VERTRIEB: 1-800-867-1380

Hochverfügbarkeit und Notfallwiederherstellung für SQL Server auf virtuellen Azure-Computern

Letzte Aktualisierung: Januar 2015

Virtuelle Computer (VMs) in Microsoft Azure mit SQL Server bieten die Möglichkeit, die Kosten einer Datenbanklösung zu reduzieren, die mit Hochverfügbarkeit und Notfallwiederherstellung (High Availability and Disaster Recovery, HADR) ausgestattet ist. Die meisten SQL Server-HADR-Lösungen werden auf virtuellen Computern in Azure- unterstützt – als reine Azure--Lösungen sowie auch als Hybridlösungen. Bei einer reinen Azure--Lösung wird das gesamte HADR-System in Azure- ausgeführt. Bei einer Hybridlösung wird ein Teil der Lösung in Azure- und der andere Teil lokal in Ihrer Organisation ausgeführt. Die Flexibilität der Azure--Umgebung ermöglicht je nach Budget und HADR-Anforderungen Ihrer SQL Server-Datenbanksysteme deren vollständige oder teilweise Verlegung in Azure-.

Es liegt ganz bei Ihnen sicherzustellen, dass Ihr Datenbanksystem über die erforderlichen HADR-Funktionen verfügt, die von der Vereinbarung zum Servicelevel (SLA) gefordert werden. Obwohl Azure- bereits mit Hochverfügbarkeitsmechanismen ausgestattet ist, z. B. der Selbstreparatur von Cloud Services und der Wiederherstellungserkennung der virtuellen Computer, ist dies noch keine Gewähr dafür, dass Sie die gewünschte Vereinbarung zum Servicelevel erfüllen können. Genau genommen sichern diese Mechanismen die Hochverfügbarkeit der virtuellen Computer, nicht aber die Hochverfügbarkeit der auf den virtuellen Computern ausgeführten SQL Server. Schließlich kann die SQL Server-Instanz auch ausfallen, obwohl der virtuelle Computer online und betriebsbereit ist. Darüber hinaus kommt es bei virtuellen Computern trotz der von Azure- bereitgestellten Hochverfügbarkeitsmechanismen zu Ausfallzeiten, z. B. durch die Wiederherstellung nach Software- oder Hardwarefehlern oder Betriebssystemupgrades.

Möglicherweise ist auch der geografisch redundante Speicher (GRS) in Azure-, der durch ein Feature namens "Georeplikation" implementiert ist, nicht die geeignete Notfallwiederherstellungslösung für Ihre Datenbanken. Da die Georeplikation Daten asynchron sendet, können bei einem Notfall jüngste Aktualisierungen verloren gehen. Weitere Informationen zu den Einschränkungen von Georeplikation finden Sie im Abschnitt Geografische Replikation von Daten- und Protokolldateien auf separaten Datenträgern wird nicht unterstützt.

Die folgenden SQL Server HADR-Technologien werden unter anderem in Azure- unterstützt:

Die einzelnen Technologien können kombiniert werden, um eine SQL Server-Lösung zu implementieren, die sowohl über Hochverfügbarkeits- als auch Notfallwiederherstellungsfunktionen verfügt. Je nach eingesetzter Technologie kann bei einer Hybridbereitstellung ein VPN-Tunnel für das virtuelle Netzwerk in Azure- erforderlich sein. In den folgenden Abschnitten werden einige Beispiele für Bereitstellungsarchitekturen vorgestellt.

Hochverfügbarkeitslösungen für SQL Server-Datenbanken lassen sich in Azure- durch zwei Technologien implementieren: AlwaysOn-Verfügbarkeitsgruppen oder Datenbankspiegelung.

 

Technologie Beispielarchitekturen

AlwaysOn-Verfügbarkeitsgruppen

Alle Verfügbarkeitsreplikate werden auf VMs in Azure- ausgeführt, um Hochverfügbarkeit innerhalb derselben Region zu gewährleisten. Zusätzlich zu den virtuellen SQL Server-Computern müssen Sie einen Domänencontroller konfigurieren, da für Windows Server Failover Clustering (WSFC) eine Active Directory-Domäne erforderlich ist.

AlwaysOn-Verfügbarkeitsgruppen in Windows Azure

Weitere Informationen finden Sie unter Lernprogramm: AlwaysOn-Verfügbarkeitsgruppen in Azure (GUI).

Datenbankspiegelung

Prinzipal-, Spiegel- und Zeugenserver werden alle im selben Azure--Datencenter ausgeführt, um Hochverfügbarkeit zu gewährleisten. Sie können über einen Domänencontroller bereitgestellt werden.

Datenbankspiegelung in Windows Azure

Die gleiche Datenbank-Spiegelungskonfiguration kann auch ohne einen Domänencontroller unter Verwendung von Serverzertifikaten bereitgestellt werden.

