第2章 インプレースアップグレードの計画および準備

OpenStack Platform 環境のインプレースアップグレードを実施する前に、アップグレードのプランを作成し、正常なアップグレードを妨げる可能性のある障害に対処してください。

2.1. Red Hat OpenStack Platform 16.1 の理解

アップグレードを実施する前に Red Hat OpenStack Platform 16.1 をよく理解しておくことで、結果として生じる環境や、アップグレードに影響を与える可能性のあるバージョン間の変更点を理解することができます。Red Hat OpenStack Platform 16.1 の理解を深めるには、以下の推奨事項に従ってください。

  • アップグレードパスにわたるすべてのバージョンのリリースノートを確認し、計画が必要になる可能性のある要素を識別します。

    • 新しい機能が含まれるコンポーネント
    • 既知の問題

    以下のリンクから、各バージョンのリリースノートを確認してください。

  • バージョン 16.1 の『director のインストールと使用方法』を参照し、新たな要件および本ガイドのプロセスについて十分に理解してください。
  • 概念実証用の Red Hat OpenStack Platform 16.1 アンダークラウドおよびオーバークラウドをインストールします。対象のバージョンの OpenStack Platform を実際に操作して経験を積み、対象のバージョンと現在のバージョンの違いを調査します。

2.2. Red Hat OpenStack Platform 16.1 における変更点の概要

Red Hat OpenStack Platform 16.1 へのアップグレード時に、以下に概要を示す変更が行われます。

  • OpenStack Platform director 16.1 では、config-download と呼ばれる Ansible による手法を使用してオーバークラウドを設定します。これは、標準の heat ベースの設定手法に代わるものです。director は引き続き heat を使用してプロビジョニング操作のオーケストレーションを行います。
  • director のインストールには、オーバークラウドのデプロイメントと同じ手法が使用されます。したがって、アンダークラウドでの各サービスのインストールおよび設定にも、ブループリントとして openstack-tripleo-heat-templates が使用されます。
  • アンダークラウドでは、OpenStack サービスはコンテナー内で実行されます。
  • アンダークラウドは、新たな方法でコンテナーイメージをプルして保管します。オーバークラウドのデプロイ前にコンテナーイメージをプルする代わりに、アンダークラウドはデプロイメントプロセス中に関連するすべてのコンテナーイメージをプルします。
  • オーバークラウドのデプロイメントプロセスには、ノードを登録するための Advanced Subscription Management 手法が含まれます。この手法には、OpenStack Platform ノードを登録するための Ansible ロールが組み込まれています。さらに、新しい手法では、必要に応じて異なるノードロールに異なるサブスクリプションを適用します。
  • オーバークラウドは、デフォルトの ML2 メカニズムドライバーとして Open Virtual Network (OVN) を使用するようになりました。Open vSwitch (OVS) サービスを OVN に移行することができます。この移行は、アップグレードが正常に完了した後に実施します。
  • アンダークラウドおよびオーバークラウドは、共に Red Hat Enterprise Linux 8 上で動作します。
  • openstack-tripleo-heat-templates には、deployment ディレクトリーに統一されたコンポーザブルサービステンプレートコレクションが含まれています。このディレクトリーに含まれるテンプレートのコンテンツは、コンテナー化されたサービスと Puppet ベースのコンポーザブルサービスの両テンプレートからのコンテンツをマージしたものです。
  • OpenStack Data Processing サービス (sahara) はサポートされなくなりました。

    重要

    お使いの Red Hat OpenStack Platform 13 環境で sahara を有効にしている場合には、このアップグレードを続行せず、Red Hat Global Support Services にお問い合わせください。

  • Service Telemetry Framework (STF) を優先し、OpenStack Telemetry のコンポーネントは非推奨になりました。

2.3. Red Hat Enterprise Linux 8 の変更点

