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
parameter_defaults:
NeutronPublicInterface: eth1
EC2MetadataIp: 192.168.100.1
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 設定をカスタマイズします。