可靠性设计用于说明 ZCF 架构中各能力域的高可用与数据保护机制。其中，云平台承载云主机和网络服务等业务负载可靠性能力，存储服务承载数据冗余和故障自愈能力，容器服务承载容器集群高可用能力，共同降低故障场景下的业务中断和数据丢失风险。

业务负载高可用覆盖云主机和容器集群两类承载对象。云主机高可用用于在物理机或云主机故障时恢复业务运行，容器集群高可用用于保障 Kubernetes 管理节点和关键组件持续可用。

云主机高可用指平台检测到云主机故障后，自动在健康的物理机重新启动该云主机的机制。该机制可降低云主机宕机时间，保障业务连续性，且整个过程不依赖专有硬件。

实现原理

云主机高可用流程由管理节点和物理机 agent 协作完成：

• 管理节点：负责处理云主机故障信息，并调度故障检测、恢复任务。管理节点定期获取云主机状态，当云主机处于停止状态时，将尝试启动该云主机。
• 物理机 agent：负责汇报云主机故障信息，执行故障检测和 Fencer 机制，定期检查云主机网络及存储状态，检测到故障时，物理机 agent 将强制终止当前云主机进程，并由管理节点在健康物理机上重新启动。

关于故障检测

通过网络、I/O 心跳两种机制进行物理机故障检测：

• 网络检测：
  • 检查管理网络：通过管理网连接状态，判断物理机是否故障：
    • 检查管理节点和当前物理机间的管理网络心跳，快速发现物理机管理网络连接异常。
    • 管理节点通过其他健康的物理机检查疑似异常的物理机，判断该物理机是否彻底从管理网络断开。
  • 检查物理机与共享存储的网络连接状态。
  • 检查物理机业务网口状态。
• I/O 心跳检测：通过存储层面的心跳记录检查物理机磁盘 I/O 是否正常。如 I/O 心跳检测与（管理）网络检测结果冲突，以 I/O 心跳检测结果为准：
  • SAN 存储：检测 sanlock 心跳记录是否按时更新。
  • Ceph 存储：检测自定义 host 心跳记录和云盘对应的 RBD Watcher。
  • 多存储场景（即云主机根云盘、数据盘使用不同主存储）：以根云盘所在主存储记录为准。

关于防脑裂

为防止高可用过程中，因网络分区导致云主机脑裂（即不同物理机上同时运行同一个云主机进程），引入 Fencer 机制，当检测到故障时，将强制终止相关的云主机进程。

关于故障恢复与调度

故障恢复由 Checker 负责，云主机进程强制终止后，Checker 将在健康的物理机重新启动该云主机，与 Fencer 形成闭环，确保云主机只在一台物理机上运行。

容器服务底座 Kubernetes 集群的管理节点高可用采用 Kubernetes 官方推荐的高可用方案设计，由三台管理节点组成容器服务集群，每个管理节点主要包含 kube-apiserver、kube-scheduler、kube-controller-manager 三个组件。同时每个管理节点包含一个 etcd 节点，有三台 etcd 节点组成的集群作为 Kubernetes 的元数据存储，实现集群数据的高度可靠性和一致性。

网络高可用面向物理链路、基础网络服务和网络服务实例故障场景，保障业务网络持续运行，主要包括物理机网络高可用和网络服务高可用。

物理机网络高可用由交换机侧链路冗余和物理机侧网卡 Bonding 共同实现。交换机侧负责提供链路和设备冗余，物理机侧将多张网卡绑定为一个逻辑接口，两者配合降低单网卡、单链路或单交换机故障对业务网络的影响。

物理机侧高可用：网卡 Bonding

物理机侧高可用主要通过网卡 Bonding 实现。Bonding 将物理机的多张网卡绑定为一个逻辑接口，并与交换机侧堆叠或 M-LAG 配合，提供链路冗余和带宽聚合能力。常用模式包括模式 1（active-backup）和模式 4（802.3ad）。

• 模式 1（active-backup）：同一时刻只有一张网卡处于活跃状态，其他网卡处于备用状态。主网卡或主链路故障时，流量可切换到备用链路。
• 模式 4（802.3ad）：多张网卡通过 LACP 协议形成逻辑链路组（LAG），由交换机与物理机 Bonding 协同实现链路冗余和带宽聚合。

网络服务包括基本网络服务（如 DHCP）和由 VPC 路由器或负载均衡实例提供的其他网络服务（如负载均衡、端口转发等）。

在该模式下，DHCP 服务不依赖中心节点，管理节点故障不影响已有云主机正常获取 IP 地址。

其他网络服务

其他网络服务主要由 VPC 路由器或负载均衡实例提供，云平台通过 VPC 路由器或负载均衡实例高可用保障网络服务高可用。

VPC 路由器支持双机主备模式，即部署一对互为主备的 VPC 路由器，形成高可用组。配置变化实时同步主备路由器，确保主备路由器配置一致。当主路由器状态异常时，将自动切换至备路由器，保证业务持续运行。主备路由器建议分别部署在不同的物理机，进一步避免单点故障。

