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

云计算系统的容错和故障恢复(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