当我们谈论容灾时 是在谈些什么?

云计算
说起容灾,很多同学脑子里冒出”同城双活”,“两地三中心”,“RPO”,“RTO”等等。其实这些名词背后均隐射一层含义,面对一些灾难时候,业务如何做冗余来快速恢复业务。
说起容灾,很多同学脑子里冒出”同城双活”,“两地三中心”,“RPO”,“RTO”等等。其实这些名词背后均隐射一层含义,面对一些灾难时候,业务如何做冗余来快速恢复业务。

容灾是一个非常传统的话题,是在产生IT系统的第一天开始就必须要考虑的问题。总的来说它主要是指“数据中心灾难、区域性灾难和人为误操作”三个方面造成对IT系统的灾难时的恢复工作。

将容灾这个词,分开来看“容”和“灾”。“灾“可大可小,某种意义上来讲就是"单点"问题,例如核心业务部署单台服务器上,这台服务器宕机起不来了,对业务来讲就是一场灾难;而“容”,是解决各种"单点"问题。以资源部署粒度来看,一直在解决单点问题路上,如下图:


业务容灾方案有很多种,但是万变不离其宗,本质上都是通过“冗余”来解决"单点"问题;从而不同维度的单点问题,方案决策因素和成本差异会非常大。

1)为什么要做容灾?

梳理当前系统“灾”,主要有哪些痛点,并对其优先级排序。例如单点隐患,难扩展性,运维成本高等等现状,结合现状进行排序,对后续方案选择至关重要。

2)容灾要做到什么程度能满足当前要求?

设计当前系统“容”,对当前系统潜在灾难逃生通道进行冗余设计,当灾难真正发生,预计多长时间能恢复,或者业务稳定性SLA,如SLA=99.999%。

基于容灾范围和目标,在设计容灾方案重点从以下三方面来考虑评估。

1)成本,包括人力,时间以及资金。对于成本和恢复耗时成反比,业务恢复时间越少,成本也会越高,这是强正相关。

2)可用性,首先考虑引入方案对现有系统增加哪些不确定因素,评估这些不确定对稳定性影响。当前是是单可用区部署,主从数据同步使用强同步;客户计划实现同地域不同AZ粒度容灾。这样一个变化会引入不确定因素,例如AZ之间网络延时和稳定性,如果AZ间网络时常抖动,等待从节点返回ack有延时,线上业务时常被hang。其次考虑当前方案能否满足容灾切换和恢复目标。

3)扩展性,主要为后续业务容灾平滑演进。从某种意义来讲,无论是自建idc还是云厂家在建设数据中心时候都不能无限大,在物理机房限制条件下,如果业务发展足够好,就会存在资源不够,扩展受物理设施限制。因此在容灾方案选择的时候,要有前瞻性,对于set化进行提前布局。

容灾的分类和关键指标rpo和rto。

传统容灾的主要技术

从成本,可用性以及可扩展性做横向对比,容灾主要有以下四种实现方案。

在国内,“两地三中心”的容灾架构已经广泛的被企业级用户认可,成为企业级容灾架构的标准,但由于建设成本高,周期长等原因,实际按照此标准建设的企业少之又少。混合云容灾架构,就是在云环境中实现“两地三中心”,同时利用!云中资源的弹性大幅度降低资源成本和建设以及运维的复杂性。

软件定义一切,云容灾解放企业IT生产力

如果企业客户已经在自己的数据中心中完成了容灾环境的搭建,势必消耗了大量了资源,包括机架空间、电力、IT资源、人力资源等等,而容灾环境本身是一个并不产生经济效应的保障性系统,对企业资源的占用巨大。

云资源池通过软件定义的方式,能够打造与企业内部完全相同的复杂IT环境,实现企业级应用的完整镜像,随着应用容灾系统迁移至云中,可以将企业现有的容灾中心转变成生产中心,从而扩大客户自建数据中心的承载能力,或大幅降低IT资源的运营成本。

随时容灾演练,确保备用环境可用性

在传统的容灾环境中,容灾演练是一个令人头疼的大问题,因为容灾环境的建设不是“一锤子买卖”,随着生产环境和数据的不断变化,容灾环境必须跟随生产环境改变,否则在发生灾难时就无法实现业务的快速切换和启动,因此,定期的容灾演练是必须的。而传统环境中的容灾演练要配合硬件和软件厂商,耗时耗力,效果还往往不尽如人意。

在云环境中,能够轻松实现容灾环境的复制,从而与生产环境并行的实现容灾环境的测试演练,通过实际的演练来验证容灾环境的可用性以及数据的完整性,在演练结束后可以随时将演练环境删除或关停,演练成本和复杂程度都大幅降低。

云容灾实现秒级回滚,解决人为错误

在生产环境中,由于人为的误操作、系统升级、补丁等操作造成的对IT系统以及数据的破坏很难防范,尤其是有一些操作和BUG导致系统在运行一段时间后才能发现故障,而此时容灾环境的数据有可能已经被覆盖,难以恢复。

在云中实现的容灾环境能够借助数据快照、数据日志等功能,除了能够保存最新的业务数据意外,还能够实现数据的秒级回滚。在发现系统出现故障后,不但能够切换到容灾环境中的最新数据,还能够选择过去24小时中的任意时间点进行恢复,从而解决了容灾系统中的脏数据问题。

利用容灾环境切换,实现生产系统的平滑上云

现有的IT生产系统环境往往错综复杂且数据量大,这样的系统往往需要冗长的数据搬迁和环境搭建时间,生产系统面临长时间的停机,无法接受。

