Netzwerke im Zeitalter der Container

Lori Mac VittieDistinguished Engineer und Chief Evangelist | F5

In den vergangenen Jahren haben zunächst die Virtualisierung und inzwischen auch die Containerisierung die Anwendungsdichte auf der jeweiligen Hardware erhöht. Dadurch konzentrieren wir uns zunehmend auf die Herausforderung, den Ost-West-Datenverkehr statt des Nord-Süd-Datenverkehrs zu verwalten.

Für alle, die mit den Datenverkehrsmustern in Rechenzentren noch nicht ganz vertraut sind, hier eine kurze Zusammenfassung: Nord-Süd-Verkehr bezeichnet den Datenverkehr zwischen Benutzer und Anwendung oder zwischen Client und Server sowie den ein- und ausgehenden Datenverkehr eines Rechenzentrums. Ost-West-Verkehr bezeichnet den Datenverkehr zwischen Servern, Anwendungen oder Diensten beziehungsweise ganz allgemein innerhalb eines Rechenzentrums.

Nord-Süd-Datenverkehrsmuster werden durch die wachsende Zahl von Benutzern, Anwendungen und Geräten beeinflusst. Je mehr Verbindungen zwischen Benutzern und Anwendungen erforderlich sind, desto mehr Nord-Süd-Datenverkehr entsteht. Der Ost-West-Datenverkehr wird von Anwendungsarchitekturen und Infrastrukturtechnologien beeinflusst. Wenn Technologien wie Virtualisierung und Container mit neuen Architekturen wie Microservices kombiniert werden, steigt die Zahl der „Anwendungen“ oder „Dienste“, die miteinander kommunizieren müssen, exponentiell an und zwar über das gesamte Rechenzentrum hinweg.

Grundsätzlich, gilt: Je verteilter eine Anwendungsarchitektur und ihre Infrastruktur sind, desto mehr Ost-West-Datenverkehr ist zu erwarten.

Verstärkt wird dieser Anstieg durch den Trend zum „Right-Sizing“ von Anwendungen. Statt die Kapazitätsplanung auf Wachstumsprognosen zu stützen, richtet sich die Kapazität nach dem aktuellen Bedarf – zuzüglich einer kleinen Reserve. Dank ausgereifterer Technologien wie der automatischen Skalierung können wir Ressourcen effizienter nutzen, sodass weniger Rechen- und Netzwerkressourcen ungenutzt bleiben und Budget verbrauchen, ohne einen entsprechenden Mehrwert zu schaffen. Dies ist übrigens einer der Vorteile einer Private Cloud: Ressourcen, die andernfalls ungenutzt blieben und somit verschwendet würden, lassen sich besser ausschöpfen. Möglich wird dies durch eine serviceorientierte Bereitstellung und Verwaltung, die eine bedarfsgerechte Nutzung der Ressourcen in Echtzeit ermöglicht.

Aber ich schweife ab. Entscheidend ist, dass der Ost-West-Datenverkehr aufgrund von Architekturen und Technologien mit einer Geschwindigkeit zunimmt, die wahrscheinlich über der Zunahme des Nord-Süd-Datenverkehrs liegt.

Nun hat jede bedeutende Veränderung bei Anwendungsarchitekturen und Technologien in den vergangenen zwanzig Jahren eine entsprechende Reaktion im „Netzwerk“ ausgelöst. Denn das Netzwerk ist für die Steuerung des Datenverkehrs verantwortlich, unabhängig davon, in welche Richtung er fließt. Ob Ost-West oder Nord-Süd, spielt keine Rolle. Ob virtuell oder physisch – Netzwerktechnik sorgt dafür, dass der Datenverkehr von seinem Ausgangspunkt dorthin gelangt, wo er hinmuss.

Angesichts des durch die Aufteilung von Anwendungen in Microservices noch stärker zunehmenden Ost-West-Datenverkehrs stellt sich nun die Frage: Wie sollte das Netzwerk darauf reagieren? Genauer gesagt: Wie sollten die Dienste im Netzwerk reagieren, um die entscheidenden Funktionen (Verfügbarkeit, Sicherheit, Optimierung) bereitzustellen, die erforderlich sind, um Anwendungen für Benutzer oder zunehmend auch für andere Anwendungen bereitzustellen?

AUSWIRKUNG EINS: VERLAGERUNG ZUR APP

Die erste Antwort auf diese Frage liegt auf der Hand: Anwendungsnahe Dienste müssen näher an die Anwendung rücken. Sie können nicht weiterhin am Rand des Nord-Süd-Datenverkehrs angesiedelt sein und Dienste für Anwendungen bereitstellen, die diese hauptsächlich über den Ost-West-Datenverkehr nutzen. Das wäre eine ineffiziente Nutzung der Netzwerkressourcen, und die dadurch entstehenden Routingmuster führen zu Latenzen bei der Anwendungskommunikation. In diesem Zusammenhang fallen zunehmend Begriffe wie „Tromboning“ und „Hairpinning“. Sie bezeichnen Datenverkehrsmuster, bei denen eine Route durch das Netzwerk eine Maschine verlässt, das Netzwerk in nördlicher Richtung durchläuft und anschließend zur selben Maschine zurückkehrt. Diese Latenz verursacht reale Geschäftskosten durch geringere Produktivität („Einen Moment bitte, mein ‚Computer‘ ist heute langsam“) und dadurch, dass Verbraucher häufiger Warenkörbe und Webanwendungen verlassen. Genau das gilt es zu vermeiden: Wenn der Datenverkehr in Ost-West-Richtung verläuft, sollten sich auch die Dienste in diesem Datenpfad befinden.

