Ceph オブジェクトストレージに基づく階層型ハイブリッドクラウドストレージソリューション

パブリッククラウドストレージサービスは簡単に拡張できます。ユーザーは、ストレージ容量のニーズに応じて、既存のストレージサービスの容量を簡単に拡張できます。そのため、ユーザーの観点から見ると、パブリッククラウドストレージサービスは最大容量という特徴を持っています。

無制限の容量: パブリッククラウドストレージサービスは簡単に拡張できます。ユーザーは、ストレージ容量のニーズに応じて、既存のストレージサービスの容量を簡単に拡張できます。そのため、ユーザーの観点から見ると、パブリッククラウドストレージサービスは容量無制限という特徴があります。
低コスト: パブリッククラウドストレージサービスは従量課金モデルを採用しており、実際の容量使用量に基づいた課金をサポートします。同時に、ストレージインフラストラクチャの要件がないため、コストが低いという利点があります。
パフォーマンスが低い: パブリックネットワーク経由でストレージサービスにアクセスする際のネットワークオーバーヘッド、クラウドサービスプロバイダーが使用する共通の共有ハードウェアリソース、および仮想化テクノロジを通じて提供されるサービスにより、パブリッククラウドストレージサービスのアクセスパフォーマンスはそれほど高くありません。
[[236436]]
セキュリティと制御性が不十分: 前述のように、パブリッククラウドでは、すべてのハードウェア、ソフトウェア、およびその他のサポートインフラストラクチャはクラウドサービスプロバイダーによって所有および管理され、すべての組織とテナントが同じハードウェア、ストレージデバイス、およびネットワークデバイスを共有します。したがって、データのセキュリティと制御性の観点から、パブリッククラウドストレージサービスは理想的な選択肢ではありません。

プライベートクラウドストレージ

高性能: プライベートネットワークや専用回線によってネットワークオーバーヘッドが低く抑えられ、ソフトウェアおよびハードウェアリソースの選択に優れた柔軟性があるため、プライベートクラウドストレージサービスはパブリッククラウドよりも優れたアクセスパフォーマンスを提供できます。
高いセキュリティと制御性: プライベートクラウドストレージサービスでは、ソフトウェアとハードウェアのリソースが他の組織やテナントと共有されず、サービスを完全にプライベートネットワーク内に構築できるため、より高いレベルの制御性とセキュリティを実現できます。
容量制限: プライベートクラウドストレージサービスの場合、すべてのリソースは自己所有であり、ストレージクラスターの拡張など、自己メンテナンスが必要です。したがって、容量の観点から見ると、ストレージクラスターを拡張するための明示的および暗黙的なコストは非常に高くなります。したがって、ユーザーの観点から見ると、プライベートクラウドストレージサービスは 100% の容量ではありません。
高コスト: 前述のように、プライベートクラウドストレージサービスでは、データセンターの構築と運用、プライベートネットワークや専用ネットワークの構築、クラスターのメンテナンスなど、すべてのソフトウェアおよびハードウェアリソースコスト、ストレージクラスターの運用と保守のコストをすべてプライベートクラウドストレージサービスのコストに含める必要があります。また、オンデマンドで容量を割り当てて必要な分だけ利用できるパブリッククラウドストレージとは異なり、プライベートクラウドストレージでは、将来予測される最大容量需要を満たし、頻繁な容量拡張による高額な運用・保守コストを回避するために、クラスターを構築する際には計画的な容量で構築されることが多いです。これにより、実際にはストレージクラスター全体の使用容量が長時間にわたって不飽和状態になり、一部のストレージリソースが長時間にわたってアイドル状態になります。上記の 2 つの側面により、プライベートクラウドストレージはパブリッククラウドストレージよりも高価になるという問題が生じます。

ハイブリッドクラウドストレージ

ハイブリッドクラウドストレージは、プライベートクラウドストレージとパブリッククラウドストレージを接続し、これら 2 つを組み合わせて外部に共同でストレージサービスを提供します。プライベートクラウドストレージとパブリッククラウドストレージの利点をすべて統合したものと言えます。

