アンダークラウドは、Red Hat OpenStack Platform director ツールセットが含まれる主要管理ノードです。OpenStack をインストールした単一システムで、OpenStack 環境 (オーバークラウド) を設定する OpenStack ノードをプロビジョニング/管理するためのコンポーネントが含まれます。アンダークラウドを設定するコンポーネントは、さまざまな機能を持ちます。

オーバークラウドは、アンダークラウドを使用して構築した Red Hat OpenStack Platform 環境です。これには、作成予定の OpenStack Platform 環境をベースに定義するさまざまなノードロールが含まれます。アンダークラウドには、以下に示すオーバークラウドのデフォルトノードロールセットが含まれます。

Red Hat OpenStack Platform director は、OpenStack Platform 環境に高可用性サービスを提供するためにコントローラーノードクラスターを使用します。director は、各コントローラーノードにコンポーネントの複製セットをインストールし、それらをまとめて単一のサービスとして管理します。このタイプのクラスター設定では、1 つのコントローラーノードが機能しなくなった場合にフォールバックするので、OpenStack のユーザーには一定の運用継続性が提供されます。

OpenStack Platform director は、複数の主要なソフトウェアを使用して、コントローラーノード上のコンポーネントを管理します。

オーバークラウド上の各 OpenStack Platform サービスは、対応するノード上の個別の Linux コンテナー内で実行されます。これにより、それぞれのサービスを分離し、OpenStack Platform を簡単に維持およびアップグレードすることができます。以下に示すように、Red Hat では、オーバークラウド用コンテナーイメージを取得するためのさまざまな方法をサポートしています。

本ガイドでは、レジストリー情報の設定および基本的なコンテナー操作の実施方法について説明します。コンテナー化されたサービスに関する詳しい情報は、コンテナー化されたサービスへの移行 を参照してください。

通常、OpenStack を使用する大規模な組織では、数千単位またはそれ以上のクライアントにサービスを提供します。ブロックストレージリソースの消費に関して、それぞれの OpenStack クライアントは固有のニーズを持つのが一般的です。glance (イメージ)、cinder (ボリューム)、nova (コンピュート) を単一ノードにデプロイすると、数千単位のクライアントがある大規模なデプロイメントでの管理ができなくなる可能性があります。このような課題は、OpenStack をスケールアウトすることによって解決できます。

ただし、実際には、Red Hat Ceph Storage などのソリューションを活用して、ストレージ層を仮想化する必要もでてきます。ストレージ層の仮想化により、Red Hat OpenStack Platform のストレージ層を数十テラバイト規模からペタバイトさらにはエクサバイトのストレージにスケーリングすることが可能です。Red Hat Ceph Storage は、市販のハードウェアを使用しながらも、高可用性/高パフォーマンスのストレージ仮想化層を提供します。仮想化によってパフォーマンスが低下するというイメージがありますが、Ceph はブロックデバイスイメージをクラスター全体でオブジェクトとしてストライプ化するため、大きい Ceph のブロックデバイスイメージはスタンドアロンのディスクよりもパフォーマンスが優れているということになります。Ceph ブロックデバイスでは、パフォーマンスを強化するために、キャッシュ、Copy On Write クローン、Copy On Read クローンもサポートされています。

Red Hat Ceph Storage に関する情報は、Red Hat Ceph Storage を参照してください。

以下の点に注意してください。

director をホストするアンダークラウドシステムは、オーバークラウド内の全ノードのプロビジョニングおよび管理を行います。

$ yum install libvirt-client libvirt-daemon qemu-kvm libvirt-daemon-driver-qemu libvirt-daemon-kvm virt-install bridge-utils rsync virt-viewer

$ virt-install --name undercloud --memory=16384 --vcpus=4 --location /var/lib/libvirt/images/rhel-server-7.5-x86_64-dvd.iso --disk size=100 --network bridge=br-ex --network bridge=br-ctlplane --graphics=vnc --hvm --os-variant=rhel7

--initrd-inject=/root/ks.cfg --extra-args "ks=file:/ks.cfg"

$ virsh snapshot-create-as --domain undercloud --disk-only --atomic --quiesce

$ rsync --sparse -avh --progress /var/lib/libvirt/images/undercloud.qcow2 1.qcow2

$ virsh blockcommit undercloud vda --active --verbose --pivot

アンダークラウドのホストには、最低でも 2 つのネットワークが必要です。

これは、必要なネットワークの最小数を示します。ただし、director は他の Red Hat OpenStack Platform ネットワークトラフィックをその他のネットワーク内に分離することができます。Red Hat OpenStack Platform は、ネットワークの分離に物理インターフェイスとタグ付けされた VLAN の両方をサポートしています。

以下の点に注意してください。

以下の項では、オーバークラウドのインストール内の個別システムおよびノードの要件について詳しく説明します。

アンダークラウドおよびオーバークラウドにはいずれも、Red Hat コンテンツ配信ネットワーク (CDN) または Red Hat Satellite Server 5 もしくは Red Hat Satellite Server 6 を使用した Red Hat リポジトリーへのアクセスが必要です。Red Hat Satellite Server を使用する場合は、必要なリポジトリーをお使いの OpenStack Platform 環境に同期する必要があります。以下の CDN チャネル名一覧を参考にしてください。

director はオーバークラウドの構築に、デフォルトで複数のノード種別を提供します。これらのノード種別は以下のとおりです。

以下の表には、オーバークラウドの設定例と各シナリオで使用するノード種別の定義をまとめています。

さらに、個別のサービスをカスタムのロールに分割するかどうかを検討します。コンポーザブルロールのアーキテクチャーに関する詳しい情報はオーバークラウドの高度なカスタマイズの コンポーザブルサービスとカスタムロール を参照してください。

ロールとサービスを適切にマッピングして相互に正しく通信できるように、環境のネットワークトポロジーおよびサブネットのプランニングを行うことが重要です。Red Hat OpenStack Platform では、自律的に動作してソフトウェアベースのネットワーク、静的/Floating IP アドレス、DHCP を管理する Neutron ネットワークサービスを使用します。director は、オーバークラウド環境の各コントローラーノードに、このサービスをデプロイします。

Red Hat OpenStack Platform は、さまざまなサービスをマッピングして、お使いの環境の各種サブネットに割り当てられたネットワークトラフィックの種別を分類します。このネットワークトラフィック種別には以下が含まれます。

一般的な Red Hat OpenStack Platform のシステム環境では通常、ネットワーク種別の数は物理ネットワークのリンク数を超えます。全ネットワークを正しいホストに接続するには、オーバークラウドは VLAN タグ付けを使用して、1 つのインターフェイスに複数のネットワークを提供します。ネットワークの多くは、サブネットが分離されていますが、インターネットアクセスまたはインフラストラクチャーにネットワーク接続ができるようにルーティングを提供するレイヤー 3 のゲートウェイが必要です。

director は、トラフィック種別の中から 6 つを特定のサブネットまたは VLAN にマッピングする方法を提供します。このようなトラフィック種別には、以下が含まれます。

未割り当てのネットワークは、プロビジョニングネットワークと同じサブネットに自動的に割り当てられます。

下図では、ネットワークが個別の VLAN に分離されたネットワークトポロジーの例を紹介しています。各オーバークラウドノードは、ボンディングで 2 つ (nic2 および nic3) のインターフェイスを使用して、対象の VLAN 経由でこれらのネットワークを提供します。また、各オーバークラウドのノードは、ネイティブの VLAN (nic1) を使用するプロビジョニングネットワークでアンダークラウドと通信します。

図3.1 ボンディングインターフェイスを使用する VLAN トポロジーの例

以下の表は、異なるネットワークのレイアウトをマッピングするネットワークトラフィック例が記載されています。

director は、オーバークラウド環境にさまざまなストレージオプションを提供します。オプションは以下のとおりです。

高可用性なオーバークラウドをデプロイするために、director は複数のコントローラー、コンピュート、およびストレージノードを単一のクラスターとして連携するように設定します。ノードで障害が発生すると、障害が発生したノードのタイプに応じて、自動フェンシングおよび再起動プロセスがトリガーされます。オーバークラウドの高可用性アーキテクチャーおよびサービスに関する情報は、高可用性デプロイメントと使用方法 を参照してください。

director を使用して、コンピュートインスタンスの高可用性 (インスタンス HA) を設定することもできます。このメカニズムにより、ノードで障害が発生するとコンピュートノード上のインスタンスが自動的に退避および再起動されます。インスタンス HA に対する要件は通常のオーバークラウドの要件と同じですが、追加のステップを実施してデプロイメントのために環境を準備する必要があります。インスタンス HA の仕組みおよびインストール手順に関する情報は、コンピュートインスタンスの高可用性 を参照してください。

ご自分の環境でプロキシーを使用している場合は、以下の考慮事項を確認して、Red Hat OpenStack Platform の一部とプロキシーを統合する際のさまざまな設定手法、およびそれぞれの手法の制限事項を十分に理解するようにしてください。

システム全体のプロキシー手法には、以下の制限事項があります。

これらのオプションの詳細については、man dnf.conf を実行してください。

dnf プロキシー手法には、以下の制限事項があります。

これらのオプションの詳細については、man rhsm.conf を実行してください。

Red Hat Subscription Manager プロキシー手法には、以下の制限事項があります。

director のインストールプロセスでは、root 以外のユーザーがコマンドを実行する必要があります。以下のコマンドを使用して、stack という名前のユーザーを作成して、パスワードを設定します。

stack ユーザーで director のインストールを続行します。

director はシステムのイメージと Heat テンプレートを使用して、オーバークラウド環境を構築します。これらのファイルを整理するには、イメージとテンプレート用にディレクトリーを作成するように推奨します。

[stack@director ~]$ mkdir ~/images
[stack@director ~]$ mkdir ~/templates

アンダークラウドでは、インストールと設定プロセスにおいて完全修飾ドメイン名が必要です。使用する DNS サーバーは、完全修飾ドメイン名を解決できる必要があります。たとえば、内部またはプライベートの DNS サーバーを使用することができます。これは、アンダークラウドのホスト名を設定する必要がある場合があることを意味します。

以下の手順に従って、Red hat OpenStack Platform director に関連したパッケージをインストールします。

Red Hat OpenStack Platform で Ceph Storage を使用する場合、ceph-ansible パッケージが必要です。

Red Hat Ceph Storage を使用する場合、またはデプロイメントで外部の Ceph Storage クラスターを使用する場合、ceph-ansible パッケージをインストールします。既存 Ceph Storage クラスターとの統合についての詳しい情報は、オーバークラウドの既存 Red Hat Ceph クラスターとの統合 を参照してください。

director のインストールプロセスには、ネットワーク設定を判断する特定の設定が必要です。この設定は、stack ユーザーのホームディレクトリーに undercloud.conf として配置されているテンプレートに保存されています。以下の手順では、デフォルトのテンプレートをベースに使用して設定を行う方法についてを説明します。

