Menu Close

13 から 16.2 へのアップグレードフレームワーク

Red Hat OpenStack Platform 16.2

Red Hat OpenStack Platform 13 から 16.2 へのインプレースアップグレード

概要

本ガイドでは、ロングライフバージョン間のインプレースアップグレードのフレームワークについて説明します。このフレームワークには、OpenStack Platform 環境をあるロングライフバージョンから次のロングライフバージョンにアップグレードするためのツールが含まれます。今回、本書では Red Hat OpenStack Platform 13 (Queens) から 16.2 (Train) へのアップグレードに重点を置いています。

はじめに

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。この取り組みは膨大な作業を要するため、今後の複数のリリースで段階的に用語の置き換えを実施して参ります。詳細は、弊社の CTO、Chris Wright のメッセージ を参照してください。

Red Hat ドキュメントへのフィードバックの提供

弊社ドキュメントに対するご意見をお聞かせください。ドキュメントの改善点があればお知らせください。

ドキュメントへのダイレクトフィードバック (DDF) 機能の使用 (英語版のみ)

特定の文章、段落、またはコードブロックに対して直接コメントを送付するには、DDF の Add Feedback 機能を使用してください。なお、この機能は英語版のドキュメントでのみご利用いただけます。

  1. Multi-page HTML 形式でドキュメントを表示します。
  2. ドキュメントの右上隅に Feedback ボタンが表示されていることを確認してください。
  3. コメントするテキスト部分をハイライト表示します。
  4. Add Feedback をクリックします。
  5. Add Feedback フィールドにコメントを入力します。
  6. (オプション) ドキュメントチームが連絡を取り問題についてお伺いできるように、ご自分のメールアドレスを追加します。
  7. Submit をクリックします。

第1章 Red Hat OpenStack Platform のアップグレードフレームワークについて

アップグレード用の Red Hat OpenStack Platform(RHOSP)フレームワークは、RHOSP 環境をあるロングライフバージョンから次のロングライフバージョンにアップグレードするためのワークフローです。このワークフローはインプレースのソリューションで、アップグレードは既存の環境内で実行されます。

1.1. ロングライフバージョンのアップグレードフレームワーク

Red Hat OpenStack Platform(RHOSP) アップグレードフレームワーク を使用して、複数バージョンのオーバークラウドのインプレースアップグレードパスを実施することができます。この機能は、ロングライフバージョン とされている特定の OpenStack のバージョンの使用を継続し、次のロングライフバージョンが提供された際にアップグレードする機会を提供することを目的としています。

Red Hat OpenStack Platform のアップグレードプロセスでは、ノード上の Red Hat Enterprise Linux(RHEL)のバージョンもアップグレードします。

本ガイドは、以下のバージョン間のアップグレードフレームワークを提供します。

現在のバージョン目的のバージョン

Red Hat OpenStack Platform 13 latest

Red Hat OpenStack Platform 16.2 latest

1.2. ロングライフバージョンのライフサイクルサポート

Red Hat OpenStack Platform のライフサイクルサポートに関する正確な日付けおよび詳細な情報は、Red Hat OpenStack Platform のライフサイクルを参照してください。

1.3. ロングライフリリースのアップグレードパス

更新またはアップグレードを開始する前に、更新およびアップグレードパスについて理解してください。メジャーバージョンからメジャーバージョンへのアップグレードを実行する前に、まず既存の環境を最新のマイナーリリースに更新する必要があります。

たとえば、現在のデプロイメントが Red Hat Enterprise Linux(RHEL)7.9 上の Red Hat OpenStack Platform(RHOSP)13.0.6 の場合、RHOSP 16.2 にアップグレードする前に最新の RHOSP 13.0 バージョンに対してマイナーアップデートを実行する必要があります。

注記

現在の RHOSP および RHEL バージョンは、/etc/rhosp-release ファイルおよび /etc/redhat-release ファイルで確認できます。

表1.1 バージョンパスを更新します。

現行バージョンターゲットバージョン

RHEL 7.x 上の RHOSP 10.0.x

RHEL 7.7 の最新 RHOSP 10.0

RHEL 7.x 上の RHOSP 13.0.x

RHEL 7.9 の最新 RHOSP 13.0

RHEL 8.2 上の RHOSP 16.1.x

RHEL 8.2 の最新 RHOSP 16.1 の最新

RHEL 8.2 上の RHOSP 16.1.x

RHEL 8.4 の最新 RHOSP 16.2

RHEL 8.4 における RHOSP 16.2.x

RHEL 8.4 の最新 RHOSP 16.2

詳細は、「 Red Hat OpenStack Platform の最新状態の維持」を参照して ください。

表1.2 バージョンパスのアップグレード

現行バージョンターゲットバージョン

RHEL 7.7 における RHOSP 10

RHEL 7.9 の最新 RHOSP 13

RHEL 7.9 における RHOSP 13

RHEL 8.2 の最新 RHOSP 16.1 の最新

RHEL 7.9 における RHOSP 13

RHEL 8.4 の最新 RHOSP 16.2

Red Hat では、お使いの環境を次のロングライフリリースにアップグレードするためのオプションを 2 つ提供しています。

インプレースアップグレード
既存の環境でサービスのアップグレードを実施します。本ガイドでは、主にこのオプションを中心に説明します。
並列移行
新しい Red Hat OpenStack Platform 16.2 環境を作成し、ワークロードを現在の環境から新しい環境に移行します。Red Hat OpenStack Platform の並列移行についての詳しい情報は、Red Hat Global Professional Services にお問い合わせください。
重要

以下の表に示す時間は内部テストに基づく最短の推定値であり、すべての実稼働環境には適用されない可能性があります。たとえば、ハードウェアのスペックが低い場合やブート時間が長い場合は、これらの時間に余裕を持たせてください。各タスクのアップグレード時間を正確に測定するには、実稼働環境と類似したハードウェアを持つテスト環境でこれらの手順を実施してください。

表1.3 アップグレードパスの影響と時間

 インプレースアップグレード並列移行

アンダークラウドのアップグレード時間

それぞれの主要な操作の推定時間は以下のとおりです。

  • Leapp アップグレードコマンド: 30 分間
  • Leapp リブート: 30 分間
  • director のアップグレード: 40 分間

なし。既存のアンダークラウドに加えて、新しいアンダークラウドを作成します。

オーバークラウドコントロールプレーンのアップグレード時間

コントローラーノードごとの推定時間は以下のとおりです。

  • Leapp アップグレードおよびリブート: 60 分間
  • サービスのアップグレード: 60 分間

なし。既存のコントロールプレーンに加えて、新しいコントロールプレーンを作成します。

コントロールプレーンの機能停止時間

ブートストラップコントローラーノードのサービスアップグレード時間: 約 60 分間

なし。ワークロードの移行中、両方のオーバークラウドは稼動状態にあります。

コントロールプレーンの機能停止による影響

機能停止時間中 OpenStack の操作を行うことはできません。

機能停止時間はありません。

オーバークラウドデータプレーンのアップグレード時間

コンピュートノードおよび Ceph Storage ノードごとの推定時間は以下のとおりです。

  • Leapp アップグレードおよびリブート: 60 分間
  • サービスのアップグレード: 30 分間

なし。既存のデータプレーンに加えて、新しいデータプレーンを作成します。

データプレーンの機能停止時間

ノード間のワークロードの移行により、機能停止時間は最小限に抑えられます。

オーバークラウド間のワークロードの移行により、機能停止時間は最小限に抑えられます。

追加ハードウェアに関する要件

追加のハードウェアは必要ありません。

新しいアンダークラウドおよびオーバークラウドを作成するために、追加のハードウェアが必要です。

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

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

2.1. Red Hat OpenStack Platform 16.2 の理解

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

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

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

  • OpenStack Platform director 16.2 では、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 のコンポーネントは非推奨になりました。
  • Red Hat Enterprise Linux (RHEL) バージョン 8.3 以降、Intel Transactional Synchronization Extensions (TSX) 機能のサポートはデフォルトで無効になっています。これにより、RHEL バージョン 8.2 を使用する Red Hat OpenStack Platform 13 を実行するホストから、RHEL バージョン 8.4 で Red Hat OpenStack Platform 16.2 を実行するホストに移行する場合に、ホスト間のインスタンスのライブマイグレーションに関連する問題が発生します。

    コンピュートノードをリブートすると、インスタンスのライブマイグレーションに失敗します。アップグレードしたノードが TSX 機能を有効にして起動し、インスタンスを正常に移行できるようにするには、コンピュートノードの KernelArgs ロールパラメーターに tsx=off を追加して、ノードをリブートします。

    詳細は、Red Hat ナレッジベースのソリューション「Gidance on Intel TSX impact on OpenStack guests(RHEL 8.3 以降)」を参照し てください。

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.2 は、ベースオペレーティングシステムとして Red Hat Enterprise Linux 8.4 を使用します。アップグレードプロセスの一環として、ノードのベースオペレーティングシステムを Red Hat Enterprise Linux 8.4 にアップグレードします。

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 へのアップグレードを実施します。Leapp およびその依存関係を利用できるようにするには、以下の Red Hat Enterprise Linux 7 リポジトリーが有効であることを確認します。

  • Red Hat Enterprise Linux 7 Server RPMs x86_64 7Server または Red Hat Enterprise Linux 7 Server RPMs x86_64 7.9

    rhel-7-server-rpms
    x86_64 7Server
    or:
    rhel-7-server-rpms
    x86_64 7.9
  • Red Hat Enterprise Linux 7 Server - Extras RPMs x86_64

    rhel-7-server-extras-rpms
    x86_64

詳細は、「アップグレードに向けて RHEL 7 システムの準備」を参照してください。

オペレーティングシステムのアップグレードを実施する際、アンダークラウドとオーバークラウドでは別個のプロセスが使用されます。

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

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

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

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

制限

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

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

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

トラブルシューティング

Leapp が原因と考えられる問題のトラブルシューティングに関する詳細は、『RHEL 7 から RHEL 8 へのアップグレード』「トラブルシューティング」を参照してください。

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)
  • インスタンス HA が有効な環境

    注記

    アップグレードの際には、nova ライブマイグレーションがサポートされます。ただし、インスタンス HA が開始する避難はサポートされません。コンピュートノードをアップグレードする場合、ノードはクリーンにシャットダウンされ、ノード上で実行されているワークロードはインスタンス HA によって自動的に退避されません。その代わり、手動でライブマイグレーションを行う必要があります。

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

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

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

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

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

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

  1. Red Hat OpenStack Platform デプロイメントをバージョン 13 からバージョン 16.2 にアップグレードする前に、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.2 へのアップグレードフレームワーク』に記載のアップグレードパスに従うことができます。該当する場合は、この特定のシナリオをサポートする条件ステップを実行する必要があります。条件ステップは、「外部の Ceph デプロイメントと共にアップグレードする場合は」で始まる箇所です。
  4. 外部の Ceph デプロイメントと共にアップグレードする場合は、オーバークラウドのアップグレードプロセスの一部として RHCSv4 ceph-ansible をインストールします。director を使用してデプロイされた Ceph クラスターをアップグレードする場合は、オーバークラウドのアップグレードプロセスの完了後に RHCSv4 ceph-ansible をインストールします。
重要

Red Hat Ceph Storage クラスターを、以前のサポート対象バージョンからバージョン 4.2z2 にアップグレードする場合、モニターがセキュアでないglobal_id 再要求を許可する ことを示す警告メッセージと共に、ストレージクラスターが HEALTH_WARN の状態でアップグレードが完了します。これは、パッチが適用された CVE (CVE-2021-20288) が原因です。「Ceph HEALTH_WARN with 'mons are allowing insecure global_id reclaim' after install/upgrade to RHCS 4.2z2 (or newer)」を参照してください。

CVE により HEALTH_WARN の状態が表示されるため、一時的に健全性についての警告をミュートすることができます。ただし、警告をミュートすると、古いクライアントおよびパッチが適用されていないクライアントがクラスターに接続されても表示されないリスクがあります。健全性についての警告のミュートについての詳細は、Red Hat Ceph Storage のドキュメントの「Upgrading a Red Hat Ceph Storage cluster」を参照してください。

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

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

BZ#1902849 - osp13-osp16.1 ffu fails on clusters previously upgraded from osp8, osp10
以前にバージョン RHOSP 10 からアップグレードした Red Hat OpenStack Platform (RHOSP) 環境には、BZ#1902849 を避けるために python-docker パッケージが必要です。詳細は、Red Hat ナレッジベースのソリューション「osp13-osp16.1 ffu fails on older environments missing python-docker package」を参照してください。
BZ#1925078 - RHOSP13-16.1 FFU: Overcloud upgrade hangs in controller after failed attempt with reference to wrong ceph image.

OSP13 で UEFI ブートおよび UEFI ブートローダーを使用するシステムは、UEFI の問題が発生し以下のような状況に陥る可能性があります。

  • /etc/fstab が更新されない
  • EFI システムで grub-install が誤って使用される

詳細は、Red Hat ナレッジベースのソリューション「FFU 13 to 16.1: Leapp fails to update the kernel on UEFI based systems and /etc/fstab does not contain the EFI partition」を参照してください。

システムで UEFI が使用されている場合は、Red Hat Technical Support にお問い合わせください。

BZ#1895887 - [FFWD] ovs+dpdk fail to attach device OvsDpdkHCI

Leapp ユーティリティーを使用してアップグレードした後、OVS-DPDK 負荷を持つコンピュートノードが正しく機能しません。この問題を解決するには、次のいずれかの操作を行います。

コンピュートノードをアップグレードする前に、/etc/modules-load.d/vfio-pci.conf ファイルを削除します。

または

コンピュートノードのアップグレード後に、コンピュートノードで ovs-vswitchd サービスを再起動します。

この問題は RHOSP 16.1.3 に影響を及ぼします。詳細については、Red Hat ナレッジベースのソリューション「OVS-DPDK errors after Framework Upgrade from OSP 13 to 16.1 on HCI compute node」を参照してください。

BZ#1965350 - OSP13→16.2 leapp fails with: Detected loaded kernel drivers which have been removed in RHEL 8
バグ BZ#1965350 を回避するには、アンダークラウドおよびオーバークラウドノードの Leapp によるアップグレードプロセス中に、RHEL 8 でサポートされなくなった floppy および pata_acpi カーネルモジュールをアンロードする必要があります。本ガイドには、この問題を避けるための回避策が含まれています。
BZ#1923165 - OSP-16.2 (Upgrades)(TripleO) Add a config to disable Intel "TSX" on RHEL-8.3 kernel

Red Hat Enterprise Linux (RHEL) バージョン 8.3 以降、Intel Transactional Synchronization Extensions (TSX) 機能のサポートはデフォルトで無効になっています。これにより、以下の移行シナリオにおけるホスト間でのインスタンスのライブマイグレーションで問題が発生します。

  • TSX カーネル引数が有効なホストから TSX カーネル引数が無効なホストへの移行。

TSX 機能をサポートする Intel ホストでは、ライブマイグレーションに失敗する場合があります。この問題の影響を受ける CPU の詳細は、「Affected Configurations」を参照してください。

詳細は、Red Hat ナレッジベースのソリューション「Guidance on Intel TSX impact on OpenStack guests」を参照してください。

BZ#2016144 - FFU 13-16.1: Leapp アップグレードの再起動時に openvswitch が Starting ovsdb-server ovsdb-server: /var/run/openvswitch/ovsdb-server.pid.tmp: create failed (Permission denied)とのエラーで起動に失敗する
以前のバージョンからアップグレードされた Red Hat Open Stack Platform (RHOSP) 環境には、/etc/systemd/system/ovs*に不要なファイルが含まれている可能性があります。RHOSP 13 から RHOSP 16.2 へのオーバークラウドのアップグレードプロセスを開始する前に、これらのファイルを削除する必要があります。
BZ#2021525 - openstack overcloud upgrade run times out / HAProxy container fails to start
Red Hat Open Stack Platform (RHOSP) 13 から RHOSP 16.2 へのアップグレードは、無効な SELinux ラベルが原因でデプロイメントステップ中に失敗することがあります。解決策や詳細については、Red Hat ナレッジベースのソリューションPacemaker managed services might not restart during an OSP13 - OSP16.x FFUを参照してください。
BZ#2008976 - Python2 packages cleaning up after Leapp upgrade failing in Leapp dependencies

Leapp バージョン 5.0.8-100.202109241452Z.1332835 では、Leapp パッケージを保持する DNFのexcludeオプションのため、python2Leapp パッケージの自動削除は失敗します。

UpgradeInitCommandパラメーターを環境ファイルに追加し、DNF の exclude ステートメントを削除します。

parameter defaults:
  UpgradeInitCommand: "sudo dnf config-manager --save --setopt exclude=''"

詳しくは、アップグレード環境ファイルの作成をご覧ください。

BZ#1978228 - OSP13→16.2 Leapp upgrade failed with TLSEverywhere
お使いの環境で TLS-Everywhere を使用していて、authconfigからauthselectに移行したい場合は、authselect_check.confirmパラメーターをTrueに設定してください。それ以外の場合は、この値をFalseに設定します。詳しくは、アップグレード環境ファイルの作成をご覧ください。
BZ#2015325 - FFU: upgrade failed during "Upgrade Mysql database from a temporary container" step
Red Hat Enterprise Linux にはmariadb-server 用のアップグレード可能な RPM が含まれていますが、これが Red Hat Open Stack Platform (RHOSP) のコンテナー化された mariadb のアップグレードを妨害します。RHOSP のアップグレードを行う前に、コントローラーホストからmariadb-serverパッケージを削除します。詳しくは、アップグレード環境ファイルの作成をご覧ください。
BZ#2027787 - FFU: undercloud upgrade to 16.2 fails because of missing dependencies of swtpm

advanced-virt-for-rhel-8-x86_64-rpmおよびadvanced-virt-for-rhel-8-x86_64-eus-rpmリポジトリーには、アップグレードが正常に行われないという既知の問題があります。

  1. これらのリポジトリーを無効にします。

    $ sudo subscription-manager repos \
    --disable=advanced-virt-for-rhel-8-x86_64-rpms \
    --disable=advanced-virt-for-rhel-8-x86_64-eus-rpms
  2. アンダークラウドまたはオーバークラウドにインストールされているこれらのリポジトリーのパッケージをすべて削除します。
  3. アップグレード環境ファイルにUpgradeLeappCommandOptionsパラメーターを追加し、必要なリポジトリーを有効にします。詳しくは、アップグレード環境ファイルの作成をご覧ください。
BZ#2024447: FFU RHOSP 13 から 16 まで、配置ユーザーの Identity サービス(keystone)パスワードは NovaPassword によってオーバーライドされました。

Red Hat OpenStack Platform 13 から 16.2 へのアップグレード中に NovaPassword パラメーターの値を定義し、PlacementPassword パラメーターにない場合、NovaPassword パラメーターは placement ユーザーの OpenStack Identity サービス(keystone)パスワードを上書きします。Identity サービスのパスワードを保存するには、parameter_defaults セクションに NovaPassword または PlacementPassword を設定しないでください。

parameter_defaults セクションで両方のパスワードを設定した場合には、コンピュートノードはアップグレードされるまでコントロールプレーンと通信できない場合があります。コンピュートノードのアップグレードについての詳しい情報は、『director のインストールと使用方法』の「コンピュートノード のアップグレード」を参照してください。

また、NovaPasswordPlacementPassword、またはその両方を使用して RHOSP 13 にオーバークラウドをデプロイした場合には、それらのパスワードをテンプレートから削除し、RHOSP 16.2 にアップグレードする前に RHOSP 13 で openstack overcloud deploy コマンドを実行する必要があります。

Red Hat Ceph Storage の問題

BZ#1855813 - [FFU] 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.2 へのアップグレードを実施する前に、Red Hat OpenStack Platform 13 環境のマイナーバージョン更新を実施し、ceph-ansible のバージョンが 3.2.46 以降になるようにしてください。

2.8. バックアップおよび復元

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

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

Red Hat OpenStack Platform 環境をアップグレードする前に、環境を現在のリリースの最新マイナーバージョンに更新します。たとえば、Red Hat OpenStack Platform 16.2 へのアップグレードを実施する前に、お使いの 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.2 へのアップグレード後も維持されます。

2.11. RHEL 登録リソースの削除

既存の環境ファイルまたは rhel-registration.yaml テンプレートで DeleteOnRHELUnregistration パラメーターが true に設定されている場合には、オーバークラウドのアップグレードを続行できません。この場合は、最新の Red Hat OpenStack Platform 13z バージョンへのマイナーアップデートを実行する際に、DeleteOnRHELUnregistration パラメーターを false に設定します。

手順

  1. DeleteOnRHELUnregistration パラメーターが true に設定されている場合、環境ファイルの parameter_defaults セクションで、パラメーターを false に設定します。
  2. openstack overcloud update prepare コマンドを実行します。
  3. openstack undercloud upgrade コマンドを実行します。

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

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

注記

CDN または Satellite をリポジトリーソースとして使用すると、検証に失敗します。この問題を解決するには、Red Hat ナレッジベースのソリューション「Repository validation fails because of SSL certificate error 」を参照してください。

手順

  1. アンダークラウドに stack ユーザーとしてログインします。
  2. 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

第3章 リポジトリー

本項では、アンダークラウドおよびオーバークラウドのリポジトリーについて説明します。特定の状況において、リポジトリーを有効にする必要がある場合は、本項を参照してください。

  • Red Hat カスタマーポータルに登録する際にリポジトリーを有効にする。
  • リポジトリーを有効にして Red Hat Satellite Server に同期させる。
  • Red Hat Satellite Server に登録する際にリポジトリーを有効にする。

3.1. アンダークラウドのリポジトリー

Red Hat OpenStack Platform 16.2 は、Red Hat Enterprise Linux 8.4 上で動作します。したがって、これらのリポジトリーからのコンテンツを該当する Red Hat Enterprise Linux バージョンにロックする必要があります。

注記

リポジトリーを Red Hat Satellite と同期する場合は、特定バージョンの Red Hat Enterprise Linux リポジトリーを有効にすることができます。ただし、選択したバージョンに関係なく、リポジトリーは同じままです。たとえば、BaseOS リポジトリーの 8.4 バージョンを有効にすることができますが、リポジトリー名は、選択した特定のバージョンに関係なく rhel-8-for-x86_64-baseos-eus-rpms のままになります。

警告

ここで指定する以外のリポジトリーは、サポートされません。別途推奨されない限り、以下の表に記載されている以外の製品またはリポジトリーを有効にしないでください。有効にすると、パッケージの依存関係の問題が発生する可能性があります。Extra Packages for Enterprise Linux (EPEL) を有効にしないでください。

コアリポジトリー

以下の表には、アンダークラウドをインストールするためのコアリポジトリーをまとめています。

名前リポジトリー要件の説明

Red Hat Enterprise Linux 8 for x86_64 - BaseOS (RPMs) Extended Update Support (EUS)

rhel-8-for-x86_64-baseos-eus-rpms

x86_64 システム用ベースオペレーティングシステムのリポジトリー

Red Hat Enterprise Linux 8 for x86_64 - AppStream (RPMs)

rhel-8-for-x86_64-appstream-eus-rpms

Red Hat OpenStack Platform の依存関係が含まれます。

Red Hat Enterprise Linux 8 for x86_64 - High Availability (RPMs) Extended Update Support (EUS)

rhel-8-for-x86_64-highavailability-eus-rpms

Red Hat Enterprise Linux の高可用性ツール。コントローラーノードの高可用性に使用します。

Red Hat Ansible Engine 2.9 for RHEL 8 x86_64 (RPMs)

ansible-2.9-for-rhel-8-x86_64-rpms

Red Hat Enterprise Linux 用 Ansible エンジン。最新バージョンの Ansible を提供するために使用されます。

Red Hat Satellite Tools for RHEL 8 Server RPMs x86_64

satellite-tools-<satellite_version>-for-rhel-8-x86_64-rpms

Red Hat Satellite 6 でホストを管理するツール。<satellite_version> は、使用する Red Hat Satellite Server のバージョンに置き換えます。

Red Hat OpenStack Platform 16.2 for RHEL 8 (RPMs)

openstack-16.2-for-rhel-8-x86_64-rpms

Red Hat OpenStack Platform のコアリポジトリー。Red Hat OpenStack Platform director のパッケージが含まれます。

Red Hat Fast Datapath for RHEL 8 (RPMS)

fast-datapath-for-rhel-8-x86_64-rpms

OpenStack Platform 用 Open vSwitch (OVS) パッケージを提供します。

Ceph リポジトリー

以下の表には、アンダークラウド用の Ceph Storage 関連のリポジトリーをまとめています。

名前リポジトリー要件の説明

Red Hat Ceph Storage Tools 4 for RHEL 8 x86_64 (RPMs)

rhceph-4-tools-for-rhel-8-x86_64-rpms

Ceph Storage クラスターと通信するためのノード用のツールを提供します。オーバークラウドで Ceph Storage を使用する場合、または既存の Ceph Storage クラスターと統合する場合、アンダークラウドにはこのリポジトリーからの ceph-ansible パッケージが必要です。

IBM POWER 用リポジトリー

以下の表には、POWER PC アーキテクチャー上で Red Hat Openstack Platform を構築するためのリポジトリーを一覧にしてまとめています。コアリポジトリーの該当リポジトリーの代わりに、これらのリポジトリーを使用してください。

名前リポジトリー要件の説明

Red Hat Enterprise Linux for IBM Power, little endian - BaseOS (RPMs)

rhel-8-for-ppc64le-baseos-rpms

ppc64le システム用ベースオペレーティングシステムのリポジトリー

Red Hat Enterprise Linux 8 for IBM Power, little endian - AppStream (RPMs)

rhel-8-for-ppc64le-appstream-rpms

Red Hat OpenStack Platform の依存関係が含まれます。

Red Hat Enterprise Linux 8 for IBM Power, little endian - High Availability (RPMs)

rhel-8-for-ppc64le-highavailability-rpms

Red Hat Enterprise Linux の高可用性ツール。コントローラーノードの高可用性に使用します。

Red Hat Fast Datapath for RHEL 8 IBM Power, little endian (RPMS)

fast-datapath-for-rhel-8-ppc64le-rpms

OpenStack Platform 用 Open vSwitch (OVS) パッケージを提供します。

Red Hat Ansible Engine 2.9 for RHEL 8 IBM Power, little endian (RPMs)

ansible-2.9-for-rhel-8-ppc64le-rpms

Red Hat Enterprise Linux 用 Ansible エンジン。最新バージョンの Ansible を提供します。

Red Hat OpenStack Platform 16.2 for RHEL 8 (RPMs)

openstack-16.2-for-rhel-8-ppc64le-rpms

ppc64le システム用 Red Hat OpenStack Platform のコアリポジトリー

3.2. オーバークラウドのリポジトリー

Red Hat OpenStack Platform 16.2 は、Red Hat Enterprise Linux 8.4 上で動作します。したがって、これらのリポジトリーからのコンテンツを該当する Red Hat Enterprise Linux バージョンにロックする必要があります。

注記

リポジトリーを Red Hat Satellite と同期する場合は、特定バージョンの Red Hat Enterprise Linux リポジトリーを有効にすることができます。ただし、選択したバージョンに関係なく、リポジトリーは同じままです。たとえば、BaseOS リポジトリーの 8.4 バージョンを有効にすることができますが、リポジトリー名は、選択した特定のバージョンに関係なく rhel-8-for-x86_64-baseos-eus-rpms のままになります。

警告

ここで指定する以外のリポジトリーは、サポートされません。別途推奨されない限り、以下の表に記載されている以外の製品またはリポジトリーを有効にしないでください。有効にすると、パッケージの依存関係の問題が発生する可能性があります。Extra Packages for Enterprise Linux (EPEL) を有効にしないでください。

コントローラーノード用リポジトリー

以下の表には、オーバークラウドのコントローラーノード用コアリポジトリーをまとめています。

名前リポジトリー要件の説明

Red Hat Enterprise Linux 8 for x86_64 - BaseOS (RPMs) Extended Update Support (EUS)

rhel-8-for-x86_64-baseos-eus-rpms

x86_64 システム用ベースオペレーティングシステムのリポジトリー

Red Hat Enterprise Linux 8 for x86_64 - AppStream (RPMs)

rhel-8-for-x86_64-appstream-eus-rpms

Red Hat OpenStack Platform の依存関係が含まれます。

Red Hat Enterprise Linux 8 for x86_64 - High Availability (RPMs) Extended Update Support (EUS)

rhel-8-for-x86_64-highavailability-eus-rpms

Red Hat Enterprise Linux の高可用性ツール。

Red Hat Ansible Engine 2.9 for RHEL 8 x86_64 (RPMs)

ansible-2.9-for-rhel-8-x86_64-rpms

Red Hat Enterprise Linux 用 Ansible エンジン。最新バージョンの Ansible を提供するために使用されます。

Red Hat OpenStack Platform 16.2 for RHEL 8 (RPMs)

openstack-16.2-for-rhel-8-x86_64-rpms

Red Hat OpenStack Platform のコアリポジトリー

Red Hat Fast Datapath for RHEL 8 (RPMS)

fast-datapath-for-rhel-8-x86_64-rpms

OpenStack Platform 用 Open vSwitch (OVS) パッケージを提供します。

Red Hat Ceph Storage Tools 4 for RHEL 8 x86_64 (RPMs)

rhceph-4-tools-for-rhel-8-x86_64-rpms

Red Hat Enterprise Linux 8 での Red Hat Ceph Storage 4 用ツール

Red Hat Satellite Tools for RHEL 8 Server RPMs x86_64

satellite-tools-<satellite_version>-for-rhel-8-x86_64-rpms

Red Hat Satellite 6 でホストを管理するツール。<satellite_version> は、使用する Red Hat Satellite Server のバージョンに置き換えます。

コンピュートノード用リポジトリー

以下の表には、オーバークラウドのコンピュートノード用コアリポジトリーをまとめています。

名前リポジトリー要件の説明

Red Hat Enterprise Linux 8 for x86_64 - BaseOS (RPMs) Extended Update Support (EUS)

rhel-8-for-x86_64-baseos-eus-rpms

x86_64 システム用ベースオペレーティングシステムのリポジトリー

Red Hat Enterprise Linux 8 for x86_64 - AppStream (RPMs)

rhel-8-for-x86_64-appstream-eus-rpms

Red Hat OpenStack Platform の依存関係が含まれます。

Red Hat Enterprise Linux 8 for x86_64 - High Availability (RPMs) Extended Update Support (EUS)

rhel-8-for-x86_64-highavailability-eus-rpms

Red Hat Enterprise Linux の高可用性ツール。

Red Hat Ansible Engine 2.9 for RHEL 8 x86_64 (RPMs)

ansible-2.9-for-rhel-8-x86_64-rpms

Red Hat Enterprise Linux 用 Ansible エンジン。最新バージョンの Ansible を提供するために使用されます。

Red Hat OpenStack Platform 16.2 for RHEL 8 (RPMs)

openstack-16.2-for-rhel-8-x86_64-rpms

Red Hat OpenStack Platform のコアリポジトリー

Red Hat Fast Datapath for RHEL 8 (RPMS)

fast-datapath-for-rhel-8-x86_64-rpms

OpenStack Platform 用 Open vSwitch (OVS) パッケージを提供します。

Red Hat Ceph Storage Tools 4 for RHEL 8 x86_64 (RPMs)

rhceph-4-tools-for-rhel-8-x86_64-rpms

Red Hat Enterprise Linux 8 での Red Hat Ceph Storage 4 用ツール

Red Hat Satellite Tools for RHEL 8 Server RPMs x86_64

satellite-tools-<satellite_version>-for-rhel-8-x86_64-rpms

Red Hat Satellite 6 でホストを管理するツール。<satellite_version> は、使用する Red Hat Satellite Server のバージョンに置き換えます。

リアルタイムコンピュート用リポジトリー

以下の表には、リアルタイムコンピュート (RTC) 機能用リポジトリーをまとめています。

名前リポジトリー要件の説明

Red Hat Enterprise Linux 8 for x86_64 - Real Time (RPMs)

rhel-8-for-x86_64-rt-rpms

リアルタイム KVM (RT-KVM) のリポジトリー。リアルタイムカーネルを有効化するためのパッケージが含まれています。RT-KVM 対象の全コンピュートノードで、このリポジトリーを有効にします。注記: このリポジトリーにアクセスするには、別途 Red Hat OpenStack Platform for Real Time SKU のサブスクリプションが必要です。

Red Hat Enterprise Linux 8 for x86_64 - Real Time for NFV (RPMs)

rhel-8-for-x86_64-nfv-rpms

NFV 向けのリアルタイム KVM (RT-KVM) のリポジトリー。リアルタイムカーネルを有効化するためのパッケージが含まれています。RT-KVM 対象の全 NFV コンピュートノードで、このリポジトリーを有効にします。注記: このリポジトリーにアクセスするには、別途 Red Hat OpenStack Platform for Real Time SKU のサブスクリプションが必要です。

Ceph Storage ノード用リポジトリー

以下の表には、オーバークラウド用の Ceph Storage 関連のリポジトリーをまとめています。

名前リポジトリー要件の説明

Red Hat Enterprise Linux 8 for x86_64 - BaseOS (RPMs)

rhel-8-for-x86_64-baseos-rpms

x86_64 システム用ベースオペレーティングシステムのリポジトリー

Red Hat Enterprise Linux 8 for x86_64 - AppStream (RPMs)

rhel-8-for-x86_64-appstream-rpms

Red Hat OpenStack Platform の依存関係が含まれます。

Red Hat Ansible Engine 2.9 for RHEL 8 x86_64 (RPMs)

ansible-2.9-for-rhel-8-x86_64-rpms

Red Hat Enterprise Linux 用 Ansible エンジン。最新バージョンの Ansible を提供するために使用されます。

Red Hat OpenStack Platform 16.2 Director Deployment Tools for RHEL 8 x86_64 (RPMs)

openstack-16.2-deployment-tools-for-rhel-8-x86_64-rpms

director が Ceph Storage ノードを設定するのに役立つパッケージ。このリポジトリーは、スタンドアロンの Ceph Storage サブスクリプションに含まれています。OpenStack Platform と Ceph Storage を組み合わせたサブスクリプションを使用する場合は、openstack-16.2-for-rhel-8-x86_64-rpms リポジトリーを使用します。

Red Hat OpenStack Platform 16.2 for RHEL 8 (RPMs)

openstack-16.2-for-rhel-8-x86_64-rpms

director が Ceph Storage ノードを設定するのに役立つパッケージ。このリポジトリーは、OpenStack Platform と Ceph Storage を組み合わせたサブスクリプションに含まれています。スタンドアロンの Ceph Storage サブスクリプションを使用する場合は、openstack-16.2-deployment-tools-for-rhel-8-x86_64-rpms リポジトリーを使用します。

Red Hat Ceph Storage Tools 4 for RHEL 8 x86_64 (RPMs)

rhceph-4-tools-for-rhel-8-x86_64-rpms

Ceph Storage クラスターと通信するためのノード用のツールを提供します。

IBM POWER 用リポジトリー

以下の表には、POWER PC アーキテクチャー上で OpenStack Platform を構築するためのリポジトリーをまとめています。コアリポジトリーの該当リポジトリーの代わりに、これらのリポジトリーを使用してください。

名前リポジトリー要件の説明

Red Hat Enterprise Linux for IBM Power, little endian - BaseOS (RPMs)

rhel-8-for-ppc64le-baseos-rpms

ppc64le システム用ベースオペレーティングシステムのリポジトリー

Red Hat Enterprise Linux 8 for IBM Power, little endian - AppStream (RPMs)

rhel-8-for-ppc64le-appstream-rpms

Red Hat OpenStack Platform の依存関係が含まれます。

Red Hat Enterprise Linux 8 for IBM Power, little endian - High Availability (RPMs)

rhel-8-for-ppc64le-highavailability-rpms

Red Hat Enterprise Linux の高可用性ツール。コントローラーノードの高可用性に使用します。

Red Hat Fast Datapath for RHEL 8 IBM Power, little endian (RPMS)

fast-datapath-for-rhel-8-ppc64le-rpms

OpenStack Platform 用 Open vSwitch (OVS) パッケージを提供します。

Red Hat Ansible Engine 2.9 for RHEL 8 IBM Power, little endian (RPMs)

ansible-2.9-for-rhel-8-ppc64le-rpms

Red Hat Enterprise Linux 用 Ansible エンジン。最新バージョンの Ansible を提供するために使用されます。

Red Hat OpenStack Platform 16.2 for RHEL 8 (RPMs)

openstack-16.2-for-rhel-8-ppc64le-rpms

ppc64le システム用 Red Hat OpenStack Platform のコアリポジトリー

3.3. Red Hat Satellite Server 6 に関する考慮事項

Red Hat Satellite Server 6 を使用して Red Hat OpenStack Platform 環境用の RPM およびコンテナーイメージをホストする場合、Red Hat OpenStack Platform 16.2 のアップグレード中に Satellite Server 6 を使用してコンテンツを提供する際には、特定の考慮事項があります。

