第5章 オーバークラウドのアップグレードの準備

本項では、アップグレードのプロセスに備えてオーバークラウドを準備します。本項のすべてのステップが、お使いのオーバークラウドに適用されるわけではありません。ただし、各ステップをチェックして、アップグレードのプロセスが開始する前にオーバークラウドで追加の設定が必要かどうかを確認しておくことを推奨します。

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

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

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

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

  • OpenStack Platform サービス

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

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

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

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

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

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

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

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

6章オーバークラウドのアップグレード」の手順では、全コンピュートノードでアップグレードを実行する前の、アップグレードプロセスのテスト用のコンピュートノードの例として、compute-0 を使用しています。

次のステップでは、roles_data ファイルを更新して、新しいコンポーザブルサービスがお使いの環境内の適切なロールに追加されるようにします。既存の roles_data ファイルを手動で編集するには、以下に記載する OpenStack Platform 13 のロール向けの新規コンポーザブルサービスの一覧を使用してください。

注記

Red Hat OpenStack Platform 12 以前のバージョンでコンピュートインスタンス向けの高可用性 (インスタンス HA) を有効化していて、バージョン 13 以降のバージョンへの Fast Forward Upgrade を実行する場合には、最初にインスタンス HA を手動で無効にする必要があります。手順については、「以前のバージョンからのインスタンス HA の無効化」を参照してください。

5.3. 新規コンポーザブルサービス

Red Hat OpenStack Platform の今回のバージョンには、新たなコンポーザブルサービスが含まれています。独自のロールにカスタムの roles_data ファイルを使用する場合には、これらの新しい必須サービスを該当するロールに追加してください。

全ロール

以下の新規サービスは全ロールに適用されます。

OS::TripleO::Services::MySQLClient
他のコンポーザブルサービス用のデータベース設定を提供する MariaDB クライアントをノード上で設定します。このサービスは、スタンドアロンのコンポーザブルサービスを使用する全ロールに追加してください。
OS::TripleO::Services::CertmongerUser
オーバークラウドが Certmonger から証明書を要求できるようにします。TLS/SSL 通信を有効にしている場合にのみ使用されます。
OS::TripleO::Services::Docker
コンテナー化されたサービスを管理するために docker をインストールします。
OS::TripleO::Services::ContainersLogrotateCrond
コンテナーログ用の logrotate サービスをインストールします。
OS::TripleO::Services::Securetty
ノード上で securetty を設定できるようにします。environments/securetty.yaml 環境ファイルで有効化済みです。
OS::TripleO::Services::Tuned
Linux のチューニングデーモン (tuned) を有効化して設定します。
OS::TripleO::Services::AuditD
auditd デーモンを追加して、ルールを設定します。デフォルトでは無効になっています。
OS::TripleO::Services::Collectd
collectd デーモンを追加します。デフォルトでは無効になっています。
OS::TripleO::Services::Rhsm
Ansible ベースの方法を使用してサブスクリプションを設定します。デフォルトでは無効になっています。
OS::TripleO::Services::RsyslogSidecar
ロギング用のサイドカーコンテナーを設定します。デフォルトでは無効になっています。

特定のロール

以下の新規サービスは特定のロールに適用されます。

OS::TripleO::Services::NovaPlacement
OpenStack Compute (nova) Placement API を設定します。現在のオーバークラウドでスタンドアロンの Nova API ロールを使用している場合には、そのロールにこのサービスを追加します。そうでない場合には、このサービスを Controller ロールに追加してください。
OS::TripleO::Services::PankoApi
OpenStack Telemetry Event Storage (panko) サービスを設定します。現在のオーバークラウドでスタンドアロンの Telemetry ロールを使用している場合には、このサービスをそのロールに追加します。そうでない場合には、このサービスを Controller ロールに追加してください。
OS::TripleO::Services::Clustercheck
Controller またはスタンドアローンの Database ロールなどの OS::TripleO::Services::MySQL サービスも使用するロールに必要です。
OS::TripleO::Services::Iscsid
Controller ロール、Compute ロール、BlockStorage ロールで、iscsid サービスを設定します。
OS::TripleO::Services::NovaMigrationTarget
コンピュート ノード上で移行ターゲットサービスを設定します。
OS::TripleO::Services::Ec2Api
コントローラー ノードで OpenStack Compute (nova) EC2-API サービスを有効化します。デフォルトでは無効になっています。
OS::TripleO::Services::CephMgr
コントローラー ノードで Ceph Manager サービスを有効にします。ceph-ansible 設定の一部として有効化されています。
OS::TripleO::Services::CephMds
コントローラー ノードで Ceph Metadata Service (MDS) を有効化します。デフォルトでは無効になっています。
OS::TripleO::Services::CephRbdMirror
RADOS Block Device (RBD) ミラーリングサービスを有効化します。デフォルトでは無効になっています。

上記に加えて、特定のカスタムロール向けサービスの最新の一覧は、『オーバークラウドの高度なカスタマイズ』「サービスアーキテクチャー: スタンドアロンロール」の項を参照してください。

新規コンポーザブルサービスに加えて、OpenStack Platform 13 以降で非推奨になったサービスについても注意してください。

5.4. 非推奨のコンポーザブルサービス

カスタムの roles_data ファイルを使用する場合には、該当するロールから以下のサービスを削除してください。

OS::TripleO::Services::Core
このサービスは、その他の Pacemaker サービスのコア依存関係として機能していました。このサービスは、高可用性コンポーザブルサービスに対応するために削除されました。
OS::TripleO::Services::VipHosts
このサービスは、ノードのホスト名と IP アドレスで /etc/hosts ファイルを設定していました。このサービスは、director の Heat テンプレートに直接統合されるようになりました。
OS::TripleO::Services::FluentdClient
このサービスは、OS::TripleO::Services::Fluentd サービスに置き換えられました。
OS::TripleO::Services::ManilaBackendGeneric
Manila の汎用バックエンドはサポートされなくなりました。

