HA/DR-Optionen und Überlegungen

Obwohl die Möglichkeit, dass eine AWS Availability Zone oder Region vollständig offline geht, äußerst selten ist, empfehlen wir aus Redundanz und zur Minimierung von Datenverlusten einen mehrgleisigen Ansatz für Backup und Wiederherstellung im Notfall. Backup- und Wiederherstellungsprozesse sollten ein angemessenes Maß an Granularität beinhalten, um das Recovery Time Objective (RTO) und das Recovery Point Objective (RPO) für den Workload zu erreichen und Geschäftsprozesse zu unterstützen. Sie sind oft von der Anwendung abhängig. Unterstützt im Fall von Datenbanken AWS auch alle Microsoft-Empfehlungen für die Einrichtung und Konfiguration von SQL Server für Hochverfügbarkeit und Notfallwiederherstellung (HA/DR). Different editions of SQL Server support various HA/DR options, and you should consider special cases such as very large databases (VLDBs) on a case-by-case basis. As with any DR configuration, testing is essential to ensure that each application meets its service-level agreements (SLAs) for HA/DR. For your test/developmentUmgebung). Erwägen Sie die Verwendung der SQL Server Developer Edition, die kostenlos ist, aber mit Einschränkungen verbunden ist.

Für einen Anwendungsfall, der ein RPO von 15 Minuten und ein RTO von 4 Stunden erfordert, können Sie eine Kombination der folgenden HA/DR-Optionen in Betracht ziehen:

• Systemeigene HA/DR-Optionen für SQL Server mit Warm-Standby (Datenbankebene) — Illustrationen einiger dieser Architekturen finden Sie im Abschnitt weiter unten in diesem Handbuch. EC2 Architekturdiagramme für SQL Server auf Amazon

  • Zwei Knoten, Multi-AZ in einer einzelnen Region (synchroner Commit-Modus) oder in mehreren Regionen (asynchroner Commit-Modus, Basic Availability Group)

  • Drei Knoten (oder mehr), Multi-AZ in mehreren Regionen (Modi für synchrones Commit und asynchrones Commit)

  • Versand mit zwei Knoten, Multi-AZ und Protokollversand in mehreren Regionen (mit Protokollsicherungen alle 5 Minuten)

• Native SQL Server-Backups auf Amazon S3 (Datenbankebene, nur DR) — Vollständige Backups (einmal täglich)

  • Differenzielle Backups (alle 2—4 Stunden).

  • Backups protokollieren (alle 5—10 Minuten).

  • Backups müssen erstellt und auf Amazon Simple Storage Service (Amazon S3) kopiert werden, indem benutzerdefinierte Skripts oder eine Option wie ein File Gateway für effiziente Sicherung und Übertragung verwendet werden.

  • Wenn Sie über Hunderte von Datenbanken verfügen, können Sie weiterhin Ihre vorhandenen Backup-Tools (wie Commvault oder Litespeed) verwenden, um Backups effizient zu verwalten und sie direkt in Amazon S3 zu speichern.

  • Verwenden Sie Amazon S3 Cross-Region Replication (CRR) mit S3 Replication Time Control (RTC), um die Objektreplikation innerhalb einer SLA von 15 Minuten zu steuern und zu überwachen.

  • Zur Einhaltung gesetzlicher Vorschriften und zur Kosteneinsparung können Sie auch S3 Lifecycle Management verwenden, um ältere Backups zur Langzeitspeicherung zu verschieben und zu speichern.

  • Wenn Sie native SQL Server-Backups verwenden und diese regelmäßig nach Amazon S3 verschieben, sind Backups im Katastrophenfall in der Zielregion sofort verfügbar. Dadurch entfällt die Notwendigkeit, Backups zu übertragen oder Snapshots wiederherzustellen.

  • Wir empfehlen die Verwendung von SQL Native Backup Compression, um die Dateigrößen zu reduzieren.

• AWS Snapshots (Instanz- und Volume-Ebene, nur DR)

  • Amazon Elastic Compute Cloud (Amazon EC2) Amazon Machine Image (AMI) -Backups, um Datenbanken von Grund auf neu aufzubauen

  • Volumen-Snapshots von Amazon Elastic Block Store (Amazon EBS) zum Anhängen von EBS-Volumes an Amazon EC2

Verwaltung von HA/DR-Ressourcen in AWS Backup

