手順

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 インストールと使用方法』ガイドの「ノードの再起動」の手順に従って各ノードを再起動します。

手順

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

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

   $ sudo yum update -y python-tripleoclient

5. /home/stack/undercloud.conf ファイルを編集して、enabled_drivers パラメーターに pxe_ssh ドライバーが含まれていないことを確認します。Virtual Baseboard Management Controller (VBMC) が推奨されるようになったため、このドライバーは非推奨となり、Red Hat OpenStack Platform から削除されました。pxe_ssh ノードを VBMC に切り替えるための説明は、『director のインストールと使用方法』ガイドの「Virtual Baseboard Management Controller (VBMC)」の項を参照してください。

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

   $ openstack undercloud upgrade

   このコマンドにより、director のパッケージがアップグレードされ、director の設定が最新の状態に更新されて、バージョンの変更後に指定されていない設定内容が追加されます。このコマンドによって、オーバークラウドのスタックデータや環境内の既存のノードのデータなど、保存されたデータは削除されません。

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

   $ sudo reboot

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

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

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

   注記

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

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

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

手順

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

   $ rm -rf ~/images/*

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

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

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

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

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

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

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

   $ openstack image list
   $ ls -l /httpboot

手順

1. openstack-tripleo-heat-templates-compat パッケージをインストールします。

   $ sudo yum install openstack-tripleo-heat-templates-compat

   これにより、Heat テンプレートコレクションの compat ディレクトリー (/usr/share/openstack-tripleo-heat-templates/compat) に以前のテンプレートがインストールされ、以前のバージョン (ocata) から命名された compat へのリンクが作成されます。これらのテンプレートは、アップグレードされた director との後方互換性があるので、最新バージョンの director を使用して以前のバージョンのオーバークラウドをインストールすることができます。

2. コア Heat テンプレートの一時的なコピーを作成します。

   $ cp -a /usr/share/openstack-tripleo-heat-templates /tmp/osp12

3. 以前のバージョンをそれ独自のディレクトリーに移動します。

   $ mv /tmp/osp12/compat /tmp/osp11

4. 両ディレクトリーのコンテンツに対して diff を実行します。

   $ diff -urN /tmp/osp11 /tmp/osp12

   このコマンドにより、バージョン間におけるコアテンプレートの変更が表示されます。この内容を確認すると、オーバークラウドのアップグレード中にどのような動作が行われるかがわかります。

手順

1. 登録情報が記載された環境ファイルを編集します。以下に例を示します。

   $ vi ~/templates/rhel-registration/environment-rhel-registration.yaml

2. 以下のパラメーター値を編集します。

   rhel_reg_repos

   Red Hat OpenStack Platform 12 の新しいリポジトリーが含まれるように更新します。

   rhel_reg_activation_key

   Red Hat OpenStack Platform 12 のリポジトリーにアクセスするためのアクティベーションキーを更新します。

   rhel_reg_sat_repo

   Red Hat Satellite 6 のより新しいバージョンを使用する場合には、Satellite 6 の管理ツールが含まれているリポジトリーを更新します。

3. 環境ファイルを保存します。

手順

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

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

2. ストレージの環境ファイルで、最新のリソースと設定を使用するようにします。これは、以下のように変更する必要があります。

   1. resource_registry はコア Heat テンプレートコレクションの docker/services サブディレクトリーからコンテナー化されたサービスを使用します。以下に例を示します。

1. 新しい CephAnsibleDisksConfig パラメーターを使用して、ディスクのマッピングの方法を定義します。以前のバージョンの Red Hat OpenStack Platform では、ceph::profile::params::osds hieradata を使用して OSD レイアウトを定義していました。この hieradata を CephAnsibleDisksConfig パラメーターの構成に変換します。たとえば、hieradata に以下の内容が記載されているとします。

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

   この場合には、CephAnsibleDisksConfig は以下のようになります。

   parameters_default:
     CephAnsibleDisksConfig:
       devices:
       - /dev/sdb
       - /dev/sdc
       - /dev/sdd
       journal_size: 512
       osd_scenario: collocated

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

手順

1. Ceph Storage の設定が含まれた環境ファイルを編集します。

2. resource_registry が Puppet リソースを使用するように設定します。以下に例を示します。

   resource_registry:
     OS::TripleO::Services::CephMon: ../puppet/services/ceph-mon.yaml
     OS::TripleO::Services::CephOSD: ../puppet/services/ceph-osd.yaml
     OS::TripleO::Services::CephClient: ../puppet/services/ceph-client.yaml

   注記

   /usr/share/openstack-tripleo-heat-templates/environments/puppet-ceph.yaml の内容を例として使用します。

3. 「オーバークラウドノードのアップグレード」の手順に従って、コントローラーベースのノードをコンテナー化されたサービスにアップグレードします。
4. 「コンピュートノードのアップグレード」の手順に従って HCI ノードをアップグレードします。

5. Ceph Storage 設定の resource_registry を編集して、コンテナー化されたサービスを使用するようにします。

   resource_registry:
     OS::TripleO::Services::CephMon: ../docker/services/ceph-ansible/ceph-mon.yaml
     OS::TripleO::Services::CephOSD: ../docker/services/ceph-ansible/ceph-osd.yaml
     OS::TripleO::Services::CephClient: ../docker/services/ceph-ansible/ceph-client.yaml

   注記

   /usr/share/openstack-tripleo-heat-templates/environments/storage-environment.yaml の内容を例として使用します。

6. ストレージの環境ファイルの parameter_defaults セクションにCephAnsiblePlaybook パラメーターを追加します。

     CephAnsiblePlaybook: /usr/share/ceph-ansible/infrastructure-playbooks/switch-from-non-containerized-to-containerized-ceph-daemons.yml

7. ストレージの環境ファイルの parameter_defaults セクションにCephAnsibleDisksConfig パラメーターを追加して、ディスクレイアウトを定義します。以下に例を示します。

     CephAnsibleDisksConfig:
       devices:
       - /dev/vdb
       - /dev/vdc
       - /dev/vdd
       journal_size: 512
       osd_scenario: collocated

8. 「アップグレードの最終処理」の手順に従って、オーバークラウドのアップグレードの最終処理を実行します。

手順

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
     tasks:
       - name: Copy undercloud CA
         copy:
           src: ca.crt.pem
           dest: /etc/pki/ca-trust/source/anchors/
       - name: Update trust
         command: "update-ca-trust extract"
       - name: Get the hostname of the undercloud
         delegate_to: 127.0.0.1
         command: hostname
         register: undercloud_hostname
       - name: Verify URL
         uri:
           url: https://{{ undercloud_hostname.stdout }}:13808/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 には複数のタスクが含まれており、各ノードで以下の操作を実行します。

   • アンダークラウドの認証局のファイル (ca.crt.pem) をオーバークラウドノードにコピーします。このファイルの名前と場所は、設定によって異なる場合があります。この例では、自己署名証明書の手順 (『director のインストールと使用方法』の「SSL/TLS 証明書の設定」を参照) で定義された名前と場所を使用しています。
   • オーバークラウドノードで、CA トラストデータベースを更新するコマンドを実行します。
   • オーバークラウドノードから、アンダークラウドの Object Storage Public API をチェックして、成功したかどうかを報告します。

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

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

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

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

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

手順

1. 以下のコマンドを実行して、OVERCLOUD_HOSTS 環境変数内のノードの IP アドレスの一覧を保存します。

   $ 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. アップグレードを開始します。

4. コンピュートノードまたは 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. parameter_defaults セクションで、アップグレードプロセス中に os-net-config を実行して、OVS 2.7 PCI アドレスを DPDK ポートに関連付けするためのするためのネットワークデプロイメントパラメーターを追加します。

   parameter_defaults:
     ComputeNetworkDeploymentActions: ['CREATE', 'UPDATE']

   パラメーター名は、DPDK のデプロイに使用するロール名と一致する必要があります。この例では、ロール名は Compute なので、パラメーター名は ComputeNetworkDeploymentActions となっています。

   注記

   初回のアップグレードの後には、このパラメーターは必要ないので、環境ファイルから削除すべきです。

2. resource_registry セクションで、ComputeNeutronOvsAgent サービスを neutron-ovs-dpdk-agent puppet サービスに上書きします。

   resource_registry:
     OS::TripleO::Services::ComputeNeutronOvsAgent: /usr/share/openstack-tripleo-heat-templates/puppet/services/neutron-ovs-dpdk-agent.yaml

   Red Hat OpenStack Platform 12 は、新しい　ComputeOvsDpdk ロールの追加をサポートするための新しいサービス (OS::TripleO::Services::ComputeNeutronOvsDpdk) を追加しました。上記の例では、このサービスをアップグレード向けに外部にマッピングしています。

手順

1. openstack overcloud deploy コマンドに以下の項目を指定して実行します。

   • ネットワーク分離やストレージなど、お使いの環境に関連したすべてのオプションおよびカスタムの環境ファイル
   • 「アップグレードの最終処理」で生成された overcloud_images.yaml 環境ファイル

   • major-upgrade-composable-steps-docker.yaml 環境ファイル

     以下に例を示します。

   $ openstack overcloud deploy --templates \
     -e /home.stack/templates/node_count.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 \
     -e /home/stack/templates/network_environment.yaml \
     -e /home/stack/templates/overcloud_images.yaml  \
     -e /usr/share/openstack-tripleo-heat-templates/environments/major-upgrade-composable-steps-docker.yaml \
     --ntp-server pool.ntp.org

2. 新しい環境ファイルの設定でオーバークラウドが更新されるまで待ちます。

   重要

   アップグレードにより OpenStack Networking (neutron) サーバーと L3 エージェントが無効化されるので、このステップの実行中には新規ルーターの作成はできません。この間には、インスタンスへのアクセスは引き続き可能です。

3. 全サービスがアクティブかどうかを確認します。たとえば、コントローラーノード上のサービスを確認するには、以下のコマンドを実行します。

   [stack@director ~]$ ssh heat-admin@192.168.24.10
   [heat-admin@overcloud-controller-0 ~]$ sudo pcs status
   [heat-admin@overcloud-controller-0 ~]$ sudo docker ps

手順

1. Object Storage ノードの一覧を取得します。

   $ openstack server list -c Name -f value --name objectstorage

2. 一覧内の各 Object Storage ノードで以下のステップを実行します。

   1. アップグレードするノードを特定するためのノード名を使用して upgrade-non-controller.sh スクリプトを実行します。

      $ upgrade-non-controller.sh --upgrade overcloud-objectstorage-0

      注記

      事前にプロビジョニング済みのノードインフラストラクチャーを使用している場合には、このコマンドでの変更について、「アップグレードの最終処理」を参照してください。

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

   3. Object Storage ノードを再起動します。

      $ openstack server reboot overcloud-objectstorage-0

   4. Object Storage ノードの再起動が完了するまで待ちます。

1. アップグレードするコンピュートノードの選択
2. 別のコンピュートノードへの移行
3. 空のコンピュートノードのアップグレード
4. アップグレードしたコンピュートノードの再起動と有効化

1. 全コンピュートノードを一覧表示します。

   $ source ~/stackrc
   $ openstack server list -c Name -f value --name compute

2. アップグレードするコンピュートノードを選択して、UUID と名前を書き留めておきます。

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

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

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

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

3. 以下のコマンドの 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 コマンドで非推奨の警告が表示される可能性がありますが、安全に無視することができます。

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

5. 正常に移行したことを確認します。

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

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

1. アップグレードするノードを特定するためのノード名を使用して upgrade-non-controller.sh スクリプトを実行します。

   $ upgrade-non-controller.sh --upgrade overcloud-compute-0

   注記

   事前にプロビジョニング済みのノードインフラストラクチャーを使用している場合には、このコマンドでの変更について、「アップグレードの最終処理」を参照してください。

2. コンピュートノードのアップグレードが完了するまで待ちます。

1. コンピュートノードにログインして、再起動します。

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

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

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

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

4. コンピュートノードが有効化されているかどうかを確認します。

   (overcloud) $ openstack compute service list

手順

1. openstack overcloud deploy コマンドに以下の項目を指定して実行します。

   • ネットワーク分離やストレージなど、お使いの環境に関連したすべてのオプションおよびカスタムの環境ファイル
   • 「アップグレードの最終処理」で生成された overcloud_images.yaml 環境ファイル

   • major-upgrade-converge-docker.yaml 環境ファイル

     以下に例を示します。

   $ openstack overcloud deploy --templates \
     -e /home.stack/templates/node_count.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 \
     -e /home/stack/templates/network_environment.yaml \
     -e /home/stack/templates/overcloud_images.yaml  \
     -e /usr/share/openstack-tripleo-heat-templates/environments/major-upgrade-converge-docker.yaml \
     --ntp-server pool.ntp.org

2. 新しい環境ファイルの設定でオーバークラウドが更新されるまで待ちます。

3. 全サービスがアクティブかどうかを確認します。たとえば、コントローラーノード上のサービスを確認するには、以下のコマンドを実行します。

   [stack@director ~]$ ssh heat-admin@192.168.24.10
   [heat-admin@overcloud-controller-0 ~]$ sudo pcs status
   [heat-admin@overcloud-controller-0 ~]$ sudo systemctl list-units 'openstack-*' 'neutron-*' 'httpd*'

手順

1. 環境ファイルを新規作成するか、既存のファイルを編集します。この例では undercloud-ca-map.yaml というファイル名を使用しています。

2. 環境ファイルの parameter_defaults セクションに CAMap パラメーターを追加します。以下の構文を例として使用してください。

   parameter_defaults:
     CAMap:
       undercloud-ca: 1
         content: | 2
           -----BEGIN CERTIFICATE-----
           MIIDlTCCAn2gAwIBAgIJAOnPtx2hHEhrMA0GCSqGSIb3D
           BAYTAlVTMQswCQYDVQQIDAJOQzEQMA4GA1UEBwwHUmFsZ
           UmVkIEhhdDELMAkGA1UECwwCUUUxFDASBgNVBAMMCzE5M
           ...
           ...
           -----END CERTIFICATE-----

   1

   これは、各オーバークラウドノードのトラストデータベースで CA を識別する名前です。

   2

   content セクションは、実際の CA 証明書です。このセクションに CA の内容をコピーして貼り付けます。CA の ID が YAML 構文の要件に合っていることを確認してください。

3. このファイルを保存します。
4. このファイルは、 openstack overcloud deploy コマンドを次回に実行する際に指定してください。

手順

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. エラーが発生しているコンテナー化されたサービスがあるかどうかを確認します。

   (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)" | awk -F',' '{ print $1" "$2" "$18 }'

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

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. 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-12.0.tar /usr/share/rhosp-director-images/ironic-python-agent-latest-12.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 container image tag discover \
     --image registry.access.redhat.com/rhosp12/openstack-base:latest \
     --tag-from-label version-release

   最も新しいタグを書き留めておきます。

2. openstack overcloud container image prepare コマンドで、コンテナーイメージのソース用の更新された環境ファイルを作成します。たとえば、registry.access.redhat.com からのイメージを使用する場合は、以下のコマンドを実行します。

   $ openstack overcloud container image prepare \
     --namespace=registry.access.redhat.com/rhosp12 \
     --prefix=openstack- \
     --tag [TAG] \ 1
     --set ceph_namespace=registry.access.redhat.com/rhceph \
     --set ceph_image=rhceph-2-rhel7 \
     --set ceph_tag=latest \
     --env-file=/home/stack/templates/overcloud_images.yaml \
     -e /home/stack/templates/custom_environment_file.yaml 2

   1

   [TAG] の箇所は、前のステップで取得したタグに置き換えます。

   2

   -e パラメーターで追加の環境ファイルを指定します。 director は指定されているすべての環境ファイルでカスタムリソースを確認して、コンテナー化されたサービスに必要なコンテナーイメージを特定します。

   この環境ファイルを異なるソース種別用に生成する方法についての詳しい情報は、『director のインストールと使用方法』ガイドの「コンテナーレジストリー情報の設定」を参照してください。

3. openstack overcloud update stack コマンドを実行して、オーバークラウド内のコンテナーイメージの場所を更新します。

   $ openstack overcloud update stack --init-minor-update \
     --container-registry-file /home/stack/templates/overcloud_images.yaml

   --init-minor-update はオーバークラウドスタック内のパラメーターの更新のみを実行します。実際のパッケージやコンテナーの更新は行いません。このコマンドが完了するまで待ちます。

4. openstack overcloud update コマンドを使用してパッケージとコンテナーの更新を実行します。--nodes オプションを使用して、各ロールのノードをアップグレードします。たとえば、以下のコマンドは、Controller ロールのノードを更新します。

   $ openstack overcloud update stack --nodes Controller

   以下の順序で、各ロールグループにこのコマンドを実行します。

   • Controller
   • CephStorage
   • Compute
   • ObjectStorage
   • Database、MessageBus、Networker などのカスタムのロール
5. 選択したロールの更新プロセスが開始します。director は Ansible playbook を使用して更新を実行し、各タスクの出力を表示します。
6. 次のロールグループを更新します。全ノードの更新が完了するまで作業を繰り返してください。
7. 更新プロセスを実行しても、オーバークラウド内のノードは自動的には再起動しません。カーネルまたは Open vSwitch を更新した場合には、再起動が必要です。各ノードの /var/log/yum.log ファイルをチェックして、kernel または openvswitch のパッケージのメジャー/マイナーバージョンが更新されているかどうかを確認します。更新されている場合には、『director インストールと使用方法』ガイドの「ノードの再起動」の手順に従って各ノードを再起動します。