云计算系统的容错和故障恢复.doc

云计算系统的容错和故障恢复.doc

《云计算系统的容错和故障恢复.doc》由会员分享，可在线阅读，更多相关《云计算系统的容错和故障恢复.doc（7页珍藏版）》请在冰豆网上搜索。

云计算系统的容错和故障恢复

（1）

云计算属于分布式系统，许多因素导致系统异常：

首先，云计算系统由成百上千的节点组成，节点的失效是常事。

假如节点的平均无故障时间是3年，则一个1000节点的机群，平均每天可能有一个节点故障。

从商业成本来看，使用普通和主流的计算机（CPU，内存、网络、硬盘等）比高可靠计算机的性能/价格比更高，更何况无论多么可靠的计算机也会出现故障。

其次，电源、网络等其他硬件也会出现故障；第三，软件出故障的几率远远高于硬件；第四，各种人为因素，例如错误的操作，也导致故障。

由于这些因素，云计算系统需要很好地处理各种原因导致的故障，自动从故障中恢复，并且不影响运行中的上层的应用程序：

l        多副本的数据

云计算分布式文件系统保存了数据的多个副本（例如，GFS缺省保存3份），当某个副本失效后，分布式文件系统的master会在适当的时机启动副本复制，使得数据的副本数保持设定的数量，保证了数据的安全；

l        Worker故障

分布式文件系统的worker可能出现故障，master通过内置的heartbeat/lease监控所有worker的状态，一旦确认某个worker故障，master会把该worker保存的数据的副本个数减一，以便系统在适当时机启动副本复制以保证数据不会丢失；

l        Master故障

为了避免master成为系统的单点，master也有多个副本：

其中一个是主master，其余为辅master，主master承担着master的职责，例如应答用户和worker的请求，记录操作日志等；辅master通过操作日志保持与主master的准同步。

当主master发生故障后，在分布式选举协议作用下，一个辅master会升级成为主master，保证系统的继续运行；

l        应用程序容错

出于容错和故障恢复的原因，云计算系统的上层应用程序不能假设它正在或将要使用哪个worker，也不能假设数据存储在或将要存储到哪个worker上，当应用程序需要使用数据时，云计算客户端库将询问云计算系统的master获得数据副本所在的位置，并向其中一个副本（通常是与该客户端网络“距离”最近的）发出数据请求，如果该worker在开始或者中途出现故障或因为其他原因无法完成该请求，则云计算客户端库会自动转向另外一个副本，这对上层应用是完全透明的。

云计算系统的容错和故障恢复

（2）

在前一篇文章中，我谈到了云计算采用了数据多个副本（缺省是3），除了应对各种软件硬件故障外，多个副本还提高了云计算系统数据读服务能力：

每个副本都可以独立提供读服务，由于多个副本通常分布在不同的网络交换机上，因此网络带宽得到更充分的利用。

与此同时，多个副本增加了数据写入的成本：

写入数据时要同时在多台机器上写入，占用了更多的磁盘空间，传输数据要跨多个网络交换机。

由于通常情况下数据的读出次数远多于写入次数，这样获得了更好的整体性能。

一个问题是：

为什么缺省用3个数据副本而不是2个或4个？

让我们用一个非常简化的模型来分析使用3个副本时数据的可靠性如何，或者说，数据丢失的可能性有多大。

为了简单起见，让我们把问题局限在节点计算机上，假设总共有N个节点计算机，它们的平均无故障时间都是M，云计算系统对一个数据副本丢失并进行复制的时间为T，则一台计算机在T时间内出故障的概率是T/M，不出故障的概率是（1-T/M）：

N台机器在该时间内都不出故障的概率是（1-T/M）的N次方；

N台机器在该时间内恰好有1台出故障的概率是：

（1-T/M）的（N-1）次方*T/M*N；

N台机器在该时间内恰好有2台出故障的概率是：

（1-T/M）的（N-2）次方*T/M*T/M*N*（N-1）/（2*1）

因此，N台机器在该时间段内至少有两台机器故障的概率是：

P2（N,M,T）=1-都不出故障的概率-恰好1台出故障的概率

因此，N台机器在该时间段内至少有两台机器故障的概率是：

P3（N,M,T）=1-都不出故障的概率-恰好1台出故障的概率--恰好2台出故障的概率

因此假如N=1000，M=50,000小时，T=600秒，则

P2（N=10台，M=50,000小时，T=600秒）=5.0*10的-10次方；

P2（N=1000台，M=50,000小时，T=600秒）=6.1*10的-9次方；

P2（N=5000台，M=50,000小时，T=600秒）=1.4*10的-4次方；

P3（N=10台，M=50,000小时，T=600秒）=4.5*10的-15次方；

P3（N=1000台，M=50,000小时，T=600秒）=6.2*10的-9次方；

P3（N=5000台，M=50,000小时，T=600秒）=7.6*10的-7次方；

可以看出，当机器数量达到5000台时，至少3台机器出故障的概率低于百万分之一，而至少两台机器出故障的概率高于万分之一。

因此采用3个数据副本时数据有比较高的可靠性。

当机器数量较小时，例如10台时，至少两台机器出故障的概率也是很低的，但是，如果采用2个副本，则当一台机器出现故障时，则该机器上保存的数据都变成单副本，因此云计算系统需要马上做出反应，复制这些数据以避免再有一台机器故障时导致的数据丢失。

假如该计算机上保存了1TB数据，则即使剩下9台机器每秒复制50MB数据，则仍然需要1TB/（9*50MB），约2230秒的时间，这将使得系统在较长时间内对外服务性能有明显下降。

因此2个副本很少使用。