undercloud.conf ファイルで設定するパラメーターの一覧を以下に示します。エラーを避けるために、パラメーターは決して該当するセクションから削除しないでください。

[ctlplane-subnet]
cidr = 192.168.24.0/24
dhcp_start = 192.168.24.5
dhcp_end = 192.168.24.24
inspection_iprange = 192.168.24.100,192.168.24.120
gateway = 192.168.24.1
masquerade = true

プロビジョニングネットワークは、環境に応じて、必要なだけ指定することができます。

これらのパラメーターの値は、設定に応じて変更してください。完了したら、ファイルを保存します。

director に Puppet hieradata を設定して、サービスに対して利用可能な undercloud.conf パラメーター以外のカスタム設定を行うことができます。この機能を使用するには、以下の手順を実施します。

以下の手順では、director をインストールしてインストール後の基本的なタスクを実行します。

director のインストールが完了しました。これで、director のコマンドラインツールが使用できるようになりました。

director では、オーバークラウドのノードをプロビジョニングする際に、複数のディスクが必要です。必要なディスクは以下のとおりです。

以下の手順は、これらのイメージの取得およびインストールの方法について説明します。

オーバークラウドで cdn.redhat.com などの外部のホスト名を解決する予定の場合は、オーバークラウドノード上にネームサーバーを設定することを推奨します。ネットワークを分離していない標準のオーバークラウドの場合には、ネームサーバーはアンダークラウドのコントロールプレーンのサブネットを使用して定義されます。環境でネームサーバーを定義するには、以下の手順に従ってください。

これで director の設定およびインストールが完了しました。次の章では、ノードの登録、検査、さまざまなノードロールのタグ付けなど、オーバークラウドの基本的な設定について説明します。

Red Hat OpenStack Platform では、以下のレジストリータイプがサポートされています。

上記のリストから方法を選択し、レジストリー情報の設定を続けます。

本項では、openstack overcloud container image prepare コマンドの使用方法について説明します。これには、このコマンドのさまざまなオプションについての概念的な情報も含まれます。

以下のスニペットは、このファイルの内容の例を示しています。

parameter_defaults:
  DockerAodhApiImage: registry.redhat.io/rhosp13/openstack-aodh-api:13.0-34
  DockerAodhConfigImage: registry.redhat.io/rhosp13/openstack-aodh-api:13.0-34
...

環境ファイルには、DockerInsecureRegistryAddress パラメーターもアンダークラウドレジストリーの IP アドレスとポートに設定されます。このパラメーターにより、SSL/TLS 証明書なしにアンダークラウドレジストリーからイメージにアクセスするオーバークラウドノードが設定されます。

openstack overcloud container image prepare コマンドでは、この機能に以下のオプションを使用します。

このファイルの内容の例を以下に示します。

container_images:
- imagename: registry.redhat.io/rhosp13/openstack-aodh-api:13.0-34
- imagename: registry.redhat.io/rhosp13/openstack-aodh-evaluator:13.0-34
...

その結果、director は以下のような形式のイメージ名を生成します。

director は、OpenStack Platform のコアサービス用のコンテナーイメージのみを作成します。一部の追加機能には、追加のコンテナーイメージを必要とするサービスが使われます。これらのサービスは、環境ファイルで有効化することができます。openstack overcloud container image prepare コマンドでは、以下のオプションを使用して環境ファイルと対応するコンテナーイメージを追加します。

以下の表は、コンテナーイメージを使用する追加のサービスのサンプル一覧とそれらの対応する環境ファイルがある /usr/share/openstack-tripleo-heat-templates ディレクトリー内の場所をまとめています。

以下の項には、追加するサービスの例を記載します。

この環境ファイルに加えて、Ceph Storage コンテナーの場所を定義する必要があります。これは、OpenStack Platform サービスの場所とは異なります。--set オプションを使用して、以下の Ceph Storage 固有のパラメーターを設定してください。

以下のスニペットは、コンテナーイメージファイル内に Ceph Storage が含まれている例です。

$ openstack overcloud container image prepare \
  ...
  -e /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-ansible.yaml \
  --set ceph_namespace=registry.redhat.io/rhceph \
  --set ceph_image=rhceph-3-rhel7 \
  --tag-from-label {version}-{release} \
  ...

$ openstack overcloud container image prepare \
  ...
  -e /usr/share/openstack-tripleo-heat-templates/environments/services-docker/ironic.yaml \
  ...

$ openstack overcloud container image prepare \
  ...
  -e /usr/share/openstack-tripleo-heat-templates/environments/services-docker/sahara.yaml \
  ...

$ openstack overcloud container image prepare \
  ...
  -r ~/custom_roles_data.yaml
  -e /usr/share/openstack-tripleo-heat-templates/environments/services-docker/neutron-sriov.yaml \
  ...

$ openstack overcloud container image prepare \
  ...
  -e /usr/share/openstack-tripleo-heat-templates/environments/services-docker/octavia.yaml
\
  ...

  environments/manila-isilon-config.yaml
  environments/manila-netapp-config.yaml
  environments/manila-vmax-config.yaml
  environments/manila-cephfsnative-config.yaml
  environments/manila-cephfsganesha-config.yaml
  environments/manila-unity-config.yaml
  environments/manila-vnx-config.yaml

環境ファイルのカスタマイズおよびデプロイに関する詳細は、以下の資料を参照してください。

Red Hat では、オーバークラウドのコンテナーイメージを registry.redhat.io でホストしています。リモートレジストリーからイメージをプルするのが最も簡単な方法です。レジストリーはすでに設定済みで、プルするイメージの URL と名前空間を指定するだけで良いからです。ただし、オーバークラウドの作成中には、オーバークラウドノードがリモートリポジトリーからすべてのイメージをプルするので、外部接続で輻輳が生じる場合があります。したがって、実稼働環境ではこの方法は推奨されません。実稼働環境用には、この方法ではなく以下のいずれかの方法を使用してください。

レジストリーの設定が完了しました。

アンダークラウド上でローカルレジストリーを設定して、オーバークラウドのコンテナーイメージを保管することができます。

director を使用して、registry.redhat.io から各イメージをプルし、アンダークラウドで実行する docker-distribution レジストリーに各イメージをプッシュできます。director を使用してオーバークラウドを作成する場合は、オーバークラウドの作成プロセス中に、ノードは関連するイメージをアンダークラウドの docker-distribution レジストリーからプルします。

これにより、コンテナーイメージのネットワークトラフィックは、内部ネットワーク内に留まるので、外部ネットワークとの接続で輻輳が発生せず、デプロイメントプロセスを迅速化することができます。

レジストリーの設定が完了しました。

Red Hat Satellite 6 には、レジストリーの同期機能が備わっています。これにより、複数のイメージを Satellite Server にプルし、アプリケーションライフサイクルの一環として管理することができます。また、他のコンテナー対応システムも Satellite をレジストリーとして使うことができます。コンテナーイメージ管理の詳細は、Red Hat Satellite 6 コンテンツ管理ガイドの コンテナーイメージの管理 を参照してください。

以下の手順は、Red Hat Satellite 6 の hammer コマンドラインツールを使用した例を示しています。組織には、例として ACME という名称を使用しています。この組織は、実際に使用する Satellite 6 の組織に置き換えてください。

レジストリーの設定が完了しました。

コンテナーイメージのソースが記載された overcloud_images.yaml 環境ファイルができました。今後のデプロイメント操作ではすべてこのファイルを追加してください。

director では、手動で作成したノード定義のテンプレートが必要です。このファイル (instackenv.json) は、JSON 形式を使用して、ノードのハードウェアおよび電源管理の情報が含まれます。たとえば、2 つのノードを登録するテンプレートは、以下のようになります。

{
    "nodes":[
        {
            "mac":[
                "bb:bb:bb:bb:bb:bb"
            ],
            "name":"node01",
            "cpu":"4",
            "memory":"6144",
            "disk":"40",
            "arch":"x86_64",
            "pm_type":"ipmi",
            "pm_user":"admin",
            "pm_password":"p@55w0rd!",
            "pm_addr":"192.168.24.205"
        },
        {
            "mac":[
                "cc:cc:cc:cc:cc:cc"
            ],
            "name":"node02",
            "cpu":"4",
            "memory":"6144",
            "disk":"40",
            "arch":"x86_64",
            "pm_type":"ipmi",
            "pm_user":"admin",
            "pm_password":"p@55w0rd!",
            "pm_addr":"192.168.24.206"
        }
    ]
}

このテンプレートでは、以下の属性を使用します。

テンプレートを作成したら、以下のコマンドを実行してフォーマットおよび構文を検証します。

$ source ~/stackrc
(undercloud) $ openstack overcloud node import --validate-only ~/instackenv.json

stack ユーザーのホームディレクトリーにファイルを保存し (/home/stack/instackenv.json)、続いて以下のコマンドを実行してテンプレートを director にインポートします。

(undercloud) $ openstack overcloud node import ~/instackenv.json

このコマンドでテンプレートをインポートして、テンプレートから director に各ノードを登録します。

ノードを登録して設定が完了した後に、CLI でこれらのノードの一覧を表示します。

(undercloud) $ openstack baremetal node list

director は各ノードでイントロスペクションプロセスを実行することができます。このプロセスを実行すると、各ノードが PXE を介してイントロスペクションエージェントをブートします。このエージェントは、ノードからハードウェアのデータを収集して、director に送り返します。次に director は、director 上で実行中の OpenStack Object Storage (swift) サービスにこのイントロスペクションデータを保管します。director は、プロファイルのタグ付け、ベンチマーキング、ルートディスクの手動割り当てなど、さまざまな目的でハードウェア情報を使用します。

以下のコマンドを実行して、各ノードのハードウェア属性を検証します。

(undercloud) $ openstack overcloud node introspect --all-manageable --provide

別のターミナルウィンドウで以下のコマンドを使用してイントロスペクションの進捗状況をモニターリングします。

(undercloud) $ sudo journalctl -l -u openstack-ironic-inspector -u openstack-ironic-inspector-dnsmasq -u openstack-ironic-conductor -f

イントロスペクション完了後には、すべてのノードが available の状態に変わります。

ノードのイントロスペクション情報を表示するには、以下のコマンドを実行します。

(undercloud) $ openstack baremetal introspection data save <UUID> | jq .

<UUID> をイントロスペクション情報を取得するノードの UUID に置き換えてください。

(undercloud) $ openstack baremetal node manage [NODE UUID]
(undercloud) $ openstack overcloud node introspect [NODE UUID] --provide

イントロスペクションが完了すると、ノードは available の状態に変わります。

(undercloud) $ for node in $(openstack baremetal node list --fields uuid -f value) ; do openstack baremetal node manage $node ; done
(undercloud) $ openstack overcloud node introspect --all-manageable --provide

