Suchen
Verloren im Labyrinth der IT-Begriffe? Hier finden Sie Definitionen und Basiswissen zu Rechenzentrums-IT und -Infrastruktur.

Infrastruktur-Komponente für flexible Datacenter-Umgebungen Was ist ein Service Mesh?

| Autor / Redakteur: M.A. Jürgen Höfling / Ulrike Ostler

Auch Services benötigen Services. Wenn man allgemeine, in diversen Applikationen immer wieder nachgefragte Dienste in speziellen Service-Apps zusammenfasst, entsteht ein Service-Mesh.

Firmen zum Thema

All-In-One-Anwendungen werden heute durch engmaschige Netze von kleinen, kompakten Services abgelöst
All-In-One-Anwendungen werden heute durch engmaschige Netze von kleinen, kompakten Services abgelöst
(Bild: Klicker_pixelio.de)

Großvolumige All-in-One-Arbeitslasten werden in Cloud-basierten Rechenzentrumsstrukturen zunehmend durch eine Vielzahl von kleinen, kompakten Programmpaketen ersetzt. Diese kleinteiligen Strukturen sind dabei als (Micro-)Services konzipiert, die sich wechselseitig über Anwendungs-Programmierschnittstellen (API) ihre jeweiligen Aufgaben zuweisen beziehungsweise diese abrufen.

Auf diese Weise ist es in eleganter Weise möglich, ständig wiederkehrende Standardabläufe wie Ver- und Entschlüsselung, Authentifizierung oder das Sammeln und Aufbereiten von Metriken „auszuklammern“, wie man in der Algebra sagen würde, und sie Anwendungen mit ganz unterschiedlichen Funktionen bei Bedarf als Service zur Verfügung zu stellen. Bei großen Workloads kommt dabei ein ganzes Netzwerk von Standard-Services zusammen, das als „Service-Mesh“ eine eigene Infrastruktur-Schicht bildet und auf Applikationsebene ähnlich wie das Transportprotokoll TCP/IP auf der Netzwerk-Ebene für Stabilität, Sicherheit, Lastverteilung und Transportwege-Optimierung sorgt. Ein solches Service-Netz hängt eng mit der Existenz rein Cloud basierter (Multi-Cluster-) Rechenzentren oder auch hybrider Umgebungen von Vor-Ort- Rechenzentren in Kombination mit Cloud-Umgebungen zusammen.

Service-Mesh darf keinen übermäßigen Ballast erzeugen

Cloud native“ Applikationen, also originär auf der Cloud aufsetzende Anwendungen gehören mittlerweile zum IT-Normalbetrieb, wie der letztjährige Report der Cloud Native Computing Foundation zeigt. Eine einzige Cloud native Anwendung kann dabei aus Hunderten von Services bestehen, die wiederum ihrerseits aus Tausenden von Instanzen bestehen. Und jede dieser Instanzen ändert sich unter Umständen in Bruchteilen von Sekunden, weil ein Orchestrierungsinstrument wie etwa Kubernetes die Abläufe, in die die Services eingebunden sind, ständig neu zusammenstellt.

Mit diesem Bündel an Spezial-Programmen lassen sich auch größte Arbeitslasten kompetent abwickeln, womöglich sogar über mehrere Cloud-Cluster. Aber natürlich hat das Ganze einen Preis: Damit die „vielen Köche“ nicht den Brei verderben, sondern ein exquisites Endergebnis erzielen, müssen sie sich ständig austauschen. Der Kommunikationsaufwand steigt also mit der Zahl der Services rapide. Das erfordert neue Verfahren und Technologien, mit denen sich die Anwender erst einmal vertraut machen müssen, bevor sie sie effizient ausnutzen können.

Abgesehen von diesem Einarbeitungs-Aufwand muss die Service-Netz-Architektur intelligent konzipiert sein. Ansonsten führt sie zu nicht mehr tolerierbaren Verzögerungszeiten (Latenz), zu übermäßigem Ressourcenverbrauch, zu ungleich verteilten Arbeits-Teil-Lasten oder auch zu Netzwerk-Unterbrechungen, weil das Ganze zu lange dauert. Und wenn Service-Verbindungen nicht mehr funktionieren und beispielsweise ein Service, der Fehler erzeugt, nicht schnell und effizient aus dem Kreis der Services zeitweilig entfernt wird - so genanntes Circuit Breaking -, dann ist die ganze Applikation lahmgelegt. Dann funktionieren ein hochautomatisierter Bank-Beratungsprozess, eine Produktionsstraße oder ein selbstfahrendes Auto – um nur einige Beispiele zu nennen - nicht mehr in der vorgesehenen Weise.

Wie ein Service-Mesh en Detail funktioniert

