Dell EqualLogic バックエンドガイド
Red Hat OpenStack Platform オーバークラウドでの Dell EqualLogic Storage の使用ガイド
概要
第1章 はじめに リンクのコピーリンクがクリップボードにコピーされました!
本書では、1 つ以上の Dell EqualLogic バックエンドを使用するように OpenStack を設定する方法について説明します。また、Dell EqualLogic デバイスと OpenStack Block Storage サービス間のボリュームサイズの不一致に対応する手順も含まれます。
以下のセクションは、以下を前提としています。
- Block Storage バックエンドに Dell EqualLogic デバイスおよびドライバーのみを使用する予定です。
- 正常に機能する Block Storage サービスと共に、director により OpenStack オーバークラウドがすでにデプロイされている。
- Dell ストレージデバイスがすでにデプロイされ、ストレージリポジトリーとして設定されている。
- Dell EqualLogic Group がすでにデプロイされ、SSH 経由でアクセスできる。
- 利用可能な Dell EqualLogic Group のグループマネージャーへの接続に必要な認証情報がある(つまり、CHAP およびグループマネージャーの認証情報)。
-
昇格した特権を持つアカウントのユーザー名およびパスワードを所有している。オーバークラウドのデプロイ用に作成されたものと同じアカウントを使用できる。Creating a Director Installation Userでは、この目的のために
stackユーザーを作成し使用します。
RHEL OpenStack Platform が director を使用してデプロイされる場合、主要なオーバークラウド設定 (特に Block Storage サービスのバックエンド) も、director を使用して定義およびオーケストレーションする必要があります。これにより、今後オーバークラウドが更新されても設定が維持されます。director を使用した OpenStack のデプロイについての詳しい情報は、Director Installation and Usageを参照してください。
本書の目的は、目的の Dell EqualLogic バックエンド設定をオーバークラウドの Block Storage サービスにオーケストレーションする方法について説明することです。本書では、バックエンドで可能な異なるデプロイメント設定については説明しません。利用可能な異なるデプロイメント設定については、デバイスの製品ドキュメントを参照してください。
デプロイする結果のバックエンド設定 (およびその対応する設定) を理解したら、director を介してオーケストレーションする方法について、本書を参照してください。
現在、director には Dell EqualLogic バックエンドの 単一 インスタンスをデプロイする統合コンポーネントのみがあります。そのため、本書では単一のバックエンドのデプロイメントのみを説明します。
Dell EqualLogic バックエンドの複数のインスタンスをデプロイするには、カスタムのバックエンド設定 が必要です。手順については、Custom Block Storage Back End Deployment Guideを参照してください。
第2章 プロセスの説明 リンクのコピーリンクがクリップボードにコピーされました!
RHEL OpenStack Platform には、Block Storage サービスでサポートされるすべての Dell デバイスに必要なすべてのドライバーが含まれます。さらに、director には、デバイスをオーバークラウドのバックエンドとして統合するのに必要な Puppet マニフェスト、環境ファイル、オーケストレーションテンプレートもあります。
単一の Dell デバイスをバックエンドとして設定する には、デフォルトの 環境ファイルを編集して、オーバークラウドのデプロイメントに含める必要があります。このファイルは、アンダークラウドでローカルで使用でき、ご使用の環境に応じて編集できます。
このファイルを編集したら、director 経由で呼び出します。これにより、今後のオーバークラウド更新後も維持されます。以下のセクションでは、このプロセスをより詳細に説明します。さらに、デフォルトの環境ファイルには、残りの必要な Block Storage 設定を定義する必要な Puppet マニフェストと Orchestration (Heat) テンプレートを呼び出すのに十分な情報がすでに含まれています。
第3章 単一バックエンドの定義 リンクのコピーリンクがクリップボードにコピーされました!
本項では、単一のバックエンドのデプロイメントについて説明します。Dell EqualLogic バックエンドの複数のインスタンスをデプロイするには、カスタムのバックエンド設定 が必要です。手順については、Custom Block Storage Back End Deployment Guideを参照してください。
Director のデプロイメントでは、単一 の Dell EqualLogic バックエンドを定義する最も簡単な方法は、統合環境ファイルを使用することです。このファイルは、アンダークラウドノードの以下のパスにあります。
/usr/share/openstack-tripleo-heat-templates/environments/cinder-eqlx-config.yaml
このファイルを、編集して後で呼び出すことができローカルパスにコピーします。たとえば、~/templates/ にコピーするには、以下のコマンドを実行します。
cp /usr/share/openstack-tripleo-heat-templates/environments/cinder-eqlx-config.yaml ~/templates/
$ cp /usr/share/openstack-tripleo-heat-templates/environments/cinder-eqlx-config.yaml ~/templates/
その後、コピー(~/templates/cinder-eqlx-config.yaml)を開き、必要に応じて編集します。以下のスニペットに、このファイルのデフォルトの内容を示します。
- 1
resource_registryセクションの OS::TripleO::ControllerExtraConfigPre: パラメーターは、cinder-eqlx.yamlという名前の Heat テンプレートを参照します。これは、Director がバックエンドの設定に必要なリソースをロードするために使用するテンプレートです。デフォルトでは、このパラメーターはcinder-eqlx.yamlへの相対パスを指定します。そのため、このパラメーターをファイルへの絶対パスで更新します。resource_registry: OS::TripleO::ControllerExtraConfigPre: /usr/share/openstack-tripleo-heat-templates/puppet/extraconfig/pre_deploy/controller/cinder-eqlx.yaml
resource_registry: OS::TripleO::ControllerExtraConfigPre: /usr/share/openstack-tripleo-heat-templates/puppet/extraconfig/pre_deploy/controller/cinder-eqlx.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 2
- parameter_defaults セクションには、バックエンドの定義が含まれます。具体的には、director が
cinder-eqlx.yamlで定義されたリソースに渡す必要があるパラメーターが含まれます。 - 3
- CinderEnableEqlxBackend: true 行は、Dell EqualLogic バックエンドのデフォルト設定に必要な Puppet マニフェストを使用するように director に指示します。これには、Block Storage サービスが使用するボリュームドライバー(具体的には
cinder.volume.drivers.eqlx.DellEQLSanISCSIDriver)の定義が含まれます。
Dell EqualLogic バックエンドを定義するには、適宜 parameter_defaults セクションの設定を編集します。以下の表は、各パラメーターと、対応する /etc/cinder/cinder.conf 設定のリストを示します。
| パラメーター | /etc/cinder/cinder.conf setting | 説明 |
|---|---|---|
| CinderEqlxBackendName | volume_backend_name | ボリュームのバックエンドを識別する任意の名前。 |
| CinderEqlxSanIp | san_ip | SSH 経由で Dell EqualLogic Group に到達するのに使用される IP アドレス。 |
| CinderEqlxSanLogin | san_login |
CinderEqlxSanIp で SSH 経由でグループマネージャーにログインするユーザー名。デフォルトのユーザー名は |
| CinderEqlxSanPassword | san_password |
CinderEqlxSanLogin の対応するパスワード。デフォルトのパスワードは |
| CinderEqlxSanThinProvision | san_thin_provision |
この設定に必要な SAN ボリュームのシンプロビジョニングを有効 ( |
| CinderEqlxGroupname | eqlx_group_name |
Block Storage サービスがボリュームとスナップショットを作成するプールに使用されるグループ。デフォルトのグループは |
| CinderEqlxPool | eqlx_pool |
Block Storage サービスがボリュームとスナップショットを作成するプール。このオプションは、単一の Dell EqualLogic Group 上の Block Storage サービスが使用する複数のプールには使用できません。デフォルトのプールは |
| CinderEqlxChapLogin | eqlx_chap_login |
プール内の各ボリュームの CHAP ログインアカウント。デフォルトのアカウント名は |
| CinderEqlxChapPassword | eqlx_chap_password | CinderEqlxChapLogin の対応するパスワード。デフォルトのパスワードは 16 進数で無作為に生成されるので、このパスワードは手動で設定する必要があります。 |
| CinderEqlxUseChap | eqlx_use_chap |
CHAP 認証を無効にする (デフォルトでは |
第4章 設定したバックエンドのデプロイ リンクのコピーリンクがクリップボードにコピーされました!
director のインストールでは、root 以外のユーザーを使用してコマンドを実行します。これには、Block Storage バックエンドのデプロイメントのオーケストレーションが含まれます。Creating a Director Installation User では、この目的のために stack という名前のユーザーを作成します。このユーザーは、昇格された権限で設定されます。
3章単一バックエンドの定義で設定した単一のバックエンドをデプロイするには、まず stack ユーザーとしてアンダークラウドにログインします。次に、以下を実行してバックエンドをデプロイします(編集した ~/templates/cinder-eqlx-config.yamlで定義)。
openstack overcloud deploy --templates -e ~/templates/cinder-eqlx-config.yaml
$ openstack overcloud deploy --templates -e ~/templates/cinder-eqlx-config.yaml
オーバークラウドの作成時に追加の環境ファイルを渡した場合には、予定外の変更がオーバークラウドに加えられないように、ここで the -e オプションを使用して環境ファイルを再度渡します。
詳細は、オーバークラウドの スケーリング および オーバークラウドの 更新 を参照してください。
director がオーケストレーションを完了したら、バックエンドをテストします。手順については 5章設定したバックエンドのテスト を参照してください。
第5章 設定したバックエンドのテスト リンクのコピーリンクがクリップボードにコピーされました!
バックエンドをデプロイした後に、そこにボリュームを正常に作成できるかどうかをテストします。これを実行するには、最初に必要な環境変数を読み込む必要があります。これらの変数は、デフォルトで /home/stack/overcloudrc で定義されます。
これらの変数を読み込むには、stack ユーザーとして以下のコマンドを実行します。
source /home/stack/overcloudrc
$ source /home/stack/overcloudrc
詳細は、基本的なオーバークラウドへのアクセス を 参照してください。
これでコントローラーノードにログインするはずです。そこから、使用するバックエンド (ここでは、3章単一バックエンドの定義で新たに定義したバックエンド) を指定するために使用できる ボリューム種別 を作成することができます。これは、他のバックエンドが有効化されている OpenStack デプロイメントで必要です (director を使用することを推奨)。
delleql という名前のボリューム種別を作成するには、以下のコマンドを実行します。
cinder type-create delleql
$ cinder type-create delleql
次に、このボリュームタイプを で定義されたバックエンドにマッピングします。バックエンド名が tripleo_eqlx の場合( CinderEqlxBackendName パラメーターで定義されたように)、xref:edityaml[)で以下を実行します。
cinder type-key delleql set volume_backend_name=tripleo_eqlx
$ cinder type-key delleql set volume_backend_name=tripleo_eqlx
これで、ボリューム種別を呼び出して、新たに定義したバックエンドに 2 GB のボリュームを作成することができるはずです。そのためには、以下のコマンドを実行します。
cinder create --volume-type delleql 2
$ cinder create --volume-type delleql 2
第6章 Dell EqualLogic バックエンドとのボリュームサイズ不一致の対応 リンクのコピーリンクがクリップボードにコピーされました!
ボリュームサイズを報告する際に、Dell EqualLogic (EQL) バックエンドは内部ボリュームメタデータに使用される追加のストレージも考慮します。このサイズは、Block Storage サービスにより報告されるボリュームサイズよりも若干大きくなります。ただし、EQL バックエンドによって報告されるボリュームサイズは、Image サービスで使用されるものと同じです。
そのため、EQL バックエンドにイメージベースのボリュームを作成する場合は、最初にイメージのサイズを確認します。イメージが元々ボリュームベースの場合、EQL(および拡張により Image サービス) は、Block Storage サービスによって報告されるボリュームサイズよりも若干大きなサイズを報告します。
EQL で報告されるイメージサイズが若干大きい場合は、このイメージがベースのボリュームを作成する際に、サイズの不一致を考慮する必要があります。
6.1. 例 リンクのコピーリンクがクリップボードにコピーされました!
ここでは、1 GB のボリュームを作成するケースを示します。
# cinder create --display-name vol1 1
Block Storage サービスは 1 GB のボリュームサイズを報告しますが、EQL アレイではサイズ (VolReserve) が若干大きくなります。
eql> volume select volume-6bdace69-bd41-42fc-a63a-f834fb65a2e4
eql (volume-6bdace69-bd41-42fc-a63a-f834fb65a2e4)> show
_______________________________ Volume Information ______... Name: volume-6bdace69-bd41-42fc-a63a-f834fb65a2e4 Size: 1GB VolReserve: 1.01GB ...
_______________________________ Volume Information ______...
Name: volume-6bdace69-bd41-42fc-a63a-f834fb65a2e4
Size: 1GB
VolReserve: 1.01GB
...
このボリュームから新しいイメージを作成すると、cinder は 1 GB の正しいボリュームサイズを報告します。
# cinder upload-to-image --disk-format raw --container-format bare vol1 image_vol1
ただし、Image サービスは若干大きなサイズを報告します。
# glance image-list
...+------------+-------------+------------------+------------+--------+ ...| Name | Disk Format | Container Format | Size | Status | ...+------------+-------------+------------------+------------+--------+ ...| image_vol1 | raw | bare | 1085276160 | active | ...+------------+-------------+------------------+------------+--------+
...+------------+-------------+------------------+------------+--------+
...| Name | Disk Format | Container Format | Size | Status |
...+------------+-------------+------------------+------------+--------+
...| image_vol1 | raw | bare | 1085276160 | active |
...+------------+-------------+------------------+------------+--------+
glance ツールは、約 1.01 GB のイメージサイズを報告します。その結果、このイメージベースで新しい 1 GB のボリュームを作成すると失敗します。
# cinder create --display-name vol2 --image-id c65f7eae-e2c1-44ba-8af1-e33695897559 1
ERROR: Invalid input received: Size of specified image 2 is larger than volume size 1
ERROR: Invalid input received: Size of specified image 2 is larger than volume size 1
6.2. 回避策 リンクのコピーリンクがクリップボードにコピーされました!
前述のように、イメージベースのボリュームのサイズを指定する際に、Image サービスと Block Storage サービスによって報告されるボリュームサイズ間の不一致を考慮する必要があります。つまり、イメージベースのボリュームのサイズを指定する場合には、glance により報告されるイメージサイズ後の次の整数 を使用することになります。
上記の例の場合は、glance は 1.01 GB のイメージサイズを報告していました。つまり、ボリュームを作成する場合は、1 GB ではなく、2 GB のボリュームサイズを指定する必要があります。
# cinder create --display-name vol2 --image-id c65f7eae-e2c1-44ba-8af1-e33695897559 2