引言:云计算与高可用性
云计算是互联网时代信息基础设施与应用服务模式的重要形式。据高德纳公司(Gartner)的数据,2017年,世界范围的公有云服务市场总量达到2468亿美元,国内市场容量为1174.12亿美元。云计算在人们的生活和工作中扮演越来越重要角色的同时,其在可用性方面的不足日益成为一个亟待解决的问题。2013年8月16日,谷歌的云服务由于故障下线5分钟,导致互联网流量瞬间下降40%,造成55万美元的损失[1];而亚马逊在2013年发生故障,导致Instagram等著名网站有59分钟无法访问。仅在2013年上半年,大型公有云服务发生故障的次数就超过了10次。据统计,发生一次故障,对于小型企业造成的损失大于5.5万美元,对中型企业的损失超过9万美元,而对大型企业的损失则超过数百万美元。
表1 2016上半年部分云服务故障
云服务 | 时间 | 影响 |
推特 | 2016.1.19 | 网页和移动端服务下线8小时 |
微软 | 2016.2.22 | 部分Office 365用户无法正常访问 |
软营 | 2016.3.3 | 部分欧洲客户CRM故障10小时 |
赛门铁克 | 2016.4.11 | 所提供的云安全服务下线24小时 |
谷歌 | 2016.4.11 | 谷歌云平台服务下线18分钟 |
软营 | 2016.5.10 | 删除4小时的用户数据 |
苹果 | 2016.6.2 | 云服务故障影响零售和备份服务 |
亚马逊 | 2016.6.4 | 断电导致EC2服务故障10小时 |
在数据中心和云计算环境中,高可用性和容错能力对于基于网络的客户端和服务器系统至关重要。在《云计算标准白皮书》中[2],将服务的可用性列为云计算的六大挑战之首;在国际数据公司(IDC)对全球范围云计算用户的调研中,可用性是用户关心的第二大问题[3]。云计算的高速发展使得越来越多的关键应用也开始被部署到云端,系统的可用性,特别是应用透明的虚拟机的可用性,就自然成为虚拟机适用性的另一个重要指标。
在虚拟化系统范畴中,高可用(High Availability, HA)是指虚拟化系统的计算环境(包括软硬件)能达到尽可能少的宕机时间。高可用性的指标可以用服务级别协议(Service Level Agreement, SLA)来量化。工业界有两种方法来测量服务级别协议,分别是故障发生到恢复的时间以及两次故障之间的时间。大多数情况下,第一种测量方案被广泛采用,具体指标如表2所示。
表2 系统可用性指标
系统可用性 | 宕机时间/年 | 宕机时间/月 | 宕机时间/周 | 宕机时间/天 |
90% | 36.5天 | 72小时 | 16.8小时 | 2.4小时 |
99% | 3.65天 | 7.20小时 | 1.68小时 | 14.4分 |
99.9% | 8.76小时 | 43.8分 | 10.1分钟 | 1.44分 |
99.99% | 52.56分 | 4.38分 | 1.01分钟 | 8.66秒 |
99.999% | 5.25分 | 25.9秒 | 6.05秒 | 0.87秒 |
影响一个系统可用性的因素非常多,包括软件设计、硬件设施、第三方服务等。正如服务级别协议的定义,这不仅仅是一个技术指标,还是服务提供商和用户之间的契约。导致服务不可用的因素分为两种,一种是无计划的,另一种是有计划的。无计划因素包括系统级故障(操作系统、网络、电源以及外围设备等)、数据故障(误操作、硬盘故障、网络故障等)、自然灾害、人为破坏等。有计划因素包括日常任务(备份、安全管理等)、运维相关、升级相关等。
一般来说,一个系统要达到高可用性,需要做好如下设计:(1)对软硬件做冗余,以消除单点故障;(2)故障检测和恢复;(3)需要可靠的交汇点。其中,冗余节点最大的难题就是对于有状态的节点的数据复制和数据一致性的保证。如果系统的数据镜像到冗余节点是异步的,那么在故障恢复的时候就会出现数据差异的情况;如果系统的数据镜像到冗余节点是同步的,那么就会导致冗余节点越多性能越慢的问题。所以,很多高可用系统都是根据系统需求在做各种取舍。例如,数据中心中有多种高可用技术解决方案,如表3所示。这也验证了著名的CAP理论,即对于一个分布式计算系统来说,不可能同时满足一致性、可用性、分区容错性。
备份 | 主从备份 | 多主备份 | 两阶段提交 | Paxos | |
一致性 | 弱 | 最终 | 最终 | 强 | 强 |
事务性 | 不支持 | 全部 | 本地 | 全部 | 全部 |
延迟 | 低 | 低 | 低 | 高 | 高 |
吞吐量 | 高 | 高 | 高 | 低 | 中等 |
数据丢失 | 许多 | 一些 | 一些 | 无 | 无 |
故障恢复 | 宕机 | 只读 | 读写 | 读写 | 读写 |
对于最终一致性,在宕机的情况下,会出现没有完成数据的完全同步的情况,因此会出现数据差异性。而对于强一致性,要么使用性能比较慢的两阶段提交的方案;要么使用性能比较好、但实现比较复杂的Paxos协议。另一方面,目前能提供虚拟化服务的厂商均能够实现较为完备的平台高可用性解决方案。例如VMWARE vSphere平台的高可用技术,通过配置多台ESXi服务器构建群集,结合硬件设备、网络、存储等多个层面的冗余实现平台层面的高可用,为虚拟化平台中运行的应用程序提供快速中断恢复和容错保障。vSphere高可用技术通过在主机出现故障时重启虚拟机来为虚拟机提供基本级别的保护,缺点是存在非计划宕机时间,影响业务的连续性。vSphere平台中的容错(fault tolerance)技术通过创建和维护与主虚拟机相同、且可在发生故障切换时随时替换主虚拟机的辅助虚拟机,来确保虚拟机的连续可用性,获得比vSphere更高级别的可用性和数据保护。
现有虚拟化高可用性技术与方案
冗余是解决虚拟化系统高可用性和容错性的不二选择。硬件冗余方案,比如惠普公司的不间断服务器,使用了冗余组件和特定的系统设计,但是由于它的价格特别昂贵,并没有被大规模推广。传统软件方案在多台机器上同时运行相同的工作负载,并且按照锁步(lock-step)或者周期性状态复制(checkpoint)的方式进行同步。当其中的任何一个机器出现硬件故障的时候,其他机器可以代替故障机器继续工作。
服务器虚拟化使得通过虚拟机复制实现和应用无关的不间断服务成为可能,使得云服务提供商可以提供一种新的服务:高可用的基础设施服务。传统的虚拟机复制通过虚拟机锁步技术,实现在每一条指令边界的虚拟机状态复制。对于确定性指令(deterministic instructions),主虚拟机(Primary VM, PVM)和从虚拟机(Secondary VM, SVM)可以在没有虚拟机监视器介入的情况下并行执行。而对于不确定性指令(non-deterministic instructions),通过锁步技术,由虚拟机监视器模拟执行,确保在指令边界获得相同的执行结果。这种方法在多处理器情况下遭受非常大的锁步开销,因为多处理器环境下的内存访问结果是不确定的。因此这种解决方式效率低下。
另外一种虚拟机复制方法,是周期性的虚拟机状态复制。这种复制,是在每一个周期的边界设置虚拟机状态同步检查点(checkpoint)进行同步。也就是说,周期性地将主虚拟机的状态复制到从虚拟机上,例如Remus[14]。这种复制方法是在一个周期内将输出数据包缓存起来,直到下一个检查点进行同步的时候才发送出去,以便从虚拟机能在硬件出错的时候成功接管。但是,这种复制受限于传输缓存带来的额外网络延迟和频繁的虚拟机状态同步的开销。周期性的虚拟机状态复制方法的性能一直存在瓶颈,也没有得到广泛使用。虚拟机锁步和周期性的虚拟机状态复制方法实现了在特定指令边界的虚拟机状态的完全匹配。
但是,机器状态的完全匹配是一个过于严格的条件。只要在硬件出错时,从虚拟机能够成功接管服务,维持应用程序的语义,不间断服务就可以得到实现,而不管机器状态是否完全相同。这中间存在一个边界:只要从虚拟机和主虚拟机之间的差异在一定的边界内,从虚拟机就可能是一个有效的复制品,能够在主虚拟机遇到硬件出错的时候成功接管服务。当然,精确确定这个机器状态差异的边界太过复杂,对这个边界的精确确认没有太多的实际意义。从客户端的角度来看,只要从虚拟机和主虚拟机产生相同的网络响应包,在客户端/服务器系统中,从虚拟机就可以是一个有效的复制品。当主虚拟机经历硬件故障的时候,从虚拟机就能够成功接管。从客户端的角度看,并不能觉察出任何区别,就如同客户端自己一直都在和从虚拟机通信一样。虽然不确性定指令的执行可能立即引起虚拟机机器状态的不同,但是主虚拟机和从虚拟机在短时间里还是很可能会产生相同的输出或者响应,具有输出相似性或响应相似性。例如,TCP时间戳通常使用系统的滴答时间(jiffies),它的精确值在主虚拟机和从虚拟机之间往往是不确定的。但是,只有当两个虚拟机之间的时间差异累积足够长的时间的情况下,两者之间的时间戳才会出现不同的值。
有一些研究面向特定的操作系统和应用程序,提出相应的容错和不间断服务方案。例如,TFT[4]在应用程序和操作系统之间安置一个虚拟机监视器代理,在系统调用接口处协调主副本实例实现可确定的计算。TFT没有考虑多处理器情形。PLR[5]通过生成额外的运行时系统,实现了单线程模型下的进程级别冗余。Degerminator[6]引入新的并行编程模型,并且修改了操作系统来支持确定的并行计算。它们都受使用模型的局限,或者需要对操作系统和应用程序进行修改。
在云计算容错方面,相关工作包括应用级容错技术[11]、系统级容错技术[16]等;为避免由于软硬件维护、扫描等导致的服务不可用,相关工作包括虚拟机并发迁移技术[17]、在线升级技术[18, 19],以及不需停机的在线扫描技术[20]等,这些技术同样使用了虚拟化技术来实现高可用性。
多线程程序的确定性重放技术也可用于提高可用性。例如,Scribe[7]提出一种新操作系统机制,将具有非确定性结果的交互作用的点交会进行同步并且记录,实现应用程序的日志记录和重播。ODR[8]是一个可以再现错误、放松了保真度的重播系统。SMP-Revirt[9]为程序调试目的重播多处理器虚拟机系统的执行。面对数据竞争和死锁,Dthread[10]通过将多线程应用程序变成多个进程,利用私有的写时拷贝映射到共享内存强制实现确定性。但这些方法都不能提供一种有效的实现不间断服务的方案。
我们的工作
针对上述问题,我们提出了COLO(Coarse-grain Lock-stepping Virtual Machines for Non-stop Service),它是一种基于客户端/服务器系统的粗粒度锁步虚拟机方法,实现不间断服务。在COLO中,主虚拟机和从虚拟机并行执行,来自客户端的接收数据包首先被COLO管理器接收,同时被COLO管理器转送到主虚拟机和从虚拟机。同样,COLO管理器接收来自主虚拟机和从虚拟机的响应数据包,并在发送给客户机之前将它们按COLO的要求进行管理。
只要当一个从虚拟机对客户请求产生和主虚拟机完全相同的响应时,这个从虚拟机就被认为是一个合法的主虚拟机副本。在这种情况下,来自主虚拟机和从虚拟机的响应包就可以被立即发送回客户端(只发送一份,另一份被丢弃)。一旦COLO监测到从虚拟机和主虚拟机的响应差异,COLO就发起一个强制的虚拟机状态同步(checkpoint),把主虚拟机的状态严格复制到从虚拟机。在这个过程中,来自主虚拟机和从虚拟机的响应发送数据包被暂时挂起,直到将主虚拟机的状态成功地同步到从虚拟机(实现再一次的虚拟机状态完全匹配)。在虚拟机状态同步的时候,COLO管理器只需要传送自上一次同步以来的增量虚拟机状态即可。随着执行的继续,主虚拟机和从虚拟机的状态又会由于不确定性指令的执行而开始偏离,COLO管理器会继续比较它们的响应直到它决定重新同步。因此,从客户端角度看,COLO保证了从虚拟机始终是一个有效的主虚拟机副本,并且在主虚拟机发生故障时能够接管,就像客户端一直和从虚拟机在通讯一样。
COLO的实现基于Xen和它的增量虚拟机同步(checkpoint)方案,即Remus,但是该解决方案本身是通用的,足以在其他虚拟机监视器中实现,并且其成果已经在Xen社区开源。其整体架构如图1所示。
图1 COLO体系架构
COLO由一对网络连接的物理节点组成:主节点运行主虚拟机,从节点运行从虚拟机,并作为主虚拟机的有效备份。主虚拟机和从虚拟机独立并行执行,按照应用程序语义根据客户端的请求产生输出或者响应数据包。基于这个原理,来自客户端或者外部网络的数据包首先被主节点接收,然后由COLO转发给从节点,这样主虚拟机和从虚拟机就能够收到相同的请求(不管是内容还是包序列)。从节点的COLO管理器获取并且处理来自从虚拟机的输出数据包,并将它们转发给主节点的COLO管理器。主节点上的COLO管理器根据所收到的、分别来自主从节点的响应数据包,判断从虚拟机是否为一个有效的主虚拟机副本。
COLO能够处理硬件异常终止故障,保持系统的可用性。如果在主节点的COLO管理器发布第k-1个数据包而从节点的COLO管理器还没消耗(发送)第k个数据包的时候(图2中区域A),主虚拟机所在的硬件节点发生故障,这个时候从虚拟机只要能够从第k个数据包开始向客户端发送响应,从客户端角度来看没什么区别。也就是说从虚拟机可以成功接管响应。如果异常终止故障发生在从节点的COLO管理器消耗(发送)第k个数据包之后,但是在主虚拟机开始释放第k个数据包之前(图2中区域B),或者如果异常终止故障在主虚拟机正在释放第k个数据包的时候发生(图2中区域C),从虚拟机从第k+1个数据包开始向客户端发送响应,从客户端的角度看第k个包丢失。在这种情况下,从虚拟机还是能够成功接管控制权,如同在互联网环境下的丢包事件。操作系统网络栈和应用程序本来就被设计成可以从这种类型的错误(丢包)中恢复,因为这种丢包情况在真实网络系统中也随时可能发生。所以COLO也能够在这个情况下实现不间断服务。
当主节点硬件故障发生在COLO进行虚拟机状态复制的时候(图2中区域D),如果当前完整的新主虚拟机状态还没有完全传输到从虚拟机,从虚拟机可以从之前的本地的虚拟机快照中恢复(到上一个同步的状态),直接接管控制权,就如对于上述区域B的操作一样:即从第k+1个数据包开始返回响应,并且依赖于操作系统网络栈和应用程序自身从这个丢包状态中恢复过来。如果完整的新主虚拟机状态已经完全传输到从虚拟机,从虚拟机从新的主虚拟机状态(包含数据包k)恢复执行,并且向客户端发送响应数据包k,和上述区域A一样实现高可用性。
图2 COLO中的执行与点检验流
以上是COLO的主要设计思想。COLO实现了一个与应用无关的、可以在硬件异常终止故障时提供不间断服务的全新的解决方案,并采取额外的性能优化技术来进一步优化响应相似度和减少虚拟机状态复制的开销,例如修改TCP/IP协议栈、利用硬件辅助分页技术等。虽然COLO倾向于提供和应用程序无关的不间断服务的解决方案,但可以将COLO和少量应用级别的修改结合起来以进一步增强响应的确定性,提高性能。例如,优化数据库中的串行事务的并发控制方案可以被应用在COLO中,从而实现更高效的不间断服务。
未来展望
高可用性与容错性已经成为云计算中的迫切需求。本文分析了在虚拟化云计算环境下服务可用性所面临的挑战与机遇。高可用性和容错在云计算和数据中心环境的研究才刚刚开始。随着应用场景的不断丰富,计算量和计算密度的不断增加,各种新型计算资源的不断出现,软硬件栈的不断演进,使系统对可用性和容错能力都提出了更高的要求,需要做进一步的深入探索。
在粗粒度锁步虚拟机方面,深入研究粗粒度锁步虚拟机方法和各种关键应用的关系,以及和各种流行的不同操作系统的关系是一个长久的过程。同时,如何修改客户机操作系统、甚至应用程序本身来适应粗粒度锁步的应用场景,是一个需要解决的紧迫课题。如何将粗粒度锁步技术应用到原生操作系统中,利用操作系统的功能直接实现对应用程序的粗粒度锁步(即状态复制),实现应用程序的高可用性是另一个大的研究方向。还有一点,我们认为虚拟机/应用程序锁步、粗粒度锁步以及状态复制技术各有自己的应用场景和适用场景,一种基于多种技术的自适应分析、优化和选择方法即混合方法也是一个重要的研究方向。 ■
参考文献
[1] New York Daily.Google goes down for five minutes on Friday night, global internet traffic drops 40%[R/OL]. (2013).http://www.nydailynews.com/news/national/google-minutes-web-traffic-plummets-article-1.1429712 ,
[2] 中国电子技术标准化研究院. 云计算标准化白皮书[OL].(2014-07-21).www.cac.gov.cn/files/pdf/baipishu/CloudStandardization.pdf.
[3] IDC[OL].http://www.idc.com.
[4] Bressoud T C. TFT: A software system for application-transparent fault tolerance[C]//Proceedings of the the Twenty-Eighth Annual International Symposium on Fault-Tolerant Computing. Washington,DC: IEEE CS Press, 1998:128.
[5] Shye A, Blomstedt J, Moseley T, et al. PLR: A software approach to transient fault tolerance for multicore architectures[J]. IEEE Transactions on Dependable and Secure Computing, 2009(6)2:135-148.
[6] Aviram, Amittai, et al. Determinator: OS support for efficient deterministic parallelism[C]. 9th OSDI, 2010.
[7] Laadan O, Viennot N, Nieh J, et al. Transparent, lightweight application execution replay on commodity multiprocessor operating systems[C]//Proceedings of the ACM SIGMETRICS international conference on Measurement and modeling of computer systems. New York: ACM Press, 2010: 155-166.
[8] Altekar G, Stoica I. ODR:output-deterministic replay for multicore debugging[C]//Proceedings of the ACM SIGOPS 22nd symposium on Operating systems principles(SOSP’09). New York: ACM, 2009:193-206.
[9] Dunlap G W, Lucchetti D G, Fetterman M A, et al. Execution replay of multiprocessor virtual machines[C]//Proceedings of the fourth ACM SIGPLAN/SIGOPS international conference on Virtual execution environments(VEE’08).New York: ACM Press, 2008:121-130.
[10] Liu T, Charlie C, Emery D B. Dthreads: efficient deterministic multithreading[C]//Proceedings of the Twenty-Third ACM Symposium on Operating Systems Principles. New York: ACM Press, 2011: 327-336.
[11] Wang P, Zhang K, Chen R, et al. Replication-Based Fault-Tolerance for Large-Scale Graph Processing[C]//Proceedings of the IEEE/IFIP International Conference on Dependable Systems and Networks. IEEE, 2014:562-573.
[12] Malewicz G, Austern M H, Bik A J C, et al. Pregel: a system for large-scale graph processing[C]// Proceedings of the 2010 ACM SIGMOD International Conference on Management of data(SIGMOD’10). New York: ACM Press, 2010:135-146.
[13] Gonzalez J E, Low Y, Gu H, et al. PowerGraph: distributed graph-parallel computation on natural graphs[C]//Proceedings of the 10th USENIX conference on Operating Systems Design and Implementation. Berkeley, CA: USENIX Association Press, 2012:17-30.
[14] Cully B, Lefebvre G, Meyer D, et al. Remus: high availability via asynchronous virtual machine replication[C]//Proceedings of the 5th USENIX Symposium on Networked Systems Design and Implementation(NSDI'08), 2008:161-174.
[15] Dong Y Z, Ye W, Jiang Y H, et al. COLO: COarse-grained LOck-stepping virtual machines for non-stop service[C]//Proceedings of the 4th annual Symposium on Cloud Computing(SOCC ’13). ACM, 2013:3.
[16] Shi L, Wu Y, Xia Y, et al. Deconstructing Xen[C]. The Network and Distributed System Security Symposium 2017.
[17] Song X, Shi J, Liu R, et al. Parallelizing live migration of virtual machines[C]// Proceedings of the 9th ACM SIGPLAN/SIGOPS international conference on Virtual execution environments(VEE’13). New York: ACM Press, 2013:85-96.
[18] Chen H, Yu J, Chen R, et al. POLUS: A POwerful Live Updating System[C]// Proceedings of the 29th international conference on Software Engineering(ICSE ’07). IEEE, 2007:271-281.
[19] Chen H, Chen R, Zhang F, et al. Live updating operating systems using virtualization[C]// Proceedings of the 2nd international conference on Virtual execution environments(VEE’06). New York: ACM Press, 2006:35-44.
[20] Liu Y, Xia Y, Guan H, et al. Concurrent and consistent virtual machine introspection with hardware transactional memory[C]//Proceedings of the IEEE International Symposium on High PERFORMANCE Computer Architecture. IEEE, 2014:416-427.
所有评论仅代表网友意见