负载均衡实例高可用和 VPC 路由器高可用机制基本相同：部署一对互为主备的负载均衡实例，形成高可用组，并通过 Keepalived 监控主备实例状态，当主实例故障时，将自动切换至备实例，保障业务持续运行。

存储可靠性围绕数据冗余、故障域隔离、一致性检查、故障检测和数据重建等能力展开，用于保障存储服务在硬件故障、节点异常和容量变化等场景下持续提供数据访问能力。本节以 ZStack ZStone 为例，介绍分布式存储在 ZCF 架构中的可靠性设计。

通过故障域隔离技术，可将故障对业务的影响限制在某个范围内，避免出现“牵一发而动全身”的情况发生，从而提高业务连续性。

通过基于故障域的扩容技术，配合合理的存储策略，可以将新扩容的节点独立成一个硬盘池，避免了数据的迁移。这种方式能够实现业务的无感扩容，向应用屏蔽了底层存储的变更细节，避免了传统存储变更时需要业务系统同时变更的情况。这样一来，运维人员及业务人员的工作量大大减少，同时也能提高系统的可靠性和性能。

存储服务支持自动故障监测和报警机制。该机制监控存储系统和各个存储服务器，检测到故障时将自动向平台发送告警消息。用户可另外添加邮箱报警器接收告警消息，以及时采取措施进行故障修复。

同时，检测到故障发生时，支持自动服务重启和数据迁移，最大程度上保障了数据的可靠、可用，从而形成高可靠、高可用的分布式存储系统。

分布式存储支持数据重平衡，使存储集群中的数据均衡分布在各个存储服务器下的数据盘上，从而提高存储系统的性能和可靠性。

手动数据重平衡：

同时支持手动数据重平衡功能，用户可根据实际的数据分布情况，手动进行数据重平衡操作。

数据保护与恢复覆盖快照、灾备、CDP 和系统配置备份等能力，用于在误操作、系统故障或灾难场景下保留可恢复的数据状态。

灾备服务以业务数据恢复为目标，融合定时全量备份、定时增量备份等机制，对云主机、云盘和管理节点数据库等数据进行备份，并在数据误删、主存储数据损坏或数据中心灾难等场景下恢复业务数据。灾备服务包括数据备份和数据恢复两类关键机制。

灾备服务支持基于 Qemu 块设备层的数据备份，各类型主存储上的云主机均支持备份。备份类型可分为：全量备份、增量备份。全量备份包含完整的数据集合，增量备份仅包含自上一次备份后所有更新的数据集合。全量备份和增量备份均仅备份真实数据。

默认情况下，备份策略是在首次全量备份后，每 63 个增量备份的下一次备份就会自动执行一次全量备份。这是因为增量备份之间有依赖关系，在做新的一次全量备份后，才能对之前的增量备份进行删除。实际上，系统内部有更智能灵活的应对策略来决定使用哪种合适的备份方式，以确保备份数据的安全可靠。

数据备份可分为三部分：数据复制、数据传输、数据保存。

灾备模块利用 Qemu 块设备层的脏数据跟踪功能（Dirty Bitmap）实现备份数据的跟踪与导出。

云主机磁盘文件数据发生变化的位置被称为脏数据位置，Dirty Bitmap 记录自上次备份后，虚拟磁盘文件上产生脏数据的所有位置记录，根据位置记录，就可导出自上次备份后所有被修改过的数据，即增量的备份数据。最终全量备份文件和各个增量备份文件会产生一个完整的备份链，保存完整的数据。

云平台提供自适应的备份导出策略，后台会根据不同情况选择导出增量数据还是全量数据。Dirty Bitmap 存在于 Qemu 进程的内存中，云主机重启后就会丢失这部分信息，因此当云主机重启后云平台会自动选择导出全量备份数据。

针对不同的虚拟化组件版本，支持两套不同的实现方案，主要区别在备份数据的传输上。

第一种方案：Data Over SSHFS。使用 SSHFS 在计算节点上挂载远程备份服务器的备份目录，然后将备份数据导入备份服务器。SSHFS 是一个简单的 FUSE Over SSH 方案，数据链路由 SSH 会话加密，每个备份任务有单独的 SSHFS 链路。

第二种方案：Data Over NBD。在备份服务器上使用 NBD 模块导出一个备份磁盘，然后在计算节点通过 Qemu 的块设备任务（Block-job），直接将备份数据导入备份磁盘。

备份服务器支持多种存储介质，包括：SAN、NAS、磁盘阵列以及带库等。

备份数据在备份服务器中切片去重存放，备份数据会被切分成 64MB 大小的数据块，然后计算 Hash，建立索引。拥有相同 Hash 的数据块不会被存储多份。

从本地备份数据恢复云主机/云盘，会把备份服务器上的切片数据合并导入主存储中。

