分散ストレージ Ceph の進化 · SOSP 2019

[[347277]]

「Read the Papers」は、コンピューターおよびソフトウェア エンジニアリングの分野の論文を分析する一連の記事です。このシリーズの各記事では、OSDI や SOSP などのトップカンファレンスの論文を読みます。ここでは詳細をすべて紹介することはできませんが、論文では重要な内容を抜粋して紹介します。関連する論文に非常に興味がある場合は、リンクをクリックして直接原文を読むことができます。

この記事では、2019 年の SOSP ジャーナルに掲載された論文「分散ストレージ バックエンドとして不適格なファイル システム: Ceph の 10 年間の進化から得られた教訓」[^1] を紹介しています。この論文では、分散ストレージ システム Ceph が過去 10 年間の進化の過程で遭遇したいくつかの問題について紹介しています。ファイル システム ユーザーとして、そこから多くの経験と教訓を学び、同様の問題に遭遇したときに同じ間違いを繰り返さないようにすることもできます。

図1 - Ceph

2004 年から今日まで、Ceph のストレージ バックエンドは、初期の B ツリー ベースの EBOFS から今日の BlueStore まで進化してきました。ストレージバックエンドは非常に成熟しました。新しいストレージ システムは、優れたパフォーマンスを提供するだけでなく、優れた互換性も備えています。この記事では、分散ストレージ Ceph のアーキテクチャと、その進化の過程で遭遇した課題について簡単に紹介します。

Ceph アーキテクチャ

分散ファイル システムは、複数の物理マシン上のストレージ領域を集約し、高帯域幅、並列 I/O、水平拡張、フォールト トレランス、強力な一貫性を備えた外部データ ストレージ システムに提供できます。分散システムによって設計が若干異なり、ストレージ リソースの管理に使用される物理マシン上のモジュールを表す用語も異なりますが、ストレージ バックエンドは一般に、物理マシン上のストレージ デバイスを直接管理するソフトウェア モジュールとして定義されます。 Ceph では、このモジュールはオブジェクト ストレージ デバイス (OSD) です。

図2 - Ceph アーキテクチャ

Ceph は上図に示すアーキテクチャを使用します。その中核となるのは、Reliable Autonomic Distributed Object Store (RADOS) です。これは、数万の OSD に水平に拡張でき、自己修復、自己管理、強力な一貫性を備えたレプリカ オブジェクト ストレージ サービスを提供します。

Ceph が提供する librados を使用して、RADOS に保存されているオブジェクトとオブジェクト コレクションを操作できます。このライブラリは、操作が簡単なトランザクション インターフェイスを提供し、その上に次のものを構築できます。

• RADOS Gateway (RGW): Amazon S3 に似たオブジェクト ストレージ。
• RADOS ブロック デバイス (RBD): Amazon EBS に似た仮想ブロック デバイス。
• CephFS: POSIX セマンティクスを提供する分散ファイルシステム。

RADOS 内のオブジェクトは論理パーティション、つまりプールに保存されます。オブジェクトはプール内で分割され、各分割単位は配置グループ (PG) と呼ばれます。配置グループ内のデータは、設定されたレプリカの数に応じて複数の OSD に同期されるため、単一の OSD に障害が発生した場合でもデータの正確性が保証されます。

RADOS クラスター内の各ノードは、ローカル ストレージ デバイスごとに独立した OSD デーモンを実行します。これらのプロセスは、librados からの要求を処理し、他の OSD ノードと連携して、データのコピー、移行、およびエラー回復を完了します。すべてのデータは、内部 ObjectStore インターフェースを通じてローカルに保存されます。互換性要件を満たすために、ハードウェア デバイスにさまざまなインターフェイスを実装できます。

進化の課題

他の分散ファイルシステムとは異なり、現在、Ceph のストレージバックエンド BlueStore はローカルファイルシステムをバイパスし、ローカルの raw デバイスを直接管理します。これは、Ceph チームの経験から、ローカル ファイル システム上にストレージ バックエンドを構築するのは非常に面倒なことであることが判明しているためです。

図3 - ストレージバックエンドの課題

1. 追加のオーバーヘッドなしでローカル ファイル システム上に直接トランザクション メカニズムを構築するのは非常に複雑です。
2. ローカル ファイル システムのメタデータのパフォーマンスは、分散ファイル システムのパフォーマンスに重大な影響を及ぼします。
3. 成熟したファイルシステムは非常に堅牢なインターフェースを持ち、新しいストレージ ハードウェアに適応することが困難です。

効率的な取引

トランザクションは、一連の操作を独立したアトミック ユニットにカプセル化することで、アプリケーション開発を簡素化できます。この一連の操作は、完全に実行されるか、まったく実行されないかのいずれかです。データベースについて多少の知識があるエンジニアであれば、トランザクションの 4 つの特性、つまり原子性、一貫性、独立性、永続性についてよく理解しているはずです。ここではそれらについて詳細には説明しません。

トランザクションはアプリケーション開発者の作業を大幅に簡素化し、負担を軽減することができますが、ローカル ファイル システム上で効率的なトランザクション メカニズムをサポートすることは非常に困難な作業です。この論文では、トランザクションを実装するための 3 つの方法を提案しています。

