撰寫本文的目的是幫助您選擇適合自己的解決方案,並了解 Gluster、Ceph 和 Vstorage (Virtuozzo) 等 SDS 之間的差異。
文本使用了更詳細地披露某些問題的文章鏈接,因此描述將盡可能簡短,使用要點,沒有不必要的廢話和介紹性信息,如果您願意,您可以在互聯網上獨立獲取這些信息。
事實上,當然,提出的主題需要文本的語氣,但在現代世界越來越多的人不喜歡閱讀很多))),所以你可以快速閱讀並做出選擇,如果有什麼不清楚,請點擊鏈接或谷歌不清楚的話))),而這篇文章就像這些深層主題的透明包裝,顯示填充物- 每個決定的主要關鍵點。
糊狀
讓我們從 Gluster 開始,它被超融合平台製造商積極使用,其基於開源的 SDS 適合虛擬環境,可以在 RedHat 網站的儲存部分找到,您可以從兩個 SDS 選項中進行選擇:Gluster 或 Ceph。
Gluster 由一堆翻譯器組成 - 執行分發檔案等所有工作的服務。 Brick 是一項為一個磁碟提供服務的服務,Volume 是將這些 Brick 結合在一起的磁碟區(池)。 接下來是使用 DHT(分散式雜湊表)功能將檔案分組的服務。 我們不會在描述中包含分片服務,因為下面的連結將描述與其相關的問題。
寫入時,整個檔案儲存在brick中,其副本同時寫入第二台伺服器上的brick。 接下來,第二個檔案將被寫入不同伺服器上的第二組兩個磚塊(或更多)。
如果檔案大小大致相同且磁碟區僅由一組組成,那麼一切都很好,但在其他情況下,描述中會出現以下問題:
- 群組中的空間利用不均勻,這取決於文件的大小,如果群組中沒有足夠的空間來寫入文件,您將收到錯誤,文件將不會被寫入,也不會重新分配到另一個群組;
- 寫一個文件時,IO只去一組,其餘的都是空閒的;
- 寫一個文件時無法取得整個卷的IO;
- 由於缺乏將資料分佈到區塊中,整體概念看起來效率較低,在區塊中更容易平衡和解決均勻分佈的問題,而不是像現在整個檔案進入區塊。
從官方描述來看
這些發現也與使用者體驗的描述有關
圖為寫入兩個檔案時的負載分佈,其中第一個檔案的副本分佈在前三台伺服器上,這三台伺服器合併為磁碟區0 組,第二個檔案的三個副本放置在三台伺服器的第二組卷1 上伺服器。 每台伺服器有一個磁碟。
一般的結論是,您可以使用 Gluster,但要了解效能和容錯能力會受到限制,這會在超融合解決方案的某些條件下產生困難,其中虛擬環境的運算負載也需要資源。
還有一些Gluster的性能指標是在一定條件下可以達到的,僅限於
頭孢
現在讓我們從架構描述中了解 Ceph
架構
從架構的描述來看,核心是CRUSH,透過它選擇儲存資料的位置。 接下來是 PG——這是最難理解的抽象(邏輯組)。 需要 PG 才能使 CRUSH 更加有效。 PG的主要目的是將物件分組,以減少資源消耗,提高效能和可擴展性。 直接單獨尋址物件而不將它們組合到 PG 中將非常昂貴。 OSD 是針對每個單獨磁碟的服務。
一個集群可以有一個或多個資料池,用於不同的目的和不同的設定。 池分為放置組。 置放群組儲存用戶端存取的物件。 這是邏輯等級結束、物理層級開始的地方,因為每個置放群組都分配有一個主磁碟和多個副本磁碟(具體數量取決於池複製因子)。 換句話說,在邏輯級別,物件儲存在特定的置放群組中,在物理級別 - 儲存在分配給它的磁碟上。 在這種情況下,磁碟可以物理上位於不同的節點,甚至位於不同的資料中心。
在這個方案中,歸置組看起來像是整個解決方案靈活性的必要級別,但同時,作為這個鏈條中的一個額外環節,這不自覺地意味著生產力的損失。 例如,在寫入資料時,系統需要將其分割為這些群組,然後在實體層面分為主磁碟和副本磁碟。 也就是說,雜湊函數在搜尋和插入物件時起作用,但有一個副作用 - 重建雜湊的成本非常高且受到限制(當新增或刪除磁碟時)。 另一個哈希問題是無法更改的明確固定的資料位置。 也就是說,如果不知何故磁碟負載增加,那麼系統沒有機會不寫入它(透過選擇另一個磁碟),雜湊函數迫使資料根據規則定位,無論多麼糟糕磁碟是這樣的,所以Ceph在重建PG時會消耗大量內存,以防自我修復或增加存儲。 結論是,Ceph 運作良好(儘管很慢),但前提是沒有擴展、緊急情況或更新。
當然,可以選擇透過快取和快取共享來提高效能,但這需要良好的硬件,並且仍然會有損失。 但總體而言,在生產力方面,Ceph 看起來比 Gluster 更有吸引力。 此外,在使用這些產品時,有必要考慮一個重要因素 - 這是高水準的能力、經驗和專業精神,特別是 Linux,因為正確部署、配置和支援一切非常重要,這給管理者帶來了更多的責任和負擔。
儲存空間
該架構看起來更有趣
儲存可以與 kvm-qemu 管理程式的服務共存,這些只是已找到緊湊的最佳元件層次結構的幾個服務:透過 FUSE 安裝的客戶端服務(已修改,非開源)、MDS 元資料服務(元數據服務),service Chunk服務資料塊,物理層面相當於一塊磁碟僅此而已。 當然,就速度而言,最好使用具有兩個副本的容錯方案,但如果您在SSD 驅動器上使用快取和日誌,則可以在SSD 驅動器上對容錯編碼(擦除編碼或raid6)進行適當的超頻。混合方案,甚至在全快閃記憶體上更好。 EC(擦除編碼)有一些缺點:當改變一個資料塊時,需要重新計算奇偶校驗量。 為了避免與此操作相關的損失,Ceph 以延遲的方式寫入EC,並且在某個請求期間可能會出現效能問題,例如,當需要讀取所有區塊時,以及在Virtuozzo Storage 的情況下,寫入更改的區塊使用「日誌結構檔案系統」方法進行,最大限度地減少奇偶校驗計算成本。 為了大致估計有和沒有 EC 的情況下加速工作的選項,有
儲存組件的簡單圖並不意味著這些組件不吸收
有一個方案可以比較Ceph和Virtuozzo儲存服務對硬體資源的消耗。
如果以前可以使用舊文章、使用其中最重要的行來比較 Gluster 和 Ceph,那麼使用 Virtuozzo 就更困難了。 關於該產品的文章並不多,資訊只能從以下文件中收集
我會嘗試幫助描述這個架構,所以文字會多一點,但是自己理解文檔需要花很多時間,而且現有的文檔只能透過修改表格來作為參考內容或按關鍵字搜尋。
讓我們考慮一下具有上述元件的混合硬體配置中的記錄過程:記錄開始轉到客戶端啟動它的節點(FUSE 安裝點服務),但元資料服務 (MDS) 主元件當然會轉到將客戶端直接導向到所需的chunk 服務(儲存服務CS 區塊),即MDS 不參與記錄過程,而只是將服務導向到所需的chunk。 總的來說,我們可以用往桶子裡倒水來錄音來比喻。 每個桶是一個 256MB 的資料塊。
即一個磁碟就是一定數量的這樣的桶,即磁碟體積除以256MB。 每個副本分佈到一個節點,第二個副本幾乎並行到另一個節點,等等...如果我們有三個副本,並且有SSD 磁碟用於緩存(用於讀取和寫入日誌),那麼寫入後將發生寫入確認將日誌寫入 SSD,並且 SSD 的並行重置將在 HDD 上繼續,就像在背景一樣。 如果有三個副本,則在第三個節點的 SSD 確認後才會提交記錄。 看起來三個 SSD 的寫入速度總和除以 XNUMX 就可以得到一個副本的寫入速度,但副本是並行寫入的,網路延遲速度通常比 SSD 更高,事實上,寫入效能將取決於網路。 在這方面,為了看到真實的IOPS,您需要透過以下方式正確載入整個Vstorage
上述SSD上的記錄日誌的工作原理是,只要資料進入其中,服務立即讀取該日誌並寫入HDD。 每個集群有多個元資料服務 (MDS),它們的數量由法定人數決定,法定人數根據 Paxos 演算法工作。 從客戶端的角度來看,FUSE掛載點是一個叢集儲存資料夾,對叢集中的所有節點同時可見,每個節點根據這個原理都有一個掛載的客戶端,因此這個儲存對於每個節點都是可用的。
對於任何上述方法的效能,在規劃和部署階段,正確配置網路非常重要,其中由於聚合和正確選擇的網路通道頻寬而存在平衡。 在聚合中,選擇正確的雜湊模式和幀大小非常重要。 與上述 SDS 也有很大的區別,這是與 Virtuozzo Storage 中的快速路徑技術的融合。 與其他開源解決方案不同,除了現代化的保險絲之外,它還顯著提高了 IOPS,並使您不受水平或垂直擴展的限制。 總的來說,與上面描述的架構相比,這個看起來更強大,但為了這種樂趣,當然需要購買許可證,這與 Ceph 和 Gluster 不同。
總而言之,我們可以強調三者中的佼佼者:Virtuozzo Storage 在架構的性能和可靠性方面排名第一,Ceph 排名第二,Gluster 排名第三。
選擇Virtuozzo Storage 的標準:它是一組最佳的架構組件,針對這種Fuse 方法進行了現代化改造,具有快速路徑、一組靈活的硬體配置、更少的資源消耗以及與計算共享的能力(計算/虛擬化),也就是說,它完全適合超融合解決方案,而他就是其中的一部分。 第二名是 Ceph,因為與 Gluster 相比,它是一種更有效率的架構,因為它在區塊中運行,並且具有更靈活的場景和在更大叢集中工作的能力。
計劃寫一篇 vSAN、Space Direct Storage、Vstorage 和 Nutanix Storage 的比較,在 HPE 和華為設備上測試 Vstorage,以及 Vstorage 與外部硬體儲存系統整合的場景,所以如果你喜歡這篇文章,那就很高興收到您的回饋,考慮到您的評論和願望,這可以增加新文章的動力。
來源: www.habr.com