K8S容灾方案的五个关键点

容灾恢复是绝大多数企业级应用的基本要求

在没有Kubernetes也没有容器的时候,备份和恢复解决方案通常在虚拟机(VM)级别上实现。当应用程序在单个VM上运行时,容灾系统适用于这样的传统应用程序。但是,当使用Kubernetes对应用程序进行容器化管理时,这样的容灾系统就无法使用了。有效的Kubernetes容灾恢复方案必须针对容器化架构进行重新设计,并按Kubernetes的原生方式来运行。
传统的基于VM的备份和恢复解决方案,使用快照来收集数据,但这些数据对于某个具体容器化应用并不足够。因为任何一个特定的VM都将包含来自多个应用的数据。如果您尝试通过VM快照来备份APP 1,将会同时获取其他应用的多余数据。但这些数据从容器角度来看又不够:APP 1可能还会将数据存储在其他VM上。因此通过对某个单独VM的快照无法捕获所有APP1的数据。

基于分布式体系结构的现代应用需要的容灾方案,需要能够找到特定应用的所有相关数据和配置信息,并能够以零RPO(Recovery Point Objective,复原点目标)和接近零RTO(Recovery Time Object,复原时间目标)的方式进行恢复。

一个有效的Kubernetes容灾解决方案需要具备:

容器粒度的控制
能够备份数据和配置
Kubernetes命名空间感知
针对多云和混合云架构的优化
保持应用的一致性

容灾解决方案必须满足以上五个标准,才能确保Kubernetes上运行的含大量数据的应用程序在容灾恢复的时候,满足服务水平协议(SLA)或相关法律要求。

让我们分析一下为什么这五个标准都很重要。

容器粒度控制
容器粒度控制容灾方案意味着用户可以备份特定的Pod或Pod组,而不是备份整个VM或服务器。这使得用户可以仅快照属于该应用程序的容器。

假设您有一个三节点Kubernetes集群,其中有一个三节点Cassandra环和三个单节点PostgreSQL数据库,分布在三个虚拟机上。使用传统的灾难恢复解决方案,备份群集的唯一方法是备份三个虚拟机。这将导致提取,转换和加载过程带来的复杂性增加,存储成本增加和RTO增加。备份充足数据的唯一方法是备份超出必要数据的更多数据。
使用容器粒度的方式,可以在三个VM上仅备份一个PostgreSQL数据库或三节点Cassandra环,而无需其他任何备份。

Kubernetes命名空间感知
传统的备份和恢复解决方案不是以Kubernetes的方式进行的。
Kubernetes中的命名空间通常运行多个相关的应用程序。例如,企业Kubernetes部署中的一种常见模式是使公司/部门所有的应用都运行在同一个命名空间内。在这种情况下,通常有必要一起备份Kubernetes命名空间中的所有应用程序。

但是,像每个单独的应用一样,命名空间分布在许多虚拟机上。每个虚拟机可能还有来自几个不同命名空间的Pod。如果没有支持命名空间的容灾解决方案,则完全备份将需要备份和存储远远超出必要的数据。即使采用了这种过分的备份策略,在发生故障的情况下也很难还原整个命名空间,从而导致较高的RTO。

应用的一致性
即使您想通过备份系统中的所有VM来解决上述问题,使用传统的容灾恢复方案也很难避免数据损坏。为了成功地备份分布式应用,而没有数据损坏的风险,在快照进行过程中,必须锁定应用程序中的所有Pods。基于VM的快照无法实现此目的,因为它们无法锁定整个应用程序,无法跨多个VM执行应用一致性的快照。
成功的快照,要使数据损坏风险最小化,并必须保持分布式架构的应用的一致性。这意味着在锁定属于应用程序的所有Pods的同时,来执行快照。

数据和配置备份

容灾系统的目标不仅是防止数据丢失,还在于保持RTO较低。您需要应用程序在遇到问题后尽快重新启动并运行。
这需要备份应用数据和配置信息。如果备份中不包含配置信息,则必须就地重建应用程序,这是一个缓慢,手动且可能容易出错的过程。但是,如果仅保存配置,则可能会丢失所有数据。


