驱动故障恢复
MinIO 支持用新的健康驱动器热插拔故障驱动器。MinIO 会检测并修复这些驱动器,无需任何节点或部署级重启。 MinIO 修复 仅发生在更换的驱动器上,并且在大多数情况下对部署性能的影响最小或可以忽略不计。
MinIO 修复确保恢复到驱动器上的所有数据的完整性和正确性。
对驱动器的独占访问权限
MinIO 要求 对用于对象存储的驱动器或卷进行独占访问。任何其他进程、软件、脚本或人员都不应直接对提供给 MinIO 的驱动器或卷或 MinIO 在其上放置的对象或文件执行任何操作。
除非 MinIO 工程师指示,否则请勿使用脚本或工具直接修改、删除或移动提供的驱动器上的任何数据分片、奇偶校验分片或元数据文件,包括从一个驱动器或节点移动到另一个驱动器或节点。此类操作很可能会导致 MinIO 无法修复的广泛损坏和数据丢失。
以下步骤提供了驱动器更换的更详细的演练。这些步骤假设一个 MinIO 部署,其中每个节点使用 /etc/fstab
管理驱动器,并根据 记录的先决条件 使用每个驱动器的标签。
1) 卸载故障驱动器
使用 umount
卸载每个故障驱动器。例如,以下命令会卸载位于 /dev/sdb
上的驱动器
umount /dev/sdb
2) 更换故障驱动器
从节点硬件中移除故障驱动器,并用已知健康的驱动器替换它。更换驱动器必须满足以下要求
XFS 格式化 并且为空。
相同的驱动器类型(例如 HDD、SSD、NVMe)。
相同或更高性能。
相同或更大容量。
使用容量更大的更换驱动器不会增加总集群存储。MinIO 使用最小驱动器的容量作为 服务器池 中所有驱动器的上限。
以下命令会将驱动器格式化为 XFS,并为其分配一个标签以匹配故障驱动器。
mkfs.xfs /dev/sdb -L DRIVE1
MinIO 强烈建议 使用基于标签的挂载,以确保在系统重启后仍然保持一致的驱动器顺序。
3) 检查和更新 fstab
检查 /etc/fstab
文件,并在需要时进行更新,使故障驱动器的条目指向新格式化的更换驱动器。
如果使用基于标签的驱动器分配,请确保每个标签都指向正确的新格式化的驱动器。
如果使用基于 UUID 的驱动器分配,请根据新格式化的驱动器更新每个点的 UUID。可以使用
lsblk
查看驱动器 UUID。
例如,考虑
$ cat /etc/fstab
# <file system> <mount point> <type> <options> <dump> <pass>
LABEL=DRIVE1 /mnt/drive1 xfs defaults,noatime 0 2
LABEL=DRIVE2 /mnt/drive2 xfs defaults,noatime 0 2
LABEL=DRIVE3 /mnt/drive3 xfs defaults,noatime 0 2
LABEL=DRIVE4 /mnt/drive4 xfs defaults,noatime 0 2
注意
依赖于挂载外部存储的云环境实例如果一个或多个远程文件挂载返回错误或故障,可能会遇到引导故障。例如,如果一个或多个 EBS 卷无法挂载,则具有挂载持久 EBS 卷的 AWS ECS 实例可能会使用标准 /etc/fstab
配置无法引导。
可以在引导时设置 nofail
选项,以静默错误报告并允许实例在存在一个或多个挂载问题的情况下引导。
您不应该在具有本地连接磁盘的系统上使用此选项,因为静默驱动器错误会阻止 MinIO 和操作系统以正常方式响应这些错误。
鉴于前面的示例命令,不需要对 fstab
进行任何更改,因为替换驱动器位于 /mnt/drive1
使用与故障驱动器相同的标签 DRIVE1
。
4) 重新挂载替换的驱动器
使用 mount -a
重新挂载在本过程开始时卸载的驱动器
mount -a
该命令应该导致所有替换的驱动器重新挂载。
5) 监控 MinIO 的驱动器检测和修复状态
使用 mc admin logs
命令或 journalctl -u minio
用于 systemd
管理的安装,以监控重新挂载驱动器后的服务器日志输出。输出应包含识别每个已格式化和空驱动器的消息。
使用 mc admin heal
监控部署上的整体 修复 状态。MinIO 会积极修复替换的驱动器,以确保从降级状态快速恢复。
6) 下一步
监控集群以查找任何进一步的驱动器故障。某些驱动器批次可能在彼此非常接近的时间段内发生故障。遇到高于预期驱动器故障率的部署应安排专门维护来更换已知坏批次。考虑使用 MinIO SUBNET 与 MinIO 工程师协调有关任何此类操作的指南。