弹性伸缩

弹性伸缩, 是云计算中的一种常用方法，通过该方法，服务器池中的计算资源量（通常根据有效的服务器数量来衡量）会根据服务器池中的负载进行动态伸缩。 它与负载均衡紧密相关，并以此为基础。[1][2]

优势

弹性伸缩具有如下优点：

  • 对于服务运行在自建机房的公司，弹性伸缩通常意味着允许一些服务器在低负载时进入睡眠状态，从而节省电费（以及用于冷却机器的水费和水费）。[3]
  • 对于使用在托管在云上的机房的公司而言，自动扩展可能意味着更低的费用，因为大多数云提供商都基于总使用量而不是最大容量进行收费。[4]
  • 即使对于不能在任何给定时间减少运行或支付的总计算能力的公司，它们也可以在低流量时降低服务器的负载。[5]
  • 弹性伸缩解决方案（例如Amazon Web Services提供的解决方案）还可以用来替换异常状态的实例，从而在一定程度上防止硬件，网络和应用程序故障。[6]
  • 在生产工作负载经常变化且不可预测的情况下，弹性伸缩可以提供更长的正常运行时间和更高的可用性。

弹性伸缩与每天，每周或每年固定的服务器使用周期不同，它可以响应实际的使用模式，从而减少了因流量负载而配置的服务器太少或太多的潜在弊端。例如，如果流量通常在午夜时分较低，则静态伸缩方案可能会将某些服务器安排在夜间休眠，但这可能会导致在用户碰巧在夜间需要使用服务时（例如由于病毒性传播的新闻）出现宕机。与之相度的，弹性伸缩可以更好地应对预期外的流量高峰。[3][7]

术语

在下面的列表中，我们使用 亚马逊云计算服务 (AWS)提供的术语.[8] 但是我们会标注出术语的别名，并且不会使用特定于Amazon服务名称的术语。

名称(AWS 的名称[8])含义别名 (Google Cloud Platform,[9] Microsoft Azure,[10] 或其他平台)
实例属于服务器组的一部分的，用于弹性伸缩的单个服务器或计算机
弹性伸缩组具有自动伸缩功能的实例的集合以及所有相关的策略和状态信息托管实例组 (Google Cloud Platform)
尺寸当前属于弹性伸缩组的实例数
所需容量（或所需大小）弹性伸缩组在任何给定时间点应具有的实例数。 如果尺寸小于所需大小，则弹性伸缩组将尝试启动（设置和追加）新实例。 如果尺寸大于所需大小，则弹性伸缩组将尝试删除（分离并终止）实例
最小尺寸系统允许的实例数的最小值
最大尺寸系统允许伸缩的实例数最大值
测量指标与弹性伸缩组关联的度量（例如CPU利用率，内存使用，网络使用），会定期生成时间序列的数据点。可用于设置伸缩策略的指标阈值。指标可以是弹性伸缩组实例指标的汇总，也可以是和伸缩组关联的负载均衡的指标。
伸缩策略用于指定弹性伸缩组的所需容量（或其最小和最大值）的更改，以响应超过特定阈值的指标的策略。 扩容策略可以具有关联的冷却时间，这可以防止在特定扩容操作之后立即发生其他扩容操作。 对所需容量的更改可以是增量的（增加或减少一个特定的值），也可以指定所需容量的新值。 增加所需容量的策略称为“向外扩展”或“扩大”策略，而减少所需容量的策略称为“向外扩展”或“缩小”策略。
健康检查自动伸缩组确定与其连接的实例是否正常运行的一种方法。 运行状况检查可以基于实例是否仍然存在并且可访问，也可以基于实例是否仍在注册并在关联的负载均衡器中使用。
启动配置启动新实例时使用的参数和脚本的描述。 这包括实例类型，购买选项（例如，在AWS中为现货或按需购买），可能的启动可用区域，机器映像以及在启动时运行的脚本。实例模板 (Google Cloud Platform)
手工伸缩手动执行的伸缩操作。
按计划扩展在特定时间执行伸缩操作的策略。比如，每天执行，每月执行，没年执行。更多请查看 #Scheduled scaling

实践

亚马逊云服务 (AWS)
Auto-scaling

亚马逊云计算服务在 2006 年 8 月启动了 亚马逊弹性计算云 (EC2)， 来允许开发人员编程启动和结束实例（机器）。[11][12] 在最初启动时，AWS不提供自动缩放功能，但是通过编程方式创建和终止实例的能力使开发人员可以灵活地编写自己的代码以进行自动伸缩。

