Red Hat Training
A Red Hat training course is available for Red Hat OpenStack Platform
第8章 事前にプロビジョニングされたノードを使用した基本的なオーバークラウドの設定
本章では、OpenStack Platform 環境を設定します。事前にプロビジョニングされたノードを使用して OpenStack Platform 環境を設定する基本的な手順を説明します。以下のシナリオは、標準のオーバークラウド作成のシナリオとはさまざまな点で異なります。
- 外部ツールを使用してノードをプロビジョニングしてから、director でオーバークラウドの設定のみを制御することができます。
- director のプロビジョニングの方法に依存せずにノードを使用することができます。これは、電源管理制御なしでオーバークラウドを作成する場合や、DHCP/PXE ブートの制限があるネットワークを使用する場合に便利です。
- director は、ノードの管理に OpenStack Compute (nova)、OpenStack Bare Betal (ironic) または OpenStack Image (glance) を使用しません。
-
事前にプロビジョニングされたノードでは、QCOW2
overcloud-full
イメージに依存しないカスタムパーティショニングレイアウトを使用することができます。
このシナリオでは、カスタム機能のない基本的な設定を行いますが、『オーバークラウドの高度なカスタマイズ』に記載の手順に従って、この基本的なオーバークラウドに高度な設定オプションを追加して、仕様に合わせてカスタマイズすることができます。
事前にプロビジョニングされたノードと director がプロビジョニングしたノードが混在するオーバークラウド環境はサポートされていません。
要件
- 「4章director のインストール」で作成した director ノード
- ノードに使用するベアメタルマシンのセット。必要なノード数は、作成予定のオーバークラウドのタイプにより異なります。これらのマシンは、各ノード種別に設定された要件にも従う必要があります。これらのノードには、ホストオペレーティングシステムとして Red Hat Enterprise Linux 7.5 以降をインストールする必要があります。Red Hat では、利用可能な最新バージョンの使用を推奨します。
- 事前にプロビジョニングされたノードを管理するためのネットワーク接続 1 つ。このシナリオでは、オーケストレーションエージェントの設定のために、ノードへの SSH アクセスが中断されないようにする必要があります。
コントロールプレーンネットワーク用のネットワーク接続 1 つ。このネットワークには、主に 2 つのシナリオがあります。
プロビジョニングネットワークをコントロールプレーンとして使用するデフォルトのシナリオ。このネットワークは通常、事前にプロビジョニングされたノードから director への Layer 3 (L3) を使用したルーティング可能なネットワーク接続です。このシナリオの例では、以下の IP アドレスの割り当てを使用します。
表8.1 プロビジョニングネットワークの IP 割り当て
ノード名 IP アドレス director
192.168.24.1
コントローラー
192.168.24.2
Compute
192.168.24.3
- 別のネットワークを使用するシナリオ。director のプロビジョニングネットワークがプライベートのルーティング不可能なネットワークの場合には、サブネットからノードの IP アドレスを定義して、パブリック API エンドポイント経由で director と通信することができます。このシナリオには特定の注意事項があります。これについては、本章の後半の「オーバークラウドノードに別のネットワークを使用する方法」で考察します。
- この例で使用するその他すべてのネットワーク種別には、OpenStack サービス用のコントロールプレーンネットワークも使用しますが、他のネットワークトラフィック種別用に追加のネットワークを作成することができます。
8.1. ノード設定のためのユーザーの作成
このプロセスの後半では、director が オーバークラウドノードに stack
ユーザーとして SSH アクセスする必要があります。
各オーバークラウドノードで、
stack
という名前のユーザーを作成して、それぞれにパスワードを設定します。たとえば、コントローラーノードでは以下のコマンドを使用します。[root@controller ~]# useradd stack [root@controller ~]# passwd stack # specify a password
sudo
を使用する際に、このユーザーがパスワードを要求されないようにします。[root@controller ~]# echo "stack ALL=(root) NOPASSWD:ALL" | tee -a /etc/sudoers.d/stack [root@controller ~]# chmod 0440 /etc/sudoers.d/stack
事前にプロビジョニングされた全ノードで
stack
ユーザーの作成と設定が完了したら、director ノードから各オーバークラウドノードにstack
ユーザーの公開 SSH 鍵をコピーします。たとえば、director の公開 SSH 鍵をコントローラーノードにコピーするには、以下のコマンドを実行します。[stack@director ~]$ ssh-copy-id stack@192.168.24.2
8.2. ノードのオペレーティングシステムの登録
ノードごとに Red Hat サブスクリプションへのアクセスが必要です。以下の手順は、各ノードを Red Hat コンテンツ配信ネットワークに登録する方法を説明しています。各ノードで以下の手順を実行してください。
登録コマンドを実行して、プロンプトが表示されたらカスタマーポータルのユーザー名とパスワードを入力します。
[root@controller ~]# sudo subscription-manager register
Red Hat OpenStack Platform 14 のエンタイトルメントプールを検索します。
[root@controller ~]# sudo subscription-manager list --available --all --matches="Red Hat OpenStack"
上記のステップで特定したプール ID を使用して、Red Hat OpenStack Platform 14 のエンタイトルメントをアタッチします。
[root@controller ~]# sudo subscription-manager attach --pool=pool_id
デフォルトのリポジトリーをすべて無効にします。
[root@controller ~]# sudo subscription-manager repos --disable=*
必要な Red Hat Enterprise Linux リポジトリーを有効にします。
x86_64 システムの場合には、以下のコマンドを実行します。
[root@controller ~]# sudo subscription-manager repos --enable=rhel-7-server-rpms --enable=rhel-7-server-extras-rpms --enable=rhel-7-server-rh-common-rpms --enable=rhel-ha-for-rhel-7-server-rpms --enable=rhel-7-server-openstack-14-rpms --enable=rhel-7-server-rhceph-2-osd-rpms --enable=rhel-7-server-rhceph-2-mon-rpms --enable=rhel-7-server-rhceph-2-tools-rpms
POWER システムの場合には、以下のコマンドを実行します。
[root@controller ~]# sudo subscription-manager repos --enable=rhel-7-for-power-le-rpms --enable=rhel-7-server-openstack-14-for-power-le-rpms
重要記載されたリポジトリーのみを有効にします。追加のリポジトリーを使用すると、パッケージとソフトウェアの競合が発生する場合があります。他のリポジトリーは有効にしないでください。
システムを更新して、ベースシステムのパッケージを最新の状態にします。
[root@controller ~]# sudo yum update -y [root@controller ~]# sudo reboot
このノードをオーバークラウドに使用する準備ができました。
8.3. director への SSL/TLS アクセスの設定
director が SSL/TLS を使用する場合は、事前にプロビジョニングされたノードには、director の SSL/TLS 証明書の署名に使用する認証局ファイルが必要です。独自の認証局を使用する場合には、各オーバークラウドノード上で以下のステップを実行します。
-
事前にプロビジョニングされた各ノードの
/etc/pki/ca-trust/source/anchors/
ディレクトリーに認証局ファイルをコピーします。 各オーバークラウドノード上で以下のコマンドを実行します。
[root@controller ~]# sudo update-ca-trust extract
これにより、オーバークラウドノードが director のパブリック API に SSL/TLS 経由でアクセスできるようにします。
8.4. コントロールプレーンのネットワークの設定
事前にプロビジョニングされたオーバークラウドノードは、標準の HTTP 要求を使用して director からメタデータを取得します。これは、オーバークラウドノードでは以下のいずれかに対して L3 アクセスが必要であることを意味します。
-
director のコントロールプレーンネットワーク。これは、
undercloud.conf
ファイルのnetwork_cidr
パラメーターで定義されたサブネットです。ノードには、このサブネットへの直接アクセスまたはルーティング可能なアクセスのいずれかが必要です。 -
undercloud.conf
ファイルのundercloud_public_host
パラメーターとして指定された director のパブリック API のエンドポイント。コントロールプレーンへの L3 ルートがない場合や、SSL/TLS 通信を使用する場合に、このオプションを利用できます。オーバークラウドがパブリック API エンドポイントを使用するための追加の設定手順については、「オーバークラウドノードに別のネットワークを使用する方法」を参照してください。
director は、コントロールプレーンネットワークを使用して標準のオーバークラウドを管理、設定します。事前にプロビジョニングされたノードを使用したオーバークラウドの場合には、director が事前にプロビジョニングされたノードと通信する方法に対応するために、ネットワーク設定を変更する必要がある場合があります。
ネットワーク分離の使用
ネットワークを分離すると、コントロールプレーンなど、固有のネットワークを使用するようにサービスをグループ化できます。『オーバークラウドの高度なカスタマイズ』には、ネットワーク分離の方法が複数記載されています。また、コントロールプレーン上のノードに固有の IP アドレスを定義することも可能です。ネットワーク分離や予測可能なノード配置方法の策定に関する詳しい情報は、『オーバークラウドの高度なカスタマイズ』の以下のセクションを参照してください。
ネットワーク分離を使用する場合には、NIC テンプレートに、アンダークラウドのアクセスに使用する NIC を含めないようにしてください。これらのテンプレートにより NIC が再構成され、デプロイメント時に接続性や設定の問題が発生する可能性があります。
IP アドレスの割り当て
ネットワーク分離を使用しない場合には、単一のコントロールプレーンを使用して全サービスを管理することができます。これには、各ノード上のコントロールプレーンの NIC を手動で設定して、コントロールプレーンネットワークの範囲内の IP アドレスを使用するようにする必要があります。director のプロビジョニングネットワークをコントロールプレーンとして使用する場合には、選択したオーバークラウドの IP アドレスが、プロビジョニング (dhcp_start
および dhcp_end
) とイントロスペクション (inspection_iprange
) の両方の DHCP 範囲外になるようにしてください。
標準のオーバークラウド作成中には、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 を定義します。このマッピングは以下を定義します。
-
割り当ての名前は、
<node_hostname>-<network>
の形式です (例:controller-ctlplane
、compute-ctlplane
)。 以下のパラメーターパターンを使用する IP 割り当て
-
fixed_ips/ip_address
: コントロールプレーンの固定 IP アドレスを定義します。複数の IP アドレスを定義する場合には、複数のip_address
パラメーターを一覧で指定してください。 -
subnets/cidr
: サブネットの CIDR 値を定義します。
-
本章の後半のステップでは、作成された環境ファイル (ctlplane-assignments.yaml
) を openstack overcloud deploy
コマンドの一部として使用します。
8.5. オーバークラウドノードに別のネットワークを使用する方法
デフォルトでは、director はオーバークラウドのコントロールプレーンとしてプロビジョニングネットワークを使用しますが、このネットワークが分離されて、ルーティング不可能な場合には、ノードは設定中に director の内部 API との通信ができません。このような状況では、ノードに別のネットワークを定義して、パブリック API 経由で director と通信できるように設定する必要がある場合があります。
このシナリオには、以下のような複数の要件があります。
- オーバークラウドノードは、「コントロールプレーンのネットワークの設定」からの基本的なネットワーク設定に対応する必要があります。
- パブリック API エンドポイントを使用できるように director 上で SSL/TLS を有効化する必要があります。詳しい情報は、「director の設定パラメーター」と「付録A SSL/TLS 証明書の設定」を参照してください。
-
director 向けにアクセス可能な完全修飾ドメイン名 (FQDN) を定義する必要があります。この FQDN は、director にルーティング可能な IP アドレスを解決する必要があります。
undercloud.conf
ファイルのundercloud_public_host
パラメーターを使用して、この FQDN を設定します。
本項に記載する例では、主要なシナリオとは異なる IP アドレスの割り当てを使用します。
表8.2 プロビジョニングネットワークの IP 割り当て
ノード名 | IP アドレスまたは FQDN |
---|---|
director (内部 API) |
192.168.24.1 (プロビジョニングネットワークおよびコントロールプレーン) |
director (パブリック API) |
10.1.1.1 / director.example.com |
オーバークラウドの仮想 IP |
192.168.100.1 |
コントローラー |
192.168.100.2 |
Compute |
192.168.100.3 |
以下の項では、オーバークラウドノードに別のネットワークが必要な場合の追加の設定について説明します。
IP アドレスの割り当て
IP の割り当て方法は、「コントロールプレーンのネットワークの設定」と似ていますが、コントロールプレーンはデプロイしたサーバーからルーティング可能ではないので、DeployedServerPortMap
パラメーターを使用して、コントロールプレーンにアクセスする仮想 IP アドレスなど、選択したオーバークラウドノードのサブネットから IP アドレスを割り当てます。以下は、このネットワークアーキテクチャーに対応するように、「コントロールプレーンのネットワークの設定」の ctlplane-assignments.yaml
環境ファイルを変更したバージョンです。
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
- 1
RedisVipPort
リソースは、network/ports/noop.yaml
にマッピングされます。このマッピングは、デフォルトの Redis VIP アドレスがコントロールプレーンから割り当てられていることが理由です。このような場合には、noop
を使用して、このコントロールプレーンマッピングを無効化します。- 2
EC2MetadataIp
とControlPlaneDefaultRoute
パラメーターは、コントロールプレーンの仮想 IP アドレスの値に設定されます。デフォルトの NIC 設定テンプレートでは、これらのパラメーターが必須で、デプロイメント中に実行される検証に合格するには、ping 可能な IP アドレスを使用するように設定する必要があります。または、これらのパラメーターが必要ないように NIC 設定をカスタマイズします。
8.6. 事前にプロビジョニングされたノードのホスト名のマッピング
事前にプロビジョニングされたノードを設定する場合には、Heat ベースのホスト名をそれらの実際のホスト名にマッピングして、ansible-playbook
が解決されたホストに到達できるようにする必要があります。それらの値は、HostnameMap
を使用してマッピングします。
手順
環境ファイル (例:
hostname-map.yaml
) を作成して、HostnameMap
パラメーターとホスト名のマッピングを指定します。以下の構文を使用してください。parameter_defaults: HostnameMap: [HEAT HOSTNAME]: [ACTUAL HOSTNAME] [HEAT HOSTNAME]: [ACTUAL HOSTNAME]
[HEAT HOSTNAME]
は通常[STACK NAME]-[ROLE]-[INDEX]
の表記法に従います。以下に例を示します。parameter_defaults: HostnameMap: overcloud-controller-0: controller-00-rack01 overcloud-controller-1: controller-01-rack02 overcloud-controller-2: controller-02-rack03 overcloud-compute-0: compute-00-rack01 overcloud-compute-1: compute-01-rack01 overcloud-compute-2: compute-02-rack01
-
hostname-map.yaml
の内容を保存します。
8.7. 事前にプロビジョニングされたノードでのオーバークラウドの作成
オーバークラウドのデプロイメントには、「デプロイメントコマンド」に記載の標準の CLI の方法を使用します。事前にプロビジョニングされたノードの場合は、デプロイメントコマンドに追加のオプションと、コア Heat テンプレートコレクションからの環境ファイルが必要です。
-
--disable-validations
: 事前にプロビジョニングされたインフラストラクチャーで使用しないサービスに対する基本的な CLI 検証を無効化します。無効化しないと、デプロイメントに失敗します。 -
environments/deployed-server-environment.yaml
: 事前にプロビジョニングされたインフラストラクチャーを作成、設定するための主要な環境ファイル。この環境ファイルは、OS::Nova::Server
リソースをOS::Heat::DeployedServer
リソースに置き換えます。 -
environments/deployed-server-bootstrap-environment-rhel.yaml
: 事前にプロビジョニングされたサーバー上でブートストラップのスクリプトを実行する環境ファイル。このスクリプトは、追加パッケージをインストールして、オーバークラウドノードの基本設定を提供します。 -
environments/deployed-server-pacemaker-environment.yaml
: 事前にプロビジョニングされたコントローラーノードで Pacemaker の設定を行う環境ファイル。このファイルに登録されるリソースの名前空間は、deployed-server/deployed-server-roles-data.yaml
からのコントローラーのロール名を使用します。デフォルトでは、ControllerDeployedServer
となっています。 deployed-server/deployed-server-roles-data.yaml
: カスタムロールのサンプルファイル。これは、デフォルトのroles_data.yaml
が複製されたファイルですが、各ロールのdisable_constraints: True
パラメーターも含まれています。このパラメーターは、生成されたロールテンプレートのオーケストレーションの制約を無効にします。これらの制約は、事前にプロビジョニングされたインフラストラクチャーで使用しないサービスが対象です。独自のカスタムロールファイルを使用する場合には、各ロールに
disable_constraints: True
パラメーターを追加するようにしてください。以下に例を示します。- name: ControllerDeployedServer disable_constraints: True CountDefault: 1 ServicesDefault: - OS::TripleO::Services::CACerts - OS::TripleO::Services::CephMon - OS::TripleO::Services::CephExternal - OS::TripleO::Services::CephRgw ...
以下は、事前にプロビジョニングされたアーキテクチャー固有の環境ファイルを使用したオーバークラウドデプロイメントのコマンド例です。
$ 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
ユーザーのアクセスを有効化します。
8.8. オーバークラウドデプロイメントの出力
オーバークラウドの作成が完了すると、オーバークラウドを設定するために実施された 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
8.9. オーバークラウドへのアクセス
director は、director ホストからオーバークラウドに対話するための設定を行い、認証をサポートするスクリプトを作成して、stack
ユーザーのホームディレクトリーにこのファイル (overcloudrc
) を保存します。このファイルを使用するには、以下のコマンドを実行します。
(undercloud) $ source ~/overcloudrc
これで、director のホストの CLI からオーバークラウドと対話するために必要な環境変数が読み込まれます。コマンドプロンプトが変わり、オーバークラウドと対話していることが示されます。
(overcloud) $
director のホストとの対話に戻るには、以下のコマンドを実行します。
(overcloud) $ source ~/stackrc (undercloud) $
8.10. 事前にプロビジョニングされたノードのスケーリング
事前にプロビジョニングされたノードをスケーリングするプロセスは、「11章オーバークラウドノードのスケーリング」に記載の標準のスケーリングの手順と似ていますが、事前にプロビジョニングされたノードを新たに追加するプロセスは異なります。これは、事前にプロビジョニングされたノードが OpenStack Bare Metal (ironic) および OpenStack Compute (nova) からの標準の登録および管理プロセスを使用しないためです。
事前にプロビジョニングされたノードのスケールアップ
事前にプロビジョニングされたノードでオーバークラウドをスケールアップする際には、各ノードで director のノード数に対応するようにオーケストレーションエージェントを設定する必要があります。
事前にプロビジョニングされたノードをスケールアップするプロセスの概要は、以下のとおりです。
- 「要件」の説明に従って、事前にプロビジョニングされたノードを新たに準備します。
- ノードをスケールアップします。手順については「11章オーバークラウドノードのスケーリング」を参照してください。
- デプロイメントコマンドを実行した後に、director が新しいノードリソースを作成して設定を開始するまで待ちます。
事前にプロビジョニングされたノードのスケールダウン
事前にプロビジョニングされたノードを持つオーバークラウドをスケールダウンするには、「11章オーバークラウドノードのスケーリング」に記載の通常のスケールダウンの手順に従います。
ほとんどのスケーリング操作では、ノードの 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 のベアメタルサービスがこの機能を制御しますが、事前にプロビジョニングされたノードでは、これらのノードを手動でシャットダウンするか、物理システムごとに電源管理制御を使用します。スタックからノードを削除した後にノードの電源をオフにしないと、稼動状態が続き、オーバークラウド環境の一部として再接続されてしまう可能性があります。
削除したノードの電源をオフにした後には、再プロビジョニングしてベースのオペレーティングシステムの設定に戻し、それらのノードが意図せずにオーバークラウドに加わってしまうことがないようにします。
オーバークラウドから以前に削除したノードは、再プロビジョニングしてベースオペレーティングシステムを新規インストールしてからでなければ、再利用しないようにしてください。スケールダウンのプロセスでは、オーバークラウドスタックからノードを削除するだけで、パッケージはアンインストールされません。
8.11. 事前にプロビジョニングされたオーバークラウドの削除
標準のオーバークラウドと同じ手順で、事前にプロビジョニングされたノードを使用するオーバークラウド全体を削除します。詳しい情報は、「オーバークラウドの削除」を参照してください。
オーバークラウドの削除後には、全ノードの電源をオフにしてから再プロビジョニングして、ベースオペレーティングシステムの設定に戻します。
オーバークラウドから削除したノードは、再プロビジョニングしてベースオペレーティングシステムを新規インストールしてからでなければ再利用しないでください。削除のプロセスでは、オーバークラウドスタックを削除するだけで、パッケージはアンインストールされません。
8.12. オーバークラウド作成の完了
これで、事前にプロビジョニングされたノードを使用したオーバークラウドの作成が完了しました。作成後の機能については、「9章オーバークラウド作成後のタスクの実行」を参照してください。