关闭服务器池

MinIO支持在具有两个及以上池的部署中取消池的服务并将其移除服务器池。要进行取消池的服务，必须至少有一个剩余池具有足够的可用空间来接收取消服务池中的对象。

从 RELEASE.2023-01-18T04-36-38Z 开始，MinIO支持在单个取消池命令中排队多服务器池。列出的每个池立即进入只读状态，但只有一个池会被逐一处理。

取消池设计用于删除相对于部署中的其他池而言硬件不再足够或性能不佳的旧服务器池。基于每个池中可用空闲空间的比率，MinIO自动将数据从取消服务池中迁移到剩余池中。

在取消服务过程中，MinIO通常路由读操作（例如 GET 、 LIST 、 HEAD ）。 MinIO将写操作（例如 PUT 、带版本控制的 DELETE ）路由到部署中剩余的 “活动” 池中。带版本控制的对象在整个迁移过程中保持其排序。

本页上的程序从具有至少两个服务器池的分布式 MinIO 部署中取消并移除一个或多个服务器池。

退役是永久性的

一旦MinIO开始停用一个池，它就会将该池标记为永久不活动状态（“正在排空”）。取消或中断停用过程**不会**将池恢复为活动状态。在停用多个池时要格外小心。

停用是一个重要的管理操作，需要在计划和执行上注意，并不是一个琐碎或“日常”的任务。

通过4008 -566-339联系MinIO销售团队，可以更安全的处理好退役相关问题，我们为商业客户提供全面的商业化技术支持。通过与MinIO工程师协调可以确保成功停用，包括性能测试和健康诊断。

社区用户可以在`MinIO社区支持 <https://slack.min.io>`__寻求支持。社区支持只是最佳努力，并没有关于响应时间的服务级别协议。

先决条件

先备份集群设置

在开始退役之前，使用 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很好地配合使用：

为了支持MinIO而配置防火墙或负载均衡器不在此过程的范围内。

部署必须具备足够的存储空间

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

使用纠删码计算器来确定可用存储容量。然后通过已存在于部署中的对象的大小来减少它。

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

Pool 1	100TB Used	200TB Total
Pool 2	100TB Used	200TB Total
Pool 3	100TB Used	200TB Total

退役池1（Pool 1）需要将100TB已使用的存储空间分布到剩余池中。池2（Pool 2）和池3（Pool 3）各自拥有100TB未使用的存储空间，并且可以安全地吸收存储在池1中的数据。

但是，如果池1 （Pool 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 或者联系4008-566-339 MinIO工程师团队问题以寻求进一步帮助。没有SUBNET订阅的社区用户可以重试退役流程或通过 MinIO 社区 Slack 寻求其他支持。 MinIO仅提供最佳尝试的社区支持，并且在响应灵敏度方面不提供 SLA。

退役启用分层的服务器

在 RELEASE.2023-03-20T20-16-18Z 版本发生变更.

对于启用和激活了分层的部署，退役将对象引用移动到新的活动池中。应用程序可以继续针对这些对象发出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 │
└─────┴────────────────────────────────────────────────────────────────┴──────────────────────────────────┴────────┘

以上示例部署有三个存储池。每个存储池有四个服务器，每个服务器有四个驱动器。

首先确定要退役的目标存储池，并检查当前容量。 MinIO 部署中剩余的存储池必须具备足够的总容量，以迁移存储在将被退役的存储池中的所有对象。

在上面的示例中，该部署有 210TiB 的总存储空间，其中使用了 110TiB。第一个存储池 ( minio-{01...04} ) 是退役的目标，因为它在创建 MinIO 部署时就已经被预配，并且已经完全满了。剩余的新的存储池可以吸收第一个存储池中存储的所有对象，而不会对总可用存储造成显著影响。

2) 开始退役过程

退役是永久性的

一旦MinIO开始退役一个存储池，它会将该存储池标记为*永久性的*不活动状态 (“draining”) 。取消或中断退役过程**不会**将存储池恢复为活跃状态。

在运行以下命令之前，审查并确认您正在退役正确的存储池。

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

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

退役多服务器池

在 RELEASE.2023-01-18T04-36-38Z 版本发生变更.

在发出退役命令时，您可以开始多个服务器池的退役过程。

输入命令后：

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 │  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 │
└─────┴────────────────────────────────────────────────────────────────┴──────────────────────────────────┴────────┘

上述示例部署有三个池。每个池都有四个服务器，每个服务器有四个驱动器。

确定退役目标池并查看当前容量。部署中的其余池必须具有足够的总容量以迁移存储在退役池中的所有对象。

在上面的示例中，部署共有111TiB的总存储空间，已使用了145TiB。

第一个池( minio-{01...04} ) 是第一个退役目标，因为它是在创建MinIO部署时预配的，并且已经完全填满。
第二个池 ( minio-{05...08} ) 是第二个退役目标，因为它也是在创建MinIO部署时预配的，并且接近饱和。
第四个池 ( minio-{13...16} ) 是一个新添加的池，拥有来自已完成服务器扩展的新硬件。

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

重要

在开始退役过程之前，请完成任何服务器扩展以添加新的存储资源。

2) 启动退役过程

退役是永久性的

一旦MinIO开始退役池，它将标记这些池为 永久性 不活动状态（ draining ）。取消或以其他方式中断退役过程不会将池恢复到活动状态。

在运行以下命令之前，请检查并验证您正在退役正确的池。

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

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

商业支持购买咨询

关闭服务器池

先决条件

先备份集群设置

网络设置和防火墙

部署必须具备足够的存储空间

考虑因素

替换服务器池

退役是可恢复的

退役是非破坏性的

退役会忽略已过期的对象和尾随的 DeleteMarker

行为

最终清单检查

退役启用分层的服务器

退役服务器池

1) 检查MinIO部署的拓扑结构图

2) 开始退役过程

3) 监视退役过程

4) 从部署配置中删除已退役的池

5) 更新网络控制计划

6) 重启MinIO部署

退役多服务器池

1) 检查MinIO部署的网络拓扑

2) 启动退役过程

3) 监控退役过程

4) 从部署配置中删除已退役池。

5) 更新网络控制计划

6) 重启MinIO部署

退役会忽略已过期的对象和尾随的 `DeleteMarker`