Red Hat Training

A Red Hat training course is available for Red Hat OpenStack Platform

第3章 director ベースの環境: メジャーバージョンへのアップグレードの実行

警告

最新のメジャーバージョンにアップグレードする前に、アンダークラウドとオーバークラウドが最新のマイナーバージョンに更新されていることを確認してください。これには、OpenStack Platform サービスとベースオペレーティングシステムの両方が含まれます。マイナーバージョンを更新するプロセスについては、Red Hat OpenStack Platform 9『Red Hat OpenStack Platform のアップグレード』の「director ベースの環境: マイナーバージョンへの更新の実行」の章を参照してください。先にマイナーバージョンを更新せずに、メジャーバージョンをアップグレードすると、アップグレードプロセスが失敗してしまう可能性があります。

警告

With High Availaibility for Compute instances (or Instance HA, as described in High Availability for Compute Instances), upgrades or scale-up operations are not possible. Any attempts to do so will fail.

If you have Instance HA enabled, disable it before performing an upgrade or scale-up. To do so, perform a rollback as described in Rollback.

本章では、環境のアップグレードの方法を考察します。これには、アンダークラウドとオーバークラウドの両方の機能の更新が含まれます。このアップグレードプロセスでは、次のメジャーバージョンに移行する手段を提供します。今回は、Red Hat OpenStack Platform 9 から Red Hat OpenStack Platform 10 へのアップグレードです。

この手順は、いずれの場合も以下のワークフローに従って作業を行います。

  1. Red Hat OpenStack Platform director パッケージのアップグレード
  2. Red Hat OpenStack Platform director でのオーバークラウドイメージのアップグレード
  3. Red Hat OpenStack Platform director を使用したオーバークラウドスタックとパッケージのアップグレード

3.1. アップグレードのサポートステートメント

アップグレードプロセスを成功させるには、メジャーバージョン間の変更に対応するための準備が必要です。以下のサポートステートメントを確認して、Red Hat OpenStack Platform のアップグレードのプランニングに役立ててください。

Red Hat OpenStack Platform director でのアップグレードは、ライブの実稼働環境で実行する前に、その環境固有の設定で全面的にテストする必要があります。Red Hat では、director を使用する場合の標準のオプションとして提供されているユースケースの大半とそれらの組み合わせを検証済みですが、可能な組み合わせの数が多いため、それらは完全に網羅されません。さらに、標準デプロイメントの設定が変更された場合には、手動または設定後のフックを使用して、実稼働用以外の環境でアップグレード機能をテストすることが極めて重要です。そのため、以下を実行することを推奨します。

  • アンダークラウドノードのバックアップを実行してから、アップグレードの手順のステップを開始します。バックアップの手順は、 『Back Up and Restore the Director Undercloud』ガイドを参照してください。
  • カスタマイズされた設定を使用するアップグレード手順は、実稼働環境で実行する前にテスト環境で実行してください。
  • このアップグレードの実行するにあたって懸念がある場合には、作業を開始する前に Red Hat のサポートチームにご連絡いただき、アップグレードのプロセスについてのアドバイスおよびサポートを依頼してください。

本項で説明するアップグレードプロセスは、director を使ったカスタマイズにのみ対応しています。director を使用せずにオーバークラウドの機能をカスタマイズした場合は、以下のステップを実行してください。

  • その機能を無効にします。
  • オーバークラウドをアップグレードします。
  • アップグレードの完了後に機能を再度有効にします。

これは、アップグレードがすべて完了するまで、カスタマイズされた機能が使用できないことを意味します。

Red Hat OpenStack Platform director 10 は、Red Hat OpenStack Platform の以前のオーバークラウドバージョンを管理できます。詳しい情報は、以下のサポートマトリックスを参照してください。

表3.1 Red Hat OpenStack Platform director 10 のサポートマトリックス

バージョン

オーバークラウドの更新

オーバークラウドのデプロイ

オーバークラウドのスケーリング

Red Hat OpenStack Platform 10

Red Hat OpenStack Platform 9 および 10

Red Hat OpenStack Platform 9 および 10

Red Hat OpenStack Platform 9 および 10

旧バージョンのオーバークラウドを管理している場合には、以下の Heat テンプレートコレクションを使用してください。

  • Red Hat OpenStack Platform 9 の場合: /usr/share/openstack-tripleo-heat-templates/mitaka/

以下に例を示します。 

$ openstack overcloud deploy --templates /usr/share/openstack-tripleo-heat-templates/mitaka/ [OTHER_OPTIONS]

アップグレードの一般的なヒントは以下のとおりです。

  • 各ステップの後には、コントローラーノードのクラスターで pcs status コマンドを実行して、リソースにエラーが発生していないことを確認します。
  • このアップグレードの実行に関して何らかの懸念がある場合は、作業を開始する前に Red Hat に連絡して、アップグレードプロセスについてのアドバイスおよびサポートを依頼してください。