Datenbankspiegelung mit Zertifikat in Windows Azure

Weitere Informationen finden Sie unter Lernprogramm: Datenbankspiegelung für hohe Verfügbarkeit in Azure.

Eine Notfallwiederherstellungslösung für Ihre SQL Server-Datenbanken in Azure- kann auf AlwaysOn-Verfügbarkeitsgruppen, Datenbankspiegelung oder einer Sicherungs-/Wiederherstellungslösung mit Speicher-Blobs basieren.

 

Technologie Beispielarchitekturen

AlwaysOn-Verfügbarkeitsgruppen

Verfügbarkeitsreplikate, die in mehreren Datencentern auf virtuellen Computern in Azure- ausgeführt werden, um die Notfallwiederherstellung zu gewährleisten. Diese regionsübergreifende Lösung schützt vor dem Ausfall ganzer Standorte.

SQLHADR

Innerhalb einer Region sollte sich alle Replikate im selben Cloud-Dienst und im selben VNet befinden. Da jede Region ein gesondertes VNet besitzt, erfordern diese Lösungen VNet-zu-VNet-Verbindungen. Weitere Informationen finden Sie unter Konfigurieren von VNet-zu-VNet-Verbindungen.

Datenbankspiegelung

Prinzipal- und Spiegelserver werden zur Notfallwiederherstellung in verschiedenen Datencentern ausgeführt. Die Bereitstellung muss über Serverzertifikate erfolgen, weil sich eine Active Directory-Domäne nicht auf mehrere Datencenter erstrecken kann.

Datenbankspiegelung (DR) in Windows Azure

Weitere Informationen finden Sie unter Lernprogramm: Datenbankspiegelung für die Notfallwiederherstellung in Azure.

Sicherung und Wiederherstellung mit dem Azure--Blob-Speicherdienst

Produktionsdatenbanken werden zur Notfallwiederherstellung direkt im Blob-Speicher eines anderen Datencenters gesichert.

Sicherung auf Blog in Windows Azure

Weitere Informationen finden Sie unter Sicherung und Wiederherstellung für SQL Server auf virtuellen Azure-Computern.

Zur Notfallwiederherstellung Ihrer SQL Server-Datenbanken in einer hybriden IT-Umgebung stehen Ihnen die folgenden Optionen zur Verfügung: AlwaysOn-Verfügbarkeitsgruppen, Datenbankspiegelung, Protokollversand und Sicherung/Wiederherstellung im Azure--Blob-Speicher.

 

Technologie Beispielarchitekturen

AlwaysOn-Verfügbarkeitsgruppen

Zur standortübergreifenden Notfallwiederherstellung werden einige Verfügbarkeitsreplikate auf VMs in Azure- und andere lokal ausgeführt. Der Produktionsstandort kann sich lokal oder in einem Azure--Datencenter befinden.

AlwaysOn-Verfügbarkeitsgruppen in Hybrid-IT

Da sich alle Verfügbarkeitsreplikate im selben WSFC-Cluster befinden müssen, muss sich der WSFC-Cluster über beide Netzwerke (Multisubnetz-WSFC-Cluster) erstrecken. Diese Konfiguration erfordert eine VPN-Verbindung zwischen Azure- und dem lokalen Netzwerk.

Zur erfolgreichen Notfallwiederherstellung der Datenbanken sollten Sie auch einen Replikatdomänencontroller am Notfallwiederherstellungs-Standort installieren.

Datenbankspiegelung

  • Zur standortübergreifenden Notfallwiederherstellung mithilfe von Serverzertifikaten wird ein Partner auf einem virtuellen Computer in Azure- und der andere Partner lokal ausgeführt. Die Partner müssen sich nicht in derselben Active Directory-Domäne befinden, und es ist keine VPN-Verbindung erforderlich.

    Datenbankspiegelung in Hybrid-IT

    Weitere Informationen finden Sie unter Lernprogramm: Datenbankspiegelung für die Notfallwiederherstellung in einer hybriden IT-Umgebung.

  • Zur standortübergreifenden Notfallwiederherstellung wird ein Partner auf einem virtuellen Computer in Azure- und der andere lokal in derselben Active Directory-Domäne ausgeführt. Eine VPN-Verbindung zwischen dem virtuellen Netzwerk in Azure- und dem lokalen Netzwerk ist erforderlich.

    Zur erfolgreichen Notfallwiederherstellung der Datenbanken sollten Sie auch einen Replikatdomänencontroller am Notfallwiederherstellungs-Standort installieren.

Protokollversand

Zur standortübergreifenden Notfallwiederherstellung wird ein Server auf einem virtuellen Computer in Azure- und der andere lokal ausgeführt. Der Protokollversand hängt von Windows-Datenfreigaben ab, weshalb eine VPN-Verbindung zwischen dem virtuellen Netzwerk in Azure- und dem lokalen Netzwerk erforderlich ist.

