Red Hat Training

A Red Hat training course is available for Red Hat OpenStack Platform

Red Hat OpenDaylight のインストールおよび設定ガイド

Red Hat OpenStack Platform 12

Red Hat OpenStack Platform を使用した OpenDaylight のインストールと設定

OpenStack Documentation Team

概要

本ガイドでは、Red Hat OpenDaylight のインストールと設定について説明します。

前書き

本書では、OpenDaylight のソフトウェア定義ネットワーク (SDN) コントローラーを使用するように Red Hat OpenStack Platform 12 をデプロイする方法について説明します。OpenDaylight コントローラーは、neutron ML2/OVS プラグインと、その L2 エージェントおよび L3 エージェントと互換性があり、簡単に置き換えることができます。OpenDaylight は、Red Hat OpenStack 環境内でネットワークの仮想化を提供します。

第1章 概要

1.1. OpenDaylight とは

OpenDaylight プラットフォームは、Java で書かれたプログラミング可能な SDN コントローラーで、OpenStack 環境のネットワーク仮想化に使用することができます。コントローラーのアーキテクチャーは、ノースバウンドとサウスバウンドの別々のインターフェースで構成されます。OpenStack の統合の目的においては、メインのノースバウンドインターフェースは NeutronNorthbound プロジェクトを使用します。これは、OpenStack Networking サービス (neutron) と通信します。サウスバウンドの OpenDaylight プロジェクト、OVSDB、および OpenFlow プラグインは Open vSwitch (OVS) コントロールおよびデータプレーンと通信します。neutron の設定をネットワーク仮想化に変換するメインの OpenDaylight プロジェクトは、NetVirt プロジェクトです。

1.2. OpenStack での OpenDaylight の機能

1.2.1. デフォルトの neutron アーキテクチャー

neutron のリファレンスアーキテクチャーでは、一式のエージェントを使用してOpenStack 内のネットワークを管理します。これらのエージェントは、neutron に異なるプラグインとして提供されます。コアプラグインは、レイヤー 2 のオーバーレイテクノロジーとデータプレーンの種別の管理に使用されます。サービスプラグインは、レイヤー 3 または OSI モデルのより上位の層でのネットワーク操作 (例: ファイアウォール、DHCP、ルーティング、NAT) の管理に使用されます。

デフォルトでは、Red Hat OpenStack Platform は Modular Layer 2 (ML2) のコアプラグインを OVS メカニズムドライバーと共に使用します。これは、各コンピュートノードとコントローラーノードで OVS を設定するためのエージェントを提供します。サービスプラグイン、DHCP エージェント、メタデータエージェントは、L3 エージェントと共にコントローラー上で実行されます。

1.2.2. OpenDaylight をベースとするネットワークアーキテクチャー

OpenDaylight は、networking-odl と呼ばれる独自のドライバーを提供することにより、ML2 コアプラグインと統合します。これにより、全ノードで OVS エージェントを使用する必要がなくなります。OpenDaylight は、個別のノードにエージェントを使用せずに、環境全体にわたる各 OVS インスタンスを直接プログラミングすることができます。レイヤー 3 のサービスの場合は、neutron が OpenDaylight L3 プラグインを使用するように設定されます。この方法を使用すると、データプレーンを直接プログラミングして、OpenDaylight が分散仮想ルーティング機能を処理できるため、ルーティングやネットワークアドレス変換 (NAT) を処理する複数のノード上のエージェントの数が削減されます。neutron DHCP およびメタデータエージェントは引き続き、DHCP とメタデータ (cloud-init) の要求の管理に使用されます。

注記

OpenDaylight は DHCP サービスを提供できますが、現行の Red Hat OpenStack Platform director アーキテクチャーをデプロイする場合には、neutron DHCP エージェントを使用すると高可用性 (HA) と仮想マシン (VM) インスタンスのメタデータ (cloud-init) のサポートが提供されるため、Red Hat では DHCP サービスの機能は OpenDaylight に依存せずに neutron DHCP エージェントをデプロイすることを推奨しています。

1.3. Red Hat OpenStack Platform director とその設計について

Red Hat OpenStack Platform director は完全な OpenStack 環境をインストールおよび管理するためのツールセットです。これは、主に TripleO (OpenStack-On-OpenStack) プロジェクトをベースとしています。

このプロジェクトは OpenStack コンポーネントを使用して、完全に機能する OpenStack 環境をインストールします。また、OpenStack ノードとして機能するベアメタルシステムのプロビジョニングと制御を行う新たな OpenStack コンポーネントも含まれています。この方法で、リーンで、かつ堅牢性の高い、完全な Red Hat OpenStack Platform 環境をインストールすることができます。

Red Hat OpenStack Platform director では、アンダークラウドオーバークラウド の 2 つの主要な概念を採用しています。アンダークラウドは、オーバークラウドのインストールと設定を行います。Red Hat OpenStack Platform director のアーキテクチャーに関する詳しい情報は、『director のインストールと使用方法』ガイドを参照してください。

図1.1 Red Hat OpenStack Platform director: アンダークラウドとオーバークラウド

OpenStack Platform director

1.3.1. Red Hat OpenStack Platform director と OpenDaylight

Red Hat OpenStack Platform director では、コンポーザブルサービスとカスタムロールの概念が導入されています。これにより、必要な場合にロールごとに追加/有効化することができる孤立したリソースが形成されます。カスタムロールにより、ユーザーはデフォルトの Controller / Compute ロールに依存しない、独自のロールを作成することができます。つまり、ユーザーは、デプロイする OpenStack サービスと、それらのサービスをホストするノードを選択できます。

OpenDaylight を director に統合するために、2 つのサービスが追加されました。

  • OpenDaylight SDN コントローラーを実行するための OpenDaylightApi サービス
  • 各ノードで OVS を設定して OpenDaylight と適切に通信するための OpenDaylightOvs サービス

デフォルトでは、OpenDaylightApi サービスは Controller ロール上で実行するように設定される一方、OpenDaylightOvs サービスは Controller ロールと Compute ロールで実行されるように設定されます。OpenDaylight は、OpenDaylightApi サービスインスタンスの数を 3 からスケーリングすることによって 高可用性 (HA) を提供します。デフォルトでは、Controller を 3 つ以上にスケーリングすると、HA が自動的に有効化されます。OpenDaylight の HA アーキテクチャーに関する詳しい情報は、「OpenDaylight での高可用性とクラスタリング」を参照してください。

図1.2 OpenDaylight and OpenStack: ベースアーキテクチャー

OpenStack and OpenDaylight Architecture

1.3.2. Red Hat OpenStack Platform director でのネットワーク分離

Red Hat OpenStack Platform director は、個別のサービスを特定の事前定義済みのネットワーク種別に設定することができます。このネットワークトラフィック種別には以下が含まれます。

IPMI

ノードの電源管理に使用されるネットワーク。このネットワークは、アンダークラウドをインストールする前に設定しておく必要があります。

Provisioning (ctlplane)

director はこのネットワークトラフィック種別を使用して、 DHCP および PXE ブートで新規ノードをデプロイし、オーバークラウドのベアメタルサーバー上で OpenStack Platform のインストールをオーケストレーションします。ネットワークは、アンダークラウドのインストール前に設定する必要があります。または、ironic でオペレーティングシステムのイメージを直接デプロイすることができます。その場合には、PXE ブートは必要ではありません。

Internal API (internal_api)

Internal API ネットワークは、API 通信を使用した OpenStack サービス間の通信、RPC メッセージ、データベース通信やロードバランサーの背後の内部通信に使用されます。

Tenant (tenant)

neutron は VLAN (各テナントネットワークがネットワーク VLAN) またはオーバーレイトンネルを使用して各テナントに独自のネットワークを提供します。ネットワークは、各テナントネットワーク内で分離されます。トンネリングを使用する場合には、競合は発生することなく、複数のテナントネットワークで同じ IP アドレス範囲を使用することができます。

注記

Generic Routing Encapsulation (GRE) および Virtual eXtensible Local Area Network (VXLAN) は両方ともコードベースで利用可能ですが、 OpenDaylight で推奨されるトンネリングプロトコルは VXLAN です。VXLAN の定義は RFC 7348 に記載されています。本書では、これ以降、トンネリングが使用される場合にはいずれも VXLAN を中心とします。

Storage (storage)

Block Storage、NFS、iSCSI など。理想的には、これはパフォーマンス上の理由から、完全に別のスイッチファブリックに分離した方がよいでしょう。

Storage Management (storage_mgmt)

OpenStack Object Storage (swift) は、参加するレプリカノード間でデータオブジェクトを同期するためにこのネットワークを使用します。プロキシーサービスは、ユーザー要求と基盤となるストレージ層の間の仲介インターフェースとして機能します。プロキシーは、受信要求を受け取り、必要なレプリカの位置を特定して要求データを取得します。Ceph バックエンドを使用するサービスは、Ceph と直接対話せずにフロントエンドのサービスを使用するため、ストレージ管理ネットワーク経由で接続を確立します。RBD ドライバーは例外で、このトラフィックは直接 Ceph に接続する点に注意してください。

External/Public API

この API は、グラフィカルシステム管理用の OpenStack Dashboard (Horizon)、OpenStack サービス用のパブリック API をホストして、インスタンスへの受信トラフィック向けに SNAT を実行します。外部ネットワークがプライベート IP アドレスを使用する場合には (RFC-1918 に準拠)、インターネットからのトラフィックに対して、さらに NAT を実行する必要があります。

Floating IP

テナントネットワーク内のインスタンスに割り当てられた Floating IP アドレスと Fixed IP アドレスとの間の 1 対 1 の IPv4 アドレスマッピングを使用して、受信トラフィックがインスタンスに到達できるようにします。外部と Floating IP ネットワークは、別々に維持管理するのではなく、組み合わせるのが一般的な設定です。

Management

SSH アクセス、DNS トラフィック、NTP トラフィックなどのシステム管理機能を提供します。このネットワークは、コントローラー以外のノード用のゲートウェイとしても機能します。

一般的な Red Hat OpenStack Platform のシステム環境では通常、ネットワーク種別の数は物理ネットワークのリンク数を超えます。全ネットワークを正しいホストに接続するには、オーバークラウドは 802.1q VLAN タグ付けを使用して、1 つのインターフェースに複数のネットワークを提供することができます。ネットワークの多くは、サブネットが分離されていますが、インターネットアクセスまたはインフラストラクチャーにネットワーク接続ができるようにルーティングを提供する レイヤー 3 ゲートウェイが必要です。

OpenDaylight の場合は、関連するネットワークには Internal APITenantExternal のサービスが含まれ、それらは ServiceNetMap 内の各ネットワークにマッピングされます。デフォルトでは、ServiceNetMap により OpenDaylightApi ネットワークが Internal API ネットワークにマッピングされます。この設定は、neutron へのノースバウンドトラフィックと OVS へのサウスバウンドトラフィックが Internal API ネットワークに分離されることを意味します。

OpenDaylight は分散ルーティングアーキテクチャーを使用するので、各コンピュートノードが Floating IP ネットワークに接続されている必要があります。デフォルトでは、Red Hat OpenStack Platform director は External ネットワークが OVS ブリッジ br-ex にマッピングされた neutron の物理ネットワーク datacentre で実行されることを想定します。そのため、コンピュートノードの NIC テンプレートでは、デフォルトの設定に br-ex を含める必要があります。

図1.3 OpenDaylight と OpenStack: ネットワーク分離の例

OpenStack and OpenDaylight Network Isolation

1.3.3. ネットワークとファイアウォールの設定

ファイアウォールが厳しく制約されている場合など、一部のデプロイメントでは、OpenDaylight サービスのトラフィックを有効にするためにファイアウォールを手動で設定する必要のある場合があります。

デフォルトでは、OpenDaylight のノースバウンドは 80808181 ポートを使用します。swift サービスも 8080 を使用するので、競合しないようにするには、Red Hat OpenStack Platform director でインストールを行う際に OpenDaylight ポートは 80818181 に設定されます。Red Hat OpenDaylight ソリューションでは、サウスバウンドは OVS インスタンスが通常接続するポート 66406653 でリッスンするように設定されます。

OpenStack では、通常、各サービスに独自の仮想 IP アドレス (VIP) があり、OpenDaylight も同様に動作します。HAProxy8081 ポートをパブリックに公開し、OpenStack にすでに存在するプレーンの仮想 IP を制御するように設定されます。VIP とポートは、 ML2 プラグインに提供され、 neutron はそのポートを介してすべての通信を行います。OVS インスタンスは、OpenDaylight がサウスバウンド用に実行しているノードの物理 IP に直接接続します。

サービスプロトコルデフォルトのポートネットワーク

OpenStack Neutron API

TCP

9696

Internal API

OpenStack Neutron API (SSL)

TCP

13696

Internal API

OpenDaylight ノースバウンド

TCP

8081、8181

Internal API

OpenDaylight サウスバウンド: OVSDB

TCP

6640

Internal API

OpenDaylight サウスバウンド: OpenFlow

TCP

6653

Internal API

OpenDaylight 高可用性

TCP

2550

Internal API

OpenDaylight HA: Akka

TCP

2550

Internal API

VXLAN

UDP

4789

Tenant

表 1: ネットワークとファイアウォールの設定

注記

前項では、OpenDaylight の統合に関連したサービスとプロトコルを中心とする情報を記載していますが、すべては網羅していません。Red Hat OpenStack で実行するサービスに必要なネットワークポートの全一覧は、『Firewall Rules for Red Hat OpenStack Platform』ガイドを参照してください。

第2章 OpenDaylight を実行するための要件

以下の項には、OpenDaylight を使用するオーバークラウドのデプロイに必要な要件の一覧を記載します。Red Hat OpenDaylight を正しくインストールして実行するには、十分なコンピューティングリソースが必要です。以下に最小要件を示します。

2.1. コンピュートノードの要件

コンピュートノードは、仮想マシンインスタンスが起動した後にそれらを稼働させる役割を果たします。全コンピュートノードが、ハードウェアの仮想化をサポートしている必要があります。また、ホストする仮想マシンインスタンスの要件をサポートするのに十分なメモリーとディスク容量も必要です。

プロセッサー

Intel 64 または AMD64 CPU 拡張機能をサポートする 64 ビットのプロセッサーで Intel VT または AMD-V のハードウェア仮想化拡張機能が有効化されていること。このプロセッサーには最小でも 4 つのコアが搭載されていることを推奨しています。

メモリー

最小で 6 GB のメモリー。これに、仮想マシンインスタンスに割り当てるメモリー容量に基づいて、追加の RAM を加算します。

ディスク容量

最小 40 GB の空きディスク領域

ネットワークインターフェースカード

最小 1 枚の 1 Gbps ネットワークインターフェースカード (実稼働環境では最低でも NIC を 2 枚使用することを推奨)。ボンディングインターフェース向けの場合や、タグ付けされた VLAN トラフィックを委譲する場合には追加のネットワークインターフェースを使用します。詳しくは、Red Hat OpenStack Platform でサポートされている NIC の一覧 を参照してください。

電源管理

