Shulou(Shulou.com)06/01 Report--

In this issue, the editor will bring you about how AWS configures AutoScaling to achieve highly available flexible computing services. The article is rich in content and analyzes and describes it from a professional point of view. I hope you can get something after reading this article.

A priori knowledge

AWS is Amazon's cloud computing platform.

EC2 is a CVM provided by AWS, which generally uses a CentOS-based Amazon Linux system, just like most CVMs.

ELB is a load balancer service provided by AWS. You can forward the request to an EC2 instance in the target group. It will also check the health of the target group instance, and only forward the request to the healthy instance.

target

The AWS AutoScaling service allows us to set AutoScaling groups (ASG). ASG maintains a set of EC2 instances, and EC2 instances can be distributed in different availability zones to ensure availability. AutoScaling can check the health status of instances, automatically replace unhealthy instances, increase or decrease the number of instances needed according to specific rules, and trigger events to call other services when starting or destroying EC2 instances. AutoScaling service can be used in conjunction with ELB elastic load balancer service. The instance does not need public network IP, and the instance will automatically join the target group of ELB after startup, and wait for the ELB connection to be exhausted before terminating the instance.

The structure we are going to implement is shown in the figure:

It looks like a dream, but it's not so comfortable to use.

Create a startup configuration for EC2 for ASG

We need to provide ASG with startup configuration (Launch Configuration). The startup configuration specifies a series of information such as EC2 instance type, AMI image, storage device, IAM role, SSH Key, user data (User Data), and so on, to start a new instance.

We are mainly concerned with IAM roles and startup scripts, and other on-demand configurations.

User data is actually a startup script that executes user data as a script as root at the end of initialization when the EC2 instance is started. You can log in to the instance and view its output at the end of the / var/log/cloud-init-output.log log.

Because every time you modify the startup configuration, you need to recreate the ASG, and it is very cumbersome to clear the instance, so it is best to set the user data to get the real startup script from the outside to run, so that you can modify and debug:

#! / usr/bin/env bashaws S3 cp s3://bucket/key / tmp/myscript.sh & & chmod + x / tmp/myscript.sh & & / tmp/myscript.sh

This requires granting S3 access to the IAM role of EC2.

Create ASG

We create an ASG according to the startup configuration, set the minimum, maximum and required number of instances, connect the instances to a specific ELB target group, take the health check of ELB as the health basis of the instances in ASG, and so on.

Unhealthy instances will be terminated after the health check fails and the wait times out. For more information, please see the health check of the instance in ASG.

Lifecycle of instances in ASG

Instances in ASG have the concept of life cycle, that is, instances have a state and transfer between different states.

The lifecycle of the instance in ASG is shown in the figure:

Life cycle hook

Hooks can be added to both the initiated Pending state and the terminated Terminating state. The hook triggers the event and waits for the event to complete before moving to the next state (when there is no hook, the instance automatically jumps to the next state). The hook can set the timeout time limit and the timeout result.

You can use things like aws-cli or AWS SDK to proactively complete a lifecycle event or postpone it. Event completion needs to provide results, and both proactive completion and timeout have two options: "continue" and "abandon".

Multiple hooks can be added to the startup or termination phase, and they will be executed in turn after the previous hook completes and the result is "continue". Once the result of "abandon" occurs in the startup phase, the instance will skip other hooks and start the termination process directly, which will also trigger the hook of the termination phase; after the result of "abandonment" occurs in the termination phase, the instance will skip other hooks and terminate directly.

Add a hook

Using the aws autoscaling put-lifecycle-hook command to add trenches, there are two optional transition values:

When an autoscaling:EC2_INSTANCE_LAUNCHING instance is started

When an autoscaling:EC2_INSTANCE_TERMINATING instance is terminated

The following example of the command demonstrates adding a "hook at startup, timeout period of 600s, and discard the instance after timeout":

