Durchführen der Entwurfsvorgänge für die Sicherung und Wiederherstellung
Organisationen wie Tailwind Traders benötigen für ihre unternehmenskritischen Apps ein hohes Maß an Zuverlässigkeit. Um die gewünschte Zuverlässigkeit für lokale Apps zu erzielen, werden häufig mehr Computingressourcen, z. B. Server und Speicher, erworben. Durch den Kauf weiterer Computerressourcen entsteht Redundanz in einer lokalen Infrastruktur.
Es ist auch wichtig, dass jede unternehmenskritische App und die zugehörigen Daten nach einem Ausfall wiederhergestellt werden können. Diese Wiederherstellbarkeit wird häufig durch Komponenten für die Sicherung und Wiederherstellung und entsprechende Verfahren erreicht. Für Organisationen mit in Azure gehosteten Apps oder Organisationen mit Hybrid-App-Bereitstellungen gelten andere Aspekte und Optionen.
Zuverlässige Apps sind:
Resilient gegenüber Ausfällen einzelner Komponenten
Hoch verfügbar und Möglichkeit zur Ausführung in einem fehlerfreien Zustand ohne signifikante Downtime
Um die gewünschte Resilienz und Hochverfügbarkeit zu erzielen, müssen Sie zunächst Ihre Anforderungen definieren.
Hinweis
In diesem Modul ist mit „Resilienz“ gemeint, dass das System Ausfälle – sowohl versehentlicher als auch böswilliger Art – korrekt verarbeiten und die anschließende Wiederherstellung durchführen kann.
Definieren Ihrer Anforderungen
Das Definieren Ihrer Anforderungen umfasst Folgendes:
Ermitteln Ihrer geschäftlichen Anforderungen
Aufstellen eines Resilienzplans zur Erfüllung dieser Anforderungen
Verwenden Sie die folgende Tabelle mit den zu beachtenden Aspekten hierbei als Hilfe.
| Aspekt | Beschreibung |
|---|---|
| Was sind Ihre Workloads, und worum geht es bei deren Nutzung? | Eine Workload ist eine bestimmte Funktion oder Aufgabe, die in Bezug auf die Geschäftslogik und die Datenspeicheranforderungen logisch von anderen Aufgaben getrennt ist. Für jede Workload gelten meist andere Anforderungen an die Verfügbarkeit, Skalierbarkeit, Datenkonsistenz und Notfallwiederherstellung. |
| Welche Nutzungsmuster gelten für Ihre Workloads? | Anhand von Nutzungsmustern können Ihre Anforderungen ermittelt werden. Ermitteln Sie sowohl für kritische als auch für nicht kritische Zeiten die Unterschiede in Bezug auf die Anforderungen. Planen Sie zur Sicherstellung der Uptime die regionsübergreifende Redundanz, falls eine Region ausfällt. Andererseits können Sie Ihre Anwendung in nicht kritischen Zeiten in einer einzigen Region ausführen, um die Kosten zu minimieren. |
| Welche Verfügbarkeitsmetriken werden verwendet? | Als Metriken werden normalerweise die durchschnittliche Zeit bis zur Wiederherstellung (Mean Time To Recovery, MTTR) und die durchschnittliche Zeit zwischen Fehlern (Mean Time Between Failures, MTBF) verwendet. MTBF ist die Laufzeit, die für eine Komponente realistisch zwischen Ausfällen zu erwarten ist. MTTR ist die durchschnittliche Zeit, die nach einem Fehler zur Wiederherstellung einer Komponente erforderlich ist. Ermitteln Sie anhand dieser Metriken, wo Sie für Redundanz sorgen und welche Vereinbarungen zum Servicelevel (Service-Level Agreements, SLAs) für Kunden festgelegt werden sollen. |
| Welche Wiederherstellungsmetriken werden verwendet? | Mit dem RTO-Wert (Recovery Time Objective) wird angegeben, wie lange eine Ihrer Apps nach einem Incident maximal nicht verfügbar sein darf. Der RPO-Wert (Recovery Point Objective) steht für die maximale Datenverlustdauer, die während eines Notfalls zulässig ist. Berücksichtigen Sie auch den RLO-Wert (Recovery Level Objective). Mit dieser Metrik wird die Granularität der Wiederherstellung bestimmt. Anders ausgedrückt: Hiermit wird angegeben, ob es für Sie möglich sein muss, eine Serverfarm, eine Web-App, eine Website oder nur ein bestimmtes Element wiederherzustellen. Führen Sie eine Risikobewertung durch, um diese Werte zu ermitteln. Sorgen Sie dafür, dass Sie genau über die Kosten und das Risiko für Downtime bzw. Datenverlust in Ihrer Organisation Bescheid wissen. |
| Was sind die Verfügbarkeitsziele für Workloads? | Definieren Sie Ziel-SLAs für jede Workload, um sicherzustellen, dass die App-Architektur Ihre geschäftlichen Anforderungen erfüllt. Berücksichtigen Sie dabei neben Anwendungsabhängigkeiten auch die Kosten und die Komplexität der Erfüllung von Verfügbarkeitsanforderungen. |
| Welche SLAs verwenden Sie? | In Azure beschreibt die SLA die von Microsoft zugesicherte Verfügbarkeit und Konnektivität. Wenn die Vereinbarung zum Servicelevel für einen bestimmten Dienst 99,9 Prozent beträgt, können Sie erwarten, dass der Dienst 99,9 Prozent der Zeit verfügbar ist. |
Tipp
Wenn der MTTR-Wert einer kritischen Komponente in einem Hochverfügbarkeitsszenario den RTO-Wert des Systems überschreitet, kann ein Fehler im System ggf. zu einer nicht akzeptablen Störung des Geschäftsbetriebs führen. Anders ausgedrückt: Sie können das System nicht innerhalb des definierten RTO-Zeitraums wiederherstellen.
Definieren Sie Ihre eigenen Ziel-SLAs für jede Workload Ihrer Lösung, indem Sie die obigen Fragen beantworten. Hierdurch können Sie sicherstellen, dass die Architektur Ihre geschäftlichen Anforderungen erfüllt. Wenn für eine Workload beispielsweise eine Uptime von 99,99 Prozent erforderlich ist, diese aber von einem Dienst mit einer SLA mit 99,9 Prozent abhängig ist, kann dieser Dienst im System kein Single Point of Failure sein.
Nachdem Sie Ihre Wiederherstellungsanforderungen definiert haben, können Sie eine geeignete Wiederherstellungstechnologie auswählen.