Teilen über


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

Gilt für:SQL Server auf Azure-VM

Dieser Artikel vergleicht und kontrastiert die reinen Azure- und hybriden Business Continuity-Lösungen, die Sie für Hochverfügbarkeit und Disaster Recovery (HADR) mit Ihrem SQL Server auf Azure Virtual Machines (VMs) verwenden können

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.

Hinweis

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

Übersicht

SQL Server auf Azure-VMs unterstützen den folgenden Lösungstyp:

  • Nur Azure: Das gesamte HADR-System in Azure ausgeführt.
  • Hybrid: 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. Es liegt an Ihnen, sicherzustellen, dass Ihre Datenbanksysteme über HADR-Funktionen verfügen, die Ihre Geschäftlichen Anforderungen an das Wiederherstellungszeitziel (RTO), das Recovery Point Objective (RPO) und die Vereinbarung zum Service Level (SLA) erfüllen.

Die integrierten Hochverfügbarkeitsmechanismen von Azure, wie z. B. Service Healing für Cloud-Dienste und Ausfallwiederherstellungserkennung für virtuelle Maschinen, garantieren nicht, dass Sie die SLA, RTO oder RPO einhalten 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.

Funktionen der Geschäftskontinuität

In der folgenden Tabelle sind sowohl Nur-Azure- als auch hybride SQL Server-Features aufgeführt, die Sie für hohe Verfügbarkeit (HA), Notfallwiederherstellung (DR) oder beides (HA/DR) verwenden können:

Diese SQL Server-Features werden sowohl für die Geschäftskontinuität in einer Nur-Azure-Konfiguration als auch in einer Hybridkonfiguration unterstützt. Einige der Optionen eignen sich ideal für hohe Verfügbarkeit und Notfallwiederherstellung (HA/DR), hohe Verfügbarkeit (HA), während andere für die Notfallwiederherstellung (DR) verwendet werden.

SQL Server-Funktionen Option für Hochverfügbarkeit/Notfallwiederherstellung Details
Always On-Verfügbarkeitsgruppen Hochverfügbarkeit und Notfallwiederherstellung Bietet Schutz auf Datenbankebene, erhöht die Hochverfügbarkeit und Notfallwiederherstellung durch Hinzufügen von Replikaten in verschiedenen Verfügbarkeitszonen und/oder Regionen.
Always On-Failoverclusterinstanzen (FCIs) Hochverfügbarkeit Verwendet gemeinsam genutzten Speicher, um Schutz auf Instanzebene bereitzustellen. Erhöhen Sie den Schutz sowohl auf datenbank- als auch auf Instanzebene, indem Sie sie mit Verfügbarkeitsgruppen kombinieren.
Protokollversand Notfallwiederherstellung Der Schutz auf Datenbankebene für die Notfallwiederherstellung umfasst das Senden von Transaktionsprotokollsicherungen von einem primären Server und das Wiederherstellen dieser Sicherungen an einen sekundären Server. Eine Azure-Dateifreigabe wird benötigt.
SQL Server-Sicherung und -Wiederherstellung mit dem Microsoft Azure Blob Storage Notfallwiederherstellung Sicherungen von Produktionsdatenbanken, die in Azure Blob Storage für den Notfallwiederherstellungsschutz gespeichert sind.
Azure Site Recovery Notfallwiederherstellung Eine Notfallwiederherstellungslösung, die VMs von einem primären Standort auf einen sekundären Standort repliziert.

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. Obwohl die Technologien identisch sind, gibt es möglicherweise einige Unterschiede bei der Einrichtung in Azure oder in einem Hybriddesign.

Verfügbarkeitsgruppen(HADR)

Der Schutz von SQL Server auf Azure-VMs auf Datenbankebene kann mithilfe von Verfügbarkeitsgruppen als Hochverfügbarkeit und Notfallwiederherstellung-Lösung (HADR) erfolgen. Replikate, die auf Azure-VMs in derselben Region ausgeführt werden, bieten Hochverfügbarkeit. Eine Domänencontroller-VM ist erforderlich, da Windows-Failoverclustering eine Active Directory-Domäne benötigt.

