director のインストールと使用方法
Red Hat OpenStack Platform director を使用した OpenStack クラウド作成のエンドツーエンドシナリオ
概要
多様性を受け入れるオープンソースの強化
Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。この取り組みは膨大な作業を要するため、今後の複数のリリースで段階的に用語の置き換えを実施して参ります。詳細は、Red Hat CTO である Chris Wright のメッセージ を参照してください。
第1章 director の概要
Red Hat OpenStack Platform (RHOSP) director は、完全な RHOSP 環境のインストールおよび管理を行うためのツールセットです。director は、主に OpenStack プロジェクト TripleO をベースとしています。director により、完全に機能するスリムで堅牢な RHOSP 環境をインストールすることができます。この環境を使用して、OpenStack ノードして使用するベアメタルシステムのプロビジョニングおよび制御を行うことができます。
director は、アンダークラウドとオーバークラウドという 2 つの主要な概念を採用しています。まずアンダークラウドをインストールし、続いてアンダークラウドをツールとして使用してオーバークラウドをインストールおよび設定します。
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 Compute (nova): ベアメタルノードの管理
- OpenStack Networking (neutron) および Open vSwitch: ベアメタルノードのネットワークの制御
- OpenStack Image サービス (glance): director がベアメタルマシンに書き込むイメージの格納
- OpenStack Orchestation (heat) および Puppet: director がオーバークラウドイメージをディスクに書き込んだ後のノードのオーケストレーションおよび設定
- OpenStack Workflow サービス (mistral): プランのインポートやデプロイなど、特定の director 固有のアクションに対してワークフローセットを提供します。
- OpenStack Messaging Service (zaqar): OpenStack Workflow サービスのメッセージサービスを提供します。
OpenStack Object Storage (swift): 以下のさまざまな OpenStack Platform のコンポーネントに対してオブジェクトストレージを提供します。
- OpenStack Image サービスのイメージストレージ
- OpenStack Bare Metal のイントロスペクションデータ
- OpenStack Workflow サービスのデプロイメントプラン
1.2. オーバークラウドについて
オーバークラウドは、アンダークラウドが構築することで得られる Red Hat OpenStack Platform (RHOSP) 環境です。オーバークラウドは、さまざまなロールを持つ複数のノードで設定されます。このノード設定は、希望する OpenStack Platform 環境をベースに定義されます。アンダークラウドには、以下に示すオーバークラウドのデフォルトノードロールセットが含まれます。
- Controller
Controller ノードは、OpenStack 環境に管理、ネットワーク、高可用性の機能を提供します。Controller ノード 3 台で高可用性クラスターを設定する OpenStack 環境が推奨されます。
デフォルトの Controller ノードロールは、以下のコンポーネントをサポートします。これらのサービスがすべてデフォルトで有効化されている訳ではありません。これらのコンポーネントの中には、有効にするのにカスタムの環境ファイルまたは事前にパッケージ化された環境ファイルを必要とするものがあります。
- 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
- Compute
Compute ノードは OpenStack 環境にCompute リソースを提供します。Compute ノードをさらに追加して、環境を徐々にスケールアウトすることができます。デフォルトの Compute ノードには、以下のコンポーネントが含まれます。
- OpenStack Compute (nova)
- KVM/QEMU
- OpenStack Telemetry (ceilometer) エージェント
- Open vSwitch
- ストレージ
ストレージノードは OpenStack 環境にストレージを提供します。以下のリストで、RHOSP のさまざまなストレージノード種別について説明します。
- Ceph Storage ノード: ストレージクラスターを設定するために使用します。それぞれのノードには、Ceph Object Storage Daemon (OSD) が含まれます。また、環境の一部として Ceph Storage ノードをデプロイする場合には、director により Ceph Monitor が Controller ノードにインストールされます。
Block Storage (cinder): 高可用性 Controller ノードの外部 Block Storage として使用します。このノードには、以下のコンポーネントが含まれます。
- OpenStack Block Storage (cinder) ボリューム
- OpenStack Telemetry エージェント
- Open vSwitch
Object Storage (swift): これらのノードは、OpenStack Swift の外部ストレージ層を提供します。Controller ノードは、Swift プロキシーを介してオブジェクトストレージノードにアクセスします。オブジェクトストレージノードには、以下のコンポーネントが含まれます。
- OpenStack Object Storage (swift) のストレージ
- OpenStack Telemetry エージェント
- Open vSwitch
1.3. Red Hat OpenStack Platform での高可用性について
Red Hat OpenStack Platform (RHOSP) director は、OpenStack Platform 環境に高可用性サービスを提供するために Controller ノードクラスターを使用します。それぞれのサービスについて、director はすべての Controller ノードに同じコンポーネントをインストールし、Controller ノードをまとめて単一のサービスとして管理します。このタイプのクラスター設定では、1 つの Controller ノードが機能しなくなった場合にフォールバックが可能です。これにより、OpenStack のユーザーには一定レベルの運用継続性が提供されます。
OpenStack Platform director は、複数の主要なソフトウェアを使用して、Controller ノード上のコンポーネントを管理します。
- Pacemaker: Pacemaker は、クラスターのリソースを管理します。Pacemaker は、クラスター内の全ノードにわたって OpenStack コンポーネントの可用性を管理および監視します。
- HA Proxy: クラスターに負荷分散およびプロキシーサービスを提供します。
- Galera: クラスター全体の RHOSP データベースを複製します。
- Memcached: データベースのキャッシュを提供します。
- バージョン 13 から、director を使用して Compute インスタンスの高可用性 (インスタンス HA) をデプロイできるようになりました。インスタンス HA により、Compute ノードで障害が発生した際に Compute ノードからインスタンスを自動的に退避させることができます。
1.4. Red Hat OpenStack Platform でのコンテナー化について
アンダークラウドおよびオーバークラウド上の各 OpenStack Platform サービスは、対応するノード上の個別の Linux コンテナー内で実行されます。このコンテナー化により、サービスを分離し、環境を維持し、Red Hat OpenStack Platform (RHOSP) をアップグレードすることができます。
Red Hat OpenStack Platform 16.2 では、Red Hat Enterprise Linux 8.4 オペレーティングシステムへのインストールがサポートされます。Red Hat Enterprise Linux 8.4 には Docker が含まれなくなり、Docker エコシステムに代わる新たなツールセットが用意されています。したがって、OpenStack Platform 16.2 では、Docker に代わるこれらの新しいツールにより、OpenStack Platform のデプロイメントおよびアップグレードを行います。
- Podman
Pod Manager (Podman) はコンテナー管理用のツールです。このツールには、ほとんどすべての Docker CLI コマンドが実装されています。ただし、Docker Swarm に関連するコマンドは含まれません。Podman は、Pod、コンテナー、およびコンテナーイメージを管理します。Podman と Docker の主な違いの 1 つは、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 (Compute ) を単一ノードにデプロイすると、数千単位のクライアントがある大規模なデプロイメントでの管理ができなくなる可能性があります。このような課題は、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 を参照してください。
マルチアーキテクチャークラウドでは、Red Hat は事前にインストール済みの Ceph 実装または外部の Ceph 実装のみをサポートします。詳細は、Integrating an Overcloud with an Existing Red Hat Ceph Cluster および Configuring the CPU architecture for the overcloud を参照してください。
第2章 アンダークラウドのプランニング
アンダークラウドに director を設定してインストールする前に、アンダークラウドホストを計画して、特定の要件を満たしていることを確認する必要があります。
2.1. コンテナー化されたアンダークラウド
アンダークラウドは、最終的な Red Hat OpenStack Platform (RHOSP) 環境 (オーバークラウドと呼ばれる) の設定、インストール、および管理をコントロールするノードです。アンダークラウドは、各 RHOSP コンポーネントサービスをコンテナーとして実行します。アンダークラウドは、これらのコンテナー化されたサービスを使用して、director という名前のツールセットを作成します。このツールセットは、オーバークラウドの作成と管理に使用されます。
アンダークラウドおよびオーバークラウドの両方でコンテナーが使用されているので、どちらも同じアーキテクチャーを使用してコンテナーをプル、設定、および実行します。このアーキテクチャーは、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 つのネットワークを使用し、データプレーンに別のネットワークを使用することを推奨します。OVS ブリッジの上にプロビジョニングおよびコントロールプレーンネットワークを作成しないでください。
プロビジョニングおよびコントロールプレーンネットワークは、Linux ボンディング上または個々のインターフェイスで設定できます。Linux ボンディングを使用する場合は、アクティブバックアップボンディングタイプとして設定します。
- 非 Controller ノードでは、プロビジョニングおよびコントロールプレーンネットワークのトラフィック量は比較的少なく、高帯域幅や負荷分散は必要ありません。
Controller では、プロビジョニングおよびコントロールプレーンネットワークに追加の帯域幅が必要です。帯域幅が増加する理由は、Controller が他のロールで多くのノードにサービスを提供するためです。環境に頻繁に変更を加える場合も、より多くの帯域幅が必要になります。
最高のパフォーマンスを得るには、50 を超える Compute ノードを備えた Controller (または 4 つを超えるベアメタルノードが同時にプロビジョニングされている場合) は、非 Controller ノードのインターフェイスの 4 〜 10 倍の帯域幅を備えている必要があります。
- 50 を超えるオーバークラウドノードがプロビジョニングされる場合、アンダークラウドはプロビジョニングネットワークへのより高い帯域幅の接続を持つ必要があります。
- ワークステーションから director マシンへのアクセスに使用する NIC を、プロビジョニングまたはコントロールプレーン NIC として使用しないでください。director のインストールでは、プロビジョニング NIC を使用してブリッジが作成され、リモート接続はドロップされます。director システムへリモート接続する場合には、外部 NIC を使用します。
プロビジョニングネットワークには、環境のサイズに適した IP 範囲が必要です。以下のガイドラインを使用して、この範囲に含めるべき IP アドレスの総数を決定してください。
- イントロスペクション中は、プロビジョニングネットワークに接続されているノードごとに少なくとも 1 つの一時 IP アドレスを含めます。
- デプロイメント中は、プロビジョニングネットワークに接続されているノードごとに少なくとも 1 つの永続的な IP アドレスを含めます。
- プロビジョニングネットワーク上のオーバークラウド高可用性クラスターの仮想 IP 用に、追加の IP アドレスを含めます。
- 環境のスケーリング用に、この範囲にさらに IP アドレスを追加します。
-
Controller ノードのネットワークカードまたはネットワークスイッチの異常がオーバークラウドサービスの可用性を阻害するのを防ぐには、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
-
ceph-ansible
Playbook は、アンダークラウドがデプロイするホスト 10 台につき 1 GB の常駐セットサイズ (RSS) を消費します。デプロイメントで新規または既存の Ceph クラスターを使用する場合は、それに応じてアンダークラウド用 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 Enterprise Linux 8.4 でホストされていること |
Red Hat Virtualization | 認定済みのハイパーバイザーとしてリストされている 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 8.4 ゲストをサポートしていることを確認してください。
仮想マシンの要件
仮想アンダークラウドのリソース要件は、ベアメタルのアンダークラウドの要件と似ています。ネットワークモデル、ゲスト 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_env
PAM モジュールのバッファーが固定されているため、no_proxy
の最大長は 1024 文字です。 -
一部のコンテナーでは、
/etc/environments
の環境変数が正しくバインドおよび解析されないため、これらのサービスの実行時に問題が発生します。詳細については、BZ#1916070: proxy configuration updates in /etc/environment files are not being picked up in containers correctly および BZ#1918408: mistral_executor container fails to properly set no_proxy environment parameter を参照してください。
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. アンダークラウドのリポジトリー
RHOSP (RHOSP) 16.2 は、Red Hat Enterprise Linux (RHEL) 8.4 上で実行されます。そのため、これらのリポジトリーからのコンテンツをそれぞれの RHEL バージョンにロックする必要があります。
-
Red Hat Satellite を使用してリポジトリーを同期する場合は、RHEL リポジトリーの特定バージョンを有効にすることができます。ただし、選択したバージョンに関係なく、リポジトリーラベルは同じままです。たとえば、BaseOS リポジトリーの 8.4 バージョンを有効にした場合、リポジトリー名には有効にした特定のバージョンが含まれますが、リポジトリーラベルは依然として
rhel-8-for-x86_64-baseos-eus-rpms
です。 -
advanced-virt-for-rhel-8-x86_64-rpms
およびadvanced-virt-for-rhel-8-x86_64-eus-rpms
リポジトリーは必要なくなりました。これらのリポジトリーを無効にするには、Red Hat ナレッジベースのソリューション記事 advanced-virt-for-rhel-8-x86_64-rpms are no longer required in OSP 16.2 を参照してください。
ここで指定する以外のリポジトリーは、サポートされません。別途推奨されない限り、以下の表に記載されている以外の製品またはリポジトリーを有効にしないでください。有効にすると、パッケージの依存関係の問題が発生する可能性があります。Extra Packages for Enterprise Linux (EPEL) を有効にしないでください。
コアリポジトリー
以下の表には、アンダークラウドをインストールするためのコアリポジトリーをまとめています。
名前 | リポジトリー | 要件の説明 |
---|---|---|
Red Hat Enterprise Linux 8 for x86_64 - BaseOS (RPMs) Extended Update Support (EUS) |
| x86_64 システム用ベースオペレーティングシステムのリポジトリー |
Red Hat Enterprise Linux 8 for x86_64 - AppStream (RPMs) |
| RHOSP の依存関係が含まれます。 |
Red Hat Enterprise Linux 8 for x86_64 - High Availability (RPMs) Extended Update Support (EUS) |
| RHEL の高可用性ツール。Controller ノードの高可用性に使用します。 |
Red Hat Ansible Engine 2.9 for RHEL 8 x86_64 (RPMs) |
| Ansible Engine for RHEL。最新バージョンの Ansible を提供するために使用されます。 |
RHOSP 16.2 for RHEL 8 (RPMs)。 |
| RHOSP director のパッケージが含まれるコア RHOSP リポジトリー。 |
Red Hat Fast Datapath for RHEL 8 (RPMS) |
| OpenStack Platform 用 Open vSwitch (OVS) パッケージを提供します。 |
Ceph リポジトリー
以下の表には、アンダークラウド用の Ceph Storage 関連のリポジトリーをまとめています。
名前 | リポジトリー | 要件の説明 |
---|---|---|
Red Hat Ceph Storage Tools 4 for RHEL 8 x86_64 (RPMs) |
|
Ceph Storage クラスターと通信するためのノード用のツールを提供します。オーバークラウドで Ceph Storage を使用する場合、または既存の Ceph Storage クラスターと統合する場合、アンダークラウドにはこのリポジトリーからの |
IBM POWER 用リポジトリー
次の表には、POWER PC アーキテクチャー上の RHOSP のリポジトリーのリストが含まれています。コアリポジトリーの該当リポジトリーの代わりに、これらのリポジトリーを使用してください。
名前 | リポジトリー | 要件の説明 |
---|---|---|
Red Hat Enterprise Linux for IBM Power, little endian - BaseOS (RPMs) |
| ppc64le システム用ベースオペレーティングシステムのリポジトリー |
Red Hat Enterprise Linux 8 for IBM Power, little endian - AppStream (RPMs) |
| RHOSP の依存関係が含まれます。 |
Red Hat Enterprise Linux 8 for IBM Power, little endian - High Availability (RPMs) |
| RHEL の高可用性ツール。Controller ノードの高可用性に使用します。 |
Red Hat Fast Datapath for RHEL 8 IBM Power, little endian (RPMS) |
| OpenStack Platform 用 Open vSwitch (OVS) パッケージを提供します。 |
Red Hat Ansible Engine 2.9 for RHEL 8 IBM Power, little endian (RPMs) |
| Ansible Engine for RHEL。最新バージョンの Ansible を提供します。 |
Red Hat OpenStack Platform 16.2 for RHEL 8 (RPMs) |
| ppc64le システム用のコア RHOSP リポジトリー。 |
第3章 director インストールの準備
director をインストールおよび設定するには、アンダークラウドを Red Hat Customer Portal または Red Hat Satellite サーバーに登録し、director パッケージをインストールし、インストール中にコンテナーイメージを取得するために director のコンテナーイメージソースを設定するなどの準備作業を完了する必要があります。
3.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 [stack@director ~]$ sudo hostnamectl set-hostname --transient 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
重要RHOSP 環境でポートの名前を内部的に解決するには、DNS のポートエクステンションの DNS ドメイン (
dns_domain_ports
) を有効にする必要があります。NeutronDnsDomain
のデフォルト値 (openstacklocal
) を使用する場合、Networking サービスは DNS のポート名を内部的に解決しません。詳細は、ネットワーキングガイド の DNS がポートに割り当てる名前の指定 を参照してください。
3.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: Physical
Pool ID
の値を特定して、Red Hat OpenStack Platform 16.2 のエンタイトルメントをアタッチします。[stack@director ~]$ sudo subscription-manager attach --pool=Valid-Pool-Number-123456
アンダークラウドを Red Hat Enterprise Linux 8.4 にロックします。
$ sudo subscription-manager release --set=8.4
3.3. アンダークラウド用リポジトリーの有効化
アンダークラウドに必要なリポジトリーを有効にし、システムパッケージを最新バージョンに更新します。
手順
-
アンダークラウドに
stack
ユーザーとしてログインします。 デフォルトのリポジトリーをすべて無効にしてから、必要な Red Hat Enterprise Linux リポジトリーを有効にします。
[stack@director ~]$ sudo subscription-manager repos --disable=* [stack@director ~]$ sudo subscription-manager repos \ --enable=rhel-8-for-x86_64-baseos-tus-rpms \ --enable=rhel-8-for-x86_64-appstream-tus-rpms \ --enable=rhel-8-for-x86_64-highavailability-tus-rpms \ --enable=ansible-2.9-for-rhel-8-x86_64-rpms \ --enable=openstack-16.2-for-rhel-8-x86_64-rpms \ --enable=fast-datapath-for-rhel-8-x86_64-rpms
これらのリポジトリーには、director のインストールに必要なパッケージが含まれます。
container-tools
リポジトリーモジュールをバージョン3.0
に設定します。[stack@director ~]$ sudo dnf module reset container-tools [stack@director ~]$ sudo dnf module enable -y container-tools:3.0
システムで更新を実行して、ベースシステムパッケージを最新の状態にします。
[stack@director ~]$ sudo dnf update -y [stack@director ~]$ sudo reboot
3.4. director パッケージのインストール
Red Hat OpenStack Platform director に関連するパッケージをインストールします。
手順
director のインストールと設定を行うためのコマンドラインツールをインストールします。
[stack@director ~]$ sudo dnf install -y python3-tripleoclient
3.5. ceph-ansible のインストール
Red Hat OpenStack Platform で Ceph Storage を使用する場合、ceph-ansible
パッケージが必要です。
手順
Ceph Tools リポジトリーを有効にします。
[stack@director ~]$ sudo subscription-manager repos --enable=rhceph-4-tools-for-rhel-8-x86_64-rpms
ceph-ansible
パッケージをインストールします。[stack@director ~]$ sudo dnf install -y ceph-ansible
3.6. コンテナーイメージの準備
アンダークラウドのインストールには、コンテナーイメージの取得先およびその保存方法を定義するための環境ファイルが必要です。この環境ファイルを生成してカスタマイズし、コンテナーイメージの準備に使用します。
アンダークラウド用に特定のコンテナーイメージバージョンを設定する必要がある場合は、イメージを特定のバージョンに固定する必要があります。詳しい情報は、アンダークラウド用コンテナーイメージの固定 を参照してください。
手順
-
アンダークラウドホストに
stack
ユーザーとしてログインします。 デフォルトのコンテナーイメージ準備ファイルを生成します。
$ sudo 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
を変更します。
3.7. コンテナーイメージ準備のパラメーター
コンテナー準備用のデフォルトファイル (containers-prepare-parameter.yaml
) には、ContainerImagePrepare
heat パラメーターが含まれます。このパラメーターで、イメージのセットを準備するためのさまざまな設定を定義します。
parameter_defaults: ContainerImagePrepare: - (strategy one) - (strategy two) - (strategy three) ...
それぞれの設定では、サブパラメーターのセットにより使用するイメージやイメージの使用方法を定義することができます。以下の表には、ContainerImagePrepare
ストラテジーの各設定で使用することのできるサブパラメーターの情報をまとめています。
パラメーター | 説明 |
---|---|
| 設定からイメージ名を除外する正規表現のリスト |
|
設定に含める正規表現のリスト。少なくとも 1 つのイメージ名が既存のイメージと一致している必要があります。 |
|
対象となるイメージのタグに追加する文字列。たとえば、16.2.3-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
タグは使用されません。
3.8. コンテナーイメージタグ付けのガイドライン
Red Hat コンテナーレジストリーでは、すべての Red Hat OpenStack Platform コンテナーイメージをタグ付けするのに、特定のバージョン形式が使用されます。この形式は、version-release
のように各コンテナーのラベルのメタデータに従います。
- version
- Red Hat OpenStack Platform のメジャーおよびマイナーバージョンに対応します。これらのバージョンは、1 つまたは複数のリリースが含まれるストリームとして機能します。
- release
- バージョンストリーム内の、特定コンテナーイメージバージョンのリリースに対応します。
たとえば、Red Hat OpenStack Platform の最新バージョンが 16.2.3 で、コンテナーイメージのリリースが 5.161
の場合、コンテナーイメージのタグは 16.2.3-5.161 となります。
Red Hat コンテナーレジストリーでは、コンテナーイメージバージョンの最新リリースとリンクするメジャーおよびマイナー version
タグのセットも使用されます。たとえば、16.2 と 16.2.3 の両方が、16.2.3 コンテナーストリームの最新 release
とリンクします。16.2 の新規マイナーリリースが公開されると、16.2 タグは新規マイナーリリースストリームの最新 release
とリンクします。一方、16.2.3 タグは、引き続き 16.2.3 ストリーム内の最新 release
とリンクします。
ContainerImagePrepare
パラメーターには 2 つのサブパラメーターが含まれ、これを使用してダウンロードするコンテナーイメージを定義することができます。これらのサブパラメーターは、set
ディクショナリー内の tag
パラメーターおよび tag_from_label
パラメーターです。以下のガイドラインを使用して、tag
または tag_from_label
のどちらを使用するかを判断してください。
tag
のデフォルト値は、お使いの OpenStack Platform のメジャーバージョンです。本バージョンでは、16.2 です。これは常に最新のマイナーバージョンおよびリリースに対応します。parameter_defaults: ContainerImagePrepare: - set: ... tag: 16.2 ...
OpenStack Platform コンテナーイメージの特定マイナーバージョンに変更するには、タグをマイナーバージョンに設定します。たとえば、16.2.2 に変更するには、
tag
を 16.2.2 に設定します。parameter_defaults: ContainerImagePrepare: - set: ... tag: 16.2.2 ...
-
tag
を設定すると、インストールおよび更新時に、director は必ずtag
で設定したバージョンの最新のコンテナーイメージrelease
をダウンロードします。 tag
を設定しないと、director は最新のメジャーバージョンと共にtag_from_label
の値を使用します。parameter_defaults: ContainerImagePrepare: - set: ... # tag: 16.2 ... tag_from_label: '{version}-{release}'
tag_from_label
パラメーターは、Red Hat コンテナーレジストリーから検査する最新コンテナーイメージリリースのラベルメタデータからタグを生成します。たとえば、特定のコンテナーのラベルは、以下のversion
およびrelease
メタデータを使用します。"Labels": { "release": "5.161", "version": "16.2.3", ... }
-
tag_from_label
のデフォルト値は{version}-{release}
です。これは、各コンテナーイメージのバージョンおよびリリースのメタデータラベルに対応します。たとえば、コンテナーイメージのversion
に 16.2.3 が、release
に 5.161 が、それぞれ設定されている場合、コンテナーイメージのタグは 16.2.3-5.161 となります。 -
tag
パラメーターは、常にtag_from_label
パラメーターよりも優先されます。tag_from_label
を使用するには、コンテナー準備の設定でtag
パラメーターを省略します。 -
tag
およびtag_from_label
の主な相違点は、次のとおりです。director がtag
を使用してイメージをプルする場合は、Red Hat コンテナーレジストリーがバージョンストリーム内の最新イメージリリースとリンクするメジャーまたはマイナーバージョンのタグだけに基づきます。一方、tag_from_label
を使用する場合は、director がタグを生成して対応するイメージをプルできるように、各コンテナーイメージのメタデータの検査を行います。
3.9. プライベートレジストリーからのコンテナーイメージの取得
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: false
3.10. イメージ準備エントリーの階層化
ContainerImagePrepare
パラメーターの値は YAML リストです。したがって、複数のエントリーを指定することができます。
次の例は、16.2.1-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-rhel8 name_prefix: openstack- name_suffix: '' tag:16.2 - push_destination: true includes: - nova-api set: namespace: registry.redhat.io/rhosp-rhel8 tag: 16.2.1-hotfix
includes
および excludes
のパラメーターでは、各エントリーのイメージの絞り込みをコントロールするのに正規表現が使用されます。includes
設定と一致するイメージが、excludes
と一致するイメージに優先します。一致するとみなされるためには、イメージ名に includes
または excludes
の正規表現の値が含まれている必要があります。
ブロックストレージ (シンダー) ドライバーがプラグインと呼ばれるベンダー提供のシンダーボリュームイメージを必要とする場合も、同様の手法が使用されます。Block Storage ドライバーにプラグインが必要な場合は、Advanced Overcloud Customization ガイドの Deploying a vendor plugin を参照してください。
3.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
ファイルを保存します。
3.12. 準備プロセスにおけるイメージの変更
イメージの準備中にイメージを変更し、変更したそのイメージで直ちにオーバークラウドをデプロイすることが可能です。
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
レジストリーがインストールされないため、新しいアンダークラウドのインストール前にこのコマンドを実行することはできません。アンダークラウドが正常にインストールされた後に、このコマンドを実行することができます。
3.13. コンテナーイメージの既存パッケージの更新
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 ...
3.14. コンテナーイメージへの追加 RPM ファイルのインストール
RPM ファイルのディレクトリーをコンテナーイメージにインストールすることができます。この機能は、ホットフィックスやローカルパッケージビルドなど、パッケージリポジトリーからは入手できないパッケージのインストールに役立ちます。
Red Hat OpenStack Platform (RHOSP) ディレクターは、Ceph コンテナーではなく、RHOSP コンテナーのコンテナーイメージへの追加の RPM ファイルのインストールをサポートします。
既存のデプロイメントでコンテナーイメージを変更する場合は、変更後にマイナー更新を実行して変更をオーバークラウドに適用する必要があります。詳細は、Red Hat OpenStack Platform を最新状態に保つ を参照してください。
手順
次の
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 ...
3.15. カスタム 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
ファイルの例を以下に示します。USER
root ディレクティブを実行した後は、元のイメージのデフォルトユーザーに戻す必要があります。FROM registry.redhat.io/rhosp-rhel8/openstack-nova-compute:latest USER "root" COPY customize.sh /tmp/ RUN /tmp/customize.sh USER "nova"
3.16. コンテナーイメージ管理用 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-rhel8/openstack" --format="{{ .Name }}" | sort > satellite_images $ sudo podman search --limit 1000 "registry.redhat.io/rhceph" | grep rhceph-4-dashboard-rhel8 $ sudo podman search --limit 1000 "registry.redhat.io/rhceph" | grep rhceph-4-rhel8 $ sudo podman search --limit 1000 "registry.redhat.io/openshift" | grep ose-prometheus
Ceph をインストールして Ceph Dashboard を有効にする場合は、次の ose-prometheus コンテナーが必要です。
registry.redhat.io/openshift4/ose-prometheus-node-exporter:v4.6 registry.redhat.io/openshift4/ose-prometheus:v4.6 registry.redhat.io/openshift4/ose-prometheus-alertmanager:v4.6
-
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 4 コンテナーイメージを追加します。
$ hammer repository create \ --organization "ACME" \ --product "OSP Containers" \ --content-type docker \ --url https://registry.redhat.io \ --docker-upstream-name rhceph/rhceph-4-rhel8 \ --upstream-username USERNAME \ --upstream-password PASSWORD \ --name rhceph-4-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-4-dashboard-rhel8 \ --upstream-username USERNAME \ --upstream-password PASSWORD \ --name rhceph-4-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 およびポート。Red Hat Satellite のデフォルトのレジストリーポートは 443 です。 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-4 ceph_namespace: satellite.example.com:443 ceph_tag: latest name_prefix: acme-production-myosp16_1-osp_containers- name_suffix: '' namespace: satellite.example.com:443 neutron_driver: null tag: '16.2' ...
Red Hat SatelliteServer に保存されている特定のコンテナーイメージのバージョンを使用するには、tag
のキーと値のペアを set
ディクショナリー内の特定のバージョンに設定します。たとえば、16.2.2 イメージストリームを使用するには、set
ディクショナリーに tag: 16.2.2
を設定します。
undercloud.conf
設定ファイルで containers-prepare-parameter.yaml
環境ファイルを定義する必要があります。定義しないと、アンダークラウドはデフォルト値を使用します。
container_images_file = /home/stack/containers-prepare-parameter.yaml
第4章 アンダークラウドへの director のインストール
Director を設定してインストールするには、undercloud.conf
ファイルに適切なパラメーターを設定し、undercloud installation コマンドを実行します。director をインストールしたら、ノードのプロビジョニング中に director がベアメタルノードへの書き込みに使用するオーバークラウドイメージをインポートします。
4.1. director の設定
director のインストールプロセスでは、director が stack
ユーザーのホームディレクトリーから読み取る undercloud.conf
設定ファイルに、特定の設定が必要になります。設定のベースとするためにデフォルトのテンプレートをコピーするには、以下の手順を実施します。
手順
デフォルトのテンプレートを
stack
ユーザーのホームディレクトリーにコピーします。[stack@director ~]$ cp \ /usr/share/python-tripleoclient/undercloud.conf.sample \ ~/undercloud.conf
-
undercloud.conf
ファイルを編集します。このファイルには、アンダークラウドを設定するための設定値が含まれています。パラメーターを省略したり、コメントアウトした場合には、アンダークラウドのインストールでデフォルト値が使用されます。
4.2. director の設定パラメーター
以下のリストで、undercloud.conf
ファイルを設定するパラメーターについて説明します。エラーを避けるために、パラメーターは決して該当するセクションから削除しないでください。
少なくとも、コンテナーイメージの設定が含まれる環境ファイルに container_images_file
パラメーターを設定する必要があります。このパラメーターに適切なファイルを正しく設定しないと、director は ContainerImagePrepare
パラメーターからコンテナーイメージのルールセットを取得することや、ContainerImageRegistryCredentials
パラメーターからコンテナーレジストリーの認証情報を取得することができなくなります。
デフォルト
undercloud.conf
ファイルの [DEFAULT]
セクションで定義されているパラメーターを以下に示します。
- additional_architectures
オーバークラウドがサポートする追加の (カーネル) アーキテクチャーのリスト。現在、オーバークラウドは、デフォルトの
x86_64
アーキテクチャーに加えてppc64le
アーキテクチャーをサポートしています。注記ppc64le のサポートを有効にする場合には、
ipxe_enabled
をFalse
に設定する必要もあります。複数の CPU アーキテクチャーを使用したアンダークラウドの設定の詳細については、Configuring a multiple CPU architecture overcloud を参照してください。- certificate_generation_ca
-
要求した証明書に署名する CA の
certmonger
のニックネーム。generate_service_certificate
パラメーターを設定した場合に限り、このオプションを使用します。local
CA を選択する場合は、certmonger はローカルの CA 証明書を/etc/pki/ca-trust/source/anchors/cm-local-ca.pem
に抽出し、証明書をトラストチェーンに追加します。 - clean_nodes
- デプロイメントを再実行する前とイントロスペクションの後にハードドライブを消去するかどうかを定義します。
- cleanup
-
一時的なファイルを削除します。デプロイメント中に使用される一時ファイルを保持するには、これを
False
に設定します。一時ファイルは、エラーが発生した場合にデプロイメントのデバッグに役立ちます。 - container_cli
-
コンテナー管理用の CLI ツール。このパラメーターは、
podman
に設定したままにしてください。Red Hat Enterprise Linux 8.4 がサポートするのは、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_mistral、enable_nova、enable_tempest、enable_validations、enable_zaqar
-
director で有効にするコアサービスを定義します。これらのパラメーターは
true
に設定されたままにします。 - enable_node_discovery
-
introspection ramdisk を PXE ブートする不明なノードを自動的に登録します。新規ノードは、
fake
ドライバーをデフォルトとして使用しますが、discovery_default_driver
を設定して上書きすることもできます。また、イントロスペクションルールを使用して、新しく登録したノードにドライバーの情報を指定することもできます。 - enable_novajoin
-
アンダークラウドに
novajoin
メタデータサービスをインストールするかどうかを定義します。 - enable_routed_networks
- ルーティングされたコントロールプレーンネットワークのサポートを有効にするかどうかを定義します。
- enable_swift_encryption
- 保存データの Swift 暗号化を有効にするかどうかを定義します。
- enable_telemetry
-
アンダークラウドに OpenStack Telemetry サービス (gnocchi、aodh、panko) をインストールするかどうかを定義します。Telemetry サービスを自動的にインストール/設定するには、
enable_telemetry
パラメーターをtrue
に設定します。デフォルト値はfalse
で、アンダークラウド上の telemetry が無効になります。このパラメーターは、メトリックデータを消費する Red Hat CloudForms などの他の製品を使用する場合に必要です。
RBAC はすべてのコンポーネントでサポートされているわけではありません。Alarming サービス (aodh) と Gnocchi は、安全な RBAC ルールを考慮していません。
- 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
に設定します。このオプションは、登録ノードのハードウェアを検査する際にベンチマーク分析を実行する場合に必要です。 - ipa_otp
-
IPA サーバーにアンダークラウドノードを登録するためのワンタイムパスワードを定義します。これは、
enable_novajoin
が有効な場合に必要です。 - 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
で設定されたネットワークパラメーターを無視します。ボンディングを設定する場合、またはインターフェイスにオプションを追加する場合に、このパラメーターを使用します。アンダークラウドネットワークインターフェイスのカスタマイズの詳細については、Configuring undercloud network interfaces を参照してください。 - 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 ネットワークにない場合は、Undercloud の管理 API がリッスンするインターフェイスにControlVirtualInterface
パラメーターを設定する必要があります。デフォルトでは、管理 API はbr-ctlplane
インターフェイスでリッスンします。ControlVirtualInterface
パラメーターをカスタム環境ファイルに設定し、custom_env_files
パラメーターを設定して、undercloud.conf
ファイルにカスタム環境ファイルを含めます。アンダークラウドネットワークインターフェイスのカスタマイズについての詳細は、Configuring undercloud network interfaces を参照してください。
- 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
ファイルにカスタム環境ファイルを含めます。アンダークラウドネットワークインターフェイスのカスタマイズについての詳細は、Configuring undercloud network interfaces を参照してください。
- 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
-
オーバークラウドインスタンスのゲートウェイ。外部ネットワークにトラフィックを転送するアンダークラウドのホストです。director に別の IP アドレスを使用する場合または直接外部ゲートウェイを使用する場合以外は、この値はデフォルト (
192.168.24.1
) のままにします。 - host_routes
-
このネットワーク上のオーバークラウドインスタンス用の neutron が管理するサブネットのホストルート。このパラメーターにより、アンダークラウド上の
local_subnet
のホストルートも設定されます。 - inspection_iprange
-
検査プロセス中に使用するこのネットワーク上のノードの一時的な IP 範囲。この範囲は、
dhcp_start
とdhcp_end
で定義された範囲と重複することはできませんが、同じ IP サブネット内になければなりません。
実際の設定に応じて、これらのパラメーターの値を変更してください。完了したら、ファイルを保存します。
4.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 のインストールに追加されます。
4.4. アンダークラウド設定用の標準 heat パラメーター
以下の表には、アンダークラウド用のカスタム環境ファイルで設定する標準の heat パラメーターをまとめています。
パラメーター | 説明 |
---|---|
|
アンダークラウドの |
|
アンダークラウドの |
| デバッグモードを有効にします。 |
カスタム環境ファイルの parameter_defaults
セクションで、これらのパラメーターを設定します。
parameter_defaults: Debug: True AdminPassword: "myp@ssw0rd!" AdminEmail: "admin@example.com"
4.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: 15
undercloud.conf
ファイルのhieradata_override
パラメーターを、新しい/home/stack/hieradata.yaml
ファイルのパスに設定します。hieradata_override = /home/stack/hieradata.yaml
4.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 Networking for the Overcloudの Configuring an IPv6 address on the undercloud を参照してください。
手順
-
undercloud.conf
ファイルを開きます。 IPv6 アドレスモードをステートレスまたはステートフルのいずれかに指定します。
[DEFAULT] ipv6_address_mode = <address_mode> ...
NIC がサポートするモードに基づいて、
<address_mode>
をdhcpv6-stateless
またはdhcpv6-stateful
に置き換えます。注記ステートフルアドレスモードを使用する場合、ファームウェア、チェーンローダー、およびオペレーティングシステムは、DHCP サーバーが追跡する ID を生成するために異なるアルゴリズムを使用する場合があります。DHCPv6 は MAC によってアドレスを追跡せず、リクエスターからの ID 値が変更されても、MAC アドレスが同じままである場合、同じアドレスを提供しません。したがって、ステートフル DHCPv6 を使用する場合は、次の手順を実行してネットワークインターフェイスを設定する必要もあります。
ステートフル 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 ネームサーバーに置き換えます。
4.7. アンダークラウドネットワークインターフェイスの設定
特定のネットワーク機能を持つアンダークラウドをインストールするには、undercloud.conf
ファイルにカスタムネットワーク設定を追加します。たとえば、一部のインターフェイスは DHCP を持ちません。このような場合は、アンダークラウドのインストールプロセス中に os-net-config
が設定を適用できるように、undercloud.conf
ファイルでこれらのインターフェイスの DHCP を無効にする必要があります。
手順
- アンダークラウドのホストにログインします。
新規ファイル
undercloud-os-net-config.yaml
を作成し、必要なネットワーク設定を追加します。詳細については、Advanced Overcloud Customization Guide の Networkinterfacereference を参照してください。
以下に例を示します。
network_config: - name: br-ctlplane type: ovs_bridge use_dhcp: false dns_servers: - 192.168.122.1 domain: lab.example.com ovs_extra: - "br-set-external-id br-ctlplane bridge-id br-ctlplane" addresses: - ip_netmask: 172.20.0.1/26 members: - type: interface name: nic2
特定のインターフェイスのネットワークボンディングを作成するには、次のサンプルを使用します。
network_config: - name: br-ctlplane type: ovs_bridge use_dhcp: false dns_servers: - 192.168.122.1 domain: lab.example.com ovs_extra: - "br-set-external-id br-ctlplane bridge-id br-ctlplane" addresses: - ip_netmask: 172.20.0.1/26 members: - name: bond-ctlplane type: linux_bond use_dhcp: false bonding_options: "mode=active-backup" mtu: 1500 members: - type: interface name: nic2 - type: interface name: nic3
undercloud.conf
ファイルのnet_config_override
パラメーターに、undercloud-os-net-config.yaml
ファイルへのパスを追加します。[DEFAULT] ... net_config_override=undercloud-os-net-config.yaml ...
注記director は、
net_config_override
パラメーターに追加するファイルをテンプレートとして使用し、/etc/os-net-config/config.yaml
ファイルを生成します。os-net-config
はテンプレートで定義するインターフェイスを管理するので、このファイルですべてのアンダークラウドネットワークインターフェイスのカスタマイズを実行する必要があります。- アンダークラウドをインストールします。
検証
アンダークラウドのインストールが正常に完了したら、
/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
4.8. director のインストール
director をインストールして基本的なインストール後タスクを行うには、以下の手順を実施します。
手順
以下のコマンドを実行して、アンダークラウドに director をインストールします。
[stack@director ~]$ openstack undercloud install
このコマンドにより、director の設定スクリプトが起動します。director は追加のパッケージをインストールし、
undercloud.conf
の設定に従ってサービスを設定し、すべての RHOSP サービスコンテナーを起動します。このスクリプトは、完了までに数分かかります。スクリプトにより、2 つのファイルが生成されます。
-
undercloud-passwords.conf
: director サービスの全パスワードリスト -
stackrc
: director コマンドラインツールへアクセスできるようにする初期化変数セット
-
RHOSP サービスコンテナーが実行中であることを確認します。
[stack@director ~]$ sudo podman ps -a --format "{{.Names}} {{.Status}}"
次のコマンド出力は、RHOSP サービスコンテナーが実行中 (
Up
) であることを示しています。memcached Up 3 hours (healthy) haproxy Up 3 hours rabbitmq Up 3 hours (healthy) mysql Up 3 hours (healthy) iscsid Up 3 hours (healthy) keystone Up 3 hours (healthy) keystone_cron Up 3 hours (healthy) neutron_api Up 3 hours (healthy) logrotate_crond Up 3 hours (healthy) neutron_dhcp Up 3 hours (healthy) neutron_l3_agent Up 3 hours (healthy) neutron_ovs_agent Up 3 hours (healthy) ironic_api Up 3 hours (healthy) ironic_conductor Up 3 hours (healthy) ironic_neutron_agent Up 3 hours (healthy) ironic_pxe_tftp Up 3 hours (healthy) ironic_pxe_http Up 3 hours (unhealthy) ironic_inspector Up 3 hours (healthy) ironic_inspector_dnsmasq Up 3 hours (healthy) neutron-dnsmasq-qdhcp-30d628e6-45e6-499d-8003-28c0bc066487 Up 3 hours ...
stack
ユーザーを初期化してコマンドラインツールを使用するには、以下のコマンドを実行します。[stack@director ~]$ source ~/stackrc
プロンプトには、OpenStack コマンドがアンダークラウドに対して認証および実行されることが表示されるようになります。
(undercloud) [stack@director ~]$
director のインストールが完了しました。これで、director コマンドラインツールが使用できるようになりました。
4.9. オーバークラウド用の CPU アーキテクチャーの設定
Red Hat OpenStack Platform (RHOSP) は、オーバークラウドの CPU アーキテクチャーをデフォルトで x86_64 として設定します。POWER (ppc64le) ハードウェアにオーバークラウド Compute ノードをデプロイすることもできます。Compute ノードのクラスターには、同じアーキテクチャーのシステム、または x86_64 と ppc64le が混在するシステムを使用することができます。
アンダークラウド、Controller ノード、Ceph Storage ノード、およびその他のシステムは、すべて x86_64 ハードウェアでのみサポートされています。
4.9.1. オーバークラウドの単一 CPU アーキテクチャーとしての POWER (ppc64le) の設定
オーバークラウド上の Compute ノードのデフォルトの CPU アーキテクチャーは x86_64 です。オーバークラウド Compute ノードを POWER (ppc64le) ハードウェアにデプロイするには、アーキテクチャーを ppc64le に変更できます。
手順
undercloud.conf
ファイルで iPXE を無効にします。[DEFAULT] ipxe_enabled = False
注記RHOSP 16.2.1 以前の場合、この設定により、デプロイメント内のすべての x86_64 ノードも PXE/ レガシーモードで起動します。オーバークラウド用にマルチ CPU アーキテクチャーを設定するには、Configuring a multiple CPU architecture overcloud を参照してください。
アンダークラウドをインストールします。
[stack@director ~]$ openstack undercloud install
詳細は、Installing director on the undercloud を参照してください。
- インストールスクリプトが完了するまで待ちます。
- オーバークラウドノードのイメージを取得してアップロードします。詳細は、Obtaining images for overcloud nodes を参照してください。
4.9.2. マルチ CPU アーキテクチャーオーバークラウドの設定
RHOSP 16.2.2 以降では、アーキテクチャーに POWER (ppc64le) と x86_64 UEFI ノードの両方が含まれている場合、PXE と iPXE の両方のブートモードをサポートするようにアンダークラウドを設定することができます。
アーキテクチャーに POWER (ppc64le) ノードが含まれている場合、RHOSP 16.2.1 以前は PXE ブートのみをサポートします。
手順
undercloud.conf
ファイルで iPXE を有効にします。[DEFAULT] ipxe_enabled = True
-
アンダークラウド用のカスタム環境ファイル
undercloud_noIronicIPXEEnabled.yaml
を作成します。 デフォルトのベアメタルプロビジョニングサービス (ironic) iPXE 設定を
PXE
に変更するには、以下の設定をundercloud_noIronicIPXEEnabled.yaml
に追加します。parameter_defaults: IronicIPXEEnabled: false IronicInspectorIPXEEnabled: true
アーキテクチャーに
ppc64le
ノードが含まれている場合は、以下の設定をundercloud_noIronicIPXEEnabled.yaml
に追加して、ブートタイムアウトを無効にします。parameter_defaults: ExtraConfig: ironic::config::ironic_config: ipmi/disable_boot_timeout: value: 'false'
undercloud.conf
ファイルにカスタム環境ファイルを含めます。[DEFAULT] ... custom_env_files = undercloud_noIronicIPXEEnabled.yaml
アンダークラウドをインストールします。
[stack@director ~]$ openstack undercloud install
詳細は、Installing director on the undercloud を参照してください。
- インストールスクリプトが完了するまで待ちます。
オーバークラウドノードを登録します。
(undercloud)$ openstack overcloud node import ~/nodes.json
オーバークラウドノードの登録の詳細については、Registering nodes for the overcloud を参照してください。
- ノードの登録および設定が完了するまで待ちます。
director がノードを正常に登録したことを確認します。
(undercloud)$ openstack baremetal node list
登録された各ノードの既存の機能を確認します。
$ openstack baremetal node show <node> -f json -c properties | jq -r .properties.capabilities
ノードの既存の機能に
boot_mode:uefi
を追加して、登録されている各ノードのブートモードをuefi
に設定します。$ openstack baremetal node set --property capabilities="boot_mode:uefi,<capability_1>,...,<capability_n>" <node>
-
<node>
をベアメタルノードの ID に置き換えてください。 -
<capability_1>
、および<capability_n>
までのすべての機能を、手順 6 で取得した各機能に置き換えます。
-
- オーバークラウドノードのイメージを取得してアップロードします。詳細は、Multiple CPU architecture overcloud images を参照してください。
各ノードのブートモードを設定します。
レガシー/PXE の場合。
$ openstack baremetal node set --boot-interface pxe <node_name>
iPXE の場合:
$ openstack baremetal node set --boot-interface ipxe <node_name>
4.9.3. マルチアーキテクチャーオーバークラウドでの Ceph Storage の使用
マルチアーキテクチャークラウドにおいて外部 Ceph へのアクセスを設定する場合には、CephAnsiblePlaybook
パラメーターを /usr/share/ceph-ansible/site.yml.sample
に設定し、クライアントキーおよびその他の Ceph 固有パラメーターを含めます。
以下に例を示します。
parameter_defaults: CephAnsiblePlaybook: /usr/share/ceph-ansible/site.yml.sample CephClientKey: AQDLOh1VgEp6FRAAFzT7Zw+Y9V6JJExQAsRnRQ== CephClusterFSID: 4b5c8c0a-ff60-454b-a1b4-9747aa737d19 CephExternalMonHost: 172.16.1.7, 172.16.1.8
4.9.4. マルチアーキテクチャーオーバークラウドでのコンポーザブルサービスの使用
一般に Controller ノードの一部となる以下のサービスは、テクノロジープレビューとしてカスタムロールでの使用が可能です。
- Block Storage サービス (cinder)
- Image サービス (glance)
- Identity サービス (keystone)
- Networking サービス (neutron)
- Object Storage サービス (swift)
Red Hat は、テクノロジープレビューの機能をサポートしていません。
コンポーザブルサービスについての詳しい情報は、Advanced Overcloud Customizationの composable services and custom roles を参照してください。以下の例を使用して、上記のサービスを Controller ノードから専用の ppc64le ノードに移動する方法を説明します。
(undercloud) [stack@director ~]$ rsync -a /usr/share/openstack-tripleo-heat-templates/. ~/templates (undercloud) [stack@director ~]$ cd ~/templates/roles (undercloud) [stack@director roles]$ cat <<EO_TEMPLATE >ControllerPPC64LE.yaml ############################################################################### # Role: ControllerPPC64LE # ############################################################################### - name: ControllerPPC64LE description: | Controller role that has all the controller services loaded and handles Database, Messaging and Network functions. CountDefault: 1 tags: - primary - controller networks: - External - InternalApi - Storage - StorageMgmt - Tenant # For systems with both IPv4 and IPv6, you may specify a gateway network for # each, such as ['ControlPlane', 'External'] default_route_networks: ['External'] HostnameFormatDefault: '%stackname%-controllerppc64le-%index%' ImageDefault: ppc64le-overcloud-full ServicesDefault: - OS::TripleO::Services::Aide - OS::TripleO::Services::AuditD - OS::TripleO::Services::CACerts - OS::TripleO::Services::CephClient - OS::TripleO::Services::CephExternal - OS::TripleO::Services::CertmongerUser - OS::TripleO::Services::CinderApi - OS::TripleO::Services::CinderBackendDellPs - OS::TripleO::Services::CinderBackendDellSc - OS::TripleO::Services::CinderBackendDellEMCUnity - OS::TripleO::Services::CinderBackendDellEMCVMAXISCSI - OS::TripleO::Services::CinderBackendDellEMCVNX - OS::TripleO::Services::CinderBackendDellEMCXTREMIOISCSI - OS::TripleO::Services::CinderBackendNetApp - OS::TripleO::Services::CinderBackendScaleIO - OS::TripleO::Services::CinderBackendVRTSHyperScale - OS::TripleO::Services::CinderBackup - OS::TripleO::Services::CinderHPELeftHandISCSI - OS::TripleO::Services::CinderScheduler - OS::TripleO::Services::CinderVolume - OS::TripleO::Services::Collectd - OS::TripleO::Services::Docker - OS::TripleO::Services::Fluentd - OS::TripleO::Services::GlanceApi - OS::TripleO::Services::GlanceRegistry - OS::TripleO::Services::Ipsec - OS::TripleO::Services::Iscsid - OS::TripleO::Services::Kernel - OS::TripleO::Services::Keystone - OS::TripleO::Services::LoginDefs - OS::TripleO::Services::MySQLClient - OS::TripleO::Services::NeutronApi - OS::TripleO::Services::NeutronBgpVpnApi - OS::TripleO::Services::NeutronSfcApi - OS::TripleO::Services::NeutronCorePlugin - OS::TripleO::Services::NeutronDhcpAgent - OS::TripleO::Services::NeutronL2gwAgent - OS::TripleO::Services::NeutronL2gwApi - OS::TripleO::Services::NeutronL3Agent - OS::TripleO::Services::NeutronLbaasv2Agent - OS::TripleO::Services::NeutronLbaasv2Api - OS::TripleO::Services::NeutronLinuxbridgeAgent - OS::TripleO::Services::NeutronMetadataAgent - OS::TripleO::Services::NeutronML2FujitsuCfab - OS::TripleO::Services::NeutronML2FujitsuFossw - OS::TripleO::Services::NeutronOvsAgent - OS::TripleO::Services::NeutronVppAgent - OS::TripleO::Services::Ntp - OS::TripleO::Services::ContainersLogrotateCrond - OS::TripleO::Services::OpenDaylightOvs - OS::TripleO::Services::Rhsm - OS::TripleO::Services::RsyslogSidecar - OS::TripleO::Services::Securetty - OS::TripleO::Services::SensuClient - OS::TripleO::Services::SkydiveAgent - OS::TripleO::Services::Snmp - OS::TripleO::Services::Sshd - OS::TripleO::Services::SwiftProxy - OS::TripleO::Services::SwiftDispersion - OS::TripleO::Services::SwiftRingBuilder - OS::TripleO::Services::SwiftStorage - OS::TripleO::Services::Timezone - OS::TripleO::Services::TripleoFirewall - OS::TripleO::Services::TripleoPackages - OS::TripleO::Services::Tuned - OS::TripleO::Services::Vpp - OS::TripleO::Services::OVNController - OS::TripleO::Services::OVNMetadataAgent - OS::TripleO::Services::Ptp EO_TEMPLATE (undercloud) [stack@director roles]$ sed -i~ -e '/OS::TripleO::Services::\(Cinder\|Glance\|Swift\|Keystone\|Neutron\)/d' Controller.yaml (undercloud) [stack@director roles]$ cd ../ (undercloud) [stack@director templates]$ openstack overcloud roles generate \ --roles-path roles -o roles_data.yaml \ Controller Compute ComputePPC64LE ControllerPPC64LE BlockStorage ObjectStorage CephStorage
4.10. オーバークラウドノードのイメージの取得
director では、オーバークラウドのノードをプロビジョニングするのに、複数のディスクイメージが必要です。
- イントロスペクションカーネルおよび ramdisk: PXE ブートでのベアメタルシステムのイントロスペクション用
- デプロイメントカーネルおよび ramdisk: システムのプロビジョニングおよびデプロイメント用
- オーバークラウドカーネル、ramdisk、完全なイメージで、director がノードのハードディスクに書き込むベースオーバークラウドシステムを形成しています。
CPU アーキテクチャーに基づいて、必要なイメージを取得してインストールできます。他の Red Hat OpenStack Platform (RHOSP) サービスを実行したくない場合、またはサブスクリプションエンタイトルメントの 1 つを使用したくない場合は、basic イメージを取得してインストールし、ベア OS をプロビジョニングすることもできます。
4.10.1. シングル CPU アーキテクチャーのオーバークラウドイメージ
Red Hat OpenStack Platform (RHOSP) のインストールには、director 用に次のオーバークラウドイメージを提供するパッケージが含まれています。
-
overcloud-full
-
overcloud-full-initrd
-
overcloud-full-vmlinuz
CPU アーキテクチャーがデフォルトの x86-64 の場合には、オーバークラウドのデプロイメントに以下のイメージおよび手順が必要です。これらのイメージを director にインポートすると、イントロスペクションイメージも director PXE サーバーにインストールされます。
手順
-
アンダークラウドに
stack
ユーザーとしてログインします。 stackrc
ファイルを取得します。[stack@director ~]$ source ~/stackrc
rhosp-director-images
およびrhosp-director-images-ipa-x86_64
パッケージをインストールします。(undercloud) [stack@director ~]$ sudo dnf install rhosp-director-images 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/overcloud-full-latest-16.2.tar /usr/share/rhosp-director-images/ironic-python-agent-latest-16.2.tar; do tar -xvf $i; done
イメージを director にインポートします。
(undercloud) [stack@director images]$ openstack overcloud image upload --image-path /home/stack/images/
イメージがアップロードされていることを確認します。
(undercloud) [stack@director images]$ openstack image list +--------------------------------------+------------------------+ | ID | Name | +--------------------------------------+------------------------+ | ef793cd0-e65c-456a-a675-63cd57610bd5 | overcloud-full | | 9a51a6cb-4670-40de-b64b-b70f4dd44152 | overcloud-full-initrd | | 4f7e33f4-d617-47c1-b36f-cbe90f132e5d | overcloud-full-vmlinuz | +--------------------------------------+------------------------+
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
4.10.2. 複数の CPU アーキテクチャーのオーバークラウドイメージ
Red Hat OpenStack Platform (RHOSP) のインストールには、デフォルトの CPU アーキテクチャーである x86-64 を使用したオーバークラウドのデプロイに必要な次のイメージを提供するパッケージが含まれています。
-
overcloud-full
-
overcloud-full-initrd
-
overcloud-full-vmlinuz
RHOSP のインストールには、POWER (ppc64le) CPU アーキテクチャーを使用したオーバークラウドのデプロイに必要な次のイメージを提供するパッケージも含まれています。
-
ppc64le-overcloud-full
これらのイメージを director にインポートすると、イントロスペクションイメージも director PXE サーバーにインストールされます。
手順
-
アンダークラウドに
stack
ユーザーとしてログインします。 stackrc
ファイルを取得します。[stack@director ~]$ source ~/stackrc
rhosp-director-images-all
パッケージをインストールします。(undercloud) [stack@director ~]$ sudo dnf install rhosp-director-images-all
アーカイブをアーキテクチャー個別のディレクトリーにデプロイメントします。ここでは、
stack
ユーザーのホームディレクトリー下のimages
ディレクトリー (/home/stack/images
) です。(undercloud) [stack@director ~]$ cd ~/images (undercloud) [stack@director images]$ for arch in x86_64 ppc64le ; do mkdir $arch ; done (undercloud) [stack@director images]$ for arch in x86_64 ppc64le ; do for i in /usr/share/rhosp-director-images/overcloud-full-latest-16.1-${arch}.tar /usr/share/rhosp-director-images/ironic-python-agent-latest-16.1-${arch}.tar ; do tar -C $arch -xf $i ; done ; done
イメージを director にインポートします。
(undercloud) [stack@director ~]$ cd ~/images (undercloud) [stack@director images]$ openstack overcloud image upload --image-path ~/images/ppc64le --architecture ppc64le --whole-disk --http-boot /var/lib/ironic/tftpboot/ppc64le (undercloud) [stack@director images]$ openstack overcloud image upload --image-path ~/images/ppc64le --architecture ppc64le --whole-disk --image-type ironic-python-agent --http-boot /var/lib/ironic/httpboot/ppc64le (undercloud) [stack@director images]$ openstack overcloud image upload --image-path ~/images/x86_64/ --architecture x86_64 --http-boot /var/lib/ironic/tftpboot (undercloud) [stack@director images]$ openstack overcloud image upload --image-path ~/images/x86_64 --architecture x86_64 --image-type ironic-python-agent --http-boot /var/lib/ironic/httpboot
イメージがアップロードされていることを確認します。
(undercloud) [stack@director images]$ openstack image list +--------------------------------------+---------------------------+--------+ | ID | Name | Status | +--------------------------------------+---------------------------+--------+ | 6a6096ba-8f79-4343-b77c-4349f7b94960 | overcloud-full | active | | de2a1bde-9351-40d2-bbd7-7ce9d6eb50d8 | overcloud-full-initrd | active | | 67073533-dd2a-4a95-8e8b-0f108f031092 | overcloud-full-vmlinuz | active | | f0fedcd0-3f28-4b44-9c88-619419007a03 | ppc64le-overcloud-full | active | +--------------------------------------+---------------------------+--------+
Director がイントロスペクション PXE イメージを
/var/lib/ironic/tftpboot
にコピーしたことを確認します。(undercloud) [stack@director images]$ ls -l /var/lib/ironic/tftpboot /var/lib/ironic/tftpboot/ppc64le/ /var/lib/ironic/tftpboot: total 422624 -rwxr-xr-x. 1 root root 6385968 Aug 8 19:35 agent.kernel -rw-r--r--. 1 root root 425530268 Aug 8 19:35 agent.ramdisk -rwxr--r--. 1 42422 42422 20832 Aug 8 02:08 chain.c32 -rwxr--r--. 1 42422 42422 715584 Aug 8 02:06 ipxe.efi -rw-r--r--. 1 root root 22 Aug 8 02:06 map-file drwxr-xr-x. 2 42422 42422 62 Aug 8 19:34 ppc64le -rwxr--r--. 1 42422 42422 26826 Aug 8 02:08 pxelinux.0 drwxr-xr-x. 2 42422 42422 21 Aug 8 02:06 pxelinux.cfg -rwxr--r--. 1 42422 42422 69631 Aug 8 02:06 undionly.kpxe /var/lib/ironic/tftpboot/ppc64le/: total 457204 -rwxr-xr-x. 1 root root 19858896 Aug 8 19:34 agent.kernel -rw-r--r--. 1 root root 448311235 Aug 8 19:34 agent.ramdisk -rw-r--r--. 1 42422 42422 336 Aug 8 02:06 default
4.10.3. コンテナーイメージで複数の CPU アーキテクチャーを有効化する
Red Hat OpenStack Platform (RHOSP) デプロイメントに複数の CPU アーキテクチャーがあり、コンテナーイメージを使用する場合は、コンテナーイメージを更新して複数のアーキテクチャーを有効にする必要があります。
手順
-
アンダークラウドに
stack
ユーザーとしてログインします。 stackrc
ファイルを取得します。[stack@director ~]$ source ~/stackrc
追加のアーキテクチャーを
containers-prepare-parameter.yaml
ファイルに追加して、複数のアーキテクチャーを有効にします。parameter_defaults: ContainerImageRegistryLogin: true AdditionalArchitectures: [<list_of_architectures>] ContainerImagePrepare: - push_destination: true ...
<list_of_architectures>
を、オーバークラウド環境でサポートされているアーキテクチャーのコンマ区切りリスト ([ppc64le]
など) に置き換えます。コンテナーを準備してアップロードします。
$ openstack tripleo container image prepare \ -e ~/containers-prepare-parameter.yaml
4.10.4. 最小限のオーバークラウドイメージ
overcloud-minimal
イメージを使用すると、他の Red Hat OpenStack Platform (RHOSP) サービスを実行したり、サブスクリプションエンタイトメントを消費したりしたくないベア OS をプロビジョニングすることが可能です。
RHOSP のインストールには、director 用に次のオーバークラウドイメージを提供する overcloud-minimal
パッケージが含まれています。
-
overcloud-minimal
-
overcloud-minimal-initrd
-
overcloud-minimal-vmlinuz
デフォルトの overcloud-full.qcow2
イメージは、フラットなパーティションイメージです。ただし、完全なディスクイメージをインポートして使用することも可能です。詳細は、24章完全なディスクイメージの作成 を参照してください。
手順
-
アンダークラウドに
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-16.2.tar
イメージを director にインポートします。
(undercloud) [stack@director images]$ openstack overcloud image upload --image-path /home/stack/images/ --image-type os --os-image-name overcloud-minimal.qcow2
イメージがアップロードされていることを確認します。
(undercloud) [stack@director images]$ openstack image list +--------------------------------------+---------------------------+ | ID | Name | +--------------------------------------+---------------------------+ | ef793cd0-e65c-456a-a675-63cd57610bd5 | overcloud-full | | 9a51a6cb-4670-40de-b64b-b70f4dd44152 | overcloud-full-initrd | | 4f7e33f4-d617-47c1-b36f-cbe90f132e5d | overcloud-full-vmlinuz | | 32cf6771-b5df-4498-8f02-c3bd8bb93fdd | overcloud-minimal | | 600035af-dbbb-4985-8b24-a4e9da149ae5 | overcloud-minimal-initrd | | d45b0071-8006-472b-bbcc-458899e0d801 | overcloud-minimal-vmlinuz | +--------------------------------------+---------------------------+
4.11. コントロールプレーン用のネームサーバーの設定
オーバークラウドで cdn.redhat.com
などの外部のホスト名を解決する予定の場合は、オーバークラウドノード上にネームサーバーを設定してください。ネットワークを分離していない標準のオーバークラウドの場合には、ネームサーバーはアンダークラウドのコントロールプレーンのサブネットを使用して定義されます。環境でネームサーバーを定義するには、以下の手順を実施します。
手順
source コマンドで
stackrc
ファイルを読み込み、director コマンドラインツールを有効にします。[stack@director ~]$ source ~/stackrc
ctlplane-subnet
サブネット用のネームサーバーを設定します。(undercloud) [stack@director images]$ openstack subnet set --dns-nameserver [nameserver1-ip] --dns-nameserver [nameserver2-ip] ctlplane-subnet
各ネームサーバーに
--dns-nameserver
オプションを使用します。サブネットを表示してネームサーバーを確認します。
(undercloud) [stack@director images]$ openstack subnet show ctlplane-subnet +-------------------+-----------------------------------------------+ | Field | Value | +-------------------+-----------------------------------------------+ | ... | | | dns_nameservers | 8.8.8.8 | | ... | | +-------------------+-----------------------------------------------+
サービストラフィックを別のネットワークに分離する場合は、オーバークラウドのノードはネットワーク環境ファイルの DnsServers
パラメーターを使用する必要があります。また、コントロールプレーンのネームサーバーと DnsServers
パラメーターを同じ DNS サーバーに設定する必要があります。
4.12. アンダークラウド設定の更新
新たな要件に合わせて、アンダークラウドの設定を変更する必要がある場合は、該当する設定ファイルを編集し、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 | +---------------------+----------------------+
アンダークラウドの再設定が完了しました。
4.13. アンダークラウドのコンテナーレジストリー
Red Hat Enterprise Linux 8.4 には、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
- レジストリーからイメージを削除します。
第5章 アンダークラウドミニオンのインストール
追加のアンダークラウドミニオンをデプロイして、OpenStack Platform director のサービスを複数ホストにわたってスケーリングすることができます。これにより、大規模なオーバークラウドをデプロイする際にパフォーマンスが向上します。この機能はオプションです。
この機能は、本リリースでは テクノロジープレビュー として提供しているため、Red Hat では全面的にはサポートしていません。これは、テスト用途にのみご利用いただく機能です。実稼働環境にはデプロイしないでください。テクノロジープレビュー機能についての詳しい情報は、対象範囲の詳細 を参照してください。
5.1. アンダークラウドミニオン
アンダークラウドミニオンにより、別のホスト上に heat-engine
サービスおよび ironic-conductor
サービスが追加されます。これらの追加サービスは、アンダークラウドのオーケストレーションおよびプロビジョニング操作をサポートします。アンダークラウドの操作を複数ホスト間に分散することにより、オーバークラウドのデプロイメントにより多くのリソースを割り当てることができ、結果として大規模なデプロイメントをより迅速に実施することができます。
5.2. アンダークラウドミニオンの要件
サービスの要件
スケーリングされたアンダークラウドミニオン上の heat-engine
サービスおよび ironic-conductor
サービスは、ワーカーのセットを使用します。それぞれのワーカーは、そのサービスに固有の操作を実行します。複数のワーカーを用いると、同時に操作を実行することができます。ミニオンのデフォルトのワーカー数は、ミニオンホストの合計 CPU スレッド数の半分です。ここでは、合計スレッド数とは CPU コア数にハイパースレッディングの値を掛けたものを指します。たとえば、ミニオンの CPU スレッド数が 16 の場合には、デフォルトでは、ミニオンによりサービスごとに 8 つのワーカーが提供されます。デフォルトでは、ミニオンのサービスに最小および最大のワーカー数も適用されます。
サービス | 最小値 | 最大値 |
---|---|---|
| 4 | 24 |
| 2 | 12 |
アンダークラウドミニオンの CPU およびメモリーの最低要件を以下に示します。
- Intel 64 または AMD64 CPU 拡張機能をサポートする、8 スレッド 64 ビット x86 プロセッサー。このプロセッサーにより、各アンダークラウドサービスに 4 つのワーカーが提供されます。
- 最小 16 GB の RAM
多数のワーカーを使用するには、CPU スレッドごとに 2 GB の RAM の比率で、アンダークラウド上の仮想 CPU 数およびメモリー容量を増やします。たとえば、48 スレッドのマシンには 96 GB の RAM が必要です。これにより、heat-engine
用 24 ワーカーおよび ironic-conductor
用 12 ワーカーが提供されます。
コンテナーイメージの要件
アンダークラウドミニオンは、内部コンテナーイメージレジストリーをホストしません。したがって、以下のいずれかの方法を使用してコンテナーイメージを取得するようにミニオンを設定する必要があります。
-
イメージを Red Hat Container Image Registry (
registry.redhat.io
) から直接プルします。 - Red Hat Satellite Server でホストするイメージをプルする。
どちらの方法でも、containers-prepare-parameter.yaml
ファイルの ContainerImagePrepare
heat パラメーターの一部として、push_destination: false
を設定する必要があります。
5.3. ミニオンの準備
ミニオンをインストールする前に、ホストマシンでいくつかの基本設定を完了する必要があります。
- コマンドを実行するための非 root ユーザー
- 解決可能なホスト名
- Red Hat サブスクリプション
- イメージの準備およびミニオンのインストールを行うためのコマンドラインツール
手順
-
ミニオンホストに
root
ユーザーとしてログインします。 stack
ユーザーを作成します。[root@minion ~]# useradd stack
stack
ユーザーのパスワードを設定します。[root@minion ~]# passwd stack
sudo
を使用する場合にパスワードを要求されないようにします。[root@minion ~]# echo "stack ALL=(root) NOPASSWD:ALL" | tee -a /etc/sudoers.d/stack [root@minion ~]# chmod 0440 /etc/sudoers.d/stack
新規作成した
stack
ユーザーに切り替えます。[root@minion ~]# su - stack [stack@minion ~]$
ミニオンのベースおよび完全なホスト名を確認します。
[stack@minion ~]$ hostname [stack@minion ~]$ hostname -f
上記のコマンドのいずれかで正しい完全修飾ホスト名が出力されない、またはエラーが表示される場合には、
hostnamectl
でホスト名を設定します。[stack@minion ~]$ sudo hostnamectl set-hostname minion.example.com [stack@minion ~]$ sudo hostnamectl set-hostname --transient minion.example.com
/etc/hosts
ファイルを編集して、システムホスト名のエントリーを追加します。たとえば、システムの名前がminion.example.com
で、IP アドレスに10.0.0.1
を使用する場合には、/etc/hosts
ファイルに以下の行を追加します。10.0.0.1 minion.example.com manager
Red Hat コンテンツ配信ネットワークまたは Red Hat Satellite のどちらかにシステムを登録します。たとえば、システムをコンテンツ配信ネットワークに登録するには、以下のコマンドを実行します。要求されたら、カスタマーポータルのユーザー名およびパスワードを入力します。
[stack@minion ~]$ sudo subscription-manager register
Red Hat OpenStack Platform (RHOSP) director のエンタイトルメントプール ID を検索します。
[stack@minion ~]$ sudo subscription-manager list --available --all --matches="Red Hat OpenStack" Subscription Name: Name of SKU Provides: Red Hat Single Sign-On Red Hat Enterprise Linux Workstation Red Hat CloudForms Red Hat OpenStack Red Hat Software Collections (for RHEL Workstation) Red Hat Virtualization SKU: SKU-Number Contract: Contract-Number Pool ID: Valid-Pool-Number-123456 Provides Management: Yes Available: 1 Suggested: 1 Service Level: Support-level Service Type: Service-Type Subscription Type: Sub-type Ends: End-date System Type: Physical
Pool ID
の値を特定して、Red Hat OpenStack Platform 16.2 のエンタイトルメントをアタッチします。[stack@minion ~]$ sudo subscription-manager attach --pool=Valid-Pool-Number-123456
デフォルトのリポジトリーをすべて無効にしてから、必要な Red Hat Enterprise Linux リポジトリーを有効にします。
[stack@minion ~]$ sudo subscription-manager repos --disable=* [stack@minion ~]$ sudo subscription-manager repos --enable=rhel-8-for-x86_64-baseos-eus-rpms --enable=rhel-8-for-x86_64-appstream-eus-rpms --enable=rhel-8-for-x86_64-highavailability-eus-rpms --enable=ansible-2.9-for-rhel-8-x86_64-rpms --enable=openstack-16.2-for-rhel-8-x86_64-rpms --enable=fast-datapath-for-rhel-8-x86_64-rpms
これらのリポジトリーには、ミニオンのインストールに必要なパッケージが含まれます。
システムで更新を実行して、ベースシステムパッケージを最新の状態にします。
[stack@minion ~]$ sudo dnf update -y [stack@minion ~]$ sudo reboot
ミニオンのインストールと設定を行うためのコマンドラインツールをインストールします。
[stack@minion ~]$ sudo dnf install -y python3-tripleoclient
5.4. アンダークラウド設定ファイルのミニオンへのコピー
ミニオンには、アンダークラウドからの設定ファイルがいくつか必要です。これにより、ミニオンのインストールでミニオンサービスを設定し、それらを director に登録することができます。
-
tripleo-undercloud-outputs.yaml
-
tripleo-undercloud-passwords.yaml
手順
-
アンダークラウドに
stack
ユーザーとしてログインします。 ファイルをアンダークラウドからミニオンにコピーします。
$ scp ~/tripleo-undercloud-outputs.yaml ~/tripleo-undercloud-passwords.yaml stack@<minion-host>:~/.
-
<minion-host>
は、ミニオンのホスト名または IP アドレスに置き換えます。
-
5.5. アンダークラウドの認証局のコピー
アンダークラウドがエンドポイントの暗号化に SSL/TLS を使用する場合は、ミニオンホストにアンダークラウドの SSL/TLS 証明書に署名した認証局が含まれている必要があります。アンダークラウドの設定により、この認証局は以下のいずれかになります。
- ミニオンホストに事前に証明書を読み込む外部の認証局。対応の必要はありません。
-
director が
/etc/pki/ca-trust/source/anchors/cm-local-ca.pem
に生成する自己署名認証局。このファイルをミニオンホストにコピーし、ファイルをミニオンホストの信頼済み認証局の一部として追加します。この手順では、このファイルを例として使用します。 -
OpenSSL で作成するカスタムの自己署名認証局。本書の例では、このファイルを
ca.crt.pem
と呼びます。このファイルをミニオンホストにコピーし、ファイルをミニオンホストの信頼済み認証局の一部として追加します。
手順
-
ミニオンホストに
root
ユーザーとしてログインします。 認証局ファイルをアンダークラウドからミニオンにコピーします。
[root@minion ~]# scp \ root@<undercloud-host>:/etc/pki/ca-trust/source/anchors/cm-local-ca.pem \ /etc/pki/ca-trust/source/anchors/undercloud-ca.pem
-
<undercloud-host>
は、アンダークラウドのホスト名または IP アドレスに置き換えます。
-
ミニオンホストの信頼済み認証局を更新します。
[root@minion ~]# update-ca-trust enable [root@minion ~]# update-ca-trust extract
5.6. ミニオンの設定
ミニオンのインストールプロセスでは、ミニオンが stack
ユーザーのホームディレクトリーから読み取る minion.conf
設定ファイルに、特定の設定が必要になります。デフォルトのテンプレートを設定のベースとして使用するには、以下の手順を実施します。
手順
-
ミニオンホストに
stack
ユーザーとしてログインします。 デフォルトのテンプレートを
stack
ユーザーのホームディレクトリーにコピーします。[stack@minion ~]$ cp \ /usr/share/python-tripleoclient/minion.conf.sample \ ~/minion.conf
minion.conf
ファイルを編集します。このファイルには、ミニオンを設定するためのパラメーターが含まれています。パラメーターを省略したり、コメントアウトした場合には、ミニオンのインストールでデフォルト値が使用されます。以下の推奨パラメーターを確認してください。-
minion_hostname
: ミニオンのホスト名に設定します。 -
minion_local_interface
: プロビジョニングネットワークを介してアンダーグラウンドに接続するインターフェイスに設定します。 -
minion_local_ip
: プロビジョニングネットワークのフリー IP アドレスに設定します。 -
minion_nameservers
: ミニオンがホスト名を解決できるように DNS ネームサーバーに設定します。 -
enable_ironic_conductor
:ironic-conductor
サービスを有効にするかどうかを定義します。 -
enable_heat_engine
:heat-engine
サービスを有効にするかどうかを定義します。
-
デフォルトの minion.conf
ファイルでは、ミニオンの heat-engine
サービスだけが有効になります。ironic-conductor
サービスを有効にするには、enable_ironic_conductor
パラメーターを true
に設定します。
5.7. ミニオンの設定パラメーター
以下のリストで、minion.conf
ファイルを設定するパラメーターについて説明します。エラーを避けるために、パラメーターは決して該当するセクションから削除しないでください。
デフォルト
minion.conf
ファイルの [DEFAULT]
セクションで定義されているパラメーターを以下に示します。
- cleanup
-
一時ファイルをクリーンナップします。コマンド実行後もデプロイメント時に使用した一時ファイルをそのまま残すには、このパラメーターを
False
に設定します。ファイルを残すと、生成されたファイルのデバッグを行う場合やエラーが発生した場合に役に立ちます。 - container_cli
-
コンテナー管理用の CLI ツール。このパラメーターは、
podman
に設定したままにしてください。Red Hat Enterprise Linux 8.4 がサポートするのは、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
を使用する場合には、このパラメーターを未設定のままにします。 - enable_heat_engine
-
ミニオンに heat engine サービスをインストールするかどうかを定義します。デフォルトは
true
です。 - enable_ironic_conductor
-
ミニオンに ironic conductor サービスをインストールするかどうかを定義します。デフォルト値は
false
です。ironic conductor サービスを有効にするには、この値をtrue
に設定します。 - heat_container_image
- 使用する heat コンテナーイメージの URL。未設定のままにします。
- heat_native
-
ネイティブの heat テンプレートを使用します。
true
のままにします。 - hieradata_override
-
director に Puppet hieradata を設定するための
hieradata
オーバーライドファイルへのパス。これにより、サービスに対してminion.conf
パラメーター以外のカスタム設定を行うことができます。設定すると、ミニオンのインストールでこのファイルが/etc/puppet/hieradata
ディレクトリーにコピーされ、階層の最初のファイルに設定されます。 - minion_debug
-
ミニオンサービスの
DEBUG
ログレベルを有効にするには、この値をtrue
に設定します。 - minion_enable_selinux
-
デプロイメント時に、SELinux を有効または無効にします。問題をデバッグする場合以外は、この値を
true
に設定したままにすることを強く推奨します。 - minion_enable_validations
- minion で検証サービスを有効にします。
- minion_hostname
- ミニオンの完全修飾ホスト名を定義します。設定すると、ミニオンのインストールで全システムのホスト名が設定されます。未設定のままにすると、ミニオンは現在のホスト名を使用しますが、システムのホスト名設定をすべて適切に定義する必要があります。
- minion_local_interface
アンダークラウドのプロビジョニング NIC 用に選択するインターフェイス。ミニオンは、DHCP および PXE ブートサービスにもこのデバイスを使用します。この値を選択したデバイスに変更します。接続されているデバイスを確認するには、
ip addr
コマンドを使用します。ip addr
コマンドの出力結果の例を、以下に示します。2: eth0: <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 eth0 valid_lft 3462sec preferred_lft 3462sec inet6 fe80::5054:ff:fe75:2409/64 scope link valid_lft forever preferred_lft forever 3: eth1: <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 は
eth0
を、プロビジョニング NIC は未設定のeth1
を使用します。今回は、local_interface
をeth1
に設定します。この設定スクリプトにより、このインターフェイスがinspection_interface
パラメーターで定義したカスタムのブリッジにアタッチされます。- minion_local_ip
-
アンダークラウドのプロビジョニング NIC 用に定義する IP アドレス。ミニオンは、DHCP および PXE ブートサービスにもこの IP アドレスを使用します。デフォルトの IP アドレスが環境内の既存の IP アドレスまたはサブネットと競合するなどの理由により、プロビジョニングネットワークに別のサブネットを使用する場合以外は、この値をデフォルトの
192.168.24.1/24
のままにします。 - minion_local_mtu
-
local_interface
に使用する最大伝送単位 (MTU)。ミニオンでは 1500 以下にします。 - minion_log_file
-
ミニオンのインストールログおよびアップグレードログを保管するログファイルへのパス。デフォルトでは、ログファイルはホームディレクトリー内の
install-minion.log
です。たとえば、/home/stack/install-minion.log
のようになります。 - minion_nameservers
- ミニオンのホスト名解決に使用する DNS ネームサーバーのリスト
- minion_ntp_servers
- ミニオンの日付と時刻を同期できるようにする Network Time Protocol サーバーのリスト
- minion_password_file
-
ミニオンがアンダークラウドサービスに接続するためのパスワードが含まれるファイル。このパラメーターは、アンダークラウドからコピーした
tripleo-undercloud-passwords.yaml
ファイルに設定したままにしておきます。 - minion_service_certificate
- OpenStack SSL/TLS 通信の証明書の場所とファイル名。理想的には、信頼できる認証局から、この証明書を取得します。それ以外の場合は、独自の自己署名の証明書を生成します。
- minion_timezone
- ミニオン用ホストのタイムゾーン。タイムゾーンを指定しなければ、ミニオンは既存のタイムゾーン設定を使用します。
- minion_undercloud_output_file
-
ミニオンがアンダークラウドサービスに接続するのに使用できるアンダークラウド設定情報が含まれるファイル。このパラメーターは、アンダークラウドからコピーした
tripleo-undercloud-outputs.yaml
ファイルに設定したままにします。 - net_config_override
-
ネットワーク設定のオーバーライドテンプレートへのパス。このパラメーターを設定すると、ミニオンは JSON 形式のテンプレートを使用して
os-net-config
でネットワークを設定し、minion.conf
で設定したネットワークパラメーターを無視します。/usr/share/python-tripleoclient/minion.conf.sample
の例を参照してください。 - networks_file
-
heat
をオーバーライドするネットワークファイル - output_dir
- 状態、処理された heat テンプレート、および Ansible デプロイメントファイルを出力するディレクトリー
- roles_file
- ミニオンのインストールで、デフォルトロールファイルを上書きするのに使用するロールファイル。ミニオンのインストールにデフォルトのロールファイルが使用されるように、このパラメーターは未設定のままにすることを強く推奨します。
- templates
- 上書きする heat テンプレートファイル
5.8. ミニオンのインストール
ミニオンをインストールするには、以下の手順を実施します。
手順
-
ミニオンホストに
stack
ユーザーとしてログインします。 以下のコマンドを実行して、ミニオンをインストールします。
[stack@minion ~]$ openstack undercloud minion install
このコマンドによりミニオンの設定スクリプトが起動し、追加のパッケージがインストールされ、
minion.conf
ファイルの設定に応じてミニオンサービスが設定されます。このスクリプトは、完了までに数分かかります。
5.9. ミニオンのインストールの検証
ミニオンのインストールが正常に行われたことを確認するには、以下の手順を実施します。
手順
-
アンダークラウドに
stack
ユーザーとしてログインします。 stackrc
ファイルを取得します。[stack@director ~]$ source ~/stackrc
ミニオンで heat engine サービスを有効にしている場合には、ミニオンからの
heat-engine
サービスがアンダークラウドサービスのリストに表示されることを確認します。[stack@director ~]$ $ openstack orchestration service list
このコマンド出力には、アンダークラウドとミニオン両方の
heat-engine
ワーカーが記載された表が表示されます。ミニオンで ironic conductor サービスを有効にしている場合には、ミニオンからの
ironic-conductor
サービスがアンダークラウドサービスのリストに表示されることを確認します。[stack@director ~]$ $ openstack baremetal conductor list
このコマンド出力には、アンダークラウドとミニオン両方の
ironic-conductor
ワーカーが記載された表が表示されます。
第6章 オーバークラウドのプランニング
以下の項で、Red Hat OpenStack Platform (RHOSP) 環境のさまざまな要素をプランニングする際のガイドラインを説明します。これには、ノードロールの定義、ネットワークトポロジーのプランニング、ストレージなどが含まれます。
デプロイ後は、オーバークラウドノードの名前を変更しないでください。デプロイメント後にノードの名前を変更すると、インスタンスの管理に問題が生じます。
6.1. ノードロール
director には、オーバークラウドを作成するために、以下に示すデフォルトノード種別が含まれます。
- Controller
環境を制御するための主要なサービスを提供します。これには、Dashboard (horizon)、認証 (keystone)、イメージストレージ (glance)、ネットワーク (neutron)、オーケストレーション (heat)、高可用性サービスが含まれます。高可用性に対応した実稼働レベルの環境の場合は、Red Hat OpenStack Platform (RHOSP) 環境に Controller ノードが 3 台必要です。
注記1 台の Controller ノードで設定される環境は、実稼働用ではなくテスト目的にのみ使用してください。2 台の Controller ノードまたは 4 台以上の Controller ノードで設定される環境はサポートされません。
- Compute
- ハイパーバイザーとして機能し、環境内で仮想マシンを実行するのに必要な処理機能を持つ物理サーバー。基本的な RHOSP 環境には少なくとも 1 つの Compute ノードが必要です。
- Ceph Storage
- Red Hat Ceph Storage を提供するホスト。Ceph Storage ホストはクラスターに追加され、クラスターをスケーリングします。このデプロイメントロールはオプションです。
- Swift Storage
- OpenStack Object Storage (swift) サービスに外部オブジェクトストレージを提供するホスト。このデプロイメントロールはオプションです。
以下の表には、オーバークラウドの設定例と各シナリオで使用するノード種別の定義をまとめています。
Controller | Compute | Ceph Storage | Swift Storage | 合計 | |
小規模のオーバークラウド | 3 | 1 | - | - | 4 |
中規模のオーバークラウド | 3 | 3 | - | - | 6 |
追加のオブジェクトストレージがある中規模のオーバークラウド | 3 | 3 | - | 3 | 9 |
Ceph Storage クラスターがある中規模のオーバークラウド | 3 | 3 | 3 | - | 9 |
さらに、個別のサービスをカスタムのロールに分割するかどうかを検討します。コンポーザブルロールのアーキテクチャーについての詳しい情報は、Advanced Overcloud Customizationの Composable Services and Custom Roles を参照してください。
アンダークラウド | Controller | Compute | Ceph Storage | 合計 | |
概念実証 | 1 | 1 | 1 | 1 | 4 |
Red Hat OpenStack Platform は、Day 2 操作中、稼働状態にある Ceph Storage クラスターを維持します。そのため、MON ノードまたはストレージノードの数が 3 未満のデプロイメントでは、一部のDay 2 操作 (Ceph Storage クラスターのアップグレードまたはマイナー更新等) を行うことができません。単一の Controller ノードまたは単一の Ceph Storage ノードを使用している場合は、Day 2 操作に失敗します。
6.2. オーバークラウドネットワーク
ロールとサービスをマッピングして相互に正しく通信できるように、環境のネットワークトポロジーおよびサブネットのプランニングを行うことが重要です。Red Hat OpenStack Platform (RHOSP) では、自律的に動作してソフトウェアベースのネットワーク、静的/Floating IP アドレス、DHCP を管理する Openstack Networking (neutron) サービスを使用します。
デフォルトでは、director は接続に プロビジョニング/コントロールプレーン を使用するようにノードを設定します。ただし、ネットワークトラフィックを一連のコンポーザブルネットワークに分離し、カスタマイズしてサービスを割り当てることができます。
一般的な RHOSP のシステム環境では通常、ネットワーク種別の数は物理ネットワークのリンク数を超えます。全ネットワークを正しいホストに接続するために、オーバークラウドは VLAN タグ付けを使用して、それぞれのインターフェイスに複数のネットワークを提供します。ネットワークの多くは独立したサブネットですが、一部のネットワークには、インターネットアクセスまたはインフラストラクチャーにネットワーク接続ができるようにルーティングを提供するレイヤー 3 のゲートウェイが必要です。ネットワークトラフィックの種別を分離するのに VLAN を使用している場合には、802.1Q 標準をサポートするスイッチを使用してタグ付けされた VLAN を提供する必要があります。
VLAN を使用して、プロジェクト (tenant) ネットワークを作成します。プロジェクト VLAN を使用せずに、特殊用途のネットワーク用に Geneve トンネルまたは VXLAN トンネルを作成できます。Red Hat では、トンネリングを無効にして neutron VLAN モードでオーバークラウドをデプロイする場合でも、Geneve または VXLAN でトンネル化されたプロジェクトネットワークをデプロイすることを推奨しています。Geneve または VXLAN でトンネル化されたプロジェクトネットワークをデプロイする場合でも、トンネルネットワークをユーティリティーネットワークまたは仮想化ネットワークとして使用するように環境を更新できます。プロジェクト VLAN を使用してデプロイメントに Geneve または VXLAN 機能を追加することは可能ですが、中断を引き起こさずに既存のオーバークラウドにプロジェクト 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 を参照してください。
6.3. オーバークラウドのストレージ
任意のドライバーまたはバックエンド種別のバックエンド cinder ボリュームを使用するゲストインスタンスで LVM を使用すると、パフォーマンス、ボリュームの可視性/可用性、およびデータ破損の問題が生じます。可視性、可用性、およびデータ破損の問題を軽減するには、LVM フィルターを使用します。詳しい情報は、Storage Guideの section 2 Block Storage and Volumes および KCS アーティクル 3213311Using LVM on a cinder volume exposes the data to the compute host を参照してください。
director には、オーバークラウド環境用にさまざまなストレージオプションが含まれています。
- Ceph Storage ノード
director は、Red Hat Ceph Storage を使用して拡張可能なストレージノードセットを作成します。オーバークラウドは、以下のストレージ種別にこのノードを使用します。
- イメージ: Image サービス (glance) は仮想マシンのイメージを管理します。イメージを変更することはできません。OpenStack はイメージバイナリーブロブとして処理し、それに応じてイメージをダウンロードします。Image サービス (glance) を使用して、Ceph ブロックデバイスにイメージを保管することができます。
- ボリューム: OpenStack は Block Storage サービス (cinder) を使用してボリュームを管理します。Block Storage サービス (cinder) ボリュームはブロックデバイスです。OpenStack では、ボリュームを使用して仮想マシンをブートしたり、ボリュームを実行中の仮想マシンにアタッチしたりします。Block Storage サービスを使用して、イメージの Copy-on-Write クローンで仮想マシンをブートすることができます。
- ファイルシステム: OpenStack は Shared File Systems サービス (manila) を使用して共有ファイルシステムを管理します。ファイル共有は、ファイルシステムによりバッキングされます。manila を使用して、Ceph Storage ノードにデータを保管する CephFS ファイルシステムにバッキングされる共有を管理することができます。
ゲストディスク: ゲストディスクは、ゲストオペレーティングシステムのディスクです。デフォルトでは、Compute サービス (nova) で仮想マシンをブートすると、仮想マシンのディスクはハイパーバイザーのファイルシステム上のファイルとして表示されます (通常
/var/lib/nova/instances/<uuid>/
内)。Ceph 内にあるすべての仮想マシンは、Block Storage サービス (cinder) を使用せずにブートすることができます。これにより、ライブマイグレーションのプロセスを使用して、簡単にメンテナンス操作を実施することができます。また、ハイパーバイザーに障害が発生した場合には、nova evacuate
をトリガーして仮想マシンを別の場所で実行することもできるので便利です。重要サポートされるイメージ形式の詳細は、Creating and Managing Imagesの Image Service を参照してください。
Ceph Storage についての詳しい情報は、Red Hat Ceph Storage アーキテクチャーガイド を参照してください。
- Swift Storage ノード
- director は、外部オブジェクトストレージノードを作成します。これは、オーバークラウド環境で Controller ノードをスケーリングまたは置き換える必要があるが、高可用性クラスター外にオブジェクトストレージを保持する必要がある場合に便利です。
6.4. オーバークラウドのセキュリティー
OpenStack Platform の実装のセキュリティーレベルは、お使いの環境のセキュリティーレベルと同等でしかありません。ネットワーク環境内の適切なセキュリティー原則に従って、ネットワークアクセスを正しく制御するようにします。
- ネットワークのセグメント化を使用して、ネットワークトラフィックを軽減し、機密データを分離します。フラットなネットワークは、セキュリティーレベルがはるかに低くなります。
- サービスアクセスとポートを最小限に制限します。
- 適切なファイアウォールルールおよびパスワードの使用を徹底してください。
- 必ず SELinux を有効にします。
システムのセキュリティー保護についての詳細は、以下の Red Hat ガイドを参照してください。
- Red Hat Enterprise Linux 8 の セキュリティーの強化
- Red Hat Enterprise Linux 8 の SELinux の使用
6.5. オーバークラウドの高可用性
高可用性なオーバークラウドをデプロイするために、director は複数の Controller、Compute、およびストレージノードを単一のクラスターとして連携するように設定します。ノードで障害が発生すると、障害が発生したノードのタイプに応じて、自動フェンシングおよび再起動プロセスがトリガーされます。オーバークラウドの高可用性アーキテクチャーおよびサービスに関する情報は、High Availability Deployment and Usage を参照してください。
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 を使用して、Compute インスタンスの高可用性 (インスタンス HA) を設定することもできます。この高可用性のメカニズムにより、ノードで障害が発生すると Compute ノード上のインスタンスが自動的に退避および再起動されます。インスタンス HA に対する要件は通常のオーバークラウドの要件と同じですが、環境をデプロイメント用に準備するために追加のステップを実施する必要があります。インスタンス HA およびそのインストール手順についての情報は、High Availability for Compute Instances を参照してください。
6.6. Controller ノードの要件
Controller ノードは、Red Hat OpenStack Platform 環境の中核となるサービス (例: Dashboard (horizon)、バックエンドのデータベースサーバー、Identity サービス (keystone) の認証、および高可用性サービスなど) をホストします。
- プロセッサー
- Intel 64 または AMD64 CPU 拡張機能をサポートする 64 ビット x86 プロセッサー。
- メモリー
最小のメモリー容量は 32 GB です。ただし、推奨のメモリー容量は、仮想 CPU の数 (CPU コアの数をハイパースレッディングの値で乗算した数値に基づく) によって異なります。以下の計算により、RAM の要件を決定します。
Controller の最小メモリー容量の算出:
- 各仮想 CPU ごとに 1.5 GB のメモリーを使用します。たとえば、仮想 CPU が 48 個あるマシンにはメモリーは 72 GB 必要です。
Controller の推奨メモリー容量の算出:
- 各仮想 CPU ごとに 3 GB のメモリーを使用します。たとえば、仮想 CPU が 48 個あるマシンにはメモリーは 144 GB 必要です。
メモリーの要件に関する詳しい情報は、Red Hat カスタマーポータルで Red Hat OpenStack Platform Hardware Requirements for Highly Available Controllers を参照してください。
- ディスクストレージとレイアウト
Object Storage サービス (swift) が Controller ノード上で実行されていない場合には、最小で 50 GB のストレージが必要です。ただし、Telemetry および Object Storage サービスはいずれも Controller にインストールされ、ルートディスクを使用するように設定されます。これらのデフォルトは、市販のハードウェア上に構築される小型のオーバークラウドのデプロイに適しています。これらの環境は、概念検証およびテストの標準的な環境です。これらのデフォルトを使用すれば、最小限のプランニングでオーバークラウドをデプロイすることができますが、ワークロードキャパシティーとパフォーマンスの面ではあまり優れていません。
ただし、Telemetry が絶えずストレージにアクセスするため、エンタープライズ環境の場合、デフォルト設定では大きなボトルネックが生じる可能性があります。これにより、ディスク I/O が過度に使用されて、その他すべての Controller サービスに深刻な影響をもたらします。このタイプの環境では、オーバークラウドのプランニングを行って、適切に設定する必要があります。
Red Hat は、Telemetry と Object Storage の両方の推奨設定をいくつか提供しています。詳しくは、Deployment Recommendations for Specific Red Hat OpenStack Platform Services を参照してください。
- ネットワークインターフェイスカード
- 最小 2 枚の 1 Gbps ネットワークインターフェイスカード。タグ付けされた VLAN トラフィックを委譲する場合や、ボンディングインターフェイス向けには、追加のネットワークインターフェイスを使用します。
- 電源管理
- 各 Controller ノードには、Intelligent Platform Management Interface (IPMI) 機能などのサポート対象の電源管理インターフェイスがサーバーのマザーボードに搭載されている必要があります。
- 仮想化のサポート
- Red Hat では、Red Hat Virtualization プラットフォーム上の仮想 Controller ノードのみをサポートします。詳細は、Creating virtualized control planes を参照してください。
6.7. Compute ノードの要件
Compute ノードは、仮想マシンインスタンスが起動した後にそれらを稼働させるロールを果たします。Compute ノードには、ハードウェアの仮想化をサポートするベアメタルシステムが必要です。また、ホストする仮想マシンインスタンスの要件をサポートするのに十分なメモリーとディスク容量も必要です。
- プロセッサー
- Intel 64 または AMD64 CPU 拡張機能をサポートする 64 ビット x86 プロセッサーで、Intel VT または AMD-V のハードウェア仮想化拡張機能が有効化されている。このプロセッサーには最小でも 4 つのコアが搭載されていることを推奨しています。
- IBM POWER 8 プロセッサー
- メモリー
ホストオペレーティングシステム用に最低 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 トラフィックを委譲する場合や、ボンディングインターフェイス向けには、追加のネットワークインターフェイスを使用します。
- 電源管理
- 各 Compute ノードには、Intelligent Platform Management Interface (IPMI) 機能などのサポート対象の電源管理インターフェイスがサーバーのマザーボードに搭載されている必要があります。
6.8. Ceph Storage ノードの要件
Red Hat OpenStack Platform (RHOSP) director を使用して Red Hat Ceph Storage ノードを作成する場合は、追加要件があります。
Ceph Storage ノードのプロセッサー、メモリー、ネットワークインターフェイスカード (NIC)、およびディスクレイアウトを選択する方法に関する詳細は、Red Hat Ceph Storage Hardware Guide の Hardware selection recommendations for Red Hat Ceph Storage を確認してください。
各 Ceph Storage ノードにも、Intelligent Platform Management Interface (IPMI) 機能などのサポート対象の電源管理インターフェイスがサーバーのマザーボードに搭載されている必要があります。
RHOSP director は ceph-ansible
を使用しますが、Ceph Storage ノードのルートディスクへの OSD インストールには対応しません。したがって、サポートされる Ceph Storage ノードには少なくとも 2 つのディスクが必要になります。
Ceph Storage ノードと RHEL の互換性
- RHOSP 16.2 は RHEL 8.4 でサポートされています。RHOSP 16.1 以降にアップグレードする前に、Red Hat ナレッジベースの記事 Red Hat Ceph Storage: Supported configurations を確認してください。
Red Hat Ceph Storage の互換性
- RHOSP 16.2 は Red Hat Ceph Storage 4 をサポートします。
配置グループ (PG)
- デプロイメントの規模によらず、動的で効率的なオブジェクトの追跡を容易に実施するために、Ceph Storage では配置グループ (PG) が使用されています。OSD の障害やクラスターのリバランスの際には、Ceph は配置グループおよびその内容を移動または複製することができるので、Ceph Storage クラスターは効率的にリバランスおよび復旧を行うことができます。
- director が作成するデフォルトの配置グループ数が常に最適とは限らないので、実際の要件に応じて正しい配置グループ数を計算することが重要です。配置グループの計算ツールを使用して、正しい配置グループ数を計算することができます。PG の計算ツールを使用するには、Ceph クラスターに関するその他の属性 (OSD の数など) と共に、サービスごとに予測されるストレージ使用量をパーセンテージで入力します。計算ツールは、プールごとに最適な PG 数を返します。詳細は、Ceph Placement Groups (PGs) per Pool Calculator を参照してください。
- 自動スケーリングは、配置グループを管理するもう 1 つの方法です。自動スケーリング機能では、具体的な配置グループ数ではなく、サービスごとに予想される Ceph Storage 要件をパーセンテージで設定します。Ceph は、クラスターの使用状況に応じて配置グループを自動的にスケーリングします。詳細は、Red Hat Ceph Storage ストレージストラテジーガイドの 配置グループの自動スケーリング を参照してください。
プロセッサー
- Intel 64 または AMD64 CPU 拡張機能をサポートする 64 ビット x86 プロセッサー。
ネットワークインターフェイスカード
- 最小 1 枚の 1 Gbps ネットワークインターフェイスカード (NIC)。ただし、Red Hat では実稼働環境の場合には最低でも NIC を 2 枚使用することを推奨します。ボンディングインターフェイス向けやタグ付けされた VLAN トラフィックを委譲する場合は、追加の NIC を使用します。特に大量のトラフィックを処理する Red Hat OpenStack Platform (RHOSP) 環境を構築する場合には、ストレージノードに 10 Gbps インターフェイスを使用します。
電源管理
- 各 Controller ノードには、Intelligent Platform Management Interface (IPMI) 機能などのサポート対象の電源管理インターフェイスがサーバーのマザーボードに搭載されている必要があります。
Ceph Storage クラスターを使用するオーバークラウドのインストールについての詳しい情報は、Deploying an Overcloud with Containerized Red Hat Ceph を参照してください。
6.9. オブジェクトストレージノードの要件
オブジェクトストレージノードは、オーバークラウドのオブジェクトストレージ層を提供します。Object Storage プロキシーは、Controller ノードにインストールされます。ストレージ層には、ノードごとに複数のディスクを持つベアメタルノードが必要です。
- プロセッサー
- 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 トラフィックを委譲する場合や、ボンディングインターフェイス向けには、追加のネットワークインターフェイスを使用します。
- 電源管理
- 各 Controller ノードには、Intelligent Platform Management Interface (IPMI) 機能などのサポート対象の電源管理インターフェイスがサーバーのマザーボードに搭載されている必要があります。
6.10. オーバークラウドのリポジトリー
Red Hat OpenStack Platform (RHOSP) 16.2 は、Red Hat Enterprise Linux (RHEL) 8.4 上で動作します。そのため、これらのリポジトリーからのコンテンツをそれぞれの RHEL バージョンにロックする必要があります。
-
Red Hat Satellite を使用してリポジトリーを同期する場合は、RHEL リポジトリーの特定バージョンを有効にすることができます。ただし、選択したバージョンに関係なく、リポジトリーラベルは同じままです。たとえば、BaseOS リポジトリーの 8.4 バージョンを有効にした場合、リポジトリー名には有効にした特定のバージョンが含まれますが、リポジトリーラベルは依然として
rhel-8-for-x86_64-baseos-eus-rpms
です。 -
advanced-virt-for-rhel-8-x86_64-rpms
およびadvanced-virt-for-rhel-8-x86_64-eus-rpms
リポジトリーは必要なくなりました。これらのリポジトリーを無効にするには、Red Hat ナレッジベースのソリューション記事 advanced-virt-for-rhel-8-x86_64-rpms are no longer required in OSP 16.2 を参照してください。
ここで指定する以外のリポジトリーは、サポートされません。別途推奨されない限り、以下の表に記載されている以外の製品またはリポジトリーを有効にしないでください。有効にすると、パッケージの依存関係の問題が発生する可能性があります。Extra Packages for Enterprise Linux (EPEL) を有効にしないでください。
Controller ノード用リポジトリー
以下の表には、オーバークラウドの Controller ノード用コアリポジトリーをまとめています。
名前 | リポジトリー | 要件の説明 |
---|---|---|
Red Hat Enterprise Linux 8 for x86_64 - BaseOS (RPMs) Extended Update Support (EUS) |
| x86_64 システム用ベースオペレーティングシステムのリポジトリー |
Red Hat Enterprise Linux 8 for x86_64 - AppStream (RPMs) |
| RHOSP の依存関係が含まれます。 |
Red Hat Enterprise Linux 8 for x86_64 - High Availability (RPMs) Extended Update Support (EUS) |
| RHEL の高可用性ツール。 |
Red Hat Ansible Engine 2.9 for RHEL 8 x86_64 (RPMs) |
| Ansible Engine for RHEL。最新バージョンの Ansible を提供するために使用されます。 |
Red Hat OpenStack Platform 16.2 for RHEL 8 (RPMs) |
| コア RHOSP リポジトリー。 |
Red Hat Fast Datapath for RHEL 8 (RPMS) |
| OpenStack Platform 用 Open vSwitch (OVS) パッケージを提供します。 |
Red Hat Ceph Storage Tools 4 for RHEL 8 x86_64 (RPMs) |
| Red Hat Ceph Storage 4 for RHEL 8 のツール。 |
Compute ノードおよび ComputeHCI ノードのリポジトリー
以下の表に、オーバークラウド内の Compute ノードおよび ComputeHCI ノードのコアリポジトリーを示します。
名前 | リポジトリー | 要件の説明 |
---|---|---|
Red Hat Enterprise Linux 8 for x86_64 - BaseOS (RPMs) Extended Update Support (EUS) |
| x86_64 システム用ベースオペレーティングシステムのリポジトリー |
Red Hat Enterprise Linux 8 for x86_64 - AppStream (RPMs) |
| RHOSP の依存関係が含まれます。 |
Red Hat Enterprise Linux 8 for x86_64 - High Availability (RPMs) Extended Update Support (EUS) |
| RHEL の高可用性ツール。 |
Red Hat Ansible Engine 2.9 for RHEL 8 x86_64 (RPMs) |
| Ansible Engine for RHEL。最新バージョンの Ansible を提供するために使用されます。 |
Red Hat OpenStack Platform 16.2 for RHEL 8 (RPMs) |
| コア RHOSP リポジトリー。 |
Red Hat Fast Datapath for RHEL 8 (RPMS) |
| OpenStack Platform 用 Open vSwitch (OVS) パッケージを提供します。 |
Red Hat Ceph Storage Tools 4 for RHEL 8 x86_64 (RPMs) |
| Red Hat Ceph Storage 4 for RHEL 8 のツール。 |
Real Time Compute リポジトリー
以下の表には、Real Time Compute (RTC) 機能用リポジトリーをまとめています。
名前 | リポジトリー | 要件の説明 |
---|---|---|
Red Hat Enterprise Linux 8 for x86_64 - Real Time (RPMs) |
|
リアルタイム KVM (RT-KVM) のリポジトリー。リアルタイムカーネルを有効化するためのパッケージが含まれています。RT-KVM 対象のすべての Compute ノードで、このリポジトリーを有効にします。注記: このリポジトリーにアクセスするには、別途 |
Red Hat Enterprise Linux 8 for x86_64 - Real Time for NFV (RPMs) |
|
NFV 向けのリアルタイム KVM (RT-KVM) のリポジトリー。リアルタイムカーネルを有効化するためのパッケージが含まれています。RT-KVM 対象のすべての NFV Compute ノードで、このリポジトリーを有効にします。注記: このリポジトリーにアクセスするには、別途 |
Ceph Storage ノード用リポジトリー
以下の表には、オーバークラウド用の Ceph Storage 関連のリポジトリーをまとめています。
名前 | リポジトリー | 要件の説明 |
---|---|---|
Red Hat Enterprise Linux 8 for x86_64 - BaseOS (RPMs) |
| x86_64 システム用ベースオペレーティングシステムのリポジトリー |
Red Hat Enterprise Linux 8 for x86_64 - AppStream (RPMs) |
| RHOSP の依存関係が含まれます。 |
Red Hat Enterprise Linux 8 for x86_64 - High Availability (RPMs) Extended Update Support (EUS) |
|
RHEL の高可用性ツール。注記: Ceph Storage ロールに |
Red Hat Ansible Engine 2.9 for RHEL 8 x86_64 (RPMs) |
| Ansible Engine for RHEL。最新バージョンの Ansible を提供するために使用されます。 |
Red Hat OpenStack Platform 16.2 Director Deployment Tools for RHEL 8 x86_64 (RPMs) |
|
director が Ceph Storage ノードを設定するのに役立つパッケージ。このリポジトリーは、スタンドアロンの Ceph Storage サブスクリプションに含まれています。OpenStack Platform と Ceph Storage を組み合わせたサブスクリプションを使用する場合は、 |
Red Hat OpenStack Platform 16.2 for RHEL 8 (RPMs) |
|
director が Ceph Storage ノードを設定するのに役立つパッケージ。このリポジトリーは、OpenStack Platform と Ceph Storage を組み合わせたサブスクリプションに含まれています。スタンドアロンの Ceph Storage サブスクリプションを使用する場合は、 |
Red Hat Ceph Storage Tools 4 for RHEL 8 x86_64 (RPMs) |
| Ceph Storage クラスターと通信するためのノード用のツールを提供します。 |
Red Hat Fast Datapath for RHEL 8 (RPMS) |
| OpenStack Platform 用 Open vSwitch (OVS) パッケージを提供します。Ceph Storage ノードで OVS を使用している場合は、このリポジトリーをネットワークインターフェイス設定 (NIC) テンプレートに追加します。 |
IBM POWER 用リポジトリー
次の表に、POWER PC アーキテクチャー上の RHOSP のリポジトリーをまとめています。コアリポジトリーの該当リポジトリーの代わりに、これらのリポジトリーを使用してください。
名前 | リポジトリー | 要件の説明 |
---|---|---|
Red Hat Enterprise Linux for IBM Power, little endian - BaseOS (RPMs) |
| ppc64le システム用ベースオペレーティングシステムのリポジトリー |
Red Hat Enterprise Linux 8 for IBM Power, little endian - AppStream (RPMs) |
| RHOSP の依存関係が含まれます。 |
Red Hat Enterprise Linux 8 for IBM Power, little endian - High Availability (RPMs) |
| RHEL の高可用性ツール。Controller ノードの高可用性に使用します。 |
Red Hat Fast Datapath for RHEL 8 IBM Power, little endian (RPMS) |
| OpenStack Platform 用 Open vSwitch (OVS) パッケージを提供します。 |
Red Hat Ansible Engine 2.9 for RHEL 8 IBM Power, little endian (RPMs) |
| Ansible Engine for RHEL。最新バージョンの Ansible を提供するために使用されます。 |
Red Hat OpenStack Platform 16.2 for RHEL 8 (RPMs) |
| ppc64le システム用のコア RHOSP リポジトリー。 |
6.11. プロビジョニングの方法
Red Hat OpenStack Platform 環境にノードをプロビジョニングする場合、使用できる主な方法が 3 つあります。
- director を使用したプロビジョニング
-
Red Hat OpenStack Platform director は、標準のプロビジョニング方法です。このシナリオでは、
openstack overcloud deploy
コマンドによって、デプロイメントのプロビジョニングと設定の両方を実行します。標準のプロビジョニングおよびデプロイメント方法についての詳しい情報は、7章基本的なオーバークラウドの設定 を参照してください。 - OpenStack Bare Metal (ironic) サービスを使用したプロビジョニング
このシナリオでは、標準の director デプロイメントのプロビジョニングステージと設定ステージを、2 つの別のプロセスに分割することができます。この方法は、標準の director デプロイメントに伴うリスクの一部を軽減し、より効率的に障害点を特定するのに役立ちます。このシナリオについての詳しい情報は、8章オーバークラウドのデプロイ前に行うベアメタルノードのプロビジョニング を参照してください。
重要この機能は、本リリースでは テクノロジープレビュー として提供しているため、Red Hat では全面的にはサポートしていません。これは、テスト用途にのみご利用いただく機能です。実稼働環境にはデプロイしないでください。テクノロジープレビュー機能についての詳しい情報は、対象範囲の詳細 を参照してください。
- 外部ツールを使用したプロビジョニング
このシナリオでは、director は外部ツールを使用して事前にプロビジョニングされたノードでオーバークラウドの設定を制御します。この方法は、電源管理制御を設定せずにオーバークラウドを作成する場合や、DHCP/PXE ブートの制限があるネットワークを使用する場合、あるいは QCOW2
overcloud-full
イメージに依存しないカスタムのパーティションレイアウトを持つノードを使用する場合に便利です。このシナリオでは、ノードの管理に OpenStack Compute (nova)、OpenStack Bare Metal (ironic)、または OpenStack Image (glance) サービスを使用しません。このシナリオについての詳しい情報は、9章事前にプロビジョニングされたノードを使用した基本的なオーバークラウドの設定 を参照してください。
事前にプロビジョニングされたノードと director がプロビジョニングしたノードを組み合わせることはできません。
第7章 基本的なオーバークラウドの設定
基本設定のオーバークラウドには、カスタム機能は含まれません。基本的な Red Hat OpenStack Platform (RHOSP) 環境を設定するには、次のタスクを実行する必要があります。
- オーバークラウドのベアメタルノードを登録します。
- ベアメタルノードのハードウェアのインベントリーをディレクターに提供します。
- 各ベアメタルノードに、ノードを指定されたロールに一致させるリソースクラスでタグ付けします。
この基本的なオーバークラウドに高度な設定オプションを追加して、仕様に合わせてカスタマイズできます。詳細は、Advanced Overcloud Customization を参照してください。
7.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
フィールドにダミーのデータを含める必要があります。偽のデータを含める方法の詳細は、Using director introspection to collect bare metal node hardware information を参照してください。
-
- cpu
- (オプション) ノード上の CPU 数
- memory
- (オプション) メモリーサイズ (MB 単位)
- disk
- (オプション) ハードディスクのサイズ (GB 単位)
- arch
(オプション) システムアーキテクチャー
重要マルチアーキテクチャークラウドをビルドする場合には、
x86_64
アーキテクチャーを使用するノードとppc64le
アーキテクチャーを使用するノードを区別するために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
重要マルチアーキテクチャーノードの場合は、
--http-boot /var/lib/ironic/tftpboot/
オプションも追加する必要があります。-
ファイルを
stack
ユーザーのホームディレクトリー (/home/stack/nodes.json
) に保存します。 テンプレートを director にインポートして、各ノードをテンプレートから director に登録します。
(undercloud)$ openstack overcloud node import ~/nodes.json
注記UEFI ブートモードを使用する場合は、各ノードでブートモードも設定する必要があります。UEFI ブートモードを設定せずにノードをイントロスペクトすると、ノードはレガシーモードでブートします。詳細は、Setting the boot mode to UEFI boot mode を参照してください。
ノードの登録および設定が完了するまで待ちます。完了したら、ノードが director に正しく登録されていることを確認します。
(undercloud)$ openstack baremetal node list
7.2. ベアメタルノードハードウェアのインベントリーの作成
ディレクターは、プロファイルのタグ付け、ベンチマーク、および手動のルートディスク割り当てのために、Red Hat OpenStack Platform (RHOSP) デプロイメント内のノードのハードウェアインベントリーを必要とします。
次のいずれかの方法を使用して、ハードウェアインベントリーをディレクターに提供できます。
- Automatic: 各ノードからハードウェア情報を収集するディレクターのイントロスペクションプロセスを使用できます。このプロセスは、各ノードでイントロスペクションエージェントを起動します。イントロスペクションエージェントは、ノードからハードウェアのデータを収集し、そのデータを director に送り返します。ディレクターは、アンダークラウドノードで実行されている Object Storage サービス (swift) にハードウェアデータを保存します。
- Manual: 各ベアメタルマシンの基本的なハードウェアインベントリーを手動で設定できます。このインベントリーは、ベアメタルプロビジョニングサービス (ironic) に保存され、ベアメタルマシンの管理とデプロイに使用されます。
オーバークラウドに derive_params.yaml
を使用する場合は、ディレクターの自動イントロスペクションプロセスを使用する必要があります。これには、イントロスペクションデータが存在する必要があります。derive_params.yaml
の詳細は、Workflows and derived parameters を参照してください。
ディレクターの自動イントロスペクションプロセスには、ベアメタルプロビジョニングサービスポートを手動で設定する方法に比べて、次の利点があります。
-
イントロスペクションは、接続されているすべてのポートをハードウェア情報に記録します。これには、
nodes.yaml
でまだ設定されていない場合に PXE ブートに使用するポートも含まれます。 -
イントロスペクションは、属性が LLDP を使用して検出可能である場合、各ポートの
local_link_connection
属性を設定します。手動による方法を使用する場合は、ノードを登録するときに各ポートにlocal_link_connection
を設定する必要があります。 -
イントロスペクションは、スパイン/リーフ型または DCN のアーキテクチャーをデプロイするときに、ベアメタルプロビジョニングサービスポートの
physical_network
属性を設定します。
7.2.1. ディレクターのイントロスペクションを使用してベアメタルノードのハードウェア情報を収集する
物理マシンをベアメタルノードとして登録した後、ディレクターイントロスペクションを使用して、ハードウェアの詳細を自動的に追加し、イーサネット MAC アドレスごとにポートを作成できます。
自動イントロスペクションの代わりに、ベアメタルノードのハードウェア情報をディレクターに手動で提供できます。詳細は、ベアメタルノードのハードウェア情報を手動で設定する を参照してください。
前提条件
- オーバークラウドのベアメタルノードを登録しました。
手順
-
アンダークラウドホストに
stack
ユーザーとしてログインします。 stackrc
アンダークラウド認証情報ファイルを入手します。$ source ~/stackrc
pre-introspection 検証グループを実行して、プリイントロスペクションの要件を確認します。
(undercloud)$ openstack tripleo validator run --group pre-introspection
- 検証レポートの結果を確認します。
オプション: 特定の検証からの詳細な出力を確認します。
(undercloud)$ openstack tripleo validator show run --full <validation>
<validation>
を、確認するレポートの特定の検証の 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
を設定していることも確認する必要があります。(undercloud)$ 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
に設定します。(undercloud)$ openstack baremetal port set <port_uuid> \ --local-link-connection switch_id=52:54:00:00:00:00 \ --local-link-connection port_id=p0
ローカルリンク接続フィールドにダミーのデータが含まれていることを確認します。
(undercloud)$ openstack baremetal port list --long -c UUID -c "Node UUID" -c "Local Link Connection"
イントロスペクション完了後には、すべてのノードが available
の状態に変わります。
7.2.2. ベアメタルノードのハードウェア情報を手動で設定する
物理マシンをベアメタルノードとして登録した後、ハードウェアの詳細を手動で追加し、イーサネット MAC アドレスごとにベアメタルポートを作成できます。オーバークラウドをデプロイする前に、少なくとも 1 つのベアメタルポートを作成する必要があります。
手動イントロスペクションの代わりに、自動ディレクターイントロスペクションプロセスを使用して、ベアメタルノードのハードウェア情報を収集できます。詳細は、Using director introspection to collect bare metal node hardware information を参照してください。
前提条件
- オーバークラウドのベアメタルノードを登録しました。
-
nodes.json
の登録済みノードの各ポートにlocal_link_connection
を設定しました。詳しい情報は、Registering nodes for the overcloud を参照してください。
手順
-
アンダークラウドホストに
stack
ユーザーとしてログインします。 stackrc
アンダークラウド認証情報ファイルを入手します。$ source ~/stackrc
ノードの機能に
boot_option':'local
を追加して、登録されたノードごとにブートオプションをlocal
に設定します。(undercloud)$ openstack baremetal node set \ --property capabilities="boot_option:local" <node>
-
<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 | +------------+--------+---------------------------------------------+ | boot | False | Cannot validate image information for node | | | | a02178db-1550-4244-a2b7-d7035c743a9b | | | | because one or more parameters are missing | | | | from its instance_info. Missing are: | | | | ['ramdisk', 'kernel', 'image_source'] | | console | None | not supported | | deploy | False | Cannot validate image information for node | | | | a02178db-1550-4244-a2b7-d7035c743a9b | | | | because one or more parameters are missing | | | | from its instance_info. Missing are: | | | | ['ramdisk', 'kernel', 'image_source'] | | inspect | None | not supported | | management | True | | | network | True | | | power | True | | | raid | True | | | storage | True | | +------------+--------+---------------------------------------------+
有効出力の
Result
は、次のことを示しています。-
False
: インターフェイスは検証に失敗しました。instance_info
パラメーター[\'ramdisk', \'kernel', and \'image_source']
が見つからない場合、Compute サービスがデプロイメントプロセスの最初にこれらのパラメーターを設定するので、この時点では設定されていない可能性があ ります。ディスクイメージ全体を使用している場合は、検証にパスするためにimage_source
を設定するだけでよい場合があります。 -
True
: インターフェイスは検証にパスしました。 -
None
: インターフェイスはドライバーでサポートされていません。
-
7.3. プロファイルへのノードのタグ付け
各ノードのハードウェアを登録、検査した後には、特定のプロファイルにノードをタグ付けします。このプロファイルタグにより、ノードがフレーバーに照合され、そのフレーバーがデプロイメントロールに割り当てられます。以下の例は、Controller ノードのロール、フレーバー、プロファイル、ノード間の関係を示しています。
タイプ | 説明 |
---|---|
ロール |
|
フレーバー |
|
プロファイル |
|
ノード |
また、各ノードに |
アンダークラウドのインストール時に、デフォルトプロファイルのフレーバー compute
、control
、swift-storage
、ceph-storage
、block-storage
が作成され、大半の環境で変更なしに使用することができます。
手順
特定のプロファイルにノードをタグ付けする場合には、各ノードの
properties/capabilities
パラメーターにprofile
オプションを追加します。たとえば、特定のプロファイルを使用するように特定のノードをタグ付けするには、以下のコマンドを使用します。(undercloud) $ NODE=<NODE NAME OR ID> (undercloud) $ PROFILE=<PROFILE NAME> (undercloud) $ openstack baremetal node set --property capabilities="profile:$PROFILE,boot_option:local" $NODE
-
$NODE
変数にノードの名前または UUID を設定します。 -
$PROFILE
変数は、control
またはcompute
などの特定のプロファイルに設定します。 -
properties/capabilities
のprofile
オプションには、profile:control
またはprofile:compute
などの対応するプロファイルとノードをタグ付けする$PROFILE
変数が含まれます。 -
各ノードのブート方法を定義するには、
boot_option:local
オプションを設定します。
追加の
openstack baremetal node show
コマンドおよびjq
フィルタリングを使用して、既存のcapabilities
の値を保持することもできます。(undercloud) $ openstack baremetal node set --property capabilities="profile:$PROFILE,boot_option:local,$(openstack baremetal node show $NODE -f json -c properties | jq -r .properties.capabilities | sed "s/boot_mode:[^,]*,//g")" $NODE
-
ノードのタグ付けが完了した後には、割り当てたプロファイルまたはプロファイルの候補を確認します。
(undercloud) $ openstack overcloud profiles list
7.4. ブートモードを UEFI モードに設定する
デフォルトのブートモードはレガシー BIOS モードです。レガシー BIOS ブートモードの代わりに UEFI ブートモードを使用するように RHOSP デプロイメントのノードを設定できます。
一部のハードウェアは、レガシー BIOS ブートモードをサポートしていません。レガシー BIOS ブートモードをサポートしていないハードウェアでレガシー BIOS ブートモードを使用しようとすると、デプロイメントが失敗する可能性があります。ハードウェアが正常にデプロイされるようにするには、UEFI ブートモードを使用します。
UEFI ブートモードを有効にする場合は、ユーザーイメージとともに、パーティションレイアウトとブートローダーを含む独自のディスク全体のイメージを構築する必要があります。完全なディスクイメージの作成に関する詳細は、完全なディスクイメージの作成 を参照してください。
手順
undercloud.conf
ファイルで以下のパラメーターを設定します。ipxe_enabled = True
undercloud.conf
ファイルを保存して、アンダークラウドのインストールを実行します。$ openstack undercloud install
インストールスクリプトが完了するまで待ちます。
登録された各ノードの既存の機能を確認します。
$ openstack baremetal node show <node> -f json -c properties | jq -r .properties.capabilities
-
<node>
をベアメタルノードの ID に置き換えてください。
-
ノードの既存の機能に
boot_mode:uefi
を追加して、登録されている各ノードのブートモードをuefi
に設定します。$ openstack baremetal node set --property capabilities="boot_mode:uefi,<capability_1>,...,<capability_n>" <node>
-
<node>
をベアメタルノードの ID に置き換えてください。 <capability_1>
および<capability_n>
までのすべての機能を、手順 3 で取得した各機能に置き換えます。たとえば、次のコマンドを使用して、ローカルブートでブートモードを
uefi
に設定します。
$ openstack baremetal node set --property capabilities="boot_mode:uefi,boot_option:local" <node>
-
ベアメタルフレーバーごとに、ブートモードを
uefi
に設定します。$ openstack flavor set --property capabilities:boot_mode='uefi' <flavor>
7.5. 仮想メディアブートの有効化
この機能は、本リリースでは テクノロジープレビュー として提供しているため、Red Hat では全面的にはサポートしていません。これは、テスト用途にのみご利用いただく機能です。実稼働環境にはデプロイしないでください。テクノロジープレビュー機能についての詳しい情報は、対象範囲の詳細 を参照してください。
Redfish 仮想メディアブートを使用して、ノードの Baseboard Management Controller (BMC) にブートイメージを提供することができます。これにより、BMC はイメージを仮想ドライブのいずれかに挿入することができます。その後、ノードは仮想ドライブからイメージに存在するオペレーティングシステムにブートすることができます。
Redfish ハードウェア種別は、仮想メディアを通じたデプロイ、レスキュー、およびユーザーの各イメージのブートに対応しています。Bare Metal サービス (ironic) は、ノードのデプロイメント時に、ノードに関連付けられたカーネルイメージおよび ramdisk イメージを使用して、UEFI または BIOS ブートモード用のブート可能 ISO イメージをビルドします。仮想メディアブートの主な利点は、PXE の TFTP イメージ転送フェーズを排除し、HTTP GET 等の方法を使用することができる点です。
仮想メディアを通じて redfish
ハードウェア種別のノードをブートするには、ブートインターフェイスを redfish-virtual-media
に設定し、UEFI ノードの場合は EFI システムパーティション (ESP) イメージを定義します。続いて、登録したノードが Redfish 仮想メディアブートを使用するように設定します。
前提条件
-
undercloud.conf
ファイルのenabled_hardware_types
パラメーターで、Redfish ドライバーが有効化されている。 - ベアメタルノードが登録されている。
- Image サービス (glance) に IPA およびインスタンスイメージがある。
- UEFI ノードの場合、EFI システムパーティション (ESP) イメージも Image サービス (glance) で利用可能でなければなりません。
- ベアメタルフレーバー
- クリーニングおよびプロビジョニング用ネットワーク
手順
Bare Metal サービス (ironic) のブートインターフェイスを
redfish-virtual-media
に設定します。$ openstack baremetal node set --boot-interface redfish-virtual-media $NODE_NAME
-
$NODE_NAME
はノード名に置き換えてください。
-
UEFI ノードの場合は、ブートモードを
uefi
に設定します。NODE=<NODE NAME OR ID> ; openstack baremetal node set --property capabilities="boot_mode:uefi,$(openstack baremetal node show $NODE -f json -c properties | jq -r .properties.capabilities | sed "s/boot_mode:[^,]*,//g")" $NODE
$NODE
はノード名に置き換えてください。注記BIOS ノードの場合は、このステップを実施しないでください。
UEFI ノードの場合は、EFI システムパーティション (ESP) イメージを定義します。
$ openstack baremetal node set --driver-info bootloader=$ESP $NODE_NAME
$ESP
は glance イメージの UUID または ESP イメージの URL に、$NODE_NAME
はノードの名前に、それぞれ置き換えてください。注記BIOS ノードの場合は、このステップを実施しないでください。
ベアメタルノードにポートを作成し、そのポートをベアメタルノード上の NIC の MAC アドレスに関連付けます。
$ openstack baremetal port create --pxe-enabled True --node $UUID $MAC_ADDRESS
-
$UUID
はベアメタルノードの UUID に、$MAC_ADDRESS
はベアメタルノード上の NIC の MAC アドレスに、それぞれ置き換えてください。
-
7.6. マルチディスククラスターのルートディスクの定義
ほとんどの Ceph Storage ノードは複数のディスクを使用します。ノードが複数のディスクを使用する場合、director はルートディスクを識別する必要があります。デフォルトのプロビジョニングプロセスでは、director はルートディスクにオーバークラウドイメージを書き込みます。
この手順を使用して、シリアル番号でルートデバイスを識別します。ルートディスクを識別するために使用できるその他のプロパティーの詳細については、「ルートディスクを識別するプロパティー」 を参照してください。
手順
各ノードのハードウェアイントロスペクションからのディスク情報を確認します。以下のコマンドを実行して、ノードのディスク情報を表示します。
(undercloud)$ openstack baremetal introspection data save 1a4e30da-b6dc-499d-ba87-0bd8a3819bc0 | jq ".inventory.disks"
たとえば、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='{"serial":"<serial_number>"}' <node-uuid>
たとえば、ルートデバイスをシリアル番号が
61866da04f380d001ea4e13c12e36ad6
の disk 2 に設定するには、以下のコマンドを実行します。(undercloud)$ openstack baremetal node set --property root_device='{"serial": "61866da04f380d001ea4e13c12e36ad6"}' 1a4e30da-b6dc-499d-ba87-0bd8a3819bc0
注記選択したルートディスクから起動するように各ノードの BIOS を設定します。最初にネットワークからのブートを試み、次にルートディスクからのブートを試みるように、ブート順序を設定します。
director は、ルートディスクとして使用する特定のディスクを把握します。openstack overcloud deploy
コマンドを実行すると、director はオーバークラウドをプロビジョニングし、ルートディスクにオーバークラウドのイメージを書き込みます。
7.7. ルートディスクを識別するプロパティー
以下の属性を定義すると、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
を使用しないでください。この値は、ノードのブート時に変更される可能性があります。
7.8. overcloud-minimal イメージの使用による Red Hat サブスクリプションエンタイトルメントの使用回避
デフォルトでは、プロビジョニングプロセス中 director はルートディスクに QCOW2 overcloud-full
イメージを書き込みます。overcloud-full
イメージには、有効な Red Hat サブスクリプションが使用されます。ただし、overcloud-minimal
イメージを使用して、たとえばベア OS をプロビジョニングすることもできます。この場合、他の OpenStack サービスは使用されないので、サブスクリプションエンタイトルメントは消費されません。
この典型的なユースケースは、Ceph デーモンのみを持つノードをプロビジョニングする場合です。この場合や類似のユースケースでは、overcloud-minimal
イメージのオプションを使用して、有償の Red Hat サブスクリプションが限度に達するのを避けることができます。overcloud-minimal
イメージの取得方法についての情報は、オーバークラウドノードのイメージの取得 を参照してください。
Red Hat OpenStack Platform (RHOSP) のサブスクリプションには Open vSwitch (OVS) が含まれますが、overcloud-minimal
イメージを使用する場合には、OVS などのコアサービスは利用できません。Ceph Storage ノードをデプロイするのに OVS は必要ありません。ovs_bond
を使用してボンディングを定義する代わりに、linux_bond
を使用します。linux_bond
の詳細は、Linux ボンディングのオプション を参照してください。
手順
overcloud-minimal
イメージを使用するように director を設定するには、以下のイメージ定義を含む環境ファイルを作成します。parameter_defaults: <roleName>Image: overcloud-minimal
<roleName>
をロール名に置き換え、ロール名にImage
を追加します。Ceph Storage ノードのovercloud-minimal
イメージの例を以下に示します。parameter_defaults: CephStorageImage: overcloud-minimal
roles_data.yaml
ロール定義ファイルで、rhsm_enforce
パラメーターをFalse
に設定します。rhsm_enforce: False
-
この環境ファイルを
openstack overcloud deploy
コマンドに渡します。
overcloud-minimal
イメージでは、標準の Linux ブリッジしかサポートされません。OVS は Red Hat OpenStack Platform のサブスクリプションエンタイトルメントが必要な OpenStack サービスなので、このイメージでは OVS はサポートされません。
7.9. アーキテクチャーに固有なロールの作成
マルチアーキテクチャークラウドを構築する場合には、roles_data.yaml
ファイルにアーキテクチャー固有のロールを追加する必要があります。以下に示す例では、デフォルトのロールに加えて ComputePPC64LE
ロールを追加しています。
openstack overcloud roles generate \ --roles-path /usr/share/openstack-tripleo-heat-templates/roles -o ~/templates/roles_data.yaml \ Controller Compute ComputePPC64LE BlockStorage ObjectStorage CephStorage
Creating a Custom Role File セクションには、ロールについての情報が記載されています。
7.10. 環境ファイル
アンダークラウドには、オーバークラウドの作成プランを形作るさまざまな heat テンプレートが含まれます。YAML フォーマットの環境ファイルを使用して、オーバークラウドの特性をカスタマイズすることができます。このファイルで、コア heat テンプレートコレクションのパラメーターおよびリソースを上書きします。必要に応じていくつでも環境ファイルを追加することができます。ただし、後で指定する環境ファイルで定義されるパラメーターとリソースが優先されることになるため、環境ファイルの順番は重要です。以下のリストは、環境ファイルの順序の例です。
- 各ロールのノード数およびフレーバー。オーバークラウドを作成するには、この情報の追加は不可欠です。
- コンテナー化された OpenStack サービスのコンテナーイメージの場所
任意のネットワーク分離ファイル。heat テンプレートコレクションの初期化ファイル (
environments/network-isolation.yaml
) から開始して、次にカスタムの NIC 設定ファイル、最後に追加のネットワーク設定の順番です。詳しい情報は、Advanced Overcloud Customization の以下の章を参照してください。- 外部のロードバランサーを使用している場合には、外部の負荷分散機能の環境ファイル。詳しい情報は、External Load Balancing for the Overcloud を参照してください。
- Ceph Storage、NFS、または iSCSI 等のストレージ環境ファイル
- Red Hat CDN または Satellite 登録用の環境ファイル
- その他のカスタム環境ファイル
Open Virtual Networking (OVN) は、Red Hat OpenStack Platform 16.2 におけるデフォルトのネットワークメカニズムドライバーです。分散仮想ルーター (DVR) で OVN を使用する場合には、openstack overcloud deploy
コマンドに environments/services/neutron-ovn-dvr-ha.yaml
ファイルを追加する必要があります。DVR なしで OVN を使用する場合には、openstack overcloud deploy
コマンドに environments/services/neutron-ovn-ha.yaml
ファイルを追加する必要があります。
Red Hat では、カスタム環境ファイルを別のディレクトリーで管理することを推奨します (たとえば、templates
ディレクトリー)。
オーバークラウドの高度な機能のカスタマイズについての詳しい情報は、Advanced Overcloud Customization を参照してください。
基本的なオーバークラウドでは、ブロックストレージにローカルの LVM ストレージを使用しますが、この設定はサポートされません。ブロックストレージには、外部ストレージソリューション (Red Hat Ceph Storage 等) を使用することを推奨します。
環境ファイルの拡張子は、.yaml
または .template
にする必要があります。そうでないと、カスタムテンプレートリソースとして処理されません。
これ以降の数セクションで、オーバークラウドに必要な環境ファイルの作成について説明します。
7.11. ノード数とフレーバーを定義する環境ファイルの作成
デフォルトでは、director は baremetal
フレーバーを使用して 1 つの Controller ノードと 1 つの Compute ノードを持つオーバークラウドをデプロイします。ただし、この設定は概念検証のためのデプロイメントにしか適しません。異なるノード数およびフレーバーを指定して、デフォルトの設定をオーバーライドすることができます。小規模な実稼働環境では、少なくとも 3 つの Controller ノードと 3 つの Compute ノードをデプロイし、特定のフレーバーを割り当ててノードが適切なリソース仕様を持つようにします。ノード数およびフレーバーの割り当てを定義する環境ファイル node-info.yaml
を作成するには、以下の手順を実施します。
手順
/home/stack/templates/
ディレクトリーにnode-info.yaml
ファイルを作成します。(undercloud) $ touch /home/stack/templates/node-info.yaml
ファイルを編集し、必要なノード数およびフレーバーを設定します。以下の例には、3 台の Controller ノードおよび 3 台の Compute ノードが含まれます。
parameter_defaults: OvercloudControllerFlavor: control OvercloudComputeFlavor: compute ControllerCount: 3 ComputeCount: 3
7.12. アンダークラウド 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 設定に関連する他の証明書が含まれる場合があります。
director は、オーバークラウドのデプロイメント時に CA 証明書をそれぞれのオーバークラウドノードにコピーします。これにより、それぞれのノードはアンダークラウドの SSL エンドポイントが提示する暗号化を信頼するようになります。環境ファイルに関する詳しい情報は、「オーバークラウドデプロイメントへの環境ファイルの追加」 を参照してください。
7.13. 新規デプロイメントでの TSX の無効化
Red Hat Enterprise Linux 8.3 以降、カーネルは、デフォルトで Intel Transactional Synchronization Extensions (TSX) 機能のサポートを無効にします。
ワークロードまたはサードパーティーベンダー用に厳密に要求しない限り、新しいオーバークラウドで TSX を明示的に無効にする必要があります。
環境ファイルで KernelArgs
heat パラメーターを設定します。
parameter_defaults: ComputeParameters: KernelArgs: "tsx=off"
openstack overcloud deploy
コマンドを実行する際に、環境ファイルを指定します。
7.14. デプロイメントコマンド
OpenStack 環境作成における最後の段階では、openstack overcloud deploy
コマンドを実行してオーバークラウドを作成します。このコマンドを実行する前に、キーオプションやカスタムの環境ファイルの追加方法を十分に理解しておいてください。
バックグラウンドプロセスとして openstack overcloud deploy
を実行しないでください。オーバークラウドの作成をバックグラウンドプロセスとして実行した場合、デプロイメントの途中で停止してしまう可能性があります。
7.15. デプロイメントコマンドのオプション
以下の表には、openstack overcloud deploy
コマンドの追加パラメーターをまとめています。
一部のオプションは、本リリースでは テクノロジープレビュー として提供されているため、Red Hat では全面的にはサポートしていません。これらはテスト目的にのみご利用いただく機能で、実稼働環境で使用すべきではありません。テクノロジープレビュー機能についての詳しい情報は、対象範囲の詳細 を参照してください。
パラメーター | 説明 |
---|---|
|
デプロイする 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 テンプレートのパラメーターを対比しています。
パラメーター | 説明 | heat テンプレートのパラメーター |
---|---|---|
| スケールアウトする Controller ノード数 |
|
| スケールアウトする Compute ノード数 |
|
| スケールアウトする Ceph Storage ノードの数 |
|
| スケールアウトする Block Storage (cinder) ノード数 |
|
| スケールアウトする Object Storage (swift) ノード数 |
|
| Controller ノードに使用するフレーバー |
|
| Compute ノードに使用するフレーバー |
|
| 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 の今後のリリースで廃止される予定です。
7.16. オーバークラウドデプロイメントへの環境ファイルの追加
オーバークラウドをカスタマイズするための環境ファイルを追加するには、-e
オプションを使用します。必要に応じていくつでも環境ファイルを追加することができます。ただし、後で指定する環境ファイルで定義されるパラメーターとリソースが優先されることになるため、環境ファイルの順番は重要です。
-e
オプションを使用してオーバークラウドに追加した環境ファイルはいずれも、オーバークラウドのスタック定義の一部となります。
以下のコマンドは、本シナリオの初期に定義した環境ファイルを使用してオーバークラウドの作成を開始する方法の一例です。
(undercloud) $ openstack overcloud deploy --templates \ -e /home/stack/templates/node-info.yaml\ -e /home/stack/containers-prepare-parameter.yaml \ -e /home/stack/inject-trust-anchor-hiera.yaml \ -r /home/stack/templates/roles_data.yaml \
上記のコマンドでは、以下の追加オプションも使用できます。
- --templates
-
/usr/share/openstack-tripleo-heat-templates
の heat テンプレートコレクションをベースとして使用し、オーバークラウドを作成します。 - -e /home/stack/templates/node-info.yaml
- 各ロールに使用するノード数とフレーバーを定義する環境ファイルを追加します。
- -e /home/stack/containers-prepare-parameter.yaml
- コンテナーイメージ準備の環境ファイルを追加します。このファイルはアンダークラウドのインストール時に生成したもので、オーバークラウドの作成に同じファイルを使用することができます。
- -e /home/stack/inject-trust-anchor-hiera.yaml
- アンダークラウドにカスタム証明書をインストールする環境ファイルを追加します。
- -r /home/stack/templates/roles_data.yaml
- (オプション) カスタムロールを使用する、またはマルチアーキテクチャークラウドを有効にする場合に生成されるロールデータ。詳細は、「アーキテクチャーに固有なロールの作成」 を参照してください。
director は、再デプロイおよびデプロイ後の機能にこれらの環境ファイルを必要とします。これらのファイルが含まれていない場合には、オーバークラウドが破損する可能性があります。
これ以降の段階でオーバークラウド設定を変更するには、以下の操作を実施します。
- カスタムの環境ファイルおよび heat テンプレートのパラメーターを変更します。
-
同じ環境ファイルを指定して
openstack overcloud deploy
コマンドを再度実行します。
オーバークラウドの設定は直接編集しないでください。手動で設定しても、オーバークラウドスタックの更新時に、director が設定を上書きするためです。
7.17. デプロイ前の検証の実行
pre-deployment 検証グループを実行して、デプロイメント要件を確認します。
手順
source コマンドで
stackrc
ファイルを読み込みます。$ source ~/stackrc
この検証には、オーバークラウドプランのコピーが必要です。必要なすべての環境ファイルと共に、オーバークラウドプランをアップロードします。プランのみをアップロードするには、
--update-plan-only
オプションを指定してopenstack overcloud deploy
コマンドを実行します。$ openstack overcloud deploy --templates \ -e environment-file1.yaml \ -e environment-file2.yaml \ ... --update-plan-only
--group pre-deployment オプションを指定して、
openstack tripleo validator run
コマンドを実行します。$ openstack tripleo validator run --group pre-deployment
オーバークラウドにデフォルトのプラン名
overcloud
以外の名前を使用する場合は、--plan
オプションでプラン名を設定します。$ openstack tripleo validator run --group pre-deployment \ --plan myovercloud
検証レポートの結果を確認します。特定の検証からの詳細出力を表示するには、レポートからの特定検証の UUID を指定して
openstack tripleo validator show run --full
コマンドを実行します。$ openstack tripleo validator show run --full <UUID>
検証結果が FAILED
であっても、Red Hat OpenStack Platform のデプロイや実行が妨げられることはありません。ただし、FAILED
の検証結果は、実稼働環境で問題が発生する可能性があることを意味します。
7.18. オーバークラウドデプロイメントの出力
オーバークラウドの作成が完了すると、オーバークラウドを設定するために実施された 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
7.19. オーバークラウドへのアクセス
director は、アンダークラウドからオーバークラウドと対話するための設定を行い、認証をサポートするスクリプトを作成します。director は、このファイル overcloudrc
を stack
ユーザーのホームディレクトリーに保存します。このファイルを使用するには、以下のコマンドを実行します。
(undercloud) $ source ~/overcloudrc
このコマンドにより、アンダークラウド CLI からオーバークラウドと対話するのに必要な環境変数が読み込まれます。コマンドプロンプトが変わり、オーバークラウドと対話していることが示されます。
(overcloud) $
アンダークラウドとの対話に戻るには、以下のコマンドを実行します。
(overcloud) $ source ~/stackrc (undercloud) $
7.20. デプロイ後の検証の実行
post-deployment 検証グループを実行し、デプロイメント後の状態を確認します。
手順
source コマンドで
stackrc
ファイルを読み込みます。$ source ~/stackrc
--group post-deployment オプションを指定して、
openstack tripleo validator run
コマンドを実行します。$ openstack tripleo validator run --group post-deployment
オーバークラウドにデフォルトのプラン名
overcloud
以外の名前を使用する場合は、--plan
オプションでプラン名を設定します。$ openstack tripleo validator run --group post-deployment \ --plan myovercloud
検証レポートの結果を確認します。特定の検証からの詳細出力を表示するには、レポートからの特定検証の UUID を指定して
openstack tripleo validator show run --full
コマンドを実行します。$ openstack tripleo validator show run --full <UUID>
検証結果が FAILED
であっても、Red Hat OpenStack Platform のデプロイや実行が妨げられることはありません。ただし、FAILED
の検証結果は、実稼働環境で問題が発生する可能性があることを意味します。
第8章 オーバークラウドのデプロイ前に行うベアメタルノードのプロビジョニング
この機能は、本リリースでは テクノロジープレビュー として提供しているため、Red Hat では全面的にはサポートしていません。これは、テスト用途にのみご利用いただく機能です。実稼働環境にはデプロイしないでください。テクノロジープレビュー機能についての詳しい情報は、対象範囲の詳細 を参照してください。
オーバークラウドのデプロイメントプロセスには、2 つの主要な操作があります。
- ノードのプロビジョニング
- オーバークラウドのデプロイ
これらの操作を別個のプロセスに分割すると、このプロセスに伴うリスクの一部を軽減し、より効率的に障害点を特定することができます。
ベアメタルノードをプロビジョニングする。
- ノード定義ファイルを yaml 形式で作成します。
- ノード定義ファイルを指定して、プロビジョニングコマンドを実行します。
オーバークラウドをデプロイする。
- プロビジョニングコマンドにより生成される heat 環境ファイルを指定して、デプロイメントコマンドを実行します。
プロビジョニングプロセスにより、ノードがプロビジョニングされ、ノード数、予測可能なノード配置、カスタムイメージ、カスタム NIC 等のさまざまなノード仕様が含まれる heat 環境ファイルが生成されます。オーバークラウドをデプロイする際に、このファイルをデプロイメントコマンドに追加します。
事前にプロビジョニングされたノードと director がプロビジョニングしたノードを組み合わせることはできません。
8.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
フィールドにダミーのデータを含める必要があります。偽のデータを含める方法の詳細は、Using director introspection to collect bare metal node hardware information を参照してください。
-
- cpu
- (オプション) ノード上の CPU 数
- memory
- (オプション) メモリーサイズ (MB 単位)
- disk
- (オプション) ハードディスクのサイズ (GB 単位)
- arch
(オプション) システムアーキテクチャー
重要マルチアーキテクチャークラウドをビルドする場合には、
x86_64
アーキテクチャーを使用するノードとppc64le
アーキテクチャーを使用するノードを区別するために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
重要マルチアーキテクチャーノードの場合は、
--http-boot /var/lib/ironic/tftpboot/
オプションも追加する必要があります。-
ファイルを
stack
ユーザーのホームディレクトリー (/home/stack/nodes.json
) に保存します。 テンプレートを director にインポートして、各ノードをテンプレートから director に登録します。
(undercloud)$ openstack overcloud node import ~/nodes.json
注記UEFI ブートモードを使用する場合は、各ノードでブートモードも設定する必要があります。UEFI ブートモードを設定せずにノードをイントロスペクトすると、ノードはレガシーモードでブートします。詳細は、Setting the boot mode to UEFI boot mode を参照してください。
ノードの登録および設定が完了するまで待ちます。完了したら、ノードが director に正しく登録されていることを確認します。
(undercloud)$ openstack baremetal node list
8.2. ベアメタルノードハードウェアのインベントリーの作成
ディレクターは、プロファイルのタグ付け、ベンチマーク、および手動のルートディスク割り当てのために、Red Hat OpenStack Platform (RHOSP) デプロイメント内のノードのハードウェアインベントリーを必要とします。
次のいずれかの方法を使用して、ハードウェアインベントリーをディレクターに提供できます。
- Automatic: 各ノードからハードウェア情報を収集するディレクターのイントロスペクションプロセスを使用できます。このプロセスは、各ノードでイントロスペクションエージェントを起動します。イントロスペクションエージェントは、ノードからハードウェアのデータを収集し、そのデータを director に送り返します。ディレクターは、アンダークラウドノードで実行されている Object Storage サービス (swift) にハードウェアデータを保存します。
- Manual: 各ベアメタルマシンの基本的なハードウェアインベントリーを手動で設定できます。このインベントリーは、ベアメタルプロビジョニングサービス (ironic) に保存され、ベアメタルマシンの管理とデプロイに使用されます。
オーバークラウドに derive_params.yaml
を使用する場合は、ディレクターの自動イントロスペクションプロセスを使用する必要があります。これには、イントロスペクションデータが存在する必要があります。derive_params.yaml
の詳細は、Workflows and derived parameters を参照してください。
ディレクターの自動イントロスペクションプロセスには、ベアメタルプロビジョニングサービスポートを手動で設定する方法に比べて、次の利点があります。
-
イントロスペクションは、接続されているすべてのポートをハードウェア情報に記録します。これには、
nodes.yaml
でまだ設定されていない場合に PXE ブートに使用するポートも含まれます。 -
イントロスペクションは、属性が LLDP を使用して検出可能である場合、各ポートの
local_link_connection
属性を設定します。手動による方法を使用する場合は、ノードを登録するときに各ポートにlocal_link_connection
を設定する必要があります。 -
イントロスペクションは、スパイン/リーフ型または DCN のアーキテクチャーをデプロイするときに、ベアメタルプロビジョニングサービスポートの
physical_network
属性を設定します。
8.2.1. ディレクターのイントロスペクションを使用してベアメタルノードのハードウェア情報を収集する
物理マシンをベアメタルノードとして登録した後、ディレクターイントロスペクションを使用して、ハードウェアの詳細を自動的に追加し、イーサネット MAC アドレスごとにポートを作成できます。
自動イントロスペクションの代わりに、ベアメタルノードのハードウェア情報をディレクターに手動で提供できます。詳細は、ベアメタルノードのハードウェア情報を手動で設定する を参照してください。
前提条件
- オーバークラウドのベアメタルノードを登録しました。
手順
-
アンダークラウドホストに
stack
ユーザーとしてログインします。 stackrc
アンダークラウド認証情報ファイルを入手します。$ source ~/stackrc
pre-introspection 検証グループを実行して、プリイントロスペクションの要件を確認します。
(undercloud)$ openstack tripleo validator run --group pre-introspection
- 検証レポートの結果を確認します。
オプション: 特定の検証からの詳細な出力を確認します。
(undercloud)$ openstack tripleo validator show run --full <validation>
<validation>
を、確認するレポートの特定の検証の 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
を設定していることも確認する必要があります。(undercloud)$ 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
に設定します。(undercloud)$ openstack baremetal port set <port_uuid> \ --local-link-connection switch_id=52:54:00:00:00:00 \ --local-link-connection port_id=p0
ローカルリンク接続フィールドにダミーのデータが含まれていることを確認します。
(undercloud)$ openstack baremetal port list --long -c UUID -c "Node UUID" -c "Local Link Connection"
イントロスペクション完了後には、すべてのノードが available
の状態に変わります。
8.2.2. ベアメタルノードのハードウェア情報を手動で設定する
物理マシンをベアメタルノードとして登録した後、ハードウェアの詳細を手動で追加し、イーサネット MAC アドレスごとにベアメタルポートを作成できます。オーバークラウドをデプロイする前に、少なくとも 1 つのベアメタルポートを作成する必要があります。
手動イントロスペクションの代わりに、自動ディレクターイントロスペクションプロセスを使用して、ベアメタルノードのハードウェア情報を収集できます。詳細は、Using director introspection to collect bare metal node hardware information を参照してください。
前提条件
- オーバークラウドのベアメタルノードを登録しました。
-
nodes.json
の登録済みノードの各ポートにlocal_link_connection
を設定しました。詳しい情報は、Registering nodes for the overcloud を参照してください。
手順
-
アンダークラウドホストに
stack
ユーザーとしてログインします。 stackrc
アンダークラウド認証情報ファイルを入手します。$ source ~/stackrc
ノードの機能に
boot_option':'local
を追加して、登録されたノードごとにブートオプションをlocal
に設定します。(undercloud)$ openstack baremetal node set \ --property capabilities="boot_option:local" <node>
-
<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 | +------------+--------+---------------------------------------------+ | boot | False | Cannot validate image information for node | | | | a02178db-1550-4244-a2b7-d7035c743a9b | | | | because one or more parameters are missing | | | | from its instance_info. Missing are: | | | | ['ramdisk', 'kernel', 'image_source'] | | console | None | not supported | | deploy | False | Cannot validate image information for node | | | | a02178db-1550-4244-a2b7-d7035c743a9b | | | | because one or more parameters are missing | | | | from its instance_info. Missing are: | | | | ['ramdisk', 'kernel', 'image_source'] | | inspect | None | not supported | | management | True | | | network | True | | | power | True | | | raid | True | | | storage | True | | +------------+--------+---------------------------------------------+
有効出力の
Result
は、次のことを示しています。-
False
: インターフェイスは検証に失敗しました。instance_info
パラメーター[\'ramdisk', \'kernel', and \'image_source']
が見つからない場合、Compute サービスがデプロイメントプロセスの最初にこれらのパラメーターを設定するので、この時点では設定されていない可能性があ ります。ディスクイメージ全体を使用している場合は、検証にパスするためにimage_source
を設定するだけでよい場合があります。 -
True
: インターフェイスは検証にパスしました。 -
None
: インターフェイスはドライバーでサポートされていません。
-
8.3. ベアメタルノードのプロビジョニング
新しい YAML ファイル ~/overcloud-baremetal-deploy.yaml
を作成し、デプロイするベアメタルノードの数と属性を定義して、これらのノードにオーバークラウドロールを割り当てます。プロビジョニングプロセスにより heat 環境ファイルが作成され、そのファイルを openstack overcloud deploy
コマンドに追加することができます。
前提条件
- アンダークラウドがインストールされます。詳しくは、Installing director を参照してください。
- イントロスペクション済みで、プロビジョニングおよびデプロイメントに利用可能なベアメタルノード。詳細は、Registering nodes for the overcloud および Creating an inventory of the bare metal node hardware を参照してください。
手順
source コマンドで
stackrc
アンダークラウド認証情報ファイルを読み込みます。$ source ~/stackrc
新しい
~/overcloud-baremetal-deploy.yaml
ファイルを作成し、プロビジョニングする各ロールのノード数を定義します。たとえば、Controller ノード 3 つと Compute ノード 3 つをプロビジョニングするには、以下の構文を使用します。- name: Controller count: 3 - name: Compute count: 3
~/overcloud-baremetal-deploy.yaml
ファイルで、ノードに割り当てる予測ノード配置、カスタム NIC、またはその他の属性を定義します。たとえば、以下の例の構文を使用すると、3 つの Controller ノードがノードnode00
、node01
、およびnode02
に、3 つの Compute ノードがノード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
ノードエントリーごとに手動でノードを定義するのを避けるために、
defaults
パラメーターでデフォルトのパラメーター値を上書きすることもできます。- name: Controller count: 3 defaults: nics: network: custom-network subnet: custom-subnet instances: - hostname: overcloud-controller-0 name: node00 ...
ノード定義ファイルで使用できるパラメーター、属性、および値の詳細は、Bare metal node provisioning attributes を参照してください。
オプション: デフォルトでは、プロビジョニングプロセスでは
overcloud-full
イメージが使用されます。image
属性を使用して、ロールのすべてのノードまたは特定のノードインスタンスで、使用するカスタムイメージを定義できます。- name: Controller count: 3 instances: - hostname: overcloud-controller-0 name: node00 image: href: overcloud-custom
注記2 TiB を超える root (
/
) パーティションを持つベアメタルノードは、ディスクイメージ全体を使用する必要があります。完全なディスクイメージの詳細は、完全なディスクイメージの作成 を参照してください。~/overcloud-baremetal-deploy.yaml
ファイルを指定し、--output
オプションで出力ファイルを定義して、プロビジョニングコマンドを実行します。(undercloud)$ openstack overcloud node provision \ --stack stack \ --output ~/overcloud-baremetal-deployed.yaml \ ~/overcloud-baremetal-deploy.yaml
プロビジョニングプロセスにより、
--output
オプションで指定する名前の heat 環境ファイルが生成されます。このファイルには、ノード定義が含まれます。オーバークラウドをデプロイする際に、このファイルをデプロイメントコマンドに追加します。別のターミナルでノードをモニタリングし、プロビジョニングが正常に行われていることを確認します。プロビジョニングプロセスでは、ノードの状態が
available
からactive
に変わります。(undercloud)$ watch openstack baremetal node list
metalsmith
ツールを使用して、割り当てや neutron ポートなどを含むノードの統合ビューを取得します。(undercloud)$ metalsmith list
openstack baremetal allocation
コマンドを使用して、ノードのホスト名への関連付けを確認することもできます。(undercloud)$ openstack baremetal allocation list
ノードが正常にプロビジョニングされると、オーバークラウドをデプロイすることができます。詳細は、Configuring a basic overcloud with pre-provisioned nodes を参照してください。
8.4. ベアメタルノードのスケールアップ
既存オーバークラウドのベアメタルノード数を増やすには、~/overcloud-baremetal-deploy.yaml
ファイルのノード数を増やして、オーバークラウドを再デプロイします。
前提条件
- アンダークラウドの正常なインストール。詳しくは、Installing director を参照してください。
- オーバークラウドの正常なデプロイメント。詳細は、Configuring a basic overcloud with pre-provisioned nodes を参照してください。
- イントロスペクション済みで、プロビジョニングおよびデプロイメントに利用可能なベアメタルノード。詳細については、Registering nodes for the overcloud と Creating an inventory of the bare-metal node hardware を参照してください。
手順
source コマンドで
stackrc
アンダークラウド認証情報ファイルを読み込みます。$ source ~/stackrc
ベアメタルノードのプロビジョニングに使用した
~/overcloud-baremetal-deploy.yaml
ファイルを編集し、スケールアップするロールのcount
パラメーターを増やします。たとえば、オーバークラウドに Compute ノードが 3 つある場合に、以下のスニペットを使用して Compute ノード数を 10 に増やします。- name: Controller count: 3 - name: Compute count: 10
instances
パラメーターを使用して、予測可能なノード配置を追加することもできます。使用可能なパラメーターと属性の詳細は、Bare metal node provisioning attributes を参照してください。~/overcloud-baremetal-deploy.yaml
ファイルを指定し、--output
オプションで出力ファイルを定義して、プロビジョニングコマンドを実行します。(undercloud)$ openstack overcloud node provision \ --stack stack \ --output ~/overcloud-baremetal-deployed.yaml \ ~/overcloud-baremetal-deploy.yaml
-
openstack baremetal node list
コマンドを使用して、プロビジョニングの進捗をモニタリングします。 デプロイメントに該当するその他の環境ファイルと共に、プロビジョニングコマンドによって生成される
~/overcloud-baremetal-deployed.yaml
ファイルを指定して、オーバークラウドをデプロイします。(undercloud)$ openstack overcloud deploy \ ... -e /usr/share/openstack-tripleo-heat-templates/environments/deployed-server-environment.yaml \ -e ~/overcloud-baremetal-deployed.yaml \ --deployed-server \ --disable-validations \ ...
8.5. ベアメタルノードのスケールダウン
スタックから削除するノードを ~/overcloud-baremetal-deploy.yaml
ファイルでタグ付けし、オーバークラウドを再デプロイしてから、--baremetal-deployment
オプションを指定して openstack overcloud node delete
コマンドにこのファイルを追加します。
前提条件
- アンダークラウドの正常なインストール。詳細は、4章アンダークラウドへの director のインストール を参照してください。
- オーバークラウドの正常なデプロイメント。詳細は、9章事前にプロビジョニングされたノードを使用した基本的なオーバークラウドの設定 を参照してください。
- スタックから削除する 1 つ以上のベアメタルノード
手順
source コマンドで
stackrc
アンダークラウド認証情報ファイルを読み込みます。$ source ~/stackrc
ベアメタルノードのプロビジョニングに使用した
~/overcloud-baremetal-deploy.yaml
ファイルを編集し、スケールダウンするロールのcount
パラメーターを減らします。また、スタックから削除するノードごとに以下の属性を定義する必要もあります。- ノードの名前
- ノードに関連付けられたホスト名
provisioned: false
属性たとえば、スタックからノード
overcloud-controller-1
を削除するには、~/overcloud-baremetal-deploy.yaml
ファイルに以下のスニペットを追加します。- name: Controller count: 2 instances: - hostname: overcloud-controller-0 name: node00 - hostname: overcloud-controller-1 name: node01 # Removed from cluster due to disk failure provisioned: false - hostname: overcloud-controller-2 name: node02
~/overcloud-baremetal-deploy.yaml
ファイルを指定し、--output
オプションで出力ファイルを定義して、プロビジョニングコマンドを実行します。(undercloud)$ openstack overcloud node provision \ --stack stack \ --output ~/overcloud-baremetal-deployed.yaml \ ~/overcloud-baremetal-deploy.yaml
デプロイメントに該当するその他の環境ファイルと共に、プロビジョニングコマンドによって生成される
~/overcloud-baremetal-deployed.yaml
ファイルを指定して、オーバークラウドを再デプロイします。(undercloud)$ openstack overcloud deploy \ ... -e /usr/share/openstack-tripleo-heat-templates/environments/deployed-server-environment.yaml \ -e ~/overcloud-baremetal-deployed.yaml \ --deployed-server \ --disable-validations \ ...
オーバークラウドの再デプロイ後、
provisioned: false
属性で定義したノードがスタックには存在しなくなります。ただし、これらのノードは provisioned の状態で稼働したままです。注記スタックから一時的にノードを削除する場合は、オーバークラウドを属性
provisioned: false
でデプロイしてから属性provisioned: true
で再デプロイすることで、ノードをスタックに戻すことができます。--baremetal-deployment
オプションで~/overcloud-baremetal-deploy.yaml
ファイルを指定して、openstack overcloud node delete
コマンドを実行します。(undercloud)$ openstack overcloud node delete \ --stack stack \ --baremetal-deployment ~/overcloud-baremetal-deploy.yaml
注記スタックから削除するノードを、
openstack overcloud node delete
コマンドのコマンド引数に含めないでください。
8.6. ベアメタルノードプロビジョニングの属性
以下の表で、openstack baremetal node provision
コマンドでベアメタルノードをプロビジョニングする際に使用できるパラメーター、属性、および値について説明します。
パラメーター | 値 |
---|---|
name | ロール名 (必須) |
count |
このロール用にプロビジョニングするノード数。デフォルト値は |
defaults |
|
instances |
特定のノードの属性を指定するために使用可能な値のディクショナリー。 |
hostname_format |
このロールのデフォルトのホスト名形式を上書きします。デフォルトの形式では、小文字のロール名を使用します。たとえば、Controller ロールのデフォルト形式は、 |
構文の例
以下の例では、name
はノードの論理名を指し、hostname
は、オーバークラウドスタック名、ロール、および増分インデックスから派生して生成されたホスト名を指します。すべての Controller サーバーは、デフォルトのカスタムイメージ overcloud-full-custom
を使用し、予測可能なノード上にあります。Compute サーバーの 1 つは、カスタムホスト名 overcloud-compute-special
の node04
上に予測的に配置され、残りの 99 の Compute サーバーは、使用可能なノードのプールから自動的に割り当てられるノード上にあります。
- name: Controller count: 3 defaults: image: href: file:///var/lib/ironic/images/overcloud-full-custom.qcow2 instances: - hostname: overcloud-controller-0 name: node00 - hostname: overcloud-controller-1 name: node01 - hostname: overcloud-controller-2 name: node02 - name: Compute count: 100 instances: - hostname: overcloud-compute-special name: node04
パラメーター | 値 |
---|---|
hostname |
ホスト名が |
name | プロビジョニングするノードの名前 |
image |
ノードにプロビジョニングするイメージの詳細。 |
capabilities | ノードのケイパビリティーを照合する際の選択基準 |
nics |
要求された NIC を表すディクショナリーのリスト。 |
profile | 高度なプロファイルマッチングを使用する際の選択基準 |
provisioned |
このノードがプロビジョニングされているかどうかを判断するブール値。デフォルト値は |
resource_class |
ノードのリソースクラスを照合する際の選択基準。デフォルト値は |
root_size_gb |
ルートパーティションのサイズ (GiB 単位)。デフォルト値は |
swap_size_mb | スワップパーティションのサイズ (MiB 単位) |
traits | ノード特性を照合する際の選択基準としての特性のリスト |
構文の例
以下の例では、すべての Controller サーバーでカスタムのデフォルトオーバークラウドイメージ overcloud-full-custom
が使用されます。Controller サーバー overcloud-controller-0
は node00
上に予測的に配置され、カスタム設定のルートパーティションおよびスワップパーティションサイズを持ちます。他の 2 つの Controller サーバーは、利用可能なノードのプールから自動的に割り当てられるノード上にあり、デフォルト設定のルートパーティションおよびスワップパーティションサイズを持ちます。
- name: Controller count: 3 defaults: image: href: file:///var/lib/ironic/images/overcloud-full-custom.qcow2 instances: - hostname: overcloud-controller-0 name: node00 root_size_gb: 140 swap_size_mb: 600
パラメーター | 値 |
---|---|
href |
glance イメージの参照、またはルートパーティションもしくは完全なディスクイメージの URL。サポートされる URL スキームは、 |
checksum | href が URL の場合、この値はルートパーティションまたは完全なディスクイメージの SHA512 チェックサムでなければなりません。 |
kernel | glance イメージの参照またはカーネルイメージの URL。パーティションイメージに対してのみ、この属性を使用します。 |
ramdisk | glance イメージの参照または ramdisk イメージの URL。パーティションイメージに対してのみ、この属性を使用します。 |
構文の例
以下の例では、3 つの Controller サーバーは、すべて利用可能なノードのプールから自動的に割り当てられるノード上にあります。この環境の全 Controller サーバーは、デフォルトのカスタムイメージ overcloud-full-custom
を使用します。
- name: Controller count: 3 defaults: image: href: file:///var/lib/ironic/images/overcloud-full-custom.qcow2 checksum: 1582054665 kernel: file:///var/lib/ironic/images/overcloud-full-custom.vmlinuz ramdisk: file:///var/lib/ironic/images/overcloud-full-custom.initrd
パラメーター | 値 |
---|---|
fixed_ip | この NIC に使用する特定の IP アドレス |
network | この NIC のポートを作成する neutron ネットワーク |
subnet | この NIC のポートを作成する neutron サブネット |
port | 新しいポートを作成する代わりに使用する既存の neutron ポート |
構文の例
以下の例では、3 つの Controller サーバーは、すべて利用可能なノードのプールから自動的に割り当てられるノード上にあります。この環境の全 Controller サーバーは、デフォルトのカスタムイメージ overcloud-full-custom
を使用します。また、特定のネットワーク要件を持ちます。
- name: Controller count: 3 defaults: image: href: file:///var/lib/ironic/images/overcloud-full-custom.qcow2 nics: network: custom-network subnet: custom-subnet
第9章 事前にプロビジョニングされたノードを使用した基本的なオーバークラウドの設定
本章では、事前にプロビジョニングされたノードを使用して Red Hat OpenStack Platform (RHOSP) 環境を設定するのに使用できる基本的な設定手順を説明します。以下のシナリオは、標準のオーバークラウド作成のシナリオとはさまざまな点で異なります。
- 外部ツールを使用してノードをプロビジョニングしてから、director でオーバークラウドの設定のみを制御することができます。
- director のプロビジョニングの方法に依存せずにノードを使用することができます。これは、電源管理制御を設定せずにオーバークラウドを作成する場合や、DHCP/PXE ブートの制限があるネットワークを使用する場合に便利です。
- director では、ノードを管理するのに OpenStack Compute (nova)、OpenStack Bare Metal (ironic)、または OpenStack Image (glance) を使用しません。
- 事前にプロビジョニングされたノードでは、QCOW2 overcloud-full イメージに依存しないカスタムパーティションレイアウトを使用することができます。
このシナリオには、カスタム機能を持たない基本的な設定のみが含まれています。ただし、Advanced Overcloud Customization に記載の手順に従って、この基本的なオーバークラウドに高度な設定オプションを追加し、仕様に合わせてカスタマイズすることができます。
事前にプロビジョニングされたノードと director がプロビジョニングしたノードを組み合わせることはできません。
9.1. 事前にプロビジョニングされたノードの要件
事前にプロビジョニングされたノードを使用してオーバークラウドのデプロイメントを開始する前に、以下の項目が環境に存在していること確認してください。
- 4章アンダークラウドへの director のインストール で作成した director ノード
- ノードに使用するベアメタルマシンのセット。必要なノード数は、作成予定のオーバークラウドのタイプにより異なります。これらのマシンは、各ノード種別に設定された要件に従う必要があります。これらのノードには、ホストオペレーティングシステムとして Red Hat Enterprise Linux 8.4 をインストールする必要があります。Red Hat では、利用可能な最新バージョンの使用を推奨します。
- 事前にプロビジョニングされたノードを管理するためのネットワーク接続 1 つ。このシナリオでは、オーケストレーションエージェントの設定のために、ノードへの SSH アクセスが中断されないようにする必要があります。
コントロールプレーンネットワーク用のネットワーク接続 1 つ。このネットワークには、主に 2 つのシナリオがあります。
プロビジョニングネットワークをコントロールプレーンとして使用するデフォルトのシナリオ:このネットワークは通常、事前にプロビジョニングされたノードから director へのレイヤー 3 (L3) を使用したルーティング可能なネットワーク接続です。このシナリオの例では、以下の IP アドレスの割り当てを使用します。
表9.1 プロビジョニングネットワークの 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
のマッピングが含まれないようにします。
9.2. 事前にプロビジョニングされたノードでのユーザーの作成
事前にプロビジョニングされたノードを使用してオーバークラウドを設定する場合、director はオーバークラウドノードに SSH アクセスする必要があります。事前にプロビジョニングされたノードで SSH 鍵認証のユーザーを作成し、そのユーザーに対してパスワード不要の sudo アクセスを設定する必要があります。事前にプロビジョニングされたノードでユーザーを作成したら、openstack overcloud deploy
コマンドで --overcloud-ssh-user
および --overcloud-ssh-key
オプションを使用して、事前にプロビジョニングされたノードでオーバークラウドを作成することができます。
デフォルトでは、オーバークラウドの SSH ユーザーおよびオーバークラウドの SSH 鍵の値は、それぞれ stack
ユーザーおよび ~/.ssh/id_rsa
です。stack
ユーザーを作成するには、以下の手順を実施します。
手順
各オーバークラウドノードで、
stack
ユーザーを作成して、それぞれにパスワードを設定します。Controller ノードで、以下の例に示すコマンドを実行します。[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 鍵を Controller ノードにコピーするには、以下の例に示すコマンドを実行します。[stack@director ~]$ ssh-copy-id stack@192.168.24.2
SSH 鍵をコピーするには、各オーバークラウドノードの SSH 設定で一時的に PasswordAuthentication Yes
を設定しなければならない場合があります。SSH 鍵をコピーした後に PasswordAuthentication No
を設定し、今後は SSH 鍵を使用して認証を行います。
9.3. 事前にプロビジョニングされたノードのオペレーティングシステムの登録
それぞれのノードには、Red Hat サブスクリプションへのアクセスが必要です。ノードを Red Hat コンテンツ配信ネットワークに登録するには、各ノードで以下の手順を実施します。
記載されたリポジトリーのみを有効にします。追加のリポジトリーを使用すると、パッケージとソフトウェアの競合が発生する場合があります。他のリポジトリーは有効にしないでください。
手順
登録コマンドを実行して、プロンプトが表示されたらカスタマーポータルのユーザー名とパスワードを入力します。
[heat-admin@controller-0 ~]$ sudo subscription-manager register
Red Hat OpenStack Platform 16.2 のエンタイトルメントプールを検索します。
[heat-admin@controller-0 ~]$ sudo subscription-manager list --available \ --all --matches="Red Hat OpenStack"
上記のステップで特定したプール ID を使用して、Red Hat OpenStack Platform 16 のエンタイトルメントをアタッチします。
[heat-admin@controller-0 ~]$ sudo subscription-manager attach --pool=pool_id
デフォルトのリポジトリーをすべて無効にします。
[heat-admin@controller-0 ~]$ sudo subscription-manager repos --disable=*
必要な Red Hat Enterprise Linux リポジトリーを有効にします。
x86_64 システムの場合:
[heat-admin@controller-0 ~]$ sudo subscription-manager repos \ --enable=rhel-8-for-x86_64-baseos-eus-rpms \ --enable=rhel-8-for-x86_64-appstream-eus-rpms \ --enable=rhel-8-for-x86_64-highavailability-eus-rpms \ --enable=ansible-2.9-for-rhel-8-x86_64-rpms \ --enable=openstack-16.2-for-rhel-8-x86_64-rpms \ --enable=fast-datapath-for-rhel-8-x86_64-rpms
POWER システムの場合:
[heat-admin@controller-0 ~]$ sudo subscription-manager repos \ --enable=rhel-8-for-ppc64le-baseos-rpms \ --enable=rhel-8-for-ppc64le-appstream-rpms \ --enable=rhel-8-for-ppc64le-highavailability-rpms \ --enable=ansible-2.8-for-rhel-8-ppc64le-rpms \ --enable=openstack-16-for-rhel-8-ppc64le-rpms \ --enable=fast-datapath-for-rhel-8-ppc64le-rpms
container-tools
リポジトリーモジュールをバージョン3.0
に設定します。[heat-admin@controller-0 ~]$ sudo dnf module disable -y container-tools:rhel8 [heat-admin@controller-0 ~]$ sudo dnf module enable -y container-tools:3.0
オーバークラウドで Ceph Storage ノードを使用する場合は、該当する Ceph Storage リポジトリーを有効にします。
[heat-admin@cephstorage-0 ~]$ sudo subscription-manager repos \ --enable=rhel-8-for-x86_64-baseos-rpms \ --enable=rhel-8-for-x86_64-appstream-rpms \ --enable=ansible-2.9-for-rhel-8-x86_64-rpms \ --enable=openstack-16.2-deployment-tools-for-rhel-8-x86_64-rpms
Red Hat Ceph Storage ノードを除くすべてのオーバークラウドノードで RHEL バージョンをロックします。
[heat-admin@controller-0 ~]$ sudo subscription-manager release --set=8.4
システムを更新して、ベースシステムパッケージが最新の状態になるようにします。
[heat-admin@controller-0 ~]$ sudo dnf update -y [heat-admin@controller-0 ~]$ sudo reboot
このノードをオーバークラウドに使用する準備ができました。
9.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 経由でアクセスできるようになります。
9.5. コントロールプレーンのネットワークの設定
事前にプロビジョニングされたオーバークラウドノードは、標準の HTTP 要求を使用して director からメタデータを取得します。これは、オーバークラウドノードでは以下のいずれかに対して L3 アクセスが必要であることを意味します。
-
director のコントロールプレーンネットワーク。これは、
undercloud.conf
ファイルのnetwork_cidr
パラメーターで定義するサブネットです。オーバークラウドノードには、このサブネットへの直接アクセスまたはルーティング可能なアクセスのいずれかが必要です。 -
undercloud.conf
ファイルのundercloud_public_host
パラメーターで指定する director のパブリック API エンドポイント。コントロールプレーンへの L3 ルートがない場合や、SSL/TLS 通信を使用する場合に、このオプションを利用することができます。パブリック API エンドポイントを使用するオーバークラウドノードの設定についての詳細は、「事前にプロビジョニングされたノードへの別ネットワークの使用」を参照してください。
director は、コントロールプレーンネットワークを使用して標準のオーバークラウドを管理、設定します。事前にプロビジョニングされたノードを使用したオーバークラウドの場合には、director と事前にプロビジョニングされたノード間の通信に対応するために、ネットワーク設定を変更しなければならない場合があります。
ネットワーク分離の使用
ネットワーク分離を使用することで、サービスをグループ化してコントロールプレーンなど特定のネットワークを使用することができます。Advanced Overcloud Customization には、ネットワーク分離の設定が複数記載されています。コントロールプレーン上のノードに特定の 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 アドレス設定を実装するために、以下の IP アドレスを割り当てた環境ファイル ctlplane-assignments.yaml
を使用することができます。
resource_registry: OS::TripleO::DeployedServer::ControlPlanePort: /usr/share/openstack-tripleo-heat-templates/deployed-server/deployed-neutron-port.yaml parameter_defaults: DeployedServerPortMap: controller-0-ctlplane: fixed_ips: - ip_address: 192.168.24.2 subnets: - cidr: 192.168.24.0/24 network: tags: 192.168.24.0/24 compute-0-ctlplane: fixed_ips: - ip_address: 192.168.24.3 subnets: - cidr: 192.168.24.0/24 network: tags: - 192.168.24.0/24
この例では、OS::TripleO::DeployedServer::ControlPlanePort
リソースはパラメーターセットを director に渡して、事前にプロビジョニングされたノードの IP 割り当てを定義します。DeployedServerPortMap
パラメーターを使用して、各オーバークラウドノードに対応する IP アドレスおよびサブネット CIDR を定義します。マッピングにより、以下の属性が定義されます。
-
割り当ての名前。形式は
<node_hostname>-<network>
です。ここで、<node_hostname>
の値はノードの短縮ホスト名で、<network>
はネットワークの小文字を使用した名前です。たとえば、controller-0.example.com
であればcontroller-0-ctlplane
となり、compute-0.example.com
の場合はcompute-0-ctlplane
となります。 以下のパラメーターパターンを使用する IP 割り当て
-
fixed_ips/ip_address
: コントロールプレーンの固定 IP アドレスを定義します。複数の IP アドレスを定義する場合には、複数のip_address
パラメーターをリストで指定してください。 -
subnets/cidr
: サブネットの CIDR 値を定義します。
-
本章のこの後のセクションで、作成された環境ファイル (ctlplane-assignments.yaml
) を openstack overcloud deploy
コマンドの一部として使用します。
9.6. 事前にプロビジョニングされたノードへの別ネットワークの使用
デフォルトでは、director はオーバークラウドのコントロールプレーンとしてプロビジョニングネットワークを使用します。ただし、このネットワークが分離されてルーティング不可能な場合には、ノードは設定中に director の Internal API と通信することができません。このような状況では、ノードに別のネットワークを定義して、パブリック API 経由で director と通信するように設定しなければならない場合があります。
このシナリオには、いくつかの要件があります。
- オーバークラウドノードは、「コントロールプレーンのネットワークの設定」からの基本的なネットワーク設定に対応する必要があります。
- パブリック API エンドポイントを使用できるように director 上で SSL/TLS を有効化する必要があります。詳しい情報は、「director の設定パラメーター」 および 20章カスタム SSL/TLS 証明書の設定 を参照してください。
-
director 向けにアクセス可能な完全修飾ドメイン名 (FQDN) を定義する必要があります。この FQDN は、director にルーティング可能な IP アドレスを解決する必要があります。
undercloud.conf
ファイルのundercloud_public_host
パラメーターを使用して、この FQDN を設定します。
本項に記載する例では、主要なシナリオとは異なる 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 の割り当て方法は、「コントロールプレーンのネットワークの設定」に記載の手順と類似しています。ただし、コントロールプレーンはデプロイしたサーバーからルーティング可能ではないので、DeployedServerPortMap
パラメーターを使用して、コントロールプレーンにアクセスする仮想 IP アドレスを含め、選択したオーバークラウドノードのサブネットから IP アドレスを割り当てる必要があります。以下の例は、「コントロールプレーンのネットワークの設定」 からの ctlplane-assignments.yaml
環境ファイルを修正したバージョンで、このネットワークアーキテクチャーに対応します。
resource_registry:
OS::TripleO::DeployedServer::ControlPlanePort: /usr/share/openstack-tripleo-heat-templates/deployed-server/deployed-neutron-port.yaml
OS::TripleO::Network::Ports::ControlPlaneVipPort: /usr/share/openstack-tripleo-heat-templates/deployed-server/deployed-neutron-port.yaml
OS::TripleO::Network::Ports::RedisVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/noop.yaml
OS::TripleO::Network::Ports::OVNDBsVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/noop.yaml 1
parameter_defaults:
NeutronPublicInterface: eth1
DeployedServerPortMap:
control_virtual_ip:
fixed_ips:
- ip_address: 192.168.100.1
subnets:
- cidr: 24
controller-0-ctlplane:
fixed_ips:
- ip_address: 192.168.100.2
subnets:
- cidr: 24
compute-0-ctlplane:
fixed_ips:
- ip_address: 192.168.100.3
subnets:
- cidr: 24
- 1
RedisVipPort
リソースおよびOVNDBsVipPort
リソースは、network/ports/noop.yaml
にマップされます。デフォルトの Redis および OVNDB の VIP アドレスはコントロールプレーンから取得されるため、このマッピングが必要です。このような場合には、noop
を使用して、このコントロールプレーンマッピングを無効化します。
9.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
ファイルを保存します。
9.8. 事前にプロビジョニングされたノード向けの Ceph Storage の設定
すでにデプロイされているノードに ceph-ansible
を設定するには、アンダークラウドホストで以下の手順を実施します。
手順
アンダークラウドホストで環境変数
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 クライアントとして定義したホストを設定します。
9.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/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 や Workflow サービス (mistral) などのどの API サービスにもこの鍵を渡さず、director の openstack overcloud deploy
コマンドだけがこの鍵を使用して tripleo-admin
ユーザーのアクセスを有効化します。
9.10. オーバークラウドデプロイメントの出力
オーバークラウドの作成が完了すると、オーバークラウドを設定するために実施された 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
9.11. オーバークラウドへのアクセス
director は、アンダークラウドからオーバークラウドと対話するための設定を行い、認証をサポートするスクリプトを作成します。director は、このファイル overcloudrc
を stack
ユーザーのホームディレクトリーに保存します。このファイルを使用するには、以下のコマンドを実行します。
(undercloud) $ source ~/overcloudrc
このコマンドにより、アンダークラウド CLI からオーバークラウドと対話するのに必要な環境変数が読み込まれます。コマンドプロンプトが変わり、オーバークラウドと対話していることが示されます。
(overcloud) $
アンダークラウドとの対話に戻るには、以下のコマンドを実行します。
(overcloud) $ source ~/stackrc (undercloud) $
9.12. 事前にプロビジョニングされたノードのスケーリング
事前にプロビジョニングされたノードをスケーリングするプロセスは、16章オーバークラウドノードのスケーリング に記載する標準のスケーリング手順と類似しています。ただし、事前にプロビジョニングされたノードを新たに追加するプロセスは異なります。これは、事前にプロビジョニングされたノードが OpenStack Bare Metal (ironic) および OpenStack Compute (nova) からの標準の登録および管理プロセスを使用しないためです。
事前にプロビジョニングされたノードのスケールアップ
事前にプロビジョニングされたノードでオーバークラウドをスケールアップする際には、各ノードで director のノード数に対応するようにオーケストレーションエージェントを設定する必要があります。
オーバークラウドノードをスケールアップするには、以下の操作を実施します。
- 「事前にプロビジョニングされたノードの要件」の説明に従って、事前にプロビジョニングされたノードを新たに準備します。
- ノードをスケールアップします。詳細は、16章オーバークラウドノードのスケーリング を参照してください。
- デプロイメントコマンドを実行した後に、director が新しいノードリソースを作成して設定を開始するまで待ちます。
事前にプロビジョニングされたノードのスケールダウン
事前にプロビジョニングされたノードを持つオーバークラウドをスケールダウンするには、16章オーバークラウドノードのスケーリング に記載するスケールダウン手順に従います。
スケールダウン操作では、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 のベアメタルサービスがこの機能を制御します。ただし、事前にプロビジョニングされたノードでは、これらのノードを手動でシャットダウンするか、物理システムごとに電源管理制御を使用する必要があります。スタックからノードを削除した後にノードの電源をオフにしないと、稼動状態が続き、オーバークラウド環境の一部として再接続されてしまう可能性があります。
削除したノードの電源をオフにした後に、それらのノードをベースオペレーティングシステムの設定に再プロビジョニングし、意図せずにオーバークラウドに加わらないようにします。
オーバークラウドから以前に削除したノードは、再プロビジョニングしてベースオペレーティングシステムを新規インストールするまでは、再利用しないようにしてください。スケールダウンのプロセスでは、オーバークラウドスタックからノードを削除するだけで、パッケージはアンインストールされません。
事前にプロビジョニングされたオーバークラウドの削除
事前にプロビジョニングされたノードを使用するオーバークラウド全体を削除するには、「オーバークラウドの削除」 で標準のオーバークラウド削除手順を参照してください。オーバークラウドを削除した後に、全ノードの電源をオフにしてからベースオペレーティングシステムの設定に再プロビジョニングします。
オーバークラウドから以前に削除したノードは、再プロビジョニングしてベースオペレーティングシステムを新規インストールするまでは、再利用しないようにしてください。削除のプロセスでは、オーバークラウドスタックを削除するだけで、パッケージはアンインストールされません。
第10章 複数のオーバークラウドのデプロイ
この機能は、本リリースでは テクノロジープレビュー として提供しているため、Red Hat では全面的にはサポートしていません。これは、テスト用途にのみご利用いただく機能です。実稼働環境にはデプロイしないでください。テクノロジープレビュー機能についての詳しい情報は、対象範囲の詳細 を参照してください。
1 つのアンダークラウドノードを使用して、複数のオーバークラウドをデプロイおよび管理することができます。それぞれのオーバークラウドは、スタックリソースを共有しない個別の heat スタックです。この設定は、アンダークラウドとオーバークラウドの比率が 1 : 1 の環境で、無視できない程度のオーバーヘッドが発生する場合に有用です。たとえば、エッジサイト、複数サイト、および複数製品にまたがる環境などです。
複数のオーバークラウドデプロイメントのオーバークラウド環境は完全に分離されており、source
コマンドを使用して環境を切り替えることができます。各オーバークラウドには、デプロイプロセスによって作成される一意の認証情報ファイルがあります。オーバークラウドに関する操作を行うには、source コマンドで適切な認証情報ファイルを読み込む必要があります。
Bare Metal Provisioning サービス (ironic) をベアメタルのプロビジョニングに使用する場合は、すべてのオーバークラウドが同じプロビジョニングネットワーク上にある必要があります。同じプロビジョニングネットワークを使用することができない場合には、デプロイされたサーバー法を使用して、ルーティングされたネットワークで複数のオーバークラウドをデプロイすることができます。このシナリオでは、HostnameMap
パラメーターの値が各オーバークラウドのスタック名と一致している必要があります。
1 つのアンダークラウドに複数のオーバークラウドをデプロイするには、以下のタスクを実行する必要があります。
- アンダークラウドをデプロイします。詳細は、パート I. Director のインストールおよび設定 を参照してください。
- 最初のオーバークラウドをデプロイします。詳細については、パート II基本的なオーバークラウドのデプロイメント を参照してください。
-
新しいオーバークラウド用の環境ファイルの新しいセットを作成し、デプロイコマンドで新しい設定ファイルと新しい
stack
名とともにコア Heat テンプレートを指定することにより、追加のオーバークラウドをデプロイします。
10.1. 追加のオーバークラウドのデプロイ
1 つのアンダークラウドに複数のオーバークラウドをデプロイできます。以下の手順は、既存のオーバークラウド overcloud-one
を持つ既存の Red Hat OpenStack Platform (RHOSP) デプロイメントに新しいオーバークラウド overcloud-two
を作成してデプロイする方法を示しています。
前提条件
- アンダークラウド。
- 1 つ以上のオーバークラウド。
- 追加のオーバークラウドで使用できるノード。
- それぞれのオーバークラウドが作成されるスタックで固有のネットワークを持つように、追加のオーバークラウド用のカスタムネットワーク
手順
-
アンダークラウドホストに
stack
ユーザーとしてログインします。 stackrc
アンダークラウド認証情報ファイルを入手します。$ source ~/stackrc
デプロイする追加のオーバークラウド用に、新たなディレクトリーを作成します。
(undercloud)$ mkdir ~/overcloud-two
network_data.yaml
ファイルを既存のオーバークラウドから追加のオーバークラウド用の新しいディレクトリーにコピーします。(undercloud)$ cp network_data.yaml ~/overcloud-two/network_data.yaml
~/overcloud-two/network_data.yaml
ファイルを開き、name_lower
を追加のオーバークラウドネットワークの一意の名前に更新します。- name: InternalApi name_lower: internal_api_cloud_2 ...
まだ存在しない場合は
service_net_map_replace
を追加し、値を追加のオーバークラウドネットワークのデフォルト値に設定します。- name: InternalApi name_lower: internal_api_cloud_2 service_net_map_replace: internal_api
追加のオーバークラウドの各サブネットに VLAN ID を指定します。
- name: InternalApi ... vip: true vlan: 21 ip_subnet: '172.21.0.0/24' allocation_pools: [{'start': '172.21.0.4', 'end': '172.21.0.250'}] ipv6_subnet: 'fd00:fd00:fd00:2001::/64' ipv6_allocation_pools: [{'start': 'fd00:fd00:fd00:2001::10', 'end': 'fd00:fd00:fd00:2001:ffff:ffff:ffff:fffe'}] mtu: 1500 - name: Storage ...
overcloud-two
外部ネットワークのゲートウェイの IP アドレスを指定します。- name: External ... gateway_ip: <ip_address> ...
-
<ip_address>
をovercloud-two
外部ネットワークのゲートウェイの IP アドレス (例:10.0.10.1
) に置き換えます。
-
-
/usr/share/openstack-tripleo-heat-templates/environments/network-environment.yaml
ファイル (例:network_overrides.yaml
) で提供されるデフォルトの隔離されたネットワーク設定をオーバーライドする、追加のオーバークラウド用のネットワーク設定ファイルを作成します。 ~/overcloud-two/network_overrides.yaml
ファイルを開き、overcloud-two
DNS サーバーの IP アドレスを追加します。parameter_defaults: ... DnsServers: - <ip_address> ...
-
<ip_address>
をovercloud-two
DNS サーバーの IP アドレス (例:10.0.10.2
) に置き換えます。
-
デプロイメントで予測可能な IP アドレスを使用する場合は、新しいネットワーク IP アドレスマッピングファイル
ips-from-pool-overcloud-two.yaml
でovercloud-two
ノードの IP アドレスを設定します。parameter_defaults: ControllerIPs: ... internal_api_cloud_2: - 192.168.1.10 - 192.168.1.11 - 192.168.1.12 ... external_cloud_2: - 10.0.1.41 ...
overcloud-two
環境ファイルを他の環境ファイルと一緒にスタックに追加し、追加のオーバークラウドをデプロイします。(undercloud)$ openstack overcloud deploy --templates \ --stack overcloud-two \ -n ~/overcloud-two/network_data.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/network-environment.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/net-single-nic-with-vlans.yaml \ -e ~/overcloud-two/network_overrides.yaml \ -e [your environment files] \ ...
デプロイメントプロセスにより、
overcloud-two
とやり取りして管理するためのovercloud-tworc
が作成されます。追加のオーバークラウドと対話するには、オーバークラウド認証情報ファイルを入手します。
$ source overcloud-tworc
10.2. 複数のオーバークラウドの管理
デプロイするそれぞれのオーバークラウドでは、同じコア heat テンプレートセット /usr/share/openstack-tripleo-heat-templates
が使用されます。非標準のコアテンプレートセットを使用すると、更新およびアップグレード時に問題が発生する可能性があるので、Red Hat では、これらのテンプレートを変更したり複製したりしないことを推奨します。
その代わりに、複数のオーバークラウドをデプロイまたは維持する際の管理を容易にするため、各クラウドに固有の環境ファイル用ディレクトリーを個別に作成します。各クラウドのデプロイコマンドを実行する際に、コア heat テンプレートと共に個別に作成したクラウド固有の環境ファイルを含めます。たとえば、アンダークラウドおよび 2 つのオーバークラウド用に以下のディレクトリーを作成します。
~stack/undercloud
- アンダークラウドに固有の環境ファイルを保管します。
~stack/overcloud-one
- 最初のオーバークラウドに固有の環境ファイルを保管します。
~stack/overcloud-two
- 2 番目のオーバークラウドに固有の環境ファイルを保管します。
overcloud-one
または overcloud-two
をデプロイまたは再デプロイする場合には、--templates
オプションでデプロイコマンドにコア heat テンプレートを追加し、続いてクラウド固有の環境ファイルディレクトリーからの追加環境ファイルをすべて指定します。
あるいは、バージョン管理システムにリポジトリーを作成し、デプロイメントごとにブランチを使用します。詳しくは、Advanced Overcloud Customization guideの Using Customized Core Heat Templates セクションを参照してください。
利用可能なオーバークラウドプランのリストを表示するには、以下のコマンドを使用します。
$ openstack overcloud plan list
現在デプロイされているオーバークラウドのリストを表示するには、以下のコマンドを使用します。
$ openstack stack list
第11章 オーバークラウドのインストール後タスクの実施
本章では、オーバークラウドを作成したすぐ後に実施するタスクについて説明します。これらのタスクにより、オーバークラウドを使用可能な状態にすることができます。
11.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 | +-----------+---------------------+---------------------+-------------------+
実際のオーバークラウドに別の名前が使用されている場合には、
--plan
引数を使用してその名前のオーバークラウドを選択します。$ openstack overcloud status --plan my-deployment
11.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
で確認してください。
11.3. デフォルトのテナントネットワークの作成
仮想マシンが内部で通信できるように、オーバークラウドにはデフォルトの 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 アドレスを自動的に割り当てます。
11.4. デフォルトの Floating IP ネットワークの作成
オーバークラウドの外部から仮想マシンにアクセスするためには、仮想マシンに Floating IP アドレスを提供する外部ネットワークを設定する必要があります。
ここでは、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
この範囲が、外部ネットワークの他の IP アドレスと競合しないようにしてください。
11.5. デフォルトのプロバイダーネットワークの作成
プロバイダーネットワークは別の種別の外部ネットワーク接続で、トラフィックをプライベートテナントネットワークから 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
を使用する仮想マシンからのトラフィックをプロバイダーネットワークにルーティングできるようになります。
11.6. 新たなブリッジマッピングの作成
デプロイメント時に追加のブリッジをマッピングすれば、Floating IP ネットワークは br-ex
だけでなく任意のブリッジを使用することができます。
たとえば、br-floating
という新規ブリッジを floating
という物理ネットワークにマッピングするには、環境ファイルに NeutronBridgeMappings
パラメーターを追加します。
parameter_defaults: NeutronBridgeMappings: "datacentre:br-ex,floating:br-floating"
この手法により、オーバークラウドの作成後に独立した外部ネットワークを作成することができます。たとえば、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
11.7. オーバークラウドの検証
オーバークラウドは、OpenStack Integration Test Suite (tempest) ツールセットを使用して、一連の統合テストを行います。本項では、統合テストを実施するための準備について説明します。OpenStack Integration Test Suite の使用方法についての詳しい説明は、OpenStack Integration Test Suite Guide を参照してください。
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
11.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
この環境ファイルにより、オーバークラウド内のスタックを削除することができなくなります。したがって、以下の操作を実施することはできません。
- オーバークラウドの削除
- 個々の Compute ノードまたは Ceph Storage ノードの削除
- Controller ノードの置き換え
スタックの削除を有効にするには、custom_env_files
パラメーターから prevent-stack-delete.yaml
ファイルを削除し、openstack undercloud install
コマンドを実行します。
第12章 基本的なオーバークラウド管理タスクの実施
本章では、オーバークラウドのライフサイクル期間中に実行しなければならない可能性がある、基本的なタスクについて説明します。
12.1. SSH を使用したオーバークラウドノードへのアクセス
SSH プロトコルを使用して、各オーバークラウドノードにアクセスすることができます。
-
各オーバークラウドノードには
heat-admin
ユーザーが含まれます。 -
アンダークラウドの
stack
ユーザーは、各オーバークラウドノードのheat-admin
ユーザーに鍵ベースの SSH アクセスを行うことができます。 -
すべてのオーバークラウドノードは短縮ホスト名を持ち、アンダークラウドはこのホスト名をコントロールプレーンネットワーク上の IP アドレスに解決します。それぞれの短縮ホスト名には、
.ctlplane
接尾辞が使用されます。たとえば、overcloud-controller-0
の短縮名はovercloud-controller-0.ctlplane
です。
前提条件
- 稼動状態にあるコントロールプレーンネットワークと共にデプロイされたオーバークラウド
手順
-
アンダークラウドに
stack
ユーザーとしてログインします。 source コマンドで
overcloudrc
ファイルを読み込みます。$ source ~/stackrc
アクセスするノードの名前を確認します。
(undercloud) $ openstack server list
ノードに
heat-admin
ユーザーとして接続し、ノードの短縮ホスト名を使用します。(undercloud) $ ssh heat-admin@overcloud-controller-0.ctlplane
12.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 およびそのデーモンで管理されていました。OpenStack Platform 16 では、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:33 UTC 4s left Mon 2019-02-18 20:17:03 UTC 1min 25s ago tripleo_mistral_engine_healthcheck.timer tripleo_mistral_engine_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
コマンドは、コンテナーのヘルスステータスを表示しません。
コンテナーログの確認
OpenStack Platform 16 では、新たなロギングディレクトリー /var/log/containers/stdout
が導入されています。ここには、すべてのコンテナーの標準出力 (stdout) と標準エラー (stderr) が、コンテナーごとに 1 つのファイルに統合されて保存されます。
paunch および container-puppet.py
スクリプトは、出力を /var/log/containers/stdout
ディレクトリーにプッシュするように podman コンテナーを設定します。これにより、container-puppet-*
コンテナー等の削除されたコンテナーを含め、すべてのログのコレクションが作成されます。
また、ホストはこのディレクトリーにログローテーションを適用し、大きな容量のファイルがディスク容量を消費する問題を防ぎます。
コンテナーが置き換えられた場合には、新しいコンテナーは同じログファイルにログを出力します。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
12.3. オーバークラウド環境の変更
オーバークラウドを変更して、新たな機能を追加したり、既存の操作を変更したりすることができます。オーバークラウドを変更するには、カスタムの環境ファイルと heat テンプレートに変更を加えて、最初に作成したオーバークラウドから openstack overcloud deploy
コマンドをもう 1 度実行します。たとえば、「デプロイメントコマンド」に記載の手順を使用してオーバークラウドを作成した場合には、以下のコマンドを再度実行します。
$ source ~/stackrc (undercloud) $ openstack overcloud deploy --templates \ -e ~/templates/node-info.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.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 /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \ -e ~/templates/network-environment.yaml \ -e ~/templates/storage-environment.yaml \ -e ~/templates/node-info.yaml \ --ntp-server pool.ntp.org
このコマンドにより、環境ファイルからの新規パラメーターやリソースがスタックに追加されます。
オーバークラウドの設定に手動で変更を加えることは推奨されません。director によりこれらの変更が後で上書きされてしまう可能性があるためです。
12.4. オーバークラウドへの仮想マシンのインポート
既存の OpenStack 環境からご自分の Red Hat OpenStack Platform (RHOSP) 環境に仮想マシンを移行することができます。
手順
既存の OpenStack 環境において、実行中のサーバーのスナップショットを作成して新規イメージを作成し、そのイメージをダウンロードします。
$ openstack server image create instance_name --name image_name $ openstack image save image_name --file exported_vm.qcow2
エクスポートしたイメージをアンダークラウドノードにコピーします。
$ scp exported_vm.qcow2 stack@192.168.0.2:~/.
-
アンダークラウドに
stack
ユーザーとしてログインします。 source コマンドで
overcloudrc
ファイルを読み込みます。$ source ~/overcloudrc
エクスポートしたイメージをオーバークラウドにアップロードします。
(overcloud) $ openstack image create imported_image --file exported_vm.qcow2 --disk-format qcow2 --container-format bare
新規インスタンスを起動します。
(overcloud) $ openstack server create imported_instance --key-name default --flavor m1.demo --image imported_image --nic net-id=net_id
これらのコマンドにより、各仮想マシンのディスクが既存の OpenStack 環境から新たな Red Hat OpenStack Platform にコピーされます。QCOW スナップショットでは、元の階層化システムが失われます。
このプロファイルにより、Compute ノードからすべてのインスタンスが移行されます。インスタンスのダウンタイムなしにノードでメンテナンスを実行できるようになります。Compute ノードを有効な状態に戻すには、以下のコマンドを実行します。
$ source ~/overcloudrc (overcloud) $ openstack compute service set [hostname] nova-compute --enable
12.5. 動的インベントリースクリプトの実行
director を使用すると、Ansible ベースの自動化をご自分の Red Hat OpenStack Platform (RHOSP) 環境で実行することができます。director は、tripleo-ansible-inventory
コマンドを使用して、環境内にノードの動的インベントリーを生成します。
手順
ノードの動的インベントリーを表示するには、
stackrc
を読み込んだ後にtripleo-ansible-inventory
コマンドを実行します。$ source ~/stackrc (undercloud) $ tripleo-ansible-inventory --list
--list
オプションを使用すると、全ホストの詳細が返されます。このコマンドにより、動的インベントリーが JSON 形式で出力されます。{"overcloud": {"children": ["controller", "compute"], "vars": {"ansible_ssh_user": "heat-admin"}}, "controller": ["192.168.24.2"], "undercloud": {"hosts": ["localhost"], "vars": {"overcloud_horizon_url": "http://192.168.24.4:80/dashboard", "overcloud_admin_password": "abcdefghijklm12345678", "ansible_connection": "local"}}, "compute": ["192.168.24.3"]}
お使いの環境で Ansible のPlaybookを実行するには、
ansible
コマンドを実行し、-i
オプションを使用して動的インベントリーツールの完全パスを追加します。以下に例を示します。(undercloud) $ ansible [HOSTS] -i /bin/tripleo-ansible-inventory [OTHER OPTIONS]
[HOSTS]
を使用するホストの種別に置き換えてください。-
全 Controller ノードの場合には
controller
-
全 Compute ノードの場合には
compute
-
オーバークラウドの全子ノードの場合には
overcloud
(たとえば、controller
ノードおよびcompute
ノードの場合) -
アンダークラウドの場合には
undercloud
-
全ノードの場合には
"*"
-
全 Controller ノードの場合には
[OTHER 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 ベースの設定を上書きする可能性があります。
12.6. オーバークラウドの削除
オーバークラウドを削除するには、openstack overcloud delete
コマンドを実行します。
手順
既存のオーバークラウドを削除します。
$ source ~/stackrc (undercloud) $ openstack overcloud delete overcloud
openstack stack list
コマンドの出力にオーバークラウドが表示されなくなったことを確認します。(undercloud) $ openstack stack list
削除には、数分かかります。
- 削除が完了したら、デプロイメントシナリオの標準ステップに従って、オーバークラウドを再度作成します。
第13章 Ansible を使用したオーバークラウドの設定
Ansible は、オーバークラウドの設定を適用する主要な方法です。本章では、オーバークラウドの Ansible 設定を操作する方法について説明します。
director は Ansible Playbook を自動生成しますが、Ansible の構文を十分に理解しておくと役立ちます。Ansible の使用についての詳細は、Ansible のドキュメント を参照してください。
Ansible でもロールの概念を使用します。これは、OpenStack Platform director のロールとは異なります。Ansible のロール は再利用可能な Playbook のコンポーネントを形成しますが、director のロールには OpenStack サービスのノード種別へのマッピングが含まれます。
13.1. Ansible ベースのオーバークラウド設定 (config-download)
director は、config-download
機能を使用してオーバークラウドを設定します。director は、OpenStack Orchestration サービス (heat) および OpenStack Workflow サービス (mistral) と共に config-download
を使用してソフトウェア設定を生成し、その設定を各オーバークラウドノードに適用します。heat は SoftwareDeployment
リソースから全デプロイメントデータを作成して、オーバークラウドのインストールと設定を行いますが、設定の適用は一切行いません。heat は、heat API から設定データの提供のみを行います。director がスタックを作成する場合には、mistral ワークフローが heat API に対して設定データ取得のクエリーを実行し、Ansible Playbook のセットを生成してオーバークラウドに適用します。
結果として、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 を適用します。
13.2. config-download の作業ディレクトリー
director により、config-download
プロセス用に Ansible Playbook のセットが生成されます。これらの Playbook は /var/lib/mistral/
内の作業ディレクトリーに保管されます。このディレクトリーには、オーバークラウドの名前が付けられます。したがって、デフォルトでは overcloud
です。
作業ディレクトリーには、各オーバークラウドロールの名前が付けられた複数のサブディレクトリーが存在します。これらのサブディレクトリーには、オーバークラウドロールのノードの設定に関連するすべてのタスクが含まれます。さらに、これらのサブディレクトリーには、特定のノードの名前が付けられたサブディレクトリーが存在します。これらのサブディレクトリーには、オーバークラウドロールのタスクに適用するノード固有の変数が含まれます。したがって、作業ディレクトリー内のオーバークラウドロールは、以下のような設定になります。
─ /var/lib/mistral/overcloud | ├── Controller │ ├── overcloud-controller-0 | ├── overcloud-controller-1 │ └── overcloud-controller-2 ├── Compute │ ├── overcloud-compute-0 | ├── overcloud-compute-1 │ └── overcloud-compute-2 ...
それぞれの作業ディレクトリーは、各デプロイメント操作後の変更を記録するローカルの Git リポジトリーです。ローカル Git リポジトリーを使用して、各デプロイメント間の設定変更を追跡します。
13.3. config-download の作業ディレクトリーへのアクセスの有効化
/var/lib/mistral/
にある作業ディレクトリー内の全ファイルの所有者は、OpenStack Workflow サービス (mistral) コンテナーの mistral
ユーザーです。アンダークラウドの stack
ユーザーに、このディレクトリー内の全ファイルへのアクセス権限を付与することができます。この設定は、ディレクトリー内の特定操作を実施するのに役立ちます。
手順
アンダークラウドの
stack
ユーザーに/var/lib/mistral
ディレクトリーのファイルへのアクセス権限を付与するには、setfacl
コマンドを使用します。$ sudo setfacl -R -m u:stack:rwx /var/lib/mistral $ sudo chmod -R og-rwx /var/lib/mistral/.ssh
このコマンドを実行しても、
mistral
ユーザーのディレクトリーへのアクセス権限は維持されます。
13.4. config-download ログの確認
config-download
プロセス中、Ansible によりアンダークラウド内の config-download
の作業ディレクトリーにログファイルが作成されます。
手順
less
コマンドを使用して、config-download
の作業ディレクトリー内のログを表示します。以下の例では、overcloud
作業ディレクトリーが使われています。$ less /var/lib/mistral/overcloud/ansible.log
13.5. 作業ディレクトリーでの Git 操作の実施
config-download
の作業ディレクトリーは、ローカルの Git リポジトリーです。デプロイメント操作を実行するたびに、director は該当する変更に関する Git コミットを作業ディレクトリーに追加します。Git 操作を実施して、さまざまなステージでのデプロイメント設定を表示したり、異なるデプロイメント間で設定を比較したりすることができます。
作業ディレクトリーには制限がある点に注意してください。たとえば、Git を使用して config-download
の作業ディレクトリーを前のバージョンに戻しても、この操作は作業ディレクトリー内の設定にしか影響を及ぼしません。したがって、以下の設定は影響を受けません。
- オーバークラウドデータスキーマ: 作業ディレクトリーのソフトウェア設定の前のバージョンを適用しても、データ移行およびスキーマ変更は取り消されません。
- オーバークラウドのハードウェアレイアウト: 以前のソフトウェア設定に戻しても、スケールアップ/ダウン等のオーバークラウドハードウェアに関する変更は取り消されません。
-
heat スタック: 作業ディレクトリーを前のバージョンに戻しても、heat スタックに保管された設定は影響を受けません。heat スタックは新たなバージョンのソフトウェア設定を作成し、それがオーバークラウドに適用されます。オーバークラウドに永続的な変更を加えるには、
openstack overcloud deploy
コマンドを再度実行する前に、オーバークラウドスタックに適用する環境ファイルを変更します。
config-download
の作業ディレクトリー内の異なるコミットを比較するには、以下の手順を実施します。
手順
オーバークラウドに関する
config-download
の作業ディレクトリーに移動します。この例の作業ディレクトリーは、overcloud
という名前のオーバークラウド用です。$ cd /var/lib/mistral/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
13.6. 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
コマンドを実行します。
13.7. 標準デプロイメントでの 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 は /var/lib/mistral/
の作業ディレクトリーに config-download
ファイルを生成します。デプロイメントプロセスが終了したら、作業ディレクトリーの Ansible Playbooks を表示して、オーバークラウドを設定するために director が実行したタスクを確認します。
13.8. プロビジョニングと設定を分離した 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 は /var/lib/mistral/
の作業ディレクトリーに config-download
ファイルを生成します。デプロイメントプロセスが終了したら、作業ディレクトリーの Ansible Playbooks を表示して、オーバークラウドを設定するために director が実行したタスクを確認します。
13.9. ansible-playbook-command.sh スクリプトを使用した config-download の実行
標準の方式または個別のプロビジョニングおよび設定プロセスを使用してオーバークラウドをデプロイすると、director は /var/lib/mistral/
に作業ディレクトリーを生成します。このディレクトリーには、設定プロセスを再度実行するのに必要な Playbook およびスクリプトが含まれています。
前提条件
以下の方式のいずれかでデプロイされたオーバークラウド
- プロビジョニングプロセスと設定プロセスをまとめて実施する標準の方式
- プロビジョニングプロセスと設定プロセスを分離する方式
手順
-
アンダークラウドホストに
stack
ユーザーとしてログインします。 Ansible Playbook のディレクトリーに移動します。
$ cd /var/lib/mistral/overcloud/
/var/lib/mistral/.ssh
ディレクトリーの所有者をstack
ユーザーに変更します。$ sudo chown stack. -R /var/lib/mistral/.ssh/
ansible-playbook-command.sh
コマンドを実行して、オーバークラウドの設定を実行します。$ sudo ./ansible-playbook-command.sh
/var/lib/mistral/.ssh
ディレクトリーの所有者をmistral
ユーザーに変更します。これは、mistral_executor
コンテナー内で実行されている ansible-playbook コマンドが正常に実行されるようにするために必要です。$ sudo chown 42430:42430 -R /var/lib/mistral/.ssh/
mistral
ユーザーとしてスクリプトを再実行します。このスクリプトには追加の Ansible 引数を渡すことができ、それらの引数は、そのまま
ansible-playbook
コマンドに渡されます。つまり、チェックモード (--check
)、ホストの限定 (--limit
)、変数のオーバーライド (-e
) など、他の Ansible 機能を使用することができます。以下に例を示します。$ ./ansible-playbook-command.sh --limit Controller
警告--limit
を使用して大規模にデプロイする場合、実行に含まれるホストのみがノード全体の SSHknown_hosts
ファイルに追加されます。したがって、ライブマイグレーションなどの一部の操作は、known_hosts
ファイルにないノード間では機能しない場合があります。注記すべてのノードで
/etc/hosts
ファイルが最新であることを確認するには、root
ユーザーとして次のコマンドを実行します。(undercloud)$ sudo -i (undercloud)$ cd /var/lib/mistral/overcloud (undercloud)$ ANSIBLE_REMOTE_USER="tripleo-admin" ansible allovercloud \ -i 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-download
Playbook を実行すると、それぞれのホストの SSH フィンガープリントに関するメッセージが表示される場合があります。これらのメッセージを回避するには、ansible-playbook-command.sh
スクリプトの実行時に、--ssh-common-args="-o StrictHostKeyChecking=no"
を追加します。$ ./ansible-playbook-command.sh --tags overcloud --ssh-common-args="-o StrictHostKeyChecking=no"
13.10. 手動で作成した 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 config download \ --name overcloud \ --config-dir ~/config-download
-
--name
は、Ansible ファイルのエクスポートに使用するオーバークラウドの名前です。 -
--config-dir
は、config-download
ファイルを保存する場所です。
-
config-download
ファイルが含まれるディレクトリーに移動します。$ cd ~/config-download
静的なインベントリーファイルを生成します。
$ tripleo-ansible-inventory \ --stack <overcloud> \ --ansible_ssh_user heat-admin \ --static-yaml-inventory inventory.yaml
-
<overcloud>
を実際のオーバークラウドの名前に置き換えてください。
-
config-download
ファイルおよび静的なインベントリーファイルを使用して、設定を実施します。デプロイメント用の Playbook を実行するには、ansible-playbook
コマンドを実行します。$ ansible-playbook \ -i inventory.yaml \ -e gather_facts=true \ -e @global_vars.yaml \ --private-key ~/.ssh/id_rsa \ --become \ ~/config-download/deploy_steps_playbook.yaml
- 設定プロセスが完了するまで待ちます。
この設定から手動で
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>
を実際のオーバークラウドの名前に置き換えてください。
-
関連情報
config-download
ディレクトリーには、オーバークラウドの設定を実行するdeploy_steps_playbook.yaml
という名前の Playbook が含まれています。この Playbook を表示するには、以下のコマンドを実行します。$ less deploy_steps_playbook.yaml
Playbook は、作業ディレクトリーに含まれているさまざまなタスクファイルを使用します。タスクファイルには、OpenStack Platform の全ロールに共通するものと、特定の OpenStack Platform ロールおよびサーバー固有のものがあります。
config-download
ディレクトリーには、オーバークラウドの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 \ -i inventory.yaml \ -e gather_facts=true \ -e @global_vars.yaml \ --private-key ~/.ssh/id_rsa \ --become \ --tags overcloud \ ~/config-download/deploy_steps_playbook.yaml
オーバークラウドに対して
config-download
Playbook を実行すると、それぞれのホストの 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 \ ~/config-download/deploy_steps_playbook.yaml
13.11. 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 を超える値を設定しないでください。
13.12. 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 使用します。
13.13. 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
- アンダークラウドでのみ実行される外部デプロイメントタスク
13.14. 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
、および paunch (コンテナー設定) が含まれます。タグ:
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
第14章 Ansible を使用したコンテナーの管理
この機能は、本リリースでは テクノロジープレビュー として提供しているため、Red Hat では全面的にはサポートしていません。これは、テスト用途にのみご利用いただく機能です。実稼働環境にはデプロイしないでください。テクノロジープレビュー機能についての詳しい情報は、対象範囲の詳細 を参照してください。
Red Hat OpenStack Platform 16.2 では、Paunch を使用してコンテナーを管理します。ただし、Ansible ロール tripleo-container-manage
を使用してコンテナーの管理操作を実施することもできます。tripleo-container-manage
ロールを使用する場合は、初めに Paunch を無効にする必要があります。Paunch が無効になっていると、director は自動的に Ansible ロールを使用します。カスタム Playbook を作成して、特定のコンテナー管理操作を実施することもできます。
-
heat が生成するコンテナー設定データを収集する。
tripleo-container-manage
ロールは、このデータを使用してコンテナーのデプロイメントをオーケストレーションします。 - コンテナーを起動する。
- コンテナーを停止する。
- コンテナーを更新する。
- コンテナーを削除する。
- 特定の設定でコンテナーを実行する。
director はコンテナー管理を自動的に実施しますが、コンテナー設定をカスタマイズしなければならない場合や、オーバークラウドを再デプロイせずにコンテナーにホットフィックスを適用しなければならない場合があります。
このロールがサポートするのは Podman コンテナー管理だけです。
前提条件
- アンダークラウドの正常なインストール。詳細は、「director のインストール」 を参照してください。
14.1. アンダークラウドでの tripleo-container-manage Ansible ロールの有効化
この機能は、本リリースでは テクノロジープレビュー として提供しているため、Red Hat では全面的にはサポートしていません。これは、テスト用途にのみご利用いただく機能です。実稼働環境にはデプロイしないでください。テクノロジープレビュー機能についての詳しい情報は、対象範囲の詳細 を参照してください。
Red Hat OpenStack Platform 16.2 では、Paunch がデフォルトのコンテナー管理メカニズムです。ただし、tripleo-container-manage
Ansible ロールを使用することもできます。このロールを使用する場合は、Paunch を無効にする必要があります。
前提条件
-
ベースオペレーティングシステムおよび
python3-tripleoclient
パッケージがインストールされたホストマシン。詳細は、3章director インストールの準備 を参照してください。
手順
-
アンダークラウドホストに
stack
ユーザーとしてログインします。 undercloud.conf
ファイルでundercloud_enable_paunch
パラメーターをfalse
に設定します。undercloud_enable_paunch: false
openstack undercloud install
コマンドを実行します。$ openstack undercloud install
14.2. オーバークラウドでの tripleo-container-manage Ansible ロールの有効化
この機能は、本リリースでは テクノロジープレビュー として提供しているため、Red Hat では全面的にはサポートしていません。これは、テスト用途にのみご利用いただく機能です。実稼働環境にはデプロイしないでください。テクノロジープレビュー機能についての詳しい情報は、対象範囲の詳細 を参照してください。
Red Hat OpenStack Platform 16.2 では、Paunch がデフォルトのコンテナー管理メカニズムです。ただし、tripleo-container-manage
Ansible ロールを使用することもできます。このロールを使用する場合は、Paunch を無効にする必要があります。
前提条件
- アンダークラウドの正常なインストール。詳細は、4章アンダークラウドへの director のインストール を参照してください。
手順
-
アンダークラウドホストに
stack
ユーザーとしてログインします。 source コマンドで
stackrc
認証情報ファイルを読み込みます。$ source ~/stackrc
デプロイメントに該当するその他の環境ファイルと共に、オーバークラウドデプロイメントコマンドに
/usr/share/openstack-tripleo-heat-templates/environments/disable-paunch.yaml
ファイルを追加します。(undercloud) [stack@director ~]$ openstack overcloud deploy --templates \ -e /usr/share/openstack-tripleo-heat-templates/environments/disable-paunch.yaml -e <other_environment_files> ...
14.3. 単一コンテナーでの操作の実施
この機能は、本リリースでは テクノロジープレビュー として提供しているため、Red Hat では全面的にはサポートしていません。これは、テスト用途にのみご利用いただく機能です。実稼働環境にはデプロイしないでください。テクノロジープレビュー機能についての詳しい情報は、対象範囲の詳細 を参照してください。
tripleo-container-manage
ロールを使用して、すべてのコンテナーまたは特定のコンテナーを管理することができます。特定のコンテナーを管理する場合は、特定のコンテナーをカスタム Ansible Playbook の対象にできるように、コンテナーデプロイメントステップおよびコンテナー設定 JSON ファイルの名前を特定する必要があります。
前提条件
- アンダークラウドの正常なインストール。詳細は、4章アンダークラウドへの director のインストール を参照してください。
手順
-
アンダークラウドに
stack
ユーザーとしてログインします。 source コマンドで
overcloudrc
認証情報ファイルを読み込みます。$ source ~/overcloudrc
-
コンテナーデプロイメントステップを特定します。各ステップのコンテナー設定は、
/var/lib/tripleo-config/container-startup-config/step_{1,2,3,4,5,6}
ディレクトリーに保存されています。 -
コンテナーの JSON 設定ファイルを特定します。コンテナー設定ファイルは、該当する
step_*
ディレクトリーに保存されています。たとえば、ステップ 1 の HAProxy コンテナーの設定ファイルは、/var/lib/tripleo-config/container-startup-config/step_1/haproxy.json
です。 適切な Ansible Playbook を作成します。たとえば、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_systemd_order: true 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_config_overrides: haproxy: image: registry.redhat.io/tripleomaster/<HAProxy-container>:hotfix
tripleo-container-manage
ロールで使用することのできる変数についての詳細は、「tripleo-container-manage ロールの変数」 を参照してください。Playbook を実行します。
(overcloud) [stack@director]$ ansible-playbook <custom_playbook>.yaml
変更を適用せずに Playbook を実行する場合は、
ansible-playbook
コマンドに--check
オプションを追加します。(overcloud) [stack@director]$ ansible-playbook <custom_playbook>.yaml --check
変更を適用せずに Playbook がコンテナーに加える変更を把握する場合は、
ansible-playbook
コマンドに--check
および--diff
オプションを追加します。(overcloud) [stack@director]$ ansible-playbook <custom_playbook>.yaml --check --diff
14.4. tripleo-container-manage ロールの変数
この機能は、本リリースでは テクノロジープレビュー として提供しているため、Red Hat では全面的にはサポートしていません。これは、テスト用途にのみご利用いただく機能です。実稼働環境にはデプロイしないでください。テクノロジープレビュー機能についての詳しい情報は、対象範囲の詳細 を参照してください。
tripleo-container-manage
Ansible ロールには、以下の変数が含まれます。
名前 | デフォルト値 | 説明 |
---|---|---|
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 のコンテナーを管理するには、この値を |