Hier wird einmal eine denkbare Aufgabestellung im Detail durchgespielt:

  • Bei einer Anfrage muss die Steuerung des Services-Netze entscheiden, welche Dienste der anfragende Dienst benötigt beziehungsweise ansteuern will. Befinden sich diese im Rechenzentrum Vor-Ort (falls vorhanden) oder in der Cloud?
  • Oft wird die Service-Netz-Steuerung mehrere Zielpunkte finden. Plausibilitätsbetrachtungen und gespeichertes Wissen aus den vergangenen Abläufen helfen bei der korrekten Auswahl.
  • Die Service-Netz-Steuerung versucht die Instanz herauszufinden, bei der die beste und schnellte Antwort zu erwarten ist. Auch hierbei greift der Steuerungsmechanismus auf vergangene Erfahrungsdaten zurück.
  • Die Service-Netz-Steuerung sendet die Anfrage.
  • Antwortet der angesprochene Service nicht - aus welchen Gründen auch immer –, wird ein anderer Ansprechpartner gesucht (natürlich nur, wenn ein solcher in der Vorauswahl ermittelt worden ist)
  • Wenn eine getriggerte Instanz konstant Fehlermeldungen ausgibt, wird sie erst einmal stillgelegt und nicht mehr angesprochen.
  • Wenn die Anfrage eine Zeitüberschreitung erzeugt, versucht die Steuerung es nicht andauernd wieder und erzeugt damit unnütze Last, sondern gibt eine Fehlermeldung aus.
  • Alle bisher beschriebenen Ausgabe-Werte werden durch die Service-Netz-Steuerung in ein Ergebnisbündel zusammengefasst und an ein zentrales Monitoring-System übermittelt.

Technisch umgesetzt wird ein Service Mesh durch einen Server Proxy, also einen Rechner, der als Mittler zwischen zwei Rechnern, dem anfragenden und dem antwortenden Rechner, geschaltet ist und die Kommunikation auf sichere Weise verwaltet.

Die Marktteilnehmer und eine Initiative für mehr Einsatzbreite

Ein Service-Netz ist in der heutigen IT-Welt von vielen Endpoints einerseits und „Rechenzentren im Irgendwo“ andererseits (Vor-Ort, öffentliche Cloud, private Cloud, Multi-Cloud, alles zusammen gemischt) eine gute Sache. Aber es ist auch eine komplexe Angelegenheit, bei der viele Parameter berücksichtigt werden sollten. Vor allem stellt sich auch bei Service-Netzen wie immer in der IT die Frage, inwieweit man durch der Entscheidung für ein bestimmtes Produkt in seinen weiteren Käufen und Aktionen eingeschränkt wird.

Derzeit ist das ursprünglich von Google und IBM zusammen mit dem „“Envoy„ -Team des Uber-Konkurrenten Lyft gestartete OpenSource-Projekt „Istio“ das wohl meistgenutzte Service-Mesh. Es ist für das ebenfalls aus dem Google-Dunstkreis stammende Orchestrierungs-Werkzeug „Kubernetes“ optimiert, ist aber auch in anderen Umgebungen einsetzbar.

Ein weiteres Service Mesh, das von der Cloud Native Computing Foundation gepuschte (ursprünglich von Buoyant stammende) Programmpaket „Linkerd“ war das erste Service-Mesh überhaupt und zumindest bis zur Version 2 ganz für Kubernetes ausgelegt. Seit der Version 2.8 ist Linkerd in Multi-Cluster-Umgebungen und Hybrid-Cloud-Umgebungen einsetzbar und damit unter anderem auch für Fail-over-Szenarien in Rechenzentren verwendbar.

Alternativen zu Istio und Linkerd

Istio und Linkerd sind derzeit führend in Sachen Service Mesh. Mit „Red Hat Open Shift Service Mesh“, „Hashicorp Consul“, „Moesh“ oder „Kume“ gibt es aber noch einige weitere Angebote, die vom Funktionsumfang her mehr oder weniger gut ausgebaut sind. Und die „AWS Mesh App“ ist schon gewichtig dadurch, dass sie in einem Riesenkonzern wie Amazon eingesetzt wird.

Auch wenn einige Service-Netze flexibler verwendbar sind als andere, kann man nicht so einfach mal ein Mesh gegen ein anderes austauschen. Immerhin gibt es mit der Microsoft Service Mesh Interface-Initiative seit letztem Jahr einen Ansatz in Richtung Vereinheitlichung. Die unter anderem von den Service-Mesh-Spezialisten Hashicorp, Buoyant, Solo.io sowie den IT-Schwergewichten Red Hat und VMWare getragene „Koalition der Kompatibilitäts-Willigen“ definiert ein Bündel von APIs für Service-Netze.

Wenn die Definitionen befolgt werden, entsteht eine gewisse Austauschbarkeit der verschiedenen Produkte, ohne dass dabei den Innovationskräften einzelner Hersteller zu starke Fesseln angelegt werden. Die Initiative ist sicher nur ein erster Schritt in Richtung „Industrialisierung von Service-Netzen“, aber der Ansatz ist wichtig für eine breitere Akzeptanz dieser neuen Infrastruktur-Komponente. Denn schließlich gibt eine generische Service-Mesh-Schnittstelle den Entwicklern mehr Freiheiten bei der Entscheidung, welches Service-Mesh sie letztendlich einsetzen wollen.

(ID:46696345)

Über den Autor