PDF大到不能失败
拥抱失败，以免被失败吞噬。
Pat Helland、Simon Weaver 和 Ed Harris
网络规模计算意味着运行数十万台服务器。它需要与较小环境从根本上不同的方法。一致的服务器硬件和数据中心规划，以及一致且简单的配置至关重要。一切设计都旨在期望和拥抱失败，而无需人工干预。运维必须在很大程度上是自主的。软件必须假设崩溃。开发、测试和部署必须具有集成和自动化的解决方案。
本文简要概述了许多网络规模工作者熟知的技术，但这些技术常常让其他人感到惊讶。
网络规模基础设施意味着大量服务器协同工作——通常是成千上万台服务器朝着同一个目标努力。如何管理这些环境的复杂性？如何引入通用性和简洁性？
究竟什么是网络规模基础设施？
在网络规模数据中心中，为了实现统一且可互换的硬件资源，需要付出大量的努力。如果您可以只使用一种服务器，它具有相同的 CPU、相同的 DRAM、相同的存储和相同的网络容量，那么任何一台服务器都和下一台服务器一样好。当所有服务器都相同时，就只有一个备件池和一个可分配的资源。
您希望像对待一袋钉子一样对待您的硬件资源。任何单个钉子都无关紧要。重要的是用于建造房屋的有用钉子的总数。通常，您会买太多钉子，并期望有一定的故障率。当钉子弯曲或断裂时，您不会为此感到太情绪化。
同样，当数据中心中的服务器发生故障时，您也不能感到情绪化。这种情况一直都在发生。
多样性导致复杂性。复杂性导致不可预测性和网站可用性的降低。
大数定律可能是正确的
大数定律指出，单个组件可能不可靠，但总体的预期故障率是可预测的。虽然您无法知道掷一对骰子的确切结果，但您可以知道长期以来的预期概率。您投掷的次数越多，对平均值的信心就越强。
同样，在大型数据中心中，您运行的服务器越多，就越容易为预期的故障做计划。服务器组越大，就越有可能发生故障。图 1 显示了典型的服务器故障率。
重要的是可预测性，而不是可靠性。东西可能会坏……东西将会坏。在数万台服务器的情况下，每天都有很多东西坏掉！您只需要预测多久发生一次。
网络规模的硬件
典型的网络规模数据中心对硬件的看法与典型的 IT 部门不同。它们避免多样性，并尽可能坚持使用通用硬件。假设每件硬件都很有可能发生故障，并且运行在其上的软件需要在发生故障时成功工作。此外，不可阻挡的改进步伐意味着长期保留硬件并不划算。新硬件将以相同的电耗提供更多的“性价比”。
定制即巴洛克
当某物是定制的时，您会对其进行调整和修改，直到它完美为止。在某些环境中，系统和服务器的设计具有其自身的特殊配置。
巴洛克是一种建筑风格，具有许多华丽的细节和巨大的多样性。在大型环境中，定制变成了巴洛克式。各种类型服务器的个体细节变得令人难以承受。具有大量服务器类型的聚合系统充满了细节和复杂性。
克隆攻击
在典型的数据中心中，您选择一个标准服务器配置，并坚持每个人都使用相同的类型。就像亨利·福特的 T 型车一样，您可以选择任何颜色，只要它是黑色。
使用一个 SKU（库存单位）进行订购，您可以在购买服务器时获得对供应商的巨大杠杆。此外，该 SKU 只有一个备件池。
现在，也有一些例外情况。每家公司都在逐步引入一种新型服务器，同时逐步淘汰旧服务器。此外，拥有极少数特殊服务器也很常见——例如，用于计算负载的服务器和用于存储的服务器。
尽管如此，严格控制服务器类型的多样性至关重要。
数据中心硬件的短暂寿命
在数据中心中摆弄东西会引起问题。升级服务器可能会导致不一致。干脆别这样做！在维修时，您真正只想用相同的备件替换服务器，然后重新安装其软件。也许可以修复损坏的服务器并使其成为备件。
服务器和其他设备随着时间的推移提供的价值会降低。新服务器以相同的尺寸和相同的电力提供更多的计算和存储。电力成本的价值降低了。
数据中心硬件通常在三年后退役并丢弃（或退还给租赁方）。不值得保留。
几年后，数据中心服务器和烤牛肉的价值都大大降低了。
这意味着将新服务器快速投入生产存在很大压力。假设调试、激活和将数据加载到新服务器中需要两个月的时间。此外，可能需要一个月的时间来停用服务器并将数据从中取出。在总共三年的生命周期中，有三个月没有生产性地使用。服务器的生命周期是一个重要的财务问题。
网络规模的运维
网络规模的运维与较小规模的运维非常不同。进行人工操作是不切实际的。这导致了自主数据中心管理。
人是无法扩展的——即使不考虑皮肤病问题
假设您的运维人员每人可以管理 100 台服务器。这在 DevOps 环境中非常典型。每台服务器都需要关注以验证状态、处理故障和执行维修。通常，服务器有多种类型，您希望为每台服务器优化硬件。是否每个人都了解所有服务器类型？它们的不同运维任务是什么？
每人 100 台服务器的五万台服务器需要 500 名运维人员。随着规模的扩大，这种情况很快就会失控。
禅宗与数据中心维护艺术
为了支持网络规模的数据中心，我们不得不从 Ops 发展到 DevOps，再到 NoOps，如图 2 所示。从历史上看，在手动运维中，人们不仅决定做什么，而且还做了运维服务器所需的所有实际工作。DevOps 是向前迈出的一大步，因为它自动化了运维的繁重工作。尽管如此，当扩展到数万台服务器时，这仍然是不够的。在 NoOps 或自主管理系统中，工作流程和对运维任务的控制也实现了自动化。
网络规模的软件
软件必须通过无状态服务器池和旨在应对副本丢失的特殊存储服务器来拥抱失败。
无状态服务器和打地鼠
无状态服务器接受请求，可以从其他服务器读取数据，可以向其他服务器写入数据，然后返回结果。当无状态服务器死机时，必须重新启动其工作。无状态服务器的设计就是为了应对故障。
无状态服务器必须是幂等的。重新启动工作仍然必须给出正确的答案。了解幂等行为是大型系统的重要组成部分。幂等性并没有那么难！
通常，无状态服务器作为服务器池运行，其数量随着需求的波动而增加或减少。当一台服务器发生故障时，其兄弟服务器上的需求会增加，这很可能会导致替换服务器重新启动。就像街机游戏打地鼠一样，您一击中一个，另一个就会弹出来。
按需分配
对无状态服务的并发请求需要分配给服务器。跨服务器池的负载均衡请求很像喷洒工作。
当对服务器的请求花费的时间超出预期时，很可能是因为存在等待单个服务器的队列。如果您将工作分散到更多服务器上，则每个服务器的队列会更短。这将导致更快的响应。
向服务器池添加服务器通常会缩短请求的响应时间。删除服务器会回收资源。给定响应时间目标，这可以通过自动化机器人来完成。
避免创伤性服务器损伤导致的内存丢失
大多数分布式存储系统将每条数据保存在数据中心三个不同机架上的三台独立服务器上。选择三个副本是持久性目标、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（Google 文件系统）、1 HDFS（Hadoop 分布式文件系统）、3 微软 Bing 的 Cosmos 分布式文件系统2 和其他利用此技术的系统中得到尝试和验证。
大型数据中心需要考虑这种方法的两个基本方面。首先，软件驱动的机器人恢复对于高可用性至关重要。人工操作耗时太长，并且会被管理故障淹没。其次，集群越大，可能的存储服务器就越多。存储服务器越多，分布在集群周围的碎片就越小，恢复时间就越快。
网络规模的开发、测试和部署
大型网络环境中的开发和测试最适合与生产环境共享资源。成功开发、测试和部署软件带来了许多挑战。最重要的是，您几乎一直都在努力跟上不断变化的环境。
隔离病房
集中数据中心资源非常重要。将用于开发和测试的数据中心与生产数据中心分离可能很诱人，但这最终会造成问题。当需求和资源分离时，管理它们变得困难。也很难确保生产环境与开发/测试环境同步，并且您正在测试将在生产环境中运行的内容。
使用生产数据中心进行开发和测试意味着共享资源。您必须使用容器或 VM（虚拟机）隔离资源。您的客户将使用与您的测试人员相同的服务器，因此您必须隔离生产数据。一般来说，开发和测试人员不得访问客户数据，以遵守安全团队的要求。
虽然确保工作负载的安全隔离带来了许多挑战，但好处大于麻烦。您不需要用于开发/测试的专用数据中心，并且资源可以潮起潮落。
批准、发布、金丝雀和回滚
在大型环境中管理软件变更也存在复杂性。正式的批准、通过安全路径的发布、寻找问题的自动化监视器以及自动化回滚都是必不可少的。
正式批准涉及发布规则。将会有代码审查和自动化测试套件。官方批准通常至少涉及两个人。
发布到生产环境包括代码签名，其中创建加密签名以验证软件的完整性。该软件被发布到所需的服务器。有时，可能有数万个节点正在接收新版本。每个节点都被告知代码签名，并且它验证正确的位是否在那里。旧版本的软件将与新版本并排保留。
分配少量服务器作为金丝雀，它们将在所有其他服务器之前尝试新版本。就像带入地下矿井以检查有害气体的小鸟（金丝雀会在矿工之前因气体而死亡，然后矿工会赶紧逃到安全地带）一样，在软件发布中，自动化机器人首先尝试少量服务器，只有在成功时，才会推出更多服务器。
回滚是撤消新版本部署的自动化机制。每台服务器都保留旧版本的软件，并且可以在收到指示时弹回旧版本。
结论
运行大型数据中心需要在方法上进行一些根本性的改变。一切都必须更简单、自动化，并期望失败。
服务器和服务行为的简单模型
网络规模系统基于三个重要的前提运行
• 期望失败。任何组件都可能发生故障，系统会自动继续运行，无需人工干预。
• 最小的杠杆。底层系统为部署和回滚提供支持。当服务器出现问题时，最好杀死整个服务器，而不是处理部分故障。
• 软件控制。如果它不能通过软件控制，就不要让它发生。对所有内容使用版本控制，并使用人类可读的配置。
可靠性在于服务，而不是服务器！
拥抱失败，以免被失败吞噬！
运行数十万台服务器需要不同的方法。它需要一致的硬件（服务器和网络），并尽量减少多样性。数据中心必须具有简单且可预测的配置。它们必须拥抱失败，并根据需要自动将服务放置到硬件上。
运维必须从手动发展到自动化再到自主化。人应该设定目标并处理重大异常。系统完成其余工作。
软件必须通过无状态服务器池和旨在应对副本丢失的特殊存储服务器来拥抱失败。
集成的开发、测试和部署被深入构建到系统中，并具有受控和自动化的软件部署。
参考文献
1. Ghemawat, S., Gobioff, H., Leung, S.-T. 2003. The Google file system. Proceedings of the 19th Symposium on Operating Systems Principles: 29-43.
2. Ronnie Chaiken, Bob Jenkins, Per-Åke Larson, Bill Ramsey,
Darren Shakib, Simon Weaver, Jingren Zhou 2008. SCOPE: Easy and efficient parallel processing of massive data sets. Proceedings of VLDB 2008. http://www.vldb.org/pvldb/1/1454166.pdf
3. Shvachko, H., Kuang, H., Radia, S., Chansler, R. 2010. Hadoop Distributed File System. Proceedings of the IEEE 26th Symposium on Mass Storage Systems and Technologies: 1-10.
相关文章
从混乱中寻求秩序
Natalya Noy，斯坦福大学
本体论将帮助您构建半结构化数据吗？
https://queue.org.cn/detail.cfm?id=1103835
弹性工程：学习拥抱失败
与 Jesse Robbins、Kripa Krishnan、John Allspaw 和 Tom Limoncelli 的讨论
https://queue.org.cn/detail.cfm?id=2371297
Schema.org：Web 上结构化数据的演变
大数据使通用模式变得更加必要。
R.V. Guha、Dan Brickley 和 Steve Macbeth
https://queue.org.cn/detail.cfm?id=2857276
Pat Helland 自 1978 年以来一直从事事务系统、数据库、应用程序平台、分布式系统、容错系统和消息传递系统的实施工作。为了休闲，他偶尔会撰写技术论文。他目前在 Salesforce 工作。
Simon Weaver 18 年来一直致力于设计和构建分布式和自主系统，解决大数据、无人值守基础设施和人工智能领域的问题。Simon 目前在 Salesforce 工作。
Ed Harris 领导 Salesforce.com 的基础设施计算团队，为世界上最值得信赖的企业云构建计算、网络和存储基础。在 Salesforce 之前，Ed 在微软的 Bing 基础设施部门工作，从事 Cosmos 大数据服务。
版权 © 2017 由所有者/作者持有。出版权已许可给 。
最初发表于 Queue 第 15 卷，第 1 期—
在 数字图书馆 中评论本文
更多相关文章
Phil Vachon - 王国钥匙
一次不幸的手指误操作引发了当前的危机：客户意外删除了签署新固件更新所需的私钥。他们有一些令人兴奋的新功能要发布，以及通常的一系列可靠性改进。他们的客户越来越不耐烦，但当被问及发布日期时，我的客户不得不拖延。他们如何才能提出一个有意义的日期？他们已经失去了签署新固件版本的能力。
Peter Alvaro, Severine Tymon - 将天才从故障测试中解放出来
本文呼吁分布式系统研究社区改进容错测试的最新技术。普通用户需要工具来自动化选择定制的故障注入。我们推测，超级用户选择实验的过程可以通过软件有效地建模。本文描述了一个验证该推测的原型，介绍了实验室和现场的早期结果，并确定了可以使这一愿景成为现实的新研究方向。
Steve Chessin - 注入错误以获得乐趣和利润
一个不幸的事实是，任何带有运动部件的物体最终都会磨损和发生故障，电子电路也不例外。当然，在这种情况下，运动部件是电子。除了电迁移（运动的电子逐渐将金属原子推出位置，导致导线变细，从而增加其电阻并最终产生开路）和树枝状生长（相邻导线之间的电压差导致位移的金属原子相互迁移，就像磁铁会相互吸引一样，最终导致短路）的磨损机制之外，电子电路也容易受到背景辐射的影响。
Michael W. Shapiro - 现代操作系统中的自我修复
每天驾驶连接旧金山和门洛帕克的 101 公路，广告牌上的笑脸笑盈盈地向我保证，2004 年的计算机领域一切安好。他们告诉我，网络和服务器可以自我防御、自我诊断、自我修复，甚至在所有这些内省之后，还剩下足够的计算能力来执行其所有者分配的任务。
© 保留所有权利。