Amazon EC2 Auto Scaling 如何工作?

发布于 2024-12-06 19:32:38 字数 290 浏览 1 评论 0原文

我想了解亚马逊如何实现自动缩放功能。我可以理解它是如何触发的,但我不知道自动缩放期间到底发生了什么。是如何扩展的。例如,

如果我将触发条件设置为cpu>90。一旦虚拟机的CPU使用率增加到90以上:

  1. 它是否有一个模板映像将被复制到新机器并启动?
  2. 开始处理新请求需要多长时间?
  3. 旧虚拟机会有停机时间吗?

据我所知,它能够在虚拟机之间提供负载平衡。但是,我找不到任何解释亚马逊自动扩展如何工作的链接/论文。如果您能为我提供一些相关信息,那就太好了。谢谢。

I am trying to understand how Amazon implements the auto scaling feature. I can understand how it is triggered but I don't know what exactly happens during the auto scaling. How does it expand. For instance,

If I set the triggering condition as cpu>90. Once the vm's cpu usage increases above 90:

  1. Does it have a template image which will be copied to the new machine and started?
  2. How long will it take to start servicing the new requests ?
  3. Will the old vm have any downtime ?

I understand that it has the capability to provide load balancing between the VMs. But, I cannot find any links/paper which explains how Amazon auto scaling works. It will be great if you can provide me some information regarding the same. Thank you.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

倚栏听风 2024-12-13 19:32:38

本质上,在设置中,您注册一个 AMI 和一组 EC2 启动参数 - 启动配置(实例大小、用户数据、安全组、区域、可用区等),您还可以设置扩展策略。

  1. 您的扩展触发器
  2. 会触发检查策略,以确定哪个启动配置
  3. 适用于使用注册的 AMI 和启动配置参数来调用 ec2 运行实例。

此时,一个实例已启动,它是 AMI 和启动配置的组合。它使用 IP 地址将自身注册到 AWS 环境中。

作为初始启动的一部分(由 ec2config 或 ec2run 完成 - 从内存中获取) - 新启动的实例可以连接到实例元数据并运行存储在“userdata”中的脚本。该脚本可以引导软件安装、操作系统配置、设置,以及您可以使用脚本执行的任何操作。

完成后,您将获得一个新创建的实例。

现在 - 如果此过程是通过自动缩放和弹性负载平衡启动的,则在实例“Windows 已准备就绪”时(检查 ec2config.log),负载均衡器会将实例添加到自身。一旦它响应请求,它将被标记为健康,并且 ELB 将开始路由流量。

黄金标准是拥有一个通用 AMI,并使用引导脚本将所有软件包/msi/gems 或您需要的任何内容安装到服务器上。但经常发生的情况是,人们构建一个黄金映像,并注册该 AMI 进行扩展。

后一种方法的缺点是每个版本都需要创建新的 AMI,并更新启动配置。

希望能为您提供更多信息。

Essentially, in the set up you register an AMI, and a set of EC2 start parameters - a launch configuration (Instance size, userdata, security group, region, availability zone etc) You also set up scaling policies.

  1. Your scaling trigger fires
  2. Policies are examined to determine which launch configuration pplies
  3. ec2 run instance is called with the registered AMI and the launch configuration parameters.

At this point, an instance is started which is a combination of the AMI and the launch configuration. It registers itself with an IP address into the AWS environment.

As part of the initial startup (done by ec2config or ec2run - going from memory here) - the newly starting instance can connect to instance meta data and run the script stored in "userdata". This script can bootstrap software installation, operating system configuration, settings, anything really that you can do with a script.

Once it's completed, you've got a newly created instance.

Now - if this process was kicked off by auto-scale and elastic-load-balancing, at the point that the instance is "Windows is ready" (Check ec2config.log), the load balancer will add the instance to itself. Once it's responding to requests, it will be marked healthy, and the ELB will start routing traffic.

The gold standard is to have a generic AMI, and use your bootstrap script to install all the packages / msi's / gems or whatever you need onto the server. But what often happens is that people build a golden image, and register that AMI for scaling.

The downside to the latter method is that every release requires a new AMI to be created, and the launch configurations to be updated.

Hope that gives you a bit more info.

薆情海 2024-12-13 19:32:38

阅读这篇文章,当我对这个主题进行一些研究时,它对我很有帮助。

http://www.codebelay.com/blog/2009/08/02/how-to-load-balance-and-auto-scale-with-amazons-ec2/

Have a read of this chaps blog, it helped me when I doing some research on the subject.

http://www.codebelay.com/blog/2009/08/02/how-to-load-balance-and-auto-scale-with-amazons-ec2/

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文