Lab 9: Enabling Auto Scale to Handle Spikes and Troughs

The lab script contains an excerpt from the AWS documentation in regards to auto scaling: “Auto Scaling is a web service designed to launch or terminate Amazon EC2 instances automatically based on user-defined policies, schedules, and health checks.”

Auto Scaling is found under the EC2 service.
001 Launch Configurations

The ‘Launch Configurations’ option needs to be selected, then clicking on ‘Create Auto Scaling Group’ followed by ‘Create Launch Configuration’.
The configuration needs to have the following specifications:

002 Choosing Web Server from my AMIs

My AMIs: DinoStoreWebServer
Instance: t2.micro
Name: scale-web
IAM Role:  WebServerRole
Security Group: WebRDPGroup
Key Pair: (I’m using an existing key pair)

003 Review Launch 1 of 2004 Review Launch 2 of 2
In ‘Create Auto Scaling Group’ a group needs to be created with the following specifications:

Group Name: scale-web-asg
Group Size: starting with two instances
Network: Default VPC
Subnet: Default subnets for each Availability Zone

005 Create Auto-Scaling Group

Advanced Details:
Receive traffic from ELB: DinoStoreLB
Health Check Type: ELB
006 Advanced details 9_1_c_v
Configure Scaling Properties:
Group remains at initial size
007 Auto-Scaling Policies
Tags-Name:ASG-WebServer, Tag instances

 

In the EC2 dashboard, the auto scaling information shows the instances launch, as does the instance screen.
The lab script makes mention that the manually created servers would usually be deleted before or after the set up of the auto scaling group. This would be because of their inability to scale.
The load balancer screen also shows the status of the instances in service.
012 AS w Two Instances

Using the load balancer URL, the DinoStore web site can be displayed. Upon refreshing the site, the internal IPs change.

This slideshow requires JavaScript.

For this all of my instances attached to the load balancer were utilized.

Then in the EC2 instance window, the web server and its image (the non auto-scaling instances) need to be terminated, before testing the DinoStore site refresh to check the number of IPs available.

This slideshow requires JavaScript.

The number of different IPs available dropped down to match the number of auto scale IP instances within the load balancer.

In order to test the auto scaling, one of the autoscale instances needs to be terminated, and then the EC2 instance window and the auto scaling groups window need to be checked for a new instance being automatically created.
020 AS Instances Starting with Available Space
After the new instance is in service, the DinoStore page again needs refreshing to check the number of IP addresses. (This has more than one new instance in progress as I was playing around with the settings and set the desired number of instances to five.)

 

Challenges
The challenge I faced with this lab was due to my lack of knowledge that I can only have ten EC2 instances available at any one time. The auto scaling group ended up failing because of this limitation, which I had reached with the rest of my instances.
010 Auto-Scaling -Activity History w One Instance
In order to resolve this, I terminated any unnecessary instances.

Advertisements

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.

Introduction to Elastic Load Balancing

Introduction and Aim
The purpose of this lab is to gain an understanding of the Amazon Elastic Load Balancer. QwikLabs describes the Amzon Elastic Load Balancer (ELB) as a ‘service that automatically distributes incoming application traffic across multiple EC2 instances.’ This can increase the fault tolerance in applications as the ELB service responds to incoming traffic with the required load balancing capacity. The ELB service can be provided for within a single availability zone, or throughout many zones. This service can also be used in a VPC.

 

Goals

  • Logging into the Amazon Management Console
  • Creating an Elastic Load Balancer
  • Adding Instances to an Elastic Load Balancer

 

Logging into the Amazon Management console
When using AWS, I log into the console through my administrator account rather than my root account. This is a security measure as my root account has access to the financial aspect of AWS. If I were intending to use AWS in  a business scheme or for sensitive information, I would have more users, each with access corresponding to the level of security required.
In order to reduce latency, my AWS account is set in the Sydney region. Although not every service is available at the Sydney zone, I’m currently only working with the basics of what AWS can provide, so I haven’t yet come across any availability issues.

 

Creating an Elastic Load Balancer
ELBs are located within the EC2 service. For this lab, I choose a classic load balancer which I’ve called ‘free-lab-load-balancer’.
Classic LB
The security group assigned to the ELB is a new one called ELB-SG1. The lab script has a preset one, but as the lab script is being used only as a guideline, then I needed to use an existing one or make a new one.
InkedAssign SG (NEW) New SG_LI
The Type is an AWS preset configuration, so I’m keeping it as is.

The next step in the Load Balance launch is the ‘Configure Security Settings’,  in which nothing is changed, so I just move onto the ‘Configure Health Check’ screen. When I did this, a warning screen appeared:
Config Sec Settings Warning
This warning is something to be heeded for future professional use, but not for this lab.
The lab script asks for the following values:
Response Timeout: 2 seconds
Health Check Interval: 6 seconds
Unhealthy Threshold: 2
Healthy Threshold: 2
Config Health Check

The next step is to add EC2 Instances, I chose two arbitrary instances that were displayed in my instance option list.
Adding EC2 Instances

As Tags are not a part of this exercise, I move on to the final step of reviewing all the load balance specifications.
ELB Review
After checking that everything was according to the script, the load balance can be created.

 

Once the load balance is created, I can click on the ‘Instance’ tab alongside the ‘Description’ tab near the bottom of the screen. ELB has alt-text that is displayed over the ‘i’ picture next to the instances. The alt-text reports on the status of the instances in relation to the load balance.
Instances Within the ELB
In the ‘Description’ tab, the DNS field name contains a hyperlink that when copied into the browser window, directs to the load balance page. QwikLabs states that ‘While it all looks the same on the front end, as you refresh the page, on the back end your requests are being load balanced between your two running instances.’

The DNS link didn’t work for me, and instead just showed a blank screen. Upon further inspection with the Firefox developer tool, the network was reporting an Error 503, which is a back end server problem.
Back End Server Unavailable

I considered that perhaps I had made a mistake during the load balance launch process, so I created another load balance, taking a look at a classmate’s blog for assistance and rigorously looking over the lab script again.

The DNS link result this time was: Server not found. Using the developer tool, I was able to see that it wasn’t the same problem as my previous load balance as my previous load balance, which implied that it wasn’t a back-end server issue anymore.
Network Display for LB 2
DNS Resolution
Unfortunately, I still didn’t know what the problem seemed to be, or why the problem was no longer a back end issue.

 

Conclusion
This was an interesting lab in the application of a multi-instance service such as the Amazon Elastic Load Balance. I would like to know why the DNS link failed, and I’m not confident that I could determine that on my own. Having a trained person explain the methods and reasons behind the specifications of the launching of an ELB, may be a beneficial method in helping me understand how to correctly implement the ELB service.