Red Hat Training

A Red Hat training course is available for Red Hat OpenStack Platform

第6章 director を使用しない環境: 高可用性環境における個別の OpenStack サービス (稼働中の Compute) のアップグレード

本章では、高可用性の環境でライブのコンピュートを使用して 1 度に 1 サービスずつアップグレードするのに必要な手順について説明します。このシナリオでは、director を使用しない Red Hat OpenStack Platform 9 から Red Hat OpenStack Platform 10 へのアップグレードを行います。

稼働中の Compute を使用してアップグレードを行うと、Compute サービスの中断が最小限に抑えられます。小規模なサービスの場合はわずか数分ですが、新たにアップグレードされたコンピュートホストにワークロードを移動する場合は、移行の所要時間がより長くなります。既存のワークロードは無期限で稼働させることが可能です。また、データベース移行を待つ必要はありません。

重要

特定のパッケージの依存関係が原因で、OpenStack サービスのパッケージのアップグレードを試みると、OpenStack のサービスがアップグレードされる前に、Python ライブラリーがアップグレードされてしまう場合があります。そのために、特定のサービスが完了前に失敗する可能性があります。このような状況が発生した場合には、残りのサービスのアップグレードを継続します。このシナリオが完了すると、全サービスが稼動状態になるはずです。

注記

この方法では、コンピュートノードを稼働させるのに追加のハードウェアリソースが必要となる場合があります。

注記

本章に記載する手順は、すべての Red Hat OpenStack Platform ドキュメントで順守しているアーキテクチャー命名規則に従います。この規則に精通していない場合には、手順を開始する前に Red Hat OpenStack Platform ドキュメントスイート で『アーキテクチャーガイド』を参照してください。

6.1. アップグレード前のタスク

各ノードで subscription-manager コマンドを使用して、Red Hat OpenStack Platform 10 リポジトリーに変更します。

# subscription-manager repos --disable=rhel-7-server-openstack-9-rpms
# subscription-manager repos --enable=rhel-7-server-openstack-10-rpms

openstack-selinux パッケージをアップグレードします。

# yum upgrade openstack-selinux

これは、アップグレードしたサービスが SELinux が有効なシステムで正しく実行されるようにするために必要です。

6.2. MariaDB のアップグレード

MariaDB を実行する各ホストで、以下の手順を実行します。1 つのホストでの手順がすべて完了してから、次のホストでこのプロセスを開始してください。

  1. ローカルノードで実行されないようにサービスを停止します。

    # pcs resource ban galera-master $(crm_node -n)
  2. pcs status の出力で、ローカルノードで実行中のサービスがなくなるまで待ちます。これは、数分かかる可能性があります。ローカルノードは、slaves モードに切り替わります。

    Master/Slave Set: galera-master [galera]
    Masters: [ overcloud-controller-1 overcloud-controller-2 ]
    Slaves: [ overcloud-controller-0 ]

    ノードは最終的に Stopped に変わります。

    Master/Slave Set: galera-master [galera]
    Masters: [ overcloud-controller-1 overcloud-controller-2 ]
    Stopped: [ overcloud-controller-0 ]
  3. 適切なパッケージをアップグレードします。

    # yum upgrade '*mariadb*' '*galera*'
  4. Pacemaker がローカルノードで galera リソースのスケジューリングができるようにします。

    # pcs resource clear galera-master
  5. pcs status の出力で gelara リソースがローカルノードでマスターとして実行されていることが表示されるまで待ちます。pcs status コマンドの出力は、以下のように表示されるはずです。

    Master/Slave Set: galera-master [galera]
    Masters: [ overcloud-controller-0 overcloud-controller-1 overcloud-controller-2 ]

上記の手順は、MariaDB クラスターの完全なアップグレードが完了するまで各ノードで個別に実行します。

6.3. MongoDB のアップグレード

