第7章 オーバークラウド作成後のタスクの実行

本章では、任意のオーバークラウドを作成後に実行するタスクについて考察します。

7.1. オーバークラウドのテナントネットワークの作成

オーバークラウドには、インスタンス用のテナントネットワークが必要です。source コマンドで overcloud を読み込んで、Neutron で初期テナントネットワークを作成します。以下に例を示します。

$ source ~/overcloudrc
$ openstack network create default
$ openstack subnet create default --network default --gateway 172.20.1.1 --subnet-range 172.20.0.0/16

上記のステップにより、default という名前の基本的な Neutron ネットワークが作成されます。オーバークラウドは、内部 DHCP メカニズムを使用したこのネットワークから、IP アドレスを自動的に割り当てます。

neutron net-list により、作成したネットワークを確認します。

$ openstack network list
+-----------------------+-------------+--------------------------------------+
| id                    | name        | subnets                              |
+-----------------------+-------------+--------------------------------------+
| 95fadaa1-5dda-4777... | default     | 7e060813-35c5-462c-a56a-1c6f8f4f332f |
+-----------------------+-------------+--------------------------------------+

7.2. オーバークラウドの外部ネットワークの作成

インスタンスに Floating IP を割り当てることができるように、オーバークラウドで外部ネットワークを作成する必要があります。

ネイティブ VLAN の使用

以下の手順では、外部ネットワーク向けの専用インターフェースまたはネイティブの VLAN が設定されていることが前提です。

source コマンドで overcloud を読み込み、Neutron で外部ネットワークを作成します。以下に例を示します。

$ source ~/overcloudrc
$ openstack network create public --external --provider-network-type flat --provider-physical-network datacentre
$ openstack subnet create public --network public --dhcp --allocation-pool start=10.1.1.51,end=10.1.1.250 --gateway 10.1.1.1 --subnet-range 10.1.1.0/24

以下の例では、public という名前のネットワークを作成します。オーバークラウドでは、デフォルトの Floating IP プールにこの特定の名前が必要です。このネットワークは、「オーバークラウドの検証」の検証テストでも重要となります。

このコマンドにより、ネットワークと datacentre の物理ネットワークのマッピングも行われます。デフォルトでは、datacentrebr-ex ブリッジにマッピングされます。オーバークラウドの作成時にカスタムの Neutron の設定を使用していない限りは、このオプションはデフォルトのままにしてください。

非ネイティブ VLAN の使用

ネイティブ VLAN を使用しない場合には、以下のコマンドでネットワークを VLAN に割り当てます。

$ source ~/overcloudrc
$ openstack network create public --external --provider-network-type vlan --provider-physical-network datacentre --provider-segment 104
$ openstack subnet create public --network public --dhcp --allocation-pool start=10.1.1.51,end=10.1.1.250 --gateway 10.1.1.1 --subnet-range 10.1.1.0/24

provider:segmentation_id の値は、使用する VLAN を定義します。この場合は、104 を使用します。

neutron net-list により、作成したネットワークを確認します。

$ openstack network list
+-----------------------+-------------+--------------------------------------+
| id                    | name        | subnets                              |
+-----------------------+-------------+--------------------------------------+
| d474fe1f-222d-4e32... | public      | 01c5f621-1e0f-4b9d-9c30-7dc59592a52f |
+-----------------------+-------------+--------------------------------------+

7.3. 追加の Floating IP ネットワークの作成

Floating IP ネットワークは、以下の条件を満たす限りは、br-ex だけでなく、どのブリッジにも使用することができます。

  • ネットワーク環境ファイルで、NeutronExternalNetworkBridge"''" に設定されている。
  • デプロイ中に追加のブリッジをマッピングしている。たとえば、br-floating という新規ブリッジを floating という物理ネットワークにマッピングするには、以下のコマンドを実行します。

    $ openstack overcloud deploy --templates -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml -e ~/templates/network-environment.yaml --neutron-bridge-mappings datacentre:br-ex,floating:br-floating

オーバークラウドの作成後に Floating IP ネットワークを作成します。