一个真正的Kubernetes的企业级容灾系统将同时包含数据和配置备份。这样在系统失败后,可以用一两个命令快速重新部署应用程序。

针对多云和混合云架构进行了优化
绝大多数企业在实践中,应用程序至少在两个环境中运行。这可能意味着多个本地数据中心或多个Amazon Web Services(AWS)区域。在容灾恢复的情况下,通常将一个数据中心作为主站点,而将第二个数据中心作为备份站点。但是,也有许多公司使用公有云和本地数据中心的组合来运行应用程序并满足其业务需求。在大多数情况下,企业会根据其RPO和RTO要求选择最佳的架构方式。

对于容灾恢复解决方案而言,结合这些不同的架构方式以支持不同级别的RPO和RTO至关重要。有效的容灾恢复解决方案应该能够提供同步和异步数据复制,具体取决于主群集和备份群集之间的延迟。

当主站点和备份站点之间的往返延迟通常在10毫秒以下时,可以实现允许RTO和RPO为零的同步复制。这种情况通常是当主集群和备份群集所在数据中心地理相距较近。
在某些情况下,企业希望主站点和备份站点之间的地理距离远一些。在这种情况下,RTO仍可以为零或接近零。但是延迟的增加,同步复制数据会产生比较大的性能问题。如果应用能够接受15分钟或1小时的RPO,则也是可接受的容灾方案。

Kubernetes的企业级容灾恢复方案,应为用户提供适用于多云或混合云架构的,同步复制或异步复制的选择。这样可以使用户能够基于自己的数据中心架构和业务需求情况,来选择不同的容灾恢复方案。

结论
当企业将关键业务应用迁移至Kubernetes时,重新思考和设计容灾恢复的方案非常重要。实际上可以做到在满足与容灾相关的SLA的同时,
在Kubernetes上运行应用。

但它需要采用专为Kubernetes设计的容灾方法,与Kubernetes的工作方式深入结合。传统的基于VM的容灾解决方案无法做到这一点。

Portworx Enterprise 存储平台是专门为容器和Kubernetes构建的。它可为Kubernetes上运行的应用实现零RPO和接近零的RTO容灾恢复。并具有容器粒度控制的,命名空间感知的,应用一致性的容灾恢复。故障恢复可以完全自动化,从尽可能降低RTO。

原文地址:https://blog.51cto.com/14572152/2458637

时间: 2024-11-08 22:30:43

K8S容灾方案的五个关键点的相关文章

MongDB集群容灾方案步骤

MongoDB复制集优/特点支持大数据量.高扩展性.高性能.灵活数据模型.高可用性.同步机制数据复制的目的是使数据得到最大的可用性,避免单点故障引起的整站不能访问的情况的发生,Mongodb的副本集在同一时刻只有一台服务器是可以写的,副本集的主从复制也是一个异步同步的过程,是slave端从primary端获取日志,然后在自己身上完全顺序的执行日志所记录的各种操作(该日志是不记录查询操作的),这个日志就是local数据库中的oplog.rs表,默认在64位机器上这个表是比较大的,占磁盘大小的5%,

【亲述】Uber容错设计与多机房容灾方案 - 高可用架构系列

此文是根据赵磊在[QCON高可用架构群]中的分享内容整理而成.转载请事先联系赵磊及相关编辑. 赵磊,Uber高级工程师,08年上海交通大学毕业,曾就职于微软,后加入Facebook主要负责Messenger的后端消息服务.这个系统在当时支持Facebook全球5亿人同时在线.目前在Uber负责消息系统的构建并推进核心服务在高可用性方向的发展. 前言 赵磊在7月21号的全球架构师峰会深圳站上,做了主题演讲:Uber高可用消息系统构建,对于这个热门主题,高可用架构群展开了热议,大家对分布式系统中的各

keepalived容灾方案,实现nginx负载均衡主从架构

环境准备: 2台nginx服务器,2台负载均衡nginx服务器 一: 第一步首先准备好环境,2台可以使用yum源直接安装nginx,用来显示测试页面,测试显示页面内容为本地服务器的ip地址,如下图所示: 原文地址:https://www.cnblogs.com/bobo-wq/p/11509410.html

