OpenStack Networking

OpenStack Networking

OpenStack Networking により、ネットワーク、サブネット、ポートなどのネットワークオブジェクトを作成、管理でき、これらのネットワークオブジェクトは他の OpenStack サービスも利用できます。プラグインにより様々なネットワーク装置やネットワークソフトウェアを収容することができ、 自由度のある OpenStack アーキテクチャーやデプロイメントが実現できます。

Networking サービス、コード名 neutron、は、ユーザーがクラウドにおけるネットワーク接続性やアドレス割り当てを定義できる API を提供します。Networking サービスを使うと、オペレーターはクラウドネットワークを支えるネットワーク技術として様々な技術を活用できます。 Networking サービスは、 L3 転送や NAT から負荷分散、境界 ファイアウォール (perimeter firewall)、 仮想プライベートネットワーク (VPN) などまで様々なネットワークサービスを設定、管理するための API も提供しています。

以下のコンポーネントがあります。

API サーバー

OpenStack Networking API は、レイヤー 2 ネットワークと IP アドレス管理 (IPAM) をサポートしています。また、レイヤー 3 ルーター用の API 拡張もサポートしており、これによりレイヤー 2 ネットワーク間のルーティング、および外部ネットワークへのゲートウェイが提供されます。 OpenStack Networking に対応するプラグインは増え続けており、ルーター、スイッチ、仮想スイッチ、SDN コントローラーなどの様々な製品やオープンソースのネットワーク技術で相互運用性が実現されています。

OpenStack Networking プラグインとエージェント

ポートの接続と抜去、ネットワークとサブネットの作成、IP アドレスの割り当てを行います。選択したプラグインは、そのクラウドで使用されるベンダーや技術により異なります。大事なのは、同時には 1 つのプラグインしか使用できないことです。

メッセージングキュー

API 操作を完了するためにエージェント間でやり取りされる RPC 要求を受信し宛先に届けます。 ML2 プラグインで Open vSwitchLinux bridge の ML2 メカニズムドライバーを使う場合、 neutron サーバーと各ハイパーバイザー上で動作する neutron エージェント間の RPC にメッセージキューが使用されます。

概念

様々なネットワークトポロジーを作るには、ネットワークやサブネットの作成、設定を行い、Compute などの他の OpenStack サービスに仮想デバイスをこれらのネットワークのポートに接続するように指示します。 OpenStack Networking の主要な利用者は OpenStack Compute で、 Networking を使ってインスタンスに対する接続性を提供します。特に、 OpenStack Networking では、各テナントは複数のプライベートネットワークを所有でき、テナント自身の IP アドレス割り当てスキームを使うことができます。他のテナントが使用する IP アドレスと重複する IP アドレスも使用できます。テナントネットワークとプロバイダーネットワークという 2 種類のネットワークがあります。ネットワーク作成時に指定すれば、どちらのネットワークもテナント間で共有させることができます。

プロバイダーネットワーク

Provider networks offer layer-2 connectivity to instances with optional support for DHCP and metadata services. These networks connect, or map, to existing layer-2 networks in the data center, typically using VLAN (802.1q) tagging to identify and separate them.

Provider networks generally offer simplicity, performance, and reliability at the cost of flexibility. Only administrators can manage provider networks because they require configuration of physical network infrastructure. Also, provider networks only handle layer-2 connectivity for instances, thus lacking support for features such as routers and floating IP addresses.

In many cases, operators who are already familiar with virtual networking architectures that rely on physical network infrastructure for layer-2, layer-3, or other services can seamlessly deploy the OpenStack Networking service. In particular, provider networks appeal to operators looking to migrate from the Compute networking service (nova-network) to the OpenStack Networking service. Over time, operators can build on this minimal architecture to enable more cloud networking features.

一般には、 レイヤー 3 操作を行う OpenStack Networking のソフトウェアコンポーネントは、最も性能と信頼性に影響を与えるコンポーネントです。性能と信頼性を向上させるため、プロバイダーネットワークでは、レイヤー 3 操作を物理ネットワーク基盤に移しています。

ある特定のユースケースでは、従来の仮想化とベアメタルホストが混在する、かなり大きな物理ネットワーク基盤を使った環境に、 OpenStack 環境があります。 OpenStack 環境内で動作するアプリケーションが OpenStack 環境外のアプリケーションに直接レイヤー 2 (通常は VLAN を使用) でのアクセスが必要な場合があります。