$ openstack network create ext-net --external --provider-physical-network floating --provider-network-type vlan --provider-segment 105
$ openstack subnet create ext-subnet --network ext-net --dhcp --allocation-pool start=10.1.2.51,end=10.1.2.250 --gateway 10.1.2.1 --subnet-range 10.1.2.0/24

7.4. オーバークラウドのプロバイダーネットワークの作成

プロバイダーネットワークは、デプロイしたオーバークラウドの外部に存在するネットワークに物理的に接続されたネットワークです。これは、既存のインフラストラクチャーネットワークや、Floating IP の代わりにルーティングによって直接インスタンスに外部アクセスを提供するネットワークを使用することができます。

プロバイダーネットワークを作成する際には、ブリッジマッピングを使用する物理ネットワークに関連付けます。これは、Floating IP ネットワークの作成と同様です。コンピュートノードは、仮想マシンの仮想ネットワークインターフェースをアタッチされているネットワークインターフェースに直接接続するため、プロバイダーネットワークはコントローラーとコンピュートの両ノードに追加します。

たとえば、使用するプロバイダーネットワークが br-ex ブリッジ上の VLAN の場合には、以下のコマンドを使用してプロバイダーネットワークを VLAN 201 上に追加します。

$ openstack network create provider_network --provider-physical-network datacentre --provider-network-type vlan --provider-segment 201 --share

このコマンドにより、共有ネットワークが作成されます。また、--share と指定する代わりにテナントを指定することも可能です。そのネットワークは、指定されたテナントに対してのみ提供されます。プロバイダーネットワークを外部としてマークした場合には、そのネットワークでポートを作成できるのはオペレーターのみとなります。

Neutron が DHCP サービスをテナントのインスタンスに提供するように設定するには、プロバイダーネットワークにサブネットを追加します。

$ openstack subnet create provider-subnet --network  provider_network --dhcp --allocation-pool start=10.9.101.50,end=10.9.101.100 --gateway 10.9.101.254 --subnet-range 10.9.101.0/24

他のネットワークがプロバイダーネットワークを介して外部にアクセスする必要がある場合があります。このような場合には、新規ルーターを作成して、他のネットワークがプロバイダーネットワークを介してトラフィックをルーティングできるようにします。

$ openstack router create external
$ openstack router set --external-gateway provider_network external

このルーターに他のネットワークを接続します。たとえば、subnet1 という名前のサブネットがある場合には、以下のコマンドを実行してルーターに接続することができます。

$ openstack router add subnet external subnet1

これにより、subnet1 がルーティングテーブルに追加され、subnet1 を使用するトラフィックをプロバイダーネットワークにルーティングできるようになります。

7.5. 基本的なオーバークラウドフレーバーの作成

本ガイドの検証ステップは、インストール環境にフレーバーが含まれていることを前提としてます。まだ 1 つのフレーバーも作成していない場合には、以下のコマンドを使用してさまざまなストレージおよび処理能力に対応する基本的なデフォルトフレーバーセットを作成してください。

$ openstack flavor create m1.tiny --ram 512 --disk 0 --vcpus 1
$ openstack flavor create m1.smaller --ram 1024 --disk 0 --vcpus 1
$ openstack flavor create m1.small --ram 2048 --disk 10 --vcpus 1
$ openstack flavor create m1.medium --ram 3072 --disk 10 --vcpus 2
$ openstack flavor create m1.large --ram 8192 --disk 10 --vcpus 4
$ openstack flavor create m1.xlarge --ram 8192 --disk 10 --vcpus 8

コマンドオプション

ram
フレーバーの最大 RAM を定義するには、ram オプションを使用します。
disk
フレーバーのハードディスク容量を定義するには、disk オプションを使用します。
vcpus
フレーバーの仮想 CPU 数を定義するには、vcpus オプションを使用します。

openstack flavor create コマンドについての詳しい情報は、$ openstack flavor create --help で確認してください。

7.6. オーバークラウドの検証

オーバークラウドは、OpenStack Integration Test Suite (tempest) ツールセットを使用して、一連の統合テストを行います。本項には、統合テストの実行準備に関する情報を記載します。OpenStack Integration Test Suite の使用方法に関する詳しい説明は、『OpenStack Integration Test Suite ガイド』を参照してください。

Integration Test Suite の実行前