AWS Backupist ein vollständig verwalteter Service, der die Möglichkeit bietet, Backup-Pläne und -Zeitpläne zu erstellen und diesen Backup-Plänen AWS Ressourcen zuzuweisen, die an der HA/DR-Konfiguration beteiligt sind, wie Amazon EBS-Volumes zum Erstellen von Snapshots und Amazon. EC2 AMIs Sie können ihn auch verwenden, um Kopien dieser EBS-Snapshots für mehrere Regionen AWS Backup zu planen. Für eine optimale Nutzung AWS Backup muss ein effizienter Tagging-Mechanismus für Ressourcen vorhanden sein. AWS Backup unterstützt auch anwendungskonsistente Backups über den Windows Volume Shadow Copy Service (VSS), den Sie für SQL Server verwenden können. Für den Schutz auf Speicherebene empfehlen wir die Verwendung von EBS-Snapshots. Die ersten EBS-Snapshots sind voll und die nachfolgenden Snapshots sind inkrementell. EBS-Snapshots bieten zwar Schutz auf Speicherebene, ersetzen jedoch nicht die auf Dateien basierenden systemeigenen SQL Server-Backups, die eine Wiederherstellung ermöglichen. point-in-time

Wird für HA/DR verwendet AWS DMS

Wenn Sie nach einer Alternative zu den SQL Server Always On-Optionen für die Replikation suchen oder wenn Sie über heterogene Quell- und Zieldatenbanken verfügen, entweder in einer Hybridkonfiguration oder in AWS, können Sie AWS Database Migration Service (AWS DMS) auf folgende Weise verwenden.

Wenn Sie SQL Server in einem selbstverwalteten Kontext (gehostet bei Amazon EC2 oder vor Ort) verwenden AWS DMS , unterstützt es die einmalige und fortlaufende Replikation in zwei Modi: mithilfe von MS-REPLICATION (zum Erfassen von Änderungen an Tabellen mit Primärschlüsseln) und MS-CDC (zum Erfassen von Änderungen an Tabellen ohne Primärschlüssel). Wenn Sie jedoch Amazon Relational Database Service (Amazon RDS) als Quelle für verwenden AWS DMS, wird nur MS-CDC unterstützt. AWS DMS bietet eine Reihe von Quell- und Zielendpunkten, unterstützt heterogene Datenbank-Engines und bietet eine detaillierte Kontrolle über den Replikationsprozess. Sie können das AWS Schema Conversion Tool (AWS SCT) auch AWS DMS für heterogene Datenbankmigrationen verwenden. AWS SCT automatisiert Änderungen auf Schemaebene und erstellt außerdem Berichte zur Vorbereitung und Planung der Migration.

Sie fügen Quell- und Zieldatenbanken als Endpunkte hinzu AWS DMS, wie in der folgenden Abbildung dargestellt. Dieser Dienst implementiert einen logischen Replikationsprozess, indem er entweder MS-REPLICATION oder MS-CDC verwendet. Wenn Sie über ein Hybrid-Setup verfügen, können Sie die Konfiguration AWS DMS für eine fortlaufende Replikation zwischen lokalen und Geräten konfigurieren. AWS Während der Umstellung kann die AWS DMS Migrationsaufgabe gestoppt werden und die Anwendung kann ohne weitere Verzögerung eine Verbindung zu der Datenbank herstellen, die bereits mit der lokalen Datenbank synchronisiert ist. Die Verwendung von AWS DMS SQL Server als Quelle hat einige Einschränkungen, die in der AWS DMS Dokumentation beschrieben werden.

Erwägen Sie in den folgenden Szenarien die Verwendung von systemeigenen HA/DR-Methoden AWS DMS anstelle von systemeigenen HA/DR-Methoden:

• Wenn Sie Lizenzkosten sparen möchten. Wenn Sie beispielsweise eine erweiterte Version wie SQL Server Enterprise Edition nur wegen ihrer Always-On-Optionen verwenden, könnten Sie AWS DMS stattdessen die Installation in Betracht ziehen, da sie eine logische Replikationsoption ohne die Kosten einer Enterprise Edition-Lizenz bereitstellen kann.

• Wenn Sie über heterogene Quellen und Ziele verfügen. Die Versionen von SQL Server auf dem Primär- und dem Notfallwiederherstellungsknoten müssen nicht übereinstimmen (innerhalb bestimmter AWS DMS Einschränkungen), was eine erhebliche Flexibilität bietet.

• Um den Mehraufwand von Windows, SQL Server-Clustering und der Einrichtung und Verwaltung verteilter Verfügbarkeitsgruppen zu vermeiden. AWS DMS bietet eine unkomplizierte Einrichtung und einfache Verwaltung von Replikationsaufgaben.

• Für geschäftliche Anwendungsfälle wie Übertragung nahezu in Echtzeit (abhängig von Replikationsinstanz, Netzwerkkonfiguration und Datenvolumen), Datenmaskierung, selektive Filterung, Schema-/Tabellenzuordnung (homogen und heterogen), Bewertungen vor der Migration und JSON-Unterstützung.

