Bei der Auswahl der Hardware-Komponenten wurden folgende Überlegungen mit einbezogen:
- Die Vorkommnisse der letzten Jahre (Stromausfälle und -abschaltungen) sowie diverse Katastrophenszenarien (z.B. Brand) haben dazu geführt, das Konzept einer redundanten Aufteilung auf verschiedene Gebäude beizubehalten bzw. weiter umzusetzen. Da beide Server (Produktions- und Testrechner) bereits auf die Standorte ZID und Bibliothek aufgeteilt sind, ist es naheliegend, auch Daten redundant auf diese Weise abzulegen. Das setzt natürlich eine Dual-Storage-Konfiguration voraus. Da nicht unbegrenzte finanzielle Mittel zur Verfügung stehen und jede weitere Erhöhung der Datensicherheit immer größere Investitionen mit sich bringt, soll eine schrittweise Umsetzung auch unter teilweiser Verwendung bestehender Komponenten (ohne Performance-Einbuße) möglich sein.
- In der alten Konfiguration ist der Testserver am Standort Bibliothek mit zwei 2Gbit Multimode FC-Leitungen (Shortwave) mit dem Storage im ZID verbunden. Dieser Leitungstyp ist bezüglich Distanz und Geschwindigkeit am Limit, abgesehen davon gibt es nur wenige Multimode-Querverbindungen, welche vorwiegend für Telefonie und Netzwerk vorgesehen sind. Aus diesem Grund sollen in Zukunft für gebäudeübergreifende FC-Verbindungen hauptsächlich 4Gbit Singlemode FC-(Longwave)-Leitungen eingesetzt werden. Da die bestehenden Hostadapter der Server keine austauschbaren SFPs (Small Form-factor Pluggable) besitzen und nicht beliebig viele Singlemode-Leitungen für eine Punkt-zu-Punkt-Struktur zur Verfügung stehen, müssen FC-Switches mit Longwave SFPs für die Standortkoppelung eingesetzt werden.
- In den letzten beiden Jahren kam es leider einige Male vor, dass bibliothekarische Daten aus der Datenbank auf Grund von Fehlbedienung und/oder Software-Problemen teilweise wiederhergestellt werden mussten. Das gleiche betraf auch diverse Konfigurationsdateien. Für solche Fälle ist es besser, die Daten beider Storages nicht 1:1 zu spiegeln (per Hardware oder auf Betriebssystembasis), sondern die Replikation der Datenbankapplikation selbst bzw. geeigenten Tools zu überlassen. Ein Recover ist bei diesem Konzept schneller bzw. unter Umständen gar nicht notwendig. Die Vor- und Nachteile verschiedener Methoden der redundanten Datenhaltung werden weiter unten näher betrachtet.
Nach reiflichen Überlegungen entschied sich der ZID für die Anschaffung eines SUN StorageTek 6140 FC-Arrays mit 16 Stück 300GByte FC-Platten, Dual-RAID-Controller, 4GByte Cache und 8 4Gbit Host Ports. Das Storage hat eine sehr gute Performance, mehr als doppelt soviel Speicherkapazität wie das alte und ist für die Zukunft ausreichend erweiterbar. Das alte Storage (Sun StorageTek 3510 FC-Array) wird beibehalten und für die redundante Datenhaltung eingesetzt. Weiters wurden zwei SilkWorm 220E FC-Switches von Brocade für die Gebäudekoppelung ausgewählt. Natürlich wären für eine optimale Ausfallssicherheit und die Vermeidung von „Single Points of Failures“ doppelte FC-Switches auf beiden Seiten notwendig. Eine solche Maßnahme erhöht zwar nicht die Datensicherheit, verringert aber die Wahrscheinlichkeit einer Unterbrechung im Produktionsbetrieb. Inwieweit eine solche Maßnahme notwendig ist und auch das alte Storage durch ein neues ersetzt werden soll, wird im nächsten Jahr entschieden. Jeder Server und jedes Storage ist doppelt mit seinem FC-Switch verbunden und die Querverbindung zwischen den beiden Switches erfolgt durch zwei 4Gbit Singlemode-Leitungen. Bei der Wahl der FC-Switches wurde noch darauf geachtet, dass es bei dem Typ möglich ist, mehrere Querverbindungen nicht nur für eine Verbesserung der Redundanz sondern auch für eine Erhöhung der Gesamtübertragungskapazität einzusetzen. Es gibt zwar bereits die 10Gbit-Technologie, diese ist aber immer noch relativ teuer.
Wie bereits zuvor erwähnt, gibt es prinzipiell mehrere Methoden, Daten (vorwiegend Datenbanken) redundant zu halten:
- Eine Methode ist die Spiegelung von Storages auf Hardware-Basis. Voraussetzung dafür sind quasi identische Storagesysteme mit schnellem Interlink (am besten 10Gbit). Da gerade bei transaktionskritischen Datenbanksystemen eine asynchrone Spiegelung nicht akzeptabel ist, sind solche Lösungen in der Regel sehr teuer. Vorteil ist sicher eine absolut identische Datenhaltung und ein unterbrechungsfreier Betrieb bei Ausfall einer Spiegelkomponente. Nachteil ist natürlich, dass bei Datenverlust durch Fehler des Betriebssystems, der Applikation oder bei menschlichem Versagen beide Seiten gleich betroffen sind.
- Eine einfachere und billigere Methode ist die Spiegelung von Storages auf Betriebssystem-Ebene (z.B. Logical Volume Manager). Voraussetzung dafür sind Storage-Systeme mit annähernd gleicher Kapazität und Perfor- mance. Ansonsten wäre die Gesamt-Performance und -kapazität lediglich der kleinste gemeinsame Nenner. Oft ist die Konfiguration einer solchen Lösung (vor allem im High Availability Cluster Betrieb) nicht trivial. Vor- und Nachteile sind ähnlich der obigen Methode.
- Eine dritte Methode wäre die Spiegelung der Daten auf Applikationsbasis. In diesem Fall sind beide Storages nicht gleichberechtigt (Master + Slave) und es müssen auch nicht notwendigerweise beide Storages kapazitiv gleichwertig sein. Je nach Art und Weise der Replikation und Anforderungen der Aktualität der replizierten Daten ist der Performance-Unterschied beider Storages relevant. Die Vorteile dieser flexibleren Methode sind, dass erstens nur notwendige Daten gespiegelt werden und dadurch die Gesamtspeicherkapazität erhöht wird, zweitens verschiedene Replikationsmethoden gleichzeitig angewendet werden können und drittens bei Datenverlust oder Fehlbedienung nicht notwendigerweise beide Seiten betroffen sein müssen. Nachteil ist natürlich, dass bei Ausfall des Master Storages der Betrieb unterbrochen ist und entsprechende Recover-Maßnahmen eingeleitet werden müssen. Da die replizierten Daten allerdings permanent am Slave Storage vorhanden sind (auch definiert lange Archiv-Daten), kann die Wiederherstellung relativ schnell durchgeführt werden. Das Gleiche betrifft auch eine geplante Abschaltung des Master Storages.
Der ZID hat sich nach längerem Abwägen zwischen den beiden letzten Methoden für die Variante der Spiegelung auf Applikationsbasis entschieden. Im Wesentlichen geht es um die Replikation der Oracle-Datenbank und der Aleph-Konfigurationsdateien. Oracle bietet verschiedene Möglichkeiten, Daten zu replizieren, eine davon ist die herkömmliche durch gespiegelte Controlfiles, Redo- und Archive-Logs. Mit dieser Methode und einem nächtlichen vollen Hot Backup auf das Slave Storage kann im Fall eines Totalverlustes des Master Storages die Datenbank ohne langwieriges Restore vom Band rasch wieder hergestellt werden (inkl. der allerletzten Transaktion). Das Gleiche betrifft auch die Notwendigkeit eines Zurück-fahrens der Datenbank auf einen früheren Zeitpunkt auf Grund von Fehlbedienung. Es gibt natürlich außer dieser Methode auch noch andere Möglichkeiten, eine Oracle-Datenbank im laufenden Betrieb zu replizieren, z.B. Oracle Data Guard, Oracle ASM bzw. Produkte von Drittherstellern, um nur einige zu nennen. Alle haben ihre Vor- und Nachteile, bzw. sind teilweise nicht gerade billig (Data Guard benötigt Enterprise Lizenz, ASM funktioniert nur mit Raw Partitions). Des Weiteren muss man auch auf die Oracle-Versionskompatibilität der Produkte und die Akzeptanz durch die Fa. Exlibris (Aleph Bibliotheks-Software) achten.
Die Spiegelung anderer Daten wie z.B. Aleph-Konfigurationsdateien wird durch das Public Domain Synchronisationsprogramm „rsync“ bewerkstelligt, welches ungefähr alle 15 Minuten einen Abgleich durchführt. Dadurch ist dem Benutzer die Möglichkeit gegeben, irrtümliche Löschaktionen rasch ungeschehen zu machen. Zusätzlich ist ausreichend Platz vorhanden, um mehrere Generationen von Daten online zu archivieren.
Die Umstellung auf das neue Storage erfolgt in zwei Schritten. Zuerst muss die bestehende SAN(Storage Area Network)-Struktur von „Direct Attached“ auf „Fabric“ mit FC-Switches umgebaut werden. In diesem Zuge wird auch gleich das alte Storage vom Rechnerraum des ZID auf den Standort Bibliothek übersiedelt. Danach sind ausreichend Anschlüsse frei, um das neue Storage zusätzlich in das SAN einzubinden. Nachdem das neue Storage seine endgültige Konfiguration erhalten hat, wird der komplette Datenbestand vom alten auf das neue Storage überspielt und das alte Storage ebenfalls neu konfiguriert. Danach können die Datenbank und diverse Synchronisations- und Backup-Scripts an die neue Master-Slave Dual-Storage-Konfiguration angepasst werden. Unabhängig davon muss noch die Querverbindung zwischen den Gebäuden von Multimode-FC auf Singlemode-FC umgestellt werden (Kabelverlegungsarbeiten). Diese Tätigkeiten sollten bis zum Jahreswechsel abgeschlossen sein, da im Jänner bereits von der Fa. Exlibris ein Testsystem der neuen Aleph Version 18 installiert wird.
Im Anschluss sind noch zwei Abbildungen enthalten, welche die aktuelle und die neue Gesamtkonfiguration des Bibliothekssystems darstellen.