高パフォーマンス: アクティブデータはプライベートクラウドストレージに保存され、アーカイブデータはパブリッククラウドストレージに保存されます。まず、パフォーマンスの観点から、アクティブデータと頻繁にアクセスされるデータをプライベートクラウドストレージに保存することで、ハイブリッドクラウドストレージはより高いアクセスパフォーマンスを提供できます。
高いセキュリティと制御性: ハイブリッドクラウドストレージのプライベートクラウド部分のソフトウェアとハードウェアリソースは自社所有かつ排他的であるため、重要な機密データ情報をプライベートクラウドストレージに保存すると、より高い制御性とセキュリティを実現できます。
無制限の容量: パブリッククラウドストレージとの相互接続により、ハイブリッドクラウドストレージは、パブリッククラウドストレージの無制限の容量という特性を活用して、無制限の容量という特性も備えています。
比較的低コスト: アーカイブされたデータ、アクセス頻度の低いデータ、アクセスパフォーマンス要件が低いデータをパブリッククラウドストレージに保存することを選択できます。プライベートクラウドストレージのコストを節約しながら、パブリッククラウドストレージをオンデマンドで割り当てるというコスト上の利点も得られます。そのため、ハイブリッドクラウドストレージには、プライベートクラウドストレージに比べてコストが低いという利点もあります。

既存のソリューションの限界

パブリッククラウドストレージやプライベートクラウドストレージと比較すると、ハイブリッドクラウドストレージはより包括的で完全です。 Ceph のオブジェクトストレージは、ハイブリッドクラウドシナリオ向けのソリューション、つまり Cloud Sync 機能も提供します。 Ceph RGW の Cloud Sync 機能は、RGW マルチサイトメカニズムに基づいて実装されています。まず、RGW マルチサイトメカニズムを見てみましょう。

RGW マルチサイト

Ceph RGW のマルチサイトメカニズムは、複数の Ceph オブジェクトストレージクラスター間でデータを同期するために使用されます。関連する中核概念は次のとおりです。

ゾーン: RGW のグループによって外部サービスが提供される独立したクラスターに対応します。
ゾーングループ: 名前が示すように、各ゾーングループは複数のゾーンに対応でき、データとメタデータはゾーン間で同期されます。
レルム: 各レルムは、複数のゾーングループを含めることができる独立した名前空間です。メタデータはゾーングループ間で同期されます。

マルチサイトの仕組みは次のとおりです。

Multisite はゾーンレベルの機能処理メカニズムであるため、デフォルトではゾーンレベルのデータ同期になります。つまり、Multisite を構成すると、ゾーン全体のデータが同期されます。

ゾーン全体のレベルでのデータ同期は操作の粒度が粗すぎるため、多くのシナリオには適用できません。現在、Ceph RGW は、より細かい操作粒度と高い柔軟性を備えた、bucket syncenable/disable によるバケットレベルのデータ同期の有効化/無効化もサポートしています。

RGWクラウド同期

Cloud Sync は RGW マルチサイトに基づいて実装されており、Ceph 内のオブジェクトデータを S3 インターフェイスをサポートするパブリッククラウドストレージに同期することをサポートします。デフォルトはゾーンレベルのデータ同期です。上記の紹介から、RGW のマルチサイトメカニズムは、複数の Ceph オブジェクトストレージクラスターと複数のデータセンター間のデータ同期を実現するために使用されていることがわかります。ゾーン自体は抽象的な概念です。より抽象的な観点から見ると、単なる Ceph オブジェクトストレージクラスター以上のものを表すことができます。

RGW Cloud Sync機能はこの考えに基づいて実装されています。 Cloud Sync フレームワークでは、スレーブゾーンは Ceph オブジェクトストレージクラスターだけに対応するのではなく、より抽象的な概念になっています。つまり、任意のクラスターを表すことができ、このクラスターは Ceph オブジェクトストレージクラスターにすることも、もちろん AWS の S3 にすることもできます。 Cloud Sync 機能は、S3 インターフェースをサポートするストレージクラスターをスレーブゾーンの概念に抽象化し、Multisite メカニズムを通じて Ceph 内のオブジェクトデータを外部オブジェクトストレージに同期します。

バケット同期の有効化/無効化を通じて、バケットレベルのデータ同期を有効化/無効化できます。

クラウド同期の制限

Ceph オブジェクトストレージを使用する場合、RGW の Cloud Sync 機能は、基本的にハイブリッドクラウドストレージのアプリケーションシナリオを満たすことができます。ただし、RGW Cloud Sync 機能の現在の実装に関しては、次のような制限が残っています。

