第2章 OpenStack Platform アップグレードの準備

このプロセスでは、OpenStack Platform 環境を準備します。これには、以下のステップを伴います。

  • アンダークラウドとオーバークラウドの両方をバックアップします。
  • アンダークラウドを OpenStack Platform 10 の最新のマイナーバージョンに更新します (最新の Open vSwitch を含む)。
  • 新しいカーネルまたはシステムパッケージがインストールされた場合には、アンダークラウドをリブートします。
  • オーバークラウドを OpenStack Platform 10 の最新のマイナーバージョンに更新します (最新の Open vSwitch を含む)。
  • 新しいカーネルまたはシステムパッケージがインストールされた場合には、オーバークラウドノードをリブートします。
  • アンダークラウドとオーバークラウドの両方で検証のチェックを実行します。

これらの手順により、OpenStack Platform 環境は、アップグレードを開始する前に、最適な状態となります。

2.1. ベアメタルアンダークラウドのバックアップ

完全なアンダークラウドのバックアップには、以下のデータベースおよびファイルが含まれます。

  • アンダークラウドノード上の MariaDB データベース
  • (データベースを正確に復元できるように) アンダークラウド上の MariaDB 設定ファイル
  • 設定データ: /etc
  • ログデータ: /var/log
  • イメージデータ: /var/lib/glance
  • 証明書生成データ (SSL を使用している場合): /var/lib/certmonger
  • コンテナーイメージデータ: /var/lib/docker および /var/lib/registry
  • swift の全データ: /srv/node
  • stack ユーザーのホームディレクトリー内の全データ: /home/stack
注記

バックアッププロセスを実行する前に、アンダークラウドに利用可能なディスク容量が十分にあることを確認します。アーカイブファイルは、少なくとも 3.5 GB となることが予想され、それ以上になる可能性があります。

