director のインストールと使用方法
Red Hat OpenStack Platform director を使用した OpenStack クラウド作成のエンドツーエンドシナリオ
OpenStack Documentation Team
rhos-docs@redhat.com概要
多様性を受け入れるオープンソースの強化
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 つの主要な概念を採用しています。まずアンダークラウドをインストールし、続いてアンダークラウドをツールとして使用してオーバークラウドをインストールおよび設定します。
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 |
|
| $HOME/tripleo-deploy/<stack> |
|
| $HOME/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-* |
|
| config-download |
|
| environment |
|
| heat-launcher | 一時的な Heat 設定とデータベースのバックアップを含む一時的な Heat 作業ディレクトリー。 |
| outputs |
|
| <stack>-deployment_status.yaml | 保存されたスタックステータスが含まれます。 |
| <stack>-export.yaml |
|
| <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 テンプレートのコピーが含まれています。ソーステンプレートは |
| tripleo-overcloud-baremetal-deployment.yaml | オーバークラウドノードをプロビジョニングするためのベアメタルデプロイメントの入力。 |
| tripleo-overcloud-network-data.yaml | オーバークラウドネットワークをプロビジョニングするためのネットワークデプロイメントの入力。 |
| tripleo-overcloud-roles-data.yaml |
CLI の |
| 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 標準スイッチのセキュリティー保護 を参照してください。
-
IPv4
これらの設定を適用したら、director 仮想マシンの電源を一旦オフにしてから再投入する必要があります。仮想マシンを再起動するだけでは不十分です。
-
Red Hat Enterprise Virtualization:
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_envPAM モジュールのバッファーが固定されているため、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) |
| x86_64 システム用ベースオペレーティングシステムのリポジトリー |
| Red Hat Enterprise Linux 9 for x86_64 - AppStream (RPMs) |
| Red Hat OpenStack Platform の依存関係が含まれます。 |
| Red Hat Enterprise Linux 9 for x86_64 - High Availability (RPMs) Extended Update Support (EUS) |
| Red Hat Enterprise Linux の高可用性ツール。コントローラーノードの高可用性に使用します。 |
| Red Hat OpenStack Platform 17.0 for RHEL 9 (RPMs) |
| Red Hat OpenStack Platform のコアリポジトリー。Red Hat OpenStack Platform director のパッケージが含まれます。 |
| Red Hat Fast Datapath for RHEL 9 (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 テンプレートにしかパラメーターを適用しません。この例では、MyIP は my_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- このディレクトリーには、追加機能を有効にするのに使用できるテンプレートが含まれます。
firstboot-
このディレクトリーには、ノードの初回作成時に director が使用する
first_bootスクリプトの例が含まれています。
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 コマンドは、以下のプロセスを順に実行します。
- コア heat テンプレートコレクションからデフォルト設定を読み込みます。
-
environment-file-1.yamlの設定を適用します。この設定により、デフォルト設定と共通している設定は上書きされます。 -
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 リポジトリーを作成します。
テンプレートコレクションを
/home/stack/templatesディレクトリーにコピーします。$ cd ~/templates $ cp -r /usr/share/openstack-tripleo-heat-templates .
カスタムテンプレートのディレクトリーに移動して git リポジトリーを初期化します。
$ cd ~/templates/openstack-tripleo-heat-templates $ git init .
Git のユーザー名およびメールアドレスを設定します。
$ git config --global user.name "<USER_NAME>" $ git config --global user.email "<EMAIL_ADDRESS>"
-
<USER_NAME>を使用するユーザー名に置き換えます。 <EMAIL_ADDRESS>をご自分のメールアドレスに置き換えます。初期コミットに向けて全テンプレートをステージします。
$ git add *
初期コミットを作成します。
$ git commit -m "Initial creation of custom core heat templates"
これで、最新のコアテンプレートコレクションを格納する初期
masterブランチが作成されます。このブランチは、カスタムブランチのベースとして使用し、新規テンプレートバージョンをこのブランチにマージします。
カスタムブランチを使用して、コアテンプレートコレクションの変更を保管します。以下の手順に従って
my-customizationsブランチを作成し、カスタマイズを追加します。my-customizationsブランチを作成して、そのブランチに切り替えます。$ git checkout -b my-customizations
- カスタムブランチ内のファイルを編集します。
変更を git にステージします。
$ git add [edited files]カスタムブランチに変更をコミットします。
$ git commit -m "[Commit message for custom changes]"このコマンドにより、変更がコミットとして
my-customizationsブランチに追加されます。masterブランチを更新するには、masterからmy-customizationsにリベースすると、git はこれらのコミットを更新されたテンプレートに追加します。これは、カスタマイズをトラッキングして、今後テンプレートが更新された際にそれらを再生するのに役立ちます。
アンダークラウドの更新時には、
openstack-tripleo-heat-templatesパッケージも更新を受け取る可能性があります。このような場合には、カスタムテンプレートコレクションも更新する必要があります。openstack-tripleo-heat-templatesパッケージのバージョンを環境変数として保存します。$ export PACKAGE=$(rpm -qv openstack-tripleo-heat-templates)
テンプレートコレクションのディレクトリーに移動して、更新されたテンプレート用に新規ブランチを作成します。
$ cd ~/templates/openstack-tripleo-heat-templates $ git checkout -b $PACKAGE
そのブランチの全ファイルを削除して、新しいバージョンに置き換えます。
$ git rm -rf * $ cp -r /usr/share/openstack-tripleo-heat-templates/* .
初期コミット用にすべてのテンプレートを追加します。
$ git add *
パッケージ更新のコミットを作成します。
$ git commit -m "Updates for $PACKAGE"
このブランチを master にマージします。git 管理システム (例: GitLab) を使用している場合には、管理ワークフローを使用してください。git をローカルで使用している場合には、
masterブランチに切り替えてからgit mergeコマンドを実行してマージします。$ git checkout master $ git merge $PACKAGE
master ブランチに最新のコアテンプレートコレクションが含まれるようになりました。これで、my-customization ブランチを更新されたコレクションからリベースできます。
my-customizationブランチを更新します。my-customizationsブランチに切り替えます。$ git checkout my-customizations
このブランチを
masterからリベースします。$ git rebase master
これにより、
my-customizationsブランチが更新され、このブランチに追加されたカスタムコミットが再生されます。
リベース中に発生する競合を解決します。
どのファイルで競合が発生しているかを確認します。
$ git status
- 特定したテンプレートファイルで競合を解決します。
解決したファイルを追加します。
$ git add [resolved files]リベースを続行します。
$ git rebase --continue
カスタムテンプレートコレクションをデプロイします。
必ず
my-customizationブランチに切り替えた状態にします。git checkout my-customizations
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: 特定のサービスのデフォルトパラメーター
これらのパラメーターの値は、以下の方法で変更することができます。
- カスタムパラメーター用の環境ファイルを作成します。
-
その環境ファイルの
parameter_defaultsセクションにカスタムのパラメーターを追加します。 -
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 パラメーターを設定するには、ControllerParameters と ComputeParameters パラメーターの両方が含まれる環境ファイルを作成し、特定のロールごとに 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 を使用してオプションを設定するには、以下のワークフローに従ってオプションを確認し、特定のオーバークラウドパラメーターにマッピングしてください。
- 設定するオプションを特定します。そのオプションを使用するサービスを書き留めておきます。
このオプションに対応する Puppet モジュールを確認します。Red Hat OpenStack Platform 用の Puppet モジュールは director ノードの
/etc/puppet/modulesにあります。各モジュールは、特定のサービスに対応しています。たとえば、keystoneモジュールは OpenStack Identity (keystone) に対応しています。- 選択したオプションを制御する変数が Puppet モジュールに含まれている場合には、次のステップに進んでください。
- 選択したオプションを制御する変数が Puppet モジュールに含まれていない場合には、そのオプションには hieradata は存在しません。可能な場合には、オーバークラウドがデプロイメントを完了した後でオプションを手動で設定することができます。
コア heat テンプレートコレクションに hieradata 形式の Puppet 変数が含まれているかどうかを確認します。
deployment/*は通常、同じサービスの Puppet モジュールに対応します。たとえば、deployment/keystone/keystone-container-puppet.yamlテンプレートは、keystoneモジュールの hieradata を提供します。- heat テンプレートが Puppet 変数用の hieradata を設定している場合には、そのテンプレートは変更することのできる director ベースのパラメーターも開示する必要があります。
- heat テンプレートが Puppet 変数用の hieradata を設定していない場合には、環境ファイルを使用して、設定フックにより hieradata を渡します。hieradata のカスタマイズに関する詳細は、「Puppet: ロール用 hieradata のカスタマイズ」 を参照してください。
手順
OpenStack Identity (keystone) の通知の形式を変更するには、ワークフローを使用して、以下の手順を実施します。
-
設定する OpenStack パラメーターを特定します (
notification_format)。 keystonePuppet モジュールでnotification_formatの設定を検索します。$ grep notification_format /etc/puppet/modules/keystone/manifests/*
この場合は、
keystoneモジュールはkeystone::notification_formatの変数を使用してこのオプションを管理します。keystoneサービステンプレートでこの変数を検索します。$ grep "keystone::notification_format" /usr/share/openstack-tripleo-heat-templates/deployment/keystone/keystone-container-puppet.yaml
このコマンドの出力には、director が
KeystoneNotificationFormatパラメーターを使用してkeystone::notification_formathieradata を設定していると表示されます。
-
設定する OpenStack パラメーターを特定します (
最終的なマッピングは、以下の表のとおりです。
| director のパラメーター | Puppet hieradata | OpenStack Identity (keystone) のオプション |
|---|---|---|
|
|
|
|
オーバークラウドの環境ファイルで 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 ファイルに変数のネームサーバーを追加します。
手順
ノードの
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パラメーターは、設定を適用するタイミングを定義します。上記の例では、オーバークラウドが作成または更新された時に設定を適用します。設定可能なアクションはCREATE、UPDATE、DELETE、SUSPEND、およびRESUMEです。 -
input_valuesではdeploy_identifierというパラメーターを定義し、親テンプレートからのDeployIdentifierを格納します。このパラメーターにより、各デプロイメント更新のリソースにタイムスタンプが提供されます。これにより、これ以降のオーバークラウド更新時にリソースが再度適用されるようになります。
-
heat テンプレートをロールベースのリソース種別として登録する環境ファイル (
~/templates/pre_config.yaml) を作成します。たとえば、コントローラーノードだけに設定を適用するには、ControllerExtraConfigPreフックを使用します。resource_registry: OS::TripleO::ControllerExtraConfigPre: /home/stack/templates/nameserver.yaml parameter_defaults: nameserver_ip: 192.168.1.1
その他の環境ファイルと共に環境ファイルをスタックに追加します。
$ 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 ファイルに変数のネームサーバーを追加します。
手順
各ノードの
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パラメーターは、設定を適用するタイミングを定義します。上記の例では、オーバークラウドが作成または更新された時にのみ設定を適用します。設定可能なアクションはCREATE、UPDATE、DELETE、SUSPEND、およびRESUMEです。 -
input_valuesパラメーターではdeploy_identifierというサブパラメーターを定義し、親テンプレートからのDeployIdentifierを格納します。このパラメーターにより、各デプロイメント更新のリソースにタイムスタンプが提供されます。これにより、これ以降のオーバークラウド更新時にリソースが再度適用されるようになります。
-
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
その他の環境ファイルと共に環境ファイルをスタックに追加します。
$ 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 ファイルに変数のネームサーバーを追加します。
手順
各ノードの
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パラメーターは、設定を適用するタイミングを定義します。上記の例では、オーバークラウドが作成または更新された時に設定を適用します。設定可能なアクションはCREATE、UPDATE、DELETE、SUSPEND、およびRESUMEです。 -
input_valuesではdeploy_identifierというパラメーターを定義し、親テンプレートからのDeployIdentifierを格納します。このパラメーターにより、各デプロイメント更新のリソースにタイムスタンプが提供されます。これにより、これ以降のオーバークラウド更新時にリソースが再度適用されるようになります。
-
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
その他の環境ファイルと共に環境ファイルをスタックに追加します。
$ 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
- すべてのノードに追加する設定
手順
デプロイ後の設定プロセスに設定を追加するには、
parameter_defaultsセクションにこれらのパラメーターが記載された環境ファイルを作成します。たとえば、コンピュートホストに確保するメモリーを 1024 MB に増やし VNC キーマップを日本語に指定するには、ComputeExtraConfigパラメーターの以下のエントリーを使用します。parameter_defaults: ComputeExtraConfig: nova::compute::reserved_host_memory: 1024 nova::compute::vnc_keymap: ja-
ご自分のデプロイメントに該当するその他の環境ファイルと共に、この環境ファイルを
openstack overcloud deployコマンドに追加します。
それぞれのパラメーターを定義することができるのは 1 度だけです。さらに定義すると、以前の値が上書きされます。
5.5. Puppet: 個別のノードの hieradata のカスタマイズ
heat テンプレートコレクションを使用して、個別のノードの Puppet hieradata を設定することができます。
手順
ノードのイントロスペクションデータからシステム UUID を特定します。
$ openstack baremetal introspection data save 9dcc87ae-4c6d-4ede-81a5-9b20d7dc4a14 | jq .extra.system.product.uuid
このコマンドは、システム UUID を返します。以下に例を示します。
"f5055c6c-477f-47fb-afe5-95c6928c407f"
ノード固有の 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" ]}}'-
ご自分のデプロイメントに該当するその他の環境ファイルと共に、この環境ファイルを
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 をインストールするケースを考えます。
手順
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 クラスが含まれています。OS::TripleO::NodeExtraConfigPost:リソース種別として heat テンプレートを登録する環境ファイル (~templates/puppet_post_config.yaml) を作成します。resource_registry: OS::TripleO::NodeExtraConfigPost: /home/stack/templates/custom_puppet_config.yaml
ご自分のデプロイメントに該当するその他の環境ファイルと共に、この環境ファイルを
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 をインストールする前に、ホストマシンでいくつかの基本設定を完了する必要があります。
手順
-
お使いのアンダークラウドに
rootユーザーとしてログインします。 stackユーザーを作成します。[root@director ~]# useradd stack
ユーザーのパスワードを設定します。
[root@director ~]# passwd stack
sudoを使用する場合にパスワードを要求されないようにします。[root@director ~]# echo "stack ALL=(root) NOPASSWD:ALL" | tee -a /etc/sudoers.d/stack [root@director ~]# chmod 0440 /etc/sudoers.d/stack
新規作成した
stackユーザーに切り替えます。[root@director ~]# su - stack [stack@director ~]$
システムイメージおよび heat テンプレート用のディレクトリーを作成します。
[stack@director ~]$ mkdir ~/images [stack@director ~]$ mkdir ~/templates
director はシステムのイメージと heat テンプレートを使用して、オーバークラウド環境を構築します。ローカルファイルシステムの管理を容易にするために、Red Hat ではこれらのディレクトリーを作成することを推奨します。
アンダークラウドのベースおよび完全なホスト名を確認します。
[stack@director ~]$ hostname [stack@director ~]$ hostname -f
上記のコマンドのいずれかで正しい完全修飾ホスト名が出力されない、またはエラーが表示される場合には、
hostnamectlでホスト名を設定します。[stack@director ~]$ sudo hostnamectl set-hostname undercloud.example.com
アンダークラウドホストの完全修飾ドメイン名 (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
Red Hat OpenStack Platform director をオーバークラウドまたはその認証プロバイダーとは別のドメインに配置する予定の場合には、追加のドメインを /etc/resolv.conf に加える必要があります。
search overcloud.com idp.overcloud.com
6.2. アンダークラウドの登録およびサブスクリプションのアタッチ
director をインストールする前に、subscription-manager を実行し、アンダークラウドを登録して有効な Red Hat OpenStack Platform サブスクリプションをアタッチする必要があります。
手順
-
アンダークラウドに
stackユーザーとしてログインします。 Red Hat コンテンツ配信ネットワークまたは Red Hat Satellite のどちらかにシステムを登録します。たとえば、システムをコンテンツ配信ネットワークに登録するには、以下のコマンドを実行します。要求されたら、カスタマーポータルのユーザー名およびパスワードを入力します。
[stack@director ~]$ sudo subscription-manager register
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: PhysicalPool IDの値を特定して、Red Hat OpenStack Platform 17.0 のエンタイトルメントをアタッチします。[stack@director ~]$ sudo subscription-manager attach --pool=Valid-Pool-Number-123456
アンダークラウドを Red Hat Enterprise Linux 9.0 にロックします。
$ sudo subscription-manager release --set=9.0
6.3. アンダークラウド用リポジトリーの有効化
アンダークラウドに必要なリポジトリーを有効にし、システムパッケージを最新バージョンに更新します。
手順
-
アンダークラウドに
stackユーザーとしてログインします。 デフォルトのリポジトリーをすべて無効にしてから、必要な 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 のインストールに必要なパッケージが含まれます。
システムで更新を実行して、ベースシステムパッケージを最新の状態にします。
[stack@director ~]$ sudo dnf update -y [stack@director ~]$ sudo reboot
6.4. director パッケージのインストール
Red Hat OpenStack Platform director に関連するパッケージをインストールします。
手順
director のインストールと設定を行うためのコマンドラインツールをインストールします。
[stack@director ~]$ sudo dnf install -y python3-tripleoclient
6.5. コンテナーイメージの準備
アンダークラウドのインストールには、コンテナーイメージの取得先およびその保存方法を定義するための環境ファイルが必要です。この環境ファイルを生成してカスタマイズし、コンテナーイメージの準備に使用します。
アンダークラウド用に特定のコンテナーイメージバージョンを設定する必要がある場合は、イメージを特定のバージョンに固定する必要があります。詳しい情報は、アンダークラウド用コンテナーイメージの固定 を参照してください。
手順
-
アンダークラウドホストに
stackユーザーとしてログインします。 デフォルトのコンテナーイメージ準備ファイルを生成します。
$ 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ファイルを使用することができます。
-
-
要件に合わせて
containers-prepare-parameter.yamlを変更します。
6.6. コンテナーイメージ準備のパラメーター
コンテナー準備用のデフォルトファイル (containers-prepare-parameter.yaml) には、ContainerImagePrepare heat パラメーターが含まれます。このパラメーターで、イメージのセットを準備するためのさまざまな設定を定義します。
parameter_defaults: ContainerImagePrepare: - (strategy one) - (strategy two) - (strategy three) ...
それぞれの設定では、サブパラメーターのセットにより使用するイメージやイメージの使用方法を定義することができます。以下の表には、ContainerImagePrepare ストラテジーの各設定で使用することのできるサブパラメーターの情報をまとめています。
| パラメーター | 説明 |
|---|---|
|
| 設定からイメージ名を除外する正規表現の一覧 |
|
|
設定に含める正規表現の一覧。少なくとも 1 つのイメージ名が既存のイメージと一致している必要があります。 |
|
|
対象となるイメージのタグに追加する文字列。たとえば、17.0.0-5.161 のタグが付けられたイメージをプルし、 |
|
| 変更するイメージを絞り込むイメージラベルのディクショナリー。イメージが定義したラベルと一致する場合には、director はそのイメージを変更プロセスに含めます。 |
|
| イメージのアップロード中 (ただし目的のレジストリーにプッシュする前) に実行する Ansible ロール名の文字列 |
|
|
|
|
| アップロードプロセス中にイメージをプッシュするレジストリーの名前空間を定義します。
実稼働環境でこのパラメーターを
|
|
| 元のコンテナーイメージをプルするソースレジストリー |
|
|
初期イメージの取得場所を定義する、 |
|
|
指定したコンテナーイメージのメタデータラベルの値を使用して、すべてのイメージのタグを作成し、そのタグが付けられたイメージをプルします。たとえば、 |
イメージをアンダークラウドにプッシュする場合は、push_destination: UNDERCLOUD_IP:PORT の代わりに push_destination: true を使用します。push_destination: true 手法を使用することで、IPv4 アドレスおよび IPv6 アドレスの両方で一貫性が確保されます。
set パラメーターには、複数の キー: 値 定義を設定することができます。
| キー | 説明 |
|---|---|
|
| Ceph Storage コンテナーイメージの名前 |
|
| Ceph Storage コンテナーイメージの名前空間 |
|
| Ceph Storage コンテナーイメージのタグ |
|
| Ceph Storage Alert Manager コンテナーイメージの名前、namespace、およびタグ。 |
|
| Ceph Storage Grafana コンテナーイメージの名前、namespace、およびタグ。 |
|
| Ceph Storage Node Exporter コンテナーイメージの名前、namespace、およびタグ。 |
|
| Ceph Storage Prometheus コンテナーイメージの名前、namespace、およびタグ。 |
|
| 各 OpenStack サービスイメージの接頭辞 |
|
| 各 OpenStack サービスイメージの接尾辞 |
|
| 各 OpenStack サービスイメージの名前空間 |
|
|
使用する OpenStack Networking (neutron) コンテナーを定義するのに使用するドライバー。標準の |
|
|
ソースからの全イメージに特定のタグを設定します。定義されていない場合は、director は Red Hat OpenStack Platform のバージョン番号をデフォルト値として使用します。このパラメーターは、 |
コンテナーイメージでは、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 に設定されている、または使用されていない場合は、ContainerImageRegistryLogin を true に設定する必要があります。
parameter_defaults:
ContainerImagePrepare:
- push_destination: false
set:
namespace: registry.redhat.io/...
...
...
ContainerImageRegistryCredentials:
registry.redhat.io:
myuser: 'p@55w0rd!'
ContainerImageRegistryLogin: true
ただし、オーバークラウドノードに ContainerImageRegistryCredentials で定義されたレジストリーホストへのネットワーク接続がなく、ContainerImageRegistryLogin を true に設定すると、ログインを試みる際にデプロイメントが失敗する可能性があります。オーバークラウドノードに ContainerImageRegistryCredentials で定義されたレジストリーホストへのネットワーク接続がない場合、push_destination を true に、ContainerImageRegistryLogin を false に設定して、オーバークラウドノードがアンダークラウドからイメージをプルできるようにします。
parameter_defaults:
ContainerImagePrepare:
- push_destination: true
set:
namespace: registry.redhat.io/...
...
...
ContainerImageRegistryCredentials:
registry.redhat.io:
myuser: 'p@55w0rd!'
ContainerImageRegistryLogin: false6.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 ハードウェアをブロックストレージのバックエンドとして使用するために、ベンダープラグインをデプロイする方法について説明します。
手順
オーバークラウド用に新たなコンテナーイメージファイルを作成します。
$ sudo openstack tripleo container image prepare default \ --local-push-destination \ --output-env-file containers-prepare-parameter-dellemc.yaml- containers-prepare-parameter-dellemc.yaml ファイルを編集します。
メインの 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}"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 ...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]-
containers-prepare-parameter-dellemc.yamlファイルを保存します。 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 を設定することができます。
手順
containers-prepare-parameter.yamlファイルを編集し、Ceph Storage コンテナーを除外します。parameter_defaults: ContainerImagePrepare: - push_destination: true excludes: - ceph - prometheus set: …excludesパラメーターは正規表現を使用して、cephまたはprometheus文字列を含むコンテナーイメージを除外します。-
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 を使用したコンテナーイメージの変更をサポートします。
手順
以下の例では、
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 .../home/stack/nova-custom/Dockerfileファイルの例を以下に示します。USERroot ディレクティブを実行した後は、元のイメージのデフォルトユーザーに戻す必要があります。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 コンテナーレジストリーの認証 を参照してください。
手順
すべてのコンテナーイメージの一覧を作成します。
$ 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-prometheusCeph をインストールして 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
-
Satellite 6 の
hammerツールがインストールされているシステムにsatellite_imagesファイルをコピーします。あるいは、Hammer CLI ガイド に記載の手順に従って、アンダークラウドにhammerツールをインストールします。 以下の
hammerコマンドを実行して、実際の Satellite 組織に新規製品 (OSP Containers) を作成します。$ hammer product create \ --organization "ACME" \ --name "OSP Containers"
このカスタム製品に、イメージを保管します。
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
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-4-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
コンテナーイメージを同期します。
$ hammer product synchronize \ --organization "ACME" \ --name "OSP Containers"
Satellite Server が同期を完了するまで待ちます。
注記設定によっては、
hammerから Satellite Server のユーザー名およびパスワードが要求される場合があります。設定ファイルを使って自動的にログインするようにhammerを設定することができます。詳しくは、Red Hat Satellite Hammer CLI ガイドの 認証 セクションを参照してください。-
お使いの Satellite 6 サーバーでコンテンツビューが使われている場合には、新たなバージョンのコンテンツビューを作成してイメージを反映し、アプリケーションライフサイクルの環境に従ってプロモートします。この作業は、アプリケーションライフサイクルをどのように設定するかに大きく依存します。たとえば、ライフサイクルに
productionという名称の環境があり、その環境でコンテナーイメージを利用可能にする場合には、コンテナーイメージを含むコンテンツビューを作成し、そのコンテンツビューをproduction環境にプロモートします。詳しくは、Red Hat Satellite コンテンツ管理ガイドの コンテンツビューの管理 を参照してください。 baseイメージに使用可能なタグを確認します。$ hammer docker tag list --repository "base" \ --organization "ACME" \ --lifecycle-environment "production" \ --product "OSP Containers"
このコマンドにより、特定環境のコンテンツビューでの OpenStack Platform コンテナーイメージのタグが表示されます。
アンダークラウドに戻り、Satellite サーバーをソースとして使用して、イメージを準備するデフォルトの環境ファイルを生成します。以下のサンプルコマンドを実行して環境ファイルを生成します。
$ sudo openstack tripleo container image prepare default \ --output-env-file containers-prepare-parameter.yaml
-
--output-env-file: 環境ファイルの名前です。このファイルには、アンダークラウド用コンテナーイメージを準備するためのパラメーターが含まれます。ここでは、ファイル名はcontainers-prepare-parameter.yamlです。
-
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_namespace、ceph_image、ceph_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 設定ファイルに、特定の設定が必要になります。設定のベースとするためにデフォルトのテンプレートをコピーするには、以下の手順を実施します。
手順
デフォルトのテンプレートを
stackユーザーのホームディレクトリーにコピーします。[stack@director ~]$ cp \ /usr/share/python-tripleoclient/undercloud.conf.sample \ ~/undercloud.conf
-
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パラメーターを設定した場合に限り、このオプションを使用します。localCA を選択する場合は、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_interfaceをem1に設定します。この設定スクリプトにより、このインターフェイスが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_hostがlocal_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_hostがlocal_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_ip、gateway、undercloud_admin_host、undercloud_public_host、およびInspection_iprangeパラメーターに設定された値をサブネットの完全な IP 範囲から削除して、割り当てプールを決定します。開始アドレスと終了アドレスのペアのリストを指定することで、アンダークラウドのコントロールプレーンのサブネットに非連続割り当てプールを設定することができます。または、
dhcp_excludeオプションを使用して、IP アドレス範囲内の IP アドレスを除外することもできます。たとえば、次の設定は両方とも割り当てプール172.20.0.100-172.20.0.150と172.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_startとdhcp_endで定義された範囲と重複することはできませんが、同じ IP サブネット内になければなりません。
実際の設定に応じて、これらのパラメーターの値を変更してください。完了したら、ファイルを保存します。
7.3. 環境ファイルを使用したアンダークラウドの設定
undercloud.conf ファイルを使用して、アンダークラウドの主要なパラメーターを設定します。heat パラメーターが含まれる環境ファイルを使用して、アンダークラウドの追加設定を行うこともできます。
手順
-
/home/stack/templates/custom-undercloud-params.yamlという名前で環境ファイルを作成します。 このファイルを編集して、必要な heat パラメーターを追加します。たとえば、特定の OpenStack Platform サービスのデバッグを有効にするには、
custom-undercloud-params.yamlファイルに以下のスニペットを追加します。parameter_defaults: Debug: True
完了したら、このファイルを保存します。
undercloud.confファイルを編集し、custom_env_filesパラメーターまでスクロールします。作成したcustom-undercloud-params.yaml環境ファイルをポイントするようにパラメーターを編集します。custom_env_files = /home/stack/templates/custom-undercloud-params.yaml
注記コンマ区切りリストを使用して、複数の環境ファイルを指定することができます。
アンダークラウドの次回インストールまたはアップグレード操作時に、この環境ファイルが director のインストールに追加されます。
7.4. アンダークラウド設定用の標準 heat パラメーター
以下の表には、アンダークラウド用のカスタム環境ファイルで設定する標準の heat パラメーターをまとめています。
| パラメーター | 説明 |
|---|---|
|
|
アンダークラウドの |
|
|
アンダークラウドの |
|
| デバッグモードを有効にします。 |
カスタム環境ファイルの parameter_defaults セクションで、これらのパラメーターを設定します。
parameter_defaults: Debug: True AdminPassword: "myp@ssw0rd!" AdminEmail: "admin@example.com"
7.5. アンダークラウドへの hieradata の設定
director に Puppet hieradata を設定して、サービスに対して利用可能な undercloud.conf パラメーター以外のカスタム設定を行うことができます。
手順
-
hieradata オーバーライドファイルを作成します (例:
/home/stack/hieradata.yaml)。 カスタマイズした 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: 15undercloud.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 プロビジョニングを有効にします。
前提条件
- アンダークラウドの IPv6 アドレス。詳しい情報は、オーバークラウドの IPv6 ネットワークの アンダークラウドの IPv6 アドレスの設定 を参照してください。
手順
-
undercloud.confファイルを開きます。 IPv6 アドレスモードをステートレスまたはステートフルのいずれかに指定します。
[DEFAULT] ipv6_address_mode = <address_mode> ...
-
NIC がサポートするモードに基づいて、
<address_mode>をdhcpv6-statelessまたはdhcpv6-statefulに置き換えます。
注記ステートフルアドレスモードを使用する場合、ファームウェア、チェーンローダー、およびオペレーティングシステムは、DHCP サーバーが追跡する ID を生成するために異なるアルゴリズムを使用する場合があります。DHCPv6 は MAC によってアドレスを追跡せず、リクエスターからの ID 値が変更されても、MAC アドレスが同じままである場合、同じアドレスを提供しません。したがって、ステートフル DHCPv6 を使用する場合は、次の手順を実行してネットワークインターフェイスを設定する必要もあります。
-
NIC がサポートするモードに基づいて、
ステートフル DHCPv6 を使用するようにアンダークラウドを設定した場合は、ベアメタルノードに使用するネットワークインターフェイスを指定します。
[DEFAULT] ipv6_address_mode = dhcpv6-stateful ironic_enabled_network_interfaces = neutron,flat ...
ベアメタルノードのデフォルトのネットワークインターフェイスを設定します。
[DEFAULT] ... ironic_default_network_interface = neutron ...
アンダークラウドがプロビジョニングネットワーク上にルーターを作成するかどうかを指定します。
[DEFAULT] ... enable_routed_networks: <true/false> ...
-
<true/false>をtrueに置き換えて、ルーティングされたネットワークを有効にし、アンダークラウドがプロビジョニングネットワーク上にルーターを作成しないようにします。trueの場合、データセンタールーターはルーターアドバタイズメントを提供する必要があります。 -
<true/false>をfalseに置き換えて、ルーティングされたネットワークを無効にし、プロビジョニングネットワーク上にルーターを作成します。
-
ローカル 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 アドレスに置き換えます。
-
オプション: director がインスタンスの管理に使用するプロビジョニングネットワークを設定します。
[ctlplane-subnet] cidr = <ipv6_address>/<ipv6_prefix> ...
-
<ipv6_address>を、デフォルトのプロビジョニングネットワークを使用していないときにインスタンスの管理に使用するネットワークの IPv6 アドレスに置き換えます。 -
<ipv6_prefix>を、デフォルトのプロビジョニングネットワークを使用していないときにインスタンスの管理に使用するネットワークの IP アドレス接頭辞に置き換えます。
-
プロビジョニングノードの 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 アドレスに置き換えます。
-
オプション: トラフィックを 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 アドレスに置き換えます。
-
デフォルトゲートウェイを使用しない場合は、
検査プロセス中に使用する 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_startとdhcp_endで定義された範囲と重複することはできませんが、同じ IP サブネット内になければなりません。-
サブネットの 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 を無効にする必要があります。
手順
- アンダークラウドのホストにログインします。
新規ファイル
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: nic3undercloud.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はテンプレートで定義するインターフェイスを管理するので、このファイルですべてのアンダークラウドネットワークインターフェイスのカスタマイズを実行する必要があります。- アンダークラウドをインストールします。
検証
アンダークラウドのインストールが正常に完了したら、
/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 をインストールして基本的なインストール後タスクを行うには、以下の手順を実施します。
手順
以下のコマンドを実行して、アンダークラウドに 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 コマンドラインツールへアクセスできるようにする初期化変数セット
-
このスクリプトは、全 OpenStack Platform サービスのコンテナーも自動的に起動します。以下のコマンドを使用して、有効になったコンテナーを確認することができます。
[stack@director ~]$ sudo podman ps
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 サーバーにインストールされます。
手順
-
アンダークラウドに
stackユーザーとしてログインします。 stackrcファイルを取得します。[stack@director ~]$ source ~/stackrc
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
stackユーザーのホームディレクトリー/home/stack/imagesにimagesディレクトリーを作成します。(undercloud) [stack@director ~]$ mkdir /home/stack/images
ディレクトリーがすでに存在する場合は、この手順をスキップしてください。
イメージアーカイブを
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
イメージを director にインポートします。
(undercloud) [stack@director images]$ openstack overcloud image upload --image-path /home/stack/images/
このコマンドは、イメージ形式を QCOW から RAW に変換し、イメージのアップロードの進行状況に関する詳細な更新を提供します。
オーバークラウドのイメージが
/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
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
手順
-
アンダークラウドに
stackユーザーとしてログインします。 stackrcファイルを取得します。[stack@director ~]$ source ~/stackrc
overcloud-minimalパッケージをインストールします。(undercloud) [stack@director ~]$ sudo dnf install rhosp-director-images-minimal
イメージのアーカイブを、
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
イメージを 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 コマンドを再度実行して、インストール後のアンダークラウド設定に変更を加えることができます。
手順
アンダークラウドの設定ファイルを変更します。以下の例では、
undercloud.confファイルを編集して、有効なハードウェア種別の一覧にidracハードウェア種別を追加しています。enabled_hardware_types = ipmi,redfish,idrac
openstack undercloud installコマンドを実行し、新たな変更を反映させてアンダークラウドを更新します。[stack@director ~]$ openstack undercloud install
コマンドの実行が完了するまで待ちます。
stackユーザーを初期化し、コマンドラインツールを使用します。[stack@director ~]$ source ~/stackrc
プロンプトには、OpenStack コマンドがアンダークラウドに対して認証および実行されることが表示されるようになります。
(undercloud) [stack@director ~]$
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 を使用すると、コンピューティングホストにデータが公開される を参照してください。
- ローカルディスクのパーティションサイズ
ストレージノードのストレージと保持の要件を考慮して、次のデフォルトのディスクパーティションサイズが要件を満たしているかどうかを判断します。
Partition デフォルトのサイズ /8GB
/tmp1 GB
/var/log10 GB
/var/log/audit2 GB
/home1 GB
/var他のすべてのパーティションが割り当てられた後、ディスクの残りのサイズが割り当てられます。
パーティションに割り当てられたディスクサイズを変更するには、
overcloud-baremetal-deploy.yamlノード定義ファイルの Ansible_playbooks 定義で追加の Ansible 変数role_growvols_argsを更新します。詳細は、オーバークラウド用のベアメタルノードのプロビジョニング を参照してください。パーティションサイズの設定を最適化した後もパーティションがいっぱいになる場合は、次のいずれかのタスクを実行します。
- 影響を受けるパーティションからファイルを手動で削除します。
新しい物理ディスクを追加し、LVM ボリュームグループに追加します。詳しくは、論理ボリュームの設定と管理 を参照してください。
注記新しいディスクを追加するには、サポートの例外が必要です。サポートの例外、またはその他のオプションについては、Red Hat カスタマーエクスペリエンスおよびエンゲージメントチーム にお問い合わせください。
8.4. オーバークラウドのセキュリティー
OpenStack Platform の実装のセキュリティーレベルは、お使いの環境のセキュリティーレベルと同等でしかありません。ネットワーク環境内の適切なセキュリティー原則に従って、ネットワークアクセスを正しく制御するようにします。
- ネットワークのセグメント化を使用して、ネットワークトラフィックを軽減し、機密データを分離します。フラットなネットワークは、セキュリティーレベルがはるかに低くなります。
- サービスアクセスとポートを最小限に制限します。
- 適切なファイアウォールルールおよびパスワードの使用を徹底してください。
- 必ず SELinux を有効にします。
システムのセキュリティー保護についての詳細は、以下の Red Hat ガイドを参照してください。
- Red Hat Enterprise Linux 9 の セキュリティーの強化
- Red Hat Enterprise Linux 9 の SELinux の使用
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) |
| x86_64 システム用ベースオペレーティングシステムのリポジトリー |
| Red Hat Enterprise Linux 9 for x86_64 - AppStream (RPMs) |
| Red Hat OpenStack Platform の依存関係が含まれます。 |
| Red Hat Enterprise Linux 9 for x86_64 - High Availability (RPMs) Extended Update Support (EUS) |
| Red Hat Enterprise Linux の高可用性ツール。 |
| Red Hat OpenStack Platform 17 for RHEL 9 x86_64 (RPMs) |
| Red Hat OpenStack Platform のコアリポジトリー |
| Red Hat Fast Datapath for RHEL 9 (RPMS) |
| OpenStack Platform 用 Open vSwitch (OVS) パッケージを提供します。 |
| Red Hat Ceph Storage Tools 5 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) |
| x86_64 システム用ベースオペレーティングシステムのリポジトリー |
| Red Hat Enterprise Linux 9 for x86_64 - AppStream (RPMs) |
| Red Hat OpenStack Platform の依存関係が含まれます。 |
| Red Hat Enterprise Linux 9 for x86_64 - High Availability (RPMs) Extended Update Support (EUS) |
| Red Hat Enterprise Linux の高可用性ツール。 |
| Red Hat OpenStack Platform 17 for RHEL 9 x86_64 (RPMs) |
| Red Hat OpenStack Platform のコアリポジトリー |
| Red Hat Fast Datapath for RHEL 9 (RPMS) |
| OpenStack Platform 用 Open vSwitch (OVS) パッケージを提供します。 |
| Red Hat Ceph Storage Tools 5 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) |
|
リアルタイム KVM (RT-KVM) のリポジトリー。リアルタイムカーネルを有効化するためのパッケージが含まれています。RT-KVM 対象の全コンピュートノードで、このリポジトリーを有効にします。注記: このリポジトリーにアクセスするには、別途 |
Ceph Storage ノード用リポジトリー
以下の表には、オーバークラウド用の Ceph Storage 関連のリポジトリーをまとめています。
| 名前 | リポジトリー | 要件の説明 |
|---|---|---|
| Red Hat Enterprise Linux 9 for x86_64 - BaseOS (RPMs) |
| x86_64 システム用ベースオペレーティングシステムのリポジトリー |
| Red Hat Enterprise Linux 9 for x86_64 - AppStream (RPMs) |
| Red Hat OpenStack Platform の依存関係が含まれます。 |
| Red Hat OpenStack Platform 17 Director Deployment Tools for RHEL 9 x86_64 (RPMs) |
|
director が Ceph Storage ノードを設定するのに役立つパッケージ。このリポジトリーは、スタンドアロンの Ceph Storage サブスクリプションに含まれています。OpenStack Platform と Ceph Storage を組み合わせたサブスクリプションを使用する場合は、 |
| Red Hat OpenStack Platform 17 for RHEL 9 x86_64 (RPMs) |
|
director が Ceph Storage ノードを設定するのに役立つパッケージ。このリポジトリーは、OpenStack Platform と Ceph Storage を組み合わせたサブスクリプションに含まれています。スタンドアロンの Ceph Storage サブスクリプションを使用する場合は、 |
| Red Hat Ceph Storage Tools 5 for RHEL 9 x86_64 (RPMs) |
| Ceph Storage クラスターと通信するためのノード用のツールを提供します。 |
| Red Hat Fast Datapath for RHEL 9 (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 は、ロールテンプレートの管理とカスタムの roles_data ファイルの自動生成を行うためのコマンドをいくつか提供しています。
手順
デフォルトロールのテンプレートを一覧表示します。
$ openstack overcloud role list BlockStorage CephStorage Compute ComputeHCI ComputeOvsDpdk Controller ...
openstack overcloud roles showコマンドを使用して、YAML 形式のロール定義を表示します。$ openstack overcloud role show Compute
カスタムの
roles_dataファイルを生成します。openstack overcloud role generateコマンドを使用して、複数の事前定義済みロールを単一のロールに統合します。たとえば、以下のコマンドを実行して、Controller、Compute、およびNetworkerロールが含まれるroles_data.yamlファイルを生成します。$ openstack overcloud role generate -o ~/roles_data.yaml Controller Compute Networker
-oオプションを使用して、出力ファイルの名前を定義します。このコマンドにより、カスタムの
roles_dataファイルが作成されます。ただし、上記の例では、ControllerとNetworkerロールを使用しており、その両方に同じネットワークエージェントが含まれています。つまり、ネットワークサービスはControllerロールからNetworkerロールにスケーリングされ、オーバークラウドはControllerノードとNetworkerノード間にネットワークサービスの負荷のバランスを取ります。この
Networkerロールをスタンドアロンにするには、独自のカスタムControllerロールと、その他の必要なロールを作成することができます。これにより、独自のカスタムロールからroles_dataファイルを生成できるようになります。コア heat テンプレートコレクションから
stackユーザーのホームディレクトリーにディレクトリーをコピーします。$ cp -r /usr/share/openstack-tripleo-heat-templates/roles ~/.
このディレクトリー内でカスタムロールファイルを追加または変更します。このディレクトリーをカスタムロールのソースとして使用するには、ロールのサブコマンドに
--roles-pathオプションを指定します。$ openstack overcloud role generate -o my_roles_data.yaml \ --roles-path ~/roles \ Controller Compute Networker
このコマンドにより、
~/rolesディレクトリー内の個々のロールから、単一のmy_roles_data.yamlファイルが生成されます。
デフォルトのロールコレクションには、ControllerOpenstack ロールも含まれます。このロールには、Networker、Messaging、および Database ロールのサービスは含まれません。ControllerOpenstack は、スタンドアロンの Networker、Messaging、Database ロールと組み合わせて使用することができます。
9.4. サポートされるカスタムロール
以下の表で、利用可能なカスタムロールについて説明します。カスタムロールテンプレートは、/usr/share/openstack-tripleo-heat-templates/roles ディレクトリーにあります。
| ロール | 説明 | ファイル |
|---|---|---|
|
| OpenStack Block Storage (cinder) ノード |
|
|
| 完全なスタンドアロンの Ceph Storage ノード。OSD、MON、Object Gateway (RGW)、Object Operations (MDS)、Manager (MGR)、および RBD Mirroring が含まれます。 |
|
|
| スタンドアロンのスケールアウト Ceph Storage ファイルロール。OSD および Object Operations (MDS) が含まれます。 |
|
|
| スタンドアロンのスケールアウト Ceph Storage オブジェクトロール。OSD および Object Gateway (RGW) が含まれます。 |
|
|
| Ceph Storage OSD ノードロール |
|
|
| 代替のコンピュートノードロール |
|
|
| DVR 対応のコンピュートノードロール |
|
|
| ハイパーコンバージドインフラストラクチャーを持つコンピュートノード。Compute および Ceph OSD サービスが含まれます。 |
|
|
|
コンピュートインスタンス HA ノードロール。 |
|
|
| Cavium Liquidio Smart NIC を持つコンピュートノード |
|
|
| コンピュート OVS DPDK RealTime ロール |
|
|
| コンピュート OVS DPDK ロール |
|
|
|
リアルタイムのパフォーマンスに最適化された Compute ロール。このロールを使用する場合には、 |
|
|
| コンピュート SR-IOV RealTime ロール |
|
|
| コンピュート SR-IOV ロール |
|
|
| 標準のコンピュートノードロール |
|
|
|
データベース、メッセージング、ネットワーク設定、および OpenStack Compute (nova) コントロールコンポーネントを持たない Controller ロール。 |
|
|
| コア Controller サービスは組み込まれているが Ceph Storage (MON) コンポーネントを持たない Controller ロール。このロールはデータベース、メッセージング、およびネットワーク機能を処理しますが、Ceph Storage 機能は処理しません。 |
|
|
|
OpenStack Compute (nova) コントロールコンポーネントが含まれない Controller ロール。 |
|
|
|
データベース、メッセージング、およびネットワーク設定コンポーネントが含まれない Controller ロール。 |
|
|
| すべてのコアサービスが組み込まれ、Ceph NFS を使用する Controller ロール。このロールはデータベース、メッセージング、およびネットワーク機能を処理します。 |
|
|
| すべてのコアサービスが組み込まれた Controller ロール。このロールはデータベース、メッセージング、およびネットワーク機能を処理します。 |
|
|
| 通常の Controller ロールと同じですが、OVN Metadata エージェントがデプロイされます。 |
|
|
| スタンドアロンのデータベー出力ル。Pacemaker を使用して Galera クラスターとして管理されるデータベース。 |
|
|
| ハイパーコンバージドインフラストラクチャーおよびすべての Ceph Storage サービスを持つコンピュートノード。OSD、MON、Object Gateway (RGW)、Object Operations (MDS)、Manager (MGR)、および RBD Mirroring が含まれます。 |
|
|
| ハイパーコンバージドインフラストラクチャーおよび Ceph Storage ファイルサービスを持つコンピュートノード。OSD および Object Operations (MDS) が含まれます。 |
|
|
| ハイパーコンバージドインフラストラクチャーおよび Ceph Storage ブロックサービスを持つコンピュートノード。OSD、MON、および Manager が含まれます。 |
|
|
| ハイパーコンバージドインフラストラクチャーおよび Ceph Storage オブジェクトサービスを持つコンピュートノード。OSD および Object Gateway (RGW) が含まれます。 |
|
|
| Ironic Conductor ノードロール |
|
|
| スタンドアロンのメッセージングロール。Pacemaker を使用して管理される RabbitMQ。 |
|
|
| スタンドアロンのネットワーク設定ロール。単独で OpenStack Networking (neutron) エージェントを実行します。デプロイメントで ML2/OVN メカニズムドライバーが使用される場合は、Deploying a Custom Role with ML2/OVN に記載の追加ステップを参照してください。 |
|
|
| 通常の Networker ロールと同じですが、OVN Metadata エージェントがデプロイされます。Deploying a Custom Role with ML2/OVN に記載の追加ステップを参照してください。 |
|
|
|
スタンドアロンの |
|
|
| Swift オブジェクトストレージノードロール |
|
|
| すべてのメトリックおよびアラームサービスを持つ Telemetry ロール |
|
9.5. ロールパラメーターの考察
それぞれのロールには以下のパラメーターが含まれます。
- name
-
(必須) 空白または特殊文字を含まないプレーンテキスト形式のロール名。選択した名前により、他のリソースとの競合が発生しないことを確認します。たとえば、
Networkの代わりにNetworkerを名前に使用します。 - description
- (オプション) プレーンテキスト形式のロールの説明
- tags
(オプション) ロールのプロパティーを定義するタグの YAML リスト。このパラメーターを使用して
controllerとprimaryタグの両方で、プライマリーロールを定義します。- 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デフォルトのネットワークには、
External、InternalApi、Storage、StorageMgmt、Tenant、Managementが含まれます。- 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です。-
コントローラー、オブジェクトストレージ、および Ceph Storage ノードのデフォルトは
- 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 ロールを作成するケースを考えます。
手順
デフォルトの
rolesディレクトリーのカスタムコピーを作成します。$ cp -r /usr/share/openstack-tripleo-heat-templates/roles ~/.
~/roles/Horizon.yamlという名前の新規ファイルを作成して、ベースおよびコアの OpenStack Dashboard サービスが含まれたHorizonロールを新規作成します。- name: Horizon CountDefault: 1 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-
nameパラメーターをカスタムロールの名前に設定します。カスタムロール名の最大長は 47 文字です。 -
CountDefaultパラメーターを1に設定して、デフォルトのオーバークラウドに常にHorizonノードが含まれるようにすると良いでしょう。
-
(オプション) 既存のオーバークラウド内でサービスをスケーリングする場合は、既存のサービスを
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 ...~/rolesディレクトリーをソースに使用して、新しいroles_data-horizon.yamlファイルを生成します。$ openstack overcloud roles generate -o roles_data-horizon.yaml \ --roles-path ~/roles \ Controller Compute Horizon
オプション: 予測ノード配置を設定します。たとえば、次の設定を使用して、ノード node00、node01、および node02 に 3 つのコントローラーノードをプロビジョニングし、node04、node05、および node06 に 3 つのコンピューティングノードをプロビジョニングし、node07 に 1 つの Horizon ノードをプロビジョニングします。
- 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 - 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([])}}
デフォルトのロールの場合は、これにより次のサービス一覧パラメーターが作成されます: ControllerServices、ComputeServices、BlockStorageServices、ObjectStorageServices、CephStorageServices
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 パラメーターのデフォルト一覧として定義されます。
環境ファイルを使用してサービスパラメーターのデフォルト一覧を上書きすることもできます。たとえば、環境ファイルで ControllerServices を parameter_default として定義して、roles_data.yaml ファイルからのサービス一覧を上書きすることができます。
9.9. ロールへのサービスの追加と削除
サービスの追加と削除の基本的な方法では、ノードロールのデフォルトサービス一覧のコピーを作成してからサービスを追加/削除します。たとえば、OpenStack Orchestration (heat) をコントローラーノードから削除するケースを考えます。
手順
デフォルトの
rolesディレクトリーのカスタムコピーを作成します。$ cp -r /usr/share/openstack-tripleo-heat-templates/roles ~/.
~/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新しい
roles_dataファイルを生成します。$ openstack overcloud roles generate -o roles_data-no_heat.yaml \ --roles-path ~/roles \ Controller Compute Networker
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 ファイルを使用します。
手順
CinderBackupサービスをcinder-backup設定を含む heat テンプレートにリンクする環境ファイルにエントリーを追加します。resource_registry: OS::TripleO::Services::CinderBackup: ../podman/services/pacemaker/cinder-backup.yaml ...
このエントリーにより、デフォルトの null 操作のリソースが上書きされ、これらのサービスが有効になります。
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 ソフトウェアがインストールされていますが、有効化または設定されていないことを意味します。
手順
カスタムの
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ロールを維持するようにしてください。また、プロビジョニングするノードを選択する際には、必要な汎用 Red Hat Enterprise Linux 9 ノード数とフレーバーを指定する環境ファイル (
generic-node-params.yaml) も追加することができます。parameter_defaults: OvercloudGenericFlavor: baremetal GenericCount: 1
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: undef10.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: undef10.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 オプション
| 名前 | オプション | 型 | デフォルト値 |
|---|---|---|---|
|
| ネットワークの名前 | string | |
|
| オプション: ネットワークの小文字の名前。 | string |
|
|
| オプション: ネットワークの DNS ドメイン名。 | string | |
|
| 最大伝送単位 (MTU) | number |
|
|
| オプション: IPv6 を使用する場合は true に設定します。 | Boolean |
|
|
| ネットワーク上に VIP を作成します。 | Boolean |
|
|
| ネットワークのサブネットが含まれます。 | ディクショナリー |
表10.2 サブネット定義のネットワークデータ YAML オプション
| 名前 | オプション | タイプ / 要素 | 例 |
|---|---|---|---|
|
| IPv4 CIDR ブロック表記。 | string | 192.0.5.0/24 |
|
| IPv6 CIDR ブロック表記。 | string | 2001:db6:fd00:1000::/64 |
|
| オプション: ゲートウェイ IPv4 アドレス。 | string | 192.0.5.1 |
|
| サブネットの開始アドレスと終了アドレス。 | リスト/ディクショナリー | start: 192.0.5.100 end: 192.0.5.150 |
|
| サブネットの開始アドレスと終了アドレス。 | リスト/ディクショナリー | start: 2001:db6:fd00:1000:100::1 end: 2001:db6:fd00:1000:150::1 |
|
| ネットワークゲートウェイ経由のルーティングが必要な IPv4 ネットワークのリスト。 | リスト/ディクショナリー | |
|
| ネットワークゲートウェイ経由のルーティングが必要な IPv6 ネットワークのリスト。 | リスト/ディクショナリー | |
|
| オプション: ネットワークの VLAN ID。 | number |
routes および routes_ipv6 オプションには、ルートのリストが含まれています。各ルートは、destination と nexthop キーを含むディクショナリーエントリーです。どちらのオプションも文字列型です。
routes:
- destination: 198.51.100.0/24
nexthop: 192.0.5.1
- destination: 203.0.113.0/24
nexthost: 192.0.5.1routes:
- 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 データオプション
| 名前 | オプション | タイプ / 要素 | デフォルト値 |
|---|---|---|---|
|
| Neutron ネットワーク名。 | string | |
|
| オプション: 事前定義されたFixed IP アドレス。 | string | |
|
| Neutron サブネット名。仮想 IP neutron ポートのサブネットを指定します。ルーティングされたネットワークを使用するデプロイメントに必要です。 | string | |
|
| オプション: FQDN (完全修飾ドメイン名)。 | リスト/ディクショナリー |
|
|
| オプション: 仮想 IP 名。 | string |
|
10.2.3. ネットワーク分離の設定
ネットワーク分離を有効にして設定するには、必要な要素を network_data.yaml 設定ファイルに追加する必要があります。
手順
ネットワーク YAML 定義ファイルを作成します。
$ cp /usr/share/openstack-tripleo-heat-templates/network-data-samples/default-network-isolation-ipv6.yaml /home/stack/templates/network_data.yaml
オーバークラウドのネットワーク環境の要件に合わせて、
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 ディレクトリーにサンプルファイルがあります。
手順
利用可能なサンプル設定ファイルを一覧表示します。
$ 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
ニーズに最適なネットワーク設定ファイルの例をコピーします。
$ cp /usr/share/openstack-tripleo-heat-templates/network-data-samples/default-network-isolation.yaml /home/stack/templates/network_data.yaml
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.1network_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 ネットワークのルートを設定します。
必要なサンプルネットワーク VIP 定義テンプレートを
/usr/share/openstack-tripleo-heat-templates/network-data-samplesから環境ファイルディレクトリーにコピーします。次の例では、vip-data-default-network-isolation.yamlをvip_data.yamlという名前のローカル環境ファイルにコピーします。$ cp /usr/share/openstack-tripleo-heat-templates/network-data-samples/vip-data-default-network-isolation.yaml /home/stack/templates/vip_data.yaml
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 名を設定します。
-
サンプルネットワーク設定テンプレートをコピーします。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/
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 %}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オーバークラウドネットワークをプロビジョニングします。このアクションにより、オーバークラウドのデプロイ時に環境ファイルで使用される出力ファイルが生成されます。
(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)。
-
ネットワーク 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 ノードに追加することができます。
手順
カスタム
roles_data.yamlファイルがまだない場合には、デフォルトをご自分のホームディレクトリーにコピーします。$ cp /usr/share/openstack-tripleo-heat-templates/roles_data.yaml /home/stack/templates/roles_data.yaml
-
カスタムの
roles_data.yamlファイルを編集します。 ネットワークを追加するロールの
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- カスタムネットワークを対応するロールに追加したら、ファイルを保存します。
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) を使用します。
手順
source コマンドで stackrc アンダークラウド認証情報ファイルを読み込みます。
$ source ~/stackrc
オーバークラウドネットワークをプロビジョニングします。
$ openstack overcloud network provision \ --output overcloud-networks-deployed.yaml \ custom_network_data.yaml
ネットワーク VIP をプロビジョニングします。
$ openstack overcloud network vip provision \ --stack overcloud \ --output overcloud-networks-vips-deployed.yaml \ custom_vip_data.yamlオーバークラウドノードをプロビジョニングします。
$ openstack overcloud node provision \ --stack overcloud \ --output overcloud-baremetal-deployed.yaml \ overcloud-baremetal-deploy.yaml以下の例のように、設定ファイルとテンプレートを必要な順序で指定して、
openstack overcloud deployコマンドを作成します。$ openstack overcloud deploy --templates \ --networks-file custom_network_data.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 を更新します。
手順
network_data.yamlファイルで、名前を変更する各ネットワークのname_lowerパラメーターに新しい名前を入力します。- name: InternalApi name_lower: MyCustomInternalApi
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 を使用する際にスループットを向上させるには、このオプションを |
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 サービスにより提供されるデフォルトのルートを使用します。 |
| persist_mapping | False | システム名の代わりにデバイスのエイリアス設定を記述します。 |
| dhclient_args | なし | DHCP クライアントに渡す引数 |
| dns_servers | なし | ボンディングに使用する DNS サーバーの一覧 |
ovs_bridge
Open vSwitch で、複数の interface、ovs_bond、vlan オブジェクトを接続するブリッジを定義します。
ネットワークインターフェイス種別 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 サービスにより提供されるデフォルトのルートを使用します。 |
| 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 サービスにより提供されるデフォルトのルートを使用します。 |
| persist_mapping | False | システム名の代わりにデバイスのエイリアス設定を記述します。 |
| dhclient_args | なし | DHCP クライアントに渡す引数 |
| dns_servers | なし | ボンディングに使用する DNS サーバーの一覧 |
linux_bridge
複数の interface、linux_bond、vlan オブジェクトを接続する 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 サービスにより提供されるデフォルトのルートを使用します。 |
| 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 |
このルートをデフォルトルートに設定します。 |
| 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 }}
ネットワークインターフェイスのテンプレートは、実際のインターフェイス名 (eth0、eth1、enp0s25) または番号付きのインターフェイス (nic1、nic2、nic3) のいずれかを使用します。名前付きのインターフェイス (eth0、eno2 など) ではなく、番号付きのインターフェイス (nic1、nic2 など) を使用した場合には、ロール内のホストのネットワークインターフェイスは、全く同じである必要はありません。たとえば、あるホストに em1 と em2 のインターフェイスが指定されており、別のホストには eno1 と eno2 が指定されていても、両ホストの NIC は nic1 および nic2 として参照することができます。
番号付きのインターフェイスの順序は、名前付きのネットワークインターフェイスのタイプの順序と同じです。
-
eth0、eth1などのethX。これらは、通常オンボードのインターフェイスです。 -
eno0、eno1などのenoX。これらは、通常オンボードのインターフェイスです。 -
enp3s0、enp3s1、ens3などの英数字順のenXインターフェイス。これらは、通常アドオンのインターフェイスです。
番号による NIC スキームには、アクティブなインターフェイスだけが含まれます (たとえば、インターフェイスにスイッチに接続されたケーブルがあるかどうかが考慮されます)。4 つのインターフェイスを持つホストと、6 つのインターフェイスを持つホストがある場合は、nic1 から nic4 を使用して各ホストで 4 本のケーブルだけを結線します。
特定のノードの os-net-config マッピングを設定し、各ノードの物理インターフェイスにエイリアスを割り当てて、どの物理 NIC が特定のエイリアス (nic1 や nic2 など) にマップされるかを事前に決定できます。また、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 のノードにマップし、これらのノード上の名前付きインターフェイスのエイリアスとしてnic1、nic2、および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.110.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 のインストール を参照してください。
手順
/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"ご自分のデプロイメントに該当するその他の環境ファイルと共に、カスタム 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 }}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 はサポートを追加する予定はありません。
手順
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 アンダークラウドのインストールが成功しました。
手順
-
アンダークラウドホストに
stackユーザーとしてログインします。 source コマンドでアンダークラウドの認証情報ファイルを読み込みます。
$ source ~/stackrc
カスタム YAML 環境ファイルを作成します。
例
$ vi /home/stack/templates/custom-environment.yaml
環境ファイルには、キーワード
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です。
コア heat テンプレート、環境ファイル、およびこの新しいカスタム環境ファイルを指定して、deployment コマンドを実行します。
重要後で実行される環境ファイルで定義されているパラメーターとリソースが優先されることになるため、環境ファイルの順序は重要となります。
例
$ openstack overcloud deploy --templates \ -e /home/stack/templates/custom-environment.yaml
関連情報
- Director インストールと使用方法 ガイドの 環境ファイル
- Director インストールと使用方法 ガイドの オーバークラウドの作成時の環境ファイルの追加
10.6. ネットワークインターフェイスボンディング
カスタムネットワーク設定では、さまざまなボンディングオプションを使用することができます。
10.6.1. オーバークラウドノードのネットワークインターフェイスボンディング
複数の物理 NIC をバンドルして、単一の論理チャネルを形成することができます。この設定はボンディングとも呼ばれます。ボンディングを設定して、高可用性システム用の冗長性またはスループットの向上を実現することができます。
Red Hat OpenStack Platform では、Open vSwitch (OVS) カーネルボンディング、OVS-DPDK ボンディング、および Linux カーネルボンディングがサポートされます。
表10.10 サポート対象のインターフェイスボンディングの種別
| ボンディング種別 | 種別の値 | 許可されるブリッジ種別 | 許可されるメンバー |
|---|---|---|---|
| OVS カーネルボンディング |
|
|
|
| OVS-DPDK ボンディング |
|
|
|
| Linux カーネルボンディング |
|
|
|
ovs_bridge と ovs_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.4. Open vSwitch (OVS) ボンディングモードでの Link Aggregation Control Protocol (LACP) の使用
ボンディングを、オプションの Link Aggregation Control Protocol (LACP) と共に使用することができます。LACP は動的ボンディングを作成するネゴシエーションプロトコルで、これにより負荷分散機能および耐障害性を持たせることができます。
以下の表を使用して、LACP オプションと組み合わせた OVS カーネルおよび OVS-DPDK ボンディングインターフェイスのサポート互換性について説明します。
OVS/OVS-DPDK balance-tcp モードは、テクノロジープレビューとしてのみ利用可能です。
Control ネットワークおよび Storage ネットワークの場合、Red Hat では VLAN を使用する Linux ボンディングを LACP と組み合わせて使用することを推奨します。OVS ボンディングを使用すると、更新、ホットフィックス等の理由により OVS または neutron エージェントが再起動すると、コントロールプレーンの中断が生じる可能性があるためです。Linux ボンディング/LACP/VLAN の設定であれば、OVS の中断を懸念することなく NIC を管理できます。
表10.11 OVS カーネルおよび OVS-DPDK ボンディングモードの LACP オプション
| 目的 | OVS ボンディングモード | 互換性のある LACP オプション | 備考 |
| 高可用性 (active-passive) |
|
| |
| スループットの向上 (active-active) |
|
|
|
|
|
|
|
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 }}1 つの VLAN を持つ
802.3adLACP モードに設定された Linux ボンディング- 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+ 形式に変換できます。
手順
変換ツールをダウンロードします。
-
/usr/share/openstack-tripleo-heat-templates/tools/convert_v1_net_data.py
-
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 テンプレート
- その他のカスタムネットワークファイル
手順
変換ツールをダウンロードします。
-
/usr/share/openstack-tripleo-heat-templates/tools/convert_heat_nic_config_to_ansible_j2.py
-
コンピュートとコントローラーの 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ファイルを生成します。-
生成された各
.j2ファイルを検査して、設定が環境に対して正しく、また完全であることを確認します。次に、手動で、変換できなかった設定を強調表示するツールが生成したコメントに、手動で対応します。NIC 設定を Jinja2 形式に手動で変換する方法は、Heat パラメーターから Ansible 変数へのマッピング を参照してください。 生成された
.j2ファイルを指すように、network-environment.yamlファイルの*NetworkConfigTemplateパラメーターを設定します。parameter_defaults: ControllerNetworkConfigTemplate: '/home/stack/templates/custom-nics/controller.j2' ComputeNetworkConfigTemplate: '/home/stack/templates/custom-nics/compute.j2'
古いネットワーク設定ファイルの
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 テンプレート
- その他のカスタムネットワークファイル
手順
-
Jinja2 テンプレートを作成します。
os-net-configスキーマを使用して新しいテンプレートを作成するか、アンダークラウドノードの/usr/share/ansible/roles/tripleo_network_config/templates/ディレクトリーからサンプルテンプレートをコピーして編集できます。 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 %}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 変数へのマッピング を参照してください。生成された
.j2ファイルを指すように、network-environment.yamlファイルの*NetworkConfigTemplateパラメーターを設定します。parameter_defaults: ControllerNetworkConfigTemplate: '/home/stack/templates/custom-nics/controller.j2' ComputeNetworkConfigTemplate: '/home/stack/templates/custom-nics/compute.j2'
古いネットワーク設定ファイルの
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 形式に変換するには、Ansible 変数を使用してデプロイのネットワークプロパティーを設定する必要があります。たとえば、現在のデプロイで get_param: InternalApiNetworkVlanID を使用して vlan_id を設定している場合は、新しい Jinja2 テンプレートで次の設定に置き換えます。
vlan_id: {{ internal_api_vlan_id }}
次の表は、heat パラメーターから同等の Ansible vars へのマッピングで利用できるものを一覧にしています。
表10.13 heat パラメーターから Ansible vars へのマッピング
| Heat パラメーター | Ansible vars |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
bond_interface_ovs_options、num_dpdk_interface_rx_queues、および dns_search_domains パラメーターの値は、overcloud-baremetal-deploy.yaml 設定ファイルの network_config セクションで指定する必要があります。
表に記載されていない 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>は、設定するプロパティー (ip、vlan_id、またはmtuなど) に置き換えます。
たとえば、各 NetworkVlanID の値を動的に入力するには、{{ <network_name>_vlan_id }} を次の設定に置き換えます。
{{ lookup(‘vars’, networks_lower[network] ~ ‘_vlan_id’) }}`10.7.5. ネットワークデータスキーマの変更
ネットワークデータスキーマは、Red Hat OpenStack Platform (RHOSP) 17 で更新されました。RHOSP 16 以前で使用されていたネットワークデータスキーマと、RHOSP 17 以降で使用されていたネットワークデータスキーマの主な違いは次のとおりです。
-
ベースサブネットは、
サブネットマップに移動されました。これにより、スパインリーフネットワーキングなど、ルーティングされないデプロイメントとルーティングされるデプロイメントの設定が調整されます。 -
無効なネットワークを無視するために、
enabledオプションが使用されなくなりました。代わりに、設定ファイルから無効なネットワークを削除する必要があります。 -
compat_nameオプションは、このオプションを使用していた heat リソースが削除されたため、不要になりました。 -
ip_subnet、gateway_ip、allocation_pools、routes、ipv6_subnet、gateway_ipv6、ipv6_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章 オーバークラウドのプロビジョニングとデプロイ
オーバークラウドを作成するには、以下のタスクを実行する必要があります。
物理ネットワークのネットワークリソースをプロビジョニングします。
- ネットワークの分離またはカスタム設定可能ネットワークをデプロイする場合は、ネットワーク定義ファイルを YAML 形式で作成します。
- ネットワーク定義ファイルを含め、ネットワークプロビジョニングコマンドを実行します。
- YAML 形式でネットワーク仮想 IP (VIP) 定義ファイルを作成します。
- ネットワーク VIP 定義ファイルを含め、ネットワーク VIP プロビジョニングコマンドを実行します。
ベアメタルノードをプロビジョニングします。
- ノード定義ファイルを yaml 形式で作成します。
- ノード定義ファイルを含め、ベアメタルノードプロビジョニングコマンドを実行します。
オーバークラウドをデプロイします。
- プロビジョニングコマンドにより生成される heat 環境ファイルを指定して、デプロイメントコマンドを実行します。
11.1. オーバークラウドネットワークのプロビジョニング
Red Hat OpenStack Platform (RHOSP) 物理ネットワーク環境のネットワークリソースを設定するには、次のタスクを実行する必要があります。
- オーバークラウドのネットワークリソースを設定およびプロビジョニングします。
- オーバークラウドのネットワーク仮想 IP を設定およびプロビジョニングします。
11.1.1. オーバークラウドのネットワーク定義の設定とプロビジョニング
YAML 形式のネットワーク定義ファイルで、オーバークラウドの物理ネットワークを設定します。プロビジョニングプロセスでは、ネットワーク仕様を含むネットワーク定義ファイルから heat 環境ファイルが作成されます。オーバークラウドをデプロイするときに、デプロイメントコマンドにこの heat 環境ファイルを含めます。
前提条件
- アンダークラウドがインストールされます。詳しくは、Installing director を参照してください。
手順
source コマンドで
stackrcアンダークラウド認証情報ファイルを読み込みます。$ source ~/stackrc
必要なサンプルネットワーク定義テンプレートを
/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
ネットワーク環境に合わせてネットワーク定義ファイルを設定します。たとえば、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- 環境のその他のネットワークとネットワーク属性を設定します。ネットワーク定義ファイルでネットワーク属性の設定に使用できるプロパティーの詳細は、オーバークラウドネットワークの設定 を参照してください。
オーバークラウドネットワークをプロビジョニングします。
(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など) に置き換えます。
-
オプション:
ネットワークのプロビジョニングが完了したら、次のコマンドを使用して、作成されたネットワークとサブネットを確認できます。
(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 環境ファイルを含めます。
前提条件
- アンダークラウドがインストールされます。詳しくは、Installing director を参照してください。
- オーバークラウドネットワークがプロビジョニングされます。詳細は、オーバークラウドのネットワーク定義の設定とプロビジョニング を参照してください。
手順
source コマンドで
stackrcアンダークラウド認証情報ファイルを読み込みます。$ source ~/stackrc
必要なサンプルネットワーク 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
オプション: 環境に合わせて VIP 定義ファイルを設定します。たとえば、次の例では、External ネットワークとコントロールプレーンの VIP を定義しています。
- network: external dns_name: overcloud - network: ctlplane dns_name: overcloud
- 環境のその他のネットワーク VIP 属性を設定します。VIP 定義ファイルで VIP 属性の設定に使用できるプロパティーの詳細は コンポーザブルネットワークの追加 を参照してください。
ネットワーク 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など) に置き換えます。
-
オプション:
ネットワーク VIP のプロビジョニングが完了したら、次のコマンドを使用して、作成された VIP を確認できます。
(undercloud)$ openstack port list (undercloud)$ openstack port show <port>
-
<port>は、確認するポートの名前または UUID に置き換えます。
-
次のステップ
11.2. ベアメタルオーバークラウドノードのプロビジョニング
Red Hat OpenStack Platform (RHOSP) 環境を設定するには、次のタスクを実行する必要があります。
- オーバークラウドのベアメタルノードを登録します。
- ベアメタルノードのハードウェアのインベントリーをディレクターに提供します。
- ノード定義ファイルで、ベアメタルノードの数量、属性、およびネットワークレイアウトを設定します。
- ベアメタルノードに、指定のノードとこのノードを合致させるリソースクラスを割り当てます。
プロファイルを一致させてオーバークラウドノードを指定するなど、追加のオプションのタスクを実行することもできます。
11.2.1. オーバークラウドノードの登録
ディレクターには、ノードのハードウェアと電源管理の詳細を指定するノード定義テンプレートが必要です。このテンプレートは、JSON 形式の nodes.json または YAML 形式の nodes.yaml で作成できます。
手順
ノードを一覧表示する
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 アドレス
テンプレートのフォーマットと構文を確認します。
$ source ~/stackrc (undercloud)$ openstack overcloud node import --validate-only ~/nodes.json
-
テンプレートファイルを
stackユーザーのホームディレクトリー (/home/stack/nodes.json) に保存します。 テンプレートを director にインポートして、各ノードをテンプレートから director に登録します。
(undercloud)$ openstack overcloud node import ~/nodes.json
ノードの登録および設定が完了するまで待ちます。完了したら、ノードが 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 アドレスごとにポートを作成できます。
自動イントロスペクションの代わりに、ベアメタルノードのハードウェア情報をディレクターに手動で提供できます。詳細は、ベアメタルノードのハードウェア情報の手動設定 を参照してください。
前提条件
- オーバークラウドのベアメタルノードを登録しました。
手順
-
アンダークラウドホストに
stackユーザーとしてログインします。 stackrcアンダークラウド認証情報ファイルを入手します。$ source ~/stackrc
pre-introspection 検証グループを実行して、プリイントロスペクションの要件を確認します。
(undercloud)$ validation run --group pre-introspection \ --inventory <inventory_file>
<inventory_file>ファイルを Ansible インベントリーファイルの名前および場所に置き換えます (例:~/tripleo-deploy/undercloud/tripleo-ansible-inventory.yaml)。注記検証を実行すると、出力の
Reasons列は 79 文字に制限されます。検証結果を完全に表示するには、検証ログファイルを表示します。
- 検証レポートの結果を確認します。
オプション: 特定の検証からの詳細な出力を確認します。
(undercloud)$ validation history get --full <UUID>
<UUID>は、確認するレポートの特定の検証の UUID に置き換えます。重要検証結果が
FAILEDであっても、Red Hat OpenStack Platform のデプロイや実行が妨げられることはありません。ただし、FAILEDの検証結果は、実稼働環境で問題が発生する可能性があることを意味します。
各ノードのハードウェア属性を検証します。すべてのノードまたは特定のノードのハードウェア属性を検査できます。
すべてのノードのハードウェア属性を検査します。
(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 に置き換えます。
-
別のターミナルウィンドウで、イントロスペクションの進捗ログを監視します。
(undercloud)$ sudo tail -f /var/log/containers/ironic-inspector/ironic-inspector.log
重要イントロスペクションプロセスが完了するまで実行されていることを確認します。イントロスペクションは通常、ベアメタルノードの場合 15 分かかります。ただし、イントロスペクションネットワークのサイズが正しくないと、時間がかかる可能性があり、イントロスペクションが失敗する可能性があります。
オプション: 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を設定しました。詳細は、オーバークラウドノードの登録 を参照してください。
手順
-
アンダークラウドホストに
stackユーザーとしてログインします。 stackrcアンダークラウド認証情報ファイルを入手します。$ source ~/stackrc
登録されたノードごとに、ブートオプションを
localに設定します。(undercloud)$ openstack baremetal node set <node> \ --property capabilities="boot_option:local"
-
<node>をベアメタルノードの ID に置き換えてください。
-
ノードドライバーのデプロイカーネルとデプロイ 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) に置き換えます。
-
ノードの属性を更新して、ノード上のハードウェアの仕様と一致するようにします。
(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>は、アーキテクチャータイプに置き換えます。
-
オプション: 各ノードの IPMI 暗号スイートを指定します。
(undercloud)$ openstack baremetal node set <node> \ --driver-info ipmi_cipher_suite=<version>
-
<node>をベアメタルノードの ID に置き換えてください。 <version>は、ノードで使用する暗号スイートのバージョンに置き換えます。以下の有効な値のいずれかに設定します。-
3- ノードは SHA1 暗号スイートで AES-128 を使用します。 -
17- ノードは SHA256 暗号スイートで AES-128 を使用します。
-
-
オプション: 複数のディスクがある場合は、ルートデバイスのヒントを設定して、デプロイメントに使用するディスクをデプロイ 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)。このプロパティーは、永続デバイス名が付いたデバイスにのみ使用してください。注記複数のプロパティーを指定する場合には、デバイスはそれらの全プロパティーと一致する必要があります。
-
-
プロビジョニングネットワーク上の NIC の MAC アドレスを使用してポートを作成することにより、Bare Metal Provisioning サービスにノードのネットワークカードを通知します。
(undercloud)$ openstack baremetal port create --node <node_uuid> <mac_address>
-
<node_uuid>をベアメタルノードの一意の ID に置き換えます。 -
<mac_address>は、PXE ブートに使用する NIC の MAC アドレスに置き換えます。
-
ノードの設定を検証します。
(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 など、ノード定義ファイルで設定したノード仕様が含まれています。オーバークラウドをデプロイする際に、このファイルをデプロイメントコマンドに追加します。プロビジョニングプロセスでは、ノード定義ファイル内の各ノードまたはロールに対して定義されたすべてのネットワークのポートリソースもプロビジョニングされます。
前提条件
- アンダークラウドがインストールされます。詳しくは、Installing director を参照してください。
- ベアメタルノードは登録とイントロスペクトが行われ、プロビジョニングとデプロイメントに使用できます。詳細は、Registering nodes for the overcloud と ベアメタルノードハードウェアのインベントリー作成 を参照してください。
手順
source コマンドで
stackrcアンダークラウド認証情報ファイルを読み込みます。$ source ~/stackrc
overcloud-baremetal-deploy.yamlノード定義ファイルを作成し、プロビジョニングするロールごとにノード数を定義します。たとえば、3 つのコントローラーノードと 3 つのコンピュートノードをプロビジョニングするには、以下の設定をovercloud-baremetal-deploy.yamlファイルに追加します。- name: Controller count: 3 - name: Compute count: 3
オプション: 予測ノード配置を設定します。たとえば、以下の設定を使用すると、3 つのコントローラーノードがノード
node00、node01、およびnode02に、3 つのコンピュートノードがノードnode04、node05、および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オプション: デフォルトでは、プロビジョニングプロセスは
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ロールのすべてのノードのネットワークレイアウト、または特定のノードのネットワークレイアウトを定義します。
特定のノード
次の例では、特定のコントローラーノードのネットワークをプロビジョニングし、予測可能な 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 テンプレートを作成できます。
オプション: デフォルトのディスクパーティションサイズが要件を満たさない場合は、ディスクパーティションサイズの割り当てを設定します。たとえば、
/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>を、ログファイルに割り当てるディスクのサイズに置き換えます。
-
-
Object Storage サービス (swift) とディスク全体のオーバークラウドイメージ
overcloud-hardened-uefi-fullを使用する場合に、ディスクのサイズと/varおよび/srvのストレージ要件に基づいて/srvパーティションのサイズを設定する必要があります。詳細は、Object Storage サービスのディスクパーティション全体の設定 を参照してください。 - オプション: カスタムリソースクラスまたはプロファイル機能を使用して、オーバークラウドノードを特定のロールに指定します。詳細は、リソースクラスを一致させることによるオーバークラウドノードのロールの指定 および プロファイルを一致させることによるオーバークラウドノードのロールの指定 を参照してください。
- ノードに割り当てるその他の属性を定義します。ノード定義ファイルでノード属性を設定するために使用できるプロパティーについて詳しくは、ベアメタルノードのプロビジョニング属性 を参照してください。ノード定義ファイルの例は、ノード定義ファイルの例 を参照してください。
オーバークラウドノードをプロビジョニングします。
(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.yamlAnsible Playbook にネットワーク定義を提供します。 -
<deployment_file>は、デプロイメントコマンドに含めるために生成する heat 環境ファイルの名前に置き換えます (例:/home/stack/templates/overcloud-baremetal-deployed.yaml)。 -
<node_definition_file>は、ノード定義ファイルの名前 (overcloud-baremetal-deploy.yamlなど) に置き換えます。
-
オプション:
別のターミナルでプロビジョニングの進捗を監視します。
(undercloud)$ watch openstack baremetal node list
-
プロビジョニングが成功すると、ノードの状態が
availableからactiveに変わります。 - ノードのハードウェアまたはネットワーク設定の障害が原因でノードのプロビジョニングが失敗した場合は、プロビジョニング手順を再度実行する前に、失敗したノードを削除できます。詳細については、障害が発生したベアメタルノードをノード定義ファイルから削除する を参照してください。
-
プロビジョニングが成功すると、ノードの状態が
metalsmithツールを使用して、割り当てやポートなどを含むノードの統合ビューを取得します。(undercloud)$ metalsmith list
ノードとホスト名の関連付けを確認します。
(undercloud)$ openstack baremetal allocation list
次のステップ
11.2.4. ベアメタルノードのプロビジョニング属性
次の表を使用して、ノード属性を設定するために使用できるプロパティーと、openstack baremetal node provision コマンドでベアメタルノードをプロビジョニングするときに使用できる値を理解してください。
- ロールのプロパティー: ロールのプロパティーを使用して、各ロールを定義します。
- 各ロールのデフォルトプロパティーとインスタンスプロパティー: デフォルトプロパティーまたはインスタンスプロパティーを使用して、使用可能なノードのプールからノードを割り当てるための選択基準を指定し、ベアメタルノードの属性とネットワーク設定プロパティーを設定します。
ベアメタル定義ファイルの作成については、オーバークラウド用のベアメタルノードのプロビジョニング を参照してください。
表11.1 ロールのプロパティー
| プロパティー | 値 |
|---|---|
|
| ロール名 (必須) |
|
|
このロール用にプロビジョニングするノード数。デフォルト値は |
|
|
|
|
|
特定のノードの属性を指定するために使用可能な値のディクショナリー。 |
|
|
このロールのデフォルトのホスト名形式を上書きします。デフォルトで生成されるホスト名は、オーバークラウドのスタック名、ロール、および増分インデックス (すべて小文字) から派生します。たとえば、Controller ロールのデフォルト形式は、 |
|
|
Ansible Playbook と Ansible 変数の値のディクショナリー。Playbook は、ノードをプロビジョニングしてから、かつノードのネットワークを設定する前に、ロールインスタンスに対して実行されます。Ansible Playbook の指定の詳細は、 |
表11.2 defaults と instances のプロパティー
| プロパティー | 値 |
|---|---|
|
|
( |
|
|
( |
|
|
ノードにプロビジョニングするイメージの詳細。サポート対象の |
|
| ノードのケイパビリティーを照合する際の選択基準 |
|
|
ノードに渡された設定ドライブにデータと初回起動コマンドを追加します。詳細は、 |
|
|
インスタンスを metalsmith でプロビジョニングするには、 |
|
|
インスタンスネットワークを表すディクショナリーのリスト。ネットワーク属性の設定の詳細については、 |
|
|
ロールまたはインスタンスのネットワーク設定ファイルへのリンク。ネットワーク設定ファイルへのリンクの設定の詳細は、 |
|
| プロファイルマッチングの選択基準。詳細は、プロファイルを照合することによるオーバークラウドノードへのロール指定 を参照してください。 |
|
|
ノードをプロビジョニングするには、 |
|
|
ノードのリソースクラスを照合する際の選択基準。デフォルト値は |
|
|
ルートパーティションのサイズ (GiB 単位)。デフォルト値は |
|
| スワップパーティションのサイズ (MiB 単位) |
|
| ノード特性を照合する際の選択基準としての特性の一覧 |
表11.3 image プロパティー
| プロパティー | 値 |
|---|---|
|
|
ノードにプロビジョニングするルートパーティションまたはディスクイメージ全体の URL を指定します。サポートされている URL スキーム: 注記
|
|
|
ルートパーティションまたはディスクイメージ全体の MD5 チェックサムを指定します。 |
|
| カーネルイメージのイメージ参照または URL を指定します。パーティションイメージに対してのみ、この属性を使用します。 |
|
| RAM ディスクイメージのイメージ参照または URL を指定します。パーティションイメージに対してのみ、この属性を使用します。 |
表11.4 network プロパティー
| プロパティー | 値 |
|---|---|
|
| このネットワークに使用する特定の IP アドレス |
|
| ネットワークポートを作成するネットワーク。 |
|
| ネットワークポートを作成するサブネット。 |
|
| 新しいポートを作成する代わりに使用する既存のポート。 |
|
|
プロビジョニングネットワーク ( |
表11.5 network_config プロパティー
| プロパティー | 値 |
|---|---|
|
| ノードのネットワーク設定を適用するときに使用する Ansible J2 NIC 設定テンプレートを指定します。NIC テンプレートの設定については、オーバークラウドネットワークの設定 を参照してください。 |
|
|
External ネットワークにアクセスするために作成する OVS ブリッジの名前。デフォルトのブリッジ名は |
|
|
パブリックブリッジに追加するインターフェイスの名前を指定します。デフォルトのインターフェイスは |
|
|
更新時にネットワーク設定の変更を適用するには、 |
|
|
各ノードまたはノードグループの NIC マッピング設定 |
|
|
デフォルトルートに使用するネットワーク。デフォルトのルートネットワークは |
|
| ノードのネットワークを設定するときにスキップするネットワークのリスト。 |
|
|
|
|
|
結合インターフェイスに使用する OVS オプションまたは結合オプション。たとえば、OVS のボンディングの場合は |
|
| DPDK ボンドまたは DPDK ポートに必要な RX キューの数を指定します。 |
表11.6 config_drive プロパティー
| プロパティー | 値 |
|---|---|
|
|
ノードの起動時に実行するタスクの |
|
|
config-drive |
表11.7 ansible_playbooks プロパティー
| プロパティー | 値 |
|---|---|
|
| ロール定義 YAML ファイルに相対的な、Ansible Playbook へのパス。 |
|
| Playbook の実行時に設定する追加の Ansible 変数。次の構文を使用して、追加の変数を指定します。 ansible_playbooks:
- playbook: a_playbook.yaml
extra_vars:
param1: value1
param2: value2
たとえば、ディスク全体のオーバークラウドイメージ 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 を参照してください。
- ノードのハードウェア障害が原因で、ベアメタルノードのプロビジョニングが失敗しました。
手順
source コマンドで
stackrcアンダークラウド認証情報ファイルを読み込みます。$ source ~/stackrc
-
overcloud-baremetal-deploy.yamlノード定義ファイルを開きます。 ノードが割り当てられているロールの
countパラメーターを減らします。たとえば、以下の設定は、ObjectStorageロールのカウントパラメーターを更新して、ObjectStorage専用のノード数が 3 に減ったことを反映します。- name: ObjectStorage count: 3
-
ロールの
instances属性でまだ定義されていない場合は、スタックから削除するノードのhostnameとnameを定義します。 削除するノードに属性
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ベアメタルノードのプロビジョニングを解除します。
(undercloud)$ openstack overcloud node unprovision \ --stack <stack> \ --network-ports \ /home/stack/templates/overcloud-baremetal-deploy.yaml
-
<stack>を、ベアメタルノードがプロビジョニングされるスタックの名前に置き換えます。指定しない場合、デフォルトはovercloudです。
-
オーバークラウドノードをプロビジョニングして、デプロイメントコマンドに含める 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 のリソースクラスが割り当てられます。
ノードのプロビジョニング後にノードに割り当てられたリソースクラスを変更するには、スケールダウン手順を使用してノードのプロビジョニングを解除してから、スケールアップ手順を使用して、新しいリソースクラスの割り当てでノードを再プロビジョニングする必要があります。詳細は、オーバークラウドノードのスケーリング を参照してください。
前提条件
- オーバークラウド用のベアメタルノードの初期プロビジョニングを実行しています。
手順
カスタムリソースクラスを持つロールに指定する各ベアメタルノードを割り当てます。
(undercloud)$ openstack baremetal node set \ --resource-class <resource_class> <node>
-
<resource_class>は、リソースクラスの名前 (baremetal.CPU-PINNINGなど) に置き換えます。 -
<node>をベアメタルノードの ID に置き換えてください。
-
-
まだ定義されていない場合は、
overcloud-baremetal-deploy.yamlファイルにロールを追加します。 ロールのノードに割り当てるリソースクラスを指定します。
- name: <role> count: 1 defaults: resource_class: <resource_class>-
<role>をロールの名前に置き換えます。 -
<resource_class>は、手順 1 で指定したリソースクラスの名前に置き換えます。
-
- オーバークラウドのベアメタルノードのプロビジョニング に戻り、プロビジョニングプロセスを完了します。
11.2.7. プロファイルを一致させることによるオーバークラウドノードのロールの指定
プロファイル機能を使用して、オーバークラウドノードを特定のロールに指定できます。プロファイルは、ノードの機能をデプロイメントロールと照合します。
イントロスペクションルールを使用して、自動プロファイル割り当てを実行することもできます。詳しくは、プロファイルの自動タグ付けの設定 を参照してください。
ノードのプロビジョニング後にノードに割り当てられたプロファイルを変更するには、スケールダウン手順を使用してノードのプロビジョニングを解除してから、スケールアップ手順を使用して、新しいプロファイルの割り当てでノードを再プロビジョニングする必要があります。詳細は、オーバークラウドノードのスケーリング を参照してください。
前提条件
- オーバークラウド用のベアメタルノードの初期プロビジョニングを実行しています。
手順
新しいノード機能を追加するたびに、既存のノード機能が上書きされます。したがって、再設定するには、登録済みの各ノードの既存の機能を取得する必要があります。
$ openstack baremetal node show <node> \ -f json -c properties | jq -r .properties.capabilities
ノードの既存の機能に
profile:<profile>を追加して、ロールプロファイルに一致させる各ベアメタルノードにプロファイル機能を割り当てます。(undercloud)$ openstack baremetal node set <node> \ --property capabilities="profile:<profile>,<capability_1>,...,<capability_n>"
-
<node>は、ベアメタルノードの名前または ID に置き換えます。 -
<profile>は、ロールプロファイルに一致するプロファイルの名前に置き換えます。 -
<capability_1>および<capability_n>までのすべての機能は、手順 1 で取得した各機能に置き換えます。
-
-
まだ定義されていない場合は、
overcloud-baremetal-deploy.yamlファイルにロールを追加します。 ロールのノードに割り当てるプロファイルを定義します。
- name: <role> count: 1 defaults: profile: <profile>-
<role>をロールの名前に置き換えます。 -
<profile>は、ノードの機能に一致するプロファイルの名前に置き換えます。
-
- オーバークラウドのベアメタルノードのプロビジョニング に戻り、プロビジョニングプロセスを完了します。
11.2.8. Object Storage サービスのディスクパーティション全体の設定
ディスクイメージ全体である overcloud-hardened-uefi-full は、個別のボリュームに分割されます。デフォルトでは、ディスク全体のオーバークラウドイメージでデプロイされたノードの /var パーティションは、ディスクが完全に割り当てられるまで自動的に増加します。Object Storage サービス (swift) を使用する場合は、ディスクのサイズと /var および /srv のストレージ要件に基づいて /srv パーティションのサイズを設定します。
前提条件
- オーバークラウド用のベアメタルノードの初期プロビジョニングを実行しています。
手順
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%
- オーバークラウドのベアメタルノードのプロビジョニング に戻り、プロビジョニングプロセスを完了します。
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: node0611.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) で利用可能でなければなりません。
- ベアメタルフレーバー
- クリーニングおよびプロビジョニング用ネットワーク
手順
-
アンダークラウドホストに
stackユーザーとしてログインします。 stackrcアンダークラウド認証情報ファイルを入手します。$ source ~/stackrc
Bare Metal Provisioning サービスの起動インターフェイスを
redfish-virtual-mediaに設定します。(undercloud)$ openstack baremetal node set --boot-interface redfish-virtual-media <node>
-
<node>はノード名に置き換えてください。
-
ESP イメージを定義します。
(undercloud)$ openstack baremetal node set --driver-info bootloader=<esp> <node>
-
<esp>を Image サービス (glance) イメージの UUID または ESP イメージの URL に置き換えます。 -
<node>はノード名に置き換えてください。
-
ベアメタルノードにポートを作成し、そのポートをベアメタルノード上の 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 は、複数のディスク設定でルートディスクを識別する必要があります。オーバークラウドイメージは、プロビジョニングプロセス中にルートディスクに書き込まれます。
ハードウェアプロパティーは、ルートディスクを識別するために使用されます。ルートディスクを特定するのに使用できるプロパティーの詳細は、「ルートディスクを識別するプロパティー」 を参照してください。
手順
各ノードのハードウェアイントロスペクションからのディスク情報を確認します。
(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" } ]
-
一意のハードウェアプロパティーを使用して、ノードのルートディスクを設定します。
(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
-
- 最初にネットワークから起動し、次にルートディスクから起動するように、各ノードの 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 ボンディングの作成 を参照してください。
手順
-
overcloud-baremetal-deploy.yamlファイルを開きます。 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: node02roles_data.yamlロール定義ファイルで、rhsm_enforceパラメーターをFalseに設定します。rhsm_enforce: False
プロビジョニングコマンドを実行します。
(undercloud)$ openstack overcloud node provision \ --stack stack \ --output /home/stack/templates/overcloud-baremetal-deployed.yaml \ /home/stack/templates/overcloud-baremetal-deploy.yaml
-
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 オプションを使用してオーバークラウドに追加した環境ファイルはいずれも、オーバークラウドのスタック定義の一部となります。後で指定する環境ファイルで定義されるパラメーターとリソースが優先されることになるため、環境ファイルの順番は重要です。
初回のデプロイメント後にオーバークラウド設定を変更するには、以下のアクションを実行します。
- カスタムの環境ファイルおよび heat テンプレートのパラメーターを変更します。
-
同じ環境ファイルを指定して
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 を使用してください。
手順
証明書ファイルを開き、証明書部分だけをコピーします。鍵を含めないでください。
$ vi /home/stack/ca.crt.pem
必要となる証明書部分の例を、以下に示します。
-----BEGIN CERTIFICATE----- MIIDlTCCAn2gAwIBAgIJAOnPtx2hHEhrMA0GCSqGSIb3DQEBCwUAMGExCzAJBgNV BAYTAlVTMQswCQYDVQQIDAJOQzEQMA4GA1UEBwwHUmFsZWlnaDEQMA4GA1UECgwH UmVkIEhhdDELMAkGA1UECwwCUUUxFDASBgNVBAMMCzE5Mi4xNjguMC4yMB4XDTE3 -----END CERTIFICATE-----
以下に示す内容で
/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 設定に関連する他の証明書が含まれる場合があります。
-
/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の検証結果は、実稼働環境で問題が発生する可能性があることを意味します。
手順
-
アンダークラウドホストに
stackユーザーとしてログインします。 stackrcアンダークラウド認証情報ファイルを入手します。$ source ~/stackrc
デプロイメントに必要なすべての環境ファイルを使用して、オーバークラウド計画を更新します。
$ openstack overcloud deploy --templates \ -e environment-file1.yaml \ -e environment-file2.yaml \ ... --stack-only
オーバークラウドスタックを検証します。
$ validation run \ --group pre-deployment \ --inventory <inventory_file>
-
<inventory_file>ファイルを Ansible インベントリーファイルの名前および場所に置き換えます (例:~/tripleo-deploy/undercloud/tripleo-ansible-inventory.yaml)。
注記検証を実行すると、出力の
Reasons列は 79 文字に制限されます。検証結果を完全に表示するには、検証ログファイルを表示します。-
検証レポートの結果を確認します。
$ 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 コマンドで使用できるオプションについては、デプロイメントコマンドのオプション を参照してください。
手順
オーバークラウド環境に必要な環境ファイルと設定ファイル (director のインストールで提供される未編集の heat テンプレートファイルと作成したカスタム環境ファイルの両方) を照合します。これには、次のファイルが含まれている必要があります。
-
overcloud-baremetal-deployed.yamlノード定義ファイル。 -
overcloud-networks-deployed.yamlネットワーク定義ファイル。 -
overcloud-vip-deployed.yamlネットワーク VIP 定義ファイル。 - コンテナー化された OpenStack サービスのコンテナーイメージの場所。
- Red Hat CDN または Satellite 登録用の環境ファイル
- その他のカスタム環境ファイル
-
- 環境ファイルと設定ファイルを優先順位に従って整理し、編集されていない Heat テンプレートファイル、その次にデフォルトプロパティーのオーバーライドなどのカスタム設定を含む環境ファイルをリストします。
以下の例のように、設定ファイルとテンプレートを必要な順序で指定して、
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
- カスタムロールを使用する、またはマルチアーキテクチャークラウドを有効にする場合に生成されるロールデータ。
オーバークラウドの作成が完了すると、オーバークラウドを設定するために実施された 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 ****** ========================================================================
オーバークラウドの作成が完了すると、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 デプロイメントコマンドのオプション
| パラメーター | 説明 |
|---|---|
|
|
デプロイする heat テンプレートが含まれるディレクトリー。空欄にした場合には、デプロイメントコマンドはデフォルトのテンプレートの場所である |
|
| 作成または更新するスタックの名前 |
|
| デプロイメントのタイムアウト時間 (分単位) |
|
| ハイパーバイザーに使用する仮想化タイプ |
|
|
時刻の同期に使用する Network Time Protocol (NTP) サーバー。コンマ区切りリストで複数の NTP サーバーを指定することも可能です (例: |
|
|
環境変数 |
|
|
オーバークラウドノードにアクセスする SSH ユーザーを定義します。通常、SSH アクセスは |
|
| オーバークラウドノードへの SSH アクセスに使用する鍵のパスを定義します。 |
|
| オーバークラウドノードへの SSH アクセスに使用するネットワーク名を定義します。 |
|
|
オーバークラウドのデプロイメントに渡す追加の環境ファイル。このオプションは複数回指定することができます。 |
|
| デプロイメントに追加する環境ファイルが含まれるディレクトリー。デプロイメントコマンドでは、これらの環境ファイルは最初に番号順、その後にアルファベット順で処理されます。 |
|
|
ロールファイルを定義し、 |
|
|
ネットワークファイルを定義し、 |
|
|
プラン環境ファイルを定義し、 |
|
| デプロイメント後に一時ファイルを削除せず、それらの場所をログに記録するには、このオプションを使用します。 |
|
| 実際のデプロイメントを実行せずにプランを更新するには、このオプションを使用します。 |
|
| オーバークラウドの作成プロセスでは、デプロイメントの前に一連のチェックが行われます。このオプションは、デプロイメント前のチェックで何らかの致命的でないエラーが発生した場合に終了します。どのようなエラーが発生してもデプロイメントが失敗するので、このオプションを使用することを推奨します。 |
|
| オーバークラウドの作成プロセスでは、デプロイメントの前に一連のチェックが行われます。このオプションは、デプロイメント前のチェックで何らかのクリティカルではない警告が発生した場合に終了します。 |
|
| オーバークラウドを作成せずにオーバークラウドで検証チェックを実行するには、このオプションを使用します。 |
|
|
|
|
| オーバークラウドデプロイ後の設定を省略するには、このオプションを使用します。 |
|
| オーバークラウドデプロイ後の設定を強制的に行うには、このオプションを使用します。 |
|
|
デプロイメントコマンドで |
|
| 引数とパラメーターが記載された YAML ファイルへのパス |
|
| オーバークラウドサービスのパスワード生成を無効にする場合は、このオプションを使用します。 |
|
|
事前にプロビジョニングされたオーバークラウドノードをデプロイする場合は、このオプションを使用します。 |
|
|
|
|
|
オーバークラウドスタックの作成を無効にして、ソフトウェア設定を適用する |
|
|
保存した |
|
|
Ansible 設定ファイルへのパス。このファイルの設定は、 |
|
|
|
|
|
(テクノロジープレビュー) config-download Playbook の実行を特定のノードまたはノードセットに制限する場合は、このオプションを使用してノードのコンマ区切りリストを指定します。たとえば、 |
|
| (テクノロジープレビュー) config-download の特定のタスクセットでデプロイメントを実施する場合は、このオプションを使用して config-download Playbook からのタグのコンマ区切りリストを指定します。 |
|
| (テクノロジープレビュー) config-download Playbook のタグの一部を省略する場合は、このオプションを使用して省略するタグのコンマ区切りリストを指定します。 |
オプションの全一覧を表示するには、以下のコマンドを実行します。
(undercloud) $ openstack help overcloud deploy
環境ファイルの parameter_defaults セクションに追加する heat テンプレートのパラメーターの使用が優先されるため、一部のコマンドラインパラメーターは古いか非推奨となっています。以下の表では、非推奨となったパラメーターと、それに相当する heat テンプレートのパラメーターを対比しています。
表11.9 非推奨の CLI パラメーターと heat テンプレートのパラメーターの対照表
| パラメーター | 説明 | heat テンプレートのパラメーター |
|---|---|---|
|
| スケールアウトするコントローラーノード数 |
|
|
| スケールアウトするコンピュートノード数 |
|
|
| スケールアウトする Ceph Storage ノードの数 |
|
|
| スケールアウトする Block Storage (cinder) ノード数 |
|
|
| スケールアウトする Object Storage (swift) ノード数 |
|
|
| コントローラーノードに使用するフレーバー |
|
|
| コンピュートノードに使用するフレーバー |
|
|
| Ceph Storage ノードに使用するフレーバー |
|
|
| Block Storage (cinder) ノードに使用するフレーバー |
|
|
| Object Storage (swift) ノードに使用するフレーバー |
|
|
| オーバークラウドの作成プロセスでは、デプロイメントの前に一連のチェックが行われます。このオプションは、デプロイメント前のチェックで何らかの致命的なエラーが発生した場合に終了します。どのようなエラーが発生してもデプロイメントが失敗するので、このオプションを使用することを推奨します。 | パラメーターのマッピングなし |
|
|
デプロイメント前の検証を完全に無効にします。これらの検証は、デプロイメント前の検証として組み込まれていましたが、 | パラメーターのマッピングなし |
|
|
| パラメーターのマッピングなし |
|
| カスタマーポータルまたは Satellite 6 にオーバークラウドノードを登録する場合は、このオプションを使用します。 |
|
|
|
このオプションを使用して、オーバークラウドノードの登録方法を定義します。Red Hat Satellite 6 または Red Hat Satellite 5 の場合は |
|
|
| 登録に使用する組織。 |
|
|
| すでに登録済みでもシステムを登録する場合は、このオプションを使用します。 |
|
|
|
オーバークラウドノードを登録する 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 サーバーの場合は、オーバークラウドは |
|
|
| 登録に使用するアクティベーションキーを定義する場合は、このオプションを使用します。 |
|
これらのパラメーターは、Red Hat OpenStack Platform の今後のリリースで廃止される予定です。
11.3.8. オーバークラウドのデプロイメントの検証
デプロイされたオーバークラウドを検証します。
前提条件
- オーバークラウドをデプロイしている。
手順
source コマンドで
stackrc認証情報ファイルを読み込みます。$ source ~/stackrc
オーバークラウドのデプロイメントを検証します。
$ validation run \ --group post-deployment \ [--inventory <inventory_file>]
<inventory_file>は ansible インベントリーファイルの名前に置き換えます。デフォルトでは、動的インベントリーはtripleo-ansible-inventoryと呼ばれます。注記検証を実行すると、出力の
Reasons列は 79 文字に制限されます。検証結果を完全に表示するには、検証ログファイルを表示します。
検証レポートの結果を確認します。
$ validation show run [--full] <UUID>
-
<UUID>は、検証実行の UUID に置き換えます。 -
オプション:
--fullオプションを使用して、検証実行からの詳細な出力を表示します。
-
検証結果が FAILED であっても、Red Hat OpenStack Platform のデプロイや実行が妨げられることはありません。ただし、FAILED の検証結果は、実稼働環境で問題が発生する可能性があることを意味します。
関連資料
11.3.9. オーバークラウドへのアクセス
director は、アンダークラウドからのオーバークラウドの操作に必要な認証情報を含めて認証情報ファイルを生成します。director は、このファイル overcloudrc を stack ユーザーのホームディレクトリーに保存します。
手順
source コマンドで
overcloudrcファイルを読み込みます。(undercloud)$ source ~/overcloudrc
オーバークラウドにアクセスしていることを示すコマンドプロンプトに切り替わります。
(overcloud)$
アンダークラウドの操作に戻るには、
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 イメージに依存しないカスタムパーティションレイアウトを使用することができます。
このシナリオには、カスタム機能を持たない基本的な設定のみが含まれています。
事前にプロビジョニングされたノードと director がプロビジョニングしたノードを組み合わせることはできません。
11.4.1. 事前にプロビジョニングされたノードの要件
事前にプロビジョニングされたノードを使用してオーバークラウドのデプロイメントを開始する前に、以下の項目が環境に存在していること確認してください。
- 7章アンダークラウドへの director のインストール で作成した director ノード
- ノードに使用するベアメタルマシンのセット。必要なノード数は、作成予定のオーバークラウドのタイプにより異なります。これらのマシンは、各ノード種別に設定された要件に従う必要があります。これらのノードには、ホストオペレーティングシステムとして Red Hat Enterprise Linux 9.0 をインストールする必要があります。Red Hat では、利用可能な最新バージョンの使用を推奨します。
- 事前にプロビジョニングされたノードを管理するためのネットワーク接続 1 つ。このシナリオでは、オーケストレーションエージェントの設定のために、ノードへの SSH アクセスが中断されないようにする必要があります。
コントロールプレーンネットワーク用のネットワーク接続 1 つ。このネットワークには、主に 2 つのシナリオがあります。
プロビジョニングネットワークをコントロールプレーンとして使用するデフォルトのシナリオ:このネットワークは通常、事前にプロビジョニングされたノードから director へのレイヤー 3 (L3) を使用したルーティング可能なネットワーク接続です。このシナリオの例では、以下の IP アドレスの割り当てを使用します。
表11.10 プロビジョニングネットワークの IP 割り当て
ノード名 IP アドレス director
192.168.24.1
Controller 0
192.168.24.2
Compute 0
192.168.24.3
- 別のネットワークを使用するシナリオ:director のプロビジョニングネットワークがプライベートのルーティング不可能なネットワークの場合には、サブネットからノードの IP アドレスを定義して、パブリック API エンドポイント経由で director と通信することができます。このシナリオの要件についての詳細は、「事前にプロビジョニングされたノードへの別ネットワークの使用」を参照してください。
- この例で使用するその他すべてのネットワーク種別も、OpenStack サービス用のコントロールプレーンネットワークを使用します。ただし、ネットワークトラフィックの他のタイプに追加でネットワークを作成することができます。
-
いずれかのノードで Pacemaker リソースが使用される場合、サービスユーザー
haclusterおよびサービスグループhaclientの UID/GID は、189 でなければなりません。これは CVE-2018-16877 に対応するためです。オペレーティングシステムと共に Pacemaker をインストールした場合、インストールによりこれらの ID が自動的に作成されます。ID の値が正しく設定されていない場合は、アーティクル OpenStack minor update / fast-forward upgrade can fail on the controller nodes at pacemaker step with "Could not evaluate: backup_cib" の手順に従って ID の値を変更します。 -
一部のサービスが誤った IP アドレスにバインドされてデプロイメントに失敗するのを防ぐために、
/etc/hostsファイルにnode-name=127.0.0.1のマッピングが含まれないようにします。
11.4.2. 事前にプロビジョニングされたノードでのユーザーの作成
事前にプロビジョニングされたノードを使用してオーバークラウドを設定する場合、director はオーバークラウドノードに SSH アクセスする必要があります。事前にプロビジョニングされたノードで SSH 鍵認証のユーザーを作成し、そのユーザーに対してパスワード不要の sudo アクセスを設定する必要があります。事前にプロビジョニングされたノードでユーザーを作成したら、openstack overcloud deploy コマンドで --overcloud-ssh-user および --overcloud-ssh-key オプションを使用して、事前にプロビジョニングされたノードでオーバークラウドを作成することができます。
デフォルトでは、オーバークラウドの SSH ユーザーおよびオーバークラウドの SSH 鍵の値は、それぞれ stack ユーザーおよび ~/.ssh/id_rsa です。stack ユーザーを作成するには、以下の手順を実施します。
手順
各オーバークラウドノードで、
stackユーザーを作成して、それぞれにパスワードを設定します。コントローラーノードで、以下の例に示すコマンドを実行します。[root@controller-0 ~]# useradd stack [root@controller-0 ~]# passwd stack # specify a password
sudoを使用する際に、このユーザーがパスワードを要求されないようにします。[root@controller-0 ~]# echo "stack ALL=(root) NOPASSWD:ALL" | tee -a /etc/sudoers.d/stack [root@controller-0 ~]# chmod 0440 /etc/sudoers.d/stack
事前にプロビジョニングされた全ノードで
stackユーザーの作成と設定を行った後に、director ノードから各オーバークラウドノードにstackユーザーの公開 SSH 鍵をコピーします。director の公開 SSH 鍵をコントローラーノードにコピーするには、以下の例に示すコマンドを実行します。[stack@director ~]$ ssh-copy-id stack@192.168.24.2
SSH 鍵をコピーするには、各オーバークラウドノードの SSH 設定で一時的に PasswordAuthentication Yes を設定しなければならない場合があります。SSH 鍵をコピーした後に PasswordAuthentication No を設定し、今後は SSH 鍵を使用して認証を行います。
11.4.3. 事前にプロビジョニングされたノードのオペレーティングシステムの登録
それぞれのノードには、Red Hat サブスクリプションへのアクセスが必要です。ノードを Red Hat コンテンツ配信ネットワークに登録するには、各ノードで以下の手順を実施します。root ユーザーとして、または sudo 権限を持つユーザーとしてコマンドを実行します。
記載されたリポジトリーのみを有効にします。追加のリポジトリーを使用すると、パッケージとソフトウェアの競合が発生する場合があります。他のリポジトリーは有効にしないでください。
手順
登録コマンドを実行して、プロンプトが表示されたらカスタマーポータルのユーザー名とパスワードを入力します。
[root@controller-0 ~]# sudo subscription-manager register
Red Hat OpenStack Platform 17.0 のエンタイトルメントプールを検索します。
[root@controller-0 ~]# sudo subscription-manager list --available --all --matches="Red Hat OpenStack"
上記のステップで特定したプール ID を使用して、Red Hat OpenStack Platform 16 のエンタイトルメントをアタッチします。
[root@controller-0 ~]# sudo subscription-manager attach --pool=pool_id
デフォルトのリポジトリーをすべて無効にします。
[root@controller-0 ~]# sudo subscription-manager repos --disable=*
必要な Red Hat Enterprise Linux リポジトリーを有効にします。
[root@controller-0 ~]# 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-beta-for-rhel-9-x86_64-rpms \ --enable=fast-datapath-for-rhel-9-x86_64-rpms
オーバークラウドで Ceph Storage ノードを使用する場合は、該当する Ceph Storage リポジトリーを有効にします。
[root@cephstorage-0 ~]# sudo subscription-manager repos \ --enable=rhel-9-for-x86_64-baseos-rpms \ --enable=rhel-9-for-x86_64-appstream-rpms \ --enable=openstack-beta-deployment-tools-for-rhel-9-x86_64-rpms
Red Hat Ceph Storage ノードを除くすべてのオーバークラウドノードで RHEL バージョンをロックします。
[root@controller-0 ~]# sudo subscription-manager release --set=9.0
システムを更新して、ベースシステムパッケージが最新の状態になるようにします。
[root@controller-0 ~]# sudo dnf update -y [root@controller-0 ~]# sudo reboot
このノードをオーバークラウドに使用する準備ができました。
11.4.4. director への SSL/TLS アクセスの設定
director が SSL/TLS を使用する場合は、事前にプロビジョニングされたノードには、director の SSL/TLS 証明書の署名に使用する認証局ファイルが必要です。独自の認証局を使用する場合には、各オーバークラウドノード上で以下の操作を実施します。
手順
-
事前にプロビジョニングされた各ノードの
/etc/pki/ca-trust/source/anchors/ディレクトリーに認証局ファイルをコピーします。 各オーバークラウドノード上で以下のコマンドを実行します。
[root@controller-0 ~]# sudo update-ca-trust extract
この手順により、オーバークラウドノードが director のパブリック API に SSL/TLS 経由でアクセスできるようになります。
11.4.5. コントロールプレーンのネットワークの設定
事前にプロビジョニングされたオーバークラウドノードは、標準の HTTP 要求を使用して director からメタデータを取得します。これは、オーバークラウドノードでは以下のいずれかに対して L3 アクセスが必要であることを意味します。
-
director のコントロールプレーンネットワーク。これは、
undercloud.confファイルのnetwork_cidrパラメーターで定義するサブネットです。オーバークラウドノードには、このサブネットへの直接アクセスまたはルーティング可能なアクセスのいずれかが必要です。 -
undercloud.confファイルのundercloud_public_hostパラメーターで指定する director のパブリック API エンドポイント。コントロールプレーンへの L3 ルートがない場合や、SSL/TLS 通信を使用する場合に、このオプションを利用することができます。パブリック API エンドポイントを使用するオーバークラウドノードの設定についての詳細は、「事前にプロビジョニングされたノードへの別ネットワークの使用」 を参照してください。
director は、コントロールプレーンネットワークを使用して標準のオーバークラウドを管理、設定します。事前にプロビジョニングされたノードを使用したオーバークラウドの場合には、director と事前にプロビジョニングされたノード間の通信に対応するために、ネットワーク設定を変更しなければならない場合があります。
ネットワーク分離の使用
ネットワーク分離を使用することで、サービスをグループ化してコントロールプレーンなど特定のネットワークを使用することができます。コントロールプレーン上のノードに特定の IP アドレスを定義することも可能です。ネットワークの分離と予測可能なノード配置ストラテジーの作成の詳細は、ネットワークの分離 を参照してください。
ネットワーク分離を使用する場合には、NIC テンプレートに、アンダークラウドのアクセスに使用する NIC を含めないようにしてください。これらのテンプレートにより NIC が再設定され、デプロイメント時に接続性や設定の問題が発生する可能性があります。
IP アドレスの割り当て
ネットワーク分離を使用しない場合には、単一のコントロールプレーンを使用して全サービスを管理することができます。これには、各ノード上のコントロールプレーンの NIC を手動で設定して、コントロールプレーンネットワークの範囲内の IP アドレスを使用するようにする必要があります。director のプロビジョニングネットワークをコントロールプレーンとして使用する場合には、選択したオーバークラウドの IP アドレスが、プロビジョニング (dhcp_start および dhcp_end) とイントロスペクション (inspection_iprange) 両方の DHCP 範囲外になるようにしてください。
標準のオーバークラウド作成中には、director は OpenStack Networking (neutron) ポートを作成し、プロビジョニング/コントロールプレーンネットワークのオーバークラウドノードに IP アドレスを自動的に割り当てます。ただし、これにより、各ノードに手動で設定する IP アドレスとは異なるアドレスを director が割り当ててしまう可能性があります。このような場合には、予測可能な IP アドレス割り当て方法を使用して、director がコントロールプレーン上で事前にプロビジョニングされた IP の割り当てを強制的に使用するようにしてください。
ネットワーク分離を使用している場合は、予測可能な IP 戦略を実装するために、カスタム環境ファイル deploy-ports.yaml を作成します。次のカスタム環境ファイルの例 deploy-ports.yaml は、一連のリソースレジストリーマッピングとパラメーターを director に渡し、事前にプロビジョニングされたノードの IP 割り当てを定義します。NodePortMap、ControlPlaneVipData、および VipPortMap パラメーターは、各オーバークラウドノードに対応する IP アドレスとサブネット CIDR を定義します。
resource_registry: # Deployed Virtual IP port resources OS::TripleO::Network::Ports::ExternalVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/deployed_vip_external.yaml OS::TripleO::Network::Ports::InternalApiVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/deployed_vip_internal_api.yaml OS::TripleO::Network::Ports::StorageVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/deployed_vip_storage.yaml OS::TripleO::Network::Ports::StorageMgmtVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/deployed_vip_storage_mgmt.yaml # Deployed ControlPlane port resource OS::TripleO::DeployedServer::ControlPlanePort: /usr/share/openstack-tripleo-heat-templates/deployed-server/deployed-neutron-port.yaml # Controller role port resources OS::TripleO::Controller::Ports::ExternalPort: /usr/share/openstack-tripleo-heat-templates/network/ports/deployed_external.yaml OS::TripleO::Controller::Ports::InternalApiPort: /usr/share/openstack-tripleo-heat-templates/network/ports/deployed_internal_api.yaml OS::TripleO::Controller::Ports::StorageMgmtPort: /usr/share/openstack-tripleo-heat-templates/network/ports/deployed_storage_mgmt.yaml OS::TripleO::Controller::Ports::StoragePort: /usr/share/openstack-tripleo-heat-templates/network/ports/deployed_storage.yaml OS::TripleO::Controller::Ports::TenantPort: /usr/share/openstack-tripleo-heat-templates/network/ports/deployed_tenant.yaml # Compute role port resources OS::TripleO::Compute::Ports::InternalApiPort: /usr/share/openstack-tripleo-heat-templates/network/ports/deployed_internal_api.yaml OS::TripleO::Compute::Ports::StoragePort: /usr/share/openstack-tripleo-heat-templates/network/ports/deployed_storage.yaml OS::TripleO::Compute::Ports::TenantPort: /usr/share/openstack-tripleo-heat-templates/network/ports/deployed_tenant.yaml # CephStorage role port resources OS::TripleO::CephStorage::Ports::StorageMgmtPort: /usr/share/openstack-tripleo-heat-templates/network/ports/deployed_storage_mgmt.yaml OS::TripleO::CephStorage::Ports::StoragePort: /usr/share/openstack-tripleo-heat-templates/network/ports/deployed_storage.yaml parameter_defaults: NodePortMap: 1 # Controller node parameters controller-00-rack01: 2 ctlplane: 3 ip_address: 192.168.24.201 ip_address_uri: 192.168.24.201 ip_subnet: 192.168.24.0/24 external: ip_address: 10.0.0.201 ip_address_uri: 10.0.0.201 ip_subnet: 10.0.0.10/24 internal_api: ip_address: 172.16.2.201 ip_address_uri: 172.16.2.201 ip_subnet: 172.16.2.10/24 management: ip_address: 192.168.1.201 ip_address_uri: 192.168.1.201 ip_subnet: 192.168.1.10/24 storage: ip_address: 172.16.1.201 ip_address_uri: 172.16.1.201 ip_subnet: 172.16.1.10/24 storage_mgmt: ip_address: 172.16.3.201 ip_address_uri: 172.16.3.201 ip_subnet: 172.16.3.10/24 tenant: ip_address: 172.16.0.201 ip_address_uri: 172.16.0.201 ip_subnet: 172.16.0.10/24 ... # Compute node parameters compute-00-rack01: ctlplane: ip_address: 192.168.24.11 ip_address_uri: 192.168.24.11 ip_subnet: 192.168.24.0/24 internal_api: ip_address: 172.16.2.11 ip_address_uri: 172.16.2.11 ip_subnet: 172.16.2.10/24 storage: ip_address: 172.16.1.11 ip_address_uri: 172.16.1.11 ip_subnet: 172.16.1.10/24 tenant: ip_address: 172.16.0.11 ip_address_uri: 172.16.0.11 ip_subnet: 172.16.0.10/24 ... # Ceph node parameters ceph-00-rack01: ctlplane: ip_address: 192.168.24.101 ip_address_uri: 192.168.24.101 ip_subnet: 192.168.24.0/24 storage: ip_address: 172.16.1.101 ip_address_uri: 172.16.1.101 ip_subnet: 172.16.1.10/24 storage_mgmt: ip_address: 172.16.3.101 ip_address_uri: 172.16.3.101 ip_subnet: 172.16.3.10/24 ... # Virtual IP address parameters ControlPlaneVipData: fixed_ips: - ip_address: 192.168.24.5 name: control_virtual_ip network: tags: [192.168.24.0/24] subnets: - ip_version: 4 VipPortMap external: ip_address: 10.0.0.100 ip_address_uri: 10.0.0.100 ip_subnet: 10.0.0.100/24 internal_api: ip_address: 172.16.2.100 ip_address_uri: 172.16.2.100 ip_subnet: 172.16.2.100/24 storage: ip_address: 172.16.1.100 ip_address_uri: 172.16.1.100 ip_subnet: 172.16.1.100/24 storage_mgmt: ip_address: 172.16.3.100 ip_address_uri: 172.16.3.100 ip_subnet: 172.16.3.100/24 RedisVirtualFixedIPs: - ip_address: 192.168.24.6 use_neutron: false
- 1
NodePortMapマッピングは、ノード割り当ての名前を定義します。- 2
<node_hostname>の形式に従う、ノードの短いホスト名。- 3
- ノードのネットワーク定義と IP 割り当て。ネットワークには、
ctlplane、external、internal_api、management、storage、storage_mgmt、およびtenantが含まれます。IP 割り当てには、ip_address、ip_address_uri、およびip_subnetが含まれます。-
IPv4:
ip_addressとip_address_uriは同じ値に設定する必要があります。 IPv6:
-
ip_address: 括弧なしの IPv6 アドレスに設定します。 -
ip_address_uri:[2001:0db8:85a3:0000:0000:8a2e:0370:7334]のように、角括弧で囲まれた IPv6 アドレスに設定します。
-
-
IPv4:
11.4.6. 事前にプロビジョニングされたノードへの別ネットワークの使用
デフォルトでは、director はオーバークラウドのコントロールプレーンとしてプロビジョニングネットワークを使用します。ただし、このネットワークが分離されてルーティング不可能な場合には、ノードは設定中に director の Internal API と通信することができません。このような状況では、ノードに別のネットワークを定義して、パブリック API 経由で director と通信するように設定しなければならない場合があります。
このシナリオには、いくつかの要件があります。
- オーバークラウドノードは、「コントロールプレーンのネットワークの設定」 からの基本的なネットワーク設定に対応する必要があります。
- パブリック API エンドポイントを使用できるように director 上で SSL/TLS を有効化する必要があります。詳細は、オーバークラウドのパブリックエンドポイントでの SSL/TLS の有効化 を参照してください。
-
director 向けにアクセス可能な完全修飾ドメイン名 (FQDN) を定義する必要があります。この FQDN は、director にルーティング可能な IP アドレスを解決する必要があります。
undercloud.confファイルのundercloud_public_hostパラメーターを使用して、この FQDN を設定します。
本項に記載する例では、主要なシナリオとは異なる IP アドレスの割り当てを使用します。
表11.11 プロビジョニングネットワークの IP 割り当て
| ノード名 | IP アドレスまたは FQDN |
|---|---|
| director (Internal API) | 192.168.24.1 (プロビジョニングネットワークおよびコントロールプレーン) |
| director (パブリック API) | 10.1.1.1 / director.example.com |
| オーバークラウドの仮想 IP | 192.168.100.1 |
| Controller 0 | 192.168.100.2 |
| Compute 0 | 192.168.100.3 |
以下の項では、オーバークラウドノードに別のネットワークが必要な場合の追加の設定について説明します。
IP アドレスの割り当て
IP の割り当て方法は、「コントロールプレーンのネットワークの設定」に記載の手順と類似しています。ただし、コントロールプレーンはデプロイされたサーバーからルーティングできない場合があるため、NodePortMap、ControlPlaneVipData、および VipPortMap パラメーターを使用して、選択したオーバークラウドノードサブネットから IP アドレス (コントロールプレーンにアクセスするための仮想 IP アドレスを含む) を割り当てることができます。次の例は、「コントロールプレーンのネットワークの設定」 からの deployed-ports.yaml カスタム環境ファイルの修正版です。このネットワークアーキテクチャーに対応します。
parameter_defaults:
NodePortMap:
controller-00-rack01
ctlplane
ip_address: 192.168.100.2
ip_address_uri: 192.168.100.2
ip_subnet: 192.168.100.0/24
...
compute-00-rack01:
ctlplane
ip_address: 192.168.100.3
ip_address_uri: 192.168.100.3
ip_subnet: 192.168.100.0/24
...
ControlPlaneVipData:
fixed_ips:
- ip_address: 192.168.100.1
name: control_virtual_ip
network:
tags: [192.168.100.0/24]
subnets:
- ip_version: 4
VipPortMap:
external:
ip_address: 10.0.0.100
ip_address_uri: 10.0.0.100
ip_subnet: 10.0.0.100/24
....
RedisVirtualFixedIPs:1
- ip_address: 192.168.100.10
use_neutron: false- 1
RedisVipPortリソースは、network/ports/noop.yamlにマッピングされます。デフォルトの Redis 仮想 IP アドレスがコントロールプレーンから割り当てられているので、このマッピングが必要です。このような場合には、noopを使用して、このコントロールプレーンマッピングを無効化します。
11.4.7. 事前にプロビジョニングされたノードのホスト名のマッピング
事前にプロビジョニングされたノードを設定する場合には、heat ベースのホスト名をそれらの実際のホスト名にマッピングして、ansible-playbook が解決されたホストに到達できるようにする必要があります。それらの値は、HostnameMap を使用してマッピングします。
手順
環境ファイル (たとえば
hostname-map.yaml) を作成して、HostnameMapパラメーターとホスト名のマッピングを指定します。以下の構文を使用してください。parameter_defaults: HostnameMap: [HEAT HOSTNAME]: [ACTUAL HOSTNAME] [HEAT HOSTNAME]: [ACTUAL HOSTNAME][HEAT HOSTNAME]は通常[STACK NAME]-[ROLE]-[INDEX]の表記法に従います。parameter_defaults: HostnameMap: overcloud-controller-0: controller-00-rack01 overcloud-controller-1: controller-01-rack02 overcloud-controller-2: controller-02-rack03 overcloud-novacompute-0: compute-00-rack01 overcloud-novacompute-1: compute-01-rack01 overcloud-novacompute-2: compute-02-rack01-
hostname-map.yamlファイルを保存します。
11.4.8. 事前にプロビジョニングされたノード向けの Ceph Storage の設定
すでにデプロイされているノードに Ceph を設定するには、アンダークラウドホストで以下の手順を実施します。
手順
アンダークラウドホストで環境変数
OVERCLOUD_HOSTSを作成し、変数に Ceph クライアントとして使用するオーバークラウドホストの IP アドレスのスペース区切りリストを設定します。export OVERCLOUD_HOSTS="192.168.1.8 192.168.1.42"
デフォルトのオーバークラウドプランの名前は
overcloudです。別の名前を使用する場合は、環境変数OVERCLOUD_PLANを作成してカスタムの名前を保存します。export OVERCLOUD_PLAN="<custom-stack-name>"
-
<custom-stack-name>を実際のスタックの名前に置き換えます。
-
enable-ssh-admin.shスクリプトを実行して、Ansible が Ceph クライアントの設定に使用することのできるオーバークラウドノードのユーザーを設定します。bash /usr/share/openstack-tripleo-heat-templates/deployed-server/scripts/enable-ssh-admin.sh
openstack overcloud deploy コマンドを実行すると、Ansible は OVERCLOUD_HOSTS 変数で Ceph クライアントとして定義したホストを設定します。
11.4.9. 事前にプロビジョニングされたノードを使用したオーバークラウドの作成
オーバークラウドのデプロイメントには、標準の CLI の方法を使用します。事前にプロビジョニングされたノードの場合は、デプロイメントコマンドに追加のオプションと、コア heat テンプレートコレクションからの環境ファイルが必要です。
-
--disable-validations: このオプションを使用して、事前にプロビジョニングされたインフラストラクチャーで使用しないサービスに対する基本的な CLI 検証を無効にします。これらの検証を無効にしないと、デプロイメントに失敗します。 -
environments/deployed-server-environment.yaml: 事前にプロビジョニングされたインフラストラクチャーを作成、設定するには、この環境ファイルを追加します。この環境ファイルは、OS::Nova::ServerリソースをOS::Heat::DeployedServerリソースに置き換えます。
以下のコマンドは、事前にプロビジョニングされたアーキテクチャー固有の環境ファイルを使用したオーバークラウドデプロイメントコマンドの例です。
$ source ~/stackrc (undercloud)$ openstack overcloud deploy \ --disable-validations \ -e /usr/share/openstack-tripleo-heat-templates/environments/deployed-server-environment.yaml \ -e /home/stack/templates/deployed-ports.yaml \ -e /home/stack/templates/hostname-map.yaml \ --overcloud-ssh-user stack \ --overcloud-ssh-key ~/.ssh/id_rsa \ <OTHER OPTIONS>
--overcloud-ssh-user および --overcloud-ssh-key オプションは、設定ステージ中に各オーバークラウドノードに SSH 接続して、初期 tripleo-admin ユーザーを作成し、SSH キーを /home/tripleo-admin/.ssh/authorized_keys に挿入するのに使用します。SSH キーを挿入するには、--overcloud-ssh-user および --overcloud-ssh-key (~/.ssh/id_rsa がデフォルト) を使用して、初回 SSH 接続用の認証情報を指定します。--overcloud-ssh-key オプションで指定する秘密鍵の公開を制限するために、director は Heat などのどの API サービスにもこの鍵を渡さず、director の openstack overcloud deploy コマンドだけがこの鍵を使用して tripleo-admin ユーザーのアクセスを有効化します。
11.4.10. オーバークラウドへのアクセス
director は、アンダークラウドからのオーバークラウドの操作に必要な認証情報を含めて認証情報ファイルを生成します。director は、このファイル overcloudrc を stack ユーザーのホームディレクトリーに保存します。
手順
source コマンドで
overcloudrcファイルを読み込みます。(undercloud)$ source ~/overcloudrc
オーバークラウドにアクセスしていることを示すコマンドプロンプトに切り替わります。
(overcloud)$
アンダークラウドの操作に戻るには、
stackrcファイルを読み込みます。(overcloud)$ source ~/stackrc (undercloud)$
アンダークラウドにアクセスしていることを示すコマンドプロンプトに切り替わります。
(undercloud)$
11.4.11. 事前にプロビジョニングされたノードのスケーリング
事前にプロビジョニングされたノードをスケーリングするプロセスは、19章オーバークラウドノードのスケーリング に記載する標準のスケーリング手順と類似しています。ただし、事前にプロビジョニングされたノードを新たに追加するプロセスは異なります。これは、事前にプロビジョニングされたノードが OpenStack Bare Metal (ironic) および OpenStack Compute (nova) からの標準の登録および管理プロセスを使用しないためです。
事前にプロビジョニングされたノードのスケールアップ
事前にプロビジョニングされたノードでオーバークラウドをスケールアップする際には、各ノードで director のノード数に対応するようにオーケストレーションエージェントを設定する必要があります。
オーバークラウドノードをスケールアップするには、以下の操作を実施します。
- 「事前にプロビジョニングされたノードの要件」 の説明に従って、事前にプロビジョニングされたノードを新たに準備します。
- ノードをスケールアップします。詳細は、19章オーバークラウドノードのスケーリング を参照してください。
- デプロイメントコマンドを実行した後に、director が新しいノードリソースを作成して設定を開始するまで待ちます。
事前にプロビジョニングされたノードのスケールダウン
事前にプロビジョニングされたノードを持つオーバークラウドをスケールダウンするには、19章オーバークラウドノードのスケーリング に記載するスケールダウン手順に従います。
スケールダウン操作では、OSP でプロビジョニングされたノードと事前にプロビジョニングされたノードの両方にホスト名を使用できます。OSP プロビジョニングされたノードに UUID を使用することもできます。ただし、事前にプロビジョニングされたノードには UUID がないため、常にホスト名を使用します。ホスト名または UUID 値を openstack overcloud node delete コマンドに渡します。
手順
削除するノードの名前を特定します。
$ openstack stack resource list overcloud -n5 --filter type=OS::TripleO::ComputeDeployedServerServer
対応するノード名を
stack_name列からopenstack overcloud node deleteコマンドに渡します。$ openstack overcloud node delete --stack <overcloud> <stack>
-
<overcloud>は、オーバークラウドスタックの名前または UUID に置き換えてください。 -
<stack_name>を削除するノードの名前に置き換えます。openstack overcloud node deleteコマンドに複数のノード名を含めることができます。
-
openstack overcloud node deleteコマンドが完全に終了したことを確認します。$ openstack stack list
削除の操作が完了すると、
オーバークラウドスタックのステータスはUPDATE_COMPLETEと表示されます。
スタックからオーバークラウドノードを削除したら、それらのノードの電源をオフにします。標準のデプロイメントでは、director のベアメタルサービスがこの機能を制御します。ただし、事前にプロビジョニングされたノードでは、これらのノードを手動でシャットダウンするか、物理システムごとに電源管理制御を使用する必要があります。スタックからノードを削除した後にノードの電源をオフにしないと、稼動状態が続き、オーバークラウド環境の一部として再接続されてしまう可能性があります。
削除したノードの電源をオフにした後に、それらのノードをベースオペレーティングシステムの設定に再プロビジョニングし、意図せずにオーバークラウドに加わらないようにします。
オーバークラウドから以前に削除したノードは、再プロビジョニングしてベースオペレーティングシステムを新規インストールするまでは、再利用しないようにしてください。スケールダウンのプロセスでは、オーバークラウドスタックからノードを削除するだけで、パッケージはアンインストールされません。
事前にプロビジョニングされたオーバークラウドの削除
事前にプロビジョニングされたノードを使用するオーバークラウド全体を削除するには、「オーバークラウドスタックの削除」 で標準のオーバークラウド削除手順を参照してください。オーバークラウドを削除した後に、全ノードの電源をオフにしてからベースオペレーティングシステムの設定に再プロビジョニングします。
オーバークラウドから以前に削除したノードは、再プロビジョニングしてベースオペレーティングシステムを新規インストールするまでは、再利用しないようにしてください。削除のプロセスでは、オーバークラウドスタックを削除するだけで、パッケージはアンインストールされません。
第12章 Ansible ベースのオーバークラウド登録
director は、Ansible ベースのメソッドを使用して、オーバークラウドノードを Red Hat カスタマーポータルまたは Red Hat Satellite Server に登録します。
以前のバージョンの Red Hat OpenStack Platform の rhel-registration メソッドを使用していた場合は、それを無効にして Ansible ベースのメソッドに切り替える必要があります。詳しい情報は、「rhsm コンポーザブルサービスへの切り替え」 および 「rhel-registration から rhsm へのマッピング」 を参照してください。
director ベースの登録メソッドに加えて、デプロイメント後に手動で登録することもできます。詳細は、「手動による Ansible ベースの登録の実行」 を参照してください。
12.1. Red Hat Subscription Manager (RHSM) コンポーザブルサービス
rhsm コンポーザブルサービスを使用して、Ansible を介してオーバークラウドノードを登録することができます。デフォルトの roles_data ファイルの各ロールには、OS::TripleO::Services::Rhsm リソースが含まれており、これはデフォルトで無効になっています。サービスを有効にするには、このリソースを rhsm コンポーザブルサービスのファイルに登録します。
resource_registry: OS::TripleO::Services::Rhsm: /usr/share/openstack-tripleo-heat-templates/deployment/rhsm/rhsm-baremetal-ansible.yaml
rhsm コンポーザブルサービスは RhsmVars パラメーターを受け入れます。これを使用して、登録に必要な複数のサブパラメーターを定義することができます。
parameter_defaults:
RhsmVars:
rhsm_repos:
- rhel-9-for-x86_64-baseos-eus-rpms
- rhel-9-for-x86_64-appstream-eus-rpms
- rhel-9-for-x86_64-highavailability-eus-rpms
…
rhsm_username: "myusername"
rhsm_password: "p@55w0rd!"
rhsm_org_id: "1234567"
rhsm_release: 9.0
RhsmVars パラメーターをロール固有のパラメーター (例: ControllerParameters) と共に使用することにより、異なるノードタイプ用の特定のリポジトリーを有効化する場合に柔軟性を提供することもできます。
12.2. RhsmVars サブパラメーター
rhsm コンポーザブルサービスを設定する際に、以下のサブパラメーターを RhsmVars パラメーターの一部として使用します。利用可能な Ansible パラメーターについての詳細は、ロールに関するドキュメント を参照してください。
rhsm | 説明 |
|---|---|
|
|
登録の方法を選択します。 |
|
|
登録に使用する組織。この ID を特定するには、アンダークラウドノードから |
|
|
使用するサブスクリプションプール ID。サブスクリプションを自動でアタッチしない場合は、このパラメーターを使用します。この ID を特定するには、アンダークラウドノードから |
|
| 登録に使用するアクティベーションキー |
|
|
このパラメーターを使用して、互換性のあるサブスクリプションを自動的にこのシステムにアタッチします。この機能を有効にするには、値を |
|
| コンテンツを取得するためのベース URL。デフォルトの URL は Red Hat コンテンツ配信ネットワークです。Satellite サーバーを使用している場合は、この値を Satellite サーバーコンテンツリポジトリーのベース URL に変更します。 |
|
| 登録用のサブスクリプション管理サービスのホスト名。デフォルトは Red Hat Subscription Management のホスト名です。Satellite サーバーを使用している場合は、この値を Satellite サーバーのホスト名に変更します。 |
|
| 有効にするリポジトリーの一覧 |
|
| 登録用のユーザー名。可能な場合には、登録にアクティベーションキーを使用します。 |
|
| 登録用のパスワード。可能な場合には、登録用のアクティベーションキーを使用します。 |
|
| リポジトリー固定用の Red Hat Enterprise Linux リリース。Red Hat OpenStack Platform の場合、このパラメーターは 9.0 に設定されます。 |
|
|
HTTP プロキシーのホスト名。たとえば、 |
|
|
HTTP プロキシー通信用のポート。たとえば、 |
|
| HTTP プロキシーにアクセスするためのユーザー名 |
|
| HTTP プロキシーにアクセスするためのパスワード |
rhsm_method が portal に設定されている場合に限り、rhsm_activation_key と rhsm_repos を使用できます。rhsm_method を satellite に設定すると、rhsm_activation_key または rhsm_repos のいずれかを使用できます。
12.3. rhsm コンポーザブルサービスを使用したオーバークラウドの登録
rhsm コンポーザブルサービスを有効にして設定する環境ファイルを作成します。director はこの環境ファイルを使用して、ノードを登録し、サブスクライブします。
手順
-
設定を保存するための環境ファイル (
templates/rhsm.yml) を作成します。 環境ファイルに設定を追加します。以下に例を示します。
resource_registry: OS::TripleO::Services::Rhsm: /usr/share/openstack-tripleo-heat-templates/deployment/rhsm/rhsm-baremetal-ansible.yaml parameter_defaults: RhsmVars: rhsm_repos: - rhel-9-for-x86_64-baseos-eus-rpms - rhel-9-for-x86_64-appstream-eus-rpms - rhel-9-for-x86_64-highavailability-eus-rpms … rhsm_username: "myusername" rhsm_password: "p@55w0rd!" rhsm_org_id: "1234567" rhsm_pool_ids: "1a85f9223e3d5e43013e3d6e8ff506fd" rhsm_method: "portal" rhsm_release: 9.0-
resource_registryセクションは、各ロールで利用可能なOS::TripleO::Services::Rhsmリソースにrhsmコンポーザブルサービスを関連付けます。 -
RhsmVarsの変数は、Red Hat の登録を設定するためにパラメーターを Ansible に渡します。
-
- 環境ファイルを保存します。
12.4. 異なるロールに対する rhsm コンポーザブルサービスの適用
rhsm コンポーザブルサービスをロールごとに適用することができます。たとえば、コントローラーノード、コンピュートノード、および Ceph Storage ノードに、異なる設定セットを適用することができます。
手順
-
設定を保存するための環境ファイル (
templates/rhsm.yml) を作成します。 環境ファイルに設定を追加します。以下に例を示します。
resource_registry: OS::TripleO::Services::Rhsm: /usr/share/openstack-tripleo-heat-templates/deployment/rhsm/rhsm-baremetal-ansible.yaml parameter_defaults: ControllerParameters: RhsmVars: rhsm_repos: - rhel-9-for-x86_64-baseos-eus-rpms - rhel-9-for-x86_64-appstream-eus-rpms - rhel-9-for-x86_64-highavailability-eus-rpms - openstack-17-for-rhel-9-x86_64-rpms - fast-datapath-for-rhel-9-x86_64-rpms - rhceph-5-tools-for-rhel-9-x86_64-rpms rhsm_username: "myusername" rhsm_password: "p@55w0rd!" rhsm_org_id: "1234567" rhsm_pool_ids: "55d251f1490556f3e75aa37e89e10ce5" rhsm_method: "portal" rhsm_release: 9.0 ComputeParameters: RhsmVars: rhsm_repos: - rhel-9-for-x86_64-baseos-eus-rpms - rhel-9-for-x86_64-appstream-eus-rpms - rhel-9-for-x86_64-highavailability-eus-rpms - openstack-17-for-rhel-9-x86_64-rpms - rhceph-5-tools-for-rhel-9-x86_64-rpms - fast-datapath-for-rhel-9-x86_64-rpms rhsm_username: "myusername" rhsm_password: "p@55w0rd!" rhsm_org_id: "1234567" rhsm_pool_ids: "55d251f1490556f3e75aa37e89e10ce5" rhsm_method: "portal" rhsm_release: 9.0 CephStorageParameters: RhsmVars: rhsm_repos: - rhel-9-for-x86_64-baseos-rpms - rhel-9-for-x86_64-appstream-rpms - rhel-9-for-x86_64-highavailability-rpms - openstack-17-deployment-tools-for-rhel-9-x86_64-rpms rhsm_username: "myusername" rhsm_password: "p@55w0rd!" rhsm_org_id: "1234567" rhsm_pool_ids: "68790a7aa2dc9dc50a9bc39fabc55e0d" rhsm_method: "portal" rhsm_release: 9.0resource_registryは、各ロールで利用可能なOS::TripleO::Services::Rhsmリソースにrhsmコンポーザブルサービスを関連付けます。ControllerParameters、ComputeParameters、およびCephStorageParametersパラメーターはいずれも、個別のRhsmVarsパラメーターを使用してサブスクリプションの情報をそれぞれのロールに渡します。注記Red Hat Ceph Storage のサブスクリプションおよび Ceph Storage 固有のリポジトリーを使用するように、
CephStorageParametersパラメーター内のRhsmVarsパラメーターを設定します。rhsm_reposパラメーターに、コントローラーノードおよびコンピュートノードに必要な Extended Update Support (EUS) リポジトリーではなく、標準の Red Hat Enterprise Linux リポジトリーが含まれるようにします。- 環境ファイルを保存します。
12.5. Red Hat Satellite Server へのオーバークラウドの登録
ノードを Red Hat カスタマーポータルではなく Red Hat Satellite に登録するには、rhsm コンポーザブルサービスを有効にして設定する環境ファイルを作成します。
手順
-
設定を保存するための環境ファイル (
templates/rhsm.yml) を作成します。 環境ファイルに設定を追加します。以下に例を示します。
resource_registry: OS::TripleO::Services::Rhsm: /usr/share/openstack-tripleo-heat-templates/deployment/rhsm/rhsm-baremetal-ansible.yaml parameter_defaults: RhsmVars: rhsm_activation_key: "myactivationkey" rhsm_method: "satellite" rhsm_org_id: "ACME" rhsm_server_hostname: "satellite.example.com" rhsm_baseurl: "https://satellite.example.com/pulp/repos" rhsm_release: 9.0resource_registryは、各ロールで利用可能なOS::TripleO::Services::Rhsmリソースにrhsmコンポーザブルサービスを関連付けます。RhsmVarsの変数は、Red Hat の登録を設定するためにパラメーターを Ansible に渡します。- 環境ファイルを保存します。
12.6. rhsm コンポーザブルサービスへの切り替え
従来の rhel-registration メソッドは、bash スクリプトを実行してオーバークラウドの登録を処理します。このメソッド用のスクリプトと環境ファイルは、/usr/share/openstack-tripleo-heat-templates/extraconfig/pre_deploy/rhel-registration/ のコア Heat テンプレートコレクションにあります。
rhel-registration メソッドを rhsm コンポーザブルサービスに切り替えるには、以下の手順を実施します。
手順
rhel-registration環境ファイルは、今後のデプロイメント操作から除外します。通常は、以下のファイルを除外します。-
rhel-registration/environment-rhel-registration.yaml -
rhel-registration/rhel-registration-resource-registry.yaml
-
カスタムの
roles_dataファイルを使用する場合には、roles_dataファイルの各ロールに必ずOS::TripleO::Services::Rhsmコンポーザブルサービスを含めてください。以下に例を示します。- name: Controller description: | Controller role that has all the controller services loaded and handles Database, Messaging and Network functions. CountDefault: 1 ... ServicesDefault: ... - OS::TripleO::Services::Rhsm ...-
rhsmコンポーザブルサービスのパラメーター用の環境ファイルを今後のデプロイメント操作に追加します。
このメソッドは、rhel-registration パラメーターを rhsm サービスのパラメーターに置き換えて、サービスを有効化する Heat リソースを変更します。
resource_registry: OS::TripleO::NodeExtraConfig: rhel-registration.yaml
必要に応じて、以下を行ってください。
resource_registry: OS::TripleO::Services::Rhsm: /usr/share/openstack-tripleo-heat-templates/deployment/rhsm/rhsm-baremetal-ansible.yaml
デプロイメントに /usr/share/openstack-tripleo-heat-templates/environments/rhsm.yaml 環境ファイルを追加して、サービスを有効にすることもできます。
12.7. rhel-registration から rhsm へのマッピング
rhel-registration メソッドから rhsm メソッドへの情報の移行を容易に行うには、以下の表を使用してパラメーターとその値をマッピングします。
rhel-registration | rhsm / RhsmVars |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
12.8. rhsm コンポーザブルサービスを使用したオーバークラウドのデプロイ
Ansible がオーバークラウドノードの登録プロセスを制御するように、rhsm コンポーザブルサービスを使用してオーバークラウドをデプロイします。
手順
openstack overcloud deployコマンドにrhsm.yml環境ファイルを追加します。openstack overcloud deploy \ <other cli args> \ -e ~/templates/rhsm.yamlこれにより、Ansible のオーバークラウドの設定と、Ansible ベースの登録が有効化されます。
- オーバークラウドのデプロイメントが完了するまで待ちます。
オーバークラウドノードのサブスクリプション情報を確認します。たとえば、コントローラーノードにログインして、以下のコマンドを実行します。
$ sudo subscription-manager status $ sudo subscription-manager list --consumed
12.9. 手動による Ansible ベースの登録の実行
director ノードで動的インベントリースクリプトを使用して、デプロイしたオーバークラウドで、手動による Ansible ベースの登録を行うことができます。このスクリプトを使用して、ホストグループとしてノードロールを定義します。続いて ansible-playbook を使用して定義したノードロールに対して Playbook を実行します。コントローラーノードを手動で登録するには、以下の例の Playbook を使用します。
手順
ノードを登録する
redhat_subscriptionモジュールを使用して Playbook を作成します。たとえば、以下の Playbook はコントローラーノードに適用されます。--- - name: Register Controller nodes hosts: Controller become: yes vars: repos: - rhel-9-for-x86_64-baseos-eus-rpms - rhel-9-for-x86_64-appstream-eus-rpms - rhel-9-for-x86_64-highavailability-eus-rpms - openstack-17-for-rhel-9-x86_64-rpms - fast-datapath-for-rhel-9-x86_64-rpms tasks: - name: Register system redhat_subscription: username: myusername password: p@55w0rd! org_id: 1234567 release: 9.0 pool_ids: 1a85f9223e3d5e43013e3d6e8ff506fd - name: Disable all repos command: "subscription-manager repos --disable *" - name: Enable Controller node repos command: "subscription-manager repos --enable {{ item }}" with_items: "{{ repos }}"このプレイには 3 つのタスクが含まれます。
- ノードを登録する。
- 自動的に有効化されるリポジトリーをすべて無効にする。
-
コントローラーノードに関連するリポジトリーだけを有効にする。リポジトリーは
repos変数でリストされます。
オーバークラウドのデプロイ後には、以下のコマンドを実行して、Ansible がオーバークラウドに対して Playbook (
ansible-osp-registration.yml) を実行することができます。$ ansible-playbook -i /usr/bin/tripleo-ansible-inventory ansible-osp-registration.yml
このコマンドにより、以下のアクションが行われます。
- 動的インベントリースクリプトを実行し、ホストとそのグループの一覧を取得する。
-
Playbook の
hostsパラメーターで定義されているグループ (この場合はコントローラーグループ) 内のノードに、その Playbook のタスクを適用する。
第13章 NFS ストレージの設定
共有 NFS ストレージを使用するようにオーバークラウドを設定できます。
13.1. サポートされる設定および制限
サポートされる NFS ストレージ
- Red Hat では、認定済みのストレージバックエンドおよびドライバーを使用することを推奨します。Red Hat では、汎用 NFS バックエンドの NFS ストレージを使用することを推奨していません。認定済みのストレージバックエンドおよびドライバーと比較すると、その機能に制限があるためです。たとえば、汎用 NFS バックエンドは、ボリュームの暗号化やボリュームのマルチアタッチなどの機能をサポートしません。サポート対象のドライバーについての情報は、Red Hat Ecosystem Catalog を参照してください。
- Block Storage (cinder) サービスおよび Compute (nova) サービスには、NFS バージョン 4.0 以降を使用する必要があります。Red Hat OpenStack Platform (RHOSP) は、以前のバージョンの NFS をサポートしません。
サポートされていない NFS 設定
RHOSP は、通常のボリューム操作を妨げるため、NetApp 機能の NAS セキュアをサポートしていません。Director はデフォルトでこの機能を無効にします。したがって、NFS バックエンドまたは NetApp NFS Block Storage バックエンドが NAS セキュアをサポートするかどうかを制御する次の heat パラメーターは編集しないでください。
-
CinderNetappNasSecureFileOperations -
CinderNetappNasSecureFilePermissions -
CinderNasSecureFileOperations -
CinderNasSecureFilePermissions
-
NFS 共有を使用する場合の制限
- バックエンドが NFS 共有の場合、スワップディスクを持つインスタンスはサイズ変更または再構築できません。
13.2. NFS ストレージの設定
共有 NFS ストレージを使用するようにオーバークラウドを設定できます。
手順
-
nfs_storage.yamlなどの NFS ストレージを設定するための環境ファイルを作成します。 次のパラメーターを新しい環境ファイルに追加して、NFS ストレージを設定します。
parameter_defaults: CinderEnableIscsiBackend: false CinderEnableNfsBackend: true GlanceBackend: file CinderNfsServers: 192.0.2.230:/cinder GlanceNfsEnabled: true GlanceNfsShare: 192.0.2.230:/glance
注記CinderNfsMountOptionsパラメーターおよびGlanceNfsOptionsパラメーターは設定しないでください。これらのパラメーターのデフォルト値は、ほとんどの Red Hat OpenStack Platform (RHOSP) 環境に適した NFS マウントオプションを有効にするためです。environment/storage/glance-nfs.yamlファイルでGlanceNfsOptionsパラメーターの値を確認できます。同じ NFS サーバーを共有するように複数のサービスを設定する際に問題が発生した場合は、Red Hat サポートにお問い合わせください。その他の環境ファイルと共に NFS ストレージ環境ファイルをスタックに追加して、オーバークラウドをデプロイします。
(undercloud)$ openstack overcloud deploy --templates \ -e [your environment files] \ -e /home/stack/templates/nfs_storage.yaml
13.3. 変換用の外部 NFS 共有の設定
Block Storage サービス (cinder) がオーバークラウドのコントローラーノードでイメージ形式の変換を実行し、スペースが限られている場合は、大きな Image Service (glance) のイメージを変換すると、ノードのルートディスクスペースが完全に使用される可能性があります。変換に外部 NFS 共有を使用して、ノードのスペースが完全にいっぱいになるのを防ぐことができます。
外部 NFS 共有設定を制御する 2 つの director heat パラメーターがあります。
-
CinderImageConversionNfsShare -
CinderImageConversionNfsOptions
手順
アンダークラウドに
stackユーザーとしてログインし、stackrc認証情報ファイルを読み込みます。$ source ~/stackrc
新規または既存のストレージ関連の環境ファイルに、外部 NFS 共有に関する情報を追加します。
parameter_defaults: CinderImageConversionNfsShare: 192.168.10.1:/convert
注記NFS マウントオプションを制御する
CinderImageConversionNfsOptionsパラメーターのデフォルト値は、ほとんどの環境で十分です。ご自分の環境に該当するその他の環境ファイルと共に、新しい設定が含まれる環境ファイルを openstack overcloud deploy コマンドに追加します。
$ openstack overcloud deploy \ --templates \ … -e <existing_overcloud_environment_files> \ -e <new_environment_file> \ …
-
<existing_overcloud_environment_files>を既存のデプロイメントに含まれる環境ファイルの一覧に置き換えます。 -
<new_environment_file>を、NFS 共有設定を含む新規または編集済みの環境ファイルに置き換えます。
-
第14章 オーバークラウドのインストール後タスクの実施
本章では、オーバークラウドを作成したすぐ後に実施するタスクについて説明します。これらのタスクにより、オーバークラウドを使用可能な状態にすることができます。
14.1. オーバークラウドデプロイメントステータスの確認
オーバークラウドのデプロイメントステータスを確認するには、openstack overcloud status コマンドを使用します。このコマンドにより、すべてのデプロイメントステップの結果が返されます。
手順
stackrcファイルを取得します。$ source ~/stackrc
デプロイメントステータスの確認コマンドを実行します。
$ openstack overcloud status
このコマンドの出力に、オーバークラウドのステータスが表示されます。
+-----------+---------------------+---------------------+-------------------+ | Plan Name | Created | Updated | Deployment Status | +-----------+---------------------+---------------------+-------------------+ | overcloud | 2018-05-03 21:24:50 | 2018-05-03 21:27:59 | DEPLOY_SUCCESS | +-----------+---------------------+---------------------+-------------------+
実際のオーバークラウドに別の名前が使用されている場合には、
--stack引数を使用してその名前のオーバークラウドを選択します。$ openstack overcloud status --stack <overcloud_name>
-
<overcloud_name>は、実際のオーバークラウドの名前に置き換えてください。
-
14.2. 基本的なオーバークラウドフレーバーの作成
本ガイドの検証ステップは、インストール環境にフレーバーが含まれていることを前提としてます。まだ 1 つのフレーバーも作成していない場合には、以下の手順を実施して、さまざまなストレージおよび処理能力に対応する基本的なデフォルトフレーバーセットを作成してください。
手順
source コマンドで
overcloudrcファイルを読み込みます。$ source ~/overcloudrc
openstack flavor createコマンドを実行してフレーバーを作成します。以下のオプションを使用して、各フレーバーのハードウェア要件を指定します。- --disk
- 仮想マシンのボリュームのハードディスク容量を定義します。
- --ram
- 仮想マシンに必要な RAM を定義します。
- --vcpus
- 仮想マシンの仮想 CPU 数を定義します。
デフォルトのオーバークラウドフレーバー作成の例を以下に示します。
$ openstack flavor create m1.tiny --ram 512 --disk 0 --vcpus 1 $ openstack flavor create m1.smaller --ram 1024 --disk 0 --vcpus 1 $ openstack flavor create m1.small --ram 2048 --disk 10 --vcpus 1 $ openstack flavor create m1.medium --ram 3072 --disk 10 --vcpus 2 $ openstack flavor create m1.large --ram 8192 --disk 10 --vcpus 4 $ openstack flavor create m1.xlarge --ram 8192 --disk 10 --vcpus 8
openstack flavor create コマンドについての詳しい情報は、$ openstack flavor create --help で確認してください。
14.3. デフォルトの Tenant ネットワークの作成
仮想マシンが内部で通信できるように、オーバークラウドにはデフォルトの Tenant ネットワークが必要です。
手順
source コマンドで
overcloudrcファイルを読み込みます。$ source ~/overcloudrc
デフォルトの Tenant ネットワークを作成します。
(overcloud) $ openstack network create default
ネットワーク上にサブネットを作成します。
(overcloud) $ openstack subnet create default --network default --gateway 172.20.1.1 --subnet-range 172.20.0.0/16
作成したネットワークを確認します。
(overcloud) $ openstack network list +-----------------------+-------------+--------------------------------------+ | id | name | subnets | +-----------------------+-------------+--------------------------------------+ | 95fadaa1-5dda-4777... | default | 7e060813-35c5-462c-a56a-1c6f8f4f332f | +-----------------------+-------------+--------------------------------------+
これらのコマンドにより、default という名前の基本的な Networking サービス (neutron) ネットワークが作成されます。オーバークラウドは内部 DHCP メカニズムを使用して、このネットワークから仮想マシンに IP アドレスを自動的に割り当てます。
14.4. デフォルトの Floating IP ネットワークの作成
オーバークラウドの外部から仮想マシンにアクセスするためには、仮想マシンに Floating IP アドレスを提供するExternal ネットワークを設定する必要があります。
ここでは、2 つの手順例を示します。実際の環境に最も適した例を使用してください。
- ネイティブ VLAN (フラットネットワーク)
- 非ネイティブ VLAN (VLAN ネットワーク)
これらの例の両方で、public という名前のネットワークを作成します。オーバークラウドでは、デフォルトの Floating IP プールにこの特定の名前が必要です。この名前は、「オーバークラウドの検証」 の検証テストでも重要となります。
デフォルトでは、OpenStack Networking (neutron) は、datacentre という物理ネットワーク名をホストノード上の br-ex ブリッジにマッピングします。public オーバークラウドネットワークを物理ネットワーク datacentre に接続し、これにより br-ex ブリッジを通じてゲートウェイが提供されます。
前提条件
- Floating IP ネットワーク向けの専用インターフェイスまたはネイティブ VLAN
手順
source コマンドで
overcloudrcファイルを読み込みます。$ source ~/overcloudrc
publicネットワークを作成します。ネイティブ VLAN 接続用に
flatネットワークを作成します。(overcloud) $ openstack network create public --external --provider-network-type flat --provider-physical-network datacentre
非ネイティブ VLAN 接続用に
vlanネットワークを作成します。(overcloud) $ openstack network create public --external --provider-network-type vlan --provider-physical-network datacentre --provider-segment 201
--provider-segmentオプションを使用して、使用する VLAN を定義します。この例では、VLAN は201です。
Floating IP アドレスの割り当てプールを使用してサブネットを作成します。以下の例では、IP 範囲は
10.1.1.51から10.1.1.250までです。(overcloud) $ openstack subnet create public --network public --dhcp --allocation-pool start=10.1.1.51,end=10.1.1.250 --gateway 10.1.1.1 --subnet-range 10.1.1.0/24
この範囲が、External ネットワークの他の IP アドレスと競合しないようにしてください。
14.5. デフォルトのプロバイダーネットワークの作成
プロバイダーネットワークは別の種別の External ネットワーク接続で、トラフィックをプライベート Tenant ネットワークから External インフラストラクチャーネットワークにルーティングします。プロバイダーネットワークは Floating IP ネットワークと類似していますが、プライベートネットワークをプロバイダーネットワークに接続するのに、論理ルーターが使用されます。
ここでは、2 つの手順例を示します。実際の環境に最も適した例を使用してください。
- ネイティブ VLAN (フラットネットワーク)
- 非ネイティブ VLAN (VLAN ネットワーク)
デフォルトでは、OpenStack Networking (neutron) は、datacentre という物理ネットワーク名をホストノード上の br-ex ブリッジにマッピングします。public オーバークラウドネットワークを物理ネットワーク datacentre に接続し、これにより br-ex ブリッジを通じてゲートウェイが提供されます。
手順
source コマンドで
overcloudrcファイルを読み込みます。$ source ~/overcloudrc
providerネットワークを作成します。ネイティブ VLAN 接続用に
flatネットワークを作成します。(overcloud) $ openstack network create provider --external --provider-network-type flat --provider-physical-network datacentre --share
非ネイティブ VLAN 接続用に
vlanネットワークを作成します。(overcloud) $ openstack network create provider --external --provider-network-type vlan --provider-physical-network datacentre --provider-segment 201 --share
--provider-segmentオプションを使用して、使用する VLAN を定義します。この例では、VLAN は201です。
例に示すこれらのコマンドにより、共有ネットワークが作成されます。テナントだけが新しいネットワークにアクセスするように、
--shareを指定する代わりにテナントを指定することも可能です。プロバイダーネットワークを外部としてマークした場合には、そのネットワークでポートを作成できるのはオペレーターのみとなります。
providerネットワークにサブネットを追加して、DHCP サービスを提供します。(overcloud) $ openstack subnet create provider-subnet --network provider --dhcp --allocation-pool start=10.9.101.50,end=10.9.101.100 --gateway 10.9.101.254 --subnet-range 10.9.101.0/24
他のネットワークがプロバイダーネットワークを通じてトラフィックをルーティングできるように、ルーターを作成します。
(overcloud) $ openstack router create external
ルーターの外部ゲートウェイを
providerネットワークに設定します。(overcloud) $ openstack router set --external-gateway provider external
このルーターに他のネットワークを接続します。たとえば、以下のコマンドを実行してサブネット
subnet1をルーターに割り当てます。(overcloud) $ openstack router add subnet external subnet1
このコマンドにより、
subnet1がルーティングテーブルに追加され、subnet1を使用する仮想マシンからのトラフィックをプロバイダーネットワークにルーティングできるようになります。
14.6. 新たなブリッジマッピングの作成
デプロイメント時に追加のブリッジをマッピングすれば、Floating IP ネットワークは br-ex だけでなく任意のブリッジを使用することができます。
手順
br-floatingという新規ブリッジをfloatingという物理ネットワークにマッピングするには、環境ファイルにNeutronBridgeMappingsパラメーターを追加します。parameter_defaults: NeutronBridgeMappings: "datacentre:br-ex,floating:br-floating"
この手法により、オーバークラウドの作成後に独立した External ネットワークを作成することができます。たとえば、
floating物理ネットワークにマッピングする Floating IP ネットワークを作成するには、以下のコマンドを実行します。$ source ~/overcloudrc (overcloud) $ openstack network create public --external --provider-physical-network floating --provider-network-type vlan --provider-segment 105 (overcloud) $ openstack subnet create public --network public --dhcp --allocation-pool start=10.1.2.51,end=10.1.2.250 --gateway 10.1.2.1 --subnet-range 10.1.2.0/24
14.7. オーバークラウドの検証
オーバークラウドは、OpenStack Integration Test Suite (tempest) ツールセットを使用して、一連の統合テストを行います。本項では、統合テストを実施するための準備について説明します。OpenStack Integration Test Suite の使用方法についての詳しい説明は、OpenStack Integration Test Suite ガイド を参照してください。
Integration Test Suite では、テストを成功させるために、いくつかのインストール後手順が必要になります。
手順
アンダークラウドからこのテストを実行する場合は、アンダークラウドのホストがオーバークラウドの Internal API ネットワークにアクセスできるようにします。たとえば、172.16.0.201/24 のアドレスを使用して Internal API ネットワーク (ID: 201) にアクセスするにはアンダークラウドホストに一時的な VLAN を追加します。
$ source ~/stackrc (undercloud) $ sudo ovs-vsctl add-port br-ctlplane vlan201 tag=201 -- set interface vlan201 type=internal (undercloud) $ sudo ip l set dev vlan201 up; sudo ip addr add 172.16.0.201/24 dev vlan201
- OpenStack Integration Test Suite Guide の説明に従って、統合テストを実施します。
検証が完了したら、オーバークラウドの Internal API への一時接続を削除します。この例では、以下のコマンドを使用して、以前にアンダークラウドで作成した VLAN を削除します。
$ source ~/stackrc (undercloud) $ sudo ovs-vsctl del-port vlan201
14.8. オーバークラウドの削除防止
オーバークラウドが削除されないように、heat のカスタムポリシーを設定します。
手順
-
prevent-stack-delete.yamlという名前の環境ファイルを作成します。 HeatApiPoliciesパラメーターを設定します。parameter_defaults: HeatApiPolicies: heat-deny-action: key: 'actions:action' value: 'rule:deny_everybody' heat-protect-overcloud: key: 'stacks:delete' value: 'rule:deny_everybody'重要heat-deny-actionは、アンダークラウドのインストールに追加する必要のあるデフォルトポリシーです。undercloud.confファイルのcustom_env_filesパラメーターに、prevent-stack-delete.yaml環境ファイルを追加します。custom_env_files = prevent-stack-delete.yaml
アンダークラウドのインストールコマンドを実行して設定をリフレッシュします。
$ openstack undercloud install
この環境ファイルにより、オーバークラウド内のスタックを削除することができなくなります。したがって、以下の操作を実施することはできません。
- オーバークラウドの削除
- 個々のコンピュートノードまたは Ceph Storage ノードの削除
- コントローラーノードの置き換え
スタックの削除を有効にするには、custom_env_files パラメーターから prevent-stack-delete.yaml ファイルを削除し、openstack undercloud install コマンドを実行します。
第15章 基本的なオーバークラウド管理タスクの実施
本章では、オーバークラウドのライフサイクル期間中に実行しなければならない可能性がある、基本的なタスクについて説明します。
15.1. SSH を使用したオーバークラウドノードへのアクセス
SSH プロトコルを使用して、各オーバークラウドノードにアクセスすることができます。
-
各オーバークラウドノードには
tripleo-adminユーザーが含まれます。 -
アンダークラウドの
stackユーザーは、各オーバークラウドノードのtripleo-adminユーザーに鍵ベースの SSH アクセスを行うことができます。 -
すべてのオーバークラウドノードは短縮ホスト名を持ち、アンダークラウドはこのホスト名をコントロールプレーンネットワーク上の IP アドレスに解決します。それぞれの短縮ホスト名には、
.ctlplane接尾辞が使用されます。たとえば、overcloud-controller-0の短縮名はovercloud-controller-0.ctlplaneです。
前提条件
- 稼動状態にあるコントロールプレーンネットワークと共にデプロイされたオーバークラウド
手順
-
アンダークラウドに
stackユーザーとしてログインします。 アクセスするノードの名前を確認します。
(undercloud)$ metalsmith list
tripleo-adminユーザーとしてノードに接続します。(undercloud)$ ssh tripleo-admin@overcloud-controller-0
15.2. コンテナー化されたサービスの管理
Red Hat OpenStack Platform (RHOSP) では、アンダークラウドおよびオーバークラウドノード上のコンテナー内でサービスが実行されます。特定の状況では、1 つのホスト上で個別のサービスを制御する必要がある場合があります。本項では、コンテナー化されたサービスを管理するためにノード上で実行することのできる、一般的なコマンドについて説明します。
コンテナーとイメージの一覧表示
実行中のコンテナーを一覧表示するには、以下のコマンドを実行します。
$ sudo podman ps
コマンド出力に停止中またはエラーの発生したコンテナーを含めるには、コマンドに --all オプションを追加します。
$ sudo podman ps --all
コンテナーイメージを一覧表示するには、以下のコマンドを実行します。
$ sudo podman images
コンテナーの属性の確認
コンテナーまたはコンテナーイメージのプロパティーを表示するには、podman inspect コマンドを使用します。たとえば、keystone コンテナーを検査するには、以下のコマンドを実行します。
$ sudo podman inspect keystone
Systemd サービスを使用したコンテナーの管理
以前のバージョンの OpenStack Platform では、コンテナーは Docker およびそのデーモンで管理されていました。これで、Systemd サービスインターフェイスがコンテナーのライフサイクルを管理します。それぞれのコンテナーはサービスであり、Systemd コマンドを実行して各コンテナーに関する特定の操作を実施します。
Systemd は再起動ポリシーを適用するため、Podman CLI を使用してコンテナーを停止、起動、および再起動することは推奨されません。その代わりに、Systemd サービスコマンドを使用してください。
コンテナーのステータスを確認するには、systemctl status コマンドを実行します。
$ sudo systemctl status tripleo_keystone
● tripleo_keystone.service - keystone container
Loaded: loaded (/etc/systemd/system/tripleo_keystone.service; enabled; vendor preset: disabled)
Active: active (running) since Fri 2019-02-15 23:53:18 UTC; 2 days ago
Main PID: 29012 (podman)
CGroup: /system.slice/tripleo_keystone.service
└─29012 /usr/bin/podman start -a keystone
コンテナーを停止するには、systemctl stop コマンドを実行します。
$ sudo systemctl stop tripleo_keystone
コンテナーを起動するには、systemctl start コマンドを実行します。
$ sudo systemctl start tripleo_keystone
コンテナーを再起動するには、systemctl restart コマンドを実行します。
$ sudo systemctl restart tripleo_keystone
コンテナーステータスを監視するデーモンはないので、以下の状況では Systemd はほとんどのコンテナーを自動的に再起動します。
-
podman stopコマンドの実行など、明瞭な終了コードまたはシグナル - 起動後に podman コンテナーがクラッシュするなど、不明瞭な終了コード
- 不明瞭なシグナル
- コンテナーの起動に 1 分 30 秒以上かかった場合のタイムアウト
Systemd サービスに関する詳しい情報は、systemd.service のドキュメント を参照してください。
コンテナー内のサービス設定ファイルに加えた変更は、コンテナーの再起動後には元に戻ります。これは、コンテナーがノードのローカルファイルシステム上の /var/lib/config-data/puppet-generated/ にあるファイルに基づいてサービス設定を再生成するためです。たとえば、keystone コンテナー内の /etc/keystone/keystone.conf を編集してコンテナーを再起動すると、そのコンテナーはノードのローカルシステム上にある /var/lib/config-data/puppet-generated/keystone/etc/keystone/keystone.conf を使用して設定を再生成します。再起動前にコンテナー内で加えられた変更は、この設定によって上書きされます。
Systemd タイマーを使用した podman コンテナーの監視
Systemd タイマーインターフェイスは、コンテナーのヘルスチェックを管理します。各コンテナーのタイマーがサービスユニットを実行し、そのユニットがヘルスチェックスクリプトを実行します。
すべての OpenStack Platform コンテナーのタイマーを一覧表示するには、systemctl list-timers コマンドを実行し、出力を tripleo が含まれる行に限定します。
$ sudo systemctl list-timers | grep tripleo Mon 2019-02-18 20:18:30 UTC 1s left Mon 2019-02-18 20:17:26 UTC 1min 2s ago tripleo_nova_metadata_healthcheck.timer tripleo_nova_metadata_healthcheck.service Mon 2019-02-18 20:18:34 UTC 5s left Mon 2019-02-18 20:17:23 UTC 1min 5s ago tripleo_keystone_healthcheck.timer tripleo_keystone_healthcheck.service Mon 2019-02-18 20:18:35 UTC 6s left Mon 2019-02-18 20:17:13 UTC 1min 15s ago tripleo_memcached_healthcheck.timer tripleo_memcached_healthcheck.service (...)
特定のコンテナータイマーのステータスを確認するには、healthcheck サービスに対して systemctl status コマンドを実行します。
$ sudo systemctl status tripleo_keystone_healthcheck.service
● tripleo_keystone_healthcheck.service - keystone healthcheck
Loaded: loaded (/etc/systemd/system/tripleo_keystone_healthcheck.service; disabled; vendor preset: disabled)
Active: inactive (dead) since Mon 2019-02-18 20:22:46 UTC; 22s ago
Process: 115581 ExecStart=/usr/bin/podman exec keystone /openstack/healthcheck (code=exited, status=0/SUCCESS)
Main PID: 115581 (code=exited, status=0/SUCCESS)
Feb 18 20:22:46 undercloud.localdomain systemd[1]: Starting keystone healthcheck...
Feb 18 20:22:46 undercloud.localdomain podman[115581]: {"versions": {"values": [{"status": "stable", "updated": "2019-01-22T00:00:00Z", "..."}]}]}}
Feb 18 20:22:46 undercloud.localdomain podman[115581]: 300 192.168.24.1:35357 0.012 seconds
Feb 18 20:22:46 undercloud.localdomain systemd[1]: Started keystone healthcheck.
コンテナータイマーを停止、起動、再起動、およびコンテナータイマーのステータスを表示するには、.timer Systemd リソースに対して該当する systemctl コマンドを実行します。たとえば、tripleo_keystone_healthcheck.timer リソースのステータスを確認するには、以下のコマンドを実行します。
$ sudo systemctl status tripleo_keystone_healthcheck.timer ● tripleo_keystone_healthcheck.timer - keystone container healthcheck Loaded: loaded (/etc/systemd/system/tripleo_keystone_healthcheck.timer; enabled; vendor preset: disabled) Active: active (waiting) since Fri 2019-02-15 23:53:18 UTC; 2 days ago
healthcheck サービスは無効だが、そのサービスのタイマーが存在し有効になっている場合には、チェックは現在タイムアウトしているが、タイマーに従って実行されることを意味します。チェックを手動で開始することもできます。
podman ps コマンドは、コンテナーのヘルスステータスを表示しません。
コンテナーログの確認
Red Hat OpenStack Platform 17.0 は、すべてのコンテナーからのすべての標準出力 (stdout) をログに記録し、標準エラー (stderr) は /var/log/containers/stdout 内 のコンテナーごとに 1 つのファイルに統合されます。
また、ホストはこのディレクトリーにログローテーションを適用し、大きな容量のファイルがディスク容量を消費する問題を防ぎます。
コンテナーが置き換えられた場合には、新しいコンテナーは同じログファイルにログを出力します。podman はコンテナー ID ではなくコンテナー名を使用するためです。
podman logs コマンドを使用して、コンテナー化されたサービスのログを確認することもできます。たとえば、keystone コンテナーのログを確認するには、以下のコマンドを実行します。
$ sudo podman logs keystone
コンテナーへのアクセス
コンテナー化されたサービスのシェルに入るには、podman exec コマンドを使用して /bin/bash を起動します。たとえば、keystone コンテナーのシェルに入るには、以下のコマンドを実行します。
$ sudo podman exec -it keystone /bin/bash
root ユーザーとして keystone コンテナーのシェルに入るには、以下のコマンドを実行します。
$ sudo podman exec --user 0 -it <NAME OR ID> /bin/bash
コンテナーから出るには、以下のコマンドを実行します。
# exit
15.3. オーバークラウド環境の変更
オーバークラウドを変更して、新たな機能を追加したり、既存の操作を変更したりすることができます。
手順
オーバークラウドを変更するには、カスタムの環境ファイルと heat テンプレートに変更を加えて、最初に作成したオーバークラウドから
openstack overcloud deployコマンドをもう 1 度実行します。たとえば、「オーバークラウドの設定およびデプロイ」 に記載の手順を使用してオーバークラウドを作成した場合には、以下のコマンドを再度実行します。$ source ~/stackrc (undercloud) $ openstack overcloud deploy --templates \ -e ~/templates/overcloud-baremetal-deployed.yaml \ -e ~/templates/network-environment.yaml \ -e ~/templates/storage-environment.yaml \ --ntp-server pool.ntp.org
director は heat 内の
overcloudスタックを確認してから、環境ファイルと heat テンプレートのあるスタックで各アイテムを更新します。director はオーバークラウドを再度作成せずに、既存のオーバークラウドに変更を加えます。重要カスタム環境ファイルからパラメーターを削除しても、パラメーター値はデフォルト設定に戻りません。
/usr/share/openstack-tripleo-heat-templatesのコア heat テンプレートコレクションからデフォルト値を特定し、カスタム環境ファイルでその値を手動で設定する必要があります。新規環境ファイルを追加する場合には、`-e` オプションを使用して
openstack overcloud deployコマンドにそのファイルを追加します。以下に例を示します。$ source ~/stackrc (undercloud) $ openstack overcloud deploy --templates \ -e ~/templates/new-environment.yaml \ -e ~/templates/network-environment.yaml \ -e ~/templates/storage-environment.yaml \ -e ~/templates/overcloud-baremetal-deployed.yaml \ --ntp-server pool.ntp.org
このコマンドにより、環境ファイルからの新規パラメーターやリソースがスタックに追加されます。
重要オーバークラウドの設定に手動で変更を加えることは推奨されません。director によりこれらの変更が後で上書きされてしまう可能性があるためです。
15.4. オーバークラウドへの仮想マシンのインポート
既存の OpenStack 環境からご自分の Red Hat OpenStack Platform (RHOSP) 環境に仮想マシンを移行することができます。
手順
既存の OpenStack 環境において、実行中のサーバーのスナップショットを作成して新規イメージを作成し、そのイメージをダウンロードします。
$ openstack server image create --name <image_name> <instance_name> $ openstack image save --file <exported_vm.qcow2> <image_name>
-
<instance_name>は、インスタンスの名前に置き換えます。 -
<image_name>は、新しいイメージの名前に置き換えます。 -
<exported_vm.qcow2>は、エクスポートされた仮想マシンの名前に置き換えます。
-
エクスポートしたイメージをアンダークラウドノードにコピーします。
$ scp exported_vm.qcow2 stack@192.168.0.2:~/.
-
アンダークラウドに
stackユーザーとしてログインします。 overcloudrc認証情報ファイルを入手します。$ source ~/overcloudrc
エクスポートしたイメージをオーバークラウドにアップロードします。
(overcloud) $ openstack image create --disk-format qcow2 -file <exported_vm.qcow2> --container-format bare <image_name>
新規インスタンスを起動します。
(overcloud) $ openstack server create --key-name default --flavor m1.demo --image imported_image --nic net-id=net_id <instance_name>
これらのコマンドを使用すると、各仮想マシンのディスクが既存の OpenStack 環境から新たな Red Hat OpenStack Platform にコピーできます。QCOW スナップショットでは、元の階層化システムが失われます。
15.5. エフェメラル Heat プロセスの開始
以前のバージョンの Red Hat OpenStack Platform (RHOSP) では、システムにインストールされた Heat プロセスを使用してオーバークラウドをインストールしていました。ここで、エフェメラル Heat を使用してオーバークラウドをインストールします。つまり、heat-api および heat-engine プロセスは、deployment、update、および upgrade コマンドによってオンデマンドで開始されます。
以前は、openstack stack コマンドを使用してスタックを作成および管理していました。このコマンドは、デフォルトでは使用できなくなりました。スタックに障害が発生した場合など、トラブルシューティングとデバッグの目的で、最初にエフェメラル Heat プロセスを起動して openstack stack コマンドを使用する必要があります。
openstack overcloud tripleo launch heat コマンドを使用して、デプロイメントの外部でエフェメラル Heat を有効にします。
手順
openstack tripleo launch heatコマンドを使用して、エフェメラル Heat プロセスを起動します。(undercloud)$ openstack tripleo launch heat --heat-dir /home/stack/overcloud-deploy/overcloud/heat-launcher --restore-db
このコマンドは、Heat プロセスを起動した後に終了し、この Heat プロセスは podman Pod としてバックグラウンドで実行され続けます。
podman pod psコマンドを使用して、ephemeral-heatプロセスが実行されていることを確認します。(undercloud)$ sudo podman pod ps POD ID NAME STATUS CREATED INFRA ID # OF CONTAINERS 958b141609b2 ephemeral-heat Running 2 minutes ago 44447995dbcf 3
exportコマンドを使用して、OS_CLOUD環境をエクスポートします。(undercloud)$ export OS_CLOUD=heat
インストールされているスタックを一覧表示するには、
openstack stack listコマンドを使用します。(undercloud)$ openstack stack list +--------------------------------------+------------+---------+-----------------+----------------------+--------------+ | ID | Stack Name | Project | Stack Status | Creation Time | Updated Time | +--------------------------------------+------------+---------+-----------------+----------------------+--------------+ | 761e2a54-c6f9-4e0f-abe6-c8e0ad51a76c | overcloud | admin | CREATE_COMPLETE | 2022-08-29T20:48:37Z | None | +--------------------------------------+------------+---------+-----------------+----------------------+--------------+
openstack stack environment showやopenstack stack resource listなどのコマンドでデバッグできます。デバッグが終了したら、一時的な Heat プロセスを停止します。
(undercloud)$ openstack tripleo launch heat --kill
Heat 環境のエクスポートが失敗することがあります。これは、overcloudrc などの他の資格情報が使用されている場合に発生する可能性があります。この場合、既存の環境を設定解除し、Heat 環境を取り込みます。
(overcloud)$ unset OS_CLOUD (overcloud)$ unset OS_PROJECT_NAME (overcloud)$ unset OS_PROJECT_DOMAIN_NAME (overcloud)$ unset OS_USER_DOMAIN_NAME (overcloud)$ OS_AUTH_TYPE=none (overcloud)$ OS_ENDPOINT=http://127.0.0.1:8006/v1/admin (overcloud)$ export OS_CLOUD=heat
15.6. 動的インベントリースクリプトの実行
Ansible ベースの自動化をご自分の Red Hat OpenStack Platform (RHOSP) 環境で実行することができます。/home/stack/overcloud-deploy/<stack> ディレクトリーにある Tripleo-ansible-inventory.yaml インベントリーファイルを使用して、Ansible Play またはアドホックコマンドを実行します。
アンダークラウドで Ansible Playbook または Ansible アドホックコマンドを実行する場合は、/home/stack/tripleo-deploy/undercloud/tripleo-ansible-inventory.yaml インベントリーファイルを使用する必要があります。
手順
ノードのインベントリーを表示するには、次の Ansible アドホックコマンドを実行します。
(undercloud) $ ansible -i ./overcloud-deploy/<stack>/tripleo-ansible-inventory.yaml all --list
注記stack をデプロイされたオーバークラウドスタックの名前に置き換えます。
環境上で Ansible Playbook を実行するには、
ansibleコマンドを実行し、-iオプションを使用してインベントリーファイルへのフルパスを含めます。以下に例を示します。(undercloud) $ ansible <hosts> -i ./overcloud-deploy/tripleo-ansible-inventory.yaml <playbook> <options>
<hosts>を、使用するホストのタイプに置き換えます。-
全コントローラーノードの場合には
controller -
全コンピュートノードの場合には
compute -
オーバークラウドの全子ノードの場合には
overcloud(たとえば、コントローラーノードおよびコンピュートノードの場合) -
全ノードの場合には
"*"
-
全コントローラーノードの場合には
<options>を追加の Ansible オプションに置き換えます。-
ホストキーの確認を省略するには、
--ssh-extra-args='-o StrictHostKeyChecking=no'オプションを使用します。 -
Ansible の自動化を実行する SSH ユーザーを変更するには、
-u [USER]オプションを使用します。オーバークラウドのデフォルトの SSH ユーザーは、動的インベントリーのansible_ssh_userパラメーターで自動的に定義されます。-uオプションは、このパラメーターより優先されます。 -
特定の Ansible モジュールを使用するには、
-m [MODULE]オプションを使用します。デフォルトはcommandで Linux コマンドを実行します。 -
選択したモジュールの引数を定義するには、
-a [MODULE_ARGS]オプションを使用します。
-
ホストキーの確認を省略するには、
オーバークラウドのカスタム Ansible 自動化は、標準のオーバークラウドスタックの一部ではありません。この後に openstack overcloud deploy コマンドを実行すると、オーバークラウドノード上の OpenStack Platform サービスに対する Ansible ベースの設定を上書きする可能性があります。
15.7. オーバークラウドスタックの削除
オーバークラウドスタックを削除して、すべてのスタックノードのプロビジョニングを解除できます。
オーバークラウドスタックを削除しても、すべてのオーバークラウドデータが消去されるわけではありません。オーバークラウドのデータをすべて消去する必要がある場合は、Red Hat サポートにお問い合わせください。
手順
-
アンダークラウドホストに
stackユーザーとしてログインします。 stackrcアンダークラウド認証情報ファイルを入手します。$ source ~/stackrc
スタック内のすべてのノードとその現在のステータスのリストを取得します。
(undercloud)$ openstack baremetal node list +--------------------------------------+--------------+--------------------------------------+-------------+--------------------+-------------+ | UUID | Name | Instance UUID | Power State | Provisioning State | Maintenance | +--------------------------------------+--------------+--------------------------------------+-------------+--------------------+-------------+ | 92ae71b0-3c31-4ebb-b467-6b5f6b0caac7 | compute-0 | 059fb1a1-53ea-4060-9a47-09813de28ea1 | power on | active | False | | 9d6f955e-3d98-4d1a-9611-468761cebabf | compute-1 | e73a4b50-9579-4fe1-bd1a-556a2c8b504f | power on | active | False | | 8a686fc1-1381-4238-9bf3-3fb16eaec6ab | controller-0 | 6d69e48d-10b4-45dd-9776-155a9b8ad575 | power on | active | False | | eb8083cc-5f8f-405f-9b0c-14b772ce4534 | controller-1 | 1f836ac0-a70d-4025-88a3-bbe0583b4b8e | power on | active | False | | a6750f1f-8901-41d6-b9f1-f5d6a10a76c7 | controller-2 | e2edd028-cea6-4a98-955e-5c392d91ed46 | power on | active | False | +--------------------------------------+--------------+--------------------------------------+-------------+--------------------+-------------+
オーバークラウドスタックを削除し、ノードとネットワークのプロビジョニングを解除します:
(undercloud)$ openstack overcloud delete -b <node_definition_file> \ --networks-file <networks_definition_file> --network-ports <stack>
-
<node_definition_file>は、ノード定義ファイルの名前 (overcloud-baremetal-deploy.yamlなど) に置き換えます。 -
<networks_definition_file>は、ネットワーク定義ファイルの名前 (network_data.yamlなど) に置き換えます。 -
<stack>を、削除するスタックの名前に置き換えます。指定しない場合、デフォルトのスタックはovercloudです。
-
オーバークラウドを削除することを確認します。
Are you sure you want to delete this overcloud [y/N]?
- オーバークラウドが削除され、ノードとネットワークがプロビジョニング解除されるまで待ちます。
ベアメタルノードがプロビジョニング解除されていることを確認します。
(undercloud) [stack@undercloud-0 ~]$ openstack baremetal node list +--------------------------------------+--------------+---------------+-------------+--------------------+-------------+ | UUID | Name | Instance UUID | Power State | Provisioning State | Maintenance | +--------------------------------------+--------------+---------------+-------------+--------------------+-------------+ | 92ae71b0-3c31-4ebb-b467-6b5f6b0caac7 | compute-0 | None | power off | available | False | | 9d6f955e-3d98-4d1a-9611-468761cebabf | compute-1 | None | power off | available | False | | 8a686fc1-1381-4238-9bf3-3fb16eaec6ab | controller-0 | None | power off | available | False | | eb8083cc-5f8f-405f-9b0c-14b772ce4534 | controller-1 | None | power off | available | False | | a6750f1f-8901-41d6-b9f1-f5d6a10a76c7 | controller-2 | None | power off | available | False | +--------------------------------------+--------------+---------------+-------------+--------------------+-------------+
スタックディレクトリーを削除します。
$ rm -rf ~/overcloud-deploy/<stack> $ rm -rf ~/config-download/<stack>
注記openstack overcloud deployコマンドを使用してオーバークラウドをデプロイするときに--output-dirと--working-dirオプションを使用した場合、スタックのディレクトリーパスはデフォルトとは異なる可能性があります。
第16章 Ansible を使用したオーバークラウドの設定
Ansible は、オーバークラウドの設定を適用する主要な方法です。本章では、オーバークラウドの Ansible 設定を操作する方法について説明します。
director は Ansible Playbook を自動生成しますが、Ansible の構文を十分に理解しておくと役立ちます。Ansible の使用についての詳細は、Ansible のドキュメント を参照してください。
Ansible でもロールの概念を使用します。これは、OpenStack Platform director のロールとは異なります。Ansible のロール は再利用可能な Playbook のコンポーネントを形成しますが、director のロールには OpenStack サービスのノード種別へのマッピングが含まれます。
16.1. Ansible ベースのオーバークラウド設定 (config-download)
director は、config-download 機能を使用してオーバークラウドを設定します。director は、config-download を OpenStack Orchestration (heat) と組み合わせて使用して、ソフトウェア設定を生成し、その設定を各オーバークラウドノードに適用します。heat は SoftwareDeployment リソースから全デプロイメントデータを作成して、オーバークラウドのインストールと設定を行いますが、設定の適用は一切行いません。heat は、heat API から設定データの提供のみを行います。
結果として、openstack overcloud deploy コマンドを実行すると、以下のプロセスが実行されます。
-
director は
openstack-tripleo-heat-templatesを元に新たなデプロイメントプランを作成し、プランをカスタマイズするための環境ファイルおよびパラメーターをすべて追加します。 - director は heat を使用してデプロイメントプランを翻訳し、オーバークラウドスタックとすべての子リソースを作成します。これには、OpenStack Bare Metal サービス (ironic) を使用したノードのプロビジョニングも含まれます。
- heat はデプロイメントプランからソフトウェア設定も作成します。director はこのソフトウェア設定から Ansible Playbook をコンパイルします。
-
director は、特に Ansible SSH アクセス用としてオーバークラウドノードに一時ユーザー (
tripleo-admin) を生成します。 - director は heat ソフトウェア設定をダウンロードし、heat の出力を使用して Ansible Playbook のセットを生成します。
-
director は、
ansible-playbookを使用してオーバークラウドノードに Ansible Playbook を適用します。
16.2. config-download の作業ディレクトリー
ansible-playbook コマンドは、Ansible プロジェクトディレクトリーを作成します。デフォルト名は ~/config-download/overcloud です。このプロジェクトディレクトリーには、heat からダウンロードしたソフトウェア設定が保存されます。これには、ansible-playbook を実行してオーバークラウドを設定するために必要なすべての Ansible 関連ファイルが含まれています。
ディレクトリーの内容は次のとおりです。
-
tripleo-ansible-inventory.yaml - すべてのオーバークラウドノードの
hostsとvarsを含む Ansible インベントリーファイル。 -
ansible.log -
ansible-playbookの最新の実行からのログファイル。 -
ansible.cfg -
ansible-playbook の実行時に使用される設定ファイル。 -
ansible-playbook-command.sh -
ansible-playbookの再実行に使用される実行可能スクリプト。 ssh_private_key - オーバークラウドノードへのアクセスに使用されるプライベート ssh キー。
- ansible-playbook の再現
プロジェクトディレクトリーが作成されたら、ansible-playbook-command.sh コマンドを実行してデプロイメントを再現します。
$ ./ansible-playbook-command.sh
チェックモード --check、ホストの制限 --limit、変数のオーバーライド -e などの追加の引数を指定してスクリプトを実行できます。
$ ./ansible-playbook-command.sh --check
16.3. config-download ログの確認
config-download プロセス中に、Ansible はアンダークラウドの /home/stack ディレクトリーに ansible.log という名前のログファイルを作成します。
手順
lessコマンドでログを表示します。$ less ~/ansible.log
16.4. 作業ディレクトリーでの Git 操作の実施
config-download の作業ディレクトリーは、ローカルの Git リポジトリーです。デプロイメント操作を実行するたびに、director は該当する変更に関する Git コミットを作業ディレクトリーに追加します。Git 操作を実施して、さまざまなステージでのデプロイメント設定を表示したり、異なるデプロイメント間で設定を比較したりすることができます。
作業ディレクトリーには制限がある点に注意してください。たとえば、Git を使用して config-download の作業ディレクトリーを前のバージョンに戻しても、この操作は作業ディレクトリー内の設定にしか影響を及ぼしません。したがって、以下の設定は影響を受けません。
- オーバークラウドデータスキーマ: 作業ディレクトリーのソフトウェア設定の前のバージョンを適用しても、データ移行およびスキーマ変更は取り消されません。
- オーバークラウドのハードウェアレイアウト: 以前のソフトウェア設定に戻しても、スケールアップ/ダウン等のオーバークラウドハードウェアに関する変更は取り消されません。
-
heat スタック: 作業ディレクトリーを前のバージョンに戻しても、heat スタックに保管された設定は影響を受けません。heat スタックは新たなバージョンのソフトウェア設定を作成し、それがオーバークラウドに適用されます。オーバークラウドに永続的な変更を加えるには、
openstack overcloud deployコマンドを再度実行する前に、オーバークラウドスタックに適用する環境ファイルを変更します。
config-download の作業ディレクトリー内の異なるコミットを比較するには、以下の手順を実施します。
手順
オーバークラウドの
config-downloadの作業ディレクトリー (通常はovercloudという名前) に移動します。$ cd ~/config-download/overcloud
git logコマンドを実行して、作業ディレクトリー内のコミットの一覧を表示します。ログの出力に日付が表示されるようにフォーマットを設定することもできます。$ git log --format=format:"%h%x09%cd%x09" a7e9063 Mon Oct 8 21:17:52 2018 +1000 dfb9d12 Fri Oct 5 20:23:44 2018 +1000 d0a910b Wed Oct 3 19:30:16 2018 +1000 ...
デフォルトでは、最新のコミットから順に表示されます。
2 つのコミットのハッシュに対して
git diffコマンドを実行し、デプロイメント間の違いをすべて表示します。$ git diff a7e9063 dfb9d12
16.5. config-download を使用するデプロイメント方式
オーバークラウドのデプロイメントに関して、config-download を使用する方式は以下の 4 つに大別されます。
- 標準のデプロイメント
-
openstack overcloud deployコマンドを実行して、プロビジョニングステージの後に設定ステージを自動的に実行します。これは、openstack overcloud deployコマンドを実行する際のデフォルトの方式です。 - プロビジョニングと設定の分離
-
特定のオプションを指定して
openstack overcloud deployコマンドを実行し、プロビジョニングステージと設定ステージを分離します。 - デプロイメント後の ansible-playbook-command.sh スクリプトの実行
-
プロビジョニングステージと設定ステージを分離または組み合わせて
openstack overcloud deployコマンドを実行し、続いてconfig-downloadの作業ディレクトリーに用意されているansible-playbook-command.shスクリプトを実行し、設定ステージを再度適用します。 - ノードのプロビジョニング、config-download の手動作成、および Ansible の実行
-
特定のオプションを指定して
openstack overcloud deployコマンドを実行し、ノードをプロビジョニングしてから、deploy_steps_playbook.yamlを指定してansible-playbookコマンドを実行します。
16.6. 標準デプロイメントでの config-download の実行
config-download を実行するためのデフォルトの方法は、openstack overcloud deploy コマンドを実行することです。この方式は、ほとんどの環境に適します。
前提条件
- アンダークラウドの正常なインストール。
- デプロイ可能なオーバークラウドノード
- 実際のオーバークラウドカスタマイズに該当する Heat 環境ファイル
手順
-
アンダークラウドホストに
stackユーザーとしてログインします。 stackrcファイルを取得します。$ source ~/stackrc
デプロイメントコマンドを実行します。オーバークラウドに必要なすべての環境ファイルを追加します。
$ openstack overcloud deploy \ --templates \ -e environment-file1.yaml \ -e environment-file2.yaml \ ...
- デプロイメントプロセスが完了するまで待ちます。
デプロイプロセス中に、director は config-download ファイルを ~/config-download/overcloud の作業ディレクトリーに生成します。デプロイメントプロセスが終了したら、作業ディレクトリーの Ansible Playbooks を表示して、オーバークラウドを設定するために director が実行したタスクを確認します。
16.7. プロビジョニングと設定を分離した config-download の実行
openstack overcloud deploy コマンドは、heat ベースのプロビジョニングプロセスの後に、config-download 設定プロセスを実行します。各プロセスを個別に実施するように、デプロイメントコマンドを実行することもできます。独立したプロセスとしてオーバークラウドノードをプロビジョニングするには、この方式を使用します。これにより、オーバークラウドの設定プロセスを実施する前に、ノードで手動の事前設定タスクを実行することができます。
前提条件
- アンダークラウドの正常なインストール。
- デプロイ可能なオーバークラウドノード
- 実際のオーバークラウドカスタマイズに該当する Heat 環境ファイル
手順
-
アンダークラウドホストに
stackユーザーとしてログインします。 stackrcファイルを取得します。$ source ~/stackrc
--stack-onlyオプションを指定してデプロイメントコマンドを実行します。オーバークラウドに必要なすべての環境ファイルを追加します。$ openstack overcloud deploy \ --templates \ -e environment-file1.yaml \ -e environment-file2.yaml \ ... --stack-only
- プロビジョニングプロセスが完了するまで待ちます。
tripleo-adminユーザーによるアンダークラウドからオーバークラウドへの SSH アクセスを有効にします。config-downloadプロセスでは、tripleo-adminユーザーを使用して Ansible ベースの設定を実施します。$ openstack overcloud admin authorize
-
ノードで手動の事前設定タスクを実行します。設定に Ansible を使用する場合は、
tripleo-adminユーザーを使用してノードにアクセスします。 --config-download-onlyオプションを指定してデプロイメントコマンドを実行します。オーバークラウドに必要なすべての環境ファイルを追加します。$ openstack overcloud deploy \ --templates \ -e environment-file1.yaml \ -e environment-file2.yaml \ ... --config-download-only
- 設定プロセスが完了するまで待ちます。
設定段階で、director は config-download ファイルを ~/config-download/overcloud 作業ディレクトリーに生成します。デプロイメントプロセスが終了したら、作業ディレクトリーの Ansible Playbooks を表示して、オーバークラウドを設定するために director が実行したタスクを確認します。
16.8. ansible-playbook-command.sh スクリプトを使用した config-download の実行
標準の方式または個別のプロビジョニングおよび設定プロセスを使用してオーバークラウドをデプロイすると、director は ~/config-download/overcloud に作業ディレクトリーを生成します。このディレクトリーには、設定プロセスを再度実行するのに必要な Playbook およびスクリプトが含まれています。
前提条件
以下の方式のいずれかでデプロイされたオーバークラウド
- プロビジョニングプロセスと設定プロセスをまとめて実施する標準の方式
- プロビジョニングプロセスと設定プロセスを分離する方式
手順
-
アンダークラウドホストに
stackユーザーとしてログインします。 ansible-playbook-command.shスクリプトを実行します。このスクリプトには追加の Ansible 引数を渡すことができ、それらの引数は、そのまま
ansible-playbookコマンドに渡されます。これにより、チェックモード (--check)、ホストの限定 (--limit)、変数のオーバーライド (-e) など、Ansible の機能を更に活用することが可能となります。以下に例を示します。$ ./ansible-playbook-command.sh --limit Controller
警告--limitを使用して大規模にデプロイする場合、実行に含まれるホストのみがノード全体の SSHknown_hostsファイルに追加されます。したがって、ライブマイグレーションなどの一部の操作は、known_hostsファイルにないノード間では機能しない場合があります。注記すべてのノードで
/etc/hostsファイルが最新であることを確認するには、stackユーザーとして次のコマンドを実行します。(undercloud)$ cd /home/stack/overcloud-deploy/overcloud/config-download/overcloud (undercloud)$ ANSIBLE_REMOTE_USER="tripleo-admin" ansible allovercloud \ -i /home/stack/overcloud-deploy/overcloud/tripleo-ansible-inventory.yaml \ -m include_role \ -a name=tripleo_hosts_entries \ -e @global_vars.yaml
設定プロセスが完了するまで待ちます。
追加情報
作業ディレクトリーには、オーバークラウドの設定タスクを管理する
deploy_steps_playbook.yamlという名前の Playbook が含まれています。この Playbook を表示するには、以下のコマンドを実行します。$ less deploy_steps_playbook.yaml
Playbook は、作業ディレクトリーに含まれているさまざまなタスクファイルを使用します。タスクファイルには、OpenStack Platform の全ロールに共通するものと、特定の OpenStack Platform ロールおよびサーバー固有のものがあります。
作業ディレクトリーには、オーバークラウドの
roles_dataファイルで定義する各ロールに対応するサブディレクトリーも含まれます。以下に例を示します。$ ls Controller/
各 OpenStack Platform ロールにディレクトリーには、そのロール種別の個々のサーバー用のサブディレクトリーも含まれます。これらのディレクトリーには、コンポーザブルロールのホスト名の形式を使用します。
$ ls Controller/overcloud-controller-0
deploy_steps_playbook.yamlの Ansible タスクはタグ付けされます。タグの全一覧を確認するには、ansible-playbookで CLI オプション--list-tagsを使用します。$ ansible-playbook -i tripleo-ansible-inventory.yaml --list-tags deploy_steps_playbook.yaml
次に、
ansible-playbook-command.shスクリプトで--tags、--skip-tags、--start-at-taskのいずれかを使用して、タグ付けした設定を適用します。$ ./ansible-playbook-command.sh --tags overcloud
オーバークラウドに対して
config-downloadPlaybook を実行すると、それぞれのホストの SSH フィンガープリントに関するメッセージが表示される場合があります。これらのメッセージを回避するには、ansible-playbook-command.shスクリプトの実行時に、--ssh-common-args="-o StrictHostKeyChecking=no"を追加します。$ ./ansible-playbook-command.sh --tags overcloud --ssh-common-args="-o StrictHostKeyChecking=no"
16.9. 手動で作成した Playbook を使用した config-download の実行
標準のワークフローとは別に、専用の config-download ファイルを作成することができます。たとえば、--stack-only オプションを指定して openstack overcloud deploy コマンドを実行し、ノードをプロビジョニングしてから、別途 Ansible 設定を手動で適用することができます。
前提条件
- アンダークラウドの正常なインストール。
- デプロイ可能なオーバークラウドノード
- 実際のオーバークラウドカスタマイズに該当する Heat 環境ファイル
手順
-
アンダークラウドホストに
stackユーザーとしてログインします。 stackrcファイルを取得します。$ source ~/stackrc
--stack-onlyオプションを指定してデプロイメントコマンドを実行します。オーバークラウドに必要なすべての環境ファイルを追加します。$ openstack overcloud deploy \ --templates \ -e environment-file1.yaml \ -e environment-file2.yaml \ ... --stack-only
- プロビジョニングプロセスが完了するまで待ちます。
tripleo-adminユーザーによるアンダークラウドからオーバークラウドへの SSH アクセスを有効にします。config-downloadプロセスでは、tripleo-adminユーザーを使用して Ansible ベースの設定を実施します。$ openstack overcloud admin authorize
config-downloadファイルを生成します。$ openstack overcloud deploy \ --stack overcloud --stack-only \ --config-dir ~/overcloud-deploy/overcloud/config-download/overcloud/
-
--stackは、オーバークラウドの名前を指定します。 -
--stack-onlyは、確実にコマンドが Heat スタックのみをデプロイし、ソフトウェア設定をスキップするようにします。 -
--config-dirは、config-downloadファイルの場所を指定します。
-
config-downloadファイルが含まれるディレクトリーに移動します。$ cd ~/config-download
静的なインベントリーファイルを生成します。
$ tripleo-ansible-inventory \ --stack <overcloud> \ --ansible_ssh_user tripleo-admin \ --static-yaml-inventory inventory.yaml
-
<overcloud>を実際のオーバークラウドの名前に置き換えてください。
-
~/overcloud-deploy/overcloud/config-download/overcloudファイルと静的インベントリーファイルを使用して設定を実行します。デプロイメント用の Playbook を実行するには、ansible-playbookコマンドを実行します。$ ansible-playbook \ -i inventory.yaml \ -e gather_facts=true \ -e @global_vars.yaml \ --private-key ~/.ssh/id_rsa \ --become \ ~/overcloud-deploy/overcloud/config-download/overcloud/deploy_steps_playbook.yaml
注記オーバークラウドに対して
config-download/overcloudPlaybook を実行すると、それぞれのホストの SSH フィンガープリントに関するメッセージが表示される場合があります。これらのメッセージを回避するには、--ssh-common-args="-o StrictHostKeyChecking=no"をansible-playbookコマンドに追加します。$ ansible-playbook \ -i inventory.yaml \ -e gather_facts=true \ -e @global_vars.yaml \ --private-key ~/.ssh/id_rsa \ --ssh-common-args="-o StrictHostKeyChecking=no" \ --become \ --tags overcloud \ ~/overcloud-deploy/overcloud/config-download/overcloud/deploy_steps_playbook.yaml
- 設定プロセスが完了するまで待ちます。
ansible ベースの設定から手動で
overcloudrcファイルを生成します。$ openstack action execution run \ --save-result \ --run-sync \ tripleo.deployment.overcloudrc \ '{"container":"overcloud"}' \ | jq -r '.["result"]["overcloudrc.v3"]' > overcloudrc.v3デプロイメントステータスを手動で success に設定します。
$ openstack workflow execution create tripleo.deployment.v1.set_deployment_status_success '{"plan": "<overcloud>"}'-
<overcloud>を実際のオーバークラウドの名前に置き換えてください。
-
~/overcloud-deploy/overcloud/config-download/overcloud/ ディレクトリーには、Playbook deploy_steps_playbook.yaml が含まれています。Playbook は、作業ディレクトリーに含まれているさまざまなタスクファイルを使用します。すべての Red Hat OpenStack Platform (RHOSP) ロールに共通のタスクファイルもあれば、特定の RHOSP ロールおよびサーバーに固有のタスクファイルもあります。
~/overcloud-deploy/overcloud/config-download/overcloud/ ディレクトリーには、オーバークラウドの roles_data ファイルで定義した各ロールに対応するサブディレクトリーも含まれています。各 RHOSP ロールディレクトリーには、そのロールタイプの個々のサーバーのサブディレクトリーも含まれます。ディレクトリーは、Controller/overcloud-controller-0 などの設定可能なロールのホスト名形式を使用します。
deploy_steps_playbook.yaml の Ansible タスクはタグ付けされます。タグの全一覧を確認するには、ansible-playbook で CLI オプション --list-tags を使用します。
$ ansible-playbook -i tripleo-ansible-inventory.yaml --list-tags deploy_steps_playbook.yaml
次に、ansible-playbook-command.sh スクリプトで --tags、--skip-tags、--start-at-task のいずれかを使用して、タグ付けした設定を適用できます。
$ ansible-playbook \ -i inventory.yaml \ -e gather_facts=true \ -e @global_vars.yaml \ --private-key ~/.ssh/id_rsa \ --become \ --tags overcloud \ ~/overcloud-deploy/overcloud/config-download/overcloud/deploy_steps_playbook.yaml
16.10. config-download の制限事項
config-download 機能にはいくつかの制限があります。
-
--tags、--skip-tags、--start-at-taskなどの ansible-playbook CLI 引数を使用する場合には、デプロイメントの設定は、間違った順序で実行したり適用したりしないでください。これらの CLI 引数は、以前に失敗したタスクを再度実行する場合や、初回のデプロイメントを繰り返す場合に便利な方法です。ただし、デプロイメントの一貫性を保証するには、deploy_steps_playbook.yamlの全タスクを順番どおりに実行する必要があります。 タスク名に変数を使用する特定のタスクに
--start-at-task引数を使用することはできません。たとえば、--start-at-task引数は、以下の Ansible タスクでは機能しません。- name: Run puppet host configuration for step {{ step }}-
オーバークラウドのデプロイメントに director でデプロイされた Ceph Storage クラスターが含まれる場合、
external_deploy_stepsのタスクも省略しない限り、--checkオプションを使用する際にstep1のタスクを省略することはできません。 -
--forksオプションを使用して、同時に実施する Ansible タスクの数を設定することができます。ただし、同時タスクが 25 を超えると、config-download操作のパフォーマンスが低下します。このため、--forksオプションに 25 を超える値を設定しないでください。
16.11. config-download の主要ファイル
config-download の作業ディレクトリー内の主要なファイルを以下に示します。
Ansible の設定および実行
config-download の作業ディレクトリー内の以下のファイルは、Ansible を設定/実行するための専用ファイルです。
- ansible.cfg
-
ansible-playbook実行時に使用する設定ファイル - ansible.log
-
最後に実行した
ansible-playbookに関するログファイル - ansible-errors.json
- デプロイメントエラーが含まれる JSON 構造のファイル
- ansible-playbook-command.sh
-
最後のデプロイメント操作の
ansible-playbookコマンドを再実行するための実行可能スクリプト - ssh_private_key
- Ansible がオーバークラウドノードにアクセスする際に使用する SSH 秘密鍵
- tripleo-ansible-inventory.yaml
- すべてのオーバークラウドノードのホストおよび変数が含まれる Ansible インベントリーファイル
- overcloud-config.tar.gz
- 作業ディレクトリーのアーカイブ
Playbook
以下のファイルは、config-download の作業ディレクトリー内の Playbook です。
- deploy_steps_playbook.yaml
- デプロイメントのメインステップ。この Playbook により、オーバークラウド設定の主要な操作が実施されます。
- pre_upgrade_rolling_steps_playbook.yaml
- メジャーアップグレードのための事前アップグレードステップ
- upgrade_steps_playbook.yaml
- メジャーアップグレードのステップ
- post_upgrade_steps_playbook.yaml
- メジャーアップグレードに関するアップグレード後ステップ
- update_steps_playbook.yaml
- マイナー更新のステップ
- fast_forward_upgrade_playbook.yaml
- Fast Forward Upgrade のタスク。Red Hat OpenStack Platform のロングライフバージョンから次のロングライフバージョンにアップグレードする場合にのみ、この Playbook 使用します。
16.12. config-download のタグ
Playbook では、オーバークラウドに適用されるタスクを管理するのにタグ付けされたタスクを使用します。ansible-playbook CLI の引数 --tags または --skip-tags でタグを使用して、実行するタスクを管理します。デフォルトで有効なタグに関する情報を、以下の一覧に示します。
- facts
- ファクト収集操作
- common_roles
- すべてのノードに共通な Ansible ロール
- overcloud
- オーバークラウドデプロイメント用のすべてのプレイ
- pre_deploy_steps
-
deploy_stepsの操作の前に実施されるデプロイメント - host_prep_steps
- ホスト準備のステップ
- deploy_steps
- デプロイメントのステップ
- post_deploy_steps
-
deploy_stepsの操作の後に実施される手順 - external
- すべての外部デプロイメントタスク
- external_deploy_steps
- アンダークラウドでのみ実行される外部デプロイメントタスク
16.13. config-download のデプロイメントステップ
deploy_steps_playbook.yaml Playbook により、オーバークラウドが設定されます。この Playbook により、オーバークラウドデプロイメントプランに基づき完全なオーバークラウドをデプロイするのに必要なすべてのソフトウェア設定が適用されます。
本項では、この Playbook で使用されるさまざまな Ansible プレイの概要について説明します。本項のプレイと同じ名前が、Playbook 内で使用され ansible-playbook の出力にも表示されます。本項では、それぞれのプレイに設定される Ansible タグについても説明します。
- Gather facts from undercloud
アンダークラウドノードからファクトを収集します。
タグ:
facts- Gather facts from overcloud
オーバークラウドノードからファクトを収集します。
タグ:
facts- Load global variables
global_vars.yamlからすべての変数を読み込みます。タグ:
always- Common roles for TripleO servers
共通の Ansible ロールをすべてのオーバークラウドノードに適用します。これには、ブートストラップパッケージをインストールする tripleo-bootstrap および ssh の既知のホストを設定する tripleo-ssh-known-hosts が含まれます。
タグ:
common_roles- Overcloud deploy step tasks for step 0
deploy_steps_tasks テンプレートインターフェイスからのタスクを適用します。
タグ:
overcloud、deploy_steps- Server deployments
ネットワーク設定や hieradata 等の設定に、サーバー固有の heat デプロイメントを適用します。これには、NetworkDeployment、<Role>Deployment、<Role>AllNodesDeployment 等が含まれます。
タグ:
overcloud、pre_deploy_steps- Host prep steps
host_prep_steps テンプレートインターフェイスからのタスクを適用します。
タグ:
overcloud、host_prep_steps- External deployment step [1,2,3,4,5]
external_deploy_steps_tasks テンプレートインターフェイスからのタスクを適用します。Ansible は、アンダークラウドノードに対してのみこれらのタスクを実行します。
タグ:
external、external_deploy_steps- Overcloud deploy step tasks for [1,2,3,4,5]
deploy_steps_tasks テンプレートインターフェイスからのタスクを適用します。
タグ:
overcloud、deploy_steps- Overcloud common deploy step tasks [1,2,3,4,5]
puppet ホストの設定、
container-puppet.py、およびtripleo-container-manage(コンテナーの設定と管理) など、各ステップで実行される一般的なタスクを適用します。タグ:
overcloud、deploy_steps- Server Post Deployments
5 ステップのデプロイメントプロセス後に実施される設定に、サーバー固有の heat デプロイメントを適用します。
タグ:
overcloud、post_deploy_steps- External deployment Post Deploy tasks
external_post_deploy_steps_tasks テンプレートインターフェイスからのタスクを適用します。Ansible は、アンダークラウドノードに対してのみこれらのタスクを実行します。
タグ:
external、external_deploy_steps
第17章 Ansible を使用したコンテナーの管理
Red Hat OpenStack Platform 17.0 は、tripleo_container_manage Ansible ロールを使用してコンテナーの管理操作を実行します。カスタム Playbook を作成して、特定のコンテナー管理操作を実行することもできます。
-
heat が生成するコンテナー設定データを収集する。
tripleo_container_manageロールは、このデータを使用してコンテナーのデプロイメントをオーケストレーションします。 - コンテナーを起動する。
- コンテナーを停止する。
- コンテナーを更新する。
- コンテナーを削除する。
- 特定の設定でコンテナーを実行する。
director はコンテナー管理を自動的に実施しますが、コンテナー設定をカスタマイズしなければならない場合や、オーバークラウドを再デプロイせずにコンテナーにホットフィックスを適用しなければならない場合があります。
このロールがサポートするのは Podman コンテナー管理だけです。
17.1. tripleo-container-manage ロールのデフォルトと変数
次の抜粋は、tripleo_container_manage Ansible ロールのデフォルトと変数を示しています。
# All variables intended for modification should place placed in this file.
tripleo_container_manage_hide_sensitive_logs: '{{ hide_sensitive_logs | default(true)
}}'
tripleo_container_manage_debug: '{{ ((ansible_verbosity | int) >= 2) | bool }}'
tripleo_container_manage_clean_orphans: true
# All variables within this role should have a prefix of "tripleo_container_manage"
tripleo_container_manage_check_puppet_config: false
tripleo_container_manage_cli: podman
tripleo_container_manage_concurrency: 1
tripleo_container_manage_config: /var/lib/tripleo-config/
tripleo_container_manage_config_id: tripleo
tripleo_container_manage_config_overrides: {}
tripleo_container_manage_config_patterns: '*.json'
# Some containers where Puppet is run, can take up to 10 minutes to finish
# in slow environments.
tripleo_container_manage_create_retries: 120
# Default delay is 5s so 120 retries makes a timeout of 10 minutes which is
# what we have observed a necessary value for nova and neutron db-sync execs.
tripleo_container_manage_exec_retries: 120
tripleo_container_manage_healthcheck_disabled: false
tripleo_container_manage_log_path: /var/log/containers/stdouts
tripleo_container_manage_systemd_teardown: true17.2. tripleo-container-manage molecule のシナリオ
Molecule は tripleo_container_manage ロールをテストするために使用されます。以下は、molecule のデフォルトのインベントリーを示しています。
hosts:
all:
hosts:
instance:
ansible_host: localhost
ansible_connection: local
ansible_distribution: centos8Usage
Red Hat OpenStack 17.0 は、このロールで Podman のみをサポートします。Docker のサポートはロードマップ上にあります。
Molecule Ansible ロールは、次のタスクを実行します。
-
TripleO Heat テンプレートによって生成されたコンテナー設定データを収集します。このデータは、信頼できる情報源として使用されます。コンテナーがすでに
Moleculeで管理されている場合には、現在の状態に関係なく、設定データは必要に応じてコンテナーを再設定します。 -
systemdシャットダウンファイルを管理します。ノードのシャットダウン時または起動時のサービス注文に必要なTripleO Container systemdサービスを作成します。また、netns-placeholderサービスも管理します。 不要になったコンテナーまたは再設定が必要なコンテナーを削除します。コンテナーを削除する必要があるかどうかを判断するための一連のルールが含まれる、
needs_delete ()という名前のカスタムフィルターを使用します。-
コンテナーが
tripleo_ansibleによって管理されていない場合、またはコンテナーのconfig_idが入力 ID と一致しない場合には、コンテナーは削除されません。 -
コンテナーに
config_dataがない場合、またはコンテナーに入力データと一致しないconfig_dataがある場合には、コンテナーは削除されます。コンテナーが削除されると、そのロールもsystemdサービスとヘルスチェックを無効にして削除することに注意してください。
-
コンテナーが
start_orderコンテナー設定で定義された特定の順序でコンテナーを作成します。デフォルトは 0 です。-
コンテナーが
execの場合には、複数のexecを同時に実行できるように asyncを使用して、exec 専用の Playbook が実行されます。 -
それ以外の場合、
podman_containerが非同期で使用され、コンテナーが作成されます。コンテナーに再起動ポリシーがある場合、systemdサービスが設定されます。コンテナーにヘルスチェックスクリプトがある場合には、systemd healthcheckサービスが設定されます。
-
コンテナーが
tripleo_container_manage_concurrency パラメーターはデフォルトで 1 に設定されており、2 より大きい値を設定すると、Podman ロックに関する問題が発生する可能性があります。
Playbook の例:
- name: Manage step_1 containers using tripleo-ansible
block:
- name: "Manage containers for step 1 with tripleo-ansible"
include_role:
name: tripleo_container_manage
vars:
tripleo_container_manage_config: "/var/lib/tripleo-config/container-startup-config/step_1"
tripleo_container_manage_config_id: "tripleo_step1"17.3. tripleo_container_manage ロールの変数
tripleo_container_manage Ansible ロールには、以下の変数が含まれます。
表17.1 ロール変数
| 名前 | デフォルト値 | 説明 |
|---|---|---|
| tripleo_container_manage_check_puppet_config | false |
Ansible で Puppet コンテナー設定を確認する場合は、この変数を使用します。Ansible は、設定ハッシュを使用して更新されたコンテナー設定を識別することができます。コンテナーに Puppet からの新規設定がある場合は、この変数を |
| tripleo_container_manage_cli | podman |
この変数を使用して、コンテナーを管理するのに使用するコマンドラインインターフェイスを設定します。 |
| tripleo_container_manage_concurrency | 1 | この変数を使用して、同時に管理するコンテナーの数を設定します。 |
| tripleo_container_manage_config | /var/lib/tripleo-config/ | この変数を使用して、コンテナー設定ディレクトリーへのパスを設定します。 |
| tripleo_container_manage_config_id | tripleo |
この変数を使用して、特定の設定ステップの ID を設定します。たとえば、デプロイメントのステップ 2 のコンテナーを管理するには、この値を |
| tripleo_container_manage_config_patterns | *.json | この変数を使用して、コンテナー設定ディレクトリーの設定ファイルを識別する bash 正規表現を設定します。 |
| tripleo_container_manage_debug | false |
この変数を使用して、デバッグモードを有効または無効にします。特定の一度限りの設定でコンテナーを実行する場合、コンテナーのライフサイクルを管理するコンテナーコマンドを出力する場合、またはテストおよび検証目的で操作を行わずにコンテナー管理を実施する場合に、 |
| tripleo_container_manage_healthcheck_disable | false | この変数を使用して、ヘルスチェックを有効または無効にします。 |
| tripleo_container_manage_log_path | /var/log/containers/stdouts | この変数を使用して、コンテナーの stdout ログパスを設定します。 |
| tripleo_container_manage_systemd_order | false | この変数を使用して、Ansible による systemd のシャットダウン順序を有効または無効にします。 |
| tripleo_container_manage_systemd_teardown | true | この変数を使用して、使用されなくなったコンテナーのクリーンアップをトリガーします。 |
| tripleo_container_manage_config_overrides | {} | この変数を使用して、コンテナー設定をオーバーライドします。この変数では、値にディクショナリー形式が使用されます。ここで、それぞれのキーはコンテナー名およびオーバーライドするパラメーター (例: コンテナーイメージ、ユーザー) です。この変数は、JSON コンテナー設定ファイルにカスタムオーバーライドを書き込みません。したがって、コンテナーが新たにデプロイ、更新、またはアップグレードされると、JSON 設定ファイルの内容に戻ります。 |
| tripleo_container_manage_valid_exit_code | [] |
この変数を使用して、コンテナーが終了コードを返すかどうかを確認します。この値は一覧にする必要があります (例: |
17.4. tripleo-container-manage ヘルスチェック
Red Hat OpenStack 17.0 までは、コンテナーのヘルスチェックは systemd タイマーで実装され、podman exec を実行して特定のコンテナーが正常かどうかを判断していました。現在は、Podman のネイティブの healthcheck インターフェイスを使用しており、統合と使用がさらに簡単になっています。
コンテナー (keystone など) が正常かどうかを確認するには、次のコマンドを実行します。
$ sudo podman healthcheck run keystone
戻りコードは 0 および “healthy” である必要があります。
"Healthcheck": {
"Status": "healthy",
"FailingStreak": 0,
"Log": [
{
"Start": "2020-04-14T18:48:57.272180578Z",
"End": "2020-04-14T18:48:57.806659104Z",
"ExitCode": 0,
"Output": ""
},
(...)
]
}17.5. tripleo-container-manage デバッグ
tripleo_container_manage Ansible ロールを使用すると、特定のコンテナーに対して特定のアクションを実行できます。これは次の目的で使用できます。
- 特定の 1 回限りの設定でコンテナーを実行します。
- コンテナーのライフサイクル管理用のコンテナーコマンドを出力します。
- Ansible がコンテナーに加えられた変更を出力します。
1 つのコンテナーを管理するには、次の 2 つのことを知っておく必要があります。
- オーバークラウドのデプロイ中のどのステップでコンテナーがデプロイされたか。
- コンテナー設定を含む、生成された JSON ファイルの名前。
以下は、イメージ設定をオーバーライドする ステップ 1 で HAproxy コンテナーを管理する Playbook の例です。
- hosts: localhost
become: true
tasks:
- name: Manage step_1 containers using tripleo-ansible
block:
- name: "Manage HAproxy container at step 1 with tripleo-ansible"
include_role:
name: tripleo_container_manage
vars:
tripleo_container_manage_config_patterns: 'haproxy.json'
tripleo_container_manage_config: "/var/lib/tripleo-config/container-startup-config/step_1"
tripleo_container_manage_config_id: "tripleo_step1"
tripleo_container_manage_clean_orphans: false
tripleo_container_manage_config_overrides:
haproxy:
image: quay.io/tripleoRed_Hat_OpenStack_Platform-17.0-Director_Installation_and_Usage.entos9/centos-binary-haproxy:hotfix
Ansible が check mode で実行されている場合に、コンテナーは削除または作成されませんが、Playbook の実行の最後にコマンドのリストが表示され、Playbook で出される可能性のある結果が示されます。これはデバッグに役立ちます。
$ ansible-playbook haproxy.yaml --check
diff mode を追加すると、Ansible によってコンテナーに加えられた変更が表示されます。
$ ansible-playbook haproxy.yaml --check --diff
tripleo_container_manage_clean_orphans パラメーターはオプションです。false に設定できます。これは、固有の config_id が割り当てられた、孤立したコンテナーが削除されないことを意味します。このパラメーターを使用して、config_id が同じ、別の実行中のコンテナーに影響を与えずに、1 つのコンテナーを管理できます。
tripleo_container_manage_config_overrides パラメーターはオプションであり、イメージやコンテナーユーザーなどの特定のコンテナー属性をオーバーライドするために使用できます。このパラメーターは、コンテナー名とオーバーライドするパラメーターを使用してディクショナリーを作成します。これらのパラメーターは存在する必要があり、TripleO Heat テンプレートでコンテナー設定を定義します。
ディクショナリーは JSON ファイルのオーバーライドを更新しないことに注意してください。そのため、更新またはアップグレードが実行された場合に、コンテナーは JSON ファイルの設定で再構成されます。
第18章 検証フレームワークの使用
Red Hat OpenStack Platform (RHOSP) には検証フレームワークが含まれており、アンダークラウドおよびオーバークラウドの要件と機能の検証に使用することができます。フレームワークには、以下に示す 2 つの検証種別が含まれます。
-
validationコマンドセットを使用して実行する手動の Ansible ベースの検証。 - インフライトの自動検証: デプロイメントプロセス中に実行されます。
実行する検証を理解し、環境に関係のない検証をスキップする必要があります。たとえば、事前デプロイメントの検証には、どこでも TLS のテストが含まれます。環境を TLS 用に設定する予定がない場合、どこでも、このテストは失敗します。validation run コマンドで --validation オプションを使用して、環境に応じて検証を調整します。
18.1. Ansible ベースの検証
Red Hat OpenStack Platform (RHOSP) director のインストール時に、director は openstack-tripleo-validations パッケージから Playbook のセットもインストールします。それぞれの Playbook には、特定のシステム要件のテストおよびグループが含まれます。このグループを使用して、OpenStack Platform のライフサイクル中の特定のステージにタグ付けされた一連のテストを実施することができます。
no-op- no-op (操作なし) タスクを実行してワークフローが正しく機能していることを確かめる検証。これらの検証は、アンダークラウドとオーバークラウドの両方で実行されます。
prep-
アンダークラウドノードのハードウェア設定を確認する検証。
openstack undercloud installコマンドを実行する前に、これらの検証を実行します。 openshift-on-openstack- 環境が要件を満たし OpenShift on OpenStack をデプロイできることを確認する検証
pre-introspection- Ironic Inspector を使用するノードのイントロスペクション前に実行する検証
pre-deployment-
openstack overcloud deployコマンドの前に実行する検証 post-deployment- オーバークラウドのデプロイメントが完了した後に実行する検証
pre-upgrade- アップグレード前に RHOSP デプロイメントを検証するための検証。
post-upgrade- アップグレード後に RHOSP デプロイメントを検証するための検証。
18.2. 検証設定ファイルの変更
検証設定ファイルは、検証の実行とリモートマシン間の通信のあらゆる側面を制御するために編集できる .ini ファイルです。
次のいずれかの方法で、デフォルトの設定値を変更できます。
- デフォルトの /etc/validations.cfg ファイルを編集します。
-
デフォルトの
/etc/validations.cfgファイルの独自のコピーを作成して編集し、CLI から--config引数を使用して渡します。設定ファイルの独自のコピーを作成する場合は、--configを使用して、実行のたびに CLI でこのファイルを指定します。
デフォルトでは、検証設定ファイルの場所は /etc/validation.cfg です。
設定ファイルを正しく編集していることを確認してください。そうしないと、検証が次のようなエラーで失敗する可能性があります。
- 検出されない検証
- 異なる場所に書き込まれたコールバック
- 誤って解析されたログ
前提条件
- 環境を検証する方法を完全に理解している。
手順
オプション: 編集用に検証設定ファイルのコピーを作成します。
-
/etc/validation.cfgをホームディレクトリーにコピーします。 - 新しい設定ファイルに必要な編集を加えます。
-
検証コマンドを実行します。
$ validation run --config <configuration-file>
<configuration-file> は、使用する設定ファイルへのファイルパスに置き換えます。
注記検証を実行すると、出力の
Reasons列は 79 文字に制限されます。検証結果を完全に表示するには、検証ログファイルを表示します。
18.3. 検証の一覧表示
検証リスト コマンドを実行して、利用可能なさまざまな種類の検証を一覧表示します。
手順
source コマンドで
stackrcファイルを読み込みます。$ source ~/stackrc
検証リストコマンドを実行します。すべての検証を一覧表示するには、オプションを設定せずにコマンドを実行します。
$ validation list
グループの検証を一覧表示するには、
--groupオプションを指定してコマンドを実行します。$ validation list --group prep
オプションの完全なリストについては、validation list --help を実行してください。
18.4. 検証の実行
検証または検証グループを実行するには、validation run コマンドを使用します。オプションの完全なリストを表示するには、validation run --help コマンドを使用します。
検証を実行すると、出力の Reasons 列は 79 文字に制限されます。検証結果を完全に表示するには、検証ログファイルを表示します。
手順
stackrcファイルを取得します。$ source ~/stackrc
tripleo-ansible-inventory.yamlという静的インベントリーファイルを検証します。$ validation run --group pre-introspection -i tripleo-ansible-inventory.yaml
注記インベントリーファイルは、スタンドアロンまたはアンダークラウドデプロイメントの場合は
~/tripleo-deploy/<stack>ディレクトリー、オーバークラウドデプロイメントの場合は~/overcloud-deploy/<stack>ディレクトリーにあります。検証実行コマンドを入力します。単一の検証を実行するには、
--validationオプションで検証の名前を指定してコマンドを入力します。たとえば、各ノードのメモリー要件を確認するには、--validation check-ramを入力します。$ validation run --validation check-ram
複数の特定の検証を実行するには、実行する検証のコンマ区切りリストとともに
--validationオプションを使用します。使用可能な検証のリストを表示する方法の詳細については、Listing validations を参照してください。グループのすべての検証を実行するには、
--groupオプションを指定してコマンドを入力します。$ validation run --group prep
特定の検証からの詳細な出力を表示するには、レポートからの特定の検証 UUID に対して
validation history get --fullコマンドを実行します。$ validation history get --full <UUID>
18.5. 検証の作成
validation init コマンドを使用して検証を作成できます。コマンドを実行すると、新しい検証用の基本テンプレートが作成されます。要件に合わせて新しい検証ロールを編集できます。
Red Hat は、ユーザー作成の検証をサポートしていません。
前提条件
- 環境を検証する方法を完全に理解している。
- コマンドを実行するディレクトリーへのアクセス権がある。
手順
検証を作成します。
$ validation init <my-new-validation>
<my-new-validation>は、新しい検証の名前に置き換えます。このコマンドを実行すると、次のディレクトリーとサブディレクトリーが作成されます。
/home/stack/community-validations ├── library ├── lookup_plugins ├── playbooks └── roles
注記The Community Validations are disabled by default というエラーメッセージが表示された場合は、検証設定ファイルで
enable_community_validationsパラメーターがTrueに設定されていることを確認してください。このファイルのデフォルトの名前と場所は/etc/validation.cfgです。
- 要件に合わせてロールを編集します。
関連情報
18.6. 検証履歴の表示
検証または検証グループの実行後に、director は各検証の結果を保存します。validation history list コマンドを使用して、過去の検証結果を表示します。
前提条件
- 検証または検証グループを実行している。
手順
-
アンダークラウドホストに
stackユーザーとしてログインします。 stackrcファイルを取得します。$ source ~/stackrc
すべての検証または最新の検証のリストを表示できます。
すべての検証の一覧を表示します。
$ validation history list
--validationオプションを使用して、特定の検証タイプの履歴を表示します。$ validation history get --validation <validation-type>
- <validation-type> は、検証のタイプ (ntp など) に置き換えます。
特定の検証 UUID のログを表示します。
$ validation show run --full 7380fed4-2ea1-44a1-ab71-aab561b44395
関連情報
18.7. 検証フレームワークのログ形式
検証または検証グループの実行後に、director は各検証の JSON 形式のログを /var/logs/validations ディレクトリーに保存します。ファイルを手動で表示するか、validation history get --full コマンドを使用して、特定の検証 UUID のログを表示できます。
それぞれの検証ログファイルは、特定の形式に従います。
<UUID>_<Name>_<Time>- UUID
- 検証用の Ansible UUID
- 名前
- 検証の Ansible 名
- Time
- 検証を実行した時の開始日時
それぞれの検証ログには、3 つの主要部分が含まれます。
plays
plays セクションには、検証の一部として director が実行したタスクに関する情報が含まれます。
play-
プレイはタスクのグループです。それぞれの
playセクションには、開始/終了時刻、期間、プレイのホストグループ、ならびに検証 ID およびパス等の、特定のタスクグループに関する情報が含まれます。 tasks-
検証を行うために director が実行する個別の Ansible タスク。それぞれの
tasksセクションにはhostsセクションが含まれ、それぞれの個別ホストで生じたアクションおよびアクションの実行結果が含まれます。tasksセクションにはtaskセクションも含まれ、これにはタスクの期間が含まれます。
stats
stats セクションには、各ホストで実施した全タスクの結果の基本概要 (成功したタスクおよび失敗したタスク等) が含まれます。
validation_output
検証中にいずれかのタスクが失敗したか、警告メッセージが発行された場合、validation_output にその失敗または警告の出力が含まれます。
18.8. 検証フレームワークのログ出力形式
検証フレームワークのデフォルト動作では、検証ログを JSON 形式で保存します。ログの出力は、ANSIBLE_STDOUT_CALLBACK 環境変数を使用して変更できます。
検証の出力ログ形式を変更するには、検証を実行し、--extra-env-vars ANSIBLE_STDOUT_CALLBACK=<callback> オプションを追加します。
$ validation run --extra-env-vars ANSIBLE_STDOUT_CALLBACK=<callback> --validation check-ram
-
<callback>を Ansible 出力コールバックに置き換えます。標準的な Ansible 出力コールバックの一覧を表示するには、以下のコマンドを実行します。
$ ansible-doc -t callback -l
検証フレームワークには、以下の追加のコールバックが含まれます。
validation_json-
フレームワークは、JSON 形式の検証結果をログファイルとして
/var/logs/validationsに保存します。これは、検証フレームワークのデフォルトコールバックです。 validation_stdout- フレームワークは、画面に JSON 形式の検証結果を表示します。
http_jsonフレームワークは、JSON 形式の検証結果を外部ロギングサーバーに送信します。このコールバック用に、追加の環境変数も追加する必要があります。
HTTP_JSON_SERVER- 外部サーバーの URL
HTTP_JSON_PORT- 外部サーバーの API エントリーポイントのポート。デフォルトポートは 8989 です。
追加の
--extra-env-varsオプションを使用して、これらの環境変数を設定します。$ validation run --extra-env-vars ANSIBLE_STDOUT_CALLBACK=http_json \ --extra-env-vars HTTP_JSON_SERVER=http://logserver.example.com \ --extra-env-vars HTTP_JSON_PORT=8989 \ --validation check-ram重要http_jsonコールバックを使用する前に、ansible.cfgファイルのcallback_whitelistパラメーターにhttp_jsonを追加する必要があります。callback_whitelist = http_json
18.9. インフライト検証
Red Hat OpenStack Platform (RHOSP) では、コンポーザブルサービスのテンプレートに、インフライト検証が含まれています。インフライト検証により、オーバークラウドのデプロイメントプロセスの主要ステップにおけるサービスの動作ステータスを確認します。
インフライト検証は、デプロイメントプロセスの一部として自動的に実行されます。一部のインフライト検証は、openstack-tripleo-validations パッケージからのロールも使用します。
第19章 オーバークラウドノードのスケーリング
この機能の内容は、本リリースでは ドキュメントプレビュー として提供されているため、Red Hat で完全には検証していません。テスト用にのみ使用し、実稼働環境では使用しないでください。
オーバークラウドの作成後にノードを追加または削除する場合は、オーバークラウドを更新する必要があります。
オーバークラウドからノードを削除する場合は、openstack server delete を使用しないでください。本項の手順に従って、適切にノードの削除/置き換えを行ってください。
オーバークラウドノードのスケールアウトまたは削除を開始する前に、ベアメタルノードがメンテナーンスモードに設定されていないことを確認してください。
以下の表を使用して、各ノード種別のスケーリングに対するサポートを判断してください。
表19.1 各ノード種別のスケーリングサポート
| ノード種別 | スケールアップ | スケールダウン | 備考 |
| コントローラー | 非対応 | 非対応 | 20章コントローラーノードの置き換え に記載の手順を使用して、コントローラーノードを置き換えることができます。 |
| Compute | 対応 | 対応 | |
| Ceph Storage ノード | 対応 | 非対応 | オーバークラウドを最初に作成する際に Ceph Storage ノードを 1 つ以上設定する必要があります。 |
| オブジェクトストレージノード | 対応 | 対応 |
オーバークラウドをスケーリングする前に、空き領域が少なくとも 10 GB あることを確認してください。この空き領域は、イメージの変換やノードのプロビジョニングプロセスのキャッシュに使用されます。
19.1. オーバークラウドへのノード追加
オーバークラウドにノードを追加できます。
Red Hat OpenStack Platform の新規インストールには、セキュリティーエラータやバグ修正などの特定の更新が含まれていません。その結果、Red Hat Customer Portal または Red Hat Satellite Server を使用する接続環境をスケールアップすると、RPM 更新は新しいノードに適用されません。最新の更新をオーバークラウドノードに適用するには、以下のいずれかを実行する必要があります。
- スケールアウト操作後にノードのオーバークラウド更新を完了します。
-
virt-customizeツールを使用して、スケールアウト操作の前にパッケージをベースのオーバークラウドイメージに変更します。詳細は、Red Hat ナレッジベースで Modifying the Red Hat Linux OpenStack Platform Overcloud Image with virt-customize のソリューションを参照してください。
手順
登録する新規ノードの詳細を記載した新しい JSON ファイル (
newnodes.json) を作成します。{ "nodes":[ { "mac":[ "dd:dd:dd:dd:dd:dd" ], "cpu":"4", "memory":"6144", "disk":"40", "arch":"x86_64", "pm_type":"ipmi", "pm_user":"admin", "pm_password":"p@55w0rd!", "pm_addr":"192.168.24.207" }, { "mac":[ "ee:ee:ee:ee:ee:ee" ], "cpu":"4", "memory":"6144", "disk":"40", "arch":"x86_64", "pm_type":"ipmi", "pm_user":"admin", "pm_password":"p@55w0rd!", "pm_addr":"192.168.24.208" } ] }新しいノードを登録します。
$ source ~/stackrc (undercloud)$ openstack overcloud node import newnodes.json
新しいノードごとにイントロスペクションプロセスを開始します。
(undercloud)$ openstack overcloud node introspect \ --provide <node_1> [node_2] [node_n]
-
--provideオプションを使用して、イントロスペクション後に指定されたすべてのノードをavailable状態にリセットします。 -
<node_1>、[node_2]、および[node_n]までの全ノードを、イントロスペクトする各ノードの UUID に置き換えます。
-
新しいノードごとにイメージのプロパティーを設定します。
(undercloud)$ openstack overcloud node configure <node>
19.2. ベアメタルノードのスケールアップ
既存オーバークラウドのベアメタルノード数を増やすには、overcloud-baremetal-deploy.yaml ファイルのノード数を増やして、オーバークラウドを再デプロイします。
前提条件
- 新しいベアメタルノードが登録され、イントロスペクトされ、プロビジョニングとデプロイメントに使用できる。詳細については、オーバークラウドのノードの登録 と ベアメタルノードハードウェアのインベントリーの作成 を参照してください。
手順
source コマンドで
stackrcアンダークラウド認証情報ファイルを読み込みます。$ source ~/stackrc
-
ベアメタルノードのプロビジョニングに使用する
overcloud-baremetal-deploy.yamlノード定義ファイルを開きます。 スケールアップするロールの
countパラメーターを増やします。たとえば、以下の設定では、Object Storage ノード数を 4 に増やします。- name: Controller count: 3 - name: Compute count: 10 - name: ObjectStorage count: 4
オプション: 新規ノードに予測可能なノード配置を設定します。たとえば、以下の設定を使用して、
node03に新しい Object Storage ノードをプロビジョニングします。- name: ObjectStorage count: 4 instances: - hostname: overcloud-objectstorage-0 name: node00 - hostname: overcloud-objectstorage-1 name: node01 - hostname: overcloud-objectstorage-2 name: node02 - hostname: overcloud-objectstorage-3 name: node03- オプション: 新しいノードに割り当てるその他の属性を定義します。ノード定義ファイルでノード属性を設定するために使用できるプロパティーについて詳しくは、ベアメタルノードのプロビジョニング属性 を参照してください。
-
Object Storage サービス (swift) とディスク全体のオーバークラウドイメージ
overcloud-hardened-uefi-fullを使用する場合に、ディスクのサイズと/varおよび/srvのストレージ要件に基づいて/srvパーティションのサイズを設定します。詳細は、Object Storage サービスのディスクパーティション全体の設定 を参照してください。 オーバークラウドノードをプロビジョニングします。
(undercloud)$ openstack overcloud node provision \ --stack <stack> \ --output <deployment_file> \ /home/stack/templates/overcloud-baremetal-deploy.yaml
-
<stack>を、ベアメタルノードがプロビジョニングされるスタックの名前に置き換えます。指定しない場合、デフォルトはovercloudです。 -
<deployment_file>は、デプロイメントコマンドに含めるために生成する heat 環境ファイルの名前に置き換えます (例:/home/stack/templates/overcloud-baremetal-deployed.yaml)。
-
別のターミナルでプロビジョニングの進捗をモニターリングします。プロビジョニングが成功すると、ノードの状態が
availableからactiveに変わります。(undercloud)$ watch openstack baremetal node list
生成された
overcloud-baremetal-deployed.yamlファイルを他の環境ファイルと一緒にスタックに追加し、オーバークラウドをデプロイします。(undercloud)$ openstack overcloud deploy --templates \ -e [your environment files] \ -e /home/stack/templates/overcloud-baremetal-deployed.yaml \ --deployed-server \ --disable-validations \ ...
19.3. ベアメタルノードのスケールダウン
オーバークラウド内のベアメタルノードの数を縮小するには、ノード定義ファイルでスタックから削除するノードにタグを付け、オーバークラウドを再デプロイしてから、オーバークラウドからベアメタルノードを削除します。
前提条件
- アンダークラウドの正常なインストール。詳細は、Installing director on the undercloud を参照してください。
- オーバークラウドの正常なデプロイメント。詳細は、プリプロビジョニングされたノードを使用した基本的なオーバークラウドの設定 を参照してください。
Object Storage ノードを置き換える場合は、削除するノードから新しい置き換えノードにデータを複製します。新しいノードでレプリケーションのパスが完了するまで待機します。
/var/log/swift/swift.logファイルで複製パスの進捗を確認することができます。パスが完了すると、Object Storage サービス (swift) は、以下の例のようにエントリーをログに追加します。Mar 29 08:49:05 localhost object-server: Object replication complete. Mar 29 08:49:11 localhost container-server: Replication run OVER Mar 29 08:49:13 localhost account-server: Replication run OVER
手順
source コマンドで
stackrcアンダークラウド認証情報ファイルを読み込みます。$ source ~/stackrc
-
スケールダウンするロールについて、
overcloud-baremetal-deploy.yamlファイルのcountパラメーターの数を減らします。 -
スタックから削除する各ノードの
hostnameとnameを定義します (ロールのinstances属性で定義されていない場合)。 削除するノードに属性
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オーバークラウドの再デプロイ後、
provisioned: false属性で定義したノードがスタックには存在しなくなります。ただし、これらのノードは provisioned の状態で稼働したままです。注記スタックから一時的にノードを削除するには、属性
provisioned: falseでオーバークラウドをデプロイし、属性provisioned: trueでオーバークラウドを再デプロイして、ノードをスタックに戻します。オーバークラウドからノードを削除します。
(undercloud)$ openstack overcloud node delete \ --stack <stack> \ --baremetal-deployment /home/stack/templates/overcloud-baremetal-deploy.yaml
<stack>を、ベアメタルノードがプロビジョニングされるスタックの名前に置き換えます。指定しない場合、デフォルトはovercloudです。注記スタックから削除するノードを、
openstack overcloud node deleteコマンドのコマンド引数に含めないでください。
オーバークラウドノードをプロビジョニングして、デプロイメントコマンドに含める 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)。
-
プロビジョニングコマンドによって生成された
overcloud-baremetal-deployed.yamlファイルを他の環境ファイルと一緒にスタックに追加し、オーバークラウドをデプロイします。(undercloud)$ openstack overcloud deploy \ ... -e /usr/share/openstack-tripleo-heat-templates/environments/deployed-server-environment.yaml \ -e /home/stack/templates/overcloud-baremetal-deployed.yaml \ --deployed-server \ --disable-validations \ ...
19.4. コンピュートノードの削除または交換
状況によっては、オーバークラウドからコンピュートノードを削除する必要があります。たとえば、問題のあるコンピュートノードを置き換える必要がある場合などです。コンピュートノードを削除すると、スケールアウト操作中にインデックスが再利用されないように、ノードのインデックスがデフォルトで拒否リストに追加されます。
オーバークラウドデプロイメントからノードを削除した後、削除されたコンピュートノードを置き換えることができます。
前提条件
削除するノードでは、ノードが新しいインスタンスをスケジュールできないようにするために、コンピュートサービスが無効になっています。コンピュートサービスが無効になっていることを確認するには、次のコマンドを使用します。
(overcloud)$ openstack compute service list
コンピュートサービスが無効になっていない場合は、無効にします。
(overcloud)$ openstack compute service set <hostname> nova-compute --disable
ヒント--disable-reasonオプションを使用して、サービスを無効にする理由についての簡単な説明を追加します。これは、コンピュートサービスを再デプロイする場合に役立ちます。- コンピュートノードのワークロードは、他のコンピュートノードに移行されました。詳しくは、コンピュートノード間の仮想マシンインスタンスの移行 を参照してください。
インスタンス HA が有効になっている場合は、次のいずれかのオプションを選択します。
-
コンピュートノードにアクセスできる場合は、
rootユーザーとしてコンピュートノードにログインし、shutdown -h nowコマンドを使用してクリーンシャットダウンを実行します。 コンピュートノードにアクセスできない場合は、
rootユーザーとしてコントローラーノードにログインし、コンピュートノードの STONITH デバイスを無効にして、ベアメタルノードをシャットダウンします。[root@controller-0 ~]# pcs stonith disable <stonith_resource_name> [stack@undercloud ~]$ source stackrc [stack@undercloud ~]$ openstack baremetal node power off <UUID>
-
コンピュートノードにアクセスできる場合は、
手順
source コマンドでアンダークラウド設定を読み込みます。
(overcloud)$ source ~/stackrc
-
スケールダウンするロールについて、
overcloud-baremetal-deploy.yamlファイルのcountパラメーターの数を減らします。 -
スタックから削除する各ノードの
hostnameとnameを定義します (ロールのinstances属性で定義されていない場合)。 削除するノードに属性
provisioned: falseを追加します。たとえば、スタックからノードovercloud-compute-1を削除するには、overcloud-baremetal-deploy.yamlファイルに以下のスニペットを追加します。- name: Compute count: 2 instances: - hostname: overcloud-compute-0 name: node00 - hostname: overcloud-compute-1 name: node01 # Removed from cluster due to disk failure provisioned: false - hostname: overcloud-compute-2 name: node02オーバークラウドの再デプロイ後、
provisioned: false属性で定義したノードがスタックには存在しなくなります。ただし、これらのノードは provisioned の状態で稼働したままです。注記スタックから一時的にノードを削除する場合は、オーバークラウドを属性
provisioned: falseでデプロイしてから属性provisioned: trueで再デプロイすることで、ノードをスタックに戻すことができます。オーバークラウドからノードを削除します。
(undercloud)$ openstack overcloud node delete \ --stack <stack> \ --baremetal-deployment /home/stack/templates/overcloud-baremetal-deploy.yaml
<stack>を、ベアメタルノードがプロビジョニングされるスタックの名前に置き換えます。指定しない場合、デフォルトはovercloudです。注記スタックから削除するノードを、
openstack overcloud node deleteコマンドのコマンド引数に含めないでください。
オーバークラウドノードをプロビジョニングして、デプロイメントコマンドに含める heat 環境ファイルを更新して生成します。
(undercloud)$ openstack overcloud node provision \ --stack <stack> \ --output <deployment_file> \ /home/stack/templates/overcloud-baremetal-deploy.yaml
-
<stack>を、ベアメタルノードがプロビジョニングされるスタックの名前に置き換えます。指定しない場合、デフォルトはovercloudです。 -
<deployment_file>は、デプロイメントコマンドに含めるために生成する heat 環境ファイルの名前に置き換えます (例:/home/stack/templates/overcloud-baremetal-deployed.yaml)。
-
インスタンス HA が有効な場合は、以下の操作を実行します。
ノードの Pacemaker リソースをクリーンアップします。
$ sudo pcs resource delete <scaled_down_node> $ sudo cibadmin -o nodes --delete --xml-text '<node id="<scaled_down_node>"/>' $ sudo cibadmin -o fencing-topology --delete --xml-text '<fencing-level target="<scaled_down_node>"/>' $ sudo cibadmin -o status --delete --xml-text '<node_state id="<scaled_down_node>"/>' $ sudo cibadmin -o status --delete-all --xml-text '<node id="<scaled_down_node>"/>' --force
-
<scaled_down_node>は、削除したノードの名前に置き換えます。
-
ノードの STONITH デバイスを削除します。
$ sudo pcs stonith delete <device-name>
- オーバークラウドデプロイメントで削除されたコンピュートノードを置き換える場合は、Replacing a removed Compute node を参照してください。
19.4.1. コンピュートノードを手動で削除する
openstack overcloud node delete コマンドが到達不能なノードのために失敗した場合は、オーバークラウドからのコンピュートノードの削除を手動で完了する必要があります。
前提条件
-
コンピュートノードの削除または置換 手順を実行すると、ステータス
UPDATE_FAILEDが返されました。
手順
openstack tripleo launch heatコマンドを使用して、エフェメラル Heat プロセスを起動します。(undercloud)$ openstack tripleo launch heat --heat-dir /home/stack/overcloud-deploy/overcloud/heat-launcher --restore-db
このコマンドは、Heat プロセスを起動した後に終了し、この Heat プロセスは podman Pod としてバックグラウンドで実行され続けます。
podman pod psコマンドを使用して、ephemeral-heatプロセスが実行されていることを確認します。(undercloud)$ sudo podman pod ps POD ID NAME STATUS CREATED INFRA ID # OF CONTAINERS 958b141609b2 ephemeral-heat Running 2 minutes ago 44447995dbcf 3
exportコマンドを使用して、OS_CLOUD環境をエクスポートします。(undercloud)$ export OS_CLOUD=heat
インストールされているスタックを一覧表示するには、
openstack stack listコマンドを使用します。(undercloud)$ openstack stack list +--------------------------------------+------------+---------+-----------------+----------------------+--------------+ | ID | Stack Name | Project | Stack Status | Creation Time | Updated Time | +--------------------------------------+------------+---------+-----------------+----------------------+--------------+ | 761e2a54-c6f9-4e0f-abe6-c8e0ad51a76c | overcloud | admin | CREATE_COMPLETE | 2022-08-29T20:48:37Z | None | +--------------------------------------+------------+---------+-----------------+----------------------+--------------+
手動で削除するノードの UUID を特定します。
(undercloud)$ openstack baremetal node list
削除するノードをメンテナーンスモードに移動します。
(undercloud)$ openstack baremetal node maintenance set <node_uuid>
- コンピュートサービスがその状態をベアメタルサービスと同期するのを待ちます。これには最大 4 分かかる場合があります。
source コマンドでオーバークラウド設定を読み込みます。
(undercloud)$ source ~/overcloudrc
削除したノードのネットワークエージェントを削除します。
(overcloud)$ for AGENT in $(openstack network agent list --host <scaled_down_node> -c ID -f value) ; do openstack network agent delete $AGENT ; done
-
<scaled_down_node>を、削除するノードの名前に置き換えます。
-
ノードが新しいインスタンスをスケジュールできないように、オーバークラウド上の削除されたノードでコンピュートサービスが無効になっていることを確認します。
(overcloud)$ openstack compute service list
コンピュートサービスが無効になっていない場合は、無効にします。
(overcloud)$ openstack compute service set <hostname> nova-compute --disable
ヒント--disable-reasonオプションを使用して、サービスを無効にする理由についての簡単な説明を追加します。これは、コンピュートサービスを再デプロイする場合に役立ちます。削除した Compute サービスを、Placement サービスのリソースプロバイダーから除外します。
(overcloud)$ openstack resource provider list (overcloud)$ openstack resource provider delete <uuid>
source コマンドでアンダークラウド設定を読み込みます。
(overcloud)$ source ~/stackrc
スタックからコンピュートノードを削除します。
(undercloud)$ openstack overcloud node delete --stack <overcloud> <node>
-
<overcloud>は、オーバークラウドスタックの名前または UUID に置き換えてください。 <node>を、削除するコンピュートノードのコンピュートサービスホスト名または UUID に置き換えます。注記ノードの電源がすでにオフになっている場合、このコマンドは
WARNINGメッセージを返します。Ansible failed, check log at `~/ansible.log` WARNING: Scale-down configuration error. Manual cleanup of some actions may be necessary. Continuing with node removal.
このメッセージは無視しても問題ありません。
-
- オーバークラウドノードが削除されるのを待ちます。
ノードの削除が完了したら、オーバークラウドスタックのステータスを確認します。
(undercloud)$ openstack stack list
表19.2 結果
ステータス 説明 UPDATE_COMPLETE削除操作は正常に完了しました。
UPDATE_FAILED削除操作が失敗しました。
メンテナーンスモード中にオーバークラウドノードの削除に失敗した場合は、問題はハードウェアにある可能性があります。
インスタンス HA が有効な場合は、以下の操作を実行します。
ノードの Pacemaker リソースをクリーンアップします。
$ sudo pcs resource delete <scaled_down_node> $ sudo cibadmin -o nodes --delete --xml-text '<node id="<scaled_down_node>"/>' $ sudo cibadmin -o fencing-topology --delete --xml-text '<fencing-level target="<scaled_down_node>"/>' $ sudo cibadmin -o status --delete --xml-text '<node_state id="<scaled_down_node>"/>' $ sudo cibadmin -o status --delete-all --xml-text '<node id="<scaled_down_node>"/>' --force
ノードの STONITH デバイスを削除します。
$ sudo pcs stonith delete <device-name>
オーバークラウドで削除されたコンピュートノードを置き換えない場合は、ノード数を含む環境ファイルの
ComputeCountパラメーターを減らします。通常、このファイルの名前はovercloud-baremetal-deployed.yamlです。たとえば、ノードを 1 つ削除する場合、ノード数を 4 から 3 に減らします。parameter_defaults: ... ComputeCount: 3 ...
ノード数を減らすと、
openstack overcloud deployを実行しても director は新規ノードをプロビジョニングしません。オーバークラウドデプロイメントで削除されたコンピュートノードを置き換える場合は、Replacing a removed Compute node を参照してください。
19.4.2. 削除されたコンピュートノードの交換
オーバークラウドデプロイメントで削除されたコンピュートノードを置き換えるには、新しいコンピュートノードを登録して検査するか、削除したコンピュートノードを再度追加します。また、ノードをプロビジョニングするようにオーバークラウドを設定する必要があります。
手順
オプション: 削除されたコンピュートノードのインデックスを再利用するには、コンピュートノードが削除されたときに拒否リストを置き換えるロールの
RemovalPoliciesModeパラメーターとRemovalPoliciesパラメーターを設定します。parameter_defaults: <RoleName>RemovalPoliciesMode: update <RoleName>RemovalPolicies: [{'resource_list': []}]削除されたコンピュートノードを置き換えます。
- 新しいコンピュートノードを追加するには、新しいノードを登録、検査、およびタグ付けして、プロビジョニングの準備をします。詳細は、オーバークラウドの設定とデプロイ を参照してください。
手動で削除したコンピュートノードを再度追加するには、ノードをメンテナーンスモードから削除します。
(undercloud)$ openstack baremetal node maintenance unset <node_uuid>
-
既存のオーバークラウドのデプロイに使用した
openstack overcloud deployコマンドを再実行します。 - デプロイメントプロセスが完了するまで待ちます。
ディレクターが新しいコンピュートノードを正常に登録したことを確認します。
(undercloud)$ openstack baremetal node list
手順 1 を実行して、
update用のロールのRemovalPoliciesModeを設定した場合は、ロールのRemovalPoliciesModeをデフォルト値のappendにリセットして、コンピュートノードが削除されたときにコンピュートノードインデックスを現在の拒否リストに追加する必要があります。parameter_defaults: <RoleName>RemovalPoliciesMode: append
-
既存のオーバークラウドのデプロイに使用した
openstack overcloud deployコマンドを再実行します。
19.5. Ceph Storage ノードの置き換え
director を使用して、director で作成したクラスター内の Ceph Storage ノードを置き換えることができます。詳細は、director ガイドとともに Red Hat Ceph Storage および Red Hat OpenStack Platform をデプロイする を参照してください。
19.6. スキップデプロイ識別子の使用
スタック更新操作中に、puppet はデフォルトで、すべてのマニフェストを再適用します。その結果、必要のない操作に時間がかかることがあります。
デフォルトの操作をオーバーライドするには、skip-deploy-identifier オプションを使用します。
openstack overcloud deploy --skip-deploy-identifier
デプロイメントコマンドで DeployIdentifier パラメーターの一意の ID を生成するのを希望しない場合は、このオプションを使用します。ソフトウェア設定のデプロイメントステップは、実際に設定が変更された場合にしか実行されません。このオプションの使用には注意が必要です。特定のロールをスケールアウトする時など、ソフトウェア設定の実行が明らかに不要な場合にしか使用しないでください。
puppet マニフェストまたは hierdata に変更がある場合、--skip-deploy-identifier が指定されている場合でも、puppet はすべてのマニフェストを再適用します。
19.7. ノードのブラックリスト登録
オーバークラウドノードがデプロイメントの更新を受け取らないように除外することができます。これは、新規ノードをスケーリングする場合に、既存のノードがコア heat テンプレートコレクションから更新されたパラメーターセットやリソースを受け取らないように除外するのに役立ちます。つまり、ブラックリストに登録されているノードは、スタック操作の影響を受けなくなります。
ブラックリストを作成するには、環境ファイルの DeploymentServerBlacklist パラメーターを使います。
ブラックリストの設定
DeploymentServerBlacklist パラメーターは、サーバー名のリストです。新たな環境ファイルを作成するか、既存のカスタム環境ファイルにパラメーター値を追加して、ファイルをデプロイメントコマンドに渡します。
parameter_defaults:
DeploymentServerBlacklist:
- overcloud-compute-0
- overcloud-compute-1
- overcloud-compute-2パラメーター値のサーバー名には、実際のサーバーホスト名ではなく、OpenStack Orchestation (heat) で定義されている名前を使用します。
openstack overcloud deploy コマンドで、この環境ファイルを指定します。
$ source ~/stackrc (undercloud) $ openstack overcloud deploy --templates \ -e server-blacklist.yaml \ [OTHER OPTIONS]
heat はリスト内のサーバーをすべてブラックリストし、heat デプロイメントの更新を受け取らないようにします。スタック操作が完了した後には、ブラックリストに登録されたサーバーは以前の状態のままとなります。操作中に os-collect-config エージェントの電源をオフにしたり、停止したりすることもできます。
- ノードをブラックリストに登録する場合には、注意が必要です。ブラックリストを有効にした状態で要求された変更を適用する方法を十分に理解していない限り、ブラックリストは使用しないでください。ブラックリスト機能を使用すると、スタックがハングアップしたり、オーバークラウドが誤って設定されたりする場合があります。たとえば、クラスター設定の変更が Pacemaker クラスターの全メンバーに適用される場合、この変更の間に Pacemaker クラスターのメンバーをブラックリストに登録すると、クラスターが機能しなくなることがあります。
- 更新またはアップグレードの操作中にブラックリストを使わないでください。これらの操作には、特定のサーバーに対する変更を分離するための独自の方法があります。
-
サーバーをブラックリストに追加すると、そのサーバーをブラックリストから削除するまでは、それらのノードにはさらなる変更は適用されません。これには、更新、アップグレード、スケールアップ、スケールダウン、およびノードの置き換えが含まれます。たとえば、新規コンピュートノードを使用してオーバークラウドをスケールアウトする際に既存のコンピュートノードをブラックリストに登録すると、ブラックリストに登録したノードには
/etc/hostsおよび/etc/ssh/ssh_known_hostsに加えられた情報が反映されません。これにより、移行先ホストによっては、ライブマイグレーションが失敗する可能性があります。コンピュートノードのブラックリスト登録が解除される次回のオーバークラウドデプロイメント時に、これらのノードは/etc/hostsおよび/etc/ssh/ssh_known_hostsに加えられた情報で更新されます。/etc/hostsファイルおよび/etc/ssh/ssh_known_hostsファイルは手動で変更しないでください。/etc/hostsファイルおよび/etc/ssh/ssh_known_hostsファイルを変更するには、Clearing the Blacklist セクションで説明するように、オーバークラウドのデプロイコマンドを実行します。
ブラックリストのクリア
その後のスタック操作のためにブラックリストをクリアするには、DeploymentServerBlacklist を編集して空の配列を使用します。
parameter_defaults: DeploymentServerBlacklist: []
DeploymentServerBlacklist パラメーターを削除しないでください。パラメーターを削除すると、オーバークラウドのデプロイメントには、前回保存された値が使用されます。
第20章 コントローラーノードの置き換え
特定の状況では、高可用性クラスター内のコントローラーノードに障害が発生することがあります。その場合は、そのコントローラーノードをクラスターから削除して新しいコントローラーノードに置き換える必要があります。
以下のシナリオの手順を実施して、コントローラーノードを置き換えます。コントローラーノードを置き換えるプロセスでは、openstack overcloud deploy コマンドを実行し、コントローラーノードを置き換えるリクエストでオーバークラウドを更新します。
以下の手順は、高可用性環境にのみ適用されます。コントローラーノード 1 台の場合には、この手順は使用しないでください。
20.1. コントローラー置き換えの準備
オーバークラウドのコントローラーノードを置き換える前に、Red Hat OpenStack Platform 環境の現在の状態をチェックしておくことが重要です。このチェックをしておくと、コントローラーの置き換えプロセス中に複雑な事態が発生するのを防ぐことができます。以下の事前チェックリストを使用して、コントローラーノードの置き換えを実行しても安全かどうかを確認してください。チェックのためのコマンドはすべてアンダークラウドで実行します。
手順
アンダークラウドで、
overcloudスタックの現在の状態をチェックします。$ source stackrc $ openstack overcloud status
overcloudスタックの deployemnt ステータスがDEPLOY_SUCCESSである場合にのみ続行します。データベースクライアントツールをインストールします。
$ sudo dnf -y install mariadb
root ユーザーのデータベースへのアクセス権限を設定します。
$ sudo cp /var/lib/config-data/puppet-generated/mysql/root/.my.cnf /root/.
アンダークラウドデータベースのバックアップを実行します。
$ mkdir /home/stack/backup $ sudo mysqldump --all-databases --quick --single-transaction | gzip > /home/stack/backup/dump_db_undercloud.sql.gz
アンダークラウドに、新規ノードプロビジョニング時のイメージのキャッシュと変換に対応できる 10 GB の空きストレージ領域があることを確認します。
$ df -h
新規コントローラーノード用に IP アドレスを再利用する場合は、古いコントローラーが使用したポートを削除するようにしてください。
$ openstack port delete <port>
コントローラーノードで実行中の Pacemaker の状態をチェックします。たとえば、実行中のコントローラーノードの IP アドレスが 192.168.0.47 の場合には、以下のコマンドで Pacemaker のステータスを表示します。
$ ssh tripleo-admin@192.168.0.47 'sudo pcs status'
この出力には、既存のノードで動作中のサービスおよび障害の発生しているノードで停止しているサービスがすべて表示されます。
オーバークラウド MariaDB クラスターの各ノードで以下のパラメーターをチェックします。
-
wsrep_local_state_comment: Synced wsrep_cluster_size: 2実行中のコントローラーノードで以下のコマンドを使用して、パラメーターをチェックします。以下の例では、コントローラーノードの IP アドレスは、それぞれ 192.168.0.47 と 192.168.0.46 です。
$ for i in 192.168.0.46 192.168.0.47 ; do echo "*** $i ***" ; ssh tripleo-admin@$i "sudo podman exec \$(sudo podman ps --filter name=galera-bundle -q) mysql -e \"SHOW STATUS LIKE 'wsrep_local_state_comment'; SHOW STATUS LIKE 'wsrep_cluster_size';\""; done
-
RabbitMQ のステータスをチェックします。たとえば、実行中のコントローラーノードの IP アドレスが 192.168.0.47 の場合には、以下のコマンドで RabbitMQ のステータスを表示します。
$ ssh tripleo-admin@192.168.0.47 "sudo podman exec \$(sudo podman ps -f name=rabbitmq-bundle -q) rabbitmqctl cluster_status"
running_nodesキーには、障害が発生しているノードは表示されず、稼働中のノード 2 台のみが表示されるはずです。フェンシングが有効な場合は、無効にします。たとえば、実行中のコントローラーノードの IP アドレスが 192.168.0.47 の場合には、以下のコマンドを実行してフェンシングのステータスを確認します。
$ ssh tripleo-admin@192.168.0.47 "sudo pcs property show stonith-enabled"
フェンシングを無効にするには、以下のコマンドを実行します。
$ ssh tripleo-admin@192.168.0.47 "sudo pcs property set stonith-enabled=false"
障害が発生したコントローラーノードにログインし、実行中のすべての
nova_*コンテナーを停止します。$ sudo systemctl stop tripleo_nova_api.service $ sudo systemctl stop tripleo_nova_api_cron.service $ sudo systemctl stop tripleo_nova_compute.service $ sudo systemctl stop tripleo_nova_conductor.service $ sudo systemctl stop tripleo_nova_metadata.service $ sudo systemctl stop tripleo_nova_placement.service $ sudo systemctl stop tripleo_nova_scheduler.service
オプション: virt ドライバーとして Bare Metal サービス (ironic) を使用している場合は、削除するコントローラーに
instances.hostが設定されているベアメタルインスタンスのセルデータベースのサービスエントリーを手動で更新する必要があります。レッドハットサポートにお問い合わせください。注記Bare Metal サービス (ironic) を virt ドライバーとして使用する場合のセルデータベースのこの手動更新は、BZ2017980 が完了するまで、ノードのリバランスを確保するための一時的な回避策です。
20.2. Ceph monitor デーモンの削除
コントローラーノードが Ceph monitor サービスを実行している場合には、以下のステップを完了して、ceph-mon デーモンを削除してください。
クラスターに新しいコントローラーノードを追加すると、新しい Ceph monitor デーモンも自動的に追加されます。
手順
置き換えるコントローラーノードに接続します。
$ ssh tripleo-admin@192.168.0.47
Ceph mon サービスを一覧表示します。
$ sudo systemctl --type=service | grep ceph ceph-4cf401f9-dd4c-5cda-9f0a-fa47fbf12b31@crash.controller-0.service loaded active running Ceph crash.controller-0 for 4cf401f9-dd4c-5cda-9f0a-fa47fbf12b31 ceph-4cf401f9-dd4c-5cda-9f0a-fa47fbf12b31@mgr.controller-0.mufglq.service loaded active running Ceph mgr.controller-0.mufglq for 4cf401f9-dd4c-5cda-9f0a-fa47fbf12b31 ceph-4cf401f9-dd4c-5cda-9f0a-fa47fbf12b31@mon.controller-0.service loaded active running Ceph mon.controller-0 for 4cf401f9-dd4c-5cda-9f0a-fa47fbf12b31 ceph-4cf401f9-dd4c-5cda-9f0a-fa47fbf12b31@rgw.rgw.controller-0.ikaevh.service loaded active running Ceph rgw.rgw.controller-0.ikaevh for 4cf401f9-dd4c-5cda-9f0a-fa47fbf12b31
Ceph mon サービスを停止します。
$ sudo systemtctl stop ceph-4cf401f9-dd4c-5cda-9f0a-fa47fbf12b31@mon.controller-0.service
Ceph mon サービスを無効にします。
$ sudo systemctl disable ceph-4cf401f9-dd4c-5cda-9f0a-fa47fbf12b31@mon.controller-0.service
- 置き換えるコントローラーノードとの接続を終了します。
SSH を使用して、同じクラスター内の別のコントローラーノードに接続します。
$ ssh tripleo-admin@192.168.0.46
Ceph 仕様ファイルは、この手順の後半で変更および適用します。ファイルを操作するには、エクスポートする必要があります。
$ sudo cephadm shell --ceph orch ls --export > spec.yaml
クラスターから monitor を削除します。
$ sudo cephadm shell -- ceph mon remove controller-0 removing mon.controller-0 at [v2:172.23.3.153:3300/0,v1:172.23.3.153:6789/0], there will be 2 monitors
コントローラーノードから切断し、クラスターから削除するコントローラーノードに再度ログインします。
$ ssh tripleo-admin@192.168.0.47
Ceph mgr サービスを一覧表示します。
$ sudo systemctl --type=service | grep ceph ceph-4cf401f9-dd4c-5cda-9f0a-fa47fbf12b31@crash.controller-0.service loaded active running Ceph crash.controller-0 for 4cf401f9-dd4c-5cda-9f0a-fa47fbf12b31 ceph-4cf401f9-dd4c-5cda-9f0a-fa47fbf12b31@mgr.controller-0.mufglq.service loaded active running Ceph mgr.controller-0.mufglq for 4cf401f9-dd4c-5cda-9f0a-fa47fbf12b31 ceph-4cf401f9-dd4c-5cda-9f0a-fa47fbf12b31@rgw.rgw.controller-0.ikaevh.service loaded active running Ceph rgw.rgw.controller-0.ikaevh for 4cf401f9-dd4c-5cda-9f0a-fa47fbf12b31
Ceph mgr サービスを停止します。
$ sudo systemctl stop ceph-4cf401f9-dd4c-5cda-9f0a-fa47fbf12b31@mgr.controller-0.mufglq.service
Ceph mgr サービスを無効にします。
$ sudo systemctl disable ceph-4cf401f9-dd4c-5cda-9f0a-fa47fbf12b31@mgr.controller-0.mufglq.service
cephadmシェルを起動します。$ sudo cephadm shell
コントローラーノードの Ceph mgr サービスがクラスターから削除されていることを確認します。
$ ceph -s cluster: id: b9b53581-d590-41ac-8463-2f50aa985001 health: HEALTH_OK services: mon: 2 daemons, quorum controller-2,controller-1 (age 2h) mgr: controller-2(active, since 20h), standbys: controller1-1 osd: 15 osds: 15 up (since 3h), 15 in (since 3h) data: pools: 3 pools, 384 pgs objects: 32 objects, 88 MiB usage: 16 GiB used, 734 GiB / 750 GiB avail pgs: 384 active+cleanCeph mgr サービスが正常に削除された場合、ノードは一覧表示されません。
Red Hat Ceph Storage 仕様をエクスポートします。
$ ceph orch ls --export > spec.yaml
-
spec.yaml仕様ファイルで、ホストのすべてのインスタンス (controller-0など) をservice_type: monおよびservice_type: mgrから削除します。 Red Hat Ceph Storage 仕様を再適用します。
$ ceph orch apply -i spec.yaml
削除されたホストに Ceph デーモンが残っていないことを確認します。
$ ceph orch ps controller-0
注記デーモンが存在する場合は、次のコマンドを使用してそれらを削除します。
$ ceph orch host drain controller-0
ceph orch host drainコマンドを実行する前に、/etc/cephの内容をバックアップします。ceph orch host drainコマンドを実行した後、内容を復元します。https://bugzilla.redhat.com/show_bug.cgi?id=2153827 が解決されるまで、ceph orch host drainコマンドを実行する前にバックアップする必要があります。Red Hat Ceph Storage クラスターから
controller-0ホストを削除します。$ ceph orch host rm controller-0 Removed host 'controller-0'
cephadm シェルを終了します。
$ exit
関連情報
systemd を使用した Red Hat Ceph Storage サービスの制御の詳細は、Ceph のプロセス管理について を参照してください。
Red Hat Ceph Storage 仕様ファイルの編集と適用の詳細は、サービス仕様を使用した Ceph モニターデーモンのデプロイ を参照してください。
20.3. コントローラーノードを置き換えるためのクラスター準備
ノードを置き換える前に、Pacemaker がノード上で実行されていないことを確認してからそのノードを Pacemaker クラスターから削除するようにしてください。
手順
コントローラーノードの IP アドレス一覧を表示するには、以下のコマンドを実行します。
(undercloud)$ metalsmith -c Hostname -c "IP Addresses" list +------------------------+-----------------------+ | Hostname | IP Addresses | +------------------------+-----------------------+ | overcloud-compute-0 | ctlplane=192.168.0.44 | | overcloud-controller-0 | ctlplane=192.168.0.47 | | overcloud-controller-1 | ctlplane=192.168.0.45 | | overcloud-controller-2 | ctlplane=192.168.0.46 | +------------------------+-----------------------+
ノードにログインし、ペースメーカーのステータスを確認します。Pacemaker が実行中の場合は、
pcs clusterコマンドを使用して Pacemaker を停止します。この例では、overcloud-controller-0で Pacemaker を停止します。(undercloud) $ ssh tripleo-admin@192.168.0.45 "sudo pcs status | grep -w Online | grep -w overcloud-controller-0" (undercloud) $ ssh tripleo-admin@192.168.0.45 "sudo pcs cluster stop overcloud-controller-0"
注記古いノードが物理的に利用できない、または停止している場合には、そのノードでは Pacemaker はすでに停止しているので、この操作を実施する必要はありません。
ノードで Pacemaker を停止したら、Pacemaker クラスターからノードを削除します。以下に示すコマンドの例では、
overcloud-controller-1にログインし、overcloud-controller-0を削除しています。(undercloud) $ ssh tripleo-admin@192.168.0.45 "sudo pcs cluster node remove overcloud-controller-0"
置き換えるノードにアクセスすることができない場合には (ハードウェア障害などの理由により)、
pcsコマンドを実行する際にさらに--skip-offlineおよび--forceオプションを指定して、ノードをクラスターから強制的に削除します。(undercloud) $ ssh tripleo-admin@192.168.0.45 "sudo pcs cluster node remove overcloud-controller-0 --skip-offline --force"
Pacemaker クラスターからノードを削除したら、Pacemaker の既知のホスト一覧からノードを削除します。
(undercloud) $ ssh tripleo-admin@192.168.0.45 "sudo pcs host deauth overcloud-controller-0"
ノードにアクセス可能かどうかにかかわらず、このコマンドを実行することができます。
置き換え後に新しいコントローラーノードで正しい STONITH フェンシングデバイスが使用されるようにするには、以下のコマンドを入力してノードからデバイスを削除します。
(undercloud) $ ssh tripleo-admin@192.168.0.45 "sudo pcs stonith delete <stonith_resource_name>"
-
<stonith_resource_name>は、ノードに対応する STONITH リソースの名前に置き換えます。リソース名には<resource_agent>-<host_mac>形式が使用されます。リソースエージェントおよびホストの MAC アドレスは、fencing.yamlファイルのFencingConfigセクションに記載されています。
-
オーバークラウドデータベースは、置き換え手順の実行中に稼働し続ける必要があります。この手順の実行中に Pacemaker が Galera を停止しないようにするには、実行中のコントローラーノードを選択して、そのコントローラーノードの IP アドレスを使用して、アンダークラウドで以下のコマンドを実行します。
(undercloud) $ ssh tripleo-admin@192.168.0.45 "sudo pcs resource unmanage galera-bundle"
20.4. ブートストラップコントローラーノードの置き換え
ブートストラップ操作に使用するコントローラーノードを置き換え、ノード名を維持するには、以下の手順を実施して、置き換えプロセス後にブートストラップコントローラーノードの名前を設定します。
手順
以下のコマンドを実行して、ブートストラップコントローラーノードの名前を確認します。
ssh tripleo-admin@CONTROLLER_IP "sudo hiera -c /etc/puppet/hiera.yaml pacemaker_short_bootstrap_node_name"
-
CONTROLLER_IPを、任意のアクティブなコントローラーノードの IP アドレスに置き換えます。
-
環境ファイルに
ExtraConfigセクションが含まれているかどうかを確認します。ExtraConfigパラメーターが存在しない場合は、以下の環境ファイル~/templates/bootstrap-controller.yamlを作成し、以下の内容を追加します。parameter_defaults: ExtraConfig: pacemaker_short_bootstrap_node_name: NODE_NAME mysql_short_bootstrap_node_name: NODE_NAMENODE_NAMEを、置き換えプロセス後にブートストラップ操作に使用する既存のコントローラーノードの名前に置き換えます。お使いの環境ファイルに
ExtraConfigパラメーターがすでに含まれている場合は、pacemaker_short_bootstrap_node_nameおよびmysql_short_bootstrap_node_nameパラメーターを設定する行だけを追加します。
ブートストラップコントローラーノード置き換えのトラブルシューティングに関する情報は、アーティクル Replacement of the first controller node fails at step 1 if the same hostname is used for a new node を参照してください。
20.5. コントローラーノードのプロビジョニング解除と削除
コントローラーノードのプロビジョニングを解除して削除するには、次の手順を実行します。
手順
stackrcファイルを取得します。$ source ~/stackrc
overcloud-controller-0ノードの UUID を特定します。(undercloud)$ NODE=$(metalsmith -c UUID -f value show overcloud-controller-0)
ノードをメンテナーンスモードに切り替えます。
$ openstack baremetal node maintenance set $NODE
overcloud-baremetal-deploy.yamlファイルをコピーします。$ cp /home/stack/templates/overcloud-baremetal-deploy.yaml /home/stack/templates/unprovision_controller-0.yaml
unprovision_controller-0.yamlファイルで、コントローラー数を減らして、置き換えるコントローラーノードのプロビジョニングを解除します。この例では、数を3から2に減らします。controller-0ノードをinstancesディクショナリーに移動し、provisionedパラメーターをfalseに設定します。- name: Controller count: 2 hostname_format: controller-%index% defaults: resource_class: BAREMETAL.controller networks: [ ... ] instances: - hostname: controller-0 name: <IRONIC_NODE_UUID_or_NAME> provisioned: false - name: Compute count: 2 hostname_format: compute-%index% defaults: resource_class: BAREMETAL.compute networks: [ ... ]node unprovisionコマンドを実行します。$ openstack overcloud node delete \ --stack overcloud \ --baremetal-deployment /home/stack/templates/unprovision_controller-0.yaml
The following nodes will be unprovisioned: +--------------+-------------------------+--------------------------------------+ | hostname | name | id | +--------------+-------------------------+--------------------------------------+ | controller-0 | baremetal-35400-leaf1-2 | b0d5abf7-df28-4ae7-b5da-9491e84c21ac | +--------------+-------------------------+--------------------------------------+ Are you sure you want to unprovision these overcloud nodes and ports [y/N]?
オプション
ironic ノードを削除します。
$ openstack baremetal node delete <IRONIC_NODE_UUID>
-
IRONIC_NODE_UUIDは、ノードの UUID に置き換えます。
20.6. オーバークラウドへの新しいコントローラーノードのデプロイ
オーバークラウドに新しいコントローラーノードをデプロイするには、以下の手順を実行します。
前提条件
- 新しいコントローラーノードが登録、検査、およびタグ付けされていて、プロビジョニングの準備ができている。詳細は、ベアメタルオーバークラウドノードのプロビジョニング を参照してください。
手順
director にログインし、source コマンドで
stackrc認証情報ファイルを読み込みます。$ source ~/stackrc
元の
overcloud-baremetal-deploy.yaml環境ファイルを使用してオーバークラウドをプロビジョニングします。$ openstack overcloud node provision --stack overcloud --network-config --output /home/stack/templates/overcloud-baremetal-deployed.yaml /home/stack/templates/overcloud-baremetal-deploy.yaml
注記同じスケジューリング、配置、または IP アドレスを使用する場合は
overcloud-baremetal-deploy.yaml環境ファイルを編集できます。instancesセクションで、新しい controller-0 インスタンスのホスト名、名前、およびネットワークを設定します。以下に例を示します。- name: Controller count: 3 hostname_format: controller-%index% defaults: resource_class: BAREMETAL.controller networks: - 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: templates/multiple_nics/multiple_nics_dvr.j2 default_route_network: - external instances: - hostname: controller-0 name: baremetal-35400-leaf1-2 networks: - network: external subnet: external_subnet fixed_ip: 10.0.0.224 - network: internal_api subnet: internal_api_subnet01 fixed_ip: 172.17.0.97 - network: storage subnet: storage_subnet01 fixed_ip: 172.18.0.24 - network: storage_mgmt subnet: storage_mgmt_subnet01 fixed_ip: 172.19.0.129 - network: tenant subnet: tenant_subnet01 fixed_ip: 172.16.0.11 - name: Compute count: 2 hostname_format: compute-%index% defaults: [ ... ]ノードがプロビジョニングされたら、
overcloud-baremetal-deploy.yamlファイルからinstanceセクションを削除します。新しいコントローラーノードで
cephadmユーザーを作成するには、新しいホストの情報を含む基本的な Ceph 仕様をエクスポートします。$ openstack overcloud ceph spec --stack overcloud \ /home/stack/templates/overcloud-baremetal-deployed.yaml \ -o ceph_spec_host.yaml
注記環境でカスタムロールを使用している場合は、
--roles-dataオプションを含めます。cephadmユーザーを新しいコントローラーノードに追加します。$ openstack overcloud ceph user enable \ --stack overcloud ceph_spec_host.yaml
新しいロールを Ceph クラスターに追加します。
$ sudo cephadm shell \ -- ceph orch test add controlller-3 <IP_ADDRESS> <LABELS> 192.168.24.31 _admin mon mgr Inferring fsid 4cf401f9-dd4c-5cda-9f0a-fa47fbf12b31 Using recent ceph image undercloud-0.ctlplane.redhat.local:8787/rh-osbs/rhceph@sha256:3075e8708792ebd527ca14849b6af4a11256a3f881ab09b837d7af0f8b2102ea Added host 'controller-3' with addr '192.168.24.31'
- <IP_ADDRESS> をコントローラーノードの IP アドレスに置き換えます。
- <LABELS> を必要な Ceph ラベルに置き換えます。
openstack overcloud deployコマンドを再実行します。$ openstack overcloud deploy --stack overcloud --templates \ -n /home/stack/templates/network_data.yaml \ -r /home/stack/templates/roles_data.yaml \ -e /home/stack/templates/overcloud-baremetal-deployed.yaml \ -e /home/stack/templates/overcloud-networks-deployed.yaml \ -e /home/stack/templates/overcloud-vips-deployed.yaml \ -e /home/stack/templates/bootstrap_node.yaml \ -e [ ... ]注記置き換え用のコントローラーノードがブートストラップノードの場合には、
bootstrap_node.yaml環境ファイルを含めます。
20.7. 新しいコントローラーノードへの Ceph サービスのデプロイ
新しいコントローラーノードをプロビジョニングし、Ceph モニターサービスが実行されたら、コントローラーノードに mgr、rgw、および osd Ceph サービスをデプロイできます。
前提条件
- 新しいコントローラーノードがプロビジョニングされ、Ceph モニターサービスが実行されている。
手順
spec.yml環境ファイルを変更し、以前のコントローラーノード名を新しいコントローラーノード名に置き換えます。$ cephadm shell -- ceph orch ls --export > spec.yml
注記基本的な Ceph 環境ファイル
ceph_spec_host.yamlには、必要なすべてのクラスター情報が含まれていないため、使用しないでください。変更した Ceph 仕様ファイルを適用します。
$ cat spec.yml | sudo cephadm shell -- ceph orch apply -i - Inferring fsid 4cf401f9-dd4c-5cda-9f0a-fa47fbf12b31 Using recent ceph image undercloud-0.ctlplane.redhat.local:8787/rh-osbs/rhceph@sha256:3075e8708792ebd527ca14849b6af4a11256a3f881ab09b837d7af0f8b2102ea Scheduled crash update... Scheduled mgr update... Scheduled mon update... Scheduled osd.default_drive_group update... Scheduled rgw.rgw update...
新しいモニターの可視性を確認します。
$ sudo cephadm --ceph status
をクリックします。
20.8. コントローラーノード置き換え後のクリーンアップ
ノードの交換が完了したら、コントローラークラスターを完成させることができます。
手順
- コントローラーノードにログインします。
Galera クラスターの Pacemaker 管理を有効にし、新規ノード上で Galera を起動します。
[tripleo-admin@overcloud-controller-0 ~]$ sudo pcs resource refresh galera-bundle [tripleo-admin@overcloud-controller-0 ~]$ sudo pcs resource manage galera-bundle
フェンシングの有効化:
[tripleo-admin@overcloud-controller-0 ~]$ sudo pcs property set stonith-enabled=true
最終のステータスチェックを実行して、サービスが正しく実行されていることを確認します。
[tripleo-admin@overcloud-controller-0 ~]$ sudo pcs status
注記エラーが発生したサービスがある場合には、
pcs resource refreshコマンドを使用して問題を解決し、そのサービスを再起動します。director を終了します。
[tripleo-admin@overcloud-controller-0 ~]$ exit
オーバークラウドと対話できるようにするために、source コマンドで
overcloudrcファイルを読み込みます。$ source ~/overcloudrc
オーバークラウド環境のネットワークエージェントを確認します。
(overcloud) $ openstack network agent list
古いノードにエージェントが表示される場合には、そのエージェントを削除します。
(overcloud) $ for AGENT in $(openstack network agent list --host overcloud-controller-1.localdomain -c ID -f value) ; do openstack network agent delete $AGENT ; done
必要に応じて、新規ノード上の L3 エージェントホストにルーターを追加します。以下のコマンド例では、UUID に 2d1c1dc1-d9d4-4fa9-b2c8-f29cd1a649d4 を使用して L3 エージェントに
r1という名称のルーターを追加しています。(overcloud) $ openstack network agent add router --l3 2d1c1dc1-d9d4-4fa9-b2c8-f29cd1a649d4 r1
cinder サービスを掃除します。
cinder サービスを一覧表示します。
(overcloud) $ openstack volume service list
コントローラーノードにログインし、
cinder-apiコンテナーに接続し、cinder-manage service removeコマンドを使用して、残っているサービスを削除します。[tripleo-admin@overcloud-controller-0 ~]$ sudo podman exec -it cinder_api cinder-manage service remove cinder-backup <host> [tripleo-admin@overcloud-controller-0 ~]$ sudo podman exec -it cinder_api cinder-manage service remove cinder-scheduler <host>
RabbitMQ クラスターをクリーンアップします。
- コントローラーノードにログインします。
podman execコマンドを使用して bash を起動し、RabbitMQ クラスターのステータスを確認します。[tripleo-admin@overcloud-controller-0 ~]$ podman exec -it rabbitmq-bundle-podman-0 bash [tripleo-admin@overcloud-controller-0 ~]$ rabbitmqctl cluster_status
置き換えられたコントローラーノードをクリアするには、
rabbitmqctlコマンドを使用します。[tripleo-admin@overcloud-controller-0 ~]$ rabbitmqctl forget_cluster_node <node_name>
-
ブートストラップコントローラーノードを置き換えた場合は、置き換えプロセス後に環境ファイル
~/templates/bootstrap-controller.yamlを削除するか、既存の環境ファイルからpacemaker_short_bootstrap_node_nameおよびmysql_short_bootstrap_node_nameパラメーターを削除する必要があります。このステップにより、これ以降の置き換えで director がコントローラーノード名をオーバーライドしようとするのを防ぎます。詳細は、ブートストラップコントローラーノードの交換 を参照してください。 オーバークラウドで Object Storage サービス (swift) を使用している場合は、オーバークラウドノードを更新した後、swift リングを同期する必要があります。次の例のようなスクリプトを使用して、リングファイルを既存のコントローラーノード (この例では コントローラーノード 0) からすべてのコントローラーノードに配布し、それらのノードで Object Storage サービスコンテナーを再起動します。
#!/bin/sh set -xe SRC="tripleo-admin@overcloud-controller-0.ctlplane" ALL="tripleo-admin@overcloud-controller-0.ctlplane tripleo-admin@overcloud-controller-1.ctlplane tripleo-admin@overcloud-controller-2.ctlplane"
リングファイルの現在のセットを取得します。
ssh "${SRC}" 'sudo tar -czvf - /var/lib/config-data/puppet-generated/swift_ringbuilder/etc/swift/{*.builder,*.ring.gz,backups/*.builder}' > swift-rings.tar.gzリングをすべてのノードにアップロードし、それらを正しい場所に配置して、swift サービスを再起動します。
for DST in ${ALL}; do cat swift-rings.tar.gz | ssh "${DST}" 'sudo tar -C / -xvzf -' ssh "${DST}" 'sudo podman restart swift_copy_rings' ssh "${DST}" 'sudo systemctl restart tripleo_swift*' done
第21章 ノードの再起動
アンダークラウドおよびオーバークラウドで、ノードをリブートしなければならない場合があります。以下の手順を使用して、さまざまなノード種別をリブートする方法を説明します。
- 1 つのロールで全ノードをリブートする場合には、各ノードを個別にリブートすることを推奨しています。ロールの全ノードを同時に再起動すると、その操作中サービスにダウンタイムが生じる場合があります。
- OpenStack Platform 環境の全ノードをリブートする場合には、以下の順序でノードをリブートします。
推奨されるノードリブート順
- アンダークラウドノードのリブート
- コントローラーノードおよびその他のコンポーザブルノードのリブート
- スタンドアロンの Ceph MON ノードのリブート
- Ceph Storage ノードのリブート
- Object Storage サービス (swift) ノードを再起動します。
- コンピュートノードのリブート
21.1. アンダークラウドノードのリブート
アンダークラウドノードをリブートするには、以下の手順を実施します。
手順
-
アンダークラウドに
stackユーザーとしてログインします。 アンダークラウドをリブートします。
$ sudo reboot
- ノードがブートするまで待ちます。
21.2. コントローラーノードおよびコンポーザブルノードの再起動
設定可能なロールに基づいてコントローラーノードとスタンドアロンノードを再起動し、コンピュートノードと Ceph ストレージノードを除外します。
手順
- リブートするノードにログインします。
オプション: ノードが Pacemaker リソースを使用している場合は、クラスターを停止します。
[tripleo-admin@overcloud-controller-0 ~]$ sudo pcs cluster stop
ノードをリブートします。
[tripleo-admin@overcloud-controller-0 ~]$ sudo reboot
- ノードが起動するまで待ちます。
検証
サービスが有効になっていることを確認します。
ノードが Pacemaker サービスを使用している場合は、ノードがクラスターに再度加わったか確認します。
[tripleo-admin@overcloud-controller-0 ~]$ sudo pcs status
ノードが Systemd サービスを使用している場合は、すべてのサービスが有効化されていることを確認します。
[tripleo-admin@overcloud-controller-0 ~]$ sudo systemctl status
ノードがコンテナー化されたサービスを使用している場合には、ノード上の全コンテナーがアクティブであることを確認します。
[tripleo-admin@overcloud-controller-0 ~]$ sudo podman ps
21.3. スタンドアロンの Ceph MON ノードのリブート
スタンドアロンの Ceph MON ノードをリブートするには、以下の手順を実施します。
手順
- Ceph MON ノードにログインします。
ノードをリブートします。
$ sudo reboot
- ノードがブートして MON クラスターに再度加わるまで待ちます。
クラスター内の各 MON ノードで、この手順を繰り返します。
21.4. Ceph Storage (OSD) クラスターのリブート
Ceph Storage (OSD) ノードのクラスターを再起動するには、以下の手順を実施します。
前提条件
ceph-monサービスを実行している Ceph Monitor または Controller ノードで、Red Hat Ceph Storage クラスターのステータスが正常であり、pg ステータスがactive+cleanであることを確認する。$ sudo cephadm -- shell ceph status
Ceph クラスターが正常な場合、
HEALTH_OKのステータスが返されます。Ceph クラスターのステータスが異常な場合、
HEALTH_WARNまたはHEALTH_ERRのステータスが返されます。トラブルシューティングのガイダンスについては、Red Hat Ceph Storage 5 トラブルシューティングガイド を参照してください。
手順
ceph-monサービスを実行している Ceph Monitor または Controller ノードにログインし、Ceph Storage クラスターのリバランスを一時的に無効にします。$ sudo cephadm shell -- ceph osd set noout $ sudo cephadm shell -- ceph osd set norebalance
注記マルチスタックまたは分散計算ノード (DCN) アーキテクチャーを使用している場合は、
nooutフラグとnorebalanceフラグの設定時に Ceph クラスター名を指定する必要があります。例:sudo cephadm shell -c /etc/ceph/<cluster>.conf -k /etc/ceph/<cluster>.client.keyring。- 再起動する最初の Ceph Storage ノードを選択し、そのノードにログインします。
ノードを再起動します。
$ sudo reboot
- ノードが起動するまで待ちます。
ノードにログインし、Ceph クラスターのステータスを確認します。
$ sudo cephadm -- shell ceph status
pgmapにより、すべてのpgsが正常な状態 (active+clean) として報告されることを確認します。- ノードからログアウトして、次のノードを再起動し、ステータスを確認します。全 Ceph Storage ノードが再起動されるまで、このプロセスを繰り返します。
完了したら、
ceph-monサービスを実行している Ceph Monitor または Controller ノードにログインし、クラスターのリバランスを有効にします。$ sudo cephadm shell -- ceph osd unset noout $ sudo cephadm shell -- ceph osd unset norebalance
注記マルチスタックまたは分散計算ノード (DCN) アーキテクチャーを使用している場合は、
nooutフラグとnorebalanceフラグの設定解除時に Ceph クラスター名を指定する必要があります。例:sudo cephadm shell -c /etc/ceph/<cluster>.conf -k /etc/ceph/<cluster>.client.keyring。最終のステータスチェックを実行して、クラスターが
HEALTH_OKを報告していることを確認します。$ sudo cephadm shell ceph status
21.5. Object Storage サービス (swift) ノードの再起動
次の手順では、Object Storage サービス (swift) ノードを再起動します。クラスター内のすべてのオブジェクトストレージノードに対して、次の手順を実行します。
手順
- オブジェクトストレージノードにログインします。
ノードを再起動します。
$ sudo reboot
- ノードが起動するまで待ちます。
- クラスター内のオブジェクトストレージノードごとに再起動を繰り返します。
21.6. コンピュートノードの再起動
Red Hat Open Stack Platform 環境でのインスタンスのダウンタイムを最小限に抑えるために、インスタンスの移行ワークフローでは、再起動するコンピュートノードからインスタンスを移行する時に必要な手順を概説します。
インスタンスの移行ワークフロー
- コンピュートノードを再起動する前に、インスタンスを別のノードに移行するか決定します。
- 再起動するコンピュートノードを選択して無効にし、新規インスタンスをプロビジョニングしないようにします。
- インスタンスを別のコンピュートノードに移行します。
- 空のコンピュートノードを再起動します。
- 空のコンピュートノードを有効にします。
前提条件
コンピュートノードを再起動する前に、ノードの再起動中にインスタンスを別のコンピュートノードに移行するか決定する。
コンピュートノード間で仮想マシンインスタンスを移行する際に発生する可能性のある移行の制約リストを確認する。詳細は、インスタンス作成のための Compute サービスの設定 の 移行の制約 を参照してください。
インスタンスを移行できない場合は、以下のコアテンプレートパラメーターを設定して、コンピュートノード再起動後のインスタンスの状態を制御する。
NovaResumeGuestsStateOnHostBoot-
リブート後のコンピュートノードで、インスタンスを同じ状態に戻すか定義します。
Falseに設定すると、インスタンスは停止した状態を維持し、手動で起動する必要があります。デフォルト値はFalseです。 NovaResumeGuestsShutdownTimeout再起動する前に、インスタンスのシャットダウンを待つ秒数。この値を
0に設定することは推奨されません。デフォルト値は300です。オーバークラウドパラメーターおよびその使用方法についての詳細は、オーバークラウドのパラメーター を参照してください。
手順
-
アンダークラウドに
stackユーザーとしてログインします。 全コンピュートノードとその UUID を一覧表示します。
$ source ~/stackrc (undercloud) $ metalsmith list | grep compute
リブートするコンピュートノードの UUID を特定します。
オーバークラウドからコンピュートノードを選択し、そのノードを無効にします。
$ source ~/overcloudrc (overcloud)$ openstack compute service list (overcloud)$ openstack compute service set <hostname> nova-compute --disable
-
<hostname>は、コンピュートノードのホスト名に置き換えます。
-
コンピュートノード上の全インスタンスを一覧表示します。
(overcloud)$ openstack server list --host <hostname> --all-projects
オプション: インスタンスを別のコンピュートノードに移行するには、次の手順を実行します。
インスタンスを別のコンピュートノードに移行する場合は、以下のコマンドのいずれかを使用します。
インスタンスを別のホストに移行するには、次のコマンドを実行します。
(overcloud) $ openstack server migrate <instance_id> --live <target_host> --wait
-
<instance_id>は、インスタンス ID に置き換えます。 -
<target_host>は、インスタンスの移行先のホストに置き換えます。
-
nova-schedulerがターゲットホストを自動的に選択できるようにします。(overcloud) $ nova live-migration <instance_id>
すべてのインスタンスを一度にライブマイグレーションします。
$ nova host-evacuate-live <hostname>
注記novaコマンドで非推奨の警告が表示される可能性がありますが、無視しても問題ありません。
- 移行が完了するまで待ちます。
移行が正常に完了したことを確認します。
(overcloud) $ openstack server list --host <hostname> --all-projects
- コンピュートノードのインスタンスがなくなるまで、移行を続けます。
コンピュートノードにログインして、ノードを再起動します。
[tripleo-admin@overcloud-compute-0 ~]$ sudo reboot
- ノードが起動するまで待ちます。
コンピュートノードを再度有効にします。
$ source ~/overcloudrc (overcloud) $ openstack compute service set <hostname> nova-compute --enable
コンピュートノードが有効であることを確認します。
(overcloud) $ openstack compute service list
第22章 アンダークラウドおよびオーバークラウドのシャットダウンおよび起動
アンダークラウドおよびオーバークラウドでメンテナーンスを実施する必要がある場合は、オーバークラウド起動時の問題を最小限に抑えるために、アンダークラウドおよびオーバークラウドノードを特定の順序でシャットダウンして起動する必要があります。
前提条件
- 動作中のアンダークラウドおよびオーバークラウド
22.1. アンダークラウドおよびオーバークラウドのシャットダウン順序
Red Hat OpenStack Platform 環境をシャットダウンするには、オーバークラウドおよびアンダークラウドを以下の順序でシャットダウンする必要があります。
- オーバークラウドコンピュートノード上のインスタンスをシャットダウンします。
- コンピュートノードをシャットダウンします。
- コントローラーノードの高可用性サービスおよび OpenStack Platform のサービスをすべて停止します。
- Ceph Storage ノードをシャットダウンします。
- コントローラーノードをシャットダウンします。
- アンダークラウドをシャットダウンします。
22.2. オーバークラウドコンピュートノード上のインスタンスのシャットダウン
Red Hat OpenStack Platform 環境のシャットダウンのサブタスクとして、コンピュートノードをシャットダウンする前にコンピュートノード上のインスタンスをすべてシャットダウンします。
前提条件
- Compute サービスがアクティブなオーバークラウド
手順
-
アンダークラウドに
stackユーザーとしてログインします。 source コマンドでオーバークラウドの認証情報ファイルを読み込みます。
$ source ~/overcloudrc
オーバークラウドで実行中のインスタンスを表示します。
$ openstack server list --all-projects
オーバークラウドのそれぞれのインスタンスを停止します。
$ openstack server stop <INSTANCE>
オーバークラウド内のすべてのインスタンスを停止するまで、それぞれのインスタンスでこのステップを繰り返します。
22.3. コンピュートノードのシャットダウン
Red Hat OpenStack Platform 環境をシャットダウンする際のサブタスクとして、それぞれのコンピュートノードにログインしてシャットダウンします。
前提条件
- コンピュートノード上のすべてのインスタンスがシャットダウンされている。
手順
-
コンピュートノードに
rootユーザーとしてログインします。 ノードをシャットダウンします。
# shutdown -h now
- すべてのコンピュートノードをシャットダウンするまで、それぞれのコンピュートノードでこの手順を実施します。
22.4. コントローラーノードのサービスの停止
Red Hat OpenStack Platform 環境のシャットダウンする際のサブタスクとして、コントローラーノードをシャットダウンする前にノードのサービスを停止します。これには Pacemaker サービスおよび systemd サービスが含まれます。
前提条件
- Pacemaker サービスがアクティブなオーバークラウド
手順
-
コントローラーノードに
rootユーザーとしてログインします。 Pacemaker クラスターを停止します。
# pcs cluster stop --all
このコマンドにより、すべてのノード上のクラスターが停止します。
Pacemaker サービスが停止するまで待ち、サービスが停止したことを確認します。
Pacemaker のステータスを確認します。
# pcs status
Pacemaker サービスが実行されていないことを Podman で確認します。
# podman ps --filter "name=.*-bundle.*"
Red Hat OpenStack Platform のサービスを停止します。
# systemctl stop 'tripleo_*'
サービスが停止するまで待ち、サービスが実行されなくなったことを Podman で確認します。
# podman ps
22.5. Ceph Storage ノードのシャットダウン
Red Hat OpenStack Platform 環境のシャットダウンのサブタスクとして、Ceph Storage サービスを無効にし、続いてそれぞれの Ceph Storage ノードにログインしてシャットダウンします。
前提条件
- 正常な Ceph Storage クラスター。
- Ceph MON サービスがスタンドアロンの Ceph MON ノードまたはコントローラーノードで動作している。
手順
-
Ceph MON サービスを実行するノード (例: コントローラーノードまたはスタンドアロンの Ceph MON ノード) に
rootユーザーとしてログインします。 クラスターが正常であることを確認します。以下の例の
podmanコマンドにより、コントローラーノード上の Ceph MON コンテナー内でステータス確認が実施されます。# sudo podman exec -it ceph-mon-controller-0 ceph status
ステータスが
HEALTH_OKであることを確認します。クラスターの
noout、norecover、norebalance、nobackfill、nodown、およびpauseフラグを設定します。以下の例のpodmanコマンドにより、コントローラーノード上の Ceph MON コンテナーを通じてこれらのフラグが設定されます。# sudo podman exec -it ceph-mon-controller-0 ceph osd set noout # sudo podman exec -it ceph-mon-controller-0 ceph osd set norecover # sudo podman exec -it ceph-mon-controller-0 ceph osd set norebalance # sudo podman exec -it ceph-mon-controller-0 ceph osd set nobackfill # sudo podman exec -it ceph-mon-controller-0 ceph osd set nodown # sudo podman exec -it ceph-mon-controller-0 ceph osd set pause
それぞれの Ceph Storage ノードをシャットダウンします。
-
Ceph Storage ノードに
rootユーザーとしてログインします。 ノードをシャットダウンします。
# shutdown -h now
- すべての Ceph Storage ノードをシャットダウンするまで、それぞれの Ceph Storage ノードでこの手順を実施します。
-
Ceph Storage ノードに
スタンドアロンの Ceph MON ノードをすべてシャットダウンします。
-
スタンドアロンの Ceph MON ノードに
rootユーザーとしてログインします。 ノードをシャットダウンします。
# shutdown -h now
- スタンドアロンの Ceph MON ノードをすべてシャットダウンするまで、それぞれのスタンドアロンの Ceph MON ノードでこの手順を実施します。
-
スタンドアロンの Ceph MON ノードに
22.6. コントローラーノードのシャットダウン
Red Hat OpenStack Platform 環境のシャットダウンのサブタスクとして、それぞれのコントローラーノードにログインしてシャットダウンします。
前提条件
- Pacemaker クラスターが停止している。
- コントローラーノードのすべての Red Hat OpenStack Platform サービスが停止している。
手順
-
コントローラーノードに
rootユーザーとしてログインします。 ノードをシャットダウンします。
# shutdown -h now
- すべてのコントローラーノードをシャットダウンするまで、それぞれのコントローラーノードでこの手順を実施します。
22.7. アンダークラウドのシャットダウン
Red Hat OpenStack Platform 環境のシャットダウンのサブタスクとして、アンダークラウドノードにログインしてアンダーグラウンドをシャットダウンします。
前提条件
- 動作中のアンダークラウド
手順
-
アンダークラウドに
stackユーザーとしてログインします。 アンダークラウドをシャットダウンします。
$ sudo shutdown -h now
22.8. システムメンテナンスの実施
アンダークラウドおよびオーバークラウドを完全にシャットダウンしたら、環境内のシステムに対するメンテナンスを実施し、続いてアンダークラウドおよびオーバークラウドを起動します。
22.9. アンダークラウドおよびオーバークラウドの起動順序
Red Hat OpenStack Platform 環境を起動するには、アンダークラウドおよびオーバークラウドを以下の順序で起動する必要があります。
- アンダークラウドを起動します。
- コントローラーノードを起動します。
- Ceph Storage ノードを起動します。
- コンピューティングノードを起動します。
- オーバークラウドのコンピュートノードでインスタンスを起動します。
22.10. アンダークラウドの起動
Red Hat OpenStack Platform 環境の起動のサブタスクとして、アンダークラウドノードの電源をオンにし、アンダークラウドにログインし、アンダークラウドのサービスを確認します。
前提条件
- アンダークラウドの電源がオフになっている。
手順
- アンダークラウドの電源をオンにし、アンダークラウドがブートするまで待ちます。
検証
-
アンダークラウドホストに
stackユーザーとしてログインします。 stackrcアンダークラウド認証情報ファイルを入手します。$ source ~/stackrc
アンダークラウドのサービスを確認します。
$ systemctl list-units 'tripleo_*'
tripleo-ansible-inventory.yamlという名前の静的インベントリーファイルを検証します。$ validation run --group pre-introspection -i <inventory_file>
<inventory_file>ファイルを Ansible インベントリーファイルの名前および場所に置き換えます (例:~/tripleo-deploy/undercloud/tripleo-ansible-inventory.yaml)。注記検証を実行すると、出力の
Reasons列は 79 文字に制限されます。検証結果を完全に表示するには、検証ログファイルを表示します。
すべてのサービスとコンテナーがアクティブおよび正常であることを確認します。
$ validation run --validation service-status --limit undercloud -i <inventory_file>
関連情報
22.11. コントローラーノードの起動
Red Hat OpenStack Platform 環境の起動のサブタスクとして、それぞれのコントローラーノードの電源をオンにし、そのノードの Pacemaker 以外のサービスを確認します。
前提条件
- コントローラーノードの電源がオフになっている。
手順
- それぞれのコントローラーノードの電源をオンにします。
検証
-
rootユーザーとして各コントローラーノードにログインします。 コントローラーノードのサービスを確認します。
$ systemctl -t service
Pacemaker ベース以外のサービスだけが動作中です。
Pacemaker サービスが起動するまで待ち、サービスが起動したことを確認します。
$ pcs status
注記環境でインスタンス HA を使用している場合、Pacemaker リソースは、コンピュートノードを起動するか、
pcs stonith confirm <compute_node>コマンドを使用して手動でフェンスを解除する操作を実行するまで起動しません。このコマンドは、インスタンス HA を使用する各コンピュートノードで実行する必要があります。
22.12. Ceph Storage ノードの起動
Red Hat OpenStack Platform 環境の起動のサブタスクとして、Ceph MON ノードおよび Ceph Storage ノードの電源をオンにし、Ceph Storage サービスを有効にします。
前提条件
- 電源がオフの Ceph Storage クラスター。
- 電源がオフのスタンドアロンの Ceph MON ノードまたは電源がオンのコントローラーノードで、Ceph MON サービスが有効になっている。
手順
- 使用している環境にスタンドアロンの Ceph MON ノードがある場合、それぞれの Ceph MON ノードの電源をオンにします。
- それぞれの Ceph Storage ノードの電源をオンにします。
-
Ceph MON サービスを実行するノード (例: コントローラーノードまたはスタンドアロンの Ceph MON ノード) に
rootユーザーとしてログインします。 クラスターノードのステータスを確認します。以下の例の
podmanコマンドにより、コントローラーノード上の Ceph MON コンテナー内でステータス確認が実施されます。# sudo podman exec -it ceph-mon-controller-0 ceph status
それぞれのノードの電源がオンで、接続された状態であることを確認します。
クラスターの
noout、norecover、norebalance、nobackfill、nodown、およびpauseフラグの設定を解除します。以下の例のpodmanコマンドにより、コントローラーノード上の Ceph MON コンテナーを通じてこれらのフラグの設定が解除されます。# sudo podman exec -it ceph-mon-controller-0 ceph osd unset noout # sudo podman exec -it ceph-mon-controller-0 ceph osd unset norecover # sudo podman exec -it ceph-mon-controller-0 ceph osd unset norebalance # sudo podman exec -it ceph-mon-controller-0 ceph osd unset nobackfill # sudo podman exec -it ceph-mon-controller-0 ceph osd unset nodown # sudo podman exec -it ceph-mon-controller-0 ceph osd unset pause
検証
クラスターが正常であることを確認します。以下の例の
podmanコマンドにより、コントローラーノード上の Ceph MON コンテナー内でステータス確認が実施されます。# sudo podman exec -it ceph-mon-controller-0 ceph status
ステータスが
HEALTH_OKであることを確認します。
22.13. コンピュートノードの起動
Red Hat OpenStack Platform 環境の起動のサブタスクとして、それぞれのコンピュートノードの電源をオンにし、そのノードのサービスを確認します。
前提条件
- 電源がオフのコンピュートノード
手順
- それぞれのコンピュートノードの電源をオンにします。
検証
-
各コンピュートに
rootユーザーとしてログインします。 コンピュートノードのサービスを確認します。
$ systemctl -t service
22.14. オーバークラウドコンピュートノード上のインスタンスの起動
Red Hat OpenStack Platform 環境の起動のサブタスクとして、コンピュートノード上のインスタンスを起動します。
前提条件
- アクティブなノードを持つアクティブなオーバークラウド
手順
-
アンダークラウドに
stackユーザーとしてログインします。 source コマンドでオーバークラウドの認証情報ファイルを読み込みます。
$ source ~/overcloudrc
オーバークラウドで実行中のインスタンスを表示します。
$ openstack server list --all-projects
オーバークラウド内のインスタンスを起動します。
$ openstack server start <INSTANCE>
第23章 その他のイントロスペクション操作
状況によっては、標準のオーバークラウドデプロイメントワークフローの外部でイントロスペクションを実行したい場合があります。たとえば、既存の未使用ノードのハードウェアを交換した後、新しいノードをイントロスペクトしたり、イントロスペクションデータを更新したりすることができます。
23.1. ノードイントロスペクションの個別実行
available の状態のノードで個別にイントロスペクションを実行するには、ノードを管理モードに設定して、イントロスペクションを実行します。
手順
すべてのノードを
manageable状態に設定します。(undercloud) $ openstack baremetal node manage [NODE UUID]
イントロスペクションを実行します。
(undercloud) $ openstack overcloud node introspect [NODE UUID] --provide
イントロスペクションが完了すると、ノードの状態が
availableに変わります。
23.2. 初回のイントロスペクション後のノードイントロスペクションの実行
--provide オプションを指定したので、初回のイントロスペクションの後には、全ノードが available の状態になります。最初のイントロスペクションの後にすべてのノードでイントロスペクションを実行するには、ノードを管理モードに設定してイントロスペクションを実行します。
手順
すべてのノードを
manageable状態に設定します(undercloud) $ for node in $(openstack baremetal node list --fields uuid -f value) ; do openstack baremetal node manage $node ; done
bulk introspection コマンドを実行します。
(undercloud) $ openstack overcloud node introspect --all-manageable --provide
イントロスペクション完了後には、すべてのノードが
availableの状態に変わります。
23.3. ネットワークイントロスペクションの実行によるインターフェイス情報の取得
ネットワークイントロスペクションにより、Link Layer Discovery Protocol (LLDP) データがネットワークスイッチから取得されます。以下のコマンドにより、ノード上の全インターフェイスに関する LLDP 情報のサブセット、または特定のノードおよびインターフェイスに関するすべての情報が表示されます。この情報は、トラブルシューティングに役立ちます。director では、デフォルトで LLDP データ収集が有効になっています。
手順
ノード上のインターフェイスを一覧表示するには、以下のコマンドを実行します。
(undercloud) $ openstack baremetal introspection interface list [NODE UUID]
以下に例を示します。
(undercloud) $ openstack baremetal introspection interface list c89397b7-a326-41a0-907d-79f8b86c7cd9 +-----------+-------------------+------------------------+-------------------+----------------+ | Interface | MAC Address | Switch Port VLAN IDs | Switch Chassis ID | Switch Port ID | +-----------+-------------------+------------------------+-------------------+----------------+ | p2p2 | 00:0a:f7:79:93:19 | [103, 102, 18, 20, 42] | 64:64:9b:31:12:00 | 510 | | p2p1 | 00:0a:f7:79:93:18 | [101] | 64:64:9b:31:12:00 | 507 | | em1 | c8:1f:66:c7:e8:2f | [162] | 08:81:f4:a6:b3:80 | 515 | | em2 | c8:1f:66:c7:e8:30 | [182, 183] | 08:81:f4:a6:b3:80 | 559 | +-----------+-------------------+------------------------+-------------------+----------------+
インターフェイスのデータおよびスイッチポートの情報を表示するには、以下のコマンドを実行します。
(undercloud) $ openstack baremetal introspection interface show [NODE UUID] [INTERFACE]
以下に例を示します。
(undercloud) $ openstack baremetal introspection interface show c89397b7-a326-41a0-907d-79f8b86c7cd9 p2p1 +--------------------------------------+------------------------------------------------------------------------------------------------------------------------+ | Field | Value | +--------------------------------------+------------------------------------------------------------------------------------------------------------------------+ | interface | p2p1 | | mac | 00:0a:f7:79:93:18 | | node_ident | c89397b7-a326-41a0-907d-79f8b86c7cd9 | | switch_capabilities_enabled | [u'Bridge', u'Router'] | | switch_capabilities_support | [u'Bridge', u'Router'] | | switch_chassis_id | 64:64:9b:31:12:00 | | switch_port_autonegotiation_enabled | True | | switch_port_autonegotiation_support | True | | switch_port_description | ge-0/0/2.0 | | switch_port_id | 507 | | switch_port_link_aggregation_enabled | False | | switch_port_link_aggregation_id | 0 | | switch_port_link_aggregation_support | True | | switch_port_management_vlan_id | None | | switch_port_mau_type | Unknown | | switch_port_mtu | 1514 | | switch_port_physical_capabilities | [u'1000BASE-T fdx', u'100BASE-TX fdx', u'100BASE-TX hdx', u'10BASE-T fdx', u'10BASE-T hdx', u'Asym and Sym PAUSE fdx'] | | switch_port_protocol_vlan_enabled | None | | switch_port_protocol_vlan_ids | None | | switch_port_protocol_vlan_support | None | | switch_port_untagged_vlan_id | 101 | | switch_port_vlan_ids | [101] | | switch_port_vlans | [{u'name': u'RHOS13-PXE', u'id': 101}] | | switch_protocol_identities | None | | switch_system_name | rhos-compute-node-sw1 | +--------------------------------------+------------------------------------------------------------------------------------------------------------------------+
23.4. ハードウェアイントロスペクション情報の取得
Bare Metal サービスでは、オーバークラウド設定の追加ハードウェア情報を取得する機能がデフォルトで有効です。undercloud.conf ファイル内の Inspection_extras パラメーターの詳細は、Director 設定パラメーター を参照してください。
たとえば、numa_topology コレクターは、追加ハードウェアイントロスペクションの一部で、各 NUMA ノードに関する以下の情報が含まれます。
- RAM (キロバイト単位)
- 物理 CPU コアおよびそのシブリングスレッド
- NUMA ノードに関連付けられた NIC
手順
上記の情報を取得するには、<UUID> をベアメタルノードの UUID に置き換えて、以下のコマンドを実行します。
# openstack baremetal introspection data save <UUID> | jq .numa_topology
取得されるベアメタルノードの NUMA 情報の例を以下に示します。
{ "cpus": [ { "cpu": 1, "thread_siblings": [ 1, 17 ], "numa_node": 0 }, { "cpu": 2, "thread_siblings": [ 10, 26 ], "numa_node": 1 }, { "cpu": 0, "thread_siblings": [ 0, 16 ], "numa_node": 0 }, { "cpu": 5, "thread_siblings": [ 13, 29 ], "numa_node": 1 }, { "cpu": 7, "thread_siblings": [ 15, 31 ], "numa_node": 1 }, { "cpu": 7, "thread_siblings": [ 7, 23 ], "numa_node": 0 }, { "cpu": 1, "thread_siblings": [ 9, 25 ], "numa_node": 1 }, { "cpu": 6, "thread_siblings": [ 6, 22 ], "numa_node": 0 }, { "cpu": 3, "thread_siblings": [ 11, 27 ], "numa_node": 1 }, { "cpu": 5, "thread_siblings": [ 5, 21 ], "numa_node": 0 }, { "cpu": 4, "thread_siblings": [ 12, 28 ], "numa_node": 1 }, { "cpu": 4, "thread_siblings": [ 4, 20 ], "numa_node": 0 }, { "cpu": 0, "thread_siblings": [ 8, 24 ], "numa_node": 1 }, { "cpu": 6, "thread_siblings": [ 14, 30 ], "numa_node": 1 }, { "cpu": 3, "thread_siblings": [ 3, 19 ], "numa_node": 0 }, { "cpu": 2, "thread_siblings": [ 2, 18 ], "numa_node": 0 } ], "ram": [ { "size_kb": 66980172, "numa_node": 0 }, { "size_kb": 67108864, "numa_node": 1 } ], "nics": [ { "name": "ens3f1", "numa_node": 1 }, { "name": "ens3f0", "numa_node": 1 }, { "name": "ens2f0", "numa_node": 0 }, { "name": "ens2f1", "numa_node": 0 }, { "name": "ens1f1", "numa_node": 0 }, { "name": "ens1f0", "numa_node": 0 }, { "name": "eno4", "numa_node": 0 }, { "name": "eno1", "numa_node": 0 }, { "name": "eno3", "numa_node": 0 }, { "name": "eno2", "numa_node": 0 } ] }
第24章 ベアメタルノードの自動検出
自動検出を使用すると、オーバークラウドノードを登録してそのメタデータを生成するのに、instackenv.json ファイルを作成する必要がありません。この改善は、ノードに関する情報を取得するのに費す時間を短縮するのに役立ちます。たとえば、自動検出を使用する場合、IPMI IP アドレスを照合し、その後に instackenv.json を作成する必要がありません。
24.1. 自動検出の有効化
Bare Metal 自動検出を有効にして設定し、PXE でブートするときにプロビジョニングネットワークに参加するノードを自動的に検出してインポートします。
手順
undercloud.confファイルで、ベアメタルの自動検出を有効にします。enable_node_discovery = True discovery_default_driver = ipmi
-
enable_node_discovery: 有効にすると、PXE を使用して introspection ramdisk をブートするすべてのノードが、自動的に Bare Metal サービス (ironic) に登録されます。 -
discovery_default_driver: 検出されたノードに使用するドライバーを設定します。例:ipmi
-
IPMI の認証情報を ironic に追加します。
IPMI の認証情報を
ipmi-credentials.jsonという名前のファイルに追加します。この例のSampleUsername、RedactedSecurePassword、およびbmc_addressの値を、実際の環境に応じて置き換えてください。[ { "description": "Set default IPMI credentials", "conditions": [ {"op": "eq", "field": "data://auto_discovered", "value": true} ], "actions": [ {"action": "set-attribute", "path": "driver_info/ipmi_username", "value": "SampleUsername"}, {"action": "set-attribute", "path": "driver_info/ipmi_password", "value": "RedactedSecurePassword"}, {"action": "set-attribute", "path": "driver_info/ipmi_address", "value": "{data[inventory][bmc_address]}"} ] } ]
IPMI の認証情報ファイルを ironic にインポートします。
$ openstack baremetal introspection rule import ipmi-credentials.json
24.2. 自動検出のテスト
PXE は、プロビジョニングネットワークに接続されているノードを起動して、Bare Metal 自動検出機能をテストします。
手順
- 必要なノードの電源をオンにします。
openstack baremetal node listコマンドを実行します。新しいノードがenrollの状態でリストに表示されるはずです。$ openstack baremetal node list +--------------------------------------+------+---------------+-------------+--------------------+-------------+ | UUID | Name | Instance UUID | Power State | Provisioning State | Maintenance | +--------------------------------------+------+---------------+-------------+--------------------+-------------+ | c6e63aec-e5ba-4d63-8d37-bd57628258e8 | None | None | power off | enroll | False | | 0362b7b2-5b9c-4113-92e1-0b34a2535d9b | None | None | power off | enroll | False | +--------------------------------------+------+---------------+-------------+--------------------+-------------+
各ノードにリソースクラスを設定します。
$ for NODE in `openstack baremetal node list -c UUID -f value` ; do openstack baremetal node set $NODE --resource-class baremetal ; done
各ノードにカーネルと ramdisk を設定します。
$ for NODE in `openstack baremetal node list -c UUID -f value` ; do openstack baremetal node manage $NODE ; done $ openstack overcloud node configure --all-manageable
全ノードを利用可能な状態に設定します。
$ for NODE in `openstack baremetal node list -c UUID -f value` ; do openstack baremetal node provide $NODE ; done
24.3. ルールを使用した異なるベンダーハードウェアの検出
異種のハードウェアが混在する環境では、イントロスペクションルールを使って、認証情報の割り当てやリモート管理を行うことができます。たとえば、DRAC を使用する Dell ノードを処理するには、別の検出ルールが必要になる場合があります。
手順
以下の内容で、
dell-drac-rules.jsonという名前のファイルを作成します。[ { "description": "Set default IPMI credentials", "conditions": [ {"op": "eq", "field": "data://auto_discovered", "value": true}, {"op": "ne", "field": "data://inventory.system_vendor.manufacturer", "value": "Dell Inc."} ], "actions": [ {"action": "set-attribute", "path": "driver_info/ipmi_username", "value": "SampleUsername"}, {"action": "set-attribute", "path": "driver_info/ipmi_password", "value": "RedactedSecurePassword"}, {"action": "set-attribute", "path": "driver_info/ipmi_address", "value": "{data[inventory][bmc_address]}"} ] }, { "description": "Set the vendor driver for Dell hardware", "conditions": [ {"op": "eq", "field": "data://auto_discovered", "value": true}, {"op": "eq", "field": "data://inventory.system_vendor.manufacturer", "value": "Dell Inc."} ], "actions": [ {"action": "set-attribute", "path": "driver", "value": "idrac"}, {"action": "set-attribute", "path": "driver_info/drac_username", "value": "SampleUsername"}, {"action": "set-attribute", "path": "driver_info/drac_password", "value": "RedactedSecurePassword"}, {"action": "set-attribute", "path": "driver_info/drac_address", "value": "{data[inventory][bmc_address]}"} ] } ]- この例のユーザー名およびパスワードの値を、実際の環境に応じて置き換えてください。
ルールを ironic にインポートします。
$ openstack baremetal introspection rule import dell-drac-rules.json
第25章 プロファイルの自動タグ付けの設定
イントロスペクションプロセスでは、一連のベンチマークテストを実行します。director は、これらのテストのデータを保存します。このデータをさまざまな方法で使用するポリシーセットを作成することができます。
- ポリシーにより、パフォーマンスの低いノードまたは不安定なノードを特定して、これらのノードがオーバークラウドで使用されないように隔離することができます。
- ポリシーにより、ノードを自動的に特定のプロファイルにタグ付けするかどうかを定義することができます。
25.1. ポリシーファイルの構文
ポリシーファイルは JSON 形式で、ルールセットが記載されます。各ルールでは、説明、条件、およびアクションが定義されます。説明 はプレーンテキストで記述されたルールの説明で、条件 はキー/値のパターンを使用して評価を定義し、アクション は条件のパフォーマンスを表します。
説明
これは、プレーンテキストで記述されたルールの説明です。
例:
"description": "A new rule for my node tagging policy"
conditions
ここでは、以下のキー/値のパターンを使用して評価を定義します。
- field
評価するフィールドを定義します。
-
memory_mb: ノードのメモリーサイズ (MB 単位) -
cpus: ノードの CPU の合計スレッド数 -
cpu_arch: ノードの CPU のアーキテクチャー -
local_gb: ノードのルートディスクの合計ストレージ容量
-
- op
評価に使用する演算を定義します。これには、以下の属性が含まれます。
-
eq: 等しい -
ne: 等しくない -
lt: より小さい -
gt: より大きい -
le: より小さいか等しい -
ge: より大きいか等しい -
in-net: IP アドレスが指定のネットワーク内にあることを確認します。 -
matches: 指定の正規表現と完全に一致する必要があります。 -
contains: 値には、指定の正規表現が含まれる必要があります。 -
is-empty:fieldが空欄であることを確認します。
-
- invert
- 評価の結果をインバージョン (反転) するかどうかを定義するブール値
- multiple
複数の結果が存在する場合に、使用する評価を定義します。このパラメーターには以下の属性が含まれます。
-
any: いずれかの結果が一致する必要があります。 -
all: すべての結果が一致する必要があります。 -
first: 最初の結果が一致する必要があります。
-
- value
- 評価する値を定義します。フィールド、演算および値の条件が満たされる場合には、true の結果を返します。そうでない場合には、条件は false の結果を返します。
例:
"conditions": [
{
"field": "local_gb",
"op": "ge",
"value": 1024
}
],アクション
条件が true の場合には、ポリシーはアクションを実行します。アクションでは、action キーおよび action の値に応じて追加のキーが使用されます。
-
fail: イントロスペクションが失敗します。失敗のメッセージには、messageパラメーターが必要です。 -
set-attribute: ironic ノードの属性を設定します。ironic の属性へのパス (例:/driver_info/ipmi_address) を指定するpathフィールドおよび設定するvalueが必要です。 -
set-capability: ironic ノードのケイパビリティーを設定します。新しいケイパビリティーの名前と値を指定するnameおよびvalueフィールドが必要です。これにより、このケイパビリティーの既存の値が置き換えられます。たとえば、これを使用してノードのプロファイルを定義します。 -
extend-attribute:set-attributeと同じですが、既存の値を一覧として扱い、その一覧に値を追記します。オプションのuniqueパラメーターを True に設定すると、対象の値がすでに一覧に含まれている場合には何も追加しません。
例:
"actions": [
{
"action": "set-capability",
"name": "profile",
"value": "swift-storage"
}
]25.2. ポリシーファイルの例
イントロスペクションルールを記載した JSON ファイル (rules.json) の例を以下に示します。
[
{
"description": "Fail introspection for unexpected nodes",
"conditions": [
{
"op": "lt",
"field": "memory_mb",
"value": 4096
}
],
"actions": [
{
"action": "fail",
"message": "Memory too low, expected at least 4 GiB"
}
]
},
{
"description": "Assign profile for object storage",
"conditions": [
{
"op": "ge",
"field": "local_gb",
"value": 1024
}
],
"actions": [
{
"action": "set-capability",
"name": "profile",
"value": "swift-storage"
}
]
},
{
"description": "Assign possible profiles for compute and controller",
"conditions": [
{
"op": "lt",
"field": "local_gb",
"value": 1024
},
{
"op": "ge",
"field": "local_gb",
"value": 40
}
],
"actions": [
{
"action": "set-capability",
"name": "compute_profile",
"value": "1"
},
{
"action": "set-capability",
"name": "control_profile",
"value": "1"
},
{
"action": "set-capability",
"name": "profile",
"value": null
}
]
}
]上記の例は、3 つのルールで設定されています。
- メモリーが 4096 MiB 未満の場合には、イントロスペクションが失敗します。クラウドから特定のノードを除外する場合は、このルール種別を適用することができます。
- ハードドライブのサイズが 1 TiB 以上のノードの場合は swift-storage プロファイルが無条件で割り当てられます。
-
ハードドライブが 1 TiB 未満だが 40 GiB を超えているノードは、コンピュートノードまたはコントローラーノードのいずれかに割り当てることができます。
openstack overcloud profiles matchコマンドを使用して後で最終選択できるように、2 つのケイパビリティー (compute_profileおよびcontrol_profile) を割り当てています。このプロセスが機能するためには、既存のプロファイルケイパビリティーを削除する必要があります。削除しないと、既存のプロファイルケイパビリティーが優先されます。
プロファイルマッチングルールは、他のノードを変更しません。
イントロスペクションルールを使用して profile 機能を割り当てる場合は常に、既存の値よりこの割り当てた値が優先されます。ただし、すでにプロファイルケイパビリティーを持つノードについては、[PROFILE]_profile ケイパビリティーは無視されます。
25.3. ポリシーファイルを director にインポートする
ポリシー JSON ファイルで定義したポリシールールを適用するには、ポリシーファイルを director にインポートする必要があります。
手順
ポリシーファイルを director にインポートします。
$ openstack baremetal introspection rule import <policy_file>
-
<policy_file>をポリシールールファイルの名前 (例:rules.json) に置き換えます。
-
イントロスペクションのプロセスを実行します。
$ openstack overcloud node introspect --all-manageable
ポリシールールが適用されるノードの UUID を取得します。
$ openstack baremetal node list
ポリシールールファイルで定義されたプロファイルがノードに割り当てられていることを確認します。
$ openstack baremetal node show <node_uuid>
イントロスペクションルールを間違えた場合は、すべてのルールを削除します。
$ openstack baremetal introspection rule purge
第26章 仮想コントロールプレーンの作成
仮想コントロールプレーンは、ベアメタルではなく仮想マシン (VM) 上にあるコントロールプレーンです。仮想コントロールプレーンを使用することで、コントロールプレーンに必要なベアメタルマシンの数を減らすことができます。
本章では、Red Hat OpenStack Platform (RHOSP) および Red Hat Virtualization を使用して、オーバークラウドの RHOSP コントロールプレーンを仮想化する方法について説明します。
26.1. 仮想コントロールプレーンのアーキテクチャー
director を使用して、Red Hat Virtualization クラスターにデプロイされたコントローラーノードを使用するオーバークラウドをプロビジョニングします。その後、これらの仮想コントローラーを仮想コントロールプレーンノードとしてデプロイできます。
仮想コントローラーノードは、Red Hat Virtualization 上でのみサポートされます。
以下のアーキテクチャー図は、仮想コントロールプレーンのデプロイ方法を示しています。オーバークラウドを Red Hat Virtualization の仮想マシン上で実行中のコントローラーノードに分散し、コンピュートノードおよびストレージノードをベアメタル上で実行します。
OpenStack 仮想アンダークラウドは、Red Hat Virtualization 上で実行されます。
仮想コントロールプレーンのアーキテクチャー
OpenStack Bare Metal Provisioning サービス (ironic) には、Red Hat Virtualization の仮想マシン用ドライバー staging-ovirt が含まれています。このドライバーを使用して、Red Hat Virtualization 環境内の仮想ノードを管理できます。このドライバーを使用して、Red Hat Virtualization 環境内の仮想マシンとしてオーバークラウドのコントローラーをデプロイすることもできます。
RHOSP オーバークラウドのコントロールプレーンを仮想化する際の利点と制限
RHOSP オーバークラウドのコントロールプレーンを仮想化する利点は数多くありますが、すべての設定に適用できる訳ではありません。
利点
オーバークラウドのコントロールプレーンを仮想化することには、ダウンタイムを回避し、パフォーマンスを向上させる数多くの利点があります。
- ホットプラグおよびホットアンプラグを使用して CPU およびメモリーを必要に応じてスケーリングし、リソースを仮想コントローラーに動的に割り当てることができます。これにより、ダウンタイムを防ぎ、プラットフォームの拡張に合わせて増大した能力を活用できます。
- 同じ Red Hat Virtualization クラスターに追加のインフラストラクチャー仮想マシンをデプロイすることができます。これにより、データセンターのサーバーフットプリントが最小限に抑えられ、物理ノードの効率が最大化されます。
- コンポーザブルロールを使用すると、より複雑な RHOSP コントロールプレーンを定義することができ、リソースをコントロールプレーンの特定のコンポーネントに割り当てることができます。
- 仮想マシンのライブマイグレーション機能により、サービスを中断せずにシステムをメンテナーンスすることができます。
- Red Hat Virtualization がサポートするサードパーティーまたはカスタムツールを統合することができます。
制限
仮想コントロールプレーンには、使用できる設定の種類に制限があります。
- 仮想 Ceph Storage ノードおよびコンピュートノードはサポートされません。
- ファイバーチャネルを使用するバックエンドについては、Block Storage (cinder) のイメージからボリュームへの転送はサポートされません。Red Hat Virtualization は N_Port ID Virtualization (NPIV) をサポートしていません。したがって、ストレージのバックエンドからコントローラー (デフォルトで cinder-volume を実行) に LUN をマッピングする必要のある Block Storage (cinder) ドライバーは機能しません。仮想化されたコントローラーに含めるのではなく、cinder-volume 専用のロールを作成し、そのロールを使用して物理ノードを作成する必要があります。詳しい情報は、オーバークラウドの高度なカスタマイズの コンポーザブルサービスとカスタムロール を参照してください。
26.2. Red Hat Virtualization ドライバーを使用した仮想コントローラーのプロビジョニング
RHOSP および Red Hat Virtualization を使用してオーバークラウドの仮想 RHOSP コントロールプレーンをプロビジョニングするには、以下の手順を実施します。
前提条件
- Intel 64 または AMD64 CPU 拡張機能をサポートする、64 ビット x86 プロセッサーが必要です。
以下のソフトウェアがすでにインストールされ、設定されている必要があります。
- Red Hat Virtualization。詳しい情報は、Red Hat Virtualization ドキュメントスイート を参照してください。
- Red Hat OpenStack Platform (RHOSP)。詳しい情報は、director のインストールと使用方法 を参照してください。
- 事前に仮想コントローラーノードを準備しておく必要があります。これらの要件は、ベアメタルのコントローラーノードの要件と同じです。詳しい情報は、コントローラーノードの要件 を参照してください。
- オーバークラウドのコンピュートノードおよびストレージノードとして使用するベアメタルノードを、事前に準備しておく必要があります。ハードウェアの仕様については、コンピュートノードの要件 および Ceph Storage ノードの要件 を参照してください。
- 論理ネットワークが作成され、ホストネットワークのクラスターで複数ネットワークによるネットワーク分離を使用する用意ができている必要があります。詳しい情報は、Red Hat Virtualization Administration Guide の Logical Networks を参照してください。
- 各ノードの内部 BIOS クロックを UTC に設定する必要があります。これにより、タイムゾーンオフセットを適用する前に hwclock が BIOS クロックを同期するとファイルのタイムスタンプに未来の日時が設定される問題を防ぐことができます。
パフォーマンスのボトルネックを防ぐために、コンポーザブルロールを使用しデータプレーンサービスをベアメタルのコントローラーノード上に維持します。
手順
director で
staging-ovirtドライバーを有効にするには、undercloud.conf設定ファイルのenabled_hardware_typesパラメーターにこのドライバーを追加します。enabled_hardware_types = ipmi,redfish,ilo,idrac,staging-ovirt
アンダークラウドに
staging-ovirtドライバーが含まれることを確認します。(undercloud) [stack@undercloud ~]$ openstack baremetal driver list
アンダークラウドを正しく設定していれば、コマンドにより以下の結果が返されます。
+---------------------+-----------------------+ | Supported driver(s) | Active host(s) | +---------------------+-----------------------+ | idrac | localhost.localdomain | | ilo | localhost.localdomain | | ipmi | localhost.localdomain | | pxe_drac | localhost.localdomain | | pxe_ilo | localhost.localdomain | | pxe_ipmitool | localhost.localdomain | | redfish | localhost.localdomain | | staging-ovirt | localhost.localdomain |
オーバークラウドノードの定義テンプレート (例:
nodes.json) を更新し、Red Hat Virtualization がホストする仮想マシンを director に登録します。詳細は、オーバークラウドのノード登録 を参照してください。以下のキー/値のペアを使用して、オーバークラウドでデプロイする仮想マシンの特性を定義します。表26.1 オーバークラウド用仮想マシンの設定
キー この値に設定します pm_typeoVirt/RHV 仮想マシン用の OpenStack Bare Metal Provisioning (ironic) サービスドライバー
staging-ovirtpm_userRed Hat Virtualization Manager のユーザー名
pm_passwordRed Hat Virtualization Manager のパスワード
pm_addrRed Hat Virtualization Manager サーバーのホスト名または IP
pm_vm_nameコントローラーが作成される Red Hat Virtualization Manager の仮想マシンの名前
以下に例を示します。
{ "nodes": [ { "name":"osp13-controller-0", "pm_type":"staging-ovirt", "mac":[ "00:1a:4a:16:01:56" ], "cpu":"2", "memory":"4096", "disk":"40", "arch":"x86_64", "pm_user":"admin@internal", "pm_password":"password", "pm_addr":"rhvm.example.com", "pm_vm_name":"{osp_curr_ver}-controller-0", "capabilities": "profile:control,boot_option:local" }, ... }Red Hat Virtualization Host ごとに 1 つのコントローラーを設定します。
- Red Hat Virtualization でアフィニティーグループをソフトネガティブアフィニティーに設定し、コントローラー用仮想マシンの高可用性を確保します。詳しい情報は、Red Hat Virtualization Virtual Machine Management Guide の Affinity Groups を参照してください。
- Red Hat Virtualization Manager のインターフェイスにアクセスし、これを使用してそれぞれの VLAN をコントローラー用仮想マシンの個別の論理仮想 NIC にマッピングします。詳しい情報は、Red Hat Virtualization Administration Guide の Logical Networks を参照してください。
-
director とコントローラー用仮想マシンの仮想 NIC で
no_filterを設定し、仮想マシンを再起動します。これにより、コントローラー用仮想マシンにアタッチされたネットワークで MAC スプーフィングフィルターが無効化されます。詳しい情報は、Red Hat Virtualization Administration Guide の Virtual Network Interface Cards を参照してください。 オーバークラウドをデプロイして、新しい仮想コントローラーノードを環境に追加します。
(undercloud) [stack@undercloud ~]$ openstack overcloud deploy --templates
第27章 高度なコンテナーイメージ管理の実施
デフォルトのコンテナーイメージ設定は、ほとんどの環境に対応します。状況によっては、コンテナーイメージ設定にバージョンの固定などのカスタマイズが必要になる場合があります。
27.1. アンダークラウド用コンテナーイメージの固定
特定の状況では、アンダークラウド用に特定のコンテナーイメージバージョンのセットが必要な場合があります。そのような場合には、イメージを特定のバージョンに固定する必要があります。イメージに固定するには、コンテナー設定ファイルを生成および変更し、続いてアンダークラウドのロールデータをコンテナー設定ファイルと組み合わせ、サービスとコンテナーイメージのマッピングが含まれる環境ファイルを生成する必要があります。次に、この環境ファイルを undercloud.conf ファイルの custom_env_files パラメーターに追加します。
手順
-
アンダークラウドホストに
stackユーザーとしてログインします。 --output-env-fileオプションを指定してopenstack tripleo container image prepare defaultコマンドを実行し、デフォルトのイメージ設定が含まれるファイルを生成します。$ sudo openstack tripleo container image prepare default \ --output-env-file undercloud-container-image-prepare.yaml
環境の要件に応じて、
undercloud-container-image-prepare.yamlファイルを変更します。-
tag:パラメーターを削除して、director がtag_from_label:パラメーターを使用できるようにします。director はこのパラメーターを使用して各コンテナーイメージの最新バージョンを特定し、それぞれのイメージをプルし、director のコンテナーレジストリーの各イメージをタグ付けします。 - アンダークラウドの Ceph ラベルを削除します。
-
neutron_driver:パラメーターが空であることを確認します。OVN はアンダークラウドでサポートされないため、このパラメーターをOVNに設定しないでください。 コンテナーイメージレジストリーの認証情報を追加します。
ContainerImageRegistryCredentials: registry.redhat.io: myser: 'p@55w0rd!'注記image-serveレジストリーがまだインストールされていないので、新しいアンダークラウドのアンダークラウドレジストリーにコンテナーイメージをプッシュすることはできません。push_destinationの値をfalseに設定するか、またはカスタム値を使用して、イメージを直接ソースからプルする必要があります。詳細は、コンテナーイメージ準備のパラメーター を参照してください。
-
カスタムの
undercloud-container-image-prepare.yamlファイルと組み合わせたアンダークラウドのロールファイルを使用する、新たなコンテナーイメージ設定ファイルを作成します。$ sudo openstack tripleo container image prepare \ -r /usr/share/openstack-tripleo-heat-templates/roles_data_undercloud.yaml \ -e undercloud-container-image-prepare.yaml \ --output-env-file undercloud-container-images.yaml
undercloud-container-images.yamlファイルは、サービスパラメーターのコンテナーイメージへのマッピングが含まれる環境ファイルです。たとえば、OpenStack Identity (keystone) は、ContainerKeystoneImageパラメーターを使用してそのコンテナーイメージを定義します。ContainerKeystoneImage: undercloud.ctlplane.localdomain:8787/rhosp-rhel9/openstack-keystone:17.0
コンテナーイメージタグは
{version}-{release}形式に一致することに注意してください。-
undercloud.confファイルのcustom_env_filesパラメーターにundercloud-container-images.yamlファイルを追加します。アンダークラウドのインストールを実施する際に、アンダークラウドサービスはこのファイルから固定されたコンテナーイメージのマッピングを使用します。
27.2. オーバークラウド用コンテナーイメージのピニング
特定の状況では、オーバークラウド用に特定のコンテナーイメージバージョンのセットが必要な場合があります。そのような場合には、イメージを特定のバージョンに固定する必要があります。イメージに固定するには、containers-prepare-parameter.yaml ファイルを作成して、このファイルを使用してアンダークラウドレジストリーにコンテナーイメージをプルし、固定されたイメージの一覧が含まれる環境ファイルを生成する必要があります。
たとえば、containers-prepare-parameter.yaml ファイルに以下の内容が含まれる場合があります。
parameter_defaults:
ContainerImagePrepare:
- push_destination: true
set:
name_prefix: openstack-
name_suffix: ''
namespace: registry.redhat.io/rhosp-rhel9
neutron_driver: ovn
tag_from_label: '{version}-{release}'
ContainerImageRegistryCredentials:
registry.redhat.io:
myuser: 'p@55w0rd!'
ContainerImagePrepare パラメーターには、単一のルール set が含まれます。このルール set には tag パラメーターを含めないでください。各コンテナーイメージの最新バージョンとリリースを特定するのに、tag_from_label パラメーターを使用する必要があります。director はこのルール set を使用して各コンテナーイメージの最新バージョンを特定し、それぞれのイメージをプルし、director のコンテナーレジストリーの各イメージをタグ付けします。
手順
openstack tripleo container image prepareコマンドを実行します。このコマンドは、containers-prepare-parameter.yamlファイルで定義されたソースからすべてのイメージをプルします。固定されたコンテナーイメージの一覧が含まれる出力ファイルを指定するには、--output-env-fileを追加します。$ sudo openstack tripleo container image prepare -e /home/stack/templates/containers-prepare-parameter.yaml --output-env-file overcloud-images.yaml
overcloud-images.yamlファイルは、サービスパラメーターのコンテナーイメージへのマッピングが含まれる環境ファイルです。たとえば、OpenStack Identity (keystone) は、ContainerKeystoneImageパラメーターを使用してそのコンテナーイメージを定義します。ContainerKeystoneImage: undercloud.ctlplane.localdomain:8787/rhosp-rhel9/openstack-keystone:17.0
コンテナーイメージタグは
{version}-{release}形式に一致することに注意してください。openstack overcloud deployコマンドを実行する際に、containers-prepare-parameter.yamlおよびovercloud-images.yamlファイルを特定の順序で環境ファイルコレクションに含めます。$ openstack overcloud deploy --templates \ ... -e /home/stack/containers-prepare-parameter.yaml \ -e /home/stack/overcloud-images.yaml \ ...
オーバークラウドサービスは、overcloud-images.yaml ファイルに一覧表示されている固定されたイメージを使用します。
第28章 director のエラーに関するトラブルシューティング
director プロセスの特定の段階で、エラーが発生する可能性があります。本項では、典型的な問題の診断について説明します。
28.1. ノードの登録に関するトラブルシューティング
ノード登録における問題は、通常ノードの情報が間違っていることが原因で発生します。このような場合には、ノードの情報が含まれるテンプレートファイルを検証して、インポートされたノードの情報を修正します。
手順
stackrcファイルを取得します。$ source ~/stackrc
--validate-onlyオプションを指定して、ノードのインポートコマンドを実行します。このオプションを指定した場合には、インポートを実施せずにノードのテンプレートを検証します。(undercloud) $ openstack overcloud node import --validate-only ~/nodes.json Waiting for messages on queue 'tripleo' with no timeout. Successfully validated environment file
インポートしたノードの誤った情報を修正するには、
openstack baremetalコマンドを実行してノードの情報を更新します。ネットワーク設定の詳細を変更する方法を、以下の例に示します。インポートしたノードに割り当てられたポートの UUID を特定します。
$ source ~/stackrc (undercloud) $ openstack baremetal port list --node [NODE UUID]
MAC アドレスを更新します。
(undercloud) $ openstack baremetal port set --address=[NEW MAC] [PORT UUID]
ノードの新しい IPMI アドレスを設定します。
(undercloud) $ openstack baremetal node set --driver-info ipmi_address=[NEW IPMI ADDRESS] [NODE UUID]
28.2. ハードウェアのイントロスペクションに関するトラブルシューティング
Bare Metal Provisioning インスペクタサービスの Ironic-inspector は、インスペクション RAM ディスクが応答しない場合、デフォルトの 1 時間後にタイムアウトします。タイムアウトは検査 RAM ディスクのバグを示している可能性がありますが、通常は環境の設定ミスが原因でタイムアウトが発生します。
一般的な環境設定ミスの問題を診断して解決し、イントロスペクションプロセスが最後まで確実に実行されるようにすることができます。
手順
stackrcアンダークラウド認証情報ファイルを入手します。$ source ~/stackrc
ノードを
manageableの状態にします。イントロスペクションは、デプロイメント用を意味するavailableの状態にあるノードを検査しません。availableの状態にあるノードを検査するには、イントロスペクションの前にノードのステータスをmanageableの状態に変更します。(undercloud)$ openstack baremetal node manage <node_uuid>
イントロスペクションのデバッグ中にイントロスペクション RAM ディスクへの一時的なアクセスを設定するには、
sshkeyパラメーターを使用して、公開 SSH キーを/httpboot/inspector.ipxeファイルのkernel設定に追加します。kernel http://192.2.0.1:8088/agent.kernel ipa-inspection-callback-url=http://192.168.0.1:5050/v1/continue ipa-inspection-collectors=default,extra-hardware,logs systemd.journald.forward_to_console=yes BOOTIF=${mac} ipa-debug=1 ipa-inspection-benchmarks=cpu,mem,disk selinux=0 sshkey="<public_ssh_key>"ノード上でイントロスペクションを実行します。
(undercloud)$ openstack overcloud node introspect <node_uuid> --provide
イントロスペクションの完了後にノードの状態を
availableに変更するには、--provideオプションを使用します。dnsmasqログでノードの IP アドレスを特定します。(undercloud)$ sudo tail -f /var/log/containers/ironic-inspector/dnsmasq.log
エラーが発生する場合には、root ユーザーおよび一時アクセス用の詳細を使用してノードにアクセスします。
$ ssh root@192.168.24.105
イントロスペクション中にノードにアクセスして、診断コマンドを実行してイントロスペクションの失敗に関するトラブルシューティングを行います。
イントロスペクションのプロセスを停止するには、以下のコマンドを実行します。
(undercloud)$ openstack baremetal introspection abort <node_uuid>
プロセスがタイムアウトするまで待つことも可能です。
注記イントロスペクションの最初の中止後、Red Hat OpenStack Platform director は実行を 3 回試みます。イントロスペクションを完全に中止するには、それぞれの試行時に
openstack baremetal introspection abortコマンドを実行します。
28.3. オーバークラウドの作成およびデプロイメントに関するトラブルシューティング
オーバークラウドの初回作成は、OpenStack Orchestration (heat) サービスにより実行されます。オーバークラウドのデプロイメントに失敗した場合には、OpenStack クライアントおよびサービスログファイルを使用して、失敗したデプロイメントの診断を行います。
手順
stackrcファイルを取得します。$ source ~/stackrc
デプロイメントのエラー発生ステップ確認コマンドを実行します。
$ openstack overcloud failures
以下のコマンドを実行して、エラーの詳細を表示します。
(undercloud) $ openstack stack failures list <OVERCLOUD_NAME> --long
-
<OVERCLOUD_NAME>を実際のオーバークラウドの名前に置き換えてください。
-
以下のコマンドを実行し、エラーが発生したスタックを特定します。
(undercloud) $ openstack stack list --nested --property status=FAILED
28.4. ノードのプロビジョニングに関するトラブルシューティング
OpenStack Orchestration (heat) サービスは、プロビジョニングプロセスを制御します。ノードのプロビジョニングに失敗した場合には、OpenStack クライアントおよびサービスログファイルを使用して、問題の診断を行います。
手順
stackrcファイルを取得します。$ source ~/stackrc
Bare Metal サービスをチェックして、全登録ノードおよびそれらの現在の状態を表示します。
(undercloud) $ openstack baremetal node list +----------+------+---------------+-------------+-----------------+-------------+ | UUID | Name | Instance UUID | Power State | Provision State | Maintenance | +----------+------+---------------+-------------+-----------------+-------------+ | f1e261...| None | None | power off | available | False | | f0b8c1...| None | None | power off | available | False | +----------+------+---------------+-------------+-----------------+-------------+
プロビジョニングに使用できるすべてのノードは、以下の状態でなければなりません。
-
Maintenance:
Falseに設定。 -
Provision State: プロビジョニングの前に
availableに設定。
-
Maintenance:
ノードの
MaintenanceがFalseに設定されていない場合、またはProvision Stateがavailableに設定されていない場合は、次の表を使用して問題と解決策を特定します。問題 原因 ソリューション Maintenance が自動的に
Trueに設定される。director がノードの電源管理にアクセスすることができない。
ノードの電源管理の認証情報を確認します。
Provision State は
availableに設定されているが、ノードがプロビジョニングされない。ベアメタルのデプロイメントが開始される前に問題が生じた。
プロファイルおよびフレーバーのマッピングを含め、ノードの詳細を確認します。ノードのハードウェア詳細がフレーバーの要件を満たしていることを確認します。
Provision State がノードの
wait call-backに設定される。このノードのプロビジョニングプロセスがまだ終了していない。
このステータスが変わるまで待ちます。あるいは、ノードの仮想コンソールに接続し、出力を確認します。
Provision State および Power State はそれぞれ
activeおよびpower onだが、ノードが応答しない。ノードのプロビジョニングは正常に終了したが、デプロイメント後の設定ステップで問題が生じている。
ノード設定のプロセスを診断します。ノードの仮想コンソールに接続し、出力を確認します。
Provision State が
errorまたはdeploy failedである。ノードのプロビジョニングに失敗している。
openstack baremetal node showコマンドを使用してベアメタルノードの詳細を表示し、エラーに関する説明が含まれるlast_errorフィールドを確認します。
関連情報
28.5. プロビジョニング時の IP アドレス競合に関するトラブルシューティング
対象のホストにすでに使用中の IP アドレスが割り当てられている場合には、イントロスペクションおよびデプロイメントのタスクは失敗します。このタスク失敗を防ぐには、プロビジョニングネットワークのポートスキャンを実行して、検出の IP アドレス範囲とホストの IP アドレス範囲が解放されているかどうかを確認します。
手順
nmapをインストールします。$ sudo dnf install nmap
nmapを使用して、アクティブなアドレスの IP アドレス範囲をスキャンします。この例では、192.168.24.0/24 の範囲をスキャンします。この値は、プロビジョニングネットワークの IP サブネットに置き換えてください (CIDR 表記のビットマスク)。$ sudo nmap -sn 192.168.24.0/24
nmapスキャンの出力を確認します。たとえば、アンダークラウドおよびサブネット上に存在するその他のホストの IP アドレスを確認する必要があります。$ sudo nmap -sn 192.168.24.0/24 Starting Nmap 6.40 ( http://nmap.org ) at 2015-10-02 15:14 EDT Nmap scan report for 192.168.24.1 Host is up (0.00057s latency). Nmap scan report for 192.168.24.2 Host is up (0.00048s latency). Nmap scan report for 192.168.24.3 Host is up (0.00045s latency). Nmap scan report for 192.168.24.5 Host is up (0.00040s latency). Nmap scan report for 192.168.24.9 Host is up (0.00019s latency). Nmap done: 256 IP addresses (5 hosts up) scanned in 2.45 seconds
アクティブな IP アドレスが undercloud.conf の IP アドレス範囲と競合している場合には、オーバークラウドノードのイントロスペクションまたはデプロイを実行する前に、IP アドレスの範囲を変更するか、IP アドレスを解放するかのいずれかを行う必要があります。
28.6. No Valid Host Found エラーに関するトラブルシューティング
/var/log/nova/nova-conductor.log に、以下のエラーが含まれる場合があります。
NoValidHost: No valid host was found. There are not enough hosts available.
このエラーは、Compute Scheduler が新規インスタンスをブートするのに適したベアメタルノードを検出できない場合に発生します。通常これは、Compute サービスが検出を想定しているリソースと、Bare Metal サービスが Compute に通知するリソースが、一致していないことを意味します。不一致によるエラーがあることを確認するには、以下の手順を実施します。
手順
stackrcファイルを取得します。$ source ~/stackrc
ノードのイントロスペクションが成功したことを確認します。イントロスペクションが失敗する場合には、各ノードに必要な ironic ノードの属性が含まれていることを確認してください。
(undercloud) $ openstack baremetal node show [NODE UUID]
propertiesJSON フィールドのcpus、cpu_arch、memory_mb、およびlocal_gbキーに有効な値が指定されていることを確認してください。ノードにマッピングされた Compute フレーバーが、必要なノード数のノード属性を超えないようにしてください。
(undercloud) $ openstack flavor show [FLAVOR NAME]
-
openstack baremetal node listコマンドを実行して、available の状態にあるノードが十分にあることを確認します。ノードの状態がmanageableの場合には、通常イントロスペクションに失敗します。 openstack baremetal node listコマンドを実行し、ノードがメンテナーンスモードに設定されていないことを確認します。ノードが自動的にメンテナーンスモードに切り替わる場合には、電源管理の認証情報が間違っていることが一般的な原因として考えられます。電源管理の認証情報を確認し、メンテナーンスモードを解除します。(undercloud) $ openstack baremetal node maintenance unset [NODE UUID]
-
プロファイルの自動タグ付けを使用している場合には、各フレーバー/プロファイルに対応するノードが十分に存在することを確認します。ノードで
openstack baremetal node showコマンドを実行し、propertiesフィールドのcapabilitiesキーを確認します。たとえば、Compute ロールにタグ付けされたノードには、profile:computeの値が含まれます。 イントロスペクションの後にノードの情報が Bare Metal から Compute に反映されるのを待つ必要があります。ただし、一部のステップを手動で実行した場合、短時間 Compute サービス (nova) がノードを利用できない状態になる可能性があります。以下のコマンドを使用して、システム内の合計リソースをチェックします。
(undercloud) $ openstack hypervisor stats show
28.7. コンテナーの設定に関するトラブルシューティング
Red Hat OpenStack Platform director は、podman を使用してコンテナーを管理し、puppet を使用してコンテナー設定を作成します。以下の手順で、エラーが発生した場合にコンテナーを診断する方法について説明します。
ホストへのアクセス
stackrcファイルを取得します。$ source ~/stackrc
障害の発生したコンテナーがあるノードの IP アドレスを取得します。
(undercloud) $ metalsmith list
ノードにログインします。
(undercloud) $ ssh tripleo-admin@192.168.24.60
障害が発生したコンテナーの識別
すべてのコンテナーを表示します。
$ sudo podman ps --all
障害の発生したコンテナーを特定します。障害の発生したコンテナーは、通常ゼロ以外のステータスで終了します。
コンテナーログの確認
各コンテナーは、主要プロセスからの標準出力を保持します。この出力をログとして使用し、コンテナー実行時に実際に何が発生したのかを特定するのに役立てます。たとえば、
keystoneコンテナーのログを確認するには、以下のコマンドを実行します。$ sudo podman logs keystone
多くの場合、このログにコンテナー障害の原因に関する情報が含まれます。
ホストには、失敗したサービスの
stdoutログも保持されます。stdoutログは、/var/log/containers/stdouts/に保存されます。たとえば、障害の発生したkeystoneコンテナーのログを確認するには、以下のコマンドを使用します。$ cat /var/log/containers/stdouts/keystone.log
コンテナーの検査
状況によっては、コンテナーに関する情報を検証する必要がある場合があります。たとえば、以下のコマンドを使用して keystone コンテナーのデータを確認します。
$ sudo podman inspect keystone
このコマンドにより、ローレベルの設定データが含まれた JSON オブジェクトが返されます。その出力を jq コマンドにパイプして、特定のデータを解析することが可能です。たとえば、keystone コンテナーのマウントを確認するには、以下のコマンドを実行します。
$ sudo podman inspect keystone | jq .[0].Mounts
--format オプションを使用して、データを単一行に解析することもできます。これは、コンテナーデータのセットに対してコマンドを実行する場合に役立ちます。たとえば、keystone コンテナーを実行するのに使用するオプションを再生成するには、以下のように inspect コマンドに --format オプションを指定して実行します。
$ sudo podman inspect --format='{{range .Config.Env}} -e "{{.}}" {{end}} {{range .Mounts}} -v {{.Source}}:{{.Destination}}:{{ join .Options "," }}{{end}} -ti {{.Config.Image}}' keystone
--format オプションは、Go 構文を使用してクエリーを作成します。
これらのオプションを podman run コマンドと共に使用して、トラブルシューティング目的のコンテナーを再度作成します。
$ OPTIONS=$( sudo podman inspect --format='{{range .Config.Env}} -e "{{.}}" {{end}} {{range .Mounts}} -v {{.Source}}:{{.Destination}}{{if .Mode}}:{{.Mode}}{{end}}{{end}} -ti {{.Config.Image}}' keystone )
$ sudo podman run --rm $OPTIONS /bin/bashコンテナー内でのコマンドの実行
状況によっては、特定の Bash コマンドでコンテナー内の情報を取得する必要がある場合があります。このような場合には、以下の podman コマンドを使用して、稼働中のコンテナー内でコマンドを実行します。たとえば、podman exec コマンドを実行して、keystone コンテナー内でコマンドを実行します。
$ sudo podman exec -ti keystone <COMMAND>
-ti オプションを指定すると、コマンドは対話式の擬似ターミナルで実行されます。
-
<COMMAND>を実行するコマンドに置き換えてください。たとえば、各コンテナーには、サービスの接続を確認するためのヘルスチェックスクリプトがあります。keystoneにヘルスチェックスクリプトを実行するには、以下のコマンドを実行します。
$ sudo podman exec -ti keystone /openstack/healthcheck
コンテナーのシェルにアクセスするには、コンテナー内で実行するコマンドとして /bin/bash を使用して podman exec を実行します。
$ sudo podman exec -ti keystone /bin/bash
コンテナーファイルシステムの確認
障害の発生したコンテナーのファイルシステムを確認するには、
podman mountコマンドを実行します。たとえば、障害の発生したkeystoneコンテナーのファイルシステムを確認するには、以下のコマンドを実行します。$ sudo podman mount keystone
これによりマウント位置が表示され、ファイルシステムの内容を確認することができます。
/var/lib/containers/storage/overlay/78946a109085aeb8b3a350fc20bd8049a08918d74f573396d7358270e711c610/merged
これは、コンテナー内の Puppet レポートを確認する際に役立ちます。これらのレポートは、コンテナーのマウント内の
var/lib/puppet/ディレクトリーにあります。
コンテナーのエクスポート
コンテナーに障害が発生した場合には、ファイルの内容を詳細に調べる必要があります。この場合は、コンテナーの全ファイルシステムを tar アーカイブとしてエクスポートすることができます。たとえば、keystone コンテナーのファイルシステムをエクスポートするには、以下のコマンドを実行します。
$ sudo podman export keystone -o keystone.tar
このコマンドにより keystone.tar アーカイブが作成されます。これを抽出して、調べることができます。
28.8. コンピュートノードの異常に関するトラブルシューティング
コンピュートノードは、Compute サービスを使用して、ハイパーバイザーベースの操作を実行します。これは、このサービスを中心にコンピュートノードのメインの診断が行われていることを意味します。
手順
stackrcファイルを取得します。$ source ~/stackrc
障害が発生したコンピュートノードの IP アドレスを取得します。
(undercloud) $ openstack server list
ノードにログインします。
(undercloud) $ ssh tripleo-admin@192.168.24.60
root ユーザーに変更します。
$ sudo -i
コンテナーのステータスを表示します。
$ sudo podman ps -f name=nova_compute
-
コンピュートノードの主なログファイルは
/var/log/containers/nova/nova-compute.logです。コンピュートノードの通信で問題が発生した場合、このファイルを使用して診断を始めます。 - コンピュートノードでメンテナーンスを実行する場合には、既存のインスタンスをホストから稼働中のコンピュートノードに移行し、ノードを無効にします。
28.9. SOS レポートの作成
Red Hat に連絡して Red Hat OpenStack Platform に関するサポートを受ける必要がある場合は、SOS レポート を生成しなければならない場合があります。SOS レポート 作成についての詳しい情報は、以下のドキュメントを参照してください。
28.10. ログの場所
問題のトラブルシューティングを行う場合、以下のログを使用してアンダークラウドおよびオーバークラウドについての情報を収集します。
表28.1 アンダークラウドおよびオーバークラウドノード両方に関するログ
| 情報 | ログの場所 |
|---|---|
| コンテナー化されたサービスに関するログ |
|
| コンテナー化されたサービスからの標準出力 |
|
| Ansible の設定に関するログ |
|
表28.2 アンダークラウドノードに関する追加のログ
| 情報 | ログの場所 |
|---|---|
|
|
|
| アンダークラウドのインストールに関するログ |
|
表28.3 オーバークラウドノードに関する追加のログ
| 情報 | ログの場所 |
|---|---|
| cloud-init に関するログ |
|
| 高可用性に関するログ |
|
第29章 アンダークラウドおよびオーバークラウドサービスについてのヒント
本項では、アンダークラウド上の特定の OpenStack サービスのチューニングと管理についてアドバイスを行います。
29.1. デプロイメントパフォーマンスのチューニング
Red Hat OpenStack Platform director は、OpenStack Orchestration (heat) を使用してメインのデプロイメントおよびプロビジョニング機能を実施します。heat は一連のワーカーを使用してデプロイメントタスクを実行します。デフォルトのワーカー数を計算するには、director の heat 設定ではアンダークラウドの合計 CPU スレッド数を 2 で割ります。ここでは、スレッド数とは CPU コア数にハイパースレッディングの値を掛けたものを指します。たとえば、アンダークラウドの CPU スレッド数が 16 の場合には、デフォルトでは heat により 8 つのワーカーが提供されます。デフォルトでは、director の設定に最小および最大のワーカー数も適用されます。
| サービス | 最小値 | 最大値 |
|---|---|---|
| OpenStack Orchestration (heat) | 4 | 24 |
ただし、環境ファイルの HeatWorkers パラメーターを使用して、手動でワーカー数を設定することができます。
heat-workers.yaml
parameter_defaults: HeatWorkers: 16
undercloud.conf
custom_env_files: heat-workers.yaml
29.2. コンテナーでの swift-ring-builder の実行
Object Storage (swift) リングを管理するには、サーバーコンテナー内で swift-ring-builder コマンドを使用します。
-
swift_object_server -
swift_container_server -
swift_account_server
たとえば、swift オブジェクトリングの情報を表示するには、以下のコマンドを実行します。
$ sudo podman exec -ti -u swift swift_object_server swift-ring-builder /etc/swift/object.builder
アンダークラウドおよびオーバークラウドノードの両方で、このコマンドを実行することができます。
29.3. HAProxy の SSL/TLS 暗号ルールの変更
アンダークラウドで SSL/TLS を有効にした場合には (「director の設定パラメーター」を参照)、HAProxy 設定で使用する SSL/TLS の暗号とルールを強化することをお勧めします。この強化は、POODLE TLS 脆弱性 などの SSL/TLS の脆弱性を回避するのに役立ちます。
hieradata_override のアンダークラウド設定オプションを使用して、以下の hieradata を設定します。
- tripleo::haproxy::ssl_cipher_suite
- HAProxy で使用する暗号スイート
- tripleo::haproxy::ssl_options
- HAProxy で使用する SSL/TLS ルール
たとえば、以下のような暗号およびルールを使用することができます。
-
暗号:
ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS -
ルール:
no-sslv3 no-tls-tickets
hieradata オーバーライドファイル (haproxy-hiera-overrides.yaml) を作成して、以下の内容を記載します。
tripleo::haproxy::ssl_cipher_suite: ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS tripleo::haproxy::ssl_options: no-sslv3 no-tls-tickets
暗号のコレクションは、改行せずに 1 行に記述します。
openstack undercloud install を実行する前に作成した hierradata オーバーライドファイルを使用するように、undercloud.conf ファイルの hieradata_override パラメーターを設定します。
[DEFAULT] ... hieradata_override = haproxy-hiera-overrides.yaml ...
第30章 電源管理ドライバー
IPMI は、director が電源管理制御に使用する主要な手法ですが、director は他の電源管理タイプもサポートします。この付録には、director がサポートする電源管理機能の一覧が記載されています。オーバークラウドのノードを登録する際に、これらの電源管理設定を使用します。詳しい情報は、オーバークラウドノードの登録 を参照してください。
30.1. Intelligent Platform Management Interface (IPMI)
Baseboard Management Controller (BMC) を使用する際の標準的な電源管理手法
- pm_type
-
このオプションを
ipmiに設定します。 - pm_user、pm_password
- IPMI のユーザー名およびパスワード
- pm_addr
- IPMI コントローラーの IP アドレス
- pm_port (オプション)
- IPMI コントローラーに接続するためのポート
30.2. Redfish
Distributed Management Task Force (DMTF) の開発した、IT インフラストラクチャー向け標準 RESTful API
- pm_type
-
このオプションを
redfishに設定します。 - pm_user、pm_password
- Redfish のユーザー名およびパスワード
- pm_addr
- Redfish コントローラーの IP アドレス
- pm_system_id
-
システムリソースへの正規パス。このパスには、そのシステムの root サービス、バージョン、パス/一意 ID を含める必要があります。たとえば、
/redfish/v1/Systems/CX34R87。 - redfish_verify_ca
-
ベースボード管理コントローラー (BMC) の Redfish サービスが、認識済み認証局 (CA) により署名された有効な TLS 証明書を使用するように設定されていない場合、ironic の Redfish クライアントは BMC への接続に失敗します。
redfish_verify_caオプションをfalseに設定して、エラーをミュートします。ただし、BMC 認証を無効にすると、BMC のアクセスセキュリティーが低下するので、注意してください。
30.3. Dell Remote Access Controller (DRAC)
DRAC は、電源管理やサーバー監視などの帯域外 (OOB) リモート管理機能を提供するインターフェイスです。
- pm_type
-
このオプションを
idracに設定します。 - pm_user、pm_password
- DRAC のユーザー名およびパスワード
- pm_addr
- DRAC ホストの IP アドレス
30.4. Integrated Lights-Out (iLO)
Hewlett-Packard の iLO は、電源管理やサーバー監視などの帯域外 (OOB) リモート管理機能を提供するインターフェイスです。
- pm_type
-
このオプションを
iloに設定します。 - pm_user、pm_password
- iLO のユーザー名およびパスワード
- pm_addr
iLO インターフェイスの IP アドレス
-
このドライバーを有効にするには、
undercloud.confのenabled_hardware_typesオプションにiloを追加してから、openstack undercloud installを再実行します。 - 正常にイントロスペクションを実施するためには、HP ノードの ILO ファームウェアバージョンは、最低でも 1.85 (2015 年 5 月 13 日版) でなければなりません。この ILO ファームウェアバージョンを使用するノードで、director は正常にテストされています。
- 共有 iLO ポートの使用はサポートされません。
-
このドライバーを有効にするには、
30.5. Fujitsu Integrated Remote Management Controller (iRMC)
Fujitsu iRMC は、LAN 接続と拡張された機能を統合した Baseboard Management Controller (BMC) です。このドライバーは、iRMC に接続されたベアメタルシステムの電源管理にフォーカスしています。
iRMC S4 以降のバージョンが必要です。
- pm_type
-
このオプションを
irmcに設定します。 - pm_user、pm_password
iRMC インターフェイスのユーザー名とパスワード
重要iRMC ユーザーには
ADMINISTRATOR権限が必要です。- pm_addr
- iRMC インターフェイスの IP アドレス
- pm_port (オプション)
- iRMC の操作に使用するポート。デフォルトは 443 です。
- pm_auth_method (オプション)
-
iRMC 操作の認証方法。
basicまたはdigestを使用します。デフォルトはbasicです。 - pm_client_timeout (オプション)
- iRMC 操作のタイムアウト (秒単位)デフォルトは 60 秒です。
- pm_sensor_method (オプション)
センサーデータの取得方法。
ipmitoolまたはscciです。デフォルトはipmitoolです。-
このドライバーを有効にするには、
undercloud.confのenabled_hardware_typesオプションにirmcを追加してから、openstack undercloud installコマンドを再実行します。
-
このドライバーを有効にするには、
30.6. Red Hat Virtualization
このドライバーにより、RESTful API を介して、Red Hat Virtualization (RHV) 内の仮想マシンを制御することができるようになります。
- pm_type
-
このオプションを
staging-ovirtに設定します。 - pm_user、pm_password
-
RHV 環境のユーザー名およびパスワード。ユーザー名には、認証プロバイダーも含めます。たとえば、
admin@internal。 - pm_addr
- RHV REST API の IP アドレス
- pm_vm_name
- 制御する仮想マシンの名前
- mac
ノード上のネットワークインターフェイスの MAC アドレス一覧。各システムのプロビジョニング NIC の MAC アドレスのみを使用します。
-
このドライバーを有効にするには、
undercloud.confのenabled_hardware_typesオプションにstaging-ovirtを追加してから、openstack undercloud installコマンドを再実行します。
-
このドライバーを有効にするには、
30.7. 手動管理ドライバー
電源管理を持たないベアメタルデバイスを制御するには、manual-management ドライバーを使用します。director は登録されたベアメタルデバイスを制御しないので、イントロスペクションおよびデプロイメントの特定の時点で、手動で電源管理操作を実施する必要があります。
このオプションは、テストおよび評価の目的でのみ利用することができます。Red Hat OpenStack Platform のエンタープライズ環境には推奨していません。
- pm_type
このオプションを
manual-managementに設定します。- このドライバーは、電源管理を制御しないので、認証情報は使用しません。
-
このドライバーを有効にするには、
undercloud.confのenabled_hardware_typesオプションにmanual-managementを追加してから、openstack undercloud installコマンドを再実行します。 -
instackenv.jsonノードインベントリーファイルで、手動で管理するノードのpm_typeをmanual-managementに設定します。
イントロスペクション
-
ノードのイントロスペクションを実行する際には、
openstack overcloud node introspectコマンドを実行した後に手動でノードを起動します。ノードが PXE を介して起動することを確認します。 -
ノードクリーニングを有効にしている場合は、
openstack baremetal node listコマンドを実行した際にIntrospection completedメッセージが表示され、各ノードの状態がclean waitになった後、手動でノードを再起動するようにしてください。ノードが PXE を介して起動することを確認します。 - イントロスペクションとクリーニングのプロセスが完了したら、ノードをシャットダウンします。
Deployment
-
オーバークラウドデプロイメントを実行する場合は、
openstack baremetal node listコマンドを使用してノードのステータスを確認してください。ノードのステータスがdeployingからwait call-backに変わるまで待ってから、ノードを手動で開始します。ノードが PXE を介して起動することを確認します。 -
オーバークラウドプロビジョニングプロセスが完了すると、ノードはシャットダウンします。設定プロセスを開始するには、ディスクからノードを起動する必要があります。プロビジョニングの完了を確認するには、
openstack baremetal node listコマンドを使用してノードのステータスを確認し、ノードのステータスが各ノードでactiveに変わるまで待ちます。ノードステータスがactiveな場合、プロビジョニングされたオーバークラウドノードを手動で起動します。