停用伺服器池

先備份叢集設定

在開始停用之前，請使用 mc admin cluster bucket export 和 mc admin cluster iam export 命令，分別取得 Bucket 元數據和 IAM 配置的快照。 您可以使用這些快照來還原 Bucket/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 超出本程序的範圍。

部署必須有足夠的儲存空間

停用程序會將物件從目標池遷移到部署中的其他池。部署上的總可用儲存空間必須超過已停用池的總儲存空間。

使用 Erasure Code 計算器 來判斷可用的儲存容量。然後從該容量中減去已在部署中的物件大小。

例如，考慮一個已使用和可用儲存空間分佈如下的部署

停用池 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 開始，停用也會忽略根據父 Bucket 設定的 生命週期規則 而過期的物件版本。從 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）路由到部署中的剩餘池。

管理部署連線的負載平衡器、反向 Proxy 或其他網路控制元件目前不需要修改其配置。

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 顯示為 failed，您可以重新執行 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) 路由到部署中未排定解除委任的剩餘池。

已解除委任的池的清空一次發生一個池，依序完成每個池的解除委任。清空 _不會_ 同時發生於所有解除委任池。

管理部署連線的負載平衡器、反向 Proxy 或其他網路控制元件目前不需要修改其配置。

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 顯示為 failed，您可以重新執行 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 來確認部署中所有剩餘伺服器的正常運行時間。