文件

硬體檢查清單

在規劃生產環境、分散式 MinIO 部署的硬體配置時,請使用下列檢查清單。

考量事項

在為您的 MinIO 實作選擇硬體時,請考慮以下因素

  • 啟動時要儲存的預期資料量(以 tebibytes 為單位)

  • 至少未來兩年的預期資料大小增長

  • 物件數量(依平均物件大小)

  • 資料的平均保留時間(以年為單位)

  • 要部署的站台數量

  • 預期的儲存貯體數量

生產環境硬體建議

下列檢查清單遵循 MinIO 針對生產環境部署的建議配置。所提供的指南旨在作為基準,不能取代 MinIO SUBNET 效能診斷、架構審查和直接工程支援。

MinIO 與任何分散式系統一樣,都受益於為給定伺服器集區中的所有節點選擇相同的配置。請確保整個集區節點的硬體(CPU、記憶體、主機板、儲存配接器)和軟體(作業系統、核心設定、系統服務)選擇一致。

如果節點具有不同的硬體或軟體配置,部署可能會顯示不可預測的效能。受益於將過時資料儲存在較低成本硬體上的工作負載,應該部署專用的「暖」或「冷」MinIO 部署,並將資料轉換到該層級。

MinIO 不提供託管服務或硬體銷售

請參閱我們的參考硬體頁面,了解我們硬體合作夥伴提供的精選伺服器和儲存元件。

描述

最低

建議

專用裸機或虛擬主機(「主機」)。

4 個專用主機

8 個以上的專用主機

每個主機的專用本機連接磁碟機.

每個 MinIO 伺服器 4 個磁碟機

每個 MinIO 伺服器 8 個以上的磁碟機

高速網路基礎架構.

25GbE

100GbE

支援現代 SIMD 指令 (AVX-512) 的伺服器級 CPU,例如 Intel® Xeon® Scalable 或更高版本。

每個主機 8 個 CPU/插槽或 vCPU

每個主機 16 個以上的 CPU/插槽或 vCPU

可用記憶體以滿足或超過每個伺服器的使用量,並具備合理的緩衝。

每個主機 32GB 可用記憶體

每個主機 128GB 以上可用記憶體

重要

以下領域對 MinIO 效能的影響最大,依重要性順序排列

網路基礎架構

吞吐量不足或受限會限制效能

儲存控制器

舊韌體、吞吐量受限或硬體故障會限制效能並影響可靠性

儲存(磁碟機)

舊韌體或速度慢/老舊/故障的硬體會限制效能並影響可靠性

在專注於其他硬體資源(例如與運算相關的限制)之前,請優先確保每個這些領域所需的元件。

上述最低建議反映了 MinIO 在協助企業客戶部署於各種 IT 基礎架構上,同時維持所需 SLA/SLO 的經驗。雖然 MinIO 可能在低於最低建議拓撲的條件下執行,但任何潛在的成本節省都將以降低可靠性、效能或整體功能為代價。

網路

MinIO 建議使用高速網路,以支援連接儲存裝置(聚合磁碟機、儲存控制器和 PCIe 匯流排)的最大可能吞吐量。下表提供給定實體或虛擬網路介面所支援的最大儲存吞吐量的一般準則。此表假設所有網路基礎架構組件(例如路由器、交換器和實體纜線)也支援網路介面卡頻寬。

網路介面卡頻寬 (Gbps)

預估聚合儲存吞吐量 (GBps)

10Gbps

1.25GBps

25Gbps

3.125GBps

50Gbps

6.25GBps

100Gbps

12.5GBps

網路對 MinIO 效能的影響最大,其中每個主機的低頻寬會人為地限制儲存的潛在效能。以下網路吞吐量限制的範例假設使用持續 I/O 約為 100MB/s 的旋轉磁碟機。

  • 1GbE 網路連結可支援高達 125MB/s,或一個旋轉磁碟機

  • 10GbE 網路可支援大約 1.25GB/s,可能支援 10-12 個旋轉磁碟機

  • 25GbE 網路可支援大約 3.125GB/s,可能支援約 30 個旋轉磁碟機

記憶體

記憶體主要限制每個節點的並行連線數。

