停用服务器池

首先备份集群设置

使用 mc admin cluster bucket export 和 mc admin cluster iam export 命令分别对存储桶元数据和 IAM 配置进行快照，以便在开始停用流程之前进行备份。您可以使用这些快照恢复存储桶/IAM 设置，以在必要时从用户或流程错误中恢复。

网络和防火墙

每个节点都应能够与部署中的所有其他节点进行双向网络通信。对于容器化或编排的基础设施，这可能需要对网络和路由组件（如入口或负载均衡器）进行特定配置。某些操作系统可能还需要设置防火墙规则。例如，以下命令在使用 firewalld 的服务器上显式打开默认的 MinIO 服务器 API 端口 9000。

firewall-cmd --permanent --zone=public --add-port=9000/tcp
firewall-cmd --reload

如果您设置了静态的 MinIO 控制台 端口（例如 :9001），则必须也授予对该端口的访问权限，以确保外部客户端能够连接。

MinIO **强烈建议**使用负载均衡器来管理与集群的连接。负载均衡器应使用“最少连接”算法将请求路由到 MinIO 部署，因为部署中的任何 MinIO 节点都可以接收、路由或处理客户端请求。

以下负载均衡器已知可以很好地与 MinIO 配合使用

• NGINX

• HAProxy

配置防火墙或负载均衡器以支持 MinIO 不在本过程的范围内。

部署必须有足够的存储空间

停用流程会将目标池中的对象迁移到部署中的其他池。部署上的总可用存储空间必须超过停用池的总存储空间。

使用 纠删码计算器 来确定可用的存储容量。然后减去部署上已存在对象的存储大小。

例如，考虑一个具有以下已用和可用存储空间分布的部署

停用池 1 需要将 100TB 的已用存储空间分布到剩余的池中。池 2 和池 3 各有 100TB 的未使用存储空间，可以安全地容纳池 1 中存储的数据。

但是，如果池 1 已满（例如 200TB 已用空间），则停用将完全填满剩余的池，并可能阻止任何进一步的写入操作。

替换服务器池

对于硬件升级周期，如果您用新池替换旧池硬件，则应在开始停用旧池之前通过扩展添加新池。首先添加新池可以使停用流程以平衡的方式在所有可用池（包括现有池和新池）之间传输对象。

在停用旧硬件池之前，完成所有计划的 硬件扩展。

停用需要集群的拓扑结构在整个池清空过程中保持稳定。**不要**尝试在单个步骤中执行扩展和停用更改。

停用是可恢复的

如果因部署重启或网络故障等瞬态问题中断，MinIO 会恢复停用。

对于手动取消或失败的停用尝试，只有在您手动重新启动停用操作后，MinIO 才会恢复。

无论是否中断，池都将保持停用状态。池在停用开始后永远无法恢复到活动状态。

停用是非破坏性的

删除停用的服务器池需要同时重启部署中的所有 MinIO 节点。

MinIO 强烈建议同时重启部署中的所有 MinIO 服务器进程。MinIO 操作是原子且严格一致的。因此，重启过程不会对应用程序和正在进行的操作造成干扰。

**不要**执行“滚动”（例如一次一个节点）重启。

停用忽略已过期的对象和尾随 DeleteMarker

从 RELEASE.2023-05-27T05-56-19Z 开始，停用会忽略仅剩余版本为 DeleteMarker 的对象。这避免了为实际上已完全删除的对象在剩余服务器池上创建空元数据。

从 RELEASE.2023-06-23T20-26-00Z 开始，停用还会忽略根据父存储桶配置的 生命周期规则 而过期的对象版本。从 RELEASE.2023-06-29T05-12-28Z 开始，您可以使用 mc admin trace --call decommission 监控停用过程中被忽略的删除标记和已过期对象。

停用流程完成后，您可以安全地关闭该池。由于唯一剩余的数据已计划删除或只是一个 DeleteMarker，您可以根据您的内部程序安全地清除或销毁这些驱动器。

最终列表检查

在停用流程结束时，MinIO 会检查池上的项目列表。如果列表返回为空，则 MinIO 将停用标记为成功完成。如果返回任何对象，则 MinIO 将返回错误，表明停用流程失败。

