孙悟空救活人参果树,RTO、RPO是多少?

西游记中,孙悟空一直是神挡杀神佛挡杀佛的存在。

强如如来,擒拿孙悟空,也需要靠打赌。强如观音,让孙悟空服帖,也需要借助紧箍。

唯有一人,只凭借袖里乾坤一招就两次秒杀孙悟空,逼的孙悟空不得不得到处求人搬救兵,最终靠观音菩萨出山,才解决此事。此人就是五庄观主镇元子。

镇元子这个人可不简单,在西游记中出现的人物中,此人水平可以说独一档的存在。天地人神鬼,镇元子属于地仙之祖,论辈分,那如来见了也要叫一声"叔"。

孙悟空能够推倒人参果树,是趁着镇元子外出去听讲"混元道果"。结果师徒在逃跑的路上被回来的镇元子直接抓住。

以孙悟空的性情,能一棒子解决的问题都不算问题,但这次碰到了硬茬子。打不过镇元子的孙悟空最后只能求观音菩萨,利用玉净瓶里的甘露水让人参果树恢复如初。

在企业IT系统中,当"摊上事儿"时,让事件恢复如初也是最常用的方式。

 让事件恢复如初,RTO、RPO很关键

很多IT系统的稳定、可靠直接关系到企业的营收能力,一旦系统出现故障,很可能直接导致生产力下降、收入锐减,甚至让公司声誉受损。

尤其是当前信息技术越来越为企业竞争力要素的时候。试想一下,金融、银行这些机构宕机一天,估计CIO就得卷铺盖走人了。

IT系统不是你想不"宕"就不宕机的。除了人为误操作,很多天灾你是想躲也很难躲掉了。例如突发的地震、洪水,还有瞬间愤怒值爆表的"程序员"等等,很可能直接让系统瞬间崩溃,从而导致宕机,影响业务连续性。

那什么是业务连续性?百度百科是这么说的:业务连续性是企业在发生紧急或中断情况之后维持关键功能运行的就绪程度。当然,简单翻译过来就是,你IT系统遇到事儿后摆平事的能力。

那么这个摆平事的能力怎么来评判呢?那首先需要了解恢复时间目标 (RTO)和恢复点目标 (RPO)两个非常重要的参数。

我们再来看看官方定义:RTO(Recovery Time Objective),是指系统灾难发生后,从 IT 系统从宕机到系统恢复之间的时间。RPO(Recovery Point Objective),是指系统数据能够恢复到系统发生前的哪个时间节点。

用孙悟空救活人参果树的例子来说,RTO就是孙悟空从推倒人参果树到请到观音菩萨使得人参果树恢复如初的这段时间。RPO就是观音菩萨让人参果树恢复到被推倒前的那一刻。

当然,如果你还没明白,这里我用最直白的话来说就是,RTO是说你的业务能停多久,RPO是业务能丢多长时间。

比如,你的数据库当机了。如果你的业务能够忍受30分钟之内启动起来,那么RTO就等于30分钟。

再比如,你的数据库当机了,30分钟后恢复了。如果你的业务能够忍受丢失最后2分钟的数据,那么你的RPO就是2分钟。

 平衡好RTO和RPO,是一种艺术

对于企业IT系统来说,RTO和RPO这两个指标是非常重要的。几分钟恢复业务和几天恢复业务效果是完全不一样的。数据恢复到一天前,还是恢复到一周前,这个对于公司业务的影响也是不一样的。

以银行系统为例,站在企业管理者来说,RTO 越短、RPO 越新,银行在出现宕机后的损失就越小。但这同时也意味着系统开发成本将会急剧上升。如何去平衡RTO和RPO之间的关系,不仅仅是一门学问,更是一种艺术。

目前企业在做数据保护时一般都是通过RPO与RTO两个指标来进行衡量,核心目标就是尽可能的缩短数据回复时间(降低RTO),避免数据丢失(RPO接近于0)。

在理想的情况下,完美的方案当然是RTO及RPO皆为零,当灾难发生后,系统立即恢复,而且完全没有数据丢失,可是其造价是非常昂贵的,而且也不一定有这个必要。因此,最佳方案必须在RTO,RPO,维护及价钱多方面,都能达致平衡。

如今,随着数据的重要性越来越被重视以及云计算的出现,各种数据保护的方式层出不穷,什么CDP、多副本、两地三中心、异地容灾等,这些新技术的出现的一个最终目标,都是尽量的降低RTO和RPO。

那么一个核心问题就是,经过这么多年的发展,企业的IT系统的RTO与RPO是否能够等于0呢?

 RTO与RPO等于0,是忽悠还是硬实力?

如今,随着企业和个人的生产、生活已经与各类互联网应用紧密相连,任何中断都越来越无法忍受。

因此,将数据归档并运到地下室的保险库,并希望永远不再需要它的思维已经成为过去。恢复必须立即发生。

PowerStore Metro Node(城域节点),旨在帮助用户解决业务连续性挑战。

与市面上常见的主动/被动解决方案不同,戴尔易安信PowerStore Metro Node实现了真正的同城双活(主动/主动),允许在两个站点同时写入,并支持恢复点目标(RPO)和恢复时间目标(RTO)同时为零!从而确保在城域地理边界内,用户数据将始终可用且可访问(数据往返时延小于10毫秒)。

此外,PowerStore Metro Node通过其独特的虚机(VM)见证技术,可自动启动站点即时故障转移,这意味着DTO(决策时间目标)也将为零

在上图中,第一个异步(asynch)复制是常见的模式。异步复制是两个不同存储系统之间的周期性传输数据,意味着RTO/RPO/DTO始终大于零。

第二个同步(synch)复制意味着两个存储系统完全镜像。这将提供零的RPO,但RTO/DTO始终大于零,因为必须手动启动故障转移和决策过程。

第三个城域同步,也称为同城双活。在城域复制配置中,两个存储系统完全镜像,并且可以同时在两个位置完全访问数据。这意味着RPO/RTO/DTO始终等于零,不需要时间进行恢复,也不需要做出决策,因为系统可以自主方式做出决策。

PowerStore Metro Node的智能决策通过一个见证来实现,该见证作为一个虚机被安装,可以防止脑裂情况的发生。

因此,当城域配置中的两个阵列彼此失去通信但仍可能处于联机状态时,就会发生脑裂情况。该见证可以防止这些情况的发生,并根据用户定义规则自主做出故障切换的决定,从而使用户再也不用担心人工干预。让RPO/RTO/DTO始终等于零,做的真正意义上的持续数据保护。

END
➤  往期精彩回顾


◆为什么说CXL能重构数据中心?
RDMA——让数据中心“狂飙”?
◆怎么为数据中心CPU“减负”?
【漫画】集中取暖 or 自采暖?
喝酒撸串聊云计算?
云计算“PUA”客户简史
◆云计算最后竟成了"一朵云"?
伪存储专家装X指南进阶版



“点赞”和“在看”也是一种美德!

请使用浏览器的分享功能分享到微信等