本文介绍了云原生环境下，尤其是基于Kubernetes的容器平台，如何应对业务连续性的挑战。探讨了业务连续性、容灾和灾难恢复的概念，强调了容灾能力对企业的重要性。文章详细讨论了容器平台容灾的挑战，如以应用为中心的容灾、异构基础设施支持、多粒度切换需求和管理复杂性。提出了基于备份恢复、数据复制和双活容灾的实现思路，并介绍了YS1000的容灾方案，该方案支持统一管理和监控，适用于有状态和无状态应用的容灾切换，以及异构集群环境。
目录
引言
自从Kubernetes在2015年发布1.0版之后，几乎就奠定了k8s成为容器编排的业界标准，到现在早已成为事实上的云原生操作系统。在云原生的趋势影响下，很多企业要么在新业务中将容器应用运行在k8s容器平台，要么将已有的应用进行容器化改造，运行在容器平台中进行开发、迭代、运维。由于云原生倡导的微服务化，资源池化，灵活敏捷等理念，云原生特别是容器平台对于业务连续性有更高的期待。那么新的问题产生了，对于运行在容器平台上的应用，如何实现业务的连续性？
什么是业务连续性
业务连续性（Business continuity）是一个比较宽泛的概念，通常是指企业在紧急情况下应对风险和快速反应的能力，以保证企业业务的连续运转。对现代化的企业和组织来说，企业的业务通常由IT基础设施来支撑， 因此业务连续性也常常被狭义的认为是应对IT基础设施故障和灾难的能力。
业务连续性对现代化的企业至关重要：
- 让企业有着24*7的可持续运营能力
- 可以确保数据的安全
- 让企业有着竞争优势
- 对企业的声誉和营收也有正面的影响
领先的企业和组织非常重视业务连续性的规划和管理，在新业务上线之前，就会根据业务类型、数据量的大小、数据的重要程度等因素，来制定相应的业务连续性计划。当灾难发生时，能够快速的恢复关键业务的运营，从而将损失减到最低。
什么是容灾
容灾（Disaster tolerance）是指能够容忍灾难的能力，也可以称为应用的韧性（Resiliency）。对于IT系统来讲，要容忍的灾难类型就包括地震、洪水等自然灾害；软硬件故障；网络或病毒攻击；人为蓄意破坏或者误操作等等。容灾常常与灾难恢复相互混用，可以认为容灾就是灾难恢复的能力，那什么是灾难恢复呢？
什么是灾难恢复
灾难恢复（Disaster recovery）是指企业将信息系统从灾难造成的故障或瘫痪状态恢复到可正常运行状态的一个过程。对大多数企业来说，IT系统的灾难恢复是实现业务连续性的一个关键，也可以说是一个子集。
容灾能力建设的主要目的，就是在灾难发生的时候，能够保证生产业务系统的不间断运行。因此，对大部分现代化的企业来说，IT系统容灾能力的建设成为了业务连续性管理的核心部分。
容灾的关键指标
衡量容灾一般有两个重要的指标：
- RTO
恢复时间目标（Restore time objective），指的是所能容忍的业务停止服务的最长时间
- RPO
恢复点目标（Restore point objective），指的是业务系统所能容忍的数据丢失量。下图表示了RTO和RPO的关系：
企业在进行业务连续性规划时，首先要对当前的业务和数据进行一个梳理。对于非关键的业务或者数据，小时级的RPO/RTO可能就已经足够；而对比较关键的业务和数据，可能要求分钟级的RPO/RTO；对于最核心的业务，可能会选择秒级甚至接近0的RPO/RTO。
容器平台的容灾
容器应用对业务连续性的要求
云原生的容器平台代表了技术的新趋势，微服务、敏捷开发、持续集成与发布（CICD）、自动化运维等技术框架以k8s为核心不断的演进。今天的CIO们对部署在容器平台的应用也提出了更高的要求：
- 业务不中断
- 快速响应需求
- 提供24*7的服务
期望容器应用能够提供持续的服务交付。因此，容器平台的应用对业务连续性有着天然的需求。
容器平台实现容灾的挑战
基于k8s构建的容器平台虽然有着各种新技术光环的加持，然而要在容器平台实现容灾却有着各种挑战：
-
以应用为中心的容灾取代以机器为中心的容灾
k8s带来了声明式API，资源编排等先进技术和理念，是一种颠覆性的新技术。然而由于容器的应用组成方式的改变，一个应用不再绑定到某个机器或者虚机，而是在一个集群内部以一组k8s资源、相关的镜像、以及持久化数据等实体构成。因此，在虚机时代以机器为中心的容灾思路不能在容器平台继续应用。在容器平台，必须以应用为中心，根据组成应用的各个实体，例如应用的资源、镜像和数据，分别应用容灾的机制，然后统一的以应用为单位来管理。
-
需要支持容灾站点的异构基础设施和K8s版本
云原生容器发展到现在，已经形成一个非常多样化的生态。一个企业的数据中心可能会使用不同的容器平台，部署多个k8s集群，使用不同的存储。因此在对容器平台进行容灾方案设计规划时，生产集群和容灾集群是异构的基础设施，或者k8s版本不同是一种常态。
-
需要支持丰富的容灾切换粒度：集群级别、应用组和单个应用
应用容器化、微服务化的另一个挑战是，应用数量的激增。对于虚机应用，一个虚机上可能就运行一个或者几个应用，然而一个由10-20台机器或虚机构建的k8s集群，可能会运行几百个应用。对于运维人员来说，由于应用数量的增多，以及应用之间可能有复杂的依赖关系；在管理容器应用的容灾时，最好能够针对单个应用、多个应用的组合或者整个集群所有的应用进行切换的能力，从而给运维人员带来应用粒度的容灾切换和管理的能力。
-
需要简单易用的切换流程管理和端到端的监控能力
k8s带来了先进的技术，同时也带来了管理的复杂性，例如应用数量级的增加和更复杂的依赖关系。在进行容器应用的容灾流程设计时，如果没有简单清晰的流程管理和端到端的监控能力，对承载了几百甚至上千应用的容器平台的容灾管理来说，是一个极大的考验。
容器应用实现容灾的原则
根据以上的挑战，容器平台的容灾在实现上应该从以下几个方面来考虑：
-
以应用为中心
支持定义完整的应用资源，容灾配置（比如更换容器镜像源）以及容灾策略（比如容灾实例副本）满足对容器应用的容灾保护需要。
-
自动化
容器应用基于微服务架构实现业务开发和部署的敏捷性，持续发布和更新。应用容灾需要自动及时同步应用版本更新和配置变更。
-
流程化
容灾切换是一个相对复杂的过程，结合自动化和流程化能够确保应用容灾切换的及时性和准确性。
-
标准化
K8s通过定义标准接口为容器应用屏蔽底层基础设施差异。应用容灾基于标准接口对异构环境支持的同时，进一步需要对不同容器云平台进行适配，满足异构灾备站点的环境需要。
容器平台的容灾实现思路
容器平台虽然带来了很多新的技术和理念，在实现容灾的大的思路上，其实和传统容灾实现思路类似，主要有以下几种思路。
基于备份恢复的容灾
如果容器应用的数据在容器内，那么利用基本的备份和恢复能力进行容灾是一个相对比较普适的方案，在业界也常被称为冷备。基于备份恢复的容灾有以下特点：
-
RPO/RTO在小时级
这里RPO基本取决于备份的频率，而备份的频率跟备份的数据增量、数据传输带宽等因素相关。RTO主要取决于恢复的数据量和恢复数据传输带宽。一般来说，如果整体数据量不是太大，数据传输带宽不是瓶颈的情况下，可以做到小时级的RPO/RTO。
-
支持异构环境
由于备份和恢复在生产和灾备站点是分开执行，对环境没有特别的依赖，即使生产和灾备使用不同的基础架构也没有影响。
-
成本相对较低
备份和恢复是大多数备份厂商的基础能力，基于备份恢复进行容灾的建设相对来说成本比较低。
-
自动化程度一般
通常来说，备份和恢复是分开进行配置和管理，尤其是恢复时，可能需要根据应用的依赖进行手动的恢复，因此整体方案的自动化程度不高。
在容灾规划和建设的初期，对于非关键的业务和数据，可以先基于已有的备份恢复的能力进行容灾的实施和验证，对RPO/RTO要求比较高的业务可以同步的进行规划和建设。
基于数据复制的容灾
如果容器应用的数据由容器外部署的数据库和外置存储提供，并且数据能够利用数据库或者存储的同步/异步数据复制能力，可以实现数据复制方式的容灾，也可以称为热备方案。这样的方案有以下几个特点：
-
RPO/RTO在分钟级
由于可以利用数据层的数据复制能力，RPO和RTO可以达到分钟级。
-
不支持异构环境
数据复制能力一般由数据库厂商或者存储厂商带来，通常要求生产和灾备中心有同样的软硬件基础设施。
-
成本相对较高
数据复制能力不仅要购买额外的数据复制软件或者授权，对于存储硬件、网络的要求都比较高，因此建设成本也相对比较高。
-
自动化程度较高
数据层的数据复制与同步一般是在数据复制关系配置完成后，就可以自动运行的功能，只有在发生故障或者容灾演练时才会用到切换和控制的能力。如果数据层提供了对外的API接口，上层的容灾管理软件进行集成之后，就能够实现应用容灾管理大部分的自动化，需要人工介入的地方主要是在异常和处理失败的地方。
基于备份恢复和数据复制的容灾都可以归类为主从（Active passive）方式的容灾，正常情况下业务都运行在生产站点，只有遇到站点故障，或者容灾测试的场合，才会执行主从切换的操作，将业务运行在灾备站点。
双活容灾
双活是容灾建设的最高级形式，业务可以在生产站点和灾备站点同时运行，做到真正无感知的切换。相比主从式的容灾，双活容灾方案有以下几个特点：
-
RPO/RTO接近0
支撑双活架构的数据层一般也是基于数据库或者存储的数据同步能力，并且往往在同城建设数据中心，中心间的数据传输延迟在毫秒级。由于两个中心数据保持同步，并且应用可以通过全局负载均衡进行流量控制，在遇到故障切换时只有部分应用的流量需要切换，因此RPO/RTO接近0。
-
同样不支持异构环境
-
对应用要求比较高
双活架构要求应用本身的逻辑能够处理由于运行在不同站点带来的数据冲突的可能性。例如对在线交易系统来说，如果通过不同客户端同时登录同一个账户，是否能够检测并处理由此带来的数据不一致问题。
-
技术复杂度高，成本最高
由于双活要从流量层、应用层、数据库中间件层、存储层来端到端的考虑整体的方案，技术复杂度比较高，建设的成本相比前两种方案也是最高的。
企业在进行业务连续性规划和建设时，要根据当前不同业务的需求来进行分阶段的建设，总体上可以采用由易到难，由非关键业务到关键业务的顺序来逐步进行规划和建设，逐渐的提高业务的容灾能力。
YS1000的容灾方案
YS1000是骥步科技围绕云原生容器应用打造的一款备份容灾商业解决方案，继产品诞生以来在备份恢复迁移等场景持续迭代打磨之后，针对容器平台的容灾场景发布的全新功能，有以下特点：
- 通过图形界面完成容灾流程的统一管理和监控
- 同时支持有状态和无状态应用的统一容灾切换
- 支持应用颗粒度和集群颗粒度的切换
- 支持异构集群，允许不同版本或者不同厂商之间容灾
YS1000的容灾功能架构图如下所示：
YS1000充分考虑了容器应用的特点，将容器应用的容灾分为几个模块：
-
容灾配置管理
集群容灾配置可以导入生产站点和灾备站点中需要建立容灾关系的k8s 集群，配置对应的容器镜像服务地址等，并选择数据同步的类型。应用容灾配置可以选择容器应用资源，创建容灾应用实例，并关联上述集群容灾策略。
-
应用资源同步
根据设定的容灾策略，同步主站点应用资源至指定灾备中心容器环境并根据应用配置的容灾环境进行资源转换，比如镜像源，节点亲和性等信息。
-
数据同步管理
管理数据同步，如创建管理Ceph同步的CR，检查同步状态，停止、启动数据同步等操作。
-
容灾状态切换管理
对容灾实例定义的应用进行故障切换，回退，建立反向同步关系等操作，将应用容灾管理通过图形界面和鼠标点击来实现。
扫一扫
333
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
