クラウド オブジェクト ストレージ:OpenStack Swift および Ceph オブジェクト ゲートウェイ

完了

OpenStack Swift は、OpenStack クラウド プラットフォームに属するオブジェクト ストレージ サービスです。 Swift は、(Azure Blob Storage のように) バイナリ オブジェクトとやり取りをするための、REST ベースの HTTP インターフェイスをクライアントに提供します。 Swift は無料かつオープンソースであり、任意のコンピューターにインストールして構成することができます。これにより、パブリック クラウドとプライベート クラウドの両方にオブジェクト ストレージを効果的に提供できます。

Swift のデータ モデルと API

Swift data model.

図 11:Swift のデータ モデル

Swift では、ユーザーがアカウントにアクセスし、そのアカウントを使用してコンテナーを定義し、そのコンテナーを使用してオブジェクトを格納することができます。 例として、swift.mycloud.com で実行されている Swift サービスでアカウント 123456 を持つユーザーが、picture.jpg という名前のオブジェクトをコンテナー images に格納しているとします。 この例の場合、オブジェクトにアクセスするための完全なパスは次のようになります。

https://swift.mycloud.com/v1/123456/images/picture.jpg

Swift では、RESTful インターフェイスが使用されるため、GETPUTPOST のような標準の HTTP アクセス動詞が使用されます。 SWIFT API は S3 API をベースにモデル化されているので、API のメカニズムやサポートされる操作が似ています。 コマンドはステートレスであり、適用されるコンテキストによって影響を受けます。 コンテナーに対して GET コマンドを実行すると、そのコンテナーに格納されているすべてのオブジェクトが一覧表示されます。一方、オブジェクトに対して GET コマンドを実行すると、そのオブジェクトが返されます。 Swift 操作の完全な一覧については、API リファレンス (Swift API) を参照してください。 S3 と SWIFT については、100% の API 互換性があるわけではないことに注意する必要があります。 たとえば、請求や AWS リージョンに関連する S3 API 要求は、Swift ではレプリケートされません。

また、Swift では、(認証されていない、Swift サービスのパブリック アクセスとして) サービスにアクセスしようとしているユーザーの認証済みアクセスもサポートされていることに注意する必要があります。 Swift は、Keystone と呼ばれる OpenStack 独自の認証サービスに統合されています。

Swift のアーキテクチャ

Swift では、パフォーマンス、フォールト トレランス、信頼性、持続性を確保するために、多層アーキテクチャが使用されます。 他の分散データストアと同様、Swift ではフォールト トレランスのためにレプリケーションが使用されます。 Swift の API の説明で示されているように、Swift では、アカウント、コンテナー、およびオブジェクトに関する情報を保持する必要があります。 そのため、Swift では独立したプロセスを実行して、クラスター内の各レイヤーに関する情報が追跡されます。

Swift アーキテクチャの各種コンポーネントは次のとおりです。

Swift cluster architecture.

図 12:Swift クラスターのアーキテクチャ

プロキシ ノード:これらは、受信した API 要求を処理するフロントエンド サーバーです。 Swift クラスターでは、送られてくる要求の負荷に対する処理能力を高めるために、複数のプロキシ サーバーを使用することができます。 プロキシ サーバーは、要求の送信先となるダウンストリーム サーバーを決定します。 また、プロキシ サーバーは応答を調整し、エラーを処理します。

オブジェクト ノード:これらは、オブジェクトを格納または取得できる、実際のオブジェクト ストレージ デバイスです。

ゾーン:Swift では、可用性ゾーンを構成して、障害の境界を分離することができます。 データの各レプリカは、個別のゾーンに置かれます (可能な場合)。 ゾーンは、最小のレベルとして、単一のオブジェクト サーバーにすることもできますし、少数のオブジェクト サーバーのグループにすることもできます。 ゾーンは、サーバーとパーティションを編成するために使用されます。これによりシステムは、データやサービスの可用性を損なうことなく、1 つのゾーンにつき少なくとも 1 つの障害を許容できるようになります。

Swift でのデータ配置

リング:リングは、アカウント/コンテナー/オブジェクトの名前と、その物理的な場所との間のマッピングを表します。 ストレージ ポリシー (以下で説明します) に応じて、アカウント、コンテナー、および 1 つのオブジェクト リングに対し、個別のリングが存在します。 オブジェクト、コンテナー、またはアカウントに対して、他のコンポーネントが何らかの操作を実行する必要がある場合は、適切なリングとやり取りして、クラスター内での場所を特定する必要があります。 リングは、ゾーンオブジェクト サーバーパーティションレプリカを使用して、このマッピングを維持します。 リング内の各パーティションは、既定ではクラスター全体で 3 回レプリケートされ、パーティションの場所は、リングによって維持されるマッピング内に格納されます。 リングは、障害シナリオでのハンドオフに使用されるデバイスを決定する役割も担います。

