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 11 が対象です。これには、アンダークラウドとオーバークラウドの両方の機能の更新が含まれます。
インスタンスの高可用性を実装している場合には、アップグレードやスケールアップはできないので (『コンピュートインスタンスの高可用性』で説明しています)、操作を試みても失敗してしまいます。
また、インスタンスの高可用性を有効にすると、将来、director を使用したアップグレードはできなくなります。これは、メジャーアップグレードとマイナーアップグレードの両方に該当します。詳しくは、https://access.redhat.com/ja/solutions/2898841 を参照してください。
この手順は、いずれの場合も以下のワークフローに従って作業を行います。
- Red Hat OpenStack Platform director パッケージの更新
- Red Hat OpenStack Platform director でのオーバークラウドイメージの更新
- Red Hat OpenStack Platform director を使用したオーバークラウドパッケージの更新
Red Hat は、更新を実行する前に以下の作業を済ませておくことを推奨します。
- アップグレード手順のステップを開始する前に、アンダークラウドノードのバックアップを実行してください。バックアップの手順については、『director のアンダークラウドのバックアップと復元』ガイドを参照してください。
- 実稼働環境で手順を実行する前に、すべての変更が加えられたテスト環境で更新の手順を実行します。
- 更新を実行するにあたってアドバイスやサポートが必要な場合には、Red Hat までご連絡ください。
2.1. director パッケージの更新
director は、標準の RPM メソッドを使用して環境を更新します。このメソッドでは、yum コマンドを実行して、director のホストが確実に最新のパッケージを使用するようにします。
-
director に
stackユーザーとしてログインします。 主要な OpenStack Platform サービスを停止します。
$ sudo systemctl stop 'openstack-*' 'neutron-*' httpd
注記これにより、アンダークラウドで短時間のダウンタイムが生じます。アンダークラウドの更新中もオーバークラウドは引き続き機能します。
python-tripleoclientパッケージと依存関係を更新し、マイナーバージョンの更新向けの最新のスクリプトを使用できるようにします。$ sudo yum update -y instack-undercloud openstack-puppet-modules openstack-tripleo-common python-tripleoclient
director は
openstack undercloud upgradeコマンドを使用して、アンダークラウドの環境を更新します。以下のコマンドを実行します。$ openstack undercloud upgrade
ノードを再起動して、新しいシステム設定を有効にし、全アンダークラウドサービスを更新します。
ノードを再起動します。
$ sudo reboot
- ノードが起動するまで待ちます。
ノードが起動したら、全サービスのステータスを確認します。
$ sudo systemctl list-units "openstack*" "neutron*" "openvswitch*"
再起動後に openstack-nova-compute が有効になるまでに約 10 分かかる場合があります。
オーバークラウドとそのノードが存在しているかどうかを確認します。
$ 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-11.0.tar /usr/share/rhosp-director-images/ironic-python-agent-latest-11.0.tar; do tar -xvf $i; done
最新のイメージを director にインポートして、ノードがこれらの新規イメージを使用するように設定します。
$ cd ~ $ openstack overcloud image upload --update-existing --image-path ~/images $ openstack overcloud node configure $(openstack baremetal node list -c UUID -f csv --quote none | sed "1d" | paste -s -d " ")
新規イメージの存在をチェックして、イメージの更新を最終確認します。
$ openstack image list $ ls -l /httpboot
director が更新され、最新のイメージを使用するようになりました。この更新の後にはサービスを再起動する必要はありません。
2.3. オーバークラウドパッケージの更新
オーバークラウドでは、環境の更新に標準の RPM メソッドを使用します。これには、以下の 2 つのステップを実行する必要があります。
元の
openstack overcloud deployコマンドに--update-plan-onlyオプションを追加して、現在のプランを更新します。以下に例を示します。$ openstack overcloud deploy --update-plan-only \ --templates \ -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>|...]
--update-plan-onlyのオプションを指定すると、director に保管されているオーバークラウドのプランのみが更新されます。-eオプションを使用して、オーバークラウドと関連のある環境ファイルとその更新パスを追加します。後で実行される環境ファイルで定義されているパラメーターとリソースが優先されることになるため、環境ファイルの順序は重要となります。以下の一覧は、環境ファイルの順序の例です-
Heat テンプレートコレクションの初期化ファイル (
environments/network-isolation.yaml) を含むネットワーク分離ファイルと、次にカスタムの NIC 設定ファイル - 外部のロードバランシングの環境ファイル
- ストレージの環境ファイル
- Red Hat CDN または Satellite 登録用の環境ファイル
- その他のカスタム環境ファイル
-
Heat テンプレートコレクションの初期化ファイル (
openstack overcloud updateコマンドを使用して、全ノードでパッケージの更新を実行します。以下に例を示します。$ openstack overcloud update stack -i overcloud
全ノードで並行して更新を実行すると問題が発生する可能性があります。たとえば、パッケージの更新には、サービスの再起動が必要となる場合があり、その操作によって他のノードが中断される可能性があります。そのため、このプロセスでは、一連のブレークポイントを設けて、ノードごとに更新します。1 つのノードでパッケージの更新が完了すると、更新プロセスは次のノードに移ります。更新のプロセスには、各ブレークポイントで確認が要求される対話モードでコマンドを実行するための
-iオプションも必要です。-iオプションを使用しない場合には、更新は最初のブレークポイントで一時停止の状態のままとなります。
これで更新のプロセスが開始します。このプロセス中に、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 インストールと使用方法』ガイドの「ノードの再起動」の手順に従って各ノードを再起動します。