Red Hat OpenStack Platform の最新状態の維持

Red Hat OpenStack Platform 16.1

Red Hat OpenStack Platform のマイナー更新の実施

OpenStack Documentation Team

概要

本書では、お使いの Red Hat OpenStack Platform 環境のマイナー更新を行う手順について説明します。

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

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

Red Hat ドキュメントへのフィードバック (英語のみ)

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 16.1 環境が最新のパッケージおよびコンテナーで更新された状態を維持するのに役立ちます。

本ガイドは、以下のバージョンのアップグレードパスを提供します。

現在の OpenStack バージョン新しい OpenStack バージョン

Red Hat OpenStack Platform 16.0

Red Hat OpenStack Platform 16.1.z

Red Hat OpenStack Platform 16.1

Red Hat OpenStack Platform 16.1.z

1.1. ワークフローの概要

以下の表には、アップグレードのプロセスに必要なステップの概要をまとめています。

ステップ説明

アンダークラウドの更新

アンダークラウドを最新の OpenStack Platform 16.1.z バージョンに更新します。

オーバークラウドの更新

オーバークラウドを最新の OpenStack Platform 16.1.z バージョンに更新します。

Ceph Storage ノードの更新

すべての Ceph Storage サービスをアップグレードします。

アップグレードの最終段階

コンバージェンスのコマンドを実行して、オーバークラウドスタックをリフレッシュします。

インフラストラクチャーがマルチスタックの場合は、各オーバークラウドスタックを一度に 1 つずつ完全に更新します。分散コンピュートノード (DCN) インフラストラクチャーがある場合は、中央のロケーションでオーバークラウドを完全に更新してから、各エッジサイトでオーバークラウドを一度に 1 つずつ更新します。

RHOSP 環境を更新する前の考慮事項

更新プロセス中のガイドとして、次の情報を考慮してください。

  • Red Hat は、アンダークラウドおよびオーバークラウドの制御プレーンをバックアップすることを推奨しています。ノードのバックアップについて詳しくは、アンダークラウドおよびコントロールプレーンノードのバックアップと復元 を参照してください。
  • 更新を妨げる可能性のある既知の問題を把握してください。
  • 現在のメンテナンスリリースを確認するには、$ cat /etc/rhosp-release を実行してください。環境を更新した後にこのコマンドを実行して、更新を検証することもできます。

1.2. 更新を妨げる可能性のある既知の問題

マイナーバージョンの更新の正常な完了に影響を及ぼす可能性のある、以下の既知の問題を確認してください。

ノードのクラスターをシャットダウンする際に生じる競合状態により、Pacemaker バージョン 2.0.3-5.el8_2.4 を実行するオーバークラウドノードで更新に失敗する場合があります。

現在オーバークラウドノードのいずれかに Pacemaker バージョン 2.0.3-5.el8_2.4 がインストールされている場合、BZ#1973660 を避けるためにオーバークラウドノードを更新する前に Pacemaker をアップグレードする必要があります。詳細は、以下の Red Hat ナレッジベースのソリューション Update from OSP16.1 to OSP16.2 might fail to update certain HA containers を参照してください。

+RHEL 8.2 を実行し、コンポーザブルロールをベースとするノードの場合は、他のロールを更新する前に最初に Database ロールを更新する必要があります。

既知の問題により、リリース 16.1.6 以前から 16.1.7 以降に更新した後、LDAP 接続が失敗します。RHOSP 16.1.7 では、Identity サービス (keystone) コンテナーがホストファイルシステムに /etc/openldap をマウントします。以前に RHOSP 13 から更新したことがある場合、古い設定ファイルが /etc/openldap ディレクトリーに存在し、Identity サービスの LDAP 接続が失敗する原因となる可能性があります。

回避策として、各コントローラーで次のコマンドを実行します。

$ sudo cp /etc/openldap/ldap.conf.rpmnew /etc/openldap/ldap.conf
$ sudo podman restart keystone

次の条件を満たしている場合、ovn-controller の再起動中に、プロバイダーネットワークからトラバースするネットワークトラフィックが中断されます。

  • お使いの環境には、フローティング IP またはプロバイダーネットワーク上の直接ポートによって接続されたプロバイダーネットワークがあります。
  • 任意の 16.1 リリースに更新する

ダウンタイムは、既存のワークロードの数によって異なります。ダウンタイムを回避するには、Red Hat Knowledgebase の解決策を適用します。16.2.2 より古い OSP (すべての 16.1 バージョンを含む) からの更新/アップグレード時にデータプレーンが中断される

第2章 マイナー更新の準備

Red Hat OpenStack Platform 16.1 を最新のマイナーリリースに更新するプロセスを開始する前に、アンダークラウドおよびオーバークラウドで準備手順を実施する必要があります。

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

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

