第10章 Red Hat OpenStack Platform ネットワーキングサービス

OpenStack Networking サービス (neutron) により、エンドユーザーまたはプロジェクトがネットワークリソースを定義および消費できるようになります。OpenStack Networking は、ネットワーク設定のオーケストレーションに加えて、クラウド内のインスタンスのネットワーク接続や IP アドレスを定義するためのプロジェクト向け API を提供します。API 中心のネットワークサービスへの移行により、クラウドアーキテクトと管理者は、物理ネットワークおよび仮想ネットワークのインフラストラクチャーおよびサービスをセキュアにするための優れたプラクティスを考慮する必要があります。

OpenStack Networking は、オープンソースのコミュニティーまたはサードパーティーサービスを使用して API を拡張性を提供するプラグインアーキテクチャーと共に設計されました。アーキテクチャーの設計要件を評価する上で、OpenStack Networking のコアサービス、サードパーティー製品で提供される追加のサービス、物理インフラストラクチャーに実装する必要のある補助サービスを判断しておくことは重要です。

本項では、OpenStack Networking の実装時に、プロセスと適切なプラクティスについて概説します。

10.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 はネットワークコンポーネント (ルーティングなど) をコンピュートノードに移行する一方で、まだネットワークノードが必要です。したがって、コンピュートノードはパブリックネットワーク間のアクセスを必要とするため、ファイアウォールルールとセキュリティーモデルがこのアプローチをサポートする必要があるため、公開機能が高まり、お客様が追加でセキュリティーを考慮する必要があります。