Self-service networks

Self-service networks primarily enable general (non-privileged) projects to manage networks without involving administrators. These networks are entirely virtual and require virtual routers to interact with provider and external networks such as the Internet. Self-service networks also usually provide DHCP and metadata services to instances.

In most cases, self-service networks use overlay protocols such as VXLAN or GRE because they can support many more networks than layer-2 segmentation using VLAN tagging (802.1q). Furthermore, VLANs typically require additional configuration of physical network infrastructure.

IPv4 self-service networks typically use private IP address ranges (RFC1918) and interact with provider networks via source NAT on virtual routers. Floating IP addresses enable access to instances from provider networks via destination NAT on virtual routers. IPv6 self-service networks always use public IP address ranges and interact with provider networks via virtual routers with static routes.

The Networking service implements routers using a layer-3 agent that typically resides at least one network node. Contrary to provider networks that connect instances to the physical network infrastructure at layer-2, self-service networks must traverse a layer-3 agent. Thus, oversubscription or failure of a layer-3 agent or network node can impact a significant quantity of self-service networks and instances using them. Consider implementing one or more high-availability features to increase redundancy and performance of self-service networks.

ユーザーはプロジェクト内の接続性を提供するテナントネットワークを作成できます。デフォルトでは、テナントネットワークは完全に分離されており、他のプロジェクトとは共有できません。 OpenStack Networking は以下の種類のネットワーク分離技術、オーバーレイ技術をサポートしています。

Flat

すべてのインスタンスが同じネットワークにあります。これは、ホストとも共有できます。VLAN タギングや他のネットワーク分割が行われません。

VLAN

ユーザーは、 VLAN ID (802.1Q タグ) を使って、物理ネットワークに存在する VLAN に対応するプロバイダーネットワークやテナントネットワークを作成できます。これにより、インスタンスは環境内で互いに通信できます。また、インスタンスは、同じレイヤー 2 VLAN 上にある、専用のサーバー、ファイアウォール、ロードバランサー、その他のネットワーク基盤と通信することもできます。

GRE と VXLAN

VXLAN と GRE は、オーバーレイプロトコルで、オーバーレイネットワークを作成し、コンピュートインスタンス間の通信を実現します。 トラフィックが GRE や VXLAN のテナントネットワーク外と通信するには、Networking ルーターが必要です。直接接続されたテナントネットワークを、インターネットなどの外部ネットワークと接続するためにも、ルーターは必要です。ルーターは Floating IP を使って外部ネットワークから直接インスタンスに接続できるようにするためにも必要です。

Tenant and provider networks

サブネット

IP アドレスブロックと関連する設定です。サブネットは、テナントネットワークとプロバイダーネットワークの両方に networking サービスが提供する元々の IPAM (IP アドレス管理) として知られています。新しいポートがネットワークに作成された際に、 IP アドレスを割り当てるのにサブネットは使用されます。

サブネットプール

通常、エンドユーザーは任意の有効な IP アドレスでサブネットを作成でき、他に何の制約もありません。しかしながら、場合によっては、管理者やテナントが、アドレスプールをあらかじめ定義し、サブネット作成時にこのプールからアドレスを自動割り当てする方がよい場面があります。

サブネットプールを使うと、どのアドレスが使用できるかは、すべてのサブネットは定義されたプール内になければいけないという制約により決まります。また、同じプールから割り当てた 2 つのサブネットでアドレスの再利用や重複はできません。

詳しい情報は サブネットプール を参照してください。

ポート

ポートは、仮想サーバーの NIC などの 1 つのデバイスを、仮想ネットワークに接続する接続点です。ポートは、そのポートで使用される MAC アドレスや IP アドレスなどの関連するネットワーク設定の表現でもあります。

ルーター

Routers provide virtual layer-3 services such as routing and NAT between self-service and provider networks or among self-service networks belonging to a project. The Networking service uses a layer-3 agent to manage routers via namespaces.

セキュリティーグループ

Security groups provide a container for virtual firewall rules that control ingress (inbound to instances) and egress (outbound from instances) network traffic at the port level. Security groups use a default deny policy and only contain rules that allow specific traffic. Each port can reference one or more security groups in an additive fashion. The firewall driver translates security group rules to a configuration for the underlying packet filtering technology such as iptables.

