第3章 Object Storage

OpenStack Object Storage (openstack-swift) は、コンテナー内にオブジェクト (データ) を格納します。コンテナーとは、ファイルシステムにおけるディレクトリーと似ています。ただし、入れ子にはできません。コンテナーは、あらゆるタイプの非構造化データを格納する簡単な方法をユーザーに提供します。たとえば、オブジェクトには写真、テキストファイル、イメージなどが含まれます。格納されるオブジェクトは圧縮されません。

3.1. Object Storage サービスの管理

以下の手順では、Object Storage サービスをニーズに合わせてさらにカスタマイズする方法について説明します。

3.1.1. Erasure Coding の設定

Erasure coding (EC) は、データの断片化、拡張、冗長データによる暗号化、別の場所やストレージメディアセットでの保存の際にデータを保護する方法です。EC は、従来のレプリケーションより小さいストレージボリュームを使用して、必要とされる耐久性を取得します。レプリケーションファクターが 3 のものと比較すると、注意深くデプロイメントを行うことで、50％の節約が実現できます。ただし、ワークロードによっては、Erasure Coding がパフォーマンスに悪影響を与える可能性があります。

Erasure Coding は、Object Storage Service 向けにストレージポリシーとしてサポートされます。ストレージポリシーにより複数のオブジェクトリングを作成することでさまざまな目的のクラスターをセグメント化できます。Red Hat は、Erasure Coding およびレプリケーションストレージポリシーで使用するデバイスを分割することを推奨します。これにより、クラスターの動きをより簡単に分析することができます。

選択する方向性は、Erasure Coding ポリシーのデプロイの理由により異なります。主な検討事項は以下のとおりです。

既存のインフラストラクチャーのレイアウト
専用の Erasure Coding ノード (または Erasure Coding デバイス)の追加コスト
目的とする使用モデル

3.1.1.1. Erasure Coding ポリシーの設定

Erasure Coding を使用するには、最初に /etc/swift/swift.conf で EC の追加のポリシーを定義します。以下の「Erasure Coding ポリシーの例」では、一般的な例を紹介しています。

Erasure Coding ポリシーの例

[storage-policy:1]
default = no
name = ec104
alias = myec,erasure_coding
policy_type = erasure_coding
ec_type = jerasure_rs_vand
ec_num_data_fragments = 10
ec_num_parity_fragments = 4
ec_object_segment_size = 1048576

注記

Object Storage ポリシーヘッダー (例: [storage-policy:1]) にはインデックスの番号が含まれます。今回の場合は 1 です。Object Storage のインデックス数は 0 から開始するので、上記の「Erasure Coding ポリシーの例」では、ポリシーインデックスが 0 の別のポリシーがすでに存在することを想定しています。以下に例を示します。

[storage-policy:0]
name = default
default = yes

Erasure Coding ポリシーの定義後に、関連のオブジェクトストレージリングを作成、設定する必要があります。説明は「オブジェクトストレージリングの設定」を参照してください。

以下の表では、「Erasure Coding ポリシーの例」で使用する各種パラメーターについて説明しています。

表3.1 ストレージポリシーのパラメーター
用語	説明
default	このポリシーがデフォルトのものかどうかを設定します (yes/no)。これは、/etc/swift/swift.conf に複数のポリシーが定義されている場合に使用します。
name	標準のストレージポリシーのパラメーター
alias	ポリシーの別名をコンマ区切りにしたリスト
policy_type	この値を erasure_coding に設定して、Erasure Coding ポリシーであることを指定します。
ec_type	使用予定の Erasure Coding スキームを指定します。サポートされる値の一覧については表3.2「サポートされる Erasure Coding スキーム」を参照してください。
ec_num_data_fragments	データを構成するフラグメントの合計数
ec_num_parity_fragments	パリティーを構成するフラグメントの合計数
ec_object_segment_size	セグメントをエンコーダー/デコーダーにフィードする前に増やすデータのバッファー量。デフォルト値は 1048576 です。