現在の環境についての仮定

  • Satellite Server がすでに Red Hat OpenStack Platform 13 の RPM およびコンテナーイメージをホストしている。
  • Red Hat OpenStack Platform 13 環境内の全ノードを、ご自分の Satellite Server サーバーにすでに登録している。たとえば、以前に Red Hat OpenStack Platform 13 のコンテンツビューにリンクされたアクティベーションキーを使用して、ノードを OpenStack Platform 13 のコンテンツに登録した。

Red Hat OpenStack Platform のアップグレードに関する推奨事項

  • Red Hat OpenStack Platform 13 のアンダークラウドおよびオーバークラウドの両方に必要な RPM リポジトリーを有効にして同期します。これには、必要な Red Hat Enterprise Linux 8.4 リポジトリーが含まれます。
  • ご自分の Satellite Server にカスタム製品を作成し、以下の Red Hat OpenStak Platform バージョン用のコンテナーイメージをホストします。

    • Red Hat OpenStack Platform 16.2
    • Red Hat OpenStack Platform 15
  • Red Hat OpenStack Platform 16.2 アップグレード用のコンテンツビューを作成してプロモートし、以下のコンテンツをコンテンツビューに含めます。

    • 以下の Red Hat Enterprise Linux 7 リポジトリー

      • Red Hat Enterprise Linux 7 Server RPMs x86_64 7Server または Red Hat Enterprise Linux 7 Server RPMs x86_64 7.9

        rhel-7-server-rpms
        x86_64 7Server
        or:
        rhel-7-server-rpms
        x86_64 7.9
      • Red Hat Enterprise Linux 7 Server - Extras RPMs x86_64

        rhel-7-server-extras-rpms
        x86_64
    • Red Hat Enterprise Linux 8.4 リポジトリーを含む、アンダークラウドおよびオーバークラウドの全 RPM リポジトリーRed Hat Enterprise Linux リポジトリーの正しいバージョン(8.4)が含まれていることを確認してください。正しいバージョンが含まれていないと、RHEL 8 のリポジトリーを有効にする際に問題が発生する可能性があります。詳細については、Red Hat ナレッジベースのソリューションRHEL 7 to RHEL 8 LEAPP Upgrade Failing When Using Red Hat Satelliteを参照してください。
    • Red Hat OpenStack Platform 16.2 コンテナーイメージ
    • Red Hat OpenStack Platform 15 コンテナーイメージ
  • アクティベーションキーを、Red Hat OpenStack Platform 16.2 のアップグレード用に作成した Red Hat OpenStack Platform 16.2 のコンテンツビューに関連付けます。
  • どのノードにも katello-host-tools-fact-plugin パッケージがインストールされていないことを確認します。Leapp によるアップグレードではこのパッケージがアップグレードされず、パッケージが Red Hat Enterprise Linux 8.4 システムに残されるので、subscription-manager がエラーを報告します。
  • Red Hat OpenStack Platform 16.2 コンテナーイメージをホストするように Satellite Server を設定することができます。詳しくは、『director の インストールと使用方法』 の「コンテナーイメージ用の Satellite サーバーの準備 」を参照してください。
  • Ceph のサブスクリプションを使用し、Ceph ストレージノード用に overcloud-minimal イメージを使用するように director を設定している場合、Satellite Server でコンテンツビューを作成し、以下の Red Hat Enterprise Linux (RHEL) 8.4 リポジトリーを追加する必要があります。

第4章 アンダークラウドアップグレードの準備

アンダークラウドのアップグレードを実施する前に、アンダークラウドのアップグレードが正常に実行されるように準備の手順を完了する必要があります。

4.1. 外部の Ceph と組み合わせたアップグレードの前提条件

外部の Ceph デプロイメントと共にアップグレードする場合、Red Hat OpenStack Platform デプロイメントをアップグレードする前に、Red Hat Ceph Storage クラスターをバージョン 3 からバージョン 4 にアップグレードする必要があります。詳細は、Red Hat Ceph Storage 4『インストールガイド』「Red Hat Ceph Storage クラスターのアップグレード」を参照してください。

4.2. 新たなメモリー要件

Red Hat OpenStack Platform 16.2 では、アンダークラウドに新たなメモリー要件が適用されます。

Red Hat OpenStack Platform 13Red Hat OpenStack Platform 16.2

16 GB RAM

24 GB RAM

アップグレードを続行する前に、アンダークラウドがこれらの新たな要件を満たすことを確認してください。

4.3. 予測可能なアンダークラウドノード NIC 名の使用

アンダークラウドノードで Leapp によるアップグレードを実施する前に、カーネルベースの NIC 名が使用されているかどうかを確認する必要があります。この NIC 名には、通常 eth の接頭辞が含まれます。NIC の割り当てに関して、通常これらの NIC 名は予測可能ではありません。

playbook-nics.yaml Playbook を実行して NIC の名前を変更し、インターフェースの NIC 接頭辞を使用することができます。また、Playbook の実行時に prefix 変数を変更することで、別の NIC 接頭辞を設定することもできます。ただし、NIC の変更は、Leapp によるアップグレードプロセスが完了し、ノードがリブートされた後にのみ適用されます。

手順

  1. アンダークラウドに stack ユーザーとしてログインします。
  2. playbook-nics.yaml という名前の Ansible Playbook を作成し、以下のコンテンツを Playbook にコピーします。

    ---
    - name: Rename eth devices
      hosts: all
      become: yes
      vars:
        prefix: "em"
        undercloud_conf: "/home/stack/undercloud.conf"
        osnet_conf: "/etc/os-net-config/config.json"
      tasks:
        - set_fact:
            eth_interfaces: "{{ ansible_interfaces | select('match','eth.*') | list }}"
        - debug:
            msg: "{{ eth_interfaces }}"
        - name: Update udev rules
          lineinfile:
            line: "SUBSYSTEM==\"net\", ACTION==\"add\", DRIVERS==\"?*\", ATTR{address}==\"{{ ansible_facts[item]['perm_macaddress'] | default(ansible_facts[item]['macaddress']) }}\", NAME=\"{{ item|replace('eth',prefix) }}\""
            path: /etc/udev/rules.d/70-rhosp-persistent-net.rules
            create: True
          with_items: "{{ eth_interfaces }}"
        - name: Rename eth files
          block:
            - name: Check that eth files exists
              stat:
                path: /etc/sysconfig/network-scripts/ifcfg-{{ item }}
              register: nic_result
              with_items: "{{ eth_interfaces }}"
            - name: Copy nic files using the new prefix
              copy:
                remote_src: True
                src: "{{ item.stat.path }}"
                dest: "{{ item.stat.path|replace('eth',prefix) }}"
              with_items: "{{ nic_result.results }}"
              when: item.stat.exists
            - name: Edit NAME in new network-script files
              lineinfile:
                regexp: "^NAME=.*"
                line: "NAME={{ item.item|replace('eth',prefix) }}"
                path: "{{ item.stat.path|replace('eth',prefix) }}"
              with_items: "{{ nic_result.results }}"
              when: item.stat.exists
            - name: Edit DEVICE in new network-script files
              lineinfile:
                regexp: "^DEVICE=.*"
                line: "DEVICE={{ item.item|replace('eth',prefix) }}"
                path: "{{ item.stat.path|replace('eth',prefix) }}"
              with_items: "{{ nic_result.results }}"
              when: item.stat.exists
            - name: Backup old eth network-script files
              copy:
                remote_src: True
                src: "{{ item.stat.path }}"
                dest: "{{ item.stat.path }}.bak"
              with_items: "{{ nic_result.results }}"
              when: item.stat.exists
            - name: Remove old eth network-script files
              file:
                path: "{{ item.stat.path }}"
                state: absent
              with_items: "{{ nic_result.results }}"
              when: item.stat.exists
        - name: Rename route files
          block:
            - name: Check that route files exists
              stat:
                path: /etc/sysconfig/network-scripts/route-{{ item }}
              register: route_result
              with_items: "{{ eth_interfaces }}"
            - name: Copy route files using the new prefix
              copy:
                remote_src: True
                src: "{{ item.stat.path }}"
                dest: "{{ item.stat.path|replace('eth',prefix) }}"
              with_items: "{{ route_result.results }}"
              when: item.stat.exists
            - name: Update prefix in route files that use IP command arguments format
              replace:
                regexp: "eth"
                replace: "{{ prefix }}"
                path: "{{ item.stat.path|replace('eth',prefix) }}"
              with_items: "{{ route_result.results }}"
              when: item.stat.exists
            - name: Backup old route files
              copy:
                remote_src: True
                src: "{{ item.stat.path }}"
                dest: "{{ item.stat.path }}.bak"
              with_items: "{{ route_result.results }}"
              when: item.stat.exists
            - name: Remove old route files
              file:
                path: "{{ item.stat.path }}"
                state: absent
              with_items: "{{ route_result.results }}"
              when: item.stat.exists
        - name: Perform a final regex for any remaining eth prefixes in ifcfg files
          block:
            - name: Get a list of all ifcfg files
              find:
                paths: /etc/sysconfig/network-scripts/
                patterns: 'ifcfg-*'
                excludes: '*.bak'
              register: ifcfg_files
            - name: Perform final regex on ifcfg files
              replace:
                path: "{{ item[0].path }}"
                regexp: "{{ item[1] }}"
                replace: "{{ item[1]|replace('eth',prefix) }}"
              with_nested:
                - "{{ ifcfg_files.files }}"
                - "{{ eth_interfaces }}"
        - name: Replace interface name in files referencing old eth interface
          block:
            - name: Check if undercloud.conf exists
              stat:
                path: "{{ undercloud_conf }}"
              register: undercloud_conf_stat
            - name: Replace interface name in undercloud.conf
              replace:
                path: "{{ undercloud_conf }}"
                regexp: 'eth(\d+)'
                replace: "{{ prefix }}\\1"
              when: undercloud_conf_stat.stat.exists
            - name: Check if os-net-config's config.json exists
              stat:
                path: "{{ osnet_conf }}"
              register: osnet_conf_stat
            - name: Replace interface name in config.json
              replace:
                path: "{{ osnet_conf }}"
                regexp: 'eth(\d+)'
                replace: "{{ prefix }}\\1"
              when: osnet_conf_stat.stat.exists
        - name: Patch vlan devices
          block:
            - name: Check that vlan files exists
              stat:
                path: /etc/sysconfig/network-scripts/ifcfg-{{ item }}
              register: nic_result
              when: item.startswith("vlan")
              with_items: "{{ ansible_interfaces }}"
            - name: Backup old vlan network-script files
              copy:
                remote_src: True
                src: "{{ item.stat.path }}"
                dest: "{{ item.stat.path }}.bak"
              when: item.item.startswith("vlan") and item.stat.exists
              with_items: "{{ nic_result.results }}"
            - name: Edit PHYSDEV in new network-script files
              replace:
                path: "{{ item.stat.path }}"
                regexp: "^PHYSDEV=eth"
                replace: "PHYSDEV={{ prefix }}"
              when: item.item.startswith("vlan") and item.stat.exists
              with_items: "{{ nic_result.results }}"
    注記

    この Playbook を使用して、アップグレードプロセスの後半でオーバークラウドの NIC の名前を変更します。

  3. アンダークラウドで playbook-nics.yaml Playbook を実行します。

    $ ansible-playbook -c local -i localhost, playbook-nics.yaml

    この Playbook により、新しい NIC の接頭辞が em に設定されます。別の NIC 接頭辞を設定するには、Playbook の実行時に prefix 変数を設定します。

    $ ansible-playbook -c local -i localhost, -e prefix="mynic" ~/playbook-nics.yaml

    NIC の変更は、Leapp によるアップグレードプロセスが完了し、ノードがリブートされた後にのみ適用されます。

4.4. アンダークラウドでの SSH root 権限パラメーターの設定

Leapp によるアップグレードでは、PermitRootLogin パラメーターが /etc/ssh/sshd_config ファイルに存在するかどうかを確認します。このパラメーターを、明示的に yes または no のいずれかに設定する必要があります。

セキュリティー上の理由から、アンダークラウドで root ユーザーへの SSH アクセスを無効にするには、このパラメーターを no に設定します。

手順

  1. アンダークラウドに stack ユーザーとしてログインします。
  2. /etc/ssh/sshd_config ファイルに PermitRootLogin パラメーターがあるかどうかを確認します。

    $ sudo grep PermitRootLogin /etc/ssh/sshd_config
  3. /etc/ssh/sshd_config ファイルにパラメーターがない場合は、ファイルを編集して PermitRootLogin パラメーターを設定します。

    PermitRootLogin no
  4. ファイルを保存します。

4.5. 次世代電源管理ドライバーへの移行

Red Hat OpenStack Platform では ハードウェアタイプ とも呼ばれる次世代ドライバーが使用され、従来のドライバーがこれに置き換えられています。

従来のドライバーとそれと等価な次世代ハードウェアタイプの対比を、以下の表に示します。

従来のドライバー新しいハードウェアタイプ

pxe_ipmitool

ipmi

pxe_drac

idrac

pxe_ilo

ilo

pxe_irmc

irmc

VBMC (pxe_ipmitool)

ipmi

fake_pxe

fake-hardware

OpenStack Platform 15 では、これらの従来ドライバーは削除され、使用できなくなっています。OpenStack Platform 15 に アップグレードする前に ハードウェアタイプに変更する必要があります。

手順

  1. 有効なハードウェアタイプの最新の一覧を確認します。

    $ source ~/stackrc
    $ openstack baremetal driver list --type dynamic
  2. 有効ではないハードウェアタイプのドライバーを使用する場合には、undercloud.conf ファイルの enabled_hardware_types パラメーターを使用してそのドライバーを有効にします。

    enabled_hardware_types = ipmi,redfish,idrac
  3. ファイルを保存し、アンダークラウドをリフレッシュします。

    $ openstack undercloud install
  4. 以下のコマンドを実行します。OLDDRIVER および NEWDRIVER 変数を、実際の電源管理タイプに置き換えてください。

    $ source ~/stackrc
    $ OLDDRIVER="pxe_ipmitool"
    $ NEWDRIVER="ipmi"
    $ for NODE in $(openstack baremetal node list --driver $OLDDRIVER -c UUID -f value) ; do openstack baremetal node set $NODE --driver $NEWDRIVER; done

第5章 アンダークラウドのオペレーティングシステムのアップグレード

director をアップグレードする前に、アンダークラウドのオペレーティングシステムを Red Hat Enterprise Linux 7 から Red Hat Enterprise Linux 8 にアップグレードする必要があります。このオペレーティングシステムのアップグレードの一環として、Red Hat OpenStack Platform 13 のパッケージを削除し、続いて Leapp ユーティリティーを実行してシステムパッケージをアップグレードする必要があります。このパッケージの削除およびオペレーティングシステムのアップグレードは、アンダークラウドのデータベースには影響を及ぼしません。オペレーティングシステムのアップグレードが完了したら、Red Hat OpenStack Platform 16.2 バージョンの director パッケージを再インストールします。

5.1. Red Hat OpenStack Platform director パッケージの削除

Leapp ユーティリティーを実行する前に、Red Hat Enterprise Linux 7 に関連付けられた Red Hat OpenStack Platform 13 パッケージを削除します。これらのパッケージ名には、リリースに関する接尾辞 el7ost が使用されます。一部の el7ost は、subscription-manager および Leapp ユーティリティーの依存関係としてシステム上に残ります。

手順

  1. アンダークラウドに stack ユーザーとしてログインします。
  2. アンダークラウド上の主要 OpenStack サービスを無効にします。

    $ sudo systemctl stop 'openstack-*' httpd haproxy mariadb 'rabbitmq*' docker xinetd
  3. OpenvSwitch およびアップグレードに必要な特定の Python 2 パッケージは除き、アンダークラウドから主要 OpenStack サービスを削除します。

    $ sudo yum -y remove '*el7ost*' 'galera*' 'haproxy*' \
        httpd 'mysql*' 'pacemaker*' xinetd python-jsonpointer \
        qemu-kvm-common-rhev qemu-img-rhev 'rabbit*' \
        'redis*' \
        -- \
        -'*openvswitch*' -python-docker -python-PyMySQL \
        -python-pysocks -python2-asn1crypto -python2-babel \
        -python2-cffi -python2-cryptography -python2-dateutil \
        -python2-idna -python2-ipaddress -python2-jinja2 \
        -python2-jsonpatch -python2-markupsafe -python2-pyOpenSSL \
        -python2-requests -python2-six -python2-urllib3 \
        -python-httplib2 -python-passlib -python2-netaddr -ceph-ansible
  4. /etc/httpd および /var/lib/docker ディレクトリーからコンテンツを削除します。

    $ sudo rm -rf /etc/httpd /var/lib/docker

5.2. アンダークラウドでの Leapp アップグレードの実施

Leapp ユーティリティーをインストールして実行し、オペレーティングシステムを Red Hat Enterprise Linux (RHEL) 8 にアップグレードします。

前提条件

手順

  1. アンダークラウドに stack ユーザーとしてログインします。
  2. Leapp ユーティリティーをインストールします。

    $ sudo yum install leapp
  3. ナレッジベースのアーティクルRHEL 7 から RHEL 8 へのインプレースアップグレード時に Leapp ユーティリティーで必要なデータに添付されている追加の必須データファイル (RPM パッケージの変更および RPM リポジトリーマッピング) をダウンロードし、それらのファイルを /etc/leapp/files/ ディレクトリーに置きます。
  4. Red Hat サブスクリプションを更新します。

    • アンダークラウドの登録に Red Hat カスタマーポータルを使用している場合、現在のサブスクリプションをリフレッシュし、Red Hat Enterprise Linux 8.4 コンテンツへのアクセス権限を取得します。

      $ sudo subscription-manager refresh
    • アンダークラウドの登録に Red Hat Satellite Server を使用している場合は、アンダークラウドを Red Hat OpenStack Platform (RHOSP) 16.2 のアクティベーションキーに関連付けられたコンテンツビューに再登録します。

      $ sudo subscription-manager register --force --org ORG --activationkey ACTIVATION_KEY
      注記

      Red Hat OpenStack Platform 16.2 用に作成するコンテンツビューには、Red Hat Enterprise Linux 8.4 のコンテンツが含まれている必要があります。

  5. Red Hat OpenStack Platform 16.2 では、新しいバージョンの Open vSwitch が使用されます。to_remove および to_install トランザクションファイルにより、Open vSwitch のバージョンを置き換えます。

    $ echo 'openvswitch2.11' | sudo tee -a /etc/leapp/transaction/to_remove
    $ echo 'openvswitch2.15' | sudo tee -a /etc/leapp/transaction/to_install
  6. to_keep トランザクションファイルを使用して、アップグレードプロセス中に Red Hat Ceph Storage 3 バージョンの ceph-ansible を維持します。

    $ echo 'ceph-ansible' | sudo tee -a /etc/leapp/transaction/to_keep
  7. RHEL 8 ではサポートされなくなったカーネルモジュールを調整します。

    $ if [ -f /usr/share/leapp-repository/repositories/system_upgrade/el7toel8/actors/kernel/checkkerneldrivers/files/removed_drivers.txt ]; then
        for module in pata_acpi floppy; do
            sudo sed -i "/^${module}$/d" /usr/share/leapp-repository/repositories/system_upgrade/el7toel8/actors/kernel/checkkerneldrivers/files/removed_drivers.txt
        done
    else
        for module in pata_acpi floppy; do
            jq ". | del(.data[] | select(.driver_name == \"${module}\"))" /etc/leapp/files/device_driver_deprecation_data.json > /etc/leapp/files/device_driver_deprecation_data.json_modified
            mv /etc/leapp/files/device_driver_deprecation_data.json_modified /etc/leapp/files/device_driver_deprecation_data.json
        done
    fi
  8. pam_pkcs11 モジュールを削除します。

    $ sudo leapp answer --add --section remove_pam_pkcs11_module_check.confirm=True
  9. (オプション) TLS-Everywhere アーキテクチャーで環境がデプロイされ、システムでの認証を設定するのに非推奨の authconfig ユーティリティーが使用される場合は、authselect ユーティリティーを使用して RHEL 8 システムを設定します。

    $ sudo leapp answer --add --section authselect_check.confirm=True

    Leapp によるアップグレードプロセス時の認証設定の詳細は、『Upgrading from RHEL 7 to RHEL 8』「Known issues」を参照してください。

  10. LEAPP_DEVEL_TARGET_RELEASE および LEAPP_UNSUPPORTED 環境変数を設定して、アップグレードする RHEL 8 マイナーバージョンを指定します。RHOSP 16.2 では、RHEL 8 マイナーバージョンを 8.4 に設定する必要があります。

    $ export LEAPP_UNSUPPORTED=1
    $ export LEAPP_DEVEL_TARGET_RELEASE=8.4

    LEAPP_DEVEL 接頭辞を付けて環境変数を使用する場合は、LEAPP_UNSUPPORTED 環境変数を使用する必要があります。

  11. Leapp プロセスから、永続的なネットワーク名のアクターを削除します。

    注記

    Leapp によるアップグレードプロセスを実行する前にネットワークインターフェース名を変更しない場合、RHEL 8.2 へのアップグレードの完了後にインターフェース名が変わる可能性があります。ネットワークインターフェース名の変更に関する詳細は、「予測可能なアンダークラウドノード NIC 名の使用」を参照してください。

    $ sudo rm -f /usr/share/leapp-repository/repositories/system_upgrade/el7toel8/actors/persistentnetnamesdisable/actor.py
  12. Leapp によるアップグレードプロセスを開始します。

    $ sudo -E leapp upgrade --debug --enablerepo rhel-8-for-x86_64-baseos-eus-rpms --enablerepo rhel-8-for-x86_64-appstream-eus-rpms --enablerepo fast-datapath-for-rhel-8-x86_64-rpms --enablerepo ansible-2.9-for-rhel-8-x86_64-rpms

    --enablerepo オプションを使用して、Leapp によるアップグレードプロセス中に有効にするリポジトリーを設定します。特に新しいバージョンの Open vSwitch を使用する場合は、Red Hat OpenStack Platform 16.2 への移行を円滑に行うために、これらのリポジトリーを追加する必要があります。

  13. leapp upgrade コマンドが正常に完了するのを待ちます。
  14. ルートディレクトリーに空の .autorelabel ファイルを作成します。

    $ sudo touch /.autorelabel

    リブート後、SELinux はこのファイルを検出し、自動的にファイルシステムのラベルを変更します。

  15. アンダークラウドをリブートします。

    $ sudo reboot
  16. DNF の設定で定義されているトランザクションの除外対象から、Leapp のパッケージを削除します。

    $ sudo dnf config-manager --save --setopt exclude=''

第6章 director のアップグレード

アンダークラウドのオペレーティングシステムのアップグレードが完了したら、director をアップグレードします。以前の Red Hat OpenStack Platform 13 のアンダークラウドのデータベースは、オペレーティングシステムのアップグレード後にホスト上に残ります。openstack undercloud upgrade コマンドを実行する前に、新しい Red Hat OpenStack Platform 16.2 パッケージをインストールし、Red Hat OpenStack Platform 16.2 コンテナーイメージの新しいソースを設定します。

6.1. 環境の Red Hat Enterprise Linux リリースへのロック

Red Hat OpenStack Platform 16.2 は Red Hat Enterprise Linux 8.4 でサポートされています。更新を実施する前に、オペレーティングシステムをより新しいマイナーリリースにアップグレードしないように、アンダークラウドのリポジトリーを Red Hat Enterprise Linux 8.4 リリースにロックする必要があります。

手順

  1. アンダークラウドに stack ユーザーとしてログインします。
  2. subscription-manager release コマンドを使用して、アンダークラウドを特定のバージョンにロックします。

    $ sudo subscription-manager release --set=8.4

6.2. アンダークラウド用リポジトリーの有効化

アンダークラウドに必要なリポジトリーを有効にし、システムパッケージを最新バージョンに更新します。

手順

  1. アンダークラウドに stack ユーザーとしてログインします。
  2. デフォルトのリポジトリーをすべて無効にしてから、必要な Red Hat Enterprise Linux リポジトリーを有効にします。

    [stack@director ~]$ sudo subscription-manager repos --disable=*
    [stack@director ~]$ sudo subscription-manager repos \
    --enable=rhel-8-for-x86_64-baseos-eus-rpms \
    --enable=rhel-8-for-x86_64-appstream-eus-rpms \
    --enable=rhel-8-for-x86_64-highavailability-eus-rpms \
    --enable=ansible-2.9-for-rhel-8-x86_64-rpms \
    --enable=openstack-16.2-for-rhel-8-x86_64-rpms \
    --enable=fast-datapath-for-rhel-8-x86_64-rpms

    これらのリポジトリーには、director のインストールに必要なパッケージが含まれます。

  3. container-tools リポジトリーモジュールをバージョン 3.0 に設定します。

    [stack@director ~]$ sudo dnf module disable -y container-tools:rhel8
    [stack@director ~]$ sudo dnf module enable -y container-tools:3.0
  4. オペレーティングシステムを同期し、システムパッケージがオペレーティングシステムのバージョンと一致するようにします。

    [stack@director ~]$ sudo dnf distro-sync -y
    [stack@director ~]$ sudo reboot

6.3. director パッケージのインストール

Red Hat OpenStack Platform director に関連するパッケージをインストールします。

手順

  1. director のインストールと設定を行うためのコマンドラインツールをインストールします。

    [stack@director ~]$ sudo dnf install -y python3-tripleoclient

6.4. コンテナーイメージの準備

アンダークラウドのインストールには、コンテナーイメージの取得先およびその保存方法を定義するための環境ファイルが必要です。この環境ファイルを生成してカスタマイズし、コンテナーイメージの準備に使用します。

注記

アンダークラウド用に特定のコンテナーイメージバージョンを設定する必要がある場合は、イメージを特定のバージョンに固定する必要があります。詳しい情報は、「アンダークラウド用コンテナーイメージの固定」を参照してください。

手順

  1. アンダークラウドホストに stack ユーザーとしてログインします。
  2. デフォルトのコンテナーイメージ準備ファイルを生成します。

    $ sudo openstack tripleo container image prepare default \
      --local-push-destination \
      --output-env-file containers-prepare-parameter.yaml

    上記のコマンドでは、以下の追加オプションを使用しています。

    • --local-push-destination: コンテナーイメージの保管場所として、アンダークラウド上のレジストリーを設定します。つまり、director は必要なイメージを Red Hat Container Catalog からプルし、それをアンダークラウド上のレジストリーにプッシュします。director はこのレジストリーをコンテナーイメージのソースとして使用します。Red Hat Container Catalog から直接プルする場合には、このオプションを省略します。
    • --output-env-file: 環境ファイルの名前です。このファイルには、コンテナーイメージを準備するためのパラメーターが含まれます。ここでは、ファイル名は containers-prepare-parameter.yaml です。

      注記

      アンダークラウドとオーバークラウド両方のコンテナーイメージのソースを定義するのに、同じ containers-prepare-parameter.yaml ファイルを使用することができます。

  3. 要件に合わせて containers-prepare-parameter.yaml を変更します。

6.5. コンテナーイメージ準備のパラメーター

コンテナー準備用のデフォルトファイル (containers-prepare-parameter.yaml) には、ContainerImagePrepare heat パラメーターが含まれます。このパラメーターで、イメージのセットを準備するためのさまざまな設定を定義します。

parameter_defaults:
  ContainerImagePrepare:
  - (strategy one)
  - (strategy two)
  - (strategy three)
  ...

それぞれの設定では、サブパラメーターのセットにより使用するイメージやイメージの使用方法を定義することができます。以下の表には、ContainerImagePrepare ストラテジーの各設定で使用することのできるサブパラメーターの情報をまとめています。

パラメーター説明

excludes

設定からイメージ名を除外する正規表現の一覧

includes

設定に含める正規表現の一覧。少なくとも 1 つのイメージ名が既存のイメージと一致している必要があります。includes パラメーターを指定すると、excludes の設定はすべて無視されます。

modify_append_tag

対象となるイメージのタグに追加する文字列。たとえば、16.2.3-5.161 のタグが付けられたイメージをプルし、modify_append_tag-hotfix に設定すると、director は最終イメージを 16.2.3-5.161-hotfix とタグ付けします。

modify_only_with_labels

変更するイメージを絞り込むイメージラベルのディクショナリー。イメージが定義したラベルと一致する場合には、director はそのイメージを変更プロセスに含めます。

modify_role

イメージのアップロード中 (ただし目的のレジストリーにプッシュする前) に実行する Ansible ロール名の文字列

modify_vars

modify_role に渡す変数のディクショナリー

push_destination

アップロードプロセス中にイメージをプッシュするレジストリーの名前空間を定義します。

  • true に設定すると、push_destination はホスト名を使用してアンダークラウドレジストリーの名前空間に設定されます。これが推奨される方法です。
  • false に設定すると、ローカルレジストリーへのプッシュは実行されず、ノードはソースから直接イメージをプルします。
  • カスタムの値に設定すると、director はイメージを外部のローカルレジストリーにプッシュします。

実稼働環境でこのパラメーターを false に設定した場合、イメージを Red Hat Container Catalog から直接プルする際に、すべてのオーバークラウドノードが同時に外部接続を通じて Red Hat Container Catalog からイメージをプルするため、帯域幅の問題が発生する可能性があります。コンテナーイメージをホストする Red Hat Satellite Server から直接プルする場合にのみ、false を使用します。

push_destination パラメーターが false に設定されているか、または定義されておらずリモートレジストリーで認証が必要な場合は、ContainerImageRegistryLogin パラメーターを true に設定し、ContainerImageRegistryCredentials パラメーターで認証情報を追加します。

pull_source

元のコンテナーイメージをプルするソースレジストリー

set

初期イメージの取得場所を定義する、キー:値 定義のディクショナリー

tag_from_label

指定したコンテナーイメージのメタデータラベルの値を使用して、すべてのイメージのタグを作成し、そのタグが付けられたイメージをプルします。たとえば、tag_from_label: {version}-{release} を設定すると、director は version および release ラベルを使用して新しいタグを作成します。あるコンテナーについて、version を 16.2.3 に設定し、release5.161 に設定した場合、タグは 16.2.3-5.161 となります。set ディクショナリーで tag を定義していない場合に限り、director はこのパラメーターを使用します。

重要

イメージをアンダークラウドにプッシュする場合は、push_destination: UNDERCLOUD_IP:PORT の代わりに push_destination: true を使用します。push_destination: true 手法を使用することで、IPv4 アドレスおよび IPv6 アドレスの両方で一貫性が確保されます。

set パラメーターには、複数の キー:値 定義を設定することができます。

キー説明

ceph_image

Ceph Storage コンテナーイメージの名前

ceph_namespace

Ceph Storage コンテナーイメージの名前空間

ceph_tag

Ceph Storage コンテナーイメージのタグ

ceph_alertmanager_image

ceph_alertmanager_namespace

ceph_alertmanager_tag

Ceph Storage Alert Manager コンテナーイメージの名前、namespace、およびタグ。

ceph_grafana_image

ceph_grafana_namespace

ceph_grafana_tag

Ceph Storage Grafana コンテナーイメージの名前、namespace、およびタグ。

ceph_node_exporter_image

ceph_node_exporter_namespace

ceph_node_exporter_tag

Ceph Storage Node Exporter コンテナーイメージの名前、namespace、およびタグ。

ceph_prometheus_image

ceph_prometheus_namespace

ceph_prometheus_tag

Ceph Storage Prometheus コンテナーイメージの名前、namespace、およびタグ。

name_prefix

各 OpenStack サービスイメージの接頭辞

name_suffix

各 OpenStack サービスイメージの接尾辞

namespace

各 OpenStack サービスイメージの名前空間

neutron_driver

使用する OpenStack Networking (neutron) コンテナーを定義するのに使用するドライバー。標準の neutron-server コンテナーに設定するには、null 値を使用します。OVN ベースのコンテナーを使用するには、ovn に設定します。

tag

ソースからの全イメージに特定のタグを設定します。定義されていない場合は、director は Red Hat OpenStack Platform のバージョン番号をデフォルト値として使用します。このパラメーターは、tag_from_label の値よりも優先されます。

注記

コンテナーイメージでは、Red Hat OpenStack Platform のバージョンに基づいたマルチストリームタグが使用されます。したがって、今後 latest タグは使用されません。

6.6. コンテナーイメージタグ付けのガイドライン

Red Hat コンテナーレジストリーでは、すべての Red Hat OpenStack Platform コンテナーイメージをタグ付けするのに、特定のバージョン形式が使用されます。この形式は、version-release のように各コンテナーのラベルのメタデータに従います。

version
Red Hat OpenStack Platform のメジャーおよびマイナーバージョンに対応します。これらのバージョンは、1 つまたは複数のリリースが含まれるストリームとして機能します。
release
バージョンストリーム内の、特定コンテナーイメージバージョンのリリースに対応します。

たとえば、Red Hat OpenStack Platform の最新バージョンが 16.2.3 で、コンテナーイメージのリリースが 5.161 の場合、コンテナーイメージのタグは 16.2.3-5.161 となります。

Red Hat コンテナーレジストリーでは、コンテナーイメージバージョンの最新リリースとリンクするメジャーおよびマイナー version タグのセットも使用されます。たとえば、16.2 と 16.2.3 の両方が、16.2.3 コンテナーストリームの最新 release とリンクします。16.2 の新規マイナーリリースが公開されると、16.2 タグは新規マイナーリリースストリームの最新 release とリンクします。一方、16.2.3 タグは、引き続き 16.2.3 ストリーム内の最新 release とリンクします。

ContainerImagePrepare パラメーターには 2 つのサブパラメーターが含まれ、これを使用してダウンロードするコンテナーイメージを定義することができます。これらのサブパラメーターは、set ディクショナリー内の tag パラメーターおよび tag_from_label パラメーターです。以下のガイドラインを使用して、tag または tag_from_label のどちらを使用するかを判断してください。

  • tag のデフォルト値は、お使いの OpenStack Platform のメジャーバージョンです。本バージョンでは、16.2 です。これは常に最新のマイナーバージョンおよびリリースに対応します。

    parameter_defaults:
      ContainerImagePrepare:
      - set:
          ...
          tag: 16.2
          ...
  • OpenStack Platform コンテナーイメージの特定マイナーバージョンに変更するには、タグをマイナーバージョンに設定します。たとえば、16.2.2 に変更するには、tag を 16.2.2 に設定します。

    parameter_defaults:
      ContainerImagePrepare:
      - set:
          ...
          tag: 16.2.2
          ...
  • tag を設定すると、インストールおよび更新時に、director は必ず tag で設定したバージョンの最新のコンテナーイメージ release をダウンロードします。
  • tag を設定しないと、director は最新のメジャーバージョンと共に tag_from_label の値を使用します。

    parameter_defaults:
      ContainerImagePrepare:
      - set:
          ...
          # tag: 16.2
          ...
        tag_from_label: '{version}-{release}'
  • tag_from_label パラメーターは、Red Hat コンテナーレジストリーから検査する最新コンテナーイメージリリースのラベルメタデータからタグを生成します。たとえば、特定のコンテナーのラベルは、以下の version および release メタデータを使用します。

      "Labels": {
        "release": "5.161",
        "version": "16.2.3",
        ...
      }
  • tag_from_label のデフォルト値は {version}-{release} です。これは、各コンテナーイメージのバージョンおよびリリースのメタデータラベルに対応します。たとえば、コンテナーイメージの version に 16.2.3 が、release に 5.161 が、それぞれ設定されている場合、コンテナーイメージのタグは 16.2.3-5.161 となります。
  • tag パラメーターは、常に tag_from_label パラメーターよりも優先されます。tag_from_label を使用するには、コンテナー準備の設定で tag パラメーターを省略します。
  • tag および tag_from_label の主な相違点は、次のとおりです。director が tag を使用してイメージをプルする場合は、Red Hat コンテナーレジストリーがバージョンストリーム内の最新イメージリリースとリンクするメジャーまたはマイナーバージョンのタグだけに基づきます。一方、tag_from_label を使用する場合は、director がタグを生成して対応するイメージをプルできるように、各コンテナーイメージのメタデータの検査を行います。

6.7. プライベートレジストリーからのコンテナーイメージの取得

registry.redhat.io レジストリーにアクセスしてイメージをプルするには、認証が必要です。registry.redhat.io およびその他のプライベートレジストリーで認証するには、containers-prepare-parameter.yaml ファイルに ContainerImageRegistryCredentials および ContainerImageRegistryLogin パラメーターを含めます。

ContainerImageRegistryCredentials

一部のコンテナーイメージレジストリーでは、イメージにアクセスするのに認証が必要です。そのような場合には、containers-prepare-parameter.yaml 環境ファイルの ContainerImageRegistryCredentials パラメーターを使用します。ContainerImageRegistryCredentials パラメーターは、プライベートレジストリーの URL に基づくキーのセットを使用します。それぞれのプライベートレジストリーの URL は、独自のキーと値のペアを使用して、ユーザー名 (キー) およびパスワード (値) を定義します。これにより、複数のプライベートレジストリーに対して認証情報を指定することができます。

parameter_defaults:
  ContainerImagePrepare:
  - push_destination: true
    set:
      namespace: registry.redhat.io/...
      ...
  ContainerImageRegistryCredentials:
    registry.redhat.io:
      my_username: my_password

上記の例の my_username および my_password を、実際の認証情報に置き換えてください。Red Hat では、個人のユーザー認証情報を使用する代わりに、レジストリーサービスアカウントを作成し、それらの認証情報を使用して registry.redhat.io コンテンツにアクセスすることを推奨します。

複数のレジストリーの認証情報を指定するには、ContainerImageRegistryCredentials でレジストリーごとに複数のキー/ペアの値を設定します。

parameter_defaults:
  ContainerImagePrepare:
  - push_destination: true
    set:
      namespace: registry.redhat.io/...
      ...
  - push_destination: true
    set:
      namespace: registry.internalsite.com/...
      ...
  ...
  ContainerImageRegistryCredentials:
    registry.redhat.io:
      myuser: 'p@55w0rd!'
    registry.internalsite.com:
      myuser2: '0th3rp@55w0rd!'
    '192.0.2.1:8787':
      myuser3: '@n0th3rp@55w0rd!'
重要

デフォルトの ContainerImagePrepare パラメーターは、認証が必要な registry.redhat.io からコンテナーイメージをプルします。

詳細は、「Red Hat コンテナーレジストリーの認証」を参照してください。

ContainerImageRegistryLogin

ContainerImageRegistryLogin パラメーターを使用して、コンテナーイメージを取得するために、オーバークラウドノードシステムがリモートレジストリーにログインする必要があるかどうかを制御します。このような状況は、アンダークラウドを使用してイメージをホストする代わりに、オーバークラウドノードがイメージを直接プルする場合に発生します。

特定の設定について、push_destination が false に設定されている、または使用されていない場合は、ContainerImageRegistryLogintrue に設定する必要があります。

parameter_defaults:
  ContainerImagePrepare:
  - push_destination: false
    set:
      namespace: registry.redhat.io/...
      ...
  ...
  ContainerImageRegistryCredentials:
    registry.redhat.io:
      myuser: 'p@55w0rd!'
  ContainerImageRegistryLogin: true

ただし、オーバークラウドノードに ContainerImageRegistryCredentials で定義されたレジストリーホストへのネットワーク接続がなく、ContainerImageRegistryLogintrue に設定すると、ログインを試みる際にデプロイメントが失敗する可能性があります。オーバークラウドノードに ContainerImageRegistryCredentials で定義されたレジストリーホストへのネットワーク接続がない場合、push_destinationtrue に、ContainerImageRegistryLoginfalse に設定して、オーバークラウドノードがアンダークラウドからイメージをプルできるようにします。

parameter_defaults:
  ContainerImagePrepare:
  - push_destination: true
    set:
      namespace: registry.redhat.io/...
      ...
  ...
  ContainerImageRegistryCredentials:
    registry.redhat.io:
      myuser: 'p@55w0rd!'
  ContainerImageRegistryLogin: false

6.8. アップグレード用の移行コンテナーの取得

アップグレードには、以前のバージョンの Red Hat OpenStack Platform および Red Hat Ceph Storage のコンテナーが必要です。これらのコンテナーは、Red Hat OpenStack Platform 16.2 への移行に役立ちます。

手順

  1. アンダークラウドホストに stack ユーザーとしてログインします。
  2. containers-prepare-parameter.yaml ファイルを編集します。
  3. 遷移コンテナーパラメーターを ContainerImagePrepare パラメーターに 設定します。デプロイメントの種別に応じて、以下のいずれかの方法でパラメーターを設定します。

    • director を使用してデプロイされた Red Hat Ceph Storage クラスターがデプロイメントで使用される場合は、以下のパラメーターを追加します。

      parameter_defaults:
        ContainerImagePrepare:
        - push_destination: true
          set:
            ...
            name_prefix_stein: openstack-
            name_suffix_stein: ''
            namespace_stein: registry.redhat.io/rhosp15-rhel8
            tag_stein: 15.0
            ceph3_namespace: registry.redhat.io/rhceph
            ceph3_tag: latest
            ceph3_image: rhceph-3-rhel7
            ...
      • *_stein パラメーターで定義する Red Hat OpenStack Platform 15 用のコンテナーイメージが、アップグレードプロセスでデータベースの移行に使用されます。
      • ceph3_* パラメーターは、オーバークラウドが使用する現在の Red Hat Ceph Storage コンテナーイメージを定義します。Red Hat Ceph Storage 3 から 4 への移行には、オーバークラウドに ceph3_* および ceph_* 両方のパラメーターが必要です。
      • コンテナーイメージのストレージに Red Hat Satellite Server を使用している場合は、名前空間をご自分の Red Hat Satellite Server 上のイメージの場所に設定します。
    • 外部の Ceph Storage クラスターがデプロイメントで使用される場合は、以下のパラメーターを追加します。

      parameter_defaults:
        ContainerImagePrepare:
        - push_destination: true
          set:
            ...
            name_prefix_stein: openstack-
            name_suffix_stein: ''
            namespace_stein: registry.redhat.io/rhosp15-rhel8
            tag_stein: 15.0
            ceph_namespace: registry.redhat.io/rhceph
            ceph_tag: latest
            ceph_image: rhceph-4-rhel8
            ...
      • *_stein パラメーターで定義する Red Hat OpenStack Platform 15 用のコンテナーイメージが、アップグレードプロセスでデータベースの移行に使用されます。
      • ceph_* パラメーターは、オーバークラウドが使用する現在の Red Hat Ceph Storage 4 コンテナーイメージを定義します。
      • コンテナーイメージのストレージに Red Hat Satellite Server を使用している場合は、名前空間をご自分の Red Hat Satellite Server 上のイメージの場所に設定します。
  4. neutron_driver パラメーターを openvswitch に変更します。

    parameter_defaults:
      ContainerImagePrepare:
      - push_destination: true
        set:
          ...
          neutron_driver: openvswitch
          ...

    アップグレードプロセスの全期間中、Open vSwitch との互換性が維持されます。Red Hat OpenStack Platform 16.2 へのアップグレードが完了したら、オーバークラウドを Open vSwitch から Open Virtual Network (OVN) に移行します。

  5. containers-prepare-parameter.yaml ファイルを保存します。

6.9. undercloud.conf ファイルの更新

引き続き Red Hat OpenStack Platform 13 環境からの元の undercloud.conf ファイルを使用できますが、Red Hat OpenStack Platform 16.2 との互換性を維持するために、ファイルを変更する必要があります。

手順

  1. アンダークラウドホストに stack ユーザーとしてログインします。
  2. undercloud.conf ファイルを編集します。
  3. ファイル内の DEFAULT セクションに、以下のパラメーターを追加します。

    container_images_file = /home/stack/containers-prepare-parameter.yaml

    director が正しい場所からアンダークラウドのコンテナーイメージをプルできるように、このパラメーターで containers-prepare-parameter.yaml 環境ファイルの場所を定義します。

  4. generate_service_certificate パラメーターを確認します。このパラメーターのデフォルト設定は、false から true に変更されます。これにより、アップグレード中にアンダークラウドで SSL/TLS が有効になります。
  5. 予測可能な NIC 命名規則に移行している場合は、local_interface パラメーターを確認してください。
  6. Red Hat OpenStack Platform 13 で masquerade_network パラメーターを設定した場合には、このパラメーターを削除して、サブネットごとに masquerade = true を設定します。
  7. ファイル内の他のすべてのパラメータが変更されていないか確認します。
  8. ファイルを保存します。

6.10. director の設定パラメーター

以下の一覧で、undercloud.conf ファイルを設定するパラメーターについて説明します。エラーを避けるために、パラメーターは決して該当するセクションから削除しないでください。

重要

少なくとも、コンテナーイメージの設定が含まれる環境ファイルに container_images_file パラメーターを設定する必要があります。このパラメーターに適切なファイルを正しく設定しないと、director は ContainerImagePrepare パラメーターからコンテナーイメージのルールセットを取得することや、ContainerImageRegistryCredentials パラメーターからコンテナーレジストリーの認証情報を取得することができなくなります。

デフォルト

undercloud.conf ファイルの [DEFAULT] セクションで定義されているパラメーターを以下に示します。

additional_architectures

オーバークラウドがサポートする追加の (カーネル) アーキテクチャーの一覧。現在、オーバークラウドはデフォルトの x86_ 64 アーキテクチャーに加えて ppc64le アーキテクチャーをサポートしています。

注記

ppc64le のサポートを有効にする場合には、ipxe_enabledFalse に設定する必要もあります。複数 の CPU アーキテクチャーを使用したアンダークラウドの設定に関する詳細は、「複数の CPU アーキテクチャーオーバークラウドの 設定」を参照してください。

certificate_generation_ca
要求した証明書に署名する CA の certmonger のニックネーム。generate_service_certificate パラメーターを設定した場合に限り、このオプションを使用します。local CA を選択する場合は、certmonger はローカルの CA 証明書を /etc/pki/ca-trust/source/anchors/cm-local-ca.pem に抽出し、証明書をトラストチェーンに追加します。
clean_nodes
デプロイメントを再実行する前とイントロスペクションの後にハードドライブを消去するかどうかを定義します。
cleanup
一時ファイルをクリーンナップします。デプロイメントコマンドの実行後もデプロイメント時に使用した一時ファイルをそのまま残すには、このパラメーターを False に設定します。ファイルを残すと、生成されたファイルのデバッグを行う場合やエラーが発生した場合に役に立ちます。
container_cli
コンテナー管理用の CLI ツール。このパラメーターは、podman に設定したままにしてください。Red Hat Enterprise Linux 8.4 がサポートするのは、podman だけです。
container_healthcheck_disabled
コンテナー化されたサービスのヘルスチェックを無効にします。Red Hat は、ヘルスチェックを有効にし、このオプションを false に設定したままにすることを推奨します。
container_images_file

コンテナーイメージ情報が含まれる heat 環境ファイル。このファイルには、以下のエントリーを含めることができます。

  • 必要なすべてのコンテナーイメージのパラメーター
  • 必要なイメージの準備を実施する ContainerImagePrepare パラメーター。このパラメーターが含まれるファイルの名前は、通常 containers-prepare-parameter.yaml です。
container_insecure_registries
podman が使用するセキュアではないレジストリーの一覧。プライベートコンテナーレジストリー等の別のソースからイメージをプルする場合には、このパラメーターを使用します。多くの場合、podman は Red Hat Container Catalog または Satellite サーバー (アンダークラウドが Satellite に登録されている場合) のいずれかからコンテナーイメージをプルするための証明書を持ちます。
container_registry_mirror
設定により podman が使用するオプションの registry-mirror
custom_env_files
アンダークラウドのインストールに追加する新たな環境ファイル
deployment_user
アンダークラウドをインストールするユーザー。現在のデフォルトユーザー stack を使用する場合には、このパラメーターを未設定のままにします。
discovery_default_driver
自動的に登録されたノードのデフォルトドライバーを設定します。enable_node_discovery パラメーターを有効にし、enabled_hardware_types の一覧にドライバーを含める必要があります。
enable_ironic、enable_ironic_inspector、enable_mistral、enable_nova、enable_tempest、enable_validations、enable_zaqar
director で有効にするコアサービスを定義します。これらのパラメーターは true に設定されたままにします。
enable_node_discovery
introspection ramdisk を PXE ブートする不明なノードを自動的に登録します。新規ノードは、fake ドライバーをデフォルトとして使用しますが、discovery_default_driver を設定して上書きすることもできます。また、イントロスペクションルールを使用して、新しく登録したノードにドライバーの情報を指定することもできます。
enable_novajoin
アンダークラウドに novajoin メタデータサービスをインストールするかどうかを定義します。
enable_routed_networks
ルーティングされたコントロールプレーンネットワークのサポートを有効にするかどうかを定義します。
enable_swift_encryption
保存データの Swift 暗号化を有効にするかどうかを定義します。
enable_telemetry
アンダークラウドに OpenStack Telemetry サービス (gnocchi、aodh、panko) をインストールするかどうかを定義します。Telemetry サービスを自動的にインストール/設定するには、enable_telemetry パラメーターを true に設定します。デフォルト値は false で、アンダークラウド上の telemetry が無効になります。このパラメーターは、メトリックデータを消費する Red Hat CloudForms などの他の製品を使用する場合に必要です。
警告

RBAC はすべてのコンポーネントによってサポートされません。Alarming サービス(aodh)および Gnocchi はセキュアな RBAC ルールを考慮しません。

enabled_hardware_types
アンダークラウドで有効にするハードウェアタイプの一覧
generate_service_certificate
アンダークラウドのインストール時に SSL/TLS 証明書を生成するかどうかを定義します。これは undercloud_service_certificate パラメーターに使用します。アンダークラウドのインストールで、作成された証明書 /etc/pki/tls/certs/undercloud-[undercloud_public_vip].pem を保存します。certificate_generation_ca パラメーターで定義される CA はこの証明書に署名します。
heat_container_image
使用する heat コンテナーイメージの URL。未設定のままにします。
heat_native
heat-all を使用してホストベースのアンダークラウド設定を実行します。true のままにします。
hieradata_override
director に Puppet hieradata を設定するための hieradata オーバーライドファイルへのパス。これにより、サービスに対して undercloud.conf パラメーター以外のカスタム設定を行うことができます。設定すると、アンダークラウドのインストールでこのファイルが /etc/puppet/hieradata ディレクトリーにコピーされ、階層の最初のファイルに設定されます。この機能の使用についての詳細は、「アンダークラウドへの hieradata の設定」を参照してください。
inspection_extras
イントロスペクション時に追加のハードウェアコレクションを有効化するかどうかを定義します。このパラメーターを使用するには、イントロスペクションイメージに python-hardware または python-hardware-detect パッケージが必要です。
inspection_interface
ノードのイントロスペクションに director が使用するブリッジ。これは、director の設定により作成されるカスタムのブリッジです。LOCAL_INTERFACE でこのブリッジをアタッチします。これは、デフォルトの br-ctlplane のままにします。
inspection_runbench
ノードイントロスペクション時に一連のベンチマークを実行します。ベンチマークを有効にするには、このパラメーターを true に設定します。このオプションは、登録ノードのハードウェアを検査する際にベンチマーク分析を実行する場合に必要です。
ipa_otp
IPA サーバーにアンダークラウドノードを登録するためのワンタイムパスワードを定義します。これは、enable_novajoin が有効な場合に必要です。
ipv6_address_mode

アンダークラウドのプロビジョニングネットワーク用の IPv6 アドレス設定モード。このパラメーターに設定できる値の一覧を以下に示します。

  • dhcpv6-stateless: ルーター広告 (RA) を使用するアドレス設定と DHCPv6 を使用するオプションの情報
  • dhcpv6-stateful: DHCPv6 を使用するアドレス設定とオプションの情報
ipxe_enabled
iPXE か標準の PXE のいずれを使用するか定義します。デフォルトは true で iPXE を有効化します。標準の PXE を使用するには、このパラメーターを false に設定します。PowerPC デプロイメント、またはハイブリッド PowerPC および x86 デプロイメントの場合は、この値を false に設定します。
local_interface

director のプロビジョニング NIC 用に選択するインターフェース。director は、DHCP および PXE ブートサービスにもこのデバイスを使用します。この値を選択したデバイスに変更します。接続されているデバイスを確認するには、ip addr コマンドを使用します。ip addr コマンドの出力結果の例を、以下に示します。

2: em0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 52:54:00:75:24:09 brd ff:ff:ff:ff:ff:ff
    inet 192.168.122.178/24 brd 192.168.122.255 scope global dynamic em0
       valid_lft 3462sec preferred_lft 3462sec
    inet6 fe80::5054:ff:fe75:2409/64 scope link
       valid_lft forever preferred_lft forever
3: em1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noop state DOWN
    link/ether 42:0b:c2:a5:c1:26 brd ff:ff:ff:ff:ff:ff

この例では、外部 NIC は em0 を使用し、プロビジョニング NIC は、現在設定されていない em1 を使用します。この場合は、local_interfaceem1 に設定します。この設定スクリプトにより、このインターフェースが inspection_interface パラメーターで定義したカスタムのブリッジにアタッチされます。

local_ip

director のプロビジョニング NIC 用に定義する IP アドレス。director は、DHCP および PXE ブートサービスにもこの IP アドレスを使用します。この IP アドレスが環境内の既存の IP アドレスまたはサブネットと競合するなどの理由により、プロビジョニングネットワークに別のサブネットを使用する場合以外は、この値をデフォルトの 192.168.24.1/24 のままにします。

IPv6 の場合、ステートフル接続とステートレス接続の両方をサポートするには、ローカル IP アドレス接頭辞の長さが /64 である必要があります。

local_mtu
local_interface に使用する最大伝送単位 (MTU)。アンダークラウドでは 1500 以下にします。
local_subnet
PXE ブートと DHCP インターフェースに使用するローカルサブネット。local_ip アドレスがこのサブネットに含まれている必要があります。デフォルトは ctlplane-subnet です。
net_config_override
ネットワーク設定のオーバーライドテンプレートへのパス。このパラメーターを設定すると、アンダークラウドは JSON または YAML 形式のテンプレートを使用して、os-net-config でネットワークを設定し、undercloud.conf で設定されたネットワークパラメーターを無視します。ボンディングを設定する場合、またはインターフェースにオプションを追加する場合に、このパラメーターを使用します。アンダークラウドネットワークインターフェースのカスタマイズに関する詳しい情報は、『Director Installation and Usage』の「 Configuring undercloud network interfaces 」を参照してください。
networks_file
heat をオーバーライドするネットワークファイル
output_dir
状態、処理された heat テンプレート、および Ansible デプロイメントファイルを出力するディレクトリー
overcloud_domain_name

オーバークラウドをデプロイする際に使用する DNS ドメイン名

注記

オーバークラウドを設定する際に、CloudDomain にこのパラメーターと同じ値を設定する必要があります。オーバークラウドを設定する際に、環境ファイルでこのパラメーターを設定します。

roles_file
アンダークラウドのインストールで、デフォルトロールファイルを上書きするのに使用するロールファイル。director のインストールにデフォルトのロールファイルが使用されるように、このパラメーターは未設定のままにすることを強く推奨します。
scheduler_max_attempts
スケジューラーがインスタンスのデプロイを試行する最大回数。スケジューリング時に競合状態にならないように、この値を 1 度にデプロイする予定のベアメタルノードの数以上に指定する必要があります。
service_principal
この証明書を使用するサービスの Kerberos プリンシパル。FreeIPA など CA で Kerberos プリンシパルが必要な場合に限り、このパラメーターを使用します。
subnets
プロビジョニングおよびイントロスペクション用のルーティングネットワークのサブネットの一覧。デフォルト値に含まれるのは、ctlplane-subnet サブネットのみです。詳細は、サブネット を参照してください。
templates
上書きする heat テンプレートファイル
undercloud_admin_host

SSL/TLS 経由の director の管理 API エンドポイントに定義する IP アドレスまたはホスト名。director の設定により、IP アドレスは /32 ネットマスクを使用するルーティングされた IP アドレスとして director のソフトウェアブリッジに接続されます。

undercloud_admin_hostlocal_ip と同じ IP ネットワークにない場合は、ControlVirtualInterface パラメーターをアンダークラウドの管理 API がリッスンするインターフェースに設定する必要があります。デフォルトでは、admin API は br-ctlplane インターフェースをリッスンします。カスタム環境ファイルに ControlVirtualInterface パラメーターを設定して、custom_env_files パラメーターを設定してカスタム環境ファイルを undercloud.conf ファイルに追加します。

アンダークラウドネットワークインターフェースのカスタマイズに関する詳しい情報は、「アンダー クラウドネットワークインターフェースの設定」を参照して ください。

undercloud_debug
アンダークラウドサービスのログレベルを DEBUG に設定します。DEBUG ログレベルを有効にするには、この値を true に設定します。
undercloud_enable_selinux
デプロイメント時に、SELinux を有効または無効にします。問題をデバッグする場合以外は、この値を true に設定したままにすることを強く推奨します。
undercloud_hostname
アンダークラウドの完全修飾ホスト名を定義します。設定すると、アンダークラウドのインストールで全システムのホスト名が設定されます。未設定のままにすると、アンダークラウドは現在のホスト名を使用しますが、システムのホスト名設定をすべて適切に定義する必要があります。
undercloud_log_file
アンダークラウドのインストールログおよびアップグレードログを保管するログファイルへのパス。デフォルトでは、ログファイルはホームディレクトリー内の install-undercloud.log です。たとえば、/home/stack/install-undercloud.log のようになります。
undercloud_nameservers
アンダークラウドのホスト名解決に使用する DNS ネームサーバーの一覧
undercloud_ntp_servers
アンダークラウドの日付と時刻を同期できるようにする Network Time Protocol サーバーの一覧
undercloud_public_host

SSL/TLS 経由の director のパブリック API エンドポイントに定義する IP アドレスまたはホスト名。director の設定により、IP アドレスは /32 ネットマスクを使用するルーティングされた IP アドレスとして director のソフトウェアブリッジに接続されます。

undercloud_public_hostlocal_ip と同じ IP ネットワークにない場合は、PublicVirtualInterface パラメーターをアンダークラウドのパブリック API がリッスンするパブリックに表示されるインターフェースに設定する必要があります。デフォルトでは、パブリック API は br-ctlplane インターフェースをリッスンします。カスタム環境ファイルに PublicVirtualInterface パラメーターを設定して、custom_env_files パラメーターを設定してカスタム環境ファイルを undercloud.conf ファイルに追加します。

アンダークラウドネットワークインターフェースのカスタマイズに関する詳しい情報は、「アンダー クラウドネットワークインターフェースの設定」を参照して ください。

undercloud_service_certificate
OpenStack SSL/TLS 通信の証明書の場所とファイル名。理想的には、信頼できる認証局から、この証明書を取得します。それ以外の場合は、独自の自己署名の証明書を生成します。
undercloud_timezone
アンダークラウド用ホストのタイムゾーン。タイムゾーンを指定しなければ、director は既存のタイムゾーン設定を使用します。
undercloud_update_packages
アンダークラウドのインストール時にパッケージを更新するかどうかを定義します。

サブネット

undercloud.conf ファイルには、各プロビジョニングサブネットの名前が付いたセクションがあります。たとえば、ctlplane-subnet という名前のサブネットを作成するには、undercloud.conf ファイルで以下のような設定を使用します。

[ctlplane-subnet]
cidr = 192.168.24.0/24
dhcp_start = 192.168.24.5
dhcp_end = 192.168.24.24
inspection_iprange = 192.168.24.100,192.168.24.120
gateway = 192.168.24.1
masquerade = true

プロビジョニングネットワークは、環境に応じて、必要なだけ指定することができます。

重要

director がサブネットを作成した後、director はサブネットの IP アドレスを変更することはできません。

cidr
オーバークラウドインスタンスの管理に director が使用するネットワーク。これは、アンダークラウドの neutron サービスが管理するプロビジョニングネットワークです。プロビジョニングネットワークに別のサブネットを使用しない限り、この値はデフォルト (192.168.24.0/24) のままにします。
masquerade

外部ネットワークへのアクセスのために、cidr で定義したネットワークをマスカレードするかどうかを定義します。このパラメーターにより、director 経由で外部ネットワークにアクセスすることができるように、プロビジョニングネットワークにネットワークアドレス変換 (NAT) の一部メカニズムが提供されます。

注記

director 設定は、適切な sysctl カーネルパラメーターを使用して IP フォワーディングも自動的に有効化します。

dhcp_start、dhcp_end
オーバークラウドノードの DHCP 割り当て範囲 (開始アドレスと終了アドレス)。ノードを割り当てるのに十分な IP アドレスがこの範囲に含まれるようにします。
dhcp_exclude
DHCP 割り当て範囲で除外する IP アドレス
dns_nameservers
サブネットに固有の DNS ネームサーバー。サブネットにネームサーバーが定義されていない場合には、サブネットは undercloud_nameservers パラメーターで定義されるネームサーバーを使用します。
gateway
オーバークラウドインスタンスのゲートウェイ。外部ネットワークにトラフィックを転送するアンダークラウドのホストです。director に別の IP アドレスを使用する場合または直接外部ゲートウェイを使用する場合以外は、この値はデフォルト (192.168.24.1) のままにします。
host_routes
このネットワーク上のオーバークラウドインスタンス用の neutron が管理するサブネットのホストルート。このパラメーターにより、アンダークラウド上の local_subnet のホストルートも設定されます。
inspection_iprange
検査プロセス中に使用するこのネットワーク上のノードの一時的な IP 範囲。この範囲は、dhcp_startdhcp_end で定義された範囲と重複することはできませんが、同じ IP サブネット内になければなりません。

6.11. director のアップグレードの実施

director をアップグレードするには、以下の手順を実施します。

手順

  1. 以下のコマンドを実行して、アンダークラウド上の director をアップグレードします。

    $ openstack undercloud upgrade

    このコマンドにより、director の設定スクリプトが起動します。director によりパッケージがアップグレードされ、undercloud.conf の設定に合わせてサービスが設定されます。このスクリプトは、完了までに数分かかります。

    注記

    director の設定スクリプトでは、次の設定に進む前に確認が求められます。この確認を省略するには、-y オプションを使用します。

    $ openstack undercloud upgrade -y
  2. このスクリプトにより、アンダークラウド上の OpenStack Platform サービスのコンテナーも、すべて自動的に起動されます。systemd リソースでそれぞれのサービスを管理します。systemd リソースを確認します。

    $ sudo systemctl list-units "tripleo_*"

    systemd サービスでコンテナーを制御します。以下のコマンドを使用して、有効化されたコンテナーを確認してください。

    $ sudo podman ps
  3. スクリプトにより stack ユーザーが docker グループに追加され、stack ユーザーがコンテナー管理コマンドを使用できるようになります。以下のコマンドで stack ユーザーのアクセス権限をリフレッシュします。

    $ exec su -l stack

    このコマンドを実行すると、再度ログインが求められます。stack ユーザーのパスワードを入力します。

  4. stack ユーザーを初期化してコマンドラインツールを使用するには、以下のコマンドを実行します。

    $ source ~/stackrc

    プロンプトには、OpenStack コマンドがアンダークラウドに対して認証および実行されることが表示されるようになります。

    (undercloud) $

director のアップグレードが完了しました。

第7章 オーバークラウド準備の初期手順

オーバークラウドのアップグレードに向けた準備を行うには、いくつかの初期手順を完了する必要があります。

7.1. オーバークラウドサービスのダウンタイムの準備

オーバークラウドのアップグレードプロセスにより、重要なポイントで主要のサービスは無効化されます。このため、アップグレード中は、オーバークラウドサービスを使用して新規リソースを作成することはできません。アップグレード中は、オーバークラウドで実行中のワークロードはアクティブな状態のままなので、インスタンスはアップグレード中にも稼働し続けることになります。

アップグレード中にはユーザーがオーバークラウドのサービスにアクセスできないように、メンテナンスの時間帯を計画することが重要となります。

オーバークラウドのアップグレードによる影響を受ける項目

  • OpenStack Platform サービス

オーバークラウドのアップグレードによる影響を受けない項目

  • アップグレード中に実行するインスタンス
  • Ceph Storage OSD (インスタンス向けのバックエンドストレージ)
  • Linux ネットワーク
  • Open vSwitch ネットワーク
  • アンダークラウド

7.2. アップグレードテスト用のコンピュートノードの選択

オーバークラウドのアップグレードプロセスでは、次のいずれかを行うことができます。

  • 1 つのロールのノードをすべてアップグレードする
  • 個別のノードを別々にアップグレードする

オーバークラウドのアップグレードプロセスを円滑にするには、全コンピュートノードをアップグレードする前に、環境内にある個々のコンピュートノードのいくつかでアップグレードをテストすると役立ちます。これにより、アップグレード中に大きな問題が発生しなくなり、ワークロードのダウンタイムを最小限に抑えることができます。

アップグレードをテストするノードを選択するにあたっては、以下の推奨事項を参考にしてください。

  • アップグレードのテストには、2 台または 3 台のコンピュートノードを選択します。
  • クリティカルなインスタンスが実行されていないノードを選択します。
  • 必要な場合には、選択したテスト用のコンピュートノードから他のコンピュートノードにクリティカルなインスタンスを移行します。

7.3. アップグレード前の要件の検証

pre-upgrade 検証グループを実行して、アップグレード前の要件を確認します。

手順

  1. source コマンドで stackrc ファイルを読み込みます。

    $ source ~/stackrc
  2. --group pre-upgrade オプションを指定して openstack tripleo validator run コマンドを実行し、/usr/libexec/platform-python python ランタイム環境を追加します。

    $ openstack tripleo validator run --group pre-upgrade --python-interpreter /usr/libexec/platform-python
  3. 検証レポートの結果を確認します。特定の検証からの詳細出力を表示するには、レポートからの特定検証の UUID を指定して openstack tripleo validator show run --full コマンドを実行します。

    $ openstack tripleo validator show run  --full <UUID>
重要

検証結果が FAILED であっても、Red Hat OpenStack Platform のデプロイや実行が妨げられることはありません。ただし、FAILED の検証結果は、実稼働環境で問題が発生する可能性があることを意味します。

7.4. オーバークラウドでのフェンシングの無効化

オーバークラウドをアップグレードする前に、フェンシングが無効になっていることを確認します。

オーバークラウドをアップグレードする場合、高可用性機能を維持するために、各コントローラーノードを個別にアップグレードします。フェンシングが環境にデプロイされると、オーバークラウドは特定ノードが無効であることを検出し、フェンシング操作を試みる場合があります。これにより、意図しない結果が生じる可能性があります。

オーバークラウドでフェンシングを有効にしている場合には、意図しない結果を防ぐために、アップグレード期間中フェンシングを一時的に無効にする必要があります。

注記

オーバークラウドでフェンシングを再び有効にするには、openstack overcloud update convergeコマンドを実行する前に、fencing.yaml環境ファイルでEnableFencingパラメーターをtrueに設定します。director は、デプロイメント時にオーバークラウドでのフェンシングを有効にします。

手順

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

    $ source ~/stackrc
  3. コントローラーノードにログインし、Pacemaker コマンドを実行してフェンシングを無効にします。

    $ ssh heat-admin@<controller_ip> "sudo pcs property set stonith-enabled=false"

    <controller_ip> を、コントローラーノードの IP アドレスに置き換えます。コントローラーノードの IP アドレスは、openstack server listコマンドで確認できます。

  4. fencing.yaml環境ファイルで、EnableFencingパラメーターをfalseに設定し、アップグレードプロセス中にフェンシングが無効のままとなるようにします。

7.5. オーバークラウドインベントリーファイルの作成

tripleo-ansible-inventory コマンドを使用して、環境内の全ノードの Ansible インベントリー ファイルを生成します。

手順

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

    $ source ~/stackrc
  3. 全ノードの静的なインベントリーファイルを作成します。

    $ tripleo-ansible-inventory --static-yaml-inventory ~/inventory.yaml --stack STACK_NAME

    デフォルトのスタック名 (overcloud) を使用していない場合は、--stack STACK NAME オプションでスタック名を設定します。STACK NAME は実際のスタック名に置き換えます。

  4. お使いの環境で Ansible のプレイブックを実行するには、ansible-playbook コマンドを実行し、-i オプションを使用して動的インベントリーツールの完全パスを追加します。以下に例を示します。

    (undercloud) $ ansible-playbook -i ~/inventory.yaml PLAYBOOK

第8章 Leapp アップグレードのためのオーバークラウド設定

ロングライフバージョンの Red Hat OpenStack Platform (RHOSP) をアップグレードするには、ベースオペレーティングシステムを Red Hat Enterprise Linux 7 から Red Hat Enterprise Linux 8 にアップグレードする必要があります。Red Hat Enterprise Linux 7 では、Leapp ユーティリティーを使用して Red Hat Enterprise Linux 8 へのアップグレードを実施します。Leapp およびその依存関係についての詳細は、「アップグレードに向けて RHEL 7 システムの準備」を参照してください。

オーバークラウドのアップグレードフレームワークでは、leapp によるアップグレードが自動的に実施されます。RHOSP が正常にアップグレードされるようにするには、アップグレード前のレポート生成を手動で実行して、発生する可能性のある問題を特定および解決することを推奨します。Compute、Controller、および Ceph Storage ロールのそれぞれについて、少なくとも 1 つのホストでアップグレード前のレポート生成を実行します。Leapp のアップグレード前のレポートの詳細は、「アップグレード前のレポートの確認」を参照してください。

8.1. アップグレード環境ファイルの作成

アップグレードプロセスでは、環境ファイルを使用して、アップグレードプロセスを有効にして特定のアップグレードパラメーターを設定します。

手順

  1. アンダークラウドに stack ユーザーとしてログインします。
  2. templates ディレクトリーに upgrades-environment.yaml という名前の環境ファイルを作成します。

    $ touch templates/upgrades-environment.yaml
  3. ファイルを編集し、以下の必須コンテンツを追加します。

    parameter_defaults:
      UpgradeLeappDevelSkip: "LEAPP_UNSUPPORTED=1 LEAPP_DEVEL_TARGET_RELEASE=8.4"
      LeappInitCommand: |
        for module in pata_acpi floppy; do sudo sed -i "/^${module}$/d" /usr/share/leapp-repository/repositories/system_upgrade/el7toel8/actors/kernel/checkkerneldrivers/files/removed_drivers.txt; done
        sudo rm -f /usr/share/leapp-repository/repositories/system_upgrade/el7toel8/actors/persistentnetnamesdisable/actor.py
        sudo yum -y remove mariadb-server* || true
      UpgradeInitCommand: "sudo dnf config-manager --save --setopt exclude=''"
      UpgradeLeappCommandOptions: " --enablerepo rhel-8-for-x86_64-baseos-eus-rpms --enablerepo rhel-8-for-x86_64-appstream-eus-rpms --enablerepo rhel-8-for-x86_64-highavailability-eus-rpms --enablerepo ansible-2.9-for-rhel-8-x86_64-rpms --enablerepo fast-datapath-for-rhel-8-x86_64-rpms "
    • UpgradeLeappDevelSkip: Leapp によるチェックを省略し、Leapp の実行時に環境変数を設定します。
    • LeappInitCommand は、各オーバークラウドノードで実行されるコマンドまたはスクリプトのスニペットを渡し、Leapp によるアップグレードに向けてノードを準備します。

    • UpgradeInitCommand は、各オーバークラウドノードで実行されるコマンドまたはスクリプトのスニペットを渡します。python2パッケージの自動削除が正常に行われるように、dnf config-manager --save --setopt exclude=''コマンドで、Leapp パッケージを DNF の除外対象から外します。
    • UpgradeLeappCommandOptionsは、Leapp のアップグレードプロセスにコマンドまたはスクリプトスニペットを渡します。このパラメーターを使用して、アップグレードに必要なリポジトリーを有効にします。
  4. (オプション) お使いの環境で TLS-Everywhere を使用していて、authconfigからauthselectに移行したい場合は、バグBZ#1978228 - OSP13→16.2 Leapp upgrade failed with TLSEverywhereを回避するために、authselect_check.confirmパラメーターをTrueに設定してください。

    parameter_defaults:
      LeappInitCommand: |
        sudo leapp answer --section authselect_check.confirm=True --add

    それ以外の場合は、値をFalseに設定します。

    注記

    LeappInitCommandパラメーターに複数のコマンドを渡すには、|構文を使います。

    parameter-defaults:
      LeappInitCommand: |
        <command_1>
        <command_2>
  5. upgrades-environment.yaml ファイルを保存します。

8.2. アップグレードのパラメーター

パラメーター説明

UpgradeInitCommand

アップグレードプロセスを初期化するためにすべてのオーバークラウドノード上で実行するコマンドまたはスクリプトのスニペット。たとえば、リポジトリーの切り替えなど。

UpgradeInitCommonCommand

アップグレードプロセスに必要な共通のコマンド。操作者は通常このパラメーターを変更する必要はなく、major-upgrade-composable-steps.yaml および major-upgrade-converge.yaml 環境ファイルで設定および設定解除されます。

UpgradeLeappCommandOptions

Leapp コマンドに追加するその他のコマンドラインオプション

UpgradeLeappDebug

Leapp の実行中にデバッグのアウトプットを出力します。デフォルト値は True です。

UpgradeLeappDevelSkip

開発/テスト環境で Leapp を実行する場合は、環境変数を設定して Leapp の確認を省略します。たとえば、LEAPP_DEVEL_SKIP_RHSM=1 と設定します。

UpgradeLeappEnabled

オペレーティングシステムのアップグレードに Leapp を使用します。デフォルト値は False です。

UpgradeLeappPostRebootDelay

マシンがリブートしてテストコマンドに応答するのを待つ最大の時間 (秒)。デフォルト値は 120 です。

UpgradeLeappRebootTimeout

Leapp による OS アップグレードフェーズのタイムアウト時間 (秒単位)。デフォルト値は 3600 です。

UpgradeLeappToInstall

Leapp によるアップグレード後にインストールするパッケージの一覧

UpgradeLeappToRemove

Leapp によるアップグレード時に削除するパッケージの一覧

8.3. オーバークラウドノードでの予測可能な NIC 名の使用

オーバークラウドノードで Leapp によるアップグレードを実施する前に、カーネルベースの NIC 名が使用されているかどうかを確認する必要があります。この NIC 名には、通常 eth の接頭辞が含まれます。NIC の割り当てに関して、通常これらの NIC 名は予測可能ではありません。