3.2. アップグレード前の重要な注記

  • Red Hat OpenStack Platform 10 では、Red Hat Enterprise Linux 7.3 で利用可能となった、一部の新しいカーネルパラメーターを使用します。アンダークラウドとオーバークラウドを Red Hat Enterprise Linux 7.3 と Open vSwitch 2.5 にアップグレードしてください。アンダークラウドとオーバークラウドに対してパッケージの更新を実行する手順は、「director ベースの環境: マイナーバージョンへの更新の実行」を参照してください。カーネルを最新バージョンに更新した場合には、システムを再起動して、新しいカーネルパラメーターが有効になるようにしてください。
  • OpenStack Platform 10 のアップグレード手順を実行すると、新しいコンポーザぶるアーキテクチャーに移行されます。これは、以前のバージョンでは Pacemaker によって管理されていたサービスの多くが systemd の管理機能を使用することになります。このため、Pacemaker によって管理されるリソースの数が削減されます。
  • 以前のバージョンの Red Hat OpenStack Platform では、OpenStack Telemetry (ceilometer) はメトリックのストレージに自らのデータベースを使用していました。Red Hat OpenStack Platform 10 では、OpenStack Telemetry のデフォルトのバックエンドとして、OpenStack Telemetry Metrics (gnocchi) を使用します。メトリックデータの移行プランはない点に注意してください。

  • OpenStack Telemetry Alarms (aodh) では、コンポジットアラームの方が支持されるようになったため、コンビネーションアラームは非推奨となりました。次の点に注意してください。

    • Aodh は、デフォルトでは、コンビネーションアラームは公開しません。
    • 新規パラメーター EnableCombinationAlarms は、オーバークラウドでコンビネーションアラームを有効にします。これは、デフォルト値は false です。OpenStack Platform 10 で引き続きコンビネーションアラームを使用するには、true に設定してください。
    • OpenStack Platform 10 には、コンポジットアラームに移行するためのマイグレーションスクリプト (aodh-data-migration) が含まれています。このデータの移行手順は、本ガイドの「OpenStack Telemetry Alarming データベースの移行」に記載しています。このスクリプトを実行して、アラームをコンポジットに必ず変換してください。
    • コンビネーションアラームに対するサポートは、次のリリースから廃止されます。

3.3. オーバークラウドの確認

アップグレードを実行する前に、オーバークラウドが安定した状態であることをチェックします。director で以下のステップを実行して、オーバークラウド内の全サービスが稼働していることを確認してください。

  1. 高可用性サービスのステータスを確認します。 

    ssh heat-admin@[CONTROLLER_IP] "sudo pcs resource cleanup ; sleep 60 ; sudo pcs status"

    [CONTROLLER_IP] はコントローラーノードの IP アドレスに置き換えます。このコマンドは、オーバークラウドの Pacemaker クラスターを最新の状態に更新し、60 秒待ってからそのクラスターのステータスを報告します。

  2. オーバークラウドノードで、失敗した 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

  3. 各ノードで 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

3.4. アンダークラウドのアップグレード

3.4.1. director のアップグレード

Red Hat OpenStack Platform director をアップグレードするには、以下の手順に従ってください。

  1. director に stack ユーザーとしてログインします。

  2. OpenStack Platform のリポジトリーを更新します。 

    $ sudo subscription-manager repos --disable=rhel-7-server-openstack-9-rpms --disable=rhel-7-server-openstack-9-director-rpms
$ sudo subscription-manager repos --enable=rhel-7-server-openstack-10-rpms

    上記のコマンドは、yum が最新のリポジトリーを使用するように設定します。

  3. 主要な OpenStack Platform サービスを停止します。 

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

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

  4. yum を使用して director をアップグレードします。 

    $ sudo yum update python-tripleoclient

  5. 以下のコマンドでアンダークラウドをアップグレードします。 

    $ openstack undercloud upgrade

    このコマンドにより、director のパッケージがアップグレードされ、director の設定が最新の状態に更新されて、バージョンの変更後に指定されていない設定内容が追加されます。このコマンドによって、オーバークラウドのスタックデータや環境内の既存のノードのデータなど、保存されたデータは削除されません。

アンダークラウドで /var/log/yum.log ファイルをチェックして、kernel または openvswitch のパッケージのメジャー/マイナーバージョンが更新されているかどうかを確認します。更新されている場合には、アンダークラウドを再起動します。

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

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

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

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

再起動後に openstack-nova-compute が有効になるまでに約 10 分かかる場合があります。

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

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

カスタマイズされたコアの Heat テンプレートを使用する場合には、更新されたコアの Heat テンプレートと現在の設定の相違点を確認するようにしてください。Red Hat では、今後のリリースで Heat テンプレートコレクションへの更新を提供します。変更されたテンプレートコレクションを使用すると、カスタムのコピーと /usr/share/openstack-tripleo-heat-templates にあるオリジナルのコピーとの間に相違が生じる可能性があります。以下のコマンドを実行して、カスタムの Heat テンプレートと更新されるオリジナルのバージョンとの差分を確認します。 

# diff -Nar /usr/share/openstack-tripleo-heat-templates/ ~/templates/my-overcloud/

これらの更新をカスタムの Heat テンプレートコレクションに適用するか、/usr/share/openstack-tripleo-heat-templates/ でテンプレートの新しいコピーを作成して、カスタマイズを適用します。