从 2008 年 4 月开始，AWS 的第三方弹性伸缩软件开始出现。 这其中包括 Scalr[13] 和 RightScale。RightScale 被 Animoto 使用，从而能应对 Facebook 的流量伸缩。[14][15]

2009年5月18日，作为Amazon Elastic Compute Cloud的一部分，Amazon 推出了自己的弹性伸缩功能以及 Elastic Load Balancing。[16] 现在，自动缩放是Amazon EC2产品不可或缺的组成部分。[2][17][18] Amazon Web Services 上的自动缩放是通过Web浏览器或命令行工具完成的。[19] 2016年5月，AWS ECS服务中也提供了自动伸缩功能。[20]

视频点播提供商Netflix记录了他们在Amazon Web Services中使用自动缩放功能来满足其高度可变的消费者需求的情况。 他们发现积极地扩大规模，延迟和谨慎地缩小规模最能实现其正常运行时间和响应能力的目标。[7]

在描述 TechCrunch 的文章中, Zev Laderman, Newvem（一个用来优化 AWS 云基础设施的服务） 的联合创始人， CEO 推荐说在项目起步阶段使用弹性伸缩是他们的花费保持在较低的水平。[4]

各种适用于AWS的最佳实践指南都建议即使在负载不变的情况下也要使用其自动缩放功能。 这是因为自动缩放具有另外两个优点：自动替换由于任何原因（例如硬件故障，网络故障或应用程序错误）而变得不正常的任何实例。 并且自动替换因价格或容量原因而中断的竞价型实例，这使得将竞价型实例用于生产目的更加可行。[6][21][22] Netflix的内部最佳实践要求每个实例都在一个弹性伸缩组中，并且其一致性猴子（Netflix 内部的测试工具）会终止不在自动伸缩组中的所有实例，以实施此最佳做法。[23]

微软的 Windows Azure

2013年6月27日， 微软 公布其 Windows Azure 云计算平台支持弹性伸缩功能。[24][25][26] 文档可参考 微软开发者网络.[10][27]

甲骨文云

Oracle Cloud Platform 允许服务器实例通过定义自动扩展规则自动收缩或扩展集群。[28] 这些顾泽主要利用 CPU 和内存的利用率来决定何时增加和删除节点。

谷歌云平台

2014年11月17日，Google Compute Engine 发布了贪生伸缩的 beta 版本试用功能。[29][30][31][32] As of March 2015, the autoscaling tool is still in Beta.[9]

Facebook

在2014年8月的博客文章中，一位Facebook工程师透露，该公司已开始使用自动缩放功能以降低能源成本。 博客文章报道了在低流量时间（午夜左右）能耗下降了27％，在典型的24小时周期内能耗下降了10-15％。[3][33]

Kubernetes 水平 Pod 伸缩器

Kubernetes Horizontal Pod Autoscaler 自动的调整 pods 在 replication controller 页面存档备份，存于, deployment 页面存档备份，存于 或 replicaset 页面存档备份，存于 中的数量。 调整主要基于对 CPU 的监控(其 beta 版也可以监控其他一些指标 application-provided metrics 页面存档备份，存于)[34]

可选的弹性伸缩决策方案

默认情况下，自动缩放使用``被动决策方法来处理流量缩放：缩放仅响应于度量标准的实时更改而发生，在某些情况下，特别是当更改发生得很快时，这种被动缩放方法是不够的。 下面介绍了另外两种自动缩放决策方法。

按计划扩展方案

这是一种自动缩放的方法，其中在一天的特定时间更改自动缩放组的最小大小，最大大小或所需容量。例如，如果已知流量负载在 一天中的特定时间，但是更改太突然了，以至于基于响应式方法的自动缩放无法足够快速地响应.AWS自动缩放组支持计划的缩放。[35]

预测性弹性伸缩

这种自动缩放方法使用predictive Analytics，其想法是将最近的使用趋势与历史使用数据以及其他类型的数据结合起来，以预测将来的使用情况，并根据这些预测进行自动缩放。

Netflix发现，对于部分基础架构和特定的工作负载，其预测分析引擎Scryer比Amazon的反应式自动缩放方法提供了更好的结果。它特别适合以下场景：[36][33]

  • 在不久的将来识别需求的巨大峰值，并提前一点准备好产能
  • 处理大规模中断，例如整个可用区和区域的故障
  • 处理可变的流量模式，根据一天中不同时间的典型需求水平和变化率，在横向扩展或纵向扩展速率上提供更大的灵活性

在2018年11月20日，AWS宣布将在其自动扩展产品中提供预测扩展功能。[37]

其他

