手順

1. ceph-mon サービスを実行しているノードにログインします。このノードは、通常コントローラーノードまたはスタンドアロンの Ceph Monitor ノードです。

2. Ceph クラスターのステータスを表示します。

   $ NODE=$(openstack server list --name controller-0 -f value -c Networks | cut -d= -f2); ssh heat-admin@$NODE "sudo ceph -s"

3. クラスターの健全性ステータスが HEALTH_OK であり、すべてのオブジェクトストレージデーモン (OSD) がアクティブであることを確認します。

手順

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

2. データベースのバックアップを作成します。

   [root@director ~]# mysqldump --opt --all-databases > /root/undercloud-all-databases.sql

3. backup ディレクトリーを作成して、そのディレクトリーを所有するユーザーを stack ユーザーに変更します。

   [root@director ~]# mkdir /backup
   [root@director ~]# chown stack: /backup

   このディレクトリーを使用して、アンダークラウドのデータベースおよびファイルシステムを含むアーカイブを保存します。

4. バックアップ ディレクトリーに移動します。

   [root@director ~]# cd /backup

5. データベースのバックアップと設定ファイルをアーカイブします。

   [root@director ~]# tar --xattrs --xattrs-include='*.*' --ignore-failed-read -cf \
       undercloud-backup-$(date +%F).tar \
       /root/undercloud-all-databases.sql \
       /etc \
       /var/log \
       /var/lib/glance \
       /var/lib/certmonger \
       /var/lib/docker \
       /var/lib/registry \
       /srv/node \
       /root \
       /home/stack

   • --ignore-failed-read オプションを指定すると、アンダークラウドに適用されないディレクトリーはスキップされます。
   • --xattrs および --xattrs-include='.' オプションには、Object Storage (swift) および SELinux のメタデータを保存するために必要な拡張属性が含まれます。

   これで、undercloud-backup-<date>.tar.gz という名前のファイルが作成されます。<date> はシステムの日付になります。この tar ファイルを安全な場所にコピーします。

手順

1. データベースのバックアップを実行します。

   1. コントローラーノードにログインします。オーバークラウドには、アンダークラウドからアクセスできます。

      $ ssh heat-admin@192.0.2.100

   2. root ユーザーに変更します。

      $ sudo -i

   3. バックアップを保管するための一時ディレクトリーを作成します。

      # mkdir -p /var/tmp/mysql_backup/

   4. データベースのパスワードを取得して、MYSQLDBPASS の環境変数に保存します。このパスワードは、/etc/puppet/hieradata/service_configs.json ファイルの mysql::server::root_password の変数に保管されています。以下のコマンドを使用してパスワードを保管します。

      # MYSQLDBPASS=$(sudo hiera -c /etc/puppet/hiera.yaml mysql::server::root_password)

   5. データベースのバックアップを作成します。

      # mysql -uroot -p$MYSQLDBPASS -s -N -e "select distinct table_schema from information_schema.tables where engine='innodb' and table_schema != 'mysql';" | xargs mysqldump -uroot -p$MYSQLDBPASS --single-transaction --databases > /var/tmp/mysql_backup/openstack_databases-$(date +%F)-$(date +%T).sql

      このコマンドにより、/var/tmp/mysql_backup/openstack_databases-<date>.sql という名前のデータベースバックアップがダンプされます。<date> はシステムの日付と時刻になります。このデータベースダンプを安全な場所にコピーします。

   6. ユーザーおよびパーミッションに関する全情報をバックアップします。

      # mysql -uroot -p$MYSQLDBPASS -s -N -e "SELECT CONCAT('\"SHOW GRANTS FOR ''',user,'''@''',host,''';\"') FROM mysql.user where (length(user) > 0 and user NOT LIKE 'root')" | xargs -n1 mysql -uroot -p$MYSQLDBPASS -s -N -e | sed 's/$/;/' > /var/tmp/mysql_backup/openstack_databases_grants-$(date +%F)-$(date +%T).sql

      このコマンドにより、/var/tmp/mysql_backup/openstack_databases_grants-<date>.sql という名前のデータベースバックアップがダンプされます。<date> はシステムの日付と時刻になります。このデータベースダンプを安全な場所にコピーします。

2. Pacemaker の設定をバックアップします。

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

   2. 以下のコマンドを実行し、現在の Pacemaker 設定のアーカイブを作成します。

      # sudo pcs config backup pacemaker_controller_backup

   3. 作成されたアーカイブ (pacemaker_controller_backup.tar.bz2) を安全な場所にコピーします。

3. OpenStack Telemetry データベースをバックアップします。

   1. 任意のコントローラーに接続して、MongoDB のプライマリーインスタンスの IP を取得します。

      # MONGOIP=$(sudo hiera -c /etc/puppet/hiera.yaml mongodb::server::bind_ip)

   2. バックアップを作成します。

      # mkdir -p /var/tmp/mongo_backup/
      # mongodump --oplog --host $MONGOIP --out /var/tmp/mongo_backup/

   3. /var/tmp/mongo_backup/ 内のデータベースダンプを安全な場所にコピーします。

4. Redis クラスターをバックアップします。

   1. HAProxy から Redis のエンドポイントを取得します。

      # REDISIP=$(sudo hiera -c /etc/puppet/hiera.yaml redis_vip)

   2. Redis クラスターのマスターパスワードを取得します。

      # REDISPASS=$(sudo hiera -c /etc/puppet/hiera.yaml redis::masterauth)

   3. Redis クラスターの接続をチェックします。

      # redis-cli -a $REDISPASS -h $REDISIP ping

   4. Redis データベースをダンプします。

      # redis-cli -a $REDISPASS -h $REDISIP bgsave

      このコマンドにより、データベースのバックアップがデフォルトの /var/lib/redis/ ディレクトリーに保管されます。このデータベースダンプを安全な場所にコピーします。

5. 各コントローラーノードのファイルシステムをバックアップします。

   1. バックアップ用のディレクトリーを作成します。

      # mkdir -p /var/tmp/filesystem_backup/

   2. 以下の tar コマンドを実行します。

      # tar --acls --ignore-failed-read --xattrs --xattrs-include='*.*' \
          -zcvf /var/tmp/filesystem_backup/`hostname`-filesystem-`date '+%Y-%m-%d-%H-%M-%S'`.tar \
          /etc \
          /srv/node \
          /var/log \
          /var/lib/nova \
          --exclude /var/lib/nova/instances \
          /var/lib/glance \
          /var/lib/keystone \
          /var/lib/cinder \
          /var/lib/heat \
          /var/lib/heat-config \
          /var/lib/heat-cfntools \
          /var/lib/rabbitmq \
          /var/lib/neutron \
          /var/lib/haproxy \
          /var/lib/openvswitch \
          /var/lib/redis \
          /var/lib/os-collect-config \
          /usr/libexec/os-apply-config \
          /usr/libexec/os-refresh-config \
          /home/heat-admin

      --ignore-failed-read オプションを使用すると、見つからないディレクトリーは無視されます。これは、特定のサービスが使用されていない場合や、独自のカスタムロール上に分離されている場合に役立ちます。

   3. 作成された tar ファイルを安全な場所にコピーします。

6. オーバークラウドで削除された行をアーカイブします。

   1. アーカイブされた削除済みインスタンスを確認します。

      $ source ~/overcloudrc
      $ nova list --all-tenants --deleted

   2. アーカイブされた削除済みインスタンスがない場合は、オーバークラウドのコントローラーノードの 1 つで以下のコマンドを入力して、削除済みインスタンスをアーカイブします。

      # su - nova -s /bin/bash -c "nova-manage --debug db archive_deleted_rows --max_rows 1000"

      削除されたすべてのインスタンスをアーカイブするまで、このコマンドを再実行します。

   3. オーバークラウドのコントローラーノードの 1 つで以下のコマンドを入力して、アーカイブされた削除済みインスタンスをすべてパージします。

      # su - nova -s /bin/bash -c "nova-manage --debug db purge --all --all-cells"

   4. アーカイブされた削除済みインスタンスが残っていないことを確認します。

      $ nova list --all-tenants --deleted

手順

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

2. 主要な OpenStack Platform サービスを停止します。

   $ sudo systemctl stop 'openstack-*' 'neutron-*' httpd

   注記

   これにより、アンダークラウドで短時間のダウンタイムが生じます。アンダークラウドのアップグレード中もオーバークラウドは引き続き機能します。

3. RHEL のバージョンを RHEL 7.7 に設定します。

   $ sudo subscription-manager release --set=7.7

4. python-tripleoclient パッケージと依存関係を更新し、マイナーバージョンの更新向けの最新のスクリプトを使用できるようにします。

   $ sudo yum update -y python-tripleoclient

5. openstack undercloud upgrade コマンドを実行します。

   $ openstack undercloud upgrade

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

7. アンダークラウドをリブートして、オペレーティングシステムのカーネルとその他のシステムパッケージを更新します。

   $ sudo reboot

8. ノードがブートするまで待ちます。
9. アンダークラウドに stack ユーザーとしてログインします。

手順

1. カスタムの環境ファイル (例: network-environment.yaml) で、vhost ユーザーソケットディレクトリーを変更します。

   parameter_defaults:
     NeutronVhostuserSocketDir: "/var/lib/vhost_sockets"

2. openstack overcloud deploy コマンドに ovs-dpdk-permissions.yaml ファイルを追加して、qemu グループの設定値を OVS-DPDK 向けに hugetlbfs に設定します。

    -e environments/ovs-dpdk-permissions.yaml

