Geschäftskontinuität und HADR für SQL Server in Azure Virtual Machines

  • Artikel

Gilt für:SQL Server auf Azure-VM

Geschäftskontinuität bedeutet, dass Sie Ihr Geschäft trotz eines Notfalls fortsetzen, die Wiederherstellung planen und sicherstellen können, dass Ihre Daten hochverfügbar sind. SQL Server in Azure Virtual Machines kann die Kosten für Datenbanklösungen mit Hochverfügbarkeit und Notfallwiederherstellung (High Availability, Disaster Recovery – HADR) senken.

Die meisten SQL Server-HADR-Lösungen werden auf virtuellen Computern (VMs) als reine Azure- und als Hybridlösungen unterstützt. In einer reinen Azure-Lösung wird das gesamte HADR-System in Azure ausgeführt. In einer Hybridkonfiguration wird ein Teil der Lösung in Azure und der andere Teil lokal in Ihrer Organisation ausgeführt. Die Flexibilität der Azure-Umgebung können Sie teilweise oder vollständig in Azure verschieben, um Budget- und HADR-Anforderungen der SQL Server-Datenbanksysteme zu erfüllen.

In diesem Artikel werden die Geschäftskontinuitätslösungen verglichen und gegenübergestellt, die für SQL Server auf Azure-VMs verfügbar sind.

Übersicht

Es ist Ihre Aufgabe sicherzustellen, dass Ihr Datenbanksystem über die gemäß der Vereinbarung zum Servicelevel (SLA) erforderlichen HADR-Funktionen verfügt. Die Tatsache, dass Azure Funktionen für Hochverfügbarkeit bereitstellt, z. B. die Selbstreparatur für Clouddienste und die Wiederherstellungserkennung für virtuelle Computer, gewährleistet noch nicht, dass Sie die Vereinbarung zum Servicelevel erfüllen können. Auch wenn diese Mechanismen Hochverfügbarkeit der virtuellen Computer sicherstellen, schützen Sie nicht die Verfügbarkeit der auf den virtuellen Computern ausgeführten SQL Server-Instanzen.

Es ist möglich, dass eine SQL Server-Instanz ausfällt, obwohl die VM online und betriebsbereit ist. Und selbst die Funktionen für Hochverfügbarkeit von Azure lassen Ausfallzeiten von virtuellen Computern zu, z. B. für die Wiederherstellung nach Software- oder Hardwareausfällen und zur Ermöglichung von Betriebssystemupgrades.

Georedundanter Speicher (GRS) in Azure wird mit einer Funktion namens „Georeplikation“ implementiert. GRS ist möglicherweise keine geeignete Notfallwiederherstellungslösung für Ihre Datenbanken. Da bei der Georeplikation Daten asynchron gesendet werden, können die neuesten Updates bei einem Ausfall verloren gehen. Weitere Informationen zu Einschränkungen bei der Georeplikation finden Sie im Abschnitt Georeplikationsunterstützung.

Hinweis

Sie können Ihre Failoverclusterinstanz und Verfügbarkeitsgruppenlösung jetzt mithilfe von Azure Migrate per Lift-und-Shift-Verfahren zu SQL Server auf Azure-VMs verschieben.

Bereitstellungsarchitekturen

Azure unterstützt die folgenden SQL Server-Technologien für Geschäftskontinuität:

Sie können mehrere Technologie kombinieren, um eine SQL Server-Lösung zu implementieren, die über Funktionen für Hochverfügbarkeit und Notfallwiederherstellung verfügt. Abhängig von der verwendeten Technologie erfordert eine Hybridbereitstellung ggf. einen VPN-Tunnel mit dem virtuellen Azure-Netzwerk. In den folgenden Abschnitten werden einige Beispiele für Bereitstellungsarchitekturen vorgestellt.

Reines Azure: Lösungen mit hoher Verfügbarkeit

Mit Always On-Verfügbarkeitsgruppen können Sie eine Lösung mit Hochverfügbarkeit für SQL Server auf Datenbankebene einsetzen. Sie können auch eine Lösung mit Hochverfügbarkeit auf Instanzebene mit Always On-Failoverclusterinstanzen erstellen. Für zusätzlichen Schutz können Sie Redundanz auf beiden Ebenen erstellen, indem Sie Verfügbarkeitsgruppen für Failoverclusterinstanzen erstellen.