各コントローラーノードには、Intelligent Platform Management Interface (IPMI) 機能などのサポート対象の電源管理インターフェースがサーバーのマザーボードに搭載されている必要があります。

2.2. コントローラーノードの要件

コントローラーノードは、Red Hat OpenStack Platform 環境の中核となるサービス (例: Horizon Dashboard、バックエンドのデータベースサーバー、Keystone 認証、高可用性サービスなど) をホストする役割を果たします。

プロセッサー

Intel 64 または AMD64 CPU 拡張機能をサポートする 64 ビットのプロセッサー

メモリー

最小のメモリー容量は 20 GB です。推奨のメモリー容量は、CPU のコア数により異なります。以下の計算を参考にしてください。

コントローラーの最小 RAM の計算: 1 コアあたり 1.5 GB のメモリーを使用します。たとえば、コアが 48 個あるマシンには、72 GB の RAM が必要です。

コントローラーの 推奨 RAM の計算: 1 コアあたり 3 GB のメモリーを使用します。たとえば、コアが 48 個あるマシンには、144 GB の RAM が必要です。必要なメモリーの算出についての詳しい情報は、Red Hat カスタマーポータルで 「Red Hat OpenStack Platform Hardware Requirements for Highly Available Controllers」を参照してください。

ディスク容量

最小 40 GB の空きディスク領域

ネットワークインターフェースカード

最小 2 枚の 1 Gbps ネットワークインターフェースカード。タグ付けされた VLAN トラフィックを委譲する場合や、ボンディングインターフェース向けの場合には追加のネットワークインターフェースを使用します。

電源管理

各コントローラーノードには、Intelligent Platform Management Interface (IPMI) 機能などのサポート対象の電源管理インターフェースがサーバーのマザーボードに搭載されている必要があります。

第3章 オーバークラウドへの OpenDaylight のインストール

本ガイドには、OpenDaylight のインストールを中心とした内容を記載しています。OpenDaylight をデプロイする前には、アンダークラウド環境が正常に機能しており、オーバークラウドノードが物理ネットワークに接続されていることを確認する必要があります。

『director のインストールと使用方法』で、アンダークラウドとオーバークラウドのデプロイに必要な手順を説明している「アンダークラウドのインストール」および「CLI ツールを使用した基本的なオーバークラウドの設定」の項を参照してください。

Red Hat OpenStack platform で OpenDaylight をインストールするには、いくつかの方法があります。次の章では、OpenDaylight の最も役立つシナリオとインストールの方法を紹介します。

3.1. デフォルトの設定と設定値のカスタマイズ

OpenDaylight のインストールの推奨される方法は、デフォルトの環境ファイル neutron-opendaylight.yaml を使用して、そのファイルをアンダークラウドでデプロイメントコマンドに引数として渡す方法です。これにより、OpenDaylight のデフォルトのインストール環境がデプロイされます。

OpenDaylight インストールと設定のその他のシナリオは、このインストールの方法をベースとしています。基本的には、デプロイメントコマンドに特定の環境ファイルを指定するだけで、さまざまな異なるシナリオで OpenDaylight をデプロイすることができます。

3.1.1. デフォルトの環境ファイルについての理解

デフォルトの環境ファイルは neutron-opendaylight.yaml という名前で、/usr/share/openstack-tripleo-heat-templates/environments/services-docker/ ディレクトリーにあります。このファイルで、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'

Red Hat OpenStack Platform director では、resource_registry は、デプロイメントのリソースを対応するリソース定義の yaml ファイルにマッピングするのに使用されます。サービスは、マッピング可能なリソースの一種です。特定のサービスを無効にする必要がある場合には、OS::Heat::None オプションに値を設定すると、そのサービスは、OpenDaylight 環境では使用されなくなります。デフォルトファイルには、OpenDaylightApi および OpenDaylightOvs のサービスが有効化されていますが、デフォルトの neutron エージェントの機能は OpenDaylight が取って代わるため、明示的に無効化されています。

Heat パラメーターは、director を使用したデプロイメントの設定値を設定するために使用されます。デフォルト値を上書きするには、環境ファイルの parameter_defaults セクションを使用してください。

上記の例では、NeutronEnableForceMetadataNeutronMechanismDriversNeutronServicePlugins のパラメーターは、OpenDaylight を有効化するように設定しています。

注記

その他のサービスとそれらの設定オプションは、本書の後半に記載しています。

3.1.2. OpenDaylight API サービスの設定

/usr/share/openstack-tripleo-heat-templates/puppet/services ディレクトリーにある opendaylight-api.yaml ファイルで保存されているデフォルト値を変更して、必要に応じて OpenDaylight API サービスを設定することができます。ただし、このファイルの設定は決して直接変更すべきではありません。このファイルはフォールバックする場合の解決方法として保管しておくのが賢明なので、この環境ファイルのコピーを作成して parameter_defaults セクション内の必要な値を設定した方がよいでしょう。これは後でデプロイメントのコマンドで渡します。

注記

デプロイメントのコマンドでは、前述した環境ファイルで指定されている全設定が、後に示す環境ファイルの設定に置き換えられます。このため、環境ファイルの順番は重要で、注意を払う必要があります。

3.1.2.1. 設定可能なオプション

OpenDaylight API サービス の設定時には、複数のパラメーターを設定することができます。

OpenDaylightPort

ノースバウンドの通信に使用するポートを設定します。デフォルトは 8081 です。

OpenDaylightUsername

OpenDaylight のログインユーザー名を設定します。デフォルトは admin です。

OpenDaylightPassword

OpenDaylight のログインパスワードを設定します。デフォルトは admin です。

OpenDaylightEnableDHCP

OpenDaylight を有効化して、DHCP サービスとして機能するようにします。デフォルトは false です。

OpenDaylightFeatures

OpenDaylight で起動する機能のコンマ区切りリスト。デフォルトは [odl-netvirt-openstack, odl-netvirt-ui, odl-jolokia] です。

OpenDaylightConnectionProtocol

REST のアクセスに使用する L7 プロトコルを設定します。デフォルトは http です。

OpenDaylightManageRepositories

OpenDaylight リポジトリーを管理するかどうかを設定します。デフォルトは false です。

OpenDaylightSNATMechanism

OpenDaylight が SNAT メカニズムを使用するように設定します。conntrackcontroller のいずれかを選択することができます。デフォルト値は conntrack です。

3.1.3. OpenDaylight OVS サービスの設定

OpenDaylight OVS サービス は、/usr/share/openstack-tripleo-heat-templates/puppet/services ディレクトリーにある opendaylight-ovs.yaml ファイルでパラメーターとデフォルト値を参照することによって設定することができます。ただし、このファイルディレクトリーの設定は決して変更すべきではありません。このファイルはフォールバックする場合の解決方法として保管しておくのが賢明なので、この環境ファイルのコピーを作成して parameter_defaultsセクション内の必要な値を設定した方がよいでしょう。これは後でデプロイメントのコマンドで渡します。

注記

デプロイメントのコマンドでは、前述した環境ファイルで指定されている全設定が、後に示す環境ファイルの設定に置き換えられます。このため、環境ファイルの順番は重要で、注意を払う必要があります。

3.1.3.1. 設定可能なオプション

OpenDaylight OVS サービス の設定時には、複数のパラメーターを指定することができます。

OpenDaylightPort

OpenDaylight へのノースバウンドの通信に使用するポートを設定します。デフォルトは 8081 です。OVS サービスはノースバウンドで OpenDaylight に対してクエリーを実行し、接続の前に完全に稼動状態であることを確認します。

OpenDaylightConnectionProtocol

REST アクセスに使用するレイヤー 7 プロトコル。デフォルトは http です。現在 OpenDaylight でサポートされているプロトコルは http のみとなっています。

OpenDaylightCheckURL

OVS が接続する前に OpenDaylight が完全に稼働していることを確認するのに使用する URL。デフォルトは restconf/operational/network-topology:network-topology/topology/netvirt:1 です。

OpenDaylightProviderMappings

論理ネットワークと物理インターフェースの間のマッピングのコンマ区切りリスト。この設定は、VLAN デプロイメントに必要です。デフォルトは datacentre:br-ex です。

Username

OpenDaylight OVS サービスのカスタムユーザー名を設定可能にします。

Password

OpenDaylight OVS サービスのカスタムパスワードを設定可能にします。

HostAllowedNetworkTypes

この OVS ホストに許可されているネットワーク種別。nova インスタンスとネットワークのスケジュール先となるホストを制限するために、ホストまたはロールによって異なる場合があります。デフォルトは ['local', 'vlan', 'vxlan', 'gre'] です。

OvsEnableDpdk

OVS で DPDK を有効化するかどうかを選択します。デフォルト値は false です。

OvsVhostuserMode

vhostuser ポート作成での OVS のモードを指定します。クライアントモードでは、ハイパーバイザーが vhostuser ソケットを作成する役割を果たします。サーバーモードでは、OVS が vhostuser を作成します。デフォルト値は client です。

VhostuserSocketDir

vhostuser ソケットを使用するディレクトリーを指定します。デフォルト値は /var/run/openvswitch です。

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 プラグインは、これらのノードに対して分散ルーティングを使用するので、Controller ロールの 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 環境ファイルの準備

作業を開始する前に

手順

  1. アンダークラウドにログオンして、admin の認証情報を読み込みます。

    $ source ~/stackrc
  2. オーバークラウドのインストールに使用される docker コンテナーイメージへの参照が記載されたレジストリーファイル docker-images.yaml を作成します。

    $ openstack overcloud container image prepare --pull-source registry.access.redhat.com --namespace rhosp12 \
     --prefix=openstack- --suffix=-docker --tag latest \
     -e /usr/share/openstack-tripleo-heat-templates/environments/docker.yaml \
     --env-file /home/stack/templates/docker-images.yaml
  3. OpenDaylight インストール用の docker コンテナーイメージへの参照が記載されたレジストリーファイル odl-images.yaml を作成します。

    $ openstack overcloud container image prepare --pull-source registry.access.redhat.com --namespace rhosp12  \
     --prefix=openstack- --suffix=-docker --tag latest \
     -e /usr/share/openstack-tripleo-heat-templates/environments/services-docker/neutron-opendaylight.yaml \
     --env-file /home/stack/templates/odl-images.yaml
  4. オーバークラウドをデプロイするための環境の作成が正常に完了し、「OpenDaylight を実装するオーバークラウドのインストール」に記載のインストールを開始する準備が整いました。

詳細情報

openstack overcloud image prepare コマンドは、オーバークラウドと OpenDaylight のインストール用のコンテナーイメージ環境ファイルを準備します。このコマンドでは、以下のオプションを使用します。

-e
OpenDaylight、OVS など、その環境に必要な特定のコンテナーイメージを追加するためのサービス環境ファイルを指定します。
--env-file
インストールに使用されるコンテナーイメージの一覧を記載した新規コンテナーイメージの環境ファイルを作成します。
--pull-source
Docker コンテナーレジストリーの場所を設定します。
--namespace
Docker コンテナーのバージョンを設定します。
--prefix
イメージ名にプレフィックスを追加します。
--suffix
イメージ名にサフィックスを追加します。
--tag
イメージのリリースを定義します。

3.2.2. OpenDaylight を実装するオーバークラウドのインストール

作業を開始する前に

手順

  1. アンダークラウドにログオンして、admin の認証情報を読み込みます。

    $ source ~/stackrc
  2. 事前に作成した環境ファイルを使用してオーバークラウドをデプロイします。

    $ 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 /home/stack/templates/docker-images.yaml \
     -e /home/stack/templates/odl-images.yaml
     -e <other needed environment files>
注記

複数の環境ファイルで同じパラメーターが記述されている場合には、先に適用される環境ファイルの設定は、後で適用される環境ファイルによって上書きされます。パラメーターが誤って設定されるのを防ぐために、環境ファイルの指定順序には注意を払う必要があります。

ヒント

変更するパラメーターのみを設定する最小限の環境ファイルを作成して、デフォルトの環境ファイルと組み合わせることにより、一部のパラメーターは簡単に上書きすることができます。

詳細情報

オーバークラウドと OpenDaylight をデプロイする上記の openstack overcloud deploy コマンドには、以下のオプションを使用します。

--templates
Heat テンプレートが保管されているディレクトリーのパスを定義します。
-e
読み込む環境ファイルを指定します。

3.3. カスタムロールでの OpenDaylight のインストール

カスタムロールで OpenDaylight をインストールすると、OpenDaylightApi サービスが分離されて、コントローラーノードとは異なる、指定の OpenDaylight ノードで実行されます。

OpenDaylight 用のカスタムロールを使用するには、ノードのレイアウトと機能を設定するロールファイルを作成する必要があります。

3.3.1. デフォルトロールをベースとするロールファイルのカスタマイズ

OpenStack では、ユーザー定義のロールリストを使用してデプロイするオプションが提供されています。各ロールはユーザー定義のサービスリストを実行します (ここで「ロール」とは、「Controller」などのノードグループを意味し、「service」は「nova API」などの個別のサービスまたは設定を指します)。ロールの例は 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
  • 上記のコマンドでロール名を引数として渡すことによって、ロールファイルをカスタマイズして一部のロールのみが含まれるようにすることができます。ControllerComputeTelemetry ロールで 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: 1
  • HostnameFormatDefault: ホスト名の書式文字列を定義します。この値は任意です。

    HostnameFormatDefault: '%stackname%-computeovsdpdk-%index%'
  • Description: ロールを説明し、それについての情報を追加します。

    Description:
        Compute OvS DPDK Role

