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

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

云计算属于分布式系统,许多因素导致系统异常：首先，云计算系统由成百上千的节点组成,节点的失效是常事。假如节点的平均无故障时间是3年，则一个1000节点的机群,平均每天可能有一个节点故障。从商业成本来看，使用普通和主流的计算机(CPU，内存、网络、硬盘等)比高可靠计算机的性能/价格比更高，更何况无论多么可靠的计算机也会出现故障。其次，电源、网络等其他硬件也会出现故障；第三，软件出故障的几率远远高于硬件；第四，各种人为因素，例如错误的操作，也导致故障。由于这些因素，云计算系统需要很好地处理各种原因导致的故障,自动从故障中恢复,并且不影响运行中的上层的应用程序：

l多副本的数据
云计算分布式文件系统保存了数据的多个副本（例如，GFS缺省保存3份)，当某个副本失效后，分布式文件系统的master会在适当的时机启动副本复制，使得数据的副本数保持设定的数量,保证了数据的安全;
lWorker故障
分布式文件系统的worker可能出现故障，master通过内置的heartbeat/lease监控所有worker的状态，一旦确认某个worker故障，master会把该worker保存的数据的副本个数减一,以便系统在适当时机启动副本复制以保证数据不会丢失；
lMaster故障
为了避免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台机器出故障的概率低于百万分之一，而至少两台机器