XNUMX年間の開発の停滞を経て フォールトトレラントな分散ファイル システムの新しいブランチに取り組んでいます и XNUMX番目のリリース候補。 最近 LizardFS を開発している会社の所有者が変わり、新しい経営陣が採用され、開発者が交代しました。 過去 XNUMX 年間、このプロジェクトはコミュニティから撤退し、十分な関心を払っていませんでしたが、新しいチームはコミュニティと以前の関係を復活させ、コミュニティと緊密な交流を確立する予定です。 プロジェクトのコードは C および C++ 言語で書かれており、 GPLv3ライセンスに基づいて。
リザードFS 分散クラスター ファイル システム。これにより、さまざまなサーバー間でデータを分散できますが、単一の大きなパーティションの形式でそれらのサーバーにアクセスでき、従来のディスク パーティションと同様の方法で操作できます。 LizardFS でマウントされたパーティションは、POSIX ファイル属性、ACL、ロック、ソケット、パイプ、デバイス ファイル、シンボリック リンク、およびハード リンクをサポートします。 システムには単一障害点がなく、すべてのコンポーネントが冗長化されています。 データ操作の並列化がサポートされています (複数のクライアントが同時にファイルにアクセスできます)。
フォールト トレランスを確保するために、データは複数のレプリカに分割され、冗長性を持って異なるノードに分散されます (複数のコピーが異なるノードに配置されます)。ノードまたはドライブに障害が発生しても、システムは情報を失うことなく動作を継続し、データを自動的に再分散します。残りのノードを考慮して。 ストレージを拡張するには、メンテナンスのために作業を停止することなく、新しいノードをストレージに接続するだけで十分です (システム自体がデータの一部を新しいサーバーに複製し、新しいサーバーを考慮してストレージのバランスをとります)。 クラスターのサイズを縮小するためにも同じことを行うことができます。システムから削除される古い機器を無効にするだけです。
データとメタデータは別々に保存されます。 運用にあたっては、マスター/スレーブ モードで動作する 64 台のメタデータ サーバーと、少なくとも 5 台のデータ ストレージ サーバー (チャンクサーバー) をインストールすることをお勧めします。 さらに、メタデータをバックアップするために、ログ サーバーを使用してメタデータの変更に関する情報を保存し、既存のすべてのメタデータ サーバーが損傷した場合に操作を復元できるようにすることができます。 各ファイルは最大 6 MB のブロック (チャンク) に分割されます。 ブロックは、選択したレプリケーション モードに従ってストレージ サーバー間で分散されます。 標準 (個々のディレクトリとの関係を含め、異なるノードに配置されるコピー数の明示的な決定 - 重要なデータの場合はコピー数を増やすことができ、重要なデータの場合はコピー数を増やすことができます)重要でないデータは削減されます）、XOR（RAIDXNUMX）、および EC（RAIDXNUMX）。
ストレージはペタバイトサイズまで拡張できます。 応用分野には、アーカイブ、仮想マシン イメージのストレージ、マルチメディア データ、バックアップ、DRC (災害復旧センター) としての使用、およびハイ パフォーマンス コンピューティング クラスターのストレージとしての使用が含まれます。 LizardFS は、あらゆるサイズのファイルに対して非常に高い読み取り速度を提供し、書き込み時には、継続的な変更がない場合、開いているファイルでの集中的な作業、および小さなファイルの束。
FS の機能の中で、特定の時点でのファイルの状態を反映するスナップショットのサポートと、「ごみ箱」の組み込み実装 (ファイルはすぐには削除されず、いつでも利用できる) の存在にも注目できます。しばらくは回復します）。 パーティションへのアクセスは、IP アドレスまたはパスワードによって制限できます (NFS と同様)。 特定のカテゴリのユーザーのサイズと帯域幅を制限できるクォータとサービス品質の管理メカニズムがあります。 セグメントが異なるデータセンターに配置される、地理的に分散されたストレージ施設を作成することが可能です。
LizardFS プロジェクトは 2013 年にフォークとして設立されました 、主に、リードソロモン誤り訂正コード (raidzN に類似) に基づくレプリケーション モードの存在、ACL サポートの拡張、Windows プラットフォーム用のクライアントの存在、追加の最適化 (たとえば、クライアントとストレージ サーバー、ブロックは可能であれば現在のノードとともに送信され、メタデータはメモリにキャッシュされます）、より柔軟な構成システム、データの先読み、ディレクトリ クォータ、および内部リワークのサポート。
LizardFS 3.13.0は3.13月末にリリースされる予定です。 LizardFS XNUMX の主な革新は、フォールト トレランスを確保するためのコンセンサス アルゴリズムの使用です (障害時のマスター サーバーの切り替え)。 (以前は商用製品で使用されていた uRaft の独自の実装を使用します)。 uRaft を使用すると構成が簡素化され、障害回復の遅延が軽減されますが、少なくとも XNUMX つの稼働ノードが必要で、そのうちの XNUMX つはクォーラムとして使用されます。
その他の変更点: FUSE3 サブシステムに基づく新しいクライアント、エラー修正の問題の解決、nfs-gansha プラグインが C 言語で書き直されました。 アップデート 3.13.0-rc2 では、3.13 ブランチの以前のテスト リリースを使用できなくしたいくつかの重大なバグが修正されています (3.12 ブランチの修正はまだ公開されておらず、3.12 から 3.13 へのアップデートでは依然として完全なデータ損失が発生しています)。
2020 年は開発に重点を置きます。
、完全に書き直された新しい LizardFS カーネルで、開発者によれば、ブランチ 3.12 と比較してパフォーマンスが XNUMX 倍向上します。 Agama は、非同期入出力ベースのイベント駆動型アーキテクチャに移行します。 、主にユーザー空間で動作します (カーネル キャッシュ メカニズムへの依存を減らすため)。 さらに、新しいデバッグ サブシステムと、パフォーマンス自動チューニングをサポートするネットワーク アクティビティ アナライザーも提供されます。
LizardFS クライアントは、バージョニング書き込み操作の完全なサポートを追加します。これにより、災害復旧の信頼性が向上し、異なるクライアントが同じデータへのアクセスを共有するときに発生する問題が解決され、パフォーマンスが大幅に向上します。 クライアントは、ユーザー空間で動作する独自のネットワーク サブシステムに転送されます。 Agama ベースの LizardFS の最初の実用的なプロトタイプは、2020 年の第 XNUMX 四半期に完成する予定です。 同時に、LizardFS を Kubernetes プラットフォームと統合するためのツールを実装すると約束しています。
出所： オープンネット.ru