权衡多云灾难恢复的挑战

很多企业制定了多云备份策略,但这并不意味着应该这样做。企业需要权衡这种方法带来的挑战和潜在收益。

如果企业希望将其备份策略扩展到云端,则多云灾难恢复可能不是首选。云计算或私有数据中心发生故障的风险是引起多云架构关注的主要因素。虽然一般来说,数据备份是一种降低风险的行之有效的策略,但有时它可能带来比解决方案更多的问题。企业管理员需要权衡风险,并询问自己多云灾难恢复计划是否适合其工作负载。

故障注意事项

关于复杂系统的可靠性,有一个简单的经验法则:如果两个元素可以执行相同的任务,则它们可以互相备份。这降低了故障的综合风险。相反,如果两个要素都必须积极工作才能使复杂的系统正确运行,则发生故障的风险会更高。

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

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

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

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

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

•IaaS托管。云计算提供商在不同地理位置为虚拟机提供每个虚拟机不同的资源和不同的服务级别协议。尽管云计算提供商的运营实践通常有所不同,但适应这些差异并不复杂。

•增强Web服务的托管。企业通过一组API使用高级功能。通常,由于功能和编程方面的差异,必须为每个云平台自定义使用Web服务的应用程序。这使开发负担加倍,也可能增加许可和运营成本。

容器和微服务

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

企业有两种选择可以缓解这个问题。首先是放弃云计算提供商的运营工具。例如,放弃托管的Kubernetes,转而使用Red Hat OpenShift或VMware vSphere等工具从数据中心运行Kubernetes生态系统。另一个选择是通过联合方法将企业的云计算提供商托管服务与诸如Google Cloud Anthos或IBM的Kabanero之类的工具连接起来。

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

成本要求

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

与弹性应用程序部署和重新部署相关的成本取决于这些相同的因素,而企业的操作实践决定了恢复对问题的响应速度,这是获得可靠性的重要因素。

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

唯一的例外是无服务器。由于它遵循按使用付费的定价模式,因此无论企业的组件运行哪种云平台,其费用都趋于相同。但是需要记住,无服务器可能是一个更昂贵的托管选项,特别是对于需要经常运行的应用程序,并且它需要更专业的应用程序设计。

多云不只是灾难恢复

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

规划多云意味着企业正在为任何云平台做好准备。始终保持选择的开放是明智之举,尤其是在公共云提供商的格局不断发生变化的情况下。

版权声明:本文为企业网D1Net编译,转载需注明出处为:企业网D1Net,如果不注明出处,企业网D1Net将保留追究其法律责任的权利。

(来源:企业网D1Net)

如果您在企业IT、网络、通信行业的某一领域工作,并希望分享观点,欢迎给企业网D1Net投稿

本文分享自微信公众号 - 云计算D1net(D1Net02)

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2019-10-17

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏自学测试之道

Appscan工具之环境搭建

它是由IBM公司开发的一款在web应用程序渗透测试舞台上使用最广泛的工具,有助于专业安全人员进行Web应用程序自动化脆弱性评估。AppScan 可自动化 Web...

29010
来自专栏追逐时光

.NET之Hangfire快速入门和使用

  定时任务调度问题,是一个老生常谈的问题。网上有许多定时任务调度的解决方案,对于我而言很早以前主要是使用Window计划和Window服务来做任务定时执行,然...

11620
来自专栏汪宇杰博客

在树莓派4上安装 .NET Core 3.0 运行时及 SDK

我最近买了个树莓派4,4GB内存高富帅配置,并安装了官方操作系统Raspbian。今天我成功运行了一个ASP.NET Core 3.0 应用程序。我们来看看怎么...

90840
来自专栏一个爱瞎折腾的程序猿

自定义构建基于.net core 的基础镜像

nuget的包源无法访问(无法ping通),而我在一台服务器上访问https://api.nuget.org/v3/index.json时则会自动重定向到htt...

13220
来自专栏DotNet程序园

用.NET做动态域名解析

动态域名解析,或DNSR,通常用于解析IP地址经常变化的域名。电信网络提供了公网IP,给广大程序员远程办公、内容分享等方面带来了极大的便利。但公网IP是动态的,...

37710
来自专栏me的随笔

.NET Core应用的三种部署方式

FDD:Framework-dependent deployment,框架依赖部署。这种方式针对某个特定版本的.NET Core进行发布,只打包应用本身及.NE...

9410
来自专栏跟着阿笨一起玩NET

ASP.NET Core使用Docker进行容器化托管和部署

8420
来自专栏.Net、.Net Core 、Docker

jenkins在windows上自动化部署.Net(.Net Core)项目

  什么是持续集成呢?Continuous integration(CI)。持续集成是一种软件开发实践,即团队开发成员经常集成他们的工作,通常每个成员至少集成一...

18030
来自专栏追逐时光

.NET Core使用NPOI导出复杂Word详解

  最近使用NPOI做了个导出Word文档的功能,关于使用.NET Core 导出Word文档的方式有很多。最终我为什么选择了NPOI来实现了这个功能,首先是N...

14430
来自专栏汪宇杰博客

“自启动”树莓派上的 .NET Core 3.0 环境

昨天发了一篇《在树莓派4上安装 .NET Core 3.0 运行时及 SDK》,但其实有个坑,只要一重启树莓派,.NET Core环境就丢了,得重新配置 DOT...

10630

扫码关注云+社区

领取腾讯云代金券

年度创作总结 领取年终奖励