Each project contains a default security group that allows all egress traffic and denies all ingress traffic. You can change the rules in the default security group. If you launch an instance without specifying a security group, the default security group automatically applies to it. Similarly, if you create a port without specifying a security group, the default security group automatically applies to it.

注釈

メタデータサービスを使用する場合、デフォルトの出力ルールを削除すると、 169.254.169.254 の TCP ポート 80 へのアクセスが拒否され、その結果インスタンスがメタデータを取得できなくなります。

Security group rules are stateful. Thus, allowing ingress TCP port 22 for secure shell automatically creates rules that allow return egress traffic and ICMP error messages involving those TCP connections.

By default, all security groups contain a series of basic (sanity) and anti-spoofing rules that perform the following actions:

  • Allow egress traffic only if it uses the source MAC and IP addresses of the port for the instance, source MAC and IP combination in allowed-address-pairs, or valid MAC address (port or allowed-address-pairs) and associated EUI64 link-local IPv6 address.
  • Allow egress DHCP discovery and request messages that use the source MAC address of the port for the instance and the unspecified IPv4 address (0.0.0.0).
  • Allow ingress DHCP and DHCPv6 responses from the DHCP server on the subnet so instances can acquire IP addresses.
  • Deny egress DHCP and DHCPv6 responses to prevent instances from acting as DHCP(v6) servers.
  • Allow ingress/egress ICMPv6 MLD, neighbor solicitation, and neighbor discovery messages so instances can discover neighbors and join multicast groups.
  • Deny egress ICMPv6 router advertisements to prevent instances from acting as IPv6 routers and forwarding IPv6 traffic for other instances.
  • Allow egress ICMPv6 MLD reports (v1 and v2) and neighbor solicitation messages that use the source MAC address of a particular instance and the unspecified IPv6 address (::). Duplicate address detection (DAD) relies on these messages.
  • Allow egress non-IP traffic from the MAC address of the port for the instance and any additional MAC addresses in allowed-address-pairs on the port for the instance.

Although non-IP traffic, security groups do not implicitly allow all ARP traffic. Separate ARP filtering rules prevent instances from using ARP to intercept traffic for another instance. You cannot disable or remove these rules.

You can disable security groups including basic and anti-spoofing rules by setting the port attribute port_security_enabled to False.

API 拡張

OpenStack Networking サービスは拡張性があります。API 拡張は 2 つの目的で使用されます。 API に新しい機能をバージョンの変更なしに追加できます。ベンダー固有の特定の機能を追加できます。アプリケーションは、 URI /extensions に GET を行うことで、利用可能な API 拡張の一覧を取得できます。 API 拡張はバージョン毎であることに注意してください。ある API バージョンで利用できた API 拡張は別の API バージョンでは利用できないかもしれません。

DHCP

The optional DHCP service manages IP addresses for instances on provider and self-service networks. The Networking service implements the DHCP service using an agent that manages qdhcp namespaces and the dnsmasq service.

メタデータ

The optional metadata service provides an API for instances to obtain metadata such as SSH keys.

サービスとコンポーネントの構造

サーバー

  • API を提供する、データベースを管理する、など

プラグイン

  • エージェントを管理する

エージェント

  • レイヤー 2/3 の接続性をインスタンスに提供する

  • 物理〜仮想ネットワーク間の変換を扱う

  • メタデータを処理する、など

レイヤー 2 (Ethernet とスイッチング)

  • Linux ブリッジ

  • OVS

レイヤー 3 (IP とルーティング)

  • L3
  • DHCP

その他

  • メタデータ

サービス

ルーティングサービス

VPNaaS

仮想プライベートネットワークサービス (VPNaaS) は VPN 機能セットを実現する neutron 機能拡張です。

LBaaS

負荷分散サービス (LBaaS) API は、ロードバランサーの払い出しと設定を行います。参照実装は HAProxy ソフトウェアロードバランサーをベースとしています。

FWaaS

Firewall-as-a-Service (FWaaS) API は実験的な API で、新しい機能を使う人やベンダーがネットワーク実装の評価に使っています。

Creative Commons Attribution 3.0 License

Except where otherwise noted, this document is licensed under Creative Commons Attribution 3.0 License. See all OpenStack Legal Documents.