手順

  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. backup ディレクトリーに移動します。

    [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 ファイルを安全な場所にコピーします。

関連情報

2.2. オーバークラウドのコントロールプレーンサービスのバックアップ

以下の手順では、オーバークラウドのデータベースと設定のバックアップを作成します。オーバークラウドのデータベースとサービスのバックアップにより、稼働環境のスナップショットが確保されます。スナップショットがあると、操作のエラーが発生してオーバークラウドを元の状態に復元する必要がある場合に役立ちます。

重要

この手順では、不可欠なコントロールプレーンサービスのみが含まれます。コンピュートノードのワークロード、Ceph Storage ノード上のデータ、追加のサービスのバックアップは対象外です。

手順

  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 ファイルを安全な場所にコピーします。

関連情報

2.3. 現在のアンダークラウドパッケージの OpenStack Platform 10.z の更新

director では、アンダークラウドノード上のパッケージを更新するためのコマンドが提供されています。これにより、OpenStack Platform 環境の現行バージョン内のマイナーアップデートを実行することができます。これは、OpenStack Platform 10 内でのマイナー更新です。

注記

このステップにより、アンダークラウドのオペレーティングシステムも Red Hat Enterprise Linux 7 の最新バージョンに更新され、Open vSwitch はバージョン 2.9 となります。

手順

  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 ユーザーとしてログインします。

アンダークラウドのパッケージの更新に加えて、オーバークラウドのイメージを最新の状態に維持して、イメージの設定が最新の openstack-tripleo-heat-template パッケージと同期することを推奨します。これにより、現在の準備段階と実際の Fast Foward Upgrade の間に実行されるデプロイメントとスケーリングの操作が正常に実行されるようになります。次の項では、このシナリオでイメージを更新する方法について説明します。環境を準備した直後に環境のアップグレードを行う予定の場合には、次の項はスキップできます。

2.4. NFV 対応環境の更新準備

お使いの環境でネットワーク機能仮想化 (NFV) が有効化されている場合には、アンダークラウドの更新後およびオーバークラウドの更新前に以下のステップを実行します。

手順

  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」を参照してください。

2.5. 現在のオーバークラウドイメージの OpenStack Platform 10.z の更新

アンダークラウドの更新プロセスで、rhosp-director-images および rhosp-director-images-ipa パッケージから新規イメージアーカイブがダウンロードされる可能性があります。このプロセスにより、Red Hat OpenStack Platform 10 内のアンダークラウドでそれらのイメージが更新されます。

前提条件

  • アンダークラウドを現行バージョンの最新のマイナーリリースに更新済みであること

手順

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

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

アンダークラウドでは、更新された OpenStack Platform 10 のパッケージが使用されるようになりました。次にオーバークラウドを最新のマイナーリリースに更新します。

2.6. 現在のオーバークラウドパッケージの OpenStack Platform 10.z の更新

director では、全オーバークラウドノード上のパッケージを更新するためのコマンドが提供されています。これにより、OpenStack Platform 環境の現行バージョン内のマイナーアップデートを実行することができます。これは、Red Hat OpenStack Platform 10 内でのマイナー更新です。

注記

このステップにより、オーバークラウドノードのオペレーティングシステムも Red Hat Enterprise Linux 7 の最新バージョンに更新され、Open vSwitch はバージョン 2.9 となります。

前提条件

  • アンダークラウドを現行バージョンの最新のマイナーリリースに更新済みであること
  • オーバークラウドのバックアップを実行済みであること

手順

  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

更新プロセスを実行しても、オーバークラウド内のノードは自動的には再起動しません。カーネルおよびその他のシステムッケージを更新した場合には、リブートが必要です。各ノードの /var/log/yum.log ファイルをチェックして、kernel または openvswitch パッケージのメジャーまたはマイナーバージョンが更新されているかどうかを確認します。更新されている場合には、以下の手順に従って各ノードをリブートします。

2.7. コントローラーノードおよびコンポーザブルノードのリブート

以下の手順では、コントローラーノードと、コンポーザブルロールをベースとするスタンドアロンのノードをリブートします。これには、コンピュートノードと Ceph Storage ノードは含まれません。

手順

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

2.8. Ceph Storage (OSD) クラスターのリブート

以下の手順では、Ceph Storage (OSD) ノードのクラスターをリブートします。

手順

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

    $ sudo ceph osd set noout
    $ sudo ceph osd set norebalance
  2. リブートする最初の Ceph Storage ノードを選択して、ログインします。
  3. ノードをリブートします。

    $ sudo reboot
  4. ノードがブートするまで待ちます。
  5. ノードにログインして、クラスターのステータスを確認します。

    $ sudo ceph -s

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

  6. ノードからログアウトして、次のノードをリブートし、ステータスを確認します。全 Ceph Storage ノードがリブートされるまで、このプロセスを繰り返します。
  7. 完了したら、Ceph MON またはコントローラーノードにログインして、クラスターのリバランスを再度有効にします。

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

    $ sudo ceph status

2.9. コンピュートノードのリブート

コンピュートノードをリブートするには、以下のワークフローを実施します。

  • リブートするコンピュートノードを選択して無効にし、新規インスタンスをプロビジョニングしないようにする。
  • インスタンスのダウンタイムを最小限に抑えるために、インスタンスを別のコンピュートノードに移行する。
  • 空のコンピュートノードをリブートして有効にする。

手順

  1. アンダークラウドに stack ユーザーとしてログインします。
  2. リブートするコンピュートノードの UUID を特定するには、全コンピュートノードを一覧表示します。

    $ 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

2.10. システムパッケージの確認

アップグレードの前には、アンダークラウドノードと全オーバークラウドノードが、以下のパッケージの最新バージョンを使用している必要があります。

パッケージバージョン

openvswitch

2.9 以降

qemu-img-rhev

2.10 以降

qemu-kvm-common-rhev

2.10 以降

qemu-kvm-rhev

2.10 以降

qemu-kvm-tools-rhev

2.10 以降

手順

  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. すべてのノードでこれらのステップを繰り返します。

アンダークラウドは、更新された OpenStack Platform 10 パッケージを使用するようになりました。次の手順で、システムが稼動状態かどうかを確認します。

2.11. OpenStack Platform 10 アンダークラウドの検証

Red Hat OpenStack Platform 10 のアンダークラウドをアップグレードする前に機能を確認するステップを以下に示します。

手順

  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 である必要があります。

関連情報

2.12. OpenStack Platform 10 オーバークラウドの検証

Red Hat OpenStack Platform 10 のオーバークラウドをアップグレードする前に機能を確認するステップを以下に示します。

手順

  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'

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

    $ 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. オーバークラウドデータベースのレプリケーションの正常性を確認します。

    $ 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 クラスターの正常性を確認します。

    $ 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 リソースの正常性を確認します。

    $ 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. 各オーバークラウドノードでディスク領域を確認します。

    $ 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 ツールが実行されて、クラスターをチェックします。

    $ 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 ツールが実行され、空き領域をチェックします。

    $ 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」を参照してください。

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

    $ for NODE in $(openstack server list -f value -c Networks | cut -d= -f2); do echo "=== $NODE ===" ; ssh heat-admin@$NODE "sudo ntpstat" ; done
  12. オーバークラウドのアクセス情報を読み込みます。

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

    $ openstack network agent list

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

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

    $ openstack compute service list

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

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

    $ openstack volume service list

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

関連情報

2.13. NFV 対応環境の更新の最終処理

お使いの環境でネットワーク機能仮想化 (NFV) が有効化されている場合には、アンダークラウドとオーバークラウドを更新した後に、以下のステップを実行する必要があります。

手順

既存の OVS-DPDK インスタンスを移行して、OVS ポートで vhost ソケットモードが dkdpvhostuser から dkdpvhostuserclient に変わることを確認します。既存のインスタンスのスナップショットを作成して、そのスナップショットイメージをベースに新規インスタンスを再ビルドすることを推奨します。インスタンスのスナップショットに関する詳細は、「インスタンスのスナップショットの管理」を参照してください。

インスタンスのスナップショットを作成して、そのスナップショットから新規インスタンスを起動するには、以下の手順を実行します。

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

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

    # openstack server stop SERVER_ID
  3. インスタンスのスナップショットイメージを作成します。

    # openstack image create --id SERVER_ID SNAPSHOT_NAME
  4. このスナップショットイメージで新規インスタンスを起動します。

    # openstack server create --flavor DPDK_FLAVOR --nic net-id=DPDK_NET_ID--image SNAPSHOT_NAME INSTANCE_NAME
  5. オプションとして、新規インスタンスのステータスが ACTIVE であることを確認します。

    # openstack server list

スナップショットを作成する必要のある全インスタンスでこの手順を繰り返してから、再起動します。

2.14. yum 履歴の保持

オーバークラウドのマイナーアップデートが完了したら、yum 履歴を保持します。ロールバック操作のために yum トランザクションを元に戻す必要がある場合に、この情報が役立ちます。

手順

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

    # sudo yum history list all > /home/heat-admin/$(hostname)-yum-history-all
  2. それぞれのノードで以下のコマンドを実行して、最後の yum 履歴項目の ID を保存します。

    # yum history list all | head -n 5 | tail -n 1 | awk '{print $1}' > /home/heat-admin/$(hostname)-yum-history-all-last-id
  3. これらのファイルを安全な場所にコピーします。

2.15. 次のステップ

準備段階が完了したので、次に「3章アンダークラウドのアップグレード」に記載のステップに従って、アンダークラウドを 10 から 13 にアップグレードします。