Netzwerkarchitektur

OpenStack Networking ist ein eigenständiger Service, der oft mehrere Prozesse über mehrere Knoten hinweg einsetzt. Diese Prozesse interagieren miteinander und andere OpenStack-Dienste. Der Hauptprozess des OpenStack Networking-Dienstes ist Neutron Server, ein Python-Daemon, der die OpenStack Networking API enthüllt und die Tenantanforderungen an eine Suite von Plug-Ins zur weiteren Verarbeitung übergibt.

Die OpenStack Networking Komponenten sind:

Neutron Server (Neutron Server und Neutron-*-Plugin)

Dieser Dienst läuft auf dem Netzwerkknoten, um die Networking API und ihre Erweiterungen zu bedienen. Es erzwingt auch das Netzwerkmodell und die IP-Adressierung jedes Portes. Der Neutronenserver benötigt indirekten Zugriff auf eine persistente Datenbank. Dies geschieht durch Plugins, die mit der Datenbank mit AMQP (Advanced Message Queuing Protocol) kommunizieren.

Plugin Agent (Neutron-*-Agent)

Läuft auf jedem Rechenknoten, um die Konfiguration des lokalen virtuellen Switches (vswitch) zu verwalten. Das Plug-In, das Sie verwenden, bestimmt, welche Agenten ausgeführt werden. Dieser Dienst erfordert einen Warteschlangenzugriff und hängt vom verwendeten Plugin ab. Einige Plugins wie OpenDaylight (ODL) und Open Virtual Network (OVN) benötigen keine Python-Agenten auf Compute-Knoten.

DHCP-Agent (Neutron-DHCP-Agent)

Bietet DHCP-Dienste für Tenant-Netzwerke. Dieser Agent ist das gleiche über alle Plug-Ins und ist verantwortlich für die Wartung der DHCP-Konfiguration. Der Neutron-DHCP-Agent benötigt einen Warteschlangenzugriff. Optional abhängig vom Plug-In.

L3-Agent (Neutron-l3-Agent)

Bietet L3/NAT-Weiterleitung für den externen Netzzugang von VMs auf Tenantnetzwerken. Erfordert den Nachrichtenwarteschlangenzugriff. Optional abhängig vom Plug-In.

Netzwerkanbieterdienste (SDN-Server/Dienste)

Bietet zusätzliche Netzwerkdienste für Tenantnetze an. Diese SDN-Dienste können mit Neutron Server, Neutron-Plugin und Plugin-Agenten über Kommunikationskanäle wie REST-APIs interagieren.

Die folgende Abbildung zeigt ein architektonisches und vernetztes Flussdiagramm der OpenStack Networking Komponenten:

OpenStack Networking Service Platzierung auf physischen Servern

Dieser Leitfaden konzentriert sich auf eine Standardarchitektur, die einen Cloud Controller Host, einen Netzwerk Host und einen Satz von compute Hypervisoren für das Ausführen von VMs umfasst.

Netzwerkkonnektivität von physischen Servern

Ein Standard-OpenStack Networking-Setup hat bis zu vier verschiedene physikalische Rechenzentrumsnetze:

Management-Netzwerk

Wird für die interne Kommunikation zwischen OpenStack-Komponenten verwendet. Die IP-Adressen in diesem Netzwerk sollten nur innerhalb des Rechenzentrums erreichbar sein und gelten als Management Security Domain.

Gastnetzwerk

Wird für die VM-Datenkommunikation innerhalb der Cloud-Bereitstellung verwendet. Die IP-Adressierungsanforderungen dieses Netzwerks hängen vom verwendeten Plug-In von OpenStack Networking und den Netzwerkkonfigurationsmöglichkeiten der virtuellen Netzwerke des Tenants ab. Dieses Netzwerk gilt als Guest Security Domain.

Externes Netzwerk

Wird verwendet, um VMs mit Internetzugang in einigen Bereitstellungsszenarien zur Verfügung zu stellen. Die IP-Adressen in diesem Netzwerk sollten von jedermann im Internet erreichbar sein. Dieses Netzwerk gilt als in der Public Security Domain.

API Netzwerk

Setzt alle OpenStack-APIs, einschließlich der OpenStack Networking API, an Tenant. Die IP-Adressen in diesem Netzwerk sollten von jedermann im Internet erreichbar sein. Dies kann das gleiche Netzwerk wie das externe Netzwerk sein, da es möglich ist, ein Subnetz für das externe Netzwerk zu erstellen, das IP-Zuweisungsbereiche verwendet, um nur weniger als den gesamten Bereich von IP-Adressen in einem IP-Block zu verwenden. Dieses Netzwerk gilt als Public Security Domain.

Weitere Informationen finden Sie im OpenStack Administrator Guide.