Ceph オブジェクトストレージに基づくハイブリッドクラウドメカニズムの詳細な分析

1. 背景

クラウドコンピューティングの発展の勢いに乗って、Ceph が今日最も注目されているソフトウェア定義ストレージオープンソースプロジェクトになったことは間違いありません。下の図に示すように、同じ基盤プラットフォーム上で、ファイルストレージ、オブジェクトストレージ、ブロックストレージの 3 つのストレージインターフェイスを提供できます。この記事では主にオブジェクトストレージ、つまり radosgw に焦点を当てます。

Ceph をベースにすることで、優れたセキュリティ、高可用性、優れたスケーラビリティを備えたプライベートストレージプラットフォームを迅速かつ簡単に構築できます。プライベートストレージプラットフォームは、セキュリティ上の利点によりますます注目を集めていますが、多くの欠点もあります。たとえば、次のシナリオでは、多国籍企業が海外のローカルビジネスデータにアクセスする必要があります。この長距離データアクセス要件をどのようにサポートできるでしょうか?民営化された環境のみの場合、解決策は 2 つしかありません。

[[225085]]

地域をまたいでローカルデータセンターのデータに直接アクセスすると、アクセス待ち時間が長くなることは間違いありません。

海外にデータセンターを構築し、ローカルデータをリモートデータセンターに継続的に非同期的に複製する方法の欠点は、コストが高すぎることです。

このシナリオでは、単純なプライベートクラウドストレージプラットフォームでは上記の問題を適切に解決できません。ただし、ハイブリッドクラウドソリューションを採用することで、上記の要件をより適切に満たすことができます。上記の長距離データアクセスのシナリオでは、パブリッククラウドのリモートデータセンターノードをストレージポイントとして最大限に活用し、ローカルデータセンターのデータをパブリッククラウドに非同期的にコピーし、ターミナルを介してパブリッククラウドのデータに直接アクセスできます。この方法は、総合的なコストと速度の面で大きな利点があり、このような長距離データアクセスのニーズに適しています。

2. 開発状況:RGW Cloud Syncの開発履歴

Ceph オブジェクトストレージに基づくハイブリッドクラウドメカニズムは、Ceph エコシステムへの優れた補足となります。これに基づいて、コミュニティは Mimic バージョンで RGW Cloud Sync 機能をリリースします。この機能は、当初、テストで使用した Tencent Cloud COS など、S3 プロトコルをサポートするパブリッククラウドオブジェクトストレージプラットフォームへの RGW のデータのエクスポートをサポートします。 Mulsite の他のプラグインと同様に、RGW Cloud Sync 機能も、S3 プロトコルと互換性のある新しい同期プラグイン (現在は AWS Sync モジュールと呼ばれています) になっています。 RGW Cloud Sync 機能の全体的な開発履歴は次のとおりです。

Suseは、単純なアップロードのみをサポートする初期バージョンを提供しました。
Red Hat は、この初期バージョンで、マルチパートアップロード、削除などの完全なセマンティックサポートを実装しました。大きなファイルを同期する際のメモリ爆発の問題を考慮して、ストリーミングアップロードも実装されています。

Ceph コミュニティがバージョン M でリリースするパブリッククラウド同期機能について実際のフィールドテストを実施し、存在する問題に基づいてフィードバックと開発を提供しました。実際のテストでは、次の動作環境を構築しました。

クラウドゾーンには、読み取り専用ゾーンとして構成されたパブリッククラウド同期プラグインが含まれており、リージョン間でRgwゾーンに書き込まれたデータをTencent CloudパブリッククラウドオブジェクトストレージプラットフォームCOSに同期します。RGWからパブリッククラウドプラットフォームへのデータの同期とバックアップに成功し、さまざまなクラウドパスにデータをインポートするための自由なカスタマイズをサポートしています。同時に、同期プロセス中に発生するエラーや現在遅れているデータを迅速に監視できる同期ステータス表示機能も改善しました。

3. コアメカニクス

マルチサイト