您可以使用此公式計算每個節點的最大並行請求數

\(totalRam / ramPerRequest\)

要計算每個請求使用的 RAM 量,請使用此公式

\(((2MiB + 128KiB) * driveCount) + (2 * 10MiB) + (2 * 1 MiB)\)

10MiB 是預設的 erasure block 大小 v1。1 MiB 是預設的 erasure block 大小 v2。

下表列出基於主機磁碟機數量和可用系統 RAM 的節點上最大並行請求數

磁碟機數量

32 GiB 的 RAM

64 GiB 的 RAM

128 GiB 的 RAM

256 GiB 的 RAM

512 GiB 的 RAM

4 個磁碟機

1,074

2,149

4,297

8,595

17,190

8 個磁碟機

840

1,680

3,361

6,722

13,443

16 個磁碟機

585

1,170

2.341

4,681

9,362

下表提供基於節點上本機儲存總量分配 MinIO 使用的記憶體的一般準則

主機儲存總量

建議的主機記憶體

高達 1 Tebibyte (Ti)

8GiB

高達 10 Tebibyte (Ti)

16GiB

高達 100 Tebibyte (Ti)

32GiB

高達 1 Pebibyte (Pi)

64GiB

超過 1 Pebibyte (Pi)

128GiB

重要

RELEASE.2024-01-28T22-35-53Z 開始,MinIO 在分散式設定中為每個節點預先配置 2GiB 的記憶體,並為單節點設定預先配置 1GiB 的記憶體。

儲存

對磁碟機的獨佔存取權

MinIO 需要 對於提供用於物件儲存的磁碟機或磁碟區的獨佔存取權。其他程序、軟體、腳本或人員不應直接對提供給 MinIO 的磁碟機或磁碟區,或 MinIO 放置在其上的物件或檔案執行任何操作。

除非 MinIO 工程部門指示,否則請勿使用腳本或工具直接修改、刪除或移動所提供磁碟機上的任何資料分片、同位分片或中繼資料檔案,包括從一個磁碟機或節點到另一個磁碟機或節點。此類操作很可能導致廣泛的損壞和資料遺失,超出 MinIO 的修復能力。

使用直接連接的「本機」儲存裝置 (DAS)

DAS,例如本機連接的 JBOD(僅是一堆磁碟機)陣列,比網路儲存裝置(NAS、SAN、NFS)提供顯著的效能和一致性優勢。

網路檔案系統磁碟區會破壞一致性保證

MinIO 嚴格的讀取後寫入列表後寫入一致性模型需要本機磁碟機檔案系統。如果底層儲存磁碟區是 NFS 或類似的網路連接儲存磁碟區,則 MinIO 無法提供一致性保證。

使用帶有標籤的 XFS 格式化磁碟機

將磁碟機格式化為 XFS,並以 JBOD 陣列的形式呈現給 MinIO,不使用 RAID 或其他集區配置。使用任何其他類型的備份儲存(SAN/NAS、ext4、RAID、LVM)通常會導致效能、可靠性、可預測性和一致性降低。

格式化 XFS 磁碟機時,每個磁碟機都應套用唯一的標籤。例如,以下命令將四個磁碟機格式化為 XFS 並套用對應的磁碟機標籤。

mkfs.xfs /dev/sdb -L MINIODRIVE1
mkfs.xfs /dev/sdc -L MINIODRIVE2
mkfs.xfs /dev/sdd -L MINIODRIVE3
mkfs.xfs /dev/sde -L MINIODRIVE4

使用 /etc/fstab 掛載磁碟機

MinIO 需要 磁碟機在重新啟動時保持其在掛載位置的順序。MinIO 支援將具有現有 MinIO 資料的磁碟機任意遷移到新的掛載位置,無論是有意的還是由於作業系統層級行為導致的。

必須使用 /etc/fstab 或類似的掛載控制系統,以將磁碟機掛載到一致的路徑。例如

$ nano /etc/fstab

# <file system>        <mount point>    <type>  <options>         <dump>  <pass>
LABEL=MINIODRIVE1      /mnt/drive-1     xfs     defaults,noatime  0       2
LABEL=MINIODRIVE2      /mnt/drive-2     xfs     defaults,noatime  0       2
LABEL=MINIODRIVE3      /mnt/drive-3     xfs     defaults,noatime  0       2
LABEL=MINIODRIVE4      /mnt/drive-4     xfs     defaults,noatime  0       2