サポートされる最も細かい同期粒度はバケットレベルです。一部のアプリケーションシナリオでは、バケットレベルでの同期の粒度が十分に柔軟ではありません。時間制御に関しては、RGW Multisite のデータ同期処理は、RGW 独自のコルーチンライブラリを通じて実装されます。処理プロセス全体は非同期で完了し、データ同期処理の開始時間を手動で制御することはできません。したがって、このデータ同期処理の時間制御は柔軟性が十分ではなく、時間に敏感なシナリオには適用できません。

UMStor、Ceph をベースにした階層型ハイブリッドクラウドストレージソリューション

上記の制限を踏まえて、より柔軟なデータ管理および移行ソリューションを提供するために、より細かい管理粒度とより優れた時間制御を備えたメカニズムを実装できるかどうかを検討し始めました。オブジェクトデータストレージの階層化、オブジェクトのライフサイクル管理、自動生成と移行などの一連の実践を通じて、Ceph ベースの階層型ハイブリッドクラウドストレージソリューション UMStor を開発しました。

ソリューション1: オブジェクトデータストレージのアップグレード

まず、オブジェクトデータのストレージを分類するために、Ceph オブジェクトストレージでストレージクラスを実装する方法を紹介します。

ストレージシステムのサイジング

ストレージシステムを分類する必要があるのはなぜですか?以下の3つの側面から考えることができると思います。

1. ストレージメディア

まず、ストレージクラスターでは、アクセス性能やコストなどの考慮により、SSDとHDDの両方を導入する場合があります。この場合、ストレージ階層化が行われないと、アクセス性能要件が低いデータやアーカイブされたデータは SSD に保存され、アクセス性能要件が高いデータは HDD に保存されることになり、データアクセス性能に影響を与え、データ保存コストが増加してしまうことは間違いありません。

2. ストレージ戦略

インスタンス
インスタンス
消去コード

一部のデータには非常に高い信頼性が求められるため、3 つのコピーの形式で保存します。一部のデータについては、信頼性に対する要件がそれほど高くない場合があります。この場合、ストレージスペースを節約するために 2 つのコピーを保存することをお勧めします。

3. ストレージプロバイダー

ユークラウド
AWS の

したがって、ストレージシステムでストレージグレーディングを実行することが実際には非常に重要です。

RGWデータ保存ルール

RGW 自体には、データの保存ルールである配置ルールの概念があります。配置ルールでは、バケットインデックスデータを格納するインデックスプール、オブジェクトデータを格納するデータプール、および Multipart 経由で大きなファイルをアップロードするときに一時データを格納するデータエクストラプールを定義できます。

配置ルールは使用されるストレージプールに対して定義され、ストレージプールはゾーン下の概念であるため、配置ルールは RGW でゾーンレベルの構成として使用され、その影響の粒度はバケットレベルです。つまり、バケットが使用する配置ルールを指定でき、バケットにアップロードされたすべてのオブジェクトデータは、バケットの配置ルールで定義された配置ルールに従って保存されます。ユーザーは、異なるバケットに異なる配置ルールを構成して、異なるストレージメディアの異なるバケットにオブジェクトデータを保存したり、異なるストレージポリシーを使用したりすることができます。

ただし、バケットレベルのデータストレージルールは、特定のアプリケーションシナリオのニーズを満たすほど柔軟ではありません。

オブジェクトデータストレージ戦略

ストレージクラスの概念自体は、AWS S3 の重要な機能です。 S3 では、各オブジェクトにはオブジェクトのデータのストレージポリシーを定義する「ストレージクラス」属性があります。 S3 のストレージクラス機能は、次の定義済みストレージポリシーをサポートしています。

STANDARD は頻繁にアクセスされるデータ用です。
STANDARD_IA は、アクセス頻度は低いが、必要なときに高速アクセスが必要なデータに使用されます。
ONEZONE_IA は、アクセス頻度は低いが、必要なときに高速アクセスが必要なデータに使用されます。他の Amazon オブジェクトストレージクラスでは少なくとも 3 つのアベイラビリティーゾーン (AZ) にデータが保存されますが、S3 One Zone-IA では 1 つの AZ にデータが保存されます。
REDUCED_REDUNDANCY は主に、高いストレージ信頼性を必要としないデータに使用されます。データストレージのコピー数を減らすことで、ストレージコストを削減します。
氷河。

前述の分散ストレージシステムのストレージ分類の要求と、RGW が現在サポートしているデータ配置ルールメカニズムを組み合わせて、Ceph オブジェクトストレージにオブジェクトストレージクラスの概念を導入しました。

