Microsoft sagt der Datenbankspiegelung adé Hochverfügbarkeit mit SQL Server 2014 wird teuer

Autor / Redakteur: Filipe Pereira Martins und Anna Kobylinska / Ulrike Ostler

Seit Microsoft die Datenbankspiegelung zum alten Eisen erklärt hat, suchen Anwender von der Datenbank „SQL Server“ nach Alternativen in Sachen Hochverfügbarkeit. Mit „SQL Server 2012“ vorgestellt und im Release 2014 ausgebaut, soll die Technologie „AlwaysOn“ mit Hochverfügbarkeitsgruppen die Alternative sein. Das birgt Einschränkungen.

Firmen zum Thema

In SQL Server 2014 sind alle Hochverfügbarkeits-Features, für die Microsoft eine Zukunft vorsieht, den Anwendern der Edition Enterprise vorbehalten.
In SQL Server 2014 sind alle Hochverfügbarkeits-Features, für die Microsoft eine Zukunft vorsieht, den Anwendern der Edition Enterprise vorbehalten.
(Bild: Microsoft)

Technische Lösungen rund um die Hochverfügbarkeit (High Availability oder kurz: HA) sollen die Erreichbarkeit von Diensten maximieren, die Auswirkungen eines Hardwareschadens mildern, die Ausfälle der Netzinfrastruktur auffangen. Dank HA-Features lassen sich nicht nur die Ausfallzeiten aus der Sicht des Endbenutzers minimieren, sondern auch der Verlust transaktionaler Daten praktisch ausschließen.

SQL Server 2012 konnte bisher je nach Edition mit bis zu drei Features für die Hochverfügbarkeit aufwarten: der synchronen Datenbankspiegelung, den AlwaysOn Failover-Cluster-Instanzen und den AlwaysOn-Verfügbarkeitsgruppen (die letzte Option ist nur in der „Edition Enterprise“ zu haben). Bei der synchronen Datenbankspiegelung in SQL Server handelte es sich um eine Hochverfügbarkeitslösung; bei der asynchronen Datenbankspiegelung (nur in der Enterprise-Edition verfügbar) um eine Notfalllösung zur Datenwiderherstellung.

Das Wenn und Aber für die Datenbankspiegelung

Bei der Datenbankspiegelung besteht die Umgebung aus zwei Instanzen mit lokalem Speicher, einem Prinzipal-Server mit der Prinzipal-Datenbank und einem Spiegel-Server mit der Spiegel-Datenbank. Im Hochsicherheitsmodus kann ein automatisches Failover stattfinden. Dies erfordert allerdings einen dritten Server, den so genannten Zeugen.

Bei der synchronen Datenbankspiegelung übergibt der Prinzipal-Server den Commit einer jeden Transaktion unmittelbar an den Spiegel-Server und erst nach Erhalt einer Bestätigung meldet er den Vorgang als abgeschlossen. Der Sekundär-Server kann die Aufgaben des Primär-Server sofort übernehmen.

Informationen von außerhalb der betreffenden Datenbank wie Jobs, Joints und Transaktionen, die mehrere Datenbanken gleichzeitig betreffen, gehen entweder verloren oder lassen sich nicht fehlerfrei übernehmen. Diese Lösung ist zudem langsam.

Asynchrone Datenbankspiegelung erfolgt mit einer erheblichen Zeitverzögerung. Daher eignet sich dieses Vorgehen zwar nicht für ein automatisches Failover, dafür aber für die Datensicherung und die Notfallwiederherstellung durch einen Administrator.

Unterstützung gekündigt

Microsoft möchte die Datenbankspiegelung in künftigen Versionen nicht mehr unterstützen. Anwender von SQL Server sind daher gut beraten, dieses Feature bereits heute nicht mehr zu nutzen und schon erst recht keine neuen Anwendungen dafür zu entwickeln.

Abbildung 1: Installation von SQL Server 2014 CTP2
Abbildung 1: Installation von SQL Server 2014 CTP2
(Bild: McKinley Denali Inc.)

Als Ersatz hat Microsoft die AlwaysOn-Hochverfügbarkeitsgruppen vorgesehen. Der einzige Schönheitsfehler: Jede Server-Instanz in einer Hochverfügbarkeitsgruppe benötigt die Enterprise-Edition von SQL Server. Alleine die Lizenzgebühren für die minimale Ausstattung der kleinsten Ausbaustufe einer Hochverfügbarkeitsgruppe kommen da schon bei einer Laufzeit von drei Jahren auf einen stolzen Betrag von über einhunderttausend Euro.

Features wie die Datenbankreplikation und der Logversand können die Sicherheit der Daten verbessern und die Datenwiederherstellung im Notfall vereinfachen, aber sie sind keine HA-Features im wahrsten Sinne.

Datenbankreplikation