如果是非 Ceph 主存储，合并后的备份恢复数据会以磁盘链的形式存放；如果是 Ceph 主存储，会把磁盘链合并成单个磁盘文件存放。

如果是新建恢复，恢复到主存储的磁盘数据会被当作镜像缓存来创建新云主机/云盘；如果是覆盖恢复，会把恢复到主存储的磁盘路径更新到当前云主机/云盘的数据库记录中，随后删除旧的云主机/云盘文件。

CDP 服务用于为云主机中的重要业务系统提供细粒度持续数据保护。通过 CDP 服务，用户可以将云主机数据恢复到指定时间状态，也可以在不恢复系统的情况下找回文件。CDP 服务包括数据备份、数据恢复和备份可靠性指标等能力。

CDP 数据备份通过持续跟踪云主机数据变化，将变化数据同步到备份服务器，并形成可用于恢复的时间点数据状态。

CDP 模块利用 Qemu 块设备层的脏数据跟踪功能（Dirty Bitmap）以及 Drive-mirror 实现备份数据的跟踪与导出。

云主机磁盘文件数据发生变化的位置被称为脏数据位置，Dirty Bitmap 记录自上次备份后，虚拟磁盘文件上产生脏数据的所有位置记录，根据位置记录，就可导出自上次备份后所有被修改过的数据，即增量的备份数据。

云平台提供自适应的备份导出策略，后台会根据不同情况选择导出增量数据还是全量数据。Dirty Bitmap 存在于 Qemu 进程的内存中，云主机重启后就会丢失这部分信息，因此当云主机重启后云平台会自动选择导出全量备份数据。

导出的备份数据通过 Drive-mirror 被导入保存至 CDP 备份服务器上的空白 QCOW2 磁盘文件中。空白的磁盘文件在创建 CDP 任务时会预先被创建出来，再通过 NBD 协议导出成一个网络上可访问的块设备，这样 CDP 备份任务就可把云主机的云盘数据持续导入至 CDP 备份服务器。

云主机数据传输至 CDP 备份服务器上后，以 QCOW2 磁盘文件形式存放。针对 QCOW2 磁盘文件会有一个 Qemu 存储服务来提供各种保护策略下的数据恢复点。

CDP 任务的数据恢复点由 BP 点和 RP 点组成。BP 点以粗粒度形式按时间定期生成外部快照（默认 20 分钟），RP 点则可根据实际设置的 CDP 保护策略，最快以 1 秒 1 次记录 IO 变化来生成恢复点。

CDP 备份服务器首先会对云主机数据进行一次全量复制生成基本 BP 点，后续通过 Qemu 持续捕获 I/O 数据变化，将每次变化的 I/O 数据打上时间戳生成 RP 点并保存下来。恢复点的生成都是在 CDP 备份服务器上做的，对原云主机无任何影响。

CDP 数据恢复支持基于指定恢复点恢复云主机数据或找回文件，帮助用户在误操作、业务异常或恢复演练场景下验证并恢复数据。

当因误删云主机丢失部分文件时，CDP 备份数据支持快速浏览备份文件，实现文件级别的数据恢复。用户可选择任意恢复点浏览恢复点中的文件和数据，也可预览文件内容，确认文件包含所需数据后，再选择下载文件或锁定恢复点做后续的数据恢复。

当云主机业务发生故障或遭受病毒需做整机数据恢复时，CDP 备份数据支持秒级快速恢复，满足业务快速恢复上线的需求。

快速恢复主要包含两个步骤：云主机快速拉起、云主机数据迁移。

在 CDP 备份服务器上，云主机备份数据以 QCOW2 磁盘格式存放。为实现快速拉起，首先会将备份的 QCOW2 磁盘通过 NBD 以网络块设备方式映射出来，然后云主机在计算节点上通过 NBD 来访问备份服务器上的云主机备份磁盘，此时云主机已正常提供业务，用户可正常读写云主机。

由于云主机磁盘尚未存放至主存储，后台会启动一个存储迁移任务，将备份服务器上的磁盘数据同步到主存储上。在该过程中，对云主机的修改写入均会被记录为脏页，一并同步至主存储的目标磁盘中。

当同步任务发现数据全部拷贝完成后，云主机会默认将磁盘路径动态切换成主存储的路径来访问。后台迁移过程会将云主机的所有数据均同步至主存储，并且整个过程对用户完全无感知，也不会对云主机业务产生影响。

评估灾备系统可靠性有两个重要指标：RPO 与 RTO。RPO（Recovery Point Objective）指恢复点目标，强调灾难发生后，企业能容忍的数据丢失量。RTO（Recovery Time Objective）指恢复时间目标，强调灾难发生后，企业能容忍的数据恢复时间。

CDP 模块在云主机低负载情况下 RPO 与 RTO 最低均可达 1 秒。

系统配置备份对于云平台来说至关重要。当云平台发生异常，或相关配置丢失时，可通过系统配置的备份数据进行恢复。

云平台提供备份服务模块，支持本地灾备、异地灾备、公有云灾备多种灾备方案。