高可用性的几个级别

本文涉及的产品
传统型负载均衡 CLB,每月750个小时 15LCU
网络型负载均衡 NLB,每月750个小时 15LCU
应用型负载均衡 ALB,每月750个小时 15LCU
简介: 大家常说高可用,High Availablility,但是一般说到这个词的时候,具体指的什么方案呢?本文就将讲述高可用性的几个级别。

大家常说高可用,High Availablility,但是一般说到这个词的时候,具体指的什么方案呢?

级别一:FT (Fault Tolerance) 双击热备

image

通过创建与主实例保持虚拟同步的虚拟机,使应用在服务器发生故障的情况下也能够持续可用。

这种方法常通过使主虚拟机 和辅助虚拟机执行相同顺序的 x86指令来完成此过程。主虚拟机捕获所有输入和事件,并在辅助虚拟机上进行重放。

辅助虚拟机执行与主虚拟机相同的指令序列,如果运行主虚拟机的主机或运行辅助虚拟机的主机发生故障,则会发生即时且透明的故障切换。

虽然FT功能很强大,但是在虚拟化中很少用到FT功能,一是对资源浪费比较严重,二是性能下降比较快,由于是指令级别的同步,因而两台虚拟机之间的距离非常近,无法完全达到容灾的目的,三是如果主虚拟机因为执行非法指令蓝屏,则辅助虚拟机也马上就会发生,根本无法保证业务延续性。

级别二:虚拟机HA

image

虚拟机HA主要指在有一个共享存储池的情况下,当一台物理机挂了,这台物理机上的虚拟机可以迁移到其他物理机的机制。

因为虚拟机是有状态的,因而需要共享存储池来保证状态可以被另外一台物理机读取到。

在HA状态下,虚拟机的恢复时间一般在秒级别,也即当监控探测到物理机挂了之后,可以迅速在空闲的物理机上将虚拟机启动起来。

启动HA的物理机集群可以比较大,可以跨机架,比FT更能起到容灾的目标。

级别三:同城双活

如果一个机架,或者整个机房,甚至整个数据中心着火了,则如何保证业务的连续性呢?

image

一种常用的机制是同城双活,就是在同一个城市,距离大概30km到100km的两个数据中心之间,通过高速专线互联的方式,让两个数据中心形成一个大二层网络。

同城双活最重要的是数据如何从一个数据中心同步到另一个数据中心,并且在一个数据中心故障的时候,可以实现存储设备的切换,保证状态能够快速切换到另一个数据中心。主流的存储厂商都提供在高速光纤互联情况下,在一定距离之内的两台存储设备的近实时的同步,数据双活是一切双活的基础。

基于双数据中心的数据同步,对上看起来可以形成一个统一的存储池,从而数据库层在共享存储池的情况下可以近实时的切换,例如Oracle RAC。

虚拟机在统一的存储池的情况下,也可以实现跨机房的HA,在一个机房切换到另一个机房。

SLB负载均衡实现同一机房的各个虚拟机之间的负载均衡。

GSLB可以实现跨机房的负载均衡,实现外部访问的切换。

如果在两个数据中心距离很近,并且大二层可通的情况下,也可以使用VRRP协议,通过VIP方式进行外部访问的切换。

同城双活一般宣称是实时切换,但是真正实施起来,一般在几分钟到十几分钟,对于数据量比较大的,还会几十分钟。

级别四:异地容灾

image

当你觉得一个地方两个数据中心还是不保险,例如海啸,地震,原子弹等,则可以在异地修建容灾数据中心。

第一大问题还是数据的问题,也即生产数据中心的数据如何备份到容灾数据中心,由于异地距离比较远,不可能像双活一样采取近同步的方式,只能通过异步的方式进行同步,也可以预见的是,容灾切换的时候,数据会丢失一部分。

由于容灾数据中心平时是不用的,不会讲所有的业务都进行容灾,否则成本太高。

对于数据的问题比较建议从业务层面进行容灾,由于数据同步会比较慢,可以根据业务需求高优先级同步重要的数据,因而容灾的层次越高越好。

例如有的用户完全不想操心,则使用存储层面的异步复制,对于存储设备来讲,是无法区分放在存储上的虚拟机哪台是重要的,哪台是不重要的,完全根据块进行复制,很可能先复制了不重要的虚拟机。

如果用户想对虚拟机做区分,则可以使用虚拟机层面的异步复制,用户知道哪些虚拟机更重要一些,哪些虚拟机不重要,则可以先同步重要的虚拟机。

如果用户可以根据业务层情况,在更细的粒度上区分哪些对业务来讲是重要的数据,例如交易数据,需要优先同步,哪些对于业务来讲是不重要的数据,例如日志数据。

在有异地容灾的情况下,可以平时进行容灾演练,看容灾数据中心是否能够真正起作用,别容灾了半天,真用上的时候掉链子。

由于是异地,容灾切换的时间一般在小时级别,几个小时不等。

级别五:异地备份

备份是比容灾更加不灵活的一种方式,和容灾的不同是,容灾需要使得虚拟机的资源时刻准备着,等需要切换的时候,马上就用,数据和虚拟机还是热数据。而备份更多的是以冷数据的方式,将虚拟机镜像,数据库镜像等变成文件存放在价格比较便宜的存储上面,成本比容灾要低得多。

