Hochverfügbarkeit ist eine so geläufige Forderung an Datenbanken, dass die meisten Hersteller einfach administrierbare Tools zum Schutz vor Ausfällen mitliefern. Eine dieser Techniken, die Oracle für diesen Zweck in petto hat, heißt Data Guard.
Ob Onlineshop oder Finanzbuchhaltung, Wetterdienst oder Aktienhandel, Nachrichtenagentur oder Genforschungslabor - immer arbeiten im Hintergrund Datenbanken, ohne die alle Räder stillstehen würden. Weil die meisten Prozesse heute auf solche Datenablagen angewiesen sind und deren Ausfall oft mit empfindlichen finanziellen Verlusten verbunden wäre, gehören die Techniken für Hochverfügbarkeit in diesem Bereich zum Standard.
Entsprechend hat auch Oracle, eine der meistbenutzten kommerziellen Datenbanken, gleich mehrere High-Availability-Konzepte realisiert: Bis Version 8i gab es den Oracle Parallel Server (OPS). Heute kann der Nutzer auf Standby-Datenbanken, ab Version 9i tragen sie den Namen Data Guard, zurückgreifen oder den Real Application Cluster (RAC) einsetzen oder Oracles Flashback-Technologie verwenden.
Der Real Application Cluster, der wahrscheinlich bekannteste Ansatz, besteht aus mehreren Serverknoten, die gemeinsam auf ein Speichersystem zugreifen (Shared Storage). Dessen Hardware muss unbedingt ausreichend redundant ausgelegt sein, weil ihr Ausfall das Aus für den gesamten Cluster bedeuten würde. Das Hinscheiden eines Serverknotens dagegen kann ein Cluster-Kollege, der die ausgefallenen Dienste einfach übernimmt, fast ohne Zeitverlust kompensieren.
Hardware-Ausfälle jeder Art, also inklusive eines Aus der Speichersysteme, vermag dagegen der Data Guard aufzufangen. Freilich hat das einen Preis, denn hinter diesem Konzept steht ein Zwillingssystem aus einer Produktionsdatenbank und bis zu neun Kopien (Standby-Systemen). Der Data Guard eignet sich aufgrund seines Konzepts und wegen des überschaubaren Administrationsaufwands sowie der geringen Softwarekosten besonders für kleinere und mittelgroße Anwendungen. Abbildung 1 verdeutlicht seine Funktionsweise.
Abbildung 1: So funktioniert Data Guard: Die Redo-Logs übertragen die Änderungen an den gespeicherten Daten vom primären System auf die Kopie.
Während sich beim RAC - bedingt durch den Shared Storage - der Server und die Speichersysteme am selben Ort befinden müssen, lassen sich beim Data Guard die primären und alle sekundären Datenbanken räumlich getrennt installieren. Befände sich die primäre Datenbank in Berlin, dürfte ein Standby-System etwa in Wien laufen. Damit ließe sich dann sogar die höchste Stufe der Absicherung - ein Desaster Tolerant System - erreichen, das selbst dann ohne merklichen Zeitverlust weiterarbeitet, wenn eine Seite durch Brand oder einen Elementarschaden (Überschwemmung, Erdbeben) total zerstört würde [1].
Auch die planmäßige Maintenance vereinfacht der Data Guard erheblich. So können die Administratoren problemlos auf einer Seite Wartungsarbeiten erledigen, die zwingend eine Downtime des Systems erfordern. In dieser Zeit arbeitet der Partner alle Anfragen ab, der sich nach einem abschließenden Switchback wieder in seine ursprüngliche Rolle als Standby-System fügt.
Darüber hinaus braucht das Standby-System nicht nur im Dienst der Hochverfügbarkeit zu stehen [3]. Es kann beispielsweise auch das primäre System beim Erstellen Ressourcen-fressender Reports entlasten oder langwierige Statistiken berechnen.
Alle Rezensionen aus dem Linux-Magazin
Im Insecurity Bulletin widmet sich Mark Vogelsberger aktuellen Sicherheitslücken sowie Hintergründen und Security-Grundlagen. mehr...
