SBD: ローカルにファイルシステムがある

SBD: We Have a Filesystem at Home

Author

［画像: Daniel Botha］

Name

Daniel Botha

［画像: A weary bird cook beside a cool pasta robot］

Image by Annie Ruygt

自家製パスタを作る人々について、私はあまり好ましくないことを言わざるを得ません。ここでは、インフラストラクチャを構築する際の考え方として、それらを例に挙げます。一生懸命取り組めば取り組むほど、物事が良くなるというのは、不当に簡単な考え方です。しかし、インフラは 1 ドルのスパゲッティ袋のようなものです。うまく機能するシンプルなものであり（そして、キッチン隅の小麦粉を 1 週間かけてこすり落とす必要がないものです）。

Sprites の開発が始まったとき、それは新しい種類の製品のための新しい種類のインフラでした。そのため、パスタのセクションで適切なファイルシステムが見つからなかったとき、私たちは独自のファイルシステムを作成しました。それは巧妙でしたが、まさにその理由で気に入らなかったのです。この記事では、その代替となる Sprites Block Device (SBD) を紹介します。これは、棚から手に取るスパゲッティ袋のようなもので、気づく唯一の違いは、より優れた信頼性です。

It was always object storage

Sprites のストレージのコアとなる側面に関する私たちのスタンスは、v1 から変わっていません。Sprite のディスクのルートはオブジェクトストレージであり、Sprite が実行されているサーバー上の NVMe ではありません。これが、Sprite がスリープし、別のサーバーでウェイクアップしても、ファイルが置かれていた場所を見つけられる理由です。Sprite の永続的な状態は、多かれ少なかれ、バケット内の場所です。なぜそうしたのか、感情を込めて、長文で書きました。

オブジェクトストアの性質として、オブジェクトの一部を変更することはできません。1 バイトを変更するには、オブジェクト全体を置き換える必要があります。これは、ファイルの途中の数バイトを常に書き換える Linux プログラムとは文化的に合いません。その翻訳を処理する何者かが必要です。

ローンチ時、その何者かは JuiceFS の大幅に改造されたバージョンでした。標準の JuiceFS は、ストレージをバケット内のデータ（チャンクとして）と、どのチャンクがどのファイルを構成するかを示すメタデータ（マップ）に分割し、データベースに保存します。しかし、私たちはそのようには使用しませんでした。私たちのホットロッドバージョンは、書き換えられた SQLite メタデータバックエンドを実行し、Litestream で永続化されていました。それは 1 つのファイルのみを保存しました。100 GB のディスクイメージで、ループデバイスに ext4 がマウントされていました。Linux は通常の ext4 の操作を行いました。JuiceFS は単にイメージを保持していました。

それはうまく機能しました。Sprites はそれを使用して出荷され、多くの人々がそれを作成し、チェックポイントは高速でした。なぜなら、チェックポイントは主にメタデータを移動するだけだったからです。しかし、使用量が増えるにつれて、ひび割れが現れ始めました。

Manifests that lie

メタデータデータベースを持つファイルシステムには、分離不可能な 2 つのコンポーネントがあります。バケット内のチャンクと、それらのチャンクがどのように組み合わさってファイルになるかを説明するデータベースです。それらが一致すれば、ファイルがあります。一致しなければ、あなたは終わっています。

私たちが上に構築したすべてのレイヤーは、その配置を引き継ぎ、追加する必要がありました。JuiceFS でのチェックポイントは、ディスクイメージのコピーオンライトクローンだったので、メタデータデータベースはライブディスクだけでなく、すべてのチェックポイントのチャンクも追跡していました。2 番目の SQLite データベース checkpoints.db は、チェックポイント自体と、各チェックポイントにマウントするイメージファイルをリストしていました。

したがって、Sprite のディスクはチャンク、どのチャンクが各イメージを構成するかを示すメタデータデータベース、そしてどのイメージがどのチェックポイントであるかを示すチェックポイントデータベースで構成されていました。それぞれが個別に永続化されていたため、それぞれが正しい状態を保ちながら、他のものが間違っている可能性がありました。

What could go wrong?

実際の経験に基づいているかどうかは定かではない話ですが、ある日 Sprite が起動しなくなりました。JuiceFS はオブジェクトストレージにチャンクを要求していますが、404 が返ってきます。私たちは高速化するために、JuiceFS をライトバックモードで実行していました。まずメタデータにチャンクを記録し、後からバイトをアップロードします。この 2 つのステップの間にマシンがクラッシュした場合、メタデータは存在しないチャンクを指します。

