摘要:AWS 混合云容灾架构不但能够实现企业级的应用云容灾,还能够帮助企业级客户平滑实现企业 IT 的云转型。
在我们谈论容灾时,我们在谈些什么?
容灾是一个非常传统的话题,是在产生 IT 系统的第一天开始就必须要考虑的问题。总的来说它主要是指“数据中心灾难、区域性灾难和人为误操作”三个方面造成对 IT 系统的灾难时的恢复工作。
在中国,“两地三中心”的容灾架构已经广泛的被企业级用户认可,成为企业级容灾架构的标准,但由于建设成本高,周期长等原因,实际按照此标准建设的企业少之又少。而 AWS 的混合云容灾架构,就是在 AWS 的云环境中实现“两地三中心”,同时利用 AWS 云中资源的弹性大幅度降低资源成本和建设以及运维的复杂性。
软件定义一切,AWS 云容灾解放企业 IT 生产力
如果企业客户已经在自己的数据中心中完成了容灾环境的搭建,势必消耗了大量了资源,包括机架空间、电力、IT 资源、人力资源等等,而容灾环境本身是一个并不产生经济效应的保障性系统,对企业资源的占用巨大。AWS 云资源池通过软件定义的方式,能够打造与企业内部完全相同的复杂 IT 环境,实现企业级应用的完整镜像,随着应用容灾系统迁移至 AWS 云中,可以将企业现有的容灾中心转变成生产中心,从而扩大客户自建数据中心的承载能力,或大幅降低 IT 资源的运营成本。
随时容灾演练,确保备用环境可用性
在传统的容灾环境中,容灾演练是一个令人头疼的大问题,因为容灾环境的建设不是“一锤子买卖”,随着生产环境和数据的不断变化,容灾环境必须跟随生产环境改变,否则在发生灾难时就无法实现业务的快速切换和启动,因此,定期的容灾演练是必须的。而传统环境中的容灾演练要配合硬件和软件厂商,耗时耗力,效果还往往不尽如人意。在 AWS 云环境中,能够轻松实现容灾环境的复制,从而与生产环境并行的实现容灾环境的测试演练,通过实际的演练来验证容灾环境的可用性以及数据的完整性,在演练结束后可以随时将演练环境删除或关停,演练成本和复杂程度都大幅降低。
AWS 云容灾实现秒级回滚,解决人为错误
在生产环境中,由于人为的误操作、系统升级、补丁等操作造成的对 IT 系统以及数据的破坏很难防范,尤其是有一些操作和 BUG 导致系统在运行一段时间后才能发现故障,而此时容灾环境的数据有可能已经被覆盖,难以恢复。在 AWS 云中实现的容灾环境能够借助数据快照、数据日志等功能,除了能够保存最新的业务数据意外,还能够实现数据的秒级回滚。在发现系统出现故障后,不但能够切换到容灾环境中的最新数据,还能够选择过去 24 小时中的任意时间点进行恢复,从而解决了容灾系统中的脏数据问题。
利用 AWS 容灾环境切换,实现生产系统的平滑上云
现有的 IT 生产系统环境往往错综复杂且数据量大,让这样的系统上云往往需要冗长的数据搬迁和环境搭建时间,生产系统面临长时间的停机,无法接受。AWS 容灾解决方案能够与生产系统并行地传输生产数据,并在云中搭建与企业内部结构相同的生产系统镜像环境,待云中数据与生产中心数据同步一致后,以容灾切换的方式使生产业务切换至 AWS 云上,最大限度地降低了生产环境的停机时间,实现了平滑上云。
AWS 云中容灾,只为实际使用量买单
从容灾系统的 TCO 上看,AWS 容灾解决方案更是具备明显优势。无需前期对硬件、软件的采购和安装,省去了大量前提投入成本。更重要的是,容灾方案中 AWS 云中资源可以选择不开机或只开启少量小机型资源,对于不开机的资源将完全不收取 EC2 虚拟机资源的费用,又能保持 EC2 虚拟机的状态和后台数据的增量更新。经过我们的测算,一个典型的容灾系统项目,以 5 年为周期进行计算,TCO 只需花费原有私有云容灾环境的 1/3,而第一年的投入资金更是传统项目的 1/10.
总结
容灾虽然是一个非常古老和传统的 IT 业务,但随着云计算技术的不断成熟和普及,它恰恰成为了一个非常适合率先在公有云中实现的业务。首先它的建设风险低,与生产系统完全并行,前期投入小,无需提前采购,而且它还能够成为企业上云过程中建设自身团队云能力的一个绝好机会,经过云容灾项目之后,企业对 AWS 云资源、云技术都会有一个全面的了解,且能够利用这个机会验证 AWS 云环境承载企业生产系统的能力到底如何,再逐步实现企业级 IT 环境的云转型。
(未完待续)
本次分享的内容先到这里,今后我们会继续针对 AWS 混合云容灾架构中的诸多关键技术要点进行细致的分享,敬请期待!
如对 AWS 混合云容灾架构解决方案感兴趣,请联系我们: yuwangcn@amazon.com
作者介绍:
王宇,AWS 企业容灾解决方案业务拓展经理,目前负责 AWS 中国区的混合云、容灾和 DevOps 产品和解决方案。曾服务于 VMware 等传统私有云厂商,熟悉传统 IT 架构和私有云、混合云、公有云的解决方案融合。
本文转载自 AWS 技术博客。
原文链接:
评论