手順

  1. デフォルトのロールファイルを新規ディレクトリーにコピーします。元のファイルは、フォールバックする場合の解決方法として保管してください。

    $ mkdir ~/roles
    $ cp /usr/share/openstack-tripleo-heat-templates/roles/* ~/roles
  2. コントローラーノードで OpenDaylightAPI サービスをスイッチオフします。そのためには、~/roles にある Controller.yaml ファイルでデフォルトのコントローラーロールを編集し、そのファイルから OpenDaylightApi の行を削除します。

       - name: Controller
         CountDefault: 1
         ServicesDefault:
          - OS::TripleO::Services::TripleoFirewall
          - OS::TripleO::Services::OpenDaylightApi #<--Remove this
          - OS::TripleO::Services::OpenDaylightOvs
  3. ~/roles ディレクトリーに新しい OpenDaylight.yaml ファイルを作成し、OpenDaylight ロールの説明を追加します。

    - name: OpenDaylight
       CountDefault: 1
       ServicesDefault:
         - OS::TripleO::Services::Kernel
         - OS::TripleO::Services::Ntp
         - OS::TripleO::Services::OpenDaylightApi
         - OS::TripleO::Services::TripleoPackages
         - OS::TripleO::Services::TripleoFirewall
         - OS::TripleO::Services::Docker
         - OS::TripleO::Services::Sshd
  4. ファイルを保存します。
  5. OpenDaylight をカスタムロールで実装する OpenStack オーバークラウドのデプロイに使用する新規ロールファイルを生成します。

    $ openstack overcloud roles generate --roles-path ~/roles -o ~/roles_data.yaml Controller Compute OpenDaylight

3.3.3. OpenDaylight をカスタムロールで実装するオーバークラウドのインストール

作業を開始する前に

手順

  1. -r 引数を指定してデプロイメントコマンドを実行し、デフォルトのロール定義を上書きします。 このオプションは、カスタマイズされたロールが設定されている別の roles_data.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
注記

後に指定する環境ファイルのパラメーターにより、前の環境ファイルのパラメーターが上書きされます。パラメーターが誤って上書きされるのを防ぐために、環境ファイルの指定順序には注意を払う必要があります。

ヒント

変更するパラメーターのみを設定する最小限の環境ファイルを作成して、デフォルトの環境ファイルと組み合わせることにより、一部のパラメーターは簡単に上書きすることができます。

詳細情報

  • この引数は、Red Hat OpenStack Platform director 内のロール定義をインストール時に上書きするのに使用されます。

    -r <roles_data>.yaml
  • カスタムロールを使用するには、インストール中にそのカスタムロール用に使用する追加の ironic ノードが必要となります。

3.3.4. カスタムロールでの OpenDaylight インストールの検証

作業を開始する前に

手順

  1. 既存のインスタンスを一覧表示します。

    $ openstack server list
  2. 結果を確認し、新規 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 ベースのインスタンスを作成できるようにする必要があります。

作業を開始する前に

手順

  1. デフォルトのロールファイルを新規ディレクトリーにコピーします。元のファイルは、フォールバックする場合の解決方法として保管してください。

    $ mkdir ~/roles
    $ cp /usr/share/openstack-tripleo-heat-templates/roles/* ~/roles
  2. ~/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
  3. ファイルを保存します。
  4. NeutronSriovAgent および NeutronSriovHostConfig のサービスをデフォルトの Compute ロールから削除し、対応するロールファイルを保存します。

         - OS::TripleO::Services::NeutronSriovHostConfig
         - OS::TripleO::Services::NeutronSriovAgent
  5. OpenStack オーバークラウドでデプロイする、OpenDaylight の SR-IOV 対応のコンピュートに使用する新規ロールファイルを生成します。

    $ 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 ファイルで設定されているデフォルトのパラメーターを上書きする必要があります。標準の SR-IOV 環境ファイルは /usr/share/openstack-tripleo-heat-templates にあります。ただし、元のファイルは編集しないのがグッドプラクティスです。このため、元の環境ファイルのコピーを作成して、そのコピー内で必要なパラメーターを変更する必要があります。

また、変更するパラメーターのみを指定する新規環境ファイルを作成して、両方のファイルをデプロイメントに使用することができます。カスタマイズされた 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"

詳細情報

前述の yaml ファイルでは、以下のオプションを設定することができます。以下の表には、各オプションについての説明と、SR-IOV 機能を有効化するために必要な設定を記載します。

NovaSchedulerDefaultFilters

SR-IOV 用の PCI パススルーを使用できるようにします。このパラメーターは、環境ファイル内でコメント解除して、PciPassthroughFilter を追加する必要があります。

NovaSchedulerAvailableFilters

Nova のデフォルトフィルターに PCI パススルーフィルターを指定できるようにします。このパラメーターは必須で、nova.scheduler.filters.all_filters を追加する必要があります。

NeutronPhysicalDevMappings

neutron の論理ネットワークをホストのネットワークインターフェースにマッピングします。neutron が仮想ネットワークを物理ポートにバインドできるようにするには、このパラメーターを指定する必要があります。

NeutronSriovNumVFs

ホストのネットワークインターフェース用に作成する VF 数。構文: <Interface name>:<number of VFs>

NovaPCIPassthrough

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 のインストール

作業を開始する前に

手順

  1. -r 引数を使用してデプロイメントコマンドを実行し、カスタマイズしたロールファイルと OpenDaylight で SR-IOV 機能を設定するのに必要な環境ファイルを指定します。

    $ 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 /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
    -e <other needed environment files>
注記

後に指定する環境ファイルのパラメーターにより、前の環境ファイルのパラメーターが上書きされます。パラメーターが誤って上書きされるのを防ぐために、環境ファイルの指定順序には注意を払う必要があります。

ヒント

変更するパラメーターのみを設定する最小限の環境ファイルを作成して、デフォルトの環境ファイルと組み合わせることにより、一部のパラメーターは簡単に上書きすることができます。

詳細情報

  • インストール時にロールの定義を上書きするには、-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 容量
  • 『ネットワーク機能仮想化 (NFV) のプランニングおよび設定ガイド』を参照すること

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 をデプロイするには、Red Hat で提供している neutron-opendaylight-dpdk.yaml を使用することができます。このファイルは、/usr/share/openstack-tripleo-heat-templates/environments/services-docker ディレクトリーにあります。

デフォルトのファイルには、以下の値が含まれています。

# 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 サービスを設定することができます。

TunedProfileName

IRQ のピニングを有効化して、OVS-DPDK で使用する CPU コアから分離します。デフォルトプロファイル: cpu-partitioning

IsolCpusList

CPU コアの一覧を指定し、カーネルスケジューラーがそれらのコアを使用しないようにして、代わりに OVS-DPDK に割り当てて専用にすることができます。書式は、個々のコアのコンマ区切りリストまたは範囲で指定します (例: 1,2,3,4-8,10-12)。

KernelArgs

ブート時にカーネルに渡す引数をリストします。OVS-DPDK の場合は、IOMMUHugepages を有効にする必要があります。以下に例を示します。

---- intel_iommu=on iommu=pt default_hugepagesz=1GB hugepagesz=1G hugepages=60 ----

上記で指定している RAM の容量はヒュージページ用の 60 GB であることに注意してください。この値を設定する場合には、コンピュートノードで利用可能な RAM 容量を考慮することが重要です。

OvsDpdkSocketMemory

各 NUMA ノードに割り当てるヒュージページメモリーの容量を (MB 単位で) 指定します。パフォーマンスを最大限にするには、DPDK NIC に最も近いソケットにメモリーを割り当てます。ソケットあたりのメモリーをリストする形式は以下のようになります。

---- "<socket 0 mem MB>,<socket 1 mem MB>" ----

例: "1024,0"

OvsDpdkDriverType

PMD スレッドに使用する UIO ドライバーの種別を指定します。DPDK NIC がサポートしているドライバーを指定する必要があります。種別には vfio-pciuio_pci_generic などがあります。

OvsPmdCoreList

PMD スレッドのピニング先となる個々のコアまたは範囲をリストします。ここで指定するコアは、OvsDpdkSocketMemory の設定でメモリーが割り当てられているのと同じ NUMA ノード上にある必要があります。ハイパースレッディングが使用される場合には、ホスト上の物理コアを構成する論理コアを指定する必要があります。

OvsDpdkMemoryChannels

ソケットあたりのメモリーチャネルの数を指定します。

NovaVcpuPinSet

libvirtd で nova インスタンスをピニングするコア。パフォーマンスを最適にするには、OVS PMD コアがピニングされているのと同じソケット上のコアを使用してください。

3.5.3. OVS-DPDK を実装する OpenDaylight のインストール

作業を開始する前に

手順

  1. OpenDaylight で DPDK 機能を設定するのに必要な環境ファイルを使用してデプロイメントコマンドを実行します。
$ 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 /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
-e <other environmental files>
注記

後に指定する環境ファイルのパラメーターにより、前の環境ファイルのパラメーターが上書きされます。パラメーターが誤って上書きされるのを防ぐために、環境ファイルの指定順序には注意を払う必要があります。

ヒント

変更するパラメーターのみを設定する最小限の環境ファイルを作成して、デフォルトの環境ファイルと組み合わせることにより、一部のパラメーターは簡単に上書きすることができます。

3.6. L2GW 対応の OpenDaylight のインストール

レイヤー 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 をデフォルトの設定でデプロイする場合には、Red Hat で提供している neutron-l2gw-opendaylight.yaml を使用します。このファイルは /usr/share/openstack-tripleo-heat-templates/environments/services-docker ディレクトリーにあります。

デフォルトのファイルには、以下の値が含まれています。

# 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: ../puppet/services/neutron-l2gw-api.yaml

parameter_defaults:
  NeutronServicePlugins: "networking_l2gw.services.l2gateway.plugin.L2GatewayPlugin"
  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 ファイルの値を変更することによって設定することができます。

NeutronServicePlugins

neutron.service_plugins 名前空間から読み込まれるサービスプラグインのエンドポイントのコンマ区切りリスト。デフォルトは router です。

L2gwServiceProvider

このサービスを提供するのに使用すべきプロバイダーを定義します。デフォルトは L2GW:OpenDaylight:networking_odl.l2gateway.driver.OpenDaylightL2gwDriver:default です。

L2gwServiceDefaultInterfaceName

デフォルトのインターフェースの名前を設定します。

L2gwServiceDefaultDeviceName

デフォルトのデバイスの名前を設定します。

L2gwServiceQuotaL2Gateway

L2 ゲートウェイ用のサービスクォータを指定します。デフォルトは 10 です。

L2gwServicePeriodicMonitoringInterval

L2GW サービスのモニタリング間隔を指定します。

3.6.3. L2GW を実装する OpenDaylight のインストール

作業を開始する前に

手順

  1. OpenDaylight で L2GW 機能を設定するのに必要な環境ファイルを使用してデプロイメントコマンドを実行します。
$ 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 /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
-e <other environmental files>
注記

後に指定する環境ファイルのパラメーターにより、前の環境ファイルのパラメーターが上書きされます。パラメーターが誤って上書きされるのを防ぐために、環境ファイルの指定順序には注意を払う必要があります。

ヒント

変更するパラメーターのみを設定する最小限の環境ファイルを作成して、デフォルトの環境ファイルと組み合わせることにより、一部のパラメーターは簡単に上書きすることができます。

第4章 デプロイメントのテスト

4.1. 基本的なテストの実行

基本的なテストでは、インスタンスが相互に ping できるかどうかを検証します。また、Floating IPSSH アクセスもチェックします。以下の例では、アンダークラウドからテストを実行する方法について説明します。

本手順では、個別のステップを多数実行する必要があるので、便宜を図るために小さいセクションに分けています。ただし、これらのステップは、所定の順序で実行する必要があります。

注記
このステップでは、flat ネットワークを使用して _External_ network を作成し、_VXLAN_ を使用して _Tenant_ networks を作成します。デプロイメントに望ましい場合には、_VLAN External_ networks と _VLAN Tenant_ networks もサポートされています。

4.1.1. テスト用の新規ネットワークの作成

  1. オーバークラウドにアクセスするための認証情報を読み込みます。

    $ source /home/stack/overcloudrc
  2. オーバークラウドの外部からインスタンスにアクセスするのに使用する neutron の外部ネットワークを作成します。

    $ openstack network create --external --project service --external  --provider-network-type flat --provider-physical-network datacentre
  3. 新しい外部ネットワーク (前のステップで作成済み) に対応する neutron サブネットを作成します。

    $ openstack subnet create  --project service --no-dhcp --network external --gateway 192.168.37.1 --allocation-pool start=192.168.37.200,end=192.168.37.220 --subnet-range 192.168.37.0/24 external-subnet
  4. オーバークラウドインスタンスを作成するための cirros イメージをダウンロードします。

    $ wget http://download.cirros-cloud.net/0.3.4/cirros-0.3.4-x86_64-disk.img
  5. オーバークラウドの glance に cirros イメージをアップロードします。

    $ openstack image create cirros --public --file ./cirros-0.3.4-x86_64-disk.img --disk-format qcow2 --container-format bare
  6. オーバークラウドインスタンスに使用する tiny フレーバーを作成します。

    $ openstack flavor create m1.tiny --ram 512 --disk 1 --public
  7. インスタンスをホストするための VXLAN ベースのテナントネットワークを作成します。

    $ openstack network create net_test --provider-network-type=vxlan --provider-segment 100
  8. テナントネットワーク (前のステップで作成済み) のサブネットを作成します。

    $ openstack subnet create --network net_test --subnet-range 123.123.123.0/24 test
  9. テナントネットワークの ID を特定して保存します。

    $ net_mgmt_id=$(openstack network list | grep net_test | awk '{print $2}')
  10. cirros1 という名前のインスタンスを作成して、net_test ネットワークに接続します。

    $ openstack server create --flavor m1.tiny --image cirros --nic net-id=$net_mgmt_id cirros1
  11. cirros2 という名前の第 2 のインスタンスを作成して、同様に net_test ネットワークに接続します。

    $ openstack server create --flavor m1.tiny --image cirros --nic net-id=$net_mgmt_id cirros2

4.1.2. ネットワークとテスト環境の設定

  1. admin プロジェクトの ID を特定して保存します。

    $ admin_project_id=$(openstack project list | grep admin | awk '{print $2}')
  2. admin プロジェクトのデフォルトのセキュリティーグループを特定して保存します。

    $ admin_sec_group_id=$(openstack security group list | grep $admin_project_id | awk '{print $2}')
  3. admin のデフォルトセキュリティーグループに、ICMP トラフィックの受信を許可するルールを追加します。

    $ openstack security group rule create $admin_sec_group_id --protocol icmp --ingress
  4. admin のデフォルトセキュリティーグループに、ICMP トラフィックの送信を許可するルールを追加します。

    $ openstack security group rule create $admin_sec_group_id --protocol icmp --egress
  5. admin のデフォルトセキュリティーグループに、SSH トラフィックの受信を許可するルールを追加します。

    $ openstack security group rule create $admin_sec_group_id --protocol tcp --dst-port 22 --ingress
  6. admin のデフォルトセキュリティーグループにルールを追加して SSH トラフィックの送信を許可します。

    $ openstack security group rule create $admin_sec_group_id --protocol tcp --dst-port 22 --egress

4.1.3. 接続性のテスト

  1. horizon からインスタンスの novnc コンソールにアクセスできるはずです。overcloudrc のパスワードを使用して admin として horizon にログインします。cirros イメージのデフォルトのログインでは、ユーザー名は cirros、パスワードは cubswin:) です。
  2. novnc コンソールから、DHCP アドレスがインスタンスに割り当てられているかどうかをことを確認します。

    $ ip addr show
    注記

    アンダークラウドから nova console-log <instance id> を使用してこの操作を行う方法もあります。これにより、DHCP リースが取得されているかどうかが表示されます。

  3. 次に、ステップ 1 と 2 をその他すべてのインスタンスで繰り返します。
  4. 1 つのインスタンスから他のインスタンスに ping を試みて、オーバークラウドにおける基本的な テナント ネットワーク接続を検証します。
  5. Floating IP を使用して他のインスタンスに到達できるかどうかを確認します。

4.1.4. デバイスの作成

  1. cirros1 インスタンスに割り当てる Floating IP を外部ネットワーク上に作成します。

    $ openstack floating ip create external
  2. Floating IP と cirros1 のテナント IP の間での NAT 処理に使用するルーターを作成します。

    $ openstack router create test
  3. ルーターのゲートウェイを外部ネットワークに設定します。

    $ openstack router set test --external-gateway external
  4. テナントネットワークに接続するルーターへのインターフェースを追加します。

    $ openstack router add subnet test test
  5. ステップ 1 で作成した Floating IP を特定して保存します。

    $ floating_ip=$(openstack floating ip list | head -n -1 | grep -Eo '[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+')
  6. Floating IP を cirros1 インスタンスに割り当てます。

    $ openstack server add floating ip cirros1 $floating_ip
  7. 外部ネットワークにアクセス可能なノードからインスタンスへのログインを試みます。

    $ ssh cirros@$floating_ip

4.2. 高度なテストの実行

OpenDaylight の設定およびデプロイメントのコンポーネントのいくつかは、デプロイメント後に確認することができます。インストールの特定の部分をテストするには、いくつかの手順に従って操作を実行する必要があります。各手順は別々に記載しています。

これらの手順は、オーバークラウド ノードで実行します。

4.2.1. オーバークラウドノードへの接続

この手順では、オーバークラウドノードに接続して稼働中かどうかをテストします。

手順

  1. アンダークラウドにログインします。
  2. 以下のコマンドを入力して作業を開始します。

      $ source /home/stack/stackrc
  3. 全インスタンスを一覧表示します。

      $ openstack server list
  4. 必要なインスタンスを選択して、一覧に表示される IP アドレスを書き留めておきます。
  5. マシンに接続します。上記の一覧から取得した IP アドレスを使用します。

      $ ssh heat-admin@<IP from step 4>
  6. superuser に切り替えます。

      $ sudo -i

4.2.2. OpenDaylight のテスト

OpenDaylight が機能することをテストするには、サービスが稼働していることと、特定の機能が正しく読み込まれていることを確認する必要があります。

手順

  1. OpenDaylight を実行するオーバークラウドノードまたはカスタムロールで実行している OpenDaylight ノードに superuser としてログインします。
  2. OpenDaylight サービスがアクティブかどうかを確認します。

    # systemctl status opendaylight
  3. HAProxy がポート 8081 をリッスンするように適切に設定されていることを確認します。

    # grep -A7 opendaylight /etc/haproxy/haproxy.cfg
  4. karaf アカウントに接続します。

    $ ssh -p 8101 karaf@localhost
  5. インストール済みの機能を一覧表示します。

    $ feature:list | grep odl-netvirt-openstack
  6. API が稼働中であることを確認します。

    # web:list | grep neutron
  7. VXLAN トンネルが稼動状態であることを確認します。

    # vxlan:show
  8. REST API が正しく応答するかどうかをテストするには、それを使用するモジュールを一覧表示して確認することができます。

    # curl -u "admin:admin" http://localhost:8181/restconf/modules

    以下と同じような出力が表示されます (この例は短く省略されています)。

    {"modules":{"module":[{"name":"netty-event-executor","revision":"2013-11-12","namespace":"urn:opendaylight:params:xml:ns:yang:controller:netty:eventexecutor"},{"name" ...
  9. REST ストリームをリストします。

    # curl -u "admin:admin" http://localhost:8181/restconf/streams

    以下のような出力が表示されます。

    {"streams":{}}
  10. 以下のコマンドを入力して、NetVirt の準備が整って実行中であることを確認します。

    # curl -u "admin:admin" http://localhost:8181/restconf/operational/network-topology:network-topology/topology/netvirt:1

    以下の出力により確認されます。

    {"topology":[{"topology-id":"netvirt:1"}]}

詳細情報

  • ステップ 5: この手順で生成されたリストの 3 番目のコラムに x がある場合には、その機能は適切にインストールされていることになります。
  • ステップ 6: この API エンドポイントは、/etc/neutron/plugins/ml2/ml2_conf.ini で設定され、neutron が OpenDaylight と通信するのに使用されます。

4.2.3. Open vSwitch のテスト

Open vSwitch を検証するには、コンピュートノードの 1 つに接続し、適切に設定されて OpenDaylight に接続されていることを確認します。

手順

  1. オーバークラウド内のコンピュートノードの 1 つに superuser として接続します。 
  2. Open vSwitch の設定を一覧表示します。

    # ovs-vsctl show
  3. 出力に Manager が複数ある点に注意してください (以下の例の 2 行目と 3 行目)。

        6b003705-48fc-4534-855f-344327d36f2a
            Manager "ptcp:6639:127.0.0.1"
            Manager "tcp:172.17.1.16:6640"
                is_connected: true
            Bridge br-ex
                fail_mode: standalone
                Port br-ex-int-patch
                    Interface br-ex-int-patch
                        type: patch
                        options: {peer=br-ex-patch}
                Port br-ex
                    Interface br-ex
                        type: internal
                Port "eth2"
                    Interface "eth2"
            Bridge br-isolated
                fail_mode: standalone
                Port "eth1"
                    Interface "eth1"
                Port "vlan50"
                    tag: 50
                    Interface "vlan50"
                        type: internal
                Port "vlan30"
                    tag: 30
                    Interface "vlan30"
                        type: internal
                Port br-isolated
                    Interface br-isolated
                        type: internal
                Port "vlan20"
                    tag: 20
                    Interface "vlan20"
                        type: internal
            Bridge br-int
                Controller "tcp:172.17.1.16:6653"
                    is_connected: true
                fail_mode: secure
                Port br-ex-patch
                    Interface br-ex-patch
                        type: patch
                        options: {peer=br-ex-int-patch}
                Port "tun02d236d8248"
                    Interface "tun02d236d8248"
                        type: vxlan
                        options: {key=flow, local_ip="172.17.2.18", remote_ip="172.17.2.20"}
                Port br-int
                    Interface br-int
                        type: internal
                Port "tap1712898f-15"
                    Interface "tap1712898f-15"
            ovs_version: "2.7.0"
  4. OpenDaylight が実行されているノードの IP アドレスを tcp Manager がポイントしていることを確認します。
  5. Manager の下に is_connected: true と表示されていることを確認し、OVS から OpenDaylight への接続が確立されて、OVSDB プロトコルを使用していることを確かめます。
  6. 各ブリッジ (br-int 以外) が存在し、Compute ロールでのデプロイメントに使用した NIC テンプレートと一致していることを確認します。
  7. tcp 接続が、OpenDaylight サービスが実行されているところの IP に対応していることを確認します。
  8. ブリッジ br-intis_connected: true が表示され、OpenFlow プロトコルから OpenDaylight への接続が確立されていることを確認します。

詳細情報

  • br-int は OpenDaylight によって自動的に作成されます。

4.2.4. コンピュートノード上の Open vSwitch の設定の確認

  1. コンピュートノードに superuser として接続します。 
  2. Open vSwitch の設定を一覧表示します。

    # ovs-vsctl list open_vswitch
  3. 出力を確認します。以下の例と同様の内容が表示されます。

     _uuid               : 4b624d8f-a7af-4f0f-b56a-b8cfabf7635d
     bridges             : [11127421-3bcc-4f9a-9040-ff8b88486508, 350135a4-4627-4e1b-8bef-56a1e4249bef]
     cur_cfg             : 7
     datapath_types      : [netdev, system]
     db_version          : "7.12.1"
     external_ids        : {system-id="b8d16d0b-a40a-47c8-a767-e118fe22759e"}
     iface_types         : [geneve, gre, internal, ipsec_gre, lisp, patch, stt, system, tap, vxlan]
     manager_options     : [c66f2e87-4724-448a-b9df-837d56b9f4a9, defec179-720e-458e-8875-ea763a0d8909]
     next_cfg            : 7
     other_config        : {local_ip="11.0.0.30", provider_mappings="datacentre:br-ex"}
     ovs_version         : "2.7.0"
     ssl                 : []
     statistics          : {}
     system_type         : RedHatEnterpriseServer
     system_version      : "7.4-Maipo"
  4. other_config オプションの値に、VXLAN トンネルを介してテナントネットワークに接続するローカルインターフェースの正しい local_ip が設定されていることを確認します。
  5. other_config のオプション下の provider_mappings の値が OpenDaylightProviderMappings Heat テンプレートパラメーターで指定されている値と一致していることを確認します。この設定により、neutron の論理ネットワークが対応する物理インターフェースにマッピングされます。

4.2.5. neutron の設定の確認

手順

  1. Controller ロールのノードの 1 つの superuser アカウントに接続します。
  2. /etc/neutron/neutron.conf ファイルに service_plugins=odl-router_v2,trunk の設定が含まれていることを確認します。
  3. /etc/neutron/plugin.ini ファイルに以下の ml2 設定が含まれていることを確認します。

    [ml2]
    mechanism_drivers=opendaylight_v2
    
    [ml2_odl]
    password=admin
    username=admin
    url=http://192.0.2.9:8081/controller/nb/v2/neutron
  4. オーバークラウド のコントローラーの 1 つで、neutron エージェントが適切に稼働していることを確認します。

    # openstack network agent list
  5. メタデータエージェントと DHCP エージェントが up の状態 (admin_state_up オプションが True) であることを確認します。

    +--------------------------------------+----------------+--------------------------+-------------------+-------+----------------+------------------------+
    | id                                   | agent_type     | host                     | availability_zone | alive | admin_state_up | binary                 |
    +--------------------------------------+----------------+--------------------------+-------------------+-------+----------------+------------------------+
    | 3be198c5-b3aa-4d0e-abb4-51b29db3af47 | Metadata agent | controller-0.localdomain |                   | :-)   | True           | neutron-metadata-agent |
    | 79579d47-dd7d-4ef3-9614-cd2f736043f3 | DHCP agent     | controller-0.localdomain | nova              | :-)   | True           | neutron-dhcp-agent     |
    +--------------------------------------+----------------+--------------------------+-------------------+-------+----------------+------------------------+

詳細情報

  • ステップ 3 で触れた plugin.ini 内の IP は、 InternalAPI の仮想 IP アドレス (VIP) である必要があります。
  • ステップ 5 の出力には、Open vSwitch エージェントまたは L3 エージェントは記載されていない点に注意してください。これらはいずれも OpenDaylight によって管理されるようになったので、出力に含まれていないのは望ましい状態です。

第5章 デバッグ

5.1. ログの特定

5.1.1. OpenDaylight ログへのアクセス

OpenDaylight のログは、全 OpenDaylight ノードの /opt/opendaylight/data/log/ ディレクトリーに保管されています。OpenDaylight は、そのログを karaf.log ファイルに保管します。

最新のログは、karaf.log という名前で、それよりも前のログには karaf.log.1 というように番号が付きます。

5.1.2. Karaf シェルを使用した OpenDaylight ログへのアクセス

ログにアクセスするもう 1 つの方法として、OpenDaylight ノード上の Karaf シェルにログインする方法があります。

  1. Karaf アカウントに接続します。

      $ ssh -p 8101 karaf@localhost
  2. NetVirt 上でトレースレベルのロギングを有効化します。

      $ log set TRACE org.opendaylight.netvirt
  3. Karaf シェル内のログを tail する必要がある場合には、以下のコマンドを実行します。

      $ log:tail

詳細情報

  • Karaf シェルは、任意の OpenDaylight 機能で異なるロギングレベルを有効にするのに役立ちます。FATAL、ERROR、WARN、INFO、DEBUG、TRACE のレベルから選択することができます。
  • TRACE を有効にすると、大量のログ情報を受信することになります。

5.1.3. OpenStack Networking のログへのアクセス

ネットワーク関連の OpenStack コマンドが失敗した場合には、まず最初に neutron のログを確認すべきです。このログは、各 neutron ノードの /var/log/neutron ディレクトリー内の server.log に保管されます。

server.log ファイルには、OpenDaylight との通信に関するエラーも記載されます。neutron エラーが OpenDaylight との対話に起因している場合には、OpenDaylight ログを確認して、エラーの原因を特定する必要もあります。

5.2. ネットワークエラーのデバッグ

ネットワークでエラーが発生したにも拘らず (例: インスタンスの接続できないなど)、OpenStack コマンドを発行してもエラーが報告されなかったり、neutron のログにも記載されない場合には、OVS ノードを検査してネットワークトラフィックと OpenFlow のフローを確認すると役立つ場合があります。

  1. ネットワークエラーが発生したノードに (superuser として) ログインします。
  2. br-int スイッチに関する情報を表示します。

    # ovs-ofctl -O openflow13 show br-int
  3. 出力を確認します。以下の例と同じような内容が表示されるはずです。

    OFPT_FEATURES_REPLY (OF1.3) (xid=0x2): dpid:0000e4c153bdb306
    n_tables:254, n_buffers:256
    capabilities: FLOW_STATS TABLE_STATS PORT_STATS GROUP_STATS QUEUE_STATS
    OFPST_PORT_DESC reply (OF1.3) (xid=0x3):
     1(br-ex-patch): addr:ae:38:01:09:66:5b
         config:     0
         state:      0
         speed: 0 Mbps now, 0 Mbps max
     2(tap1f0f610c-8e): addr:00:00:00:00:00:00
         config:     PORT_DOWN
         state:      LINK_DOWN
         speed: 0 Mbps now, 0 Mbps max
     3(tun1147c81b59c): addr:66:e3:d2:b3:b8:e3
         config:     0
         state:      0
         speed: 0 Mbps now, 0 Mbps max
     LOCAL(br-int): addr:e4:c1:53:bd:b3:06
         config:     PORT_DOWN
         state:      LINK_DOWN
         speed: 0 Mbps now, 0 Mbps max
    OFPT_GET_CONFIG_REPLY (OF1.3) (xid=0x5): frags=normal miss_send_len=0
  4. br-int スイッチの統計を一覧表示します。

    # ovs-ofctl -O openflow13 dump-ports br-int
  5. 出力を確認します。以下の例と同じような内容が表示されるはずです。

    OFPST_PORT reply (OF1.3) (xid=0x2): 4 ports
      port LOCAL: rx pkts=101215, bytes=6680190, drop=0, errs=0, frame=0, over=0, crc=0
               tx pkts=0, bytes=0, drop=0, errs=0, coll=0
               duration=90117.708s
      port  1: rx pkts=126887, bytes=8970074, drop=0, errs=0, frame=0, over=0, crc=0
               tx pkts=18764, bytes=2067792, drop=0, errs=0, coll=0
               duration=90117.418s
      port  2: rx pkts=1171, bytes=70800, drop=0, errs=0, frame=0, over=0, crc=0
               tx pkts=473, bytes=44448, drop=0, errs=0, coll=0
               duration=88644.819s
      port  3: rx pkts=120197, bytes=8776126, drop=0, errs=0, frame=0, over=0, crc=0
               tx pkts=119408, bytes=8727254, drop=0, errs=0, coll=0
               duration=88632.426s

詳細情報

  • ステップ 3 で、この OVS ノードで 3 つのポートが作成されたのがわかります。1 番目のポートはブリッジ br-ex に送信されるパッチポートで、このシナリオでは、外部ネットワークの接続に使用されます。2 番目のポートは、tap ポートで、DHCP エージェントインスタンスに接続されます (これは、ホストはコントローラーなのでわかります。コントローラーではなく、Compute ロール上の場合には、インスタンスとなります)。3 番目のポートは、テナントトラフィック用に作成された VXLAN トンネルポートです。
  • 各ポートの用途を理解したら、ポートの統計を調べて、ポートがトラフィックの送受信を確実に行なっていることを確認します (ステップ 4 を参照)。
  • ステップ 5 の出力から、各ポートがパケットを受信 (rx pkts) および送信 (tx pkts) していることを確認できます。

5.2.1. OpenFlow のフローを使用した高度なデバッグ

OpenFlow に精通している上級ユーザーの場合には、スイッチ上のフローを検査して、トラフィックがどこでドロップするかを検出するのが次のレベルのデバッグです。

  1. フローを一覧表示してヒットしたパケット数を確認するには、以下のコマンドを入力します。

    # ovs-ofctl -O openflow13 dump-flows br-int
  2. コマンドの出力を確認して、必要な情報を取得します。

    OFPST_FLOW reply (OF1.3) (xid=0x2):
     cookie=0x8000000, duration=90071.665s, table=0, n_packets=126816, n_bytes=8964820, priority=1,in_port=1 actions=write_metadata:0x20000000001/0xffffff0000000001,goto_table:17
     cookie=0x8000000, duration=88967.292s, table=0, n_packets=473, n_bytes=44448, priority=4,in_port=2 actions=write_metadata:0x40000000000/0xffffff0000000001,goto_table:17
     cookie=0x8000001, duration=88954.901s, table=0, n_packets=120636, n_bytes=8807869, priority=5,in_port=3 actions=write_metadata:0x70000000001/0x1fffff0000000001,goto_table:36
     cookie=0x8000001, duration=90069.534s, table=17, n_packets=126814, n_bytes=8964712, priority=5,metadata=0x20000000000/0xffffff0000000000 actions=write_metadata:0xc0000200000222e0/0xfffffffffffff
    ffe,goto_table:19
     cookie=0x8040000, duration=90069.533s, table=17, n_packets=126813, n_bytes=8964658, priority=6,metadata=0xc000020000000000/0xffffff0000000000 actions=write_metadata:0xe00002138a000000/0xffffffff
    fffffffe,goto_table:48
     cookie=0x8040000, duration=88932.689s, table=17, n_packets=396, n_bytes=36425, priority=6,metadata=0xc000040000000000/0xffffff0000000000 actions=write_metadata:0xe00004138b000000/0xfffffffffffff
    ffe,goto_table:48
注記

上記の出力は長いため途中から省略されています。

5.2.2. OpenFlow でのパケットのトラバース

理解すべき重要な点として、パケットに対して実行されるネットワーク機能は複数の異なる OpenFlow テーブルに分かれ、パケットはそれらのテーブルをゼロから順番に通過していくことが挙げられます。受信パケットはテーブル 0 に着信し、次に OpenFlow のパイプライン を経て進み、ポートから送信されて OpenDaylight のコントローラーに到達するか、ドロップされます。パケットは、処理の必要があるネットワーク機能に応じて、1 つまたは複数のテーブルをスキップする場合があります。テーブルの全体図と各テーブルが対応するネットワーク機能を以下に示します。

図5.1 OpenDaylight NetVirt OpenFlow の パイプライン

OpenDaylight NetVirt OpenFlow Pipeline

第6章 デプロイメントの例

6.1. テナントネットワークを使用した模範的なインストールシナリオ

本章では、OpenStack を使用した実稼働環境における OpenDaylight のインストールの例を考察します。このシナリオでは、テナントトラフィックの分離にトンネリング (VXLAN) が使用されます。

6.1.1. 物理トポロジー

このシナリオのトポロジーは、6 つのノードで構成されます。

  • 1 x director アンダークラウドノード
  • 3 x OpenStack オーバークラウドコントローラー。OpenStack サービスに加えて OpenDaylight SDN コントローラーがインストール済み。
  • 2 x OpenStack オーバークラウドコンピュートノード

6.1.2. 物理ネットワーク環境のプランニング

オーバークラウドのコントローラーノードは、それぞれ、3 つのネットワークインターフェースカード (NIC) を使用します。

名前目的

nic1

Management ネットワーク (例: SSH を介したノードへのアクセス)

nic2

Tenant () キャリアー、Provisioning (PXE、DHCP)、Internal API の各ネットワーク

nic3

パブリック API のネットワークアクセス

オーバークラウドのコンピュートノードには 3 つの NIC が実装されます。

名前目的

nic1

Management ネットワーク

nic2

Tenant キャリアー、Provisioning、Internal API ネットワーク

nic3

External (Floating IP) ネットワーク

アンダークラウドノードには 2 つの NIC が実装されます。

名前目的

nic1

Management ネットワークに使用

nic2

Provisioning ネットワークに使用

6.1.3. NIC の接続性のプランニング

この場合、環境ファイルは、インターフェースの抽象名 (nic1nic2) を使用し、ホストのオペレーティングシステムで提供される実際のデバイス名 (例: eth0eno2 など) は使用しません。同じロールに属するホストには、全く同じネットワークインターフェースデバイス名は必要ありません。1 台のホストで em1em2 のインターフェースを使用するイップで他のホストで eno1eno2 を使用しても全く問題ありません。各 NIC は nic1 および nic2 と呼ばれます。

抽象化された NIC スキームでは、稼働中かつ接続済みのインターフェースにのみ依存します。ホストによってインターフェースが異なる場合には、ホストを接続するのに必要な最小限のインターフェース数を使用すれば十分です。たとえば、1 台のホストに物理インターフェースが 4 つあり、他のホストには 6 つある場合、nic1nic2nic3nic4 のみを使用して、両ホストに 4 本のケーブルを接続します。

6.1.4. ネットワーク、VLAN、IP のプランニング

このシナリオでは、ネットワーク分離を使用して、Management、Provisioning、Internal API、Tenant、Public API、Floating IP のネットワークトラフィックを分離します。

図6.1 このシナリオで使用するネットワークトポロジーの詳細

Detailed network topology used in this scenario

以下の表には、各ネットワークに関連付けられる VLAN ID と IP サブネットをまとめています。

ネットワークVLAN IDIP サブネット

プロビジョニング

ネイティブ

192.0.5.0/24

Internal API

600

172.17.0.0/24

Tenant

603

172.16.0.0/24

パブリック API

411

10.35.184.144/28

Floating IP

412

10.35.186.146/28

OpenStack Platform director は br-isolated OVS ブリッジを作成し、ネットワーク設定ファイルの定義に従って各ネットワークの VLAN インターフェースを追加します。br-ex ブリッジも director によって自動的に作成され、関連するネットワークインターフェースが接続されます。

ホスト間の接続性を提供する物理ネットワークスイッチが、VLAN ID を適用するように適切に設定されていることを確認します。ホストに接続する全スイッチポートは、前述の VLAN を使用して「trunk」として設定する必要があります。ここで「trunk」という用語は、複数の VLAN ID が同じポートを通過できるポートという意味で使用しています。

注記

物理スイッチの設定に関する内容は、本書の対象範囲外です。

注記

network-environment.yamlTenantNetworkVlanID で、VXLAN トンネリングを使用する場合の Tenant ネットワークの VLAN タグを定義することができます (VXLAN テナントのトラフィックが VLAN タグ付けされた下層のネットワーク上で転送される)。Tenant ネットワークがネイティブ VLAN 上で実行されるようにした方が望ましい場合には、この値を空にすることも可能です。また、VLAN テナント種別のネットワークを使用する場合には、 TenantNetworkVlanID に指定されている値以外の VLAN タグを使用することができる点にも注意してください。

6.1.5. このシナリオで使用する OpenDaylight の設定ファイル

このシナリオにおける OpenStack と OpenDaylight のデプロイには、アンダークラウドで以下のデプロイメントコマンドを実行しています。

$ openstack overcloud deploy --debug \
  --templates \
  --environment-file "$HOME/extra_env.yaml" \
  --libvirt-type kvm \
  -e /home/stack/baremetal-vlan/network-environment.yaml \
  -e /usr/share/openstack-tripleo-heat-templates/environments/neutron-opendaylight.yaml \
  --log-file overcloud_install.log &> overcloud_install.log

また、本ガイドでは、このシナリオに使用した設定ファイルとその内容を記載し、使用した設定についても説明しています。

6.1.5.1. extra_env.yaml ファイル

このファイルにはパラメーターが 1 つしかありません。

 parameter_defaults:
    OpenDaylightProviderMappings: 'datacentre:br-ex,tenant:br-isolated'

これらは、OpenDaylight によって制御される各ノードが使用するマッピングです。物理ネットワーク datacenter は、br-ex OVS ブリッジにマッピングされ、Tenant ネットワークのトラフィックは br-isolated OVS ブリッジにマッピングされます。

6.1.5.2. undercloud.conf ファイル

このファイルは /home/stack/baremetal-vlan/ ディレクトリーにあります。

注記

ファイルのパスは、カスタマイズされたバージョンの設定ファイルをポイントしています。

  [DEFAULT]
  local_ip = 192.0.5.1/24
  network_gateway = 192.0.5.1
  undercloud_public_vip = 192.0.5.2
  undercloud_admin_vip = 192.0.5.3
  local_interface = eno2
  network_cidr = 192.0.5.0/24
  masquerade_network = 192.0.5.0/24
  dhcp_start = 192.0.5.5
  dhcp_end = 192.0.5.24
  inspection_iprange = 192.0.5.100,192.0.5.120

上記の例では、Provisioning ネットワーク用の 192.0.5.0/24 サブネットが使用されています。物理インターフェース eno2 はアンダークラウドノードでプロビジョニング用に使用されます。

6.1.5.3. network-environment.yaml ファイル

これは、ネットワークを設定するメインのファイルで、/home/stack/baremetal-vlan/ ディレクトリーにあります。以下のファイルでは、VLAN ID と IP サブネットが異なるネットワークとプロバイダーマッピングに指定されます。nic-configs ディレクトリー内の controller.yaml および compute.yaml は、コントローラーノードとコンピュートノードのネットワーク設定を指定するのに使用されます。

この例では、コントローラーノードの数 (3) とコンピュートノードの数 (2) が指定されています。

resource_registry:
  # Specify the relative/absolute path to the config files you want to use for
  # override the default.
  OS1::TripleO::Compute::Net::SoftwareConfig: nic-configs/compute.yaml
  OS::TripleO::Controller::Net::SoftwareConfig: nic-configs/controller.yaml

  # Network isolation configuration
  # Service section
  # If some service should be disable, use the following example
  # OS::TripleO::Network::Management: OS::Heat::None
    OS::TripleO::Network::External: /usr/share/openstack-tripleo-heat-templates/network/external.yaml
    OS::TripleO::Network::InternalApi: /usr/share/openstack-tripleo-heat-templates/network/internal_api.yaml
    OS::TripleO::Network::Tenant: /usr/share/openstack-tripleo-heat-templates/network/tenant.yaml
    OS::TripleO::Network::Management: OS::Heat::None
    OS::TripleO::Network::StorageMgmt: OS::Heat::None
    OS::TripleO::Network::Storage: OS::Heat::None

  # Port assignments for the VIP addresses
    OS::TripleO::Network::Ports::ExternalVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/external.yaml
    OS::TripleO::Network::Ports::InternalApiVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/internal_api.yaml
    OS::TripleO::Network::Ports::RedisVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/vip.yaml
    OS::TripleO::Network::Ports::StorageVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/noop.yaml
    OS::TripleO::Network::Ports::StorageMgmtVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/noop.yaml

  # Port assignments for the controller role
    OS::TripleO::Controller::Ports::ExternalPort: /usr/share/openstack-tripleo-heat-templates/network/ports/external.yaml
    OS::TripleO::Controller::Ports::InternalApiPort: /usr/share/openstack-tripleo-heat-templates/network/ports/internal_api.yaml
    OS::TripleO::Controller::Ports::TenantPort: /usr/share/openstack-tripleo-heat-templates/network/ports/tenant.yaml
    OS::TripleO::Controller::Ports::ManagementPort: /usr/share/openstack-tripleo-heat-templates/network/ports/noop.yaml
    OS::TripleO::Controller::Ports::StoragePort: /usr/share/openstack-tripleo-heat-templates/network/ports/noop.yaml
    OS::TripleO::Controller::Ports::StorageMgmtPort: /usr/share/openstack-tripleo-heat-templates/network/ports/noop.yaml

  # Port assignments for the Compute role
    OS::TripleO::Compute::Ports::ExternalPort: /usr/share/openstack-tripleo-heat-templates/network/ports/external.yaml
    OS::TripleO::Compute::Ports::InternalApiPort: /usr/share/openstack-tripleo-heat-templates/network/ports/internal_api.yaml
    OS::TripleO::Compute::Ports::TenantPort: /usr/share/openstack-tripleo-heat-templates/network/ports/tenant.yaml
    OS::TripleO::Compute::Ports::ManagementPort: /usr/share/openstack-tripleo-heat-templates/network/ports/noop.yaml
    OS::TripleO::Compute::Ports::StoragePort: /usr/share/openstack-tripleo-heat-templates/network/ports/noop.yaml
    OS::TripleO::Compute::Ports::StorageMgmtPort: /usr/share/openstack-tripleo-heat-templates/network/ports/noop.yaml

  # Port assignments for service virtual IP addresses for the controller role
    OS::TripleO::Controller::Ports::RedisVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/vip.yaml

parameter_defaults:
  # Customize all these values to match the local environment
  InternalApiNetCidr: 172.17.0.0/24
  TenantNetCidr: 172.16.0.0/24
  ExternalNetCidr: 10.35.184.144/28
  # CIDR subnet mask length for provisioning network
  ControlPlaneSubnetCidr: '24'
  InternalApiAllocationPools: [{'start': '172.17.0.10', 'end': '172.17.0.200'}]
  TenantAllocationPools: [{'start': '172.16.0.100', 'end': '172.16.0.200'}]
  # Use an External allocation pool which will leave room for floating IP addresses
  ExternalAllocationPools: [{'start': '10.35.184.146', 'end': '10.35.184.157'}]
  # Set to the router gateway on the external network
  ExternalInterfaceDefaultRoute: 10.35.184.158
  # Gateway router for the provisioning network (or Undercloud IP)
  ControlPlaneDefaultRoute: 192.0.5.254
  # Generally the IP of the Undercloud
  EC2MetadataIp: 192.0.5.1
  InternalApiNetworkVlanID: 600
  TenantNetworkVlanID: 603
  ExternalNetworkVlanID: 411
  # Define the DNS servers (maximum 2) for the overcloud nodes
  DnsServers: ["10.35.28.28","8.8.8.8"]
  # May set to br-ex if using floating IP addresses only on native VLAN on bridge br-ex
  NeutronExternalNetworkBridge: "''"
  # The tunnel type for the tenant network (vxlan or gre). Set to '' to disable tunneling.
  NeutronTunnelTypes: ''
  # The tenant network type for Neutron (vlan or vxlan).
  NeutronNetworkType: 'vxlan'
  # The OVS logical->physical bridge mappings to use.
  # NeutronBridgeMappings: 'datacentre:br-ex,tenant:br-isolated'
  # The Neutron ML2 and OpenVSwitch vlan mapping range to support.
  NeutronNetworkVLANRanges: 'datacentre:412:412'
  # Nova flavor to use.
  OvercloudControlFlavor: baremetal
  OvercloudComputeFlavor: baremetal
  # Number of nodes to deploy.
  ControllerCount: 3
  ComputeCount: 2

  # Sets overcloud nodes custom names
  # http://docs.openstack.org/developer/tripleo-docs/advanced_deployment/node_placement.html#custom-hostnames
  ControllerHostnameFormat: 'controller-%index%'
  ComputeHostnameFormat: 'compute-%index%'
  CephStorageHostnameFormat: 'ceph-%index%'
  ObjectStorageHostnameFormat: 'swift-%index%'

6.1.5.4. controller.yaml ファイル

このファイルは /home/stack/baremetal-vlan/nic-configs/ ディレクトリーにあります。以下の例では、br-isolatedbr-ex の 2 つのスイッチを定義しています。nic2br-isolated の下、nic3br-ex に配置されます。

heat_template_version: pike

description: >
  Software Config to drive os-net-config to configure VLANs for the
  controller role.

parameters:
  ControlPlaneIp:
    default: ''
    description: IP address/subnet on the ctlplane network
    type: string
  ExternalIpSubnet:
    default: ''
    description: IP address/subnet on the external network
    type: string
  InternalApiIpSubnet:
    default: ''
    description: IP address/subnet on the internal API network
    type: string
  StorageIpSubnet:
    default: ''
    description: IP address/subnet on the storage network
    type: string
  StorageMgmtIpSubnet:
    default: ''
    description: IP address/subnet on the storage mgmt network
    type: string
  TenantIpSubnet:
    default: ''
    description: IP address/subnet on the tenant network
    type: string
  ManagementIpSubnet: # Only populated when including environments/network-management.yaml
    default: ''
    description: IP address/subnet on the management network
    type: string
  ExternalNetworkVlanID:
    default: ''
    description: Vlan ID for the external network traffic.
    type: number
  InternalApiNetworkVlanID:
    default: ''
    description: Vlan ID for the internal_api network traffic.
    type: number
  TenantNetworkVlanID:
    default: ''
    description: Vlan ID for the tenant network traffic.
    type: number
  ManagementNetworkVlanID:
    default: 23
    description: Vlan ID for the management network traffic.
    type: number
  ExternalInterfaceDefaultRoute:
    default: ''
    description: default route for the external network
    type: string
  ControlPlaneSubnetCidr: # Override this with parameter_defaults
    default: '24'
    description: The subnet CIDR of the control plane network.
    type: string
  DnsServers: # Override this with parameter_defaults
    default: []
    description: A list of DNS servers (2 max for some implementations) that will be added to resolv.conf.
    type: comma_delimited_list
  EC2MetadataIp: # Override this with parameter_defaults
    description: The IP address of the EC2 metadata server.
    type: string

resources:
  OsNetConfigImpl:
    type: OS::Heat::StructuredConfig
    properties:
      group: os-apply-config
      config:
        os_net_config:
          network_config:
            -
              type: ovs_bridge
              name: br-isolated
              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: nic2
                  # force the MAC address of the bridge to this interface
                  primary: true
                -
                  type: vlan
                  vlan_id: {get_param: InternalApiNetworkVlanID}
                  addresses:
                    -
                      ip_netmask: {get_param: InternalApiIpSubnet}
                -
                  type: vlan
                  vlan_id: {get_param: TenantNetworkVlanID}
                  addresses:
                    -
                      ip_netmask: {get_param: TenantIpSubnet}
            -
              type: ovs_bridge
              name: br-ex
              use_dhcp: false
              dns_servers: {get_param: DnsServers}
              members:
                -
                  type: interface
                  name: nic3
                  # force the MAC address of the bridge to this interface
                -
                  type: vlan
                  vlan_id: {get_param: ExternalNetworkVlanID}
                  addresses:
                  -
                    ip_netmask: {get_param: ExternalIpSubnet}
                  routes:
                    -
                      default: true
                      next_hop: {get_param: ExternalInterfaceDefaultRoute}

outputs:
  OS::stack_id:
    description: The OsNetConfigImpl resource.
    value: {get_resource: OsNetConfigImpl}

6.1.5.5. compute.yaml ファイル

このファイルは /home/stack/baremetal-vlan/nic-configs/ ディレクトリーにあります。コンピュートのオプションの大半はコントローラーのオプションと同じです。この例では、nic3 は、外部接続 (Floating IP ネットワーク) に使用される br-ex の下にあります。

heat_template_version: pike

description: >
  Software Config to drive os-net-config to configure VLANs for the
  Compute role.

parameters:
  ControlPlaneIp:
    default: ''
    description: IP address/subnet on the ctlplane network
    type: string
  ExternalIpSubnet:
    default: ''
    description: IP address/subnet on the external network
    type: string
  InternalApiIpSubnet:
    default: ''
    description: IP address/subnet on the internal API network
    type: string
  TenantIpSubnet:
    default: ''
    description: IP address/subnet on the tenant network
    type: string
  ManagementIpSubnet: # Only populated when including environments/network-management.yaml
    default: ''
    description: IP address/subnet on the management network
    type: string
  InternalApiNetworkVlanID:
    default: ''
    description: Vlan ID for the internal_api network traffic.
    type: number
  TenantNetworkVlanID:
    default: ''
    description: Vlan ID for the tenant network traffic.
    type: number
  ManagementNetworkVlanID:
    default: 23
    description: Vlan ID for the management network traffic.
    type: number
  StorageIpSubnet:
    default: ''
    description: IP address/subnet on the storage network
    type: string
  StorageMgmtIpSubnet:
    default: ''
    description: IP address/subnet on the storage mgmt network
    type: string
  ControlPlaneSubnetCidr: # Override this with parameter_defaults
    default: '24'
    description: The subnet CIDR of the control plane network.
    type: string
  ControlPlaneDefaultRoute: # Override this with parameter_defaults
    description: The default route of the control plane network.
    type: string
  DnsServers: # Override this with parameter_defaults
    default: []
    description: A list of DNS servers (2 max for some implementations) that will be added to resolv.conf.
    type: comma_delimited_list
  EC2MetadataIp: # Override this with parameter_defaults
    description: The IP address of the EC2 metadata server.
    type: string
  ExternalInterfaceDefaultRoute:
    default: ''
    description: default route for the external network
    type: string

resources:
  OsNetConfigImpl:
    type: OS::Heat::StructuredConfig
    properties:
      group: os-apply-config
      config:
        os_net_config:
          network_config:
            -
              type: ovs_bridge
              name: br-isolated
              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}
               -
                 next_hop: {get_param: ControlPlaneDefaultRoute}
              members:
                -
                  type: interface
                  name: nic2
                  # force the MAC address of the bridge to this interface
                  primary: true
                -
                  type: vlan
                  vlan_id: {get_param: InternalApiNetworkVlanID}
                  addresses:
                    -
                      ip_netmask: {get_param: InternalApiIpSubnet}
                -
                  type: vlan
                  vlan_id: {get_param: TenantNetworkVlanID}
                  addresses:
                    -
                      ip_netmask: {get_param: TenantIpSubnet}
            -
              type: ovs_bridge
              name: br-ex
              use_dhcp: false
              members:
                -
                  type: interface
                  name: nic3

outputs:
  OS::stack_id:
    description: The OsNetConfigImpl resource.
    value: {get_resource: OsNetConfigImpl}

6.1.6. このシナリオで使用する Red Hat OpenStack Platform director の設定ファイル

6.1.6.1. neutron.conf ファイル

このファイルは、/etc/neutron/ ディレクトリーにあり、以下の情報が含まれています。

[DEFAULT]
service_plugins=odl-router_v2,trunk

6.1.6.2. ml2_conf.ini ファイル

このファイルは /etc/neutron/plugins/ml2/ ディレクトリーにあり、以下の情報が含まれているはずです。

[ml2]
type_drivers = vxlan,vlan,flat,gre
tenant_network_types = vxlan
mechanism_drivers = opendaylight_v2

[ml2_type_vlan]
network_vlan_ranges = datacentre:412:412

[ml2_odl]
password = admin
username = admin
url = http://172.17.1.18:8081/controller/nb/v2/neutron
  1. [ml2] セクションの下には、ネットワーク種別として VXLAN が使用されており、opendaylight_v2 メカニズムドライバーが指定されている点に注意してください。
  2. [ml2_type_vlan] の下には、network-environment.yaml ファイルで設定されているのと同じマッピングを指定する必要があります。
  3. [ml2_odl] の下には、OpenDaylightController にアクセスするための設定が記載されているはずです。

上記の情報を使用して、OpenDaylight コントローラーにアクセスできるかどうかを確認します。

$ curl -H "Content-Type:application/json" -u admin:admin http://172.17.1.18:8081/controller/nb/v2/neutron/networks

6.2. プロバイダーネットワークを使用する模範的なインストールシナリオ

このインストールシナリオでは、テナントネットワークではなく、プロバイダーネットワークを使用した OpenStack と OpenDaylight の例を示します。外部の neutron プロバイダーネットワークは、レイヤー 3 (L3) およびその他のネットワークサービスを提供する物理ネットワークインフラストラクチャーに仮想マシンインスタンスをブリッジングします。大半の場合は、プロバイダーネットワークは、VLAN ID を使用してレイヤー 2 (L2) セグメンテーションを実装します。プロバイダーネットワークは、プロバイダーネットワーク上で仮想マシンインスタンスの起動をサポートする各コンピュートノードでプロバイダーブリッジにマッピングします。

6.2.1. 物理トポロジー

このシナリオのトポロジーは、6 つのノードで構成されます。

  • 1 x director アンダークラウドノード
  • 3 x OpenStack オーバークラウドコントローラー。OpenStack サービスに加えて OpenDaylight SDN コントローラーがインストール済み。
  • 2 x OpenStack オーバークラウドコンピュートノード

6.2.2. 物理ネットワーク環境のプランニング

オーバークラウドコントローラーノードはそれぞれ、4 つのネットワークインターフェースカード (NIC) を使用します。

名前目的

nic1

Management ネットワーク (例: SSH を介したノードへのアクセス)

nic2

Provisioning ネットワーク (PXE, DHCP) および Internal API ネットワーク

nic3

Tenant ネットワーク

nic4

Public API ネットワーク、Floating IP ネットワーク

オーバークラウドのコンピュートノードには、4 つの NIC が実装されます。

名前目的

nic1

Management ネットワーク

nic2

Provisioning ネットワークと Internal API ネットワーク

nic3

Tenant ネットワーク

nic4

Floating IP ネットワーク

アンダークラウドノードには 2 つの NIC が実装されます。

名前目的

nic1

Management ネットワークに使用

nic2

Provisioning ネットワークに使用

6.2.3. NIC の接続性のプランニング

この場合、環境ファイルは、インターフェースの抽象名 (nic1nic2) を使用し、ホストのオペレーティングシステムで提供される実際のデバイス名 (例: eth0eno2 など) は使用しません。同じロールに属するホストには、全く同じネットワークインターフェースデバイス名は必要ありません。1 台のホストで em1em2 のインターフェースを使用するイップで他のホストで eno1eno2 を使用しても全く問題ありません。各 NIC は nic1 および nic2 と呼ばれます。

抽象化された NIC スキームでは、稼働中かつ接続済みのインターフェースにのみ依存します。ホストによってインターフェースが異なる場合には、ホストを接続するのに必要な最小限のインターフェース数を使用すれば十分です。たとえば、1 台のホストに物理インターフェースが 4 つあり、他のホストには 6 つある場合、nic1nic2nic3nic4 のみを使用して、両ホストに 4 本のケーブルを接続します。

6.2.4. ネットワーク、VLAN、IP のプランニング

このシナリオでは、ネットワーク分離を使用して、Management、Provisioning、Internal API、Tenant、Public API、Floating IP のネットワークトラフィックを分離します。

図6.2 このシナリオで使用するネットワークトポロジーの詳細

Detailed network topology used in this scenario

以下の表には、各ネットワークに関連付けられる VLAN ID と IP サブネットをまとめています。

ネットワークVLAN IDIP サブネット

プロビジョニング

ネイティブ

192.0.5.0/24

Internal API

600

172.17.0.0/24

Tenant

554,555-601

172.16.0.0/24

パブリック API

552

192.168.210.0/24

Floating IP

553

10.35.186.146/28

OpenStack Platform director は br-isolated OVS ブリッジを作成し、ネットワーク設定ファイルの定義に従って各ネットワークの VLAN インターフェースを追加します。br-ex ブリッジは director によって自動的に作成され、関連するネットワークインターフェースが接続されます。

ホスト間の接続性を提供する物理ネットワークスイッチが、VLAN ID を適用するように適切に設定されていることを確認します。ホストに接続する全スイッチポートは、前述の VLAN を使用して trunks として設定する必要があります。ここで「trunk」という用語は、複数の VLAN ID が同じポートを通過できるポートという意味で使用しています。

注記

物理スイッチの設定に関する内容は、本書の対象範囲外です。

注記

network-environment.yamlTenantNetworkVlanID で、VXLAN トンネリングを使用する場合の Tenant ネットワークの VLAN タグを定義することができます (VXLAN テナントのトラフィックが VLAN タグ付けされた下層のネットワーク上で転送される)。Tenant ネットワークがネイティブ VLAN 上で実行されるようにした方が望ましい場合には、この値を空にすることも可能です。また、VLAN テナント種別のネットワークを使用する場合には、 TenantNetworkVlanID に指定されている値以外の VLAN タグを使用することができる点にも注意してください。

6.2.5. このシナリオで使用する OpenDaylight の設定ファイル

このシナリオにおける OpenStack と OpenDaylight のデプロイには、アンダークラウドで以下のデプロイメントコマンドを実行しています。

$ openstack overcloud deploy --debug \
  --templates \
  --environment-file "$HOME/extra_env.yaml" \
  --libvirt-type kvm \
  -e /home/stack/baremetal-vlan/network-environment.yaml \
  -e /usr/share/openstack-tripleo-heat-templates/environments/neutron-opendaylight.yaml \
  --log-file overcloud_install.log &> overcloud_install.log

また、本ガイドでは、このシナリオに使用した設定ファイルとその内容を記載し、使用した設定についても説明しています。

6.2.5.1. extra_env.yaml ファイル

このファイルにはパラメーターが 1 つしかありません。

 parameter_defaults:
    OpenDaylightProviderMappings: 'datacentre:br-ex,tenant:br-vlan'

これらは、OpenDaylight によって制御される各ノードのマッピングです。物理ネットワーク datacenter は、br-ex OVS ブリッジにマッピングされ、Tenant ネットワークのトラフィックは br-vlan OVS ブリッジにマッピングされます。

6.2.5.2. undercloud.conf ファイル

このファイルは /home/stack/ ディレクトリーにあります。

注記

ファイルのパスは、カスタマイズされたバージョンの設定ファイルをポイントしています。

  [DEFAULT]
  local_ip = 192.0.5.1/24
  network_gateway = 192.0.5.1
  undercloud_public_vip = 192.0.5.2
  undercloud_admin_vip = 192.0.5.3
  local_interface = eno2
  network_cidr = 192.0.5.0/24
  masquerade_network = 192.0.5.0/24
  dhcp_start = 192.0.5.5
  dhcp_end = 192.0.5.24
  inspection_iprange = 192.0.5.100,192.0.5.120

上記の例では、Provisioning ネットワーク用の 192.0.5.0/24 サブネットが使用されています。物理インターフェース eno2 はアンダークラウドノードでプロビジョニング用に使用されます。

6.2.5.3. network-environment.yaml ファイル

これは、ネットワークを設定するメインのファイルで、/home/stack/baremetal-vlan/ ディレクトリーにあります。以下のファイルでは、VLAN ID と IP サブネットが異なるネットワークとプロバイダーマッピングに指定されます。nic-configs ディレクトリー内の controller.yaml および compute.yaml は、コントローラーノードとコンピュートノードのネットワーク設定を指定するのに使用されます。

この例では、コントローラーノードの数 (3) とコンピュートノードの数 (2) が指定されています。

resource_registry:
  # Specify the relative/absolute path to the config files you want to use for override the default.
  OS::TripleO::Compute::Net::SoftwareConfig: nic-configs/compute.yaml
  OS::TripleO::Controller::Net::SoftwareConfig: nic-configs/controller.yaml

  # Network isolation configuration
  # Service section
  # If some service should be disabled, use the following example
  # OS::TripleO::Network::Management: OS::Heat::None
  OS::TripleO::Network::External: /usr/share/openstack-tripleo-heat-templates/network/external.yaml
  OS::TripleO::Network::InternalApi: /usr/share/openstack-tripleo-heat-templates/network/internal_api.yaml
  OS::TripleO::Network::Tenant: /usr/share/openstack-tripleo-heat-templates/network/tenant.yaml
  OS::TripleO::Network::Management: OS::Heat::None
  OS::TripleO::Network::StorageMgmt: OS::Heat::None
  OS::TripleO::Network::Storage: OS::Heat::None

  # Port assignments for the VIPs
  OS::TripleO::Network::Ports::ExternalVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/external.yaml
  OS::TripleO::Network::Ports::InternalApiVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/internal_api.yaml
  OS::TripleO::Network::Ports::RedisVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/vip.yaml
  OS::TripleO::Network::Ports::StorageVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/noop.yaml
  OS::TripleO::Network::Ports::StorageMgmtVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/noop.yaml

  # Port assignments for the controller role
  OS::TripleO::Controller::Ports::ExternalPort: /usr/share/openstack-tripleo-heat-templates/network/ports/external.yaml
  OS::TripleO::Controller::Ports::InternalApiPort: /usr/share/openstack-tripleo-heat-templates/network/ports/internal_api.yaml
  OS::TripleO::Controller::Ports::TenantPort: /usr/share/openstack-tripleo-heat-templates/network/ports/tenant.yaml
  OS::TripleO::Controller::Ports::ManagementPort: /usr/share/openstack-tripleo-heat-templates/network/ports/noop.yaml
  OS::TripleO::Controller::Ports::StoragePort: /usr/share/openstack-tripleo-heat-templates/network/ports/noop.yaml
  OS::TripleO::Controller::Ports::StorageMgmtPort: /usr/share/openstack-tripleo-heat-templates/network/ports/noop.yaml

  # Port assignments for the compute role
  OS::TripleO::Compute::Ports::ExternalPort: /usr/share/openstack-tripleo-heat-templates/network/ports/external.yaml
  OS::TripleO::Compute::Ports::InternalApiPort: /usr/share/openstack-tripleo-heat-templates/network/ports/internal_api.yaml
  OS::TripleO::Compute::Ports::TenantPort: /usr/share/openstack-tripleo-heat-templates/network/ports/tenant.yaml
  OS::TripleO::Compute::Ports::ManagementPort: /usr/share/openstack-tripleo-heat-templates/network/ports/noop.yaml
  OS::TripleO::Compute::Ports::StoragePort: /usr/share/openstack-tripleo-heat-templates/network/ports/noop.yaml
  OS::TripleO::Compute::Ports::StorageMgmtPort: /usr/share/openstack-tripleo-heat-templates/network/ports/noop.yaml

  # Port assignments for service virtual IPs for the controller role
  OS::TripleO::Controller::Ports::RedisVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/vip.yaml
  OS::TripleO::NodeUserData: /home/stack/baremetal-vlan/firstboot-config.yaml

parameter_defaults:
  # Customize all these values to match the local environment
  InternalApiNetCidr: 172.17.0.0/24
  TenantNetCidr: 172.16.0.0/24
  ExternalNetCidr: 192.168.210.0/24
  # CIDR subnet mask length for provisioning network
  ControlPlaneSubnetCidr: '24'
  InternalApiAllocationPools: [{'start': '172.17.0.10', 'end': '172.17.0.200'}]
  TenantAllocationPools: [{'start': '172.16.0.100', 'end': '172.16.0.200'}]
  # Use an External allocation pool which will leave room for floating IPs
  ExternalAllocationPools: [{'start': '192.168.210.2', 'end': '192.168.210.12'}]
  # Set to the router gateway on the external network
  ExternalInterfaceDefaultRoute: 192.168.210.1
  # Gateway router for the provisioning network (or Undercloud IP)
  ControlPlaneDefaultRoute: 192.0.5.1
  # Generally the IP of the Undercloud
  EC2MetadataIp: 192.0.5.1
  InternalApiNetworkVlanID: 600
  TenantNetworkVlanID: 554
  ExternalNetworkVlanID: 552
  # Define the DNS servers (maximum 2) for the overcloud nodes
  DnsServers: ["10.35.28.28","8.8.8.8"]
  # May set to br-ex if using floating IPs only on native VLAN on bridge br-ex
  NeutronExternalNetworkBridge: "''"
  # The tunnel type for the tenant network (vxlan or gre). Set to '' to disable tunneling.
  NeutronTunnelTypes: ''
  # The tenant network type for Neutron (vlan or vxlan).
  NeutronNetworkType: 'vlan'
  # The OVS logical->physical bridge mappings to use.
  #  NeutronBridgeMappings: 'datacentre:br-ex,tenant:br-isolated'
  # The Neutron ML2 and OpenVSwitch vlan mapping range to support.
  NeutronNetworkVLANRanges: 'datacentre:552:553,tenant:555:601'
  # Nova flavor to use.
  OvercloudControlFlavor: baremetal
  OvercloudComputeFlavor: baremetal
  # Number of nodes to deploy.
  ControllerCount: 3
  ComputeCount: 2

  # Sets overcloud nodes custom names
  # http://docs.openstack.org/developer/tripleo-docs/advanced_deployment/node_placement.html#custom-hostnames
  ControllerHostnameFormat: 'controller-%index%'
  ComputeHostnameFormat: 'compute-%index%'
  CephStorageHostnameFormat: 'ceph-%index%'
  ObjectStorageHostnameFormat: 'swift-%index%'

6.2.5.4. controller.yaml ファイル

ファイルは /home/stack/baremetal-vlan/nic-configs/ ディレクトリーにあります。この例では、br-isolatedbr-vlanbr-ex の 3 つのスイッチを定義します。

heat_template_version: pike

description: >
  Software Config to drive os-net-config to configure VLANs for the
  controller role.

parameters:
  ControlPlaneIp:
    default: ''
    description: IP address/subnet on the ctlplane network
    type: string
  ExternalIpSubnet:
    default: ''
    description: IP address/subnet on the external network
    type: string
  InternalApiIpSubnet:
    default: ''
    description: IP address/subnet on the internal API network
    type: string
  StorageIpSubnet:
    default: ''
    description: IP address/subnet on the storage network
    type: string
  StorageMgmtIpSubnet:
    default: ''
    description: IP address/subnet on the storage mgmt network
    type: string
  TenantIpSubnet:
    default: ''
    description: IP address/subnet on the tenant network
    type: string
  ManagementIpSubnet: # Only populated when including environments/network-management.yaml
    default: ''
    description: IP address/subnet on the management network
    type: string
  ExternalNetworkVlanID:
    default: ''
    description: Vlan ID for the external network traffic.
    type: number
  InternalApiNetworkVlanID:
    default: ''
    description: Vlan ID for the internal_api network traffic.
    type: number
  TenantNetworkVlanID:
    default: ''
    description: Vlan ID for the tenant network traffic.
    type: number
  ManagementNetworkVlanID:
    default: 23
    description: Vlan ID for the management network traffic.
    type: number
  ExternalInterfaceDefaultRoute:
    default: ''
    description: default route for the external network
    type: string
  ControlPlaneSubnetCidr: # Override this with parameter_defaults
    default: '24'
    description: The subnet CIDR of the control plane network.
    type: string
  DnsServers: # Override this with parameter_defaults
    default: []
    description: A list of DNS servers (2 max for some implementations) that will be added to resolv.conf.
    type: comma_delimited_list
  EC2MetadataIp: # Override this with parameter_defaults
    description: The IP address of the EC2 metadata server.
    type: string

resources:
  OsNetConfigImpl:
    type: OS::Heat::StructuredConfig
    properties:
      group: os-apply-config
      config:
        os_net_config:
          network_config:
            -
              type: interface
              name: nic1
              use_dhcp: false
            -
              type: ovs_bridge
              name: br-isolated
              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: nic2
                  # force the MAC address of the bridge to this interface
                  primary: true
                -
                  type: vlan
                  vlan_id: {get_param: InternalApiNetworkVlanID}
                  addresses:
                    -
                      ip_netmask: {get_param: InternalApiIpSubnet}
            -
              type: ovs_bridge
              name: br-ex
              use_dhcp: false
              dns_servers: {get_param: DnsServers}
              members:
                -
                  type: interface
                  name: nic4
                  # force the MAC address of the bridge to this interface
                -
                  type: vlan
                  vlan_id: {get_param: ExternalNetworkVlanID}
                  addresses:
                  -
                    ip_netmask: {get_param: ExternalIpSubnet}
                  routes:
                    -
                      default: true
                      next_hop: {get_param: ExternalInterfaceDefaultRoute}
            -
              type: ovs_bridge
              name: br-vlan
              use_dhcp: false
              dns_servers: {get_param: DnsServers}
              members:
                -
                  type: interface
                  name: nic3
                -
                  type: vlan
                  vlan_id: {get_param: TenantNetworkVlanID}
                  addresses:
                    -
                      ip_netmask: {get_param: TenantIpSubnet}

outputs:
  OS::stack_id:
    description: The OsNetConfigImpl resource.
    value: {get_resource: OsNetConfigImpl}

6.2.5.5. compute.yaml ファイル

このファイルは /home/stack/baremetal-vlan/nic-configs/ ディレクトリーにあります。コンピュートのオプションの大半はコントローラーのオプションと同じです。この例では、nic4 は、外部接続 (Floating IP ネットワーク) に使用される br-ex の下にあります。

heat_template_version: pike

description: >
  Software Config to drive os-net-config to configure VLANs for the
  compute role.

parameters:
  ControlPlaneIp:
    default: ''
    description: IP address/subnet on the ctlplane network
    type: string
  ExternalIpSubnet:
    default: ''
    description: IP address/subnet on the external network
    type: string
  InternalApiIpSubnet:
    default: ''
    description: IP address/subnet on the internal API network
    type: string
  TenantIpSubnet:
    default: ''
    description: IP address/subnet on the tenant network
    type: string
  ManagementIpSubnet: # Only populated when including environments/network-management.yaml
    default: ''
    description: IP address/subnet on the management network
    type: string
  InternalApiNetworkVlanID:
    default: ''
    description: Vlan ID for the internal_api network traffic.
    type: number
  TenantNetworkVlanID:
    default: ''
    description: Vlan ID for the tenant network traffic.
    type: number
  ManagementNetworkVlanID:
    default: 23
    description: Vlan ID for the management network traffic.
    type: number
  StorageIpSubnet:
    default: ''
    description: IP address/subnet on the storage network
    type: string
  StorageMgmtIpSubnet:
    default: ''
    description: IP address/subnet on the storage mgmt network
    type: string
  ControlPlaneSubnetCidr: # Override this with parameter_defaults
    default: '24'
    description: The subnet CIDR of the control plane network.
    type: string
  ControlPlaneDefaultRoute: # Override this with parameter_defaults
    description: The default route of the control plane network.
    type: string
  DnsServers: # Override this with parameter_defaults
    default: []
    description: A list of DNS servers (2 max for some implementations) that will be added to resolv.conf.
    type: comma_delimited_list
  EC2MetadataIp: # Override this with parameter_defaults
    description: The IP address of the EC2 metadata server.
    type: string
  ExternalInterfaceDefaultRoute:
    default: ''
    description: default route for the external network
    type: string

resources:
  OsNetConfigImpl:
    type: OS::Heat::StructuredConfig
    properties:
      group: os-apply-config
      config:
        os_net_config:
          network_config:
            -
              type: interface
              name: nic1
              use_dhcp: false
            -
              type: ovs_bridge
              name: br-isolated
              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}
               -
                 next_hop: {get_param: ControlPlaneDefaultRoute}
                 default: true
              members:
                -
                  type: interface
                  name: nic2
                  # force the MAC address of the bridge to this interface
                  primary: true
                -
                  type: vlan
                  vlan_id: {get_param: InternalApiNetworkVlanID}
                  addresses:
                    -
                      ip_netmask: {get_param: InternalApiIpSubnet}
            -
              type: ovs_bridge
              name: br-ex
              use_dhcp: false
              members:
                -
                  type: interface
                  name: nic4
            -
              type: ovs_bridge
              name: br-vlan
              use_dhcp: false
              dns_servers: {get_param: DnsServers}
              members:
                -
                  type: interface
                  name: nic3
                -
                  type: vlan
                  vlan_id: {get_param: TenantNetworkVlanID}
                  addresses:
                    -
                      ip_netmask: {get_param: TenantIpSubnet}


outputs:
  OS::stack_id:
    description: The OsNetConfigImpl resource.
    value: {get_resource: OsNetConfigImpl}

6.2.6. このシナリオで使用する Red Hat OpenStack Platform director の設定ファイル

6.2.6.1. neutron.conf ファイル

このファイルは、/etc/neutron/ ディレクトリーにあり、以下の情報が含まれています。

[DEFAULT]
service_plugins=odl-router_v2,trunk

6.2.6.2. ml2_conf.ini ファイル

このファイルは /etc/neutron/plugins/ml2/ ディレクトリーにあり、以下の情報が含まれているはずです。

[DEFAULT]
[ml2]
type_drivers = vxlan,vlan,flat,gre
tenant_network_types = vlan
mechanism_drivers = opendaylight_v2
extension_drivers = qos,port_security
path_mtu = 0

[ml2_type_flat]
flat_networks = datacentre

[ml2_type_geneve]
[ml2_type_gre]
tunnel_id_ranges = 1:4094

[ml2_type_vlan]
network_vlan_ranges = datacentre:552:553,tenant:555:601

[ml2_type_vxlan]
vni_ranges = 1:4094
vxlan_group = 224.0.0.1

[securitygroup]
[ml2_odl]
password=<PASSWORD>
username=<USER>
url=http://172.17.0.10:8081/controller/nb/v2/neutron
  1. [ml2] セクションの下には、ネットワーク種別として VXLAN が使用されており、opendaylight_v2 メカニズムドライバーが指定されている点に注意してください。
  2. [ml2_type_vlan] の下には、network-environment.yaml ファイルで設定されているのと同じマッピングを指定する必要があります。
  3. [ml2_odl] の下には、OpenDaylightController にアクセスするための設定が記載されているはずです。

上記の情報を使用して、OpenDaylight コントローラーにアクセスできるかどうかを確認します。

$ curl -H "Content-Type:application/json" -u admin:admin http://172.17.1.18:8081/controller/nb/v2/neutron/networks

第7章 OpenDaylight での高可用性とクラスタリング

Red Hat OpenStack Platform 12 は、neutron と OpenDaylight コントローラーの両方で高可用性クラスタリングをサポートしています。以下の表には、高可用性クラスターを実行可能な推奨アーキテクチャーをまとめています。

ノード種別ノード数ノードのモード

Neutron

3

active/active/active

OpenDaylight

3

active/active/active

コンピュートノード (nova または OVS)

任意

 

OpenDaylight のロールは、コンポーザブルなので、neutron と同じノードまたは別のノードにデプロイすることができます。設定はすべてアクティブモードです。全ノードが要求を処理できます。要求を受信したノードが処理できない場合には、別の適切なノードに転送します。全ノードが相互に同期します。Open_vSwitch Database (OVSDB) スキーマのサウスバウンドでは、利用可能なコントローラーノードが Open vSwitch を共有し、各スイッチはクラスター内の特定のノードによって処理されます。

7.1. 高可用性とクラスタリング向けの OpenDaylight の構成

Red Hat OpenStack Platform director は OpenDaylight コントローラーノードをデプロイするので、OpenDaylight のクラスタリングを設定するために必要な全情報を持っています。OpenDaylight の各ノードには、ノードの ロール (クラスター内での名前) を特定して、クラスター内の他のノード (シード ノード) を少なくともリストした akka.conf 設定ファイルが必要です。ノードには、クラスター内でのデータの複製方法を記述した module-shards.conf ファイルも必要です。Red Hat OpenStack Platform director は、選択したデプロイメントの構成に基づいて適切に設定を行います。akka.conf ファイルはノードに依存する一方、module-shards.conf ファイルはノードとインストールされているデータストア (ならびにそのインストールされた機能。その大部分を制御します) に依存します。

akka.conf の例を以下に示します。

odl-cluster-data {
  akka {
    remote {
      netty.tcp {
        hostname = "192.0.2.1"
      }
    },
    cluster {
      seed-nodes = [
        "akka.tcp://opendaylight-cluster-data@192.0.2.1:2550",
        "akka.tcp://opendaylight-cluster-data@192.0.2.2:2550",
        "akka.tcp://opendaylight-cluster-data@192.0.2.3:2550"],
      roles = [ "member-1" ]
    }
  }
}

上記でリストされているノードは シードノード です。これらは、現在のクラスター設定全体を反映する必要はありません。シードノードのリストを使用して現在のクラスター内の実ノードが到達可能な限り、起動するノードはクラスターに参加することができます。設定ファイルでは、名前の代わりに IP アドレスを使用することができます。

module-shards.conf ファイルの例

module-shards = [
{
  name = "default"
  shards = [{
    name="default"
    replicas = [
      "member-1",
      "member-2",
      "member-3"
    ]
  }]
},
{
  name = "topology"
  shards = [{
    name="topology"
    replicas = [
      "member-1",
      "member-2",
      "member-3"
    ]
  }]
}]

他のデータストアを設定する必要がある場合には、セクションをさらに追加することができます (通常は “inventory” など)。これは必須ではなく、デフォルトの設定は、明示的な設定のないシャードに使用され、大半の場合は問題なく機能します。本シナリオでは、デフォルトのシャードのみを設定します。

module-shards = [
{
  name = "default"
  shards = [{
    name="default"
    replicas = [
      "member-1",
      "member-2",
      "member-3"
    ]
  }]
}]

7.2. クラスターの動作

クラスターは動的には定義されないので、自動調整されません。新規ノードのみを設定しても、その新規ノードを起動して既存のクラスターに接続させることはできません。クラスター管理 RPC を介したノードの追加および削除に関する情報をクラスターに通知する必要があります。

OpenDaylight のクラスターはリーダー/フォロワーモデルをベースとしています。アクティブなノードの 1 つがリーダーとして選択され、残りのアクティブなノードがフォロワーになります。これは、Raft のコンセンサスをベースとするモデルに従って処理されます。この原則に従ってクラスター内のノードの過半数が同意すれば、1 つのトランザクションのみがコミットされます。

OpenDaylight では、ノードがクラスターとの接続を失った場合には、ローカルのトランザクションは先に進められなくなります。最終的には、タイムアウトして (デフォルトでは 10 分)、フロントエンドのアクターが停止します。これらはすべてシャードごとに適用されるので、シャードによって異なるリーダーを持つことができます。この動作により、以下のいずれかの状況となります。

  • 通信がない状態が 10 分未満の場合には、マイノリティーノードがマジョリティーリーダーに再接続します。全トランザクションがロールバックされ、大半のトランザクションは再生されます。
  • 通信がない状態が 10 分以上の場合には、マイノリティーノードが稼働停止し、ログに情報を記録します。読み取り専用の要求はまだ完了するはずですが、変更は永続されず、ノードは自分ではクラスターに再度参加できません。

これは、クラスター外のノードをユーザーがモニタリングする必要があることを意味します。可用性とクラスターの同期をチェックして、同期されていない時間が長すぎる場合には、それらのノードを再起動します。ノードをモニタリングするには、ユーザーは Jolokia REST サービスを使用します (詳しくは、「Jolokia のモニタリング」 を参照)。

7.3. クラスターの要件

ボンディングや MTU などで、クラスターをサポートするために特定のネットワーク要件はありません。クラスターの通信は、高レイテンシーをサポートしていませんが、データセンターレベルのレイテンシーは受容可能です。

7.4. Open vSwitch の設定

各スイッチは、Red Hat OpenStack Platform director によりすべてのコントローラーで設定されます。director には、この操作を自動的に行うのに必要な全情報があります。OVSDB は、クラスターノード内のスイッチ共有をサポートして、一定レベルのロードバランシングを可能にします。ただし、各スイッチはクラスター内の全ノードに連絡して、最初に応答があったノードを選択して、そのノードをデフォルトでマスタースイッチにします。この動作により、コントローラーに割り当てられたノードの クラスタリング が行われ、最も応答が早いノードが大半のスイッチを処理します。

7.5. クラスターのモニタリング

7.5.1. Jolokia のモニタリング

クラスターのステータスをモニタリングするには、OpenDaylight で Jolokia のサポートを有効化する必要があります。データストアのクラスタリングレポートは、Jolokia のアドレス (http://192.0.2.1:8181/jolokia/read/org.opendaylight.controller:Category=Shards,name=member-1-shard-inventory-config,type=DistributedConfigDatastore) から取得することができます。このレポートは、JSON ドキュメント形式です。

注記

お使いの環境に併せて IP addressmember-1 の値を変更する必要があります。どのノードが応答してもよい場合には、IP アドレスは仮想 IP をポイントすることができます。ただし、特定のコントローラーのアドレスを指定した方が、より適切な結果が得られます。

この説明には、各ノードで同じリーダーを指定する必要があります。

注記

クラスターは、アップストリームの OpenDaylight チームが開発した Cluster Monitor Tool でモニタリングすることも可能ですこれは、製品の Github リポジトリーにあります。

このツールは、Red Hat OpenStack Platform 12 の一部ではないため、Red Hat からのサポートは提供していません。

7.6. OpenDaylight のポートについての理解

OpenDaylight の正式な全ポートの一覧は、OpenDaylight の Wiki ページに掲載されています。このシナリオに関連するポートは以下のとおりです。

ポート番号用途

2550

クラスタリング

6653

OpenFlow

6640、6641

OVSDB

8087

neutron

8181

RESTCONF、Jolokia

コントローラーでこれらのポートへのトラフィックをブロックすると、以下のような影響があります。

クラスタリング
クラスター化されたノードは、通信できなくなります。クラスター化モードで実行する場合には、各ノードにピアが少なくとも 1 つ必要です。全トラフィックがブロックされた場合には、コントローラーが停止します (前述したクラスターの動作に関する説明を参照してください)。
OpenFlow
スイッチがコントローラーに到達できなくなります。
OVSDB
Open vSwitch は、コントローラーに到達できなくなります。コントローラーは、アクティブな OVS 接続を開始できますが、スイッチからコントローラーへの ping は失敗して、他のコントローラーにフェイルオーバーします。
neutron
Neutron がコントローラーに到達できなくなります。
RESTCONF
REST エンドポイントを使用する外部ツールは、コントローラーに到達できなくなります。このシナリオで影響を受けるのは、モニタリングツールのみのはずです。

OpenDaylight 側では、ログにはクラスタリングのブロックされたトラフィックのみが表示され、それ以外は何も記録されません (他のポートは、ODL コントローラーとの通信に使用されるため)。現在 Red Hat OpenStack Platform director により開放されるポートは https://github.com/openstack/tripleo-heat-templates/blob/master/puppet/services/opendaylight-api.yaml#L72 に記載されています。

ターゲットデバイスでこれらのポートへのトラフィックをブロックすると、以下のような影響があります。

クラスタリング
上記と同じ
OpenFlow
コントローラーはフローをプッシュできなくなります。
OVSDB
コントローラーはスイッチに到達できなくなります (コントローラーは OVS のパッシブ接続に応答可能となります)。

2 番目の状況では、いずれの場合も、OpenDaylight は設定と稼働状態は別々に維持管理するので、設定は引き続き到達不可能なデバイスをポイントし、コントローラーは引き続きそれらのデバイスへの接続を試みます。

7.7. OpenDaylight のフローについての理解

フロー説明

Neutron → ODL

Neutron、HA プロキシー、ODL の順序です。Pacemaker は仮想 IP (物理 IP が 3 つでバッキング) を管理します。ドライバーは TCP セッションを開いたままに維持しようと試みます。これにより影響を受ける場合があります。

ODL → Neutron

ODL により開始される通信はありません。

ODL → ODL

ODL ノードはポート 2550 (設定可能) で相互に通信します。

ODL → OVS

ODL は、OVSDB (ポート 6640 および 6641) と OpenFlow (ポート 6633) を使用してスイッチと通信します。仮想 IP は関与せず、ODL は全スイッチの IP アドレスを認識しており、各 ODL ノードは全スイッチについて認識しています。

OVS → ODL

ODL は、OVSDB (ポート 6640 および 6641) と OpenFlow (ポート 6633) を使用してスイッチと通信します。仮想 IP は関与せず、ODL が全スイッチを設定して、全コントローラーを認識するようにします。スイッチからコントローラーへの通知は全ノードに送信されます。

7.8. Neutron DHCP エージェント HA

デフォルトの設定では、DHCP エージェントが OVS エージェントと共に全 neutron ノードで実行されます。ロールはコンポーザブルなので、エージェントはコントローラーから分離することができます。DHCP エージェントは、ポートを立ち上げる段階とリースの更新時の高可用性にのみに重要です。ポートの作成時には、neutron が IP と MAC アドレスを割り当てて、ポートが立ち上がる前に全 DHCP エージェントを適切に設定します。この段階の間は、受信する DHCP 要求は、全 DHCP エージェントが応答します。

DHCP エージェントに問題が発生した場合のデータプレーンの可用性を最大限にするために、リース期間が長く設定されており、ノードには更新のための遅延が短時間設定されています。このため、DHCP エージェントはほとんど必要ありませんが、必要とされる場合には、利用できない DHCP エージェントに対して要求を実行するノードは即時にフェイルオーバーし、ブロードキャスト要求を発行して、残りの DHCP エージェントのいずれかを自動的に選択します。

エージェントには、独自のプロセスモニターがあります。systemd によりエージェントが起動され、それらの名前空間が作成されて、その内部でプロセスが開始します。エージェントが機能しなくなった場合には、名前空間は稼動状態のままで、systemd は、他のプロセスを再起動したり終了したりせずにエージェントを再起動します (systemd はそれらのプロセスを所有しません)。次にエージェントは名前空間を再度接続して、実行中の全プロセスと共に再利用します。

7.9. Neutron メタデータエージェント HA

リファレンス実装では、メタデータサービスは、対応する DHCP エージェントと同じ名前空間内で、ネットワークノードと統合されたコントローラー上で実行されます。メタデータプロキシーは、ポート80 をリッスンし、既知のメタデータアドレスを使用して静的ルートでトラフィックを仮想マシンからプロキシーにリダイレクトします。プロキシーは Unix ソケットを使用して同じノード上でメタデータサービスと通信し、メタデータサービスは nova と通信します。Unix ソケットでは、プロキシーとサービス間で IP をルーティング可能にする必要はないので、メタデータサービスは、ノードがルーティングされなくても利用可能です。HA は keepalive と VRRP エレクションを使用して処理されます。フェイルオーバー時間は 2-5 秒です。エージェントは、DHCP エージェントと同じように処理されます (systemd および名前空間)。

Red Hat OpenStack Platform 11 ではメタデータサービスは、カスタムの Python スクリプトですが、Red Hat OpenStack Platform 12 では HAProxy で、メモリー使用量が 30 パーセント低くなります。多くのユーザーはルーターごとに 1 プロキシーを使用し、コントローラーあたりのルーター数が数百もしくは数千にも及ぶため、これは特に重要となります。

第8章 Red Hat OpenStack Platform および OpenDaylight に関する参考資料

コンポーネント参考資料

OpenDaylight

本書に記載されていない詳しい情報については、OpenDaylight Carbon の ドキュメント を参照してください。

Red Hat OpenDaylight Product Guide

Red Hat OpenDaylight と、Red Hat OpenStack Platform との関係についての詳しい情報は、『Red Hat OpenDaylight Product Guide』を参照してください。

Red Hat Enterprise Linux

Red Hat OpenStack Platform は Red Hat Enterprise Linux 7.4 でサポートされています。Red Hat Enterprise Linux のインストールに関する情報は、『Red Hat Enterprise Linux インストールガイド』を参照してください。

Red Hat OpenStack Platform

OpenStack のコンポーネントとそれらの依存関係をインストールするには、Red Hat OpenStack Platform director を使用します。director は基本的な OpenStack アンダークラウドとして使用して、OpenStack ノードを最終的なオーバークラウド内にプロビジョニングして管理します。デプロイしたオーバークラウドに必要な環境に加えて、アンダークラウドをインストールするための追加のホストマシンが 1 台必要となる点に注意してください。詳しい手順は、 『Red Hat OpenStack Platform director のインストールと使用方法』を参照してください。

Red Hat OpenStack Platform director を使用した、Red Hat OpenStack Platform エンタープライズ環境向けの高度な機能 (例: ネットワーク分離、ストレージ設定、SSL 通信、全般的な設定方法) の設定に関する情報は、『オーバークラウドの高度なカスタマイズ』を参照してください。

NFV のドキュメント

NFV を実装する Red Hat OpenStack Platform のデプロイメントに関する詳しい情報は、『ネットワーク機能仮想化 (NFV) のプランニングおよび設定ガイド』を参照してください。