第2章 director ベースの環境: マイナーバージョンへの更新の実行

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

アンダークラウドのオペレーティングシステムが Red Hat Enterprise Linux 7.2 から 7.3 に更新された場合や、Open vSwitch のバージョンが 2.4 から 2.5 に更新された場合などで、カーネルまたは Open vSwitch のメジャー/マイナーバージョンが更新された後には、リブートが必要となります。director ノードの /var/log/yum.log ファイルをチェックして、kernel または openvswitch のパッケージのメジャーバージョンまたはマイナーバージョンが更新されているかどうかを確認し、更新されている場合には各ノードのリブートを実行します。

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

$ sudo systemctl list-units "openstack*" "neutron*" "openvswitch*"

オーバクラウドとそのノードが存在しているかどうかを確認します。

$ source ~/stackrc
$ openstack server list
$ openstack baremetal node list
$ openstack stack list

アンダークラウドの更新プロセスにより、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 が更新され、最新のイメージを使用するようになりました。この更新の後にはサービスを再起動する必要はありません。

オーバークラウドでは、環境の更新に標準の RPM メソッドを使用します。このメソッドでは、director から openstack overcloud update を使用して全ノードを更新します。

-e を使用して、オーバークラウドと関連のある環境ファイルとアップグレードパスを追加します。後で実行される環境ファイルで定義されているパラメーターとリソースが優先されることになるため、環境ファイルの順序は重要となります。以下の一覧は、環境ファイルの順序の例です。

全ノードで並行して更新を実行すると問題が発生する可能性があります。たとえば、パッケージの更新には、サービスの再起動が必要となる場合があり、その操作によって他のノードが中断される可能性があります。そのため、この更新プロセスでは、一連のブレークポイントを設けて、ノードごとに更新します。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」の手順に従って各ノードを再起動します。