Red Hat Training
A Red Hat training course is available for Red Hat OpenStack Platform
第9章 オーバークラウド作成後のタスクの実行
本章では、任意のオーバークラウドを作成後に実行するタスクについて考察します。
9.1. オーバークラウドデプロイメントステータスの確認
オーバークラウドのデプロイメントステータスを確認するには、openstack overcloud status
コマンドを使用します。このコマンドの出力に、全デプロイメントステップの結果が表示されます。
手順
source コマンドで
stackrc
ファイルを読み込みます。$ source ~/stackrc
デプロイメントステータスの確認コマンドを実行します。
$ openstack overcloud status
このコマンドの出力に、ステータスが表示されます。
+-----------+---------------------+---------------------+-------------------+ | Plan Name | Created | Updated | Deployment Status | +-----------+---------------------+---------------------+-------------------+ | overcloud | 2018-05-03 21:24:50 | 2018-05-03 21:27:59 | DEPLOY_SUCCESS | +-----------+---------------------+---------------------+-------------------+
ご自分のオーバークラウドに別の名前が使用されている場合には、
--plan
引数を使用してその名前のオーバークラウドを選択します。$ openstack overcloud status --plan my-deployment
9.2. コンテナー化されたサービスの管理
OpenStack Platform では、アンダークラウドおよびオーバークラウドノード上のコンテナー内でサービスが実行されます。特定の状況では、1 つのホスト上で個別のサービスを制御しなければならない場合があります。本項では、コンテナー化されたサービスを管理するためにノード上で実行できる、一般的な docker
コマンドについて説明します。docker
を使用したコンテナー管理に関する包括的な情報は、『Getting Started with Containers』の「Working with Docker formatted containers」を参照してください。
コンテナーとイメージの一覧表示
実行中のコンテナーを一覧表示するには、以下のコマンドを実行します。
$ sudo docker ps
停止中またはエラーの発生したコンテナーも一覧表示するには、コマンドに --all
オプションを追加します。
$ sudo docker ps --all
コンテナーイメージを一覧表示するには、以下のコマンドを実行します。
$ sudo docker images
コンテナーのプロパティーの確認
コンテナーまたはコンテナーイメージのプロパティーを確認するには、docker inspect
コマンドを使用します。たとえば、keystone
コンテナーを確認するには、以下のコマンドを実行します。
$ sudo docker inspect keystone
基本的なコンテナー操作の管理
コンテナー化されたサービスを再起動するには、docker restart
コマンドを使用します。たとえば、keystone
コンテナーを再起動するには、以下のコマンドを実行します。
$ sudo docker restart keystone
コンテナー化されたサービスを停止するには、docker stop
コマンドを使用します。たとえば、keystone
のコンテナーを停止するには、以下のコマンドを実行します。
$ sudo docker stop keystone
停止されているコンテナー化されたサービスを起動するには、docker start
コマンドを使用します。たとえば、keystone
のコンテナーを起動するには、以下のコマンドを実行します。
$ sudo docker start keystone
コンテナー内のサービス設定ファイルに加えた変更は、コンテナーの再起動後には元に戻ります。これは、コンテナーがノードのローカルファイルシステム上の /var/lib/config-data/puppet-generated/
にあるファイルに基づいてサービス設定を再生成するためです。たとえば、keystone
コンテナー内の /etc/keystone/keystone.conf
を編集してコンテナーを再起動すると、そのコンテナーはノードのローカルシステム上にある /var/lib/config-data/puppet-generated/keystone/etc/keystone/keystone.conf
を使用して設定を再生成します。再起動前にコンテナー内で加えられた変更は、この設定によって上書きされます。
コンテナーのモニター
コンテナー化されたサービスのログを確認するには、docker logs
コマンドを使用します。たとえば、keystone
のログを確認するには、以下のコマンドを実行します。
$ sudo docker logs keystone
コンテナーへのアクセス
コンテナー化されたサービスのシェルに入るには、docker exec
コマンドを使用して /bin/bash
を起動します。たとえば、keystone
コンテナーのシェルに入るには、以下のコマンドを実行します。
$ sudo docker exec -it keystone /bin/bash
keystone
コンテナーのシェルに root ユーザーとして入るには、以下のコマンドを実行します。
$ sudo docker exec --user 0 -it <NAME OR ID> /bin/bash
コンテナーから出るには、以下のコマンドを実行します。
# exit
アンダークラウドおよびオーバークラウド上での swift-ring-builder の有効化
Object Storage (swift) ビルドの持続性を考慮し、swift-ring-builder
および swift_object_server
コマンドはアンダークラウドおよびオーバークラウドノードに含まれなくなりました。ただし、コマンドは引き続きコンテナーで使用することができます。それぞれのコンテナー内でこれらのコマンドを実行するには、以下のコマンドを実行します。
docker exec -ti -u swift swift_object_server swift-ring-builder /etc/swift/object.builder
これらのコマンドが必要な場合には、アンダークラウドでは stack
ユーザーとして、オーバークラウドでは heat-admin
ユーザーとして、以下のパッケージをインストールします。
sudo yum install -y python-swift sudo yum install -y python2-swiftclient
OpenStack Platform のコンテナー化されたサービスのトラブルシューティングに関する情報は、「コンテナー化されたサービスのエラー」を参照してください。
9.3. オーバークラウドのテナントネットワークの作成
オーバークラウドには、インスタンス用のテナントネットワークが必要です。source コマンドで overcloud
を読み込んで、Neutron で初期テナントネットワークを作成します。以下に例を示します。
$ source ~/overcloudrc (overcloud) $ openstack network create default (overcloud) $ openstack subnet create default --network default --gateway 172.20.1.1 --subnet-range 172.20.0.0/16
上記のステップにより、default
という名前の基本的な Neutron ネットワークが作成されます。オーバークラウドは、内部 DHCP メカニズムを使用したこのネットワークから、IP アドレスを自動的に割り当てます。
作成したネットワークを確認します。
(overcloud) $ openstack network list +-----------------------+-------------+--------------------------------------+ | id | name | subnets | +-----------------------+-------------+--------------------------------------+ | 95fadaa1-5dda-4777... | default | 7e060813-35c5-462c-a56a-1c6f8f4f332f | +-----------------------+-------------+--------------------------------------+
9.4. オーバークラウドの外部ネットワークの作成
インスタンスに Floating IP を割り当てることができるように、オーバークラウドで外部ネットワークを作成する必要があります。
ネイティブ VLAN の使用
以下の手順では、外部ネットワーク向けの専用インターフェースまたはネイティブの VLAN が設定されていることが前提です。
source コマンドで overcloud
を読み込み、Neutron で外部ネットワークを作成します。以下に例を示します。
$ source ~/overcloudrc (overcloud) $ openstack network create public --external --provider-network-type flat --provider-physical-network datacentre (overcloud) $ 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
の物理ネットワークのマッピングも行われます。デフォルトでは、datacentre
は br-ex
ブリッジにマッピングされます。オーバークラウドの作成時にカスタムの Neutron の設定を使用していない限りは、このオプションはデフォルトのままにしてください。
非ネイティブ VLAN の使用
ネイティブ VLAN を使用しない場合には、以下のコマンドでネットワークを VLAN に割り当てます。
$ source ~/overcloudrc (overcloud) $ openstack network create public --external --provider-network-type vlan --provider-physical-network datacentre --provider-segment 104 (overcloud) $ 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 を使用します。
作成したネットワークを確認します。
(overcloud) $ openstack network list +-----------------------+-------------+--------------------------------------+ | id | name | subnets | +-----------------------+-------------+--------------------------------------+ | d474fe1f-222d-4e32... | public | 01c5f621-1e0f-4b9d-9c30-7dc59592a52f | +-----------------------+-------------+--------------------------------------+
9.5. 追加の Floating IP ネットワークの作成
Floating IP ネットワークは、以下の条件を満たす限りは、br-ex
だけでなく、どのブリッジにも使用することができます。
-
ネットワーク環境ファイルで、
NeutronExternalNetworkBridge
が"''"
に設定されている。 デプロイ中に追加のブリッジをマッピングしている。たとえば、
br-floating
という新規ブリッジをfloating
という物理ネットワークにマッピングするには、環境ファイルで以下の設定を使用します。parameter_defaults: NeutronBridgeMappings: "datacentre:br-ex,floating:br-floating"
オーバークラウドの作成後に Floating IP ネットワークを作成します。
$ source ~/overcloudrc (overcloud) $ openstack network create ext-net --external --provider-physical-network floating --provider-network-type vlan --provider-segment 105 (overcloud) $ 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
9.6. オーバークラウドのプロバイダーネットワークの作成
プロバイダーネットワークは、デプロイしたオーバークラウドの外部に存在するネットワークに物理的に接続されたネットワークです。これは、既存のインフラストラクチャーネットワークや、Floating IP の代わりにルーティングによって直接インスタンスに外部アクセスを提供するネットワークを使用することができます。
プロバイダーネットワークを作成する際には、ブリッジマッピングを使用する物理ネットワークに関連付けます。これは、Floating IP ネットワークの作成と同様です。コンピュートノードは、仮想マシンの仮想ネットワークインターフェースをアタッチされているネットワークインターフェースに直接接続するため、プロバイダーネットワークはコントローラーとコンピュートの両ノードに追加します。
たとえば、使用するプロバイダーネットワークが br-ex ブリッジ上の VLAN の場合には、以下のコマンドを使用してプロバイダーネットワークを VLAN 201 上に追加します。
$ source ~/overcloudrc (overcloud) $ openstack network create provider_network --provider-physical-network datacentre --provider-network-type vlan --provider-segment 201 --share
このコマンドにより、共有ネットワークが作成されます。また、--share
と指定する代わりにテナントを指定することも可能です。そのネットワークは、指定されたテナントに対してのみ提供されます。プロバイダーネットワークを外部としてマークした場合には、そのネットワークでポートを作成できるのはオペレーターのみとなります。
Neutron が DHCP サービスをテナントのインスタンスに提供するように設定するには、プロバイダーネットワークにサブネットを追加します。
(overcloud) $ 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
他のネットワークがプロバイダーネットワークを介して外部にアクセスする必要がある場合があります。このような場合には、新規ルーターを作成して、他のネットワークがプロバイダーネットワークを介してトラフィックをルーティングできるようにします。
(overcloud) $ openstack router create external (overcloud) $ openstack router set --external-gateway provider_network external
このルーターに他のネットワークを接続します。たとえば、subnet1
という名前のサブネットがある場合には、以下のコマンドを実行してルーターに接続することができます。
(overcloud) $ openstack router add subnet external subnet1
これにより、subnet1
がルーティングテーブルに追加され、subnet1
を使用するトラフィックをプロバイダーネットワークにルーティングできるようになります。
9.7. 基本的なオーバークラウドフレーバーの作成
本ガイドの検証ステップは、インストール環境にフレーバーが含まれていることを前提としてます。まだ 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
で確認してください。
9.8. オーバークラウドの検証
オーバークラウドは、OpenStack Integration Test Suite (tempest) ツールセットを使用して、一連の統合テストを行います。本項には、統合テストの実行準備に関する情報を記載します。OpenStack Integration Test Suite の使用方法に関する詳しい説明は、『OpenStack Integration Test Suite Guide』を参照してください。
Integration Test Suite の実行前
アンダークラウドからこのテストを実行する場合は、アンダークラウドのホストがオーバークラウドの内部 API ネットワークにアクセスできるようにします。たとえば、172.16.0.201/24 のアドレスを使用して内部 API ネットワーク (ID: 201) にアクセスするにはアンダークラウドホストに一時的な VLAN を追加します。
$ source ~/stackrc (undercloud) $ sudo ovs-vsctl add-port br-ctlplane vlan201 tag=201 -- set interface vlan201 type=internal (undercloud) $ sudo ip l set dev vlan201 up; sudo ip addr add 172.16.0.201/24 dev vlan201
OpenStack Integration Test Suite を実行する前に、heat_stack_owner
ロールがオーバークラウドに存在することを確認してください。
$ source ~/overcloudrc (overcloud) $ openstack role list +----------------------------------+------------------+ | ID | Name | +----------------------------------+------------------+ | 6226a517204846d1a26d15aae1af208f | swiftoperator | | 7c7eb03955e545dd86bbfeb73692738b | heat_stack_owner | +----------------------------------+------------------+
このロールが存在しない場合は、作成します。
(overcloud) $ openstack role create heat_stack_owner
Integration Test Suite の実行後
検証が完了したら、オーバークラウドの内部 API への一時接続を削除します。この例では、以下のコマンドを使用して、以前にアンダークラウドで作成した VLAN を削除します。
$ source ~/stackrc (undercloud) $ sudo ovs-vsctl del-port vlan201
9.9. オーバークラウド環境の変更
オーバークラウドを変更して、別機能を追加したり、操作の方法を変更したりする場合があります。オーバークラウドを変更するには、カスタムの環境ファイルと Heat テンプレートに変更を加えて、最初に作成したオーバークラウドから openstack overcloud deploy
コマンドをもう 1 度実行します。たとえば、「デプロイメントコマンド」の方法を使用してオーバークラウドを作成した場合には、以下のコマンドを再度実行します。
$ source ~/stackrc (undercloud) $ openstack overcloud deploy --templates \ -e ~/templates/node-info.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \ -e ~/templates/network-environment.yaml \ -e ~/templates/storage-environment.yaml \ --ntp-server pool.ntp.org
director は Heat 内の overcloud
スタックを確認してから、環境ファイルと Heat テンプレートのあるスタックで各アイテムを更新します。オーバークラウドは再度作成されずに、既存のオーバークラウドに変更が加えられます。
新規環境ファイルを追加する場合には、openstack overcloud deploy
コマンドで -e
オプションを使用して そのファイルを追加します。以下に例を示します。
$ source ~/stackrc (undercloud) $ openstack overcloud deploy --templates \ -e ~/templates/new-environment.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \ -e ~/templates/network-environment.yaml \ -e ~/templates/storage-environment.yaml \ -e ~/templates/node-info.yaml \ --ntp-server pool.ntp.org
これにより、環境ファイルからの新規パラメーターやリソースがスタックに追加されます。
director により後で上書きされてしまう可能性があるので、オーバークラウドの設定には手動で変更を加えないことを推奨します。
9.10. 動的インベントリースクリプトの実行
director を使用すると、Ansible ベースの自動化を OpenStack Platform 環境で実行することができます。director は、tripleo-ansible-inventory
コマンドを使用して、環境内にノードの動的インベントリーを生成します。
手順
ノードの動的インベントリーを表示するには、
stackrc
を読み込んだ後にtripleo-ansible-inventory
コマンドを実行します。$ source ~/stackrc (undercloud) $ tripleo-ansible-inventory --list
--list
オプションを指定すると、全ホストの詳細が表示されます。これにより、動的インベントリーが JSON 形式で出力されます。{"overcloud": {"children": ["controller", "compute"], "vars": {"ansible_ssh_user": "heat-admin"}}, "controller": ["192.168.24.2"], "undercloud": {"hosts": ["localhost"], "vars": {"overcloud_horizon_url": "http://192.168.24.4:80/dashboard", "overcloud_admin_password": "abcdefghijklm12345678", "ansible_connection": "local"}}, "compute": ["192.168.24.3"]}
お使いの環境で Ansible のプレイブックを実行するには、
ansible
コマンドを実行し、-i
オプションを使用して動的インベントリーツールの完全パスを追加します。以下に例を示します。(undercloud) $ ansible [HOSTS] -i /bin/tripleo-ansible-inventory [OTHER OPTIONS]
[HOSTS]
は使用するホストの種別に置き換えます。以下に例を示します。-
全コントローラーノードの場合には
controller
-
全コンピュートノードの場合には
compute
-
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 ベースの設定を上書きする可能性があります。
9.11. オーバークラウドへの仮想マシンのインポート
既存の OpenStack 環境があり、仮想マシンを Red Hat OpenStack Platform 環境に移行する予定がある場合には、以下の手順を使用します。
実行中のサーバーのスナップショットを作成して新規イメージを作成し、そのイメージをダウンロードします。
$ source ~/overcloudrc (overcloud) $ openstack server image create instance_name --name image_name (overcloud) $ openstack image save image_name --file exported_vm.qcow2
エクスポートしたイメージをオーバークラウドにアップロードして、新しいインスタンスを起動します。
(overcloud) $ openstack image create imported_image --file exported_vm.qcow2 --disk-format qcow2 --container-format bare (overcloud) $ 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 を使用したスナップショットでは、元の階層化システムが失われます。
9.12. コンピュートノードからのインスタンスの移行
オーバークラウドのコンピュートノードでメンテナンスを行う場合があります。ダウンタイムを防ぐには、そのコンピュートノード上の仮想マシンを同じオーバークラウド内の別のコンピュートノードに移行します。
director は、すべてのコンピュートノードがセキュアな移行を提供するように設定します。全コンピュートノードには、各ホストの nova
ユーザーが移行プロセス中に他のコンピュートノードにアクセスすることができるようにするための共有 SSH キーも必要です。director は、OS::TripleO::Services::NovaCompute
コンポーザブルサービスを使用してこのキーを作成します。このコンポーザブルサービスは、全コンピュートロールにデフォルトで含まれているメインのサービスの 1 つです (『オーバークラウドの高度なカスタマイズ』の「コンポーザブルサービスとカスタムロール」を参照)。
手順
アンダークラウドから、コンピュートノードを選択し、そのノードを無効にします。
$ source ~/overcloudrc (overcloud) $ openstack compute service list (overcloud) $ openstack compute service set [hostname] nova-compute --disable
コンピュートノード上の全インスタンスを一覧表示します。
(overcloud) $ openstack server list --host [hostname] --all-projects
以下のコマンドの 1 つを使用して、インスタンスを移行します。
選択した特定のホストにインスタンスを移行します。
(overcloud) $ openstack server migrate [instance-id] --live [target-host]--wait
nova-scheduler
により対象のホストが自動的に選択されるようにします。(overcloud) $ nova live-migration [instance-id]
一度にすべてのインスタンスのライブマイグレーションを行います。
$ nova host-evacuate-live [hostname]
注記nova
コマンドで非推奨の警告が表示される可能性がありますが、安全に無視することができます。
- 移行が完了するまで待ちます。
正常に移行したことを確認します。
(overcloud) $ openstack server list --host [hostname] --all-projects
- 選択したコンピュートノードのインスタンスがなくなるまで、移行を続けます。
これにより、コンピュートノードからすべてのインスタンスが移行されます。インスタンスのダウンタイムなしにノードでメンテナンスを実行できるようになります。コンピュートノードを有効な状態に戻すには、以下のコマンドを実行します。
$ source ~/overcloudrc (overcloud) $ openstack compute service set [hostname] nova-compute --enable
9.13. オーバークラウドの削除防止
heat stack-delete overcloud
コマンドで誤って削除されないように、Heat には特定のアクションを制限するポリシーセットが含まれます。/etc/heat/policy.json
を開いて、以下のパラメーターを検索します。
"stacks:delete": "rule:deny_stack_user"
このパラメーターの設定を以下のように変更します。
"stacks:delete": "rule:deny_everybody"
ファイルを保存します。
これにより heat
クライアントでオーバークラウドが削除されないように阻止されます。オーバークラウドを削除できるように設定するには、ポリシーを元の値に戻します。
9.14. オーバークラウドの削除
オーバークラウドはすべて、必要に応じて削除することができます。
既存のオーバークラウドを削除します。
$ source ~/stackrc (undercloud) $ openstack overcloud delete overcloud
オーバークラウドが削除されていることを確認します。
(undercloud) $ openstack stack list
削除には、数分かかります。
削除が完了したら、デプロイメントシナリオの標準ステップに従って、オーバークラウドを再度作成します。
9.15. トークンのフラッシュ間隔の確認
Identity サービス (keystone) は、他の OpenStack サービスに対するアクセス制御にトークンベースのシステムを使用します。ある程度の期間が過ぎた後には、データベースに未使用のトークンが多数蓄積されます。デフォルトの cronjob は毎日トークンをフラッシュします。環境をモニタリングして、必要に応じてトークンのフラッシュ間隔を調節することを推奨します。
オーバークラウドでは、KeystoneCronToken
の値を使用して間隔を調整することができます。詳しい情報は、『オーバークラウドのパラメーター』を参照してください。