イントロスペクション完了後には、すべてのノードが available の状態に変わります。

ノード上のインターフェイスのリストを取得するには、以下のコマンドを実行します。

(undercloud) $ openstack baremetal introspection interface list [NODE UUID]

以下に例を示します。

(undercloud) $ openstack baremetal introspection interface list c89397b7-a326-41a0-907d-79f8b86c7cd9
+-----------+-------------------+------------------------+-------------------+----------------+
| Interface | MAC Address       | Switch Port VLAN IDs   | Switch Chassis ID | Switch Port ID |
+-----------+-------------------+------------------------+-------------------+----------------+
| p2p2      | 00:0a:f7:79:93:19 | [103, 102, 18, 20, 42] | 64:64:9b:31:12:00 | 510            |
| p2p1      | 00:0a:f7:79:93:18 | [101]                  | 64:64:9b:31:12:00 | 507            |
| em1       | c8:1f:66:c7:e8:2f | [162]                  | 08:81:f4:a6:b3:80 | 515            |
| em2       | c8:1f:66:c7:e8:30 | [182, 183]             | 08:81:f4:a6:b3:80 | 559            |
+-----------+-------------------+------------------------+-------------------+----------------+

インターフェイスのデータおよびスイッチポートの情報を表示するには、以下のコマンドを実行します。

(undercloud) $ openstack baremetal introspection interface show [NODE UUID] [INTERFACE]

以下に例を示します。

(undercloud) $ openstack baremetal introspection interface show c89397b7-a326-41a0-907d-79f8b86c7cd9 p2p1
+--------------------------------------+------------------------------------------------------------------------------------------------------------------------+
| Field                                | Value                                                                                                                  |
+--------------------------------------+------------------------------------------------------------------------------------------------------------------------+
| interface                            | p2p1                                                                                                                   |
| mac                                  | 00:0a:f7:79:93:18                                                                                                      |
| node_ident                           | c89397b7-a326-41a0-907d-79f8b86c7cd9                                                                                   |
| switch_capabilities_enabled          | [u'Bridge', u'Router']                                                                                                 |
| switch_capabilities_support          | [u'Bridge', u'Router']                                                                                                 |
| switch_chassis_id                    | 64:64:9b:31:12:00                                                                                                      |
| switch_port_autonegotiation_enabled  | True                                                                                                                   |
| switch_port_autonegotiation_support  | True                                                                                                                   |
| switch_port_description              | ge-0/0/2.0                                                                                                             |
| switch_port_id                       | 507                                                                                                                    |
| switch_port_link_aggregation_enabled | False                                                                                                                  |
| switch_port_link_aggregation_id      | 0                                                                                                                      |
| switch_port_link_aggregation_support | True                                                                                                                   |
| switch_port_management_vlan_id       | None                                                                                                                   |
| switch_port_mau_type                 | Unknown                                                                                                                |
| switch_port_mtu                      | 1514                                                                                                                   |
| switch_port_physical_capabilities    | [u'1000BASE-T fdx', u'100BASE-TX fdx', u'100BASE-TX hdx', u'10BASE-T fdx', u'10BASE-T hdx', u'Asym and Sym PAUSE fdx'] |
| switch_port_protocol_vlan_enabled    | None                                                                                                                   |
| switch_port_protocol_vlan_ids        | None                                                                                                                   |
| switch_port_protocol_vlan_support    | None                                                                                                                   |
| switch_port_untagged_vlan_id         | 101                                                                                                                    |
| switch_port_vlan_ids                 | [101]                                                                                                                  |
| switch_port_vlans                    | [{u'name': u'RHOS13-PXE', u'id': 101}]                                                                                 |
| switch_protocol_identities           | None                                                                                                                   |
| switch_system_name                   | rhos-compute-node-sw1                                                                                                  |
+--------------------------------------+------------------------------------------------------------------------------------------------------------------------+

たとえば、numa_topology コレクターは、この追加ハードウェアイントロスペクションの一部で、各 NUMA ノードに関する以下の情報が含まれます。

この情報を取得するには、ベアメタルノードの UUID を指定して、openstack baremetal introspection data save _UUID_ | jq .numa_topology コマンドを実行します。

取得されるベアメタルノードの NUMA 情報の例を以下に示します。

{
  "cpus": [
    {
      "cpu": 1,
      "thread_siblings": [
        1,
        17
      ],
      "numa_node": 0
    },
    {
      "cpu": 2,
      "thread_siblings": [
        10,
        26
      ],
      "numa_node": 1
    },
    {
      "cpu": 0,
      "thread_siblings": [
        0,
        16
      ],
      "numa_node": 0
    },
    {
      "cpu": 5,
      "thread_siblings": [
        13,
        29
      ],
      "numa_node": 1
    },
    {
      "cpu": 7,
      "thread_siblings": [
        15,
        31
      ],
      "numa_node": 1
    },
    {
      "cpu": 7,
      "thread_siblings": [
        7,
        23
      ],
      "numa_node": 0
    },
    {
      "cpu": 1,
      "thread_siblings": [
        9,
        25
      ],
      "numa_node": 1
    },
    {
      "cpu": 6,
      "thread_siblings": [
        6,
        22
      ],
      "numa_node": 0
    },
    {
      "cpu": 3,
      "thread_siblings": [
        11,
        27
      ],
      "numa_node": 1
    },
    {
      "cpu": 5,
      "thread_siblings": [
        5,
        21
      ],
      "numa_node": 0
    },
    {
      "cpu": 4,
      "thread_siblings": [
        12,
        28
      ],
      "numa_node": 1
    },
    {
      "cpu": 4,
      "thread_siblings": [
        4,
        20
      ],
      "numa_node": 0
    },
    {
      "cpu": 0,
      "thread_siblings": [
        8,
        24
      ],
      "numa_node": 1
    },
    {
      "cpu": 6,
      "thread_siblings": [
        14,
        30
      ],
      "numa_node": 1
    },
    {
      "cpu": 3,
      "thread_siblings": [
        3,
        19
      ],
      "numa_node": 0
    },
    {
      "cpu": 2,
      "thread_siblings": [
        2,
        18
      ],
      "numa_node": 0
    }
  ],
  "ram": [
    {
      "size_kb": 66980172,
      "numa_node": 0
    },
    {
      "size_kb": 67108864,
      "numa_node": 1
    }
  ],
  "nics": [
    {
      "name": "ens3f1",
      "numa_node": 1
    },
    {
      "name": "ens3f0",
      "numa_node": 1
    },
    {
      "name": "ens2f0",
      "numa_node": 0
    },
    {
      "name": "ens2f1",
      "numa_node": 0
    },
    {
      "name": "ens1f1",
      "numa_node": 0
    },
    {
      "name": "ens1f0",
      "numa_node": 0
    },
    {
      "name": "eno4",
      "numa_node": 0
    },
    {
      "name": "eno1",
      "numa_node": 0
    },
    {
      "name": "eno3",
      "numa_node": 0
    },
    {
      "name": "eno2",
      "numa_node": 0
    }
  ]
}

auto-discovery を使用すると、最初に instackenv.json ファイルを作成せずに、アンダークラウドノードを登録してそのメタデータを生成することができます。この改善により、最初のノード情報取得に費す時間を短縮できます。たとえば、IPMI IP アドレスを照合し、その後に instackenv.json ファイルを作成する必要がなくなります。

マルチアーキテクチャークラウドをビルドする場合には、roles_data.yaml にアーキテクチャー固有のロールを追加する必要があります。以下に示す例では、デフォルトのロールに加えて ComputePPC64LE ロールを追加しています。roles_data ファイルの作成 セクションには、ロールについての情報が記載されています。

openstack overcloud roles generate \
    --roles-path /usr/share/openstack-tripleo-heat-templates/roles -o ~/templates/roles_data.yaml \
    Controller Compute ComputePPC64LE BlockStorage ObjectStorage CephStorage

各ノードのハードウェアを登録、検査した後には、特定のプロファイルにノードをタグ付けします。このプロファイルタグにより、ノードがフレーバーに照合され、次にそのフレーバーがデプロイメントロールに割り当てられます。以下の例では、コントローラーノードのロール、フレーバー、プロファイル、ノード間の関係を示しています。

アンダークラウドのインストール時に、デフォルトプロファイルのフレーバー compute、control、swift-storage、ceph-storage、block-storage が作成され、大半の環境で変更なしに使用することができます。

特定のプロファイルにノードをタグ付けする場合には、各ノードの properties/capabilities パラメーターに profile オプションを追加します。たとえば、2 つのノードをタグ付けしてコントローラープロファイルとコンピュートプロファイルをそれぞれ使用するには、以下のコマンドを実行します。

(undercloud) $ openstack baremetal node set --property capabilities='profile:compute,boot_option:local' 58c3d07e-24f2-48a7-bbb6-6843f0e8ee13
(undercloud) $ openstack baremetal node set --property capabilities='profile:control,boot_option:local' 1a4e30da-b6dc-499d-ba87-0bd8a3819bc0

profile:compute と profile:control オプションを追加することで、この 2 つのノードがそれぞれのプロファイルにタグ付けされます。

これらのコマンドは、各ノードのブート方法を定義する boot_option:local パラメーターも設定します。お使いのハードウェアによっては、boot_mode パラメーターを uefi に追加して、ノードが BIOS モードの代わりに UEFI を使用してブートするようにする必要がある場合もあります。詳細は、「UEFI ブートモード」 を参照してください。

ノードのタグ付けが完了した後には、割り当てたプロファイルまたはプロファイルの候補を確認します。

(undercloud) $ openstack overcloud profiles list

(undercloud) $ openstack flavor create --id auto --ram 4096 --disk 40 --vcpus 1 networker
(undercloud) $ openstack flavor set --property "cpu_arch"="x86_64" --property "capabilities:boot_option"="local" --property "capabilities:profile"="networker" networker

この新規プロファイルにノードを割り当てます。

(undercloud) $ openstack baremetal node set --property capabilities='profile:networker,boot_option:local' dad05b82-0c74-40bf-9d12-193184bfc72d

ノードで複数のディスクが使用されている場合には、director はプロビジョニング時にルートディスクを特定する必要があります。たとえば、ほとんどの Ceph Storage ノードでは、複数のディスクが使用されます。デフォルトのプロビジョニングプロセスでは、director はルートディスクにオーバークラウドイメージを書き込みます。

以下のプロパティーを定義すると、director がルートディスクを特定するのに役立ちます。

シリアル番号を使用してルートデバイスを指定するには、以下の手順を実施します。

director は、ルートディスクとして使用する特定のディスクを把握します。openstack overcloud deploy コマンドを実行すると、director はオーバークラウドをプロビジョニングし、ルートディスクにオーバークラウドのイメージを書き込みます。