この手順では、OpenStack Telemetry サービスのバックエンドとして機能する MongoDB をアップグレードします。

  1. mongod リソースを Pacemaker の制御対象から除外します。

    # pcs resource unmanage mongod-clone
  2. このサービスを全コントローラーノードで停止します。各コントローラーノードで以下のコマンドを実行します。

    # systemctl stop mongod
  3. 適切なパッケージをアップグレードします。

    # yum upgrade 'mongodb*' 'python-pymongo*'
  4. 更新したユニットファイルを有効にするために systemd を再読み込みします。

    # systemctl daemon-reload
  5. 各コントローラーで以下のコマンドを実行して、mongod サービスを再起動します。

    # systemctl start mongod
  6. リソースをクリーンアップします。

    # pcs resource cleanup mongod-clone
  7. リソースを Pacemaker の制御対象に戻します。

    # pcs resource manage mongod-clone
  8. pcs status の出力で、上記のリソースが実行中と表示されるまで待ちます。

6.4. WSGI サービスのアップグレード

この手順では、全コントローラーノード上の WSGI サービスのパッケージを同時にアップグレードします。これには、OpenStack Identity (keystone) と OpenStack Dashboard (horizon) が含まれます。

  1. サービスを Pacemaker の制御下から削除します。

    # pcs resource unmanage httpd-clone
  2. 各コントローラーノードで以下のコマンドを実行して httpd サービスを停止します。

    # systemctl stop httpd
  3. 適切なパッケージをアップグレードします。

    # yum -d1 -y upgrade \*keystone\*
    # yum -y upgrade \*horizon\* \*openstack-dashboard\* httpd
    # yum -d1 -y upgrade \*horizon\* \*python-django\*
  4. 各コントローラーノードで、更新したユニットファイルを有効にするために、systemd を再読み込みします。

    # systemctl daemon-reload
  5. 初期のバージョンのインストーラーでは、期限切れの keystone トークンが自動的に削除されるようにシステム設定されていない可能性があるため、トークンテーブルに期限切れのエントリーが多数含まれている可能性があります。このような場合には、データベーススキーマのアップグレードの所要時間が大幅に増大する可能性があります。

    問題を緩和するには、データベースから期限切れのトークンをフラッシュします。Identity データベースのアップグレードを実行する前に keystone-manage コマンドを実行します。

    # keystone-manage token_flush

    これで、期限切れのトークンがデータベースからフラッシュされます。このコマンドは、cron を使用して定期的に (例: 毎日) 実行するように設定することが可能です。

  6. Identity サービスのデータベーススキーマを更新します。

    # su -s /bin/sh -c "keystone-manage db_sync" keystone
  7. 各コントローラーノードで以下のコマンドを実行してサービスを再起動します。

    # systemctl start httpd
  8. Pacemaker を使用して Identity サービスをクリーンアップします。

    # pcs resource cleanup httpd-clone
  9. リソースを Pacemaker の制御対象に戻します。

    # pcs resource manage httpd-clone
  10. pcs status の出力で、上記のリソースが実行中と表示されるまで待ちます。

6.5. Image サービス (glance) のアップグレード

この手順では、全コントローラーノード上で Image サービスのパッケージを同時にアップグレードします。

  1. Pacemaker で Image サービスのリソースを停止します。

    # pcs resource disable openstack-glance-registry-clone
    # pcs resource disable openstack-glance-api-clone
  2. pcs status の出力で、両サービスが停止されるまで待ちます。
  3. 適切なパッケージをアップグレードします。

    # yum upgrade '*glance*'
  4. 更新したユニットファイルを有効にするために systemd を再読み込みします。

    # systemctl daemon-reload
  5. Image サービスのデータベーススキーマを更新します。

    # su -s /bin/sh -c "glance-manage db_sync" glance
  6. Pacemaker を使用して Image サービスをクリーンアップします。

    # pcs resource cleanup openstack-glance-api-clone
    # pcs resource cleanup openstack-glance-registry-clone
  7. Pacemaker で Image サービスのリソースを再起動します。

    # pcs resource enable openstack-glance-api-clone
    # pcs resource enable openstack-glance-registry-clone
  8. pcs status の出力で、上記のリソースが実行中と表示されるまで待ちます。