如果停用失败，客户应在重试停用之前打开 MinIO SUBNET 问题以获取进一步的帮助。没有 SUBNET 订阅的社区用户可以重试停用流程或通过 MinIO 社区 Slack 寻求其他支持。MinIO 提供尽力而为的社区支持，并且不提供关于响应能力的 SLA。

停用启用了分层的服务器

对于启用了分层且处于活动状态的部署，停用会将对象引用移动到新的活动池。应用程序可以继续对这些对象发出 GET 请求，MinIO 会透明地处理从远程层检索它们。

在较旧的 MinIO 版本中，分层配置会阻止停用。

1) 检查 MinIO 部署拓扑

mc admin decommission 命令会返回 MinIO 部署中所有池的列表

mc admin decommission status myminio

该命令返回类似于以下内容的输出

┌─────┬────────────────────────────────────────────────────────────────┬──────────────────────────────────┬────────┐
│ ID  │ Pools                                                          │ Capacity                         │ Status │
│ 1st │ https://minio-{01...04}.example.com:9000/mnt/disk{1...4}/minio │  10 TiB (used) / 10  TiB (total) │ Active │
│ 2nd │ https://minio-{05...08}.example.com:9000/mnt/disk{1...4}/minio │  60 TiB (used) / 100 TiB (total) │ Active │
│ 3rd │ https://minio-{09...12}.example.com:9000/mnt/disk{1...4}/minio │  40 TiB (used) / 100 TiB (total) │ Active │
└─────┴────────────────────────────────────────────────────────────────┴──────────────────────────────────┴────────┘

上面的示例部署有三个池。每个池有四台服务器，每台服务器有四个驱动器。

确定要停用的目标池并检查当前容量。部署中的剩余池必须具有足够的总容量来迁移停用池中存储的所有对象。

在上面的示例中，部署具有 210TiB 的总存储空间和 110TiB 的已用存储空间。第一个池 (minio-{01...04}) 是停用的目标，因为它是在创建 MinIO 部署时配置的，并且已完全使用。剩余的新池可以容纳第一个池中存储的所有对象，而不会显着影响总可用存储空间。

2) 开始停用流程

使用 mc admin decommission start 命令开始停用目标池。指定部署的 别名 和要停用的池的完整描述，包括所有主机、磁盘和文件路径。

mc admin decommission start myminio/ https://minio-{01...04}.example.net:9000/mnt/disk{1...4}/minio

此示例命令开始在 myminio 部署上停用匹配的服务器池。

在停用过程中，MinIO 继续将读取操作（GET、LIST、HEAD）路由到尚未迁移对象的池中。MinIO 将所有新的写入操作（PUT）路由到部署中剩余的池。

管理部署连接的负载均衡器、反向代理或其他网络控制组件此时无需修改其配置。

3) 监控停用过程

使用 mc admin decommission status 命令监控停用过程。

mc admin decommission status myminio

该命令返回类似于以下内容的输出

┌─────┬────────────────────────────────────────────────────────────────┬──────────────────────────────────┬──────────┐
│ ID  │ Pools                                                          │ Capacity                         │ Status   │
│ 1st │ https://minio-{01...04}.example.com:9000/mnt/disk{1...4}/minio │  10 TiB (used) / 10  TiB (total) │ Draining │
│ 2nd │ https://minio-{05...08}.example.com:9000/mnt/disk{1...4}/minio │  60 TiB (used) / 100 TiB (total) │ Active   │
│ 3rd │ https://minio-{09...12}.example.com:9000/mnt/disk{1...4}/minio │  40 TiB (used) / 100 TiB (total) │ Active   │
└─────┴────────────────────────────────────────────────────────────────┴──────────────────────────────────┴──────────┘

您可以通过向命令指定服务器池的描述来检索更详细的信息

mc admin decommission status myminio https://minio-{01...04}.example.com:9000/mnt/disk{1...4}/minio

该命令返回类似于以下内容的输出

Decommissioning rate at 100MiB/sec [1TiB/10TiB]
Started: 30 minutes ago

mc admin decommission status 在停用完成后将 Status 标记为 Complete。停用完成后，您可以继续执行下一步。

如果 Status 显示为失败，您可以重新运行 mc admin decommission start 命令以恢复该过程。对于持续性故障，请使用 mc admin logs 或查看 systemd 日志（例如 journalctl -u minio）以识别更具体的错误。

4) 从部署配置中删除停用的池

