Ozone Manager

受众： 集群管理员

前置条件： 熟悉 Ozone 集群管理与 Linux 系统管理。

1. 概述

当包含 Ozone Manager（OM）元数据目录的磁盘发生故障时，正确的恢复流程对于维持集群可用性、防止数据丢失至关重要。本文档提供了全面、分步骤的指导，用于安全地更换 OM 节点上发生故障的磁盘，并分别针对单机（standalone）配置和高可用（HA）配置给出了不同的流程。正确遵循这些流程可确保停机时间最短，并保持 Ozone 集群元数据的完整性。

目的本指南提供了在 Ozone Manager（OM）节点上安全更换故障磁盘所需的步骤。
OM 磁盘故障的影响 OM 磁盘至关重要，因为它存储着 RocksDB 数据库，其中包含整个对象存储命名空间（卷、桶、对象键）以及数据块位置。如果处理不当，该磁盘故障可能导致元数据丢失。
关键区别：HA 与非 HA 恢复流程完全取决于您的 OM 是单个独立实例，还是基于 Ratis 的高可用（HA）仲裁组的一部分。HA 流程要安全得多，并且不会造成集群停机。不建议在生产环境中运行独立模式的 OM。

2. 风险检查

重要： 以下步骤假设 Ozone 配置文件完好无损。如果配置文件已损坏，则需要先从备份中恢复配置文件（如适用），然后再继续执行磁盘更换流程。

在开始之前，管理员应当：

确定故障磁盘： 使用系统工具（dmesg、smartctl 等）确认哪块磁盘已故障及其挂载点。
确定 OM 目录： 检查您的 ozone-site.xml，确认哪些 Ozone 目录位于故障磁盘上。最重要的目录有：
- ozone.om.db.dirs：主 OM 元数据数据库（RocksDB）。该目录存储整个对象存储命名空间。
- ozone.om.ratis.storage.dir：Ratis 存储目录（如果配置在独立的磁盘上）。该目录存储日志等 Ratis 元数据。如果未显式配置，则回退使用 ozone.metadata.dirs。对于生产环境，建议将其配置在独立的高速磁盘上（最好是 SSD），以获得更好的性能。
准备替换磁盘： 准备一块全新的、状态良好的磁盘，将其物理安装、格式化，并挂载到系统上与故障磁盘相同的路径。确保该磁盘对运行 OM 进程的用户具有正确的属主和权限。OM 元数据目录的默认权限为 750（可通过 ozone.om.db.dirs.permissions 配置）。

3. 单机（非 HA）Ozone Manager 的处理流程

这是一项高风险的人工灾难恢复过程，将导致集群停机。

停止整个集群： 关闭所有客户端、DataNode、SCM 和 Ozone Manager，以防止任何进一步的状态变更。
尝试数据恢复： 如果故障磁盘仍可部分读取，请尽力将 ozone.om.db.dirs 目录的内容复制到一个安全的临时位置。
若恢复失败，请从备份还原： 如果 OM 数据库文件无法恢复，则必须从最近的备份进行恢复。本文档不涵盖备份过程本身，但在这种情况下，这是唯一的恢复途径。
更换并配置磁盘： 物理更换硬件，并确保新的空磁盘挂载到 ozone.om.db.dirs 中定义的正确路径。
恢复元数据： 将恢复的数据**（来自步骤 2）或还原的备份数据（来自步骤 3）**复制到新磁盘上的 ozone.om.db.dirs 路径。
重启并验证：
- 启动 SCM 和 Ozone Manager 服务。
- OM 运行后，启动各个 DataNode。
- 运行 ozone sh volume list 及其他基本命令，验证命名空间完好且集群正常运行。

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

该流程安全得多，能够利用 OM HA 集群的内置冗余特性，且不需要完全停止集群。

引导（Bootstrap）流程

停止故障的 OM 实例： 在磁盘故障的节点上，仅停止 Ozone Manager 进程。其他 OM 将继续运行，其中一个将继续担任 Leader 并处理客户端请求。
更换并配置磁盘： 物理更换硬件。将新的空磁盘挂载到 ozone.om.db.dirs 定义的路径，并确保其具有正确的属主和权限。如果 ozone.om.ratis.storage.dir 也在故障磁盘上，请确保在新磁盘上也正确配置该路径。
验证配置： 在继续之前，确保所有现有 OM 的 ozone-site.xml 配置文件均已更新为正在恢复的 OM 的配置详情（nodeId、地址、端口等）。引导过程将通过检查所有 OM 的磁盘配置来验证这一点。如果某个现有 OM 的配置未更新，那么在启动引导时可能会崩溃。
重新初始化 OM：
- 这是关键步骤。由于本地数据库已丢失，OM 需要从当前的 OM Leader 获取最新状态的完整副本来"重生"。
- 使用 --bootstrap 参数运行 OM 以触发此过程。例如：
```
ozone om --bootstrap
```

此命令会检测到该 OM 属于一个已存在的 Ratis 环，但没有本地状态。
5. 启动 OM 并进行监控：

在修复的节点上启动 Ozone Manager 服务（如果引导命令尚未启动它）。
跟踪 OM 的日志文件（.log 和 .out）。你应该能看到表明它正在连接到 OM HA 环、并且正在安装"快照"的消息。这意味着当前的 OM 主节点正在将整个元数据数据库流式传输到这个新的从节点。
根据元数据的大小，此过程可能需要一些时间。

**验证：**快照安装完成后，OM 将完成启动，以从节点身份加入 Ratis 环，并开始接收实时更新。
- 你可以在任意一个 OM 节点上查看 OM Web UI。此时对等节点列表应显示所有 OM 均为健康状态。
- 或者，使用命令 ozone admin om roles -id <OM_SERVICE_ID> 验证所有 OM 是否显示为 LEADER 或 FOLLOWER。
- 集群现已恢复到完全冗余状态，此流程到此结束。

5. 其他注意事项

快照的磁盘空间要求
- **关键：**当 Ozone Manager（OM）在 HA 环境中作为从节点时，它会从主节点下载快照 tar 包到本地元数据目录。
- 始终确保 OM 磁盘具有至少 2 倍当前 OM 数据库大小的空间，以容纳已有数据和传入的快照。
- 这样可以避免磁盘空间问题，并在恢复操作期间保持集群稳定性。
分离 Ratis 日志
- 如果你已将 ozone.om.ratis.storage.dir 配置在单独的专用磁盘上（出于性能考虑推荐这样做），那么该磁盘的故障将遵循相同的 HA 恢复流程。
- OM 启动时会自动从环中的其他成员重建其 Ratis 日志。
磁盘监控
- 本流程凸显了主动监控磁盘健康状况（smartd 等）的重要性，以便在灾难性故障发生之前主动更换磁盘。