Interview mit Marco Metzlaff, Libelle

Disaster Recovery in heterogenen Umgebungen

Seite: 2/2

Anbieter zum Thema

Können Sie Unternehmen Empfehlungen geben, wie sie sich sichern sollten?

Als Best Practices zum Thema Verfügbarkeit und Katastrophenvorsorge bei Ausfall von Servern, Rechenzentren und logischen Fehlern empfehlen wir den Einsatz von Spiegelungen, Partition Mobility hingegen für das Provisioning von Systemen aus Performancegründen und die Durchführung von geplanten Downtimes für Server. Eine Spiegelung beispielweise mit BusinessShadow ermöglicht auf Grund der Nähe zur Applikation, dass Datenkonsistenz sowohl innerhalb eines Systems als auch über physikalische und virtuelle Systemgrenzen hinweg hergestellt werden kann. Zusätzlich dazu sind logische Fehler erkenn- und beseitigbar.

Darüber hinaus bieten Spiegelungslösungen wie BusinessShadow die Möglichkeit Technologien, wie sie LiveMotion oder VMMotion im lokalen Rechenzentrum anbieten, auch über Weitverkehrsnetze zu ermöglichen.

Ein weiterer wichtiger Bereich des Einsatzes unseres Produktes ist neben der klassischen Katastrophenvorsorge dann auch der Umzug von Systemen, insbesondere wenn es auf kurze Umschaltzeiten über lange Distanzen ankommt. Dabei sind Umschaltzeiten im Minutenbereich selbst über Entfernungen von mehreren tausend Kilometern kein Problem. Unsere Kunden setzen bei solchen Umzügen auf diese Technologie, weil sie damit in der Lage sind, Umschaltzeiten, Aufwände und auch das generelle Umzugsrisiko zu minimieren.

Wodurch unterscheidet sich zeitversetzte Datenspiegelung von anderen Konzepten?

Grundsätzlich gibt es unterschiedliche Ansätze und Wege, wie sich eine Katastrophenvorsorge realisieren lässt. Weitverbreitet sind dabei eine Spiegelung auf Ebene der Datenbanken oder eine Spiegelung auf Ebene der Blöcke im Speichersubsystem oder in Logical Volume Managern. All diese Technologien haben Ihre Vor- und Nachteile. Allgemein jedoch gilt: je näher eine Absicherung der Daten an der Applikation implementiert ist, desto einfacher ist es möglich umfassende und systemübergreifende Datenkonsistenz zu gewährleisten. Insbesondere die asynchrone Spiegelung auf Blockebene birgt das Risiko der Korruption von Daten, wenn die Blockgröße des Speichersubsystems nicht mit der Größe der Datenbankblöcke überein stimmt.

Das Besondere an der zeitversetzten Datenspiegelung ist, dass sich nicht nur physikalische Fehler beheben, sondern auch logische Fehler erkennen und beseitigen lassen, also zum Beispiel Importe aus fehlerhaften Schnittstellen, fehlerhafte Bedienung usw. Dies gilt übrigens nicht nur für ein einzelnes System, es lassen sich ganze Systemverbünde, die durch die Fehlerfortpflanzung betroffen sind, wieder in einen konsistenten Zustand überführen. Der Fokus liegt hier übrigens nicht ausschließlich auf dem Thema Datenbank. Um eine ganzheitliche Abdeckung der Applikation gegenüber Fehlern zu gewährleisten, verwendet das Produkt die Methode der zeitversetzten Datenspiegelung auch für Filesysteme, in denen oft Schnittstelleninformationen oder andere kritische Dateien abgelegt werden.

Zusammenfassend kann man sagen, dass sich die zeitversetzte Datenspiegelung besonders dann eignet, wenn es um die Reaktion auf sowohl physikalische als auch logische Fehler geht, wenn mehr als nur die Datenbank von der Verfügbarkeitsanforderung betroffen ist, oder wenn eine Spiegelung über weite Distanzen durchgeführt werden soll.

(ID:2022169)