容灾备份一体机顺利通过山东省多家医院、法院测试

联鼎软件容灾备份一体机智能鼎成功到达济南并接受客户的考验,目前已经对山东省内多家医院.法院顺利完成测试,并获得了客户的一致认可,解决了客户一体化容灾备份的难题,保证客户的应用不间断,数据不丢失.联鼎软件的智能鼎很好的向客户展示了产品简便快捷的管理操作.快速的业务接管能力等优势. 联鼎软件推出的智能鼎(集群容灾一体机)是一组软硬件高度集成的设备集合: 智能鼎(集群容灾备份一体机)作为一款国内领先的保障核心业务数据与应用安全的设备,它将备份.容灾等功能与高性能的硬件设备集成于一体,突破了传统业务系统

数据容灾在数据库容灾领域中的比重及其意义

数据容灾只是确保数据安全的一个方案,当这个方案无法保障数据安全时,需要专业的数据恢复工具对其原有数据或者备份数据进行数据恢复.无论采用哪种容灾方案,数据备份还是最基础的,没有备份的数据,任何容灾都没有现实意义.但光有备份是不够的,容灾也必不可少.容灾对于IT而言,就是提供一个防止各种灾难的计算机信息系统.     数据容灾根据不同时机需求可以有不同的等级.中小企业通常只需采用本地容灾即可.所谓本地容灾就是在企业网络本地所进行的容灾措施,其中包括在本地备份.存储.保管备份媒体.在一些大众型企业,所

【容灾】RTO和RPO

要建设容灾系统,就必须提出相应 的设计指标,以此作为衡量和选择容灾解决方案的参数. 目前,国际上通用的容灾系统的评审标准为Share 78,主要包括以下内容.  ●备份/恢复的范围  ●灾难恢复计划的状态  ●业务中心与容灾中心之间的距离  ●业务中心与容灾中心之间如何连接  ●数据是怎样在两个中心之间传送的  ●允许有多少数据丢失  ●保证更新的数据在容灾中心被更新  ●容灾中心可以开始容灾进程的能力  Share 78只是建立容灾系统的一种评审标准,在设计容灾系统时,还需要提供更加具体的设计

云环境下的容灾

声明: 本博客欢迎转发,但请保留原作者信息! 博客地址:http://blog.csdn.net/halcyonbaby 内容系本人学习.研究和总结,如有雷同,实属荣幸! 云环境下的容灾 什么是容灾? 简单的说是对灾难的而应对策略.比如火灾,盗窃,人为损坏,火山,地震,洪水,战争,飓风等自然灾害或者人为灾害. RTO/RPO RPO(Recovery Point Objective): 指灾难后可能恢复到的时间点.涉及丢失业务数据的多少. RTO(Recovery Point Time): 指灾

Redis存储及容灾策略

Redis利用内存发挥的高性能读写在很多场景下大有所为,但是Redis本身毕竟还是一个单机数据库,如果系统对其属于强依赖,那么还是必须做好必要的容灾,针对这个问题,有以下几种策略: 一.M/S切换 由于Redis是单机数据库,所以针对MySQL的一些容灾方案也能顺利适用,例如当Redis意外宕机,可以将请求马上切到备库,同时快速恢复数据. 二.AOF Redis有两种持久化的方式,分别是SnapShotting和Append-Only File,其原理和特性可以参考<对redis数据持久化的一些

阿里云负载均衡升级:同城容灾进一步提升可用性

为了向广大SLB用户提供更加稳定可靠的负载均衡服务,近期阿里云对其SLB系统进行了升级,优先在杭州和青岛地域部署了同城容灾的本地高可用解决方案,下面就让我们一起来了解一下SLB同城容灾方案. 什么是同城容灾? SLB集群本身,已经实现了各种冗余,包括电力.网络.服务器等.我们单集群可以防止“单路电力故障”.“单边网络故障”.“服务硬件故障”.“系统意外宕机”甚至“整(一)个机柜突然掉电.突然断网.突然宕机”等故障对用户对外服务造成的影响. 但是更大范围的故障,比如整个数据中心不可用,已经不能从S