アンダークラウドからこのテストを実行する場合は、アンダークラウドのホストがオーバークラウドの内部 API ネットワークにアクセスできるようにします。たとえば、172.16.0.201/24 のアドレスを使用して内部 API ネットワーク (ID: 201) にアクセスするにはアンダークラウドホストに一時的な VLAN を追加します。

$ source ~/stackrc
$ sudo ovs-vsctl add-port br-ctlplane vlan201 tag=201 -- set interface vlan201 type=internal
$ sudo ip l set dev vlan201 up; sudo ip addr add 172.16.0.201/24 dev vlan201

OpenStack Validation を実行する前に、heat_stack_owner ロールがオーバークラウドに存在することを確認してください。

$ source ~/overcloudrc
$ openstack role list
+----------------------------------+------------------+
| ID                               | Name             |
+----------------------------------+------------------+
| 6226a517204846d1a26d15aae1af208f | swiftoperator    |
| 7c7eb03955e545dd86bbfeb73692738b | heat_stack_owner |
+----------------------------------+------------------+

このロールが存在しない場合は、作成します。

$ openstack role create heat_stack_owner

Integration Test Suite の実行後

検証が完了したら、オーバークラウドの内部 API への一時接続を削除します。この例では、以下のコマンドを使用して、以前にアンダークラウドで作成した VLAN を削除します。

$ source ~/stackrc
$ sudo ovs-vsctl del-port vlan201

7.7. コントローラーノードのフェンシング

フェンシングとは、クラスターとそのリソースを保護するために、ノードを分離するプロセスのことです。フェンシングがないと、異常が発生したノードが原因でクラスター内のデータが破損する可能性があります。

director は、Pacemaker を使用して、高可用性のコントローラーノードクラスターを提供します。Pacemaker は、異常が発生したノードをフェンシングするのに STONITH (Shoot-The-Other-Node-In-The-Head) というプロセスを使用します。デフォルトでは、クラスターの STONITH は無効化されているため、Pacemaker がクラスター内の各ノードの電源管理を制御できるように手動で設定する必要があります。

注記

director 上の stack ユーザーから、heat-admin ユーザーとして各ノードにログインします。オーバークラウドを作成すると自動的に stack ユーザーの SSH キーが各ノードの heat-admin にコピーされます。

pcs status コマンドで、実行中のクラスターがあることを確認します。

$ sudo pcs status
Cluster name: openstackHA
Last updated: Wed Jun 24 12:40:27 2015
Last change: Wed Jun 24 11:36:18 2015
Stack: corosync
Current DC: lb-c1a2 (2) - partition with quorum
Version: 1.1.12-a14efad
3 Nodes configured
141 Resources configured

pcs property show コマンドで、stonith が無効になっていることを確認します。

$ sudo pcs property show
Cluster Properties:
cluster-infrastructure: corosync
cluster-name: openstackHA
dc-version: 1.1.12-a14efad
have-watchdog: false
stonith-enabled: false

コントローラーノードには、director がサポートするさまざまな電源管理デバイスのフェンシングエージェントのセットが含まれます。これには、以下の項目が含まれます。

表7.1 フェンシングエージェント

デバイス

タイプ

fence_ipmilan

Intelligent Platform Management Interface (IPMI)

fence_idracfence_drac5

Dell Remote Access Controller (DRAC)

fence_ilo

Integrated Lights-Out (iLO)

fence_ucs

Cisco UCS: 詳細は、「Configuring Cisco Unified Computing System (UCS) Fencing on an OpenStack High Availability Environment」を参照してください。

fence_xvmfence_virt

libvirt および SSH

本セクションの後半部分では、例として IPMI エージェント (fence_ipmilan) を取り上げます。

Pacemaker がサポートする IPMI オプションの全一覧を表示します。

$ sudo pcs stonith describe fence_ipmilan

各ノードに、電源管理を制御するための IPMI デバイスを設定する必要があります。そのためには、各ノードの Pacemaker に stonith デバイスを追加する必要があります。クラスターで以下のコマンドを使用します。

注記

それぞれの例の 2 番目のコマンドは、ノードが自分自身のフェンシングを要求しないようにするためのものです。

コントローラーノード 0 の場合:

