SQL Server im Dauereinsatz
Datenbanken ohne Unterbrechung

SQL-Server 2008: mehr Funktionen zur Ausfallsicherheit

Im Sommer dieses Jahres will Microsoft seine neue Version des SQL Servers liefern. Gegenüber dessen Vorgänger SQL Server 2005 stellt die Version 2008 einige wesentliche Neuerungen bereit. Dazu gehören auch erweiterte Funktionen der Hochverfügbarkeit. Dessen Ziel wiederum liegt in der permanenten Aufrechterhaltung der IT-Dienste. Im englischen Sprachgebrauch wird dabei auch von der Business Continuity gesprochen.

Der SQL Server bietet hierzu ein ganzes Bündel an Techniken und Möglichkeit. Nicht alle davon sind neu und manche bestanden auch schon in den Vorgängerversionen. Hier sollen sie exemplarischen gegenübergestellt werden. Jede dieser genannten Techniken hat einen Vor- aber auch Nachteile und eignet sich meist auch für spezielle Zwecke.

Der SQL Server stellt eine tragende Säule in der Microsoft Infrastruktur dar (Klick aufs bild = Originalgröße Microsoft-Folie).

Datenbankspiegelung und Transaktionsreplikation

Die vielleicht umfangreichste Variante zur Absicherung des SQL Servers ist die Spiegelung der kompletten Datenbank. Hierbei werden die Daten vom primären und aktiven SQL-Server zeitnahe auf einen zweiten Standby-Server repliziert. Damit existieren immer zwei Kopien der Datenbank. Dieser Datenbankspiegel wird für jede Datenbank separat eingerichtet. Fällt der primäre Server aus, so springt der bis dato inaktive Standby-Server ein. Diese Umschaltung kann entweder automatisch oder manuell, und gesteuert durch den Administrator, erfolgen. In der Version 2005 des SQL Server musste der übernehmende Server beim Failover neu gestartet werden. Diese bedingte einen kurzen Ausfall. Diesen Mangel hat man nun bei der Version 2008 beseitigt.

Transaktionen repliziert
Bei der Transaktionsreplikation tauschen zwei Server ihre Änderungen aus. Dies kann wechselseitig in beiden Richtungen passieren. Jeder der beteiligten Server veröffentlicht hierzu Daten, die der Partnerserver abonniert. Umgesetzt wird die Transaktionsreplikation wird durch zwei SQL Server Snapshot-Agenten, dem Protokoll-Lese-Agenten und dem Verteilungs-Agenten.

Auf der Quellseite bereitet der Agent die Daten auf und erzeugt die Snapshot-Dateien. Zum Inhalt dieser Snapshot-Dateien gehören sowohl die Informationen zum Datenbankschema sowie die Daten selbst. Eingeleitet wird die Transaktionsreplikation mit einem vollständigen Snapshot. Anschließend werden nur noch die Daten- und Schemaänderungen an den Abonnenten übertragen. Dort angekommen überträgt der Abonnent die Änderungen in der gleichen Abfolge in die eigene Datenbank. Daraus entsteht eine Kopie des Originals.

Bei der Peer to Peer Replikation werden identische Kopien der Daten erzeugt (Klick aufs Bild eigt ganzes Fenster).

Da der Austausch wie erwähnt in beiden Richtungen passieren kann, eignet sich die Transaktionsreplikation auch für verteilte Transaktionen. Das Prinzip lässt sich aber für die unidirektionale Datenspiegelung heranziehen.

Protokollversand und Failover-Clustering

Beim Protokollversand (Log shipping) werden nur die Transaktionsprotokolle vom primären SLQ Server auf den zweiten Server übertragen. Der Protokollversand unterstützt aber auch die parallele Übertragung von einer Quelle auf mehrere Ziele. Es wird in drei Stufen abgewickelt.

Zuerst erfolgt die Sicherung des Transaktionsprotokolls auf dem Quellserver. Diese Sicherung wird dann auf den oder die Zielserver transferiert. Dort angekommen übertragen die Zielserver die Transaktionen in ihre lokalen Datenbanken. Wenn notwendig kann der gesamte Vorgang durch einen unabhängigen Überwachungsserver verfolgt werden. Dieser prüft, ob die vorgegeben Abläufe eingehalten werden und generiert andernfalls Warnmeldungen.

Der SQL Server unterstützt unterschiedliche Replikationsmodelle (Klick aufs Bild = größere Ansicht).

Durch die 1:n-Replikation der Inhalte eignet sich der Protokollversand vor allem auch für die Verteilung von Daten auf mehrere Server. Beim Ausfall des primären Rechners muss der Administrator die Umschaltung eines der Sicherungsserver, der nun zum primären Rechner werden soll, in jedem Fall manuell vornehmen

Ganze Server-Cluster garantieren Hochverfügbarkeit
Den geringsten Ausfall und damit die höchste Verfügbarkeit erreicht man mit einem Failover-Cluster. Hierbei handelt es sich um vollständig redundante Server-Systeme mit gemeinsamen Datenträgern. Alle Knotenrechner zusammen bilden eine Ressourcengruppe. Diese tritt nach außen als ein geclusterter Dienst in Erscheinung. Folglich wird der gesamte Failover-Cluster als ein einzelner SQL Server im Netzwerk dargestellt. Dahinter verbergen sich aber mehrere Knoten des Clusters.

Im Fehlerfall, also bei Ausfall eines dieser Knoten übernehmen die anderen den Dienst weiter. Dies kann, sofern die Applikation mitspielt, völlig unbemerkt vom Benutzer erfolgen. Damit federn Failover-Cluster Ausfälle einer Server-Hardware aber auch des SQL Server ab, denn der Benutzer wird bei korrekter Funktionsweise davon nichts bemerken.

Die Techniken des Failover-Cluster lassen sich ferner mit anderen Varianten, wie etwa der Datenbankspiegelung, dem Protokollversand oder der Replikation kombinieren. Microsoft hat zudem im Windows Server 2008 die Clusterfunktionen erweitert und unterstützt nun auch geographisch verteilte Cluster.