3.4.2. director 上のオーバークラウドイメージのアップグレード

以下の手順では、ノードの検出とオーバークラウドのデプロイメントに向け最新のイメージが確保されるようにします。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-10.0.tar /usr/share/rhosp-director-images/ironic-python-agent-latest-10.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 は、最新のイメージを使用してアップグレードされました。

重要

オーバークラウドのイメージのバージョンがアンダークラウドのバージョンに対応していることを確認してください。

3.4.3. 以前のテンプレートバージョンの使用と比較

アップグレードプロセスにより、最新のオーバークラウドバージョンに対応したコア Heat テンプレートの新しいセットがインストールされます。Red Hat OpenStack Platform のリポジトリーには、openstack-tripleo-heat-templates-compat パッケージ内のコアテンプレートコレクションの以前のバージョンが維持されています。このパッケージは、以下のコマンドを実行してインストールします。 

$ sudo yum install openstack-tripleo-heat-templates-compat

これにより、Heat テンプレートコレクションの compat ディレクトリー (/usr/share/openstack-tripleo-heat-templates/compat) に以前のテンプレートがインストールされ、以前のバージョン (mitaka) から命名された compat へのリンクが作成されます。これらのテンプレートは、アップグレードされた director との後方互換性があるので、最新バージョンの director を使用して以前のバージョンのオーバークラウドをインストールすることができます。

以前のバージョンを最新のバージョンと比較すると、アップグレード中にオーバークラウドに加えられる変更内容を確認することができます。現在のテンプレートコレクションを以前のバージョンと比較する必要がある場合は、以下のプロセスを使用してください。

  1. コア Heat テンプレートの一時的なコピーを作成します。 

    $ cp -a /usr/share/openstack-tripleo-heat-templates /tmp/osp10

  2. 以前のバージョンをそれ独自のディレクトリーに移動します。 

    $ mv /tmp/osp10/compat /tmp/osp9

  3. 両ディレクトリーのコンテンツに対して diff を実行します。 

    $ diff -urN /tmp/osp9 /tmp/osp10

このコマンドにより、バージョン間におけるコアテンプレートの変更が表示されます。この内容を確認すると、オーバークラウドのアップグレード中にどのような動作が行われるかがわかります。

3.5. オーバークラウドのアップグレード前の設定

3.5.1. Red Hat サブスクリプションの詳細

Satellite の登録に環境ファイルを使用する場合は、その環境ファイルで以下のパラメーターを更新するようにしてください。

  • rhel_reg_repos: オーバークラウドを有効化するためのリポジトリー。新しい Red Hat OpenStack Platform 10 リポジトリーを含みます。有効化するリポジトリーについては、「リポジトリーの要件」を参照してください。
  • rhel_reg_activation_key: Red Hat OpenStack Platform 10 リポジトリー用の新規アクティベーションキー
  • rhel_reg_sat_repo: katello-agent など、Red Hat Satellite 6 の管理ツールが含まれるリポジトリーを定義する新たなパラメーター。Red Hat Satellite 6 に登録する場合はこのパラメーターを追加するようにしてください。

3.5.2. SSL の設定

SSL を使用するオーバークラウドをアップグレードする場合には、以下の点を認識しておいてください。

  • ネットワークの設定には、PublicVirtualFixedIPs パラメーターを以下の形式で指定する必要があります。 

      PublicVirtualFixedIPs: [{'ip_address':'192.168.200.180'}]

    この行を、ネットワーク環境ファイルの parameter_defaults のセクション下に追加してください。

  • SSL エンドポイントを記載した新規環境ファイル。このファイルは、オーバークラウドへのアクセスに IP アドレスまたは DNS を使用するかによって異なります。

    • IP アドレスを使用する場合には、/usr/share/openstack-tripleo-heat-templates/environments/tls-endpoints-public-ip.yaml を使用してください。
    • DNS を使用する場合には、/usr/share/openstack-tripleo-heat-templates/environments/tls-endpoints-public-dns.yaml を使用してください。
  • SSL/TLS の設定に関する詳しい情報は、 『Red Hat OpenStack Platform Advanced Overcloud Customization』ガイドの「Enabling SSL/TLS on the Overcloud」の章を参照してください。

3.5.3. Ceph Storage

カスタムの storage-environment.yaml ファイルを使用する場合には、resource_registry のセクションに以下の新規リソースが含まれていることを確認してください。 

resource_registry:
  OS::TripleO::Services::CephMon: /usr/share/openstack-tripleo-heat-templates/puppet/services/ceph-mon.yaml
  OS::TripleO::Services::CephOSD: /usr/share/openstack-tripleo-heat-templates/puppet/services/ceph-osd.yaml
  OS::TripleO::Services::CephClient: /usr/share/openstack-tripleo-heat-templates/puppet/services/ceph-client.yaml

これらのリソースにより、Ceph Storage コンポーザブルサービスが Red Hat OpenStack Platform 10 で確実に有効化されます。Red Hat OpenStack Platform 10 のデフォルトの storage-environment.yaml ファイルが更新され、これらのリソースが含まれるようになりました。