RGW Cloud Sync 機能は、基本的には Multisite に基づく新しい同期プラグイン (aws 同期モジュール) です。まず、Multisite のコアメカニズムのいくつかを見てみましょう。 Multisite は、RGW でのリモートデータバックアップソリューションです。本質的には、これはログベースの非同期レプリケーション戦略です。次の図は、Multisite の概略図です。

Multisite の基本的な概念は次のとおりです。

ゾーン: 独立した Ceph クラスター内に存在し、バックエンドプールのグループに対応する rgw サービスのグループによって提供されます。
ゾーングループ: 少なくとも 1 つのゾーンを含み、ゾーン間でデータとメタデータを同期します。
レルム: 少なくとも 1 つのゾーングループを含む独立した名前空間。ゾーングループ間でメタデータが同期されます。

マルチサイトで機能するメカニズムのいくつか、つまりデータ同期、非同期フレームワーク、同期プラグインについて見てみましょう。データ同期セクションでは主にマルチサイトのデータ同期プロセスを分析し、非同期フレームワークセクションではマルチサイトのコルーチンフレームワークを紹介し、同期プラグインセクションではマルチサイトのいくつかの同期プラグインを紹介します。

データ同期

データ同期は、ゾーングループ内のデータをバックアップするために使用されます。ゾーンに書き込まれたデータは、最終的にゾーングループ内のすべてのゾーンに同期されます。完全なデータ同期プロセスには、次の 3 つのステップが含まれます。

初期化: リモートソースゾーンとローカルゾーン間のログシャードの対応を確立します。つまり、リモートデータログをローカルゾーンにマップします。後で、データログを使用して、更新する必要があるデータがあるかどうかを確認します。
完全同期マップの構築: リモートバケットのメタデータを取得し、マッピング関係を確立して、バケットの同期ステータスを記録します。マルチサイトを構成するときにソースゾーンにデータがない場合、この手順は直接スキップされます。
データ同期: オブジェクトデータの同期を開始し、RGW APIを介してソースゾーンのデータログを取得し、対応するバイログを使用してデータを同期します。

以下では、バケット内のデータの増分同期を使用して、データ同期の動作メカニズムを説明します。 RGW に精通している人は誰でも、バケットインスタンスには少なくとも 1 つのバケットシャードが含まれていることを知っているはずです。データ同期は、バケットシャード単位でデータを同期します。各バケットシャードには、対応するデータログシャードとバイログシャードがあります。

対応する関係が確立され、完全な同期が完了すると、ローカルゾーンはソースゾーンの各データログシャードに対応する sync_marker を記録します。その後、ローカルゾーンは sync_marker をリモートデータログの max_marker と定期的に比較します。まだ同期されていないデータがある場合、データログエントリは rgw を通じて消費されます。データログエントリには対応するバケットシャードが記録され、バケットシャードに対応するバイログを使用してデータを同期できます。下の図に示すように、リモートデータログは gw_data_chang_log_entry の形式でログを保存します。各データログエントリには rgw_data_change というフィールドが含まれており、rgw_data_change に含まれるキーフィールドはバケットシャードの名前であることがわかります。次に、対応するバイログシャードを見つけて、増分同期のためにバイログを消費します。実際、完全同期では sync_marker は開始されず、最初からデータログを直接消費してデータを同期します。

非同期フレームワーク

RGW で使用される非同期実行フレームワークは、boost::asio::coroutine ライブラリに基づいて開発されています。スタックレスコルーチンです。一般的なコルーチンテクノロジとは異なり、Async Framework は、コルーチンをサポートするために現在のスタック情報を保存する ucontext テクノロジを使用せず、マクロテクニックを使用して同様の効果を実現します。 reenter/yield/fork などのいくつかの疑似キーワード (マクロ) を通じてコルーチンを実装します。 RGWCoroutine は、RGW で定義されたコルーチンに関する抽象クラスです。これは boost::asio::coroutine のサブクラスでもあります。これはタスクフローを記述するために使用され、実装される暗黙的なステートマシンが含まれます。 RGWCoroutine は他の RGWCoroutine を呼び出したり、並列 RGWCoroutine を生成したりできます。

