The AWS documentation on elastic-load balancing states that “Elastic Load Balancing [is a scaled service that] automatically distributes your incoming application traffic across multiple EC2 instances. It detects unhealthy instances and reroutes traffic to healthy instances until the unhealthy instances have been restored. Elastic Load Balancing automatically scales its request handling capacity in response to incoming traffic.” This excerpt is stated at the top of the lab script to provide greater comprehension for action of Elastic-Load Balancing.
Elastic load balancing is found in the EC2 service, under ‘Load Balancers’. The load balancer created has the following specifications:
Load Balancer name: DinoStoreLB
Load Balancer Configuration: Kept as default
Security Group: WebRDPGroup
Ping Protocol: TCP (This influences the Load balancer choice at the start of the creation.)
Ping Port: 80
-Add the two web servers created in prior labs
The instances are defined as being ‘Out of Service’ until the registration process finishes. Once registered, they are defined as being ‘In Service’.
The load balancer public DNS is then copied and paste into a new tab with the website name as its suffix. This supplies the DinoStore site but cycles through the two different IPs belonging to the web server instances.
Removing one of the instances results in the load balancer only having the single IP address use, so there is no change to the IP address of the DinoStore site.
Once the removed instance is re-instated, the load balancer can now choose between using either IP again.
I didn’t find any challenges or difficulties in this lab. I did however, have to track back on my initial creation of the elastic IP as I had chosen the wrong type.
Not so much a challenge, but more of an interesting aside; I noticed that changes that were installed into the web server’s (IP 172.31.21.72) DinoStore application weren’t immediately changed on my LabSix-WS instance (IP 172.31.16.31). I concluded from this that the image is only as relevant as the time when it was taken. To resolve the discrepancies between my server and its image, I created a new image (IP 172.31.17.235), which was re-instated instead of the removed LabSix-WS image.
The lack of interchange of adjusted information between an instance and its image, does make me wonder how relevant images are for servers that are frequently updated, as a new image then also needs to be made in response to the update.