3.5.4. オーバークラウドのパラメーター

アップグレードを実行するにあたっては、オーバークラウドパラメーターについての以下の情報に注意してください。

  • Red Hat OpenStack Platform 10 のデフォルトのタイムゾーンは UTC です。必要な場合には、タイムゾーンを指定する環境ファイルを追加してください。
  • カスタムの ServiceNetMap を指定してオーバークラウドをアップグレードする場合には、新規サービスに最新の ServiceNetMap を追加するようにしてください。ServiceNetMapDefaults パラメーターで定義されるデフォルトのサービス一覧は、network/service_net_map.j2.yaml ファイルにあります。カスタムの ServiceNetMap の使用方法については、『Advanced Overcloud Customization』の「Isolating Networks」のセクションを参照してください。

  • 新たなコンポーザブルサービスアーキテクチャーにより、OpenStack Image サービス (Glance) 向けに NFS バックエンドを設定するためのパラメーターが変更されました。新規パラメーターは以下のとおりです。

    GlanceNfsEnabled
    イメージストレージ用の共有を管理するための Pacemaker を有効にするパラメーター。無効に設定されている場合には、オーバークラウドはコントローラーノードのファイルシステムにイメージを保管します。true に設定してください。
    GlanceNfsShare
    イメージストレージをマウントするための NFS 共有 (例: 192.168.122.1:/export/glance)
    GlanceNfsOptions
    イメージストレージ用の NFS マウントオプション

  • 新しいコンポーザブルサービスアーキテクチャーにより、一部の設定フックの構文が変更されました。設定前または設定後のフックを使用してカスタムのスクリプトを環境に提供する場合には、カスタム環境ファイルの構文をチェックします。『Advanced Overcloud Customization』 ガイドで以下のセクションを参照してください。

3.5.5. カスタムのコアテンプレート

重要

本セクションに記載の内容は、コア Heat テンプレートコレクションを使用している場合にのみ必要です。これはコピーに、/usr/share/openstack-tripleo-heat-templates/ にある元のコア Heat テンプレートコレクションの静的なスナップショットが使用されるためです。 オーバークラウドに未変更のコア Heat テンプレートコレクションを使用する場合には、本セクションのステップは省略してください。

変更されたテンプレートコレクションを更新するには、以下の作業を行う必要があります。

  1. 既存のカスタムテンプレートコレクションをバックアップします。 

    $ mv ~/templates/my-overcloud/ ~/templates/my-overcloud.bak

  2. /usr/share/openstack-tripleo-heat-templates にあるテンプレートコレクションの新しいバージョンを置き換えます。 

    $ sudo cp -rv /usr/share/openstack-tripleo-heat-templates ~/templates/my-overcloud/

  3. 古いバージョンと新しいバージョンのカスタムテンプレートコレクションの差異を確認します。これらの 2 つの間の変更を確認するには、以下の diff コマンドを使用します。 

    $ diff -Nar ~/templates/my-overcloud.bak/ ~/templates/my-overcloud/

これは、新規テンプレートコレクションに取り入れることが可能な旧テンプレートコレクションのカスタマイズを特定するのに役立ちます。新規カスタムテンプレートコレクションにカスタマイズの設定を取り入れます。

重要

Red Hat は、今後のリリースで Heat テンプレートコレクションの更新を提供します。変更されたテンプレートコレクションを使用すると、カスタムのコピーと /usr/share/openstack-tripleo-heat-templates にあるオリジナルのコピーとの間に相違が生じる可能性があります。オーバークラウドをカスタマイズするには、『Advanced Overcloud Customization』ガイドの「Configuration Hooks」のセクションを参照することを推奨します。Heat テンプレートコレクションのコピーを作成する場合には、git などのバージョン管理システムを使用して変更をトラッキングすべきです。

3.6. オーバークラウドのアップグレード

3.6.1. 概要とワークフロー

本項には、オーバークラウドのアップグレードに必要な手順を記載します。各セクションを順を追って進み、お使いの環境に関連するセクションのみを適用します。

このプロセスでは、ステージごとに分けた手法を使用してアップグレードを行うには、元の openstack overcloud deploy コマンドを複数回実行する必要があります。コマンドを実行する度に、既存の環境ファイルに、別のアップグレードの環境ファイルが追加されます。これらの新しいアップグレード環境ファイルには、以下のようなファイルがあります。

  • major-upgrade-ceilometer-wsgi-mitaka-newton.yaml: OpenStack Telemetry (‘Ceilometer’) を WSGI サービスに変換します。
  • major-upgrade-pacemaker-init.yaml: アップグレードの初期設定を行います。これには、オーバークラウドの各ノードにある Red Hat OpenStack Platform のリポジトリーの更新や、特定のノードへの特別なアップグレードスクリプトの提供などが含まれます。
  • major-upgrade-pacemaker.yaml: コントローラーノードをアップグレードします。
  • (オプション) major-upgrade-remove-sahara.yaml: オーバークラウドから OpenStack Clustering (sahara) を削除します。このステップは、OpenStack Platform 9 と 10 の間の違いを調整します。詳しい情報は、「コントローラーノードのアップグレード」 を参照してください。
  • major-upgrade-pacemaker-converge.yaml: オーバークラウドのアップグレードの最終処理。これは、実行されるアップグレードが director の最新の Heat テンプレートコレクションの内容と一致するように合わせます。
  • major-upgrade-aodh-migration.yaml: OpenStack Telemetry Alarming (aodh) サービスのデータベースを MongoDB から MariaDB に移行します。