6.6. Block Storage (cinder) サービスのアップグレード

この手順では、全コントローラーノード上で Block Storage サービスのパッケージを同時にアップグレードします。

  1. Pacemaker で Block Storage サービスのリソースを停止します。

    # pcs resource disable openstack-cinder-api-clone
    # pcs resource disable openstack-cinder-scheduler-clone
    # pcs resource disable openstack-cinder-volume
  2. pcs status の出力で、上記のサービスが停止されるまで待ちます。
  3. 適切なパッケージをアップグレードします。

    # yum upgrade '*cinder*'
  4. 更新したユニットファイルを有効にするために systemd を再読み込みします。

    # systemctl daemon-reload
  5. Block Storage サービスのデータベーススキーマを更新します。

    # su -s /bin/sh -c "cinder-manage db sync" cinder
  6. Pacemaker を使用して Block Storage サービスをクリーンアップします。

    # pcs resource cleanup openstack-cinder-volume
    # pcs resource cleanup openstack-cinder-scheduler-clone
    # pcs resource cleanup openstack-cinder-api-clone
  7. Pacemaker で Block Storage サービスのリソースすべてを再起動します。

    # pcs resource enable openstack-cinder-volume
    # pcs resource enable openstack-cinder-scheduler-clone
    # pcs resource enable openstack-cinder-api-clone
  8. pcs status の出力で、上記のリソースが実行中と表示されるまで待ちます。

6.7. Orchestration (heat) のアップグレード

この手順では、全コントローラーノード上で Orchestration サービスのパッケージを同時にアップグレードします。

  1. Pacemaker で Orchestration リソースを停止します。

    # pcs resource disable openstack-heat-api-clone
    # pcs resource disable openstack-heat-api-cfn-clone
    # pcs resource disable openstack-heat-api-cloudwatch-clone
    # pcs resource disable openstack-heat-engine-clone
  2. pcs status の出力で、上記のサービスが停止されるまで待ちます。
  3. 適切なパッケージをアップグレードします。

    # yum upgrade '*heat*'
  4. 更新したユニットファイルを有効にするために systemd を再読み込みします。

    # systemctl daemon-reload
  5. Orchestration のデータベーススキーマを更新します。

    # su -s /bin/sh -c "heat-manage db_sync" heat
  6. Pacemaker を使用して Orchestration サービスをクリーンアップします。

    # pcs resource cleanup openstack-heat-clone
    # pcs resource cleanup openstack-heat-api-cloudwatch-clone
    # pcs resource cleanup openstack-heat-api-cfn-clone
    # pcs resource cleanup openstack-heat-api-clone
  7. Pacemaker で Orchestration リソースを再起動します。

    # pcs resource enable openstack-heat-clone
    # pcs resource enable openstack-heat-api-cloudwatch-clone
    # pcs resource enable openstack-heat-api-cfn-clone
    # pcs resource enable openstack-heat-api-clone
  8. pcs status の出力で、上記のリソースが実行中と表示されるまで待ちます。

6.8. Telemetry (ceilometer) のアップグレード

この手順では、全コントローラーノード上で Telemetry サービスのパッケージを同時にアップグレードします。

注記