アンダークラウドおよびオーバークラウドは、共に Red Hat Enterprise Linux 8 上で動作します。これには、アンダークラウドおよびオーバークラウドに関連する新しいツールおよび機能が含まれます。

  • アンダークラウドおよびオーバークラウドは Red Hat Container Toolkit を使用します。コンテナーライフサイクルをビルドおよび制御する docker に代わって、Red Hat Enterprise Linux 8 には、新しいコンテナーイメージをビルドするための buildah およびコンテナー管理用の podman が含まれます。
  • Red Hat Enterprise Linux 8 には docker-distribution パッケージが含まれていません。アンダークラウドには、オーバークラウドノードにコンテナーイメージを提供するためのプライベート HTTP レジストリーが追加されました。
  • Red Hat Enterprise Linux 7 から 8 へのアップグレードプロセスには、leapp ツールが使用されます。
  • Red Hat Enterprise Linux 8 は、ntp サービスを使用しません。その代わりに、Red Hat Enterprise Linux 8 では chronyd が使用されます。
  • Red Hat Enterprise Linux 8 には、新しいバージョンの高可用性ツールが含まれています。

Red Hat OpenStack Platform 16.1 は、ベースオペレーティングシステムとして Red Hat Enterprise Linux 8.2 を使用します。アップグレードプロセスの一環として、ノードのベースオペレーティングシステムを Red Hat Enterprise Linux 8.2 にアップグレードします。

Red Hat Enterprise Linux 7 と 8 の主な相違点は、『RHEL 8 の導入における検討事項』を参照してください。Red Hat Enterprise Linux 8 に関する一般的な情報は、「Product Documentation for Red Hat Enterprise Linux 8」を参照してください。

2.4. Red Hat OpenStack Platform での Leapp アップグレードの使用

ロングライフバージョンの Red Hat OpenStack Platform のアップグレードには、Red Hat Enterprise Linux 7 から Red Hat Enterprise Linux 8 へのアップグレードも必要です。Red Hat Enterprise Linux 7 には leapp と呼ばれるツールが含まれており、このツールにより Red Hat Enterprise Linux 8 へのアップグレードを実施します。オペレーティングシステムのアップグレードを実施する際には、アンダークラウドとオーバークラウドではそれぞれ別個のプロセスが使用されます。

アンダークラウドのプロセス

openstack undercloud upgrade コマンドを実行する前に、手動で leapp によるアップグレードを行います。アンダークラウドのアップグレードには、leapp によるアップグレードを実施する手順が含まれます。

オーバークラウドのプロセス

オーバークラウドのアップグレードフレームワークでは、leapp によるアップグレードが自動的に実施されます。

制限

アップグレードに影響を及ぼす可能性のある制限の詳細は、『RHEL 7 から RHEL 8 へのアップグレード』の以下のセクションを参照してください。

特に、ディスク全体またはパーティションで暗号化が使用される (LUKS 暗号化、ファイルシステムの暗号化など) ノードで Leapp によるアップグレードを行うことはできません。この制限は、dmcrypt: true パラメーターで設定した Ceph OSD ノードに影響します。

既知の制限がお使いの環境に影響を及ぼす場合は、Red Hat Technical Support Team にアドバイスを求めてください。

2.5. サポート対象のアップグレードシナリオ

アップグレードを進める前に、ご自分のオーバークラウドがサポート対象であることを確認してください。

注記

以下の一覧に記載されていない特定のシナリオがサポート対象かどうか不明な場合は、Red Hat Technical Support Team にアドバイスを求めてください。

サポート対象のシナリオ

以下のインプレースアップグレードシナリオは、テスト済みでサポートの対象です。

  • デフォルトのロール種別を使用する標準環境: Controller、Compute、および Ceph Storage OSD
  • 分割 Controller コンポーザブルロール
  • Ceph Storage コンポーザブルロール
  • ハイパーコンバージドインフラストラクチャー: 同一ノード上の Compute サービスおよび Ceph Storage OSD サービス
  • ネットワーク機能仮想化 (NFV) 技術を使用する環境: Single-root Input/Output Virtualization (SR-IOV) および Data Plane Development Kit (DPDK)

