Wie berechnen Sie das zusammengesetzte Service Level Agreement (SLA) für Cloud-Services?


27

Cloud - Services gehostet von Amazon Web Services , Azure , Google und die meisten anderen veröffentlichen die S ervice L evel A greement oder SLA, für die einzelnen Dienstleistungen , die sie bieten. Architekten, Plattformingenieure und Entwickler sind dann dafür verantwortlich, diese zusammenzustellen, um eine Architektur zu erstellen, die das Hosting für eine Anwendung bereitstellt.

Für sich genommen bieten diese Dienste in der Regel eine Verfügbarkeit im Bereich von drei bis vier Neun:

  • Azure Traffic Manager: 99,99% oder vier Neunen.
  • SQL Azure: 99,99% oder vier Neunen.
  • Azure App-Dienst: 99,95% oder "Drei Neun Fünf".

Wenn sie jedoch in Architekturen kombiniert werden, besteht die Möglichkeit, dass eine Komponente ausfällt, was zu einer Gesamtverfügbarkeit führt, die nicht den Komponentendiensten entspricht.

Verfügbarkeit der seriellen Verbindung

Serienmäßige Verfügbarkeit

In diesem Beispiel gibt es drei mögliche Fehlermodi:

  • SQL Azure ist inaktiv
  • App Service ist nicht verfügbar
  • Beide sind unten

Daher muss die Gesamtverfügbarkeit dieses "Systems" unter 99,95% liegen. Mein Grund zu der Annahme ist, dass die SLA für beide Dienste:

Der Service ist 23 Stunden von 24 verfügbar

Dann:

  • Der App-Service kann zwischen 01:00 und 02:00 Uhr ausfallen
  • Die Datenbank aus zwischen 0500 und 0600

Beide Komponenten befinden sich innerhalb ihrer SLA, aber das Gesamtsystem war für 2 von 24 Stunden nicht verfügbar.

Serielle und parallele Verfügbarkeit

Serielle und parallele Verfügbarkeit

In dieser Architektur gibt es jedoch hauptsächlich eine große Anzahl von Fehlermodi:

  • SQL Server in RegionA ist inaktiv
  • SQL Server in RegionB ist inaktiv
  • App Service in RegionA ist nicht verfügbar
  • App Service in RegionB ist nicht verfügbar
  • Der Traffic Manager ist ausgefallen
  • Kombinationen von oben

Da der Traffic Manager ein Leistungsschalter ist, kann er einen Ausfall in beiden Regionen erkennen und den Verkehr in die Arbeitsregion leiten. Es gibt jedoch immer noch einen einzelnen Ausfallpunkt in Form des Traffic Managers, sodass die Gesamtverfügbarkeit des "Systems" nicht gewährleistet ist höher als 99,99% sein.

Wie kann die Gesamtverfügbarkeit der beiden oben genannten Systeme für das Unternehmen berechnet und dokumentiert werden, was möglicherweise eine Neugestaltung erfordert, wenn das Unternehmen ein höheres Servicelevel wünscht, als die Architektur bereitstellen kann?

Wenn Sie die Diagramme mit Anmerkungen versehen möchten, habe ich sie in Lucid Chart erstellt und einen Mehrzweck-Link erstellt. Beachten Sie, dass jeder diese bearbeiten kann, sodass Sie möglicherweise eine Kopie der zu kommentierenden Seiten erstellen möchten.


Niedrigster SLA von SPOF, vorausgesetzt, Ihre App kann die Sitzungsunterbrechung bewältigen?
Tensibai

1
@Tensibai - Ich glaube nicht, dass dies möglich ist. Wenn die SLA für beide Dienste nach meinem ersten Beispiel 23 von 24 Stunden verfügbar wäre, könnte der App-Service zwischen 01:00 und 02:00 Uhr und die Datenbank zwischen 01:00 und 02:00 Uhr verfügbar sein 0500 und 0600, beide Komponenten liegen innerhalb ihrer SLA, aber das Gesamtsystem war für 2 von 24 Stunden nicht verfügbar. Sinnvoll?
Richard Slater

