第3章 Object Storage およびコンテナー
OpenStack Object Storage (openstack-swift) は、コンテナー内にオブジェクト (データ) を格納します。コンテナーとは、ファイルシステムにおけるディレクトリーと似ています。ただし、入れ子にはできません。コンテナーは、あらゆるタイプの非構造化データを格納する簡単な方法をユーザーに提供します。たとえば、オブジェクトには写真、テキストファイル、イメージなどが含まれます。格納されるオブジェクトは暗号化や圧縮はされません。
3.1. Object Storage サービスの管理
以下の手順では、Object Storage サービスをニーズに合わせてさらにカスタマイズする方法について説明します。
3.1.1. Object Storage サービスの Erasure Code
Erasure coding (EC) は、データの断片化、拡張、冗長データによる暗号化、別の場所やストレージメディアセットでの保存の際にデータを保護する方法です。EC は、従来のレプリケーションより小さいストレージボリュームを使用して、必要とされる耐久性を取得します。レプリケーションファクターが 3 のものと比較すると、注意深くデプロイメントを行うことで、50% の節約が実現できます。ただし、ワークロードによっては、Erasure Coding がパフォーマンスに悪影響を与える可能性があります。
Red Hat OpenStack Platform 8 リリースには、Object Storage サービス向けの Erasure Coding サポートがテクノロジープレビューとして利用できます。テクノロジープレビューとして提供されている機能のサポート範囲についての詳しい情報は、https://access.redhat.com/support/offerings/techpreview/ を参照してください。
Erasure Coding は、Object Storage Service 向けにストレージポリシーとしてサポートされます。ストレージポリシーにより複数のオブジェクトリングを作成することでさまざまな目的のクラスターをセグメント化できます。Red Hat は、Erasure Coding およびレプリケーションストレージポリシーで使用するデバイスを分割することを推奨します。これにより、クラスターの動きをより簡単に分析することができます。
選択する方向性は、Erasure Coding ポリシーのデプロイの理由により異なります。主な検討事項は以下のとおりです。
- 既存のインフラストラクチャーのレイアウト
- 専用の Erasure Coding ノード (または Erasure Coding デバイス)の追加コスト
- 目的とする使用モデル
3.1.1.1. Erasure Coding の設定
Erause Coding ポリシーを使用するには、swift.conf ファイルで Erasure Coding ポリシーを定義して、関連のオブジェクトリングを作成、設定します。Erasure Coding ポリシーの設定方法例は、以下のとおりです。
[storage-policy:2] name = ec104 policy_type = erasure_coding ec_type = jerasure_rs_vand ec_num_data_fragments = 10 ec_num_parity_fragments = 4 ec_object_segment_size = 1048576
以下の表では、ストレージポリシーの用語を説明しています。
| 用語 | 説明 |
|---|---|
|
name |
標準のストレージポリシーのパラメーター |
|
policy_type |
この値を erasure_coding に設定して、Erasure Coding ポリシーであることを指定します。 |
|
ec_type |
この値は、選択した PyECLib バックエンドの利用可能なオプションに合わせて設定します。これは、使用する Erasure Coding スキームを指定します。たとえば、ここで示すオプションでは、Vandermonde Reed-Solomon の暗号化を選択していますが、flat_xor_hd_3 のオプションは Flat-XOR ベースの HD の組み合わせコードを選択します。完全な詳細は、PyECLib を参照してください。 |
|
ec_num_data_fragments |
データを構成するフラグメントの合計数 |
|
ec_num_parity_fragments |
パリティーを構成するフラグメントの合計数 |
|
ec_object_segment_size |
セグメントをエンコーダー/デコーダーにフィードする前に増やすデータのバッファー量。デフォルト値は 1048576 です。 |
PyECLib がオブジェクトを暗号化する際には、N 個のフラグメントに分割します。設定時に、フラグメントのうち何個がデータで、何個がパリティーであるかを知っておくことが重要です。上記の例では、PyECLib はオブジェクトを 14 個のフラグメントに分割して、そのうち、実際のオブジェクトデータは 10 個で、パリティーデータは 4 個 (計算は ec_type に左右される) です。このような設定では、システムは、ディスクの障害は 4 回分までであればデータの損失なしで済みます。その他に一般的に使用される設定は 4+2 (データフラグメント 4 個とパリティーフラグメント 2 個) または 8+3 (データフラグメント 8 個とパリティーフラグメント 3 個) です。
ポリシーをデプロイして、そのポリシーでオブジェクトを作成した後にはこれらの設定オプションの変更はできない点にご注意ください。設定の変更が望ましい場合には、新規ポリシーを作成して、データを新しいコンテナーに移行します。ただし、定義が済むと、ポリシーのインデックスは破棄できません。ポリシーを終了する場合には、ポリシーを無効にすることはできますが、削除はできません。基本的に、以前のポリシーが残っていてもパフォーマンスへの影響はありませんが、若干、管理の負担が出てきます。
3.1.1.2. オブジェクトストレージリングの設定
オブジェクトストレージは、リング と呼ばれるデータ構造を使用して、パーティション領域をクラスターに分散します。このパーティション領域は、Object Storage サービスのレプリケーションシステムの中核となります。これにより、Object Storage サービスが迅速かつ簡単にクラスター内の各パーティションを同期できるようになります。Swift のコンポーネントがデータと対話する必要がある場合には、ローカルでリング内を素早く検索して、各レプリカに使用可能なパーティションを見つけます。
Object Storage サービスにはすでに 3 つのリングがあり、各種データが格納されています。リングは、アカウント情報に 1 つ、(アカウント内のオブジェクトを整理するのに役立つ) コンテナーに 1 つ、オブジェクトのレプリカに 1 つあります。Erasure Code をサポートするために、Erasure Code のチャンクを格納するために作成された追加のリングがあります。
たとえば、典型的なレプリケーションリングを作成するには、以下のコマンドを使用します。
swift-ring-builder object-1.builder create 10 3 1
3 は、レプリカの数です。
以下のように、Erasure Coding のオブジェクトリングを作成するには、レプリカの数の部分にフラグメントの数を指定する必要があります。
swift-ring-builder object-1.builder create 10 14 1
14 は、データフラグメント 10 とパリティーフラグメント 4 (10+4) を合わせた設定です。
Erasure Coding ポリシーのオブジェクトリングで使用するデバイスを決定する際には、パフォーマンスの影響を考慮します。デプロイメントの前の設定に対して、テスト環境でパフォーマンスのベンチマーキングを実行することを推奨します。swift.conf で Erasure Coding のポリシーを設定してオブジェクトリングを作成した後には、指定のポリシー名でコンテナーを作成して通常通りに対話することで、アプリケーションでの Erasure Coding の使用準備が整います。
3.1.2. Image サービスのバックエンドとしてのオブジェクトストレージの設定
デフォルトでは、OpenStack の Image サービスは、イメージおよびインスタンスのスナップショットを /var/lib/glance/images/ のローカルのファイルシステムに保存します。または、(可能な場合には) Image サービスが Object Storage サービスにイメージとスナップショットを保存するように設定することも可能です。
この設定には、以下の手順を実行します。
root として Image サービスを実行中のノード (Identity も実行するコントローラーノード) にログインし、OpenStack の認証情報 (これは通常
openrcという名前のファイル) を読み込みます。# source ~/openrc
Image サービスが
adminロールを持つserviceテナントの一部であることを確認します。# keystone user-role-list --user glance --tenant service
返されたロールの 1 つは、
adminでなければなりません。/etc/glance/glance.confファイルを開き、以下の行をコメントアウトします。##### DEFAULT OPTIONS ##### #default_store = file #filesystem_store_datadir = /var/lib/glance/images/
同じファイル内で
DEFAULT OPTIONSのセクションに以下の行を追加します。default_store = swift swift_store_auth_address = http://KEYSTONEIP:35357/v2.0/ swift_store_user = service:glance swift_store_key = ADMINPW swift_store_create_container_on_put = True
上記の設定で、
-
KEYSTONEIPは、Identity サービスの IP アドレスに置き換えてください。 -
ADMINPWは、/etc/glance/glance-api.confファイルの管理者パスワードの値に置き換えてください。
-
Image サービスを再起動して変更を適用します。
# systemctl restart openstack-glance-api # systemctl restart openstack-glance-registry
この時点から、(Dashboard または glance 経由) Image サービスにアップロードされたイメージは glance という名前の Object Storage コンテナーに保存されるはずです。このコンテナーは、サービスアカウントに存在します。
新規作成イメージが Image サービスに保存されたことを確認するには、以下のコマンドを実行します。
# ls /var/lib/glance/images
Dashboard または glance image-list により、イメージがアクティブな状態であることが報告されたら、以下のコマンドを実行してイメージがオブジェクトストレージにあるかどうかを確認できます。
# swift --os-auth-url http://KEYSTONEIP:5000/v2.0 --os-tenant-name service --os-username glance --os-password ADMINPW list glance
3.2. 基本的なコンテナー管理
擬似フォルダーは、オブジェクトを格納することができる論理デバイスで、入れ子が可能となっているので、整理がしやすくなります。たとえば、画像を保管する Images フォルダーや、ビデオを保管する Media フォルダーなどを作成することができます。
各プロジェクトに 1 つまたは複数のコンテナーを作成することができます。また、各コンテナーには、1 つまたは複数の擬似フォルダーを作成することができます。
3.2.1. コンテナーの作成
- Dashboard で プロジェクト > オブジェクトストア > コンテナー を選択します。
- コンテナーの作成 をクリックします。
コンテナー名 を指定して、コンテナーアクセス フィールドで以下のいずれかのオプションを選択します。
タイプ 説明 プライベート現在のプロジェクトでユーザーに対してアクセスを制限します。
パブリックパブリックの URL を使用して API アクセスを全員に許可します。ただし、Dashboard では、プロジェクトユーザーには、他のプロジェクトのパブリックコンテナーおよびデータは表示されません。
- コンテナーの作成 をクリックします。
3.2.2. コンテナー用の擬似フォルダーの作成
- Dashboard で プロジェクト > オブジェクトストア > コンテナー を選択します。
- 擬似フォルダーを追加するコンテナーの名前をクリックします。
- 疑似フォルダーの作成 をクリックします。
- 疑似フォルダー名 フィールドに名前を指定し、作成 をクリックします。
3.2.3. コンテナーの削除
- Dashboard で プロジェクト > オブジェクトストア > コンテナー を選択します。
- コンテナー のセクションの一覧を参照して全オブジェクトが削除済みであることを確認します (「オブジェクトの削除」を参照)。
- 対象のコンテナーの矢印メニューで コンテナーの削除 を選択します。
- コンテナーの削除 をクリックして、コンテナーを削除する操作を確定します。
3.2.4. オブジェクトのアップロード
実際のファイルをアップロードしない場合でも、オブジェクトは (プレースホルダーとして) 作成され、後でファイルをアップロードする際に使用することができます。
- Dashboard で プロジェクト > オブジェクトストア > コンテナー を選択します。
- アップロードしたオブジェクトの配置先となるコンテナーの名前をクリックします。そのコンテナーに擬似フォルダーがすでに存在している場合には、擬似フォルダーの名前をクリックすることもできます。
- ファイルをブラウズしてオブジェクトのアップロード をクリックします。
オブジェクト名 フィールドに名前を指定します。
- 擬似フォルダーはスラッシュ (/) の記号を使用して指定することができます (例: Images/myImage.jpg)。指定したフォルダーがまだ存在していない場合には、オブジェクトのアップロード時に作成されます。
- その場所 (オブジェクトがすでに存在している場所) に一意ではない名前は、そのオブジェクトの以前のコンテンツを上書きします。
- オブジェクトのアップロード をクリックします。
3.2.5. オブジェクトのコピー
- Dashboard で プロジェクト > オブジェクトストア > コンテナー を選択します。
- オブジェクトのコンテナーまたはフォルダーの名前をクリックします (オブジェクトを表示します)。
- オブジェクトのアップロード をクリックします。
- コピーするファイルを参照し、矢印メニューで コピー を選択します。
以下の項目を設定します。
フィールド 説明 宛先コンテナー
新規プロジェクトの宛先コンテナー
パス
宛先コンテナーの擬似フォルダー。フォルダーが存在しない場合は、作成されます。
宛先オブジェクト名
新規オブジェクト名。その場所に一意ではない名前を使用した場合 (そのオブジェクトがすでに存在している場合) には、そのオブジェクトの以前のコンテンツが上書きされます。
- オブジェクトのコピー をクリックします。
3.2.6. オブジェクトの削除
- Dashboard で プロジェクト > オブジェクトストア > コンテナー を選択します。
- 一覧を参照して対象のオブジェクトを特定し、矢印メニューで オブジェクトの削除 を選択します。
- オブジェクトの削除 をクリックして、オブジェクトを削除する操作を確定します。

Where did the comment section go?
Red Hat's documentation publication system recently went through an upgrade to enable speedier, more mobile-friendly content. We decided to re-evaluate our commenting platform to ensure that it meets your expectations and serves as an optimal feedback mechanism. During this redesign, we invite your input on providing feedback on Red Hat documentation via the discussion platform.