director のインストールと使用方法

手順

1. お使いのアンダークラウドに root ユーザーとしてログインします。

2. stack ユーザーを作成します。

   [root@director ~]# useradd stack

3. ユーザーのパスワードを設定します。

   [root@director ~]# passwd stack

4. sudo を使用する場合にパスワードを要求されないようにします。

   [root@director ~]# echo "stack ALL=(root) NOPASSWD:ALL" | tee -a /etc/sudoers.d/stack
   [root@director ~]# chmod 0440 /etc/sudoers.d/stack

5. 新規作成した stack ユーザーに切り替えます。

   [root@director ~]# su - stack
   [stack@director ~]$

6. システムイメージおよび heat テンプレート用のディレクトリーを作成します。

   [stack@director ~]$ mkdir ~/images
   [stack@director ~]$ mkdir ~/templates

   director はシステムのイメージと heat テンプレートを使用して、オーバークラウド環境を構築します。ローカルファイルシステムの管理を容易にするために、Red Hat ではこれらのディレクトリーを作成することを推奨します。

7. アンダークラウドのベースおよび完全なホスト名を確認します。

   [stack@director ~]$ hostname
   [stack@director ~]$ hostname -f

   上記のコマンドのいずれかで正しい完全修飾ホスト名が出力されない、またはエラーが表示される場合には、hostnamectl でホスト名を設定します。

   [stack@director ~]$ sudo hostnamectl set-hostname manager.example.com
   [stack@director ~]$ sudo hostnamectl set-hostname --transient manager.example.com

8. /etc/hosts を編集して、システムホスト名のエントリーを追加します。/etc/hosts の IP アドレスは、アンダークラウドのパブリック API に使用する予定のアドレスと一致する必要があります。たとえば、システムの名前が manager.example.com で、IP アドレスに 10.0.0.1 を使用する場合には、/etc/hosts ファイルに以下の行を追加します。

   10.0.0.1  manager.example.com manager

9. Red Hat コンテンツ配信ネットワークまたは Red Hat Satellite のどちらかにシステムを登録します。たとえば、システムをコンテンツ配信ネットワークに登録するには、以下のコマンドを実行します。要求されたら、カスタマーポータルのユーザー名およびパスワードを入力します。

   [stack@director ~]$ sudo subscription-manager register

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

    [stack@director ~]$ sudo subscription-manager list --available --all --matches="Red Hat OpenStack"
    Subscription Name:   Name of SKU
    Provides:            Red Hat Single Sign-On
                         Red Hat Enterprise Linux Workstation
                         Red Hat CloudForms
                         Red Hat OpenStack
                         Red Hat Software Collections (for RHEL Workstation)
                         Red Hat Virtualization
    SKU:                 SKU-Number
    Contract:            Contract-Number
    Pool ID:             Valid-Pool-Number-123456
    Provides Management: Yes
    Available:           1
    Suggested:           1
    Service Level:       Support-level
    Service Type:        Service-Type
    Subscription Type:   Sub-type
    Ends:                End-date
    System Type:         Physical

11. Pool ID の値を特定して、Red Hat OpenStack Platform 16.0 のエンタイトルメントをアタッチします。

    [stack@director ~]$ sudo subscription-manager attach --pool=Valid-Pool-Number-123456

12. アンダークラウドを Red Hat Enterprise Linux 8.1 にロックします。

    $ sudo subscription-manager release --set=8.1

13. デフォルトのリポジトリーをすべて無効にしてから、必要な Red Hat Enterprise Linux リポジトリーを有効にします。

    [stack@director ~]$ sudo subscription-manager repos --disable=*
    [stack@director ~]$ sudo subscription-manager repos --enable=rhel-8-for-x86_64-baseos-eus-rpms --enable=rhel-8-for-x86_64-appstream-eus-rpms --enable=rhel-8-for-x86_64-highavailability-eus-rpms --enable=ansible-2.8-for-rhel-8-x86_64-rpms --enable=openstack-16-for-rhel-8-x86_64-rpms --enable=fast-datapath-for-rhel-8-x86_64-rpms

    これらのリポジトリーには、director のインストールに必要なパッケージが含まれます。

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

    [stack@director ~]$ sudo dnf update -y
    [stack@director ~]$ sudo reboot

15. director のインストールと設定を行うためのコマンドラインツールをインストールします。

    [stack@director ~]$ sudo dnf install -y python3-tripleoclient

手順

1. Ceph Tools リポジトリーを有効にします。

   [stack@director ~]$ sudo subscription-manager repos --enable=rhceph-4-tools-for-rhel-8-x86_64-rpms

2. ceph-ansible パッケージをインストールします。

   [stack@director ~]$ sudo dnf install -y ceph-ansible

手順

1. アンダークラウドホストに stack ユーザーとしてログインします。

2. デフォルトのコンテナーイメージ準備ファイルを生成します。

   $ openstack tripleo container image prepare default \
     --local-push-destination \
     --output-env-file containers-prepare-parameter.yaml

   上記のコマンドでは、以下の追加オプションを使用しています。

   • --local-push-destination: コンテナーイメージの保管場所として、アンダークラウド上のレジストリーを設定します。つまり、director は必要なイメージを Red Hat Container Catalog からプルし、それをアンダークラウド上のレジストリーにプッシュします。director はこのレジストリーをコンテナーイメージのソースとして使用します。Red Hat Container Catalog から直接プルする場合には、このオプションを省略します。

   • --output-env-file: 環境ファイルの名前です。このファイルには、コンテナーイメージを準備するためのパラメーターが含まれます。ここでは、ファイル名は containers-prepare-parameter.yaml です。

     注記

     アンダークラウドとオーバークラウド両方のコンテナーイメージのソースを定義するのに、同じ containers-prepare-parameter.yaml ファイルを使用することができます。

3. 要件に合わせて containers-prepare-parameter.yaml を変更します。

手順

1. containers-prepare-parameter.yaml ファイルを編集し、Ceph Storage コンテナーを除外します。

   parameter_defaults:
     ContainerImagePrepare:
     - push_destination: true
       excludes:
         - ceph
         - prometheus
       set:
         …​

   excludes パラメーターは正規表現を使用して、ceph または prometheus 文字列を含むコンテナーイメージを除外します。

2. containers-prepare-parameter.yaml ファイルを保存します。

手順

1. すべてのコンテナーイメージの一覧を作成します。

   $ sudo podman search --limit 1000 "registry.redhat.io/rhosp" | grep rhosp-rhel8 | awk '{ print $2 }' | grep -v beta | sed "s/registry.redhat.io\///g" | tail -n+2 > satellite_images

2. Satellite 6 の hammer ツールがインストールされているシステムに satellite_images ファイルをコピーします。あるいは、『 Hammer CLI ガイド』 に記載の手順に従って、アンダークラウドに hammer ツールをインストールします。

3. 以下の hammer コマンドを実行して、実際の Satellite 組織に新規製品 (OSP16 Containers) を作成します。

   $ hammer product create \
     --organization "ACME" \
     --name "OSP16 Containers"

   このカスタム製品に、イメージを保管します。

4. 製品にベースコンテナーイメージを追加します。

   $ hammer repository create \
     --organization "ACME" \
     --product "OSP16 Containers" \
     --content-type docker \
     --url https://registry.redhat.io \
     --docker-upstream-name rhosp-rhel8/openstack-base \
     --upstream-username USERNAME \
     --upstream-password PASSWORD \
     --name base

5. satellite_images ファイルからオーバークラウドのコンテナーイメージを追加します。

   $ while read IMAGE; do \
     IMAGENAME=$(echo $IMAGE | cut -d"/" -f2 | sed "s/openstack-//g" | sed "s/:.*//g") ; \
     hammer repository create \
     --organization "ACME" \
     --product "OSP16 Containers" \
     --content-type docker \
     --url https://registry.redhat.io \
     --docker-upstream-name $IMAGE \
     --upstream-username USERNAME \
     --upstream-password PASSWORD \
     --name $IMAGENAME ; done < satellite_images

6. Ceph Storage 4 コンテナーイメージを追加します。

   $ hammer repository create \
     --organization "ACME" \
     --product "OSP16 Containers" \
     --content-type docker \
     --url https://registry.redhat.io \
     --docker-upstream-name rhceph-beta/rhceph-4-rhel8 \
     --upstream-username USERNAME \
     --upstream-password PASSWORD \
     --name rhceph-4-rhel8

7. コンテナーイメージを同期します。

   $ hammer product synchronize \
     --organization "ACME" \
     --name "OSP16 Containers"

   Satellite Server が同期を完了するまで待ちます。

   注記

   設定によっては、hammer により Satellite サーバーのユーザー名とパスワードを求めるプロンプトが出される場合があります。設定ファイルを使用して自動的にログインするように hammer を設定できます。詳細は、『 Hammer CLI ガイド』 の 「認証」 セクションを参照してください。

8. お使いの Satellite 6 サーバーでコンテンツビューが使われている場合には、新たなバージョンのコンテンツビューを作成してイメージを反映し、アプリケーションライフサイクルの環境に従ってプロモートします。この作業は、アプリケーションライフサイクルをどのように構成するかに大きく依存します。たとえば、ライフサイクルに production という名称の環境があり、その環境でコンテナーイメージを利用可能にする場合には、コンテナーイメージを含むコンテンツビューを作成し、そのコンテンツビューを production 環境にプロモートします。詳細は、「 コンテンツビューの管理」 を参照してください。

9. base イメージに使用可能なタグを確認します。

   $ hammer docker tag list --repository "base" \
     --organization "ACME" \
     --lifecycle-environment "production" \
     --content-view "myosp16" \
     --product "OSP16 Containers"

   このコマンドにより、特定環境のコンテンツビューでの OpenStack Platform コンテナーイメージのタグが表示されます。

10. アンダークラウドに戻り、Satellite サーバーをソースとして使用して、イメージを準備するデフォルトの環境ファイルを生成します。以下のサンプルコマンドを実行して環境ファイルを生成します。

    $ openstack tripleo container image prepare default \
      --output-env-file containers-prepare-parameter.yaml

    • --output-env-file: 環境ファイルの名前です。このファイルには、アンダークラウド用コンテナーイメージを準備するためのパラメーターが含まれます。ここでは、ファイル名は containers-prepare-parameter.yaml です。

11. containers-prepare-parameter.yaml ファイルを編集して以下のパラメーターを変更します。

    • push_destination: 選択したコンテナーイメージの管理手段に応じて、これを true または false に設定します。このパラメーターを false に設定すると、オーバークラウドノードはイメージを直接 Satellite からプルします。このパラメーターを true に設定すると、director はイメージを Satellite からアンダークラウドレジストリーにプルし、オーバークラウドはそのイメージをアンダークラウドレジストリーからプルします。
    • namespace: Satellite サーバー上のレジストリーの URL およびポート。Red Hat Satellite のデフォルトのレジストリーポートは 5000 です。

    • name_prefix: プレフィックスは Satellite 6 の命名規則に基づきます。これは、コンテンツビューを使用するかどうかによって異なります。

      • コンテンツビューを使用する場合、構成は [org]-[environment]-[content view]-[product]- です。たとえば、acme-production-myosp16-osp16_containers- のようになります。
      • コンテンツビューを使用しない場合、構成は [org]-[product]- です。たとえば、acme-osp16_containers- のようになります。
    • ceph_namespace、ceph_image、ceph_tag: Ceph Storage を使用する場合には、Ceph Storage コンテナーイメージの場所を定義するこれらの追加パラメーターを指定します。ceph_image に Satellite 固有のプレフィックスが追加された点に注意してください。このプレフィックスは、name_prefix オプションと同じ値です。

手順

1. デフォルトのテンプレートを stack ユーザーのホームディレクトリーにコピーします。

   [stack@director ~]$ cp \
     /usr/share/python-tripleoclient/undercloud.conf.sample \
     ~/undercloud.conf

2. undercloud.conf ファイルを編集します。このファイルには、アンダークラウドを設定するための設定値が含まれています。パラメーターを省略したり、コメントアウトした場合には、アンダークラウドのインストールでデフォルト値が使用されます。

手順

1. /home/stack/templates/custom-undercloud-params.yaml という名前で環境ファイルを作成します。

2. このファイルを編集して、必要な heat パラメーターを追加します。たとえば、特定の OpenStack Platform サービスのデバッグを有効にするには、custom-undercloud-params.yaml ファイルに以下のスニペットを追加します。

   parameter_defaults:
     Debug: True

   完了したら、このファイルを保存します。

3. undercloud.conf ファイルを編集し、custom_env_files パラメーターまでスクロールします。作成した custom-undercloud-params.yaml 環境ファイルをポイントするようにパラメーターを編集します。

   custom_env_files = /home/stack/templates/custom-undercloud-params.yaml

   注記

   コンマ区切りリストを使用して、複数の環境ファイルを指定することができます。

手順

1. hieradata オーバーライドファイルを作成します (例: /home/stack/hieradata.yaml)。

2. カスタマイズした hieradata をファイルに追加します。たとえば、Compute (nova) サービスのパラメーター force_raw_images をデフォルト値の True から False に変更するには、以下のスニペットを追加します。

   nova::compute::force_raw_images: False

   設定するパラメーターに Puppet 実装がない場合には、以下の手段によりパラメーターを設定します。

   nova::config::nova_config:
     DEFAULT/<parameter_name>:
       value: <parameter_value>

   以下に例を示します。

   nova::config::nova_config:
     DEFAULT/network_allocate_retries:
       value: 20
     ironic/serial_console_state_timeout:
       value: 15

3. undercloud.conf ファイルの hieradata_override パラメーターを、新しい /home/stack/hieradata.yaml ファイルのパスに設定します。

   hieradata_override = /home/stack/hieradata.yaml

手順

1. サンプルの undercloud.conf ファイルをコピーするか、既存の undercloud.conf ファイルを変更します。

