SLO, SLI, SLA für vSphere with Tanzu

Dieser Blogbeitrag ist aus einer Diskussion entstanden und wird das Thema SLO, SLI und SLA im Kontext von "vSphere with Tanzu" behandeln. Wobei der Kernpunkt auf der Berechnung von SLA liegt.  Dieser Blog-Beitrag soll keinesfalls als Einleitung verstanden werden, er dient eher als Überblick.

Was ist SLO, SLI, SLA?

Fangen wir man an mit der kurzen Erklärung der Begriffen…

SLO steht für Service-Level-Objektiv. Ein SLO legt das angestrebte Qualitätsniveau eines Services oder einer Anwendung fest. SLO definiert, wie gut und zuverlässig unser Service den Kunden zur Verfügung gestellt werden soll. z.B. könnte ein SLO vorgeben, dass eine Internetseite innerhalb von 2 Sekunden vollständig geladen sein muss.

SLI steht für Service-Level-Indikator. Ein SLI repräsentiert den tatsächlichen Zustand der in den SLOs definierten Ziele. Im Grunde genommen sind SLIs die Messinstrumente, die uns zeigen, wie gut unser Service funktioniert und ob wir die in den SLOs festgelegten Ziele erreichen. Zurück zum oberen Beispiel: SLI gibt an, wie schnell unsere Internetseite tatsächlich geladen wird – ob es nun 2 Sekunden, 5 Sekunden oder vielleicht 1,5 Sekunden sind.

SLA steht für Service-Level-Agreement (Dienstleistungsvereinbarung) und sicherlich ist die bekannteste Abkürzung aus allen drei. Ein SLA legt fest, welche Maßnahmen ergriffen werden, wenn die in den SLIs gemessenen Werte schlechter sind als die in den SLOs festgelegten Schwellenwerte. Aus juristischer Sicht handelt es sich um einen Vertrag zwischen dem Anbieter eines Services und dem Nutzer dieses Services. In diesem Vertrag wird genau festgelegt, was man von einem Service erwarten kann und welche Konsequenzen es hat, wenn diese Erwartungen nicht erfüllt werden.

Tanzu SLO SLI SLA

 

Ein Blick auf „vSphere with Tanzu“

Bevor wir auf die einzelnen Punkte eingehen, müssen wir die wichtigste Eigenschaft von Tanzu erläutern. vSphere with Tanzu ist eine integrierte Funktion von vSphere, die direkt nach der Installation von vSphere in vollem Umfang vorhanden ist und nur aktiviert werden muss, wenn einige wenige Voraussetzungen erfüllt sind.

Aus dieser Perspektive ist es für mich (da ich kein SRE-Ingenieur bin) ziemlich schwierig, alle Abhängigkeiten von vSphere with Tanzu zu berücksichtigen und entsprechend zu gewichten. Die SLOs, SLIs und SLAs für vSphere beeinflussen erheblich die SLOs, SLIs und SLAs für vSphere with Tanzu.

Bitte beachten Sie auch, dass das Thema „Tanzu Kubernetes Cluster“ (TKSs) nur minimal behandelt wird, obwohl die „vSphere with Tanzu“ – Komponente genau dafür dient, die TKCs bereitzustellen und den Kubernetes Workload zu bedienen.

 

SLO für vSphere with Tanzu

Wenn ich vSphere with Tanzu nutzen würde, wären für mich als Kunde folgende Aspekte wichtig:

  1. die "Supervisor Cluster" sind immer verfügbar.
  2. ich kann jederzeit „vSphere Namespaces“ sowie „Tanzu Kubernetes Cluster“ in der gewünschten Größe anlegen.
  3. es stehen stets ausreichend Hardware-Ressourcen zur Verfügung, um bei Bedarf die VM-Klassen ändern zu können.
  4. es sollte eine ausreichende Skalierbarkeit gewährleistet sein, z.B. bei zunehmender Arbeitslast
  5. es sollte nie zu Engpässen bei der Anforderung von Netzwerkadressen kommen.
  6. die Storage-Kapazitäten müssen immer verfügbar sein.
  7. die gewünschten Identity Provider müssen stets verfügbar sein.
  8. usw. …

Mit „dauerhaft“ und „immer“ meine ich eine 24/7-Verfügbarkeit. Die oben genannte Liste könnte erheblich erweitert werden. Ich habe bewusst wichtige Punkte wie:

 ausgelassen.

 

SLI für vSphere with Tanzu

So könnten die SLIs aussehen, wenn man die obere sieben Punkte als Grundlage nimmt. Bitte vergessen Sie nicht, dass es sich in diesem Fall nur um ein Beispiel handelt und die spezifischen Anforderungen des Kunden sowie die technischen Gegebenheiten zu berücksichtigen sind.

 Nr.   Service Level Indicator  Beschreibung
