MinIO創始者是Anand Babu Periasamy, Harshavardhana（戒日王）等人， Anand是GlusterFS的初始開發者、Gluster公司的創始人與CTO，Harshavardhana曾經是GlusterFS的開發人員，直到2011年紅帽收購了Gluster公司。MinIO在設計上汲取了GlusterFS的相關經驗與教訓，系統複雜度上作了大量簡化。
一、MinIO簡介
01.概述
MinIO對象存儲系統是爲海量數據存儲、人工智能、大數據分析而設計，基於Apache License v2.0開源協議的對象存儲系統，它完全兼容Amazon S3接口，單個對象最大可達5TB，適合存儲海量圖片、視頻、日誌文件、備份數據和容器/虛擬機鏡像等。MinIO主要採用Golang語言實現，整個系統都運行在操作系統的用戶態空間，客戶端與存儲服務器之間採用http/https通信協議。
02.設計哲學
極簡理念——採用儘可以簡單可靠的集羣管理方案，摒棄複雜的大規模集羣調度管理，減少風險因素與性能瓶頸，聚焦產品的核心功能，打造高可靠的集羣、靈活的擴展能力以及超高的性能；
積木式擴展——建立衆多的中小規模、易管理的集羣，支持跨數據中心將多個集羣聚合成超大資源池，而非直接採用大規模、統一管理的分佈式集羣。
03.設計原則
04.產品特點
05.高級特性
二、技術架構
01 數據組織結構
NAS系統把整個存儲資源組織爲目錄樹的形式。與此不同，對象存儲系統把存儲資源組織爲租戶-桶-對象的形式。數據結構組織見下圖：
對象：類似於hash表中的表項：它的名字相當於關鍵字，它的內容相當於“值”。
桶：是若干個對象的邏輯抽象，是盛裝對象的容器。
租戶：用於隔離存儲資源。在租戶之下可以建立桶、存儲對象。
用戶：在租戶下面創建的用於訪問不同桶的賬號。可以使用MinIO提供的mc命令設置不用用戶訪問各個桶的權限。
02 數據分佈與均衡
1 去中心化架構
MinIO採用去中心化的無共享架構，對象數據被打散存放在不同節點的多塊硬盤，對外提供統一命名空間訪問，並通過Web負載均衡器或DNS輪詢（DNS round-robin）在各服務器之間實現負載均衡。
2 統一命名空間
MinIO對象存儲系統主要有兩種部署方式，一種是常見的本地分佈式集羣部署，一種是聯盟模式部署。本地分佈式集羣部署方式即在多個本地服務器節點部署MinIO軟件，並將其組件成單套分佈式存儲集羣，並提供統一命名空間和標準S3訪問接口。聯盟部署模式即將多個MinIO集羣在邏輯上組成了統一命名空間，實現近乎無限的擴展與海量的數據規模管理，這些集羣可以都在本地，或分佈在不同地域的數據中心。
如下圖所示，4個服務器節點組成一個MinIO集羣，每個服務器節點中會選擇相同數據的硬盤創建一個糾刪組，某個桶的數據會根據MinIO的分佈式算法，切片分散存儲到對應的糾刪組中（詳見糾刪碼相關內容）。
3 分佈式鎖管理
與分佈式數據庫相類似，MinIO對象存儲系統也面臨數據一致性問題：一個客戶端程序在讀取一個對象的同時，另一個客戶端程序可能正在修改或者刪除這個對象。爲了避免出現數據不一致情況，MinIO相關開發人員爲MinIO對象存儲專門設計並實現了dsync分佈式鎖管理器。它採用如下分佈式鎖管理機制：
l 任何一個節點的鎖請求都會廣播給集羣內所有在線節點；
l 如果n/2 + 1個節點回應“是”，則成功獲得鎖；
l 客戶端獲得鎖以後可保留任意時間，不需要時自己釋放即可。釋放操作也會廣播給所有的節點，從而恢復鎖的可用狀態。寫鎖僅能被一個寫入者獲得。
設計目標
•要求設計簡單，因爲簡單的設計，可以避免程序中很多非常棘手的條件分支的支持。
•不存在主節點，因爲一旦在設計上引入主節點，那麼如果主節點宕機，整個鎖管理器機制即將失效，這對MinIO對象存儲系統影響非常嚴重，是不可接受的。
•系統必須是彈性的，即使存在多個失效的節點，只要它們的個數小於n/2, 整個鎖管理系統是可以正常工作的。
•完全可以替代Golang標準庫中的sync.RWMutex互斥鎖。這樣可以簡化MinIO對象存儲系統的編程。
•當失效節點重啓以後，其它節點重新連接。
不使用zookeeper/raft等技術的原因
zookeeper/raft功能豐富，而MinIO對象儲存的使用用例其實很有限。在MinIO中使用zookeeper/raft，會使整個系統增加不必要的複雜性。
優勢
•實際操作極其簡單，有效代碼不足一千行，易理解，易維護。
•超高的性能。詳細數據請參考文獻[12]
4 雲網關模式
MinIO存儲系統的後端可以是磁盤，也可以作爲雲網關，對接第三方的NAS系統、分佈式文件系統或公有云存儲資源，併爲業務系統轉換提供標準的對象訪問接口。
目前MinIO支持Google 雲存儲、HDFS、阿里巴巴OSS、亞馬遜S3, 微軟Azure Blob 存儲等第三方存儲資源。
03 元數據
1 架構
MinIO對象存儲系統無元數據數據庫，所有的操作都是對象級別的粒度的。這種做法的優勢是:
• 個別對象的失效，不會溢出爲更大級別的系統失效。
•便於實現“強一致性”這個特性。此特性對於機器學習與大數據處理非常重要。
2 管理
元數據與數據一起存放在磁盤上：數據部分糾刪分片以後存儲在磁盤上，元數據以明文形式存放在元數據文件裏（xl.json）。假定對象名字爲obj-with-metadata, 它所在的桶的名字是bucket_name, disk是該對象所在糾刪組的任一個磁盤的路徑，如下目錄：
disk/bucket_name/obj-with-metadata
記錄了這個對象在此磁盤上的信息。其中的內容如下：
其中的xl.json即是此對象的元數據文件。part.1 即此對象的第一個數據分片。對象的元數據文件xl.json的內容是如下這種形式的json字符串：
字段說明
1 format字段
該字段指明瞭這個對象的格式是xl。MinIO內部存儲數據主要有兩種數據格式:xl與fs。使用如下命令啓動的MinIO使用的存儲格式是fs:
這種模式主要用於測試， 對象存儲很多API都是並沒有真正實現的樁函數。在生產環境所用的部署方式（本地分佈式集羣部署、聯盟模式部署、雲網關模式部署）中，存儲格式都是xl。
2 stat字段
記錄了此對象的狀態，包括大小與修改時間，如下圖：
3 erasure字段
這個字段記錄此對象與糾刪碼有關的信息，如下圖：
• 其中的algorithm指明瞭此對象採用的是Klaus Post實現的糾刪碼，生成矩陣是範德蒙矩陣。
• data，parity指明瞭糾刪組中數據盤、校驗盤的個數。
• blockSize 指明瞭對象被分塊的大小，默認是5M（請參見上一節“數據分佈與均衡”）。
•index指明瞭當前磁盤在糾刪組中的序號。
• distribution:每個糾刪組的數據盤、校驗盤的個數是固定的，但是不同的對象的分片寫入這個糾刪組的不同磁盤的順序是不同的。這裏記錄了分佈順序。
• checksum:它下面的字段個數跟此對象的分片數量有關。在舊版本的MinIO對象存儲系統，每一個分片經過hash函數計算出的checksum會記錄在元數據文件的這個位置。最新版的MinIO會把checksum直接計入分片文件（即part.1等文件）的前32個字節。
此字段之下algorithm的值是”highwayhash256S”表明checksum值是寫入分片文件的。
4 minio字段
這個字段記錄了存儲此對象的minio的版本。
5 meta字段
Content-type, etag兩個字段是MinIO對象存儲系統自動生成的。
用戶在使用Python等語言的寫作的訪問MinIO的程序中，如果上傳對象時候指定了幾個自定義屬性，比如：
author屬性值爲Zhangsan
Nation屬性值爲Cn
Type屬性值爲love
那麼對象元數據文件的meta字段就會出現如下幾個子字段：
X-Amz-Meta-Author
X-Amz-Meta-Nation
X-Amz-Meta-Type
6 parts字段
記錄各個分片的信息：
04 集羣擴展
1 擴展方式
MinIO支持聯盟部署模式，即將多個MinIO集羣組成一個統一命名空間（一個ETCD集羣，若干個CoreDNS服務）。其中ETCD集羣相當於整個對象存儲系統的配置數據庫，很多重要的信息，如桶IP地址等存儲於其中。這種模式的MinIO的架構如下圖：
聯盟模式多集羣部署
同樣，MinIO在擴展時也採用相同機制，而不是傳統分佈式存儲的添加節點方式。MinIO主要通過添加新的集羣來擴大整個系統，可用空間大幅增加且仍然保持統一命名空間。通過這種方式，MinIO對象存儲系統幾乎可以無限的擴展總體性能和容量。
2 統一域名訪問
MinIO集羣擴展加入新了集羣或桶後，對象存儲的客戶端程序需要通過統一域名/url（如bucket1.domain.com）來訪問數據對象，這個過程涉及到了CoreDNS系統。
CoreDNS實現單一域名/URL訪問
MinIO對象存儲的某個客戶端（比如mc），首先向某個MinIO服務發送創建桶的請求。MinIO服務把這個桶所在的MinIO集羣的外部網址（一般爲一個Nginx的IP地址，或者MinIO集羣的每一臺服務器的IP地址）,寫入到etcd集羣中。
假定域名爲domain.com,桶名爲buc-1，集羣的服務器IP地址爲192.168.1.108、192.168.1.109，那麼寫入etcd集羣的共有兩條數據.第一條數據的key，value二元組爲：
第二條數據的key，value二元組爲：
CoreDNS通過etcd系統獲知”bucket1.domain.com”這個url所對應的兩個IP地址爲192.168.1.108, 192.168.1.109。對象存儲的客戶端主機設置如上所配置的CoreDNS服務之後，客戶端程序就可以通過域名”bucket1.domain.com”來找到訪問這個桶。
3 優勢特性
單一的、超大的命名空間需要花費大量的創建、維護與停機時間，複雜的部署管理，進而帶來更嚴重的次生故障。MinIO的設計理念就是化整爲零，簡化集羣擴展，減小單個集羣的體量，輕量化單個集羣的運維，從而使得超大規模的存儲管理與維護變得更加容易。
• 集羣的節點完全對等，沒有主節點，多個節點可以併發提供對象訪問服務;
• 創建桶的時候，可以指定數據中心/地域，以匹配對應的業務訪問;
• 無論添加多少個集羣,原有集羣的性能幾乎是不變的;
• 集羣不會過大（32個節點），可實現可靠的分佈式鎖管理器，進而保證更新、刪除等操作的強一致性。傳統的架構允許集羣擴容到數百上千節點，此情況下的強一致性容易產生性能問題;
• 故障的影響範圍小，限制在單個集羣內部。
05 糾刪碼
在同一集羣內，MinIO會自動生成若干糾刪組，用於存放桶數據。一個糾刪組中的一定數量的磁盤發生的故障（故障磁盤的數量小於等於校驗盤的數量），通過糾刪碼算法可以恢復出正確的數據。MinIO集成了Reed-Solomon糾刪碼庫，MinIO存儲對象數據時，首先把它生成若干等長的片段（對於大對象，默認按5MB切片)，然後每一個片段會糾刪算法分成若干分片，包括數據分片與校驗分片，每個分片放置在一個糾刪組的某個節點上。對象的每一個數據分片、校驗分片都被“防比特位衰減”算法所保護。
對於一個對象，MinIO是如何定位它所在的糾刪組呢？
假定所有的糾刪組都有一個序號（從0開始，直至糾刪組個數減1）。MinIO會根據對象名（類似於文件系統的全路徑名)，使用crc32哈希算法計算出一個整數。然後使用這個整數除以糾刪組的個數，得到一個餘數。這個餘數，可以作爲糾刪組的序號，這樣就確定了這個對象所在的糾刪組。MinIO採用CRC32哈希算法，與GlusterFs的Davies-Meyer哈希算法（性能、衝突概率與md4, md5相近）不一樣的是， CRC32算法的哈希值分佈較不均勻，但運算速度極快，高出md4數倍。相對於容量均衡，MinIO更看重數據的寫入速度。
06 數據修復
比特位衰減（Bitrot）是指存在存儲介質中的數據發生了緩慢的變化，如向存儲介質寫入一段比特流，一段時間後再讀出來，二者並不一致。比特位衰減的原因大致有：磁記錄磨損、磁盤幻象寫(phantom writes)、磁盤指向錯誤(misdirectedreads/writes)、宇宙射線的輻射等。MinIO對象存儲系統從設計之初即考慮到修復靜默錯誤，從被修復的目標來說，按照大小可以分爲以下三種類型的修復：某個對象、某個桶、整個集羣。
在控制檯上執行mc命令即開始進行數據修復。該命令一方面向minio發送數據修復的HTTP請求，另一方面不斷地接收minio服務進程返回的修復進度信息，而後輸出到控制檯，直到修復工作完畢。
如前文所述，每個對象都被分成多個分片，然後存儲於多臺主機的磁盤上。數據修復可以分爲正常、深度兩種模式，正常模式下只是簡單地檢查分片狀態信息，深度模式下會使用hash算法來校驗分片的內容，找出比特位錯誤，同時也更耗費資源。
MinIO具體修復流程如下：
• mc命令作爲MinIO對象存儲的客戶端軟件、管理工具，它內部鏈接了minio軟件（代碼網址：https://github.com/minio/minio/）的madmin軟件模塊，通過調用madmin中的修復函數，mc包裝了mc命令的命令行參數，然後向minio服務進程發送HTTP消息。
•mc發送一個修復請求，在minio中被類healSequence所描述。每一個healSequence可以啓動、停止、查詢狀態。minio服務程序收到新的任務的時候，會檢查是否跟原有的healSequence有重疊的任務，如果有重疊，則啓動的修復任務失敗。如果minio服務沒有發現錯誤，則使用深度優先搜索的算法，按照磁盤元數據信息、桶、對象的順序，不斷地給後臺修復線程推送任務。
•minio後臺修復線程修復對象的流程算法：對於對象的每一個block（默認大小爲5M），從糾刪組的各個主機讀取各個分片，如果有錯誤的分片，就需要修復，有兩種可能：校驗分片錯誤——minio使用各個數據分片重新計算缺失的校驗片。數據分片錯誤——使用糾刪算法恢復數據（需要計算逆矩陣）。
07 lambda計算
MinIO對象存儲軟件支持lambda計算通知機制，即桶中的對象支持事件通知機制。MinIO當前支持的事件類型有：對象上傳、對象下載、對象刪除、對象複製等。MinIO對象存儲軟件當前支持的事件接受系統有：Redis,NATS, AMQP, MQTT,Apache Kafka, MySql, PostgreSQL, Elasticsearch等。
對象通知機制，極大地增強了MinIO對象存儲的擴展性，可以讓用戶通過自行開發來實現某些MinIO對象存儲不便實現的功能，比如基於元數據進行的各種檢索、各種跟用戶的業務有關的計算。既方便了用戶，又有助於MinIO對象存儲的生態建設。
對象通知機制，使用極爲簡單，用戶只需在MinIO進行少許配置即可。請參考文獻[15]。
08 持續備份
傳統的複製的一大問題是不能有效地擴展，很難超過幾百TB。在當今的時代，爲了支持災難恢復，任何單位都需要一個備份策略。而且這個備份策略需要跨越不同的地理位置、不同的數據中心、多種多樣的雲環境。
MinIO的持續備份是爲跨數據中心的大型部署而設計的。通過使用lambda計算通知機制，它可以快速、有效地計算處需要增量備份的內容，這遠比傳統的批處理模式優秀。持續備份使得未備份的數據儘可能的少，這意味着發生災難或者嚴重錯誤時候，丟失的數據儘可能的少，很好地保護了用戶的數據資產。
9 軟件模塊
MinIO對象存儲系統主要由以下軟件模塊部分組成：存儲服務器軟件minio，存儲客戶端軟件mc，多種語言的客戶端SDK。minio分爲上下兩層，上層負責minio的系統管理與對外接口，下層實現具體的邏輯。
1 cmd模塊
這是minio的上層，也就是源代碼中的cmd子目錄，參見： https://github.com/minio/minio/tree/master/cmd。這一部分主要負責minio的命令行參數解析、初始化系統、格式化磁盤、管理內嵌的web服務器、S3 API的解析與邏輯處理。
2 各個軟件包
這個是minio底層邏輯實現，也就是源代碼目錄中的pkg子目錄。其中一些軟件包（比如madmin）, 可被其它組織（或個人）在編寫輔助minio的軟件的時候所重複使用。
• madmin：使用這個軟件包可以自己使用Golang語言撰寫MinIO集羣的管理程序，比如獲取服務的狀態（磁盤、cpu等信息）、重啓某個機器服務、啓動修復某個桶的任務、重新配置系統、獲取剖析信息等等。
• S3 select：如果對象存儲系統中有很多超大型的對象，比如大小是幾個GB甚至幾個TB的對象。如果應用程序（比如spark分析程序），要把符合條件的若干個對象都讀過去，然後再做分析，會及其的慢，浪費很多帶寬(畢竟對象中可能只有很少的一部分是對某個分析程序有用的)。因此Amazon引入了S3 Select 的功能。通俗地說，就是把select 類型的sql語句在某個對象上執行，從對象中取出一部分內容返回給應用。MinIO提供了S3 Select 功能。相對於S3 Select, MinIO要求對象的內容必須是CSV、 JSON,或者 Parquet格式。S3Select API實現中使用的語法分析器是 Alec Thomas寫的如下項目：
https://github.com/alecthomas/participle
這個實現的分析算法是帶有棧的ll(k)分析算法。
三 性能測試
MinIO已經爲高性能做過高度優化，尤其是部分關鍵的算法已經使用SIMD指令對Intel(AVX2/AVX512)、Arm(NEON)的cpu做過特殊優化，主要包括：
1) 糾刪碼部分用到的伽羅瓦域的運算：加法、乘法、乘方等等；
2) 監測比特位衰減(bitrot)的哈希函數,如HighwayHash。
另外每一個MinIO集羣都是無中心的，其中的每一個節點都是對等的，從而在性能上，不會存在單點瓶頸，也不會有單點故障。
如下的硬件配置之下：Intel Skylake CPU, NVMe磁盤，以及Mellanox CX5 dual 100-GbE網卡。下圖是MinIO inc的測試結果：
四 設計討論
爲什麼MinIO單集羣不支持擴展？
•傳統的擴展方式的劣勢
通過增加節點來擴展單集羣，一般需要進行數據均衡，否則羣集內各存儲節點會因負載不均而出現新的瓶頸。除了數據均衡操作的時機這個問題以外，在均衡過程中一般需要從存儲使用率高的節點向使用率低的節點遷移數據。當集羣擴容之後，大量已經寫入的文件落點會出現改變，文件需要遷移到真實的落點。當存儲系統容量比較大時，則會發生大量的文件/對象進行遷移,遷移過程可能由於佔用大量資源而導致上層應用性能下降。而且當文件/對象遷移過程中，機器故障可能會導致一些意想不到的情況,尤其是有大量業務的時候。當然針對此類問題，Gluterfs之類的文件系統有一些比較複雜的處理辦法。
•使用場景
人工智能、大數據分析、視頻監控等典型使用場景中，對象存儲系統中存儲的數據往往寫入以後一般不再修改。如果現有MinIO集羣存儲空間使用完畢，重新添加新集羣，然後繼續寫入新集羣即可。MinIO對象存儲的客戶端應用，從業務層面自行決定那些對象存在於哪個集羣裏面，使用起來並不麻煩。
單集羣不可擴展，也就是說系統不需要處理擴展和數據均衡，不僅有效降低系統複雜性，而且可以使得系統部署規劃具有很好的可預測性。
對於海量對象存儲應用場景，數據通常具有典型的生命週期特徵，根據實際需求設計好單集羣規模，按聯合方式擴展，整個系統具有非常好的可維護性。
•MinIO方案的優勢
不支持對單個集羣進行擴展，MinIO對象存儲系統的這種設計，使得系統的很多模塊更加簡單（比如從一個對象轉換到它所在的糾刪組，只用簡單的哈希即可。）降低了整個系統出錯的概率，使得MinIO對象存儲系統更加可靠、穩定。
詳細的討論參見文獻[14]
MinIO是否有類似於GlusterFs 的translator類機制？
沒有，GlusterFs是使用c語言實現的，而c語言是比較低級的語言，本身沒有模塊機制。Golang語言自身有強大的模塊機制，所以也就不需要類似於translator之類的機制。
MinIO的糾刪碼機制，爲何沒有采用柯西矩陣？
就Reed-Solomon糾刪碼的生成矩陣來說，Klaus的糾刪碼庫裏面可以選擇柯西生成矩陣。不過當前MinIO軟件使用的仍然是範德蒙矩陣的Reed-Solomon糾刪算法。這是因爲:雖然柯西矩陣的生成相比範德蒙矩陣更快，不過MinIO編碼矩陣的生成是隻進行一次的操作（程序運行中，生成的這個矩陣會被保存起來）。使用柯西矩陣對數據的吞吐量並沒有什麼影響。
五 對象存儲產品選型討論
開源對象存儲軟件以MinIO,Ceph爲典型代表。爲幫助相關人員在選擇對象存儲系統之時選擇合適的產品，此處對二者的特點、特性做一定討論。
01 MinIO優勢
1 部署極其簡單
MinIO系統的服務程序僅有minio一個可執行文件，基本不依賴其它共享庫或者rpm/apt包。minio的配置項很少（大部分都是內核之類系統級的設置），甚至不配置也可以正常運行起來。百度、google、bing等搜索引擎上基本沒有關於MinIO部署問題的網頁，可見在實踐中，很少有使用者遇到這方面的問題。
相比之下，Ceph系統的模塊，相關的rpm、apt包衆多，配置項非常多，難以部署，難調優。某些Linux發行版的Ceph安裝包甚至有bug，需要使用者手動改動Ceph的python腳本，才能安裝完畢。
2 二次開發容易
MinIO對象存儲系統除了極少數代碼使用匯編實現以外，全部使用Golang語言實現。Ceph系統是使用業界聞名的難學難用的c++語言編寫的。Golang語言由於產生較晚，吸收了很多語言尤其是c++的教訓，語言特性比較現代化。相對而言，MinIO系統的維護、二次開發比較容易。
3 網管模式支持多種其他存儲
通過網關模式，MinIO對象存儲後端，可以對接各種現有的常見其它存儲類型，比如的NAS系統，微軟Azure Blob 存儲、Google 雲存儲、HDFS、阿里巴巴OSS、亞馬遜S3等，非常有利於企業複用現有資源，有利於企業低成本（硬件成本約等於零，部署MinIO對象存儲軟件即可）地從現有系統平滑升級到對象存儲。
02 Ceph優勢
•數據冗餘策略更加豐富
Ceph同時支持副本、糾刪碼，而MinIO只支持糾刪碼。對於個別的對於數據可靠性要求極高的單位，Ceph對象存儲更加合適。
•社區目前更成熟
03 其他對比
1 廠商支持
國內使用Ceph的廠商、基於Ceph進行自研的存儲廠商都比較多，在使用過程中遇到的問題（有些時候，甚至需要修改、增強乃至重新實現Ceph本身的功能），可以向相關廠商尋求支持。國際方面，Ceph早已被紅帽收購，而紅帽近期又被IBM收購。
MinIO開發與支持的廠商只有MinIO公司。由於架構比較先進，語言高級，MinIO本身的程序比較容易讀懂、修改。招聘Golang程序員來 維護MinIO所花費的成本，顯然低於招聘c++程序員來維護Ceph。
2 多語言客戶端SDK
二者均有常見編程語言的客戶端，比如：python, java等。MinIO對象存儲軟件的開發SDK另外支持純函數式的語言Haskell。
3 技術文檔
內部實現的文檔MinIO基本不存在。想要了解內部實現乃至參與開發的技術人員，只能到如下社區：
http://minio.slack.com/ ，與MinIO的開發人員直接交流，或者自己閱讀代碼。Ceph的各種實現文檔、算法說明文檔非常豐富。這方面Ceph要比MinIO成熟很多。
04 結論
由以上討論，可見作爲對象存儲軟件來說，MinIO， Ceph都非常優秀，各自有各自的優勢。準備使用對象存儲軟件的用戶，應該根據自己單位的需求、技術儲備等實際情況，選擇適當的軟件。
六 參考硬件
MinIO是符合軟件定義存儲SDS理念的，兼容主流X86服務器以及ARM/飛騰平臺，同時也可以移植到諸如申威（Alpha架構）和龍芯（Mips架構）等硬件平臺。
下面這些符合工業標準的、廣泛採用的服務器是經過MinIO inc.優化測試過的、MinIO對象存儲軟件表現優異的服務器：
參考文獻
1https://github.com/krishnasrinivas/wikinotes/wiki/minio-scaling
2https://docs.aws.amazon.com/zh_cn/AmazonS3/latest/dev/Welcome.html
3Klaus Post官網：https://klauspost.com/
4https://github.com/klauspost/reedsolomon
5https://developer.ibm.com/articles/cl-cloudstorage/
6https://github.com/minio/dsync
7https://github.com/minio/dsync/pull/22#issue-176751755
8https://github.com/minio/minio/blob/master/cmd/xl-sets.go
9https://min.io/resources/docs/MinIO-throughput-benchmarks-on-NVMe-SSD.pdf
10https://github.com/minio/minio/blob/master/cmd/admin-heal-ops.go
11https://github.com/klauspost/reedsolomon/blob/master/options.go
12https://github.com/minio/dsync
13https://min.io/resources/docs/CPG-MinIO-implementation-guide.pdf
14https://github.com/minio/minio/issues/7986
15https://docs.min.io/docs/minio-bucket-notification-guide.html
（TaoCloud團隊原創 《MinIO技術白皮書》微信公衆號版）