在云环境中,容灾解决方案能够与生产系统并行地传输生产数据,并在云中搭建与企业内部结构相同的生产系统镜像环境,待云中数据与生产中心数据同步一致后,以容灾切换的方式使生产业务切换至云上,最大限度地降低了生产环境的停机时间,实现了平滑上云。

容灾虽然是一个非常古老和传统的IT业务,但随着云计算技术的不断成熟和普及,它恰恰成为了一个非常适合率先在公有云中实现的业务。

首先它的建设风险低,与生产系统完全并行,前期投入小,无需提前采购,而且它还能够成为企业上云过程中建设自身团队云能力的一个绝好机会,经过云容灾项目之后,企业对云资源、云技术都会有一个全面的了解,且能够利用这个机会验证云环境承载企业生产系统的能力到底如何,再逐步实现企业级IT环境的云转型。

云容灾行业面临的挑战

取代传统容灾思维,将“如何有效利用云资源构建高效可靠的容灾服务,保障IT基础架构设施的安全性和稳定性,从而确保业务的持续性稳定增长”,作为企业高效安全智能地保护数据、赋能业务增长而思考的首要问题。在当前情况下,云容灾行业将面临全新挑战:

1.云原生能力

我们不难发现云原生带给IT产业一次重新洗牌,从应用开发过程到 IT 从业者的技术能力,都是一次颠覆性的革命。在此基础上,出现了基于云原生平台的 Open Application Model 定义,在云原生平台基础上进一步抽象,更加关注应用而非基础架构。同时,越来越多的公有云开始支持 Serverless 服务,更加说明了未来的发展趋势:应用为核心,轻量化基础架构层在系统建设过程中的角色。

这种大的趋势下,传统的迁移和容灾仍然停留在数据搬运的层次上,而忽略了面向云的特性和用户业务重新思考和构建。云计算的愿景是让云资源像水、电一样按需使用,所以基于云上的迁移和容灾也理应顺应这样的历史潮流。

传统的容灾往往以存储为核心,拥有对存储的至高无上的控制权。并且在物理时代,对于计算、存储和网络等基础架构层也没有有效的调度方法,无法实现高度自动化的编排。而基于云原生构建的应用,核心变成了云原生服务本身。当用户业务系统全面上云后,用户不再享有对底层存储的绝对控制权,所以传统的容灾手段,就风光不在了。

在构建云原生容灾的解决方案上,要以业务为核心去思考构建方法,利用云原生服务的编排能力实现业务系统的连续性。云原生架构也可以更好的提升业务稳定性,最大程度的降低了企业内耗。

2.多云的支持能力

国外的云计算市场稳定成熟,比如,公有云市场最主要的云运营商只有AWS、微软Azure、和Google Cloud,可谓“三足鼎立”。而我国云计算市场则是大相径庭:我国实际运营的公有云至少在10朵以上,这个局面更像是“群雄逐鹿”;再加上专有云、私有云的各种产品,让用户在第一时间无从选择。

国内云市场纷繁复杂,很多企业用户为避免单一厂商锁定的问题而选择混合云作为长期的云平台建设战略。混合云目前是用户建设云平台的首选方案,采用多云策略的企业将面临更大的云容灾挑战,这就要求云容灾工具能够更好的对多云环境进行适配,满足用户跨云容灾的需求,真正实现用户的业务数据跨云流转成为常态。

3.更复杂的混合云场景

传统IT架构和云并存的情况下,企业用云的环境更加复杂。从本地到云,从云到云(包括公有云,私有云),上云,下云的容灾,都给容灾厂商带来一些新的场景下的挑战,需要改变传统思维,来满足多样化的需求。

4.及时恢复能力提升

数据恢复的快慢,很大程度上制约着业务恢复的进度,容灾恢复过程中不对原始备份数据产生任何影响,最大限度减少因灾难或故障造成核心业务中断的情况发生,有效保证原始备份数据安全的同时,也为备份数据的验证奠定基础。在用户大量使用公有云和线路的情况下,及时恢复的解决方案面临更大的挑战。

5. CDP(continual data protection)连续数据保护能力提升

CDP(continual data protection)连续数据保护,是一种在不影响主要数据运行的前提下,可以实现持续捕捉或跟踪目标数据所发生的任何改变,并且能够恢复到此前任意时间点的方法采用CDP技术以后,用户不必再留出专门的系统备份时间,即使发生故障,数据也可以在短时间内(秒级)恢复到故障之前的任意时刻。用户的数据量与日俱增,一些关键应用的损失会给用户带来巨大损失,因此在追求更高的业务连续性上的要求始终在提升。

责任编辑:华轩 来源: 数字化助推器
相关推荐

2016-08-12 10:11:22

2022-11-11 09:28:57

软件设计DDD

2020-11-16 15:47:05

SaaS软件转型

2022-07-05 09:31:46

基础设施容器Docker

2019-02-19 10:22:07

5G5G手机5G技术

2017-04-05 17:59:29

思科CTO下午茶

2022-04-28 13:02:32

cpu指令编程

2019-06-04 14:36:04

高并发Java架构

2022-03-11 21:28:31

部署开发服务器

2023-08-28 10:33:09

敏捷Scrum理念

2019-03-18 10:08:18

RSACRSA大会 网络安全

2019-12-24 11:19:44

容器DockerLinux

2014-02-06 12:21:35

软件集成

2019-07-30 13:12:22

2016-11-22 23:44:56

2021-11-12 05:59:23

容灾备份5G

2017-03-07 15:43:28

编程语言函数数据结构

2017-10-11 08:40:29

VR服务器移动端

2017-10-11 13:25:00

前端

2021-11-18 21:09:50

流批场景引擎
点赞
收藏

51CTO技术栈公众号