RGWCoroutine クラスには、RGWCoroutinesStack メンバーが含まれています。 call を使用して他の RGWCoroutines を呼び出すと、対応するタスクフローがスタックに格納されます。すべてのタスクフローが完了するまで、制御は呼び出し元に戻りません。ただし、新しい RGWCoroutine を生成すると、タスクフローを格納するための新しいタスクスタックが生成され、現在実行中のタスクフローがブロックされることはありません。コルーチンが非同期 IO 操作を実行する必要がある場合、コルーチンは自身をブロック済みとしてマークし、IO イベントがタスクマネージャーに登録されます。 IO が完了すると、タスクマネージャーは現在のスタックのロックを解除し、コルーチンの制御を復元します。次の図は、事前に決められた期間でリクエストハンドラーを実装するコルーチンの使用例を示しています。

同期プラグイン

上記のデータ同期プロセスは、ある Ceph ゾーンから別の Ceph ゾーンにデータを同期することです。プロセスを完全に抽象化して、データ同期をより一般的なものにし、さまざまな同期モジュールを追加して、さまざまな宛先へのデータ移行を実現できます。上位層でのデータログ消費のロジックは一貫しているため、上位層データが宛先に到達する最後のステップのみが異なります。したがって、さまざまな同期プラグインを実装するには、データの同期と削除の関連インターフェースを実装するだけで済みます。各プラグインは、RGW では同期モジュールと呼ばれます。現在、Ceph には次の 4 つの同期モジュールがあります。

rgw: デフォルトの同期モジュール。Ceph ゾーン間でデータを同期するために使用されます。
ログ: オブジェクトの拡張属性を取得して印刷するために使用されます
elasticsearch: 一部の検索リクエストをサポートするために、データメタデータをESに同期するために使用されます。
AWS: Mimic バージョンがリリースされました。RGW のデータを S3 プロトコル 4 をサポートするオブジェクトストレージプラットフォームにエクスポートするために使用されます。

RGWクラウド同期

ストリーミングプロセス

前述したように、Suse は RGW Cloud Sync の初期バージョンを提供しました。下の図に示すように、同期プロセスは論理的に 3 つのステップに分かれています。まず、リモートオブジェクトが HTTP 接続を介して AWS Sync モジュールに取得され、メモリにロードされます。次に、オブジェクトがクラウドに配置され、クラウドは配置結果を返します。

このプロセスは小さなファイルの場合は問題ありませんが、オブジェクトが大きい場合は、すべてをメモリにロードすると問題になります。そのため、Red Hat はこれに基づいてストリーミングプロセスをサポートしています。基本的に、パイプ CR と呼ばれる新しいコルーチンが使用されます。パイプラインのようなメカニズムを使用して、リモートオブジェクトの取得用とオブジェクトのアップロード用の 2 つの HTTP 接続を同時に維持します。これら 2 つのプロセスは並列に実行され、次の図に示すように、メモリの爆発を効果的に防ぐことができます。

マルチパートアップロード

マルチパートアップロードはストリーミングプロセスに基づいており、大きなファイルのマルチパートアップロードをサポートします。全体的なプロセスは次のとおりです。

JSON 設定

パブリッククラウドストレージ環境は比較的複雑であり、AWS Sync モジュールの使用をサポートするにはより複雑な構成が必要です。したがって、Red Hat はこのプラグインで JSON 設定をサポートしています。

他のプラグインと比較して、主に host_style、acl_mapping、target_path の 3 つの構成項目が追加されています。 Host_style はドメイン名を構成するための形式、acl_mapping は ACL 情報を構成するための同期方法、target_path は宛先の構成メタデータの保存ポイントです。次の図は実際の構成を示しています。これは、AWS ゾーンが設定され、パス形式のドメイン名形式が使用されていることを示します。 target_path は、rgw に、それが属するゾーングループの名前と user_id を追加し、その後にバケット名が続きます。最後に、クラウド内のオブジェクトのパスは、target_path とオブジェクト名を組み合わせたものになります。

5. RGW Cloud Syncのフォローアップ作業には、主に次の4つの項目が含まれます。