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.
Related
For an ALB (which has a security group containing more than one AZ for HA) to make sense, the EC2 instances in the ALB's target group ALSO have to be living on more than one AZ, is that correct?
Otherwise, if all instances are in the same AZ but the ALB supports multiple AZs, this doesn't make sense, am I getting this right?
ALB's target group ALSO have to be living on more than one AZ, is that correct?
It is incorrect. You don't have to place them in more than one 1 AZ. But they still have to be at least in one of the AZs enabled for the ALB - it can't be a different AZ.
And the reason why you don't have to do it, is because for ALB cross-zone load balancing is always enabled:
When cross-zone load balancing is enabled, each load balancer node distributes traffic across the registered targets in all enabled Availability Zones.
With Application Load Balancers, cross-zone load balancing is always enabled.
this doesn't make sense, am I getting this right?
Sort of. You ALB requires two AZs for HA. Thus, placing all instances in one of them is not really recommended. But sometimes you have to do it. An example is that your instances in ASG share a pool of EBS volumes. EBS volumes have zonal scope, so you have to bound all your instances to a single AZ.
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.
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 am looking for how to specify the zone I want to deploy to in a single instance deployment, with autoscaling, while also having automatic failover to another zone -- Do any options exist to achieve this?
More context
Due to how reserved instances are linked to a single availability zone (AZ), we find it to be a good strategy (from an "ease of management"/simplicity perspective), when buying reserved instances for our dev environment, to buy them all in a single zone and then launch all dev instances in that single zone. (In production, we buy across zones and run with autoscale groups that specify to deploy across all zones).
I am looking for how to:
Specify the AZ that I want an instance to be deployed to, so that I can leverage the reserved instances that are tied to a single (and consistent) AZ.
while also having
The ability to failover to an alternate zone if the primary zone fails (yes, you will pay more money until you move the reserved instances, but presumably the failover is temporary e.g. 8 hours, and you can fail back once the zone is back online).
The issue is that I can see how you can achieve 1 or 2, but not 1 and 2 at the same time.
To achieve 1, I would specify a single subnet (and therefore AZ) to deploy to, as part of the autoscale group config.
To achieve 2, I would specify more than one subnet in different AZs, while keeping the min/max/capacity setting at 1. If the AZ that the instance non-deterministically got deployed to fails, the autoscale group will spin up an instance in the other AZ.
One cannot do 1 and 2 together to achieve a preference for which zone an autoscale group of min/max/capacity of 1 gets deployed to while also having automatic failover if the zone the server is in fails; they are competing solutions.
This solution uses all AWS mechanisms to achieve the desired effect:
Launch the instance into the preferred zone by specifying that zone's subnet in the 1st autoscale group's config; this group's min/max/capacity is set to 1/1/1.
Create a second autoscale group with the same launch config as the 1st, but this other autoscale group is set to a min/max/desired of 0/1/0; this group should be configured with the subnets in every available zone in the region except the one specified in the 1st autoscale group.
Associate the 2nd autoscale group with the same ELB that is associated with the 1st autoscale group.
Set up a CloudWatch alarm that triggers on the unhealthy host alarm for #1's autoscale group; have the alarm change the #2 autoscale group's to a min/max/desired of 1/1/1. (As well as send out a notification so that you know this happened).
If you don't expect to get unhealthy host alarms except in the cases where there is an actual host failure or if the AZ goes down -- which is true in our case -- this is a workable solution.
As you have already figured out, (as of mid-2015) that's not possible. Auto-scaling doesn't have the concept of failover, strictly speaking. It expects you to provide more than one AZ and machines enough in each one if you want to have high availability. If you don't, then you aren't going to get it.
The only possible workaround I can imagine for this is setting up a watchdog yourself which changes the auto-scaling group's subnet once an AZ becomes unavailable. Not so hard to do, but no so reliable as well.