OpenStackクラウドのオブジェクトの保存：SwiftとCephの比較

著者： ドミトリー・ウコフ

復習

多くの人は、オブジェクト指向のストレージと、iSCSIやFibreChannel（ストレージエリアネットワーク、SAN）に基づくブロックストレージを混同していますが、実際にはそれらの間に多くの違いがあります。 システムはSAN上のブロックデバイスのみを表示しますが（デバイス名の良い例は/ dev / sdb linux）、オブジェクトストアへのアクセスは専用のクライアントアプリケーション（box.comクライアントアプリケーションなど）を使用してのみ取得できます。

ブロックストレージはクラウドインフラストラクチャの重要な部分です。 主な使用方法は、仮想マシンのイメージの保存またはユーザーファイルの保存です（たとえば、さまざまな種類のバックアップ、ドキュメント、イメージ）。 オブジェクトストレージの主な利点は、スケーラビリティとデータの冗長性を確保しながら、エンタープライズレベルのストレージと比較して実装コストが非常に低いことです。 オブジェクトストレージを実装する最も一般的な方法は2つあります。 この記事では、OpenStackがインターフェースを提供する2つのメソッドを比較します。

Openstack swift

Swiftネットワークアーキテクチャ

OpenStack Object Storage （Swift）は、標準化されたサーバーのクラスターを使用するスケーラブルな分散バックアップオブジェクトストレージを提供します。 「分散」とは、各データがストレージノードのクラスター全体に複製されることを意味します。 レプリカの数は構成できますが、商用インフラストラクチャの場合は少なくとも3つ必要です。

Swiftのオブジェクトへのアクセスは、RESTインターフェースを介して行われます。 これらのオブジェクトは、必要に応じて保存、取得、更新できます。 オブジェクトストレージは、多数のサーバーに簡単に分散できます。

各オブジェクトへのアクセスパスは、3つの要素で構成されています。

/アカウント/コンテナ/オブジェクト

オブジェクトは、オブジェクトを識別する一意の名前です。 アカウントとコンテナは、オブジェクトをグループ化する方法を提供します。 アカウントとコンテナのネストはサポートされていません。

Swiftソフトウェアは、アカウント処理サーバー、コンテナー処理サーバー、ストレージ、レプリケーション、コンテナーおよびアカウント管理を実行するオブジェクト処理サーバーなどのコンポーネントで構成されています。 さらに、プロキシサーバーと呼ばれる別のマシンがユーザーにSwift APIを提供し、要求に応じてクライアントからクライアントにオブジェクトを転送します。

アカウント処理サーバーは、特定のアカウントのコンテナーリストを提供します。 コンテナ処理サーバーは、特定のコンテナ内のオブジェクトのリストを提供します。 オブジェクト処理サーバーは、完全なパスがある場合、オブジェクト自体を単に返すか保存します。

指輪

ユーザーデータは一連のコンピューターに分散されているため、ユーザーデータの場所を追跡することが重要です。 Swiftでは、これは「リング」と呼ばれる内部データ構造を使用して実現されます。 リングはすべてのSwiftクラスターノード（リポジトリとプロキシの両方）にあります。 このようにして、Swiftは、このメタデータリポジトリが参照メタデータへのアクセスのボトルネックになったときに、集中メタデータサーバーに依存する多くの分散ファイルシステムの問題を解決します。 リングは、中央のデータカードよりもクラスターへの参加をよく反映するため、単一のオブジェクトを保存または削除するためにリングストレージは必要ありません。 これはI / O操作にプラスの効果をもたらし、アクセス遅延を大幅に削減します。

アカウントデータベース、コンテナ、および個々のオブジェクトには個別のリングがありますが、すべてのリングは同じように機能します。 つまり、特定のアカウント、コンテナ、またはオブジェクト名について、リングはストレージノード上の物理的な場所に関する情報を返します。 技術的には、このアクションは順次ハッシュ法を使用して実行されます。 リングのアルゴリズムの詳細な説明は、 ブログとこのリンクにあります。

プロキシサーバー

プロキシサーバーは、パブリックAPIへのアクセスを提供し、ストレージエンティティへのリクエストを処理します。 リクエストごとに、プロキシサーバーは、リングを使用して、アカウント、コンテナ、オブジェクトの場所に関する情報を受け取ります。 場所を受信した後、サーバーは要求をルーティングします。 オブジェクトは、バッファリングのサポートなしでプロキシサーバーからクライアントに直接転送されます（より正確に言うと、名前に「proxy」が含まれていますが、「proxy」サーバーはhttpなどで「proxying」を実行しません）。

オブジェクト処理サーバー

これは、オブジェクトを保存、取得、削除できる単純なBLOB（ブロブストレージ）リポジトリです。 オブジェクトはストレージノードにバイナリファイルとして保存され、メタデータは拡張ファイル属性（xattrs）にあります。 そのため、オブジェクトサーバーファイルシステムはファイルのxattrsをサポートする必要があります。

各オブジェクトは、ファイルのチェックサムから取得したパスと操作のタイムスタンプを使用して保存されます。 最後のレコードは常に（グローバルクロック同期を引き起こす分散シナリオを含む）を上回り、オブジェクトの最新バージョンのメンテナンスを保証します。 削除は、ファイルのバージョン（「.ts」で終わる0バイトのファイル、これは廃棄（tombstone）を意味する）とも見なされます。 これにより、削除されたファイルが正しく複製されます。 この場合、古いバージョンのファイルは失敗しても再表示されません。

コンテナ取扱サーバー

コンテナ処理サーバーは、オブジェクトのリストを処理します。 彼はオブジェクトがどこにあるのかを知らず、特定のコンテナの内容のみを知ります。 リストはsqlite3データベースファイルとして保存され、オブジェクトと同じ方法でクラスター全体に複製されます。 オブジェクトの総数や、このコンテナに使用されているストレージの量などの統計も追跡されます。

特別なプロセス（swift-container-updater）は、実行中のノードのコンテナーデータベースを常にチェックし、コンテナーデータが変更されるとアカウントデータベースを更新します。 更新する必要があるアカウントを見つけるには、リングを使用します。

アカウント処理サーバー

コンテナー処理サーバーと同様に機能しますが、コンテナーリストを処理します。

特徴と機能

-レプリケーション：手動で構成できるオブジェクトのコピーの数。

-オブジェクトのダウンロードは同期プロセスです。プロキシサーバーは、レプリカの半分以上が記録されている場合にのみ「201 Created」HTTPコードを返します。

-OpenStack認証サービス（Keystone）との統合：アカウントは参加者に割り当てられます。

-データの検証：xattrsに保存されているメタデータと比較したファイルシステム内のmd5オブジェクトの合計。

-コンテナの同期：複数のデータセンターでコンテナを同期することが可能になります。

-転送メカニズム：追加のノードを使用して、障害が発生した場合にレプリカを保存することができます。

-オブジェクトのサイズが5 GBを超える場合、分割する必要があります。これらの部分は個別のオブジェクトとして保存されます。 同時に読むことができます。

セフ

Cephは、分散POSIXメタデータおよびセマンティクス管理を備えた分散ネットワーク接続ストレージです。 Cephオブジェクトリポジトリへのアクセスは、専用のcmdlineツール、FUSE、Amazon S3クライアントなどのさまざまなクライアントを介して取得できます（「 S3 Gateway 」と呼ばれる互換性レベルを使用）。 Cephには高度なモジュール性があります。さまざまな機能セットが、組み合わせて組み立てられるさまざまなコンポーネントによって提供されます。 特に、s3 APIを介してアクセスされるオブジェクトストアの場合、オブジェクト処理サーバー、監視サーバー、RADOSゲートウェイの 3つのコンポーネントを起動するだけで十分です。

監視サーバー

