AWS-EC2-2

-

AWS Load Balancer

For handling the high bandwidth of HTTP request and response. Multiple servers can host the same backend service, but it is hard to be picked by the client in which the IP address of the host is the one. Additional, when no matter the auto-scaling group working or manually to scale-out or scale-in, the IP address should be added to or be deleted from the list of hosts which for hosting the service
  • Elastic Loading Balancing responses to separate and distribute the traffic to multiple targets, like EC2, ECS, Lambda, etc. 
  • ELB listener should be assigned at least two availability zones
  • Each availability zone only can have one ELB node which should be assigned to a public subnet in this AZ if the traffic is public traffic, but if the traffic is coming from internal AWS instance, then the ELB node should be assigned into the private subnet in this AZ,
  • ELB categories:
    • Classic Load Balancer
    • Application Load Balancer
    • Network Load Balancer

Elastic Load Balancer

  • Overview Structure

  • Internal Implementation


  • Only able to balance the inbound traffic, ELB cannot balance the outbound traffic
  • ELB sends the traffic to the Eth0 of EC2 instance, but if the Eth0 was bounded multiple IP addresses then ELB will send the traffic to the primary IP address
  • ELB was charged since its status has been changed to Active

ELB Listener and Node

For listening to the connection requests, also the client can configure the port protocol for the ELB listeners. Each availability zone should have and only have one ELB node.

  • Classic Load Balancer
    • HTTPS, HTTP, TCP, SSL
    • Directly binding by EC2, and only accept the EC2 instance as the target
  • Application Load Balancer
    • HTTPS, HTTP (application layer)
    • Bind the target group which contains all targets, and then distribute the traffic to each target
  • Network Load Balancer
    • TCP, TLS (transport layer)
    • Bind the target group which contains all targets, and then distribute the traffic to each target

ELB Health Check

ELB health check will keep checking all the targets which were registered to the ELB. If the checking result is failed, then ELB will stop to send traffic to the target which has the out-of-service service.
  • How it works
    • ELB keep sending an HTTP ping request to target, if the target response within the expected time period, then the result is 200 (OK), otherwise it failed.
  • Health Check Parameters
    • Classic Load Balancer
      • Ping Protocol: HTTP (HTTP, HTTPS, TCP, SSL)
      • Ping Port: 80 (1 - 65535)
      • Response Timeout: 5s (2s - 60s)
      • Health Check Interval: 30s (5s - 300s)
      • Unhealthy Threshold: 2 times (2 times - 10 times) *continually happened
      • Healthy Threshold: 10 times (2 times - 10 times) *continually happened
    • Application Load Balancer
      • Ping Protocol: HTTP (HTTP, HTTPS)
      • Ping Port: 80 (1 - 65535)
      • Response Timeout: 5s (2s - 60s)
      • Health Check Interval: 30s (5s - 300s)
      • Unhealthy Threshold: 2 times (2 times - 10 times) *continually happened
      • Healthy Threshold: 10 times (2 times - 10 times) *continually happened
      • Success Code: 200 (200 - 299)
    • Network Load Balancer
      • Ping Protocol: TCP (HTTP, HTTPS, TCP)
      • Ping Port: Traffic Port (1 - 65535)
      • Response Timeout: 10s (HTTPS, TCP), 5s (HTTP)
      • Health Check Interval: 30s (5s - 300s)
      • Unhealthy Threshold: [Must same to Health Check Threshold]
      • Healthy Threshold: 3 times (2 times - 10 times) *continually happened
      • Success Code: 200 (200 - 299)

Internet-Facing ELB (public traffic)

Receiving traffic comes from the public internet
  • The internet-facing ELB will be assigned a public DNS name which is used in separate the coming traffic request and randomly decode to one of all ELB nodes. 
  • Each internet-facing ELB Node will have existed in a public subnet because each ELB Node will be assigned a public IP address
  • Not all of the EC2 instances should exist in the public subnet, but in the public subnet of the same AZ, there is an ELB node existed.

Internal ELB (private traffic)

