[ English | Indonesia | español | English (United Kingdom) | 한국어 (대한민국) | русский | français | Deutsch ]
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 bridges/switches¶
The combination of containers and flexible deployment options requires implementation of advanced Linux networking features, such as bridges, switches and namespaces.
Bridges/switches provide layer 2 connectivity (similar to switches) among physical, logical, and virtual network interfaces within a host. After a bridge/switch is created, the network interfaces are virtually plugged in to it.
OpenStack-Ansible can use linux bridges or openvswitches to connect physical and logical network interfaces on the host to virtual network interfaces within containers.
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.