停用服务器池

首先备份集群设置

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

网络和防火墙

每个节点都应具有与部署中其他所有节点的完全双向网络访问权限。对于容器化或编排的基础设施，这可能需要对网络和路由组件（如 ingress 或负载均衡器）进行特定配置。某些操作系统可能还需要设置防火墙规则。例如，以下命令在使用 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 会将状态标记为完成。一旦停用完成，您就可以进行下一步了。

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

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

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

.deb 或 .rpm 软件包会安装一个 systemd 服务文件到 /lib/systemd/system/minio.service。对于二进制安装，本程序假设该文件是根据安装和管理程序手动创建的。

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 会将状态标记为完成。一旦 MinIO 完成所有池的停用，您就可以进行下一步了。

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

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

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

.deb 或 .rpm 软件包会安装一个 systemd 服务文件到 /lib/systemd/system/minio.service。对于二进制安装，本程序假设该文件是根据安装和管理程序手动创建的。

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 确认部署中所有剩余服务器的正常运行时间。