What Bugs Live in the cloud?（翻译）

What Bugs Live in the cloud?

参考文献：Gunawi H S, Hao M, Leesatapornwongsa T, et al. What Bugs Live in the Cloud? A Study of 3000+ Issues in Cloud Systems[C]// ACM, 2014:1-14.

1.介绍

1.3 Findings

块中的新bugs：经典的产生问题的方面是可靠性、性能和可用性等类别。先发现了一种新的，衡量云系统的类别：数据一致性、可伸缩性和topolog bugs。

杀手锏级的bugs：从研究大规模问题中得出，killer-bugs能影响大多数节点或整个集群。可能在一个微弱的方面，它们的存在就会使得级联式的失败。

硬件方面的失败：13%的问题来源于硬件失败。硬件可能会在任何时间以停止、损坏或者跛行limp的方式失败。在软件层来修复硬件失败是一个挑战。

令人恼火的软件bugs：每种问题可能导致各种类型的错误。

可行性第一，正确性第二：用户更加偏好可行性而不是正确性。例如，我们可能会忽略一些不一致、低等级的错误、碰撞等，以便系统能够继续运行。这是非常危险的，因为未来可能发生一些意想不到的结果，也许运行不正确的看起来好过停机。用户通常是根据明确的性能或者可用性度量来分析的，而不是未定义的度量。

多维可靠性工具的需求：每种错误都可能导致很多可能的结果，反之亦然。故障查找工具不应该只是一个维度的。例如，基于失败操作捕获错误处理失误的工具是不完整的工具。 错误处理错误会引起各种含义（第6.1节）。 同样，如果一个系统试图确保在一个轴上完全可靠（例如，没有数据丢失），则系统必须部署所有可以捕获所有硬件和软件问题的错误查找工具（§7）。 此外，我们发现许多错误是由于不仅一个而是多种类型的问题造成的。 一个主要的例子是分布式数据竞争与失败（§6.3）; 其结果是数据竞争检测器必须包括故障注入。

总之，我们对大规模的云系统的错误进行研究，我们将在论文中提出的有趣发现。 我们公开发布了CBSDB[9]以使云社区受益。 最后，据我们所知，我们对云系统进行了迄今为止最大的bug研究。’

在下面的章节中，我们首先描述我们的方法（§2），然后根据方面（§3），错误范围（§4），硬件问题（§5），软件错误（§6）和 含义（§7）。 然后，我们演示CBSDB的其他用例（§8），讨论相关工作（§9）和结论（§10）。

2.方法论

目标系统：选择了六种流行并且很重要的云系统架构：

Hadoop MR： 代表了分布式框架（注：有两个库，一个是开发架构，包括lib，UI框架等，另一个是系统问题，本文使用的是第二个）

HDFS：可伸缩的文件系统

HBase、Cassandra: 分布式Key-value存储（NoSQL系统）

Zookeeper：协调服务

Flume： 流式系统

问题库：目标项目都由Apache进行托管，每个项目都有一个高度组织的问题库。每个库都包含主要由开发者提交的开发和部署问题，有时由更大的用户社区提交。这里的“问题”指的是bugs和新特性。

对于每个问题库存在着很多的新标签，“发布时间、解决时间、bug的重要程度、补丁可用性和回复数量”。根据回复标签，回复的内容富含着大量的信息。一个复杂的问题通常由很长的讨论。bug的重要程度标签一共有五种属性，没价值、次要、主要、关键、阻塞五种。我们将前2种划分为次要，后三种划分为重要。本文主要关注重要的问题。

问题分类： 

第一个分类是 问题类型：冗杂或者重要。

重要问题：开发与部署问题

不重要：代码维护、重构、单元测试、文档、很容易解决的bugs

作者对bugs进行了额外的手动分类，因为有的开发者会把不重要的问题标记为重要。重要的问题会进行再一次的分类，不重要的则直接跳过。

如果问题包括硬件问题，则增加硬件类型和失败模式。

然后我们确切的指出软件bug类型。最终增加“含义”标签。