Technologie Beispielarchitekturen
Verfügbarkeitsgruppen Verfügbare Replikate, die auf Azure-VMs in derselben Region ausgeführt werden, bieten Hochverfügbarkeit. Sie müssen eine Domänencontroller-VM konfigurieren, da für das Windows-Failoverclustering eine Active Directory-Domäne erforderlich ist.

Für höhere Redundanz und Verfügbarkeit können die Azure-VMs in unterschiedlichen Verfügbarkeitszonen bereitgestellt werden, wie in der Übersicht über Verfügbarkeitsgruppen beschrieben. Abbildung, die den „Domänencontroller“ über dem „WSFC-Cluster
Informationen zu den ersten Schritten finden Sie im Tutorial zu Verfügbarkeitsgruppen.
Failoverclusterinstanzen Failoverclusterinstanzen werden auf SQL Server-VMs unterstützt. Da das FCI-Feature freigegebenen Speicher erfordert, funktionieren fünf Lösungen mit SQL Server auf Azure-VMs:

– Verwenden von freigegebenen Azure-Datenträgern für Windows Server 2019. Freigegebene verwaltete Datenträger sind ein Azure-Produkt, das das gleichzeitige Anfügen eines verwalteten Datenträgers an mehrere virtuelle Computer zulässt. VMs im Cluster können von Ihrem angefügten Datenträger lesen oder auf ihn schreiben. Dies ist abhängig von der Reservierung, die von der gruppierten Anwendung über SCSI Persistent Reservations (SCSI PR) ausgewählt wurde. Bei SCSI PR handelt es sich um eine Speicherlösung nach Branchenstandard, der von Anwendungen im lokalen Storage Area Network (SAN) genutzt wird. Wenn Sie SCSI PR für einen verwalteten Datenträger aktivieren, können Sie diese Anwendungen unverändert zu Azure migrieren.

– Verwenden von Direkte Speicherplätze (S2D), um ein softwarebasiertes virtuelles SAN für Windows Server 2016 oder höher bereitzustellen

– Verwenden einer Premium-Dateifreigabe für Windows Server 2012 oder höher. Premium-Dateifreigaben sind SSD-gestützte Dateifreigaben mit konsistent geringer Latenz, die für die Verwendung mit der Failoverclusterinstanz vollständig unterstützt werden.

– Verwenden von Speicher, der von einer Partnerlösung für Clustering unterstützt wird. Ein spezifisches Beispiel mit SIOS DataKeeper finden Sie im Blogbeitrag Failoverclustering und SIOS DataKeeper.

– Verwenden von freigegebenem Blockspeicher für ein iSCSI-Remoteziel über Azure ExpressRoute. Beispielsweise macht NetApp Private Storage (NPS) ein iSCSI-Ziel über ExpressRoute mit Equinix für virtuelle Azure-Computer verfügbar.

Für gemeinsame Speichernutzungs- und Datenreplikationslösungen von Microsoft-Partnern sollten Sie sich an den Hersteller wenden, falls beim Failover Probleme in Bezug auf den Datenzugriff auftreten.

Bereiten Sie Ihre VM zuerst für FCI vor.

Reines Azure: Notfallwiederherstellungslösungen

Sie können eine Notfallwiederherstellungslösung für Ihre SQL Server-Datenbanken in Azure mit Verfügbarkeitsgruppen, Datenbankspiegelung oder Sicherung und Wiederherstellung mit Speicherblobs umsetzen.