Receiving traffic comes from the internal of AWS
  • The internal ELB will be assigned a private DNS name which is used in the same way of internet-facing ELB
  • Each internal ELB Node will be assigned a private IP address 
    • The private IP address comes from the subnet CIDR
    • The minimum suffix of CIDR of subnet CIDR is 27, at least 8 available IP addresses for ensuring the availability of the elasticity of ELB 
  • Even though the EC2 instance may have its own public IP address, but for internal ELB, it will be assigned separated traffic to EC2 instance with the private IP address

ELB Node Scalability

In each ELB node, it is not a single host. Inside of it, AWS did redundancy for each ELB node. In each ELB node, there are several ENIs which is bounded an IP address for each. In the internal ELB, the ELB node is in the private subnet, and then for each IP address which bounded in each ENI should be a private IP address. All of the IP addresses should be reserved from the private subnet CIDR. For the best experience for the ELB Node Scalability, AWS suggests at least reserved 8 available IP addresses from CIDR for the ELB Node.
  • During scaling, ELB Node needs a few minutes to start and register new ENI to the ELB Node Domain Name Service (default TTL is the 60s)
  • If the traffic is too large, and the ELB Node scaling cannot catch up with the speed, then it will return the 503 error code, therefore, there is no mechanism like a queue to handle this scenario
  • Therefore, ELB is not good at traffic rapidly increase or decrease
  • But the user still can contact AWS support to manually warm up the ELB for being able to handle this scenario

ELB Cross-Zone Load Balancing


  • The percentage of data received by each ELB Node is the same
  • The ELB Node which in the less-instances AZ will distribute some traffic to other AZs for balancing the entire traffic for all instances
  • The Cross-Zone traffic is not free to compare to the inner traffic in AZ so that it is better to balance the instances by the architect 
  • By default, the Cross-Zone load balancing is different in different ELBs
    • CLB: disabled
    • ALB: enabled
    • NLB: enabled
  • All ELBs are not working with cross-region

ELB Security Group and NACL

  • ELB has to be assigned a security group
  • ELB  security group should have its own inbound rule for allowing the traffic comes from the frontend
  • ELB  security group should have its own outbound rule for allowing the traffic (both for EC2 and for health check) comes from the backend
  • ELB NACL should have its own inbound and outbound rules for allowing the traffic which contains the traffic for request, response and health check

ELB Protocol

The Load Balancer Protocol is the Frontend Protocol, and the Instance Protocol is the Backend Protocol
  • Supported protocols
    • HTTPS (Application Layer, 443)
    • HTTP (Application Layer, 80)
    • TCP (Transport Layer, 80)
    • SSL/TLS (Transport Layer, 443)
  • Frontend and Backend Protocols should be consistent
    • example, if the frontend traffic comes with HTTPS protocol, when the ELB sends the traffic to the backend, the backend protocol should be the same as the frontend protocol, which is HTTPS protocol.
  • Load Balancer Protocol Encrypted Protocol
    • By using an encrypted protocol, it needs a client certificate
    • Amazon Certificate Manager (ACM)
      • For managing all certificates for user
      • Import or export certificate through ACM
      • If ACM doesn't support the certificate, the user could use IAM
      • The certificate from ACM cannot import to IAM
    • The certificate used in the internet-facing ELB always a Certificate Authority (CA) which is certified by a trusted organization, not a Self-signed Certificate
  • Instance Protocol Encrypted Protocol
    • Not just the traffic from the client to ELB could be encrypted, the traffic from ELB to instance also could be encrypted. But generally, we do not encrypt the traffic from ELB to instance, because AWS promised that only the ends of two side can listen to the data and event, even in the same account.
    • For stopping the encrypting text, at the ELB, the client needs to do the SSL/TLS termination, and then from ELB to the instance, can communicate with clear text
    • The certificate could be not just CA, it also works with a self-signed certificate. Because of that in the inner internet, the user doesn't have to prove that "I am Me"

SSL Negotiation

