Netzwerke der Zukunft

Sind Service-Meshes die nächste SDN-Generation?

| Autor / Redakteur: Wolfgang Kirchberger / Andreas Donner

Service-Meshes können viele der Vorteile von SDN bieten; ersetzen aber Software-Defined Networks nicht zwangsläufig!
Service-Meshes können viele der Vorteile von SDN bieten; ersetzen aber Software-Defined Networks nicht zwangsläufig! (Bild: © Vjom - stock.adobe.com)

Der technologische Wandel ist nicht aufzuhalten. Im Gegenteil: Er beschleunigt sich. Viele Unternehmen migrieren in die Cloud, um von deren Vorteilen zu profitieren: Skalierbarkeit, Flexibilität und Agilität. Aber die breite Einführung der Cloud und andere Trends wie Mobility, das Internet der Dinge (IoT) und Big Data-Anwendungen haben tiefgreifende Auswirkungen auf die IT-Infrastrukturen.

Netzwerke und Services auf traditionelle Art und Weise in Hardware zu implementieren macht diese unflexibel, statisch und unfähig, auf die sich schnell verändernden Anforderungen von Applikationen zu reagieren. Um den Übergang von einer Hardware-basierten zu einer Cloud-basierten Umgebung möglichst reibungslos zu gestalten, wollen Unternehmen ihre Netzwerke so aufbauen, dass diese die Vernetzung und Service-Anforderungen der immer dynamischeren Anwendungen erfüllen.

Netzwerke müssen daher konzeptbezogen, skalierbar, programmierbar und automatisiert sein – denn nur so bilden sie die Basis, um Ideen in neue Geschäftschancen zu wandeln. Software-Defined Networks und ihre mögliche nächste Generation – Service-Meshes – erfüllen diese Voraussetzungen und gehen sogar schon darüber hinaus.

Egal, ob Sie containerbasierte Ansätze verfolgen und / oder Funktionen-as-a-Service-Stacks implementieren: in der neuen Welt der Mikro-Service-Architekturen gewinnt das Netzwerk zunehmend an Bedeutung. Die Gründe dafür sind die folgenden:

  • 1. Die Bausteine von Mikro-Service-Anwendungen sind voneinander über das Netzwerk entkoppelt. Sie re-integrieren sich mittels APIsviaRemote Procedure Calls (RPC), welche sich aus CORBA und RMI sowie früheren Webservices wie SOAP und REST hin zu neuen Methoden wie Apache „Thrift“ oder das noch aktuellere gRPC entwickelt haben: ein neues CNCF-Projekt, dass Google für sichere und schnelle http2-basierte RPC bereitgestellt hat. RPC gibt es bereits seit längerer Zeit, aber mittlerweile sind Netzwerke schnell genug, um RPC als generelle Kommunikationsmethode zwischen Applikationskomponenten zu verwenden. Damit lassen sich Monolithen aufbrechen, bei denen Service-Module bislang gebundelt oder kombiniert wurden mit einer enggekoppelten API-Kommunikation basierend auf vollintegrierten Softwarepackages und Softwarebibliotheken. Einige der Leser mögen sich vielleicht noch an das etwas „esoterische“ IPC (Interprocess Communication) erinnern.
  • 2. Jeder Mikro-Service-Baustein skaliert durch Instanz-Replikation. Das Front-End jedes Mikro-Service fungiert damit als Load Balancer, der selbst eine Netzwerk-Komponente ist. Darüber hinaus müssen die Dienste ihre jeweils abhängigen Services entdecken. Das wird üblicherweise mit Domain Name Services (DNS) und Service Discovery durchfgeührt.
  • 3. Um das Scale-Out von Verarbeitungskapazität zu beschleunigen und die Zuverlässigkeit zu verbessern, wird eine Mikro-Serviceinstanz oftmals selbst zwischen Applikationszustand (State) und Speicherung entkoppelt. Der State ist auch wieder über das Netzwerk gespeichert, beispielsweise über die Nutzung von APIs in einen Objektspeicher, eine Datenbank, einen k/v-Speicher oder Streaming- oder Message-Queue. Natürlich gibt es auch noch die guten alten Disksysteme, aber solche Disks und die dazugehörigen Dateisysteme sind selbst oft wiederum virtuelle Netzlaufwerke. Die API- und RPC-Varianten um States zu speichern sind selbst wiederum Micro-Service Systeme und vielleicht am besten vergleichbar mit der Benutzung einer Disk. Sie integrieren die komplexen Abläufe in verteilten Speichersystemen, und erfüllen ihre umfangreichen Aufgaben oft über das Netzwerk.