存储可以是专门用于备份的存储设备,也可以使用对象存储等大容量而且成本低的存储。

备份往往区分全量备份和差量备份,一般在重要的时间点保存全量备份,然后以后的一段时间保存差量备份,然后再全量备份,再差量备份。

备份恢复的过程也是从最近的全量备份开始,逐渐补足差量备份,从而达到最接近最终状态的数据。

一旦用到备份,则说明环境已经全部不在,需要重新准备环境来运行虚拟机和存储,所以恢复的时间在天级别。

原文发布时间为:2018-07-10
本文作者:刘超
本文来自云栖社区合作伙伴“程序员小灰”,了解相关信息可以关注“程序员小灰

相关文章
|
6月前
|
算法 关系型数据库 MySQL
TiDB保证数据一致性的策略与优势
【2月更文挑战第28天】TiDB作为一款分布式数据库,通过其独特的策略和优势,确保在分布式环境下数据的一致性。本章将详细探讨TiDB保证数据一致性的核心策略,包括其采用的分布式一致性协议、数据复制机制以及容错处理等方面,并阐述这些策略所带来的优势。通过理解TiDB的数据一致性保证机制,读者将能更深入地认识其作为分布式数据库的价值。
|
消息中间件 存储 SQL
跨系统数据一致性方案的思考(上)
本文主要意在总结沉淀现有问题解决经验过程,整理解决跨系统数据不一致问题的经验方法。 跨系统数据一致性,比较优秀的解决方案就是微服务化,不同应用系统采用统一数据源方式,这样可以有效避免数据一致性问题。 但是我们很多系统由于历史原因或者业务缘由,导致非服务化情况下,又要采取数据一致性方案。
跨系统数据一致性方案的思考(上)
|
6月前
|
存储
云存储中的数据一致性与冗余策略
【5月更文挑战第31天】云存储关键在于数据一致性和冗余策略。强一致性确保所有副本始终同步,可能影响性能;最终一致性允许短暂不一致,最终达一致。多副本策略复制数据提高可用性,纠删码策略通过编码创建冗余。结合两者以平衡性能与准确性。选择合适策略可提升云存储系统性能、可用性和可靠性,未来研究将深化这一领域。
95 1
|
3月前
|
存储 监控 开发者
分布式链路监控系统问题之实现应用级透明的问题如何解决
分布式链路监控系统问题之实现应用级透明的问题如何解决
|
5月前
|
监控 关系型数据库 分布式数据库
PolarDB故障恢复机制:快速恢复与数据一致性保障
【6月更文挑战第29天】**PolarDB云原生数据库的故障恢复机制确保高可用性与数据一致性。利用ROW快照备份实现秒级备份,结合Redo Log进行时间点恢复。通过日志分析定位故障,快速启动备用实例恢复服务。分布式事务及强一致性读保证数据完整性。PolarDB的高效恢复策略是其在云数据库市场中的关键优势。**
133 16
|
6月前
|
监控 NoSQL 算法
Redis集群模式:高可用性与性能的完美结合!
小米探讨Redis集群模式,通过一致性哈希分散负载,主从节点确保高可用性。节点间健康检测、主备切换、数据复制与同步、分区策略和Majority选举机制保证服务可靠性。适合高可用性及性能需求场景,哨兵模式则适用于简单需求。一起学习技术的乐趣!关注小米微信公众号“软件求生”获取更多内容。
328 11
Redis集群模式:高可用性与性能的完美结合!
|
6月前
|
算法 安全 程序员
揭秘分布式系统:日志复制如何保障数据一致性?
本文介绍了分布式系统中的日志复制技术,这是保证高可用性和数据一致性的重要手段。以Raft算法为例,文章阐述了Leader如何将客户端请求复制到Follower的日志中:Leader首先记录请求,然后通过RPC发送给Follower,等待ACK确认,必要时进行重试。当多数Follower确认后,Leader提交日志并通知Follower。文中还提到了网络分区和日志一致性等挑战,以及应对策略,如超时机制、领导选举、日志匹配和压缩。最后,强调了日志复制在面对故障时确保系统一致性和可用性的作用。
269 4
|
6月前
|
前端开发 JavaScript 算法
分布式系统的一致性级别划分及Zookeeper一致性级别分析
分布式系统的一致性级别划分及Zookeeper一致性级别分析
|
关系型数据库 MySQL 数据库
深入探析MySQL中的隔离性级别:保障数据一致性的关键
在关系型数据库中,隔离性是事务特性中的一个重要方面。它确保了在多个并发事务同时操作数据库时,各个事务之间的操作不会相互干扰,从而保障了数据的一致性和正确性。MySQL作为一款广泛使用的关系型数据库,提供了多种隔离性级别供开发者选择。本文将深入探讨MySQL中的隔离性级别,介绍不同级别的特点、用途以及可能的问题。
381 0
|
定位技术 网络架构 UED
主从副本架构可能存在风险
主从副本架构可能存在风险
154 0
下一篇
无影云桌面