図4 - トランザクションを実装する3つの方法

1. ファイル システムの内部構造に基づくトランザクション メカニズム - 多くのファイル システムは内部でトランザクションを実装しているため、一部の内部複合操作をアトミックに実行できます。ただし、これらのトランザクション メカニズムは内部でのみ使用されるため、機能が非常に制限されているか、使用できない場合があり、ファイル システムの内部トランザクションを使用することは困難です。

2. ユーザー空間での論理書き込み先行ログ (WAL) の実装 — この実装は機能しますが、3 つの重大な問題があります。

• 低速の読み取り、変更、書き込み — WAL ベースのログ記録メカニズムは、各トランザクションに対して次の手順を実行します。トランザクションをシリアル化してログに書き込み、fsync を呼び出してトランザクションをコミットし、トランザクション操作をファイル システムにコミットします。この実装は、各トランザクションが実行前に前のトランザクションの結果を読み取る必要があるため、つまり 3 つのステップが完了するまで待機する必要があるため、非効率的です。
• 非べき等操作 - 一部のファイルに対する操作はべき等ではない可能性があり、エラー回復のためにログを再生するときにデータ エラーが発生したり、データが破損したりする可能性があります。
• 二重書き込み - すべてのデータは最初に WAL に書き込まれ、次にファイル システムに書き込まれます。同じデータを同時に 2 か所に書き込むと、ディスク帯域幅が半分に減少します。

3. トランザクション キー値データベースを使用する - メタデータは RocksDB に保存されますが、オブジェクトはファイル システムに保存されます。これは、ストレージにオブジェクトを書き込むには、オブジェクトをファイルに書き込み、メタデータを RocksDB に書き込み、fsync を 2 回呼び出す必要があり、一部のファイル システム (JFS) では、fsync ごとに高価な FLUSH CACHE が 2 回トリガーされるためです。これは、一貫性によってもたらされる大きな追加オーバーヘッドです。

高速メタデータ操作

ローカル ファイル システムでの非効率的なメタデータ操作は、分散ファイル システムに大きな影響を与えます。 Ceph で readdir 操作を使用して大きなファイル ディレクトリをトラバースすると、メタデータ操作が全体的なパフォーマンスに与える影響を体験できます。

RADOS クラスター内のオブジェクトは、ファイル名のハッシュに基づいて配置グループにマッピングされます。これらのオブジェクトも、トラバース時にハッシュ順序に従います。システム内で非常に長いオブジェクト名に遭遇した場合、ローカル ファイル システムのファイル名の長さ制限を突破するために拡張属性を使用する必要がある場合があります。これらのファイルを検索するときは、比較のために実際のファイル名を取得するために stat を呼び出す必要もあります。システムのトラバーサルが遅い問題を解決するために、次の階層構造を使用してファイル オブジェクトを保存します。

図 5 - フォルダとオブジェクト

ファイルを検索または走査するときは、まず適切なフォルダーを選択し、次にフォルダー内のオブジェクトを走査します。 stat 関数の呼び出しを減らすために、ストレージ バックエンドは各フォルダー内のファイルが可能な限り少なくなるようにする必要があります。フォルダ内のコンテンツが徐々に増えていくと、コンテンツを複数のフォルダに分割する必要もありますが、このコンテンツ分割プロセスには非常に時間がかかります。

分散ファイルシステムの動作はローカルファイルシステムに基づいており、ストレージハードウェアの急速な発展により分散ファイルシステムにさらなる課題がもたらされるため、新しいハードウェアデバイスをサポートします。ストレージ デバイスの容量とパフォーマンスを向上させるために、HDD および SSD プロバイダーは、ホスト管理の SMR および ZNS テクノロジーを導入して既存のハードウェアを改良してきました。これらの技術は分散ファイルシステムのパフォーマンスを向上させるために非常に重要であり、ストレージデバイス開発者も新しいハードウェアを開発しており、これによってもファイルシステムの適応コストが増加します。

要約すると、従来の分散ファイルシステム開発者は、通常、ローカルファイルシステムをストレージバックエンドとして使用し、ローカルファイルシステムに基づいてより一般的なファイルシステムを構築しようとします。ただし、基盤となるツールは完全に互換性がないため、プロジェクトは非常に複雑になります。これは、多くの開発者が、新しいファイル システムが成熟するまでに 10 年かかる可能性があると考えているためです。しかし、Ceph チームの経験に基づくと、成熟したストレージ バックエンドをゼロから開発するのにそれほど時間はかかりません。

著者の観点から見ると、Ceph の進化は実に合理的です。システムの構築を始めた当初は、既存のツールをできるだけ活用して作業負荷を軽減したいと考えていました。既存のツールが役に立たなくなった場合にのみ、複雑なシステムをゼロから構築することを検討する必要があります。もし Ceph がプロジェクト開始当初からストレージ バックエンドをゼロから構築していたら、Ceph は市場を占有して現在の地位を獲得することはできなかったかもしれません。

この記事はWeChatの公開アカウント「本当に論理がない」から転載したものです。下のQRコードからフォローできます。この記事を転載する場合は「There is No Logic」公式アカウントまでご連絡ください。