MinIO對象存儲介紹

2024-04-06 分类：知識 阅读()

Minio是GlusterFS創始人之一Anand Babu Periasamy發佈新的開源項目。基於Apache License v2.0開源協議的對象存儲項目，采用Golang實現，客戶端支Java,Python,Javacript, Golang語言。

其設計的主要目標是作為私有雲對象存儲的標準方案。主要用於存儲海量的圖片，視頻，文檔等。非常適合於存儲大容量非結構化的數據，例如圖片、視頻、日志文件、備份數據和容器/虛擬機鏡像等，而一個對象文件可以是任意大小，從幾kb到最大5T不等。

對象存儲的元數據

在對象存儲裡，元數據包括 account（用戶）， bucket， bucket index等信息。Minio沒有獨立的元數據服務器。元數據都保存在底層的本地文件系統中。這個涉及和GlusterFs的架構設計很類似。

在本地文件系統裡，一個bucket對應本地文件系統中的一個目錄。一個對象Object對應bucket目錄下的一個子目錄（在EC的情況下對應多個part文件）。該子目錄下保存著對象相關的數據和元數據。

圖1 minio 存儲結構示意

如上圖所示：在Erasure Set中有4個磁盤：Disk1，Disk2，Disk3，Disk4，四個磁盤組成一個Erasure Set。每個bucket對應一個相應桶名稱的目錄，每個對象對應bucket的一個目錄：目錄裡保存著對應的數據和元數據文件。

創建bucket的元數據操作：對於Erasure Set(2+2)為例：創建一個bucket，對應底層文件系統的4次目錄創建。創建一個文件，需要對應底層4次目錄創建和8次文件創建操作。對於小文件，數據和元數據都保存在meta文件中，也需要4次目錄創建和4次文件創建操作。由此可推斷，minio在對應大量小文件的場景下性能非常差。

數據存儲EC

Minio目前數據僅支持EC的數據讀寫模式，不支持副本模式，也不支持一個集群內的擴容。在Minio的設計裡，一個獨立的集群中的節點數量和磁盤的數量是都是固定的，後續不能增加。隻能以Federation的方式以整個集群為單位整體擴容。

Minio把4~16個磁盤組成一個Erasure Set，每個Erasure Set包含4~16個磁盤，最少4個磁盤，最大16個磁盤，最小需要4個節點。磁盤均勻分佈在所有的節點上。

例如：4個節點，每個節點8個磁盤。 每個Erasure Set 最大16個磁盤，總共32個磁盤的集群創建2個Erasure Set。每個節點取4塊磁盤構成一個獨立的Erasure Set中。

例如：5個節點，每個節點10個磁盤：組成瞭5個Erasure Set，每個節點2個磁盤組成一個Erasure Set。

對象在Erasure Set 中通過Hash均勻分佈在所有的Erasure Set中。在Minio中用格式（EC：N），其中N表示EC（M+N），M為數據塊的數量，N為校驗塊parity的數量。Minio的讀操作，需要的磁盤數量為：Erasure Set中M個磁盤，寫操作需要M+1個磁盤。

EC Set的配置：

圖2：EC Set的配置

對於小文件，數據和元數據都同時保存在對應的xl.meta的文件中。對應大文件的寫入，會創建相應的目錄，該目錄下是對應的part的數據文件和元數據。

圖3： Minio存儲圖4： minio本地磁盤存儲結構

由圖3可知：當前集群中有2個bucket：test1和test2。 test1中有3個對象：分別是x，y，wget-log三個對象。x是30M的大文件，通過multipart上傳到集群中，有2個part，分別為part.1和part.2文件。wget-log文件是一個小文件，大小為357.9KB.

通過圖4：可以清晰的看到，每個bucket對應一個同名本地目錄，每個對象也對應一個同名的目錄，下面存數據和元數據。對應小文件，數據和元數據都保存在 xl.meta的元數據文件中。

故障恢復

Minio的EC的實現邏輯是在客戶端實現的。故障分為臨時故障和永久故障：

  1. 臨時故障：客戶端會在隊列中不斷的重試。如果客戶端crash，那麼就隻能依賴讀修復或者後臺掃描修復瞭。
  2. 永久性故障：如果磁盤故障和節點故障，這時候需要管理員去主動恢復節點（節點重啟）或者添加新的磁盤，替換舊的磁盤。替換完成後，Minio的EC Set會主動監測EC Set 的所有磁盤的狀態，並主動的修復數據。
  • 讀恢復：讀操作首先讀數據，如果數據不完整，會通過parity塊來主動修復損壞的EC data block。
  • 後臺掃描：Minio後臺會不斷的掃描數據和校驗塊是否完整，如果不完整，會在後臺啟動修復。
  • 手動觸發修復：Minio提供命令管理員也可以主動觸發修復。

minio擴容

Mino不支持單個集群的擴容。Minio通過Federation模式來實現整個集群擴容。

傳統的擴展方式是：通過增加新的存儲節點來擴展單集群，這種方式一般需要處理數據重新尋址（數據映射）和數據均衡，數據遷移的問題。

Minio不支持對單個集群進行擴展。這種設計使得系統的很多模塊更加簡單（比如一個對象定位到它所在的糾刪組EC Set，運用簡單的取模哈希即可），降低瞭整個系統出錯的概率，使得MinIO對象存儲系統更加可靠、穩定。但是這就需要部署前規劃好集群的大小和部署方式，相對不夠靈活。

Federation 依賴2個組件：

  • etcd (用於存儲桶DNS服務記錄)
  • CoreDNS (用於基於填充的桶式DNS服務記錄的DNS管理，可選)

Minio的Federation模式的擴容：隻能用於新的bucket模式。Etcd 用於記錄bucket 和 集群的映射關系。CoreDNS 用於域名解析。

圖5：Minio的聯邦模式

如圖5所示：每個minio cluster把自己的信息註冊到etcd裡。一個bucket 隻能存儲在一個集群中。Application通過coreDNS來調度bucket對應的集群，coreDNS通過各種負載均衡的算法來分配bucket訪問的集群。讀取時，通過etcd來獲取bucket對應的集群信息。

對象存儲的其它功能

Bucket and Object tag

支持給bucket和對象打標簽。目前Buceket 和 Object 的 tag 保存在對應的元數據文件中。

Minio gateway

minio gateway功能可以不使用自帶的Erasure Code Set存儲系統，可以直接對接第三方的對象存儲（AWS，GCS，Azure等其他公有雲），NAS，HDFS等存儲系統，從而通過s3直接訪問上述系統。這個功能為已有的NAS，HDFS等系統提供S3接口提供瞭極大的方便。

多租戶

每個租戶可以有一套獨立的minio server集群，部署在相關的節點和磁盤上。不同租戶Server的端口不同，對應的磁盤的數據目錄不同。

支持Bucket Quota

minio 支持bucket級別的配額管理。

Bucket replication

Minio支持bucket之間同步或異步的復制。支持兩種模式：server side和client side，也支持active-passive和 active-active模式。

  • Server-sidde Bucket Replication 支持後端相同的MinIO Cluster之間的同一個集群或者遠程集群之間的數據復
  • Client-side Bucket Replication通過mc mirror進程實現桶的數據在 S3接口兼容的集群之間完成數據復制。client-side的復制模式有兩種：同步和異步兩種復制模式。同步的模式就是當數據完全復制到2個集群中，才給客戶端完成上傳成功的應答。Minio模式為異步復制模式。

Storage Class

Minio目前支持兩種模式的存儲級別：STANDARD 和 REDUCED_REDUNDANCY， 其區別僅僅是 EC 模式下 parity block 數量的不同。REDUCED_REDUNDANCY的parity小於等於STANDARD的parity的數量。STANDARD默認EC:4，REDUCED_REDUNDANCY默認 EC:2模式。

Disk Cache

Minio 可以使用本地磁盤做Cache：實現Write-Through和Write-Back兩種緩存模式。

DiskCache主要的應用場景：Edge Server做為Gateway Cache，通過在application和public cloud之間設置一個writethrough緩存。

對於write throught模式，所有的upload操作都是 write through模式：同時寫cache 和 public cloud存儲。download操作可以就近訪問本地的Cache。

對於WriteBack，本地緩存可能有數據丟失的風險，如果應用場景可以接受，也可以使用這種緩存模式。

MINIO_CACHE_QUOTA 設置緩存容量大小。通過LRU算法來實現緩存淘汰。MINIO_CACHE_WATERMARK_LOW和 MINIO_CACHE_WATERMARK_HIGH 用來控制緩存空間的低位和高位。MINIO_CACHE_AFTER設置一個對象緩存需要的最小訪問次數。MINIO_CACHE_RANGE可以設置對象的rang read訪問是否要緩存。MINIO_CACHE_COMMIT設置緩存的模式：writeback 或者writethrough模式。MINIO_CACHE_EXCLUDE可用設置某些模式的文件名不緩存。

Bucket Notifications

Bucket notifications機制：當minio中有bucket或者對象相關的創建，刪除等事件，可以同步到外部到系統中。目前支持如下列表的外部系統：

圖6：Minio支持的bucket的Notification的模式

生命周期

  • Minio支持對象生命周期的管理。

WORM

  • 支持WORM數據保護的功能

多版本

  • Minio支持對象的多版本。

壓縮加密

  • 支持壓縮和加密

桶策略

  • 支持bucket policy功能

s3 select

  • 支持部分S3 Select功能

總結

  1. Minio的類似於glusterfs是一個無中心元數據服務器的設計。其對象的index還是依賴底層本地文件系統，導致當bucket 保存大量對象時， bucket list操作很慢。
  2. Minio目前隻支持EC的模式。
    1. 針對大文件的場景比較合適，由於設計簡單，能發揮出磁盤等硬件的性能。目前看到的minio的應用場景也主要是替代HDFS的大數據的場景。
    2. EC默認推薦的配置是EC（M+N），其中M=N的模式，也就是數據盤和冗餘盤相等的模式。例如 EC(4+4),EC(8+8)等模式，這種配置磁盤空間的利用率隻有50%左右。對於大文件，大容量的情況，似乎空間浪費還是比較嚴重。社區後續也支持自己設置EC的模式，考慮到可靠性，目前官方不推薦使用。
    3. 針對海量小文件場景，EC顯然不合適，無論是元數據還是數據存儲模式都不合適，性能比較差，空間利用率比較差。
  3. Minio的擴容也隻支持集群擴容。並且新的集群隻能存儲新創建的bucket的數據。這對應用來說很不友好。
  4. 故障恢復：在單個集群裡，節點或者磁盤都是固定的，不能動態的增加。所以磁盤或者節點失效後需要管理員人工介入，及時更換新的磁盤或者修改未能成功啟動的磁盤，然後管理員通過命令才能在後臺恢復數據。
  5. 其它對象存儲的功能支持的比較全: 存儲分級，生命周期，WORM，壓縮加密，多版本，桶策略，桶復制等功能。

綜上所述：Minio對象存儲系統適用於大文件場景，海量小文件的場景下並不適合。通過Federation擴容的方式適用於新創建的bucket的場景。 對於Minio的架構設和設計，筆者並不特別看好，其和glusterfs類似，適合大文件的應用場景，對於Minio的未來，筆者也不看好。

參考：

Learn how to configure the MinIO bucket lookups with DNS

| Minio中文文檔

赞(0)
分享到

相关推荐

看點