I'm working my way through a practice exam for an AWS certification. One of the questions is as follows:
The web tier for an a pplication is running on 6 EC2 instances spread
across 2 AZs behind a classic ELB. The data tier is a MySQL database
running on an EC2 instance. What changes will increase the
availability of the application? (select TWO)
A: Turn on CloudTrail in the AWs account
B: Migrate the MySQL database to a Multi-AZ RDS MySQL database instance
C: Turn on cross-zone load balancing on the ELB
D: Launch the web tier EC2 instances in an Auto Scaling Group
E: Increase the instance size of the web tier EC2 instance
Correct answers are B and D. My question is, why is C NOT a correct answer? The instructor (an Amazon employee) glosses over C, explaining that "enabling cross-zone load balancing would have little to no effect on availability." But the way I'm looking at it, if the ELB can't send traffic to both AZ's, then we're effectively making our 6-instance system into a 3-instance system (assuming there are 3 in each AZ). And a single AZ system is never the considered a highly available architecture, since if that one AZ fails, your whole system is unavailable.
Enabling cross-zone load balancing does not impact availability because ELBs can send traffic to all configured AZs without the feature enabled. That's not what cross-zone balancing means.
An ELB configured in two availability zones always has at least two balancer nodes, one in each AZ. You can't see this, directly, but if you look under "Network Interfaces" in the EC2 console, you can find the Elastic Network Interfaces (ENIs) attached to the balancer nodes. Each node has one ENI. The service determines how many nodes a balancer has, based on load. This is managed automatically, and you are not billed based on node count.
Cross-zone load balancing controls what each node can do. "Enabled" means the balancer node in zone A can send traffic to instances in zone A or B, instead of just to instances in zone A, and the same for the balancer node in zone B.
This doesn't improve availability because if an availability zone is lost, then the balancer node in that zone is also lost, so the fact that it could have sent traffic to instances in the other zone is immaterial.
Cross-zone load balancing helps ensure that the workload is spread as evenly as possible across all instances behind the balancer, which helps if you have asymmetry -- such as 3 application instances in one AZ and 2 application instances in the other (in this case, the zone with 2 would see proportionally more traffic per instance than the zone with 3) -- or other cases where the instances are not seeing evenly-balanced workloads, which would be more likely when the number of instances behind the balancer is small or if there is wide variation in request processing time due to the complexity of certain requests compared to others.
What changes will increase the availability of the application?
Increased availability means that there are less time periods where the application is serving requests.
(B) Multi-AZ database will certainly help because if one AZ fails, it will automatically promote the secondary database server in the other AZ
(D) Auto Scaling will certainly help because failed instances will be replaced.
Cross-zone load balancing would help where there are no healthy instances available in an AZ but traffic is being handled by the ELB in that AZ. It is an unlikely scenario, especially with 3 instances in an AZ, but I could understand an argument for it. However, the other two answers are much stronger.
It's worth mentioning that official AWS Certification questions go through several levels of technical review and shouldn't leave such ambiguity in a question. Sample exam questions (be it in an AWS course or otherwise) probably haven't gone through such detailed scrutiny.
Related
I am about to take my AWS Architect Associate Certification Exam and I have some things on ELB and ASG that I still don't get (or maybe I just did not study enough) and I liked to ask your help to clear things out.
Multi-AZ Autoscaling Group
what difference does it make when I say I have one ASG that will handle
autoscaling for 3 AZs rather than have one ASG for each AZ? If fault tolerance
is the answer then the latter should be the standard setup, why have one ASG
for three or two AZs?
Multi-AZ ELB
same kind of question as I had for #1.
3.
Multi-AZ ASG and one ELB for each AZ
Multi-Az ASG and one ELB that serves multiple AZs
One ASG and One ELB for each AZ
What are the use cases for each?
The answer becomes more obvious when you think about the implications and understand what may be some missing details.
If an ASG crosses multiple availability zones, then it can increase capacity in the healthy zones when the instances in a catastrophically failed AZ become unavailable. With one in each, there would be no coordination like this.
The same thing is true for ELB. In both Classic and Application load balancers, when you deploy a single ELB in multiple AZs, you actually get balancer hardware allocated from the beginning in each AZ -- yet the price is the same. If an AZ fails, it fails, and you still have working hardware in the remaining zones.
ELBs and ASGs in a single AZ would not be fault tolerant, and there's no reason to provision separate ones for each AZ, when you can provision just one, and have it handle the failure of an entire availability zone (unlikely, but not impossible) by scaling out (deploying more hardware) capacity in the healthy zones that remain.
AWS recently introduced NLB (Network load balancer) where EIP (Elastic IP) can be linked to a AZ (availability zone). It is recommended to have NLB over multiple AZs hence have multiple EIP linked to each.
But what happens when one of the AZ goes down, does the linked EIP gets linked to other AZ till the original AZ comes back again? This is important if you are using single EIP (i.e. using one AZ for NLB) where such failure can cause traffic failures even though your servers running on multi-AZs are up and running.
Answering my question for anyone struggling with similar question. This is what AWS support responded to my question
Availability zones (AZs) are distinct geographical locations that are engineered to be insulated from failures in other AZs. However, unfortunately when an AZ fails the service is disrupted on that AZ. There would be no IP shift to another AZ automatically[1].
Although AZ failures are rare and AWS takes great efforts to not have such failures, these type of failures can and do occur. For this reason we normally ask users to place resources(NLB) in multiple AZs. This way an application can be protected from failure at a single location. If one zone fails, the application in the other zone can continue to run[2].
[1]https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html#concepts-regions-availability-zones
[2]https://media.amazonwebservices.com/architecturecenter/AWS_ac_ra_ftha_04.pdf
The EIP stops working if there are no healthy instances in the AZ, and NLB removes its entry from the load balancer' DNS records. It is added back in when the AZ becomes healthy again.
If one or more target groups does not have a healthy target in an enabled Availability Zone, we remove the IP address for the corresponding subnet from DNS so that requests cannot be routed to targets in that Availability Zone.
https://docs.aws.amazon.com/elasticloadbalancing/latest/network/target-group-health-checks.html
For this reason, your callers should respect the DNS TTL.
The title might be a little too much, but i am unable to find any statements regarding this. I am trying to set up computes in multiple AZ's (in a region) with auto-scaling. i am also trying to see if i can get away with only one ELB to do the load balancing act.
In this setup, the ELB is a single point of failure so, I would like to know, if anyone knows the recovery associated with ELB's. There are documentations about scaling in ELB but not the recovery/higher availability.
thanks
Make sure you select multiple AZs for the load balancer as well. You will have to in order for it to work with EC2 instances in multiple AZs anyway. When you do that, multiple ELB instances are created for you behind the scenes, one in each AZ. So the ELB isn't really a "single point of failure".
The most common issue you may see with an ELB is if you have a very quick, large burst of traffic, which will take the ELB a few minutes to scale up to meet the demand. If you know ahead of time you will be getting a large increase in traffic you can send a request to AWS support to pre-warm the ELB for you.
I recommend reading the section titled "Common Pitfalls When Testing Elastic Load Balancing" in this article.
An ELB is a logical entity that consists of multiple (at least 2 - one per AZ - and generally more) instances that route traffic to your back ends.
If an individual ELB instance were to fail, it would be replaced automatically, much in the way autoscaling replaces failed instances.
You can usually tell how many instances are in your ELB by doing a DNS lookup - you will see multiple IP addresses returned.
ELBs can become overloaded if you have a sudden burst of traffic, so they are not failure proof, but for most loads they do a very good job.
I recently started reading about and playing around with AWS. I have particular interest in the different high availability architectures that can be acheived using the platform. Specifically, I am looking for a reliable poor man's solution that can be implemented using the least amount of servers.
So far, I am satisfied with solutions for the main HA concerns: load balancing, redundancy, auto recovery, scalability ...
The only sticking point I have is with failover solutions.
Using an ELB might seem great, however ELB actually uses DNS balancing under the hood. See Is AWS's Elastic Load Balancer a single point of failure?. Also from a Netflix blog post: Lessons Netflix Learned from the AWS Outage
This is because the ELB is a two tier load balancing scheme. The first tier consists of basic DNS based round robin load balancing. This gets a client to an ELB endpoint in the cloud that is in one of the zones that your ELB is configured to use.
Now, I have learned DNS failover is not an ideal solution, as others have pointed out, mainly because of unpredictable DNS caching. See for example: Why is DNS failover not recommended?.
Other than ELBs, it seems to me that most AWS HA architectures rely on DNS failover using route 53.
Finally, the floating IP/Elastic IP (EIP) strategy has popped up in a very small number of articles, such as Leveraging Multiple IP Addresses for Virtual IP Address Fail-over and I'm having a hard time figuring out if this is a viable solution for production systems. Also, all examples I came across implemented this using a set of active-passive instances. It seems like a waste to have a passive for every active to achieve this.
In light of this, I would like to ask you what is a faster and more reliable way to perform failover?
More specifically, please discuss how to perform failover without using DNS for the following 2 setups:
2 active-active EC2 instances in seperate AZs. Active-active, because this is a budget setup, were we can't afford to have an instance sitting around.
1 ELB with 2 EC2 instances in region A, 1 ELB with 2 EC2 instances in region B. Again, both regions are active and serving traffic. How do you handle the failover from 1 ELB to the other?
You'll understand ELB better by playing with it, if you are the inquisitive type, as I am.
"1" ELB provisioned in 2 availability zones is billed as 1 but deployed as 2. There are 2 IP addresses assigned, one to each balancer, and 2 A records auto-created, one for each, with very short TTLs.
Each of these 2 balancers will forward traffic to the instance in its same AZ, or you can enable cross-AZ load balancing (and you should, if you only have 1 server instance in each AZ).
These IP addresses do not change often and though it stands to reason that ELBs fail like anything else, I have maybe 30 of them and have never knowingly had a dead one on my hands, presumably because the ELB infrastructure will replace a dead instance and change the DNS without your intervention.
For 2 regions, you have little choice other than using DNS at some level. Latency-based routing from Route 53 can send people to the closest site in normal operations and route all traffic to the other site in the event of an outage of an entire region (as detected by Route 53 health checks), but with this is somewhat more likely to encounter issues with DNS caching when the entire region is unavailable.
Of course, part of the active/passive dilemma in a single region using Elastic IP is easily remedied with HAProxy on both app servers. It's an http request router and load balancer like ELB, but with a broader set of features. The code is so tight that you can likely run it on your app servers with negligible CPU consumption. The instance with the EIP would then balance traffic between its local app server and the peer. Across regions, HAProxy behind ELB could forward traffic to a mate in a remote region, if the local region is up but for whatever reason the application can't serve requests from the local region. (I have used such a setup to increase availability of external services, by bouncing the request to a remote AWS region when the direct Internet path from the local region is not working.)
I have runnning e-commerce based ruby on rails application on AWS stack. I am running ubuntu 10.04 ec2 instances with Elastic load balancer and I have maintained equal number of instance in the both the availability zone, 1a and 1b. But according to my observation, ELB seeming to be pushing more traffic to 1a rather then dividing it equally. Though the health of the instances running in 1b is good and also I have disabled the sticky session on the ELB. I have 2 large and 1 medium instances running on both the availability zones.
What the cause of in equal distribution of the load.
In my experience, this can happen if a disproportionate amount of traffic is coming from a single network or ip address.
ELB uses different layers of balancing. DNS load balancing will send it to a set of IP addresses in one of the two zones, and the software load balancer will distribute traffic between instances in the zone.
If you have a lot of traffic coming from the same network, its likely that a lot of users are getting the same DNS resolution on your load balancer and ending up in the same zone.
If the source traffic is coming from a single Network/IP range or IP address, ELB might load balance the traffic disproportionately to the backend. I have discussed this point as well as couple of other details to note on ELB in my blog "Dissecting ELB". I have also noticed this behavior in some popular OSS LB implementations as well, You can have balance algorithm as "source" and as well as session sticky combined . If session ID is not sent on the HTTP, then it will load balance based "source".