Es gibt immer ein Zurück: vier Disaster-Recovery-Lösungen

Replikation

Synchrone Replikation

Pro

  • Daten sind an allen Standorten aktuell.
  • Kommt es zum Systemausfall, sind die Daten sofort verfügbar.

Contra

  • Beeinträchtigt in der Regel die Anwendungsleistung.
  • Die Datenspeicherung kann sich durch die Latenzzeit des Netzwerks zwischen verschiedenen Standorten unterscheiden; dies führt auch zu Write-Commit-Verzögerungen über Netzwerkknoten hinweg.

Asynchrone Replikation

Pro

  • Hat meist weniger Auswirkungen auf die Anwendungsleistung als die synchrone Replikation, maximiert also die Leistung.
  • Die Daten stehen am sekundären Replikationsstandort sofort zur Verfügung.
  • Contra

  • Die Daten am sekundären Standort können eine Zeitdifferenz im Verhältnis zum primären Standort aufweisen.
  • Möglichkeit der Datenkorruption bei einigen Datenbanken.

Periodische Replikation

Pro

  • Daten sind am sekundären Replikationsstandort sofort verfügbar.
  • Contra

  • Daten sind alt und möglicherweise inkonsistent.
  • Erfordert mehr Speicher zur Aufrechterhaltung der Gesamtkonsistenz.
  • Das Abgleichen der Datensätze kann sehr schwierig sein.

Remote Mirroring (Fernspiegelung)

Die Fernspiegelung, bei der primäre und sekundäre Standorte über ein SAN verbunden sind, ist sicherlich eine gute Lösung. Mit einem Programm zur Verwaltung der Datenträger (Volume Management Software) sind die physischen Laufwerke auf beiden Seiten transparent (für die Anwendung und die Anwender) in logischen Einheiten organisiert, was bei einigen Management-Prorammen auch unabhängig von der Hardware geschehen kann. Mit der richtigen Management-Software ist die Verwaltung recht einfach.

Sowohl Replikation als auch Fernspiegelung haben ihre Vor- und Nachteile; die Spiegelung über ein SAN ist in der Regel auf Entfernungen unter 100 km beschränkt, kann aber synchron durchgeführt werden, während die Replikation auf Entfernungen von über 100 km stattfinden kann (zum Beispiel über IP), normalerweise aber asynchron abläuft – es sei denn, man kann mit Einbußen bei der Anwendungsleistung leben.

Clustering

Clustering ist eine nahtlose Methode zur Verbesserung der Möglichkeiten der Geschäftsfortsetzung im Falle eines Systemausfalls. Eine einfache Definition von Clustering ist die Verwendung mehrerer Server, Speichergeräte und redundanter Anschlüsse, die zur Außenwelt hin als ein System erscheinen.

Neben der Bereitstellung einer hohen Verfügbarkeit hat Clustering den zusätzlichen Vorteil, dass es für die Lastverteilung beziehungsweise den Lastausgleich eingesetzt werden kann. Selbstverständlich muss die jeweilige Anwendung Clustering unterstützen, was bei großen Datenbanken wie SAP und Oracle natürlich der Fall ist.

Ein Cluster kann über ein SAN bestehen, wodurch der primäre Standort von den anderen Failover-Standorten relativ weit entfernt sein kann, wenn das Unternehmen oder die Organisation entsprechend groß und geographisch verteilt ist. Über ein WAN eines öffentlichen Netzbetreibers ist auch globales Clustering möglich, wobei auch in diesem Fall die Möglichkeit besteht, den Cluster von einem einzigen Punkt aus zu überwachen und zu verwalten.

Eine typische Architektur kann so aussehen, dass sich der Haupt-Cluster am primären Standort befindet. Kann nun ein einzelner Server nicht auf einen Failover-Server umschalten, führt dies nicht zu einem Leistungsabfall und der entfernte Standort wird eventuell gar nicht genutzt, es sei denn, ein größerer Unfall führt zum Ausfall des primären Clusters.

Themenseiten: Security-Praxis

Fanden Sie diesen Artikel nützlich?
Content Loading ...
Whitepaper

Artikel empfehlen:

Neueste Kommentare 

2 Kommentare zu Es gibt immer ein Zurück: vier Disaster-Recovery-Lösungen

Kommentar hinzufügen
  • Am 6. Februar 2004 um 16:16 von Gilbert Diedrichs

    Disaster Recovery Lösungen
    Nur auf der letzte Seite geht der Autor auf die Besonderheit "Disaster" ein, insgesamt ist die Betrachtung noch zu idealistisch.
    Es beginnt damit, dass ein Unternehmen ohne Not keinen leistungsfähigen Server in Reserve vorhält – die Lieferzeit für vernünftige Server liegt ohne besonderen Vertrag im Bereich von Tagen. Dann muss ein Notfall-Szenario davon ausgehen, dass mehr als nur ein Server nicht verfügbar ist, evtl. das gesamte RZ oder Gebäude. Also muss auch das Datensicherungslaufwerk neu beschafft werden, bei Tapes mit dem gleichen Formfaktor!
    Wenn nur ein einzelner Server ausfällt entstehen bei den üblichen vernetzten Applikationen Inkonsistenzen durch die Recovery eines einzelnen Systems.
    Als Faustregel gilt, dass alles, was nicht in einem echten vollständigen Test überprüft wurde, nicht funktioniert. Aus meiner Praxis weiss ich, dass viele Datensicherungen auf Band nicht nutzbar sind, weil Dateien oder ganze Bänder nicht lesbar sind, bzw. neuere Dateien nicht in den Backup-Plan aufgenommen wurden. Das heisst, ein Notfallplan muss umfassend sein, vom GAU ausgehen und jedes Jahr mindestens einmal im Test simuliert werden.
    Insgesamt ist die Ausfallzeit selbst bei kleinen Notfällen erheblich länger als man sich vorstellt und echte Notfälle in Firmen ohne Notfallplanung führen in mehr als der Hälfte der Fälle zum Untergang des Unternehmens. innerhalb von 12 Monaten (Versicherungsaussagen).

  • Am 5. Februar 2004 um 22:46 von cst

    Es gibt immer ein Zurück: vier Disaster Recovery Lösungen
    man hat beim Lesen der Artikel absolut nicht den Eindruck das der Autor von dem Thema wirklich etwas versteht, geschweige denn Ahnung von den am Markt erhältlichen Produkten hat.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *