Notfallwiederherstellung (Disaster Recovery, DR)

Wie bei allen anderen Unternehmensanwendungen sollte Avantra in der Lage sein, im Katastrophenfall erfolgreich wiederhergestellt zu werden . Die Geschwindigkeit, mit der Sie im Katastrophenfall wiederherstellen können, hängt vollständig von den Anforderungen Ihrer Organisation ab, und Sie sollten Ihre Avantra-Umgebung so einrichten, dass sie diesen Anforderungen entspricht.

Wichtige Einflussfaktoren

RTO und RPO sind wichtige Einflussfaktoren bei Ihren Überlegungen zur Avantra-DR. Diese beiden Punkte sind deshalb so wichtig, weil sie Ihre Entscheidungen bezüglich der Architektur Ihrer Avantra-Landschaft direkt beeinflussen.

RTO

Ihr Recovery Time Objective (RTO) ist die maximal akzeptable Zeit, die für die Wiederherstellung eines Systems oder Dienstes nach einem Ausfall oder einer Störung benötigt wird. Es stellt die Zeit dar, innerhalb derer Ihre Organisation in der Lage sein sollte, den Betrieb auf ein vordefiniertes akzeptables Niveau wiederherzustellen.

Die entscheidende Frage ist hier, wie lange Ihre Organisation in einem Katastrophenszenario ohne funktionierende Avantra-Umgebung arbeiten kann.

RPO

Ihr Recovery Point Objective (RPO) ist die maximal zulässige Menge an Datenverlust, die eine Organisation im Falle einer Katastrophe oder Störung zu tolerieren bereit ist. Mit anderen Worten: RPO gibt den Zeitpunkt an, bis zu dem Daten nach einem Vorfall wiederhergestellt werden müssen.

Die entscheidende Frage, die Sie sich in Bezug auf RPO stellen müssen, ist: Wenn Sie Ihr Avantra-System wiederherstellen, wie groß darf die Datenlücke sein, die Sie in einem Katastrophenszenario akzeptieren würden?

DR-Szenarien

Für alle HA- und DR-Szenarien ist es unerlässlich, dass Ihr Avantra-Server von Anfang an mit einem DNS-Alias eingerichtet wird und dass dieser Alias sowohl für den Benutzer- als auch für den Agentenzugriff auf den Avantra-Server verwendet wird. Wenn Sie eine reine IP-Adresse oder den Hostnamen des Avantra-Servers verwenden, treten Probleme bei der Wiederherstellung der Agent-Verbindung zum Avantra-Server in einem HA- oder DR-Szenario auf.

Der vollständig qualifizierte DNS-Alias sollte im Avantra-Server unter den folgenden Konfigurationselementen (im Menü „Administration → Einstellungen“ zu finden) konfiguriert werden:

  • Avantra Master

    • Network.masterhost

  • Avantra UI

    • xanguihost

Sie sollten niemals zwei Sätze von Avantra-Diensten gleichzeitig auf derselben Datenbank ausführen, da dies zu Datenverlust führen kann.

Szenario 1 – Neuerstellung in 24 Stunden

Wenn Ihr RTO 24 Stunden beträgt und Ihr RPO 24 Stunden beträgt, können Sie bequem einen neuen Datenbankserver in der Cloud einrichten, ein Datenbank-Backup vom Vortag wiederherstellen und dann einen Snapshot Ihres Avantra-Servers vom Vortag wiederherstellen – und das alles innerhalb des 24-Stunden-RTO.

Die wichtigste Voraussetzung wäre lediglich, sicherzustellen, dass es ein externes/regionsfremdes Backup Ihrer Avantra-Datenbank und einen täglichen Snapshot des Avantra-Servers gibt, der im Katastrophenfall verfügbar ist.

Um in diesem Szenario DR aufzurufen, würden Sie Folgendes tun:

  • Erstellen Sie eine neue Datenbankinstanz und stellen Sie das Backup vom Vortag wieder her

  • Erstellen Sie einen neuen Avantra-Server auf der Grundlage eines Snapshots vom Vortag

  • Verweisen Sie den DNS-Alias für den Avantra-Server auf den neuen DR-Avantra-Server-Host

  • Konfigurieren Sie den DR-Avantra-Server neu, um die neue Datenbankinstanz in der Datei /opt/avantra/.xandira/database.cfg zu verwenden

  • Starten Sie die Avantra-Dienste auf dem DR-Server

  • Melden Sie sich mit dem lokalen Avantra-Administratorbenutzer an und aktualisieren Sie die SSO-Konfiguration (falls erforderlich)

  • Warten Sie, bis alle Avantra-Agenten wieder verbunden sind

Szenario 2 - Failover innerhalb von 1 Stunde

Wenn Ihr RTO 1 Stunde und Ihr RPO 10 Minuten beträgt, ist die Erstellung neuer Datenbanken und Server in diesem Zeitrahmen (selbst in der Cloud) nicht einfach, sodass eine alternative Einrichtung erforderlich ist.

In diesem Fall hätten Sie einen Cold-Standby-Avantra-Serverknoten in einem alternativen Rechenzentrum/einer alternativen Zone, der eine Replikation auf Speicherebene des Volumes mit den Anwendungsdaten im Dateisystem (normalerweise der Ordner /opt/avantra) zusammen mit einer Datenbankinstanz enthält, die über die Protokollübertragung (oder auf andere Weise) auf dem neuesten Stand gehalten wird.