そのため、上に存在する ext4 ファイルシステムは、チェックサムが失敗したディレクトリブロックを見つけ、読み取り専用になります。Sprite を新しいマシンに移動しても、JuiceFS のチェックポイントはクローンだったため、チェックポイントを復元しても役立ちません。それらは同じチャンクを共有していたため、すべてのチェックポイントで同じギャップが発生していました。

My agent ate my dogfood

このような問題の技術的な詳細よりも、その繊細な性質こそが、Fly.io の歴史上最も集中的なドッグフーディング期間をもたらしました。そして、エージェントのためにコンピューターをドッグフーディングするなら、エージェントに食べさせるべきです。

そこで私たちは、Sprite のフリートを書き込み、チェックポイント、スリープ、ウェイク、リストアへと繰り返し実行し、返ってくるすべてのバイトを検証するハーネスを構築しました。私たちはそれを約 5,000 サイクルの間、400 の JuiceFS Sprite に向けました。そのうちのゼロではない数が、チェックポイント機能を永久に失いました。さて…くそ。

しばらくの間、私たちはレシピを調査し続けました。より多くの調整、より多くの修復ツール、そして 3 つの台帳を一致させ続けるためのますます巧妙な方法がありました。しかし、修理キットが付いてくるスパゲッティは、どんなに調理しても、奇妙な後味を残すものです。

Just a disk

登場：Sprites Block Device (SBD)。これはバケットを受け取り、NBD 経由で Linux カーネルにブロックデバイスとして提示します。Sprite はそのデバイスを ext4 としてフォーマットし、マウントします。これは、任意の Linux ボックスにディスクをマウントするのと同じ方法です。

当たり前だ。

SBD の下では、メタデータはブロックと共にバケット内に存在するため、同期を保つための独立したデータベースは必要ありません。Sprite 内のデーモン sbd serve は、ローカルキャッシュからカーネルのブロック読み書きに応答し、ダーティブロックをバックグラウンドでオブジェクトストレージにアップロードし、バイトがビルから出たことを保証する必要があるときにフラッシュします。

Ext4 は依然として主要な作業を行います。私たちは、その下のすべてをはるかにシンプルにしました。1 つのデーモンと 1 つのバケットで、かつてはファイルシステム、データベース、ディスクイメージを同期させる必要がありました。

Dumber checkpoints are better checkpoints

チェックポイントは、エージェントのためのパディングルームとして設計されたインフラストラクチャにとって非常に重要です。JuiceFS の下では、チェックポイントはディスクイメージのコピーオンライトクローンであり、checkpoints.db に記録されていました。SBD の下では、チェックポイントはボリューム全体のブロックのスナップショットであり、バージョン番号が付いており、SBD 独自のチェックポイントカタログに記録されます。ああ…単一の真実の源泉からの、抑制されていない快適さ。

リストアも同様に標準的です。各チェックポイントは、それが属するボリュームのバージョンを知っているため、リストアはファイルシステムをアンマウントし、ボリュームをインプレースで巻き戻し、再びマウントします。再起動にかかるコストと同程度です。

もちろん、まだ問題が発生する可能性はあります。違いは、Sprite が、信頼できないディスクを抱えて続行するのではなく、停止してそれを通知するようになったことです。SBD は、オブジェクトストレージから読み戻した各ブロックを、書き込んだものと比較してチェックします。SBD 自体がクラッシュした場合、Sprite 全体が再起動します。なぜなら、クリーンな再起動が、信頼できるディスクに戻る唯一の方法だからです。

Mom’s spaghetti

継続的な熱心なドッグフーディング、境界線上の虐待的なテストハーネス、およびいくつかの先駆的なデザインパートナーからのインプットにより、SBD は自家製パスタファイルシステムよりも何桁も信頼性が高いことが証明されています。

したがって、SBD は今後 Sprites のファイルシステムとなります。Ext4、ブロックデバイス上、バケット上。あなたのファイルを追跡している唯一のものは、すべての Linux ボックスがすでに実行しているファイルシステムコードです。

10/6 より前に作成された Sprites をお持ちの場合は、これらの手順 を使用して移行できます。

前の投稿 ↓

Your Agent Speaks MCP. Give It a Computer.