Red Hat Training

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

Red Hat OpenStack Platform のアップグレード

Red Hat OpenStack Platform 10

Red Hat OpenStack Platform 環境のアップグレード

概要

本書では、Red Hat OpenStack Platform 9(Mitaka)から 10(Newton)にアップグレードする複数の異なる方法について説明します。これらの方法は、アップグレード元およびアップグレード先のいずれも Red Hat Enterprise Linux 7 をベースにインストールされた OpenStack デプロイメントであることを前提としています。

第1章 はじめに

本書では、Red Hat OpenStack Platform を最新の状態に維持するプロセスについて説明します。本書では、Red Hat OpenStack Platform 10(Newton) を対象とするアップグレードおよび更新に重点を置いています。

Red Hat は、Red Hat Enterprise Linux 7.3 での Red Hat OpenStack Platform 10 へのアップグレードのみをサポートします。さらに、Red Hat は、以下の異なるシナリオを以下の条件に基づいて推奨しています。

  • director ベースのオーバークラウドまたは手動で作成した環境を使用している。
  • 高可用性ツールを使用して、クラスター内のコントローラーノードのセットを管理します。

「アップグレードシナリオの比較」 では、すべてのアップグレードシナリオを説明します。このようなシナリオでは、作業用の Red Hat OpenStack Platform 10 リリースにアップグレードし、そのバージョン内でマイナーアップデートを行うことができます。

1.1. アップグレードシナリオの比較

Red Hat は、Red Hat OpenStack Platform 10 に以下のアップグレードシナリオを推奨します。以下の表には、それぞれの簡単な説明をまとめています。

警告

Red Hat Enterprise Linux 7.3 カーネルにアップグレードするには、Open vSwitch (OVS) 2.4.0 も OVS 2.5.0 にアップグレードする必要があります。カーネルだけアップグレードすると、OVS は機能しなくなります。

表1.1 アップグレードシナリオ

方法説明

director ベースの環境: マイナーバージョンへの更新の実行

このシナリオでは、Red Hat OpenStack Platform 10 のマイナーバージョンから新しいバージョンの Red Hat OpenStack Platform 10 への更新について説明します。そのためには、director のパッケージを更新し、続いて director を使用してオーバークラウド内の全ノード上でパッケージの更新を起動します。

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

このシナリオは、Red Hat OpenStack Platform のメジャーバージョンからアップグレードするためのものです。この場合は、バージョン 9 から 10 にアップグレードします。そのためには、director のパッケージを更新し、続いて director を使用して各ノードでアップグレードスクリプトを追加し、続いてオーバークラウドスタックのアップグレードを実行する必要があります。

直接以外の環境: OpenStack サービスのアップグレード

このシナリオは、管理に director を使用しない Red Hat OpenStack Platform 環境内の全パッケージをアップグレードすることです(例: 手動で作成された環境)。このシナリオでは、すべてのパッケージを同時にアップグレードします。

直接以外の環境: 標準環境での個別の OpenStack サービス(Live Compute)のアップグレード

このシナリオは、管理に director を使用しない Red Hat OpenStack Platform 環境内の全パッケージをアップグレードすることです(例: 手動で作成された環境)。このシナリオでは、各 OpenStack サービスを個別に更新します。

直接以外の環境: 高可用性環境での個別の OpenStack サービス(Live Compute)のアップグレード

このシナリオでは、管理に director を使用せず(例: 手動で作成された環境など)、コントローラーベースの OpenStack サービスに高可用性ツールを使用する Red Hat OpenStack Platform 環境内の全パッケージをアップグレードします。このシナリオでは、各 OpenStack サービスを個別に更新します。

すべてのメソッドの場合:

  • 本リリースの正しいリポジトリーを全ホストで有効にしていることを確認します。
  • アップグレードには、一部のサービスの中断が発生します。
  • コンピュートノードをリブートするか、インスタンスを明示的にシャットダウンしない限り、実行中のインスタンスはアップグレードプロセスの影響を受けません。
警告

Red Hat は、Red Hat OpenStack Platform のベータリリースからサポートされるリリースへのアップグレードをサポートしません。

1.2. リポジトリーの要件

アンダークラウドおよびオーバークラウドにはいずれも、Red Hat コンテンツ配信ネットワーク (CDN) または Red Hat Satellite 5 もしくは 6 のいずれかを使用した Red Hat リポジトリーへのアクセスが必要です。Red Hat Satellite Server を使用する場合は、必要なリポジトリーをお使いの OpenStack Platform 環境に同期します。以下の CDN チャネル名一覧を参考にしてください。

表1.2 OpenStack Platform リポジトリー

名前

リポジトリー

要件の説明

Red Hat Enterprise Linux 7 Server (RPMs)

rhel-7-server-rpms

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

Red Hat Enterprise Linux 7 Server - Extras (RPM)

rhel-7-server-extras-rpms

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

Red Hat Enterprise Linux 7 Server - RH Common (RPMs)

rhel-7-server-rh-common-rpms

Red Hat OpenStack Platform のデプロイと設定用のツールが含まれます。

Red Hat Satellite Tools for RHEL 7 Server RPMs x86_64

rhel-7-server-satellite-tools-6.2-rpms

Red Hat Satellite 6 でのホスト管理ツール

Red Hat Enterprise Linux High Availability (for RHEL 7 Server) (RPMs)

rhel-ha-for-rhel-7-server-rpms

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

Red Hat Enterprise Linux OpenStack Platform 10 for RHEL 7 (RPMs)

rhel-7-server-openstack-10-rpms

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

Red Hat Ceph Storage OSD 2 for Red Hat Enterprise Linux 7 Server (RPMs)

rhel-7-server-rhceph-2-osd-rpms

(Ceph Storage ノード向け) Ceph Storage Object Storage デーモンのリポジトリー。Ceph Storage ノードにインストールします。

Red Hat Ceph Storage MON 2 for Red Hat Enterprise Linux 7 Server (RPMs)

rhel-7-server-rhceph-2-mon-rpms

(Ceph Storage ノード向け) Ceph Storage Monitor デーモンのリポジトリー。Ceph Storage ノードを使用して OpenStack 環境にあるコントローラーノードにインストールします。

Red Hat Ceph Storage Tools 2 for Red Hat Enterprise Linux 7 Server (RPMs)

rhel-7-server-rhceph-2-tools-rpms

Ceph Storage クラスターと通信するためのノード用のツールを提供します。このリポジトリーは、Ceph Storage クラスターを使用するオーバークラウドをデプロイする際に、すべてのオーバークラウドノードで有効にする必要があります。

注記

ネットワークがオフラインの Red Hat OpenStack Platform 環境用リポジトリーを設定するには、Red Hat カスタマーポータルで オフライン環境で Red Hat OpenStack Platform Director を設定する のアーティクルを参照してください。

1.3. アップグレードを開始する前に

アップグレードを実施する前に、ハードウェアに対するファームウェアの更新をすべて適用します。

第2章 director ベースの環境: マイナーバージョンへの更新の実行

本項では、同じバージョン内で Red Hat OpenStack Platform 環境のパッケージを更新する方法について説明します。今回の例では、Red Hat OpenStack Platform 10 内で更新されます。これには、アンダークラウドとオーバークラウドの両方の要素の更新が含まれます。

前提条件

  • OSP10 でマイナーアップデートを実行する前に、storage-environment.yaml ファイルを編集し、NodeDataLookup の UUID を小文字に設定する必要があります。詳細は、Red Hat ナレッジベースソリューションの「 minor update on OSP10 fails on ceph 」を参照してください。
警告

コンピュートインスタンスの高可用性(または コンピュートインスタンスの高可用性)では、アップグレードまたはスケールアップ操作を行うことができません。これを試みると失敗します。

インスタンス HA を有効にしている場合には、アップグレードまたはスケールアップを実行する前にインスタンスを無効にします。これを実行するには、「 ロールバック」の説明に従ってロールバック を実行 ます。

両方の状況においては、以下のワークフローが必要です。

  1. Red Hat OpenStack Platform director パッケージを更新します。
  2. Red Hat OpenStack Platform director 上のオーバークラウドイメージの更新
  3. Red Hat OpenStack Platform director を使用したオーバークラウドパッケージの更新

2.1. 更新前の注意事項

2.1.1. 一般的な推奨事項

更新を実行する前に、Red Hat は以下を推奨します。

  • 更新手順のステップを開始する前に、アンダークラウドノードのバックアップを実行します。バックアップ手順につい ては、『director のアンダークラウドのバックアップおよびリストア』を 参照してください。
  • Red Hat OpenStack Platform 10 ELS は Red Hat Enterprise Linux(RHEL)7.7 でのみサポートされます。そのため、更新を実行する前に RHEL バージョンを RHEL 7.7 に設定することが重要です。
  • OSP10 でマイナーアップデートを実行する前に、storage-environment.yaml ファイルを編集し、NodeDataLookup の UUID を小文字に設定する必要があります。詳細は、Red Hat ナレッジベースソリューションの「 minor update on OSP10 fails on ceph 」を参照してください。
  • 実稼働環境で手順を実行する前に、すべての変更を含むテスト環境で更新の手順を実行します。
  • 必要に応じて、Red Hat に連絡し、更新の実行に関するガイダンスやサポートを依頼してください。

2.1.2. NFV 事前設定

ネットワーク機能仮想化(NFV)が有効なオーバークラウドには、Open vSwitch(OVS)パッケージへの更新に対応するために追加の準備が必要です。OVS-DPDK を設定する際にこの移行をサポートするには、以下のガイドラインに従ってください。

注記

OVS-DPDK デプロイメントでは、Red Hat OpenStack Platform 10 と OVS 2.9 の組み合わせは、OVS クライアントモードで稼働します。

  1. カスタムの環境ファイル (例: network-environment.yaml) で、vhost ユーザーソケットディレクトリーを変更します。

    parameter_defaults:
      NeutronVhostuserSocketDir: "/var/lib/vhost_sockets"
  2. openstack overcloud deploy コマンドに ovs-dpdk-permissions.yaml ファイルを追加して、qemu グループの設定値を OVS-DPDK 向けに hugetlbfs に設定します。

     -e /usr/share/openstack-tripleo-heat-templates/environments/ovs-dpdk-permissions.yaml

2.2. Red Hat OpenStack Platform の更新

2.2.1. アンダークラウドパッケージの更新

director は、環境の更新に標準の RPM 方法に依存します。そのためには、director のホストが yum で最新のパッケージを使用するようにする必要があります。

  1. director に stack ユーザーとしてログインします。
  2. 主要な OpenStack Platform サービスを停止します。

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

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

  3. RHEL のバージョンを RHEL 7.7 に設定します。

    $ sudo subscription-manager release --set=7.7
  4. python-tripleoclient パッケージと依存関係を更新し、マイナーバージョンの更新向けの最新のスクリプトを使用できるようにします。

    $ sudo yum update python-tripleoclient
  5. director は openstack undercloud upgrade コマンドを使用して、アンダークラウドの環境を更新します。以下のコマンドを実行します。

    $ openstack undercloud upgrade

カーネルまたは Open vSwitch へのメジャーおよびマイナーバージョンの更新には、アンダークラウドのオペレーティングシステムが Red Hat Enterprise Linux 7.2 から 7.3 に更新された場合や、Open vSwitch がバージョン 2.4 から 2.5 に更新された場合など、リブートが必要です。director ノードの /var/log/yum.log ファイルをチェックして、kernel または openvswitch パッケージのメジャーまたはマイナーバージョンが更新されているかどうかを確認します。更新されている場合には、各ノードの再起動を実行します。

  1. ノードをリブートします。

    $ sudo reboot
  2. ノードがブートするまで待ちます。
  3. ノードがブートしたら、全サービスのステータスを確認します。

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

    リブート後に openstack-nova-compute がアクティブになるまでに約 10 分かかる場合があります。

  4. オーバークラウドとそのノードが存在することを確認します。

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