パーティション:Swift は、コンシステント ハッシュ法を使用して、ゾーン内のどのオブジェクト ノードがどのオブジェクトを格納する必要があるかを判断します。 コンシステント ハッシュ法によるリングの各部分を、パーティションと呼びます。

ストレージ ポリシー:ストレージ ポリシーは、オブジェクト ストレージ プロバイダーが Swift 環境のサービス レベル、機能、および動作を差別化できるようにするための手段を提供します。 Swift で構成された各ストレージ ポリシーは、抽象名を使用してクライアントに公開されます。 システム内の各デバイスは、1 つ以上のストレージ ポリシーに割り当てられます。 これは、複数のオブジェクト リングを使用することによって実現されます。各ストレージ ポリシーには独立したオブジェクト リングがあり、そのリングには、特定の差別化を実装するハードウェアのサブセットが含まれる場合があります。 ストレージ ポリシーを使用することで、クラウド プロバイダーは、高度な SLA を契約しているクライアントに対して、SSD ベースの高速なオブジェクト アクセスを提供できる一方、異なる SLA を契約している別のクライアントに対しては、従来のディスクベースのストレージを提供することができます。

次に、Swift でのオブジェクト操作の実行方法について、例を見ていきましょう。 たとえば、あるクライアント要求が、特定のコンテナーへのオブジェクト PUT 要求で構成されているとします。 この要求は、まずプロキシ ノードによって受信されます。このノードが、最初に要求を認証し、適切なアクセスを保証します。 次に、プロキシ サーバーはオブジェクト名のハッシュを取得し、オブジェクト リングを使用して、データが保存されるべき 3 つのパーティションの場所 (ドライブ) をすべて検索します。 このプロセスでは、オブジェクト リングを使用して、3 つのデバイスの IP と、その他の情報が検索されます。

3 つすべてのパーティションの場所が特定されたら、プロキシ サーバーのプロセスによって各ストレージ ノードにオブジェクトが送信され、適切なパーティションに配置されます。 クォーラムに達した場合 (このケースで言うと、3 つ書き込みのうち少なくとも 2 つが正常に返された場合) は、プロキシ サーバーのプロセスによって、アップロードが成功したことがクライアントに通知されます。 このように、Swift ではクォーラム書き込みが一貫性メカニズムとして使用されます。 最後に、コンテナー レイヤーが非同期的に更新され、新しいオブジェクトが反映されます。

Swift の一貫性モデル

Swift は、最終的に一貫性のあるシステムになるように設計されています。 Swift のすべてのデータはゾーン間でレプリケートされ、オブジェクトもバージョン管理されます。 Swift では、レプリケーターと呼ばれる特別な用途のプロセスが実行されます。このプロセスは、アカウント、コンテナー、およびオブジェクトの状態を監視するものです。 新しいエンティティやエンティティの更新バージョンが検出されると、クラスターのレプリケーション ポリシーに従って、それらのデータが他のサーバーへと確実にレプリケートされます。

Swift では、オーディターと呼ばれる特別なプロセスも使用されます。これは、Swift クラスターに保存されているデータをスキャンして、それらが侵害されていないことを確認するものです。 オーディターは、各オブジェクトのチェックサムを計算して、それらが一致することを確認します。 不一致がある場合、そのオブジェクトは隔離領域に移動され、ストレージ管理者に調査依頼が通知されます。

Ceph オブジェクト ゲートウェイ

クラウド オブジェクト ストアについての説明を終える前に、Ceph オブジェクト ゲートウェイ (RADOSGW とも呼ばれます) についても説明しておく必要があります。 RADOSGW は、Ceph ストレージ クラスター (RADOS) の追加レイヤーで、RADOS に格納されているオブジェクトとやり取りするための RESTful HTTP インターフェイスを提供するものです。 Ceph オブジェクト ゲートウェイは、Amazon S3 と SWIFT API の両方をサポートし、アプリケーションをそのプラットフォームに移行できるようにするという点で、ユニークな機能を備えています。 RADOSGW は、Amazon S3 と Swift で使用されるデータ モデルをレプリケートし、両方のサービスと同様の機能を提供します。