これらのデプロイメントのコマンドの間に、さまざまなタイプのノードで upgrade-non-controller.sh スクリプトを実行します。このスクリプトにより、コントローラー以外のノードでパッケージがアップグレードされます。

ワークフロー

オーバークラウドのアップグレードプロセスでは、以下のワークフローを使用します。

  1. major-upgrade-ceilometer-wsgi-mitaka-newton.yaml 環境ファイルを指定してデプロイメントコマンドを実行します。
  2. major-upgrade-pacemaker-init.yaml 環境ファイルを指定してデプロイメントコマンドを実行します。
  3. 各 Object Storage ノードで upgrade-non-controller.sh を実行します。
  4. major-upgrade-pacemaker.yaml と、オプションの major-upgrade-remove-sahara.yaml の環境ファイルを指定してデプロイメントコマンドを実行します。
  5. 各 Ceph Storage ノードで upgrade-non-controller.sh を実行します。
  6. 各 Compute ノードで upgrade-non-controller.sh を実行します。
  7. major-upgrade-pacemaker-converge.yaml 環境ファイルを指定してデプロイメントコマンドを実行します。
  8. major-upgrade-aodh-migration.yaml 環境ファイルを指定してデプロイメントコマンドを実行します。

3.6.2. OpenStack Telemetry の WSGI サービスへのアップグレード

このステップでは、OpenStack Telemetry (ceilometer) サービスをスタンドアロンのサービスとしてではなく httpd 下で Web Server Gateway Interface (WSGI) アプレットとして実行するようにアップグレードします。このプロセスにより、スタンドアロンの openstack-ceilometer-api サービスは自動的に無効化され、WSGI アプレットを有効化するのに必要な設定がインストールされます。

アンダークラウドから major-upgrade-ceilometer-wsgi-mitaka-newton.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 /home/stack/templates/network_env.yaml \
  -e /usr/share/openstack-tripleo-heat-templates/environments/major-upgrade-ceilometer-wsgi-mitaka-newton.yaml \
  --ntp-server pool.ntp.org

新しい環境ファイルの設定でオーバークラウドが更新されるまで待ちます。

注記

コントローラーノードにログインして pcs status コマンドを実行し、コントローラークラスター内の全リソースがアクティブかどうかを確認します。いずれかのリソースが失敗した場合には、pcs resource cleanup を実行してエラーをクリーニングし、各リソースの状態を Started に設定します。エラーが引き続き発生する場合には、Red Hat にヘルプ / サポートをリクエストしてください。

3.6.3. アップグレードスクリプトのインストール

このステップでは、コントローラー以外の各ノードにスクリプトをインストールします。これらのスクリプトは、メジャーバージョンのパッケージアップグレードおよび設定を実行します。各スクリプトは、ノードタイプによって異なります。たとえば、コンピュートノードにインストールされるアップグレードのスクリプトは、Ceph Storage ノードにインストールされるスクリプトとは異なります。

この初期化のステップにより、全オーバークラウド上で有効なリポジトリーの更新も行われるので、手動で古いリポジトリーを無効にして新しいリポジトリーを有効にする必要はありません。

アンダークラウドから major-upgrade-pacemaker-init.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 /home/stack/templates/network_env.yaml \
  -e /usr/share/openstack-tripleo-heat-templates/environments/major-upgrade-pacemaker-init.yaml \
  --ntp-server pool.ntp.org

新しい環境ファイルの設定でオーバークラウドが更新されるまで待ちます。

注記

コントローラーノードにログインして pcs status コマンドを実行し、コントローラークラスター内の全リソースがアクティブかどうかを確認します。いずれかのリソースが失敗した場合には、pcs resource cleanup を実行してエラーをクリーニングし、各リソースの状態を Started に設定します。エラーが引き続き発生する場合には、Red Hat にヘルプ / サポートをリクエストしてください。

3.6.4. Object Storage ノードのアップグレード

director は upgrade-non-controller.sh コマンドを使用してアップグレードのスクリプトを実行します。このスクリプトは、major-upgrade-pacemaker-init.yaml 環境ファイルから、コントローラー以外の各ノードに渡されます。このステップでは、各 Object Storage ノードを以下のコマンドでアップグレードします。 

$ for NODE in `openstack server list -c Name -f value --name objectstorage` ; do upgrade-non-controller.sh --upgrade $NODE ; done

各 Object Storage ノードのアップグレードが完了するまで待ちます。

各オブジェクトストレージノードで /var/log/yum.log ファイルをチェックして、kernel または openvswitch のパッケージのメジャー/マイナーバージョンが更新されているかどうかを確認します。更新されている場合には、各 Object Storage ノードを再起動します。

  1. 再起動する Object Storage ノードを選択します。そのノードにログインして再起動します。 

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

  3. ノードにログインして、ステータスを確認します。 

    $ sudo systemctl list-units "openstack-swift*"
  4. ノードからログアウトして、次の Object Storage ノードでこのプロセスを繰り返します。
