分散ブロックストレージエンジンを設計するにはどうすればよいでしょうか?

この記事はシリーズの 2 番目であり、ストレージ エンジンの要件、考え方、設計に焦点を当てています。前回の記事は「SDS HCI シリーズ：分散ブロックストレージ研究開発のためのメタデータ サービスの設計方法」です。

[[246289]]

まず、データ ストレージ エンジン モジュールにどのような要件があるのか​​を見てみましょう。

まず第一に、それは間違いなくまだ信頼できるものです。弊社のお客様のアプリケーション シナリオのほとんどはコア アプリケーションであるため、データの信頼性は絶対に保証される必要があり、妥協の余地はありません。

2つ目はパフォーマンスです。現在、10G ネットワークと NVMe SSD を含む SSD はすでに非常に人気があります。ハードウェアが高速化するにつれて、パフォーマンスのボトルネックもハードウェアからソフトウェアへと移行します。特にストレージ エンジンの場合、パフォーマンスは非常に重要です。

絶対的なパフォーマンスを追求するだけでなく、効率性も追求したいと考えています。すべての CPU 命令が無駄にならないことを願っています。最小限の CPU 命令で IO 操作を完了するよう努めます。その理由は、ストレージ ハードウェア デバイスがますます高速化しており、現在最も高速なストレージでは、1 回のアクセスがわずか 10 ナノ秒で実現できるためです。ただし、プログラムにロックが追加され、コンテキスト スイッチが実行されると、数百ナノ秒が経過する可能性があります。効率的に実行しないと、現在の CPU では SSD のパフォーマンスを十分に活用できない可能性があります。 CPU を効率的に使用することに加えて、メモリ リソースとネットワーク帯域幅リソースも効率的に使用する必要があります。同時に、同じ容量の SSD の価格は HDD よりも依然として高いため、圧縮、重複排除などの技術を使用して、ディスク領域を可能な限り節約し、SSD の領域利用効率を向上させるように努めています。

***、これも非常に重要なポイントですが、ストレージ エンジンはデバッグしやすく、アップグレードしやすい必要があります。ソフトウェア エンジニアの場合、作業時間の 50% 以上がデバッグに費やされ、ストレージ ソフトウェア エンジニアの場合、この割合はさらに高くなる可能性があります。私たちは、問題が見つかった場合にすぐに特定して修正できるように、デバッグが非常に簡単なソフトウェア製品を作成したいと考えています。アップグレードについても同様です。ソフトウェアの反復がますます速くなっている現在、ソフトウェアを簡単にアップグレードして、ユーザーが新しいバージョンのソフトウェアをより早く使用し、新しいバージョンの機能とパフォーマンスの最適化を享受できるようにしたいと考えています。

次に具体的な実装を見てみましょう。ストレージ エンジンを実装する場合、多くの従来のストレージ ベンダーは、IO パス全体をカーネル スペースに実装することを選択することがよくあります。例えば、上の図では、上層はコアストレージエンジン、下層はファイルシステム、ブロックデバイス、およびドライバーです。ネットワーク スタックもカーネルに実装されているため、ストレージ エンジンをカーネルに配置すると、パフォーマンスが最適化され、コンテキスト スイッチが削減されます。

しかし、この実装には非常に深刻な問題が数多くあり、その第一はデバッグが難しいことです。カーネル開発を行ったことがある人なら、カーネル内のデバッグが非常に面倒な作業であることをご存知でしょう。また、開発言語はCのみで、他の言語は使用できません。

同時に、カーネル内での開発とアップグレードは非常に困難になります。アップグレードでは、バグ修正であれ、新機能の追加であれ、サーバー全体を再起動する必要がある場合があり、ストレージ システムに多大なコストがかかります。もう 1 つの非常に重要な要素は、障害領域が非常に大きいことです。カーネル内のモジュールに問題が発生すると、カーネル全体が汚染され、デッドロックやカーネルパニックが発生する可能性があります。通常、これを修正するにはサーバーを再起動する必要があります。

問題が非常に多いため、設計時にカーネル スペース アプローチを使用することは絶対に選択しません。私たちは、ストレージ エンジンをユーザー空間、つまりユーザー モードで実装することを選択しました。

ユーザー スペースの実装では、多くのプロジェクトが LSM ツリー データ構造上にストレージ エンジンを構築することを選択します。 LSM ツリーはファイル システム上で実行されます。カーネルと比較すると、ユーザー スペースはより柔軟性があり、さまざまな言語で使用できます。サーバーを再起動せずにプロセスを再起動するだけで済むため、アップグレードも簡単です。ユーザー スペースでの障害はサービス プロセス自体にのみ影響し、カーネルの動作には影響しません。しかし、この方法の問題点は、パフォーマンスが十分ではないことです。 IO は依然としてカーネルを通過する必要があるため、コンテキストの切り替えが発生し、この切り替えによってパフォーマンスのオーバーヘッドが発生します。

