8.6. オーバークラウドノードに別のネットワークを使用する方法
デフォルトでは、director はオーバークラウドのコントロールプレーンとしてプロビジョニングネットワークを使用します。ただし、このネットワークが分離されてルーティング不可能な場合には、ノードは設定中に director の内部 API と通信することができません。このような状況では、ノードに別のネットワークを定義して、パブリック API 経由で director と通信するように設定しなければならない場合があります。
このシナリオには、いくつかの要件があります。
- オーバークラウドノードは、「コントロールプレーンのネットワークの設定」からの基本的なネットワーク設定に対応する必要があります。
- パブリック API エンドポイントを使用できるように director 上で SSL/TLS を有効化する必要があります。詳しい情報は、「director の設定パラメーター」と付録A SSL/TLS 証明書の設定を参照してください。
-
director 向けにアクセス可能な完全修飾ドメイン名 (FQDN) を定義する必要があります。この FQDN は、director にルーティング可能な IP アドレスを解決する必要があります。
undercloud.conf
ファイルのundercloud_public_host
パラメーターを使用して、この FQDN を設定します。
本項に記載する例では、主要なシナリオとは異なる IP アドレスの割り当てを使用します。
ノード名 | IP アドレスまたは FQDN |
---|---|
director (内部 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 |
以下の項では、オーバークラウドノードに別のネットワークが必要な場合の追加の設定について説明します。
オーケストレーションの設定
アンダークラウドの SSL/TLS 通信を有効化している場合には、director は、大半のサービスにパブリック API エンドポイントを提供します。ただし、OpenStack Orchestration (heat) は、メタデータのデフォルトのプロバイダーとして内部エンドポイントを使用します。そのため、オーバークラウドノードがパブリックエンドポイントの OpenStack Orchestration にアクセスできるように、アンダークラウドを変更する必要があります。この変更には、director 上の Puppet hieradata の変更などが含まれます。
undercloud.conf
の hieradata_override
を使用すると、アンダークラウド設定用に追加で Puppet hieradata を指定することができます。以下の手順を使用して、OpenStack Orchestration に関連する hieradata を変更してください。
-
hieradata_override
ファイルをまだ使用していない場合には、新しいファイルを作成します。以下の例では、/home/stack/hieradata.yaml
にあるファイルを使用します。 /home/stack/hieradata.yaml
に以下の hieradata を追加します。heat_clients_endpoint_type: public heat::engine::default_deployment_signal_transport: TEMP_URL_SIGNAL
これにより、デフォルトの
internal
からpublic
にエンドポイントが変更され、TempURL を使用するシグナルの方法が OpenStack Object Storage (swift) から変更されます。undercloud.conf
で、hieradata_override
パラメーターを hieradata ファイルのパスに設定します。hieradata_override = /home/stack/hieradata.yaml
-
openstack undercloud install
コマンドを再度実行して、新規設定オプションを実装します。
これにより、オーケストレーションメタデータが director のパブリック API 上の URL を使用するように切り替えられます。
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 1 parameter_defaults: NeutronPublicInterface: eth1 EC2MetadataIp: 192.168.100.1 2 ControlPlaneDefaultRoute: 192.168.100.1 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
リソースは、network/ports/noop.yaml
にマッピングされます。このマッピングは、デフォルトの Redis VIP アドレスがコントロールプレーンから割り当てられていることが理由です。このような場合には、noop
を使用して、このコントロールプレーンマッピングを無効化します。- 2
EC2MetadataIp
とControlPlaneDefaultRoute
パラメーターは、コントロールプレーンの仮想 IP アドレスの値に設定されます。デフォルトの NIC 設定テンプレートでは、これらのパラメーターが必須で、デプロイメント中に実行される検証に合格するには、ping 可能な IP アドレスを使用するように設定する必要があります。または、これらのパラメーターが必要ないように NIC 設定をカスタマイズします。