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 つのホストでの手順がすべて完了してから、次のホストでこのプロセスを開始してください。
ローカルノードで実行されないようにサービスを停止します。
# pcs resource ban galera-master $(crm_node -n)
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 ]
適切なパッケージをアップグレードします。
# yum upgrade '*mariadb*' '*galera*'
Pacemaker がローカルノードで
galera
リソースのスケジューリングができるようにします。# pcs resource clear galera-master
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 をアップグレードします。
mongod
リソースを Pacemaker の制御対象から除外します。# pcs resource unmanage mongod-clone
このサービスを全コントローラーノードで停止します。各コントローラーノードで以下のコマンドを実行します。
# systemctl stop mongod
適切なパッケージをアップグレードします。
# yum upgrade 'mongodb*' 'python-pymongo*'
更新したユニットファイルを有効にするために
systemd
を再読み込みします。# systemctl daemon-reload
各コントローラーで以下のコマンドを実行して、
mongod
サービスを再起動します。# systemctl start mongod
リソースをクリーンアップします。
# pcs resource cleanup mongod-clone
リソースを Pacemaker の制御対象に戻します。
# pcs resource manage mongod-clone
-
pcs status
の出力で、上記のリソースが実行中と表示されるまで待ちます。
6.4. WSGI サービスのアップグレード
この手順では、全コントローラーノード上の WSGI サービスのパッケージを同時にアップグレードします。これには、OpenStack Identity (keystone) と OpenStack Dashboard (horizon) が含まれます。
サービスを Pacemaker の制御下から削除します。
# pcs resource unmanage httpd-clone
各コントローラーノードで以下のコマンドを実行して
httpd
サービスを停止します。# systemctl stop httpd
適切なパッケージをアップグレードします。
# yum -d1 -y upgrade \*keystone\* # yum -y upgrade \*horizon\* \*openstack-dashboard\* httpd # yum -d1 -y upgrade \*horizon\* \*python-django\*
各コントローラーノードで、更新したユニットファイルを有効にするために、
systemd
を再読み込みします。# systemctl daemon-reload
初期のバージョンのインストーラーでは、期限切れの keystone トークンが自動的に削除されるようにシステム設定されていない可能性があるため、トークンテーブルに期限切れのエントリーが多数含まれている可能性があります。このような場合には、データベーススキーマのアップグレードの所要時間が大幅に増大する可能性があります。
問題を緩和するには、データベースから期限切れのトークンをフラッシュします。Identity データベースのアップグレードを実行する前に
keystone-manage
コマンドを実行します。# keystone-manage token_flush
これで、期限切れのトークンがデータベースからフラッシュされます。このコマンドは、
cron
を使用して定期的に (例: 毎日) 実行するように設定することが可能です。Identity サービスのデータベーススキーマを更新します。
# su -s /bin/sh -c "keystone-manage db_sync" keystone
各コントローラーノードで以下のコマンドを実行してサービスを再起動します。
# systemctl start httpd
Pacemaker を使用して Identity サービスをクリーンアップします。
# pcs resource cleanup httpd-clone
リソースを Pacemaker の制御対象に戻します。
# pcs resource manage httpd-clone
-
pcs status
の出力で、上記のリソースが実行中と表示されるまで待ちます。
6.5. Image サービス (glance) のアップグレード
この手順では、全コントローラーノード上で Image サービスのパッケージを同時にアップグレードします。
Pacemaker で Image サービスのリソースを停止します。
# pcs resource disable openstack-glance-registry-clone # pcs resource disable openstack-glance-api-clone
-
pcs status
の出力で、両サービスが停止されるまで待ちます。 適切なパッケージをアップグレードします。
# yum upgrade '*glance*'
更新したユニットファイルを有効にするために
systemd
を再読み込みします。# systemctl daemon-reload
Image サービスのデータベーススキーマを更新します。
# su -s /bin/sh -c "glance-manage db_sync" glance
Pacemaker を使用して Image サービスをクリーンアップします。
# pcs resource cleanup openstack-glance-api-clone # pcs resource cleanup openstack-glance-registry-clone
Pacemaker で Image サービスのリソースを再起動します。
# pcs resource enable openstack-glance-api-clone # pcs resource enable openstack-glance-registry-clone
-
pcs status
の出力で、上記のリソースが実行中と表示されるまで待ちます。
6.6. Block Storage (cinder) サービスのアップグレード
この手順では、全コントローラーノード上で Block Storage サービスのパッケージを同時にアップグレードします。
Pacemaker で Block Storage サービスのリソースを停止します。
# pcs resource disable openstack-cinder-api-clone # pcs resource disable openstack-cinder-scheduler-clone # pcs resource disable openstack-cinder-volume
-
pcs status
の出力で、上記のサービスが停止されるまで待ちます。 適切なパッケージをアップグレードします。
# yum upgrade '*cinder*'
更新したユニットファイルを有効にするために
systemd
を再読み込みします。# systemctl daemon-reload
Block Storage サービスのデータベーススキーマを更新します。
# su -s /bin/sh -c "cinder-manage db sync" cinder
Pacemaker を使用して Block Storage サービスをクリーンアップします。
# pcs resource cleanup openstack-cinder-volume # pcs resource cleanup openstack-cinder-scheduler-clone # pcs resource cleanup openstack-cinder-api-clone
Pacemaker で Block Storage サービスのリソースすべてを再起動します。
# pcs resource enable openstack-cinder-volume # pcs resource enable openstack-cinder-scheduler-clone # pcs resource enable openstack-cinder-api-clone
-
pcs status
の出力で、上記のリソースが実行中と表示されるまで待ちます。
6.7. Orchestration (heat) のアップグレード
この手順では、全コントローラーノード上で Orchestration サービスのパッケージを同時にアップグレードします。
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
-
pcs status
の出力で、上記のサービスが停止されるまで待ちます。 適切なパッケージをアップグレードします。
# yum upgrade '*heat*'
更新したユニットファイルを有効にするために
systemd
を再読み込みします。# systemctl daemon-reload
Orchestration のデータベーススキーマを更新します。
# su -s /bin/sh -c "heat-manage db_sync" heat
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
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
-
pcs status
の出力で、上記のリソースが実行中と表示されるまで待ちます。
6.8. Telemetry (ceilometer) のアップグレード
この手順では、全コントローラーノード上で Telemetry サービスのパッケージを同時にアップグレードします。
このコンポーネントには、「7章director を使用しない環境向けの追加の手順」に記載したように、追加のアップグレード手順がいくつかあります。これらの追加手順は、手動の環境ではオプションですが、現在の OpenStack の推奨事項に合わせるのに役立ちます。
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
-
pcs status
の出力で、上記のサービスが停止されるまで待ちます。 適切なパッケージをアップグレードします。
# yum upgrade '*ceilometer*' '*aodh*' '*gnocchi*'
更新したユニットファイルを有効にするために
systemd
を再読み込みします。# systemctl daemon-reload
以下のコマンドを使用して Telemetry データベーススキーマを更新します。
# ceilometer-dbsync # aodh-dbsync # gnocchi-upgrade
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
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
-
pcs status
の出力で、上記のリソースが実行中と表示されるまで待ちます。
以前のバージョンの Telemetry サービスは、現在のバージョンでは非推奨となっている rpc_backend
パラメーターの値を使用していました。/etc/ceilometer/ceilometer.conf
ファイルの rpc_backend
パラメーターが以下のように設定されていることを確認してください。
rpc_backend=rabbit
6.9. コントローラーノード上の Compute サービス (nova) のアップグレード
この手順では、全コントローラーノード上で Compute サービスのパッケージを同時にアップグレードします。
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
-
pcs status
の出力で、上記のサービスが停止されるまで待ちます。 適切なパッケージをアップグレードします。
# yum upgrade '*nova*'
更新したユニットファイルを有効にするために
systemd
を再読み込みします。# systemctl daemon-reload
Compute のデータベーススキーマを更新します。
# su -s /bin/sh -c "nova-manage api_db sync" nova # su -s /bin/sh -c "nova-manage db sync" 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
これにより、コントローラーノードは、以前のバージョンを使用しているコンピュートノードとの通信が引き続き可能となります。
まず、コントローラーの 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
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
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
-
pcs status
の出力で、上記のリソースが実行中と表示されるまで待ちます。
6.10. Clustering サービス (sahara) のアップグレード
本手順では、全コントローラーノードで同時に Clustering サービスのパッケージを更新します。
Pacemaker で Clustering サービスのリソースをすべて停止します。
# pcs resource disable openstack-sahara-api-clone # pcs resource disable openstack-sahara-engine-clone
-
pcs status
の出力で、上記のサービスが停止されるまで待ちます。 適切なパッケージをアップグレードします。
# yum upgrade '*sahara*'
更新したユニットファイルを有効にするために
systemd
を再読み込みします。# systemctl daemon-reload
Clustering サービスのデータベーススキーマを更新します。
# su -s /bin/sh -c "sahara-db-manage upgrade heads" sahara
Pacemaker を使用して Clustering サービスをクリーンアップします。
# pcs resource cleanup openstack-sahara-api-clone # pcs resource cleanup openstack-sahara-engine-clone
Pacemaker で Block Storage サービスのリソースすべてを再起動します。
# pcs resource enable openstack-sahara-api-clone # pcs resource enable openstack-sahara-engine-clone
-
pcs status
の出力で、上記のリソースが実行中と表示されるまで待ちます。
6.11. OpenStack Networking (neutron) のアップグレード
この手順では、全コントローラーノード上で Networking サービスのパッケージを同時にアップグレードします。
Pacemaker による OpenStack Networking クリーンアップスクリプトがトリガーされないようにします。
# pcs resource unmanage neutron-ovs-cleanup-clone # pcs resource unmanage neutron-netns-cleanup-clone
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
適切なパッケージをアップグレードします。
# yum upgrade 'openstack-neutron*' 'python-neutron*'
OpenStack Networking のデータベーススキーマを更新します。
# su -s /bin/sh -c "neutron-db-manage upgrade heads" neutron
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
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
クリーンアップエージェントを Pacemaker の制御対象に戻します。
# pcs resource manage neutron-ovs-cleanup-clone # pcs resource manage neutron-netns-cleanup-clone
-
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
これにより、コントローラーノードは、以前のバージョンを使用しているコンピュートノードとの通信が引き続き可能となります。
ホスト上の OpenStack サービスをすべて停止します。
# systemctl stop 'openstack*' '*nova*'
すべてのパッケージをアップグレードします。
# yum upgrade
ホスト上の OpenStack サービスをすべて起動します。
# openstack-service start
全ホストをアップグレードした後には、以前のステップで設定した API の制限を削除します。全ホスト上で以下のコマンドを実行します。
# crudini --del /etc/nova/nova.conf upgrade_levels compute
ホスト上の 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』を参照してください。