テクノロジープレビューのシナリオ

アップグレードフレームワークを以下の機能と併用した場合は、テクノロジープレビューとみなされます。したがって、Red Hat では全面的にはサポートしていません。以下のシナリオは概念実証の環境でのみテストし、実稼働環境へのアップグレードは行わないでください。テクノロジープレビュー機能についての詳しい情報は、「対象範囲の詳細」を参照してください。

  • エッジおよび分散コンピュートノード (DCN) のシナリオ

テストされていないサポート対象外のシナリオ

以下に示すインプレースアップグレードのシナリオは、テストされていないか、サポート対象外かのいずれかです。ご自分のオーバークラウド設定が以下のシナリオ一覧のいずれかと一致する場合は、アップグレードを延期して Red Hat Technical Support Team にアドバイスを求めてください。

  • インスタンス HA が有効な環境

2.6. 外部の Ceph デプロイメントと組み合わせたアップグレードに関する考慮事項

別途 Red Hat Ceph Storage システムをデプロイしていて、director を使用して OpenStack をデプロイおよび設定している場合は、Red Hat OpenStack Platform のアップグレードフレームワークを使用して、外部の Ceph デプロイメントと共にインプレースアップグレードを行うことができます。このシナリオは、director を使用してデプロイされた Ceph クラスターのアップグレードとは異なります。

外部の Ceph デプロイメントと組み合わせたインプレースアップグレードのプランニングおよび準備を行う際に考慮すべき違いは以下のとおりです。

  1. Red Hat OpenStack Platform デプロイメントをバージョン 13 からバージョン 16.1 にアップグレードする前に、Red Hat Ceph Storage クラスターをバージョン 3 からバージョン 4 にアップグレードする必要があります。詳細は、Red Hat Ceph Storage 4『インストールガイド』「Red Hat Ceph Storage クラスターのアップグレード」を参照してください。
  2. Red Hat Ceph Storage クラスターをバージョン 3 からバージョン 4 にアップグレードした後も、Red Hat OpenStack Platform 13 では引き続き RHCSv3 クライアントコンポーネントが実行されている可能性がありますが、これらは RHCSv4 クラスターに対して互換性があります。
  3. 『13 から 16.1 へのアップグレードフレームワーク』に記載のアップグレードパスに従うことができます。該当する場合は、この特定のシナリオをサポートする条件ステップを実行する必要があります。条件ステップは、「外部の Ceph デプロイメントと共にアップグレードする場合は」で始まる箇所です。
  4. 外部の Ceph デプロイメントと共にアップグレードする場合は、オーバークラウドのアップグレードプロセスの一部として RHCSv4 ceph-ansible をインストールします。director を使用してデプロイされた Ceph クラスターをアップグレードする場合は、オーバークラウドのアップグレードプロセスの完了後に RHCSv4 ceph-ansible をインストールします。

2.7. アップグレードを妨げる可能性のある既知の問題

アップグレードの正常な完了に影響を及ぼす可能性のある、以下の既知の問題を確認してください。