手順

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

    $ source ~/stackrc
  3. RhsmVars パラメーターが含まれるオーバークラウドのサブスクリプション管理用環境ファイルを編集します。通常、このファイルのデフォルト名は rhsm.yml です。
  4. サブスクリプション管理の設定で rhsm_release パラメーターを確認します。このパラメーターが設定されていない場合は、このパラメーターを追加してパラメーターを 8.2 に設定します。

    parameter_defaults:
      RhsmVars:
        …​
        rhsm_username: "myusername"
        rhsm_password: "p@55w0rd!"
        rhsm_org_id: "1234567"
        rhsm_pool_ids: "1a85f9223e3d5e43013e3d6e8ff506fd"
        rhsm_method: "portal"
        rhsm_release: "8.2"
  5. オーバークラウドのサブスクリプション管理用環境ファイルを保存します。
  6. オーバークラウドの静的なインベントリーファイルを作成します。

    $ tripleo-ansible-inventory --ansible_ssh_user heat-admin --static-yaml-inventory ~/inventory.yaml

    デフォルトのオーバークラウド名 overcloud 以外のオーバークラウド名を使用する場合は、--plan オプションを使用して実際のオーバークラウドの名前を設定します。

  7. すべてのノードで、オペレーティングシステムのバージョンを Red Hat Enterprise Linux 8.2 にロックするタスクが含まれる Playbook を作成します。

    $ cat > ~/set_release.yaml <<'EOF'
    - hosts: all
      gather_facts: false
      tasks:
        - name: set release to 8.2
          command: subscription-manager release --set=8.2
          become: true
    EOF
  8. set_release.yaml Playbook を実行します。

    $ ansible-playbook -i ~/inventory.yaml -f 25 ~/set_release.yaml --limit <undercloud>,<Controller>,<Compute>
    • --limit オプションを使用して、コンテンツをすべての RHOSP ノードに適用します。<undercloud><Controller><Compute> を、それらのノードを含む環境内の Ansible グループに置き換えます。
    • これらのノードに別のサブスクリプションを使用している場合は、Ceph Storage ノードに対してこの Playbook を実行することはできません。
注記

手動でノードを特定のバージョンにロックするには、ノードにログインして subscription-manager release コマンドを実行します。

$ sudo subscription-manager release --set=8.2

2.2. EUS リポジトリーから TUS リポジトリーへの変更

Red Hat OpenStack Platform サブスクリプションには、Red Hat Enterprise Linux 8.2 Extended Update Support (EUS) のリポジトリーが含まれます。2022 年 4 月 30 日以降、メンテナンスサポートを受けるには、RHEL 8.2 Telecommunications Update Service (TUS) リポジトリーを有効化する必要があります。TUS リポジトリーには、Red Hat Enterprise Linux 8.2 の最新のセキュリティーパッチとバグ修正が含まれています。更新を実行する前に、以下のリポジトリーに切り替えます。

EUS リポジトリーTUS リポジトリー

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

rhel-8-for-x86_64-baseos-tus-rpms

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

rhel-8-for-x86_64-appstream-tus-rpms

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

rhel-8-for-x86_64-highavailability-tus-rpms

重要

特定バージョンの Podman との互換性を維持するには、TUS リポジトリーを使用する必要があります。より新しいバージョンの Podman は、Red Hat Open Stack Platform 16.1 のリリースに対してテストされておらず、予期せぬ結果を招く可能性があります。

前提条件

  • RHOSP 16.1 EUS サブスクリプション

手順

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

    $ source ~/stackrc
  3. RhsmVars パラメーターが含まれるオーバークラウドのサブスクリプション管理用環境ファイルを編集します。通常、このファイルのデフォルト名は rhsm.yml です。
  4. サブスクリプション管理の設定で rhsm_repos パラメーターを確認します。このパラメーターに TUS リポジトリーが含まれていない場合、該当するリポジトリーを TUS バージョンに変更します。

    parameter_defaults:
      RhsmVars:
        rhsm_repos:
          - rhel-8-for-x86_64-baseos-tus-rpms
          - rhel-8-for-x86_64-appstream-tus-rpms
          - rhel-8-for-x86_64-highavailability-tus-rpms
          - ansible-2.9-for-rhel-8-x86_64-rpms
          - advanced-virt-for-rhel-8-x86_64-rpms
          - openstack-16.1-for-rhel-8-x86_64-rpms
          - rhceph-4-tools-for-rhel-8-x86_64-rpms
          - fast-datapath-for-rhel-8-x86_64-rpms
  5. オーバークラウドのサブスクリプション管理用環境ファイルを保存します。
  6. オーバークラウドの静的なインベントリーファイルを作成します。

    $ tripleo-ansible-inventory --ansible_ssh_user heat-admin --static-yaml-inventory ~/inventory.yaml

    デフォルトのオーバークラウド名 overcloud 以外のオーバークラウド名を使用する場合は、--plan オプションを使用して実際のオーバークラウドの名前を設定します。

  7. すべてのノードで、リポジトリーを Red Hat Enterprise Linux 8.2 TUS に設定するタスクが含まれる Playbook を作成します。

    $ cat > ~/change_tus.yaml <<'EOF'
    - hosts: all
      gather_facts: false
      tasks:
        - name: change to tus repos
          command: subscription-manager repos --disable=rhel-8-for-x86_64-baseos-eus-rpms --disable=rhel-8-for-x86_64-appstream-eus-rpms --disable=rhel-8-for-x86_64-highavailability-eus-rpms --enable=rhel-8-for-x86_64-baseos-tus-rpms --enable=rhel-8-for-x86_64-appstream-tus-rpms --enable=rhel-8-for-x86_64-highavailability-tus-rpms
          become: true
    EOF
  8. change_tus.yaml Playbook を実行します。

    $ ansible-playbook -i ~/inventory.yaml -f 25 ~/change_tus.yaml --limit <undercloud>,<Controller>,<Compute>
    • --limit オプションを使用して、コンテンツをすべての RHOSP ノードに適用します。<undercloud><Controller><Compute> を、それらのノードを含む環境内の Ansible グループに置き換えます。
    • これらのノードに別のサブスクリプションを使用している場合は、Ceph Storage ノードに対してこの Playbook を実行することはできません。

