Mit Netz und doppeltem Boden - JAXenter
Hochverfügbarkeit von Datenbanken: Cluster vs. Standby

Mit Netz und doppeltem Boden

Andrej Mücke

In den letzten Jahren sind die Ansprüche an die Verfügbarkeit von datenbankbasierten Anwendungen in Unternehmen stark gewachsen. Um diesen Anforderungen gerecht zu werden, bietet sich der Einsatz von Hochverfügbarkeits-Lösungen an, die speziell auf Datenbanken 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. Das 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. Andererseits 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 immer mehr Software-Lösungen 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 Netzwerkrouter sicherlich 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-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ügbarkeits-Lösung (HV) eine ganz entscheidende Rolle. Um die jeweiligen Klassen zu ermitteln, sind zunächst die Auswirkungen eines möglichen Ausfalls zu eruieren und kostenmäßig 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 oftmals nicht konstant, so dass 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.

Vorteile von Standby-Lösungen für Datenbanken

  • Sicherung der Datenintegrität
  • Schutz vor Datenverlusten
  • Minimierung der Ausfallzeiten
  • Hardware-Unabhängigkeit

Die Absicherung im Falle des Defekts einzelner Hardware-Komponenten 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 umgehen diese Problematik. Neben unerwarteten Ausfällen durch Hardware- oder Software-seitige 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 Datenbank-Software 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 Datenbank-Management-System (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 IT-Verantwortliche die Server räumlich trennen können. Der Sekundär-Server 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 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 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. Die Datenbank kann dabei in einem rein lesenden Modus geöffnet und beispielsweise für Auswertungen oder Datensicherungen verwendet werden.

Bei einem 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 Clientsysteme 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

Um die erforderliche Verfügbarkeit von datenbankbasierten Anwendungen zu gewährleisten, reicht eine Cluster-Lösung nicht aus. Eine leistungsfähige Alternative stellen Standby-Lösungen für Datenbanken dar, bei denen die Software unabhängig von der eingesetzten Hardware Funktionen für Hochverfügbarkeit bereitstellt.

Andrej Mücke ist Leiter der Datenbankentwicklung Conzept 16 bei der Vectorsoft AG.

Geschrieben von
Andrej Mücke
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.