11.3. オーバークラウドの更新
本項には、オーバークラウドの更新に必要な手順を記載します。各セクションを順番に従って進み、お使いの環境に関連するセクションのみを適用します。
11.3.1. 設定エージェント
重要
以下のセクションは、Red Hat Enterprise Linux OpenStack Platform 7.0 または 7.1 を Red Hat Enterprise Linux OpenStack Platform 7.2 以降のバージョンに更新する場合のみ必要です。
既知の問題 (BZ#1278181 を参照) が原因で、オーバークラウドは設定エージェントを一部手動で設定する必要があります。これには、設定エージェントのスクリプトの新しいバージョンを director からオーバークラウド内の各ノードにコピーする作業を伴います。
stack
ユーザーとして director ホストにログインし、アンダークラウドの設定ファイルを source コマンドで読み込みます。
$ source ~/stackrc
設定エージェント (
55-heat-config
) を各オーバークラウドノードにコピーします。この操作を行うには、以下のコマンドを使用して全ホストに対して実行します。
$ for i in `nova list|awk '/Running/ {print $(NF-1)}'|awk -F"=" '{print $NF}'`; do echo $i; scp -o StrictHostKeyChecking=no /usr/share/openstack-heat-templates/software-config/elements/heat-config/os-refresh-config/configure.d/55-heat-config heat-admin@${i}: ; ssh -o StrictHostKeyChecking=no heat-admin@${i} 'sudo /bin/bash -c "cp /home/heat-admin/55-heat-config /usr/libexec/os-refresh-config/configure.d/55-heat-config"'; done
これにより、設定エージェントは最新の状態となります。
このオーバークラウドは、デプロイ後のファイルをいくつか再作成する必要もあります。director には、これをアーカイブするためのスクリプトが含まれています。
heat-config-rebuild-deployed
スクリプトをコピーして実行します。この操作は、以下のコマンドを使用して全ノードに対して実行します。
$ for i in `nova list|awk '/Running/ {print $(NF-1)}'|awk -F"=" '{print $NF}'`; do echo $i; scp -o StrictHostKeyChecking=no /usr/share/openstack-heat-templates/software-config/elements/heat-config/bin/heat-config-rebuild-deployed heat-admin@${i}: ; ssh -o StrictHostKeyChecking=no heat-admin@${i} 'sudo /bin/bash -c "mkdir -p /usr/share/openstack-heat-templates/software-config/elements/heat-config/bin ; cp heat-config-rebuild-deployed /usr/share/openstack-heat-templates/software-config/elements/heat-config/bin/heat-config-rebuild-deployed ; chmod +x /usr/share/openstack-heat-templates/software-config/elements/heat-config/bin/heat-config-rebuild-deployed ; /usr/share/openstack-heat-templates/software-config/elements/heat-config/bin/heat-config-rebuild-deployed"' ; done
11.3.2. 変更済みのオーバークラウドテンプレート
重要
本セクションは、「カスタムのオーバークラウド Heat テンプレートの使用」 にある変更済みのテンプレートコレクションを使用する場合のみに必要です。これは、そのコピーが、
/usr/share/openstack-tripleo-heat-templates/
にある元の 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
にあるオリジナルのコピーとの間に相違が生じる可能性があります。Red Hat は、Heat テンプレートコレクションを変更する代わりに以下の項に記載する方法を使用することを推奨します。
Heat テンプレートコレクションのコピーを作成する場合には、
git
などのバージョン管理システムを使用して、テンプレートに加えられた変更をトラッキングすべきです。
11.3.3. 新規環境のパラメーター
更新した Heat テンプレートコレクションには、元の Red Hat Enterprise Linux OpenStack Platform 7.0 リリースには含まれていなかった新しいパラメーターがいくつか必要です。これらのパラメーターは今後の更新で追加することを推奨します。
カスタムの環境ファイル (
~/templates/param-updates.yaml
) に以下にあげる追加のパラメーターを記載します。
表11.1 含めるべき追加のパラメーター
新規パラメーター
|
説明
|
---|---|
ControlPlaneDefaultRoute
|
コントロールプレーンネットワークのデフォルトルート
|
EC2MetadataIp
|
EC2 メタデータサーバーの IP アドレス
|
例
parameter_defaults: ControlPlaneDefaultRoute: 192.168.1.1 EC2MetadataIp: 169.254.169.254
オーバークラウドの今後の更新時にこのファイルを追加するようにしてください。
11.3.4. バージョン固有の注意事項
本項には、director およびオーバークラウドの初期バージョン固有の注意事項を記載します。本項の記載内容は、今後の更新時にオーバークラウドスタックに追加する際の参考資料として利用してください。
OpenStack Platform director 7.0 を使用しており、OpenStack Platform director 7.2 以降にアップグレードする場合:
- 初回のクラウドデプロイメントに使用したのと同じ値の
ServiceNetMap
パラメーターを必ず使用するようにしてください (「OpenStack サービスの分離ネットワークへの割り当て」を参照)。初回のデプロイメントでカスタム値が使用されていた場合には、それと同じカスタム値を指定してください。7.0 からの更新でカスタムのServiceNetMap
値を初回デプロイメントで使用しなかった場合には、以下の環境ファイルを更新のコマンドに追加して、7.0 の値を保持します。/usr/share/openstack-tripleo-heat-templates/environments/updates/update-from-keystone-admin-internal-api.yaml
オーバークラウドの今後の更新時にこのファイルを追加するようにしてください。オーバークラウド作成後のServiceNetMap
値の変更は、現在サポートされていません。 - オーバークラウドに単一のネットワークを使用する場合 (例: オリジナルのデプロイメントに
network-isolation.yaml
が含まれていなかった場合) には、更新のコマンドに以下の環境ファイルを追加します。/usr/share/openstack-tripleo-heat-templates/environments/updates/update-from-publicvip-on-ctlplane.yaml
オーバークラウドの今後の更新時にこのファイルを追加するようにしてください。外部のロードバランサーを使用する場合にはこのファイルは必要ない点に注意してください。
OpenStack Platform director 7.1 を使用しており、OpenStack Platform director 7.2 以降にアップグレードする場合:
- 初回のクラウドデプロイメントに使用したのと同じ値の
ServiceNetMap
パラメーターを必ず使用するようにしてください (「OpenStack サービスの分離ネットワークへの割り当て」を参照)。初回のデプロイメントでカスタム値が使用されていた場合には、それと同じカスタム値を指定してください。7.1 からの更新でカスタムのServiceNetMap
の値を使用しなかった場合には、ServiceNetMap
に追加の環境ファイルや値を指定する必要はありません。オーバークラウドの作成後のServiceNetMap
値の変更は現在サポートされていません。 - 更新のコマンドに以下の環境ファイルを追加して、仮想 IP リソースが
vip.yaml
にマップされたままの状態となるようにします。/usr/share/openstack-tripleo-heat-templates/environments/updates/update-from-vip.yaml
オーバークラウドの今後の更新時にこのファイルを追加するようにしてください。外部のロードバランサーを使用する場合にはこのファイルは必要ない点に注意してください。 - 7.1 からの更新で外部のロードバランサーを使用しない場合には、
control_virtual_ip
の入力パラメーターにコントロール仮想 IP を指定します。これは、アップグレード中にリソースが置き換えられることが理由です。そのためには、以下のコマンドで、現在の control_virtual_ip アドレスを確認します。$ neutron port-show control_virtual_ip | grep ip_address {"subnet_id": "3d7c11e0-53d9-4a54-a9d7-55865fcc1e47", "ip_address": "192.0.2.21"} |
この仮想 IP を 「新規環境のパラメーター」に記載の~/templates/param-updates.yaml
の例のようなカスタムの環境ファイルに追加します。parameters: ControlFixedIPs: [{'ip_address':'192.0.2.21'}]
オーバークラウドの今後の更新時にこのファイルを追加するようにしてください。外部のロードバランサーを使用する場合にはこのファイルは必要ない点に注意してください。既存の Neutron ポートを削除します。$ neutron port-delete control_virtual_ip
更新プロセスにより、この仮想 IP は、元の IP アドレスを使用する新しいポートに置き換えられます。
OpenStack Platform director 7.2 から OpenStack Platform director 7.3 以降にアップグレードする場合:
- アンダークラウドの Heat では、既知の問題 (BZ#1305947 を参照) に対応するために、RPC 応答のタイムアウトを引き伸ばす必要があります。
/etc/heat/heat.conf
を編集して、以下のパラメーターに設定してください。rpc_response_timeout=600
次にすべての Heat サービスを再起動します。$ systemctl restart openstack-heat-api.service $ systemctl restart openstack-heat-api-cfn.service $ systemctl restart openstack-heat-engine.service
11.3.5. オーバークラウドパッケージの更新
オーバークラウドでは、環境の更新に標準の RPM メソッドを利用します。このメソッドでは、director から
openstack overcloud update
を使用して全ノードを更新します。
-e
を使用して、オーバークラウドと関連のある環境ファイルとアップグレードパスを追加します。後で実行される環境ファイルで定義されているパラメーターとリソースが優先されることになるため、環境ファイルの順序は重要となります。以下の一覧は、環境ファイルの順序の例です。
- Heat テンプレートコレクションの
overcloud-resource-registry-puppet.yaml
ファイル。このファイルは、openstack overcloud deploy
コマンドを実行する場合には自動的に含まれますが、openstack overcloud update
コマンドを実行する場合は必ず指定する必要があります。 - Heat テンプレートコレクションの初期化ファイル (
environments/network-isolation.yaml
) を含むネットワーク分離ファイルと、次にカスタムの NIC 設定ファイル。ネットワークの分離についての詳しい情報は、「VLAN への全ネットワークの分離」を参照してください。 - 外部のロードバランシングの環境ファイル
- ストレージの環境ファイル
- Red Hat CDN または Satellite 登録用の環境ファイル
- 「バージョン固有の注意事項」のバージョン固有の環境ファイル
- その他のカスタム環境ファイル
全ノードで並行して更新を実行すると問題が発生する可能性があります。たとえば、パッケージの更新には、サービスの再起動が必要となる場合があり、その操作によって他のノードが中断される可能性があります。そのため、この更新プロセスでは、一連のブレークポイントを設けて、ノードごとに更新します。1 つのノードでパッケージの更新が完了すると、更新プロセスは次のノードに移ります。更新のプロセスには、各ブレークポイントで確認が要求される対話モードでコマンドを実行するための
-i
オプションも必要です。-i
オプションを使用しない場合には、更新は最初のブレークポイントで一時停止の状態のままとなります。
director 7.1 から 7.2 に更新するコマンドの例を以下に示します。
$ 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 /usr/share/openstack-tripleo-heat-templates/environments/updates/update-from-vip.yaml \ -e /home/stack/templates/param-updates.yaml
このコマンドを実行すると更新のプロセスが開始します。このプロセス中に、director はブレークポイントを通過するためのプロンプトを定期的に表示します。以下に例を示します。
not_started: [u'overcloud-controller-0', u'overcloud-controller-1', u'overcloud-controller-2'] on_breakpoint: [u'overcloud-compute-0'] Breakpoint reached, continue?
Enter を押すと、
on_breakpoint
一覧の最後のノードからブレークポイントを通過します。これで、そのノードの更新が開始します。また、ノード名を入力して特定のノードでブレークポイントを通過したり、複数のノードで一度にブレークポイントを通過するための正規表現を入力することも可能です。ただし、複数のコントローラーノードで同時にブレークポイントを通過することはお勧めしません。全ノードが更新を完了するまで、このプロセスを継続します。
重要
更新のプロセスを実行する場合には、オーバークラウド内のノードは自動的には再起動されません。インスタンスのダウンタイムなしで環境を再起動する手順については、9章オーバークラウドのリブートを参照してください。
重要
コントローラーノードにフェンシングを設定している場合には、更新プロセスによってその設定が無効になる場合があります。 更新プロセスの完了時には、コントローラーノードの 1 つで以下のコマンドを実行してフェンシングを再度有効にします。
$ sudo pcs property set stonith-enabled=true