4.5. ネットワーキング
OpenStack Networking サービス (neutron) により、エンドユーザーまたはプロジェクトがネットワークリソースを定義および消費できるようになります。OpenStack Networking は、ネットワーク設定のオーケストレーションに加えて、クラウド内のインスタンスのネットワーク接続や IP アドレスを定義するためのプロジェクト向け API を提供します。API 中心のネットワークサービスへの移行により、クラウドアーキテクトと管理者は、物理ネットワークおよび仮想ネットワークのインフラストラクチャーおよびサービスをセキュアにするための優れたプラクティスを考慮する必要があります。
OpenStack Networking は、オープンソースのコミュニティーまたはサードパーティーサービスを使用して API を拡張性を提供するプラグインアーキテクチャーと共に設計されました。アーキテクチャーの設計要件を評価する上で、OpenStack Networking のコアサービス、サードパーティー製品で提供される追加のサービス、物理インフラストラクチャーに実装する必要のある補助サービスを判断しておくことは重要です。
本項では、OpenStack Networking の実装時に、プロセスと適切なプラクティスについて概説します。
4.5.1. ネットワークアーキテクチャー
OpenStack Networking は、複数のノードに複数のプロセスをデプロイするスタンドアロンのサービスです。これらのプロセスは、相互、その他の OpenStack サービスと対話します。OpenStack Networking サービスの主なプロセスは、neutron-server で、OpenStack Networking API を公開し、追加の処理のためにプロジェクト要求をプラグインスイートに渡す Python デーモンです。
OpenStack Networking のコンポーネントは以下のとおりです。
-
Neutron サーバー (
neutron-server
およびneutron-*-plugin
): neutron-server サービスは、Networking API とその拡張機能 (またはプラグイン) と対話するためにコントローラーノード上で実行されます。また、各ポートのネットワークモデルと IP アドレス処理も実施します。neutron-server では、永続データベースへの直接アクセスが必要です。エージェントは、neutron-server を介してデータベースに間接的にアクセスできます。このデータベースは AMQP (Advanced Message Queuing Protocol) を使用して通信します。 - Neutron データベース: データベースは neutron 情報の一元化ソースで、API がデータベースのトランザクションをすべて記録します。これにより、複数の Neutron サーバーが同じデータベースクラスターを共有でき、すべてが同期され、ネットワーク設定トポロジーの永続性が可能になります。
-
プラグインエージェント (
neutron-*-agent
): 各コンピュートノードおよびネットワークノード (L3 および DHCP エージェントあり) で実行され、ローカルの仮想スイッチ (vswitch) 設定を管理します。有効なプラグインは有効なエージェントを決定します。これらのサービスにはメッセージキューのアクセスが必要で、使用されているプラグインによっては、外部ネットワークコントローラーまたは SDN 実装へのアクセスが必要です。OpenDaylight (ODL) や Open Virtual Network (OVN) などの一部のプラグインでは、コンピュートノード上に python エージェントを必要としません。統合には、有効な Neutron プラグインのみが必要です。 -
DHCP エージェント (
neutron-dhcp-agent
): プロジェクトネットワークへの DHCP サービスを提供します。このエージェントはすべてのプラグインで同じで、DHCP 設定を維持します。neutron-dhcp-agent にはメッセージキューのアクセスが必要です。プラグインに応じてオプションになります。 -
メタデータエージェント (
neutron-metadata-agent
、neutron-ns-metadata-proxy
): インスタンスオペレーティングシステムの設定とユーザー指定の初期スクリプト ('userdata') を適用するために使用されるメタデータサービスを提供します。この実装では、cloud-init が送信するメタデータ API 要求をメタデータエージェントにプロキシー化するために、L3 または DHCP エージェント名前空間でneutron-ns-metadata-proxy
を実行する必要があります。 -
L3 エージェント (
neutron-l3-agent
): プロジェクトネットワーク上の仮想マシンの外部ネットワークアクセスに L3/NAT 転送します。メッセージキューのアクセスが必要です。プラグインに応じてオプションになります。 - ネットワークプロバイダーサービス (SDN サーバー/サービス): プロジェクトネットワークに対して追加のネットワークサービスを提供します。これらの SDN サービスは、REST API などの通信チャネルを介して neutron-server、neutron-plugin、およびプラグインエージェントと対話する可能性があります。
以下の図は、OpenStack Networking コンポーネントのアーキテクチャーおよびネットワークフローの図を示しています。
このアプローチは、分散仮想ルーター (DVR) および Layer-3 高可用性 (L3HA) が使用された場合に大幅に変更されることに注意してください。L3HA はルーター間で VRRP を実装するため、これらのモードは neutron のセキュリティーランドスケープを変更します。デプロイメントは、ルーターに対する DoS 攻撃を軽減できるように適切にサイズで強化する必要があります。また、VRRP スプーフィングの脅威に対処するために、ルーター間のローカルネットワークトラフィックを機密として扱う必要があります。DVR はネットワークコンポーネント (ルーティングなど) をコンピュートノードに移行する一方で、まだネットワークノードが必要です。したがって、コンピュートノードはパブリックネットワーク間のアクセスを必要とするため、ファイアウォールルールとセキュリティーモデルがこのアプローチをサポートする必要があるため、公開機能が高まり、お客様が追加でセキュリティーを考慮する必要があります。
4.5.1.1. 物理サーバーでの Neutron サービスの配置
本項では、コントローラーノード、ネットワークノード、および実行中のインスタンス用のコンピュートノードセットが含まれる標準のアーキテクチャーを説明します。物理サーバーのネットワーク接続を確立するために、通常の neutron デプロイメントは、4 つの異なる物理データセンターネットワークで構成されます。
- 管理ネットワーク: OpenStack コンポーネント間の内部通信に使用されます。このネットワークの IP アドレスはデータセンター内でのみ到達でき、管理セキュリティーゾーンとみなされます。デフォルトでは、Management network ロールは Internal API ネットワークにより実行されます。
- ゲストネットワーク: ゲストクラウドデプロイメント内の仮想マシンデータ通信に使用します。このネットワークの IP アドレス要件は、使用中の OpenStack Networking プラグインや、プロジェクトによる仮想ネットワークの選択肢により異なります。このネットワークは、ゲストセキュリティーゾーンとみなされます。
- 外部ネットワーク: 一部のデプロイメントシナリオにおいて、インターネットにアクセスできる仮想マシンを提供するのに使用します。このネットワークの IP アドレスは、インターネット上の誰でも到達できるはずです。このネットワークは、パブリックセキュリティーゾーンにあると見なされます。このネットワークは、neutron 外部ネットワーク により提供されます。これらの neutron VLAN は、外部ブリッジ上でホストされます。これらは Red Hat OpenStack Platform director により作成されませんが、デプロイ後の neutron により作成されます。
- パブリック API ネットワーク: OpenStack Networking API を含むすべての OpenStack API をプロジェクトに公開する。このネットワークの IP アドレスは、インターネット上の誰でも到達できるはずです。これは、IP ブロック内の IP アドレスの完全な範囲より小さい IP 割り当て範囲を使用する外部ネットワークのサブネットを作成することができるので、外部ネットワークと同じネットワークである可能性があります。このネットワークは、パブリックセキュリティーゾーンにあると見なされます。
このトラフィックを別のゾーンに分割することを推奨します。詳細は次のセクションを参照してください。