Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

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 アドレスの割り当てを使用します。

      Expand
      表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 鍵のデフォルト値は tripleo-admin ユーザーおよび ~/.ssh/id_rsa なので、事前にプロビジョニングされたノードごとに tripleo-admin という名前のユーザーを作成します。以下の手順により、コントローラーノードに tripleo-admin ユーザーを作成します。オーバークラウドに追加する事前にプロビジョニングされたノードごとに、この手順を繰り返します。

手順

  1. tripleo-admin ユーザーを作成し、コントローラーノードにパスワードを設定します。 

    [root@controller-0 ~]# useradd tripleo-admin
[root@controller-0 ~]# passwd <password>
    Copy to Clipboard Toggle word wrap
    • &lt ;password& gt; を tripleo-admin ユーザーのパスワードに置き換えます。

  2. sudo を使用する際に、このユーザーがパスワードを要求されないようにします。 

    [root@controller-0 ~]# echo "tripleo-admin ALL=(root) NOPASSWD:ALL" | tee -a /etc/sudoers.d/tripleo-admin
[root@controller-0 ~]# chmod 0440 /etc/sudoers.d/tripleo-admin
    Copy to Clipboard Toggle word wrap
  3. コントローラーノードの SSH 設定で PasswordAuthentication Yes を設定します。

  4. tripleo-admin ユーザーの公開 SSH 鍵を director ノードからコントローラーノードにコピーします。 

    [stack@director ~]$ ssh-copy-id tripleo-admin@192.168.24.2
    Copy to Clipboard Toggle word wrap
  5. コントローラーノードの SSH 設定で PasswordAuthentication No を設定します。
  6. ノードへのアクセス時に、SSH キーを使用して認証できることを確認します。

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

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

重要

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

手順

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

    [root@controller-0 ~]# sudo subscription-manager register
    Copy to Clipboard Toggle word wrap

  2. Red Hat OpenStack Platform (RHOSP) 17.1 のエンタイトルメントプールを検索します。 

    [root@controller-0 ~]# sudo subscription-manager list --available --all --matches="Red Hat OpenStack"
    Copy to Clipboard Toggle word wrap

  3. 前の手順で特定したプール ID を使用して、RHOSP 17.1 のエンタイトルメントをアタッチします。 

    [root@controller-0 ~]# sudo subscription-manager attach --pool=pool_id
    Copy to Clipboard Toggle word wrap

  4. デフォルトのリポジトリーをすべて無効にします。 

    [root@controller-0 ~]# sudo subscription-manager repos --disable=*
    Copy to Clipboard Toggle word wrap

  5. 必要な Red Hat Enterprise Linux (RHEL) リポジトリーを有効にします。 

    [root@controller-0 ~]# sudo subscription-manager repos \
 --enable=rhel-9-for-x86_64-baseos-e4s-rpms \
 --enable=rhel-9-for-x86_64-appstream-e4s-rpms \
 --enable=rhel-9-for-x86_64-highavailability-e4s-rpms \
 --enable=openstack-17.1-for-rhel-9-x86_64-rpms \
 --enable=fast-datapath-for-rhel-9-x86_64-rpms
    Copy to Clipboard Toggle word wrap

  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
    Copy to Clipboard Toggle word wrap

  7. Red Hat Ceph Storage ノードを除くすべてのオーバークラウドノードで RHEL バージョンをロックします。 

    [root@controller-0 ~]# subscription-manager release --set=9.2
    Copy to Clipboard Toggle word wrap

  8. システムを更新して、ベースシステムパッケージが最新の状態になるようにします。 

    [root@controller-0 ~]# sudo dnf update -y
[root@controller-0 ~]# sudo reboot
    Copy to Clipboard Toggle word wrap

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

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
    Copy to Clipboard Toggle word wrap

この手順により、オーバークラウドノードが 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 の割り当てを強制的に使用するようにしてください。

重要

Red Hat OpenStack Platform 17.1 以降、ips-from-pool.yaml ファイルを使用して予測可能な IP をノードに割り当てることができなくなりました。ネットワークの IP アドレスを指定するには、ベアメタル定義ファイルの fixed_ip プロパティーを使用する必要があります。詳細は、ベアメタルノードのプロビジョニング属性 および オーバークラウド用のベアメタルノードのプロビジョニング を参照し てください。

ネットワーク分離を使用している場合は、予測可能な IP 戦略を実装するために、カスタム環境ファイル deploy-ports.yaml を作成します。次のカスタム環境ファイルの例 deploy-ports.yaml は、一連のリソースレジストリーマッピングとパラメーターを director に渡し、事前にプロビジョニングされたノードの IP 割り当てを定義します。NodePortMap、ControlPlaneVipData、および 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
Copy to Clipboard Toggle word wrap
1
NodePortMap マッピングは、ノード割り当ての名前を定義します。
2
<node_hostname> の形式に従う、ノードの短いホスト名。
3
ノードのネットワーク定義と IP 割り当て。ネットワークには、ctlplane、external、internal_api、management、storage、storage_mgmt、および tenant が含まれます。IP 割り当てには、ip_address、ip_address_uri、および ip_subnet が含まれます。
  • IPv4: ip_address と ip_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 アドレスの割り当てを使用します。

Expand
表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 の割り当て方法は、「コントロールプレーンのネットワークの設定」に記載の手順と類似しています。ただし、コントロールプレーンはデプロイされたサーバーからルーティングできない場合があるため、NodePortMap、ControlPlaneVipData、および 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
Copy to Clipboard Toggle word wrap
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]
    Copy to Clipboard Toggle word wrap

    [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
    Copy to Clipboard Toggle word wrap
  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"
    Copy to Clipboard Toggle word wrap

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

    export OVERCLOUD_PLAN="<custom-stack-name>"
    Copy to Clipboard Toggle word wrap
    • <custom-stack-name> を実際のスタックの名前に置き換えます。

  3. enable-ssh-admin.sh スクリプトを実行して、Ansible が Ceph クライアントの設定に使用することのできるオーバークラウドノードのユーザーを設定します。 

    bash /usr/share/openstack-tripleo-heat-templates/deployed-server/scripts/enable-ssh-admin.sh
    Copy to Clipboard Toggle word wrap

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>
Copy to Clipboard Toggle word wrap

--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 は、このファイル overcloudrc を stack ユーザーのホームディレクトリーに保存します。

手順

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

    (undercloud)$ source ~/overcloudrc
    Copy to Clipboard Toggle word wrap

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

    (overcloud)$
    Copy to Clipboard Toggle word wrap

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

    (overcloud)$ source ~/stackrc
(undercloud)$
    Copy to Clipboard Toggle word wrap

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

    (undercloud)$
    Copy to Clipboard Toggle word wrap

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

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

注記

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

Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2026 Red Hatトップに戻る