每个池完成停用后，您可以安全地将其从部署配置中删除。修改部署中每个剩余 MinIO 服务器的启动命令并删除停用的池。

.deb 或 .rpm 包将 systemd 服务文件安装到 /lib/systemd/system/minio.service。对于二进制安装，此过程假设该文件已根据 部署 MinIO：多节点多驱动器 过程手动创建。

minio.service 文件使用位于 /etc/default/minio 的环境文件来获取配置设置，包括启动设置。具体来说，MINIO_VOLUMES 变量设置启动命令

cat /etc/default/minio | grep "MINIO_VOLUMES"

该命令返回类似于以下内容的输出

MINIO_VOLUMES="https://minio-{1...4}.example.net:9000/mnt/disk{1...4}/minio https://minio-{5...8}.example.net:9000/mnt/disk{1...4}/minio https://minio-{9...12}.example.net:9000/mnt/disk{1...4}/minio"

编辑环境文件并从 MINIO_VOLUMES 值中删除停用的池。

5) 更新网络控制平面

更新任何负载均衡器、反向代理或其他网络控制平面，以从 MinIO 部署的连接配置中删除停用的服务器池。

配置网络控制平面组件的具体说明不在此过程的范围内。

6) 重新启动 MinIO 部署

在部署中的每个节点上同时发出以下命令以重新启动 MinIO 服务

sudo systemctl restart minio.service

使用以下命令确认服务已上线并正常运行

sudo systemctl status minio.service
journalctl -f -u minio.service

在服务器处理连接和同步时，MinIO 可能会记录大量非关键警告。这些警告通常是瞬态的，并且随着部署上线而解决。

MinIO 强烈建议同时重启部署中的所有 MinIO 服务器进程。MinIO 操作是原子且严格一致的。因此，重启过程不会对应用程序和正在进行的操作造成干扰。

**不要**执行“滚动”（例如一次一个节点）重启。

部署上线后，使用 mc admin info 确认部署中所有剩余服务器的正常运行时间。

1) 查看 MinIO 部署拓扑

mc admin decommission 命令会返回 MinIO 部署中所有池的列表

mc admin decommission status myminio

该命令返回类似于以下内容的输出

┌─────┬────────────────────────────────────────────────────────────────┬──────────────────────────────────┬────────┐
│ ID  │ Pools                                                          │ Capacity                         │ Status │
│ 1st │ https://minio-{01...04}.example.com:9000/mnt/disk{1...4}/minio │  10 TiB (used) / 10  TiB (total) │ Active │
│ 2nd │ https://minio-{05...08}.example.com:9000/mnt/disk{1...4}/minio │  95 TiB (used) / 100 TiB (total) │ Active │
│ 3rd │ https://minio-{09...12}.example.com:9000/mnt/disk{1...4}/minio │  40 TiB (used) / 500 TiB (total) │ Active │
│ 4th │ https://minio-{13...16}.example.com:9000/mnt/disk{1...4}/minio │  0  TiB (used) / 500 TiB (total) │ Active │
└─────┴────────────────────────────────────────────────────────────────┴──────────────────────────────────┴────────┘

上面的示例部署有三个池。每个池有四台服务器，每台服务器有四个驱动器。

确定要停用的目标池并检查当前容量。部署中的剩余池必须具有足够的总容量来迁移停用池中存储的所有对象。

在上面的示例中，部署总存储容量为 1110TiB，已使用 145TiB。

• 第一个池（minio-{01...04}）是第一个停用目标，因为它是在创建 MinIO 部署时配置的，并且已完全满载。

• 第二个池（minio-{05...08}）是第二个停用目标，因为它也是在创建 MinIO 部署时配置的，并且接近满载。

• 第四个池（minio-{13...16}）是一个新添加的池，包含来自已完成服务器扩展的新硬件。

第三和第四个池可以吸收存储在第一个池中的所有对象，而不会显着影响可用存储总量。

2) 启动停用过程

使用 mc admin decommission start 命令开始停用目标池。指定部署的 别名 和要停用的每个池的完整描述的逗号分隔列表，包括所有主机、磁盘和文件路径。

mc admin decommission start myminio/ https://minio-{01...04}.example.net:9000/mnt/disk{1...4}/minio,https://minio-{05...08}.example.net:9000/mnt/disk{1...4}/minio

