故障切换到远程站点是一项成熟的技术，云存储也是一项成熟的技术。但是如果用户们在遇到故障后想把虚拟环境切换到云端，他们就面临独特的挑战。
虽然这两个过程都用到复制，但云故障切换要双将备份内容复制到云端以便之后恢复复杂得多。故障切换过程使用云作为辅助的灾难恢复站点。备用服务器接手处理出现故障的虚拟机环境，确保应用程序性能不受影响，然后等问题解决后，再切换回到主数据中心。出现故障后切换到云的过程可能是自动化，也可能是人工的，各自有其优缺点。
不妨定义一些细节。我们在此谈论的是虚拟机到虚拟机。使用裸机恢复(BMR)技术，将内部物理服务器故障切换到云端物理服务器在技术上可行的，但是这不切实际。很少有云灾难恢复厂商支持这么做，因为它们基于虚拟服务器技术。虚拟机架构让用户得以避免在辅助数据中心维护相同的硬件这个问题，这是基于云的灾难恢复解决方案的一大卖点。
我们还会探讨公有云环境下的故障切换。虽然故障切换在公司自身拥有的私有云中肯定可行，但是它有悖于公有云提供的易于扩展这个初衷。
你需要了解的方面
为何故障切换到远程站点是一项成熟技术，而故障切换到云端却不是?云本身是区别所在。
毫无疑问，云因灵活扩展、经济实惠而很吸引人;一旦故障切换站点经过了测试，而且很全面，维护起来就比较简单。就虚拟环境故障切换而言，你不需要像在远程站点那样非要维护几乎相同的硬件，能够获得近乎无限扩展的好处。然而，将生产环境数据故障切换到云端也确实存在诸多挑战。
保持服务级别
单单备份数据的风险相当低。公有云的可靠性很高，可用性也很高，而且因分布式操作而在不断提高。但是说到关键的业务应用程序，备份和存储引起的云存储风险就会急剧加大。由于通过互联网传输数据速度缓慢，在恢复时间目标(RTO)和恢复点目标(RPO)可以接受的情况下，将虚拟化生产数据远程故障切换到云端是相当新颖的做法。
如果你有必要的带宽，将服务器映像备份到云端相当简单。但是在故障切换场景下在云端运行那些应用程序却完全不同。首先，VMware和Hyper-V需要各自不同的故障切换域;此外，特定的应用程序可能需要配置不同的域，以便为故障切换的应用程序提供合适的服务级别。
将应用程序交给云端灾难恢复站点之前先要进行测试。亚马逊、谷歌、Azure及其他大型公有云都能满足以较低服务提供较高性能的需要，但是你需要测试自己的带宽和配置。
要在带宽方面投入
带宽在使用云端作为灾难恢复站点方面起到了重要作用。虚拟化数据中心会生成庞大快照，而且是大量的庞大快照。想有效地管理云端故障切换灾难恢复站点，有效管理快照是关键所在，如果你在考虑一款可以缩短数据传输时间的云网关产品，更是如此。快照在低流量环境下完全没有问题，但是在大容量复制环境下，快照会成为瓶颈。
无论你是否使用云网关，只需复制变化的增量数据，并实行重复数据删除和压缩。如果你的服务级别允许，还需要避免不断地复制快照。不断或近乎不断地复制快照会耗用以太网资源，更不用说耗用互联网带宽了。不管怎么样，高效的快照算法对成功的云端故障切换而言必不可少。
安全性和可用性
另一个挑战是安全性。为云端备份和归档数据确保安全很重要;保护及访问生产数据更是重要得多。你同时需要可靠性和可用性：之所以需要可靠性，是因为那样云服务提供商不会丢失你的数据;之所以需要可用性，是因为那样你在需要访问自己的数据时，可以随时访问。与服务提供商一起敲定服务级别。虽然你支付的费用高于简单的备份和恢复，但是说到应用程序，你不希望有任何闪失。
在加密级别方面做好调查工作，并且决定要不要加密静态数据(可能需要)和传输中数据(可能需要，也可能不需要)。另外要留意多租户问题。公有云是一种大规模的多租户环境。一个风险是，如果其他租户突然耗用大量资源，你的性能就会下降。你最不希望看到的一幕是，就在你的应用程序从云端灾难恢复站点启动运行时，别人的突然使用抢占了你的资源。要弄明白公有云提供商和灾难恢复厂商如何保护你，远离其他租户及系统故障的影响。
另一个潜在问题出现在自动化故障切换上。灾难恢复自动化通常来说是关键灾难恢复的一个***实践，但由于所谓的脑裂事件(split-brain event)，它也不是什么“灵丹妙药”。当虚拟机层面的错误引发自动化故障切换时，尽管虚拟机实际上并未处于故障状态，就会出现脑裂事件。2015年，出现故障后自动切换到云端在监测路径和事件方面有所改进，但这仍是需要留意的一个问题。就许多情况而言，一旦虚拟机出现故障，立即提醒IT团队，这也许是比纯粹自动化更合理的解决方案。
动态云
云是个动态环境，不过成功的故障切换有赖于用户能够找到迁移后的应用程序及其数据。厂商提供的一种选择就是，使用基于云的集群作为故障切换灾难恢复站点。
微软Windows Server使用集群方法作为内部站点与远程站点之间一种成熟可靠的灾难恢复技术。然而，基于Windows的集群需要访问活动目录。这就意味着IT人员需要将活动目录扩展到云端，而这又需要网络活动目录与云活动目录不断同步。
一种更常见的方法是，将虚拟机及其数据复制到云端，那样万一内部环境出现故障，用户可以被透明地重定向至云端。这种架构的缺点在于需要解析IP地址和DNS记录的变更，以便适应出现变化的生产站点。
如今，大多数服务提供商和厂商为你传输变更内容，或者提供更容易这么做的工具。比如说，Amazon Route 53的DNS Web服务就可以为开发人员和用户使这两种类型的变更实现自动化，因而更容易在云端执行故障切换过程。解决地址问题的另一个办法就是，新厂商从头开始开发基于云的灾难恢复解决方案。Zadara公司推出了虚拟专用存储阵列(VPSA)，在AWS及其他云服务提供商的平台上，使用公有云提供企业级灾难恢复服务，并且使地址动态变更实现自动化。
#p#
为何操这份心?因为值得一做
你做好了设置和服务级别后，虚拟故障切换到云端是一种出色的灾难恢复方案。尽管初始的设置和测试很复杂，但是这比租用远程站点、实际构建另一个辅助数据中心来得容易，更不用说确保软硬件基本相同带来的麻烦和风险了。相反，你将复制到一个高度灵活、可动态扩展的环境;对于试图让两个数据中心确保步伐一致的人来说，这是需要考虑的重大因素。
你可能想花钱购置更高的带宽，或者至少花钱购置提供带宽优化技术的产品――***同时在这两方面有所投入。然而，一旦你进行了额外的投入，所需的日常成本相当合理。除了可以避免建立和维护辅助数据中心的费用外，没必要花钱为辅助数据中心雇用工作人员。你还可以让现有的IT工作人员腾出手来，处理不同的高价值项目。
管理起来与平常的管理很相似。如果你已经在使用VMware或Hyper-V工具复制到辅助数据中心，可以使用同样的工具复制到云端。第三方产品也是如此，因为它们会保留尽可能多的熟悉的虚拟机管理程序控制台和工具集。
比如说，Hyper-V就使用以Azure为中心的Hyper-V Replica以及Azure站点恢复管理器，在Azure里面的虚拟机管理器(VMM)云中实现虚拟机的复制和故障切换。Hyper-V恢复管理器(HRM)可以使这个过程的更多环节实现自动化。VMware提供了站点恢复管理器(SRM);其新的公有云恢复产品是VMware vCloud Air Disaster Recovery。与SRM不同，Air DR为VMware vSphere提供了原生的云端灾难恢复。vCloud Air DR建立在vSphere Replication的异步复制和故障切换技术上。
不仅仅用于灾难恢复
云端故障切换的驱动因素不一而足。灾难恢复是***的驱动因素，不过数据迁移、测试/开发和另外的过程也能从中得益。
• 虚拟机迁移。云端故障切换还适用于虚拟机迁移等规划的过程。Nutanix用户曾声称，他们使用Nutanix Cloud Connect作为故障切换站点，用于迁移虚拟化的Web应用程序。Nutanix使用Nutanix Prism和Cloud Connect，管理公有云中的备份和恢复、灾难恢复及测试/开发。基于云的控制器虚拟机(CVM)集群运行起来与远程集群如出一辙。数据从内部集群相应地传输到云端。
在规划迁移前几天，该用户将所有受影响的应用程序及数据统统传输到云端，具体方法是：手动关闭虚拟机，等待自动化故障切换完成，然后激活云集群。然后，等一切准备就续后，他们将应用程序及数据恢复到新的环境。
• 灾难恢复测试。灾难恢复测试传统上很麻烦、不现实、耗费时间，这就是为什么许多公司很少测试灾难恢复方案。有了云端故障切换，IT人员就很容易测试故障切换程序和恢复时间，不需要花心思建立相同的远程数据中心。Zerto Virtual Replication是一款基于虚拟机管理程序的复制产品，它支持云端的大规模灾难恢复和测试，另外还支持自动化故障切换和故障恢复。 Unitrends Reliable DR则为多虚拟机应用程序管理针对特定应用程序的测试，并使这种测试实现自动化，而且确保了在虚拟化生产环境下的故障切换。
•裸机恢复(BMR)。云端虚拟化还能帮助裸机恢复。裸机恢复是指万一出现故障，恢复一个相同的系统这个过程，从操作系统、驱动程序、应用程序一直到生产数据。物理裸机恢复需要相同的硬件环境，确保无差错恢复，不然你会遇到严重错误。在虚拟机环境中，Zetta.net等厂商能恢复虚拟机映像，以便启动裸机。这有助于裸机恢复过程大大提高效率，并大大减少差错。
考虑到随之而来的种种问题，基于云的故障切换值得研究和投入吗?对许多公司来说，答案是肯定的;但并非对每家公司都是如此。如果你有效果良好的远程灾难恢复环境，就不需要丢弃这个环境。如果贵公司拥有多个数据中心，这些数据中心之间又有复制和灾难恢复系统，肯定不需要丢弃现有环境。
然而，即便那样，IT人员也应该考虑测试基于云的灾难恢复，作为虚拟化服务器环境下的试点项目。虚拟网络正在非常迅速地扩大，它们在生成大量数据。可灵活扩展的云在这些特定的环境提供了实实在在的优点。
原文标题：Virtual Failover in the Cloud: Challenge Abound
