Red Hat OpenStack Platform のアップグレード

手順

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 --ignore-failed-read -cf \
       undercloud-backup-`date +%F`.tar \
       /etc \
       /var/log \
       /var/lib/glance \
       /var/lib/certmonger \
       /srv/node \
       /root \
       /home/stack

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

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

手順

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

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

      $ ssh heat-admin@192.0.2.100

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

      $ sudo -i

   3. まだ mariadb クライアントツールがインストールされていない場合には、それらのツールをインストールします。

      # dnf install mariadb

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

      # mkdir -p /var/tmp/mysql_backup/

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

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

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

      # 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> はシステムの日付と時刻になります。このデータベースダンプを安全な場所にコピーします。

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

      # 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. 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/ ディレクトリーに保管されます。このデータベースダンプを安全な場所にコピーします。

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

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

      # mkdir -p /var/tmp/filesystem_backup/

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

      # tar --ignore-failed-read --xattrs \
          -zcvf /var/tmp/filesystem_backup/fs_backup-`date '+%Y-%m-%d-%H-%M-%S'`.tar.gz \
          /var/lib/kolla \
          /var/lib/config-data \
          /var/log/containers \
          /var/log/openvswitch \
          /etc \
          /srv/node \
          /root \
          /home/heat-admin

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

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

手順

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

   $ source ~/stackrc

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

   (undercloud) $ sudo systemctl list-units --state=failed 'tripleo_*'

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

   (undercloud) $ df -h

   『Director Installation and Usage』の「Undercloud Reqirements」 を元に、十分な空き容量があるかどうかを判断します。

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

   (undercloud) $ sudo chronyc -a 'burst 4/4'

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 'tripleo_*' '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 podman ps -f 'exited=1' --all" ; 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

   &lt ;PASSWORD&gt; および <IP ADDRESS& gt; の情報を 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 podman exec clustercheck clustercheck" ; 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 chronyc -a 'burst 4/4'" ; 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. 有効なハードウェアタイプの最新の一覧を確認します。

   $ source ~/stackrc
   $ openstack baremetal driver list --type dynamic

2. 有効ではないハードウェアタイプのドライバーを使用する場合には、undercloud.conf ファイルの enabled_hardware_types パラメーターを使用してそのドライバーを有効にします。

   enabled_hardware_types = ipmi,redfish,idrac

3. ファイルを保存し、アンダークラウドをリフレッシュします。

   $ openstack undercloud install

4. 以下のコマンドを実行します。OLDDRIVER および NEWDRIVER 変数を、実際の電源管理タイプに置き換えてください。

   $ source ~/stackrc
   $ OLDDRIVER="pxe_ipmitool"
   $ NEWDRIVER="ipmi"
   $ for NODE in $(openstack baremetal node list --driver $OLDDRIVER -c UUID -f value) ; do openstack baremetal node set $NODE --driver $NEWDRIVER; done

手順

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

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

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

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

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

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

   $ sudo dnf update -y python-tripleoclient* openstack-tripleo-common openstack-tripleo-heat-templates

手順

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

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

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

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

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

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

     注記

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

3. containers-prepare-parameter.yaml を編集し、要求に合わせて変更を加えます。

手順

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

   $ openstack undercloud upgrade

   このコマンドにより、director の設定スクリプトが起動します。director によりパッケージがアップグレードされ、undercloud.conf の設定に合わせてサービスが設定されます。このスクリプトは、完了までに数分かかります。

   注記

   director の設定スクリプトでは、次の設定に進む前に確認が求められます。この確認を省略するには、-y オプションを使用します。

   $ openstack undercloud upgrade -y

2. このスクリプトにより、アンダークラウド上の OpenStack Platform サービスのコンテナーも、すべて自動的に起動されます。以下のコマンドを使用して、有効化されたコンテナーを確認してください。

   [stack@director ~]$ sudo docker ps

3. スクリプトにより stack ユーザーが docker グループに追加され、stack ユーザーがコンテナー管理コマンドを使用できるようになります。以下のコマンドで stack ユーザーのアクセス権限をリフレッシュします。

   [stack@director ~]$ exec su -l stack

   このコマンドを実行すると、再度ログインが求められます。stack ユーザーのパスワードを入力します。

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

   [stack@director ~]$ source ~/stackrc

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

   (undercloud) [stack@director ~]$

手順

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

   $ rm -rf ~/images/*

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

   $ cd ~/images
   $ for i in /usr/share/rhosp-director-images/overcloud-full-latest-14.0.tar /usr/share/rhosp-director-images/ironic-python-agent-latest-14.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 /var/lib/ironic/httpboot/

手順

1. rhel-registration 環境ファイルは、今後のデプロイメント操作から除外します。通常は、以下のファイルを除外します。

   • rhel-registration/environment-rhel-registration.yaml
   • rhel-registration/rhel-registration-resource-registry.yaml

2. カスタムの roles_data ファイルを使用する場合には、roles_data ファイルの各ロールに必ず OS::TripleO::Services::Rhsm コンポーザブルサービスを含めてください。以下に例を示します。

   - name: Controller
     description: |
       Controller role that has all the controller services loaded and handles
       Database, Messaging and Network functions.
     CountDefault: 1
     ...
     ServicesDefault:
       ...
       - OS::TripleO::Services::Rhsm
       ...

3. rhsm コンポーザブルサービスのパラメーター用の環境ファイルを今後のデプロイメント操作に追加します。

手順

1. director のコアテンプレートコレクションに切り替えます。

   $ cd /usr/share/openstack-tripleo-heat-templates

2. tools ディレクトリーの merge-new-params-nic-config-script.py python スクリプトを実行します。たとえば、コントローラーノードのカスタム NIC テンプレートを更新するには、以下のオプションを指定してスクリプトを実行します。

   $ python ./tools/merge-new-params-nic-config-script.py --role-name Controller -t /home/stack/ccsosp-templates/custom-nics/controller.yaml

   このスクリプトで使用する以下のオプションに留意してください。

   • --role-name: テンプレート更新のベースとして使用するロールの名前を定義します。
   • -t、--template: 更新する NIC テンプレートのファイル名を定義します。
   • -n、--network-data: network_data ファイルへの相対パスを定義します。カスタムの network_data ファイルの場合に、このオプションを使用します。省略した場合には、スクリプトはデフォルトのファイルを使用します。
   • -r、--roles-data: roles_data.yaml ファイルへの相対パスを定義します。カスタムの roles_data ファイルの場合に、このオプションを使用します。省略した場合には、スクリプトはデフォルトのファイルを使用します。

3. スクリプトは元のテンプレートのコピーを保存し、コピーのファイル名にタイムスタンプの拡張子を追加します。元のテンプレートと更新されたテンプレートの違いを比較するには、以下のコマンドを実行します。

   $ diff /home/stack/ccsosp-templates/custom-nics/controller.yaml.[TIMESTAMP] /home/stack/ccsosp-templates/custom-nics/controller.yaml

   [TIMESTAMP] を元のファイル名のタイムスタンプに置き換えます。

   出力に、そのロールの新しいルートパラメーターが表示されます。

   StorageMgmtInterfaceRoutes:
     default: []
     description: >
       Routes for the storage_mgmt network traffic. JSON route e.g. [{'destination':'10.0.0.0/16', 'nexthop':'10.0.0.1'}] Unless
       the default is changed, the parameter is automatically resolved from the subnet host_routes attribute.
     type: json
   TenantInterfaceRoutes:
     default: []
     description: >
       Routes for the tenant network traffic. JSON route e.g. [{'destination':'10.0.0.0/16', 'nexthop':'10.0.0.1'}] Unless
       the default is changed, the parameter is automatically resolved from the subnet host_routes attribute.
     type: json
   ExternalInterfaceRoutes:
     default: []
     description: >
       Routes for the external network traffic. JSON route e.g. [{'destination':'10.0.0.0/16', 'nexthop':'10.0.0.1'}] Unless
       the default is changed, the parameter is automatically resolved from the subnet host_routes attribute.
     type: json
   InternalApiInterfaceRoutes:
     default: []
     description: >
       Routes for the internal_api network traffic. JSON route e.g. [{'destination':'10.0.0.0/16', 'nexthop':'10.0.0.1'}] Unless
       the default is changed, the parameter is automatically resolved from the subnet host_routes attribute.
     type: json
   ManagementInterfaceRoutes:
     default: []
     description: >
       Routes for the management network traffic. JSON route e.g. [{'destination':'10.0.0.0/16', 'nexthop':'10.0.0.1'}] Unless
       the default is changed, the parameter is automatically resolved from the subnet host_routes attribute.
     type: json
   StorageInterfaceRoutes:
     default: []
     description: >
       Routes for the storage network traffic. JSON route e.g. [{'destination':'10.0.0.0/16', 'nexthop':'10.0.0.1'}] Unless
       the default is changed, the parameter is automatically resolved from the subnet host_routes attribute.
     type: json

手順

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

   $ source ~/stackrc

2. upgrade prepare コマンドを実行します。

   $ openstack overcloud upgrade prepare \
       --templates \
       -e /home/stack/containers-prepare-parameter.yaml \
       -e <ENVIRONMENT FILE>

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

   • カスタム設定環境ファイル (-e)
   • 新しいコンテナーイメージの場所を定義した環境ファイル (containers-prepare-parameter.yaml) (-e)。多くの場合、アンダークラウドが使用する環境ファイルと同じファイルです。
   • 該当する場合は、--roles-file でカスタムロール (roles_data) ファイルを指定します。
   • 該当する場合は、--networks-file でコンポーザブルネットワーク (network_data) ファイルを指定します。
   • カスタムのスタック名を使用する場合は、--stack オプションでその名前を渡します。
3. アップグレードの準備が完了するまで待ちます。

手順

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

   $ source ~/stackrc

2. container_image_prepare にタグ付けされたタスクに対して openstack overcloud external-upgrade run コマンドを実行します。

   $ openstack overcloud external-upgrade run --tags container_image_prepare

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

手順

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

   $ source ~/stackrc

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

   $ openstack overcloud upgrade run --nodes Controller

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

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

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

手順

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

   $ source ~/stackrc

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

   $ openstack overcloud upgrade run --nodes Compute

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

手順

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

   $ source ~/stackrc

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

   $ openstack overcloud upgrade run --nodes CephStorage

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

4. Ceph Storage の外部アップグレードプロセスを実行します。以下に例を示します。

   $ openstack overcloud external-upgrade run --tags ceph

   • カスタムのスタック名を使用する場合は、--stack オプションでその名前を渡します。
   • 追加のオーバーライドを渡すには、「アップグレード用のカスタムパラメーター」 を参照してください。
5. Ceph Storage ノードのアップグレードが完了するまで待ちます。

手順

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

   $ source ~/stackrc

2. online_upgrade にタグ付けされたタスクに対して openstack overcloud external-upgrade run コマンドを実行します。

   $ openstack overcloud external-upgrade run --tags online_upgrade

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

手順

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

   $ source ~/stackrc

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

   $ openstack overcloud upgrade converge \
       --templates \
       -e <ENVIRONMENT FILE>

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

   • カスタム設定環境ファイル (-e)
   • カスタムのスタック名を使用する場合は、--stack オプションでその名前を渡します。
   • 該当する場合は、--roles-file でカスタムロール (roles_data) ファイルを指定します。
   • 該当する場合は、--networks-file でコンポーザブルネットワーク (network_data) ファイルを指定します。
3. アップグレードの最終処理が完了するまで待ちます。