注記

コントローラーノードにログインして pcs status コマンドを実行し、コントローラークラスター内の全リソースがアクティブかどうかを確認します。いずれかのリソースが失敗した場合には、pcs resource cleanup を実行してエラーをクリーニングし、各リソースの状態を Started に設定します。エラーが引き続き発生する場合には、Red Hat にヘルプ / サポートをリクエストしてください。

3.6.5. コントローラーノードのアップグレード

コントローラーノードをアップグレードする際には、高可用性ツールを実行するコントローラーノードへの完全アップグレードを提供する別の環境ファイル (major-upgrade-pacemaker.yaml) を指定する必要があります。

アンダークラウドから major-upgrade-pacemaker.yaml の環境ファイルを指定して openstack overcloud deploy を実行します。ネットワークの分離やストレージなど環境に関連するすべてのオプションとカスタムの環境ファイルも必ず指定してください。

コントローラーノードでは、OpenStack Data Processing (sahara) を有効な状態のままに保持するかどうかによって、追加のファイルが必要な場合があります。OpenStack Platform 9 では、OpenStack Data Processing がデフォルトのオーバークラウド向けに自動的にインストールされていました。OpenStack Platform 10 では、ユーザーは環境ファイルを明示的に指定して、OpenStack Data Processing を有効化する必要があります。これには、以下のような意味があります。

  • OpenStack Data Processing が必要なくなった場合には、デプロイメントに major-upgrade-remove-sahara.yaml ファイルを指定します。
  • OpenStack Data Processing を保持する場合には、デプロイメントで major-upgrade-remove-sahara.yaml ファイルを追加しないでください。オーバークラウドのアップグレードが完了したら、/usr/share/openstack-tripleo-heat-templates/environments/services/sahara.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-pacemaker.yaml
  -e /usr/share/openstack-tripleo-heat-templates/environments/major-upgrade-remove-sahara.yaml \
  --ntp-server pool.ntp.org

新しい環境ファイルの設定でオーバークラウドが更新されるまで待ちます。

重要

以下の点に注意してください。

  • このステップは、コントローラーのアップグレードの際に Neutron サーバーおよび L3 エージェントを無効化します。これは、Floating IP アドレスがこのステップでは利用できないということを意味します。
  • このステップにより、コントローラークラスターの Pacemaker の設定が変更されるので、特定の高可用性機能はアップグレードによって一時的に無効になります。

各コントローラーで /var/log/yum.log ファイルをチェックして、kernel または openvswitch のパッケージのメジャー/マイナーバージョンが更新されているかどうかを確認します。更新されている場合には、各コントローラーを再起動します。

  1. 再起動するノードを選択します。そのノードにログインして再起動します。 

    $ sudo reboot

    クラスター内の残りのコントローラーノードは、再起動中も高可用性サービスが保持されます。

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

  3. ノードにログインして、クラスターのステータスを確認します。 

    $ sudo pcs status

    このノードは、クラスターに再度参加します。

    注記

    再起動後に失敗するサービスがあった場合には、sudo pcs resource cleanup を実行し、エラーを消去して各リソースの状態を Started に設定します。エラーが引き続き発生する場合には、Red Hat にアドバイス/サポートをリクエストしてください。

  4. コントローラーノード上の全 systemd サービスがアクティブであることを確認します。 

    $ sudo systemctl list-units "openstack*" "neutron*" "openvswitch*"
  5. ノードからログアウトして、次に再起動するコントローラーノードを選択し、すべてのコントローラーノードが再起動されるまでこの手順を繰り返します。
重要

OpenStack Platform 10 のアップグレード手順を実行すると、新しいコンポーザぶるアーキテクチャーに移行されます。これは、以前のバージョンでは Pacemaker によって管理されていたサービスの多くが systemd の管理機能を使用することになります。このため、Pacemaker によって管理されるリソースの数が削減されます。

3.6.6. Ceph Storage ノードのアップグレード

director は upgrade-non-controller.sh コマンドを使用してアップグレードのスクリプトを実行します。このスクリプトは、major-upgrade-pacemaker-init.yaml 環境ファイルから、コントローラー以外の各ノードに渡されます。このステップでは、各 Ceph Storage ノードを以下のコマンドでアップグレードします。

各 Ceph Storage ノードをアップグレードします。 

$ for NODE in `openstack server list -c Name -f value --name ceph` ; do upgrade-non-controller.sh --upgrade $NODE ; done

各 Ceph Storage ノードで /var/log/yum.log ファイルをチェックして、kernel または openvswitch のパッケージのメジャー/マイナーバージョンが更新されているかどうかを確認します。更新されている場合には、各 Ceph Storage ノードを再起動します。

  1. Ceph MON またはコントローラーノードにログインして、Ceph Storage クラスターのリバランスを一時的に無効にします。 

    $ sudo ceph osd set noout
