MinIO | 多雲環境的物件儲存

成功的多雲儲存策略會利用架構
和可在各種環境中運作的工具。

公有雲

這是一個越來越大的領域，但從 AWS、Azure、GCP、IBM、阿里巴巴、騰訊和政府雲開始。您的混合/多雲儲存軟體需要在您的應用程式堆疊運行的任何地方運行。即使是聲稱在單一雲端上運行的公司也不是 - 總是有其他雲端。MinIO 在每個公有雲提供者之間提供儲存一致性，防止您在擴展到新雲端時需要重寫應用程式。

私有雲

Kubernetes 是現代私有雲的主要軟體架構。這包括所有 Kubernetes 發行版，例如 VMware (Tanzu)、RedHat (OpenShift)、Rancher/SUSE、HP (Ezmeral) 和 Rafay。多雲 Kubernetes 需要軟體定義且雲原生的物件儲存。私有雲還包括更傳統的裸機實例，但企業工作負載越來越多地被容器化和協調。

邊緣

邊緣是關於將計算移動到產生資料的位置。一旦處理完畢，資料就會移動到更集中的位置。邊緣儲存解決方案必須輕巧、強大、雲原生且具有彈性，才能在此多雲架構中運行。很難做好這件事，這就是為什麼很少有供應商討論它，他們沒有很好的答案 - 即使是 Amazon。

混合/多雲儲存的屬性

多雲儲存遵循公有雲中建立的模型，公有雲提供者一致採用雲原生物件儲存。公有雲的成功有效地使檔案和區塊儲存過時。每個新應用程式都是為 AWS S3 API 而寫的 - 而不是 POSIX。為了像雲原生技術一樣擴展和執行，舊應用程式必須為 S3 API 重寫，並重構為微服務以相容於容器。

Kubernetes 原生

Kubernetes 原生設計需要一個運算子服務來佈建和管理多租戶物件儲存即服務基礎架構。每個租戶都在自己隔離的命名空間中運行，同時共享底層硬體資源。運算子模式使用自訂資源定義 (CRD) 擴展 Kubernetes 熟悉的宣告式 API 模型，以執行常見操作，例如資源協調、不中斷升級、叢集擴展和維持高可用性。

MinIO 專為充分利用 Kubernetes 架構而打造。由於伺服器二進位檔案快速且輕巧，MinIO Operator 能夠密集地共同部署多個租戶而不會耗盡資源。使用可攜式 Kubernetes 原生儲存獲得多雲能力，利用 Kubernetes 和相關生態系統的優勢。

一致

混合/多雲儲存在 API 相容性、效能、安全性和合規性方面必須保持一致。它需要以一致且獨立於底層硬體的方式執行。任何變化，即使是很小的變化，都可能破壞應用程式 - 造成巨大的操作負擔。

由於 MinIO 非常輕巧，我們可以在幾分鐘內跨公有、私有和邊緣推出不中斷更新，保持相同一致的體驗。MinIO 抽象化了這些架構之間的底層差異，包括金鑰管理、身分管理、存取原則和硬體/作業系統差異。

高效能

由於物件儲存被用作主要和次要儲存，因此它需要大規模提供效能。從行動/網路應用程式到 AI/ML，資料密集型工作負載需要底層物件儲存具有卓越的效能。即使是資料保護工作負載也需要高效能存取才能進行重複資料刪除和快照。沒有企業可以承受緩慢的還原過程。傳統上，這些工作負載需要裸機效能。現在可以將所有這些工作負載容器化 - 正如公有雲提供者的成功所證明的那樣。

MinIO 是世界上最快的物件儲存，在 NVMe 上的讀寫速度為 325 GiB/s 和 171 GiB/s，在 HDD 上的讀寫速度為 11 GiB/s 和 9 GiB/s。在這些速度下，每個工作負載都可以在任何基礎架構上運行的任何多雲架構範圍內。

可擴展

許多人認為擴展僅僅是指系統可以變得多大。然而，在這個想法中被忽略的是，隨著環境的增長，操作效率的重要性。多雲物件儲存解決方案必須有效率且透明地擴展，無論底層環境如何，並且只需最少的人工互動和最大程度的自動化即可完成。這只能透過建立在簡單架構之上的 API 驅動平台來實現。

MinIO 對簡單性的不懈關注意味著可以使用最少的人力資源來管理大規模、數 PB 的資料基礎架構。這是 API 和自動化的功能，並建立了一個可以創建顯著可擴展的多雲儲存的環境。

軟體定義

在多雲環境中取得成功的唯一方法是使用軟體定義儲存。原因很簡單。硬體設備無法在公有雲或 Kubernetes 上運行。公有雲儲存服務產品並非設計為在其他公有雲、私有雲或 Kubernetes 平台上運行。即使它們可以運行，頻寬成本也會高於儲存成本，因為它們並非開發為跨網路複製。而軟體定義儲存則可以在公有雲、私有雲和邊緣環境中運行。

MinIO 從軟體起家，可跨多種作業系統和硬體架構移植。我們的 200 萬+ IP 在 AWS、GCP 和 Azure 上運行便是證明。