2. undercloud.conf ファイルで以下のパラメーター値を設定します。

   1. NIC が Red Hat OpenStack Platform でステートフル DHCPv6 をサポートする場合は、ipv6_address_mode を dhcpv6-stateless または dhcpv6-stateful に設定します。ステートフルな DHCPv6 の可用性についての詳しい情報は、Bugzilla #1575026 を参照してください。
   2. アンダークラウドでプロビジョニングネットワークにルーターを作成する必要がない場合は、enable_routed_networks を true に設定します。この場合、データセンタールーターはルーター広告を提供する必要があります。それ以外の場合は、この値を false に設定します。
   3. local_ip をアンダークラウドの IPv6 アドレスに設定します。
   4. アンダークラウドインターフェースのパラメーター undercloud_public_host と undercloud_admin_host に IPv6 アドレス設定を使用します。

   5. [ctlplane-subnet] セクションで、以下のパラメーターに IPv6 アドレス設定を使用します。

      • cidr
      • dhcp_start
      • dhcp_end
      • gateway
      • inspection_iprange

   6. [ctlplane-subnet] セクションで、dns_nameservers パラメーターにサブネットの IPv6 ネームサーバーを設定します。

      ipv6_address_mode = dhcpv6-stateless
      enable_routed_networks: false
      local_ip = <ipv6-address>
      undercloud_admin_host = <ipv6-address>
      undercloud_public_host = <ipv6-address>
      
      [ctlplane-subnet]
      cidr = <ipv6-address>::<ipv6-mask>
      dhcp_start = <ipv6-address>
      dhcp_end = <ipv6-address>
      dns_nameservers = <ipv6-dns>
      gateway = <ipv6-address>
      inspection_iprange = <ipv6-address>,<ipv6-address>

手順

1. 以下のコマンドを実行して、アンダークラウドに director をインストールします。

   [stack@director ~]$ openstack undercloud install

   このコマンドにより、director の設定スクリプトが起動します。director により追加のパッケージがインストールされ、undercloud.conf の設定に応じてサービスが設定されます。このスクリプトは、完了までに数分かかります。

   スクリプトにより、2 つのファイルが生成されます。

   • undercloud-passwords.conf: director サービスの全パスワード一覧
   • stackrc: director コマンドラインツールへアクセスできるようにする初期化変数セット

2. このスクリプトは、全 OpenStack Platform サービスのコンテナーも自動的に起動します。以下のコマンドを使用して、有効になったコンテナーを確認することができます。

   [stack@director ~]$ sudo podman ps

3. stack ユーザーを初期化してコマンドラインツールを使用するには、以下のコマンドを実行します。

   [stack@director ~]$ source ~/stackrc

   プロンプトには、OpenStack コマンドがアンダークラウドに対して認証および実行されることが表示されるようになります。

   (undercloud) [stack@director ~]$

手順

1. source コマンドで stackrc ファイルを読み込み、director コマンドラインツールを有効にします。

   [stack@director ~]$ source ~/stackrc

2. ctlplane-subnet サブネット用のネームサーバーを設定します。

   (undercloud) [stack@director images]$ openstack subnet set --dns-nameserver [nameserver1-ip] --dns-nameserver [nameserver2-ip] ctlplane-subnet

   各ネームサーバーに --dns-nameserver オプションを使用します。

3. サブネットを表示してネームサーバーを確認します。

   (undercloud) [stack@director images]$ openstack subnet show ctlplane-subnet
   +-------------------+-----------------------------------------------+
   | Field             | Value                                         |
   +-------------------+-----------------------------------------------+
   | ...               |                                               |
   | dns_nameservers   | 8.8.8.8                                       |
   | ...               |                                               |
   +-------------------+-----------------------------------------------+

手順

1. アンダークラウドの設定ファイルを変更します。以下の例では、undercloud.conf ファイルを編集して、有効なハードウェア種別の一覧に idrac ハードウェア種別を追加しています。

   enabled_hardware_types = ipmi,redfish,idrac

2. openstack undercloud install コマンドを実行し、新たな変更を反映させてアンダークラウドを更新します。

   [stack@director ~]$ openstack undercloud install

   コマンドの実行が完了するまで待ちます。

3. stack ユーザーを初期化し、コマンドラインツールを使用します。

   [stack@director ~]$ source ~/stackrc

   プロンプトには、OpenStack コマンドがアンダークラウドに対して認証および実行されることが表示されるようになります。

   (undercloud) [stack@director ~]$

4. director が新しい設定を適用していることを確認します。この例では、有効なハードウェア種別の一覧を確認しています。

   (undercloud) [stack@director ~]$ openstack baremetal driver list
   +---------------------+----------------+
   | Supported driver(s) | Active host(s) |
   +---------------------+----------------+
   | idrac               | unused         |
   | ipmi                | unused         |
   | redfish             | unused         |
   +---------------------+----------------+

手順

1. ミニオンホストに root ユーザーとしてログインします。

2. stack ユーザーを作成します。

   [root@minion ~]# useradd stack

3. stack ユーザーのパスワードを設定します。

   [root@minion ~]# passwd stack

4. sudo を使用する場合にパスワードを要求されないようにします。

   [root@minion ~]# echo "stack ALL=(root) NOPASSWD:ALL" | tee -a /etc/sudoers.d/stack
   [root@minion ~]# chmod 0440 /etc/sudoers.d/stack

5. 新規作成した stack ユーザーに切り替えます。

   [root@minion ~]# su - stack
   [stack@minion ~]$

6. ミニオンのベースおよび完全なホスト名を確認します。

   [stack@minion ~]$ hostname
   [stack@minion ~]$ hostname -f

   上記のコマンドのいずれかで正しい完全修飾ホスト名が出力されない、またはエラーが表示される場合には、hostnamectl でホスト名を設定します。

   [stack@minion ~]$ sudo hostnamectl set-hostname minion.example.com
   [stack@minion ~]$ sudo hostnamectl set-hostname --transient minion.example.com

7. /etc/hosts ファイルを編集して、システムホスト名のエントリーを追加します。たとえば、システムの名前が minion.example.com で、IP アドレスに 10.0.0.1 を使用する場合には、/etc/hosts ファイルに以下の行を追加します。

   10.0.0.1  minion.example.com manager

8. Red Hat コンテンツ配信ネットワークまたは Red Hat Satellite のどちらかにシステムを登録します。たとえば、システムをコンテンツ配信ネットワークに登録するには、以下のコマンドを実行します。要求されたら、カスタマーポータルのユーザー名およびパスワードを入力します。

   [stack@minion ~]$ sudo subscription-manager register

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

   [stack@minion ~]$ sudo subscription-manager list --available --all --matches="Red Hat OpenStack"
   Subscription Name:   Name of SKU
   Provides:            Red Hat Single Sign-On
                        Red Hat Enterprise Linux Workstation
                        Red Hat CloudForms
                        Red Hat OpenStack
                        Red Hat Software Collections (for RHEL Workstation)
                        Red Hat Virtualization
   SKU:                 SKU-Number
   Contract:            Contract-Number
   Pool ID:             Valid-Pool-Number-123456
   Provides Management: Yes
   Available:           1
   Suggested:           1
   Service Level:       Support-level
   Service Type:        Service-Type
   Subscription Type:   Sub-type
   Ends:                End-date
   System Type:         Physical

10. Pool ID の値を特定して、Red Hat OpenStack Platform 16.0 のエンタイトルメントをアタッチします。

    [stack@minion ~]$ sudo subscription-manager attach --pool=Valid-Pool-Number-123456

11. デフォルトのリポジトリーをすべて無効にしてから、必要な Red Hat Enterprise Linux リポジトリーを有効にします。

    [stack@minion ~]$ sudo subscription-manager repos --disable=*
    [stack@minion ~]$ sudo subscription-manager repos --enable=rhel-8-for-x86_64-baseos-eus-rpms --enable=rhel-8-for-x86_64-appstream-eus-rpms --enable=rhel-8-for-x86_64-highavailability-eus-rpms --enable=ansible-2.8-for-rhel-8-x86_64-rpms --enable=openstack-16-for-rhel-8-x86_64-rpms --enable=fast-datapath-for-rhel-8-x86_64-rpms

    これらのリポジトリーには、ミニオンのインストールに必要なパッケージが含まれます。

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

    [stack@minion ~]$ sudo dnf update -y
    [stack@minion ~]$ sudo reboot

13. ミニオンのインストールと設定を行うためのコマンドラインツールをインストールします。

    [stack@minion ~]$ sudo dnf install -y python3-tripleoclient

手順

1. アンダークラウドに stack ユーザーとしてログインします。

2. ファイルをアンダークラウドからミニオンにコピーします。

   $ scp ~/tripleo-undercloud-outputs.yaml ~/tripleo-undercloud-passwords.yaml stack@<minion-host>:~/.

   <minion-host> は、ミニオンのホスト名または IP アドレスに置き換えます。

手順

1. ミニオンホストに root ユーザーとしてログインします。

2. 認証局ファイルをアンダークラウドからミニオンにコピーします。

   [root@minion ~]# scp \
       root@<undercloud-host>:/etc/pki/ca-trust/source/anchors/cm-local-ca.pem \
       /etc/pki/ca-trust/source/anchors/undercloud-ca.pem

   <undercloud-host> は、アンダークラウドのホスト名または IP アドレスに置き換えます。

3. ミニオンホストの信頼済み認証局を更新します。

   [root@minion ~]# update-ca-trust enable
   [root@minion ~]# update-ca-trust extract

手順

1. ミニオンホストに stack ユーザーとしてログインします。

2. デフォルトのテンプレートを stack ユーザーのホームディレクトリーにコピーします。

   [stack@minion ~]$ cp \
     /usr/share/python-tripleoclient/minion.conf.sample \
     ~/minion.conf

3. minion.conf ファイルを編集します。このファイルには、ミニオンを設定するためのパラメーターが含まれています。パラメーターを省略したり、コメントアウトした場合には、ミニオンのインストールでデフォルト値が使用されます。以下の推奨パラメーターを確認してください。

   • minion_hostname: ミニオンのホスト名に設定します。
   • minion_local_interface: プロビジョニングネットワークを介してアンダーグラウンドに接続するインターフェースに設定します。
   • minion_local_ip: プロビジョニングネットワークのフリー IP アドレスに設定します。
   • minion_nameservers: ミニオンがホスト名を解決できるように DNS ネームサーバーに設定します。
   • enable_ironic_conductor: ironic-conductor サービスを有効にするかどうかを定義します。
   • enable_heat_engine: heat-engine サービスを有効にするかどうかを定義します。

手順

1. ミニオンホストに stack ユーザーとしてログインします。

2. 以下のコマンドを実行して、ミニオンをインストールします。

   [stack@minion ~]$ openstack undercloud minion install

   このコマンドによりミニオンの設定スクリプトが起動し、追加のパッケージがインストールされ、minion.conf ファイルの設定に応じてミニオンサービスが設定されます。このスクリプトは、完了までに数分かかります。

手順

1. アンダークラウドに stack ユーザーとしてログインします。

2. stackrc ファイルを取得します。

   [stack@director ~]$ source ~/stackrc

3. ミニオンで heat engine サービスを有効にしている場合には、ミニオンからの heat-engine サービスがアンダークラウドサービスのリストに表示されることを確認します。

   [stack@director ~]$ $ openstack orchestration service list

   このコマンド出力には、アンダークラウドとミニオン両方の heat-engine ワーカーが記載された表が表示されます。

4. ミニオンで ironic conductor サービスを有効にしている場合には、ミニオンからの ironic-conductor サービスがアンダークラウドサービスのリストに表示されることを確認します。

   [stack@director ~]$ $ openstack baremetal conductor list

   このコマンド出力には、アンダークラウドとミニオン両方の ironic-conductor ワーカーが記載された表が表示されます。

手順

1. ノードの一覧が含まれるテンプレートを作成します。以下の例に示す JSON および YAML テンプレートを使用して、ノード定義のテンプレートを構成する方法を説明します。

   JSON テンプレートの例

   {
       "nodes":[
           {
               "mac":[
                   "bb:bb:bb:bb:bb:bb"
               ],
               "name":"node01",
               "cpu":"4",
               "memory":"6144",
               "disk":"40",
               "arch":"x86_64",
               "pm_type":"ipmi",
               "pm_user":"admin",
               "pm_password":"p@55w0rd!",
               "pm_addr":"192.168.24.205"
           },
           {
               "mac":[
                   "cc:cc:cc:cc:cc:cc"
               ],
               "name":"node02",
               "cpu":"4",
               "memory":"6144",
               "disk":"40",
               "arch":"x86_64",
               "pm_type":"ipmi",
               "pm_user":"admin",
               "pm_password":"p@55w0rd!",
               "pm_addr":"192.168.24.206"
           }
       ]
   }

   YAML テンプレートの例

   nodes:
     - mac:
         - "bb:bb:bb:bb:bb:bb"
       name: "node01"
       cpu: 4
       memory: 6144
       disk: 40
       arch: "x86_64"
       pm_type: "ipmi"
       pm_user: "admin"
       pm_password: "p@55w0rd!"
       pm_addr: "192.168.24.205"
     - mac:
         - cc:cc:cc:cc:cc:cc
       name: "node02"
       cpu: 4
       memory: 6144
       disk: 40
       arch: "x86_64"
       pm_type: "ipmi"
       pm_user: "admin"
       pm_password: "p@55w0rd!"
       pm_addr: "192.168.24.206"

   このテンプレートには、以下の属性が含まれます。

   name

   ノードの論理名

   pm_type

   使用する電源管理ドライバー。この例では IPMI ドライバー (ipmi) を使用しています。

   注記

   IPMI が推奨されるサポート対象電源管理ドライバーです。サポート対象電源管理ドライバーの種別およびそのオプションに関する詳細は、「付録A 電源管理ドライバー」を参照してください。それらの電源管理ドライバーが想定どおりに機能しない場合には、電源管理に IPMI を使用してください。

   pm_user; pm_password

   IPMI のユーザー名およびパスワード

   pm_addr

   IPMI デバイスの IP アドレス

   pm_port (オプション)

   特定の IPMI デバイスにアクセスするためのポート

   mac

   (オプション) ノード上のネットワークインターフェースの MAC アドレス一覧。各システムのプロビジョニング NIC の MAC アドレスのみを使用します。

   cpu

   (オプション) ノード上の CPU 数

   memory

   (オプション) メモリーサイズ (MB 単位)

   disk

   (オプション) ハードディスクのサイズ (GB 単位)

   arch

   (オプション) システムアーキテクチャー

   重要

   マルチアーキテクチャークラウドをビルドする場合には、x86_64 アーキテクチャーを使用するノードと ppc64le アーキテクチャーを使用するノードを区別するために arch キーが必須です。