Before the client needs to send an HTTPS/SSL/TSL request to ELB, they need to do the encryption request handshake (negotiation)
  • Cryptographic Protocol
    • SSL v3
    • TLS v1
    • TLS v1.1
    • TLS v1.2
  • Cipher Algorithm
    • ECDHE-ECDSA-AES128-GCM-SHA256
    • ECDHE-RSA-AES128-GCM-SHA256
  • Server order preference (Depends on which, server cipher list or client cipher list)
    • If enabled, then the first matched cipher from the server cipher list to client cipher list will be selected

Session Stickness

  • By default, the traffic from ELB to the instance is stateless traffic so that there is no storage for storing the status. For ELB, each traffic request is randomly sending to an instance, so that for the case which needs to maintain the communication, the session should be saved in somewhere
  • To enable this setting, AWS will store your current state in the local browser cookie, and then implement the session stickiness function
  • Classic ELB and Application ELB support the session stickiness.

Connection Draining 

  • When there is one EC2 is unhealthy, by default AWS will deregister this EC2 instance from ELB immediately. But if the connection draining is set to enable, then AWS will wait for a while, after the session completed the EC2 will be deregistered.
  • The waiting time could be set from 1s to 3600s (1hour)
  • During the draining time, ELB won't send any new request to this EC2 instance, and the status of this EC2 instance will become to InService: Deregistration Currently in Progress, and at this time the auto-scaling group won't terminate the EC2 instance too
  • If after the draining time, there still is any session that hasn't completed yet, then ELB will force to terminate these sessions, but AWS will continue to complete those terminated sessions and connect to a new healthy EC2 instance to complete them and keep session stickiness

ELB Monitoring

  • ELB will send metrics to CloudWatch per min
  • Metrics include
    • BackendConnectionErrors
    • HealthyHostCount
    • Latency
    • ...
  • Access Log
    • By default it is disabled
    • If enable it, the user should specify an S3 bucket to store the access logs
    • Access logs include request time, request IP, etc.

ELB Target Group

  • For the classic load balancer, all of the EC2 instances are directly bind onto the load balancer. 
  • But for the application load balancer and network load balancer, there is a middleware called target group. The load balancer will default distribute traffic to each target which inside of the target group, and each target is not just EC2 instance, it could be Lambda (only ALB), even an IP address.
  • Each target group is only able to contain the same target type and using only one protocol
  • But each target could be registered by the same target with the different port number
  • Health check port by default is the same to traffic port, but it could be override

ELB Headers

  • For CLB and ALB
    • When a client request is coming to load balancer, there are three header options will be added to the header before doing the load balancing 
      • x-forwarded-for: for recording the source IP
      • x-forwarded-proto: for recording the connection protocol
      • x-forwarded-port: for recording the connection port
    • The reason for adding these three headers is because when the original traffic get separated and be sent to a different target, the source IP, connection protocol and connection port will point to the load balancer, but the instance cannot track the original IP, protocol and port
  • For NLB
    • Because NLB is in layer 4 (transport layer), there is no Https/Http request, the header exists in the request. Therefore, the NLB doesn't have this functionality

ELB Listener Rule

  • ALB could have multiple ELB listeners, and each of them could set more than one rules
  • Some of ELB rules like the rules in ALB can have if...else condition statements and each rule needs to be bound an action which will be executed by after satisfied all conditions
  • Conditions
    • Host header
    • Path
    • Http Header
    • Query String
    • Source IP
  • Actions
    • Forward to
    • Redirect to
    • Return fixed response
    • Authenticate (Https only)
  • The rule will evaluate the condition by ID, once a condition got satisfied, it won't go-ahead for evaluating the next condition

Network Load Balancer

  • NLB is existing at layer 4 (transport layer) so that it cannot understand the Http request, certainly, it cannot see the Http request header too.
  • It is high-efficiency because it cannot understand the package of the Http request, it only transfers the segment/datagram, therefore it doesn't need to calculate/compute for the package
  • If the network load balancer chooses the TCP protocol, the instance has to choose the TCP protocol too
  • Only the Network Load Balancer can bind the static IP address for an NLB Node, therefore users can directly access the IP address of NLB Node instead of using DNS Name
  • NLB support to establish 5500 concurrent connections to a target at the same time, if 5500 is not enough, the user can bind the same host to another target to obtain another 5500 connections
  • NLB doesn't support connection multiplexing (multiple requests per connection), because the NLB target will receive a lot of connections
    • For example, some other connections get improved that can received multiple Http requests in one connection (like after handshake to establish a stable connection), but in NLB, there is only accept single request per connection

