it innovations.de

Microsoft SQL Server - Hochverfügbarkeitslösungen (HA)

IT-Projekte / Consulting / Beratung / Support

Microsoft SQL Server wird bei vielen OLTP Anwendungen, ERP Programmen und DWH als Datenbankserver eingesetzt. Ausfälle dieser Systeme sind unternehmenskritisch und verursachen Ausfallkosten.

Der Microsoft SQL Server bietet mit Backup und Restore, Log Shipping, Replikation, Database Mirroring, Failover Clustering und AlwaysOn verschiedene Hochverfügbarkeitsalternativen (HA).

Beratung zu Hochverfügbarkeitslösungen (HA) von Microsoft SQL Server, Einführung, Consulting, Projekt-Durchführung mit anschließendem Support führen wir gerne bei Ihnen durch. Fragen Sie an und lassen sich beraten.


Microsoft SQL Server - Hochverfügbarkeit

Microsoft SQL Server Hochverfügbarkeit - Backup und Restore

Diese Technik ist der Eckstein der Absicherung eines SQL Servers. Es ist nicht nur die älteste verfügbare Technik sondern die letzte Instanz falls alle anderen Techniken scheitern. In periodischen Abständen werden die Änderungsdaten von abgeschlossenen Transaktionen in eine Datei geschrieben (Transaktionsprotokollsicherung). Basierend auf einer Datenbanksicherung kann dann der Zustand einer Datenbank wiederhergestellt werden. Ein besonderer Aspekt ist, dass der Zustand einer Datenbank zu einem bestimmten Zeitpunkt wiederhergestellt wird. Damit ist es ein Verfahren um Benutzerfehler zu kompensieren. Als alleiniges Verfahren zur Erreichung von Hochverfügbarkeit ist Backup- / Restore nicht geeignet:

  • Vollständiges Wiederherstellen einer Datenbank ist nur bedingt automatisiert.
  • Die Dauer der Wiederherstellung hängt von unterschiedlichen Faktoren ab (Größe der Datenbank, Alter der letzten Vollsicherung, Menge der anstehenden Änderungen, Umfang der vorbereiteten Maßnahmen) und sollte nicht unterschätzt werden
  • Der maximale Datenverlust hängt von der Frequenz und Dauer der Transaktionsprotokollsicherungen ab. Falls das System zumindest administrativ verfügbar ist kann es sein dass man alle abgeschlossenen Transaktionen retten kann (RPO=0)

Bezogen auf die SLA-Parameter kann man sagen dass RPO im Bereich von Minuten liegt und RTO im Bereich von Stunden (vorausgesetzt bei einem Systemausfall steht eine Ersatzhardware bereit).

Microsoft SQL Server Hochverfügbarkeit - Log Shipping

Log Shipping basiert auf Backup und Restore und ist eine Automatisierung dieses Prozesses: Der produktive SQL Server sichert regelmäßig sein Transaktionsprotokoll aus einer Datenbank in eine Datei. Auf einem anderen Server wird permanent wiederhergestellt. Diese Technik ist schon lange für den SQL Server verfügbar und sehr solide. Der zentrale Vorteil gegenüber Backup/Restore ist die Reduzierung des RTO-Parameters: Im Störungsfall ist man schneller wieder Online, da die Datenbank auf dem Standby-System nahe am Produktionssystem ist. Ein weiterer Vorteil ist die Tatsache dass Log Shipping zu mehreren Zielsystemen möglich ist und ein automatisches Failover unterstützt wird. Nachteile von Log Shipping:

  • RPO von 0 nicht möglich. In der Regel im Bereich von Minuten
  • Dateisystem ist Zwischenpuffer für die Transaktionen (Daten werden nicht direkt zwischen den SQL Servern ausgetauscht). Damit spielt die I/O-Rate des Dateisystems für diese Ablage eine Rolle
  • Lesender Zugriff auf die Standbydatenbank nur sehr eingeschränkt möglich (nicht während Widerherstellungsphasen). Dafür z.B. für Beladung eines Data Warehouse uninteressant.
  • Bei Umschaltung auf das Standbysystem muss Navition auf den neuen Datenbankserver umgestellt werden.
  • Systemdatenbanken können nicht gespiegelt werden.

