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

云计算系统的容错和故障恢复(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，不出故障的概率是（1T/M）：N台机器在该时间内都不出故障的概率是(1T/M）的N次方；N台机器在该时间内恰好有1台出故障的概率是：（1T/M)的（N1）次方T/MN；N台机器在该时间内恰好有2台出故障的概率是:（1T/M）的（N2）次方*T/MT/M*N*（N1）/(21）因此，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.010的-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/（950MB)，约2230秒的时间，这将使得系统在较长时间内对外服务性能有明显下降。因此2个副本很少使用。云计算分布式架构综述传统的关系数据库由底层文件系统和上层表格系统构成，类似地,云计算也包含了分布式文件系统（如Google的文件系统GFS）和分布式表格系统(如Google的Bigtable)两个部分，其中分布式文件系统实现可靠、高效的数据存储和处理，分布式表格系统在分布式文件系统的基础上实现表的各种处理逻辑，例如查询、修改、扫描等。此外，鉴于开发和调试分布式程序有比较大的难度，实现高效的分布式程序挑战更大,因而云计算还有一个分布式计算系统（MapReduce)，通过它，云计算上的分布式程序开发变得易如反掌,运行效率却大大提升。MapReduce既可以运行在分布式的表格系统上，也可以直接运行在分布式文件系统上,达到很高的并行度，获得很好的效率。云计算系统常常是单一主控机（single master)+多工作机(many workers)模式,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 ： stringl 行（row)行（row)是二进制串，最大长度为64KB（实际应用中，大部分行字符串为10100字节）。对统一行内的数据的读或写总是原子的。分布式表格系统总是把整个表格按行(row）排序(字典序),然后按整行动态切分，每个切分后的块称为一个子表(tablet,在Google的Bigtable中，每个子表一般不超过256MB)，子表也是分布式表格系统的worker加载/卸载和负载平衡的基本单元。在网页库表格中，行（row）是网页的URL，但其中的域名部分被颠倒了，例如maps。l 列（column）列按列族（column family)分组，同一列族内的单元格的内容常常相同,并用修饰词（qualifier)区分不同的单元格，即column = “family：qualifier.一个表格内的列族个数是有限的（例如最多上百个）且一般由可打印字符组成，但修饰词（qualifier）的个数没有任何限制且可以是任意字符。例如,网页库表格中，content(网页内容）可以是一个列族，language(语言）可能是另外一个列族。出于进一步的性能优化的考虑，Bigtable还允许用户把内容相似或相关的列族组成局部群组（locality group)，同一局部群组内的列族的数据常常存放在一起，这样可以加快它们的访问速度；用户还可以把某些局部群组设定为装入内存，这样访问这些群组时就不需要访问磁盘。列族是权限控制的基本单元：有些用户可以添加新数据、修改已经存在的数据，有些用户只能读已经存在的数据，还有一些用户连已经存在的数据都不能读.局部群组则是数据压缩的基本单元，用户可以对不同的局部群组指定不同的压缩算法或者同一压缩算法的不同参数,等等；l 时间戳时间戳是64位整数，可以用来表示真正的时间（例如网页抓取的时间），这时它的单位是微秒，时间戳也可以是用户指定的任意值.Bigtable允许用户（针对列族）指定保存最新的多少个时间戳版本或者从现在起多长时间内的版本（如一周以内所有版本)，例如,在网页库表格中设置为保留最新的3个版本,超出的版本则被垃圾回收；Bigtable采用了3层B+树结构来存储表格数据,第三层为用户数据层（user data tablets)，第二层为元数据索引层(metadata tablets），用来索引用户数据tablets，第一层为根索引层（root tablet)，用来索引第二层数据.根索引层和元数据索引层的主要数据被设置为装入内存，应用程序需要访问用户数据时，Bigtable会根据需要依次访问root tablet和metadata tablets,这使得系统仅仅在访问用户数据时才访问磁盘。云计算的分布式表格系统是其中相对比较复杂的部分,这里以Bigtable为例做了十分简单的描述,后续文章还会有比较详细的叙述。