第3章 オーバークラウドへの OpenDaylight のインストール
本ガイドには、OpenDaylight のインストールを中心とした内容のみを記載しています。OpenDaylight をデプロイする前には、アンダークラウド環境が正常に機能しており、オーバークラウドノードが物理ネットワークに接続されていることを確認する必要があります。
アンダークラウドとオーバークラウドのデプロイに必要な手順を記載した『director のインストールと使用方法』の「アンダークラウドのインストール」および「CLI ツールを使用した基本的なオーバークラウドの設定」を参照してください。
Red Hat OpenStack platform で OpenDaylight をインストールするには、いくつかの方法があります。次の章では、OpenDaylight の最も役立つシナリオとインストールの方法を紹介します。
3.1. デフォルトの設定と設定値のカスタマイズ
OpenDaylight のインストールの推奨される方法は、デフォルトの環境ファイル neutron-opendaylight.yaml を使用して、そのファイルをアンダークラウドでデプロイメントコマンドに引数として渡す方法です。これにより、OpenDaylight のデフォルトのインストール環境がデプロイされます。
OpenDaylight インストールと設定のその他のシナリオは、このインストールの方法をベースとしています。デプロイメントコマンドに特定の環境ファイルを指定することによって、さまざまな異なるシナリオで OpenDaylight をデプロイすることができます。
3.1.1. デフォルトの環境ファイルについての理解
デフォルトの環境ファイルは /usr/share/openstack-tripleo-heat-templates/environments/services-docker/ ディレクトリー内の neutron-opendaylight.yaml です。この環境ファイルで OpenDaylight がサポートするサービスを有効化/無効化します。また、この環境ファイルは、director がデプロイメント中に設定する必須のパラメーターを定義します。
以下のファイルは、Docker ベースのデプロイメントに使用することができる neutron-opendaylight.yaml ファイルの例です。
# A Heat environment that can be used to deploy OpenDaylight with L3 DVR using Docker containers resource_registry: OS::TripleO::Services::NeutronOvsAgent: OS::Heat::None OS::TripleO::Services::ComputeNeutronOvsAgent: OS::Heat::None OS::TripleO::Services::ComputeNeutronCorePlugin: OS::Heat::None OS::TripleO::Services::OpenDaylightApi: ../../docker/services/opendaylight-api.yaml OS::TripleO::Services::OpenDaylightOvs: ../../puppet/services/opendaylight-ovs.yaml OS::TripleO::Services::NeutronL3Agent: OS::Heat::None OS::TripleO::Docker::NeutronMl2PluginBase: ../../puppet/services/neutron-plugin-ml2-odl.yaml parameter_defaults: NeutronEnableForceMetadata: true NeutronPluginExtensions: 'port_security' NeutronMechanismDrivers: 'opendaylight_v2' NeutronServicePlugins: 'odl-router_v2,trunk' OpenDaylightLogMechanism: 'console'
Red Hat OpenStack Platform director は resource_registry を使用してデプロイメント用のリソースを対応するリソース定義の yaml ファイルにマッピングします。サービスは、マッピング可能なリソース種別の 1 つです。特定のサービスを無効化する必要がある場合には、 OS::Heat::None の値を設定します。デフォルトのファイルでは、OpenDaylightApi と OpenDaylightOvs のサービスが有効化されますが、neutron エージェントは、OpenDaylight がその機能を継承するため、明示的に無効化されます。
Heat パラメーターは、director を使用したデプロイメントの設定値を設定するために使用されます。デフォルト値を上書きするには、環境ファイルの parameter_defaults セクションを使用してください。
この例では、OpenDaylight を有効化するために、NeutronEnableForceMetadata、NeutronMechanismDrivers、NeutronServicePlugins のパラメーターが設定されています。
その他のサービスとそれらの設定オプションは、本書の後半に記載しています。
3.1.2. OpenDaylight API サービスの設定
必要に応じて、/usr/share/openstack-tripleo-heat-templates/puppet/services/opendaylight-api.yaml ファイルのデフォルト値を変更することができます。このファイルの設定は、決して直接上書きしないようにしてください。代わりに、このファイルを複製して、元のファイルをバックアップ対策として保持します。複製したファイルのみを編集し、そのファイルをデプロイメントのコマンドで渡します。
後に指定する環境ファイルのパラメーターにより、前の環境ファイルのパラメーターが上書きされます。パラメーターが誤って上書きされるのを防ぐために、環境ファイルの指定順序には注意を払う必要があります。
3.1.2.1. 設定可能なオプション
OpenDaylight API サービス の設定時には、いくつかのパラメーターを指定することができます。
|
|
ノースバウンドの通信に使用するポートを設定します。デフォルト値は |
|
|
OpenDaylight のログインユーザー名を設定します。デフォルト値は |
|
|
OpenDaylight のログインパスワードを設定します。デフォルト値は |
|
|
OpenDaylight を有効化して、DHCP サービスとして機能するようにします。デフォルト値は |
|
|
OpenDaylight で起動する機能のカンマ区切りのリスト。デフォルト値は |
|
|
REST のアクセスに使用する L7 プロトコルを設定します。デフォルトは |
|
|
OpenDaylight リポジトリーを管理するかどうかを設定します。デフォルトは |
|
|
OpenDaylight が使用する SNAT メカニズムを設定します。 |
|
|
OpenDaylight のロギングメカニズムを設定します。 |
|
|
OpenDaylight TLS キーストアのパスワードを設定します。デフォルト値は |
|
|
内部ネットワークで TLS を有効または無効にします。 |
|
|
内部ネットワーク内のサービス用に TLS を有効にする場合は、 |
3.1.3. OpenDaylight OVS サービスの設定
必要に応じて、/usr/share/openstack-tripleo-heat-templates/puppet/services/opendaylight-ovs.yaml ファイルのデフォルト値を変更することができます。このファイルの設定は、決して直接上書きしないようにしてください。代わりに、このファイルを複製して、元のファイルをバックアップ対策として保持します。複製したファイルのみを編集し、そのファイルをデプロイメントのコマンドで渡します。
後に指定する環境ファイルのパラメーターにより、前の環境ファイルのパラメーターが上書きされます。パラメーターが誤って上書きされるのを防ぐために、環境ファイルの指定順序には注意を払う必要があります。
3.1.3.1. 設定可能なオプション
OpenDaylight OVS サービス の設定時には、いくつかのパラメーターを指定することができます。
|
|
OpenDaylight へのノースバウンドの通信に使用するポートを設定します。デフォルトは |
|
|
REST アクセスに使用するレイヤー 7 プロトコル。デフォルトは |
|
|
OpenDaylight の検証に使用する URL は、OVS が接続する前に完全に稼働します。デフォルト値は |
|
|
論理ネットワークと物理インターフェースの間のマッピングのコンマ区切りリスト。この設定は、VLAN デプロイメントに必要です。デフォルトは |
|
|
OpenDaylight OVS サービスのカスタムユーザー名を設定可能にします。デフォルト値は |
|
|
OpenDaylight OVS サービスのカスタムパスワードを設定可能にします。デフォルト値は |
|
|
この OVS ホストに許可されているネットワーク種別。nova インスタンスとネットワークのスケジュール先となるホストを制限するために、ホストまたはロールによって異なる場合があります。デフォルトは |
|
|
OVS で DPDK を有効化するかどうかを選択します。デフォルト値は |
|
|
vhostuser ポート作成での OVS のモードを指定します。クライアントモードでは、ハイパーバイザーが vhostuser ソケットを作成する役割を果たします。サーバーモードでは、OVS が vhostuser を作成します。デフォルト値は |
|
|
vhostuser ソケットを使用するディレクトリーを指定します。デフォルト値は |
|
|
OVS ハードウェアオフロードを有効または無効にします。 |
|
|
内部ネットワークで TLS を有効または無効にします。 |
|
|
内部ネットワーク内のサービス用に TLS を有効にする場合は、 |
|
|
このパラメーターを使用して、OpenDaylight の更新レベルを指定します。 |
|
|
vhost-user ソケットディレクトリーのグループを設定します。vhostuser がデフォルトの |
|
|
vhost-user ソケットディレクトリーのユーザー名を設定します。vhostuser がデフォルトの |
3.1.4. OpenDaylight での neutron メタデータサービスの使用
OpenStack Compute サービスにより、特定のアドレス 169.254.169.254 に対して Web 要求を実行することによって、仮想マシンはそれらに関連付けられたメタデータのクエリーを行うことができます。OpenStack Networking は、分離されたネットワークまたは重複する IP アドレスを使用する複数のネットワークから要求が実行された場合でも、そのような nova-api に対する要求をプロキシーします。
メタデータサービスは、neutron L3 エージェントルーターを使用して、メタデータ要求または DHCP エージェントインスタンスに対応します。レイヤー 3 のルーティングプラグインを有効化して OpenDaylight をデプロイすると、neutron L3 エージェントが無効化されます。このため、テナントネットワークにルーターがある場合でも、メタデータは DHCP インスタンスを通過するように設定する必要があります。この機能は、デフォルトの環境ファイル neutron-opendaylight.yaml で有効化されます。無効にするには、NeutronEnableForceMetadata を false に設定してください。
仮想マシンインスタンスには、169.254.169.254/32 に DHCP オプション 121 を使用する静的なホストルートがインストールされます。この静的なルートが配置されていると、169.254.169.254:80 へのメタデータ要求は、DHCP ネットワーク名前空間内のメタデータ名前サーバープロキシーに送信されます。名前空間のプロキシーは、次に HTTP ヘッダーをインスタンスの IP と共に要求に追加し、Unix ドメインソケットを介して、メタデータエージェントに接続します。メタデータエージェントは、neutron にクエリーを実行し、送信元の IP とネットワーク ID に対応するインスタンス ID を要求し、それを nova メタデータサービスにプロキシーします。追加の HTTP ヘッダーは、テナント間の分離を維持し、重複する IP をサポートできるようにするのに必要です。
3.1.5. ネットワーク設定と NIC テンプレートについての理解
Red Hat OpenStack Platform director では、物理的な neutron ネットワークのデータセンターは、デフォルトで br-ex という名前の OVS ブリッジにマッピングされます。これは、OpenDaylight の統合と常に同じです。デフォルトの OpenDaylightProviderMappings を使用して flat または VLAN _External ネットワークを作成する予定の場合には、コンピュートノード用の NIC テンプレートで OVS br-ex ブリッジを設定する必要があります。レイヤー 3 プラグインは、これらのノードに対して分散ルーティングを使用するので、コントローラーロールの NIC テンプレートでは br-ex を設定する必要はなくなります。
br-ex ブリッジは、ネットワーク分離内の任意のネットワークにマッピングすることができますが、例に示したように、通常は外部ネットワークにマッピングされます。
type: ovs_bridge
name: {get_input: bridge_name}
use_dhcp: false
members:
-
type: interface
name: nic3
# force the MAC address of the bridge to this interface
primary: true
dns_servers: {get_param: DnsServers}
addresses:
-
ip_netmask: {get_param: ExternalIpSubnet}
routes:
-
default: true
ip_netmask: 0.0.0.0/0
next_hop: {get_param: ExternalInterfaceDefaultRoute}DPDK では、別の OVS ブリッジを作成する必要があります。これは、通常は br-phy という名前で、ovs-dpdk ポートと共に指定します。ブリッジの IP アドレスは、VXLAN オーバーレイネットワークトンネル向けに設定されます。
type: ovs_user_bridge
name: br-phy
use_dhcp: false
addresses:
-
ip_netmask: {get_param: TenantIpSubnet}
members:
-
type: ovs_dpdk_port
name: dpdk0
driver: uio_pci_generic
members:
-
type: interface
name: nic1
# force the MAC address of the bridge to this interface
primary: trueネットワーク分離を使用する場合には、コンピュートノード上のこのブリッジには IP アドレスまたはデフォルトのルートを配置する必要はありません。
また、br-ex ブリッジを完全に使用することなく、外部ネットワークアクセスを設定することが可能です。このメソッドを使用するには、オーバークラウドのコンピュートノードのインターフェース名を前もって確認しておく必要があります。たとえば、コンピュートノード上の 3 番目のインターフェースの確定的な名前が eth3 の場合には、コンピュートノード用の NIC テンプレートでインターフェースを指定するのにその名前を使用することができます。
- type: interface name: eth3 use_dhcp: false
3.2. OpenDaylight の基本インストール
本項では、標準の環境ファイルを使用して OpenDaylight をデプロイする方法を説明します。
3.2.1. オーバークラウド用の OpenDaylight 環境ファイルの準備
作業を開始する前に
- アンダークラウドをインストールします。詳しくは、 「アンダークラウドのインストール」を参照してください。
- オプションとして、オーバークラウドと OpenDaylight のインストール中に使用するコンテナーイメージを備えたローカルレジストリーを作成します。 詳しくは、『director のインストールと使用方法』ガイドの「コンテナーイメージのソースの設定」を参照してください。
手順
アンダークラウドにログインして、admin の認証情報を読み込みます。
$ source ~/stackrc
OpenStack および OpenDaylight のインストールに必要な Docker コンテナーイメージへの参照が含まれた Docker レジストリーファイル
odl-images.yamlを作成します。$ openstack overcloud container image prepare -e /usr/share/openstack-tripleo-heat-templates/environments/services-docker/neutron-opendaylight.yaml --output-env-file /home/stack/templates/odl-images.yaml
オーバークラウドをデプロイするための環境の作成が正常に完了し、「OpenDaylight を実装するオーバークラウドのインストール」に記載のインストールを開始する準備が整いました。
詳細情報
openstack overcloud image prepare コマンドは、オーバークラウドと OpenDaylight のインストール用のコンテナーイメージ環境ファイルを準備します。このコマンドでは、以下のオプションを使用します。
- -e
- OpenDaylight、OVS など、その環境に必要な特定のコンテナーイメージを追加するためのサービス環境ファイルを指定します。
- --env-file
- インストールに使用されるコンテナーイメージの一覧を記載した新規コンテナーイメージの環境ファイルを作成します。
- --pull-source
- Docker コンテナーレジストリーの場所を設定します。
- --namespace
- Docker コンテナーのバージョンを設定します。
- --prefix
- イメージ名にプレフィックスを追加します。
- --suffix
- イメージ名にサフィックスを追加します。
- --tag
- イメージのリリースを定義します。
3.2.2. OpenDaylight を実装するオーバークラウドのインストール
作業を開始する前に
- 「オーバークラウド用の OpenDaylight 環境ファイルの準備」の手順に従って、デプロイメントに必要な環境ファイルを作成します。
手順
アンダークラウドにログインして、admin の認証情報を読み込みます。
$ source ~/stackrc
事前に作成した環境ファイルを使用してオーバークラウドをデプロイします。
$ openstack overcloud deploy --templates /usr/share/openstack-tripleo-heat-templates \ -e <other environment files> -e /usr/share/openstack-tripleo-heat-templates/environments/services-docker/neutron-opendaylight.yaml \ -e /home/stack/templates/odl-images.yaml
デプロイのコマンドで先に指定する環境ファイルは、そのコマンドで後に指定する環境ファイルによって上書きされます。指定する環境ファイルの順序に注意を払って、パラメーターが誤って上書きされないようにする必要があります。
変更するパラメーターのみの設定する最小限の環境ファイルを作成して、デフォルトの環境ファイルと組み合わせることにより、一部のパラメーターを上書きすることができます。
詳細情報
本手順の openstack overcloud deploy コマンドでは、以下のオプションを使用しています。
- --templates
- Heat テンプレートのディレクトリーへのパスを定義します。
- -e
- 環境ファイルを指定します。
3.3. カスタムロールでの OpenDaylight のインストール
カスタムロールで OpenDaylight をインストールすると、OpenDaylightApi サービスが分離されて、コントローラーノードとは異なる、指定の OpenDaylight ノードで実行されます。
OpenDaylight 用のカスタムロールを使用する場合には、ノードのレイアウトと機能の設定が含まれたロールファイルを作成する必要があります。
3.3.1. デフォルトロールをベースとするロールファイルのカスタマイズ
ユーザー定義のロール一覧を使用して、OpenStack をデプロイすることができます。各ロールは、ユーザー定義のサービス一覧を実行します。ロールとは、個別のサービスまたは設定が含まれるノードのグループです。たとえば、nova API サービスが含まれる Controller ロールを作成することができます。ロールのサンプルは、openstack-tripleo-heat-templates で参照することができます。
これらのロールを使用して、オーバークラウドノードに必要なロールが記載された roles_data.yaml ファイルを作成します。また、ディレクトリー内に個別のファイルを作成し、それらを使用して新しい roles_data.yaml を生成することによって、カスタムロールを作成することも可能です。
特定の OpenStack ロールのみをインストールするカスタマイズされた環境ファイルを作成するには、以下の手順を完了します。
手順
admin の認証情報を読み込みます。
$ source ~/stackrc
カスタムの
roles_data.yamlファイルを生成するのに使用可能なデフォルトのロールの一覧$ openstack overcloud role list
これらのロールをすべて使用する場合には、以下のコマンドを実行して
roles_data.yamlファイルを生成します。$ openstack overcloud roles generate -o roles_data.yaml
ロールファイルをカスタマイズして、一部のロールのみが含まれるようにするには、前のステップで、コマンドにそのロール名を引数として渡すことができます。たとえば、Controller、Compute、Telemetry ロールのみが含まれる
roles_data.yamlファイルを作成するには、以下のコマンドを実行します。$ openstack overcloud roles generate - roles_data.yaml Controller Compute Telemetry
3.3.2. OpenDaylight 用のカスタムロールの作成
カスタムロールを作成するには、ロールファイルディレクトリーに新しいロールファイルを作成して、新しい roles_data.yaml ファイルを生成します。作成するカスタムロールごとに、新しいロールファイルを作成する必要があります。各カスタムロールファイルは、特定の役割のためのデータが含まれている必要があり、カスタムのロールファイル名はロール名と一致する必要があります。
このファイルでは、少なくとも以下のパラメーターを定義する必要があります。
Name:ロール名を定義します。この名前は、必ず空にせず、一意の文字列する必要があります。- Name: Custom_role
ServicesDefault:このロールで使用するサービスをリストします。サービスを使用しない場合には、この変数は空のままにすることができます。以下に書式の例を示します。ServicesDefault: - OS::TripleO::Services::AuditD - OS::TripleO::Services::CACerts - OS::TripleO::Services::CertmongerUser - OS::TripleO::Services::Collectd - OS::TripleO::Services::Docker
必須のパラメーター以外に、他の設定も定義することができます。
CountDefault:デフォルトのノード数を定義します。CountDefault:が空の場合には、デフォルトでゼロに設定されます。CountDefault: 1
HostnameFormatDefault:ホスト名の書式文字列を定義します。この値は任意です。HostnameFormatDefault: '%stackname%-computeovsdpdk-%index%'
Description:ロールについて説明し、情報を追加します。Description: Compute OvS DPDK Role
手順
デフォルトのロールファイルを新規ディレクトリーにコピーします。元のファイルは、バックアップとして保管してください。
$ mkdir ~/roles $ cp /usr/share/openstack-tripleo-heat-templates/roles/* ~/roles
~/rolesのController.yamlファイルでデフォルトのコントローラーロールを編集して、そのファイルからOpenDaylightApiの行を削除し、コントローラーノード上で OpenDaylightAPI サービスを無効にします。- name: Controller CountDefault: 1 ServicesDefault: - OS::TripleO::Services::TripleoFirewall - OS::TripleO::Services::OpenDaylightApi #<--Remove this - OS::TripleO::Services::OpenDaylightOvs~/rolesディレクトリーに新しいOpenDaylight.yamlファイルを作成して、 OpenDaylight ロールの説明を追加します。- name: OpenDaylight CountDefault: 1 ServicesDefault: - OS::TripleO::Services::Aide - OS::TripleO::Services::AuditD - OS::TripleO::Services::CACerts - OS::TripleO::Services::CertmongerUser - OS::TripleO::Services::Collectd - OS::TripleO::Services::Docker - OS::TripleO::Services::Fluentd - OS::TripleO::Services::Ipsec - OS::TripleO::Services::Kernel - OS::TripleO::Services::LoginDefs - OS::TripleO::Services::MySQLClient - OS::TripleO::Services::Ntp - OS::TripleO::Services::ContainersLogrotateCrond - OS::TripleO::Services::Rhsm - OS::TripleO::Services::RsyslogSidecar - OS::TripleO::Services::Securetty - OS::TripleO::Services::SensuClient - OS::TripleO::Services::Snmp - OS::TripleO::Services::Sshd - OS::TripleO::Services::Timezone - OS::TripleO::Services::TripleoFirewall - OS::TripleO::Services::TripleoPackages - OS::TripleO::Services::Tuned - OS::TripleO::Services::Ptp - OS::TripleO::Services::OpenDaylightApi- ファイルを保存します。
OpenDaylight をカスタムロールで実装する OpenStack オーバークラウドのデプロイに使用する新規ロールファイルを生成します。
$ openstack overcloud roles generate --roles-path ~/roles -o ~/roles_data.yaml Controller Compute OpenDaylight
3.3.3. OpenDaylight をカスタムロールで実装するオーバークラウドのインストール
作業を開始する前に
- アンダークラウドをインストールします (「アンダークラウドのインストール」を参照)。
- オーバークラウドのコンテナーイメージへのリンクを記載した環境ファイルを作成します (「オーバークラウド用の OpenDaylight 環境ファイルの準備」を参照)。
- カスタムロールで OpenDaylight を設定するためのロールファイルを準備します (「OpenDaylight 用のカスタムロールの作成」を参照)。
手順
必要な OpenDaylight ノードをフレーバーにマッピングする環境ファイルを作成します。必要な OpenDaylight ノード数。OpenDaylight のコンポーザブルロール用のフレーバーを作成して、そのフレーバーで ironic ノードをタグ付けする必要もあります。
- name: odl-composable parameter_defaults: - OvercloudOpenDaylightFlavor: opendaylight - OvercloudOpenDaylightCount: 1 ServicesDefault: - OS::TripleO::Opendaylight::Net::SoftwareConfig: /home/stack/templates/nic-configs/odl.yaml-r 引数を指定してデプロイメントコマンドを実行し、デフォルトのロール定義を上書きします。このオプションは、カスタマイズされたロールが設定されている別の
roles_data.yamlを使用するようにデプロイメントコマンドに指示します。前のステップで作成したodl-composable.yaml環境ファイルをデプロイメントコマンドに渡します。以下の例では、ironic ノードが合計で 3 つあり、その中の 1 つがカスタムの OpenDaylight ロール用に確保されます。$ openstack overcloud deploy --templates /usr/share/openstack-tripleo-heat-templates -e /usr/share/openstack-tripleo-heat-templates/environments/docker.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/services-docker/neutron-opendaylight.yaml -e network-environment.yaml --compute-scale 1 --ntp-server 0.se.pool.ntp.org --control-flavor control --compute-flavor compute -r ~/roles_data.yaml -e /home/stack/templates/docker-images.yaml -e /home/stack/templates/odl-images.yaml -e /home/stack/templates/odl-composable.yaml
デプロイのコマンドで先に指定する環境ファイルは、そのコマンドで後に指定する環境ファイルによって上書きされます。指定する環境ファイルの順序に注意を払って、パラメーターが誤って上書きされないようにする必要があります。
変更するパラメーターのみの設定する最小限の環境ファイルを作成して、デフォルトの環境ファイルと組み合わせることにより、一部のパラメーターを上書きすることができます。
詳細情報
-rオプションは、インストール時にロールの定義を上書きします。-r <roles_data>.yaml
- カスタムロールを使用するには、インストール中にそのカスタムロール用に使用する追加の ironic ノードが必要となります。
3.3.4. カスタムロールでの OpenDaylight インストールの検証
作業を開始する前に
- カスタムロールで OpenDaylight を実装するオーバークラウドをインストールします。詳しくは、「OpenDaylight を実装するオーバークラウドのインストール」 を参照してください。
手順
既存のインスタンスを一覧表示します。
$ openstack server list
結果を確認し、新規 OpenDaylight ロールが 1 つのインスタンスとして専用になっていることを確認します。
+--------------------------------------+--------------------------+--------+------------+-------------+--------------------+ | ID | Name | Status | Task State | Power State | Networks | +--------------------------------------+--------------------------+--------+------------+-------------+--------------------+ | 360fb1a6-b5f0-4385-b68a-ff19bcf11bc9 | overcloud-controller-0 | BUILD | spawning | NOSTATE | ctlplane=192.0.2.4 | | e38dde02-82da-4ba2-b5ad-d329a6ceaef1 | overcloud-novacompute-0 | BUILD | spawning | NOSTATE | ctlplane=192.0.2.5 | | c85ca64a-77f7-4c2c-a22e-b71d849a72e8 | overcloud-opendaylight-0 | BUILD | spawning | NOSTATE | ctlplane=192.0.2.8 | +--------------------------------------+--------------------------+--------+------------+-------------+--------------------+
3.4. SR-IOV 対応の OpenDaylight のインストール
OpenDaylight は、Single Root Input/Output Virtualization (SR-IOV) 対応のコンピュートノードと共にデプロイすることができます。このデプロイメントでは、コンピュートノードは、SR-IOV のみの専用ノードで稼働する必要があり、OVS をベースとする nova インスタンスを混在させてはなりません。単一の OpenDaylight デプロイメント内で OVS と SR-IOV のコンピュートノードの両方をデプロイすることは可能です。
このシナリオでは、カスタムの SR-IOV コンピュートロールを使用してこの種のデプロイメントを行います。
SR-IOV のデプロイメントでは、neutron SR-IOV エージェントを使用して、Virtual Function (VF) を設定する必要があります。これは、デプロイ時に Compute インスタンスに直接渡されて、そこでネットワークポートとして機能します。VF はコンピュートノード上のホスト NIC から派生するので、デプロイメントを開始する前に、ホストのインターフェースに関する情報が必要となります。
3.4.1. SR-IOV コンピュートロールの準備
「カスタムロールでの OpenDaylight のインストール」に記載したのと同じ方法に従って、SR-IOV コンピュートノード用のカスタムロールを作成し、デフォルトの Compute ロールが OVS ベースの nova インスタンスに対応する一方で、SR-IOV ベースのインスタンスを作成できるようにする必要があります。
作業を開始する前に
- 「カスタムロールでの OpenDaylight のインストール」 の章を参照してください。
手順
デフォルトのロールファイルを新規ディレクトリーにコピーします。元のファイルは、バックアップとして保管してください。
$ mkdir ~/roles $ cp /usr/share/openstack-tripleo-heat-templates/roles/* ~/roles
~/rolesディレクトリーに新しいComputeSriov.yamlファイルを作成して、 以下のロールの説明を追加します。- name: ComputeSRIOV CountDefault: 1 ServicesDefault: - OS::TripleO::Services::Kernel - OS::TripleO::Services::Ntp - OS::TripleO::Services::NeutronSriovHostConfig - OS::TripleO::Services::NeutronSriovAgent - OS::TripleO::Services::TripleoPackages - OS::TripleO::Services::TripleoFirewall - OS::TripleO::Services::Sshd - OS::TripleO::Services::NovaCompute - OS::TripleO::Services::NovaLibvirt - OS::TripleO::Services::NovaMigrationTarget - OS::TripleO::Services::Timezone - OS::TripleO::Services::ComputeNeutronCorePlugin - OS::TripleO::Services::Securetty- ファイルを保存します。
NeutronSriovAgentおよびNeutronSriovHostConfigのサービスをデフォルトのコンピュートロールから削除して、対応するロールファイルを保存します。- OS::TripleO::Services::NeutronSriovHostConfig - OS::TripleO::Services::NeutronSriovAgentOpenDaylight のコンピュートで SR-IOV をサポートする OpenStack オーバークラウドのデプロイに使用する新規ロールファイルを生成します。
$ openstack overcloud roles generate --roles-path ~/roles -o ~/roles_data.yaml Controller Compute ComputeSriov
3.4.2. SR-IOV エージェントサービスの設定
SR-IOV をサポートする OpenDaylight をデプロイするには、neutron-opendaylight.yaml ファイルのデフォルトのパラメーターをオーバーライドする必要があります。/usr/share/openstack-tripleo-heat-templates にある標準の SR-IOV 環境ファイルと、neutron-opendaylight.yaml 環境ファイルを使用することができます。元のファイルは編集しないのが適切なプラクティスです。代わりに、元の環境ファイルを複製して、その複製したファイル内でパラメーターを変更してください。
また、変更するパラメーターのみを指定する新規環境ファイルを作成して、両方のファイルをデプロイメントに使用することができます。 カスタマイズされた OpenDaylight をデプロイするには、デプロイメントコマンドに両方のファイルを渡します。後で指定する環境ファイルが前の設定を上書きするので、これらは正しい順序でデプロイメントコマンドに含める必要があります。ただし順序は、neutron-opendaylight.yaml が最初で、neutron-opendaylight-sriov.yaml が後になります。
OpenDaylight と SR-IOV をデフォルト設定でデプロイする場合には、Red Hat で提供している neutron-opendaylight-sriov.yaml を使用することができます。パラメーターを変更または追加する必要がある場合には、デフォルトの SR-IOV 環境ファイルのコピーを作成して、その新規作成されたファイルを編集してください。
カスタマイズされた neutron-opendaylight-sriov.yaml ファイルの例を以下に示します。
# A Heat environment that can be used to deploy OpenDaylight with SRIOV resource_registry: OS::TripleO::Services::NeutronOvsAgent: OS::Heat::None OS::TripleO::Services::ComputeNeutronOvsAgent: OS::Heat::None OS::TripleO::Services::ComputeNeutronCorePlugin: ../puppet/services/neutron-plugin-ml2.yaml OS::TripleO::Services::NeutronCorePlugin: ../puppet/services/neutron-plugin-ml2-odl.yaml OS::TripleO::Services::OpenDaylightApi: ../docker/services/opendaylight-api.yaml OS::TripleO::Services::OpenDaylightOvs: ../puppet/services/opendaylight-ovs.yaml OS::TripleO::Services::NeutronSriovAgent: ../puppet/services/neutron-sriov-agent.yaml OS::TripleO::Services::NeutronL3Agent: OS::Heat::None parameter_defaults: NeutronEnableForceMetadata: true NeutronPluginExtensions: 'port_security' NeutronMechanismDrivers: ['sriovnicswitch','opendaylight_v2'] NeutronServicePlugins: 'odl-router_v2,trunk' # Add PciPassthroughFilter to the scheduler default filters #NovaSchedulerDefaultFilters: ['RetryFilter','AvailabilityZoneFilter','RamFilter','ComputeFilter','ComputeCapabilitiesFilter', 'ImagePropertiesFilter','ServerGroupAntiAffinityFilter','ServerGroupAffinityFilter','PciPassthroughFilter'] #NovaSchedulerAvailableFilters: ["nova.scheduler.filters.all_filters","nova.scheduler.filters.pci_passthrough_filter.PciPassthroughFilter"] #NeutronPhysicalDevMappings: "datacentre:ens20f2" # Number of VFs that needs to be configured for a physical interface #NeutronSriovNumVFs: "ens20f2:5" #NovaPCIPassthrough: # - devname: "ens20f2" # physical_network: "datacentre"
詳細情報
neutron-opendaylight-sriov.yaml ファイルでは、以下のオプションを設定することができます。以下の表には、各オプションについての説明と、SR-IOV 機能を有効化するために必要な設定を記載します。
|
|
SR-IOV 用の PCI パススルーを使用できるようにします。このパラメーターは、環境ファイル内でコメント解除して、 |
|
|
Nova のデフォルトフィルターに PCI パススルーフィルターを指定できるようにします。このパラメーターは必須で、 |
|
|
neutron の論理ネットワークをホストのネットワークインターフェースにマッピングします。neutron が仮想ネットワークを物理ポートにバインドできるようにするには、このパラメーターを指定する必要があります。 |
|
|
1 つのホストのネットワークインターフェイス用に作成する VF の数。構文: |
|
|
PCI パススルーでの使用を許可する nova の PCI デバイスのホワイトリストを一覧形式で設定します。以下に例を示します。 NovaPCIPassthrough:
- vendor_id: "8086"
product_id: "154c"
address: "0000:05:00.0"
physical_network: "datacentre"
特定のハードウェア属性の代わりに単に論理デバイス名を使用することもできます。 NovaPCIPassthrough:
- devname: "ens20f2"
physical_network: "datacentre"
|
3.4.3. SR-IOV 対応の OpenDaylight のインストール
作業を開始する前に
- アンダークラウドをインストールします (「アンダークラウドのインストール」を参照)。
- オーバークラウドのコンテナーイメージへのリンクを記載した環境ファイルを作成します (「オーバークラウド用の OpenDaylight 環境ファイルの準備」を参照)。
- カスタムロールで SR-IOV 対応の OpenDaylight を設定するためのロールファイルを作成します (「SR-IOV コンピュートロールの準備」を参照)。
手順
-rの引数を使用してデプロイメントコマンドを実行し、カスタマイズしたロールファイルと OpenDaylight で SR-IOV 機能を有効化するのに必要な環境ファイルを指定します。$ openstack overcloud deploy --templates /usr/share/openstack-tripleo-heat-templates -e <other environment files> -e /usr/share/openstack-tripleo-heat-templates/environments/services-docker/neutron-opendaylight.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/services-docker/neutron-opendaylight-sriov.yaml -e network-environment.yaml --compute-scale 1 --ntp-server 0.se.pool.ntp.org --control-flavor control --compute-flavor compute -r my_roles_data.yaml -e /home/stack/templates/docker-images.yaml -e /home/stack/templates/odl-images.yaml
デプロイのコマンドで先に指定する環境ファイルは、そのコマンドで後に指定する環境ファイルによって上書きされます。指定する環境ファイルの順序に注意を払って、パラメーターが誤って上書きされないようにする必要があります。
変更するパラメーターのみの設定する最小限の環境ファイルを作成して、デフォルトの環境ファイルと組み合わせることにより、一部のパラメーターを上書きすることができます。
詳細情報
-rオプションは、インストール時にロールの定義を上書きします。-r <roles_data>.yaml
- カスタムロールを使用するには、インストール中にそのカスタムロール用に使用する追加の ironic ノードが必要となります。
3.5. OVS-DPDK 対応の OpenDaylight のインストール
OpenDaylight は、director を使用して Open vSwitch Data Plane Development Kit (DPDK) アクセラレーションに対応するようにデプロイすることができます。このデプロイメントでは、カーネル空間ではなくユーザー空間でパケットが処理されるために、データプレーンパフォーマンスが向上します。OVS-DPDK 対応のデプロイメントには、潜在的なパフォーマンスを引き出すために、各コンピュートノードのハードウェア物理レイアウトに関する知識が必要です。
特に次の点を考慮すべきです。
- ホスト上のネットワークインターフェースが DPDK をサポートしていること
- コンピュートノードの NUMA ノードのトポロジー (ソケット数、CPU コア、1 ソケットあたりのメモリー容量)
- DPDK NIC PCI バスが各 NUMA ノードに近いこと
- コンピュートノード上で使用可能な RAM 容量
- 『Network Functions Virtualization Planning and Configuration Guide』を参照してください。
3.5.1. OVS-DPDK デプロイメントファイルの準備
OVS-DPDK をデプロイするには、異なる環境ファイルを使用します。そのファイルは、 /usr/share/openstack-tripleo-heat-templates/environments/services-docker ディレクトリーにある neutron-opendaylight.yaml 環境ファイルで設定されている一部のパラメーターを上書きします。元の環境ファイルは変更しないでください。代わりに、必要なパラメーターが含まれた新しい環境ファイルを作成します (例: neutron-opendaylight-dpdk.yaml)。
OVS-DPDK を実装する OpenDaylight をデフォルトの設定でデプロイするには、/usr/share/openstack-tripleo-heat-templates/environments/services-docker ディレクトリーにあるデフォルトの neutron-opendaylight-dpdk.yaml 環境ファイルを使用します。
デフォルトのファイルには、以下の値が含まれています。
# A Heat environment that can be used to deploy OpenDaylight with L3 DVR and DPDK.
# This file is to be used with neutron-opendaylight.yaml
parameter_defaults:
NovaSchedulerDefaultFilters: "RamFilter,ComputeFilter,AvailabilityZoneFilter,ComputeCapabilitiesFilter,ImagePropertiesFilter,NUMATopologyFilter"
OpenDaylightSNATMechanism: 'controller'
ComputeOvsDpdkParameters:
OvsEnableDpdk: True
## Host configuration Parameters
#TunedProfileName: "cpu-partitioning"
#IsolCpusList: "" # Logical CPUs list to be isolated from the host process (applied via cpu-partitioning tuned).
# It is mandatory to provide isolated cpus for tuned to achive optimal performance.
# Example: "3-8,12-15,18"
#KernelArgs: "" # Space separated kernel args to configure hugepage and IOMMU.
# Deploying DPDK requires enabling hugepages for the overcloud compute nodes.
# It also requires enabling IOMMU when using the VFIO (vfio-pci) OvsDpdkDriverType.
# This should be done by configuring parameters via host-config-and-reboot.yaml environment file.
## Attempting to deploy DPDK without appropriate values for the below parameters may lead to unstable deployments
## due to CPU contention of DPDK PMD threads.
## It is highly recommended to to enable isolcpus (via KernelArgs) on compute overcloud nodes and set the following parameters:
#OvsDpdkSocketMemory: "" # Sets the amount of hugepage memory to assign per NUMA node.
# It is recommended to use the socket closest to the PCIe slot used for the
# desired DPDK NIC. Format should be comma separated per socket string such as:
# "<socket 0 mem MB>,<socket 1 mem MB>", for example: "1024,0".
#OvsDpdkDriverType: "vfio-pci" # Ensure the Overcloud NIC to be used for DPDK supports this UIO/PMD driver.
#OvsPmdCoreList: "" # List or range of CPU cores for PMD threads to be pinned to. Note, NIC
# location to cores on socket, number of hyper-threaded logical cores, and
# desired number of PMD threads can all play a role in configuring this setting.
# These cores should be on the same socket where OvsDpdkSocketMemory is assigned.
# If using hyperthreading then specify both logical cores that would equal the
# physical core. Also, specifying more than one core will trigger multiple PMD
# threads to be spawned, which may improve dataplane performance.
#NovaVcpuPinSet: "" # Cores to pin Nova instances to. For maximum performance, select cores
# on the same NUMA node(s) selected for previous settings.3.5.2. OVS-DPDK デプロイメントの設定
neutron-opendaylight-dpdk.yaml の値を変更して、OVS-DPDK サービスを設定することができます。
|
|
IRQ のピニングを有効化して、OVS-DPDK で使用する CPU コアから分離します。デフォルトプロファイル: |
|
|
CPU コアの一覧を指定し、カーネルスケジューラーがそれらのコアを使用しないようにして、代わりに OVS-DPDK に割り当てて専用にすることができます。書式は、個々のコアのコンマ区切りリストまたは範囲で指定します (例: |
|
|
ブート時にカーネルに渡す引数をリストします。OVS-DPDK の場合は、
---- 指定されている RAM の容量はヒュージページ用の 60 GB であることに注意してください。この値を設定する場合には、コンピュートノードで利用可能な RAM 容量を考慮することが重要です。 |
|
|
各 NUMA ノードに割り当てるヒュージページメモリーの容量を (MB 単位で) 指定します。パフォーマンスを最大限にするには、DPDK NIC に最も近いソケットにメモリーを割り当てます。ソケットあたりのメモリーをリストする形式は以下のようになります。 ---- "<socket 0 mem MB>,<socket 1 mem MB>" ---- 例: "1024,0" |
|
|
PMD スレッドで使用する UIO ドライバー種別を指定します。DPDK NIC は指定したドライバーをサポートしている必要があります。Red Hat OpenStack Platform のデプロイメントでは、 |
|
|
PMD スレッドのピニング先となる個々のコアまたは範囲をリストします。ここで指定するコアは、 |
|
|
ソケットあたりのメモリーチャネルの数を指定します。 |
|
|
libvirtd で nova インスタンスをピニングするコア。パフォーマンスを最適にするには、OVS PMD コアがピニングされているのと同じソケット上のコアを使用してください。 |
3.5.3. OVS-DPDK を実装する OpenDaylight のインストール
作業を開始する前に
- アンダークラウドをインストールします (「アンダークラウドのインストール」を参照)。
- オーバークラウドのコンテナーイメージへのリンクを記載した環境ファイルを作成します (「オーバークラウド用の OpenDaylight 環境ファイルの準備」を参照)。
- カスタムロールで SR-IOV 対応の OpenDaylight を設定するためのロールファイルを作成します (「OVS-DPDK デプロイメントファイルの準備」を参照)。
手順
- OpenDaylight で DPDK 機能を有効化するのに必要な環境ファイルを使用してデプロイメントコマンドを実行します。
$ openstack overcloud deploy --templates /usr/share/openstack-tripleo-heat-templates -e <other environment files> -e /usr/share/openstack-tripleo-heat-templates/environments/services-docker/neutron-opendaylight.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/services-docker/neutron-opendaylight-dpdk.yaml -e network-environment.yaml --compute-scale 1 --ntp-server 0.se.pool.ntp.org --control-flavor control --compute-flavor compute -r my_roles_data.yaml -e /home/stack/templates/docker-images.yaml -e /home/stack/templates/odl-images.yaml
デプロイのコマンドで先に指定する環境ファイルは、そのコマンドで後に指定する環境ファイルによって上書きされます。指定する環境ファイルの順序に注意を払って、パラメーターが誤って上書きされないようにする必要があります。
変更するパラメーターのみの設定する最小限の環境ファイルを作成して、デフォルトの環境ファイルと組み合わせることにより、一部のパラメーターを上書きすることができます。
3.5.4. 例: ODL と VXLAN トンネリングを使用する OVS-DPDK の設定
このセクションには、ODL と VXLAN トンネリングを使用する OVS-DPDKの設定例を記載しています。
OVS-DPDK 用の OpenStack を最適化するには、network-environment.yaml ファイルに設定する OVS-DPDK パラメーターの最適な値を判断する必要があります。詳しくは、「Deriving DPDK parameters with workflows」を参照してください。
3.5.4.1. ComputeOvsDpdk コンポーザブルロールの生成
ComputeOvsDpdk ロール用の roles_data.yaml を生成します。
# openstack overcloud roles generate --roles-path templates/openstack-tripleo-heat-templates/roles -o roles_data.yaml Controller ComputeOvsDpdk
3.5.4.2. CPU アフィニティー用の tuned 設定
tunedを設定して CPU フィニティーを有効にします。heat_template_version: 2014-10-16 description: > Example extra config for post-deployment parameters: servers: type: json DeployIdentifier: type: string default: '' resources: ExtraDeployments: type: OS::Heat::StructuredDeployments properties: servers: {get_param: servers} config: {get_resource: ExtraConfig} actions: ['CREATE','UPDATE'] input_values: deploy_identifier: {get_param: DeployIdentifier} ExtraConfig: type: OS::Heat::SoftwareConfig properties: group: script config: | #!/bin/bash set -x function tuned_service_dependency() { tuned_service=/usr/lib/systemd/system/tuned.service grep -q "network.target" $tuned_service if [ "$?" -eq 0 ]; then sed -i '/After=.*/s/network.target//g' $tuned_service fi grep -q "Before=.*network.target" $tuned_service if [ ! "$?" -eq 0 ]; then grep -q "Before=.*" $tuned_service if [ "$?" -eq 0 ]; then sed -i 's/^\(Before=.*\)/\1 network.target openvswitch.service/g' $tuned_service else sed -i '/After/i Before=network.target openvswitch.service' $tuned_service fi fi } if hiera -c /etc/puppet/hiera.yaml service_names | grep -q neutron_ovs_dpdk_agent; then tuned_service_dependency fi
3.5.4.3. OVS-DPDK パラメーターの設定
OVS-DPDK 向けの OpenStack ネットワークを最適化するには、network-environment.yaml で設定する OVS-DPDK パラメーターの最適な値を判断する必要があります。詳しくは、https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/13/html/network_functions_virtualization_planning_and_configuration_guide/part-dpdk-configure#proc_derive-dpdk を参照してください。
resource_registryの下に OVS-DPDK 用のカスタムリソースを追加します。resource_registry: # Specify the relative/absolute path to the config files you want to use for override the default. OS::TripleO::ComputeOvsDpdk::Net::SoftwareConfig: nic-configs/computeovsdpdk.yaml OS::TripleO::Controller::Net::SoftwareConfig: nic-configs/controller.yaml OS::TripleO::NodeExtraConfigPost: post-install.yamlparameter_defaultsの下で、トンネルの種別とテナントの種別をvxlanに設定します。NeutronTunnelTypes: 'vxlan' NeutronNetworkType: 'vxlan'
parameters_defaultsの下にブリッジのマッピングを設定します。# The OVS logical->physical bridge mappings to use. NeutronBridgeMappings: 'tenant:br-link0' OpenDaylightProviderMappings: 'tenant:br-link0'
parameter_defaultsの下に、ComputeOvsDpdkロール向けのロール固有パラメーターを設定します。########################## # OVS DPDK configuration # ########################## ComputeOvsDpdkParameters: KernelArgs: "default_hugepagesz=1GB hugepagesz=1G hugepages=32 iommu=pt intel_iommu=on isolcpus=2-19,22-39" TunedProfileName: "cpu-partitioning" IsolCpusList: "2-19,22-39" NovaVcpuPinSet: ['4-19,24-39'] NovaReservedHostMemory: 4096 OvsDpdkSocketMemory: "4096,4096" OvsDpdkMemoryChannels: "4" OvsDpdkCoreList: "0,20,1,21" OvsPmdCoreList: "2,22,3,23" OvsEnableDpdk: true注記ゲストインスタンス作成の失敗を避けるために、DPDK PMD 用の DPDK NIC の有無にかかわらず、各 NUMA ノード上で (シブリングスレッドを使用して) 少なくとも 1 つのCPUを割り当てる必要があります。
注記本手順に示したとおり、これらのヒュージページは仮想マシンと、
OvsDpdkSocketMemoryパラメーターを使用する OVS-DPDK によって消費されます。仮想マシンが利用可能なヒュージページの数は、bootパラメーターからOvsDpdkSocketMemoryを減算した値です。DPDK インスタンスに関連付けるフレーバーに
hw:mem_page_size=1GBを追加する必要もあります。注記OvsDPDKCoreListとOvsDpdkMemoryChannelsは、この手順では 必須 の設定です。適切な値を設定せずに DPDK のデプロイメントを試みると、デプロイメントが失敗したり、不安定なデプロイメントになったりします。
3.5.4.4. コントローラーノードの設定
分離ネットワーク用のコントロールプレーンの Linux ボンディングを作成します。
- type: linux_bond name: bond_api bonding_options: "mode=active-backup" use_dhcp: false dns_servers: get_param: DnsServers addresses: - ip_netmask: list_join: - / - - get_param: ControlPlaneIp - get_param: ControlPlaneSubnetCidr routes: - ip_netmask: 169.254.169.254/32 next_hop: get_param: EC2MetadataIp members: - type: interface name: eth1 primary: trueこの Linux ボンディングに VLAN を割り当てます。
- type: vlan vlan_id: get_param: InternalApiNetworkVlanID device: bond_api addresses: - ip_netmask: get_param: InternalApiIpSubnet - type: vlan vlan_id: get_param: StorageNetworkVlanID device: bond_api addresses: - ip_netmask: get_param: StorageIpSubnet - type: vlan vlan_id: get_param: StorageMgmtNetworkVlanID device: bond_api addresses: - ip_netmask: get_param: StorageMgmtIpSubnet - type: vlan vlan_id: get_param: ExternalNetworkVlanID device: bond_api addresses: - ip_netmask: get_param: ExternalIpSubnet routes: - default: true next_hop: get_param: ExternalInterfaceDefaultRouteクラウドネットワークへの Floating IPアドレスにアクセスするための OVS ブリッジを作成します。
- type: ovs_bridge name: br-link0 use_dhcp: false mtu: 9000 members: - type: interface name: eth2 mtu: 9000 - type: vlan vlan_id: get_param: TenantNetworkVlanID mtu: 9000 addresses: - ip_netmask: get_param: TenantIpSubnet
3.5.4.5. DPDK インターフェースのコンピュートノードの設定
デフォルトの compute.yaml ファイルから compute-ovs-dpdk.yaml ファイルを作成し、次のように変更します。
分離ネットワーク用のコントロールプレーンの Linux ボンディングを作成します。
- type: linux_bond name: bond_api bonding_options: "mode=active-backup" use_dhcp: false dns_servers: get_param: DnsServers members: - type: interface name: nic7 primary: true - type: interface name: nic8この Linux ボンディングに VLAN を割り当てます。
- type: vlan vlan_id: get_param: InternalApiNetworkVlanID device: bond_api addresses: - ip_netmask: get_param: InternalApiIpSubnet - type: vlan vlan_id: get_param: StorageNetworkVlanID device: bond_api addresses: - ip_netmask: get_param: StorageIpSubnetコントローラーにリンクする DPDK ポートを備えたブリッジを設定します。
- type: ovs_user_bridge name: br-link0 use_dhcp: false ovs_extra: - str_replace: template: set port br-link0 tag=_VLAN_TAG_ params: _VLAN_TAG_: get_param: TenantNetworkVlanID addresses: - ip_netmask: get_param: TenantIpSubnet members: - type: ovs_dpdk_bond name: dpdkbond0 mtu: 9000 rx_queue: 2 members: - type: ovs_dpdk_port name: dpdk0 members: - type: interface name: nic3 - type: ovs_dpdk_port name: dpdk1 members: - type: interface name: nic4注記複数の DPDK デバイスを含めるには、追加する DPDK デバイスごとに
typeのコードセクションを繰り返します。注記OVS-DPDK を使用する場合には、同じコンピュートノード上の 全 ブリッジが
ovs_user_bridgeの種別である必要があります。同じノード上でovs_bridgeとovs_user_bridgeが混在する構成は、director では受け入れ可能ですが、Red Hat OpenStack Platform ではサポートされていません。
3.5.4.6. オーバークラウドのデプロイ
overcloud_deploy.sh スクリプトを実行してオーバークラウドをデプロイします。
#!/bin/bash openstack overcloud deploy \ --templates \ -r /home/stack/ospd-13-vxlan-dpdk-odl-ctlplane-dataplane-bonding-hybrid/roles_data.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/host-config-and-reboot.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/services-docker/neutron-opendaylight.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/services-docker/neutron-opendaylight-dpdk.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/ovs-dpdk-permissions.yaml \ -e /home/stack/ospd-13-vxlan-dpdk-odl-ctlplane-dataplane-bonding-hybrid/docker-images.yaml \ -e /home/stack/ospd-13-vxlan-dpdk-odl-ctlplane-dataplane-bonding-hybrid/network-environment.yaml
3.6. L2GW 対応の OpenDaylight のインストール
この機能は、本リリースでは テクノロジープレビュー として提供しているため、Red Hat では全面的にはサポートしていません。これは、テスト目的のみでご利用いただく機能で、実稼働環境にデプロイすべきではありません。テクノロジープレビューについての詳しい情報は「対象範囲の詳細」を参照してください。
レイヤー 2 ゲートウェイサービスにより、テナントの仮想ネットワークを物理ネットワークにブリッジングすることができます。この統合により、ルーティングされたレイヤー 3 の接続ではなく、レイヤー 2 のネットワーク接続で物理サーバー上のリソースにアクセスすることができます。これは、L3 や Floating IP を経由する代わりにレイヤー 2 のブロードキャストドメインを拡張することを意味します。
3.6.1. L2GW デプロイメントファイルの準備
L2GW 対応の OpenDaylight をデプロイするには、 /usr/share/openstack-tripleo-heat-templates/environments ディレクトリー内の neutron-l2gw-opendaylight.yaml ファイルを使用します。このファイル内の設定を変更する必要がある場合には、既存のファイルを変更する代わりに、この環境ファイルの必要なパラメーターが含まれたコピーを新規作成してください。
OpenDaylight と L2GW をデフォルトの設定でデプロイする場合には、/usr/share/openstack-tripleo-heat-templates/environments/services-docker ディレクトリーの neutron-l2gw-opendaylight.yaml を使用することができます。
デフォルトのファイルには、以下の値が含まれています。
# A Heat environment file that can be used to deploy Neutron L2 Gateway service # # Currently there are only two service provider for Neutron L2 Gateway # This file enables L2GW service with OpenDaylight as driver. # # - OpenDaylight: L2GW:OpenDaylight:networking_odl.l2gateway.driver.OpenDaylightL2gwDriver:default resource_registry: OS::TripleO::Services::NeutronL2gwApi: ../../docker/services/neutron-l2gw-api.yaml parameter_defaults: NeutronServicePlugins: "odl-router_v2,trunk,l2gw" L2gwServiceProvider: ['L2GW:OpenDaylight:networking_odl.l2gateway.driver.OpenDaylightL2gwDriver:default'] # Optional # L2gwServiceDefaultInterfaceName: "FortyGigE1/0/1" # L2gwServiceDefaultDeviceName: "Switch1" # L2gwServiceQuotaL2Gateway: 10 # L2gwServicePeriodicMonitoringInterval: 5
3.6.2. OpenDaylight L2GW デプロイメントの設定
neutron-l2gw-opendaylight.yamlファイルの値を変更して、サービスを設定することができます。
|
|
サービスプラグインのエントリーポイントのコンマ区切りリストは、 |
|
|
このサービスを提供するのに使用する必要のあるプロバイダーを定義します。デフォルトは |
|
|
デフォルトのインターフェースの名前を設定します。 |
|
|
デフォルトのデバイスの名前を設定します。 |
|
|
L2 ゲートウェイ用のサービスクォータを指定します。デフォルトは |
|
|
L2GW サービスのモニタリング間隔を指定します。 |
3.6.3. L2GW を実装する OpenDaylight のインストール
作業を開始する前に
- アンダークラウドをインストールします (「アンダークラウドのインストール」を参照)。
- オーバークラウドのコンテナーイメージへのリンクを記載した環境ファイルを作成します (「オーバークラウド用の OpenDaylight 環境ファイルの準備」を参照)。
- SR-IOV 対応のカスタムロールで OpenDaylight を設定するためのロールファイルを作成します (「L2GW デプロイメントファイルの準備」を参照)。
手順
- OpenDaylight で L2GW 機能を有効化するのに必要な環境ファイルを使用してデプロイメントコマンドを実行します。
$ openstack overcloud deploy --templates /usr/share/openstack-tripleo-heat-templates -e <other environment files> -e /usr/share/openstack-tripleo-heat-templates/environments/services-docker/neutron-opendaylight.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/services-docker/neutron-l2gw-opendaylight.yaml -e /home/stack/templates/docker-images.yaml -e /home/stack/templates/odl-images.yaml
デプロイのコマンドで先に指定する環境ファイルは、そのコマンドで後に指定する環境ファイルによって上書きされます。指定する環境ファイルの順序に注意を払って、パラメーターが誤って上書きされないようにする必要があります。
変更するパラメーターのみの設定する最小限の環境ファイルを作成して、デフォルトの環境ファイルと組み合わせることにより、一部のパラメーターを上書きすることができます。

Where did the comment section go?
Red Hat's documentation publication system recently went through an upgrade to enable speedier, more mobile-friendly content. We decided to re-evaluate our commenting platform to ensure that it meets your expectations and serves as an optimal feedback mechanism. During this redesign, we invite your input on providing feedback on Red Hat documentation via the discussion platform.