2.3. Red Hat Openstack Platform および Ansible リポジトリーの更新

Red Hat OpenStack Platform 16.1 パッケージおよび Ansible 2.9 パッケージを使用するようにリポジトリーを更新します。

手順

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

    $ source ~/stackrc
  3. RhsmVars パラメーターが含まれるオーバークラウドのサブスクリプション管理用環境ファイルを編集します。通常、このファイルのデフォルト名は rhsm.yml です。
  4. サブスクリプション管理の設定で rhsm_repos パラメーターを確認します。rhsm_repos パラメーターで Red Hat OpenStack Platform 16.0 リポジトリーおよび Ansible 2.8 リポジトリーが使用されている場合は、リポジトリーを正しいバージョンに変更します。

    parameter_defaults:
      RhsmVars:
        rhsm_repos:
          - rhel-8-for-x86_64-baseos-tus-rpms
          - rhel-8-for-x86_64-appstream-tus-rpms
          - rhel-8-for-x86_64-highavailability-tus-rpms
          - ansible-2.9-for-rhel-8-x86_64-rpms
          - advanced-virt-for-rhel-8-x86_64-rpms
          - openstack-16.1-for-rhel-8-x86_64-rpms
          - fast-datapath-for-rhel-8-x86_64-rpms
  5. オーバークラウドのサブスクリプション管理用環境ファイルを保存します。
  6. オーバークラウドの静的なインベントリーファイルを作成します。

    $ tripleo-ansible-inventory --ansible_ssh_user heat-admin --static-yaml-inventory ~/inventory.yaml

    デフォルトのオーバークラウド名 overcloud 以外のオーバークラウド名を使用する場合は、--plan オプションを使用して実際のオーバークラウドの名前を設定します。

  7. すべてのノードで、リポジトリーを Red Hat OpenStack Platform 16.1 に設定するタスクが含まれる Playbook を作成します。

    $ cat > ~/update_rhosp_repos.yaml <<'EOF'
    - hosts: all
      gather_facts: false
      tasks:
        - name: change osp repos
          command: subscription-manager repos --disable=openstack-16-for-rhel-8-x86_64-rpms --enable=openstack-16.1-for-rhel-8-x86_64-rpms --disable=ansible-2.8-for-rhel-8-x86_64-rpms --enable=ansible-2.9-for-rhel-8-x86_64-rpms
          become: true
    EOF
  8. update_rhosp_repos.yaml Playbook を実行します。

    $ ansible-playbook -i ~/inventory.yaml -f 25 ~/update_rhosp_repos.yaml --limit <undercloud>,<Controller>,<Compute>
    • --limit オプションを使用して、コンテンツをすべての RHOSP ノードに適用します。<undercloud><Controller><Compute> を、それらのノードを含む環境内の Ansible グループに置き換えます。
    • これらのノードに別のサブスクリプションを使用している場合は、Ceph Storage ノードに対してこの Playbook を実行することはできません。
  9. すべてのノードで、リポジトリーを Red Hat OpenStack Platform 16.1 に設定するタスクが含まれる Playbook を作成します。

    $ cat > ~/update_ceph_repos.yaml <<'EOF'
    - hosts: all
      gather_facts: false
      tasks:
        - name: change ceph repos
          command: subscription-manager repos --disable=openstack-16-deployment-tools-for-rhel-8-x86_64-rpms --enable=openstack-16.1-deployment-tools-for-rhel-8-x86_64-rpms --disable=ansible-2.8-for-rhel-8-x86_64-rpms --enable=ansible-2.9-for-rhel-8-x86_64-rpms
          become: true
    EOF
  10. update_ceph_repos.yaml Playbook を実行します。

    $ ansible-playbook -i ~/inventory.yaml -f 25 ~/update_ceph_repos.yaml --limit CephStorage

    --limit オプションを使用して、コンテンツを Ceph Storage ノードに適用します。

2.4. container-tools のバージョンの設定

container-toolsモジュールをバージョン2.0に設定して、すべてのノードで正しいパッケージバージョンを使用するようにします。

手順

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

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

    $ tripleo-ansible-inventory --ansible_ssh_user heat-admin --static-yaml-inventory ~/inventory.yaml

    デフォルトのオーバークラウド名 overcloud 以外のオーバークラウド名を使用する場合は、--plan オプションを使用して実際のオーバークラウドの名前を設定します。

  4. すべてのノードで container-tools モジュールをバージョン 2.0 に設定するタスクが含まれる Playbook を作成します。

    $ cat > ~/container-tools.yaml <<'EOF'
    - hosts: all
      gather_facts: false
      tasks:
        - name: disable default dnf module for container-tools
          command: dnf module reset -y container-tools
          become: true
        - name: set dnf module for container-tools:2.0
          command: dnf module enable -y container-tools:2.0
          become: true
    EOF
  5. すべてのノードに対して container-tools.yaml Playbook を実行します。

    $ ansible-playbook -i ~/inventory.yaml -f 25 ~/container-tools.yaml

2.5. コンテナーイメージ準備ファイルの更新

コンテナー準備ファイルは、ContainerImagePrepare パラメーターが含まれるファイルです。このファイルを使用して、アンダークラウドおよびオーバークラウドのコンテナーイメージを取得する際のルールを定義します。環境を更新する前に、ファイルを確認して正しいイメージバージョンを取得するようにしてください。

手順

  1. コンテナー準備ファイルを編集します。通常、このファイルのデフォルト名は containers-prepare-parameter.yaml です。
  2. それぞれのルールセットについて、tag パラメーターが 16.1 に設定されていることを確認します。

    parameter_defaults:
      ContainerImagePrepare:
      - push_destination: true
        set:
          …​
          tag: '16.1'
        tag_from_label: '{version}-{release}'
注記

更新に特定のタグ (16.116.1.2 等) を使用しない場合は、tag キーと値のペアを削除し、tag_from_label のみを指定します。これにより、更新プロセスの一部として使用するタグの値を決定する際に、インストールされた Red Hat OpenStack Platform バージョンが使用されます。

  1. このファイルを保存します。

2.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 パブリックエンドポイントファイルを保存します。

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

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

コントローラーノードの更新プロセス中にフェンシングが環境にデプロイされると、オーバークラウドは特定ノードが無効であることを検出し、フェンシング操作を試みる場合があります。これにより、意図しない結果が生じる可能性があります。

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

手順

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

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

    $ ssh heat-admin@CONTROLLER_IP "sudo pcs property set stonith-enabled=false"
  4. fencing.yaml 環境ファイルで、EnableFencing パラメーターを false に設定し、更新プロセス中にフェンシングが無効のままとなるようにします。

第3章 アンダークラウドの更新

以下の手順では、アンダークラウドおよびそのオーバークラウドイメージを最新の Red Hat OpenStack Platform 16.1 バージョンに更新します。

3.1. コンテナー化されたアンダークラウドのマイナー更新の実施

director では、アンダークラウドノード上の主要なパッケージを更新するためのコマンドが提供されています。これにより、OpenStack Platform 環境の現行バージョン内のマイナー更新を実行することができます。

手順

  1. director に stack ユーザーとしてログインします。
  2. dnf コマンドを実行して、director の主要なパッケージをアップグレードします。

    $ sudo dnf update -y python3-tripleoclient* tripleo-ansible ansible
  3. director は openstack undercloud upgrade コマンドを使用して、アンダークラウドの環境を更新します。以下のコマンドを実行します。

    $ openstack undercloud upgrade
  4. アンダークラウドのアップグレードプロセスが完了するまで待ちます。
  5. アンダークラウドをリブートして、オペレーティングシステムのカーネルとその他のシステムパッケージを更新します。

    $ sudo reboot
  6. ノードがブートするまで待ちます。

3.2. オーバークラウドイメージの更新

現在のオーバークラウドイメージを新しいバージョンに置き換える必要があります。新しいイメージにより、director は最新バージョンの OpenStack Platform ソフトウェアを使用してノードのイントロスペクションとプロビジョニングを行うことができるようになります。

前提条件

  • アンダークラウドが最新バージョンに更新されていること

