Notfallwiederherstellungsszenarien

Dieser Abschnitt enthält Beispiele für den Ausfall einer einzelnen Availability Zone oder AWS Region und behandelt Optionen für Disaster Recovery (DR). In den Beispielen wird von einem Recovery Point Objective (RPO) von 15 Minuten und einem Recovery Time Objective (RTO) von 4 Stunden ausgegangen.

Ausfall der Availability Zone

Sie können eine der folgenden Optionen verwenden, um die Wiederherstellung nach einem Ausfall einer einzelnen Availability Zone innerhalb der angegebenen Parameter (RPO von 15 Minuten, RTO von 4 Stunden) durchzuführen.

• Stellen Sie die Anwendungswiederherstellung mithilfe des neuesten Amazon Elastic Compute Cloud (Amazon EC2) Image-Backups bereit und stellen Sie über eine Always-On-Verfügbarkeitsgruppenbereitstellung oder Protokollversand eine Verbindung zur vorhandenen Warm-Standby-Datenbank-Instance her.

  • Eine SQL Server Always-On-Verfügbarkeitsgruppe für DR mit zwei oder mehr Knoten ermöglicht ein automatisches Failover auf den sekundären Knoten im Modus synchrones Commit oder asynchrones Commit, sodass die Datenbank sofort verfügbar ist. Bei einem HA-Setup sind beide Knoten für Lesevorgänge verfügbar. Diese Option erfüllt sowohl die RTO- als auch die RPO-Anforderungen problemlos. In der SQL Server Standard Edition ist die Verwendung von Basisverfügbarkeitsgruppen ebenfalls eine Option, die jedoch auf zwei Knoten beschränkt ist, da eine Verfügbarkeitsgruppe nur eine Datenbank enthalten kann. Sie können jedoch mehrere Verfügbarkeitsgruppen innerhalb einer Region oder regionsübergreifend einrichten. Dieses Setup bietet Kosteneinsparungen, da keine zusätzlichen Kosten für den sekundären Knoten anfallen, der für Lesevorgänge nicht zugänglich ist. SQL Server Enterprise Edition bietet volle Funktionalität und Failover für alle Datenbanken innerhalb einer einzigen Verfügbarkeitsgruppe. Beispiele für diese Option finden Sie in den folgenden Architekturdiagrammen:

    • HA/DR-Architektur mit zwei Knoten und Always-On-Verfügbarkeitsgruppencluster (Einzelregion, Multi-AZ)

    • HA/DR-Architektur mit drei Knoten (eine Region, Multi-AZ)

    • HA/DR-Architektur mit vier Knoten und Always-On-Cluster für verteilte Verfügbarkeitsgruppen (mehrere Regionen, Multi-AZ)

    • HA/DR-Architektur mit drei Knoten und einer einzigen Verfügbarkeitsgruppe (mehrere Regionen)

  • Der Versand von SQL Server-Protokollen als DR-Lösung erfordert einen manuellen Failover auf einen Standby-Server und hängt von der Häufigkeit der Protokollsicherungen ab. Dies ist eine der kostengünstigsten DR-Optionen. Die SQL Server-Editionen für den primären DR-Standort und den per Protokoll versandten DR-Standort müssen nicht übereinstimmen. Diese Option erfüllt das RPO (verwendet Transaktionsprotokollsicherungen alle 5 Minuten) und RTO, erfordert jedoch Wartung durch manuelle, benutzerdefinierte Skripts. Ein Beispiel für diese Option finden Sie im folgenden Architekturdiagramm:

    • HA/DR-Architektur mit drei Knoten und Protokollversand (mehrere Regionen)

• Wenn Sie über eine Anwendung wie eine SQL Server Reporting Services (SSRS) -Anwendung verfügen, die über eine horizontal skalierte Bereitstellung verfügt, kann der Load Balancer den gesamten Datenverkehr auf den sekundären Knoten umleiten.

• Sie können Amazon EC2 Base AMIs für die Anwendung und den Datenbankserver zur Bereitstellung der Infrastruktur verwenden. Datenbanken können je nach Größe und Sicherungshäufigkeit in einer neuen Availability Zone anhand der neuesten systemeigenen Backups (vollständige Sicherung, differenzielle Sicherung oder Transaktionsprotokoll-Backups alle 5 Minuten) oder mithilfe von EBS-Snapshots wiederhergestellt werden. Diese Option erfüllt die RPO- und RTO-Anforderungen, erfordert jedoch benutzerdefiniertes Scripting. Sie müssen auch den Zeitaufwand für die Bereitstellung der Infrastruktur berücksichtigen, und die Erfüllung der RPO- und RTO-Anforderungen kann eine Herausforderung sein.

