用户日常业务需要的、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服务建设中必须重点考虑的一部分。