I have this question
You need to create an autoscaling managed instance group for an HTTPS web application. You want to make sure that unhealthy VMs are recreated. What should you do?
A. Create a health check on port 443 and use that when creating the Managed Instance Group.
B. Select Multi-Zone instead of Single-Zone when creating the Managed Instance Group.
C. In the Instance Template, add the label ‘health-check’.
D. In the Instance Template, add a startup script that sends a heartbeat to the metadata server.
Which is the correct answer?
You need to create an autoscaling managed instance group for an HTTPS
web application. You want to make sure that unhealthy VMs are
recreated. What should you do?
Let's analyze each possible answer to determine the best answer. There are two types of health checks, one for load balancers and the second for auto-healing. My comments below are for auto-healing.
This question is sort of a trick question. Depending on how you "read" the question, the answer can be different.
A. Create a health check on port 443 and use that when creating the
Managed Instance Group.
This is a possible answer. You can detect the health of an instance on port 443 if HTTPS is running on the instances. However, this is not the normal case. Usually, SSL offload is performed at the load balancer with backend traffic being HTTP. However, the question states "HTTPS web application". This is a key point. In order to have auto-healing, you must have or create a health check and apply it to the Managed Instance Group.
B. Select Multi-Zone instead of Single-Zone when creating the Managed
Instance Group.
This is a possible answer. If all of your instances are running in a single zone, the loss of a zone means the loss of all instances. In this case, auto-healing will not work. Using a multi-zone architecture adds zone fault tolerance. However, the loss of a zone does not mean new instances will be created in the other zones unless you also have auto-scaling enabled. Selecting multi-zone will not meet the objective of auto-healing failed VMs in all cases. You would also need to create/assign a health check.
C. In the Instance Template, add the label ‘health-check’.
This is not a possible answer. Specifying a label for an Instance Template means that the label will be applied to each instance that is created. This does nothing for health checks. This is a trick answer.
D. In the Instance Template, add a startup script that sends a
heartbeat to the metadata server.
This is not a possible answer. The metadata server does not provide health check features.
Drumroll Please ....
Therefore the best answer is A in my opinion. A is the only answer that actually does a health check.
B is a trick answer that I think will fool many people.
The best answer is a combination of A and B plus auto-scaling, but that is not an option for this question.
Related
I want to configure active-passive failover with Route-53 in which primary (Active) resource is available/running and in case of any failure, Passive instance should take over.
I want to know how we need to configure Passive EC2 instance.
I am referring to the article Active-active and active-passive failover - Amazon Route 53.
In the given scenario, if Amazon Route 53 detects a failure, it simply sends the traffic to the alternate instance.
That instance should already be fully configured ready to process any traffic it receives.
It should use the same instance configuration as 'Active-Active', except it doesn't get any traffic when the primary instance is operating correctly.
just to add to the above comment from John, You can use cloud watch to monitor the heart beat and spin up the passive instance aka make it active when you need it.
Yes, you can add a cron job or event. I am not sure whether you can use a combination of both. Refer to the screenshot for details.
In the screenshot i assumed that you have aaaaaaa as your prod instance and bbbbbbbbb as your DR instance.
I found this question..
You want to configure autohealing for network load balancing for a group of Compute Engine instances that run in multiple zones, using the fewest possible steps. You need to configure recreation of VMs if they are unresponsive after 3 attempts of 10 seconds each. What should you do?
A. Create an HTTP load balancer with a backend configuration that references an existing instance group. Set the health check to healthy(HTTP)
B. Create an HTTP load balancer with a backend configuration that references an existing instance group. Define a balancing mode and set the maximum RPS to 10.
C. Create a managed instance group. Set the Autohealing health check to healthy(HTTP)
D. Create a managed instance group. Verify that the auto scaling setting is on.
Which is the correct answer? I think is A
To configure the recreation of VMs, you need Autohealing. So not B and D.
A: Load balancing health checks help direct traffic away from non-responsive instances and toward healthy instances; these health checks do not cause Compute Engine to recreate instances.
C: Application-based autohealing improves application availability by relying on a health checking signal that detects application-specific issues such as freezing, crashing, or overloading. If a health check determines that an application has failed on an instance, the group automatically recreates that instance.
So the answer is C.
You want to configure autohealing for network load balancing for a
group of Compute Engine instances that run in multiple zones, using
the fewest possible steps. You need to configure recreation of VMs if
they are unresponsive after 3 attempts of 10 seconds each. What should
you do?
Let's analyze each possible answer to determine the best answer. Note that this question has a key phrase "using the fewest possible steps". This phrase will bias selecting the best answer.
A. Create an HTTP load balancer with a backend configuration that
references an existing instance group. Set the health check to
healthy(HTTP)
This is a possible answer. This answer assumes that the existing backend is configured correctly.
B. Create an HTTP load balancer with a backend configuration that
references an existing instance group. Define a balancing mode and set
the maximum RPS to 10.
This is a possible answer. This answer assumes that the existing backend is configured correctly. This answer adds an additional step over answer A.
C. Create a managed instance group. Set the Autohealing health check
to healthy(HTTP)
This is only a partial solution. The default configuration is auto scaling enabled. You still need to create the HTTP Load Balancer.
D. Create a managed instance group. Verify that the auto scaling
setting is on.
This is only a partial solution. Creating a Managed Instance Group with Auto Scaling is required, but you still need to create the HTTP Load Balancer.
Drumroll Please ....
Therefore the best answer is A in my opinion.
I'm trying to set up an AWS environment for the first time and have so far got a DNS entry pointing to a Classic ELB. I also have an EC2 instance running but I don't seem to be able to add the EC2 instance to the ELB in the UI. The documentation says that I can do this in the "Instances" tab in Load balancer screen but I don't have the tab at all. All I can see is Description | Listeners | Monitoring | Tags.
Does anyone have any ideas why the "Instances" tab night be missing from the UI?
There are now two different types of Elastic Load Balancer.
ELB/1.0, the original, is now called a "Classic" balancer.
ELB/2.0, the new version, is an "Application Load Balancer" (or "ALB").
They each have different features and capabilities.
One notable difference is that ALB doesn't simply route traffic to instances, it routes traffic to targets on instances, so (for example) you could pool multiple services on the same instance (e.g. port 8080, 8081, 8082) even though those requests all came into the balancer on port 80. And these targets are configured in virtual objects called target groups. So there are a couple of new abstraction layers, and this part of the provisioning workflow is much different. It's also provisioned using a different set of APIs.
Since the new Application Load Balancer is the default selection in the console wizard, it's easy to click past it, not realizing that you've selected something other than the classic ELB you might have been expecting, and that sounds like what occurred in this case.
It might be possible that you have selected Application Load Balancer instead of selecting Classic Load Balancer.
If that is the case, then you need to add your instance in Target Group as Instances tab is not available in the Application Load Balancer.
I hope above may resolve your case.
I have three EC2 instances, with a classic load balancer. Ideally I should have two tasks running in two instances. So when creating the service I made the desired count of the tasks to 2.
My problem arises when I try to run new version of the task definition. I update the service to run the new task definition. So it should theoretically run two updated tasks replacing the old ones, since i have three ec2 running.
What happens actually is only one updated task is running together with the old tasks. So altogether 3 tasks running even though the desired count is set to 2, as you are able to see in the given image.
Does anyone know a solution for this ?
When using a classic load balancer, you can only map static ports on the ec2 instance.
Your deployment settings are:
min-health: 100%
max-healthy: 200%
The new version of the service would require two more hosts available with the free tcp port you requested. Since you only have 3 servers in the cluster, this condition will not be satisfied. You can either add more servers to your cluster, or use the Application Load Balancer (ALB) which will integrate with docker dynamic port mapping.
Update regarding security groups:
To manage security groups, you can tag a security group with another. For example, tag your ALB with 'app-gateway-alb' which allows specific ports from outside your network, then on the container have a security group which allows ANY TCP from 'app-gateway-alb' this is achieved by putting the security group ID in the text box where you would generally put the CIDR rule.
I have created two instances in AWS (one is Live & other is Backup). My website is hosted on Live Instance. what I want to do is, if Live instance Status check fails, then it should switch to Backup Instance. Is there any automated process to achieve the same?
Is not a good idea to keep one instance idle and pay for it. Put them under an Elastic Load Balancer and start using both of them. The ELB health check will automatically remove the instances that stop working. Then you can continue to monitor the number of healthy instances under your ELB with AWS Cloud Watch and setup an alert - to get an email when something happens or you can even autoscale
Liviu Costea's answer is the best way to go. If you insist on only keeping one active server at a time, and you are using Route53 for your DNS, then you can use Route 53 Health Checks to switch the domain name resolution from your primary server to your secondary server in the case that your primary server goes out of service.