4.2. Planungsnetzwerke

Es ist wichtig, die Netzwerktopologie Ihrer Umgebung und die Subnetze zu planen, damit Sie die Rollen und Dienste ordnungsgemäß zuordnen und diese korrekt miteinander kommunizieren können. Red Hat Enterprise Linux OpenStack Platform 7 benutzt den Neutron Networking-Dienst, der autonom arbeitet und Software-basierte Netzwerke, statische und floating IP-Adresssen und DCHP verwaltet. Der Director stellt diesen Dienst an jedem Controller-Knoten einer Overcloud-Umgebung bereit.
Red Hat Enterprise Linux OpenStack Platform ordnet verschiedene Dienste den separaten Netzwerkdatenverkehrstypen zu, die den verschiedenen Subnetzen in Ihrer Umgebung zugewiesen sind. Diese Netzwerkdatenverkehrstypen sind:

Tabelle 4.2. Netzwerktypen-Zuweisung

Netzwerktypen
Beschreibung
Verwendet von
IPMI
Für Energieverwaltung der Knoten verwendetes Netzwerk. Dieses Netzwerk wird vor der Installation der Undercloud definiert.
Alle Knoten
Provisioning
Der Director benutzt diese Netzwerkdatenverkehrstypen um neue Knoten über PXE Boot bereitzustellen und die Installation der OpenStack Platform auf den Bare-Metal-Servern der Overcloud zu orchestrieren. Dieses Netzwerk wird vor der Installation der Undercloud definiert.
Alle Knoten
Internes API
Das interne API-Netzwerk wird für die Kommunikation zwischen den OpenStack Diensten via API-Kommunikation, RPC-Meldungen und Datenbankkommunikation benutzt.
Controller, Compute, Cinder Storage, Swift Storage
Mandant
Neutron versorgt jeden Mandanten mit seinen eigenen Netzwerken, entweder unter Verwendung von VLAN-Aufgabentrennung, wobei jedes Mandantennetzwerk ein Netzwerk-VLAN ist, oder mithilfe von Tunneling durch VXLAN oder GRE. Netzwerkdatenverkehr ist innerhalb jedes Mandantennetzwerks isoliert. Jedes Mandantennetzwerk hat ein zugehöriges IP-Subnetz und mehrere Mandantennetzwerke können dieselbe Adresse verwenden.
Controller, Compute
Speicher
Block Storage, NFS, iSCSI und andere. Idealerweise wäre dies aus Leistungsgründen auf eine vollkommen separate Switch-Fabric isoliert.
Alle Knoten
Speicherverwaltung
Der OpenStack Objektspeicher (swift) benutzt dieses Netzwerk um Datenobjekte zwischen teilnehmenden Replika-Knoten zu synchronisieren. Der Proxy-Dienst agiert als Zwischenschnittstelle zwischen Benutzeranforderungen und der zugrunde liegenden Speicherebene. Der Proxy empfängt eingehende Anforderungen und sucht die nötigen Replikas um die angeforderten Daten abzurufen. Dienste, die ein Ceph Back-End benutzen, verbinden über das Speicherverwaltungsnetzwerk, da sie nicht mit Ceph direkt interagieren, sondern einen Front-End Dienst verwenden. Beachten Sie, dass der RBD-Driver eine Ausnahme darstellt; dieser Datenverkehr verbindet direkt mit Ceph.
Controller, Ceph Storage, Cinder Storage, Swift Storage
Extern
Ermöglicht dem eingehenden Datenverkehr Instanzen zu erreichen unter Verwendung von 1-zu-1 IP-Adressen Mapping zwischen den floating IP-Adressen und den tatsächlich an Instanzen im Mandantennetzwerk zugewiesenen IP-Adressen. Hostet außerdem das OpenStack Dashboard (horizon) für graphische Systemverwaltung, öffentliche APIs für OpenStack Dienste und führt SNAT bei für Instanzen bestimmtem, eingehenden Datenverkehr aus. Benutzt das externe Netzwerk private IP-Adressen (gemäß RFC-1918), so muss weitere NAT bei aus dem Internet stammendem Datenverkehr durchgeführt werden.
Controller
Bei einer typischen Red Hat Enterprise Linux OpenStack Platform Installation übertrifft die Anzahl von Netzwerktypen häufig die Anzahl von physischen Netzwerkverbindungen. Um alle Netzwerke mit den richtigen Hosts zu verbinden, benutzt die Overcloud VLAN -Tagging um mehr als ein Netzwerk pro Schnittstelle zu liefern. Die meisten Netzwerke sind isolierte Subnetze, aber manche erfordern ein Layer 3 Gateway um Routing für Internet oder Infrastrukturnetzwerkkonnektivität bereitzustellen.
Der Director bietet eine Methode für das Mapping von fünf dieser Datenverkehrstypen zu einem bestimmten Subnetz oder VLANs. Diese Datenverkehrstypen beinhalten:
  • Internes API
  • Speicher
  • Speicherverwaltung
  • Mandantennetzwerk
  • Extern
Jedes nicht zugewiesene Netzwerk ist automatisch demselben Subnetz als Provisioning-Netzwerk zugewiesen.
Das Diagramm unten gibt Ihnen ein Beispiel für eine Netzwerktopologie, bei der die Netzwerke auf separaten VLANs isoliert sind. Jeder Overcloud-Knoten benutzt zwei Schnittstellen (nic2 und nic3) in einem Bond um diese Netzwerke über ihre jeweiligen VLANs zu liefern. Unterdessen kommuniziert jeder Overcloud-Knoten mit der Undercloud über das Provisioning Netzwerk durch ein systemeigenes VLAN, das nic1 verwendet.
Example VLAN Topology using Bonded Interfaces

Abbildung 4.1. Beispiel für VLAN-Topologie, die verbundene Schnittstellen benutzt

Dieses Handbuch bietet mehrere Szenarien, basierend auf der von Ihnen gewünschten Umgebung. Die folgende Tabelle definiert Netzwerkdatenverkehr-Mapping für jedes Szenario:

Tabelle 4.3. Netzwerk-Mappings

Mappings
Gesamtschnittstellen
Gesamt-VLANs
Testumgebung
Netzwerk 1 - Provisioning, Interne API, Speicher, Speicherverwaltung, Mandantennetzwerke, Extern
1
1
Basisumgebung
Netzwerk 1 - Provisioning, Interne API, Speicher, Speicherverwaltung, Mandantennetzwerke
Netzwerk 2 - Extern
2
2
Erweiterte Umgebung mit Ceph-Storage
Netzwerk 1 - Provisioning
Netzwerk 2 - Interne API
Netzwerk 3 - Mandantennetzwerk
Netzwerk 4 - Speicher
Netzwerk 5 - Speicherverwaltung
Netzwerk 6 - Extern
3 (umfasst 2 verbundene Schnittstellen)
6