Aws autoscaling put-lifecycle-hook\-auto-scaling-group-name ${ASG}\-lifecycle-hook-name ${HOOK}\-lifecycle-transition "autoscaling:EC2_INSTANCE_LAUNCHING"\-- heartbeat-timeout 600\-default-result "ABANDON"

If you use the SNS or SQS below to receive events, you also need to provide role-arn and notification-target-arn. AWS provides more complete documentation to add lifecycle hooks to describe this process.

Report event completion or postponement

Use the aws autoscaling complete-lifecycle-action command to proactively complete the event to continue the life cycle (CONTINUE) or abandon (ABANDON). Based on the information you get, you can provide either instance-id or lifecycle-action-token:

The following example of the command demonstrates "completing the ${HOOK} event on the instance of the ${ASG} group ${INSTANCE_ID}, and the result is to continue":

Aws autoscaling complete-lifecycle-action\-auto-scaling-group-name ${ASG}\-lifecycle-hook-name ${HOOK}\-instance-id ${INSTANCE_ID}\-lifecycle-action-result CONTINUE

The command aws autoscaling record-lifecycle-action-heartbeat resets the timeout, using a method similar to complete-lifecycle-action described above.

Note that if you want a script on top of EC2 to do the above, you need to allow autoscaling:CompleteLifecycleAction or autoscaling:RecordLifecycleActionHeartbeat permissions to the IAM role of EC2.

How does an EC2 instance get its own instance-id?

INSTANCE_ID=$ (curl-s http://169.254.169.254/latest/meta-data/instance-id)ASG=$(aws autoscaling describe-auto-scaling-instances-- output text-- query 'AutoScalingInstances [? InstanceId== `' ${INSTANCE_ID}'`] .AutoScalingGroupName')

For more information, please see the command output for retrieving instance metadata and controlling aws-cli.

The spread of the Hook event

AWS allows this event to be propagated outward after the hook is triggered, in three ways-through CloudWatch Events, SNS, or SQS. They will carry enough information. For more information, please refer to the AutoScaling event.

If you have any questions about the specific configuration, please refer to the first two steps in the add Lifecycle Hook section "adding Lifecycle hooks to the Auto Scaling Group".

After the event is propagated, it is usually handled using Amazon Lambda or an additional server. Also note that if you want Lambda to report that the event is completed or deferred, allow the appropriate permissions to the IAM role of Lambda.

A lot of times we need to execute scripts on EC2 instances, which can be found in this blog. AWS uses Simple System Manager to send commands to EC2 to execute scripts remotely.

Personal experience in event handling

When an instance is started, we usually do not propagate the event to Lambda for processing. Instead, the startup script in the user's data reports the completion of the event (to continue) after execution, or notifies SQS, SNS, Lambda, etc.

Because we need to install SSM Agent manually when the instance is started, the service is not available to the outside world. So we can't communicate with EC2 in this way.

When the instance is terminated, we usually use Lambda processing, and use SSM to notify EC2 to execute the recycling script. The recycling script reports event completion (continuation) by itself. If SSM fails, Lambda reports event completion (abandonment).

Expand the size of ASG

AWS provides a variety of strategies for expanding the size of ASG.

Here we provide two simple manual strategies to expand the size of ASG:

Aws autoscaling put-scaling-policy\-- auto-scaling-group-name ${ASG}\-- policy-name "inc"\-- policy-type "SimpleScaling"\-- adjustment-type "ChangeInCapacity"\-- scaling-adjustment 1aws autoscaling put-scaling-policy\-- auto-scaling-group-name ${ASG}\-policy-name "dec"\-- policy-type "SimpleScaling"\- -adjustment-type "ChangeInCapacity"\-- scaling-adjustment-1

Now that we have a highly available elastic computing service, the configuration process is complex, and it is best to configure it in CloudFormation or script it in aws-cli.

This is how to configure AutoScaling to achieve highly available elastic computing services in AWS shared by the editor. If you happen to have similar doubts, please refer to the above analysis. If you want to know more about it, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.