1、引言
云计算是一种新型的业务模式，能够为数据中心厂商节约能耗，提高设备利用率，并突破传统服务模式开展多样化的创新商业服务模式；用户可以不用自己购买IT固定资产，而通过VDC (Virtual Data Center，虚拟数据中心)服务提供商按需租用自己所需的计算、存储、网络资源，并可随时随需扩展、新增、停租资源。
云计算基础设施即服务IaaS(Infrastructure as a Service)业务模式最典型的应用场景是虚拟数据中心，该业务模式的出现将计算机系统的维护进行了细分，由服务供应链的各方各司其职：用户只需考虑其自身应用基于虚拟环境的部署架构，VDC服务提供商只需考虑将硬件资源池化并保证服务可用性，硬件厂商只需考虑底层设备对虚拟化环境的支持和优化。维护重点细分之后，应对风险的责任也就细分了。因此云计算环境下的灾难应对并不是服务供应链中只有某一方需要考虑的问题，而是需要各方基于各自责任范围形成协调一致的措施，这样才能在灾难来临时最大程度的减小损失。
本文探讨了云计算IaaS服务提供商和用户应对灾难的策略，并提出了一种VDC容灾架构。
2、灾难的定义和分类
根据原国务院信息化工作办公室的定义，灾难是指由于人为或自然的原因，造成信息系统运行严重故障或瘫痪，使信息系统支持的业务功能停顿或服务水平不可接受、达到特定的时间的突发性事件，通常导致信息系统需要切换到备用场地运行。根据这一定义，灾难不仅指海啸、地震等自然灾害，还包括其它任何由无法预知的原因引起的服务不可用。IT服务的失效能够直接导致企业实现核心价值的关键业务系统受到重创。例如，银行的ATM机失效、网站的网页无法访问、证券的交易系统失灵、数据中心的网络阻塞等，最终将导致致命的伤害，造成不可挽回的损失。
我们将灾难进一步细分，按照人为因素的多少分为以下三类：
(1)非人为自然灾难：海啸、地震等区域毁灭性灾难；
(2)人为非技术性灾难：火灾、停电、人员损失等局部临时性灾难；
(3)人为技术性灾难：设备故障、逻辑缺陷、人为操作失误等可优化灾难。
3、VDC业务各方需应对的灾难
对于VDC业务来说，应对第一、第二类灾难主要依托预先制定的容灾预案；应对第三类灾难主要依托密集型的技术干预，服务架构越复杂，引起第三类灾难的风险环节就越多，但与第一、第二类灾难不同的是，第三类灾难可通过整改措施转变为“一次性灾难”，降低重复发生的可能性。
VDC服务提供商和VDC用户都会面临以上三类灾难，但各自的应对和预防措施不同。
3.1VDC提供商需要应对的灾难
一个配置准确、正常运营的VDC能够让租户通过云管理平台在15分钟内获得所申请的资源，并且可以随时按需关闭、新增和扩展虚拟服务器，这是VDC提供商IaaS服务的基本特点。其服务架构可以分为资源层、业务层、展现层，其中任何一层都有出现异常的可能，具体可以表现为：
(1)资源层设备损坏(三类灾难都可能引起)；
(2)资源层网络受培；
(3)资源层主机系统故障；
(4)业务层调度逻辑错误；
(5)业务层拒绝服务；
(6)展现层拒绝服务；
(7)其它无法预知的技术故障。
以上这些异常每一种都会引起服务不可用。架构中各模块之间有相互依赖逻辑，一处技术故障经常会引起“连锁反应”，导致多个环节异常，增加系统管理的复杂度，从而导致服务不可用时间的延长。
三类灾难的发生虽然不可预知，但通过执行预先制定的容灾预案，VDC提供商可以将由非人为自然灾难和人为非技术性灾难引起的服务间断控制在最小范围。技术性灾难则需要VDC提供商通过自身的技术力量准确定位、排除，并对服务架构进行巩固和预防。灾难的应对直接影响VDC服务的可靠性和稳定性，是其服务质量的关键因素，也是VDC实现服务级别协议SLA(Service Level Agreement)管理的关键因素之一。
3.2VDC用户需要应对的灾难
对于3.1节描述的灾难，VDC服务提供商有完备的应急和应对措施，VDC用户在此基础上可充分利用云服务资源申请的自动、快捷、方便，进一步为自身应用设置灵活的容灾策略。然而另有一些灾难因素是VDC提供商无能为力的，用户必须考虑跨VDC提供商的灾备方案来解决，这些因素包括：
(1)VDC提供商转变经营策略，不再提供云计算服务，所有设备移作他用；
(2)VDC提供商宣告破产，所有设备去向不明。对于此类灾难的用户应对措施将在5.2节详细描述。
4、云提供商应对灾难的措施
4.1基础设施要求
资源层是云计算服务架构的最底层，为了面对不可预知的灾难，VDC提供商必须准确了解各有关基础设施资源的特性，并在合适的位置设置合适的基础设施资源。
4.1.1网络是关键
云计算以网络为依托，网络通畅是云计算服务的根本保障。VDC服务区域内部的物理主机连接(本地网)、跨域调度的连接(主干网)、对外提供服务的业务连接(外网)是不同层次的网络，各自的流量带宽要求不同，发挥的功能也不同。所有资源的调度、备份算法、容灾策略都运行在满足各自需求的网络上，网络异常造成的拥堵轻则影响用户体验，重则导致服务中断。以下以亚马逊云计算服务曾经出现的事故来说明这一点。
亚马逊互联网络服务(Amazon Web Service，简称“AWS”)，服务区域内部的主机连接分为两类，一类为高性能的、高吞吐能力的连接弹性计算云(Elastic Comute Cloud，简称“EC2”)和弹性存储块(Elastic Block Store，简称“EBS”)的业务网，另一类为稳定的、低吞吐能力的连接EBS和容灾存储的备份网。2011年4月21日，AWS维护工程师为北美某服务区域的EBS扩容，在设备与网络相连时，误将EC2与EBS之间的连接接入备份网，同时造成了业务和备份服务的网络阻塞，由此触发了一系列的灾难；
(1)因业务拥堵直接造成该服务区的虚拟机(VM)无法响应对块存储的读写操作，用户无法新建虚拟机；
(2)因备份服务的网络拥堵直接导致13%的容灾存储被挤下线；
(3)网络设置恢复后，因容灾备份的触发，起初无法找到备份副本的EBS大面积同时启动副本重建，备份网络再次拥堵；
(4)容灾存储消耗过快，无法找到备份所需存储资源的EBS始终处于重新寻找资源(re-mirroring)的状态中；
(5)调度服务器接收不到EBS的备份反馈，进程无法释放，进程数很快占满，开始拒绝接收新的调度服务，导致其它服务区域的请求不被响应。
AWS花了3天时间将该连锁反应导致的异常数据量减小到了0.2%，1周的时间让系统完全恢复正常运作。由此给AWS带来的经济损失为故障服务区域10天的营业额(AWS为补偿用户作出的决策)；故障发生期间给用户带来的损失是无法估量的，期间有数10个网站用户的站点无法启动和被访问。
当然，这里不是暗示在VDC架构设计的时候在所有的网络连接上都使用高速、高吞吐量的设备，而是强调在做组件架构、制定容灾策略的时候需要充分考虑网络能力以及制定合理的业务响应逻辑方案来应对出现网络拥堵的情况。
4.1.2主存储与容灾存储的存储模式区别
业务数据和容灾数据对底层存储的需求不同，使用的存储设备也不同，表1列举了业务存储(主存储)和容灾存储的需求区别。
用户日常业务需要的、VDC提供IaaS服务必不可少的物理存储设备即为主存储，主存储提供模板库和弹性存储服务。模板库中的镜像数据为一次写多次读，允许删除，连续I/O的需求可高达几十GB；弹性存储为用户数据，多次读多次写，允许删除，连续I/O的需求不固定。为达到最佳的用户体验，主存储需要最快的磁盘和最快的与计算服务相连的网络。
容灾存储可直观理解成主存储的副本，备份/复制一般按照固定的间隔进行，一次写多次读，有删除操作，连续I/O的需求一般为几十GB，速度要求不高，但必须要求稳定可靠。容灾存储和主存储之间的网络不要求快速，但需要相对均匀的流量。
此外，为优化存储设置，还可以从文件系统、存储格式等方面为主存储和容灾存储设定不同的机制。为主存储进行合适的RAID设置，保证性能稳定的同时降低成本；为容灾存储设置专门支持的文件系统，通过时间戳、作者信息等附加属性实现同名文件的版本区分，通过压缩、除重策略实现存储空间的节省。
4.2容灾策略要求
容灾的目的是在主数据发生故障以后，通过利用容灾存储的冗余数据来恢复应用。容灾策略的受益可以量化成其为用户挽回的直接和间接的损失。当容灾收益大于部署成本时，就值得去实施这个容灾策略。
4.2.1备份/复制的机制
据备份一般是指利用备份软件把数据从磁盘备份到磁带或磁盘进行离线保存。备份数据的格式是磁带格式，不能被业务系统直接访问。在原数据被破坏或丢失时，备份数据必须由备份软件恢复成可用数据，才可让数据处理系统访问。
数据复制是指利用复制软件把数据从一个磁盘复制到另一个磁盘，生成一个数据副本。这个数据副本是业务系统直接可以访问的，不需要进行任何的数据恢复操作，这一点是复制与磁盘到磁盘(D2D)备份的最大区别。复制又可以分为同步复制、异步复制、增量复制。
采用何种备份/复制机制取决于系统对RPO(Recovery Point Objective s，恢复点目标)的要求，为满足不同RPO，备份/复制机制的实现成本有很大的差异，RPO直接决定了备份/复制机制的启动间隔。一份有效的容灾副本是灾难来临时使瘫痪的业务系统恢复正常工作的必要条件。为不使灾难导致主数据和容灾数据同时失效，往往采用异地备份的模式。在备份/复制运行时，需要做到不影响业务系统的服务性能，这就要求合理的利用备份时间窗口，在系统相对不繁忙的时段进行备份或复制。对于5 x 8的非关键系统，备份时间相对较大，但对于7 x 24的主系统来说，备份时间窗口就很小，需要通过加快备份速度和实现在线复制来解决。
最常见的RPO接近于1天的应用，可以采用每周一次全量备份、每天一次增量备份的策略。如此获得的备份副本更新频率为1天，一旦主数据失效，都能够恢复至1天以前的数据。这个备份机制对一些要求比较高的信息是完全不可接受的。通过增量复制策略可以满足更小的RPO，但增量复制也是一种非实时的复制方式，它依然需要依靠一定的策略(数据变化量阈值、日历安排等)来启动，增量复制可以结合快照技术有效保证数据的一致性。
对于RPO接近于0的关键业务应用，可以采用异步复制的策略。异步复制在向主机返回写请求确认信号之后实时进行，是一种实时复制模式，因此又叫异步镜像，异步镜像对于连接业务系统和容灾中心的链路带宽要求理论上只需达到“日新增数据量/(24×3600 x 8)”即可。异步镜像的优势在于用相对一般的网络带宽和QoS满足接近于0的RPO，但由于复制机制的原因，无法有效的保证数据的一致性。
对于RPO要求严格为0的应用，灾备策略需要投入的成本最高，需要采用同步复制的模式。同步复制是在向主机返回写请求确认信号之前实时进行的，也叫同步镜像。为有效的保证数据一致性，需要关闭主机缓存，并需要在业务系统和容灾中心之间采用光纤直连、波分设备的网络部署。
复制机制有基于主机和基于存储之分。基于主机的复制一般由安装在主机上的复制软件来实施，会影响主机系统的性能；基于存储的复制由存储设备控制器或虚拟化存储管理平台执行，它独立于主机，不会对主机系统的性能造成影响。对于VDC来说，所有的服务都需要基于网络提供，备份/复制由于执行机制的不同，可以不占用物理主机资源，但必然会占用网络资源。这就需要将业务网络和灾备网络分离，并实行合理的网络监控机制。2011年4月21日，AWS的服务中断事故除了人为因素之外，也由于容灾逻辑中对网络连接监测的不合理导致备份策略后续大量的重镜像执行，造成了拥堵。
4.2.2高可用和负载机制
高可用和负载均衡都是需要在本地网部署，需要保证各主机之间秒级间隔的频繁互通，因此面向的应用场景仅针对主机失效，无法应对自然灾难以及停电、火灾等非技术灾难。
高可用可以保证主机系统能够提供24小时的不间断服务，在主机发生故障时，备机能够自动及时检测到故障，并接管主机发生故障的服务(可以是主机的全部服务，或者仅发生故障部分的服务)；当备机故障时，主机检测到故障并发送通知给管理员，以便进行即时维护。负载均衡的特点在于能够分摊大流量的数据，将密集的服务请求下放到若干个相互独立的主机上。任一主机失效并不影响所提供服务的连续性。
在VDC的云计算服务中，可以考虑在服务模块的单点故障处部署高可用，在瓶颈处部署负载均衡，详见6节。
5、用户应对灾难的应急措施
VDC灾备的目标是laaS服务的连续性，即资源申请、监控、账单查询等业务模块的正常运行，而对于虚拟机本身不提供灾备机制。因此为了达到最佳用户体验，用户除了按就近原则选择地理位置最近的服务区域部署自己的虚拟机外，还需要根据自身的需要制定合适的容灾策略，这些容灾手段是无法由VDC代劳的。
5.1同一云服务提供商不同服务区之间的容灾策略设置
VDC的跨域资源调度需要占用大量的网络资源，出于成本考虑，一般VDC提供商不主动提供用户数据的跨域备份/复制。然而对于用户而言，跨域的异地副本是实现其本身数据高可用的保障。异地副本包括虚拟机镜像模板、存储。VDC提供商一般会提供若干个标准的虚拟机镜像模板，每个用户都能基于这些标准模板建立自己的虚拟机。用户对虚拟机可以进行个性化的配置和调整，删除多余的程序、关闭多余的服务端口，以优化自身部署的应用。一个健康的用户虚拟机应包含除数据以外的所有服务模块及所需的运行时环境。当这样的虚拟机设置、调试完成，投入使用后，用户需要对该虚拟机镜像做备份，将其作为个性化的模板，并保证这个模板在所有的服务区域内都具备独立的副本。这样才能保证在任何时候，在任-N务区域，用户都能快速创建相同的个性化虚拟机实例。通过如此灵活设置的个性化模板可以使得VDC上用户自身服务的RTO远小于基于物理主机的RTO。
对于存储而言，用户需要自行设定跨服务区域的备份和复制策略，在衡量自身服务的RPOS~成本后进行实际部署，部署方式与4.2.1节的描述类似，这里不再赘述。
5.2不同云提供商之间的容灾
跨不同VDC提供商的容灾策略考虑的是应对单一VDC提供商业务停止的风险。物理灾难发生频率较小，但经营模式、业务范围的变化随时随地都在发生，因此用户应用的部署及灾备策略应该考虑到VDC提供商层面的冗余。
5.2.1主、备提供商之间服务的依赖关系
选取备用提供商的原则应与选取主提供商的原则一致，需要充分考虑其能够提供的服务能力，而且主、备提供商之间不存在业务上的相互依赖关系。如果备用提供商的物理设施依赖于主提供商，那么当主提供商的云计算服务终止后，备用提供商的服务会受到连带的影响，对云计算服务的用户来说就失去了容灾的意义。因此在选取备用提供商时，用户应该考虑以下原则：
(1)主、备VDC提供商之间不存在相互的物理设施租赁业务；
(2)主、备VDC提供商的基础设施供给不依赖于完全相同的直属厂商，即每一个VDC提供商仅依靠其“独有”的直属设备厂商都有能力搭建出能够提供完整服务的Iaas服务架构。
5.2.2基于主、备提供商的容灾策略
5.2.2.1使用备用提供商做备份
这里所说的备份仅指数据备份，有关备份间隔的选定
与4.2.1节描述的原则一致。这里需要注意的是，不同VDC提供商的存储文件系统不一定相互兼容，这就需要选择符合自己需求的备用提供商。即当需要使用恢复策略时，从备用提供商的存储服务中获取的备份副本能够及时并完整的传输至主提供商，并且能够被主提供商服务中建立的虚拟服务器识别并准确的读取。
5.2.2.2使用备用提供商切换部署
对于使用Iaas服务的用户来说，能够在需要的时候在备用VDC提供商处搭建起虚拟运行环境提供对外服务是选择备用提供商的主要目的。在这个场景中，可以认为主VDC提供商的服务已经完全瘫痪，已无法从中读取出任何的信息，包括虚拟机的配置、模板以及用户数据等。为了在备用VDC提供商的IaaS环境中预先做好可以启动业务环境的所有准备，用户需要考虑以下几个方面：
(1)备用提供商支持的文件系统，同5.2.2.1节；
(2)在备用提供商处的数据备份，同5.2.2.1节；
(3)备用提供商支持的虚拟机操作系统需要符合用户所需运行时的环境；
(4)用户在主VDC提供商处做的每一次系统更新都要及时地反映在备用提供商中，具体表现为系统更新后虚拟机模板的更新，不同VDC提供商的的虚拟机模板不一定兼容，这需要用户手动在备用VDC环境中做独立的更新；
(5)为主、备VDC提供商的服务部署监控。
这里所说的监控包含三个方面：调用vDc服务平台API获取的有关虚拟机的全局监控、各虚拟机实例的性能监控、用户自身部署服务的监控。通过这三方面的监控用户才能够第一时间做出在备用VDC提供商处启用服务的决策。需要注意的是，由于监控的目的是为了及时发现和预防主提供商所提供的服务失效，因此监控程序本身应该部署在相对主、备提供商独立的环境中，由此来保证VDC提供商的服务不影响监控程序的正常运行。
6、VDC的容灾架构建议
无论是VDC提供商还是VDC用户，容灾策略部署的目的在于能够在灾难降临时在RTO限定范围内恢复至限定的RPO状态，因此各方“严谨”的容灾策略都应该做定期的演练，以便及时发现问题并进行补救，最大程度的降低人为技术性灾难。这里给出一个可供VDC提供商参考的容灾架构。
搭建完成的IaaS服务架构是部署容灾策略的前提，IaaS架构图如图1所示。
图1中所示的云控制器、节点控制器均为单点故障，为提升VDC的服务可用性，可以为其设置高可用技术，集群控制器需要汇总所有主机的网络负载，形成带宽瓶颈，因此可以设置负载均衡架构。此外，整个云平台的元数据库也建议使用高可用进行部署，如图2所示。
在架构上，模板库的作用范围为整个节点，或整个服务区域，弹性存储的作用范围为整个集群。在各自的作用范围内，VDC提供商应当保证数据的可用性，并且模板库、弹性存储的调用对上层的用户透明。例如AWS的简单存储服务(Simple Storage Service，简称“S3”服务)虽然可用性不高(即经常出现无法连接或服务不可用的现象)，但可以保证用户数据不丢失。在服务区域内部，VDC提供商的物理设备链接是相对稳定的本地网，稍加设置即可最小化备份占用的业务带宽。对于跨域存储的备份，由于需要占用成本相对较高的主干网带宽，因此VDC提供商不自动为每个用户提供异地容灾，但可以设置容灾通道由用户自行定制使用。对于用户而言，只需为备份时占用的网络流量和备份副本占用的存储空间付费即可。在具备完善的物理设备支撑的同时，容灾策略的触发算法也至关重要。AWS的事故正是由于容灾触发算法的逻辑不严密导致了连带性的服务中断，先前的人为操作失误恰好暴露了触发算法的漏洞，AWS才得以设法巩固其业务逻辑。一般来说，基于不可靠设备建立的稳定存储系统都需要依赖于LOCKSS策略，因此当副本减少时，容灾策略会自动触发副本重建程序。导致副本逻辑丢失的诱因有多种，最具代表性的是存储介质物理损坏和存储介质网络请求不响应。重建副本的途径如果依赖于其诱因，就会出现死循环。AWS因为网络拥堵导致部分备份副本被挤下线，容灾策略检测到副本逻辑丢失时自动触发本地网范围内的存储搜索并建立新的副本，大量的副本重建指令同时触发使得已经拥堵的网络资源更加拥堵，不但更加恶化了容灾策略，也使得正常业务遭受了影响。
正如AWS官方声明所言，如果没有维护工程师的误操作，容灾触发算法的这一逻辑缺陷将始终存在，并且很难在日常的容灾演练中发现。这就说明逻辑的完善需要在实践中慢慢积累，现在看似严密的策略也会存在一些尚未暴露的缺陷，无论是VDC提供商还是VDC用户，都需要在IaaS服务的使用过程中不断的完善、巩固各自的容灾策略。
7、总结
为了应对自然灾难、人为非技术灾难和人为技术性灾难，VDC提供商和VDC用户都需要部署各自自身的容灾策略。对于VDC服务提供商来说，需要在物理资源如存储、网络、云管理平台的服务模块等层面设置可行的容灾和负载策略；对于VDC用户，除了依赖于提供商的灾备策略外还需要应对VDC提供商终止服务的风险，采取多提供商的策略。
当然，为了使IaaS服务和部署在IaaS服务上的应用稳定持续的运行，除了容灾策略以外，安全策略的部署也是很重要的一部分，这涉及到VDC机房本身的IDC安全，以及虚拟层的安全，这是VDC的IaaS服务建设中必须重点考虑的一部分。
核心关注：拓步ERP系统平台是覆盖了众多的业务领域、行业应用，蕴涵了丰富的ERP管理思想，集成了ERP软件业务管理理念，功能涉及供应链、成本、制造、CRM、HR等众多业务领域的管理，全面涵盖了企业关注ERP管理系统的核心领域，是众多中小企业信息化建设首选的ERP管理软件信赖品牌。
转载请注明出处：拓步ERP资讯网http://www.toberp.com/
本文标题：浅析云计算IaaS服务的灾难应对策略
本文网址：http://www.toberp.com/html/consultation/1083974415.html
相关文章