Microsoft SQL Server Hochverfügbarkeit - Replikation

Replikation, insbesondere die sog. Transaktionale Replikation, ist eine Technik zur Verteilung von Tabelleninhalten. also primär nicht als Failover-Lösung konzipiert kann aber dafür genutzt werden. Bei der Replikation wählt man einzelne zu replizierende Tabellen aus. Ein Vorteil gegenüber dem Log Shipping ist dass die Zieldatenbank für Lesezugriff verfügbar ist. Die Nachteile die Transaktionale Replikation oft für Hochverfügbarkeitsszenarien ungeeignet machen:

  • RPO von 0 nicht möglich. In der Regel im Bereich von Minuten
  • Sogenannte „Distribution“-Datenbank ist Zwischenpuffer für die Transaktionen (Daten werden nicht direkt zwischen den SQL Servern ausgetauscht).
  • Kein automatisches Failover
  • Bei Umschaltung auf das Standbysystem muss Navition auf den neuen Datenbankserver umgestellt werden.
  • Hohe Systemkomplexität und administrativer Aufwand falls als Hochverfügbarkeitslösung genutzt. Systemdatenbanken können nicht gespiegelt werden.

Microsoft SQL Server Hochverfügbarkeit - Database Mirroring (DBM)

DBM ist eine Technik die beim SQL Server seit der Version 2005 verfügbar ist. Im Unterschied zu den Techniken „Log Shipping“ und „Transaktionale Replikation“ werden hier die Daten abgeschlossener Transaktionen direkt zwischen zwei Datenbankserver ausgetauscht, wodurch eine höhere Performance erzielt wird. DBM unterstützt zwei Modi:

  • Synchron: das Commit von Transaktionen wird so lange zurückgestellt bis eine Wiederherstellung auf dem Standbysystem (Spiegel) garantiert werden kann. Insofern ist in diesem Modus ein RPO von 0 möglich
  • Asynchron: hier steht der Durchsatz im Vordergrund. Transaktionen auf dem Primärsystem werden nicht durch das Standbysystem zurückgehalten. Allerdings ist so ein RPO von 0 nicht mehr garantiert (bei niedrigem Systemdurchsatz kann der Versatz auch im Bereich von Stunden liegen)

Stimmt der Durchsatz des Systems so kann bei DBM ein RPO von 0 sowie eine RTO von deutlich unter einer Minute erreicht werden. Weitere Vorteile sind:

  • Automatisches Failover
  • Spiegel kann mit Hilfe von Database Snapshots lesbar gemacht werden
  • Hot Standby. RTO in der Regel im Bereich von Sekunden

Nachteilige Aspekte von Database Mirroring:

  • Standby-Server hat separaten Namen. Keine automatische Umstellung von Navision (automatischen Client-Redirect gibt es nur bei Verwendung spezieller Treiber, die von Navision nicht unterstützt werden)
  • Systemdatenbanken können nicht gespiegelt werden - Nur ein Spiegel möglich

Letztendlich ist bei DBM der Durchsatz des Systems entscheidend um RPO bei 0 und RTO nahe 0 zu halten. Einflussfaktoren hier sind die Storageausstattung beider Knoten sowie die Netzwerkverbindung. Der Standbyserver sollte mindestens genauso ausgestattet sein wie der Primäre Server. Weiterhin wird für das automatische Failover ein sog. Witness benötigt. Das ist ein dritter SQL Server welcher das System überwacht und ggf. einen Nodeswitch veranlasst. Der Witness kann auch mit der kostenlosen Version SQL Server Express eingerichtet werden. Ein weiterer Punkt der beachtet werden muss ist dass der Ausfall des Standbyservers auch das primäre System beeinflusst. Ist der Standbyserver / Spiegel zu lange Offline dann kann das Transaktionsprotokoll am primären Server überlaufen, was dazu führt dass keine Änderungstransaktionen akzeptiert werden. In diesem Fall müsste der Spiegel getrennt werden, was ohne Skripting nicht automatisch geht. Anschließend muss der Spiegel neu aufgesetzt werden. Unter Umständen verliert man so für Stunden die Hochverfügbarkeit. Die administrative Komplexität von Mirroring kann man mit „mittel“ einstufen.

