Lab 8: Using ELB to Scale Applications.

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

002 Review ELB003 Review ELB Part 2

The instances are defined as being ‘Out of Service’ until the registration process finishes. Once registered, they are defined as being ‘In Service’.
005 New ELB Instances description

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.

This slideshow requires JavaScript.

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.

This slideshow requires JavaScript.

Once the removed instance is re-instated, the load balancer can now choose between using either IP again.

This slideshow requires JavaScript.

 

Challenges
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.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s