2. テンプレートを作成したら、以下のコマンドを実行してフォーマットおよび構文を検証します。

   $ source ~/stackrc
   (undercloud) $ openstack overcloud node import --validate-only ~/nodes.json

3. stack ユーザーのホームディレクトリーにファイルを保存し (/home/stack/nodes.json)、続いて以下のコマンドを実行してテンプレートを director にインポートします。

   (undercloud) $ openstack overcloud node import ~/nodes.json

   このコマンドにより、それぞれのノードがテンプレートから director に登録されます。

4. ノードの登録および設定が完了するまで待ちます。完了したら、ノードが director に正しく登録されていることを確認します。

   (undercloud) $ openstack baremetal node list

手順

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

   $ source ~/stackrc

2. --group pre-introspection オプションを指定して openstack tripleo validator run コマンドを実行します。

   $ openstack tripleo validator run --group pre-introspection

3. 検証レポートの結果を確認します。

手順

1. 以下のコマンドを実行して、各ノードのハードウェア属性を検証します。

   (undercloud) $ openstack overcloud node introspect --all-manageable --provide

   • --all-manageable オプションを使用して、管理状態にあるノードのみをイントロスペクションします。ここでは、すべてのノードが管理状態にあります。
   • --provide オプションを使用して、イントロスペクション後に全ノードを available の状態に再設定します。

2. 別のターミナルウィンドウで、イントロスペクションの進捗ログを監視します。

   (undercloud) $ sudo tail -f /var/log/containers/ironic-inspector/ironic-inspector.log

   重要

   このプロセスを必ず完了させてください。ベアメタルノードの場合には、通常 15 分ほどかかります。

手順

1. 特定のプロファイルにノードをタグ付けする場合には、各ノードの properties/capabilities パラメーターに profile オプションを追加します。たとえば、2 つのノードをタグ付けしてコントローラープロファイルとコンピュートプロファイルをそれぞれ使用するには、以下のコマンドを実行します。

   (undercloud) $ openstack baremetal node set --property capabilities='profile:control,boot_option:local' 1a4e30da-b6dc-499d-ba87-0bd8a3819bc0
   (undercloud) $ openstack baremetal node set --property capabilities='profile:compute,boot_option:local' 58c3d07e-24f2-48a7-bbb6-6843f0e8ee13

   profile:control と profile:compute オプションを追加することで、この 2 つのノードがそれぞれのプロファイルにタグ付けされます。

   これらのコマンドは、各ノードのブート方法を定義する boot_option:local パラメーターも設定します。

2. ノードのタグ付けが完了した後には、割り当てたプロファイルまたはプロファイルの候補を確認します。

   (undercloud) $ openstack overcloud profiles list

手順

1. undercloud.conf ファイルで以下のパラメーターを設定します。

   ipxe_enabled = True
   inspection_enable_uefi = True

2. undercloud.conf ファイルを保存して、アンダークラウドのインストールを実行します。

   $ openstack undercloud install

   インストールスクリプトが完了するまで待ちます。

3. 登録済みの各ノードのブートモードを uefi に設定します。たとえば、capabilities プロパティーに boot_mode パラメーターを追加する場合や既存のパラメーターを置き換える場合には、以下のコマンドを実行します。

   $ NODE=<NODE NAME OR ID> ; openstack baremetal node set --property capabilities="boot_mode:uefi,$(openstack baremetal node show $NODE -f json -c properties | jq -r .properties.capabilities | sed "s/boot_mode:[^,]*,//g")" $NODE

   注記

   profile および boot_option のケイパビリティーが保持されていることを確認してください。

   $ openstack baremetal node show r530-12 -f json -c properties | jq -r .properties.capabilities

4. 各フレーバーのブートモードを uefi に設定します。

   $ openstack flavor set --property capabilities:boot_mode='uefi' control

手順

1. Bare Metal サービス (ironic) のブートインターフェースを redfish-virtual-media に設定します。

   $ openstack baremetal node set --boot-interface redfish-virtual-media $NODE_NAME

   $NODE_NAME はノード名に置き換えてください。

2. UEFI ノードの場合は、ブートモードを uefi に設定します。

   NODE=<NODE NAME OR ID> ; openstack baremetal node set --property capabilities="boot_mode:uefi,$(openstack baremetal node show $NODE -f json -c properties | jq -r .properties.capabilities | sed "s/boot_mode:[^,]*,//g")" $NODE

   $NODE はノード名に置き換えてください。

   注記

   BIOS ノードの場合は、このステップを実施しないでください。

3. UEFI ノードの場合は、EFI システムパーティション (ESP) イメージを定義します。

   $ openstack baremetal node set --driver-info bootloader=$ESP $NODE_NAME

   $ESP は glance イメージの UUID または ESP イメージの URL に、$NODE_NAME はノードの名前に、それぞれ置き換えてください。

   注記

   BIOS ノードの場合は、このステップを実施しないでください。

4. ベアメタルノードにポートを作成し、そのポートをベアメタルノード上の NIC の MAC アドレスに関連付けます。

   $ openstack baremetal port create --pxe-enabled True --node $UUID $MAC_ADDRESS

   $UUID はベアメタルノードの UUID に、$MAC_ADDRESS はベアメタルノード上の NIC の MAC アドレスに、それぞれ置き換えてください。

手順

1. 各ノードのハードウェアイントロスペクションからのディスク情報を確認します。以下のコマンドを実行して、ノードのディスク情報を表示します。

   (undercloud) $ openstack baremetal introspection data save 1a4e30da-b6dc-499d-ba87-0bd8a3819bc0 | jq ".inventory.disks"

   たとえば、1 つのノードのデータで 3 つのディスクが表示される場合があります。

   [
     {
       "size": 299439751168,
       "rotational": true,
       "vendor": "DELL",
       "name": "/dev/sda",
       "wwn_vendor_extension": "0x1ea4dcc412a9632b",
       "wwn_with_extension": "0x61866da04f3807001ea4dcc412a9632b",
       "model": "PERC H330 Mini",
       "wwn": "0x61866da04f380700",
       "serial": "61866da04f3807001ea4dcc412a9632b"
     }
     {
       "size": 299439751168,
       "rotational": true,
       "vendor": "DELL",
       "name": "/dev/sdb",
       "wwn_vendor_extension": "0x1ea4e13c12e36ad6",
       "wwn_with_extension": "0x61866da04f380d001ea4e13c12e36ad6",
       "model": "PERC H330 Mini",
       "wwn": "0x61866da04f380d00",
       "serial": "61866da04f380d001ea4e13c12e36ad6"
     }
     {
       "size": 299439751168,
       "rotational": true,
       "vendor": "DELL",
       "name": "/dev/sdc",
       "wwn_vendor_extension": "0x1ea4e31e121cfb45",
       "wwn_with_extension": "0x61866da04f37fc001ea4e31e121cfb45",
       "model": "PERC H330 Mini",
       "wwn": "0x61866da04f37fc00",
       "serial": "61866da04f37fc001ea4e31e121cfb45"
     }
   ]

2. openstack baremetal node set --property root_device= コマンドを実行して、ノードのルートディスクを設定します。ルートディスクを定義するのに最も適切なハードウェア属性値を指定します。

   (undercloud) $ openstack baremetal node set --property root_device=’{“serial”:”<serial_number>”}' <node-uuid>

   たとえば、ルートデバイスをシリアル番号が 61866da04f380d001ea4e13c12e36ad6 の disk 2 に設定するには、以下のコマンドを実行します。

手順

1. overcloud-minimal イメージを使用するように director を設定するには、以下のイメージ定義を含む環境ファイルを作成します。

   parameter_defaults:
     <roleName>Image: overcloud-minimal

2. <roleName> をロール名に置き換え、ロール名に Image を追加します。Ceph Storage ノードの overcloud-minimal イメージの例を以下に示します。

   parameter_defaults:
     CephStorageImage: overcloud-minimal

3. この環境ファイルを openstack overcloud deploy コマンドに渡します。

手順

1. /home/stack/templates/ ディレクトリーに node-info.yaml ファイルを作成します。

   (undercloud) $ touch /home/stack/templates/node-info.yaml

2. ファイルを編集し、必要なノード数およびフレーバーを設定します。以下の例には、3 台のコントローラーノードおよび 3 台のコンピュートノードが含まれます。

   parameter_defaults:
     OvercloudControllerFlavor: control
     OvercloudComputeFlavor: compute
     ControllerCount: 3
     ComputeCount: 3

手順

1. 証明書ファイルを開き、証明書部分だけをコピーします。鍵を含めないでください。

   $ vi /home/stack/ca.crt.pem

   必要となる証明書部分の例を、以下に示します。

   -----BEGIN CERTIFICATE-----
   MIIDlTCCAn2gAwIBAgIJAOnPtx2hHEhrMA0GCSqGSIb3DQEBCwUAMGExCzAJBgNV
   BAYTAlVTMQswCQYDVQQIDAJOQzEQMA4GA1UEBwwHUmFsZWlnaDEQMA4GA1UECgwH
   UmVkIEhhdDELMAkGA1UECwwCUUUxFDASBgNVBAMMCzE5Mi4xNjguMC4yMB4XDTE3
   -----END CERTIFICATE-----

2. 以下に示す内容で /home/stack/inject-trust-anchor-hiera.yaml という名称の新たな YAML ファイルを作成し、PEM ファイルからコピーした証明書を追加します。

   parameter_defaults:
     CAMap:
       undercloud-ca:
         content: |
           -----BEGIN CERTIFICATE-----
           MIIDlTCCAn2gAwIBAgIJAOnPtx2hHEhrMA0GCSqGSIb3DQEBCwUAMGExCzAJBgNV
           BAYTAlVTMQswCQYDVQQIDAJOQzEQMA4GA1UEBwwHUmFsZWlnaDEQMA4GA1UECgwH
           UmVkIEhhdDELMAkGA1UECwwCUUUxFDASBgNVBAMMCzE5Mi4xNjguMC4yMB4XDTE3
           -----END CERTIFICATE-----

1. カスタムの環境ファイルおよび heat テンプレートのパラメーターを変更します。
2. 同じ環境ファイルを指定して openstack overcloud deploy コマンドを再度実行します。

手順

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

   $ source ~/stackrc

2. この検証には、オーバークラウドプランのコピーが必要です。必要なすべての環境ファイルと共に、オーバークラウドプランをアップロードします。プランのみをアップロードするには、--update-plan-only オプションを指定して openstack overcloud deploy コマンドを実行します。

   $ openstack overcloud deploy --templates \
       -e environment-file1.yaml \
       -e environment-file2.yaml \
       ...
       --update-plan-only

3. --group pre-deployment オプションを指定して、openstack tripleo validator run コマンドを実行します。

   $ openstack tripleo validator run --group pre-deployment

4. オーバークラウドにデフォルトのプラン名 overcloud 以外の名前を使用する場合は、--plan オプションでプラン名を設定します。

   $ openstack tripleo validator run --group pre-deployment \
       --plan myovercloud

5. 検証レポートの結果を確認します。

手順

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

   $ source ~/stackrc

2. --group post-deployment オプションを指定して、openstack tripleo validator run コマンドを実行します。

   $ openstack tripleo validator run --group post-deployment

3. オーバークラウドにデフォルトのプラン名 overcloud 以外の名前を使用する場合は、--plan オプションでプラン名を設定します。

   $ openstack tripleo validator run --group post-deployment \
       --plan myovercloud

4. 検証レポートの結果を確認します。

手順

1. ノードの一覧が含まれるテンプレートを作成します。以下の例に示す JSON および YAML テンプレートを使用して、ノード定義のテンプレートを構成する方法を説明します。

   JSON テンプレートの例

   {
       "nodes":[
           {
               "mac":[
                   "bb:bb:bb:bb:bb:bb"
               ],
               "name":"node01",
               "cpu":"4",
               "memory":"6144",
               "disk":"40",
               "arch":"x86_64",
               "pm_type":"ipmi",
               "pm_user":"admin",
               "pm_password":"p@55w0rd!",
               "pm_addr":"192.168.24.205"
           },
           {
               "mac":[
                   "cc:cc:cc:cc:cc:cc"
               ],
               "name":"node02",
               "cpu":"4",
               "memory":"6144",
               "disk":"40",
               "arch":"x86_64",
               "pm_type":"ipmi",
               "pm_user":"admin",
               "pm_password":"p@55w0rd!",
               "pm_addr":"192.168.24.206"
           }
       ]
   }

   YAML テンプレートの例

   nodes:
     - mac:
         - "bb:bb:bb:bb:bb:bb"
       name: "node01"
       cpu: 4
       memory: 6144
       disk: 40
       arch: "x86_64"
       pm_type: "ipmi"
       pm_user: "admin"
       pm_password: "p@55w0rd!"
       pm_addr: "192.168.24.205"
     - mac:
         - cc:cc:cc:cc:cc:cc
       name: "node02"
       cpu: 4
       memory: 6144
       disk: 40
       arch: "x86_64"
       pm_type: "ipmi"
       pm_user: "admin"
       pm_password: "p@55w0rd!"
       pm_addr: "192.168.24.206"

   このテンプレートには、以下の属性が含まれます。

   name

   ノードの論理名

   pm_type

   使用する電源管理ドライバー。この例では IPMI ドライバー (ipmi) を使用しています。

   注記

   IPMI が推奨されるサポート対象電源管理ドライバーです。サポート対象電源管理ドライバーの種別およびそのオプションに関する詳細は、「付録A 電源管理ドライバー」を参照してください。それらの電源管理ドライバーが想定どおりに機能しない場合には、電源管理に IPMI を使用してください。

   pm_user; pm_password

   IPMI のユーザー名およびパスワード

   pm_addr

   IPMI デバイスの IP アドレス

   pm_port (オプション)

   特定の IPMI デバイスにアクセスするためのポート

   mac

   (オプション) ノード上のネットワークインターフェースの MAC アドレス一覧。各システムのプロビジョニング NIC の MAC アドレスのみを使用します。

   cpu

   (オプション) ノード上の CPU 数

   memory

   (オプション) メモリーサイズ (MB 単位)

   disk

   (オプション) ハードディスクのサイズ (GB 単位)

   arch

   (オプション) システムアーキテクチャー

   重要

   マルチアーキテクチャークラウドをビルドする場合には、x86_64 アーキテクチャーを使用するノードと ppc64le アーキテクチャーを使用するノードを区別するために arch キーが必須です。