一个问题可能含有多个标签，一个bug可能影响到多个机器甚至是整个集群。所以增添了bug scope标签。

此外，还增加了bug所在位置的标签。

Cloud Bug Study DB （CBSDB）

分类的结果存储在CBSDB中，包括一系列的生数据、数据挖掘脚本和图形工具，能够对云问题进行质与量的分析

2011.1.1-2014.1.1 CBSDB囊括了21,399个问题，标记出了3655个重要的问题。一共对于重要问题加注了25,309个标签。

有效性威胁：每个问题被过了至少两遍。

如果出现异议，则进行讨论。

每个问题都有3-4个人进行讨论。

论文声明：

以下章节按问题分类组织（表1）。 

所有讨论的bugs和图表只来自重要的问题。

对于每个分类，我们提出定量和定性的结果，并进一步介绍子分类。

对于每个分类，我们引用一些有趣的问题作为脚注（例如m2345）。 脚注包含超链接; 感兴趣的读者可以点击链接阅读开发者的更多讨论。

缩写：“bugs／issues”意味着至关重要的问题

“系统”意味着对我们的目标系统的一般参考

“主要协议”意味着面向用户的操作（例如读/写） 

操作协议“意味着诸如背景守护进程（例如，闲话）

管理协议（例如，节点退役）之类的非主要协议

3.问题方面

3.1可靠性、性能、可用性

（CAP

Consistency：所有节点在同一时间看到的是同样的数据

•  Availability：确保每个请求收到成功还是失败的回应

•  Partition Tolerance：系统无视偶然的消息丢失持续运行，错误容忍度）

问题：可靠性（45%）、性能（22%）、可用性（16%）

3.2数据一致性方面

数据一致性意味着：所有节点和副本有一样的数据值或者最终达成一致。

（一致性又可以分为强一致性与弱一致性。

强一致性可以理解为在任意时刻，所有节点中的数据是一样的。同一时间点，你在节点A中获取到key1的值与在节点B中获取到key1的值应该都是一样的。

弱一致性包含很多种不同的实现，目前分布式系统中广泛实现的是最终一致性。

所谓最终一致性，就是不保证在任意时刻任意节点上的同一份数据都是相同的，但是随着时间的迁移，不同节点上的同一份数据总是在向趋同的方向变化。也可以简单的理解为在一段时间后，节点间的数据会最终达到一致状态。）

有5%的情况下，（是指在所有案例中吗？应该是指在调查的案例中）用户得到陈旧的数据或者系统不稳定。

原因：操作协议中的逻辑错误、数据竞争和故障处理问题。

操作协议漏洞百出：读、写、bootstrap（引导程序）、cloning、fsck（file system check）等操作协议都会影响到数据一致性。

例如，Cassandra中，在bootstrapping时，cassandra应该从多个邻居节点取回多副本来保证key等一致性，但是对于协议bug，只取回最邻近节点的副本。

（Gossip协议）

cross-DC跨数据中心

HBase由于在clone操作中的连接问题，元数据被克隆，数据没有被克隆。

（解释：A snapshot is a set of metadata information that allows an admin to get back to a previous state of the table. A snapshot is not a copy of the table; it’s just a list of file names and doesn’t copy the data. A full snapshot restore means that you get back to the previous “table schema” and you get back your previous data losing any changes made since the snapshot was taken.

metedata：元数据（Metadata），又称中介数据、中继数据，为描述数据的数据（data about data），主要是描述数据属性（property）的信息，用来支持如指示存储位置、历史数据、资源查找、文件记录等功能。）

还有很多种情况会使云系统中已经被删除的数据被认为是有效的，丢失一些交易日志，忘记擦除一些函数中的存储值，导致数据过时。

并发性的错误和节点故障：节点内的数据竞争也是数据不一致的一个重要原因。

例如：在缓存内更新数据的读写速度不一致也会导致将旧数据写入缓存中。

复杂的异步消息重新排序加上节点故障也会使系统进入不正确的状态。

Zookeeper 在不同的节点提交交易会有不同的结果。

