7.2. OpenStack Networking のインストール概要
7.2.1. OpenStack Networking のアーキテクチャー
OpenStack Networking は、クラウド管理者が、個々のサービスをどの物理システムで実行するかを決定するにあたって柔軟性を提供します。評価目的の場合には、全サービスデーモンを単一の物理ホストで実行することが可能です。また、各サービスに独自のホストを使用したり、複数のホストにわたって複製して冗長化を行ったりすることもできます。
本章は、クラウドコントローラーのロールをネットワークホストのロールと組み合わせたアーキテクチャーに焦点を当てつつ、仮想マシンインスタンスを実行する複数のコンピュートノードを可能にします。本章でクラウドコントローラーにデプロイされるネットワークサービスは、別のネットワークホストに完全にデプロイすることもできます。これは、仮想マシンインスタンスから外部ネットワークへ大量のネットワークトラフィックがルーティングされる必要のあることが予想される環境に推奨されます。
ネットワーク例の図
ネットワークのサービスおよびエージェントの配置は、要件によって異なります。以下の図は、専用のネットワークノードとテナントネットワークを使用する一般的なデプロイメントモデルです。
2 つのコンピュートノードで Open vSwitch (ovs-agent) を実行し、1 つのネットワークノードで、FWaaS や LBaaS などのサービスを含むネットワーク機能 (L3 ルーティング、DHCP、NAT) を実行します。各コンピュートノードには、テナントトラフィック用と管理用の接続性のために 2 枚のネットワークカードが装備されます。ネットワークノードには、プロバイダートラフィック専用に 3 枚目のネットワークカードが搭載されます。
7.2.2. OpenStack Networking API
OpenStack Networking は、OpenStack Compute のような他のサービスからデバイスによって使用されるネットワーク接続性とアドレス指定を定義するための強力な API を提供します。
OpenStack Compute API には、コンピュートリソースを記述するための、仮想サーバーの抽象化層があります。同様に、OpenStack Networking API には、ネットワークリソースを記述するための仮想ネットワーク/サブネット/ポートの抽象化層があります。さらに詳しい説明は以下のとおりです。
- ネットワーク
- 分離された L2 セグメント。物理ネットワークの世界では VLAN と類似しています。
- サブネット
- v4 または v6 の IP アドレスのブロックおよび関連する設定の状態
- ポート
- 仮想サーバーの NIC など単一のデバイスを仮想ネットワークに接続するための接続ポイント。そのポートで使用する MAC アドレスや IP アドレスなど、関連するネットワーク設定も記述します。
ネットワークおよびサブネットを作成/設定して、リッチなネットワークトポロジーを設定した後に、OpenStack Compute などの他の OpenStack サービスに指示をして、それらのネットワーク上のポートに仮想デバイスを接続することができます。特に、OpenStack Networking は、各テナントによる複数のプライベートネットワークの使用をサポートしており、他のテナントが使用している IP アドレスと重複している場合でも、テナントは独自の IP アドレス指定スキームを選択することが可能です。これにより、極めて高度のクラウドネットワークユースケースが実現となります。たとえば、多層 Web アプリケーションを構築してから、IP アドレスを変更せずに複数のアプリケーションをクラウドに移行するケースがあります。
クラウド管理者が上記の機能をテナントに直接公開しない場合でも、 OpenStack Networking API は管理目的で非常に役立ちます。API はネットワークオファリングのカスタマイズにおいて、はるかに高い柔軟性をクラウド管理者に対して提供します。
7.2.3. OpenStack Networking API の拡張機能
OpenStack Networking API は、プラグインにより、コア API 自体では提供されていない追加のネットワーク機能を有効にするための拡張機能を提供するプラグインを使用することができます。
- プロバイダーネットワーク
- プロバイダーネットワークにより、物理データセンター内のネットワークに直接マップする仮想ネットワークの作成が可能です。これにより、管理者は、インターネットなどのパブリックネットワークへの直接のアクセスをテナントに提供したり、特定の意図や目的が定義された物理ネットワーク環境の既存の VLAN と統合したりすることが可能となります。プロバイダーの拡張機能が有効化されると、管理者権限のある OpenStack Networking のユーザーは、全仮想ネットワーク上の追加のプロバイダー属性を確認することが可能となります。また、そのようなユーザーは、新規プロバイダーネットワークの作成時にプロバイダー属性を指定することができます。Open vSwitch および Linux Bridge の両プラグインは、プロバイダーネットワーク拡張機能をサポートしています。
- レイヤー 3 (L3) ルーティングと ネットワークアドレス変換 (NAT)
- L3 ルーティング API の拡張機能は、抽象 L3 ルーターを提供します。これにより、API ユーザーは、動的なプロビジョニングと設定を行うことができます。このルーターは、OpenStack Networking が制御する単一または複数のレイヤー 2 (L2) ネットワークに接続することが可能です。また、このルーターは、単一または複数のプライベート L2 ネットワークをインターネットなどの共通のパブリック/外部ネットワークに接続するゲートウェイを提供することができます。L3 ルーターは、ルーターを外部ネットワークに接続するゲートウェイポートに基本的な NAT 機能を提供します。このルーターは、外部ネットワーク上のパブリック IP アドレスと、ルーターに接続された L2 ネットワーク上のプライベート IP アドレスの間の静的マッピングを提供する Floating IP アドレスをサポートしています。これにより、外部のパブリックネットワーク上のシステムに Compute インスタンスを選択的に公開することが可能となります。また、必要に応じて、Floating IP アドレスを別の OpenStack Networking ポートに再確保することも可能となります。
- セキュリティグループ
- セキュリティグループおよびルールは、特定のネットワークポートを通過するネットワークトラフィックの種別と方向をフィルタリングします。これにより、Compute インスタンス内に存在するファイアウォールルールを補完する追加のセキュリティレイヤーが提供されます。セキュリティグループは、単一または複数のセキュリティルールを伴うコンテナーオブジェクトです。単一のセキュリティグループで、複数の Compute インスタンスへのネットワークを管理することができます。Floating IP アドレス、Networking LBaaS VIP、ルーターインターフェース、およびインスタンスのために作成されたポートは、セキュリティグループに割り当てられます。セキュリティグループが指定されなかった場合、ポートは
defaultのセキュリティグループに割り当てられます。デフォルトでは、このグループは全受信トラフィックをドロップし、全送信トラフィックを許可します。追加のセキュリティルールはをdefaultセキュリティグループに追加して動作を変更したり、必要に応じて新規セキュリティグループを作成することができます。Open vSwitch、Linux Bridge、VMware NSX、NEC、および Ryu ネットワークのプラグインは現在セキュリティグループをサポートしています。注記
Compute のセキュリティグループとは異なり、OpenStack Networking のセキュリティグループは、インスタンス単位ではなく、ポート単位で適用されます。
7.2.4. OpenStack Networking のプラグイン
当初の OpenStack Compute ネットワーク実装は、Linux VLAN および ファイアウォールを使用してすべてのネットワーク分離を実行する、基本的なネットワークモデルを前提としていました。OpenStack Networing により、plug-in の概念が採用されました。これは、OpenStack Networking API のプラグ可能なバックエンド実装です。プラグインは、多様のテクノロジーを使用して論理 API 要求を実装することが可能です。OpenStack Networking プラグインは、基本的な Linux VLAN や ファイアウォールを使用するものもあれば、L2-in-L3 トンネリングや OpenFlow などのより高度なテクノロジーを採用して同様のメリットを提供するものもあります。
これらのネットワークテクノロジーに対応するプラグインは、現在テスト中で、Red Hat Enterprise Linux OpenStack Platform での使用がサポートされています。
その他のパッケージ済みの利用可能なプラグインには以下が含まれます。
- Open vSwitch (openstack-neutron-openvswitch)
- Linux Bridge (openstack-neutron-linuxbridge)
- Cisco (openstack-neutron-cisco)
- NEC OpenFlow (openstack-neutron-nec)
- VMware (openstack-neutron-vmware)
- Ryu (openstack-neutron-ryu)
プラグインにより、クラウド管理者は、異なるオプションを比較検討して、デプロイメントに適切なネットワークテクノロジーを決定することができます。
7.2.5. VMware NSX の統合
OpenStack Networking は、ネットワーク用の NSX プラグインを使用して、既存の VMware vCenter デプロイメントと統合します。NSX プラグインは、ネットワークノードにインストールされると、NSX コントローラーを有効化して、設定を一元管理したり、管理対象のネットワークノードにプッシュします。ネットワークノードは、ハイパーバイザーとして NSX コントローラーに追加されると管理されているものと見なされます。
以下の図は、NSX デプロイメントの例を示しており、異なるコンピュートノード間で仮想マシン間のトラフィックが通過する経路を図解しています。ネットワークノード上における VMware NSX プラグインと
neutron-server サービスの配置に注意してください。NSX コントローラーは、中央に緑色で示され、ネットワークノードにつながっています。これは、管理関係を示しています。
7.2.6. Open vSwitch の概要
Open vSwitch は、レガシーの Linux ソフトウェアブリッジに置き換わるものとして設計された、ソフトウェア定義ネットワーク (SDN: Software-Defined Networking) の仮想スイッチです。業界標準の NetFlow、OpenFlow、および sFlow をサポートする仮想ネットワークへのスイッチングサービスを提供します。Open vSwitch は、STP、LACP、802.1Q VLAN タグ付けなどのレイヤー 2 (L2) 機能のサポートにより、物理スイッチとの統合も可能です。
Open vSwitch トンネリングは、Open vSwitch のバージョン 1.11.0-1.el6 以降でサポートされています。具体的なカーネルの要件については、以下の表を参照してください。
| 機能 | カーネルの要件 |
|---|---|
| GRE トンネリング | 2.6.32-358.118.1.openstack.el6 以降 |
| VXLAN トンネリング | 2.6.32-358.123.4.openstack.el6 以降 |
7.2.7. Modular Layer 2 (ML2) の概要
ML2 とは、OpenStack Havana で導入された新しいネットワーク用コアプラグインです。以前の単一プラグインのモデルに置き換わる、ML2 のモジュラー型設計により、複数のネットワークテクノロジーが混在する同時操作が可能となります。モノリシックな Open vSwitch および linuxbridge プラグインは、非推奨となっており、将来のリリースでは削除される予定です。これらの機能は、代わりに ML2 のメカニズムに再実装されています。
注記
ML2 はデフォルトのネットワークプラグインで、 Open vSwitch がデフォルトのメカニズムドライバーとして設定されています。
ML2 の背後の要件
以前は、ネットワークのデプロイでは、実装時に選択したプラグインのみしか使用することはできませんでした。たとえば、Open vSwitch プラグインを実行するデプロイは、Open vSwitch のみを単独にしか使えず、linuxbridge などの別のプラグインを同時に実行することは不可能でした。異種の要件を伴う環境では、これは制限事項となっていました。
ML2 ネットワーク種別
複数のネットワークセグメントタイプを同時に操作することができます。また、これらのネットワークセグメントは、ML2 のマルチセグメントネットワークサポートを利用して相互接続することが可能です。ポートは接続性のあるセグメントに自動的にバインドされ、特定のセグメントにバインドする必要はありません。メカニズムドライバーにより、ML2 がサポートするネットワークセグメントタイプは以下のように異なります。
- flat
- GRE
- local
- VLAN
- VXLAN
ml2_conf.ini ファイルの ML2 セクションでさまざまなタイプドライバーが有効化されます。
[ml2] type_drivers = local,flat,vlan,gre,vxlan
ML2 メカニズム
共通のコードベースを使用するメカニズムとしてプラグインが再実装されています。このアプローチにより、コードの再利用が可能になる上、コードのメンテナンスとテストにおける複雑性が大幅に軽減されます。現在サポート対象となっているメカニズムドライバーには以下が含まれます。
- Arista
- Cisco
- Nexus
- Hyper-V Agent
- L2 Population
- Linuxbridge Agent
- Open vSwitch Agent
- Tail-f NCS
ml2_conf.ini ファイルの ML2 セクションでさまざまなメカニズムドライバーが有効化されます。
[ml2] mechanism_drivers = openvswitch,linuxbridge,l2population
7.2.8. ネットワークバックエンドの選択
Red Hat Enterprise Linux OpenStack Platform は、Nova ネットワークと OpenStack Networking (Neutron) という 2 つの明らかに異なるネットワークバックエンドを提供します。Nova ネットワークは OpenStack のテクノロジーロードマップでは廃止予定となっていますが、現在はまだ利用可能な状態です。OpenStack の将来のロードマップでは、OpenStack Networking はソフトウェア定義ネットワーク (SDN) の中核的なコンポーネントと考えられており、活発な開発が進められています。
Nova ネットワークと OpenStack Networking の間には、現在移行パスが存在しないという点は、重要な考慮事項です。この問題は、運用担当者が後で OpenStack Networking にアップグレードするつもりで Nova ネットワークのデプロイを計画している場合に影響を及ぼします。現在、これらのテクノロジーを切り替えるには、手動で作業を行う必要があり、システムを計画的に停止しなければならなくなる可能性が高くなっています。
OpenStack Networking (Neutron) の選択
- オーバーレイネットワークソリューションが必要な場合: OpenStack Networking は、仮想マシントラフィックの分離に GRE または VXLAN トンネリングをサポートします。GRE または VXLAN を使用すると、ネットワークファブリック上で VLAN を設定する必要はありません。物理ネットワークからの唯一の要件は、ノード間の IP 接続性を提供することです。さらに、VXLAN または GRE により、理論上の拡張の上限は 1600 万の一意識別子まで可能となります。これは、802.1q VLAN ID の上限である 4094 をはるかに超えています。Nova ネットワークのネットワーク分離は 802.1q VLAN をベースとしており、GRE または VXLAN によるトンネリングはサポートしていません。
- テナント間で重複する IP アドレスが必要な場合: OpenStack Networking は、異なるテナントが重複や干渉のリスクなしに同じコンピュートノード上で同じサブネット範囲 (例: 192.168.1/24) を使用することができる、Linux カーネルのネットワーク名前空間の機能を利用します。これは大型のマルチテナントデプロイメントに適しています。これに対して、Nova ネットワークは、全テナントが使用するサブネットに常に注意を払う必要のあるフラットなトポロジーを提供します。
- Red Hat 認定のサードパーティー製ネットワークプラグインが必要な場合: デフォルトでは、Red Hat Enterprise OpenStack Platform 5 は、Open vSwitch (OVS) メカニズムドライバーとともにオープンソースの ML2 コアプラグインを使用します。OpenStack Networking のプラグ可能なアーキテクチャーにより、物理ネットワークファブリックおよびその他のネットワーク要件に基づいて、デフォルトの ML2/Open vSwitch ドライバーの代わりにサードパーティー製のネットワークプラグインをデプロイすることができます。Red Hat では、Red Hat Enterprise OpenStack Platform を対象とするネットワークプラグインをより多く認定するために、常にパートナー認定プログラムの強化を図っています。認定プログラムに関するさらに詳しい情報および認定済みのネットワークプラグインについては、 http://marketplace.redhat.com を参照してください。
- VPN-as-a-service (VPNaaS), Firewall-as-a-service (FWaaS) または Load-Balancing-as-a-service (LBaaS) が必要な場合: これらのネットワークサービスは、Networking のみで利用可能で、Nova ネットワークでは提供されていません。Dashboard により、テナントは、管理者が介入する必要なしに、これらのサービスを管理することができます。
Nova ネットワークを選択する場合
- デプロイメントにフラット (タグなし) または VLAN (802.1q タグ付き) ネットワークが必要な場合: これは、拡張性が必要であることに加えて (拡張の上限は、理論上では 4094 VLAN ID ですが、実際には物理スイッチのサポートはこの値を大幅に下回る傾向にあります)、ノード間で必要な VLAN のセットをトランキングするために物理ネットワーク上で適正な設定が不可欠であるため、管理とプロビジョニングが必要であることを意味します。
- デプロイメントにテナント間で重複する IP アドレスが必要ない場合。これは通常、小型のプライベートデプロイメントのみに適しています。
- ソフトウェア定義ネットワーク (SDN) ソリューションまたは物理ネットワークファブリックと対話する機能が必要ない場合。
- セルフサービスの VPN、ファイアウォール、またはロードバランシングサービスが必要ない場。
7.2.9. L2 Population メカニズムドライバーの設定
L2 Population ドライバーはブロードキャスト、マルチキャスト、およびユニキャストのトラフィックを有効化して、大型のオーバーレイネットワークをスケールアウトします。デフォルトでは、Open vSwitch GRE および VXLAN がブロードキャストを各エージェントに複製します。これには、送信先のネットワークをホストしていないエージェントも含まれます。この設計には、多大なネットワークとプロセスのオーバーヘッドを受容する必要があります。L2 Population ドライバーにより導入される代替の設計は、ARP 解決および MAC 学習トラフィックのための部分的なメッシュを実装します。このトラフィックは、対象設定済みのユニキャストとしてカプセル化されることによって、必要なエージェントにのみ送信されます。
L2 population ドライバーを有効化するには、メカニズムドライバーのリストに追加します。また、少なくとも 1 つのトンネリングドライバーが有効化されている必要もあります (GRE と VXLAN のいずれか一方または両方)。
ml2_conf.ini ファイルに適切な設定オプションを追加します。
[ml2] type_drivers = local,flat,vlan,gre,vxlan mechanism_drivers = openvswitch,linuxbridge,l2population
ovs_neutron_plugin.ini ファイルで L2 Population を有効化します。これは、L2 エージェントを実行する各ノードで有効化する必要があります。
[agent] l2_population = True
7.2.10. OpenStack Networking のエージェント
OpenStack Networking Service およびインストール済みのプラグインだけでなく、多数のコンポーネントが一体となって OpenStack 環境にネットワーク機能を提供します。
- L3 エージェント
- L3 エージェントは、openstack-neutron パッケージの一部です。複数の L2 ネットワークに接続し、ゲートウェイサービスを提供することが可能な抽象 L3 ルーターとして機能します。L3 エージェントをホストするノードには、外部ネットワークに接続されたネットワークインターフェース上の手動で設定した IP アドレスを使用してはなりません。その代わりとして、OpenStack Networking での使用に提供されている外部ネットワークからの IP アドレスの範囲が設定されている必要があります。これらの IP アドレスは、内部ネットワークと外部ネットワークの間のリンクを提供するルーターに割り当てられます。選択範囲は、デプロイメント内のルーターごとおよび希望の Floating IP ごとに一意の IP アドレスを提供することが可能な範囲の大きさである必要があります。
- DHCP エージェント
- OpenStack Networking DHCP エージェントは、ネットワーク上で実行される仮想マシンへの IP アドレス確保が可能です。サブネットの作成時にこのエージェントが有効化されて稼働していると、そのサブネットにはデフォルトで DHCP が有効化されます。
- プラグインエージェント
- Open vSwitch や Linux Bridge を含む OpenStack Networking プラグインの多くは、それら独自のエージェントを活用します。プラグイン固有のエージェントは、データパケットを管理する各ノードで実行されます。これには、全コンピュートノードだけでなく、
neutron-dhcp-agentおよびneutron-l3-agentの専用エージェントを実行するノードが含まれます。
7.2.11. テナントとプロバイダーネットワーク
以下の図には、テナントとプロバイダーネットワークの種別の概要と、それらがネットワークトポロジー全体でどのように対話するかを図解しています。
テナントネットワーク
テナントネットワークは、プロジェクト内の接続性のためにユーザーが作成します。これらは、デフォルトで完全に分離され、他のプロジェクトとは共有されません。Networking はさまざまな種別のテナントネットワークをサポートしています。
- フラット
- 全インスタンスが同じネットワークに存在し、そのネットワークは、ホストと共有することも可能です。VLAN タグ付けやその他のネットワーク分離は行われません。
- ローカル
- インスタンスは、ローカルのコンピュートホストに存在し、実質的には外部ネットワークから分離されます。
- VLAN
- Networking では、物理ネットワークにある VLAN に対応する VLAN ID (802.1Q タグ付け)を使用してユーザーが複数のプロバイダーネットワークまたはテナントネットワークを作成することができます。これにより、インスタンスは環境全体で相互に通信を行うことが可能となります。また、専用のサーバー、ファイアウォール、ロードバランサー、および同じレイヤー 2 上にあるその他のネットワークインフラストラクチャーと通信することもできます。
- VXLAN/GRE
- VXLAN および GRE は、ネットワークオーバーレイを使用して、インスタンス間のプライベートの通信をサポートします。ネットワークルーターは、トラフィックが GRE または VXLAN テナントネットワークの外部に通過できるようにするために必要です。また、ルーターは、直接接続されたテナントネットワークを外部ネットワーク (インターネットを含む) に接続するのにも必要とされ、Floating IP アドレスを使用して外部ネットワークから直接インスタンスに接続する機能を提供します。
プロバイダーネットワーク
プロバイダーネットワークは OpenStack の管理者によって作成され、データセンター内の既存の物理ネットワークに直接マップします。このカテゴリーの中で有用なネットワークタイプには、フラット (タグなし) と VLAN (802.1Q タグ付き) があります。ネットワーク作成プロセスの一環としてプロバイダーネットワークがテナント間で共有されるように許可することができます。
7.2.12. 単一ノード上の複数のネットワーク
ML2 Open vSwitch メカニズムドライバーまたは非推奨の Open vSwitch プラグインのいずれかを実行している単一ノード上で、複数の外部ネットワークを稼働させることができるようになりました。
手順7.1 複数のプロバイダーネットワークの作成
eth1を使用する新規外部ネットワークに接続性を提供する Open vSwitch ブリッジを作成します。#ovs-vsctl add-br br-eth1#ovs-vsctl add-port br-eth1 eth1#ip link set eth1 up- ブリッジとルーターのインターフェースは、L3 エージェントにより自動的にマップされます。これは、
/etc/neutron/plugins/openvswitch/ovs_neutron_plugin.iniに作成された物理ネットワークからブリッジへのマッピングをリレーすることによって行われます。たとえば、トンネリングモードでは、L3 エージェントはbr-intを外部ブリッジにパッチし、外部のbr-int上にqルーターのインターフェースを設定します。以下に記載のオプションに空の値を設定して、この動作を/etc/neutron/l3_agent.iniで有効にします。gateway_external_network_id = external_network_bridge =
ネットワークノードで 物理ネットワークが対応する外部のブリッジにマップするようにovs_neutron_plugin.iniを編集します。bridge_mappings = physnet1:br-ex,physnet2:br-eth1
L3 エージェントおよび Open vSwitch エージェントのサービス再起動して、変更を有効にします。#service neutron-l3-agent restart#service neutron-openvswitch-agent restart以下のステップは、2 つの外部ネットワークを同じ Networking ノードに作成する具体的な手順です。続行する前にl3_agent.iniの設定があることを確認してください。 - 新規プロバイダーネットワーク
physnet1および関連するトポロジーを作成します。#neutron net-create ext_net -provider:network_type flat -provider:physical_network physnet1 -router:external=True#neutron subnet-create ext_net -gateway 172.16.0.1 172.16.0.0/24 - -enable_dhcp=False#neutron router-create router1#neutron router-gateway-set router1 ext_net#neutron net-create privnet#neutron subnet-create privnet -gateway 192.168.123.1 192.168.123.0/24 -name privnet_subnet#neutron router-interface-add router1 privnet_subnet - 新規プロバイダーネットワーク
physnet2および関連するトポロジーを作成します。#neutron net-create ext_net2 -provider:network_type flat -provider:physical_network physnet2 -router:external=True#neutron subnet-create ext_net2 -allocation-pool start=192.168.1.200,end=192.168.1.222 -gateway=192.168.1.1 -enable_dhcp=False 192.168.1.0/24#neutron router-create router2#neutron router-gateway-set router2 ext_net2#neutron net-create privnet2#neutron subnet-create privnet2 -gateway 192.168.125.1 192.168.125.0/24 -name privnet2_subnet#neutron router-interface-add router2 privnet2_subnet
7.2.13. 推奨されるネットワークデプロイメント
OpenStack Networking は、コンピュート環境をサポートするネットワークのデプロイにおいて極めて高い柔軟性を提供します。このため、デプロイの厳密なレイアウトは、予想されるワークロード、予想されるスケール、および利用可能なハードウェアの組み合わせによって異なります。
本章では、実例を示す目的で、以下にあげる種別のノードで構成されるネットワークデプロイメントに焦点を当てています。
- サービスノード
- サービスノードは、ネットワーク API をクライアントに公開して、受信要求を処理した後に、他のノードがアクションを実行するためのメッセージキューに転送します。サービスノードは、ネットワークサービス自体とアクティブなネットワークプラグインの両方をホストします。コントローラーノードを使用して、クライアント接続 API および全サービスのスケジューラーをホストする環境では、本章で適用されているように、コントローラーノードがサービスノードの役割も果たします。
- ネットワークノード
- ネットワークノードは、ネットワークのワークロードの大半を処理します。DHCP エージェント、レイヤー 3 (L3) エージェント、レイヤー 2 (L2) エージェント、およびメタデータプロキシをホストします。また、エージェントが必要なプラグインに加えて、プラグインのインスタンスも (そのようなプラグインが使用されている環境で、データパケットを処理するその他すべてのシステムと同様に) 実行します。Open vSwitch プラグインと Linux Bridge プラグインの両方にエージェントが含まれています。
- コンピュートノード
- コンピュートは、コンピュートインスタンス自体をホストします。コンピュートインスタンスをネットワークサービスに接続するには、コンピュートノードも L2 エージェントを実行している必要があります。また、データパケットを処理するその他すべてのシステムと同様に、コンピュートノードもプラグインエージェントのインスタンスを実行する必要もあります。
上記のデプロイメント種別および責任分担は、推奨案に過ぎません。これ以外の分担も同様に有効です。特に、一部の環境では、ネットワークノードとサービスノードが統合される場合があります。
警告
packstack ユーティリティを使用して、または手動で Compute ネットワークを使用するように設定された環境は、OpenStack Networking を使用するように再設定することができます。ただし、Compute インスタンスがすでに作成済みで、Compute ネットワークを使用するように設定されている環境には、このような再設定は現在は推奨されません。このような変更を行う場合は、各コンピュートノードで以下のコマンドを実行して openstack-nova-network サービスをあらかじめ停止します。
#service openstack-nova-network stop
また、
chkconfig コマンドで、openstack-nova-network サービスを永続的に無効にしておく必要もあります。
#chkconfig openstack-nova-network off
重要
アクティブなコントローラーノードを 2 台以上実行している場合には、複数のノードで
nova-consoleauth を実行しないでください。複数の nova-consoleauth インスタンスを実行すると、トークン要求でノード間に競合が発生してエラーとなる可能性があります。
7.2.14. カーネルの要件
OpenStack のネットワークトラフィックを処理するノードには、ネットワーク名前空間の使用をサポートする Red Hat Enterprise Linux カーネルが必要です。また、Open vSwitch プラグインには
2.6.32-431.el6.x86_64 以降のカーネルバージョンが必要です。
Red Hat Enterprise Linux のサポート対象バージョンに含まれるデフォルトのカーネルは両方の要件を満たしています。
Red Hat Enterprise Linux OpenStack Platform の以前のリリースでは、ネットワーク名前空間およびその他の OpenStack 機能をサポートするカスタムの Red Hat Enterprise Linux カーネルを手動でインストールしてブートする必要がありました。今回のリリースでは、この作業は不要となり、OpenStack Networking の要件はすべて、サポート対象の Red Hat Enterprise Linux バージョンに組み込まれるようになりました。