Elastic Load Balancer (ELB)

  1. Three types
    1. Classic LB (for classic EC2) uses Transport layer (L4) or application layer (L7) of TCP/IP
    2. Application LB uses application layer of TCP/IP
    3. Network ELB (TCP)
  2. How to Create ELB
    1. Choose type of ELB
    2. Name, internal or internet facing, VPC
    3. ELB Protocol, ELB Port
      1. For Classic choose HTTP/HTTPS/TCP/SSL
      2. For application ELB choose HTTP/HTTPS
      3. Tor Network ELB choose TCP/Port
    4. Instance protocol, Instance port
    5. Assign Security Group
    6. Configure health check
      1. Ping protocol/port/path (example: /test.html)
      2. Response timeout (amount of time before response starts)
      3. Interval (amount of time between pings)
      4. Unhealthy threshold (number of consecutive failures before declaring instance unhealthy)
      5. Healthy threshold (number of consecutive pass before declaring instance healthy)
    7. Add EC2 instances
      1. Add one or more EC2s directly for classic ELB
      2. For Network ELB and Application ELB, create a new Target Group or use existing target group
        1. TG needs Name, Protocol, Port, Target Type (Instance id or ip)
        2. Add EC2 instances (instance id) or private ip/port to the TG
  3. After creating ELB note the DNS name: elbname.regionname.elb.amazonaws.com which can be updated in your DNS
  4. Session management (AWS documentation on ELB session management)
    1. By default, a Classic Load Balancer routes each request independently to the registered instance with the smallest load. However, you can use the sticky session feature (also known as session affinity), which enables the load balancer to bind a user’s session to a specific instance. This ensures that all requests from the user during the session are sent to the same instance.
    2. Stickiness can be setup thru console or CLI
    3. Elastic Load Balancing creates a cookie, named AWSELB, that is used to map the session to the instance.
    4. Duration based session stickiness:
      1. On the Edit stickiness page, select Enable load balancer generated cookie stickiness.
      2. (Optional) For Expiration Period type the cookie expiration period, in seconds. If you do not specify an expiration period, the sticky session lasts for the duration of the browser session.
      3. If there is no cookie (first request), the load balancer chooses an instance based on the existing load balancing algorithm (least loaded EC2). A cookie is inserted into the response for binding subsequent requests from the same user to that instance.  After a cookie expires (after duration from above step), the session is no longer sticky.
    5. Application-Controlled session stickiness:  
      1. The load balancer uses a special cookie to associate the session with the instance that handled the initial request, but follows the lifetime of the application cookie specified in the policy configuration.
      2. The load balancer only inserts a new stickiness cookie if the application response includes a new application cookie.
      3. The load balancer stickiness cookie does not update with each request.
      4. If the application cookie is explicitly removed or expires, the session stops being sticky until a new application cookie is issued.
      5. If an instance fails or becomes unhealthy, the load balancer stops routing requests to that instance, and chooses a new healthy instance based on the existing load balancing algorithm.
      6. The load balancer treats the session as now “stuck” to the new healthy instance, and continues routing requests to that instance even if the failed instance comes back.
      7. On the Edit stickiness page, select Enable application generated cookie stickiness.
      8. For Cookie Name, type the name of your application cookie.
    6. ELB can distribute load across EC2 instances running across AZs within a region only.
  5. You can use request tracing to track HTTP requests from clients to targets or other services. When the load balancer receives a request from a client, it adds or updates the X-Amzn-Trace-Id header before sending the request to the target. Any services or applications between the load balancer and the target can also add or update this header. If you enable access logs, the contents of the X-Amzn-Trace-Id header are logged
  6. You can use a microservices architecture to structure your application as services that you can develop and deploy independently. You can install one or more of these services on each EC2 instance, with each service accepting connections on a different port. You can use a single Application Load Balancer to route requests to all the services for your application. When you register an EC2 instance with a target group, you can register it multiple times; for each service, register the instance using the port for the service.
  7. When you deploy your services using Amazon Elastic Container Service (Amazon ECS), you can use dynamic port mapping to support multiple tasks from a single service on the same container instance. Amazon ECS manages updates to your services by automatically registering and de-registering containers with your target group using the instance ID and port for each container.
  8. If your web servers must be connected to the Internet and database servers are only connected to the web servers
    1. Create an Internet-facing load balancer and register the web servers with it.
    2. Create an internal load balancer and register the database servers with it.
    3. The web servers receive requests from the Internet-facing load balancer and send requests for the database servers to the internal load balancer.
    4. The database servers receive requests from the internal load balancer.
  9.  If you have ten instances in Availability Zone 1  and two instances in AZ2, the requests are distributed evenly between the two Availability Zones. As a result, the two instances in us-west-2b serve the same amount of traffic as the ten instances in us-west-2a. Instead, you should have six instances in each Availability Zone
  10. Advantages of ALB over CLB:
    1. Support for host-based routing. You can configure rules for your listener that forward requests based on the host field in the HTTP header. This enables you to route requests to multiple domains using a single load balancer
    2. Support for routing requests to multiple applications on a single EC2 instance. You can register each instance or IP address with the same target group using multiple ports.
    3. Support for registering targets by IP address, including targets outside the VPC for the load balancer.
    4. Support for containerized applications in Amazon Elastic Container Service (Amazon ECS)
  11. Advantages of ALB over NLB:
    1. NLB is at layer 4, does not understand applications, uses simple ICMP ping to determine the health as opposed to actual application health
    2. ALB can distribute traffic to to different web servers with own ips but port 80 running on the same host. NLB can’t
<<< Elastic Block Storage (EBS)Auto Scaling Groups and Launch Configurations >>>
Copyright 2005-2016 KnowledgeHills. Privacy Policy. Contact .