カスタムの roles_data ファイルを使用する場合には、各ロールから以下のサービスを削除してください。

上記に加えて、特定のカスタムロール向けサービスの最新の一覧は、『オーバークラウドの高度なカスタマイズ』「サービスアーキテクチャー: スタンドアロンロール」の項を参照してください。

5.5. コンテナー化されたサービスへの切り替え

Fast Forward Upgrade プロセスにより、特定の Systemd サービスがコンテナー化されたサービスに変換されます。/usr/share/openstack-tripleo-heat-templates/environments/ からのデフォルトの環境ファイルを使用する場合には、この変換は自動的に行われます。

カスタム環境ファイルを使用してオーバークラウドのサービスを有効にする場合には、環境ファイルの resource_registry セクションで、登録したコンポーザブルサービスがすべてコンポーザブルサービスにマッピングされていることを確認します。

手順

  1. カスタム環境ファイルを表示します。

    $ cat ~/templates/custom_environment.yaml
  2. ファイルコンテンツの resource_registry セクションを確認します。
  3. resource_registry セクションのコンポーザブルサービスを確認します。以下の名前空間を使用するコンポーザブルサービス。

    OS::TripleO::Services

    たとえば、以下のコンポーザブルサービスは、OpenStack Bare Metal サービス (ironic) API に関するものです。

    OS::TripleO::Services::IronicApi
  4. コンポーザブルサービスが Puppet 固有の Heat テンプレートにマッピングされているかどうかを確認します。以下に例を示します。

    resource_registry:
      OS::TripleO::Services::IronicApi: /usr/share/openstack-triple-heat-template/puppet/services/ironic-api.yaml
  5. コンテナー化バージョンの Heat テンプレートが /usr/share/openstack-triple-heat-template/docker/services/ にあるかどうかを確認し、サービスをコンテナー化バージョンに再マッピングします。

    resource_registry:
      OS::TripleO::Services::IronicApi: /usr/share/openstack-triple-heat-template/docker/services/ironic-api.yaml

    あるいは、/usr/share/openstack-tripleo-heat-templates/environments/ にあるサービスの更新された環境ファイルを使用します。たとえば、OpenStack Bare Metal サービス (ironic) を有効にする最新の環境ファイルは /usr/share/openstack-tripleo-heat-templates/environments/services/ironic.yaml で、ここにはコンテナー化されたサービスへのマッピングが含まれています。

    カスタムサービスがコンテナー化されたサービスを使用しない場合には、マッピングを Puppet 固有の Heat テンプレートのままにします。

5.6. 非推奨パラメーター

以下のパラメーターは非推奨となり、置き換えられた点に注意してください。

旧パラメーター新規パラメーター

KeystoneNotificationDriver

NotificationDriver

controllerExtraConfig

ControllerExtraConfig

OvercloudControlFlavor

OvercloudControllerFlavor

controllerImage

ControllerImage

NovaImage

ComputeImage

NovaComputeExtraConfig

ComputeExtraConfig

NovaComputeServerMetadata

ComputeServerMetadata

NovaComputeSchedulerHints

ComputeSchedulerHints

注記

カスタムの Compute ロールを使用している場合に、ロール固有の ComputeSchedulerHints を使用するには、以下の設定を環境に追加して、非推奨の NovaComputeSchedulerHints パラメーターが設定されていても定義されていないことを確認する必要があります。

parameter_defaults:
  NovaComputeSchedulerHints: {}

カスタムロールを使用する場合は、ロール固有の _ROLE_SchedulerHints パラメーターを使用するようにこの設定を追加する必要があります。

NovaComputeIPs

ComputeIPs

SwiftStorageServerMetadata

ObjectStorageServerMetadata

SwiftStorageIPs

ObjectStorageIPs

SwiftStorageImage

ObjectStorageImage

OvercloudSwiftStorageFlavor

OvercloudObjectStorageFlavor

NeutronDpdkCoreList

OvsPmdCoreList

NeutronDpdkMemoryChannels

OvsDpdkMemoryChannels

NeutronDpdkSocketMemory

OvsDpdkSocketMemory

NeutronDpdkDriverType

OvsDpdkDriverType

HostCpusList

OvsDpdkCoreList

新規パラメーターの値には、入れ子状の一重引用符を省き二重引用符を使用します。以下に例を示します。

旧パラメーターおよび値新規パラメーターおよび値

NeutronDpdkCoreList: "'2,3'"

OvsPmdCoreList: "2,3"

HostCpusList: "'0,1'"

OvsDpdkCoreList: "0,1"

お使いのカスタム環境ファイルのこれらのパラメーターを更新してください。以下のパラメーターは非推奨となりましたが、現在それと等価なパラメーターはありません。

NeutronL3HA
L3 高可用性は、分散仮想ルーター (NeutronEnableDVR) を使用した構成を除き、すべてのケースで有効です。
CeilometerWorkers
より新しいコンポーネント (Gnocchi、Aodh、Panko) が優先され、Ceilometer は非推奨となりました。
CinderNetappEseriesHostType
E-series のサポートは、すべて非推奨となりました。
ControllerEnableSwiftStorage
代わりに、ControllerServices パラメーターの操作を使用する必要があります。
OpenDaylightPort
OpenDaylight のデフォルトポートを定義するには、EndpointMap を使用します。
OpenDaylightConnectionProtocol
このパラメーターの値は、TLS を使用してオーバークラウドをデプロイするかどうかに基づいて決定されるようになりました。

/home/stack ディレクトリーで以下の egrep コマンドを実行して、非推奨のパラメーターが含まれる環境ファイルを特定します。

