构建灾难恢复站点的准备

在构建一个远程VMware灾难恢复站点之前，有许多问题需要考虑。

清查现有的基础设施。在彻底理清一个主要数据中心的资产之前，不能对其进行复制。

了解应用程序和它们的依存关系。明确哪些应用程序需要抵抗灾难的能力。要考虑到（主站点和备份站点）存储和网络架构之间任何潜在的差异，确保程序即使在不同的环境下，也能够按照预期实现把故障转移到备份站点。

建立恢复点目标（RPO）和恢复时间目标(RTO)。 如果数据每小时复制到第二数据中心，当灾难发生时，有可能最多丢失之间59分59秒的数据。如果这样是可接受的，不会严重地影响业务，那么PTO可以设定为一个小时。

为用户服务。终端用户也许不能够访问运行维护的所有的服务器和应用程序。要考虑怎样替换用户们的桌面和应用程序，明确他们怎样进行远程访问。

构建灾难恢复站点的实施

选取数据中心地址。一条可承担到主数据中心的高速连接是选择灾难恢复中心需要考虑的关键的几个因素之一。

获取、安装和准备硬件。

安装和配置vSphere。

实施复制。初始化数据的复制将是最大规模的数据传输，随后的对发生改变的块进行复制将会小很多，但是复制数据的大小会依据应用程序中数据量改变的大小而定。复制的数据的大小也会依据复制的间隔（由RPO决定）而变化。

硬件独立：基于物理系统的灾难恢复解决方案都需要将相同的硬件保留到恢复站点，或必须经过很多复杂耗时的步骤在新的或不同的硬件上重建服务器操作系统。有时候碰巧恢复服务器就是同一个硬件模型，但是包含了最新硬盘控制器固件，会导致服务器镜像延迟。虚拟化使硬件从操作系统中抽象化，而且使操作系统中使用的设备驱动器统一化，不管是何种底层硬件模型，所有虚拟机都使用一个共同的驱动集。这样，在新服务器上安装服务器镜像时就省了很多设备驱动对应的麻烦，大大减少了恢复时间和配置错误的风险。

虚拟机磁盘格式文件：虚拟机将其子操作系统、应用、存储和配置（如IP地址）存放在一个文件里。这个文件——虚拟机磁盘格式（VMDK）或虚拟硬盘（VHD）文件，包含了整个操作系统环境以便能进行简单的虚拟机装载和保存。这个文件不仅包含了操作系统镜像和应用编码，还描述了虚拟机所需的配置，其中包括虚拟处理器、内存和设备。这个简单的可移动文件包含了组成服务器所需的一切信息、服务器环境描述、实际码和数据。从虚拟机磁盘文件启动虚拟机时系统会自动迅速设置所有参数。在灾难恢复站点进行恢复会变得很简单，只需启动VMHD或VHD。

物理工具到虚拟工具： 虚拟机解决方案需要利用管理工具来创建、启动、停止和保存虚拟机镜像。为了方便创建虚拟机，有很多工具可以帮助分析物理服务器和从服务器创建VMDK或VHD。从物理系统创建的VMDK或VHD文件可以很快地部署到恢复站点。硬件再利用：恢复站点的虚拟机硬件不必闲置在那里等着灾难发生，它也可以用作开发、测试或其它用途。当发生灾难时，关闭用于测试或开发的虚拟机，然后启动生产虚拟机，这个过程只需几秒钟即可完成。

灾难恢复的复杂性剖析

由于用户对于服务器虚拟化技术接受程度不断提高，业界有一种对于所谓的“万能的高可用策略”的需求。虽然这种做法可以在一定程度上通过集群故障迁移技术实现简化数据保护的步骤，但并不是所有的数据保护都支持这种做法。

首先，即使当前关于服务器虚拟化部署最乐观的预测成为现实，到2016年也仍然有21%的X86平台的关键业务（产生收入的高性能事务处理程序）运行在高达75%的没有使用任何虚拟化技术的物理服务器上。所以，针对虚拟化和非虚拟化的不同服务器采用不同的策略是很有必要的。