1  Verfügbarkeit von Supervisor Cluster  Misst den Prozentsatz der Zeit, in der die „Supervisor Cluster“ verfügbar sind.
2  Fähigkeit, vSphere Namespaces und Tanzu Kubernetes Cluster anzulegen  Misst die Zeit oder den Prozentsatz der Anfragen, die erfolgreich bearbeitet wurden, um „vSphere Namespaces“ und „Tanzu Kubernetes Cluster“ anzulegen.
3  Verfügbarkeit von Hardware-Ressourcen  Misst den Prozentsatz der Zeit, in dem ausreichend Hardware-Ressourcen verfügbar sind, um VM-Klassen ändern zu können.
4  Skalierbarkeit  Misst, wie gut das System bei zunehmender Arbeitslast skaliert, z.B. durch Messung der Zeit zur Bereitstellung zusätzlicher Ressourcen oder der Fähigkeit, zusätzliche Workloads ohne Leistungsverlust zu verarbeiten.
5  Verfügbarkeit von Netzwerkadressen  Misst den Prozentsatz der Zeit, in dem Netzwerkadressen verfügbar sind und Engpässe vermieden werden können.
6  Verfügbarkeit von Storage-Kapazitäten  Misst den Prozentsatz der Zeit, in dem ausreichend Speicherkapazität verfügbar ist.
7  Verfügbarkeit von Identity Providern  Misst den Prozentsatz der Zeit, in dem die gewünschten Identity Provider verfügbar sind.

 

SLOs/SLIs

Die SLOs/SLIs sind in der Regel detaillierte interne technische Messungen, die vom Dienstleister verwendet werden, um die eigene Servicequalität zu überwachen und zu steuern. Ob es hilfreich wäre, dem Kunden auch Einblick in die SLOs und SLIs zu geben, hängt wahrscheinlich von der individuellen Situation ab. Möglicherweise kann eine solche Transparenz zu mehr Vertrauen in die Fähigkeiten des Dienstleisters führen.

Ich gehe davon aus, dass zu diesem Punkt sehr unterrichtlichen Sichtweisen gibt. Nochmals zu Erinnerung: auch wenn ich die SLOs/SLIs nebeneinander platzierte, sind sie nicht dasselbe. SLIs sind die Metriken, die verwendet werden, um die Leistung und Verfügbarkeit eines Services zu messen. Die SLOs sind die Ziele, die auf der Grundlage dieser Metriken festgelegt werden. Die intern verwendete SLIs sind nicht unbedingt für den Kunden sichtbar oder relevant.

 

SLA für vSphere with Tanzu

Endlich sind wir zum Kernpunkt dieser Ausführungen gekommen. Wie oben bereits erklärt, wird das Service Level Agreement direkt mit dem Kunden vereinbart und beschreibt das erwartete Leistungsniveau des Services.

Wenn wir uns an einem der führenden Anbieter im Bereich Cloud (wie AWS) orientieren, könnte die SLA ziemlich kurz und oberflächlich ausfallen:

 Monatlicher Verfügbarkeitsprozentsatz  Prozentsatz der Servicegutschrift 
 Weniger als 99,95 %, aber größer oder gleich 99,0 %   10 %
 Weniger als 99,0 %, aber größer oder gleich 95,0 %  25 %
 Weniger als 95,0 %  100%

Quelle: SLA für Amazon Elastic Container Service für Kubernetes 

99,95%

Wie man sieht, versprechen selbst die Marktführer nicht die oftmals angestrebten fünf Neunen (99,999 %) (5 min), sondern setzen auf realistische 99,95 % (4 Stunden) Verfügbarkeit. Die Verfügbarkeitsprozentsätze sind unten in der Tabelle aufgelistet.

Wie bereits oben erwähnt, stellt vSphere with Tanzu keine eigenständige Komponente dar, sondern ist eine integrierte Funktion von vSphere. Daher haben die SLAs von vSphere einen erheblichen Einfluss auf die SLAs für vSphere with Tanzu.

Folgende Punkte müssen bei der Berechnung von SLAs für "vSphere with Tanzu" berücksichtigt werden:

Weiterhin müssen alle oben ausgeführten Faktoren (und auch die, die nicht auf der Liste stehen) beaufsichtigt werden, um eine SLA für "vSphere with Tanzu" zu berechnen. Sie müssen auch klar definieren, welche Leistungskennzahlen einbezogen werden und wie diese gemessen und berechnet werden. All diese Informationen werden benötigt, um die Gesamtverfügbarkeitsmetrik (Total Availability Metric) zu berechnen.

Gesamtverfügbarkeitsmetrik

Die Gesamtverfügbarkeit wird durch das Multiplizieren der Verfügbarkeiten der einzelnen Komponenten berechnet, wenn alle Komponenten für den Betrieb des Services notwendig sind.

Gesamtverfügbarkeit = Service A * Service B * Service C * Service D * Service E

Nehmen wir mal drei ersten Komponenten aus unseren Liste: vSphere, NSX-T, vSAN und LDAP. Jede dieser Komponenten hat selbstverständlich ihre eigene Verfügbarkeits-SLA. So kann die Berechnung aussehen:

Um die Gesamtverfügbarkeit zu berechnen, werden zuerst die Prozentsätze in Dezimalzahlen  konvertiert und anschließend miteinander multipliziert:

