7.4. 事前にプロビジョニングされたノードを使用した基本的なオーバークラウドの設定

本章では、事前にプロビジョニングされたノードを使用して Red Hat OpenStack Platform (RHOSP) 環境を設定するのに使用できる基本的な設定手順を説明します。以下のシナリオは、標準のオーバークラウド作成のシナリオとはさまざまな点で異なります。

  • 外部ツールを使用してノードをプロビジョニングしてから、director でオーバークラウドの設定のみを制御することができます。
  • director のプロビジョニングの方法に依存せずにノードを使用することができます。これは、電源管理制御を設定せずにオーバークラウドを作成する場合や、DHCP/PXE ブートの制限があるネットワークを使用する場合に便利です。
  • director では、ノードを管理するのに OpenStack Compute (nova)、OpenStack Bare Metal (ironic)、または OpenStack Image (glance) を使用しません。
  • 事前にプロビジョニングされたノードでは、QCOW2 overcloud-full イメージに依存しないカスタムパーティションレイアウトを使用することができます。

このシナリオには、カスタム機能を持たない基本的な設定のみが含まれています。

重要

事前にプロビジョニングされたノードと director がプロビジョニングしたノードを組み合わせることはできません。

7.4.1. 事前にプロビジョニングされたノードの要件

事前にプロビジョニングされたノードを使用してオーバークラウドのデプロイメントを開始する前に、以下の項目が環境に存在していること確認してください。

  • 4章アンダークラウドへの director のインストール で作成した director ノード
  • ノードに使用するベアメタルマシンのセット。必要なノード数は、作成予定のオーバークラウドのタイプにより異なります。これらのマシンは、各ノード種別に設定された要件に従う必要があります。これらのノードには、ホストオペレーティングシステムとして Red Hat Enterprise Linux 9.2 がインストールされている必要があります。Red Hat では、利用可能な最新バージョンの使用を推奨します。
  • 事前にプロビジョニングされたノードを管理するためのネットワーク接続 1 つ。このシナリオでは、オーケストレーションエージェントの設定のために、ノードへの SSH アクセスが中断されないようにする必要があります。
  • コントロールプレーンネットワーク用のネットワーク接続 1 つ。このネットワークには、主に 2 つのシナリオがあります。

    • プロビジョニングネットワークをコントロールプレーンとして使用するデフォルトのシナリオ:このネットワークは通常、事前にプロビジョニングされたノードから director へのレイヤー 3 (L3) を使用したルーティング可能なネットワーク接続です。このシナリオの例では、以下の IP アドレスの割り当てを使用します。

      表7.11 プロビジョニングネットワークの IP 割り当て

      ノード名IP アドレス

      director

      192.168.24.1

      Controller 0

      192.168.24.2

      Compute 0

      192.168.24.3

    • 別のネットワークを使用するシナリオ:director のプロビジョニングネットワークがプライベートのルーティング不可能なネットワークの場合には、サブネットからノードの IP アドレスを定義して、パブリック API エンドポイント経由で director と通信することができます。このシナリオの要件についての詳細は、「事前にプロビジョニングされたノードへの別ネットワークの使用」を参照してください。
  • この例で使用するその他すべてのネットワーク種別も、OpenStack サービス用のコントロールプレーンネットワークを使用します。ただし、ネットワークトラフィックの他のタイプに追加でネットワークを作成することができます。
  • いずれかのノードで Pacemaker リソースが使用される場合、サービスユーザー hacluster およびサービスグループ haclient の UID/GID は、189 でなければなりません。これは CVE-2018-16877 に対応するためです。オペレーティングシステムと共に Pacemaker をインストールした場合、インストールによりこれらの ID が自動的に作成されます。ID の値が正しく設定されていない場合は、アーティクル OpenStack minor update / fast-forward upgrade can fail on the controller nodes at pacemaker step with "Could not evaluate: backup_cib" の手順に従って ID の値を変更します。
  • 一部のサービスが誤った IP アドレスにバインドされてデプロイメントに失敗するのを防ぐために、/etc/hosts ファイルに node-name=127.0.0.1 のマッピングが含まれないようにします。

7.4.2. 事前にプロビジョニングされたノードでのユーザーの作成

事前にプロビジョニングされたノードを使用してオーバークラウドを設定する場合、director はオーバークラウドノードに SSH アクセスする必要があります。事前にプロビジョニングされたノードで SSH 鍵認証のユーザーを作成し、そのユーザーに対してパスワード不要の sudo アクセスを設定する必要があります。事前にプロビジョニングされたノードでユーザーを作成したら、openstack overcloud deploy コマンドで --overcloud-ssh-user および --overcloud-ssh-key オプションを使用して、事前にプロビジョニングされたノードでオーバークラウドを作成することができます。

デフォルトでは、オーバークラウドの SSH ユーザーおよびオーバークラウドの SSH 鍵の値は、それぞれ stack ユーザーおよび ~/.ssh/id_rsa です。stack ユーザーを作成するには、以下の手順を実施します。

手順

  1. 各オーバークラウドノードで、stack ユーザーを作成して、それぞれにパスワードを設定します。Controller ノードで、以下の例に示すコマンドを実行します。

    [root@controller-0 ~]# useradd stack
    [root@controller-0 ~]# passwd stack  # specify a password
  2. sudo を使用する際に、このユーザーがパスワードを要求されないようにします。

    [root@controller-0 ~]# echo "stack ALL=(root) NOPASSWD:ALL" | tee -a /etc/sudoers.d/stack
    [root@controller-0 ~]# chmod 0440 /etc/sudoers.d/stack
  3. 事前にプロビジョニングされた全ノードで stack ユーザーの作成と設定を行った後に、director ノードから各オーバークラウドノードに stack ユーザーの公開 SSH 鍵をコピーします。director の公開 SSH 鍵を Controller ノードにコピーするには、以下の例に示すコマンドを実行します。

    [stack@director ~]$ ssh-copy-id stack@192.168.24.2
重要

SSH 鍵をコピーするには、各オーバークラウドノードの SSH 設定で一時的に PasswordAuthentication Yes を設定しなければならない場合があります。SSH 鍵をコピーした後に PasswordAuthentication No を設定し、今後は SSH 鍵を使用して認証を行います。

7.4.3. 事前にプロビジョニングされたノードのオペレーティングシステムの登録

それぞれのノードには、Red Hat サブスクリプションへのアクセスが必要です。ノードを Red Hat コンテンツ配信ネットワークに登録するには、各ノードで以下の手順を実施します。root ユーザーとして、または sudo 権限を持つユーザーとしてコマンドを実行します。

重要

記載されたリポジトリーのみを有効にします。追加のリポジトリーを使用すると、パッケージとソフトウェアの競合が発生する場合があります。他のリポジトリーは有効にしないでください。

手順

  1. 登録コマンドを実行して、プロンプトが表示されたらカスタマーポータルのユーザー名とパスワードを入力します。

    [root@controller-0 ~]# sudo subscription-manager register
  2. Red Hat OpenStack Platform (RHOSP) 17.1 のエンタイトルメントプールを検索します。

    [root@controller-0 ~]# sudo subscription-manager list --available --all --matches="Red Hat OpenStack"
  3. 前の手順で特定したプール ID を使用して、RHOSP 17.1 のエンタイトルメントをアタッチします。

    [root@controller-0 ~]# sudo subscription-manager attach --pool=pool_id
  4. デフォルトのリポジトリーをすべて無効にします。

    [root@controller-0 ~]# sudo subscription-manager repos --disable=*
  5. 必要な Red Hat Enterprise Linux (RHEL) リポジトリーを有効にします。

    [root@controller-0 ~]# sudo subscription-manager repos \
     --enable=rhel-9-for-x86_64-baseos-eus-rpms \
     --enable=rhel-9-for-x86_64-appstream-eus-rpms \
     --enable=rhel-9-for-x86_64-highavailability-eus-rpms \
     --enable=openstack-17.1-for-rhel-9-x86_64-rpms \
     --enable=fast-datapath-for-rhel-9-x86_64-rpms
  6. オーバークラウドで Red Hat Ceph Storage ノードが使用されている場合は、関連する Red Hat Ceph Storage リポジトリーを有効にします。

    [root@cephstorage-0 ~]# sudo subscription-manager repos \
     --enable=rhel-9-for-x86_64-baseos-rpms \
     --enable=rhel-9-for-x86_64-appstream-rpms \
     --enable=openstack-deployment-tools-for-rhel-9-x86_64-rpms
  7. Red Hat Ceph Storage ノードを除くすべてのオーバークラウドノードで RHEL バージョンをロックします。

    [root@controller-0 ~]# subscription-manager release --set=9.2
  8. システムを更新して、ベースシステムパッケージが最新の状態になるようにします。

    [root@controller-0 ~]# sudo dnf update -y
    [root@controller-0 ~]# sudo reboot

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