Abbildung, die den Domänencontroller über dem WSFC-Cluster zeigt, der aus dem primären Replikat, dem sekundären Replikat und dem Dateifreigabenzeugen besteht.

Informationen zu den ersten Schritten finden Sie im Tutorial zu Verfügbarkeitsgruppen.

Für höhere Redundanz, Verfügbarkeit und Notfallwiederherstellungsschutz können die Azure-VMs in unterschiedlichen Verfügbarkeitszonen bereitgestellt werden, wie in der Übersicht über Verfügbarkeitsgruppen beschrieben. Die Ausweitung von Verfügbarkeitsreplikaten auf mehrere Rechenzentren in Azure-VMs sorgt für eine weitere Notfallwiederherstellungsabdeckung. Eine 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.

In einer hybriden Konfiguration werden einige Verfügbarkeitsreplikate in Azure-VMs ausgeführt, während andere Replikate für eine standortübergreifende Notfallwiederherstellung vor Ort sind. Der Produktionsstandort kann sich entweder vor Ort oder in einem Azure-Rechenzentrum befinden.

Diagramm der Verfügbarkeitsgruppen, die von der lokalen Bereitstellung in Azure konfiguriert sind.

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.

Failoverclusterinstanzen (HA)

SQL Server auf Azure VMs unterstützen Failoverclusterinstanzen (FCI) und diese Lösung bietet hohe Verfügbarkeit auf Instanzebene. Für zusätzlichen Schutz können Sie Redundanz sowohl auf der Datenbank und der Instanzebene erstellen, indem Sie Verfügbarkeitsgruppen über Failoverclusterinstanzen erstellen. Das FCI-Feature erfordert freigegebenen Speicher. Es gibt fünf Lösungen, die mit SQL Server auf Azure-VMs funktionieren:

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

Protokollversand (DR)

Eine weitere Lösung für die Notfallwiederherstellung in Azure ist der Protokollversand, bei dem automatisch Transaktionsprotokollsicherungen von einer primären Datenbank auf einem Primärserver an eine oder mehrere sekundäre Datenbanken auf einem separaten Sekundärserver gesendet werden. Die Konfiguration des Protokollversands verwendet eine Azure File Share zum Speichern der Transaktionsprotokollsicherungen.

Diagramm des Protokollversands in Azure.

Wenn Sie den Protokollversand in einer Hybridumgebung konfigurieren müssen, befindet sich ein Server auf einer Azure-VM und der andere lokal für die standortübergreifende Notfallwiederherstellung. 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.

Back up and Restore (DR)

Das Sichern Ihrer Produktionsdatenbanken ist für die Notfallwiederherstellung erforderlich. In Azure können Sie Datenbanken direkt im Blobspeicher in einem anderen Rechenzentrum für die Notfallwiederherstellung sichern.

Abbildung, die eine Datenbank in einer Region zeigt, die Daten in Blob Storage in einer anderen Region sichert.

Die lokalen Produktionsdatenbanken können in einer Hybrid-Lösung direkt in Azure Blob Storage für Notfallwiederherstellung gesichert werden.

Diagramm der Sicherung und Wiederherstellung.

Weitere Informationen finden Sie unter Sicherung und Wiederherstellung für SQL Server in Azure Virtual Machines.

Replikation mit von Azure Site Recovery (DR)

Azure Site Recovery kann sowohl in Azure als auch in einer Hybridkonfiguration als Notfallwiederherstellungslösung verwendet werden.

Innerhalb von Azure wird die produktive SQL Server-Instanz in einem Azure-Rechenzentrum direkt auf Azure Storage in einem anderen Azure-Rechenzentrum für die Notfallwiederherstellung repliziert.

Abbildung, die eine Datenbank in einem Azure-Rechenzentrum zeigt, das die Azure Site Recovery-Replikation für die Notfallwiederherstellung in einem anderen Rechenzentrum nutzt.

Für Hybrid-Umgebungen wird die lokale SQL Server-Produktionsinstanz 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. Wählen Sie unter Einstellungen die Option Konfigurieren und dann unter SQL Server-Lizenz die Option HA/DR. Wählen Sie dann Übernehmen, um Ihre 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.