VMWare SRM容灾方案建议书

1、VMWare SRM容灾方案建议书 目 录 TOC o 1-3 1概述 PAGEREF _Toc480615995 h 31.1灾难恢复的重要意义 PAGEREF _Toc480615996 h 31.2容灾的总体规划 PAGEREF _Toc480615997 h 41.2.1技术指标RPO、RTO PAGEREF _Toc480615998 h 41.2.2国际标准SHARE78 PAGEREF _Toc480615999 h 51.2.3界定灾备系统的适用范围 PAGEREF _Toc480616000 h 91.2.4界定灾备建设的目标 PAGEREF _Toc480616001 h

2、91.2.5界定灾备系统的总体架构 PAGEREF _Toc480616002 h 101.3XXX企业容灾方案现状分析 PAGEREF _Toc480616003 h 102灾难恢复解决方案 PAGEREF _Toc480616004 h 132.1vCenter Site Recovery Manager PAGEREF _Toc480616005 h 132.1.1概述 PAGEREF _Toc480616006 h 132.1.2Site Recovery Manager的主要功能特性 PAGEREF _Toc480616007 h 152.1.3SRM支持灵活的拓扑 PAGEREF

3、_Toc480616008 h 172.1.4超越灾难恢复：灾难规避和计划内迁移 PAGEREF _Toc480616009 h 182.1.5VMware Site Recovery 的工作方式 PAGEREF _Toc480616010 h 182.1.6灾难恢复自动化和利用软件定义的存储 PAGEREF _Toc480616011 h 192.2vSphere Replication PAGEREF _Toc480616012 h 202.2.1概览 PAGEREF _Toc480616013 h 202.2.2利用vSphere Replication来扩大灾难恢复的覆盖范围 PAGE

4、REF _Toc480616014 h 212.2.3实现原理与工作机制 PAGEREF _Toc480616015 h 252.2.4vSphere Replication的优势 PAGEREF _Toc480616016 h 273方案架构设计 PAGEREF _Toc480616017 h 293.1客户容灾设计要求 PAGEREF _Toc480616018 h 293.2实施方案选择 PAGEREF _Toc480616019 h 303.2.1将基于阵列的复制与 SRM 结合使用 PAGEREF _Toc480616020 h 303.2.2将 vSphere Replicatio

5、n 与 SRM 结合使用 PAGEREF _Toc480616021 h 313.2.3将基于阵列的复制和 vSphere Replication 与 SRM 结合使用 PAGEREF _Toc480616022 h 323.3网络设计 PAGEREF _Toc480616023 h 333.3.1在恢复站点配置相同或不同的IP地址 PAGEREF _Toc480616024 h 333.3.2SRM通讯端口设置 PAGEREF _Toc480616025 h 353.4存储设计 PAGEREF _Toc480616026 h 373.4.1存储复制 PAGEREF _Toc480616027

6、 h 373.4.2占位虚拟机 PAGEREF _Toc480616028 h 383.4.3快照空间 PAGEREF _Toc480616029 h 384配置清单及说明 PAGEREF _Toc480616030 h 394.1硬件配置需求 PAGEREF _Toc480616031 h 394.2虚拟化软件配置需求 PAGEREF _Toc480616032 h 395方案总结 PAGEREF _Toc480616033 h 415.1方案要点 PAGEREF _Toc480616034 h 415.2方案优势 PAGEREF _Toc480616035 h 416专业服务 PAGERE

7、F _Toc480616036 h 436.1VMware专业服务介绍 PAGEREF _Toc480616037 h 436.2专业咨询服务内容 PAGEREF _Toc480616038 h 436.2.1VMware Accelerate咨询服务 PAGEREF _Toc480616039 h 436.2.2技术咨询服务 PAGEREF _Toc480616040 h 446.2.3技术客户经理(TAM)服务 PAGEREF _Toc480616041 h 446.3专业服务实施流程 PAGEREF _Toc480616042 h 456.3.1评估 PAGEREF _Toc480616

8、043 h 466.3.2规划与设计 PAGEREF _Toc480616044 h 466.3.3实施 PAGEREF _Toc480616045 h 466.3.4运维 PAGEREF _Toc480616046 h 477支持服务概述 PAGEREF _Toc480616047 h 487.1VMware支持的角色和职责 PAGEREF _Toc480616048 h 487.2全球技术支持服务 PAGEREF _Toc480616049 h 487.3自助服务支持 PAGEREF _Toc480616050 h 497.3.1社会支持 PAGEREF _Toc480616051 h 4

9、97.3.2其他资源 PAGEREF _Toc480616052 h 508缩略语解释 PAGEREF _Toc480616053 h 51概述灾难恢复的重要意义统计数据表明：93%的企业，一旦发生数据中心失效达 10 天的情况，通常在一年内就会破产。图：业务可用性与灾难恢复对企业的影响来自Forrestor在2014年第二季度的咨询报告表明，正常运行时间和数据保护对业务而言非常关键，灾难带来的员工工作效率下降、士气低落、收入下降、声誉受损和影响合规性将对企业产生巨大的消极影响。图：中断造成的不良影响灾难的发生往往是出乎人们意料的，当突然发生大的灾难，日常建立的控制措施已不再有效时，组织如何才