このコンポーネントには、「7章director を使用しない環境向けの追加の手順」に記載したように、追加のアップグレード手順がいくつかあります。これらの追加手順は、手動の環境ではオプションですが、現在の OpenStack の推奨事項に合わせるのに役立ちます。

  1. Pacemaker で Telemetry リソースをすべて停止します。

    # pcs resource disable openstack-ceilometer-api-clone
    # pcs resource disable openstack-ceilometer-collector-clone
    # pcs resource disable openstack-ceilometer-notification-clone
    # pcs resource disable openstack-ceilometer-central-clone
    # pcs resource disable openstack-aodh-evaluator-clone
    # pcs resource disable openstack-aodh-listener-clone
    # pcs resource disable openstack-aodh-notifier-clone
    # pcs resource disable openstack-gnocchi-metricd-clone
    # pcs resource disable openstack-gnocchi-statsd-clone
    # pcs resource disable delay-clone
  2. pcs status の出力で、上記のサービスが停止されるまで待ちます。
  3. 適切なパッケージをアップグレードします。

    # yum upgrade '*ceilometer*' '*aodh*' '*gnocchi*'
  4. 更新したユニットファイルを有効にするために systemd を再読み込みします。

    # systemctl daemon-reload
  5. 以下のコマンドを使用して Telemetry データベーススキーマを更新します。

    # ceilometer-dbsync
    # aodh-dbsync
    # gnocchi-upgrade
  6. Pacemaker を使用して Telemetry サービスをクリーンアップします。

    # pcs resource cleanup delay-clone
    # pcs resource cleanup openstack-ceilometer-api-clone
    # pcs resource cleanup openstack-ceilometer-collector-clone
    # pcs resource cleanup openstack-ceilometer-notification-clone
    # pcs resource cleanup openstack-ceilometer-central-clone
    # pcs resource cleanup openstack-aodh-evaluator-clone
    # pcs resource cleanup openstack-aodh-listener-clone
    # pcs resource cleanup openstack-aodh-notifier-clone
    # pcs resource cleanup openstack-gnocchi-metricd-clone
    # pcs resource cleanup openstack-gnocchi-statsd-clone
  7. Pacemaker で Telemetry リソースをすべて再起動します。

    # pcs resource enable delay-clone
    # pcs resource enable openstack-ceilometer-api-clone
    # pcs resource enable openstack-ceilometer-collector-clone
    # pcs resource enable openstack-ceilometer-notification-clone
    # pcs resource enable openstack-ceilometer-central-clone
    # pcs resource enable openstack-aodh-evaluator-clone
    # pcs resource enable openstack-aodh-listener-clone
    # pcs resource enable openstack-aodh-notifier-clone
    # pcs resource enable openstack-gnocchi-metricd-clone
    # pcs resource enable openstack-gnocchi-statsd-clone
  8. pcs status の出力で、上記のリソースが実行中と表示されるまで待ちます。
重要

以前のバージョンの Telemetry サービスは、現在のバージョンでは非推奨となっている rpc_backend パラメーターの値を使用していました。/etc/ceilometer/ceilometer.conf ファイルの rpc_backend パラメーターが以下のように設定されていることを確認してください。

rpc_backend=rabbit

6.9. コントローラーノード上の Compute サービス (nova) のアップグレード

