文件

部署架構

本頁提供從生產角度來看的 MinIO 部署架構概述。有關特定硬體或軟體組態的資訊,請參閱

分散式 MinIO 部署

一個生產 MinIO 部署至少包含 4 個具有同質儲存和運算資源的 MinIO 主機。

MinIO 將這些資源彙總為一個,並將其本身呈現為單一物件儲存服務。

4 Node MinIO deployment with homogeneous storage and compute resources

此池中的每個 MinIO 主機都具有相符的運算、儲存和網路組態

當使用本地連接的儲存(例如附加到主機上 PCI-E 控制器板的 NVMe 或 SSD 硬碟)時,MinIO 可提供最佳效能。

儲存控制器應以「Just a Bunch of Drives」(JBOD) 組態呈現 XFS 格式的硬碟,且沒有 RAID、池化或其他硬體/軟體復原層。MinIO 不建議在硬碟或控制器層進行快取。任一種快取都可能在快取填滿和清除時導致I/O尖峰,從而導致無法預測的效能。

MinIO Server diagram of Direct-Attached Storage via SAS to a PCI-E Storage Controller

每個 SSD 都透過 SAS 連接到以 HBA 模式運作的 PCI-E 連接的儲存控制器

MinIO 會自動將池中的硬碟分組為抹除集

抹除集是 MinIO 可用性和復原能力的基礎組件。MinIO 在池中的節點之間對稱地條帶化抹除集,以保持抹除集硬碟的均勻分佈。然後,MinIO 會根據部署的同位將物件劃分為資料和同位分片,並將它們分佈在抹除集中。

有關 MinIO 冗餘和修復的更完整討論,請參閱抹除編碼物件修復

Diagram of object being sharded into eight data and eight parity blocks, distributed across sixteen drives

使用最大同位數 EC:8,MinIO 將物件切分成 8 個資料和 8 個同位區塊,並將它們分佈在抹除集中的硬碟之間。此池中的所有抹除集都具有相同的條帶大小和分片分佈。

MinIO 使用基於物件名稱和路徑的確定性雜湊演算法,來選擇特定物件的 Erasure Set(糾刪碼集合)。

對於每個獨特的物件命名空間 BUCKET/PREFIX/[PREFIX/...]/OBJECT.EXTENSION,MinIO 總是為讀/寫操作選擇相同的 Erasure Set。MinIO 會處理 Pool(儲存池)和 Erasure Set 內的所有路由,使選擇/讀取/寫入過程對應用程式完全透明。

Diagram of object retrieval from only data shards

MinIO 會在將物件返回給請求用戶端之前,從資料或同位分片中透明地重建物件。

每個 MinIO 伺服器都完整掌握分散式拓撲的資訊,因此應用程式可以連接並將操作導向部署中的任何節點。

回應的 MinIO 節點會自動處理內部請求路由到部署中的其他節點,將最終回應返回給用戶端。

應用程式通常不應管理這些連線,因為對部署拓撲的任何變更都需要更新應用程式。生產環境應部署負載平衡器或類似的網路控制平面元件,來管理與 MinIO 部署的連線。例如,您可以部署 NGINX 負載平衡器,針對部署中的可用節點執行「最少連線」或「輪循」負載平衡。

Diagram of an eight node MinIO deployment behind a load balancer

負載平衡器將請求路由到部署中的任何節點。接收節點會處理之後的任何節點間請求。

您可以透過儲存池擴展來擴充 MinIO 部署的可用儲存空間。

每個 Pool 都由一組獨立的節點組成,這些節點具有自己的 Erasure Set。MinIO 必須查詢每個 Pool,以判斷正確的 Erasure Set,以便將讀寫操作導向到該 Erasure Set,因此每個額外的 Pool 都會增加每次呼叫的節點間流量。包含正確 Erasure Set 的 Pool 接著會回應操作,對應用程式保持完全透明。

如果您透過擴展儲存池來修改 MinIO 拓撲,則可以修改負載平衡器,將新儲存池的節點納入其中,來更新應用程式。應用程式可以繼續使用負載平衡器的位址來進行 MinIO 部署,而無需進行任何更新或修改。這可確保請求平均分散到所有儲存池,同時應用程式繼續使用單一負載平衡器 URL 來進行 MinIO 操作。

Diagram of a multi-pool minio deployment behind a load balancer

PUT 請求需要檢查每個儲存池以找到正確的 Erasure Set。一旦確定,MinIO 會對物件進行分割,並將資料和同位分片分散到適當的集合中。

用戶端應用程式可以使用任何與 S3 相容的 SDK 或程式庫,來與 MinIO 部署互動。

MinIO 發布其自己的SDK,專門用於與 S3 相容的部署。

Diagram of multiple S3-compatible clients using SDKs to connect to MinIO

使用各種與 S3 相容的 SDK 的用戶端,可以針對相同的 MinIO 部署執行操作。

MinIO 使用嚴格的 S3 API 實作,包括要求用戶端使用 AWS Signature V4 或舊版 Signature V2 來簽署所有操作。AWS 簽章計算使用用戶端提供的標頭,因此負載平衡器、Proxy、安全程式或其他元件對這些標頭進行的任何修改,都將導致簽章不符的錯誤和請求失敗。請確保任何此類中間元件都支援從用戶端到伺服器傳遞未經修改的標頭。

雖然 S3 API 對所有操作都使用諸如 GETPOST 之類的 HTTP 方法,但應用程式通常會使用 SDK 來進行 S3 操作。特別是,簽章計算的複雜性通常會使透過 curl 或類似的 REST 用戶端進行介面連接變得不切實際。MinIO 建議使用與 S3 相容的 SDK 或程式庫,這些 SDK 或程式庫會自動執行簽章計算,作為操作的一部分。

已複寫的 MinIO 部署

MinIO 站點複寫提供對同步不同獨立部署的支援。

您可以在不同的機架、資料中心或地理區域中部署對等站點,以支援諸如 BC/DR 或全球分散式 MinIO 物件儲存中的地理位置讀/寫效能等功能。

Diagram of a multi-site deployment with three MinIO peer site

具有三個對等點的 MinIO 多站點部署。在一個對等點上的寫入操作會自動複寫到組態中的所有其他對等點。

複寫效能主要取決於每個對等站點之間的網路延遲。

對於地理上分散的對等站點,站點之間的高延遲可能導致顯著的複寫滯後。這可能會與接近或達到部署整體效能容量的工作負載複合,因為複寫過程本身需要足夠的空閒 I/O 來同步物件。

Diagram of a multi-site deployment with latency between sites

在此對等組態中,站點 A 與其對等站點之間的延遲為 100 毫秒。物件完全同步到所有站點的最快時間至少為 110 毫秒。

部署支援站點間容錯移轉協定的全域負載平衡器或類似網路設備,對於多站點部署的功能至關重要。

負載平衡器應支援健全狀況探測/檢查設定,以偵測一個站點的故障,並自動將應用程式重新導向到任何剩餘的健全對等點。

Diagram of a site replication deployment with two sites

負載平衡器會使用已設定的邏輯(地理位置、延遲等)自動路由用戶端請求。寫入一個站點的資料會自動複寫到另一個對等站點。

負載平衡器應滿足單站點部署在連線平衡和標頭保留方面的相同要求。MinIO 複寫會透過將物件排隊進行複寫來處理暫時性故障。