10、能保护核心业务不被中断，使灾难的造成的风险降到最低呢？这正是灾难恢复需要考虑的问题。数据中心的灾难会以不同形式发生，比如电力中断、硬件故障、人为操作失误、以及自然灾害。大量的事例表明，业务中断不是“假如”的问题,而是“何时”的问题。因此，只要是拥有IT信息系统的组织，都应为随时可能发生的中断作好准备。保证业务连续性也就是确保业务连续运作，不管发生什么情况，重要的系统和网络必须具有不间断的可用性。事实上，灾难恢复的影响不仅仅局限于上面提到的金融领域，政府、公安、医疗、教育等诸多行业都需要使用业务可用性解决方案来保证其业务的可用性，对于这些企业，机关，单位而言，当IT基础设施突然停运，不仅企业内部

11、的业务流转、办公等面临瘫痪，更重要的是，对外与客户或合作伙伴的所有业务交流都不得不陷入停滞。容灾的总体规划真正的容灾是数据被不间断的一致性访问！在灾难备份的世界里，是有等级观念的，级别不同，灾备系统所采用的技术和达到的功能是不同的，在系统建设资金投入方面的差距也很巨大。所以，对用户来说，明确灾备系统建设的总体规划十分必要。技术指标RPO、RTO衡量容灾技术的两个技术指标RPO、RTORPO(Recovery Point Objective): 以数据为出发点，主要指的是业务系统所能容忍的数据丢失量。及在发生灾难，容灾系统接替原生产系统运行时，容灾系统与原生产中心不一至的数据量。RPO是反映恢复

12、数据完整性的指标，在同步数据复制方式下，RPO等于数据传输时延的时间；在异步数据复制方式下，RPO基本为异步传输数据排队的时间。在实际应用中，考虑到数据传输因素，业务数据库与容灾备份数据库的一致性（SCN）是不相同的，RPO表示业务数据与容灾备份数据的SCN的时间差。发生灾难后，启动容灾系统完成数据恢复，RPO就是新恢复业务系统的数据损失量。RTO(Recovery Time Objective):以应用为出发点，即应用的恢复时间目标，主要指的是所能容忍的应用停止服务的最长时间，也就是从灾难发生到业务系统恢复服务功能所需要的最短时间周期。是反映业务恢复及时性的指标，表示业务从中断到恢复正常所需

13、的时间。RTO值越小，代表容灾系统的数据恢复能力越强。各种容灾解决方案的RTO有较大差别，基于光通道技术的同步数据复制，配合异地备用的业务系统和跨业务中心与备份中心的高可用管理，这种容灾解决方案具有最小的RTO。容灾系统为获得最小的RTO，需要投入大量资金。不同容灾方案的RTO和RPO是不相同的。国际标准SHARE78要建设容灾系统，就必须提出相应 的设计指标，以此作为衡量和选择容灾解决方案的参数。目前，国际上通用的容灾系统的评审标准为SHARE 78，主要包括以下内容。备份/恢复的范围灾难恢复计划的状态业务中心与容灾中心之间的距离业务中心与容灾中心之间如何连接数据是怎样在两个中心之间传送的允

14、许有多少数据丢失保证更新的数据在容灾中心被更新容灾中心可以开始容灾进程的能力SHARE 78是建立容灾系统的一种评审标准。建立容灾系统的最终目的，是为了在灾难发生后能够以最快速度恢复数据服务，主要体现在RTO Objective)和RPO上。SHARE78,M028报告中定义的灾备的七个级别和与其对应的数据丢失量与恢复时间情况详见下表：灾难备份等级与业务恢复情况对照表等级描述PRORTO企业百分比0级无灾备计划-48小时0.1%2级车辆运送热备份2448小时24小时90%3级电子传送24小时24小时6%4级活动状态备份中心秒级24小时0.5%5级两中心、两阶段确认秒级2小时0.1%6级零数据丢

15、失零丢失2小时3%Tier 0 Tier 0 - 无异地数据备份(No off-site Data)Tier 0 被定义为没有信息存储的需求，没有建立备份硬件平台的需求，也没有发展应急计划的需求，数据仅在本地进行备份恢复， 没有数据送往异地。这种方式是最为低成本的灾难备份解决方案，但事实上这种灾难备份并没有真正灾难备份的能力，因为它的数据并没有被送往远离本地的地方，而数据的恢复也仅是利用本地的记录。 Tier 1Tier 1- PTAM车辆转送方式( Pickup Truck Access Method)作为 Tier 1 的灾难备份方案需要设计一个应急方案，能够备份所需要的信息并将它存储在异

16、地，然后根据灾难备份的具体需求，有选择地建立备份平台， 但事先并不提供数据处理的硬件平台。 PTAM是一种用于许多中心备份的标准方式，数据在完成写操作之后，将会被送到远离本地的地方，同时具备有数据恢复的程序。在灾难发生后，一整套系统和应用安装动作需要在一台未启动的计算机上重新完成。系统和数据将被恢复并重新与网络相连。这种灾难备份方案相对来说成本较低(仅仅需要传输工具的消耗以及存储设备的消耗)。 但同时有难于管理的问题，即很难知道什么样的数据在什么样的地方。一旦系统可以工作，标准的做法是首先恢复关键应用，其余的应用根据需要恢复。这样的情况下，恢复是可能的，但需要一定的时间，同时依赖于什么时候硬件

