Red Hat Training
A Red Hat training course is available for Red Hat OpenStack Platform
第3章 director ベースの環境: メジャーバージョンへのアップグレードの実行
最新のメジャーバージョンにアップグレードする前に、アンダークラウドとオーバークラウドが最新のマイナーバージョンに更新されていることを確認してください。これには、OpenStack Platform サービスとベースオペレーティングシステムの両方が含まれます。マイナーバージョンを更新するプロセスについては、Red Hat OpenStack Platform 8『Red Hat OpenStack Platform のアップグレード』の「director ベースの環境: マイナーバージョンへの更新の実行」の章を参照してください。先にマイナーバージョンを更新せずに、メジャーバージョンをアップグレードすると、アップグレードプロセスが失敗してしまう可能性があります。
インスタンスの高可用性を実装している場合には、アップグレードやスケールアップはできないので (『コンピュートインスタンスの高可用性』で説明しています)、操作を試みても失敗してしまいます。
また、インスタンスの高可用性を有効にすると、将来、director を使用したアップグレードはできなくなります。これは、メジャーアップグレードとマイナーアップグレードの両方に該当します。詳しくは、https://access.redhat.com/ja/solutions/2898841 を参照してください。
本章では、環境のアップグレードの方法を見て行きます。ここでは、アンダークラウドとオーバークラウド両方のアップグレードプロセスを説明します。このアップグレードプロセスでは、次のメジャーバージョンに移行する手段を提供します。今回は、Red Hat OpenStack Platform 8 から Red Hat OpenStack Platform 9 へのアップグレードです。
いずれの場合の手順でも、以下のワークフローを実行していきます。
- Red Hat OpenStack Platform director パッケージの更新
- Red Hat OpenStack Platform director でのオーバークラウドイメージの更新
- Red Hat OpenStack Platform director を使用したオーバークラウドスタックとパッケージの更新
バージョンのアップグレードを行う前に、「アップグレード前の重要な注記」の情報を必ず一読してください。
3.1. アップグレード前の重要な注記
環境をアップグレードする前に、以下の注記を必ず一読してください。
Red Hat OpenStack Platform director でのアップグレードは、ライブの実稼働環境で実行する前に、その環境固有の設定で全面的にテストする必要があります。Red Hat では、director を使用する場合の標準のオプションとして提供されているユースケースの大半とそれらの組み合わせを検証済みですが、可能な組み合わせの数が多いため、それらを完全に網羅することはできません。さらに、標準デプロイメントの設定が変更された場合には、手動または設定後のフックを使用して、実稼働用以外の環境でアップグレード機能をテストすることが極めて重要です。そのため、以下を実行することを推奨します。
- アンダークラウドノードのバックアップを実行してから、アップグレードの手順のステップを開始します。バックアップの手順は、 『director のアンダークラウドのバックアップと復元』ガイドを参照してください。
- 実稼働環境で手順を実行する前に、すべての変更が加えられたテスト環境でアップグレードの手順を実行します。
- このアップグレードの実行に関して何らかの懸念がある場合は、作業を開始する前に、Red Hat までご連絡いただき、アップグレードプロセスについてのアドバイスおよびサポートを依頼してください。
- 本項で説明するアップグレードプロセスは、director を使ったカスタマイズにのみ対応しています。director 以外を使用してオーバークラウドの機能をカスタマイズした場合は、オーバークラウドをアップグレードして、アップグレードの完了後にその機能を再度有効化してください。つまり、カスタマイズした機能は、アップグレードがすべて完了するまで利用できないということになります。
Red Hat OpenStack Platform director 9 は、Red Hat OpenStack Platform 8 の特定のオーバークラウドバージョンを管理できます。詳しい情報は、以下のサポートマトリックスを参照してください。
表3.1 Red Hat OpenStack Platform director 9 のサポートマトリックス
バージョン
オーバークラウドの更新
オーバークラウドのデプロイ
オーバークラウドのスケーリング
Red Hat OpenStack Platform 9
8.0
すべてのバージョン
すべてのバージョン
旧バージョンのオーバークラウドを管理している場合には、以下の Heat テンプレートコレクションを使用してください。
Red Hat OpenStack Platform 8:
/usr/share/openstack-tripleo-heat-templates/liberty/
以下に例を示します。
$ openstack overcloud deploy -templates /usr/share/openstack-tripleo-heat-templates/liberty/ [OTHER_OPTIONS]
- Red Hat OpenStack Platform 9 へのメジャーアップグレードを試みる前には、アンダークラウドとオーバークラウドを Red Hat OpenStack Platform 8 および Red Hat Enterprise Linux 7 の最新のマイナーリリースに必ずアップグレードしておいてください。「director ベースの環境: マイナーバージョンへの更新の実行」で、アンダークラウドとオーバークラウドにパッケージの更新を実行する手順を参照してください。カーネルが最新バージョンに更新された場合には、再起動して新規カーネルパラメーターを有効にしてください。
3.2. director のアップグレード
以下の手順を試みる前に、「アップグレード前の重要な注記」に記載の情報を一読してください。
Red Hat OpenStack Platform director をアップグレードするには、以下の手順に従ってください。
-
director に
stack
ユーザーとしてログインします。 OpenStack Platform のリポジトリーを更新します。
$ sudo subscription-manager repos --disable=rhel-7-server-openstack-8-rpms --disable=rhel-7-server-openstack-8-director-rpms $ sudo subscription-manager repos --enable=rhel-7-server-openstack-9-rpms --enable=rhel-7-server-openstack-9-director-rpms
上記のコマンドは、
yum
が最新のリポジトリーを使用するように設定します。主要な OpenStack Platform サービスを停止します。
$ sudo systemctl stop 'openstack-*' 'neutron-*' httpd
注記これにより、アンダークラウドで短時間のダウンタイムが生じます。アンダークラウドの更新中もオーバークラウドは引き続き機能します。
yum
を使用して director をアップグレードします。$ sudo yum update python-tripleoclient
以下のコマンドでアンダークラウドをアップグレードします。
$ openstack undercloud upgrade
このコマンドにより、director のパッケージがアップグレードされ、director の設定が最新の状態に更新されて、バージョンの変更後に指定されていない設定内容が追加されます。このコマンドによって、オーバークラウドのスタックデータや環境内の既存のノードのデータなど、保存されたデータは削除されません。
各ノードで /var/log/yum.log
ファイルをチェックして、kernel
または openvswitch
のパッケージのメジャー/マイナーバージョンが更新されているかどうかを確認します。更新されている場合には、各ノードを再起動します。
ノードを再起動します。
$ sudo reboot
- ノードが起動するまで待ちます。
ノードが起動したら、全サービスのステータスを確認します。
$ sudo systemctl list-units "openstack*" "neutron*" "openvswitch*"
オーバクラウドとそのノードが存在しているかどうかを確認します。
$ source ~/stackrc $ openstack server list $ openstack baremetal node list $ openstack stack list
オーバークラウドを Red Hat OpenStack Platform 9 にアップグレードした後には以下の点に注意してください。
アンダークラウドの
admin
ユーザーは、Red Hat OpenStack Platform 9 に含まれていない追加のロール (_member_
) が必要な場合があります。このロールは、オーバークラウドの通信の際に重要です。このロールがあるかどうか確認します。$ openstack role list
このロールが存在しない場合は、作成します。
$ openstack role create _member_
admin
テナントでadmin
ユーザーにこのロールを追加します。$ openstack role add --user admin --project admin _member_
カスタマイズされたコアの Heat テンプレートを使用する場合には、更新されたコアの Heat テンプレートと現在の設定の相違点を確認するようにしてください。Red Hat では、今後のリリースで Heat テンプレートコレクションへの更新を提供します。変更されたテンプレートコレクションを使用すると、カスタムのコピーと /usr/share/openstack-tripleo-heat-templates
にあるオリジナルのコピーとの間に相違が生じる可能性があります。以下のコマンドを実行して、カスタムの Heat テンプレートと更新されるオリジナルのバージョンとの差分を確認します。
# diff -Nary /usr/share/openstack-tripleo-heat-templates/ ~/templates/my-overcloud/
これらの更新をカスタムの Heat テンプレートコレクションに適用するか、/usr/share/openstack-tripleo-heat-templates/
でテンプレートの新しいコピーを作成して、カスタマイズを適用します。
3.3. director 上のオーバークラウドイメージのアップグレード
以下の手順のステップを試す前に、「アップグレード前の重要な注記」の情報を必ず一読してください。
以下の手順では、ノードの検出とオーバークラウドのデプロイメントに向け最新のイメージが確保されるようにします。rhosp-director-images
および rhosp-director-images-ipa
のパッケージからの新規イメージは、アンダークラウドのアップグレードですでに更新されています。
stack
ユーザーの images
ディレクトリー (/home/stack/images
) から既存のイメージを削除します。
$ rm -rf ~/images/*
アーカイブを展開します。
$ cd ~/images $ for i in /usr/share/rhosp-director-images/overcloud-full-latest-9.0.tar /usr/share/rhosp-director-images/ironic-python-agent-latest-9.0.tar; do tar -xvf $i; done
最新のイメージを director にインポートして、ノードがこれらの新規イメージを使用するように設定します。
$ openstack overcloud image upload --update-existing --image-path ~/images/. $ openstack baremetal configure boot
新規イメージの存在をチェックして、イメージの更新を最終確認します。
$ openstack image list $ ls -l /httpboot
director は、最新のイメージを使用してアップグレードされました。
オーバークラウドのイメージのバージョンがアンダークラウドのバージョンに対応していることを確認してください。
3.4. オーバークラウドのアップグレード
以下の手順のステップを試す前に、「アップグレード前の重要な注記」の情報を必ず一読してください。
本項には、オーバークラウドのアップグレードに必要な手順を記載します。各セクションを順番に従って進み、お使いの環境に関連するセクションのみを適用します。
このプロセスでは、ステージごとに分けた手法を使用してアップグレードを行うには、元の openstack overcloud deploy
コマンドを複数回実行する必要があります。コマンドを実行する度に、既存の環境ファイルに、別のアップグレードの環境ファイルが追加されます。これらの新しいアップグレード環境ファイルには、以下のようなファイルがあります。
-
major-upgrade-aodh.yaml
: OpenStack Telemetry Alarming (aodh
) サービスをインストールします。 -
major-upgrade-keystone-liberty-mitaka.yaml
: OpenStack Identity (keystone
) をスタンドアロンのサービスから、httpd
下の Web Server Gateway Interface (WSGI) サービスに移行します。 -
major-upgrade-pacemaker-init.yaml
: アップグレードの初期設定を行います。これには、オーバークラウドの各ノードにある Red Hat OpenStack Platform のリポジトリーの更新や、特定のノードへの特別なアップグレードスクリプトの提供などが含まれます。 -
major-upgrade-pacemaker.yaml
: コントローラーノードをアップグレードします。 -
major-upgrade-pacemaker-converge.yaml
: オーバークラウドのアップグレードの最終処理。これは、実行されるアップグレードが director の最新の Heat テンプレートコレクションの内容と一致するように合わせます。
これらのデプロイメントのコマンドの間に、さまざまなタイプのノードで upgrade-non-controller.sh
スクリプトを実行します。このスクリプトにより、コントローラー以外のノードでパッケージが更新されます。
ワークフロー
オーバークラウドのアップグレードプロセスでは、以下のワークフローを使用します。
-
major-upgrade-aodh.yaml
環境ファイルを指定してデプロイメントコマンドを実行します。 -
major-upgrade-keystone-liberty-mitaka.yaml
環境ファイルを指定してデプロイメントコマンドを実行します。 -
major-upgrade-pacemaker-init.yaml
環境ファイルを指定してデプロイメントコマンドを実行します。 -
各 Object Storage ノードで
upgrade-non-controller.sh
を実行します。 -
major-upgrade-pacemaker.yaml
環境ファイルを指定してデプロイメントコマンドを実行します。 -
各 Compute ノードで
upgrade-non-controller.sh
を実行します。 -
各 Ceph Storage ノードで
upgrade-non-controller.sh
を実行します。 -
major-upgrade-pacemaker-converge.yaml
環境ファイルを指定してデプロイメントコマンドを実行します。
3.4.1. オーバークラウドをアップグレードする前の注意事項
Satellite の登録に環境ファイルを使用する場合は、その環境ファイルで以下のパラメーターを更新するようにしてください。
-
rhel_reg_repos
: オーバークラウドを有効化するためのリポジトリー。新しい Red Hat OpenStack Platform 9 リポジトリーを含みます。有効化するリポジトリーについては、「リポジトリーの要件」を参照してください。 -
rhel_reg_activation_key
: Red Hat OpenStack Platform 9 リポジトリー用の新規アクティベーションキー -
rhel_reg_sat_repo
:katello-agent
など、Red Hat Satellite 6 の管理ツールが含まれるリポジトリーを定義する新たなパラメーター。Red Hat Satellite 6 に登録する場合はこのパラメーターを追加するようにしてください。
-
-
各ステップの後には、コントローラーノードのクラスターで
pcs status
コマンドを実行して、リソースにエラーが発生していないことを確認します。 - Red Hat OpenStack Platform 9 のデフォルトのタイムゾーンは UTC です。Red Hat OpenStack Platform 7 までは EST でした。必要な場合には、タイムゾーンを指定する環境ファイルを追加してください。
-
SSL/TLS を有効化したオーバークラウドをアップグレードする場合には、新規サービス用に最新の
EndpointMap
を指定してください。エンドポイントの最新リストは、アンダークラウドの/usr/share/openstack-tripleo-heat-templates/environments/enable-tls.yaml
にある環境ファイルの例を参照してください。SSL/TLS 設定に関する詳しい情報は、『Red Hat OpenStack Platform director のインストールと使用方法』の「6.11. オーバークラウドの SSL/TLS の有効化」 を参照してください。 -
カスタムの
ServiceNetMap
を使用してオーバークラウドをアップグレードする場合には、新規サービス向けに最新のServiceNetMap
を指定してください。サービスの最新リストは、『Red Hat OpenStack Platform director のインストールと使用方法』の「6.2.3. OpenStack サービスの分離ネットワークへの割り当て」 を参照してください。 director によって管理されているストレージノードがオーバークラウドに含まれている場合には、ノードに "client.openstack" CephX ユーザー用の新しいキーが必要です。Ceph Storage 用のその他のパラメーターが記載されている環境ファイル (通常は
storage-environment.yaml
) にCephClientKey
パラメーターを追加してください。オーバークラウドノードで新しいキーを生成します。$ ceph-authtool --gen-print-key AQAfoaRXSAy/HxAAShHIViinopC2xtPW+RceQA==
生成したキーを環境ファイルの
CephClientKey
に追加します。parameter_defaults: CephStorageCount: 3 CephClusterFSID: '4b5c8c0a-ff60-454b-a1b4-9747aa737d19' CephMonKey: 'AQC+Ox1VmEr3BxAALZejqeHj50Nj6wJDvs96OQ=='' CephAdminKey: 'AQDLOh1VgEp6FRAAFzT7Zw+Y9V6JJExQAsRnRQ==' CephClientKey: 'AQAfoaRXSAy/HxAAShHIViinopC2xtPW+RceQA=='
オーバークラウドで TLS/SSL の有効化にカスタムのエンドポイントマップを使用している場合には、以下の新規サービスのエンドポイントとのマッピングを必ず更新してください。
- OpenStack Telemetry Metrics (gnocchi)
- OpenStack Telemetry Alarming (aodh)
- OpenStack Clustering (sahara)
コアの Heat テンプレートコレクションから最新の TLS/SSL マッピングを確認して (
/usr/share/openstack-tripleo-heat-templates/environments/enable-tls.yaml
のEndpointMap
を確認)、カスタムのenable-tls.yaml
ファイルのEndpointMap
に不足しているエンドポイントを追加します。詳しい情報は、『Red Hat OpenStack Platform director のインストールと使用方法』の「オーバークラウドの SSL/TLS の有効化」を参照してください。
3.4.2. 変更されたオーバークラウドテンプレートの使用
本セクションに記載の内容は、コア Heat テンプレートコレクションを使用している場合にのみ必要です。これはコピーに、/usr/share/openstack-tripleo-heat-templates/
にある元のコア Heat テンプレートコレクションの静的なスナップショットが使用されるためです。 オーバークラウドに未変更のコア Heat テンプレートコレクションを使用する場合には、本セクションのステップは省略してください。
変更されたテンプレートコレクションを更新するには、以下の作業を行う必要があります。
既存のカスタムテンプレートコレクションをバックアップします。
$ mv ~/templates/my-overcloud/ ~/templates/my-overcloud.bak
/usr/share/openstack-tripleo-heat-templates にあるテンプレートコレクションの新しいバージョンを置き換えます。
$ sudo cp -rv /usr/share/openstack-tripleo-heat-templates ~/templates/my-overcloud/
古いバージョンと新しいバージョンのカスタムテンプレートコレクションの差異を確認します。これらの 2 つの間の変更を確認するには、以下の diff コマンドを使用します。
$ diff -Nary ~/templates/my-overcloud.bak/ ~/templates/my-overcloud/
これは、新規テンプレートコレクションに取り入れることが可能な旧テンプレートコレクションのカスタマイズを特定するのに役立ちます。新規カスタムテンプレートコレクションにカスタマイズの設定を取り入れます。
Red Hat は、今後のリリースで Heat テンプレートコレクションの更新を提供します。変更されたテンプレートコレクションを使用すると、カスタムのコピーと /usr/share/openstack-tripleo-heat-templates
にあるオリジナルのコピーとの間に相違が生じる可能性があります。オーバークラウドをカスタマイズするには、『Advanced Overcloud Customization』ガイドの「Configuration Hooks」のセクションを参照することを推奨します。Heat テンプレートコレクションのコピーを作成する場合には、git などのバージョン管理システムを使用して変更をトラッキングすべきです。
3.4.3. Aodh のインストール
このステップにより、旧 OpenStack Telemetry Alarming (ceilometer-alarm
) サービスが新しいコンポーネント (aodh
) に置き換えられます。このプロセスには、新しい環境ファイル (major-upgrade-aodh.yaml
) を指定して openstack overcloud deploy
コマンドを実行する必要があります。このコマンドにより、以下の操作が行われます。
-
Pacemaker から
openstack-ceilometer-alarm
サービスを自動的に削除し、Controller ノードから関連するパッケージを削除します。 -
コントローラーノードに
aodh
サービスをインストールし、Pacemaker がそのサービスを管理するように設定します。
アンダークラウドから、major-upgrade-aodh.yaml
の環境ファイル を指定して openstack overcloud deploy
を実行します。ネットワークの分離やストレージなどお使いの環境に関連するカスタムの環境ファイルも含めるようにしてください。
以下は、openstack overcloud deploy
コマンドで、ファイルも追加した例です。
$ openstack overcloud deploy --force-postconfig --templates \ --control-scale 3 \ --compute-scale 3 \ -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_env.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/major-upgrade-aodh.yaml
最終のデプロイメントコマンドには --force-postconfig
オプションを必ず指定してください。このオプションを使用しなかった場合には、オーバークラウドでの新規サービスポイントの表示が失敗します。
新しい環境ファイルの設定でオーバークラウドが更新されるまで待ちます。
コントローラーノードにログインして pcs status
コマンドを実行し、コントローラークラスター内の全リソースがアクティブかどうかを確認します。いずれかのリソースが失敗した場合には、pcs resource cleanup
を実行してエラーをクリーニングし、各リソースの状態を Started
に設定します。エラーが引き続き発生する場合には、Red Hat にヘルプ / サポートをリクエストしてください。
3.4.4. Keystone のアップグレード
このステップでは、OpenStack Identity (keystone
) サービスがコントローラーノードでスタンドアロンのサービスとして実行される代わりに httpd
下で Web Server Gateway Interface (WSGI) アプレットとして実行されるようにアップグレードします。このプロセスにより、スタンドアロンの openstack-keystone
サービスは自動的に無効化され、WSGI アプレットを有効化するのに必要な設定がインストールされます。
アンダークラウドから major-upgrade-keystone-liberty-mitaka.yaml
の環境ファイルを指定して openstack overcloud deploy
を実行します。ネットワークの分離やストレージなどお使いの環境に関連するカスタムの環境ファイルも含めるようにしてください。
以下は、openstack overcloud deploy
コマンドで、ファイルも追加した例です。
$ openstack overcloud deploy --templates \ --control-scale 3 \ --compute-scale 3 \ -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_env.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/major-upgrade-keystone-liberty-mitaka.yaml
新しい環境ファイルの設定でオーバークラウドが更新されるまで待ちます。
コントローラーノードにログインして pcs status
コマンドを実行し、コントローラークラスター内の全リソースがアクティブかどうかを確認します。いずれかのリソースが失敗した場合には、pcs resource cleanup
を実行してエラーをクリーニングし、各リソースの状態を Started
に設定します。エラーが引き続き発生する場合には、Red Hat にヘルプ / サポートをリクエストしてください。
3.4.5. アップグレードスクリプトのインストール
このステップでは、コントローラー以外の各ノードにスクリプトをインストールします。これらのスクリプトは、メジャーバージョンのパッケージアップグレードおよび設定を実行します。各スクリプトは、ノードタイプによって異なります。たとえば、コンピュートノードにインストールされるアップグレードのスクリプトは、Ceph Storage ノードにインストールされるスクリプトとは異なります。
この初期化のステップにより、全オーバークラウド上で有効なリポジトリーの更新も行われるので、手動で古いリポジトリーを無効にして新しいリポジトリーを有効にする必要はありません。
アンダークラウドから major-upgrade-pacemaker-init.yaml
の環境ファイルを指定して openstack overcloud deploy
を実行します。ネットワークの分離やストレージなどお使いの環境に関連するカスタムの環境ファイルも含めるようにしてください。
以下は、openstack overcloud deploy
コマンドで、ファイルも追加した例です。
$ openstack overcloud deploy --templates \ --control-scale 3 \ --compute-scale 3 \ -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_env.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/major-upgrade-pacemaker-init.yaml
新しい環境ファイルの設定でオーバークラウドが更新されるまで待ちます。
コントローラーノードにログインして pcs status
コマンドを実行し、コントローラークラスター内の全リソースがアクティブかどうかを確認します。いずれかのリソースが失敗した場合には、pcs resource cleanup
を実行してエラーをクリーニングし、各リソースの状態を Started
に設定します。エラーが引き続き発生する場合には、Red Hat にヘルプ / サポートをリクエストしてください。
3.4.6. Object Storage ノードのアップグレード
director は upgrade-non-controller.sh
コマンドを使用してアップグレードのスクリプトを実行します。このスクリプトは、major-upgrade-pacemaker-init.yaml
環境ファイルから、コントローラー以外の各ノードに渡されます。このステップでは、各 Object Storage ノードを以下のコマンドでアップグレードします。
$ for NODE in `nova list | grep swift | awk -F "|" '{ print $2 }'` ; do upgrade-non-controller.sh --upgrade $NODE ; done
各 Object Storage ノードのアップグレードが完了するまで待ちます。
各ノードで /var/log/yum.log
ファイルをチェックして、kernel
または openvswitch
のパッケージのメジャー/マイナーバージョンが更新されているかどうかを確認します。更新されている場合には、各ノードを再起動します。
再起動する Object Storage ノードを選択します。そのノードにログインして再起動します。
$ sudo reboot
- ノードが起動するまで待ちます。
ノードにログインして、ステータスを確認します。
$ sudo systemctl list-units "openstack-swift*"
- ノードからログアウトして、次の Object Storage ノードでこのプロセスを繰り返します。
コントローラーノードにログインして pcs status
コマンドを実行し、コントローラークラスター内の全リソースがアクティブかどうかを確認します。いずれかのリソースが失敗した場合には、pcs resource cleanup
を実行してエラーをクリーニングし、各リソースの状態を Started
に設定します。エラーが引き続き発生する場合には、Red Hat にヘルプ / サポートをリクエストしてください。
3.4.7. コントローラーノードのアップグレード
コントローラーノードをアップグレードする際には、高可用性ツールを実行するコントローラーノードへの完全アップグレードを提供する別の環境ファイル (major-upgrade-pacemaker.yaml
) を指定する必要があります。
アンダークラウドから major-upgrade-pacemaker.yaml
の環境ファイルを指定して openstack overcloud deploy
を実行します。ネットワークの分離やストレージなど環境に関連するカスタムの環境ファイルも指定するようにしてください。
以下は、openstack overcloud deploy
コマンドで、ファイルも追加した例です。
$ openstack overcloud deploy --templates \ --control-scale 3 \ --compute-scale 3 \ -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 network_env.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/major-upgrade-pacemaker.yaml
新しい環境ファイルの設定でオーバークラウドが更新されるまで待ちます。
このステップは、コントローラーのアップグレードの際に Neutron サーバーおよび L3 エージェントを無効化します。これは、Floating IP アドレスがこのステップでは利用できないということを意味します。
各ノードで /var/log/yum.log
ファイルをチェックして、kernel
または openvswitch
のパッケージのメジャー/マイナーバージョンが更新されているかどうかを確認します。更新されている場合には、各ノードを再起動します。
再起動するノードを選択します。そのノードにログインして再起動します。
$ sudo reboot
クラスター内の残りのコントローラーノードは、再起動中も高可用性サービスが保持されます。
- ノードが起動するまで待ちます。
ノードにログインして、クラスターのステータスを確認します。
$ sudo pcs status
このノードは、クラスターに再度参加します。
注記再起動後に失敗するサービスがあった場合には、sudo
pcs resource cleanup
を実行し、エラーを消去して各リソースの状態をStarted
に設定します。エラーが引き続き発生する場合には、Red Hat にアドバイス/サポートをリクエストしてください。コントローラーノード上の全
systemd
サービスがアクティブであることを確認します。$ sudo systemctl list-units "openstack*" "neutron*" "openvswitch*"
- ノードからログアウトして、次に再起動するコントローラーノードを選択し、すべてのコントローラーノードが再起動されるまでこの手順を繰り返します。
3.4.8. Ceph Storage ノードのアップグレード
director は upgrade-non-controller.sh
コマンドを使用してアップグレードのスクリプトを実行します。このスクリプトは、major-upgrade-pacemaker-init.yaml
環境ファイルから、コントローラー以外の各ノードに渡されます。このステップでは、各 Ceph Storage ノードを以下のコマンドでアップグレードします。
各 Ceph Storage ノードをアップグレードします。
$ for NODE in `nova list | grep ceph | awk -F "|" '{ print $2 }'` ; do upgrade-non-controller.sh --upgrade $NODE ; done
各ノードで /var/log/yum.log
ファイルをチェックして、kernel
または openvswitch
のパッケージのメジャー/マイナーバージョンが更新されているかどうかを確認します。更新されている場合には、各ノードを再起動します。
- 再起動する最初の Ceph Storage ノードを選択して、ログインします。
Ceph Storage クラスターのリバランシングを一時的に無効にします。
$ sudo ceph osd set noout $ sudo ceph osd set norebalance
ノードを再起動します。
$ sudo reboot
- ノードが起動するまで待ちます。
ノードにログインして、クラスターのステータスを確認します。
$ sudo ceph -s
pgmap
により、すべてのpgs
が正常な状態 (active+clean
) として報告されることを確認します。- ノードからログアウトして、次のノードを再起動し、ステータスを確認します。全 Ceph Storage ノードすべてが再起動されるまで、このプロセスを繰り返します。
操作が完了したら、クラスターのリバランシングを再度有効にします。
$ sudo ceph osd unset noout $ sudo ceph osd unset norebalance
最終のステータスチェックを実行して、クラスターが
HEALTH_OK
と報告することを確認します。$ sudo ceph status
コントローラーノードにログインして pcs status
コマンドを実行し、コントローラークラスター内の全リソースがアクティブかどうかを確認します。いずれかのリソースが失敗した場合には、pcs resource cleanup
を実行してエラーをクリーニングし、各リソースの状態を Started
に設定します。エラーが引き続き発生する場合には、Red Hat にヘルプ / サポートをリクエストしてください。
3.4.9. コンピュートノードのアップグレード
コンピュートノードを個別にアップグレードして、OpenStack Platform 環境のインスタンスのダウンタイムがゼロになるようにします。この操作は、以下のワークフローに従って実行します。
- アップグレードするコンピュートノードを選択します。
- インスタンスを別のコンピュートノードに移行します。
- 空のコンピュートノードをアップグレードします。
全コンピュートノードとその UUID を一覧表示します。
$ nova list | grep "compute"
アップグレードするコンピュートノードを選択してから、まず最初に以下の手順に従ってそのノードのインスタンスを移行します。
アンダークラウドから、再起動するコンピュートノードを選択し、そのノードを無効にします。
$ source ~/overcloudrc $ openstack compute service list $ openstack compute service set [hostname] nova-compute --disable
コンピュートノード上の全インスタンスを一覧表示します。
$ openstack server list --host [hostname]
インスタンスの移行のターゲットホストとして機能する 2 番目のコンピュートノードを選択し、このホストには、移行されるインスタンスをホストするのに十分なリソースが必要です。無効化されたホストからターゲットホストに各インスタンスを移行する操作をアンダークラウドから実行します。
$ nova live-migration [instance-name] [target-hostname] $ nova migration-list $ nova resize-confirm [instance-name]
- コンピュートノードからすべてのインスタンスが移行されるまで、このステップを繰り返します。
インスタンスの設定と移行の詳しい手順は、『director のインストールと使用方法』の「オーバークラウドのコンピュートノードからの仮想マシンの移行」を参照してください。
director は upgrade-non-controller.sh
コマンドを使用してアップグレードのスクリプトを実行します。このスクリプトは、major-upgrade-pacemaker-init.yaml
環境ファイルから、コントローラー以外の各ノードに渡されます。以下のコマンドを実行して、各コンピュートノードをアップグレードします。
$ source ~/stackrc $ upgrade-non-controller.sh --upgrade NODE_UUID
NODE_UUID は、選択したコンピュートノードの UUID に置き換えます。コンピュートーノードのアップグレードが完了するまで待ちます。
アップグレードしたコンピュートノード上の /var/log/yum.log
ファイルをチェックして、kernel
または openvswitch
のパッケージがアップグレードされているかどうかを確認します。アップグレードされている場合には、各ノードのリブートを実行します。
コンピュートノードのログインしてリブートします。
$ sudo reboot
- ノードが起動するまで待ちます。
コンピュートノードを再度有効化します。
$ source ~/overcloudrc $ openstack compute service set [hostname] nova-compute --enable
- リブートする次のノードを選択します。
全ノードがリブートされるまで、各ノードで個別にマイグレーションとリブートのプロセスを繰り返します。
コントローラーノードにログインして pcs status
コマンドを実行し、コントローラークラスター内の全リソースがアクティブかどうかを確認します。いずれかのリソースが失敗した場合には、pcs resource cleanup
を実行してエラーをクリーニングし、各リソースの状態を Started
に設定します。エラーが引き続き発生する場合には、Red Hat にヘルプ / サポートをリクエストしてください。
3.4.10. アップグレードの最終処理
director には、アップグレードの最終処理を最後まで実行して、オーバークラウドスタックが現在の Heat テンプレートコレクションと確実に同期されるようにする必要があります。そのためには、openstack overcloud deploy
コマンドで環境ファイル (major-upgrade-pacemaker-converge.yaml
) を指定する必要があります。
アンダークラウドから major-upgrade-pacemaker-converge.yaml
の環境ファイルを指定して openstack overcloud deploy
を実行します。ネットワークの分離やストレージなどお使いの環境に関連するカスタムの環境ファイルも含めるようにしてください。
以下は、openstack overcloud deploy
コマンドで、ファイルも追加した例です。
$ openstack overcloud deploy --force-postconfig --templates \ --control-scale 3 \ --compute-scale 3 \ -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 network_env.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/major-upgrade-pacemaker-converge.yaml
最終のデプロイメントコマンドには --force-postconfig
オプションを必ず指定してください。このオプションを使用しなかった場合には、オーバークラウドでの新規サービスポイントの表示が失敗します。
新しい環境ファイルの設定でオーバークラウドが更新されるまで待ちます。
これで、オーバークラウドのアップグレード手順が完了しました。
コントローラーノードにログインして pcs status
コマンドを実行し、コントローラークラスター内の全リソースがアクティブかどうかを確認します。いずれかのリソースが失敗した場合には、pcs resource cleanup
を実行してエラーをクリーニングし、各リソースの状態を Started
に設定します。エラーが引き続き発生する場合には、Red Hat にヘルプ / サポートをリクエストしてください。
3.4.11. オーバークラウドのアップグレード後の注意事項
オーバークラウドを Red Hat OpenStack Platform 9 にアップグレードした後には以下の点に注意してください。
コンピュートノードが
neutron-openvswitch-agent
の問題をレポートする可能性があります。これが発生した場合には、各コンピュートノードにログインして、このサービスを再起動します。以下のようなコマンドを実行します。$ sudo systemctl restart neutron-openvswitch-agent
-
更新プロセスを実行しても、オーバークラウド内のノードは自動的には再起動しません。必要な場合には、更新コマンドが完了した後に手動で再起動を実行してください。クラスターベースのノード (Ceph Storage ノードやコントローラーノード) を個別に再起動して、ノードがクラスターに再度参加するまで待ちます。Ceph Storage ノードの場合は、
ceph health
で確認して、クラスターのステータスがHEALTH OK
であることを確認します。コントローラーノードの場合は、pcs resource
で確認して、各ノードですべてのリソースが実行されていることを確認してください。 状況によっては、コントローラーノードの再起動後に IPv6 環境で
corosync
サービスの起動に失敗する可能性があります。これは、コントローラーノードが静的な IPv6 アドレスを設定する前に Corosync が起動してしまうことが原因です。このような場合は、コントローラーノードで Corosync を手動で再起動してください。$ sudo systemctl restart corosync
コントローラーノードにフェンシングを設定している場合には、更新プロセスによってその設定が無効になる場合があります。更新プロセスの完了時には、コントローラーノードの 1 つで以下のコマンドを実行してフェンシングを再度有効にします。
$ sudo pcs property set stonith-enabled=true
次回に (
openstack overcloud deploy
コマンドを実行して) オーバークラウドのスタックを更新またはスケーリングする際には、オーバークラウドでのパッケージの更新をトリガーする ID をリセットする必要があります。環境ファイルに空のUpdateIdentifier
パラメーターを追加して、openstack overcloud deploy
コマンドの実行時にそのファイルを指定します。環境ファイルの内容の例を以下に示します。parameter_defaults: UpdateIdentifier: