01
背景の解釈
1990年代に提案されたLog-Structured File System（LFS）の考え方とNANDフラッシュは完全に一致します。ログ構造ファイル システムの設計の背後にある主なアイデアは、メカニカル ディスクの優れたシーケンシャル書き込みパフォーマンスを利用して、悪質なランダム書き込みの問題を回避することでした。ログ構造ファイル システムには、機械式ハードディスクの時代には適用上の制限があり、ログ データの配置方法を採用すると、シーケンシャル リードのパフォーマンスが非常に低下するという問題がありました。したがって、ログ構造ファイルシステムは、大きなブロックのデータを読み書きする環境でのみ合理的になります。
NANDフラッシュメディアでは、機械式ハードディスクのようなランダムな読み書きの問題がないため、ログ構造化データ配置方式ではパフォーマンス上の問題が発生せず、「書き込み時の消去」による寿命や消耗の問題も解決できます。 NAND フラッシュのバランスの問題。
02
既存の問題
03
スキームの選択
書き込む前にログを書き込みます。ログには、書き込まれるデータを記録する REDO ログ、または書き込む前にデータを記録してから書き込む UNDO ログがあります。完全な削除ログを書き込みます。中断された場合は、各コピーのデータの一貫性を確保するために、元に戻すかやり直しが実行されます。Ceph の Unaligned IO は、UNDO ログを使用してデータベースに古いデータを記録することにより、RMW モードで更新されます。FASS では、logctl は REDO モードを使用して、LOG に書き込む必要があるデータを記録します。欠点は、2 回書き込む必要があり、書き込み増幅が深刻であることです。
Ceph の BlueStore はこのように実装されており、データが上書きされると、ディスク上の対応する場所にある既存のコンテンツを直接更新するのではなく、新しく書き込まれたコンテンツを保存するための新しいスペースが割り当てられます。新しい書き込みが完了すると、元のスペースが解放されます。したがって、RMWのもう一度読み出しの問題や上書きの問題は解決できます。ROW はランダム書き込みをシーケンシャル書き込みに変換できるため、特定の書き込みパフォーマンスを向上させることができます。ただし、ROW の元のブロックにはまだ一部の有効なコンテンツが保持されており、その範囲内での後続の操作には複数回の読み取りが必要であり、読み取りパフォーマンスに影響します。FASS もこの方法を使用する場合、チャンク スペース管理の粒度を 4K に変更し、メタデータの保存場所をデータ リストに変更する必要があります。
Log-Structuredは、ディスク領域全体をログボリュームとみなして書き込みを行うため、書き込み1回を削減できますが、実装が複雑になり、データ本来の連続性が崩れてしまうというデメリットがあります。
再書き込みがサポートされていない場合は、テープ全体に書き込む必要があります。ストライプ全体に十分でない場合は、ストライプも占有する必要があり、小さな IO ランダム書き込みスペースが大幅に無駄になります。たとえば、4K データ、16K のストライプ、ポジティブ ストライプ書き込みはスペースの 75% を無駄にします。小さなファイルを集約して大きなブロックに順次書き込む場合、基本的にスペースの無駄はありません。
04
分析する
上記の分析から、ディスク書き込み寿命と圧縮と重複排除のサポートを考慮しながら EC のランダム書き込みパフォーマンスが向上する場合、現時点では FASS の選択肢は Log-Structured のみになります。
Log-Structured は、ログ ボリューム設計のアイデアを提供し、書き込まれた IO をログの形式で最後に追加し、ランダム IO をシーケンシャル化し、ストリップ全体を大きなブロックでシーケンシャルに書き込みます。FASS プロジェクトでログ構造化ストレージを導入し、ログ構造化ストレージ ボリュームを提供し、書き込み増幅を削減し、ランダム書き込み IO パフォーマンスを向上させ、ディスク寿命を延長します。
05
ログ構造に基づいた設計
FASS 2.0 分散型オールフラッシュ ブロック ストレージ システムの実装は、ログ構造に基づいています。これは、HDD のようなマッピング方法を SSD のようなマッピング方法に変更します。これは、システムに分散型 SSD コントローラーを実装するのと同じです。
範囲サイズが固定されており、スペース管理が便利なため、現在のバージョンでは範囲レイヤーに Log-Structured が実装されています。主にWALとデータログで構成されます。
WAL (Write Ahead Log) 事前書き込みログは、データ操作の原子性と永続性を保証するために使用されます。ランダムな小さなブロック書き込み IO を大きなブロックの順次 (追加) 書き込み操作に集約します。データログはディスク上に置かれたデータですが、新しいデータが追記されるため古いデータが残り、古いデータのガベージコレクション（Garbage Collection、以下GC）が発生します。
WAL はコピー冗長戦略を採用しており、データ ログと同じ保護レベルを備えています。たとえば、データ ログが EC4+2 を使用する場合、WAL は 3 つのコピーを使用し、WAL はディスクへの書き込み後に上位アプリケーションに戻ることができます。
WAL で使用されるディスク レイアウトには次のものが含まれます。
-
wal ヘッダー: wal の全体的なメタデータ。ヘッダーの begin/end は、wal ペイロードの開始アドレスと終了アドレスを示します。
-
alloc ヘッダー: データのメタデータ + メタデータの割り当てられた記憶領域を管理します。wal ペイロードは異なるセグメントに分割され、セグメントの順序に従ってループバック配信が実行されます。
-
data&meta: 4K に従って分割されたデータとメタデータが含まれます。メタデータでは4Kデータが1iomdに対応しており、容量の増大を抑えるために複数データのメタデータをマージして書き込むことになります。メタには、off+size、crc、クロック (IO 順序を識別) などが含まれます。データとメタデータは 4K 単位で順次追記されて書き込まれ、メタデータは kv 形式でメモリにキャッシュされます。
データログは4KB単位でディスクに書き込まれ、メタデータはアドレスマッピング方式で保存され、4K単位でメモリにロードされ、一貫性を確保するためのポリシーに従ってマッピングキャッシュがディスクにダンプされます。キャッシュとディスク上のデータのデータを保存し、フラッシュ プロセスのデータの信頼性を確保するために addr_log が使用されます。データ ログの各セグメントは固定サイズです。
データ ログで使用されるディスク レイアウトには次のものが含まれます。
-
マップヘッダー: マップメタデータ。フラッシュおよび newloc の位置決めに使用されます。
-
addr map: マッピングテーブルの配置データ。4K 単位で、各 4K ページの LBA が含まれます。マッピング キャッシュはメモリにロードおよび保存され、ディスクは定期的に同期して配置されます。
-
addr log: wal flash が addrBulk 形式で保存されたときのログを記録します。
-
data alloc: データ ページの割り当てを管理するメタデータ。alloc ヘッダーには全体的な情報が記録されます。seg メタは割り当てメタデータを記録します。スペースは無視されます。
-
データログ：4K単位で保存されるデータ。
データログはGCをサポートしています。データ D1 が物理アドレス n に書き込まれ、次にデータ D2 がアドレス (n+1) に書き込まれ、その後 D1 のデータが D1' に更新されるとします。ただし、更新されたデータは上書きされず、アドレス ( n+2)、アドレス n を「無効」としてマークします。
このような操作を何度も繰り返すと、segment1 には多くの「有効」データと「無効」データが埋め込まれます。このセグメント 1 に再度書き込みたい場合は、すべての「有効な」データを別の空のスペース セグメント 2 にコピーしてから、セグメント 1 のスペースを再利用する必要があります。このような操作は GC (つまり、ガベージ コレクション) です。
GCではOP(Over-Provisioning)と呼ばれる空き領域を確保する必要がありますが、OPとデータログ領域の間に明確な境界はなく、データログと同じ領域が使用されます。また、スペースの使用状況に応じて、OP スペースのサイズを自動的に調整します。
06
FASS 2.0 IO プロセス
07
利点
