Storage Container Manager

受众： 集群管理员

前置条件： 熟悉 Ozone 集群管理，尤其是 SCM 及其 HA 配置。

1. 概述

当承载存储容器管理器（Storage Container Manager，SCM）元数据目录的磁盘发生故障时，正确的恢复流程对于维持集群可用性、防止数据丢失至关重要。

如果由于任何原因需要更换承载 SCM 元数据目录（ozone.scm.db.dirs）的磁盘，就必须通过运行 ozone scm --bootstrap 来重建 SCM 元数据目录（前提是已配置 SCM HA）。

目的： 本指南详细说明了更换 SCM 节点上故障磁盘的流程。
SCM 磁盘故障的影响： SCM 磁盘至关重要，因为它存储着 RocksDB 数据库，其中包含整个集群物理存储的状态，包括：
- 数据节点的注册与心跳状态。
- 管道（Pipeline）信息与状态。
- 容器位置与副本信息。
- 如果该磁盘故障而没有合适的恢复计划，可能导致集群无法管理存储或分配新的数据块。
关键区别：HA 与非 HA： 该流程完全取决于您的 SCM 是单个独立实例，还是基于 Ratis 的高可用（HA）法定集群的一部分。运行独立的 SCM 存在单点故障问题，不建议在生产环境中使用。

2. 预检

开始之前，管理员应：

确认故障磁盘： 使用系统工具（dmesg、smartctl 等）确认哪块磁盘发生故障及其挂载点。
确认 SCM 相关目录： 检查 ozone-site.xml，确认哪些 Ozone 目录位于故障磁盘上。最重要的属性有：
- ozone.scm.db.dirs：主要的 SCM 元数据数据库（RocksDB）。该目录存储整个集群的块管理元数据。
- ozone.scm.ha.ratis.storage.dir：SCM 内部 HA Ratis 日志的存放位置（在 HA 部署中）。该目录存储日志等 Ratis 元数据。如果未显式配置，则回退到 ozone.metadata.dirs。在生产环境中，建议将其配置在独立的高速磁盘上（最好是 SSD），以获得更好的性能。
- ozone.scm.ha.ratis.snapshot.dir：SCM 存放恢复期间从 Leader 下载的快照 tar 包的目录。如果未显式配置，则默认使用 ozone.metadata.dirs 下的组件专属位置。
准备替换磁盘： 物理安装一块新的健康磁盘。对其格式化，并挂载到与故障磁盘相同的路径。确保运行 SCM 进程的用户对其拥有正确的属主和权限。SCM 元数据目录的默认权限为 750（可通过 ozone.scm.db.dirs.permissions 配置）。

3. 独立（非 HA）SCM 的处理流程

该流程是一次重大的灾难恢复事件，需要整个集群停机，并且必须有有效的备份。

停止整个集群： 关闭所有客户端、DataNode、OM 和 SCM。由于 SCM 不可用，DataNode 无法发送心跳，新的块分配也会失败。
尝试数据恢复： 如有可能，尽最大努力将 ozone.scm.db.dirs 目录的内容从故障磁盘复制到安全的临时位置。
如果恢复失败，从备份还原： 如果 SCM 数据库无法恢复，则必须从最近的备份中进行还原。没有备份的情况下，您将面临永久性数据丢失的风险，或者需要从 DataNode 报告中进行漫长、复杂且可能不完整的状态重建。如果部署了 Recon，其本地 SCM 副本（来自 DataNode 报告）可能可用作恢复来源——参见 Recon。
更换并配置磁盘： 物理更换硬件，并确保新的空白磁盘挂载到 ozone.scm.db.dirs 中定义的正确路径。
恢复元数据： 将恢复的数据**（来自步骤 2）或从备份还原的数据（来自步骤 3）**复制到新磁盘上的 ozone.scm.db.dirs 路径。
重启并验证：
- 首先启动 SCM 服务。
- 一旦 SCM 完全初始化并运行，再启动 OM，然后启动 DataNode。
- 检查 SCM Web UI，确认 DataNode 正在发送心跳且管道（pipeline）状态健康。运行客户端 I/O 测试以确保集群完全正常运行。

4. HA（基于 Ratis）SCM 的操作流程

这是推荐的生产环境流程。它利用 HA 法定人数进行恢复，无需集群停机，并且更加安全。

引导（Bootstrap）流程