0,999 (vSphere) * 0,9995 (NSX-T) * 0,999 (vSAN) * 0,9995 (LDAP) = 0.9969 oder abgerundet 99,7%

In unserem stark vereinfachtem Bespiel kommen wir auf die Gesamtverfügbarkeit von 99,74%. Man geht aber davon aus, dass alle Komponenten voneinander unabhängig sind und der Ausfall einer Komponente nicht zum Ausfall der anderen führt. Die Realität von vSphere mit Tanzu sieht leider etwas anders aus: Wenn vSphere stirbt, stirbt Tanzu mit.

 

Fazit

Hoffentlich konnte dieser Beitrag dazu beitragen, dass die Festlegung, Berechnung und Definition von SLOs, SLIs und SLAs für jeden IT-Dienstleister von entscheidender Bedeutung sind, auch wenn diese Aufgaben nicht besonders faszinierend erscheinen.

Die Betrachtung von vSphere with Tanzu - Beispielen verdeutlicht, wie komplex die Tanzu-bezogene Berechnung sein kann,  insbesondere in Bezug auf die Abhängigkeiten zwischen verschiedenen Komponenten.

 

 

Beispiel SLI für Tanzu Kubernetes Cluster

   Metriken   Beschreibung 
 1   Verfügbarkeit des Clusters  Die Zeit, in der das Cluster betriebsbereit den Nutzer zur Verfügung steht. 
 2  Cluster Performance  Es geht hier um die CPU-, RAM-Auslastung sowie Netzwerklatenz.
 3  Cluster Deployment Zeit  Die Zeit, in der das Cluster (TKC) erstellt wird.
 4  Clusterkapazität  Wie viel von den zugewiesenen Ressourcen (CPU, Speicher, Netzwerk) wird zu einem bestimmten Zeitpunkt genutzt werden kann?
 5  Verfügbarkeit von Pods  Die Zeit, in der die Pods auf dem Cluster up & running.
 6  Erfolgsrate von Deployments   Wie oft werden Deployments erfolgreich abgeschlossen (im Vergleich zu Fehlern).
 7  Reaktionszeit auf Anfragen  Die Zeit, die benötigt wird, um auf Anfragen an den Cluster zu reagieren.
 8  API-Antwortzeiten  Wie schnell reagiert die Kubernetes-API auf Anfragen.
 9  Fehlerquote  Die Anzahl der Fehler, die innerhalb eines bestimmten Zeitraums auftreten.
 10   Recovery Time Objective  Beschreibt die Zeit, die benötigt wird, um das System nach einem Ausfall wiederherzustellen.
 11  Recovery Point Objective  Beschreibt die Menge an Daten, die bei einem Ausfall verloren gehen könnten.
 12  Update-Frequenz und -Erfolgsrate   Wie oft werden Updates durchgeführt und wie viele davon erfolgreich sind.
 13  Skalierungszeit  Die Zeit, die benötigt wird, um zusätzliche Ressourcen hinzuzufügen oder zu entfernen.
 14  Pod-Startzeit  Wie lange dauert es vom Start eines Pods bis zu seinen Ready-Zustand.
 15  Pod-Fehlerrate  Wie oft ist der Start von Pods fehlerhaft.
 16  Netzwerkleistung  Wie schnell können Daten innerhalb des Clusters, zwischen den Clustern und nach außen übertragen werden?
 17  Storage-Zuverlässigkeit  Die Verfügbarkeit von Storage lässt sich messen. 
 18  Netzwerkverfügbarkeit  Es geht um Verfügbarkeit der  internen Netzwerke und die Verbindungen zu externen Netzen. 
 19  Netzwerkleistung  Es geht hier um die Netzwerk-Performance.
 20  Backups und Restores - Erfolgsrate   Es geht hier um die Erfolgsquote bei der Sicherung und Wiederherstellung.
 21  Zuverlässigkeit der Cluster-Infrastruktur-Komponenten  Hier geht es um den Komponenten wie z.B. etcd, Kube-Scheduler oder Kube-Controller-Manager
 22  Cluster Add-Ons  Hier geht es um den Zustand der externen Komponenten, z.B. Ingress-Controller, Service Meshes

 23

 Sicherheit  Wie oft kommt es zu den Sicherheitsvorfällen und wie schnell dauert die Behebung?
 
Wenn Sie das Monitoring-System für Ihren Kubernetes-Cluster konfigurieren, sollten die zu überwachenden Metriken mit den definierten SLIs übereinstimmen.

 

Verfügbarkeit in %

 Verfügbarkeitsprozentsatz   Jährliche Ausfallzeit (365 Tage)   Wöchentliche Ausfallzeit 
 99% (zwei Neunen)  3 Tage 15 Stunden  1 Stunde 40 Minuten
 99,9% (drei Neunen)  8 Stunden 46 Minuten  10 Minuten
 99,95 %   4 Stunden 23 Minuten  5 Minuten
 99,99% (vier Neunen)  52 Minuten 36 Sekunden  1 Minute
 99,999% (fünf Neunen)  5 Minuten 15 Sekunden  6 Sekunden