Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# Homogene Datenbankmigration für SQL Server
AWS bietet Ihnen die Möglichkeit, SQL Server-Datenbanken in einer Cloud-Umgebung auszuführen. Für Entwickler und Datenbankadministratoren ist das Ausführen einer SQL Server-Datenbank in der AWS Cloud dem Ausführen einer SQL Server-Datenbank in einem Rechenzentrum sehr ähnlich. In diesem Abschnitt werden Optionen für die Migration Ihrer SQL Server-Datenbank von einer lokalen Umgebung oder einem Rechenzentrum in die AWS Cloud beschrieben.
AWS bietet drei Optionen für die Ausführung von SQL Server auf AWS, wie in der folgenden Tabelle beschrieben.
****
| Option | Highlights | Weitere Informationen |
| --- | --- | --- |
| SQL Server auf Amazon RDS | Managed Service bietet einfache Bereitstellung und Lizenzierung, ist kostengünstig, einfach einzurichten, zu verwalten und zu warten. | Abschnitt [Amazon RDS for SQL Server](rds-sql.md) |
| SQL Server auf Amazon RDS Benutzerdefiniert | Verwalteter Service, aber Sie behalten die Administratorrechte für die Datenbank und das zugrunde liegende Betriebssystem. | Abschnitt [Amazon RDS Benutzerdefiniert für SQL Server](rds-custom-sql.md) |
| SQL Server auf Amazon EC2 | Selbstverwaltet, bietet volle Kontrolle und Flexibilität. | [Abschnitt Amazon EC2 für SQL Server](ec2-sql.md) |
| SQL Server in der VMware Cloud auf AWS | Richten Sie Ihre SQL Server-Workloads in VMware Cloud on ein, skalieren und betreiben Sie sie AWS und integrieren Sie sie mit Directory Service Active Directory Connector und Amazon S3. | [VMware Abschnitt Cloud on AWS für SQL Server](vmware-sql.md) |
**Notice (Hinweis)**
Seit dem 30. April 2024 AWS wird VMware Cloud on nicht mehr von AWS oder seinen Vertriebspartnern weiterverkauft. Der Service wird weiterhin über Broadcom verfügbar sein. Wir empfehlen Ihnen, sich für weitere Informationen an Ihren AWS Vertreter zu wenden.
Ihre Anwendungsanforderungen, Datenbankfunktionen, Funktionalität, Wachstumskapazität und die allgemeine Komplexität der Architektur bestimmen, welche Option Sie wählen sollten. Wenn Sie mehrere SQL Server-Datenbanken migrieren AWS, eignen sich einige davon möglicherweise hervorragend für Amazon RDS, während andere möglicherweise besser für die direkte Ausführung auf Amazon EC2 geeignet sind. Möglicherweise verfügen Sie über Datenbanken, die auf der SQL Server Enterprise Edition ausgeführt werden, sich aber gut für die SQL Server Standard Edition eignen. Möglicherweise möchten Sie auch Ihre unter Windows ausgeführte SQL Server-Datenbank so modernisieren, dass sie auf einem Linux-Betriebssystem ausgeführt wird, um Kosten und Lizenzen zu sparen. Viele AWS Kunden führen mehrere SQL Server-Datenbank-Workloads in Amazon RDS, Amazon EC2 und VMware Cloud on aus. AWS
**Anmerkung**
Sie können Migration Hub Orchestrator verwenden, um Ihre SQL Server-Datenbankmigrationen zu Amazon EC2 oder Amazon RDS mithilfe nativer Sicherung und Wiederherstellung zu automatisieren und zu orchestrieren. [Weitere Informationen finden Sie im Abschnitt.AWS Migration Hub Orchestrator](mho.md)
# Amazon RDS für SQL Server
Amazon RDS for SQL Server ist ein verwalteter Datenbankservice, der die Bereitstellung und Verwaltung von SQL Server auf AWS vereinfacht. Amazon RDS macht es einfach, SQL Server-Bereitstellungen in der Cloud einzurichten, zu betreiben und zu skalieren. Mit Amazon RDS können Sie innerhalb von Minuten mehrere Versionen von SQL Server (2014, 2016, 2017, 2019 und 2022) und Editionen (einschließlich Express, Web, Standard und Enterprise) mit kosteneffizienter und anpassbarer Rechenkapazität bereitstellen. Sie können Amazon RDS for SQL Server Server-DB-Instances entweder mit Allzweck-SSD oder bereitgestelltem IOPS-SSD-Speicher bereitstellen. (Einzelheiten finden Sie in der AWS Dokumentation unter [Amazon RDS-Speichertypen](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html#Concepts.Storage).) Die bereitgestellte IOPS-SSD ist auf schnelle, vorhersehbare und konsistente I/O Leistung ausgelegt und für I/O-intensive, transaktionale (OLTP) Datenbank-Workloads optimiert.
Mit Amazon RDS können Sie sich auf die Anwendungsentwicklung konzentrieren, da es zeitaufwändige Datenbankverwaltungsaufgaben wie Bereitstellung, Backups, Software-Patching, Überwachung und Hardwareskalierung übernimmt. Amazon RDS for SQL Server bietet auch Multi-AZ-Bereitstellungen und Read Replicas (für SQL Server Enterprise Edition), um hohe Verfügbarkeit, Leistung, Skalierbarkeit und Zuverlässigkeit für Produktionsworkloads zu gewährleisten.
## Wann sollten Sie sich für Amazon RDS entscheiden?
Amazon RDS for SQL Server ist eine Migrationsoption, wenn:
+ Sie möchten sich auf Ihr Geschäft und Ihre Anwendungen konzentrieren und sich AWS um undifferenzierte, schwere Aufgaben wie die Bereitstellung der Datenbank, die Verwaltung von Sicherungs- und Wiederherstellungsaufgaben, die Verwaltung von Sicherheitspatches, kleinere Upgrades der SQL Server-Version und die Speicherverwaltung kümmern.
+ Sie benötigen eine hochverfügbare Datenbanklösung und möchten die Vorteile der von Amazon RDS angebotenen synchronen Multi-AZ-Replikation per Knopfdruck nutzen, ohne Datenbankspiegelung, Failover-Cluster oder Always-On-Verfügbarkeitsgruppen manuell einrichten und verwalten zu müssen.
+ Sie möchten die SQL Server-Lizenz als Teil der Instanzkosten auf Stundenbasis bezahlen, anstatt eine große Vorabinvestition zu tätigen.
+ Ihre Datenbankgröße und Ihre IOPS-Anforderungen werden von Amazon RDS for SQL Server unterstützt. Die aktuellen Höchstgrenzen finden Sie in der AWS Dokumentation unter [Amazon RDS DB Instance Storage](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html).
+ Sie möchten keine Backups oder point-in-time Wiederherstellungen Ihrer Datenbank verwalten.
+ Sie möchten sich auf wichtige Aufgaben wie Leistungsoptimierung und Schemaoptimierung konzentrieren, anstatt sich auf die tägliche Verwaltung der Datenbank zu konzentrieren.
+ Sie möchten den Instanztyp auf der Grundlage Ihrer Workload-Muster nach oben oder unten skalieren, ohne sich Gedanken über die Komplexität der Lizenzierung machen zu müssen.
Wenn Sie sich nach der Bewertung Ihrer Datenbank- und Projektanforderungen für eine Migration zu Amazon RDS for SQL Server entscheiden, lesen Sie sich die Details in den folgenden Abschnitten durch und lesen Sie sich die [bewährten Methoden für die Migration](best-practices.md) durch, auf die wir weiter unten in diesem Leitfaden eingehen.
Informationen zu den derzeit unterstützten Funktionen, Versionen und Optionen von SQL Server finden Sie unter [Funktionen von Amazon RDS for SQL Server](https://aws.amazon.com/rds/sqlserver/features/) auf der AWS Website, Choosing [between Amazon EC2 and Amazon RDS](comparison.md) weiter unten in diesem Handbuch und [Microsoft SQL Server on Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_SQLServer.html) in der AWS Dokumentation. Wenn Sie zu Amazon RDS Custom wechseln, lesen Sie sich unbedingt die [Anforderungen und Einschränkungen für Amazon RDS Custom for SQL Server](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/custom-reqs-limits-MS.html) durch.
## Hohe Verfügbarkeit
Amazon RDS bietet Hochverfügbarkeit und Failover-Unterstützung für Datenbanken, die mit der Multi-AZ-Option bereitgestellt werden. Wenn Sie Ihre Datenbank mit der Multi-AZ-Option bereitstellen, stellt Amazon RDS automatisch eine synchrone Standby-Instance in einer anderen Availability Zone bereit und verwaltet diese. Die Primärdatenbank repliziert die Daten synchron auf die Standby-Instance. Wenn Probleme auftreten, repariert Amazon RDS automatisch die fehlerhafte Instance und stellt die Synchronisation wieder her. Im Falle eines Infrastrukturausfalls oder einer Unterbrechung der Availability Zone führt Amazon RDS einen automatischen Failover zur Standby-Instance durch. Ein Failover erfolgt nur, wenn die Standby- und Primärdatenbank vollständig synchronisiert sind. Da der Endpunkt für die Primär- und Standby-Instances derselbe bleibt, können Sie den Datenbankbetrieb wieder aufnehmen, sobald der Failover abgeschlossen ist, ohne dass ein manuelles Eingreifen erforderlich ist. Die Failover-Zeit hängt von der Zeit ab, die benötigt wird, um den Wiederherstellungsprozess abzuschließen. Große Transaktionen erhöhen die Failover-Zeit.
Das folgende Diagramm veranschaulicht die Multi-AZ-Bereitstellungsoption von Amazon RDS for SQL Server.
![\[Amazon RDS for SQL Server in a Multi-AZ configuration\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/migration-sql-server/images/sql-migration-rds-ha.png)
Wenn Sie SQL Server in einer Multi-AZ-Konfiguration einrichten, konfiguriert Amazon RDS automatisch die Standby-Datenbank-Instance mithilfe von Datenbankspiegelung oder AlwaysOn-Verfügbarkeitsgruppen, basierend auf der Version von SQL Server, die Sie bereitstellen. Die spezifischen Versionen und Editionen von SQL Server sind in der [Amazon RDS-Dokumentation](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_SQLServerMultiAZ.html) aufgeführt.
In Multi-AZ-Bereitstellungen werden Operationen wie die Skalierung von Instanzen oder System-Upgrades wie das Patchen von Betriebssystemen (OS) zunächst auf der Standby-Instance angewendet, bevor der automatische Failover der primären Instance durchgeführt wird, um die Verfügbarkeit zu erhöhen.
Aufgrund der Failover-Optimierung von SQL Server können bestimmte Workloads eine höhere I/O-Last auf der Standby-Instanz erzeugen als auf der Primärinstanz, insbesondere bei Bereitstellungen mit Datenbankspiegelung. Diese Funktionalität kann zu höheren IOPS auf der Standby-Instanz führen. Wir empfehlen, dass Sie bei der Bereitstellung des Speichertyps und der IOPS Ihrer Amazon RDS for SQL Server-DB-Instance die maximalen IOPS-Anforderungen sowohl der primären als auch der Standby-Instances berücksichtigen. Sie können auch angeben`MultiSubnetFailover=True`, ob Ihr Client-Treiber dies unterstützt, um die Failover-Zeit erheblich zu reduzieren.
### Einschränkungen
+ Die Multi-AZ-Option ist für SQL Server Express und Web Editionen nicht verfügbar. Sie ist nur für die Editionen SQL Server Standard und Enterprise verfügbar.
+ Sie können die Standby-DB-Instance nicht so konfigurieren, dass sie die Datenbankleseaktivität akzeptiert.
+ Regionsübergreifendes Multi-AZ wird nicht unterstützt.
+ In Amazon RDS können Sie einen Stop-Befehl für eine eigenständige DB-Instance ausgeben und die Instance im gestoppten Zustand belassen, um Rechengebühren zu vermeiden. Sie können eine Amazon-RDS-for-SQL-Server-DB-Instance in einer Multi-AZ-Konfiguration nicht anhalten. Stattdessen können Sie die Instance beenden, vor der Kündigung einen letzten Snapshot erstellen und bei Bedarf aus dem Snapshot eine neue Amazon RDS-Instance erstellen. Oder Sie können zuerst die Multi-AZ-Konfiguration entfernen und dann die Instance beenden. Nach sieben Tagen wird Ihre gestoppte Instance neu gestartet, sodass alle ausstehenden Wartungsarbeiten durchgeführt werden können.
Weitere Einschränkungen finden Sie in den [Hinweisen und Empfehlungen zur Bereitstellung von Microsoft SQL Server Multi-AZ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_SQLServerMultiAZ.html#USER_SQLServerMultiAZ.Recommendations) in der Amazon RDS-Dokumentation.
## Read Replicas
Read Replicas bieten Skalierbarkeit und Lastenausgleich. Eine SQL Server-Lesereplik ist eine physische Kopie einer Amazon RDS for SQL Server-DB-Instance, die nur für Lesezwecke verwendet wird. Amazon RDS trägt dazu bei, die Belastung der primären DB-Instance zu reduzieren, indem schreibgeschützte Workloads auf die Read Replica-DB-Instance ausgelagert werden. An Ihrer primären DB-Instance vorgenommene Aktualisierungen werden asynchron auf die Read Replica-Instance kopiert.
Wenn Sie eine Read Replica anfordern, erstellt Amazon RDS einen Snapshot der Quell-DB-Instance, und dieser Snapshot wird zur Read Replica. Beim Erstellen und Löschen einer Read Replica tritt kein Ausfall auf. Amazon RDS for SQL Server aktualisiert die Primärdatenbank unmittelbar nach dem Upgrade der Read Replicas, unabhängig vom Wartungsfenster. Jede Read Replica verfügt über einen separaten Endpunkt, über den Sie eine Verbindung zur Read Replica-Datenbank herstellen.
Amazon RDS for SQL Server macht es einfach, Read Replicas zu erstellen, indem Always-On-Verfügbarkeitsgruppen konfiguriert und sichere Netzwerkverbindungen zwischen einer primären DB-Instance und ihren Read Replicas aufrechterhalten werden.
Sie können eine Read Replica in derselben AWS Region wie Ihre Primärdatenbank oder in einer anderen Region einrichten. Sie können bis zu fünf Read Replicas für eine Quell-DB-Instance erstellen.
**Anmerkung**
Read Replicas sind nur mit den folgenden SQL Server-Versionen und -Editionen verfügbar:
SQL Server 2017 Enterprise Edition 14.00.3049.1 oder höher
SQL Server 2016 Enterprise Edition 13.00.5216.0 oder höher
SQL Server-Versionen und -Editionen, die die Datenbankspiegelung für Multi-AZ-Umgebungen unterstützen, bieten keine Read Replicas.
Das folgende Diagramm zeigt eine Amazon RDS for SQL Server-DB-Instance in einer Multi-AZ-Umgebung mit einer Read Replica in einer anderen Availability Zone innerhalb derselben AWS Region. Nicht alle AWS Regionen bieten mehr als zwei Availability Zones. Sie sollten daher [überprüfen, welche Region](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/) Sie verwenden möchten, bevor Sie diese Strategie anwenden.
![\[Amazon RDS for SQL Server with a read replica in another Availability Zone in the same Region\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/migration-sql-server/images/sql-migration-rds-rr-same-region.png)
Eine SQL Server-Lesereplik erlaubt keine Schreibvorgänge. Sie können das Lesereplikat jedoch heraufstufen, um es schreibbar zu machen. Nachdem Sie es heraufgestuft haben, können Sie es nicht wieder in eine Read Replica umwandeln. Sie wird zu einer einzelnen, eigenständigen DB-Instance, die keine Beziehungen zu ihrer ursprünglichen primären Datenbank-Instance hat. Die Daten in der hochgestuften Read Replica stimmen mit den Daten in der Quell-DB-Instance bis zu dem Zeitpunkt überein, zu dem die Anfrage zur Heraufstufung gestellt wurde. Die Version der SQL Server-DB-Engine der Quell-DB-Instance und all ihrer Read Replicas wird identisch sein.
Für eine effiziente Replikation empfehlen wir Folgendes:
+ Richten Sie jede Read Replica mit denselben Rechen- und Speicherressourcen ein wie die Quell-DB-Instance.
+ Sie müssen automatische Backups auf der Quell-DB-Instance aktivieren, indem Sie den Aufbewahrungszeitraum für Backups auf einen anderen Wert als 0 (Null) setzen.
+ Die Quell-DB-Instance muss in einer Multi-AZ-Umgebung mit AlwaysOn-Verfügbarkeitsgruppen bereitgestellt werden.
Informationen zur Unterstützung, Editionen und Einschränkungen von SQL Server-Versionen finden [Sie unter Einschränkungen von Read Replica with SQL Server](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/SQLServer.ReadReplicas.html#SQLServer.ReadReplicas.Limitations) in der Amazon RDS-Dokumentation.
Weitere Informationen zur Verwendung von Read Replicas finden Sie in der Dokumentation unter [Working with Read Replicas](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html) und [Working with SQL Server Read Replicas for Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/SQLServer.ReadReplicas.html). AWS Weitere Informationen zu den Kosten von Datenübertragungen finden Sie unter [Amazon RDS – Preise](https://aws.amazon.com/rds/pricing/).
## Notfallwiederherstellung
Mit Amazon RDS for SQL Server können Sie eine zuverlässige, regionsübergreifende Disaster Recovery (DR) -Strategie entwickeln. Die Hauptgründe für die Entwicklung einer DR-Lösung sind Geschäftskontinuität und Compliance:
+ Eine effektive DR-Strategie hilft Ihnen dabei, Ihre Systeme bei einem katastrophalen Ereignis mit minimalen oder gar keinen Unterbrechungen am Laufen zu halten. Eine zuverlässige und effektive regionsübergreifende DR-Strategie sorgt dafür, dass Ihr Unternehmen auch dann weiterläuft, wenn eine ganze Region offline geht.
+ Eine regionsübergreifende DR-Lösung hilft Ihnen dabei, Prüf- und Compliance-Anforderungen zu erfüllen.
Recovery Point Objective (RPO), Recovery Time Objective (RTO) und Kosten sind drei wichtige Kennzahlen, die Sie bei der Entwicklung Ihrer DR-Strategie berücksichtigen sollten. Weitere Optionen für die Bereitstellung regionsübergreifender Replikate finden Sie unter. [AWS Marketplace](https://aws.amazon.com/marketplace/) Weitere Informationen zu diesen Ansätzen finden Sie unter [Regionsübergreifende Notfallwiederherstellung von Amazon RDS for SQL Server](https://aws.amazon.com/blogs/database/cross-region-disaster-recovery-of-amazon-rds-for-sql-server/) im AWS Datenbank-Blog.
# Amazon RDS Custom für SQL Server
Wenn Sie aufgrund von Anpassungsanforderungen für Drittanbieteranwendungen nicht zu einem vollständig verwalteten Service wie Amazon RDS wechseln können, können Sie zu Amazon RDS Custom for SQL Server migrieren. Mit Amazon RDS Custom können Sie Administratorrechte für die Datenbank und das zugrunde liegende Betriebssystem behalten, um abhängige Anwendungen zu aktivieren.
## Wann sollten Sie sich für Amazon RDS Custom for SQL Server entscheiden?
Amazon RDS Custom for SQL Server ist eine gute Migrationsoption, wenn:
+ Sie haben ältere, benutzerdefinierte und verpackte Anwendungen, die Zugriff auf das zugrunde liegende Betriebssystem und die Datenbankumgebung benötigen.
+ Sie benötigen Administratorzugriff, um die Anforderungen der herstellerspezifischen Anwendungsbereitstellung zu erfüllen.
+ Sie benötigen Zugriff auf das zugrunde liegende Betriebssystem, um Einstellungen zu konfigurieren, Patches zu installieren und native Funktionen zu aktivieren, um die Anforderungen der abhängigen Anwendung zu erfüllen.
+ Sie möchten auf die Datenbankumgebung zugreifen und diese anpassen (indem Sie benutzerdefinierte Datenbank-Patches anwenden oder Betriebssystempakete ändern), um sie an Ihre Datenbank- und Anwendungsanforderungen anzupassen.
## Funktionsweise
Um Amazon RDS Custom for SQL Server zu verwenden, lesen Sie sich die [Anforderungen](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/custom-reqs-limits-MS.html#custom-reqs-limits.reqsMS) in der Dokumentation zu Amazon RDS Custom for SQL Server durch. Sie müssen zuerst Ihre Umgebung für Amazon RDS Custom for SQL Server einrichten, wie in der [Amazon RDS-Dokumentation](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/custom-setup-sqlserver.html) beschrieben. Nachdem die Umgebung eingerichtet ist, folgen Sie diesen Schritten, die in der folgenden Abbildung dargestellt sind:
1. Erstellen Sie eine Amazon RDS Custom for SQL Server-DB-Instance aus einer von Amazon RDS Custom angebotenen SQL Server-Engine-Version.
Amazon RDS Custom for SQL Server unterstützt derzeit SQL Server 2019 und SQL Server 2022 unter Windows 2019 mit den in der Dokumentation aufgeführten [unterstützten DB-Instance-Klassen](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/custom-reqs-limits-MS.html#custom-reqs-limits.instancesMS). Weitere Informationen finden Sie unter [Erstellen einer benutzerdefinierten RDS-DB-Instance für SQL Server](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/custom-creating-sqlserver.html#custom-creating-sqlserver.create).
1. Connect Ihre Anwendung mit dem Amazon RDS Custom DB-Instance-Endpunkt.
Weitere Informationen finden Sie unter [Herstellen einer Verbindung zu Ihrer benutzerdefinierten RDS-Instance mithilfe AWS Systems Manager](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/custom-creating-sqlserver.html#custom-creating-sqlserver.ssm) und [Herstellen einer Verbindung zu Ihrer benutzerdefinierten RDS-DB-Instance mithilfe von RDP](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/custom-creating-sqlserver.html#custom-creating-sqlserver.rdp).
1. (Optional) Greifen Sie auf den Host zu, um Ihre Software anzupassen.
1. Überwachen Sie Benachrichtigungen und Nachrichten, die von Amazon RDS Custom Automation generiert wurden.
Weitere Informationen zu diesen Schritten finden Sie in der [Amazon RDS Custom-Dokumentation](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/custom-sqlserver.workflow.html).
![\[Amazon RDS-Benutzerdefinierter Arbeitsablauf für SQL Server\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/migration-sql-server/images/custom-rds-sql-server.png)
Amazon RDS Custom ist ein verwalteter Datenbankservice, der die Einrichtung, den Betrieb und die Skalierung von Datenbanken in der Cloud automatisiert und Ihnen gleichzeitig Zugriff auf das zugrunde liegende Betriebssystem und die Datenbankumgebung gewährt. In Amazon RDS Custom for SQL Server können Sie Software installieren, um benutzerdefinierte Anwendungen und Agenten auszuführen. Da Sie privilegierten Zugriff auf den Host haben, können Sie Dateisysteme ändern, um ältere Anwendungen zu unterstützen. Sie können auch benutzerdefinierte Datenbank-Patches anwenden oder Betriebssystempakete auf Ihren Amazon RDS Custom DB-Instances ändern.
Wenn Sie Ihre Instance anpassen möchten, können Sie die Amazon RDS-Automatisierung für bis zu 24 Stunden pausieren und sie dann fortsetzen, wenn Ihre Anpassungsarbeiten abgeschlossen sind. Durch das Anhalten der Automatisierung wird verhindert, dass die Amazon RDS-Automatisierung Ihre Anpassungen direkt beeinträchtigt.
Wenn Sie die Automatisierung wieder aufnehmen, bestimmt der [Support-Perimeter](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/custom-troubleshooting.html#custom-troubleshooting.support-perimeter), ob Ihre Anpassung der Datenbank- oder Betriebssystemumgebung die benutzerdefinierte Amazon RDS-Automatisierung beeinträchtigt oder unterbricht. Amazon RDS Custom unterstützt Ihre Anpassung der Host- und Datenbankumgebung, solange Ihre Änderungen die DB-Instance nicht außerhalb des Support-Perimeters platzieren. Die Support-Perimeterprüfungen werden standardmäßig alle 30 Minuten durchgeführt und erfolgen auch nach Ereignissen wie dem Löschen von Snapshots oder der Deinstallation des Amazon RDS Custom Agents, der die DB-Instance überwacht. Der Amazon RDS Custom Agent ist eine wichtige Komponente, um die Funktionalität von Amazon RDS Custom sicherzustellen. Wenn Sie den Agenten deinstallieren, führt Amazon RDS Custom nach einer Minute die Support-Perimeterprüfung durch und verschiebt die DB-Instance außerhalb des Support-Perimeters.
Wenn Sie eine Amazon RDS Custom for SQL Server-DB-Instance einrichten, ist die Softwarelizenz enthalten. Das heißt, Sie müssen SQL Server-Lizenzen nicht separat erwerben. Weitere Informationen zur Lizenzierung finden Sie in Abschnitt 10.5 in den [AWS Servicebedingungen](https://aws.amazon.com/service-terms/). Wenn Sie über ein aktives AWS Premium Support-Konto verfügen, können Sie sich bei SQL Server-spezifischen Problemen an den AWS Premium-Support für Amazon RDS Custom wenden.
Amazon RDS Custom for SQL Server wird in einer begrenzten Auswahl von AWS-Regionen und mit begrenzten DB-Instance-Klassen unterstützt. Informationen zu diesen und anderen Einschränkungen finden Sie auf der Seite mit den [Anforderungen und Einschränkungen](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/custom-reqs-limits-MS.html) in der Dokumentation zu Amazon RDS Custom for SQL Server.
Wenn Sie über eine lokale SQL Server-Datenbank verfügen, können Sie den in der [Amazon RDS-Dokumentation](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/custom-migrating.html) beschriebenen Prozess befolgen, um sie mithilfe systemeigener Sicherungs- und Wiederherstellungsprogramme zu Amazon RDS Custom for SQL Server zu migrieren.
Weitere Informationen finden Sie in den folgenden Ressourcen:
+ [Neu — Amazon RDS Custom for SQL Server ist allgemein verfügbar](https://aws.amazon.com/blogs/aws/new-amazon-rds-custom-for-sql-server-is-generally-available/) (AWS News-Blog)
+ [Konfiguration der SQL Server-Replikation zwischen Amazon RDS Custom for SQL Server und Amazon RDS for SQL Server](https://aws.amazon.com/blogs/database/configure-sql-server-replication-between-amazon-rds-custom-for-sql-server-and-amazon-rds-for-sql-server/) (AWS Datenbank-Blog)
+ [Automatisieren Sie die lokale Migration oder die Migration von Amazon EC2 SQL Server zu Amazon RDS for SQL Server mithilfe von benutzerdefiniertem Protokollversand](https://aws.amazon.com/blogs/database/automate-on-premises-or-amazon-ec2-sql-server-to-amazon-rds-for-sql-server-migration-using-custom-log-shipping/) (AWS Datenbank-Blog)
+ [Konfiguration von Hochverfügbarkeit mit Always-On-Verfügbarkeitsgruppen auf Amazon RDS Custom for SQL Server](https://aws.amazon.com/blogs/database/configure-high-availability-with-always-on-availability-groups-on-amazon-rds-custom-for-sql-server/) (AWS Datenbank-Blog)
+ [Erste Schritte mit Amazon RDS Custom for SQL Server mithilfe einer CloudFormation Vorlage (Netzwerk-Setup)](https://aws.amazon.com/blogs/database/get-started-with-amazon-rds-custom-for-sql-server-using-an-aws-cloudformation-template-network-setup/) (AWS Datenbank-Blog)
+ [Migrieren Sie lokale SQL Server-Workloads mithilfe verteilter Verfügbarkeitsgruppen zu Amazon RDS Custom for SQL Server](https://aws.amazon.com/blogs/database/migrate-on-premises-sql-server-workloads-to-amazon-rds-custom-for-sql-server-using-distributed-availability-groups/) (AWS Datenbank-Blog)
+ [Optimieren Sie Ihre SQL Server-Kosten, indem Sie Bring Your Own Media (BYOM) auf Amazon RDS Custom for SQL Server](https://aws.amazon.com/blogs/database/optimize-your-sql-server-costs-by-using-bring-your-own-media-byom-on-amazon-rds-custom-for-sql-server/) verwenden (AWS Datenbank-Blog)
# Amazon EC2 für SQL Server
Amazon EC2 unterstützt eine selbstverwaltete SQL Server-Datenbank. Das heißt, Sie haben damit die volle Kontrolle über die Einrichtung der Infrastruktur und der Datenbankumgebung. Das Ausführen der Datenbank auf Amazon EC2 ist dem Ausführen der Datenbank auf Ihrem eigenen Server sehr ähnlich. Sie haben die volle Kontrolle über die Datenbank und den Zugriff auf Betriebssystemebene, sodass Sie die Tools Ihrer Wahl verwenden können, um das Betriebssystem, die Datenbanksoftware, Patches, Datenreplikation, Sicherung und Wiederherstellung zu verwalten. Für diese Migrationsoption müssen Sie alle Komponenten, einschließlich EC2-Instances, Speichervolumes, Skalierbarkeit, Netzwerk und Sicherheit, auf der Grundlage von bewährten AWS Architekturpraktiken einrichten, konfigurieren, verwalten und optimieren. Sie sind für die Datenreplikation und -wiederherstellung auf Ihren Instances in derselben oder in verschiedenen AWS Regionen verantwortlich.
## Wann sollten Sie sich für Amazon EC2 entscheiden?
Amazon EC2 ist eine gute Migrationsoption für Ihre SQL Server-Datenbank, wenn:
+ Sie benötigen die volle Kontrolle über die Datenbank und Zugriff auf das zugrunde liegende Betriebssystem, die Datenbankinstallation und -konfiguration.
+ Sie möchten Ihre Datenbank verwalten, einschließlich Backups und Wiederherstellung, Patchen des Betriebssystems und der Datenbank, Optimieren der Betriebssystem- und Datenbankparameter, Sicherheitsmanagement und Konfiguration von Hochverfügbarkeit oder Replikation.
+ Sie möchten Funktionen und Optionen verwenden, die derzeit nicht von Amazon RDS unterstützt werden. Einzelheiten finden Sie unter [Nicht unterstützte Funktionen und Funktionen mit eingeschränkter Unterstützung](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_SQLServer.html#SQLServer.Concepts.General.FeatureNonSupport) in der Amazon RDS-Dokumentation.
+ Sie benötigen eine bestimmte SQL Server-Version, die von Amazon RDS nicht unterstützt wird. Eine Liste der unterstützten Versionen und Editionen finden Sie in der [Amazon RDS-Dokumentation unter SQL Server-Versionen auf](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_SQLServer.html#SQLServer.Concepts.General.VersionSupport) Amazon RDS.
+ Ihre Anforderungen an Datenbankgröße und Leistung übertreffen die aktuellen Angebote von Amazon RDS for SQL Server. Einzelheiten finden Sie unter [Amazon RDS-DB-Instance-Speicher](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html) in der Amazon RDS-Dokumentation.
+ Sie möchten automatische Softwarepatches vermeiden, die möglicherweise nicht mit Ihren Anwendungen kompatibel sind.
+ Sie möchten Ihre eigene Lizenz mitbringen, anstatt das Modell mit Lizenz für Amazon RDS for SQL Server zu verwenden.
+ Sie möchten IOPS und Speicherkapazität erreichen, die über den aktuellen Grenzwerten liegen. Einzelheiten finden Sie unter [Amazon RDS-DB-Instance-Speicher](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html) in der Amazon RDS-Dokumentation.
Eine Liste der derzeit auf Amazon EC2 unterstützten SQL Server-Funktionen und -Versionen finden Sie weiter unten in diesem [Handbuch unter Choosing between Amazon EC2 and Amazon RDS](comparison.md).
# Hohe Verfügbarkeit
Sie können jede von SQL Server unterstützte Replikationstechnologie mit Ihrer SQL Server-Datenbank auf Amazon EC2 verwenden, um Hochverfügbarkeit, Datenschutz und Notfallwiederherstellung zu erreichen. Einige der gängigen Lösungen sind Protokollversand, Datenbankspiegelung, AlwaysOn-Verfügbarkeitsgruppen und AlwaysOn-Failover-Cluster-Instances.
Das folgende Diagramm zeigt, wie Sie SQL Server auf Amazon EC2 in mehreren Availability Zones innerhalb einer einzigen AWS Region verwenden können. Die primäre Datenbank ist eine Datenbank mit Lese-/Schreibzugriff, und die sekundäre Datenbank ist mit Protokollversand, Datenbankspiegelung oder Always-On-Verfügbarkeitsgruppen für hohe Verfügbarkeit konfiguriert. Alle Transaktionsdaten aus der Primärdatenbank werden übertragen und können asynchron für den Protokollversand und asynchron für Always-On-Verfügbarkeitsgruppen und Spiegelung auf die sekundäre Datenbank angewendet werden.
![\[SQL Server on Amazon EC2 in a Multi-AZ configuration in one AWS Region\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/migration-sql-server/images/sql-migration-ec2.png)
# Versand protokollieren
Mit dem Protokollversand können Sie Transaktionsprotokoll-Backups automatisch von einer primären Datenbank-Instance an eine oder mehrere sekundäre Datenbanken (auch bekannt als *Warm-Standby*) auf separaten DB-Instances senden. Beim Protokollversand werden Aufträge des SQL Server-Agents verwendet, um das Sichern, Kopieren und Anwenden der Transaktionsprotokollsicherungen zu automatisieren. Obwohl der Protokollversand in der Regel als Disaster Recovery-Funktion betrachtet wird, kann er auch für hohe Verfügbarkeit sorgen, da sekundäre DB-Instances heraufgestuft werden können, falls die primäre DB-Instance ausfällt. Wenn Ihr RTO und RPO flexibel sind oder Ihre Datenbanken nicht als äußerst geschäftskritisch angesehen werden, sollten Sie den Protokollversand in Betracht ziehen, um eine bessere Verfügbarkeit Ihrer SQL Server-Datenbanken zu gewährleisten.
Der Protokollversand erhöht die Verfügbarkeit von Datenbanken, indem er den Zugriff auf sekundäre Datenbanken ermöglicht, die bei Bedarf als schreibgeschützte Kopien der Primärdatenbank verwendet werden können. Sie können eine Verzögerung (eine längere Verzögerungszeit) konfigurieren, während der Sie versehentlich geänderte Daten in der Primärdatenbank wiederherstellen können, bevor diese Änderungen an die sekundäre Datenbank gesendet werden.
Wir empfehlen, die primären und sekundären DB-Instances in separaten Availability Zones auszuführen und eine Monitor-Instance bereitzustellen, um alle Details des Protokollversands nachzuverfolgen. Backup-, Kopier-, Wiederherstellungs- und Fehlerereignisse für eine Protokollversandgruppe sind in der Monitor-Instance verfügbar. Bei einer Konfiguration für den Protokollversand wird nicht automatisch ein Failover vom Primärserver auf den Sekundärserver durchgeführt. Jede der sekundären Datenbanken kann jedoch manuell online geschaltet werden, wenn die Primärdatenbank nicht mehr verfügbar ist.
Der Protokollversand wird häufig als Notfallwiederherstellungslösung verwendet, kann aber je nach Ihren Anwendungsanforderungen auch als Hochverfügbarkeitslösung verwendet werden. Verwenden Sie den Protokollversand in folgenden Fällen:
+ Sie haben flexible RTO- und RPO-Anforderungen. Der Versand von Protokollen bietet ein RPO von Minuten und ein RTO von Minuten bis Stunden.
+ Sie benötigen kein automatisches Failover auf die sekundäre Datenbank.
+ Sie möchten aus der sekundären Datenbank lesen, benötigen aber keine Lesbarkeit während eines Wiederherstellungsvorgangs.
Weitere Informationen zum Protokollversand finden Sie in der [Microsoft SQL Server-Dokumentation](https://docs.microsoft.com/en-us/sql/database-engine/log-shipping/about-log-shipping-sql-server).
# Datenbankspiegelung
Bei der Datenbankspiegelung wird eine Datenbank, die sich auf einer EC2-Instance befindet, auf einer separaten DB-Instance vollständig oder fast vollständig schreibgeschützt (Mirror) bereitgestellt. Amazon RDS verwendet Datenbankspiegelung, um Multi-AZ-Unterstützung für Amazon RDS for SQL Server bereitzustellen. Diese Funktion erhöht die Verfügbarkeit und den Schutz von Datenbanken und bietet einen Mechanismus, um Datenbanken während Upgrades verfügbar zu halten.
**Anmerkung**
Laut der [Microsoft-Dokumentation](https://docs.microsoft.com/en-us/sql/database-engine/database-mirroring/database-mirroring-sql-server) wird die Datenbankspiegelung in einer future Version von SQL Server entfernt. Sie sollten stattdessen planen, AlwaysOn-Verfügbarkeitsgruppen zu verwenden.
Bei der Datenbankspiegelung können SQL-Server eine von drei Rollen übernehmen:
+ Der Prinzipalserver, der die read/write Primärversion der Datenbank hostet.
+ Der Spiegelserver, der eine Kopie der Prinzipaldatenbank hostet.
+ Ein optionaler Zeugenserver. Dieser Server ist nur im Hochsicherheitsmodus verfügbar. Er überwacht den Status des Datenbankspiegels und automatisiert den Failover von der Primärdatenbank zur Spiegeldatenbank.
Zwischen dem Principal- und dem Spiegelserver wird eine Spiegelungssitzung eingerichtet. Während der Spiegelung werden alle Datenbankänderungen, die in der Prinzipaldatenbank vorgenommen werden, auch in der Spiegeldatenbank durchgeführt. Die Datenbankspiegelung kann entweder ein synchroner oder ein asynchroner Vorgang sein. Dies wird durch zwei Betriebsmodi für die Spiegelung bestimmt: den Hochsicherheitsmodus und den Hochleistungsmodus.
+ **Hochsicherheitsmodus: Dieser Modus** verwendet synchrone Operationen. In diesem Modus synchronisiert die Datenbankspiegelungssitzung die Einfüge-, Aktualisierungs- und Löschvorgänge aus der Prinzipaldatenbank so schnell wie möglich mit der Spiegeldatenbank. Sobald die Datenbank synchronisiert ist, wird die Transaktion sowohl in der Principal- als auch in der Spiegeldatenbank festgeschrieben. Wir empfehlen, diesen Betriebsmodus zu verwenden, wenn sich die Spiegeldatenbanken in derselben oder unterschiedlichen Availability Zones befinden, aber in derselben AWS Region gehostet werden.
+ **Hochleistungsmodus:** In diesem Modus werden asynchrone Operationen verwendet. In diesem Modus synchronisiert die Datenbankspiegelungssitzung die Einfüge-, Aktualisierungs- und Löschvorgänge von der Prinzipaldatenbank mit der Spiegeldatenbank. Es kann jedoch zu einer Verzögerung zwischen dem Zeitpunkt, zu dem die Prinzipaldatenbank Transaktionen festschreibt, und dem Zeitpunkt, zu dem die Spiegeldatenbank Transaktionen festschreibt, auftreten. Wir empfehlen, diesen Modus zu verwenden, wenn sich die Spiegeldatenbanken in verschiedenen Regionen befinden. AWS
Verwenden Sie die Datenbankspiegelung, wenn:
+ Sie haben strenge RTO- und RPO-Anforderungen und dürfen keine Verzögerungen zwischen der primären und der sekundären Datenbank haben. Die Datenbankspiegelung bietet ein RPO von null Sekunden (mit synchronem Commit) und ein RTO von Sekunden bis Minuten.
+ Sie müssen nicht aus der sekundären Datenbank lesen.
+ Sie möchten ein automatisches Failover durchführen, wenn Sie einen Zeugenserver im Synchronisierungsmodus konfiguriert haben.
+ Sie können keine AlwaysOn-Verfügbarkeitsgruppen verwenden, was die bevorzugte Option ist.
Einschränkungen:
+ Nur one-to-one Failover wird unterstützt. Es ist nicht möglich, mehrere Datenbankziele mit der Primärdatenbank zu synchronisieren.
Weitere Informationen zur Spiegelung finden Sie in der [Microsoft SQL Server-Dokumentation](https://docs.microsoft.com/en-us/sql/database-engine/database-mirroring/database-mirroring-sql-server).
# AlwaysOn-Verfügbarkeitsgruppen
SQL Server Always-On-Verfügbarkeitsgruppen bieten Hochverfügbarkeits- und Notfallwiederherstellungslösungen für SQL Server-Datenbanken. Eine Verfügbarkeitsgruppe besteht aus einer Reihe von Benutzerdatenbanken, für die gemeinsam ein Failover ausgeführt wird. Sie umfasst einen einzelnen Satz von read/write Primärdatenbanken und mehrere (ein bis acht) Sätze verwandter, sekundärer Datenbanken. Sie können die sekundären Datenbanken der Anwendungsebene als schreibgeschützte Kopien der Primärdatenbanken zur Verfügung stellen (nur SQL Server Enterprise Edition), um eine Scale-Out-Architektur für Lese-Workloads bereitzustellen. Sie können die sekundären Datenbanken auch für Sicherungsvorgänge verwenden.
SQL Server Always On-Verfügbarkeitsgruppen unterstützen sowohl den synchronen als auch den asynchronen Commit-Modus. Im synchronen Modus schreibt das primäre Replikat Datenbanktransaktionen fest, nachdem die Änderungen festgeschrieben oder in das Protokoll des sekundären Replikats geschrieben wurden. In diesem Modus können Sie ein geplantes manuelles Failover und ein automatisches Failover durchführen, wenn die Replikate synchron sind. Sie können den synchronen Commit-Modus zwischen SQL Server-Instanzen innerhalb derselben Umgebung verwenden (z. B. wenn sich alle Instanzen lokal oder alle Instanzen in einer lokalen Umgebung befinden). AWS
Im asynchronen Commit-Modus schreibt das primäre Replikat Datenbanktransaktionen fest, ohne auf das sekundäre Replikat zu warten. Sie können den asynchronen Commit-Modus zwischen SQL Server-Instanzen verwenden, die sich in unterschiedlichen Umgebungen befinden (z. B. wenn Sie Instanzen vor Ort und in der Umgebung haben). AWS
Sie können AlwaysOn-Verfügbarkeitsgruppen für Hochverfügbarkeit oder Notfallwiederherstellung verwenden. Verwenden Sie diese Methode, wenn:
+ Sie haben strenge RTO- und RPO-Anforderungen. AlwaysOn-Verfügbarkeitsgruppen bieten einen RPO-Wert von Sekunden und einen RTO-Wert von Sekunden bis Minuten.
+ Sie möchten eine Gruppe von Datenbanken verwalten und ein Failover durchführen. AlwaysOn-Verfügbarkeitsgruppen unterstützen 0-4 sekundäre Replikate im synchronen Commit-Modus für SQL Server 2019.
+ Sie möchten den automatischen Failover im synchronen Commit-Modus verwenden und benötigen keinen Zeugenserver.
+ Sie möchten aus der sekundären Datenbank lesen.
+ Sie möchten mehrere Datenbankziele mit Ihrer Primärdatenbank synchronisieren.
Ab SQL Server 2016 SP1 bietet die SQL Server Standard Edition grundlegende Hochverfügbarkeit für eine einzelne, nicht lesbare sekundäre Datenbank und einen Listener pro Verfügbarkeitsgruppe. Sie unterstützt außerdem maximal zwei Knoten pro Verfügbarkeitsgruppe.
# Immer aktive Failover-Clusterinstanzen
SQL Server Always On Failover Cluster Instances (FCIs) verwenden Windows Server Failover Clustering (WSFC), um Hochverfügbarkeit auf Serverinstanzebene bereitzustellen. Eine FCI ist eine einzelne Instanz von SQL Server, die auf allen WSFC-Knoten installiert wird, um eine hohe Verfügbarkeit für die gesamte Installation von SQL Server zu gewährleisten. Wenn auf dem zugrunde liegenden Knoten Hardware-, Betriebssystem-, Anwendungs- oder Dienstausfälle auftreten, wird alles innerhalb der SQL Server-Instanz auf einen anderen WSFC-Knoten verschoben. Dazu gehören Systemdatenbanken, SQL Server-Logins, SQL Server-Agent-Jobs und Zertifikate.
Eine FCI ist im Allgemeinen einer Always-On-Verfügbarkeitsgruppe vorzuziehen, wenn:
+ Sie verwenden die SQL Server Standard Edition anstelle der Enterprise Edition.
+ Sie haben eine große Anzahl kleiner Datenbanken pro Instanz.
+ Sie ändern ständig Objekte auf Instanzebene wie SQL Server-Agent-Jobs, Anmeldungen usw.
Es gibt vier Optionen für die Bereitstellung auf: FCIs AWS
+ Amazon EBS Multi-Attach mit dauerhaften Reservierungen
+ Amazon FSx für Windows-Dateiserver
+ Amazon FSx für NetApp ONTAP
+ Lösungen von Partnern AWS
## Amazon EBS Multi-Attach mit dauerhaften Reservierungen verwenden
[Amazon EBS Multi-Attach mit NVMe Reservierungen](https://docs.aws.amazon.com/ebs/latest/userguide/nvme-reservations.html) unterstützt die Erstellung von SQL Server FCIs mit Amazon `io2` EBS-Volumes als gemeinsam genutztem Speicher auf Windows Server-Failover-Clustern. Diese Funktion vereinfacht den Einrichtungsprozess für Failover-Cluster, indem Sie mithilfe von Amazon `io2` EBS-Volumes einen Failover-Cluster erstellen können. Diese Volumes können nur Instances zugeordnet werden, die sich in derselben Availability Zone befinden. Um Windows Server-Failovercluster mithilfe von Amazon `io2` EBS-Volumes bereitzustellen, müssen Sie die neuesten AWS NVMe Treiber verwenden.
Amazon EBS-Volumes und Instance-Speicher-Volumes werden als NVMe Blockgeräte auf [Nitro-basierten](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/instance-types.html#ec2-nitro-instances) Instances verfügbar gemacht. Sie müssen den [AWS NVMe Treiber](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/aws-nvme-drivers.html) installiert und die [persistente SCSI-Reservierungsfunktion](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/aws-nvme-drivers.html#configure-scsi-persistent-reservations) konfiguriert haben, wenn Sie Amazon `io2` EBS-Volumes verwenden, um WSFC und SQL Server zu bilden. FCIs
Weitere Informationen zu dieser Funktion finden Sie im AWS Blogbeitrag [So stellen Sie einen SQL Server-Failover-Cluster mit Amazon EBS Multi-Attach auf](https://aws.amazon.com/blogs/modernizing-with-aws/how-to-deploy-a-sql-server-failover-cluster-with-amazon-ebs-multi-attach-on-windows-server/) Windows Server bereit.
## Amazon FSx für Windows File Server verwenden
[Amazon FSx für Windows File Server](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html) bietet vollständig verwalteten gemeinsamen Dateispeicher. Es repliziert den Speicher automatisch synchron in zwei Availability Zones, um eine hohe Verfügbarkeit zu gewährleisten. Die Verwendung von FSx for Windows File Server für die Dateispeicherung hilft dabei, SQL Server-Hochverfügbarkeitsbereitstellungen auf Amazon EC2 zu vereinfachen und zu optimieren.
Bei Microsoft SQL Server wird Hochverfügbarkeit in der Regel über mehrere Datenbankknoten in einem WSFC bereitgestellt, und jeder Knoten hat Zugriff auf gemeinsam genutzten Dateispeicher. Sie können Windows File Server auf zwei Arten als gemeinsam genutzten Speicher für SQL Server-Hochverfügbarkeitsbereitstellungen verwenden FSx : als Speicher für aktive Datendateien und als SMB-Dateifreigabezeuge.
Informationen darüber, wie Sie die Komplexität und die Kosten der Ausführung von SQL Server FCI-Bereitstellungen mithilfe FSx von Windows File Server reduzieren können, finden Sie im Blogbeitrag [Vereinfachen Sie Ihre Microsoft SQL Server-Hochverfügbarkeitsbereitstellungen mithilfe von Amazon FSx for Windows](https://aws.amazon.com/blogs/storage/simplify-your-microsoft-sql-server-high-availability-deployments-using-amazon-fsx-for-windows-file-server/) File Server. Der Blogbeitrag enthält auch step-by-step Anweisungen zur Bereitstellung von SQL Server FCIs mithilfe eines Amazon FSx Multi-AZ-Dateisystems als gemeinsam genutzte Speicherlösung. Weitere Informationen finden Sie in der [Amazon FSx for Windows File Server-Dokumentation](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html).
## Amazon FSx für NetApp ONTAP verwenden
Amazon FSx for NetApp ONTAP ist ein vollständig verwalteter Service, der äußerst zuverlässige, skalierbare, leistungsstarke und funktionsreiche Dateispeicherung bietet, die auf dem NetApp ONTAP-Dateisystem basiert. FSx for ONTAP kombiniert die vertrauten Funktionen, Leistungen, Fähigkeiten und API-Operationen von NetApp Dateisystemen mit der Agilität, Skalierbarkeit und Einfachheit eines vollständig verwalteten Services. AWS
FSx for ONTAP bietet Multiprotokollzugriff auf Daten über die NFS-, SMB- und iSCSI-Protokolle für Windows- und Linux-Systeme. Sie können eine hochverfügbare SQL Server Always On FCI-Architektur erstellen, wie im Blogbeitrag [SQL Server High Availability Deployments Using Amazon FSx for NetApp ](https://aws.amazon.com/blogs/modernizing-with-aws/sql-server-high-availability-amazon-fsx-for-netapp-ontap/) ONTAP ausführlich beschrieben. FSx for ONTAP bietet auch eine schnelle Möglichkeit, ein Failover Ihrer SQL Server-Umgebung auf eine andere Umgebung durchzuführen, um die Anforderungen AWS-Region an Recovery Time Objective (RTO) und Recovery Point Objective (RPO) zu erfüllen. Weitere Informationen finden Sie im Blogbeitrag [Implementieren von HA und DR für die SQL Server Always-On-Failover-Clusterinstanz mithilfe](https://aws.amazon.com/blogs/storage/implementing-ha-and-dr-for-sql-server-always-on-failover-cluster-instance-using-amazon-fsx-for-netapp-ontap/) von ONTAP. FSx
Sie können es auch für AWS Launch Wizard die Bereitstellung von SQL Server-Lösungen verwenden AWS, wobei Always-On-Verfügbarkeitsgruppen und Einzelknotenbereitstellungen unterstützt werden. Launch Wizard unterstützt die Bereitstellung für SQL Server Always on FCIs auf Amazon EC2 mit FSx für ONTAP als gemeinsam genutzten Speicher. Dieser Service spart Ihnen Zeit und Mühe, indem er einen komplexen manuellen Bereitstellungsprozess durch einen geführten, konsolenbasierten Assistenten ersetzt, der die Migration Ihrer lokalen SQL Server-Workloads beschleunigt, die auf gemeinsam genutzten Speicher angewiesen sind. Weitere Informationen darüber, wie Launch Wizard Ihnen helfen kann, SQL Server innerhalb weniger Stunden bereitzustellen und zu konfigurieren, finden Sie FCIs im Blogbeitrag [Simplify SQL Server Always On-Bereitstellungen mit AWS Launch Wizard und Amazon FSx](https://aws.amazon.com/blogs/storage/simplify-sql-server-always-on-deployments-with-the-aws-launch-wizard-and-amazon-fsx/). Launch Wizard unterstützt auch die Bereitstellung für SQL Server Always On, FCIs indem [Amazon FSx für Windows File Server](https://aws.amazon.com/fsx/windows/) als gemeinsam genutzte Speicherlösung verwendet wird.
## Verwenden von Lösungen von AWS Partnern
+ [SIOS DataKeeper](https://us.sios.com/) bietet Hochverfügbarkeits-Cluster-Failover-Unterstützung für alle Availability AWS-Regionen Zones. SIOS DataKeeper ist verfügbar in. [AWS Marketplace](https://aws.amazon.com/marketplace/seller-profile?id=3c91e2f7-fc8d-4cce-a8aa-1e37abcb4408)
+ [DxEnterprise](https://dh2i.com/dxenterprise-high-availability/)von DH2i ermöglicht ein vollautomatisches Failover von SQL Server-Verfügbarkeitsgruppen in Kubernetes und ein einheitliches Instanz-Failover für Windows und Linux. D2HI ist verfügbar in. [AWS Marketplace](https://aws.amazon.com/marketplace/seller-profile?id=4e97d4b7-3366-42fd-8be8-732d38c9e24b)
# FSx für Windows-Dateiserver
FSx for Windows File Server bietet vollständig verwalteten, äußerst zuverlässigen und skalierbaren Dateispeicher, auf den über das Server Message Block (SMB) -Protokoll zugegriffen werden kann. Es basiert auf Windows Server und bietet eine Vielzahl von Verwaltungsfunktionen wie Benutzerkontingente, Dateiwiederherstellung für Endbenutzer und Microsoft Active Directory (AD) -Integration. Es bietet Single-AZ- und Multi-AZ-Bereitstellungsoptionen, vollständig verwaltete Backups und Verschlüsselung von Daten im Speicher und bei der Übertragung. Mit den Speicheroptionen Solid-State-Drives (SSD) und Festplattenlaufwerke (HDD) können Sie Kosten und Leistung für Ihre Workloads optimieren. Außerdem können Sie den Speicher skalieren und die Durchsatzleistung Ihres Dateisystems jederzeit ändern. Auf den FSx Amazon-Dateispeicher kann von Windows- und Linux-Recheninstanzen aus zugegriffen werden AWS, die auf und vor Ort ausgeführt werden.
Amazon FSx erleichtert die Bereitstellung von gemeinsam genutztem Windows-Speicher für SQL Server-Bereitstellungen mit hoher Verfügbarkeit, da es kontinuierlich verfügbare Dateifreigaben (CA) und kleinere Dateisysteme unterstützt. Diese Option eignet sich für die folgenden Anwendungsfälle:
+ Als gemeinsam genutzter Speicher, der von SQL Server-Knoten in einer WSFC-Instanz verwendet wird.
+ Als SMB-Dateifreigabezeuge, der mit jedem SQL Server-Cluster mit WSFC verwendet werden kann.
Amazon FSx bietet schnelle Leistung mit einem Basisdurchsatz von bis zu 2 GB/second pro Dateisystem, Hunderttausenden von IOPS und konsistenten Latenzen unter einer Millisekunde.
Um die richtige Leistung für Ihre SQL-Instances bereitzustellen, können Sie ein Durchsatzniveau wählen, das unabhängig von der Größe Ihres Dateisystems ist. Höhere Durchsatzkapazitäten bedeuten auch höhere IOPS-Werte, die der Dateiserver für die SQL Server-Instanzen bereitstellen kann, die auf ihn zugreifen.
Die Speicherkapazität bestimmt nicht nur, wie viele Daten Sie speichern können, sondern auch, wie viele IOPS Sie auf dem Speicher ausführen können. Jedes Gigabyte Speicher bietet 3 IOPS. Sie können für jedes Dateisystem eine Größe von bis zu 64 TB bereitstellen.
Informationen zur Konfiguration und Verwendung von Amazon FSx zur Reduzierung der Komplexität und der Kosten Ihrer SQL Server-Hochverfügbarkeitsbereitstellungen finden Sie im AWS Storage-Blog unter [Vereinfachen Sie Ihre Microsoft SQL Server-Hochverfügbarkeitsbereitstellungen mithilfe von FSx Windows File Server](https://aws.amazon.com/blogs/storage/simplify-your-microsoft-sql-server-high-availability-deployments-using-amazon-fsx-for-windows-file-server/). Weitere Informationen zum Erstellen einer neuen CA-Freigabe finden Sie in der Dokumentation [FSx für Windows File Server](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/managing-file-shares.html#create-ca-share).
# Notfallwiederherstellung
Viele Unternehmen implementieren Hochverfügbarkeit für ihre SQL Server-Datenbanken, aber das ist für Unternehmen, die eine echte IT-Resilienz benötigen, nicht ausreichend. Wir empfehlen Ihnen, eine Notfallwiederherstellungslösung zu implementieren, um Datenverlust und Ausfallzeiten unternehmenskritischer Datenbanken zu vermeiden. Die Einführung einer Disaster Recovery-Architektur für mehrere Regionen für Ihre SQL Server-Bereitstellungen hilft Ihnen:
+ Sorgen Sie für Geschäftskontinuität
+ Verbessern Sie die Latenz für Ihren geografisch verteilten Kundenstamm
+ Erfüllen Sie Ihre Prüfungs- und behördlichen Anforderungen
Zu den Optionen für die Notfallwiederherstellung gehören [Protokollversand](ec2-log-shipping.md), [AlwaysOn-Verfügbarkeitsgruppen](ec2-always-on.md), [Amazon EBS-Snapshots](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-copy-snapshot.html), die in Amazon S3 gespeichert und AWS regionsübergreifend repliziert werden, [AlwaysOn-Failover-Cluster-Instances (FCIs)](ec2-fci.md) in Kombination mit AlwaysOn-Verfügbarkeitsgruppen und verteilte Verfügbarkeitsgruppen.
## Verteilte Verfügbarkeitsgruppen
Eine Architektur mit verteilten Verfügbarkeitsgruppen ist ein optimaler Ansatz für die Bereitstellung von SQL Server in mehreren Regionen. Eine verteilte Verfügbarkeitsgruppe ist ein besonderer Typ von Verfügbarkeitsgruppe, die sich über zwei separate Verfügbarkeitsgruppen erstreckt. Sie können sie sich als eine Verfügbarkeitsgruppe von Verfügbarkeitsgruppen vorstellen. Die zugrunde liegenden Verfügbarkeitsgruppen sind auf zwei verschiedenen WSFC-Clustern konfiguriert.
Verteilte Verfügbarkeitsgruppen sind lose miteinander verknüpft, was bedeutet, dass sie keinen einzigen WSFC-Cluster benötigen und von SQL Server verwaltet werden. Da die WSFC-Cluster einzeln verwaltet werden und Übertragungen hauptsächlich asynchron zwischen zwei Verfügbarkeitsgruppen erfolgen, ist es einfacher, die Notfallwiederherstellung an einem anderen Standort zu konfigurieren. Die primären Replikate in jeder Verfügbarkeitsgruppe synchronisieren ihre eigenen sekundären Replikate.
Verteilte Verfügbarkeitsgruppen unterstützen derzeit nur manuelles Failover. Um sicherzustellen, dass keine Daten verloren gehen, beenden Sie alle Transaktionen in den globalen Primärdatenbanken (d. h. in den Datenbanken der primären Verfügbarkeitsgruppe). Stellen Sie dann die verteilte Verfügbarkeitsgruppe auf synchrones Commit ein.
# VMware Cloud on AWS für SQL Server
**Notice (Hinweis)**
Seit dem 30. April 2024 AWS wird VMware Cloud on nicht mehr von AWS oder seinen Vertriebspartnern weiterverkauft. Der Service wird weiterhin über Broadcom verfügbar sein. Wir empfehlen Ihnen, sich für weitere Informationen an Ihren AWS Vertreter zu wenden.
[VMware Cloud on AWS](https://aws.amazon.com/vmware/) ist ein integriertes Cloud-Angebot, das gemeinsam von AWS und entwickelt wurde VMware. SQL Server lässt sich problemlos in VMware Cloud on integrieren AWS. Diese Migrationsoption ermöglicht es Ihnen, auf Ihren bestehenden Investitionen in Virtualisierung aufzubauen.
Sie können stündlich, AWS auf Abruf oder in Abonnementform auf VMware Cloud on zugreifen. Es umfasst dieselben VMware Kerntechnologien, die Sie in Ihren Rechenzentren ausführen, darunter vSphere Hypervisor (ESXi), Virtual SAN (vSAN) und die NSX-Netzwerkvirtualisierungsplattform, und wurde entwickelt, um eine effiziente, nahtlose Erfahrung bei der Verwaltung Ihrer SQL Server-Datenbanken zu bieten. Sie können den Speicher, die Rechenleistung und den Arbeitsspeicher Ihrer SQL Server-Datenbanken auf VMware Cloud On innerhalb weniger Minuten skalieren. AWS
VMware Cloud on AWS wird direkt auf der physischen Hardware ausgeführt, nutzt jedoch die Netzwerk- und Hardwarefunktionen, die zur Unterstützung des Infrastrukturmodells entwickelt wurden, bei dem AWS Sicherheit an erster Stelle steht. Das bedeutet, dass der VMware Virtualisierungsstapel auf der AWS Infrastruktur ausgeführt wird, ohne dass verschachtelte Virtualisierung verwendet werden muss.
VMware Cloud on AWS macht es einfach, Ihre SQL Server-Datenbank-Workloads einzurichten, zu skalieren und zu betreiben. AWS Es bietet Hochverfügbarkeitslösungen, lässt sich in das lokale Active Directory integrieren und bietet Zugriff auf AWS Dienste wie AWS Directory Service for Microsoft Active Directory AD Connector, Amazon Route 53 CloudWatch, Amazon und Amazon S3. Sie können Ihre Backups in Amazon S3 speichern und Ihren Disaster Recovery-Prozess modernisieren und vereinfachen.
## Wann sollten Sie VMware Cloud on wählen AWS
VMware Cloud on AWS ist eine Option für Ihre SQL Server-Datenbank, wenn:
+ Ihre SQL Server-Datenbanken werden bereits in einem lokalen Rechenzentrum in einer virtualisierten vSphere-Umgebung ausgeführt.
+ Sie haben eine große Anzahl von Datenbanken und benötigen aus einem der folgenden Gründe eine schnelle Migration (z. B. nur wenige Stunden) zur Cloud, ohne dass das Migrationsteam zusätzliche Arbeit leisten muss:
+ Erweiterung des Rechenzentrums. Sie benötigen On-Demand-Kapazität, um virtualisierte Desktops auszuführen, Anwendungen zu veröffentlichen oder eine development/testing Umgebung bereitzustellen.
+ Wiederherstellung im Notfall. Sie möchten ein neues Disaster Recovery-System einrichten oder Ihr bestehendes System ersetzen.
+ Cloud-Migration. Sie möchten Ihr gesamtes Rechenzentrum in die Cloud migrieren oder Ihre Infrastruktur auffrischen.
Wenn Ihre SQL Server-Datenbank mehr als 80.000 IOPS benötigt, können Sie vSAN verwenden.
Weitere Informationen finden Sie unter [In the Works — VMware Cloud AWS on](https://aws.amazon.com/blogs/aws/in-the-works-vmware-cloud-on-aws/) im AWS News-Blog und [Bereitstellen von Microsoft SQL Server on VMware Cloud AWS](https://aws.amazon.com/solutionspace/solutions/sql-server-vmware-cloud-on-aws/) auf der AWS Website.