BZ#1852360: swift_rsync and swift_rsync_healthcheck moved in failed state after UC upgrade
Red Hat OpenStack Platform 16.1 アンダークラウド上のコンテナー化された tripleo_swift_rsync サービスが failed の状態を報告します。これは、xinetd を介して OpenStack Object Storage (swift) rsync デーモンを実行する Red Hat OpenStack Platform 16.1 バージョンとの競合によるものです。本ガイドでは、アンダークラウドのアップグレード前に削除する必要のあるパッケージの一覧に xinetd が含まれています。Red Hat は、16.1 の次回マイナーリリースの更新でこの問題を解決することを目指しています。
BZ#1866479: container-tools module stream not enabled correctly on update from 16.0.2 to 16.1
Red Hat Enterprise Linux 8 AppStream リポジトリーは、デフォルトの dnf モジュールとして container-tools:rhel8 を使用します。Red Hat OpenStack Platform 16.1 がサポートされる正しいバージョンの Podman を使用するには、オーバークラウドおよびアンダークラウドで container-tools:2.0 モジュールへの変更が必要です。アンダークラウドについてはこのモジュールを手動で変更しますが、オーバークラウド用には director がアップグレードプロセス中にこのモジュールを自動的に変更する必要があります。本ガイドには、UpgradeInitCommand パラメーターを使用してオーバークラウドでこのモジュール変更を行う回避策が含まれています。
BZ#1871834: ovn controllers cannot connect ovn dbs during 13-16.1 FFU upgrade

Open Virtual Network (OVN) の仮想 IP アドレス変更により、OVN コントローラーはアップグレード中に OVN データベースに接続できなくなります。この問題を回避するには、以下の手順を実行します。

  1. コントローラーノードをアップグレードしたら、新たな OVN 仮想 IP アドレスを取得します。

    [root@controller-0 ~]# ovs-vsctl get open . external_ids:ovn-remote | sed -e 's/\"//g'

    このコマンドにより、以下の形式で出力が生成されます。

    tcp:<NewOvnVIP>:6642
  2. コンピュートのアップグレードプロセスを開始する前に、それぞれのコンピュートノードにログインして OVN 仮想 IP アドレスを設定します。

    [root@compute-0 ~]# sudo docker exec -uroot ovn_controller ovs-vsctl set Open_Vswitch . external_ids:ovn-remote="tcp:<NewOvnVIP>:6642"

Red Hat は、16.1 の次回マイナーリリースの更新でこの問題を解決することを目指しています。

BZ#1885212: ovn-controllers can't connect to SB DB in hybrid state

+

OVN を使用する OpenStack Platform 13 環境では、アップグレード中に OVN Southbound データベース接続に問題が生じます。コンピュートノードで実行されている ovn-controller は OVN 2.11 を使用しますが、コントローラーノード上の Southbound データベースは OVN 2.13 を使用します。これにより、アップグレード中に負荷の移行などコンピュートベースの操作を実施する際に問題が発生します。Red Hat は、16.1 の次回マイナーリリースの更新でこの問題を解決することを目指しています。

BZ#1882400: During FFU new vms with SRIOV ports cannot be created

+ --- ポートバインディングの変更により、コンピュートノードがハイブリッドの状態である間 SR-IOV ポートが設定された新しい仮想マシンを作成することはできません。アップグレードを開始する前、またはアップグレードが正常に完了した後に、SR-IOV ポートが設定された仮想マシンを作成します。詳しくは、「During Framework Upgrade from OpenStack 13 to 16.1 new instances with SR-IOV ports cannot be created」を参照してください。 ---

Red Hat Ceph Storage の問題

BZ#1855813: Ceph tools repo should be switched from RHCS3 to RHCS4 only after converge, before running external-upgrade
アンダークラウド上の ceph-ansible Playbook コレクションにより、オーバークラウド上に Red Hat Ceph Storage コンテナーがデプロイされます。環境をアップグレードするには、アップグレードプロセス中 Ceph Storage 3 コンテナーを維持するために、Red Hat Ceph Storage 3 バージョンの ceph-ansible が必要です。本ガイドには、Ceph Storage 4 へのアップグレード準備が整うまで、アップグレードプロセス中 ceph-ansible バージョン 3 を維持する手順が含まれています。13 から 16.1 へのアップグレードを実施する前に、Red Hat OpenStack Platform 13 環境のマイナーバージョン更新を実施し、ceph-ansible のバージョンが 3.2.46 以降になるようにしてください。
BZ#1870617: noout ceph flag not unset during the FFU workflow
本ガイドには、Ceph Storage OSD クラスターのアップグレード前に noout および norebalance フラグを設定し、Ceph Storage OSD クラスターのアップグレードが完了したら設定を解除するためのコマンドが含まれています。Red Hat は、16.1 の次回マイナーリリースの更新でこの手順を自動化することを目指しています。

