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.
# 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.