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