デフォルトでは、プロビジョニングプロセス中 director はルートディスクに QCOW2 overcloud-full イメージを書き込みます。overcloud-full イメージには、有効な Red Hat サブスクリプションが使用されます。ただし、overcloud-minimal イメージを使用して、たとえばベア OS をプロビジョニングすることもできます。この場合、他の OpenStack サービスは使用されないので、サブスクリプションエンタイトルメントは消費されません。

この典型的なユースケースは、Ceph デーモンのみを持つノードをプロビジョニングする場合です。この場合や類似のユースケースでは、overcloud-minimal イメージのオプションを使用して、有償の Red Hat サブスクリプションが限度に達するのを避けることができます。overcloud-minimal イメージの取得方法についての情報は、オーバークラウドノードのイメージの取得 を参照してください。

デフォルトでは、director は baremetal フレーバーを使用して 1 つのコントローラーノードとコンピュートノードを持つオーバークラウドをデプロイします。ただし、この設定は概念検証のためのデプロイメントにしか適しません。異なるノード数およびフレーバーを指定して、デフォルトの設定をオーバーライドすることができます。小規模な実稼働環境では、コントローラーノードとコンピュートノードを少なくとも 3 つにし、適切なリソース仕様でノードが作成されるように特定のフレーバーを割り当てる必要があります。以下の手順では、ノード数およびフレーバー割り当てを定義する環境ファイル node-info.yaml の作成方法を説明します。

このファイルは、この後「オーバークラウド作成時の環境ファイルの追加」で使用します。

アンダークラウドで TLS が使用され CA が一般に信頼できない場合には、以下の手順に従う必要があります。アンダークラウドは、SSL エンドポイントの暗号化のために自己の認証局 (CA) を運用します。デプロイメントの他の要素からアンダークラウドのエンドポイントにアクセスできるようにするには、アンダークラウドの CA を信頼するようにオーバークラウドノードを設定します。

undercloud_service_certificate および generate_service_certificate オプションの説明および使用方法については、「director の設定パラメーター」 を参照してください。

オーバークラウドのデプロイメント時に CA 証明書がそれぞれのオーバークラウドノードにコピーされ、アンダークラウドの SSL エンドポイントが提示する暗号化を信頼するようになります。環境ファイル追加の詳細は、「オーバークラウド作成時の環境ファイルの追加」を参照してください。

アンダークラウドには、オーバークラウドの作成プランとして機能するさまざまな Heat テンプレートが含まれます。YAML フォーマットの環境ファイルを使って、オーバークラウドの特性をカスタマイズすることができます。このファイルで、コア Heat テンプレートコレクションのパラメーターおよびリソースを上書きします。必要に応じていくつでも環境ファイルを追加することができます。ただし、後で実行される環境ファイルで定義されているパラメーターとリソースが優先されることになるため、環境ファイルの順番は重要です。以下の一覧は、環境ファイルの順序の例です。

カスタム環境ファイルは、別のディレクトリーで管理することを推奨します (たとえば、templates ディレクトリー)。

オーバークラウドの高度なカスタマイズ を使用して、オーバークラウドの詳細機能をカスタマイズすることができます。

Heat テンプレートおよび環境ファイルの詳細については、オーバークラウドの高度なカスタマイズの Heat テンプレートの理解 の章を参照してください。

OpenStack 環境作成における最後の段階では、openstack overcloud deploy コマンドを実行して OpenStack 環境を作成します。このコマンドを実行する前に、キーオプションやカスタムの環境ファイルの追加方法を十分に理解しておく必要があります。

環境ファイルの parameter_defaults セクションに追加する Heat テンプレートのパラメーターの使用が優先されるため、一部のコマンドラインパラメーターは古いか非推奨となっています。以下の表では、非推奨となったパラメーターと、それに相当する Heat テンプレートのパラメーターを対照しています。

これらのパラメーターは、Red Hat OpenStack Platform の今後のリリースで廃止される予定です。

(undercloud) $ openstack help overcloud deploy

オーバークラウドをカスタマイズするには、-e を指定して、環境ファイルを追加します。必要に応じていくつでも環境ファイルを追加することができます。ただし、後で実行される環境ファイルで定義されているパラメーターとリソースが優先されることになるため、環境ファイルの順番は重要です。以下の一覧は、環境ファイルの順序の例です。

-e オプションを使用してオーバークラウドに追加した環境ファイルはいずれも、オーバークラウドのスタック定義の一部となります。以下のコマンドは、追加するカスタム環境ファイルを使用してオーバークラウドの作成を開始する方法の一例です。

(undercloud) $ openstack overcloud deploy --templates \
  -e /home/stack/templates/node-info.yaml\
  -e /home/stack/templates/overcloud_images.yaml \
  -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \
  -e /home/stack/templates/network-environment.yaml \
  -e /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-ansible.yaml \
  -e /home/stack/templates/ceph-custom-config.yaml \
  -e /home/stack/inject-trust-anchor-hiera.yaml \
  -r /home/stack/templates/roles_data.yaml \
  --ntp-server pool.ntp.org \

上記のコマンドでは、以下の追加オプションも使用できます。

director は、9章オーバークラウド作成後のタスクの実行に記載の再デプロイおよびデプロイ後の機能にこれらの環境ファイルを必要とします。これらのファイルが含まれていない場合には、オーバークラウドが破損する可能性があります。

オーバークラウド設定を後で変更する予定の場合には、以下の作業を行う必要があります。

(undercloud) $ ls -1 ~/templates
00-node-info.yaml
10-overcloud_images.yaml
20-network-isolation.yaml
30-network-environment.yaml
40-storage-environment.yaml
50-rhel-registration.yaml

以下のデプロイメントコマンドを実行してディレクトリーを追加します。

(undercloud) $ openstack overcloud deploy --templates --environment-directory ~/templates

たとえば、回答ファイルには以下の内容を含めることができます。

templates: /usr/share/openstack-tripleo-heat-templates/
environments:
  - ~/templates/00-node-info.yaml
  - ~/templates/10-network-isolation.yaml
  - ~/templates/20-network-environment.yaml
  - ~/templates/30-storage-environment.yaml
  - ~/templates/40-rhel-registration.yaml

以下のデプロイメントコマンドを実行して回答ファイルを追加します。

(undercloud) $ openstack overcloud deploy --answers-file ~/answers.yaml

openstack overcloud deploy コマンドを使用する代わりに、director を使用してインポートしたプランを管理することもできます。

新規プランを作成するには、以下のコマンドを stack ユーザーとして実行します。

(undercloud) $ openstack overcloud plan create --templates /usr/share/openstack-tripleo-heat-templates my-overcloud

このコマンドは、/usr/share/openstack-tripleo-heat-templates 内のコア Heat テンプレートコレクションからプランを作成します。director は、入力内容に基づいてプランに名前を指定します。この例では、my-overcloud という名前です。director は、この名前をオブジェクトストレージコンテナー、ワークフロー環境、オーバークラウドスタック名のラベルとして使用します。

以下のコマンドを使用して環境ファイルからパラメーターを追加します。

(undercloud) $ openstack overcloud parameters set my-overcloud ~/templates/my-environment.yaml

以下のコマンドを使用してプランをデプロイします。

(undercloud) $ openstack overcloud plan deploy my-overcloud

以下のコマンドを使用して既存のプランを削除します。

(undercloud) $ openstack overcloud plan delete my-overcloud

オーバークラウドの作成またはスタックの更新を実行する前に、Heat テンプレートと環境ファイルにエラーがないかどうかを検証します。

(undercloud) $ openstack overcloud plan create --templates /usr/share/openstack-tripleo-heat-templates overcloud-validation
(undercloud) $ mkdir ~/overcloud-validation
(undercloud) $ cd ~/overcloud-validation
(undercloud) $ openstack container save overcloud-validation

その後の検証テストには ~/overcloud-validation のレンダリング済みテンプレートを使用します。

(undercloud) $ openstack orchestration template validate --show-nested --template ~/overcloud-validation/overcloud.yaml -e ~/overcloud-validation/overcloud-resource-registry-puppet.yaml -e [ENVIRONMENT FILE] -e [ENVIRONMENT FILE]

このコマンドは、テンプレート内の構文エラーを特定します。テンプレートの構文の検証が正常に行われた場合には、出力には、作成されるオーバークラウドのテンプレートのプレビューが表示されます。

オーバークラウドの作成プロセスが開始され、director によりノードがプロビジョニングされます。このプロセスは完了するまで多少時間がかかります。オーバークラウドの作成のステータスを確認するには、stack ユーザーとして別のターミナルを開き、以下のコマンドを実行します。

(undercloud) $ source ~/stackrc
(undercloud) $ openstack stack list --nested

openstack stack list --nested コマンドは、オーバークラウド作成の現在の段階を表示します。

オーバークラウドのデプロイメントが正常に完了すると、シェルから以下の情報が返されます。この情報を使用してオーバークラウドにアクセスすることができます。

Overcloud configuration completed.
Overcloud Endpoint: http://192.168.24.113:5000
Overcloud Horizon Dashboard URL: http://192.168.24.113:80/dashboard
Overcloud rc file: /home/stack/overcloudrc
Overcloud Deployed

director は、director ホストからオーバークラウドに対話するための設定を行い、認証をサポートするスクリプトを作成します。director は、このファイル overcloudrc を stack ユーザーのホームディレクトリーに保存します。このファイルを使用するには、以下のコマンドを実行します。

(undercloud) $ source ~/overcloudrc

これにより、director ホストの CLI からオーバークラウドと対話するために必要な環境変数が読み込まれます。コマンドプロンプトが変わり、オーバークラウドと対話していることが示されます。

(overcloud) $

director のホストとの対話に戻るには、以下のコマンドを実行します。

(overcloud) $ source ~/stackrc
(undercloud) $

オーバークラウドの各ノードには、heat-admin と呼ばれるユーザーが含まれます。stack ユーザーには、各ノードに存在するこのユーザーに SSH 経由でアクセスすることができます。SSH でノードにアクセスするには、希望のノードの IP アドレスを特定します。

(undercloud) $ openstack server list

次に、heat-admin ユーザーとノードの IP アドレスを使用して、ノードに接続します。

(undercloud) $ ssh heat-admin@192.168.24.23

これで、コマンドラインツールを使用したオーバークラウドの作成が完了しました。作成後の機能については、9章オーバークラウド作成後のタスクの実行を参照してください。

director の Web UI には SSL 経由でアクセスします。たとえば、アンダークラウドの IP アドレスが 192.168.24.1 の場合には、UI にアクセスするためのアドレスは https://192.168.24.1 です。Web UI はまず、以下のフィールドが含まれるログイン画面を表示します。

UI へのログイン時に、UI は OpenStack Identity のパブリック API にアクセスして、他のパブリック API サービスのエンドポイントを取得します。これらのサービスには、以下が含まれます。