$ egrep -r -w 'KeystoneNotificationDriver|controllerExtraConfig|OvercloudControlFlavor|controllerImage|NovaImage|NovaComputeExtraConfig|NovaComputeServerMetadata|NovaComputeSchedulerHints|NovaComputeIPs|SwiftStorageServerMetadata|SwiftStorageIPs|SwiftStorageImage|OvercloudSwiftStorageFlavor|NeutronDpdkCoreList|NeutronDpdkMemoryChannels|NeutronDpdkSocketMemory|NeutronDpdkDriverType|HostCpusList|NeutronDpdkCoreList|HostCpusList|NeutronL3HA|CeilometerWorkers|CinderNetappEseriesHostType|ControllerEnableSwiftStorage|OpenDaylightPort|OpenDaylightConnectionProtocol' *

OpenStack Platform 環境で非推奨となったこれらのパラメーターがまだ必要な場合には、デフォルトの roles_data ファイルで使用することができます。ただし、カスタムの roles_data ファイルを使用していて、オーバークラウドにそれらの非推奨パラメーターが引き続き必要な場合には、roles_data ファイルを編集して各ロールに以下の設定を追加することによって、パラメーターへのアクセスを可能にすることができます。

Controller ロール

- name: Controller
  uses_deprecated_params: True
  deprecated_param_extraconfig: 'controllerExtraConfig'
  deprecated_param_flavor: 'OvercloudControlFlavor'
  deprecated_param_image: 'controllerImage'
  ...

Compute ロール

- name: Compute
  uses_deprecated_params: True
  deprecated_param_image: 'NovaImage'
  deprecated_param_extraconfig: 'NovaComputeExtraConfig'
  deprecated_param_metadata: 'NovaComputeServerMetadata'
  deprecated_param_scheduler_hints: 'NovaComputeSchedulerHints'
  deprecated_param_ips: 'NovaComputeIPs'
  deprecated_server_resource_name: 'NovaCompute'
  disable_upgrade_deployment: True
  ...

Object Storage ロール

- name: ObjectStorage
  uses_deprecated_params: True
  deprecated_param_metadata: 'SwiftStorageServerMetadata'
  deprecated_param_ips: 'SwiftStorageIPs'
  deprecated_param_image: 'SwiftStorageImage'
  deprecated_param_flavor: 'OvercloudSwiftStorageFlavor'
  disable_upgrade_deployment: True
  ...

5.7. 非推奨の CLI オプション

環境ファイルの parameter_defaults セクションに追加する Heat テンプレートのパラメーターの使用が優先されるため、一部のコマンドラインオプションは古いか非推奨となっています。以下の表では、非推奨となったオプションと、それに相当する Heat テンプレートのオプションをマッピングしています。

表5.1 非推奨の CLI オプションと Heat テンプレートのパラメーターの対照表

オプション説明Heat テンプレートのパラメーター

--control-scale

スケールアウトするコントローラーノードの数

ControllerCount

--compute-scale

スケールアウトするコンピュートノードの数

ComputeCount

--ceph-storage-scale

スケールアウトする Ceph Storage ノードの数

CephStorageCount

--block-storage-scale

スケールアウトする Cinder ノード数

BlockStorageCount

--swift-storage-scale

スケールアウトする Swift ノード数

ObjectStorageCount

--control-flavor

コントローラーノードに使用するフレーバー

OvercloudControllerFlavor

--compute-flavor

コンピュートノードに使用するフレーバー

OvercloudComputeFlavor

--ceph-storage-flavor

Ceph Storage ノードに使用するフレーバー

OvercloudCephStorageFlavor

--block-storage-flavor

Cinder ノードに使用するフレーバー

OvercloudBlockStorageFlavor

--swift-storage-flavor

Swift Storage ノードに使用するフレーバー

OvercloudSwiftStorageFlavor

--neutron-flat-networks

フラットなネットワークが neutron プラグインで設定されるように定義します。外部ネットワークを作成ができるようにデフォルトは「datacentre」に設定されています。

NeutronFlatNetworks

--neutron-physical-bridge

各ハイパーバイザーで作成する Open vSwitch ブリッジ。デフォルトは「br-ex」です。通常、このパラメーターを変更する必要はありません。

HypervisorNeutronPhysicalBridge

--neutron-bridge-mappings

使用する論理ブリッジから物理ブリッジへのマッピング。ホストの外部ブリッジ (br-ex) を物理名 (datacentre) にマッピングするようにデフォルト設定されています。これは、デフォルトの Floating ネットワークに使用されます。

NeutronBridgeMappings

--neutron-public-interface

ネットワークノード向けに br-ex にブリッジするインターフェースを定義します。

NeutronPublicInterface

--neutron-network-type

Neutron のテナントネットワーク種別

NeutronNetworkType

--neutron-tunnel-types

neutron テナントネットワークのトンネリング種別。複数の値を指定するには、コンマ区切りの文字列を使用します。

NeutronTunnelTypes

--neutron-tunnel-id-ranges

テナントネットワークを割り当てに使用できる GRE トンネリングの ID 範囲

NeutronTunnelIdRanges

--neutron-vni-ranges

テナントネットワークを割り当てに使用できる VXLAN VNI の ID 範囲

NeutronVniRanges

--neutron-network-vlan-ranges

サポートされる Neutron ML2 および Open vSwitch VLAN マッピングの範囲。デフォルトでは、物理ネットワーク「datacentre」上の VLAN を許可するように設定されています。

NeutronNetworkVLANRanges

--neutron-mechanism-drivers

neutron テナントネットワークのメカニズムドライバー。デフォルトは「openvswitch」です。複数の値を指定するには、コンマ区切りの文字列を使用します。

NeutronMechanismDrivers

--neutron-disable-tunneling

VLAN で区切られたネットワークまたは neutron でのフラットネットワークを使用するためにトンネリングを無効化します。

パラメーターのマッピングなし

--validation-errors-fatal

オーバークラウドの作成プロセスでは、デプロイメントの前に一連のチェックが行われます。このオプションは、デプロイメント前のチェックで何らかの致命的なエラーが発生した場合に終了します。どのようなエラーが発生してもデプロイメントが失敗するので、このオプションを使用することを推奨します。

パラメーターのマッピングなし

--ntp-server