7.4.4. director への SSL/TLS アクセスの設定

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

手順

  1. 事前にプロビジョニングされた各ノードの /etc/pki/ca-trust/source/anchors/ ディレクトリーに認証局ファイルをコピーします。
  2. 各オーバークラウドノード上で以下のコマンドを実行します。

    [root@controller-0 ~]#  sudo update-ca-trust extract

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

7.4.5. コントロールプレーンのネットワークの設定

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

ネットワーク分離を使用している場合は、予測可能な IP 戦略を実装するために、カスタム環境ファイル deploy-ports.yaml を作成します。次のカスタム環境ファイルの例 deploy-ports.yaml は、一連のリソースレジストリーマッピングとパラメーターを director に渡し、事前にプロビジョニングされたノードの IP 割り当てを定義します。NodePortMapControlPlaneVipData、および VipPortMap パラメーターは、各オーバークラウドノードに対応する IP アドレスとサブネット CIDR を定義します。

resource_registry:
  # Deployed Virtual IP port resources
  OS::TripleO::Network::Ports::ExternalVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/deployed_vip_external.yaml
  OS::TripleO::Network::Ports::InternalApiVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/deployed_vip_internal_api.yaml
  OS::TripleO::Network::Ports::StorageVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/deployed_vip_storage.yaml
  OS::TripleO::Network::Ports::StorageMgmtVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/deployed_vip_storage_mgmt.yaml

  # Deployed ControlPlane port resource
  OS::TripleO::DeployedServer::ControlPlanePort: /usr/share/openstack-tripleo-heat-templates/deployed-server/deployed-neutron-port.yaml

  # Controller role port resources
  OS::TripleO::Controller::Ports::ExternalPort: /usr/share/openstack-tripleo-heat-templates/network/ports/deployed_external.yaml
  OS::TripleO::Controller::Ports::InternalApiPort: /usr/share/openstack-tripleo-heat-templates/network/ports/deployed_internal_api.yaml
  OS::TripleO::Controller::Ports::StorageMgmtPort: /usr/share/openstack-tripleo-heat-templates/network/ports/deployed_storage_mgmt.yaml
  OS::TripleO::Controller::Ports::StoragePort: /usr/share/openstack-tripleo-heat-templates/network/ports/deployed_storage.yaml
  OS::TripleO::Controller::Ports::TenantPort: /usr/share/openstack-tripleo-heat-templates/network/ports/deployed_tenant.yaml

  # Compute role port resources
  OS::TripleO::Compute::Ports::InternalApiPort: /usr/share/openstack-tripleo-heat-templates/network/ports/deployed_internal_api.yaml
  OS::TripleO::Compute::Ports::StoragePort: /usr/share/openstack-tripleo-heat-templates/network/ports/deployed_storage.yaml
  OS::TripleO::Compute::Ports::TenantPort: /usr/share/openstack-tripleo-heat-templates/network/ports/deployed_tenant.yaml

  # CephStorage role port resources
  OS::TripleO::CephStorage::Ports::StorageMgmtPort: /usr/share/openstack-tripleo-heat-templates/network/ports/deployed_storage_mgmt.yaml
  OS::TripleO::CephStorage::Ports::StoragePort: /usr/share/openstack-tripleo-heat-templates/network/ports/deployed_storage.yaml

