1. FRR は、VTY シェルを起動して、FRR ソケットに接続します。

   $ vtysh --vty_socket -c <command_file>

2. VTY シェルは、次のコマンドを含むファイルを渡します。

   LEAK_VRF_TEMPLATE = '''
   router bgp {{ bgp_as }}
     address-family ipv4 unicast
       import vrf {{ vrf_name }}
     exit-address-family
   
     address-family ipv6 unicast
       import vrf {{ vrf_name }}
     exit-address-family
   
   router bgp {{ bgp_as }} vrf {{ vrf_name }}
     bgp router-id {{ bgp_router_id }}
     address-family ipv4 unicast
       redistribute connected
     exit-address-family
   
     address-family ipv6 unicast
       redistribute connected
     exit-address-family
   ...

   VTY シェルが渡すコマンドは、次を実行します。

   1. デフォルトで bgp_vrf という名前の VRF を作成します。

   2. ダミーインターフェイスタイプを VRF に関連付けます。

      デフォルトでは、ダミーインターフェイスの名前は bgp-nic です。

   3. IP アドレスを OVS プロバイダーブリッジに追加して、Address Resolution Protocol (ARP) と Neighbor Discovery Protocol (NDP) が有効になっていることを確認します。

3. Zebra デーモンは、VM とロードバランサーの IP アドレスがローカルインターフェイスで追加および削除されるのを監視し、Zebra はルートをアドバタイズおよび撤回します。

   FRR は、redistribute connected オプションを有効にして、設定されているため、ルートのアドバタイズと撤回は、ダミーインターフェイス bgp-nic からルートを公開または削除するだけで、設定されます。

   注記

   テナントネットワークに接続された仮想マシンの公開は、デフォルトで無効になっています。RHOSP 設定で有効にされている場合、OVN BGP エージェントは neutron ルーターゲートウェイポートを公開します。OVN BGP エージェントは、テナントネットワーク上の仮想マシンに流れるトラフィックを、chassisredirect 論理ルーターポート (CR-LRP) をホストするノードを介して OVN オーバーレイに注入します。

4. FRR は、VM またはロードバランサーをホスティングするノード、または OVN ルーターゲートウェイポートを含むノードの IP アドレスを公開します。

1. OVS プロバイダーブリッジに IP アドレスを追加して、ARP と NDP を有効にします。

2. /etc/iproute2/rt_tables の各 OVS プロバイダーブリッジのルーティングテーブルにエントリーを追加します。

   注記

   RHEL カーネルの場合、ルーティングテーブルの最大数は 252 です。これにより、プロバイダーネットワークの数が 252 に制限されます。

3. VLAN デバイスをブリッジに接続し、ARP および NDP を有効にします (VLAN プロバイダーネットワークのみ)。
4. OVS プロバイダーブリッジで余分な OVS フローをクリーンアップします。

1. ルーティングテーブルに特定のルートを適用する IP アドレスルールを追加します。

   次の例では、このルールは OVS プロバイダーブリッジに関連付けられています。

   $ ip rule
   
   0:      from all lookup local
   1000:   from all lookup [l3mdev-table]
   *32000:  from all to IP lookup br-ex*  # br-ex is the OVS provider bridge
   *32000:  from all to CIDR lookup br-ex*  # for VMs in tenant networks
   32766:  from all lookup main
   32767:  from all lookup default

2. IP アドレスルートを OVS プロバイダーブリッジルーティングテーブルに追加して、トラフィックを OVS プロバイダーブリッジデバイスにルーティングします。

   $ ip route show table br-ex
   
   default dev br-ex scope link
   *CIDR via CR-LRP_IP dev br-ex*  # for VMs in tenant networks
   *CR-LRP_IP dev br-ex scope link*  # for the VM in tenant network redirection
   *IP dev br-ex scope link*  # IPs on provider or FIPs

3. IPv4 または IPv6 のどちらを使用しているかに応じて、次のいずれかの方法を使用して、トラフィックを OVS プロバイダーブリッジ (br-ex) 経由で OVN にルーティングします。

   1. IPv4 の場合は、OVN ルーターゲートウェイポート CR-LRP の静的 ARP エントリーを追加します。これは、OVN がその L2 ネットワークの外部の ARP 要求に応答しないためです。

      $ ip nei
      
      ...
      CR-LRP_IP dev br-ex lladdr CR-LRP_MAC PERMANENT
      ...

   2. IPv6 の場合は、NDP プロキシーを追加します。

      $ ip -6 nei add proxy CR-LRP_IP dev br-ex

4. OVS プロバイダーブリッジに新しいフローを追加して、OVN オーバーレイからカーネルネットワークにトラフィックを送信します。これにより、宛先 MAC アドレスが OVS プロバイダーブリッジの MAC アドレスに変更されます (actions=mod_dl_dst:OVN_PROVIDER_BRIDGE_MAC,NORMAL)。

   $ sudo ovs-ofctl dump-flows br-ex
   
   cookie=0x3e7, duration=77.949s, table=0, n_packets=0, n_bytes=0, priority=
   900,ip,in_port="patch-provnet-1" actions=mod_dl_dst:3a:f7:e9:54:e8:4d,NORMAL
   cookie=0x3e7, duration=77.937s, table=0, n_packets=0, n_bytes=0, priority=
   900,ipv6,in_port="patch-provnet-1" actions=mod_dl_dst:3a:f7:e9:54:e8:4d,NORMAL

1. (オプション) frr-parameters.yaml でアンダークラウドの BGP 設定値を設定します。
2. undercloud.conf でアンダークラウドのスパインリーフネットワークトポロジーの設定値を設定します。
3. openstack undercloud install コマンドを実行します。

手順

1. アンダークラウドホストに stack ユーザーとしてログインします。

2. stackrc アンダークラウド認証情報ファイルを入手します。

   $ source ~/stackrc

3. BGP を使用して、他のラックとオーバークラウドノードに到達する予定の場合は、カスタムヒート環境ファイル /home/stack/templates/frr-parameters.yaml に以下のパラメーターを追加して、アンダークラウドにインストールされるように、FRRouting (FRR) を設定します。

   注記

   このパスを控えておいてください。後のステップで必要になります。

   例:

   parameter_defaults:
     ContainerFrrImage: registry.redhat.io/rhosp-17.1/openstack-frr-rhel9:17.1.1
     FrrBfdEnabled: true
     FrrBgpEnabled: true
     FrrBgpAsn: 64999
     FrrBgpUplinks: ['nic2', 'nic3']
     FrrBgpUplinksScope: internal
     FrrLogLevel: debugging
     FrrBgpRouterID: 172.30.4.1
     FrrBgpIpv4SrcIp: 172.30.4.1
     FrrBgpIpv6SrcIp: fe80::5054:ff:fe74:73ce

   ヒント

   詳細は、オーバークラウドパラメーター ガイドの ネットワーク (neutron) パラメーター を参照してください。

   FrrBfdEnabled

   true の場合、Bidirectional Forwarding Detection (BFD) を有効にします。デフォルトは false です。

   FrrBgpEnabled

   true の場合、Border Gateway Protocol (BGP) を有効にします。デフォルトは true です。

   FrrBgpAsn

   FRRouting 内で使用されるデフォルトの ASN。デフォルトは 65000 です。FrrBgpAsn は、使用されるロールごとに異なる値に設定できます。

   FrrBgpUplinks

   アップリンクネットワークインターフェイスのコンマ区切りリスト。デフォルトは ['nic1', 'nic2'] です。

   FrrBgpUplinksScope

   内部 (iBGP) または外部 (eBGP) ネイバーとピアリングします。デフォルトは internal です。

   FrrLogLevel

   emergencies、alerts、critical、errors、warnings、notifications、informational、debugging の値セットを使用して、FRR のログレベルを指定します。デフォルトは informational です。

   FrrBgpRouterID

   FRR で使用される BGP router_id。

   FrrBgpIpv4SrcIp

   IPv4 ネットワークトラフィックの送信元 IP アドレス。

   FrrBgpIpv6SrcIp

   IPv6 ネットワークトラフィックの送信元 IP アドレス。

   tripleo_frr_bgp_peers

   ピアリングする Free Range Routing (FRR) の IP アドレスまたはホスト名のリストを指定するために使用されるロール固有のパラメーター。

   tripleo_frr_ovn_bgp_agent_enable

   データプレーンルートが公開されない RHOSP ノード上で OVN BGP エージェントを有効または無効にするために使用されるロール固有のパラメーター。デフォルト値は true です。

4. undercloud.conf ファイルがまだない場合には、サンプルのテンプレートファイルをコピーします。

   $ cp /usr/share/python-tripleoclient/undercloud.conf.sample \
   ~/templates/undercloud.conf

5. DEFAULT セクションで、次の一般パラメーター値を設定します。

   例:

   [DEFAULT]
   # General
   cleanup = false
   container_images_file=/home/stack/templates/
   \containers-prepare-parameter.yaml
   overcloud_domain_name = {{ cloud_domain }}
   undercloud_timezone = UTC
   undercloud_hostname = undercloud-0.{{ cloud_domain }}
   
   # BGP on undercloud
   ...
   
   # TLS-e
   ...
   
   # Networking
   ...
   
   # Subnets
   ...

   ヒント

   詳細は、director を使用した Red Hat OpenStack Platform のインストールおよび管理 の director 設定パラメーター を参照してください。

   overcloud_domain_name

   オーバークラウドをデプロイする際に使用する DNS ドメイン名を指定します。次のステップでは、この値がオーバークラウドの CloudDomain パラメーターの値と一致することを確認する必要があります。

   cleanup

   一時的なファイルを削除します。デプロイメント中に使用される一時ファイルを保持するには、これを false に設定します。一時ファイルは、エラーが発生した場合にデプロイメントのデバッグに役立ちます。

   container_images_file

   コンテナーイメージ情報を含む Heat 環境ファイルを指定します。

   container_insecure_registries

   podman が使用するセキュアではないレジストリーのリスト。プライベートコンテナーレジストリー等の別のソースからイメージをプルする場合には、このパラメーターを使用します。

   custom_env_files

   アンダークラウドのインストールに追加する新たな環境ファイル

   undercloud_hostname

   アンダークラウドの完全修飾ホスト名を定義します。本パラメーターを指定すると、アンダークラウドのインストールでホスト名すべてに設定されます。指定しないと、アンダークラウドは現在のホスト名を使用しますが、システムのホスト名すべてを適切に設定しておく必要があります。

   undercloud_timezone

   アンダークラウド用ホストのタイムゾーン。タイムゾーンを指定しなければ、director は既存のタイムゾーン設定を使用します。

6. アンダークラウドに BGP をインストールする場合は、DEFAULT セクションでアンダークラウドの FRR を有効にし、前の手順で FRR パラメーター値を設定したカスタム環境ファイルを指定します。

   例:

   [DEFAULT]
   # General
   ...
   
   # BGP on undercloud
   enable_frr=true
   custom_env_files=/home/stack/templates/frr-parameters.yaml
   
   # TLS-e
   ...
   
   # Networking
   ...
   
   # Subnets
   ...

7. TLS-everywhere を使用している場合は、[DEFAULT] セクションで、次の TLS-everywhere パラメーター値を設定します。

   例:

   [DEFAULT]
   # General
   ...
   
   # BGP on undercloud
   ...
   
   # TLS-e
   enable_novajoin = False
   undercloud_nameservers = {{ freeipa_ip }}
   generate_service_certificate = True
   ipa_otp = {{ undercloud_otp }}
   
   # Networking
   ...
   
   # Subnets
   ...

   ヒント

   詳細は、director を使用した Red Hat OpenStack Platform のインストールおよび管理 の director 設定パラメーター を参照してください。

   enable_novajoin

   true の場合、novajoin サービスが TLS をデプロイできるようにします。

   undercloud_nameservers

   アンダークラウドのネームサーバーの DNS サーバーの現在の IP アドレスを指定します。この情報は /etc/resolv.conf にあります。

   generate_service_certificate

   アンダークラウドのインストール時に SSL/TLS 証明書を生成するかどうかを定義します。これは undercloud_service_certificate パラメーターに使用します。

   ipa_otp

   FreeIPA OTP ファクトを設定します。

8. DEFAULT セクションで、次のネットワークパラメーター値を設定します。

   例:

   [DEFAULT]
   # General
   ...
   
   # BGP on undercloud
   ...
   
   # TLS-e
   ...
   
   # Networking
   local_interface = eth0
   local_ip = {{ undercloud_ctlplane }}/24
   undercloud_public_host = {{ undercloud_public_host }}
   undercloud_admin_host = {{ undercloud_admin_host }}
   
   # Subnets
   ...

   ヒント

   詳細は、director を使用した Red Hat OpenStack Platform のインストールおよび管理 の director 設定パラメーター を参照してください。

   local_interface

   ローカルネットワーク用にブリッジするインターフェイス。

   local_ip

   leaf0 上のアンダークラウドの IP アドレス。

   undercloud_public_host

   アンダークラウドの外部向け IP アドレス。

   undercloud_admin_host

   アンダークラウドの管理 IP アドレス。この IP アドレスは、通常 leaf0 上にあります。

9. 以前に subnets パラメーターで定義したサブネットごとに新しいセクションを作成します。

   重要

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

   例:

   [DEFAULT]
   # General
   ...
   
   # BGP on undercloud
   ...
   
   # TLS-e
   ...
   
   # Networking
   ...
   
   # Subnets
   [r1]
   # This subnet is used for overcloud nodes deployed on rack1.
   cidr = 192.168.1.0/24
   dhcp_start = 192.168.1.150
   dhcp_end = 192.168.1.170
   inspection_iprange = 192.168.1.171,192.168.1.185
   gateway = 192.168.1.1
   masquerade = False
   [r2]
   # This subnet is used for overcloud nodes deployed on rack2.
   cidr = 192.168.2.0/24
   dhcp_start = 192.168.2.150
   dhcp_end = 192.168.2.170
   inspection_iprange = 192.168.2.171,192.168.2.185
   gateway = 192.168.2.1
   masquerade = False
   [r3]
   # This subnet is used for overcloud nodes deployed on rack3.
   cidr = 192.168.3.0/24
   dhcp_start = 192.168.3.150
   dhcp_end = 192.168.3.170
   inspection_iprange = 192.168.3.171,192.168.3.185
   gateway = 192.168.3.1
   masquerade = False
   [r4]
   # This subnet is used for the underloud node and potentially FreeIPA
   # that are deployed on rack4.
   cidr = 192.168.4.0/24
   dhcp_start = {{ undercloud_dhcp_start }}
   dhcp_end = 192.168.4.170
   inspection_iprange = 192.168.4.171,192.168.4.185
   gateway = 192.168.4.1
   masquerade = False

   ヒント

   詳細は、director を使用した Red Hat OpenStack Platform のインストールおよび管理 ガイドの サブネット を参照してください。

   cidr

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

   masquerade

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

   注記

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

   dhcp_start と dhcp_end

   オーバークラウドノードの DHCP 割り当て範囲 (開始アドレスと終了アドレス)。ノードを割り当てるのに十分な IP アドレスがこの範囲に含まれるようにします。

   dhcp_exclude

   DHCP 割り当て範囲で除外する IP アドレス

   dns_nameservers

   サブネットに固有の DNS ネームサーバー。サブネットにネームサーバーが定義されていない場合には、サブネットは undercloud_nameservers パラメーターで定義されるネームサーバーを使用します。

   gateway

   オーバークラウドインスタンスのゲートウェイ。External ネットワークにトラフィックを転送するアンダークラウドのホストです。director に別の IP アドレスを使用する場合または直接外部ゲートウェイを使用する場合以外は、この値はデフォルト (192.168.24.1) のままにします。

10. インストールコマンドを実行します。

    $ openstack undercloud install

11. 各リーフおよびラックに到達するための追加のネットワークルートを含む、アンダークラウドのネットワーク設定が正しいことを確認します。

    詳細は、director を使用した Red Hat OpenStack Platform のインストールおよび管理 の director 設定パラメーター を参照してください。

検証

1. director 設定スクリプトは、すべてのサービスを自動的に開始します。RHOSP サービスコンテナーが実行中であることを確認します。

   $ 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
   ...

2. コマンドラインツールを使用するために stack ユーザーを初期化できることを確認します。

   $ source ~/stackrc

   プロンプトに (undercloud) が表示される場合、これは、OpenStack コマンドが認証され、アンダークラウドに対して実行されることを示しています。

   出力例

   (undercloud) [stack@director ~]$

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

手順

1. アンダークラウドホストに stack ユーザーとしてログインします。

2. stackrc アンダークラウド認証情報ファイルを入手します。

   $ source ~/stackrc

3. /home/stack の下に templates ディレクトリーを作成します。

   $ mkdir /home/stack/templates

4. デフォルトのネットワーク定義テンプレート、routed-networks.yaml をカスタムの templates ディレクトリーにコピーします。

   例:

   $ cp /usr/share/openstack-tripleo-heat-templates/network-data-samples/\
   routed-networks.yaml \
   /home/stack/templates/spine-leaf-networks-data.yaml

5. ネットワーク定義テンプレートのコピーを編集して、各ベースネットワークおよび関連する各リーフサブネットを設定可能なネットワークアイテムとして定義します。

   ヒント

   詳細は、director を使用した Red Hat OpenStack Platform のインストールと管理 ガイドの ネットワーク定義ファイル設定のオプション を参照してください。

   例:

   以下の例は、内部 API ネットワークおよびそのリーフネットワークを定義する方法を示しています。

   - name: InternalApi
     name_lower: internal_api
     vip: true
     mtu: 1500
     subnets:
       internal_api_subnet:
         ip_subnet: 172.16.32.0/24
         gateway_ip: 172.16.32.1
         allocation_pools:
           - start: 172.16.32.4
             end: 172.16.32.250
         vlan: 20
       internal_api_leaf1_subnet:
         ip_subnet: 172.16.33.0/24
         gateway_ip: 172.16.33.1
         allocation_pools:
           - start: 172.16.33.4
             end: 172.16.33.250
         vlan: 30
       internal_api_leaf2_subnet:
         ip_subnet: 172.16.34.0/24
         gateway_ip: 172.16.34.1
         allocation_pools:
           - start: 172.16.34.4
             end: 172.16.34.250
         vlan: 40

次のステップ

1. 作成したカスタムネットワーク定義ファイルのパスとファイル名をメモします。この情報は、後で RHOSP オーバークラウド用にネットワークをプロビジョニングする際に必要になります。
2. 次のステップ リーフロールの定義とネットワークの接続 に進みます。

手順

1. アンダークラウドホストに stack ユーザーとしてログインします。

2. stackrc アンダークラウド認証情報ファイルを入手します。

   $ source ~/stackrc

3. RHOSP に同梱されている Controller、Compute、Ceph Storage ロールのデフォルトロールを stack ユーザーのホームディレクトリーにコピーします。ファイルがリーフ 0 であることを示すようにファイルの名前を変更します。

   $ cp /usr/share/openstack-tripleo-heat-templates/roles/Controller.yaml \
   ~/roles/Controller0.yaml
   $ cp /usr/share/openstack-tripleo-heat-templates/roles/Compute.yaml \
   ~/roles/Compute0.yaml
   $ cp /usr/share/openstack-tripleo-heat-templates/roles/CephStorage.yaml \
   ~/roles/CephStorage0.yaml

4. リーフ 0 ファイルをコピーして、リーフ 1 およびリーフ 2 ファイルを作成します。

   $ cp ~/roles/Controller0.yaml ~/roles/Controller1.yaml
   $ cp ~/roles/Controller0.yaml ~/roles/Controller2.yaml
   $ cp ~/roles/Compute0.yaml ~/roles/Compute1.yaml
   $ cp ~/roles/Compute0.yaml ~/roles/Compute2.yaml
   $ cp ~/roles/CephStorage0.yaml ~/roles/CephStorage1.yaml
   $ cp ~/roles/CephStorage0.yaml ~/roles/CephStorage2.yaml

5. 各ファイルのパラメーターを編集して、それぞれのリーフパラメーターに合わせます。

   ヒント

   ロールデータテンプレートのさまざまなパラメーターについては、director を使用した Red Hat OpenStack Platform のインストールと管理 ガイドの ロールパラメーターの考察 を参照してください。

   例 - ComputeLeaf0

   - name: ComputeLeaf0
     HostnameFormatDefault: '%stackname%-compute-leaf0-%index%'

   例 - CephStorageLeaf0

   - name: CephStorageLeaf0
     HostnameFormatDefault: '%stackname%-cephstorage-leaf0-%index%'

6. それぞれのリーフネットワークのパラメーターと整合するように、リーフ 1 および リーフ 2 ファイルの network パラメーターを編集します。

   例 - ComputeLeaf1

   - name: ComputeLeaf1
     networks:
       InternalApi:
         subnet: internal_api_leaf1
       Tenant:
         subnet: tenant_leaf1
       Storage:
         subnet: storage_leaf1

   例 - CephStorageLeaf1

   - name: CephStorageLeaf1
     networks:
       Storage:
         subnet: storage_leaf1
       StorageMgmt:
         subnet: storage_mgmt_leaf1

   注記

   この設定を行うのは、リーフ 1 および リーフ 2 だけです。リーフ 0 の network パラメーターは、ベースサブネットの値のままにします (各サブネットの小文字を使用した名前に接尾辞 _subnet を追加したもの)。たとえば、リーフ 0 の内部 API は internal_api_subnet です。

7. コントローラー、コンピュート、および Networker (存在する場合) の各ロールファイルで、ServicesDefault パラメーターの下にあるサービスのリストに OVN BGP エージェントを追加します。

   例:

   - name: ControllerRack1
     ...
     ServicesDefault:
       ...
       - OS::TripleO::Services::Frr
       - OS::TripleO::Services::OVNBgpAgent
       ...

8. ロールの設定が完了したら、overcloud roles generate コマンドを実行して完全なロールデータファイルを生成します。

   例:

   $ openstack overcloud roles generate --roles-path ~/roles \
   -o spine-leaf-roles-data.yaml Controller Compute Compute1 Compute2 \
   CephStorage CephStorage1 CephStorage2

   これにより、それぞれのリーフネットワークのすべてのカスタムロールを含む 1 つのカスタムロールデータファイルが作成されます。

次のステップ

1. overcloudrolesgenerate コマンドによって作成されたカスタムロールデータファイルのパスとファイル名をメモします。このパスは、後でオーバークラウドをデプロイするときに使用します。
2. 次のステップ リーフロール用のカスタム NIC 設定の作成 に進みます。

手順

1. アンダークラウドホストに stack ユーザーとしてログインします。

2. stackrc アンダークラウド認証情報ファイルを入手します。

   $ source ~/stackrc

3. デフォルトの NIC テンプレートの 1 つからコンテンツをコピーして、NIC 設定のカスタムテンプレートを作成します。

   例:

   この例では、NIC テンプレート single-nic-vlans をコピーし、NIC 設定のカスタムテンプレートとして使用します。

   $ cp -r /usr/share/ansible/roles/tripleo_network_config/\
   templates/single-nic-vlans/* /home/stack/templates/spine-leaf-nics/.

4. 前の手順で作成した各 NIC テンプレートで、スパイン/リーフトポロジーの詳細に一致するように NIC 設定を変更します。

   例:

   {% set mtu_list = [ctlplane_mtu] %}
   {% for network in role_networks %}
   {{ mtu_list.append(lookup('vars', networks_lower[network] ~ '_mtu')) }}
   {%- endfor %}
   {% set min_viable_mtu = mtu_list | max %}
   network_config:
   - type: ovs_bridge
     name: {{ neutron_physical_bridge_name }}
     mtu: {{ min_viable_mtu }}
     use_dhcp: false
     dns_servers: {{ ctlplane_dns_nameservers }}
     domain: {{ dns_search_domains }}
     addresses:
     - ip_netmask: {{ ctlplane_ip }}/{{ ctlplane_subnet_cidr }}
     routes: {{ ctlplane_host_routes }}
     members:
     - type: interface
       name: nic1
       mtu: {{ min_viable_mtu }}
       # force the MAC address of the bridge to this interface
       primary: true
   {% for network in role_networks %}
     - type: vlan
       mtu: {{ lookup('vars', networks_lower[network] ~ '_mtu') }}
       vlan_id: {{ lookup('vars', networks_lower[network] ~ '_vlan_id') }}
       addresses:
       - ip_netmask:
           {{ lookup('vars', networks_lower[network] ~ '_ip') }}/{{ lookup('vars', networks_lower[network] ~ '_cidr') }}
       routes: {{ lookup('vars', networks_lower[network] ~ '_host_routes') }}
   {% endfor %}

   ヒント

   詳細は、director を使用した Red Hat OpenStack Platform のインストールと管理 ガイドの カスタムネットワークインターフェイステンプレート を参照してください。

5. カスタム NIC テンプレートを各カスタムロールにマッピングする parameter_defaults セクションを含む、spine-leaf-nic-roles-map.yaml などのカスタム環境ファイルを作成します。

   parameter_defaults:
     %%ROLE%%NetworkConfigTemplate: <path_to_ansible_jinja2_nic_config_file>

   例:

   parameter_defaults:
     Controller0NetworkConfigTemplate: '/home/stack/templates/spine-leaf-nics/single-nic-vlans.j2'
     Controller1NetworkConfigTemplate: '/home/stack/templates/spine-leaf-nics/single-nic-vlans.j2'
     Controller2NetworkConfigTemplate: '/home/stack/templates/spine-leaf-nics/single-nic-vlans.j2'
     ComputeLeaf0NetworkConfigTemplate: '/home/stack/templates/spine-leaf-nics/single-nic-vlans.j2'
     ComputeLeaf1NetworkConfigTemplate: '/home/stack/templates/spine-leaf-nics/single-nic-vlans.j2'
     ComputeLeaf2NetworkConfigTemplate: '/home/stack/templates/spine-leaf-nics/single-nic-vlans.j2'
     CephStorage0NetworkConfigTemplate: '/home/stack/templates/spine-leaf-nics/single-nic-vlans.j2'
     CephStorage1NetworkConfigTemplate: '/home/stack/templates/spine-leaf-nics/single-nic-vlans.j2'
     CephStorage2NetworkConfigTemplate: '/home/stack/templates/spine-leaf-nics/single-nic-vlans.j2'

次のステップ

1. カスタム NIC テンプレートのパスとファイル名、およびカスタム NIC テンプレートを各カスタムロールにマッピングするカスタム環境ファイルをメモします。このパスは、後でオーバークラウドをデプロイするときに使用します。
2. 次のステップ リーフネットワークの設定 に進みます。

手順

1. アンダークラウドホストに stack ユーザーとしてログインします。

2. stackrc アンダークラウド認証情報ファイルを入手します。

   $ source ~/stackrc

3. spin-leaf-ctlplane.yaml などの新しいカスタム環境ファイルで、parameter_defaults セクションを作成し、デフォルトの OVS プロバイダーブリッジ (br-ex) を使用するリーフごとに NeutronBridgeMappings パラメーターを設定します。

   重要

   ネットワーク定義を含めるために作成するカスタム環境ファイルの名前は、.yaml または .template で終わる必要があります。

   例:

   parameter_defaults:
     NeutronFlatNetworks: provider1
     ControllerRack1Parameters:
       NeutronBridgeMappings: ["provider1:br-ex", "provider2:br-vlan"]
   
     ControllerRack2Parameters:
       NeutronBridgeMappings: ["provider1:br-ex", "provider2:br-vlan"]
   
     ControllerRack3Parameters:
       NeutronBridgeMappings: ["provider1:br-ex", "provider2:br-vlan"]
   
     ComputeRack1Parameters:
       NeutronBridgeMappings: ["provider1:br-ex", "provider2:br-vlan"]
   
     ComputeRack2Parameters:
       NeutronBridgeMappings: ["provider1:br-ex", "provider2:br-vlan"]
   
     ComputeRack3Parameters:
       NeutronBridgeMappings: ["provider1:br-ex", "provider2:br-vlan"]

   ヒント

   詳細は、第 17 章ネットワーク (neutron) パラメータ (オーバークラウドのパラメーター ガイド) を参照してください。

4. VLAN ネットワークマッピングの場合、vlan を NeutronNetworkType に追加し、NeutronNetworkVLANRanges を使用してリーフネットワークの VLAN をマッピングします。

   例

   parameter_defaults:
     NeutronNetworkType: 'geneve,vlan'
     NeutronNetworkVLANRanges: 'provider2:1:1000'
   
     ControllerRack1Parameters:
       NeutronBridgeMappings: ["provider1:br-ex", "provider2:br-vlan"]
   
     ControllerRack2Parameters:
       NeutronBridgeMappings: ["provider1:br-ex", "provider2:br-vlan"]
   
     ControllerRack3Parameters:
       NeutronBridgeMappings: ["provider1:br-ex", "provider2:br-vlan"]
   
     ComputeRack1Parameters:
       NeutronBridgeMappings: ["provider1:br-ex", "provider2:br-vlan"]
   
     ComputeRack2Parameters:
       NeutronBridgeMappings: ["provider1:br-ex", "provider2:br-vlan"]
   
     ComputeRack3Parameters:
       NeutronBridgeMappings: ["provider1:br-ex", "provider2:br-vlan"]

   注記

   スパイン/リーフトポロジーでは、フラットネットワークと VLAN の両方を使用できます。

5. <role>ControlPlaneSubnet パラメーターを使用して、各スパイン/リーフネットワークのコントロールプレーンサブネットマッピングを追加します。

   例:

   parameter_defaults:
     NeutronNetworkType: 'geneve,vlan'
     NeutronNetworkVLANRanges: 'provider2:1:1000'
   
     ControllerRack1Parameters:
       NeutronBridgeMappings: ["provider1:br-ex", "provider2:br-vlan"]
       ControlPlaneSubnet: r1
   
     ControllerRack2Parameters:
       NeutronBridgeMappings: ["provider1:br-ex", "provider2:br-vlan"]
       ControlPlaneSubnet: r2
   
     ControllerRack3Parameters:
       NeutronBridgeMappings: ["provider1:br-ex", "provider2:br-vlan"]
       ControlPlaneSubnet: r3
   
     ComputeRack1Parameters:
       NeutronBridgeMappings: ["provider1:br-ex", "provider2:br-vlan"]
   
     ComputeRack2Parameters:
       NeutronBridgeMappings: ["provider1:br-ex", "provider2:br-vlan"]
   
     ComputeRack3Parameters:
       NeutronBridgeMappings: ["provider1:br-ex", "provider2:br-vlan"]

6. 各リーフの OVN BGP エージェント、FRRouting、CMS オプションを設定します。

   注記

   FRR サービスは、すべての RHOSP ノードで実行され、コントロールプレーンと、データプレーン全体のさまざまなノードで実行されているサービスとの間の接続を提供します。ただし、OVN BGP エージェントは、すべてのコンピュートノードと enable-chassis-as-gw で設定されたノードでのみ実行する必要があります。

   データプレーンルートが公開されていない RHOSP ノードの場合、tripleo_frr_ovn_bgp_agent_enable パラメーターを false に設定して、これらのロールの OVN BGP エージェントを無効にします。デフォルトは true です。

   例:

   parameter_defaults:
     DatabaseRack1ExtraGroupVars:
       tripleo_frr_ovn_bgp_agent_enable: false

   例:

   parameter_defaults:
     NeutronNetworkType: 'geneve,vlan'
     NeutronNetworkVLANRanges: 'provider2:1:1000'
   
     ControllerRack1Parameters:
       NeutronBridgeMappings: ["provider1:br-ex", "provider2:br-vlan"]
       ControlPlaneSubnet: r1
       FrrOvnBgpAgentDriver: 'ovn_bgp_driver'
       FrrOvnBgpAgentExposeTenantNetworks: True
       OVNCMSOptions: "enable-chassis-as-gw"
   
     ControllerRack2Parameters:
       NeutronBridgeMappings: ["provider1:br-ex", "provider2:br-vlan"]
       ControlPlaneSubnet: r2
       FrrOvnBgpAgentDriver: 'ovn_bgp_driver'
       FrrOvnBgpAgentExposeTenantNetworks: True
       OVNCMSOptions: "enable-chassis-as-gw"
   
     ControllerRack3Parameters:
       NeutronBridgeMappings: ["provider1:br-ex", "provider2:br-vlan"]
       ControlPlaneSubnet: r3
       FrrOvnBgpAgentDriver: 'ovn_bgp_driver'
       FrrOvnBgpAgentExposeTenantNetworks: True
       OVNCMSOptions: "enable-chassis-as-gw"
   
     ComputeRack1Parameters:
       NeutronBridgeMappings: ["provider1:br-ex", "provider2:br-vlan"]
       FrrOvnBgpAgentDriver: 'ovn_bgp_driver'
   
     ComputeRack2Parameters:
       NeutronBridgeMappings: ["provider1:br-ex", "provider2:br-vlan"]
       FrrOvnBgpAgentDriver: 'ovn_bgp_driver'
   
     ComputeRack3Parameters:
       NeutronBridgeMappings: ["provider1:br-ex", "provider2:br-vlan"]
       FrrOvnBgpAgentDriver: 'ovn_bgp_driver'

   ヒント

   詳細は、第 17 章ネットワーク (neutron) パラメータ (オーバークラウドのパラメーター ガイド) を参照してください。

   OVNCMSOptions

   OVSDB で設定する CMS オプション

   FrrOvnBgpAgentReconcileInterval

   ステータスをチェックする頻度を定義して、正しい場所で正しい IP のみが公開されるようにします。デフォルト: 120

   FrrOvnBgpAgentOvsdbConnection

   ネイティブ OVSDB バックエンドの接続文字列。TCP 接続には tcp:<IP_address>:<port> を使用します。デフォルト: tcp:127.0.0.1:6640

   FrrOvnBgpAgentExposeTenantNetworks

   MP-BGP IPv4 および IPv6 ユニキャストを介してテナントネットワーク上の VM IP を公開します。BGP ドライバーが必要です (THT パラメーター FrrOvnBgpAgentDriver を参照)。デフォルト: false

   FrrOvnBgpAgentDriver

   VM IP が BGP 経由で公開される方法を設定します。EVPN ドライバーは、プロバイダーネットワーク上の VM IP と、MP-BGP IPv4 および IPv6 ユニキャストを介してテナントネットワーク上の VM に関連付けられた FIP を公開します。BGP ドライバーは、MP-BGP EVPN VXLAN 経由でテナントネットワーク上の VM IP を公開します。デフォルト: ovn_evpn_driver

   FrrOvnBgpAgentAsn

   BGP モードでの実行時にエージェントが使用する Autonomous System 番号 (ASN)。デフォルト: 64999FrrOvnBgpAgentAsn は、使用されるロールごとに異なる値に設定できます。

   FrrLogLevel

   ログレベル。デフォルト: 情報提供

   FrrBgpAsn

   FRR 内で使用されるデフォルトの ASN。デフォルトは 65000 です。FrrBgpAsn は、使用されるロールごとに異なる値に設定できます。

次のステップ

1. 作成したカスタムネットワーク環境ファイルのパスとファイル名をメモします。このパスは、後でオーバークラウドをデプロイするときに必要になります。
2. 次のステップ 仮想 IP アドレス用サブネットの設定 に進みます。

手順

1. アンダークラウドホストに stack ユーザーとしてログインします。

2. stackrc アンダークラウド認証情報ファイルを入手します。

   $ source ~/stackrc

3. spin-leaf-vip-data.yaml などの新しいカスタムネットワーク仮想 IP 定義テンプレートで、コントローラーノードが使用する特定のサブネット上に作成する必要のある仮想 IP アドレスを一覧表示します。

   例:

   - network: storage_mgmt
     subnet: storage_mgmt_subnet_leaf1
   - network: internal_api
     subnet: internal_api_subnet_leaf1
   - network: storage
     subnet: storage_subnet_leaf1
   - network: external
     subnet: external_subnet_leaf1
     ip_address: 172.20.11.50
   - network: ctlplane
     subnet: leaf0
   - network: oc_provisioning
     subnet: oc_provisioning_subnet_leaf1
   - network: storage_nfs
     subnet: storage_nfs_subnet_leaf1

   spine-leaf-vip-data.yaml ファイルで、以下のパラメーターを使用できます。

   network

   neutron ネットワーク名を設定します。これは唯一の必須パラメーターです。

   ip_address

   VIP の IP アドレスを設定します。

   subnet

   neutron サブネット名を設定します。仮想 IP neutron ポートを作成するときにサブネットを指定するために使用します。このパラメーターは、展開でルーティングされたネットワークを使用する場合に必要です。

   dns_name

   FQDN (完全修飾ドメイン名) を設定します

   name

   仮想 IP 名を設定します。

   ヒント

   詳細は、director を使用した Red Hat OpenStack Platform のインストールと管理 ガイドの コンポーザブルネットワークの追加 を参照してください。

次のステップ

1. 作成したカスタムネットワーク仮想 IP 定義テンプレートのパスとファイル名をメモします。このパスは、後で RHOSP オーバークラウド用にネットワーク仮想 IP をプロビジョニングするときに使用します。
2. 次のステップ オーバークラウド用のネットワークと VIP のプロビジョニング に進みます。

手順

1. アンダークラウドホストに stack ユーザーとしてログインします。

2. stackrc アンダークラウド認証情報ファイルを入手します。

   $ source ~/stackrc

3. オーバークラウドネットワークをプロビジョニングします。

   overcloud network professional コマンドを使用して、前に作成したネットワーク定義ファイルへのパスを指定します。

   ヒント

   詳細は、director を使用した Red Hat OpenStack Platform のインストールと管理 ガイドの オーバークラウドのネットワーク定義の設定とプロビジョニング を参照してください。

   例:

   この例では、パスは /home/stack/templates/spine-leaf-networks-data.yaml です。--output 引数を使用して、コマンドによって作成されたファイルに名前を付けます。

   $ openstack overcloud network provision \
     --output spine-leaf-networks-provisioned.yaml \
    /home/stack/templates/spine-leaf-networks-data.yaml

   重要

   指定する出力ファイルの名前は、.yaml または .template で終わる必要があります。

4. オーバークラウド仮想 IP をプロビジョニングします。

   overcloud network vip professional コマンドを --stack 引数とともに使用して、前に作成した仮想 IP 定義ファイルに名前を付けます。--output 引数を使用して、コマンドによって作成されたファイルに名前を付けます。

   ヒント

   詳細は、director を使用した Red Hat OpenStack Platform のインストールと管理 ガイドの オーバークラウドのネットワーク仮想 IP の設定とプロビジョニング を参照してください。

   $ openstack overcloud network vip provision \
     --stack spine-leaf-overcloud \
    --output spine-leaf-vips-provisioned.yaml \
    /home/stack/templates/spine-leaf-vip-data.yaml

   重要

   指定する出力ファイルの名前は、.yaml または .template で終わる必要があります。

5. 生成された出力ファイルのパスとファイル名に注意してください。この情報は、後でオーバークラウドをデプロイするときに使用します。

次のステップ

1. 事前にプロビジョニングされたノードを使用している場合は、オーバークラウドデプロイメントコマンドの実行 にスキップしてください。
2. それ以外の場合は、次のステップ オーバークラウドにベアメタルノードを登録する に進みます。

手順

1. アンダークラウドホストに stack ユーザーとしてログインします。

2. stackrc アンダークラウド認証情報ファイルを入手します。

   $ source ~/stackrc

3. 新しいノード定義テンプレート (barematal-nodes.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"

   ヒント

   テンプレートパラメーター値と JSON の例の詳細は、director を使用した Red Hat OpenStack Platform のインストールと管理 ガイドの オーバークラウドのノードの登録 を参照してください。

4. テンプレートのフォーマットと構文を確認します。

   例:

   $ openstack overcloud node import --validate-only ~/templates/\
   baremetal-nodes.yaml

5. エラーを修正し、ノード定義テンプレートを保存します。

6. ノード定義テンプレートを RHOSP director にインポートして、各ノードをテンプレートから director に登録します。

   例:

   $ openstack overcloud node import ~/baremetal-nodes.yaml

手順

1. アンダークラウドホストに stack ユーザーとしてログインします。

2. stackrc アンダークラウド認証情報ファイルを入手します。

   $ source ~/stackrc

3. pre-introspection 検証グループを実行して、プリイントロスペクションの要件を確認します。

   $ validation run --group pre-introspection

4. 検証レポートの結果を確認します。

5. オプション: 特定の検証からの詳細な出力を確認します。

   $ validation history get --full <UUID>

   <UUID> は、確認するレポートの特定の検証の UUID に置き換えます。

   重要

   検証結果が FAILED であっても、RHOSP のデプロイや実行が妨げられることはありません。ただし、FAILED の検証結果は、実稼働環境で問題が発生する可能性があることを意味します。

6. すべてのノードのハードウェア属性を検査します。

   $ openstack overcloud node introspect --all-manageable --provide

   ヒント

   詳細は、director を使用した Red Hat OpenStack Platform のインストールと管理ガイド の director のイントロスペクションを使用したベアメタルノードのハードウェア情報の収集 を参照してください。

   別のターミナルウィンドウで、イントロスペクションの進捗ログを監視します。

   $ sudo tail -f /var/log/containers/ironic-inspector/ironic-inspector.log

手順

1. アンダークラウドホストに stack ユーザーとしてログインします。

2. stackrc アンダークラウド認証情報ファイルを入手します。

   $ source ~/stackrc

3. spin-leaf-baremetal-nodes.yaml などのベアメタルノード定義ファイルを作成し、プロビジョニングするロールごとにノード数を定義します。

   例:

   - name: ControllerRack1
     count: 1
     hostname_format: ctrl-1-%index%
     defaults:
       network_config:
         default_route_network:
         - ctlplane
         template: /home/stack/tht/nics_r1.yaml
       networks:
         - network: ctlplane
           vif: true
         - network: left_network
         - network: right_network1
         - network: main_network
         - network: main_network_ipv6
     instances:
     - hostname: ctrl-1-0
       name: ctrl-1-0
       capabilities:
         node: ctrl-1-0
       networks:
       - network: ctlplane
         vif: true
       - network: left_network
         fixed_ip: 100.65.1.2
         subnet: left_network_r1
       - network: right_network1
         fixed_ip: 100.64.0.2
         subnet: right_network1_sub
       - network: main_network
         fixed_ip: 172.30.1.1
         subnet: main_network_r1
       - network: main_network_ipv6
         fixed_ip: f00d:f00d:f00d:f00d:f00d:f00d:f00d:0001
         subnet: main_network_ipv6_r1
   - name: ComputeRack1
     count: 2
     hostname_format: cmp-1-%index%
     defaults:
       network_config:
         default_route_network:
           - ctlplane
         template: /home/stack/tht/nics_r1.yaml
       networks:
         - network: ctlplane
           vif: true
         - network: left_network
         - network: right_network1
         - network: main_network
         - network: main_network_ipv6
     instances:
     - hostname: cmp-1-0
       name: cmp-1-0
       capabilities:
         node: cmp-1-0
       networks:
       - network: ctlplane
         vif: true
       - network: left_network
         fixed_ip: 100.65.1.6
         subnet: left_network_r1
       - network: right_network1
         fixed_ip: 100.64.0.6
         subnet: right_network1_sub
       - network: main_network
         fixed_ip: 172.30.1.2
         subnet: main_network_r1
       - network: main_network_ipv6
         fixed_ip: f00d:f00d:f00d:f00d:f00d:f00d:f00d:0004
         subnet: main_network_ipv6_r1
     - hostname: cmp-1-1
       name: cmp-1-1
       capabilities:
         node: cmp-1-1
       networks:
       - network: ctlplane
         vif: true
       - network: left_network
         fixed_ip: 100.65.1.10
         subnet: left_network_r1
       - network: right_network1
         fixed_ip: 100.64.0.10
         subnet: right_network1_sub
       - network: main_network
         fixed_ip: 172.30.1.3
         subnet: main_network_r1
       - network: main_network_ipv6
         fixed_ip: f00d:f00d:f00d:f00d:f00d:f00d:f00d:0005
         subnet: main_network_ipv6_r1
   - name: ControllerRack2
     count: 1
     hostname_format: ctrl-2-%index%
     defaults:
       network_config:
         default_route_network:
         - ctlplane
         template: /home/stack/tht/nics_r2.yaml
       networks:
         - network: ctlplane
           vif: true
         - network: left_network
         - network: right_network2
         - network: main_network
         - network: main_network_ipv6
     instances:
     - hostname: ctrl-2-0
       name: ctrl-2-0
       capabilities:
         node: ctrl-2-0
       networks:
       - network: ctlplane
         vif: true
       - network: left_network
         fixed_ip: 100.65.2.2
         subnet: left_network_r2
       - network: right_network2
         fixed_ip: 100.64.0.2
         subnet: right_network2_sub
       - network: main_network
         fixed_ip: 172.30.2.1
         subnet: main_network_r2
       - network: main_network_ipv6
         fixed_ip: f00d:f00d:f00d:f00d:f00d:f00d:f00d:0002
         subnet: main_network_ipv6_r1
   - name: ComputeRack2
     count: 2
     hostname_format: cmp-2-%index%
     defaults:
       network_config:
         default_route_network:
         - ctlplane
         template: /home/stack/tht/nics_r2.yaml
       networks:
       - network: ctlplane
         vif: true
       - network: left_network
       - network: right_network2
       - network: main_network
       - network: main_network_ipv6
     instances:
     - hostname: cmp-2-0
       name: cmp-2-0
       capabilities:
         node: cmp-2-0
       networks:
       - network: ctlplane
         vif: true
       - network: left_network
         fixed_ip: 100.65.2.6
         subnet: left_network_r2
       - network: right_network2
         fixed_ip: 100.64.0.6
         subnet: right_network2_sub
       - network: main_network
         fixed_ip: 172.30.2.2
         subnet: main_network_r2
       - network: main_network_ipv6
         fixed_ip: f00d:f00d:f00d:f00d:f00d:f00d:f00d:0006
         subnet: main_network_ipv6_r1
     - hostname: cmp-2-1
       name: cmp-2-1
       capabilities:
         node: cmp-2-1
       networks:
       - network: ctlplane
         vif: true
       - network: left_network
         fixed_ip: 100.65.2.10
         subnet: left_network_r2
       - network: right_network2
         fixed_ip: 100.64.0.10
         subnet: right_network2_sub
       - network: main_network
         fixed_ip: 172.30.2.3
         subnet: main_network_r2
       - network: main_network_ipv6
         fixed_ip: f00d:f00d:f00d:f00d:f00d:f00d:f00d:0007
         subnet: main_network_ipv6_r1
   - name: ControllerRack3
     count: 1
     hostname_format: ctrl-3-%index%
     defaults:
       network_config:
         default_route_network:
         - ctlplane
         template: /home/stack/tht/nics_r3.yaml
       networks:
       - network: ctlplane
         vif: true
       - network: left_network
       - network: right_network3
       - network: main_network
       - network: main_network_ipv6
     instances:
     - hostname: ctrl-3-0
       name: ctrl-3-0
       capabilities:
         node: ctrl-3-0
       networks:
       - network: ctlplane
         vif: true
       - network: left_network
         fixed_ip: 100.65.3.2
         subnet: left_network_r3
       - network: right_network3
         fixed_ip: 100.64.0.2
         subnet: right_network3_sub
       - network: main_network
         fixed_ip: 172.30.3.1
         subnet: main_network_r3
       - network: main_network_ipv6
         fixed_ip: f00d:f00d:f00d:f00d:f00d:f00d:f00d:0003
         subnet: main_network_ipv6_r1
   - name: ComputeRack3
     count: 2
     hostname_format: cmp-3-%index%
     defaults:
       network_config:
         default_route_network:
         - ctlplane
         template: /home/stack/tht/nics_r3.yaml
       networks:
       - network: ctlplane
         vif: true
       - network: left_network
       - network: right_network3
       - network: main_network
       - network: main_network_ipv6
     instances:
     - hostname: cmp-3-0
       name: cmp-3-0
       capabilities:
         node: cmp-3-0
       networks:
       - network: ctlplane
         vif: true
       - network: left_network
         fixed_ip: 100.65.3.6
         subnet: left_network_r3
       - network: right_network3
         fixed_ip: 100.64.0.6
         subnet: right_network3_sub
       - network: main_network
         fixed_ip: 172.30.3.2
         subnet: main_network_r3
       - network: main_network_ipv6
         fixed_ip: f00d:f00d:f00d:f00d:f00d:f00d:f00d:0008
         subnet: main_network_ipv6_r1
     - hostname: cmp-3-1
       name: cmp-3-1
       capabilities:
         node: cmp-3-1
       networks:
       - network: ctlplane
         vif: true
       - network: left_network
         fixed_ip: 100.65.3.10
         subnet: left_networ10_r3
       - network: right_network3
         fixed_ip: 100.64.0.10
         subnet: right_network3_sub
       - network: main_network
         fixed_ip: 172.30.3.3
         subnet: main_network_r3
       - network: main_network_ipv6
         fixed_ip: f00d:f00d:f00d:f00d:f00d:f00d:f00d:0009
         subnet: main_network_ipv6_r1

   ヒント

   ベアメタルノード定義ファイルを設定できるプロパティーの詳細は、director を使用した Red Hat OpenStack Platform のインストールと管理 ガイドの オーバークラウドのベアメタルノードのプロビジョニング を参照してください。

4. overcloud node provision コマンドを使用して、オーバークラウドのベアメタルノードをプロビジョニングします。

   例:

   $ openstack overcloud node provision \
    --stack spine_leaf_overcloud \
    --network-config \
    --output spine-leaf-baremetal-nodes-provisioned.yaml \
    /home/stack/templates/spine-leaf-baremetal-nodes.yaml

   重要

   指定する出力ファイルの名前は、.yaml または .template で終わる必要があります。

5. 別のターミナルでプロビジョニングの進捗をモニタリングします。プロビジョニングが成功すると、ノードの状態が available から active に変わります。

   $ watch openstack baremetal node list

6. metalsmith ツールを使用して、割り当てやポートなどを含むノードの統合ビューを取得します。

   $ metalsmith list

7. 生成された出力ファイルのパスとファイル名に注意してください。このパスは、後でオーバークラウドをデプロイするときに必要になります。

手順

1. Red Hat Ceph Storage をインストールする方法については、director を使用した Red Hat Ceph Storage および Red Hat OpenStack Platform のデプロイ 手順に従ってください。Ceph Storage クラスターを設定するステップで、次の追加のステップを実行します。

2. Ceph 設定ファイルを作成し、[global] という名前のセクションを追加します。

   例:

   この例では、Ceph 設定ファイルの名前は、initial-ceph.conf です。

   $ echo "[global]" > initial-ceph.conf

3. [global] セクションに、public_network パラメーターと cluster_network パラメーターを追加し、undercloud.conf ファイルにリストされているサブネット CIDR をそれぞれに追加します。オーバークラウドノードに対応するサブネット CIDR のみを含めてください。

   ヒント

   追加するサブネット CIDR は、RHOSP 動的ルーティング用のアンダークラウドのインストールと設定 で説明されているものです。

   例:

   この例では、オーバークラウドノードに対応する undercloud.conf ファイル内のサブネットを public_network パラメーターと cluster_network パラメーターに追加します。

   [global]
   public_network="192.168.1.0/24,192.168.2.0/24,192.168.3.0/24"
   cluster_network="192.168.1.0/24,192.168.2.0/24,192.168.3.0/24"

4. Ceph をデプロイする準備ができたら、overcloud ceph deploy コマンドに必ず Initial-ceph.conf を含めます。

   例:

   $ openstack overcloud ceph deploy --config initial-ceph.conf \
   <other_arguments> \
   /home/stack/templates/overcloud-baremetal-deployed.yaml

   重要

   動的ルーティングはまだ利用できません。したがって、Ceph ノードが NTP サーバーに到達するためにルーティングを必要とする場合、Ceph ノードの NTP 設定が遅れる可能性があります。

   サイトで NTP サーバーを使用している場合は、openstack overcloud ceph deploy コマンドに --skip-ntp を追加してください。

   Ceph が必要な NTP サーバーに到達できるように BGP ルートが確立されるまでは、Ceph クラスターを実稼働環境に導入しないでください。オーバークラウドがデプロイされ NTP が設定されないと、NTP が設定されていない Ceph クラスターにより、さまざまな異常が発生する可能性があります。たとえば、デーモンが受信したメッセージを無視したり、タイムスタンプが古かったり、メッセージが時間内に受信されなかった場合にトリガーされるタイムアウトが早すぎたり遅すぎたりすることがあります。

5. overcloud ceph deploy コマンドの実行により生成された出力ファイルのパスとファイル名をメモします。この例では、/home/stack/templates/overcloud-baremetal-deployed.yaml です。この情報は、後でオーバークラウドをデプロイするときに必要になります。

手順

1. アンダークラウドホストに stack ユーザーとしてログインします。

2. stackrc アンダークラウド認証情報ファイルを入手します。

   $ source ~/stackrc

3. オーバークラウド環境に必要なカスタム環境ファイルとカスタムテンプレートを照合します。このリストには、director インストールで提供される未編集の heat テンプレートファイルと、作成したカスタムファイルが含まれます。次のファイルへのパスがあることを確認します。

   • オーバークラウド上のスパイン/リーフネットワークの仕様を含むカスタムネットワーク定義ファイル (例: spin-leaf-networks-data.yaml)。

     詳細は、リーフネットワークの定義 を参照してください。

   • 各リーフのロールを定義するカスタムロールデータファイル。

     例: spine-leaf-roles.yaml

     詳細は、リーフのロールの定義とネットワークの接続 を参照してください。

   • ロールと各ロールのカスタム NIC テンプレートマッピングを含むカスタム環境ファイル。

     例: spine-leaf-nic-roles-map.yaml

     詳細は、リーフロール用のカスタム NIC 設定の作成 を参照してください。

   • 個別のネットワークマッピングを含み、オーバークラウドのコントロールプレーンネットワークへのアクセスを設定するカスタムネットワーク環境ファイル。

     例: spine-leaf-ctlplane.yaml

     詳細は、リーフネットワークの設定 を参照してください。

   • オーバークラウドネットワークのプロビジョニングからの出力ファイル。

     例: spine-leaf-networks-provisioned.yaml

     詳細は、オーバークラウドのネットワークと VIP のプロビジョニング を参照してください。

   • オーバークラウド仮想 IP のプロビジョニングからの出力ファイル。

     例: spine-leaf-vips-provisioned.yaml

     詳細は、オーバークラウドのネットワークと VIP のプロビジョニング を参照してください。

   • 事前にプロビジョニングされたノードを使用していない場合は、ベアメタルノードのプロビジョニングからの出力ファイル。

     例: spine-leaf-baremetal-nodes-provisioned.yaml

     詳細は、オーバークラウド用のベアメタルノードのプロビジョニング を参照してください。

   • overcloud ceph deploy コマンドからの出力ファイル。

     例: overcloud-baremetal-deployed.yaml。

     詳細は、動的ルーティング環境への Ceph のデプロイ を参照してください。

   • その他のカスタム環境ファイル

4. コマンドへの入力であるカスタム環境ファイルとカスタムテンプレートを慎重に並べ替えて、overcloud deploy コマンドを入力します。

   一般的なルールは、未編集の heat テンプレートファイルを最初に指定し、次にカスタム環境ファイルと、デフォルトプロパティーのオーバーライドなどのカスタム設定を含むカスタムテンプレートを指定することです。

   overclouddeploy コマンドへの入力をリストする際には、次の順序に従います。

   1. 各ロールにマップされたカスタム NIC テンプレートを含むカスタム環境ファイルを含めます。

      例: network-environment.yaml の後に、spine-leaf-nic-roles-map.yaml を追加します。

      network-environment.yaml ファイルは、設定可能なネットワークパラメーターのデフォルトのネットワーク設定を提供します。これは、マッピングファイルによってオーバーライドされます。director はこのファイルを network-environment.j2.yaml Jinja2 テンプレートからレンダリングする点に注意してください。

   2. 他のスパイン/リーフネットワーク環境ファイルを作成した場合は、これらの環境ファイルをロールと NIC テンプレートのマッピングファイルの後に含めます。

   3. 環境ファイルを更に追加します。(例: コンテナーイメージの場所や Ceph クラスターの設定を定義した環境ファイルなど)。

      例:

      overcloud deploy コマンド例からの以下の抜粋は、コマンドの入力の適切な順序を示しています。

      $ openstack overcloud deploy --templates \
        -n /home/stack/templates/spine-leaf-networks-data.yaml \
        -e /usr/share/openstack-tripleo-heat-templates/environments/network-environment.yaml \
        -e /usr/share/openstack-tripleo-heat-templates/environments/services/frr.yaml \
        -e /usr/share/openstack-tripleo-heat-templates/environments/services/ovn-bgp-agent.yaml \
        -e /home/stack/templates/spine-leaf-nic-roles-map.yaml \
        -e /home/stack/templates/spine-leaf-ctlplane.yaml \
        -e /home/stack/templates/spine-leaf-baremetal-provisioned.yaml \
        -e /home/stack/templates/spine-leaf-networks-provisioned.yaml \
        -e /home/stack/templates/spine-leaf-vips-provisioned.yaml \
        -e /home/stack/templates/overcloud-baremetal-deployed.yaml \
        -e /home/stack/containers-prepare-parameter.yaml \
        -e /home/stack/inject-trust-anchor-hiera.yaml \
        -r /home/stack/templates/spine-leaf-roles-data.yaml
        ...

   ヒント

   詳細は、director を使用した Red Hat OpenStack Platform のインストールと管理 ガイドの オーバークラウドの作成 を参照してください。

5. overcloud deploy コマンドを実行します。

   オーバークラウドの作成が完了すると、RHOSP director は、オーバークラウドへのアクセスに役立つ詳細を提供します。

手順

1. BGP デーモン bgpd のトラブルシューティングを行うホストにログインします。通常、bgpd は、すべてのオーバークラウドノードで実行されます。

2. FRR コンテナーに入ります。

   $ sudo podman exec -it frr bash

3. VTY シェルコマンドを実行するには、次の 2 つのオプションがあります。

   • インタラクティブモード

     sudo vtysh を 1 回入力してインタラクティブモードに入り、複数の VTY シェルコマンドを実行します。

     例:

     $ sudo vtysh
     > show bgp summary

   • Direct モード

     各 VTY シェルコマンドの前に sudo vtysh -c を付けます。

     例:

     $ sudo vtysh -c 'show bgp summary'

4. 以下に、VTY シェル BGP デーモンのトラブルシューティングコマンドをいくつか示します。

   ヒント

   IPv6 を使用している場合は、ip 引数を省略します。

   特定のルーティングテーブルまたはすべてのルーティングテーブルを表示します。

   > show ip bgp <IPv4_address> | all
   > show bgp <IPv6_address> | all

   BGP ピアにアドバタイズされたスロールート

   > show ip bgp neighbors <router-ID> <advertised-routes>

   BGP ピアから受信したスロールート

   > show ip bgp neighbors <router-ID> <received-routes>