Technologie Beispielarchitekturen
Verfügbarkeitsgruppen Die Replikate für die Verfügbarkeit werden in mehreren Rechenzentren auf virtuellen Azure-Computern für die Notfallwiederherstellung ausgeführt. Diese regionsübergreifende Lösung bietet Schutz vor dem vollständigen Ausfall einzelner Standorte.
Abbildung, die zwei Regionen mit einem „primären Replikat“ und einem „sekundären Replikat“ zeigt, die durch einen asynchronen Commit verbunden sind.
Alle Replikate innerhalb einer Region sollten sich in demselben Clouddienst und im gleichen virtuellen Netzwerk befinden. Da jede Region über ein separates virtuelles Netzwerk verfügt, erfordern diese Lösungen eine Verbindung zwischen den Netzwerken. Weitere Informationen finden Sie unter Konfigurieren einer Verbindung zwischen Netzwerken mit dem Azure-Portal. Ausführliche Anweisungen finden Sie unter Konfigurieren einer SQL Server Always On-Verfügbarkeitsgruppe in verschiedenen Azure-Regionen.
Spiegeln von Datenbanken Prinzipale, Spiegelungen und Server werden in verschiedenen Rechenzentren für die Notfallwiederherstellung ausgeführt. Sie müssen diese mithilfe von Serverzertifikaten bereitstellen.
Diagramm, das den Prinzipal in einer Region zeigt, der mit dem Spiegel in einer anderen Region mit Hochleistung verbunden ist.
Sicherung und Wiederherstellung mit Azure Blob Storage Die Produktionsdatenbanken werden direkt im Blobspeicher in einem anderen Rechenzentrum für die Notfallwiederherstellung gesichert.
Abbildung, die eine Datenbank in einer Region zeigt, die Daten in Blob Storage in einer anderen Region sichert.
Weitere Informationen finden Sie unter Sicherung und Wiederherstellung für SQL Server auf Azure-VMs.
Replikation und Failover von SQL Server zu Azure mit Azure Site Recovery Die SQL Server-Produktionsinstanz in einem Azure-Rechenzentrum, die für die Notfallwiederherstellung direkt in Azure Storage in einem anderen Azure-Rechenzentrum repliziert wird.
Abbildung, die eine Datenbank in einem Azure-Rechenzentrum zeigt, das die ASR-Replikation für die Notfallwiederherstellung in einem anderen Rechenzentrum nutzt.
Weitere Informationen finden Sie unter Schützen von SQL Server mit der Notfallwiederherstellung von SQL Server und Azure Site Recovery.

Hybrid-IT: Notfallwiederherstellungslösungen

Sie können eine Notfallwiederherstellungslösung für Ihre SQL Server-Datenbanken in einer IT-Hybridumgebung mit Verfügbarkeitsgruppen, Datenbankspiegelung, Protokollversand und Sicherung/Wiederherstellung mit Azure Blob Storage nutzen.

Technologie Beispielarchitekturen
Verfügbarkeitsgruppen Einige Replikate für die Verfügbarkeit werden auf virtuellen Azure-Computern ausgeführt und andere lokal, um eine standortübergreifende Notfallwiederherstellung sicherzustellen. Der Produktionsstandort kann sich entweder vor Ort oder in einem Azure-Rechenzentrum befinden.
Diagramm der Verfügbarkeitsgruppen.
Da sich alle Verfügbarkeitsreplikate in demselben Failovercluster befinden müssen, muss der Cluster beide Netzwerke (ein Failovercluster in mehreren Subnetzen) einschließen. Diese Konfiguration erfordert eine VPN-Verbindung zwischen Azure und dem lokalen Netzwerk.

Für die erfolgreiche Notfallwiederherstellung der Datenbanken sollten Sie auch einen Replikatdomänencontroller am Standort für die Notfallwiederherstellung installieren. Informationen zu den ersten Schritten finden Sie im Tutorial zu Verfügbarkeitsgruppen.
Spiegeln von Datenbanken Ein Partner wird auf einer Azure-VM und der andere lokal ausgeführt, um standortübergreifende Notfallwiederherstellung unter Verwendung von Serverzertifikaten zu gewährleisten. Die Partner müssen sich nicht in derselben Active Directory-Domäne befinden, und es ist keine VPN-Verbindung erforderlich.
Diagramm der Datenbankspiegelung.
Ein anderes Szenario zur Datenbankspiegelung sieht einen Partner vor, der auf einem virtuellen Azure-Computer ausgeführt wird, während der andere lokal in derselben Active Directory-Domäne für die standortübergreifende Notfallwiederherstellung ausgeführt wird. Eine VPN-Verbindung zwischen dem virtuellen Azure-Netzwerk und dem lokalen Netzwerk ist erforderlich.

