アンダークラウド は、最終的な OpenStack Platform 環境 (オーバークラウド と呼ばれる) の設定、インストール、および管理をコントロールするノードです。アンダークラウド自体は、コンテナー化された OpenStack Platform コンポーネントを使用して、OpenStack Platform director と呼ばれるツールセットを作成します。この場合、アンダークラウドはレジストリーソースからコンテナーイメージのセットをプルし、コンテナーの設定を生成し、各 OpenStack Platform サービスをコンテナーとして実行します。その結果、アンダークラウドにより、オーバークラウドを作成/管理するためのツールセットとして機能する、コンテナー化されたサービスのセットが提供されます。

アンダークラウドおよびオーバークラウドの両方でコンテナーが使用されているので、どちらも同じアーキテクチャーを使用してコンテナーをプル、設定、および実行します。このアーキテクチャーは、ノードプロビジョニング用の OpenStack Orchestration サービス (Heat とも呼ばれる) ならびにサービスおよびコンテナー設定用の Ansible をベースにしています。異常発生時のトラブルシューティングに役立つので、Heat および Ansible に関する知識を習得することを推奨します。

アンダークラウドでは、2 つの主要ネットワークへのアクセスが必要です。

結果的に、アンダークラウドには少なくとも 2 枚の 1 Gbps ネットワークインターフェースカードが必要です。ただし、特にオーバークラウド環境で多数のノードをプロビジョニングする場合には、プロビジョニングネットワークのトラフィック用に 10 Gbps インターフェースの使用を推奨します。

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

アンダークラウドをインストールする前に、環境の規模を判断することが重要です。検討すべき項目を以下に示します。

アンダークラウドの CPU およびメモリーの最低要件を以下に示します。

より多くのワーカーを使用する場合には、アンダークラウドにより多くの仮想 CPU およびメモリーが必要になります。以下の要件に従ってください。

アンダークラウド用として、ルートディスク上に少なくとも 100 GB の空きディスク領域があることが推奨されます。この領域の内訳は以下のとおりです。

アンダークラウドのインストールおよび設定には、以下のリポジトリーが必要です。

director のインストールには、以下の項目が必要です。

アンダークラウドの設定には、イメージの取得先およびその保存方法を定義するための初期レジストリーの設定が必要です。以下のプロセスで、コンテナーイメージを準備するための環境ファイルを生成およびカスタマイズする方法を説明します。

コンテナー準備用のこのデフォルトファイル (containers-prepare-parameter.yaml) には、ContainerImagePrepare Heat パラメーターが含まれます。このパラメーターで、イメージのセットを準備するためのさまざまな設定を定義します。

parameter_defaults:
  ContainerImagePrepare:
  - (strategy one)
  - (strategy two)
  - (strategy three)
  ...

それぞれの設定では、サブパラメーターのセットにより使用するイメージやイメージの使用方法を定義することができます。ContainerImagePrepare の各設定で使用するサブパラメーターの一覧を、以下の表に示します。

set パラメーターには、複数の キー:値 定義を設定することができます。それらのキーの一覧を、以下の表に示します。

ContainerImagePrepare の値は YAML リストです。したがって、複数のエントリーを指定することができます。以下の例で、2 つのエントリーを指定するケースを説明します。この場合、director はすべてのイメージの最新バージョンを使用しますが、nova-api イメージについてのみ、14.0-44 とタグ付けされたバージョンを使用します。

ContainerImagePrepare:
- tag_from_label: "{version}-{release}"
  push_destination: true
  excludes:
  - nova-api
  set:
    namespace: registry.access.redhat.com/rhosp14
    name_prefix: openstack-
    name_suffix: ''
    tag: latest
- push_destination: true
  includes:
  - nova-api
  set:
    namespace: registry.access.redhat.com/rhosp14
    tag: 14.0-44

includes および excludes のエントリーで、それぞれのエントリーでのイメージ絞り込み方法をコントロールします。includes 設定と一致するイメージが、excludes と一致するイメージに優先します。一致するとみなされるためには、イメージ名に設定値が含まれていなければなりません。

準備プロセス中にイメージを変更して必要な修正を加え、直ちにこれらの変更を反映してデプロイすることが可能です。イメージを変更するユースケースを以下に示します。

変更が必要な各イメージで Ansible ロールを呼び出して、変更を行います。ロールはソースイメージを取得して必要な変更を行った後に、その結果をタグ付けします。続いて prepare コマンドでイメージをプッシュし、変更したイメージを参照するように heat パラメーターを設定することができます。

