Standby-Lösungen für die Datenbank
Mit Netz und doppeltem Boden
In den vergangenen Jahren sind die Ansprüche an die Verfügbarkeit von datenbankbasierenden Anwendungen in Unternehmen stark gewachsen. Um diesen Anforderungen gerecht zu werden, bietet sich der Einsatz von Hochverfügbarkeitslösungen an, die speziell auf diese Applikationen ausgerichtet sind.
Kaum ein Geschäftsprozess lässt sich heutzutage noch ohne IT-Unterstützung durchführen.
Verlängerte Servicezeiten, Anwendungen im Internet oder der globale Zugriff auf Applikationen
setzen vermehrt eine hohe Verfügbarkeit voraus – oft rund um die Uhr an sieben Tagen in der Woche.
Dies betrifft nicht nur Systeme, die für die Kerngeschäfte benötigt werden, sondern inzwischen auch
periphere Bereiche.
Gleichzeitig hat die Anzahl potenzieller Ausfallursachen zugenommen. Da Applikationen immer mehr
Komponenten wie beispielsweise VPN-Verbindungen oder Webserver einbeziehen, steigt auch die Zahl
der SPOFs (Single Point of Failure), bei deren Ausfall die gesamte Anwendung lahmgelegt wird.
Außerdem hat die Vernetzung verschiedener Programme wie beispielsweise im Rahmen einer
serviceorientierten Architektur (SOA) zur Folge, dass die Applikation bei einer Unterbrechung nur
noch eingeschränkt nutzbar ist. Da Softwarelösungen sehr häufig Datenbanken als Speichergrundlage
verwenden, besteht ein wichtiger Faktor darin, die Verfügbarkeit der Datenbanksysteme
sicherzustellen.
Sechs Kategorien der Hochverfügbarkeit
Verfügbarkeit wird meist durch das prozentuale Verhältnis von Up- zu Downtimes ausgedrückt. Eine
Verfügbarkeit von 99,95 Prozent bedeutet bei Dauerbetrieb eine maximale Unterbrechungszeit von nur
fünf Stunden im Jahr. Eine solche Angabe ist für einen Netzwerk-Router sicher geeignet, für
Applikationen ist eine funktionale Einteilung oft sinnvoller. Die Harvard Research Group (HRG)
teilt Hochverfügbarkeit in ihrer Availability Environment Classification in insgesamt sechs Klassen
ein (AEC 0 bis 5). Bei AEC-0 ist eine Unterbrechung zulässig und eine Datenintegrität nicht
erforderlich, während bei AEC-5 die Funktion permanent verfügbar sein muss.
Das Wissen darüber, welches System im Unternehmen welche Verfügbarkeitsklasse benötigt, spielt
bei der Auswahl einer Hochverfügbarkeitslösung (HV) eine entscheidende Rolle. Um die jeweiligen
Klassen zu ermitteln, sind zunächst die Auswirkungen eines möglichen Ausfalls zu eruieren und deren
Kosten zu beziffern. Schwer einschätzbar sind dabei insbesondere die indirekten oder verzögerten
Auswirkungen des Ausfalls. Das Verhältnis von Ausfalldauer zur Schadenshöhe ist oft nicht konstant,
sodass die entstehenden Kosten bei einer längeren Unterbrechung exponentiell zunehmen.
Hochverfügbarkeitslösungen begrenzen zwar die Ausfallzeiten, verursachen aber gleichzeitig
Investitions- und Betriebskosten, die in Relation zu den Unterbrechungskosten zu setzen sind. Dabei
ist auch der Administrationsaufwand einer HV-Lösung zu berücksichtigen.
Die Absicherung im Fall des Defekts einzelner Hardwarekomponenten lässt sich beispielsweise mit
RAID-Systemen oder redundanten Netzteilen noch relativ einfach umsetzen. Um sich gegen den
Komplettausfall eines Servers zu wappnen, ist bereits ein aufwändiges Cluster-System erforderlich.
Allerdings läuft auch ein optimal funktionierender Cluster im Störungsfall nicht wirklich
unterbrechungsfrei weiter. So können Ausfallzeiten von mehreren Minuten oder sogar Stunden
entstehen, wenn der Administrator nach dem Wechsel des Serverrechners zunächst Integritätsprüfungen
und Recovery-Maßnahmen auf den Datenbanken durchführen muss. Außerdem liegt im Cluster nur eine
logische Kopie pro Datenbank vor. Sind diese Dateien beschädigt, ist die Datenbank nicht mehr
verwendbar.
Wechsel der Datenbank
Spezielle Hochverfügbarkeitslösungen für Datenbanken wie beispielsweise die Hot-Standby-Lösung
des Datenbanksystems Conzept 16 umgehen diese Problematik. Neben unerwarteten Ausfällen durch
hardware- oder softwareseitige Fehler berücksichtigen sie auch geplante Unterbrechungen
beispielsweise aufgrund von Wartungsarbeiten. Sie sorgen zum einen für Datenintegrität (AEC-1) und
zum anderen für geringe Ausfallzeiten von wenigen Sekunden (AEC-2). Um dies zu erreichen, wird dem
primären Datenbankserver ein weiterer Rechner zur Seite gestellt. Auf diesem nimmt die
Datenbanksoftware eine kontinuierliche Spiegelung der Datenbanken vor. Die Anwender arbeiten nach
wie vor auf der Datenbank des Primärservers. Bei jeder Veränderungen der Daten auf dem Primärsystem
führt das Datenbankmanagementsystem (DBMS) einen Abgleich auf dem Sekundärserver durch. Die
Datenübertragung erfolgt entweder zeitgleich (synchroner Betrieb) oder mit einer zeitlichen
Verzögerung (asynchroner Betrieb). Jeder Server hat somit eine eigene vollständige Kopie der
Datenbank. Ein wesentlicher Vorteil dieser Lösung ist, dass sich die Server räumlich trennen
lassen. Der Sekundärserver lässt sich so in einem anderen Brandschutzabschnitt des Rechenzentrums
oder sogar in einem Ausweichrechenzentrum unterbringen. Zudem besteht im Vergleich zu
Clustersystemen eine größere Flexibilität hinsichtlich der verwendeten Hardware. So ist es meist
problemlos möglich, Server unterschiedlicher Leistung und Spezifikation zu koppeln, wodurch sich
entsprechende Kostenvorteile ergeben.
Der Datenabgleich kann auf zwei verschiedenen Ebenen erfolgen. Bei einer physikalischen
Standby-Datenbank werden die Änderungen auf der Ebene der Storage Engine übertragen. Das Verfahren
belastet das Sekundärsystem nur wenig, erzeugt aber unter gewissen Umständen hohe Datenvolumen für
die Übertragung und ist anfälliger für Fehler im Speichersubsystem. Bei einer logischen
Standby-Datenbank werden die Änderungen auf Transaktionsebene erfasst und müssen vom Sekundärserver
erneut verarbeitet werden. Das Übertragungsvolumen ist dabei geringer, das Standby-System wird aber
stärker ausgelastet. Bei der logischen Variante lässt sich die Standby-Datenbank – je nach
Datenbanksystem – noch für andere Zwecke nutzen. Es ist möglich, die Datenbank in einem rein
lesenden Modus zu öffnen und beispielsweise für Auswertungen oder Datensicherungen zu
verwenden.
Bei Ausfall des Primärservers erkennt das Sekundärsystem diesen Zustand und wechselt vom
Standby-Betrieb in den aktiven Modus (Failover). Alle bereits abgeschlossenen und übertragenen
Transaktionen sind dabei sofort wieder verfügbar. Die Client-Systeme stellen den Ausfall ebenfalls
fest und wechseln zum Sekundärserver. Dies kann entweder vollautomatisch oder durch den Benutzer
erfolgen. Die Anwender können somit nahezu ohne Unterbrechung weiterarbeiten.
Bei Wartungsarbeiten wird der Wechsel des aktiven Systems manuell durch den Systemadministrator
vorgenommen (Switchover). Dadurch beeinträchtigen selbst umfangreiche Reparaturen nicht die
Verfügbarkeit, da die Benutzer während dieser Zeit vollständig auf dem Sekundärserver arbeiten.
Fazit: Cluster-Lösung allein reicht nicht aus
Um die erforderliche Verfügbarkeit von datenbankbasierten Anwendungen zu gewährleisten, reicht
eine Cluster-Lösung allein nicht aus. Eine leistungsfähige Alternative stellen Standby-Lösungen für
Datenbanken dar, bei denen die Software unabhängig von der eingesetzten Hardware alle notwendigen
Funktionen für die Hochverfügbarkeit bereitstellt.
Sicherung der Datenintegrität
Schutz vor Datenverlusten
Minimierung der Ausfallzeiten
Hardwareunabhängigkeit
Lesen Sie mehr zum Thema