2. テンプレートを作成したら、以下のコマンドを実行してフォーマットおよび構文を検証します。

   $ source ~/stackrc
   (undercloud) $ openstack overcloud node import --validate-only ~/nodes.json

3. stack ユーザーのホームディレクトリーにファイルを保存し (/home/stack/nodes.json)、続いて以下のコマンドを実行してテンプレートを director にインポートします。

   (undercloud) $ openstack overcloud node import ~/nodes.json

   このコマンドにより、それぞれのノードがテンプレートから director に登録されます。

4. ノードの登録および設定が完了するまで待ちます。完了したら、ノードが director に正しく登録されていることを確認します。

   (undercloud) $ openstack baremetal node list

手順

1. 以下のコマンドを実行して、各ノードのハードウェア属性を検証します。

   (undercloud) $ openstack overcloud node introspect --all-manageable --provide

   • --all-manageable オプションを使用して、管理状態にあるノードのみをイントロスペクションします。ここでは、すべてのノードが管理状態にあります。
   • --provide オプションを使用して、イントロスペクション後に全ノードを available の状態に再設定します。

2. 別のターミナルウィンドウで、イントロスペクションの進捗ログを監視します。

   (undercloud) $ sudo tail -f /var/log/containers/ironic-inspector/ironic-inspector.log

   重要

   このプロセスを必ず完了させてください。ベアメタルノードの場合には、通常 15 分ほどかかります。

手順

1. source コマンドで stackrc アンダークラウド認証情報ファイルを読み込みます。

   $ source ~/stackrc

2. 新しい ~/overcloud-baremetal-deploy.yaml ファイルを作成し、プロビジョニングする各ロールのノード数を定義します。たとえば、コントローラーノード 3 つとコンピュートノード 3 つをプロビジョニングするには、以下の構文を使用します。

   - name: Controller
     count: 3
   - name: Compute
     count: 3

3. ~/overcloud-baremetal-deploy.yaml ファイルで、予測可能なノード配置、カスタムイメージ、カスタム NIC、またはノードに割り当てるその他の属性を定義します。たとえば、以下の例の構文を使用すると、3 つのコントローラーノードがノード node00、node01、および node02 に、3 つのコンピュートノードがノード node04、node05、および node06 に、それぞれプロビジョニングされます。

   - name: Controller
     count: 3
     instances:
     - hostname: overcloud-controller-0
       name: node00
     - hostname: overcloud-controller-1
       name: node01
     - hostname: overcloud-controller-2
       name: node02
   - name: Compute
     count: 3
     instances:
     - hostname: overcloud-novacompute-0
       name: node04
     - hostname: overcloud-novacompute-1
       name: node05
     - hostname: overcloud-novacompute-2
       name: node06

   デフォルトでは、プロビジョニングプロセスには overcloud-full イメージが使用されます。instances パラメーターで image 属性を使用して、カスタムイメージを定義することができます。

   - name: Controller
     count: 3
     instances:
     - hostname: overcloud-controller-0
       name: node00
       image:
         href: overcloud-custom

   ノードエントリーごとに手動でノードを定義するのを避けるために、defaults パラメーターでデフォルトのパラメーター値を上書きすることもできます。

   - name: Controller
     count: 3
     defaults:
       image:
         href: overcloud-custom
     instances:
     - hostname :overcloud-controller-0
       name: node00
     - hostname: overcloud-controller-1
       name: node01
     - hostname: overcloud-controller-2
       name: node02

   ノード定義ファイルで使用できるパラメーター、属性、および値についての詳しい情報は、「ベアメタルノードプロビジョニングの属性」を参照してください。

4. ~/overcloud-baremetal-deploy.yaml ファイルを指定し、--output オプションで出力ファイルを定義して、プロビジョニングコマンドを実行します。

   (undercloud) $ sudo openstack overcloud node provision \
   --stack stack \
   --output ~/overcloud-baremetal-deployed.yaml \
   ~/overcloud-baremetal-deploy.yaml

   プロビジョニングプロセスにより、--output オプションで指定する名前の heat 環境ファイルが生成されます。このファイルには、ノード定義が含まれます。オーバークラウドをデプロイする際に、このファイルをデプロイメントコマンドに追加します。

5. 別のターミナルでノードをモニタリングし、プロビジョニングが正常に行われていることを確認します。プロビジョニングプロセスでは、ノードの状態が available から active に変わります。

   (undercloud) $ watch openstack baremetal node list

   metalsmith ツールを使用して、割り当てや neutron ポートなどを含むノードの統合ビューを取得します。

   (undercloud) $ metalsmith list

   また、openstack baremetal allocation コマンドを使用して、ノードのホスト名への関連付けを確認し、プロビジョニングしたノードの IP アドレスを取得することもできます。

   (undercloud) $ openstack baremetal allocation list

手順

1. source コマンドで stackrc アンダークラウド認証情報ファイルを読み込みます。

   $ source ~/stackrc

2. ベアメタルノードのプロビジョニングに使用した ~/overcloud-baremetal-deploy.yaml ファイルを編集し、スケールアップするロールの count パラメーターを増やします。たとえば、オーバークラウドにコンピュートノードが 3 つある場合に、以下のスニペットを使用してコンピュートノード数を 10 に増やします。

   - name: Controller
     count: 3
   - name: Compute
     count: 10

   instances パラメーターを使用して、予測可能なノード配置を追加することもできます。利用可能なパラメーターおよび属性についての詳しい情報は、「ベアメタルノードプロビジョニングの属性」を参照してください。

3. ~/overcloud-baremetal-deploy.yaml ファイルを指定し、--output オプションで出力ファイルを定義して、プロビジョニングコマンドを実行します。

   (undercloud) $ sudo openstack overcloud node provision \
   --stack stack \
   --output ~/overcloud-baremetal-deployed.yaml \
   ~/overcloud-baremetal-deploy.yaml

4. openstack baremetal node list コマンドを使用して、プロビジョニングの進捗をモニタリングします。

5. デプロイメントに該当するその他の環境ファイルと共に、プロビジョニングコマンドによって生成される ~/overcloud-baremetal-deployed.yaml ファイルを指定して、オーバークラウドをデプロイします。

   (undercloud) $ openstack overcloud deploy \
     ...
     -e /usr/share/openstack-tripleo-heat-templates/environments/deployed-server-environment.yaml \
     -e ~/overcloud-baremetal-deployed.yaml \
     --deployed-server \
     --disable-validations \
     ...

手順

1. source コマンドで stackrc アンダークラウド認証情報ファイルを読み込みます。

   $ source ~/stackrc

2. ベアメタルノードのプロビジョニングに使用した ~/overcloud-baremetal-deploy.yaml ファイルを編集し、スケールダウンするロールの count パラメーターを減らします。また、スタックから削除するノードごとに以下の属性を定義する必要もあります。

   • ノードの名前
   • ノードに関連付けられたホスト名

   • provisioned: false 属性

     たとえば、スタックからノード overcloud-controller-1 を削除するには、~/overcloud-baremetal-deploy.yaml ファイルに以下のスニペットを追加します。

     - name: Controller
       count: 2
       instances:
       - hostname: overcloud-controller-0
         name: node00
       - hostname: overcloud-controller-1
         name: node01
         # Removed from cluster due to disk failure
         provisioned: false
       - hostname: overcloud-controller-2
         name: node02

3. ~/overcloud-baremetal-deploy.yaml ファイルを指定し、--output オプションで出力ファイルを定義して、プロビジョニングコマンドを実行します。

   (undercloud) $ sudo openstack overcloud node provision \
   --stack stack \
   --output ~/overcloud-baremetal-deployed.yaml \
   ~/overcloud-baremetal-deploy.yaml

4. デプロイメントに該当するその他の環境ファイルと共に、プロビジョニングコマンドによって生成される ~/overcloud-baremetal-deployed.yaml ファイルを指定して、オーバークラウドを再デプロイします。

   (undercloud) $ openstack overcloud deploy \
     ...
     -e /usr/share/openstack-tripleo-heat-templates/environments/deployed-server-environment.yaml \
     -e ~/overcloud-baremetal-deployed.yaml \
     --deployed-server \
     --disable-validations \
     ...

   オーバークラウドの再デプロイ後、provisioned: false 属性で定義したノードがスタックには存在しなくなります。ただし、これらのノードは provisioned の状態で稼働したままです。

   注記

   スタックから一時的にノードを削除する場合は、オーバークラウドを属性 provisioned: false でデプロイしてから属性 provisioned: true で再デプロイすることで、ノードをスタックに戻すことができます。

5. --baremetal-deployment オプションで ~/overcloud-baremetal-deploy.yaml ファイルを指定して、openstack overcloud node delete コマンドを実行します。

   (undercloud) $ sudo openstack overcloud node delete \
   --stack stack \
   --baremetal-deployment ~/overcloud-baremetal-deploy.yaml

   注記

   スタックから削除するノードを、openstack overcloud node delete コマンドのコマンド引数に含めないでください。