時刻の同期に使用する NTP サーバーを設定します。

NtpServer

これらのパラメーターは Red Hat OpenStack Platform から削除されています。CLI オプションは Heat パラメーターに変換して、環境ファイルに追加することを推奨します。

これらの新たなパラメーターを含んだ deprecated_cli_options.yaml ファイルの例を以下に示します。

parameter_defaults:
  ControllerCount: 3
  ComputeCount: 3
  CephStorageCount: 3
  ...

本ガイドの後半には、これらの新しいパラメーターを含む deprecated_cli_options.yaml 環境ファイルの例を記載しています。

5.8. コンポーザブルネットワーク

Red Hat OpenStack Platform の今回のバージョンでは、コンポーザブルネットワーク向けの新機能が導入されています。カスタムの roles_data ファイルを使用する場合には、ファイルを編集して、コンポーザブルネットワークを各ロールに追加します。コントローラーノードの場合の例を以下に示します。

- name: Controller
  networks:
    - External
    - InternalApi
    - Storage
    - StorageMgmt
    - Tenant

その他の構文例については、デフォルトの /usr/share/openstack-tripleo-heat-templates/roles_data.yaml ファイルを確認してください。また、ロールの例のスニペットについては、/usr/share/openstack-tripleo-heat-templates/roles を確認してください。

カスタムのスタンドアロンロールとコンポーザブルネットワークの対応表を以下に示します。

ロール必要なネットワーク

Ceph Storage Monitor

StorageStorageMgmt

Ceph Storage OSD

StorageStorageMgmt

Ceph Storage RadosGW

StorageStorageMgmt

Cinder API

InternalApi

Compute

InternalApiTenantStorage

Controller

ExternalInternalApiStorageStorageMgmtTenant

Database

InternalApi

Glance

InternalApi

Heat

InternalApi

Horizon

InternalApi

Ironic

必要なネットワークはなし。API には、プロビジョニング/コントロールプレーンネットワークを使用。

Keystone

InternalApi

Load Balancer

ExternalInternalApiStorageStorageMgmtTenant

Manila

InternalApi

Message Bus

InternalApi

Networker

InternalApiTenant

Neutron API

InternalApi

Nova

InternalApi

OpenDaylight

ExternalInternalApiTenant

Redis

InternalApi

Sahara

InternalApi

Swift API

Storage

Swift Storage

StorageMgmt

Telemetry

InternalApi

重要

以前のバージョンでは、*NetName パラメーター (例: InternalApiNetName) によってデフォルトのネットワークの名前が変更されていました。このパラメーターはサポートされなくなりました。カスタムのコンポーザブルネットワークファイルを使用してください。詳しい情報は、『オーバークラウドの高度なカスタマイズ』「カスタムコンポーザブルネットワーク」を参照してください。

5.9. Ceph Storage または HCI ノードのアップグレードの準備

コンテナー化されたサービスにアップグレードされたため、Ceph Storage ノードのインストールと更新の方法が変わりました。Ceph Storage の設定では、ceph-ansible パッケージ内の Playbook のセットを使用するようになりました。このパッケージはアンダークラウドにインストールします。

重要

手順

  1. director の管理する Ceph Storage クラスターまたは外部の Ceph Storage クラスターを使用している場合には、ceph-ansible パッケージをインストールします。

    1. アンダークラウドで Ceph Tools リポジトリーを有効にします。

      [stack@director ~]$ sudo subscription-manager repos --enable=rhel-7-server-rhceph-3-tools-rpms
    2. ceph-ansible パッケージをアンダークラウドにインストールします。

      [stack@director ~]$ sudo yum install -y ceph-ansible
  2. Ceph 固有の環境ファイルを確認し、Ceph 固有の heat リソースがコンテナー化されたサービスを使用する状態にします。

    • director が Ceph Storage クラスターを管理する場合には、resource_register のリソースが docker/services/ceph-ansible のテンプレートをポイントする状態にします。

      resource_registry:
        OS::TripleO::Services::CephMgr: /usr/share/openstack-tripleo-heat-templates/docker/services/ceph-ansible/ceph-mgr.yaml
        OS::TripleO::Services::CephMon: /usr/share/openstack-tripleo-heat-templates/docker/services/ceph-ansible/ceph-mon.yaml
        OS::TripleO::Services::CephOSD: /usr/share/openstack-tripleo-heat-templates/docker/services/ceph-ansible/ceph-osd.yaml
        OS::TripleO::Services::CephClient: /usr/share/openstack-tripleo-heat-templates/docker/services/ceph-ansible/ceph-client.yaml
      重要

      この設定は、/usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-ansible.yaml の環境ファイルに記載されています。このファイルは、-e を使用して今後すべてのデプロイメントコマンドに追加することができます。

      注記

      環境で使用する環境ファイルまたはテンプレートファイルが /usr/share ディレクトリーにない場合は、ファイルへの絶対パスを含める必要があります。

    • 外部 Ceph Storage クラスターの場合には、resource_register のリソースが docker/services/ceph-ansible のテンプレートをポイントする状態にします。

      resource_registry:
        OS::TripleO::Services::CephExternal: /usr/share/openstack-tripleo-heat-templates/docker/services/ceph-ansible/ceph-external.yaml
      重要

      この設定は、/usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-ansible-external.yaml の環境ファイルに記載されています。このファイルは、-e を使用して今後すべてのデプロイメントコマンドに追加することができます。

  3. director が管理する Ceph Storage クラスターの場合には、新しい CephAnsibleDisksConfig パラメーターを使用して、ディスクのマッピングの方法を定義します。以前のバージョンの Red Hat OpenStack Platform では、ceph::profile::params::osds hieradata を使用して OSD レイアウトを定義していました。この hieradata を CephAnsibleDisksConfig パラメーターの構成に変換します。以下の例で、Ceph ジャーナルディスクが共存する場合と共存しない場合について、hieradata を CephAnsibleDisksConfig パラメーターの構成に変換する方法を説明します。

    重要

    osd_scenario を設定する必要があります。osd_scenario を設定しないままにすると、デプロイメントに失敗する場合があります。

    • Ceph ジャーナルディスクが共存するケースで、hieradata が以下のようであれば、

      parameter_defaults:
        ExtraConfig:
          ceph::profile::params::osd_journal_size: 512
          ceph::profile::params::osds:
            '/dev/sdb': {}
            '/dev/sdc': {}
            '/dev/sdd': {}

      CephAnsibleDisksConfig パラメーターを使用して、以下のように hieradata を変換し、ceph::profile::params::osds{} に設定します。

      parameter_defaults:
        CephAnsibleDisksConfig:
          devices:
          - /dev/sdb
          - /dev/sdc
          - /dev/sdd
          journal_size: 512
          osd_scenario: collocated
        ExtraConfig:
            ceph::profile::params::osds: {}
    • ジャーナルがより高速な専用のデバイスにあり共存しないケースで、hieradata が以下のようであれば、

      parameter_defaults:
        ExtraConfig:
          ceph::profile::params::osd_journal_size: 512
          ceph::profile::params::osds:
            '/dev/sdb':
               journal: ‘/dev/sdn’
            '/dev/sdc':
               journal: ‘/dev/sdn’
            '/dev/sdd':
               journal: ‘/dev/sdn’

      CephAnsibleDisksConfig パラメーターを使用して、以下のように hieradata を変換し、ceph::profile::params::osds{} に設定します。

      parameter_defaults:
        CephAnsibleDisksConfig:
          devices:
          - /dev/sdb
          - /dev/sdc
          - /dev/sdd
          dedicated_devices:
          - /dev/sdn
          - /dev/sdn
          - /dev/sdn
          journal_size: 512
          osd_scenario: non-collocated
        ExtraConfig:
          ceph::profile::params::osds: {}

    ceph-ansible に使用する OSD ディスクレイアウトオプションの完全な一覧は、/usr/share/ceph-ansible/group_vars/osds.yml.sample のサンプルファイルを参照してください。

  4. 今後のデプロイメントコマンドでは、-e オプションを使用して新しい Ceph の設定環境ファイルを指定します。これには以下のファイルが含まれます。

    • director の管理する Ceph Storage の場合:

      • /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-ansible.yaml
      • Ansible ベースのディスクマッピングが含まれる環境ファイル
      • Ceph Storage のカスタマイズに関するその他の環境ファイル
    • 外部 Ceph Storage の場合:

      • /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-ansible-external.yaml
      • Ceph Storage のカスタマイズに関するその他の環境ファイル