Ansible ロール tripleo-modify-image は要求されたロールインターフェースに従い、変更のユースケースに必要な処理を行います。変更は、ContainerImagePrepare パラメーターの modify 固有のキーでコントロールします。

ロール tripleo-modify-image が処理する別のユースケースを選択するには、tasks_from 変数をそのロールで必要なファイルに設定します。

イメージを変更する ContainerImagePrepare エントリーを開発およびテストする場合には、イメージが想定どおりに変更されていることを確認するために、prepare コマンド単体で実行することを推奨します。

sudo openstack tripleo container image prepare \
  -e ~/containers-prepare-parameter.yaml

以下のエントリーにより、イメージのパッケージが全て更新されます。ただし、アンダークラウドホストの yum リポジトリー設定が使用されます。

ContainerImagePrepare:
- push_destination: true
  ...
  modify_role: tripleo-modify-image
  modify_append_tag: "-updated"
  modify_vars:
    tasks_from: yum_update.yml
    compare_host_packages: true
    yum_repos_dir_path: /etc/yum.repos.d
  ...

RPM ファイルのディレクトリーをインストールすることができます。この機能は、ホットフィックス、ローカルパッケージビルド、またはパッケージリポジトリーからは入手できないパッケージのインストールに役立ちます。たとえば、以下のエントリーにより、centos-binary-nova-compute イメージだけにホットフィックスパッケージがインストールされます。

ContainerImagePrepare:
- push_destination: true
  ...
  includes:
  - nova-compute
  modify_role: tripleo-modify-image
  modify_append_tag: "-hotfix"
  modify_vars:
    tasks_from: rpm_install.yml
    rpms_path: /home/stack/nova-hotfix-pkgs
  ...

柔軟性を高めるために、Dockerfile を含むディレクトリーを指定して必要な変更を加えることが可能です。ロールが呼び出されると、Dockerfile.modified ファイルが生成され、これにより FROM ディレクティブが変更され新たな LABEL ディレクティブが追加されます。以下の例では、centos-binary-nova-compute イメージでカスタム Dockerfile が実行されます。

ContainerImagePrepare:
- push_destination: true
  ...
  includes:
  - nova-compute
  modify_role: tripleo-modify-image
  modify_append_tag: "-hotfix"
  modify_vars:
    tasks_from: modify_image.yml
    modify_dir_path: /home/stack/nova-custom
  ...

/home/stack/nova-custom/Dockerfile の例を以下に示します。USER root ディレクティブを実行した後は、元のイメージのデフォルトユーザーに戻す必要があります。

FROM docker.io/tripleomaster/centos-binary-nova-compute:latest

USER root

COPY customize.sh /tmp/
RUN /tmp/customize.sh

USER "nova"

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

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

Satellite 固有のパラメーターが含まれる環境ファイルの例を以下に示します。

parameter_defaults:
  ContainerImagePrepare:
  - push_destination: true
    set:
      ceph_image: acme-production-myosp14-osp14_containers-rhceph-3-rhel7
      ceph_namespace: satellite.example.com:5000
      ceph_tag: latest
      name_prefix: acme-production-myosp14-osp14_containers-
      name_suffix: ''
      namespace: satellite.example.com:5000
      neutron_driver: null
      tag: latest
      ...
    tag_from_label: '{version}-{release}'

アンダークラウドおよびオーバークラウドの両方を作成する際に、この環境ファイルを使用します。

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 をインストールしてインストール後の基本的なタスクを実行します。

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

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

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

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

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

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

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

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

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

デフォルトでは、director は接続に プロビジョニング / コントロールプレーン を使用するようにノードを設定します。ただし、ネットワークトラフィックを一連の コンポーザブルネットワーク に分離し、カスタマイズしてサービスを割り当てることができます。

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

director には、NIC を分離コンポーザブルネットワークと連携させるための、さまざまなテンプレートも用意されています。

専用のテンプレートを作成して、特定の NIC 構成をマッピングすることもできます。

ネットワーク構成を検討する上で、以下の点を考慮することも重要です。

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

OpenStack Platform の実装のセキュリティーレベルは、その環境のセキュリティーレベルと同等です。ネットワーク環境内の適切なセキュリティー原則に従って、ネットワークアクセスが正しく制御されるようにします。以下に例を示します。

システムのセキュリティー保護については、以下のドキュメントを参照してください。

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

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