イメージの設定が最新の openstack-tripleo-heat-template パッケージの要件と一致するように、オーバークラウドのイメージを最新の状態に維持することが重要です。今後デプロイメントとスケーリング操作が正常に実行されるようにするには、「オーバークラウドイメージの更新」 に記載の手順に従ってオーバークラウドイメージを更新します。

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

アンダークラウドの更新プロセスで、rhosp-director-images および rhosp-director-images -ipa パッケージから新規イメージアーカイブがダウンロードされる可能性があります。yum ログをチェックして、新規イメージのアーカイブが利用可能かどうかを確認します。

$ sudo grep "rhosp-director-images" /var/log/yum.log

新規アーカイブが利用可能な場合には、現在のイメージを新規イメージに置き換えてください。新しいイメージをインストールするには、最初に stack ユーザーの images ディレクトリー (/home/stack/images) から既存のイメージを削除します。

$ rm -rf ~/images/*

アーカイブを展開します。

$ cd ~/images
$ for i in /usr/share/rhosp-director-images/overcloud-full-latest-10.0.tar /usr/share/rhosp-director-images/ironic-python-agent-latest-10.0.tar; do tar -xvf $i; done

最新のイメージを director にインポートして、ノードがこれらの新規イメージを使用するように設定します。

$ openstack overcloud image upload --update-existing --image-path /home/stack/images/
$ openstack baremetal configure boot

新規イメージがあるかどうかをチェックして、イメージ更新の最終処理を行います。

$ openstack image list
$ ls -l /httpboot

director が更新され、最新のイメージを使用するようになりました。この更新の後にはサービスを再起動する必要はありません。

2.2.3. オーバークラウドパッケージの更新

オーバークラウドは、環境を更新する標準の RPM 方法に依存します。これには、以下のステップを伴います。

  1. サブスクリプション管理の設定で rhel_reg_release パラメーターを確認します。このパラメーターが設定されていない場合は、それを追加してバージョン 7.7 に設定する必要があります。

    parameter_defaults:
      ...
      rhel_reg_release: "7.7"

    オーバークラウドのサブスクリプション管理用環境ファイルに加えた変更を、必ず保存してください。

  2. 元の openstack overcloud deploy コマンドに --update-plan-only オプションを追加して、現在のプランを更新します。例を以下に示します。

    $ openstack overcloud deploy --update-plan-only \
      --templates  \
      -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \
      -e /home/stack/templates/network-environment.yaml \
      -e /home/stack/templates/storage-environment.yaml \
      -e /home/stack/templates/rhel-registration/environment-rhel-registration.yaml \
      [-e <environment_file>|...]

    --update-plan-only のオプションを指定すると、director に保管されているオーバークラウドのプランのみが更新されます。-e を使用して、オーバークラウドと関連のある環境ファイルとその更新パスを追加します。後で実行される環境ファイルで定義されているパラメーターとリソースが優先されることになるため、環境ファイルの順序は重要となります。以下の一覧は、環境ファイルの順序の例です。

    • Heat テンプレートコレクションの初期化ファイル (environments/network-isolation.yaml) を含むネットワーク分離ファイルと、次にカスタムの NIC 設定ファイル
    • 外部のロードバランシングの環境ファイル
    • ストレージの環境ファイル
    • Red Hat CDN または Satellite 登録用の環境ファイル
    • その他のカスタム環境ファイル
  3. openstack overcloud update コマンドを使用して、全ノードでパッケージの更新を実行します。例を以下に示します。

    $ openstack overcloud update stack -i overcloud

    すべてのノードで並行して更新を実行すると、問題が発生する可能性があります。たとえば、パッケージの更新にはサービスの再起動が必要になる可能性があり、これにより他のノードが中断される可能性があります。このため、プロセスがブレークポイントのセットを使用して各ノードを更新するためです。これは、ノードが 1 つずつ更新されることを意味します。1 つのノードがパッケージの更新を完了すると、更新プロセスが次のノードに移動します。更新プロセスでは、各ブレークポイントで確認が必要なインタラクティブモードにコマンドを配置する -i オプションも必要です。-i オプションを指定しないと、最初のブレークポイントで更新が一時停止されたままになります。

これにより、更新プロセスが開始されます。このプロセス中に、director は IN_PROGRESS のステータスを報告して、ブレークポイントをクリアするように定期的に要求します。例を以下に示します。

not_started: [u'overcloud-controller-0', u'overcloud-controller-1', u'overcloud-controller-2']
on_breakpoint: [u'overcloud-compute-0']
Breakpoint reached, continue? Regexp or Enter=proceed, no=cancel update, C-c=quit interactive mode:

Enter を押すと、on_breakpoint 一覧の最後のノードからブレークポイントをクリアします。これで、そのノードの更新が開始します。特定のノードでノード名を入力してブレークポイントをクリアしたり、Python ベースの正規表現を使用して複数のノード上のブレークポイントを一度にクリアしたりすることもできます。ただし、複数のコントローラーノードのブレークポイントを一度にクリアすることは推奨されません。すべてのノードの更新が完了するまでこのプロセスを続行します。

更新が完了すると、コマンドにより COMPLETE のステータスが報告されます。

...
IN_PROGRESS
IN_PROGRESS
IN_PROGRESS
COMPLETE
update finished with status COMPLETE

コントローラーノードにフェンシングを設定している場合には、更新プロセスによってその設定が無効になる場合があります。更新プロセスが完了したら、いずれかのコントローラーノードで以下のコマンドを実行してフェンシングを再度有効にします。

$ sudo pcs property set stonith-enabled=true

更新プロセスを実行しても、オーバークラウド内のノードは自動的には再起動しません。カーネルまたは Open vSwitch へのメジャーおよびマイナーバージョンの更新には、オーバークラウドのオペレーティングシステムが Red Hat Enterprise Linux 7.2 から 7.3 に更新されるか、Open vSwitch がバージョン 2.4 から 2.5 に更新された場合など、再起動が必要です。各ノードの /var/log/yum.log ファイルをチェックして、kernel または openvswitch パッケージのメジャーまたはマイナーバージョンが更新されているかどうかを確認します。そのような場合には、director のインストールと使用方法』 の「オーバークラウドの再起動」に記載の 手順に従って、各ノードのリブートを実施します。

2.3. 更新後の注記

2.3.1. sshd コンポーザブルサービス

Red Hat OpenStack Platform 10 の最新アップデートには、ライブマイグレーション機能に必要な OS::TripleO::Services::Sshd コンポーザブルサービスが含まれています。director のコアテンプレートコレクションには、初期リリースにこのサービスは含まれませんでしたが、openstack-tripleo-heat-templates-5.2.0-12 パッケージおよびそれ以降のバージョンに含まれるようになりました。

デフォルトのロールデータファイルにはこのサービスが含まれ、director は更新時にオーバークラウドにサービスをインストールします。

カスタムロールデータファイルを使用する場合には、各オーバークラウドロールに OS::TripleO::Services::Sshd サービスを追加してから、オーバークラウドスタックを更新して新規サービスを含めます。

詳しくは、「Red Hat OpenStack Platform director(TripleO)CVE-2017-2637 bug and Red Hat OpenStack Platform "」 を参照してください。

2.3.2. NFV Post-Configuration

オーバークラウドでネットワーク機能仮想化(NFV)を使用する場合は、以下の手順に従って更新を終了します。

手順

既存の OVS-DPDK インスタンスを移行して、OVS ポートで vhost ソケットモードが dkdpvhostuser から dkdpvhostuserclient に変わることを確認します。既存のインスタンスのスナップショットを作成して、そのスナップショットイメージをベースに新規インスタンスを再ビルドすることを推奨します。インスタンスのスナップ ショットに関する詳細は、「インスタンスのスナップショットの管理」を 参照してください。

インスタンスのスナップショットを作成して、そのスナップショットから新規インスタンスを起動するには、以下の手順を実行します。

  1. スナップショットを作成するインスタンスのサーバー ID を確認します。

    # openstack server list
  2. スナップショットを作成する前に、元のインスタンスをシャットダウンして、全データがディスクにフラッシュされるようにしてください。

    # openstack server stop SERVER_ID
  3. インスタンスのスナップショットイメージを作成します。

    # openstack image create --id SERVER_ID SNAPSHOT_NAME
  4. このスナップショットイメージで新規インスタンスを起動します。

    # openstack server create --flavor DPDK_FLAVOR --nic net-id=DPDK_NET_ID --image SNAPSHOT_NAME INSTANCE_NAME
  5. オプションとして、新規インスタンスのステータスが ACTIVE であることを確認します。

    # openstack server list

スナップショットを作成する必要のある全インスタンスでこの手順を繰り返してから、再起動します。

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

警告

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

警告

コンピュートインスタンスの高可用性(または コンピュートインスタンスの高可用性)では、アップグレードまたはスケールアップ操作を行うことができません。これを試みると失敗します。

インスタンス HA を有効にしている場合には、アップグレードまたはスケールアップを実行する前にインスタンスを無効にします。これを実行するには、「 ロールバック」の説明に従ってロールバック を実行 ます。

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

両方の状況においては、以下のワークフローが必要です。

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

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

アップグレードプロセスでは、あるメジャーバージョンから次のメジャーバージョンへの変更に対応する準備が必要です。Red Hat OpenStack Platform のアップグレード計画についての詳細は、以下のサポートステートメントを参照してください。

Red Hat OpenStack Platform director のアップグレードには、ライブ実稼働環境で実行する前に、特定の設定を使用した完全なテストが必要です。Red Hat では、director で標準オプションとして提供されるほとんどのユースケースと組み合わせをテストしています。ただし、組み合わせことのできる組み合わせの数により、完全な一覧はありません。さらに、設定が手動または設定フックを使用して標準のデプロイメントから変更された場合には、実稼働以外の環境でアップグレード機能をテストすることが重要になります。そのため、以下を行うことをお勧めします。

  • アップグレード手順を開始する前に、アンダークラウドノードのバックアップを実行します。バックアップ手順につい ては、『director のアンダークラウドのバックアップおよびリストア』を 参照してください。
  • 実稼働環境で手順を実行する前に、テスト環境にカスタマイズしてアップグレード手順を実施します。
  • このアップグレードの実行に慣れていない場合は、先に進む前に、Red Hat のサポートチームに連絡し、アップグレードプロセスに関するガイダンスやサポートを依頼してください。

本項に記載するアップグレードプロセスは、director によるカスタマイズのみに対応します。director 外でオーバークラウド機能をカスタマイズした場合には、以下の操作を行います。

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

これは、アップグレード全体が完了するまでカスタマイズされた機能は利用できません。

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

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

バージョン

オーバークラウドの更新

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

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

Red Hat OpenStack Platform 10

Red Hat OpenStack Platform 9 および 10

Red Hat OpenStack Platform 9 および 10

Red Hat OpenStack Platform 9 および 10

古いバージョンのオーバークラウドを管理する場合には、以下の Heat テンプレートコレクションを使用します。* Red Hat OpenStack Platform 9 の場合: /usr/share/openstack-tripleo-heat-templates/mitaka/

例を以下に示します。

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

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

  • 各ステップの後に、コントローラーノードクラスターで pcs status コマンドを実行して、リソースが失敗していないことを確認します。
  • Red Hat に連絡し、アップグレードプロセスに関するガイダンスやサポートをリクエストしてから、このアップグレードの実行に適さない場合は、先に進みます。

3.2. アップグレードの重要な注意点

  • Red Hat OpenStack Platform 10 では、Red Hat Enterprise Linux 7.3 で新たなカーネルパラメーターが使用されるようになりました。アンダークラウドおよびオーバークラウドを Red Hat Enterprise Linux 7.3 および Open vSwitch 2.5 にアップグレードしている。アンダークラウドおよびオーバークラウドのパッケージの更新を 実行する方法については、「直接ベースの環境: マイナーバージョン への更新の実行」を参照してください。カーネルを最新バージョンに更新したら再起動を実行し、新しいカーネルパラメーターを有効にします。
  • OpenStack Platform 10 のアップグレード手順は、新しいコンポーザブルアーキテクチャーに移行します。これは、以前のバージョンで Pacemaker が管理するサービスの多くは、systemd 管理を使用するようになりました。これにより、Pacemaker が管理するリソースの数が少なくなります。
  • 以前のバージョンの Red Hat OpenStack Platform では、OpenStack Telemetry(ceilometer)はそのデータベースをメトリックストレージとして使用していました。Red Hat OpenStack Platform 10 では、OpenStack Telemetry のデフォルトバックエンドとして OpenStack Telemetry Metrics(gnocchi)が使用されます。メトリクスデータに外部の Ceph Storage クラスターを使用する場合には、Red Hat OpenStack 10 にアップグレードする前に外部の Ceph Storage クラスターに新しいプールを作成します。このプールの名前は GnocchiRbdPoolName パラメーターで設定され、デフォルトのプール名は metrics です。CephPools パラメーターを使用してプールの一覧をカスタマイズする場合は、メトリックプールを一覧に追加します。メトリクスデータのデータ移行計画はないことに注意してください。詳細は、「OpenStack Telemetry メトリクス」 を参照してください。
  • OpenStack Telemetry Alarms(aodh)の組み合わせが、複合アラームを優先して非推奨になりました。以下の点に留意してください。

    • aodh は、デフォルトで組み合わせたアラームを公開しません。
    • 新しいパラメーター EnableCombinationAlarms は、オーバークラウドで組み合わせたアラームを有効にします。デフォルトは false です。OpenStack Platform 10 で組み合わせたアラームを引き続き使用するには、true に設定します。
    • OpenStack Platform 10 には、複合アラームに移行する移行スクリプト(aodh-data-migration)が含まれています。本ガイドでは、「OpenStack Telemetry Alarming データベースの移行」 でこのデータを移行する手順を説明します。このスクリプトを実行して、アラームを複合に変換するようにしてください。
    • 組み合わせアラームのサポートは次のリリースで削除されます。

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

アップグレードを実行する前に、オーバークラウドが安定していることを確認してください。director で以下の手順を実施して、オーバークラウド内の全サービスが実行していることを確認します。

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

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

    [CONTROLLER_IP] をコントローラーノードの IP アドレスに置き換えます。このコマンドによりオーバークラウドの Pacemaker クラスターがリフレッシュされ、60 秒間待機した後、クラスターのステータスを報告します。

  2. オーバークラウドノードで、障害の発生した OpenStack Platform systemd サービスの有無を確認します。以下のコマンドは、すべてのノードで失敗したサービスをチェックします。

    $ for IP in $(openstack server list -c Networks -f csv | sed '1d' | sed 's/"//g' | cut -d '=' -f2) ; do echo "Checking systemd services on $IP" ; ssh heat-admin@$IP "sudo systemctl list-units 'openstack-*' 'neutron-*' --state=failed --no-legend" ; done
  3. os-collect-config が各ノードで実行されていることを確認します。以下のコマンドは、各ノードでこのサービスをチェックします。

    $ for IP in $(openstack server list -c Networks -f csv | sed '1d' | sed 's/"//g' | cut -d '=' -f2) ; do echo "Checking os-collect-config on $IP" ; ssh heat-admin@$IP "sudo systemctl list-units 'os-collect-config.service' --no-legend" ; done

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

3.4.1. director のアップグレード

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

  1. director に stack ユーザーとしてログインします。
  2. OpenStack Platform リポジトリーを更新します。

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

    これにより、yum が最新のリポジトリーを使用するように設定します。

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

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

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

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

    $ sudo yum update python-tripleoclient
  5. 以下のコマンドを使用してアンダークラウドをアップグレードします。

    $ openstack undercloud upgrade

    このコマンドにより、director のパッケージがアップグレードされ、director の設定が更新され、バージョンの変更以降に未設定の設定が行われます。このコマンドにより、保存したデータ(オーバークラウドのスタックデータや環境内の既存ノードのデータなど)は削除されません。

作成された各サービスの設定ファイルを確認します。アップグレードしたパッケージは、各サービスの Red Hat OpenStack Platform 10 バージョンに適した .rpmnew ファイルがインストールされている可能性があります。

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

  1. ノードをリブートします。

    $ sudo reboot
  2. ノードがブートするまで待ちます。
  3. ノードがブートしたら、全サービスのステータスを確認します。

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

    リブート後に openstack-nova-compute がアクティブになるまでに約 10 分かかる場合があります。

  4. オーバークラウドとそのノードが存在することを確認します。

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

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

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

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

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

この手順により、ノード検出およびオーバークラウドのデプロイメント用の最新イメージを確保することができます。rhosp-director-images および rhosp-director-images -ipa パッケージからの新しいイメージはすでにアンダークラウドのアップグレードから更新されています。

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

$ rm -rf ~/images/*

アーカイブを展開します。

$ cd ~/images
$ for i in /usr/share/rhosp-director-images/overcloud-full-latest-10.0.tar /usr/share/rhosp-director-images/ironic-python-agent-latest-10.0.tar; do tar -xvf $i; done

最新のイメージを director にインポートして、ノードがこれらの新規イメージを使用するように設定します。

$ openstack overcloud image upload --update-existing --image-path /home/stack/images/.
$ openstack baremetal configure boot

新規イメージがあるかどうかをチェックして、イメージ更新の最終処理を行います。

$ openstack image list
$ ls -l /httpboot

director が最新のイメージでアップグレードされるようになりました。

重要

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

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

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

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

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

以前のバージョンと最新バージョンを比較すると、アップグレード中にオーバークラウドへの変更を特定するのに役立ちます。現在のテンプレートコレクションを以前のバージョンと比較する必要がある場合は、以下のプロセスを使用します。

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

    $ cp -a /usr/share/openstack-tripleo-heat-templates /tmp/osp10
  2. 以前のバージョンをそれ独自のディレクトリーに移動します。

    $ mv /tmp/osp10/compat /tmp/osp9
  3. 両ディレクトリーのコンテンツに対して diff を実行します。

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

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

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

3.5.1. Red Hat Subscription Details

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

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

3.5.2. SSL 設定

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

  • ネットワーク設定では、以下の形式で PublicVirtualFixedIPs パラメーターが必要です。

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

    ネットワーク環境ファイルの parameter_defaults セクションに、このパラメーターを追加します。

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

    • IP アドレスを使用する場合には、/usr/share/openstack-tripleo-heat-templates/environments/tls-endpoints-public-ip.yaml を使用します。
    • DNS を使用する場合には、/usr/share/openstack-tripleo-heat-templates/environments/tls-endpoints-public-dns.yaml を使用します。
  • SSL/TLS 設定に関する詳細は、『 Red Hat OpenStack Platform のオーバークラウドの高度なカスタマイズ』「オーバークラウドでの SSL/TLS の有効化 」を参照してください。

3.5.3. Ceph Storage

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

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

RBD クライアントが以前の Ceph Storage ソフトウェアリリースと連携するようにするには、以下の Ceph Storage パラメーターも追加する必要があります。

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

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

3.5.4. OpenStack Telemetry メトリクス

Red Hat OpenStack Platform 10 では、メトリックデータを保管するための新しいコンポーネントが導入されました。カスタムの storage-environment.yaml ファイルでデプロイされた Red Hat Ceph Storage クラスターを使用する場合には、ファイルの parameters_default セクションで以下の新規パラメーターを確認してください。

  • GnocchiBackend: 使用するバックエンド。この rbd (Ceph Storage)を設定します。その他のオプションには、swift または ファイル などがあります。
  • GnocchiRbdPoolName: メトリックデータに使用する Ceph Storage プールの名前デフォルトは metrics です。

外部の Ceph Storage クラスター(例: director で管理されないクラスター)を使用する場合には、アップグレードを実行する前に GnocchiRbdPoolName (例: デフォルトは メトリクス)で定義されているプールを手動で追加する必要があります。

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

アップグレード用オーバークラウドパラメーターに関する情報は、以下の点に注意してください。

  • Red Hat OpenStack Platform 10 のデフォルトのタイムゾーンは UTC です。必要な場合は、タイムゾーンを指定するための環境ファイルを指定します。
  • カスタムの ServiceNetMap を使用してオーバークラウドをアップグレードする場合には、新規サービスの最新 ServiceNetMap を含めるようにしてください。サービスのデフォルト一覧は、network/service_net_map.j2.yaml ファイルにある ServiceNetMapDefaults パラメーターで定義されます。カスタム ServiceNetMap の使用に関する詳細は、『オーバークラウドの 高度なカスタマイズ』 の「ネットワーク分離 」を参照してください。
  • 新しいコンポーザブルサービスのアーキテクチャーにより、OpenStack Image Storage(Glance)の NFS バックエンドを設定するパラメーターが変更になりました。新しいパラメーターは以下のとおりです。

    GlanceNfsEnabled
    イメージストレージ用の共有を管理するための Pacemaker を有効にするパラメーター。無効に設定されている場合には、オーバークラウドはコントローラーノードのファイルシステムにイメージを保管します。true に設定します。
    GlanceNfsShare
    イメージストレージをマウントするための NFS 共有。たとえば、192.168.122.1:/export/glance と設定します。
    GlanceNfsOptions
    イメージストレージ用の NFS マウントオプション
  • 新しいコンポーザブルサービスのアーキテクチャーにより、一部の設定フックの構文が変更されます。設定前または事後の設定フックを使用して環境にカスタムスクリプトを提供する場合は、カスタム環境ファイルの構文を確認してください。『オーバークラウドの 高度なカスタマイズ』 の以下のセクションを使用してください。

  • 一部のコンポーザブルサービスには、Puppet hieradata を設定するための新規パラメーターが含まれます。hieradata を使用して以前のパラメーターを設定した場合には、オーバークラウドの更新で 重複宣言 のエラーが報告される可能性があります。そのような場合には、コンポーザブルサービスのパラメーターを使用します。たとえば、以下の代わりに使用できます。

    parameter_defaults:
      controllerExtraConfig:
        heat::config::heat_config:
          DEFAULT/num_engine_workers:
            value: 1

    以下を使用します。

    parameter_defaults:
      HeatWorkers: 1

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

重要

このセクションが必要なのは、コア Heat テンプレートコレクションの変更バージョンを使用する場合にのみ必要です。これは、/usr/share/openstack-tripleo-heat-templates/ からの元のコア Heat テンプレートコレクションの静的なスナップショットであるためです。未変更のコア Heat テンプレートコレクションをオーバークラウドに使用する場合には、このセクションを省略することができます。

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

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

    $ mv ~/templates/my-overcloud/ ~/templates/my-overcloud.bak
  2. /usr/share/openstack-tripleo-heat-templates からのテンプレートコレクションの新バージョンを置き換えます。

    $ sudo cp -rv /usr/share/openstack-tripleo-heat-templates ~/templates/my-overcloud/
  3. 古いカスタムテンプレートコレクションと新しいカスタムテンプレートコレクションの違いを確認します。この 2 つの間の変更を確認するには、以下の diff コマンドを使用します。

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

これにより、新しいテンプレートコレクションに組み込むことができる古いテンプレートコレクションからのカスタマイズを特定するのに役立ちます。新しいカスタムテンプレートコレクションにカスタマイズを組み込む。

重要

Red Hat は、今後のリリースで Heat テンプレートコレクションへの更新を提供します。変更したテンプレートコレクションを使用すると、カスタムコピーと /usr/share/openstack-tripleo-heat-templates 内の元のコピー間で分岐が生じる可能性があります。オーバークラウドをカスタマイズするには、Red Hat では 『オーバークラウドの高度なカスタマイズ』 の「 設定フック 」の使用を推奨します。Heat テンプレートコレクションのコピーを作成する場合には、git などのバージョン管理システムを使用してテンプレートへの変更を追跡する必要があります。

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

3.6.1. 概要とワークフロー

本項では、オーバークラウドのアップグレードに必要な手順を説明します。各セクションを順番に実行し、お使いの環境に関連するセクションのみを適用するようにしてください。

このプロセスには、アップグレードの段階的な方法を提供するために、元の openstack overcloud deploy コマンドを複数回実行する必要があります。コマンドを実行するたびに、既存の環境ファイルと共に異なるアップグレード環境ファイルを指定します。これらの新たなアップグレード環境ファイルは、以下のとおりです。

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

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

ワークフロー

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

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

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

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

undercloud から openstack overcloud deploy を実行し、major-upgrade-ceilometer-mitaka-newton.yaml 環境ファイルを追加します。ネットワーク分離やストレージなど、お使いの環境に関連するすべてのオプションおよびカスタム環境ファイルも追加するようにしてください。

以下は、ファイルが追加された openstack overcloud deploy コマンドの例です。

$ openstack overcloud deploy --templates \
  --control-scale 3 \
  --compute-scale 3 \
  -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \
  -e /usr/share/openstack-tripleo-heat-templates/environments/net-single-nic-with-vlans.yaml  \
  -e /home/stack/templates/network_env.yaml \
  -e /usr/share/openstack-tripleo-heat-templates/environments/major-upgrade-ceilometer-wsgi-mitaka-newton.yaml \
  --ntp-server pool.ntp.org

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

注記

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

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

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

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

undercloud から openstack overcloud deploy を実行し、major-upgrade-pacemaker-init.yaml 環境ファイルを追加します。ネットワーク分離やストレージなど、お使いの環境に関連するすべてのオプションおよびカスタム環境ファイルも追加するようにしてください。

以下は、ファイルが追加された openstack overcloud deploy コマンドの例です。

$ openstack overcloud deploy --templates \
  --control-scale 3 \
  --compute-scale 3 \
  -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \
  -e /usr/share/openstack-tripleo-heat-templates/environments/net-single-nic-with-vlans.yaml  \
  -e /home/stack/templates/network_env.yaml \
  -e /usr/share/openstack-tripleo-heat-templates/environments/major-upgrade-pacemaker-init.yaml \
  --ntp-server pool.ntp.org

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

注記

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

3.6.4. オブジェクトストレージノードのアップグレード

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

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

各オブジェクトストレージノードがアップグレードを完了するまで待ちます。

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

  1. リブートするオブジェクトストレージノードを選択します。そのノードにログインしてリブートします。

    $ sudo reboot
  2. ノードがブートするまで待ちます。
  3. ノードにログインしてステータスを確認します。

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

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

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

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

undercloud から openstack overcloud deploy を実行し、major-upgrade-pacemaker.yaml 環境ファイルを追加します。ネットワーク分離やストレージなど、お使いの環境に関連するオプションおよびカスタム環境ファイルをすべて追加するようにしてください。

コントローラーノードでは、OpenStack Data Processing(sahara)サービスを有効にしたかどうかによって、追加のファイルが必要になる場合があります。OpenStack Platform 9 では、デフォルトのオーバークラウド用の OpenStack Data Processing が自動的にインストールされます。OpenStack Platform 10 では、OpenStack Data Processing を有効化するために環境ファイルを明示的に追加する必要があります。この設定には、以下のような特徴があります。

  • OpenStack Data Processing が必要なくなった場合には、デプロイメントに major-upgrade-remove-sahara.yaml ファイルを追加します。
  • OpenStack Data Processing を維持する場合は、デプロイメントに major-upgrade-remove-sahara.yaml ファイルを含めないでください。オーバークラウドのアップグレードが完了したら、/usr/share/openstack-tripleo-heat-templates/environments/services/sahara.yaml を追加して、サービスを有効にし、設定するようにしてください。

必須およびオプションのファイルの両方を使用した openstack overcloud deploy コマンドの例を以下に示します。

$ openstack overcloud deploy --templates \
  --control-scale 3 \
  --compute-scale 3 \
  -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \
  -e /usr/share/openstack-tripleo-heat-templates/environments/net-single-nic-with-vlans.yaml \
  -e network_env.yaml \
  -e /usr/share/openstack-tripleo-heat-templates/environments/major-upgrade-pacemaker.yaml
  -e /usr/share/openstack-tripleo-heat-templates/environments/major-upgrade-remove-sahara.yaml \
  --ntp-server pool.ntp.org

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

重要

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

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

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

  1. リブートするノードを選択します。リブートする前に、そのノードにログインしてクラスターを停止します。

    $ sudo pcs cluster stop
  2. クラスターをリブートします。

    $ sudo reboot

    リブート中、クラスターの残りのコントローラーノードは高可用性サービスを維持します。

  3. ノードがブートするまで待ちます。
  4. ノードのクラスターを再度有効化します。

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

    $ sudo pcs status

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

    注記

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

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

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

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

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

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

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

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

各 Ceph Storage ノードの /var/log/yum.log ファイルをチェックして、カーネル または openvswitch パッケージのメジャーまたはマイナーバージョンが更新されているかどうかを確認します。その場合は、各 Ceph Storage ノードのリブートを実施します。

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

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

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

    $ sudo ceph -s

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

  6. ノードからログアウトして、次のノードをリブートし、ステータスを確認します。全 Ceph Storage ノードがリブートされるまで、このプロセスを繰り返します。
  7. 完了したら、Ceph MON またはコントローラーノードにログインして、クラスターのリバランスを再度有効にします。

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

    $ sudo ceph status
注記

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

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

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

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

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

$ openstack server list | grep "compute"

アップグレードするコンピュートノードを選択し、まず以下のプロセスを使用してインスタンスを移行します。

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

    $ source ~/overcloudrc
    $ openstack compute service list
    $ openstack compute service set [hostname] nova-compute --disable
  2. コンピュートノード上の全インスタンスを一覧表示します。

    $ openstack server list --host [hostname] --all-projects
  3. 無効にしたホストから各インスタンスを移行します以下のコマンドの 1 つを使用します。

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

      $ openstack server migrate [instance-id] --live [target-host]--wait
    2. nova-scheduler により対象のホストが自動的に選択されるようにする。

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

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

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

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

インスタンスの設定および移行に関する詳しい説明は、『 director のインストールと使用方法』の 「コンピュートノード間の仮想マシンインスタンスの移行」 を参照し てください。

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

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

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

アップグレードしたコンピュートノードの /var/log/yum.log ファイルをチェックして、カーネル または openvswitch パッケージのメジャーまたはマイナーバージョンが更新されているかどうかを確認します。その場合には、コンピュートノードのリブートを実施します。

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

    $ sudo reboot
  2. ノードがブートするまで待ちます。
  3. コンピュートノードを再度有効化します。

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

すべてのノードを再起動するまで、各ノードで移行およびリブートプロセスを繰り返します。

注記

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

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

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

重要

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

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

外部の Red Hat Ceph Storage バージョン 1.3 との後方互換性が必要な場合には、rbd_default_features を 1 に設定します。外部の Red Hat Ceph Storage クラスターがバージョン 2.0 以降であるか、または director を使用して Red Hat OpenStack Platform 環境をデプロイし、director により環境が Red Hat Ceph Storage バージョン 2.0 以降にアップグレードされている場合は、rbd_default_features63 に設定します。

次の手順で openstack overcloud deploy を実行する際に、このファイルを追加します。

undercloud から openstack overcloud deploy を実行し、major-upgrade-pacemaker-converge.yaml 環境ファイルを追加します。Ceph(該当する場合)、ネットワーク分離、ストレージなど、お使いの環境に関連するすべてのオプションおよびカスタム環境ファイルも追加するようにしてください。

これは、major-upgrade-pacemaker-converge.yaml ファイルを追加した openstack overcloud deploy コマンドの例です。

$ openstack overcloud deploy --templates \
  --control-scale 3 \
  --compute-scale 3 \
  -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \
  -e /usr/share/openstack-tripleo-heat-templates/environments/net-single-nic-with-vlans.yaml \
  -e network_env.yaml \
  -e /usr/share/openstack-tripleo-heat-templates/environments/major-upgrade-pacemaker-converge.yaml \
  --ntp-server pool.ntp.org

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

注記

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

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

この手順では、OpenStack Telemetry Alarming(aodh)サービスのデータベースを MongoDB から MariaDB に移行します。このプロセスでは、移行を自動的に実行します。

undercloud から openstack overcloud deploy を実行し、major-upgrade-aodh-migration.yaml 環境ファイルを追加します。ネットワーク分離やストレージなど、お使いの環境に関連するすべてのオプションおよびカスタム環境ファイルも追加するようにしてください。

以下は、ファイルが追加された openstack overcloud deploy コマンドの例です。

$ openstack overcloud deploy --templates \
  --control-scale 3 \
  --compute-scale 3 \
  -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \
  -e /usr/share/openstack-tripleo-heat-templates/environments/net-single-nic-with-vlans.yaml  \
  -e /home/stack/templates/network_env.yaml \
  -e /usr/share/openstack-tripleo-heat-templates/environments/major-upgrade-aodh-migration.yaml \
  --ntp-server pool.ntp.org

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

注記

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

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

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

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

  • 作成された各サービスの設定ファイルを確認します。アップグレードしたパッケージは、各サービスの Red Hat OpenStack Platform 10 バージョンに適した .rpmnew ファイルがインストールされている可能性があります。
  • 「コントローラーノードのアップグレード」 からオプションの major-upgrade-remove-sahara.yaml ファイルを追加しなかった場合には、/usr/share/openstack-tripleo-heat-templates/environments/services/sahara.yaml を追加して、OpenStack Clustering(sahara)がオーバークラウドで有効化された状態にするようにしてください。
  • コンピュートノードが neutron-openvswitch-agent の問題をレポートする可能性があります。これが発生した場合には、各コンピュートノードにログインして、このサービスを再起動します。例を以下に示します。

    $ sudo systemctl restart neutron-openvswitch-agent
  • アップグレードプロセスでは、オーバークラウド内のノードを自動的には再起動しません。必要な場合は、アップグレードコマンドの完了後に手動で再起動を実行します。クラスターベースのノード(Ceph Storage ノードやコントローラーノードなど)を個別にリブートし、ノードがクラスターに再参加するのを待ちます。Ceph Storage ノードの場合は、ceph の正常性 を確認し、クラスターのステータスが HEALTH OK であることを確認します。コントローラーノードの場合は、pcs resource をチェックして、全リソースが各ノードで実行されていることを確認します。
  • 状況によっては、コントローラーノードのリブート後に IPv6 環境で corosync サービスの起動に失敗する可能性があります。これは、コントローラーノードが静的な IPv6 アドレスを設定する前に Corosync が起動してしまうことが原因です。このような場合は、コントローラーノードで Corosync を手動で再起動してください。

    $ sudo systemctl restart corosync
  • コントローラーノードにフェンシングを設定している場合には、アップグレードプロセスにより無効にされる可能性があります。アップグレードプロセスが完了したら、いずれかのコントローラーノードで以下のコマンドを実行してフェンシングを再度有効にします。

    $ sudo pcs property set stonith-enabled=true
  • 次回オーバークラウドスタックを更新またはスケーリングする場合( openstack overcloud deploy コマンドの実行など)、オーバークラウドのパッケージの更新をトリガーする ID をリセットする必要があります。空の UpdateIdentifier パラメーターを環境ファイルに追加して、openstack overcloud deploy コマンドの実行時に追加します。以下は、そのような環境ファイルの例です。

    parameter_defaults:
      UpdateIdentifier:

第4章 直接以外の環境: OpenStack サービスのアップグレード

このシナリオでは、director を使用しない環境で Red Hat OpenStack Platform 9 から Red Hat OpenStack Platform 10 にアップグレードし ます。以下の手順では、全ノード上のサービスをすべてアップグレードします。これは、以下のワークフローを伴います。

  1. すべての OpenStack サービスの無効化
  2. パッケージアップグレードの実行
  3. すべてのデータベースの同期の実行
  4. すべての OpenStack サービスの有効化
注記

本章の手順では、アーキテクチャーの命名規則に続いて、すべての Red Hat OpenStack Platform ドキュメントに従います。規則に慣れていない場合は、先に進む前に、Red Hat OpenStack Platform ドキュメント スイート の『アーキテクチャーガイド』を参照してください。

4.1. すべての OpenStack サービスの無効化

ノード上での Red Hat OpenStack Platform の完全なアップグレードを実施する最初のステップとして、すべての OpenStack サービスをシャットダウンする必要があります。この手順は、OpenStack が管理に高可用性ツールを使用するかどうか(例: コントローラーノードで Pacemaker を使用するなど)によって異なります。このステップには、両方のノード種別の手順が含まれます。

標準のノード

更新前に、OpenStack Platform サービスの systemd スナップショットを作成します。

# systemctl snapshot openstack-services

メインの OpenStack Platform サービスを無効にします。

# systemctl stop 'openstack-*'
# systemctl stop 'neutron-*'
# systemctl stop 'openvswitch'

高可用性ノード

すべての OpenStack サービスを無効にし、データベースと負荷分散サービスをアクティブなままにする必要があります。たとえば、Pacemaker で HAProxy サービス、Galera サービス、および MongoDB サービスを管理対象外に切り替えます。

# pcs resource unmanage haproxy
# pcs resource unmanage galera
# pcs resource unmanage mongod

クラスターに stop-all-resources プロパティーを設定して、残りの Pacemaker が管理するリソースを無効にします。Pacemaker クラスターの単一メンバーで以下を実行します。

# pcs property set stop-all-resources=true

Pacemaker が管理するリソースがすべて停止するまで待ちます。pcs status コマンドを実行して、各リソースのステータスを確認します。

# pcs status
重要

HAProxy は利用できないサービスのブロードキャストメッセージが表示される可能性があります。これは通常の動作です。

4.2. パッケージアップグレードの実行

次の手順では、ノード上のパッケージをすべてアップグレードします。OpenStack サービスを使用する各ノードで、このステップを実行します。

subscription-manager コマンドを使用して、Red Hat OpenStack Platform 10 リポジトリーに切り替えます。

# subscription-manager repos --disable=rhel-7-server-openstack-9-rpms
# subscription-manager repos --enable=rhel-7-server-openstack-10-rpms

ノードで yum update コマンドを実行します。

# yum update

パッケージのアップグレードが完了するまで待ちます。

作成された設定ファイルを確認します。アップグレードしたパッケージは、Red Hat OpenStack Platform 10 バージョンのサービスに適した .rpmnew ファイルがインストールされます。OpenStack サービスの新規バージョンでは、特定の設定オプションが非推奨になる場合があります。また、OpenStack ログで非推奨の警告を確認するようにしてください。これは、今後のアップグレード時に問題を引き起こす可能性があるためです。各サービスに関する新しい、更新、非推奨となった設定オプションの詳細は、「 Red Hat OpenStack Platform ドキュメントスイート」の「設定リファレンス」を参照してください

環境内の各ノードでパッケージのアップグレードを実行します。

4.3. 全データベースの同期の実行

次の手順では、サービスごとにデータベースをアップグレードします。

注記

Identity サービスで期限切れのトークンをフラッシュして、データベースの同期に必要な時間を短縮します。

# keystone-manage token_flush

データベースを使用する各サービスのデータベーススキーマをアップグレードします。サービスのデータベースをホストするノードで以下のコマンドを実行します。

表4.1 OpenStack サービスデータベースを同期するコマンド

サービスプロジェクト名コマンド

アイデンティティー

keystone

# su -s /bin/sh -c "keystone-manage db_sync" keystone

Image サービス

glance

# su -s /bin/sh -c "glance-manage db_sync" glance

Block Storage

cinder

# su -s /bin/sh -c "cinder-manage db sync" cinder

オーケストレーション

heat

# su -s /bin/sh -c "heat-manage db_sync" heat

コンピュート

nova

# su -s /bin/sh -c "nova-manage api_db sync" nova

# su -s /bin/sh -c "nova-manage db sync" nova

Telemetry

ceilometer

# ceilometer-dbsync

Telemetry Alarming

aodh

# aodh-dbsync

Telemetry メトリクス

gnocchi

# gnocchi-upgrade

クラスターリング

sahara

# su -s /bin/sh -c "sahara-db-manage upgrade heads" sahara

ネットワーク

neutron

# su -s /bin/sh -c "neutron-db-manage upgrade heads" neutron

4.4. すべての OpenStack サービスの有効化

最後のステップにより、ノード上の OpenStack サービスが有効になります。この手順は、OpenStack が管理に高可用性ツールを使用するかどうかによって異なります。たとえば、コントローラーノードで Pacemaker を使用します。このステップには、両方のノード種別の手順が含まれます。

標準のノード

すべての OpenStack サービスを再起動します。

# systemctl isolate openstack-services.snapshot

高可用性ノード

Pacemaker を使用してリソースを再起動します。Pacemaker クラスターの単一メンバーに stop-all-resources プロパティーをリセットします。例を以下に示します。

# pcs property set stop-all-resources=false

すべてのリソースが起動するまで待ちます。pcs status コマンドを実行して、各リソースのステータスを確認します。

# pcs status

データベースやロードバランサーなど、管理外のリソースの Pacemaker 管理を有効にします。

# pcs resource manage haproxy
# pcs resource manage galera
# pcs resource manage mongod
注記

このアップグレードシナリオには、7章直接以外の環境用の追加の手順 に記載の追加のアップグレード手順があります。これらの追加の手順は、手動環境向けにオプションですが、現在の OpenStack Platform の推奨事項に合わせるのに役立ちます。

4.5. アップグレード後の注意事項

OpenStack サービスの新規バージョンでは、特定の設定オプションが非推奨になる場合があります。また、OpenStack ログで非推奨の警告を確認するようにしてください。これは、今後のアップグレード時に問題を引き起こす可能性があるためです。各サービスに関する新しい、更新、非推奨となった設定オプションの詳細は、「 Red Hat OpenStack Platform ドキュメントスイート」の「設定リファレンス」を参照してください

第5章 直接以外の環境: 標準環境での個別の OpenStack サービス(Live Compute)のアップグレード

本項では、高可用性(HA)以外の環境でライブコンピュートで一度に 1 つのサービスを更新して、クラウドデプロイメントをアップグレードする手順を説明します。このシナリオでは、director を使用しない環境で Red Hat OpenStack Platform 9 から Red Hat OpenStack Platform 10 にアップグレードし ます。

Compute をアップグレードすると、Compute サービスに中断が最小限に抑えられますが、サービスが短時間でしか実行されず、ワークロードが新たにアップグレードされた Compute ホストに移行する間隔が長くなります。既存のワークロードは無期限に実行でき、データベースの移行を待つ必要はありません。

重要

特定のパッケージの依存関係により、1 つの OpenStack サービスのパッケージをアップグレードすると、Python ライブラリーが他の OpenStack サービスがアップグレードされる前にアップグレードされる可能性があります。これにより、特定のサービスが早期に失敗する可能性があります。このような場合には、残りのサービスのアップグレードを継続します。このシナリオが完了したら、すべてのサービスが機能する必要があります。

注記

この方法では、コンピュートノードを起動するために追加のハードウェアリソースが必要になる場合があります。

注記

本章の手順では、アーキテクチャーの命名規則に続いて、すべての Red Hat OpenStack Platform ドキュメントに従います。規則に慣れていない場合は、先に進む前に、Red Hat OpenStack Platform ドキュメント スイート の『アーキテクチャーガイド』を参照してください。

5.1. アップグレード前のタスク

各ノードで subscription-manager コマンドを使用して、Red Hat OpenStack Platform 10 リポジトリーに切り替えます。

# subscription-manager repos --disable=rhel-7-server-openstack-9-rpms
# subscription-manager repos --enable=rhel-7-server-openstack-10-rpms

更新前に、OpenStack Platform サービスの systemd スナップショットを作成します。

# systemctl snapshot openstack-services

メインの OpenStack Platform サービスを無効にします。

sudo systemctl stop 'openstack-*'
sudo systemctl stop 'neutron-*'
sudo systemctl stop 'openvswitch'

openstack-selinux パッケージをアップグレードします。

# yum upgrade openstack-selinux

これは、アップグレードしたサービスが SELinux が有効になっているシステムで正しく実行されるようにするために必要です。

5.2. WSGI サービスのアップグレード

Identity サービスと Dashboard WSGI アプレットを無効にします。

# systemctl stop httpd

両方のサービスのパッケージを更新します。

# yum -d1 -y upgrade \*keystone\*
# yum -y upgrade \*horizon\* \*openstack-dashboard\*
# yum -d1 -y upgrade \*horizon\* \*python-django\*

Identity サービスのトークンテーブルに、有効期限が切れているエントリーが多数ある可能性があります。これにより、データベーススキーマのアップグレードが完了するまでにかかる時間が大幅に増大します。データベースから期限切れのトークンをフラッシュし、問題を軽減するには、Identity データベースのアップグレードを実行する前に keystone-manage コマンドを使用できます。

# keystone-manage token_flush
# su -s /bin/sh -c "keystone-manage db_sync" keystone

これにより、データベースから期限切れのトークンをフラッシュします。cron を使用して、このコマンドを定期的に実行するように配置できます。

httpd サービスを再起動します。

# systemctl start httpd

5.3. Object Storage(swift)のアップグレード

Object Storage ホストで、以下を実行します。

# systemctl stop '*swift*'
# yum -d1 -y upgrade \*swift\*
# systemctl start openstack-swift-account-auditor \
    openstack-swift-account-reaper \
    openstack-swift-account-replicator \
    openstack-swift-account \
    openstack-swift-container-auditor \
    openstack-swift-container-replicator \
    openstack-swift-container-updater \
    openstack-swift-container \
    openstack-swift-object-auditor \
    openstack-swift-object-replicator \
    openstack-swift-object-updater \
    openstack-swift-object \
    openstack-swift-proxy

5.4. Image サービス(glance)のアップグレード

Image サービスホストで以下を実行します。

# systemctl stop '*glance*'
# yum -d1 -y upgrade \*glance\*
# su -s /bin/sh -c "glance-manage db_sync" glance
# systemctl start openstack-glance-api \
    openstack-glance-registry

5.5. Block Storage(cinder)のアップグレード

Block Storage ホストで、以下を実行します。

# systemctl stop '*cinder*'
# yum -d1 -y upgrade \*cinder\*
# su -s /bin/sh -c "cinder-manage db sync" cinder
# systemctl start openstack-cinder-api \
    openstack-cinder-scheduler \
    openstack-cinder-volume

5.6. Orchestration のアップグレード(heat)

Orchestration ホストで以下を実行します。

# systemctl stop '*heat*'
# yum -d1 -y upgrade \*heat\*
# su -s /bin/sh -c "heat-manage db_sync" heat
# systemctl start openstack-heat-api-cfn \
    openstack-heat-api-cloudwatch \
    openstack-heat-api \
    openstack-heat-engine

5.7. Telemetry(ceilometer)のアップグレード

注記

このコンポーネントには、7章直接以外の環境用の追加の手順 に記載の追加のアップグレード手順があります。これらの追加の手順は、手動環境向けにオプションですが、現在の OpenStack Platform の推奨事項に合わせるのに役立ちます。

  1. Telemetry コンポーネントサービスをホストするすべてのノードで、以下を実行します。

    # systemctl stop '*ceilometer*'
    # systemctl stop '*aodh*'
    # systemctl stop '*gnocchi*'
    # yum -d1 -y upgrade \*ceilometer\* \*aodh\* \*gnocchi\*
  2. データベースがインストールされているコントローラーノードで、以下のコマンドを実行します。

    # ceilometer-dbsync
    # aodh-dbsync
    # gnocchi-upgrade
  3. パッケージのアップグレードが完了したら、Telemetry コンポーネントサービスをホストするすべてのノードで以下のコマンドを実行して Telemetry サービスを再起動します。

    # systemctl start openstack-ceilometer-api \
        openstack-ceilometer-central \
        openstack-ceilometer-collector \
        openstack-ceilometer-notification \
        openstack-aodh-evaluator \
        openstack-aodh-listener \
        openstack-aodh-notifier \
        openstack-gnocchi-metricd \
        openstack-gnocchi-statsd

5.8. Compute(nova)のアップグレード

  1. コンピュートホストのローリングアップグレードを実行する場合は、お使いの環境との互換性を確保するために、明示的な API バージョンの制限を設定する必要があります。

    コントローラーまたはコンピュートノードで Compute サービスを起動する前に、nova.conf[upgrade_levels] セクションで、以前の Red Hat OpenStack Platform バージョン(mitaka)に compute オプションを設定します。

    # crudini --set /etc/nova/nova.conf upgrade_levels compute mitaka

    コントローラーおよびコンピュートノードでこの変更を行う必要があります。

    すべてのコンピュートノードをアップグレードしてから、この操作を元に戻す必要があります。

  2. コンピュートホストで、以下のコマンドを実行します。

    # systemctl stop '*nova*'
    # yum -d1 -y upgrade \*nova\*
    # su -s /bin/sh -c "nova-manage api_db sync" nova
    # su -s /bin/sh -c "nova-manage db sync" nova
  3. ホストをすべてアップグレードしたら、前のステップで設定した API 制限を削除します。すべてのホストで以下を実行します。

    # crudini --del /etc/nova/nova.conf upgrade_levels compute
  4. すべてのコントローラーノードおよびコンピュートノードで Compute サービスを再起動します。

    # systemctl start openstack-nova-api \
        openstack-nova-conductor \
        openstack-nova-consoleauth \
        openstack-nova-novncproxy \
        openstack-nova-scheduler

5.9. Clustering(sahara)のアップグレード

  1. クラスタリングコンポーネントサービスをホストしているすべてのノードで、以下を実行します。

    # systemctl stop '*sahara*'
    # yum -d1 -y upgrade \*sahara\*
  2. データベースがインストールされているコントローラーノードで、以下のコマンドを実行します。

    # su -s /bin/sh -c "sahara-db-manage upgrade heads" sahara
  3. パッケージのアップグレードが完了したら、クラスタリングコンポーネントサービスをホストするすべてのノードで以下のコマンドを実行し、クラスタリングサービスを再起動します。

    # systemctl start openstack-sahara-api \
        openstack-sahara-engine

5.10. OpenStack Networking(neutron)のアップグレード

  1. OpenStack Networking ホストで以下を実行します。

    # systemctl stop '*neutron*'
    # yum -d1 -y upgrade \*neutron\*
  2. 同じホストで、OpenStack Networking データベーススキーマを更新します。

    # su -s /bin/sh -c "neutron-db-manage upgrade heads" neutron
  3. OpenStack Networking サービスを再起動します。

    # systemctl start neutron-dhcp-agent \
        neutron-l3-agent \
        neutron-metadata-agent \
        neutron-openvswitch-agent \
        neutron-server
注記

お使いの環境で有効にした追加の OpenStack Networking サービスを起動します。

5.11. アップグレード後のタスク

個別のサービスのアップグレードをすべて完了したら、全システムで完全なパッケージアップグレードを行う必要があります。

# yum upgrade

これにより、すべてのパッケージが最新の状態になります。実行中のプロセスが、更新されたバージョンのバイナリーを使用していることを確認するために、将来の日付に OpenStack ホストの再起動をスケジュールする必要がある場合があります。

作成された設定ファイルを確認します。アップグレードしたパッケージは、Red Hat OpenStack Platform 10 バージョンのサービスに適した .rpmnew ファイルがインストールされます。

OpenStack サービスの新規バージョンでは、特定の設定オプションが非推奨になる場合があります。また、OpenStack ログで非推奨の警告を確認するようにしてください。これは、今後のアップグレード時に問題を引き起こす可能性があるためです。各サービスに関する新しい、更新、非推奨となった設定オプションの詳細は、「 Red Hat OpenStack Platform ドキュメントスイート」の「設定リファレンス」を参照してください

第6章 直接以外の環境: 高可用性環境での個別の OpenStack サービス(Live Compute)のアップグレード

本章では、高可用性(HA)環境でライブコンピュートで一度に 1 つのサービスを更新して、クラウドデプロイメントをアップグレードする手順を説明します。このシナリオでは、director を使用しない環境で Red Hat OpenStack Platform 9 から Red Hat OpenStack Platform 10 にアップグレードし ます。

Compute をアップグレードすると、Compute サービスに中断が最小限に抑えられますが、サービスが短時間でしか実行されず、ワークロードが新たにアップグレードされた Compute ホストに移行する間隔が長くなります。既存のワークロードは無期限に実行でき、データベースの移行を待つ必要はありません。

重要

特定のパッケージの依存関係により、1 つの OpenStack サービスのパッケージをアップグレードすると、Python ライブラリーが他の OpenStack サービスがアップグレードされる前にアップグレードされる可能性があります。これにより、特定のサービスが早期に失敗する可能性があります。このような場合には、残りのサービスのアップグレードを継続します。このシナリオが完了したら、すべてのサービスが機能する必要があります。

注記

この方法では、コンピュートノードを起動するために追加のハードウェアリソースが必要になる場合があります。

注記

本章の手順では、アーキテクチャーの命名規則に続いて、すべての Red Hat OpenStack Platform ドキュメントに従います。規則に慣れていない場合は、先に進む前に、Red Hat OpenStack Platform ドキュメント スイート の『アーキテクチャーガイド』を参照してください。

6.1. アップグレード前のタスク

各ノードで subscription-manager コマンドを使用して、Red Hat OpenStack Platform 10 リポジトリーに切り替えます。

# subscription-manager repos --disable=rhel-7-server-openstack-9-rpms
# subscription-manager repos --enable=rhel-7-server-openstack-10-rpms

openstack-selinux パッケージをアップグレードします。

# yum upgrade openstack-selinux

これは、アップグレードしたサービスが SELinux が有効になっているシステムで正しく実行されるようにするために必要です。

6.2. MariaDB のアップグレード

MariaDB を実行している各ホストで以下の手順を実行します。別のホストでプロセスを開始する前に、1 つのホストで手順を実行します。

  1. ローカルノードでサービスの実行を停止します。

    # pcs resource ban galera-master $(crm_node -n)
  2. pcs status が、ローカルノードでサービスが実行されなくなったことを示しているまで待ちます。これには数分の時間がかかる場合があります。ローカルノードがスレーブモードに移行されます。

    Master/Slave Set: galera-master [galera]
    Masters: [ overcloud-controller-1 overcloud-controller-2 ]
    Slaves: [ overcloud-controller-0 ]

    ノードは最終的に停止状態に切り替わります。

    Master/Slave Set: galera-master [galera]
    Masters: [ overcloud-controller-1 overcloud-controller-2 ]
    Stopped: [ overcloud-controller-0 ]
  3. 関連するパッケージをアップグレードします。

    # yum upgrade '*mariadb*' '*galera*'
  4. Pacemaker がローカルノードで galera リソースをスケジュールできるようにします。

    # pcs resource clear galera-master
  5. pcs status が、galera リソースがローカルノードでマスターとして実行されていることを示します。pcs status コマンドは、以下のような出力を提供します。

    Master/Slave Set: galera-master [galera]
    Masters: [ overcloud-controller-0 overcloud-controller-1 overcloud-controller-2 ]

MariaDB クラスターが完全なアップグレードを完了するまで、各ノードでこの手順を個別に実行します。

6.3. MongoDB のアップグレード

以下の手順では、OpenStack Telemetry サービスのバックエンドデータベースとして機能する MongoDB をアップグレードします。

  1. Pacemaker の制御から mongod リソースを削除します。

    # pcs resource unmanage mongod-clone
  2. すべてのコントローラーノードでサービスを停止します。各コントローラーノードで、以下のコマンドを実行します。

    # systemctl stop mongod
  3. 関連するパッケージをアップグレードします。

    # yum upgrade 'mongodb*' 'python-pymongo*'
  4. systemd を、更新されたユニットファイルに対応するよう再読み込みします。

    # systemctl daemon-reload
  5. 各コントローラーで以下のコマンドを実行して、コントローラーで mongod サービスを再起動します。

    # systemctl start mongod
  6. リソースをクリーンアップします。

    # pcs resource cleanup mongod-clone
  7. Pacemaker の制御にリソースを返します。

    # pcs resource manage mongod-clone
  8. pcs status の出力で、上記のリソースが実行中であることを示すまで待ちます。

6.4. WSGI サービスのアップグレード

この手順では、全コントローラーノード上の WSGI サービスのパッケージを同時にアップグレードします。これには、OpenStack Identity(keystone)および OpenStack Dashboard(horizon)が含まれます。

  1. Pacemaker の制御からサービスを削除します。

    # pcs resource unmanage httpd-clone
  2. 各コントローラーノードで以下のコマンドを実行して、httpd サービスを停止します。

    # systemctl stop httpd
  3. 関連するパッケージをアップグレードします。

    # yum -d1 -y upgrade \*keystone\*
    # yum -y upgrade \*horizon\* \*openstack-dashboard\* httpd
    # yum -d1 -y upgrade \*horizon\* \*python-django\*
  4. 各コントローラーノードで更新されたユニットファイルについて、systemd を再読み込みします。

    # systemctl daemon-reload
  5. インストーラーの以前のバージョンでは、期限切れの Keystone トークンを自動的にパージするようにシステムが設定されていない可能性があります。トークンテーブルには期限切れのエントリーが多数ある可能性があります。これにより、データベーススキーマのアップグレードが完了するまでにかかる時間が大幅に増大します。

    期限切れトークンをデータベースからフラッシュして、問題を軽減する。Identity データベースのアップグレードを実行する前に、keystone-manage コマンドを実行します。

    # keystone-manage token_flush

    これにより、データベースから期限切れのトークンをフラッシュします。cron を使用して(毎日など)このコマンドを定期的に実行するように配置できます。

  6. Identity サービスデータベーススキーマを更新します。

    # su -s /bin/sh -c "keystone-manage db_sync" keystone
  7. 各コントローラーノードで以下のコマンドを実行してサービスを再起動します。

    # systemctl start httpd
  8. Pacemaker を使用して Identity サービスをクリーンアップします。

    # pcs resource cleanup httpd-clone
  9. Pacemaker の制御にリソースを返します。

    # pcs resource manage httpd-clone
  10. pcs status の出力で、上記のリソースが実行中であることを示すまで待ちます。

6.5. Image サービス(glance)のアップグレード

この手順では、全コントローラーノード上の Image サービスのパッケージを同時にアップグレードします。

  1. Pacemaker の Image サービスリソースを停止します。

    # pcs resource disable openstack-glance-registry-clone
    # pcs resource disable openstack-glance-api-clone
  2. pcs status の出力で、両方のサービスの実行が停止しているのを待ちます。
  3. 関連するパッケージをアップグレードします。

    # yum upgrade '*glance*'
  4. systemd を、更新されたユニットファイルに対応するよう再読み込みします。

    # systemctl daemon-reload
  5. Image サービスデータベーススキーマを更新します。

    # su -s /bin/sh -c "glance-manage db_sync" glance
  6. Pacemaker を使用して Image サービスをクリーンアップします。

    # pcs resource cleanup openstack-glance-api-clone
    # pcs resource cleanup openstack-glance-registry-clone
  7. Pacemaker で Image サービスリソースを再起動します。

    # pcs resource enable openstack-glance-api-clone
    # pcs resource enable openstack-glance-registry-clone
  8. pcs status の出力で、上記のリソースが実行中であることを示すまで待ちます。

6.6. Block Storage サービス(cinder)のアップグレード

以下の手順では、全コントローラーノード上の Block Storage サービス用のパッケージを同時にアップグレードします。

  1. Pacemaker 内のすべての Block Storage サービスリソースを停止します。

    # pcs resource disable openstack-cinder-api-clone
    # pcs resource disable openstack-cinder-scheduler-clone
    # pcs resource disable openstack-cinder-volume
  2. pcs status の出力で、上記のサービスの実行が停止しているのを待ちます。
  3. 関連するパッケージをアップグレードします。

    # yum upgrade '*cinder*'
  4. systemd を、更新されたユニットファイルに対応するよう再読み込みします。

    # systemctl daemon-reload
  5. Block Storage サービスのデータベーススキーマを更新します。

    # su -s /bin/sh -c "cinder-manage db sync" cinder
  6. Pacemaker を使用して Block Storage サービスをクリーンアップします。

    # pcs resource cleanup openstack-cinder-volume
    # pcs resource cleanup openstack-cinder-scheduler-clone
    # pcs resource cleanup openstack-cinder-api-clone
  7. Pacemaker 内のすべての Block Storage サービスリソースを再起動します。

    # pcs resource enable openstack-cinder-volume
    # pcs resource enable openstack-cinder-scheduler-clone
    # pcs resource enable openstack-cinder-api-clone
  8. pcs status の出力で、上記のリソースが実行中であることを示すまで待ちます。

6.7. Orchestration のアップグレード(heat)

この手順では、全コントローラーノードの Orchestration サービスのパッケージを同時にアップグレードします。

  1. Pacemaker の Orchestration リソースを停止します。

    # pcs resource disable openstack-heat-api-clone
    # pcs resource disable openstack-heat-api-cfn-clone
    # pcs resource disable openstack-heat-api-cloudwatch-clone
    # pcs resource disable openstack-heat-engine-clone
  2. pcs status の出力で、上記のサービスの実行が停止しているのを待ちます。
  3. 関連するパッケージをアップグレードします。

    # yum upgrade '*heat*'
  4. systemd を、更新されたユニットファイルに対応するよう再読み込みします。

    # systemctl daemon-reload
  5. Orchestration データベーススキーマを更新します。

    # su -s /bin/sh -c "heat-manage db_sync" heat
  6. Pacemaker を使用して Orchestration サービスをクリーンアップします。

    # pcs resource cleanup openstack-heat-clone
    # pcs resource cleanup openstack-heat-api-cloudwatch-clone
    # pcs resource cleanup openstack-heat-api-cfn-clone
    # pcs resource cleanup openstack-heat-api-clone
  7. Pacemaker で Orchestration リソースを再起動します。

    # pcs resource enable openstack-heat-clone
    # pcs resource enable openstack-heat-api-cloudwatch-clone
    # pcs resource enable openstack-heat-api-cfn-clone
    # pcs resource enable openstack-heat-api-clone
  8. pcs status の出力で、上記のリソースが実行中であることを示すまで待ちます。

6.8. Telemetry(ceilometer)のアップグレード

以下の手順では、全コントローラーノード上で Telemetry サービスのパッケージを同時にアップグレードします。

注記

このコンポーネントには、7章直接以外の環境用の追加の手順 に記載の追加のアップグレード手順があります。これらの追加の手順は、手動環境向けにオプションですが、現在の OpenStack Platform の推奨事項に合わせるのに役立ちます。

  1. Pacemaker のすべての Telemetry リソースを停止します。

    # pcs resource disable openstack-ceilometer-api-clone
    # pcs resource disable openstack-ceilometer-collector-clone
    # pcs resource disable openstack-ceilometer-notification-clone
    # pcs resource disable openstack-ceilometer-central-clone
    # pcs resource disable openstack-aodh-evaluator-clone
    # pcs resource disable openstack-aodh-listener-clone
    # pcs resource disable openstack-aodh-notifier-clone
    # pcs resource disable openstack-gnocchi-metricd-clone
    # pcs resource disable openstack-gnocchi-statsd-clone
    # pcs resource disable delay-clone
  2. pcs status の出力で、上記のサービスの実行が停止しているのを待ちます。
  3. 関連するパッケージをアップグレードします。

    # yum upgrade '*ceilometer*' '*aodh*' '*gnocchi*'
  4. systemd を、更新されたユニットファイルに対応するよう再読み込みします。

    # systemctl daemon-reload
  5. 以下のコマンドを使用して Telemetry データベーススキーマを更新します。

    # ceilometer-dbsync
    # aodh-dbsync
    # gnocchi-upgrade
  6. Pacemaker を使用して Telemetry サービスをクリーンアップします。

    # pcs resource cleanup delay-clone
    # pcs resource cleanup openstack-ceilometer-api-clone
    # pcs resource cleanup openstack-ceilometer-collector-clone
    # pcs resource cleanup openstack-ceilometer-notification-clone
    # pcs resource cleanup openstack-ceilometer-central-clone
    # pcs resource cleanup openstack-aodh-evaluator-clone
    # pcs resource cleanup openstack-aodh-listener-clone
    # pcs resource cleanup openstack-aodh-notifier-clone
    # pcs resource cleanup openstack-gnocchi-metricd-clone
    # pcs resource cleanup openstack-gnocchi-statsd-clone
  7. Pacemaker のすべての Telemetry リソースを再起動します。

    # pcs resource enable delay-clone
    # pcs resource enable openstack-ceilometer-api-clone
    # pcs resource enable openstack-ceilometer-collector-clone
    # pcs resource enable openstack-ceilometer-notification-clone
    # pcs resource enable openstack-ceilometer-central-clone
    # pcs resource enable openstack-aodh-evaluator-clone
    # pcs resource enable openstack-aodh-listener-clone
    # pcs resource enable openstack-aodh-notifier-clone
    # pcs resource enable openstack-gnocchi-metricd-clone
    # pcs resource enable openstack-gnocchi-statsd-clone
  8. pcs status の出力で、上記のリソースが実行中であることを示すまで待ちます。
重要

以前のバージョンの Telemetry サービスのバージョンでは、非推奨となった rpc_backend パラメーターの値を使用していました。/etc/ceilometer/ceilometer.conf ファイルの rpc_backend パラメーターが以下に設定されていることを確認します。

rpc_backend=rabbit

6.9. コントローラーノードでの Compute サービス(nova)のアップグレード

以下の手順では、全コントローラーノード上の Compute サービスのパッケージを同時にアップグレードします。

  1. Pacemaker のすべてのコンピュートリソースを停止します。

    # pcs resource disable openstack-nova-novncproxy-clone
    # pcs resource disable openstack-nova-consoleauth-clone
    # pcs resource disable openstack-nova-conductor-clone
    # pcs resource disable openstack-nova-api-clone
    # pcs resource disable openstack-nova-scheduler-clone
  2. pcs status の出力で、上記のサービスの実行が停止しているのを待ちます。
  3. 関連するパッケージをアップグレードします。

    # yum upgrade '*nova*'
  4. systemd を、更新されたユニットファイルに対応するよう再読み込みします。

    # systemctl daemon-reload
  5. Compute データベーススキーマを更新します。

    # su -s /bin/sh -c "nova-manage api_db sync" nova
    # su -s /bin/sh -c "nova-manage db sync" nova
  6. コンピュートホストのローリングアップグレードを実行する場合は、Mitaka 環境と Newton 環境間の互換性を確保するために、明示的な API バージョンの制限を設定する必要があります。

    コントローラーまたはコンピュートノードで Compute サービスを起動する前に、nova.conf[upgrade_levels] セクションで、以前の Red Hat OpenStack Platform バージョン(mitaka)に compute オプションを設定します。

    # crudini --set /etc/nova/nova.conf upgrade_levels compute mitaka

    これにより、コントローラーノードは引き続き以前のバージョンのコンピュートノードと通信することができます。

    まず、1 つのコントローラーノードで pcs resource unmanage を実行して、コンピュートリソースの管理を解除する必要があります。

    # pcs resource unmanage openstack-nova-novncproxy-clone
    # pcs resource unmanage openstack-nova-consoleauth-clone
    # pcs resource unmanage openstack-nova-conductor-clone
    # pcs resource unmanage openstack-nova-api-clone
    # pcs resource unmanage openstack-nova-scheduler-clone

    すべてのコントローラーで全サービスを再起動します。

    # openstack-service restart nova

    すべてのコンピュートホストを Red Hat OpenStack Platform 10 にアップグレードした後に、コントロールを Pacemaker に戻す必要があります。

    # pcs resource manage openstack-nova-scheduler-clone
    # pcs resource manage openstack-nova-api-clone
    # pcs resource manage openstack-nova-conductor-clone
    # pcs resource manage openstack-nova-consoleauth-clone
    # pcs resource manage openstack-nova-novncproxy-clone
  7. Pacemaker の全コンピュートリソースをクリーンアップします。

    # pcs resource cleanup openstack-nova-scheduler-clone
    # pcs resource cleanup openstack-nova-api-clone
    # pcs resource cleanup openstack-nova-conductor-clone
    # pcs resource cleanup openstack-nova-consoleauth-clone
    # pcs resource cleanup openstack-nova-novncproxy-clone
  8. Pacemaker の全コンピュートリソースを再起動します。

    # pcs resource enable openstack-nova-scheduler-clone
    # pcs resource enable openstack-nova-api-clone
    # pcs resource enable openstack-nova-conductor-clone
    # pcs resource enable openstack-nova-consoleauth-clone
    # pcs resource enable openstack-nova-novncproxy-clone
  9. pcs status の出力で、上記のリソースが実行中であることを示すまで待ちます。

6.10. Clustering サービス(sahara)のアップグレード

この手順では、すべてのコントローラーノードで、クラスタリングサービスのパッケージを同時にアップグレードします。

  1. Pacemaker のすべてのクラスタリングサービスリソースを停止します。

    # pcs resource disable openstack-sahara-api-clone
    # pcs resource disable openstack-sahara-engine-clone
  2. pcs status の出力で、上記のサービスの実行が停止しているのを待ちます。
  3. 関連するパッケージをアップグレードします。

    # yum upgrade '*sahara*'
  4. systemd を、更新されたユニットファイルに対応するよう再読み込みします。

    # systemctl daemon-reload
  5. Clustering サービスデータベーススキーマを更新します。

    # su -s /bin/sh -c "sahara-db-manage upgrade heads" sahara
  6. Pacemaker を使用してクラスタリングサービスをクリーンアップします。

    # pcs resource cleanup openstack-sahara-api-clone
    # pcs resource cleanup openstack-sahara-engine-clone
  7. Pacemaker 内のすべての Block Storage サービスリソースを再起動します。

    # pcs resource enable openstack-sahara-api-clone
    # pcs resource enable openstack-sahara-engine-clone
  8. pcs status の出力で、上記のリソースが実行中であることを示すまで待ちます。

6.11. OpenStack Networking(neutron)のアップグレード

この手順では、全コントローラーノード上の Networking サービスのパッケージを同時にアップグレードします。

  1. Pacemaker が OpenStack Networking のクリーンアップスクリプトをトリガーしないようにします。

    # pcs resource unmanage neutron-ovs-cleanup-clone
    # pcs resource unmanage neutron-netns-cleanup-clone
  2. Pacemaker の OpenStack Networking リソースを停止します。

    # pcs resource disable neutron-server-clone
    # pcs resource disable neutron-openvswitch-agent-clone
    # pcs resource disable neutron-dhcp-agent-clone
    # pcs resource disable neutron-l3-agent-clone
    # pcs resource disable neutron-metadata-agent-clone
  3. 関連するパッケージをアップグレードします。

    # yum upgrade 'openstack-neutron*' 'python-neutron*'
  4. OpenStack Networking データベーススキーマを更新します。

    # su -s /bin/sh -c "neutron-db-manage upgrade heads" neutron
  5. Pacemaker で OpenStack Networking リソースをクリーンアップします。

    # pcs resource cleanup neutron-metadata-agent-clone
    # pcs resource cleanup neutron-l3-agent-clone
    # pcs resource cleanup neutron-dhcp-agent-clone
    # pcs resource cleanup neutron-openvswitch-agent-clone
    # pcs resource cleanup neutron-server-clone
  6. Pacemaker で OpenStack Networking リソースを再起動します。

    # pcs resource enable neutron-metadata-agent-clone
    # pcs resource enable neutron-l3-agent-clone
    # pcs resource enable neutron-dhcp-agent-clone
    # pcs resource enable neutron-openvswitch-agent-clone
    # pcs resource enable neutron-server-clone
  7. クリーンアップエージェントを Pacemaker コントロールに戻します。

    # pcs resource manage neutron-ovs-cleanup-clone
    # pcs resource manage neutron-netns-cleanup-clone
  8. pcs status の出力で、上記のリソースが実行中であることを示すまで待ちます。

6.12. コンピュート(nova)ノードのアップグレード

以下の手順では、単一のコンピュートノード上のパッケージをアップグレードします。各コンピュートノードで、個別にこの手順を実施します。

コンピュートホストのローリングアップグレードを実行する場合は、Mitaka 環境と Newton 環境間の互換性を確保するために、明示的な API バージョンの制限を設定する必要があります。

コントローラーまたはコンピュートノードで Compute サービスを起動する前に、nova.conf[upgrade_levels] セクションで、以前の Red Hat OpenStack Platform バージョン(mitaka)に compute オプションを設定します。

# crudini --set /etc/nova/nova.conf upgrade_levels compute mitaka

更新前に、OpenStack Platform サービスの systemd スナップショットを作成します。

# systemctl snapshot openstack-services

これにより、コントローラーノードは引き続き以前のバージョンのコンピュートノードと通信することができます。

  1. ホストにあるすべての OpenStack サービスを停止します。

    # systemctl stop 'openstack*' '*nova*'
  2. すべてのパッケージをアップグレードします。

    # yum upgrade
  3. ホスト上の全 OpenStack サービスを起動します。

    # openstack-service start
  4. ホストをすべてアップグレードしたら、前のステップで設定した API 制限を削除します。すべてのホストで以下を実行します。

    # crudini --del /etc/nova/nova.conf upgrade_levels compute
  5. ホスト上の全 OpenStack サービスを再起動します。

    # systemctl isolate openstack-services.snapshot

6.13. アップグレード後のタスク

個別のサービスのアップグレードをすべて完了したら、すべてのノードで完全なパッケージアップグレードを実行する必要があります。

# yum upgrade

これにより、すべてのパッケージが最新の状態になります。実行中のプロセスが、更新されたバージョンのバイナリーを使用していることを確認するために、将来の日付に OpenStack ホストの再起動をスケジュールする必要がある場合があります。

作成された設定ファイルを確認します。アップグレードしたパッケージは、Red Hat OpenStack Platform 10 バージョンのサービスに適した .rpmnew ファイルがインストールされます。

OpenStack サービスの新規バージョンでは、特定の設定オプションが非推奨になる場合があります。また、OpenStack ログで非推奨の警告を確認するようにしてください。これは、今後のアップグレード時に問題を引き起こす可能性があるためです。各サービスに関する新しい、更新、非推奨となった設定オプションの詳細は、「 Red Hat OpenStack Platform ドキュメントスイート」の「設定リファレンス」を参照してください

第7章 直接以外の環境用の追加の手順

以下の項では、director で管理されない Red Hat OpenStack Platform 環境の追加の手順について記載します。以下の手順は、OpenStack Platform エコシステム内の変更に対応し、Red Hat OpenStack Platform 10 へのアップグレード後に最も適しています。

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

この手順では、OpenStack Telemetry(ceilometer)API をアップグレードして、スタンドアロンサービスではなく httpd の下にある Web Server Gateway Interface(WSGI)アプレットとして実行されます。このプロセスは、スタンドアロンの openstack-ceilometer-api サービスを無効にし、WSGI アプレットを有効にするために必要な設定をインストールします。

  1. OpenStack Telemetry サービスを無効にします。この手順は、高可用性のコントローラーノードを使用するかどうかによって異なります。

    • 高可用性のない環境の場合:

      $ sudo systemctl stop openstack-ceilometer-api
    • 高可用性がある環境の場合:

      $ sudo pcs resource disable openstack-ceilometer-api
  2. 各コントローラーで、OpenStack Telemetry サービス WSGI アプレット(/lib/python2.7/site-packages/ceilometer/api/app.wsgi)を /var/www/cgi-bin/ の新しいディレクトリーにコピーします。例を以下に示します。

    $ sudo mkdir /var/www/cgi-bin/ceilometer
    $ cp /lib/python2.7/site-packages/ceilometer/api/app.wsgi /var/www/cgi-bin/ceilometer/app
  3. 各コントローラーで、OpenStack Telemetry サービス用に仮想ホスト設定ファイル(10-ceilometer_wsgi.conf)を作成します。このファイルを /etc/httpd/conf.d/ に保存します。仮想ホストファイルの内容は以下のようになります。

    Listen 8777
    
    <VirtualHost *:8777>
      DocumentRoot "/var/www/cgi-bin/ceilometer"
    
      <Directory "/var/www/cgi-bin/ceilometer">
        Options Indexes FollowSymLinks MultiViews
        AllowOverride None
        Require all granted
      </Directory>
    
      ErrorLog "/var/log/httpd/ceilometer_wsgi_error.log"
      ServerSignature Off
      CustomLog "/var/log/httpd/ceilometer_wsgi_access.log" combined
    
      SetEnvIf X-Forwarded-Proto https HTTPS=1
      WSGIApplicationGroup %{GLOBAL}
      WSGIDaemonProcess ceilometer group=ceilometer processes=1 threads=4 user=ceilometer
      WSGIProcessGroup ceilometer
      WSGIScriptAlias / "/var/www/cgi-bin/ceilometer/app"
    </VirtualHost>
  4. httpd サービスを再起動します。この手順は、高可用性のコントローラーノードを使用するかどうかによって異なります。

    • 高可用性のない環境の場合:

      $ sudo systemctl restart httpd
    • 高可用性がある環境の場合:

      $ sudo pcs resource restart httpd

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

アップグレードの一環として、aodh-dbsync ツールが新しい MariaDB データベースを作成します。ただし、以前のデータベースでは MongoDB を使用していました。以下の手順では、以前の OpenStack Telemetry Alarming(aodh)サービスのデータベースを MongoDB から MariaDB に移行します。環境のアップグレード後にこの手順を実行します。

/etc/aodh/aodh.conf 設定ファイルを編集して、データベース接続を MariaDB データベースに変更します。例を以下に示します。

[database]
connection = mysql+pymysql://username:password@host/aodh?charset=utf8

以下のコマンドを実行して移行を実行します。

$ sudo /usr/bin/aodh-data-migration \
  --nosql-conn `crudini --get /etc/ceilometer/ceilometer.conf database connection` \
  --sql-conn `crudini --get /etc/aodh/aodh.conf database connection`

このコマンドは、( --sql-connを介して)MongoDB から MariaDB にデータを移行します。

第8章 director ベースのアップグレードのトラブルシューティング

本セクションでは、両方の問題のトラブルシューティングに関するアドバイスを提供します。

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

アンダークラウドのアップグレードコマンド(openstack undercloud upgrade)が失敗する場合は、以下のアドバイスを使用して、アップグレードの進捗をブロックする問題を特定します。

  • openstack undercloud upgrade コマンドは、実行中に進捗ログを出力します。アップグレードプロセスのある時点でエラーが発生した場合、コマンドはエラーのある時点で停止します。この情報を使用して、アップグレードの進捗に起因する問題を特定します。
  • openstack undercloud upgrade コマンドは、Puppet を実行してアンダークラウドサービスを設定します。これにより、以下のディレクトリーに有用な Puppet レポートが生成されます。

    • /var/lib/puppet/state/last_run_report.yaml: アンダークラウド用に生成される最後の Puppet レポート。このファイルには、失敗した Puppet アクションの原因が表示されます。
    • /var/lib/puppet/state/last_run_summary.yaml: last_run_report.yaml ファイルの概要
    • /var/lib/puppet/reports: アンダークラウドのすべての Puppet レポート。

      この情報を使用して、アップグレードの進捗に起因する問題を特定します。

  • 失敗したサービスの有無を確認します。

    $ sudo systemctl -t service

    エラーが発生したサービスがある場合には、対応するログを確認します。たとえば、openstack-ironic-api に障害が発生した場合には、以下のコマンドを使用してそのサービスのログを確認します。

    $ sudo journalctl -xe -u openstack-ironic-api
    $ sudo tail -n 50 /var/log/ironic/ironic-api.log

アンダークラウドのアップグレードが行われている問題を修正したら、アップグレードコマンドを再実行します。

$ openstack undercloud upgrade

アップグレードコマンドが再び開始し、アンダークラウドを設定します。

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

オーバークラウドのアップグレードプロセスに失敗した場合は、以下のアドバイスを使用して、アップグレードの進捗をブロックする問題を特定します。

  • Heat スタックの一覧を確認し、UPDATE_FAILED のステータスを持つスタックを特定します。以下のコマンドは、これらのスタックを特定します。

    $ heat stack-list --show-nested | awk -F "|" '{ print $3,$4 }' | grep "UPDATE_FAILED" | column -t

    失敗したスタックとそのテンプレートを表示して、スタックがどのように失敗したかを特定します。

    $ heat stack-show overcloud-Controller-qyoy54dyhrll-1-gtwy5bgta3np
    $ heat template-show overcloud-Controller-qyoy54dyhrll-1-gtwy5bgta3np
  • Pacemaker がすべてのコントローラーノードで正しく実行されていることを確認します。必要に応じてコントローラーノードにログインして、コントローラークラスターを再起動します。

    $ sudo pcs cluster start

オーバークラウドのアップグレードを妨げていた問題を修正したら、試みたアップグレードステップの openstack overcloud deploy コマンドを再度実行します。以下は、アップグレードプロセスの最初の openstack overcloud deploy コマンドの例です。これには major-upgrade-pacemaker-init.yaml が含まれます。

$ openstack overcloud deploy --templates \
  -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \
  -e /usr/share/openstack-tripleo-heat-templates/environments/net-single-nic-with-vlans.yaml  \
  -e network_env.yaml \
  -e /usr/share/openstack-tripleo-heat-templates/environments/major-upgrade-pacemaker-init.yaml

openstack overcloud deploy は、オーバークラウドスタックの更新を再試行します。

付録A NFV の更新用の YAML ファイルのサンプル

これらの YAML ファイルのサンプルは、OVS-DPDK デプロイメント向けの OVS をアップグレードします。

A.1. Red Hat OpenStack Platform 10 OVS 2.9 の更新ファイル

A.1.1. post-install.yaml

heat_template_version: 2014-10-16

description: >
  Example extra config for post-deployment

parameters:
  servers:
    type: json
  ComputeHostnameFormat:
    type: string
    default: ""

resources:
  ExtraDeployments:
    type: OS::Heat::StructuredDeployments
    properties:
      servers:  {get_param: servers}
      config: {get_resource: ExtraConfig}
      # Do this on CREATE/UPDATE (which is actually the default)
      actions: ['CREATE', 'UPDATE']

  ExtraConfig:
    type: OS::Heat::SoftwareConfig
    properties:
      group: script
      config: |
            #!/bin/bash
            set -x
            function tuned_service_dependency() {
              tuned_src_service="/usr/lib/systemd/system/tuned.service"
              tuned_service="${tuned_src_service/usr\/lib/etc}"
              grep -q "network.target" $tuned_src_service
              if [ "$?" -eq 0 ]; then
                sed '/After=.*/s/network.target//g' $tuned_src_service > $tuned_service
              fi
              grep -q "Before=.*network.target" $tuned_service
              if [ ! "$?" -eq 0 ]; then
                grep -q "Before=.*" $tuned_service
                if [ "$?" -eq 0 ]; then
                  sed -i 's/^\(Before=.*\)/\1 network.target openvswitch.service/g' $tuned_service
                else
                  sed -i '/After/i Before=network.target openvswitch.service' $tuned_service
                fi
              fi
            }

            if hiera -c /etc/puppet/hiera.yaml service_names | grep -q -e neutron_ovs_dpdk_agent -e neutron_sriov_agent -e neutron_sriov_host_config; then
                 tuned_service_dependency
            fi