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
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
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.
quelle
Antworten:
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:
Die Wahrscheinlichkeit, dass einer von ihnen ausfällt, ist die Summe ihrer Wahrscheinlichkeit:
Wenn zwei Ereignisse unabhängig voneinander sind, lautet die resultierende Formel zur Berücksichtigung der Wahrscheinlichkeit, dass beide Ereignisse ausfallen, wie folgt:
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):
Die Wahrscheinlichkeit, in Ordnung zu sein, ist also
1 - 0.0816 = 0.9184in Prozent:91,84%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%und0,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-WahrscheinlichkeitP(G) = 0,99900025gekoppeltWie 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:
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 ).
quelle
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:
So
Es parallel Berechnung ist ein wenig komplizierter , als wir brauchen zu überlegen , was der Prozentsatz un Verfügbarkeit sein wird:
Die Berechnung erfolgt wie folgt:
Multiplizieren Sie die un Verfügbarkeit der zusammen zwei Regionen.
Wandeln Sie das wieder in Verfügbarkeit um
Multiplizieren Sie die Verfügbarkeit von Traffic Manager mit der Verfügbarkeit der beiden Regionen.
Das Ergebnis ist die Verfügbarkeit des gesamten Systems.
Ich habe Excel verwendet, um die Berechnungen durchzuführen. Hier sind die Werte:
... und die Formeln ...
quelle