故障转移到远程站点是一项成熟的技术，云存储也是如此。但是，如果用户想在中断后将他们的虚拟环境切换到云端，他们将面临独特的挑战。虽然这两个过程都使用复制，但云故障转移要将备份双重复制到云以供以后恢复要复杂得多。故障转移过程使用云作为辅助灾难恢复站点。备用服务器接管故障虚拟机环境，确保应用性能不受影响，然后等待问题解决后再切换回主数据中心。故障后切换到云的过程可以是自动的，也可以是手动的，各有优缺点。让我们定义一些细节。我们在这里谈论虚拟机到虚拟机。使用BareMetalRecovery(BMR)技术，可以将本地物理服务器故障转移到云中的物理服务器，这在技术上是可行的，但不切实际。很少有云灾备供应商支持这一点，因为他们基于虚拟服务器技术。虚拟机架构可以让用户避免在二级数据中心维护相同硬件的问题，这是基于云的容灾解决方案的一大卖点。我们还讨论了公共云环境中的故障??转移。虽然在公司自己的私有云中当然可以进行故障转移，但它违背了公共云提供的易于扩展的目的。您需要了解的内容为什么故障转移到远程站点是一项成熟的技术，但故障转移到云却不是？云本身就是不同之处。毫无疑问，云因其可扩展性和可负担性而具有吸引力。一旦故障转移站点经过测试且全面，维护起来就相对简单了。在虚拟环境故障转移方面，您不必像在远程站点那样维护几乎相同的硬件，并且您可以获得近乎无限的可扩展性的好处。然而，将生产数据故障转移到云端确实存在挑战。维持简单备份数据的服务水平的风险相当低。公共云可靠性高，可用性高，并且由于分布式操作而不断增加。但是，当涉及到关键业务应用程序时，备份和存储带来的云存储风险会急剧上升。由于通过Internet传输数据的速度很慢，将虚拟化生产数据远程故障转移到云是相当新颖的，具有可接受的恢复时间目标(RTO)和恢复点目标(RPO)。如果您有必要的带宽，将服务器映像备份到云端是相当简单的。但是在故障转移场景中在云中运行这些应用程序是一个完全不同的故事。首先，VMware和Hyper-V需要单独的故障转移域；此外，特定的应用程序可能需要配置不同的域，以便为故障转移应用程序提供适当级别的服务。在将应用程序移交给云灾难恢复站点之前对其进行测试。亚马逊、谷歌、Azure等大型公有云可以满足高性能低服务的需求，但需要测试自己的带宽和配置。带宽投资在将云用作灾难恢复站点方面起着重要作用。一个虚拟化的数据中心需要巨大的快照，以及大量的巨大快照。快照的有效管理是有效管理云故障转移灾难恢复站点的关键，尤其是当您正在考虑可以减少数据传输时间的云网关产品时。快照在低流量环境中非常好，但在高容量复制环境中，快照可能成为瓶颈。不管你是否使用云网关，你只需要复制增量数据变化，并进行去重和压缩。如果您的服务级别允许，您还需要避免不断复制快照。持续或近乎持续地复制快照会消耗以太网资源，更不用说互联网带宽了。无论如何，高效的快照算法对于成功的云故障转移至关重要。安全性和可用性另一个挑战是安全性。在云中保护备份和存档数据很重要；保护和访问生产数据更为重要。您需要可靠性和可用性：可靠性，这样云服务提供商就不会丢失您的数据；可用性，以便您可以在需要时访问您的数据。与服务提供商合作确定服务级别。虽然您支付的不仅仅是简单的备份和恢复费用，但在应用程序方面，您不希望出现任何问题。对加密级别进行研究并决定是否加密静态数据（可能）和传输中的数据（可能会或可能不会）。还要注意多租户问题。公共云是一个大规模的多租户环境。一个风险是，如果其他租户突然消耗大量资源，您的性能就会下降。您最不想看到的是当您的应用程序从云灾难恢复站点启动并运行时，其他人突然使用您的资源。了解公共云提供商和灾难恢复供应商如何保护您免受其他租户和系统故障的影响。另一个潜在的问题是自动故障转移。灾难恢复自动化通常是关键灾难恢复的最佳实践，但由于所谓的脑裂事件，它并不是万灵药。当虚拟机级别的错误触发自动故障转移时，即使虚拟机实际上并未处于故障状态，也会发生裂脑事件。在2015年，自动故障转移到云在监控路径和事件方面有所改进，但这仍然是一个需要注意的问题。在许多情况下，一旦虚拟机出现故障就提醒IT团队可能是比纯自动化更合理的解决方案。动态云是一个动态环境，但成功的故障转移取决于用户能够找到迁移的应用程序及其数据。供应商提供的一种选择是使用基于云的集群作为故障转移灾难恢复站点。MicrosoftWindowsServer使用集群方法作为内部站点和远程站点之间经过验证且可靠的灾难恢复技术。但是，基于Windows的集群需要访问ActiveDirectory。这意味着IT人员需要将ActiveDirectory扩展到云端，这反过来又需要网络ActiveDirectory和云ActiveDirectory之间的持续同步。一种更常见的方法是将虚拟机及其数据复制到云端，以便在发生本地故障时，可以透明地将用户重定向到云端。这种架构的缺点是需要解决IP地址和DNS记录的变化，以适应不断变化的生产站点。如今，大多数服务提供商和供应商都会为您传输更改，或提供工具来简化此操作。例如，AmazonRoute53的DNSWeb服务为开发人员和用户自动执行这两种类型的更改，从而更容易在云中执行故障转移过程。解决问题的另一种方法是让新供应商从头开始开发基于云的灾难恢复解决方案。Zadara推出了虚拟私有存储阵列（VPSA），利用公有云在AWS等云服务商的平台上提供企业级容灾服务，实现动态地址变更自动化。#p#为什么要打扰？因为物有所值一旦您获得正确的设置和服务级别，虚拟故障转移到云是一个出色的灾难恢复解决方案。虽然初始设置和测试很复杂，但这比租用一个远程站点并实际构建另一个辅助数据中心要容易，更不用说确保硬件和软件基本相同的麻烦和风险了。相反，您正在复制到一个高度灵活、动态可扩展的环境中；对于任何试图保持两个数据中心同步的人来说，这是一个巨大的考虑因素。您可能想花钱购买更高的带宽，或者至少购买一种提供带宽优化技术的产品——同时投资于两者。然而，一旦你进行了额外的投资，所需的日常成本是相当合理的。除了避免建立和维护二级数据中心的费用外，也无需花钱为二级数据中心配备人员。您还可以让现有IT员工腾出时间来处理不同的高价值项目。管理与正常管理非常相似。如果您已经在使用VMware或Hyper-V工具复制到辅助数据中心，则可以使用相同的工具复制到云。第三方产品也是如此，因为它们尽可能多地保留了熟悉的管理程序控制台和工具集。例如，Hyper-V使用以Azure为中心的Hyper-VReplica和AzureSiteRecoveryManager在Azure的虚拟机管理器(VMM)云中实现虚拟机的复制和故障转移。Hyper-V恢复管理器(HRM)可以自动执行此过程的更多部分。VMware提供站点恢复管理器(SRM)；其新的公共云恢复产品是VMwarevCloudAirDisasterRecovery。与SRM不同，AirDR为VMwarevSphere提供原生云灾难恢复。vCloudAirDR建立在vSphereReplication的异步复制和故障切换技术之上。不仅仅是为了灾难恢复云故障转移有很多驱动因素。灾难恢复是主要驱动力，但数据迁移、测试/开发和其他流程也可以从中受益。?虚拟机迁移。云故障转移也适用于虚拟机迁移等计划流程。Nutanix用户声称他们使用NutanixCloudConnect作为迁移虚拟化Web应用程序的故障转移站点。Nutanix使用NutanixPrism和CloudConnect管理公共云中的备份和恢复、灾难恢复和测试/开发。基于云的控制器虚拟机(CVM)集群的行为与远程集群完全一样。数据相应地从内部集群传输到云端。在计划迁移的前几天，用户通过手动关闭虚拟机，等待自动故障转移完成，然后激活云集群，将所有受影响的应用程序和数据转移到云端。然后，当一切准备就绪后，他们将应用程序和数据恢复到新环境。?灾难恢复测试。灾难恢复测试历来繁琐、不切实际且耗时，这就是为什么许多公司很少测试灾难恢复场景的原因。借助云故障转移，IT人员可以轻松测试故障转移过程和恢复时间，而无需花时间构建相同的远程数据中心。ZertoVirtualReplication是一款基于hypervisor的复制产品，支持云端大规模容灾和测试，也支持自动故障转移和回切。UnitrendsReliableDR管理并自动执行针对多VM应用程序的特定于应用程序的测试，并确保虚拟化生产环境中的故障??转移。?裸机恢复(BMR)。云虚拟化还可以帮助进行裸机恢复。裸机恢复是在发生故障时恢复相同系统的过程，从操作系统、驱动程序、应用程序一直到生产数据。物理裸机恢复需要相同的硬件环境才能保证无错恢复，否则会遇到严重的错误。在虚拟机环境中，Zetta.net等供应商可以还原虚拟机映像以引导裸机。这有助于裸机恢复过程更加高效且不易出错。考虑到随之而来的所有问题，基于云的故障转移是否值得研究和投资？对于许多公司来说，答案是肯定的；但不适合所有人。如果您有一个运行良好的远程灾难恢复环境，则无需放弃该环境。如果你的公司有多个数据中心，它们之间有复制和灾难恢复系统，当然没有必要丢弃现有的环境。然而，即便如此，IT人员仍应考虑将测试基于云的灾难恢复作为虚拟化服务器环境中的试点项目。虚拟网络发展非常迅速，它们正在生成大量数据。可扩展的云在这些特定环境中提供了真正的优势。原标题：云中的虚拟故障转移：挑战比比皆是