表3.2 サポートされる Erasure Coding スキーム
スキーム	説明/参照
liberasurecode_rs_vand	Vandermonde Reed-Solomon エンコーディング。liberasurecode により実装されるソフトウェアのみのバックエンド
jerasure_rs_vand	Jerasure をベースにする Vandermonde Reed-Solomon エンコーディング
jerasure_rs_cauchy	Jerasure をベースにする Cauchy Reed-Solomon エンコーディング (Jerasure の派生)
flat_xor_hd_3, flat_xor_hd_4	Flat-XOR ベースの HD 組み合わせコード (liberasurecode)
isa_l_rs_vand	Intel Storage Acceleration Library (ISA-L): SIMD accelerated Erasure Coding バックエンド

Object Storage サービスがオブジェクトを暗号化する際には、N 個のフラグメントに分割します。設定時に、フラグメントのうち何個がデータで、何個がパリティーであるかを知っておくことが重要です。Erasure Coding ポリシーの例では、PyECLib はオブジェクトを 14 個のフラグメントに分割して、そのうち、実際のオブジェクトデータは 10 個で、パリティーデータは 4 個 (計算は ec_type に左右される) です。このような設定では、システムは、ディスクの障害は 4 回分までであればデータの損失なしで済みます。その他に一般的に使用される設定は 4+2 (データフラグメント 4 個とパリティーフラグメント 2 個) または 8+3 (データフラグメント 8 個とパリティーフラグメント 3 個) です。

重要

ポリシーをデプロイして、そのポリシーでオブジェクトを作成した後にはこれらの設定オプションの変更はできません。設定の変更が望ましい場合には、新規ポリシーを作成して、データを新しいコンテナーに移行します。ただし、定義が済むと、ポリシーのインデックスは破棄できません。ポリシーを終了する場合には、ポリシーを無効にすることはできますが、削除はできません。基本的に、以前のポリシーが残っていてもパフォーマンスへの影響はありませんが、若干、管理の負担が出てきます。

3.1.1.2. オブジェクトストレージリングの設定

オブジェクトストレージは、リング と呼ばれるデータ構造を使用して、パーティション領域をクラスターに分散します。このパーティション領域は、Object Storage サービスのデータ永続性エンジン (data durability engine) の中核となります。これにより、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 ポリシーのオブジェクトリングで使用するデバイスを決定する際には、パフォーマンスの影響を考慮します。デプロイメントの前の設定に対して、テスト環境でパフォーマンスのベンチマーキングを実行することを推奨します。/etc/swift/swift.conf で Erasure Coding のポリシーを設定してオブジェクトリングを作成した後には、指定のポリシー名でコンテナーを作成して通常通りに対話することで、アプリケーションでの Erasure Coding の使用準備が整います。

3.1.1.3. Erasure Coding の使用

新規の Erasure Coding ポリシーを定義して、そのオブジェクトストレージリングを設定した後には、初めて新しいコンテナーを作成する際に EC ポリシーを使用することができます。複数のポリシーを定義した場合には、デフォルトのストレージポリシーが割り当てられたコンテナーが作成されます。

新しいコンテナーでデフォルト以外のストレージポリシーを使用するには、コンテナーの作成時に特別なメタデータヘッダー送信する必要があります。たとえば、新規コンテナー (CONTAINERNAME) で「Erasure Coding ポリシーの設定」に定義した「Erasure Coding ポリシーの例」で提示したポリシーを使用するには、以下のコマンドを実行します。

# swift post -H "X-Storage-Policy:ec104" CONTAINERNAME

3.1.2. Fast-POST の設定

デフォルトでは、Object Storage サービスは、メタデータの一部でも変更があると必ず、オブジェクト全体をコピーします。fast-post 機能を使用することでこれを回避できます。これは、複数の大型オブジェクトのコンテンツタイプを変更する際に時間を節約する際に役立ちます。

Fast-Post 機能を有効化するには、Object Storage プロキシーサービスの object_post_as_copy オプションを無効にします。これには、以下を実行します。

Object Storage プロキシーサービスをホストするノードにログインします。
/etc/swift/proxy-server.conf を開きます。
以下のように、[app:proxy-server] のセクションで、object_post_as_copy を false に設定します。
```
[app:proxy-server]
use = egg:swift#proxy
set log_name = proxy-server
…
object_post_as_copy = false
…
```
ノードで Object Storage プロキシーサービスを再起動します。
```
# systemctl restart openstack-swift-proxy.service
# systemctl restart openstack-swift-object-expirer.service
```
policy-0 以外のストレージポリシーが /etc/swift/swift.conf に記載されている場合には、以下も実行してください。
```
# systemctl restart openstack-swift-container-reconciler.service
```

注記

一般的なオーバークラウドのデプロイメントでは、Object Storage サービスはコントローラーノードにインストールされています。

3.1.3. 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 では、プロジェクトユーザーには、他のプロジェクトのパブリックコンテナーおよびデータは表示されません。

コンテナーの作成 をクリックします。

新しいコンテナーはデフォルトのストレージポリシーを使用します。複数のストレージポリシーが定義されている場合には (たとえば、デフォルトのポリシーと、Erasure Coding を有効にするポリシーなど)、コマンドラインからデフォルト以外のストレージポリシーを使用するようにコンテナーを設定することができます。これには以下を実行してください。

# swift post -H "X-Storage-Policy:POLICY" CONTAINERNAME

上記の設定で、

POLICY は、コンテナーで使用するポリシーの名前またはエイリアスに置き換えます。Erasure Coding を使用するサンプルのポリシーについては、「Erasure Coding ポリシーの設定」を参照してください。
CONTAINERNAME は、コンテナーの名前に置き換えてください。

3.2.2. コンテナー用の擬似フォルダーの作成

Dashboard で プロジェクト > オブジェクトストア > コンテナー を選択します。
擬似フォルダーを追加するコンテナーの名前をクリックします。
疑似フォルダーの作成 をクリックします。
疑似フォルダー名 フィールドに名前を指定し、作成をクリックします。

3.2.3. コンテナーの削除

Dashboard で プロジェクト > オブジェクトストア > コンテナー を選択します。
コンテナー のセクションの一覧を参照して全オブジェクトが削除済みであることを確認します (「オブジェクトの削除」を参照)。
対象のコンテナーの矢印メニューで コンテナーの削除 を選択します。
コンテナーの削除 をクリックして、コンテナーを削除する操作を確定します。

3.2.4. オブジェクトのアップロード

実際のファイルをアップロードしない場合でも、オブジェクトは (プレースホルダーとして) 作成され、後でファイルをアップロードする際に使用することができます。

Dashboard で プロジェクト > オブジェクトストア > コンテナー を選択します。
アップロードしたオブジェクトの配置先となるコンテナーの名前をクリックします。そのコンテナーに擬似フォルダーがすでに存在している場合には、擬似フォルダーの名前をクリックすることもできます。
ファイルをブラウズしてオブジェクトのアップロード をクリックします。
オブジェクト名 フィールドに名前を指定します。
- 擬似フォルダーはスラッシュ (/) の記号を使用して指定することができます (例: Images/myImage.jpg)。指定したフォルダーがまだ存在していない場合には、オブジェクトのアップロード時に作成されます。
- その場所 (オブジェクトがすでに存在している場所) に一意ではない名前は、そのオブジェクトの以前のコンテンツを上書きします。
オブジェクトのアップロード をクリックします。

3.2.5. オブジェクトのコピー

Dashboard で プロジェクト > オブジェクトストア > コンテナー を選択します。
オブジェクトのコンテナーまたはフォルダーの名前をクリックします (オブジェクトを表示します)。
オブジェクトのアップロード をクリックします。
コピーするファイルを参照し、矢印メニューで コピー を選択します。

以下の項目を設定します。

フィールド	説明
宛先コンテナー	新規プロジェクトの宛先コンテナー
パス	宛先コンテナーの擬似フォルダー。フォルダーが存在しない場合は、作成されます。
宛先オブジェクト名	新規オブジェクト名。その場所に一意ではない名前を使用した場合 (そのオブジェクトがすでに存在している場合) には、そのオブジェクトの以前のコンテンツが上書きされます。

オブジェクトのコピー をクリックします。

3.2.6. オブジェクトの削除

Dashboard で プロジェクト > オブジェクトストア > コンテナー を選択します。
一覧を参照して対象のオブジェクトを特定し、矢印メニューで オブジェクトの削除 を選択します。
オブジェクトの削除 をクリックして、オブジェクトを削除する操作を確定します。