Hinweis: Database Mirroring ist 2016 abgekündigt, funktioniert aber noch bis SQL Server 2014. Mit SQL Server 2016 ist Mirroring nicht mehr möglich.

Microsoft SQL Server Hochverfügbarkeit - Failover Clustering

Diese Technik unterscheidet sich insofern von den vorhergehenden als das zwischen dem primären Datenbanksystem und dem Standby-System keine Transaktionsdaten ausgetauscht werden. Vereinfacht dargestellt handelt es sich bei Failover-Clustering um zwei (oder mehr) separate SQL Server die sich die gleichen Datenbankdateien teilen. Dies bedingt dass nur ein SQL Server Online ist. Fällt der aktive SQL Server aus so wird der zweite gestartet („Warm Standby“) und übernimmt die Datenbankdateien. Von Seiten der Clients (eg. Navision) wird ein virtueller Servernamen gesehen. D.h. dass im Falle eines Failovers sämtliche Clients ohne Änderung des SQL Server Netzwerknamens weiterarbeiten können. Nachdem Failover Clustering mit einem Shared Storage arbeitet ist ein gespiegeltes Storage unabdingbar. Ohne dieses ist das Storage Single Point of Failure.

Vorteile von Failover Clustering:

  • RPO in der Regel um eine Minute („Warm Standby“). Standby-SQL Server muss gestartet werden, Mounten der Datenbanken samt REDO/UNDO sowie Erstellung der tempdb
  • Einfache Administration. „Fühlt“ sich an wie ein Standalone-Server

Nachteile von Failover Clustering:

  • Gegenüber Mirroring und AlwaysOn komplexe Systemumgebung: Storageanbindung über iSCSI oder FibreChannel notwendig. Gespiegeltes Storage
  • Cluster schützt nicht vor korrupten Datenbanken. Sollte bei einem gespiegelten Storage keine Rolle spielen.

Microsoft SQL Server Hochverfügbarkeit - AlwaysOn

Bei AllwaysOn handelt es sich um eine Weiterentwicklung von Database Mirroring mit folgenden Neuerungen:

  • Mehr als ein Spiegel („Secondaries“)
  • Spiegel können lesbar gemacht werden („Readable Secondarys“).
  • Virtueller Netzwerkname gegenüber Clients wie bei Failover Clustering
  • Offload von Backups auf Secondaries möglich
  • Mehrere Datenbanken (keine Systemdatenbanken) können zu sogenannten „Availabilty Groups“ zusammengefasst werden. Im Falle einer Störung fallen diese gemeinsam zum Standbysystem
  • Leseoperationen (z.B. Reporting) kann automatisch auf Readable Secondaries umgeleitet werden.

Ansonsten gilt bei AlwaysOn was schon zu Database Mirroring gesagt wurde:

  • RPO von 0 bei synchroner Spiegelung möglich
  • RTO im Bereich von Sekunden
  • Spiegeln der Systemdatenbanken nicht möglich.

AlwaysOn ist ab SQL Server 2012 verfügbar.


Hochverfügbarkeitslösung bei angegliederten BI-Systemen mit SQL Server

Sofern ein BI System / DWH an die primäre SQL Server Datenbank der ERP oder OLTP Anwendung angegliedert ist, sind bei der Planung einer Hochverfügbarkeitslösung weitere Faktoren zu berücksichtigen.


Definition Hochverfügbarkeit

Da der Begriff „Hochverfügbarkeit“ (englisch HA = High Availabilty) oftmals recht weit gefasst ist - hier eine Definition.
Zunächst versteht man unter Hochverfügbarkeit ein Systemdesign / Implementierung welches für einen gegebenen Zeitabschnitt den störungsfreien Betrieb gewährleistet.
Oftmals wird bei einer Hochverfügbarkeit davon Ausgegangen, dass der störungsfreie Betrieb ohne manuellen Eingriff gewährleistet ist. In diesem Kontext werden aber auch Lösungen betrachtet bei denen ein gewisser manueller Eingriff notwendig sein kann. Damit sollen bestimmte kostengünstige Verfahren nicht von vornherein ausgeschlossen werden.

„Verfügbarkeit“ wird in Form von Service Level Agreements definiert. Bei Datenbankservern sind in diesem Rahmen folgende Parameter entscheidend:

  • Recovery Point Objective (RPO)
    Damit wird der störungsbedingte maximal akzeptable Datenverlust definiert. Also „wie viele Daten darf ich verlieren“
  • Recovery Time Objective (RTO)
    Hiermit wird die maximal akzeptable Zeit definiert nach der ein System infolge eines störungsbedingten Ausfalls wieder bereit steht

Ausgehend von diesen Parametern gibt es eine standardisierte Definition von Verfügbarkeitsklassen:

Akzeptierte Downtime (RTO) Akzeptierter Datenverlust (RPO)
> 99.99% (max. 52 min.) 5 min oder weniger
99.9% - 99.99% (52 min. - 8.7 h) 5 min bis 8,7 Stunden
< 99.9% (Stunden bis Tage) Stunden bis Tage

Basis für ein Systemdesign sind also entsprechende Vorgaben für beide Parameter.
Betriebsstörungen können unterschiedliche Ursachen haben und sind nicht immer auf Ausfall von Hard- / Software zurückzuführen. Hier eine Übersicht:

  • Störungen: dazu gehören alle technischen Ursachen für einen Systemausfall wie Hard- und Softwarefehler, Stromausfall etc.
  • Benutzerfehler: Hierzu zählen Benutzerinteraktionen die zu Systemstörungen führen da deren Kompensation zu einem Ausfall führt. Beispiel dafür wäre z.B. die versehentliche Löschung von Aufträgen durch einen Endanwender welche durch Systemwiederherstellung (Restore) rückgängig gemacht werden muss.
  • Online-Administration:  Zu dieser Kategorie zählen sämtliche geplanten Wartungsarbeiten am System wie das Einspielen von neuen Softwareversionen, Servicepacks und Updates.
  • Ressourcenkonfiguration: Damit sind geplante Umkonfigurationen von CPU, Hauptspeicher und Storage gemeint. Zum Teil sind diese Operationen mit Änderungen der Hardware verbunden. Es kann sich aber auch durch Änderungen von Systemparametern des SQL Servers handeln. Die meisten dieser Parameter können beim SQL Server Online ohne Unterbrechung um konfiguriert werden. Bei manchen ist ein Neustart des SQL Servers notwendig.

Bezogen auf einen Datenbankserver können folgende ungeplante Störungen auftreten:

  • Ausfall des Systems (Hard- / Software)
  • Ungewollte Datenänderungen dir Rückgängig gemacht werden müssen
  • Beschädigung der Datenbank
  • Blockierungen aufgrund des Mehrbenutzerbetriebs / Ressourcenengpässen. Das System fällt nicht vollständig aus sondern ist in bestimmten Bereichen nicht vollständig nutzbar

SQL Server bietet unterschiedliche Techniken zur Adressierung möglicher Störungsursachen. Allerdings kann nur eine Kombination verfügbarer Techniken alle Störungsursachen adressieren.

Entscheidend ist es, die möglichen Lösungen und Wahlmöglichkeiten zu kennen bevor man eine Auswahl trifft. Für jede bereitgestellte Technik gibt es:

  • Eine Lösungsarchitektur
  • Hochverfügbarkeitseigenschaften
  • Einschränkungen
  • Kosten