von Redaktion IT-A…
Lesezeit
3 Minuten
Hochverfügbare SQL-Cluster in der Google-Cloud
SQL-Server-Failovercluster-Instanzen stellen die Hochverfügbarkeit von SQL-Servern sicher. Um der Anforderung an gemeinsam nutzbaren Speicher in der Google-Cloud gerecht zu werden, empfiehlt der Cloudprovider Storage Spaces Direct. Die Krux dabei: Die Einrichtung erfordert, dass sich alle VMs und der Speicher im selben Rechenzentrum befinden. Hochverfügbarkeit gewährleistet Google jedoch nur bei standortübergreifenden Konfigurationen. Wie sich dieses Dilemma lösen lässt, verrät unsere Schritt-für-Schritt-Anleitung.
SQL-Server müssen laufen. Die Erstellung und Konfiguration von AlwaysOn-Failovercluster-Instanzen (FCI) ist die gängigste Methode, um diese hochverfügbar zu halten. Voraussetzung für ihre Einrichtung ist ein gemeinsam nutzbarer zentraler Speicher. In lokalen Infrastrukturen kommen hierfür üblicherweise SAN- oder NAS-Lösungen zum Einsatz.
Nicht hingegen in der Google Cloud: Hier wird Shared Storage über das in Windows Server 2016 eingeführte Microsoft Storage Spaces Direct (S2D) realisiert. Dieses dient dazu, Speicher zu einem softwarebasierten virtuellen SAN zusammenschließen und über mehrere Cluster-Knoten hinweg als Pool bereitzustellen. Dieser Ansatz hat allerdings seinen Preis. Nicht nur, da sich die Funktion erst ab der Edition SQL Server 2016 nutzen lässt. Vielmehr wirft sie auch Probleme in Sachen Hochverfügbarkeit auf.
Zwickmühle Storage Spaces Direct
Grundsätzlich ist die Einrichtung von SQL-Server-FCIs in der Google-Cloud kein Hexenwerk. Die zu diesem Zweck im Internet bereitgestellte Anleitung ist klar und lässt sich leicht umsetzen. Ist das Ziel jedoch eine Verfügbarkeit von 99,99 Prozent, greifen die vom Provider ausgesprochenen Konfigurationsempfehlungen nur bedingt. Der Grund ist, dass der gemeinsame nutzbare Speicher mit Storage Spaces Direct angelegt wird. Gemäß den Microsoft-Vorgaben erfordert dies, dass sich alle virtuellen Maschinen und der Speicher im gleichen Rechenzentrum befinden.
Genau hier liegt allerdings der Hase im Pfeffer begraben. Denn fällt das Datacenter einmal komplett aus, stehen auch die SQL-Server still und der Zugriff auf VMs und Daten ist vorübergehend nicht mehr möglich. Aus diesem Grund schreibt Google die Platzierung von VMs in mehreren Zonen der Google-Cloud vor. Nur wenn diese Bedingung erfüllt ist, gilt auch die in den SLAs festgelegte Hochverfügbarkeitszusage. Im Rückkehrschluss bedeutet dies, dass die Garantie bei S2D-Konfigurationen in der Regel bei nur 99,95 Prozent liegt.
Alternative Failovercluster-Software
Einen Ausweg aus dem Dilemma bietet Failovercluster-Software. Mit dem Zusatz "SANless" versehene Lösungen kommen wie der Name schon andeutet ohne ein SAN aus. Mit ihrem Einsatz lassen sich vollständig speicherunabhängig arbeitende, auf einer Shared-Nothing-Architektur beruhende Server-Cluster mit gemeinsam nutzbarem Speicher und automatischer Ausfallsicherung (Failover) erstellen. Dies schafft die Basis für eine hohe Anwendungsverfügbarkeit.
Ein weiterer Pluspunkt ist, dass sich die erstellten Cluster übergreifend sowohl im LAN als auch im WAN in privaten, öffentlichen sowie hybriden Cloudumgebungen betreiben lassen und zudem erweiterbar sind. Somit können Unternehmen eine einzige auf die Anforderungen der meisten Anwendungen abgestimmte und damit universal einsetzbare Hochverfügbarkeitslösung bereitstellen.
SQL-Server-FCI konfigurieren
Die Einrichtung einer SQL-Server-FCI in der Google Cloud setzt zunächst die Erstellung eines Failoverclusters mit mindestens zwei Servern voraus. Google empfiehlt hierfür folgende Schritte:
Software von Drittanbietern schließt Lücke
Mit dem Einsatz von Failovercluster-Software lassen sich vorgenannte S2D-Einschränkungen aufheben. Ein Großteil der Programme kombiniert die Replikation von Daten in Echtzeit mit einer kontinuierlichen Anwendungsüberwachung und bietet darüber hinaus die Möglichkeit, Wiederherstellungsrichtlinien für Failover und Failback festzulegen. Diese Verbindung sorgt dafür, dass geschäftskritische Anwendungen jederzeit umfassend geschützt sind – inklusive jener, die das Always-On-Failovercluster-Feature der SQL-Server-Standard und der Enterprise-Edition nutzen.
Einige der am Markt angebotenen robusteren Failovercluster-Lösungen warten überdies mit vielerlei konfigurationserleichternden Funktionen auf; bedienen lassen sie sich in der Regel über eine intuitiv gehaltene grafische Benutzeroberfläche. Außerdem kann zwischen synchroner und asynchroner Replikation gewählt und per WAN-Optimierung die Leistung maximiert werden. Des Weiteren zeichnen sie sich dadurch aus, dass sich bei planmäßigen Wartungsarbeiten der Wechsel vom aktiven Primär- auf ein Standby-System manuell auslösen lässt und regelmäßige Sicherungen ohne Anwendungsunterbrechung möglich sind.
Optionen für gemeinsam nutzbaren Speicher
Zu den in der Google-Cloud für diesen Zweck optional nutzbaren Lösungen gehört die SIOS Datakeeper Cluster Edition des auf Hochverfügbarkeits- und Disaster-Recovery-Anwendungen spezialisierten Unternehmens SIOS Technology. Nach Abschluss der sieben oben kurz angerissenen für das Aufsetzen des Basis-Clusters notwendigen Schritte lassen sich mit dem Programm Cluster-Komponenten erstellt werden, die eine 99,99-prozentige Verfügbarkeit der SQL-Server-FCIs gewährleisten.
Die Replikation auf Blockebene stellt sicher, dass der lokal angeschlossene Speicher auch über Rechenzentren hinweg auf jeder SQL-Instanz synchron läuft. Die Integration in das Windows-Server-Failoverclustering erfolgt über eine eigene Speicherklassenressource. Das Volume präsentiert sich dem Cluster wie eine physische Festplatte, steuert jedoch anstelle von SCSI-Reservierungen in welche Richtung Daten gespiegelt werden. Daraus resultierend schreibt stets nur der aktive Server auf die Festplatte, das passive System empfängt alle Änderungen entweder synchron oder asynchron.
Fazit
Letztlich fallen durch den Einsatz der Failovercluster-Software die in der Google-Anleitung angegebenen Limitierungen weg. Denn infolge der Einrichtung eines weder auf Storage Spaces Direct basierenden noch ein SAN benötigenden Failoverclusters lässt sich jede beliebige SQL-Server-Edition verwenden. Ferner hält jede Festplatte im Cluster eine vollständige Replik der Daten auf Blockebene vor. Dadurch lässt sich die gewünschte 99,99-prozentige Verfügbarkeit erreichen.
ln/Dave Bermingham, Senior Technical Evangelist bei SIOS Technology
Nicht hingegen in der Google Cloud: Hier wird Shared Storage über das in Windows Server 2016 eingeführte Microsoft Storage Spaces Direct (S2D) realisiert. Dieses dient dazu, Speicher zu einem softwarebasierten virtuellen SAN zusammenschließen und über mehrere Cluster-Knoten hinweg als Pool bereitzustellen. Dieser Ansatz hat allerdings seinen Preis. Nicht nur, da sich die Funktion erst ab der Edition SQL Server 2016 nutzen lässt. Vielmehr wirft sie auch Probleme in Sachen Hochverfügbarkeit auf.
Zwickmühle Storage Spaces Direct
Grundsätzlich ist die Einrichtung von SQL-Server-FCIs in der Google-Cloud kein Hexenwerk. Die zu diesem Zweck im Internet bereitgestellte Anleitung ist klar und lässt sich leicht umsetzen. Ist das Ziel jedoch eine Verfügbarkeit von 99,99 Prozent, greifen die vom Provider ausgesprochenen Konfigurationsempfehlungen nur bedingt. Der Grund ist, dass der gemeinsame nutzbare Speicher mit Storage Spaces Direct angelegt wird. Gemäß den Microsoft-Vorgaben erfordert dies, dass sich alle virtuellen Maschinen und der Speicher im gleichen Rechenzentrum befinden.
Genau hier liegt allerdings der Hase im Pfeffer begraben. Denn fällt das Datacenter einmal komplett aus, stehen auch die SQL-Server still und der Zugriff auf VMs und Daten ist vorübergehend nicht mehr möglich. Aus diesem Grund schreibt Google die Platzierung von VMs in mehreren Zonen der Google-Cloud vor. Nur wenn diese Bedingung erfüllt ist, gilt auch die in den SLAs festgelegte Hochverfügbarkeitszusage. Im Rückkehrschluss bedeutet dies, dass die Garantie bei S2D-Konfigurationen in der Regel bei nur 99,95 Prozent liegt.
Alternative Failovercluster-Software
Einen Ausweg aus dem Dilemma bietet Failovercluster-Software. Mit dem Zusatz "SANless" versehene Lösungen kommen wie der Name schon andeutet ohne ein SAN aus. Mit ihrem Einsatz lassen sich vollständig speicherunabhängig arbeitende, auf einer Shared-Nothing-Architektur beruhende Server-Cluster mit gemeinsam nutzbarem Speicher und automatischer Ausfallsicherung (Failover) erstellen. Dies schafft die Basis für eine hohe Anwendungsverfügbarkeit.
Ein weiterer Pluspunkt ist, dass sich die erstellten Cluster übergreifend sowohl im LAN als auch im WAN in privaten, öffentlichen sowie hybriden Cloudumgebungen betreiben lassen und zudem erweiterbar sind. Somit können Unternehmen eine einzige auf die Anforderungen der meisten Anwendungen abgestimmte und damit universal einsetzbare Hochverfügbarkeitslösung bereitstellen.
SQL-Server-FCI konfigurieren
Die Einrichtung einer SQL-Server-FCI in der Google Cloud setzt zunächst die Erstellung eines Failoverclusters mit mindestens zwei Servern voraus. Google empfiehlt hierfür folgende Schritte:
- VPC-Netzwerk einrichten
- Windows-Domaincontroller erstellen und konfigurieren
- Cluster-VMs und Datenlaufwerke erstellen
- Netzwerk der Cluster-VMs konfigurieren
- File Share Witness (Dateifreigabezeugen) erzeugen
- Internes Loadbalancing-Modul erstellen
- Windows-Failovercluster erzeugen
Software von Drittanbietern schließt Lücke
Mit dem Einsatz von Failovercluster-Software lassen sich vorgenannte S2D-Einschränkungen aufheben. Ein Großteil der Programme kombiniert die Replikation von Daten in Echtzeit mit einer kontinuierlichen Anwendungsüberwachung und bietet darüber hinaus die Möglichkeit, Wiederherstellungsrichtlinien für Failover und Failback festzulegen. Diese Verbindung sorgt dafür, dass geschäftskritische Anwendungen jederzeit umfassend geschützt sind – inklusive jener, die das Always-On-Failovercluster-Feature der SQL-Server-Standard und der Enterprise-Edition nutzen.
Einige der am Markt angebotenen robusteren Failovercluster-Lösungen warten überdies mit vielerlei konfigurationserleichternden Funktionen auf; bedienen lassen sie sich in der Regel über eine intuitiv gehaltene grafische Benutzeroberfläche. Außerdem kann zwischen synchroner und asynchroner Replikation gewählt und per WAN-Optimierung die Leistung maximiert werden. Des Weiteren zeichnen sie sich dadurch aus, dass sich bei planmäßigen Wartungsarbeiten der Wechsel vom aktiven Primär- auf ein Standby-System manuell auslösen lässt und regelmäßige Sicherungen ohne Anwendungsunterbrechung möglich sind.
Optionen für gemeinsam nutzbaren Speicher
Zu den in der Google-Cloud für diesen Zweck optional nutzbaren Lösungen gehört die SIOS Datakeeper Cluster Edition des auf Hochverfügbarkeits- und Disaster-Recovery-Anwendungen spezialisierten Unternehmens SIOS Technology. Nach Abschluss der sieben oben kurz angerissenen für das Aufsetzen des Basis-Clusters notwendigen Schritte lassen sich mit dem Programm Cluster-Komponenten erstellt werden, die eine 99,99-prozentige Verfügbarkeit der SQL-Server-FCIs gewährleisten.
Die Replikation auf Blockebene stellt sicher, dass der lokal angeschlossene Speicher auch über Rechenzentren hinweg auf jeder SQL-Instanz synchron läuft. Die Integration in das Windows-Server-Failoverclustering erfolgt über eine eigene Speicherklassenressource. Das Volume präsentiert sich dem Cluster wie eine physische Festplatte, steuert jedoch anstelle von SCSI-Reservierungen in welche Richtung Daten gespiegelt werden. Daraus resultierend schreibt stets nur der aktive Server auf die Festplatte, das passive System empfängt alle Änderungen entweder synchron oder asynchron.
Sobald die Failovercluster-Software aufgespielt, deren Einrichtung abgeschlossen und sämtliche Eingaben gemacht sind, wird wie in der Google-Dokumentation beschrieben, mit der Konfiguration der Hochverfügbarkeit für den SQL-Server mit FCI fortgefahren. Hierfür ist die Neuinstallation der SQL-Server auf den VMs erforderlich, die sich auf die zuvor mit der Failovercluster-Lösung erstellte und mehrere Rechenzentren überspannende Speicherkonfiguration stützt. Sobald dies erledigt ist, erfolgt die Konfiguration der Cluster für den Health Check und ein Test des Failover-Vorgangs.
Letztlich fallen durch den Einsatz der Failovercluster-Software die in der Google-Anleitung angegebenen Limitierungen weg. Denn infolge der Einrichtung eines weder auf Storage Spaces Direct basierenden noch ein SAN benötigenden Failoverclusters lässt sich jede beliebige SQL-Server-Edition verwenden. Ferner hält jede Festplatte im Cluster eine vollständige Replik der Daten auf Blockebene vor. Dadurch lässt sich die gewünschte 99,99-prozentige Verfügbarkeit erreichen.
ln/Dave Bermingham, Senior Technical Evangelist bei SIOS Technology