（Zookeeper提供的一致性是弱一致性,首先数据的复制有如下规则:zookeeper确保对znode树的每一个修改都会被复制到集合体中超过半数的机器上。那么就有可能有节点的数据不是最新的而被客户端访问到。并且会有一个时间点,在集群中是不一致的.）

总结：相比较于主要协议，操作协议的测试更少，可能包含的错误更多。当云系统检测到数据不一致的时候，开发者往往会让它们继续运行。似乎可用性比一致性要更重要。

3.3可拓展性方面

可拓展性方面的问题占据云系统问题的2%。（也许是因为在小规模的测试中很难发现这一类的问题）在这个类别中，软件优化（29％），空间（21％）和负载（21％）是主要的根源。 在应用方面，性能问题（52％），组件停机时间（27％）和失败操作（16％）占主导地位。 为了更深入地了解根本问题，我们将可扩展性问题分为四个规模：集群规模，数据大小，负载和故障。

集群规模：算法协议必须对集群大小进行预测，算法可以是节点数量的二次方或者三次方。例如，在Cassandra，当一个节点改变其环的位置，其他受到影响的节点需要重新执行复杂度为（n^3）的计算。如果节点的数量很多，如100·300，这有可能导致CPU爆炸或者整个集群崩溃，需要重新手动重新集群。

弹性往往不能彻底的测试; 系统管理员认为他们可以解除/重新调用任意数量的节点，但这可能是致命的。举个例子，在HDFS中，当大量的节点被淘汰和重新投入使用时，大量的额外负载（数百万个被迁移的块和日志消息）使关键服务陷入困境。

数据大小：在大数据时代，云系统必须预测大数据量，但通常不清楚这个限制是什么。 例如，在HBase中，由于查表操作的效率低下，打开一个大于100K的大表需要几十分钟的时间。

在HDFS中，引导协议不会根据提交日志段数，块数（可能为数百万个）和节点间重新启动消息进行扩展。 整个群集重启可能需要几十分钟。同样在HBase中，日志清理过程是日志文件数量的O（n2）， 这个缓慢的过程导致HBase在服务传入请求方面落后。 我们还发现用户在大型数据上提交查询情况可能会导致服务器端的OOM（out of memory 内存溢出）。 在这里，用户必须将大型查询分解成更小的部分（第6.5节）。

请求负载规模：云系统有时不能提供各种类型的大型的请求负载。 例如，一些HDFS用户创建了数千个并行的小文件，导致OOM; HDFS并不期望这种情况，因为它针对的是大文件。

在Cassandra中可以删除一系列可能会阻滞其他重要数据块的

失败规模：在规模上，大量的组件可以同时失败，但是往往不能同时恢复。 例如，在MapReduce中，由于与HDFS的未优化通信，恢复16,000个失败的mapper（如果AM停机）需要7个多小时。 在另一种情况下，当大量的reducer报告失败时，任务2h内不会重新启动，（由于阈值错误）。另外，当MapReduce遇到任务失败的时候，复杂度为O（n3）的计算（3次for循环）被放大了。 在ZooKeeper中，当1000个客户端由于网络故障而同时断开连接时，由于心跳响应的延迟，会话关闭流会导致其他实时客户端断开连接。（参考：http://cailin.iteye.com/blog/2014486/）

总结：主要的读/写协议往往是健壮的，因为它们一直由实时用户工作负载进行隐式测试。 另一方面，操作协议（恢复，启动等）经常带有可扩展性错误。 因此，操作规程需要经常进行大规模的测试。通用的解决方案，如松散耦合，去中心化，批处理batching和节流throttle是受欢迎的，但有时它们是不够的; 有些问题需要修复特定的算法。

Topology方面：

在一些情况下（1％），云系统的协议在某些网络拓扑上无法正常工作。 我们称之为拓扑bug; 他们也很有趣，因为他们通常在部署前看不见。 下面我们描述三个与拓扑错误有关的问题。

跨数据中心（Cross-DC data center）最近，地理分布式系统已经普及[37,47,56]。在这种情况下，通信延迟较高，因此不同步是一个基本属性。然而，一些协议本质上仍然是同步的（例如，Cassandra的传送可能需要一天的时间，并且延迟一个跨数据中心的部署）。