Comments

Post a Comment

Popular posts from this blog

Union Find 模板

-
Union Find Union Find Union Find 动态的计算联通块问题 结构 global variables constructor() find(int x) union(int a, int b) 模板 (Map) global variables private Map<Integer, Integer> f; constructor() UnionFind(int n) { this.f = new HashMap<Integer, Integer>(); for (int i = 0; i < n; i++) { f.put(i, i); } } find(int x) int find(int x) { int root = x; // 找到“根” while (f.get(root) != root) { root = f.get(root); } // 拆“整”为“零”，把每个元素直接接到“根”上 while (root != x) { int nx = f.get(x); f.put(x, root); x = nx; } return root; } union(int a, int b) void union(int a, int b) { int rA = find(a); int rB = find(b); if (rA != rB) { f.put(rB, rA); } } 例题 Friend Circles 根据模板添加额外的全局变量，比如此题需要count，在每次合并的时候 count-- ，在初始化的时候或者写一个 setter 和 getter 去给 count 赋值和取值 public class Solution { class UnionFind { private int count; private Map...
Read more

Tree的经典题

-
Tree的经典题 Tree的经典题 找第k小 Kth Smallest Element in a BST 在树上就不需要使用Heap了，因为inorder traversal本身就是一个从小到大的序列，这里我们有几种方法 1. Recursive traversal 创建全局变量，记录traverse到哪儿了，当走到k的时候把值赋给result即可 时间复杂度 O(n) public class Solution { //设置全局变量 private int count = 0; private int result = 0; public int kthSmallest(TreeNode root, int k) { traversal(root, k); return result; } private void traversal(TreeNode root, int k) { if (root == null) { return; } traversal(root.left, k); //如果count等于k的时候才把结果赋给result //注意count从0开始，所以count先++之后再判断 count++; if (count == k) { result = root.val; } traversal(root.right, k); } } 2. Quick Select on Tree 首先要traverse计算每个点到它的时候子树总共有多少个点，然后用quick select，如果大于k，直接去左边找，如果小于k，判断当左边的个数加1正好等于k，那么这个k就落在root上，如果加1之后还小于k那么就要去向右边找了，因为此时左边没有第k个点。 时间复杂度 O(n) 最好最坏都是 public class Solution { public int kthSmal...
Read more

Tree DFS

-
Tree DFS Tree DFS Tree上的DFS分为两种（Divide Conquer + Traversal和纯Divide Conquer） 建立当前/用全局变量（根据不同的方式） root 为 空 （ 返回 什么/ 更新 指针） 左 节点和 右 节点 都 为 空 ，用 root 构建 当前 解（ 返回 什么/ 更新 指针） 左 节点和 右 节点 不 为 空 ，用 左右 构建 当前 解 返回 当前 /选择 左 ， 右 ， 中 Divide Conquer + Traversal 不同 一般 没有 全局变量， 创建当前 变量作为当前最终解 通过 左 节点的最终解和 右 节点的最终解， 计算 并更新 当前 变量 判断 左 节点的最终解， 右 节点的最终解， 当前 变量，在三个解中 选择 一个 作为当前层的最终解 返回 更新传入的参数指针 （ 有时会单独建立 class Result 类 ） 流程 建立 当前 变量（不一定第一步） root 为 空 （ 返回 什么） left 节点和 right 节点 都 为 空 ，用 root 构建 当前 解（ 返回 什么/ 更新 指针） left 节点和 right 节点 不 为 空 ，用 左右 解 leftResult , rightResult 计算 当前 解 选择 符合的解 比较 （ leftResult ， rightResult ， result ） + 选出 合适的解 直接使用 ：当前解 使用 选中的解 返回 更新 传入的指针 例题（Minimum Subtree） public class Solution { class Result { TreeNode minSubtree; int minSum; int sum; Result(TreeNode minSubtree, int minSum, int sum) { this.minSubtree = minSubtree; this...
Read more