Service-Mesh

Dies zeigt, warum das Netzwerk ein wichtiger „Kleber“ für Mikro-Services ist. Die Idee und Implementierung eines Service-Mesh ist noch relativ neu, erfährt aber aktuell hohe Aufmerksamkeit. Der Grund dafür: Service-Meshes handhaben die wichtigsten Netzwerk-Herausforderungen, welche unter den Punkten 1 und 2 aufgeführt wurden und sind insbesondere in neuen Projekte wie CNCF Linkerd und Istio integraler Bestandteil

Software-Defined Networks und Service Meshes automatisieren

Es gibt drei generelle Aspekte von Automation, in denen SDN und Service-Meshes in einem unterschiedlichen Kontext eingesetzt werden. Dazu gehören Programmierfähigkeit, Konfiguration und Installation.

Progammierfähigkeit

Programmierfähigkeit ist eine Voraussetzung, wenn es darum geht, die Infrastruktur zu automatisieren. Gut implementierte SDNs sind nicht an die Hardware-Seite des Netzwerks gebunden. Viele davon bieten – wie OpenContrail – eine logisch zentralisierte Steuerebene (Control Plane) mit einem API. Die beiden primären Service-Meshes, die weiter oben angesprochen wurden, ermöglichen dies ebenfalls, sie folgen analog zu SDNs dem Ansatz einer zentralisierten Controlplane mit verteilten Forwardingplane Agents. Istio verfügt über eine zentrale Control Plane-API, während Linkerd verteilter ist. Allerdings stellt es ein API durch sein Namerd Pendant zur Verfügung. Viele würden wahrscheinlich das gRPC API der beiden Service-Meshes als moderner und vorteilhafter als das OpenContrail RESTful API charakterisieren. Dieses ist jedoch sehr gut getestet und in der Praxis bewährt – im Vergleich zu den Istio API-Funktionen, die sich noch im Entwicklungsstadium befinden.

Konfiguration

Einen größeren Unterschied als die APIs macht die Art und Weise, wie der Zugriff auf die Funktionalität erfolgt. Die Service-Meshes verwenden YAML, um Konfigurationsziele anzugeben welche über ein Command-Line-Interface (CLI) geliefert werden können. Es darf angenommen werden, dass die meisten Experten dies als einen Vorteil gegenüber SDNs ansehen welche dies nicht bieten (zumindest OpenContrail unterstützt das heute noch nicht). SDN wie Service-Meshes stellen ebenso webbasierte Schnittstellen zur Verfügung. Die OpenContrail Web-Schnittstelle ist nach fünf Jahren Entwicklungszeit ausgefeilt, hat ein modernes Look&Feel und ist hervorragend für den Einsatz in Unternehmen geeignet.

Im Hinblick auf „Network as a Code“-Trends, lassen sich CLI und YAML einfacher programmieren und die Versionen kontrollieren als dies beispielsweise beim OpenContrail-API der Fall ist. In einer OpenStack-Umgebung lässt sich OpenContrail über YAML-basierte Heat-Vorlagen konfigurieren. In einer Container-basierten K8s oder OpenShift Welt ist dies jedoch weniger relevant. In der K8s Welt wird die OpenContrail SDN-Konfiguration in K8s Objekte annotiert – und absichtlich einfach gehalten, daher wird nur einen Teil der OpenContrail Funktionalität freigelegt. Es bleibt abzuwarten, was in Zukunft mit K8s TPRs, ConfigMaps oder einem eigenen OpenContrail Interpreter möglich wird.

Installation

Linkerd wurde von Buoyant entwickelt, das heißt, jedes Unternehmen erhält Support, wenn dies notwendig ist – Anwender kommen aber auch alleine gut durch den ersten Tag mit der Lösung. Als DaemonSet-Modell zusammen mit Kubernetes implementiert, ist es bereits als vorkonfigurierte Lösung erhältlich. Istio hingegen ist brandneu, verfügt aber bereits über Helm-Charts zur schnellen Implementierung und lässt sich schnell und einfach mit Kubernetes ausliefern. Allerdings bedeutet der Einsatz von Istio, dass der Envoy Proxy der Anwendung in jeden Kubernetes-Pod als Sidecar gebundelt werden muss. Dies ist zwar ein Extra-Schritt, aber mit dem kube-inject-Kommando recht einfach durchzuführen. Sidecar versus DaemonSet Überlegungen beiseite: Das Bundle funktioniert extrem gut und es ist wichtig, dies im Zusammenhang mit dem Debugging zu verstehen.

