ACM通信
实践
网络可靠
图片来源:Dalibor Zivotic
“网络是可靠的”在彼得·多伊奇的“分布式计算的八个谬误”的经典列表中名列榜首，所有这些谬误“从长远来看都被证明是错误的，而且所有这些谬误都带来了巨大的麻烦和痛苦的学习经验”(https://blogs.oracle.com/jag/resource/Fallacies.html)．解释和理解网络行为的影响是设计健壮的分布式程序的关键。事实上，Deutsch的六个“谬论”直接与网络通信的限制有关。这应该不足为奇:通过共享通道进行通信的能力(通常也是要求)是分布式程序的一个决定性特征，该领域的许多关键结果都与在特定的网络条件集下执行分布式计算的可能性和不可能性有关。
例如，著名的FLP不可能结果9演示了在异步网络(即面临不确定通信的网络)中无法保证一致性分区进程之间)，其中有一个错误的进程。这意味着，在不可靠(不及时)的消息传递的情况下，在网络异步和单个服务器故障的情况下，不能保证能够完成基本操作，例如修改集群中的机器集(即维护组成员关系，就像Zookeeper这样的系统目前的任务一样)。相关结果描述了无法保证可序列化事务的进展，7linearizable读/写11以及在不利条件下各种有用的、程序员友好的保证。3.这些结果的含义不仅仅是学术上的:这些不可能的结果推动了在网络故障时提供一系列替代保证的系统和设计的扩散。5然而，在一个更友好、更可靠、能够保证及时消息传递的网络下，FLP和许多相关结果不再成立:8通过对网络行为做出更强的保证，我们可以绕过这些不可能证明的可编程含义。
因此，部署环境中的可靠性程度在健壮的系统设计中是至关重要的，它直接决定了系统可以在不等待的情况下可靠地执行的操作类型。不幸的是，网络的程度实际上真实世界中的可靠性是相当多且不断发展的争论的主题。一些人声称网络是可靠的(或者在实践中划分是非常罕见的)，并且我们过于关注理论失效模式的设计。相反，其他人证实分区确实发生在他们的部署中，正如Amazon Web Services的James Hamilton简洁地总结的那样，“网络分区应该很少，但网络设备继续导致比它应该引起的更多的问题”(http://bit.ly/1mD8E3q)．那么谁是对的呢?
这一讨论中的一个关键挑战是缺乏证据。我们几乎没有比较网络和应用程序可靠性的规范化基础，数据更少。我们可以跟踪链路可用性和估计数据包丢失，但理解端到端对应用程序的影响更困难。我们所拥有的有限证据很难概括:它通常是特定于部署的，并且与特定的供应商、拓扑和应用程序设计密切相关。更糟糕的是，即使组织对其网络行为有清晰的了解，他们也很少分享细节。最后，分布式系统被设计为抵抗失败，这意味着明显的停机通常依赖于故障模式的复杂交互作用。当网络故障时，许多应用程序会静默地降级，导致的问题可能在一段时间内无法理解。
因此，我们对现实世界分布式系统的故障模式的许多看法都是建立在猜测和谣言的基础上的。系统管理员和开发人员会边喝啤酒边交换故事，但对网络可用性的详细、公开的事后分析和全面调查却很少。在本文中，我们将非正式地将其中的一些故事(在大多数情况下，它们都是毫不掩饰的轶事)放在一起。我们的重点是在可能的情况下描述实际的网络行为，在不可能的情况下(更常见的是)描述网络故障和异步对实际系统部署的影响。我们相信这是迈向更开放和诚实地讨论现实分区行为的第一步，并最终走向更健壮的分布式系统设计。
来自大规模部署的隆隆声
首先，让我们考虑来自分布式系统中大型参与者的证据:运行全球分布式基础设施、拥有数十万台服务器的公司。这些报告可能最好地概括了大规模的操作，提炼了可能是有史以来部署的最大分布式系统的操作经验。这些公司的出版物(不同于我们稍后将研究的许多报告)通常捕获总体系统行为和大规模统计趋势，并指出(通常是间接地)分区在其部署中是值得关注的。
来自多伦多大学和微软研究院的一个团队研究了几个微软数据中心的网络故障行为。12他们发现平均每天5.2个设备和40.8个链路的故障率，平均修复时间约为5分钟(最多为一周)。虽然研究人员注意到，将链路故障和通信分区相关联是一项挑战，但他们估计，每次故障的包损失中值为59,000个包。也许更令人担忧的是，他们发现网络冗余只提高了43%的中间流量;也就是说，网络冗余并不能消除网络故障的常见原因。
加州大学圣地亚哥分校和惠普实验室的研究人员进行了一项联合研究，通过分析支持票数据(http://www.hpl.hp.com/techreports/2012/HPL-2012-101.pdf)．与连接相关的票占支持票的11.4%(其中14%属于最高优先级)，最高优先级的票的事件持续时间中值为2小时45分钟，所有票的事件持续时间中值为4小时18分钟。
谷歌的论文描述了Chubby(他们的分布式锁管理器)的设计和操作，概述了多个集群在700天的操作中61次中断的根本原因(http://research.google.com/archive/chubby-osdi06.pdf)．在持续时间超过30秒的9次停机中，4次是网络维护引起的，2次是“疑似网络连接问题”引起的。
网络在现实世界中到底有多可靠，一直是一个备受争议的话题。
在“构建大规模分布式系统的设计课程和建议”(http://www.cs.cornell.edu/projects/ladis2009/talks/dean-keynote-ladis2009.pdf)， Jeff Dean建议，一个新的谷歌集群第一年的典型情况包括:
- 5个机架不稳定(4080台机器看到50%的包丢失)
- 8次网络维护(其中4次可能会导致约30分钟的随机连接丢失)
- 三次路由器故障(必须立即中断一个小时的流量)
虽然谷歌没有告诉我们很多关于其网络分区的应用程序级后果的信息，但Dean认为它们值得关注，他引用了创建“易于使用的抽象来解决状态块的多个版本的冲突更新”的长期挑战，这对于“修复网络分区后在不同数据中心协调复制的状态”很有用。
亚马逊的Dynamo论文(http://bit.ly/1mDs0Yh)经常引用分区的发生率作为一个关键的设计考虑因素。作者特别指出，他们拒绝了来自“传统复制关系数据库系统”的设计，因为它们“不能处理网络分区”。
雅虎PNUTS/Sherpa被设计为在地理位置不同的数据中心运行的分布式数据库。最初，pnut支持高度一致的时间轴一致性操作，每个数据项有一个主节点。然而，开发人员注意到，在发生网络分区或服务器故障的情况下，这种设计决策对许多应用程序的限制太大:16
Sherpa的第一个部署支持时间线一致性模型，即，记录的所有副本以相同的顺序应用所有更新，并具有api级别的特性，使应用程序能够处理异步复制。严格遵守会导致网络分区或服务器故障时的困难情况。这些问题可以通过覆盖过程和本地数据复制部分解决，但在许多情况下，应用程序需要一种轻松的方法．
根据同一份报告，pnut现在提供了较弱的一致性替代方案，在分区期间提供可用性。
数据中心网络故障
数据中心的网络容易出现掉电、配置错误、固件错误、拓扑变化、线缆损坏和恶意流量等问题。因此，它们的失效模式是不同的。
正如微软SIGCOMM的论文所建议的那样，冗余并不总是能防止链接故障。当一个配电装置发生故障并损坏了两个冗余的机架顶部开关中的一个时，Fog Creek失去了该机架上的一部分客户的服务，但大多数用户仍然可以使用。但是，那个架子上的另一个开关也因不明原因失去动力。该故障将相邻的两个机架相互隔离，导致所有随需应变服务瘫痪。
在一次计划中的网络重构以提高可靠性期间，Fog Creek突然失去了对其网络的访问。10
几个交换机之间形成了一个网络环路。控制访问交换机管理网络的网关彼此隔离，产生了裂脑的场景。由于…多交换机BPDU(桥接协议数据单元)泛滥，表示生成树振荡。这很可能是改变循环定义域的原因．
根据BPDU标准，洪水不应该发生。但它确实发生了，这种与系统假设的偏差导致了两个小时的总服务不可用。
为了解决由雏菊链式网络拓扑结构引起的高延迟，Github在其数据中心(https://github.com/blog/1346-network-problems-last-friday)．尽管是一个冗余的网络，但安装过程导致了桥环，交换机禁用链接以防止故障。这个问题很快得到了解决，但后来的调查显示，许多接口仍然固定在100%的容量。
在调查该问题时，一个配置错误的交换机触发了异常的自动故障检测行为:当一条链路被禁用时，故障检测器也被禁用所有链接，导致停机18分钟。该问题被追踪到固件错误，阻止交换机正确更新其MAC地址缓存，迫使它们广播大多数数据包到每个接口。
2012年12月，一个计划中的汇聚交换机软件更新导致了Github (https://github.com/blog/1364-downtime-last-saturday)．为了收集诊断信息，网络供应商关闭了在其中一个汇聚交换机上运行的特定软件代理。
Github的汇聚交换机使用一种称为MLAG的特性成对聚集，该特性将两个物理交换机作为一个单层二层设备。MLAG故障检测协议依赖于以太网链路状态和节点间交换的逻辑心跳消息。当交换机代理被杀死时，它无法关闭以太网链路，从而阻止仍然正常运行的汇聚交换机处理链路聚合、生成树和其他L2协议。这迫使生成树的领导者选举和所有链路的重新收敛，阻塞接入交换机之间的所有流量达90秒。
这个90秒的网络分区导致使用Pacemaker和DRBD进行HA故障转移的文件服务器互相宣布对方死亡，并向彼此发出STONITH(朝另一个节点头部开枪)消息。网络分区延迟了这些消息的传递，导致一些文件服务器对误以为是这样这两个活跃。当网络恢复时，两个节点同时向对方开枪。由于两个节点都死，属于这对节点的文件不可用。
为了防止文件系统损坏，DRBD要求管理员在恢复复制之前确保原来的主节点仍然是主节点。对于两个节点都是主节点的pair，运维团队必须检查日志文件，或单独使每个节点联机，以确定其状态。恢复这些文件服务器对花了5个小时，在此期间Github服务严重降级。
云计算网络
大规模虚拟化环境在瞬时延迟、数据包丢失和完全的网络分区方面臭名昭著，通常会影响特定的软件版本或可用性分区。有时，故障发生在提供者数据中心的特定子部分之间，揭示了底层硬件拓扑中的分割平面。
在一个评论中，也许可以打电话给我:MongoDB (http://aphyr.com/posts/284-call-me-maybe-mongodb)， Scott Bessler观察到与Kyle在Jepsen的帖子中展示的完全相同的失败模式:
我们今天遇到了这种情况，当时EC2 West区域出现了网络问题，导致了一个网络分区，在一个3节点的替换集中将PRIMARY和它的2个secondary分隔开。2小时后，旧的主节点重新加入，并将新的主节点上的一切都回退了．
该分区导致2小时的写丢失。从我们与大规模MongoDB用户的对话中，我们了解到导致EC2故障转移的网络事件很常见。同时接受多日投票的初选很常见。
中断可能导致两个节点连接到Internet，但无法看到彼此。这种类型的分区特别危险，因为写入分区集群的两端可能导致数据不一致和丢失。Paul Mineiro在Mnesia集群中报告了这个场景(http://bit.ly/1zrVxI1)，双方在一夜之间产生分歧。集群的状态不是临界的，所以操作团队只是关闭了集群的一侧。他们总结道:“经验使我们确信，我们需要优先考虑我们的网络分区恢复策略。”
EC2中的网络中断只能影响某些节点组。例如，一份关于前端和后端服务器之间的总分区的报告指出，一个站点的服务器与所有后端实例的连接会在几秒钟内丢失，每月会发生几次(https://forums.aws.amazon.com/thread.jspa?messageID=454155)．尽管中断时间很短，但却导致了3045分钟的中断和ElasticSearch索引的损坏。随着问题的升级，中断“每天发生2到4次”。
2011年4月21日，亚马逊网络服务中断了12个小时，2导致数百个知名网站下线。作为正常AWS扩展活动的一部分，Amazon工程师将流量从单个美国东部可用分区(AZ)的弹性块存储(EBS)网络中的路由器转移，但是，由于不正确的路由策略:
．.．受影响的可用性区域中的许多EBS节点与其集群中的其他EBS节点完全隔离。与正常的网络中断不同，此更改同时断开了主网络和从网络，使受影响的节点彼此完全隔离．
分区加上积极的故障恢复代码，导致镜像风暴，导致网络拥塞，并在EBS中触发了以前未知的竞争条件。EC2大约12小时不可用，EBS超过80小时不可用或降级。
EBS故障还导致Amazon的关系数据库服务中断。当一个AZ发生故障时，RDS被设计成故障转移到另一个AZ。然而，由于故障转移协议的错误，美国东部2.5%的多AZ数据库失败。
这种相关的故障导致依赖AWS的客户端普遍中断。例如，Heroku报告用户的数据库出现了16到60个小时的不可用。
2013年7月18日，Twilio在Redis中存储账户信用的计费系统出现故障。19一个网络分区将Redis主服务器与所有从服务器隔离开来。因为Twilio没有提升新的次要服务器，所以对主服务器的写入保持一致。然而，当主服务器对辅助服务器再次可见时，所有辅助服务器都会同时启动与主服务器的完全重新同步，导致主服务器超载并导致依赖redis的服务失败。
运维团队重新启动了Redis主系统，以解决高负载问题。然而，在重新启动时，Redis主服务器重新加载了一个错误的配置文件，这导致它进入只读模式。在所有账户余额为零且处于只读模式的情况下，每次Twilio API调用都会导致计费系统自动为客户的信用卡充值。1.1%的客户在40分钟内被多收费。例如，约会提醒报告说，他们发出的每条短信和电话都会导致他们的信用卡支付500美元的费用，而信用卡在支付了3500美元后就不再接受支付了。
Twilio从一个独立的计费系统(一个关系数据存储)恢复了Redis状态，在经历了一些故障后，恢复了正常的服务，包括对受影响用户的信用。
主机提供商
运行自己的数据中心可能比使用公共云基础设施更便宜、更可靠，但这意味着您必须是一名网络和服务器管理员。托管提供商呢?它们向用户租用专用的或虚拟的硬件，通常为您负责网络和硬件设置。
Freistil IT通过托管/托管提供商托管其服务器。他们的监控系统向Freistil发出警报，称某个特定数据中心有50%100%的包丢失。15路由器固件bug导致的网络故障第二天又出现了。高丢包率导致GlusterFS分布式文件系统进入split-brain而未被检测到:
．.．我们是在下午意识到(问题)的，当时一位客户打电话给我们的支持热线，因为他们的网站无法提供某些图像文件。我们发现这是由大脑分裂引起的……Gluster文件系统内置的自愈算法无法解决这两个数据集之间的不一致．
修复这种不一致导致了“由于网络流量短暂激增而导致的网络节点短暂过载”。
有趣的是，许多主要的托管主机提供商都经历过网络故障。一家在主要主机提供商上运行100200个节点的公司报告说，在90天的时间内，该提供商的网络经历了5个不同的分区时期。一些分区禁止提供商的云网络与公共Internet之间的连接，另一些分区将云网络与提供商的内部托管网络分离。
发给Linux-HA的帖子详细描述了Heartbeat对之间的长时间运行的分区(http://bit.ly/1k9Ym6V)，其中两个Linode虚拟机各自宣布另一个虚拟机死亡，并为自己申请一个共享IP。连续的帖子表明了进一步的网络问题:由于DNS解析失败，邮件发送失败，节点报告网络不可达。在这种情况下，影响似乎是最小的，部分原因是分区应用程序只是一个代理。
广域网络
虽然我们主要关注局域网络(或近局域网络)上的故障，但广域网络(WAN)故障也很常见，尽管记录较少。这些故障特别有趣，因为冗余广域网路由通常较少，而且保证高可用性(和灾难恢复)的系统通常需要跨多个数据中心分布。因此，分区下的适当降级或延迟增加对于地理上分布广泛的服务尤其重要。
加州大学圣地亚哥分校的研究人员分析了CENIC广域网5年的运行情况，18它包含了加州200多个路由器。通过相互关联的链路故障和额外的外部BGP和traceroute数据，他们发现超过508个“隔离网络分区”导致主机之间的连接问题。平均分区持续时间从软件相关故障的6分钟到硬件相关故障的8.2小时以上(中值2.7分钟和32分钟;分别为19.9分钟和3.7天)。
PagerDuty将他们的系统设计为在节点、数据中心甚至提供者故障时仍可使用;它们的服务在两个EC2区域和Linode托管的数据中心之间复制。2013年4月13日，位于加州北部的AWS对等点降级，导致PagerDuty的一个EC2节点出现连接问题。由于AWS可用性区域之间的延迟增加，通知调度系统失去了仲裁，并完全停止调度消息。
尽管PagerDuty的基础结构在设计时考虑到了分区容限，但由于两个数据中心之间的共享对等点导致的相关故障导致了18分钟的不可用，导致入站API请求丢失，并延迟排队页面，直到重新建立quorum。
全局路由故障
尽管互联网系统的冗余程度很高，但仍有一些网络故障在全球范围内发生。
CloudFlare运行23个数据中心，具有冗余网络路径和任意转换故障转移。为了应对针对他们客户的DDoS攻击，CloudFlare运营团队部署了一个新的防火墙规则，以丢弃特定大小的包。17Juniper的FlowSpec协议将该规则传播到所有CloudFlare边缘路由器，但随后:
应该发生的情况是，没有数据包应该符合这个规则，因为实际上没有数据包那么大。实际情况是，路由器遇到了规则，然后继续消耗所有的RAM，直到它们崩溃．
由于路由器无法自动重启，以及管理端口无法访问，从故障中恢复非常复杂。
尽管一些数据中心一开始恢复了在线，但由于整个网络上的所有流量都对它们造成了冲击，使它们的资源过载，它们又重新恢复了．
CloudFlare仔细监控其网络，运营团队立即发现了故障。然而，协调全球分布式系统是复杂的，呼叫现场工程师手动查找和重启路由器需要时间。恢复在30分钟后开始，并在一个小时后完成。
2011年，作为Juniper Networks路由器升级的一部分而引入的固件bug导致了三级通信网络骨干网的中断。随后，包括时代华纳有线、RIM黑莓和几家英国互联网服务提供商在内的服务都被切断。
已经发生了几次与BGP错误配置相关的全球互联网中断。值得注意的是，在2008年，巴基斯坦电信响应政府的一项禁令予以屏蔽YouTube.com该网站错误地向其他提供商发布了其(被屏蔽的)路由，从而劫持了该网站的流量，并短暂地导致该网站无法访问。
2010年，杜克大学的一组研究人员通过测试BGP协议中的一个实验标志(http://bit.ly/1rbAl4j)．2006年也发生过类似的事件，玛莎·斯图尔特生活(Martha Stewart Living)和the纽约时报离线;2005年，土耳其的一个错误配置试图重定向整个互联网;1997年。
网卡和驱动程序
大量的分区涉及不可靠的网络硬件和/或驱动程序。
作为网卡不可靠的一个经典例子，Marc Donges和Michael Chan描述了他们的广受欢迎的Broadcom BCM5709芯片是如何丢弃入站数据包而不是出站数据包的(http://www.spinics.net/lists/net-dev/msg210485.html)．主服务器无法为请求提供服务，但是，因为它仍然可以向热备服务器发送心跳，所以备服务器认为主服务器是活的，并拒绝接管。他们的服务中断了5个小时，没有重启就无法恢复。
尽管互联网系统的冗余程度很高，但仍有一些网络故障在全球范围内发生。
Sven Ulland进行了跟进，报告了在Linux 2.6.32-41squeeze2上使用BCM5709S芯片组时出现的相同症状。尽管从主线提取提交，据说修复了bnx2驱动程序的一组类似的问题，Ulland的团队直到2.6.38版本才解决这个问题。
由于大量服务器都采用了BCM5709，因此可以广泛观察到这些固件错误的更大影响。例如，5709在802.3 s流控制中有一个错误，导致当芯片组崩溃或缓冲区被填满时出现多余的PAUSE帧。这个问题被BCM56314和BCM56820片上交换机设备(在许多机架顶部交换机中可以找到)放大了，在默认情况下，它们向与问题5709网卡通信的任何接口发送PAUSE帧。这将导致整个交换机或网络的级联故障。
正如ElasticSearch故障报告中所述，bnx2驱动程序还可能导致瞬时或震荡网络故障。与此同时，Broadcom 57711因在大帧负载下导致高延迟而臭名昭著，这对于使用iscsi支持存储的ESX用户来说是一个特别棘手的问题。
一个主板制造商未能为其基于Intel 82574的系统正确地闪光EEPROM。结果是一个非常难以诊断的错误，其中一个特定结构的入站SIP包将禁用NIC。14只有冷重启才能使系统恢复正常。
在一次预定的升级之后，CityCloud注意到两个不同的GlusterFS对中出现了意外的网络故障，然后是第三个。6由于怀疑链路聚合，CityCloud关闭了交换机上的该功能，并允许进行自修复操作。
大约12小时后，网络故障又出现了。CityCloud将原因确定为驱动程序问题，并更新了被停机的节点，并返回服务。但是，这次中断导致了GlusterFS对之间的数据不一致和虚拟机文件系统之间的数据损坏。
应用程序级故障
并非所有异步都起源于物理网络。有时，丢失或延迟消息是崩溃、程序错误、操作系统调度器延迟或进程过载的结果。下面的研究强调了这样一个事实:通信失败(其中系统延迟或丢失消息)可能发生在软件堆栈的任何层，而期望同步通信的设计可能在异步期间表现出出乎意料的行为。
盆景。io (http://www.bonsai.io/blog/2013/03/05/outage-post-mortem)发现在一个ElasticSearch节点上CPU和内存使用量很高，并且很难连接到各种集群组件，这可能是“允许通过集群的请求数量过高”的结果。
重新启动服务器后，集群分裂为两个独立的组件。随后的重启解决了裂脑行为，但客户抱怨他们无法删除或创建索引。日志显示，服务器不断试图恢复未分配的索引，这“破坏了集群为改变集群状态的正常流量提供服务的尝试”。该故障导致20分钟不可用和6小时的服务降级。
停止整个世界的垃圾收集和磁盘I/O阻塞会导致运行时延迟几秒到几分钟。正如Searchbox IO和其他几个生产用户所发现的，ElasticSearch集群中的GC压力会导致次要节点宣布主节点已死，并尝试新的选举(https://github.com/elasticsearch/elasticsearch/issues/2488)．由于非多数仲裁配置，ElasticSearch选择了两个不同的主节点，导致不一致和停机。令人惊讶的是，由于协议设计的原因，即使在多数仲裁的情况下，ElasticSearch目前也不阻止同步的主选举;由于I/O导致的GC暂停和高IO_WAIT时间会导致裂脑行为、写丢失和索引损坏。
停止整个世界的垃圾收集和磁盘I/O阻塞会导致运行时延迟几秒到几分钟。
2012年，一次例行的数据库迁移导致了Github上MySQL主服务器意外的高负载。13集群协调器无法对繁忙的MySQL服务器执行运行状况检查，因此判断主服务器已关闭，并提升了辅助服务器。次要服务器有一个冷缓存，性能很差，导致故障转移回原始的主要服务器。操作团队手动停止了自动故障转移，站点似乎恢复了。
第二天早上，操作团队发现备用MySQL节点不再复制主节点的更改。操作人员决定禁用协调器的维护模式，并允许复制管理器修复该问题。不幸的是，这触发了协调器中的段错误，并且由于手动配置和自动复制工具之间的冲突，github.com被渲染为不可用。
该分区导致MySQL数据库在从服务器和主服务器之间，以及MySQL和其他数据存储(如Redis)之间不一致。由于外键关系不一致，Github将私有存储库显示到错误的用户仪表板，并错误地路由了一些新创建的存储库。
当一个双节点集群进行分区时，在任何情况下，一个节点都不能可靠地声明自己是主节点。当DRBD文件系统发生这种情况时，正如一位用户报告的那样(http://bit.ly/1nbv4E)，两个节点都可以保持在线并接受写操作，从而导致不同的文件系统级更改。
短暂的故障可能导致长时间的停机。在一个Usenet帖子到novell.support。在cluster-services中，管理员报告运行Novell NetWare的双节点故障转移集群经历了短暂的网络中断。辅助节点最终关闭了自己，而主节点(尽管仍在运行)不再被网络上的其他主机访问。这篇文章继续详细介绍了与备份任务相关的一系列网络分区事件!
一位voldb用户报告说，经常有网络故障导致副本发散(http://bit.ly/1mDeC4d)，但也表明他们的网络日志中没有丢弃的数据包。因为这个集群没有启用裂脑检测，所以两个节点作为独立的主节点运行，导致大量数据丢失。
有时，没有人知道系统为什么分区。这次RabbitMQ的失败似乎是其中一种情况:很少重传，消息之间没有很大的间隔，节点之间没有明显的连接丢失(http://bit.ly/1qZROze)．将分区检测超时时间增加到两分钟可以减少分区的频率，但并不能完全阻止分区。
另一例EC2裂脑(http://bit.ly/1mDeIZA):当发现消息的交换时间超过3秒时，一个双节点集群“大约每10个初创公司中就有一个”无法聚合。因此，两个节点都将作为具有相同集群名称的主节点开始。由于ElasticSearch不会自动降级初选，裂脑一直持续到管理员介入。将发现超时时间增加到15秒解决了这个问题。
有一些零星的关于Windows Azure分区的报告，例如RabbitMQ集群的这个帐户每周进入split-brain (http://bit.ly/1sCN4Nw)．还有ElasticSearch的脑裂报告(http://bit.ly/U5xAFS)，但由于Azure相对于EC2来说是一个相对较新的产品，对其网络可靠性的描述是有限的。
我们将何去何从?
本文旨在作为一个参考点来说明，根据广泛的(通常是非正式的)描述，通信失败发生在许多现实环境中。进程、服务器、网卡、交换机以及本地和广域网络都可能发生故障，造成实际的经济后果。网络中断可能突然发生在已经稳定了几个月的系统中，在例行升级期间，或作为紧急维护的结果。这些中断的后果从延迟增加和临时不可用到不一致、损坏和数据丢失。脑裂不是一个学术问题:它发生在各种系统中，有时一连好几天。分区值得认真考虑。
另一方面，有些网络确实是可靠的。据大型金融公司的工程师们报道，尽管他们在设计能够优雅地容忍分区的系统上投入了大量精力，但他们的网络很少(如果有的话)表现出分区行为。谨慎的工程和积极的网络发展(加上大量的资金)可以防止中断。此外，在本文中，我们展示了故障场景;我们承认，要证明网络故障没有发生要困难得多!
然而，并不是所有的组织都能负担得起高可靠网络的成本或操作复杂性。从谷歌和Amazon(由于规模庞大，它们运营商品和/或低成本硬件)到仅靠微薄预算建立的单人初创公司，通信隔离网络故障是一种真正的风险，此外还有真实的分布式系统面临的各种其他故障模式(包括人为错误)。
在分区发生之前考虑这个风险是很重要的，因为在白板上就分区行为做出决定要比在生产环境中重新设计、重新设计和升级复杂系统容易得多，特别是当它向用户抛出错误时。对于某些应用程序，失败是这是一个选项，但你应该将其作为设计的一部分进行描述和明确说明。最后，考虑到额外的延迟1以及协调的好处4对于支持分区的设计，您可能会发现，在一般情况下，考虑这些分区也会带来好处。
我们邀请您贡献您自己的使用或不使用网络分区的经验。打开一个拉请求https://github.com/aphyr/partitions-post(顺便提一下，它包含了所有的参考资料)，留下评论，写一篇博客文章，或者发布一篇事后分析。数据将为这次对话、未来的设计提供信息，并最终为我们所依赖的系统的可用性提供信息．
相关文章
在queue.acm.org
今天的最终一致性:限制、扩展和超越
Peter Bailis和Ali Ghodsi
http://queue.acm.org/detail.cfm?id=2462076
抗脆弱组织
阿里尔Tseitlin
http://queue.acm.org/detail.cfm?id=2499552
自愈网络
罗伯特·普尔，克里夫·鲍曼和夏洛特·伯吉斯·奥本
http://queue.acm.org/detail.cfm?id=864027
参考文献
1.现代分布式数据库系统设计中的一致性权衡:CAP只是故事的一部分。电脑45(2 (2012)， 3742;http://dl.acm.org/citation.cfm?id=2360959．
2.亚马逊网络服务。2011年美国东部地区亚马逊EC2和亚马逊RDS服务中断总结;http://aws.amazon.com/message/65648/．
3.P. Bailis, A. Davidson, A. Fekete, A. Ghodsi, Hellerstein, J.M.和I. Stoica .高可用性交易:优点和限制。在VLDB 2014论文集(出现);http://www.bailis.org/papers/hat-vldb2014.pdf．
4.P. Bailis, Fekete, A.， Franklin, m.j.， Ghodsi, A.， Hellerstein, J.M.和Stoica, I.避免协调的数据库系统，2014;http://arxiv.org/abs/1402.2237
5.Bailis, P.和Ghodsi, A.今天的最终一致性:限制、扩展和超越。ACM队列11， 3 (2013);http://queue.acm.org/detail.cfm?id=2462076．
6.CityCloud, 2011;https://www.citycloud.eu/cloud-computing/post-mortem/．
7.戴维森，S.B，加西亚-莫利纳，H.和斯金，D.分区网络的一致性:一个调查。ACM计算调查17， 3 (1985)， 341370;http://dl.acm.org/citation.cfm?id=5508．
8.Dwork, C. Lynch, M.和Stockmeyer, L.部分同步存在下的共识。JACM 352 (1988);288323.http://dl.acm.org/citation.cfm?id=42283．
9.费舍尔，m.j.，林奇，n.a.，帕特森，M.S.一个错误过程的分布式共识的不可能性。JACM 32， 2 (1985)， 374382;http://dl.acm.org/citation.cfm?id=214121
10.Fog Creek软件公司。5月56日网络维护后验;http://status.fogcreek.com/2012/05/may-5-6-network-maintenance-post-mortem.html．
11.Gilbert, S.和Lynch, N. Brewer的猜想和一致的、可用的、允许分区的web服务的可行性。ACM SIGACT新闻332 (2002)， 5159;http://dl.acm.org/citation.cfm?id=564601．
12.吉尔，P.，贾恩，N.，纳加潘，N.理解数据中心的网络故障:测量、分析和影响。在SIGCOMM '11会议记录；http://research.microsoft.com/enus/um/people/navendu/papers/sigcomm11netwiser.pdf．
13.Github。2012年，Github本周可用;https://github.com/blog/1261-github-availability-this-week．
14.基尔霍夫纳，k，死亡的包裹;http://blog.krisk.org/2013/02/packets-of-death.html．
15.事后分析:上周的网络问题;http://www.freistil.it/2013/02/post-mortem-network-issues-last-week/．
16.纳拉扬，P.P.S.夏尔巴更新，2010年;https://developer.yahoo.com/blogs/ydn/sherpa-7992.html#4．
17.今天的停电事后分析，2013年;http://blog.cloudflare.com/todays-outage-post-mortem-82515．
18.Turner, D.， Levchenko, K.， Snoeren, A.和Savage, S.加利福尼亚断层线:了解网络故障的原因和影响。在SIGCOMM '10会议记录；http://cseweb.ucsd.edu/~snoeren/papers/cenic-sigcomm10.pdf．
19.为什么Twilio。计费事件分析:分解、分析和根本原因;http://www.twilio.com/blog/2013/07/billing-incident-post-mortem.html．
数字图书馆是由计算机协会出版的。版权所有©2014 ACM, Inc.
没有找到条目