例如在HBase中，两个数据中心进行无限制的ping-pong请求，由于两个数据中心之间

的数据漂移，导致时间以来操作失败。

机架感知：一些操作协议（如恢复）不能感知机架。例如，当一个mapper和一个reducer通过一个flaky片连接跑在不同的机架上，MR总是认为mapper是有问题的，并列入黑名单。MR然后重新跑在同一个机架上跑mapper，最后机架上的所有节点都是不正确的，并被列入黑名单。一个更好的恢复方法是准确的识别跨机架网络问题。在HDFS的两个机架等场景中，如果一个namenode和一个datanode-1在机架A，客户端和datanode-2在机架B，并且跨机架饱和，则namenode将降级datanode-2 ，从而迫使客户端通过datanode-1进行连接，尽管在这种拓扑结构中，机架B中的客户端和datanode-2之间的通信更加优化。

（？？？为什么降级就能优化）

新的分层体系结构：随着云系统的成熟，其体系结构也在不断发展（例如，Cassandra中添加了虚拟节点，而HDFS中则添加了节点组）。架构的改变不总是和受影响的协议相一致。例如，在Cassandra中，具有虚拟节点(vnode)的集群拓扑和规模突然改变，但是许多Cassandra协议仍然采用物理节点拓扑结构( gossip协议不能处理gossip消息的数量级增加

)，导致许多可扩展性问题.在HDFS中，节点组导致许多协议更改，如故障转移，平衡，复制和迁移。

总结：用户希望云系统可以在许多不同的拓扑结构（即不同数量的节点，机架和数据中心，不同的网络条件下）上正常运行。拓扑相关的测试和验证仍然很少，应该成为未来云可靠性工具的重点。另一个重点是相关的拓扑架构的变化通常不会导致受影响的协议的直接改变。

3.5 QoS（quality of service）方面

QoS是多租户系统的基本要求[46,49]。我们研究中的QoS问题相对较少（1％）。

水平/系统内QoS：关于影响其他操作的繁重操作有许多问题，开发人员可以使用经典技术（如准入控制，优先级划分和限制）来快速修复。但是，在一个协议中引入阈值时必须小心，因为它会对其他协议产生负面影响。例如，在HDFS中，在流级别调节会导致请求在RPC层排队。（注：Remote Procedure Call Protocol远程过程调用）

垂直/跨系统的QoS：这是QoS的最大挑战;开发人员只能控制自己的系统，但可堆叠的云系统需要端到端的QoS。例如，HBase开发者提出了如何在HDFS或MapReduce层转化HBase层的QoS的问题。此外，一些技术（如调节）难以一直执行到操作系统级别（例如，磁盘QoS涉及许多度量标准，如带宽，IOPS或延迟）。也讨论了缺乏对QoS精度控制的影响（例如，当开发人员无法控制Java GC时很难保证QoS）。

结论：横向QoS更容易保证，因为它只涉及一个系统。云系统必须检查在一个协议中QoS的执行不会对其他协议造成负面影响。垂直的QoS似乎遥不可及;开发者没有端到端的控制权，也没有提出许多跨系统的QoS提议[46]。越来越多的挑战是开源云系统不是天生就具有QoS，而且很可能必须从根本上改变。

4.致命的bugs

致命性的bugs指的是可能会影响到多节点甚至是整个集群的bug。尽管社区推广无单点失效原则，但实际上SPoF（single point of failure）仍实际存在。

一个正反馈回路：这种情况下，故障发生，然后恢复开始，但恢复引入更多的负载，因此更多的故障[29,32]。例如，在cassandra，gossip 流量在规模上显着增加，导致群集不稳定几个小时。由于存活的节点被错误地宣告死亡，管理员或弹性工具可能会向集群添加更多节点，从而导致更多的gossip流量。云系统应该更好地识别正反馈回路。

程序错误buggy故障转移failover：