Im Hinblick auf SDN gibt es eine Reihe unterschiedlicher Implementierungen. OpenContrail arbeitet auf einem von Juniper unterstützten Helm-Chart für eine einfache Installation. Es gibt aber mittlerweile auch Ansible Playbooks und andere vergleichbare Konfigurationsmanagement-Lösungen, die von der Community entwickelt und veröffentlicht wurden.

OpenContrail wird ebenso wie die beiden Service-Meshes als Container implementiert. Ein Unterschied: Der OpenContrail-Forwarding-Agent an jedem Knotenpunkt ist sowohl ein User-Space-Modul als auch ein Kernel-Modul (oder DPDK-basiert oder SmartNIC-basiert). Sie sind zwar containerisiert, aber das Kernel-Modul ist nur dazu da, die insmod-Installation anzustoßen. IT-Administratoren sind unterschiedlicher Meinungen bei diesem Thema. Fakt ist jedoch, dass das Kernel-Modul die Leistung sowie die Integration mit dem Netzwerk-Stack optimiert. Jedoch sind die genutzten Ressourcen nicht Container-basiert und daher unbeschränkt. Das Ressourcen-Management unterscheidet sich damit beispielsweise von dem eines User-Space-Sidecar-Prozesses. Im Endeffekt trifft dies auch für den kube-Proxy oder jedes IP-Tabellen-basierte Networking zu, welche durch OpenContrail vrouter ersetzt werden.

Fazit: Service-Meshes sind nur teilweise die nächste SDN-Generation

Ist damit die Frage nach Service-Meshes als nächste Generation von Software-Defined Networks beantwortet? Einerseits ja: Service-Meshes können viele der Vorteile von SDN bieten. Sie ermöglichen eine Mikro-Segmentierung und Sicherheit für RPC zwischen Mikro-Services – und zwar mit verbesserter TLS-basierter Security- und Identitätszuweisung für jeden einzelnen Mikro-Service. Service-Meshes verfügen über modernes, anwendungsspezifisches Load Balancing und über Fehlerbehebung. Ohne Applikationsanalyse und Code Refactoring lässt sich dies sonst nur schwer realisieren.

Andererseits nein: Service-Meshes ersetzen nicht zwangsläufig SDN – weder heute noch in näherer Zukunft. Sie setzen auf der Containter Network-Schnittstelle (CNI) und der Container-Vernetzung auf – sie laufen über Software-Defined Networks, daher benötigen sie immer noch eine solide Basis. Die meisten IT-Teams wollen außerdem mehrere Sicherheitsschichten, die mittels Isolation das Netzwerk schützen, wenn sie eine Mikro-Segmentierung und Mandantenfähigkeit erhalten. Diese sind integraler Bestandteil von SDN-Lösungen – und zwar ohne die Leistungsfähigkeit zu beeinträchtigen.

Wolfgang Kirchberger.
Wolfgang Kirchberger. (Bild: Juniper Networks)

Software-Defined Networks gewährleisten darüber hinaus die Vernetzung über Cluster, Stacks und Laufzeiten außerhalb von Containern. Damit erfüllen sie selbst die Wünsche von IT-Teams, die auf möglichst niedrige Latenzzeiten fokussiert sind. Auf jeden Fall bieten Service-Meshes eine Reihe von Vorteilen über ihre Netzwerk- und Security-Mehrwerte hinaus. Sie werden in naher Zukunft in beinahe jede Mikro-Service-Architektur und -Stack integriert sein.

Über den Autor

Wolfgang Kirchberger ist Systems Engineering Director der DACH Region bei Juniper Networks.

Kommentare werden geladen....

Sie wollen diesen Beitrag kommentieren? Schreiben Sie uns hier

Anonym mitdiskutieren oder einloggen Anmelden

Avatar
  1. Avatar
    Avatar
    Bearbeitet von am
    Bearbeitet von am
    1. Avatar
      Avatar
      Bearbeitet von am
      Bearbeitet von am

Kommentare werden geladen....

Kommentar melden

Melden Sie diesen Kommentar, wenn dieser nicht den Richtlinien entspricht.

Kommentar Freigeben

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

Freigabe entfernen

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 44939519 / Hardware)