您可以使用 mount -a 在初始設定期間將這些磁碟機掛載到這些路徑。否則,作業系統應在節點啟動過程中掛載這些磁碟機。

MinIO 強烈建議使用基於標籤的掛載規則,而不是基於 UUID 的規則。基於標籤的規則允許使用具有匹配格式和標籤的替代品來交換不健康或無法運作的磁碟機。基於 UUID 的規則需要編輯 /etc/fstab 檔案,以使用新的磁碟機 UUID 來取代對應。

注意

如果一個或多個遠端檔案掛載傳回錯誤或失敗,則依賴於掛載外部儲存的雲端環境執行個體可能會遇到開機失敗。例如,如果一個或多個 EBS 磁碟區掛載失敗,則具有已掛載持久性 EBS 磁碟區的 AWS ECS 執行個體可能無法使用標準 /etc/fstab 配置啟動。

您可以設定 nofail 選項,以在啟動時靜音錯誤報告,並允許執行個體在一個或多個掛載問題的情況下啟動。

您不應在具有本機連接磁碟的系統上使用此選項,因為靜音磁碟錯誤會阻止 MinIO 和作業系統以正常方式回應這些錯誤。

停用錯誤時重試 XFS

MinIO 強烈建議使用 max_retries 配置,針對以下錯誤類別停用錯誤時重試行為

  • EIO 讀取或寫入時發生錯誤

  • ENOSPC 裝置上沒有剩餘空間的錯誤

  • default 所有其他錯誤

預設的 max_retries 設定通常會指示檔案系統無限期地在錯誤時重試,而不是傳播錯誤。MinIO 可以適當地處理 XFS 錯誤,因此錯誤時重試行為最多會引入不必要的延遲或效能降低。

以下腳本會迭代指定掛載路徑下的所有磁碟機,並將 XFS max_retries 設定為 0 或「在錯誤時立即失敗」,以用於建議的錯誤類別。此腳本會忽略任何未掛載的磁碟機,無論是手動掛載還是透過 /etc/fstab 掛載。修改 /mnt/drive 行以符合您的 MinIO 磁碟機所使用的模式。

#!/bin/bash

for i in $(df -h | grep /mnt/drive | awk '{ print $1 }'); do
      mountPath="$(df -h | grep $i | awk '{ print $6 }')"
      deviceName="$(basename $i)"
      echo "Modifying xfs max_retries and retry_timeout_seconds for drive $i mounted at $mountPath"
      echo 0 > /sys/fs/xfs/$deviceName/error/metadata/EIO/max_retries
      echo 0 > /sys/fs/xfs/$deviceName/error/metadata/ENOSPC/max_retries
      echo 0 > /sys/fs/xfs/$deviceName/error/metadata/default/max_retries
done
exit 0

您必須在所有 MinIO 節點上執行此腳本,並將腳本設定為在重新啟動時重新執行,因為 Linux 作業系統通常不會保留這些變更。您可以使用具有 @reboot 計時的 cron 作業,以便在節點重新啟動時執行上述腳本,並確保所有磁碟機都停用了錯誤時重試。使用 crontab -e 建立以下作業,修改腳本路徑以符合每個節點上的路徑

@reboot /opt/minio/xfs-retry-settings.sh

使用一致的磁碟機類型和容量

確保 MinIO 部署中底層儲存的一致磁碟機類型(NVMe、SSD、HDD)。MinIO 不會區分儲存類型,也不支援在單一部署中配置「熱」或「溫」磁碟機。混合磁碟機類型通常會導致效能降低,因為部署中最慢的磁碟機成為瓶頸,而與較快磁碟機的功能無關。

在每個 MinIO 伺服器集區中,跨所有節點使用相同容量和類型的磁碟機。MinIO 將每個磁碟機的最大可用大小限制為部署中最小的大小。例如,如果部署中有 15 個 10TB 磁碟機和 1 個 1TB 磁碟機,則 MinIO 會將每個磁碟機的容量限制為 1TB。