Red Hat Enterprise Linux の問題

BZ#1861977: RHSA-2020:3216 grub2 security update renders system unbootable
RHSA-2020:3216 セキュリティーアップデートを適用すると、grub メニューが読み込まれなくなります。この問題は、shim-x64-15-14.el8_2 パッケージの使用時に発生します。shim-x64-15-15.el8_2 およびそれ以降のバージョンのパッケージでは、この問題が修正されています。ノードのリブート時に grub メニューが表示されない場合は、「System hangs after POST and the grub menu never loads after applying the RHSA-2020:3216 or RHSA-2020:3217」を参照してください。

2.8. バックアップおよびリストア

Red Hat OpenStack Platform 13 環境をアップグレードする前に、アンダークラウドおよびオーバークラウドのコントロールプレーンをバックアップします。Relax-and-recover (ReaR) ユーティリティーを使用したノードのバックアップに関する詳細は、『アンダークラウドとコントロールプレーンのバックアップおよびリストア』を参照してください。

2.9. マイナーバージョンの更新

Red Hat OpenStack Platform 環境をアップグレードする前に、環境を現在のリリースの最新マイナーバージョンに更新します。たとえば、Red Hat OpenStack Platform 16.1 へのアップグレードを実施する前に、お使いの Red Hat OpenStack Platform 13 環境を最新の 13 に更新します。

Red Hat OpenStack Platform 13 のマイナーバージョンの更新を実施する手順は、『Red Hat OpenStack Platform の最新状態の維持』を参照してください。

2.10. プロキシー設定

Red Hat OpenStack Platform 13 環境でプロキシーを使用している場合、/etc/environment ファイルのプロキシー設定は、オペレーティングシステムのアップグレードおよび Red Hat OpenStack Platform 16.1 へのアップグレード後も維持されます。

2.11. アップグレード前の Red Hat OpenStack Platform 13 の検証

Red Hat OpenStack Platform 16.1 にアップグレードする前に、tripleo-validations Playbook を使用してアンダークラウドおよびオーバークラウドを検証します。Red Hat OpenStack Platform 13 において、これらの Playbook を OpenStack Workflow サービス (mistral) を使用して実行します。

手順

  1. アンダークラウドに stack ユーザーとしてログインします。
  2. source コマンドで stackrc ファイルを読み込みます。

    $ source ~/stackrc
  3. 以下の内容で、pre-upgrade-validations.sh という名前の bash スクリプトを作成します。

    #!/bin/bash
    for VALIDATION in $(openstack action execution run tripleo.validations.list_validations '{"groups": ["pre-upgrade"]}' | jq ".result[] | .id")
    do
      echo "=== Running validation: $VALIDATION ==="
      STACK_NAME=$(openstack stack list -f value -c 'Stack Name')
      ID=$(openstack workflow execution create -f value -c ID tripleo.validations.v1.run_validation "{\"validation_name\": $VALIDATION, \"plan\": \"$STACK_NAME\"}")
      while [ $(openstack workflow execution show $ID -f value -c State) == "RUNNING" ]
      do
        sleep 1
      done
      echo ""
      openstack workflow execution output show $ID | jq -r ".stdout"
      echo ""
    done
  4. スクリプトを実行する権限を追加します。

    $ chmod +x pre-upgrade-validations.sh
  5. スクリプトを実行します。

    $ ./pre-upgrade-validations.sh

    スクリプトの出力を確認し、成功した検証と失敗した検証を確認します。

    === Running validation: "check-ftype" ===
    
    Success! The validation passed for all hosts:
    * undercloud