Die Datenbankreplikation kann die Verfügbarkeit der betreffenden Datenbank verbessern und die Notfallwiederherstellung (Disaster Recovery) der Daten ermöglichen. Die in SQL Server basiert auf dem Veröffentlichen/Abonnieren-Modell. Ein primärer Server, der so genannte „Verleger“, kann seine Daten oder eine Untermenge der Daten an mindestens einen sekundären Server, den „Abonnenten“, weitergeben.

Abbildung 2: Das Management Studio zählt auch in Microsoft SQL Server 2014 CTP2 zu den verfügbaren Tools; dieser Screenshot zeigt den Verbindungsaufbau mit SQL Server 2014.
Abbildung 2: Das Management Studio zählt auch in Microsoft SQL Server 2014 CTP2 zu den verfügbaren Tools; dieser Screenshot zeigt den Verbindungsaufbau mit SQL Server 2014.
(Bild: McKinley Denali Inc.)
Der Datenbankreplikation bietet dem Anwender eine hohe Flexibilität, doch diese wird mit einer beachtlichen Komplexität erkauft, die leicht zu Fehlern führt. SQL Server kann beispielsweise eine Untermenge einer Datenbank replizieren und verschiedene Server-Instanzen mit separaten Indizes versehen.

Dadurch können Sie die Replika mit der Erstellung detaillierter Berichterstattung beauftragen und den Produktionsserver entlasten. Das Potenzial für Fehler sollte man nicht unterschätzen.

Log-Versand

Beim Log-Versand (verfügbar in den Editionen Enterprise, BI, Standard und Web von SQL Server) schreibt der primäre Datenbankserver eine Sicherheitskopie der Transaktions-Logs auf ein gemeinsam genutztes Volume. Andere Datenbankserver können dann von einem entfernten Standort auf eben dieses Volume zugreifen, die Logs abholen und daraus die betreffende Datenbank bei sich lokal wiederherstellen, um sie für Lesezugriffe bereitzustellen.

Der Log-Versand bietet eine robuste Methode der Datenbankwiederherstellung im Notfall, ist jedoch weit davon entfernt, als eine HA-Lösung einsetzbar zu sein. SQL Server kann nicht gleichzeitig eine Datenbank wiederherstellen und Abfragen beantworten; vor der Wiederherstellung müssen alle laufenden Abfragen zwangsweise beendet werden.

AlwaysOn Failover Cluster-Instanzen

Die Server-Symbole von SQL Server 2014
Die Server-Symbole von SQL Server 2014
(Bild: Microsoft)
In einem Datencenter lässt sich die Hochverfügbarkeit von SQL Server mit AlwaysOn Failover Cluster-Instanzen umsetzen. Diese Technologie nutzt „Windows Server Failover Clustering“ (kurz: WSFC) und bietet unterstützen ein automatisches Failover.

Lokale Hochverfügbarkeit erfordert redundante Server-Instanzen, die so genannten FCIs (Failover-Cluster-Instanzen), und gemeinsam genutzten SAN-Speicher. Bei einer FCI handelt es sich um eine einzelne Instanz von SQL Server, die verteilt über mehrere WSFC-Knoten (gerne auch über mehrere Subnetze hinweg) installiert wurde.

Im Netzwerk erscheint eine solche Installation als ein einzelner Computer. Microsofts SQL Server Management Studio verbindet sich mit dem Cluster wie mit einem gewöhnlichen Host. Fällt der aktive Knoten aus, erfolgt ein vollautomatisches Failover: Der zweite Knoten übernimmt die Aufgaben des ersten Knoten.

Nicht abgeschlossene Transaktionen gehen verloren

Für die Endanwender hat sich nichts geändert; denn FCI gibt sich nach außen hin immer noch wie der gleiche Host aus. Lediglich nicht abgeschlossene Transaktionen gehen beim automatischen Failover verloren. Bereits abgeschlossene Transaktionen sind von dem Vorfall nicht betroffen.

AlwaysOn Failover Cluster-Instanzen haben dennoch einen Nachteil: Sie schützen die Umgebung vor dem Ausfall eines einzelnen Servers in dem Cluster, nicht jedoch vor dem Ausfall des SAN-Speichers. Alle Knoten greifen nämlich auf denselben gemeinsam genutzten SAN-Speicher zu.

Ein Defekt dieser Hardware könnte im Extremfall zum Verlust aller Daten führen. Um das Risiko zu minimieren, empfiehlt sich der Einsatz von SAN-Replikation. Beim Ausfall des primären SAN-Speichers besteht in diesem Fall die Möglichkeit, die SAN-Replika dem Cluster manuell zur Verfügung zu stellen. Allerdings ist diese Lösung mit erheblichen Zusatzkosten verbunden und erfordert normalerweise die Beteiligung eines SAN-Administrators.

Die Editionen Standard und BI von SQL Server 2012 und 2014 unterstützen jeweils genau zwei Knoten. Die Enterprise-Version geht diesbezüglich bis an die Grenzen des verwendeten Betriebssystems.