17、平台能够被提供准备好。Tier 2Tier 2 - PTAM卡车转送方式+热备份中心 (PTAM+Hot Site)Tier 2相当于是Tier 1再加上具有热备份能力中心的灾难备份。热备份中心拥有足够的硬件和网络设备去支持关键应用的安装需求。对于十分关键的应用，在灾难发生的同时，必须在异地有正运行着的硬件平台提供支持。这种灾难备份的方式依赖于用PTAM的方法去将日常数据放在异地存储，当灾难发生的时候，数据再被移动到一个热备份的中心。虽然移动数据到一个热备份中心增加了成本，但却明显降低了灾难备份的时间。Tier 3Tier 3 - 电子传送(Electronic Vaulting)Tier 3

18、 是在Tier 2的基础上用电子链路取代了车辆进行数据传送的灾难备份。接收方的硬件平台必须与生产中心物理地相分离，在灾难发生后，存储的数据用于灾难备份。由于热备份中心要保持持续运行，因此增加了成本。但确实是消除了运送工具的需要，提高了灾难备份的速度。Tier 4Tier 4 - 活动状态的备份中心 (Active Secondary Site)Tier 4 这种灾难备份要求两个中心同时处于活动状态并管理彼此的备份数据，允许备份行动在任何一个方向发生。接收方硬件平台必须保证与另一方平台物理地相分离，在这种情况下，工作负载可以在两个中心之间被分担，两个中心之间之间彼此备份。在两个中心之间，彼此的在

19、线关键数据的拷贝不停地相互传送着。在灾难发生时，需要的关键数据通过网络可迅速恢复，通过网络的切换，关键应用的恢复时间也可降低到了小时级。Tier 5Tier 5 - 两中心两阶段确认 (Two-Site Two-Phase Commit)Tier 5 是在Tier 4的基础上在镜像状态上管理着被选择的数据 (根据单一commit范围，在本地和远程数据库中同时更新着数据)，也就是说，在更新请求被认为是满意之前，Tier 5需要生产中心与备份中心的数据都被更新。我们可以想象这样一种情景，数据在两个中心之间相互映像，由远程two-phase commit来同步，因为关键应用使用了双重在线存储，所以在

20、灾难发生时，仅仅传送中的数据被丢失，恢复的时间被降低到了小时级。Tier 6Tier 6 - 零数据丢失 (Zero Data Loss)Tier 6 可以实现零数据丢失率，同时保证数据立即自动地被传输到备份中心。Tier 6被认为是灾难备份的最高的级别，在本地和远程的所有数据被更新的同时，利用了双重在线存储和完全的网络切换能力。Tier 6是灾难备份中最昂贵的方式，也是速度最快的恢复方式，恢复的时间被降低到了分钟级。对于Tier 6 的灾难备份解决方案，可以应用两种远程拷贝技术来实现，即PPRC同步远程拷贝和XRC异步远程拷贝。 因此，企业需要根据其计算机处理系统中数据的重要性，以及需要恢复

21、的速度和程度，来进行灾备系统建设的整体考虑和不同灾难对业务冲击的分析，并最终确定灾备系统建设的总体规划。灾备系统建设的总体规划应包括以下几个方面： 界定灾备系统的适用范围分析不同的应用系统，确定灾备系统是一个覆盖整个计算机系统的工程，根据业务的重要性，对不同的系统采用不同级别的容灾方案，如针对关键的业务应用子系统，实施高级别的容灾工程；对低级别的业务系统，实施低级别的容灾工程。总之要建立一个综合性的整体灾备建设工程。 界定灾备建设的目标 生产系统在单位时间内的数据处理能力或IO流量确定的情况下，RPO实际上成为一个反映灾备恢复过程中的数据丢失量的指标。而RTO则是指从灾难发生到备份系统可以接管

22、原有生产系统所需要花费的时间，这不仅要考虑数据的恢复时间，还应该考虑恢复后数据的完整性、一致性的修复和确认、备份中心计算机处理系统的启动和备份中心的网络切换等全部时间。总体规划中应为灾备系统设定明确的RPO和RTO指标。 但是设计容灾系统不能只看RTO和RPO，对于不同的业务系统和用户特殊的要求，其它一些指标有可能成为选择容灾解决方案的主要因素。例如，某些地区为了防范一些特定自然灾害的风险，要求容灾备份中心与业务中心保持足够的距离，在这种情况下，容灾备份中心与业务中心的距离要求就是容灾系统的重要指标。通信网络是容灾系统的组成部分，通信线路的质量也是容灾系统的性能指标之一，其中包括网络的数据传输

23、带宽、网络传输通道的冗余和网络服务商的服务水平（网络年中断率）。如果容灾系统使用的通信网络是确定的，为了比较不同容灾解决方案，可以用单位存储容量的数据库在同一通信网络上的数据完全恢复时间作为一项设计指标。大部分业务系统都是数据库应用结构，但业务系统容灾并不等于是数据库容灾，还包括访问数据库的应用程序和相关配置信息。实现数据库容灾是容灾的基础，在保数据库数据一致的前提下，还要实现应用程序和配置信息的一致性；实现应用系统的高可用性、应用程序在容灾中心与生产中心接管和切回的过程，因此，还要考虑应用的模式是C/S、B/S，两层、三层、多层次的应用结构等等。界定灾备系统的总体架构 根据实际需求、现有技术

