什么是本地保护?
本地保护是为了确保节点上主用资源在发生故障时,业务能够快速倒换至备用资源上采取的一种保护业务连续性的策略,进而提高系统可靠性。
什么是本地保护?
本地保护(Hyper High Availability,简称HyperHA)是一种资源级保护机制,当节点上的主用资源发生故障时,能够快速将业务切换至备用资源,从而保障业务连续性并提升系统可靠性。
为什么需要本地保护?
业界常见采用系统级冗余保护方案,通过主备系统切换实现在故障场景下的业务连续性保障。然而当系统出现CPU、网口等关键资源故障时,系统级切换存在粒度粗、耗时长等局限性,难以满足快速业务接管需求。为此,需要构建资源级本地保护机制,实现对单点故障的精准快速恢复。
本地保护是怎么工作的?
概念介绍
本地保护中常用的概念:
- 资源:被本地保护服务保护或监控的对象都可以抽象为资源进行管理,资源是本地保护服务管理的最小单位。例如:微服务、网口、浮动IP、节点的CPU和内存等都抽象为资源,通过控制这些资源,完成高可靠业务。
- 基础资源:指不依赖于业务服务,由系统提供的基本类型资源,比如节点、CPU、内存和网口等。一个基础资源就是一个资源组,本地保护对其使用率或状态进行统计,参与仲裁决策相关业务服务是否倒换。
- 其他资源:服务自身的资源,比如业务服务进程等非基础资源。本地保护对其进行监控,参与仲裁决策相关业务服务是否倒换。
- 主用资源:当前对外提供服务的资源。
- 备用资源:对主用资源起保护作用的资源,备用资源不对外提供服务。
- 资源组:单个节点上有依赖关系的资源组成一个资源的集合,称为资源组。比如资源A依赖资源B且与其他资源无关时,资源A、B组成一个资源组,同一资源组的所有资源需要同时升主或降备。当一个节点有多个资源组时,称之为资源组保护。当一个节点只有一个资源组时,称之为节点级保护。
- 集群:在不同节点上互为保护的资源组构成一个集群,对外提供高可靠业务。
本地保护方案介绍
本地高可用管理服务(Hyper High Availability Manager,简称HyperHAMgr),简称本地保护(HyperHA),包括HyperHAService和HyperHAAgent服务。
- HyperHAService部署在管理面节点,提供集群中本地保护相关数据的加载、倒换参数下发等功能。
- HyperHAAgent部署在各节点,提供所部属节点的状态指标采集、仲裁决策、倒换控制等功能。
HyperHAAgent通过各节点与数据一致性存储中心(MCZooKeeper,简称MCZK)之间的心跳链路(简称ZK心跳)记录节点上的资源状态,同时通过节点之间IR接口的心跳(简称IR心跳)检测节点间通信状态,仲裁模块获取各节点的状态变化信息做出倒换决策,并将决策结果通过心跳链路下发给各节点执行,同一资源组在15分钟内最多倒换3次。HyperHAMgr与MCZK通过不同网络平面的两条心跳链路通信,以提高本地保护服务的可靠性。本地保护框架图如图所示。
本地保护框架图
1.业务请求通过浮动IP访问目标节点,如图中①所示,浮动IP始终与主节点绑定。
2.HyperHAAgent对所管理的资源进行监控,包括浮动IP和资源组,如图中②所示。当发现主节点服务异常时,会进行主备倒换,并将浮动IP绑定到备节点。
3.主备节点的HyperHAAgent,通过心跳链路与对端通信,如图中③所示,比对主备节点资源,通过仲裁进行升主降备。在以下场景会触发自动倒换:
- 当主用资源发生异常时,HyperHAMgr将对该资源所在的资源组进行倒换。
- 当ZK心跳和IR心跳断连时,执行孤岛节点故障的倒换策略。
资源组倒换时,会根据各资源之间的依赖关系从顶层向下完成降备后,再从底层向上完成升主。常见的资源组故障及倒换方案如下所示。
故障场景 |
方案介绍 |
方案示例 |
|---|---|---|
基础资源故障之单节点部署场景 |
HyperHAMgr部署在单个节点,当基础资源异常时,该节点上的不依赖该基础资源组的资源组不受影响。 |
示例场景:当基础资源F异常时,如CPU超负荷、内存过载、网卡丢包或者时延异常等,节点1上的资源组2正常运行。 示例:服务A和服务B组成资源组1,服务C和服务D组成资源组2,资源组1的正常运行依赖于基础资源组的正常运行,资源组2的正常运行不依赖于基础资源组的正常运行,当节点1上的CPU负载(基础资源)过高,则资源组1降为备用状态,资源组2保持主用资源状态。 图1-2 单节点基础资源故障
|
基础资源故障之多节点部署场景 |
HyperHAMgr部署在多个节点,当基础资源异常时,依赖该基础资源的资源组都会倒换至其他节点对外提供服务,故障的节点上资源组此时处于故障隔离状态。 |
示例场景:当基础资源F异常时,如OS异常、节点异常、节点掉电等,节点1上的资源组1和资源组2都会倒换至节点2上的资源组1和资源组2。 示例:本地保护服务部署在2个节点,资源组1和资源组2的正常运行依赖于基础资源组的正常运行。当节点1上的CPU(基础资源)负载过高,节点2上的CPU所在基础资源为主用状态提供服务。启动倒换,节点2上的资源组1和资源组2升为主用资源,对外提供服务,节点1上的资源组1和资源组2降为备用资源。 图1-3 多节点基础资源故障
|
其他资源故障之单节点部署场景 |
HyperHAMgr部署在单个节点,故障资源所在的资源组会处于备用状态,其他正常的资源组仍然可对外提供服务。 |
示例场景:当资源组中某资源异常时,如服务进程异常终止、服务内部异常等,该资源组降备,其他资源组对外提供服务。 示例:本地保护服务部署在1个节点,资源组1的服务C异常。启动倒换,节点1上的资源组1降为备用资源,资源组2升为主用资源,对外提供服务。 图1-4 单节点其他资源故障
|
其他资源故障之多节点部署场景 |
HyperHAMgr部署在多个节点,故障资源所在资源组会倒换至其他节点上对应的资源组对外提供服务,保证业务的连续性。 |
示例场景:当资源C故障,如服务主实例的进程异常终止、服务主实例内部异常等,节点1的资源组1会倒换至节点2的资源组1。 示例:本地保护服务部署在2个节点,当节点1上的服务C启动失败,启动倒换,节点2上的资源组1升为主用资源,对外提供服务,节点1上的资源组1降为备用资源。 图1-5 多节点其他资源故障
|
孤岛节点故障 |
HyperHAMgr部署在多个节点。某节点和MCZK的心跳断连,以及和其组成为保护组的节点IR心跳断连时,该节点为孤岛节点,孤岛节点无法同步资源组的状态。 孤岛节点会执行以下倒换方案:如果孤岛节点中资源组为主用状态且包含浮动IP资源时,则降备。如果孤岛节点的资源组不包含浮动IP资源,则执行服务自身配置的策略。 |
示例场景:节点1因网络异常等原因,为孤岛节点,其资源组为主用状态且包含浮动IP资源,则节点1资源组1降备。 示例:节点1的资源组为主用状态且包含浮动IP资源,节点1和MCZK的心跳断连,同时节点1和节点2的节点IR心跳断连,节点1资源组降为备用资源,节点2资源组升为主用资源。 图1-6 孤岛节点故障
|
本地保护和备份恢复、异地容灾等特性有什么不同?
本地保护和备份恢复、异地容灾在保护粒度、数据时效性、RTO、RPO、运维界面、运维复杂度和使用场景等方面存在差异。具体参见如下。
维度 |
本地保护 |
备份恢复 |
异地容灾 |
|---|---|---|---|
保护粒度 |
资源级别,如微服务实例、CPU、网口。 |
数据级别,数据分类进行备份和恢复。 |
系统级别。如NCE。 |
数据时效性 |
无数据传输,故障时进行资源倒换。 |
|
数据站点间实时同步数据。 |
RTO |
|
根据备份数据量有所波动,RTO: 30分钟~24小时。 |
|
RPO |
不涉及 |
根据备份数据量有所波动,RPO:1小时~7天。 |
RPO:1min。 |
购置成本 |
中 |
中 |
高 |
运维界面 |
无用户操作界面。 |
有用户操作界面。 |
有用户操作界面。 |
运维复杂度 |
需后台操作,如查询资源状态、倒换演练等,操作复杂度中等。 |
界面操作简单,操作复杂度较低。 |
界面运维监控指标较多,如站点详情、产品详情,可实时查看产品灾备状态,操作复杂度中等。 |
适用场景 |
适合需要资源级别保护的场景,如避免节点单个资源故障导致整个站点无法提供服务的情景,如cpu故障、网口故障。 |
适合需对关键数据进行保护的场景。 为避免人为误操作(如数据误删除、配置错误)、系统软件故障(如程序崩溃、升级失败)、硬件设备损坏(如存储介质故障、服务器宕机)、网络安全事件(如病毒攻击、勒索软件)或其他不可预见的异常情况,导致关键业务数据丢失或系统服务异常时。 |
适合需要站点级系统保护的场景。 为避免地震、异常断电等自然灾害,人为错误、网络攻击、设备故障等情况,导致业务的中断,使用异地容灾特性,在两个地方搭建系统,保障业务连续运行。适用于对系统可靠性要求较高的企业场景,如NCE。 |
相关概念说明:
- RTO(Recovery Time Objective)即恢复时间目标,主要指的是所能容忍的业务停止服务的最长时间,也就是从灾难发生到业务系统恢复服务功能所需要的最短时间周期。
- RPO(Recovery Point Objective)即数据恢复点目标,主要指的是业务系统所能容忍的数据丢失量。
- 作者: 罗敏瑶
- 最近更新: 2026-10-31
- 浏览次数: 16
- 平均得分:
导出PDF