高可用性及容灾的几个衡量指标

devopsec 等级 450 0 0

网站可用性

所谓网站可用性(availability)也即网站正常运行时间的百分比,业界用 N 个9 来量化可用性, 最常说的就是类似 “4个9(也就是99.99%)” 的可用性。

高可用性及容灾的几个衡量指标


容灾恢复能力的关键指标 ================================================================================================================

RPO:(Recovery Point Obejective,恢复点目标)是指业务系统所允许的在灾难过程中的最大数据丢失量,用来衡量容灾系统的数据冗余备份能力。高可用性及容灾的几个衡量指标

RTO:(Recovery Time Objective,恢复时间目标)是指信息系统从灾难状态恢复到可运行状态所需的时间,用来衡量容灾系统的业务恢复能力。高可用性及容灾的几个衡量指标

我国的国家标准《GB20988-2007-T 信息安全技术信息系统灾难恢复规范》对灾备数据中心根据RPO与RTO两项指标分成了6个相应的等级,如下所示:

高可用性及容灾的几个衡量指标

高可用性及容灾的几个衡量指标

版权声明:本文为CSDN博主「田攀」的原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.csdn.net/pan\_tian/article/details/23270119

容灾系统的衡量指标和级别有哪些?

容灾系统是指在相隔较远的异地,建立两套或多套功能相同的IT系统,互相之间可以进行健康状态监视和功能切换,当一处系统因意外(如火灾、地震等)停止工作时,整个应用系统可以切换到另一处,使得该系统功能可以继续正常工作。容灾技术是系统的高可用性技术的一个组成部分,容灾系统更加强调处理外界环境对系统的影响,特别是灾难性事件对整个IT节点的影响,提供节点级别的系统恢复功能。

1 容灾系统衡量指标

衡量容灾系统的主要指标有RPO(Recovery Point Object,灾难发生时允许丢失的数据量)、RTO(Recovery Time Objective,系统恢复的时间)、容灾半径(生产系统和容灾系统之间的距离)以及ROI(Return of Investment,容灾系统的投入产出比)。

RPO是指业务系统所允许的灾难过程中的最大数据丢失量(以时间来度量),这是一个灾备系统所选用的数据复制技术有密切关系的指标,用以衡量灾备方案的数据冗余备份能力。

RTO是指“将信息系统从灾难造成的故障或瘫痪状态恢复到可正常运行状态,并将其支持的业务功能从灾难造成的不正常状态恢复到可接受状态”所需时间,其中包括备份数据恢复到可用状态所需时间、应用系统切换时间、以及备用网络切换时间等,该指标用以衡量容灾方案的业务恢复能力。例如,灾难发生后半天内便需要恢复,则RTO值就是十二小时。

容灾半径是指生产中心和灾备中心之间的直线距离,用以衡量容灾方案所能防御的灾难影响范围。

容灾方案的ROI也是用户需要重点关注的,它用以衡量用户投入到容灾系统的资金与从中所获得的收益的比率。

显然,具有零RTO、零RPO和大容灾半径的灾难恢复方案是用户最期望的,但受系统性能要求、适用技术及成本等方面的约束,这种方案实际上是不大可行的。所以,用户在选择容灾方案时应该综合考虑灾难的发生概率、灾难对数据的破坏力、数据所支撑业务的重要性、适用的技术措施及自身所能承受的成本等多种因素,理性地作出选择。

2 容灾级别

按照容灾系统对应用系统的保护程度可以分为数据级容灾、应用级容灾和业务级容灾。

数据级容灾仅将生产中心的数据复制到容灾中心,在生产中心出现故障时,仅能实现存储系统的接管或是数据的恢复。容灾中心的数据可以是本地生产数据的完全复制(一般在同城实现),也可以比生产数据略微落后,但必定是可用的(一般在异地实现),而差异的数据通常可以通过一些工具(如操作记录、日志等)可以手工补回。基于数据容灾实现业务恢复的速度较慢,通常情况下RTO超过24小时,但是这种级别的容灾系统运行维护成本较低。

应用级容灾是在数据级容灾的基础上,进一步实现应用可用性,确保业务的快速恢复。这就要求容灾系统的应用不能改变原有业务处理逻辑,是对生产中心系统的基本复制。因此,容灾中心需要建立起一套和本地生产相当的备份环境,包括主机、网络、应用、IP等资源均有配套,当生产系统发生灾难时,异地系统可以提供完全可用的生产环境。应用级容灾的RTO通常在12个小时以内,技术复杂度较高,运行维护的成本也比较高。

业务级容灾是生产中心与容灾中心对业务请求同时进行处理的容灾方式,能够确保业务持续可用。这种方式业务恢复过程的自动化程度高,RTO可以做到30分钟以内。但是这种容灾级别的项目实施难度大,需要从应用层对系统进行改造,比较适合流程固定的简单业务系统。这种容灾系统的运行维护成本最高。

转自:https://blog.csdn.net/z136370204/article/details/105184371/

本文转自 https://www.cnblogs.com/duanxz/p/5440708.html,如有侵权,请联系删除。

收藏
评论区

相关推荐