$ sudo ceph osd set norebalance
  2. 再起動する最初の Ceph Storage ノードを選択して、ログインします。

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

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

  5. ノードにログインして、クラスターのステータスを確認します。 

    $ sudo ceph -s

    pgmap により、すべての pgs が正常な状態 (active+clean) として報告されることを確認します。

  6. ノードからログアウトして、次のノードを再起動し、ステータスを確認します。全 Ceph Storage ノードすべてが再起動されるまで、このプロセスを繰り返します。

  7. 完了したら、Ceph MON またはコントローラーノードにログインして、クラスターのリバランスを再度有効にします。 

    $ sudo ceph osd unset noout
$ sudo ceph osd unset norebalance

  8. 最終のステータスチェックを実行して、クラスターが HEALTH_OK を報告していることを確認します。 

    $ sudo ceph status
注記

コントローラーノードにログインして pcs status コマンドを実行し、コントローラークラスター内の全リソースがアクティブかどうかを確認します。いずれかのリソースが失敗した場合には、pcs resource cleanup を実行してエラーをクリーニングし、各リソースの状態を Started に設定します。エラーが引き続き発生する場合には、Red Hat にヘルプ / サポートをリクエストしてください。

3.6.7. コンピュートノードのアップグレード

コンピュートノードを個別にアップグレードして、OpenStack Platform 環境のインスタンスのダウンタイムがゼロになるようにします。この操作は、以下のワークフローに従って実行します。

  1. アップグレードするコンピュートノードを選択します。
  2. インスタンスを別のコンピュートノードに移行します。
  3. 空のコンピュートノードをアップグレードします。

全コンピュートノードとその UUID を一覧表示します。 

$ openstack server list | grep "compute"

アップグレードするコンピュートノードを選択してから、まず最初に以下の手順に従ってそのノードのインスタンスを移行します。

  1. アンダークラウドから、再起動するコンピュートノードを選択し、そのノードを無効にします。 

    $ source ~/overcloudrc
$ openstack compute service list
$ openstack compute service set [hostname] nova-compute --disable

  2. コンピュートノード上の全インスタンスを一覧表示します。 

    $ openstack server list --host [hostname] --all-projects

  3. 無効にしたホストから各インスタンスを移行します。以下のコマンドの 1 つを使用します。

    1. 選択した特定のホストにインスタンスを移行します。 

      $ openstack server migrate [instance-id] --live [target-host]--wait

    2. nova-scheduler により対象のホストが自動的に選択されるようにします。 

      $ nova live-migration [instance-id]
      注記

      nova コマンドで非推奨の警告が表示される可能性がありますが、安全に無視することができます。

  4. 移行が完了するまで待ちます。

  5. インスタンスがコンピュートノードから移行されたことを確認します。 

    $ openstack server list --host [hostname] --all-projects
  6. コンピュートノードからすべてのインスタンスが移行されるまで、このステップを繰り返します。
重要

インスタンスの設定と移行の詳しい手順は、『director のインストールと使用方法』の「オーバークラウドのコンピュートノードからの仮想マシンの移行」を参照してください。

director は upgrade-non-controller.sh コマンドを使用してアップグレードのスクリプトを実行します。このスクリプトは、major-upgrade-pacemaker-init.yaml 環境ファイルから、コントローラー以外の各ノードに渡されます。以下のコマンドを実行して、各コンピュートノードをアップグレードします。 

$ source ~/stackrc
$ upgrade-non-controller.sh --upgrade NODE_UUID

NODE_UUID は、選択したコンピュートノードの UUID に置き換えます。コンピュートーノードのアップグレードが完了するまで待ちます。

アップグレードしたコンピュートノード上の　/var/log/yum.log ファイルをチェックして、kernel または openvswitch のパッケージがアップグレードされているかどうかを確認します。アップグレードされている場合には、コンピュートノードを再起動します。

  1. コンピュートノードのログインしてリブートします。 

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

  3. コンピュートノードを再度有効化します。 

    $ source ~/overcloudrc
$ openstack compute service set [hostname] nova-compute --enable
  4. リブートする次のノードを選択します。

全ノードがリブートされるまで、各ノードで個別にマイグレーションとリブートのプロセスを繰り返します。

注記

コントローラーノードにログインして pcs status コマンドを実行し、コントローラークラスター内の全リソースがアクティブかどうかを確認します。いずれかのリソースが失敗した場合には、pcs resource cleanup を実行してエラーをクリーニングし、各リソースの状態を Started に設定します。エラーが引き続き発生する場合には、Red Hat にヘルプ / サポートをリクエストしてください。

3.6.8. アップグレードの最終処理

director には、アップグレードの最終処理を最後まで実行して、オーバークラウドスタックが現在の Heat テンプレートコレクションと確実に同期されるようにする必要があります。そのためには、openstack overcloud deploy コマンドで環境ファイル (major-upgrade-pacemaker-converge.yaml) を指定する必要があります。

重要

Red Hat OpenStack Platform 9 環境が、以前のバージョン(Red Hat Ceph Storage 1.3) の外部の Ceph Storage クラスターと統合されている場合には、後方互換性を有効にする必要があります。そのためには、環境ファイル (例: /home/stack/templates/ceph-backwards-compatibility.yaml) を作成して、以下の内容を記載します。 