手順

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

   [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 鍵をコントローラーノードにコピーするには、以下の例に示すコマンドを実行します。

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

手順

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

   [root@controller-0 ~]# sudo subscription-manager register

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

   [root@controller-0 ~]# sudo subscription-manager list --available --all --matches="Red Hat OpenStack"

3. 上記のステップで特定したプール ID を使用して、Red Hat OpenStack Platform 16 のエンタイトルメントをアタッチします。

   [root@controller-0 ~]# sudo subscription-manager attach --pool=pool_id

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

   [root@controller-0 ~]# sudo subscription-manager repos --disable=*

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

   1. x86_64 システムの場合には、以下のコマンドを実行します。

      [root@controller-0 ~]# sudo subscription-manager repos --enable=rhel-8-for-x86_64-baseos-eus-rpms --enable=rhel-8-for-x86_64-appstream-eus-rpms --enable=rhel-8-for-x86_64-highavailability-eus-rpms --enable=ansible-2.8-for-rhel-8-x86_64-rpms --enable=openstack-16-for-rhel-8-x86_64-rpms --enable=rhceph-4-osd-for-rhel-8-x86_64-rpms --enable=rhceph-4-mon-for-rhel-8-x86_64-rpms --enable=rhceph-4-tools-for-rhel-8-x86_64-rpms --enable=advanced-virt-for-rhel-8-x86_64-rpms --enable=fast-datapath-for-rhel-8-x86_64-rpms

   2. POWER システムの場合には、以下のコマンドを実行します。

      [root@controller-0 ~]# sudo subscription-manager repos --enable=rhel-8-for-ppc64le-baseos-rpms --enable=rhel-8-for-ppc64le-appstream-rpms --enable=rhel-8-for-ppc64le-highavailability-rpms --enable=ansible-2.8-for-rhel-8-ppc64le-rpms --enable=openstack-16-for-rhel-8-ppc64le-rpms --enable=advanced-virt-for-rhel-8-ppc64le-rpms

   重要

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

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

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

手順

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

2. 各オーバークラウドノード上で以下のコマンドを実行します。

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

1. 割り当ての名前。形式は <node_hostname>-<network> です。ここで、<node_hostname> の値はノードの短縮ホスト名で、<network> はネットワークの小文字を使った名前です。たとえば、controller-0.example.com であれば controller-0-ctlplane となり、compute-0.example.com の場合は compute-0-ctlplane となります。

2. 以下のパラメーターパターンを使用する IP 割り当て

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

手順

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 ファイルを保存します。

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

   export OVERCLOUD_HOSTS="192.168.1.8 192.168.1.42"

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

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

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

手順

1. デプロイする追加のオーバークラウド用に、新たなディレクトリーを作成します。

   $ mkdir ~/overcloud-two

2. 新しいディレクトリーにおいて、追加のオーバークラウドの要件に固有な新しい環境ファイルを作成し、該当するすべての環境ファイルを既存のオーバークラウドからコピーします。

   $ cp network-data.yaml ~/overcloud-two/network-data.yaml
   $ cp network-environment.yaml ~/overcloud-two/network-environment.yaml

3. 新たなオーバークラウドの仕様に従って、環境ファイルを変更します。たとえば、既存のオーバークラウドの名前が overcloud-one で、network-data.yaml 環境ファイルで定義する VLAN を使用する場合、環境ファイルは以下のようになります。

   - name: InternalApi
     name_lower: internal_api_cloud_1
     service_net_map_replace: internal_api
     vip: true
     vlan: 20
     ip_subnet: '172.17.0.0/24'
     allocation_pools: [{'start': '172.17.0.4', 'end': '172.17.0.250'}]
     ipv6_subnet: 'fd00:fd00:fd00:2000::/64'
     ipv6_allocation_pools: [{'start': 'fd00:fd00:fd00:2000::10', 'end': 'fd00:fd00:fd00:2000:ffff:ffff:ffff:fffe'}]
     mtu: 1500
   - name: Storage
     ...

   新たなオーバークラウドは overcloud-two という名前で、異なる VLAN を使用します。~/overcloud-two/network-data.yaml 環境ファイルを編集し、各サブネット用の新たな VLAN ID を追加します。また、固有の name_lower 値を定義し、service_net_map_replace 属性を、置き換えるネットワークの名前に設定する必要があります。

   - name: InternalApi
     name_lower: internal_api_cloud_2
     service_net_map_replace: internal_api
     vip: true
     vlan: 21
     ip_subnet: '172.21.0.0/24'
     allocation_pools: [{'start': '172.21.0.4', 'end': '172.21.0.250'}]
     ipv6_subnet: 'fd00:fd00:fd00:2001::/64'
     ipv6_allocation_pools: [{'start': 'fd00:fd00:fd00:2001::10', 'end': 'fd00:fd00:fd00:2001:ffff:ffff:ffff:fffe'}]
     mtu: 1500
   - name: Storage
     ...

4. ~/overcloud-two/network-environment.yaml ファイルの以下のパラメーターを変更します。

   • overcloud-two に固有の外部ネットワークが設定されるように、ExternalNetValueSpecs パラメーターの {'provider:physical_network'} 属性に固有の値を入力し、'provider:network_type' 属性でネットワーク種別を定義します。
   • オーバークラウドの外部アクセスが可能になるように、ExternalInterfaceDefaultRoute パラメーターを外部ネットワークのゲートウェイの IP アドレスに設定します。

   • オーバークラウドが DNS サーバーにアクセスできるように、DnsServers パラメーターを DNS サーバーの IP アドレスに設定します。

     parameter_defaults:
       ...
       ExternalNetValueSpecs: {'provider:physical_network': 'external_2', 'provider:network_type': 'flat'}
       ExternalInterfaceDefaultRoute: 10.0.10.1
       DnsServers:
         - 10.0.10.2
       ...

5. openstack overcloud deploy コマンドを実行します。--templates オプションおよび --stack オプションを使用して、それぞれコアの heat テンプレートコレクションおよび新たな stack 名を指定します。また、~/overcloud-two ディレクトリーからの新規環境ファイルをすべて指定します。

   $ openstack overcloud deploy --templates \
       --stack overcloud-two \
       ...
       -n ~/overcloud-two/network-data.yaml \
       -e ~/overcloud-two/network-environment.yaml \
       -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \
       -e /usr/share/openstack-tripleo-heat-templates/environments/net-single-nic-with-vlans.yaml \
       ...

手順

1. stackrc ファイルを取得します。

   $ source ~/stackrc

2. デプロイメントステータスの確認コマンドを実行します。

   $ openstack overcloud status

   このコマンドの出力に、オーバークラウドのステータスが表示されます。

   +-----------+---------------------+---------------------+-------------------+
   | Plan Name |       Created       |       Updated       | Deployment Status |
   +-----------+---------------------+---------------------+-------------------+
   | overcloud | 2018-05-03 21:24:50 | 2018-05-03 21:27:59 |   DEPLOY_SUCCESS  |
   +-----------+---------------------+---------------------+-------------------+

   実際のオーバークラウドに別の名前が使用されている場合には、--plan 引数を使用してその名前のオーバークラウドを選択します。

   $ openstack overcloud status --plan my-deployment

手順

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

   $ source ~/overcloudrc

2. openstack flavor create コマンドを実行してフレーバーを作成します。以下のオプションを使用して、各フレーバーのハードウェア要件を指定します。

   --disk

   仮想マシンのボリュームのハードディスク容量を定義します。

   --ram

   仮想マシンに必要な RAM を定義します。

   --vcpus

   仮想マシンの仮想 CPU 数を定義します。

3. デフォルトのオーバークラウドフレーバー作成の例を以下に示します。

   $ 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

手順

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

   $ source ~/overcloudrc

2. デフォルトのテナントネットワークを作成します。

   (overcloud) $ openstack network create default

3. ネットワーク上にサブネットを作成します。

   (overcloud) $ openstack subnet create default --network default --gateway 172.20.1.1 --subnet-range 172.20.0.0/16

4. 作成したネットワークを確認します。

   (overcloud) $ openstack network list
   +-----------------------+-------------+--------------------------------------+
   | id                    | name        | subnets                              |
   +-----------------------+-------------+--------------------------------------+
   | 95fadaa1-5dda-4777... | default     | 7e060813-35c5-462c-a56a-1c6f8f4f332f |
   +-----------------------+-------------+--------------------------------------+

手順

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

   $ source ~/overcloudrc

2. public ネットワークを作成します。

   • ネイティブ VLAN 接続用に flat ネットワークを作成します。

     (overcloud) $ openstack network create public --external --provider-network-type flat --provider-physical-network datacentre

   • 非ネイティブ VLAN 接続用に vlan ネットワークを作成します。

     (overcloud) $ openstack network create public --external --provider-network-type vlan --provider-physical-network datacentre --provider-segment 201

     --provider-segment オプションを使用して、使用する VLAN を定義します。この例では、VLAN は 201 です。

3. Floating IP アドレスの割り当てプールを使用してサブネットを作成します。以下の例では、IP 範囲は 10.1.1.51 から 10.1.1.250 までです。

   (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

   この範囲が、外部ネットワークの他の IP アドレスと競合しないようにしてください。

手順

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

   $ source ~/overcloudrc

2. provider ネットワークを作成します。

   • ネイティブ VLAN 接続用に flat ネットワークを作成します。

     (overcloud) $ openstack network create provider --external --provider-network-type flat --provider-physical-network datacentre --share

   • 非ネイティブ VLAN 接続用に vlan ネットワークを作成します。

     (overcloud) $ openstack network create provider --external --provider-network-type vlan --provider-physical-network datacentre --provider-segment 201 --share

     --provider-segment オプションを使用して、使用する VLAN を定義します。この例では、VLAN は 201 です。

   例に示すこれらのコマンドにより、共有ネットワークが作成されます。テナントだけが新しいネットワークにアクセスするように、--share を指定する代わりにテナントを指定することも可能です。

   プロバイダーネットワークを外部としてマークした場合には、そのネットワークでポートを作成できるのはオペレーターのみとなります。

3. provider ネットワークにサブネットを追加して、DHCP サービスを提供します。

   (overcloud) $ openstack subnet create provider-subnet --network  provider --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

4. 他のネットワークがプロバイダーネットワークを通じてトラフィックをルーティングできるように、ルーターを作成します。

   (overcloud) $ openstack router create external

5. ルーターの外部ゲートウェイを provider ネットワークに設定します。

   (overcloud) $ openstack router set --external-gateway provider external

6. このルーターに他のネットワークを接続します。たとえば、以下のコマンドを実行してサブネット subnet1 をルーターに割り当てます。

   (overcloud) $ openstack router add subnet external subnet1

   このコマンドにより、subnet1 がルーティングテーブルに追加され、subnet1 を使用する仮想マシンからのトラフィックをプロバイダーネットワークにルーティングできるようになります。

手順

1. アンダークラウドからこのテストを実行する場合は、アンダークラウドのホストがオーバークラウドの内部 API ネットワークにアクセスできるようにします。たとえば、172.16.0.201/24 のアドレスを使用して内部 API ネットワーク (ID: 201) にアクセスするにはアンダークラウドホストに一時的な VLAN を追加します。

   $ 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

2. OpenStack Integration Test Suite を実行する前に、heat_stack_owner ロールがオーバークラウドに存在するようにします。

   $ source ~/overcloudrc
   (overcloud) $ openstack role list
   +----------------------------------+------------------+
   | ID                               | Name             |
   +----------------------------------+------------------+
   | 6226a517204846d1a26d15aae1af208f | swiftoperator    |
   | 7c7eb03955e545dd86bbfeb73692738b | heat_stack_owner |
   +----------------------------------+------------------+

3. このロールが存在しない場合は、作成します。

   (overcloud) $ openstack role create heat_stack_owner

4. 『OpenStack Integration Test Suite Guide』の説明に従って、統合テストを実施します。

5. 検証が完了したら、オーバークラウドの内部 API への一時接続を削除します。この例では、以下のコマンドを使用して、以前にアンダークラウドで作成した VLAN を削除します。

   $ source ~/stackrc
   (undercloud) $ sudo ovs-vsctl del-port vlan201

手順

1. 既存の OpenStack 環境において、実行中のサーバーのスナップショットを作成して新規イメージを作成し、そのイメージをダウンロードします。

   $ openstack server image create instance_name --name image_name
   $ openstack image save image_name --file exported_vm.qcow2

2. エクスポートしたイメージをアンダークラウドノードにコピーします。

   $ scp exported_vm.qcow2 stack@192.168.0.2:~/.

3. アンダークラウドに stack ユーザーとしてログインします。

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

   $ source ~/overcloudrc

5. エクスポートしたイメージをオーバークラウドにアップロードします。

   (overcloud) $ openstack image create imported_image --file exported_vm.qcow2 --disk-format qcow2 --container-format bare

6. 新規インスタンスを起動します。

   (overcloud) $ openstack server create  imported_instance --key-name default --flavor m1.demo --image imported_image --nic net-id=net_id

手順

1. ノードの動的インベントリーを表示するには、stackrc を読み込んだ後に tripleo-ansible-inventory コマンドを実行します。

   $ source ~/stackrc
   (undercloud) $ tripleo-ansible-inventory --list

   --list オプションを使用すると、全ホストの詳細が返されます。このコマンドにより、動的インベントリーが JSON 形式で出力されます。

   {"overcloud": {"children": ["controller", "compute"], "vars": {"ansible_ssh_user": "heat-admin"}}, "controller": ["192.168.24.2"], "undercloud": {"hosts": ["localhost"], "vars": {"overcloud_horizon_url": "http://192.168.24.4:80/dashboard", "overcloud_admin_password": "abcdefghijklm12345678", "ansible_connection": "local"}}, "compute": ["192.168.24.3"]}

2. お使いの環境で Ansible のプレイブックを実行するには、ansible コマンドを実行し、-i オプションを使用して動的インベントリーツールの完全パスを追加します。以下に例を示します。

   (undercloud) $ ansible [HOSTS] -i /bin/tripleo-ansible-inventory [OTHER OPTIONS]

   • [HOSTS] を使用するホストの種別に置き換えてください。

     • 全コントローラーノードの場合には controller
     • 全コンピュートノードの場合には compute
     • オーバークラウドの全子ノードの場合には overcloud(たとえば、コントローラー ノードおよび コンピュート ノードの場合)
     • アンダークラウドの場合には undercloud
     • 全ノードの場合には "*"

   • [OTHER OPTIONS] を追加の Ansible オプションに置き換えてください。

     • ホストキーの確認を省略するには、--ssh-extra-args='-o StrictHostKeyChecking=no' オプションを使用します。
     • Ansible の自動化を実行する SSH ユーザーを変更するには、-u [USER] オプションを使用します。オーバークラウドのデフォルトの SSH ユーザーは、動的インベントリーの ansible_ssh_user パラメーターで自動的に定義されます。-u オプションは、このパラメーターより優先されます。
     • 特定の Ansible モジュールを使用するには、-m [MODULE] オプションを使用します。デフォルトは command で Linux コマンドを実行します。
     • 選択したモジュールの引数を定義するには、-a [MODULE_ARGS] オプションを使用します。

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

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

2. openstack stack list コマンドの出力にオーバークラウドが表示されなくなったことを確認します。

   (undercloud) $ openstack stack list

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

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

手順

1. アンダークラウドの stack ユーザーに /var/lib/mistral ディレクトリーのファイルへのアクセス権限を付与するには、setfacl コマンドを使用します。

   $ sudo setfacl -R -m u:stack:rwx /var/lib/mistral

   このコマンドを実行しても、mistral ユーザーのディレクトリーへのアクセス権限は維持されます。

手順

1. less コマンドを使用して、config-download の作業ディレクトリー内のログを表示します。以下の例では、overcloud 作業ディレクトリーが使われています。

   $ less /var/lib/mistral/overcloud/ansible.log

手順

1. stackrc ファイルを取得します。

   $ source ~/stackrc

2. --stack-only オプションを指定してデプロイメントコマンドを実行します。オーバークラウドに必要なすべての環境ファイルを追加します。

   $ openstack overcloud deploy \
     --templates \
     -e environment-file1.yaml \
     -e environment-file2.yaml \
     ...
     --stack-only

3. プロビジョニングプロセスが完了するまで待ちます。

4. tripleo-admin ユーザーによるアンダークラウドからオーバークラウドへの SSH アクセスを有効にします。config-download プロセスでは、tripleo-admin ユーザーを使用して Ansible ベースの設定を実施します。

   $ openstack overcloud admin authorize

5. --config-download-only オプションを指定してデプロイメントコマンドを実行します。オーバークラウドに必要なすべての環境ファイルを追加します。

   $ openstack overcloud deploy \
     --templates \
     -e environment-file1.yaml \
     -e environment-file2.yaml \
     ...
     --config-download-only

6. 設定プロセスが完了するまで待ちます。

手順

1. Ansible Playbook のディレクトリーに移動します。

   $ cd /var/lib/mistral/overcloud/

2. ansible-playbook-command.sh コマンドを実行して、デプロイメントを再現します。

   $ ./ansible-playbook-command.sh

   このスクリプトには追加の Ansible 引数を渡すことができ、それらの引数は、そのまま ansible-playbook コマンドに渡されます。つまり、チェックモード (--check)、ホストの限定 (--limit)、変数のオーバーライド (-e) など、他の Ansible 機能を使用することができます。以下に例を示します。

   $ ./ansible-playbook-command.sh --limit Controller

3. 作業ディレクトリーには、オーバークラウドの設定を実行する deploy_steps_playbook.yaml という名前の Playbook が含まれています。この Playbook を表示するには、以下のコマンドを実行します。

   $ less deploy_steps_playbook.yaml

   Playbook は、作業ディレクトリーに含まれているさまざまなタスクファイルを使用します。タスクファイルには、OpenStack Platform の全ロールに共通するものと、特定の OpenStack Platform ロールおよびサーバー固有のものがあります。

4. 作業ディレクトリーには、オーバークラウドの roles_data ファイルで定義する各ロールに対応するサブディレクトリーも含まれます。以下に例を示します。

   $ ls Controller/

   各 OpenStack Platform ロールにディレクトリーには、そのロール種別の個々のサーバー用のサブディレクトリーも含まれます。これらのディレクトリーには、コンポーザブルロールのホスト名の形式を使用します。

   $ ls Controller/overcloud-controller-0

5. Ansible のタスクはタグ付けされます。タグの全一覧を確認するには、ansible-playbook で CLI の引数 --list-tags を使用します。

   $ ansible-playbook -i tripleo-ansible-inventory.yaml --list-tags deploy_steps_playbook.yaml

   次に、ansible-playbook-command.sh スクリプトで --tags、--skip-tags、--start-at-task のいずれかを使用して、タグ付けした設定を適用します。

   $ ./ansible-playbook-command.sh --tags overcloud

6. config-download を使用して Ceph を設定する際に、Ansible は config-download external_deploy_steps_tasks Playbook 内から ceph-ansible を実行します。config-download を手動で実行する場合、2 回目の Ansible の実行では ssh_args 引数は継承されません。この実行に Ansible 環境変数を渡すには、heat 環境ファイルを使用します。以下に例を示します。

   parameter_defaults:
     CephAnsibleEnvironmentVariables:
       ANSIBLE_HOST_KEY_CHECKING: 'False'
       ANSIBLE_PRIVATE_KEY_FILE: '/home/stack/.ssh/id_rsa'

手順

1. オーバークラウドに関する config-download の作業ディレクトリーに移動します。この例の作業ディレクトリーは、overcloud という名前のオーバークラウド用です。

   $ cd /var/lib/mistral/overcloud

2. git log コマンドを実行して、作業ディレクトリー内のコミットの一覧を表示します。ログの出力に日付が表示されるようにフォーマットを設定することもできます。

   $ git log --format=format:"%h%x09%cd%x09"
   a7e9063 Mon Oct 8 21:17:52 2018 +1000
   dfb9d12 Fri Oct 5 20:23:44 2018 +1000
   d0a910b Wed Oct 3 19:30:16 2018 +1000
   ...

   デフォルトでは、最新のコミットから順に表示されます。

3. 2 つのコミットのハッシュに対して git diff コマンドを実行し、デプロイメント間の違いをすべて表示します。

   $ git diff a7e9063 dfb9d12

手順

1. config-download ファイルを生成します。

   $ openstack overcloud config download \
     --name overcloud \
     --config-dir ~/config-download

   • --name は、Ansible ファイルのエクスポートに使用するオーバークラウドの名前です。
   • --config-dir は、config-download ファイルを保存する場所です。

2. config-download ファイルが含まれるディレクトリーに移動します。

   $ cd ~/config-download

3. 静的なインベントリーファイルを生成します。

   $ tripleo-ansible-inventory \
     --ansible_ssh_user heat-admin \
     --static-yaml-inventory inventory.yaml

手順

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

   $ source ~/stackrc

2. openstack tripleo validator list コマンドを実行します。

   • すべての検証を一覧表示するには、オプションを設定せずにコマンドを実行します。

     $ openstack tripleo validator list

   • グループの検証を一覧表示するには、--group オプションを指定してコマンドを実行します。

     $ openstack tripleo validator list --group prep

手順

1. stackrc ファイルを取得します。

   $ source ~/stackrc

2. openstack tripleo validator run コマンドを入力します。

   • 単一の検証を実行するには、--validation オプションで検証の名前を指定してコマンドを入力します。たとえば、アンダークラウドのメモリー要件を確認するには、--validation undercloud-ram を入力します。

     $ openstack tripleo validator run --validation undercloud-ram

   • グループのすべての検証を実行するには、--group オプションを指定してコマンドを入力します。

     $ openstack tripleo validator run --group prep

手順

1. 登録する新規ノードの詳細を記載した新しい JSON ファイル (newnodes.json) を作成します。

   {
     "nodes":[
       {
           "mac":[
               "dd:dd:dd:dd:dd:dd"
           ],
           "cpu":"4",
           "memory":"6144",
           "disk":"40",
           "arch":"x86_64",
           "pm_type":"ipmi",
           "pm_user":"admin",
           "pm_password":"p@55w0rd!",
           "pm_addr":"192.168.24.207"
       },
       {
           "mac":[
               "ee:ee:ee:ee:ee:ee"
           ],
           "cpu":"4",
           "memory":"6144",
           "disk":"40",
           "arch":"x86_64",
           "pm_type":"ipmi",
           "pm_user":"admin",
           "pm_password":"p@55w0rd!",
           "pm_addr":"192.168.24.208"
       }
     ]
   }

2. 以下のコマンドを実行して、新規ノードを登録します。

   $ source ~/stackrc
   (undercloud) $ openstack overcloud node import newnodes.json

3. 新規ノードを追加したら、各新規ノードごとに以下のコマンドを実行してイントロスペクションプロセスを起動します。

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

   このプロセスにより、ノードのハードウェアプロパティーの検出とベンチマークが実行されます。

4. ノードのイメージプロパティーを設定します。

   (undercloud) $ openstack overcloud node configure [NODE UUID]

手順

1. それぞれの新規ノードを希望するロールにタグ付けします。たとえば、ノードをコンピュートロールにタグ付けするには、以下のコマンドを実行します。

   (undercloud) $ openstack baremetal node set --property capabilities='profile:compute,boot_option:local' [NODE UUID]

2. オーバークラウドをスケーリングするには、ノード数が含まれる環境ファイルを編集してオーバークラウドを再デプロイする必要があります。たとえば、オーバークラウドをコンピュートノード 5 台にスケーリングするには、ComputeCount パラメーターを編集します。

   parameter_defaults:
     ...
     ComputeCount: 5
     ...

3. 更新したファイルを使用して、デプロイメントコマンドを再度実行します。以下の例では、このファイルは node-info.yaml という名前です。

   (undercloud) $ openstack overcloud deploy --templates -e /home/stack/templates/node-info.yaml [OTHER_OPTIONS]

   最初に作成したオーバークラウドからの環境ファイルおよびオプションをすべて追加するようにしてください。これには、コンピュート以外のノードに対する同様のスケジューリングパラメーターが含まれます。

4. デプロイメント操作が完了するまで待ちます。

手順

1. source コマンドでオーバークラウド設定を読み込みます。

   $ source ~/overcloudrc

2. オーバークラウド上で削除するノードの Compute サービスを無効にし、ノードで新規インスタンスがスケジューリングされないようにします。

   (overcloud) $ openstack compute service list
   (overcloud) $ openstack compute service set <hostname> nova-compute --disable

   ヒント

   --disable-reason オプションを使用して、サービスを無効にする理由についての簡単な説明を追加します。これは、Compute サービスを後で再デプロイする場合に役立ちます。

3. source コマンドでアンダークラウド設定を読み込みます。

   (overcloud) $ source ~/stackrc

4. オーバークラウドスタックの UUID を特定します。

   (undercloud) $ openstack stack list

5. 削除するノードの UUID またはホスト名を特定します。

   (undercloud) $ openstack server list

6. デプロイメントに該当するすべての環境ファイルを含め、--update-plan-only オプションを指定してオーバークラウドを再デプロイします。

   $ openstack overcloud deploy --update-plan-only \
     --templates  \
     -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \
     -e /home/stack/templates/network-environment.yaml \
     -e /home/stack/templates/storage-environment.yaml \
     -e /home/stack/templates/rhel-registration/environment-rhel-registration.yaml \
     [-e |...]

7. スタックからノードを削除します。

   $ openstack overcloud node delete --stack [STACK_UUID] --templates -e [ENVIRONMENT_FILE] [NODE1_UUID] [NODE2_UUID] [NODE3_UUID]

   [node] をノードの UUID またはホスト名に置き換えてください。

   重要

   UUID とホスト名を混在させて使用しないでください。UUID だけ、またはホスト名だけを使用します。

8. openstack overcloud node delete コマンドが完全に終了したことを確認します。

   (undercloud) $ openstack stack list

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

   重要

   同じホスト名を使用して Compute サービスを再デプロイする場合は、再デプロイするノードに既存のサービスレコードを使用する必要があります。その場合は、この手順の残りのステップを省略して、「同じホスト名を使用した Compute サービスの再デプロイ」の手順に進んでください。

9. ノードから Compute サービスを削除します。

   (undercloud) $ source ~/overcloudrc
   (overcloud) $ openstack compute service list
   (overcloud) $ openstack compute service delete <service-id>

10. ノードから Open vSwitch エージェントを削除します。

    (overcloud) $ openstack network agent list
    (overcloud) $ openstack network agent delete <openvswitch-agent-id>

11. 削除した Compute サービスを、Placement サービスのリソースプロバイダーから除外します。

    (overcloud) $ openstack resource provider list
    (overcloud) $ openstack resource provider delete <uuid>

12. ノード数が含まれる環境ファイルの ComputeCount パラメーターを減らします。このファイルは、通常 node-info.yaml という名前です。たとえば、ノードを 2 つ削除する場合、ノード数を 5 から 3 に減らします。

    parameter_defaults:
      ...
      ComputeCount: 3
      ...

    ノード数を減らすと、openstack overcloud deploy を実行しても director は新規ノードをプロビジョニングしません。

手順

1. 削除した Compute サービスを、Placement サービスのリソースプロバイダーから除外します。

   (undercloud) $ source ~/overcloudrc
   (overcloud) $ openstack resource provider list
   (overcloud) $ openstack resource provider delete <uuid>

2. Compute サービスのステータスを確認します。

   (overcloud) $ openstack compute service list --long
   ...
   | ID | Binary       | Host                  | Zone  | Status   | State | Updated At                 | Disabled Reason      |
   | 80 | nova-compute | compute-1.localdomain | nova  | disabled | up    | 2018-07-13T14:35:04.000000 | gets re-provisioned |
   ...

3. 再デプロイしたコンピュートノードのサービスの状態が up に変わったら、サービスを再度有効にします。

   (overcloud) $ openstack compute service set compute-1.localdomain nova-compute --enable

手順

1. ObjectStorageCount パラメーターを使用してオブジェクトストレージ数を増やします。このパラメーターは、通常ノード数を指定する環境ファイルの node-info.yaml に含まれています。

   parameter_defaults:
     ObjectStorageCount: 4

   ObjectStorageCount パラメーターで、環境内のオブジェクトストレージノードの数を定義します。今回の例では、オブジェクトストレージノードの数を 3 から 4 にスケーリングします。

2. 更新した ObjectStorageCount パラメーターを使用して、デプロイメントコマンドを実行します。

   $ source ~/stackrc
   (undercloud) $ openstack overcloud deploy --templates -e node-info.yaml ENVIRONMENT_FILES

3. デプロイメントコマンドの実行が完了すると、オーバークラウドには追加のオブジェクトストレージノードが含まれるようになります。

4. 新しいノードにデータを複製します。ノードを削除する前に (ここでは overcloud-objectstorage-1)、複製のパスが新規ノードで完了するのを待ちます。/var/log/swift/swift.log ファイルで複製パスの進捗を確認することができます。パスが完了すると、Object Storage サービスは以下の例のようなエントリーをログに残します。

   Mar 29 08:49:05 localhost object-server: Object replication complete.
   Mar 29 08:49:11 localhost container-server: Replication run OVER
   Mar 29 08:49:13 localhost account-server: Replication run OVER

5. リングから不要になったノードを削除するには、ObjectStorageCount パラメーターの数を減らして不要になったノードを削除します。この例では、ObjectStorageCount パラメーターを 3 に減らします。

   parameter_defaults:
     ObjectStorageCount: 3

6. 新規環境ファイル (remove-object-node.yaml) を作成します。このファイルでオブジェクトストレージノードを特定し、そのノードを削除します。以下の内容では overcloud-objectstorage-1 の削除を指定します。

   parameter_defaults:
     ObjectStorageRemovalPolicies:
       [{'resource_list': ['1']}]

7. デプロイメントコマンドに node-info.yaml ファイルと remove-object-node.yaml ファイルの両方を含めます。

   (undercloud) $ openstack overcloud deploy --templates -e node-info.yaml ENVIRONMENT_FILES -e remove-object-node.yaml

手順

1. アンダークラウドで、overcloud スタックの現在の状態をチェックします。

   $ source stackrc
   (undercloud) $ openstack stack list --nested

   overcloud スタックと後続の子スタックは、CREATE_COMPLETE または UPDATE_COMPLETE のステータスである必要があります。

2. データベースクライアントツールをインストールします。

   (undercloud) $ sudo dnf -y install mariadb

3. root ユーザーのデータベースへのアクセス権限を設定します。

   (undercloud) $ sudo cp /var/lib/config-data/puppet-generated/mysql/root/.my.cnf /root/.

4. アンダークラウドデータベースのバックアップを実行します。

   (undercloud) $ mkdir /home/stack/backup
   (undercloud) $ sudo mysqldump --all-databases --quick --single-transaction | gzip > /home/stack/backup/dump_db_undercloud.sql.gz

5. アンダークラウドに、新規ノードプロビジョニング時のイメージのキャッシュと変換に対応できる 10 GB の空きストレージ領域があることを確認します。

   (undercloud) $ df -h

6. コントローラーノードで実行中の Pacemaker の状態をチェックします。たとえば、実行中のコントローラーノードの IP アドレスが 192.168.0.47 の場合には、以下のコマンドで Pacemaker のステータスを表示します。

   (undercloud) $ ssh heat-admin@192.168.0.47 'sudo pcs status'

   この出力には、既存のノードで動作中のサービスおよび障害の発生しているノードで停止しているサービスがすべて表示されます。

7. オーバークラウド MariaDB クラスターの各ノードで以下のパラメーターをチェックします。

   • wsrep_local_state_comment: Synced

   • wsrep_cluster_size: 2

     実行中のコントローラーノードで以下のコマンドを使用して、パラメーターをチェックします。以下の例では、コントローラーノードの IP アドレスは、それぞれ 192.168.0.47 と 192.168.0.46 です。

     (undercloud) $ for i in 192.168.24.6 192.168.24.7 ; do echo "*** $i ***" ; ssh heat-admin@$i "sudo podman exec \$(sudo podman ps --filter name=galera-bundle -q) mysql -e \"SHOW STATUS LIKE 'wsrep_local_state_comment'; SHOW STATUS LIKE 'wsrep_cluster_size';\""; done

8. RabbitMQ のステータスをチェックします。たとえば、実行中のコントローラーノードの IP アドレスが 192.168.0.47 の場合には、以下のコマンドで RabbitMQ のステータスを表示します。

   (undercloud) $ ssh heat-admin@192.168.0.47 "sudo podman exec \$(sudo podman ps -f name=rabbitmq-bundle -q) rabbitmqctl cluster_status"

   running_nodes キーには、障害が発生しているノードは表示されず、稼働中のノード 2 台のみが表示されるはずです。

9. フェンシングが有効な場合は、無効にします。たとえば、実行中のコントローラーノードの IP アドレスが 192.168.0.47 の場合には、以下のコマンドを実行してフェンシングのステータスを確認します。

   (undercloud) $ ssh heat-admin@192.168.0.47 "sudo pcs property show stonith-enabled"

   フェンシングを無効にするには、以下のコマンドを実行します。

   (undercloud) $ ssh heat-admin@192.168.0.47 "sudo pcs property set stonith-enabled=false"

10. director ノードで Compute サービスがアクティブであることを確認します。

    (undercloud) $ openstack hypervisor list

    出力では、メンテナンスモードに入っていないすべてのノードが up のステータスで表示されるはずです。

11. アンダークラウドコンテナーがすべて実行中であることを確認します。

    (undercloud) $ sudo podman ps

手順

1. 置き換えるコントローラーノードに接続して、root ユーザーになります。

   # ssh heat-admin@192.168.0.47
   # sudo su -

   注記

   コントローラーノードにアクセスすることができない場合、ステップ 1 と 2 をスキップして、稼働している任意のコントローラーノードでステップ 3 から手順を続行してください。

2. monitor を停止します。

   # systemctl stop ceph-mon@<monitor_hostname>

   以下に例を示します。

   # systemctl stop ceph-mon@overcloud-controller-1

3. 置き換えるコントローラーノードとの接続を終了します。

4. 既存のコントローラーノードのいずれかに接続します。

   # ssh heat-admin@192.168.0.46
   # sudo su -

5. クラスターから monitor を削除します。

   # sudo podman exec -it ceph-mon-controller-0 ceph mon remove overcloud-controller-1

6. すべてのコントローラーノード上で、/etc/ceph/ceph.conf から v1 および v2 monitor のエントリーを削除します。たとえば、controller-1 を削除する場合には、controller-1 の IP アドレスとホスト名を削除します。

   編集前:

   mon host = [v2:172.18.0.21:3300,v1:172.18.0.21:6789],[v2:172.18.0.22:3300,v1:172.18.0.22:6789],[v2:172.18.0.24:3300,v1:172.18.0.24:6789]
   mon initial members = overcloud-controller-2,overcloud-controller-1,overcloud-controller-0

   変更後:

   mon host = [v2:172.18.0.21:3300,v1:172.18.0.21:6789],[v2:172.18.0.24:3300,v1:172.18.0.24:6789]
   mon initial members = overcloud-controller-2,overcloud-controller-0

   注記

   置き換え用のコントローラーノードを追加すると、director によって該当するオーバークラウドノード上の ceph.conf ファイルが更新されます。通常は、director がこの設定ファイルを管理するだけで、手動でファイルを編集する必要はありません。ただし、新規ノードが追加する前に他のノードが再起動してしまった場合に一貫性を保つために、手動でファイルを編集することができます。

7. (オプション) monitor データをアーカイブし、アーカイブを別のサーバーに保存します。

   # mv /var/lib/ceph/mon/<cluster>-<daemon_id> /var/lib/ceph/mon/removed-<cluster>-<daemon_id>

手順

1. コントローラーノードの IP アドレス一覧を表示するには、以下のコマンドを実行します。

   (undercloud) $ openstack server list -c Name -c Networks
   +------------------------+-----------------------+
   | Name                   | Networks              |
   +------------------------+-----------------------+
   | overcloud-compute-0    | ctlplane=192.168.0.44 |
   | overcloud-controller-0 | ctlplane=192.168.0.47 |
   | overcloud-controller-1 | ctlplane=192.168.0.45 |
   | overcloud-controller-2 | ctlplane=192.168.0.46 |
   +------------------------+-----------------------+

2. まだ古いノードにアクセスできる場合は、残りのノードのいずれかにログインし、古いノード上の Pacemaker を停止します。以下の例では、overcloud-controller-1 上の Pacemaker を停止しています。

   (undercloud) $ ssh heat-admin@192.168.0.47 "sudo pcs status | grep -w Online | grep -w overcloud-controller-1"
   (undercloud) $ ssh heat-admin@192.168.0.47 "sudo pcs cluster stop overcloud-controller-1"

   注記

   古いノードが物理的に利用できない、または停止している場合には、そのノードでは Pacemaker はすでに停止しているので、この操作を実施する必要はありません。

3. 古いノード上の Pacemaker を停止したら、Pacemaker クラスターから古いノードを削除します。以下に示すコマンドの例では、overcloud-controller-0 にログインし、overcloud-controller-1 を削除しています。

   (undercloud) $ ssh heat-admin@192.168.0.47 "sudo pcs cluster node remove overcloud-controller-1"

   置き換えるノードにアクセスすることができない場合には (ハードウェア障害などの理由により)、pcs コマンドを実行する際にさらに --skip-offline および --force オプションを指定して、ノードをクラスターから強制的に削除します。

   (undercloud) $ ssh heat-admin@192.168.0.47 "sudo pcs cluster node remove overcloud-controller-1 --skip-offline --force"

4. Pacemaker クラスターから古いノードを削除したら、Pacemaker の既知のホスト一覧からノードを削除します。

   (undercloud) $ ssh heat-admin@192.168.0.47 "sudo pcs host deauth overcloud-controller-1"

   ノードにアクセス可能かどうかにかかわらず、このコマンドを実行することができます。

5. オーバークラウドデータベースは、置き換え手順の実行中に稼働し続ける必要があります。この手順の実行中に Pacemaker が Galera を停止しないようにするには、実行中のコントローラーノードを選択して、そのコントローラーノードの IP アドレスを使用して、アンダークラウドで以下のコマンドを実行します。

   (undercloud) $ ssh heat-admin@192.168.0.47 "sudo pcs resource unmanage galera-bundle"

手順

1. stackrc ファイルを取得します。

   $ source ~/stackrc

2. overcloud-controller-1 ノードのインデックスを特定します。

   $ INSTANCE=$(openstack server list --name overcloud-controller-1 -f value -c ID)

3. インスタンスに関連付けられたベアメタルノードを特定します。

   $ NODE=$(openstack baremetal node list -f csv --quote minimal | grep $INSTANCE | cut -f1 -d,)

4. ノードをメンテナンスモードに切り替えます。

   $ openstack baremetal node maintenance set $NODE

5. コントローラーノードが仮想ノードの場合には、コントローラーホストで以下のコマンドを実行し、障害の発生した仮想ディスクをバックアップからの仮想ディスクに置き換えます。

   $ cp <VIRTUAL_DISK_BACKUP> /var/lib/libvirt/images/<VIRTUAL_DISK>

   <VIRTUAL_DISK_BACKUP> を障害の発生した仮想ディスクのバックアップへのパスに、<VIRTUAL_DISK> を置き換える仮想ディスクの名前にそれぞれ置き換えます。

   削除するノードのバックアップがない場合には、新しい仮想ノードを使用する必要があります。

   コントローラーノードがベアメタルノードの場合には、以下の手順を実施してディスクを新しいベアメタルディスクに置き換えます。

   1. 物理ハードドライブまたはソリッドステートドライブを置き換えます。
   2. 障害が発生したノードと同じ設定のノードを準備します。

6. 関連付けられていないノードの一覧を表示し、新規ノードの ID を特定します。

   $ openstack baremetal node list --unassociated

7. 新規ノードを control プロファイルにタグ付けします。

   (undercloud) $ openstack baremetal node set --property capabilities='profile:control,boot_option:local' 75b25e9a-948d-424a-9b3b-f0ef70a6eacf

手順

1. 削除するノードの UUID を把握し、それを NODEID 変数に保管します。NODE_NAME は、削除するノードの名前に置き換えてください。

   $ NODEID=$(openstack server list -f value -c ID --name NODE_NAME)

2. Heat リソース ID を特定するには、以下のコマンドを入力します。

   $ openstack stack resource show overcloud ControllerServers -f json -c attributes | jq --arg NODEID "$NODEID" -c '.attributes.value | keys[] as $k | if .[$k] == $NODEID then "Node index \($k) for \(.[$k])" else empty end'

3. 以下の内容で環境ファイル ~/templates/remove-controller.yaml を作成し、削除するコントローラーノードのノードインデックスを含めます。

   parameters:
     ControllerRemovalPolicies:
       [{'resource_list': ['NODE_INDEX']}]

4. ご自分の環境に該当するその他の環境ファイルと共に remove-controller.yaml 環境ファイルを指定して、オーバークラウドデプロイメントコマンドを入力します。

   (undercloud) $ openstack overcloud deploy --templates \
       -e /home/stack/templates/remove-controller.yaml \
       -e /home/stack/templates/node-info.yaml \
       [OTHER OPTIONS]

   注記

   -e ~/templates/remove-controller.yaml は、デプロイメントコマンドのこのインスタンスに対してのみ指定します。これ以降のデプロイメント操作からは、この環境ファイルを削除してください。

5. director は古いノードを削除して、新しいノードを作成してから、オーバークラウドスタックを更新します。以下のコマンドを使用すると、オーバークラウドスタックのステータスをチェックすることができます。

   (undercloud) $ openstack stack list --nested

6. デプロイメントコマンドの実行が完了すると、director の出力には古いノードが新規ノードに置き換えられたことが表示されます。

   (undercloud) $ openstack server list -c Name -c Networks
   +------------------------+-----------------------+
   | Name                   | Networks              |
   +------------------------+-----------------------+
   | overcloud-compute-0    | ctlplane=192.168.0.44 |
   | overcloud-controller-0 | ctlplane=192.168.0.47 |
   | overcloud-controller-2 | ctlplane=192.168.0.46 |
   | overcloud-controller-3 | ctlplane=192.168.0.48 |
   +------------------------+-----------------------+

   これで、新規ノードが稼動状態のコントロールプレーンサービスをホストするようになります。

手順

1. コントローラーノードにログインします。

2. Galera クラスターの Pacemaker 管理を有効にし、新規ノード上で Galera を起動します。

   [heat-admin@overcloud-controller-0 ~]$ sudo pcs resource refresh galera-bundle
   [heat-admin@overcloud-controller-0 ~]$ sudo pcs resource manage galera-bundle

3. 最終のステータスチェックを実行して、サービスが正しく実行されていることを確認します。

   [heat-admin@overcloud-controller-0 ~]$ sudo pcs status

   注記

   エラーが発生したサービスがある場合には、pcs resource refresh コマンドを使用して問題を解決し、そのサービスを再起動します。

4. director を終了します。

   [heat-admin@overcloud-controller-0 ~]$ exit

5. オーバークラウドと対話できるようにするために、source コマンドで overcloudrc ファイルを読み込みます。

   $ source ~/overcloudrc

6. オーバークラウド環境のネットワークエージェントを確認します。

   (overcloud) $ openstack network agent list

7. 古いノードにエージェントが表示される場合には、そのエージェントを削除します。

   (overcloud) $ for AGENT in $(openstack network agent list --host overcloud-controller-1.localdomain -c ID -f value) ; do openstack network agent delete $AGENT ; done

8. 必要に応じて、新規ノード上の L3 エージェントホストにルーターを追加します。以下のコマンド例では、UUID に 2d1c1dc1-d9d4-4fa9-b2c8-f29cd1a649d4 を使用して L3 エージェントに r1 という名称のルーターを追加しています。

   (overcloud) $ openstack network agent add router --l3 2d1c1dc1-d9d4-4fa9-b2c8-f29cd1a649d4 r1

9. 削除されたノードの Compute サービスはオーバークラウドにまだ存在しているので、それを削除する必要があります。まず、削除したノードの Compute サービスを確認します。

   [stack@director ~]$ source ~/overcloudrc
   (overcloud) $ openstack compute service list --host overcloud-controller-1.localdomain

10. 削除したノードのコンピュートサービスを削除します。

    (overcloud) $ for SERVICE in $(openstack compute service list --host overcloud-controller-1.localdomain -c ID -f value ) ; do openstack compute service delete $SERVICE ; done

手順

1. アンダークラウドに stack ユーザーとしてログインします。

2. アンダークラウドをリブートします。

   $ sudo reboot

3. ノードがブートするまで待ちます。

手順

1. リブートするノードにログインします。

2. オプション: ノードが Pacemaker リソースを使用している場合は、クラスターを停止します。

   [heat-admin@overcloud-controller-0 ~]$ sudo pcs cluster stop

3. ノードをリブートします。

   [heat-admin@overcloud-controller-0 ~]$ sudo reboot

4. ノードがブートするまで待ちます。

5. サービスを確認します。以下に例を示します。

   1. ノードが Pacemaker サービスを使用している場合には、ノードがクラスターに再度加わったかどうかを確認します。

      [heat-admin@overcloud-controller-0 ~]$ sudo pcs status

   2. ノードが Systemd サービスを使用している場合には、すべてのサービスが有効化されていることを確認します。

      [heat-admin@overcloud-controller-0 ~]$ sudo systemctl status

   3. ノードがコンテナー化されたサービスを使用している場合には、ノード上の全コンテナーがアクティブであることを確認します。

      [heat-admin@overcloud-controller-0 ~]$ sudo podman ps

手順

1. Ceph MON ノードにログインします。

2. ノードをリブートします。

   $ sudo reboot

3. ノードがブートして MON クラスターに再度加わるまで待ちます。

手順

1. Ceph MON またはコントローラーノードにログインして、Ceph Storage Cluster のリバランスを一時的に無効にします。

   $ sudo podman exec -it ceph-mon-controller-0 ceph osd set noout
   $ sudo podman exec -it ceph-mon-controller-0 ceph osd set norebalance

2. リブートする最初の Ceph Storage ノードを選択し、そのノードにログインします。

3. ノードをリブートします。

   $ sudo reboot

4. ノードがブートするまで待ちます。

5. ノードにログインして、クラスターのステータスを確認します。

   $ sudo podman exec -it ceph-mon-controller-0 ceph status

   pgmap により、すべての pgs が正常な状態 (active+clean) として報告されることを確認します。

6. ノードからログアウトして、次のノードをリブートし、ステータスを確認します。全 Ceph Storage ノードがリブートされるまで、このプロセスを繰り返します。

7. 完了したら、Ceph MON またはコントローラーノードにログインして、クラスターのリバランスを再度有効にします。

   $ sudo podman exec -it ceph-mon-controller-0 ceph osd unset noout
   $ sudo podman exec -it ceph-mon-controller-0 ceph osd unset norebalance

8. 最終のステータスチェックを実行して、クラスターが HEALTH_OK を報告していることを確認します。

   $ sudo podman exec -it ceph-mon-controller-0 ceph status

手順

1. アンダークラウドに stack ユーザーとしてログインします。

2. 全コンピュートノードとその UUID を一覧表示します。

   $ source ~/stackrc
   (undercloud) $ openstack server list --name compute

   リブートするコンピュートノードの UUID を特定します。

3. アンダークラウドから、コンピュートノードを選択します。そのノードを無効にします。

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

4. コンピュートノード上の全インスタンスを一覧表示します。

   (overcloud) $ openstack server list --host [hostname] --all-projects

5. インスタンスを移行しない場合は、このステップ に進みます。

6. インスタンスを別のコンピュートノードに移行する場合には、以下のコマンドのいずれかを使用します。

   • インスタンスを別のホストに移行する。

     (overcloud) $ openstack server migrate [instance-id] --live [target-host]--wait

   • nova-scheduler により対象のホストが自動的に選択されるようにする。

     (overcloud) $ nova live-migration [instance-id]

   • 一度にすべてのインスタンスのライブマイグレーションを行う。

     $ nova host-evacuate-live [hostname]

     注記

     nova コマンドで非推奨の警告が表示される可能性がありますが、無視して問題ありません。

7. 移行が完了するまで待ちます。

8. 移行が正常に完了したことを確認します。

   (overcloud) $ openstack server list --host [hostname] --all-projects

9. 選択したコンピュートノードのインスタンスがなくなるまで、移行を続けます。

10. コンピュートノードにログインして、ノードをリブートします。

    [heat-admin@overcloud-compute-0 ~]$ sudo reboot

11. ノードがブートするまで待ちます。

12. コンピュートノードを再度有効にします。

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

13. コンピュートノードが有効であることを確認します。

    (overcloud) $ openstack compute service list

手順

1. すべての署名済み証明書の記録は、/etc/pki/CA/index.txt ファイルに含まれます。このファイルが存在しているかどうかを確認してください。存在していない場合には、空のファイルを作成します。

   $ sudo touch /etc/pki/CA/index.txt

2. /etc/pki/CA/serial ファイルは、次に署名する証明書に使用する次のシリアル番号を特定します。このファイルが存在しているかどうかを確認してください。ファイルが存在しない場合には、新規ファイルを作成して新しい開始値を指定します。

   $ echo '1000' | sudo tee /etc/pki/CA/serial

手順

1. 鍵と証明書のペアを生成して、認証局として機能するようにします。

1. openssl req コマンドは、認証局に関する特定の情報を要求します。要求されたら、それらの情報を入力してください。

手順

1. 認証局をクライアントシステムにコピーします。

   $ sudo cp ca.crt.pem /etc/pki/ca-trust/source/anchors/

2. 各クライアントに認証局ファイルをコピーしたら、それぞれのクライアントで以下のコマンドを実行し、証明書を認証局のトラストバンドルに追加します。

   $ sudo update-ca-trust extract

手順

1. 以下のコマンドを実行し、SSL/TLS 鍵 (server.key.pem) を生成します。

   $ openssl genrsa -out server.key.pem 2048

手順

1. デフォルトの OpenSSL 設定ファイルをコピーします。

   $ cp /etc/pki/tls/openssl.cnf .

2. 新しい openssl.cnf ファイルを編集して、director に使用する SSL パラメーターを設定します。変更するパラメーターの種別には以下のような例が含まれます。

   [req]
   distinguished_name = req_distinguished_name
   req_extensions = v3_req
   
   [req_distinguished_name]
   countryName = Country Name (2 letter code)
   countryName_default = AU
   stateOrProvinceName = State or Province Name (full name)
   stateOrProvinceName_default = Queensland
   localityName = Locality Name (eg, city)
   localityName_default = Brisbane
   organizationalUnitName = Organizational Unit Name (eg, section)
   organizationalUnitName_default = Red Hat
   commonName = Common Name
   commonName_default = 192.168.0.1
   commonName_max = 64
   
   [ v3_req ]
   # Extensions to add to a certificate request
   basicConstraints = CA:FALSE
   keyUsage = nonRepudiation, digitalSignature, keyEncipherment
   subjectAltName = @alt_names
   
   [alt_names]
   IP.1 = 192.168.0.1
   DNS.1 = instack.localdomain
   DNS.2 = vip.localdomain
   DNS.3 = 192.168.0.1

   commonName_default を、以下のエントリーのいずれかに設定します。

   • IP アドレスを使用して SSL/TLS 経由で director にアクセスする場合には、undercloud.conf ファイルの undercloud_public_host パラメーターを使用します。

   • 完全修飾ドメイン名を使用して SSL/TLS 経由で director にアクセスする場合には、ドメイン名を使用します。

     v3_req セクションに subjectAltName = @alt_names を追加します。

     alt_names セクションを編集して、以下のエントリーを追加します。

   • IP: SSL 経由で director にアクセスするためにクライアントが使用する IP アドレス一覧
   • DNS: SSL 経由で director にアクセスするためにクライアントが使用するドメイン名一覧。alt_names セクションの最後に DNS エントリーとしてパブリック API の IP アドレスも追加します。
   注記

   openssl.cnf に関する詳しい情報については、man openssl.cnf コマンドを実行してください。

3. 以下のコマンドを実行し、証明書署名要求 (server.csr.pem) を生成します。

   $ openssl req -config openssl.cnf -key server.key.pem -new -out server.csr.pem

   -key オプションを使用して、OpenStack SSL/TLS 鍵を指定するようにしてください。

手順

1. 以下のコマンドを実行し、アンダークラウドまたはオーバークラウドの証明書を作成します。

   $ sudo openssl ca -config openssl.cnf -extensions v3_req -days 3650 -in server.csr.pem -out server.crt.pem -cert ca.crt.pem -keyfile ca.key.pem

   コマンドは、以下のオプションを使用します。

   -config

   カスタム設定ファイルを使用します (ここでは、v3 拡張機能を指定した openssl.cnf ファイル)。

   -extensions v3_req

   v3 拡張機能を有効にします。

   -days

   証明書の有効期限が切れるまでの日数を定義します。

   -in

   証明書署名要求

   -out

   作成される署名済み証明書

   -cert

   認証局ファイル

   -keyfile

   認証局の秘密鍵

手順

1. 以下のコマンドを実行して、証明書と鍵を統合します。

   $ cat server.crt.pem server.key.pem > undercloud.pem

   このコマンドにより、undercloud.pem ファイルが作成されます。

2. undercloud.pem ファイルを /etc/pki ディレクトリー内の場所にコピーし、HAProxy が読み取ることができるように必要な SELinux コンテキストを設定します。

   $ sudo mkdir /etc/pki/undercloud-certs
   $ sudo cp ~/undercloud.pem /etc/pki/undercloud-certs/.
   $ sudo semanage fcontext -a -t etc_t "/etc/pki/undercloud-certs(/.*)?"
   $ sudo restorecon -R /etc/pki/undercloud-certs

3. undercloud.conf ファイルの undercloud_service_certificate オプションに undercloud.pem ファイルの場所を追加します。

   undercloud_service_certificate = /etc/pki/undercloud-certs/undercloud.pem

4. アンダークラウド内の別のサービスが認証局にアクセスできるように、証明書に署名した認証局をアンダークラウドの信頼済み認証局の一覧に追加します。

   $ sudo cp ca.crt.pem /etc/pki/ca-trust/source/anchors/
   $ sudo update-ca-trust extract

1. undercloud.conf ファイルで、ベアメタルの自動検出を有効にします。

   enable_node_discovery = True
   discovery_default_driver = ipmi

   • enable_node_discovery: 有効にすると、PXE を使用して introspection ramdisk をブートするすべてのノードが、自動的に Bare Metal サービス (ironic) に登録されます。
   • discovery_default_driver: 検出されたノードに使用するドライバーを設定します。例: ipmi

2. IPMI の認証情報を ironic に追加します。

   1. IPMI の認証情報を ipmi-credentials.json という名前のファイルに追加します。この例の SampleUsername、RedactedSecurePassword、および bmc_address の値を、実際の環境に応じて置き換えてください。

      [
          {
              "description": "Set default IPMI credentials",
              "conditions": [
                  {"op": "eq", "field": "data://auto_discovered", "value": true}
              ],
              "actions": [
                  {"action": "set-attribute", "path": "driver_info/ipmi_username",
                   "value": "SampleUsername"},
                  {"action": "set-attribute", "path": "driver_info/ipmi_password",
                   "value": "RedactedSecurePassword"},
                  {"action": "set-attribute", "path": "driver_info/ipmi_address",
                   "value": "{data[inventory][bmc_address]}"}
              ]
          }
      ]

3. IPMI の認証情報ファイルを ironic にインポートします。

   $ openstack baremetal introspection rule import ipmi-credentials.json

1. 必要なノードの電源をオンにします。

2. openstack baremetal node list コマンドを実行します。新しいノードが enroll の状態でリストに表示されるはずです。

   $ openstack baremetal node list
   +--------------------------------------+------+---------------+-------------+--------------------+-------------+
   | UUID                                 | Name | Instance UUID | Power State | Provisioning State | Maintenance |
   +--------------------------------------+------+---------------+-------------+--------------------+-------------+
   | c6e63aec-e5ba-4d63-8d37-bd57628258e8 | None | None          | power off   | enroll             | False       |
   | 0362b7b2-5b9c-4113-92e1-0b34a2535d9b | None | None          | power off   | enroll             | False       |
   +--------------------------------------+------+---------------+-------------+--------------------+-------------+

3. 各ノードにリソースクラスを設定します。

   $ for NODE in `openstack baremetal node list -c UUID -f value` ; do openstack baremetal node set $NODE --resource-class baremetal ; done

4. 各ノードにカーネルと ramdisk を設定します。

   $ for NODE in `openstack baremetal node list -c UUID -f value` ; do openstack baremetal node manage $NODE ; done
   $ openstack overcloud node configure --all-manageable

5. 全ノードを利用可能な状態に設定します。

   $ for NODE in `openstack baremetal node list -c UUID -f value` ; do openstack baremetal node provide $NODE ; done

1. 以下の内容で、dell-drac-rules.json という名前のファイルを作成します。

   [
       {
           "description": "Set default IPMI credentials",
           "conditions": [
               {"op": "eq", "field": "data://auto_discovered", "value": true},
               {"op": "ne", "field": "data://inventory.system_vendor.manufacturer",
                "value": "Dell Inc."}
           ],
           "actions": [
               {"action": "set-attribute", "path": "driver_info/ipmi_username",
                "value": "SampleUsername"},
               {"action": "set-attribute", "path": "driver_info/ipmi_password",
                "value": "RedactedSecurePassword"},
               {"action": "set-attribute", "path": "driver_info/ipmi_address",
                "value": "{data[inventory][bmc_address]}"}
           ]
       },
       {
           "description": "Set the vendor driver for Dell hardware",
           "conditions": [
               {"op": "eq", "field": "data://auto_discovered", "value": true},
               {"op": "eq", "field": "data://inventory.system_vendor.manufacturer",
                "value": "Dell Inc."}
           ],
           "actions": [
               {"action": "set-attribute", "path": "driver", "value": "idrac"},
               {"action": "set-attribute", "path": "driver_info/drac_username",
                "value": "SampleUsername"},
               {"action": "set-attribute", "path": "driver_info/drac_password",
                "value": "RedactedSecurePassword"},
               {"action": "set-attribute", "path": "driver_info/drac_address",
                "value": "{data[inventory][bmc_address]}"}
           ]
       }
   ]

   この例のユーザー名およびパスワードの値を、実際の環境に応じて置き換えてください。

2. ルールを ironic にインポートします。

   $ openstack baremetal introspection rule import dell-drac-rules.json