UI は主に 3 つのセクションで設定されています。

これらの検証タスクは、デプロイメントの特定の時点で自動的に実行されます。ただし、手動で実行することもできます。実行する検証タスクの 再生 ボタンをクリックします。各検証タスクのタイトルをクリックして実行するか、検証タイトルをクリックして詳細情報を表示します。

director UI には、オーバークラウドの設定の前にプランが必要です。このプランは通常、/usr/share/openstack-tripleo-heat-templates にあるアンダークラウド上のテンプレートなど、Heat テンプレートコレクションです。さらに、ハードウェアや環境の要件に合わせてプランをカスタマイズすることができます。オーバークラウドのカスタマイズに関する詳しい情報は オーバークラウドの高度なカスタマイズ を参照してください。

プランには、オーバークラウドの設定に関する 4 つの主要な手順が表示されます。

アンダークラウドのインストールと設定を実行すると、プランが自動的にアップロードされます。Web UI に複数のプランをインポートすることも可能です。プラン 画面のパンくずリストで すべてのプラン をクリックします。これにより、現在の プラン の一覧が表示されます。プランを切り替えるには、カードをクリックします。

プランのインポート をクリックすると、以下の情報を尋ねるウィンドウが表示されます。

director の Heat テンプレートコレクションをクライアントのマシンにコピーする必要がある場合には、ファイルをアーカイブしてコピーします。

$ cd /usr/share/openstack-tripleo-heat-templates/
$ tar -cf ~/overcloud.tar *
$ scp ~/overcloud.tar user@10.0.0.55:~/.

director UI がプランをアップロードしたら、プランが プラン のリストに表示され、設定を行うことができます。選択するプランのカードをクリックします。

オーバークラウド設定の最初の手順は、ノードの登録です。以下のいずれかで、ノードの登録プロセスを開始します。

ノードの登録 ウィンドウが表示されます。

director には、登録するノードの一覧が必要です。以下のいずれかの方法でリストを取得できます。

手動登録に必要な情報は以下のとおりです。

ノードの情報を入力した後に、ウィンドウの下の ノードの登録 をクリックします。

director によりノードが登録されます。登録が完了すると、UI を使用してノードのイントロスペクションを実行できるようになります。

director UI は各ノードでイントロスペクションプロセスを実行することができます。このプロセスを実行すると、各ノードが PXE を介してイントロスペクションエージェントをブートします。このエージェントは、ノードからハードウェアのデータを収集して、director に送り返します。次に director は、director 上で実行中の OpenStack Object Storage (swift) サービスにこのイントロスペクションデータを保管します。director は、プロファイルのタグ付け、ベンチマーキング、ルートディスクの手動割り当てなど、さまざまな目的でハードウェア情報を使用します。

イントロスペクションのプロセスを開始するには、以下のステップを実行します。

イントロスペクションのプロセスを完了したら、プロビジョニングの状態 が manageable に設定されているノードをすべて選択して、プロビジョン ボタンをクリックします。プロビジョニングの状態 が available になるまで待ちます。

ノードのタグ付けおよびプロビジョニングの準備ができました。

各ノードにプロファイルのセットを割り当てることができます。それぞれのプロファイルが、個々のフレーバーおよびロールに対応します (詳細は、「プロファイルへのノードのタグ付け」を参照してください)。

ノード 画面には、さらにトグルメニューがあり、ノードのタグ付け などのその他のノード管理操作を選択することができます。

ノードのセットをタグ付けするには、以下の手順を実行します。

プラン 画面では、アップロードしたプランをカスタマイズすることができます。2 デプロイメントの設定の指定 で、設定の編集 リンクをクリックして、ベースのオーバークラウドの設定を変更します。

ウィンドウには、2 つの主要なタブが表示されます。

3 ロールの設定とノードの割り当て セクションの右下には、ロールの管理 アイコンがあります。

このアイコンをクリックすると、環境に追加できるロールを示すカードの選択肢が表示されます。ロールを追加するには、そのロールの右上にあるチェックボックスにチェックを付けます。

ロールを選択したら、変更の保存 をクリックします。

各ノードのハードウェアを登録、検査した後には、プランの画面からロールに割り当てます。

ロールにノードを割り当てるには、プラン の画面で 3 ロールの設定とノードの割り当て セクションまでスクロールします。各ロールで、スピナーウィジェットを使ってノード数をロールに割り当てます。それぞれのロールで利用可能なノードの数は、「Web UI を使用したプロファイルへのノードのタグ付け」でタグ付けしたノードに基づきます。

この操作により、各ロールの *Count パラメーターが変更されます。たとえば、コントローラーロールのノード数を 3 に変更すると、ControllerCount パラメーターが 3 に設定されます。デプロイメント設定の パラメーター タブで、これらのカウント値を表示および編集することもできます。詳しくは、「Web UI を使用したオーバークラウドプランのパラメーターの編集」を参照してください。

各ノードのロールにより、ロール固有のパラメーターを設定する手段が提供されます。プラン の画面で 3 ロールの設定とノードの割り当て セクションまでスクロールします。ロール名の横にある Edit Role Parameters アイコンをクリックします。

ウィンドウには、2 つの主要なタブが表示されます。

オーバークラウドプランが設定されたら、オーバークラウドのデプロイメントを開始することができます。そのためには、4 デプロイ セクションまでスクロールして、検証とデプロイ をクリックしてください。

アンダークラウドの検証をすべて実行しなかった場合や、すべての検証に合格しなかった場合には、警告メッセージが表示されます。アンダークラウドのホストが要件を満たしていることを確認してから、デプロイメントを実行してください。

デプロイメントの準備ができたら デプロイ をクリックしてください。

UI では、定期的に オーバークラウド作成の進捗がモニターリングされ、現在の進捗の割合を示すプログレスバーが表示されます。詳細情報の表示 リンクでは、オーバークラウドにおける現在の OpenStack Orchestration スタックのログが表示されます。

オーバークラウドのデプロイメントが完了するまで待ちます。

オーバークラウドの作成プロセスが完了したら、4 デプロイ セクションに、現在のオーバークラウドの状況と以下の詳細が表示されます。

この情報を使用してオーバークラウドにアクセスします。

これで director の UI を使用したオーバークラウドの作成が完了しました。作成後の機能については、9章オーバークラウド作成後のタスクの実行を参照してください。

このプロセスの後半では、director が オーバークラウドノードに stack ユーザーとして SSH アクセスする必要があります。

それぞれのノードには、Red Hat サブスクリプションへのアクセスが必要です。

以下の手順は、各ノードを Red Hat コンテンツ配信ネットワークに登録する方法を説明しています。各ノードで以下の手順を実行してください。

このノードをオーバークラウドに使用する準備ができました。

事前にプロビジョニングされたノードはそれぞれ、OpenStack Orchestration (heat) エージェントを使用して director と通信します。各ノード上のエージェントは、director をポーリングして、そのノードに合わせたメタデータを取得します。このメタデータにより、エージェントは各ノードを設定できます。

各ノードでオーケストレーションエージェントの初期パッケージをインストールします。

[root@controller-0 ~]# sudo yum -y install python-heat-agent*

director が SSL/TLS を使用する場合は、事前にプロビジョニングされたノードには、director の SSL/TLS 証明書の署名に使用する認証局ファイルが必要です。独自の認証局を使用する場合には、各オーバークラウドノード上で以下のステップを実行します。

これにより、オーバークラウドノードが director のパブリック API に SSL/TLS 経由でアクセスできるようにします。

事前にプロビジョニングされたオーバークラウドノードは、標準の HTTP 要求を使用して director からメタデータを取得します。これは、オーバークラウドノードでは以下のいずれかに対して L3 アクセスが必要であることを意味します。

director は、コントロールプレーンネットワークを使用して標準のオーバークラウドを管理、設定します。事前にプロビジョニングされたノードを使用したオーバークラウドの場合には、director が事前にプロビジョニングされたノードと通信する方法に対応するために、ネットワーク設定を変更する必要がある場合があります。

標準のオーバークラウド作成中には、director はプロビジョニング/コントロールプレーンネットワークのオーバークラウドノードに IP アドレスを自動的に割り当てるための OpenStack Networking (neutron) ポートを作成します。ただし、これにより、各ノードに手動で設定した IP アドレスとは異なるアドレスを director が割り当ててしまう可能性があります。このような場合には、予測可能な IP アドレス割り当て方法を使用して、director がコントロールプレーン上で事前にプロビジョニングされた IP の割り当てを強制的に使用するようにしてください。

予測可能な IP アドレス割り当て方法の例では、以下のように IP アドレスを割り当てた環境ファイル (ctlplane-assignments.yaml) を使用します。

resource_registry:
  OS::TripleO::DeployedServer::ControlPlanePort: /usr/share/openstack-tripleo-heat-templates/deployed-server/deployed-neutron-port.yaml

parameter_defaults:
  DeployedServerPortMap:
    controller-0-ctlplane:
      fixed_ips:
        - ip_address: 192.168.24.2
      subnets:
        - cidr: 24
    compute-0-ctlplane:
      fixed_ips:
        - ip_address: 192.168.24.3
      subnets:
        - cidr: 24

この例では、OS::TripleO::DeployedServer::ControlPlanePort リソースはパラメーターセットを director に渡して、事前にプロビジョニングされたノードの IP 割り当てを定義します。DeployedServerPortMap パラメーターは、各オーバークラウドノードに対応する IP アドレスおよびサブネット CIDR を定義します。このマッピングは以下を定義します。

本章の後半のステップでは、作成された環境ファイル (ctlplane-assignments.yaml) を openstack overcloud deploy コマンドの一部として使用します。

デフォルトでは、director はオーバークラウドのコントロールプレーンとしてプロビジョニングネットワークを使用します。ただし、このネットワークが分離されてルーティング不可能な場合には、ノードは設定中に director の内部 API と通信することができません。このような状況では、ノードに別のネットワークを定義して、パブリック API 経由で director と通信するように設定しなければならない場合があります。

このシナリオには、いくつかの要件があります。

本項に記載する例では、主要なシナリオとは異なる IP アドレスの割り当てを使用します。

以下の項では、オーバークラウドノードに別のネットワークが必要な場合の追加の設定について説明します。

undercloud.conf の hieradata_override を使用すると、アンダークラウド設定用に追加で Puppet hieradata を指定することができます。以下の手順を使用して、OpenStack Orchestration に関連する hieradata を変更してください。

これにより、オーケストレーションメタデータが director のパブリック API 上の URL を使用するように切り替えられます。

resource_registry:
  OS::TripleO::DeployedServer::ControlPlanePort: /usr/share/openstack-tripleo-heat-templates/deployed-server/deployed-neutron-port.yaml
  OS::TripleO::Network::Ports::ControlPlaneVipPort: /usr/share/openstack-tripleo-heat-templates/deployed-server/deployed-neutron-port.yaml
  OS::TripleO::Network::Ports::RedisVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/noop.yaml 1