$ sudo pcs stonith create my-ipmilan-for-controller-0 fence_ipmilan pcmk_host_list=overcloud-controller-0 ipaddr=192.0.2.205 login=admin passwd=p@55w0rd! lanplus=1 cipher=1 op monitor interval=60s
$ sudo pcs constraint location my-ipmilan-for-controller-0 avoids overcloud-controller-0

コントローラーノード 1 の場合:

$ sudo pcs stonith create my-ipmilan-for-controller-1 fence_ipmilan pcmk_host_list=overcloud-controller-1 ipaddr=192.0.2.206 login=admin passwd=p@55w0rd! lanplus=1 cipher=1 op monitor interval=60s
$ sudo pcs constraint location my-ipmilan-for-controller-1 avoids overcloud-controller-1

コントローラーノード 2 の場合:

$ sudo pcs stonith create my-ipmilan-for-controller-2 fence_ipmilan pcmk_host_list=overcloud-controller-2 ipaddr=192.0.2.207 login=admin passwd=p@55w0rd! lanplus=1 cipher=1 op monitor interval=60s
$ sudo pcs constraint location my-ipmilan-for-controller-2 avoids overcloud-controller-2

すべての stonith リソースを表示するには、以下のコマンドを実行します。

$ sudo pcs stonith show

特定の stonith リソースを表示するには、以下のコマンドを実行します。

$ sudo pcs stonith show [stonith-name]

最後に、stonith 属性を true に設定してフェンシングを有効にします。

$ sudo pcs property set stonith-enabled=true

属性を確認します。

$ sudo pcs property show

7.8. オーバークラウド環境の変更

オーバークラウドを変更して、別機能を追加したり、操作の方法を変更したりする場合があります。オーバークラウドを変更するには、カスタムの環境ファイルと Heat テンプレートに変更を加えて、最初に作成したオーバークラウドから openstack overcloud deploy コマンドをもう 1 度実行します。たとえば、「CLI ツールを使用したオーバークラウドの作成」の方法を使用してオーバークラウドを作成した場合には、以下のコマンドを再度実行します。

$ openstack overcloud deploy --templates -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml -e ~/templates/network-environment.yaml -e ~/templates/storage-environment.yaml --control-scale 3 --compute-scale 3 --ceph-storage-scale 3 --control-flavor control --compute-flavor compute --ceph-storage-flavor ceph-storage --ntp-server pool.ntp.org --neutron-network-type vxlan --neutron-tunnel-types vxlan

director は Heat 内の overcloud スタックを確認してから、環境ファイルと Heat テンプレートのあるスタックで各アイテムを更新します。オーバークラウドは再度作成されずに、既存のオーバークラウドに変更が加えられます。

新しい環境ファイルを追加する場合は、-e オプションを使用して openstack overcloud deploy コマンドにそのファイルを追加します。以下に例を示します。

$ openstack overcloud deploy --templates -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml -e ~/templates/network-environment.yaml -e ~/templates/storage-environment.yaml -e ~/templates/new-environment.yaml --control-scale 3 --compute-scale 3 --ceph-storage-scale 3 --control-flavor control --compute-flavor compute --ceph-storage-flavor ceph-storage --ntp-server pool.ntp.org --neutron-network-type vxlan --neutron-tunnel-types vxlan

これにより、環境ファイルからの新規パラメーターやリソースがスタックに追加されます。

重要

director により後で上書きされてしまう可能性があるので、オーバークラウドの設定には手動で変更を加えないことを推奨します。

7.9. オーバークラウドへの仮想マシンのインポート

既存の OpenStack 環境があり、仮想マシンを Red Hat OpenStack Platform 環境に移行する予定がある場合には、以下の手順を使用します。

実行中のサーバーのスナップショットを作成して新規イメージを作成し、そのイメージをダウンロードします。

$ openstack server image create instance_name --name image_name
$ openstack image save image_name --file exported_vm.qcow2

エクスポートしたイメージをオーバークラウドにアップロードして、新しいインスタンスを起動します。

$ openstack image create imported_image --file exported_vm.qcow2 --disk-format qcow2 --container-format bare
$ openstack server create  imported_instance --key-name default --flavor m1.demo --image imported_image --nic net-id=net_id
重要

