I am learning and setting up auoscale configuration for our production application. I want to know while setting scale-down which instance id to use. e.g. my configuration uses maximum number of instances as 3. I can put scale-up policy on instance id 1, but how can I put scale down policy for instance 2 and instance 3 which are still to be started.
PS: I understand for 2 instances, I can put policy on instance 1 and it will go down if load subsides.
you need to specify ami id for template ami only. all will be scaled up and down based on this single ami id. PLEASE NOTE: it is an ami id or image id that will be utilized and not an instance id.
The scale will be a range from 1 to 3 and will be configured in your autoscaling group with these tags: --min-size 1 --max-size 3 based on the metrics that you supply in the autoscaling policy.
With a minimum size of 1 instance, 1 instance will always be running. With a maximum size of 3 instances, 3 can run. There is not a need to scale non running instances.
Here is a complete tutorial:
http://www.cardinalpath.com/autoscaling-your-website-with-amazon-web-services-part-2/
Related
I have created a azure virtual machine scale set with two instances and also opted the Availability zone option ( selected all three available choices (1, 2,3). After the deployment of Scale set i am able to see two instances of virtual machines are created and visible in azure portal. Now I am confused to build my understanding and need help in below two questions -
1- If only two instances get created in this scenario then how they spread in three selected availability zones (1 , 2 & 3).
2- If same scale set with instances are getting created , how can i see other remaining 4 instances( as two are already visible) in the portal .
Q1. If only two instances get created in this scenario then how they spread in three selected availability zones (1, 2 & 3).
As I know, the availability zone is available for each instance. It means each instance is effectively distributed across three fault domains and three update domains when you select three zones. You use the CLI command to list all the instances to see which zone the instances in:
az vmss list-instances -g group_name -n vmss_name
Q2. If the same scale set with instances are getting created, how can I see other remaining 4 instances( as two are already visible) in the portal?
You cannot see the replicate of the instance in the portal, they are managed by the Azure platform. You also need not care about that.
I have a Terraform module that needs to depend on the resource aws_autoscaling_group ec2 "Instance State" and "Status Checks" (from the ec2 console) to go green before starting. How can this be done? Thanks.
In my understanding that's the default behavior of autoscaling_group. From the docs:
Terraform provides two mechanisms to help consistently manage ASG scale uptime across dependent resources.
The first is the default behavior. Terraform waits after ASG creation for min_size (or desired_capacity, if specified) healthy instances to show up in the ASG before continuing.
[...]
Terraform considers an instance "healthy" when the ASG reports HealthStatus: "Healthy" and LifecycleState: "InService"
Also, from the AWS docs:
When each instance is fully configured and passes the Amazon EC2 health checks, it is attached to the Auto Scaling group and it enters the InService state. The instance is counted against the desired capacity of the Auto Scaling group.
I am trying to get all the Amazon EC2 instances with some specific tags like environment and service in auto scaling group using the AWS CLI .
As of now I included only one tag. How can I include both the tags and I need the full information of ID like Availability zone, launch configuration, instances, name, etc.
How can I do that?
I am using query like:
aws autoscaling describe-auto-scaling-groups --query "AutoScalingGroups[? Tags[? (Key=='Environment') && Value=='staging']]".AutoScalingGroupName
Some of the information you seek (eg Launch Configuration) can be obtained from the Auto Scaling Group (using a command similar to what you provided above), while some of the information relates to the instances that are launched within the auto scaling group (eg Availability Zone).
Here is a command that will return information about instances in a specific Amazon EC2 auto scaling group (eg my-autoscaling-group):
aws ec2 describe-instances --filter Name=tag:aws:autoscaling:groupName,Values=my-autoscaling-group --query "Reservations[*].Instances[*].[InstanceId,Placement.AvailabilityZone,Tags[?Key=='Name']|[0].Value]"
I was wondering how GCP process the creation of an autoscaling group. Do they start with the minimum instances specified and evaluate the load and then adjust or the evaluate the load before launching the autoscaling group ?
max_replicas = 5
min_replicas = 2
I just want to know if the size at the creation is fixed
Thanks
You can do autoscaling on compute engine with 4 ways
When you choose an option that your needs and you can choose min and max instance number. The cluster will starting with your minimum VM settings. When your load increase than your cluster's VMs number will increase up to your max instance.
I have a brief and simple question i think.. in the emulator the role id changes in every run. What about in a real azure deployment? After a restart of the vm does the role gets the same id?
If you look at the id for the deployed instances in the cloud, you'll find that they are always named in this fasion: [RoleName]_IN_[XXX] where XXX is a number depending on the number of instances deployed. So to answer your question, since the pattern for naming the instance is the same, I would say you'll get the same id. It's a different question if the VM represented by that instance id would be the same. There're 3 scenarios to cover:
A role instance is rebooted: If you reboot a particular instance, my guess is you will get the same instance id.
A role instance goes down: Though we don't really have an option of killing a specific instance thus we can't really test it, if a particular instance goes down and Azure stands up a new instance for you for that instance you would get the same instance id.
New deployment: If you do a brand new deployment (assuming with the same number of instances), you'll get the same deployment ids but the VM will be entirely different.