第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』ガイドを参照してください。