kentoh - Fotolia

Probleme bei der Containervernetzung entschärfen

Die Containervernetzung kann Probleme bei umfangreichen Bereitstellungen verursachen. Wir zeigen, wie man den Herausforderungen begegnet.

Dies ist der zweite Beitrag unserer zweiteiligen Artikelserie über die Herausforderungen der Containervernetzung im großen Maßstab. Den ersten Artikel finden Sie hier.

Da die Vernetzung von Softwarecontainern auf Network Address Translation (NAT) beruht – und in Anbetracht der Einschränkungen von NAT selbst –, stehen Netzwerktechniker vor erheblichen Herausforderungen bei der Bereitstellung von Containern innerhalb ihrer Infrastruktur. Doch wenn man versteht, wie Container Hosts das NAT-Modell unterstützen, lassen sich diese Probleme vermeiden.

Werfen wir zunächst einen Blick darauf, wie der Host einen neuen Netzwerk-Namespace erstellt – vom Konzept her ähnlich einer VRF-Instanz (Virtual Routing and Forwarding) im MPLS/VPN-Modell – und eine spezielle Netzwerkschnittstelle, die als virtuelles Ethernet (vEth) bezeichnet wird. Bei einer vEth-Schnittstelle handelt es sich um ein Paar von Endpunkten, die verwendet werden, um Namespaces zu verbinden. Der Host platziert ein Ende von vEth in den Standard-Namespace für die Kommunikation mit der Außenwelt und das andere Ende in den neu angelegten Namespace.

Das vEth im Standard-Namespace wird mit einer Bridge verbunden, die bei Docker etwa docker0 und bei LXC lxcbr0 heißt. Der Host nutzt iptables in Linux, um NAT zu konfigurieren, und einen schlanken DHCP-Server (Dynamic Host Configuration Protocol), zum Beispiel dnsmasq, um Adressen zuzuweisen.

Workaround für NAT

Zum Glück gibt es Techniken, mit denen sich NAT umgehen lässt. Chris Swan, CTO von Cohesive Networks, fasste seine Philosophie zur Containervernetzung in seinem Vortrag auf der Konferenz Container Camp 2014 über die Vernetzung mit Docker treffend zusammen, als er davon sprach, Container zu „Elementen erster Klasse im Netzwerk“ zu machen.

Wir können dies erreichen, indem wir Container direkt mit den Netzwerkschnittstellen von Hosts verbinden. Die Container nutzen das lokale Netzwerk (LAN) gemeinsam mit dem Host. Sie erhalten eine IPv4-Adresse vom DHCP-Server des LANs oder verwenden statische Adressen. Alle Layer-4-Ports sind vollständig verfügbar. Obwohl diese direkte Verfügbarkeit weniger Durcheinander verursacht als die Verwaltung von zugeordneten Ports, erfordert die Einhaltung strikter Sicherheitsmaßnahmen Disziplin.

Eine Methode, um eine direkte Verbindung zu einer physischen Schnittstelle aufzubauen, besteht darin, einen vEth-Endpunkt mit der physischen, für Internetzugriffe offenen Schnittstelle zu überbrücken. Dieser Ansatz verlangt allerdings die Anpassung der physischen Schnittstelle, indem man die IP-Adresse entfernt und sie der Bridge-Schnittstelle zuweist.

Anstatt die Verbindung zu einer physischen Schnittstelle mit dem vEth-Netzwerktyp herzustellen, können System-Administratoren auch den verwirrenderweise macvlan getauften Netzwerktyp nutzen. Der Netzwerktyp macvlan hat nichts zu tun mit den in IEEE 802.1Q standardisierten VLANs. Vielmehr kann man ihn als Methode verstehen, um mehrere MAC-Adressen auf eine einzige Netzwerkschnittstelle zu multiplexen. Der macvlan-Typ wird im Allgemeinen im Bridge-Modus bereitgestellt, was zu einer deutlich einfacheren Bridge als eine herkömmliche lernende Bridge führt. Es findet kein Lernen statt, und das Spanning Tree Protocol ist unnötig.

Eine zweite Möglichkeit, NAT loszuwerden, sieht vor, den Host in einen vollwertigen Router zu verwandeln, der vielleicht sogar das Border Gateway Protocol beherrscht. In dem Fall routet der Host ein Präfix zu den Containern, die sich auf dem Host befinden. Und jeder Container nutzt eine global eindeutige IP-Adresse. Eindeutige Adressen über IPv4 zur Verfügung zu stellen erlaubt angesichts eines nahezu aufgebrauchten IPv4-Adressraums sicherlich keine große Skalierbarkeit. Viel sauberer wird dieses Verfahren, bei der der Host als Router fungiert, mittels IPv6. Dessen spezielles Adressmodell erlaubt einen riesigen und einfach verwaltbaren Adressraum.