各仮想マシンのディスクは、既存の OpenStack 環境から新規の Red Hat OpenStack Platform にコピーする必要があります。QCOW を使用したスナップショットでは、元の階層化システムが失われます。

7.10. Ansible による自動化の実行

director を使用すると、Ansible ベースの自動化を OpenStack Platform 環境で実行することができます。director は、tripleo-ansible-inventory コマンドを使用して、環境内にノードの動的インベントリーを生成します。

重要

動的インベントリーツールには、アンダークラウドならびにデフォルトの コントローラー および コンピュート オーバークラウドノードだけが含まれます。その他のロールはサポートされていません。

ノードの動的インベントリーを表示するには、stackrc を読み込んだ後に tripleo-ansible-inventory コマンドを実行します。

$ souce ~/stackrc
$ tripleo-ansible-inventory --list

--list オプションを指定すると、全ホストの詳細が表示されます。

これにより、動的インベントリーが JSON 形式で出力されます。

{"overcloud": {"children": ["controller", "compute"], "vars": {"ansible_ssh_user": "heat-admin"}}, "controller": ["192.0.2.2"], "undercloud": {"hosts": ["localhost"], "vars": {"overcloud_horizon_url": "http://192.0.2.4:80/dashboard", "overcloud_admin_password": "abcdefghijklm12345678", "ansible_connection": "local"}}, "compute": ["192.0.2.3"]}

お使いの環境で Ansible による自動化を実行するには、-i オプションを使用して動的インベントリーツールの完全パスを指定して ansible コマンドを実行します。以下に例を示します。

ansible [HOSTS] -i /bin/tripleo-ansible-inventory [OTHER OPTIONS]
  • [HOSTS] は使用するホストの種別に置き換えます。以下に例を示します。

    • 全コントローラーノードの場合には controller
    • 全コンピュートノードの場合には compute
    • オーバークラウドの全子ノードの場合には overcloud (たとえば、コントローラー ノードおよび コンピュート ノードの場合)
    • アンダークラウドの場合には undercloud
    • 全ノードの場合には "*"
  • [OTHER OPTIONS] は追加の Ansible オプションに置き換えてください。役立つオプションには以下が含まれます。

    • --ssh-extra-args='-o StrictHostKeyChecking=no' は、ホストキーのチェックを省略します。
    • -u [USER] は、Ansible の自動化を実行する SSH ユーザーを変更します。オーバークラウドのデフォルトの SSH ユーザーは、動的インベントリーの ansible_ssh_user パラメーターで自動的に定義されます。-u オプションは、このパラメーターより優先されます。
    • -m [MODULE] は、特定の Ansible モジュールを使用します。デフォルトは command で Linux コマンドを実行します。
    • -a [MODULE_ARGS] は選択したモジュールの引数を定義します。
重要

オーバークラウドの Ansible 自動化は、標準のオーバークラウドスタックとは異なります。つまり、この後に openstack overcloud deploy コマンドを実行すると、オーバークラウドノード上の OpenStack Platform サービスに対する Ansible ベースの設定を上書きする可能性があります。

7.11. オーバークラウドの削除防止

heat stack-delete overcloud コマンドでオーバークラウドが誤って削除されるのを防ぐために、Heat には特定のアクションを制限するポリシーセットが含まれています。/etc/heat/policy.json を編集して、以下のパラメーターを探します。

"stacks:delete": "rule:deny_stack_user"

これを以下のように変更します。

"stacks:delete": "rule:deny_everybody"

ファイルを保存します。

これにより heat クライアントによるオーバークラウドの削除が阻止されます。オーバークラウドを削除できるようにするには、ポリシーを元の値に戻します。

7.12. オーバークラウドの削除

オーバークラウドはすべて、必要に応じて削除することができます。

既存のオーバークラウドを削除します。

$ openstack stack delete overcloud

director からオーバークラウドプランを削除します。

$ openstack overcloud plan delete overcloud

オーバークラウドが削除されていることを確認します。

$ openstack stack list

削除には、数分かかります。

削除が完了したら、デプロイメントシナリオの標準ステップに従って、オーバークラウドを再度作成します。