• EC2 Amazon-Images (einschließlich EBS-Volumes) für Anwendungen und den Datenbankserver können in einer neuen Availability Zone wiederhergestellt werden. RPO kann je nach aktuellem Backup eine Herausforderung sein, aber diese Option kann mit den neuesten Transaktionsprotokollen kombiniert werden, um die Anforderungen zu erfüllen. Diese Option unterstützt Windows Volume Shadow Copy Service (VSS) -Snapshots.

Fehler in der Region

Sie können eine der folgenden Optionen verwenden, um nach einem Ausfall einer einzelnen AWS Region innerhalb der angegebenen Parameter (RPO von 15 Minuten, RTO von 4 Stunden) eine Wiederherstellung durchzuführen.

• Sie können Amazon Machine Images (AMIs) als EC2 Amazon-Basis für die Anwendung und den Datenbankserver verwenden, um die Infrastruktur bereitzustellen. Datenbanken können in einer neuen Region je nach Größe und Sicherungshäufigkeit anhand der neuesten systemeigenen Backups (vollständige Sicherung, differenzielle Sicherung oder Transaktionsprotokoll-Backups alle 5 Minuten) wiederhergestellt werden. Diese Option erfüllt die RPO- und RTO-Anforderungen, erfordert jedoch benutzerdefiniertes Scripting.

  • Der Versand von SQL Server-Protokollen als DR-Lösung erfordert einen manuellen Failover auf einen Standby-Server und hängt von der Häufigkeit der Protokollsicherungen ab. Dies ist eine der kostengünstigsten DR-Optionen. Die SQL Server-Editionen für den primären DR-Standort und den per Protokoll versandten DR-Standort müssen nicht übereinstimmen. Diese Option erfüllt RPO (indem Transaktionsprotokollsicherungen alle 5 Minuten verwendet werden) und RTO, erfordert jedoch Wartung durch manuelle, benutzerdefinierte Skripts. Große Datenbanken erfordern lange Wiederherstellungszeiten.

• Sie können ein EC2 Amazon-AMI sowohl für die Anwendung als auch für den Datenbankserver verwenden und es auf einem Ziel in einer neuen Region wiederherstellen. RPO hängt von der Größe und Häufigkeit der Backups ab.

  • Die neuesten Anwendungsabbilder können mithilfe eines AMI wiederhergestellt werden. Sie können aktuelle systemeigene Differential- oder Transaktionsprotokollsicherungen alle 5 Minuten verwenden, um die Datenbank auf den neuesten Stand zu bringen, sodass sie dem RPO entspricht.

  • RTO hängt von der Größe und der Dauer der Übertragung und Wiederherstellung der Snapshots in die neue Region ab, sofern die Quelle nicht bereits mit dem Ziel synchronisiert ist.

• Die Lösung mit der geringsten Ausfallzeit besteht darin, das Anwendungs-Backup-Image wiederherzustellen und einen warmen Standby-SQL Server-Knoten in einer Remote-Region einzurichten, indem eine Verfügbarkeitsgruppe mit zwei Knoten, drei Knoten oder vier Knoten verwendet wird (einfach, klassisch oder verteilt) und nach einem Failover eine Verbindung zum Standby-Datenbankserver hergestellt wird. Das Replikat im synchronen Commit-Modus erfüllt die RPO-Anforderungen, wohingegen das Replikat im asynchronen Commit-Modus je nach Transaktionsvolumen verzögert werden kann. Sie können eine Konfiguration mit verteilten Verfügbarkeitsgruppen verwenden, um bei Bedarf Datenbankknoten in einer neuen Region zu skalieren. Diese Konfiguration reduziert auch die Komplexität, da sie zwei unabhängige Verfügbarkeitsgruppen anstelle einer einzigen Verfügbarkeitsgruppe verwendet, die entweder im synchronen oder asynchronen Commit-Modus über mehrere Regionen verteilt ist, und sowohl RTO- als auch RPO-Anforderungen problemlos erfüllt. Alternativ ist auch die Verwendung von SQL Server-Basisverfügbarkeitsgruppen in der Standard Edition eine Option. Es gibt jedoch Einschränkungen, da es nur bis zu zwei Knoten unterstützt und nur eine Datenbank in einer einzelnen Verfügbarkeitsgruppe enthalten sein kann, obwohl mehrere Verfügbarkeitsgruppen unterstützt werden. Sie können die SQL Server Standard Edition innerhalb einer Region oder regionsübergreifend einrichten. Diese Edition bietet Kosteneinsparungen, da sie keine Gebühren für den sekundären Knoten erhebt, auf den für Lesevorgänge nicht zugegriffen werden kann. Die SQL Server Enterprise Edition bietet den vollen Funktionsumfang und unterstützt das Failover aller Datenbanken als Failover für eine einzige Verfügbarkeitsgruppe.

Häufige Anwendungsfälle