Protokollversand in Hybrid-IT

Zur erfolgreichen Notfallwiederherstellung der Datenbanken sollten Sie auch einen Replikatdomänencontroller am Notfallwiederherstellungs-Standort installieren.

Weitere Informationen finden Sie unter Lernprogramm: Protokollversand für die Notfallwiederherstellung in einer hybriden IT-Umgebung.

Sicherung und Wiederherstellung mit dem Azure-Blob-Speicherdienst

Lokale Produktionsdatenbanken werden zur Notfallwiederherstellung direkt im Azure--Blob-Speicher gesichert.

Sicherung im Blog in Hybrid-IT

Weitere Informationen finden Sie unter Sicherung und Wiederherstellung für SQL Server auf virtuellen Azure-Computern.

In Azure- unterliegt die Nutzung von virtuellen Computern, Speicher und Netzwerken anderen Gesetzmäßigkeiten als in einer lokalen, nicht virtualisierten IT-Infrastruktur. Die erfolgreiche Implementierung einer SQL Server-HADR-Lösung in Azure- setzt voraus, dass Sie die Unterschiede kennen und die Lösung entsprechend entwerfen.

Verfügbarkeitsgruppen in Azure- ermöglichen Ihnen die Platzierung der Hochverfügbarkeitsknoten in gesonderten Fehlerdomänen (Fault Domains, FDs) und Aktualisierungsdomänen (Update Domains, UDs). Damit VMs in Azure- derselben Verfügbarkeitsgruppe angehören können, müssen sie im selben Cloud-Dienst bereitgestellt werden. Nur Knoten im selben Cloud-Dienst können derselben Verfügbarkeitsgruppe angehören. Weitere Informationen finden Sie unter Verwalten der Verfügbarkeit virtueller Computer.

Nicht RFC-konforme DHCP-Dienste in Azure- können dazu führen, dass die Erstellung bestimmter WSFC-Clusterkonfigurationen fehlschlägt, da dem Clusternetzwerknamen eine doppelte IP-Adresse (dieselbe IP-Adresse wie einem der Clusterknoten) zugewiesen wird. Dieses Problem tritt beim Implementieren von AlwaysOn-Verfügbarkeitsgruppen auf – ein Vorgang, der von der WSFC-Funktion abhängt.

Stellen Sie sich ein Szenario vor, indem ein 2-Knoten-Cluster erstellt und online geschaltet wird:

  1. Nachdem der Cluster online geschaltet wurde, fordert KNOTEN1 eine dynamisch zugewiesene IP-Adresse für den Clusternetzwerknamen an.

  2. Vom DHCP-Dienst wird keine andere IP-Adresse als die eigene IP-Adresse von KNOTEN1 zugewiesen, da der DHCP-Dienst erkennt, dass die Anforderung von KNOTEN1 selbst kommt.

  3. Windows erkennt, dass eine doppelte Adresse sowohl KNOTEN1 als auch dem Clusternetzwerknamen zugewiesen ist, und die Standardclustergruppe kann nicht online geschaltet werden.

  4. Die Standardclustergruppe wechselt zu KNOTEN2, der die IP-Adresse von KNOTEN1 als Cluster-IP-Adresse ansieht und die Standardclustergruppe online schaltet.

  5. Wenn KNOTEN2 versucht, eine Verbindung mit KNOTEN1 herzustellen, verlassen die für KNOTEN1 bestimmten Pakete niemals KNOTEN2, weil die IP-Adresse von KNOTEN1 in sich selbst aufgelöst wird. KNOTEN2 kann keine Verbindung mit KNOTEN1 herstellen, verliert daher das Quorum fährt den Cluster herunter.

  6. Inzwischen kann KNOTEN1 zwar Pakete an KNOTEN2 senden, KNOTEN2 antwortet jedoch nicht. KNOTEN1 verliert das Quorum und fährt den Cluster herunter.

Dieses Szenario können Sie vermeiden, indem Sie dem Clusternetzwerknamen eine nicht verwendete statische IP-Adresse, z. B. eine verbindungslokale IP-Adresse wie 169.254.1.1 zuweisen, um den Clusternetzwerknamen online zu schalten. Wie Sie diesen Prozess vereinfachen, erfahren Sie unter Konfigurieren eines Windows-Failoverclusters in Azure für AlwaysOn-Verfügbarkeitsgruppen.

Die folgenden Lernprogramme für AlwaysOn-Verfügbarkeitsgruppen zeigen, wie eine Verfügbarkeitsgruppe in verschiedenen Szenarien konfiguriert wird.