この手順では、全コントローラーノード上で Compute サービスのパッケージを同時にアップグレードします。

  1. Pacemaker で Compute リソースをすべて停止します。

    # pcs resource disable openstack-nova-novncproxy-clone
    # pcs resource disable openstack-nova-consoleauth-clone
    # pcs resource disable openstack-nova-conductor-clone
    # pcs resource disable openstack-nova-api-clone
    # pcs resource disable openstack-nova-scheduler-clone
  2. pcs status の出力で、上記のサービスが停止されるまで待ちます。
  3. 適切なパッケージをアップグレードします。

    # yum upgrade '*nova*'
  4. 更新したユニットファイルを有効にするために systemd を再読み込みします。

    # systemctl daemon-reload
  5. Compute のデータベーススキーマを更新します。

    # su -s /bin/sh -c "nova-manage api_db sync" nova
    # su -s /bin/sh -c "nova-manage db sync" nova
  6. コンピュートホストのローリングアップグレードを実行する場合には、API バージョンの制限を明示的に設定して、Mitaka と Newton 環境間での互換性を確保する必要があります。

    コントローラーノードまたはコンピュートノードで Compute サービスを起動する前に、nova.conf ファイルの [upgrade_levels] セクションで、compute オプションを以前の Red Hat OpenStack Platform バージョン (mitaka) に設定します。

    # crudini --set /etc/nova/nova.conf upgrade_levels compute mitaka

    これにより、コントローラーノードは、以前のバージョンを使用しているコンピュートノードとの通信が引き続き可能となります。

    まず、コントローラーの 1 つで pcs resource unmanage を実行して Compute リソースの管理を解除する必要があります。

    # pcs resource unmanage openstack-nova-novncproxy-clone
    # pcs resource unmanage openstack-nova-consoleauth-clone
    # pcs resource unmanage openstack-nova-conductor-clone
    # pcs resource unmanage openstack-nova-api-clone
    # pcs resource unmanage openstack-nova-scheduler-clone

    コントローラーすべてで全サービスを再起動します。

    # openstack-service restart nova

    全コンピュートホストを Red Hat OpenStack Platform 10 にアップグレードした後には、制御を Pacemaker に戻します。

    # pcs resource manage openstack-nova-scheduler-clone
    # pcs resource manage openstack-nova-api-clone
    # pcs resource manage openstack-nova-conductor-clone
    # pcs resource manage openstack-nova-consoleauth-clone
    # pcs resource manage openstack-nova-novncproxy-clone
  7. Pacemaker で Compute リソースをすべてクリーンアップします。

    # pcs resource cleanup openstack-nova-scheduler-clone
    # pcs resource cleanup openstack-nova-api-clone
    # pcs resource cleanup openstack-nova-conductor-clone
    # pcs resource cleanup openstack-nova-consoleauth-clone
    # pcs resource cleanup openstack-nova-novncproxy-clone
  8. Pacemaker で Compute リソースをすべて再起動します。

    # pcs resource enable openstack-nova-scheduler-clone
    # pcs resource enable openstack-nova-api-clone
    # pcs resource enable openstack-nova-conductor-clone
    # pcs resource enable openstack-nova-consoleauth-clone
    # pcs resource enable openstack-nova-novncproxy-clone
  9. pcs status の出力で、上記のリソースが実行中と表示されるまで待ちます。

6.10. Clustering サービス (sahara) のアップグレード

本手順では、全コントローラーノードで同時に Clustering サービスのパッケージを更新します。

  1. Pacemaker で Clustering サービスのリソースをすべて停止します。

    # pcs resource disable openstack-sahara-api-clone
    # pcs resource disable openstack-sahara-engine-clone
  2. pcs status の出力で、上記のサービスが停止されるまで待ちます。
  3. 適切なパッケージをアップグレードします。

    # yum upgrade '*sahara*'
  4. 更新したユニットファイルを有効にするために systemd を再読み込みします。

    # systemctl daemon-reload
  5. Clustering サービスのデータベーススキーマを更新します。

    # su -s /bin/sh -c "sahara-db-manage upgrade heads" sahara
  6. Pacemaker を使用して Clustering サービスをクリーンアップします。

    # pcs resource cleanup openstack-sahara-api-clone
    # pcs resource cleanup openstack-sahara-engine-clone
  7. Pacemaker で Block Storage サービスのリソースすべてを再起動します。

    # pcs resource enable openstack-sahara-api-clone
    # pcs resource enable openstack-sahara-engine-clone
  8. pcs status の出力で、上記のリソースが実行中と表示されるまで待ちます。

6.11. OpenStack Networking (neutron) のアップグレード