Für die erfolgreiche Notfallwiederherstellung der Datenbanken sollten Sie auch einen Replikatdomänencontroller am Standort für die Notfallwiederherstellung installieren.
Protokollversand Ein Server wird auf einem virtuellen Azure-Computer und der andere lokal für die standortübergreifende Notfallwiederherstellung ausgeführt. Für das Versenden von Protokollen ist der Windows-Dateiaustausch erforderlich, deshalb muss eine VPN-Verbindung zwischen dem virtuellen Azure-Netzwerk und dem lokalen Netzwerk bestehen.
Diagramm des Protokollversands.
Für die erfolgreiche Notfallwiederherstellung der Datenbanken sollten Sie auch einen Replikatdomänencontroller am Standort für die Notfallwiederherstellung installieren.
Sicherung und Wiederherstellung mit Azure Blob Storage Die lokalen Produktionsdatenbanken werden direkt in Azure Blob Storage für Notfallwiederherstellung gesichert.
Diagramm der Sicherung und Wiederherstellung.
Weitere Informationen finden Sie unter Sicherung und Wiederherstellung für SQL Server in Azure Virtual Machines.
Replikation und Failover von SQL Server zu Azure mit Azure Site Recovery Die lokale SQL Server-Produktionsinstanz wird für Notfallwiederherstellung direkt in Azure Storage repliziert.
Diagramm der Replikation mithilfe von Azure Site Recovery.
Weitere Informationen finden Sie unter Schützen von SQL Server mit der Notfallwiederherstellung von SQL Server und Azure Site Recovery.

Kostenloses DR-Replikat in Azure

Wenn Sie über Software Assurance verfügen, können Sie hybride Notfallwiederherstellungspläne mit SQL Server implementieren, ohne dass zusätzliche Lizenzierungskosten für die passive Notfallwiederherstellungsinstanz anfallen. Sie qualifizieren sich auch für lizenzfreie DR-Replikate mit pay-as-you-go-Lizenzierung, wenn alle Replikate in Azure gehostet werden.

Beispielsweise können Sie zwei kostenlose passive sekundäre Replikate haben, wenn alle drei Replikate in Azure gehostet werden:

Diagramm mit zwei kostenlosen passiven Replikaten bei ausschließlichem Hosten in Azure.

Alternativ können Sie eine Hybridfailoverumgebung mit einem lizenzierten primären lokalen Replikat, einem kostenlosen passiven Replikat für die Hochverfügbarkeit, einem kostenlosen passiven Replikat für die lokale Notfallwiederherstellung und einem kostenlosen passiven Replikat für die Notfallwiederherstellung in Azure konfigurieren:

Diagramm mit drei kostenlosen passiven Replikaten in Hybridumgebung mit einem primären lokalen Replikat.

Weitere Informationen finden Sie in den Produktlizenzierungsbedingungen.

Navigieren Sie zu Ihrer SQL Server-VM-Ressource, um diesen Vorteil zu aktivieren. Klicken Sie unter Einstellungen auf Konfigurieren und unter SQL Server-Lizenz auf Hochverfügbarkeit/Notfallwiederherstellung. Aktivieren Sie das Kontrollkästchen, um zu bestätigen, dass diese SQL Server-VM als passives Replikat verwendet wird, und wählen Sie dann Anwenden aus, um die Einstellungen zu speichern. Beachten Sie, dass Kunden mit nutzungsbasierter Bezahlung auch berechtigt sind, den Lizenztyp Hochverfügbarkeit/Notfallwiederherstellung zu verwenden, wenn alle drei Replikate in Azure gehostet werden.

Diagramm zum Konfigurieren eines Notfallwiederherstellungsreplikats in Azure.

Wichtige Überlegungen zu SQL Server-HADR in Azure

Für die virtuellen Azure-Computer, den Speicher und die Netzwerkressourcen gelten andere Betriebsbedingungen als für eine lokale, nicht virtualisierte IT-Infrastruktur. Für eine erfolgreiche Implementierung einer SQL Server-HADR-Lösung in Azure sollten Sie diese Unterschiede kennen und Ihre Lösung daran anpassen.

Hochverfügbarkeitsknoten in einer Verfügbarkeitsgruppe

Durch Verfügbarkeitsgruppen in Azure können Sie Hochverfügbarkeitsknoten in separaten Fehler- und Updatedomänen platzieren. Die Azure-Plattform weist jedem virtuellen Computer in Ihrer Verfügbarkeitsgruppe eine Updatedomäne und eine Fehlerdomäne zu. Durch diese Konfiguration in einem Datencenter wird sichergestellt, dass während eines geplanten oder ungeplanten Wartungsereignisses mindestens ein virtueller Computer verfügbar ist und die von der Azure-SLA zugesicherte Verfügbarkeit von 99,95 Prozent eingehalten wird.