parameter_defaults:
  NeutronPublicInterface: eth1
  EC2MetadataIp: 192.168.100.1 2
  ControlPlaneDefaultRoute: 192.168.100.1
  DeployedServerPortMap:
    control_virtual_ip:
      fixed_ips:
        - ip_address: 192.168.100.1
      subnets:
        - cidr: 24
    controller-0-ctlplane:
      fixed_ips:
        - ip_address: 192.168.100.2
      subnets:
        - cidr: 24
    compute-0-ctlplane:
      fixed_ips:
        - ip_address: 192.168.100.3
      subnets:
        - cidr: 24

ceph-ansible およびデプロイ済みのサーバーを使用する場合、デプロイメントの前にアンダークラウドから以下のようなコマンドを実行する必要があります。

export OVERCLOUD_HOSTS="192.168.1.8 192.168.1.42"

bash /usr/share/openstack-tripleo-heat-templates/deployed-server/scripts/enable-ssh-admin.sh

例に示す export コマンドを使用して、OVERCLOUD_HOSTS 変数を Ceph クライアントとして使用するオーバークラウドホストの IP アドレスに設定します (Compute、Block Storage、Image、File System、Telemetry サービスなど)。enable-ssh-admin.sh スクリプトにより、Ansible が Ceph クライアントの設定に使用するオーバークラウドノードのユーザーが設定されます。

オーバークラウドのデプロイメントには、「CLI ツールを使用したオーバークラウドの作成」に記載された標準の CLI の方法を使用します。事前にプロビジョニングされたノードの場合は、デプロイメントコマンドに追加のオプションと、コア Heat テンプレートコレクションからの環境ファイルが必要です。

事前にプロビジョニングされたアーキテクチャー固有の環境ファイルを使用したオーバークラウドデプロイメントのコマンド例を、以下に示します。

$ source ~/stackrc
(undercloud) $ openstack overcloud deploy \
  [other arguments] \
  --disable-validations \
  -e /usr/share/openstack-tripleo-heat-templates/environments/deployed-server-environment.yaml \
  -e /usr/share/openstack-tripleo-heat-templates/environments/deployed-server-bootstrap-environment-rhel.yaml \
  -e /usr/share/openstack-tripleo-heat-templates/environments/deployed-server-pacemaker-environment.yaml \
  -r /usr/share/openstack-tripleo-heat-templates/deployed-server/deployed-server-roles-data.yaml

このコマンドにより、オーバークラウドの設定を開始されます。ただし、デプロイメントのスタックは、オーバークラウドのノードリソースが CREATE_IN_PROGRESS の段階に入ると一時停止します。

2017-01-14 13:25:13Z [overcloud.Compute.0.Compute]: CREATE_IN_PROGRESS  state changed
2017-01-14 13:25:14Z [overcloud.Controller.0.Controller]: CREATE_IN_PROGRESS  state changed

このように一時停止されるのは、オーバークラウドノード上のオーケストレーションエージェントがメタデータサーバーをポーリングするのを director が待っているためです。次のセクションでは、メタデータサーバーのポーリングを開始するようにノードを設定する方法を説明します。

デプロイメントは進行中ですが、CREATE_IN_PROGRESS の段階で一時停止されます。次のステップでは、オーバークラウドノードのオーケストレーションエージェントが director 上のメタデータサーバーをポーリングするように設定します。この操作には、2 つの方法があります。

[stack@director ~]$ source ~/stackrc

また、このスクリプトでは、追加の環境変数でノードのロールやその IP アドレスを定義する必要があります。これらの環境変数は以下のとおりです。

以下のコマンドは、これらの環境変数の設定例です。

(undercloud) $ export OVERCLOUD_ROLES="ControllerDeployedServer ComputeDeployedServer"
(undercloud) $ export ControllerDeployedServer_hosts="192.168.100.2"
(undercloud) $ export ComputeDeployedServer_hosts="192.168.100.3"

スクリプトを実行して、各オーバークラウドノード上にオーケストレーションエージェントを設定します。

(undercloud) $ /usr/share/openstack-tripleo-heat-templates/deployed-server/scripts/get-occ-config.sh

このスクリプトは、以下を行います。

スクリプトが完了したら、オーバークラウドノードは director 上でオーケストレーションサービスのポーリングを開始します。スタックのデプロイメントが続行されます。

[stack@director ~]$ source ~/stackrc
(undercloud) $ for STACK in $(openstack stack resource list -n5 --filter name=deployed-server -c stack_name -f value overcloud) ; do STACKID=$(echo $STACK | cut -d '-' -f2,4 --output-delimiter " ") ; echo "== Metadata URL for $STACKID ==" ; openstack stack resource metadata $STACK deployed-server | jq -r '.["os-collect-config"].request.metadata_url' ; echo ; done

これにより、各ノードのスタック名やメタデータの URL が表示されます。

== Metadata URL for ControllerDeployedServer 0 ==
http://192.168.24.1:8080/v1/AUTH_6fce4e6019264a5b8283e7125f05b764/ov-edServer-ts6lr4tm5p44-deployed-server-td42md2tap4g/43d302fa-d4c2-40df-b3ac-624d6075ef27?temp_url_sig=58313e577a93de8f8d2367f8ce92dd7be7aac3a1&temp_url_expires=2147483586

== Metadata URL for ComputeDeployedServer 0 ==
http://192.168.24.1:8080/v1/AUTH_6fce4e6019264a5b8283e7125f05b764/ov-edServer-wdpk7upmz3eh-deployed-server-ghv7ptfikz2j/0a43e94b-fe02-427b-9bfe-71d2b7bb3126?temp_url_sig=8a50d8ed6502969f0063e79bb32592f4203a136e&temp_url_expires=2147483586

各オーバークラウドノード上で以下を行います。

サービスを設定して再起動した後に、オーケストレーションエージェントは director のオーケストレーションサービスをポーリングしてオーバークラウドの設定を行います。デプロイメントスタックは作成を続行して、各ノードのスタックは最終的に CREATE_COMPLETE に変わります。

オーバークラウドの設定プロセスが開始されます。このプロセスは完了するまで多少時間がかかります。オーバークラウドの作成のステータスを確認するには、stack ユーザーとして別のターミナルを開き、以下のコマンドを実行します。

[stack@director ~]$ source ~/stackrc
(undercloud) $ heat stack-list --show-nested

heat stack-list --show-nested コマンドは、オーバークラウド作成の現在の段階を表示します。

director は、director ホストからオーバークラウドに対話するための設定を行い、認証をサポートするスクリプトを作成します。director は、このファイル overcloudrc を stack ユーザーのホームディレクトリーに保存します。このファイルを使用するには、以下のコマンドを実行します。

(undercloud) $ source ~/overcloudrc

これにより、director ホストの CLI からオーバークラウドと対話するために必要な環境変数が読み込まれます。コマンドプロンプトが変わり、オーバークラウドと対話していることが示されます。

(overcloud) $

director のホストとの対話に戻るには、以下のコマンドを実行します。

(overcloud) $ source ~/stackrc
(undercloud) $

事前にプロビジョニングされたノードをスケーリングするプロセスは、12章オーバークラウドノードのスケーリングに記載する標準のスケーリング手順と類似しています。ただし、事前にプロビジョニングされたノードを新たに追加するプロセスは異なります。これは、事前にプロビジョニングされたノードが OpenStack Bare Metal (ironic) および OpenStack Compute (nova) からの標準の登録および管理プロセスを使用しないためです。

事前にプロビジョニングされたノードをスケールアップするプロセスの概略は、以下のとおりです。

ほとんどのスケーリング操作では、ノードの UUID 値を取得して openstack overcloud node delete に渡す必要があります。この UUID を取得するには、ロールを指定してリソースの一覧を表示します。

$ openstack stack resource list overcloud -c physical_resource_id -c stack_name -n5 --filter type=OS::TripleO::<RoleName>Server

上記コマンドの <RoleName> を、スケールダウンする実際のロール名に置き換えます。ComputeDeployedServer ロールの例を以下に示します。

$ openstack stack resource list overcloud -c physical_resource_id -c stack_name -n5 --filter type=OS::TripleO::ComputeDeployedServerServer

コマンド出力の stack_name 列から、各ノードに関連付けられた UUID を確認します。stack_name には、Heat リソースグループ内のノードインデックスの整数値が含まれます。出力の例を以下に示します。

+------------------------------------+----------------------------------+
| physical_resource_id               | stack_name                       |
+------------------------------------+----------------------------------+
| 294d4e4d-66a6-4e4e-9a8b-           | overcloud-ComputeDeployedServer- |
| 03ec80beda41                       | no7yfgnh3z7e-1-ytfqdeclwvcg      |
| d8de016d-                          | overcloud-ComputeDeployedServer- |
| 8ff9-4f29-bc63-21884619abe5        | no7yfgnh3z7e-0-p4vb3meacxwn      |
| 8c59f7b1-2675-42a9-ae2c-           | overcloud-ComputeDeployedServer- |
| 2de4a066f2a9                       | no7yfgnh3z7e-2-mmmaayxqnf3o      |
+------------------------------------+----------------------------------+

stack_name 列のインデックス 0、1、または 2 は、Heat リソースグループ内のノード順に対応します。physical_resource_id 列の該当する UUID 値を、openstack overcloud node delete コマンドに渡します。

スタックからオーバークラウドノードを削除したら、それらのノードの電源をオフにします。標準のデプロイメントでは、director のベアメタルサービスがこの機能を制御します。ただし、事前にプロビジョニングされたノードでは、これらのノードを手動でシャットダウンするか、物理システムごとに電源管理制御を使用する必要があります。スタックからノードを削除した後にノードの電源をオフにしないと、稼動状態が続き、オーバークラウド環境の一部として再接続されてしまう可能性があります。

削除したノードの電源をオフにした後には、再プロビジョニングしてベースのオペレーティングシステムの設定に戻し、それらのノードが意図せずにオーバークラウドに加わってしまうことがないようにします。

標準のオーバークラウドと同じ手順で、事前にプロビジョニングされたノードを使用するオーバークラウド全体を削除します。詳しくは、「オーバークラウドの削除」を参照してください。

オーバークラウドの削除後には、全ノードの電源をオフにしてから再プロビジョニングして、ベースオペレーティングシステムの設定に戻します。

これで、事前にプロビジョニングされたノードを使用したオーバークラウドの作成が完了しました。作成後の機能については、9章オーバークラウド作成後のタスクの実行を参照してください。

オーバークラウドでは、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

$ sudo docker inspect keystone

$ sudo docker restart keystone