Ja, macht Sinn, aber in diesem Fall sollte das Ergebnis das Produkt von allem sein, nicht wahr?
Tensibai

Ich meine, App 99,95 x Sql 99,95 sollte die Gesamtverfügbarkeit der Gruppe sein
Tensibai

Denken Sie auch daran, dass Sie ein System erstellen können, das zuverlässiger als seine Komponenten ist, und zwar durch Wiederholungsversuche, Failover oder Degradation anstelle eines vollständigen Ausfalls.
Xiong Chiamiov

Antworten:


19

Ich würde das als ein mathematisches Problem betrachten, bei dem die SLA die Wahrscheinlichkeit ist, dass alles in Ordnung ist.

In diesem Fall können wir uns auf Wahrscheinlichkeitsregeln verlassen , um eine Gesamtsumme zu erhalten.

Für Ihren ersten Fall ist die Wahrscheinlichkeit, dass App Service (A) und SQL Service (B) gleichzeitig nicht verfügbar sind, das Produkt ihrer Wahrscheinlichkeit:

P(A)*P(B) = 0.0005 * 0.0005 = 0,00000025

Die Wahrscheinlichkeit, dass einer von ihnen ausfällt, ist die Summe ihrer Wahrscheinlichkeit:

P(A)+P(B) = 0.001

Wenn zwei Ereignisse unabhängig voneinander sind, lautet die resultierende Formel zur Berücksichtigung der Wahrscheinlichkeit, dass beide Ereignisse ausfallen, wie folgt:

P(A,B) = P(A) + P(B) - P(A)*P(B) = 0.001 - 0,00000025 = 0,00099975

Die Gesamt-SLA wäre also 1 - 0,00099975 = 0,99900025in Prozent99.900025 %

Eine Vereinfachung ist das Produkt aus der ersten Wahrscheinlichkeit: 0.9995 * 0.9995 = 0,99900025.

Angewendet auf Ihre 1h / 24h-Störung (4.166.666% eines Tages) ergibt dies (Dezimalstellen werden abgekürzt):

0.0416 + 0.0416 - (0.0416 * 0.0416) = 0,081597222

Die Wahrscheinlichkeit, in Ordnung zu sein, ist also 1 - 0.0816 = 0.9184in Prozent:91,84%

24 * 0.0816 = 1.95 h

Dies ist weniger als der schlimmste Fall von 2 Stunden, da möglicherweise beide gleichzeitig außer Betrieb sind.

Wenn Sie dies bedenken, werden Sie möglicherweise feststellen, dass die Verfügbarkeit für jeden von oben ist 95,84%und 0,958333333 * 0,958333333 = 0,918402778welcher von uns stammt.91.84%

In Ihrem zweiten Fall werden wir von unserer zusammengesetzten Wahrscheinlichkeit für jede Region profitieren (Entschuldigung, ich habe die Änderung für SQL abgelehnt, um sie vernünftig zu halten), vorausgesetzt, es gibt keine unabhängige Wahrscheinlichkeit für die Region selbst und jede Region ist isoliert und als solche Bei einem DB-Fehler wird nur die Region heruntergefahren.

Wir haben den Verkehrsmanager mit OK-Wahrscheinlichkeit P(T) = 0.9999und jede App + DB mit einer OK-Wahrscheinlichkeit P(G) = 0,99900025gekoppelt

Wie viel Region spielen wir eine Rolle, da wir das Produkt der Ausfallwahrscheinlichkeit anwenden müssen, um die Wahrscheinlichkeit zu erhalten, dass beide Regionen gleichzeitig ausfallen:
0,00099975 * 0,00099975 = 0,0000009995000625Dies bedeutet eine Gesamtverfügbarkeit von mindestens einer Region von99,049375 %

Jetzt haben wir die Gesamtverfügbarkeit der Regionen, das Produkt mit dem Verkehrsmanager gibt uns die Gesamtverfügbarkeit des Systems:

0.9999 * 0,9999990004999375 = 0,99989900059988750625

Die Gesamtverfügbarkeit beträgt 99.989900 %

Eine weitere Quelle zur Erklärung finden Sie in den Azure-Dokumenten (Link mit freundlicher Genehmigung von Raj Rao ).