parameter_defaults:
  NodePortMap: 1
    # Controller node parameters
    controller-00-rack01: 2
      ctlplane: 3
        ip_address: 192.168.24.201
        ip_address_uri: 192.168.24.201
        ip_subnet: 192.168.24.0/24
      external:
        ip_address: 10.0.0.201
        ip_address_uri: 10.0.0.201
        ip_subnet: 10.0.0.10/24
      internal_api:
        ip_address: 172.16.2.201
        ip_address_uri: 172.16.2.201
        ip_subnet: 172.16.2.10/24
      management:
        ip_address: 192.168.1.201
        ip_address_uri: 192.168.1.201
        ip_subnet: 192.168.1.10/24
      storage:
        ip_address: 172.16.1.201
        ip_address_uri: 172.16.1.201
        ip_subnet: 172.16.1.10/24
      storage_mgmt:
        ip_address: 172.16.3.201
        ip_address_uri: 172.16.3.201
        ip_subnet: 172.16.3.10/24
      tenant:
        ip_address: 172.16.0.201
        ip_address_uri: 172.16.0.201
        ip_subnet: 172.16.0.10/24
    ...

    # Compute node parameters
    compute-00-rack01:
      ctlplane:
        ip_address: 192.168.24.11
        ip_address_uri: 192.168.24.11
        ip_subnet: 192.168.24.0/24
      internal_api:
        ip_address: 172.16.2.11
        ip_address_uri: 172.16.2.11
        ip_subnet: 172.16.2.10/24
      storage:
        ip_address: 172.16.1.11
        ip_address_uri: 172.16.1.11
        ip_subnet: 172.16.1.10/24
      tenant:
        ip_address: 172.16.0.11
        ip_address_uri: 172.16.0.11
        ip_subnet: 172.16.0.10/24
    ...

    # Ceph node parameters
    ceph-00-rack01:
      ctlplane:
        ip_address: 192.168.24.101
        ip_address_uri: 192.168.24.101
        ip_subnet: 192.168.24.0/24
      storage:
        ip_address: 172.16.1.101
        ip_address_uri: 172.16.1.101
        ip_subnet: 172.16.1.10/24
      storage_mgmt:
        ip_address: 172.16.3.101
        ip_address_uri: 172.16.3.101
        ip_subnet: 172.16.3.10/24
    ...

  # Virtual IP address parameters
  ControlPlaneVipData:
    fixed_ips:
    - ip_address: 192.168.24.5
    name: control_virtual_ip
    network:
      tags: [192.168.24.0/24]
      subnets:
      - ip_version: 4
  VipPortMap
    external:
      ip_address: 10.0.0.100
      ip_address_uri: 10.0.0.100
      ip_subnet: 10.0.0.100/24
    internal_api:
      ip_address: 172.16.2.100
      ip_address_uri: 172.16.2.100
      ip_subnet: 172.16.2.100/24
    storage:
      ip_address: 172.16.1.100
      ip_address_uri: 172.16.1.100
      ip_subnet: 172.16.1.100/24
    storage_mgmt:
      ip_address: 172.16.3.100
      ip_address_uri: 172.16.3.100
      ip_subnet: 172.16.3.100/24

  RedisVirtualFixedIPs:
    - ip_address: 192.168.24.6
        use_neutron: false
1
NodePortMap マッピングは、ノード割り当ての名前を定義します。
2
<node_hostname> の形式に従う、ノードの短いホスト名。
3
ノードのネットワーク定義と IP 割り当て。ネットワークには、ctlplaneexternalinternal_apimanagementstoragestorage_mgmt、および tenant が含まれます。IP 割り当てには、ip_addressip_address_uri、および ip_subnet が含まれます。
  • IPv4: ip_addressip_address_uri は同じ値に設定する必要があります。
  • IPv6:

    • ip_address: 括弧なしの IPv6 アドレスに設定します。
    • ip_address_uri: [2001:0db8:85a3:0000:0000:8a2e:0370:7334] のように、角括弧で囲まれた IPv6 アドレスに設定します。

7.4.6. 事前にプロビジョニングされたノードへの別ネットワークの使用

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

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

  • オーバークラウドノードは、「コントロールプレーンのネットワークの設定」 からの基本的なネットワーク設定に対応する必要があります。
  • パブリック API エンドポイントを使用できるように director 上で SSL/TLS を有効化する必要があります。詳細は、オーバークラウドのパブリックエンドポイントでの SSL/TLS の有効化 を参照してください。
  • director 向けにアクセス可能な完全修飾ドメイン名 (FQDN) を定義する必要があります。この FQDN は、director にルーティング可能な IP アドレスを解決する必要があります。undercloud.conf ファイルの undercloud_public_host パラメーターを使用して、この FQDN を設定します。

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

表7.12 プロビジョニングネットワークの IP 割り当て