Ein Beispiel

Abbildung 3: Ein Beispielszenario für Hochverfügbarkeit beim Einsatz von SQLServer 2014
Abbildung 3: Ein Beispielszenario für Hochverfügbarkeit beim Einsatz von SQLServer 2014
(Bild: McKinley Denali Inc.)
Hier ein Beispielszenario für die Hochverfügbarkeit von SQL Server in einem Datencenter(siehe Abbildung 2): FCI INST1 unterstützt automatisches Failover zwischen Node1 und Node2; beim Hardwarefehler des gemeinsam genutzten Speichers der beiden Nodes ist dank synchroner Übergabe von T-Logs ein manuelles Failover auf die auf einem einzigen Node laufende INST2. Beim katastrophalen Ausfall der gesamten Infrastruktur des Datencenters A ist dank der asynchronen T-Log-Übergabe an INST3 im Datencenter B die manuelle Notfallwiederherstellung gesichert.

AlwaysOn-Hochverfügbarkeit in SQL Server

AlwaysOn-Hochverfügbarkeitsgruppen bauen auf WSFC auf und gewährleisten Redundanz auf Datenbankebene. Unter Verwendung von AlwaysOn-HA-Gruppen steht der Sekundär-Server für Lesezugriffe zur Verfügung. Anders als im Falle der Datenbankreplikation müssen Indizes und Schemata auf allen Instanzen identisch sein.

Failover zwischen synchronen Replika in einer AlwaysOn-Hochverfügbarkeitsgruppe erfolgt völlig automatisch. Asynchrone Replika eignen sich zwar nur für manuelles Failover, doch dafür haben sie einen anderen Vorteil: Sie können sich in verschiedenen Datencentern befinden und auf völlig verschiedener Hardware laufen.

Der Nutzen

Microsoft führte die AlwaysOn-Hochverfügbarkeitsgruppen in SQL Server 2012 ein und hat diese Technologie in der Version 2014 ausgebaut. SQL Server 2014 bietet nun Unterstützung für insgesamt acht statt der zuvor unterstützten vier Sekundär-Replikas. In Multi-Site-Umgebungen bleiben diese erstmals auch dann lesbar, wenn sich die Verbindung zum primären Server nicht herstellen lässt (was der Fall bei SQL Server 2012 ist).

Den größten Nutzen ziehen daraus diejenigen Unternehmen, die ihre Hochverfügbarkeitsgruppen in verschiedenen geografisch verteilten Datencentern aufstellen. Erstmals in SQL Server 2014 besteht zudem die Möglichkeit, die Belastung der Hochverfügbarkeitsgruppe mit einem Lastverteiler zu verwalten.

Synchrone sekundäre Replika in Azure

Abbildung 4: Microsoft Azure als eine AlwaysOn-Sekundär-Replika eines Datencenter-Deployment von SQL Server 2014
Abbildung 4: Microsoft Azure als eine AlwaysOn-Sekundär-Replika eines Datencenter-Deployment von SQL Server 2014
(Bild: McKinley Denali Inc./Microoft)
SQL Server 2014 integriert sich nahtlos mit „Windows Azure“. Benutzer von SQL Server in der Microsoft-Wolke können SQL Server 2014 als eine synchrone sekundäre Replika für die Azure-Dienste nutzen. Auch das umgekehrte Szenario ist vorgesehen: Wer SQL Server im Datencenter einsetzt, kein seine Datenbanken auf Windows Azure asynchron replizieren, um im Notfall ein manuelles Failover veranlassen zu können.

Die Preiserhöhung

Der größte Nachteil dieser Technologie ist nicht technischer sondern lizenztechnischer Natur. AlwaysOn-Hochverfügbarkeitsgruppen erfordern die Edition Enterprise sowohl in SQL Server 2012 als auch 2014. Im Gegensatz dazu war die Datenbankspiegelung, die voraussichtlich in der nächsten Version nach SQL Server 2014 entfällt, auch in der Edition Standard verfügbar.

Microsoft hätte der Standard-Edition von SQL Server 2014 zumindest die geringste Ausbaustufe von AlwaysOn-Hochverfügbarkeitsgruppen spendieren können. Der Wegfall von Hochverfügbarkeitstechnologien in der Edition Standard bedeutet also praktisch eine schleichende Preiserhöhung (siehe: Microsoft License Advisor).

Beim Einsatz von SQL Server 2014 in einem Datencenter sind AlwaysOn Failover Cluster-Instanzen von SQL Server mit SAN-Speicher für den einen oder anderen Anwender sicherlich eine akzeptable Option.

Die Autoren:

Filipe Pereira Martins und Anna Kobylinska arbeiten für die McKinley Denali Inc. (USA).

Artikelfiles und Artikellinks

(ID:42657485)