手順

  1. stackrc ファイルを取得します。

    $ source ~/stackrc
  2. stack ユーザーのホーム下の images ディレクトリー (/home/stack/images) から既存のイメージを削除します。

    $ rm -rf ~/images/*
  3. アーカイブをデプロイメントします。

    $ cd ~/images
    $ for i in /usr/share/rhosp-director-images/overcloud-full-latest-16.1.tar /usr/share/rhosp-director-images/ironic-python-agent-latest-16.1.tar; do tar -xvf $i; done
    $ cd ~
  4. director に最新のイメージをインポートします。

    $ openstack overcloud image upload --update-existing --image-path /home/stack/images/
  5. ノードが新しいイメージを使用するように設定します。

    $ openstack overcloud node configure $(openstack baremetal node list -c UUID -f value)
  6. 新規イメージが存在することを確認します。

    $ openstack image list
    $ ls -l /var/lib/ironic/httpboot
重要
  • オーバークラウドノードをデプロイする際には、オーバークラウドイメージのバージョンが該当する heat テンプレートバージョンに対応している状態にします。たとえば、RHOSP 16.1 heat テンプレートでは RHOSP 16.1 イメージのみを使用します。
  • Red Hat カスタマーポータルまたは Red Hat Satellite Server を使用する接続環境をデプロイした場合、オーバークラウドのイメージとパッケージリポジトリーのバージョンが同期していない可能性があります。オーバークラウドのイメージとパッケージリポジトリーのバージョンが一致していることを確認するには、virt-customize ツールを使用できます。詳細は、Red Hat ナレッジベースで Modifying the Red Hat Linux OpenStack Platform Overcloud Image with virt-customize のソリューションを参照してください。
  • 新しい overcloud-full イメージは、古い overcloud-full イメージを置き換えます。古いイメージに変更を加えた場合、特に今後新規ノードをデプロイする場合は、新しいイメージで変更を繰り返す必要があります。

3.3. アンダークラウドアップグレード後の注意事項

  • stack ユーザーのホームディレクトリーでコアテンプレートのローカルセットを使用している場合には、Advanced Overcloud CustomizationUsing Customized Core Heat Templates に記載の推奨ワークフローを使用して、テンプレートを更新するようにしてください。オーバークラウドをアップグレードする前に、ローカルコピーを更新する必要があります。

第4章 オーバークラウドの更新

アンダークラウドを更新した後、オーバークラウドとコンテナーイメージの準備コマンドを実行し、ノードを更新し、オーバークラウドの更新収束コマンドを実行してオーバークラウドを更新できます。コントロールプレーン API は、マイナー更新中もすべて利用できます。

前提条件

  • アンダークラウドが最新バージョンに更新されていること

4.1. オーバークラウドの更新準備タスクの実施

更新プロセスに向けてオーバークラウドを準備するには、openstack overcloud update prepare のコマンドを実行して、以下のタスクを実施します。

  • オーバークラウドのプランを OpenStack Platform 16.1 に更新する。
  • 更新に向けてノードを準備する

前提条件

  • Ceph のサブスクリプションを使用し、Ceph ストレージノード用に overcloud-minimal イメージを使用するように director を設定している場合、roles_data.yaml ロール定義ファイルで rhsm_enforce パラメーターが False に設定されていることを確認する。
  • カスタム NIC テンプレートをレンダリングした場合は、オーバークラウドのバージョンとの非互換性を回避するために、openstack-tripleo-heat-templates コレクションの更新バージョンでテンプレートを再生成する必要があります。カスタム NIC テンプレートの詳細は、オーバークラウドの高度なカスタマイズ ガイドの カスタマイズのためのデフォルトのネットワークインターフェイステンプレートのレンダリング を参照してください。

手順

  1. stackrc ファイルを取得します。

    $ source ~/stackrc
  2. 更新準備コマンドを実行します。

    $ openstack overcloud update prepare \
        --templates \
        --stack <stack_name> \
        -r <roles_data_file> \
        -n <network_data_file> \
        -e <environment_file> \
        -e <environment_file> \
        …​

    以下のオプションの中で、お使いの環境に適切なオプションを追加します。

    • オーバークラウドスタックの名前がデフォルトの名前 overcloud とは異なる場合は、更新の準備コマンドに --stack オプションを追加し、<stack_name> を実際のスタック名に置き換えます。
    • 専用のカスタムロールを使用する場合は、カスタムロール (<roles_data>) ファイル を追加します (-r)。
    • カスタムネットワークを使用する場合は、コンポーザブルネットワーク (_<network_data>) ファイル _ を追加します (-n)。
    • 高可用性クラスターをデプロイする場合は、更新の準備コマンドに --ntp-server オプションを追加するか、環境ファイルに NtpServer パラメーターおよび値を追加します。
    • すべてのカスタム設定環境ファイル (-e)
  3. 更新の準備が完了するまで待ちます。

4.2. コンテナーイメージ準備タスクの実行

オーバークラウドの更新を実行するには、最新の OpenStack Platform 16.1 のコンテナーイメージが必要です。そのためには、container_image_prepare 外部更新プロセスを実行します。このプロセスを実行するには、container_image_prepare にタグ付けされたタスクに対して openstack overcloud external-update run コマンドを実行します。これらのタスクにより以下のアクションが実施されます。

  • お使いの環境に該当するすべてのコンテナーイメージ設定を自動的に準備する。
  • 事前にこのオプションを無効にしていない限り、該当するコンテナーイメージをアンダークラウドにプルする。
注記

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

手順

  1. stackrc ファイルを取得します。

    $ source ~/stackrc
  2. container_image_prepare にタグ付けされたタスクに対して openstack overcloud external-update run コマンドを実行します。

    $ openstack overcloud external-update run --stack <stack_name> --tags container_image_prepare

4.3. オプション: すべてのオーバークラウドサーバーでの ovn-controller コンテナーの更新

Modular Layer 2 Open Virtual Network メカニズムドライバー (ML2/OVN) を使用してオーバークラウドをデプロイした場合は、ovn-controller コンテナーを最新の RHOSP 16.1 バージョンに更新します。更新は、ovn-controller コンテナーを実行するすべてのオーバークラウドサーバーで行われます。

注記

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

手順

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

    $ source ~/stackrc
  3. ovn タグを持つタスクに対して openstack overcloud external-update run コマンドを実行します。

    $ openstack overcloud external-update run --stack <stack_name> --tags ovn
  4. ovn-controller コンテナーの更新が完了するまで待ちます。

4.4. すべてのコントローラーノードの更新

以下の手順では、すべてのコントローラーノードを最新バージョンの OpenStack Platform 16.1 に更新します。このプロセスでは、--limit Controllerer オプションを指定して openstack overcloud update run コマンドを実行し、操作をコントローラーノードだけに制限します。コントロールプレーン API は、マイナー更新中もすべて利用できます。

重要

BZ#1872404 が解決されるまで、コンポーザブルロールに基づくノードについては、先ず Database ロールを更新してから、ControllerMessagingComputeCeph、およびその他のロールを更新する必要があります。

注記

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

手順

  1. stackrc ファイルを取得します。

    $ source ~/stackrc
  2. 更新コマンドを実行します。

    $ openstack overcloud update run --stack <stack_name> --limit Controller
  3. コントローラーノードの更新が完了するまで待ちます。

4.5. すべてのコンピュートノードの更新

以下の手順では、すべてのコンピュートノードを最新バージョンの OpenStack Platform 16.1 に更新します。このプロセスは、openstack overcloud update run コマンドに --limit Compute オプションを指定して、操作をコンピュートノードのみに制限して実行する必要があります。

並列処理に関する考慮事項

多数のコンピュートノードをアップグレードする場合は、パフォーマンスを向上させるために、--limit Compute オプションを指定して openstack overcloud upgrade run コマンドを実行し、20 ノードのバッチを並行して処理することができます。たとえば、デプロイメントに 80 のコンピュートノードがある場合、次のコマンドを実行して、コンピュートノードを並行して更新できます。

$ openstack overcloud update run -y --limit 'Compute[0:19]' > update-compute-0-19.log 2>&1 &
$ openstack overcloud update run -y --limit 'Compute[20:39]' > update-compute-20-39.log 2>&1 &
$ openstack overcloud update run -y --limit 'Compute[40:59]' > update-compute-40-59.log 2>&1 &
$ openstack overcloud update run -y --limit 'Compute[60:79]' > update-compute-60-79.log 2>&1 &

'Compute[0:19]''Compute[20:39]''Compute[40:59]'、および 'Compute[60:79]' のノード領域分割方法はランダムで、更新されるノードを制御することはできません。

特定のコンピュートノードを更新するには、バッチで更新するノードをコンマ区切りリストで指定します。

$ openstack overcloud update run --limit <Compute0>,<Compute1>,<Compute2>,<Compute3>
注記

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

手順

  1. stackrc ファイルを取得します。

    $ source ~/stackrc
  2. 更新コマンドを実行します。

    $ openstack overcloud update run --stack <stack_name> --limit Compute
  3. コンピュートノードの更新が完了するまで待ちます。

4.6. 全 HCI コンピュートノードの更新

以下の手順では、ハイパーコンバージドインフラストラクチャー (HCI) コンピュートノードを更新します。このプロセスでは、以下の操作を行います。

  • openstack overcloud update run コマンドに --limit ComputeHCI オプションを指定して、操作を HCI ノードのみに制限して実行する
  • openstack overcloud external-update run --tags ceph コマンドを実行し、コンテナー化された Red Hat Ceph Storage 4 クラスターへの更新を実施する
注記

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

前提条件

  • ceph-mon サービスを実行している Ceph Monitor または Controller ノードで、Red Hat Ceph Storage クラスターのステータスが正常であり、pg ステータスが active+clean であることを確認する。

    $ sudo podman exec -it ceph-mon-controller-0 ceph -s

    Ceph クラスターが正常な場合、HEALTH_OK のステータスが返されます。

    Ceph クラスターのステータスが異常な場合、HEALTH_WARN または HEALTH_ERR のステータスを返す。トラブルシューティングのガイダンスについては、Red Hat Ceph Storage 4 トラブルシューティングガイドを 参照してください。

手順

  1. stackrc ファイルを取得します。

    $ source ~/stackrc
  2. 更新コマンドを実行します。

    $ openstack overcloud update run --stack <stack_name> --limit ComputeHCI
  3. ノードの更新が完了するまで待ちます。
  4. Ceph Storage の更新コマンドを実行します。以下に例を示します。

    $ openstack overcloud external-update run --stack <stack_name> --tags ceph
  5. コンピュート HCI ノードの更新が完了するまで待ちます。

4.7. すべての Ceph Storage ノードの更新

以下の手順では、Ceph Storage ノードを更新します。このプロセスでは、以下の操作を行います。

  • openstack overcloud update run コマンドに --limit CephStorage オプションを指定して、操作を Ceph Storage ノードのみに制限して実行する
  • openstack overcloud external-update run コマンドを実行して外部プロセスとして ceph-ansible を実行し、Red Hat Ceph Storage 3 コンテナーを更新する。
重要

RHOSP 16.1 は RHEL 8.2 でサポートされています。ただし、Ceph Storage ロールにマップされているホストは、最新のメジャー RHEL リリースに更新されます。詳細は、Red Hat Ceph Storage: サポートされる設定 を参照してください。

注記

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

前提条件

  • ceph-mon サービスを実行している Ceph Monitor または Controller ノードで、Red Hat Ceph Storage クラスターのステータスが正常であり、pg ステータスが active+clean であることを確認する。

    $ sudo podman exec -it ceph-mon-controller-0 ceph -s

    Ceph クラスターが正常な場合、HEALTH_OK のステータスが返されます。

    Ceph クラスターのステータスが異常な場合、HEALTH_WARN または HEALTH_ERR のステータスを返す。トラブルシューティングのガイダンスについては、Red Hat Ceph Storage 4 トラブルシューティングガイドを 参照してください。

手順

  1. stackrc ファイルを取得します。

    $ source ~/stackrc
  2. グループノードを更新します。

    グループ内のすべてのノードを更新するには、以下のコマンドを実行します。

    $ openstack overcloud update run --limit <GROUP_NAME>

    グループ内の単一ノードを更新するには、以下のコマンドを実行します。

    $ openstack overcloud update run --limit <GROUP_NAME> [NODE_INDEX]
    注記

    ノードを個別に更新する場合は、必ずすべてのノードを更新してください。

    グループ内の最初のノードのインデックスはゼロ (0) です。たとえば、CephStorage という名前のグループの最初のノードを更新するには、以下のコマンドを実行します。

    openstack overcloud update run --limit CephStorage[0]

  3. ノードの更新が完了するまで待ちます。
  4. Ceph Storage コンテナーの更新コマンドを実行します。

    $ openstack overcloud external-update run --tags ceph
  5. Ceph Storage コンテナーの更新が完了するまで待ちます。

4.8. データベースのオンライン更新の実施

一部のオーバークラウドコンポーネントでは、データベーステーブルのオンラインアップグレード (または移行) が必要です。そのためには、online_upgrade 外部更新プロセスを実行します。このプロセスを実行するには、online_upgrade にタグ付けされたタスクに対して openstack overcloud external-update run コマンドを実行します。これにより、以下のコンポーネントに対してデータベースのオンライン更新が実行されます。

  • OpenStack Block Storage (cinder)
  • OpenStack Compute (nova)

手順

  1. stackrc ファイルを取得します。

    $ source ~/stackrc
  2. online_upgrade のタグを使用するタスクに対して openstack overcloud external-update run コマンドを実行します。

    $ openstack overcloud external-update run --tags online_upgrade

4.9. 更新の最終処理

更新には、オーバークラウドスタックを更新する最終ステップが必要です。これにより、スタックのリソース構造が OpenStackPlatform 16.1 の標準のデプロイメントと一致し、今後、通常の openstack overcloud deploy の機能を実行できるようになります。

手順

  1. stackrc ファイルを取得します。

    $ source ~/stackrc
  2. オーバークラウドでフェンシングを再度有効にするには、fencing.yaml 環境ファイルで、EnableFencing パラメーターを true に設定します。
  3. 更新の最終処理のコマンドを実行します。

    $ openstack overcloud update converge \
        --templates \
        --stack <stack_name> \
        -r <roles_data_file> \
        -n <network_data_file> \
        -e <environment_file> \
        -e <environment_file> \
        ...
        ...

    以下のオプションの中で、お使いの環境に適切なオプションを追加します。

    • EnableFencing パラメーターが true に設定された fencing.yaml 環境ファイル。
    • オーバークラウドスタックの名前がデフォルトの名前 overcloud とは異なる場合は、更新の準備コマンドに --stack オプションを追加し、<stack_name> を実際のスタック名に置き換えます。
    • 専用のカスタムロールを使用する場合は、カスタムロール (<roles_data>) のファイルを追加します (-r)
    • カスタムネットワークを使用する場合は、コンポーザブルネットワーク (<network_data>) のファイルを追加します (-n)
    • すべてのカスタム設定環境ファイル (-e)
  4. 更新の最終処理が完了するまで待ちます。

第5章 オーバークラウドのリブート

Red Hat OpenStack バージョンのマイナー更新後に、オーバークラウドをリブートします。リブートにより、関連付けられたカーネル、システムレベル、およびコンテナーコンポーネントの更新と共にノードがリフレッシュされます。これらの更新により、パフォーマンスとセキュリティー上のメリットが得られます。

ダウンタイムを計画して、以下のリブート手順を実施します。

5.1. コントローラーノードおよびコンポーザブルノードのリブート

コントローラーノードおよびコンポーザブルロールに基づくスタンドアロンのノードをリブートするには、以下の手順を実施します。ただし、これにはコンピュートノードおよび Ceph Storage ノードは含まれません。

手順

  1. リブートするノードにログインします。
  2. オプション: ノードが Pacemaker リソースを使用している場合は、クラスターを停止します。

    [heat-admin@overcloud-controller-0 ~]$ sudo pcs cluster stop
  3. ノードをリブートします。

    [heat-admin@overcloud-controller-0 ~]$ sudo reboot
  4. ノードがブートするまで待ちます。
  5. サービスを確認します。以下に例を示します。

    1. ノードが Pacemaker サービスを使用している場合には、ノードがクラスターに再度加わったかどうかを確認します。

      [heat-admin@overcloud-controller-0 ~]$ sudo pcs status
    2. ノードが Systemd サービスを使用している場合は、すべてのサービスが有効化されていることを確認します。

      [heat-admin@overcloud-controller-0 ~]$ sudo systemctl status
    3. ノードがコンテナー化されたサービスを使用している場合は、ノード上の全コンテナーがアクティブであることを確認します。

      [heat-admin@overcloud-controller-0 ~]$ sudo podman ps

5.2. Ceph Storage (OSD) クラスターの再起動

Ceph Storage (OSD) ノードのクラスターを再起動するには、以下の手順を実施します。

前提条件

  • ceph-mon サービスを実行している Ceph Monitor または Controller ノードで、Red Hat Ceph Storage クラスターのステータスが正常であり、pg ステータスが active+clean であることを確認する。

    $ sudo podman exec -it ceph-mon-controller-0 ceph -s

    Ceph クラスターが正常な場合、HEALTH_OK のステータスが返されます。

    Ceph クラスターのステータスが異常な場合、HEALTH_WARN または HEALTH_ERR のステータスを返す。トラブルシューティングのガイダンスについては、Red Hat Ceph Storage 4 トラブルシューティングガイドを 参照してください。

手順

  1. ceph-mon サービスを実行している Ceph Monitor または Controller ノードにログインし、Ceph Storage クラスターのリバランスを一時的に無効にします。

    $ sudo podman exec -it ceph-mon-controller-0 ceph osd set noout
    $ sudo podman exec -it ceph-mon-controller-0 ceph osd set norebalance
    注記

    マルチスタックまたは分散コンピュートノード (DCN) アーキテクチャーを使用している場合は、 nooutフラグとnorebalanceフラグの設定時にクラスター名を指定する必要があります。例: sudo podman exec -it ceph-mon-controller-0 ceph osd set noout --cluster <cluster_name>

  2. 再起動する最初の Ceph Storage ノードを選択し、そのノードにログインします。
  3. ノードを再起動します。

    $ sudo reboot
  4. ノードがブートするまで待ちます。
  5. ノードにログインして、クラスターのステータスを確認します。

    $ sudo podman exec -it ceph-mon-controller-0 ceph status

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

  6. ノードからログアウトして、次のノードをリブートし、ステータスを確認します。全 Ceph Storage ノードがリブートされるまで、このプロセスを繰り返します。
  7. 完了したら、ceph-mon サービスを実行している Ceph Monitor または Controller ノードにログインし、クラスターの再調整を再度有効にします。

    $ sudo podman exec -it ceph-mon-controller-0 ceph osd unset noout
    $ sudo podman exec -it ceph-mon-controller-0 ceph osd unset norebalance
    注記

    マルチスタックまたは分散コンピュートノード (DCN) アーキテクチャーを使用している場合は、 nooutフラグとnorebalanceフラグの設定解除時にクラスター名を指定する必要があります。例: sudo podman exec -it ceph-mon-controller-0 ceph osd set noout --cluster <cluster_name>

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

    $ sudo podman exec -it ceph-mon-controller-0 ceph status

5.3. コンピュートノードの再起動

コンピュートノードをリブートするには、以下の手順を実施します。Red Hat OpenStack Platform 環境内のインスタンスのダウンタイムを最小限に抑えるために、この手順には、リブートするコンピュートノードからインスタンスを移行するステップも含まれています。これは、以下のワークフローを伴います。

  • コンピュートノードをリブートする前に、インスタンスを別のノードに移行するかどうかを決定する。
  • リブートするコンピュートノードを選択して無効にし、新規インスタンスをプロビジョニングしないようにする。
  • インスタンスを別のコンピュートノードに移行する。
  • 空のコンピュートノードを再起動します。
  • 空のコンピュートノードを有効にします。

前提条件

コンピュートノードをリブートする前に、ノードをリブートする間インスタンスを別のコンピュートノードに移行するかどうかを決定する必要があります。

コンピュートノード間で仮想マシンインスタンスを移行する際に受ける可能性のある移行の制約のリストを確認してください。詳細は、Configuring the Compute Service for Instance CreationMigration constraints を参照してください。

インスタンスを移行できない場合は、以下のコアテンプレートパラメーターを設定して、コンピュートノード再起動後のインスタンスの状態を制御する。

NovaResumeGuestsStateOnHostBoot
リブート後のコンピュートノードで、インスタンスを同じ状態に戻すか定義します。False に設定すると、インスタンスは停止した状態を維持し、手動で起動する必要があります。デフォルト値は False です。
NovaResumeGuestsShutdownTimeout
再起動する前に、インスタンスのシャットダウンを待つ秒数。この値を 0 に設定することは推奨されません。デフォルト値は 300 です。

オーバークラウドパラメーターおよびその使用方法についての詳細は、オーバークラウドのパラメーター を参照してください。

手順

  1. アンダークラウドに stack ユーザーとしてログインします。
  2. 全コンピュートノードとその UUID をリスト表示します。

    $ source ~/stackrc
    (undercloud) $ openstack server list --name compute

    リブートするコンピュートノードの UUID を特定します。

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

    $ source ~/overcloudrc
    (overcloud) $ openstack compute service list
    (overcloud) $ openstack compute service set <hostname> nova-compute --disable
  4. コンピュートノード上の全インスタンスをリスト表示します。

    (overcloud) $ openstack server list --host <hostname> --all-projects
  5. インスタンスを移行しない場合は、このステップ に進みます。
  6. インスタンスを別のコンピュートノードに移行する場合には、以下のコマンドのいずれかを使用します。

    • インスタンスを別のホストに移行する。

      (overcloud) $ openstack server migrate <instance_id> --live <target_host> --wait
    • nova-scheduler がターゲットホストを自動的に選択できるようにします。

      (overcloud) $ nova live-migration <instance_id>
    • すべてのインスタンスを一度にライブマイグレーションします。

      $ nova host-evacuate-live <hostname>
      注記

      nova コマンドで非推奨の警告が表示される可能性がありますが、無視しても問題ありません。

  7. 移行が完了するまで待ちます。
  8. 移行が正常に完了したことを確認します。

    (overcloud) $ openstack server list --host <hostname> --all-projects
  9. 選択したコンピュートノードのインスタンスがなくなるまで、移行を続けます。
  10. コンピュートノードにログインして、ノードをリブートします。

    [heat-admin@overcloud-compute-0 ~]$ sudo reboot
  11. ノードが起動するまで待ちます。
  12. コンピュートノードを再度有効にします。

    $ source ~/overcloudrc
    (overcloud) $ openstack compute service set <hostname>  nova-compute --enable
  13. コンピュートノードが有効であることを確認します。

    (overcloud) $ openstack compute service list