5.10. ディスク構成が異なる Ceph または HCI ノードの環境変数の更新

HCI ノードの場合には、Compute サービスのアップグレードにはディスク定義に古い構文を使用し、ストレージサービスのアップグレードにはディスク定義に新しい構文を使用します。「Ceph Storage または HCI ノードのアップグレードの準備」を参照してください。ただし、ディスク構成が異なる場合も構文を更新しなければならない場合があります。

アップグレードするノードのディスクが同一ではない場合には、異なるディスク構成となります。たとえば、HCI ノードと Ceph Storage ノードが混在するケースでは、ディスク構成が異なります。

OpenStack Platform 12 から ceph-ansible が使用されるようになり、ディスク構成が異なる混在ノードを更新する際の構文が変更されています。つまり、OpenStack Platform 12 以降、ディスクを定義するために RoleExtraConfig のコンポーザブルロール構文を使用することはできません。以下の例を参照してください。

以下の例は、OpenStack Platform 12 以降では機能しません。

CephStorageExtraConfig:
  ceph::profile::params::osds:
    '/dev/sda'
    '/dev/sdb'
    '/dev/sdc'
    '/dev/sdd'

ComputeHCIExtraConfig:
  ceph::profile::params::osds:
    '/dev/sda'
    '/dev/sdb'

OpenStack Platform 12 以降は、アップグレードの前にテンプレートを更新する必要があります。異種ディスク構成のテンプレート更新方法に関する詳細は、『コンテナー化された Red Hat Ceph を持つオーバークラウドのデプロイ』「異なる構成の Ceph Storage ノードへのディスクレイアウトのマッピング」を参照してください。

5.11. 大規模 Ceph クラスターでの再開待機時間の延長

アップグレード中、それぞれの Ceph モニターおよび OSD は順に停止します。停止したものと同じサービスが正常に再開されるまで、移行は続行されません。Ansible は 15 秒間待って (待機) サービスの開始を確認する行為を 5 回繰り返します (リトライ)。サービスが再開されない場合には、移行は停止しオペレーターは手動操作を行う必要があります。

Ceph クラスターのサイズによっては、リトライまたは待機の値を増加しなければならない場合があります。これらのパラメーターの正確な名前およびそのデフォルト値は以下のとおりです。

 health_mon_check_retries: 5
 health_mon_check_delay: 15
 health_osd_check_retries: 5
 health_osd_check_delay: 15

これらのパラメーターのデフォルト値を更新できます。たとえば、40 秒間待って確認する行為を 30 回 (Ceph OSD の場合)、10 秒間待って確認する行為を 20 回 (Ceph MON の場合) 繰り返すようにクラスターを設定するには、openstack overcloud deploy コマンドの実行時に -e を使用して、yaml ファイルの以下のパラメーターを渡します。

parameter_defaults:
  CephAnsibleExtraConfig:
    health_osd_check_delay: 40
    health_osd_check_retries: 30
    health_mon_check_retries: 10
    health_mon_check_delay: 20

5.12. ストレージバックエンドの準備