playbook-nics.yaml Playbook を実行して NIC の名前を変更し、インターフェースの NIC 接頭辞を使用することができます。また、Playbook の実行時に prefix 変数を変更することで、別の NIC 接頭辞を設定することもできます。ただし、NIC の変更は、Leapp によるアップグレードプロセスが完了し、ノードがリブートされた後にのみ適用されます。

前提条件

  • アンダークラウドの準備プロセス中に作成された playbook-nics.yaml Playbookplaybook-nics.yaml Playbook は、イーサネットデバイス、ブリッジ、および Linux ボンディングを使用するほとんどのオーバークラウドネットワーク設定のシナリオに対応します。お使いの環境でこれらのデバイス種別以外の追加設定が必要な場合は、手順を進める前に以下の推奨事項に従ってください。

    • 実際のオーバークラウドノードと類似したネットワーク設定の別システムで Playbook をテストする。
    • Playbook を変更し、他のデバイス種別の設定内の eth プレフィックスの名称変更に対応する。
    • 以下の手順を完了したら、オーバークラウドノードのネットワーク設定を確認する。

手順

  1. アンダークラウドに stack ユーザーとしてログインします。
  2. すべてのオーバークラウドノードで playbook-nics.yaml Playbook を実行します。

    $ ansible-playbook -i ~/inventory.yaml playbook-nics.yaml

    この Playbook により、新しい NIC の接頭辞が em に設定されます。別の NIC 接頭辞を設定するには、Playbook の実行時に prefix 変数を設定します。

    $ ansible-playbook -i ~/inventory.yaml -e prefix="mynic" playbook-nics.yaml

    NIC の変更は、Leapp によるアップグレードプロセスが完了し、ノードがリブートされた後にのみ適用されます。

第9章 コンポーザブルサービスおよびパラメーターの更新

オーバークラウドのアップグレードに向けた準備を行うには、いくつかのコンポーザブルサービス設定を完了する必要があります。

9.1. カスタム roles_data ファイルのコンポーザブルサービスの更新

本項では、新しいコンポーザブルサービスおよび非推奨のコンポーザブルサービスについて説明します。

  • デフォルトの roles_data ファイルを使用する場合は、これらのサービスが自動的に含まれます。
  • カスタムの roles_data ファイルを使用する場合は、該当するロールごとに新しいサービスを追加し非推奨のサービスを削除します。
重要

デプロイメント内のオーバークラウドノードが Object Storage (swift)専用ノードの場合は、デフォルトのroles_data.yamlファイルをコピーし、ObjectStorageを編集して、deprecated_server_resource_name:'SwiftStorage' の行を削除する必要があります。

コントローラーノード

コントローラーノードでは、以下のサービスが非推奨になっています。Controller ロールからこれらのサービスを削除します。

サービス理由

OS::TripleO::Services::AodhApi

OS::TripleO::Services::AodhEvaluator

OS::TripleO::Services::AodhListener

OS::TripleO::Services::AodhNotifier

メトリックおよびモニタリングには Service Telemetry Framework (STF) が優先されるため、OpenStack Telemetry サービスは非推奨になりました。従来のテレメトリーサービスは、STF への移行を促進するために RHOSP 16.2 でのみ利用可能で、RHOSP の将来のバージョンでは削除される予定です。

注記

自動スケーリングを使用する場合は、これらのサービスをコントローラーノードから削除しないでください。

OS::TripleO::Services::PankoApi

メトリックおよびモニタリングには Service Telemetry Framework (STF) が優先されるため、OpenStack Telemetry サービスは非推奨になりました。従来のテレメトリーサービスは、STF への移行を促進するために RHOSP 16.2 でのみ利用可能で、RHOSP の将来のバージョンでは削除される予定です。

注記

CloudForms を使用する場合は、これらのサービスをコントローラーノードから削除しないでください。

OS::TripleO::Services::CeilometerApi

OS::TripleO::Services::CeilometerCollector

OS::TripleO::Services::CeilometerExpirer

OS::TripleO::Services::MongoDb

これらのサービスはサポートされなくなりました。これらのサービスをコントローラーノードから削除します。

OS::TripleO::Services::Congress

Congress はサポートされなくなったため。

OS::TripleO::Services::GlanceRegistry

OpenStack Platform Image サービス (glance) API v2 により、このサービスはサポートされなくなったため。

OS::TripleO::Services::NeutronCorePluginPlumgrid

OS::TripleO::Services::NeutronCorePluginMidonet

これらの OpenStack Networking (neutron) 用プラグインは非推奨になったため。

OS::TripleO::Services::NeutronLbaasv2Agent

OS::TripleO::Services::NeutronLbaasv2Api

Octavia を優先し、OpenStack Networking (neutron) Load Balancing as a Service は非推奨になったため。

OS::TripleO::Services::NovaConsoleauth

このサービスは削除されています。

OS::TripleO::Services::NovaPlacement

OS::TripleO::Services::PlacementApi を優先し、非推奨になったため。

OS::TripleO::Services::OpenDaylightApi

OS::TripleO::Services::OpenDaylightOvs

OpenDaylight はサポートされなくなったため。

OS::TripleO::Services::RabbitMQ

このサービスは、2 つの新規サービスに置き換えられています。

OS::TripleO::Services::OsloMessagingRpc

OS::TripleO::Services::OsloMessagingNotify

OS::TripleO::Services::SkydiveAgent

OS::TripleO::Services::SkydiveAnalyzer

Skydive はサポートされなくなったため。

OS::TripleO::Services::Tacker

Tacker はサポートされなくなったため。

OS::TripleO::Services::gnocchi_metricd

OS::TripleO::Services::gnocchi_statsd

OS::TripleO::Services::gnocchi_api

Gnocchi は非推奨となり、RHOSP の今後のリリースで削除されます。

OS::TripleO::Services::panko_api_cron

panko は非推奨となり、RHOSP の今後のリリースで削除されます。

コントローラーノードの新規サービスは以下のとおりです。Controller ロールにこれらのサービスを追加します。

サービス理由

OS::TripleO::Services::CephGrafana

Ceph Dashboard サービスを有効にするタスク

OS::TripleO::Services::CinderBackendDellEMCPowermax

OS::TripleO::Services::CinderBackendDellEMCSc

OS::TripleO::Services::CinderBackendNVMeOF

Block Storage (cinder) の新規バックエンド

OS::TripleO::Services::ContainerImagePrepare

コマンドを実行して、オーバークラウドのサービスに関連するコンテナーイメージを自動的にプルして準備します。

OS::TripleO::Services::DesignateApi

OS::TripleO::Services::DesignateCentral

OS::TripleO::Services::DesignateProducer

OS::TripleO::Services::DesignateWorker

OS::TripleO::Services::DesignateMDNS

OS::TripleO::Services::DesignateSink

DNS-as-a-Service 用サービス (designate)

OS::TripleO::Services::IronicInspector

オーバークラウドのベアメタルイントロスペクション用サービス

OS::TripleO::Services::IronicNeutronAgent

OpenStack Bare Metal (ironic) 用ネットワークエージェント

OS::TripleO::Services::NeutronAgentsIBConfig

Mellanox InfiniBand OpenStack Networking (neutron) エージェント用サービス

OS::TripleO::Services::OpenStackClients

Red Hat OpenStack Platform コマンドラインツールをインストールするためのサービス

OS::TripleO::Services::OsloMessagingRpc

OS::TripleO::Services::OsloMessagingNotify

OS::TripleO::Services::RabbitMQ の代替サービス

OS::TripleO::Services::PlacementApi

Placement API 用サービス

コンピュートノード

コンピュートノードでは、以下のサービスが非推奨になっています。Compute ロールからこれらのサービスを削除します。

サービス理由

OS::TripleO::Services::OpenDaylightOvs

OpenDaylight はサポートされなくなったため。

OS::TripleO::Services::SkydiveAgent

Skydive はサポートされなくなったため。

コンピュートノードの新規サービスは以下のとおりです。Compute ロールにこれらのサービスを追加します。

サービス理由

OS::TripleO::Services::NovaAZConfig

OpenStack Compute (nova) でホストアグリゲートおよびアベイラビリティーゾーンを設定するためのサービス

全ノード

すべてのノードで、以下のサービスが非推奨になっています。すべてのロールからこれらのサービスを削除します。

サービス理由

OS::TripleO::Services::Docker

Podman に置き換わったため。

OS::TripleO::Services::Fluentd

OS::TripleO::Services::Rsyslog を優先し、非推奨になったため。

OS::TripleO::Services::Ntp

OS::TripleO::Services::Timesync を優先し、非推奨になったため。

OS::TripleO::Services::SensuClient

このサービスは非推奨になったため。

OS::TripleO::Services::Ptp

OS::TripleO::Services::Timesync を優先し、非推奨になったため。

全ノードでの新規サービスは以下のとおりです。すべてのロールにこれらのサービスを追加します。

サービス理由

OS::TripleO::Services::BootParams

カーネル引数、Tuned プロファイル、および CPU 分離を設定するためのサービス

OS::TripleO::Services::Collectd

Collectd を設定するためのサービス

OS::TripleO::Services::Multipathd

デフォルトで無効化されている Multipathd サービスを提供します。

OS::TripleO::Services::Podman

Podman をインストールし有効にするためのサービス

OS::TripleO::Services::Rear

Relax-and-Recover (ReaR) バックアップおよびリストアツールをインストールおよび有効にするためのサービス

OS::TripleO::Services::Rsyslog

集中ログコレクションを設定するためのサービス

OS::TripleO::Services::Timesync

時刻同期方法 (デフォルトでは Chronyd) を有効にするためのサービス

9.2. カスタム環境ファイルのコンポーザブルサービスの更新

resource_registry セクションのあるカスタム環境ファイルを使用している場合は、resource_registry セクションでコンポーザブルサービステンプレートのマッピングに変更がないか確認してください。Red Hat OpenStack Platform 16.2 では、コンポーザブルサービスのファイルは /usr/share/openstack-tripleo-heat-templates/ 内の新しい場所にあります。

Red Hat OpenStack Platform 13Red Hat OpenStack Platform 16.2

docker/services/

deployment

deployment ディレクトリーには、コンポーザブルサービスをグループ化するためのサブディレクトリーセットが含まれます。たとえば、keystone サブディレクトリーには、OpenStack Identity (keystone) のコンポーザブルサービステンプレートが含まれます。

カスタム環境ファイルのコンポーザブルサービスを再マッピングするには、現在のサービスマッピングのテンプレートの場所を確認し、マッピングを新しい場所に編集します。以下の手順では、例として ceph-mgr.yaml を使用しています。

重要

以下の手順は、コンポーザブルサービスを再マッピングする際のガイドとしてのみ提供されます。いずれかのマッピングが不明であれば、Red Hat に連絡して正しいマッピングについてアドバイスを求めてください。

