使用 mc admin decommission 停用服务器池

硬件最终会达到其使用寿命的终点，必须在故障对数据可用性和完整性构成风险之前将其停用。 因此，必须主动删除数据，以防止对依赖应用程序的干扰。 MinIO 最近增加了在不影响数据可用性的情况下停用和升级服务器池的功能。 虽然停用不是一个常见的请求功能，但我们为那些在整个存储生命周期中进行规划的人提供它。 在进行关键采购时，基础设施团队喜欢提前计划，MinIO 可以满足您的需求。

这篇文章将向您展示如何停用服务器池、查看正在进行的停用状态或取消停用。

用例：停用服务器池

假设您有一个由一个包含四个节点的服务器池组成的 MinIO 集群。 此服务器池的硬件正在接近使用寿命的终点。 您购买了一个新的第二个服务器池，并希望将其添加到集群中以替换第一个服务器池，同时保持数据可用性。 mc admin decommission 命令将首先将第一个服务器池锁定为只读，然后将对象转移到新的池中。 在多池 MinIO 环境中，停用会将数据均匀地分散到所有池中。

我们将在安装硬件后进行下一步 添加新的服务器池 到我们的 MinIO 集群。

停用原始服务器池

打开一个终端并使用 MinIO 客户端开始。

$ mc admin decommission start alias/ http://minio{1...2}/data{1...4}

检查整体停用状态

根据您要移动的数据量，该过程可能需要一些时间。 您可以使用以下命令检查所有池的当前停用状态

$ mc admin decommission status alias/

您将看到类似以下内容

| ID  | Pools                          | Capacity                         | Status  |
| 1st | http://minio{1...2}/data{1...4}| 439 GiB (used) / 561 GiB (total) | Active  |
| 2nd | http://minio{3...4}/data{1...4}| 329 GiB (used) / 421 GiB (total) | Active  |

检查服务器池停用状态

您还可以查看每个池的更详细状态，例如

$ mc admin decommission status alias/ http://minio{1...2}/data{1...4}
Decommissioning rate at 36 MiB/sec [4 TiB/50 TiB]
Started: 1 minute ago

如果您从未停用的池请求状态，您将收到错误消息

mc admin decommission status alias/ http://minio{1...2}/data{1...4}
ERROR: This pool is not scheduled for decommissioning currently.

取消服务器池停用

或者，如果您决定不停用原始服务器池，您可以取消该过程。 这可能用于负载过高，并且您想将停用安排在非高峰时间

mc admin decommission cancel 不带参数，列出任何正在进行的停用。

| ID  | Pools                          | Capacity                          | Status  |
| 1st | http://minio{1...2}/data{1...4}| 439 GiB (used) / 561 GiB (total)  | Draining|

请注意，取消停用不会使池重新激活，以避免在池之间出现部分命名空间。

$ mc admin decommission cancel alias/ http://minio{1...2}/data{1...4}
| ID  | Pools                          | Capacity                          | Status            |
| 1st | http://minio{1...2}/data{1...4}| 439 GiB (used) / 561 GiB (total)  | Draining(Canceled)|

在不太可能的情况下停用失败，status 将指示停用失败

| ID  | Pools                          | Capacity                          | Status          |
| 1st | http://minio{1...2}/data{1...4}| 439 GiB (used) / 561 GiB (total)  | Draining(Failed)|
| 2nd | http://minio{3...4}/data{1...4}| 329 GiB (used) / 421 GiB (total)  | Active          |

您可以使用以下命令重新启动已取消或失败的停用

$ mc admin decommission start alias/ http://minio{1...2}/data{1...4}

停用何时完成？

status 命令还会告诉您停用何时完成

$ mc admin decommission status alias/
| ID  | Pools                          | Capacity                          | Status    |
| 1st | http://minio{1...2}/data{1...4}| 439 GiB (used) / 561 GiB (total)  | Complete  |
| 2nd | http://minio{3...4}/data{1...4}| 329 GiB (used) / 421 GiB (total)  | Active    |

删除服务器池

最后一步是从 MinIO 部署中删除第一个服务器池。 从您的 MinIO 启动命令中删除此服务器池的地址。

在 **裸机部署** 中，如果您为所有三个服务器池启动了 MinIO，如下所示

$ minio server http://minio{1...2}/data{1...4} http://minio{3...4}/data{1...4} http://minio{5...6}/data{1...4} 

那么您可以删除第一个参数来更新您的 MINIO_VOLUMES 设置

$ minio server http://minio{3...4}/data{1...4} http://minio{5...6}/data{1...4}

然后在部署中的所有服务器上并行使用 systemctl restart minio。 

在 **Kubernetes 部署** 中，需要通过更改 MinIO 容器的命令行输入来修改 MinIO 的 statefulset 规范。 完成相关更改后，继续执行 kubectl apply -f statefulset.yaml。

在 **基于操作符的 MinIO 部署** 中，您需要修改 tenant.yaml 规范并从两个条目修改 pools: 部分到一个条目，完成相关更改后，继续执行 kubectl apply -f tenant.yaml。

体验 MinIO

您可以使用单个命令在 MinIO 集群上无中断地删除和升级硬件。 这不仅使基础设施管理员的生活更轻松，而且还确保您的对象存储解决方案可以通过使用 MinIO 的灵活服务器池架构来超越其硬件。 

您可以通过 下载 MinIO 来尝试一下。 如果您想了解更多信息或有任何问题，请加入我们的 Slack 频道，给我们发送邮件至 hello@min.io 或使用“联系专家”按钮