parameter_defaults:
  ExtraConfig:
    ceph::conf::args:
      client/rbd_default_features:
        value: "1"

このファイルの作成が完了したら、次のステップで openstack overcloud deploy を実行する際に指定してください。

アンダークラウドから openstack overcloud deploy を実行して、major-upgrade-pacemaker-converge.yaml 環境ファイルを指定します。Ceph の後方互換性 (該当する場合)、ネットワークの分離、ストレージなど、お使いの環境に関連するすべてのオプションとカスタムの環境ファイルも必ず指定してください。

以下は、openstack overcloud deploy コマンドに追加で major-upgrade-pacemaker-converge.yaml ファイルを指定した例です。 

$ 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-pacemaker-converge.yaml \
  --ntp-server pool.ntp.org

新しい環境ファイルの設定でオーバークラウドが更新されるまで待ちます。

注記

コントローラーノードにログインして pcs status コマンドを実行し、コントローラークラスター内の全リソースがアクティブかどうかを確認します。いずれかのリソースが失敗した場合には、pcs resource cleanup を実行してエラーをクリーニングし、各リソースの状態を Started に設定します。エラーが引き続き発生する場合には、Red Hat にヘルプ / サポートをリクエストしてください。

3.6.9. OpenStack Telemetry Alarming データベースの移行

このステップにより、OpenStack Telemetry Alarming (aodh) サービスのデータベースが MongoDB から MariaDB に移行されます。このプロセスは、自動的にマイグレーションを実行します。

アンダークラウドから major-upgrade-aodh-migration.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 /home/stack/templates/network_env.yaml \
  -e /usr/share/openstack-tripleo-heat-templates/environments/major-upgrade-aodh-migration.yaml \
  --ntp-server pool.ntp.org

新しい環境ファイルの設定でオーバークラウドが更新されるまで待ちます。

注記

コントローラーノードにログインして pcs status コマンドを実行し、コントローラークラスター内の全リソースがアクティブかどうかを確認します。いずれかのリソースが失敗した場合には、pcs resource cleanup を実行してエラーをクリーニングし、各リソースの状態を Started に設定します。エラーが引き続き発生する場合には、Red Hat にヘルプ / サポートをリクエストしてください。

これで、オーバークラウドのアップグレード手順が完了しました。

3.7. オーバークラウドのアップグレード後の注意事項

オーバークラウドを Red Hat OpenStack Platform 10 にアップグレードした後には以下の点に注意してください。

  • 上記の操作によって生成された設定ファイルを確認します。アップグレードされたパッケージで、Red Hat OpenStack Platform 10 バージョンのサービスに適した .rpmnew ファイルがインストールされている可能性があります。
  • 「コントローラーノードのアップグレード」で準備したオプションの major-upgrade-remove-sahara.yaml ファイルを追加しなかった場合には、/usr/share/openstack-tripleo-heat-templates/environments/services/sahara.yaml を追加して、OpenStack Clustering (sahara) がオーバークラウド内で引き続き有効な状態となるようにしてください。

  • コンピュートノードが neutron-openvswitch-agent の問題をレポートする可能性があります。これが発生した場合には、各コンピュートノードにログインして、このサービスを再起動します。以下のようなコマンドを実行します。 

    $ sudo systemctl restart neutron-openvswitch-agent
  • アップグレードプロセスを実行しても、オーバークラウド内のノードは自動的には再起動しません。必要な場合には、アップグレードコマンドが完了した後に手動で再起動を実行してください。クラスターベースのノード (Ceph Storage ノードやコントローラーノード) を個別に再起動して、ノードがクラスターに再度参加するまで待ちます。Ceph Storage ノードの場合は、ceph health で確認して、クラスターのステータスが HEALTH OK であることを確認します。コントローラーノードの場合は、pcs resource で確認して、各ノードですべてのリソースが実行されていることを確認してください。

  • 状況によっては、コントローラーノードの再起動後に IPv6 環境で corosync サービスの起動に失敗する可能性があります。これは、コントローラーノードが静的な IPv6 アドレスを設定する前に Corosync が起動してしまうことが原因です。このような場合は、コントローラーノードで Corosync を手動で再起動してください。 

    $ sudo systemctl restart corosync

  • コントローラーノードにフェンシングを設定している場合には、アップグレードプロセスによってその設定が無効になる場合があります。アップグレードプロセスの完了時には、コントローラーノードの 1 つで以下のコマンドを実行してフェンシングを再度有効にします。 

    $ sudo pcs property set stonith-enabled=true

  • 次回に (openstack overcloud deploy コマンドを実行して) オーバークラウドのスタックを更新またはスケーリングする際には、オーバークラウドでのパッケージの更新をトリガーする ID をリセットする必要があります。環境ファイルに空の UpdateIdentifier パラメーターを追加して、openstack overcloud deploy コマンドの実行時にそのファイルを指定します。環境ファイルの内容の以下に例を示します。 

    parameter_defaults:
  UpdateIdentifier: