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) を使用しません。
  • 事前にプロビジョニングされたノードは、カスタムのパーティションレイアウトを使用します。

このシナリオでは、カスタム機能のない基本的な設定を行いますが、『オーバークラウドの高度なカスタマイズ』ガイドに記載の手順に従って、この基本的なオーバークラウドに高度な設定オプションを追加して、仕様に合わせてカスタマイズすることができます。

重要

事前プロビジョニングされたノードと director がプロビジョニングしたノードが混在するオーバークラウド環境はサポートされていません。

要件

  • 4章アンダークラウドのインストール」で作成した director ノード
  • ノードに使用するベアメタルマシンのセット。必要なノード数は、作成予定のオーバークラウドのタイプにより異なります (オーバークラウドロールに関する情報は「ノードのデプロイメントロールのプランニング」を参照してください)。これらのマシンは、各ノード種別の要件セットに従う必要があります。これらの要件については、「オーバークラウドの要件」を参照してください。これらのノードには Red Hat Enterprise Linux 7.3 のオペレーティングシステムが必要です。
  • 事前にプロビジョニングされたノードを管理するためのネットワーク接続 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 アクセスする必要があります。

  1. 各オーバークラウドノードで、stack という名前のユーザーを作成して、それぞれにパスワードを設定します。たとえば、コントローラーノードでは以下のコマンドを使用します。

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

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

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

8.2. ノードのオペレーティングシステムの登録

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

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

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

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

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

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

    1. 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-12-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
    2. POWER システムの場合には、以下のコマンドを実行します。

      [root@controller ~]# sudo subscription-manager repos --enable=rhel-7-for-power-le-rpms --enable=rhel-7-server-openstack-12-for-power-le-rpms
    重要

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

  6. システムを更新して、ベースシステムのパッケージを最新の状態にします。

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

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

8.3. ノードへのユーザーエージェントのインストール

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

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

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

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

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

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

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

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

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

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

  • director のコントロールプレーンネットワーク。これは、undercloud.conf ファイルの network_cidr パラメーターで定義されたサブネットです。ノードには、このサブネットへの直接アクセスまたはルーティング可能なアクセスのいずれかが必要です。
  • undercloud.conf ファイルの undercloud_public_host パラメーターとして指定された director のパブリック API のエンドポイント。コントロールプレーンへの L3 ルートがない場合や、director をポーリングしてメタデータを取得するのに 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 を定義します。このマッピングは以下を定義します。

  1. 割り当ての名前は、<node_hostname>-<network> の形式です (例: controller-ctlplanecompute-ctlplane)。
  2. 以下のパラメーターパターンを使用する IP 割り当て

    • fixed_ips/ip_address: コントロールプレーンの固定 IP アドレスを定義します。複数の IP アドレスを定義する場合には、複数の ip_address パラメーターを一覧で指定してください。
    • subnets/cidr: サブネットの CIDR 値を定義します。

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

8.6. オーバークラウドノードに別のネットワークを使用する方法

デフォルトでは、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

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

オーケストレーションの設定

アンダークラウドの SSL/TLS 通信を有効化している場合には、director は、大半のサービスにパブリック API エンドポイントを提供します。ただし、OpenStack Orchestration (heat) は、メタデータのデフォルトのプロバイダーとして内部エンドポイントを使用します。そのため、オーバークラウドノードがパブリックエンドポイントの OpenStack Orchestration にアクセスできるように、アンダークラウドを変更する必要があります。この変更には、director 上の Puppet hieradata の変更などが含まれます。

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

  1. hieradata_override ファイルをまだ使用していない場合には、新しいファイルを作成します。以下の例では、/home/stack/hieradata.yaml にあるファイルを使用します。
  2. /home/stack/hieradata.yaml に以下の hieradata を追加します。

    heat_clients_endpoint_type: public
    heat::engine::default_deployment_signal_transport: TEMP_URL_SIGNAL

    これにより、デフォルトの internal から public にエンドポイントが変更され、TempURL を使用するシグナルの方法が OpenStack Object Storage (swift) から変更されます。

  3. undercloud.conf で、hieradata_override パラメーターを hieradata ファイルのパスに設定します。

    hieradata_override = /home/stack/hieradata.yaml
  4. openstack overcloud install コマンドを再度実行して、新規設定オプションを実装します。

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

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
EC2MetadataIpControlPlaneDefaultRoute パラメーターは、コントロールプレーンの仮想 IP アドレスの値に設定されます。デフォルトの NIC 設定テンプレートでは、これらのパラメーターが必須で、デプロイメント中に実行される検証に合格するには、ping 可能な IP アドレスを使用するように設定する必要があります。または、これらのパラメーターが必要ないように NIC 設定をカスタマイズします。

8.7. 事前にプロビジョニングされたノードでのオーバークラウドの作成

オーバークラウドのデプロイメントには、「CLI ツールを使用したオーバークラウドの作成」に記載の標準の 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 \
  -r /usr/share/openstack-tripleo-heat-templates/deployed-server/deployed-server-roles-data.yaml

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

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

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

8.8. メタデータサーバーのポーリング

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

重要

初期のデプロイメントの場合のみに自動設定を使用します。ノードをスケールアップする場合には自動設定を使用しないでください。

自動設定

director のコア Heat テンプレートコレクションには、オーバークラウドノード上で Heat エージェントの自動設定を行うスクリプトが含まれます。このスクリプトで、director との認証を行ってオーケストレーションサービスに対してクエリーを実行するには、stack ユーザーとして stackrc ファイルを読み込む必要があります。

[stack@director ~]$ source ~/stackrc

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

OVERCLOUD_ROLES
設定するロールのスペース区切りの一覧。これらのロールは、ロールデータファイルで定義したロールに相関します。
[ROLE]_hosts
ロールごとに、環境変数と、ロールに含まれるノードの IP アドレス (スペース区切りの一覧) が必要です。

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

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

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

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

このスクリプトは、スクリプトを実行する同じユーザーを使用して SSH 経由で事前にプロビジョニングされたノードにアクセスします。今回の場合は、スクリプトは、stack ユーザーの認証を行います。

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

  • 各ノードのメタデータ URL を確認するために director のオーケストレーションサービスにクエリーを実行します。
  • ノードにアクセスして、固有のメタデータ URL で各ノードのエージェントを設定します。
  • オーケストレーションエージェントサービスを再起動します。

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

手動による設定

事前にプロビジョニングされたノードでオーケストレーションエージェントを手動で設定する場合には、以下のコマンドを使用して、各ノードの URL に関して director 上のオーケストレーションサービスにクエリーを実行します。

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

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

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

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

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

  1. 既存の os-collect-config.conf テンプレートを削除して、エージェントによって手動の変更が上書きされないようにします。

    $ sudo /bin/rm -f /usr/libexec/os-apply-config/templates/etc/os-collect-config.conf
  2. /etc/os-collect-config.conf ファイルを対応するメタデータ URL を使用するように設定します。たとえば、コントローラーノードは以下を使用します。

    [DEFAULT]
    collectors=request
    command=os-refresh-config
    polling_interval=30
    
    [request]
    metadata_url=http://192.168.24.1:8080/v1/AUTH_6fce4e6019264a5b8283e7125f05b764/ov-edServer-ts6lr4tm5p44-deployed-server-td42md2tap4g/43d302fa-d4c2-40df-b3ac-624d6075ef27?temp_url_sig=58313e577a93de8f8d2367f8ce92dd7be7aac3a1&temp_url_expires=2147483586
  3. ファイルを保存します。
  4. os-collect-config サービスを再起動します。

    [stack@controller ~]$ sudo systemctl restart os-collect-config

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

8.9. オーバークラウド作成の監視

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

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

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

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

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

(undercloud) $ source ~/overcloudrc

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

(overcloud) $

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

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

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

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

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

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

ノードのスケールアップの大まかなプロセスは以下のとおりです。

  1. 要件」の説明に従って、事前にプロビジョニングされたノードを準備します。
  2. ノードをスケールアップします。手順については「10章オーバークラウドのスケーリング」を参照してください。
  3. デプロイメントコマンドを実行した後に、director が新しいノードリソースを作成するまで待ちます。「メタデータサーバーのポーリング」の手順に従って、事前にプロビジョニングされたノードが director のオーケストレーションサーバーのメタデータ URL をポーリングするように設定します。

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

事前にプロビジョニングされたノードでオーバークラウドをスケールダウンするには、「10章オーバークラウドのスケーリング」に記載の通常のスケールダウンの手順に従います。

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

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

注記

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

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

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

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

注記

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

8.13. オーバークラウド作成の完了

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