Red Hat Training
A Red Hat training course is available for Red Hat OpenStack Platform
第2章 director ベースの環境: マイナーバージョンへの更新の実行
本項では、同じバージョンの Red Hat OpenStack Platform 環境の更新方法について考察します。この場合は、Red Hat OpenStack Platform 9 が対象です。これには、アンダークラウドとオーバークラウドの両方の機能の更新が含まれます。
インスタンスの高可用性を実装している場合には、アップグレードやスケールアップはできないので (『コンピュートインスタンスの高可用性』で説明しています)、操作を試みても失敗してしまいます。
また、インスタンスの高可用性を有効にすると、将来、director を使用したアップグレードはできなくなります。これは、メジャーアップグレードとマイナーアップグレードの両方に該当します。詳しくは、https://access.redhat.com/ja/solutions/2898841 を参照してください。
いずれの場合の手順でも、以下のワークフローを実行していきます。
- Red Hat OpenStack Platform director パッケージの更新
- Red Hat OpenStack Platform director でのオーバークラウドイメージの更新
- Red Hat OpenStack Platform director を使用したオーバークラウドパッケージの更新
2.1. director パッケージの更新
director は、標準の RPM メソッドを使用して環境を更新します。このメソッドでは、yum
コマンドを実行して、director のホストが確実に最新のパッケージを使用するようにします。
-
director に
stack
ユーザーとしてログインします。 主要な OpenStack Platform サービスを停止します。
$ sudo systemctl stop 'openstack-*' 'neutron-*' httpd
注記これにより、アンダークラウドで短時間のダウンタイムが生じます。アンダークラウドの更新中もオーバークラウドは引き続き機能します。
python-tripleoclient
パッケージと依存関係を更新し、マイナーバージョンの更新向けの最新のスクリプトを使用できるようにします。$ sudo yum update python-tripleoclient
director は
openstack undercloud upgrade
コマンドを使用して、アンダークラウドの環境を更新します。以下のコマンドを実行します。$ openstack undercloud upgrade
アンダークラウドのオペレーティングシステムが Red Hat Enterprise Linux 7.2 から 7.3 に更新された場合や、Open vSwitch のバージョンが 2.4 から 2.5 に更新された場合などで、カーネルまたは Open vSwitch のメジャー/マイナーバージョンが更新された後には、リブートが必要となります。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
2.2. オーバークラウドイメージの更新
アンダークラウドの更新プロセスにより、rhosp-director-images
および rhosp-director-images-ipa
パッケージから新規イメージアーカイブがダウンロードされる可能性があります。yum
ログをチェックして、新規イメージアーカイブが利用可能かどうかを確認してください。
$ sudo grep "rhosp-director-images" /var/log/yum.log
新規アーカイブが利用可能な場合には、現在のイメージを新規イメージに置き換えてください。新しいイメージをインストールするには、最初に 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 が更新され、最新のイメージを使用するようになりました。この更新の後にはサービスを再起動する必要はありません。
2.3. オーバークラウドパッケージの更新
オーバークラウドでは、環境の更新に標準の RPM メソッドを使用します。このメソッドでは、director から openstack overcloud update
を使用して全ノードを更新します。
-e
を使用して、オーバークラウドと関連のある環境ファイルとアップグレードパスを追加します。後で実行される環境ファイルで定義されているパラメーターとリソースが優先されることになるため、環境ファイルの順序は重要となります。以下の一覧は、環境ファイルの順序の例です。
-
Heat テンプレートコレクションからの
overcloud-resource-registry-puppet.yaml
ファイル。このファイルは、openstack overcloud deploy
コマンドを実行すると自動的に追加されますが、openstack overcloud update
コマンドの実行時にはこのファイルを指定する必要があります。 -
Heat テンプレートコレクションの初期化ファイル (
environments/network-isolation.yaml
) を含むネットワーク分離ファイルと、次にカスタムの NIC 設定ファイル - 外部のロードバランシングの環境ファイル
- ストレージの環境ファイル
- Red Hat CDN または Satellite 登録用の環境ファイル
- その他のカスタム環境ファイル
全ノードで並行して更新を実行すると問題が発生する可能性があります。たとえば、パッケージの更新には、サービスの再起動が必要となる場合があり、その操作によって他のノードが中断される可能性があります。そのため、この更新プロセスでは、一連のブレークポイントを設けて、ノードごとに更新します。1 つのノードでパッケージの更新が完了すると、更新プロセスは次のノードに移ります。更新のプロセスには、各ブレークポイントで確認が要求される対話モードでコマンドを実行するための -i
オプションも必要です。-i
オプションを使用しない場合には、更新は最初のブレークポイントで一時停止の状態のままとなります。
オーバークラウドを更新するコマンドの例を以下に示します。
$ openstack overcloud update stack overcloud -i \ --templates \ -e /usr/share/openstack-tripleo-heat-templates/overcloud-resource-registry-puppet.yaml \ -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>|...]
このコマンドを実行すると更新のプロセスが開始します。このプロセス中に、director は IN_PROGRESS
のステータスを報告して、ブレークポイントを通過するように定期的に要求します。以下に例を示します。
not_started: [u'overcloud-controller-0', u'overcloud-controller-1', u'overcloud-controller-2'] on_breakpoint: [u'overcloud-compute-0'] Breakpoint reached, continue? Regexp or Enter=proceed, no=cancel update, C-c=quit interactive mode:
Enter を押すと、on_breakpoint
一覧の最後のノードからブレークポイントを通過します。これで、そのノードの更新が開始します。また、ノード名を入力して特定のノードでブレークポイントを通過したり、複数のノードで一度にブレークポイントを通過するための Python ベースの正規表現を入力することも可能です。ただし、複数のコントローラーノードで同時にブレークポイントを通過することはお勧めしません。全ノードが更新を完了するまで、このプロセスを継続します。
更新が完了すると、コマンドにより COMPLETE
のステータスが報告されます。
... IN_PROGRESS IN_PROGRESS IN_PROGRESS COMPLETE update finished with status COMPLETE
コントローラーノードにフェンシングを設定している場合には、更新プロセスによってその設定が無効になる場合があります。更新プロセスの完了時には、コントローラーノードの 1 つで以下のコマンドを実行してフェンシングを再度有効にします。
$ sudo pcs property set stonith-enabled=true
更新プロセスを実行しても、オーバークラウド内のノードは自動的には再起動しません。カーネルまたは Open vSwitch のメジャー/マイナーバージョンが更新された場合 (例: オーバークラウドのオペレーティングシステムが Red Hat Enterprise Linux 7.2 から 7.3 に更新された場合や、Open vSwitch がバージョン 2.4 から 2.5 に更新された場合など) には再起動が必要です。各ノードの /var/log/yum.log
ファイルをチェックして、kernel
または openvswitch
のパッケージのメジャー/マイナーバージョンが更新されているかどうかを確認します。更新されている場合には、『Director Installation and Usage』ガイドの「Rebooting the Overcloud」の手順に従って各ノードを再起動します。