Red Hat Training
A Red Hat training course is available for Red Hat OpenStack Platform
第8章 オーバークラウド作成後のタスクの実行
本章では、任意のオーバークラウドを作成後に実行するタスクについて考察します。
8.1. オーバークラウドのテナントネットワークの作成
オーバークラウドには、インスタンス用のテナントネットワークが必要です。source コマンドで overcloud
を読み込んで、Neutron で初期テナントネットワークを作成します。以下に例を示します。
$ source ~/overcloudrc $ neutron net-create default $ neutron subnet-create --name default --gateway 172.20.1.1 default 172.20.0.0/16
上記のステップにより、default
という名前の基本的な Neutron ネットワークが作成されます。オーバークラウドは、内部 DHCP メカニズムを使用したこのネットワークから、IP アドレスを自動的に割り当てます。
neutron net-list
で作成したネットワークを確認します。
$ neutron net-list +-----------------------+-------------+----------------------------------------------------+ | id | name | subnets | +-----------------------+-------------+----------------------------------------------------+ | 95fadaa1-5dda-4777... | default | 7e060813-35c5-462c-a56a-1c6f8f4f332f 172.20.0.0/16 | +-----------------------+-------------+----------------------------------------------------+
8.2. オーバークラウドの外部ネットワークの作成
先ほど 「ネットワークの分離」 で外部ネットワークに使用するノードインターフェースを設定しましたが、インスタンスに Floating IP を割り当てることができるように、オーバークラウドでこのネットワークを作成する必要があります。
ネイティブ VLAN の使用
以下の手順では、外部ネットワーク向けの専用インターフェースまたはネイティブの VLAN が設定されていることが前提です。
source コマンドで overcloud
を読み込み、Neutron で外部ネットワークを作成します。以下に例を示します。
$ source ~/overcloudrc $ neutron net-create public --router:external --provider:network_type flat --provider:physical_network datacentre $ neutron subnet-create --name public --enable_dhcp=False --allocation-pool=start=10.1.1.51,end=10.1.1.250 --gateway=10.1.1.1 public 10.1.1.0/24
以下の例では、public
という名前のネットワークを作成します。オーバークラウドには、デフォルトの Floating IP プールにこの特定の名前が必要です。このネットワークは、「オーバークラウドの検証」の検証テストでも重要となります。
このコマンドにより、ネットワークと datacentre
の物理ネットワークのマッピングも行われます。デフォルトでは、datacentre
は br-ex
ブリッジにマッピングされます。オーバークラウドの作成時にカスタムの Neutron の設定を使用していない限りは、このオプションはデフォルトのままにしてください。
非ネイティブ VLAN の使用
ネイティブ VLAN を使用しない場合には、以下のコマンドでネットワークを VLAN に割り当てます。
$ source ~/overcloudrc $ neutron net-create public --router:external --provider:network_type vlan --provider:physical_network datacentre --provider:segmentation_id 104 $ neutron subnet-create --name public --enable_dhcp=False --allocation-pool=start=10.1.1.51,end=10.1.1.250 --gateway=10.1.1.1 public 10.1.1.0/24
provider:segmentation_id
の値は、使用する VLAN を定義します。この場合は、104 を使用します。
neutron net-list
で作成したネットワークを確認します。
$ neutron net-list +-----------------------+-------------+---------------------------------------------------+ | id | name | subnets | +-----------------------+-------------+---------------------------------------------------+ | d474fe1f-222d-4e32... | public | 01c5f621-1e0f-4b9d-9c30-7dc59592a52f 10.1.1.0/24 | +-----------------------+-------------+---------------------------------------------------+
8.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 ネットワークを作成します。
$ neutron net-create ext-net --router:external --provider:physical_network floating --provider:network_type vlan --provider:segmentation_id 105 $ neutron subnet-create --name ext-subnet --enable_dhcp=False --allocation-pool start=10.1.2.51,end=10.1.2.250 --gateway 10.1.2.1 ext-net 10.1.2.0/24
8.4. オーバークラウドのプロバイダーネットワークの作成
プロバイダーネットワークは、デプロイしたオーバークラウドの外部に存在するネットワークに物理的に接続されたネットワークです。これは、既存のインフラストラクチャーネットワークや、Floating IP の代わりにルーティングによって直接インスタンスに外部アクセスを提供するネットワークを使用することができます。
プロバイダーネットワークを作成する際には、ブリッジマッピングを使用する物理ネットワークに関連付けます。これは、Floating IP ネットワークの作成と同様です。コンピュートノードは、仮想マシンの仮想ネットワークインターフェースをアタッチされているネットワークインターフェースに直接接続するため、プロバイダーネットワークはコントローラーとコンピュートの両ノードに追加します。
たとえば、使用するプロバイダーネットワークが br-ex ブリッジ上の VLAN の場合には、以下のコマンドを使用してプロバイダーネットワークを VLAN 201 上に追加します。
$ neutron net-create --provider:physical_network datacentre --provider:network_type vlan --provider:segmentation_id 201 --shared provider_network
このコマンドにより、共有ネットワークが作成されます。また、「--shared」と指定する代わりにテナントを指定することも可能です。そのネットワークは、指定されたテナントに対してのみ提供されます。プロバイダーネットワークを外部としてマークした場合には、そのネットワークでポートを作成できるのはオペレーターのみとなります。
Neutron が DHCP サービスをテナントのインスタンスに提供するように設定するには、プロバイダーネットワークにサブネットを追加します。
$ neutron subnet-create --name provider-subnet --enable_dhcp=True --allocation-pool start=10.9.101.50,end=10.9.101.100 --gateway 10.9.101.254 provider_network 10.9.101.0/24
他のネットワークがプロバイダーネットワークを介して外部にアクセスする必要がある場合があります。このような場合には、新規ルーターを作成して、他のネットワークがプロバイダーネットワークを介してトラフィックをルーティングできるようにします。
$ neutron router-create external $ neutron router-gateway-set external provider_network
このルーターに他のネットワークを接続します。たとえば、subnet1
という名前のサブネットがある場合には、以下のコマンドを実行してルーターに接続することができます。
$ neutron router-interface-add external subnet1
これにより、subnet1
がルーティングテーブルに追加され、subnet1
を使用するトラフィックをプロバイダーネットワークにルーティングできるようになります。
8.5. オーバークラウドの検証
オーバークラウドは、Tempest を使用して一連の統合テストを実行します。以下の手順では、Tempest を使用してオーバークラウドを検証する方法を説明します。アンダークラウドからこのテストを実行する場合は、アンダークラウドのホストがオーバークラウドの内部 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
Tempest を実行する前に、heat_stack_owner
ロールがオーバークラウドに存在することを確認してください。
$ source ~/overcloudrc $ openstack role list +----------------------------------+------------------+ | ID | Name | +----------------------------------+------------------+ | 6226a517204846d1a26d15aae1af208f | swiftoperator | | 7c7eb03955e545dd86bbfeb73692738b | heat_stack_owner | +----------------------------------+------------------+
このロールが存在しない場合は、作成します。
$ keystone role-create --name heat_stack_owner
Tempest ツールセットのインストール
$ sudo yum install openstack-tempest
stack
ユーザーのホームディレクトリーに tempest
ディレクトリーを設定して、Tempest スイートをローカルにコピーします。
$ mkdir ~/tempest $ cd ~/tempest $ /usr/share/openstack-tempest-10.0.0/tools/configure-tempest-directory
上記のコマンドにより、Tempest ツールセットのローカルバージョンが作成されます。
オーバークラウドの作成プロセスが完了した後には、director により ~/tempest-deployer-input.conf
というファイルが作成されます。このファイルは、オーバークラウドに関連する Tempest の設定オプションを提供します。このファイルを使用して Tempest を設定するには、以下のコマンドを実行します。
$ tools/config_tempest.py --deployer-input ~/tempest-deployer-input.conf --debug --create identity.uri $OS_AUTH_URL identity.admin_password $OS_PASSWORD --network-id d474fe1f-222d-4e32-9242-cd1fefe9c14b
$OS_AUTH_URL
および $OS_PASSWORD
の環境変数は、以前にソースとして使用した overcloudrc
ファイルの値セットを使用します。--network-id
は「オーバークラウドの外部ネットワークの作成」で作成した外部ネットワークの UUID です。
設定スクリプトにより、Tempest テスト用に Cirros イメージをダウンロードします。director にはインターネットアクセスがあり、インターネットへのアクセスのあるプロキシーが使用されるようにしてください。http_proxy
の環境変数を設定して、コマンドラインの操作にプロキシーを使用します。
以下のコマンドを使用して、Tempest テストの全スイートを実行します。
$ tools/run-tests.sh
完全な Tempest テストスイートには、数時間かかる場合があります。代わりに、'.*smoke'
オプションを使用してテストの一部を実行します。
$ tools/run-tests.sh '.*smoke'
各テストはオーバークラウドに対して実行され、次の出力で各テストとその結果が表示されます。同じディレクトリーで生成された tempest.log
ファイルで、各テストの詳しい情報を確認することができます。たとえば、出力で以下のように失敗したテストについて表示される場合があります。
{2} tempest.api.compute.servers.test_servers.ServersTestJSON.test_create_specify_keypair [18.305114s] ... FAILED
これは、詳細情報が含まれるログのエントリーと一致します。コロンで区切られたテストの名前空間の最後の 2 つに関するログを検索します。この例では、ログで ServersTestJSON:test_create_specify_keypair
を検索します。
$ grep "ServersTestJSON:test_create_specify_keypair" tempest.log -A 4 2016-03-17 14:49:31.123 10999 INFO tempest_lib.common.rest_client [req-a7a29a52-0a52-4232-9b57-c4f953280e2c ] Request (ServersTestJSON:test_create_specify_keypair): 500 POST http://192.168.201.69:8774/v2/2f8bef15b284456ba58d7b149935cbc8/os-keypairs 4.331s 2016-03-17 14:49:31.123 10999 DEBUG tempest_lib.common.rest_client [req-a7a29a52-0a52-4232-9b57-c4f953280e2c ] Request - Headers: {'Content-Type': 'application/json', 'Accept': 'application/json', 'X-Auth-Token': '<omitted>'} Body: {"keypair": {"name": "tempest-key-722237471"}} Response - Headers: {'status': '500', 'content-length': '128', 'x-compute-request-id': 'req-a7a29a52-0a52-4232-9b57-c4f953280e2c', 'connection': 'close', 'date': 'Thu, 17 Mar 2016 04:49:31 GMT', 'content-type': 'application/json; charset=UTF-8'} Body: {"computeFault": {"message": "The server has either erred or is incapable of performing the requested operation.", "code": 500}} _log_request_full /usr/lib/python2.7/site-packages/tempest_lib/common/rest_client.py:414
-A 4
オプションを指定すると次の 4 行が表示されます。この 4 行には、通常要求ヘッダーとボディー、応答ヘッダーとボディーが含まれます。
検証が完了したら、オーバークラウドの内部 API への一時接続を削除します。この例では、以下のコマンドを使用して、以前にアンダークラウドで作成した VLAN を削除します。
$ source ~/stackrc $ sudo ovs-vsctl del-port vlan201
8.6. コントローラーノードのフェンシング
フェンシングとは、クラスターとそのリソースを保護するためにノードを分離するプロセスのことです。フェンシングがないと、問題のあるノードが原因でクラスター内のデータが破損する可能性があります。
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 がサポートするさまざまな電源管理デバイス用のフェンシングエージェントのセットが実装されています。これには、以下が含まれます。
表8.1 フェンスエージェント
デバイス |
タイプ |
|
Intelligent Platform Management Interface (IPMI) |
|
Dell Remote Access Controller (DRAC) |
|
Integrated Lights-Out (iLO) |
|
Cisco UCS: 詳しい情報は 「Configuring Cisco Unified Computing System (UCS) Fencing on an OpenStack High Availability Environment」 の記事を参照してください。 |
|
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
8.7. オーバークラウド環境の変更
オーバークラウドを変更して、別機能を追加したり、操作の方法を変更したりする場合があります。オーバークラウドを変更するには、カスタムの環境ファイルと Heat テンプレートに変更を加えて、最初に作成したオーバークラウドから openstack overcloud deploy
コマンドをもう 1 度実行します。たとえば、「7章オーバークラウドの作成」の方法を使用してオーバークラウドを作成した場合には、以下のコマンドを再度実行します。
$ 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
director は Heat 内の overcloud
スタックを確認してから、環境ファイルと Heat テンプレートのあるスタックで各アイテムを更新します。オーバークラウドは再度作成されずに、既存のオーバークラウドに変更が加えられます。
新規環境ファイルを追加する場合には、openstack overcloud deploy
コマンドで -e
オプションを使用して そのファイルを追加します。以下に例を示します。
$ 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
これにより、環境ファイルからの新規パラメーターやリソースがスタックに追加されます。
director により後で上書きされてしまう可能性があるので、オーバークラウドの設定には手動で変更を加えないことを推奨します。
8.8. オーバークラウドへの仮想マシンのインポート
既存の OpenStack 環境があり、仮想マシンを Red Hat OpenStack Platform 環境に移行する予定がある場合には、以下の手順を使用します。
実行中のサーバーのスナップショットを作成して新規イメージを作成し、そのイメージをダウンロードします。
$ nova image-create instance_name image_name $ glance image-download image_name --file exported_vm.qcow2
エクスポートしたイメージをオーバークラウドにアップロードして、新規インスタンスを起動します。
$ glance image-create --name imported_image --file exported_vm.qcow2 --disk-format qcow2 --container-format bare $ nova boot --poll --key-name default --flavor m1.demo --image imported_image --nic net-id=net_id imported
各仮想マシンのディスクは、既存の OpenStack 環境から新規の Red Hat OpenStack Platform にコピーする必要があります。QCOW を使用したスナップショットでは、元の階層化システムが失われます。
8.9. オーバークラウドのコンピュートノードからの仮想マシンの移行
オーバークラウドのコンピュートノードでメンテナンスを行う場合があります。ダウンタイムを防ぐには、以下の手順に従ってそのコンピュートノード上の仮想マシンを同じオーバークラウド内の別のコンピュートノードに移行します。
director は全コンピュートノードがセキュアな移行を提供するように設定します。移行プロセス中に、各ホストの nova
ユーザーが他のコンピュートノードにアクセスできるようにするための共有 SSH キーも全コンピュートノードに必要です。director はこのキーを自動的に作成します。
Red Hat OpenStack Platform 9 の最新の更新には、ライブマイグレーションの機能に必要なパッチが含まれています。初期リリースでは、director のコアテンプレートコレクションにこの機能は含まれていませんでしたが、openstack-tripleo-heat-templates-2.0.0-57.el7ost
パッケージ以降のバージョンで含まれるようになりました。
環境を更新して、openstack-tripleo-heat-templates-2.0.0-57.el7ost
以降のパッケージの Heat テンプレートを使用するようにします。
詳しくは、「Red Hat OpenStack Platform director (TripleO) CVE-2017-2637 bug and Red Hat OpenStack Platform」を参照してください。
インスタンスを移行するには、overcloudrc
を読み込んで、現在の nova サービスの一覧を取得します。
$ source ~/stack/overcloudrc $ nova service-list
移行予定のノードで nova-compute
サービスを無効にします。
$ nova service-disable [hostname] nova-compute
これにより、新規インスタンスはそのノード上でスケジュールされないようになります。
ノードからのインスタンスの移行プロセスを開始します。以下のコマンドは、単一のインスタンスを移行します。
$ openstack server migrate [server-name]
無効になったコンピュートノードから移行する必要のあるインスタンスごとにこのコマンドを実行します。
移行プロセスの現況は、以下のコマンドで取得できます。
$ nova migration-list
各インスタンスの移行が完了したら、nova の状態は VERIFY_RESIZE
に変わります。ここで、移行を正常に完了するか、環境をロールバックするかを確定する機会が提供されます。移行を確定するには、以下のコマンドを使用してください。
$ nova resize-confirm [server-name]
ステータスが VERIFY_RESIZE
のインスタンスごとに、このコマンドを実行します。
これにより、ホストからすべてのインスタンスが移行されます。インスタンスのダウンタイムなしにホスト上のメンテナンスを実行できるようになります。ホストを有効な状態に戻すには、以下のコマンドを実行します。
$ nova service-enable [hostname] nova-compute
8.10. オーバークラウドが削除されてないように保護
heat stack-delete overcloud
コマンドで誤って削除されないように、Heat には特定のアクションを制限するポリシーセットが含まれます。/etc/heat/policy.json
を開いて、以下のパラメーターを検索します。
"stacks:delete": "rule:deny_stack_user"
このパラメーターの設定を以下のように変更します。
"stacks:delete": "rule:deny_everybody"
ファイルを保存します。
これにより heat
クライアントでオーバークラウドが削除されないようにします。オーバークラウドを削除できるように設定するには、ポリシーを元の値に戻します。
8.11. オーバークラウドの削除
オーバークラウドはすべて、必要に応じて削除することができます。
既存のオーバークラウドを削除します。
$ heat stack-delete overcloud
オーバークラウドが削除されていることを確認します。
$ heat stack-list
削除には、数分かかります。
削除が完了したら、デプロイメントシナリオの標準ステップに従って、オーバークラウドを再度作成します。