停止故障的 SCM 实例： 在磁盘故障的节点上，仅停止 SCM 进程。其他 SCM 将继续运行，其中一个将保持领导者角色，继续管理集群。
更换并配置磁盘： 物理更换硬件。将新的空白磁盘挂载到 ozone.scm.db.dirs 和 ozone.scm.ha.ratis.storage.dir 中定义的路径。确保拥有正确的属主和权限。如果 ozone.scm.ha.ratis.snapshot.dir 也在故障磁盘上，请确保在新磁盘上也进行正确配置。
验证配置： 继续之前，请确保所有现有 SCM 的 ozone-site.xml 配置文件都已更新，包含正在恢复的 SCM 的配置信息（nodeId、地址、端口等）。引导过程将验证到现有 SCM 实例的连通性。
通过引导（Bootstrap）重新初始化 SCM： 故障的 SCM 已丢失其状态，必须通过从当前领导者获取最新状态的完整副本来重新加入 HA 集群。这通过 scm --bootstrap 命令完成。
- 运行引导命令：
```
bin/ozone scm --bootstrap
```
- 引导命令将会：
连接到现有的 SCM HA 环。
从当前 leader 获取集群 ID。
使用该集群 ID 初始化本地 SCM 存储配置。
如果启用了安全特性，则设置安全证书。

注意

bootstrap 命令不会启动 SCM 守护进程。它只准备配置和存储状态。bootstrap 完成后，你必须另行启动 SCM 服务。
启动 SCM 并进行监控：
- 在修复的节点上启动 SCM 服务：
```
ozone --daemon start scm
```
- 监控控制台输出以及 SCM 的日志文件（.log 和 .out）。你会看到指示以下情况的消息：
  1. SCM 正在连接到现有的 SCM HA 环。
  2. leader SCM 正在创建数据库检查点（快照）。
  3. 检查点正在被下载并安装到本地。
  4. SCM 正在作为 follower 加入 Ratis 环。
- 根据元数据规模和网络带宽的不同，此过程可能需要一些时间。
验证：
- 快照安装完成且 SCM 已加入环之后，从任意 SCM 节点访问 SCM Web UI。对等节点列表此时应显示所有 SCM 均为健康状态。
- 或者，使用命令 ozone admin scm roles -id <SCM_SERVICE_ID> 验证所有 SCM 是否都显示为 LEADER 或 FOLLOWER。
- 集群已恢复到完全冗余状态，整个流程到此完成。

5. 其他注意事项

5.1 原始 SCM 节点

在 HA 部署中，第一个使用 scm --init 启动的 SCM 是"原始"节点，它会生成集群的唯一 ID，并（在安全集群中）生成 SCM 证书的根 CA。
原始节点仅在最初建立 SCM HA 时需要。集群运行起来之后，原始 SCM 可以发生故障或被下线，而不会对集群造成影响；leader SCM 的子 CA 会为 OM 和 Datanode 签发证书。
集群 ID 由存活的 SCM 保留，并会在该节点成功执行 bootstrap 时复制到修复的节点上。
如果设置了 ozone.scm.primordial.node.id，bootstrap 在该节点上会跳过（不获取集群 ID，也不进行存储初始化）。因此，在修复的原始节点上，仅运行 scm --bootstrap 无法从其他 SCM 恢复。
原始磁盘被替换： 在修复的节点上，临时将 ozone.scm.primordial.node.id 设置为另一个 SCM（或取消设置），然后运行 scm --bootstrap 和 ozone --daemon start scm。该节点重新加入环后，可选择将该属性改回原值。

5.2 快照的磁盘空间要求

关键： 当 SCM 在 HA 部署中作为 follower 并需要恢复时，它会从 leader 下载快照 tar 包到本地快照目录（ozone.scm.ha.ratis.snapshot.dir）。
始终确保 SCM 磁盘至少拥有当前 SCM 数据库大小 2 倍的空间，以容纳现有数据和传入的快照。
这样可以避免磁盘空间问题，保持集群稳定性。

5.3 备份仍然必不可少

即使在健壮的 HA 配置下，定期对 SCM 数据库进行异地备份仍然是一项关键的最佳实践。
备份对于从灾难性的多节点故障或逻辑数据损坏中恢复至关重要。

5.4 Bootstrap 与 Init 的区别

scm --bootstrap 命令与 scm --init 不同：
- scm --init：仅用于第一个 SCM 节点（原生节点）初始化新集群，会创建新的集群 ID。
- scm --bootstrap：用于加入现有 HA 集群的其他 SCM 节点，或用于恢复故障的 SCM 节点。它会从现有的 SCM 实例获取集群 ID。
在非原生 SCM 节点上更换磁盘后，请使用 scm --bootstrap，然后启动 SCM。如果是在原生节点上更换磁盘，请参阅 §5.1 原生 SCM 节点，了解在运行 bootstrap 之前所需的临时配置更改。