director のインストールと使用方法

Red Hat OpenStack Platform 17.0

Red Hat OpenStack Platform director を使用した OpenStack クラウド作成のエンドツーエンドシナリオ

OpenStack Documentation Team

概要

エンタープライズ環境で Red Hat OpenStack Platform director を使用して Red Hat OpenStack Platform 17 をインストールします。これには、director のインストール、環境のプランニング、director を使用した OpenStack 環境の構築などが含まれます。

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

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

第1章 director の概要

Red Hat OpenStack Platform (RHOSP) director は、完全な RHOSP 環境のインストールおよび管理を行うためのツールセットです。director は、主に OpenStack プロジェクト TripleO をベースとしています。director により、完全に機能するスリムで堅牢な RHOSP 環境をインストールすることができます。この環境を使用して、OpenStack ノードして使用するベアメタルシステムのプロビジョニングおよび制御を行うことができます。

director は、アンダークラウドとオーバークラウドという 2 つの主要な概念を採用しています。まずアンダークラウドをインストールし、続いてアンダークラウドをツールとして使用してオーバークラウドをインストールおよび設定します。

Basic Layout of undercloud and overcloud

1.1. アンダークラウドを理解する

アンダークラウドは、Red Hat OpenStack Platform director ツールセットが含まれる主要管理ノードです。OpenStack をインストールした単一システムで、OpenStack 環境 (オーバークラウド) を設定する OpenStack ノードをプロビジョニング/管理するためのコンポーネントが含まれます。アンダークラウドを設定するコンポーネントは、さまざまな機能を持ちます。

環境のプランニング
アンダークラウドには、特定のノードロールを作成して割り当てるのに使用できるプランニング機能が含まれます。アンダークラウドには、Compute、Controller、さまざまな Storage ロールなど、特定のノードに割り当てることのできるデフォルトのノードロールセットが含まれます。また、カスタムロールを設定することもできます。さらに、各ノードロールにどの Red Hat OpenStack Platform サービスを含めるかを選択でき、新しいノード種別をモデル化するか、独自のホストで特定のコンポーネントを分離する方法を提供します。
ベアメタルシステムの制御
アンダークラウドは、各ノードの帯域外管理インターフェイス (通常 Intelligent Platform Management Interface (IPMI)) を使用して電源管理機能を制御し、PXE ベースのサービスを使用してハードウェア属性を検出し、各ノードに OpenStack をインストールします。この機能を使用して、ベアメタルシステムを OpenStack ノードとしてプロビジョニングすることができます。電源管理ドライバーの全リストについては、30章電源管理ドライバーを参照してください。
オーケストレーション
アンダークラウドには、環境のプランのセットに対応する YAML テンプレートセットが含まれます。アンダークラウドは、これらのプランをインポートして、その指示に従い、目的の OpenStack 環境を作成します。このプランに含まれるフックを使用して、環境作成プロセスの特定のポイントとして、カスタマイズを組み込むこともできます。
アンダークラウドのコンポーネント

アンダークラウドは、OpenStack のコンポーネントをベースのツールセットとして使用します。各コンポーネントは、アンダークラウドの個別のコンテナー内で動作します。

  • OpenStack Identity (keystone): director コンポーネントの認証および認可
  • OpenStack Bare Metal (ironic) - ベアメタルノードを管理します。
  • OpenStack Networking (neutron) および Open vSwitch: ベアメタルノードのネットワークの制御
  • OpenStack Orchestration (Ephemeral Heat) - director がオーバークラウドイメージをディスクに書き込んだ後、ノードのオーケストレーションを提供します。

1.2. オーバークラウドについて

オーバークラウドは、アンダークラウドが構築することで得られる Red Hat OpenStack Platform (RHOSP) 環境です。オーバークラウドは、さまざまなロールを持つ複数のノードで設定されます。このノード設定は、希望する OpenStack Platform 環境をベースに定義されます。アンダークラウドには、以下に示すオーバークラウドのデフォルトノードロールセットが含まれます。

コントローラー

コントローラーノードは、OpenStack 環境に管理、ネットワーク、高可用性の機能を提供します。コントローラーノード 3 台で高可用性クラスターを設定する OpenStack 環境が推奨されます。

デフォルトのコントローラーノードロールは、以下のコンポーネントをサポートします。これらのサービスがすべてデフォルトで有効化されている訳ではありません。これらのコンポーネントの中には、有効にするのにカスタムの環境ファイルまたは事前にパッケージ化された環境ファイルを必要とするものがあります。

  • OpenStack Dashboard (horizon)
  • OpenStack Identity (keystone)
  • OpenStack Compute (nova) API
  • OpenStack Networking (neutron)
  • OpenStack Image サービス (glance)
  • OpenStack Block Storage (cinder)
  • OpenStack Object Storage (swift)
  • OpenStack Orchestration (heat)
  • OpenStack Shared File Systems (manila)
  • OpenStack Bare Metal (ironic)
  • OpenStack Load Balancing-as-a-Service (octavia)
  • OpenStack Key Manager (barbican)
  • MariaDB
  • Open vSwitch
  • 高可用性サービス向けの Pacemaker および Galera
コンピュート

コンピュートノードは OpenStack 環境にコンピュートリソースを提供します。コンピュートノードをさらに追加して、環境を徐々にスケールアウトすることができます。デフォルトのコンピュートノードには、以下のコンポーネントが含まれます。

  • OpenStack Compute (nova)
  • KVM/QEMU
  • Open vSwitch
ストレージ

ストレージノードは OpenStack 環境にストレージを提供します。以下のリストで、RHOSP のさまざまなストレージノード種別について説明します。

  • Ceph Storage ノード: ストレージクラスターを設定するために使用します。それぞれのノードには、Ceph Object Storage Daemon (OSD) が含まれます。また、環境の一部として Ceph Storage ノードをデプロイする場合には、director により Ceph Monitor がコントローラーノードにインストールされます。
  • Block Storage (cinder): 高可用性コントローラーノードの外部 Block Storage として使用します。このノードには、以下のコンポーネントが含まれます。

    • OpenStack Block Storage (cinder) ボリューム
    • OpenStack Telemetry エージェント
    • Open vSwitch
  • Object Storage (swift): これらのノードは、OpenStack Swift の外部ストレージ層を提供します。コントローラーノードは、Swift プロキシーを介してオブジェクトストレージノードにアクセスします。オブジェクトストレージノードには、以下のコンポーネントが含まれます。

    • OpenStack Object Storage (swift) のストレージ
    • OpenStack Telemetry エージェント
    • Open vSwitch

1.3. Red Hat OpenStack Platform での高可用性について

Red Hat OpenStack Platform (RHOSP) director は、OpenStack Platform 環境に高可用性サービスを提供するためにコントローラーノードクラスターを使用します。それぞれのサービスについて、director はすべてのコントローラーノードに同じコンポーネントをインストールし、コントローラーノードをまとめて単一のサービスとして管理します。このタイプのクラスター設定では、1 つのコントローラーノードが機能しなくなった場合にフォールバックが可能です。これにより、OpenStack のユーザーには一定レベルの運用継続性が提供されます。

OpenStack Platform director は、複数の主要なソフトウェアを使用して、コントローラーノード上のコンポーネントを管理します。

  • Pacemaker: Pacemaker は、クラスターのリソースを管理します。Pacemaker は、クラスター内の全ノードにわたって OpenStack コンポーネントの可用性を管理および監視します。
  • HA Proxy: クラスターに負荷分散およびプロキシーサービスを提供します。
  • Galera: クラスター全体の RHOSP データベースを複製します。
  • Memcached: データベースのキャッシュを提供します。
注記
  • バージョン 13 から、director を使用してコンピュートインスタンスの高可用性 (インスタンス HA) をデプロイできるようになりました。インスタンス HA により、コンピュートノードで障害が発生した際にコンピュートノードからインスタンスを自動的に退避させることができます。

1.4. Red Hat OpenStack Platform でのコンテナー化について

アンダークラウドおよびオーバークラウド上の各 OpenStack Platform サービスは、対応するノード上の個別の Linux コンテナー内で実行されます。このコンテナー化により、サービスを分離し、環境を維持し、Red Hat OpenStack Platform (RHOSP) をアップグレードすることができます。

Red Hat OpenStack Platform 17.0 では、Red Hat Enterprise Linux 9.0 オペレーティングシステムへのインストールがサポートされます。Red Hat OpenStack Platform は以前、Docker を使用してコンテナー化を管理していました。OpenStack Platform 17.0 は、OpenStack Platform のデプロイとアップグレードに以下のツールを使用します。

Podman

Pod Manager (Podman) はコンテナー管理用のツールです。このツールには、ほとんどすべての Docker CLI コマンドが実装されています。ただし、Docker Swarm に関連するコマンドは含まれません。Podman は、Pod、コンテナー、およびコンテナーイメージを管理します。Podman は、バックグラウンドでデーモンを実行することなくリソースを管理できます。

Podman についての詳しい情報は、Podman の Web サイト を参照してください。

Buildah

Buildah は Open Containers Initiative (OCI) イメージのビルドに特化したツールで、Podman と共に使用します。Buildah コマンドは、Dockerfile の内容と等価です。Buildah は、コンテナーイメージをビルドするための低レベル coreutils インターフェイスも提供します。したがって、コンテナーをビルドするのに Dockerfile は必要ありません。また、Buildah は他のスクリプト言語を使用してコンテナーイメージをビルドしますが、その際にデーモンは必要ありません。

Buildah についての詳しい情報は、Buildah の Web サイト を参照してください。

Skopeo
Skopeo により、運用者はリモートコンテナーイメージを検査することができます。これは、director がイメージをプルする際にデータを収集するのに役立ちます。この機能に加えて、コンテナーイメージをあるレジストリーから別のレジストリーにコピーしたり、イメージをレジストリーから削除したりすることもできます。

Red Hat では、オーバークラウド用コンテナーイメージの管理に関して、以下の方法をサポートしています。

  • コンテナーイメージを Red Hat Container Catalog からアンダークラウド上の image-serve レジストリーにプルし、続いてそのイメージを image-serve レジストリーからプルする。イメージをアンダークラウドにプルする際には、複数のオーバークラウドノードが外部接続を通じて同時にコンテナーイメージをプルする状況を避けてください。
  • Satellite 6 サーバーからコンテナーイメージをプルする。ネットワークトラフィックは内部になるため、これらのイメージを Satellite から直接プルすることができます。

本ガイドでは、コンテナーイメージレジストリー情報の設定および基本的なコンテナー操作の実施について説明します。

1.5. Red Hat OpenStack Platform での Ceph Storage の使用

通常、Red Hat OpenStack Platform (RHOSP) を使用する大規模な組織では、数千単位またはそれ以上のクライアントにサービスを提供します。Block Storage リソースの消費に関して、それぞれの OpenStack クライアントは固有のニーズを持つのが一般的です。glance (イメージ)、cinder (ボリューム)、および nova (コンピュート) を単一ノードにデプロイすると、数千単位のクライアントがある大規模なデプロイメントでの管理ができなくなる可能性があります。このような課題は、OpenStack をスケールアウトすることによって解決できます。

ただし、実際には、Red Hat Ceph Storage などのソリューションを活用して、ストレージ層を仮想化する必要もでてきます。ストレージ層の仮想化により、RHOSP のストレージ層を数十テラバイト規模からペタバイトさらにはエクサバイトのストレージにスケーリングすることが可能です。Red Hat Ceph Storage は、市販のハードウェアを使用しながらも、高可用性/高パフォーマンスのストレージ仮想化層を提供します。仮想化によってパフォーマンスが低下するというイメージがありますが、Ceph はブロックデバイスイメージをクラスター全体でオブジェクトとしてストライプ化するため、大きな Ceph のブロックデバイスイメージはスタンドアロンのディスクよりも優れたパフォーマンスを示します。Ceph ブロックデバイスでは、パフォーマンスを強化するために、キャッシュ、Copy On Write クローン、Copy On Read クローンもサポートされています。

Red Hat Ceph Storage についての詳細な情報は、Red Hat Ceph Storage を参照してください。

1.6. デフォルトのファイルの場所

RHOSP 17 では、すべての設定ファイルが 1 つのディレクトリーにあります。ディレクトリーの名前は、使用した openstack コマンドとスタックの名前を組み合わせたものです。ディレクトリーにはデフォルトの場所がありますが、--working-dir オプションを使用してデフォルトの場所を変更できます。このオプションは、デプロイメントで使用されるファイルの読み取りまたは作成を行う任意の tripleoclient コマンドで使用できます。

デフォルトのロケーションコマンド

$HOME/tripleo-deploy/undercloud

tripleo deploy に基づく undercloud install

$HOME/tripleo-deploy/<stack>

tripleo deploy、<stack> はデフォルトでは standalone です

$HOME/overcloud-deploy/<stack>

overcloud deploy、<stack> はデフォルトではオーバークラウドです

1.6.1. アンダークラウドディレクトリーの内容説明

~/tripleo-deploy/undercloud ディレクトリーには、以下のファイルとディレクトリーがあります。これらは、~/overcloud-deploy ディレクトリーで利用可能なもののサブセットです。

heat_launcher
install-undercloud.log
tripleo-ansible-inventory.yaml
tripleo-config-generated-env-files
tripleo-undercloud-outputs.yaml
tripleo-undercloud-passwords.yaml
undercloud-install-20220823210316.tar.bzip2

1.6.2. オーバークラウドディレクトリーの内容の説明

以下のファイルとディレクトリーは ~/overcloud-deploy/overcloud ディレクトリーにあります。ここで、overcloud はスタックの名前に置き換えます。

cli-config-download
cli-enable-ssh-admin
cli-grant-local-access
cli-undercloud-get-horizon-url
config-download
environment
heat-launcher
outputs
overcloud-deployment_status.yaml
overcloud-export.yaml
overcloud-install-20220823213643.tar.bzip2
overcloud-passwords.yaml
overcloudrc
tempest-deployer-input.conf
tripleo-ansible-inventory.yaml
tripleo-heat-templates
tripleo-overcloud-baremetal-deployment.yaml
tripleo-overcloud-network-data.yaml
tripleo-overcloud-roles-data.yaml
tripleo-overcloud-virtual-ips.yaml

次の表に、これらのファイルとディレクトリーの内容を示します。

ディレクトリー説明

cli-*

ansible-runner が CLI ansible ベースのワークフローに使用するディレクトリー。

config-download

config-download ディレクトリー。以前は ~/config-download または /var/lib/mistral/<stack> と呼ばれていました。

environment

openstack stack environment show <stack> コマンドで生成された保存済みスタック環境が含まれています。

heat-launcher

一時的な Heat 設定とデータベースのバックアップを含む一時的な Heat 作業ディレクトリー。

outputs

openstack stack output show <stack> <output> コマンドで生成された保存済みスタック出力が含まれます。

<stack>-deployment_status.yaml

保存されたスタックステータスが含まれます。

<stack>-export.yaml

openstack overcloud export <stack> コマンドで生成されたスタックのエクスポート情報が含まれます。

<stack>-install-*.tar.bzip2

作業ディレクトリーの tarball。

<stack>-passwords.yaml

スタックのパスワードが含まれています。

<stack>rc

オーバークラウド API を使用するために必要な Stack rc 資格情報ファイル。

temployer-deployer-input.conf

Tempest 設定が含まれています。

tripleo-ansible-inventory.yaml

オーバークラウドの Ansible インベントリー。

tripleo-heat-templates

レンダリングされた jinja2 テンプレートのコピーが含まれています。ソーステンプレートは /usr/share/openstack-tripleo-heat-templates にあります。または、CLI で --templates オプションを使用してテンプレートを指定できます。

tripleo-overcloud-baremetal-deployment.yaml

オーバークラウドノードをプロビジョニングするためのベアメタルデプロイメントの入力。

tripleo-overcloud-network-data.yaml

オーバークラウドネットワークをプロビジョニングするためのネットワークデプロイメントの入力。

tripleo-overcloud-roles-data.yaml

CLI の -r オプションで指定されたロールデータ。

tripleo-overcloud-virtual-ips.yaml

オーバークラウドネットワーク VIP をプロビジョニングするための VIP デプロイメントの入力。

第2章 アンダークラウドのプランニング

アンダークラウドに director を設定してインストールする前に、アンダークラウドホストを計画して、特定の要件を満たしていることを確認する必要があります。

2.1. コンテナー化されたアンダークラウド

アンダークラウドは、最終的な Red Hat OpenStack Platform (RHOSP) 環境 (オーバークラウドと呼ばれる) の設定、インストール、および管理をコントロールするノードです。アンダークラウド自体は、コンテナー化された OpenStack Platform コンポーネントを使用して、director と呼ばれるツールセットを作成します。この場合、アンダークラウドはレジストリーソースからコンテナーイメージのセットをプルし、コンテナーの設定を生成し、各 OpenStack Platform サービスをコンテナーとして実行します。その結果、アンダークラウドによりコンテナー化されたサービスのセットが提供され、このサービスをオーバークラウドの作成および管理用ツールセットとして使用することができます。

アンダークラウドおよびオーバークラウドの両方でコンテナーが使用されているので、どちらも同じアーキテクチャーを使用してコンテナーをプル、設定、および実行します。このアーキテクチャーは、OpenStack Orchestration サービス (heat) をベースにノードをプロビジョニングし、Ansible を使用してサービスおよびコンテナーを設定します。heat および Ansible に関する知識を習得していると、異常発生時のトラブルシューティングに役立ちます。

2.2. アンダークラウドネットワークの準備

アンダークラウドでは、2 つの主要ネットワークへのアクセスが必要です。

  • プロビジョニングまたはコントロールプレーンネットワーク: director は、このネットワークを使用してノードをプロビジョニングし、Ansible 設定の実行時に SSH 経由でこれらのノードにアクセスします。このネットワークでは、アンダークラウドからオーバークラウドノードへの SSH アクセスも可能です。アンダークラウドには、このネットワーク上の他のノードのイントロスペクションおよびプロビジョニング用 DHCP サービスが含まれます。つまり、このネットワーク上にその他の DHCP サービスは必要ありません。director がこのネットワークのインターフェイスを設定します。
  • External ネットワーク: このネットワークにより、OpenStack Platform リポジトリー、コンテナーイメージソース、および DNS サーバーや NTP サーバー等の他のサーバーにアクセスすることができます。ご自分のワークステーションからアンダークラウドへの標準アクセスには、このネットワークを使用します。External ネットワークにアクセスするためには、アンダークラウド上でインターフェイスを手動で設定する必要があります。

アンダークラウドには、少なくとも 2 枚の 1 Gbps ネットワークインターフェイスカードが必要です。1 枚は プロビジョニングまたはコントロールプレーンネットワーク 用で、残りの 1 枚は External ネットワーク 用です。

ネットワークを計画する際には、以下のガイドラインを確認してください。

  • Red Hat は、プロビジョニングとコントロールプレーンに 1 つのネットワークを使用し、データプレーンに別のネットワークを使用することを推奨します。
  • プロビジョニングおよびコントロールプレーンネットワークは、Linux ボンディング上または個々のインターフェイスで設定できます。Linux ボンディングを使用する場合は、アクティブバックアップボンディングタイプとして設定します。

    • 非コントローラーノードでは、プロビジョニングおよびコントロールプレーンネットワークのトラフィック量は比較的少なく、高帯域幅や負荷分散は必要ありません。
    • コントローラーでは、プロビジョニングおよびコントロールプレーンネットワークに追加の帯域幅が必要です。帯域幅が増加する理由は、コントローラーが他のロールで多くのノードにサービスを提供するためです。環境に頻繁に変更を加える場合も、より多くの帯域幅が必要になります。

      最高のパフォーマンスを得るには、50 を超えるコンピュートノードを備えたコントローラー (または 4 つを超えるベアメタルノードが同時にプロビジョニングされている場合) は、非コントローラーノードのインターフェイスの 4 〜 10 倍の帯域幅を備えている必要があります。

  • 50 を超えるオーバークラウドノードがプロビジョニングされる場合、アンダークラウドはプロビジョニングネットワークへのより高い帯域幅の接続を持つ必要があります。
  • ワークステーションから director マシンへのアクセスに使用する NIC を、プロビジョニングまたはコントロールプレーン NIC として使用しないでください。director のインストールでは、プロビジョニング NIC を使用してブリッジが作成され、リモート接続はドロップされます。director システムへリモート接続する場合には、外部 NIC を使用します。
  • プロビジョニングネットワークには、環境のサイズに適した IP 範囲が必要です。以下のガイドラインを使用して、この範囲に含めるべき IP アドレスの総数を決定してください。

    • イントロスペクション中は、プロビジョニングネットワークに接続されているノードごとに少なくとも 1 つの一時 IP アドレスを含めます。
    • デプロイメント中は、プロビジョニングネットワークに接続されているノードごとに少なくとも 1 つの永続的な IP アドレスを含めます。
    • プロビジョニングネットワーク上のオーバークラウド高可用性クラスターの仮想 IP 用に、追加の IP アドレスを含めます。
    • 環境のスケーリング用に、この範囲にさらに IP アドレスを追加します。
  • コントローラーノードのネットワークカードまたはネットワークスイッチの異常がオーバークラウドサービスの可用性を阻害するのを防ぐには、keystone 管理エンドポイントがボンディングされたネットワークカードまたはネットワークハードウェアの冗長性を使用するネットワークに配置されるようにしてください。keystone エンドポイントを internal_api などの別のネットワークに移動する場合は、アンダークラウドが VLAN またはサブネットに到達できるようにします。詳細は、Red Hat ナレッジベースのソリューション Keystone Admin Endpoint を internal_api network に移行する方法 を参照してください。

2.3. 環境規模の判断

アンダークラウドをインストールする前に、環境の規模を判断します。環境をプランニングする際には、以下の要素を考慮してください。

オーバークラウドにデプロイするノードの数
アンダークラウドは、オーバークラウド内の各ノードを管理します。オーバークラウドノードのプロビジョニングには、アンダークラウドのリソースが使用されます。アンダークラウドには、すべてのオーバークラウドノードを適切にプロビジョニングし管理するのに十分なリソースを提供する必要があります。
アンダークラウドで実行する同時操作の数
アンダークラウド上の OpenStack サービスの多くは、ワーカーのセットを使用します。それぞれのワーカーは、そのサービスに固有の操作を実行します。複数のワーカーを用いると、同時に操作を実行することができます。アンダークラウドのデフォルトのワーカー数は、アンダークラウドの合計 CPU スレッド数の半分です。ここでは、スレッド数とは CPU コア数にハイパースレッディングの値を掛けたものを指します。たとえば、アンダークラウドの CPU スレッド数が 16 の場合には、デフォルトでは、director のサービス により 8 つのワーカーが提供されます。デフォルトでは、director のサービスに最小および最大のワーカー数も適用されます。
サービス最小値最大値

OpenStack Orchestration (heat)

4

24

その他すべてのサービス

2

12

アンダークラウドの CPU およびメモリーの最低要件を以下に示します。

  • Intel 64 または AMD64 CPU 拡張機能をサポートする、8 スレッド 64 ビット x86 プロセッサー。これにより、各アンダークラウドサービスに 4 つのワーカーが提供されます。
  • 最小 24 GB の RAM

多数のワーカーを使用するには、以下の推奨事項に従ってアンダークラウドの仮想 CPU 数およびメモリー容量を増やします。

  • 最小値: 1 スレッドあたり 1.5 GB のメモリーを使用します。たとえば、48 スレッドのマシンの場合、heat 用 24 ワーカーおよびその他のサービス用 12 ワーカーを最低限動作させるのに、72 GB の RAM が必要です。
  • 推奨値: 1 スレッドあたり 3 GB のメモリーを使用します。たとえば、48 スレッドのマシンの場合、heat 用 24 ワーカーおよびその他のサービス用 12 ワーカーを推奨される状態で動作させるのに、144 GB の RAM が必要です。

2.4. アンダークラウドのディスクサイズ

アンダークラウドのディスクサイズとして、ルートディスク上に少なくとも 100 GB の空きディスク領域があることが推奨されます。

  • コンテナーイメージ用に 20 GB
  • QCOW2 イメージの変換とノードのプロビジョニングプロセスのキャッシュ用に 10 GB
  • 一般用途、ログの記録、メトリック、および将来の拡張用に 70 GB 以上

2.5. 仮想化のサポート

Red Hat は、以下のプラットフォームでのみ仮想アンダークラウドをサポートします。

プラットフォーム説明

Kernel-based Virtual Machine (KVM)

Red Hat OpenStack Platform、Red Hat Virtualization、OpenShift Virtualization、および Red Hat Enterprise Linux with KVM の認定ゲストオペレーティングシステム に記載されているように、Red Hat Enterprise Linux によってホストされます。

Red Hat Virtualization

Certified Red Hat Hypervisors に記載のとおり、Red Hat Virtualization 4.x でホストされている。

Microsoft Hyper-V

Red Hat Customer Portal Certification Catalogue に記載の Hyper-V のバージョンでホストされている。

VMware ESX および ESXi

Red Hat Customer Portal Certification Catalogue に記載の ESX および ESXi のバージョンでホストされている。

重要

ハイパーバイザーが Red Hat Enterprise Linux 9.0 ゲストをサポートしていることを確認します。

仮想マシンの要件

仮想アンダークラウドのリソース要件は、ベアメタルのアンダークラウドの要件と似ています。ネットワークモデル、ゲスト CPU 機能、ストレージのバックエンド、ストレージのフォーマット、キャッシュモードなどプロビジョニングの際には、さまざまなチューニングオプションを検討してください。

ネットワークの考慮事項

電源管理
アンダークラウド仮想マシン (VM) は、オーバークラウドノードの電源管理デバイスにアクセスする必要があります。これには、ノードの登録の際に、pm_addr パラメーターに IP アドレスを設定してください。
プロビジョニングネットワーク
プロビジョニングネットワーク (ctlplane) に使用する NIC には、オーバークラウドのベアメタルノードの NIC に対する DHCP 要求をブロードキャストして、対応する機能が必要です。仮想マシンの NIC をベアメタル NIC と同じネットワークに接続するブリッジを作成します。
不明なアドレスからのトラフィックを許可する

アンダークラウドをブロックしているハイパーバイザーが未知のアドレスからトラフィックを送信しないように、仮想アンダークラウドハイパーバイザーを設定する必要があります。設定は、仮想アンダークラウドに使用しているプラットフォームによって異なります。

  • Red Hat Enterprise Virtualization: anti-mac-spoofing パラメーターを無効にします。
  • VMware ESX または ESXi:

    • IPv4 ctlplane ネットワーク: 偽造送信を許可します。
    • IPv6 ctlplane ネットワーク: 偽造送信、MAC アドレスの変更、無差別モード操作を許可します。

      VMware ESX または ESXi を設定する方法の詳細については、VMware ドキュメント Web サイトの vSphere 標準スイッチのセキュリティー保護 を参照してください。

これらの設定を適用したら、director 仮想マシンの電源を一旦オフにしてから再投入する必要があります。仮想マシンを再起動するだけでは不十分です。

2.6. 文字のエンコーディング設定

Red Hat OpenStack Platform には、ロケール設定の一部として特殊文字のエンコーディングに関する要件があります。

  • すべてのノードで UTF-8 エンコーディングを使用します。すべてのノードで LANG 環境変数を en_US.UTF-8 に設定するようにします。
  • Red Hat OpenStack Platform リソース作成の自動化に Red Hat Ansible Tower を使用している場合は、非 ASCII 文字を使用しないでください。

2.7. プロキシーを使用してアンダークラウドを実行する際の考慮事項

プロキシーを使用してアンダークラウドを実行する場合は特定の制限があります。Red Hat は、レジストリーおよびパッケージ管理に Red Hat Satellite を使用することを推奨します。

ただし、ご自分の環境でプロキシーを使用している場合は、以下の考慮事項を確認して、Red Hat OpenStack Platform の一部とプロキシーを統合する際のさまざまな設定手法、およびそれぞれの手法の制限事項を十分に理解するようにしてください。

システム全体のプロキシー設定

アンダークラウド上のすべてのネットワークトラフィックに対してプロキシー通信を設定するには、この手法を使用します。プロキシー設定を定義するには、/etc/environment ファイルを編集して以下の環境変数を設定します。

http_proxy
標準の HTTP リクエストに使用するプロキシー
https_proxy
HTTPs リクエストに使用するプロキシー
no_proxy
プロキシー通信から除外するドメインのコンマ区切りリスト

システム全体のプロキシー手法には、以下の制限事項があります。

  • pam_env PAM モジュールのバッファーが固定されているため、no_proxy の最大長は 1024 文字です。

dnf プロキシー設定

すべてのトラフィックがプロキシーを通過するように dnf を設定するには、この手法を使用します。プロキシー設定を定義するには、/etc/dnf/dnf.conf ファイルを編集して以下のパラメーターを設定します。

proxy
プロキシーサーバーの URL
proxy_username
プロキシーサーバーへの接続に使用するユーザー名
proxy_password
プロキシーサーバーへの接続に使用するパスワード
proxy_auth_method
プロキシーサーバーが使用する認証方法

これらのオプションの詳細については、man dnf.conf を実行してください。

dnf プロキシー手法には、以下の制限事項があります。

  • この手法では、dnf に対してのみプロキシーがサポートされます。
  • dnf プロキシー手法には、特定のホストをプロキシー通信から除外するオプションは含まれていません。

Red Hat Subscription Manager プロキシー

すべてのトラフィックがプロキシーを通過するように Red Hat Subscription Manager を設定するには、この手法を使用します。プロキシー設定を定義するには、/etc/rhsm/rhsm.conf ファイルを編集して以下のパラメーターを設定します。

proxy_hostname
プロキシーのホスト
proxy_scheme
プロキシーをリポジトリー定義に書き出す際のプロキシーのスキーム
proxy_port
プロキシーのポート
proxy_username
プロキシーサーバーへの接続に使用するユーザー名
proxy_password
プロキシーサーバーへの接続に使用するパスワード
no_proxy
プロキシー通信から除外する特定ホストのホスト名接尾辞のコンマ区切りリスト

これらのオプションの詳細については、man rhsm.conf を実行してください。

Red Hat Subscription Manager プロキシー手法には、以下の制限事項があります。

  • この手法では、Red Hat Subscription Manager に対してのみプロキシーがサポートされます。
  • Red Hat Subscription Manager プロキシー設定の値は、システム全体の環境変数に設定されたすべての値をオーバーライドします。

透過プロキシー

アプリケーション層のトラフィックを管理するのにネットワークで透過プロキシーが使用される場合は、プロキシー管理が自動的に行われるため、アンダークラウド自体をプロキシーと対話するように設定する必要はありません。透過プロキシーは、Red Hat OpenStack Platform のクライアントベースのプロキシー設定に関連する制限に対処するのに役立ちます。

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

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

警告

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

注記

RHOSP 17.0 は Satellite をサポートしていないため、Satellite リポジトリーはリストされていません。今後のリリースで Satellite がサポートされる予定です。パッケージリポジトリーおよびコンテナーレジストリーとしてサポートされるのは、Red Hat CDN のみです。

コアリポジトリー

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

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

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

rhel-9-for-x86_64-baseos-eus-rpms

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

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

rhel-9-for-x86_64-appstream-eus-rpms

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

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

rhel-9-for-x86_64-highavailability-eus-rpms

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

Red Hat OpenStack Platform 17.0 for RHEL 9 (RPMs)

openstack-17-for-rhel-9-x86_64-rpms

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

Red Hat Fast Datapath for RHEL 9 (RPMS)

fast-datapath-for-rhel-9-x86_64-rpms

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

第3章 heat テンプレートの概要

本章のカスタム設定では、heat テンプレートおよび環境ファイルを使用して、オーバークラウドの特定の機能を定義します。本項には、Red Hat OpenStack Platform director に関連した heat テンプレートの構造や形式を理解するための基本的な説明を記載します。

3.1. heat テンプレート

director は、Heat Orchestration Template (HOT) をオーバークラウドデプロイメントプランのテンプレート形式として使用します。HOT 形式のテンプレートは、通常 YAML 形式で表現されます。テンプレートの目的は、OpenStack Orchestration (heat) が作成するリソースのコレクションであるスタックを定義および作成し、リソースを設定することです。リソースとは、コンピュートリソース、ネットワーク設定、セキュリティーグループ、スケーリングルール、カスタムリソースなどの Red Hat OpenStack Platform (RHOSP) のオブジェクトを指します。

heat テンプレートは、3 つの主要なセクションで設定されます。

parameters
これらは、heat に渡される設定 (スタックのカスタマイズが可能) およびパラメーターのデフォルト値 (値を渡さない場合) です。これらの設定がテンプレートの parameters セクションで定義されます。
resources
resources セクションを使用して、このテンプレートを使用してスタックをデプロイする際に作成することができるリソース (コンピュートインスタンス、ネットワーク、ストレージボリューム等) を定義します。Red Hat OpenStack Platform (RHOSP) には、全コンポーネントに対応するコアリソースのセットが含まれています。これらは、スタックの一部として作成/設定する固有のオブジェクトです。RHOSP には、全コンポーネントに対応するコアリソースのセットが含まれています。これらがテンプレートの resources セクションで定義されます。
outputs
outputs セクションを使用して、スタックの作成後にクラウドユーザーがアクセスできるアウトプットパラメーターを宣言します。クラウドユーザーはこれらのパラメーターを使用して、デプロイしたインスタンスの IP アドレスやスタックの一部としてデプロイされた Web アプリケーションの URL 等のスタックの詳細を要求することができます。

基本的な heat テンプレートの例:

heat_template_version: 2013-05-23

description: > A very basic Heat template.

parameters:
  key_name:
    type: string
    default: lars
    description: Name of an existing key pair to use for the instance
  flavor:
    type: string
    description: Instance type for the instance to be created
    default: m1.small
  image:
    type: string
    default: cirros
    description: ID or name of the image to use for the instance

resources:
  my_instance:
    type: OS::Nova::Server
    properties:
      name: My Cirros Instance
      image: { get_param: image }
      flavor: { get_param: flavor }
      key_name: { get_param: key_name }

output:
  instance_name:
    description: Get the instance's name
    value: { get_attr: [ my_instance, name ] }

このテンプレートは、リソース種別 type: OS::Nova::Server を使用して、クラウドユーザーが指定する特定のフレーバー、イメージ、およびキーで my_instance というインスタンスを作成します。このスタックは、My Cirros Instance という instance_name の値を返すことができます。

heat がテンプレートを処理する際には、テンプレートのスタックとリソーステンプレートの子スタックセットを作成します。これにより、テンプレートで定義するメインのスタックを最上位とするスタックの階層が作成されます。以下のコマンドを使用して、スタックの階層を表示することができます。

$ openstack stack list --nested

3.2. 環境ファイル

環境ファイルとは特別な種類のテンプレートで、これを使用して heat テンプレートをカスタマイズすることができます。コアの heat テンプレートに加えて、環境ファイルをデプロイメントコマンドに追加することができます。環境ファイルには、3 つの主要なセクションが含まれます。

resource_registry
このセクションでは、他の heat テンプレートにリンクしたカスタムのリソース名を定義します。これにより、コアリソースコレクションに存在しないカスタムのリソースを作成することができます。
parameters
これらは、最上位のテンプレートのパラメーターに適用する共通設定です。たとえば、入れ子状のスタックをデプロイするテンプレートの場合には (リソースレジストリーマッピング等)、パラメーターは最上位のテンプレートにのみ適用され、入れ子状のリソースのテンプレートには適用されません。
parameter_defaults
これらのパラメーターは、全テンプレートのパラメーターのデフォルト値を変更します。たとえば、入れ子状のスタックをデプロイする heat テンプレートの場合には (リソースレジストリーマッピングなど)、パラメーターのデフォルト値がすべてのテンプレートに適用されます。
重要

パラメーターがオーバークラウドのすべてのスタックテンプレートに適用されるように、オーバークラウド用にカスタムの環境ファイルを作成する場合には、parameters ではなく parameter_defaults を使用します。

基本的な環境ファイルの例:

resource_registry:
  OS::Nova::Server::MyServer: myserver.yaml

parameter_defaults:
  NetworkName: my_network

parameters:
  MyIP: 192.168.0.1

特定の heat テンプレート (my_template.yaml) からスタックを作成する際に、この環境ファイル (my_env.yaml) を追加します。my_env.yaml ファイルにより、OS::Nova::Server::MyServer という新しいリソース種別が作成されます。myserver.yaml ファイルは、このリソース種別を実装する heat テンプレートファイルで、このファイルでの設定が元の設定よりも優先されます。my_template.yaml ファイルに OS::Nova::Server::MyServer リソースを含めることができます。

MyIP は、この環境ファイルと共にデプロイを行うメインの heat テンプレートにしかパラメーターを適用しません。この例では、MyIPmy_template.yaml のパラメーターにのみ適用します。

NetworkName はメインの heat テンプレート (my_template.yaml) とメインのテンプレートに含まれるリソースに関連付けられたテンプレート (上記の例では OS::Nova::Server::MyServer リソースとその myserver.yaml テンプレート) の両方に適用されます。

注記

RHOSP が heat テンプレートファイルをカスタムテンプレートリソースとして使用するには、ファイルの拡張子を .yaml または .template のいずれかにする必要があります。

3.3. オーバークラウドのコア heat テンプレート

director には、オーバークラウド用のコア heat テンプレートコレクションおよび環境ファイルコレクションが含まれます。このコレクションは、/usr/share/openstack-tripleo-heat-templates に保存されています。

このテンプレートコレクションの主なファイルおよびディレクトリーは、以下のとおりです。

overcloud.j2.yaml
オーバークラウド環境を作成するのに director が使用するメインのテンプレートファイル。このファイルでは Jinja2 構文を使用してテンプレートの特定セクションを繰り返し、カスタムロールを作成します。Jinja2 フォーマットは、オーバークラウドのデプロイメントプロセス中に YAML にレンダリングされます。
overcloud-resource-registry-puppet.j2.yaml
オーバークラウド環境を作成するのに director が使用するメインの環境ファイル。このファイルは、オーバークラウドイメージ上に保存される Puppet モジュールの設定セットを提供します。director により各ノードにオーバークラウドのイメージが書き込まれると、heat はこの環境ファイルに登録されているリソースを使用して各ノードの Puppet 設定を開始します。このファイルでは Jinja2 構文を使用してテンプレートの特定セクションを繰り返し、カスタムロールを作成します。Jinja2 フォーマットは、オーバークラウドのデプロイメントプロセス中に YAML にレンダリングされます。
roles_data.yaml
このファイルにはオーバークラウド内のロールの定義が含まれ、サービスを各ロールにマッピングします。
network_data.yaml
このファイルには、オーバークラウド内のネットワーク定義、およびそれらのサブネット、割り当てプール、仮想 IP のステータス等の属性が含まれます。デフォルトの network_data.yaml ファイルにはデフォルトのネットワーク (External、Internal Api、Storage、Storage Management、Tenant、および Management) が含まれます。カスタムの network_data.yaml ファイルを作成して、openstack overcloud deploy コマンドに -n オプションで追加することができます。
plan-environment.yaml
このファイルには、オーバークラウドプランのメタデータの定義が含まれます。これには、プラン名、使用するメインのテンプレート、およびオーバークラウドに適用する環境ファイルが含まれます。
capabilities-map.yaml
このファイルには、オーバークラウドプランの環境ファイルのマッピングが含まれます。
deployment
このディレクトリーには、heat テンプレートが含まれます。overcloud-resource-registry-puppet.j2.yaml 環境ファイルは、このディレクトリーのファイルを使用して、各ノードに Puppet の設定が適用されるようにします。
environments
このディレクトリーには、オーバークラウドの作成に使用可能なその他の heat 環境ファイルが含まれます。これらの環境ファイルは、作成された Red Hat OpenStack Platform (RHOSP) 環境の追加の機能を有効にします。たとえば、ディレクトリーには Cinder NetApp のバックエンドストレージ (cinder-netapp-config.yaml) を有効にする環境ファイルが含まれています。
network
このディレクトリーには、分離ネットワークおよびポートを作成するのに使用できる heat テンプレートのセットが含まれます。
puppet
このディレクトリーには、Puppet 設定を制御するテンプレートが含まれます。overcloud-resource-registry-puppet.j2.yaml 環境ファイルは、このディレクトリーのファイルを使用して、各ノードに Puppet の設定が適用されるようにします。
puppet/services
このディレクトリーには、全サービス設定用のレガシー heat テンプレートが含まれます。puppet/services ディレクトリー内のほとんどのテンプレートが、deployment ディレクトリーのテンプレートに置き換えられています。
extraconfig
このディレクトリーには、追加機能を有効にするのに使用できるテンプレートが含まれます。

3.4. プランの環境メタデータ

プランの環境メタデータファイルで、オーバークラウドプランのメタデータを定義することができます。director は、オーバークラウドの作成時およびオーバークラウドプランのインポート/エクスポート時にメタデータを適用します。

プランの環境メタデータファイルには、以下のパラメーターが含まれます。

version
テンプレートのバージョン
name
オーバークラウドプランおよびプランのファイルを保管するのに使用する OpenStack Object Storage (swift) 内のコンテナーの名前
template
オーバークラウドのデプロイメントに使用するコアの親テンプレート。これは、大半の場合は overcloud.yaml (overcloud.yaml.j2 テンプレートをレンダリングしたバージョン) です。
environments
使用する環境ファイルのリストを定義します。各環境ファイルの名前および相対位置を path サブパラメーターで指定します。
parameter_defaults
オーバークラウドで使用するパラメーターのセット。これは、標準の環境ファイルの parameter_defaults セクションと同じように機能します。
パスワード
オーバークラウドのパスワードに使用するパラメーターのセット。これは、標準の環境ファイルの parameter_defaults セクションと同じように機能します。通常、このセクションは director が無作為に生成したパスワードにより自動的に設定されます。

プランの環境ファイルの構文の例を、以下のスニペットに示します。

version: 1.0
name: myovercloud
description: 'My Overcloud Plan'
template: overcloud.yaml
environments:
- path: overcloud-resource-registry-puppet.yaml
- path: environments/containers-default-parameters.yaml
- path: user-environment.yaml
parameter_defaults:
  ControllerCount: 1
  ComputeCount: 1
  OvercloudComputeFlavor: compute
  OvercloudControllerFlavor: control
workflow_parameters:
  tripleo.derive_params.v1.derive_parameters:
    num_phy_cores_per_numa_node_for_pmd: 2

openstack overcloud deploy コマンドに -p オプションを使用して、プランの環境メタデータファイルを指定することができます。

(undercloud) $ openstack overcloud deploy --templates \
  -p /my-plan-environment.yaml \
  [OTHER OPTIONS]

以下のコマンドを使用して、既存のオーバークラウドプラン用のプランメタデータを確認することもできます。

(undercloud) $ openstack object save overcloud plan-environment.yaml --file -

3.5. オーバークラウド作成時の環境ファイルの追加

-e オプションを使用して、デプロイメントコマンドに環境ファイルを追加します。必要に応じていくつでも環境ファイルを追加することができます。ただし、後で指定する環境ファイルで定義されるパラメーターとリソースが優先されることになるため、環境ファイルの順番は重要です。この例では、両環境ファイルに共通のリソース種別 (OS::TripleO::NodeExtraConfigPost) と共通のパラメーター (TimeZone) が含まれています。

environment-file-1.yaml

resource_registry:
  OS::TripleO::NodeExtraConfigPost: /home/stack/templates/template-1.yaml

parameter_defaults:
  RabbitFDLimit: 65536
  TimeZone: 'Japan'

environment-file-2.yaml

resource_registry:
  OS::TripleO::NodeExtraConfigPost: /home/stack/templates/template-2.yaml

parameter_defaults:
  TimeZone: 'Hongkong'

デプロイメントコマンドに両方の環境ファイルを含めます。

$ openstack overcloud deploy --templates -e environment-file-1.yaml -e environment-file-2.yaml

openstack overcloud deploy コマンドは、以下のプロセスを順に実行します。

  1. コア heat テンプレートコレクションからデフォルト設定を読み込みます。
  2. environment-file-1.yaml の設定を適用します。この設定により、デフォルト設定と共通している設定は上書きされます。
  3. environment-file-2.yaml の設定を適用します。この設定により、デフォルト設定および environment-file-1.yaml と共通している設定は上書きされます。

これにより、オーバークラウドのデフォルト設定が以下のように変更されます。

  • OS::TripleO::NodeExtraConfigPost リソースは、environment-file-2.yaml で指定されているとおりに /home/stack/templates/template-2.yaml に設定されます。
  • TimeZone パラメーターは、environment-file-2.yaml で指定されているとおりに Hongkong に設定されます。
  • RabbitFDLimit パラメーターは、environment-file-1.yaml に定義されるように 65536 に設定されます。environment-file-2.yaml はこの値を変更しません。

この手法を使用して、複数の環境ファイルの値が競合することなく、オーバークラウドのカスタム設定を定義することができます。

3.6. カスタムのコア heat テンプレートの使用

オーバークラウドの作成時に、director は /usr/share/openstack-tripleo-heat-templates にある heat テンプレートのコアセットを使用します。このコアテンプレートコレクションをカスタマイズする場合は、以下の git ワークフローを使用してカスタムテンプレートコレクションを管理します。

手順

  • heat テンプレートコレクションが含まれる初期 git リポジトリーを作成します。

    1. テンプレートコレクションを /home/stack/templates ディレクトリーにコピーします。

      $ cd ~/templates
      $ cp -r /usr/share/openstack-tripleo-heat-templates .
    2. カスタムテンプレートのディレクトリーに移動して git リポジトリーを初期化します。

      $ cd ~/templates/openstack-tripleo-heat-templates
      $ git init .
    3. Git のユーザー名およびメールアドレスを設定します。

      $ git config --global user.name "<USER_NAME>"
      $ git config --global user.email "<EMAIL_ADDRESS>"
  • <USER_NAME> を使用するユーザー名に置き換えます。
  • <EMAIL_ADDRESS> をご自分のメールアドレスに置き換えます。

    1. 初期コミットに向けて全テンプレートをステージします。

      $ git add *
    2. 初期コミットを作成します。

      $ git commit -m "Initial creation of custom core heat templates"

      これで、最新のコアテンプレートコレクションを格納する初期 master ブランチが作成されます。このブランチは、カスタムブランチのベースとして使用し、新規テンプレートバージョンをこのブランチにマージします。

  • カスタムブランチを使用して、コアテンプレートコレクションの変更を保管します。以下の手順に従って my-customizations ブランチを作成し、カスタマイズを追加します。

    1. my-customizations ブランチを作成して、そのブランチに切り替えます。

      $ git checkout -b my-customizations
    2. カスタムブランチ内のファイルを編集します。
    3. 変更を git にステージします。

      $ git add [edited files]
    4. カスタムブランチに変更をコミットします。

      $ git commit -m "[Commit message for custom changes]"

      このコマンドにより、変更がコミットとして my-customizations ブランチに追加されます。master ブランチを更新するには、master から my-customizations にリベースすると、git はこれらのコミットを更新されたテンプレートに追加します。これは、カスタマイズをトラッキングして、今後テンプレートが更新された際にそれらを再生するのに役立ちます。

  • アンダークラウドの更新時には、openstack-tripleo-heat-templates パッケージも更新を受け取る可能性があります。このような場合には、カスタムテンプレートコレクションも更新する必要があります。

    1. openstack-tripleo-heat-templates パッケージのバージョンを環境変数として保存します。

      $ export PACKAGE=$(rpm -qv openstack-tripleo-heat-templates)
    2. テンプレートコレクションのディレクトリーに移動して、更新されたテンプレート用に新規ブランチを作成します。

      $ cd ~/templates/openstack-tripleo-heat-templates
      $ git checkout -b $PACKAGE
    3. そのブランチの全ファイルを削除して、新しいバージョンに置き換えます。

      $ git rm -rf *
      $ cp -r /usr/share/openstack-tripleo-heat-templates/* .
    4. 初期コミット用にすべてのテンプレートを追加します。

      $ git add *
    5. パッケージ更新のコミットを作成します。

      $ git commit -m "Updates for $PACKAGE"
    6. このブランチを master にマージします。git 管理システム (例: GitLab) を使用している場合には、管理ワークフローを使用してください。git をローカルで使用している場合には、master ブランチに切り替えてから git merge コマンドを実行してマージします。

      $ git checkout master
      $ git merge $PACKAGE

master ブランチに最新のコアテンプレートコレクションが含まれるようになりました。これで、my-customization ブランチを更新されたコレクションからリベースできます。

  • my-customization ブランチを更新します。

    1. my-customizations ブランチに切り替えます。

      $ git checkout my-customizations
    2. このブランチを master からリベースします。

      $ git rebase master

      これにより、my-customizations ブランチが更新され、このブランチに追加されたカスタムコミットが再生されます。

  • リベース中に発生する競合を解決します。

    1. どのファイルで競合が発生しているかを確認します。

      $ git status
    2. 特定したテンプレートファイルで競合を解決します。
    3. 解決したファイルを追加します。

      $ git add [resolved files]
    4. リベースを続行します。

      $ git rebase --continue
  • カスタムテンプレートコレクションをデプロイします。

    1. 必ず my-customization ブランチに切り替えた状態にします。

      git checkout my-customizations
    2. openstack overcloud deploy コマンドに --templates オプションを付けて、ローカルのテンプレートディレクトリーを指定して実行します。

      $ openstack overcloud deploy --templates /home/stack/templates/openstack-tripleo-heat-templates [OTHER OPTIONS]
注記

ディレクトリーの指定をせずに --templates オプションを使用すると、director はデフォルトのテンプレートディレクトリー (/usr/share/openstack-tripleo-heat-templates) を使用します。

重要

Red Hat は、heat テンプレートコレクションを変更する代わりに 5章設定フック に記載の方法を使用することを推奨します。

3.7. Jinja2 構文のレンダリング

/usr/share/openstack-tripleo-heat-templates のコア heat テンプレートには、j2.yaml の拡張子が付いた多数のファイルが含まれています。これらのファイルには Jinja2 テンプレート構文が含まれ、director はこれらのファイルを .yaml 拡張子を持つ等価な静的 heat テンプレートにレンダリングします。たとえば、メインの overcloud.j2.yaml ファイルは overcloud.yaml にレンダリングされます。director はレンダリングされた overcloud.yaml ファイルを使用します。

Jinja2 タイプの heat テンプレートでは、Jinja2 構文を使用して反復値のパラメーターおよびリソースを作成します。たとえば、overcloud.j2.yaml ファイルには以下のスニペットが含まれます。

parameters:
...
{% for role in roles %}
  ...
  {{role.name}}Count:
    description: Number of {{role.name}} nodes to deploy
    type: number
    default: {{role.CountDefault|default(0)}}
  ...
{% endfor %}

director が Jinja2 構文をレンダリングする場合、director は roles_data.yaml ファイルで定義されるロールを繰り返し処理し、{{role.name}}Count パラメーターにロール名を代入します。デフォルトの roles_data.yaml ファイルには 5 つのロールが含まれ、ここでの例からは以下のパラメーターが作成されます。

  • ControllerCount
  • ComputeCount
  • BlockStorageCount
  • ObjectStorageCount
  • CephStorageCount

レンダリング済みバージョンのパラメーターの例を以下に示します。

parameters:
  ...
  ControllerCount:
    description: Number of Controller nodes to deploy
    type: number
    default: 1
  ...

director がレンダリングするのは、コア heat テンプレートディレククトリー内からの Jinja2 タイプのテンプレートおよび環境ファイルだけです。Jinja2 テンプレートをレンダリングする際の正しい設定方法を、以下のユースケースで説明します。

ユースケース 1: デフォルトのコアテンプレート

テンプレートのディレクトリー: /usr/share/openstack-tripleo-heat-templates/

環境ファイル: /usr/share/openstack-tripleo-heat-templates/environments/ssl/enable-internal-tls.j2.yaml

Director はデフォルトのコアテンプレートの場所 (--templates) を使用し、enable-internal-tls.j2.yaml ファイルを enable-internal-tls.yaml にレンダリングします。openstack overcloud deploy コマンドを実行するときに、-e オプションを使用して、レンダリングされた enable-internal-tls.yaml ファイルの名前を含めます。

$ openstack overcloud deploy --templates \
    -e /usr/share/openstack-tripleo-heat-templates/environments/ssl/enable-internal-tls.yaml
    ...

ユースケース 2: カスタムコアテンプレート

テンプレートディレクトリー: /home/stack/tripleo-heat-installer-templates

環境ファイル: /home/stack/tripleo-heat-installer-templates/environments/ssl/enable-internal-tls.j2.yaml

Director はカスタムコアテンプレートの場所 (--templates /home/stack/tripleo-heat-templates) を使用し、director はカスタムコアテンプレート内の enable-internal-tls.j2.yaml ファイルを enable-internal-tls.yaml にレンダリングします。openstack overcloud deploy コマンドを実行するときに、-e オプションを使用して、レンダリングされた enable-internal-tls.yaml ファイルの名前を含めます。

$ openstack overcloud deploy --templates /home/stack/tripleo-heat-templates \
    -e /home/stack/tripleo-heat-templates/environments/ssl/enable-internal-tls.yaml
    ...

ユースケース 3: 誤った設定

テンプレートのディレクトリー: /usr/share/openstack-tripleo-heat-templates/

環境ファイル: /home/stack/tripleo-heat-installer-templates/environments/ssl/enable-internal-tls.j2.yaml

director はカスタムコアテンプレートの場所を使用します (--templates /home/stack/tripleo-heat-installer-templates)。ただし、選択された enable-internal-tls.j2.yaml はカスタムコアテンプレート内に配置されていないため、enable-internal-tls.yaml にレンダリングされません。この設定ではデプロイメントに失敗します。

Jinja2 構文の静的テンプレートへの処理

process-templates.py スクリプトを使用して、openstack-tripleo-heat-templates の Jinja2 構文を静的テンプレートセットにレンダリングします。process-templates.py スクリプトで openstack-tripleo-heat-templates コレクションのコピーをレンダリングするには、openstack-tripleo-heat-templates ディレクトリーに移動します。

$ cd /usr/share/openstack-tripleo-heat-templates

静的コピーを保存するカスタムディレクトリーを定義する -o オプションを指定して、tools ディレクトリーにある process-templates.py スクリプトを実行します。

$ ./tools/process-templates.py -o ~/openstack-tripleo-heat-templates-rendered

これにより、すべての Jinja2 テンプレートがレンタリング済みの YAML バージョンに変換され、結果が ~/openstack-tripleo-heat-templates-rendered に保存されます。

第4章 heat パラメーター

director テンプレートコレクション内の各 heat テンプレートには、parameters セクションがあります。このセクションには、特定のオーバークラウドサービス固有の全パラメーターの定義が含まれます。これには、以下のパラメーターが含まれます。

  • overcloud.j2.yaml: デフォルトのベースパラメーター
  • roles_data.yaml: コンポーザブルロールのデフォルトパラメーター
  • deployment/*.yaml: 特定のサービスのデフォルトパラメーター

これらのパラメーターの値は、以下の方法で変更することができます。

  1. カスタムパラメーター用の環境ファイルを作成します。
  2. その環境ファイルの parameter_defaults セクションにカスタムのパラメーターを追加します。
  3. openstack overcloud deploy コマンドでその環境ファイルを指定します。

4.1. 例 1: タイムゾーンの設定

タイムゾーンを設定するための Heat テンプレート (puppet/services/time/timezone.yaml) には TimeZone パラメーターが含まれています。TimeZone パラメーターの値を空白のままにすると、オーバークラウドはデフォルトで時刻を UTC に設定します。

タイムゾーンのリストを取得するには、timedatectl list-timezones コマンドを実行します。アジアのタイムゾーンを取得するコマンド例を以下に示します。

$ sudo timedatectl list-timezones|grep "Asia"

タイムゾーンを特定したら、環境ファイルの TimeZone パラメーターを設定します。以下に示す環境ファイルの例では、TimeZone の値を Asia/Tokyo に設定しています。

parameter_defaults:
  TimeZone: 'Asia/Tokyo'

4.2. 例 2: RabbitMQ ファイル記述子の上限の設定

特定の設定では、RabbitMQ サーバーのファイル記述子の上限を高くする必要がある場合があります。deployment/rabbitmq/rabbitmq-container-puppet.yaml の heat テンプレートを使用して RabbitFDLimit パラメーターで新しい制限を設定します。環境ファイルに以下のエントリーを追加します。

parameter_defaults:
  RabbitFDLimit: 65536

4.3. 例 3: パラメーターの有効化および無効化

デプロイメント時にパラメーターを初期設定し、それ以降のデプロイメント操作 (更新またはスケーリング操作など) ではそのパラメーターを無効にしなければならない場合があります。たとえば、オーバークラウドの作成時にカスタム RPM を含めるには、環境ファイルに以下のエントリーを追加します。

parameter_defaults:
  DeployArtifactURLs: ["http://www.example.com/myfile.rpm"]

それ以降のデプロイメントでこのパラメーターを無効にするには、パラメーターを削除するだけでは不十分です。削除するのではなく、パラメーターに空の値を設定する必要があります。

parameter_defaults:
  DeployArtifactURLs: []

これにより、それ以降のデプロイメント操作ではパラメーターは設定されなくなります。

4.4. 例 4: ロールベースのパラメーター

[ROLE]Parameters パラメーターを使用して特定のロールのパラメーターを設定します。ここで、[ROLE] はコンポーザブルロールに置き換えてください。

たとえば、director はコントローラーノードとコンピュートノードの両方に sshd を設定します。コントローラーノードとコンピュートノードに異なる sshd パラメーターを設定するには、ControllerParametersComputeParameters パラメーターの両方が含まれる環境ファイルを作成し、特定のロールごとに sshd パラメーターを設定します。

parameter_defaults:
  ControllerParameters:
    BannerText: "This is a Controller node"
  ComputeParameters:
    BannerText: "This is a Compute node"

4.5. 変更するパラメーターの特定

Red Hat OpenStack Platform director は、設定用のパラメーターを多数提供しています。場合によっては、設定する特定のオプションとそれに対応する director のパラメーターを特定するのが困難なことがあります。director を使用してオプションを設定するには、以下のワークフローに従ってオプションを確認し、特定のオーバークラウドパラメーターにマッピングしてください。

  1. 設定するオプションを特定します。そのオプションを使用するサービスを書き留めておきます。
  2. このオプションに対応する Puppet モジュールを確認します。Red Hat OpenStack Platform 用の Puppet モジュールは director ノードの /etc/puppet/modules にあります。各モジュールは、特定のサービスに対応しています。たとえば、keystone モジュールは OpenStack Identity (keystone) に対応しています。

    • 選択したオプションを制御する変数が Puppet モジュールに含まれている場合には、次のステップに進んでください。
    • 選択したオプションを制御する変数が Puppet モジュールに含まれていない場合には、そのオプションには hieradata は存在しません。可能な場合には、オーバークラウドがデプロイメントを完了した後でオプションを手動で設定することができます。
  3. コア heat テンプレートコレクションに hieradata 形式の Puppet 変数が含まれているかどうかを確認します。deployment/* は通常、同じサービスの Puppet モジュールに対応します。たとえば、deployment/keystone/keystone-container-puppet.yaml テンプレートは、keystone モジュールの hieradata を提供します。

    • heat テンプレートが Puppet 変数用の hieradata を設定している場合には、そのテンプレートは変更することのできる director ベースのパラメーターも開示する必要があります。
    • heat テンプレートが Puppet 変数用の hieradata を設定していない場合には、環境ファイルを使用して、設定フックにより hieradata を渡します。hieradata のカスタマイズに関する詳細は、「Puppet: ロール用 hieradata のカスタマイズ」 を参照してください。

手順

  1. OpenStack Identity (keystone) の通知の形式を変更するには、ワークフローを使用して、以下の手順を実施します。

    1. 設定する OpenStack パラメーターを特定します (notification_format)。
    2. keystone Puppet モジュールで notification_format の設定を検索します。

      $ grep notification_format /etc/puppet/modules/keystone/manifests/*

      この場合は、keystone モジュールは keystone::notification_format の変数を使用してこのオプションを管理します。

    3. keystone サービステンプレートでこの変数を検索します。

      $ grep "keystone::notification_format" /usr/share/openstack-tripleo-heat-templates/deployment/keystone/keystone-container-puppet.yaml

      このコマンドの出力には、director が KeystoneNotificationFormat パラメーターを使用して keystone::notification_format hieradata を設定していると表示されます。

最終的なマッピングは、以下の表のとおりです。

director のパラメーターPuppet hieradataOpenStack Identity (keystone) のオプション

KeystoneNotificationFormat

keystone::notification_format

notification_format

オーバークラウドの環境ファイルで KeystoneNotificationFormat を設定すると、オーバークラウドの設定中に keystone.conf ファイルの notification_format オプションが設定されます。

第5章 設定フック

設定フックを使用して、オーバークラウドのデプロイメントプロセスに独自のカスタム設定関数を挿入します。メインのオーバークラウドサービスの設定前後にカスタム設定を挿入するためのフックや、Puppet ベースの設定を変更/追加するためのフックを作成することができます。

5.1. 事前設定: 特定のオーバークラウドロールのカスタマイズ

オーバークラウドは、OpenStack コンポーネントのコア設定に Puppet を使用します。director の提供するフックのセットを使用して、コア設定を開始する前に特定のノードロールのカスタム設定を行うことができます。これらのフックには以下の設定が含まれます。

重要

本書の以前のバージョンでは、OS::TripleO::Tasks::*PreConfig リソースを使用してロールごとに事前設定フックを提供していました。heat テンプレートコレクションでは、これらのフックを特定の用途に使用する必要があるので、これらを個別の用途に使用すべきではありません。その代わりに、以下に概要を示す OS::TripleO::*ExtraConfigPre フックを使用してください。

OS::TripleO::ControllerExtraConfigPre
Puppet のコア設定前にコントローラーノードに適用される追加の設定
OS::TripleO::ComputeExtraConfigPre
Puppet のコア設定前にコンピュートノードに適用される追加の設定
OS::TripleO::CephStorageExtraConfigPre
Puppet のコア設定前に Ceph Storage ノードに適用される追加の設定
OS::TripleO::ObjectStorageExtraConfigPre
Puppet のコア設定前にオブジェクトストレージノードに適用される追加の設定
OS::TripleO::BlockStorageExtraConfigPre
Puppet のコア設定前に Block Storage ノードに適用される追加の設定
OS::TripleO::[ROLE]ExtraConfigPre
Puppet のコア設定前にカスタムノードに適用される追加の設定。[ROLE] をコンポーザブルロール名に置き換えてください。

以下の例では、特定ロールの全ノードの resolv.conf ファイルに変数のネームサーバーを追加します。

手順

  1. ノードの resolv.conf ファイルに変数のネームサーバーを書き込むスクリプトを実行するために、基本的な heat テンプレート ~/templates/nameserver.yaml を作成します。

    heat_template_version: 2014-10-16
    
    description: >
      Extra hostname configuration
    
    parameters:
      server:
        type: string
      nameserver_ip:
        type: string
      DeployIdentifier:
        type: string
    
    resources:
      CustomExtraConfigPre:
        type: OS::Heat::SoftwareConfig
        properties:
          group: script
          config:
            str_replace:
              template: |
                #!/bin/sh
                echo "nameserver _NAMESERVER_IP_" > /etc/resolv.conf
              params:
                _NAMESERVER_IP_: {get_param: nameserver_ip}
    
      CustomExtraDeploymentPre:
        type: OS::Heat::SoftwareDeployment
        properties:
          server: {get_param: server}
          config: {get_resource: CustomExtraConfigPre}
          actions: ['CREATE']
          input_values:
            deploy_identifier: {get_param: DeployIdentifier}
    
    outputs:
      deploy_stdout:
        description: Deployment reference, used to trigger pre-deploy on changes
        value: {get_attr: [CustomExtraDeploymentPre, deploy_stdout]}

    上記の例では、resources セクションには以下のパラメーターが含まれます。

    CustomExtraConfigPre
    ここでは、ソフトウェア設定を定義します。上記の例では、Bash スクリプト を定義し、heat が _NAMESERVER_IP_nameserver_ip パラメーターに保管された値に置き換えます。
    CustomExtraDeploymentPre

    この設定により、CustomExtraConfigPre リソースで定義したソフトウェア設定を実行します。以下の点に注意してください。

    • config パラメーターは CustomExtraConfigPre リソースを参照し、適用する設定を heat が理解できるようにします。
    • server パラメーターは、オーバークラウドノードのマッピングを取得します。これは親テンプレートにより提供されるパラメーターで、このフックのテンプレートには必須です。
    • actions パラメーターは、設定を適用するタイミングを定義します。上記の例では、オーバークラウドが作成または更新された時に設定を適用します。設定可能なアクションは CREATEUPDATEDELETESUSPEND、および RESUME です。
    • input_values では deploy_identifier というパラメーターを定義し、親テンプレートからの DeployIdentifier を格納します。このパラメーターにより、各デプロイメント更新のリソースにタイムスタンプが提供されます。これにより、これ以降のオーバークラウド更新時にリソースが再度適用されるようになります。
  2. heat テンプレートをロールベースのリソース種別として登録する環境ファイル (~/templates/pre_config.yaml) を作成します。たとえば、コントローラーノードだけに設定を適用するには、ControllerExtraConfigPre フックを使用します。

    resource_registry:
      OS::TripleO::ControllerExtraConfigPre: /home/stack/templates/nameserver.yaml
    
    parameter_defaults:
      nameserver_ip: 192.168.1.1
  3. その他の環境ファイルと共に環境ファイルをスタックに追加します。

    $ openstack overcloud deploy --templates \
        ...
        -e /home/stack/templates/pre_config.yaml \
        ...

    これにより、オーバークラウドの初回作成またはそれ以降の更新において、コア設定前にすべてのコントローラーノードに設定が適用されます。

重要

各リソースを登録することができるのは、1 つのフックにつき 1 つの heat テンプレートだけです。別の heat テンプレートに登録すると、使用する heat テンプレートがそのテンプレートに変わります。

5.2. 事前設定: 全オーバークラウドロールのカスタマイズ

オーバークラウドは、OpenStack コンポーネントのコア設定に Puppet を使用します。director の提供するフックを使用して、コア設定を開始する前にすべてのノード種別を設定することができます。

OS::TripleO::NodeExtraConfig
Puppet のコア設定前に全ノードロールに適用される追加の設定

以下の例では、各ノードの resolv.conf ファイルに変数のネームサーバーを追加します。

手順

  1. 各ノードの resolv.conf に変数のネームサーバーを追加するスクリプトを実行するために、まず基本的な heat テンプレート (~/templates/nameserver.yaml) を作成します。

    heat_template_version: 2014-10-16
    
    description: >
      Extra hostname configuration
    
    parameters:
      server:
        type: string
      nameserver_ip:
        type: string
      DeployIdentifier:
        type: string
    
    resources:
      CustomExtraConfigPre:
        type: OS::Heat::SoftwareConfig
        properties:
          group: script
          config:
            str_replace:
              template: |
                #!/bin/sh
                echo "nameserver _NAMESERVER_IP_" >> /etc/resolv.conf
              params:
                _NAMESERVER_IP_: {get_param: nameserver_ip}
    
      CustomExtraDeploymentPre:
        type: OS::Heat::SoftwareDeployment
        properties:
          server: {get_param: server}
          config: {get_resource: CustomExtraConfigPre}
          actions: ['CREATE']
          input_values:
            deploy_identifier: {get_param: DeployIdentifier}
    
    outputs:
      deploy_stdout:
        description: Deployment reference, used to trigger pre-deploy on changes
        value: {get_attr: [CustomExtraDeploymentPre, deploy_stdout]}

    上記の例では、resources セクションには以下のパラメーターが含まれます。

    CustomExtraConfigPre
    このパラメーターは、ソフトウェア設定を定義します。上記の例では、Bash スクリプト を定義し、heat が _NAMESERVER_IP_nameserver_ip パラメーターに保管された値に置き換えます。
    CustomExtraDeploymentPre

    このパラメーターにより、CustomExtraConfigPre リソースで定義したソフトウェア設定を実行します。以下の点に注意してください。

    • config パラメーターは CustomExtraConfigPre リソースを参照し、適用する設定を heat が理解できるようにします。
    • server パラメーターは、オーバークラウドノードのマッピングを取得します。これは親テンプレートにより提供されるパラメーターで、このフックのテンプレートには必須です。
    • actions パラメーターは、設定を適用するタイミングを定義します。上記の例では、オーバークラウドが作成または更新された時にのみ設定を適用します。設定可能なアクションは CREATEUPDATEDELETESUSPEND、および RESUME です。
    • input_values パラメーターでは deploy_identifier というサブパラメーターを定義し、親テンプレートからの DeployIdentifier を格納します。このパラメーターにより、各デプロイメント更新のリソースにタイムスタンプが提供されます。これにより、これ以降のオーバークラウド更新時にリソースが再度適用されるようになります。
  2. OS::TripleO::NodeExtraConfig リソース種別として heat テンプレートを登録する環境ファイル (~/templates/pre_config.yaml) を作成します。

    resource_registry:
      OS::TripleO::NodeExtraConfig: /home/stack/templates/nameserver.yaml
    
    parameter_defaults:
      nameserver_ip: 192.168.1.1
  3. その他の環境ファイルと共に環境ファイルをスタックに追加します。

    $ openstack overcloud deploy --templates \
        ...
        -e /home/stack/templates/pre_config.yaml \
        ...

    これにより、オーバークラウドの初回作成またはそれ以降の更新において、コア設定前にすべてのノードに設定が適用されます。

重要

OS::TripleO::NodeExtraConfig を登録することができるのは 1 つの heat テンプレートだけです。別の heat テンプレートに登録すると、使用する heat テンプレートがそのテンプレートに変わります。

5.3. 設定後: 全オーバークラウドロールのカスタマイズ

重要

本書の以前のバージョンでは、OS::TripleO::Tasks::*PostConfig リソースを使用してロールごとに設定後フックを提供していました。heat テンプレートコレクションでは、これらのフックを特定の用途に使用する必要があるので、これらを個別の用途に使用すべきではありません。その代わりに、以下に概要を示す OS::TripleO::NodeExtraConfigPost フックを使用してください。

オーバークラウドの初回作成時または更新時において、オーバークラウドの作成が完了してからすべてのロールに設定の追加が必要となる可能性があります。このような場合には、以下の設定後フックを使用します。

OS::TripleO::NodeExtraConfigPost
Puppet のコア設定後に全ノードロールに適用される追加の設定

以下の例では、各ノードの resolv.conf ファイルに変数のネームサーバーを追加します。

手順

  1. 各ノードの resolv.conf に変数のネームサーバーを追加するスクリプトを実行するために、まず基本的な heat テンプレート (~/templates/nameserver.yaml) を作成します。

    heat_template_version: 2014-10-16
    
    description: >
      Extra hostname configuration
    
    parameters:
      servers:
        type: json
      nameserver_ip:
        type: string
      DeployIdentifier:
        type: string
      EndpointMap:
        default: {}
        type: json
    
    resources:
      CustomExtraConfig:
        type: OS::Heat::SoftwareConfig
        properties:
          group: script
          config:
            str_replace:
              template: |
                #!/bin/sh
                echo "nameserver _NAMESERVER_IP_" >> /etc/resolv.conf
              params:
                _NAMESERVER_IP_: {get_param: nameserver_ip}
    
      CustomExtraDeployments:
        type: OS::Heat::SoftwareDeploymentGroup
        properties:
          servers:  {get_param: servers}
          config: {get_resource: CustomExtraConfig}
          actions: ['CREATE']
          input_values:
            deploy_identifier: {get_param: DeployIdentifier}

    上記の例では、resources セクションには以下のパラメーターが含まれます。

    CustomExtraConfig
    ここでは、ソフトウェア設定を定義します。上記の例では、Bash スクリプト を定義し、heat が _NAMESERVER_IP_nameserver_ip パラメーターに保管された値に置き換えます。
    CustomExtraDeployments

    この設定により、CustomExtraConfig リソースで定義したソフトウェア設定を実行します。以下の点に注意してください。

    • config パラメーターは CustomExtraConfig リソースを参照し、適用する設定を heat が理解できるようにします。
    • servers パラメーターは、オーバークラウドノードのマッピングを取得します。これは親テンプレートにより提供されるパラメーターで、このフックのテンプレートには必須です。
    • actions パラメーターは、設定を適用するタイミングを定義します。上記の例では、オーバークラウドが作成または更新された時に設定を適用します。設定可能なアクションは CREATEUPDATEDELETESUSPEND、および RESUME です。
    • input_values では deploy_identifier というパラメーターを定義し、親テンプレートからの DeployIdentifier を格納します。このパラメーターにより、各デプロイメント更新のリソースにタイムスタンプが提供されます。これにより、これ以降のオーバークラウド更新時にリソースが再度適用されるようになります。
  2. OS::TripleO::NodeExtraConfigPost: リソース種別として heat テンプレートを登録する環境ファイル (~/templates/post_config.yaml) を作成します。

    resource_registry:
      OS::TripleO::NodeExtraConfigPost: /home/stack/templates/nameserver.yaml
    
    parameter_defaults:
      nameserver_ip: 192.168.1.1
  3. その他の環境ファイルと共に環境ファイルをスタックに追加します。

    $ openstack overcloud deploy --templates \
        ...
        -e /home/stack/templates/post_config.yaml \
        ...

    これにより、オーバークラウドの初回作成またはそれ以降の更新において、コア設定の完了後にすべてのノードに設定が適用されます。

重要

OS::TripleO::NodeExtraConfigPost を登録することができるのは 1 つの heat テンプレートだけです。別の heat テンプレートに登録すると、使用する heat テンプレートがそのテンプレートに変わります。

5.4. Puppet: ロール用 hieradata のカスタマイズ

heat テンプレートコレクションにはパラメーターのセットが含まれ、これを使用して特定のノード種別に追加の設定を渡すことができます。これらのパラメーターでは、ノードの Puppet 設定用 hieradata として設定を保存します。

ControllerExtraConfig
すべてのコントローラーノードに追加する設定
ComputeExtraConfig
すべてのコンピュートノードに追加する設定
BlockStorageExtraConfig
すべての Block Storage ノードに追加する設定
ObjectStorageExtraConfig
すべてのオブジェクトストレージノードに追加する設定
CephStorageExtraConfig
すべての Ceph Storage ノードに追加する設定
[ROLE]ExtraConfig
コンポーザブルロールに追加する設定。[ROLE] をコンポーザブルロール名に置き換えてください。
ExtraConfig
すべてのノードに追加する設定

手順

  1. デプロイ後の設定プロセスに設定を追加するには、parameter_defaults セクションにこれらのパラメーターが記載された環境ファイルを作成します。たとえば、コンピュートホストに確保するメモリーを 1024 MB に増やし VNC キーマップを日本語に指定するには、ComputeExtraConfig パラメーターの以下のエントリーを使用します。

    parameter_defaults:
      ComputeExtraConfig:
        nova::compute::reserved_host_memory: 1024
        nova::compute::vnc_keymap: ja
  2. ご自分のデプロイメントに該当するその他の環境ファイルと共に、この環境ファイルを openstack overcloud deploy コマンドに追加します。
重要

それぞれのパラメーターを定義することができるのは 1 度だけです。さらに定義すると、以前の値が上書きされます。

5.5. Puppet: 個別のノードの hieradata のカスタマイズ

heat テンプレートコレクションを使用して、個別のノードの Puppet hieradata を設定することができます。

手順

  1. ノードのイントロスペクションデータからシステム UUID を特定します。

    $ openstack baremetal introspection data save 9dcc87ae-4c6d-4ede-81a5-9b20d7dc4a14 | jq .extra.system.product.uuid

    このコマンドは、システム UUID を返します。以下に例を示します。

    "f5055c6c-477f-47fb-afe5-95c6928c407f"
  2. ノード固有の hieradata を定義して per_node.yaml テンプレートを事前設定フックに登録する環境ファイルを作成します。NodeDataLookup パラメーターに、設定するノードのシステム UUID を指定します。

    resource_registry:
      OS::TripleO::ComputeExtraConfigPre: /usr/share/openstack-tripleo-heat-templates/puppet/extraconfig/pre_deploy/per_node.yaml
    parameter_defaults:
      NodeDataLookup: '{"f5055c6c-477f-47fb-afe5-95c6928c407f": {"nova::compute::vcpu_pin_set": [ "2", "3" ]}}'
  3. ご自分のデプロイメントに該当するその他の環境ファイルと共に、この環境ファイルを openstack overcloud deploy コマンドに追加します。

per_node.yaml テンプレートは、各システム UUID に対応するノード上に heiradata ファイルのセットを生成して、定義した hieradata を含めます。UUID が定義されていない場合には、生成される hieradata ファイルは空になります。上記の例では、per_node.yaml テンプレートは (OS::TripleO::ComputeExtraConfigPre フックに従って) 全コンピュートノード上で実行されますが、システム UUID が f5055c6c-477f-47fb-afe5-95c6928c407f のコンピュートノードのみが hieradata を受け取ります。

このメカニズムを使用して、特定の要件に応じて各ノードを個別に調整することができます。

5.6. Puppet: カスタムのマニフェストの適用

特定の状況では、追加のコンポーネントをオーバークラウドノードにインストールして設定する場合があります。そのためには、カスタムの Puppet マニフェストを使用して、主要な設定が完了してからノードに適用します。基本的な例として、各ノードに motd をインストールするケースを考えます。

手順

  1. Puppet 設定を起動する heat テンプレート ~/templates/custom_puppet_config.yaml を作成します。

    heat_template_version: 2014-10-16
    
    description: >
      Run Puppet extra configuration to set new MOTD
    
    parameters:
      servers:
        type: json
      DeployIdentifier:
        type: string
      EndpointMap:
        default: {}
        type: json
    
    resources:
      ExtraPuppetConfig:
        type: OS::Heat::SoftwareConfig
        properties:
          config: {get_file: motd.pp}
          group: puppet
          options:
            enable_hiera: True
            enable_facter: False
    
      ExtraPuppetDeployments:
        type: OS::Heat::SoftwareDeploymentGroup
        properties:
          config: {get_resource: ExtraPuppetConfig}
          servers: {get_param: servers}

    この例は、テンプレート内に /home/stack/templates/motd.pp を追加し、設定するノードに渡します。motd.pp ファイルには、motd のインストールと設定に必要な Puppet クラスが含まれています。

  2. OS::TripleO::NodeExtraConfigPost: リソース種別として heat テンプレートを登録する環境ファイル (~templates/puppet_post_config.yaml) を作成します。

    resource_registry:
      OS::TripleO::NodeExtraConfigPost: /home/stack/templates/custom_puppet_config.yaml
  3. ご自分のデプロイメントに該当するその他の環境ファイルと共に、この環境ファイルを openstack overcloud deploy コマンドに追加します。

    $ openstack overcloud deploy --templates \
        ...
        -e /home/stack/templates/puppet_post_config.yaml \
        ...

    これにより、motd.pp からの設定がオーバークラウド内の全ノードに適用されます。

第6章 director インストールの準備

director をインストールおよび設定するには、アンダークラウドを Red Hat Customer Portal または Red Hat Satellite サーバーに登録し、director パッケージをインストールし、インストール中にコンテナーイメージを取得するために director のコンテナーイメージソースを設定するなどの準備作業を完了する必要があります。

6.1. アンダークラウドの準備

director をインストールする前に、ホストマシンでいくつかの基本設定を完了する必要があります。

手順

  1. お使いのアンダークラウドに root ユーザーとしてログインします。
  2. stack ユーザーを作成します。

    [root@director ~]# useradd stack
  3. ユーザーのパスワードを設定します。

    [root@director ~]# passwd stack
  4. sudo を使用する場合にパスワードを要求されないようにします。

    [root@director ~]# echo "stack ALL=(root) NOPASSWD:ALL" | tee -a /etc/sudoers.d/stack
    [root@director ~]# chmod 0440 /etc/sudoers.d/stack
  5. 新規作成した stack ユーザーに切り替えます。

    [root@director ~]# su - stack
    [stack@director ~]$
  6. システムイメージおよび heat テンプレート用のディレクトリーを作成します。

    [stack@director ~]$ mkdir ~/images
    [stack@director ~]$ mkdir ~/templates

    director はシステムのイメージと heat テンプレートを使用して、オーバークラウド環境を構築します。ローカルファイルシステムの管理を容易にするために、Red Hat ではこれらのディレクトリーを作成することを推奨します。

  7. アンダークラウドのベースおよび完全なホスト名を確認します。

    [stack@director ~]$ hostname
    [stack@director ~]$ hostname -f

    上記のコマンドのいずれかで正しい完全修飾ホスト名が出力されない、またはエラーが表示される場合には、hostnamectl でホスト名を設定します。

    [stack@director ~]$ sudo hostnamectl set-hostname undercloud.example.com
  8. アンダークラウドホストの完全修飾ドメイン名 (FQDN) を解決できる DNS サーバーを使用していない場合は、/etc/hosts を編集してシステムホスト名のエントリーを追加します。/etc/hosts の IP アドレスは、アンダークラウドのパブリック API に使用する予定のアドレスと一致する必要があります。たとえば、システムの FQDN に undercloud.example.com が使用され、IP アドレスに 10.0.0.1 を使用する場合には、/etc/hosts ファイルに以下の行を追加します。

    10.0.0.1  undercloud.example.com undercloud
  9. Red Hat OpenStack Platform director をオーバークラウドまたはその認証プロバイダーとは別のドメインに配置する予定の場合には、追加のドメインを /etc/resolv.conf に加える必要があります。

    search overcloud.com idp.overcloud.com

6.2. アンダークラウドの登録およびサブスクリプションのアタッチ

director をインストールする前に、subscription-manager を実行し、アンダークラウドを登録して有効な Red Hat OpenStack Platform サブスクリプションをアタッチする必要があります。

手順

  1. アンダークラウドに stack ユーザーとしてログインします。
  2. Red Hat コンテンツ配信ネットワークまたは Red Hat Satellite のどちらかにシステムを登録します。たとえば、システムをコンテンツ配信ネットワークに登録するには、以下のコマンドを実行します。要求されたら、カスタマーポータルのユーザー名およびパスワードを入力します。

    [stack@director ~]$ sudo subscription-manager register
  3. Red Hat OpenStack Platform (RHOSP) director のエンタイトルメントプール ID を検索します。

    [stack@director ~]$ sudo subscription-manager list --available --all --matches="Red Hat OpenStack"
    Subscription Name:   Name of SKU
    Provides:            Red Hat Single Sign-On
                         Red Hat Enterprise Linux Workstation
                         Red Hat CloudForms
                         Red Hat OpenStack
                         Red Hat Software Collections (for RHEL Workstation)
                         Red Hat Virtualization
    SKU:                 SKU-Number
    Contract:            Contract-Number
    Pool ID:             Valid-Pool-Number-123456
    Provides Management: Yes
    Available:           1
    Suggested:           1
    Service Level:       Support-level
    Service Type:        Service-Type
    Subscription Type:   Sub-type
    Ends:                End-date
    System Type:         Physical
  4. Pool ID の値を特定して、Red Hat OpenStack Platform 17.0 のエンタイトルメントをアタッチします。

    [stack@director ~]$ sudo subscription-manager attach --pool=Valid-Pool-Number-123456
  5. アンダークラウドを Red Hat Enterprise Linux 9.0 にロックします。

    $ sudo subscription-manager release --set=9.0

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

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

手順

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

    [stack@director ~]$ sudo subscription-manager repos --disable=*
    [stack@director ~]$ sudo subscription-manager repos --enable=rhel-9-for-x86_64-baseos-eus-rpms --enable=rhel-9-for-x86_64-appstream-eus-rpms --enable=rhel-9-for-x86_64-highavailability-eus-rpms --enable=openstack-17-for-rhel-9-x86_64-rpms --enable=fast-datapath-for-rhel-9-x86_64-rpms

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

  3. システムで更新を実行して、ベースシステムパッケージを最新の状態にします。

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

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

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

手順

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

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

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

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

注記

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

手順

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

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

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

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

      注記

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

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

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

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

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

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

パラメーター説明

excludes

設定からイメージ名を除外する正規表現のリスト

includes

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

modify_append_tag

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

modify_only_with_labels

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

modify_role

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

modify_vars

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

push_destination

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

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

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

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

pull_source

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

set

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

tag_from_label

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

重要

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

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

キー説明

ceph_image

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

ceph_namespace

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

ceph_tag

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

ceph_alertmanager_image

ceph_alertmanager_namespace

ceph_alertmanager_tag

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

ceph_grafana_image

ceph_grafana_namespace

ceph_grafana_tag

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

ceph_node_exporter_image

ceph_node_exporter_namespace

ceph_node_exporter_tag

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

ceph_prometheus_image

ceph_prometheus_namespace

ceph_prometheus_tag

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

name_prefix

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

name_suffix

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

namespace

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

neutron_driver

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

tag

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

注記

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ContainerImageRegistryCredentials

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

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

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

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

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

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

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

ContainerImageRegistryLogin

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

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

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

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

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

6.9. イメージ準備エントリーの階層化

ContainerImagePrepare パラメーターの値は YAML リストです。したがって、複数のエントリーを指定することができます。

次の例は、17.0-hotfix のタグが付いた nova-api イメージ以外のすべてのイメージの最新版を director が使用する 2 つのエントリーを示しています。

parameter_defaults:
  ContainerImagePrepare:
  - tag_from_label: "{version}-{release}"
    push_destination: true
    excludes:
    - nova-api
    set:
      namespace: registry.redhat.io/rhosp-rhel9
      name_prefix: openstack-
      name_suffix: ''
      tag:17.0
  - push_destination: true
    includes:
    - nova-api
    set:
      namespace: registry.redhat.io/rhosp-rhel9
      tag: 17.0-hotfix

includes および excludes のパラメーターでは、各エントリーのイメージの絞り込みをコントロールするのに正規表現が使用されます。includes 設定と一致するイメージが、excludes と一致するイメージに優先します。一致するとみなされるためには、イメージ名に includes または excludes の正規表現の値が含まれている必要があります。

6.10. ベンダープラグインのデプロイ

一部のサードパーティーハードウェアをブロックストレージのバックエンドとして使用するには、ベンダープラグインをデプロイする必要があります。以下の例で、Dell EMC ハードウェアをブロックストレージのバックエンドとして使用するために、ベンダープラグインをデプロイする方法について説明します。

手順

  1. オーバークラウド用に新たなコンテナーイメージファイルを作成します。

    $ sudo openstack tripleo container image prepare default \
        --local-push-destination \
        --output-env-file containers-prepare-parameter-dellemc.yaml
  2. containers-prepare-parameter-dellemc.yaml ファイルを編集します。
  3. メインの Red Hat OpenStack Platform コンテナーイメージの設定に exclude パラメーターを追加します。このパラメーターを使用して、ベンダーコンテナーイメージで置き換えるコンテナーイメージを除外します。以下の例では、コンテナーイメージは cinder-volume イメージです。

    parameter_defaults:
      ContainerImagePrepare:
        - push_destination: true
          excludes:
      	   - cinder-volume
          set:
            namespace: registry.redhat.io/rhosp-rhel9
            name_prefix: openstack-
            name_suffix: ''
            tag: 16.2
            ...
          tag_from_label: "{version}-{release}"
  4. ContainerImagePrepare パラメーターに、ベンダープラグインの代替コンテナーイメージが含まれる新しい設定を追加します。

    parameter_defaults:
      ContainerImagePrepare:
        ...
        - push_destination: true
          includes:
            - cinder-volume
          set:
            namespace: registry.connect.redhat.com/dellemc
            name_prefix: openstack-
            name_suffix: -dellemc-rhosp16
            tag: 16.2-2
            ...
  5. ContainerImageRegistryCredentials パラメーターに registry.connect.redhat.com レジストリーの認証情報を追加します。

    parameter_defaults:
      ContainerImageRegistryCredentials:
        registry.redhat.io:
          [service account username]: [service account password]
        registry.connect.redhat.com:
          [service account username]: [service account password]
  6. containers-prepare-parameter-dellemc.yaml ファイルを保存します。
  7. openstack overcloud deploy などのデプロイメントコマンドに containers-prepare-parameter-dellemc.yaml ファイルを追加します。

    $ openstack overcloud deploy --templates
        ...
        -e containers-prepare-parameter-dellemc.yaml
        ...

    director がオーバークラウドをデプロイする際に、オーバークラウドは標準のコンテナーイメージの代わりにベンダーのコンテナーイメージを使用します。

    重要
    containers-prepare-parameter-dellemc.yaml ファイルは、オーバークラウドデプロイメント内の標準の containers-prepare-parameter.yaml ファイルを置き換えます。オーバークラウドのデプロイメントに、標準の containers-prepare-parameter.yaml ファイルを含めないでください。アンダークラウドのインストールおよび更新には、標準の containers-prepare-parameter.yaml ファイルを維持します。

6.11. Ceph Storage コンテナーイメージの除外

デフォルトのオーバークラウドロール設定では、デフォルトの Controller ロール、Compute ロール、および Ceph Storage ロールが使用されます。ただし、デフォルトのロール設定を使用して Ceph Storage ノードを持たないオーバークラウドをデプロイする場合、director は引き続き Ceph Storage コンテナーイメージを Red Hat コンテナーレジストリーからプルします。イメージがデフォルト設定の一部として含まれているためです。

オーバークラウドで Ceph Storage コンテナーが必要ない場合は、Red Hat コンテナーレジストリーから Ceph Storage コンテナーイメージをプルしないように director を設定することができます。

手順

  1. containers-prepare-parameter.yaml ファイルを編集し、Ceph Storage コンテナーを除外します。

    parameter_defaults:
      ContainerImagePrepare:
      - push_destination: true
        excludes:
          - ceph
          - prometheus
        set:
          …​

    excludes パラメーターは正規表現を使用して、ceph または prometheus 文字列を含むコンテナーイメージを除外します。

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

6.11.1. 準備プロセスにおけるイメージの変更

イメージの準備中にイメージを変更し、変更したそのイメージで直ちにオーバークラウドをデプロイすることが可能です。

注記

Red Hat OpenStack Platform (RHOSP) ディレクターは、Ceph コンテナーではなく、RHOSP コンテナーの準備中にイメージを変更することをサポートします。

イメージを変更するシナリオを以下に示します。

  • デプロイメント前にテスト中の修正でイメージが変更される、継続的インテグレーションのパイプラインの一部として。
  • ローカルの変更をテストおよび開発のためにデプロイしなければならない、開発ワークフローの一部として。
  • 変更をデプロイしなければならないが、イメージビルドパイプラインでは利用することができない場合。たとえば、プロプライエタリーアドオンの追加または緊急の修正など。

準備プロセス中にイメージを変更するには、変更する各イメージで Ansible ロールを呼び出します。ロールはソースイメージを取得して必要な変更を行い、その結果をタグ付けします。prepare コマンドでイメージを目的のレジストリーにプッシュし、変更したイメージを参照するように heat パラメーターを設定することができます。

Ansible ロール tripleo-modify-image は要求されたロールインターフェイスに従い、変更のユースケースに必要な処理を行います。ContainerImagePrepare パラメーターの変更固有のキーを使用して、変更をコントロールします。

  • modify_role では、変更する各イメージについて呼び出す Ansible ロールを指定します。
  • modify_append_tag は、ソースイメージタグの最後に文字列を追加します。これにより、そのイメージが変更されていることが明確になります。すでに push_destination レジストリーに変更されたイメージが含まれている場合には、このパラメーターを使用して変更を省略します。イメージを変更する場合には、必ず modify_append_tag を変更します。
  • modify_vars は、ロールに渡す Ansible 変数のディクショナリーです。

tripleo-modify-image ロールが処理するユースケースを選択するには、tasks_from 変数をそのロールで必要なファイルに設定します。

イメージを変更する ContainerImagePrepare エントリーを開発およびテストする場合には、イメージが想定どおりに変更されることを確認するために、追加のオプションを指定せずにイメージの準備コマンドを実行します。

sudo openstack tripleo container image prepare \
  -e ~/containers-prepare-parameter.yaml
重要

openstack tripleo container image prepare コマンドを使用するには、アンダークラウドに実行中の image-serve レジストリーが含まれている必要があります。したがって、image-serve レジストリーがインストールされないため、新しいアンダークラウドのインストール前にこのコマンドを実行することはできません。アンダークラウドが正常にインストールされた後に、このコマンドを実行することができます。

6.11.2. コンテナーイメージの既存パッケージの更新

注記

Red Hat OpenStack Platform (RHOSP) ディレクターは、Ceph コンテナーではなく、RHOSP コンテナーのコンテナーイメージ上の既存のパッケージの更新をサポートします。

手順

  • 以下の ContainerImagePrepare エントリーは、アンダークラウドホストの dnf リポジトリー設定を使用してコンテナーイメージのパッケージをすべて更新する例です。

    ContainerImagePrepare:
    - push_destination: true
      ...
      modify_role: tripleo-modify-image
      modify_append_tag: "-updated"
      modify_vars:
        tasks_from: yum_update.yml
        compare_host_packages: true
        yum_repos_dir_path: /etc/yum.repos.d
      ...

6.11.3. コンテナーイメージへの追加 RPM ファイルのインストール

RPM ファイルのディレクトリーをコンテナーイメージにインストールすることができます。この機能は、ホットフィックスやローカルパッケージビルドなど、パッケージリポジトリーからは入手できないパッケージのインストールに役立ちます。

注記

Red Hat OpenStack Platform (RHOSP) ディレクターは、Ceph コンテナーではなく、RHOSP コンテナーのコンテナーイメージへの追加の RPM ファイルのインストールをサポートします。

手順

  • 次の ContainerImagePrepare エントリーの例では、いくつかのホットフィックスパッケージを nova-compute イメージにのみインストールします。

    ContainerImagePrepare:
    - push_destination: true
      ...
      includes:
      - nova-compute
      modify_role: tripleo-modify-image
      modify_append_tag: "-hotfix"
      modify_vars:
        tasks_from: rpm_install.yml
        rpms_path: /home/stack/nova-hotfix-pkgs
      ...

6.11.4. カスタム Dockerfile を使用したコンテナーイメージの変更

Dockerfile を含むディレクトリーを指定して、必要な変更を加えることができます。tripleo-modify-image ロールを呼び出すと、ロールは Dockerfile.modified ファイルを生成し、これにより FROM ディレクティブが変更され新たな LABEL ディレクティブが追加されます。

注記

Red Hat OpenStack Platform (RHOSP) ディレクターは、Ceph コンテナーではなく、RHOSP コンテナー用のカスタム Dockerfile を使用したコンテナーイメージの変更をサポートします。

手順

  1. 以下の例では、nova-compute イメージでカスタム Dockerfile が実行されます。

    ContainerImagePrepare:
    - push_destination: true
      ...
      includes:
      - nova-compute
      modify_role: tripleo-modify-image
      modify_append_tag: "-hotfix"
      modify_vars:
        tasks_from: modify_image.yml
        modify_dir_path: /home/stack/nova-custom
      ...
  2. /home/stack/nova-custom/Dockerfile ファイルの例を以下に示します。USER root ディレクティブを実行した後は、元のイメージのデフォルトユーザーに戻す必要があります。

    FROM registry.redhat.io/rhosp-rhel9/openstack-nova-compute:latest
    
    USER "root"
    
    COPY customize.sh /tmp/
    RUN /tmp/customize.sh
    
    USER "nova"

6.11.5. コンテナーイメージ管理用 Satellite サーバーの準備

Red Hat Satellite 6 には、レジストリーの同期機能が備わっています。これにより、複数のイメージを Satellite Server にプルし、アプリケーションライフサイクルの一環として管理することができます。また、他のコンテナー対応システムも Satellite をレジストリーとして使うことができます。コンテナーイメージ管理についての詳細は、Red Hat Satellite 6 コンテンツ管理ガイドコンテナーイメージの管理 を参照してください。

以下の手順は、Red Hat Satellite 6 の hammer コマンドラインツールを使用した例を示しています。組織には、例として ACME という名称を使用しています。この組織は、実際に使用する Satellite 6 の組織に置き換えてください。

注記

この手順では、registry.redhat.io のコンテナーイメージにアクセスするために認証情報が必要です。Red Hat では、個人のユーザー認証情報を使用する代わりに、レジストリーサービスアカウントを作成し、それらの認証情報を使用して registry.redhat.io コンテンツにアクセスすることを推奨します。詳しくは、Red Hat コンテナーレジストリーの認証 を参照してください。

手順

  1. すべてのコンテナーイメージのリストを作成します。

    $ sudo podman search --limit 1000 "registry.redhat.io/rhosp-rhel9" --format="{{ .Name }}" | sort > satellite_images
    $ sudo podman search --limit 1000 "registry.redhat.io/rhceph" | grep rhceph-5-dashboard-rhel8
    $ sudo podman search --limit 1000 "registry.redhat.io/rhceph" | grep rhceph-5-rhel8
    $ sudo podman search --limit 1000 "registry.redhat.io/openshift" | grep ose-prometheus
    • Ceph をインストールして Ceph Dashboard を有効にする場合は、次の ose-prometheus コンテナーが必要です。

      registry.redhat.io/openshift4/ose-prometheus-node-exporter:v4.6
      registry.redhat.io/openshift4/ose-prometheus:v4.6
      registry.redhat.io/openshift4/ose-prometheus-alertmanager:v4.6
  2. Satellite 6 の hammer ツールがインストールされているシステムに satellite_images ファイルをコピーします。あるいは、Hammer CLI ガイド に記載の手順に従って、アンダークラウドに hammer ツールをインストールします。
  3. 以下の hammer コマンドを実行して、実際の Satellite 組織に新規製品 (OSP Containers) を作成します。

    $ hammer product create \
      --organization "ACME" \
      --name "OSP Containers"

    このカスタム製品に、イメージを保管します。

  4. satellite_images ファイルからオーバークラウドのコンテナーイメージを追加します。

    $ while read IMAGE; do \
      IMAGE_NAME=$(echo $IMAGE | cut -d"/" -f3 | sed "s/openstack-//g") ; \
      IMAGE_NOURL=$(echo $IMAGE | sed "s/registry.redhat.io\///g") ; \
      hammer repository create \
      --organization "ACME" \
      --product "OSP Containers" \
      --content-type docker \
      --url https://registry.redhat.io \
      --docker-upstream-name $IMAGE_NOURL \
      --upstream-username USERNAME \
      --upstream-password PASSWORD \
      --name $IMAGE_NAME ; done < satellite_images
  5. Ceph Storage コンテナーイメージを追加します。

    $ hammer repository create \
      --organization "ACME" \
      --product "OSP Containers" \
      --content-type docker \
      --url https://registry.redhat.io \
      --docker-upstream-name rhceph/rhceph-5-rhel8 \
      --upstream-username USERNAME \
      --upstream-password PASSWORD \
      --name rhceph-5-rhel8
    注記

    Ceph Dashboard をインストールする場合は、hammer repository create コマンドに --name rhceph-5-dashboard-rhel8 を含めます。

    $ hammer repository create \
      --organization "ACME" \
      --product "OSP Containers" \
      --content-type docker \
      --url https://registry.redhat.io \
      --docker-upstream-name rhceph/rhceph-5-dashboard-rhel8 \
      --upstream-username USERNAME \
      --upstream-password PASSWORD \
      --name rhceph-5-dashboard-rhel8
  6. コンテナーイメージを同期します。

    $ hammer product synchronize \
      --organization "ACME" \
      --name "OSP Containers"

    Satellite Server が同期を完了するまで待ちます。

    注記

    設定によっては、hammer から Satellite Server のユーザー名およびパスワードが要求される場合があります。設定ファイルを使用して自動的にログインするように hammer を設定することができます。詳しくは、Red Hat Satellite Hammer CLI ガイド認証 セクションを参照してください。

  7. お使いの Satellite 6 サーバーでコンテンツビューが使われている場合には、新たなバージョンのコンテンツビューを作成してイメージを反映し、アプリケーションライフサイクルの環境に従ってプロモートします。この作業は、アプリケーションライフサイクルをどのように設定するかに大きく依存します。たとえば、ライフサイクルに production という名称の環境があり、その環境でコンテナーイメージを利用可能にする場合には、コンテナーイメージを含むコンテンツビューを作成し、そのコンテンツビューを production 環境にプロモートします。詳しくは、Red Hat Satellite コンテンツ管理ガイドの コンテンツビューの管理 を参照してください。
  8. base イメージに使用可能なタグを確認します。

    $ hammer docker tag list --repository "base" \
      --organization "ACME" \
      --lifecycle-environment "production" \
      --product "OSP Containers"

    このコマンドにより、特定環境のコンテンツビューでの OpenStack Platform コンテナーイメージのタグが表示されます。

  9. アンダークラウドに戻り、Satellite サーバーをソースとして使用して、イメージを準備するデフォルトの環境ファイルを生成します。以下のサンプルコマンドを実行して環境ファイルを生成します。

    $ sudo openstack tripleo container image prepare default \
      --output-env-file containers-prepare-parameter.yaml
    • --output-env-file: 環境ファイルの名前です。このファイルには、アンダークラウド用コンテナーイメージを準備するためのパラメーターが含まれます。ここでは、ファイル名は containers-prepare-parameter.yaml です。
  10. containers-prepare-parameter.yaml ファイルを編集して以下のパラメーターを変更します。

    • push_destination: 選択したコンテナーイメージの管理手段に応じて、これを true または false に設定します。このパラメーターを false に設定すると、オーバークラウドノードはイメージを直接 Satellite からプルします。このパラメーターを true に設定すると、director はイメージを Satellite からアンダークラウドレジストリーにプルし、オーバークラウドはそのイメージをアンダークラウドレジストリーからプルします。
    • namespace: Satellite サーバー上のレジストリーの URL。
    • name_prefix: 接頭辞は Satellite 6 の命名規則に基づきます。これは、コンテンツビューを使用するかどうかによって異なります。

      • コンテンツビューを使用する場合、設定は [org]-[environment]-[content view]-[product]- です。例: acme-production-myosp16-osp_containers-
      • コンテンツビューを使用しない場合、設定は [org]-[product]- です。例: acme-osp_containers-
    • ceph_namespaceceph_imageceph_tag: Ceph Storage を使用する場合には、Ceph Storage コンテナーイメージの場所を定義するこれらの追加パラメーターを指定します。ceph_image に Satellite 固有の接頭辞が追加された点に注意してください。この接頭辞は、name_prefix オプションと同じ値です。

Satellite 固有のパラメーターが含まれる環境ファイルの例を、以下に示します。

parameter_defaults:
  ContainerImagePrepare:
  - push_destination: false
    set:
      ceph_image: acme-production-myosp16_1-osp_containers-rhceph-5
      ceph_namespace: satellite.example.com:5000
      ceph_tag: latest
      name_prefix: acme-production-myosp16_1-osp_containers-
      name_suffix: ''
      namespace: satellite.example.com:5000
      neutron_driver: null
      tag: '17.0'
      ...
注記

Red Hat SatelliteServer に保存されている特定のコンテナーイメージのバージョンを使用するには、tag のキーと値のペアを set ディクショナリー内の特定のバージョンに設定します。たとえば、17.0.2 イメージストリームを使用するには、set ディクショナリーに tag: 17.0.2 を設定します。

undercloud.conf 設定ファイルで containers-prepare-parameter.yaml 環境ファイルを定義する必要があります。定義しないと、アンダークラウドはデフォルト値を使用します。

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

第7章 アンダークラウドへの director のインストール

Director を設定してインストールするには、undercloud.conf ファイルに適切なパラメーターを設定し、undercloud installation コマンドを実行します。director をインストールしたら、ノードのプロビジョニング中に director がベアメタルノードへの書き込みに使用するオーバークラウドイメージをインポートします。

7.1. director の設定

director のインストールプロセスでは、director が stack ユーザーのホームディレクトリーから読み取る undercloud.conf 設定ファイルに、特定の設定が必要になります。設定のベースとするためにデフォルトのテンプレートをコピーするには、以下の手順を実施します。

手順

  1. デフォルトのテンプレートを stack ユーザーのホームディレクトリーにコピーします。

    [stack@director ~]$ cp \
      /usr/share/python-tripleoclient/undercloud.conf.sample \
      ~/undercloud.conf
  2. undercloud.conf ファイルを編集します。このファイルには、アンダークラウドを設定するための設定値が含まれています。パラメーターを省略したり、コメントアウトした場合には、アンダークラウドのインストールでデフォルト値が使用されます。

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

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

重要

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

デフォルト

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

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

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

  • 必要なすべてのコンテナーイメージのパラメーター
  • 必要なイメージの準備を実施する ContainerImagePrepare パラメーター。このパラメーターが含まれるファイルの名前は、通常 containers-prepare-parameter.yaml です。
container_insecure_registries
podman が使用するセキュアではないレジストリーのリスト。プライベートコンテナーレジストリー等の別のソースからイメージをプルする場合には、このパラメーターを使用します。多くの場合、podman は Red Hat Container Catalog または Satellite サーバー (アンダークラウドが Satellite に登録されている場合) のいずれかからコンテナーイメージをプルするための証明書を持ちます。
container_registry_mirror
設定により podman が使用するオプションの registry-mirror
custom_env_files
アンダークラウドのインストールに追加する新たな環境ファイル
deployment_user
アンダークラウドをインストールするユーザー。現在のデフォルトユーザー stack を使用する場合には、このパラメーターを未設定のままにします。
discovery_default_driver
自動的に登録されたノードのデフォルトドライバーを設定します。enable_node_discovery パラメーターを有効にし、enabled_hardware_types のリストにドライバーを含める必要があります。
enable_ironic; enable_ironic_inspector; enable_tempest; enable_validations
director で有効にするコアサービスを定義します。これらのパラメーターは true に設定されたままにします。
enable_node_discovery
introspection ramdisk を PXE ブートする不明なノードを自動的に登録します。新規ノードは、fake ドライバーをデフォルトとして使用しますが、discovery_default_driver を設定して上書きすることもできます。また、イントロスペクションルールを使用して、新しく登録したノードにドライバーの情報を指定することもできます。
enable_routed_networks
ルーティングされたコントロールプレーンネットワークのサポートを有効にするかどうかを定義します。
enabled_hardware_types
アンダークラウドで有効にするハードウェアタイプのリスト
generate_service_certificate
アンダークラウドのインストール時に SSL/TLS 証明書を生成するかどうかを定義します。これは undercloud_service_certificate パラメーターに使用します。アンダークラウドのインストールで、作成された証明書 /etc/pki/tls/certs/undercloud-[undercloud_public_vip].pem を保存します。certificate_generation_ca パラメーターで定義される CA はこの証明書に署名します。
heat_container_image
使用する heat コンテナーイメージの URL。未設定のままにします。
heat_native
heat-all を使用してホストベースのアンダークラウド設定を実行します。true のままにします。
hieradata_override
director に Puppet hieradata を設定するための hieradata オーバーライドファイルへのパス。これにより、サービスに対して undercloud.conf パラメーター以外のカスタム設定を行うことができます。設定すると、アンダークラウドのインストールでこのファイルが /etc/puppet/hieradata ディレクトリーにコピーされ、階層の最初のファイルに設定されます。この機能の使用についての詳細は、アンダークラウドへの hieradata の設定 を参照してください。
inspection_extras
イントロスペクション時に追加のハードウェアコレクションを有効化するかどうかを定義します。このパラメーターを使用するには、イントロスペクションイメージに python-hardware または python-hardware-detect パッケージが必要です。
inspection_interface
ノードのイントロスペクションに director が使用するブリッジ。これは、director の設定により作成されるカスタムのブリッジです。LOCAL_INTERFACE でこのブリッジをアタッチします。これは、デフォルトの br-ctlplane のままにします。
inspection_runbench
ノードイントロスペクション時に一連のベンチマークを実行します。ベンチマークを有効にするには、このパラメーターを true に設定します。このオプションは、登録ノードのハードウェアを検査する際にベンチマーク分析を実行する場合に必要です。
ipv6_address_mode

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

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

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

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

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

local_ip

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

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

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

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

注記

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

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

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

undercloud_admin_hostlocal_ip と同じ IP ネットワークにない場合は、アンダークラウド上の管理 API がリッスンするインターフェイスを設定する必要があります。デフォルトでは、管理 API は br-ctlplane インターフェイスでリッスンします。アンダークラウドネットワークインターフェイスの設定方法については、アンダークラウドネットワークインターフェイスの設定 を参照してください。

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

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

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

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

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

サブネット

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

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

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

重要

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

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

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

注記

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

dhcp_start、dhcp_end

オーバークラウドノードの DHCP 割り当て範囲 (開始アドレスと終了アドレス)。ノードを割り当てるのに十分な IP アドレスがこの範囲に含まれるようにします。サブネットに指定されていない場合、director は local_ipgatewayundercloud_admin_hostundercloud_public_host、および Inspection_iprange パラメーターに設定された値をサブネットの完全な IP 範囲から削除して、割り当てプールを決定します。

開始アドレスと終了アドレスのペアのリストを指定することで、アンダークラウドのコントロールプレーンのサブネットに非連続割り当てプールを設定することができます。または、dhcp_exclude オプションを使用して、IP アドレス範囲内の IP アドレスを除外することもできます。たとえば、次の設定は両方とも割り当てプール 172.20.0.100-172.20.0.150172.20.0.200-172.20.0.250 を作成します。

オプション 1

dhcp_start = 172.20.0.100,172.20.0.200
dhcp_end = 172.20.0.150,172.20.0.250

オプション 2

dhcp_start = 172.20.0.100
dhcp_end = 172.20.0.250
dhcp_exclude = 172.20.0.151-172.20.0.199

dhcp_exclude

DHCP 割り当て範囲で除外する IP アドレスたとえば、次の設定では、IP アドレス 172.20.0.105 と IP アドレス範囲 172.20.0.210-172.20.0.219 が除外されます。

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

実際の設定に応じて、これらのパラメーターの値を変更してください。完了したら、ファイルを保存します。

7.3. 環境ファイルを使用したアンダークラウドの設定

undercloud.conf ファイルを使用して、アンダークラウドの主要なパラメーターを設定します。heat パラメーターが含まれる環境ファイルを使用して、アンダークラウドの追加設定を行うこともできます。

手順

  1. /home/stack/templates/custom-undercloud-params.yaml という名前で環境ファイルを作成します。
  2. このファイルを編集して、必要な heat パラメーターを追加します。たとえば、特定の OpenStack Platform サービスのデバッグを有効にするには、custom-undercloud-params.yaml ファイルに以下のスニペットを追加します。

    parameter_defaults:
      Debug: True

    完了したら、このファイルを保存します。

  3. undercloud.conf ファイルを編集し、custom_env_files パラメーターまでスクロールします。作成した custom-undercloud-params.yaml 環境ファイルをポイントするようにパラメーターを編集します。

    custom_env_files = /home/stack/templates/custom-undercloud-params.yaml
    注記

    コンマ区切りリストを使用して、複数の環境ファイルを指定することができます。

アンダークラウドの次回インストールまたはアップグレード操作時に、この環境ファイルが director のインストールに追加されます。

7.4. アンダークラウド設定用の標準 heat パラメーター

以下の表には、アンダークラウド用のカスタム環境ファイルで設定する標準の heat パラメーターをまとめています。

パラメーター説明

AdminPassword

アンダークラウドの admin ユーザーのパスワードを設定します。

AdminEmail

アンダークラウドの admin ユーザーの電子メールアドレスを設定します。

Debug

デバッグモードを有効にします。

カスタム環境ファイルの parameter_defaults セクションで、これらのパラメーターを設定します。

parameter_defaults:
  Debug: True
  AdminPassword: "myp@ssw0rd!"
  AdminEmail: "admin@example.com"

7.5. アンダークラウドへの hieradata の設定

director に Puppet hieradata を設定して、サービスに対して利用可能な undercloud.conf パラメーター以外のカスタム設定を行うことができます。

手順

  1. hieradata オーバーライドファイルを作成します (例: /home/stack/hieradata.yaml)。
  2. カスタマイズした hieradata をファイルに追加します。たとえば、Compute (nova) サービスのパラメーター force_raw_images をデフォルト値の True から False に変更するには、以下のスニペットを追加します。

    nova::compute::force_raw_images: False

    設定するパラメーターに Puppet 実装がない場合には、以下の手段によりパラメーターを設定します。

    nova::config::nova_config:
      DEFAULT/<parameter_name>:
        value: <parameter_value>

    以下に例を示します。

    nova::config::nova_config:
      DEFAULT/network_allocate_retries:
        value: 20
      ironic/serial_console_state_timeout:
        value: 15
  3. undercloud.conf ファイルの hieradata_override パラメーターを、新しい /home/stack/hieradata.yaml ファイルのパスに設定します。

    hieradata_override = /home/stack/hieradata.yaml

7.6. IPv6 を使用してベアメタルをプロビジョニングするためのアンダークラウド設定

IPv6 ノードおよびインフラストラクチャーがある場合には、IPv4 ではなく IPv6 を使用するようにアンダークラウドおよびプロビジョニングネットワークを設定することができます。これにより、director は IPv6 ノードに Red Hat OpenStack Platform をプロビジョニングおよびデプロイすることができます。ただし、いくつかの考慮事項があります。

  • デュアルスタック IPv4/6 は利用できません。
  • tempest 検証が正しく動作しない可能性があります。
  • アップグレード時に IPv4 から IPv6 に移行することはできません。

undercloud.conf ファイルを変更して、Red Hat OpenStack Platform で IPv6 プロビジョニングを有効にします。

前提条件

手順

  1. undercloud.conf ファイルを開きます。
  2. IPv6 アドレスモードをステートレスまたはステートフルのいずれかに指定します。

    [DEFAULT]
    ipv6_address_mode = <address_mode>
    ...
    • NIC がサポートするモードに基づいて、<address_mode>dhcpv6-stateless または dhcpv6-stateful に置き換えます。
    注記

    ステートフルアドレスモードを使用する場合、ファームウェア、チェーンローダー、およびオペレーティングシステムは、DHCP サーバーが追跡する ID を生成するために異なるアルゴリズムを使用する場合があります。DHCPv6 は MAC によってアドレスを追跡せず、リクエスターからの ID 値が変更されても、MAC アドレスが同じままである場合、同じアドレスを提供しません。したがって、ステートフル DHCPv6 を使用する場合は、次の手順を実行してネットワークインターフェイスを設定する必要もあります。

  3. ステートフル DHCPv6 を使用するようにアンダークラウドを設定した場合は、ベアメタルノードに使用するネットワークインターフェイスを指定します。

    [DEFAULT]
    ipv6_address_mode = dhcpv6-stateful
    ironic_enabled_network_interfaces = neutron,flat
    ...
  4. ベアメタルノードのデフォルトのネットワークインターフェイスを設定します。

    [DEFAULT]
    ...
    ironic_default_network_interface = neutron
    ...
  5. アンダークラウドがプロビジョニングネットワーク上にルーターを作成するかどうかを指定します。

    [DEFAULT]
    ...
    enable_routed_networks: <true/false>
    ...
    • <true/false>true に置き換えて、ルーティングされたネットワークを有効にし、アンダークラウドがプロビジョニングネットワーク上にルーターを作成しないようにします。true の場合、データセンタールーターはルーターアドバタイズメントを提供する必要があります。
    • <true/false>false に置き換えて、ルーティングされたネットワークを無効にし、プロビジョニングネットワーク上にルーターを作成します。
  6. ローカル IP アドレス、および SSL/TLS を介した director Admin API および Public API エンドポイントの IP アドレスを設定します。

    [DEFAULT]
    ...
    local_ip = <ipv6_address>
    undercloud_admin_host = <ipv6_address>
    undercloud_public_host = <ipv6_address>
    ...
    • <ipv6_address> をアンダークラウドの IPv6 アドレスに置き換えます。
  7. オプション: director がインスタンスの管理に使用するプロビジョニングネットワークを設定します。

    [ctlplane-subnet]
    cidr = <ipv6_address>/<ipv6_prefix>
    ...
    • <ipv6_address> を、デフォルトのプロビジョニングネットワークを使用していないときにインスタンスの管理に使用するネットワークの IPv6 アドレスに置き換えます。
    • <ipv6_prefix> を、デフォルトのプロビジョニングネットワークを使用していないときにインスタンスの管理に使用するネットワークの IP アドレス接頭辞に置き換えます。
  8. プロビジョニングノードの DHCP 割り当て範囲を設定します。

    [ctlplane-subnet]
    cidr = <ipv6_address>/<ipv6_prefix>
    dhcp_start = <ipv6_address_dhcp_start>
    dhcp_end = <ipv6_address_dhcp_end>
    ...
    • <ipv6_address_dhcp_start> を、オーバークラウドノードに使用するネットワーク範囲の開始点の IPv6 アドレスに置き換えます。
    • <ipv6_address_dhcp_end> を、オーバークラウドノードに使用するネットワーク範囲の終わりの IPv6 アドレスに置き換えます。
  9. オプション: トラフィックを External ネットワークに転送するようにゲートウェイを設定します。

    [ctlplane-subnet]
    cidr = <ipv6_address>/<ipv6_prefix>
    dhcp_start = <ipv6_address_dhcp_start>
    dhcp_end = <ipv6_address_dhcp_end>
    gateway = <ipv6_gateway_address>
    ...
    • デフォルトゲートウェイを使用しない場合は、<ipv6_gateway_address> をゲートウェイの IPv6 アドレスに置き換えます。
  10. 検査プロセス中に使用する DHCP 範囲を設定します。

    [ctlplane-subnet]
    cidr = <ipv6_address>/<ipv6_prefix>
    dhcp_start = <ipv6_address_dhcp_start>
    dhcp_end = <ipv6_address_dhcp_end>
    gateway = <ipv6_gateway_address>
    inspection_iprange = <ipv6_address_inspection_start>,<ipv6_address_inspection_end>
    ...
    • <ipv6_address_inspection_start> を、検査プロセス中に使用するネットワーク範囲の開始点の IPv6 アドレスに置き換えます。
    • <ipv6_address_inspection_end> を、検査プロセス中に使用するネットワーク範囲の終わりの IPv6 アドレスに置き換えます。
    注記

    この範囲は、dhcp_startdhcp_end で定義された範囲と重複することはできませんが、同じ IP サブネット内になければなりません。

  11. サブネットの IPv6 ネームサーバーを設定します。

    [ctlplane-subnet]
    cidr = <ipv6_address>/<ipv6_prefix>
    dhcp_start = <ipv6_address_dhcp_start>
    dhcp_end = <ipv6_address_dhcp_end>
    gateway = <ipv6_gateway_address>
    inspection_iprange = <ipv6_address_inspection_start>,<ipv6_address_inspection_end>
    dns_nameservers = <ipv6_dns>
    • <ipv6_dns> をサブネットに固有の DNS ネームサーバーに置き換えます。

7.7. アンダークラウドネットワークインターフェイスの設定

特定のネットワーク機能を持つアンダークラウドをインストールするには、undercloud.conf ファイルにカスタムネットワーク設定を追加します。たとえば、一部のインターフェイスは DHCP を持ちません。このような場合は、アンダークラウドのインストールプロセス中に os-net-config が設定を適用できるように、undercloud.conf ファイルでこれらのインターフェイスの DHCP を無効にする必要があります。

手順

  1. アンダークラウドのホストにログインします。
  2. 新規ファイル undercloud-os-net-config.yaml を作成し、必要なネットワーク設定を追加します。

    詳細は、ネットワークインターフェイスのリファレンス を参照してください。

    以下に例を示します。

    network_config:
    - name: br-ctlplane
      type: ovs_bridge
      use_dhcp: false
      dns_servers: 192.168.122.1
      domain: lab.example.com
      ovs_extra:
      - "br-set-external-id br-ctlplane bridge-id br-ctlplane"
      addresses:
      - ip_netmask: 172.20.0.1/26
      members:
      - type: interface
        name: nic2

    特定のインターフェイスのネットワークボンディングを作成するには、次のサンプルを使用します。

    network_config:
    - name: br-ctlplane
      type: ovs_bridge
      use_dhcp: false
      dns_servers: 192.168.122.1
      domain: lab.example.com
      ovs_extra:
      - "br-set-external-id br-ctlplane bridge-id br-ctlplane"
      addresses:
      - ip_netmask: 172.20.0.1/26
      members:
      - name: bond-ctlplane
        type: linux_bond
        use_dhcp: false
        bonding_options: "mode=active-backup"
        mtu: 1500
        members:
        - type: interface
          name: nic2
        - type: interface
          name: nic3
  3. undercloud.conf ファイルの net_config_override パラメーターに、undercloud-os-net-config.yaml ファイルへのパスを追加します。

    [DEFAULT]
    ...
    net_config_override=undercloud-os-net-config.yaml
    ...
    注記

    director は、net_config_override パラメーターに追加するファイルをテンプレートとして使用し、/etc/os-net-config/config.yaml ファイルを生成します。os-net-config はテンプレートで定義するインターフェイスを管理するので、このファイルですべてのアンダークラウドネットワークインターフェイスのカスタマイズを実行する必要があります。

  4. アンダークラウドをインストールします。

検証

  • アンダークラウドのインストールが正常に完了したら、/etc/os-net-config/config.yaml ファイルに該当する設定が含まれていることを確認します。

    network_config:
    - name: br-ctlplane
      type: ovs_bridge
      use_dhcp: false
      dns_servers: 192.168.122.1
      domain: lab.example.com
      ovs_extra:
      - "br-set-external-id br-ctlplane bridge-id br-ctlplane"
      addresses:
      - ip_netmask: 172.20.0.1/26
      members:
      - type: interface
        name: nic2

7.8. director のインストール

director をインストールして基本的なインストール後タスクを行うには、以下の手順を実施します。

手順

  1. 以下のコマンドを実行して、アンダークラウドに director をインストールします。

    [stack@director ~]$ openstack undercloud install

    このコマンドにより、director の設定スクリプトが起動します。director により追加のパッケージがインストールされ、undercloud.conf の設定に応じてサービスが設定されます。このスクリプトは、完了までに数分かかります。

    スクリプトにより、2 つのファイルが生成されます。

    • /home/stack/tripleo-deploy/undercloud/tripleo-undercloud-passwords.yaml - director サービスのすべてのパスワードのリスト。
    • /home/stack/stackrc: director コマンドラインツールへアクセスできるようにする初期化変数セット
  2. このスクリプトは、全 OpenStack Platform サービスのコンテナーも自動的に起動します。以下のコマンドを使用して、有効になったコンテナーを確認することができます。

    [stack@director ~]$ sudo podman ps
  3. stack ユーザーを初期化してコマンドラインツールを使用するには、以下のコマンドを実行します。

    [stack@director ~]$ source ~/stackrc

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

    (undercloud) [stack@director ~]$

director のインストールが完了しました。これで、director コマンドラインツールが使用できるようになりました。

7.9. オーバークラウドノードのイメージの取得

director では、オーバークラウドのノードをプロビジョニングするのに、複数のディスクイメージが必要です。

  • イントロスペクションカーネルおよび ramdisk: PXE ブートでのベアメタルシステムのイントロスペクション用
  • デプロイメントカーネルおよび ramdisk: システムのプロビジョニングおよびデプロイメント用
  • オーバークラウドカーネル、ramdisk、完全なイメージで、director がノードのハードディスクに書き込むベースオーバークラウドシステムを形成しています。

必要なイメージを入手してインストールできます。他の Red Hat OpenStack Platform (RHOSP) サービスを実行したくない場合、またはサブスクリプションエンタイトルメントの 1 つを使用したくない場合は、basic イメージを取得してインストールし、ベア OS をプロビジョニングすることもできます。

7.9.1. オーバークラウドイメージのインストール

Red Hat OpenStack Platform (RHOSP) インストールには、director 用の overcloud-hardened-uefi-full.qcow2 オーバークラウドイメージを提供するパッケージが含まれています。このイメージは、デフォルトの CPU アーキテクチャー x86-64 でオーバークラウドをデプロイするために必要です。これらのイメージを director にインポートすると、イントロスペクションイメージも director PXE サーバーにインストールされます。

手順

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

    [stack@director ~]$ source ~/stackrc
  3. rhosp-director-images-uefi-x86_64 および rhosp-director-images-ipa-x86_64 パッケージをインストールします。

    (undercloud) [stack@director ~]$ sudo dnf install rhosp-director-images-uefi-x86_64 rhosp-director-images-ipa-x86_64
  4. stack ユーザーのホームディレクトリー /home/stack/imagesimages ディレクトリーを作成します。

    (undercloud) [stack@director ~]$ mkdir /home/stack/images

    ディレクトリーがすでに存在する場合は、この手順をスキップしてください。

  5. イメージアーカイブを images ディレクトリーにデプロイメントします。

    (undercloud) [stack@director ~]$ cd ~/images
    (undercloud) [stack@director images]$ for i in /usr/share/rhosp-director-images/ironic-python-agent-latest.tar /usr/share/rhosp-director-images/overcloud-hardened-uefi-full-latest.tar; do tar -xvf $i; done
  6. イメージを director にインポートします。

    (undercloud) [stack@director images]$ openstack overcloud image upload --image-path /home/stack/images/

    このコマンドは、イメージ形式を QCOW から RAW に変換し、イメージのアップロードの進行状況に関する詳細な更新を提供します。

  7. オーバークラウドのイメージが /var/lib/ironic/images/ にコピーされていることを確認します。

    (undercloud) [stack@director images]$ ls -l /var/lib/ironic/images/
    total 1955660
    -rw-r--r--. 1 root 42422 40442450944 Jan 29 11:59 overcloud-hardened-uefi-full.raw
  8. Director がイントロスペクション PXE イメージを /var/lib/ironic/httpboot にコピーしたことを確認します。

    (undercloud) [stack@director images]$ ls -l /var/lib/ironic/httpboot
    total 417296
    -rwxr-xr-x. 1 root  root    6639920 Jan 29 14:48 agent.kernel
    -rw-r--r--. 1 root  root  420656424 Jan 29 14:48 agent.ramdisk
    -rw-r--r--. 1 42422 42422       758 Jan 29 14:29 boot.ipxe
    -rw-r--r--. 1 42422 42422       488 Jan 29 14:16 inspector.ipxe

7.9.2. 最小限のオーバークラウドイメージ

overcloud-minimal イメージを使用すると、他の Red Hat OpenStack Platform (RHOSP) サービスを実行したり、サブスクリプションエンタイトメントを消費したりしたくないベア OS をプロビジョニングすることが可能です。

RHOSP のインストールには、director 用に次のオーバークラウドイメージを提供する overcloud-minimal パッケージが含まれています。

  • overcloud-minimal
  • overcloud-minimal-initrd
  • overcloud-minimal-vmlinuz

手順

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

    [stack@director ~]$ source ~/stackrc
  3. overcloud-minimal パッケージをインストールします。

    (undercloud) [stack@director ~]$ sudo dnf install rhosp-director-images-minimal
  4. イメージのアーカイブを、stack ユーザーのホームディレクトリー下の images ディレクトリー (/home/stack/images) にデプロイメントします。

    (undercloud) [stack@director ~]$ cd ~/images
    (undercloud) [stack@director images]$ tar xf /usr/share/rhosp-director-images/overcloud-minimal-latest-17.0.tar
  5. イメージを director にインポートします。

    (undercloud) [stack@director images]$ openstack overcloud image upload --image-path /home/stack/images/ --image-type os --os-image-name overcloud-minimal.qcow2

    このコマンドは、イメージのアップロードの進行状況に関する最新情報を提供します。

    Image "file:///var/lib/ironic/images/overcloud-minimal.vmlinuz" was copied.
    +---------------------------------------------------------+-------------------+----------+
    |                           Path                          |        Name       |   Size   |
    +---------------------------------------------------------+-------------------+----------+
    | file:///var/lib/ironic/images/overcloud-minimal.vmlinuz | overcloud-minimal | 11172880 |
    +---------------------------------------------------------+-------------------+----------+
    Image "file:///var/lib/ironic/images/overcloud-minimal.initrd" was copied.
    +--------------------------------------------------------+-------------------+----------+
    |                          Path                          |        Name       |   Size   |
    +--------------------------------------------------------+-------------------+----------+
    | file:///var/lib/ironic/images/overcloud-minimal.initrd | overcloud-minimal | 63575845 |
    +--------------------------------------------------------+-------------------+----------+
    Image "file:///var/lib/ironic/images/overcloud-minimal.raw" was copied.
    +-----------------------------------------------------+-------------------+------------+
    |                         Path                        |        Name       |    Size    |
    +-----------------------------------------------------+-------------------+------------+
    | file:///var/lib/ironic/images/overcloud-minimal.raw | overcloud-minimal | 2912878592 |
    +-----------------------------------------------------+-------------------+------------+

7.10. アンダークラウド設定の更新

新たな要件に合わせて、アンダークラウドの設定を変更する必要がある場合は、該当する設定ファイルを編集し、openstack undercloud install コマンドを再度実行して、インストール後のアンダークラウド設定に変更を加えることができます。

手順

  1. アンダークラウドの設定ファイルを変更します。以下の例では、undercloud.conf ファイルを編集して、有効なハードウェア種別のリストに idrac ハードウェア種別を追加しています。

    enabled_hardware_types = ipmi,redfish,idrac
  2. openstack undercloud install コマンドを実行し、新たな変更を反映させてアンダークラウドを更新します。

    [stack@director ~]$ openstack undercloud install

    コマンドの実行が完了するまで待ちます。

  3. stack ユーザーを初期化し、コマンドラインツールを使用します。

    [stack@director ~]$ source ~/stackrc

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

    (undercloud) [stack@director ~]$
  4. director が新しい設定を適用していることを確認します。この例では、有効なハードウェア種別のリストを確認しています。

    (undercloud) [stack@director ~]$ openstack baremetal driver list
    +---------------------+----------------------+
    | Supported driver(s) | Active host(s)       |
    +---------------------+----------------------+
    | idrac               | director.example.com |
    | ipmi                | director.example.com |
    | redfish             | director.example.com |
    +---------------------+----------------------+

アンダークラウドの再設定が完了しました。

7.11. アンダークラウドのコンテナーレジストリー

Red Hat Enterprise Linux 9.0 には、Docker Registry v2 をインストールするための docker-distribution パッケージが含まれなくなりました。互換性および同じ機能レベルを維持するために、director のインストールでは Apache Web サーバーおよび image-serve という仮想ホストが作成され、これによりレジストリーが提供されます。このレジストリーでも、SSL を無効にしたポート 8787/TCP が使用されます。Apache ベースのレジストリーはコンテナー化されていません。したがって、以下のコマンドを実行してレジストリーを再起動する必要があります。

$ sudo systemctl restart httpd

コンテナーレジストリーのログは、以下の場所に保存されます。

  • /var/log/httpd/image_serve_access.log
  • /var/log/httpd/image_serve_error.log.

イメージのコンテンツは、/var/lib/image-serve から提供されます。この場所では、レジストリー REST API のプル機能を実装するために、特定のディレクトリーレイアウトおよび apache 設定が使用されています。

Apache ベースのレジストリーでは、podman push コマンドも buildah push コマンドもサポートされません。つまり、従来の方法を使用してコンテナーイメージをプッシュすることはできません。デプロイ中にイメージを変更するには、ContainerImagePrepare パラメーターなどのコンテナー準備ワークフローを使用します。コンテナーイメージを管理するには、コンテナー管理コマンドを使用します。

openstack tripleo container image list
レジストリーに保存されているすべてのイメージをリスト表示します。
openstack tripleo container image show
レジストリーの特定イメージのメタデータを表示します。
openstack tripleo container image push
イメージをリモートレジストリーからアンダークラウドレジストリーにプッシュします。
openstack tripleo container image delete
レジストリーからイメージを削除します。

第8章 オーバークラウドのプランニング

以下の項で、Red Hat OpenStack Platform (RHOSP) 環境のさまざまな要素をプランニングする際のガイドラインを説明します。これには、ノードロールの定義、ネットワークトポロジーのプランニング、ストレージなどが含まれます。

重要

デプロイ後は、オーバークラウドノードの名前を変更しないでください。デプロイメント後にノードの名前を変更すると、インスタンスの管理に問題が生じます。

8.1. ノードロール

director には、オーバークラウドを作成するために、以下に示すデフォルトノード種別が含まれます。

コントローラー

環境を制御するための主要なサービスを提供します。これには、Dashboard (horizon)、認証 (keystone)、イメージストレージ (glance)、ネットワーク (neutron)、オーケストレーション (heat)、高可用性サービスが含まれます。高可用性に対応した実稼働レベルの環境の場合は、Red Hat OpenStack Platform (RHOSP) 環境にコントローラーノードが 3 台必要です。

注記

1 台のコントローラーノードで設定される環境は、実稼働用ではなくテスト目的にのみ使用してください。2 台のコントローラーノードまたは 4 台以上のコントローラーノードで設定される環境はサポートされません。

コンピュート
ハイパーバイザーとして機能し、環境内で仮想マシンを実行するのに必要な処理機能を持つ物理サーバー。基本的な RHOSP 環境には少なくとも 1 つのコンピュートノードが必要です。
Ceph Storage
Red Hat Ceph Storage を提供するホスト。Ceph Storage ホストはクラスターに追加され、クラスターをスケーリングします。このデプロイメントロールはオプションです。
Swift Storage
OpenStack Object Storage (swift) サービスに外部オブジェクトストレージを提供するホスト。このデプロイメントロールはオプションです。

以下の表には、オーバークラウドの設定例と各シナリオで使用するノード種別の定義をまとめています。

表8.1 各種シナリオに使用するノードデプロイメントロール

 

コントローラー

コンピュート

Ceph Storage

Swift Storage

合計

小規模のオーバークラウド

3

1

-

-

4

中規模のオーバークラウド

3

3

-

-

6

追加のオブジェクトストレージがある中規模のオーバークラウド

3

3

-

3

9

Ceph Storage クラスターがある中規模のオーバークラウド

3

3

3

-

9

さらに、個別のサービスをカスタムのロールに分割するかどうかを検討します。コンポーザブルロールのアーキテクチャーについての詳しい情報は、Director のインストールおよび使用方法コンポーザブルサービスとカスタムロール を参照してください。

表8.2 概念検証用デプロイメントに使用するノードデプロイメントロール

 

アンダークラウド

コントローラー

コンピュート

Ceph Storage

合計

概念実証

1

1

1

1

4

警告

Red Hat OpenStack Platform は、デー 2 操作中、稼働状態にある Ceph Storage クラスターを維持します。そのため、MON ノードまたはストレージノードの数が 3 未満のデプロイメントでは、一部のデー 2 操作 (Ceph Storage クラスターのアップグレードまたはマイナー更新等) を行うことができません。単一のコントローラーノードまたは単一の Ceph Storage ノードを使用している場合は、デー 2 操作に失敗します。

8.2. オーバークラウドネットワーク

ロールとサービスをマッピングして相互に正しく通信できるように、環境のネットワークトポロジーおよびサブネットのプランニングを行うことが重要です。Red Hat OpenStack Platform (RHOSP) では、自律的に動作してソフトウェアベースのネットワーク、静的/Floating IP アドレス、DHCP を管理する Openstack Networking (neutron) サービスを使用します。

デフォルトでは、director は接続に プロビジョニング/コントロールプレーン を使用するようにノードを設定します。ただし、ネットワークトラフィックを一連のコンポーザブルネットワークに分離し、カスタマイズしてサービスを割り当てることができます。

一般的な RHOSP のシステム環境では通常、ネットワーク種別の数は物理ネットワークのリンク数を超えます。全ネットワークを正しいホストに接続するために、オーバークラウドは VLAN タグ付けを使用して、それぞれのインターフェイスに複数のネットワークを提供します。ネットワークの多くは独立したサブネットですが、一部のネットワークには、インターネットアクセスまたはインフラストラクチャーにネットワーク接続ができるようにルーティングを提供するレイヤー 3 のゲートウェイが必要です。ネットワークトラフィックの種別を分離するのに VLAN を使用している場合には、802.1Q 標準をサポートするスイッチを使用してタグ付けされた VLAN を提供する必要があります。

注記

デプロイ時にトンネリングを無効にした neutron VLAN モードを使用する場合でも、プロジェクトネットワーク (GRE または VXLAN でトンネリング) をデプロイすることを推奨します。これには、デプロイ時にマイナーなカスタマイズを行う必要があり、将来ユーティリティーネットワークまたは仮想化ネットワークとしてトンネルネットワークを使用するためのオプションが利用可能な状態になります。VLAN を使用して Tenant ネットワークを作成することは変わりませんが、Tenant の VLAN を消費せずに特別な用途のネットワーク用に VXLAN トンネルを作成することも可能です。また、Tenant VLAN を使用するデプロイメントに VXLAN 機能を追加することは可能ですが、サービスを中断せずに Tenant VLAN を既存のオーバークラウドに追加することはできません。

director には、NIC を分離コンポーザブルネットワークと連携させるのに使用できるテンプレートセットも含まれています。デフォルトの設定は以下のとおりです。

  • シングル NIC 設定: ネイティブ VLAN 上のプロビジョニングネットワークと、オーバークラウドネットワークの種別ごとのサブネットを使用するタグ付けされた VLAN 用に NIC を 1 つ。
  • ボンディングされた NIC 設定: ネイティブ VLAN 上のプロビジョニングネットワーク用に NIC を 1 つと、オーバークラウドネットワークの種別ごとのタグ付けされた VLAN 用にボンディング設定の 2 つの NIC。
  • 複数 NIC 設定 - 各 NIC は、オーバークラウドネットワークの種別ごとのサブセットを使用します。

専用のテンプレートを作成して、特定の NIC 設定をマッピングすることもできます。

ネットワーク設定を検討する上で、以下の点を考慮することも重要です。

  • オーバークラウドの作成時には、全オーバークラウドマシンで 1 つの名前を使用して NIC を参照します。理想としては、混乱を避けるため、対象のネットワークごとに、各オーバークラウドノードで同じ NIC を使用してください。たとえば、プロビジョニングネットワークにはプライマリー NIC を使用して、OpenStack サービスにはセカンダリー NIC を使用します。
  • すべてのオーバークラウドシステムをプロビジョニング NIC から PXE ブートするように設定して、同システム上の外部 NIC およびその他の NIC の PXE ブートを無効にします。また、プロビジョニング NIC の PXE ブートは、ハードディスクや CD/DVD ドライブよりも優先されるように、ブート順序の最上位に指定するようにします。
  • director が各ノードの電源管理を制御できるように、すべてのオーバークラウドベアメタルシステムには、Intelligent Platform Management Interface (IPMI) などのサポート対象の電源管理インターフェイスが必要です。
  • 各オーバークラウドシステムの詳細 (プロビジョニング NIC の MAC アドレス、IPMI NIC の IP アドレス、IPMI ユーザー名、IPMI パスワード) をメモしてください。この情報は、後でオーバークラウドノードを設定する際に役立ちます。
  • 外部のインターネットからインスタンスにアクセス可能でなければならない場合、パブリックネットワークから Floating IP アドレスを確保して、その Floating IP アドレスをインスタンスに割り当てることができます。インスタンスはプライベートの IP アドレスを確保しますが、ネットワークトラフィックは NAT を使用して、Floating IP アドレスに到達します。Floating IP アドレスは、複数のプライベート IP アドレスではなく、単一のインスタンスにのみ割り当て可能である点に注意してください。ただし、Floating IP アドレスは、単一のテナントでのみ使用するように確保されます。したがって、そのテナントは必要に応じて Floating IP アドレスを特定のインスタンスに割り当てまたは割り当てを解除することができます。この設定では、お使いのインフラストラクチャーが外部のインターネットに公開されるので、適切なセキュリティー確保手段に従う必要があります。
  • あるブリッジのメンバーを単一のインターフェイスまたは単一のボンディングだけにすると、Open vSwitch でネットワークループが発生するリスクを緩和することができます。複数のボンディングまたはインターフェイスが必要な場合には、複数のブリッジを設定することが可能です。
  • Red Hat では、オーバークラウドノードが Red Hat コンテンツ配信ネットワークやネットワークタイムサーバーなどの外部のサービスに接続できるように、DNS によるホスト名解決を使用することを推奨します。
  • Red Hat では、プロビジョニングインターフェイス、外部インターフェイス、Floating IP インターフェイスの MTU はデフォルトの 1500 のままにしておくことを推奨します。変更すると、接続性の問題が発生する可能性があります。これは、ルーターが通常レイヤー 3 の境界を超えてジャンボフレームでのデータを転送できないためです。
注記

Red Hat Virtualization (RHV) を使用している場合には、オーバークラウドのコントロールプレーンを仮想化することができます。詳細は、Creating virtualized control planes を参照してください。

8.3. オーバークラウドのストレージ

オーバークラウド環境のバックエンドストレージとして Red Hat Ceph Storage ノードを使用できます。以下のタイプのストレージに Ceph ノードを使用するようにオーバークラウドを設定できます。

Images
Image サービス (glance) は、仮想マシンインスタンスの作成に使用されるイメージを管理します。イメージは不変のバイナリー BLOB です。Image サービスを使用して、イメージを Ceph Block Device に保存できます。サポートされるイメージ形式の詳細は、イメージの作成および管理Image サービス (glance) を参照してください。
Volumes
Block Storage サービス (cinder) は、インスタンスの永続ストレージボリュームを管理します。Block Storage サービスボリュームはブロックデバイスです。ボリュームを使用してインスタンスを起動したり、実行中のインスタンスにボリュームをアタッチしたりできます。Block Storage サービスを使用して、イメージの Copy-on-Write クローンで仮想マシンをブートすることができます。
オブジェクト
Ceph Object Gateway (RGW) は、オーバークラウドストレージのバックエンドが Red Hat Ceph Storage である場合、Ceph クラスターにデフォルトのオーバークラウドオブジェクトストレージを提供します。オーバークラウドに Red Hat Ceph Storage がない場合、オーバークラウドは Object Storage サービス (swift) を使用してオブジェクトストレージを提供します。オーバークラウドノードを Object Storage サービス専用にすることができます。これは、オーバークラウド環境でコントローラーノードをスケーリングまたは置き換える必要があるが、高可用性クラスター外にオブジェクトストレージを保持する必要がある場合に便利です。
ファイルシステム
Shared File Systems サービス (manila) は、共有ファイルシステムを管理します。Shared File Systems サービスを使用して、Ceph Storage ノード上のデータを使用して、CephFS ファイルシステムによってバックアップされた共有を管理できます。
インスタンスディスク
インスタンスを起動すると、インスタンスディスクはハイパーバイザーのインスタンスディレクトリーにファイルとして保存されます。デフォルトのファイルの場所は /var/lib/nova/instances です。

Ceph Storage についての詳しい情報は、Red Hat Ceph Storage アーキテクチャーガイド を参照してください。

8.3.1. オーバークラウドストレージノードの設定に関する考慮事項

インスタンスのセキュリティーとパフォーマンス
バックエンドの Block Storage ボリュームを使用するインスタンスで LVM を使用すると、パフォーマンス、ボリュームの可視性と可用性、およびデータの破損に関する問題が発生します。可視性、可用性、およびデータ破損の問題を軽減するには、LVM フィルターを使用します。詳細は、ストレージガイドオーバークラウドノードでの LVM2 フィルタリングの有効化 と Red Hat ナレッジベースのソリューション Cinder ボリュームで LVM を使用すると、コンピューティングホストにデータが公開される を参照してください。
ローカルディスクのパーティションサイズ

ストレージノードのストレージと保持の要件を考慮して、次のデフォルトのディスクパーティションサイズが要件を満たしているかどうかを判断します。

パーティションデフォルトのサイズ

/

8GB

/tmp

1 GB

/var/log

10 GB

/var/log/audit

2 GB

/home

1 GB

/var

他のすべてのパーティションが割り当てられた後、ディスクの残りのサイズが割り当てられます。

パーティションに割り当てられたディスクサイズを変更するには、overcloud-baremetal-deploy.yaml ノード定義ファイルの Ansible_playbooks 定義で追加の Ansible 変数 role_growvols_args を更新します。詳細は、オーバークラウド用のベアメタルノードのプロビジョニング を参照してください。

パーティションサイズの設定を最適化した後もパーティションがいっぱいになる場合は、次のいずれかのタスクを実行します。

8.4. オーバークラウドのセキュリティー

OpenStack Platform の実装のセキュリティーレベルは、お使いの環境のセキュリティーレベルと同等でしかありません。ネットワーク環境内の適切なセキュリティー原則に従って、ネットワークアクセスを正しく制御するようにします。

  • ネットワークのセグメント化を使用して、ネットワークトラフィックを軽減し、機密データを分離します。フラットなネットワークは、セキュリティーレベルがはるかに低くなります。
  • サービスアクセスとポートを最小限に制限します。
  • 適切なファイアウォールルールおよびパスワードの使用を徹底してください。
  • 必ず SELinux を有効にします。

システムのセキュリティー保護についての詳細は、以下の Red Hat ガイドを参照してください。

8.5. オーバークラウドの高可用性

高可用性なオーバークラウドをデプロイするために、director は複数のコントローラー、コンピュート、およびストレージノードを単一のクラスターとして連携するように設定します。ノードで障害が発生すると、障害が発生したノードのタイプに応じて、自動フェンシングおよび再起動プロセスがトリガーされます。オーバークラウドの高可用性アーキテクチャーおよびサービスに関する情報は、高可用性デプロイメントと使用方法 を参照してください。

注記

STONITH を使用しない高可用性オーバークラウドのデプロイはサポートの対象外です。高可用性オーバークラウドの Pacemaker クラスターの一部である各ノードには、STONITH デバイスを設定する必要があります。STONITH および Pacemaker の詳細は、Fencing in a Red Hat High Availability Cluster および Support Policies for RHEL High Availability Clusters - General Requirements for Fencing/STONITH を参照してください。

director を使用して、コンピュートインスタンスの高可用性 (インスタンス HA) を設定することもできます。この高可用性のメカニズムにより、ノードで障害が発生するとコンピュートノード上のインスタンスが自動的に退避および再起動されます。インスタンス HA に対する要件は通常のオーバークラウドの要件と同じですが、環境をデプロイメント用に準備するために追加のステップを実施する必要があります。インスタンス HA およびそのインストール手順についての情報は、コンピュートインスタンスの高可用性 を参照してください。

8.6. コントローラーノードの要件

コントローラーノードは、Red Hat OpenStack Platform 環境の中核となるサービス (例: Dashboard (horizon)、バックエンドのデータベースサーバー、Identity サービス (keystone) の認証、および高可用性サービスなど) をホストします。

プロセッサー
Intel 64 または AMD64 CPU 拡張機能をサポートする 64 ビット x86 プロセッサー。
メモリー

最小のメモリー容量は 32 GB です。ただし、推奨のメモリー容量は、仮想 CPU の数 (CPU コアの数をハイパースレッディングの値で乗算した数値に基づく) によって異なります。以下の計算により、RAM の要件を決定します。

  • コントローラーの最小メモリー容量の算出:

    • 各仮想 CPU ごとに 1.5 GB のメモリーを使用します。たとえば、仮想 CPU が 48 個あるマシンにはメモリーは 72 GB 必要です。
  • コントローラーの推奨メモリー容量の算出:

    • 各仮想 CPU ごとに 3 GB のメモリーを使用します。たとえば、仮想 CPU が 48 個あるマシンにはメモリーは 144 GB 必要です。

メモリーの要件に関する詳しい情報は、Red Hat カスタマーポータルで Red Hat OpenStack Platform Hardware Requirements for Highly Available Controllers を参照してください。

ディスクストレージとレイアウト

Object Storage サービス (swift) がコントローラーノード上で実行されていない場合には、最小で 50 GB のストレージが必要です。ただし、Telemetry および Object Storage サービスはいずれもコントローラーにインストールされ、ルートディスクを使用するように設定されます。これらのデフォルトは、市販のハードウェア上に構築される小型のオーバークラウドのデプロイに適しています。これらの環境は、概念検証およびテストの標準的な環境です。これらのデフォルトを使用すれば、最小限のプランニングでオーバークラウドをデプロイすることができますが、ワークロードキャパシティーとパフォーマンスの面ではあまり優れていません。

ただし、Telemetry が絶えずストレージにアクセスするため、エンタープライズ環境の場合、デフォルト設定では大きなボトルネックが生じる可能性があります。これにより、ディスク I/O が過度に使用されて、その他すべてのコントローラーサービスに深刻な影響をもたらします。このタイプの環境では、オーバークラウドのプランニングを行って、適切に設定する必要があります。

ネットワークインターフェイスカード
最小 2 枚の 1 Gbps ネットワークインターフェイスカード。タグ付けされた VLAN トラフィックを委譲する場合や、ボンディングインターフェイス向けには、追加のネットワークインターフェイスを使用します。
電源管理
各コントローラーノードには、Intelligent Platform Management Interface (IPMI) 機能などのサポート対象の電源管理インターフェイスがサーバーのマザーボードに搭載されている必要があります。
仮想化のサポート
Red Hat では、Red Hat Virtualization プラットフォーム上の仮想コントローラーノードのみをサポートします。詳細は、Creating virtualized control planes を参照してください。

8.7. コンピュートノードの要件

コンピュートノードは、仮想マシンインスタンスが起動した後にそれらを稼働させるロールを果たします。コンピュートノードには、ハードウェアの仮想化をサポートするベアメタルシステムが必要です。また、ホストする仮想マシンインスタンスの要件をサポートするのに十分なメモリーとディスク容量も必要です。

プロセッサー
Intel 64 または AMD64 CPU 拡張機能をサポートする 64 ビット x86 プロセッサーで、Intel VT または AMD-V のハードウェア仮想化拡張機能が有効化されている。このプロセッサーには最小でも 4 つのコアが搭載されていることを推奨しています。
メモリー

ホストオペレーティングシステム用に最低 6GB の RAM と、次の考慮事項に対応するための追加メモリー。

  • 仮想マシンインスタンスで使用できるようにするメモリーを追加します。
  • メモリーを追加して、追加のカーネルモジュール、仮想スイッチ、モニターソリューション、その他の追加のバックグラウンドタスクなど、ホスト上で特別な機能や追加のリソースを実行します。
  • Non-Uniform Memory Access (NUMA) を使用する場合、Red Hat は CPU ソケットノードあたり 8 GB、または 256 GB を超える物理 RAM がある場合はソケットノードあたり 16 GB を推奨します。
  • 少なくとも 4 GB のスワップスペースを設定します。
ディスク容量
最小 50 GB の空きディスク領域
ネットワークインターフェイスカード
最小 1 枚の 1 Gbps ネットワークインターフェイスカード (実稼働環境では最低でも NIC を 2 枚使用することを推奨)。タグ付けされた VLAN トラフィックを委譲する場合や、ボンディングインターフェイス向けには、追加のネットワークインターフェイスを使用します。
電源管理
各コンピュートノードには、Intelligent Platform Management Interface (IPMI) 機能などのサポート対象の電源管理インターフェイスがサーバーのマザーボードに搭載されている必要があります。

8.8. Red Hat Ceph Storage ノードの要件

director を使用して Ceph Storage クラスターを作成するには、追加のノード要件があります。

  • プロセッサー、メモリー、ネットワークインターフェイスカードの選択、ディスクレイアウトなどのハードウェア要件は、Red Hat Ceph Storage Hardware Guide で確認できます。
  • 各 Ceph Storage ノードにも、Intelligent Platform Management Interface (IPMI) 機能などのサポート対象の電源管理インターフェイスがサーバーのマザーボードに搭載されている必要があります。
  • 各 Ceph Storage ノードには、少なくとも 2 つのディスクが必要です。RHOSP director は cephadm を使用して Ceph Storage クラスターをデプロイします。cephadm 機能は、ノードのルートディスクへの Ceph OSD のインストールをサポートしていません。

8.9. Ceph Storage ノードと RHEL の互換性

RHOSP 17.0 は RHEL 9.0 でサポートされています。ただし、Ceph Storage ロールにマップされているホストは、最新のメジャー RHEL リリースに更新されます。アップグレードする前に、Red Hat ナレッジベースの記事 Red Hat Ceph Storage: Supported configurations を確認してください。

8.10. オブジェクトストレージノードの要件

オブジェクトストレージノードは、オーバークラウドのオブジェクトストレージ層を提供します。オブジェクトストレージプロキシーは、コントローラーノードにインストールされます。ストレージ層には、ノードごとに複数のディスクを持つベアメタルノードが必要です。

プロセッサー
Intel 64 または AMD64 CPU 拡張機能をサポートする 64 ビット x86 プロセッサー。
メモリー
メモリー要件はストレージ容量によって異なります。ハードディスク容量 1 TB あたり、最低でも 1 GB のメモリーを使用します。最適なパフォーマンスを得るには、ハードディスク容量 1 TB あたり 2 GB のメモリーを使用することを推奨します (特に、ワークロードが 100 GB に満たないファイルの場合)。
ディスク容量

ストレージ要件は、ワークロードに必要とされる容量により異なります。アカウントとコンテナーのデータを保存するには SSD ドライブを使用することを推奨します。アカウントおよびコンテナーデータとオブジェクトの容量比率は、約 1% です。たとえば、ハードドライブの容量 100 TB ごとに、アカウントおよびコンテナーデータの SSD 容量は 1 TB 用意するようにします。

ただし、これは保存したデータの種類により異なります。保存するオブジェクトの大半が小さい場合には、SSD の容量がさらに必要です。オブジェクトが大きい場合には (ビデオ、バックアップなど)、SSD の容量を減らします。

ディスクのレイアウト

推奨されるノード設定には、以下の例に示すようなディスクレイアウトが必要です。

  • /dev/sda: ルートディスク。director は、主なオーバークラウドイメージをディスクにコピーします。
  • /dev/sdb: アカウントデータに使用します。
  • /dev/sdc: コンテナーデータに使用します。
  • /dev/sdd 以降: オブジェクトサーバーディスク。ストレージ要件で必要な数のディスクを使用します。
ネットワークインターフェイスカード
最小 2 枚の 1 Gbps ネットワークインターフェイスカード。タグ付けされた VLAN トラフィックを委譲する場合や、ボンディングインターフェイス向けには、追加のネットワークインターフェイスを使用します。
電源管理
各コントローラーノードには、Intelligent Platform Management Interface (IPMI) 機能などのサポート対象の電源管理インターフェイスがサーバーのマザーボードに搭載されている必要があります。

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

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

警告

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

注記

RHOSP 17.0 は Satellite をサポートしていないため、Satellite リポジトリーはリストされていません。今後のリリースで Satellite がサポートされる予定です。パッケージリポジトリーおよびコンテナーレジストリーとしてサポートされるのは、Red Hat CDN のみです。RHOSP 17.0 は NFV をサポートしていないため、NFV リポジトリーはリストされていません。

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

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

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

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

rhel-9-for-x86_64-baseos-eus-rpms

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

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

rhel-9-for-x86_64-appstream-eus-rpms

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

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

rhel-9-for-x86_64-highavailability-eus-rpms

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

Red Hat OpenStack Platform 17 for RHEL 9 x86_64 (RPMs)

openstack-17-for-rhel-9-x86_64-rpms

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

Red Hat Fast Datapath for RHEL 9 (RPMS)

fast-datapath-for-rhel-9-x86_64-rpms

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

Red Hat Ceph Storage Tools 5 for RHEL 9 x86_64 (RPMs)

rhceph-5-tools-for-rhel-9-x86_64-rpms

Red Hat Enterprise Linux 9 での Red Hat Ceph Storage 5 用ツール

Compute ノードおよび ComputeHCI ノードのリポジトリー

以下の表に、オーバークラウド内の Compute ノードおよび ComputeHCI ノードのコアリポジトリーを示します。

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

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

rhel-9-for-x86_64-baseos-eus-rpms

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

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

rhel-9-for-x86_64-appstream-eus-rpms

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

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

rhel-9-for-x86_64-highavailability-eus-rpms

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

Red Hat OpenStack Platform 17 for RHEL 9 x86_64 (RPMs)

openstack-17-for-rhel-9-x86_64-rpms

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

Red Hat Fast Datapath for RHEL 9 (RPMS)

fast-datapath-for-rhel-9-x86_64-rpms

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

Red Hat Ceph Storage Tools 5 for RHEL 9 x86_64 (RPMs)

rhceph-5-tools-for-rhel-9-x86_64-rpms

Red Hat Enterprise Linux 9 での Red Hat Ceph Storage 5 用ツール

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

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

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

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

rhel-9-for-x86_64-rt-rpms

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

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

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

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

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

rhel-9-for-x86_64-baseos-rpms

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

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

rhel-9-for-x86_64-appstream-rpms

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

Red Hat OpenStack Platform 17 Director Deployment Tools for RHEL 9 x86_64 (RPMs)

openstack-17-deployment-tools-for-rhel-9-x86_64-rpms

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

Red Hat OpenStack Platform 17 for RHEL 9 x86_64 (RPMs)

openstack-17-for-rhel-9-x86_64-rpms

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

Red Hat Ceph Storage Tools 5 for RHEL 9 x86_64 (RPMs)

rhceph-5-tools-for-rhel-9-x86_64-rpms

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

Red Hat Fast Datapath for RHEL 9 (RPMS)

fast-datapath-for-rhel-9-x86_64-rpms

OpenStack Platform 用 Open vSwitch (OVS) パッケージを提供します。Ceph Storage ノードで OVS を使用している場合は、このリポジトリーをネットワークインターフェイス設定 (NIC) テンプレートに追加します。

8.12. ノードのプロビジョニングと設定

OpenStack Bare Metal (ironic) サービスまたは外部ツールを使用して、Red Hat OpenStack Platform (RHOSP) 環境のオーバークラウドノードをプロビジョニングします。ノードをプロビジョニングしたら、director を使用してノードを設定します。

OpenStack Bare Metal (ironic) サービスを使用したプロビジョニング
Bare Metal サービスを使用したオーバークラウドノードのプロビジョニングは、標準的なプロビジョニング方法です。詳細は、ベアメタルオーバークラウドノードのプロビジョニング を参照してください。
外部ツールを使用したプロビジョニング
Red Hat Satellite などの外部ツールを使用して、オーバークラウドノードをプロビジョニングできます。この方法は、電源管理制御を設定せずにオーバークラウドを作成する場合や、DHCP/PXE ブートの制限があるネットワークを使用する場合、あるいは overcloud-hardened-uefi-full.qcow2 イメージに依存しないカスタムのパーティションレイアウトを持つノードを使用する場合に便利です。このプロビジョニング方法は、ノードの管理に OpenStack Bare Metal サービス (ironic) を使用しません。詳細は、Configuring a basic overcloud with pre-provisioned nodes を参照してください。

第9章 コンポーザブルサービスとカスタムロール

オーバークラウドは、通常コントローラーノードやコンピュートノードなどの事前定義済みロールのノードと、異なる種別のストレージノードで設定されます。これらのデフォルトの各ロールには、director ノード上にあるコアの heat テンプレートコレクションで定義されているサービスセットが含まれます。ただし、特定のサービスのセットが含まれるカスタムロールを作成することもできます。

この柔軟性により、異なるロール上に異なるサービスの組み合わせを作成することができます。本章では、カスタムロールのアーキテクチャー、コンポーザブルサービス、およびそれらを使用する方法について説明します。

9.1. サポートされるロールアーキテクチャー

カスタムロールとコンポーザブルサービスを使用する場合には、以下のアーキテクチャーを使用することができます。

デフォルトアーキテクチャー
デフォルトの roles_data ファイルを使用します。すべての Controller サービスが単一の Controller ロールに含まれます。
サポートされるスタンドアロンのロール
/usr/share/openstack-tripleo-heat-templates/roles 内の事前定義済みファイルを使用して、カスタムの roles_data ファイルを生成します。詳細は、「サポートされるカスタムロール」 を参照してください。
カスタムコンポーザブルサービス
専用のロールを作成し、それらを使用してカスタムの roles_data ファイルを生成します。限られたコンポーザブルサービスの組み合わせしかテスト/検証されていない点に注意してください。Red Hat では、すべてのコンポーザブルサービスの組み合わせに対してサポートを提供することはできません。

9.2. Examining the roles_data file

roles_data ファイルには、director がノードにデプロイする YAML 形式のロールリストが含まれます。それぞれのロールには、そのロールを設定するすべてのサービスの定義が含まれます。以下のスニペット例を使用して、roles_data の構文を説明します。

- name: Controller
  description: |
    Controller role that has all the controller services loaded and handles
    Database, Messaging and Network functions.
  ServicesDefault:
    - OS::TripleO::Services::AuditD
    - OS::TripleO::Services::CACerts
    - OS::TripleO::Services::CephClient
    ...
- name: Compute
  description: |
    Basic Compute Node role
  ServicesDefault:
    - OS::TripleO::Services::AuditD
    - OS::TripleO::Services::CACerts
    - OS::TripleO::Services::CephClient
    ...

コア heat テンプレートコレクションには、デフォルトの roles_data ファイルが /usr/share/openstack-tripleo-heat-templates/roles_data.yaml に含まれています。デフォルトのファイルには、以下のロール種別の定義が含まれます。

  • Controller
  • Compute
  • BlockStorage
  • ObjectStorage
  • CephStorage

openstack overcloud deploy コマンドにより、デプロイ中にデフォルトの roles_data.yaml ファイルが追加されます。ただし、-r 引数を使用して、このファイルをカスタムの roles_data ファイルでオーバーライドすることができます。

$ openstack overcloud deploy --templates -r ~/templates/roles_data-custom.yaml

9.3. roles_data ファイルの作成

カスタムの roles_data ファイルは、手動で作成することができますが、個別のロールテンプレートを使用して自動生成することも可能です。director には openstack overcloud role generate コマンドがあり、複数の事前定義済みロールを結合し、カスタムの roles_data ファイルを自動生成します。

手順

  1. デフォルトロールのテンプレートをリスト表示します。

    $ openstack overcloud role list
    BlockStorage
    CephStorage
    Compute
    ComputeHCI
    ComputeOvsDpdk
    Controller
    ...
  2. ロール定義を表示します。

    $ openstack overcloud role show Compute
  3. Controller ロール、Compute ロール、および Networker ロールが含まれるカスタムの roles_data.yaml ファイルを生成します。

    $ openstack overcloud roles \
     generate -o <custom_role_file> \
     Controller Compute Networker
    • <custom_role_file> を、生成する新しいロールファイルの名前と場所 (/home/stack/templates/roles_data.yaml など) に置き換えます。

      注記

      Controller ロールおよび Networker ロールには、同じネットワークエージェントが含まれます。つまり、ネットワークサービスは Controller ロールから Networker ロールにスケーリングされ、オーバークラウドは Controller ノードと Networker ノード間にネットワークサービスの負荷のバランスを取ります。

      この Networker ロールをスタンドアロンにするには、独自のカスタム Controller ロールと、その他の必要なロールを作成することができます。これにより、独自のカスタムロールから roles_data.yaml ファイルを生成できるようになります。

  4. コア heat テンプレートコレクションから roles ディレクトリーを stack ユーザーのホームディレクトリーにコピーします。

    $ cp -r /usr/share/openstack-tripleo-heat-templates/roles/. /home/stack/templates/roles/
  5. このディレクトリー内でカスタムロールファイルを追加または変更します。このディレクトリーをカスタムロールのソースとして使用するには、ロールのサブコマンドに --roles-path オプションを指定します。

    $ openstack overcloud role \
     generate -o my_roles_data.yaml \
     --roles-path /home/stack/templates/roles \
     Controller Compute Networker

    このコマンドにより、~/roles ディレクトリー内の個々のロールから、単一の my_roles_data.yaml ファイルが生成されます。

注記

デフォルトのロールコレクションには、ControllerOpenstack ロールも含まれます。このロールには、NetworkerMessaging、および Database ロールのサービスは含まれません。ControllerOpenstack は、スタンドアロンの NetworkerMessagingDatabase ロールと組み合わせて使用することができます。

9.4. サポートされるカスタムロール

以下の表で、利用可能なカスタムロールについて説明します。カスタムロールテンプレートは、/usr/share/openstack-tripleo-heat-templates/roles ディレクトリーにあります。

ロール説明ファイル

BlockStorage

OpenStack Block Storage (cinder) ノード

BlockStorage.yaml

CephAll

完全なスタンドアロンの Ceph Storage ノード。OSD、MON、Object Gateway (RGW)、Object Operations (MDS)、Manager (MGR)、および RBD Mirroring が含まれます。

CephAll.yaml

CephFile

スタンドアロンのスケールアウト Ceph Storage ファイルロール。OSD および Object Operations (MDS) が含まれます。

CephFile.yaml

CephObject

スタンドアロンのスケールアウト Ceph Storage オブジェクトロール。OSD および Object Gateway (RGW) が含まれます。

CephObject.yaml

CephStorage

Ceph Storage OSD ノードロール

CephStorage.yaml

ComputeAlt

代替のコンピュートノードロール

ComputeAlt.yaml

ComputeDVR

DVR 対応のコンピュートノードロール

ComputeDVR.yaml

ComputeHCI

ハイパーコンバージドインフラストラクチャーを持つコンピュートノード。Compute および Ceph OSD サービスが含まれます。

ComputeHCI.yaml

ComputeInstanceHA

コンピュートインスタンス HA ノードロール。environments/compute-instanceha.yaml 環境ファイルと共に使用します。

ComputeInstanceHA.yaml

ComputeLiquidio

Cavium Liquidio Smart NIC を持つコンピュートノード

ComputeLiquidio.yaml

ComputeOvsDpdkRT

コンピュート OVS DPDK RealTime ロール

ComputeOvsDpdkRT.yaml

ComputeOvsDpdk

コンピュート OVS DPDK ロール

ComputeOvsDpdk.yaml

ComputeRealTime

リアルタイムのパフォーマンスに最適化された Compute ロール。このロールを使用する場合には、overcloud-realtime-compute イメージが利用可能で、ロール固有のパラメーター IsolCpusListNovaComputeCpuDedicatedSet、および NovaComputeCpuSharedSet がリアルタイムコンピュートノードのハードウェアに応じて設定されている必要があります。

ComputeRealTime.yaml

ComputeSriovRT

コンピュート SR-IOV RealTime ロール

ComputeSriovRT.yaml

ComputeSriov

コンピュート SR-IOV ロール

ComputeSriov.yaml

Compute

標準のコンピュートノードロール

Compute.yaml

ControllerAllNovaStandalone

データベース、メッセージング、ネットワーク設定、および OpenStack Compute (nova) コントロールコンポーネントを持たない Controller ロール。DatabaseMessagingNetworker、および Novacontrol ロールと組み合わせて使用します。

ControllerAllNovaStandalone.yaml

ControllerNoCeph

コア Controller サービスは組み込まれているが Ceph Storage (MON) コンポーネントを持たない Controller ロール。このロールはデータベース、メッセージング、およびネットワーク機能を処理しますが、Ceph Storage 機能は処理しません。

ControllerNoCeph.yaml

ControllerNovaStandalone

OpenStack Compute (nova) コントロールコンポーネントが含まれない Controller ロール。Novacontrol ロールと組み合わせて使用します。

ControllerNovaStandalone.yaml

ControllerOpenstack

データベース、メッセージング、およびネットワーク設定コンポーネントが含まれない Controller ロール。DatabaseMessaging、および Networker ロールと組み合わせて使用します。

ControllerOpenstack.yaml

ControllerStorageNfs

すべてのコアサービスが組み込まれ、Ceph NFS を使用する Controller ロール。このロールはデータベース、メッセージング、およびネットワーク機能を処理します。

ControllerStorageNfs.yaml

Controller

すべてのコアサービスが組み込まれた Controller ロール。このロールはデータベース、メッセージング、およびネットワーク機能を処理します。

Controller.yaml

ControllerSriov (ML2/OVN)

通常の Controller ロールと同じですが、OVN Metadata エージェントがデプロイされます。

ControllerSriov.yaml

データベース

スタンドアロンのデータベースロール。Pacemaker を使用して Galera クラスターとして管理されるデータベース。

Database.yaml

HciCephAll

ハイパーコンバージドインフラストラクチャーおよびすべての Ceph Storage サービスを持つコンピュートノード。OSD、MON、Object Gateway (RGW)、Object Operations (MDS)、Manager (MGR)、および RBD Mirroring が含まれます。

HciCephAll.yaml

HciCephFile

ハイパーコンバージドインフラストラクチャーおよび Ceph Storage ファイルサービスを持つコンピュートノード。OSD および Object Operations (MDS) が含まれます。

HciCephFile.yaml

HciCephMon

ハイパーコンバージドインフラストラクチャーおよび Ceph Storage ブロックサービスを持つコンピュートノード。OSD、MON、および Manager が含まれます。

HciCephMon.yaml

HciCephObject

ハイパーコンバージドインフラストラクチャーおよび Ceph Storage オブジェクトサービスを持つコンピュートノード。OSD および Object Gateway (RGW) が含まれます。

HciCephObject.yaml

IronicConductor

Ironic Conductor ノードロール

IronicConductor.yaml

Messaging

スタンドアロンのメッセージングロール。Pacemaker を使用して管理される RabbitMQ。

Messaging.yaml

Networker

スタンドアロンのネットワーク設定ロール。単独で OpenStack Networking (neutron) エージェントを実行します。デプロイメントで ML2/OVN メカニズムドライバーが使用される場合は、Deploying a Custom Role with ML2/OVN に記載の追加ステップを参照してください。

Networker.yaml

NetworkerSriov

通常の Networker ロールと同じですが、OVN Metadata エージェントがデプロイされます。Deploying a Custom Role with ML2/OVN に記載の追加ステップを参照してください。

NetworkerSriov.yaml

Novacontrol

スタンドアロンの nova-control ロール。単独で OpenStack Compute (nova) コントロールエージェントを実行します。

Novacontrol.yaml

ObjectStorage

Swift オブジェクトストレージノードロール

ObjectStorage.yaml

Telemetry

すべてのメトリックおよびアラームサービスを持つ Telemetry ロール

Telemetry.yaml

9.5. ロールパラメーターの考察

それぞれのロールには以下のパラメーターが含まれます。

name
(必須) 空白または特殊文字を含まないプレーンテキスト形式のロール名。選択した名前により、他のリソースとの競合が発生しないことを確認します。たとえば、Network の代わりに Networker を名前に使用します。
description
(オプション) プレーンテキスト形式のロールの説明
tags

(オプション) ロールのプロパティーを定義するタグの YAML リスト。このパラメーターを使用して controllerprimary タグの両方で、プライマリーロールを定義します。

- name: Controller
  ...
  tags:
    - primary
    - controller
  ...
重要

プライマリーロールをタグ付けしない場合には、最初に定義するロールがプライマリーロールになります。このロールが Controller ロールとなるようにしてください。

networks

ロール上で設定するネットワークの YAML リストまたはディクショナリー。YAML リストを使用する場合には、各コンポーザブルネットワークのリストを含めます。

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

ディクショナリーを使用する場合は、各ネットワークをコンポーザブルネットワークの特定の subnet にマッピングします。

  networks:
    External:
      subnet: external_subnet
    InternalApi:
      subnet: internal_api_subnet
    Storage:
      subnet: storage_subnet
    StorageMgmt:
      subnet: storage_mgmt_subnet
    Tenant:
      subnet: tenant_subnet

デフォルトのネットワークには、ExternalInternalApiStorageStorageMgmtTenantManagement が含まれます。

CountDefault
(任意) このロールにデプロイするデフォルトのノード数を定義します。
HostnameFormatDefault

(任意) このロールに対するホスト名のデフォルトの形式を定義します。デフォルトの命名規則では、以下の形式が使用されます。

[STACK NAME]-[ROLE NAME]-[NODE ID]

たとえば、コントローラーノード名はデフォルトで以下のように命名されます。

overcloud-controller-0
overcloud-controller-1
overcloud-controller-2
...
disable_constraints
(任意) director によるデプロイ時に OpenStack Compute (nova) および OpenStack Image Storage (glance) の制約を無効にするかどうかを定義します。事前にプロビジョニングされたノードでオーバークラウドをデプロイする場合に、このパラメーターを使用します。詳細は、director のインストールと使用方法事前にプロビジョニングされたノードを使用した基本的なオーバークラウドの設定 を参照してください。
update_serial

(任意) OpenStack の更新オプション時に同時に更新するノードの数を定義します。roles_data.yaml ファイルのデフォルト設定は以下のとおりです。

  • コントローラー、オブジェクトストレージ、および Ceph Storage ノードのデフォルトは 1 です。
  • コンピュートおよび Block Storage ノードのデフォルトは 25 です。

このパラメーターをカスタムロールから省いた場合のデフォルトは 1 です。

ServicesDefault
(任意) ノード上で追加するデフォルトのサービスリストを定義します。詳細は、「コンポーザブルサービスアーキテクチャーの考察」 を参照してください。

これらのパラメーターを使用して、新規ロールを作成すると共にロールに追加するサービスを定義することができます。

openstack overcloud deploy コマンドは、roles_data ファイルのパラメーターをいくつかの Jinja2 ベースのテンプレートに統合します。たとえば、特定の時点で overcloud.j2.yaml heat テンプレートは roles_data.yaml のロールのリストを繰り返し適用し、対応する各ロール固有のパラメーターとリソースを作成します。

たとえば、overcloud.j2.yaml heat テンプレートの各ロールのリソース定義は、以下のスニペットのようになります。

  {{role.name}}:
    type: OS::Heat::ResourceGroup
    depends_on: Networks
    properties:
      count: {get_param: {{role.name}}Count}
      removal_policies: {get_param: {{role.name}}RemovalPolicies}
      resource_def:
        type: OS::TripleO::{{role.name}}
        properties:
          CloudDomain: {get_param: CloudDomain}
          ServiceNetMap: {get_attr: [ServiceNetMap, service_net_map]}
          EndpointMap: {get_attr: [EndpointMap, endpoint_map]}
...

このスニペットには、Jinja2 ベースのテンプレートが {{role.name}} の変数を組み込み、各ロール名を OS::Heat::ResourceGroup リソースとして定義しているのが示されています。これは、次に roles_data ファイルのそれぞれの name パラメーターを使用して、対応する各 OS::Heat::ResourceGroup リソースを命名します。

9.6. 新規ロールの作成

コンポーザブルサービスアーキテクチャーを使用して、デプロイメントの要件に従ってベアメタルノードにロールを割り当てることができます。たとえば、OpenStack Dashboard (horizon) だけをホストする新しい Horizon ロールを作成するケースを考えます。

手順

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

    [stack@director ~]$ source ~/stackrc
  3. コア heat テンプレートコレクションから roles ディレクトリーを stack ユーザーのホームディレクトリーにコピーします。

    $ cp -r /usr/share/openstack-tripleo-heat-templates/roles/. /home/stack/templates/roles/
  4. home/stack/templates/rolesHorizon.yaml という名前の新規のファイルを作成します。
  5. 以下の設定を Horizon.yaml に追加して、ベースおよびコアの OpenStack Dashboard サービスが含まれる新しい Horizon ロールを作成します。

    - name: Horizon 1
      CountDefault: 1 2
      HostnameFormatDefault: '%stackname%-horizon-%index%'
      ServicesDefault:
        - OS::TripleO::Services::CACerts
        - OS::TripleO::Services::Kernel
        - OS::TripleO::Services::Ntp
        - OS::TripleO::Services::Snmp
        - OS::TripleO::Services::Sshd
        - OS::TripleO::Services::Timezone
        - OS::TripleO::Services::TripleoPackages
        - OS::TripleO::Services::TripleoFirewall
        - OS::TripleO::Services::SensuClient
        - OS::TripleO::Services::FluentdClient
        - OS::TripleO::Services::AuditD
        - OS::TripleO::Services::Collectd
        - OS::TripleO::Services::MySQLClient
        - OS::TripleO::Services::Apache
        - OS::TripleO::Services::Horizon
    1
    name パラメーターをカスタムロールの名前に設定します。カスタムロール名の最大長は 47 文字です。
    2
    CountDefault パラメーターを 1 に設定して、デフォルトのオーバークラウドに常に Horizon ノードが含まれるようにすると良いでしょう。
  6. (オプション) 既存のオーバークラウド内でサービスをスケーリングする場合は、既存のサービスを Controller ロール上に保持します。新規オーバークラウドを作成して、OpenStack Dashboard がスタンドアロンのロールに残るようにするには、Controller ロールの定義から OpenStack Dashboard コンポーネントを削除します。

    - name: Controller
      CountDefault: 1
      ServicesDefault:
        ...
        - OS::TripleO::Services::GnocchiMetricd
        - OS::TripleO::Services::GnocchiStatsd
        - OS::TripleO::Services::HAproxy
        - OS::TripleO::Services::HeatApi
        - OS::TripleO::Services::HeatApiCfn
        - OS::TripleO::Services::HeatApiCloudwatch
        - OS::TripleO::Services::HeatEngine
        # - OS::TripleO::Services::Horizon          # Remove this service
        - OS::TripleO::Services::IronicApi
        - OS::TripleO::Services::IronicConductor
        - OS::TripleO::Services::Iscsid
        - OS::TripleO::Services::Keepalived
        ...
  7. ControllerCompute、および Horizon のロールを含む、roles_data_horizon.yaml という名前の新しいロールデータファイルを生成します。

    (undercloud)$ openstack overcloud roles \
     generate -o /home/stack/templates/roles_data_horizon.yaml \
     --roles-path /home/stack/templates/roles \
     Controller Compute Horizon
  8. オプション: overcloud-baremetal-deploy.yaml ノード定義ファイルを編集して、Horizon ノードの配置を設定します。

    - name: Controller
      count: 3
      instances:
      - hostname: overcloud-controller-0
        name: node00
      ...
    - name: Compute
      count: 3
      instances:
      - hostname: overcloud-novacompute-0
        name: node04
      ...
    - name: Horizon
      count: 1
      instances:
      - hostname: overcloud-horizon-0
        name: node07

9.7. ガイドラインおよび制限事項

コンポーザブルロールのアーキテクチャーには、以下のガイドラインおよび制限事項があることに注意してください。

Pacemaker により管理されないサービスの場合:

  • スタンドアロンのカスタムロールにサービスを割り当てることができます。
  • 初回のデプロイメント後に追加のカスタムロールを作成してそれらをデプロイし、既存のサービスをスケーリングすることができます。

Pacemaker により管理されるサービスの場合:

  • スタンドアロンのカスタムロールに Pacemaker のマネージドサービスを割り当てることができます。
  • Pacemaker のノード数の上限は 16 です。Pacemaker サービス (OS::TripleO::Services::Pacemaker) を 16 のノードに割り当てた場合には、それ以降のノードは、代わりに Pacemaker Remote サービス (OS::TripleO::Services::PacemakerRemote) を使用する必要があります。同じロールで Pacemaker サービスと Pacemaker Remote サービスを割り当てることはできません。
  • Pacemaker のマネージドサービスが割り当てられていないロールには、Pacemaker サービス (OS::TripleO::Services::Pacemaker) を追加しないでください。
  • OS::TripleO::Services::Pacemaker または OS::TripleO::Services::PacemakerRemote のサービスが含まれているカスタムロールはスケールアップまたはスケールダウンできません。

一般的な制限事項

  • メジャーバージョン間のアップグレードプロセス中にカスタムロールとコンポーザブルサービスを変更することはできません。
  • オーバクラウドのデプロイ後には、ロールのサービスリストを変更することはできません。オーバークラウドのデプロイ後にサービスリストを変更すると、デプロイでエラーが発生して、ノード上に孤立したサービスが残ってしまう可能性があります。

9.8. コンポーザブルサービスアーキテクチャーの考察

コア heat テンプレートコレクションには、コンポーザブルサービスのテンプレートセットが 2 つ含まれています。

  • deployment には、主要な OpenStack サービスのテンプレートが含まれます。
  • puppet/services には、コンポーザブルサービスを設定するためのレガシーテンプレートが含まれます。互換性を維持するために、一部のコンポーザブルサービスは、このディレクトリーからのテンプレートを使用する場合があります。多くの場合、コンポーザブルサービスは deployment ディレクトリーのテンプレートを使用します。

各テンプレートには目的を特定する記述が含まれています。たとえば、deployment/time/ntp-baremetal-puppet.yaml サービステンプレートには以下のような記述が含まれます。

description: >
  NTP service deployment using puppet, this YAML file
  creates the interface between the HOT template
  and the puppet manifest that actually installs
  and configure NTP.

これらのサービステンプレートは、Red Hat OpenStack Platform デプロイメント固有のリソースとして登録されます。これは、overcloud-resource-registry-puppet.j2.yaml ファイルで定義されている一意な heat リソース名前空間を使用して、各リソースを呼び出すことができることを意味します。サービスはすべて、リソース種別に OS::TripleO::Services 名前空間を使用します。

一部のリソースは、直接コンポーザブルサービスのベーステンプレートを使用します。

resource_registry:
  ...
  OS::TripleO::Services::Ntp: deployment/time/ntp-baremetal-puppet.yaml
  ...

ただし、コアサービスにはコンテナーが必要なので、コンテナー化されたサービステンプレートを使用します。たとえば、コンテナー化された keystone サービスでは、以下のリソースを使用します。

resource_registry:
  ...
  OS::TripleO::Services::Keystone: deployment/keystone/keystone-container-puppet.yaml
  ...

通常、これらのコンテナー化されたテンプレートは、依存関係を追加するために他のテンプレートを参照します。たとえば、deployment/keystone/keystone-container-puppet.yaml テンプレートは、ContainersCommon リソースにベーステンプレートの出力を保管します。

resources:
  ContainersCommon:
    type: ../containers-common.yaml

これにより、コンテナー化されたテンプレートは、containers-common.yaml テンプレートからの機能やデータを取り込むことができます。

overcloud.j2.yaml heat テンプレートには、roles_data.yaml ファイル内の各カスタムロールのサービスリストを定義するための Jinja2-based コードのセクションが含まれています。

{{role.name}}Services:
  description: A list of service resources (configured in the heat
               resource_registry) which represent nested stacks
               for each service that should get installed on the {{role.name}} role.
  type: comma_delimited_list
  default: {{role.ServicesDefault|default([])}}

デフォルトのロールの場合は、これにより次のサービスリストパラメーターが作成されます: ControllerServicesComputeServicesBlockStorageServicesObjectStorageServicesCephStorageServices

roles_data.yaml ファイル内の各カスタムロールのデフォルトのサービスを定義します。たとえば、デフォルトの Controller ロールには、以下の内容が含まれます。

- name: Controller
  CountDefault: 1
  ServicesDefault:
    - OS::TripleO::Services::CACerts
    - OS::TripleO::Services::CephMon
    - OS::TripleO::Services::CephExternal
    - OS::TripleO::Services::CephRgw
    - OS::TripleO::Services::CinderApi
    - OS::TripleO::Services::CinderBackup
    - OS::TripleO::Services::CinderScheduler
    - OS::TripleO::Services::CinderVolume
    - OS::TripleO::Services::Core
    - OS::TripleO::Services::Kernel
    - OS::TripleO::Services::Keystone
    - OS::TripleO::Services::GlanceApi
    - OS::TripleO::Services::GlanceRegistry
...

これらのサービスは、次に ControllerServices パラメーターのデフォルトリストとして定義されます。

注記

環境ファイルを使用してサービスパラメーターのデフォルトリストを上書きすることもできます。たとえば、環境ファイルで ControllerServicesparameter_default として定義して、roles_data.yaml ファイルからのサービスリストを上書きすることができます。

9.9. ロールへのサービスの追加と削除

サービスの追加と削除の基本的な方法では、ノードロールのデフォルトサービスリストのコピーを作成してからサービスを追加/削除します。たとえば、OpenStack Orchestration (heat) をコントローラーノードから削除するケースを考えます。

手順

  1. デフォルトの roles ディレクトリーのカスタムコピーを作成します。

    $ cp -r /usr/share/openstack-tripleo-heat-templates/roles ~/.
  2. ~/roles/Controller.yaml ファイルを編集して、ServicesDefault パラメーターのサービスリストを変更します。OpenStack Orchestration のサービスまでスクロールしてそれらを削除します。

        - OS::TripleO::Services::GlanceApi
        - OS::TripleO::Services::GlanceRegistry
        - OS::TripleO::Services::HeatApi            # Remove this service
        - OS::TripleO::Services::HeatApiCfn         # Remove this service
        - OS::TripleO::Services::HeatApiCloudwatch  # Remove this service
        - OS::TripleO::Services::HeatEngine         # Remove this service
        - OS::TripleO::Services::MySQL
        - OS::TripleO::Services::NeutronDhcpAgent
  3. 新しい roles_data ファイルを生成します。

    $ openstack overcloud roles generate -o roles_data-no_heat.yaml \
      --roles-path ~/roles \
      Controller Compute Networker
  4. openstack overcloud deploy コマンドを実行する際には、この新しい roles_data ファイルを指定します。

    $ openstack overcloud deploy --templates -r ~/templates/roles_data-no_heat.yaml

    このコマンドにより、コントローラーノードには OpenStack Orchestration のサービスがインストールされない状態でオーバークラウドがデプロイされます。

注記

また、カスタムの環境ファイルを使用して、roles_data ファイル内のサービスを無効にすることもできます。無効にするサービスを OS::Heat::None リソースにリダイレクトします。以下に例を示します。

resource_registry:
  OS::TripleO::Services::HeatApi: OS::Heat::None
  OS::TripleO::Services::HeatApiCfn: OS::Heat::None
  OS::TripleO::Services::HeatApiCloudwatch: OS::Heat::None
  OS::TripleO::Services::HeatEngine: OS::Heat::None

9.10. 無効化されたサービスの有効化

一部のサービスはデフォルトで無効化されています。これらのサービスは、overcloud-resource-registry-puppet.j2.yaml ファイルで null 操作 (OS::Heat::None) として登録されます。たとえば、Block Storage のバックアップサービス (cinder-backup) は無効化されています。

  OS::TripleO::Services::CinderBackup: OS::Heat::None

このサービスを有効化するには、puppet/services ディレクトリー内の対応する heat テンプレートにリソースをリンクする環境ファイルを追加します。一部のサービスには、environments ディレクトリー内に事前定義済みの環境ファイルがあります。たとえば、Block Storage のバックアップサービスは、以下のような内容を含む environments/cinder-backup.yaml ファイルを使用します。

手順

  1. CinderBackup サービスを cinder-backup 設定を含む heat テンプレートにリンクする環境ファイルにエントリーを追加します。

    resource_registry:
      OS::TripleO::Services::CinderBackup: ../podman/services/pacemaker/cinder-backup.yaml
    ...

    このエントリーにより、デフォルトの null 操作のリソースが上書きされ、これらのサービスが有効になります。

  2. openstack overcloud deploy コマンドの実行時に、この環境ファイルを指定します。

    $ openstack overcloud deploy --templates -e /usr/share/openstack-tripleo-heat-templates/environments/cinder-backup.yaml

9.11. サービスなしの汎用ノードの作成

OpenStack サービスを一切設定しない汎用の Red Hat Enterprise Linux 9.0 ノードを作成することができます。これは、コアの Red Hat OpenStack Platform (RHOSP) 環境外でソフトウェアをホストする必要がある場合に役立ちます。たとえば、RHOSP は、Kibana や Sensu 等のモニタリングツールとの統合を提供します。詳細は、監視ツール設定ガイド を参照してください。Red Hat は、それらのモニタリングツールに対するサポートは提供しませんが、director では、それらのツールをホストする汎用の Red Hat Enterprise Linux 9.0 ノードの作成が可能です。

注記

汎用ノードは、ベースの Red Hat Enterprise Linux 9 イメージではなく、ベース の overcloud-hardened-uefi-full.qcow2 イメージを引き続き使用します。これは、ノードには何らかの Red Hat OpenStack Platform ソフトウェアがインストールされていますが、有効化または設定されていないことを意味します。

手順

  1. カスタムの roles_data.yaml ファイルに ServicesDefault のリストが含まれない汎用ロールを作成します。

    - name: Generic
    - name: Controller
      CountDefault: 1
      ServicesDefault:
        - OS::TripleO::Services::AuditD
        - OS::TripleO::Services::CACerts
        - OS::TripleO::Services::CephClient
        ...
    - name: Compute
      CountDefault: 1
      ServicesDefault:
        - OS::TripleO::Services::AuditD
        - OS::TripleO::Services::CACerts
        - OS::TripleO::Services::CephClient
        ...

    既存の Controller ロールおよび Compute ロールを維持するようにしてください。

  2. また、プロビジョニングするノードを選択する際には、必要な汎用 Red Hat Enterprise Linux 9 ノード数とフレーバーを指定する環境ファイル (generic-node-params.yaml) も追加することができます。

    parameter_defaults:
      OvercloudGenericFlavor: baremetal
      GenericCount: 1
  3. openstack overcloud deploy コマンドを実行する際に、ロールのファイルと環境ファイルの両方を指定します。

    $ openstack overcloud deploy --templates \
    -r ~/templates/roles_data_with_generic.yaml \
    -e ~/templates/generic-node-params.yaml

    この設定により、コントローラーノードが 1 台、コンピュートノードが 1 台、汎用 Red Hat Enterprise Linux 9 ノードが 1 台の 3 ノード設定の環境がデプロイされます。

第10章 オーバークラウドネットワークの設定

オーバークラウドの物理ネットワークを設定するには、以下の設定ファイルを作成します。

  • ネットワークデータスキーマで定義された構造に準拠するネットワーク設定ファイル network_data.yaml
  • Jinja2 ansible 形式の NIC テンプレートファイル j2 を使用した、ネットワークインターフェイスコントローラー (NIC) 設定ファイル。

10.1. ネットワーク設定ファイルの例

以下は、IPv4 および IPv6 のネットワークデータスキーマの例です。

10.1.1. IPv4 のネットワークデータスキーマの例

- name: Storage
  name_lower: storage                     #optional, default: name.lower
  admin_state_up: false                   #optional, default: false
  dns_domain: storage.localdomain.        #optional, default: undef
  mtu: 1442                               #optional, default: 1500
  shared: false                           #optional, default: false
  service_net_map_replace: storage        #optional, default: undef
  ipv6: false                             #optional, default: false
  vip: true                               #optional, default: false
  subnets:
    subnet01:
      ip_subnet: 172.18.1.0/24
      gateway_ip: 172.18.1.254            #optional, default: undef
      allocation_pools:                   #optional, default: []
        - start: 172.18.1.10
          end: 172.18.1.250
      enable_dhcp: false                  #optional, default: false
      routes:                             #optional, default: []
        - destination: 172.18.0.0/24
          nexthop: 172.18.1.254
      vlan: 21                            #optional, default: undef
      physical_network: storage_subnet01  #optional, default: {{name.lower}}_{{subnet name}}
      network_type: flat                  #optional, default: flat
      segmentation_id: 21                 #optional, default: undef
    subnet02:
      ip_subnet: 172.18.0.0/24
      gateway_ip: 172.18.0.254            #optional, default: undef
      allocation_pools:                   #optional, default: []
        - start: 172.18.0.10
          end: 172.18.0.250
      enable_dhcp: false                  #optional, default: false
      routes:                             #optional, default: []
        - destination: 172.18.1.0/24
          nexthop: 172.18.0.254
      vlan: 20                            #optional, default: undef
      physical_network: storage_subnet02  #optional, default: {{name.lower}}_{{subnet name}}
      network_type: flat                  #optional, default: flat
      segmentation_id: 20                 #optional, default: undef

10.1.2. IPv6 のネットワークデータスキーマの例

- name: Storage
  name_lower: storage
  admin_state_up: false
  dns_domain: storage.localdomain.
  mtu: 1442
  shared: false
  ipv6: true
  vip: true
  subnets:
    subnet01:
      ipv6_subnet: 2001:db8:a::/64
      gateway_ipv6: 2001:db8:a::1
      ipv6_allocation_pools:
        - start: 2001:db8:a::0010
          end: 2001:db8:a::fff9
      enable_dhcp: false
      routes_ipv6:
        - destination: 2001:db8:b::/64
          nexthop: 2001:db8:a::1
      ipv6_address_mode: null
      ipv6_ra_mode: null
      vlan: 21
      physical_network: storage_subnet01  #optional, default: {{name.lower}}_{{subnet name}}
      network_type: flat                  #optional, default: flat
      segmentation_id: 21                 #optional, default: undef
    subnet02:
      ipv6_subnet: 2001:db8:b::/64
      gateway_ipv6: 2001:db8:b::1
      ipv6_allocation_pools:
        - start: 2001:db8:b::0010
          end: 2001:db8:b::fff9
      enable_dhcp: false
      routes_ipv6:
        - destination: 2001:db8:a::/64
          nexthop: 2001:db8:b::1
      ipv6_address_mode: null
      ipv6_ra_mode: null
      vlan: 20
      physical_network: storage_subnet02  #optional, default: {{name.lower}}_{{subnet name}}
      network_type: flat                  #optional, default: flat
      segmentation_id: 20                 #optional, default: undef

10.2. ネットワーク分離

Red Hat OpenStack Platform (RHOSP) は、分離されたオーバークラウドネットワークを提供するため、特定のタイプのネットワークトラフィックを分離してホストできます。トラフィックは、特定のネットワークインターフェイスまたはボンディングに割り当てられます。ボンディングを使用するとフォールトトレランスが提供され、適切なボンディングプロトコルが使用されている場合は、負荷分散も利用できます。ネットワークが分離設定されていない場合には、RHOSP はすべてのサービスにプロビジョニングネットワークを使用します。

ネットワーク設定は、ネットワーク全体に適用されるパラメーターと、デプロイされたノードでネットワークインターフェイスを設定するために使用されるテンプレートの 2 つの部分で設定されます。

RHOSP デプロイメント用に次の分離されたネットワークを作成できます。

IPMI
ノードの電源管理に使用するネットワーク。このネットワークは、アンダークラウドのインストール前に事前定義されます。
プロビジョニング
Director は、このネットワークをデプロイメントと管理に使用します。プロビジョニングネットワークは通常、専用インターフェイスで設定されます。最初のデプロイメントでは PXE で DHCP を使用し、ネットワークは静的 IP に変換されます。デフォルトでは、ネイティブ VLAN で PXE ブートを実行する必要がありますが、一部のシステムコントローラーでは VLAN からブートできます。デフォルトでは、コンピュートノードとストレージノードはプロビジョニングインターフェイスを DNS、NTP、およびシステムメンテナンス用のデフォルトゲートウェイとして使用します。
Internal API
Internal API ネットワークは、API 通信、RPC メッセージ、データベース通信経由で RHOSP のサービス間の通信を行う際に使用します。
Tenant

Networking サービス (neutron) は、次のいずれかの方法を使用して、各テナント (プロジェクト) に独自のネットワークを提供します。

  • 各 Tenant ネットワークがネットワーク VLAN である、VLAN 分離。
  • トンネリング (VXLAN または GRE 経由)。

ネットワークトラフィックは、テナントのネットワークごとに分離されます。Tenant ネットワークにはそれぞれ IP サブネットが割り当てられています。また、ネットワーク名前空間が複数あると、複数の Tenant ネットワークが同じアドレスを使用できるので、競合は発生しません。

ストレージ
Block Storage、NFS、iSCSI などに使用されるネットワーク。理想的には、これはパフォーマンス上の理由から、完全に別のスイッチファブリックに分離した方がよいでしょう。
Storage Management
OpenStack Object Storage (swift) は、このネットワークを使用して、参加するレプリカノード間でデータオブジェクトを同期します。プロキシーサービスは、ユーザー要求と下層のストレージレイヤーの間の仲介インターフェイスとして機能します。プロキシーは、受信要求を受け取り、必要なレプリカの位置を特定して要求データを取得します。Ceph バックエンドを使用するサービスは、Ceph と直接対話せずにフロントエンドのサービスを使用するため、Storage Management ネットワーク経由で接続を確立します。RBD ドライバーは例外で、このトラフィックは直接 Ceph に接続する点に注意してください。
External
グラフィカルシステム管理用の OpenStack Dashboard (Horizon)、OpenStack サービス用のパブリック API をホストして、インスタンスへの受信トラフィック向けに SNAT を実行します。
Floating IP
受信トラフィックが Floating IP アドレスと Tenant ネットワーク内のインスタンスに実際に割り当てられた IP アドレスとの間の 1 対 1 の IP アドレスマッピングを使用してインスタンスに到達できるようにします。External ネットワークからは分離した VLAN 上で Floating IP をホストする場合には、Floating IP VLAN をコントローラーノードにトランキングして、オーバークラウドの作成後に Networking Service (neutron) を介して VLAN を追加します。これにより、複数のブリッジに接続された複数の Floating IP ネットワークを作成する手段が提供されます。VLAN は、トランキングされますが、インターフェイスとしては設定されません。その代わりに、Networking Service (neutron) は各 Floating IP ネットワークに選択したブリッジ上の VLAN セグメンテーション ID を使用して、OVS ポートを作成します。
注記

プロビジョニングネットワークはネイティブ VLAN である必要があり、他のネットワークはトランキングできます。

アンダークラウドは、デフォルトゲートウェイとして使用できます。ただし、すべてのトラフィックは IP マスカレード NAT (ネットワークアドレス変換) の背後にあり、残りの RHOSP ネットワークからは到達できません。アンダークラウドは、オーバークラウドのデフォルトルートの単一障害点でもあります。プロビジョニングネットワーク上のルーターデバイスに外部ゲートウェイが設定されている場合には、代わりにアンダークラウドの neutron DHCP サーバーがそのサービスを提供できます。

10.2.1. 各ロールに必要なネットワーク

VLAN を使用して Tenant ネットワークを作成できますが、テナント VLAN を使用せずに、特別な用途のために VXLAN トンネルを作成ことも可能です。テナント VLAN を使用するデプロイメントに VXLAN 機能を追加することは可能ですが、サービスを中断せずに、テナント VLAN を、デプロイされたオーバークラウドに追加することはできません。

次の表は、各ロールに接続されている分離されたネットワークの詳細を示しています。

ロールネットワーク

Controller

プロビジョニング、Internal API、Storage、Storage Management、Tenant、External

Compute

プロビジョニング、Internal API、Storage、Tenant

Ceph Storage

プロビジョニング、Internal API、Storage、Tenant

Cinder Storage

プロビジョニング、Internal API、Storage、Storage Management

Swift Storage

プロビジョニング、Internal API、Storage、Storage Management

10.2.2. ネットワーク定義ファイルの設定オプション

次の表を使用して、ネットワーク定義ファイル network_data.yaml を YAML 形式で設定するために使用できるオプションを理解してください。

表10.1 ネットワークデータ YAML オプション

名前オプションタイプデフォルト値

name

ネットワークの名前

string

 

name_lower

オプション: ネットワークの小文字の名前。

string

name.lower()

dns_domain

オプション: ネットワークの DNS ドメイン名。

string

 

mtu

最大伝送単位 (MTU)

number

1500

ipv6

オプション: IPv6 を使用する場合は true に設定します。

Boolean

false

vip

ネットワーク上に VIP を作成します。

Boolean

false

subnets

ネットワークのサブネットが含まれます。

ディクショナリー

 

表10.2 サブネット定義のネットワークデータ YAML オプション

名前オプションタイプ / 要素

ip_subnet

IPv4 CIDR ブロック表記。

string

192.0.5.0/24

ipv6_subnet

IPv6 CIDR ブロック表記。

string

2001:db6:fd00:1000::/64

gateway_ip

オプション: ゲートウェイ IPv4 アドレス。

string

192.0.5.1

allocation_pools

サブネットの開始アドレスと終了アドレス。

リスト/ディクショナリー

start: 192.0.5.100

end: 192.0.5.150

ipv6_allocation_pools

サブネットの開始アドレスと終了アドレス。

リスト/ディクショナリー

start: 2001:db6:fd00:1000:100::1

end: 2001:db6:fd00:1000:150::1

routes

ネットワークゲートウェイ経由のルーティングが必要な IPv4 ネットワークのリスト。

リスト/ディクショナリー

 

routes_ipv6

ネットワークゲートウェイ経由のルーティングが必要な IPv6 ネットワークのリスト。

リスト/ディクショナリー

 

vlan

オプション: ネットワークの VLAN ID。

number

 
注記

routes および routes_ipv6 オプションには、ルートのリストが含まれています。各ルートは、destinationnexthop キーを含むディクショナリーエントリーです。どちらのオプションも文字列型です。

routes:
  - destination: 198.51.100.0/24
    nexthop: 192.0.5.1
  - destination: 203.0.113.0/24
    nexthost: 192.0.5.1
routes:
  - destination: 2001:db6:fd00:2000::/64
    nexthop: 2001:db6:fd00:1000:100::1
  - destination: 2001:db6:fd00:3000::/64
    nexthost: 2001:db6:fd00:1000:100::1

表10.3 ネットワーク仮想 IP の YAML データオプション

名前オプションタイプ / 要素デフォルト値

network

Neutron ネットワーク名。

string

 

ip_address

オプション: 事前定義されたFixed IP アドレス。

string

 

subnet

Neutron サブネット名。仮想 IP neutron ポートのサブネットを指定します。ルーティングされたネットワークを使用するデプロイメントに必要です。

string

 

dns_name

オプション: FQDN (完全修飾ドメイン名)。

リスト/ディクショナリー

overcloud

name

オプション: 仮想 IP 名。

string

$network_name_virtual_ip

10.2.3. ネットワーク分離の設定

ネットワーク分離を有効にして設定するには、必要な要素を network_data.yaml 設定ファイルに追加する必要があります。

手順

  1. ネットワーク YAML 定義ファイルを作成します。

    $ cp /usr/share/openstack-tripleo-heat-templates/network-data-samples/default-network-isolation-ipv6.yaml /home/stack/templates/network_data.yaml
  2. オーバークラウドのネットワーク環境の要件に合わせて、network_data.yaml ファイルのオプションを更新します。

    - name: Storage
      name_lower: storage
      vip: true
      ipv6: true
      mtu: 1500
      subnets:
        storage_subnet:
          ipv6_subnet: fd00:fd00:fd00:3000::/64
          ipv6_allocation_pools:
            - start: fd00:fd00:fd00:3000::10
              end: fd00:fd00:fd00:3000:ffff:ffff:ffff:fffe
          vlan: 30
    - name: StorageMgmt
      name_lower: storage_mgmt
      vip: true
      ipv6: true
      mtu: 1500
      subnets:
        storage_mgmt_subnet:
          ipv6_subnet: fd00:fd00:fd00:4000::/64
          ipv6_allocation_pools:
            - start: fd00:fd00:fd00:4000::10
              end: fd00:fd00:fd00:4000:ffff:ffff:ffff:fffe
          vlan: 40
    - name: InternalApi
      name_lower: internal_api
      vip: true
      ipv6: true
      mtu: 1500
      subnets:
        internal_api_subnet:
          ipv6_subnet: fd00:fd00:fd00:2000::/64
          ipv6_allocation_pools:
            - start: fd00:fd00:fd00:2000::10
              end: fd00:fd00:fd00:2000:ffff:ffff:ffff:fffe
          vlan: 20
    - name: Tenant
      name_lower: tenant
      vip: false # Tenant networks do not use VIPs
      ipv6: true
      mtu: 1500
      subnets:
        tenant_subnet:
          ipv6_subnet: fd00:fd00:fd00:5000::/64
          ipv6_allocation_pools:
            - start: fd00:fd00:fd00:5000::10
              end: fd00:fd00:fd00:5000:ffff:ffff:ffff:fffe
          vlan: 50
    - name: External
      name_lower: external
      vip: true
      ipv6: true
      mtu: 1500
      subnets:
        external_subnet:
          ipv6_subnet: 2001:db8:fd00:1000::/64
          ipv6_allocation_pools:
            - start: 2001:db8:fd00:1000::10
              end: 2001:db8:fd00:1000:ffff:ffff:ffff:fffe
          gateway_ipv6: 2001:db8:fd00:1000::1
          vlan: 10

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

特定のネットワークトラフィックを異なるネットワークでホストする場合は、カスタムコンポーザブルネットワークを作成することができます。Director は、ネットワーク分離が有効になっているデフォルトのネットワークトポロジーを提供します。この設定は /usr/share/openstack-tripleo-heat-templates/network-data-samples/default-network-isolation.yaml にあります。

デフォルトのオーバークラウドでは、以下に示す事前定義済みのネットワークセグメントのセットが使用されます。

  • Internal API
  • ストレージ
  • Storage Management
  • Tenant
  • External

コンポーザブルネットワークを使用して、さまざまなサービス用のネットワークを追加することができます。たとえば、NFS トラフィック専用のネットワークがある場合には、複数のロールに提供できます。

director は、デプロイメントおよび更新フェーズでのカスタムネットワークの作成をサポートしています。このような追加のネットワークを、ベアメタルノード、システム管理に使用したり、異なるロール用に別のネットワークを作成するのに使用したりすることができます。また、これは、トラフィックが複数のネットワーク間でルーティングされる、分離型のデプロイメント用に複数のネットワークセットを作成するのに使用することもできます。

10.3.1. コンポーザブルネットワークの追加

コンポーザブルネットワークを使用して、さまざまなサービス用のネットワークを追加します。たとえば、ストレージバックアップトラフィック専用のネットワークがある場合には、ネットワークを複数のロールに提供できます。

/usr/share/openstack-tripleo-heat-templates/network-data-samples ディレクトリーにサンプルファイルがあります。

手順

  1. 利用可能なサンプル設定ファイルを一覧表示します。

    $ ll /usr/share/openstack-tripleo-heat-templates/network-data-samples/
    -rw-r--r--. 1 root root 1554 May 11 23:04 default-network-isolation-ipv6.yaml
    -rw-r--r--. 1 root root 1181 May 11 23:04 default-network-isolation.yaml
    -rw-r--r--. 1 root root 1126 May 11 23:04 ganesha-ipv6.yaml
    -rw-r--r--. 1 root root 1100 May 11 23:04 ganesha.yaml
    -rw-r--r--. 1 root root 3556 May 11 23:04 legacy-routed-networks-ipv6.yaml
    -rw-r--r--. 1 root root 2929 May 11 23:04 legacy-routed-networks.yaml
    -rw-r--r--. 1 root root  383 May 11 23:04 management-ipv6.yaml
    -rw-r--r--. 1 root root  290 May 11 23:04 management.yaml
    -rw-r--r--. 1 root root  136 May 11 23:04 no-networks.yaml
    -rw-r--r--. 1 root root 2725 May 11 23:04 routed-networks-ipv6.yaml
    -rw-r--r--. 1 root root 2033 May 11 23:04 routed-networks.yaml
    -rw-r--r--. 1 root root  943 May 11 23:04 vip-data-default-network-isolation.yaml
    -rw-r--r--. 1 root root  848 May 11 23:04 vip-data-fixed-ip.yaml
    -rw-r--r--. 1 root root 1050 May 11 23:04 vip-data-routed-networks.yaml
  2. ニーズに最適なネットワーク設定ファイルの例をコピーします。

    $ cp /usr/share/openstack-tripleo-heat-templates/network-data-samples/default-network-isolation.yaml /home/stack/templates/network_data.yaml
  3. network_data.yaml 設定ファイルを編集して、新しいネットワークのセクションを追加します。

    - name: StorageBackup
      vip: false
      name_lower: storage_backup
      subnets:
        storage_backup_subnet:
          ip_subnet: 172.16.6.0/24
          allocation_pools:
            - start: 172.16.6.4
            - end: 172.16.6.250
          gateway_ip: 172.16.6.1

    network_data.yaml ファイルでは、以下のパラメーターを使用することができます。

    name
    ネットワークの名前を設定します。
    vip
    ネットワーク上での仮想 IP アドレスの作成を有効にします
    name_lower
    ネットワーク名の小文字バージョンを設定します。director は、この名前を roles_data.yaml ファイルのロールに割り当てられる該当ネットワークにマッピングします。
    subnets
    1 つ以上のサブネット定義。
    subnet_name
    サブネットの名前を設定します。
    ip_subnet
    IPv4 サブネットを CIDR 形式で設定します。
    allocation_pools
    IPv4 サブネットの IP 範囲を設定します。
    gateway_ip
    ネットワークのゲートウェイを設定します。
    vlan
    ネットワークの VLAN ID を設定します。
    ipv6
    この値は true または false に設定します。
    ipv6_subnet
    IPv6 サブネットを設定します。
    gateway_ipv6
    IPv6 ネットワークのゲートウェイを設定します。
    ipv6_allocation_pools
    IPv6 サブネットの IP 範囲を設定します。
    routes_ipv6
    IPv6 ネットワークのルートを設定します。
  4. 必要なサンプルネットワーク VIP 定義テンプレートを /usr/share/openstack-tripleo-heat-templates/network-data-samples から環境ファイルディレクトリーにコピーします。次の例では、vip-data-default-network-isolation.yamlvip_data.yaml という名前のローカル環境ファイルにコピーします。

    $ cp /usr/share/openstack-tripleo-heat-templates/network-data-samples/vip-data-default-network-isolation.yaml  /home/stack/templates/vip_data.yaml
  5. vip_data.yaml 設定ファイルを編集します。仮想 IP データは、仮想 IP アドレス定義のリストであり、それぞれに IP アドレスが割り当てられているネットワークの名前が含まれています。

    - network: storage_mgmt
      dns_name: overcloud
    - network: internal_api
      dns_name: overcloud
    - network: storage
      dns_name: overcloud
    - network: external
      dns_name: overcloud
      ip_address: <vip_address>
    - network: ctlplane
      dns_name: overcloud
    • <vip_address> は、必要な仮想 IP アドレスに置き換えます。

    vip_data.yaml ファイルで次のパラメーターを使用できます。

    network
    neutron ネットワーク名を設定します。これは唯一の必須パラメーターです。
    ip_address
    VIP の IP アドレスを設定します。
    subnet
    neutron サブネット名を設定します。仮想 IP neutron ポートを作成するときにサブネットを指定するために使用します。このパラメーターは、展開でルーティングされたネットワークを使用する場合に必要です。
    dns_name
    FQDN (完全修飾ドメイン名) を設定します
    name
    仮想 IP 名を設定します。
  6. サンプルネットワーク設定テンプレートをコピーします。Jinja2 テンプレートは、NIC 設定テンプレートを定義するために使用されます。/usr/share/ansible/roles/tripleo_network_config/templates/ ディレクトリーにある例を参照してください。例の 1 つが要件に一致する場合は、それを使用してください。例が要件に合わない場合は、サンプル設定ファイルをコピーし、必要に応じて変更します。

    $ cp /usr/share/ansible/roles/tripleo_network_config/templates/single_nic_vlans/single_nic_vlans.j2 /home/stack/templates/
  7. single_nic_vlans.j2 設定ファイルを編集します。

    ---
    {% set mtu_list = [ctlplane_mtu] %}
    {% for network in role_networks %}
    {{ mtu_list.append(lookup('vars', networks_lower[network] ~ '_mtu')) }}
    {%- endfor %}
    {% set min_viable_mtu = mtu_list | max %}
    network_config:
    - type: ovs_bridge
      name: {{ neutron_physical_bridge_name }}
      mtu: {{ min_viable_mtu }}
      use_dhcp: false
      dns_servers: {{ ctlplane_dns_nameservers }}
      domain: {{ dns_search_domains }}
      addresses:
      - ip_netmask: {{ ctlplane_ip }}/{{ ctlplane_subnet_cidr }}
      routes: {{ ctlplane_host_routes }}
      members:
      - type: interface
        name: nic1
        mtu: {{ min_viable_mtu }}
        # force the MAC address of the bridge to this interface
        primary: true
    {% for network in role_networks %}
      - type: vlan
        mtu: {{ lookup('vars', networks_lower[network] ~ '_mtu') }}
        vlan_id: {{ lookup('vars', networks_lower[network] ~ '_vlan_id') }}
        addresses:
        - ip_netmask:
            {{ lookup('vars', networks_lower[network] ~ '_ip') }}/{{ lookup('vars', networks_lower[network] ~ '_cidr') }}
        routes: {{ lookup('vars', networks_lower[network] ~ '_host_routes') }}
    {% endfor %}
  8. overcloud-baremetal-deploy.yaml 設定ファイルで network_config テンプレートを設定します。

    - name: CephStorage
      count: 3
      defaults:
        networks:
        - network: storage
        - network: storage_mgmt
        - network: storage_backup
        network_config:
          template: /home/stack/templates/single_nic_vlans.j2
  9. オーバークラウドネットワークをプロビジョニングします。このアクションにより、オーバークラウドのデプロイ時に環境ファイルで使用される出力ファイルが生成されます。

    (undercloud)$ openstack overcloud network provision --output <deployment_file> /home/stack/templates/<networks_definition_file>.yaml
    • <networks_definition_file> は、ネットワーク定義ファイルの名前 (network_data.yaml など) に置き換えます。
    • <deployment_file> は、デプロイメントコマンドに追加するために生成する heat 環境ファイルの名前に置き換えます (例 :/home/stack/templates/overcloud-networks-deployed.yaml)
  10. ネットワーク VIP をプロビジョニングし、vip-deployed-environment.yaml ファイルを生成します。オーバークラウドをデプロイするときに、このファイルを使用します。

    (overcloud)$ openstack overcloud network vip provision  --stack <stack> --output <deployment_file> /home/stack/templates/vip_data.yaml
    • <stack> は、ネットワーク VIP がプロビジョニングされるスタックの名前に置き換えます。指定しない場合、デフォルトは overcloud です。
    • <deployment_file> は、デプロイメントコマンドに含めるために生成する heat 環境ファイルの名前に置き換えます (例 :/home/stack/templates/overcloud-vip-deployed.yaml)

10.3.2. ロールへのコンポーザブルネットワークの追加

コンポーザブルネットワークをご自分の環境で定義したオーバークラウドロールに割り当てることができます。たとえば、カスタム StorageBackup ネットワークを Ceph Storage ノードに追加することができます。

手順

  1. カスタム roles_data.yaml ファイルがまだない場合には、デフォルトをご自分のホームディレクトリーにコピーします。

    $ cp /usr/share/openstack-tripleo-heat-templates/roles_data.yaml /home/stack/templates/roles_data.yaml
  2. カスタムの roles_data.yaml ファイルを編集します。
  3. ネットワークを追加するロールの networks リストにネットワーク名を追加します。たとえば、StorageBackup ネットワークを Ceph Storage ロールに追加するには、以下のスニペット例を使用します。

    - name: CephStorage
      description: |
        Ceph OSD Storage node role
      networks:
        Storage
          subnet: storage_subnet
        StorageMgmt
          subnet: storage_mgmt_subnet
        StorageBackup
          subnet: storage_backup_subnet
  4. カスタムネットワークを対応するロールに追加したら、ファイルを保存します。

openstack overcloud deploy コマンドを実行する際に、-r オプションを使用してカスタムの roles_data.yaml ファイルを指定します。-r オプションを設定しないと、デプロイメントコマンドはデフォルトのロールセットとそれに対応する割り当て済みのネットワークを使用します。

10.3.3. コンポーザブルネットワークへの OpenStack サービスの割り当て

各 OpenStack サービスは、リソースレジストリーでデフォルトのネットワーク種別に割り当てられます。これらのサービスは、そのネットワーク種別に割り当てられたネットワーク内の IP アドレスにバインドされます。OpenStack サービスはこれらのネットワークに分割されますが、実際の物理ネットワーク数はネットワーク環境ファイルに定義されている数と異なる可能性があります。環境ファイル (たとえば /home/stack/templates/service-reassignments.yaml) で新たにネットワークマッピングを定義することで、OpenStack サービスを異なるネットワーク種別に再割り当てすることができます。ServiceNetMap パラメーターにより、各サービスに使用するネットワーク種別が決定されます。

たとえば、ハイライトしたセクションを変更して、Storage Management ネットワークサービスを Storage Backup ネットワークに再割り当てすることができます。

parameter_defaults:
  ServiceNetMap:
    SwiftStorageNetwork: storage_backup
    CephClusterNetwork: storage_backup

これらのパラメーターを storage_backup に変更すると、対象のサービスは Storage Management ネットワークではなく、Storage Backup ネットワークに割り当てられます。つまり、parameter_defaults セットを設定するのは Storage Backup ネットワーク用だけで、Storage Management ネットワーク用に設定する必要はありません。

director はカスタムの ServiceNetMap パラメーターの定義を ServiceNetMapDefaults から取得したデフォルト値の事前定義済みリストにマージして、デフォルト値を上書きします。director はカスタマイズされた設定を含む完全なリストを ServiceNetMap に返し、そのリストは多様なサービスのネットワーク割り当ての設定に使用されます。

サービスマッピングは、Pacemaker を使用するノードの network_data.yaml ファイルで vip: true と設定されているネットワークに適用されます。オーバークラウドの負荷分散サービスにより、トラフィックが仮想 IP から特定のサービスのエンドポイントにリダイレクトされます。

注記

デフォルトのサービスの全リストは、/usr/share/openstack-tripleo-heat-templates/network/service_net_map.j2.yaml ファイル内の ServiceNetMapDefaults パラメーターの箇所に記載されています。

10.3.4. カスタムコンポーザブルネットワークの有効化

デフォルトの NIC テンプレートの 1 つを使用して、カスタムのコンポーザブルネットワークを有効にします。この例では、Single NIC with VLANs テンプレート (custom_single_nic_vlans) を使用します。

手順

  1. source コマンドで stackrc アンダークラウド認証情報ファイルを読み込みます。

    $ source ~/stackrc
  2. オーバークラウドネットワークをプロビジョニングします。

    $ openstack overcloud network provision \
      --output overcloud-networks-deployed.yaml \
      custom_network_data.yaml
  3. ネットワーク VIP をプロビジョニングします。

    $ openstack overcloud network vip provision \
        --stack overcloud \
        --output overcloud-networks-vips-deployed.yaml \
         custom_vip_data.yaml
  4. オーバークラウドノードをプロビジョニングします。

    $ openstack overcloud node provision \
        --stack overcloud \
        --output overcloud-baremetal-deployed.yaml \
        overcloud-baremetal-deploy.yaml
  5. 以下の例のように、設定ファイルとテンプレートを必要な順序で指定して、openstack overcloud deploy コマンドを作成します。

    $ openstack overcloud deploy --templates \
      --networks-file network_data_v2.yaml \
      -e overcloud-networks-deployed.yaml \
      -e overcloud-networks-vips-deployed.yaml \
      -e overcloud-baremetal-deployed.yaml
      -e custom-net-single-nic-with-vlans.yaml

上記の例に示すコマンドにより、追加のカスタムネットワークを含め、コンポーザブルネットワークがオーバークラウドのノード全体にデプロイされます。

10.3.5. デフォルトネットワークの名前変更

network_data.yaml ファイルを使用して、デフォルトネットワークのユーザー表示名を変更することができます。

  • InternalApi
  • External
  • Storage
  • StorageMgmt
  • Tenant

これらの名前を変更するのに、name フィールドを変更しないでください。代わりに、name_lower フィールドをネットワークの新しい名前に変更し、新しい名前で ServiceNetMap を更新します。

手順

  1. network_data.yaml ファイルで、名前を変更する各ネットワークの name_lower パラメーターに新しい名前を入力します。

    - name: InternalApi
      name_lower: MyCustomInternalApi
  2. service_net_map_replace パラメーターに、name_lower パラメーターのデフォルト値を追加します。

    - name: InternalApi
      name_lower: MyCustomInternalApi
      service_net_map_replace: internal_api

10.4. カスタムネットワークインターフェイステンプレート

「ネットワーク分離」を設定したら、実際の環境内のノードに適したカスタムネットワークインターフェイステンプレートのセットを作成することができます。たとえば、以下のファイルを含めることができます。

  • ネットワークのデフォルト値を設定するための環境ファイル (/usr/share/openstack-tripleo-heat-templates/environments/network/multiple-nics/network-environment.yaml)
  • 各ノードの NIC レイアウトを定義するためのテンプレート。オーバークラウドのコアテンプレートコレクションには、さまざまなユースケースに対応する複数のデフォルトが含まれます。カスタム NIC テンプレートを作成するには、デフォルトの Jinja2 テンプレートをレンダリングしてカスタムテンプレートのベースにします。
  • NIC を有効にするためのカスタム環境ファイル。以下の例では、カスタムインターフェイステンプレートを参照するカスタム環境ファイル (/home/stack/templates/custom-network-configuration.yaml) を用いています。
  • ネットワーク設定パラメーターをカスタマイズするその他の環境ファイル。
  • ネットワークをカスタマイズする場合には、カスタム network_data.yaml ファイル
  • 追加のネットワークまたはカスタムコンポーザブルネットワークを作成する場合には、カスタム network_data.yaml ファイルおよびカスタム roles_data.yaml ファイル
注記

前述のリストのファイルは一部 Jinja2 形式のファイルで、.j2.yaml の拡張子を持つものがあります。director は、デプロイメント中にこれらのファイルを .yaml バージョンにレンダリングします。

10.4.1. カスタムネットワークアーキテクチャー

サンプルの NIC テンプレートは、特定のネットワーク設定に適切ではない場合があります。たとえば、特定のネットワークレイアウトに適した、専用のカスタム NIC テンプレートを作成しなければならない場合があります。また、コントロールサービスとデータサービスを異なる NIC に分離しなければならない場合があります。このような場合には、サービスから NIC への割り当てを以下のようにマッピングすることができます。

  • NIC1 (プロビジョニング)

    • Provisioning / Control Plane
  • NIC2 (コントロールグループ)

    • Internal API
    • Storage Management
    • External (パブリック API)
  • NIC3 (データグループ)

    • Tenant Network (VXLAN トンネリング)
    • Tenant VLAN / Provider VLAN
    • Storage
    • External VLAN (Floating IP/SNAT)
  • NIC4 (管理)

    • 管理

10.4.2. ネットワークインターフェイスの参照

ネットワークインターフェイスの設定には、以下のパラメーターが含まれます。

インターフェイス

単一のネットワークインターフェイスを定義します。この設定では、実際のインターフェイス名 (eth0、eth1、enp0s25) または番号によるインターフェイス (nic1、nic2、nic3) を使用して各インターフェイスを定義します。

  - type: interface
    name: nic2

表10.4 interface のオプション

オプションデフォルト説明

name

 

インターフェイス名

use_dhcp

False

DHCP を使用して IP アドレスを取得します。

use_dhcpv6

False

DHCP を使用して v6 の IP アドレスを取得します。

addresses

 

インターフェイスに割り当てられる IP アドレスのリスト

routes

 

インターフェイスに割り当てられるルートのリスト。詳細は、routes を参照してください。

mtu

1500

接続の最大伝送単位 (MTU: Maximum Transmission Unit)

primary

False

プライマリーインターフェイスとしてインターフェイスを定義します。

persist_mapping

False

システム名の代わりにデバイスのエイリアス設定を記述します。

dhclient_args

なし

DHCP クライアントに渡す引数

dns_servers

なし

インターフェイスに使用する DNS サーバーのリスト

ethtool_opts

 

特定の NIC で VXLAN を使用する際にスループットを向上させるには、このオプションを "rx-flow-hash udp4 sdfn" に設定します。

vlan

VLAN を定義します。parameters セクションから渡された VLAN ID およびサブネットを使用します。

以下に例を示します。

  - type: vlan
    device: nic{{ loop.index + 1 }}
    mtu: {{ lookup('vars', networks_lower[network] ~ '_mtu') }}
    vlan_id: {{ lookup('vars', networks_lower[network] ~ '_vlan_id') }}
    addresses:
    - ip_netmask:
      {{ lookup('vars', networks_lower[network] ~ '_ip') }}/{{ lookup('vars', networks_lower[network] ~ '_cidr') }}
  routes: {{ lookup('vars', networks_lower[network] ~ '_host_routes') }}

表10.5 vlan のオプション

オプションデフォルト説明

vlan_id

 

VLAN ID

device

 

VLAN の接続先となる親デバイス。VLAN が OVS ブリッジのメンバーではない場合に、このパラメーターを使用します。たとえば、このパラメーターを使用して、ボンディングされたインターフェイスデバイスに VLAN を接続します。

use_dhcp

False

DHCP を使用して IP アドレスを取得します。

use_dhcpv6

False

DHCP を使用して v6 の IP アドレスを取得します。

addresses

 

VLAN に割り当てられる IP アドレスのリスト

routes

 

VLAN に割り当てられるルートのリスト。詳細は、routes を参照してください。

mtu

1500

接続の最大伝送単位 (MTU: Maximum Transmission Unit)

primary

False

プライマリーインターフェイスとして VLAN を定義します。

persist_mapping

False

システム名の代わりにデバイスのエイリアス設定を記述します。

dhclient_args

なし

DHCP クライアントに渡す引数

dns_servers

なし

VLAN に使用する DNS サーバーのリスト

ovs_bond

Open vSwitch で、複数の インターフェイス を結合するボンディングを定義します。これにより、冗長性や帯域幅が向上します。

以下に例を示します。

  members:
    - type: ovs_bond
      name: bond1
      mtu: {{ min_viable_mtu }}
      ovs_options: {{ bond_interface_ovs_options }}
      members:
      - type: interface
        name: nic2
        mtu: {{ min_viable_mtu }}
        primary: true
      - type: interface
        name: nic3
        mtu: {{ min_viable_mtu }}

表10.6 ovs_bond のオプション

オプションデフォルト説明

name

 

ボンディング名

use_dhcp

False

DHCP を使用して IP アドレスを取得します。

use_dhcpv6

False

DHCP を使用して v6 の IP アドレスを取得します。

addresses

 

ボンディングに割り当てられる IP アドレスのリスト

routes

 

ボンディングに割り当てられるルートのリスト。詳細は、routes を参照してください。

mtu

1500

接続の最大伝送単位 (MTU: Maximum Transmission Unit)

primary

False

プライマリーインターフェイスとしてインターフェイスを定義します。

members

 

ボンディングで使用するインターフェイスオブジェクトのリスト

ovs_options

 

ボンディング作成時に OVS に渡すオプションのセット

ovs_extra

 

ボンディングのネットワーク設定ファイルで OVS_EXTRA パラメーターとして設定するオプションのセット

defroute

True

DHCP サービスにより提供されるデフォルトのルートを使用します。use_dhcp または use_dhcpv6 を選択した場合に限り有効です。

persist_mapping

False

システム名の代わりにデバイスのエイリアス設定を記述します。

dhclient_args

なし

DHCP クライアントに渡す引数

dns_servers

なし

ボンディングに使用する DNS サーバーのリスト

ovs_bridge

Open vSwitch で、複数の interfaceovs_bondvlan オブジェクトを接続するブリッジを定義します。

ネットワークインターフェイス種別 ovs_bridge には、パラメーター name を使用します。

注記

複数のブリッジがある場合は、デフォルト名の bridge_name を受け入れるのではなく、個別のブリッジ名を使用する必要があります。個別の名前を使用しないと、コンバージフェーズ時に 2 つのネットワークボンディングが同じブリッジに配置されます。

外部の tripleo ネットワークに OVS ブリッジを定義している場合は、bridge_name および interface_name の値を維持します。デプロイメントフレームワークが、これらの値を自動的にそれぞれ外部ブリッジ名および外部インターフェイス名に置き換えるためです。

以下に例を示します。

  - type: ovs_bridge
    name: br-bond
    dns_servers: {{ ctlplane_dns_nameservers }}
    domain: {{ dns_search_domains }}
    members:
    - type: ovs_bond
      name: bond1
      mtu: {{ min_viable_mtu }}
      ovs_options: {{ bound_interface_ovs_options }}
      members:
      - type: interface
        name: nic2
        mtu: {{ min_viable_mtu }}
        primary: true
      - type: interface
        name: nic3
        mtu: {{ min_viable_mtu }}
注記

OVS ブリッジは、Networking サービス (neutron) サーバーに接続して設定データを取得します。OpenStack の制御トラフィック (通常 Control Plane および Internal API ネットワーク) が OVS ブリッジに配置されていると、OVS がアップグレードされたり、管理ユーザーやプロセスによって OVS ブリッジが再起動されたりする度に、neutron サーバーへの接続が失われます。これにより、ダウンタイムが発生します。このような状況でダウンタイムが許容されない場合は、コントロールグループのネットワークを OVS ブリッジではなく別のインターフェイスまたはボンディングに配置する必要があります。

  • Internal API ネットワークをプロビジョニングインターフェイス上の VLAN および 2 番目のインターフェイス上の OVS ブリッジに配置すると、最小の設定を行うことができます。
  • ボンディングを実装する場合は、少なくとも 2 つのボンディング (4 つのネットワークインターフェイス) が必要です。コントロールグループを Linux ボンディング (Linux ブリッジ) に配置します。PXE ブート用のシングルインターフェイスへの LACP フォールバックをスイッチがサポートしていない場合には、このソリューションには少なくとも 5 つの NIC が必要となります。

表10.7 ovs_bridge のオプション

オプションデフォルト説明

name

 

ブリッジ名

use_dhcp

False

DHCP を使用して IP アドレスを取得します。

use_dhcpv6

False

DHCP を使用して v6 の IP アドレスを取得します。

addresses

 

ブリッジに割り当てられる IP アドレスのリスト

routes

 

ブリッジに割り当てられるルートのリスト。詳細は、routes を参照してください。

mtu

1500

接続の最大伝送単位 (MTU: Maximum Transmission Unit)

members

 

ブリッジで使用するインターフェイス、VLAN、およびボンディングオブジェクトのリスト

ovs_options

 

ブリッジ作成時に OVS に渡すオプションのセット

ovs_extra

 

ブリッジのネットワーク設定ファイルで OVS_EXTRA パラメーターとして設定するオプションのセット

defroute

True

DHCP サービスにより提供されるデフォルトのルートを使用します。use_dhcp または use_dhcpv6 を選択した場合に限り有効です。

persist_mapping

False

システム名の代わりにデバイスのエイリアス設定を記述します。

dhclient_args

なし

DHCP クライアントに渡す引数

dns_servers

なし

ブリッジに使用する DNS サーバーのリスト

linux_bond

複数の インターフェイス を結合する Linux ボンディングを定義します。これにより、冗長性や帯域幅が向上します。bonding_options パラメーターには、カーネルベースのボンディングオプションを指定するようにしてください。

以下に例を示します。

- type: linux_bridge
  name: {{ neutron_physical_bridge_name }}
  mtu: {{ min_viable_mtu }}
  use_dhcp: false
  dns_servers: {{ ctlplane_dns_nameservers }}
  domain: {{ dns_search_domains }}
  addresses:
  - ip_netmask: {{ ctlplane_ip }}/{{ ctlplane_subnet_cidr }}
  routes: {{ ctlplane_host_routes }}

ボンディングが nic2 の MAC アドレスを使用するように、nic2 には primary: true が設定される点に注意してください。

表10.8 linux_bond のオプション

オプションデフォルト説明

name

 

ボンディング名

use_dhcp

False

DHCP を使用して IP アドレスを取得します。

use_dhcpv6

False

DHCP を使用して v6 の IP アドレスを取得します。

addresses

 

ボンディングに割り当てられる IP アドレスのリスト

routes

 

ボンディングに割り当てられるルートのリスト。routesを参照してください。

mtu

1500

接続の最大伝送単位 (MTU: Maximum Transmission Unit)

primary

False

プライマリーインターフェイスとしてインターフェイスを定義します。

members

 

ボンディングで使用するインターフェイスオブジェクトのリスト

bonding_options

 

ボンディングを作成する際のオプションのセット

defroute

True

DHCP サービスにより提供されるデフォルトのルートを使用します。use_dhcp または use_dhcpv6 を選択した場合に限り有効です。

persist_mapping

False

システム名の代わりにデバイスのエイリアス設定を記述します。

dhclient_args

なし

DHCP クライアントに渡す引数

dns_servers

なし

ボンディングに使用する DNS サーバーのリスト

linux_bridge

複数の interfacelinux_bondvlan オブジェクトを接続する Linux ブリッジを定義します。外部のブリッジは、パラメーターに 2 つの特殊な値も使用します。

  • bridge_name: 外部ブリッジ名に置き換えます。
  • interface_name: 外部インターフェイスに置き換えます。

以下に例を示します。

  - type: linux_bridge
      name: bridge_name
      mtu:
        get_attr: [MinViableMtu, value]
      use_dhcp: false
      dns_servers:
        get_param: DnsServers
      domain:
        get_param: DnsSearchDomains
      addresses:
      - ip_netmask:
          list_join:
          - /
          - - get_param: ControlPlaneIp
            - get_param: ControlPlaneSubnetCidr
      routes:
        list_concat_unique:
          - get_param: ControlPlaneStaticRoutes

表10.9 linux_bridge のオプション

オプションデフォルト説明

name

 

ブリッジ名

use_dhcp

False

DHCP を使用して IP アドレスを取得します。

use_dhcpv6

False

DHCP を使用して v6 の IP アドレスを取得します。

addresses

 

ブリッジに割り当てられる IP アドレスのリスト

routes

 

ブリッジに割り当てられるルートのリスト。詳細は、routes を参照してください。

mtu

1500

接続の最大伝送単位 (MTU: Maximum Transmission Unit)

members

 

ブリッジで使用するインターフェイス、VLAN、およびボンディングオブジェクトのリスト

defroute

True

DHCP サービスにより提供されるデフォルトのルートを使用します。use_dhcp または use_dhcpv6 を選択した場合に限り有効です。

persist_mapping

False

システム名の代わりにデバイスのエイリアス設定を記述します。

dhclient_args

なし

DHCP クライアントに渡す引数

dns_servers

なし

ブリッジに使用する DNS サーバーのリスト

routes

ネットワークインターフェイス、VLAN、ブリッジ、またはボンディングに適用するルートのリストを定義します。

以下に例を示します。

  - type: linux_bridge
    name: bridge_name
    ...
    routes: {{ [ctlplane_host_routes] | flatten | unique }}
オプションデフォルト説明

ip_netmask

なし

接続先ネットワークの IP およびネットマスク

default

False

このルートをデフォルトルートに設定します。ip_netmask: 0.0.0.0/0 の設定と等価です。

next_hop

なし

接続先ネットワークに到達するのに使用するルーターの IP アドレス

10.4.3. ネットワークインターフェイスレイアウトの例

以下のスニペットはコントローラーノードの NIC テンプレートの例で、コントロールグループを OVS ブリッジから分離するカスタムネットワークシナリオの設定方法を示しています。

network_config:
- type: interface
  name: nic1
  mtu: {{ ctlplane_mtu }}
  use_dhcp: false
  addresses:
  - ip_netmask: {{ ctlplane_ip }}/{{ ctlplane_subnet_cidr }}
  routes: {{ ctlplane_host_routes }}
- type: linux_bond
  name: bond_api
  mtu: {{ min_viable_mtu_ctlplane }}
  use_dhcp: false
  bonding_options: {{ bond_interface_ovs_options }}
  dns_servers: {{ ctlplane_dns_nameservers }}
  domain: {{ dns_search_domains }}
  members:
  - type: interface
    name: nic2
    mtu: {{ min_viable_mtu_ctlplane }}
    primary: true
  - type: interface
    name: nic3
    mtu: {{ min_viable_mtu_ctlplane }}
{% for network in role_networks if not network.startswith('Tenant') %}
- type: vlan
  device: bond_api
  mtu: {{ lookup('vars', networks_lower[network] ~ '_mtu') }}
  vlan_id: {{ lookup('vars', networks_lower[network] ~ '_vlan_id') }}
  addresses:
  - ip_netmask: {{ lookup('vars', networks_lower[network] ~ '_ip') }}/{{ lookup('vars', networks_lower[network] ~ '_cidr') }}
  routes: {{ lookup('vars', networks_lower[network] ~ '_host_routes') }}
{% endfor %}
- type: ovs_bridge
  name: {{ neutron_physical_bridge_name }}
  dns_servers: {{ ctlplane_dns_nameservers }}
  members:
  - type: linux_bond
    name: bond-data
    mtu: {{ min_viable_mtu_dataplane }}
    bonding_options: {{ bond_interface_ovs_options }}
    members:
    - type: interface
      name: nic4
      mtu: {{ min_viable_mtu_dataplane }}
      primary: true
    - type: interface
      name: nic5
      mtu: {{ min_viable_mtu_dataplane }}
{% for network in role_networks if network.startswith('Tenant') %}
  - type: vlan
    device: bond-data
    mtu: {{ lookup('vars', networks_lower[network] ~ '_mtu') }}
    vlan_id: {{ lookup('vars', networks_lower[network] ~ '_vlan_id') }}
    addresses:
    - ip_netmask: {{ lookup('vars', networks_lower[network] ~ '_ip') }}/{{ lookup('vars', networks_lower[network] ~ '_cidr') }}
    routes: {{ lookup('vars', networks_lower[network] ~ '_host_routes') }}

このテンプレートは、5 つのネットワークインターフェイスを使用し、タグ付けされた複数の VLAN デバイスを、番号によるインターフェイスに割り当てます。nic4 および nic5 で、このテンプレートは OVS ブリッジを作成します。

10.5. 追加のオーバークラウドネットワーク設定

本章では、「カスタムネットワークインターフェイステンプレート」で説明した概念および手順に続いて、オーバークラウドネットワークの要素を設定する際に役立つその他の情報を提供します。

10.5.1. カスタムインターフェイスの設定

インターフェイスは個別に変更を加える必要がある場合があります。以下の例では、DHCP アドレスを使用してインフラストラクチャーネットワークに接続するための 2 つ目の NIC およびボンディング用に別の NIC を使用するのに必要となる変更を紹介します。

network_config:
  # Add a DHCP infrastructure network to nic2
  - type: interface
    name: nic2
    mtu: {{ tenant_mtu }}
    use_dhcp: true
    primary: true
  - type: vlan
    mtu: {{ tenant_mtu }}
    vlan_id: {{ tenant_vlan_id }}
    addresses:
    - ip_netmask: {{ tenant_ip }}/{{ tenant_cidr }}
    routes: {{ [tenant_host_routes] | flatten | unique }}
  - type: ovs_bridge
    name: br-bond
    mtu: {{ external_mtu }}
    dns_servers: {{ ctlplane_dns_nameservers }}
    use_dhcp: false
    members:
      - type: interface
        name: nic10
        mtu: {{ external_mtu }}
        use_dhcp: false
        primary: true
      - type: vlan
        mtu: {{ external_mtu }}
        vlan_id: {{ external_vlan_id }}
        addresses:
        - ip_netmask: {{ external_ip }}/{{ external_cidr }}
        routes: {{ [external_host_routes, [{'default': True, 'next_hop': external_gateway_ip}]] | flatten | unique }}

ネットワークインターフェイスのテンプレートは、実際のインターフェイス名 (eth0eth1enp0s25) または番号付きのインターフェイス (nic1nic2nic3) のいずれかを使用します。名前付きのインターフェイス (eth0eno2 など) ではなく、番号付きのインターフェイス (nic1nic2 など) を使用した場合には、ロール内のホストのネットワークインターフェイスは、全く同じである必要はありません。たとえば、あるホストに em1em2 のインターフェイスが指定されており、別のホストには eno1eno2 が指定されていても、両ホストの NIC は nic1 および nic2 として参照することができます。

番号付きのインターフェイスの順序は、名前付きのネットワークインターフェイスのタイプの順序と同じです。

  • eth0eth1 などの ethX。これらは、通常オンボードのインターフェイスです。
  • eno0eno1 などの enoX。これらは、通常オンボードのインターフェイスです。
  • enp3s0enp3s1ens3 などの英数字順の enX インターフェイス。これらは、通常アドオンのインターフェイスです。

番号による NIC スキームには、アクティブなインターフェイスだけが含まれます (たとえば、インターフェイスにスイッチに接続されたケーブルがあるかどうかが考慮されます)。4 つのインターフェイスを持つホストと、6 つのインターフェイスを持つホストがある場合は、nic1 から nic4 を使用して各ホストで 4 本のケーブルだけを結線します。

事前にプロビジョニングされたノードの NIC マッピングのカスタマイズ

事前にプロビジョニングされたノードを使用している場合は、環境ファイルで NetConfigDataLookup heat パラメーターを設定することで、特定ノードの os-net-config マッピングを指定できます。

注記

NetConfigDataLookup heat パラメーターの設定は、ノード定義ファイル overcloud-baremetal-deploy.yamlnet_config_data_lookup プロパティーと同等です。事前にプロビジョニングされたノードを使用していない場合は、ノード定義ファイルで NIC マッピングを設定する必要があります。net_config_data_lookup プロパティーの設定の詳細については、ベアメタルノードのプロビジョニング属性 を参照してください。

各ノードの物理インターフェイスにエイリアスを割り当てて、nic1nic2 などの特定のエイリアスにマッピングする物理 NIC を事前に定義したり、MAC アドレスを特定のエイリアスにマッピングしたりできます。MAC アドレスまたは DMI キーワードを使用して特定のノードをマップしたり、DMI キーワードを使用してノードのグループをマップしたりできます。次の例では、物理インターフェイスへのエイリアスを持つ 3 つのノードと 2 つのノードグループを設定します。得られた設定は、os-net-config により適用されます。これぞれのノードで、適用された設定が /etc/os-net-config/mapping.yaml ファイルの interface_mapping セクションに表示されます。

os-net-config-mappings.yaml

NetConfigDataLookup:
  node1: 1
    nic1: "00:c8:7c:e6:f0:2e"
  node2:
    nic1: "00:18:7d:99:0c:b6"
  node3: 2
    dmiString: "system-uuid" 3
    id: 'A8C85861-1B16-4803-8689-AFC62984F8F6'
    nic1: em3
  # Dell PowerEdge
  nodegroup1: 4
    dmiString: "system-product-name"
    id: "PowerEdge R630"
    nic1: em3
    nic2: em1
    nic3: em2
  # Cisco UCS B200-M4"
  nodegroup2:
    dmiString: "system-product-name"
    id: "UCSB-B200-M4"
    nic1: enp7s0
    nic2: enp6s0

1
指定の MAC アドレスに node1 をマップし、このノードの MAC アドレスのエイリアスとして nic1 を割り当てます。
2
node3 をシステムUUID "A8C85861-1B16-4803-8689-AFC62984F8F6" を持つノードにマップし、このノード上の em3 インターフェイスのエイリアスとして nic1 を割り当てます。
3
dmiString パラメーターは有効な文字列キーワードに設定する必要があります。有効な文字列キーワードのリストは、DMIDECODE(8) のマニュアルページを参照してください。
4
nodegroup1 内のすべてのノードを製品名 PowerEdge R630 のノードにマップし、これらのノード上の名前付きインターフェイスのエイリアスとして nic1nic2、および nic3 を割り当てます。
注記

通常、os-net-config はすでに接続済みの UP 状態のインターフェイスしか登録しません。ただし、カスタムマッピングファイルを使用してインターフェイスをハードコーディングすると、DOWN 状態のインターフェイスであっても登録されます。

10.5.2. ルートおよびデフォルトルートの設定

ホストのデフォルトルートは、2 つの方法のどちらかで設定することができます。インターフェイスが DHCP を使用しており、DHCP サーバーがゲートウェイアドレスを提供している場合には、システムはそのゲートウェイのデフォルトルートを使用します。それ以外の場合には、固定 IP が指定されたインターフェイスにデフォルトのルートを設定することができます。

Linux カーネルは複数のデフォルトゲートウェイをサポートしますが、最も低いメトリックのゲートウェイだけを使用します。複数の DHCP インターフェイスがある場合には、どのデフォルトゲートウェイが使用されるかが推測できなくなります。このような場合には、デフォルトルートを使用しないインターフェイスに defroute: false を設定することを推奨します。

たとえば、DHCP インターフェイス (nic3) をデフォルトのルートに指定する場合があります。そのためには、以下の YAML スニペットを使用して別の DHCP インターフェイス (nic2) 上のデフォルトルートを無効にします。

# No default route on this DHCP interface
- type: interface
  name: nic2
  use_dhcp: true
  defroute: false
# Instead use this DHCP interface as the default route
- type: interface
  name: nic3
  use_dhcp: true
注記

defroute パラメーターは、DHCP で取得したルートにのみ適用されます。

固定 IP が指定されたインターフェイスに静的なルートを設定するには、サブネットへのルートを指定します。たとえば、Internal API ネットワーク上のゲートウェイ 172.17.0.1 を経由するサブネット 10.1.2.0/24 にルートを設定します。

    - type: vlan
      device: bond1
      vlan_id: 9
      addresses:
      - ip_netmask: 172.17.0.100/16
      routes:
      - ip_netmask: 10.1.2.0/24
        next_hop: 172.17.0.1

10.5.3. ポリシーベースのルーティングの設定

コントローラーノードで、異なるネットワークからの無制限のアクセスを設定するには、ポリシーベースのルーティングを設定します。複数のインターフェイスを持つホストでは、ポリシーベースのルーティングはルーティングテーブルを使用し、送信元のアドレスに応じて特定のインターフェイス経由でトラフィックを送信することができます。送信先が同じであっても、異なる送信元からのパケットを異なるネットワークにルーティングすることができます。

たとえば、デフォルトのルートが External ネットワークの場合でも、パケットの送信元アドレスに基づいてトラフィックを Internal API ネットワークに送信するようにルートを設定することができます。インターフェイスごとに特定のルーティングルールを定義することもできます。

Red Hat OpenStack Platform では os-net-config ツールを使用してオーバークラウドノードのネットワーク属性を設定します。os-net-config ツールは、コントローラーノードの以下のネットワークルーティングを管理します。

  • /etc/iproute2/rt_tables ファイルのルーティングテーブル
  • /etc/sysconfig/network-scripts/rule-{ifname} ファイルの IPv4 ルール
  • /etc/sysconfig/network-scripts/rule6-{ifname} ファイルの IPv6 ルール
  • /etc/sysconfig/network-scripts/route-{ifname} のルーティングテーブル固有のルート

前提条件

  • アンダークラウドが正常にインストールされていること。詳しい情報は、Director のインストールと使用方法director のインストール を参照してください。

手順

  1. /home/stack/templates/custom-nics ディレクトリーからのカスタム NIC テンプレートに interface エントリーを作成し、インターフェイスのルートを定義し、デプロイメントに関連するルールを定義します。

      network_config:
      - type: interface
        name: em1
        use_dhcp: false
        addresses:
          - ip_netmask: {{ external_ip }}/{{ external_cidr}}
        routes:
          - default: true
            next_hop: {{ external_gateway_ip }}
          - ip_netmask: {{ external_ip }}/{{ external_cidr}}
            next_hop: {{ external_gateway_ip }}
            route_table: 2
            route_options: metric 100
        rules:
          - rule: "iif em1 table 200"
            comment: "Route incoming traffic to em1 with table 200"
          - rule: "from 192.0.2.0/24 table 200"
            comment: "Route all traffic from 192.0.2.0/24 with table 200"
          - rule: "add blackhole from 172.19.40.0/24 table 200"
          - rule: "add unreachable iif em1 from 192.168.1.0/24"
  2. ご自分のデプロイメントに該当するその他の環境ファイルと共に、カスタム NIC 設定およびネットワーク環境ファイルをデプロイメントコマンドに追加します。

    $ openstack overcloud deploy --templates \
    -e /home/stack/templates/<custom-nic-template>
    -e <OTHER_ENVIRONMENT_FILES>

検証

  • コントローラーノードで以下のコマンドを入力して、ルーティング設定が正しく機能していることを確認します。

    $ cat /etc/iproute2/rt_tables
    $ ip route
    $ ip rule

10.5.4. ジャンボフレームの設定

最大伝送単位 (MTU) の設定は、単一の Ethernet フレームで転送されるデータの最大量を決定します。各フレームはヘッダー形式でデータを追加するため、より大きい値を指定すると、オーバーヘッドが少なくなります。デフォルト値が 1500 で、1500 より高い値を使用する場合には、ジャンボフレームをサポートするスイッチポートの設定が必要になります。大半のスイッチは、9000 以上の MTU 値をサポートしていますが、それらの多くはデフォルトで 1500 に指定されています。

VLAN の MTU は、物理インターフェイスの MTU を超えることができません。ボンディングまたはインターフェイスで MTU 値を含めるようにしてください。

ジャンボフレームは、Storage、Storage Management、Internal API、Tenant ネットワークのすべてにメリットをもたらします。

jinja2 テンプレートまたは network_data.yaml ファイルで mtu の値を変更できます。network_data.yaml ファイルに値を設定すると、デプロイ中にレンダリングされます。

警告

ルーターは、通常レイヤー 3 の境界を超えてジャンボフレームでのデータを転送することができません。接続性の問題を回避するには、プロビジョニングインターフェイス、外部インターフェイス、および Floating IP インターフェイスのデフォルト MTU を変更しないでください。

---
{% set mtu_list = [ctlplane_mtu] %}
{% for network in role_networks %}
{{ mtu_list.append(lookup('vars', networks_lower[network] ~ '_mtu')) }}
{%- endfor %}
{% set min_viable_mtu = mtu_list | max %}
network_config:
- type: ovs_bridge
  name: bridge_name
  mtu: {{ min_viable_mtu }}
  use_dhcp: false
  dns_servers: {{ ctlplane_dns_nameservers }}
  domain: {{ dns_search_domains }}
  addresses:
  - ip_netmask: {{ ctlplane_ip }}/{{ ctlplane_subnet_cidr }}
  routes: {{ [ctlplane_host_routes] | flatten | unique }}
  members:
  - type: interface
    name: nic1
    mtu: {{ min_viable_mtu }}
    primary: true
  - type: vlan
    mtu: 9000  1
    vlan_id: {{ storage_vlan_id }}
    addresses:
    - ip_netmask: {{ storage_ip }}/{{ storage_cidr }}
    routes: {{ [storage_host_routes] | flatten | unique }}
  - type: vlan
    mtu: {{ storage_mgmt_mtu }} 2
    vlan_id: {{ storage_mgmt_vlan_id }}
    addresses:
    - ip_netmask: {{ storage_mgmt_ip }}/{{ storage_mgmt_cidr }}
    routes: {{ [storage_mgmt_host_routes] | flatten | unique }}
  - type: vlan
    mtu: {{ internal_api_mtu }}
    vlan_id: {{ internal_api_vlan_id }}
    addresses:
    - ip_netmask: {{ internal_api_ip }}/{{ internal_api_cidr }}
    routes: {{ [internal_api_host_routes] | flatten | unique }}
  - type: vlan
    mtu: {{ tenant_mtu }}
    vlan_id: {{ tenant_vlan_id }}
    addresses:
    - ip_netmask: {{ tenant_ip }}/{{ tenant_cidr }}
    routes: {{ [tenant_host_routes] | flatten | unique }}
  - type: vlan
    mtu: {{ external_mtu }}
    vlan_id: {{ external_vlan_id }}
    addresses:
    - ip_netmask: {{ external_ip }}/{{ external_cidr }}
    routes: {{ [external_host_routes, [{'default': True, 'next_hop': external_gateway_ip}]] | flatten | unique }}
1
jinja2 テンプレートで直接更新される mtu 値。
2
mtu 値は、デプロイ中に network_data.yaml ファイルから取得されます。

10.5.5. ジャンボフレームを細分化するための ML2/OVN ノースバウンドパス MTU 検出の設定

Internal ネットワーク上の仮想マシンがジャンボフレームを External ネットワークに送信する場合、Internal ネットワークの最大伝送単位 (MTU) が External ネットワークの MTU より大きいと、ノースバウンドフレームが External ネットワークの容量を容易に超過してしまいます。

ML2/OVS はこのオーバーサイズパケットの問題を自動的に処理し、ML2/OVN は TCP パケットについてこの問題を自動的に処理します。

ただし、ML2/OVN メカニズムドライバーを使用するデプロイメントで、オーバーズのノースバウンド UDP パケットを適切に処理するには、追加の設定手順を実施する必要があります。

以下の手順により、ML2/OVN ルーターが ICMP の fragmentation needed パケットを送信元の仮想マシンに返すように設定します。この場合、送信元アプリケーションはペイロードをより小さなパケットに分割することができます。

注記

East-West トラフィックでは、RHOSP ML2/OVN デプロイメント は East-West パスの最少 MTU を超えるパケットの断片化をサポートしていません。以下に例を示します。

  • VM1 は、MTU が 1300 に設定された Network1 上にある。
  • VM2 は、MTU が 1200 に設定された Network2 上にある。
  • サイズが 1171 以下の VM1/VM2 間の ping は、どちらの方向も成功します。サイズが 1171 を超える ping は、100% パケットロスになります。

    このタイプの断片化に対するお客様の要件が特定されていないため、Red Hat はサポートを追加する予定はありません。

手順

  1. ml2_conf.ini の ovn セクションに次の値を設定します。

    ovn_emit_need_to_frag = True

10.5.6. トランキングされたインターフェイスでのネイティブ VLAN の設定

トランキングされたインターフェイスまたはボンディングに、ネイティブ VLAN を使用したネットワークがある場合には、IP アドレスはブリッジに直接割り当てられ、VLAN インターフェイスはありません。

次の例では、External ネットワークがネイティブ VLAN 上にあるボンディングインターフェイスを設定します。

network_config:
- type: ovs_bridge
  name: br-ex
  addresses:
  - ip_netmask: {{ external_ip }}/{{ external_cidr }}
  routes: {{ external_host_routes }}
  members:
  - type: ovs_bond
    name: bond1
    ovs_options: {{ bond_interface_ovs_options }}
    members:
    - type: interface
      name: nic3
      primary: true
    - type: interface
      name: nic4
注記

アドレスまたはルートのステートメントをブリッジに移動する場合は、対応する VLAN インターフェイスをそのブリッジから削除します。該当する全ロールに変更を加えます。External ネットワークはコントローラーのみに存在するため、変更する必要があるのはコントローラーのテンプレートだけです。Storage ネットワークは全ロールにアタッチされているため、Storage ネットワークがデフォルトの VLAN の場合には、全ロールを変更する必要があります。

10.5.7. netfilter が追跡する接続の最大数を増やす

Red Hat OpenStack Platform (RHOSP) Networking サービス (neutron) は、netfilter 接続追跡を使用してステートフルファイアウォールを構築し、仮想ネットワークでネットワークアドレス変換 (NAT) を提供します。カーネルスペースが最大接続制限に達し、nf_conntrack: table full, dropping packet などのエラーが発生する状況がいくつかあります。接続追跡 (conntrack) の制限を増やして、これらのタイプのエラーを回避できます。RHOSP デプロイメントで、1 つ以上のロール、またはすべてのノードの conntrack 制限を増やすことができます。

前提条件

  • RHOSP アンダークラウドのインストールが成功しました。

手順

  1. アンダークラウドホストに stack ユーザーとしてログインします。
  2. source コマンドでアンダークラウドの認証情報ファイルを読み込みます。

    $ source ~/stackrc
  3. カスタム YAML 環境ファイルを作成します。

    $ vi /home/stack/templates/custom-environment.yaml

  4. 環境ファイルには、キーワード parameter_defaults および ExtraSysctlSettings が含まれている必要があります。netfilter が追跡できる接続の最大数の新しい値を変数 net.nf_conntrack_max に入力します。

    この例では、RHOSP デプロイメント内のすべてのホストにわたって conntrack 制限を設定できます。

    parameter_defaults:
      ExtraSysctlSettings:
        net.nf_conntrack_max:
          value: 500000

    <role>Parameter パラメーターを使用して、特定のロールの conntrack 制限を設定します。

    parameter_defaults:
      <role>Parameters:
        ExtraSysctlSettings:
          net.nf_conntrack_max:
            value: <simultaneous_connections>
    • <role> をロールの名前に置き換えます。

      たとえば、ControllerParameters を使用して Controller ロールの conntrack 制限を設定するか、ComputeParameters を使用して Compute ロールの conntrack 制限を設定します。

    • <simultaneous_connections> を、許可する同時接続数に置き換えます。

      この例では、RHOSP デプロイメントの Controller ロールのみに conntrack 制限を設定できます。

      parameter_defaults:
        ControllerParameters:
          ExtraSysctlSettings:
            net.nf_conntrack_max:
              value: 500000
      注記

      net.nf_conntrack_max のデフォルト値は 500000 接続です。最大値は 4294967295 です。

  5. コア heat テンプレート、環境ファイル、およびこの新しいカスタム環境ファイルを指定して、deployment コマンドを実行します。

    重要

    後で実行される環境ファイルで定義されているパラメーターとリソースが優先されることになるため、環境ファイルの順序は重要となります。

    $ openstack overcloud deploy --templates \
    -e /home/stack/templates/custom-environment.yaml

関連情報

10.6. ネットワークインターフェイスボンディング

カスタムネットワーク設定では、さまざまなボンディングオプションを使用することができます。

10.6.1. オーバークラウドノードのネットワークインターフェイスボンディング

複数の物理 NIC をバンドルして、単一の論理チャネルを形成することができます。この設定はボンディングとも呼ばれます。ボンディングを設定して、高可用性システム用の冗長性またはスループットの向上を実現することができます。

Red Hat OpenStack Platform では、Open vSwitch (OVS) カーネルボンディング、OVS-DPDK ボンディング、および Linux カーネルボンディングがサポートされます。

表10.10 サポート対象のインターフェイスボンディングの種別

ボンディング種別種別の値許可されるブリッジ種別許可されるメンバー

OVS カーネルボンディング

ovs_bond

ovs_bridge

interface

OVS-DPDK ボンディング

ovs_dpdk_bond

ovs_user_bridge

ovs_dpdk_port

Linux カーネルボンディング

linux_bond

ovs_bridge または linux_bridge

interface

重要

ovs_bridgeovs_user_bridge を同じノード上で組み合わせないでください。

10.6.2. Open vSwitch (OVS) ボンディングの作成

ネットワークインターフェイステンプレートで OVS ボンディングを作成します。たとえば、OVS ユーザースペースブリッジの一部としてボンディングを作成できます。

- type: ovs_user_bridge
  name: br-dpdk0
  members:
  - type: ovs_dpdk_bond
    name: dpdkbond0
    rx_queue: {{ num_dpdk_interface_rx_queues }}
    members:
    - type: ovs_dpdk_port
      name: dpdk0
      members:
      - type: interface
        name: nic4
    - type: ovs_dpdk_port
      name: dpdk1
      members:
      - type: interface
        name: nic5

以下の例では、2 つの DPDK ポートからボンディングを作成します。

ovs_options パラメーターには、ボンディングオプションが含まれます。ネットワーク環境ファイルの BondInterfaceOvsOptions パラメーターを使用して、ボンディングオプションを設定することができます。

environment_parameters:
  BondInterfaceOvsOptions: "bond_mode=active_backup"

10.6.3. Open vSwitch (OVS) 結合オプション

NIC テンプレートファイルの ovs_options heat パラメーターを使用して、さまざまな Open vSwitch (OVS) ボンディングオプションを設定することができます。

bond_mode=balance-slb
送信元負荷分散 (slb) は、送信元 MAC アドレスと出力 VLAN に基づいてフローのバランスを取り、トラフィックパターンの変化に応じて定期的に再調整します。balance-slb ボンディングオプションを使用して結合を設定する場合は、リモートスイッチで必要な設定はありません。Networking サービス (neutron) は、ソース MAC と VLAN の各ペアをリンクに割り当て、その MAC と VLAN からのすべてのパケットをそのリンクを介して送信します。トラフィックパターンの変化に応じて定期的にリバランスを行う、送信元 MAC アドレスと VLAN の番号に基づいた簡単なハッシュアルゴリズム。balance-slb モードは、Linux ボンディングドライバーで使用されるモード 2 ボンドに似ています。このモードを使用すると、スイッチが LACP を使用するように設定されていない場合でも、負荷分散機能を有効にすることができます。
bond_mode=active-backup
active-backup ボンドモードを使用してボンドを設定すると、Networking サービスは 1 つの NIC をスタンバイ状態に保ちます。アクティブな接続に障害が発生すると、スタンバイ NIC がネットワーク操作を再開します。物理スイッチに提示される MAC アドレスは 1 つのみです。このモードはスイッチ設定を必要とせず、リンクが別のスイッチに接続されている場合に機能します。このモードは、負荷分散機能は提供しません。
lacp=[active | passive | off]
Link Aggregation Control Protocol (LACP) の動作を制御します。LACP をサポートしているのは特定のスイッチのみです。お使いのスイッチが LACP に対応していない場合には bond_mode=balance-slb または bond_mode=active-backup を使用してください。
other-config:lacp-fallback-ab=true
LACP が失敗した場合は、ボンドモードとしてアクティブバックアップを設定します。
other_config:lacp-time=[fast | slow]
LACP のハートビートを 1 秒 (高速) または 30 秒 (低速) に設定します。デフォルトは低速です。
other_config:bond-detect-mode=[miimon | carrier]
リンク検出に miimon ハートビート (miimon) またはモニターキャリア (carrier) を設定します。デフォルトは carrier です。
other_config:bond-miimon-interval=100
miimon を使用する場合には、ハートビートの間隔をミリ秒単位で設定します。
bond_updelay=1000
フラッピングを防止するためにリンクがアクティブになっている必要がある間隔 (ミリ秒) を設定します。
other_config:bond-rebalance-interval=10000
ボンドメンバー間でフローがリバランスする間隔 (ミリ秒) を設定します。この値をゼロに設定すると、ボンドメンバー間のフローのリバランスが無効になります。

10.6.5. Linux ボンディングの作成

ネットワークインターフェイステンプレートで linux ボンディングを作成します。たとえば、2 つのインターフェイスをボンディングする linux ボンディングを作成することができます。

- type: linux_bond
  name: bond_api
  mtu: {{ min_viable_mtu_ctlplane }}
  use_dhcp: false
  bonding_options: {{ bond_interface_ovs_options }}
  dns_servers: {{ ctlplane_dns_nameservers }}
  domain: {{ dns_search_domains }}
  members:
  - type: interface
    name: nic2
    mtu: {{ min_viable_mtu_ctlplane }}
    primary: true
  - type: interface
    name: nic3
    mtu: {{ min_viable_mtu_ctlplane }}

bonding_options パラメーターは、Linux ボンディング用の特定のボンディングオプションを設定します。

モード
ボンディングモードを設定します。この例では、802.3ad モードまたは LACP モードです。Linux ボンディングモードの詳細は、Red Hat Enterprise Linux 9 ネットワークの設定と管理ガイドの ボンディングモードに応じたアップストリームの切り替え設定 を参照してください。
lacp_rate
LACP パケットの送信間隔を 1 秒または 30 秒に定義します。
updelay
インターフェイスをトラフィックに使用する前にそのインターフェイスがアクティブである必要のある最低限の時間を定義します。この最小設定は、ポートフラッピングによる停止を軽減するのに役立ちます。
miimon
ドライバーの MIIMON 機能を使用してポートの状態を監視する間隔 (ミリ秒単位)

以下の追加の例をガイドとして使用し、独自の Linux ボンディングを設定します。

  • 1 つの VLAN を持つ active-backup モードに設定された Linux ボンディング

    ....
    
    - type: linux_bond
      name: bond_api
      mtu: {{ min_viable_mtu_ctlplane }}
      use_dhcp: false
      bonding_options: "mode=active-backup"
      dns_servers: {{ ctlplane_dns_nameservers }}
      domain: {{ dns_search_domains }}
      members:
      - type: interface
        name: nic2
        mtu: {{ min_viable_mtu_ctlplane }}
        primary: true
      - type: interface
        name: nic3
        mtu: {{ min_viable_mtu_ctlplane }}
      - type: vlan
        mtu: {{ internal_api_mtu }}
        vlan_id: {{ internal_api_vlan_id }}
        addresses:
        - ip_netmask:
            {{ internal_api_ip }}/{{ internal_api_cidr }}
          routes:
            {{ internal_api_host_routes }}
  • OVS ブリッジ上の Linux ボンディング。1 つの VLAN を持つ 802.3ad LACP モードに設定されたボンディング

    - type: linux_bond
      name: bond_tenant
      mtu: {{ min_viable_mtu_ctlplane }}
      bonding_options: "mode=802.3ad updelay=1000 miimon=100"
      use_dhcp: false
      dns_servers: {{ ctlplane_dns_nameserver }}
      domain: {{ dns_search_domains }}
      members:
        - type: interface
          name: p1p1
          mtu: {{ min_viable_mtu_ctlplane }}
        - type: interface
          name: p1p2
          mtu: {{ min_viable_mtu_ctlplane }}
        - type: vlan
          mtu: {{ tenant_mtu }}
          vlan_id: {{ tenant_vlan_id }}
          addresses:
            - ip_netmask:
               {{ tenant_ip }}/{{ tenant_cidr }}
          routes:
            {{ tenant_host_routes }}
    重要

    min_viable_mtu_ctlplane を使用する前に、設定する必要があります。/usr/share/ansible/roles/tripleo_network_config/templates/2_linux_bonds_vlans.j2 をテンプレートディレクトリーにコピーし、必要に応じて変更します。詳細は、コンポーザブルネットワークの追加 を参照し、ネットワーク設定テンプレートに関連する手順を参照してください。

10.7. ネットワーク設定ファイルのフォーマットの更新

Red Hat OpenStack Platform (RHOSP) 17.0 では、ネットワーク設定の yaml ファイルの形式が変更されました。ネットワーク設定ファイル network_data.yaml の構造が変更され、NIC テンプレートファイルの形式が yaml ファイル形式から Jinja2 ansible 形式の j2 に変更されました。

次の変換ツールを使用して、現在の展開の既存のネットワーク設定ファイルを RHOSP 17+ 形式に変換できます。

  • convert_v1_net_data.py
  • convert_heat_nic_config_to_ansible_j2.py

既存の NIC テンプレートファイルを手動で変換することもできます。

変換する必要があるファイルは次のとおりです。

  • network_data.yaml
  • コントローラー NIC テンプレート
  • コンピュート NIC テンプレート
  • その他のカスタムネットワークファイル

10.7.1. ネットワーク設定ファイルのフォーマットの更新

Red Hat OpenStack Platform (RHOSP) 17.0 では、ネットワーク設定 yaml ファイルの形式が変更されました。convert_v1_net_data.py 変換ツールを使用して、現在のデプロイメントの既存のネットワーク設定ファイルを RHOSP 17+ 形式に変換できます。

手順

  1. 変換ツールをダウンロードします。

    • /usr/share/openstack-tripleo-heat-templates/tools/convert_v1_net_data.py
  2. RHOSP 16+ ネットワーク設定ファイルを RHOSP 17+ 形式に変換します。

    $ python3 convert_v1_net_data.py <network_config>.yaml
    • <network_config> は、変換する既存の設定ファイルの名前 (network_data.yaml など) に置き換えます。

10.7.2. NIC テンプレートの Jinja2 Ansible 形式への自動変換

Red Hat OpenStack Platform (RHOSP) 17.0 では、NIC テンプレートのファイル形式が yaml ファイル形式から Jinja2 Ansible 形式の j2 に変更されました。

convert_heat_nic_config_to_ansible_j2.py 変換ツールを使用して、現在のデプロイの既存の NIC テンプレートファイルを Jinja2 形式に変換できます。

既存の NIC テンプレートファイルを手動で変換することもできます。詳細は、NIC テンプレートの Jinja2 Ansible 形式への手動変換 を参照してください。

変換する必要があるファイルは次のとおりです。

  • コントローラー NIC テンプレート
  • コンピュート NIC テンプレート
  • その他のカスタムネットワークファイル

手順

  1. 変換ツールをダウンロードします。

    • /usr/share/openstack-tripleo-heat-templates/tools/convert_heat_nic_config_to_ansible_j2.py
  2. コンピュートとコントローラーの NIC テンプレートファイル、およびその他のカスタムネットワークファイルを Jinja2 Ansible 形式に変換します。

    $ python3 convert_heat_nic_config_to_ansible_j2.py \
     [--stack <overcloud> | --standalone] --networks_file <network_config.yaml> \
     <network_template>.yaml
    • <overcloud> は、オーバークラウドスタックの名前または UUID に置き換えてください。--stack が指定されていない場合、スタックはデフォルトで overcloud になります。

      注記

      --stack オプションは、アンダークラウドノードでオーケストレーションサービス (heat) を実行する必要があるため、RHOSP 16 デプロイメントでのみ使用できます。RHOSP 17 以降、RHOSP デプロイメントは、コンテナー内でオーケストレーションサービスを実行する一時的な Heat を使用します。オーケストレーションサービスが利用できない場合、またはスタックがない場合は、--stack の代わりに --standalone オプションを使用します。

    • <network_config.yaml> は、ネットワークデプロイを記述する設定ファイルの名前 (network_data.yaml など) に置き換えます。
    • <network_template> は、変換するネットワーク設定ファイルの名前に置き換えます。

    すべてのカスタムネットワーク設定ファイルを変換するまで、このコマンドを繰り返します。convert_heat_nic_config_to_ansible_j2.py スクリプトは、変換用に渡す yaml ごとに .j2 ファイルを生成します。

  3. 生成された各 .j2 ファイルを検査して、設定が環境に対して正しく、また完全であることを確認します。次に、手動で、変換できなかった設定を強調表示するツールが生成したコメントに、手動で対応します。NIC 設定を Jinja2 形式に手動で変換する方法は、Heat パラメーターから Ansible 変数へのマッピング を参照してください。
  4. 生成された .j2 ファイルを指すように、network-environment.yaml ファイルの *NetworkConfigTemplate パラメーターを設定します。

    parameter_defaults:
      ControllerNetworkConfigTemplate: '/home/stack/templates/custom-nics/controller.j2'
      ComputeNetworkConfigTemplate: '/home/stack/templates/custom-nics/compute.j2'
  5. 古いネットワーク設定ファイルの network-environment.yaml ファイルから resource_registry マッピングを削除します。

    resource_registry:
      OS::TripleO::Compute::Net::SoftwareConfig: /home/stack/templates/nic-configs/compute.yaml
      OS::TripleO::Controller::Net::SoftwareConfig: /home/stack/templates/nic-configs/controller.yaml

10.7.3. NIC テンプレートの Jinja2 Ansible 形式への手動変換

Red Hat OpenStack Platform (RHOSP) 17.0 では、NIC テンプレートのファイル形式が yaml ファイル形式から Jinja2 Ansible 形式の j2 に変更されました。

既存の NIC テンプレートファイルを手動で変換できます。

convert_heat_nic_config_to_ansible_j2.py 変換ツールを使用して、現在のデプロイの既存の NIC テンプレートファイルを Jinja2 形式に変換することもできます。詳細は、NIC テンプレートの Jinja2 ansible 形式への自動変換 を参照してください。

変換する必要があるファイルは次のとおりです。

  • コントローラー NIC テンプレート
  • コンピュート NIC テンプレート
  • その他のカスタムネットワークファイル

手順

  1. Jinja2 テンプレートを作成します。os-net-config スキーマを使用して新しいテンプレートを作成するか、アンダークラウドノードの /usr/share/ansible/roles/tripleo_network_config/templates/ ディレクトリーからサンプルテンプレートをコピーして編集できます。
  2. Heat 固有の関数は、Jinja2 フィルターに置き換えます。たとえば、次のフィルターを使用して min_viable_mtu を計算します。

    {% set mtu_list = [ctlplane_mtu] %}
    {% for network in role_networks %}
    {{ mtu_list.append(lookup('vars', networks_lower[network] ~ '_mtu')) }}
    {%- endfor %}
    {% set min_viable_mtu = mtu_list | max %}
  3. Ansible 変数を使用して、デプロイメントのネットワークプロパティーを設定します。個々のネットワークを手動で設定するか、role_networks を反復して各ネットワークをプログラムで設定できます。

    • 各ネットワークを手動で設定するには、各 get_param 関数を同等の Ansible 変数に置き換えます。たとえば、現在のデプロイで get_param: InternalApiNetworkVlanID を使用して vlan_id を設定している場合は、次の設定をテンプレートに追加します。

      vlan_id: {{ internal_api_vlan_id }}

      表10.12 heat パラメーターから Ansible vars へのネットワークプロパティーマッピングの例

      yaml ファイル形式Jinja2 ansible 形式、j2
      - type: vlan
        device: nic2
        vlan_id:
          get_param: InternalApiNetworkVlanID
        addresses:
        - ip_netmask:
            get_param: InternalApiIpSubnet
      - type: vlan
        device: nic2
        vlan_id: {{ internal_api_vlan_id }}
        addresses:
        - ip_netmask: {{ internal_api_ip }}/{{ internal_api_cidr }}
    • 各ネットワークをプログラムで設定するには、role_networks を使用してロール名で使用可能なネットワークを取得するテンプレートに、Jinja2 for-loop 構造を追加します。

      {% for network in role_networks %}
        - type: vlan
          mtu: {{ lookup('vars', networks_lower[network] ~ '_mtu') }}
          vlan_id: {{ lookup('vars', networks_lower[network] ~ '_vlan_id') }}
          addresses:
          - ip_netmask: {{ lookup('vars', networks_lower[network] ~ '_ip') }}/{{ lookup('vars', networks_lower[network] ~ '_cidr') }}
          routes: {{ lookup('vars', networks_lower[network] ~ '_host_routes') }}
      {%- endfor %}

    heat パラメーターから同等の Ansible vars へのマッピングの全リストについては、Heat パラメーターから Ansible 変数へのマッピング を参照してください。

  4. 生成された .j2 ファイルを指すように、network-environment.yaml ファイルの *NetworkConfigTemplate パラメーターを設定します。

    parameter_defaults:
      ControllerNetworkConfigTemplate: '/home/stack/templates/custom-nics/controller.j2'
      ComputeNetworkConfigTemplate: '/home/stack/templates/custom-nics/compute.j2'
  5. 古いネットワーク設定ファイルの network-environment.yaml ファイルから resource_registry マッピングを削除します。

    resource_registry:
      OS::TripleO::Compute::Net::SoftwareConfig: /home/stack/templates/nic-configs/compute.yaml
      OS::TripleO::Controller::Net::SoftwareConfig: /home/stack/templates/nic-configs/controller.yaml

10.7.4. Heat パラメーターから Ansible 変数へのマッピング

Red Hat OpenStack Platform (RHOSP) 17.0 では、NIC テンプレートのファイル形式が yaml ファイル形式から Jinja2 ansible 形式の j2 に変更されました。

既存の NIC テンプレートファイルを手動で Jinja2 ansible 形式に変換するには、heat パラメーターを Ansible 変数にマッピングして、デプロイメントで事前にプロビジョニングされたノードのネットワークプロパティーを設定します。--network-config オプションの引数を指定せずに openstack overcloud node provision を実行すると、heat パラメーターを Ansible 変数にマップすることもできます。

たとえば、現在のデプロイで get_param: InternalApiNetworkVlanID を使用して vlan_id を設定している場合は、新しい Jinja2 テンプレートで次の設定に置き換えます。

vlan_id: {{ internal_api_vlan_id }}
注記

--network-config オプションの引数を指定して openstack overcloud node provision を実行してノードをプロビジョニングする場合は、overcloud-baremetal-deploy.yaml のパラメーターを使用して、デプロイ用のネットワークプロパティーを設定する必要があります。詳細は、Heat パラメーターによる定義ファイルマッピングのプロビジョニング を 参照してください。

次の表は、heat パラメーターから同等の Ansible vars へのマッピングで利用できるものを一覧にしています。

表10.13 heat パラメーターから Ansible vars へのマッピング

Heat パラメーターAnsible vars

BondInterfaceOvsOptions

{{ bond_interface_ovs_options }}

ControlPlaneIp

{{ ctlplane_ip }}

ControlPlaneDefaultRoute

{{ ctlplane_gateway_ip }}

ControlPlaneMtu

{{ ctlplane_mtu }}

ControlPlaneStaticRoutes

{{ ctlplane_host_routes }}

ControlPlaneSubnetCidr

{{ ctlplane_subnet_cidr }}

DnsSearchDomains

{{ dns_search_domains }}

DnsServers

{{ ctlplane_dns_nameservers }}

注記

この Ansible 変数には、DEFAULT/undercloud_nameservers および %SUBNET_SECTION%/dns_nameserversundercloud.conf で設定された IP アドレスが入力されます。%SUBNET_SECTION%/dns_nameservers の設定は、DEFAULT/undercloud_nameservers の設定を上書きします。これにより、アンダークラウドおよびオーバークラウドに異なる DNS サーバーを使用し、異なるプロビジョニングサブネットのノードに異なる DNS サーバーを使用することができます。

NumDpdkInterfaceRxQueues

{{ num_dpdk_interface_rx_queues }}

表に記載されていない Heat パラメーターの設定

表に記載されていない heat パラメーターを設定するには、パラメーターを {{role.name}}ExtraGroupVars として設定する必要があります。このパラメーターを {{role.name}}ExtraGroupVars パラメーターとして設定しないと、新しいテンプレートで使用できません。たとえば、StorageSupernet パラメーターを設定するには、次の設定をネットワーク設定ファイルに追加します。

parameter_defaults:
  ControllerExtraGroupVars:
    storage_supernet: 172.16.0.0/16

その後、{{ storage_supernet }} を Jinja2 テンプレートに追加できます。

警告

ノードのプロビジョニングで --network-config オプションが使用されている場合には、このプロセスは機能しません。カスタム変数を必要とするユーザーは、--network-config オプションを使用しないでください。代わりに、Heat スタックの作成後に、ノードのネットワーク設定を config-download ansible 実行に適用します。

Ansible 変数構文を変換することによる各ネットワークのプログラム設定

Jinja2 の for ループ構造を使用して、role_networks を反復処理すし、利用可能なネットワークをロール名で取得する場合には、各ネットワークロールの小文字の名前を取得して、各プロパティーの先頭に追加する必要があります。次の構造を使用して、上記の表の Ansible vars を必要な構文に変換します。

{{ lookup(‘vars’, networks_lower[network] ~ ‘_<property>’) }}

  • <property> は、設定するプロパティー (ipvlan_id、または mtu など) に置き換えます。

たとえば、各 NetworkVlanID の値を動的に入力するには、{{ <network_name>_vlan_id }} を次の設定に置き換えます。

{{ lookup(‘vars’, networks_lower[network] ~ ‘_vlan_id’) }}`

10.7.5. 定義ファイルマッピングをプロビジョニングする heat パラメーター

openstack overcloud node provision コマンドに --network-config オプションの引数を指定して実行し、ノードをプロビジョニングする場合、ノード定義ファイル overcloud-baremetal-deploy.yaml のパラメーターを使用して、デプロイメントのネットワークプロパティーを設定する必要があります。

デプロイメントで事前にプロビジョニングされたノードを使用する場合は、heat パラメーターを Ansible 変数にマッピングして、ネットワーク属性を設定します。--network-config オプションの引数を指定せずに openstack overcloud node provision を実行すると、heat パラメーターを Ansible 変数にマップすることもできます。Ansible 変数を使用したネットワークプロパティーの設定の詳細については、Heat パラメーターから Ansible 変数へのマッピング を参照してください。

以下の表には、heat パラメーターからノード定義ファイル overcloud-baremetal-deploy.yaml に相当する network_config プロパティーへの利用可能なマッピングをまとめています。

表10.14 heat パラメーターからノード定義ファイル overcloud-baremetal-deploy.yamlへのマッピング

Heat パラメーターnetwork_config プロパティー

BondInterfaceOvsOptions

bond_interface_ovs_options

DnsSearchDomains

dns_search_domains

NetConfigDataLookup

net_config_data_lookup

NeutronPhysicalBridge

physical_bridge_name

NeutronPublicInterface

public_interface_name

NumDpdkInterfaceRxQueues

{{ num_dpdk_interface_rx_queues }}

{{role.name}}NetworkConfigUpdate

network_config_update

以下の表では、heat パラメーターからネットワーク定義ファイル network_data.yaml で同等のプロパティーまで、利用可能なマッピングをまとめています。

表10.15 heat パラメーターからネットワーク定義ファイル network_data.yamlへのマッピング

Heat パラメーターIPv4 network_data.yaml プロパティーIPv6 network_data.yaml プロパティー

<network_name>IpSubnet

- name: <network_name>
  subnets:
    subnet01:
      ip_subnet: 172.16.1.0/24
- name: <network_name>
  subnets:
    subnet01:
      ipv6_subnet: 2001:db8:a::/64

<network_name>NetworkVlanID

- name: <network_name>
  subnets:
    subnet01:
      ...
      vlan: <vlan_id>
- name: <network_name>
  subnets:
    subnet01:
      ...
      vlan: <vlan_id>

<network_name>Mtu

- name: <network_name>
  mtu:
- name: <network_name>
  mtu:

<network_name>InterfaceDefaultRoute

- name: <network_name>
  subnets:
    subnet01:
      ip_subnet: 172.16.16.0/24
      gateway_ip: 172.16.16.1
- name: <network_name>
  subnets:
    subnet01:
      ipv6_subnet: 2001:db8:a::/64
      gateway_ipv6: 2001:db8:a::1

<network_name>InterfaceRoutes

- name: <network_name>
  subnets:
    subnet01:
      ...
      routes:
        - destination: 172.18.0.0/24
          nexthop: 172.18.1.254
- name: <network_name>
  subnets:
    subnet01:
      ...
      routes_ipv6:
        - destination: 2001:db8:b::/64
          nexthop: 2001:db8:a::1

10.7.6. ネットワークデータスキーマの変更

ネットワークデータスキーマは、Red Hat OpenStack Platform (RHOSP) 17 で更新されました。RHOSP 16 以前で使用されていたネットワークデータスキーマと、RHOSP 17 以降で使用されていたネットワークデータスキーマの主な違いは次のとおりです。

  • ベースサブネットは、サブネット マップに移動されました。これにより、スパインリーフネットワーキングなど、ルーティングされないデプロイメントとルーティングされるデプロイメントの設定が調整されます。
  • 無効なネットワークを無視するために、enabled オプションが使用されなくなりました。代わりに、設定ファイルから無効なネットワークを削除する必要があります。
  • compat_name オプションは、このオプションを使用していた heat リソースが削除されたため、不要になりました。
  • ip_subnetgateway_ipallocation_poolsroutesipv6_subnetgateway_ipv6ipv6_allocation_pools、および routes_ipv6 のパラメーターは、ネットワークレベルでは無効になりました。これらのパラメーターは、サブネットレベルで引き続き使用されます。
  • metalsmith で Ironic ポートを作成するために使用される新しいパラメーター physical_network が導入されました。
  • 新しいパラメーター network_type および segmentation_id は、ネットワークタイプを vlan に設定するために使用される {{network.name}}NetValueSpecs の後継となります。
  • 次のパラメーターは、RHOSP 17 で非推奨になりました。

    • {{network.name}}NetCidr
    • {{network.name}}SubnetName
    • {{network.name}}Network
    • {{network.name}}AllocationPools
    • {{network.name}}Routes
    • {{network.name}}SubnetCidr_{{subnet}}
    • {{network.name}}AllocationPools_{{subnet}}
    • {{network.name}}Routes_{{subnet}}

第11章 オーバークラウドのプロビジョニングとデプロイ

オーバークラウドを作成するには、以下のタスクを実行する必要があります。

  1. 物理ネットワークのネットワークリソースをプロビジョニングします。

    1. ネットワークの分離またはカスタム設定可能ネットワークをデプロイする場合は、ネットワーク定義ファイルを YAML 形式で作成します。
    2. ネットワーク定義ファイルを含め、ネットワークプロビジョニングコマンドを実行します。
    3. YAML 形式でネットワーク仮想 IP (VIP) 定義ファイルを作成します。
    4. ネットワーク VIP 定義ファイルを含め、ネットワーク VIP プロビジョニングコマンドを実行します。
  2. ベアメタルノードをプロビジョニングします。

    1. ノード定義ファイルを yaml 形式で作成します。
    2. ノード定義ファイルを含め、ベアメタルノードプロビジョニングコマンドを実行します。
  3. オーバークラウドをデプロイします。

    1. プロビジョニングコマンドにより生成される heat 環境ファイルを指定して、デプロイメントコマンドを実行します。

11.1. オーバークラウドネットワークのプロビジョニング

Red Hat OpenStack Platform (RHOSP) 物理ネットワーク環境のネットワークリソースを設定するには、次のタスクを実行する必要があります。

  1. オーバークラウドのネットワークリソースを設定およびプロビジョニングします。
  2. オーバークラウドのネットワーク仮想 IP を設定およびプロビジョニングします。

11.1.1. オーバークラウドのネットワーク定義の設定とプロビジョニング

YAML 形式のネットワーク定義ファイルで、オーバークラウドの物理ネットワークを設定します。プロビジョニングプロセスでは、ネットワーク仕様を含むネットワーク定義ファイルから heat 環境ファイルが作成されます。オーバークラウドをデプロイするときに、デプロイメントコマンドにこの heat 環境ファイルを含めます。

前提条件

  • アンダークラウドがインストールされます。詳しくは、Installing director を参照してください。

手順

  1. source コマンドで stackrc アンダークラウド認証情報ファイルを読み込みます。

    $ source ~/stackrc
  2. 必要なサンプルネットワーク定義テンプレートを /usr/share/openstack-tripleo-heat-templates/network-data-samples から環境ファイルディレクトリーにコピーします。

    (undercloud)$ cp /usr/share/openstack-tripleo-heat-templates/network-data-samples/default-network-isolation.yaml /home/stack/templates/network_data.yaml
  3. ネットワーク環境に合わせてネットワーク定義ファイルを設定します。たとえば、External ネットワーク定義を更新できます。

    - name: External
      name_lower: external
      vip: true
      mtu: 1500
      subnets:
        external_subnet:
          ip_subnet: 10.0.0.0/24
          allocation_pools:
            - start: 10.0.0.4
              end: 10.0.0.250
          gateway_ip: 10.0.0.1
          vlan: 10
  4. 環境のその他のネットワークとネットワーク属性を設定します。ネットワーク定義ファイルでネットワーク属性の設定に使用できるプロパティーの詳細は、オーバークラウドネットワークの設定 を参照してください。
  5. オーバークラウドネットワークをプロビジョニングします。

    (undercloud)$ openstack overcloud network provision \
     [--templates <templates_directory> \]
     --output  <deployment_file> \
     /home/stack/templates/<networks_definition_file>
    • オプション: --templates オプションを含めて、/usr/share/openstack-tripleo-heat-templates にあるデフォルトテンプレートの代わりに独自のテンプレートを使用します。<templates_directory> は、テンプレートを含むディレクトリーへのパスに置き換えます。
    • <deployment_file> は、デプロイメントコマンドに追加するために生成する heat 環境ファイルの名前に置き換えます (例 :/home/stack/templates/overcloud-networks-deployed.yaml)
    • <networks_definition_file> は、ネットワーク定義ファイルの名前 (network_data.yaml など) に置き換えます。
  6. ネットワークのプロビジョニングが完了したら、次のコマンドを使用して、作成されたネットワークとサブネットを確認できます。

    (undercloud)$ openstack network list
    (undercloud)$ openstack subnet list
    (undercloud)$ openstack network show <network>
    (undercloud)$ openstack subnet show <subnet>
    • <network> は、確認するネットワークの名前または UUID に置き換えます。
    • <subnet> は、確認するサブネットの名前または UUID に置き換えます。

11.1.2. オーバークラウドのネットワーク VIP の設定とプロビジョニング

YAML 形式のネットワーク VIP 定義ファイルで、オーバークラウドのネットワーク仮想 IP (VIP) を設定します。プロビジョニングプロセスでは、VIP 仕様を含む VIP 定義ファイルから Heat 環境ファイルが作成されます。オーバークラウドをデプロイするときに、デプロイメントコマンドにこの heat 環境ファイルを含めます。

前提条件

手順

  1. source コマンドで stackrc アンダークラウド認証情報ファイルを読み込みます。

    $ source ~/stackrc
  2. 必要なサンプルネットワーク VIP 定義テンプレートを /usr/share/openstack-tripleo-heat-templates/network-data-samples から環境ファイルディレクトリーにコピーします。

    (undercloud)$ cp /usr/share/openstack-tripleo-heat-templates/network-data-samples/vip-data-default-network-isolation.yaml /home/stack/templates/vip_data.yaml
  3. オプション: 環境に合わせて VIP 定義ファイルを設定します。たとえば、次の例では、External ネットワークとコントロールプレーンの VIP を定義しています。

    - network: external
      dns_name: overcloud
    - network: ctlplane
      dns_name: overcloud
  4. 環境のその他のネットワーク VIP 属性を設定します。VIP 定義ファイルで VIP 属性の設定に使用できるプロパティーの詳細は コンポーザブルネットワークの追加 を参照してください。
  5. ネットワーク VIP をプロビジョニングします。

    (undercloud)$ openstack overcloud network vip provision \
     [--templates <templates_directory> \]
     --stack <stack> \
     --output <deployment_file> \
     /home/stack/templates/<vip_definition_file>
    • オプション: --templates オプションを含めて、/usr/share/openstack-tripleo-heat-templates にあるデフォルトテンプレートの代わりに独自のテンプレートを使用します。<templates_directory> は、テンプレートを含むディレクトリーへのパスに置き換えます。
    • <stack> は、ネットワーク VIP がプロビジョニングされているスタックの名前 (overcloud など) に置き換えます。
    • <deployment_file> は、デプロイメントコマンドに含めるために生成する heat 環境ファイルの名前に置き換えます (例 :/home/stack/templates/overcloud-vip-deployed.yaml)
    • <vip_definition_file> は VIP 定義ファイルの名前 (vip_data.yaml など) に置き換えます。
  6. ネットワーク VIP のプロビジョニングが完了したら、次のコマンドを使用して、作成された VIP を確認できます。

    (undercloud)$ openstack port list
    (undercloud)$ openstack port show <port>
    • <port> は、確認するポートの名前または UUID に置き換えます。

11.2. ベアメタルオーバークラウドノードのプロビジョニング

Red Hat OpenStack Platform (RHOSP) 環境を設定するには、次のタスクを実行する必要があります。

  1. オーバークラウドのベアメタルノードを登録します。
  2. ベアメタルノードのハードウェアのインベントリーをディレクターに提供します。
  3. ノード定義ファイルで、ベアメタルノードの数量、属性、およびネットワークレイアウトを設定します。
  4. ベアメタルノードに、指定のノードとこのノードを合致させるリソースクラスを割り当てます。

プロファイルを一致させてオーバークラウドノードを指定するなど、追加のオプションのタスクを実行することもできます。

11.2.1. オーバークラウドノードの登録

ディレクターには、ノードのハードウェアと電源管理の詳細を指定するノード定義テンプレートが必要です。このテンプレートは、JSON 形式の nodes.json または YAML 形式の nodes.yaml で作成できます。

手順

  1. ノードをリスト表示する nodes.json または nodes.yaml という名前のテンプレートを作成します。以下の例に示す JSON および YAML テンプレートを使用して、ノード定義のテンプレートを設定する方法を説明します。

    JSON テンプレートの例

    {
      "nodes": [{
        "name": "node01",
        "ports": [{
          "address": "aa:aa:aa:aa:aa:aa",
          "physical_network": "ctlplane",
          "local_link_connection": {
            "switch_id": "52:54:00:00:00:00",
            "port_id": "p0"
          }
        }],
        "cpu": "4",
        "memory": "6144",
        "disk": "40",
        "arch": "x86_64",
        "pm_type": "ipmi",
        "pm_user": "admin",
        "pm_password": "p@55w0rd!",
        "pm_addr": "192.168.24.205"
      },
      {
        "name": "node02",
        "ports": [{
          "address": "bb:bb:bb:bb:bb:bb",
          "physical_network": "ctlplane",
          "local_link_connection": {
            "switch_id": "52:54:00:00:00:00",
            "port_id": "p0"
          }
        }],
        "cpu": "4",
        "memory": "6144",
        "disk": "40",
        "arch": "x86_64",
        "pm_type": "ipmi",
        "pm_user": "admin",
        "pm_password": "p@55w0rd!",
        "pm_addr": "192.168.24.206"
      }]
    }

    YAML テンプレートの例

    nodes:
      - name: "node01"
        ports:
          - address: "aa:aa:aa:aa:aa:aa"
            physical_network: ctlplane
            local_link_connection:
              switch_id: 52:54:00:00:00:00
              port_id: p0
        cpu: 4
        memory: 6144
        disk: 40
        arch: "x86_64"
        pm_type: "ipmi"
        pm_user: "admin"
        pm_password: "p@55w0rd!"
        pm_addr: "192.168.24.205"
      - name: "node02"
        ports:
          - address: "bb:bb:bb:bb:bb:bb"
            physical_network: ctlplane
            local_link_connection:
              switch_id: 52:54:00:00:00:00
              port_id: p0
        cpu: 4
        memory: 6144
        disk: 40
        arch: "x86_64"
        pm_type: "ipmi"
        pm_user: "admin"
        pm_password: "p@55w0rd!"
        pm_addr: "192.168.24.206"

    このテンプレートには、以下の属性が含まれます。

    name
    ノードの論理名
    ポート

    特定の IPMI デバイスにアクセスするためのポート次の任意のポート属性を定義できます。

    • address: ノード上のネットワークインターフェイスの MAC アドレス。各システムのプロビジョニング NIC の MAC アドレスのみを使用します。
    • physical_network: プロビジョニング NIC に接続されている物理ネットワーク。
    • local_link_connection: IPv6 プロビジョニングを使用し、イントロスペクション中に LLDP がローカルリンク接続を正しく反映しない場合は、local_link_connection パラメーターの switch_id および port_id フィールドにダミーのデータを含める必要があります。偽のデータを含める方法の詳細は、director イントロスペクションを使用したベアメタルノードのハードウェア情報の収集 を参照してください。
    cpu
    (オプション) ノード上の CPU 数
    memory
    (オプション) メモリーサイズ (MB 単位)
    disk
    (オプション) ハードディスクのサイズ (GB 単位)
    arch
    (オプション) システムアーキテクチャー
    pm_type

    使用する電源管理ドライバー。この例では IPMI ドライバー (ipmi) を使用しています。

    注記

    IPMI が推奨されるサポート対象電源管理ドライバーです。サポートされている電源管理の種類とそのオプションの詳細は、電源管理ドライバー を参照してください。それらの電源管理ドライバーが想定どおりに機能しない場合には、電源管理に IPMI を使用してください。

    pm_user、pm_password
    IPMI のユーザー名およびパスワード
    pm_addr
    IPMI デバイスの IP アドレス
  2. テンプレートのフォーマットと構文を確認します。

    $ source ~/stackrc
    (undercloud)$ openstack overcloud node import --validate-only ~/nodes.json
  3. テンプレートファイルをstack ユーザーのホームディレクトリー (/home/stack/nodes.json) に保存します。
  4. テンプレートを director にインポートして、各ノードをテンプレートから director に登録します。

    (undercloud)$ openstack overcloud node import ~/nodes.json
  5. ノードの登録および設定が完了するまで待ちます。完了したら、ノードが director に正しく登録されていることを確認します。

    (undercloud)$ openstack baremetal node list

11.2.2. ベアメタルノードハードウェアのインベントリーの作成

ディレクターは、プロファイルのタグ付け、ベンチマーク、および手動のルートディスク割り当てのために、Red Hat OpenStack Platform (RHOSP) デプロイメント内のノードのハードウェアインベントリーを必要とします。

次のいずれかの方法を使用して、ハードウェアインベントリーをディレクターに提供できます。

  • Automatic: 各ノードからハードウェア情報を収集するディレクターのイントロスペクションプロセスを使用できます。このプロセスは、各ノードでイントロスペクションエージェントを起動します。イントロスペクションエージェントは、ノードからハードウェアのデータを収集し、そのデータを director に送り返します。Director は、ハードウェアデータを OpenStack 内部データベースに保存します。
  • Manual: 各ベアメタルマシンの基本的なハードウェアインベントリーを手動で設定できます。このインベントリーは、ベアメタルプロビジョニングサービス (ironic) に保存され、ベアメタルマシンの管理とデプロイに使用されます。

ディレクターの自動イントロスペクションプロセスには、ベアメタルプロビジョニングサービスポートを手動で設定する方法に比べて、次の利点があります。

  • イントロスペクションは、接続されているすべてのポートをハードウェア情報に記録します。これには、nodes.yaml でまだ設定されていない場合に PXE ブートに使用するポートも含まれます。
  • イントロスペクションは、属性が LLDP を使用して検出可能である場合、各ポートの local_link_connection 属性を設定します。手動による方法を使用する場合は、ノードを登録するときに各ポートに local_link_connection を設定する必要があります。
  • イントロスペクションは、スパイン/リーフ型または DCN のアーキテクチャーをデプロイするときに、ベアメタルプロビジョニングサービスポートの physical_network 属性を設定します。

11.2.2.1. ディレクターのイントロスペクションを使用してベアメタルノードのハードウェア情報を収集する

物理マシンをベアメタルノードとして登録した後、ディレクターイントロスペクションを使用して、ハードウェアの詳細を自動的に追加し、イーサネット MAC アドレスごとにポートを作成できます。

ヒント

自動イントロスペクションの代わりに、ベアメタルノードのハードウェア情報をディレクターに手動で提供できます。詳細は、ベアメタルノードのハードウェア情報の手動設定 を参照してください。

前提条件

  • オーバークラウドのベアメタルノードを登録しました。

手順

  1. アンダークラウドホストに stack ユーザーとしてログインします。
  2. stackrc アンダークラウド認証情報ファイルを入手します。

    $ source ~/stackrc
  3. pre-introspection 検証グループを実行して、プリイントロスペクションの要件を確認します。

    (undercloud)$ validation run --group pre-introspection \
     --inventory <inventory_file>
    • <inventory_file> ファイルを Ansible インベントリーファイルの名前および場所に置き換えます (例: ~/tripleo-deploy/undercloud/tripleo-ansible-inventory.yaml)。

      注記

      検証を実行すると、出力の Reasons 列は 79 文字に制限されます。検証結果を完全に表示するには、検証ログファイルを表示します。

  4. 検証レポートの結果を確認します。
  5. オプション: 特定の検証からの詳細な出力を確認します。

    (undercloud)$ validation history get --full <UUID>
    • <UUID> は、確認するレポートの特定の検証の UUID に置き換えます。

      重要

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

  6. 各ノードのハードウェア属性を検証します。すべてのノードまたは特定のノードのハードウェア属性を検査できます。

    • すべてのノードのハードウェア属性を検査します。

      (undercloud)$ openstack overcloud node introspect --all-manageable --provide
      • --all-manageable オプションを使用して、管理状態にあるノードのみをイントロスペクションします。ここでは、すべてのノードが管理状態にあります。
      • --provide オプションを使用して、イントロスペクション後に全ノードを available の状態に再設定します。
    • 特定のノードのハードウェア属性を検査します。

      (undercloud)$ openstack overcloud node introspect --provide <node1> [node2] [noden]
      • --provide オプションを使用して、イントロスペクション後に指定されたすべてのノードを available 状態にリセットします。
      • <node1>[node2]、および [noden] までのすべてのノードを、イントロスペクションする各ノードの UUID に置き換えます。
  7. 別のターミナルウィンドウで、イントロスペクションの進捗ログを監視します。

    (undercloud)$ sudo tail -f /var/log/containers/ironic-inspector/ironic-inspector.log
    重要

    イントロスペクションプロセスが完了するまで実行されていることを確認します。イントロスペクションは通常、ベアメタルノードの場合 15 分かかります。ただし、イントロスペクションネットワークのサイズが正しくないと、時間がかかる可能性があり、イントロスペクションが失敗する可能性があります。

  8. オプション: IPv6 を介したベアメタルプロビジョニング用にアンダークラウドを設定した場合は、LLDP がベアメタルプロビジョニングサービス (ironic) ポートの local_link_connection を設定していることも確認する必要があります。

    $ openstack baremetal port list --long -c UUID -c "Node UUID" -c "Local Link Connection"
    • ベアメタルノードのポートに対して Local Link Connection フィールドが空の場合、local_link_connection 値に偽のデータを手動で入力する必要があります。次の例では、偽のスイッチ ID を 52:54:00:00:00:00 に設定し、偽のポート ID を p0 に設定します。

      $ openstack baremetal port set <port_uuid> \
      --local-link-connection switch_id=52:54:00:00:00:00 \
      --local-link-connection port_id=p0
    • ローカルリンク接続フィールドにダミーのデータが含まれていることを確認します。

      $ openstack baremetal port list --long -c UUID -c "Node UUID" -c "Local Link Connection"

イントロスペクション完了後には、すべてのノードが available の状態に変わります。

11.2.2.2. ベアメタルノードのハードウェア情報を手動で設定する

物理マシンをベアメタルノードとして登録した後、ハードウェアの詳細を手動で追加し、イーサネット MAC アドレスごとにベアメタルポートを作成できます。オーバークラウドをデプロイする前に、少なくとも 1 つのベアメタルポートを作成する必要があります。

ヒント

手動イントロスペクションの代わりに、自動ディレクターイントロスペクションプロセスを使用して、ベアメタルノードのハードウェア情報を収集できます。詳細は、director イントロスペクションを使用したベアメタルノードのハードウェア情報の収集 を参照してください。

前提条件

  • オーバークラウドのベアメタルノードを登録しました。
  • nodes.json の登録済みノードの各ポートに local_link_connection を設定しました。詳細は、オーバークラウドノードの登録 を参照してください。

手順

  1. アンダークラウドホストに stack ユーザーとしてログインします。
  2. stackrc アンダークラウド認証情報ファイルを入手します。

    $ source ~/stackrc
  3. ノードドライバーのデプロイカーネルとデプロイ ramdisk を指定します。

    (undercloud)$ openstack baremetal node set <node> \
      --driver-info deploy_kernel=<kernel_file> \
      --driver-info deploy_ramdisk=<initramfs_file>
    • <node> をベアメタルノードの ID に置き換えてください。
    • <kernel_file>.kernel イメージへのパス (例: file:///var/lib/ironic/httpboot/agent.kernel) に置き換えます。
    • <initramfs_file> は、.initramfs イメージへのパス (例: file:///var/lib/ironic/httpboot/agent.ramdisk) に置き換えます。
  4. ノードの属性を更新して、ノード上のハードウェアの仕様と一致するようにします。

    (undercloud)$ openstack baremetal node set <node> \
      --property cpus=<cpu> \
      --property memory_mb=<ram> \
      --property local_gb=<disk> \
      --property cpu_arch=<arch>
    • <node> をベアメタルノードの ID に置き換えてください。
    • <cpu> は、CPU の数に置き換えます。
    • <ram> を MB 単位の RAM に置き換えます。
    • <disk> を GB 単位のディスクサイズに置き換えます。
    • <arch> は、アーキテクチャータイプに置き換えます。
  5. オプション: 各ノードの IPMI 暗号スイートを指定します。

    (undercloud)$ openstack baremetal node set <node> \
     --driver-info ipmi_cipher_suite=<version>
    • <node> をベアメタルノードの ID に置き換えてください。
    • <version> は、ノードで使用する暗号スイートのバージョンに置き換えます。以下の有効な値のいずれかに設定します。

      • 3 - ノードは SHA1 暗号スイートで AES-128 を使用します。
      • 17 - ノードは SHA256 暗号スイートで AES-128 を使用します。
  6. オプション: 複数のディスクがある場合は、ルートデバイスのヒントを設定して、デプロイメントに使用するディスクをデプロイ ramdisk に通知します。

    (undercloud)$ openstack baremetal node set <node> \
      --property root_device='{"<property>": "<value>"}'
    • <node> をベアメタルノードの ID に置き換えてください。
    • <property><value> は、デプロイメントに使用するディスクの詳細に置き換えます (例: root_device='{"size": "128"}')。

      RHOSP は、次のプロパティーをサポートしています。

      • model (文字列): デバイスの ID
      • vendor (文字列): デバイスのベンダー
      • serial (文字列): ディスクのシリアル番号
      • hctl (文字列): SCSI のホスト、チャンネル、ターゲット、Lun
      • size (整数): デバイスのサイズ (GB 単位)
      • wwn (文字列): 一意のストレージ ID
      • wwn_with_extension (文字列): ベンダー拡張子を追加した一意のストレージ ID
      • wwn_vendor_extension (文字列): 一意のベンダーストレージ ID
      • rotational (ブール値): 回転式デバイス (HDD) には true、そうでない場合 (SSD) には false
      • name (文字列): デバイス名 (例: /dev/sdb1)。このプロパティーは、永続デバイス名が付いたデバイスにのみ使用してください。

        注記

        複数のプロパティーを指定する場合には、デバイスはそれらの全プロパティーと一致する必要があります。

  7. プロビジョニングネットワーク上の NIC の MAC アドレスを使用してポートを作成することにより、Bare Metal Provisioning サービスにノードのネットワークカードを通知します。

    (undercloud)$ openstack baremetal port create --node <node_uuid> <mac_address>
    • <node_uuid> をベアメタルノードの一意の ID に置き換えます。
    • <mac_address> は、PXE ブートに使用する NIC の MAC アドレスに置き換えます。
  8. ノードの設定を検証します。

    (undercloud)$ openstack baremetal node validate <node>
    -----------------------------------------------------------------
    | Interface  | Result | Reason                                    |
    -----------------------------------------------------------------
    | bios       | True   |                                           |
    | boot       | True   |                                           |
    | console    | True   |                                           |
    | deploy     | False  | Node 229f0c3d-354a-4dab-9a88-ebd318249ad6 |
    |            |        | failed to validate deploy image info.     |
    |            |        | Some parameters were missing. Missing are:|
    |            |        | [instance_info.image_source]              |
    | inspect    | True   |                                           |
    | management | True   |                                           |
    | network    | True   |                                           |
    | power      | True   |                                           |
    | raid       | True   |                                           |
    | rescue     | True   |                                           |
    | storage    | True   |                                           |
    -----------------------------------------------------------------

    有効出力の Result は、次のことを示しています。

    • False: インターフェイスは検証に失敗しました。instance_info.image_source パラメーターが欠落していることが理由に含まれている場合には、プロビジョニング中に入力されたことが原因である可能性があり、この時点では設定されていません。ディスクイメージ全体を使用している場合は、検証にパスするために image_source を設定するだけでよい場合があります。
    • True: インターフェイスは検証にパスしました。
    • None: インターフェイスはドライバーでサポートされていません。

11.2.3. オーバークラウドのベアメタルノードのプロビジョニング

ベアメタルノードをプロビジョニングするには、デプロイするベアメタルノードの数と属性を YAML 形式のノード定義ファイルで定義し、これらのノードにオーバークラウドロールを割り当てます。ノードのネットワークレイアウトも定義します。

プロビジョニングプロセスにより、ノード定義ファイルから Heat 環境ファイルが作成されます。この Heat 環境ファイルには、ノード数、予測ノード配置、カスタムイメージ、カスタム NIC など、ノード定義ファイルで設定したノード仕様が含まれています。オーバークラウドをデプロイする際に、このファイルをデプロイメントコマンドに追加します。プロビジョニングプロセスでは、ノード定義ファイル内の各ノードまたはロールに対して定義されたすべてのネットワークのポートリソースもプロビジョニングされます。

前提条件

手順

  1. source コマンドで stackrc アンダークラウド認証情報ファイルを読み込みます。

    $ source ~/stackrc
  2. overcloud-baremetal-deploy.yaml ノード定義ファイルを作成し、プロビジョニングするロールごとにノード数を定義します。たとえば、3 つのコントローラーノードと 3 つのコンピュートノードをプロビジョニングするには、以下の設定を overcloud-baremetal-deploy.yaml ファイルに追加します。

    - name: Controller
      count: 3
    - name: Compute
      count: 3
  3. オプション: 予測ノード配置を設定します。たとえば、以下の設定を使用すると、3 つのコントローラーノードがノード node00node01、および node02 に、3 つのコンピュートノードがノード node04node05、および node06 に、それぞれプロビジョニングされます。

    - name: Controller
      count: 3
      instances:
      - hostname: overcloud-controller-0
        name: node00
      - hostname: overcloud-controller-1
        name: node01
      - hostname: overcloud-controller-2
        name: node02
    - name: Compute
      count: 3
      instances:
      - hostname: overcloud-novacompute-0
        name: node04
      - hostname: overcloud-novacompute-1
        name: node05
      - hostname: overcloud-novacompute-2
        name: node06
  4. オプション: デフォルトでは、プロビジョニングプロセスは overcloud-hardened-uefi-full.qcow2 イメージを使用します。イメージのローカル URL またはリモート URL を指定することで、特定のノードで使用されるイメージ、またはロールのすべてのノードで使用されるイメージを変更できます。次の例では、イメージをローカル QCOW2 イメージに変更します。

    特定のノード

    - name: Controller
      count: 3
      instances:
      - hostname: overcloud-controller-0
        name: node00
        image:
          href: file:///var/lib/ironic/images/overcloud-custom.qcow2
      - hostname: overcloud-controller-1
        name: node01
        image:
          href: file:///var/lib/ironic/images/overcloud-full-custom.qcow2
      - hostname: overcloud-controller-2
        name: node02
        image:
          href: file:///var/lib/ironic/images/overcloud-full-custom.qcow2

    ロールのすべてのノード

    - name: Controller
      count: 3
      defaults:
        image:
          href: file:///var/lib/ironic/images/overcloud-custom.qcow2
      instances:
      - hostname: overcloud-controller-0
        name: node00
      - hostname: overcloud-controller-1
        name: node01
      - hostname: overcloud-controller-2
        name: node02

  5. ロールのすべてのノードのネットワークレイアウト、または特定のノードのネットワークレイアウトを定義します。

    特定のノード

    次の例では、特定のコントローラーノードのネットワークをプロビジョニングし、予測可能な IP を Internal API ネットワークのノードに割り当てます。

    - name: Controller
      count: 3
      defaults:
        network_config:
          template: /home/stack/templates/nic-config/myController.j2
          default_route_network:
          - external
        instances:
          - hostname: overcloud-controller-0
            name: node00
            networks:
              - network: ctlplane
                vif: true
              - network: external
                subnet: external_subnet
              - network: internal_api
                subnet: internal_api_subnet01
                fixed_ip: 172.21.11.100
              - network: storage
                subnet: storage_subnet01
              - network: storage_mgmt
                subnet: storage_mgmt_subnet01
              - network: tenant
                subnet: tenant_subnet01

    ロールのすべてのノード

    次の例では、コントローラーロールとコンピューティングロールのネットワークをプロビジョニングします。

    - name: Controller
      count: 3
      defaults:
        networks:
        - network: ctlplane
          vif: true
        - network: external
          subnet: external_subnet
        - network: internal_api
          subnet: internal_api_subnet01
        - network: storage
          subnet: storage_subnet01
        - network: storage_mgmt
          subnet: storage_mgmt_subnet01
        - network: tenant
          subnet: tenant_subnet01
        network_config:
          template: /home/stack/templates/nic-config/myController.j2 1
          default_route_network:
          - external
    - name: Compute
      count: 3
      defaults:
        networks:
        - network: ctlplane
          vif: true
        - network: internal_api
          subnet: internal_api_subnet02
        - network: tenant
          subnet: tenant_subnet02
        - network: storage
          subnet: storage_subnet02
        network_config:
          template: /home/stack/templates/nic-config/myCompute.j2
    1
    /usr/share/ansible/roles/tripleo_network_config/templates にあるサンプル NIC テンプレートを使用して、ローカル環境ファイルディレクトリーに独自の NIC テンプレートを作成できます。
  6. オプション: デフォルトのディスクパーティションサイズが要件を満たさない場合は、ディスクパーティションサイズの割り当てを設定します。たとえば、/var/log パーティションのデフォルトのパーティションサイズは 10 GB です。ログストレージおよび保存要件を考慮して、10 GB が要件を満たすかどうかを判断してください。ログストレージ用に割り当てられたディスクサイズを増やす必要がある場合は、次の設定をノード定義ファイルに追加して、デフォルトをオーバーライドします。

    ansible_playbooks:
      - playbook: /usr/share/ansible/tripleo-playbooks/cli-overcloud-node-growvols.yaml
        extra_vars:
          role_growvols_args:
            default:
              /=8GB
              /tmp=1GB
              /var/log=<log_size>GB
              /var/log/audit=2GB
              /home=1GB
              /var=100%
    • <log_size> を、ログファイルに割り当てるディスクのサイズに置き換えます。
  7. Object Storage サービス (swift) とディスク全体のオーバークラウドイメージ overcloud-hardened-uefi-full を使用する場合に、ディスクのサイズと /var および /srv のストレージ要件に基づいて /srv パーティションのサイズを設定する必要があります。詳細は、Object Storage サービスのディスクパーティション全体の設定 を参照してください。
  8. オプション: カスタムリソースクラスまたはプロファイル機能を使用して、オーバークラウドノードを特定のロールに指定します。詳細は、リソースクラスを一致させることによるオーバークラウドノードのロールの指定 および プロファイルを一致させることによるオーバークラウドノードのロールの指定 を参照してください。
  9. ノードに割り当てるその他の属性を定義します。ノード定義ファイルでノード属性を設定するために使用できるプロパティーについて詳しくは、ベアメタルノードのプロビジョニング属性 を参照してください。ノード定義ファイルの例は、ノード定義ファイルの例 を参照してください。
  10. オーバークラウドノードをプロビジョニングします。

    (undercloud)$ openstack overcloud node provision \
     [--templates <templates_directory> \]
     --stack <stack> \
     --network-config \
     --output <deployment_file> \
     /home/stack/templates/<node_definition_file>
    • オプション: --templates オプションを含めて、/usr/share/openstack-tripleo-heat-templates にあるデフォルトテンプレートの代わりに独自のテンプレートを使用します。<templates_directory> は、テンプレートを含むディレクトリーへのパスに置き換えます。
    • <stack> を、ベアメタルノードがプロビジョニングされるスタックの名前に置き換えます。指定しない場合、デフォルトは overcloud です。
    • --network-config オプションの引数を含めて、cli-overcloud-node-network-config.yaml Ansible Playbook にネットワーク定義を提供します。
    • <deployment_file> は、デプロイメントコマンドに含めるために生成する heat 環境ファイルの名前に置き換えます (例 :/home/stack/templates/overcloud-baremetal-deployed.yaml)
    • <node_definition_file> は、ノード定義ファイルの名前 (overcloud-baremetal-deploy.yaml など) に置き換えます。
  11. 別のターミナルでプロビジョニングの進捗を監視します。

    (undercloud)$ watch openstack baremetal node list
    • プロビジョニングが成功すると、ノードの状態が available から active に変わります。
    • ノードのハードウェアまたはネットワーク設定の障害が原因でノードのプロビジョニングが失敗した場合は、プロビジョニング手順を再度実行する前に、失敗したノードを削除できます。詳細については、障害が発生したベアメタルノードをノード定義ファイルから削除する を参照してください。
  12. metalsmith ツールを使用して、割り当てやポートなどを含むノードの統合ビューを取得します。

    (undercloud)$ metalsmith list
  13. ノードとホスト名の関連付けを確認します。

    (undercloud)$ openstack baremetal allocation list

11.2.4. ベアメタルノードのプロビジョニング属性

次の表を使用して、ノード属性を設定するために使用できるプロパティーと、openstack baremetal node provision コマンドでベアメタルノードをプロビジョニングするときに使用できる値を理解してください。

  • ロールのプロパティー: ロールのプロパティーを使用して、各ロールを定義します。
  • 各ロールのデフォルトプロパティーとインスタンスプロパティー: デフォルトプロパティーまたはインスタンスプロパティーを使用して、使用可能なノードのプールからノードを割り当てるための選択基準を指定し、ベアメタルノードの属性とネットワーク設定プロパティーを設定します。

ベアメタル定義ファイルの作成については、オーバークラウド用のベアメタルノードのプロビジョニング を参照してください。

表11.1 ロールのプロパティー

プロパティー

name

ロール名 (必須)

count

このロール用にプロビジョニングするノード数。デフォルト値は 1 です。

defaults

instances エントリープロパティーのデフォルト値のディクショナリー。instances エントリーのプロパティーは、defaults パラメーターで指定したデフォルトを上書きします。

instances

特定のノードの属性を指定するために使用可能な値のディクショナリー。インスタンス パラメーターでサポートされているプロパティーの詳細は、 defaultsinstances プロパティー を参照してください。定義されるノードの数は、count パラメーターの値を超えてはなりません。

hostname_format

このロールのデフォルトのホスト名形式を上書きします。デフォルトで生成されるホスト名は、オーバークラウドのスタック名、ロール、および増分インデックス (すべて小文字) から派生します。たとえば、Controller ロールのデフォルト形式は、%stackname%-controller-%index% です。Compute ロールだけは、ロール名のルールに従いません。Compute のデフォルトの形式は、%stackname%-novacompute-%index% です。

ansible_playbooks

Ansible Playbook と Ansible 変数の値のディクショナリー。Playbook は、ノードをプロビジョニングしてから、かつノードのネットワークを設定する前に、ロールインスタンスに対して実行されます。Ansible Playbook の指定の詳細は、ansible_playbooks プロパティー を参照してください。

表11.2 defaultsinstances のプロパティー

プロパティー

hostname

(instances のみ) instance プロパティーが適用されるノードのホスト名を指定します。ホスト名は、hostname_format プロパティーから派生します。カスタムホスト名を使用できます。

name

(instances のみ) プロビジョニングするノードの名前。

image

ノードにプロビジョニングするイメージの詳細。サポート対象の image プロパティーについては、image プロパティー を参照してください。

capabilities

ノードのケイパビリティーを照合する際の選択基準

config_drive

ノードに渡された設定ドライブにデータと初回起動コマンドを追加します。詳細は、config_drive プロパティー を参照してください。

注記

初回起動時に実行する必要がある設定には、config_drive のみを使用してください。他のすべてのカスタム設定については、Ansible Playbook を作成し、ansible_playbooks プロパティーを使用して、ノードのプロビジョニング後にロールインスタンスに対して Playbook を実行します。

管理

インスタンスを metalsmith でプロビジョニングするには、true (デフォルト) に設定します。インスタンスを事前プロビジョニング済みとして処理するには、false に設定します。

networks

インスタンスネットワークを表すディクショナリーのリスト。ネットワーク属性の設定の詳細については、network プロパティー を参照してください。

network_config

ロールまたはインスタンスのネットワーク設定ファイルへのリンク。ネットワーク設定ファイルへのリンクの設定の詳細は、network_config プロパティー を参照してください。

profile

プロファイルマッチングの選択基準。詳細は、プロファイルを照合することによるオーバークラウドノードへのロール指定 を参照してください。

provisioned

ノードをプロビジョニングするには、true (デフォルト) に設定します。ノードのプロビジョニングを解除するには、false に設定します。詳細は、ベアメタルノードのスケールダウン を参照してください。

resource_class

ノードのリソースクラスを照合する際の選択基準。デフォルト値は baremetal です。詳細は、リソースクラスを一致させることによるオーバークラウドノードのロールの指定 を参照してください。

root_size_gb

ルートパーティションのサイズ (GiB 単位)。デフォルト値は 49 です。

swap_size_mb

スワップパーティションのサイズ (MiB 単位)

traits

ノード特性を照合する際の選択基準としての特性のリスト

表11.3 image プロパティー

プロパティー

href

ノードにプロビジョニングするルートパーティションまたはディスクイメージ全体の URL を指定します。サポートされている URL スキーム: file://http://、および https://

注記

file:// URL スキームを使用してイメージのローカル URL を指定する場合、イメージパスは /var/lib/ironic/images/ ディレクトリーを指している必要があります。これは、/var/lib/ironic/images がアンダークラウドから ironic-conductor コンテナーにバインドマウントされ、明示的にイメージを提供するためです。

checksum

ルートパーティションまたはディスクイメージ全体の MD5 チェックサムを指定します。href が URL の場合は必須です。

kernel

カーネルイメージのイメージ参照または URL を指定します。パーティションイメージに対してのみ、この属性を使用します。

ramdisk

RAM ディスクイメージのイメージ参照または URL を指定します。パーティションイメージに対してのみ、この属性を使用します。

表11.4 network プロパティー

プロパティー

fixed_ip

このネットワークに使用する特定の IP アドレス

network

ネットワークポートを作成するネットワーク。

subnet

ネットワークポートを作成するサブネット。

port

新しいポートを作成する代わりに使用する既存のポート。

vif

プロビジョニングネットワーク (ctlplane) で true に設定して、ネットワークを仮想インターフェイス (VIF) として接続します。VIF 添付ファイルなしでネットワーキングサービス API リソースを作成するには、false に設定します。

表11.5 network_config プロパティー

プロパティー

template

ノードのネットワーク設定を適用するときに使用する Ansible J2 NIC 設定テンプレートを指定します。NIC テンプレートの設定については、オーバークラウドネットワークの設定 を参照してください。

physical_bridge_name

External ネットワークにアクセスするために作成する OVS ブリッジの名前。デフォルトのブリッジ名は br-ex です。

public_interface_name

パブリックブリッジに追加するインターフェイスの名前を指定します。デフォルトのインターフェイスは nic1 です。

network_config_update

更新時にネットワーク設定の変更を適用するには、true に設定します。デフォルトでは無効になっています。

net_config_data_lookup

各ノードまたはノードグループの NIC マッピング設定 os-net-config を指定します。

default_route_network

デフォルトルートに使用するネットワーク。デフォルトのルートネットワークは ctlplane です。

networks_skip_config

ノードのネットワークを設定するときにスキップするネットワークのリスト。

dns_search_domains

resolv.conf に追加する DNS 検索ドメインのリスト (優先順位順)。

bond_interface_ovs_options

結合インターフェイスに使用する OVS オプションまたは結合オプション。たとえば、OVS のボンディングの場合は lacp=active および bond_mode=balance-slb、Linux のボンディングの場合は mode=4 です。

{{ num_dpdk_interface_rx_queues }}

DPDK ボンドまたは DPDK ポートに必要な RX キューの数を指定します。

表11.6 config_drive プロパティー

プロパティー

cloud_config

ノードの起動時に実行するタスクの cloud-init クラウド設定データのディクショナリー。たとえば、初回起動時にカスタムネームサーバーを resolve.conf ファイルに書き込むには、以下の cloud_configconfig_drive プロパティーに追加します。

config_drive:
  cloud_config:
    manage_resolv_conf: true
    resolv_conf:
      nameservers:
        - 8.8.8.8
        - 8.8.4.4
      searchdomains:
        - abc.example.com
        - xyz.example.com
      domain: example.com
      sortlist:
        - 10.0.0.1/255
        - 10.0.0.2
      options:
        rotate: true
        timeout: 1

meta_data

config-drive cloud-init メタデータに含める追加のメタデータ。メタデータは、ロール名 (public_keysuuidnamehostname、および instance-type) で生成されたメタデータセットに追加されます。Cloud-init は、このメタデータをインスタンスデータとして利用できるようにします。

表11.7 ansible_playbooks プロパティー

プロパティー

Playbook

ロール定義 YAML ファイルに相対的な、Ansible Playbook へのパス。

extra_vars

Playbook の実行時に設定する追加の Ansible 変数。次の構文を使用して、追加の変数を指定します。

ansible_playbooks:
  - playbook: a_playbook.yaml
    extra_vars:
      param1: value1
      param2: value2

たとえば、ディスク全体のオーバークラウドイメージ overcloud-hardened-uefi-full.qcow2 でデプロイされた任意のノードの LVM ボリュームを拡張するには、以下の別の変数を Playbook プロパティーに追加します。

ansible_playbooks:
  - playbook: /usr/share/ansible/tripleo-playbooks/cli-overcloud-node-growvols.yaml
    extra_vars:
      role_growvols_args:
        default:
          /=8GB
          /tmp=1GB
          /var/log=10GB
          /var/log/audit=2GB
          /home=1GB
          /var=100%
        Controller:
          /=8GB
          /tmp=1GB
          /var/log=10GB
          /var/log/audit=2GB
          /home=1GB
          /srv=50GB
          /var=100%

11.2.5. 障害が発生したベアメタルノードをノード定義ファイルから削除する

ノードのハードウェアまたはネットワーク設定の障害が原因でノードのプロビジョニングが失敗した場合は、プロビジョニング手順を再度実行する前に、失敗したノードを削除できます。プロビジョニング中に失敗したベアメタルノードを削除するには、ノード定義ファイルでスタックから削除するノードにタグを付け、動作中のベアメタルノードをプロビジョニングする前にノードのプロビジョニングを解除します。

前提条件

  • アンダークラウドがインストールされます。詳しくは、Installing director を参照してください。
  • ノードのハードウェア障害が原因で、ベアメタルノードのプロビジョニングが失敗しました。

手順

  1. source コマンドで stackrc アンダークラウド認証情報ファイルを読み込みます。

    $ source ~/stackrc
  2. overcloud-baremetal-deploy.yaml ノード定義ファイルを開きます。
  3. ノードが割り当てられているロールの count パラメーターを減らします。たとえば、以下の設定は、ObjectStorage ロールのカウントパラメーターを更新して、ObjectStorage 専用のノード数が 3 に減ったことを反映します。

    - name: ObjectStorage
      count: 3
  4. ロールの instances 属性でまだ定義されていない場合は、スタックから削除するノードの hostnamename を定義します。
  5. 削除するノードに属性 provisioned: false を追加します。たとえば、スタックからノード overcloud-objectstorage-1 を削除するには、overcloud-baremetal-deploy.yaml ファイルに以下のスニペットを追加します。

    - name: ObjectStorage
      count: 3
      instances:
      - hostname: overcloud-objectstorage-0
        name: node00
      - hostname: overcloud-objectstorage-1
        name: node01
        # Removed from cluster due to disk failure
        provisioned: false
      - hostname: overcloud-objectstorage-2
        name: node02
      - hostname: overcloud-objectstorage-3
        name: node03
  6. ベアメタルノードのプロビジョニングを解除します。

    (undercloud)$ openstack overcloud node unprovision \
     --stack <stack> \
     --network-ports \
     /home/stack/templates/overcloud-baremetal-deploy.yaml
    • <stack> を、ベアメタルノードがプロビジョニングされるスタックの名前に置き換えます。指定しない場合、デフォルトは overcloud です。
  7. オーバークラウドノードをプロビジョニングして、デプロイメントコマンドに含める heat 環境ファイルを更新して生成します。

    (undercloud)$ openstack overcloud node provision \
    --stack <stack> \
    --output <deployment_file> \
    /home/stack/templates/overcloud-baremetal-deploy.yaml
    • <deployment_file> は、デプロイメントコマンドに含めるために生成する heat 環境ファイルの名前に置き換えます (例 :/home/stack/templates/overcloud-baremetal-deployed.yaml)

11.2.6. リソースクラスを一致させることによるオーバークラウドノードのロールの指定

カスタムリソースクラスを使用して、オーバークラウドノードを特定のロールに指定できます。リソースクラスは、ノードとデプロイロールを照合します。デフォルトでは、すべてのノードに baremetal のリソースクラスが割り当てられます。

注記

ノードのプロビジョニング後にノードに割り当てられたリソースクラスを変更するには、スケールダウン手順を使用してノードのプロビジョニングを解除してから、スケールアップ手順を使用して、新しいリソースクラスの割り当てでノードを再プロビジョニングする必要があります。詳細は、オーバークラウドノードのスケーリング を参照してください。

前提条件

  • オーバークラウド用のベアメタルノードの初期プロビジョニングを実行しています。

手順

  1. カスタムリソースクラスを持つロールに指定する各ベアメタルノードを割り当てます。

    (undercloud)$ openstack baremetal node set \
     --resource-class <resource_class> <node>
    • <resource_class> は、リソースクラスの名前 (baremetal.CPU-PINNING など) に置き換えます。
    • <node> をベアメタルノードの ID に置き換えてください。
  2. まだ定義されていない場合は、overcloud-baremetal-deploy.yaml ファイルにロールを追加します。
  3. ロールのノードに割り当てるリソースクラスを指定します。

    - name: <role>
      count: 1
      defaults:
        resource_class: <resource_class>
    • <role> をロールの名前に置き換えます。
    • <resource_class> は、手順 1 で指定したリソースクラスの名前に置き換えます。
  4. オーバークラウドのベアメタルノードのプロビジョニング に戻り、プロビジョニングプロセスを完了します。

11.2.7. プロファイルを一致させることによるオーバークラウドノードのロールの指定

プロファイル機能を使用して、オーバークラウドノードを特定のロールに指定できます。プロファイルは、ノードの機能をデプロイメントロールと照合します。

ヒント

イントロスペクションルールを使用して、自動プロファイル割り当てを実行することもできます。詳しくは、プロファイルの自動タグ付けの設定 を参照してください。

注記

ノードのプロビジョニング後にノードに割り当てられたプロファイルを変更するには、スケールダウン手順を使用してノードのプロビジョニングを解除してから、スケールアップ手順を使用して、新しいプロファイルの割り当てでノードを再プロビジョニングする必要があります。詳細は、オーバークラウドノードのスケーリング を参照してください。

前提条件

  • オーバークラウド用のベアメタルノードの初期プロビジョニングを実行しています。

手順

  1. 新しいノード機能を追加するたびに、既存のノード機能が上書きされます。したがって、再設定するには、登録済みの各ノードの既存の機能を取得する必要があります。

    $ openstack baremetal node show <node> \
     -f json -c properties | jq -r .properties.capabilities
  2. ノードの既存の機能に profile:<profile> を追加して、ロールプロファイルに一致させる各ベアメタルノードにプロファイル機能を割り当てます。

    (undercloud)$ openstack baremetal node set  <node> \
     --property capabilities="profile:<profile>,<capability_1>,...,<capability_n>"
    • <node> は、ベアメタルノードの名前または ID に置き換えます。
    • <profile> は、ロールプロファイルに一致するプロファイルの名前に置き換えます。
    • <capability_1> および <capability_n> までのすべての機能は、手順 1 で取得した各機能に置き換えます。
  3. まだ定義されていない場合は、overcloud-baremetal-deploy.yaml ファイルにロールを追加します。
  4. ロールのノードに割り当てるプロファイルを定義します。

    - name: <role>
      count: 1
      defaults:
        profile: <profile>
    • <role> をロールの名前に置き換えます。
    • <profile> は、ノードの機能に一致するプロファイルの名前に置き換えます。
  5. オーバークラウドのベアメタルノードのプロビジョニング に戻り、プロビジョニングプロセスを完了します。

11.2.8. Object Storage サービスのディスクパーティション全体の設定

ディスクイメージ全体である overcloud-hardened-uefi-full は、個別のボリュームに分割されます。デフォルトでは、ディスク全体のオーバークラウドイメージでデプロイされたノードの /var パーティションは、ディスクが完全に割り当てられるまで自動的に増加します。Object Storage サービス (swift) を使用する場合は、ディスクのサイズと /var および /srv のストレージ要件に基づいて /srv パーティションのサイズを設定します。

前提条件

  • オーバークラウド用のベアメタルノードの初期プロビジョニングを実行しています。

手順

  1. overcloud-baremetal-deploy.yaml ノード定義ファイルの Ansible_playbooks 定義で、追加の Ansible 変数として role_growvols_args を使用して、/srv および /var パーティションを設定します。/srv または /var のいずれかを GB 単位の絶対サイズに設定し、もう一方を 100% に設定して、残りのディスク領域を消費します。

    • 次の設定例では、/srv をコントローラーノードにデプロイされた Object Storage サービスの絶対サイズに、/var を 100% に設定して、残りのディスク領域を消費します。

      ansible_playbooks:
        - playbook: /usr/share/ansible/tripleo-playbooks/cli-overcloud-node-growvols.yaml
          extra_vars:
            role_growvols_args:
              default:
                /=8GB
                /tmp=1GB
                /var/log=10GB
                /var/log/audit=2GB
                /home=1GB
                /var=100%
              Controller:
                /=8GB
                /tmp=1GB
                /var/log=10GB
                /var/log/audit=2GB
                /home=1GB
                /srv=50GB
                /var=100%
    • 以下の設定例では、/var を絶対サイズに、/srv を 100% に設定して、Object Storage サービスの Object Storage ノードの残りのディスクスペースを消費します。

      ansible_playbooks:
        - playbook: /usr/share/ansible/tripleo-playbooks/cli-overcloud-node-growvols.yaml
          extra_vars:
            role_growvols_args:
              default:
                /=8GB
                /tmp=1GB
                /var/log=10GB
                /var/log/audit=2GB
                /home=1GB
                /var=100%
             ObjectStorage:
                /=8GB
                /tmp=1GB
                /var/log=10GB
                /var/log/audit=2GB
                /home=1GB
                /var=10GB
                /srv=100%
  2. オーバークラウドのベアメタルノードのプロビジョニング に戻り、プロビジョニングプロセスを完了します。

11.2.9. ノード定義ファイルの例

次のノード定義ファイルの例では、3 つのコントローラーノードと 3 つのコンピュートノードの予測ノード配置と、それらが使用するデフォルトネットワークを定義しています。この例は、リソースクラスまたはノード機能プロファイルの照合に基づいて指定されたノードが含まれるカスタムロールを定義する方法も示しています。

- name: Controller
  count: 3
  defaults:
    image:
      href: file:///var/lib/ironic/images/overcloud-custom.qcow2
    networks:
    - network: ctlplane
      vif: true
    - network: external
      subnet: external_subnet
    - network: internal_api
      subnet: internal_api_subnet01
    - network: storage
      subnet: storage_subnet01
    - network: storagemgmt
      subnet: storage_mgmt_subnet01
    - network: tenant
      subnet: tenant_subnet01
    network_config:
        template: /home/stack/templates/nic-config/myController.j2
        default_route_network:
        - external
    profile: nodeCapability
  instances:
  - hostname: overcloud-controller-0
    name: node00
  - hostname: overcloud-controller-1
    name: node01
  - hostname: overcloud-controller-2
    name: node02
- name: Compute
  count: 3
  defaults:
    networks:
    - network: ctlplane
      vif: true
    - network: internal_api
      subnet: internal_api_subnet02
    - network: tenant
      subnet: tenant_subnet02
    - network: storage
      subnet: storage_subnet02
    network_config:
      template: /home/stack/templates/nic-config/myCompute.j2
    resource_class: baremetal.COMPUTE
  instances:
  - hostname: overcloud-novacompute-0
    name: node04
  - hostname: overcloud-novacompute-1
    name: node05
  - hostname: overcloud-novacompute-2
    name: node06

11.2.10. 仮想メディアブートの有効化

重要

この機能は、本リリースでは テクノロジープレビュー として提供しているため、Red Hat では全面的にはサポートしていません。これは、テスト用途にのみご利用いただく機能です。実稼働環境にはデプロイしないでください。テクノロジープレビュー機能についての詳しい情報は、対象範囲の詳細 を参照してください。

Redfish 仮想メディアブートを使用して、ノードの Baseboard Management Controller (BMC) にブートイメージを提供することができます。これにより、BMC はイメージを仮想ドライブのいずれかに挿入することができます。その後、ノードは仮想ドライブからイメージに存在するオペレーティングシステムにブートすることができます。

Redfish ハードウェア種別は、仮想メディアを通じたデプロイ、レスキュー、およびユーザーの各イメージのブートに対応しています。Bare Metal Provisioning サービス (ironic) は、ノードのデプロイメント時に、ノードに関連付けられたカーネルイメージおよび ramdisk イメージを使用して、UEFI または BIOS ブートモード用のブート可能 ISO イメージをビルドします。仮想メディアブートの主な利点は、PXE の TFTP イメージ転送フェーズを排除し、HTTP GET 等の方法を使用することができる点です。

仮想メディアを通じて redfish ハードウェア種別のノードをブートするには、ブートインターフェイスを redfish-virtual-media に設定し、EFI システムパーティション (ESP) イメージを定義します。続いて、登録したノードが Redfish 仮想メディアブートを使用するように設定します。

前提条件

  • undercloud.conf ファイルの enabled_hardware_types パラメーターで、Redfish ドライバーが有効化されている。
  • ベアメタルノードが登録されている。
  • Image サービス (glance) に IPA およびインスタンスイメージがある。
  • UEFI ノードの場合、EFI システムパーティション (ESP) イメージも Image サービス (glance) で利用可能でなければなりません。
  • ベアメタルフレーバー
  • クリーニングおよびプロビジョニング用ネットワーク

手順

  1. アンダークラウドホストに stack ユーザーとしてログインします。
  2. stackrc アンダークラウド認証情報ファイルを入手します。

    $ source ~/stackrc
  3. Bare Metal Provisioning サービスの起動インターフェイスを redfish-virtual-media に設定します。

    (undercloud)$ openstack baremetal node set --boot-interface redfish-virtual-media <node>
    • <node> はノード名に置き換えてください。
  4. ESP イメージを定義します。

    (undercloud)$ openstack baremetal node set --driver-info bootloader=<esp> <node>
    • <esp> を Image サービス (glance) イメージの UUID または ESP イメージの URL に置き換えます。
    • <node> はノード名に置き換えてください。
  5. ベアメタルノードにポートを作成し、そのポートをベアメタルノード上の NIC の MAC アドレスに関連付けます。

    (undercloud)$ openstack baremetal port create --pxe-enabled True \
     --node <node_uuid> <mac_address>
    • <node_uuid> をベアメタルノードの UUID に置き換えます。
    • <mac_address> をベアメタルノードの NIC の MAC アドレスに置き換えます。

11.2.11. マルチディスク Ceph クラスターのルートディスクの定義

Ceph Storage ノードは通常、複数のディスクを使用します。Director は、複数のディスク設定でルートディスクを識別する必要があります。オーバークラウドイメージは、プロビジョニングプロセス中にルートディスクに書き込まれます。

ハードウェアプロパティーは、ルートディスクを識別するために使用されます。ルートディスクを特定するのに使用できるプロパティーの詳細は、「ルートディスクを識別するプロパティー」 を参照してください。

手順

  1. 各ノードのハードウェアイントロスペクションからのディスク情報を確認します。

    (undercloud)$ openstack baremetal introspection data save <node_uuid> | --file <output_file_name>
    • <node_uuid> をノードの UUID に置き換えます。
    • <output_file_name> を、ノードイントロスペクションの出力を含むファイルの名前に置き換えます。

      たとえば、1 つのノードのデータで 3 つのディスクが表示される場合があります。

      [
        {
          "size": 299439751168,
          "rotational": true,
          "vendor": "DELL",
          "name": "/dev/sda",
          "wwn_vendor_extension": "0x1ea4dcc412a9632b",
          "wwn_with_extension": "0x61866da04f3807001ea4dcc412a9632b",
          "model": "PERC H330 Mini",
          "wwn": "0x61866da04f380700",
          "serial": "61866da04f3807001ea4dcc412a9632b"
        }
        {
          "size": 299439751168,
          "rotational": true,
          "vendor": "DELL",
          "name": "/dev/sdb",
          "wwn_vendor_extension": "0x1ea4e13c12e36ad6",
          "wwn_with_extension": "0x61866da04f380d001ea4e13c12e36ad6",
          "model": "PERC H330 Mini",
          "wwn": "0x61866da04f380d00",
          "serial": "61866da04f380d001ea4e13c12e36ad6"
        }
        {
          "size": 299439751168,
          "rotational": true,
          "vendor": "DELL",
          "name": "/dev/sdc",
          "wwn_vendor_extension": "0x1ea4e31e121cfb45",
          "wwn_with_extension": "0x61866da04f37fc001ea4e31e121cfb45",
          "model": "PERC H330 Mini",
          "wwn": "0x61866da04f37fc00",
          "serial": "61866da04f37fc001ea4e31e121cfb45"
        }
      ]
  2. 一意のハードウェアプロパティーを使用して、ノードのルートディスクを設定します。

    (undercloud)$ openstack baremetal node set --property root_device='{<property_value>}' <node-uuid>

    • <property_value> を、ルートディスクの設定に使用するイントロスペクションデータからの一意のハードウェアプロパティー値に置き換えます。
    • <node_uuid> をノードの UUID に置き換えます。

      注記

      一意のハードウェアプロパティーは、ディスクを一意に識別するハードウェアイントロスペクションステップからの任意のプロパティーです。たとえば、次のコマンドは、ディスクのシリアル番号を使用してルートディスクを設定します。

      (undercloud)$ openstack baremetal node set --property root_device='{"serial": "61866da04f380d001ea4e13c12e36ad6"}' 1a4e30da-b6dc-499d-ba87-0bd8a3819bc0

  3. 最初にネットワークから起動し、次にルートディスクから起動するように、各ノードの BIOS を設定します。

director は、ルートディスクとして使用する特定のディスクを把握します。openstack overcloud node provision コマンドを実行すると、director はオーバークラウドをプロビジョニングし、ルートディスクにオーバークラウドのイメージを書き込みます。

11.2.12. ルートディスクを識別するプロパティー

以下の属性を定義すると、director がルートディスクを特定するのに役立ちます。

  • model (文字列): デバイスの ID
  • vendor (文字列): デバイスのベンダー
  • serial (文字列): ディスクのシリアル番号
  • hctl (文字列): SCSI のホスト、チャンネル、ターゲット、Lun
  • size (整数): デバイスのサイズ (GB 単位)
  • wwn (文字列): 一意のストレージ ID
  • wwn_with_extension (文字列): ベンダー拡張子を追加した一意のストレージ ID
  • wwn_vendor_extension (文字列): 一意のベンダーストレージ ID
  • rotational (ブール値): 回転式デバイス (HDD) には true、そうでない場合 (SSD) には false
  • name (文字列): デバイス名 (例: /dev/sdb1)
重要

永続的な名前を持つデバイスには name プロパティーを使用します。ノードの起動時に値が変更される可能性があるため、name プロパティーを使用して永続的な名前を持たないデバイスのルートディスクを設定しないでください。

11.2.13. overcloud-minimal イメージの使用による Red Hat サブスクリプションエンタイトルメントの使用回避

Red Hat OpenStack Platform (RHOSP) デプロイメントのデフォルトイメージは overcloud-hardened-uefi-full.qcow2 です。overcloud-hardened-uefi-full.qcow2 イメージは、有効な Red Hat OpenStack Platform (RHOSP) サブスクリプションを使用します。サブスクリプションのエンタイトルメントを消費したくない場合は overcloud-minimal イメージを使用して、有償の Red Hat サブスクリプションが限度に達するのを回避できます。これは、たとえば Ceph デーモンのみでノードをプロビジョニングする場合や、他の OpenStack サービスを実行したくないベアオペレーティングシステム (OS) をプロビジョニングする場合に役立ちます。overcloud-minimal イメージの取得方法についての情報は、Obtaining images for overcloud nodes を参照してください。

注記

overcloud-minimal イメージでは、標準の Linux ブリッジのみサポートされます。overcloud-minimal イメージでは、Open vSwitch (OVS) はサポートされません。OVS は、Red Hat OpenStack Platform サブスクリプションエンタイトルメントを必要とする OpenStack サービスだからです。Ceph Storage ノードをデプロイするのに OVS は必要ありません。ovs_bond を使用してボンディングを定義する代わりに、linux_bond を使用します。linux_bond の詳細は、Linux ボンディングの作成 を参照してください。

手順

  1. overcloud-baremetal-deploy.yaml ファイルを開きます。
  2. overcloud-minimal イメージを使用するノードの image プロパティーを追加または更新します。特定のノードまたはロールのすべてのノードでイメージを overcloud-minimal に設定できます。

    特定のノード

    - name: Ceph
      count: 3
      instances:
      - hostname: overcloud-ceph-0
        name: node00
        image:
          href: file:///var/lib/ironic/images/overcloud-minimal.qcow2
      - hostname: overcloud-ceph-1
        name: node01
        image:
          href: file:///var/lib/ironic/images/overcloud-full-custom.qcow2
      - hostname: overcloud-ceph-2
        name: node02
        image:
          href: file:///var/lib/ironic/images/overcloud-full-custom.qcow2

    ロールのすべてのノード

    - name: Ceph
      count: 3
      defaults:
        image:
          href: file:///var/lib/ironic/images/overcloud-minimal.qcow2
      instances:
      - hostname: overcloud-ceph-0
        name: node00
      - hostname: overcloud-ceph-1
        name: node01
      - hostname: overcloud-ceph-2
        name: node02

  3. roles_data.yaml ロール定義ファイルで、rhsm_enforce パラメーターを False に設定します。

    rhsm_enforce: False
  4. プロビジョニングコマンドを実行します。

    (undercloud)$ openstack overcloud node provision \
    --stack stack \
    --output /home/stack/templates/overcloud-baremetal-deployed.yaml \
    /home/stack/templates/overcloud-baremetal-deploy.yaml
  5. overcloud-baremetal-deployed.yaml 環境ファイルを openstack overcloud deploy コマンドに渡します。

11.3. オーバークラウドの設定およびデプロイ

オーバークラウドのネットワークリソースとベアメタルノードをプロビジョニングしたら、director のインストールで提供される未編集の heat テンプレートファイルと、作成したカスタム環境ファイルを使用して、オーバークラウドを設定できます。オーバークラウドの設定が完了したら、オーバークラウド環境をデプロイできます。

重要

基本的なオーバークラウドでは、Block Storage にローカルの LVM ストレージを使用しますが、この設定はサポートされません。Red Hat では、Block Storage に Red Hat Ceph Storage などの外部ストレージソリューションを使用することを推奨しています。

11.3.1. 前提条件

  • オーバークラウドに必要なネットワークリソースとベアメタルノードをプロビジョニングしている。

11.3.2. 環境ファイルを使用したオーバークラウドの設定

アンダークラウドには、オーバークラウドの作成プランを形作るさまざまな heat テンプレートが含まれます。YAML フォーマットの環境ファイルを使用して、オーバークラウドの特性をカスタマイズすることができます。このファイルで、コア heat テンプレートコレクションのパラメーターおよびリソースを上書きします。必要に応じていくつでも環境ファイルを追加することができます。環境ファイルの拡張子は .yaml または .template にする必要があります。

Red Hat では、カスタム環境ファイルを別のディレクトリーで管理することを推奨します (たとえば、templates ディレクトリー)。

-e オプションを使用して、環境ファイルをオーバークラウドデプロイメントに含めます。-e オプションを使用してオーバークラウドに追加した環境ファイルはいずれも、オーバークラウドのスタック定義の一部となります。後で指定する環境ファイルで定義されるパラメーターとリソースが優先されることになるため、環境ファイルの順番は重要です。

初回のデプロイメント後にオーバークラウド設定を変更するには、以下のアクションを実行します。

  1. カスタムの環境ファイルおよび heat テンプレートのパラメーターを変更します。
  2. 同じ環境ファイルを指定して openstack overcloud deploy コマンドを再度実行します。

オーバークラウドの設定は直接編集しないでください。手動で設定しても、オーバークラウドスタックの更新時に、director が設定を上書きするためです。

注記

Open Virtual Networking (OVN) は、Red Hat OpenStack Platform 17.0 におけるデフォルトのネットワークメカニズムドライバーです。分散仮想ルーター (DVR) で OVN を使用する場合には、openstack overcloud deploy コマンドに environments/services/neutron-ovn-dvr-ha.yaml ファイルを追加する必要があります。DVR なしで OVN を使用する場合には、openstack overcloud deploy コマンドに environments/services/neutron-ovn-ha.yaml ファイルを追加する必要があります。

11.3.3. アンダークラウド CA を信頼するための環境ファイルの作成

アンダークラウドで TLS を使用され認証局 (CA) が一般に信頼できない場合には、SSL エンドポイント暗号化にアンダークラウドが運用する CA を使用することができます。デプロイメントの他の要素からアンダークラウドのエンドポイントにアクセスできるようにするには、アンダークラウドの CA を信頼するようにオーバークラウドノードを設定します。

注記

この手法が機能するためには、オーバークラウドノードにアンダークラウドの公開エンドポイントへのネットワークルートが必要です。スパイン/リーフ型ネットワークに依存するデプロイメントでは、この設定を適用する必要があります。

アンダークラウドで使用することのできるカスタム証明書には、2 つのタイプがあります。

  • ユーザーの提供する証明書: 自己の証明書を提供している場合がこれに該当します。自己の CA からの証明書、または自己署名の証明書がその例です。この証明書は undercloud_service_certificate オプションを使用して渡されます。この場合、自己署名の証明書または CA のどちらかを信頼する必要があります (デプロイメントによります)。
  • 自動生成される証明書: certmonger により自己のローカル CA を使用して証明書を生成する場合がこれに該当します。undercloud.conf ファイルの generate_service_certificate オプションを使用して、証明書の自動生成を有効にします。この場合、director は CA 証明書 /etc/pki/ca-trust/source/anchors/cm-local-ca.pem を生成し、アンダークラウドの HAProxy インスタンスがサーバー証明書を使用するように設定します。この CA 証明書を OpenStack Platform に配置するには、証明書を inject-trust-anchor-hiera.yaml ファイルに追加します。

以下の例では、/home/stack/ca.crt.pem に保存された自己署名の証明書が使われています。自動生成される証明書を使用する場合には、代わりに /etc/pki/ca-trust/source/anchors/cm-local-ca.pem を使用してください。

手順

  1. 証明書ファイルを開き、証明書部分だけをコピーします。鍵を含めないでください。

    $ vi /home/stack/ca.crt.pem

    必要となる証明書部分の例を、以下に示します。

    -----BEGIN CERTIFICATE-----
    MIIDlTCCAn2gAwIBAgIJAOnPtx2hHEhrMA0GCSqGSIb3DQEBCwUAMGExCzAJBgNV
    BAYTAlVTMQswCQYDVQQIDAJOQzEQMA4GA1UEBwwHUmFsZWlnaDEQMA4GA1UECgwH
    UmVkIEhhdDELMAkGA1UECwwCUUUxFDASBgNVBAMMCzE5Mi4xNjguMC4yMB4XDTE3
    -----END CERTIFICATE-----
  2. 以下に示す内容で /home/stack/inject-trust-anchor-hiera.yaml という名称の新たな YAML ファイルを作成し、PEM ファイルからコピーした証明書を追加します。

    parameter_defaults:
      CAMap:
        undercloud-ca:
          content: |
            -----BEGIN CERTIFICATE-----
            MIIDlTCCAn2gAwIBAgIJAOnPtx2hHEhrMA0GCSqGSIb3DQEBCwUAMGExCzAJBgNV
            BAYTAlVTMQswCQYDVQQIDAJOQzEQMA4GA1UEBwwHUmFsZWlnaDEQMA4GA1UECgwH
            UmVkIEhhdDELMAkGA1UECwwCUUUxFDASBgNVBAMMCzE5Mi4xNjguMC4yMB4XDTE3
            -----END CERTIFICATE-----
    注記
    • 証明書の文字列は、PEM の形式に従う必要があります。
    • CAMap パラメーターには、SSL/TLS 設定に関連する他の証明書が含まれる場合があります。
  3. /home/stack/inject-trust-anchor-hiera.yaml ファイルをデプロイコマンドに追加します。director は、オーバークラウドのデプロイメント時に CA 証明書をそれぞれのオーバークラウドノードにコピーします。これにより、それぞれのノードはアンダークラウドの SSL エンドポイントが提示する暗号化を信頼するようになります。

11.3.4. 新規デプロイメントでの TSX の無効化

Red Hat Enterprise Linux 8.3 以降、カーネルは、デフォルトで Intel Transactional Synchronization Extensions (TSX) 機能のサポートを無効にします。

ワークロードまたはサードパーティーベンダー用に厳密に要求しない限り、新しいオーバークラウドで TSX を明示的に無効にする必要があります。

環境ファイルで KernelArgs heat パラメーターを設定します。

parameter_defaults:
    ComputeParameters:
       KernelArgs: "tsx=off"

openstack overcloud deploy コマンドを実行する際に、環境ファイルを指定します。

11.3.5. オーバークラウド設定の検証

オーバークラウドをデプロイする前に、heat テンプレートと環境ファイルを検証します。

重要
  • 17.0 で API が変更されたため、現在、次の検証は不安定になっています。

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

手順

  1. アンダークラウドホストに stack ユーザーとしてログインします。
  2. stackrc アンダークラウド認証情報ファイルを入手します。

    $ source ~/stackrc
  3. デプロイメントに必要なすべての環境ファイルを使用してオーバークラウドスタックを更新します。

    $ openstack overcloud deploy --templates \
      -e environment-file1.yaml \
      -e environment-file2.yaml \
      ...
      --stack-only
  4. オーバークラウドスタックを検証します。

    $ validation run \
      --group pre-deployment \
      --inventory <inventory_file>
    • <inventory_file> ファイルを Ansible インベントリーファイルの名前および場所に置き換えます (例: ~/tripleo-deploy/undercloud/tripleo-ansible-inventory.yaml)。
    注記

    検証を実行すると、出力の Reasons 列は 79 文字に制限されます。検証結果を完全に表示するには、検証ログファイルを表示します。

  5. 検証レポートの結果を確認します。

    $ validation history get [--full] [--validation-log-dir <log_dir>] <uuid>
    • オプション: --full オプションを使用して、検証実行からの詳細な出力を表示します。
    • オプション: --validation-log-dir オプションを使用して、検証実行の出力を検証ログに書き込みます。
    • <uuid> は、検証実行の UUID に置き換えます。

11.3.6. オーバークラウドの作成

Red Hat OpenStack Platform (RHOSP) オーバークラウド環境を作成する最後の段階は、openstack overcloud deploy コマンドを実行してオーバークラウドを作成することです。openstack overcloud deploy コマンドで使用できるオプションについては、デプロイメントコマンドのオプション を参照してください。

手順

  1. オーバークラウド環境に必要な環境ファイルと設定ファイル (director のインストールで提供される未編集の heat テンプレートファイルと作成したカスタム環境ファイルの両方) を照合します。これには、次のファイルが含まれている必要があります。

    • overcloud-baremetal-deployed.yaml ノード定義ファイル。
    • overcloud-networks-deployed.yaml ネットワーク定義ファイル。
    • overcloud-vip-deployed.yaml ネットワーク VIP 定義ファイル。
    • コンテナー化された OpenStack サービスのコンテナーイメージの場所。
    • Red Hat CDN または Satellite 登録用の環境ファイル
    • その他のカスタム環境ファイル
  2. 環境ファイルと設定ファイルを優先順位に従って整理し、編集されていない Heat テンプレートファイル、その次にデフォルトプロパティーのオーバーライドなどのカスタム設定を含む環境ファイルをリストします。
  3. 以下の例のように、設定ファイルとテンプレートを必要な順序で指定して、openstack overcloud deploy コマンドを作成します。

    (undercloud) $ openstack overcloud deploy --templates \
     [-n /home/stack/templates/network_data.yaml \ ]
      -e /home/stack/templates/overcloud-baremetal-deployed.yaml\
      -e /home/stack/templates/overcloud-networks-deployed.yaml\
      -e /home/stack/templates/overcloud-vip-deployed.yaml \
      -e /home/stack/containers-prepare-parameter.yaml \
      -e /home/stack/inject-trust-anchor-hiera.yaml \
     [-r /home/stack/templates/roles_data.yaml ]
    -n /home/stack/templates/network_data.yaml
    カスタムネットワーク設定を指定します。ネットワーク分離またはカスタム設定可能なネットワークを使用する場合に必要です。オーバークラウドネットワークの設定は、オーバークラウドネットワークの設定 を参照してください。
    -e /home/stack/containers-prepare-parameter.yaml
    コンテナーイメージ準備の環境ファイルを追加します。このファイルはアンダークラウドのインストール時に生成したもので、オーバークラウドの作成に同じファイルを使用することができます。
    -e /home/stack/inject-trust-anchor-hiera.yaml
    アンダークラウドにカスタム証明書をインストールする環境ファイルを追加します。
    -r /home/stack/templates/roles_data.yaml
    カスタムロールを使用する、またはマルチアーキテクチャークラウドを有効にする場合に生成されるロールデータ。
  4. オーバークラウドの作成が完了すると、オーバークラウドを設定するために実施された Ansible のプレイの概要が director により提示されます。

    PLAY RECAP *************************************************************
    overcloud-compute-0     : ok=160  changed=67   unreachable=0    failed=0
    overcloud-controller-0  : ok=210  changed=93   unreachable=0    failed=0
    undercloud              : ok=10   changed=7    unreachable=0    failed=0
    
    Tuesday 15 October 2018  18:30:57 +1000 (0:00:00.107) 1:06:37.514 ******
    ========================================================================
  5. オーバークラウドの作成が完了すると、director はオーバークラウドにアクセスするための詳細を提供します。

    Ansible passed.
    Overcloud configuration completed.
    Overcloud Endpoint: http://192.168.24.113:5000
    Overcloud Horizon Dashboard URL: http://192.168.24.113:80/dashboard
    Overcloud rc file: /home/stack/overcloudrc
    Overcloud Deployed
ヒント

新しい環境ファイルで設定を更新するたびに追加するファイルに、デプロイメントコマンドを格納できます。

11.3.7. デプロイメントコマンドのオプション

以下の表には、openstack overcloud deploy コマンドの追加パラメーターをまとめています。

重要

一部のオプションは、本リリースでは テクノロジープレビュー として提供されているため、Red Hat では全面的にはサポートしていません。これらはテスト目的にのみご利用いただく機能で、実稼働環境で使用すべきではありません。テクノロジープレビュー機能についての詳しい情報は、対象範囲の詳細 を参照してください。

表11.8 デプロイメントコマンドのオプション

パラメーター説明

--templates [TEMPLATES]

デプロイする heat テンプレートが含まれるディレクトリー。空欄にした場合には、デプロイメントコマンドはデフォルトのテンプレートの場所である /usr/share/openstack-tripleo-heat-templates/ を使用します。

--stack STACK

作成または更新するスタックの名前

-t [TIMEOUT]--timeout [TIMEOUT]

デプロイメントのタイムアウト時間 (分単位)

--libvirt-type [LIBVIRT_TYPE]

ハイパーバイザーに使用する仮想化タイプ

--ntp-server [NTP_SERVER]

時刻の同期に使用する Network Time Protocol (NTP) サーバー。コンマ区切りリストで複数の NTP サーバーを指定することも可能です (例: --ntp-server 0.centos.pool.org,1.centos.pool.org)。高可用性クラスターのデプロイメントの場合には、コントローラーノードが一貫して同じ時刻ソースを参照することが重要です。標準的な環境には、確立された慣行によって、NTP タイムソースがすでに指定されている可能性がある点に注意してください。

--no-proxy [NO_PROXY]

環境変数 no_proxy のカスタム値を定義します。これにより、プロキシー通信から特定のホスト名は除外されます。

--overcloud-ssh-user OVERCLOUD_SSH_USER

オーバークラウドノードにアクセスする SSH ユーザーを定義します。通常、SSH アクセスは tripleo-admin ユーザーを介して行われます。

--overcloud-ssh-key OVERCLOUD_SSH_KEY

オーバークラウドノードへの SSH アクセスに使用する鍵のパスを定義します。

--overcloud-ssh-network OVERCLOUD_SSH_NETWORK

オーバークラウドノードへの SSH アクセスに使用するネットワーク名を定義します。

-e [EXTRA HEAT TEMPLATE]--environment-file [ENVIRONMENT FILE]

オーバークラウドのデプロイメントに渡す追加の環境ファイル。このオプションは複数回指定することができます。openstack overcloud deploy コマンドに渡す環境ファイルの順序が重要である点に注意してください。たとえば、逐次的に渡される各環境ファイルは、前の環境ファイルのパラメーターを上書きします。

--environment-directory

デプロイメントに追加する環境ファイルが含まれるディレクトリー。デプロイメントコマンドでは、これらの環境ファイルは最初に番号順、その後にアルファベット順で処理されます。

-r ROLES_FILE

ロールファイルを定義し、--templates ディレクトリーのデフォルトの roles_data.yaml を上書きします。ファイルの場所は、絶対パスまたは --templates に対する相対パスになります。

-n NETWORKS_FILE

ネットワークファイルを定義し、--templates ディレクトリーのデフォルトの network_data.yaml を上書きします。ファイルの場所は、絶対パスまたは --templates に対する相対パスになります。

-p PLAN_ENVIRONMENT_FILE

プラン環境ファイルを定義し、--templates ディレクトリーのデフォルトの plan-environment.yaml を上書きします。ファイルの場所は、絶対パスまたは --templates に対する相対パスになります。

--no-cleanup

デプロイメント後に一時ファイルを削除せず、それらの場所をログに記録するには、このオプションを使用します。

--update-plan-only

実際のデプロイメントを実行せずにプランを更新するには、このオプションを使用します。

--validation-errors-nonfatal

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

--validation-warnings-fatal

オーバークラウドの作成プロセスでは、デプロイメントの前に一連のチェックが行われます。このオプションは、デプロイメント前のチェックで何らかのクリティカルではない警告が発生した場合に終了します。

--dry-run

オーバークラウドを作成せずにオーバークラウドで検証チェックを実行するには、このオプションを使用します。

--run-validations

openstack-tripleo-validations パッケージで提供される外部検証を実行するには、このオプションを使用します。

--skip-postconfig

オーバークラウドデプロイ後の設定を省略するには、このオプションを使用します。

--force-postconfig

オーバークラウドデプロイ後の設定を強制的に行うには、このオプションを使用します。

--skip-deploy-identifier

デプロイメントコマンドで DeployIdentifier パラメーターの一意の ID を生成するのを希望しない場合は、このオプションを使用します。ソフトウェア設定のデプロイメントステップは、実際に設定が変更された場合にしか実行されません。このオプションの使用には注意が必要です。特定のロールをスケールアウトする時など、ソフトウェア設定の実行が明らかに不要な場合にしか使用しないでください。

--answers-file ANSWERS_FILE

引数とパラメーターが記載された YAML ファイルへのパス

--disable-password-generation

オーバークラウドサービスのパスワード生成を無効にする場合は、このオプションを使用します。

--deployed-server

事前にプロビジョニングされたオーバークラウドノードをデプロイする場合は、このオプションを使用します。--disable-validations と併用されます。

--no-config-download, --stack-only

config-download ワークフローを無効にして、スタックおよび関連する OpenStack リソースだけを作成する場合は、このオプションを使用します。このコマンドによってオーバークラウドにソフトウェア設定が適用されることはありません。

--config-download-only

オーバークラウドスタックの作成を無効にして、ソフトウェア設定を適用する config-download ワークフローだけを実行する場合は、このオプションを使用します。

--output-dir OUTPUT_DIR

保存した config-download の出力に使用するディレクトリー。ディレクトリーは mistral ユーザーが書き込み可能でなければなりません。指定しない場合、director はデフォルトの /var/lib/mistral/overcloud を使用します。

--override-ansible-cfg OVERRIDE_ANSIBLE_CFG

Ansible 設定ファイルへのパス。このファイルの設定は、config-download がデフォルトで生成する設定を上書きします。

--config-download-timeout CONFIG_DOWNLOAD_TIMEOUT

config-download のステップに使用するタイムアウト時間 (分単位)。設定しなければ、スタックデプロイメント操作後の --timeout パラメーターの残り時間にかかわらず、director はデフォルトをその時間に設定します。

--limit NODE1,NODE2

(テクノロジープレビュー) config-download Playbook の実行を特定のノードまたはノードセットに制限する場合は、このオプションを使用してノードのコンマ区切りリストを指定します。たとえば、--limit オプションは、スケールアップ操作時に新規ノード上でのみ config-download を実行する場合に役立ちます。この引数により、ホスト間のインスタンスのライブマイグレーションが失敗する可能性があります。ansible-playbook-command.sh スクリプトを使用した config-download の実行 を参照してください。

--tags TAG1,TAG2

(テクノロジープレビュー) config-download の特定のタスクセットでデプロイメントを実施する場合は、このオプションを使用して config-download Playbook からのタグのコンマ区切りリストを指定します。

--skip-tags TAG1,TAG2

(テクノロジープレビュー) config-download Playbook のタグの一部を省略する場合は、このオプションを使用して省略するタグのコンマ区切りリストを指定します。

オプションの全リストを表示するには、以下のコマンドを実行します。

(undercloud) $ openstack help overcloud deploy

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

表11.9 非推奨の CLI パラメーターと heat テンプレートのパラメーターの対照表

パラメーター説明heat テンプレートのパラメーター

--control-scale

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

ControllerCount

--compute-scale

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

ComputeCount

--ceph-storage-scale

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

CephStorageCount

--block-storage-scale

スケールアウトする Block Storage (cinder) ノード数

BlockStorageCount

--swift-storage-scale

スケールアウトする Object Storage (swift) ノード数

ObjectStorageCount

--control-flavor

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

OvercloudControllerFlavor

--compute-flavor

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

OvercloudComputeFlavor

--ceph-storage-flavor

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

OvercloudCephStorageFlavor

--block-storage-flavor

Block Storage (cinder) ノードに使用するフレーバー

OvercloudBlockStorageFlavor

--swift-storage-flavor

Object Storage (swift) ノードに使用するフレーバー

OvercloudSwiftStorageFlavor

--validation-errors-fatal

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

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

--disable-validations

デプロイメント前の検証を完全に無効にします。これらの検証は、デプロイメント前の検証として組み込まれていましたが、openstack-tripleo-validations パッケージで提供される外部検証に置き換えられています。

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

--config-download

config-download のメカニズムを使用してデプロイメントを実行します。これは現在のデフォルトであり、この CLI のオプションは今後廃止される可能性があります。

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

--rhel-reg

カスタマーポータルまたは Satellite 6 にオーバークラウドノードを登録する場合は、このオプションを使用します。

RhsmVars

--reg-method

このオプションを使用して、オーバークラウドノードの登録方法を定義します。Red Hat Satellite 6 または Red Hat Satellite 5 の場合は satellite、カスタマーポータルの場合は portal に設定します。

RhsmVars

--reg-org [REG_ORG]

登録に使用する組織。

RhsmVars

--reg-force

すでに登録済みでもシステムを登録する場合は、このオプションを使用します。

RhsmVars

--reg-sat-url [REG_SAT_URL]

オーバークラウドノードを登録する Satellite サーバーのベース URL。このパラメーターには、HTTPS URL ではなく、Satellite の HTTP URL を使用します。たとえば、https://satellite.example.com ではなく http://satellite.example.com を使用します。オーバークラウドの作成プロセスではこの URL を使用して、どのサーバーが Red Hat Satellite 5 または Red Hat Satellite 6 サーバーであるかを判断します。サーバーが Red Hat Satellite 6 サーバーの場合は、オーバークラウドは katello-ca-consumer-latest.noarch.rpm ファイルを取得して subscription-manager に登録し、katello-agent をインストールします。サーバーが Red Hat Satellite 5 サーバーの場合にはオーバークラウドは RHN-ORG-TRUSTED-SSL-CERT ファイルを取得して rhnreg_ks に登録します。

RhsmVars

--reg-activation-key [REG_ACTIVATION_KEY]

登録に使用するアクティベーションキーを定義する場合は、このオプションを使用します。

RhsmVars

これらのパラメーターは、Red Hat OpenStack Platform の今後のリリースで廃止される予定です。

11.3.8. オーバークラウドのデプロイメントの検証

デプロイされたオーバークラウドを検証します。

前提条件

  • オーバークラウドをデプロイしている。

手順

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

    $ source ~/stackrc
  2. オーバークラウドのデプロイメントを検証します。

    $ validation run \
      --group post-deployment \
      [--inventory <inventory_file>]
    • <inventory_file> は ansible インベントリーファイルの名前に置き換えます。デフォルトでは、動的インベントリーは tripleo-ansible-inventory と呼ばれます。

      注記

      検証を実行すると、出力の Reasons 列は 79 文字に制限されます。検証結果を完全に表示するには、検証ログファイルを表示します。

  3. 検証レポートの結果を確認します。

    $ validation show run [--full] <UUID>
    • <UUID> は、検証実行の UUID に置き換えます。
    • オプション: --full オプションを使用して、検証実行からの詳細な出力を表示します。
重要

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

11.3.9. オーバークラウドへのアクセス

director は、アンダークラウドからのオーバークラウドの操作に必要な認証情報を含めて認証情報ファイルを生成します。director は、このファイル overcloudrcstack ユーザーのホームディレクトリーに保存します。

手順

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

    (undercloud)$ source ~/overcloudrc

    オーバークラウドにアクセスしていることを示すコマンドプロンプトに切り替わります。

    (overcloud)$
  2. アンダークラウドの操作に戻るには、stackrc ファイルを読み込みます。

    (overcloud)$ source ~/stackrc
    (undercloud)$

    アンダークラウドにアクセスしていることを示すコマンドプロンプトに切り替わります。

    (undercloud)$

11.4. 事前にプロビジョニングされたノードを使用した基本的なオーバークラウドの設定

本章では、事前にプロビジョニングされたノードを使用して Red Hat OpenStack Platform (RHOSP) 環境を設定するのに使用できる基本的な設定手順を説明します。以下のシナリオは、標準のオーバークラウド作成のシナリオとはさまざまな点で異なります。

  • 外部ツールを使用してノードをプロビジョニングしてから、director でオーバークラウドの設定のみを制御することができます。
  • director のプロビジョニングの方法に依存せずにノードを使用することができます。これは、電源管理制御を設定せずにオーバークラウドを作成する場合や、DHCP/PXE ブートの制限があるネットワークを使用する場合に便利です。
  • director では、ノードを管理するのに OpenStack Compute (nova)、OpenStack Bare Metal (ironic)、または OpenStack Image (glance) を使用しません。
  • 事前にプロビジョニングされたノードでは、QCOW2 overcloud-full イメージに依存しないカス