一部のストレージバックエンドは、設定フックではなく、独自のコンポーザブルサービスを使用するように変更されました。カスタムストレージバックエンドを使用する場合には、environments ディレクトリーで関連する環境ファイルに新規パラメーターとリソースが含まれているかどうかを確認してください。バックエンド用のカスタム環境ファイルを更新します。以下に例を示します。

  • NetApp Block Storage (cinder) バックエンドの場合は、デプロイメント内の新しい environments/cinder-netapp-config.yaml を使用してください。
  • Dell EMC Block Storage (cinder) バックエンドの場合は、デプロイメント内の新しい environments/cinder-dellsc-config.yaml を使用してください。
  • Dell EqualLogic Block Storage (cinder) バックエンドの場合は、デプロイメント内の新しい environments/cinder-dellps-config.yaml を使用してください。

たとえば、NetApp Block Storage (cinder) バックエンドは、それぞれのバージョンに以下のリソースを使用していました。

  • OpenStack Platform 10 以前: OS::TripleO::ControllerExtraConfigPre: ../puppet/extraconfig/pre_deploy/controller/cinder-netapp.yaml
  • OpenStack Platform 11 以降: OS::TripleO::Services::CinderBackendNetApp: ../puppet/services/cinder-backend-netapp.yaml

今回の変更の結果、このバックエンドには新しい OS::TripleO::Services::CinderBackendNetApp リソースと、関連付けられたサービステンプレートを使用するようになりました。

5.13. SSL/TLS を介してアンダークラウドのパブリック API にアクセスするための準備

オーバークラウドは、アップグレード中にアンダークラウドの OpenStack Object Storage (swift) のパブリック API にアクセスする必要があります。アンダークラウドで自己署名証明書を使用している場合には、アンダークラウドの認証局を各オーバークラウドノードに追加する必要があります。

前提条件

  • アンダークラウドで、パブリック API に SSL/TLS を使用していること

手順

  1. director の動的な Ansible スクリプトが OpenStack Platform 12 バージョンに更新され、オーバークラウドプラン内の RoleNetHostnameMap Heat パラメーターを使用してインベントリーを定義するようになりました。ただし、オーバークラウドは現在 OpenStack Platform 11 のテンプレートバージョンを使用しており、これには RoleNetHostnameMap パラメーターがありません。これは、一時的な静的インベントリーファイルを作成する必要があることを意味します。このファイルは、以下のコマンドを実行すると生成することができます。

    $ openstack server list -c Networks -f value | cut -d"=" -f2 > overcloud_hosts
  2. 以下の内容を記述した Ansible Playbook (undercloud-ca.yml) を作成します。

    ---
    - name: Add undercloud CA to overcloud nodes
      hosts: all
      user: heat-admin
      become: true
      vars:
        ca_certificate: /etc/pki/ca-trust/source/anchors/cm-local-ca.pem
      tasks:
        - name: Copy undercloud CA
          copy:
            src: "{{ ca_certificate }}"
            dest: /etc/pki/ca-trust/source/anchors/
        - name: Update trust
          command: "update-ca-trust extract"
        - name: Get the swift endpoint
          shell: |
            sudo hiera swift::keystone::auth::public_url | awk -F/ '{print $3}'
          register: swift_endpoint
          delegate_to: 127.0.0.1
          become: yes
          become_user: stack
        - name: Verify URL
          uri:
            url: https://{{ swift_endpoint.stdout }}/healthcheck
            return_content: yes
          register: verify
        - name: Report output
          debug:
            msg: "{{ ansible_hostname }} can access the undercloud's Public API"
          when: verify.content == "OK"

    この Playbook には複数のタスクが含まれており、各ノードで以下の操作を実行します。

    • アンダークラウドの認証局ファイルをオーバークラウドノードにコピーします。アンダークラウドによって生成された場合には、デフォルトの場所は /etc/pki/ca-trust/source/anchors/cm-local-ca.pem です。
    • オーバークラウドノードで、認証局トラストデータベースを更新するコマンドを実行します。
    • オーバークラウドノードから、アンダークラウドの Object Storage パブリック API をチェックして、成功したかどうかを報告します。
  3. 以下のコマンドで Playbook を実行します。

    $ ansible-playbook -i overcloud_hosts undercloud-ca.yml

    ここでは、一時インベントリーを使用して、Ansible にオーバークラウドノードを指定します。

    カスタムの認証局ファイルを使用している場合は、ca_certificate 変数で場所を変更することができます。以下に例を示します。

    $ ansible-playbook -i overcloud_hosts undercloud-ca.yml -e ca_certificate=/home/stack/ssl/ca.crt.pem
  4. その結果、Ansible の出力には、ノードのデバッグメッセージが表示されます。以下に例を示します。

    ok: [192.168.24.100] => {
        "msg": "overcloud-controller-0 can access the undercloud's Public API"
    }

関連情報

5.14. Fast Forward Upgrade の登録の設定

Fast Forward Upgrade プロセスでは、リポジトリーの切り替えに新しい方法を採用しています。このため、デプロイメントのコマンドから以前の rhel-registration 環境ファイルを削除する必要があります。以下に例を示します。

  • environment-rhel-registration.yaml
  • rhel-registration-resource-registry.yaml

Fast Forward Upgrade のプロセスでは、アップグレードの各段階でスクリプトを使用してリポジトリーを変更します。このスクリプトは、OS::TripleO::Services::TripleoPackages コンポーザブルサービス (puppet/services/tripleo-packages.yaml) の一部として含まれ、FastForwardCustomRepoScriptContent パラメーターを使用します。スクリプトの内容は以下のとおりです。

#!/bin/bash
set -e
case $1 in
  ocata)
    subscription-manager repos --disable=rhel-7-server-openstack-10-rpms
    subscription-manager repos --enable=rhel-7-server-openstack-11-rpms
    ;;
  pike)
    subscription-manager repos --disable=rhel-7-server-openstack-11-rpms
    subscription-manager repos --enable=rhel-7-server-openstack-12-rpms
    ;;
  queens)
    subscription-manager repos --disable=rhel-7-server-openstack-12-rpms
    subscription-manager release --set=7.9
    subscription-manager repos --enable=rhel-7-server-openstack-13-rpms
    subscription-manager repos --disable=rhel-7-server-rhceph-2-osd-rpms
    subscription-manager repos --disable=rhel-7-server-rhceph-2-mon-rpms
    subscription-manager repos --enable=rhel-7-server-rhceph-3-mon-rpms
    subscription-manager repos --disable=rhel-7-server-rhceph-2-tools-rpms
    subscription-manager repos --enable=rhel-7-server-rhceph-3-tools-rpms
    ;;
  *)
    echo "unknown release $1" >&2
    exit 1