ceph-monは、Cephクラスターでの分散意思決定の一貫性を提供する軽量のワークフローです。 また、クラスタトポロジに関する情報を提供する新規顧客の連絡先の出発点でもあります。 通常、3つの異なる物理マシンには、互いに分離された3つのceph-monワークフローがあります。 たとえば、異なる棚や異なる列に。

オブジェクト処理サーバー

Cephがホストする実際のデータは、RADOSと呼ばれるクラスターストレージエンジンの上に格納されます。RADOSは、一連のストレージノードに展開されます。

ceph-osdは、クラスター内の各ストレージノード（オブジェクト処理サーバー）で実行されるストレージワークフローで、Ceph.ceph-osdはceph-monに接続してクラスターに参加します。 その主な目的は、クライアントからの読み取り/書き込み要求およびその他の要求を処理することです。 また、他のceph-osdプロセスと対話してデータを複製します。 このレベルでは、データモデルは比較的単純です。 名前付きプールがいくつかあり、各プール内には、フラットな名前空間（ディレクトリなし）に名前付きオブジェクトがあります。 各オブジェクトにはデータとメタデータがあります。 オブジェクトデータは、潜在的に大きな一連のバイトです。 メタデータは、キーと値のペアの順不同のコレクションです。 Cephファイルシステムは、メタデータを使用して、ファイルの所有者などに関する情報を保存します。 その下で、cef-osdワークフローはデータをローカルファイルシステムに保存します。 Btrfsをお勧めしますが、拡張属性を備えたPOSIXファイルシステムであればすべて可能です。

クラッシュアルゴリズム

Swiftは順次配信とデータ取得にリング（md5チェックサム範囲を一連のストレージノードにマッピング ）を使用しますが 、CephはこれにCRUSHと呼ばれるアルゴリズムを使用します 。 つまり、CRUSHは、オブジェクトの名前、クラスターマップ、およびCRUSHルールに基づいて、Cephのデータの物理的な場所を計算できるアルゴリズムです。 CRUSHは、物理的な組織を反映する階層内のストレージクラスターを表し、データが物理的な機器に正しく複製されるようにします。 さらに、CRUSHでは、ポリシーを使用してデータの配置を制御できます。これにより、CRUSHはクラスターへの参加の変更に対応できます。

Radosゲートウェイ

radosgwは、Cephクラスターにオブジェクトとメタデータを保存するためのRESTful HTTP APIを提供するFastCGIサービスです。

特徴と機能

-部分的または完全な読み取りおよび書き込み操作

-写真

-範囲の追加、切り捨て、複製などの機能のアトミックトランザクション

-オブジェクトレベルでのキーと値の相関

-オブジェクトのレプリカの管理

-オブジェクト（一連のオブジェクト）のグループへの集約およびマッピンググループOSDシリーズ

-共有秘密鍵を使用した認証：クライアントと監視クラスターの両方に、クライアントの秘密鍵のコピーがあります
-API S3 / Swiftとの互換性

機能概要

	スイフト	セフ
複製	はい	はい
最大オブジェクトサイズ	5 GB （より大きなオブジェクトはセグメント化されています）	無制限
マルチDCインストール（データセンター間の分散）	はい（コンテナレベルでのみ複製が可能ですが、データセンター間の完全な複製のためのスキームが提案されています）	いいえ（Cephがまだサポートしていないデータ整合性の非同期の後続レプリケーションが必要です）
Openstackとの統合	はい	部分的 （Keystoneサポートの欠如）
レプリカ管理	いや	はい
記録アルゴリズム	同期	同期
Amazon S3互換API	はい	はい
データ配置方法	リング（静的マッピング構造）	CRUSH（アルゴリズム）

ソース

Swiftの公式ドキュメント -データ構造の説明のソース。
GithubのSwift Ringソースコード -Swift RingおよびRingBuilderクラスのソースコードベース。
Chmouel Boudjnahのブログ -便利なSwiftのヒント。
Cephの公式ドキュメント -データ構造の説明の主な情報源。

英語のオリジナル記事