Da Layer 3 nicht zu Flooding neigt, beseitigt dessen Einsatz die großen Fehlerdomänen, die in Layer-2-Broadcast-Domänen erzeugt werden. Haben Sie jemals den Zusammenbruch eines Netzwerks erlebt, der das gesamte Rechenzentrum betrifft? Dann ist mit an Sicherheit grenzender Wahrscheinlichkeit bei einer einzelnen Ethernet-Broadcast-Domäne ein Spanning-Tree-Fehler oder sonstiges Flooding-Ereignis aufgetreten.

Problem: Starke Zunahme von MAC-Adressen

Containerschnittstellen mit dem Netzwerk außerhalb zu verbinden, führt jedoch zu einer neuen Gefahr: einer explodierenden Anzahl von MAC-Adressen, die im Rechenzentrumsnetzwerk sichtbar sind. Die Zahl der MAC-Adressen variiert, die ein ToR-Switch (Top of Rack) unterstützen kann. Switches, die mit einer größeren Anzahl von MAC-Adressen umgehen können – ohne dazu auf Frame-Flooding zurückzugreifen – kosten mehr. Wenn das Limit für MAC-Adressen überschritten wird, können physische Netzwerkkarten der Hosts auch in den Promiscuous Mode umschalten – was zu einer Reduzierung der Leistung führt.

Wie lässt sich eine Ende-zu-Ende-Erreichbarkeit zwischen Containern erreichen, die direkt mit physischen Host-Schnittstellen verbunden sind, ohne dass die Layer-2-Weiterleitungstabellen für ToR-Switches den Rahmen sprengen? Hier kommt die ipvlan-Funktion ins Spiel, die Ende 2014 den Weg in den Linux-Kernel fand. Anstatt die MAC-Adresse als Demultiplexer zu verwenden, wie es der macvlan-Treiber macht, nutzt der ipvlan-Treiber die Layer-3-(IP)-Adresse. Wenn der ipvlan-Treiber im L3-Modus betrieben wird, sind die MAC-Adressen der Container nicht im Netzwerk sichtbar. Nur die MAC-Adresse des Hosts für die physische Schnittstelle taucht im Netzwerk auf.

Die ipvlan-Funktion ist im Linux-Kernel 3.19 verfügbar. Allerdings ist eine stabilere Implementierung ab Version 4.0-rc7 vorhanden. Um mit ipvlan zu experimentieren, müssen Sie gegebenenfalls einen benutzerdefinierten Kernel kompilieren, da die Linux-Distributionen meist noch ältere, aber dafür stabilere Kernel verwenden. Das wird sich in den kommenden Versionen aber höchstwahrscheinlich ändern.

Problem: vEth in großem Maßstab

Zu guter Letzt – obwohl es in den meisten Containerumgebungen kaum auffallen dürfte – kann der Einsatz des vEth-Netzwerktyps für umfangreiche Bereitstellungen die Netzwerkleistung von Containern beeinträchtigen. In seiner Präsentation über das Vernetzen in Containern und Containerclustern beschrieb Google-Mitarbeiter Victor Marmol, wie das Unternehmen eine Verminderung der Leistung um 50 Prozent verzeichnete, als es den vEth-Netzwerktyp einsetzte, verglichen mit der Leistung im Standard-Namespace.

Die macvlan- und die ipvlan-Funktion reduzieren einen Teil des Verarbeitungsaufwands, der für den vEth-Netzwerktyp anfällt. Kernel-Entwickler Eric W. Biederman beschrieb den macvlan-Treiber als „einfach, dumm und schnell“. Die Leistung wird im ipvlan-Treiber beibehalten. Mit weiteren Leistungssteigerungen sowohl im macvlan- als auch im ipvlan-Treiber kann in Zukunft gerechnet werden.

Folgen Sie SearchNetworking.de auch auf Twitter, Google+ und Facebook!

Artikel wurde zuletzt im September 2015 aktualisiert

Erfahren Sie mehr über LAN-Design und Netzwerkbetrieb

- GOOGLE-ANZEIGEN

ComputerWeekly.de

Close