Software-Container können Probleme im Netzwerk verursachen

Software-Container sind attraktive Alternativen zu Hypervisoren. In großen IT-Umgebungen können Sie Netzwerk-Administratoren das Leben schwer machen.

In diesem ersten Artikel unserer zweiteiligen Serie über die Herausforderungen von Container Networking gehen wir Fragen im Zusammenhang mit Network Address Translation (NAT) nach. Der zweite Beitrag untersucht dann die Möglichkeiten, um diese Herausforderungen zu meistern und weitere potenzielle Probleme zu mildern. Beide Artikel gelten nicht speziell für eine Software-Container-Technologie, sondern gleichermaßen für Linux-Container, Docker, Canonical LXD und andere.

Die Popularität von Infrastructure as a Service (IaaS), basierend auf virtuellen Maschinen (VMs), hat die Vernetzung von Rechenzentren in großen IT-Umgebungen verändert. Genauso wird der Anstieg der Container-Virtualisierung die Data-Center-Ingenieure dazu zwingen, ihre Netzwerkinfrastruktur noch einmal zu überdenken. Abhängig von der Umgebung ist die Lebensdauer der VMs typischerweise in Tagen oder Wochen bemessen. Container werden aber viel flüchtiger sein. Sie springen ins Leben, wenn sie in einem beliebigen Teil des Rechenzentrums benötigt werden. Sie führen dann eine bestimmte Aufgabe aus bevor sie wieder im Äther verschwinden. Das Ergebnis? Das schiere Ausmaß von Containern in großen Umgebungen führt garantiert dazu, dass die Data-Center-Vernetzung nie wieder dieselbe sein wird.

Aber Container Networking ist einfach, oder? Jeder Entwickler, der Docker benutzt hat, kann mit begrenztem Wissen über IP-Netzwerke einen Software-Container mit der Standard-NAT-Konfiguration starten. In einer Entwicklungsumgebung funktionieren solche Netzwerkkonfigurationen ohne Probleme. Jedoch ist die Verwendung von Software-Containern der Auslöser für viele Netzwerkprobleme, besonders in einem großen Netzwerk.

Während die NAT-Protokollübersetzung das historische Wachstum des Consumer-Internet in den späten 1990er Jahren hervorrief, hat die Technik auch Eigenschaften, die die Netzwerk-Skalierbarkeit behindern. Darüber hinaus führt ihre Komplexität zu Herausforderungen für die Netzbetreiber. Hier sind ein paar Gründe, warum:

NAT verhindert, dass der Anwender die IP-Adresse als eindeutige Kennung für einen Endpunkt nutzen kann. Während Sie die Klarheit der IP-Zahlenfolge (zum Beispiel 10.0.0.1 oder 2001:DB8::1) eher in Frage stellen als das Domain Name System (DNS), sollten Sie die Anstrengungen beim Beseitigen von Fehlerursachen berücksichtigen, die Paketerfassung beinhaltet. Das Paket wird im Flug geändert und sieht dann je nach Capture-Punkt anders aus.

NAT macht das Logging schwierig. Idealerweise nutzt die Logging-Funktionalität einen DNS-Namen, jedoch ist dies nicht immer der Fall. Eine nicht eindeutige Kennung in der per NAT veränderten Adresse macht das intuitive Verständnis der Protokolle schwerer.

NAT verschleiert den Prozess der Fehlersuche. Alle im Datenpfad eingeführte Middleware stellt eine weitere Komponente dar, die auf seltsame Weise fehlschlagen und dabei grundlegend das End-to-End-Prinzip des Internet verletzen kann. Einige Gruppen, wie Mobilfunkbetreiber, sind sehr vertraut mit der NAT-Fehlersuche in dem relativ geschlossenen Ökosystem von Mobiltelefonen. Wenn die Anzahl der Container in Ihrem Rechenzentrum sich der Millionen-Marke nähert, fragen Sie sich, ob der Wert, den NAT hinzufügt, die Komplexität ausreichend kompensiert.

Port-Mapping ist unelegant. Nehmen wir Dockers EXPOSE-Schlüsselwort in der Docker-Konfigurationsdatei, das einen Layer-4-Port des Hosts auf einem Container-Port abbildet. Wenn mehrere Software-Container auf einem Webserver auf einem bekannten Port laufen, wie zum Beispiel 80 oder 443, dann brauchen sie einen Reverse-Proxy. Wollen Sie ein anderes Software-Paket im Datenpfad verwalten? Die Portzahl ist aber auf maximal 65535 begrenzt! Wobei man hier zugegeben muss, dass Sie wirklich eine massive Anzahl von Containern pro Host benötigen, um diesen 16-Bit-Portbereich auszuschöpfen.

Im nächsten Artikel erkunden wir weitere Fragen rund um Schwierigkeiten mit der Container-Virtualisierung. Das betrifft auch die damit verbundenen Probleme zunehmender MAC-Adressen und den Abbau der Netzwerk-Performance bei der Verwendung von virtuellen Ethernet-Schnittstellen.

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

Fortsetzung des Inhalts unten

Erfahren Sie mehr über Software-defined Networking

- GOOGLE-ANZEIGEN

ComputerWeekly.de

Close