30分钟带你了解Web工程师必知的Docker知识
前言 笔者之前和朋友一直在讨论web技术方向的话题,也一直想了解web运维方面的知识,所以特意请教了一下我的朋友老胡,他对web运维和后端技术有非常多的实战经验,所以在本
容易被忽略的5个HTML技巧
对于所有 Web 开发人员来说,无论你选择的是哪种框架或后端语言,都需要大量使用 HTML(超文本标记语言)。 各种框架和编程语言可能会此消彼长,但 HTML 永不会过时。只是,就算 HTML 的应用如此广泛,这种语言中还是有不少多数开发人员都不了解的标签和属性。 而且,尽管市面上有各种模板引擎(例如 Pug)可用,但你仍然需要对 HTML 和 CSS
Kubernetes(k8s)中文文档 Kubernetes概述
简介 Kubernetes(https://www.kubernetes.org.cn/)是一个开源的,用于管理云平台中多个主机上的容器化的应用,Kubernetes的目标是让部署容器化的应用简单并且高效(powerful),Kubernetes提供了应用部署,规划,更新,维护的一种机制。 Kubernetes一个核心的特点就是能够自主的管理容
说说ArrayList的扩容机制
ArrayList是List接口的实现类,它是支持根据需要而动态增长的数组。java中标准数组是定长的,在数组被创建之后,它们不能被加长或缩短。这就意味着在创建数组时需要知道数组的所需长度,但有时我们需要动态程序中获取数组长度。ArrayList就是为此而生的,但是它不是线程安全的,外ArrayList按照插入的顺序来存放数据 ①ArrayList扩容发生
架构与思维:设计容量,到底有多重要 ?
背景 单位每年都会举行运动会,有一个2000m长跑的项目,大约每年报名人员为男选手40人,女选手20人,只有一条橡胶跑道。一次比赛10人齐跑,所以至少需要6场比赛。 2000米的完成时间要求是20分钟,超过20分钟不计数,所以比赛耗时我们计算为20分钟,加上比赛前的动员组织,比赛后的清场,我们假定每场比赛耗时30分钟。 现在我们预估下耗时: 1、60
使用 IoC 容器来简化业务对象的管理
使用 IoC 容器来简化业务对象的管理 有过复杂业务应用编写经验的开发人员都知道业务对象的创建是一件比较麻烦的事儿。这些应用中存在着大量的业务对象,它们之间有着复杂的依赖关系,导致模块之间很容易出现循环依赖。此外,有些对象还有单例要求,依赖之间还有顺序要求,这些更加重了问题的严重性。这种情况下就需要有一种手段来简化业务对象的管理,包括创建和获取,IoC(I
高可用性及容灾的几个衡量指标
网站可用性 所谓网站可用性(availability)也即网站正常运行时间的百分比,业界用 N 个9 来量化可用性, 最常说的就是类似 “4个9(也就是99.99%)” 的可用性。 (https://imghelloworld.osscnbeijing.aliyuncs.com/67633a3236e38841845b1b
Docker 起死回生了
(https://imghelloworld.osscnbeijing.aliyuncs.com/3a5538f299bb09456db9cb4393a8f6de.png) Docker 公司在近两年里一直深陷生存危机。 2019 年时两度更换 CEO、毅然出售企业业务之后,人们对于 Docker 曾经一度看衰。 2020 年 12 月,
如何监控docker的运行状况
目录前言正文查询结果参数解析 前言监控docker容器的运行状态是非常普遍的需求,这就是我们今天的讨论内容。 正文部署了docker容器之后,我们经常会需要查看容器的运行状态,这里介绍一个非常好用的命令: docker stats 如果宿主机上有大量的容器在运行,你会看到所有的容器信息,因此我们也可以查看我们关心的某个容器,假如名字为 builde
Kubernetes Pod 自动扩容 — HPA
Kubernetes 增强了应用服务的横向扩容能力,在应对线上应用服务的资源使用率在高峰和低谷的时候,我们需要能够自动去感知应用的负载变化去调整 Pod 的副本数量,削峰填谷,提高集群的整体资源利用率和应用的服务质量。为此,Kubernetes 1.2 版本中引入 Horizontal Pod Autoscaling (HPA), 它与 kubectl sc
数据库运维做些什么?
一. 数据库生命周期 结合软件生命周期、项目的开展,数据库的生命周期大致可分为这么几个阶段。 (https://imghelloworld.osscnbeijing.aliyuncs.com/8552b8c2942bb8ce23
如何设计一个数据库?
设计两个大模块,存储(文件系统)与程序的实例模块。程序的实例模块划分为:存储管理,缓存机制,SQL解析,日志管理,权限划分,容灾机制,索引管理,锁管理。 为什么使用索引? 假设使用原始的全表查询,那么对于小量数据可能速度并没有影响,但是在大量数据的情况下会使得速度很慢。而索引,则类似于字典中的偏旁部首,加快了查询的效率。 二叉
容器DevOps,原来如此简单
当开发团队把代码提交到 Git 应用仓库的那一刻,他们心里在想什么?祈祷没有bug?渴望回家补觉?产品经理Go Die?对,也不对。因为这只是最终发布万里长征的一小步,接下来要面对测试环境、生产环境、客户环境,我这明明没问题到你那就崩的环境……其实,对开发和运维人员来说,心里最想的是一次创建或配置,可以在任意地方正常运行。据扯,2017年程序员们最痛恨的一首
【deque容器系列一】基于STL源码分析deque容器整体实现及内存结构
本篇文章基于gcc中stl的源码介绍deque容器的整体实现和它的内存结构。 说明一下,我用的是gcc7.1.0编译器,标准库源代码也是这个版本的。首先呢,还是看一下思维导图,如下: 1. deque容器整体源码实现介绍deque容器是stl中顺序容器的一种,之前已经介绍过array和vector了,今天介绍deque容器,deque的本质是一个类模板,它的
怎么让b站不挂
打开知乎和头条,b站又冲上了热榜,这次不是煽情怀旧的跨年晚会,也不是敲钟上市,而是“挂了”b站的程序员跟进迅速,问题也得到了比较快的修复。哈哈哈,上面是热点新闻,下面就是知识点了。最近在学习分布式架构,刚好看到了“两地三中心”的高可用架构,我们云畅享一下,如果b站也用的是两地三中心的架构,还会挂掉不?这里先说明下两个概念:RPO和RTO+ RTO (Reco