經過一年的開發停滯 致力於容錯分散式檔案系統的新分支 и 最近發布了第二個候選版本 LizardFS 的開發公司所有者已經更換，管理層也發生了變化，開發人員也發生了變化。過去兩年來，該計畫與社區保持了距離，並未給予應有的關注，但新團隊打算恢復與社區的先前關係，並與其建立密切的互動。這個專案程式碼使用 C 和 C++ 編寫， 根據 GPLv3 許可。
蜥蜴 分散式叢集檔案系統，允許資料分佈在不同的伺服器上，但可以作為單一大分割區進行訪問，其處理方式與傳統磁碟分割區類似。使用 LizardFS 掛載的分割區支援 POSIX 檔案屬性、ACL、鎖、套接字、管道、裝置檔案、符號連結和硬連結。系統沒有單點故障，所有組件均冗餘。支援資料操作的並行化（多個客戶端可以同時存取檔案）。
為了確保容錯能力，資料被拆分成多個副本，並冗餘地分佈在不同節點上（在不同的節點上放置多個副本）。如果節點或儲存發生故障，系統仍能繼續運作而不會遺失訊息，並根據剩餘節點的情況自動重新分配資料。要擴展儲存空間，只需連接新節點即可，無需停止維護工作（系統本身會將部分資料複製到新伺服器，並根據新伺服器的情況平衡儲存空間）。您也可以透過相同的方法縮小叢集規模—只需關閉從叢集中移除的過時設備即可。
資料和元資料分開儲存。建議安裝兩台以主從模式運作的元資料伺服器，以及至少兩台資料儲存伺服器（chunkserver）。此外，可以使用日誌伺服器備份元數據，儲存元資料變更訊息，並在所有現有元資料伺服器損壞時進行還原。每個檔案被分割為區塊（chunk），最大大小為 64 MB。區塊根據所選的複製模式分佈在儲存伺服器中：標準（明確定義放置在不同節點上的副本數量，包括與各個目錄相關的副本數量——對於重要數據，可以增加副本數量，對於不重要數據，可以減少副本數量）、XOR（RAID5）和 EC（RAID6）。
此儲存可擴充至 PB 級。應用領域包括歸檔、儲存虛擬機器映像、多媒體資料、備份、用作 DRC（災難復原中心）以及高效能運算叢集的儲存。 LizardFS 能夠高速讀取任意大小的文件，在寫入大型和中型文件時，以及在沒有持續修改、密集處理開啟文件以及一次性操作大量小文件的情況下，LizardFS 均表現出色。
FS 功能還包括對快照的支持，快照可以反映文件在特定時間的狀態，以及內建的「文件籃」（文件不會立即刪除，可在一段時間內恢復）。可以透過 IP 位址或密碼限制對分區的存取（類似於 NFS）。此外，它還具有配額和服務品質管理機制，可讓您限制特定類別使用者的大小和頻寬。此外，還可以建立地理分佈的存儲，其各個分區位於不同的資料中心。
LizardFS 計畫成立於 2013 年，最初是一個分支 主要區別在於：它具有基於里德-所羅門糾錯碼的複製模式（類似於 raidzN）、擴展的存取控制清單 (ACL) 支援以及平台用戶端。 Windows此外，還進行了其他最佳化（例如，當客戶端和儲存伺服器組合在一起時，盡可能從當前節點提供資料區塊，並將元資料緩存在記憶體中），採用了更靈活的配置系統，支援搶佔式資料讀取、目錄配額和內部重構。
LizardFS 3.13.0 計劃於 3.13 月底發布。 LizardFS XNUMX 的主要創新之處在於使用共識演算法來確保容錯能力（在發生故障時切換主伺服器）。 （使用 uRaft 的專有實現，該實現之前已用於商業產品）。使用 uRaft 簡化了設定並減少了故障復原延遲，但需要至少三個工作節點，其中一個用於仲裁。
其他變更包括基於 FUSE3 子系統的新客戶端、錯誤更正問題的解決方案以及用 C 重寫的 nfs-ganesha 插件。 3.13.0-rc2 更新修復了幾個嚴重錯誤，這些錯誤導致 3.13 分支的先前測試版本無法使用（3.12 分支的修復程序尚未發布，從 3.12 升級到 3.13 仍然會導致資料完全遺失）。
2020年工作重點將放在發展
，一個全新重寫的 LizardFS 內核，據開發人員稱，與 3.12 分支相比，其性能將提升三倍。 Agama 將過渡到事件驅動架構，基於非同步 I/O 主要在用戶空間運行（以減少對核心緩存機制的依賴）。此外，還將提供支援自動效能調整的全新調試子系統和網路活動分析器。
LizardFS 用戶端將會增強，全面支援版本化寫入操作，這將提高故障復原的可靠性，解決不同客戶端同時存取相同資料時出現的問題，並顯著提升效能。此客戶端將遷移到在用戶空間運行的獨立網路子系統。基於 Agama 的 LizardFS 首個工作原型計畫於 2020 年第二季發布。同時，他們承諾將開發用於將 LizardFS 與 Kubernetes 平台整合的工具。
來源： opennet.ru
