Bei immer mehr Unternehmen spielt der Caché-Server, der als Basis-Datenbankserver in transObjects® Anwendung findet, eine zunehmend entscheidende Rolle; man kann mittlerweile gut und gerne sagen, alles steht und fällt mit Caché. Überlegung zu Steigerung der Verfügbarkeit dieser zentralen Serverinstanz, wie etwa in WhitePaper341 aufgezeigt, gewinnen daher immer mehr an Bedeutung.
Doch im Gegensatz zu dem in WhitePaper341 diskutierten Clustering kam das Shadowing in den letzten Jahren weitaus häufiger zum Zuge. Was das Grundprinzip – und vielleicht das Geheimnis des Erfolges – von Shadowing ist sowie diverse Fragen rund um den im transObjects® Datacenter etablierten Shadowing-Service sollte der vorliegende Artikel klären.
Shadowing (zu Deutsch Schatten-Kopien bzw. -Kopieren) ist ein Spezialfall des in faq.id=28 erörterten verteilten Datenbanksystems (DDS). Das Wesen des Shadowing besteht in einem sukzessiven Replizieren der Datenbankdateien auf einen anderswo etablierten Datenbankserver und zwar im Sinne einer Backup-Vorrichtung. Das nachfolgend noch einmal angeführte DDS-Schema aus faq.id=28 behält zwar grundsätzlich seine Gültigkeit, jedoch ist hier einer der beiden Standorte bzw. Nodes (z.B. „A“) in einer Art Wartestellung und der Datenaustausch mit Clients findet grundsätzlich nicht statt – höchstens im Sinne von Controlling-Aufgaben.
Ist nun der Hauptnode (in unserem Beispiel Standort „E“) aus welchem Grund auch immer indisponiert, muss an die Backup-Instanz, die ja aufgrund von Replikation denselben Datenbestand enthält, angedockt werden. Das bedeutet, dass alle Clients, die bis dato am Hauptnode „hingen“, entsprechend „verbogen“ werden müssen und zwar so, dass sie fortan nur mit der Backup-Instanz ihre Daten austauschen. Diese Massnahme kann mehr oder minder automatisch erfolgen, ist aber normalerweise etwas für den SysOp, der dieses Failover-Szenario ganz bewusst durchzuspielen hat, am besten anhand einer Checkliste.
An dieser Stelle zeigt sich schon mal der erste Unterschied zum Clustering: eine Failback-Funktion gibt es beim Shadowing nicht, jedenfalls nicht automatisch. Denn wurde in einem Shadowing-DDS ein Failover einmal durchgeführt, kann ein Failback, d.h. eine Reaktivierung des Hauptnodes und dessen Versorgung mit aktuellen Daten, nur manuell durchgeführt werden. Dennoch hat dieser unbestreitbare Vorteil des Clustering nicht sehr viele davon abgehalten, gerade auf das Shadowing zu setzen. Warum?
Ein Failover-Cluster kann seine automatische Failover/Failback-Funktion nur dann ausüben, wenn die Datasets des Caché-Servers auf einem von allen Nodes aus zugänglichem Laufwerk, sog. Shared-Storage, gespeichert werden. Da dieses Shared-Storage (SAN: storage area network, NAS: network attached storage) per se nicht clusterbar ist, muss es ganz anderen Sicherheitsanforderungen genügen als die Hardware jedes einzelnen Nodes. Das führt nicht selten dazu, dass ein adäquates SAN oder NAS 5-stellige Kosten verursacht und da vertrauen viele Anwender lieber auf eine vollwertige Kopie ihrer Daten auf einem anderen Server (evtl. an einem anderen Standort), als auf eine einzelne Kopie auf einem noch so guten SAN oder NAS. Schliesslich kommt noch ein nicht unwichtiger Faktor hinzu und das sind die Kosten entsprechender Betriebssystem-Lizenzen, die im Falle eines Windows® 2000/2003-Clusters entsprechend hoch ausfallen (erforderlich ist eine Windows® 2000/ 2003 Server Enterprise- oder Datacenter-Edition auf jedem Clusternode!) während ein DDS diese speziellen Betriebssystem-Editions nicht benötigt. *) **)
Soweit so gut. Die Frage, die uns sehr häufig gestellt wird, lautet meistens – etwa im Zusammenhang mit dem Shadowing übers transObjects®-Datacenter – folgendermassen: Wozu brauche ich das? Ich mache doch jeden Tag Datensicherungen! Nun, die Realität ist wie so häufig etwas anders, wie das nachfolgende Beispiel verdeutlicht.
Ein kleines Unternehmen aus der Schweiz wendet transObjects®-Applikationen nur für den Bereich Warenabfertigung an. Am Donnerstag-Abend crasht der Datenträger-Controller des Caché-Servers. Der Hersteller verspricht Ersatz erst Anfang kommender Woche, also nichts wie ran ans Aufsetzen des Caché-Servers auf einer anderen Hardware. Dann nehmen wir die Datensicherungsbänder und … uff, Datenbanken (Datasets) lassen sich wiederherstellen… aber: Der Datenbestand ist von vor 24 Stunden! „Wo bleiben denn die Zolldeklarationen von heute?“
Anschliessend gibt es Probleme über Probleme mit beiden Zollbehörden wg. Doppelverzollungen etc. bis dann in ein paar Wochen der alte Datenbestand rekonstruiert werden kann… um anschliessend wieder mal logische Widersprüche zu den Vorgängen unmittelbar nach dem Crash zu verursachen… Es war Nerven- und Kapital-aufreibend. Der Kunde bestellt schlussendlich den Shadowing-Service via transObjects®-Datacenter – shade nur, dass erst jetzt, nachdem der Schaden eingetreten ist…
________________________________________
