2014年7月23日
第12卷，第7期

网络是可靠的

真实世界通信故障的非正式调查

Peter Bailis，加州大学伯克利分校
Kyle Kingsbury，Jepsen Networks

“网络是可靠的”位居 Peter Deutsch 的经典列表“分布式计算的八个谬论”之首 (https://blogs.oracle.com/jag/resource/Fallacies.html)，“所有这些[谬论]从长远来看都被证明是错误的，并且所有这些[谬论]都会引起大麻烦和痛苦的学习经历。” 考虑和理解网络行为的影响是设计健壮的分布式程序的关键——事实上，Deutsch 的八个“谬论”中有六个直接涉及到网络通信的局限性。这应该不足为奇：通过共享通道进行通信的能力（通常是要求）是分布式程序的定义特征，并且该领域中的许多关键结果都与在特定网络条件下执行分布式计算的可能性和不可能性有关。

例如，著名的 FLP 不可能性结果⁹ 证明了在异步网络（即，面临进程之间无限期通信分区的网络）中，如果有一个故障进程，则无法保证达成共识。这意味着，在消息传递不可靠（不及时）的情况下，诸如修改集群中的机器集合（即，维护组成员关系，就像 Zookeeper 等系统如今的任务一样）等基本操作无法保证在网络异步和单个服务器故障的情况下完成。相关结果描述了在不利条件下无法保证可序列化事务、⁷ 可线性化读/写¹¹ 以及各种有用的、程序员友好的保证的进度。³ 这些结果的含义不仅仅是学术性的：这些不可能性结果促使了大量系统和设计涌现，在发生网络故障时提供一系列替代保证。⁵ 然而，在更友好、更可靠的网络中，该网络保证及时的消息传递，FLP 和许多相关结果不再成立：⁸ 通过对网络行为做出更强的保证，我们可以规避这些不可能性证明的可编程性影响。

因此，部署环境中的可靠性程度对于健壮的系统设计至关重要，并直接决定了系统可以在无需等待的情况下可靠执行的操作类型。不幸的是，现实世界中网络实际可靠的程度是一个相当程度且不断发展的争论的主题。有些人声称网络是可靠的（或者分区在实践中足够罕见），我们过于担心为理论上的故障模式进行设计。相反，其他人证明分区确实发生在他们的部署中，并且，正如 AWS（亚马逊网络服务）的 James Hamilton 简洁地总结的那样 (http://perspectives.mvdirona.com/2010/04/07/StonebrakerOnCAPTheoremAndDatabases.aspx)，“网络分区应该很少见，但网络设备仍然比它应该引起的更多问题。” 那么谁是对的呢？

这场讨论中的一个关键挑战是缺乏证据。我们几乎没有用于比较网络和应用程序可靠性的标准化基础——甚至更少的数据。我们可以跟踪链路可用性并估计数据包丢失，但理解对应用程序的端到端影响更加困难。我们拥有的少量证据很难概括：它通常是特定于部署的，并且与特定的供应商、拓扑和应用程序设计紧密相关。更糟糕的是，即使组织对其网络的行为有清晰的了解，他们也很少分享细节。最后，分布式系统旨在抵抗故障，这意味着明显的中断通常取决于故障模式的复杂交互。许多应用程序在网络发生故障时会静默降级，并且由此产生的问题可能在一段时间后，甚至永远不会被理解。

因此，我们对真实世界分布式系统的故障模式的许多信念都建立在猜测和谣言之上。系统管理员和开发人员会在啤酒中交换故事，但详细的、公开的事后分析和全面的网络可用性调查却很少。在本文中，我们想非正式地将其中一些故事（在大多数情况下，这些故事都是毫不掩饰的轶事）汇集在一起。我们的重点是尽可能描述实际的网络行为，并且（更常见的是），当不可能时，重点是网络故障和异步性对真实世界系统部署的影响。我们相信这是朝着更开放和诚实的讨论真实世界分区行为迈出的第一步，并最终朝着更健壮的分布式系统设计迈进。

来自大型部署的传闻

首先，让我们考虑来自分布式系统大型参与者的证据：运营全球分布式基础设施且拥有数十万台服务器的公司。这些报告或许最能概括大规模运营，提炼了运营可能是部署过的最大分布式系统的经验。这些公司的出版物（与我们稍后将要考察的许多报告不同）通常捕捉到聚合的系统行为和大规模的统计趋势，并（通常是委婉地）表明分区是他们部署中关注的问题。

微软数据中心研究

多伦多大学和微软研究院的一个团队研究了微软几个数据中心中网络故障的行为。¹² 他们发现平均每天的故障率为 5.2 个设备和 40.8 个链路，平均修复时间约为五分钟（最长为一周）。虽然研究人员指出，将链路故障和通信分区关联起来具有挑战性，但他们估计每次故障的中位数数据包丢失为 59,000 个数据包。也许更令人担忧的是他们的发现，即网络冗余仅将中位数流量提高了 43%——也就是说，网络冗余并不能消除网络故障的常见原因。

惠普企业托管网络

加州大学圣地亚哥分校和惠普实验室的研究人员进行的一项联合研究通过分析支持票据数据 (http://www.hpl.hp.com/techreports/2012/HPL-2012-101.pdf) 检查了惠普托管网络中网络故障的原因和严重程度。 “连接”相关票据占支持票据的 11.4%（其中 14% 为最高优先级），最高优先级票据的中位数事件持续时间为 2 小时 45 分钟，所有票据的中位数持续时间为 4 小时 18 分钟。

谷歌 Chubby

谷歌关于 Chubby（其分布式锁管理器）的设计和操作的论文 (http://research.google.com/archive/chubby-osdi06.pdf) 概述了在多个集群的 700 天运行期间发生的 61 次中断的根本原因。在超过 30 秒的九次中断中，四次是由网络维护引起的，两次是由“疑似网络连接问题”引起的。

谷歌分布式系统设计经验

在“构建大规模分布式系统的设计经验和建议”中 (http://www.cs.cornell.edu/projects/ladis2009/talks/dean-keynote-ladis2009.pdf)，谷歌研究员 Jeff Dean 建议，一个新的谷歌集群的典型第一年包括

• 五个机架出现问题（40-80 台机器出现 50% 的数据包丢失）。

• 八次网络维护事件（其中四次可能导致约 30 分钟的随机连接丢失）。

• 三次路由器故障（导致需要立即拉取流量一小时）。

虽然谷歌没有告诉我们太多关于其网络分区的应用程序级后果，但 Dean 表示他们很关注这些后果，并引用了创建“用于解决对一块状态的多个版本进行冲突更新的易于使用的抽象”的长期挑战，这对于“在修复网络分区后协调不同数据中心中的复制状态”非常有用。

亚马逊 Dynamo

亚马逊的 Dynamo 论文 (http://www.allthingsdistributed.com/files/amazon-dynamo-sosp2007.pdf) 经常引用分区事件作为关键的设计考虑因素。具体而言，作者指出，他们拒绝了“传统复制关系数据库系统”的设计，因为它们“无法处理网络分区”。

雅虎! PNUTS/Sherpa

雅虎! PNUTS/Sherpa 被设计为在地理位置不同的数据中心运行的分布式数据库。最初，PNUTS 支持强一致性的“时间线一致性”操作，每个数据项有一个主节点。然而，开发人员注意到，在发生网络分区或服务器故障时，这种设计决策对于许多应用程序来说过于严格：¹⁶

Sherpa 的首次部署支持时间线一致性模型——即，记录的所有副本都以相同的顺序应用所有更新——并具有 API 级别的功能，使应用程序能够应对异步复制。严格遵守会导致网络分区或服务器故障下的困难情况。这些问题可以通过覆盖程序和本地数据复制部分解决，但在许多情况下，应用程序需要一种宽松的方法。

根据同一份报告，PNUTS 现在提供了较弱的一致性替代方案，可在分区期间提供可用性。

数据中心网络故障

数据中心网络容易受到电源故障、错误配置、固件错误、拓扑更改、电缆损坏和恶意流量的影响。它们的故障模式因此多种多样。

冗余交换机上的电源故障

正如微软的 SIGCOMM 论文所表明的那样，冗余并不总是能防止链路故障。当电源分配单元发生故障并导致两个冗余架顶式交换机中的一个瘫痪时，Fog Creek 失去了该机架上部分客户的服务，但对于大多数用户来说，仍然保持一致且可用。然而，该机架中的另一个交换机也因不明原因断电。该故障隔离了两个相邻的机架，导致所有按需服务瘫痪。

BPDU 洪泛引起的交换机脑裂

在计划的网络重新配置以提高可靠性期间，Fog Creek Software 突然失去了对其网络的访问权限。¹⁰

在几个交换机之间形成了一个网络环路。控制对交换机管理网络访问的网关彼此隔离，产生了脑裂情况。由于...多交换机 BPDU（桥协议数据单元）洪泛，两者都无法访问，这表明生成树震荡。这很可能是改变环路域的原因。

根据 BPDU 标准，洪泛不应该发生。但它确实发生了，这种与系统假设的偏差导致了两个小时的完全服务不可用。

桥接环路、错误配置、损坏的 MAC 缓存

为了解决菊花链网络拓扑导致的高延迟问题，Github 在其数据中心安装了一组聚合交换机 (https://github.com/blog/1346-network-problems-last-friday)。尽管有冗余网络，但安装过程导致了桥接环路，并且交换机禁用了链路以防止故障。这个问题很快得到解决，但后来的调查显示，许多接口仍然固定在 100% 的容量。

当该问题正在调查中时，配置错误的交换机触发了异常的自动故障检测行为：当一个链路被禁用时，故障检测器禁用了所有链路，导致 18 分钟的停机时间。该问题被追溯到固件错误，该错误阻止交换机正确更新其 MAC（媒体访问控制）地址缓存，迫使它们将大多数数据包广播到每个接口。

MLAG、生成树和 STONITH

在 2012 年 12 月 (https://github.com/blog/1364-downtime-last-saturday)，聚合交换机上的计划软件更新导致 Github 不稳定。为了收集诊断信息，网络供应商终止了在其中一个聚合交换机上运行的特定软件代理。

Github 的聚合交换机成对集群，使用一种名为 MLAG（多机箱链路聚合）的功能，该功能将两台物理交换机呈现为单个 L2（第 2 层）设备。 MLAG 故障检测协议依赖于以太网链路状态和节点之间交换的逻辑心跳消息。当交换机代理被终止时，它无法关闭以太网链路，从而阻止了仍然健康的聚合交换机处理链路聚合、生成树和其他 L2 协议。这迫使所有链路进行生成树领导者选举和重新收敛，从而阻止了访问交换机之间 90 秒的所有流量。

这 90 秒的网络分区导致使用 Pacemaker 和 DRBD（分布式复制块设备）进行 HA（高可用性）故障转移的文件服务器相互宣告死亡，并相互发出 STONITH（射杀另一节点）消息。网络分区延迟了这些消息的传递，导致一些文件服务器对认为它们都处于活动状态。当网络恢复时，两个节点同时互相射杀。由于两个节点都已死亡，因此属于该对的文件不可用。

为了防止文件系统损坏，DRBD 要求管理员确保原始主节点在恢复复制之前仍然是主节点。对于两个节点都是主节点的对，运维团队必须检查日志文件或隔离地将每个节点联机以确定其状态。恢复这些停运的文件服务器对花费了五个小时，在此期间，Github 服务显著降级。

云网络

大规模虚拟化环境以瞬时延迟、丢包和完全网络分区而臭名昭著，这些问题通常影响特定的软件版本或可用区。有时，故障发生在提供商数据中心的特定子部分之间，揭示了底层硬件拓扑的裂面。

EC2 上隔离的 MongoDB 主节点

在“Call me maybe: MongoDB”的评论中 (http://aphyr.com/posts/284-call-me-maybe-mongodb)，Scott Bessler 观察到了 Kyle 之前演示的完全相同的故障模式

[这种情况] 今天发生在我们身上，当时 EC2 West 区域出现网络问题，导致网络分区，将 PRIMARY 与其 2 个 SECONDARY 分开在一个 3 节点复制集中。 2 小时后，旧的主节点重新加入并回滚了新主节点上的所有内容。

此分区导致两小时的写入丢失。从我们与大型 MongoDB 用户的对话中，我们了解到，导致亚马逊 EC2（弹性计算云）发生故障转移的网络事件很常见。同时主节点接受多天的写入在传闻中很常见。

EC2 上的 Mnesia 脑裂

中断可能会使两个节点连接到互联网，但无法看到彼此。这种类型的分区尤其危险，因为对分区集群两侧的写入都可能导致不一致和数据丢失。 Paul Mineiro 报告了 Mnesia 集群中完全相同的场景 (http://dukesoferl.blogspot.com/2008/03/network-partition-oops.html?m=1)，该集群在一夜之间发生了分歧。集群的状态并不关键，因此运维团队只是简单地摧毁了集群的一侧。他们的结论是：“这次经历使我们确信，我们需要优先考虑我们的网络分区恢复策略。”

EC2 不稳定性导致 MongoDB 和 ElasticSearch 不可用

EC2 中的网络中断可能仅影响某些节点组。例如，一份关于前端服务器和后端服务器之间完全分区的报告 (https://forums.aws.amazon.com/thread.jspa?messageID=454155) 指出，一个站点的服务器每月会多次失去与所有后端实例的连接几秒钟。即使中断很短暂，它们也会导致 30 到 45 分钟的中断以及 ElasticSearch 的索引损坏。随着问题升级，中断“每天发生 2 到 4 次”。

AWS EBS 中断

2011 年 4 月 21 日，AWS 遭受了 12 小时的不可用²，导致数百个备受瞩目的网站离线。作为正常 AWS 扩展活动的一部分，亚马逊工程师已将流量从美国东部 AZ（可用区）中的 EBS（弹性块存储）网络中的路由器转移出去，但是，由于不正确的路由策略

...受影响的可用区中的许多 EBS 节点完全与其他集群中的 EBS 节点隔离。与正常的网络中断不同，此更改同时断开了主网络和辅助网络的连接，使受影响的节点彼此完全隔离。

分区，加上激进的故障恢复代码，导致镜像风暴，导致网络拥塞，并触发了 EBS 中先前未知的竞争条件。 EC2 大约 12 小时不可用，EBS 不可用或降级超过 80 小时。

EBS 故障还导致亚马逊的 RDS（关系数据库服务）中断。当一个 AZ 发生故障时，RDS 被设计为故障转移到另一个 AZ；但是，美国东部 2.5% 的多 AZ 数据库由于故障转移协议中的错误而未能进行故障转移。

这种相关的故障导致了依赖 AWS 的客户的广泛中断。例如，Heroku 报告称其用户数据库的不可用时间在 16 到 60 小时之间。

EC2 上隔离的 Redis 主节点

2013 年 7 月 18 日，Twilio 的计费系统（在 Redis 中存储帐户信用额度）发生故障。¹⁹ 网络分区将 Redis 主节点与所有辅助节点隔离。由于 Twilio 没有提升新的辅助节点，因此对主节点的写入保持一致。然而，当主节点再次对辅助节点可见时，所有辅助节点同时启动与主节点的完全重新同步，使其过载并导致依赖 Redis 的服务发生故障。

运维团队重启了 Redis 主节点以解决高负载问题。然而，重启后，Redis 主节点重新加载了错误的配置文件，这导致它进入只读模式。由于所有帐户余额均为零且处于只读模式，因此每个 Twilio API 调用都会导致计费系统自动为客户信用卡充值，导致 1.1% 的客户在 40 分钟内被多收费。例如，Appointment Reminder 报告称，它发出的每条 SMS 消息和电话都导致其信用卡被收取 500 美元的费用，该信用卡在达到 3,500 美元后停止接受费用。

Twilio 从独立的计费系统（关系数据存储）恢复了 Redis 状态，并在经历了一些小问题后，恢复了正常服务，包括向受影响的用户提供信用额度。

托管服务提供商

运行您自己的数据中心可能比使用公共云基础设施更便宜且更可靠，但这意味着您必须成为网络和服务器管理员。那么托管服务提供商呢？他们向用户租用专用或虚拟化硬件，并经常为您处理网络和硬件设置？

未检测到的 GlusterFS 脑裂

Freistil IT 与一家主机托管/托管服务提供商托管其服务器。其监控系统提醒 Freistil 注意到特定数据中心本地化的 50-100% 数据包丢失。¹⁵ 由路由器固件错误引起的网络故障在第二天再次发生。数据包丢失增加导致 GlusterFS 分布式文件系统在未检测到的情况下进入脑裂

...我们在下午意识到[问题]，当时一位客户致电我们的支持热线，因为他们的网站无法交付某些图像文件。我们发现这是由脑裂情况引起的...并且 Gluster 文件系统中内置的自愈算法无法解决两个数据集之间的这种不一致性。

修复这种不一致性导致“由于网络流量的短暂激增，Web 节点短暂过载”。

匿名托管服务提供商

据传闻，许多主要的托管服务提供商都经历过网络故障。一家在一家主要托管服务提供商上运行 100-200 个节点的公司报告称，在 90 天的时间里，该提供商的网络经历了五个不同的分区时期。一些分区禁用了提供商的云网络与公共互联网之间的连接，另一些分区则将云网络与提供商的内部托管网络分隔开来。

Pacemaker/Heartbeat 脑裂

Linux-HA 的一篇帖子详细介绍了 Heartbeat 对之间持续时间很长的分区 (http://readlist.com/lists/lists.linux-ha.org/linux-ha/6/31964.html)，其中两个 Linode VM 各自声明对方已死亡，并为自己声明了一个共享 IP。后续帖子表明存在进一步的网络问题：由于 DNS（域名系统）解析失败，电子邮件无法发送，并且节点报告“网络不可达”。在这种情况下，影响似乎是最小的，部分原因是分区应用程序只是一个代理。

广域网

虽然我们主要关注局域网（或近局域网）上的故障，但 WAN（广域网）故障也很常见，只是记录较少。这些故障特别有趣，因为 WAN 路由冗余通常较少，并且保证高可用性（和灾难恢复）的系统通常需要在多个数据中心之间进行分布。因此，在分区或延迟增加的情况下进行优雅降级对于地理位置分散的服务尤为重要。

CENIC 研究

UCSD 的研究人员分析了 CENIC（加利福尼亚州教育网络倡议公司）WAN 五年的运营情况¹⁸，该 WAN 包含加利福尼亚州超过 200 个路由器。通过交叉关联链路故障和额外的外部 BGP（边界网关协议）和跟踪路由数据，他们发现了 500 多个“隔离网络分区”，这些分区导致了主机之间的连接问题。软件相关故障的平均分区持续时间为 6 分钟，硬件相关故障的平均分区持续时间超过 8.2 小时（中位数分别为 2.7 分钟和 32 分钟；第 95 个百分位数分别为 19.9 分钟和 3.7 天）。

PagerDuty

PagerDuty 设计其系统在面对节点、数据中心甚至提供商故障时保持可用；它的服务在两个 EC2 区域和一个由 Linode 托管的数据中心之间复制。 2013 年 4 月 13 日，加利福尼亚州北部的 AWS 对等互连点降级，导致 PagerDuty 的一个 EC2 节点出现连接问题。随着 AWS 可用区之间的延迟增加，通知分发系统失去了仲裁，并完全停止分发消息。

即使 PagerDuty 的基础设施在设计时考虑了分区容错，但两个数据中心之间共享的对等互连点造成的关联故障仍然导致了 18 分钟的不可用，从而丢弃了入站 API 请求并延迟了排队页面，直到重新建立仲裁。

全球路由故障

尽管互联网系统具有高度冗余，但一些网络故障发生在全球范围内。

Cloudflare

CloudFlare 运行着 23 个数据中心，具有冗余网络路径和任播故障转移。为了响应针对其一位客户的 DDoS（分布式拒绝服务）攻击，CloudFlare 运维团队部署了一条新的防火墙规则，以丢弃特定大小的数据包。¹⁷ Juniper 的 FlowSpec 协议将该规则传播到所有 CloudFlare 边缘路由器——但是随后

应该发生的情况是，不应该有任何数据包与该规则匹配，因为实际上没有数据包那么大。实际发生的情况是，路由器遇到该规则，然后继续消耗其所有 RAM，直到崩溃。

由于路由器未能自动重启以及管理端口无法访问，因此从故障中恢复变得复杂。

即使一些数据中心最初恢复了联机状态，它们也再次回落，因为我们整个网络的所有流量都击中了它们，并使其资源过载。

CloudFlare 仔细监控其网络，运维团队可以立即了解故障。然而，协调全球分布式系统很复杂，并且呼叫现场工程师手动查找和重启路由器需要时间。恢复在 30 分钟后开始，并在一个小时的不可用后完成。

Juniper 路由错误

作为 Juniper Networks 路由器升级的一部分引入的固件错误导致了 Level 3 Communications 网络骨干网在 2011 年发生中断。这随后导致服务脱机，包括时代华纳有线、RIM BlackBerry 和多家英国互联网服务提供商。

全球 BGP 中断

发生过几次与 BGP 错误配置相关的全球互联网中断。值得注意的是，在 2008 年，巴基斯坦电信为了响应政府封锁 YouTube.com 的法令，错误地向其他提供商通告了其（被阻止的）路由，这劫持了来自该站点的流量，并使其短暂地无法访问。

2010 年，一组杜克大学的研究人员通过测试 BGP 中的实验性标志实现了类似的效果 (http://www.merit.edu/mail.archives/nanog/msg11505.html)。类似的事件发生在 2006 年，导致 Martha Stewart Living 和《纽约时报》等网站脱机； 2005 年，土耳其的一个错误配置试图重定向整个互联网；以及 1997 年。

网卡和驱动程序

不可靠的网络硬件和/或驱动程序与各种分区有关。

BCM5709 和 Friends

作为网卡（网络接口控制器）不可靠的经典示例，Marc Donges 和 Michael Chan (http://www.spinics.net/lists/netdev/msg210485.html) 描述了他们流行的 Broadcom BCM5709 芯片如何丢弃入站数据包而不是出站数据包。主服务器无法服务请求，但是，由于它仍然可以向其热备用服务器发送心跳信号，因此备用服务器认为主服务器处于活动状态并拒绝接管。他们的服务不可用了五个小时，并且在没有重启的情况下无法恢复。

Sven Ulland 随后报告了 BCM5709S 芯片组在 Linux 2.6.32-41squeeze2 上出现的相同症状。尽管从主线中提取了提交，据称这些提交修复了 bnx2 驱动程序的类似问题，但 Ulland 的团队直到 2.6.38 版本才能够解决该问题。

由于大量服务器出货了 BCM5709，因此广泛观察到这些固件错误的更大影响。例如，5709 在 802.3x 流控制中存在一个错误，导致在芯片组崩溃或其缓冲区已满时产生多余的 PAUSE 帧。 BCM56314 和 BCM56820 片上交换机设备（在许多架顶式交换机中发现）放大了这个问题，这些设备默认情况下将 PAUSE 帧发送到与有问题的 5709 网卡通信的任何接口。这导致了整个交换机或网络上的级联故障。

正如 ElasticSearch 故障报告中所述，bnx2 驱动程序也可能导致瞬时或抖动的网络故障。同时，Broadcom 57711 因在巨型帧负载下导致高延迟而臭名昭著，对于使用 iSCSI 支持存储的 ESX 用户来说，这是一个特别棘手的问题。

英特尔 82574 死亡数据包

一家主板制造商未能为其基于英特尔 82574 的系统正确刷写 EEPROM。结果是一个非常难以诊断的错误，其中特定结构的入站 SIP（会话发起协议）数据包会禁用网卡。¹⁴ 只有冷重启才能使系统恢复正常。

驱动程序错误导致的 GlusterFS 分区

在计划的升级之后，CityCloud 注意到两个不同的 GlusterFS 对中出现了意外的网络故障，随后又出现了第三个。⁶ CityCloud 怀疑是链路聚合，因此在其交换机上禁用了该功能，并允许自愈操作继续进行。

大约 12 小时后，网络故障再次出现。 CityCloud 确定原因是驱动程序问题，并更新了停运的节点，从而恢复了服务。然而，中断导致 GlusterFS 对之间的数据不一致以及虚拟机文件系统之间的数据损坏。

应用程序级故障

并非所有异步性都源于物理网络。有时，丢弃或延迟的消息是崩溃、程序错误、操作系统调度程序延迟或进程过载的结果。以下研究强调了一个事实，即通信故障（其中系统延迟或丢弃消息）可能发生在软件堆栈的任何层，并且期望同步通信的设计可能在异步期间表现异常。

CPU 使用率和服务争用

Bonsai.io 发现 (http://www.bonsai.io/blog/2013/03/05/outage-post-mortem) ElasticSearch 节点上 CPU 和内存使用率过高，并且难以连接到各种集群组件，这可能是“允许过多高昂的请求通过集群”的后果。

重启服务器后，集群分裂成两个独立的组件。随后的重启解决了脑裂行为，但客户抱怨他们无法删除或创建索引。日志显示服务器反复尝试恢复未分配的索引，这“毒害了集群尝试服务于更改集群状态的正常流量”。这次故障导致 20 分钟的不可用和 6 小时的服务降级。

长时间 GC 暂停和 I/O

Stop-the-world 垃圾回收和磁盘 I/O 阻塞可能会导致运行时延迟达到秒级到分钟级。正如 Searchbox IO 和其他几个生产用户 (https://github.com/elasticsearch/elasticsearch/issues/2488) 发现的那样，ElasticSearch 集群中的 GC（垃圾回收）压力可能导致辅助节点声明主节点死亡并尝试新的选举。由于非多数仲裁配置，ElasticSearch 选出了两个不同的主节点，导致不一致和停机。令人惊讶的是，即使使用多数仲裁，由于协议设计，ElasticSearch 目前也无法阻止同时进行主节点选举；由于 I/O 导致的 GC 暂停和高 IO_WAIT 时间可能会导致脑裂行为、写入丢失和索引损坏。

MySQL 过载和 Pacemaker 段错误

2012 年，一次例行的数据库迁移导致 Github 的 MySQL 主节点上出现意外的高负载。¹³ 集群协调器无法对繁忙的 MySQL 服务器执行健康检查，因此判定主节点已宕机并提升了一个辅助节点。该辅助节点具有冷缓存且性能不佳，导致故障转移回原始主节点。运维团队手动停止了此自动故障转移，网站似乎恢复了。

第二天早上，运维团队发现备用 MySQL 节点不再从主节点复制更改。运维部门决定禁用协调器的维护模式，并允许复制管理器修复问题。不幸的是，这触发了协调器中的段错误，手动配置与自动化复制工具之间的冲突导致 github.com 不可用。

分区导致 MySQL 数据库中的不一致性——包括辅助节点和主节点之间，以及 MySQL 和其他数据存储（如 Redis）之间。由于外键关系不一致，Github 向错误的用户的仪表板显示了私有存储库，并错误地路由了一些新创建的存储库。

DRBD 脑裂

当一个双节点集群分区时，在任何情况下节点都无法可靠地声明自己为主节点。当这种情况发生在 DRBD 文件系统上时，正如一位用户报告 (http://serverfault.com/questions/485545/dual-primary-ocfs2-drbd-encountered-split-brain-is-recovery-always-going-to-be) 的那样，两个节点都可以保持在线并接受写入，从而导致文件系统级别的更改出现分歧。

NetWare 脑裂

短暂的故障可能导致长时间的停机。在 Usenet 发布到 novell.support.cluster-services 的帖子中，一位管理员报告说，运行 Novell NetWare 的双节点故障转移集群遇到了瞬时网络中断。辅助节点最终自行终止，而主节点（虽然仍在运行）无法被网络上的其他主机访问。该帖子继续详细描述了一系列与备份作业相关的网络分区事件。

VoltDB 在 EC2 上的脑裂

一位 VoltDB 用户报告说，经常发生的网络故障导致副本发散 (https://forum.voltdb.com/showthread.php?552-Nodes-stop-talking-to-each-other-and-form-independent-clusters)，但也表明网络日志中没有丢包。由于此集群未启用脑裂检测，因此两个节点都作为隔离的主节点运行，导致严重的数据丢失。

神秘的 RabbitMQ 分区

有时，没有人知道系统为什么会分区。这个 RabbitMQ 故障 (http://serverfault.com/questions/497308/rabbitmq-network-partition-error) 似乎就是其中一种情况：重传很少，消息之间没有大的间隔，节点之间也没有明显的连接丢失。将分区检测超时时间增加到两分钟减少了分区的频率，但并没有完全阻止它们。

ElasticSearch 在 EC2 上的发现失败

另一个 EC2 脑裂 (http://elasticsearch-users.115913.n3.nabble.com/EC2-discovery-leads-to-two-masters-td3239318.html)：当发现消息交换时间超过三秒时，一个双节点集群在“大约十分之一的启动”中未能收敛。结果，两个节点都将以相同集群名称作为主节点启动。由于 ElasticSearch 不会自动降级主节点，因此脑裂一直持续到管理员介入。将发现超时时间增加到 15 秒解决了该问题。

Windows Azure 上的 RabbitMQ 和 ElasticSearch

有一些关于 Windows Azure 分区的零星报告，例如一个关于 RabbitMQ 集群每周都会进入脑裂的账户 (http://rabbitmq.1065348.n5.nabble.com/Instable-HA-cluster-td24690.html)。还有一个关于 ElasticSearch 脑裂的报告 (https://groups.google.com/forum/?fromgroups#!topic/elasticsearch/muZtKij3nUw)，但由于与 EC2 相比，Azure 是一个相对较新的平台，因此对其网络可靠性的描述有限。

结论：我们何去何从？

本文旨在作为一个参考点——说明根据广泛的（通常是非正式的）说法，通信故障发生在许多真实世界的环境中。进程、服务器、网卡、交换机以及局域网和广域网都可能发生故障，并带来实际的经济后果。网络中断可能会在已经稳定运行数月的系统中突然发生，可能发生在例行升级期间，也可能是紧急维护的结果。这些中断的后果包括延迟增加和暂时不可用，以及不一致、损坏和数据丢失。脑裂不是一个学术问题：它发生在各种类型的系统中——有时会持续数天。分区值得认真考虑。

另一方面，有些网络确实非常可靠。大型金融公司的工程师们通过轶事报告称，尽管他们付出了巨大的努力来设计能够优雅地容忍分区的系统，但他们的网络很少（如果有的话）表现出分区行为。谨慎的工程设计和积极的网络进步（以及大量的资金）可以防止中断。此外，在本文中，我们介绍了失败场景；我们承认，要证明网络故障未发生要困难得多。

然而，并非所有组织都能承担高可靠性网络的成本或运营复杂性。从 Google 和 Amazon（由于规模庞大而运营商品和/或低成本硬件）到预算紧张的单人创业公司，除了真实世界的分布式系统面临的各种其他故障模式（包括人为错误）之外，隔离通信的网络故障是一个真正的风险。

在分区发生之前考虑这种风险非常重要，因为在白板上制定关于分区行为的决策要比在生产环境中重新设计、重新工程和升级复杂的系统容易得多——尤其是在系统向用户抛出错误时。对于某些应用程序，失败是一种选择——但您应该将其表征并明确地将其纳入您的设计中。最后，考虑到分区感知设计的额外延迟¹ 和协调优势⁴，您可能会发现，在平均情况下，考虑这些分区也会带来好处。

我们邀请您贡献您自己关于网络分区的经验，无论有无分区。在 https://github.com/aphyr/partitions-post 上打开一个 pull request（顺便说一句，其中包含所有参考文献），留下评论，撰写博客文章，或发布事后分析。数据将为本次对话、未来的设计以及最终我们都依赖的系统的可用性提供信息。

参考文献

1. Abadi, D. 2012. Consistency tradeoffs in modern distributed database system design: CAP is only part of the story. Computer 45(2): 37-42; http://dl.acm.org/citation.cfm?id=2360959.

2. Amazon Web Services. 2011. Summary of the Amazon EC2 and Amazon RDS service disruption in the U.S. East region; http://aws.amazon.com/message/65648/.

3. Bailis, P., Davidson, A., Fekete, A., Ghodsi, A., Hellerstein, J.M., Stoica, I. 2014. Highly available transactions: virtues and limitations. In Proceedings of VLDB (to appear); http://www.bailis.org/papers/hat-vldb2014.pdf.

4. Bailis, P., Fekete, A., Franklin, M.J., Ghodsi, A., Hellerstein, J.M., Stoica, I. 2014. Coordination-avoiding database systems; http://arxiv.org/abs/1402.2237.

5. Bailis, P., Ghodsi, A. 2013. Eventual consistency today: limitations, extensions, and beyond. 11(3); https://queue.org.cn/detail.cfm?id=2462076.

6. CityCloud. 2011; https://www.citycloud.eu/cloud-computing/post-mortem/.

7. Davidson, S.B., Garcia-Molina, H., Skeen, D. 1985. Consistency in a partitioned network: a survey. Computing Surveys 17(3): 341-370; http://dl.acm.org/citation.cfm?id=5508.

8. Dwork, C., Lynch, M., Stockmeyer, L. 1988. Consensus in the presence of partial synchrony. Journal of the 35(2): 288-323. http://dl.acm.org/citation.cfm?id=42283.

9. Fischer, M. J., Lynch, N.A., Patterson, M.S. 1985. Impossibility of distributed consensus with one faulty process. Journal of the 32(2): 374-382; http://dl.acm.org/citation.cfm?id=214121.

10. Fog Creek Software. 2012. May 5-6 network maintenance post-mortem; http://status.fogcreek.com/2012/05/may-5-6-network-maintenance-post-mortem.html.

11. Gilbert, S., Lynch, N. 2002. Brewer's conjecture and the feasibility of consistent, available, partition-tolerant Web services. SIGACT News 33(2): 51-59; http://dl.acm.org/citation.cfm?id=564601.

12. Gill, P., Jain, N., Nagappan, N. 2011. Understanding network failures in data centers: measurement, analysis, and implications. In Proceedings of SIGCOMM; http://research.microsoft.com/en-us/um/people/navendu/papers/sigcomm11netwiser.pdf.

13. Github. 2012. Github availability this week; https://github.com/blog/1261-github-availability-this-week.

14. Kielhofner, K. 2013. Packets of death; http://blog.krisk.org/2013/02/packets-of-death.html.

15. Lillich, J. 2013. Post mortem: network issues last week; http://www.freistil.it/2013/02/post-mortem-network-issues-last-week/.

16. Narayan, P.P.S. 2010. Sherpa update; https://developer.yahoo.com/blogs/ydn/sherpa-7992.html#4.

17. Prince, M. 2013. Today's outage post mortem; http://blog.cloudflare.com/todays-outage-post-mortem-82515.

18. Turner, D., Levchenko, K., Snoeren, A., Savage, S. 2010. California fault lines: understanding the causes and impact of network failures. In Proceedings of SIGCOMM ; http://cseweb.ucsd.edu/~snoeren/papers/cenic-sigcomm10.pdf.

19. Twilio. 2013. Billing incident post-mortem: breakdown, analysis and root cause; http://www.twilio.com/blog/2013/07/billing-incident-post-mortem.html.

喜欢还是讨厌？告诉我们

[email protected]

Peter Bailis 是计算机科学的研究生，也是加州大学伯克利分校 AMPLab 和 BOOM 项目的成员。他目前研究数据库和分布式系统，特别关注快速且可扩展的数据服务和事务处理。他拥有哈佛大学的文学学士学位，并获得了 NSF 研究生奖学金和伯克利研究生学习奖学金。他定期在 http://bailis.org/blog 上撰写博客，并在 https://twitter.com/pbailis 上发布推文。

Kyle Kingsbury 是 Riemann、Timelike 和许多其他开源软件包的作者。在空闲时间，他作为 Jepsen 项目的一部分验证分布式系统的安全声明。

最初发表于 Queue vol. 12, no. 7—
在数字图书馆中评论本文

更多相关文章

David Collier-Brown - 你不了解带宽
当你的员工或客户说他们的互联网性能很差时，带宽可能不是问题。一旦他们拥有 50 到 100 Mbps 范围内的带宽，问题就是延迟，即 ISP 的路由器处理他们的流量需要多长时间。如果你是一家 ISP 并且你的所有客户都讨厌你，请振作起来。这现在是一个可以解决的问题，这要归功于一群敬业的人，他们找到了问题，解决了它，然后在家庭路由器中验证了他们的解决方案。

Geoffrey H. Cooper - 使用 FDO 和不受信任的安装程序模型的设备入职
设备的自动入职是处理正在安装的越来越多的“边缘”和 IoT 设备的重要技术。设备的入职与大多数设备管理功能不同，因为设备的信任从工厂和供应链转移到目标应用程序。为了通过自动入职加快流程，必须在设备中正式确定供应链中的信任关系，以允许自动化过渡。

Brian Eaton, Jeff Stewart, Jon Tedesco, N. Cihan Tas - 通过关键路径跟踪的分布式延迟分析
低延迟是许多 Google 应用程序（如搜索）的重要功能，而延迟分析工具在维持大规模低延迟方面起着至关重要的作用。对于包括功能和数据不断发展的服务的复杂分布式系统，将整体延迟保持在最低限度是一项具有挑战性的任务。在大型、真实世界的分布式系统中，现有的工具（如 RPC 遥测、CPU 分析和分布式跟踪）对于理解整个系统的子组件很有价值，但在实践中不足以执行端到端延迟分析。

David Crawshaw - 一切 VPN 焕然一新
VPN（虚拟专用网络）已有 24 年的历史。这个概念是为与我们今天所知的互联网截然不同的互联网而创建的。随着互联网的发展和变化，VPN 用户和应用程序也在发展和变化。 VPN 在 2000 年代的互联网中经历了尴尬的青春期，与其他广泛流行的抽象概念交互不良。在过去的十年中，互联网再次发生了变化，这个新的互联网为 VPN 提供了新的用途。全新协议 WireGuard 的开发为构建这些新 VPN 提供了技术基础。