Menu Close

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 を参照してください。

いずれの場合の手順でも、以下のワークフローを実行していきます。

  1. Red Hat OpenStack Platform director パッケージの更新
  2. Red Hat OpenStack Platform director でのオーバークラウドイメージの更新
  3. Red Hat OpenStack Platform director を使用したオーバークラウドパッケージの更新

2.1. director パッケージの更新

director は、標準の RPM メソッドを使用して環境を更新します。このメソッドでは、yum コマンドを実行して、director のホストが確実に最新のパッケージを使用するようにします。

  1. director に stack ユーザーとしてログインします。
  2. 主要な OpenStack Platform サービスを停止します。

    $ sudo systemctl stop 'openstack-*' 'neutron-*' httpd
    注記

    これにより、アンダークラウドで短時間のダウンタイムが生じます。アンダークラウドの更新中もオーバークラウドは引き続き機能します。

  3. python-tripleoclient パッケージと依存関係を更新し、マイナーバージョンの更新向けの最新のスクリプトを使用できるようにします。

    $ sudo yum update python-tripleoclient
  4. 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 のパッケージのメジャーバージョンまたはマイナーバージョンが更新されているかどうかを確認し、更新されている場合には各ノードのリブートを実行します。

  1. ノードを再起動します。

    $ sudo reboot
  2. ノードが起動するまで待ちます。

ノードが起動したら、全サービスのステータスを確認します。

$ 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」の手順に従って各ノードを再起動します。