Depending on your design, you can configure either a round-robin or least outstanding request algorithm to distribute the load to the backend servers in a target group. While the round-robin algorithm is widely used, it does have a few architectural issues to consider. It cannot take into consideration the target server’s capacity and utilization when distributing traffic. One web server may be running on a small EC2 instance and others on a faster, more capable server. However, round-robin will not have this awareness and will distribute all connections evenly as if they all had the same capabilities that could create uneven load distributions.
The least outstanding requests algorithm is when each new request will be forwarded to the target server with the least number of requests. Targets with long-lasting connections will not be further loaded with new requests, and the workload is more evenly spread across all targets in a group. Also, if a new server is added, it will receive the majority of the new connections since it has the lowest connection count and will offload the burden from the existing servers.
When taking a server offline, it’s a good practice to not forcefully disconnect the existing sessions but, rather, allow them to complete their sessions while also not allowing any new connections to the servers. The deregistration feature is used to gracefully shut down a target server’s connections. The connection draining is defined in the target group and, when enabled, instructs the load balancer to stop sending new connection requests to the servers in the target group. Existing connections will remain and will not be forcefully disconnected until they complete their connection or the deregistration delay time is reached. The timer value can be configured from 0 to 3,600 seconds with a default value of 300 seconds.
Deregistration is configured in the target group on the Group Details tab by selecting Edit attributes, as shown in Figure 4.9.
Load balancer deletion protection prevents a load balancer from being deleted when this feature is enabled. Deletion protection is disabled by default, and it’s a good practice to enable it. The only way to delete a load balancer when deletion protection is enabled is to disable the feature and then perform the deletion steps.
FIGURE 4.9 Deregistration delay
To enable deletion protection, select the load balancer in the web console and click the Edit attributes box. The pop-up allows you to select and save the deletion protection feature.
Figures 4.10 and 4.11 detail enabling deletion protection and the error received when attempting to delete an ELB that has deletion protection enabled.
FIGURE 4.10 ELB deletion protection
FIGURE 4.11 ELB deletion protection warning
Health checking is the determination that the backend servers are operational and able to accept connections from the ELB. The ELB will send out periodic connection requests to each server and listen for a healthy response code to be returned from the server. If the server responds positively, then the ELB will forward connections to it. However, if the server does not respond, it will be taken out of the rotation, and alarms will be generated for remediation.
The health checks are configured in each target group and allow you to define the protocol such as HTTP or HTTPS and advanced features such as TCP port number to check and the URL path on the server, with / being the root of the web server’s directory. The healthy threshold defines the number of consecutive health checks that must be successful for the ELB to consider the server healthy. The unhealthy threshold defines the number of consecutive health check failures to take the server offline. The healthy threshold is five checks, and unhealthy is two checks. The time-out value is a default of 5 seconds and is the time the ELB will wait for the server to respond, and the interval is the time between ELB health checks and is set to 30 seconds by default. Finally, the HTTP respond code to listen for is 200, which indicates that the request was successful. See Figure 4.12 for the health check configuration screen in the ELB target group section of the console.
If all of the targets fail health checks in a group, the ELB will fail to open and forward requests to all servers in the group. Also, note that the WebSockets protocol does not support health checking. The actual health checks consist of the ELB making a connection request to the backend target, and after the response is received, the ELB will close the connection request.
Acedexam Training Policies
Learning resources
Other resources
Our Training Providers