ノード名IP アドレスまたは FQDN

director (Internal API)

192.168.24.1 (プロビジョニングネットワークおよびコントロールプレーン)

director (パブリック API)

10.1.1.1 / director.example.com

オーバークラウドの仮想 IP

192.168.100.1

Controller 0

192.168.100.2

Compute 0

192.168.100.3

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

IP アドレスの割り当て

IP の割り当て方法は、「コントロールプレーンのネットワークの設定」に記載の手順と類似しています。ただし、コントロールプレーンはデプロイされたサーバーからルーティングできない場合があるため、NodePortMapControlPlaneVipData、および VipPortMap パラメーターを使用して、選択したオーバークラウドノードサブネットから IP アドレス (コントロールプレーンにアクセスするための仮想 IP アドレスを含む) を割り当てることができます。次の例は、「コントロールプレーンのネットワークの設定」 からの deployed-ports.yaml カスタム環境ファイルの修正版です。このネットワークアーキテクチャーに対応します。

parameter_defaults:
  NodePortMap:
    controller-00-rack01
      ctlplane
        ip_address: 192.168.100.2
        ip_address_uri: 192.168.100.2
        ip_subnet: 192.168.100.0/24
...
    compute-00-rack01:
      ctlplane
        ip_address: 192.168.100.3
        ip_address_uri: 192.168.100.3
        ip_subnet: 192.168.100.0/24
...
  ControlPlaneVipData:
    fixed_ips:
    - ip_address: 192.168.100.1
    name: control_virtual_ip
    network:
      tags: [192.168.100.0/24]
    subnets:
    - ip_version: 4
  VipPortMap:
    external:
      ip_address: 10.0.0.100
      ip_address_uri: 10.0.0.100
      ip_subnet: 10.0.0.100/24
....
  RedisVirtualFixedIPs:1
    - ip_address: 192.168.100.10
      use_neutron: false
1
RedisVipPort リソースは、network/ports/noop.yaml にマッピングされます。デフォルトの Redis 仮想 IP アドレスがコントロールプレーンから割り当てられているので、このマッピングが必要です。このような場合には、noop を使用して、このコントロールプレーンマッピングを無効化します。

7.4.7. 事前にプロビジョニングされたノードのホスト名のマッピング

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

手順

  1. 環境ファイル (たとえば 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-novacompute-0: compute-00-rack01
        overcloud-novacompute-1: compute-01-rack01
        overcloud-novacompute-2: compute-02-rack01
  2. hostname-map.yaml ファイルを保存します。

7.4.8. 事前にプロビジョニングされたノード向けの Ceph Storage の設定

すでにデプロイされているノードに Ceph を設定するには、アンダークラウドホストで以下の手順を実施します。

手順

  1. アンダークラウドホストで環境変数 OVERCLOUD_HOSTS を作成し、変数に Ceph クライアントとして使用するオーバークラウドホストの IP アドレスのスペース区切りリストを設定します。

    export OVERCLOUD_HOSTS="192.168.1.8 192.168.1.42"
  2. デフォルトのオーバークラウドプランの名前は overcloud です。別の名前を使用する場合は、環境変数 OVERCLOUD_PLAN を作成してカスタムの名前を保存します。

    export OVERCLOUD_PLAN="<custom-stack-name>"
    • <custom-stack-name> を実際のスタックの名前に置き換えます。
  3. enable-ssh-admin.sh スクリプトを実行して、Ansible が Ceph クライアントの設定に使用することのできるオーバークラウドノードのユーザーを設定します。

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

openstack overcloud deploy コマンドを実行すると、Ansible は OVERCLOUD_HOSTS 変数で Ceph クライアントとして定義したホストを設定します。

7.4.9. 事前にプロビジョニングされたノードを使用したオーバークラウドの作成

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

  • --disable-validations: このオプションを使用して、事前にプロビジョニングされたインフラストラクチャーで使用しないサービスに対する基本的な CLI 検証を無効にします。これらの検証を無効にしないと、デプロイメントに失敗します。
  • environments/deployed-server-environment.yaml: 事前にプロビジョニングされたインフラストラクチャーを作成、設定するには、この環境ファイルを追加します。この環境ファイルは、OS::Nova::Server リソースを OS::Heat::DeployedServer リソースに置き換えます。

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

$ source ~/stackrc
(undercloud)$ openstack overcloud deploy \
  --disable-validations \
  -e /usr/share/openstack-tripleo-heat-templates/environments/deployed-server-environment.yaml \
  -e /home/stack/templates/deployed-ports.yaml \
  -e /home/stack/templates/hostname-map.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 キーを挿入するには、--overcloud-ssh-user および --overcloud-ssh-key (~/.ssh/id_rsa がデフォルト) を使用して、初回 SSH 接続用の認証情報を指定します。--overcloud-ssh-key オプションで指定する秘密鍵の公開を制限するために、director は Heat などのどの API サービスにもこの鍵を渡さず、director の openstack overcloud deploy コマンドだけがこの鍵を使用して tripleo-admin ユーザーのアクセスを有効化します。

7.4.10. オーバークラウドへのアクセス

director は、アンダークラウドからのオーバークラウドの操作に必要な認証情報を含めて認証情報ファイルを生成します。director は、このファイル overcloudrcstack ユーザーのホームディレクトリーに保存します。

手順

  1. source コマンドで overcloudrc ファイルを読み込みます。

    (undercloud)$ source ~/overcloudrc

    オーバークラウドにアクセスしていることを示すコマンドプロンプトに切り替わります。

    (overcloud)$
  2. アンダークラウドの操作に戻るには、stackrc ファイルを読み込みます。

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

    アンダークラウドにアクセスしていることを示すコマンドプロンプトに切り替わります。

    (undercloud)$

7.4.11. 事前にプロビジョニングされたノードのスケーリング

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

7.4.11.1. 事前にプロビジョニングされたノードのスケールアップ

事前にプロビジョニングされたノードでオーバークラウドをスケールアップする際には、各ノードで director のノード数に対応するようにオーケストレーションエージェントを設定する必要があります。

手順

  1. 事前プロビジョニングされた新規ノードを準備します。詳細は、事前プロビジョニングされたノードの要件 を参照してください。
  2. ノードをスケールアップします。詳細は、オーバークラウドノードのスケーリング を参照してください。

7.4.11.2. 事前にプロビジョニングされたノードのスケールダウン

事前にプロビジョニングされたノードを持つオーバークラウドをスケールダウンする場合は、オーバークラウドノードのスケーリング に記載されているスケールダウン手順に従ってください。

スケールダウン操作では、Red Hat OpenStack Platform (RHOSP) によりプロビジョニングされたノードまたは事前にプロビジョニングされたノードの両方にホスト名を使用できます。RHOSP によりプロビジョニングされたノードに UUID を使用することもできます。ただし、事前にプロビジョニングされたノードには UUID がないため、常にホスト名を使用します。

手順

  1. 削除するノードの名前を取得します。

    $ openstack stack resource list overcloud -n5 --filter type=OS::TripleO::ComputeDeployedServerServer
  2. ノードを削除します。

    $ openstack overcloud node delete --stack <overcloud> <node> [... <node>]
    • <overcloud> は、オーバークラウドスタックの名前または UUID に置き換えてください。
    • <node> を、手順 1 で返された stack_name 列から取得した削除するノードのホスト名に置き換えます。
  3. ノードが削除されていることを確認します。

    $ openstack stack list

    削除の操作が完了すると、オーバークラウド スタックのステータスは UPDATE_COMPLETE と表示されます。

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

    注記

    オーバークラウドから以前に削除したノードは、再プロビジョニングしてベースオペレーティングシステムを新規インストールするまでは、再利用しないようにしてください。スケールダウンのプロセスでは、オーバークラウドスタックからノードを削除するだけで、パッケージはアンインストールされません。

7.4.12. 事前にプロビジョニングされたオーバークラウドの削除

事前にプロビジョニングされたノードを使用するオーバークラウド全体を削除するには、「オーバークラウドスタックの削除」 で標準のオーバークラウド削除手順を参照してください。オーバークラウドを削除した後に、全ノードの電源をオフにしてからベースオペレーティングシステムの設定に再プロビジョニングします。

注記

オーバークラウドから以前に削除したノードは、再プロビジョニングしてベースオペレーティングシステムを新規インストールするまでは、再利用しないようにしてください。削除のプロセスでは、オーバークラウドスタックを削除するだけで、パッケージはアンインストールされません。