24、、所在地域、计划防范的灾难种类和预算投入的资金量等实际情况，确定灾备系统预期达到的级别，并以此来确定灾备系统与生产运行系统在地理位置上的距离（同城还是异地或两者兼备堡垒节点），备份数据存储所在的介质（磁盘还是磁带或两者兼备），备份数据在生产中心与备份中心传输的方式（这就涉及到了具体的计算机存储与网络技术），以及备份中心计算机系统的处理能力和网络接管所需的具体架构（是否与生产中心采用完全同等数量、容量和性能的计算机、存储设备和网络体系结构）。 XXX企业容灾方案现状分析在国内，很多企业都不具备灾难恢复能力，甚至是一些金融相关的公司都没有真正意义的灾难演练过。 主要是设备成本、技术复杂度已经人员I

25、T技能等多方面因素造成的。XXX公司的采用传统灾备解决方案，并有了多年的积累和发展，但是传统的解决方案还是存在如下诸多问题的。首先，传统的可用性解决方案是利用特定于应用的解决方案（如：Oracle RAC、MS SQL集群、Exchange Database Access Groups (DAG)等）在应用级别实施业务可用性。虽然这种方法通常可以提供不错的可用性，但是由于每一组应用都有自己的解决方案，因此这种方法有如下弊端：复杂且昂贵对管理员的技术要求较高出错的风险大许可证较贵(如RAC)专用的备份架构其次，虽然有一些基础架构层的解决方案可以比应用级解决方案更加经济高效，但是这些解决方案往往在

26、正常运行时间和RTO（恢复时间目标）方面表现得比较差。除此之外，传统的灾难恢复解决方案很难在现有的物理X86环境中实现，这是因为：传统的灾难恢复计划依赖于一套非常复杂的流程和基础架构：复制数据中心、复制服务器基础架构、将数据转移到恢复站点的流程、重启服务器的流程、重新安装操作系统的流程等等。由于灾难恢复可能非常复杂，因此各个企业常常发现他们只能为少数几个重要的生产工作负载提供良好的保护，而其他的工作负载（如文件/打印服务器、内部Web服务器、部门级应用）则得不到保护或者保护的不充分。因为灾难恢复计划和基础架构非常复杂，所以各个企业都极为依赖大量的人员培训、准确且完整的恢复纪录，以及发生停机时恢

27、复流程的准确执行。除此之外，由于恢复计划的测试过程会造成中断，而且成本非常高昂，所以各个企业无法确保所有培训、文档和执行过程都切实可行并且能够成功恢复IT服务。图：传统的灾难恢复解决方案所面临的挑战上图描述了传统的灾难恢复解决方案所面临的挑战，由于存在这些挑战，该方案往往会产生如下的后果：恢复计划的测试往往会失败关键工作负载的基本恢复（如能成功）通常要花费数天或数周的时间管理和维护恢复计划要耗费IT人员大量的时间和资源简言之，当前的灾备解决方案还无法满足其企业所设定的业务可用性要求。由此，XXX公司提出重新设计和实施中心总部应用到北京IDC的异地远程灾备的需求。XXX总部应用虚拟化改造完毕后，

28、目前服务器虚拟化比例已经达到大约XX%，XX%的应用已经由虚拟化承载，其中包括XX%的关键应用。需结合应用系统架构给出中心总部应用到北京IDC的异地远程灾备方案及实施日程表，按照日程表完成异地远程灾备。灾难恢复解决方案VMware提出的基于虚拟化环境的软件定义的可用性解决方案，该方案不仅可以提供与应用级别可用性方案相类似的RTO与RPO（恢复点目标），同时，它还可以提供基础架构层解决方案所具备的简易性和成本效益。同时，由于该方案充分利用了虚拟化环境的优势，因此它可以达到传统的非软件定义解决方案无法达到的效果。VMware灾难恢复解决方案包括vCenter Site Recovery Manag

29、er和全新的vSphere Replication。vCenter Site Recovery Manager如今，企业发现越来越难以提供符合要求的灾难恢复解决方案。而Site Recovery Manager可以帮助企业应对传统灾难恢复方法的各种挑战，满足他们的恢复时间目标（RTO）、恢复点目标（RPO）以及法规遵从性要求。利用Site Recovery Manager，企业可以管理从生产数据中心到灾难恢复站点的故障切换，同时，还可以管理两个互为恢复站点且具有活动工作负载的站点之间的故障切换。概述VMware的灾难恢复解决方案分为三个大的模块，如下图不同颜色模块所示：其中灾难恢复编排属于自动

30、化解决方案；复制、备份和恢复属于数据保护解决方案；计算存储属于基础架构解决方案。图：VMware灾难恢复解决方案Site Recovery Manager可以自动执行及简化故障切换至新数据中心的过程，从而让所计划的数据中心故障切换（如数据中心迁移）变得更加顺畅。它是一款领先的灾难恢复管理和自动化解决方案，它通过自动执行恢复过程来加快恢复的速度，并将灾难恢复作为VMware虚拟基础架构管理的集成要素，从而简化灾难恢复计划的管理工作。SRM省去了复杂的手动恢复步骤，支持无中断的恢复计划测试，确保恢复过程的安全可靠。它密切集成vSphere及其他领先存储供应商提供的存储复制软件，使故障切换和恢复变得

31、快捷、可靠、经济，而且便于管理。因此，企业不仅无需担心灾难恢复的风险，还可将所有重要的系统和应用程序纳入到保护范围。自从2008年面世以来，SRM已得到长足发展。到目前为止，VMware已向一万五千多家客户售出12.5万个许可证，并且该产品还在以每年50%60%的速度继续增长。SRM为vSphere平台上的灾难恢复计划增加的巨大价值推动了这种增长，而所增加的成本却相对较低。VMware的许多客户已利用SRM从实际灾难（例如最近在日本发生的海啸和在美国发生的飓风）中快速恢复。下图是一些主要的客户以及SRM的相关市场数据。图：Site Recovery Manager 的发展趋势与部分客户SRM需

32、要若干个组件。首先，受保护的站点和故障切换站点都需要一个SRM实例。SRM实例可通过与vSphere和vCenter紧密集成来提供管理和自动化功能。SRM还需要底层复制产品来将虚拟机复制到故障切换站点。借助SRM，客户可以选择使用vSphere Replication或者使用基于存储的复制。因为vSphere Replication与SRM捆绑在一起，所以无需支付额外费用。基于存储的复制由第三方存储供应商提供，并通过Storage Replication Adapater (SRA)与SRM紧密集成，以使SRM能够利用该存储层协调复制和恢复活动。最后，SRM在这两个站点上都需要配置vSpher

33、e集群和单独的vCenter实例。图：SRM的主要功能组件Site Recovery Manager的主要功能特性VMware vCenter Site Recovery Manager可提供先进的复制、灾难恢复管理、无中断测试、自动故障切换和故障恢复以及计划内迁移功能。它可以管理从生产数据中心到灾难恢复站点的故障切换，以及两个具有活动工作负载的站点之间的故障切换，甚至还可以将多个站点恢复为一个共享的恢复站点。Site Recovery Manager经常用于计划内迁移和预防性故障切换以避免发生灾难，它的主要功能特性如下：集中式恢复计划直接从 vCenter Server 中创建并管理恢复计划

34、。自动发现并显示由 vSphere Replication 或基于阵列的复制保护的虚拟机。将虚拟机映射到故障切换站点上的相应资源(资源池、虚拟 交换机和虚拟机文件夹)。指定虚拟机引导顺序。自定义虚拟机 IP 地址。自定义故障切换站点上的低优先级虚拟机的关机。利用自定义脚本扩展恢复计划。利用基于角色的访问控制来控制对恢复计划的访问。 将多个站点恢复至一个共享的恢复站点。自服务，基于策略的调配可以为Site Recovery Manager 安装了VMware vCenter Orchestrator插件 多租户可以根据需求通过vRealize Automation Center中的蓝图（blue

35、prints）预定义的各自的灾难恢复策略 自动执行故障切换接收关于可能的站点故障的自动警报。只需单击一次鼠标，即可在 vCenter Server 中开始执行恢复计划。自动停止用于恢复的复制数据存储的复制和升级。关闭故障切换站点上的低优先级虚拟机。按照预先指定的引导顺序自动启动受保护的虚拟机。 在恢复过程中执行用户定义的脚本和暂停。在故障切换站点上自动重新配置虚拟机 IP 地址。从 vCenter Server 中管理和监控恢复计划的执行。自动故障恢复自动故障恢复到原始生产站点。通过自动反向复制到原始站点来重新保护虚拟机。 反向执行原始恢复计划。利用 vSphere Replication 中

36、的自动故障恢复功能。计划内迁移使用计划内迁移工作流确保数据零损失和应用一致性迁移。 在原始站点正常关闭受保护的虚拟机。 执行数据同步以强制将关闭的虚拟机完整复制到故障切换 站点。 执行利用应用一致性虚拟机的恢复计划。 无中断测试自动执行恢复测试。 利用存储快照功能执行恢复测试,而不会中断复制。 在隔离网络中恢复虚拟机,以免对生产应用程序造成任何 影响。 针对测试方案自定义恢复计划的执行。 完成测试后自动清理测试环境。 在 vCenter Server 中存储、查看和导出测试结果及故障切换 执行情况。 支持 vSphere Replication 利用专为 vSphere 和 vCenter S

37、ite Recovery Manager 设计的唯一真正基于虚拟化管理程序的复制产品。通过 vCenter 以精细灵活的虚拟机级别直接管理复制。 使用与存储无关的复制支持使用低端存储,包括直连存储。 执行具备灵活 RPO(介于 15 分钟到 24 小时之间)的异步 复制。 仅复制发生变更的数据块以提高网络效率。 扩展到数百个虚拟机。 利用对文件和应用一致性的支持。 使用多时间点 (MPIT) 恢复来回到以前的已知状态。 支持第三方基于阵列的复制可在主要供应商提供的大量兼容性存储阵列和复制产品中进 行选择。 使用基于 iSCSI、光纤通道或 NFS 存储的基于阵列的复制解 决方案。 通过 SRA

38、 确保与 vCenter Site Recovery Manager 紧密集成。 自动执行复制和数据同步操作,以实现协调一致的灾难恢复 故障切换和计划内迁移。 SRM支持灵活的拓扑Site Recovery Manager可用于多种不同的故障切换情形，尤其是SRM能帮助客户更好地利用对辅助站点的投资，即，当客户没有处于灾难恢复情形中时，可将辅助站点用于其他工作负载而不是使其处于闲置状态，SRM可用于如下四种不同的故障切换情形：主动-被动：Site Recovery Manager完全支持传统的主动-被动型灾难恢复情形，即运行应用的生产站点将在故障切换之前一直处于闲置状态的辅助站点中恢复。尽管这

39、是最常见的配置，但此情形也意味着您需要为大部分时间都处于闲置状态的灾难恢复站点投入大量资金。主动-主动：为了更好地利用恢复站点，Site Recovery Manager还可以使用户在不使用该恢复站点进行灾难恢复时将其用于其他工作负载。用户可以将Site Recovery Manager配置为在故障切换过程中自动关闭或挂起位于恢复站点的虚拟机，这样就可以方便地释放计算容量以用于需要恢复的工作负载。双向切换：Site Recovery Manager还可以提供双向故障切换保护，这样，您可以同时在这两个站点上运行活动的生产工作负载，并以任一方向对另一站点进行故障切换。另一站点上的备用容量将用于运行

40、需要故障切换的虚拟机。本地故障切换：尽管这不是常见情形，但有一些客户需要能够在指定的“站点”或园区中进行故障切换，例如，当存储阵列发生故障或者大楼维修迫使您将工作负载移动到其他园区大楼时。这些客户将利用Site Recovery Manager执行此类故障切换。图：SRM支持灵活的拓扑超越灾难恢复：灾难规避和计划内迁移SRM不仅限于进行灾难故障切换，它更常用于日常迁移，例如用于灾难规避和计划内迁移。当然，灾难故障切换是最重要的使用情形，也就是当一个站点停止工作并且需要尽快将虚拟机迁移到辅助站点的时候使用。在这种情况下，SRM可支持完全或局部站点恢复，并将尽快执行故障切换以恢复业务服务。其他两种

41、使用情形尽管不是那么重要，但却更为常用。灾难规避在企业事先了解灾难将要发生的时候使用，例如，预测到飓风或洪水将要来袭时。在这种情况下，企业一般可在灾难实际来袭之前提早至少几个小时得到通知。企业也经常执行计划内迁移，例如，避免因计划内维护或全局负载平衡而导致停机。对于灾难规避和计划内迁移，现在企业可利用“计划内迁移”工作流程和自动故障恢复来简化迁移流程。图：三种典型的SRM使用情形VMware Site Recovery 的工作方式Site Recovery Manager可以为用户提供创建、管理和执行灾难恢复计划的主要环节。该解决方案已经集成到VMware vCenter管理界面中，可以统一管

42、理虚拟基础架构及该架构的灾难恢复计划。SRM可以简化并自动执行设置、测试和执行恢复计划的主要环节：设置恢复基础架构：Site Recovery Manager会指导用户完成连接远程站点并连接使用的存储复制软件的操作。还可让用户轻松地将生产资源（包括计算资源和网络资源）映射到恢复站点上相应的资源。创建恢复计划：Site Recovery Manager具有直观的界面，可以协助用户创建适用于不同故障切换情况和基础架构不同部分的恢复计划。用户可以指定一些虚拟机暂停或关闭，从而释放可用资源以供恢复使用。还可以指定虚拟机启动的顺序、设置用户定义的脚本自动执行，以及必要时决定暂停恢复过程的时间点。测试恢复

43、计划：Site Recovery Manager可以利用存储阵列的快照功能，在恢复站点上自动创建无中断的、隔离的测试环境，然后将虚拟机连接到用户的隔离测试网络中。它将自动执行在实际故障切换中将使用的恢复计划，并在测试结束后清除测试环境。测试结果会被保存，以便随时查看和导出。自动执行故障切换：管理员从VMware vCenter启动恢复计划之后，Site Recovery Manager会自动执行恢复计划中的所有步骤，保证恢复完全按照预期执行。管理员通过vCenter可以看到恢复计划的执行情况，并可以随时暂停或停止执行。随着环境的变化，用户也可以通过vCenter随时更新和修改恢复计划。灾难恢复

44、自动化和利用软件定义的存储Site Recovery Manager 可安装VMware vCenter Orchestrator插件，以实现灾难恢复编排过程中每个工作流的自动化。包括无中断测试、自动执行故障切换、自动执行故障恢复以及计划内迁移。图：工作流自动化通过vRealize Automation Center中的蓝图（blueprints）预定义灾难恢复策略，租户可以实现针对应用的自助式灾难恢复。图：自助式灾难恢复计划在SRM的最新版本中，支持使用软件定义的存储Virtual SAN实现灾难恢复计划，提高了灵活度，简化了管理，同时降低了硬件成本。图：软件定义的存储实现灾难恢复计划vSp

45、here Replication通过使用内置的vSphere Replication，用户可以消除第三方复制成本，并制定更灵活的灾难恢复计划。概览vSphere Replication无需采用基于存储阵列的本机复制，即可通过网络在vSphere主机之间复制处于开启状态的虚拟机，该技术具有许多独特的优势：降低带宽需求消除存储局限性构建灵活的灾难恢复配置降低带宽需求vSphere Replication是VMware的专有复制引擎，它仅会将发生变更的数据块复制到恢复站点，与手动复制完整的虚拟机系统副本相比，可确保实现更低的带宽利用率和更高的恢复点目标。在初始同步期间，利用虚拟机数据的“种子副本”通

46、过跟踪发生变更的磁盘区域并仅复制增量数据，确保高效利用网络图：vSphere Replication消除存储局限性vSphere Replication在各个虚拟机磁盘(VMDK)级别运行，因而可以在任何存储上托管的数据存储之间进行复制，它可以：在保护站点重新改变旧存储的用途对非同类站点采用不同的存储技术（例如SAN相对于NAS、FC相对于iSCSI等）仅将辅助存储用于受保护的虚拟机，而不是整个环境构建灵活的灾难恢复配置在配置要复制的虚拟机时，只需简单单击一下，即可将vSphere Replication配置为确保应用数据和虚拟机数据保持一致，它可以：与Microsoft的卷影复制服务(VSS

47、)自动集成，可确保恢复副本一致支持灵活的恢复点目标，可从15分钟至24小时不等在虚拟机级别通过vCenter Server控制复制每个集群可扩展为数百个虚拟机利用vSphere Replication来扩大灾难恢复的覆盖范围当前，灾难恢复的覆盖范围通常只限于大型数据中心的第一层应用，也就是关键的业务应用。在许多情况下，第二或第三层等非关键应用和小型站点没有真正的灾难恢复保护，而只是使用备份进行保护。这是因为，传统灾难恢复保护不仅成本高昂而且过于复杂，因而无法广泛应用于所有应用和站点。图：灾难恢复覆盖范围通常受高额保护成本的限制不幸的是，由于日常活动仍然广泛依赖于第二或第三层应用和小型站点，因此

48、这样的灾难恢复保护会导致大量的业务风险。在理想情况下，各企业应该准备一个经济高效且简单可靠的灾难恢复计划，以满足其所有应用和站点的需要。而VMware Site Recovery Manager可以提供两种复制选择来供用户使用，它们分别是：基于存储的传统复制，在许多情况下，它仍将是大型关键业务环境青睐的选择vSphere Replication (VR)，它为复制虚拟机提供了另一种选择。VR是一种经济高效的简单机制，可用于在两个站点之间进行复制，在很多情况下，是第二或第三层应用和小型站点的更好选择图：SRM可提供广泛的复制选择由于vSphere Replication的引入，客户现在拥有更多的

49、选择，从而使复制解决方案能够更好地符合业务需求。VR和基于存储的复制可在相同的集群中配合使用，以便为更复杂的环境提供最佳灵活性。图：VR可提供经济高效且简单的复制vSphere Replication和基于存储的复制都非常有用，客户可以根据实际情况将两者结合起来使用。vSphere Replication由VMware直接提供，与基于存储的复制相比，它更为经济高效且更简单。基于存储的复制依赖于第三方存储供应商，它更昂贵、复杂，难以管理，但是功能相对强大。下图是两种复制技术在复制提供方，成本，管理以及性能方面的比较。图：vSphere Replication是基于存储的复制的补充功能vSpher

50、e Replication是将灾难恢复保护扩展至第二或第三层应用和小型站点的极佳方法。图：将灾难恢复保护扩展至第二、三层应用和小型站点基于存储的灾难恢复相当昂贵，第一层存储阵列上的存储容量和额外的复制许可证使其成本居高不下。存储、复制和SRM的成本通常在每个虚拟机2000美元左右。尽管与物理灾难恢复相比已经便宜很多，但对于不太关键的业务环境而言，其成本仍然相当高并且可能成为成本障碍。vSphere Replication更为经济高效。通过支持使用较低端存储阵列、消除对专用复制许可证的需求和提供成本较低的SRM Standard版本许可证，VR可将每个虚拟机的成本降低3倍，即每个虚拟机大约600

51、美元。由于每个虚拟机的成本更低，因此各企业能够将其灾难恢复保护扩展至更多应用和站点。vSphere Replication不仅经济高效，简单，它还可以简化复制管理，它在本质上比基于存储的复制更容易管理。在新的SRM部署中使用基于存储的复制来设置复制是一项复杂的任务。vSphere管理员必须与存储管理员同步才能确保将适当的LUN复制到包含正确复制计划的其他站点。图：借助vSphere Replication简化复制管理借助vSphere Replication，一切都将简单许多。vSphere管理员可以从vCenter直接管理复制，从而消除对存储管理员的依赖。另外，管理员可以在虚拟机级别管理复制

52、，因而再也无需进行复杂的虚拟机分组以及将虚拟机映射到LUN。VR的这一特性使得它对于简易性至关重要的情形（例如对于第二和第三层应用的保护）格外具有吸引力。实现原理与工作机制vSphere Replication是深度集成在vSphere平台中的组件，也是当今市场上唯一一款真正的“虚拟化管理程序级”复制引擎。在主站点上，正在运行的虚拟机所用的虚拟机磁盘中如果有数据块发生了变更，这些数据块将发送到辅助站点，并在该处应用于虚拟机磁盘，以制作虚拟机的离线（保护）副本。图：复制虚拟机中发生变更的数据块图：vSphere Replication体系结构vSphere Replication是一款全新设计的

53、产品，专门用于在vSphere集群之间进行复制并支持SRM部署。它依赖在ESXi中嵌入的vSphere Replication代理，该VSR代理可跟踪已更改的磁盘区域并将最新增量数据发送至受保护的站点。所复制的数据将会被vSphere Replication服务器捕获。每个vSphere Replication服务器实例可以管理大约100个虚拟机。它可捕获最新的磁盘更改并将这些更改应用到已复制的数据。vSphere Replication可通过与vCenter和SRM紧密集成的vSphere Replication管理服务器进行管理。这两个站点都需要vSphere Replication管理服

54、务器。所有vCenter操作都通过同一个管理界面完成，使用该界面可以非常轻松地为最多500个虚拟机配置复制：只需右键单击某个虚拟机，并为其副本选择目标位置即可。此过程有一步是选择“恢复点目标”，此步骤将告知vSphere Replication可以获取多久以前的虚拟机副本，然后它将时时尝试复制数据以满足恢复点目标。图：为多个虚拟机选择一个恢复点目标vSphere Replication将会对源虚拟机及其副本执行一次初始完全同步，管理员可以在目标位置放置数据的种子副本，以减少初始复制所需的时间和带宽。虚拟机的种子副本中包含一个虚拟机磁盘文件，管理员可以通过任何途径将该文件放置到目标位置。放置种子

55、并不是一个必需的过程，无论目标位置是否有种子，vSphere Replication都会创建一个初始副本。如果用户获得了一个用于复制的种子，即可使用其中的数据来减少初始同步主磁盘及其副本所需的复制量。种子可以手动创建，也可以通过管理员选择的任何途径复制到相应位置，如采用脱机复制、FTP、“人工传输网络”，甚至使用ISO或虚拟机的克隆。在完成基准同步之后，vSphere Replication将切换为仅传输已变更的数据块。这种做法可以确保通过网络向目标发送最少量的数据，并实现更高的恢复点目标。在发送唯一性数据之后，无需再次发送。系统仅复制发生变更的数据，这些数据块将发送到目标位置的vSphere

56、 Replication设备中。从受保护的虚拟机的角度看，整个过程是完全透明的，不需要对配置或日常管理进行任何更改。这种复制方式采用的是非侵入形式，与虚拟机中的操作系统无关。vSphere Replication的优势vSphere Replication可以提供非常经济高效、简单而又功能强大的复制。经济高效VR可以降低存储成本和复制成本，所以更为经济高效。它可以在存储层消除这两个站点对较高端存储阵列的需求。客户可以跨站点使用其他较低端的存储，包括直连存储。例如，一种普遍的选择是将第一层存储放在生产站点，而在故障切换站点使用较低端的存储，例如较旧或较便宜的阵列。另外，vSphere Repli

57、cation也与SRM捆绑在一起，因而无需花费额外成本，从而消除了基于存储的复制许可证所需的额外成本。简单从本质上而言，vSphere Replication也比基于存储的复制更为简单。用户可以从vCenter直接管理复制，从而消除对存储团队的依赖。另外，管理员可在单个虚拟机级别进行管理，从而大幅简化SRM的设置。功能强大尽管vSphere Replication简单且经济高效，但仍然是稳健且功能强大的复制解决方案。它可提供15分钟的RPO，并且使用户能够灵活地将RPO设定在15分钟到24小时之间。它可跟踪已更改的磁盘区域并且仅复制最新的增量数据以提高网络效率，还可扩展至最多500个虚拟机。方

58、案架构设计VMware vCenter Site Recovery Manager (SRM) 是一个业务连续性和灾难恢复解决方案，可帮助用户计划、测试 和执行受保护 vCenter Server 站点与恢复 vCenter Server 站点之间的虚拟机恢复。通过配置基于阵列的复制，管理员可将 SRM 配置为支持若干第三方磁盘复制机制。管理员也可以使用基于主机的复制，方法是配置 SRM 以使用VMware vSphere Replication 来保护虚拟机工作负载。除此之外，SRM还可以与基于阵列和基于主机的复制同时结合使用。客户容灾设计要求设计特征描述可靠性表示设计选择对应的技术能力和相

59、关基础设施的高度可用性。关键指标：XX.XXX的正常运行时间。 (99.9%)可管理性表示设计选择对环境的灵活性和操作的方便程度的影响，包括可扩展性和灵活性。关键指标：每个管理员的服务器。每个IT人员的客户。时间部署新的技术。性能表现表示的设计选择对环境的性能的影响。这并不必然反映在对基础设施中其他技术的影响。关键指标：响应时间吞吐量恢复能力 表示设计选择对从突发事件恢复的能力的影响。关键指标：RTO - 恢复时间目标。RPO - 恢复点目标。（其中RTO要求为5分钟内，RPO要求为2小时内）安全表示设计选择对整体的基础设施安全能力的正面或负面影响。也可以表示设计是否满足业务到达一定的合规性政

60、策的能力。关键指标：未经授权访问的预防数据的完整性和保密性在折衷情况下的辨析能力实施方案选择VMware vCenter Site Recovery Manager (SRM) 是一个业务连续性和灾难恢复解决方案，可帮助用户计划、测试 和执行受保护 vCenter Server 站点与恢复 vCenter Server 站点之间的虚拟机恢复。SRM对硬件的要求如下表所示，我们在对SRM进行规划时，必须严格遵循下表中指定的最小或者最佳配置。表：SRM的硬件要求通过配置基于阵列的复制，管理员可将 SRM 配置为支持若干第三方磁盘复制机制。管理员也可以使用基于主机的复制，方法是配置 SRM 以使用V