Die Gesamtverfügbarkeit scheint sehr niedrig zu sein. Durch Hinzufügen einer zusätzlichen Region und eines Verkehrsmanagers ist die SLA um eine Größenordnung niedriger als bei einer einzelnen Region. Ich versuche herauszufinden, wie ich das früher für Netzwerke gemacht habe.
Richard Slater

Puh! Ich war mir sicher, dass ich verrückt werde.
Richard Slater

@
Richard

2
@BruceBecker wahrscheinlich ja, anscheinend hat das IEEE Forschungen zu diesem Thema veröffentlicht. Ich vermute jedoch, dass es angesichts des Zwecks der Berechnung dieser Zahlen mehr darum geht, konkrete "Beweise" dafür zu haben, dass Sie Hochverfügbarkeitsfähigkeiten benötigen oder nicht einem System hinzugefügt - dh wir verwenden diese Zahlen, um Kosten-Nutzen-Entscheidungen auf der Grundlage der Risikobereitschaft eines Unternehmens zu treffen. Die Erstellung eines Bayes'schen Modells ist möglicherweise nicht die beste Verwendung unserer Zeit.
Richard Slater

1
@BruceBecker Ja, ein Teil des Problems ist gebunden (dasselbe Rechenzentrum fällt aus und beide Dienste befinden sich darin, was niedrig sein muss). Im Übrigen können wir davon ausgehen, dass die App-Dienste und SQL-Dienste auf verschiedenen Systemen ausgeführt werden und dies unwahrscheinlich ist scheitern zur gleichen Zeit aus dem gleichen Grund . Ein tieferer Einblick in die Mathematik erfordert eine genaue Dokumentation der Azure-Architektur und kann daher nur von einer Person von Microsoft beantwortet werden.
Tensibai

18

Nachdem ich Tensibais ausgezeichnete Antwort gelesen hatte , wurde mir klar, dass ich diese für Netzwerkanalysezwecke berechnen konnte. Ich habe meine Ausgabe der High Availability Network Fundamentals von Chris Oggerino ausgegraben und hatte ein Händchen dafür, nicht ganz die ersten Principals.

Wenn ich mein Serienbeispiel direkt aus Tensibais Antwort nehme, multipliziere ich einfach die Wahrscheinlichkeit, dass jede Komponente von der anderen verfügbar ist:

Serienmäßige Verfügbarkeit

So

99,95% * 99,95% = 99,9%

Es parallel Berechnung ist ein wenig komplizierter , als wir brauchen zu überlegen , was der Prozentsatz un Verfügbarkeit sein wird:

Serielle und parallele Verfügbarkeit

Die Berechnung erfolgt wie folgt:

  1. Multiplizieren Sie die un Verfügbarkeit der zusammen zwei Regionen.

    0,1% * 0,1% = 0,0001%

  2. Wandeln Sie das wieder in Verfügbarkeit um

    100% - 0,0001% = 99,9999%

  3. Multiplizieren Sie die Verfügbarkeit von Traffic Manager mit der Verfügbarkeit der beiden Regionen.

    99,99% * 99,9999% = 99,9899%

  4. Das Ergebnis ist die Verfügbarkeit des gesamten Systems.

    99,9899% liegt nahe bei 99,99%

Ich habe Excel verwendet, um die Berechnungen durchzuführen. Hier sind die Werte:

Excel-Werte

... und die Formeln ...

Excel-Formeln


1
Das war's auf eine einfachere Weise als meine (ich hatte das Bedürfnis, die Mathematik dahinter zu demonstrieren :))
Tensibai

Einverstanden, Ihre Antwort ist wirklich gut für die Mathematik.
Richard Slater

SQL Azure ist 99,99% nicht 99,95%
Jeffery Tang

1
@JefferyTang es war (wahrscheinlich) bei der Frage / Antwort-Schreibzeit (ich erinnere mich nicht genau) und der tatsächliche Wert ändert nichts an der Methodik, um die Antwort auf "Wie berechnet man die zusammengesetzte SLA aus einzelnen SLA-Teilen" zu erhalten ist die eigentliche Frage.
Tensibai
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.