权衡多云灾难恢复的挑战

许多企业已经开发了云备份策略，但这并不意味着他们应该这样做。企业需要权衡这种方法的挑战和潜在好处。

云灾难恢复可能不是企业希望将其备份策略扩展到云的首选。云计算或私有数据中心的故障风险是引起云架构关注的主要因素。虽然数据备份通常是降低风险的有效策略，但有时它带来的问题可能比解决方案多。企业管理员需要权衡风险，自问云灾难恢复计划是否适合他们的工作负载。

故障注意事项

关于复杂系统的可靠性，有一个简单的经验法则:如果两个元素可以执行相同的任务，它们可以互相备份。这降失败的总体风险。相反，如果两个要素都必须积极工作，才能使复杂的系统正常运行，那么失败的风险就会更高。

因此，要使两个云平台比一个更可靠，每个云平台必须是能够支持备份应用程序的独立资源池。对于选择云灾难恢复策略的组织，这将对架构选择、成本和其他因素产生深远影响。

此外，企业不太可能需要多云天气提供的冗余灾难恢复服务，因为数据中心和云计算因单一故障而瘫痪或中断的可能性非常小。降低风险的一个更简单的方法是使用云平台进行备份，并将其分布到整个可用区域。然后，构建混合云体系结构(云灾难恢复的首选方法)的企业可以相互备份其数据中心和云计算环境。

幸运的是，无论架构师是为混合云灾难恢复还是云灾难恢复而构建，应用程序更改和云计算服务选择基本相同。

为了使用云灾难恢复，企业需要能够跨边界无缝移动工作负载，包括跨云平台和本地数据中心。应用程序必须构建为在任何地方运行，并且运营团队需要将所有托管资源视为一个资源库。对这两种方法的任何限制都将减少云灾难恢复的好处并增加成本。

企业还需要考虑公共云服务的两个级别以及每个级别对云备份策略的影响:

容器和微服务

如果每个云平台都作为云计划的一部分单独管理，则很难在没有人工干预的情况下在环境之间进行故障切换。

企业有两种选择来缓解这个问题。首先是放弃云计算提供商的操作工具。例如，放弃托管的库本内斯，使用红帽OpenShift或VMware虚拟世界等工具从数据中心运行库本内斯生态系统。另一种选择是通过联合方式将企业的云计算提供商托管服务与诸如谷歌云安托斯或国际商用机器公司的卡巴内罗等工具连接起来。

使用微服务和服务网格(如Istio或Linkerd)更容易构建支持多云条件的应用程序。然而，这种方法需要软件重建，这对于一些组织来说可能是一个巨大的飞跃。如果企业选择这种方法，就需要将服务网格与操作工具集成起来。服务网格包括跨云分布的组件发现和工作负载平衡。

成本要求

企业必须平衡云灾难恢复的成本和它将增加的可靠性。不幸的是，对这些因素的准确分析几乎是不可能的，因为为云灾难恢复准备应用程序的成本取决于所涉及的应用程序的数量及其设计方式。

与灵活应用序的部署和重新部署相关的成本取决于这些相同的因素，而企业的运营实践决定了对问题的恢复响应速度，这是获得可靠性的一个重要因素。

不管可靠性如何，云灾难恢复无疑会增加托管成本。如果一个企业的备份资源不能将工作从另一个故障托管点转移到灾难恢复，就没有任何价值，因此企业必须在每个云中保留一些容量来支持任何故障转移。这可能会使企业的云计算托管成本增加至少25%，如果企业的所有应用程序不能容忍很少的停机时间，成本甚至会增加一倍。

唯一的例外是无服务器。因为它遵循按使用付费的定价模式，所以无论企业的组件运行在哪个云平台上，成本往往是相同的。但是请记住，无服务器可能是一种更昂贵的托管选择，尤其是对于需要频繁运行的应用程序，它需要更专业的应用程序设计。

多云不只是灾难恢复

对于大多数企业来说，云发现可能不会带来回报，但这并不意味着使用云是个坏主意。许多企业依靠云技术为全球运营提供有效的云计算服务定位。有些应用程序需要特殊的功能，并非所有云计算提供商都提供这些功能，因此它们最终会为不同的应用程序使用不同的云平台。

云计划意味着企业正在为任何云平台做准备。明智的做法是始终保持选择开放，尤其是当公共云提供商的模式不断变化时。