ACM通信
实践
太大而不能倒
信贷:Xcages
网络规模的计算意味着运行数十万台服务器。它需要一种与小型环境完全不同的方法。一致的服务器硬件和数据中心计划以及一致和简单的配置是必不可少的。一切都被设计成在没有人为干预的情况下预期并接受失败。运营必须在很大程度上实现自主。软件必须承担崩溃的风险。开发、测试和部署必须具有集成的和自动化的解决方案。
本文简要介绍了许多在Web规模上工作的人非常熟悉的技术，但却经常让其他人感到惊讶。
网络规模的基础设施意味着很多在一起工作的服务器通常是数万或数十万台服务器都朝着同一个目标工作。如何管理这些环境的复杂性?如何引入通用性和简洁性?
为了在web规模的数据中心中实现统一和可替换的硬件资源，需要付出大量的努力。如果只有一种服务器具有相同的CPU、相同的DRAM、相同的存储和相同的网络容量，那么任何服务器都与下一个服务器一样好。当所有服务器都相同时，只有一个备用池和一个资源要分配。
您希望像对待一袋钉子一样对待硬件资源。任何一颗钉子都无关紧要。有用的钉子的总数量使房子得以建造。通常情况下，你买了太多的钉子，预期一定的失败率。当钉子弯曲或折断时，你不要太情绪化。
类似地，当数据中心的服务器崩溃时，您不能激动。这种事经常发生。
多样性导致复杂性。复杂性导致不可预测性和缺乏网站可用性。
大数定律可能是正确的。根据大数定律，单个部件可能不可靠，但总体预期失败率是可以预测的。虽然您无法知道掷一对骰子的确切结果，但您可以知道随着时间的推移的预期速率。投掷次数越多，对平均值的信心就越强。
类似地，在大型数据中心中，运行的服务器越多，就越容易为预期的故障做计划。服务器的集合越大，就越有可能出现故障。图1显示典型的服务器故障率。
重要的是可预测性，而不是可靠性。事情可能会失败……的东西将失败。成千上万的服务器，每天都有很多东西失败!你只需要预测一下频率。
Web规模的硬件
典型的web规模的数据中心对硬件的考虑与典型的IT商店不同。他们避免多样性，尽可能多地坚持使用通用的硬件。假设每一块硬件都可能发生故障，而在发生故障时，运行在其上的软件需要成功工作。此外，不可阻挡的改进速度意味着将硬件保留太长时间是不划算的。这种新材料将提供更“物超所值”和更低的耗电量。
定制是巴洛克风格。当某事是定制在美国，你不断调整和修改它，直到它变得完美。在某些环境中，系统和服务器使用自己的特殊配置进行设计。
巴洛克式的是一种建筑风格，有很多华丽的细节和巨大的变化。在大规模的环境中，定制成为巴洛克风格。各种类型的服务器的各个细节变得铺天盖地。具有大量服务器类型的聚合系统充满了细节和复杂性。
克隆人的攻击。在典型的数据中心中，您选择一个标准的服务器配置，并坚持每个人都使用相同的类型。就像亨利·福特的T型车一样，你可以选择任何你喜欢的颜色，只要它是黑色的。
通过订购一个SKU(库存单位)，您可以在购买服务器时获得与供应商的巨大影响力。此外，该SKU还有一个备用池。
现在，也有一些例外。每家公司都在逐步引进新的服务器类型，同时淘汰旧的服务器类型。此外，通常只有很少的特殊服务器，例如一个用于计算负载，一个用于存储。
不过，严格控制服务器类型的多样性是必要的。
数据中心硬件寿命短。搅乱数据中心中的东西会导致问题。升级服务器可能会导致不一致。千万别这么做!在进行修复时，您实际上只想用相同的备用服务器替换服务器，然后重新安装它的软件。也许坏掉的服务器可以修复，成为备用服务器。
随着时间的推移，服务器和其他设备提供的价值越来越小。新的服务器在相同的外形和相同的电量下提供了更多的计算和存储。电力成本的价值减少了。
数据中心的硬件通常在三年后退役和废弃(或归还给它的出租人)。它不值得保留。
数据中心服务器和烤牛肉几年后就会贬值很多。
这意味着将新服务器快速投入生产的压力很大。假设调试、激活并将数据加载到新服务器需要两个月的时间。此外，可能需要一个月的时间才能使服务器退役并从中获取数据。这是三年生命中没有有效利用的三个月。服务器的生命周期是一个很大的财务问题。
Web规模的操作
Web规模的操作与较小规模的操作非常不同。动手是不实际的。这导致了自主数据中心管理。
尽管如此，人们还是不会在意皮肤问题。假设你的运营人员每个人可以管理100台服务器。这在DevOps环境中非常典型。每个服务器都需要注意验证状态、处理故障和执行修复。通常情况下，服务器有多种风格，您希望优化每个服务器的硬件。每个人都了解所有的服务器类型吗?它们的不同操作任务是什么?
典型的web规模的数据中心对硬件的考虑与典型的IT商店不同。他们避免多样性，尽可能多地坚持使用通用的硬件。
在每人100台服务器的情况下，大约5万台服务器需要500名操作员。随着规模的扩大，这种情况很快就会失控。
禅宗和数据中心维护的艺术。为了支持web规模的数据中心，我们必须从Ops发展到DevOps再到NoOps，详见图2．在历史上，通过手动操作，人们不仅决定要做什么，而且还要做操作服务器所需的所有实际工作。DevOps是一个巨大的进步，因为它自动化了繁琐的操作工作。但是，当扩展到成千上万的服务器时，这是不够的。在NoOps或自主管理的系统中，对操作任务的工作流和控制也是自动化的。
Web规模的软件
软件必须使用无状态服务器池和专门设计用于处理副本丢失的特殊存储服务器来处理故障。
无状态服务器和打地鼠。无状态服务器接受请求，可以从其他服务器读取数据，也可以将数据写入其他服务器，然后返回结果。当无状态服务器死亡时，它的工作必须重新启动。无状态服务器是为失败而设计的。
无状态服务器必须是幂等的。重新启动工作仍然必须给出正确的答案。学习幂等行为是大型系统的基本组成部分。幂等幂并没有那么难!
通常，无状态服务器作为服务器池运行，其数量随着需求的波动而增加或减少。当一个服务器出现故障时，对其兄弟服务器的需求会增加，这可能会导致一个替换服务器重新运行。就像打地鼠游戏一样，只要你击中一个，另一个就会跳出来。
按需分配。无状态服务的并发请求需要分配给服务器。跨服务器池的负载平衡请求非常类似于工作喷涂。
当对服务器的请求花费的时间比预期的长时，很可能是因为有一个队列在等待各个服务器。如果要在更多的服务器上分配工作，那么每个服务器的队列就会更短。这将导致更快的响应。
向服务器池中添加服务器通常会降低请求的响应时间。移除服务器可以回收资源。给定一个响应时间目标，这可以由自动机器人完成。
避免外伤性服务器损伤造成的记忆丧失。大多数分布式存储系统将每个数据块保存在数据中心的三个独立机架的三个独立服务器上。三个副本的选择是耐久性目标MTBF(平均故障间隔时间)和MTTR(平均修复时间)的函数。
可用性= MTBF / (MTBF + MTTR)
因为我们假设每年有五分之一的服务器发生故障，所以我们的MTBF(平均故障间隔时间)相对较短。为了提高可用性，我们要么需要较长的MTBF，要么需要较短的MTTR(平均修复时间)。通过缩短MTTR，我们可以显著提高可用性和数据持久性。
假设每个服务器中包含的数据被切割成多个片段，每个片段在许多不同的服务器上都有附加的副本，如图3．例如，服务器- a上的数据被切割成100个片段。每个片段在不同的服务器上都有它的第二和第三副本，除了服务器- a之外，总数可能多达200个。如果服务器a出现故障，其他100个辅助服务器将尝试在另外100个服务器上寻找新位置。在极限情况下，这种并行可以使MTTR降低100倍。
注意,在图3服务器b (S9、S2、S4、S8和S5)中的每个数据槽在不同的服务器上有两个其他副本。如果服务器b发生故障，则将这些槽位中的每一个复制到新的第三个服务器上。新的第三个副本的放置保留了每个副本位于独立服务器中的保证。
这种方法在GFS(谷歌文件系统)中得到了验证，2HDFS (Hadoop分布式文件系统)3.微软必应的Cosmos分布式文件系统，1以及其他利用这种技术的人。
大型数据中心需要考虑这种方法的两个基本方面。首先，软件驱动的机器人恢复对于高可用性至关重要。人类花费的时间太长，会被处理失败所淹没。其次，集群越大，存储服务器可能就越多。存储服务器越多，集群周围的碎片就越小，恢复时间就越快。
Web规模的开发、测试和部署
大型Web环境中的开发和测试最适合与生产部门共享资源。成功地开发、测试和部署软件带来了许多挑战。最重要的是，你要不断地工作以跟上环境的变化。
隔离病房。集中数据中心的资源很重要。将用于开发和测试的数据中心从生产中分离出来可能很诱人，但这最终会产生问题。当需求和资源分开时，管理它们是困难的。同样，很难确保生产与开发/测试同步，也很难确保您正在测试将在生产中运行的内容。
使用生产数据中心进行开发和测试意味着共享资源。必须使用容器或虚拟机(vm)分隔资源。您的客户将使用与您的测试人员相同的服务器，因此您必须隔离生产数据。通常，开发和测试人员不能访问客户数据，以遵守安全团队的要求。
虽然确保工作负载的安全隔离带来了许多挑战，但好处大于麻烦。您不需要专门的数据中心来进行开发/测试，资源可能会波动。
签名、推出、金丝雀和回滚。在大规模环境中，软件变更的管理也很复杂。正式的批准、通过安全路径的推出、寻找问题的自动化监督人员以及自动回滚都是必不可少的。
正式的批准涉及发布规则。将有代码评审和自动化测试套件。正式签字通常至少需要两个人。
推出生产包括代码签名，通过创建一个加密签名来验证软件的完整性。软件被发布到所需的服务器上。有时，成千上万的节点可能正在接收新版本。每个节点都被告知代码签名，并验证是否存在正确的位。该软件的旧版本将与新版本并排保存。
有几台服务器被指定为金丝雀他们会先尝试新版本。就像被带到地下矿井检查危险气体的小鸟(金丝雀会先于矿工们死于气体，矿工们会逃到安全的地方)，在软件发布中，自动机器人会先尝试几台服务器，成功后才会推出更多服务器。
回滚是撤销新版本部署的自动机制。每个服务器都保留软件的旧版本，并可以在收到指令时弹出回旧版本。
结论
运行大型数据中心需要在方法上进行一些根本性的改变。一切都必须变得更简单，自动化，并做好失败的准备。
服务器和服务行为的简单模型。网络规模的系统有三个重要前提:
- 预计失败。任何组件都可能发生故障，系统自动继续运行，无需人工干预。
- 最小的杠杆。底层系统提供对部署和回滚的支持。当服务器出现问题时，最好关闭整个服务器，而不是处理部分故障。
- 软件控制。如果软件无法控制，就不要让它发生。对所有具有人类可读配置的内容使用版本控制。
可靠性在于服务，而不是服务器!
拥抱失败，这样它就不会拥抱你。运行数十万台服务器需要一种不同的方法。它需要一致的硬件(服务器和网络)和最小的多样性。数据中心必须具有简单和可预测的配置。他们必须接受失败，并根据需要自动将服务放到硬件上。
操作必须从手动到自动化再到自动。人类应该设定目标并处理主要的异常。其余的工作由系统完成。
软件必须使用无状态服务器池和专门设计用于处理副本丢失的特殊存储服务器来处理故障。
集成开发、测试和部署通过软件的受控和自动化部署深入构建到系统中。
相关文章
在queue.acm.org
混乱中的秩序
娜塔纳
http://queue.acm.org/detail.cfm7icN1103835
与Jesse Robbins, Kripa Krishnan, John Allspaw和Tom Limoncelli的讨论
http://queue.acm.org/detail.cfm?id=2371297
Schema.org: Web上结构化数据的发展
r·v·古哈，丹·布里克利，史蒂夫·麦克白
http://queue.acm.org/detail.cfm?id=2857276
参考文献
1.柴肯，R，詹金斯，R，拉森，P-A。Ramsey, B, Shakib, D, Weaver, S, Zhou, J.范围:简单高效的海量数据集并行处理。在ACM VLDB论文集, 2008;http://www.vldb.org/pvldb/1/1454166.pdf
2.格玛沃特，S，戈比奥夫，h和梁，S - t。谷歌文件系统。在十九届会议记录thACM操作系统原理研讨会， 2003, 2943。
3.Shvachko, H.， Kuang, H.， Radia, S.， Chansler, R. Hadoop分布式文件系统。在IEEE 26论文集th大容量存储系统与技术研讨会， 2010, 110。
数字图书馆是由计算机协会出版的。版权所有©2017 ACM, Inc.
没有找到条目