Buggy故障转移：no-SPoF的关键是检测故障并执行故障转移。但是，如果故障转移代码本身是错误的，这种保证会中断。例如，在HBase中，当元数据区域服务器的故障切换出错时，整个集群停止工作，因为整个集群元数据（META和ROOT表）不可访问;有趣的是，我们看到这个问题在我们的研究中重复了四次。同样，在HA-HDFS中，当故障转移到备用名称节点时，所有datanode都变得无法访问。我们深入的分析表明，当故障转移遇到另一个故障时，故障转移代码中的错误将会出现简而言之，故障转移中的故障转移是脆弱的[25]。当受影响的组件是SPoF（例如，主节点，元数据表）时，越野车故障转移是一个致命错误。

故障转移后重复的错误：no-SPoF的另一个关键是成功的故障转移后，系统应该能够恢复先前失败的操作。如果原因是机器故障，这是真实的，但是对于软件错误则不是这样。换句话说，如果在故障转移之后，系统必须再次运行相同的错误诊断逻辑，那么整个过程将重复，整个集群最终将死亡。例如，在HBase中，当区域服务器由于损坏的区域文件的错误处理而死亡时，HBase将故障转移到另一个运行相同代码的活动区域服务器，并且也将死亡。重复这一过程，所有区域服务器都将脱机。在我们的研究中，我们看到这个问题重复了三次。类似的问题发生在区域服务器遇到不同类型的问题，如日志清理异常。为了减少这些杀手级漏洞的严重程度，云系统必须区分硬件故障和软件逻辑错误。在后一种情况下，最好是停止故障切换而不是放任故障切换杀死整个集群。

单点故障的小窗：没有单点故障的另一个关键是始终准备好故障转移。研究发现，其中一些操作任务简要地禁用了故障转移机制。例如，在ZooKeeper中，在动态集群重新配置期间，心跳监视被禁止，如果leader在这一点挂起，则不能选出新的leader。

启动代码出错：启动大型系统通常是一个复杂的操作，如果启动代码失败，那么所有的机器都是不可用的。例如，ZooKeeper leader选举协议容易出错，可能导致没有leader被选中;没有leader，ZooKeeper集群无法正常工作。同样，我们发现HDFS namenode启动协议的问题。

分布式死锁：我们的研究还发现了有趣的分布式死锁情况，其中每个节点正在等待其他节点的进展。例如，在Cassandra的启动过程中，所有节点都不会进入正常状态，因为他们保持gossip。这种协调死锁也发生在其他Cassandra协议中，如迁移和压缩，通常是由消息重新排序，网络故障或软件错误引起的。分布式死锁也可能由“无声挂起”引起（更多在§6.4）。例如，在HDFS中，一个节点上的磁盘挂起会导致整个写入管道挂起。捕捉本地死锁是具有挑战性的[51]，分布式死锁更是如此。

可扩展性和服务质量缺陷：第3.3节和第3.5节介绍的例子强调可扩展性和QoS缺陷也会影响整个集群。

总结：no-SPoF的概念不仅仅是简单的故障转移。 我们的研究揭示了许多可能使整个群集（潜在的数百或数千个节点）瘫痪的killer bugs。 在离线测试和在线失败管理中，killer bug应该得到更多的关注。

5.硬件问题

故障停机：云系统配备了各种机制来处理故障停机故障。有几个原因说明故障停机恢复不是繁琐的。首先，交织事件和故障（例如，节点上下，消息重新排序）可以迫使系统进入意外状态（更多在第6.3节）。使用协调服务不会简化问题（例如，HBase中的ZooKeeper使用）（例如，许多跨系统问题;更多在§8中）。如前所述，一系列的多重失败往往得不到妥善处理，可能发生大规模的失败（§3.3，§4）。

损坏：众所周知，硬件可能会破坏数据，因此部署了端到端的校验和。但是，校验并不是万能的。我们发现检测正确但不能恢复的情况（例如，HDFS恢复意外删除健康副本并保留损坏的副本）。软件错误也可能使所有数据副本损坏，使得端到端的校验和无关紧要。我们还发现一个有趣的情况，一个坏的硬件产生误报，导致健康的文件标记为损坏，并引发不必要的大数据恢复。