Von: DIRK PELZER
Datenbanken sind für viele Firmen ein unternehmenskritischer Faktor - nicht nur im E-Commerce kosten Ausfälle oft zehntausende von Mark pro Stunde. Es lohnt sich also, in Hochverfügbarkeitslösungen wie Cluster-Systeme zu investieren.
Die Kombination von Oracle-Datenbanken mit Windows 2000 galt hierfür bislang nicht gerade als Traumpaar. Die meisten Unternehmen setzen auf proprietäre Unix-Systeme. Doch mittlerweile gibt es mehrere Alternativen, um Oracle mit Windows 2000 hochverfügbar und skalierbar zu implementieren - und das zu niedrigeren Preisen.
Eine Lösung, die den Spagat in beide Richtungen versucht, ist der "Oracle Parallel Server" (OPS). Mit ihm können Unternehmen hochskalierbare Lösungen aufbauen, die zugleich ausfallsicher sind. Wenn die Verfügbarkeit der Datenbank im Vordergrund steht, kommen Failover-Produkte wie der "Microsoft Cluster Service" (MSCS) zum Einsatz. Eine weitere Alternative bieten Replikations-Mechanismen, welche die Datensätze auf andere Systeme replizieren.
"Oracle Parallel Server"
Bereits seit 1997 bietet Oracle den Parallel Server für Windows NT und mittlerweile auch für Windows 2000 an. Er setzt die Enterprise Edition von "Oracle 8i" voraus und soll Skalierbarkeit und Verfügbarkeit der Oracle-Datenbank verbessern.
Der Server arbeitet nach dem Shared-Disk-Prinzip. Dadurch haben alle Cluster-Knoten gleichzeitig Zugriff auf die Datenbankdateien und können Lesevorgänge parallelisiert und damit schneller ausführen - vorausgesetzt die zu Grunde liegende Anwendung unterstützt den Parallelzugriff. Schreiboperationen hingegen müssen serialisiert werden, um der Inkonsistenz des Datenbestandes vorzubeugen. Diese Aufgabe übernimmt der Distributed-Lock-Manager (DLM), der allerdings bei schreibintensiven Anwendungen und sehr vielen Knoten leicht zum Flaschenhals wird. Die Leistungsfähigkeit in OPS-Clustern mit zwei Knoten kann mit einer nicht für den OPS-Einsatz optimierten Anwendung deshalb sogar schlechter sein als bei einem einzelnen Datenbankserver.
Der Parallel-Server stellt sehr hohe Anforderungen an die Hardware. Aufgrund seiner Architektur skaliert er am besten mit wenigen leistungsfähigen Maschinen. Die Performance eines Zwei-Knoten-Clusters mit Vier-Prozessor-Maschinen ist besser als die eines Vier-Knoten-Clusters mit Zwei-Wege-Systemen. Für die Geschwindigkeit von OPS-Lösungen ist zudem der Cluster-Interconnect entscheidend, der die Kommunikation zwischen den Knoten abwickelt und die Schreibzugriffe auf die Datenbank regelt. Ein Knoten, der in eine Tabelle schreiben möchte, meldet dies beim Distributed-Lock-Manager an. Sobald er vom DLM die Mitteilung erhält, dass die gewünschte Datenstruktur für den Schreibzugriff freigegeben ist, setzt der Knoten einen "Lock" und sichert sich damit den exklusiven Zugriff. Nach Beendigung der Operation gibt der Knoten den Lock über den DLM wieder frei.
Aufgrund dieser Koordination der Cluster-Knoten tauscht eine Shared-Disk-Architektur im Vergleich zu einem Shared-Nothing-Cluster etwa hundert Mal so viele Nachrichten aus. Ein Cluster-Interconnect über eine Netzwerkverbindung mit 100 Mbit/s wie bei Fast Ethernet kann da bereits zu langsam sein. Deshalb sollten Hochgeschwindigkeits-Interconnects eingesetzt werden, zum Beispiel "Servernet VI" von Compaq oder Gigabit Ethernet. In Zukunft wird hier auch Infiniband eine wichtige Rolle übernehmen.
Der Failover bei OPS ist relativ leicht zu bewerkstelligen, da alle Cluster-Knoten auf denselben Datenbestand zugreifen. Die Geschwindigkeit hängt allerdings stark davon ab, wie viele Locks gesetzt waren und ob der Cache kohärent ist. Damit die anderen Knoten weiter arbeiten können, muss der DLM alle Locks beseitigen, die ein ausgefallener Knoten in der Datenbank gesetzt hatte. Bei schreibintensiven Anwendungen, die ständig viele Locks setzen, ist die Failover-Zeit deshalb länger.
"MSCS" und"Oracle Fail Safe"
Einen anderen Ansatz als Oracle mit dem Parallel Server verfolgt Microsoft mit seinem Cluster-Service (MSCS) für Windows 2000. Dieser ist unter Windows 2000 Advanced Server als Zwei-Knoten-Lösung verfügbar, unter dem Data Center Server sogar mit vier Knoten. Der MSCS gehört zur Kategorie der Shared-Nothing- oder Failover-Cluster: Jeder Knoten hat zu jedem Zeitpunkt exklusiven Zugriff auf die ihm zugewiesenen Ressourcen. Dies gilt auch für die Festplatten mit den Datenbankdateien.
Damit unterscheidet sich dieser Cluster-Typ vom OPS, bei dem alle Knoten gleichzeitig auf die Plattenlaufwerke zugreifen können. Der Vorteil der Shared-Nothing-Lösung: Sie benötigt keinen aufwändigen DLM-Mechanismus. Die beteiligten Knoten tauschen über den Cluster-Interconnect im wesentlichen Heartbeat-Signale aus, um festzustellen, ob noch alle Systeme aktiv sind. Ein Nachteil ist die eingeschränkte Skalierbarkeit der Datenbank, die immer nur von einem Knoten ausgeführt werden kann.
Immerhin sind mit Oracle 8i so genannte Active/Active-Konfigurationen möglich, bei denen jeder Knoten in der Lage ist, die Datenbank(en) eines ausgefallenen Systems zu übernehmen. Die beteiligten Server müssen über ausreichende Leistungsreserven verfügen, um im Notfall die zusätzliche Belastung verkraften zu können. In einer Actice-/Active-Konfiguration sollte die CPU-Auslastung im Durchschnitt 45 Prozent nicht überschreiten, gleiches gilt für den Arbeitsspeicher.
Da der MSCS keine native Unterstützung für Oracle-Datenbanken bietet, hat Oracle mit "Oracle Fail Safe" (OFS) eine Lösung entwickelt, die auf dem MSCS aufbaut. Der Datenbankspezialist hat hierfür DLLs geschrieben, die kurze Failover-Zeiten garantieren sollen. OFS sorgt zudem dafür, dass neben der Datenbank auch Oracle-Komponenten wie Forms und Reports ausfallsicher werden. Die Entwickler haben darüber hinaus eine erweiterte Skriptschnittstelle implementiert, über die der Systemverwalter beispielsweise bestimmte Lastverteilungsszenarien, Offline-Backups oder eine Verifizierung der Cluster-Gruppen vornehmen kann.
Für die Konfiguration einer Oracle-Datenbank innerhalb eines Fail-over-Clusters müssen zahlreiche Einstellungen modifiziert und angepasst werden. Um diese Arbeiten zu vereinfachen, hat Oracle eine eigene Benutzeroberfläche mit zahlreichen Assistentenentwickelt.
Plattenspeicher als Single Point of Failure
Datenbanken legen ihre Daten häufig auf einem Plattensubsystem ab, das zwar mit redundanten Netzteilen und ausfallsicheren Raid-Platten aufwartet, aber dennoch einen Single Point of Failure darstellt. So könnte etwa ein Kurzschluss zum Ausfall des gesamten Subsystems führen.
Um auch derartige Ausfälle ohne Down-Zeiten zu überstehen, empfiehlt sich der Einsatz von Replikations-Tools, die den Platteninhalt eines Subsystems auf ein anderes spiegeln. Zur Wahl stehen Controller-gestützte Systeme oder preiswertere Softwarelösungen. Bei ersteren sorgt die Firmware des Raid-Adapters dafür, dass die Daten auf zwei Systeme geschrieben werden. Fällt eines aus, findet ein transparenter Failover auf das "überlebende" System statt. Dieses Konzept setzt in der Regel identische Hardware vo-raus und ist meist sehr kostspielig.
Eine vergleichsweise preiswerte softwaregestützte Lösung bietet die Firma Veritas mit dem "Volume Manager" für Windows 2000 an. Dieser ermöglicht es, den Speicherplatz zweier unterschiedlicher Subsysteme per Raid-1-Konfiguration zu einem logischen Volume zusammenzufassen. Die beteiligten Plattensysteme müssen weder vom selben Hersteller stammen noch am selben Standort sein.
Ausfallsicherheit durch Replikation
Unternehmen, die auf eine Failover-Funktion, nicht aber auf Ausfallsicherheit verzichten können, liebäugeln häufig mit einer reinen Replikationslösung. Dabei werden die Daten auf zwei oder mehr Systemen redundant vorgehalten. Die Replikation kann synchron oder asynchron erfolgen.
Bei der synchronen Replikation gilt eine Transaktion erst dann als abgeschlossen, wenn dies von allen beteiligten Systemen bestätigt wurde. Anderenfalls findet ein Rollback statt. Dies beeinträchtigt die Performance, insbesondere wenn die beteiligten Server über eine größere Distanz verbunden sind.
Bei der asynchronen Replikation muss nur das primäre System die Transaktion bestätigen. Deshalb können unter Umständen Transaktionen auf dem Weg zu den redundanten Zielsystemen verloren gehen und müssen zeitverzögert nachgeholt werden. Während dieses Zeitraumes sind die Datenbestände inkonsistent.
Eine zuverlässige Variante stellt auch die Replikation auf Transaktionsebene dar, wie sie beispielsweise Oracle in der "Advanced Replication" realisiert hat. Diese arbeitet im Gegensatz zu den anderen Mechanismen nicht auf dem Datei- oder Block-Level, sondern auf der Transaktionsebene. Das Verfahren unterstützt neben synchroner und asynchroner Replikation auch eine Hybridform, die Teile der Datenbank synchron und andere asynchron repliziert. Sie bietet die folgenden vier Modi:
Primary Site Ownership: Die Daten gehören zu einer Site und können nur in dieser geändert werden.
Dynamic Ownership: Der Besitz über die Daten kann wandern. Updates kann nur der aktuelle Besitzer vornehmen.
Shared Ownership: Die Daten können auf allen Sites geändert werden.
Fail-over: Die Daten werden auf ein zweites System repliziert.
Die hybride Replikation eignet sich vor allem für Konfigurationen, bei denen die Daten nur auf einem System modifiziert und dann an weitere Systeme übertragen werden.
Fazit
Mittlerweile gibt es eine ganze Reihe unterschiedlicher Produkte, um Oracle-Datenbanken unter Windows 2000 ausfallsicher auszulegen. Für Unternehmen, die ihre Unix-Systeme durch Windows 2000 ersetzen wollen, sollte sich damit eine passende Lösung finden lassen. Auch bei Windows 2000 ist jedoch zu beachten, dass eine sorgfältige Planung und ausführliche Tests von Hochverfügbarkeits-Anwendungen die wichtigsten Voraussetzungen für einen erfolgreichen Produktivbetrieb sind. (cl)
Zur Person
DIPL.-ING DIRK PELZER
ist freiberuflicher Consultant und Journalist in München. Er beschäftigt sich unter anderem mit Speichernetzwerken und hochverfügbaren Rechnersystemen.