コンテナー化されたサービスを停止するには、docker stop コマンドを使用します。たとえば、keystone のコンテナーを停止するには、以下のコマンドを実行します。

$ sudo docker stop keystone

停止されているコンテナー化されたサービスを起動するには、docker start コマンドを使用します。たとえば、keystone のコンテナーを起動するには、以下のコマンドを実行します。

$ sudo docker start keystone

$ sudo docker logs keystone

$ sudo docker exec -it keystone /bin/bash

keystone コンテナーのシェルに root ユーザーとして入るには、以下のコマンドを実行します。

$ sudo docker exec --user 0 -it <NAME OR ID> /bin/bash

コンテナーから出るには、以下のコマンドを実行します。

# exit

OpenStack Platform のコンテナー化されたサービスのトラブルシューティングに関する情報は、「コンテナー化されたサービスのエラー」を参照してください。

オーバークラウドには、インスタンス用のテナントネットワークが必要です。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 |
+-----------------------+-------------+--------------------------------------+

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

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 の設定を使用していない限りは、このオプションはデフォルトのままにしてください。

$ 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 |
+-----------------------+-------------+--------------------------------------+

Floating IP ネットワークは、デプロイ中に追加のブリッジをマッピングしている限り、br-ex だけでなく、任意のブリッジを使用できます。

たとえば、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

プロバイダーネットワークは、デプロイしたオーバークラウドの外部に存在するネットワークに物理的に接続されたネットワークです。これは、既存のインフラストラクチャーネットワークや、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 を使用するトラフィックをプロバイダーネットワークにルーティングできるようになります。

本ガイドの検証ステップは、インストール環境にフレーバーが含まれていることを前提としてます。まだ 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

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

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

$ 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

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

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

$ 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 テンプレートのあるスタックで各アイテムを更新します。オーバークラウドは再度作成されずに、既存のオーバークラウドに変更が加えられます。

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

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

既存の 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

Heat に含まれるコードベースのデフォルトポリシーセットは、/etc/heat/policy.json を作成してカスタムルールを追加することでオーバーライドすることができます。全員 のオーバークラウド削除権限を無効にするには、以下のポリシーを追加します。

{"stacks:delete": "rule:deny_everybody"}

これにより heat クライアントによるオーバークラウドの削除が阻止されます。オーバークラウドを削除できるように設定するには、カスタムポリシーを削除して /etc/heat/policy.json を保存します。

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

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

$ source ~/stackrc
(undercloud) $ openstack overcloud delete overcloud

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

(undercloud) $ openstack stack list

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

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

config-download 機能

Heat は、config-download を有効化する場合またはしない場合も、標準の機能を維持します。

Heat は SoftwareDeployment リソースから全デプロイメントデータを作成して、オーバークラウドのインストールと設定を行いますが、設定の適用は一切行いません。その代わりに、Heat は API からデータの提供のみを行います。スタックが作成されたら、Mistral ワークフローが Heat API に対してデプロイメントデータのクエリーを実行して、Ansible インベントリーファイルと生成された Playbook を使用して ansible-playbook を実行します。

以下の手順では、オーバークラウドの設定メソッドを OpenStack Orchestration (heat) から Ansible ベース config-download のメソッドに切り替えます。このような状況では、アンダークラウドは Ansible の control node (ansible-playbook を実行するノード) としての機能を果たします。control node とアンダークラウドという用語は、アンダークラウドのインストールが実行されるのと同じノードを指します。

事前にプロビジョニング済みのノードを使用する場合には、追加のステップを実行して、config-download を使用したデプロイメントが成功するようにします。

事前にプロビジョニング済みのノードで config-download を使用する場合には、Heat ベースのホスト名をそれらの実際のホスト名にマッピングして、ansible-playbook が解決されたホストに到達できるようにする必要があります。それらの値は、HostnameMap を使用してマッピングします。

Mistral は、config-download 機能の Ansible Playbook の実行を処理します。Mistral は Playbook、設定ファイル、ログを作業ディレクトリーに保存します。この作業ディレクトリーは /var/lib/mistral/ にあり、Mistral ワークフロー実行の UUID を使用して名前が付けられています。

これらの作業ディレクトリーにアクセスする前に、stack ユーザーに適切なアクセス権を設定する必要があります。

config-download の過程には、Ansible によってアンダークラウドの /var/lib/mistral/<execution uuid>/ansible.log にログファイルが作成されます。<execution uuid> は、ansible-playbook を実行した Mistral の実行に対応する UUID です。

/var/lib/mistral/ 内の各作業ディレクトリーには、ansible-playbook と直接対話するために必要な Playbook とスクリプトが含まれています。以下の手順では、これらのファイルとの対話方法について説明します。

標準の Heat ベースの設定メソッドに戻るには、次回に openstack overcloud deploy を実行する際に、関連するオプションと環境ファイルを削除します。

これで、通常のオーバークラウドの操作を続行できるようになりました。

Red Hat OpenStack Platform (RHOSP) director を使用して、Red Hat Virtualization クラスターにデプロイされたコントローラーノードを使用するオーバークラウドをプロビジョニングします。その後、これらの仮想コントローラーを仮想コントロールプレーンノードとしてデプロイできます。

以下のアーキテクチャー図は、仮想コントロールプレーンのデプロイ方法を示しています。オーバークラウドは、Red Hat Virtualization 上の仮想マシンで実行中のコントローラーノードに分散されます。コンピュートノードおよびストレージノードは、ベアメタル上で実行されます。

OpenStack Bare Metal Provisioning (ironic) サービスには、Red Hat Virtualization の仮想マシン用ドライバー staging-ovirt が含まれています。このドライバーを使用して、Red Hat Virtualization 環境内の仮想ノードを管理できます。このドライバーを使用して、Red Hat Virtualization 環境内の仮想マシンとしてオーバークラウドのコントローラーをデプロイすることもできます。

RHOSP オーバークラウドのコントロールプレーンを仮想化する利点は数多くありますが、すべての設定に適用できる訳ではありません。

本項では、RHOSP および Red Hat Virtualization を使用して、オーバークラウドの仮想 RHOSP コントロールプレーンをプロビジョニングする方法について説明します。

director のノードプールにさらにノードを追加するには、以下の手順を実施します。

特定ロールのオーバークラウドノード (たとえばコンピュートノード) をスケーリングするには、以下の手順を実施します。

状況によっては、オーバークラウドからコンピュートノードを削除する必要があります。たとえば、問題のあるコンピュートノードを置き換える必要がある場合などです。コンピュートノードを削除すると、スケールアウト操作中にインデックスが再利用されないように、ノードのインデックスがデフォルトで拒否リストに追加されます。

オーバークラウドデプロイメントからノードを削除した後、削除されたコンピュートノードを置き換えることができます。

director を使用して、director で作成したクラスター内の Ceph Storage ノードを置き換えることができます。手順については、コンテナー化された Red Hat Ceph を持つオーバークラウドのデプロイ を参照してください。

本項の手順で、クラスターの整合性を保ちながらオブジェクトストレージノードを置き換える方法を説明します。以下の例では、2 台のノードで設定されるオブジェクトストレージクラスターで、ノード overcloud-objectstorage-1 を置き換える必要があります。この手順の目的は、ノードを 1 台追加し、その後 overcloud-objectstorage-1 を削除することです (結果的に、置き換えることになります)。

director は、オーバークラウドからオブジェクトストレージノードを削除して、オーバークラウド上の残りのノードを更新し、ノードの削除に対応します。

オーバークラウドノードがデプロイメントの更新を受け取らないように除外することができます。これは、既存のノードがコア Heat テンプレートコレクションから更新されたパラメーターセットやリソースを受け取らないように除外した状態で、新規ノードをスケーリングする場合に役立ちます。つまり、ブラックリストに登録されているノードは、スタック操作の影響を受けなくなります。

ブラックリストを作成するには、環境ファイルの DeploymentServerBlacklist パラメーターを使います。

parameter_defaults:
  DeploymentServerBlacklist:
    - overcloud-compute-0
    - overcloud-compute-1
    - overcloud-compute-2

openstack overcloud deploy コマンドで、この環境ファイルを指定します。

$ source ~/stackrc
(undercloud) $ openstack overcloud deploy --templates \
  -e server-blacklist.yaml \
  [OTHER OPTIONS]

Heat はリスト内のサーバーをすべてブラックリストし、Heat デプロイメントの更新を受け取らないようにします。スタック操作が完了した後には、ブラックリストに登録されたサーバーは以前の状態のままとなります。操作中に os-collect-config エージェントの電源をオフにしたり、停止したりすることもできます。

parameter_defaults:
  DeploymentServerBlacklist: []

オーバークラウドコントローラーノードの置き換えを試みる前に、Red Hat OpenStack Platform 環境の現在の状態をチェックしておくことが重要です。このチェックしておくと、コントローラーの置き換えプロセス中に複雑な事態が発生するのを防ぐことができます。以下の事前チェックリストを使用して、コントローラーノードの置き換えを実行しても安全かどうかを確認してください。チェックのためのコマンドはすべてアンダークラウドで実行します。

コントローラーノードに障害が発生しても物理ディスクがまだ機能している特定のケースでは、ノード自体を交換せずに、バックアップまたはスナップショットからノードを復元できます。

ストレージクラスターから ceph-mon デーモンを削除するには、以下の手順に従います。コントローラーノードが Ceph monitor サービスを実行している場合には、以下のステップを完了して、ceph-mon デーモンを削除してください。この手順は、コントローラーが到達可能であることを前提としています。

古いノードを置き換える場合には、Pacemaker がノード上で実行されていないことを確認してからそのノードを Pacemaker クラスターから削除する必要があります。

障害が発生したコントローラーノードを再利用して、新しいノードとして再デプロイできます。交換に使用する余分なノードがない場合は、この方法を使用します。

障害が発生したノードは、ノードの交換および再デプロイの準備が整いました。ノードの交換を実行すると、障害が発生したノードは新しいノードとして機能し、増加したインデックスを使用します。たとえば、コントロールプレーンクラスターに overcloud-controller-0、overcloud-controller-1、および overcloud-controller-2 が含まれており、overcloud-controller-1 を新しいノードとして再利用する場合は、新しいノード名が overcloud-controller-3 となります。

障害が発生したコントローラーノードを新しいノードに交換できますが、同じ BMC IP アドレスを保持できます。障害が発生したノードを削除し、BMC IP アドレスを再割り当てし、新しいノードを新しいベアメタルレコードとして追加して、イントロスペクションを実行します。

古いコントローラーノードを削除して新規コントローラーノードに置き換えるには、以下の手順を実施します。

ノードの置き換えが完了したら、以下の手順を実施してコントローラークラスターの最終処理を行います。

以下の手順では、アンダークラウドノードをリブートします。

以下の手順では、コントローラーノードと、コンポーザブルロールをベースとするスタンドアロンのノードをリブートします。これには、コンピュートノードと Ceph Storage ノードは含まれません。