示例命令开始在 myminio 部署上停用两个列出的匹配服务器池。

在停用过程中，MinIO 继续将读取操作（GET、LIST、HEAD）操作路由到尚未迁移对象的池中。MinIO 将所有新的写入操作（PUT）路由到部署中未计划停用的剩余池。

停用池的清空一次进行一个池，按顺序完成每个池的停用。清空_不会_对所有要停用的池同时进行。

管理部署连接的负载均衡器、反向代理或其他网络控制组件此时无需修改其配置。

3) 监控停用过程

使用 mc admin decommission status 命令监控停用过程。

mc admin decommission status myminio

该命令返回类似于以下内容的输出

┌─────┬────────────────────────────────────────────────────────────────┬──────────────────────────────────┬──────────┐
│ ID  │ Pools                                                          │ Capacity                         │ Status   │
│ 1st │ https://minio-{01...04}.example.com:9000/mnt/disk{1...4}/minio │  10 TiB (used) / 10  TiB (total) │ Draining │
│ 2nd │ https://minio-{05...08}.example.com:9000/mnt/disk{1...4}/minio │  95 TiB (used) / 100 TiB (total) │ Pending  │
│ 3rd │ https://minio-{09...12}.example.com:9000/mnt/disk{1...4}/minio │  40 TiB (used) / 500 TiB (total) │ Active   │
│ 4th │ https://minio-{13...16}.example.com:9000/mnt/disk{1...4}/minio │  0  TiB (used) / 500 TiB (total) │ Active   │
└─────┴────────────────────────────────────────────────────────────────┴──────────────────────────────────┴──────────┘

您可以通过向命令指定服务器池的描述来检索更详细的信息

mc admin decommission status myminio https://minio-{01...04}.example.com:9000/mnt/disk{1...4}/minio

该命令返回类似于以下内容的输出

Decommissioning rate at 100MiB/sec [1TiB/10TiB]
Started: 30 minutes ago

mc admin decommission status 在停用完成后将 Status 标记为 Complete。一旦 MinIO 完成所有池的停用，您就可以继续执行下一步。

如果 Status 显示为失败，您可以重新运行 mc admin decommission start 命令以恢复该过程。对于持续性故障，请使用 mc admin logs 或查看 systemd 日志（例如 journalctl -u minio）以识别更具体的错误。

4) 从部署配置中删除停用的池

停用完成后，您可以安全地从部署配置中删除这些池。修改部署中每个剩余 MinIO 服务器的启动命令并删除停用的池。

.deb 或 .rpm 包将 systemd 服务文件安装到 /lib/systemd/system/minio.service。对于二进制安装，此过程假设该文件已根据 部署 MinIO：多节点多驱动器 过程手动创建。

minio.service 文件使用位于 /etc/default/minio 的环境文件来获取配置设置，包括启动设置。具体来说，MINIO_VOLUMES 变量设置启动命令

cat /etc/default/minio | grep "MINIO_VOLUMES"

该命令返回类似于以下内容的输出

MINIO_VOLUMES="https://minio-{1...4}.example.net:9000/mnt/disk{1...4}/minio https://minio-{5...8}.example.net:9000/mnt/disk{1...4}/minio https://minio-{9...12}.example.net:9000/mnt/disk{1...4}/minio"

编辑环境文件并从 MINIO_VOLUMES 值中删除停用的池。

5) 更新网络控制平面

更新任何负载均衡器、反向代理或其他网络控制平面，以从 MinIO 部署的连接配置中删除停用的服务器池。

配置网络控制平面组件的具体说明不在此过程的范围内。

6) 重新启动 MinIO 部署

在部署中的每个节点上同时发出以下命令以重新启动 MinIO 服务

sudo systemctl restart minio.service

使用以下命令确认服务已上线并正常运行

sudo systemctl status minio.service
journalctl -f -u minio.service

在服务器处理连接和同步时，MinIO 可能会记录大量非关键警告。这些警告通常是瞬态的，并且随着部署上线而解决。

MinIO 强烈建议同时重启部署中的所有 MinIO 服务器进程。MinIO 操作是原子且严格一致的。因此，重启过程不会对应用程序和正在进行的操作造成干扰。

**不要**执行“滚动”（例如一次一个节点）重启。

部署上线后，使用 mc admin info 确认部署中所有剩余服务器的正常运行时间。