Red Hat Training
A Red Hat training course is available for Red Hat OpenStack Platform
第3章 director ベースの環境: メジャーバージョンのアップグレードの実行
最新のメジャーバージョンにアップグレードする前に、アンダークラウドとオーバークラウドが最新のマイナーバージョンに更新されていることを確認してください。これには、OpenStack Platform サービスとベースオペレーティングシステムの両方が含まれます。マイナーバージョンを更新するプロセスについては、Red Hat OpenStack Platform 10『Red Hat OpenStack Platform のアップグレード』の「director ベースの環境: マイナーバージョンへの更新の実行」の章を参照してください。先にマイナーバージョンを更新せずに、メジャーバージョンをアップグレードすると、アップグレードプロセスが失敗してしまう可能性があります。
インスタンスの高可用性を実装している場合には、アップグレードやスケールアップはできないので (『コンピュートインスタンスの高可用性』で説明しています)、操作を試みても失敗してしまいます。
また、インスタンスの高可用性を有効にすると、将来、director を使用したアップグレードはできなくなります。これは、メジャーアップグレードとマイナーアップグレードの両方に該当します。詳しくは、https://access.redhat.com/ja/solutions/2898841 を参照してください。
本章では、アンダークラウドとオーバークラウドを次のメジャーバージョンにアップグレードする方法を考察します。今回は、Red Hat OpenStack Platform 10 から Red Hat OpenStack Platform 11 へのアップグレードです。
この手順では以下のワークフローに従って作業を行います。
- Red Hat OpenStack Platform director パッケージのアップグレード
- Red Hat OpenStack Platform director でのオーバークラウドイメージのアップグレード
- カスタムの Heat テンプレートや環境ファイルなど、オーバークラウドのカスタマイズの更新
- コンボーザブルサービスのアップグレードをサポートする全ノードのアップグレード
- Object Storage の個別アップグレード
- コンピュートノードの個別アップグレード
- オーバークラウドのアップグレードの最終処理
3.1. アップグレードのサポートステートメント
アップグレードプロセスを成功させるには、メジャーバージョン間の変更に対応するための準備が必要です。以下のサポートステートメントを確認して、Red Hat OpenStack Platform のアップグレードのプランニングに役立ててください。
Red Hat OpenStack Platform director でのアップグレードは、ライブの実稼働環境で実行する前に、その環境固有の設定で全面的にテストする必要があります。Red Hat では、director を使用する場合の標準のオプションとして提供されているユースケースの大半とそれらの組み合わせを検証済みですが、可能な組み合わせの数が多いため、それらは完全に網羅されません。さらに、標準デプロイメントの設定が変更された場合には、手動または設定後のフックを使用して、実稼働用以外の環境でアップグレード機能をテストすることが極めて重要です。そのため、以下を実行することを推奨します。
- アンダークラウドノードのバックアップを実行してから、アップグレードの手順のステップを開始します。バックアップの手順は、 『director のアンダークラウドのバックアップと復元』ガイドを参照してください。
- カスタマイズされた設定を使用するアップグレード手順は、実稼働環境で実行する前にテスト環境で実行してください。
- このアップグレードの実行するにあたって懸念がある場合には、作業を開始する前に Red Hat のサポートチームに連絡して、アップグレードのプロセスについてのアドバイスおよびサポートを依頼してください。
本項で説明するアップグレードプロセスは、director を使ったカスタマイズにのみ対応しています。director を使用せずにオーバークラウドの機能をカスタマイズした場合は、以下のステップを実行してください。
- その機能を無効にします。
- オーバークラウドをアップグレードします。
- アップグレードの完了後に機能を再度有効にします。
これは、アップグレードがすべて完了するまで、カスタマイズされた機能が使用できないことを意味します。
Red Hat OpenStack Platform director 11 は、Red Hat OpenStack Platform の以前のオーバークラウドバージョンを管理できます。詳しい情報は、以下のサポートマトリックスを参照してください。
表3.1 Red Hat OpenStack Platform director 11 のサポートマトリックス
バージョン |
オーバークラウドの更新 |
オーバークラウドのデプロイ |
オーバークラウドのスケーリング |
Red Hat OpenStack Platform 11 |
Red Hat OpenStack Platform 11 および 10 |
Red Hat OpenStack Platform 11 および 10 |
Red Hat OpenStack Platform 11 および 10 |
旧バージョンのオーバークラウドを管理している場合には、以下の Heat テンプレートコレクションを使用してください。
-
Red Hat OpenStack Platform 10:
/usr/share/openstack-tripleo-heat-templates/newton/
以下に例を示します。
$ openstack overcloud deploy --templates /usr/share/openstack-tripleo-heat-templates/newton/ [OTHER_OPTIONS]
アップグレードの一般的なヒントは以下のとおりです。
-
各ステップの後には、コントローラーノードのクラスターで
pcs status
コマンドを実行して、リソースにエラーが発生していないことを確認します。 - このアップグレードの実行に関して何らかの懸念がある場合は、作業を開始する前に Red Hat に連絡して、アップグレードプロセスについてのアドバイスおよびサポートを依頼してください。
3.2. ライブマイグレーションの更新
コンピュートノードをアップグレードするには、ライブマイグレーションを有効化して、アップグレード中にインスタンスを利用可能な状態に確保する必要があります。 これには、OS::TripleO::Services::Sshd
サービスが必要です。このサービスは、Red Hat OpenStack Platform 10 の最新版にデフォルトのロールとして追加された新規サービスです。Red Hat OpenStack Platform 11 へのアップグレード中にライブマイグレーションが有効化されるようにするには、以下の手順を実行します。
- アンダークラウドを最新バージョンの Red Hat OpenStack Platform 10 に更新します。
-
デフォルトのロールデータファイルを使用する場合には、各ロールに
OS::TripleO::Services::Sshd
サービスが含まれていることを確認してください。カスタムのロールデータファイルを使用する場合には、この新しいサービスを各ロールに追加します。 -
OS::TripleO::Services::Sshd
サービスが含まれている最新バージョンの Red Hat OpenStack Platform 10 にオーバークラウドを更新します。 - Red Hat OpenStack Platform 11 へのアップグレードを開始します。
これにより、コンピュートノードが相互に SSH アクセスできるようになります。このアクセスは、ライブマイグレーションのプロセスで必要となります。
以前のバージョンの Red Hat OpenStack Platform では、最近のセキュリティー修正プログラム (CVE-2017-2637) によってライブマイグレーションが無効化されます。OS::TripleO::Services::Sshd
サービスは、Red Hat OpenStack Platform 10 以降のバージョンでこの問題を解決します。詳しくは、以下のリンクを参照してください。
3.3. オーバークラウドの確認
アップグレードを実行する前に、オーバークラウドが安定した状態であることをチェックします。director で以下のステップを実行して、オーバークラウド内の全サービスが稼働していることを確認してください。
高可用性サービスのステータスを確認します。
ssh heat-admin@[CONTROLLER_IP] "sudo pcs resource cleanup ; sleep 60 ; sudo pcs status"
[CONTROLLER_IP]
はコントローラーノードの IP アドレスに置き換えます。このコマンドは、オーバークラウドの Pacemaker クラスターを最新の状態に更新し、60 秒待ってからそのクラスターのステータスを報告します。オーバークラウドノードで、失敗した OpenStack Platform
systemd
サービスがあるかどうかを確認します。以下のコマンドは、失敗したサービスを全ノードで確認します。$ for IP in $(openstack server list -c Networks -f csv | sed '1d' | sed 's/"//g' | cut -d '=' -f2) ; do echo "Checking systemd services on $IP" ; ssh heat-admin@$IP "sudo systemctl list-units 'openstack-*' 'neutron-*' --state=failed --no-legend" ; done
各ノードで
os-collect-config
が実行中であることを確認します。以下のコマンドで、このサービスのステータスを各ノードでチェックします。$ for IP in $(openstack server list -c Networks -f csv | sed '1d' | sed 's/"//g' | cut -d '=' -f2) ; do echo "Checking os-collect-config on $IP" ; ssh heat-admin@$IP "sudo systemctl list-units 'os-collect-config.service' --no-legend" ; done
OpenStack Platform 10 でスタンドアロンの Keystone ノードを使用している場合には、keystone
と gnocchi
の間の競合が原因となって「openstack-gnocchi-statsd」サービスが正しく起動していない可能性があります。コントローラーノードまたは Telemetry ノードで「openstack-gnocchi-statsd」サービスを確認して、失敗した場合には、オーバークラウドのアップグレード前にサービスを再起動します。この問題は、BZ#1447422 で対処しています。
3.4. アンダークラウドのアップグレード
3.4.1. director のアップグレード
Red Hat OpenStack Platform director をアップグレードするには、以下の手順に従ってください。
-
director に
stack
ユーザーとしてログインします。 OpenStack Platform のリポジトリーを更新します。
$ sudo subscription-manager repos --disable=rhel-7-server-openstack-10-rpms $ sudo subscription-manager repos --enable=rhel-7-server-openstack-11-rpms
上記のコマンドは、
yum
が最新のリポジトリーを使用するように設定します。主要な OpenStack Platform サービスを停止します。
$ sudo systemctl stop 'openstack-*' 'neutron-*' httpd
注記これにより、アンダークラウドで短時間のダウンタイムが生じます。アンダークラウドのアップグレード中もオーバークラウドは引き続き機能します。
yum
で director の主要なパッケージをアップグレードします。$ sudo yum update -y instack-undercloud openstack-puppet-modules openstack-tripleo-common python-tripleoclient
重要デフォルトのプロビジョニング/コントロールプレーンネットワークは、
192.0.2.0/24
から192.168.24.0/24
に変更されています。このネットワークにデフォルト値を使用している場合には、undercloud.conf
で以下のパラメーターをチェックします。-
local_ip
-
network_gateway
-
undercloud_public_vip
-
undercloud_admin_vip
-
network_cidr
-
masquerade_network
-
dhcp_start
-
dhcp_end
.
openstack undercloud upgrade
コマンドを実行する前に、ネットワーク設定が適切に設定されていることを確認します。-
以下のコマンドでアンダークラウドをアップグレードします。
$ openstack undercloud upgrade
このコマンドにより、director のパッケージがアップグレードされ、director の設定が最新の状態に更新されて、バージョンの変更後に指定されていない設定内容が追加されます。このコマンドによって、オーバークラウドのスタックデータや環境内の既存のノードのデータなど、保存されたデータは削除されません。
ノードを再起動して、新しいシステム設定を有効にし、全アンダークラウドサービスを更新します。
ノードを再起動します。
$ 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
必要な場合には director で設定ファイルを確認します。アップグレードされたパッケージで、Red Hat OpenStack Platform 11 バージョンのサービスに適した .rpmnew
ファイルがインストールされている可能性があります。
3.4.2. オーバークラウドイメージのアップグレード
以下の手順では、ノードの検出とオーバークラウドのデプロイメントに向け最新のイメージが確保されるようにします。rhosp-director-images
および rhosp-director-images-ipa
のパッケージからの新規イメージは、アンダークラウドのアップグレードですでに更新されています。
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 は、最新のイメージを使用してアップグレードされました。
オーバークラウドのイメージのバージョンがアンダークラウドのバージョンに対応していることを確認してください。
3.5. オーバークラウドのアップグレード前の設定
3.5.1. Red Hat サブスクリプションの詳細
オーバークラウドのアップグレードを実行する前には、そのサブスクリプション情報を更新して、環境に最新のリポジトリーが使用されるようにします。Satellite の登録に環境ファイルを使用している場合には、その環境ファイルで以下のパラメーターを更新してください。
-
rhel_reg_repos
: オーバークラウドを有効化するためのリポジトリー。新しい Red Hat OpenStack Platform 11 リポジトリーを含みます。有効化するリポジトリーについては、「リポジトリーの要件」を参照してください。 -
rhel_reg_activation_key
: Red Hat OpenStack Platform 11 リポジトリー用の新規アクティベーションキー -
rhel_reg_sat_repo
:katello-agent
など、Red Hat Satellite 6 の管理ツールが含まれるリポジトリーを定義する新たなパラメーター。Red Hat Satellite 6 に登録する場合はこのパラメーターを更新するようにしてください。
環境ファイルのフォーマットについての詳しい情報および例は、『オーバークラウドの高度なカスタマイズ』ガイドの「オーバークラウドの登録」を参照してください。
3.5.2. 非推奨および新規のコンポーザブルサービス
以下の各項は、カスタムの roles_data.yaml
ファイルを使用してオーバークラウドロールを定義している場合に該当します。
カスタムの roles_data.yaml
ファイルから以下の非推奨サービスを削除します。
サービス | 説明 |
---|---|
|
このサービスは、他の Pacemaker サービスのコアの依存関係として機能していましたが、高可用性のコンポーザブルサービスに対応するために削除されました。 |
|
このサービスは、OpenStack Image Storage (glance) のイメージメタデータを提供していましたが、glance |
|
このサービスは、ノードのホスト名と IP アドレスで |
roles_data.yaml
ファイルに以下の新しいサービスを追加します。
サービス | 説明 |
---|---|
|
他のコンポーザブルサービス用のデータベース設定を提供する MariaDB クライアントをノード上で設定します。このサービスは、スタンドアロンのコンポーザブルサービスを使用する全ロールに追加してください。 |
|
OpenStack Compute (nova) Placement API を設定します。現在のオーバークラウドでスタンドアロンの |
|
OpenStack Telemetry Event Storage (panko) サービスを設定します。現在のオーバークラウドでスタンドアロンの |
|
全ノードに SSH アクセスを設定します。このアクセスは、インスタンスの移行に使用されます。 |
これらの新規サービスを必要とする可能性のある、オーバークラウドの別の箇所を更新します。以下に例を示します。
-
カスタムの
ServiceNetMap
パラメーター: カスタムのServiceNetMap
を指定してオーバークラウドをアップグレードする場合には、新規サービス向けに最新のServiceNetMap
が含まれるようにしてください。デフォルトのサービス一覧は、network/service_net_map.j2.yaml
ファイルのServiceNetMapDefaults
パラメーターで定義されます。カスタムのServiceNetMap
の使用方法については、『オーバークラウドの高度なカスタマイズ』の「ネットワークの分離」のセクションを参照してください。 - 外部ロードバランサー: 外部ロードバランサーを使用する場合には、新規サービスを外部ロードバランサーの設定に追加します。詳しくは、『オーバークラウド向けの外部のロードバランシング』を参照してください。
3.5.3. ロールの手動アップグレード
アップグレードプロセスにより、全ロール上のコンポーザブルサービスが段階的にアップグレードされます。ただし、一部のロールには、ノードの個別アップグレードを行って、インスタンスおよびサービスの可用性を確保する必要があります。以下のロールが対象となります。
ロール | 説明 |
---|---|
|
インスタンスの稼動状態を確保するために、ノードごとに個別のアップグレードを実行する必要があります。これらのノードのプロセスでは、アップグレードの前にそのノードからインスタンスを移行しておく必要があります。 |
|
オーバークラウドが Object Storage サービス (swift) を利用できる状態を確保するために、ノードごとに個別のアップグレードを実行する必要があります。 |
以下のアップグレードプロセスでは upgrade-non-controller.sh
コマンドを使用して、上記のロールのノードをアップグレードします。
Red Hat OpenStack Platform 11 のデフォルトの roles_data.yaml
ファイルでは、これらのロールに disable_upgrade_deployment: True
とマークされ、主要なコンポーザブルサービスのアップグレードプロセスで除外されます。この設定により、これらのロールが割り当てられたノードを個別にアップグレードすることが可能となります。ただし、これらのロールが含まれたカスタムの roles_data.yaml
ファイルを使用する場合には、Compute
および ObjectStorage
のロールの定義に disable_upgrade_deployment: True
パラメーターを必ず記載してください。以下に例を示します。
- name: Compute CountDefault: 1 disable_upgrade_deployment: True ServicesDefault: - OS::TripleO::Services::CACerts - OS::TripleO::Services::CephClient - OS::TripleO::Services::CephExternal ...
Compute ロールなど、手動のアップグレードが必要な他のカスタムロールには、disable_upgrade_deployment
を使用します。
3.5.4. ストレージバックエンド
一部のストレージバックエンドは、設定フックではなく、独自のコンポーザブルサービスを使用するように変更されました。カスタムストレージバックエンドを使用する場合には、environments
ディレクトリーで関連する環境ファイルに新規パラメーターとリソースが含まれているかどうかを確認してください。バックエンド用のカスタム環境ファイルを更新します。以下に例を示します。
-
NetApp Block Storage (cinder) バックエンドの場合は、デプロイメント内の新しい
environments/cinder-netapp-config.yaml
を使用してください。 -
Dell EMC Block Storage (cinder) バックエンドの場合は、デプロイメント内の新しい
environments/cinder-dellsc-config.yaml
を使用してください。 -
Dell EqualLogic Block Storage (cinder) バックエンドの場合は、デプロイメント内の新しい
environments/cinder-dellps-config.yaml
を使用してください。
NetApp Block Storage (cinder) バックエンドは、それぞれのバージョンに以下のリソースを使用していました。
-
OpenStack Platform 10 以前:
OS::TripleO::ControllerExtraConfigPre: ../puppet/extraconfig/pre_deploy/controller/cinder-netapp.yaml
-
OpenStack Platform 11:
OS::TripleO::Services::CinderBackendNetApp: ../puppet/services/cinder-backend-netapp.yaml
今回の変更の結果、このバックエンドには新しい OS::TripleO::Services::CinderBackendNetApp
リソースと、関連付けられたサービステンプレートを使用するようになりました。
3.5.5. NFV の設定
Red Hat OpenStack Platform 10 から Red Hat OpenStack Platform 11 にアップグレードすると、OVS パッケージもバージョン 2.5 から 2.6 に更新されます。OVS-DPDK が設定されている場合にこの移行をサポートするには、以下のガイドラインに従ってください。
Red Hat OpenStack Platform 11 は OVS クライアントモードで稼働します。
『Red Hat OpenStack Platform のアップグレード』を参照してアップグレードの準備を開始します。「コンポーザブルサービスのアップグレード」に従ってオーバークラウドのデプロイする前に、以下の手順に実行してください。
-
既存の
post-install.yaml
ファイルを、「付録A NFV アップグレードファイルのサンプル」に記載のサンプルファイルに置き換えます。 network-environment.yaml
ファイルに以下の変更を適用します。構成に応じて HostCpuList を変更します。 このパラメーターには、yaml ファイルで一重引用符と二重引用符の両方を必ず使用してください。
HostCpusList: "'3,5,7,19,21,23'"
構成に応じて NeutronDpdkSocketMemory を変更します。このパラメーターには、yaml ファイルで二重引用符のみを使用してください。
NeutronDpdkSocketMemory: "2048,2048"
NeutronVhostuserSocketDir を以下のように変更します。
NeutronVhostuserSocketDir: "/var/lib/vhost_sockets"
3.5.6. オーバークラウドのパラメーター
アップグレードを実行するにあたっては、オーバークラウドパラメーターについての以下の情報に注意してください。
-
カスタムの
ServiceNetMap
を指定してオーバークラウドをアップグレードする場合には、新規サービス向けに最新のServiceNetMap
が含まれるようにしてください。デフォルトのサービス一覧は、network/service_net_map.j2.yaml
ファイルのServiceNetMapDefaults
パラメーターで定義されます。カスタムのServiceNetMap
の使用方法については、『オーバークラウドの高度なカスタマイズ』の「ネットワークの分離」のセクションを参照してください。 - オーバークラウドネットワーク用の固定の仮想 IP アドレスは、新しいパラメーターと構文を使用します。『オーバークラウドの高度なカスタマイズ』ガイドの「予測可能な仮想 IP の割り当て」を参照してください。外部のロードバランシングを使用している場合には、『オーバークラウド向けの外部のロードバランシング』ガイドの「ロードバランシングのオプションの設定」も参照してください。
-
openstack overcloud deploy
コマンドの一部のオプションは非推奨になりました。これらのオプションの代わりに、同等の Heat パラメーターを使用すべきです。これらのパラメーターの対照表は、『director のインストールと使用方法』ガイドの「CLI ツールを使用したオーバークラウドの作成」を参照してください。 一部のコンポーザブルロールには Puppet の hieradata を設定する新規パラメーターが含まれています。以前 hieradata を使用してこれらのパラメーターを設定した場合には、オーバークラウドの更新で
Duplicate declaration
エラーが表示される可能性があります。このような場合には、コンポーザブルサービスパラメーターを使用します。たとえば、以下の設定は使用しないようにします。parameter_defaults: controllerExtraConfig: heat::config::heat_config: DEFAULT/num_engine_workers: value: 1
その代わりに、以下の設定を使用します。
parameter_defaults: HeatWorkers: 1
使用可能なパラメーターについては、『オーバークラウドのパラメーター』を参照してください。
3.5.7. カスタムのコアテンプレート
Red Hat OpenStack Platform 10 のコア Heat テンプレートコレクションの変更されたバージョンを使用している場合には、Red Hat OpenStack Platform 11 バージョンのコピーにカスタマイズを再度適用する必要があります。これには、『オーバークラウドの高度なカスタマイズ』ガイドの「カスタムのコア Heat テンプレートの使用」に記載した方法と同じように git
バージョン管理システムを使用してください。
Red Hat は、今後のリリースで Heat テンプレートコレクションの更新を提供しています。バージョン管理システムなしで変更されたテンプレートコレクションを使用すると、カスタムのコピーと /usr/share/openstack-tripleo-heat-templates
にあるオリジナルのコピーとの間に相違が生じる可能性があります。
カスタムの Heat テンプレートコレクションを使用する代わりとして、Red Hat では『オーバークラウドの高度なカスタマイズ』ガイドの「設定フック」に記載の方法を推奨しています。
3.6. オーバークラウドのアップグレード
3.6.1. オーバークラウドノードのアップグレード
オーバークラウドのアップグレードには、追加の環境ファイル (major-upgrade-composable-steps.yaml
) がデプロイメントに必要です。このファイルにより、disable_upgrade_deployment: True
パラメーターでマークされているロールを除いた全ノードに完全なアップグレードが提供されます。
アンダークラウドから major-upgrade-composable-steps.yaml
の環境ファイルを指定して openstack overcloud deploy
コマンドを実行します。ネットワークの分離やストレージなど環境に関連するオプションとカスタムの環境ファイルをすべて指定してください。
openstack overcloud deploy
コマンドで必須およびオプションのファイルを指定する例を以下に示します。
$ openstack overcloud deploy --templates \ --control-scale 3 \ --compute-scale 3 \ -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/net-single-nic-with-vlans.yaml \ -e network_env.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/major-upgrade-composable-steps.yaml \ --ntp-server pool.ntp.org
新しい環境ファイルの設定でオーバークラウドが更新されるまで待ちます。
このステップは、コントローラーのアップグレードの際に Neutron サーバーおよび L3 エージェントを無効化します。そのため、このステップの実行中には新規ルーターの作成はできません。
各ノードで /var/log/yum.log
ファイルをチェックして、kernel
または openvswitch
のパッケージのメジャー/マイナーバージョンが更新されているかどうかを確認します。更新されている場合には、『director のインストールと使用方法』ガイドの 「ノードの再起動」に記載の手順に従って、各ノードを再起動します。
major-upgrade-composable-steps.yaml
環境ファイルのデプロイ中には、disable_upgrade_deployment: True
パラメーターが指定されているロールの各ノードに対して director が特別なスクリプトを渡します。以下の項では、アンダークラウドからこのスクリプトを起動して残りのロールをアップグレードする方法について説明します。
このコマンドは、非推奨となったコンポーザブルサービスを削除して、Red Hat OpenStack Platform 11 向けの新規サービスをインストールします。非推奨および新しいサービスの一覧は、 「非推奨および新規のコンポーザブルサービス」 を参照してください。
3.6.2. Object Storage ノードのアップグレード
director は upgrade-non-controller.sh
コマンドを使用してアップグレードのスクリプトを実行します。このスクリプトは、major-upgrade-pacemaker-init.yaml
環境ファイルから、Object Storage ノードに渡されます。このステップでは、各 Object Storage ノードを以下のコマンドでアップグレードします。
$ for NODE in `openstack server list -c Name -f value --name objectstorage` ; do upgrade-non-controller.sh --upgrade $NODE ; done
各 Object Storage ノードを個別にアップグレードすることにより、アップグレード中にサービスの稼働状態を維持します。
各 Object Storage ノードのアップグレードが完了するまで待ちます。
各ノードで /var/log/yum.log
ファイルをチェックして、kernel
または openvswitch
のパッケージのメジャー/マイナーバージョンが更新されているかどうかを確認します。更新されている場合には、各ノードを再起動します。
再起動する Object Storage ノードを選択します。そのノードにログインして再起動します。
$ sudo reboot
- ノードが起動するまで待ちます。
ノードにログインして、ステータスを確認します。
$ sudo systemctl list-units "openstack-swift*"
- ノードからログアウトして、次の Object Storage ノードでこのプロセスを繰り返します。
コントローラーノードにログインして pcs status
コマンドを実行し、コントローラークラスター内の全リソースがアクティブかどうかを確認します。いずれかのリソースが失敗した場合には、pcs resource cleanup
を実行してエラーをクリーニングし、各リソースの状態を Started
に設定します。エラーが引き続き発生する場合には、Red Hat にヘルプ / サポートをリクエストしてください。
3.6.3. コンピュートノードのアップグレード
コンピュートノードを個別にアップグレードして、OpenStack Platform 環境のインスタンスのダウンタイムがゼロになるようにします。この操作は、以下のワークフローに従って実行します。
- アップグレードするコンピュートノードを選択します。
- インスタンスを別のコンピュートノードに移行します。
- 空のコンピュートノードをアップグレードします。
全コンピュートノードとその UUID を一覧表示します。
$ source ~/stackrc $ openstack server list | grep "compute"
アップグレードするコンピュートノードを選択してから、まず最初に以下の手順に従ってそのノードのインスタンスを移行します。
アンダークラウドから、再起動するコンピュートノードを選択し、そのノードを無効にします。
$ source ~/overcloudrc $ openstack compute service list $ openstack compute service set [hostname] nova-compute --disable
コンピュートノード上の全インスタンスを一覧表示します。
$ openstack server list --host [hostname] --all-projects
無効にしたホストから各インスタンスを移行します。以下のコマンドの 1 つを使用します。
選択した特定のホストにインスタンスを移行します。
$ openstack server migrate [instance-id] --live [target-host]--wait
nova-scheduler
により対象のホストが自動的に選択されるようにします。$ nova live-migration [instance-id]
注記nova
コマンドで非推奨の警告が表示される可能性がありますが、安全に無視することができます。
- 移行が完了するまで待ちます。
インスタンスがコンピュートノードから移行されたことを確認します。
$ openstack server list --host [hostname] --all-projects
- コンピュートノードからすべてのインスタンスが移行されるまで、このステップを繰り返します。
インスタンスの設定と移行の詳しい手順は、『director のインストールと使用方法』の「オーバークラウドのコンピュートノードからの仮想マシンの移行」を参照してください。
director は upgrade-non-controller.sh
コマンドを使用してアップグレードのスクリプトを実行します。このスクリプトは、major-upgrade-composable-steps.yaml
環境ファイルから、コントローラー以外の各ノードに渡されます。以下のコマンドを実行して、各コンピュートノードをアップグレードします。
$ source ~/stackrc $ upgrade-non-controller.sh --upgrade [NODE]
[NODE]
は選択したコンピュートノードの UUID または名前に置き換えます。コンピュートノードのアップグレードが完了するまで待ちます。
アップグレードしたコンピュートノード上の /var/log/yum.log
ファイルをチェックして、以下のいずれかのパッケージのメジャー/マイナーバージョンが更新されているかを確認します。
-
kernel
-
openvswitch
-
ceph-osd
(ハイパーコンバージド環境)
更新されている場合には、ノードの再起動を実行します。
コンピュートノードにログインして、再起動します。
$ sudo reboot
- ノードが起動するまで待ちます。
再度コンピュートノードを有効化します。
$ source ~/overcloudrc $ openstack compute service set [hostname] nova-compute --enable
コンピュートノードが有効化されているかどうかを確認します。
$ openstack compute service list
全ノードのアップグレードと再起動が完了するまで、各ノードでこのプロセスを個別に繰り返します。
全コンピュートノードをアップグレードした後には、stackrc
アクセスの情報を元に戻します。
$ source ~/stackrc
コントローラーノードにログインして pcs status
コマンドを実行し、コントローラークラスター内の全リソースがアクティブかどうかを確認します。いずれかのリソースが失敗した場合には、pcs resource cleanup
を実行してエラーをクリーニングし、各リソースの状態を Started
に設定します。エラーが引き続き発生する場合には、Red Hat にヘルプ / サポートをリクエストしてください。
3.6.4. アップグレードの最終処理
director には、アップグレードの最終処理を最後まで実行して、オーバークラウドスタックが現在の Heat テンプレートコレクションと確実に同期されるようにする必要があります。そのためには、openstack overcloud deploy
コマンドで環境ファイル (major-upgrade-converge.yaml
) を指定する必要があります。
Red Hat OpenStack Platform の環境が、以前のバージョン(例: Red Hat Ceph Storage 1.3) の外部の Ceph Storage Cluster と統合されている場合には、後方互換性を有効にする必要があります。そのためには、環境ファイル (例: /home/stack/templates/ceph-backwards-compatibility.yaml
) を作成して、以下の内容を記載します。
parameter_defaults: RbdDefaultFeatures: 1
このファイルの作成が完了したら、次のステップで openstack overcloud deploy
を実行する際に指定してください。
アンダークラウドから openstack overcloud deploy
を実行して、major-upgrade-converge.yaml
環境ファイルを指定します。Ceph の後方互換性 (該当する場合)、ネットワークの分離、ストレージなど、お使いの環境に関連するオプションおよびカスタム環境ファイルもすべて必ず追加するようにしてください。
major-upgrade-converge.yaml
ファイルを追加した openstack overcloud deploy
コマンドの一例を以下に示します。
$ openstack overcloud deploy --templates \ --control-scale 3 \ --compute-scale 3 \ -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/net-single-nic-with-vlans.yaml \ -e network_env.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/major-upgrade-converge.yaml \ --ntp-server pool.ntp.org
新しい環境ファイルの設定でオーバークラウドが更新されるまで待ちます。
コントローラーノードにログインして pcs status
コマンドを実行し、コントローラークラスター内の全リソースがアクティブかどうかを確認します。いずれかのリソースが失敗した場合には、pcs resource cleanup
を実行してエラーをクリーニングし、各リソースの状態を Started
に設定します。エラーが引き続き発生する場合には、Red Hat にヘルプ / サポートをリクエストしてください。
3.7. オーバークラウドのアップグレード後の注意事項
オーバークラウドを Red Hat OpenStack Platform 11 にアップグレードした後には以下の点に注意してください。
-
必要な場合にはオーバークラウドノードで作成された設定ファイルを確認します。アップグレードされたパッケージで、Red Hat OpenStack Platform 11 バージョンのサービスに適した
.rpmnew
ファイルがインストールされている可能性があります。 Red Hat OpenStack Platform 11 では、OpenStack Block Storage (cinder) API は新しい
sizelimit
フィルターを使用します。ただし、以下に記載する OpenStack Platform 9、OpenStack Platform 10、OpenStack Platform 11 の順でアップグレード行うアップグレードパスでは、この新規フィルターが更新されない可能性があります。コントローラーまたは Cinder API ノードで以下のコマンドを実行してフィルターを確認します。$ grep filter:sizelimit /etc/cinder/api-paste.ini -A1
フィルターは以下のように表示されるはずです。
[filter:sizelimit] paste.filter_factory = oslo_middleware.sizelimit:RequestBodySizeLimiter.factory
このように表示されない場合は、各コントローラーまたは Cinder API ノードの
/etc/cinder/api-paste.ini
ファイルの値を置き換えて、httpd
サービスを再起動します。$ sudo sed -i s/cinder.api.middleware.sizelimit/oslo_middleware.sizelimit/ /etc/cinder/api-paste.ini $ sudo systemctl restart httpd
コンピュートノードが
neutron-openvswitch-agent
の問題をレポートする可能性があります。これが発生した場合には、各コンピュートノードにログインして、このサービスを再起動します。以下のようなコマンドを実行します。$ sudo systemctl restart neutron-openvswitch-agent
状況によっては、コントローラーノードの再起動後に IPv6 環境で
corosync
サービスの起動に失敗する可能性があります。これは、コントローラーノードが静的な IPv6 アドレスを設定する前に Corosync が起動してしまうことが原因です。このような場合は、コントローラーノードで Corosync を手動で再起動してください。$ sudo systemctl restart corosync
コントローラーノードにフェンシングを設定している場合には、アップグレードプロセスによってその設定が無効になる場合があります。アップグレードプロセスの完了時には、コントローラーノードの 1 つで以下のコマンドを実行してフェンシングを再度有効にします。
$ sudo pcs property set stonith-enabled=true