云计算分布式架构综述

传统的关系数据库由底层文件系统和上层表格系统构成，类似地，云计算也包含了分布式文件系统（如Google的文件系统GFS）和分布式表格系统（如Google的Bigtable）两个部分，其中分布式文件系统实现可靠、高效的数据存储和处理，分布式表格系统在分布式文件系统的基础上实现表的各种处理逻辑，例如查询、修改、扫描等。

此外，鉴于开发和调试分布式程序有比较大的难度，实现高效的分布式程序挑战更大，因而云计算还有一个分布式计算系统（MapReduce），通过它，云计算上的分布式程序开发变得易如反掌，运行效率却大大提升。

MapReduce既可以运行在分布式的表格系统上，也可以直接运行在分布式文件系统上，达到很高的并行度，获得很好的效率。

云计算系统常常是单一主控机（singlemaster）+多工作机（manyworkers）模式，worker实现数据的存储、读写、分析处理等，master保存部分或全部元数据、实现worker的任务分配、状态监控、负载平衡、故障监测和故障恢复等。

Master常常使用heartbeat+lease或类似机制监控worker的状态，向worker定期发放lease，worker在lease有效期（例如几秒到几十秒）内才进行工作，lease失效后则停止工作。

如果master发现某个worker在过去一段时间内没有响应或者出现其他异常，则不再向该worker发放新的lease，并在旧的lease到期后重新分配该worker上的任务。

这使得master得以发现有故障的worker并将其从系统中剔除，并在适当的时候采取措施以避免数据丢失或者任务失败等等，也使得系统管理员不需要进行任何额外的操作就可以下线部分worker（例如机器维护、软件硬件升级、机器淘汰等等）。

如果没有其他措施，则云计算系统的单一master会成为整个系统的单点。

为了避免这种现象的出现，云计算系统通常还有一个分布式选举系统（例如Google的Chubby），master也不再是单一master，而是单一主master+几个辅master，辅master保持着对主master的准同步，一旦主master故障，则其中一个辅master会被选举并升级成为主master。

这种选举和升级通常需要若干秒的时间，但由于worker在lease有效期内即使没有master也会继续工作，且应用程序对master的访问通过名字而不是IP地址，因此上层应用程序通常看不到这种切换，或者是一个短暂的停顿。

以上只是对云计算分布式架构的一个简单描述，在后续的文章中我还会对各个部分进行较为详细的说明。

云计算之分布式文件系统

云计算的分布式文件系统（如Google的GFS）是整个云计算的基石，提供上层表格系统所需的可靠和高效的数据存储，假设是：

l        容错与自动故障恢复是DNA

整个文件系统由许多廉价计算机组成，机器故障是常事而非例外，系统需要不停地进行自我检测和监控，发现故障机器并自动恢复；

l        系统存储大文件而非小文件

整个文件系统存储数百万数千万的100MB或更大尺寸的文件，而不是数十亿的KB尺寸小文件，支持对小文件的创建、读写，但不高效；

l        文件的主要修改是追加

文件系统支持高效的大尺寸数据追加，特别是来自多个用户的无锁并发追加，小尺寸的数据追加和数据的改写也支持，但不高效；

l        高效的大尺寸顺序读

大尺寸的顺序读数据十分高效，小尺寸随机读相对比较低效；

l        持续可用的网络带宽比低的单次读写延时更加重要

多数上层应用程序对数据吞吐量有较高的要求，但对单次读写时间没有很高的要求。

保持持续可用的网络带宽比保证每次读写的低延时有更大的意义。

在云计算的分布式文件系统中，数据被分成固定大小的块，即chunk（在GFS中是64MB）。

由于可靠性和性能的需求，每个chunk在系统中有若干份拷贝（缺省是3份），保存在不同的worker上。

此外，这3份拷贝通所在的worker通常位于不同的机架和不同的网络交换机，因此一个机架或交换机故障不会导致数据不可用。

把多个拷贝分布到不同交换机上进一步提高了数据读出的可用网络带宽，增加了数据读出的性能，但却增加了写入时在不同交换机之间传输的数据量，增加了写入成本，由于数据的读远远多于对数据的写，这种做法提高了系统的总体性能。

与云计算架构的其他子系统一样，云计算的分布式文件系统采用了“单一master+多个worker”的结构，其中worker保存chunk数据的拷贝，master保存了文件和目录的名字空间、文件到chunk的映射、当前worker列表、chunk拷贝在当前worker上的分布等。

此外，master还记录了worker的chunk数据大小、可用磁盘空间、数据读写次数等，并在必要的时候进行chunk迁移以便实现负载的相对平衡。

云计算的分布式文件系统还提供了客户端库，应用程序通过客户端库访问文件数据。

例如，当客户端需要读出一个文件从某个位置开始的数据时，客户端库通过询问master获得该文件的指定位置所在的chunk以及该chunk所在的worker列表，客户端库再向其中的一个worker（通常是离该客户端网络距离最近的worker）发起读chunk（指定的偏移值和指定的长度）的请求，worker读出指定的数据后返回给客户端库，客户端库再返回给应用程序。

以上对云计算的分布式文件系统做了一个大致描述，后续文章还有更多的叙述。

云计算之分布式表格系统

云计算的分布式表格系统依赖于下层的分布式文件系统（如Google的GFS）提供可靠和高效的数据存储，也是分布式文件系统的主要使用者。

本文以Google的Bigtable为例来介绍云计算的分布式表格的基本结构，其数据模型是：

（row:

string,column:

string,time:

int64）->value:

string

l        行（row）

行（row）是二进制串，最大长度为64KB（实际应用中，大