次に、LSM ツリーについて説明します。ここでは、LSM ツリーのデータ構造と実装については詳しく説明しません。一般に、LSM ツリーは多くのストレージ エンジンの中核となります。

LSM ツリーの利点は、実装が比較的簡単なことです。参照できるオープンソース実装は多数あります。また、小さなデータ ブロックの書き込みにも非常に最適化されています。小さなデータ ブロックを結合し、バッチで書き込みます。

ただし、LSM ツリーは万能薬ではありません。最大の問題は、データ構造に起因する「読み取り増幅」と「書き込み増幅」です。この問題はどの程度深刻でしょうか?この写真（編集者注：上の写真を参照）は、「読み取りおよび書き込み増幅」のテスト結果です。図からわかるように、1GB のデータを書き込むと、最終的には書き込まれたデータ量の 3 倍、つまり「書き込み増幅」が 3 倍になります。 100G が書き込まれる場合は 14 倍に拡大されます。つまり、100G のデータが書き込まれると、実際にはディスク上で 1.4TB の書き込みトラフィックが生成されます。 「読み取り増幅」はさらに深刻になり、このシナリオでは 300 倍以上に増幅されます。これは、ハードウェアの効率を向上したいという当初の希望に反します。

LSM ツリーにはさまざまな利点がありますが、深刻な「読み取り書き込み増幅」問題があるため、LSM ツリーをデータ ストレージ エンジンとして使用することはできません。 LSM Tree の優れたアイデアから学び、それを独自のニーズと組み合わせてストレージ エンジンを実装することができます。これには、データの割り当て、スペース管理、IO、その他のロジックが含まれます。

次に、この図にはファイル システムも存在することがわかります。このファイルシステムは、ブロックデバイス上のカーネルに実装されています。一般的なファイル システムには、ext4、xfs、btrfs などがあります。多くのストレージ エンジンもファイル システム上に実装されています。しかし、ファイルシステムが本当に必要かどうかを考える必要があります。

まず、ファイル システムによって提供される機能は、ストレージ エンジンの要件をはるかに超えています。例えば、ファイルシステムが提供する ACL 機能、属性機能、マルチレベルディレクトリツリー機能は、専用のストレージエンジンには必要ありません。これらの追加機能は、多くの場合、パフォーマンスのオーバーヘッド、特に一部のグローバル ロックを発生させ、パフォーマンスに重大な影響を及ぼします。

第二に、ほとんどのファイル システムは複数のディスクではなく単一のディスク用に設計されています。通常、ストレージ サーバーには 10 個以上のディスクが展開され、SSD、HDD、またはハイブリッド展開になる場合があります。

3 番目に、多くのファイル システムは非同期 IO をあまりサポートしていません。非同期 IO インターフェイスをサポートしていますが、実際の使用中にブロッキングが発生する場合があり、これもファイル システムにとっては非常に悪い状況です。

***もう 1 つの問題は、データとメタデータの一貫性を確保するために、ファイル システムにもジャーナリング設計が採用されることです。しかし、これらのジャーナリングによって書き込み増幅の問題も発生します。サーバーに複数のファイル システムがマウントされている場合、単一のファイル システムのジャーナリングでは、ファイル システム間でアトミック性を実現できません。

最終的に、ストレージ エンジンを設計する際には、ファイル システムと LSM ツリーを放棄し、不要な機能を削除して書き込み増幅を可能な限り回避し、理想的なストレージ エンジンを独自に作成することを選択しました。必要な機能をブロックデバイスに直接実装します。

Linux カーネルではブロック レイヤーは非常に薄いレイヤーであり、そこに実装されているアルゴリズムは非常に単純であるため、ブロック レイヤーを独自に実装するつもりはありませんでした。これらのアルゴリズムには調整可能なパラメータもあり、オフにすることもできるため、パフォーマンスのオーバーヘッドがそれほど大きくなりません。

左の写真は、ZBS の現在の実装です。しかし、このアプローチの最大の問題はパフォーマンスです。ブロック レイヤーとドライバーは両方ともカーネル空間で実行され、ユーザー空間のストレージ エンジンの IO はカーネル空間を通過するため、コンテキスト スイッチが発生します。今後は、右図に示すアプローチに移行し、SSD メーカーが提供するユーザー スペース ドライバーと PMD (Poll Mode Driver) エンジンを組み合わせて、より優れたパフォーマンスを実現します。

次に、ZBS のユーザー スペース ストレージ エンジンの具体的な実装を見てみましょう。

IO スケジューラは、上位層から IO 要求を受信し、それをトランザクションに組み込み、指定された IO ワーカーに送信する役割を担います。 IO ワーカーはこのトランザクションを実行する責任があります。ジャーナル モジュールは、トランザクションをディスクに永続化し、ジャーナルをリサイクルする役割を担います。パフォーマンス層と容量層は、それぞれディスク上の空き領域を管理し、対応するディスクにデータを保存する役割を担います。