Verfügbarkeitsgruppenlistener werden auf virtuellen Computern in Azure unter Windows Server 2008 R2, Windows Server 2012 und Windows Server 2012 R2 unterstützt. Diese Unterstützung basiert auf der Verwendung von Endpunkten mit Lastenausgleich und aktiviertem Direct Server Return (DSR) auf den VMs in Azure-, die als Verfügbarkeitsgruppenknoten eingerichtet sind. Sie müssen bestimmte Konfigurationsschritte für die Listener ausführen, die für beide Arten von Clientanwendungen geeignet sind: die in Azure- und die lokal ausgeführten Anwendungen.

Clients müssen eine Verbindung zum Listener auf einem Computer herstellen, der sich nicht im selben Clouddienst wie der AlwaysOn-Verfügbarkeitsgruppen-Knoten befindet. Wenn die Verfügbarkeitsgruppe mehrere Azure--Subnetze (z. B. eine Bereitstellung, die Azure-Regionen überschreitet) umfasst, muss die Client-Verbindungszeichenfolge "MultisubnetFailover = True" einschließen. Dies führt zu parallelen Verbindungsversuchen mit den Replikaten in den unterschiedlichen Subnetzen. Anleitungen zum Erstellen eines Listeners finden Sie unter Lernprogramm: Listenerkonfiguration für AlwaysOn-Verfügbarkeitsgruppen.

Es kann weiterhin eine separate Verbindung mit jedem Verfügbarkeitsreplikat hergestellt werden, und zwar über eine direkte Verbindung mit der Serverinstanz. Da AlwaysOn-Verfügbarkeitsgruppen abwärtskompatibel mit Datenbankspiegelungsclients sind, können Sie darüber hinaus eine Verbindung mit Verfügbarkeitsreplikaten wie Datenbank-Spiegelungspartnern herstellen, solange die Replikate ähnlich wie bei der Datenbankspiegelung konfiguriert sind:

  • Ein primäres Replikat und ein sekundäres Replikat

  • Das sekundäre Replikat ist als nicht lesbar konfiguriert (die Option Lesbare sekundäre Rolle ist auf Nein festgelegt)

Im Folgenden ein Beispiel für eine Clientverbindungszeichenfolge, die für diese mit der Datenbankspiegelungskonfiguration unter Verwendung von ADO.NET oder SQL Server Native Client vergleichbare Konfiguration geeignet ist:

Data Source=ReplicaServer1;Failover Partner=ReplicaServer2;Initial Catalog=AvailabilityDatabase;

Weitere Informationen zur Clientkonnektivität finden Sie unter:

Sie sollten Ihre HADR-Lösung unter der Annahme bereitstellen, dass es Zeiträume mit hoher Netzwerklatenz zwischen Ihrem lokalen Netzwerk und Azure- geben kann. Bei der Bereitstellung von Replikaten in Azure- sollten Sie asynchronen Commits im standortübergreifenden Synchronisierungsmodus den Vorzug vor synchronen Commits geben. Wenn Sie Datenbankspiegelungsserver sowohl lokal als auch in Azure- bereitstellen, verwenden Sie anstelle des Modus für hohe Sicherheit den Modus für hohe Leistung.

Bei der geografischen Replikation auf Azure--Datenträgern ist es nicht möglich, die Daten- und Protokolldatei derselben Datenbank auf separaten Datenträgern zu speichern. GRS repliziert Änderungen unabhängig und asynchron auf jeden Datenträger. Durch diesen Mechanismus wird sichergestellt, dass die Schreibreihenfolge eines einzelnen Datenträgers in der geografisch replizierten Kopie erhalten bleibt, nicht aber die Schreibreihenfolge mehrerer geografisch replizierter Kopien auf mehreren Datenträgern. Wenn Sie eine Datenbank so konfigurieren, dass die Datendatei und die Protokolldatei auf separaten Datenträgern gespeichert werden, enthalten die nach einem Notfall wiederhergestellten Datenträger u. U. eine Kopie der Datendatei, die aktueller ist als die der Protokolldatei. Dadurch werden das Write-Ahead-Protokoll in SQL Server und die ACID-Eigenschaften von Transaktionen unterbrochen. Wenn es nicht möglich ist, die geografische Replikation für das Speicherkonto zu deaktivieren, sollten Sie alle Daten- und Protokolldateien einer bestimmten Datenbank auf demselben Datenträger speichern. Wenn Sie aufgrund der Datenbankgröße mehr als einen Datenträger verwenden müssen, entscheiden Sie sich für eine der oben beschriebenen Notfallwiederherstellungslösungen, um Datenredundanz zu gewährleisten.

Siehe auch

Fanden Sie dies hilfreich?
(1500 verbleibende Zeichen)
Vielen Dank für Ihr Feedback.
Anzeigen:
© 2015 Microsoft