Um DR in diesem Szenario aufzurufen, würden Sie Folgendes tun:

  • Den DNS-Alias für den Avantra-Server auf den DR-Host umleiten

  • Den DR-Avantra-Server so konfigurieren, dass er die DR-Datenbankinstanz in der Datei /opt/avantra/.xandira/database.cfg verwendet

  • Wenn Sie eine von einem Betriebssystem- oder Paketmanager bereitgestellte Java-Laufzeitumgebung verwenden, stellen Sie sicher, dass sie auf dem neuesten Stand mit der neuesten unterstützten Version ist

  • Die Avantra-Dienste Dienste auf dem DR-Server

  • Melden Sie sich mit dem lokalen Avantra-Administratorbenutzer an und aktualisieren Sie die SSO-Konfiguration (falls erforderlich)

  • Warten Sie, bis alle Avantra-Agenten wieder verbunden sind

Agentenkonnektivität während der DR

Wenn Sie den empfohlenen Ansatz eines DNS-Alias verwenden, der auf einen DR-Avantra-Server-Host umgeleitet werden kann, sollte die Agentenkonnektivität während einer Katastrophe weitgehend unbeeinträchtigt bleiben. Wenn Sie jedoch Agent-Gateways verwenden, über die Remote-Agenten mit dem Avantra-Server kommunizieren, müssen Sie Backup-Routen in Betracht ziehen, die nicht auf Knoten am selben Standort wie der ursprüngliche Avantra-Server angewiesen sind. Als Faustregel gilt, dass Sie immer eine Backup-Route haben sollten, wenn Sie Agent-Gateways in einer Umgebung verwenden, in der DR ein wichtiger Aspekt ist.

Nehmen wir ein Beispiel:

Ressourcen:

  • Normalbetrieb

    • Avantra-Server (A1)

    • Avantra-Agent, der als Gateway fungiert (G1)

    • Überwachter Server (S1)

  • DR-Betrieb

    • Avantra-Server (A2)

    • Avantra-Agent, der als Gateway fungiert (G2)

Wenn Ihr überwachtes System (S1) das Gateway (G1) verwendet, um mit dem Avantra-Server (A1) zu kommunizieren, sich das Gateway (G1) sich im selben Rechenzentrum wie der Avantra-Server (A1) befindet und die EINZIGE Route ist, über die das überwachte System (S1) mit Avantra kommunizieren kann, dann hat das überwachte System im Falle einer Katastrophe, die dieses Rechenzentrum betrifft, keine Möglichkeit, mit dem Avantra-Server (A1) zu kommunizieren, selbst wenn dieser in der DR-Umgebung (A2) wiederhergestellt wird.

Stattdessen sollten Sie eine Backup-Route konfigurieren, bei der das überwachte System (S1) optional ein sekundäres Gateway (G2) verwenden kann, das sich möglicherweise im selben Rechenzentrum wie der Disaster-Recovery-Avantra-Server (S2) befindet. Diese sekundäre Route könnte größtenteils nicht verfügbar sein (d. h. im Cold-Standby-Modus), es sei denn, sie wird benötigt, aber sie wird zumindest während eines DR-Szenarios sofort verfügbar sein, um mit der Verarbeitung des eingehenden Datenverkehrs von überwachten Systemen zu beginnen.

image::dr-route-example.png [Beispielroute wie oben beschrieben]

Abschließende Gedanken zu DR

Jede Umgebung ist anders

Je nach verwendeter Infrastruktur (Cloud, lokal, gehostet) gibt es mehrere Möglichkeiten, DR für Ihre Umgebung zu konfigurieren, und eine große Anzahl von Technologien, die Sie verwenden können. Das Ziel dieses Leitfadens besteht nicht darin, Schritt-für-Schritt-Anleitungen für eine bestimmte Technologie oder Umgebung bereitzustellen, sondern die Prinzipien zu veranschaulichen, die Sie beim Entwurf und Testen Ihrer eigenen DR-Einrichtung anwenden müssen.

Wir prüfen und beraten Sie gerne bei der Auswahl der besten Konfiguration für Ihre Umgebung, sind jedoch keine Experten für alle potenziellen HA- und DR-Technologien, die Sie einsetzen könnten. Wählen Sie daher bitte ein Set, mit dem Ihre IT-Organisation bereits vertraut ist und das sie bedienen kann. Dies wird Ihnen das Leben erleichtern und eine robustere Umgebung schaffen.

DR sollte keine Theorie sein Wir empfehlen Ihnen dringend, nach der Entwicklung Ihrer DR-Konfiguration das Aufrufen Ihrer DR-Umgebung zu testen. Nur wenn Sie einen vollständigen DR-Test durchgeführt haben, können Sie sicher sein, dass er sowohl funktioniert als auch die geschäftlichen Anforderungen erfüllt. Es kann sein, dass es beim ersten Mal nicht funktioniert, und das ist in Ordnung, solange es sich beim ersten Mal um einen Test handelt und Sie die Möglichkeit haben, daraus zu lernen.