Um die Hochverfügbarkeitseinrichtung zu konfigurieren, platzieren Sie alle beteiligten virtuellen SQL Server-Computer in derselben Verfügbarkeitsgruppe, damit es bei einem Wartungsereignis nicht zu Anwendungs- oder Datenverlust kommt. Nur Knoten in demselben Clouddienst können Mitglieder derselben Verfügbarkeitsgruppe sein. Weitere Informationen finden Sie unter Verwalten der Verfügbarkeit virtueller Computer.

Hochverfügbarkeitsknoten in einer Verfügbarkeitszone

Verfügbarkeitszonen sind eindeutige physische Standorte in einer Azure-Region. Jede Zone besteht aus mindestens einem Datencenter mit eigener Stromversorgung, Kühlung und Netzwerk. Die physische Trennung von Verfügbarkeitszonen innerhalb einer Region schützt Anwendungen und Daten vor Rechenzentrumsausfällen, indem sichergestellt wird, dass mindestens ein virtueller Computer verfügbar ist. So wird eine Azure-SLA (Vereinbarung zum Servicelevel) von 99,99 Prozent erreicht.

Um Hochverfügbarkeit zu konfigurieren, platzieren Sie die beteiligten virtuellen SQL Server-Computer verteilt auf die verfügbaren Verfügbarkeitszonen der Region. Es fallen zusätzliche Gebühren für Übertragungen zwischen Netzwerken zwischen Verfügbarkeitszonen an. Weitere Informationen finden Sie unter Verfügbarkeitszonen.

Netzwerklatenz bei Hybridlösungen

Stellen Sie die HADR-Lösung mit der Vorgabe bereit, dass möglicherweise Zeiträume mit hoher Netzwerklatenz zwischen dem lokalen Netzwerk und Azure auftreten. Wenn Sie Replikate in Azure bereitstellen, verwenden Sie als Synchronisierungsmodus asynchrone Commits anstelle von synchronen Commits. Beim Bereitstellen von Datenbankspiegelungsservern sollten Sie sowohl lokal als auch in Azure den Modus für hohe Leistung anstelle des Modus für hohe Sicherheit verwenden.

Weitere Informationen zu hilfreichen Cluster- und HADR-Einstellungen für die Cloudumgebung finden Sie in den bewährten Methoden für die HADR-Konfiguration.

Georeplikationssupport

Die Georeplikation von Azure-Datenträgern unterstützt nicht das Speichern von Datendatei und Protokolldatei derselben Datenbank auf unterschiedlichen Datenträgern. Der GRS repliziert Änderungen auf jedem Datenträger unabhängig und asynchron. Durch dieses Vorgehen wird die Schreibreihenfolge auf einem einzelnen Datenträgers in der georeplizierten Kopie sichergestellt, aber nicht die von georeplizierten Kopien mehrerer Datenträger. Wenn Sie eine Datenbank zum Speichern von Datendatei und Protokolldatei auf separaten Datenträgern konfigurieren, enthalten die nach einem Notfall wiederhergestellten Datenträger möglicherweise eine aktuellere Kopie der Datendatei als die Protokolldatei. Dies kann das Write-Ahead-Protokoll in SQL Server und die ACID-Eigenschaften von Transaktionen beschädigen.

Wenn Sie Georeplikation für das Speicherkonto nicht deaktivieren können, speichern Sie alle Daten- und Protokolldateien für eine Datenbank auf dem gleichen Datenträger. Wenn Sie aufgrund der Datenbankgröße mehrere Datenträger verwenden müssen, stellen Sie eine der weiter oben aufgeführten Notfallwiederherstellungslösungen bereit, um Datenredundanz zu gewährleisten.

Nächste Schritte

Entscheiden Sie, ob eine Verfügbarkeitsgruppe oder eine Failoverclusterinstanz die beste Geschäftskontinuitätslösung für Ihr Unternehmen ist. Machen Sie sich dann mit den bewährten Methoden zum Konfigurieren Ihrer Umgebung für Hochverfügbarkeit und Notfallwiederherstellung vertraut.