esac

director は、スクリプトに対して、OpenStack Platform バージョンのアップストリームのコード名を渡します。

コード名バージョン

ocata

OpenStack Platform 11

pike

OpenStack Platform 12

queens

OpenStack Platform 13

queens に変更を加えると、Ceph Storage 2 のリポジトリーも無効となり、Ceph Storage 3 MON と Tools のリポジトリーが有効になります。この変更では、Ceph Storage 3 OSD リポジトリーはコンテナー化されたため、有効になりません。

状況によっては、カスタムのスクリプトを使用する必要がある場合があります。以下に例を示します。

  • カスタムのリポジトリー名で Red Hat Satellite を使用する場合
  • カスタムの名前で接続されていないリポジトリーを使用する場合
  • 各段階に追加のコマンドを実行する場合

このような状況では、FastForwardCustomRepoScriptContent パラメーターを設定してカスタムスクリプトを追加します。

parameter_defaults:
  FastForwardCustomRepoScriptContent: |
    [INSERT UPGRADE SCRIPT HERE]

たとえば、以下のスクリプトは Satellite 6 アクティベーションキーのセットを使用して、リポジトリーを変更します。

parameter_defaults:
  FastForwardCustomRepoScriptContent: |
    set -e
    URL="satellite.example.com"
    case $1 in
      ocata)
        subscription-manager register --baseurl=https://$URL --force --activationkey=rhosp11 --org=Default_Organization
        ;;
      pike)
        subscription-manager register --baseurl=https://$URL --force --activationkey=rhosp12 --org=Default_Organization
        ;;
      queens)
        subscription-manager register --baseurl=https://$URL --force --activationkey=rhosp13 --org=Default_Organization
        ;;
      *)
        echo "unknown release $1" >&2
        exit 1
    esac

本ガイドの後半には、カスタムスクリプトを含む custom_repositories_script.yaml 環境ファイルについて記載しています。

5.15. カスタムの Puppet パラメーターの確認

Puppet パラメーターのカスタマイズに ExtraConfig インターフェースを使用する場合には、アップグレード中に、Puppet が重複した宣言のエラーを報告する可能性があります。これは、Puppet モジュール自体によって提供されるインターフェースの変更が原因です。

この手順では、環境ファイル内のカスタムの ExtraConfig hieradata パラメーターを確認する方法を説明します。

手順

  1. 環境ファイルを選択して、ExtraConfig パラメーターが設定されているかどうかを確認します。

    $ grep ExtraConfig ~/templates/custom-config.yaml
  2. このコマンドの結果に、選択したファイル内のいずれかのロールの ExtraConfig パラメーター (例: ControllerExtraConfig) が表示される場合には、そのファイルの完全なパラメーター構造を確認してください。
  3. SECTION/parameter 構文で value が続くいずれかの Puppet hieradata がパラメーターに含まれている場合には、実際の Puppet クラスのパラメーターに置き換えられている可能性があります。以下に例を示します。

    parameter_defaults:
      ExtraConfig:
        neutron::config::dhcp_agent_config:
          'DEFAULT/dnsmasq_local_resolv':
            value: 'true'
  4. director の Puppet モジュールを確認して、パラメーターが Puppet クラス内に存在しているかどうかを確認します。以下に例を示します。

    $ grep dnsmasq_local_resolv

    その場合には、新規インターフェースに変更します。

  5. 構文の変更の実例を以下に示します。

    • 例 1:

      parameter_defaults:
        ExtraConfig:
          neutron::config::dhcp_agent_config:
            'DEFAULT/dnsmasq_local_resolv':
              value: 'true'

      変更後

      parameter_defaults:
        ExtraConfig:
          neutron::agents::dhcp::dnsmasq_local_resolv: true
    • 例 2:

      parameter_defaults:
        ExtraConfig:
          ceilometer::config::ceilometer_config:
            'oslo_messaging_rabbit/rabbit_qos_prefetch_count':
              value: '32'

      変更後

      parameter_defaults:
        ExtraConfig:
          oslo::messaging::rabbit::rabbit_qos_prefetch_count: '32'

5.16. ネットワークインターフェースのテンプレートを新しい構造に変換する方法

以前は、ネットワークインターフェースの構造は OS::Heat::StructuredConfig リソースを使用してインターフェースを設定していました。

resources:
  OsNetConfigImpl:
    type: OS::Heat::StructuredConfig
    properties:
      group: os-apply-config
      config:
        os_net_config:
          network_config:
            [NETWORK INTERFACE CONFIGURATION HERE]

テンプレートは現在、OS::Heat::SoftwareConfig リソースを設定に使用しています。

resources:
  OsNetConfigImpl:
    type: OS::Heat::SoftwareConfig
    properties:
      group: script
      config:
        str_replace:
          template:
            get_file: /usr/share/openstack-tripleo-heat-templates/network/scripts/run-os-net-config.sh
          params:
            $network_config:
              network_config:
                [NETWORK INTERFACE CONFIGURATION HERE]

この設定では、$network_config 変数に保管されているインターフェースの設定を取得して、それを run-os-net-config.sh スクリプトの一部として挿入します。

警告

ネットワークインターフェースのテンプレートがこの新しい構造を使用するように更新して、ネットワークインターフェースのテンプレートが引き続き構文を順守していることを必ず確認する必要があります。この操作を実行しないと、Fast Forward Upgrade のプロセスでエラーが発生する可能性があります。