この手順では、全コントローラーノード上で Networking サービスのパッケージを同時にアップグレードします。

  1. Pacemaker による OpenStack Networking クリーンアップスクリプトがトリガーされないようにします。

    # pcs resource unmanage neutron-ovs-cleanup-clone
    # pcs resource unmanage neutron-netns-cleanup-clone
  2. Pacemaker で OpenStack Networking のリソースを停止します。

    # pcs resource disable neutron-server-clone
    # pcs resource disable neutron-openvswitch-agent-clone
    # pcs resource disable neutron-dhcp-agent-clone
    # pcs resource disable neutron-l3-agent-clone
    # pcs resource disable neutron-metadata-agent-clone
  3. 適切なパッケージをアップグレードします。

    # yum upgrade 'openstack-neutron*' 'python-neutron*'
  4. OpenStack Networking のデータベーススキーマを更新します。

    # su -s /bin/sh -c "neutron-db-manage upgrade heads" neutron
  5. Pacemaker で OpenStack Networking のリソースをクリーンアップします。

    # pcs resource cleanup neutron-metadata-agent-clone
    # pcs resource cleanup neutron-l3-agent-clone
    # pcs resource cleanup neutron-dhcp-agent-clone
    # pcs resource cleanup neutron-openvswitch-agent-clone
    # pcs resource cleanup neutron-server-clone
  6. Pacemaker で OpenStack Networking のリソースを再起動します。

    # pcs resource enable neutron-metadata-agent-clone
    # pcs resource enable neutron-l3-agent-clone
    # pcs resource enable neutron-dhcp-agent-clone
    # pcs resource enable neutron-openvswitch-agent-clone
    # pcs resource enable neutron-server-clone
  7. クリーンアップエージェントを Pacemaker の制御対象に戻します。

    # pcs resource manage neutron-ovs-cleanup-clone
    # pcs resource manage neutron-netns-cleanup-clone
  8. pcs status の出力で、上記のリソースが実行中と表示されるまで待ちます。

6.12. コンピュートノード (nova) のアップグレード

この手順では、単一のコンピュートノードのパッケージをアップグレードします。以下のステップを各コンピュートノードで個別に実行してください。

コンピュートホストのローリングアップグレードを実行する場合には、API バージョンの制限を明示的に設定して、Mitaka と Newton 環境間での互換性を確保する必要があります。

コントローラーノードまたはコンピュートノードで Compute サービスを起動する前に、nova.conf ファイルの [upgrade_levels] セクションで、compute オプションを以前の Red Hat OpenStack Platform バージョン (mitaka) に設定します。

# crudini --set /etc/nova/nova.conf upgrade_levels compute mitaka

更新を実行する前に、OpenStack サービスの systemd スナップショットを作成します。

# systemctl snapshot openstack-services

これにより、コントローラーノードは、以前のバージョンを使用しているコンピュートノードとの通信が引き続き可能となります。

  1. ホスト上の OpenStack サービスをすべて停止します。

    # systemctl stop 'openstack*' '*nova*'
  2. すべてのパッケージをアップグレードします。

    # yum upgrade
  3. ホスト上の OpenStack サービスをすべて起動します。

    # openstack-service start
  4. 全ホストをアップグレードした後には、以前のステップで設定した API の制限を削除します。全ホスト上で以下のコマンドを実行します。

    # crudini --del /etc/nova/nova.conf upgrade_levels compute
  5. ホスト上の OpenStack サービスをすべて再起動します。

    # systemctl isolate openstack-services.snapshot

6.13. アップグレード後のタスク

個別サービスのアップグレードをすべて完了した後には、全ノードで完全なパッケージアップグレードを行う必要があります。

# yum upgrade

このコマンドは、すべてのパッケージを最新の状態にします。実行中のプロセスが、配下のバイナリーの更新されたバージョンを使用するようにするには、OpenStack ホストの再起動を後日にスケジューリングする必要があります。

上記の操作によって生成された設定ファイルを確認します。アップグレードされたパッケージで、Red Hat OpenStack Platform 10 バージョンのサービスに適した .rpmnew ファイルがインストールされているはずです。

新しいバージョンの OpenStack サービスでは、特定の設定オプションが非推奨になっている可能性があります。このような非推奨の設定オプションが原因で今後のアップグレードの際に問題が発生する可能性があるため、非推奨の警告については OpenStack のログも参照してください。各サービスで新規追加/更新された設定オプションや非推奨となった設定オプションについての詳しい説明は、Red Hat OpenStack Platform ドキュメントスイート で『Configuration Reference』を参照してください。