[ English | русский | Deutsch | 한국어 (대한민국) | English (United Kingdom) | Indonesia | español | français ]
Containervernetzung¶
OpenStack-Ansible stellt Linux-Container (LXC) bereit und verwendet Linux-Bridging zwischen dem Container und den Hostschnittstellen, um sicherzustellen, dass der gesamte Datenverkehr von Containern über mehrere Hostschnittstellen fließt. Dieser Anhang beschreibt, wie die Schnittstellen verbunden sind und wie der Datenverkehr fließt.
Weitere Informationen darüber, wie der OpenStack Networking-Dienst (Neutron) die Schnittstellen für den Datenverkehr verwendet, finden Sie im OpenStack Networking Guide.
Details zur Konfiguration von Netzwerken für Ihre Umgebung finden Sie unter openstack_user_config Einstellungsreferenz.
Physische Hostschnittstellen¶
In einer typischen Produktionsumgebung sind physische Netzwerkschnittstellen in verbundenen Paaren für eine bessere Redundanz und einen höheren Durchsatz kombiniert. Vermeiden Sie die Verwendung von zwei Ports auf derselben Multiport-Netzwerkkarte für dieselbe verbundene Schnittstelle, da ein Netzwerkkartenfehler beide von der Bindung verwendeten physischen Netzwerkschnittstellen betrifft.
Linux-Bridgesn¶
Die Kombination von Containern und flexiblen Bereitstellungsoptionen erfordert die Implementierung erweiterter Linux-Netzwerkfunktionen wie Bridges und Namespaces.
Bridges bieten Layer 2-Konnektivität (ähnlich zu Switches) zwischen physischen, logischen und virtuellen Netzwerkschnittstellen innerhalb eines Hosts. Nachdem eine Bridge erstellt wurde, sind die Netzwerkschnittstellen quasi eingesteckt.
OpenStack-Ansible verwendet Bridges, um physische und logische Netzwerkschnittstellen auf dem Host mit virtuellen Netzwerkschnittstellen in Containern zu verbinden.
Namespaces bieten logisch separate Layer 3-Umgebungen (ähnlich wie Router) innerhalb eines Hosts. Namespaces verwenden virtuelle Schnittstellen für die Verbindung mit anderen Namespaces, einschließlich des Hostnamespace. Diese Schnittstellen, die oft als
veth
-Paare bezeichnet werden, sind virtuell zwischen Namespaces eingefügt, ähnlich wie Patchkabel, die physische Geräte wie Switches und Router verbinden.Jeder Container verfügt über einen Namespace, der eine Verbindung mit dem Hostnamespace mit einem oder mehreren
veth
-Paaren herstellt. Sofern nicht anders angegeben, generiert das System zufällige Namen für `` veth``-Paare.
Das folgende Abbild zeigt, wie die Containernetzwerkschnittstellen mit den Bridges und physischen Netzwerkschnittstellen des Hosts verbunden sind:
Netzwerkdiagramme¶
Hosts mit Diensten, die in Containern ausgeführt werden¶
Das folgende Diagramm zeigt, wie alle Schnittstellen und Bridges miteinander verbunden sind, um eine Netzwerkverbindung zur OpenStack-Bereitstellung bereitzustellen:
Die Schnittstelle lxcbr0
bietet dank dnsmasq (dhcp/dns) + NAT Konnektivität für die Container zur Außenwelt.
Bemerkung
Wenn Sie eine zusätzliche Netzwerkkonfiguration für Ihre Container-Schnittstellen benötigen (z. B. Ändern der Routen auf eth1 für Routen im Verwaltungsnetzwerk), passen Sie bitte Ihre Datei openstack_user_config.yml
an. Siehe openstack_user_config Einstellungsreferenz für weitere Details.
Dienste, die metal
ausgeführt werden (Bereitstellung direkt auf den physischen Hosts)¶
OpenStack-Ansible implementiert den Compute-Dienst auf dem physischen Host und nicht in einem Container. Das folgende Diagramm zeigt, wie Brücken für die Netzwerkverbindung verwendet werden:
Neutron Verkehr¶
Das folgende Diagramm zeigt, wie die Agenten des Netzwerkdienstes (Neutron) mit den Brücken br-vlan
und br-vxlan
zusammenarbeiten. Neutron ist so konfiguriert, dass ein DHCP-Agent, ein L3-Agent und ein Linux Bridge-Agent in einem Netzwerkagentencontainer verwendet werden. Das Diagramm zeigt, wie DHCP-Agenten den Instanzen Informationen (IP-Adressen und DNS-Server) zur Verfügung stellen und wie das Routing auf dem Image funktioniert.
Das folgende Diagramm zeigt, wie virtuelle Maschinen eine Verbindung zu den Br-Vlan- und Br-Vxlan-Brücken herstellen und Datenverkehr an das Netzwerk außerhalb des Hosts senden:
When Neutron agents are deployed „on metal“ on a network node or collapsed
infra/network node, the Neutron Agents
container and respective virtual
interfaces are no longer implemented. In addition, use of the
host_bind_override
override when defining provider networks allows
Neutron to interface directly with a physical interface or bond instead of the
br-vlan
bridge. The following diagram reflects the differences in the
virtual network layout.
The absence of br-vlan
in-path of instance traffic is also reflected on
compute nodes, as shown in the following diagram.