クラスター内の各 MON ノードで、この手順を繰り返します。

以下の手順では、Ceph Storage (OSD) ノードのクラスターをリブートします。

次の手順では、Object Storage サービス (swift) ノードを再起動します。クラスター内のすべてのオブジェクトストレージノードに対して、次の手順を実行します。

コンピュートノードをリブートするには、以下のワークフローを実施します。

ノード登録における問題は通常、ノードの情報が間違っていることが原因で発生します。このような場合には、ironic を使用して、登録したノードデータの問題を修正します。以下にいくつか例を示します。

割り当てられたポートの UUID を確認します。

$ source ~/stackrc
(undercloud) $ openstack baremetal port list --node [NODE UUID]

MAC アドレスを更新します。

(undercloud) $ openstack baremetal port set --address=[NEW MAC] [PORT UUID]

次のコマンドを実行します。

(undercloud) $ openstack baremetal node set --driver-info ipmi_address=[NEW IPMI ADDRESS] [NODE UUID]

イントロスペクションのプロセスは最後まで実行する必要があります。ただし、Ironic の Discovery Daemon (ironic-inspector) は、discovery ramdisk が応答しない場合にはデフォルトの 1 時間が経過するとタイムアウトします。discovery ramdisk のバグが原因とされる場合もありますが、通常は特に BIOS のブート設定などの環境の誤設定が原因で発生します。

以下には、環境設定が間違っている場合の一般的なシナリオと、診断/解決方法に関するアドバイスを示します。

$ source ~/stackrc
(undercloud) $ openstack baremetal node manage [NODE UUID]

検出が完了したら、状態を AVAILABLE に戻してからプロビジョニングを行います。

(undercloud) $ openstack baremetal node provide [NODE UUID]

$ source ~/stackrc
(undercloud) $ openstack baremetal introspection abort [NODE UUID]

プロセスがタイムアウトするまで待つことも可能です。必要であれば、/etc/ironic-inspector/inspector.conf の timeout 設定を別の時間 (秒単位) に変更します。

$ sudo systemctl list-units openstack-swift*

OpenStack Workflow (mistral) サービスは、複数の OpenStack タスクをワークフローにグループ化します。Red Hat OpenStack Platform は、これらのワークフローセットを使用して、CLI と Web UI で共通の機能を実行します。これには、ベアメタルノードの制御、検証、プラン管理、オーバークラウドのデプロイメントが含まれます。

たとえば openstack overcloud deploy コマンドを実行すると、OpenStack Workflow サービスは 2 つのワークフローを実行します。最初のワークフローは、デプロイメントプランをアップロードします。

Removing the current plan files
Uploading new plan files
Started Mistral Workflow. Execution ID: aef1e8c6-a862-42de-8bce-073744ed5e6b
Plan updated

2 つ目のワークフローは、オーバークラウドのデプロイメントを開始します。

Deploying templates in the directory /tmp/tripleoclient-LhRlHX/tripleo-heat-templates
Started Mistral Workflow. Execution ID: 97b64abe-d8fc-414a-837a-1380631c764d
2016-11-28 06:29:26Z [overcloud]: CREATE_IN_PROGRESS  Stack CREATE started
2016-11-28 06:29:26Z [overcloud.Networks]: CREATE_IN_PROGRESS  state changed
2016-11-28 06:29:26Z [overcloud.HeatAuthEncryptionKey]: CREATE_IN_PROGRESS  state changed
2016-11-28 06:29:26Z [overcloud.ServiceNetMap]: CREATE_IN_PROGRESS  state changed
...

$ source ~/stackrc
(undercloud) $ openstack workflow execution list | grep "ERROR"

失敗したワークフローの実行の UUID を取得して (例: dffa96b0-f679-4cd2-a490-4769a3825262)、実行とその出力を表示します。

(undercloud) $ openstack workflow execution show dffa96b0-f679-4cd2-a490-4769a3825262
(undercloud) $ openstack workflow execution output show dffa96b0-f679-4cd2-a490-4769a3825262

これにより、実行で失敗したタスクに関する情報を取得できます。openstack workflow execution show は、実行に使用したワークフローも表示します (例: tripleo.plan_management.v1.publish_ui_logs_to_swift)。以下のコマンドを使用して完全なワークフロー定義を表示することができます。

(undercloud) $ openstack workflow definition show tripleo.plan_management.v1.publish_ui_logs_to_swift

これは、特定のタスクがワークフローのどの部分で発生するかを特定する際に便利です。

同様のコマンド構文を使用して、アクションの実行と、その結果を表示することもできます。

(undercloud) $ openstack action execution list
(undercloud) $ openstack action execution show 8a68eba3-0fec-4b2a-adc9-5561b007e886
(undercloud) $ openstack action execution output show 8a68eba3-0fec-4b2a-adc9-5561b007e886

これは、問題を引き起こす固有のアクションを特定する際に便利です。

デプロイメントが失敗する可能性のあるレイヤーは 3 つあります。

オーバークラウドのデプロイメントがこれらのレベルのいずれかで失敗した場合には、OpenStack クライアントおよびサービスログファイルを使用して、失敗したデプロイメントの診断を行います。以下のコマンドを実行して、エラーの詳細を表示することもできます。

$ openstack stack failures list <OVERCLOUD_NAME> --long

<OVERCLOUD_NAME> を実際のオーバークラウドの名前に置き換えてください。

$ source ~/stackrc
(undercloud) $ openstack stack list --nested --property status=FAILED
+-----------------------+------------+--------------------+----------------------+
| id                    | stack_name | stack_status       | creation_time        |
+-----------------------+------------+--------------------+----------------------+
| 7e88af95-535c-4a55... | overcloud  | CREATE_FAILED      | 2015-04-06T17:57:16Z |
+-----------------------+------------+--------------------+----------------------+

$ source ~/stackrc
(undercloud) $ openstack baremetal node list

+----------+------+---------------+-------------+-----------------+-------------+
| UUID     | Name | Instance UUID | Power State | Provision State | Maintenance |
+----------+------+---------------+-------------+-----------------+-------------+
| f1e261...| None | None          | power off   | available       | False       |
| f0b8c1...| None | None          | power off   | available       | False       |
+----------+------+---------------+-------------+-----------------+-------------+

$ source ~/stackrc
(undercloud) $ openstack stack resource list overcloud --filter status=FAILED

(undercloud) $ openstack stack resource show overcloud [FAILED RESOURCE]

(undercloud) $ openstack server list

(undercloud) $ ssh heat-admin@192.168.24.14

[heat-admin@overcloud-controller-0 ~]$ sudo journalctl -u os-collect-config

(undercloud) $ openstack server list
(undercloud) $ openstack server show [SERVER ID]

宛先のホストに、すでに使用中の IP アドレスが割り当てられている場合には、検出およびデプロイメントのタスクは失敗します。この問題を回避するには、プロビジョニングネットワークのポートスキャンを実行して、検出の IP アドレス範囲とホストの IP アドレス範囲が解放されているかどうかを確認することができます。

アンダークラウドホストで以下のステップを実行します。

nmap をインストールします。

$ sudo yum install nmap

nmap を使用して、アクティブなアドレスの IP アドレス範囲をスキャンします。この例では、192.168.24.0/24 の範囲をスキャンします。この値は、プロビジョニングネットワークの IP サブネットに置き換えてください (CIDR 表記のビットマスク)。

$ sudo nmap -sn 192.168.24.0/24

nmap スキャンの出力を確認します。

たとえば、アンダークラウドおよびサブネット上に存在するその他のホストの IP アドレスを確認する必要があります。アクティブな IP アドレスが undercloud.conf の IP アドレス範囲と競合している場合には、オーバークラウドノードのイントロスペクションまたはデプロイを実行する前に、IP アドレスの範囲を変更するか、IP アドレスを解放するかのいずれかを行う必要があります。

$ sudo nmap -sn 192.168.24.0/24

Starting Nmap 6.40 ( http://nmap.org ) at 2015-10-02 15:14 EDT
Nmap scan report for 192.168.24.1
Host is up (0.00057s latency).
Nmap scan report for 192.168.24.2
Host is up (0.00048s latency).
Nmap scan report for 192.168.24.3
Host is up (0.00045s latency).
Nmap scan report for 192.168.24.5
Host is up (0.00040s latency).
Nmap scan report for 192.168.24.9
Host is up (0.00019s latency).
Nmap done: 256 IP addresses (5 hosts up) scanned in 2.45 seconds

/var/log/nova/nova-conductor.log に、以下のエラーが含まれる場合があります。

NoValidHost: No valid host was found. There are not enough hosts available.

これは、Nova Scheduler が新規インスタンスをブートするのに適したベアメタルノードを検出できなかったことを意味します。このような場合、通常は、Nova が検出を想定しているリソースと Ironic が Nova に通知するリソースが一致しなくなります。その際には、以下の点をチェックしてください。

オーバークラウドを作成した後には、将来そのオーバークラウドで特定の操作を行うようにすることができます。たとえば、利用可能なノードをスケーリングしたり、障害の発生したノードを置き換えたりすることができます。このような操作を行うと、特定の問題が発生する場合があります。本項には、オーバークラウド作成後の操作が失敗した場合の診断とトラブルシューティングに関するアドバイスを記載します。

$ sudo docker logs keystone

$ sudo docker inspect keystone

$ sudo docker inspect keystone | jq .[0].Mounts

$ sudo docker inspect --format='{{range .Config.Env}} -e "{{.}}" {{end}} {{range .Mounts}} -v {{.Source}}:{{.Destination}}{{if .Mode}}:{{.Mode}}{{end}}{{end}} -ti {{.Config.Image}}' keystone

$ OPTIONS=$( sudo docker inspect --format='{{range .Config.Env}} -e "{{.}}" {{end}} {{range .Mounts}} -v {{.Source}}:{{.Destination}}{{if .Mode}}:{{.Mode}}{{end}}{{end}} -ti {{.Config.Image}}' keystone )
$ sudo docker run --rm $OPTIONS /bin/bash

$ sudo docker exec -ti keystone <COMMAND>

$ sudo docker exec -ti keystone /openstack/healthcheck

$ sudo docker exec -ti keystone /bin/bash

$ sudo docker export keystone -o keystone.tar

このセクションでのアドバイスは、アンダークラウドのパフォーマンスを向上に役立たせることが目的です。必要に応じて、推奨事項を実行してください。

Red Hat に連絡して OpenStack Platform に関するサポートを受ける必要がある場合は、SOS レポート を生成する必要がある場合があります。SOS レポート の作成方法についての詳しい説明は、以下のナレッジベースのアーティクルを参照してください。

以下のログを使用して、トラブルシューティングの際にアンダークラウドとオーバークラウドの情報を割り出します。