• Zum einfachen Duplizieren, Stoppen und Starten von Aufgaben nach Bedarf auf der Grundlage von Protokollsequenznummern (LSNs), Zeitstempeln und ähnlichen Optionen.

Das folgende Diagramm zeigt einen alternativen Ansatz zur Bereitstellung von Replikationsunterstützung. AWS DMS In dieser Konfiguration ist die Quelle ein SQL Server Always On-Verfügbarkeitsgruppencluster und AWS DMS verwendet die Option Change Data Capture (CDC), um Daten kontinuierlich auf ein Ziel in einer anderen AWS Region zu replizieren. Für eine optimale Leistung ist es wichtig, sicherzustellen, dass die Replikationsinstanz die richtige Größe hat und in der Quellregion verbleibt.

Die Quell- und Ziel-Engines müssen nicht übereinstimmen. Im Diagramm können die mit (1) markierten primären und sekundären Knoten ein SQL Server-Cluster in einer Single-AZ- oder Multi-AZ-Konfiguration sein. Oder die Quelle kann ein einzelner SQL Server-Knoten sein, der MS-CDC oder MS-REPLICATION unterstützt.

Bei der Ziel-DB-Instance, die im Diagramm mit (2) gekennzeichnet ist, kann es sich um eine beliebige Version von SQL Server auf Amazon RDS EC2, Amazon oder ein anderes heterogenes Ziel handeln. Sie muss nicht mit den primären und sekundären Instances übereinstimmen oder AlwaysOn-Verfügbarkeitsgruppen unterstützen. Die Quelle kann beispielsweise ein SQL Server Always On-Verfügbarkeitsgruppencluster sein, und das Ziel kann Amazon Aurora PostgreSQL-Compatible Edition sein.

AWS Application Migration Service Für DR verwenden

Wir empfehlen die Verwendung von AWS Application Migration Service für lift-and-shift Migrationen zu. AWS Der Application Migration Service repliziert Ihre Computer (einschließlich Betriebssystem, Systemstatuskonfiguration, Datenbanken, Anwendungen und Dateien) kontinuierlich in einen kostengünstigen Staging-Bereich in Ihrem AWS Zielkonto und Ihrer bevorzugten Region. Im Notfall können Sie den Application Migration Service verwenden, um Tausende Ihrer Maschinen innerhalb von Minuten automatisch in ihrem vollständig bereitgestellten Zustand zu starten.

Weitere Überlegungen

In der folgenden Liste sind die möglichen Engpässe aufgeführt, die Sie bei der Entwicklung einer HA/DR-Strategie berücksichtigen sollten.

• Bandbreite, Latenz, Netzwerkkomplexität und Konnektivität in einer Knotenkonfiguration mit mehreren Regionen.

• Größe der Amazon EBS- oder EC2 Amazon-Snapshots und die Zeit, die benötigt wird, um sie mithilfe von zu kopieren. AWS Backup

  • Amazon EBS und EC2 Amazon-Snapshots werden mithilfe von in Amazon S3 gespeichert. AWS Backup

  • Ein EBS-Snapshot wird erst in die Zielregion in Amazon S3 repliziert, wenn der aktuelle Snapshot abgeschlossen ist. Die Dauer der Replikation hängt auch von der Größe des Volumes ab.

  • Wenn der Snapshot abgeschlossen ist, kann die Dauer für das Kopieren von Snapshots für 99,99% der Objekte nur 15 Minuten betragen. Für bestimmte Anwendungsfälle und kritische große Volumen sind jedoch gründliche Tests erforderlich.

• Zeit, die für die Wiederherstellung von EBS-Volumes in der Ziel-Availability Zone und -Region erforderlich ist.

• Zeit, die für die Wiederherstellung von EC2 Amazon-Images in der Ziel-Availability Zone und Region erforderlich ist.

• Bei einer Neuentwicklung wird Zeit benötigt, um die Infrastruktur für das EC2 Amazon-Image oder die wiederhergestellten EBS-Snapshots in der Availability Zone und Region des Ziels bereitzustellen.

• Bei einer Wiederherstellung von Grund auf wird die Zeit benötigt, um die systemeigenen vollständigen, differenziellen und Protokollsicherungen von SQL Server in der Availability Zone und Region des Ziels wiederherzustellen.

• Anwendungs- und externe Abhängigkeiten, die regionsübergreifend verfügbar sein müssen.

• Einschränkungen der Dateigrößen für Volumes und für das Hochladen auf Amazon S3.