AUSWIRKUNG ZWEI: BETRIEBLICHE KOMPATIBILITÄT

Die zweite Antwort lautet, dass sich Dienste wie Lastverteilung und Webanwendungssicherheit in betrieblich kompatiblen Formaten bereitstellen lassen müssen. Mit anderen Worten: Wir werden nicht vor jede neu entstehende Anwendung (oder jeden Microservice) Netzwerkhardware schalten. Daher müssen die Plattformen, auf denen diese Dienste bereitgestellt werden, virtualisiert oder containerisiert sein, damit sie mit neuen Architekturen und Technologien betrieblich kompatibel sind. Außerdem müssen sie programmatisch steuerbar sein und APIs sowie Vorlagen bereitstellen, die einen DevOps-orientierten Ansatz für Bereitstellung und Verwaltung ermöglichen. Dienste – ob Anwendungs- oder Netzwerkdienste – müssen orchestrierbar sein. Wenn sich SDN in die Tools und Frameworks integrieren lässt, die in den Betriebsumgebungen für Infrastruktur und Anwendungen vorherrschen, kann es auch diesen Bedarf erfüllen.

AUSWIRKUNG DREI: DIE ARCHITEKTUR IST ENTSCHEIDEND

Die dritte Antwort lautet, dass die Architektur wichtiger denn je wird. Nur weil ein Netzwerkdienst auf demselben Host wie die zugehörige Anwendung bereitgestellt werden kann, heißt das nicht zwangsläufig, dass er dort bereitgestellt werden sollte. Je nachdem, um welchen Dienst es sich handelt und wie er mit anderen Diensten (und Dienstinstanzen) interagiert, wird die Platzierung zu einem wichtigen Aspekt, den es zu berücksichtigen gilt. Eine schlecht konzipierte Lastverteilung kann beispielsweise zu problematischen Datenverkehrsmustern führen, die unnötige Latenzen verursachen; Latenzen, die sich unmittelbar in Unternehmensgewinne – oder -verluste – umrechnen lassen. Jeder Ausfall (von Hardware, Software, Netzwerk oder Speicher) auf dem Host, auf dem die Dienste in diesem Szenario bereitgestellt werden, führt zu einer Betriebsunterbrechung (und zwar zu einer gravierenden), da auch die Dienste ausfallen, die für die Verfügbarkeit der Anwendungen sorgen. In einer stark entkoppelten Anwendungsarchitektur (Microservices) könnte dies katastrophale Folgen haben, wenn eine hohe Abhängigkeit von diesen Anwendungen besteht.

Eine sorgfältige Abwägung (Architektur) ist erforderlich, damit bewährte Verfahren in Bezug auf Leistung und Verfügbarkeit nicht der Verlockung der naheliegendsten (und einfachsten) Lösung zum Opfer fallen.

NETZWERKTECHNIK BLEIBT EINE ARCHITEKTURAUFGABE

Networking ist und bleibt eine Frage der Architektur. Dabei geht es nicht nur um Formfaktoren – sie sind lediglich ein Mittel, um Netzwerkressourcen schneller und effizienter dort bereitzustellen, wo sie benötigt werden. Entscheidend ist vielmehr die Platzierung dieser Ressourcen und deren Auswirkungen auf alle übergeordneten Ebenen des Stacks: die Netzwerkdienste, die Anwendungsdienste, die Anwendungsleistung und letztlich den geschäftlichen Erfolg – oder Misserfolg.

Netzwerke im Zeitalter von Containern, Virtualisierung und Cloud sind ebenso eine Frage der Architektur wie des Betriebs.

Über den Autor

Lori Mac VittieDistinguished Engineer und Chief Evangelist | F5

Lori MacVittie ist Distinguished Engineer und Chief Evangelist im Office of the CTO von F5 und verfügt über umfassende Expertise in den Bereichen Anwendungsbereitstellung, Automatisierungsstrategie und Infrastruktur. Sie ist dafür bekannt, Komplexität verständlich zu machen – ob sie Leitplanken für KI-Agenten definiert, fragile Multicloud-Architekturen analysiert oder die Grenzen skalierbarer Systeme auslotet. Sie verfügt über mehr als dreißig Jahre Branchenerfahrung in der Anwendungsentwicklung, IT-Architektur sowie im Netzwerk- und Systembetrieb. Bevor sie zu F5 kam, war sie als mehrfach ausgezeichnete Technologie-Redakteurin tätig. MacVittie hat einen Masterabschluss in Informatik und ist eine produktive Autorin, deren Veröffentlichungen die Bereiche Sicherheit, Cloud und Unternehmensarchitektur abdecken. Außerdem spielt sie leidenschaftlich gern Brett- und Videospiele und vertritt mit voller Überzeugung klare Ansichten zum Thema Käse.

Weitere Blogbeiträge von Lori Mac Vittie