Zur Größenbestimmung können 80% der auf Amazon ausgeführten SQL Server-Anwendungen, EC2 die eine normale OLTP-Arbeitslast (Online Transaction Processing) haben, je nachdem, wie wichtig sie sind, in eine von drei Kategorien eingeteilt werden:

• SQL Server HA/DR mit SQL Server-Backups, wobei zwei Replikate mit synchronem Commit und ein Replikat im asynchronen Commit-Modus verwendet werden

• AWS Backup HA/DR mit SQL Server-Backups unter Verwendung eines Amazon EC2 AMI sowohl für die Anwendung als auch für die Datenbank und Amazon EBS-Speicher

• AWS Backup HA/DR mit SQL Server-Backups unter Verwendung eines EC2 Amazon-Basis-AMI für den Datenbankserver, eines EC2 Amazon-Images für die Anwendung und Amazon EBS-Snapshots

Die folgende Tabelle enthält Einzelheiten zu den einzelnen Kategorien.

	SQL Server HA/ DR mit SQL Server-Backups	AWS Backup HA/DR mit EBS-Speicher AMIs und SQL Server-Backups	AWS Backup HA/DR mit EBS-Snapshots AMIs und SQL Server-Backups
Wiederherstellungsprozess im Katastrophenfall	Stellen Sie das EC2 Amazon-Basis-AMI für die Anwendung wieder her von AWS Backup Führen Sie einen Failover zur Standby-Instance in der Region (bei einem Ausfall der Availability Zone) oder zur regionsübergreifenden Instance (bei einem Ausfall der Region) durch Erfüllt die RPO- und RTO-Anforderungen	Stellen Sie EC2 Amazon-Images aus Backups sowohl für die Anwendung als auch für die Datenbank wieder her Bietet sowohl regionalen als auch regionsübergreifenden Support Wenden Sie die neuesten differenziellen und Transaktionsprotokollsicherungen von SQL Server (alle 15 Minuten) an, um die RPO- und RTO-Anforderungen für die Datenbank zu erfüllen	EC2 Amazon-Image aus dem Backup für die Anwendung wiederherstellen Stellen Sie das EC2 Amazon-Basis-AMI für den Datenbankserver wieder her EBS-Snapshots wiederherstellen (falls vorhanden) Der Cluster muss neu erstellt werden Bietet sowohl regionsinterne als auch regionsübergreifende Unterstützung Wenden Sie die neuesten Differential- und Transaktionsprotokollsicherungen auf die Datenbank an, um die RPO-Anforderungen zu erfüllen. RTO ist jedoch möglicherweise nicht erfüllt
Primäre Ressourcen	Drei Lizenzen für die SQL Server Enterprise Edition (die Lizenz für passive HA- und DR-Knoten ist kostenlos, wenn Sie über eine bestehende Software Assurance-Lizenzvereinbarung mit Microsoft verfügen; siehe Ankündigung) EC2 Amazon-Backup-Speicherplatz auf Amazon Simple Storage Service (Amazon S3) Regionsübergreifender Datentransfer	Eine SQL Server-Lizenz (jede Edition). EC2 Amazon-Backup-Speicherplatz auf Amazon S3 SQL Server-Backups (Differential- und Protokolldateien) auf Amazon S3 Regionsübergreifender Datentransfer	Eine SQL Server-Lizenz (jede Edition). EC2 Amazon-Backup-Speicherplatz auf Amazon S3 SQL Server-Backups (Differential- und Protokolldateien) auf Amazon S3 Regionsübergreifender Datentransfer
HA/DR	Bietet HA und DR	Bietet nur DR	Bietet nur DR
RPO	Das Failover wird von der SQL Server-Verfügbarkeitsgruppe abgewickelt (DR erfolgt manuell)	Manuell oder mit benutzerdefiniertem Skript	Manuell oder mit benutzerdefiniertem Skript
RTO	Sekunden bis Minuten	Minuten bis Stunden	Mehrere Stunden
Gefahr, vermisst zu werden SLAs	Niedrig	Medium	Hoch
Verwaltbarkeit	Einfach	Mittelschwer	Mittelschwer
Skalierung	Einfach	Mittelschwer	Mittelschwer
Dateigrößenbeschränkungen für Uploads auf Amazon S3 oder regionsübergreifende Übertragung	N/A — Wird im synchronen Commit-Modus oder im asynchronen Commit-Modus zu einem Warm-Standby verarbeitet	Ja	Ja
Datenverlust	Fast Null (hängt von der Arbeitslast und der bereitgestellten Infrastruktur ab)	Hängt von der Häufigkeit der EC2 Amazon-Backup-Images und SQL-Server-Backups ab	Hängt von der Häufigkeit von EC2 Amazon-Backup-Images oder EBS-Snapshots und SQL Server-Backups ab
Kosten	Mittelschwer	Niedrig — mittel	Niedrig — mittel