3. すべてのインスタンスの vHost ユーザーポートは、必ず dpdkvhostuserclient モードに設定してください。詳細は、Manually changing the vhost user port mode を参照してください。

手順

1. yum ログをチェックして、新規イメージのアーカイブが利用可能かどうかを確認します。

   $ sudo grep "rhosp-director-images" /var/log/yum.log

2. 新規アーカイブが利用可能な場合には、現在のイメージを新規イメージに置き換えてください。新しいイメージをインストールするには、最初に stack ユーザーの images ディレクトリー (/home/stack/images) から既存のイメージを削除します。

   $ rm -rf ~/images/*

3. アンダークラウドノードにおいて、source コマンドでアンダークラウドの認証情報を読み込みます。

   $ source ~/stackrc

4. アーカイブを展開します。

   $ cd ~/images
   $ for i in /usr/share/rhosp-director-images/overcloud-full-latest-10.0.tar /usr/share/rhosp-director-images/ironic-python-agent-latest-10.0.tar; do tar -xvf $i; done

5. 最新のイメージを director にインポートして、ノードがこれらの新規イメージを使用するように設定します。

   $ cd ~/images
   $ openstack overcloud image upload --update-existing --image-path /home/stack/images/
   $ openstack overcloud node configure $(openstack baremetal node list -c UUID -f csv --quote none | sed "1d" | paste -s -d " ")

6. 新規イメージがあるかどうかをチェックして、イメージ更新の最終処理を行います。

   $ openstack image list
   $ ls -l /httpboot

   director は古いイメージを保持して、それらが更新された時のタイムスタンプを使用して名前を変更します。これらのイメージが必要でなくなったら、削除してください。

手順

1. サブスクリプション管理の設定で rhel_reg_release パラメーターを確認します。このパラメーターが設定されていない場合は、そのパラメーターを追加してバージョン 7.7 に設定する必要があります。

   parameter_defaults:
     ...
     rhel_reg_release: "7.7"

   オーバークラウドのサブスクリプション管理用環境ファイルに加えた変更を、必ず保存してください。

2. 元の openstack overcloud deploy コマンドに --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 <environment_file>|...]

   --update-plan-only のオプションを指定すると、director に保管されているオーバークラウドのプランのみが更新されます。-e オプションを使用して、オーバークラウドと関連のある環境ファイルとその更新パスを追加します。後で実行される環境ファイルで定義されているパラメーターとリソースが優先されることになるため、環境ファイルの順序は重要となります。以下の一覧は、環境ファイルの順序の例です。

   • Heat テンプレートコレクションの初期化ファイル (environments/network-isolation.yaml) を含むネットワーク分離ファイルと、次にカスタムの NIC 設定ファイル
   • 外部のロードバランシングの環境ファイル
   • ストレージの環境ファイル
   • Red Hat CDN または Satellite 登録用の環境ファイル
   • その他のカスタム環境ファイル

3. オーバークラウドの静的なインベントリーファイルを作成します。

   $ tripleo-ansible-inventory --ansible_ssh_user heat-admin --static-yaml-inventory ~/inventory.yaml

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

4. すべてのノードで、オペレーティングシステムのバージョンを Red Hat Enterprise Linux 7.7 に設定するタスクが含まれる Playbook を作成します。

   $ cat > ~/set_release.yaml <<'EOF'
   - hosts: all
     gather_facts: false
     tasks:
       - name: set release to 7.7
         command: subscription-manager release --set=7.7
         become: true
   EOF

5. set_release.yaml Playbook を実行します。

   $ ansible-playbook -i ~/inventory.yaml -f 25 ~/set_release.yaml --limit undercloud,Controller,Compute

   すべての Red Hat OpenStack Platform ノードにコンテンツを適用するには、--limit オプションを使用します。

6. openstack overcloud update コマンドを使用して、全ノードでパッケージの更新を実行します。

   $ openstack overcloud update stack -i overcloud

   -i のオプションを指定すると、各ノードは対話モードで順次に更新されます。更新プロセスによりノードの更新が完了すると、スクリプトにより、確認のためのブレークポイントが提供されます。-i オプションを指定しないと、最初のブレークポイントで更新が一時停止されたままになります。したがって、-i オプションを含めることが必須です。

   スクリプトは以下の機能を実行します。

   1. スクリプトはノード上で 1 つずつ実行します。

      1. コントローラーノードの場合は、これにより全パッケージが更新されます。
      2. その他のノードの場合には、これにより Puppet モジュールのみが更新されます。

   2. Puppet は全ノードで一度に実行されます。

      1. コントローラーノードの場合には、Puppet 実行により設定が同期されます。
      2. その他のノードの場合には、Puppet 実行により残りのパッケージが更新され、設定が同期されます。

7. 更新のプロセスが開始します。このプロセス中に、director は IN_PROGRESS のステータスを報告して、ブレークポイントをクリアするように定期的に要求します。以下に例を示します。

   starting package update on stack overcloud
   IN_PROGRESS
   IN_PROGRESS
   WAITING
   on_breakpoint: [u'overcloud-compute-0', u'overcloud-controller-2', u'overcloud-controller-1', u'overcloud-controller-0']
   Breakpoint reached, continue? Regexp or Enter=proceed (will clear 49913767-e2dd-4772-b648-81e198f5ed00), no=cancel update, C-c=quit interactive mode:

   Enter を押すと、on_breakpoint 一覧の最後のノードからブレークポイントをクリアします。これで、そのノードの更新が開始します。

8. スクリプトはノードの更新順序を自動的に事前定義します。

   • 各コントローラーノードを個別に事前定義
   • 各コンピュートノードを個別に事前定義
   • 各 Ceph Storage ノードを個別に事前定義
   • その他の全ノードを個別に事前定義

   更新を成功させるには、特に以下の順序で作業を行うことを推奨します。

   1. 各コントローラーノードのブレークポイントを個別にクリアします。更新後にノードのサービスを再起動する必要がある場合のために、各コントローラーノードには、個別のパッケージ更新が必要です。これにより、他のコントローラーノードの高可用性サービスの中断が抑えられます。
   2. コントローラーノードの更新後に、各コンピュートノードのブレークポイントをクリアします。また、特定のノード上でコンピュートノードの名前をタイプしてブレークポイントをクリアしたり、Python ベースの正規表現を使用して複数のコンピュートノード上のブレークポイントを一度にクリアしたりすることもできます。
   3. 各 Ceph Storage ノードのブレークポイントをクリアします。また、特定のノード上で Ceph Storage ノードの名前をタイプしてブレークポイントをクリアしたり、Python ベースの正規表現を使用して複数の Ceph Storage ノード上のブレークポイントを一度にクリアしたりすることもできます。
   4. 残りのブレークポイントをクリアして、その他のノードを更新します。特定のノードでノード名をタイプしてブレークポイントをクリアしたり、Python ベースの正規表現を使用して複数のノード上のブレークポイントを一度にクリアしたりすることもできます。
   5. すべてのノードの更新が完了するまで待ちます。

9. 更新が完了すると、コマンドにより COMPLETE のステータスが報告されます。

   ...
   IN_PROGRESS
   IN_PROGRESS
   IN_PROGRESS
   COMPLETE
   update finished with status COMPLETE

10. コントローラーノードにフェンシングを設定している場合には、更新プロセスによってその設定が無効になる場合があります。更新プロセスが完了したら、コントローラーノードの 1 つで以下のコマンドを実行してフェンシングを再度有効にします。

    $ sudo pcs property set stonith-enabled=true

手順

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. すべてのコントローラーノードおよびコンポーザブルノードについて、上記の手順を繰り返します。

手順

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

   $ sudo ceph osd set noout
   $ sudo ceph osd set norebalance

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

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

   $ sudo reboot

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

5. Ceph MON またはコントローラーノードにログインし、クラスターのステータスを確認します。

   $ sudo ceph -s

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

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

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

   $ sudo ceph osd unset noout
   $ sudo ceph osd unset norebalance

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

   $ sudo ceph status

手順

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

2. 再起動するコンピュートノードを特定するには、すべてのコンピュートノードを一覧表示します。

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

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. コンピュートノードにログインして、リブートします。

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

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

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

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

9. コンピュートノードが有効化されていることを確認します。

   (overcloud) $ openstack compute service list

手順

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

2. yum を実行して、システムパッケージを確認します。

   $ sudo yum list qemu-img-rhev qemu-kvm-common-rhev qemu-kvm-rhev qemu-kvm-tools-rhev openvswitch

3. ovs-vsctl を実行して、現在実行中のバージョンを確認します。

   $ sudo ovs-vsctl --version

4. すべてのノードでこれらのステップを繰り返します。

手順

1. アンダークラウドのアクセス情報を読み込みます。

   $ source ~/stackrc

2. エラーが発生している Systemd サービスがあるかどうかを確認します。

   $ sudo systemctl list-units --state=failed 'openstack*' 'neutron*' 'httpd' 'docker'

3. アンダークラウドの空き領域を確認します。

   $ df -h

   アンダークラウドの要件 を元に、十分な空き容量があるかどうかを判断します。

4. アンダークラウド上に NTP をインストールしている場合には、クロックが同期されていることを確認します。

   $ sudo ntpstat

5. アンダークラウドのネットワークサービスを確認します。

   $ openstack network agent list

   全エージェントが Alive で、それらの状態が UP である必要があります。

6. アンダークラウドの Compute サービスを確認します。

   $ openstack compute service list

   全エージェントのステータスが enabled で、状態が up である必要があります。

手順

1. アンダークラウドのアクセス情報を読み込みます。

   $ source ~/stackrc

2. ベアメタルノードのステータスを確認します。

   $ openstack baremetal node list

   全ノードの電源状態が有効で (on)、かつメンテナーンスモードが false である必要があります。

3. エラーが発生している Systemd サービスがあるかどうかを確認します。

   $ for NODE in $(openstack server list -f value -c Networks | cut -d= -f2); do echo "=== $NODE ===" ; ssh heat-admin@$NODE "sudo systemctl list-units --state=failed 'openstack*' 'neutron*' 'httpd' 'docker' 'ceph*'" ; done

4. 全サービスへの HAProxy 接続をチェックします。コントロールプレーンの仮想 IP アドレスと haproxy.stats サービスの認証情報を取得します。

   $ NODE=$(openstack server list --name controller-0 -f value -c Networks | cut -d= -f2); ssh heat-admin@$NODE sudo 'grep "listen haproxy.stats" -A 6 /etc/haproxy/haproxy.cfg'

5. 前の手順で取得した接続および認証情報を使用して、RHOSP サービスの接続ステータスを確認します。

   SSL が有効になっていない場合は、次の cURL リクエストでこれらの詳細を使用します。

   $ curl -s -u admin:<PASSWORD> "http://<IP ADDRESS>:1993/;csv" | egrep -vi "(frontend|backend)" | awk -F',' '{ print $1" "$2" "$18 }'

   SSL が有効になっている場合は、次の cURL リクエストでこれらの詳細を使用します。

   curl -s -u admin:<PASSWORD> "https://<HOSTNAME>:1993/;csv" | egrep -vi "(frontend|backend)" | awk -F',' '{ print $1" "$2" "$18 }'

   <PASSWORD> および <IP ADDRESS> または <HOSTNAME> の値は、haproxy.stats サービスからのそれぞれの情報に置き換えます。その結果表示される一覧には、各ノード上の OpenStack Platform サービスとそれらの接続ステータスが表示されます。

6. オーバークラウドデータベースのレプリケーションの正常性を確認します。

   $ for NODE in $(openstack server list --name controller -f value -c Networks | cut -d= -f2); do echo "=== $NODE ===" ; ssh heat-admin@$NODE "sudo clustercheck" ; done

7. RabbitMQ クラスターの正常性を確認します。

   $ for NODE in $(openstack server list --name controller -f value -c Networks | cut -d= -f2); do echo "=== $NODE ===" ; ssh heat-admin@$NODE "sudo rabbitmqctl node_health_check" ; done

8. Pacemaker リソースの正常性を確認します。

   $ NODE=$(openstack server list --name controller-0 -f value -c Networks | cut -d= -f2); ssh heat-admin@$NODE "sudo pcs status"

   以下の点を確認します。

   • 全クラスターノードが online であること
   • いずれのクラスターノード上でも stopped のリソースがないこと
   • pacemaker で failed のアクションがないこと

9. 各オーバークラウドノードでディスク領域を確認します。

   $ for NODE in $(openstack server list -f value -c Networks | cut -d= -f2); do echo "=== $NODE ===" ; ssh heat-admin@$NODE "sudo df -h --output=source,fstype,avail -x overlay -x tmpfs -x devtmpfs" ; done

10. オーバークラウドの Ceph Storage クラスターの正常性を確認します。以下のコマンドを使用すると、コントローラーノード上で ceph ツールが実行されて、クラスターをチェックします。

    $ NODE=$(openstack server list --name controller-0 -f value -c Networks | cut -d= -f2); ssh heat-admin@$NODE "sudo ceph -s"

11. Ceph Storage OSD に空き領域があるかどうかを確認します。以下のコマンドを使用すると、コントローラーノード上で ceph ツールが実行され、空き領域をチェックします。

    $ NODE=$(openstack server list --name controller-0 -f value -c Networks | cut -d= -f2); ssh heat-admin@$NODE "sudo ceph df"

    重要

    各 Ceph オブジェクトストレージデーモン (OSD) の配置グループ (PG) の数は、デフォルトでは 250 を超えることができません。OSD ごとの PG 数が上限を超える Ceph ノードをアップグレードすると、警告状態になりアップグレードプロセスが失敗する可能性があります。アップグレードプロセスを開始する前に、OSD ごとの PG 数を増やすことができます。この問題の診断およびトラブルシューティングに関する詳細は、アーティクル OpenStack FFU from 10 to 13 times out when Ceph allocated in one or more OSDs more than 250 PGs を参照してください。

12. オーバークラウドノードでクロックが同期されていることを確認します。

    $ for NODE in $(openstack server list -f value -c Networks | cut -d= -f2); do echo "=== $NODE ===" ; ssh heat-admin@$NODE "sudo ntpstat" ; done

13. オーバークラウドのアクセス情報を読み込みます。

    $ source ~/overcloudrc

14. オーバークラウドのネットワークサービスを確認します。

    $ openstack network agent list

    全エージェントが Alive で、それらの状態が UP である必要があります。

15. オーバークラウドの Compute サービスを確認します。

    $ openstack compute service list

    全エージェントのステータスが enabled で、状態が up である必要があります。

16. オーバークラウドのボリュームサービスを確認します。

    $ openstack volume service list

    全エージェントのステータスが enabled で、状態が up である必要があります。

1. オーバークラウドのアクセス情報を読み込みます。

   $ source ~/overcloudrc

2. スナップショットを作成するインスタンスのサーバー ID を確認します。

   $ openstack server list

3. スナップショットを作成する前に、元のインスタンスをシャットダウンして、全データがディスクにフラッシュされるようにしてください。

   $ openstack server stop SERVER_ID

4. インスタンスのスナップショットイメージを作成します。

   $ openstack image create --id SERVER_ID SNAPSHOT_NAME

5. このスナップショットイメージで新規インスタンスを起動します。

   $ openstack server create --flavor DPDK_FLAVOR --nic net-id=DPDK_NET_ID--image SNAPSHOT_NAME INSTANCE_NAME

6. オプションとして、新規インスタンスのステータスが ACTIVE であることを確認します。

   $ openstack server list

手順

1. それぞれのノードで以下のコマンドを実行して、ノードでの全 yum 履歴をファイルに保存します。

   $ sudo yum history list all > /home/heat-admin/$(hostname)-yum-history-all

2. それぞれのノードで以下のコマンドを実行して、最後の yum 履歴項目の ID を保存します。

   $ sudo yum history list all | head -n 5 | tail -n 1 | awk '{print $1}' > /home/heat-admin/$(hostname)-yum-history-all-last-id

3. これらのファイルを安全な場所にコピーします。

手順

1. stack ユーザーとして director にログインします。

2. 現在設定されている OpenStack Platform リポジトリーを無効にします。

   $ sudo subscription-manager repos --disable=rhel-7-server-openstack-10-rpms

3. 新しい OpenStack Platform リポジトリーを有効にします。

   $ sudo subscription-manager repos --enable=rhel-7-server-openstack-11-rpms

4. オーバークラウドのベースイメージの更新を無効にします。

   $ sudo yum-config-manager --setopt=exclude=rhosp-director-images* --save

5. 主要な OpenStack Platform サービスを停止します。

   $ sudo systemctl stop 'openstack-*' 'neutron-*' httpd

   注記

   これにより、アンダークラウドで短時間のダウンタイムが生じます。アンダークラウドのアップグレード中もオーバークラウドは引き続き機能します。

6. デフォルトのプロビジョニング/コントロールプレーンネットワークが 192.0.2.0/24 から 192.168.24.0/24 に変わりました。以前の undercloud.conf ファイルで、デフォルトのネットワーク値を使用していた場合には、プロビジョニング/コントロールプレーンネットワークは 192.0.2.0/24 に設定されます。これは、192.0.2.0/24 ネットワークを引き続き使用するには、undercloud.conf ファイルに特定のパラメーターを設定する必要があることを意味します。これらのパラメーターは以下のとおりです。

   • local_ip
   • network_gateway
   • undercloud_public_vip
   • undercloud_admin_vip
   • network_cidr
   • masquerade_network
   • dhcp_start
   • dhcp_end

   ネットワークの値を undercloud.conf に設定して、今後アップグレードを実行する際に 192.0.2.0/24 CIDR を引き続き使用するようにします。openstack undercloud upgrade コマンドを実行する前に、ネットワークの設定が正しく設定されていることを確認してください。

7. yum コマンドを実行して、director の主要なパッケージをアップグレードします。

   $ sudo yum update -y instack-undercloud openstack-puppet-modules openstack-tripleo-common python-tripleoclient

8. 以下のコマンドを実行してアンダークラウドをアップグレードします。

   $ openstack undercloud upgrade

9. アンダークラウドのアップグレードプロセスが完了するまで待ちます。

手順

1. stack ユーザーとして director にログインします。

2. 現在設定されている OpenStack Platform リポジトリーを無効にします。

   $ sudo subscription-manager repos --disable=rhel-7-server-openstack-11-rpms

3. 新しい OpenStack Platform リポジトリーを有効にします。

   $ sudo subscription-manager repos --enable=rhel-7-server-openstack-12-rpms

4. オーバークラウドのベースイメージの更新を無効にします。

   $ sudo yum-config-manager --setopt=exclude=rhosp-director-images* --save

5. yum コマンドを実行して、director の主要なパッケージをアップグレードします。

   $ sudo yum update -y python-tripleoclient

6. /home/stack/undercloud.conf ファイルを編集して、enabled_drivers パラメーターに pxe_ssh ドライバーが含まれていないことを確認します。Virtual Baseboard Management Controller (VBMC) が推奨されるようになったため、このドライバーは非推奨となり、Red Hat OpenStack Platform から削除されました。この新しいドライバーと移行手順の詳細は、director のインストールと使用方法の付録 Virtual Baseboard Management Controller (VBMC) を参照してください。

7. 以下のコマンドを実行してアンダークラウドをアップグレードします。

   $ openstack undercloud upgrade

8. アンダークラウドのアップグレードプロセスが完了するまで待ちます。

手順

1. stack ユーザーとして director にログインします。

2. 現在設定されている OpenStack Platform リポジトリーを無効にします。

   $ sudo subscription-manager repos --disable=rhel-7-server-openstack-12-rpms

3. RHEL のバージョンを RHEL 7.9 に設定します。

   $ sudo subscription-manager release --set=7.9

4. 新しい OpenStack Platform リポジトリーを有効にします。

   $ sudo subscription-manager repos --enable=rhel-7-server-openstack-13-rpms

5. オーバークラウドのベースイメージへの更新を再度有効にします。

   $ sudo yum-config-manager --setopt=exclude= --save

6. yum コマンドを実行して、director の主要なパッケージをアップグレードします。

   $ sudo yum update -y python-tripleoclient

7. 以下のコマンドを実行してアンダークラウドをアップグレードします。

   $ openstack undercloud upgrade

8. アンダークラウドのアップグレードプロセスが完了するまで待ちます。

9. アンダークラウドをリブートして、オペレーティングシステムのカーネルとその他のシステムパッケージを更新します。

   $ sudo reboot

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

手順

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

2. openstack-glance-registry サービスを停止して無効にします。

   $ sudo systemctl stop openstack-glance-registry
   $ sudo systemctl disable openstack-glance-registry

3. mongod サービスを停止して無効にします。

   $ sudo systemctl stop mongod
   $ sudo systemctl disable mongod

手順

1. イメージを直接 registry.redhat.io からオーバークラウドデプロイメントにプルするには、イメージパラメーターを指定するための環境ファイルが必要となります。以下のコマンドを実行してコンテナーイメージの環境ファイルを生成します。

   (undercloud) $ sudo openstack overcloud container image prepare \
     --namespace=registry.redhat.io/rhosp13 \
     --prefix=openstack- \
     --tag-from-label {version}-{release} \
     --output-env-file=/home/stack/templates/overcloud_images.yaml

   • 任意のサービス用の環境ファイルを指定するには、-e オプションを使用します。
   • カスタムロールファイルを指定するには、-r オプションを使用します。
   • Ceph Storage を使用している場合には、Ceph Storage 用のコンテナーイメージの場所を定義する追加のパラメーターを指定します: --set ceph_namespace、--set ceph_image、--set ceph_tag

2. overcloud_images.yaml ファイルを変更し、デプロイメント時に registry.redhat.io との間で認証を行うために以下のパラメーターを追加します。

   ContainerImageRegistryLogin: true
   ContainerImageRegistryCredentials:
     registry.redhat.io:
       <USERNAME>: <PASSWORD>

   • <USERNAME> および <PASSWORD> を registry.redhat.io の認証情報に置き換えます。

     overcloud_images.yaml ファイルには、アンダークラウド上のイメージの場所が含まれます。このファイルをデプロイメントに追加します。

     注記

     openstack overcloud deploy コマンドを実行する前に、リモートレジストリーにログインする必要があります。

     (undercloud) $ sudo docker login registry.redhat.io

手順

1. ローカルアンダークラウドレジストリーのアドレスを特定します。アドレスは次のパターンを使用します。

   <REGISTRY_IP_ADDRESS>:8787

   アンダークラウドの IP アドレスを使用します。これは undercloud.conf ファイルの local_ip パラメーターで設定済みのアドレスです。以下のコマンドでは、アドレスが 192.168.24.1:8787 であることを前提としています。

2. registry.redhat.io にログインします。

   (undercloud) $ docker login registry.redhat.io --username $RH_USER --password $RH_PASSWD

3. イメージをローカルレジストリーにアップロードするためのテンプレートと、それらのイメージを参照する環境ファイルを作成します。

   (undercloud) $ openstack overcloud container image prepare \
     --namespace=registry.redhat.io/rhosp13 \
     --push-destination=192.168.24.1:8787 \
     --prefix=openstack- \
     --tag-from-label {version}-{release} \
     --output-env-file=/home/stack/templates/overcloud_images.yaml \
     --output-images-file /home/stack/local_registry_images.yaml

   • 任意のサービス用の環境ファイルを指定するには、-e オプションを使用します。
   • カスタムロールファイルを指定するには、-r オプションを使用します。
   • Ceph Storage を使用している場合には、Ceph Storage 用のコンテナーイメージの場所を定義する追加のパラメーターを指定します: --set ceph_namespace、--set ceph_image、--set ceph_tag

4. 次の 2 つのファイルが作成されていることを確認します。

   • リモートソースからのコンテナーイメージの情報が含まれている local_registry_images.yaml。このファイルを使用して、Red Hat Container Registry (registry.redhat.io) からイメージをアンダークラウドにプルします。
   • アンダークラウド上の最終的なイメージの場所が記載されている overcloud_images.yaml。このファイルをデプロイメントで指定します。

5. コンテナーイメージをリモートレジストリーからプルし、アンダークラウドレジストリーにプッシュします。

   (undercloud) $ openstack overcloud container image upload \
     --config-file  /home/stack/local_registry_images.yaml \
     --verbose

   ネットワークおよびアンダークラウドディスクの速度によっては、必要なイメージをプルするのに時間がかかる場合があります。

   注記

   コンテナーイメージは、およそ 10 GB のディスク領域を使用します。

6. これで、イメージがアンダークラウドの docker-distribution レジストリーに保管されます。アンダークラウドの docker-distribution レジストリーのイメージ一覧を表示するには、以下のコマンドを実行します。

   (undercloud) $  curl http://192.168.24.1:8787/v2/_catalog | jq .repositories[]

   注記

   _catalog リソース自体は、イメージを 100 個のみ表示します。追加のイメージを表示するには、?n=<interger> クエリー文字列を _catalog リソースと共に使用して、多数のイメージを表示します。

   (undercloud) $  curl http://192.168.24.1:8787/v2/_catalog?n=150 | jq .repositories[]

   特定イメージのタグの一覧を表示するには、skopeo コマンドを使用します。

   (undercloud) $ curl -s http://192.168.24.1:8787/v2/rhosp13/openstack-keystone/tags/list | jq .tags

   タグ付けられたイメージを検証するには、skopeo コマンドを使用します。

   (undercloud) $ skopeo inspect --tls-verify=false docker://192.168.24.1:8787/rhosp13/openstack-keystone:13.0-44

手順

1. イメージをローカルレジストリーにプルするためのテンプレートを作成します。

   $ source ~/stackrc
   (undercloud) $ openstack overcloud container image prepare \
     --namespace=rhosp13 \
     --prefix=openstack- \
     --output-images-file /home/stack/satellite_images

   • 任意のサービス用の環境ファイルを指定するには、-e オプションを使用します。
   • カスタムロールファイルを指定するには、-r オプションを使用します。
   • Ceph Storage を使用している場合には、Ceph Storage 用のコンテナーイメージの場所を定義する追加のパラメーターを指定します: --set ceph_namespace、--set ceph_image、--set ceph_tag
   注記

   上記の openstack overcloud container image prepare コマンドは、registry.redhat.io のレジストリーをターゲットにしてイメージの一覧を生成します。この後のステップでは、openstack overcloud container image prepare コマンドで別の値を使用します。

2. これで、コンテナーイメージの情報が含まれた satellite_images という名前のファイルが作成されます。このファイルを使用して、コンテナーイメージを Satellite 6 サーバーに同期します。

3. satellite_images ファイルから YAML 固有の情報を削除して、イメージ一覧のみが記載されたフラットファイルに変換します。この操作は、以下の sed コマンドで実行します。

   (undercloud) $ awk -F ':' '{if (NR!=1) {gsub("[[:space:]]", ""); print $2}}' ~/satellite_images > ~/satellite_images_names

   これにより、Satellite サーバーにプルするイメージのリストが提供されます。

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

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

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

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

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

   $ hammer repository create \
     --organization "ACME" \
     --product "OSP13 Containers" \
     --content-type docker \
     --url https://registry.redhat.io \
     --docker-upstream-name rhosp13/openstack-base \
     --name base

7. 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 "OSP13 Containers" \
     --content-type docker \
     --url https://registry.redhat.io \
     --docker-upstream-name $IMAGE \
     --name $IMAGENAME ; done < satellite_images_names

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

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

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

   注記

   設定によっては、hammer から Satellite Server のユーザー名およびパスワードが要求される場合があります。設定ファイルを使って自動的にログインするように hammer を設定することができます。Hammer CLI ガイドの 認証 セクションを参照してください。

9. Satellite 6 サーバーでコンテンツビューを使用している場合には、新規コンテンツビューバージョンを作成して、イメージを取り入れます。

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

    $ hammer docker tag list --repository "base" \
      --organization "ACME" \
      --product "OSP13 Containers"

    これにより、OpenStack Platform コンテナーイメージのタグが表示されます。

11. アンダークラウドに戻り、Satellite サーバー上のイメージ用に環境ファイルを生成します。環境ファイルを生成するコマンドの例を以下に示します。

    (undercloud) $ openstack overcloud container image prepare \
      --namespace=satellite6.example.com:5000 \
      --prefix=acme-osp13_containers- \
      --tag-from-label {version}-{release} \
      --output-env-file=/home/stack/templates/overcloud_images.yaml

    注記

    このステップの openstack overcloud container image prepare コマンドは、Satellite サーバーをターゲットにします。ここでは、前のステップで使用した openstack overcloud container image prepare コマンドとは異なる値を指定します。

    このコマンドを実行する際には、以下の情報を含めてください。

    • --namespace: Satellite サーバー上のレジストリーの URL およびポート。Red Hat Satellite のレジストリーポートは 5000 です。たとえば、--namespace=satellite6.example.com:5000 のように設定します。

      注記

      Red Hat Satellite バージョン 6.10 を使用している場合は、ポートを指定する必要はありません。デフォルトのポート 443 が使用されます。詳細は、"How can we adapt RHOSP13 deployment to Red Hat Satellite 6.10?" を参照してください。.

    • --prefix= - この接頭辞は、ラベルの Satellite 6 の命名規則に基づいており、この接頭辞は小文字を使用し、アンダースコアの代わりにスペースを使用します。この接頭辞は、コンテンツビューを使用するかどうかによって異なります。

      • コンテンツビューを使用する場合、設定は [org]-[environment]-[content view]-[product]- です。たとえば、acme-production-myosp13-osp13_containers- のようになります。
      • コンテンツビューを使用しない場合、設定は [org]-[product]- です。たとえば、acme-osp13_containers- のようになります。
    • --tag-from-label {version}-{release}: 各イメージの最新のタグを識別します。
    • -e: オプションのサービスの環境ファイルを指定します。
    • -r: カスタムロールファイルを指定します。

    • --set ceph_namespace、--set ceph_image、--set ceph_tag: Ceph Storage を使用する場合には、Ceph Storage のコンテナーイメージの場所を定義する追加のパラメーターを指定します。ceph_image に Satellite 固有の接頭辞が追加された点に注意してください。この接頭辞は、--prefix オプションと同じ値です。以下に例を示します。

      --set ceph_image=acme-osp13_containers-rhceph-3-rhel7

      これにより、オーバークラウドは Satellite の命名規則の Ceph コンテナーイメージを使用することができます。

12. overcloud_images.yaml ファイルには、Satellite サーバー上のイメージの場所が含まれます。このファイルをデプロイメントに追加します。

手順

1. カスタム環境ファイルを表示します。

   $ cat ~/templates/custom_environment.yaml

2. ファイルコンテンツの resource_registry セクションを確認します。

3. resource_registry セクションのコンポーザブルサービスを確認します。以下の名前空間を使用するコンポーザブルサービス。

   OS::TripleO::Services

   たとえば、以下のコンポーザブルサービスは、OpenStack Bare Metal サービス (ironic) API に関するものです。

   OS::TripleO::Services::IronicApi

4. コンポーザブルサービスが Puppet 固有の Heat テンプレートにマッピングされているかどうかを確認します。以下に例を示します。

   resource_registry:
     OS::TripleO::Services::IronicApi: /usr/share/openstack-triple-heat-template/puppet/services/ironic-api.yaml

5. コンテナー化バージョンの Heat テンプレートが /usr/share/openstack-triple-heat-template/docker/services/ にあるかどうかを確認し、サービスをコンテナー化バージョンに再マッピングします。

   resource_registry:
     OS::TripleO::Services::IronicApi: /usr/share/openstack-triple-heat-template/docker/services/ironic-api.yaml

   あるいは、/usr/share/openstack-tripleo-heat-templates/environments/ にあるサービスの更新された環境ファイルを使用します。たとえば、OpenStack Bare Metal サービス (ironic) を有効にする最新の環境ファイルは /usr/share/openstack-tripleo-heat-templates/environments/services/ironic.yaml で、ここにはコンテナー化されたサービスへのマッピングが含まれています。

   カスタムサービスがコンテナー化されたサービスを使用しない場合には、マッピングを Puppet 固有の Heat テンプレートのままにします。

手順

1. director の管理する Ceph Storage クラスターまたは外部の Ceph Storage クラスターを使用している場合には、ceph-ansible パッケージをインストールします。

   1. アンダークラウドで Ceph Tools リポジトリーを有効にします。

      [stack@director ~]$ sudo subscription-manager repos --enable=rhel-7-server-rhceph-3-tools-rpms

   2. ceph-ansible パッケージをアンダークラウドにインストールします。

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

2. Ceph 固有の環境ファイルを確認し、Ceph 固有の heat リソースがコンテナー化されたサービスを使用する状態にします。

   • director が Ceph Storage クラスターを管理する場合には、resource_register のリソースが docker/services/ceph-ansible のテンプレートをポイントする状態にします。

     resource_registry:
       OS::TripleO::Services::CephMgr: /usr/share/openstack-tripleo-heat-templates/docker/services/ceph-ansible/ceph-mgr.yaml
       OS::TripleO::Services::CephMon: /usr/share/openstack-tripleo-heat-templates/docker/services/ceph-ansible/ceph-mon.yaml
       OS::TripleO::Services::CephOSD: /usr/share/openstack-tripleo-heat-templates/docker/services/ceph-ansible/ceph-osd.yaml
       OS::TripleO::Services::CephClient: /usr/share/openstack-tripleo-heat-templates/docker/services/ceph-ansible/ceph-client.yaml

     重要

     この設定は、/usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-ansible.yaml の環境ファイルに記載されています。このファイルは、-e を使用して今後すべてのデプロイメントコマンドに追加することができます。

     注記

     環境で使用する環境ファイルまたはテンプレートファイルが /usr/share ディレクトリーにない場合は、ファイルへの絶対パスを含める必要があります。

   • 外部 Ceph Storage クラスターの場合には、resource_register のリソースが docker/services/ceph-ansible のテンプレートをポイントする状態にします。

     resource_registry:
       OS::TripleO::Services::CephExternal: /usr/share/openstack-tripleo-heat-templates/docker/services/ceph-ansible/ceph-external.yaml

     重要

     この設定は、/usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-ansible-external.yaml の環境ファイルに記載されています。このファイルは、-e を使用して今後すべてのデプロイメントコマンドに追加することができます。

3. director が管理する Ceph Storage クラスターの場合には、新しい CephAnsibleDisksConfig パラメーターを使用して、ディスクのマッピングの方法を定義します。以前のバージョンの Red Hat OpenStack Platform では、ceph::profile::params::osds hieradata を使用して OSD レイアウトを定義していました。この hieradata を CephAnsibleDisksConfig パラメーターの設定に変換します。以下の例で、Ceph ジャーナルディスクが共存する場合と共存しない場合について、hieradata を CephAnsibleDisksConfig パラメーターの設定に変換する方法を説明します。

   重要

   osd_scenario を設定する必要があります。osd_scenario を設定しないままにすると、デプロイメントに失敗する場合があります。

   • Ceph ジャーナルディスクが共存するケースで、hieradata が以下のようであれば、

     parameter_defaults:
       ExtraConfig:
         ceph::profile::params::osd_journal_size: 512
         ceph::profile::params::osds:
           '/dev/sdb': {}
           '/dev/sdc': {}
           '/dev/sdd': {}

     CephAnsibleDisksConfig パラメーターを使用して、以下のように hieradata を変換し、ceph::profile::params::osds を {} に設定します。

     parameter_defaults:
       CephAnsibleDisksConfig:
         devices:
         - /dev/sdb
         - /dev/sdc
         - /dev/sdd
         journal_size: 512
         osd_scenario: collocated
       ExtraConfig:
           ceph::profile::params::osds: {}

   • ジャーナルがより高速な専用のデバイスにあり共存しないケースで、hieradata が以下のようであれば、

     parameter_defaults:
       ExtraConfig:
         ceph::profile::params::osd_journal_size: 512
         ceph::profile::params::osds:
           '/dev/sdb':
              journal: ‘/dev/sdn’
           '/dev/sdc':
              journal: ‘/dev/sdn’
           '/dev/sdd':
              journal: ‘/dev/sdn’

     CephAnsibleDisksConfig パラメーターを使用して、以下のように hieradata を変換し、ceph::profile::params::osds を {} に設定します。

     parameter_defaults:
       CephAnsibleDisksConfig:
         devices:
         - /dev/sdb
         - /dev/sdc
         - /dev/sdd
         dedicated_devices:
         - /dev/sdn
         - /dev/sdn
         - /dev/sdn
         journal_size: 512
         osd_scenario: non-collocated
       ExtraConfig:
         ceph::profile::params::osds: {}

   ceph-ansible に使用する OSD ディスクレイアウトオプションの完全な一覧は、/usr/share/ceph-ansible/group_vars/osds.yml.sample のサンプルファイルを参照してください。

4. 今後のデプロイメントコマンドでは、-e オプションを使用して新しい Ceph の設定環境ファイルを指定します。これには以下のファイルが含まれます。

   • director の管理する Ceph Storage の場合:

     • /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-ansible.yaml
     • Ansible ベースのディスクマッピングが含まれる環境ファイル
     • Ceph Storage のカスタマイズに関するその他の環境ファイル

   • 外部 Ceph Storage の場合:

     • /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-ansible-external.yaml
     • Ceph Storage のカスタマイズに関するその他の環境ファイル

手順

1. director の動的な Ansible スクリプトが OpenStack Platform 12 バージョンに更新され、オーバークラウドプラン内の RoleNetHostnameMap Heat パラメーターを使用してインベントリーを定義するようになりました。ただし、オーバークラウドは現在 OpenStack Platform 11 のテンプレートバージョンを使用しており、これには RoleNetHostnameMap パラメーターがありません。これは、一時的な静的インベントリーファイルを作成する必要があることを意味します。このファイルは、以下のコマンドを実行すると生成することができます。

   $ openstack server list -c Networks -f value | cut -d"=" -f2 > overcloud_hosts

2. 以下の内容を記述した Ansible Playbook (undercloud-ca.yml) を作成します。

   ---
   - name: Add undercloud CA to overcloud nodes
     hosts: all
     user: heat-admin
     become: true
     vars:
       ca_certificate: /etc/pki/ca-trust/source/anchors/cm-local-ca.pem
     tasks:
       - name: Copy undercloud CA
         copy:
           src: "{{ ca_certificate }}"
           dest: /etc/pki/ca-trust/source/anchors/
       - name: Update trust
         command: "update-ca-trust extract"
       - name: Get the swift endpoint
         shell: |
           sudo hiera swift::keystone::auth::public_url | awk -F/ '{print $3}'
         register: swift_endpoint
         delegate_to: 127.0.0.1
         become: yes
         become_user: stack
       - name: Verify URL
         uri:
           url: https://{{ swift_endpoint.stdout }}/healthcheck
           return_content: yes
         register: verify
       - name: Report output
         debug:
           msg: "{{ ansible_hostname }} can access the undercloud's Public API"
         when: verify.content == "OK"

   この Playbook には複数のタスクが含まれており、各ノードで以下の操作を実行します。

   • アンダークラウドの認証局ファイルをオーバークラウドノードにコピーします。アンダークラウドによって生成された場合には、デフォルトの場所は /etc/pki/ca-trust/source/anchors/cm-local-ca.pem です。
   • オーバークラウドノードで、認証局トラストデータベースを更新するコマンドを実行します。
   • オーバークラウドノードから、アンダークラウドの Object Storage パブリック API をチェックして、成功したかどうかを報告します。

3. 以下のコマンドで Playbook を実行します。

   $ ansible-playbook -i overcloud_hosts undercloud-ca.yml

   ここでは、一時インベントリーを使用して、Ansible にオーバークラウドノードを指定します。

   カスタムの認証局ファイルを使用している場合は、ca_certificate 変数で場所を変更することができます。以下に例を示します。

   $ ansible-playbook -i overcloud_hosts undercloud-ca.yml -e ca_certificate=/home/stack/ssl/ca.crt.pem

4. その結果、Ansible の出力には、ノードのデバッグメッセージが表示されます。以下に例を示します。

   ok: [192.168.24.100] => {
       "msg": "overcloud-controller-0 can access the undercloud's Public API"
   }

手順

1. 環境ファイルを選択して、ExtraConfig パラメーターが設定されているかどうかを確認します。

   $ grep ExtraConfig ~/templates/custom-config.yaml

2. このコマンドの結果に、選択したファイル内のいずれかのロールの ExtraConfig パラメーター (例: ControllerExtraConfig) が表示される場合には、そのファイルの完全なパラメーター構造を確認してください。

3. SECTION/parameter 構文で value が続くいずれかの Puppet hieradata がパラメーターに含まれている場合には、実際の Puppet クラスのパラメーターに置き換えられている可能性があります。以下に例を示します。

   parameter_defaults:
     ExtraConfig:
       neutron::config::dhcp_agent_config:
         'DEFAULT/dnsmasq_local_resolv':
           value: 'true'

4. director の Puppet モジュールを確認して、パラメーターが Puppet クラス内に存在しているかどうかを確認します。以下に例を示します。

   $ grep dnsmasq_local_resolv

   その場合には、新規インターフェイスに変更します。

5. 構文の変更の実例を以下に示します。

   • 例 1:

     parameter_defaults:
       ExtraConfig:
         neutron::config::dhcp_agent_config:
           'DEFAULT/dnsmasq_local_resolv':
             value: 'true'

     変更後

     parameter_defaults:
       ExtraConfig:
         neutron::agents::dhcp::dnsmasq_local_resolv: true

   • 例 2:

     parameter_defaults:
       ExtraConfig:
         ceilometer::config::ceilometer_config:
           'oslo_messaging_rabbit/rabbit_qos_prefetch_count':
             value: '32'

     変更後

     parameter_defaults:
       ExtraConfig:
         oslo::messaging::rabbit::rabbit_qos_prefetch_count: '32'

手順

1. 次のコマンドを実行して、ノード IP アドレスのリストを OVERCLOUD_HOSTS 環境変数に保存します。

   $ source ~/stackrc
   $ export OVERCLOUD_HOSTS=$(openstack server list -f value -c Networks | cut -d "=" -f 2 | tr '\n' ' ')

2. 次のスクリプトを実行します。

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

3. アップグレードを続行します。

   • 事前にプロビジョニングされたノードで openstack overcloud upgrade run コマンドを使用する場合は、--ssh-user tripleo-admin パラメーターを含めます。

   • Compute ノードまたは Object Storage ノードをアップグレードする場合は、以下を使用します。

     1. upgrade-non-controller.sh スクリプトで -U オプションを使用して、stack ユーザーを指定します。これは、事前にプロビジョニングされたノードのデフォルトユーザーが heat-admin ではなく stack であるためです。

     2. --upgrade オプションでノードの IP アドレスを使用します。これは、ノードが director の Compute (nova) サービスおよび Bare Metal (ironic) サービスで管理されておらず、ノード名がないためです。

        以下に例を示します。

        $ upgrade-non-controller.sh -U stack --upgrade 192.168.24.100

手順

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

   $ source ~/stackrc

2. お使いのデプロイメントに適したすべての該当するオプションおよび環境ファイルと共に、Fast Forward Upgrade の prepare コマンドを実行します。

   $ openstack overcloud ffwd-upgrade prepare \
       --templates \
       -e /home/stack/templates/overcloud_images.yaml \
       -e /home/stack/templates/deprecated_cli_options.yaml \
       -e /home/stack/templates/custom_repositories_script.yaml \
       -e /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-ansible.yaml \
       -e /home/stack/templates/ceph-customization.yaml \
       -e <ENVIRONMENT FILE>

   以下のオプションの中で、お使いの環境に適切なオプションを追加します。

   • カスタム設定環境ファイル (-e)。以下に例を示します。

     • コンテナーイメージの場所が記載された環境ファイル (overcloud_images.yaml)。アップグレードのコマンドで --container-registry-file の使用に関する警告が表示される場合があることに注意してください。このオプションは非推奨になり、コンテナーイメージの環境ファイルには -e の使用が推奨されるようになっているので、この警告は無視して問題ありません。
     • 該当する場合は、非推奨になった CLI オプションを Heat パラメーターにマッピングする環境ファイル。deprecated_cli_options.yaml を使用します。
     • 該当する場合は、カスタムリポジトリーのスクリプトを指定する環境ファイル。custom_repositories_script.yaml を使用します。
     • Ceph Storage ノードを使用する場合には、関連する環境ファイル
     • お使いの環境に関連する追加の環境ファイル
   • カスタムのスタック名を使用する場合には、--stack オプションでその名前を渡します。
   • 該当する場合は、--roles-file でカスタムロール (roles_data) のファイルを指定します。
   重要

   ffwd-upgrade コマンドの実行を確認するプロンプトが表示されます。yes と入力してください。

   注記

   openstack ffwd-upgrade prepare コマンドは複数回実行できます。コマンドが失敗した場合は、テンプレートの問題を修正してから、コマンドを再実行できます。

3. オーバークラウドプランが OpenStack Platform 13 バージョンに更新されます。Fast Forward Upgrade の準備が完了するまで待ちます。
4. アップグレードを行う前に、オーバークラウドのスナップショットまたはバックアップを作成します。

5. Fast Forward Upgrade のコマンドを実行します。

   $ openstack overcloud ffwd-upgrade run

   • カスタムのスタック名を使用する場合には、--stack オプションでその名前を渡します。
   重要

   ffwd-upgrade コマンドの実行を確認するプロンプトが表示されます。yes と入力してください。

   注記

   openstack ffwd-upgrade run コマンドは、複数回実行できます。コマンドが失敗した場合は、テンプレートの問題を修正してから、コマンドを再実行できます。

6. Fast Forward Upgrade が完了するまで待ちます。

手順

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

   $ source ~/stackrc

2. モノリシックなコントローラーノードを使用している場合は、Controller ロールに対してアップグレードコマンドを実行します。

   $ openstack overcloud upgrade run --nodes Controller --skip-tags validation

   • カスタムのスタック名を使用する場合は、--stack オプションでその名前を渡します。

3. 複数のロールにわたって分割されたコントローラーサービスを使用している場合の操作は以下のとおりです。

   1. Pacemaker サービスを使用するロールのアップグレードコマンドを実行します。

      $ openstack overcloud upgrade run --nodes ControllerOpenStack --skip-tags validation
      $ openstack overcloud upgrade run --nodes Database --skip-tags validation
      $ openstack overcloud upgrade run --nodes Messaging --skip-tags validation
      $ openstack overcloud upgrade run --nodes Telemetry --skip-tags validation

      • カスタムのスタック名を使用する場合は、--stack オプションでその名前を渡します。

   2. Networker ロールのアップグレードコマンドを実行します。

      $ openstack overcloud upgrade run --nodes Networker --skip-tags validation

      • カスタムのスタック名を使用する場合は、--stack オプションでその名前を渡します。

   3. Compute ロールまたは CephStorage ロールを除く、残りすべてのカスタムロールのアップグレードコマンドを実行します。

      $ openstack overcloud upgrade run --nodes ObjectStorage --skip-tags validation

      • カスタムのスタック名を使用する場合は、--stack オプションでその名前を渡します。

手順

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

   $ source ~/stackrc

2. アップグレードのコマンドを実行します。

   $ openstack overcloud upgrade run --nodes compute-0 --skip-tags validation

   注記

   OpenStack Platform サービスはオーバークラウド上では非アクティブな状態で検証できないため、上記のコマンドには --skip-tags validation を使用しています。

   • カスタムのスタック名を使用する場合には、--stack オプションでその名前を渡します。
3. テスト用ノードのアップグレードが完了するまで待ちます。

手順

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

   $ source ~/stackrc

2. アップグレードのコマンドを実行します。

   $ openstack overcloud upgrade run --nodes Compute --skip-tags validation

   注記

   OpenStack Platform サービスはオーバークラウド上では非アクティブな状態で検証できないため、上記のコマンドには --skip-tags validation を使用しています。

   • カスタムのスタック名を使用している場合には、--stack オプションでその名前を渡します。
   • カスタムの Compute ロールを使用する場合には、--nodes オプションでそのロール名を含めます。
3. コンピュートノードのアップグレードが完了するまで待ちます。

手順

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

   $ source ~/stackrc

2. アップグレードのコマンドを実行します。

   $ openstack overcloud upgrade run --nodes CephStorage --skip-tags validation

   注記

   OpenStack Platform サービスはオーバークラウド上では非アクティブな状態で検証できないため、上記のコマンドには --skip-tags validation を使用しています。

   • カスタムのスタック名を使用する場合には、--stack オプションでその名前を渡します。
3. ノードのアップグレードが完了するまで待ちます。

4. Ceph Storage のアップグレードコマンドを実行します。以下に例を示します。

   $ openstack overcloud ceph-upgrade run \
       --templates \
       -e <ENVIRONMENT FILE> \
       -e /home/stack/templates/overcloud_images.yaml \
       -e /home/stack/templates/deprecated_cli_options.yaml \
       -e /home/stack/templates/custom_repositories_script.yaml
       -e /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-ansible.yaml \
       -e /home/stack/templates/ceph-customization.yaml \
       --ceph-ansible-playbook '/usr/share/ceph-ansible/infrastructure-playbooks/switch-from-non-containerized-to-containerized-ceph-daemons.yml,/usr/share/ceph-ansible/infrastructure-playbooks/rolling_update.yml'

   以下のオプションの中で、お使いの環境に適切なオプションを追加します。

   • カスタム設定環境ファイル (-e)。以下に例を示します。

     • コンテナーイメージの場所が記載された環境ファイル (overcloud_images.yaml)。アップグレードのコマンドで --container-registry-file の使用に関する警告が表示される場合があることに注意してください。このオプションは非推奨になり、コンテナーイメージの環境ファイルには -e の使用が推奨されるようになっているので、この警告は無視して問題ありません。
     • 該当する場合は、非推奨になった CLI オプションを Heat パラメーターにマッピングする環境ファイル。deprecated_cli_options.yaml を使用します。
     • 該当する場合は、カスタムリポジトリーのスクリプトを指定する環境ファイル。custom_repositories_script.yaml を使用します。
     • Ceph Storage ノード用の関連する環境ファイル
     • お使いの環境に関連する追加の環境ファイル
   • カスタムのスタック名を使用する場合には、--stack オプションでその名前を渡します。
   • 該当する場合は、--roles-file でカスタムロール (roles_data) のファイルを指定します。
   • 以下の Ansible Playbook
   • /usr/share/ceph-ansible/infrastructure-playbooks/switch-from-non-containerized-to-containerized-ceph-daemons.yml
   • /usr/share/ceph-ansible/infrastructure-playbooks/rolling_update.yml
5. Ceph Storage ノードのアップグレードが完了するまで待ちます。

手順

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

   $ source ~/stackrc

2. アップグレードのコマンドを実行します。

   $ openstack overcloud upgrade run --roles ComputeHCI

   カスタムのスタック名を使用している場合には、--stack オプションでアップグレードコマンドにその名前を渡します。

3. Ceph Storage のアップグレードコマンドを実行します。以下に例を示します。

   $ openstack overcloud ceph-upgrade run \
       --templates \
       -e /home/stack/templates/overcloud_images.yaml \
       -e /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-ansible.yaml \
       -e /home/stack/templates/ceph-customization.yaml \
       -e <ENVIRONMENT FILE>

   以下のオプションの中で、お使いの環境に適切なオプションを追加します。

   • カスタム設定環境ファイル (-e)。以下に例を示します。

     • コンテナーイメージの場所が記載された環境ファイル (overcloud_images.yaml)。アップグレードのコマンドで --container-registry-file の使用に関する警告が表示される場合があることに注意してください。このオプションは非推奨になり、コンテナーイメージの環境ファイルには -e の使用が推奨されるようになっているので、この警告は無視して問題ありません。
     • 該当する場合は、非推奨になった CLI オプションを Heat パラメーターにマッピングする環境ファイル。deprecated_cli_options.yaml を使用します。
     • 該当する場合は、カスタムリポジトリーのスクリプトを指定する環境ファイル。custom_repositories_script.yaml を使用します。
     • Ceph Storage ノード用の関連する環境ファイル
   • カスタムのスタック名を使用する場合には、--stack オプションでその名前を渡します。
   • 該当する場合は、--roles-file でカスタムロール (roles_data) のファイルを指定します。
   • 以下の Ansible Playbook
   • /usr/share/ceph-ansible/infrastructure-playbooks/switch-from-non-containerized-to-containerized-ceph-daemons.yml
   • /usr/share/ceph-ansible/infrastructure-playbooks/rolling_update.yml
4. Ceph Storage ノードのアップグレードが完了するまで待ちます。

手順

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

   $ source ~/stackrc

2. コンピュートノードのアップグレードコマンドを実行します。

   $ openstack overcloud upgrade run --roles Compute
   If using a custom stack name, pass the name with the --stack option.

3. ノードのアップグレードが完了するまで待ちます。

4. ComputeHCI ノードのアップグレードコマンドを実行します。

   $ openstack overcloud upgrade run --roles ComputeHCI
   If using a custom stack name, pass the name with the --stack option.

5. ノードのアップグレードが完了するまで待ちます。

6. Ceph Storage ノードのアップグレードコマンドを実行します。

   $ openstack overcloud upgrade run --roles CephStorage

7. Ceph Storage ノードのアップグレードが完了するまで待ちます。

8. Ceph Storage のアップグレードコマンドを実行します。以下に例を示します。

   $ openstack overcloud ceph-upgrade run \
       --templates \
       -e /home/stack/templates/overcloud_images.yaml \
       -e /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-ansible.yaml \
       -e /home/stack/templates/ceph-customization.yaml \
       -e <ENVIRONMENT FILE>

   以下のオプションの中で、お使いの環境に適切なオプションを追加します。

   • カスタム設定環境ファイル (-e)。以下に例を示します。

     • コンテナーイメージの場所が記載された環境ファイル (overcloud_images.yaml)。アップグレードのコマンドで --container-registry-file の使用に関する警告が表示される場合があることに注意してください。このオプションは非推奨になり、コンテナーイメージの環境ファイルには -e の使用が推奨されるようになっているので、この警告は無視して問題ありません。
     • 該当する場合は、非推奨になった CLI オプションを Heat パラメーターにマッピングする環境ファイル。deprecated_cli_options.yaml を使用します。
     • 該当する場合は、カスタムリポジトリーのスクリプトを指定する環境ファイル。custom_repositories_script.yaml を使用します。
     • Ceph Storage ノード用の関連する環境ファイル
     • お使いの環境に関連する追加の環境ファイル
   • カスタムのスタック名を使用する場合には、--stack オプションでその名前を渡します。
   • 該当する場合は、--roles-file でカスタムロール (roles_data) のファイルを指定します。
   • 以下の Ansible Playbook
   • /usr/share/ceph-ansible/infrastructure-playbooks/switch-from-non-containerized-to-containerized-ceph-daemons.yml
   • /usr/share/ceph-ansible/infrastructure-playbooks/rolling_update.yml
9. Ceph Storage ノードのアップグレードが完了するまで待ちます。

手順

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

   $ source ~/stackrc

2. Fast Forward Upgrade の最終処理のコマンドを実行します。

   $ openstack overcloud ffwd-upgrade converge \
       --templates \
       -e /home/stack/templates/overcloud_images.yaml \
       -e /home/stack/templates/deprecated_cli_options.yaml \
       -e /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-ansible.yaml \
       -e /home/stack/templates/ceph-customization.yaml \
       -e <OTHER ENVIRONMENT FILES>

   以下のオプションの中で、お使いの環境に適切なオプションを追加します。

   • カスタム設定環境ファイル (-e)。以下に例を示します。

     • コンテナーイメージの場所が記載された環境ファイル (overcloud_images.yaml)。アップグレードのコマンドで --container-registry-file の使用に関する警告が表示される場合があることに注意してください。このオプションは非推奨になり、コンテナーイメージの環境ファイルには -e の使用が推奨されるようになっているので、この警告は無視して問題ありません。
     • 該当する場合は、非推奨になった CLI オプションを Heat パラメーターにマッピングする環境ファイル。deprecated_cli_options.yaml を使用します。
     • Ceph Storage ノードを使用する場合には、関連する環境ファイル
     • お使いの環境に関連する追加の環境ファイル
   • カスタムのスタック名を使用する場合には、--stack オプションでその名前を渡します。
   • 該当する場合は、--roles-file でカスタムロール (roles_data) のファイルを指定します。
   重要

   ffwd-upgrade コマンドの実行を確認するプロンプトが表示されます。yes と入力してください。

3. Fast Forward Upgrade の最終処理が完了するまで待ちます。

手順

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. すべてのコントローラーノードおよびコンポーザブルノードについて、上記の手順を繰り返します。

手順

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

   $ sudo ceph osd set noout
   $ sudo ceph osd set norebalance

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

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

   $ sudo reboot

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

5. Ceph MON またはコントローラーノードにログインし、クラスターのステータスを確認します。

   $ sudo ceph -s

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

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

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

   $ sudo ceph osd unset noout
   $ sudo ceph osd unset norebalance

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

   $ sudo ceph status

手順

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

2. 再起動するコンピュートノードを特定するには、すべてのコンピュートノードを一覧表示します。

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

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. コンピュートノードにログインして、リブートします。

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

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

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

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

9. コンピュートノードが有効化されていることを確認します。

   (overcloud) $ openstack compute service list

手順

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

   $ sudo ceph osd set noout
   $ sudo ceph osd set norebalance

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

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

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

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

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

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

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

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

6. 以下のコマンドの 1 つを使用して、インスタンスを移行します。

   1. 選択した特定のホストにインスタンスを移行する。

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

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

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

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

      $ nova host-evacuate-live [hostname]

      注記

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

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

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

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

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

10. Ceph MON またはコントローラーノードにログインし、クラスターのステータスを確認します。

    $ sudo ceph -s

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

11. コンピュート HCI ノードをリブートします。

    $ sudo reboot

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

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

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

14. コンピュートノードが有効化されていることを確認します。

    (overcloud) $ openstack compute service list

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

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

    $ sudo ceph osd unset noout
    $ sudo ceph osd unset norebalance

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

    $ sudo ceph status

手順

1. アンダークラウドのアクセス情報を読み込みます。

   $ source ~/stackrc

2. エラーが発生している Systemd サービスがあるかどうかを確認します。

   (undercloud) $ sudo systemctl list-units --state=failed 'openstack*' 'neutron*' 'httpd' 'docker'

3. アンダークラウドの空き領域を確認します。

   (undercloud) $ df -h

   アンダークラウドの要件 を元に、十分な空き容量があるかどうかを判断します。

4. アンダークラウド上に NTP をインストールしている場合には、クロックが同期されていることを確認します。

   (undercloud) $ sudo ntpstat

5. アンダークラウドのネットワークサービスを確認します。

   (undercloud) $ openstack network agent list

   全エージェントが Alive で、それらの状態が UP である必要があります。

6. アンダークラウドの Compute サービスを確認します。

   (undercloud) $ openstack compute service list

   全エージェントのステータスが enabled で、状態が up である必要があります。

手順

1. アンダークラウドのアクセス情報を読み込みます。

   $ source ~/stackrc

2. ベアメタルノードのステータスを確認します。

   (undercloud) $ openstack baremetal node list

   全ノードの電源状態が有効で (on)、かつメンテナーンスモードが false である必要があります。

3. エラーが発生している Systemd サービスがあるかどうかを確認します。

   (undercloud) $ for NODE in $(openstack server list -f value -c Networks | cut -d= -f2); do echo "=== $NODE ===" ; ssh heat-admin@$NODE "sudo systemctl list-units --state=failed 'openstack*' 'neutron*' 'httpd' 'docker' 'ceph*'" ; done

4. エラーが発生しているコンテナー化されたサービスがあるかどうかを確認します。

   (undercloud) $ for NODE in $(openstack server list -f value -c Networks | cut -d= -f2); do echo "=== $NODE ===" ; ssh heat-admin@$NODE "sudo docker ps -f 'exited=1' --all" ; done
   (undercloud) $ for NODE in $(openstack server list -f value -c Networks | cut -d= -f2); do echo "=== $NODE ===" ; ssh heat-admin@$NODE "sudo docker ps -f 'status=dead' -f 'status=restarting'" ; done

5. 全サービスへの HAProxy 接続をチェックします。コントロールプレーンの仮想 IP アドレスと haproxy.stats サービスの認証情報を取得します。

   (undercloud) $ NODE=$(openstack server list --name controller-0 -f value -c Networks | cut -d= -f2); ssh heat-admin@$NODE sudo 'grep "listen haproxy.stats" -A 6 /var/lib/config-data/puppet-generated/haproxy/etc/haproxy/haproxy.cfg'

   以下の cURL 要求でそれらの情報を使用します。

   (undercloud) $ curl -s -u admin:<PASSWORD> "http://<IP ADDRESS>:1993/;csv" | egrep -vi "(frontend|backend)" | cut -d, -f 1,2,18,37,57 | column -s, -t

   <PASSWORD> および <IP ADDRESS> の詳細を、haproxy.stats サービスからの実際の詳細に置き換えます。その結果表示される一覧には、各ノード上の OpenStack Platform サービスとそれらの接続ステータスが表示されます。

   注記

   ノードが Redis サービスを実行している場合、1 つのノードだけがそのサービスを ON のステータスで表示します。これは、Redis がアクティブ/パッシブのサービスであり、同時に複数のノードでは実行されないためです。

6. オーバークラウドデータベースのレプリケーションの正常性を確認します。

   (undercloud) $ for NODE in $(openstack server list --name controller -f value -c Networks | cut -d= -f2); do echo "=== $NODE ===" ; ssh heat-admin@$NODE "sudo docker exec clustercheck clustercheck" ; done

7. RabbitMQ クラスターの正常性を確認します。

   (undercloud) $ for NODE in $(openstack server list --name controller -f value -c Networks | cut -d= -f2); do echo "=== $NODE ===" ; ssh heat-admin@$NODE "sudo docker exec $(ssh heat-admin@$NODE "sudo docker ps -f 'name=.*rabbitmq.*' -q") rabbitmqctl node_health_check" ; done

8. Pacemaker リソースの正常性を確認します。

   (undercloud) $ NODE=$(openstack server list --name controller-0 -f value -c Networks | cut -d= -f2); ssh heat-admin@$NODE "sudo pcs status"

   以下の点を確認します。

   • 全クラスターノードが online であること
   • いずれのクラスターノード上でも stopped のリソースがないこと
   • pacemaker で failed のアクションがないこと

9. 各オーバークラウドノードでディスク領域を確認します。

   (undercloud) $ for NODE in $(openstack server list -f value -c Networks | cut -d= -f2); do echo "=== $NODE ===" ; ssh heat-admin@$NODE "sudo df -h --output=source,fstype,avail -x overlay -x tmpfs -x devtmpfs" ; done

10. オーバークラウドの Ceph Storage クラスターの正常性を確認します。以下のコマンドを使用すると、コントローラーノード上で ceph ツールが実行されて、クラスターをチェックします。

    (undercloud) $ NODE=$(openstack server list --name controller-0 -f value -c Networks | cut -d= -f2); ssh heat-admin@$NODE "sudo ceph -s"

11. Ceph Storage OSD に空き領域があるかどうかを確認します。以下のコマンドを使用すると、コントローラーノード上で ceph ツールが実行され、空き領域をチェックします。

    (undercloud) $ NODE=$(openstack server list --name controller-0 -f value -c Networks | cut -d= -f2); ssh heat-admin@$NODE "sudo ceph df"

12. オーバークラウドノードでクロックが同期されていることを確認します。

    (undercloud) $ for NODE in $(openstack server list -f value -c Networks | cut -d= -f2); do echo "=== $NODE ===" ; ssh heat-admin@$NODE "sudo ntpstat" ; done

13. オーバークラウドのアクセス情報を読み込みます。

    (undercloud) $ source ~/overcloudrc

14. オーバークラウドのネットワークサービスを確認します。

    (overcloud) $ openstack network agent list

    全エージェントが Alive で、それらの状態が UP である必要があります。

15. オーバークラウドの Compute サービスを確認します。

    (overcloud) $ openstack compute service list

    全エージェントのステータスが enabled で、状態が up である必要があります。

16. オーバークラウドのボリュームサービスを確認します。

    (overcloud) $ openstack volume service list

    全エージェントのステータスが enabled で、状態が up である必要があります。

手順

1. アンダークラウドのアクセス情報を読み込みます。

   $ source ~/stackrc

2. stack ユーザーのホーム下の images ディレクトリー (/home/stack/images) から既存のイメージを削除します。

   $ rm -rf ~/images/*

3. アーカイブを展開します。

   $ cd ~/images
   $ for i in /usr/share/rhosp-director-images/overcloud-full-latest-13.0.tar /usr/share/rhosp-director-images/ironic-python-agent-latest-13.0.tar; do tar -xvf $i; done
   $ cd ~

4. director に最新のイメージをインポートします。

   $ openstack overcloud image upload --update-existing --image-path /home/stack/images/

5. ノードが新しいイメージを使用するように設定します。

   $ openstack overcloud node configure $(openstack baremetal node list -c UUID -f value)

6. 新規イメージが存在することを確認します。

   $ openstack image list
   $ ls -l /httpboot

手順

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

   $ source ~/stackrc

2. お使いのオーバークラウドに関連する全環境ファイルを指定して、デプロイのコマンドを実行します。

   $ openstack overcloud deploy \
       --templates \
       -e <ENVIRONMENT FILE>

   以下のオプションの中で、お使いの環境に適切なオプションを追加します。

   • -e を使用したカスタム設定環境ファイル。
   • 該当する場合は、--roles-file でカスタムロール (roles_data) のファイルを指定します。
3. デプロイメントが完了するまで待ちます。