手順

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

   $ source ~/stackrc

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

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

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

   (undercloud) $ df -h

4. アンダークラウドでクロックが同期されていることを確認します。

   (undercloud) $ sudo ntpstat

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

   (undercloud) $ openstack network agent list

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

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

   (undercloud) $ openstack compute service list

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

7. アンダークラウドのボリュームサービスを確認します。

   (undercloud) $ openstack volume 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. 全サービスへの 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 /etc/haproxy/haproxy.cfg'

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

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

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

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

   (undercloud) $ 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

6. 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 rabbitmqctl node_health_check" ; done

7. 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 のアクションがないこと。

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

   (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

9. オーバークラウドの 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"

10. 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"

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

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

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

    (undercloud) $ source ~/overcloudrc

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

    (overcloud) $ openstack network agent list

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

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

    (overcloud) $ openstack compute service list

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

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

    (overcloud) $ openstack volume service list

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

手順

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

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

   # mysqldump --opt --all-databases > /root/undercloud-all-databases.sql

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

   # tar --xattrs -czf undercloud-backup-`date +%F`.tar.gz /root/undercloud-all-databases.sql /etc/my.cnf.d/server.cnf /srv/node /home/stack /etc/pki/instack-certs/undercloud.pem /etc/pki/ca-trust/source/anchors/ca.crt.pem

   このコマンドにより、undercloud-backup-[timestamp].tar.gz という名前のファイルが作成されます。

手順

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

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

   $ sudo yum update -y python-tripleoclient

3. director は openstack undercloud upgradeコマンドを使用して、アンダークラウドの環境を更新します。以下のコマンドを実行します。

   $ openstack undercloud upgrade

4. ノードを再起動します。

   $ sudo reboot

5. ノードが起動するまで待ちます。

6. 全サービスのステータスを確認します。

   $ sudo systemctl list-units "openstack*" "neutron*" "openvswitch*"

   注記

   再起動後に openstack-nova-compute が有効になるまでに約 10 分かかる場合があります。

7. オーバークラウドとそのノードが存在しているかどうかを確認します。

   $ source ~/stackrc
   $ openstack server list
   $ openstack baremetal node list
   $ openstack stack list

手順

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

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

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

   $ rm -rf ~/images/*

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

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

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

   $ cd ~
   $ 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 " ")

5. 新規イメージの存在をチェックして、イメージの更新を最終確認します。

   $ openstack image list
   $ ls -l /httpboot

   director が更新され、最新のイメージを使用するようになりました。この更新の後にはサービスを再起動する必要はありません。

手順

1. 元の 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 登録用の環境ファイル
   • その他のカスタム環境ファイル

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

   $ openstack overcloud update stack -i overcloud

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

   注記

   全ノードで並行して更新を実行すると問題が発生する可能性があります。たとえば、パッケージの更新には、サービスの再起動が必要となる場合があり、その操作によって他のノードが中断される可能性があります。そのため、このプロセスでは、一連のブレークポイントを設けて、ノードごとに更新します。1 つのノードでパッケージの更新が完了すると、更新プロセスは次のノードに移ります。

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

   not_started: [u'overcloud-controller-0', u'overcloud-controller-1', u'overcloud-controller-2']
   on_breakpoint: [u'overcloud-compute-0']
   Breakpoint reached, continue? Regexp or Enter=proceed, no=cancel update, C-c=quit interactive mode:

   Enter を押すと、on_breakpoint 一覧の最後のノードからブレークポイントを通過します。これで、そのノードの更新が開始します。また、ノード名を入力して特定のノードでブレークポイントを通過したり、複数のノードで一度にブレークポイントを通過するための Python ベースの正規表現を入力することも可能です。ただし、複数のコントローラーノードで同時にブレークポイントを通過することはお勧めしません。全ノードが更新を完了するまで、このプロセスを継続します。

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

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

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

   $ sudo pcs property set stonith-enabled=true

6. 更新プロセスを実行しても、オーバークラウド内のノードは自動的には再起動しません。カーネルまたは Open vSwitch を更新した場合には、再起動が必要です。各ノードの /var/log/yum.log ファイルをチェックして、kernel または openvswitch のパッケージのメジャー/マイナーバージョンが更新されているかどうかを確認します。更新されている場合には、『director インストールと使用方法』ガイドの「ノードの再起動」の手順に従って各ノードを再起動します。