まず、ストレージプールの概念をより高いレベルに抽象化しました。現在の Ceph オブジェクトストレージのサポートに加えて、異なるストレージメディア (HDD/SSD) に応じてストレージプールを分割することもできます。異なるストレージポリシー (データ冗長性ポリシー) (2 倍のレプリケーション/ 3 倍のレプリケーション/ 消去コード) に従ってストレージプールを分割します。外部ストレージ（外部パブリッククラウドストレージおよびプライベートクラウドストレージを含む）をストレージプールに抽象化します。
RGW ゾーンの配置ルールの範囲は、オブジェクトレベルで機能するように細かく設定されており、オブジェクトレベルのストレージグレーディングを実現します。同じストレージバケット内でも、異なるオブジェクトデータを異なるストレージプールに保存できます。

ソリューション2: オブジェクトライフサイクル管理

オブジェクトレベルのストレージクラス機能を実装した後、データ移行時間の制御性をどのように実現するかを検討し始めました。以下で紹介するのはこれです。

AWS S3 オブジェクトライフサイクル管理

オブジェクトのライフサイクル管理も AWS S3 の非常に重要な機能です。バケットのライフサイクル管理ルールを設定することで、バケット内の特定のオブジェクトセットに対してライフサイクル管理を実行できます。現在、AWS S3 オブジェクトライフサイクル管理は以下をサポートしています。

移行処理、つまり、指定された時間間隔後または特定の時点で、バケット内の特定のオブジェクトセットを現在のストレージクラスから別の指定されたストレージクラスに移行することをサポートします。
有効期限削除処理では、指定された時間間隔後または特定の時点でバケット内の特定のオブジェクトセットをクリアすることがサポートされます。

RGW オブジェクトライフサイクル管理

現在、Ceph RGW オブジェクトストレージは、LC オブジェクトライフサイクル管理もサポートしています。ただし、RGW 自体はオブジェクトストレージクラス/配置ルールをサポートしていないため、オブジェクトライフサイクル管理は現在、有効期限切れアクションと削除処理のみをサポートしています。

完全なオブジェクトライフサイクル管理の実装

上記で実装したオブジェクトストレージクラスをベースに、RGWの既存のLC実装をベースにRGW LCの処理ロジックを拡張し、オブジェクトライフサイクル管理によるオブジェクトデータの他のストレージクラスへの移行をサポートするLC移行機能を実装しました。たとえば、SSD から HDD への移行、3 コピープールから 2 コピープールへの移行、コピープールから消去コードプールへの移行、Ceph クラスターから外部の Ufile パブリッククラウドストレージへの移行などをサポートし、完全なオブジェクトライフサイクル管理を実現します。標準の AWS S3 ObjectLifecycle Management 関連インターフェースをサポートします。

上記の紹介から、私たちが実装したストレージクラス機能は、外部ストレージをストレージクラスとして指定することをサポートしています。したがって、バケットの LC ルールを構成することによって、バケット内の特定のオブジェクトセットを UFile、S3 などの外部ストレージに移行することをサポートします。

RGW の Cloud Sync 機能と比較して、LC 移行ルールを設定して Ceph クラスター内のオブジェクトデータを外部のクラウドストレージに移行すると、次の利点があります。

1. 操作の粒度がより細かくなり、オブジェクト内でデータを直接操作できるようになります。

2. 時間制御可能。 LC ルールで操作が有効になる時間を設定および指定し、データ移行の時間を手動で制御できるため、時間の制御性が高まります。

これまでに、ゾーンレベルからバケットレベル、そしてオブジェクトレベルまで、Ceph オブジェクトストレージに基づく完全かつ完全な粒度データ移行処理メカニズムを実装しており、基本的にすべてのアプリケーションシナリオの共通ニーズをカバーできます。

ソリューション3: 移行戦略を自動的に生成する

バケットログ

バケットログは、特定のバケットに対する操作とアクセスを記録および追跡するために使用される機能です。バケットログ内の各ログレコードには、要求の開始者、バケット名、要求時刻、要求された操作、返されたステータスコードなど、対応するバケットへの操作アクセス要求の詳細が記録されます。

移行戦略を自動的に生成

バケットログの操作記録と設定可能なスケールパラメータに基づいて、バケット内のオブジェクトデータの人気度が分析され、分析結果に応じて移行戦略が自動的に生成され、オブジェクトデータが管理されます。このプロセスを要約した図を以下に示します。