参考链接
  1. (PDF). Berkeley EECS. February 10, 2009 [March 21, 2015]. （原始内容存档 (PDF)于2019-08-04）.
  2. . Amazon Web Services. [March 21, 2015]. （原始内容存档于2015-03-17）.
  3. Wu, Qiang. . Facebook Code Blog. August 8, 2014 [March 21, 2015]. （原始内容存档于2017-02-25）.
  4. Laderman, Zev. . TechCrunch. April 22, 2012 [March 21, 2015]. （原始内容存档于2019-09-25）.
  5. Park, Andrew; Denlinger, Darrell; Watson, Coburn. . Netflix. September 18, 2015 [December 16, 2016]. （原始内容存档于2017-05-01）.
  6. Wittig, Michael. . cloudonaut. December 26, 2015 [December 16, 2016]. （原始内容存档于2019-09-25）.
  7. Orzell, Greg; Becker, Justin. . Netflix Tech Blog. January 18, 2012 [March 21, 2012]. （原始内容存档于2017-03-09）.
  8. . Amazon Web Services. [December 16, 2016]. （原始内容存档于2017-12-27）.
  9. . Google Cloud Platform. [March 21, 2015]. （原始内容存档于2019-09-12）.
  10. . Microsoft Developer Network. [2019-09-25]. （原始内容存档于2017-02-11）.
  11. Cubrilovic, Nik. . TechCrunch. August 24, 2006 [December 4, 2016]. （原始内容存档于2019-09-25）.
  12. Barr, Jeff. . Amazon Web Services Blog. August 25, 2006 [May 31, 2013]. （原始内容存档于2018-12-25）.
  13. Work, Henry. . TechCrunch. April 3, 2008 [March 21, 2015]. （原始内容存档于2015-03-22）.
  14. Howlett, Dennis. . ZDNet. June 25, 2008 [December 16, 2016]. （原始内容存档于2016-12-20）.
  15. von Eicken, Thorsten. . April 23, 2008 [December 16, 2016]. （原始内容存档于2016-12-20）.
  16. Barr, Jeff. . Amazon Web Services. May 18, 2009 [June 15, 2016]. （原始内容存档于2019-09-25）.
  17. . TechTarget. [March 21, 2015]. （原始内容存档于2019-04-29）.
  18. Barr, Jeff. . Amazon Web Services (official blog). July 30, 2014 [March 21, 2015]. （原始内容存档于2019-09-25）.
  19. . Amazon Web Services (community-edited page). [March 21, 2015]. （原始内容存档于2016-10-05）.
  20. . [2019-09-25]. （原始内容存档于2019-09-25）.
  21. Adams, Rich. . February 3, 2014 [December 16, 2016]. （原始内容存档于2019-05-25）.
  22. . wikiHow. [December 16, 2016]. （原始内容存档于2019-09-25）.
  23. . Netflix. July 19, 2011 [December 5, 2016]. （原始内容存档于2017-03-20）.
  24. Lardinois, Frederic. . TechCrunch. June 27, 2013 [March 21, 2015]. （原始内容存档于2019-09-25）.
  25. . ZDNet. June 27, 2013 [March 21, 2015]. （原始内容存档于2016-12-20）.
  26. Butler, Brandon. . Network World. August 7, 2013 [March 21, 2015]. （原始内容存档于2018-05-18）.
  27. . Microsoft Developer Network. [March 21, 2015]. （原始内容存档于2017-12-14）.
  28. . Oracle Help Center. [2018-05-16]. （原始内容存档于2018-05-16） （美国英语）.
  29. Balejko, Filip. . Google Cloud Platform blog. November 17, 2014 [March 21, 2015]. （原始内容存档于2016-03-05）.
  30. Protalinski, Emil. . VentureBeat. November 17, 2014 [March 21, 2015]. （原始内容存档于2019-09-25）.
  31. Lardinois, Frederic. . TechCrunch. November 17, 2014 [March 21, 2015]. （原始内容存档于2019-09-25）.
  32. Verge, Jason. . Data Center Knowledge. November 17, 2014 [March 21, 2015]. （原始内容存档于2019-09-25）.
  33. . Morpheus. November 2, 2016 [December 16, 2016]. （原始内容存档于2019-09-25）.
  34. . [June 21, 2018]. （原始内容存档于2019-09-22） （美国英语）.
  35. . Amazon Web Services. [December 16, 2016]. （原始内容存档于2017-12-24）.
  36. Jacobson, Daniel; Yuan, Danny; Joshi, Neeraj. . The Netflix Tech Blog. Netflix. [28 May 2015]. （原始内容存档于2017-04-29）.
  37. Barr, Jeff. . Amazon Web Services. November 20, 2018 [November 23, 2018]. （原始内容存档于2019-10-18）.
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.