コントローラーノードは、Red Hat OpenStack Platform 環境の中核となるサービス (例: Horizon Dashboard、バックエンドのデータベースサーバー、Keystone 認証、高可用性サービスなど) をホストする役割を果たします。

コンピュートノードは、仮想マシンインスタンスが起動した後にそれらを稼働させる役割を果たします。コンピュートノードは、ハードウェアの仮想化をサポートしている必要があります。また、ホストする仮想マシンインスタンスの要件をサポートするのに十分なメモリーとディスク容量も必要です。

Ceph Storage ノードは、Red Hat OpenStack Platform 環境でオブジェクトストレージを提供する役割を果たします。

Ceph Storage クラスターを使用するオーバークラウドのインストールについては、『Deploying an Overcloud with Containerized Red Hat Ceph』を参照してください。

オブジェクトストレージノードは、オーバークラウドのオブジェクトストレージ層を提供します。Object Storage プロキシーは、コントローラーノードにインストールされます。ストレージ層には、ノードごとに複数のディスクを持つベアメタルノードが必要です。

アンダークラウドのインストールおよび設定には、以下のリポジトリーが必要です。

director では、手動で作成したノード定義のテンプレートが必要です。このファイルは JSON または YAML 形式を使用し、ノードのハードウェアおよび電源管理の情報が含まれます。

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

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

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

デフォルトのブートモードは、レガシー BIOS モードです。新しいシステムでは、レガシー BIOS モードの代わりに UEFI ブートモードが必要な可能性があります。以下の手順を使用して、UEFI モードに変更します。

一部のノードでは、複数のディスクが使用される場合があります。このため、director はプロビジョニング中ルートディスクとして使用するディスクを特定する必要があります。プロビジョニングプロセス中、director は QCOW2 overcloud-full イメージをルートディスクに書き込みます。

director がルートディスクを容易に特定できるようにするには、以下のようなプロパティーを使用することができます。

シリアル番号を使用してルートデバイスを指定する方法を、以下の例で説明します。

マルチアーキテクチャークラウドをビルドする場合には、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

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

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

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

これ以降の数セクションで、オーバークラウドに必要な環境ファイルを作成する方法について説明します。

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

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

アンダークラウドで使用することのできるカスタム証明書には、2 つのタイプがあります。

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

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

以下の表では、openstack overcloud deploy コマンドを使用する際の追加パラメーターを一覧表示します。

オプションの完全一覧については、以下のコマンドを実行します。

(undercloud) $ openstack help overcloud deploy

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

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

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

-e オプションを使用してオーバークラウドに追加した環境ファイルは、すべてオーバークラウドのスタック定義の一部となります。

以下のコマンドは、本シナリオの初期に定義した環境ファイルを使用してオーバークラウドの作成を開始する方法の一例です。

(undercloud) $ openstack overcloud deploy --templates \
  -e /home/stack/templates/node-info.yaml\
  -e /home/stack/templates/overcloud_images.yaml \
  -e /home/stack/inject-trust-anchor-hiera.yaml
  -r /home/stack/templates/roles_data.yaml \

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

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

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

オーバークラウドを手動で編集しても、director を使用してオーバークラウドスタックの更新を行う際に director の設定で上書きされてしまうので、設定は直接編集しないでください。

オーバークラウドのデプロイメント操作を実行する前に、Heat テンプレートと環境ファイルにエラーがないかどうかを検証します。

オーバークラウドの作成が完了すると、オーバークラウドを設定するために実施された Ansible のプレイの概要が director により提示されます。

PLAY RECAP *************************************************************
overcloud-compute-0     : ok=160  changed=67   unreachable=0    failed=0
overcloud-controller-0  : ok=210  changed=93   unreachable=0    failed=0
undercloud              : ok=10   changed=7    unreachable=0    failed=0

Tuesday 15 October 2018  18:30:57 +1000 (0:00:00.107) 1:06:37.514 ******
========================================================================

director により、オーバークラウドへのアクセス情報も提供されます。

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

(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 経由で undercloud.conf ファイルの undercloud_public_host パラメーターに設定した IP アドレスからアクセスします。たとえば、アンダークラウドのパブリック IP アドレスが 192.168.24.2 の場合には、https://192.168.24.2 から UI にアクセスすることができます。

Web UI はまず、以下のフィールドが含まれるログイン画面を表示します。

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

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

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

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

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

アンダークラウドのインストールと設定を実行すると、プランが自動的にアップロードされます。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 つの主要なタブが表示されます。

オーバークラウド用コンテナーイメージを準備するには、以下の手順を使用して詳細を定義します。

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

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

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

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

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

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

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

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

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

ノードごとに Red Hat サブスクリプションへのアクセスが必要です。以下の手順は、各ノードを Red Hat コンテンツ配信ネットワークに登録する方法を説明しています。各ノードで以下の手順を実行してください。

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

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-ctlplane:
      fixed_ips:
        - ip_address: 192.168.24.2
      subnets:
        - cidr: 24
    compute-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 アドレスの割り当てを使用します。

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

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
    controller0-ctlplane:
      fixed_ips:
        - ip_address: 192.168.100.2
      subnets:
        - cidr: 24
    compute0-ctlplane:
      fixed_ips:
        - ip_address: 192.168.100.3
      subnets:
        - cidr: 24

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

オーバークラウドのデプロイメントには、「デプロイメントコマンド」に記載の標準の 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 \
  -e /home/stack/templates/hostname-map.yaml /
  -r /usr/share/openstack-tripleo-heat-templates/deployed-server/deployed-server-roles-data.yaml
  --overcloud-ssh-user stack \
  --overcloud-ssh-key ~/.ssh/id_rsa \
  [OTHER OPTIONS]

--overcloud-ssh-user および --overcloud-ssh-key オプションは、設定ステージ中に各オーバークラウドノードに SSH 接続して、初期 tripleo-admin ユーザーを作成し、SSH キーを /home/tripleo-admin/.ssh/authorized_keys に挿入するのに使用します。SSH キーを挿入するには、初回の SSH 接続で --overcloud-ssh-user と --overcloud-ssh-key (~/.ssh/id_rsa がデフォルト) を使用して認証情報を指定します。--overcloud-ssh-key で指定した秘密鍵の公開を制限するために、director は Heat や Mistral などのどの API サービスにもこの鍵を渡さず、openstack overcloud deploy コマンドのみがこの鍵を使用して tripleo-admin ユーザーのアクセスを有効化します。

オーバークラウドの作成が完了すると、オーバークラウドを設定するために実施された Ansible のプレイの概要が director により提示されます。

PLAY RECAP *************************************************************
overcloud-compute-0     : ok=160  changed=67   unreachable=0    failed=0
overcloud-controller-0  : ok=210  changed=93   unreachable=0    failed=0
undercloud              : ok=10   changed=7    unreachable=0    failed=0

Tuesday 15 October 2018  18:30:57 +1000 (0:00:00.107) 1:06:37.514 ******
========================================================================

director により、オーバークラウドへのアクセス情報も提供されます。

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

(undercloud) $ source ~/overcloudrc

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

(overcloud) $

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

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

事前にプロビジョニングされたノードをスケーリングするプロセスは、「11章オーバークラウドノードのスケーリング」に記載の標準のスケーリングの手順と似ていますが、事前にプロビジョニングされたノードを新たに追加するプロセスは異なります。これは、事前にプロビジョニングされたノードが 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 overcloud status コマンドを使用します。このコマンドの出力に、全デプロイメントステップの結果が表示されます。

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

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

オーバークラウドには、インスタンス用のテナントネットワークが必要です。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 だけでなく、どのブリッジにも使用することができます。

オーバークラウドの作成後に 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 度実行します。たとえば、「デプロイメントコマンド」の方法を使用してオーバークラウドを作成した場合には、以下のコマンドを再度実行します。

$ 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 を使用すると、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

オーバークラウドのコンピュートノードでメンテナンスを行う場合があります。ダウンタイムを防ぐには、そのコンピュートノード上の仮想マシンを同じオーバークラウド内の別のコンピュートノードに移行します。

director は、すべてのコンピュートノードがセキュアな移行を提供するように設定します。全コンピュートノードには、各ホストの nova ユーザーが移行プロセス中に他のコンピュートノードにアクセスすることができるようにするための共有 SSH キーも必要です。director は、OS::TripleO::Services::NovaCompute コンポーザブルサービスを使用してこのキーを作成します。このコンポーザブルサービスは、全コンピュートロールにデフォルトで含まれているメインのサービスの 1 つです (『オーバークラウドの高度なカスタマイズ』の「コンポーザブルサービスとカスタムロール」を参照)。

これにより、コンピュートノードからすべてのインスタンスが移行されます。インスタンスのダウンタイムなしにノードでメンテナンスを実行できるようになります。コンピュートノードを有効な状態に戻すには、以下のコマンドを実行します。

$ source ~/overcloudrc
(overcloud) $ openstack compute service set [hostname] nova-compute --enable

heat stack-delete overcloud コマンドで誤って削除されないように、Heat には特定のアクションを制限するポリシーセットが含まれます。/etc/heat/policy.json を開いて、以下のパラメーターを検索します。

"stacks:delete": "rule:deny_stack_user"

このパラメーターの設定を以下のように変更します。

"stacks:delete": "rule:deny_everybody"

ファイルを保存します。

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

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

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

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

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

(undercloud) $ openstack stack list

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

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

Identity サービス (keystone) は、他の OpenStack サービスに対するアクセス制御にトークンベースのシステムを使用します。ある程度の期間が過ぎた後には、データベースに未使用のトークンが多数蓄積されます。デフォルトの cronjob は毎日トークンをフラッシュします。環境をモニタリングして、必要に応じてトークンのフラッシュ間隔を調節することを推奨します。

オーバークラウドでは、KeystoneCronToken の値を使用して間隔を調整することができます。詳しい情報は、『オーバークラウドのパラメーター』を参照してください。

config-download の機能により、director はオーバークラウドを設定します。director は OpenStack Orchestration サービス (heat) および OpenStack Workflow サービス (mistral) と共に config-download を使用し、ソフトウェア設定を生成して各オーバークラウドノードに適用します。Heat は SoftwareDeployment リソースから全デプロイメントデータを作成して、オーバークラウドのインストールと設定を行いますが、設定の適用は一切行いません。Heat は API から設定データの提供のみを行います。director によりスタックが作成されたら、Mistral ワークフローが Heat API に対して設定データ取得のクエリーを実行し、Ansible Playbook のセットを生成してオーバークラウドに適用します。

結果として、openstack overcloud deploy コマンドを実行すると、以下のプロセスが実行されます。

director により、config-download プロセス用に Ansible Playbook のセットが生成されます。これらの Playbook は /var/lib/mistral/ 内の作業ディレクトリーに保管されます。このディレクトリーには、オーバークラウドの名前が付けられます。したがって、デフォルトでは overcloud です。

作業ディレクトリーには、各オーバークラウドロールの名前が付けられた複数のサブディレクトリーが存在します。これらのサブディレクトリーには、オーバークラウドロールのノードの設定に関連するすべてのタスクが含まれます。さらに、これらのサブディレクトリーには、特定のノードの名前が付けられたサブディレクトリーが存在します。これらのサブディレクトリーには、オーバークラウドロールのタスクに適用するノード固有の変数が含まれます。したがって、作業ディレクトリー内のオーバークラウドロールは、以下のような構成になります。

─ /var/lib/mistral/overcloud
       │
       ├─── Controller
       │   ├── overcloud-controller-0
       │   ├── overcloud-controller-1
       │   └── overcloud-controller-2
       ├─── Compute
       │   ├── overcloud-compute-0
       │   ├── overcloud-compute-1
       │   └── overcloud-compute-2
       ...

それぞれの作業ディレクトリーは、各デプロイメント操作後の変更を記録するローカルの Git リポジトリーとしても機能します。このことは、各デプロイメント間の設定変更を追跡するのに役立ちます。

/var/lib/mistral/ にある作業ディレクトリー内の全ファイルの所有者は、OpenStack Workflow サービス (mistral) コンテナーの mistral ユーザーです。アンダークラウドの stack ユーザーに、このディレクトリー内の全ファイルへのアクセス権限を付与することができます。この設定は、ディレクトリー内の特定操作を実施するのに役立ちます。

config-download プロセス中、Ansible によりアンダークラウド内の config-download の作業ディレクトリーにログファイルが作成されます。

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

config-download の作業ディレクトリーは、ローカルの Git リポジトリーとして機能します。デプロイメント操作を実行するたびに、director は該当する変更に関する Git コミットを作業ディレクトリーに追加します。これにより、Git 操作を実施して、さまざまなステージでのデプロイメント設定を表示したり、異なるデプロイメント間で設定を比較したりすることができます。

作業ディレクトリーには制約がある点に注意してください。たとえば、Git を使用して config-download の作業ディレクトリーを前のバージョンに戻しても、作業ディレクトリー内の設定が影響を受けるだけで、以下の設定は影響を受けません。

以下の手順で、Git を使用して config-download の作業ディレクトリー内の異なるコミットを比較する方法を説明します。

特定の状況では、標準のワークフローとは別に専用の config-download ファイルを生成する場合があります。たとえば、個別に設定を適用できるように、openstack overcloud deploy コマンドに --stack-only オプションを設定して、オーバークラウド Heat スタックを生成することがあります。以下の手順では、専用の config-download ファイルを手動で作成する方法について説明します。

これにより、手動で生成した config-download ファイルを使用して設定を実施するのに必要なファイルが得られます。デプロイメント用の Playbook を実行するには、ansible-playbook コマンドを実行します。

$ ansible-playbook \
  -i inventory.yaml \
  --private-key ~/.ssh/id_rsa \
  --become \
  ~/config-download/deploy_steps_playbook.yaml

この設定から手動で overcloudrc ファイルを生成するには、以下のコマンドを実行します。

$ openstack action execution run \
  --save-result \
  --run-sync \
  tripleo.deployment.overcloudrc \
  '{"container":"overcloud"}' \
  | jq -r '.["result"]["overcloudrc.v3"]' > overcloudrc.v3

config-download の作業ディレクトリー内の主要なファイルを以下に示します。

Playbook では、オーバークラウドに適用されるタスクを管理するのにタグ付けされたタスクを使用します。ansible-playbook CLI の引数 --tags または --skip-tags でタグを使用して、実行するタスクを管理します。有効なタグを以下に示します。

オーバークラウドの設定には、deploy_steps_playbook.yaml Playbook が使用されます。この Playbook により、オーバークラウドデプロイメントプランに基づき完全なオーバークラウドをデプロイするのに必要なすべてのソフトウェア設定が適用されます。

本項では、この Playbook で使用されるさまざまな Ansible プレイの概要について説明します。本項のプレイと同じ名前が、Playbook 内で使用され ansible-playbook の出力にも表示されます。各プレイに設定される Ansible タグも、以下に示します。

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

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

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

オーバークラウドからコンピュートノードを削除する必要がある状況が出てくる可能性があります。たとえば、問題のあるコンピュートノードを置き換える必要がある場合などです。

オーバークラウドから自由にノードを削除して、別の目的でそのノードを再プロビジョニングすることができます。

director を使用して、director で作成したクラスター内の Ceph Storage ノードを置き換えることができます。手順については、『Deploying an Overcloud with Containerized Red Hat Ceph』を参照してください。

本項の手順で、クラスターの整合性を保ちながらオブジェクトストレージノードを置き換える方法を説明します。以下の例では、3 台のノードで構成されるオブジェクトストレージクラスターで、ノード 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-1 ノードを overcloud-controller-3 ノードに置き換えるには、以下の手順例を実施します。overcloud-controller-3 ノードの ID は 75b25e9a-948d-424a-9b3b-f0ef70a6eacf です。

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

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

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

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

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

以下の手順では、コンピュートノードをリブートします。OpenStack Platform 環境内のインスタンスのダウンタイムを最小限に抑えるために、この手順には、選択したコンピュートノードからインスタンスを移行するステップも含まれています。これは、以下のワークフローを伴います。

available の状態のノードで個別にイントロスペクションを実行するには、ノードを管理モードに設定して、イントロスペクションを実行します。

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

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

--provide オプションを指定したので、初回のイントロスペクションの後には、全ノードが available の状態に入るはずです。初回のイントロスペクション後に全ノードにイントロスペクションを実行するには、すべてのノードを manageable の状態にして、一括のイントロスペクションコマンドを実行します。

(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 の状態に変わります。

ネットワークイントロスペクションにより、Link Layer Discovery Protocol (LLDP) データがネットワークスイッチから取得されます。以下のコマンドにより、ノード上の全インターフェースに関する LLDP 情報のサブセット、または特定のノードおよびインターフェースに関するすべての情報が表示されます。この情報は、トラブルシューティングに役立ちます。director では、デフォルトで LLDP データ収集が有効になっています。

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

(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 コレクターは、このハードウェア inspection_extras の一部で、各 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
    }
  ]
}

異種のハードウェアが混在する環境では、イントロスペクションルールを使って、認証情報の割り当てやリモート管理を行うことができます。たとえば、DRAC を使用する Dell ノードを処理するには、別の検出ルールが必要になる場合があります。

ノード登録における問題は通常、ノードの情報が間違っていることが原因で発生します。このような場合には、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) は、検出する ramdisk が応答しない場合にはデフォルトの 1 時間が経過するとタイムアウトします。検出する 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 クライアントおよびサービスログファイルを使用して、失敗したデプロイメントの診断を行います。

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

宛先のホストに、すでに使用中の 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 レポート の作成方法についての詳しい説明は、以下のナレッジベースの記事を参照してください。

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