director の Heat テンプレートコレクションには、お使いのテンプレートをこの新しい形式に変換するためのスクリプトが含まれています。このスクリプトは、/usr/share/openstack-tripleo-heat-templates/tools/yaml-nic-config-2-script.py にあります。使用方法の例を以下に示します。

$ /usr/share/openstack-tripleo-heat-templates/tools/yaml-nic-config-2-script.py \
    --script-dir /usr/share/openstack-tripleo-heat-templates/network/scripts \
    [NIC TEMPLATE] [NIC TEMPLATE] ...
重要

このスクリプトを使用する場合には、テンプレートにコメント化された行が含まれていないことを確認します。コメント化された行があると、古いテンプレート構造の解析時にエラーが発生する可能性があります。

詳細は、「ネットワーク分離」を参照してください。

5.17. DPDK および SR-IOV 設定の確認

本項は、Data Plane Development Kit (DPDK) 統合および Single Root Input/Output Virtualization (SR-IOV) 等の NFV 技術を使用するオーバークラウドに関するものです。お使いのオーバークラウドがこれらの機能を使用していない場合には、本項を無視してください。

注記

Red Hat OpenStack Platform 10 では、第一ブートスクリプトファイルを OpenStack Platform 13 用のテンプレートである host-config-and-reboot.yaml に置き換える必要はありません。アップグレードプロセスの開始から完了まで第一ブートスクリプトを維持することで、新たなリブートを回避します。

5.17.1. DPDK 環境のアップグレード

DPDK を使用する環境では、コンテナー化環境に正しく移行するように特定のサービスマッピングを確認します。

手順

  1. コンテナー化されたサービスへの変換により、DPDK サービスの Fast Forward Upgrade は自動的に実施されます。DPDK 用のカスタム環境ファイルを使用している場合には、これらの環境ファイルを手動で調整してコンテナー化されたサービスにマッピングします。

      OS::TripleO::Services::ComputeNeutronOvsDpdk:
        /usr/share/openstack-tripleo-heat-templates/docker/services/neutron-ovs-dpdk-agent.yaml
    注記

    あるいは、最新の NFV 環境ファイル /usr/share/openstack-tripleo-heat-templates/environments/services/neutron-ovs-dpdk.yaml を使用します。

  2. OpenStack Network (Neutron) エージェントサービスを適切なコンテナー化されたテンプレートにマッピングします。

    • DPDK にデフォルトの Compute ロールを使用している場合には、ComputeNeutronOvsAgent サービスをコア Heat テンプレートコレクションの docker/services ディレクトリーの neutron-ovs-dpdk-agent.yaml ファイルにマッピングします。

      resource_registry:
        OS::TripleO::Services::ComputeNeutronOvsAgent:
          /usr/share/openstack-tripleo-heat-templates/docker/services/neutron-ovs-dpdk-agent.yaml
    • DPDK にカスタムロールを使用している場合には、ComputeNeutronOvsDpdkAgentCustom 等のカスタムコンポーザブルサービスが存在しているはずです。このサービスを docker ディレクトリーの neutron-ovs-dpdk-agent.yaml ファイルにマッピングします。
  3. 以下のサービスおよび追加パラメーターを DPDK のロール定義に追加します。

      RoleParametersDefault:
        VhostuserSocketGroup: "hugetlbfs"
        TunedProfileName: "cpu-paritioning"
    
      ServicesDefault:
        - OS::TripleO::Services::ComputeNeutronOvsDPDK
  4. 以下のサービスを削除します。

      ServicesDefault:
        - OS::TripleO::Services::NeutronLinuxbridgeAgent
        - OS::TripleO::Services::NeutronVppAgent
        - OS::TripleO::Services::Tuned

5.17.2. SR-IOV 環境のアップグレード

SR-IOV を使用する環境では、コンテナー化環境に正しく移行するように以下のサービスマッピングを確認します。

手順

  1. コンテナー化されたサービスへの変換により、SR-IOV サービスの Fast Forward Upgrade は自動的に実施されます。SR-IOV 用のカスタム環境ファイルを使用している場合には、これらのサービスをコンテナー化されたサービスに正しくマッピングします。

      OS::TripleO::Services::NeutronSriovAgent:
        /usr/share/openstack-tripleo-heat-templates/docker/services/neutron-sriov-agent.yaml
    
    OS::TripleO::Services::NeutronSriovHostConfig:
        /usr/share/openstack-tripleo-heat-templates/puppet/services/neutron-sriov-host-config.yaml
    注記

    あるいは、最新の NFV 環境ファイル /usr/share/openstack-tripleo-heat-templates/environments/services/neutron-sriov.yaml を使用します。

  2. roles_data.yaml ファイルに必要な SR-IOV サービスを含めます。

    SR-IOV に デフォルトCompute ロールを使用している場合には、適切なサービスを OpenStack Platform 13 のこのロールに含めます。

    • roles_data.yaml ファイルを /usr/share/openstack-tripleo-heat-templates からお使いのカスタムテンプレートディレクトリー (例: /home/stack/templates) にコピーします。
    • 以下のサービスをデフォルトの Compute ロールに追加します。

      • OS::TripleO::Services::NeutronSriovAgent
      • OS::TripleO::Services::NeutronSriovHostConfig
    • 以下のサービスをデフォルトの Compute ロールから削除します。

      • OS::TripleO::Services::NeutronLinuxbridgeAgent
      • OS::TripleO::Services::Tuned

        SR-IOV に カスタムCompute ロールを使用している場合には、NeutronSriovAgent サービスが存在しているはずです。Red Hat OpenStack Platform 13 で導入された NeutronSriovHostConfig サービスを追加します。

        注記

        この後のセクションで、ffwd-upgradeprepareconverge コマンドを実行する際に、roles_data.yaml ファイルを追加する必要があります。

5.18. 次のステップ

オーバークラウドの準備段階が完了しました。次に「6章オーバークラウドのアップグレード」に記載のステップに従って、オーバークラウドを 10 から 13 にアップグレードします。