手順

  1. コンポーザブルサービスを使用するカスタム環境ファイルを検索します。通常、カスタム環境ファイルは /home/stack/templates ディレクトリーに保存されます。

    $ cd ~/templates/
    $ grep "OS::TripleO::Services" *

    このシナリオでは、ファイルの 1 つに古くなったマッピングがあるとします。

      OS::TripleO::Services::CephMgr: /usr/share/openstack-tripleo-heat-templates/docker/services/ceph-ansible/ceph-mgr.yaml
  2. /usr/share/openstack-tripleo-heat-templates/ の新しい ceph-mgr.yaml の場所を特定します。このファイルは、`deployment/ceph-ansible' ディレクトリーに置かれています。

    $ find /usr/share/openstack-tripleo-heat-templates/ -name ceph-mgr.yaml
    /usr/share/openstack-tripleo-heat-templates/deployment/ceph-ansible/ceph-mgr.yaml
  3. カスタム環境ファイルでサービスを編集します。

    resource_registry:
      OS::TripleO::Services::CephMgr: /usr/share/openstack-tripleo-heat-templates/deployment/ceph-ansible/ceph-mgr.yaml

    ファイルを保存します。

9.3. アンダークラウドレジストリーへのアクセスの設定

アンダークラウドレジストリーへのアクセスを設定するには、アンダークラウドのコントロールプレーンのホスト名およびプロビジョニングネットワーク上のアンダークラウドの IP アドレスを DockerInsecureRegistryAddress パラメーターに追加します。このパラメーターを containers-prepare-parameter.yaml ファイルに置き、パラメーターがこれ以降のオーバークラウドデプロイメントに含まれるようにします。

手順

  1. アンダークラウドに stack ユーザーとしてログインします。
  2. アンダークラウドのコントロールプレーンのホスト名を取得します。

    $ sudo hiera container_image_prepare_node_names
    ["undercloud.ctlplane.localdomain"]
  3. containers-prepare-parameter.yaml ファイルを編集し、DockerInsecureRegistryAddress パラメーターを追加して、アンダークラウドのコントロールプレーンのホスト名およびプロビジョニングネットワーク上のアンダークラウドの IP アドレスが含まれる YAML の一覧を指定します。

    parameter_defaults:
      DockerInsecureRegistryAddress:
      - undercloud.ctlplane.localdomain:8787
      - 192.168.24.1:8787
      ...

    ホスト名および IP アドレスの値に、オーバークラウドレジストリーのポート番号も追加する必要があります。ポート番号は 8787 です。

9.4. 非推奨化および廃止された NovaSchedulerDefaultFilters パラメーターのフィルター

お使いの環境でカスタムの NovaSchedulerDefaultFilters パラメーターが使用されている場合は、パラメーターを編集して以下に示す非推奨および廃止されたフィルターを削除します。

フィルター状態

AggregateCoreFilter

非推奨

AggregateRamFilter

非推奨

AggregateDiskFilter

非推奨

ExactCoreFilter

廃止

ExactRamFilter

廃止

ExactDiskFilter

廃止

CoreFilter

廃止

RamFilter

廃止

DiskFilter

廃止

RetryFilter

非推奨

重要

非推奨 と識別されたフィルターを使用しないでください。Red Hat OpenStack Platform 16.2 には引き続き非推奨のフィルターが含まれていますが、Red Hat OpenStack Platform の今後のバージョンにはこれらのフィルターは含まれません。

9.5. Compute 名の形式の設定

Red Hat OpenStack Platform 13 では 、%stackname%-compute-%index% がコンピュートノードのデフォルトの命名形式として使用されます。Red Hat OpenStack Platform 16.2 は %stackname%-novacompute-%index% をコンピュートノードのデフォルトの命名形式として使用します。デフォルトの命名形式を変更して、元の Red Hat OpenStack Platform 13 の命名形式を維持します。元の命名形式を使用しない場合には、director は新しい命名形式の新たな OpenStack Compute (nova) エージェントを設定し、古い命名形式の既存の OpenStack Compute (nova) エージェントを孤立サービスとして維持します。

手順

  1. アンダークラウドに stack ユーザーとしてログインします。
  2. Compute の命名形式を設定します。

    • カスタムの roles_data ファイルを使用する場合には、カスタムの roles_data ファイルを編集し、Compute ロールの HostnameFormatDefault パラメーターを設定します。

      - name: Compute
        …​
        HostnameFormatDefault: '%stackname%-compute-%index%'
        …​

      カスタム roles_data ファイルを編集します。

    • openstack-tripleo-heat-templates でデフォルトの roles_data ファイルを使用する場合には、環境ファイルで命名形式を設定します。実際のノード数およびフレーバーに合わせて環境ファイルを編集します。このファイルは、通常 node-info.yaml という名前です。parameter_defaults セクションに ComputeHostnameFormat パラメーターを追加します。

      parameter_defaults:
        …​
        ComputeHostnameFormat: '%stackname%-compute-%index%'
        …​

      node-info.yaml ファイルを保存します。

9.6. SSL/TLS 設定の更新

resource_registry から NodeTLSData リソースを削除して、SSL/TLS 設定を更新します。

手順

  1. アンダークラウドに stack ユーザーとしてログインします。
  2. stackrc ファイルを取得します。

    $ source ~/stackrc
  3. カスタムのオーバークラウド SSL/TLS パブリックエンドポイントファイルを編集します。このファイルは、通常 ~/templates/enable-tls.yaml という名前です。
  4. resource_registry から NodeTLSData リソースを削除します。

    resource_registry:
      *OS::TripleO::NodeTLSData: /usr/share/openstack-tripleo-heat-templates/puppet/extraconfig/tls/tls-cert-inject.yaml*
      ...

    オーバークラウドデプロイメントは、HAProxy の新しいサービスを使用して SSL/TLS が有効かどうかを判断します。

    注記

    enable-tls.yaml ファイルの resource_registry セクションにある唯一のリソースである場合は、resource_registry セクションをすべて削除します。

  5. SSL/TLS パブリックエンドポイントファイルを保存します。

9.7. 設定後テンプレートの更新

OS::TripleO::NodeExtraConfigPost リソースを使用して設定後テンプレートを登録して実行する場合は、テンプレートに EndpointMap パラメーターを追加する必要があります。

手順

  1. 設定後テンプレートを編集します。
  2. parameters セクションに、EndpointMap パラメーターとそのサブパラメーターを追加します。

    parameters:
      servers:
        type: json
      nameserver_ip:
        type: string
      DeployIdentifier:
        type: string
      EndpointMap:
        default: {}
        type: json
  3. テンプレートを保存します。

9.8. 従来のテレメトリーサービスを維持する場合の考慮事項

Red Hat OpenStack Platform (RHOSP) 16.2 では、Service Telemetry Framework (STF) を優先し、OpenStack Telemetry のコンポーネントは非推奨になりました。したがって、アップグレード後は従来のテレメトリーコンポーネントは有効ではありません。

自動スケーリングまたは CloudForms サービスを使用する場合は、従来のテレメトリーサービスを維持する必要があります。

従来の RHOSP 13 Telemetry サービスをそのまま使用するには、openstack overcloud upgrade prepare および openstack overcloud upgrade converge コマンドを実行する時に、/usr/share/openstack-tripleo-heat-templates/environments/enable-legacy-telemetry.yaml 環境ファイルを追加します。

アップグレード後にオーバークラウドを更新するたびに、enable-legacy-telemetry.yaml 環境ファイルも追加する必要があります。

従来のテレメトリーサービスは、STF への移行を促進するためにのみ利用可能で、RHOSP の将来のバージョンでは削除される予定です。

第10章 Red Hat カスタマーポータルへのオーバークラウド登録の更新

Red Hat OpenStack Platform 16.2 では、Ansible ベースの手法を使用してオーバークラウドノードを Red Hat カスタマーポータルに登録します。

10.1. Red Hat Subscription Manager (RHSM) コンポーザブルサービス

rhsm コンポーザブルサービスを使用して、Ansible を介してオーバークラウドノードを登録することができます。デフォルトの roles_data ファイルの各ロールには、OS::TripleO::Services::Rhsm リソースが含まれており、これはデフォルトで無効になっています。サービスを有効にするには、このリソースを rhsm コンポーザブルサービスのファイルに登録します。

resource_registry:
  OS::TripleO::Services::Rhsm: /usr/share/openstack-tripleo-heat-templates/deployment/rhsm/rhsm-baremetal-ansible.yaml

rhsm コンポーザブルサービスは RhsmVars パラメーターを受け入れます。これを使用して、登録に必要な複数のサブパラメーターを定義することができます。

parameter_defaults:
  RhsmVars:
    rhsm_repos:
      - rhel-8-for-x86_64-baseos-eus-rpms
      - rhel-8-for-x86_64-appstream-eus-rpms
      - rhel-8-for-x86_64-highavailability-eus-rpms
      …​
    rhsm_username: "myusername"
    rhsm_password: "p@55w0rd!"
    rhsm_org_id: "1234567"
    rhsm_release: 8.4

RhsmVars パラメーターをロール固有のパラメーター (例: ControllerParameters) と共に使用することにより、異なるノードタイプ用の特定のリポジトリーを有効化する場合に柔軟性を提供することもできます。

10.2. RhsmVars サブパラメーター

rhsm コンポーザブルサービスを設定する際に、以下のサブパラメーターを RhsmVars パラメーターの一部として使用します。利用可能な Ansible パラメーターについての詳細は、ロールに関するドキュメント を参照してください。

rhsm説明

rhsm_method

登録の方法を選択します。portalsatellite、または disable のいずれかです。

rhsm_org_id

登録に使用する組織。この ID を特定するには、アンダークラウドノードから sudo subscription-manager orgs を実行します。プロンプトが表示されたら Red Hat の認証情報を入力して、出力される Key の値を使用します。組織の ID についての詳細は、「Red Hat Subscription Management における組織 ID について理解する」を参照してください。

rhsm_pool_ids

使用するサブスクリプションプール ID。サブスクリプションを自動でアタッチしない場合は、このパラメーターを使用します。この ID を特定するには、アンダークラウドノードから sudo subscription-manager list --available --all --matches="Red Hat OpenStack" を実行して、出力される Pool ID 値を使用します。

rhsm_activation_key

登録に使用するアクティベーションキー

rhsm_autosubscribe

このパラメーターを使用して、互換性のあるサブスクリプションを自動的にこのシステムにアタッチします。この機能を有効にするには、値を true に設定します。

rhsm_baseurl

コンテンツを取得するためのベース URL。デフォルトの URL は Red Hat コンテンツ配信ネットワークです。Satellite サーバーを使用している場合は、この値を Satellite サーバーコンテンツリポジトリーのベース URL に変更します。

rhsm_server_hostname

登録用のサブスクリプション管理サービスのホスト名。デフォルトは Red Hat Subscription Management のホスト名です。Satellite サーバーを使用している場合は、この値を Satellite サーバーのホスト名に変更します。

rhsm_repos

有効にするリポジトリーの一覧

rhsm_username

登録用のユーザー名。可能な場合には、登録用のアクティベーションキーを使用します。

rhsm_password

登録用のパスワード。可能な場合には、登録用のアクティベーションキーを使用します。

rhsm_release

リポジトリー固定用の Red Hat Enterprise Linux リリース。Red Hat OpenStack Platform の場合、このパラメーターは 8.4 に設定されます。

rhsm_rhsm_proxy_hostname

HTTP プロキシーのホスト名。たとえば、proxy.example.com

rhsm_rhsm_proxy_port

HTTP プロキシー通信用のポート。たとえば、8080

rhsm_rhsm_proxy_user

HTTP プロキシーにアクセスするためのユーザー名

rhsm_rhsm_proxy_password

HTTP プロキシーにアクセスするためのパスワード

重要

rhsm_methodportal に設定されている場合に限り、rhsm_activation_keyrhsm_repos を使用できます。rhsm_method を「satellite」に設定すると、rhsm_activation_key または rhsm_repos のいずれかを使用できます。

10.3. rhsm コンポーザブルサービスへの切り替え

従来の rhel-registration メソッドは、bash スクリプトを実行してオーバークラウドの登録を処理します。このメソッド用のスクリプトと環境ファイルは、/usr/share/openstack-tripleo-heat-templates/extraconfig/pre_deploy/rhel-registration/ のコア Heat テンプレートコレクションにあります。

rhel-registration メソッドを rhsm コンポーザブルサービスに切り替えるには、以下の手順を実施します。

手順

  1. rhel-registration 環境ファイルは、今後のデプロイメント操作から除外します。通常は、以下のファイルを除外します。

    • rhel-registration/environment-rhel-registration.yaml
    • rhel-registration/rhel-registration-resource-registry.yaml
  2. カスタムの roles_data ファイルを使用する場合には、roles_data ファイルの各ロールに必ず OS::TripleO::Services::Rhsm コンポーザブルサービスを含めてください。以下に例を示します。

    - name: Controller
      description: |
        Controller role that has all the controller services loaded and handles
        Database, Messaging and Network functions.
      CountDefault: 1
      ...
      ServicesDefault:
        ...
        - OS::TripleO::Services::Rhsm
        ...
  3. rhsm コンポーザブルサービスのパラメーター用の環境ファイルを今後のデプロイメント操作に追加します。

このメソッドは、rhel-registration パラメーターを rhsm サービスのパラメーターに置き換えて、サービスを有効化する Heat リソースを変更します。

resource_registry:
  OS::TripleO::NodeExtraConfig: rhel-registration.yaml

必要に応じて、以下を行ってください。

resource_registry:
  OS::TripleO::Services::Rhsm: /usr/share/openstack-tripleo-heat-templates/deployment/rhsm/rhsm-baremetal-ansible.yaml

デプロイメントに /usr/share/openstack-tripleo-heat-templates/environments/rhsm.yaml 環境ファイルを追加して、サービスを有効にすることもできます。

10.4. rhel-registration から rhsm へのマッピング

rhel-registration メソッドから rhsm メソッドへの情報の移行を容易に行うには、以下の表を使用してパラメーターとその値をマッピングします。

rhel-registrationrhsm / RhsmVars

rhel_reg_method

rhsm_method

rhel_reg_org

rhsm_org_id

rhel_reg_pool_id

rhsm_pool_ids

rhel_reg_activation_key

rhsm_activation_key

rhel_reg_auto_attach

rhsm_autosubscribe

rhel_reg_sat_url

rhsm_satellite_url

rhel_reg_repos

rhsm_repos

rhel_reg_user

rhsm_username

rhel_reg_password

rhsm_password

rhel_reg_release

rhsm_release

rhel_reg_http_proxy_host

rhsm_rhsm_proxy_hostname

rhel_reg_http_proxy_port

rhsm_rhsm_proxy_port

rhel_reg_http_proxy_username

rhsm_rhsm_proxy_user

rhel_reg_http_proxy_password

rhsm_rhsm_proxy_password

10.5. rhsm コンポーザブルサービスを使用したオーバークラウドの登録

rhsm コンポーザブルサービスを有効にして設定する環境ファイルを作成します。director はこの環境ファイルを使用して、ノードを登録し、サブスクライブします。

手順

  1. 設定を保存するための環境ファイル (templates/rhsm.yml) を作成します。
  2. 環境ファイルに設定を追加します。以下に例を示します。

    resource_registry:
      OS::TripleO::Services::Rhsm: /usr/share/openstack-tripleo-heat-templates/deployment/rhsm/rhsm-baremetal-ansible.yaml
    parameter_defaults:
      RhsmVars:
        rhsm_repos:
          - rhel-8-for-x86_64-baseos-eus-rpms
          - rhel-8-for-x86_64-appstream-eus-rpms
          - rhel-8-for-x86_64-highavailability-eus-rpms
          …​
        rhsm_username: "myusername"
        rhsm_password: "p@55w0rd!"
        rhsm_org_id: "1234567"
        rhsm_pool_ids: "1a85f9223e3d5e43013e3d6e8ff506fd"
        rhsm_method: "portal"
        rhsm_release: 8.4
    • resource_registry セクションは、各ロールで利用可能な OS::TripleO::Services::Rhsm リソースに rhsm コンポーザブルサービスを関連付けます。
    • RhsmVars の変数は、Red Hat の登録を設定するためにパラメーターを Ansible に渡します。
  3. 環境ファイルを保存します。

10.6. 異なるロールに対する rhsm コンポーザブルサービスの適用

rhsm コンポーザブルサービスをロールごとに適用することができます。たとえば、コントローラーノード、コンピュートノード、および Ceph Storage ノードに、異なる設定セットを適用することができます。

手順

  1. 設定を保存するための環境ファイル (templates/rhsm.yml) を作成します。
  2. 環境ファイルに設定を追加します。以下に例を示します。

    resource_registry:
      OS::TripleO::Services::Rhsm: /usr/share/openstack-tripleo-heat-templates/deployment/rhsm/rhsm-baremetal-ansible.yaml
    parameter_defaults:
      ControllerParameters:
        RhsmVars:
          rhsm_repos:
            - rhel-8-for-x86_64-baseos-eus-rpms
            - rhel-8-for-x86_64-appstream-eus-rpms
            - rhel-8-for-x86_64-highavailability-eus-rpms
            - ansible-2.9-for-rhel-8-x86_64-rpms
            - openstack-16.2-for-rhel-8-x86_64-rpms
            - fast-datapath-for-rhel-8-x86_64-rpms
          rhsm_username: "myusername"
          rhsm_password: "p@55w0rd!"
          rhsm_org_id: "1234567"
          rhsm_pool_ids: "55d251f1490556f3e75aa37e89e10ce5"
          rhsm_method: "portal"
          rhsm_release: 8.4
      ComputeParameters:
        RhsmVars:
          rhsm_repos:
            - rhel-8-for-x86_64-baseos-eus-rpms
            - rhel-8-for-x86_64-appstream-eus-rpms
            - rhel-8-for-x86_64-highavailability-eus-rpms
            - ansible-2.9-for-rhel-8-x86_64-rpms
            - openstack-16.2-for-rhel-8-x86_64-rpms
            - fast-datapath-for-rhel-8-x86_64-rpms
          rhsm_username: "myusername"
          rhsm_password: "p@55w0rd!"
          rhsm_org_id: "1234567"
          rhsm_pool_ids: "55d251f1490556f3e75aa37e89e10ce5"
          rhsm_method: "portal"
          rhsm_release: 8.4
      CephStorageParameters:
        RhsmVars:
          rhsm_repos:
            - rhel-8-for-x86_64-baseos-rpms
            - rhel-8-for-x86_64-appstream-rpms
            - rhel-8-for-x86_64-highavailability-rpms
            - ansible-2.9-for-rhel-8-x86_64-rpms
            - openstack-16.2-deployment-tools-for-rhel-8-x86_64-rpms
          rhsm_username: "myusername"
          rhsm_password: "p@55w0rd!"
          rhsm_org_id: "1234567"
          rhsm_pool_ids: "68790a7aa2dc9dc50a9bc39fabc55e0d"
          rhsm_method: "portal"
          rhsm_release: 8.4

    resource_registry は、各ロールで利用可能な OS::TripleO::Services::Rhsm リソースに rhsm コンポーザブルサービスを関連付けます。

    ControllerParametersComputeParameters、および CephStorageParameters パラメーターはいずれも、個別の RhsmVars パラメーターを使用してサブスクリプションの情報をそれぞれのロールに渡します。

    注記

    Red Hat Ceph Storage のサブスクリプションおよび Ceph Storage 固有のリポジトリーを使用するように、CephStorageParameters パラメーター内の RhsmVars パラメーターを設定します。rhsm_repos パラメーターに、コントローラーノードおよびコンピュートノードに必要な Extended Update Support (EUS) リポジトリーではなく、標準の Red Hat Enterprise Linux リポジトリーが含まれるようにします。

  3. 環境ファイルを保存します。

第11章 Red Hat Satellite Server へのオーバークラウド登録の更新

Red Hat OpenStack Platform 16.2 では、Ansible ベースの手法を使用してオーバークラウドノードを Red Hat Satellite Server 6 に登録します。

11.1. Red Hat Subscription Manager (RHSM) コンポーザブルサービス

rhsm コンポーザブルサービスを使用して、Ansible を介してオーバークラウドノードを登録することができます。デフォルトの roles_data ファイルの各ロールには、OS::TripleO::Services::Rhsm リソースが含まれており、これはデフォルトで無効になっています。サービスを有効にするには、このリソースを rhsm コンポーザブルサービスのファイルに登録します。

resource_registry:
  OS::TripleO::Services::Rhsm: /usr/share/openstack-tripleo-heat-templates/deployment/rhsm/rhsm-baremetal-ansible.yaml

rhsm コンポーザブルサービスは RhsmVars パラメーターを受け入れます。これを使用して、登録に必要な複数のサブパラメーターを定義することができます。

parameter_defaults:
  RhsmVars:
    rhsm_repos:
      - rhel-8-for-x86_64-baseos-eus-rpms
      - rhel-8-for-x86_64-appstream-eus-rpms
      - rhel-8-for-x86_64-highavailability-eus-rpms
      …​
    rhsm_username: "myusername"
    rhsm_password: "p@55w0rd!"
    rhsm_org_id: "1234567"
    rhsm_release: 8.4

RhsmVars パラメーターをロール固有のパラメーター (例: ControllerParameters) と共に使用することにより、異なるノードタイプ用の特定のリポジトリーを有効化する場合に柔軟性を提供することもできます。

11.2. RhsmVars サブパラメーター

rhsm コンポーザブルサービスを設定する際に、以下のサブパラメーターを RhsmVars パラメーターの一部として使用します。利用可能な Ansible パラメーターについての詳細は、ロールに関するドキュメント を参照してください。

rhsm説明

rhsm_method

登録の方法を選択します。portalsatellite、または disable のいずれかです。

rhsm_org_id

登録に使用する組織。この ID を特定するには、アンダークラウドノードから sudo subscription-manager orgs を実行します。プロンプトが表示されたら Red Hat の認証情報を入力して、出力される Key の値を使用します。組織の ID についての詳細は、「Red Hat Subscription Management における組織 ID について理解する」を参照してください。

rhsm_pool_ids

使用するサブスクリプションプール ID。サブスクリプションを自動でアタッチしない場合は、このパラメーターを使用します。この ID を特定するには、アンダークラウドノードから sudo subscription-manager list --available --all --matches="Red Hat OpenStack" を実行して、出力される Pool ID 値を使用します。

rhsm_activation_key

登録に使用するアクティベーションキー

rhsm_autosubscribe

このパラメーターを使用して、互換性のあるサブスクリプションを自動的にこのシステムにアタッチします。この機能を有効にするには、値を true に設定します。

rhsm_baseurl

コンテンツを取得するためのベース URL。デフォルトの URL は Red Hat コンテンツ配信ネットワークです。Satellite サーバーを使用している場合は、この値を Satellite サーバーコンテンツリポジトリーのベース URL に変更します。

rhsm_server_hostname

登録用のサブスクリプション管理サービスのホスト名。デフォルトは Red Hat Subscription Management のホスト名です。Satellite サーバーを使用している場合は、この値を Satellite サーバーのホスト名に変更します。

rhsm_repos

有効にするリポジトリーの一覧

rhsm_username

登録用のユーザー名。可能な場合には、登録用のアクティベーションキーを使用します。

rhsm_password

登録用のパスワード。可能な場合には、登録用のアクティベーションキーを使用します。

rhsm_release

リポジトリー固定用の Red Hat Enterprise Linux リリース。Red Hat OpenStack Platform の場合、このパラメーターは 8.4 に設定されます。

rhsm_rhsm_proxy_hostname

HTTP プロキシーのホスト名。たとえば、proxy.example.com

rhsm_rhsm_proxy_port

HTTP プロキシー通信用のポート。たとえば、8080

rhsm_rhsm_proxy_user

HTTP プロキシーにアクセスするためのユーザー名

rhsm_rhsm_proxy_password

HTTP プロキシーにアクセスするためのパスワード

重要

rhsm_methodportal に設定されている場合に限り、rhsm_activation_keyrhsm_repos を使用できます。rhsm_method を「satellite」に設定すると、rhsm_activation_key または rhsm_repos のいずれかを使用できます。

11.3. rhsm コンポーザブルサービスへの切り替え

従来の rhel-registration メソッドは、bash スクリプトを実行してオーバークラウドの登録を処理します。このメソッド用のスクリプトと環境ファイルは、/usr/share/openstack-tripleo-heat-templates/extraconfig/pre_deploy/rhel-registration/ のコア Heat テンプレートコレクションにあります。

rhel-registration メソッドを rhsm コンポーザブルサービスに切り替えるには、以下の手順を実施します。

手順

  1. rhel-registration 環境ファイルは、今後のデプロイメント操作から除外します。通常は、以下のファイルを除外します。

    • rhel-registration/environment-rhel-registration.yaml
    • rhel-registration/rhel-registration-resource-registry.yaml
  2. カスタムの roles_data ファイルを使用する場合には、roles_data ファイルの各ロールに必ず OS::TripleO::Services::Rhsm コンポーザブルサービスを含めてください。以下に例を示します。

    - name: Controller
      description: |
        Controller role that has all the controller services loaded and handles
        Database, Messaging and Network functions.
      CountDefault: 1
      ...
      ServicesDefault:
        ...
        - OS::TripleO::Services::Rhsm
        ...
  3. rhsm コンポーザブルサービスのパラメーター用の環境ファイルを今後のデプロイメント操作に追加します。

このメソッドは、rhel-registration パラメーターを rhsm サービスのパラメーターに置き換えて、サービスを有効化する Heat リソースを変更します。

resource_registry:
  OS::TripleO::NodeExtraConfig: rhel-registration.yaml

必要に応じて、以下を行ってください。

resource_registry:
  OS::TripleO::Services::Rhsm: /usr/share/openstack-tripleo-heat-templates/deployment/rhsm/rhsm-baremetal-ansible.yaml

デプロイメントに /usr/share/openstack-tripleo-heat-templates/environments/rhsm.yaml 環境ファイルを追加して、サービスを有効にすることもできます。

11.4. rhel-registration から rhsm へのマッピング

rhel-registration メソッドから rhsm メソッドへの情報の移行を容易に行うには、以下の表を使用してパラメーターとその値をマッピングします。

rhel-registrationrhsm / RhsmVars

rhel_reg_method

rhsm_method

rhel_reg_org

rhsm_org_id

rhel_reg_pool_id

rhsm_pool_ids

rhel_reg_activation_key

rhsm_activation_key

rhel_reg_auto_attach

rhsm_autosubscribe

rhel_reg_sat_url

rhsm_satellite_url

rhel_reg_repos

rhsm_repos

rhel_reg_user

rhsm_username

rhel_reg_password

rhsm_password

rhel_reg_release

rhsm_release

rhel_reg_http_proxy_host

rhsm_rhsm_proxy_hostname

rhel_reg_http_proxy_port

rhsm_rhsm_proxy_port

rhel_reg_http_proxy_username

rhsm_rhsm_proxy_user

rhel_reg_http_proxy_password

rhsm_rhsm_proxy_password

11.5. Red Hat Satellite Server へのオーバークラウドの登録

ノードを Red Hat カスタマーポータルではなく Red Hat Satellite に登録するには、rhsm コンポーザブルサービスを有効にして設定する環境ファイルを作成します。

手順

  1. 設定を保存するための環境ファイル (templates/rhsm.yml) を作成します。
  2. 環境ファイルに設定を追加します。以下に例を示します。

    resource_registry:
      OS::TripleO::Services::Rhsm: /usr/share/openstack-tripleo-heat-templates/deployment/rhsm/rhsm-baremetal-ansible.yaml
    parameter_defaults:
      RhsmVars:
        rhsm_activation_key: "myactivationkey"
        rhsm_method: "satellite"
        rhsm_org_id: "ACME"
        rhsm_server_hostname: "satellite.example.com"
        rhsm_baseurl: "https://satellite.example.com/pulp/repos"
        rhsm_release: 8.4

    resource_registry は、各ロールで利用可能な OS::TripleO::Services::Rhsm リソースに rhsm コンポーザブルサービスを関連付けます。

    RhsmVars の変数は、Red Hat の登録を設定するためにパラメーターを Ansible に渡します。

  3. 環境ファイルを保存します。

11.6. Satellite Server を使用するための Leapp の準備

Satellite Server 6 を使用して RPM コンテンツをホストする場合は、以下の準備手順を実施して、Satellite を使用して Leapp によるアップグレードが正常に完了するようにします。

前提条件

  • Red Hat OpenStack Platform 16.2 および Red Hat Enterprise Linux 8.4 のリポジトリーにリンクされた Satellite Server のアクティベーションキーを作成している。
  • オーバークラウドノードの Ansible インベントリーファイルを生成している。
  • Satellite Server で Red Hat OpenStack Platform 16.2 アップグレード用のコンテンツビューを作成してプロモートし、アップグレードに必要なリポジトリーを追加している。詳細は、「Red Hat Satellite Server 6 に関する考慮事項」を参照してください。
  • Ceph のサブスクリプションを使用し、Ceph ストレージノード用に overcloud-minimal イメージを使用するように director を設定している場合、Satellite Server でコンテンツビューを作成し、以下の Red Hat Enterprise Linux (RHEL) 8.4 リポジトリーを追加する必要があります。

手順

  1. アンダークラウドに stack ユーザーとしてログインします。
  2. playbook-satellite.yaml という名前のファイルを作成し、以下のコンテンツをファイルに貼り付けます。

    - name: Pre-install leapp
      hosts: overcloud
      become: yes
      tasks:
        - name: Pre-install leapp
          yum:
            name:
              - leapp
              - leapp-repository
            state: installed
        - name: Remove katello-host-tools-fact-plugin
          yum:
            name:
              - katello-host-tools-fact-plugin
            state: removed
        - name: Register system
          redhat_subscription:
            activationkey: "osp16-key"
            org_id: "ACME"
            server_hostname: "satellite.example.com"
            rhsm_baseurl: "https://satellite.example.com/pulp/repos"
            force_register: True

    お使いの Satellite Server に合わせて redhat_subscription 変数を変更します。

  3. Playbook を実行します。

    $ ansible-playbook -i ~/inventory.yaml playbook-satellite.yaml

第12章 director でデプロイされた Ceph Storage のアップグレードの準備

director のデプロイした Red Hat Ceph Storage クラスターがデプロイメントで使用される場合は、本項に記載する手順を完了する必要があります。

注記

外部の Ceph デプロイメントと共にアップグレードする場合は、本項に記載する手順を省略し、「13章外部の Ceph デプロイメントと組み合わせたアップグレードの準備」に進む必要があります。

Red Hat OpenStack Platform 16.2 へのアップグレード中、プロセスでは Red Hat Ceph Storage 3 のコンテナー化されたサービスを継続して使用します。Red Hat OpenStack Platform 16.2 へのアップグレードが完了したら、Ceph Storage サービスを Red Hat Ceph Storage 4 にアップグレードします。

Red Hat OpenStack Platform 16.2 のアップグレードと Ceph Storage サービスの Red Hat Ceph Storage 4 へのアップグレードの両方が完了するまで、Shared File Systems サービス (manila) で新しいファイル共有をプロビジョニングすることはできません。

12.1. Ceph Storage ノードのアップグレードプロセスの概要

オーバークラウドのアップグレードプロセス中、director でデプロイされた Ceph Storage ノードは Red Hat Ceph Storage 3 コンテナーを継続して使用します。アップグレードプロセス中に Ceph Storage ノードおよびサービスがどのように影響を受けるかについて理解するには、Ceph Storage アップグレードプロセスの各要素ごとに以下の概要を参照してください。

Ceph Storage ノードおよび RHEL との互換性

RHOSP 16.2 は RHEL 8.4 でサポートされています。ただし、Ceph Storage ロールにマッピングされたホストは、最新の RHEL メジャーリリースに更新されます。詳細は、「 Red Hat Ceph Storage でサポートされる構成」を参照し てください。

ceph-ansible

ceph-ansible は、ロールおよび Playbook のコレクションです。director はこれを使用して Ceph Storage サービスのインストール、維持、およびアップグレードを行います。アンダークラウドをアップグレードする際に実行した特定のコマンドにより、Red Hat Enterprise Linux 8.4 への移行後に ceph-ansible は最新のバージョン 3 コレクションの状態を維持します。バージョン 3 の ceph-ansible は、オーバークラウドのアップグレード期間中、バージョン 3 のコンテナー化された Ceph Storage サービスを維持します。アップグレードが完了したら、Red Hat Ceph Storage Tools 4 for RHEL 8 リポジトリーを有効にし、ceph-ansible をバージョン 4 に更新します。

Podman への移行

オーバークラウドのアップグレード時には、openstack overcloud external-upgrade run --tags ceph_systemd コマンドを実行し、Ceph Storage のコンテナー化されたサービスを制御する systemd サービスが Docker ではなく Podman を使用するように変更する必要があります。Ceph Storage のコンテナー化されたサービスが含まれるいずれかのノードでオペレーティングシステムをアップグレードする前に、このコマンドを実行します。

systemd サービスがノード上で Podman を使用するように変更したら、オペレーティングシステムのアップグレードおよび OpenStack Platform サービスのアップグレードを実施します。そのノード上の Ceph Storage コンテナーは、OpenStack Platform サービスのアップグレード後に再度実行されます。

Ceph Storage のオペレーティングシステムのアップグレード

概略としては、Ceph Storage ノードで、オーバークラウドノードで実施するのと同じワークフローに従います。Ceph Storage ノードに対して openstack overcloud upgrade run --tags system_upgrade コマンドを実行すると、director は Ceph Storage ノードで Leapp を実行し、オペレーティングシステムを Red Hat Enterprise Linux 8.4 にアップグレードします。続いて、Ceph Storage ノードに対してタグ付けされていない openstack overcloud upgrade run コマンドを実行します。これにより、以下のコンテナーが実行されます。

  • Red Hat Ceph Storage 3 のコンテナー化されたサービス
  • Red Hat OpenStack Platform 16.2 のコンテナー化されたサービス

Red Hat Ceph Storage 4 へのアップグレード

Leapp によるアップグレードおよび Red Hat OpenStack Platform のアップグレードを完了した後も、Ceph Storage のコンテナー化されたサービスは引き続きバージョン 3 のコンテナーを使用します。この時点で ceph-ansible をバージョン 4 にアップグレードする必要があります。続いて openstack overcloud external-upgrade run --tags ceph コマンドを実行し、すべてのノード上の Red Hat Ceph Storage サービスをすべてバージョン 4 にアップグレードします。

Ceph Storage ワークフローの概要

Red Hat Ceph Storage をアップグレードするワークフローの概要を以下に示します。このワークフローは Red Hat OpenStack Platform の全体的なワークフローに統合されていて、アンダークラウド上でアップグレードフレームワークのコマンドを実行すると、このワークフローの操作が実施されます。

  1. アンダークラウドをアップグレードしますが、バージョン 3 の ceph-ansible を維持します。
  2. オーバークラウドのアップグレードを開始します。
  3. Ceph Storage のコンテナー化されたサービスをホストするノードごとに、以下のタスクを実行します。

    1. Ceph Storage のコンテナー化されたサービスを Podman に移行する。
    2. オペレーティングシステムをアップグレードする。
    3. OpenStack Platform サービスをアップグレードする。これにより、Ceph Storage バージョン 3 のコンテナー化されたサービスが再起動されます。
  4. オーバークラウドのアップグレードを完了します。
  5. アンダークラウドの ceph-ansible をバージョン 4 にアップグレードします。
  6. オーバークラウドで Red Hat Ceph Storage 4 にアップグレードします。
注記

このリストは Red Hat OpenStack Platform 16.2 アップグレードプロセス全体の全ステップを網羅している訳ではありません。アップグレードプロセス中 Ceph Storage サービスに何が起こるかを説明するために、Red Hat Ceph Storage に該当する要素にのみ焦点を当てています。

12.2. ceph-ansible バージョンの確認

アンダークラウドのアップグレード中、Ceph Storage 3 バージョンの ceph-ansible パッケージを維持します。これは、Ceph Storage ノード上の Ceph Storage 3 コンテナーの互換性を維持するのに役立ちます。このパッケージがアンダークラウドに残っていることを確認します。

手順

  1. アンダークラウドに stack ユーザーとしてログインします。
  2. dnf コマンドを実行して、ceph-ansible パッケージのバージョンを確認します。

    $ sudo dnf info ceph-ansible

    コマンド出力には、ceph-ansible パッケージのバージョン 3 が表示されます。

    Installed Packages
    Name         : ceph-ansible
    Version      : 3.xx.xx.xx
    ...
重要

ceph-ansible パッケージが見つからない、またはバージョン 3 のパッケージではない場合は、Red Hat Package Browser から最新のバージョン 3 パッケージをダウンロードし、アンダークラウドにパッケージを手動でインストールします。ceph-ansible バージョン 3 パッケージは Red Hat Enterprise Linux 7 リポジトリーからのみ利用可能で、Red Hat Enterprise Linux 8 リポジトリーでは利用できない点に注意してください。ceph-ansible バージョン 3 は、Red Hat OpenStack Platform のアップグレードフレームワークでの使用を除き、Red Hat Enterprise Linux 8 ではサポートされていません。

12.3. ceph-ansible リポジトリーの設定

director がオーバークラウドを Red Hat Ceph Storage 4 にアップグレードする前に、Red Hat OpenStack Platform 16.2 の検証フレームワークで ceph-ansible が適切にインストールされていることを確認します。フレームワークは、CephAnsibleRepo パラメーターを使用して、ceph-ansible が正しいリポジトリーからインストールされていることを確認します。openstack overcloud upgrade prepare コマンドの実行後に director はこのテストを無効にし、テストは Red Hat OpenStack Platform 16.2 オーバークラウドのアップグレード期間中は無効なままとなります。openstack overcloud upgrade converge コマンドの実行後に、director はこのテストを再度有効にします。ただし、この検証を準備するために、CephAnsibleRepo パラメーターを Red Hat Ceph Storage Tools 4 for RHEL 8 リポジトリーに設定する必要があります。

手順

  1. アンダークラウドに stack ユーザーとしてログインします。
  2. オーバークラウドの Ceph Storage 設定が含まれる環境ファイルを編集します。このファイルは、通常 ceph-config.yaml という名前で、templates ディレクトリーにあります。

    $ vi /home/stack/templates/ceph-config.yaml
  3. parameter_defaults セクションに CephAnsibleRepo パラメーターを追加します。

    parameter_defaults:
      ...
      CephAnsibleRepo: rhceph-4-tools-for-rhel-8-x86_64-rpms
      ...

    CephAnsibleRepo は、ceph-ansible が含まれるリポジトリーを設定します。検証フレームワークでは、このパラメーターを使用して、アンダークラウドに ceph-ansible がインストールされていることを確認します。

  4. ceph-config.yaml ファイルを保存します。

12.4. アップグレード前の Ceph クラスターステータスの確認

オーバークラウドのアップグレードを進める前に、Ceph クラスターが想定どおりに機能していることを確認する必要があります。

手順

  1. ceph-mon サービスを実行しているノードにログインします。このノードは、通常コントローラーノードまたはスタンドアロンの Ceph Monitor ノードです。
  2. 以下のコマンドを入力して、Ceph クラスターのステータスを表示します。

    $ docker exec ceph-mon-$HOSTNAME ceph -s
  3. クラスターの健全性ステータスが HEALTH_OK であること、およびすべての OSD が up の状態にあることを確認します。

第13章 外部の Ceph デプロイメントと組み合わせたアップグレードの準備

外部の Ceph デプロイメントと共にアップグレードする場合は、本項に記載する手順を完了する必要があります。

注記

デプロイメントで外部の Ceph Storage クラスターが使用されない場合は、本項に記載する手順を省略し、次のセクションに進む必要があります。

13.1. ceph-ansible のインストール

外部の Ceph デプロイメントと共にアップグレードする場合は、以下の手順を完了する必要があります。

Red Hat OpenStack Platform で Ceph Storage を使用する場合、ceph-ansible パッケージが必要です。

手順

  1. Ceph Tools リポジトリーを有効にします。

    [stack@director ~]$ sudo subscription-manager repos --enable=rhceph-4-tools-for-rhel-8-x86_64-rpms
  2. ceph-ansible パッケージをインストールします。

    [stack@director ~]$ sudo dnf install -y ceph-ansible

13.2. ceph-ansible リポジトリーの設定

director がオーバークラウドを Red Hat Ceph Storage 4 にアップグレードする前に、Red Hat OpenStack Platform 16.2 の検証フレームワークで ceph-ansible が適切にインストールされていることを確認します。フレームワークは、CephAnsibleRepo パラメーターを使用して、ceph-ansible が正しいリポジトリーからインストールされていることを確認します。openstack overcloud upgrade prepare コマンドの実行後に director はこのテストを無効にし、テストは Red Hat OpenStack Platform 16.2 オーバークラウドのアップグレード期間中は無効なままとなります。openstack overcloud upgrade converge コマンドの実行後に、director はこのテストを再度有効にします。ただし、この検証を準備するために、CephAnsibleRepo パラメーターを Red Hat Ceph Storage Tools 4 for RHEL 8 リポジトリーに設定する必要があります。

手順

  1. アンダークラウドに stack ユーザーとしてログインします。
  2. オーバークラウドの Ceph Storage 設定が含まれる環境ファイルを編集します。このファイルは、通常 ceph-config.yaml という名前で、templates ディレクトリーにあります。

    $ vi /home/stack/templates/ceph-config.yaml
  3. parameter_defaults セクションに CephAnsibleRepo パラメーターを追加します。

    parameter_defaults:
      ...
      CephAnsibleRepo: rhceph-4-tools-for-rhel-8-x86_64-rpms
      ...

    CephAnsibleRepo は、ceph-ansible が含まれるリポジトリーを設定します。検証フレームワークでは、このパラメーターを使用して、アンダークラウドに ceph-ansible がインストールされていることを確認します。

  4. ceph-config.yaml ファイルを保存します。

第14章 ネットワーク設定の更新

オーバークラウドのアップグレードに向けた準備を行うには、いくつかのネットワーク設定を完了する必要があります。

14.1. ネットワークインターフェーステンプレートの更新

Red Hat OpenStack Platform には、不足しているパラメーターを NIC テンプレートファイルに自動的に追加するスクリプトが用意されています。

手順

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

    $ source ~/stackrc
  3. アンダークラウドにおいて、update-nic-templates.sh という名前のファイルを作成し、以下の内容を追加します。

    #!/bin/bash
    STACK_NAME="overcloud"
    ROLES_DATA="/usr/share/openstack-tripleo-heat-templates/roles_data.yaml"
    NETWORK_DATA="/usr/share/openstack-tripleo-heat-templates/network_data.yaml"
    NIC_CONFIG_LINES=$(openstack stack environment show $STACK_NAME | grep "::Net::SoftwareConfig" | sed -E 's/ *OS::TripleO::// ; s/::Net::SoftwareConfig:// ; s/ http.*user-files/ /')
    echo "$NIC_CONFIG_LINES" | while read LINE; do
        ROLE=$(echo "$LINE" | awk '{print $1;}')
        NIC_CONFIG=$(echo "$LINE" | awk '{print $2;}')
    
        if [ -f "$NIC_CONFIG" ]; then
            echo "Updating template for $ROLE role."
            python3 /usr/share/openstack-tripleo-heat-templates/tools/merge-new-params-nic-config-script.py \
                --tht-dir /usr/share/openstack-tripleo-heat-templates \
                --roles-data $ROLES_DATA \
                --network-data $NETWORK_DATA \
                --role-name "$ROLE" \
                --discard-comments yes \
                --template "$NIC_CONFIG"
        else
            echo "No NIC template detected for $ROLE role. Skipping $ROLE role."
        fi
    done
    • カスタムのオーバークラウド名を使用している場合には、STACK_NAME 変数をそのオーバークラウドの名前に設定します。オーバークラウドスタックのデフォルト名は overcloud です。
    • カスタムの roles_data ファイルを使用する場合は、ROLES_DATA 変数をカスタムファイルの場所に設定します。デフォルトの roles_data ファイルを使用する場合には、変数を /usr/share/openstack-tripleo-heat-templates/roles_data.yaml のままにします。
    • カスタムの network_data ファイルを使用する場合は、NETWORK_DATA 変数をカスタムファイルの場所に設定します。デフォルトの network_dataファイルを使用する場合には、変数を /usr/share/openstack-tripleo-heat-templates/network_data.yaml のままにします。
    • /usr/share/openstack-tripleo-heat-templates/tools/merge-new-params-nic-config-script.py -h を実行して、スクリプトに追加するオプションの一覧を確認します。
  4. スクリプトに実行権限を追加します。

    $ chmod +x update-nic-templates.sh
  5. (オプション) RHOSP 環境にスパイン/リーフ型ネットワークトポロジーを使用する場合には、roles_data.yaml ファイルをチェックして、デプロイメントの NIC テンプレートに正しいロール名が使用されていることを確認します。このスクリプトは、roles_data.yaml ファイルの deprecated_nic_config_name パラメーターの値を使用します。
  6. スクリプトを実行します。

    $ ./update-nic-templates.sh

    スクリプトにより各カスタム NIC テンプレートのコピーが保存され、不足しているパラメーターで各テンプレートが更新されます。このスクリプトは、カスタムテンプレートを持たないロールもスキップします。

    No NIC template detected for BlockStorage role. Skipping BlockStorage role.
    Updating template for CephStorage role.
    The original template was saved as: /home/stack/templates/custom-nics/ceph-storage.yaml.20200903144835
    The update template was saved as: /home/stack/templates/custom-nics/ceph-storage.yaml
    Updating template for Compute role.
    The original template was saved as: /home/stack/templates/custom-nics/compute.yaml.20200903144838
    The update template was saved as: /home/stack/templates/custom-nics/compute.yaml
    Updating template for Controller role.
    The original template was saved as: /home/stack/templates/custom-nics/controller.yaml.20200903144841
    The update template was saved as: /home/stack/templates/custom-nics/controller.yaml
    No NIC template detected for ObjectStorage role. Skipping ObjectStorage role.

14.2. アップグレード中の Open vSwitch との互換性の維持

Red Hat OpenStack Platform 13 では、OpenStack Networking (neutron) のデフォルト ML2 バックエンドとして Open vSwitch (OVS) が使用されます。新しいバージョンの Red Hat OpenStack Platform では、OVS 機能を拡張した Open Virtual Network (OVN) が使用されます。ただし、安定したアップグレードを確保するには、アップグレードの期間中 OVS 機能を維持し、アップグレードの完了後に OVN に移行する必要があります。

アップグレード中に OVS との互換性を維持するには、環境ファイルコレクションの一部として以下の環境ファイルを追加します。

  • /usr/share/openstack-tripleo-heat-templates/environments/services/neutron-ovs.yaml
注記

neutron-ovs.yaml 環境ファイルを追加する場合は、neutron-ovs-dvr.yaml 環境ファイルが環境ファイルコレクションに含まれているかどうかを確認します。アップグレード中にエラーが発生するのを防ぐためには、neutron-ovs-dvr.yaml ファイルの前に neutron-ovs.yaml 環境ファイルを追加する必要があります。

OVN への移行が完了するまで、このファイルをデプロイメントの一部として扱います。すべてのオーバークラウドアップグレードコマンドおよびデプロイメントコマンドに、このファイルを追加します。

  • openstack overcloud upgrade prepare
  • openstack overcloud upgrade converge
  • openstack overcloud deploy
  • openstack overcloud update prepare
  • openstack overcloud update converge
  • 環境ファイルを使用するその他すべてのコマンド

OVS の互換性に関するトラブルシューティング

neutron-ovs.yaml ファイルで定義されたパラメーターが neutron-ovs-dvr.yaml で定義されたパラメーターを上書きするためにアップグレードプロセスが失敗する場合は、これらのファイルを追加する順序を変更し、影響を受けるノードで再度 openstack overcloud upgrade prepare および openstack overcloud upgrade run を実行します。影響を受けるノードの 1 つがコンピュートノードである場合は、そのノードから openstack-neutron* パッケージを削除します。

14.3. アップグレード中のコンポーザブルネットワーク互換性の維持

Red Hat Open Stack Platform 16.2 のnetwork_dataファイルフォーマットには、ネットワーク内の追加のサブネットやルートを定義するために使用できる新しいセクションが含まれています。ただし、カスタムの network_data ファイルを使用する場合には、引き続き Red Hat OpenStack Platform 13 の network_data ファイル形式を使用できます。

  • Red Hat Open Stack Platform 13 から 16.2 にアップグレードする際には、アップグレード中およびアップグレード後に Red Hat Open Stack Platform 13 のnetwork_dataファイル形式を使用します。Red Hat OpenStack Platform 13 コンポーザブルネットワークの構文についての詳しい情報は、「Custom composable networks」を参照してください。
  • Red Hat OpenStack Platform 16.2 に新しいオーバークラウドを作成する場合には、Red Hat OpenStack Platform 16.2 の network_data ファイル形式を使用します。Red Hat OpenStack Platform 16.2 コンポーザブルネットワークの構文についての詳しい情報は、Custom composable networksを参照してください。

第15章 ネットワーク機能仮想化 (NFV) の準備

ネットワーク機能仮想化 (NFV) を使用する場合は、オーバークラウドのアップグレードに向けて準備タスクを完了する必要があります。

15.1. ネットワーク機能仮想化 (NFV) 用環境ファイル

典型的な NFV ベースの環境では、以下のようなサービスを有効にすることができます。

  • Single-root input/output virtualization (SR-IOV)
  • Data Plane Development Kit (DPDK)

Red Hat OpenStack Platform 16.2 へのアップグレードに対応するために、これらのサービスに対して特定の再設定を行う必要はありません。ただし、NFV 機能を有効にする環境ファイルは、以下の要件を満たすようにしてください。

  • NFV 機能を有効にするデフォルトの環境ファイルは、Red Hat OpenStack Platform 16.2 openstack-tripleo-heat-templates コレクションの environments/services ディレクトリーにあります。Red Hat OpenStack Platform 13 デプロイメントに openstack-tripleo-heat-templates からのデフォルト NFV 環境ファイルを追加している場合は、Red Hat OpenStack Platform 16.2 での該当機能の正しい環境ファイルの場所を確認してください。

    • Open vSwitch (OVS) ネットワークおよび SR-IOV: /usr/share/openstack-tripleo-heat-templates/environments/services/neutron-sriov.yaml
    • Open vSwitch (OVS) ネットワークおよび DPDK: /usr/share/openstack-tripleo-heat-templates/environments/services/neutron-ovs-dpdk.yaml
  • Red Hat OpenStack Platform 13 から Red Hat OpenStack Platform 16.2 へのアップグレード中に OVS との互換性を維持するには、/usr/share/openstack-tripleo-heat-templates/environments/services/neutron-ovs.yaml 環境ファイルを追加する必要があります。環境ファイルを指定してデプロイメントおよびアップグレードのコマンドを実行する際には、neutron-ovs.yaml ファイルの後に NFV 関連の環境ファイルをすべて追加する必要があります。たとえば、OVS および NFV 環境ファイルを指定して openstack overcloud upgrade prepare を実行する場合は、以下の順序でファイルを追加します。
  • OVS 用環境ファイル
  • SR-IOV 用環境ファイル
  • DPDK 用環境ファイル

    $ openstack overcloud upgrade prepare \
        ...
        -e /usr/share/openstack-tripleo-heat-templates/environments/services/neutron-ovs.yaml \
        -e /usr/share/openstack-tripleo-heat-templates/environments/services/neutron-sriov.yaml \
        -e /usr/share/openstack-tripleo-heat-templates/environments/services/neutron-ovs-dpdk.yaml \
        ...
注記

RHOSP 13 のコンピュートノードが hybrid の状態にある場合に限り、アップグレード中に RHOSP 13 と RHOSP 16.2 のコンピュートノード間でインスタンスを移行することができます。詳細については、『Configuring the Compute Service for Instance Creation』「Migration constraints」を参照してください。

NFV ワークロードには、移行に関する追加の制約があります。アップグレード中に、OVS-DPDK コンピュートノードからのインスタンスのライブマイグレーションを行うことはできません。代替の手段として、アップグレード中に、OVS-DPDK コンピュートノードからのインスタンスのコールドマイグレーションを行うことができます。

第16章 アップグレード前の最終確認

アップグレードを開始する前に、すべての準備手順の最終確認を行います。

16.1. デプロイメントに含めるカスタムファイル

デプロイメント内のオーバークラウドノードが Object Storage (swift)専用ノードの場合は、デフォルトのroles_data.yamlファイルをコピーし、ObjectStorageを編集してdeprecated_server_resource_name: 'SwiftStorage'の行を削除する必要があります。その後、--roles-fileオプションを使用して、openstack overcloud upgrade prepareまたはopenstack overcloud upgrade convergeコマンドにそのファイルを渡します。

16.2. デプロイメントに追加する新たな環境ファイル

通常のオーバークラウドの環境ファイルに加えて、Red Hat OpenStack Platform (RHOSP) 16.2 へのアップグレードを円滑に行うために、新しい環境ファイルを追加する必要があります。

File備考

/home/stack/templates/upgrades-environment.yaml

このファイルには、アップグレードに固有のパラメーターが含まれます。このファイルは、アップグレード期間中にのみ必要です。openstack overcloud upgrade converge を実行した後は、このファイルを破棄します。

/home/stack/templates/rhsm.yaml

このファイルには、オーバークラウドの登録およびサブスクリプション情報が含まれます。このファイルにより、お使いのシステムを Red Hat カスタマーポータルまたは Red Hat Satellite Server のいずれかに登録します。

/home/stack/containers-prepare-parameter.yaml

ソースおよび準備の手順が含まれるファイルです。これは、アンダークラウドのアップグレードに使用するファイルと同じです。

/usr/share/openstack-tripleo-heat-templates/environments/services/neutron-ovs.yaml

OpenStack Platform 16.2 では、デフォルトのネットワークバックエンドとして Open Virtual Network (OVN) が使用されます。しかし、OpenStack Platform 13 では Open vSwitch (OVS) が使用されていました。アップグレード中に OVS との互換性を維持するために、このファイルを追加します。OpenStack Platform 16.2 のドキュメントには、アップグレード後に OVS から OVN に移行するための手順が記載されています。

以下のコマンドを実行する際に、環境ファイル一覧の最後にこれらのファイルを追加します。

  • openstack overcloud upgrade prepare
  • openstack overcloud upgrade converge
  • openstack overcloud deploy

16.3. デプロイメントから削除する環境ファイル

OpenStack Platform Red Hat OpenStack Platform 13 に固有の環境ファイルをすべて削除します。

  • Red Hat OpenStack Platform 13 のコンテナーイメージ一覧
  • Red Hat OpenStack Platform 13 のカスタマーポータルまたは Satellite 用 rhel-registration スクリプト

以下のコマンドを実行する際に指定する環境ファイルの一覧から、これらのファイルを削除します。

  • openstack overcloud upgrade prepare
  • openstack overcloud upgrade converge
  • openstack overcloud deploy

16.4. アップグレードのチェックリスト

以下のチェックリストを使用して、オーバークラウドをアップグレードする準備ができているかどうかを判断します。

確認項目実施状況

動作中のオーバークラウドを検証した。

はい / いいえ

オーバークラウドコントロールプレーンの Relax-and-Recover (ReaR) バックアップを実施した。詳しくは、『Red Hat OpenStack Platform 13 Undercloud and Control Plane Back Up and Restore』を参照してください。

はい / いいえ

アンダークラウドノードで実行されるデータベースのバックアップを作成している。詳細は、『Red Hat OpenStack Platform 16.2 Backing up and restoring the undercloud and control plane nodes』「Creating a database backup of the undercloud node」を参照してください。

はい / いいえ

以下の項目を含め、Leapp に関するすべての準備を実施した。

  • Leapp 環境ファイル
  • すべてのオーバークラウドノードで予測可能な NIC 名が使用されている。

はい / いいえ

登録情報を Red Hat OpenStack Platform 16.2 リポジトリーに更新し、Ansible ベースの手法を使用するように環境ファイルを変更した。

はい / いいえ

ネットワーク設定テンプレートを更新した。

はい / いいえ

環境ファイルの一覧を Red Hat OpenStack Platform 16.2 用の新しい環境ファイルで更新した。

はい / いいえ

(オプション) デプロイメントに専用の Object Storage (swift)ノードが含まれている場合。

roles_data.yaml ファイルをコピーし、deprecated_server_resource_name: 'SwiftStorage' を削除し、そのファイルを openstack overcloud upgrade prepare または openstack overcloud upgrade converge コマンドに渡します。

はい / いいえ

古い Red Hat 登録やコンテナーイメージの場所に関するファイルなど、Red Hat OpenStack Platform 13 にしか該当しない古い環境ファイルを削除した。

はい / いいえ

第17章 アップグレードコマンドの概要

アップグレードプロセスでは、プロセスの特定の段階で異なるコマンドを実行します。

重要

本セクションでは、それぞれのコマンドについてのみ説明します。これらのコマンドは特定の順序で実行し、オーバークラウドに固有のオプションを指定する必要があります。適切なステップでこれらのコマンドを実行するよう指示されるまで待ちます。

17.1. openstack overcloud upgrade prepare

このコマンドにより、オーバークラウドのアップグレードの初期準備のステップが実行されます。これには、アンダークラウド上の現在のオーバークラウドプランを新しい OpenStack Platform 16.2 オーバークラウドプランおよび更新された環境ファイルに置き換えることが含まれます。このコマンドは、openstack overcloud deploy コマンドと同じように機能し、多くの同一オプションが使用されます。

17.2. openstack overcloud upgrade run

このコマンドにより、アップグレードプロセスが実施されます。director は、新しい OpenStack Platform 16.2 オーバークラウドプランに基づいて Ansible Playbook のセットを作成し、オーバークラウド全体で Fast Forward タスクを実行します。これには、OpenStack Platform の 13 から 16.2 までの各バージョンでアップグレードプロセスを実行することが含まれます。

標準のアップグレードプロセスに加えて、このコマンドによりオーバークラウドノード上のオペレーティングシステムの Leapp アップグレードを実施することができます。--tags オプションを使用して、これらのタスクを実行します。

Leapp のアップグレードタスクタグ

system_upgrade
system_upgrade_preparesystem_upgrade_run、および system_upgrade_reboot のタスクを組み合わせるタスク
system_upgrade_prepare
Leapp を使用したオペレーティングシステムのアップグレードに向けた準備を行うタスク
system_upgrade_run
Leapp を実行し、オペレーティングシステムをアップグレードするタスク
system_upgrade_reboot
システムをリブートし、オペレーティングシステムのアップグレードを完了するタスク

ワークロード移行のアップグレードタスクタグ

nova_hybrid_state
アップグレード中のワークロードの移行を円滑に行うために、コンピュートノード上に一時的な OpenStack Platform 16.2 コンテナーをセットアップするタスク

17.3. openstack overcloud external-upgrade run

このコマンドにより、標準のアップグレードプロセス以外のアップグレードタスクが実行されます。director は新しい OpenStack Platform 16.2 オーバークラウドプランに基づいて Ansible Playbook のセットを作成するので、--tags オプションを使用して特定のタスクを実行します。

コンテナー管理の外部タスクタグ

container_image_prepare
アンダークラウドレジストリーにコンテナーイメージをプルし、オーバークラウドが使用するようにイメージを準備するタスク

Ceph Storage アップグレードの外部タスクタグ

  • director を使用してデプロイされた Red Hat Ceph Storage クラスターがデプロイメントで使用される場合は、以下のタグを使用することができます。

    ceph
    ceph-ansible Playbook を使用して Red Hat Ceph Storage をインストールするタスク
    ceph_systemd
    podman 管理を使用するために、Red Hat Ceph Storage の systemd ユニットファイルを変換するタスク
  • 外部の Ceph デプロイメントと共にアップグレードする場合は、ceph および ceph_systemd タグを使用するタスクを省略することができます。

データベース移行の外部タスクタグ

system_upgrade_cleanup
system_upgrade_transfer_data タスクに関連するストレージディレクトリーを消去するタスク
system_upgrade_stop_services
すべてのサービスをシャットダウンするタスク
system_upgrade_transfer_data
すべてのサービスをシャットダウンし、ブートストラップノードへのデータベース移行を実施するタスク

17.4. openstack overcloud upgrade converge

このコマンドにより、オーバークラウドのアップグレードの最終ステップが実施されます。この最終ステップでは、オーバークラウドの heat スタックを OpenStack Platform 16.2 のオーバークラウドプランおよび更新された環境ファイルと同期します。このプロセスにより、作成されるオーバークラウドが新しい OpenStack Platform 16.2 オーバークラウドの設定と一致するようになります。このコマンドは openstack overcloud deploy コマンドと類似していて、多くの同一オプションが使用されます。

17.5. オーバークラウドノードのアップグレードワークフロー

各オーバークラウドノードでアップグレードを実施する場合、以下の要素を考慮して、アップグレードの各段階で実行する正しいコマンドを判断する必要があります。

コントローラーサービス

  • ノードに Pacemaker サービスが含まれているか?データベースの移行を開始し、Red Hat OpenStack 13 から 16.2 へのアップグレード時の移行を円滑に行うために一時コンテナーを起動するためには、まずブートストラップノードをアップグレードする必要があります。ブートストラップコントローラーノードのアップグレードプロセス中、新しい Pacemaker クラスターが作成され、新しい Red Hat OpenStack 16.2 コンテナーがノードで起動します。一方、残りのコントローラーノードは Red Hat OpenStack 13 で稼働を続けます。ブートストラップノードをアップグレードしたら、Pacemaker サービスが含まれるその他のノードをアップグレードし、ブートストラップノードで起動した新しい Pacemaker クラスターに各ノードが参加するようにしなければなりません。Pacemaker が含まれない split-service コントローラーノードをアップグレードするプロセスでは、これらの追加手順は必要ありません。

Compute サービス

  • ノードがコンピュートノードか?ノードに Compute サービスが含まれる場合、そのノードから仮想マシンを移行して最大限の可用性を確保する必要があります。ここで言うコンピュートノードには、仮想マシンをホストするためのあらゆるノードが含まれます。この定義には、以下のコンピュートノード種別が含まれます。

    • 通常のコンピュートノード
    • ハイパーコンバージドインフラストラクチャー (HCI) を持つコンピュートノード
    • Data Plane Development Kit (DPDK) または Single Root Input/Output Virtualization (SR-IOV) 等のネットワーク機能仮想化技術を使用するコンピュートノード
    • リアルタイムコンピュートノード

Ceph Storage サービス

  • ノードに Ceph Storage サービスが含まれているか?docker ではなく podman を使用するために、ノード上のコンテナー化された Ceph Storage サービスの systemd ユニットファイルを変換する必要があります。以下のノード種別がこれに該当します。

    • Ceph Storage OSD ノード
    • Ceph MON サービスが含まれるコントローラーノード
    • Split-Controller Ceph MON ノード
    • ハイパーコンバージドインフラストラクチャー (HCI) を持つコンピュートノード

ワークフロー

以下のワークフロー図を使用して、特定ノードの正しい更新パスを特定します。

第18章 標準的なオーバークラウドのアップグレード

このシナリオでは、標準的なオーバークラウド環境のアップグレードプロセスの例を説明します。この環境には、以下のノード種別が含まれます。

  • コントローラーノード 3 台
  • Ceph Storage ノード 3 台
  • 複数のコンピュートノード

18.1. オーバークラウドアップグレード準備タスクの実行

アップグレードを行うには、openstack overcloud upgrade prepare コマンドを実行する必要があります。このコマンドにより、以下のタスクが実行されます。

  • オーバークラウドのプランを OpenStack Platform 16.2 に更新する。
  • アップグレードに向けてノードを準備する。
注記

デフォルトのスタック名 (overcloud) を使用していない場合は、--stack STACK NAME オプションでスタック名を設定します。STACK NAME は実際のスタック名に置き換えます。

手順

  1. stackrc ファイルを取得します。

    $ source ~/stackrc
  2. upgrade prepare コマンドを実行します。

    $ openstack overcloud upgrade prepare \
        --stack STACK NAME \
        --templates \
        -e ENVIRONMENT FILE
        …​
        -e /home/stack/templates/upgrades-environment.yaml \
        -e /home/stack/templates/rhsm.yaml \
        -e /home/stack/containers-prepare-parameter.yaml \
        -e /usr/share/openstack-tripleo-heat-templates/environments/services/neutron-ovs.yaml \
        …​

    以下のオプションの中で、お使いの環境に適切なオプションを追加します。

    • アップグレード固有のパラメーターが含まれる環境ファイル (upgrades-environment.yaml) (-e)
    • 登録およびサブスクリプションに関するパラメーターが含まれる環境ファイル (rhsm.yaml) (-e)
    • 新しいコンテナーイメージの場所を定義した環境ファイル (containers-prepare-parameter.yaml) (-e)。多くの場合、アンダークラウドが使用する環境ファイルと同じファイルです。
    • OVS との互換性を維持するための環境ファイル (neutron-ovs.yaml)
    • デプロイメントに関連するカスタム設定環境ファイル (-e)
    • 該当する場合は、--roles-file でカスタムロール (roles_data) ファイルを指定します。
    • 該当する場合は、--networks-file でコンポーザブルネットワーク (network_data) ファイルを指定します。
    • カスタムのスタック名を使用する場合は、--stack オプションでその名前を渡します。
  3. アップグレードの準備が完了するまで待ちます。
  4. コンテナーイメージをダウンロードします。

    $ openstack overcloud external-upgrade run --stack STACK NAME --tags container_image_prepare

18.2. director でデプロイされた Ceph Storage と組み合わせたコントローラーノードのアップグレード

director を使用してデプロイされた Red Hat Ceph Storage クラスターがデプロイメントで使用される場合は、以下の手順を完了する必要があります。

すべてのコントローラーノードを OpenStack Platform 16.2 にアップグレードする場合は、ブートストラップコントローラーノードからアップグレードを始める必要があります。

ブートストラップコントローラーノードのアップグレードプロセス中、新しい Pacemaker クラスターが作成され、新しい Red Hat OpenStack 16.2 コンテナーがノードで起動します。一方、残りのコントローラーノードは Red Hat OpenStack 13 で稼働を続けます。

ブートストラップノードをアップグレードしたら、Pacemaker サービスが含まれるその他のノードをアップグレードし、ブートストラップノードで起動した新しい Pacemaker クラスターに各ノードが参加するようにしなければなりません。詳細は、「オーバークラウドノードのアップグレードワークフロー」を参照してください。

以下の例では、コントローラーノードの名前はデフォルトの overcloud-controller-NODEID 命名規則を使用して名前を付けています。これには、以下の 3 つのコントローラーノードが含まれます。

  • overcloud-controller-0
  • overcloud-controller-1
  • overcloud-controller-2

これらの値は、該当する実際のノード名に置き換てください。

注記

デフォルトのスタック名 (overcloud) を使用していない場合は、--stack STACK NAME オプションでスタック名を設定します。STACK NAME は実際のスタック名に置き換えます。

手順

  1. stackrc ファイルを取得します。

    $ source ~/stackrc
  2. コントローラーノードで以下のコマンドを実行し、ブートストラップコントローラーノードを特定します。

    $ sudo hiera -c /etc/puppet/hiera.yaml pacemaker_short_bootstrap_node_name

    アンダークラウドからこのコマンドを実行するには、以下の SSH コマンドを実行します。ここで、CONTROLLER_IP は環境内の任意のコントローラーノードの IP アドレスに置き換えます。

    $ ssh heat-admin@CONTROLLER_IP "sudo hiera -c /etc/puppet/hiera.yaml pacemaker_short_bootstrap_node_name"

    以下の例では、overcloud-controller-0 をブートストラップノードの値として使用します。これを実際のブートストラップノードの値に置き換えてください。

  3. ブートストラップコントローラーノードをアップグレードします。

    1. ceph_systemd タグを指定して外部アップグレードコマンドを実行します。

      $ openstack overcloud external-upgrade run --stack STACK NAME --tags ceph_systemd -e ceph_ansible_limit=overcloud-controller-0

      このコマンドにより、以下の操作が行われます。

      • Podman 管理を使用するために、Ceph Storage コンテナーを制御する systemd ユニットを変更する。
      • ceph_ansible_limit 変数を使用して、アクションを選択したコントローラーノードに制限する。

      このステップは、leapp によるアップグレードに向けて Ceph Storage サービスを準備するための予備的な処置です。

    2. system_upgrade タグを指定してアップグレードコマンドを実行します。

      $ openstack overcloud upgrade run --stack STACK NAME --tags system_upgrade --limit overcloud-controller-0

      このコマンドにより、以下のアクションが行われます。

      • Leapp によるオペレーティングシステムのアップグレードを実施する。
      • Leapp によるアップグレードの一部としてリブートを実施する。

        重要

        次のコマンドにより、コントロールプレーンで機能停止が生じます。これ以降の数ステップを実施している間は、標準的なオーバークラウド操作を行うことはできません。

    3. system_upgrade_transfer_data タグを指定して外部アップグレードコマンドを実行します。

      $ openstack overcloud external-upgrade run --stack STACK NAME --tags system_upgrade_transfer_data

      このコマンドにより、最新バージョンのデータベースが既存のノードからブートストラップノードにコピーされます。

    4. nova_hybrid_state タグを指定してアップグレードコマンドを実行し、upgrade_steps_playbook.yaml Playbook だけを実行します。

      $ openstack overcloud upgrade run --stack STACK NAME --playbook upgrade_steps_playbook.yaml --tags nova_hybrid_state --limit all

      このコマンドにより、コンピュートノード上の一時的な 16.2 コンテナーが起動します。これにより、後のステップでコンピュートノードをアップグレードする際に、ワークロードの移行が円滑に行われます。

    5. タグを指定せずにアップグレードコマンドを実行します。

      $ openstack overcloud upgrade run --stack STACK NAME --limit overcloud-controller-0

      このコマンドにより、Red Hat OpenStack Platform のアップグレードが実施されます。

      重要

      このコマンドの処理が完了すると、コントロールプレーンがアクティブになります。再び標準的なオーバークラウド操作を実施することができます。

    6. アップグレード後に新しい Pacemaker クラスターが起動していること、および galera、rabbit、haproxy、redis 等のコントロールプレーンサービスが実行中であることを確認します。

      $ sudo pcs status
  4. 次のコントローラーノードをアップグレードします。

    1. 古いクラスターが実行されなくなったことを確認します。

      $ sudo pcs status

      クラスターが実行されていない場合、以下のようなエラーが表示されます。

      Error: cluster is not currently running on this node
    2. ceph_systemd タグを指定して外部アップグレードコマンドを実行します。

      $ openstack overcloud external-upgrade run --stack STACK NAME --tags ceph_systemd -e ceph_ansible_limit=overcloud-controller-1

      このコマンドにより、以下の操作が行われます。

      • Podman 管理を使用するために、Ceph Storage コンテナーを制御する systemd ユニットを変更する。
      • ceph_ansible_limit 変数を使用して、アクションを選択したコントローラーノードに制限する。

      このステップは、leapp によるアップグレードに向けて Ceph Storage サービスを準備するための予備的な処置です。

    3. 次のコントローラーノードで、system_upgrade タグを指定してアップグレードコマンドを実行します。

      $ openstack overcloud upgrade run --stack STACK NAME --tags system_upgrade --limit overcloud-controller-1

      このコマンドにより、以下のアクションが行われます。

      • Leapp によるオペレーティングシステムのアップグレードを実施する。
      • Leapp によるアップグレードの一部としてリブートを実施する。
    4. タグを指定せずにアップグレードコマンドを実行します。

      $ openstack overcloud upgrade run --stack STACK NAME --limit overcloud-controller-0,overcloud-controller-1

      このコマンドにより、Red Hat OpenStack Platform のアップグレードが実施されます。このノードに加えて、前のステップでアップグレードしたブートストラップノードを --limit オプションに含めます。

  5. 最後のコントローラーノードをアップグレードします。

    1. 古いクラスターが実行されなくなったことを確認します。

      $ sudo pcs status

      クラスターが実行されていない場合、以下のようなエラーが表示されます。

      Error: cluster is not currently running on this node
    2. ceph_systemd タグを指定して外部アップグレードコマンドを実行します。

      $ openstack overcloud external-upgrade run --stack STACK NAME --tags ceph_systemd -e ceph_ansible_limit=overcloud-controller-2

      このコマンドにより、以下の操作が行われます。

      • Podman 管理を使用するために、Ceph Storage コンテナーを制御する systemd ユニットを変更する。
      • ceph_ansible_limit 変数を使用して、アクションを選択したコントローラーノードに制限する。

      このステップは、leapp によるアップグレードに向けて Ceph Storage サービスを準備するための予備的な処置です。

    3. system_upgrade タグを指定してアップグレードコマンドを実行します。

      $ openstack overcloud upgrade run --stack STACK NAME --tags system_upgrade --limit overcloud-controller-2

      このコマンドにより、以下のアクションが行われます。

      • Leapp によるオペレーティングシステムのアップグレードを実施する。
      • Leapp によるアップグレードの一部としてリブートを実施する。
    4. タグを指定せずにアップグレードコマンドを実行します。

      $ openstack overcloud upgrade run --stack STACK NAME --limit overcloud-controller-0,overcloud-controller-1,overcloud-controller-2

      このコマンドにより、Red Hat OpenStack Platform のアップグレードが実施されます。--limit オプションにすべてのコントローラーノードを含めます。

18.3. Ceph Storage ノードのオペレーティングシステムのアップグレード

director を使用してデプロイされた Red Hat Ceph Storage クラスターがデプロイメントで使用される場合は、各 Ceph Storage ノードのオペレーティングシステムをアップグレードする必要があります。

注記

デフォルトのスタック名 (overcloud) を使用していない場合は、--stack STACK NAME オプションでスタック名を設定します。STACK NAME は実際のスタック名に置き換えます。

手順

  1. stackrc ファイルを取得します。

    $ source ~/stackrc
  2. Ceph Storage ノードを選択し、オペレーティングシステムをアップグレードします。

    1. ceph_systemd タグを指定して外部アップグレードコマンドを実行します。

      $ openstack overcloud external-upgrade run --stack STACK NAME --tags ceph_systemd -e ceph_ansible_limit=overcloud-cephstorage-0

      このコマンドにより、以下の操作が行われます。

      • Podman 管理を使用するために、Ceph Storage コンテナーを制御する systemd ユニットを変更する。
      • ceph_ansible_limit 変数を使用して、アクションを選択したノードに制限する。

      このステップは、leapp によるアップグレードに向けて Ceph Storage サービスを準備するための予備的な処置です。

    2. system_upgrade タグを指定してアップグレードコマンドを実行します。

      $ openstack overcloud upgrade run --stack STACK NAME --tags system_upgrade --limit overcloud-cephstorage-0

      このコマンドにより、以下のアクションが行われます。

      • Leapp によるオペレーティングシステムのアップグレードを実施する。
      • Leapp によるアップグレードの一部としてリブートを実施する。
    3. タグを指定せずにアップグレードコマンドを実行します。

      $ openstack overcloud upgrade run --stack STACK NAME --limit overcloud-cephstorage-0

      このコマンドにより config-download Playbook が実行され、Ceph Storage ノードでコンポーザブルサービスが設定されます。このステップでは、Ceph Storage ノードは Red Hat Ceph Storage 4 にアップグレードされません。Red Hat Ceph Storage 4 へのアップグレードは、後の手順で実施されます。

  3. 次の Ceph Storage ノードを選択し、オペレーティングシステムをアップグレードします。

    1. ceph_systemd タグを指定して外部アップグレードコマンドを実行します。

      $ openstack overcloud external-upgrade run --stack STACK NAME --tags ceph_systemd -e ceph_ansible_limit=overcloud-cephstorage-1

      このコマンドにより、以下の操作が行われます。

      • Podman 管理を使用するために、Ceph Storage コンテナーを制御する systemd ユニットを変更する。
      • ceph_ansible_limit 変数を使用して、アクションを選択したノードに制限する。

      このステップは、leapp によるアップグレードに向けて Ceph Storage サービスを準備するための予備的な処置です。

    2. system_upgrade タグを指定してアップグレードコマンドを実行します。

      $ openstack overcloud upgrade run --stack STACK NAME --tags system_upgrade --limit overcloud-cephstorage-1

      このコマンドにより、以下のアクションが行われます。

      • Leapp によるオペレーティングシステムのアップグレードを実施する。
      • Leapp によるアップグレードの一部としてリブートを実施する。
    3. タグを指定せずにアップグレードコマンドを実行します。

      $ openstack overcloud upgrade run --stack STACK NAME --limit overcloud-cephstorage-1

      このコマンドにより config-download Playbook が実行され、Ceph Storage ノードでコンポーザブルサービスが設定されます。このステップでは、Ceph Storage ノードは Red Hat Ceph Storage 4 にアップグレードされません。Red Hat Ceph Storage 4 へのアップグレードは、後の手順で実施されます。

  4. 最後の Ceph Storage ノードを選択し、オペレーティングシステムをアップグレードします。

    1. ceph_systemd タグを指定して外部アップグレードコマンドを実行します。

      $ openstack overcloud external-upgrade run --stack STACK NAME --tags ceph_systemd -e ceph_ansible_limit=overcloud-cephstorage-2

      このコマンドにより、以下の操作が行われます。

      • Podman 管理を使用するために、Ceph Storage コンテナーを制御する systemd ユニットを変更する。
      • ceph_ansible_limit 変数を使用して、アクションを選択したノードに制限する。

      このステップは、leapp によるアップグレードに向けて Ceph Storage サービスを準備するための予備的な処置です。

    2. system_upgrade タグを指定してアップグレードコマンドを実行します。

      $ openstack overcloud upgrade run --stack STACK NAME --tags system_upgrade --limit overcloud-cephstorage-2

      このコマンドにより、以下のアクションが行われます。

      • Leapp によるオペレーティングシステムのアップグレードを実施する。
      • Leapp によるアップグレードの一部としてリブートを実施する。
    3. タグを指定せずにアップグレードコマンドを実行します。

      $ openstack overcloud upgrade run --stack STACK NAME --limit overcloud-cephstorage-2

      このコマンドにより config-download Playbook が実行され、Ceph Storage ノードでコンポーザブルサービスが設定されます。このステップでは、Ceph Storage ノードは Red Hat Ceph Storage 4 にアップグレードされません。Red Hat Ceph Storage 4 へのアップグレードは、後の手順で実施されます。

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

すべてのコンピュートノードを OpenStack Platform 16.2 にアップグレードします。

注記

デフォルトのスタック名 (overcloud) を使用していない場合は、--stack STACK NAME オプションでスタック名を設定します。STACK NAME は実際のスタック名に置き換えます。

手順

  1. stackrc ファイルを取得します。

    $ source ~/stackrc
  2. インスタンスを移行します。移行計画についての詳細は、「Migrating virtual machines between Compute nodes」を参照してください。
  3. system_upgrade タグを指定してアップグレードコマンドを実行します。

    $ openstack overcloud upgrade run --stack STACK NAME --tags system_upgrade --limit overcloud-compute-0

    このコマンドにより、以下のアクションが行われます。

    • Leapp によるオペレーティングシステムのアップグレードを実施する。
    • Leapp によるアップグレードの一部としてリブートを実施する。
  4. タグを指定せずにアップグレードコマンドを実行します。

    $ openstack overcloud upgrade run --stack STACK NAME --limit overcloud-compute-0

    このコマンドにより、Red Hat OpenStack Platform のアップグレードが実施されます。

  5. 複数のコンピュートノードを並行してアップグレードするには、--limit オプションをアップグレードするノードのコンマ区切りリストに設定します。まず system_upgrade タスクを実行します。

    $ openstack overcloud upgrade run --stack STACK NAME --tags system_upgrade --limit overcloud-compute-0,overcloud-compute-1,overcloud-compute-2

    続いて、標準の OpenStack サービスのアップグレードを実施します。

    $ openstack overcloud upgrade run --stack STACK NAME  --limit overcloud-compute-0,overcloud-compute-1,overcloud-compute-2

18.5. オーバークラウドスタックの同期

アップグレードにおいては、スタックのリソース構造およびパラメーターが OpenStack Platform 16.2 の新規デプロイメントと整合するように、オーバークラウドスタックを更新する必要があります。

注記

デフォルトのスタック名 (overcloud) を使用していない場合は、--stack STACK NAME オプションでスタック名を設定します。STACK NAME は実際のスタック名に置き換えます。

手順

  1. stackrc ファイルを取得します。

    $ source ~/stackrc
  2. containers-prepare-parameter.yaml ファイルを編集し、以下のパラメーターおよびその値を削除します。

    • ceph3_namespace
    • ceph3_tag
    • ceph3_image
    • name_prefix_stein
    • name_suffix_stein
    • namespace_stein
    • tag_stein
  3. アップグレードの最終処理コマンドを実行します。

    $ openstack overcloud upgrade converge \
        --stack STACK NAME \
        --templates \
        -e ENVIRONMENT FILE
        …​
        -e /home/stack/templates/upgrades-environment.yaml \
        -e /home/stack/templates/rhsm.yaml \
        -e /home/stack/containers-prepare-parameter.yaml \
        -e /usr/share/openstack-tripleo-heat-templates/environments/services/neutron-ovs.yaml \
        …​

    以下のオプションの中で、お使いの環境に適切なオプションを追加します。

    • アップグレード固有のパラメーターが含まれる環境ファイル (upgrades-environment.yaml) (-e)
    • 登録およびサブスクリプションに関するパラメーターが含まれる環境ファイル (rhsm.yaml) (-e)
    • 新しいコンテナーイメージの場所を定義した環境ファイル (containers-prepare-parameter.yaml) (-e)。多くの場合、アンダークラウドが使用する環境ファイルと同じファイルです。
    • OVS との互換性を維持するための環境ファイル (neutron-ovs.yaml)
    • デプロイメントに関連するカスタム設定環境ファイル (-e)
    • 該当する場合は、--roles-file でカスタムロール (roles_data) ファイルを指定します。
    • 該当する場合は、--networks-file でコンポーザブルネットワーク (network_data) ファイルを指定します。
    • カスタムのスタック名を使用する場合は、--stack オプションでその名前を渡します。
  4. スタックの同期が完了するまで待ちます。
重要

これ以降のデプロイメント操作には、upgrades-environment.yaml ファイルは必要ありません。

第19章 外部の Ceph デプロイメントと組み合わせたオーバークラウドのアップグレード

このシナリオでは、外部の Ceph デプロイメントと組み合わせたオーバークラウド環境のアップグレードプロセスの例を説明します。この環境には、以下のノード種別が含まれます。

  • コントローラーノード 3 台
  • 外部の Ceph Storage クラスター
  • 複数のコンピュートノード

19.1. オーバークラウドアップグレード準備タスクの実行

アップグレードを行うには、openstack overcloud upgrade prepare コマンドを実行する必要があります。このコマンドにより、以下のタスクが実行されます。

  • オーバークラウドのプランを OpenStack Platform 16.2 に更新する。
  • アップグレードに向けてノードを準備する。
注記

デフォルトのスタック名 (overcloud) を使用していない場合は、--stack STACK NAME オプションでスタック名を設定します。STACK NAME は実際のスタック名に置き換えます。

手順

  1. stackrc ファイルを取得します。

    $ source ~/stackrc
  2. upgrade prepare コマンドを実行します。

    $ openstack overcloud upgrade prepare \
        --stack STACK NAME \
        --templates \
        -e ENVIRONMENT FILE
        …​
        -e /home/stack/templates/upgrades-environment.yaml \
        -e /home/stack/templates/rhsm.yaml \
        -e /home/stack/containers-prepare-parameter.yaml \
        -e /usr/share/openstack-tripleo-heat-templates/environments/services/neutron-ovs.yaml \
        …​

    以下のオプションの中で、お使いの環境に適切なオプションを追加します。

    • アップグレード固有のパラメーターが含まれる環境ファイル (upgrades-environment.yaml) (-e)
    • 登録およびサブスクリプションに関するパラメーターが含まれる環境ファイル (rhsm.yaml) (-e)
    • 新しいコンテナーイメージの場所を定義した環境ファイル (containers-prepare-parameter.yaml) (-e)。多くの場合、アンダークラウドが使用する環境ファイルと同じファイルです。
    • OVS との互換性を維持するための環境ファイル (neutron-ovs.yaml)
    • デプロイメントに関連するカスタム設定環境ファイル (-e)
    • 該当する場合は、--roles-file でカスタムロール (roles_data) ファイルを指定します。
    • 該当する場合は、--networks-file でコンポーザブルネットワーク (network_data) ファイルを指定します。
    • カスタムのスタック名を使用する場合は、--stack オプションでその名前を渡します。
  3. アップグレードの準備が完了するまで待ちます。
  4. コンテナーイメージをダウンロードします。

    $ openstack overcloud external-upgrade run --stack STACK NAME --tags container_image_prepare

19.2. 外部の Ceph デプロイメントと組み合わせたコントローラーノードのアップグレード

外部の Ceph デプロイメントと共にアップグレードする場合は、以下の手順を完了する必要があります。

すべてのコントローラーノードを OpenStack Platform 16.2 にアップグレードする場合は、ブートストラップコントローラーノードからアップグレードを始める必要があります。

ブートストラップコントローラーノードのアップグレードプロセス中、新しい Pacemaker クラスターが作成され、新しい Red Hat OpenStack 16.2 コンテナーがノードで起動します。一方、残りのコントローラーノードは Red Hat OpenStack 13 で稼働を続けます。

ブートストラップノードをアップグレードしたら、Pacemaker サービスが含まれるその他のノードをアップグレードし、ブートストラップノードで起動した新しい Pacemaker クラスターに各ノードが参加するようにしなければなりません。詳細は、「オーバークラウドノードのアップグレードワークフロー」を参照してください。

以下の例では、コントローラーノードの名前はデフォルトの overcloud-controller-NODEID 命名規則を使用して名前を付けています。これには、以下の 3 つのコントローラーノードが含まれます。

  • overcloud-controller-0
  • overcloud-controller-1
  • overcloud-controller-2

これらの値は、該当する実際のノード名に置き換てください。

注記

デフォルトのスタック名 (overcloud) を使用していない場合は、--stack STACK NAME オプションでスタック名を設定します。STACK NAME は実際のスタック名に置き換えます。

手順

  1. stackrc ファイルを取得します。

    $ source ~/stackrc
  2. コントローラーノードで以下のコマンドを実行し、ブートストラップコントローラーノードを特定します。

    $ sudo hiera -c /etc/puppet/hiera.yaml pacemaker_short_bootstrap_node_name

    アンダークラウドからこのコマンドを実行するには、以下の SSH コマンドを実行します。ここで、CONTROLLER_IP は環境内の任意のコントローラーノードの IP アドレスに置き換えます。

    $ ssh heat-admin@CONTROLLER_IP "sudo hiera -c /etc/puppet/hiera.yaml pacemaker_short_bootstrap_node_name"

    以下の例では、overcloud-controller-0 をブートストラップノードの値として使用します。これを実際のブートストラップノードの値に置き換えてください。

  3. ブートストラップコントローラーノードをアップグレードします。

    1. system_upgrade タグを指定してアップグレードコマンドを実行します。

      $ openstack overcloud upgrade run --stack STACK NAME --tags system_upgrade --limit overcloud-controller-0

      このコマンドにより、以下のアクションが行われます。

      • Leapp によるオペレーティングシステムのアップグレードを実施する。
      • Leapp によるアップグレードの一部としてリブートを実施する。

        重要

        次のコマンドにより、コントロールプレーンで機能停止が生じます。これ以降の数ステップを実施している間は、標準的なオーバークラウド操作を行うことはできません。

    2. system_upgrade_transfer_data タグを指定して外部アップグレードコマンドを実行します。

      $ openstack overcloud external-upgrade run --stack STACK NAME --tags system_upgrade_transfer_data

      このコマンドにより、最新バージョンのデータベースが既存のノードからブートストラップノードにコピーされます。

    3. nova_hybrid_state タグを指定してアップグレードコマンドを実行し、upgrade_steps_playbook.yaml Playbook だけを実行します。

      $ openstack overcloud upgrade run --stack STACK NAME --playbook upgrade_steps_playbook.yaml --tags nova_hybrid_state --limit all

      このコマンドにより、コンピュートノード上の一時的な 16.2 コンテナーが起動します。これにより、後のステップでコンピュートノードをアップグレードする際に、ワークロードの移行が円滑に行われます。

    4. タグを指定せずにアップグレードコマンドを実行します。

      $ openstack overcloud upgrade run --stack STACK NAME --limit overcloud-controller-0

      このコマンドにより、Red Hat OpenStack Platform のアップグレードが実施されます。

      重要

      このコマンドの処理が完了すると、コントロールプレーンがアクティブになります。再び標準的なオーバークラウド操作を実施することができます。

    5. アップグレード後に新しい Pacemaker クラスターが起動していること、および galera、rabbit、haproxy、redis 等のコントロールプレーンサービスが実行中であることを確認します。

      $ sudo pcs status
  4. 次のコントローラーノードをアップグレードします。

    1. 古いクラスターが実行されなくなったことを確認します。

      $ sudo pcs status

      クラスターが実行されていない場合、以下のようなエラーが表示されます。

      Error: cluster is not currently running on this node
    2. 次のコントローラーノードで、system_upgrade タグを指定してアップグレードコマンドを実行します。

      $ openstack overcloud upgrade run --stack STACK NAME --tags system_upgrade --limit overcloud-controller-1

      このコマンドにより、以下のアクションが行われます。

      • Leapp によるオペレーティングシステムのアップグレードを実施する。
      • Leapp によるアップグレードの一部としてリブートを実施する。
    3. タグを指定せずにアップグレードコマンドを実行します。

      $ openstack overcloud upgrade run --stack STACK NAME --limit overcloud-controller-0,overcloud-controller-1

      このコマンドにより、Red Hat OpenStack Platform のアップグレードが実施されます。このノードに加えて、前のステップでアップグレードしたブートストラップノードを --limit オプションに含めます。

  5. 最後のコントローラーノードをアップグレードします。

    1. 古いクラスターが実行されなくなったことを確認します。

      $ sudo pcs status

      クラスターが実行されていない場合、以下のようなエラーが表示されます。

      Error: cluster is not currently running on this node
    2. system_upgrade タグを指定してアップグレードコマンドを実行します。

      $ openstack overcloud upgrade run --stack STACK NAME --tags system_upgrade --limit overcloud-controller-2

      このコマンドにより、以下のアクションが行われます。

      • Leapp によるオペレーティングシステムのアップグレードを実施する。
      • Leapp によるアップグレードの一部としてリブートを実施する。
    3. タグを指定せずにアップグレードコマンドを実行します。

      $ openstack overcloud upgrade run --stack STACK NAME --limit overcloud-controller-0,overcloud-controller-1,overcloud-controller-2

      このコマンドにより、Red Hat OpenStack Platform のアップグレードが実施されます。--limit オプションにすべてのコントローラーノードを含めます。

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

すべてのコンピュートノードを OpenStack Platform 16.2 にアップグレードします。

注記

デフォルトのスタック名 (overcloud) を使用していない場合は、--stack STACK NAME オプションでスタック名を設定します。STACK NAME は実際のスタック名に置き換えます。

手順

  1. stackrc ファイルを取得します。

    $ source ~/stackrc
  2. インスタンスを移行します。移行計画についての詳細は、「Migrating virtual machines between Compute nodes」を参照してください。
  3. system_upgrade タグを指定してアップグレードコマンドを実行します。

    $ openstack overcloud upgrade run --stack STACK NAME --tags system_upgrade --limit overcloud-compute-0

    このコマンドにより、以下のアクションが行われます。

    • Leapp によるオペレーティングシステムのアップグレードを実施する。
    • Leapp によるアップグレードの一部としてリブートを実施する。
  4. タグを指定せずにアップグレードコマンドを実行します。

    $ openstack overcloud upgrade run --stack STACK NAME --limit overcloud-compute-0

    このコマンドにより、Red Hat OpenStack Platform のアップグレードが実施されます。

  5. 複数のコンピュートノードを並行してアップグレードするには、--limit オプションをアップグレードするノードのコンマ区切りリストに設定します。まず system_upgrade タスクを実行します。

    $ openstack overcloud upgrade run --stack STACK NAME --tags system_upgrade --limit overcloud-compute-0,overcloud-compute-1,overcloud-compute-2

    続いて、標準の OpenStack サービスのアップグレードを実施します。

    $ openstack overcloud upgrade run --stack STACK NAME  --limit overcloud-compute-0,overcloud-compute-1,overcloud-compute-2

19.4. オーバークラウドスタックの同期

アップグレードにおいては、スタックのリソース構造およびパラメーターが OpenStack Platform 16.2 の新規デプロイメントと整合するように、オーバークラウドスタックを更新する必要があります。

注記

デフォルトのスタック名 (overcloud) を使用していない場合は、--stack STACK NAME オプションでスタック名を設定します。STACK NAME は実際のスタック名に置き換えます。

手順

  1. stackrc ファイルを取得します。

    $ source ~/stackrc
  2. containers-prepare-parameter.yaml ファイルを編集し、以下のパラメーターおよびその値を削除します。

    • ceph3_namespace
    • ceph3_tag
    • ceph3_image
    • name_prefix_stein
    • name_suffix_stein
    • namespace_stein
    • tag_stein
  3. アップグレードの最終処理コマンドを実行します。

    $ openstack overcloud upgrade converge \
        --stack STACK NAME \
        --templates \
        -e ENVIRONMENT FILE
        …​
        -e /home/stack/templates/upgrades-environment.yaml \
        -e /home/stack/templates/rhsm.yaml \
        -e /home/stack/containers-prepare-parameter.yaml \
        -e /usr/share/openstack-tripleo-heat-templates/environments/services/neutron-ovs.yaml \
        …​

    以下のオプションの中で、お使いの環境に適切なオプションを追加します。

    • アップグレード固有のパラメーターが含まれる環境ファイル (upgrades-environment.yaml) (-e)
    • 登録およびサブスクリプションに関するパラメーターが含まれる環境ファイル (rhsm.yaml) (-e)
    • 新しいコンテナーイメージの場所を定義した環境ファイル (containers-prepare-parameter.yaml) (-e)。多くの場合、アンダークラウドが使用する環境ファイルと同じファイルです。
    • OVS との互換性を維持するための環境ファイル (neutron-ovs.yaml)
    • デプロイメントに関連するカスタム設定環境ファイル (-e)
    • 該当する場合は、--roles-file でカスタムロール (roles_data) ファイルを指定します。
    • 該当する場合は、--networks-file でコンポーザブルネットワーク (network_data) ファイルを指定します。
    • カスタムのスタック名を使用する場合は、--stack オプションでその名前を渡します。
  4. スタックの同期が完了するまで待ちます。
重要

これ以降のデプロイメント操作には、upgrades-environment.yaml ファイルは必要ありません。

第20章 オーバークラウドアップグレードのスピードアップ

オーバークラウドのアップグレードプロセスを迅速化するために、ブートストラップノードから始めてコントロールプレーンの 1/3 を一度にアップグレードできます。

コントロールプレーンの最初の 1/3 のアップグレードが完了したら、コントロールプレーン API が実行され、クラウドが機能している混在モードに環境を移動できます。高可用性の操作パフォーマンスは、コントロールプレーン全体がアップグレードされた後にのみ再開できます。

多数のコンピュートノードをアップグレードする場合は、パフォーマンスを向上させるために、--limit Compute オプションを指定して openstack overcloud upgrade run コマンドを実行し、20 ノードのグループを並行して処理することができます。バックグラウンドで複数のアップグレードタスクを実行できます。この場合、各タスクは 20 ノードの個別のグループをアップグレードします。

このシナリオは、コンポーザブルロールによる以下のノード種別が含まれるオーバークラウド環境のアップグレードプロセスの例です。

  • コントローラーノード 3 台
  • データベースノード 3 台
  • ネットワークノード 3 台
  • Ceph Storage ノード 3 台
  • 複数のコンピュートノード

20.1. オーバークラウドアップグレード準備タスクの実行

アップグレードを行うには、openstack overcloud upgrade prepare コマンドを実行する必要があります。このコマンドにより、以下のタスクが実行されます。

  • オーバークラウドのプランを OpenStack Platform 16.2 に更新する。
  • アップグレードに向けてノードを準備する。
注記

デフォルトのスタック名 (overcloud) を使用していない場合は、--stack STACK NAME オプションでスタック名を設定します。STACK NAME は実際のスタック名に置き換えます。

手順

  1. stackrc ファイルを取得します。

    $ source ~/stackrc
  2. upgrade prepare コマンドを実行します。

    $ openstack overcloud upgrade prepare \
        --stack STACK NAME \
        --templates \
        -e ENVIRONMENT FILE
        …​
        -e /home/stack/templates/upgrades-environment.yaml \
        -e /home/stack/templates/rhsm.yaml \
        -e /home/stack/containers-prepare-parameter.yaml \
        -e /usr/share/openstack-tripleo-heat-templates/environments/services/neutron-ovs.yaml \
        …​

    以下のオプションの中で、お使いの環境に適切なオプションを追加します。

    • アップグレード固有のパラメーターが含まれる環境ファイル (upgrades-environment.yaml) (-e)
    • 登録およびサブスクリプションに関するパラメーターが含まれる環境ファイル (rhsm.yaml) (-e)
    • 新しいコンテナーイメージの場所を定義した環境ファイル (containers-prepare-parameter.yaml) (-e)。多くの場合、アンダークラウドが使用する環境ファイルと同じファイルです。
    • OVS との互換性を維持するための環境ファイル (neutron-ovs.yaml)
    • デプロイメントに関連するカスタム設定環境ファイル (-e)
    • 該当する場合は、--roles-file でカスタムロール (roles_data) ファイルを指定します。
    • 該当する場合は、--networks-file でコンポーザブルネットワーク (network_data) ファイルを指定します。
    • カスタムのスタック名を使用する場合は、--stack オプションでその名前を渡します。
  3. アップグレードの準備が完了するまで待ちます。
  4. コンテナーイメージをダウンロードします。

    $ openstack overcloud external-upgrade run --stack STACK NAME --tags container_image_prepare

20.2. コントロールプレーンノードのアップグレード

環境内のコントロールプレーンノードを OpenStack Platform 16.2 にアップグレードするには、ブートストラップノードから始めてコントロールプレーンノードの 1/3 を一度にアップグレードする必要があります。

ブートストラップコントローラーノードのアップグレードプロセス中、新しい Pacemaker クラスターが作成され、新しい Red Hat OpenStack 16.2 コンテナーがノードで起動します。一方、残りのコントローラーノードは Red Hat OpenStack 13 で稼働を続けます。

以下の例では、コントロールプレーンノードの名前はデフォルトの overcloud-ROLE-NODEID の命名規則を使用して名前を付けています。これには、コンポーザブルロールによる以下のノード種別が含まれます。

  • overcloud-controller-0
  • overcloud-controller-1
  • overcloud-controller-2
  • overcloud-database-0
  • overcloud-database-1
  • overcloud-database-2
  • overcloud-networker-0
  • overcloud-networker-1
  • overcloud-networker-2
  • overcloud-ceph-0
  • overcloud-ceph-1
  • overcloud-ceph-2

これらの値は、該当する実際のノード名に置き換てください。

コントロールプレーンノードの最初の 1/3 を構成する overcloud-controller-0overcloud-database-0overcloud-networker-0 および overcloud-ceph-0 ブートストラップノードをアップグレードした後に、Pacemaker サービスが含まれる追加の各 1/3 のノードのアップグレードを行い、各ノードがブートストラップノードで起動した新規 Pacemaker クラスターに参加するようにする必要があります。したがって、overcloud-controller-2overcloud-database-2overcloud-networker-2 および overcloud-ceph-2 の前に、overcloud-controller-1overcloud-database-1overcloud-networker-1 および overcloud-ceph-1 をアップグレードする必要があります。

注記

デフォルトのスタック名 (overcloud) を使用していない場合は、--stack STACK NAME オプションでスタック名を設定します。STACK NAME は実際のスタック名に置き換えます。

手順

  1. アンダークラウドホストに stack ユーザーとしてログインします。
  2. stackrc ファイルを取得します。

    $ source ~/stackrc
  3. 任意のコントローラーノードで以下のコマンドを実行し、ブートストラップコントローラーノードを特定します。

    $ sudo hiera -c /etc/puppet/hiera.yaml pacemaker_short_bootstrap_node_name

    アンダークラウドノードからブートストラップコントローラーノードを識別することもできます。CONTROLLER_IP は、環境内の任意のコントローラーノードの IP アドレスに置き換えます。

    $ ssh heat-admin@CONTROLLER_IP "sudo hiera -c /etc/puppet/hiera.yaml pacemaker_short_bootstrap_node_name"

    以下の例では、overcloud-controller-0 をブートストラップノードの値として使用します。これを実際のブートストラップノードの値に置き換えてください。

  4. overcloud-controller-0overcloud-database-0overcloud-networker-0、および overcloud-ceph-0 コントロールプレーンノードをアップグレードします。

    1. ceph_systemd タグを指定して外部アップグレードコマンドを実行します。

      $ openstack overcloud external-upgrade run --stack STACK NAME --tags ceph_systemd -e ceph_ansible_limit=overcloud-controller-0,overcloud-database-0,overcloud-networker-0,overcloud-ceph-0

      このコマンドにより、以下のアクションが行われます。

      • Podman 管理を使用するために、Ceph Storage コンテナーを制御する systemd ユニットを変更する。
      • ceph_ansible_limit 変数を使用して、アクションを選択したノードに制限する。

      このステップは、leapp によるアップグレードに向けて Ceph Storage サービスを準備するための予備的な処置です。

    2. system_upgrade タグを指定してアップグレードコマンドを実行します。

      $ openstack overcloud upgrade run --stack STACK NAME --tags system_upgrade --limit overcloud-controller-0 &
      $ openstack overcloud upgrade run --stack STACK NAME --tags system_upgrade --limit overcloud-database-0 &
      $ openstack overcloud upgrade run --stack STACK NAME --tags system_upgrade --limit overcloud-networker-0 &
      $ openstack overcloud upgrade run --stack STACK NAME --tags system_upgrade --limit overcloud-ceph-0 &

      このコマンドにより、以下のアクションが行われます。

      • Leapp によるオペレーティングシステムのアップグレードを実施する。
      • Leapp によるアップグレードの一部としてリブートを実施する。

        重要

        次のコマンドにより、コントロールプレーンで機能停止が生じます。これ以降の数ステップを実施している間は、標準的なオーバークラウド操作を行うことはできません。

    3. system_upgrade_transfer_data タグを指定して外部アップグレードコマンドを実行します。

      $ openstack overcloud external-upgrade run --stack STACK NAME --tags system_upgrade_transfer_data

      このコマンドにより、最新バージョンのデータベースが既存のノードからブートストラップノードにコピーされます。

    4. nova_hybrid_state タグを指定してアップグレードコマンドを実行し、upgrade_steps_playbook.yaml Playbook だけを実行します。

      $ openstack overcloud upgrade run --stack STACK NAME --playbook upgrade_steps_playbook.yaml --tags nova_hybrid_state --limit all

      このコマンドにより、コンピュートノード上の一時的な 16.2 コンテナーが起動します。これにより、後のステップでコンピュートノードをアップグレードする際に、ワークロードの移行が円滑に行われます。

    5. タグを指定せずにアップグレードコマンドを実行します。

      $ openstack overcloud upgrade run --stack STACK NAME --limit overcloud-controller-0,overcloud-database-0,overcloud-networker-0,overcloud-ceph-0 --playbook all

      このコマンドにより、Red Hat OpenStack Platform のアップグレードが実施されます。

      重要

      このコマンドの処理が完了すると、コントロールプレーンがアクティブになります。再び標準的なオーバークラウド操作を実施することができます。

    6. (オプション) ブートストラップコントローラーノードにおいて、アップグレード後に新しい Pacemaker クラスターが起動していること、および galera、rabbit、haproxy、redis 等のコントロールプレーンサービスが実行中であることを確認します。

      $ sudo pcs status
  5. overcloud-controller-1overcloud-database-1overcloud-networker-1、および overcloud-ceph-1 コントロールプレーンノードをアップグレードします。

    1. overcloud-controller-1 ノードにログインし、古いクラスターが実行されなくなったことを確認します。

      $ sudo pcs status

      クラスターが実行されていない場合、以下のようなエラーが表示されます。

      Error: cluster is not currently running on this node
    2. ceph_systemd タグを指定して外部アップグレードコマンドを実行します。

      $ openstack overcloud external-upgrade run --stack STACK NAME --tags ceph_systemd -e ceph_ansible_limit=overcloud-controller-1,overcloud-database-1,overcloud-networker-1,overcloud-ceph-1

      このコマンドにより、以下の操作が行われます。

      • Podman 管理を使用するために、Ceph Storage コンテナーを制御する systemd ユニットを変更する。
      • ceph_ansible_limit 変数を使用して、アクションを選択したノードに制限する。

      このステップは、leapp によるアップグレードに向けて Ceph Storage サービスを準備するための予備的な処置です。

    3. system_upgrade タグを指定してアップグレードコマンドを実行します。

      $ openstack overcloud upgrade run --stack STACK NAME --tags system_upgrade --limit overcloud-controller-1,overcloud-database-1,overcloud-networker-1,overcloud-ceph-1

      このコマンドにより、以下のアクションが行われます。

      • Leapp によるオペレーティングシステムのアップグレードを実施する。
      • Leapp によるアップグレードの一部としてリブートを実施する。
    4. タグを指定せずにアップグレードコマンドを実行します。

      $ openstack overcloud upgrade run --stack STACK NAME --limit overcloud-controller-0,overcloud-controller-1,overcloud-database-0,overcloud-database-1,overcloud-networker-0,overcloud-networker-1,overcloud-ceph-0,overcloud-ceph-1

      このコマンドにより、Red Hat OpenStack Platform のアップグレードが実施されます。このノードに加えて、前のステップでアップグレードしたブートストラップノードを --limit オプションに含めます。

  6. overcloud-controller-2overcloud-database-2overcloud-networker-2、および overcloud-ceph-2 コントロールプレーンノードをアップグレードします。

    1. overcloud-controller-2 ノードにログインし、古いクラスターが実行されなくなったことを確認します。

      $ sudo pcs status

      クラスターが実行されていない場合、以下のようなエラーが表示されます。

      Error: cluster is not currently running on this node
    2. ceph_systemd タグを指定して外部アップグレードコマンドを実行します。

      $ openstack overcloud external-upgrade run --stack STACK NAME --tags ceph_systemd -e ceph_ansible_limit=overcloud-controller-2,overcloud-database-2,overcloud-networker-2,overcloud-ceph-2

      このコマンドにより、以下の操作が行われます。

      • Podman 管理を使用するために、Ceph Storage コンテナーを制御する systemd ユニットを変更する。
      • ceph_ansible_limit 変数を使用して、アクションを選択したノードに制限する。

      このステップは、leapp によるアップグレードに向けて Ceph Storage サービスを準備するための予備的な処置です。

    3. system_upgrade タグを指定してアップグレードコマンドを実行します。

      $ openstack overcloud upgrade run --stack STACK NAME --tags system_upgrade --limit overcloud-controller-2,overcloud-database-2,overcloud-networker-2,overcloud-ceph-2

      このコマンドにより、以下のアクションが行われます。

      • Leapp によるオペレーティングシステムのアップグレードを実施する。
      • Leapp によるアップグレードの一部としてリブートを実施する。
    4. タグを指定せずにアップグレードコマンドを実行します。

      $ openstack overcloud upgrade run --stack STACK NAME --limit overcloud-controller-0,overcloud-controller-1,overcloud-controller-2,overcloud-database-0,overcloud-database-1,overcloud-database-2,overcloud-networker-0,overcloud-networker-1,overcloud-networker-2,overcloud-ceph-0,overcloud-ceph-1,overcloud-ceph-2

      このコマンドにより、Red Hat OpenStack Platform のアップグレードが実施されます。--limit オプションにすべてのコントロールプレーンノードを含めます。

20.3. コンピュートノードの並列アップグレード

多数のコンピュートノードを OpenStack Platform 16.2 にアップグレードする場合は、--limit Compute オプションを指定して openstack overcloud upgrade run コマンドを実行し、20 ノードのグループを並行して処理することができます。

バックグラウンドで複数のアップグレードタスクを実行できます。この場合、各タスクは 20 ノードの個別のグループをアップグレードします。この方法を使用してコンピュートノードを並行してアップグレードする場合は、アップグレードするノードを選択することはできません。ノードの選択は、tripleo-ansible-inventory コマンドの実行時に生成するインベントリーファイルに基づきます。たとえば、デプロイメントに 80 のコンピュートノードがある場合、次のコマンドを実行して、コンピュートノードを並行して更新できます。

$ openstack overcloud upgrade run -y --limit 'Compute[0:19]' > upgrade-compute-00-19.log 2>&1 &
$ openstack overcloud upgrade run -y --limit 'Compute[20:29]' > upgrade-compute-20-29.log 2>&1 &
$ openstack overcloud upgrade run -y --limit 'Compute[40:59]' > update-compute-40-59.log 2>&1 &
$ openstack overcloud upgrade run -y --limit 'Compute[60:79]' > update-compute-60-79.log 2>&1 &

特定のコンピュートノードをアップグレードするには、ノードのコンマ区切りリストを使用します。

$ openstack overcloud upgrade run --limit <Compute0>,<Compute1>,<Compute2>,<Compute3>
注記

デフォルトのスタック名 (overcloud) を使用していない場合は、--stack STACK NAME オプションを使用します。STACK NAME は実際のスタック名に置き換えます。

手順

  1. アンダークラウドホストに stack ユーザーとしてログインします。
  2. stackrc ファイルを取得します。

    $ source ~/stackrc
  3. インスタンスを移行します。移行計画についての詳細は、「Migrating virtual machines between Compute nodes」を参照してください。
  4. system_upgrade タグを指定してアップグレードコマンドを実行します。

    $ openstack overcloud upgrade run -y --stack STACK NAME --tags system_upgrade --limit 'Compute[0:19]' > upgrade-compute-00-19.log 2>&1 &
    $ openstack overcloud upgrade run -y --stack STACK NAME --tags system_upgrade --limit 'Compute[20:29]' > upgrade-compute-20-29.log 2>&1 &
    $ openstack overcloud upgrade run -y --stack STACK NAME --tags system_upgrade --limit 'Compute[40:59]' > update-compute-40-59.log 2>&1 &
    $ openstack overcloud upgrade run -y --stack STACK NAME --tags system_upgrade --limit 'Compute[60:79]' > update-compute-60-79.log 2>&1 &

    このコマンドにより、以下のアクションが行われます。

    • Leapp によるオペレーティングシステムのアップグレードを実施する。
    • Leapp によるアップグレードの一部としてリブートを実施する。
  5. タグを指定せずにアップグレードコマンドを実行します。

    $ openstack overcloud upgrade run -y --stack STACK NAME --limit 'Compute[0:19]' > upgrade-compute-00-19.log 2>&1 &
    $ openstack overcloud upgrade run -y --stack STACK NAME --limit 'Compute[20:29]' > upgrade-compute-20-29.log 2>&1 &
    $ openstack overcloud upgrade run -y --stack STACK NAME --limit 'Compute[40:59]' > update-compute-40-59.log 2>&1 &
    $ openstack overcloud upgrade run -y --stack STACK NAME --limit 'Compute[60:79]' > update-compute-60-79.log 2>&1 &

    このコマンドにより、Red Hat OpenStack Platform のアップグレードが実施されます。

  6. (オプション) 選択したコンピュートノードをアップグレードするには、アップグレードするノードのコンマ区切りリストと共に --limit オプションを使用します。以下の例では、overcloud-compute-0overcloud-compute-1overcloud-compute-2 ノードを並行してアップグレードします。

    1. system_upgrade タグを指定してアップグレードコマンドを実行します。

      $ openstack overcloud upgrade run --stack STACK NAME --tags system_upgrade --limit overcloud-compute-0,overcloud-compute-1,overcloud-compute-2
    2. タグを指定せずにアップグレードコマンドを実行します。

      $ openstack overcloud upgrade run --stack STACK NAME  --limit overcloud-compute-0,overcloud-compute-1,overcloud-compute-2

20.4. オーバークラウドスタックの同期

アップグレードにおいては、スタックのリソース構造およびパラメーターが OpenStack Platform 16.2 の新規デプロイメントと整合するように、オーバークラウドスタックを更新する必要があります。

注記

デフォルトのスタック名 (overcloud) を使用していない場合は、--stack STACK NAME オプションでスタック名を設定します。STACK NAME は実際のスタック名に置き換えます。

手順

  1. stackrc ファイルを取得します。

    $ source ~/stackrc
  2. containers-prepare-parameter.yaml ファイルを編集し、以下のパラメーターおよびその値を削除します。

    • ceph3_namespace
    • ceph3_tag
    • ceph3_image
    • name_prefix_stein
    • name_suffix_stein
    • namespace_stein
    • tag_stein
  3. アップグレードの最終処理コマンドを実行します。

    $ openstack overcloud upgrade converge \
        --stack STACK NAME \
        --templates \
        -e ENVIRONMENT FILE
        …​
        -e /home/stack/templates/upgrades-environment.yaml \
        -e /home/stack/templates/rhsm.yaml \
        -e /home/stack/containers-prepare-parameter.yaml \
        -e /usr/share/openstack-tripleo-heat-templates/environments/services/neutron-ovs.yaml \
        …​

    以下のオプションの中で、お使いの環境に適切なオプションを追加します。

    • アップグレード固有のパラメーターが含まれる環境ファイル (upgrades-environment.yaml) (-e)
    • 登録およびサブスクリプションに関するパラメーターが含まれる環境ファイル (rhsm.yaml) (-e)
    • 新しいコンテナーイメージの場所を定義した環境ファイル (containers-prepare-parameter.yaml) (-e)。多くの場合、アンダークラウドが使用する環境ファイルと同じファイルです。
    • OVS との互換性を維持するための環境ファイル (neutron-ovs.yaml)
    • デプロイメントに関連するカスタム設定環境ファイル (-e)
    • 該当する場合は、--roles-file でカスタムロール (roles_data) ファイルを指定します。
    • 該当する場合は、--networks-file でコンポーザブルネットワーク (network_data) ファイルを指定します。
    • カスタムのスタック名を使用する場合は、--stack オプションでその名前を渡します。
  4. スタックの同期が完了するまで待ちます。
重要

これ以降のデプロイメント操作には、upgrades-environment.yaml ファイルは必要ありません。

第21章 コントローラーが分割されたオーバークラウドのアップグレード

このシナリオでは、コントローラーノードサービスが複数のノードに分割されているオーバークラウドのアップグレードプロセスの例を説明します。この環境には、以下のノード種別が含まれます。

  • Pacemaker を使用する複数に分割された高可用性サービス
  • 複数に分割されたコントローラーサービス
  • Ceph MON ノード 3 台
  • Ceph Storage ノード 3 台
  • 複数のコンピュートノード

21.1. オーバークラウドアップグレード準備タスクの実行

アップグレードを行うには、openstack overcloud upgrade prepare コマンドを実行する必要があります。このコマンドにより、以下のタスクが実行されます。

  • オーバークラウドのプランを OpenStack Platform 16.2 に更新する。
  • アップグレードに向けてノードを準備する。
注記

デフォルトのスタック名 (overcloud) を使用していない場合は、--stack STACK NAME オプションでスタック名を設定します。STACK NAME は実際のスタック名に置き換えます。

手順

  1. stackrc ファイルを取得します。

    $ source ~/stackrc
  2. upgrade prepare コマンドを実行します。

    $ openstack overcloud upgrade prepare \
        --stack STACK NAME \
        --templates \
        -e ENVIRONMENT FILE
        …​
        -e /home/stack/templates/upgrades-environment.yaml \
        -e /home/stack/templates/rhsm.yaml \
        -e /home/stack/containers-prepare-parameter.yaml \
        -e /usr/share/openstack-tripleo-heat-templates/environments/services/neutron-ovs.yaml \
        …​

    以下のオプションの中で、お使いの環境に適切なオプションを追加します。

    • アップグレード固有のパラメーターが含まれる環境ファイル (upgrades-environment.yaml) (-e)
    • 登録およびサブスクリプションに関するパラメーターが含まれる環境ファイル (rhsm.yaml) (-e)
    • 新しいコンテナーイメージの場所を定義した環境ファイル (containers-prepare-parameter.yaml) (-e)。多くの場合、アンダークラウドが使用する環境ファイルと同じファイルです。
    • OVS との互換性を維持するための環境ファイル (neutron-ovs.yaml)
    • デプロイメントに関連するカスタム設定環境ファイル (-e)
    • 該当する場合は、--roles-file でカスタムロール (roles_data) ファイルを指定します。
    • 該当する場合は、--networks-file でコンポーザブルネットワーク (network_data) ファイルを指定します。
    • カスタムのスタック名を使用する場合は、--stack オプションでその名前を渡します。
  3. アップグレードの準備が完了するまで待ちます。
  4. コンテナーイメージをダウンロードします。

    $ openstack overcloud external-upgrade run --stack STACK NAME --tags container_image_prepare

21.2. Pacemaker ベースのノードのアップグレード

Pacemaker サービスをホストする全ノードを OpenStack Platform 16.2 にアップグレードします。以下のロールに Pacemaker ベースのサービスが含まれます。

  • Controller
  • Database (MySQL、Galera)
  • Messaging (RabbitMQ)
  • Load Balancing (HAProxy)
  • 以下のサービスが含まれるその他すべてのロール

    • OS::TripleO::Services::Pacemaker
    • OS::TripleO::Services::PacemakerRemote

このプロセスでは、ブートストラップノードから始めて各ノードをアップグレードします。

注記

デフォルトのスタック名 (overcloud) を使用していない場合は、--stack STACK NAME オプションでスタック名を設定します。STACK NAME は実際のスタック名に置き換えます。

手順

  1. stackrc ファイルを取得します。

    $ source ~/stackrc
  2. コントローラーベースのノードで以下のコマンドを実行し、ブートストラップノードを特定します。

    $ ssh heat-admin@CONTROLLER_IP "sudo hiera -c /etc/puppet/hiera.yaml pacemaker_short_bootstrap_node_name"
  3. ブートストラップノードをアップグレードします。

    1. ノードに Ceph Storage コンテナーが含まれていれば、ceph_systemd タグを指定して外部アップグレードコマンドを実行します。

      $ openstack overcloud external-upgrade run --stack STACK NAME --tags ceph_systemd -e ceph_ansible_limit=overcloud-controller-0

      このコマンドにより、以下の操作が行われます。

      • Podman 管理を使用するために、Ceph Storage コンテナーを制御する systemd ユニットを変更する。
      • ceph_ansible_limit 変数を使用して、アクションを選択したノードに制限する。

      このステップは、leapp によるアップグレードに向けて Ceph Storage サービスを準備するための予備的な処置です。

    2. system_upgrade タグを指定してアップグレードコマンドを実行します。

      $ openstack overcloud upgrade run --stack STACK NAME --tags system_upgrade --limit overcloud-controller-0

      このコマンドにより、以下のアクションが行われます。

      • Leapp によるオペレーティングシステムのアップグレードを実施する。
      • Leapp によるアップグレードの一部としてリブートを実施する。
    3. system_upgrade_transfer_data タグを指定して外部アップグレードコマンドを実行します。

      $ openstack overcloud external-upgrade run --stack STACK NAME --tags system_upgrade_transfer_data

      このコマンドにより、最新バージョンのデータベースが既存のノードからブートストラップノードにコピーされます。

    4. nova_hybrid_state タグを指定してアップグレードコマンドを実行し、upgrade_steps_playbook.yaml Playbook だけを実行します。

      $ openstack overcloud upgrade run --stack STACK NAME --playbook upgrade_steps_playbook.yaml --tags nova_hybrid_state --limit all

      このコマンドにより、コンピュートノード上の一時的な 16.2 コンテナーが起動します。これにより、後のステップでコンピュートノードをアップグレードする際に、ワークロードの移行が円滑に行われます。

    5. タグを指定せずにアップグレードコマンドを実行します。

      $ openstack overcloud upgrade run --stack STACK NAME --limit overcloud-controller-0

      このコマンドにより、Red Hat OpenStack Platform のアップグレードが実施されます。

  4. Pacemaker ベースの各ノードをアップグレードします。

    1. ノードに Ceph Storage コンテナーが含まれていれば、ceph_systemd タグを指定して外部アップグレードコマンドを実行します。

      $ openstack overcloud external-upgrade run --stack STACK NAME --tags ceph_systemd -e ceph_ansible_limit=overcloud-database-0

      このコマンドにより、以下の操作が行われます。

      • Podman 管理を使用するために、Ceph Storage コンテナーを制御する systemd ユニットを変更する。
      • ceph_ansible_limit 変数を使用して、アクションを選択したノードに制限する。

      このステップは、leapp によるアップグレードに向けて Ceph Storage サービスを準備するための予備的な処置です。

    2. 次のノードで、system_upgrade タグを指定してアップグレードコマンドを実行します。

      $ openstack overcloud upgrade run --stack STACK NAME --tags system_upgrade --limit overcloud-database-0

      このコマンドにより、以下のアクションが行われます。

      • Leapp によるオペレーティングシステムのアップグレードを実施する。
      • Leapp によるアップグレードの一部としてリブートを実施する。
    3. タグを指定せずにアップグレードコマンドを実行します。

      $ openstack overcloud upgrade run --stack STACK NAME --limit overcloud-controller-0,overcloud-database-0

      このコマンドにより、Red Hat OpenStack Platform のアップグレードが実施されます。このノードに加えて、前のステップでアップグレードしたすべてのノードを --limit オプションに含めます。

  5. 各 Pacemaker ベースのノードでアップグレードプロセスを繰り返し、すべての Pacemaker ベースのノードをアップグレードします。

21.3. Pacemaker コントローラーノード以外のアップグレード

Pacemaker ベースのサービスが含まれないノードをすべて OpenStack Platform 16.2 にアップグレードします。これらのノードには、通常特定の OpenStack サービスが含まれます。Pacemaker ベースのサービスが含まれないロールの例は以下のとおりです。

  • Networker
  • Ironic Conductor
  • Object Storage
  • 標準のコントローラーノードから分割またはスケーリングしたサービスを持つカスタムロール

このグループには、以下のノードを含めないでください。

  • コンピュートノード
  • Ceph Storage ノード

このプロセスでは、各ノードのアップグレードを行います。

注記

デフォルトのスタック名 (overcloud) を使用していない場合は、--stack STACK NAME オプションでスタック名を設定します。STACK NAME は実際のスタック名に置き換えます。

手順

  1. stackrc ファイルを取得します。

    $ source ~/stackrc
  2. system_upgrade タグを指定してアップグレードコマンドを実行します。

    $ openstack overcloud upgrade run --stack STACK NAME --tags system_upgrade --limit overcloud-networker-0

    このコマンドにより、以下のアクションが行われます。

    • Leapp によるオペレーティングシステムのアップグレードを実施する。
    • Leapp によるアップグレードの一部としてリブートを実施する。
  3. タグを指定せずにアップグレードコマンドを実行します。

    $ openstack overcloud upgrade run --stack STACK NAME --limit overcloud-networker-0

    このコマンドにより、Red Hat OpenStack Platform のアップグレードが実施されます。

  4. 各ノードでアップグレードプロセスを繰り返し、すべてのコントローラーベースのノードをアップグレードします。

21.4. Ceph MON ノードのオペレーティングシステムのアップグレード

各 Ceph MON ノードのオペレーティングシステムをアップグレードします。ノード間のクォーラムを維持するために、それぞれの Ceph MON ノードを個別にアップグレードすることを推奨します。

注記

デフォルトのスタック名 (overcloud) を使用していない場合は、--stack STACK NAME オプションでスタック名を設定します。STACK NAME は実際のスタック名に置き換えます。

手順

  1. stackrc ファイルを取得します。

    $ source ~/stackrc
  2. Ceph MON ノードを選択し、オペレーティングシステムをアップグレードします。

    1. ceph_systemd タグを指定して外部アップグレードコマンドを実行します。

      $ openstack overcloud external-upgrade run --stack STACK NAME --tags ceph_systemd -e ceph_ansible_limit=overcloud-cephmon-0

      このコマンドにより、以下の操作が行われます。

      • Podman 管理を使用するために、Ceph Storage コンテナーを制御する systemd ユニットを変更する。
      • ceph_ansible_limit 変数を使用して、アクションを選択したノードに制限する。

      このステップは、leapp によるアップグレードに向けて Ceph Storage サービスを準備するための予備的な処置です。

    2. system_upgrade タグを指定してアップグレードコマンドを実行します。

      $ openstack overcloud upgrade run --stack STACK NAME --tags system_upgrade --limit overcloud-cephmon-0

      このコマンドにより、以下のアクションが行われます。

      • Leapp によるオペレーティングシステムのアップグレードを実施する。
      • Leapp によるアップグレードの一部としてリブートを実施する。
    3. タグを指定せずにアップグレードコマンドを実行します。

      $ openstack overcloud upgrade run --stack STACK NAME --limit overcloud-cephmon-0

      このコマンドにより config-download Playbook が実行され、Ceph MON ノードでコンポーザブルサービスが設定されます。以下の手順では、Ceph MON ノードは Red Hat Ceph Storage 4 にアップグレードされません。Red Hat Ceph Storage 4 へのアップグレードは、後の手順で実施されます。

  3. 次の Ceph MON ノードを選択し、オペレーティングシステムをアップグレードします。

    1. ceph_systemd タグを指定して外部アップグレードコマンドを実行します。

      $ openstack overcloud external-upgrade run --stack STACK NAME --tags ceph_systemd -e ceph_ansible_limit=overcloud-cephmon-1

      このコマンドにより、以下の操作が行われます。

      • Podman 管理を使用するために、Ceph Storage コンテナーを制御する systemd ユニットを変更する。
      • ceph_ansible_limit 変数を使用して、アクションを選択したノードに制限する。

      このステップは、leapp によるアップグレードに向けて Ceph Storage サービスを準備するための予備的な処置です。

    2. system_upgrade タグを指定してアップグレードコマンドを実行します。

      $ openstack overcloud upgrade run --stack STACK NAME --tags system_upgrade --limit overcloud-cephmon-1

      このコマンドにより、以下のアクションが行われます。

      • Leapp によるオペレーティングシステムのアップグレードを実施する。
      • Leapp によるアップグレードの一部としてリブートを実施する。
    3. タグを指定せずにアップグレードコマンドを実行します。

      $ openstack overcloud upgrade run --stack STACK NAME --limit overcloud-cephmon-1

      このコマンドにより config-download Playbook が実行され、Ceph MON ノードでコンポーザブルサービスが設定されます。以下の手順では、Ceph MON ノードは Red Hat Ceph Storage 4 にアップグレードされません。Red Hat Ceph Storage 4 へのアップグレードは、後の手順で実施されます。

  4. 最後の Ceph MON ノードを選択し、オペレーティングシステムをアップグレードします。

    1. ceph_systemd タグを指定して外部アップグレードコマンドを実行します。

      $ openstack overcloud external-upgrade run --stack STACK NAME --tags ceph_systemd -e ceph_ansible_limit=overcloud-cephmon-2

      このコマンドにより、以下の操作が行われます。

      • Podman 管理を使用するために、Ceph Storage コンテナーを制御する systemd ユニットを変更する。
      • ceph_ansible_limit 変数を使用して、アクションを選択したノードに制限する。

      このステップは、leapp によるアップグレードに向けて Ceph Storage サービスを準備するための予備的な処置です。

    2. system_upgrade タグを指定してアップグレードコマンドを実行します。

      $ openstack overcloud upgrade run --stack STACK NAME --tags system_upgrade --limit overcloud-cephmon-2

      このコマンドにより、以下のアクションが行われます。

      • Leapp によるオペレーティングシステムのアップグレードを実施する。
      • Leapp によるアップグレードの一部としてリブートを実施する。
    3. タグを指定せずにアップグレードコマンドを実行します。

      $ openstack overcloud upgrade run --stack STACK NAME --limit overcloud-cephmon-2

      このコマンドにより config-download Playbook が実行され、Ceph MON ノードでコンポーザブルサービスが設定されます。以下の手順では、Ceph MON ノードは Red Hat Ceph Storage 4 にアップグレードされません。Red Hat Ceph Storage 4 へのアップグレードは、後の手順で実施されます。

21.5. Ceph Storage ノードのオペレーティングシステムのアップグレード

director を使用してデプロイされた Red Hat Ceph Storage クラスターがデプロイメントで使用される場合は、各 Ceph Storage ノードのオペレーティングシステムをアップグレードする必要があります。

注記

デフォルトのスタック名 (overcloud) を使用していない場合は、--stack STACK NAME オプションでスタック名を設定します。STACK NAME は実際のスタック名に置き換えます。

手順

  1. stackrc ファイルを取得します。

    $ source ~/stackrc
  2. Ceph Storage ノードを選択し、オペレーティングシステムをアップグレードします。

    1. ceph_systemd タグを指定して外部アップグレードコマンドを実行します。

      $ openstack overcloud external-upgrade run --stack STACK NAME --tags ceph_systemd -e ceph_ansible_limit=overcloud-cephstorage-0

      このコマンドにより、以下の操作が行われます。

      • Podman 管理を使用するために、Ceph Storage コンテナーを制御する systemd ユニットを変更する。
      • ceph_ansible_limit 変数を使用して、アクションを選択したノードに制限する。

      このステップは、leapp によるアップグレードに向けて Ceph Storage サービスを準備するための予備的な処置です。

    2. system_upgrade タグを指定してアップグレードコマンドを実行します。

      $ openstack overcloud upgrade run --stack STACK NAME --tags system_upgrade --limit overcloud-cephstorage-0

      このコマンドにより、以下のアクションが行われます。

      • Leapp によるオペレーティングシステムのアップグレードを実施する。
      • Leapp によるアップグレードの一部としてリブートを実施する。
    3. タグを指定せずにアップグレードコマンドを実行します。

      $ openstack overcloud upgrade run --stack STACK NAME --limit overcloud-cephstorage-0

      このコマンドにより config-download Playbook が実行され、Ceph Storage ノードでコンポーザブルサービスが設定されます。このステップでは、Ceph Storage ノードは Red Hat Ceph Storage 4 にアップグレードされません。Red Hat Ceph Storage 4 へのアップグレードは、後の手順で実施されます。

  3. 次の Ceph Storage ノードを選択し、オペレーティングシステムをアップグレードします。

    1. ceph_systemd タグを指定して外部アップグレードコマンドを実行します。

      $ openstack overcloud external-upgrade run --stack STACK NAME --tags ceph_systemd -e ceph_ansible_limit=overcloud-cephstorage-1

      このコマンドにより、以下の操作が行われます。

      • Podman 管理を使用するために、Ceph Storage コンテナーを制御する systemd ユニットを変更する。
      • ceph_ansible_limit 変数を使用して、アクションを選択したノードに制限する。

      このステップは、leapp によるアップグレードに向けて Ceph Storage サービスを準備するための予備的な処置です。

    2. system_upgrade タグを指定してアップグレードコマンドを実行します。

      $ openstack overcloud upgrade run --stack STACK NAME --tags system_upgrade --limit overcloud-cephstorage-1

      このコマンドにより、以下のアクションが行われます。

      • Leapp によるオペレーティングシステムのアップグレードを実施する。
      • Leapp によるアップグレードの一部としてリブートを実施する。
    3. タグを指定せずにアップグレードコマンドを実行します。

      $ openstack overcloud upgrade run --stack STACK NAME --limit overcloud-cephstorage-1

      このコマンドにより config-download Playbook が実行され、Ceph Storage ノードでコンポーザブルサービスが設定されます。このステップでは、Ceph Storage ノードは Red Hat Ceph Storage 4 にアップグレードされません。Red Hat Ceph Storage 4 へのアップグレードは、後の手順で実施されます。

  4. 最後の Ceph Storage ノードを選択し、オペレーティングシステムをアップグレードします。

    1. ceph_systemd タグを指定して外部アップグレードコマンドを実行します。

      $ openstack overcloud external-upgrade run --stack STACK NAME --tags ceph_systemd -e ceph_ansible_limit=overcloud-cephstorage-2

      このコマンドにより、以下の操作が行われます。

      • Podman 管理を使用するために、Ceph Storage コンテナーを制御する systemd ユニットを変更する。
      • ceph_ansible_limit 変数を使用して、アクションを選択したノードに制限する。

      このステップは、leapp によるアップグレードに向けて Ceph Storage サービスを準備するための予備的な処置です。

    2. system_upgrade タグを指定してアップグレードコマンドを実行します。

      $ openstack overcloud upgrade run --stack STACK NAME --tags system_upgrade --limit overcloud-cephstorage-2

      このコマンドにより、以下のアクションが行われます。

      • Leapp によるオペレーティングシステムのアップグレードを実施する。
      • Leapp によるアップグレードの一部としてリブートを実施する。
    3. タグを指定せずにアップグレードコマンドを実行します。

      $ openstack overcloud upgrade run --stack STACK NAME --limit overcloud-cephstorage-2

      このコマンドにより config-download Playbook が実行され、Ceph Storage ノードでコンポーザブルサービスが設定されます。このステップでは、Ceph Storage ノードは Red Hat Ceph Storage 4 にアップグレードされません。Red Hat Ceph Storage 4 へのアップグレードは、後の手順で実施されます。

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

すべてのコンピュートノードを OpenStack Platform 16.2 にアップグレードします。

注記

デフォルトのスタック名 (overcloud) を使用していない場合は、--stack STACK NAME オプションでスタック名を設定します。STACK NAME は実際のスタック名に置き換えます。

手順

  1. stackrc ファイルを取得します。

    $ source ~/stackrc
  2. インスタンスを移行します。移行計画についての詳細は、「Migrating virtual machines between Compute nodes」を参照してください。
  3. system_upgrade タグを指定してアップグレードコマンドを実行します。

    $ openstack overcloud upgrade run --stack STACK NAME --tags system_upgrade --limit overcloud-compute-0

    このコマンドにより、以下のアクションが行われます。

    • Leapp によるオペレーティングシステムのアップグレードを実施する。
    • Leapp によるアップグレードの一部としてリブートを実施する。
  4. タグを指定せずにアップグレードコマンドを実行します。

    $ openstack overcloud upgrade run --stack STACK NAME --limit overcloud-compute-0

    このコマンドにより、Red Hat OpenStack Platform のアップグレードが実施されます。

  5. 複数のコンピュートノードを並行してアップグレードするには、--limit オプションをアップグレードするノードのコンマ区切りリストに設定します。まず system_upgrade タスクを実行します。

    $ openstack overcloud upgrade run --stack STACK NAME --tags system_upgrade --limit overcloud-compute-0,overcloud-compute-1,overcloud-compute-2

    続いて、標準の OpenStack サービスのアップグレードを実施します。

    $ openstack overcloud upgrade run --stack STACK NAME  --limit overcloud-compute-0,overcloud-compute-1,overcloud-compute-2

21.7. オーバークラウドスタックの同期

アップグレードにおいては、スタックのリソース構造およびパラメーターが OpenStack Platform 16.2 の新規デプロイメントと整合するように、オーバークラウドスタックを更新する必要があります。

注記

デフォルトのスタック名 (overcloud) を使用していない場合は、--stack STACK NAME オプションでスタック名を設定します。STACK NAME は実際のスタック名に置き換えます。

手順

  1. stackrc ファイルを取得します。

    $ source ~/stackrc
  2. containers-prepare-parameter.yaml ファイルを編集し、以下のパラメーターおよびその値を削除します。

    • ceph3_namespace
    • ceph3_tag
    • ceph3_image
    • name_prefix_stein
    • name_suffix_stein
    • namespace_stein
    • tag_stein
  3. アップグレードの最終処理コマンドを実行します。

    $ openstack overcloud upgrade converge \
        --stack STACK NAME \
        --templates \
        -e ENVIRONMENT FILE
        …​
        -e /home/stack/templates/upgrades-environment.yaml \
        -e /home/stack/templates/rhsm.yaml \
        -e /home/stack/containers-prepare-parameter.yaml \
        -e /usr/share/openstack-tripleo-heat-templates/environments/services/neutron-ovs.yaml \
        …​

    以下のオプションの中で、お使いの環境に適切なオプションを追加します。

    • アップグレード固有のパラメーターが含まれる環境ファイル (upgrades-environment.yaml) (-e)
    • 登録およびサブスクリプションに関するパラメーターが含まれる環境ファイル (rhsm.yaml) (-e)
    • 新しいコンテナーイメージの場所を定義した環境ファイル (containers-prepare-parameter.yaml) (-e)。多くの場合、アンダークラウドが使用する環境ファイルと同じファイルです。
    • OVS との互換性を維持するための環境ファイル (neutron-ovs.yaml)
    • デプロイメントに関連するカスタム設定環境ファイル (-e)
    • 該当する場合は、--roles-file でカスタムロール (roles_data) ファイルを指定します。
    • 該当する場合は、--networks-file でコンポーザブルネットワーク (network_data) ファイルを指定します。
    • カスタムのスタック名を使用する場合は、--stack オプションでその名前を渡します。
  4. スタックの同期が完了するまで待ちます。
重要

これ以降のデプロイメント操作には、upgrades-environment.yaml ファイルは必要ありません。

第22章 ハイパーコンバージドインフラストラクチャーを持つオーバークラウドのアップグレード

このシナリオでは、ハイパーコンバージドインフラストラクチャー (HCI) を持つオーバークラウドのアップグレードプロセスの例を説明します。この環境には、以下のノード種別が含まれます。

  • コントローラーノード 3 台
  • 複数の HCI コンピュートノード (Compute サービスと Ceph OSD サービスが組み合わされてノードに含まれる)

22.1. オーバークラウドアップグレード準備タスクの実行

アップグレードを行うには、openstack overcloud upgrade prepare コマンドを実行する必要があります。このコマンドにより、以下のタスクが実行されます。

  • オーバークラウドのプランを OpenStack Platform 16.2 に更新する。
  • アップグレードに向けてノードを準備する。
注記

デフォルトのスタック名 (overcloud) を使用していない場合は、--stack STACK NAME オプションでスタック名を設定します。STACK NAME は実際のスタック名に置き換えます。

手順

  1. stackrc ファイルを取得します。

    $ source ~/stackrc
  2. upgrade prepare コマンドを実行します。

    $ openstack overcloud upgrade prepare \
        --stack STACK NAME \
        --templates \
        -e ENVIRONMENT FILE
        …​
        -e /home/stack/templates/upgrades-environment.yaml \
        -e /home/stack/templates/rhsm.yaml \
        -e /home/stack/containers-prepare-parameter.yaml \
        -e /usr/share/openstack-tripleo-heat-templates/environments/services/neutron-ovs.yaml \
        …​

    以下のオプションの中で、お使いの環境に適切なオプションを追加します。

    • アップグレード固有のパラメーターが含まれる環境ファイル (upgrades-environment.yaml) (-e)
    • 登録およびサブスクリプションに関するパラメーターが含まれる環境ファイル (rhsm.yaml) (-e)
    • 新しいコンテナーイメージの場所を定義した環境ファイル (containers-prepare-parameter.yaml) (-e)。多くの場合、アンダークラウドが使用する環境ファイルと同じファイルです。
    • OVS との互換性を維持するための環境ファイル (neutron-ovs.yaml)
    • デプロイメントに関連するカスタム設定環境ファイル (-e)
    • 該当する場合は、--roles-file でカスタムロール (roles_data) ファイルを指定します。
    • 該当する場合は、--networks-file でコンポーザブルネットワーク (network_data) ファイルを指定します。
    • カスタムのスタック名を使用する場合は、--stack オプションでその名前を渡します。
  3. アップグレードの準備が完了するまで待ちます。
  4. コンテナーイメージをダウンロードします。

    $ openstack overcloud external-upgrade run --stack STACK NAME --tags container_image_prepare

22.2. director でデプロイされた Ceph Storage と組み合わせたコントローラーノードのアップグレード

director を使用してデプロイされた Red Hat Ceph Storage クラスターがデプロイメントで使用される場合は、以下の手順を完了する必要があります。

すべてのコントローラーノードを OpenStack Platform 16.2 にアップグレードする場合は、ブートストラップコントローラーノードからアップグレードを始める必要があります。

ブートストラップコントローラーノードのアップグレードプロセス中、新しい Pacemaker クラスターが作成され、新しい Red Hat OpenStack 16.2 コンテナーがノードで起動します。一方、残りのコントローラーノードは Red Hat OpenStack 13 で稼働を続けます。

ブートストラップノードをアップグレードしたら、Pacemaker サービスが含まれるその他のノードをアップグレードし、ブートストラップノードで起動した新しい Pacemaker クラスターに各ノードが参加するようにしなければなりません。詳細は、「オーバークラウドノードのアップグレードワークフロー」を参照してください。

以下の例では、コントローラーノードの名前はデフォルトの overcloud-controller-NODEID 命名規則を使用して名前を付けています。これには、以下の 3 つのコントローラーノードが含まれます。

  • overcloud-controller-0
  • overcloud-controller-1
  • overcloud-controller-2

これらの値は、該当する実際のノード名に置き換てください。

注記

デフォルトのスタック名 (overcloud) を使用していない場合は、--stack STACK NAME オプションでスタック名を設定します。STACK NAME は実際のスタック名に置き換えます。

手順

  1. stackrc ファイルを取得します。

    $ source ~/stackrc
  2. コントローラーノードで以下のコマンドを実行し、ブートストラップコントローラーノードを特定します。

    $ sudo hiera -c /etc/puppet/hiera.yaml pacemaker_short_bootstrap_node_name

    アンダークラウドからこのコマンドを実行するには、以下の SSH コマンドを実行します。ここで、CONTROLLER_IP は環境内の任意のコントローラーノードの IP アドレスに置き換えます。

    $ ssh heat-admin@CONTROLLER_IP "sudo hiera -c /etc/puppet/hiera.yaml pacemaker_short_bootstrap_node_name"

    以下の例では、overcloud-controller-0 をブートストラップノードの値として使用します。これを実際のブートストラップノードの値に置き換えてください。

  3. ブートストラップコントローラーノードをアップグレードします。

    1. ceph_systemd タグを指定して外部アップグレードコマンドを実行します。

      $ openstack overcloud external-upgrade run --stack STACK NAME --tags ceph_systemd -e ceph_ansible_limit=overcloud-controller-0

      このコマンドにより、以下の操作が行われます。

      • Podman 管理を使用するために、Ceph Storage コンテナーを制御する systemd ユニットを変更する。
      • ceph_ansible_limit 変数を使用して、アクションを選択したコントローラーノードに制限する。

      このステップは、leapp によるアップグレードに向けて Ceph Storage サービスを準備するための予備的な処置です。

    2. system_upgrade タグを指定してアップグレードコマンドを実行します。

      $ openstack overcloud upgrade run --stack STACK NAME --tags system_upgrade --limit overcloud-controller-0

      このコマンドにより、以下のアクションが行われます。

      • Leapp によるオペレーティングシステムのアップグレードを実施する。
      • Leapp によるアップグレードの一部としてリブートを実施する。

        重要

        次のコマンドにより、コントロールプレーンで機能停止が生じます。これ以降の数ステップを実施している間は、標準的なオーバークラウド操作を行うことはできません。

    3. system_upgrade_transfer_data タグを指定して外部アップグレードコマンドを実行します。

      $ openstack overcloud external-upgrade run --stack STACK NAME --tags system_upgrade_transfer_data

      このコマンドにより、最新バージョンのデータベースが既存のノードからブートストラップノードにコピーされます。

    4. nova_hybrid_state タグを指定してアップグレードコマンドを実行し、upgrade_steps_playbook.yaml Playbook だけを実行します。

      $ openstack overcloud upgrade run --stack STACK NAME --playbook upgrade_steps_playbook.yaml --tags nova_hybrid_state --limit all

      このコマンドにより、コンピュートノード上の一時的な 16.2 コンテナーが起動します。これにより、後のステップでコンピュートノードをアップグレードする際に、ワークロードの移行が円滑に行われます。

    5. タグを指定せずにアップグレードコマンドを実行します。

      $ openstack overcloud upgrade run --stack STACK NAME --limit overcloud-controller-0

      このコマンドにより、Red Hat OpenStack Platform のアップグレードが実施されます。

      重要

      このコマンドの処理が完了すると、コントロールプレーンがアクティブになります。再び標準的なオーバークラウド操作を実施することができます。

    6. アップグレード後に新しい Pacemaker クラスターが起動していること、および galera、rabbit、haproxy、redis 等のコントロールプレーンサービスが実行中であることを確認します。

      $ sudo pcs status
  4. 次のコントローラーノードをアップグレードします。

    1. 古いクラスターが実行されなくなったことを確認します。

      $ sudo pcs status

      クラスターが実行されていない場合、以下のようなエラーが表示されます。

      Error: cluster is not currently running on this node
    2. ceph_systemd タグを指定して外部アップグレードコマンドを実行します。

      $ openstack overcloud external-upgrade run --stack STACK NAME --tags ceph_systemd -e ceph_ansible_limit=overcloud-controller-1

      このコマンドにより、以下の操作が行われます。

      • Podman 管理を使用するために、Ceph Storage コンテナーを制御する systemd ユニットを変更する。
      • ceph_ansible_limit 変数を使用して、アクションを選択したコントローラーノードに制限する。

      このステップは、leapp によるアップグレードに向けて Ceph Storage サービスを準備するための予備的な処置です。

    3. 次のコントローラーノードで、system_upgrade タグを指定してアップグレードコマンドを実行します。

      $ openstack overcloud upgrade run --stack STACK NAME --tags system_upgrade --limit overcloud-controller-1

      このコマンドにより、以下のアクションが行われます。

      • Leapp によるオペレーティングシステムのアップグレードを実施する。
      • Leapp によるアップグレードの一部としてリブートを実施する。
    4. タグを指定せずにアップグレードコマンドを実行します。

      $ openstack overcloud upgrade run --stack STACK NAME --limit overcloud-controller-0,overcloud-controller-1

      このコマンドにより、Red Hat OpenStack Platform のアップグレードが実施されます。このノードに加えて、前のステップでアップグレードしたブートストラップノードを --limit オプションに含めます。

  5. 最後のコントローラーノードをアップグレードします。

    1. 古いクラスターが実行されなくなったことを確認します。

      $ sudo pcs status

      クラスターが実行されていない場合、以下のようなエラーが表示されます。

      Error: cluster is not currently running on this node
    2. ceph_systemd タグを指定して外部アップグレードコマンドを実行します。

      $ openstack overcloud external-upgrade run --stack STACK NAME --tags ceph_systemd -e ceph_ansible_limit=overcloud-controller-2

      このコマンドにより、以下の操作が行われます。

      • Podman 管理を使用するために、Ceph Storage コンテナーを制御する systemd ユニットを変更する。
      • ceph_ansible_limit 変数を使用して、アクションを選択したコントローラーノードに制限する。

      このステップは、leapp によるアップグレードに向けて Ceph Storage サービスを準備するための予備的な処置です。

    3. system_upgrade タグを指定してアップグレードコマンドを実行します。

      $ openstack overcloud upgrade run --stack STACK NAME --tags system_upgrade --limit overcloud-controller-2

      このコマンドにより、以下のアクションが行われます。

      • Leapp によるオペレーティングシステムのアップグレードを実施する。
      • Leapp によるアップグレードの一部としてリブートを実施する。
    4. タグを指定せずにアップグレードコマンドを実行します。

      $ openstack overcloud upgrade run --stack STACK NAME --limit overcloud-controller-0,overcloud-controller-1,overcloud-controller-2

      このコマンドにより、Red Hat OpenStack Platform のアップグレードが実施されます。--limit オプションにすべてのコントローラーノードを含めます。

22.3. ハイパーコンバージドインフラストラクチャー (HCI) を持つコンピュートノードのアップグレード

HCI コンピュートノードを OpenStack Platform 16.2 にアップグレードします。

注記

デフォルトのスタック名 (overcloud) を使用していない場合は、--stack STACK NAME オプションでスタック名を設定します。STACK NAME は実際のスタック名に置き換えます。

手順

  1. stackrc ファイルを取得します。

    $ source ~/stackrc
  2. インスタンスを移行します。移行計画についての詳細は、「Migrating virtual machines between Compute nodes」を参照してください。
  3. ceph_systemd タグを指定して外部アップグレードコマンドを実行します。

    $ openstack overcloud external-upgrade run --stack STACK NAME --tags ceph_systemd -e ceph_ansible_limit=overcloud-computehci-0

    このコマンドにより、以下の操作が行われます。

    • Podman 管理を使用するために、Ceph Storage コンテナーを制御する systemd ユニットを変更する。
    • ceph_ansible_limit 変数を使用して、アクションを選択した Ceph Storage ノードに制限する。

    このステップは、leapp によるアップグレードに向けて Ceph Storage サービスを準備するための予備的な処置です。

  4. system_upgrade タグを指定してアップグレードコマンドを実行します。

    $ openstack overcloud upgrade run --stack STACK NAME --tags system_upgrade --limit overcloud-computehci-0

    このコマンドにより、以下のアクションが行われます。

    • Leapp によるオペレーティングシステムのアップグレードを実施する。
    • Leapp によるアップグレードの一部としてリブートを実施する。
  5. タグを指定せずにアップグレードコマンドを実行します。

    $ openstack overcloud upgrade run --stack STACK NAME --limit overcloud-computehci-0

    このコマンドにより、Red Hat OpenStack Platform のアップグレードが実施されます。

  6. 複数のコンピュートノードを並行してアップグレードするには、--limit オプションをアップグレードするノードのコンマ区切りリストに設定します。まず、ceph_systemd タグを指定して外部アップグレードコマンドを実行します。

    $ openstack overcloud external-upgrade run --stack STACK NAME --tags ceph_systemd -e ceph_ansible_limit=overcloud-computehci-0,overcloud-computehci-1,overcloud-computehci-2

    次に、system_upgrade タスクを実行します。

    $ openstack overcloud upgrade run --stack STACK NAME --tags system_upgrade --limit overcloud-computehci-0,overcloud-computehci-1,overcloud-computehci-2

    続いて、標準の OpenStack サービスのアップグレードを実施します。

    $ openstack overcloud upgrade run --stack STACK NAME  --limit overcloud-computehci-0,overcloud-computehci-1,overcloud-computehci-2

22.4. オーバークラウドスタックの同期

アップグレードにおいては、スタックのリソース構造およびパラメーターが OpenStack Platform 16.2 の新規デプロイメントと整合するように、オーバークラウドスタックを更新する必要があります。

注記

デフォルトのスタック名 (overcloud) を使用していない場合は、--stack STACK NAME オプションでスタック名を設定します。STACK NAME は実際のスタック名に置き換えます。

手順

  1. stackrc ファイルを取得します。

    $ source ~/stackrc
  2. containers-prepare-parameter.yaml ファイルを編集し、以下のパラメーターおよびその値を削除します。

    • ceph3_namespace
    • ceph3_tag
    • ceph3_image
    • name_prefix_stein
    • name_suffix_stein
    • namespace_stein
    • tag_stein
  3. アップグレードの最終処理コマンドを実行します。

    $ openstack overcloud upgrade converge \
        --stack STACK NAME \
        --templates \
        -e ENVIRONMENT FILE
        …​
        -e /home/stack/templates/upgrades-environment.yaml \
        -e /home/stack/templates/rhsm.yaml \
        -e /home/stack/containers-prepare-parameter.yaml \
        -e /usr/share/openstack-tripleo-heat-templates/environments/services/neutron-ovs.yaml \
        …​

    以下のオプションの中で、お使いの環境に適切なオプションを追加します。

    • アップグレード固有のパラメーターが含まれる環境ファイル (upgrades-environment.yaml) (-e)
    • 登録およびサブスクリプションに関するパラメーターが含まれる環境ファイル (rhsm.yaml) (-e)
    • 新しいコンテナーイメージの場所を定義した環境ファイル (containers-prepare-parameter.yaml) (-e)。多くの場合、アンダークラウドが使用する環境ファイルと同じファイルです。
    • OVS との互換性を維持するための環境ファイル (neutron-ovs.yaml)
    • デプロイメントに関連するカスタム設定環境ファイル (-e)
    • 該当する場合は、--roles-file でカスタムロール (roles_data) ファイルを指定します。
    • 該当する場合は、--networks-file でコンポーザブルネットワーク (network_data) ファイルを指定します。
    • カスタムのスタック名を使用する場合は、--stack オプションでその名前を渡します。
  4. スタックの同期が完了するまで待ちます。
重要

これ以降のデプロイメント操作には、upgrades-environment.yaml ファイルは必要ありません。

第23章 director でデプロイされた Ceph Storage クラスターの Red Hat Ceph Storage 4 へのアップグレード

director を使用してデプロイされた Red Hat Ceph Storage クラスターがデプロイメントで使用される場合は、本項に記載する手順を完了する必要があります。

重要

Red Hat Ceph Storage クラスターを、以前のサポート対象バージョンからバージョン 4.2z2 にアップグレードする場合、モニターがセキュアでないglobal_id 再要求を許可する ことを示す警告メッセージと共に、ストレージクラスターが HEALTH_WARN の状態でアップグレードが完了します。これは、パッチが適用された CVE (CVE-2021-20288) が原因です。「Ceph HEALTH_WARN with 'mons are allowing insecure global_id reclaim' after install/upgrade to RHCS 4.2z2 (or newer)」を参照してください。

CVE により HEALTH_WARN の状態が表示されるため、一時的に健全性についての警告をミュートすることができます。ただし、警告をミュートすると、古いクライアントおよびパッチが適用されていないクライアントがクラスターに接続されても表示されないリスクがあります。健全性についての警告のミュートについての詳細は、Red Hat Ceph Storage のドキュメントの「Upgrading a Red Hat Ceph Storage cluster」を参照してください。

注記

外部の Ceph デプロイメントと共にアップグレードする場合は、本項に記載する手順を省略し、次のセクションに進む必要があります。

オーバークラウドをアップグレードしたら、director でデプロイされた Ceph Storage クラスターを Red Hat Ceph Storage クラスターバージョン 4 にアップグレードします。

23.1. ceph-ansible のインストール

director を使用してデプロイされた Red Hat Ceph Storage クラスターがデプロイメントで使用される場合は、以下の手順を完了する必要があります。

Red Hat OpenStack Platform で Ceph Storage を使用する場合、ceph-ansible パッケージが必要です。

手順

  1. Ceph Tools リポジトリーを有効にします。

    [stack@director ~]$ sudo subscription-manager repos --enable=rhceph-4-tools-for-rhel-8-x86_64-rpms
  2. ceph-ansible パッケージをインストールします。

    [stack@director ~]$ sudo dnf install -y ceph-ansible

23.2. Ceph Storage 4 へのアップグレード

Ceph Storage ノードをバージョン 3 からバージョン 4 にアップグレードします。

注記

デフォルトのスタック名 (overcloud) を使用していない場合は、--stack STACK NAME オプションでスタック名を設定します。STACK NAME は実際のスタック名に置き換えます。

手順

  1. stackrc ファイルを取得します。

    $ source ~/stackrc
  2. ceph タグを指定して、Ceph Storage の外部アップグレードプロセスを実行します。

    $ openstack overcloud external-upgrade run --stack STACK NAME --tags ceph
  3. Ceph Storage のアップグレードが完了するまで待ちます。

第24章 FileStore から BlueStore への OSD の移行

アップグレードプロセスを完了して検証を行ったら、FileStore OSD を BlueStore に移行する必要があります。1 台ずつノードの移行作業を完了していく必要があります。以下の手順では、ceph-ansible を使用して移行を完了します。以下の手順は、Ceph クラスターが director によりデプロイされている場合にのみ適用されます。

24.1. クラスターが FileStore を実行している (したがって移行が必要である) ことの確認

手順

  1. コントローラーノードやスタンドアロンの Ceph MON ノードなど、Ceph MON コンテナーを持つノードに heat-admin ユーザーとしてログインします。たとえば、標準のオーバークラウドデプロイメントでは、overcloud -controller-1 は Ceph MON コンテナーを使用します。
  2. OSD が使用しているドライバーを確認するために、Ceph クラスターに対してクエリーを行います。

    [heat-admin@overcloud-controller-1 ~]$ sudo -i
    [root@overcloud-controller-1 ~]# podman exec -it ceph-mon-overcloud-controller-1 sh -c "ceph -f json osd metadata" | jq -c 'sort_by(.hostname) | .[] | ["host", .hostname, "osd_id", .id, "objectstore", .osd_objectstore]'
    [root@overcloud-controller-1 ~]#
  3. いずれかの行が "objectstore": "filestore" を返す場合、そのノードには OSD の移行が必要です。
警告

移行の時間はクラスターのサイズによって異なります。非常に大きなクラスターの場合、移行時間はそのクラスター内の OSD の数および保存されるデータ量に比例します。お使いの環境が混合アーキテクチャーのシナリオにならないように、できるだけ早く移行を完了してください。混合アーキテクチャーのシナリオでは、パフォーマンスに影響が及ぶ可能性があります。

警告

Red Hat Ceph Storage (RHCS) 4 バージョンの ceph-ansible で FileStore ベースの OSD を管理する構成はサポートされていないため、スタックの更新を実行する前に移行を完了してください。

24.2. FileStore から BlueStore への OSD の移行

FileStore から BlueStore に移行するのに、director は Ansible を使用してノード上のすべての OSD を削除して再作成します。director は、移行プロセスの前に容量の確認を行います。最後に、director は BlueStore バックエンドを使用して OSD を再デプロイします。

前提条件

  • 正常な稼働中の Red Hat Ceph Storage (RHCS) 4 クラスター。コントローラーノードまたはスタンドアロンの Ceph MON ノード上の ceph MON コンテナーにおいて、以下のコマンドを入力してクラスターを確認することができます。

    [root@overcloud-controller-1 ~]# podman exec -it ceph-mon-overcloud-controller-1 sh -c  "ceph  -s"

手順

  1. CephAnsibleDisksConfig パラメーターの osd_objectstorefilestore にデフォルト設定されないようにします。いずれかのカスタム heat 環境ファイルに osd_objectstore パラメーターが存在する場合は、bluestore の値を明示的に定義する必要があります。

    parameter_defaults:
      CephAnsibleDisksConfig:
        devices:
          - /dev/sdb
          - /dev/sdc
          - /dev/sdd
        osd_scenario: lvm
       osd_objectstore: bluestore
    注記

    ジャーナル等に対する特定の FileStore 設定がある場合は、適切に設定を更新するようにしてください。高度な設定についての詳しい情報は、『Deploying an overcloud with containerized Red Hat Ceph』「Mapping the Ceph Storage Node Disk Layout」を参照してください。

  2. アンダークラウドに stack ユーザーとしてログインします。
  3. ceph_fstobs タグを指定して openstack overcloud external-upgrade run コマンドを入力します。<NODE_NAME> は、アップグレードする Ceph OSD ノードの名前に置き換えてください。openstack server list コマンドを使用してノード名を探すことができます。

    [stack@undercloud ~] $ openstack overcloud external-upgrade run --tags ceph_fstobs -e ceph_ansible_limit=<NODE_NAME> | tee oc-fstobs.log
  4. Ceph MON サービスが実行されているノードにログインし、Ceph クラスターにクエリーを行いアップグレードしたノードの OSD のステータスを確認します。次の OSD ノードの移行を開始する前に、アップグレードしたノードが正常に移行されていることを確認する必要があります。

    [heat-admin@overcloud-controller-1 ~]$ sudo -i
    [root@overcloud-controller-1 ~]# podman exec -it ceph-mon-overcloud-controller-1 sh -c "ceph -f json osd metadata" | jq -c '.[] | select(.hostname == "<NODE_NAME>") | ["host", .hostname, "osd_id", .id, "objectstore", .osd_objectstore]'
    [root@overcloud-controller-1 ~]# exit

    <NODE_NAME> を移行したノードの名前に置き換えます。出力結果を確認し、OSD が BlueStore を使用することが示されていれば、移行は正常に完了しています。

  5. (オプション) 特定の OSD に関する追加情報を表示するには、以下のコマンドを入力します。

    [root@overcloud-controller-1 ~]# podman exec -it ceph-mon-overcloud-controller-1 sh -c "ceph osd metadata <ID>"

    <ID> はクエリーを行う OSD の ID に置き換えてください。

  6. 次のノードで移行プロセスを開始する前に、クラスターが同期するのを待つ必要があります。

    [root@overcloud-controller-1 ~]# podman exec -it ceph-mon-overcloud-controller-1 sh -c  "ceph  -s"
    Review the command output and ensure that the health of the cluster is `HEALTH_OK` and the PGs are in the `active+clean` state.
  7. 次のノードで移行プロセスを開始する前に、クラスターのリバランスプロセスが完了するまで待つ必要があります。ステータスを確認するには、以下のコマンドを実行します。

    [heat-admin@overcloud-controller-0 ~]$ sudo podman exec ceph-mon-<NODE_NAME> ceph -w

    <NODE_NAME> を移行したノードの名前に置き換えます。

  8. ストレージクラスター内の各ノードに対して移行プロセスを繰り返します。

FileStore から BlueStore への移行に関する詳細は、Red Hat Ceph Storage の『管理ガイド』「BlueStore」を参照してください。

24.3. FileStore から BlueStore への移行の確認

OSD のステータスを確認して、移行が正常に完了していることを確認することができます。

手順

  1. いずれかのコントローラーノードがホストする ceph-mon コンテナーに heat-admin ユーザーとしてログインします。
  2. Ceph クラスターに対してクエリーを行います。

    [heat-admin@overcloud-controller-1 ~]$ sudo -i
    [root@overcloud-controller-1 ~]# podman exec -it ceph-mon-overcloud-controller-1 sh -c "ceph -f json osd metadata" | jq -c 'sort_by(.hostname) | .[] | ["host", .hostname, "osd_id", .id, "objectstore", .osd_objectstore]'
    [root@overcloud-controller-1 ~]#

設定を確認し、クラスター全体のすべての OSD が BlueStore を使用することが示されていれば、移行は正常に完了しています。

重要

推奨されるベストプラクティスは、べき等性を持つスタック更新を実行し、設定の定義と実際の設定が一致するようにすることです。スタック更新の時間はシステムのサイズによって異なります。したがって、ダウンタイムを短縮するため、メンテナンス期間中に移行を完了するよう計画することができます。

第25章 アップグレード後操作の実施

オーバークラウドのアップグレードが完了したら、アップグレード後の設定を実施して、環境が完全にサポートされ、これ以降の操作を行う準備が整っている状態にする必要があります。

25.1. アンダークラウドからの不要なパッケージおよびディレクトリーの削除

Leapp によるアップグレード後に、アンダークラウドに残っている不要なパッケージおよびディレクトリーを削除します。

手順

  1. 不要なパッケージを削除します。

    $ sudo dnf -y remove --exclude=python-pycadf-common python2*
  2. Red Hat OpenStack 13 で使用されていた古いイメージを含む /httpboot および /tftpboot ディレクトリーからコンテンツを削除します。

    $ sudo rm -rf /httpboot /tftpboot

25.2. アップグレード後の機能検証

post-upgrade 検証グループを実行し、アップグレード後の機能を確認します。

手順

  1. source コマンドで stackrc ファイルを読み込みます。

    $ source ~/stackrc
  2. --group post-upgrade オプションを指定して、openstack tripleo validator run コマンドを実行します。

    $ openstack tripleo validator run --group post-upgrade
  3. 検証レポートの結果を確認します。特定の検証からの詳細出力を表示するには、レポートからの特定検証の UUID を指定して openstack tripleo validator show run --full コマンドを実行します。

    $ openstack tripleo validator show run --full <UUID>
重要

検証結果が FAILED であっても、Red Hat OpenStack Platform のデプロイや実行が妨げられることはありません。ただし、FAILED の検証結果は、実稼働環境で問題が発生する可能性があることを意味します。

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

現在のオーバークラウドイメージを新しいバージョンに置き換える必要があります。新しいイメージにより、director は最新バージョンの OpenStack Platform ソフトウェアを使用してノードのイントロスペクションとプロビジョニングを行うことができるようになります。

前提条件

  • アンダークラウドが最新バージョンにアップグレードされていること

手順

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

    $ source ~/stackrc
  3. オーバークラウドの QCOW2 アーカイブが含まれるパッケージをインストールします。

    $ sudo dnf install rhosp-director-images rhosp-director-images-ipa-x86_64
  4. stack ユーザーのホーム下の images ディレクトリー (/home/stack/images) から既存のイメージを削除します。

    $ rm -rf ~/images/*
  5. アーカイブを展開します。

    $ cd ~/images
    $ for i in /usr/share/rhosp-director-images/overcloud-full-latest-16.2.tar /usr/share/rhosp-director-images/ironic-python-agent-latest-16.2.tar; do tar -xvf $i; done
    $ cd ~
  6. director に最新のイメージをインポートします。

    $ openstack overcloud image upload --update-existing --image-path /home/stack/images/
  7. ノードが新しいイメージを使用するように設定します。

    $ openstack overcloud node configure $(openstack baremetal node list -c UUID -f value)
重要

オーバークラウドノードをデプロイする際には、オーバークラウドイメージのバージョンが該当する heat テンプレートバージョンに対応している状態にします。たとえば、OpenStack Platform 16.2 のイメージは、OpenStack Platform 16.2 の heat テンプレートだけに使用してください。

重要

新しい overcloud-full イメージは、古い overcloud-full イメージを置き換えます。古いイメージに変更を加えた場合、特に今後新規ノードをデプロイする場合には、新しいイメージで変更を繰り返す必要があります。

25.4. CPU ピニングパラメーターの更新

Red Hat OpenStack Platform 16.2 では、CPU ピニングに新たなパラメーターが使用されます。

NovaComputeCpuDedicatedSet
専用の (ピニングされた) CPU を設定します。
NovaComputeCpuSharedSet
共有の (ピニングされていない) CPU を設定します。

Red Hat OpenStack Platform 16.2 へのアップグレードが完了したら、CPU ピニングの設定を NovaVcpuPinSet パラメーターから NovaComputeCpuDedicatedSetNovaComputeCpuSharedSet のパラメーターに移行する必要があります。

手順

  1. アンダークラウドに stack ユーザーとしてログインします。
  2. コンピュートノードが同時マルチスレッド (SMT) をサポートするが hw:cpu_thread_policy=isolated ポリシーでインスタンスを作成している場合は、以下のオプションのいずれかを実施する必要があります。

    • hw:cpu_thread_policy スレッドポリシーの設定を解除し、インスタンスのサイズを変更します。

      1. source コマンドでオーバークラウドの認証ファイルを読み込みます。

        $ source ~/overcloudrc
      2. フレーバーの hw:cpu_thread_policy プロパティーの設定を解除します。

        (overcloud) $ openstack flavor unset --property hw:cpu_thread_policy <flavor>
        注記
        • hw:cpu_thread_policy 属性の設定を解除すると、ポリシーがデフォルトの prefer ポリシーに設定されます。これにより、インスタンスは SMT 対応のコンピュートノードを使用するように設定されます (利用可能な場合)。hw:cpu_thread_policy 属性を require に設定することもできます。これにより、SMT 対応のコンピュートノードに対するハード要件が設定されます。
        • コンピュートノードに SMT アーキテクチャーがない場合や、スレッドシブリングが利用可能な CPU コアが十分にない場合には、スケジューリングが失敗します。これを回避するには、hw:cpu_thread_policyrequire ではなく prefer に設定します。デフォルトの prefer ポリシーでは、スレッドシブリングが利用可能な場合には、必ず使用されます。
        • hw:cpu_thread_policy=isolate を使用する場合は、SMT を無効にするか、SMT をサポートしないプラットフォームを使用する必要があります。
      3. 新しいスレッドポリシーを使用するようにインスタンスを変換します。

        (overcloud) $ openstack server resize --flavor <flavor> <server>
        (overcloud) $ openstack server resize confirm <server>

        hw:cpu_thread_policy=isolated ポリシーを使用するすべての固定インスタンスに対して、このステップを繰り返します。

    • コンピュートノードからインスタンスを移行して、コンピュートノードの SMT を無効にする。

      1. source コマンドでオーバークラウドの認証ファイルを読み込みます。

        $ source ~/overcloudrc
      2. コンピュートノードが新しい仮想マシンを受け入れるのを無効にします。

        (overcloud) $ openstack compute service list
        (overcloud) $ openstack compute service set <hostname> nova-compute --disable
      3. コンピュートノードからすべてのインスタンスを移行します。インスタンスの移行についての詳細は、「Migrating virtual machine instances between Compute nodes」を参照してください。
      4. コンピュートノードをリブートし、コンピュートノードの BIOS で SMT を無効にします。
      5. コンピュートノードをブートします。
      6. コンピュートノードを再度有効にします。

        (overcloud) $ openstack compute service set <hostname> nova-compute --enable
  3. stackrc ファイルを取得します。

    $ source ~/stackrc
  4. NovaVcpuPinSet パラメーターが含まれる環境ファイルを編集します。
  5. CPU ピニングの設定を NovaVcpuPinSet パラメーターから NovaComputeCpuDedicatedSetNovaComputeCpuSharedSet に移行します。

    • これまでピニングされたインスタンス用に使用されていたホストの場合には、NovaVcpuPinSet の値を NovaComputeCpuDedicatedSet に変更します。
    • これまでピニングされていないインスタンス用に使用されていたホストの場合には、NovaVcpuPinSet の値を NovaComputeCpuSharedSet に変更します。
    • NovaVcpuPinSet の値が設定されていない場合には、ノード上でホストするインスタンスの種別に応じて、すべてのコンピュートノードのコアを NovaComputeCpuDedicatedSet または NovaComputeCpuSharedSet のどちらかに割り当てる必要があります。

    たとえば、以前の環境ファイルに以下のピニング設定が定義されていたとします。

    parameter_defaults:
      ...
      NovaVcpuPinSet: 1,2,3,5,6,7
      ...

    設定をピニング設定に移行するには、NovaCompute CpuDedicatedSet パラメーターを設定し、NovaVcpuPinSet パラメーターの設定を解除します。

    parameter_defaults:
      ...
      NovaComputeCpuDedicatedSet: 1,2,3,5,6,7
      NovaVcpuPinSet: ""
      ...

    設定をピニングしない設定に移行するには、NovaComputeCpuSharedSet パラメーターを設定し、NovaVcpuPinSet パラメーターの設定を解除します。

    parameter_defaults:
      ...
      NovaComputeCpuSharedSet: 1,2,3,5,6,7
      NovaVcpuPinSet: ""
      ...
    重要

    NovaComputeCpuDedicatedSet または NovaComputeCpuSharedSet のいずれかが、NovaVcpuPinSet で定義した設定と一致するようにします。NovaComputeCpuDedicatedSet または NovaComputeCpuSharedSet のいずれかの設定を変更する、またはその両方を設定するには、設定を更新する前にピニング設定のコンピュートノードが 1 つのインスタンスも実行していないようにします。

  6. ファイルを保存します。
  7. デプロイメントコマンドを実行して、新しい CPU ピニングパラメーターでオーバークラウドを更新します。

    (undercloud) $ openstack overcloud deploy \
        --stack _STACK NAME_ \
        --templates \
        ...
        -e /home/stack/templates/<compute_environment_file>.yaml
        ...

25.5. メンバーロールへのユーザーの移行

Red Hat OpenStack Platform 13 では、デフォルトのメンバーロールは_member_と呼ばれています。
Red Hat OpenStack Platform 16.2 では、デフォルトのメンバーロールはmemberと呼ばれています。

Red Hat OpenStack Platform 13 から Red Hat OpenStack Platform 16.2 へのアップグレードを完了しても、_member_ロールに割り当てたユーザーにはそのロールが残っています。以下の手順で、すべてのユーザーをmemberロールに移行することができます。

前提条件

  • オーバークラウドが最新バージョンにアップグレードされていること

手順

  1. _member_ロールを持つクラウド上のすべてのユーザーをリストアップします。

    openstack role assignment list --names --role _member_ --sort-column project
  2. 各ユーザーに対して、_member_ロールを削除し、memberロールを適用します。

    openstack role remove --user <user> --project <project>  _member_
    openstack role add --user <user> --project <project>  member

第26章 アップグレードに関する問題のトラブルシューティング

アップグレードプロセス中に問題が発生した場合は、本セクションのアドバイスを参照してください。

26.1. 環境ファイルの修正

カスタム環境ファイルのパラメーターを誤って設定していた場合は、環境ファイルを修正して、アップグレード中いつでも openstack overcloud upgrade prepare コマンドを実行することができます。このコマンドにより、新しいバージョンのオーバークラウドプランが director にアップロードされ、これにより config-download Playbook の新しいセットが生成されます。

upgrades-environment.yaml ファイルのリポジトリー名が間違っている例を以下に示します。

parameter_defaults:
  UpgradeLeappEnabled: true
  UpgradeLeappCommandOptions: "--enablerepo rhel-7-for-x86_64-baseos-eus-rpms --enablerepo rhel-8-for-x86_64-appstream-eus-rpms --enablerepo fast-datapath-for-rhel-8-x86_64-rpms"
  CephAnsibleRepo: rhceph-4-tools-for-rhel-8-x86_64-rpms

この間違いにより、コントローラーノードの Leapp アップグレード時に問題が発生します。この問題を正すには、間違いを修正して openstack overcloud upgrade prepare コマンドを実行します。

手順

  1. ファイルの間違いを修正します。

    parameter_defaults:
      UpgradeLeappEnabled: true
      UpgradeLeappCommandOptions: "--enablerepo rhel-8-for-x86_64-baseos-eus-rpms --enablerepo rhel-8-for-x86_64-appstream-eus-rpms --enablerepo fast-datapath-for-rhel-8-x86_64-rpms"
      CephAnsibleRepo: rhceph-4-tools-for-rhel-8-x86_64-rpms
  2. 修正したファイルでアップグレードの準備コマンドを実行します。

    $ openstack overcloud upgrade prepare \
        --stack STACK NAME \
        --templates \
        -e ENVIRONMENT FILE
        …​
        -e /home/stack/templates/upgrades-environment.yaml \
        …​

    オーバークラウドスタックの更新が完了するまで待ちます。

  3. 失敗したアップグレードのステップから操作を続行します。