在采用了 x86 虚拟化技术的工作负载中，一些虚拟机（VMs）和它们对应的数据盘（表现为VMDK 和 VHD 文件）相比其他虚机和数据盘次要一些。在没有使用虚拟化技术的环境中存在很多不同的虚拟程序，但并不是所有的应用程序都是关键业务相关。传统的服务器环境中，一些应用程序和虚拟机被频繁使用，也有一些使用的不是那么频繁，这些现实情况都影响着数据备份和数据复制的频率和策略。

如何制定灾难恢复计划

数据中心工作人员和业务相关人员花了很多时间和精力在到制定和测试灾难恢复脚本上。

首先,预测潜在的数据中心灾难：灾害性天气,停电,供应商系统脱机,内部人员的破坏或外部攻击都是有可能的。

确定公司的灾难恢复应用程序要立即在线。审核清单和优先考虑日常运作的重点程序。

接下来, 原始资料和安装冗余数据中心基础设施——服务器、软件、网络连接、支持应用程序的载体,。灾难恢复计划无法避免成本考虑;一个离线数据中心是昂贵的。

通常, 灾难恢复计划要求复制每个应用程序的基础设施组件。此外, 灾难恢复需要和主备份站点网络连接，给备份系统当前的软件信息。

适当的工作人员需要了解如何调用备份进程。他将决定哪些系统使用和哪些员工应该更换系统备份。灾难恢复的职责包括通知他们的网络和系统提供商更改的数据和确保员工知道如何恢复系统。理想情况下,业务用户只是略有影响。IT团队需要在灾难恢复数据期间提供最新的备份资料程序给工作人员。

IT部门经常花很多时间在设计和分析物理灾难恢复计算环境上,而不是把时间用在编码和测试中增加价值。测试一个灾难恢复计划,数据中心团队要和相关的操作系统和所有最新的补丁一起测试需要,接收、框架、堆叠和安装硬件。他们创建灾难恢复用户账户,部署框架或应用程序服务器环境和安装测试工具。程序员可以花一半的时间在普通的灾难恢复基础设施问题上,而不是把时间用在实际的测试程序。

因为灾难恢复过程复杂,企业通常一年一次或两次进行测试偶发性的灾难恢复计划。公司越大,对灾难恢复计划证明过程越复杂。

一旦灾难恢复程序进入计划,他们很快变成过时。应用不断变化,因此团队必须在经常审查和更新灾难恢复程序。大公司在计划的每个细节上花费员工众多的时间和高达7位数以上的金钱($1,000,000+)。灾难恢复花费更多以确保计划仍然是可行的。

许多企业只是口头上承认灾难恢复。在IT投资上，花大量的时间来缓解这1%,甚至更低的灾难恢复风险似乎并不是个好的投资。IT经理有一份又长又不断增长的日常优先清单,而当灾难发生时，灾难恢复是唯一重要的事。

灾难恢复服务有其局限性。

“云端灾难恢复供应商无法完备份系统冗余,“剑桥公司的灾难恢复分析师Rachel Dines说。

灾难恢复供应商不能证明以模仿每个客户的基础设施设置建设的数据中心成本, 所以他们走捷径。灾难恢复服务提供商将构建系统处理数量有限的故障。理论上讲,如果遇到灾难恢复特定场地的问题，比如数据中心的电力中断，企业将灾难恢复他们的系统,。然而,如果发生重大自然或人为灾害,可能没有足够的空间在灾难恢复站点运行每个灾难恢复服务客户的应用程序。当发现当灾难发生时， IT组织在危难关头唯一能做的是找到它并解决,因为灾难恢复服务比传统的灾难恢复构建有更大程度的风险。

云端的灾难恢复也增加了企业网络带宽的需求。在供应商的云端灾难恢复服务放置应用程序副本和虚拟机(VM)镜像。那些应用程序和虚拟机镜像不断更新,来自企业生产站点与灾难恢复服务供应商的数据中心的数据传输。这种加载应变可用带宽。灾难恢复服务能够很好地处理简单的应用程序,但可能降低网络性能的进程密集型系统,如客户关系管理、企业资源规划应用程序。

Hyper-V的灾难恢复

第一种灾难恢复方式不是很常用，但是据我所知已经至少有一家企业选择使用这种灾难恢复方式。这家企业在微软Hyper-V平台当中运行自己的灾难恢复虚拟桌面，并且将灾难恢复虚拟桌面的备份版本存储在云中以防万一。

对于大规模灾难恢复事件来说，企业 通常会和硬件供应商达成协议，供应商将一批桌面PC租借给企业以供紧急使用，直到企业完全从事故当中恢复为止。根据协议，这些PC将会运行Windows 8并且已经安装Hyper-V。企业的灾难恢复计划是将虚拟桌面的备份版本推送到所有PC上，使用Windows 8当中的Hyper-V功能为用户提供灾难恢复虚拟桌面服务。

然而对于灾难恢复大型企业来说，完成这项灾难恢复计划需要投入异常庞大的工作量，因此灾难恢复可能是不切实际的，但是对于灾难恢复中小型企业来说，灾难恢复确实是一种十分高效的方式。这种灾难恢复方式使得企业不再依赖于任何后台基础架构，就能够恢复虚拟桌面的正常运行。

唯一的要求是DHCP（动态主机配置协议）服务器可以为虚拟桌面分配IP地址。对于这种灾难恢复情况来说，企业可以使用无线路由器提供到PC的网络连接并且分配IP地址。

Windows To Go的灾难恢复

另外一种可行方案是Windows To Go的灾难恢复。这种灾难恢复特性在Windows 8当中被首次推出，灾难恢复允许由USB闪存盘引导启动Windows。-V平台当中运行自己的灾难恢复虚拟桌面，并且将灾难恢复虚拟桌面的备份版本存储在云中以防万一。

采用这种灾难恢复方案的企业需要在遭遇灾难袭击之前，制作大量的USB闪存盘。将这些闪存盘存储在远离办公地点的场所，在遭遇灾难袭击时分发给用户。

不幸的是，使用Windows 7的企业不能采用Windows To Go这种灾难恢复方式，但是可以使用Boot toVHD作为替代灾难恢复解决方案。

不论对于哪种灾难恢复情况，USB闪存盘的容量都将限制虚拟桌面镜像的大小，因此，安装有大量应用程序的桌面镜像并不适合存放在USB闪存盘当中。

这种灾难恢复方式的另外一种缺点是如果想要实现真正的高效恢复，就需要提前花费大量时间准备闪存盘。如果虚拟桌面镜像版本十分稳定，那么并不是什么问题，但是如果企业需要定期更新其虚拟桌面镜像，那么这种灾难恢复方式就变得不切合实际了。

存储同步的灾难恢复

另外一种在VDI灾难恢复领域使用更为广泛的方式是将现有环境构建在多个数据中心，或者灾难恢复直接延伸到云中，但是这种灾难恢复方式是否可行在很大程度上取决于厂商的解决方案。虽然这是一种最为可靠的灾难恢复方式，但是灾难恢复也是最为昂贵的。

横跨数据中心的基本理念是扩展虚拟桌面所在的主机集群，以便能够分布在多个数据中心。同时将保存有虚拟硬盘的存储设备复制到其他数据中心，使用这种灾难恢复方式，可以将虚拟桌面同时存储在两个不同地点。

尽管理论上，可以实现将虚拟桌面故障转移到第二数据中心，但是在第二数据中心创建一个完全分离的虚拟桌面池却是一种更为高效的灾难恢复方式；将虚拟桌面运行在其他位置也会产生网络变更需求。 在一些灾难恢复情况当中，相比于远程恢复现有虚拟桌面，将用户连接到其他位置的虚拟桌面可能会更加容易一些。

离线虚拟桌面的灾难恢复

Mware提供的新特性允许移动办公用户离线查看和使用虚拟桌面。理论上，企业可以使用这种灾难恢复方式实现灾难准备，以灾难恢复应对能够提前通知的、即将到来的灾难，比如缓慢逼近的飓风。

但是这种灾难恢复方式的缺点也十分明显。首先，在灾难已经出现之后采用这种灾难恢复方式并不容易。其次，这种特性只能工作在VMware环境当中。

已经部署VDI环境的企业必须在灾难恢复业务连续性计划当中解决虚拟桌面问题。保证后端服务器资源在灾难袭击之后还能够正常工作是最为基础的部分，但是如果没有虚拟桌面，用户就不能正常访问这些资源。