Disaster Recovery – Überblick

Disaster Recovery-Lösung

Nachdem Sie den Disaster Recovery-Prozess zwischen einem aktiven Standort und einem Standby-Standort konfiguriert und eingeleitet haben, wird die asynchrone Replikation von MySQL und PgSQL-Datenbank zwischen den Standorten eingeleitet. Konfigurations- und RRD-Dateien werden über SCP in definierten Zeitintervallen auf den Standby-Standort gesichert.

Der Disaster Recovery-Prozess führt keine Echtzeitreplikation der Cassandra-Datenbank zum Standby-Standort durch oder überwacht den Cassandra-Service, der auf den Junos Space-Knoten ausgeführt wird.

Während des normalen Betriebs der Disaster Recovery-Lösung werden die GUI- und API-Benutzer sowie die verwalteten Geräte für alle Netzwerkmanagement-Services mit dem aktiven Standort verbunden. Die Konnektivität zwischen dem Standby-Standort und den verwalteten Geräten ist deaktiviert, solange der aktive Standort funktionsfähig ist. Wenn der aktive Standort aufgrund einer Katastrophe nicht mehr verfügbar ist, wird der Standby-Standort in Betrieb genommen. Zu diesem Zeitpunkt werden alle Services am Standby-Standort gestartet und die Konnektivität zwischen dem Standby-Standort und den verwalteten Geräten hergestellt.

Abbildung 1 zeigt die Disaster Recovery-Lösung.

Abbildung 1: Disaster Recovery-Lösung

Der Überwachungsprozess für die Notfallwiederherstellung wird am VIP-Knoten der aktiv- und Standby-Standorte eingeleitet, um den Zustand des Replikationsprozesses zu überwachen und zu erkennen, wenn der Remote-Standort ausfällt. Der Disaster Recovery Watchdog am lokalen Standort prüft, ob Konnektivitätsprobleme zwischen beiden Standorten auftreten (durch Pingen der Knoten am Remote-Standort) und ob die Standorte mit Arbitergeräten verbunden sind (wenn Sie den Geräte-Schiedsalgorithmus verwenden).

Der Disaster Recovery Watchdog an einem Standort führt die folgenden Aufgaben aus, um die Konnektivität mit den Remote- und Arbitergeräten zu bestätigen:

• Ping der VIP-Adresse des Remote-Standorts in einem regelmäßig konfigurierbaren Intervall. Der Standardwert für das Intervall ist 30 Sekunden.

  Erwarten Sie für jeden Ping eine Antwort innerhalb eines konfigurierbaren Timeout-Intervalls. Der Standardwert für das Timeout-Intervall ist 5 Sekunden.

• Wenn der lokale Standort innerhalb des Timeout-Intervalls keine Antwort erhält, fordert der Notfallwiederherstellungs-Watchdog den Ping für eine konfigurierbare Anzahl von Malen wieder. Standardmäßig beträgt die Anzahl der Wiederholungen 4.

• Wenn alle Wiederholungen fehlschlagen, kommt der Disaster Recovery Watchdog am lokalen Standort zu dem Schluss, dass die VIP-Adresse des Remote-Standorts nicht erreichbar ist.

  Der Disaster Recovery Watchdog kommt jedoch nicht zu dem Schluss, dass der Remote-Standort ausfällt, weil der Remote-Standort aufgrund eines lokalen Switchovers möglicherweise über die VIP-Adresse in einen Standby-Knoten umgestellt wird.

• Um die Möglichkeit eines VIP-Adressen-Switchovers in Betracht zu ziehen, pingt der Disaster Recovery Watchdog die IP-Adressen der anderen Load-Balancer-Knoten am Remote-Standort an. Wenn der Ping an einen der Knoten eine Antwort erhält, kommt der Disaster Recovery Watchdog zu dem Schluss, dass der Remote-Standort noch eingerichtet ist.

  Wenn der Ping an die Knoten fehlschlägt, kommt der Disaster Recovery Watchdog nicht zu dem Schluss, dass der Remote-Standort ausfällt. Stattdessen berücksichtigt der Notfallwiederherstellungswächter die Möglichkeit von Konnektivitätsproblemen zwischen den Standorten. Beide Standorte versuchen, aktiv zu werden.

• Um zu verhindern, dass beide Standorte aktiv werden, initiiert der Disaster Recovery Watchdog den Geräteschiedsalgorithmus und bestimmt, ob ein Failover erforderlich ist.

  Ein Failover wird nur eingeleitet, wenn der Prozentsatz der Arbitergeräte, die vom aktiven Standort verwaltet werden, unter den Failover-Schwellenwert fällt. Dann wird der aktive Standort zum Standby-Standort und der Standby-Standort zum aktiven Standort.

  Wenn der Prozentsatz der Arbiter-Geräte über dem Failover-Schwellenwert liegt, bleibt der Standby-Standort standby und der aktive Standort bleibt aktiv. Der Prozentsatz der Arbiter-Geräte, die vom aktiven Standort verwaltet werden, ist konfigurierbar und der Standardwert beträgt 50 %.

Das Failover wird eingeleitet, wenn die folgenden Bedingungen erfüllt sind:

• Der Standby-Standort kann die VIP-Adresse des aktiven Standorts oder die Knoten-IP-Adressen anderer Load-Balancer-Knoten am aktiven Standort nicht erreichen.

• Der Prozentsatz der arbiter-Geräte, die vom aktiven Standort verwaltet werden, liegt unter dem Failover-Schwellenwert.

Weitere Informationen zum Geräteschiedsalgorithmus finden Sie unter Fehlererkennung durch Verwendung des Geräteschiedsalgorithmus.

Voraussetzungen für die Konfiguration von Disaster Recovery

Sie müssen sicherstellen, dass Ihre Junos Space-Installation die folgenden Voraussetzungen erfüllt, bevor Sie die Disaster Recovery konfigurieren:

• Der Junos Space-Cluster am primären oder aktiven Standort (der ein einzelner oder mehrere Knoten sein kann) und der Cluster am Remote- oder Standby-Standort (der ein einzelner oder mehrere Knoten sein kann) müssen genau auf die gleiche Weise eingerichtet werden, mit allen gleichen Anwendungen, Geräteadaptern, Konfigurationen derselben IP-Familie, Und so weiter.

• Beide Cluster sollten mit SMTP-Serverinformationen aus der Junos Space-Benutzeroberfläche konfiguriert werden. Weitere Informationen finden Sie unter Verwalten von SMTP-Servern. Diese Konfiguration ermöglicht es den Clustern am aktiven Standort und am Standby-Standort, den Administrator per E-Mail zu benachrichtigen, wenn die Replikationen fehlschlagen.

Konnektivitätsanforderungen für die Konfiguration von Disaster Recovery

Sie müssen sicherstellen, dass die Disaster Recovery-Lösung die folgenden Konnektivitätsanforderungen erfüllt, bevor Sie die Disaster Recovery konfigurieren:

• Layer 3-Konnektivität zwischen den Junos Space-Clustern an den Aktiv- und Standby-Standorten. Das bedeutet:

  • Jeder Knoten in einem Cluster kann die VIP-Adresse des anderen Clusters erfolgreich anpingen

  • Jeder Knoten in einem Cluster kann SCP verwenden, um Dateien zwischen aktiv- und Standby-Standorten zu übertragen.

  • Datenbankreplikation über die beiden Cluster hinweg ist über die TCP-Ports 3306 (MySQL-Datenbankreplikation) und 5432 (Replikation der Nachbildung von Datenbanken) möglich.

  • Die Bandbreite und Latenz der Verbindung zwischen den beiden Clustern sind so, dass die Datenbankreplikation in Echtzeit erfolgreich ist. Obwohl die genaue erforderliche Bandbreite von der übertragenen Datenmenge abhängt, empfehlen wir mindestens eine 100-Mbit/s-Bandbreitenverbindung mit einer Latenz von weniger als 150 Millisekunden.

• Unabhängige Layer 3-Konnektivität zwischen jedem Cluster und verwalteten Geräten

• Unabhängige Layer 3-Konnektivität zwischen jedem Cluster und einer GUI oder NBI-Clients

Informationen zum Einrichten des Disaster Recovery-Prozesses finden Sie unter Konfigurieren des Disaster Recovery-Prozesses zwischen einem aktiven und einem Standby-Standort.

Notfallwiederherstellung Watchdog

Der Disaster Recovery Watchdog, auch bekannt als DR-Watchdog, ist ein integrierter Junos Space-Mechanismus zur Überwachung der Integrität der Datenreplikation (MySQL-Datenbank, PgSQL-Datenbank, Konfigurationsdateien und RRD-Dateien) an verschiedenen Standorten. Der Disaster Recovery Watchdog überwacht auch den gesamten Zustand der Disaster Recovery-Einrichtung, initiiert ein Failover vom aktiven zum Standby-Standort, wenn der aktive Standort ausfällt, und ermöglicht es dem Standby-Standort, die Netzwerkmanagement-Services mit minimaler Unterbrechung wieder aufzunehmen. Eine Instanz des Disaster Recovery Watchdogs wird am VIP-Knoten an beiden Standorten initiiert, wenn Sie den Disaster Recovery-Prozess starten.

Der Disaster Recovery Watchdog bietet die folgenden Services:

• Herzschlag
• mysqlMonitor
• pgsqlMonitor
• Filemonitor
• ArbiterMonitor
• configMonitor
• ServiceMonitor
• Benachrichtigung

Fehlererkennung mithilfe des Geräteschiedsalgorithmus

Ein Geräteschiedsalgorithmus wird verwendet, um Fehler an einem Standort zu erkennen. Eine Liste der hoch erreichbaren Geräte, auf denen Junos OS ausgeführt und von der Junos Space-Plattform verwaltet wird, wird als Arbitergeräte ausgewählt. Wir empfehlen, dass Sie Arbiter-Geräte basierend auf den folgenden Kriterien auswählen:

• Sie müssen die Arbiter-Geräte über von Junos Space initiierte SSH-Verbindungen von beiden Standorten erreichen können. Wählen Sie keine Geräte aus, die geräteinitiierte Verbindungen zur Junos Space Platform verwenden.

• Sie müssen in der Lage sein, Arbitergeräte von beiden Disaster Recovery-Standorten anpingen zu können.

• Sie müssen arbiter-Geräte auswählen, die mit der Junos Space-Plattform verbunden bleiben oder seltener neu gestartet oder heruntergefahren werden, da dies sich auf die Ergebnisse des Geräteschiedsalgorithmus auswirken kann. Wenn Sie vorhersehen, dass bestimmte Arbitergeräte während eines Teils ihres Lebens offline sind, vermeiden Sie die Auswahl dieser Geräte.

• Sie müssen Arbitergeräte von verschiedenen geografischen Standorten auswählen, um sicherzustellen, dass ein Problem im Verwaltungsnetzwerk an einem Standort nicht alle Arbitergeräte von Ihren Standorten aus unerreichbar macht.

• Sie können NAT- und Ww Junos OS-Geräte nicht als Arbitergeräte auswählen.

Der Geräteschiedsalgorithmus am aktiven Standort verwendet Ping, um eine Verbindung zu Arbitergeräten vom aktiven Standort aus herzustellen. Der Geräteschiedsalgorithmus am Standby-Standort meldet sich über SSH-Verbindungen bei den Arbitergeräten an, indem er die Anmeldeinformationen aus der Datenbank der Junos Space Platform verwendet. Im Folgenden sind die Workflows des Geräte-Schiedsalgorithmus an den aktiv- und Standby-Standorten.

Am aktiven Standort:

1. Ping aller ausgewählten Arbitergeräte.

2. Berechnen Sie den Prozentsatz der Arbitergeräte, die pinget werden können.

3. Prüfen Sie, ob der Prozentsatz der Arbitergeräte, die pinget werden können, über oder mit dem konfigurierten Wert des Failover-Schwellenwerts identisch ist.

   • Wenn der Prozentsatz der angeschlossenen Arbitergeräte über dem konfigurierten Wert des Failover-Schwellenwerts (failureDetection.threshold.failover-Parameter im Watchdog-Abschnitt der Disaster Recovery API) liegt, wird ein Failover nicht eingeleitet, da der aktive Standort einen Großteil der Arbitergeräte verwaltet.

   • Wenn der Prozentsatz der Arbitergeräte unter dem konfigurierten Wert des Failover-Schwellenwerts liegt, wird ein Failover eingeleitet (wenn das automatische Failover aktiviert ist) und der aktive Standort wird standby. Wenn das automatische Failover deaktiviert ist, bleibt der aktive Standort aktiv.

Am Standby-Standort:

1. Melden Sie sich über SSH-Verbindungen bei Arbitergeräten an.

2. Führen Sie einen Befehl auf jedem Arbitergerät aus, um die Liste der SSH-Verbindungen zu einem beliebigen Knoten (verwaltet durch den Knoten) am aktiven Standort abzurufen.

3. Berechnen Sie den Prozentsatz der Arbiter-Geräte, die von der aktiven Site verwaltet werden.

4. Berechnen Sie den Prozentsatz der Arbiter-Geräte, die nicht über SSH-Verbindungen erreicht werden können.

   • Wenn der Prozentsatz der arbiter-Geräte, die vom aktiven Standort verwaltet werden, über dem konfigurierten Wert des Failover-Schwellenwerts liegt oder gleicht, ist ein Failover nicht erforderlich, da der aktive Standort immer noch einen Großteil der Arbitergeräte verwaltet.

   • Wenn der Prozentsatz der arbiter-Geräte, die vom aktiven Standort verwaltet werden, unter dem konfigurierten Wert des Failover-Schwellenwerts liegt, kommt der Watchdog für die Notfallwiederherstellung zu dem Schluss, dass ein Failover erforderlich sein könnte.

5. Da jedoch die Geräte, die vom Standby-Standort aus nicht erreichbar sind, vom aktiven Standort aus verbunden und verwaltet werden können, geht der Standby-Standort davon aus, dass alle Arbitergeräte, die nicht erreicht werden können, vom aktiven Standort verwaltet werden, und berechnet den neuen Prozentsatz der geräte, die vom aktiven Standort verwaltet werden.

   • Wenn der Prozentsatz der von der aktiven Site verwalteten Geräte unter dem Schwellenwert für die Anpassung verwalteter Geräte liegt (failureDetection.threshold.adjustManaged Parameter im Watchdog-Abschnitt der Disaster Recovery API, der Standardwert ist 50 %), bleibt der Standby-Standort standby. Standardmäßig muss der Schwellenwert für die Anpassung verwalteter Geräte unter dem Failover-Schwellenwert liegen.

   • Wenn der neue Prozentsatz, der durch Hinzufügen der vom aktiven Standort verwalteten Geräte und Arbitergeräte, die nicht erreicht werden können, unter dem Failover-Schwellenwert liegt, kommt der Disaster Recovery Watchdog zu dem Schluss, dass ein Failover eingeleitet werden muss.

     Wenn das automatische Failover aktiviert ist, initiiert der Standby-Standort den Prozess der Aktivierung. Wenn das automatische Failover deaktiviert ist, erfolgt kein Failover.

Wenn Sie das automatische Failover deaktiviert haben oder die Funktion aufgrund von Konnektivitätsproblemen deaktiviert wurde, müssen Sie am Standby-Standort ausgeführt jmp-dr manualFailover werden, um die Netzwerkverwaltungsservices vom Standby-Standort aus wieder aufzunehmen.

Fehlererkennung mithilfe der benutzerdefinierten Skripte zur Fehlererkennung

Zusätzlich zur Verwendung des Geräte-Schiedsalgorithmus können Sie benutzerdefinierte Fehlererkennungsskripte (sh, bash, Perl oder Python) erstellen, um zu entscheiden, wann oder ob ein Failover zum Standby-Standort erfolgt. Benutzerdefinierte Fehlerskripte rufen den jmp-dr api v1 config ––include Befehl auf und rufen die Disaster Recovery-Konfiguration und den Status der Disaster Recovery Watchdog-Services ab. Die Disaster Recovery-Konfiguration und der Status der Disaster Recovery Watchdog-Services an einem Standort sind in verschiedenen Abschnitten organisiert. Tabelle 1 listet diese Abschnitte auf.

Verwenden Sie die Option -- <abschnittsname einschließen>, um die Details eines Abschnitts anzuzeigen, oder verwenden Sie die Details des Abschnitts im benutzerdefinierten Skript zur Fehlererkennung.

{ 
"core": {
  "peerVip": "10.155.90.210",
  "adminPass": "ABCDE12345",
  "scpTimeout": 120,
  "peerLoadBalancerNodes": "10.155.90.211",
   "peerBusinessLogicNodes": "10.155.90.211",
   "peerDeviceMgtIps": "10.155.90.211"}
}

{ "mysql": {
   "hasDedicatedDb": false,
   "peerVip": "10.155.90.210",
   "peerNodes": "10.155.90.211"
   }
}

{ "psql": {
  "hasFmpm": false,
  "peerFmpmVip": "10.155.90.210",
  "peerNodes": "10.155.90.211"
  }
}

{ "file": {
  "backup": {
    "maxCount": 3,
    "hoursOfDay": "*",
    "daysOfWeek": "*" },
  "restore": {
    "hoursOfDay": "*",
"daysOfWeek": "*" }
  }
}

{ "watchdog": {
  "heartbeat": {
"retries": 4,
"timeout": 5,
"interval": 30 },
  "notification": {
    "email": "abc@example.com",
    "interval": 3600 },
  "failureDetection": {
"isCustom": false,
"script": "/var/cache/jmp-geo/watchdog/bin/arbitration",
    "threshold": {
      "failover": 0.5,
      "adjustManaged": 0.5,
      "warning": 0.7 },
      "waitDuration": "8h",
      "arbiters": [{
        "username": "user1",
        "password": "xxx",
        "host": "10.155.69.114",
        "port": 22,
        "privateKey": ""
      }]
}
  }
}

{ "deviceManagement": {
   "peerNodes": "10.155.90.211",
   "nodes": "10.155.90.222",
”ip”: “10.155.90.228,eth0”
 }
}

{ "states": {
    "arbiterMonitor": {
      "progress": "idle",
      "msg": {
        "service": "arbiterMonitor",
        "description": "",
        "state": true,
        "force": false,
        "progress": "unknown",
        "payload": {
          "code": 0
        },
        "time": "2015-07-18T22:18:55+00:00"
      },
"service": {}
   },

    "configMonitor": {
      "progress": "idle",
      "msg": {
        "service": "configMonitor",
        "description": "",
        "state": true,
        "force": false,
        "progress": "unknown",
        "payload": {
          "code": 0
        },
        "time": "2015-07-18T22:19:15+00:00"
      },"service": {}
    },

    "fileMonitor": {
      "progress": "idle",
      "msg": {
        "service": "fileMonitor",
        "description": "",
        "state": true,
        "force": false,
        "progress": "unknown",
        "payload": {
          "code": 0
        },
        "time": "2015-07-18T22:18:59+00:00"
      },
"service": {}
    },

    "heartbeat": {
      "progress": "unknown",
      "msg": {
        "service": "heartbeat",
        "description": "",
        "state": true,
        "force": false,
        "progress": "unknown",
        "payload": {
          "localFailover": false
        },
        "time": "2015-07-18T22:17:49+00:00"
      },
"service": {
        "booting": false,
        "bootEndTime": null,
        "waitTime": null,
        "automaticFailover": false,
        "automaticFailoverEndTime": "2015-07-18T07:41:41+00:00"
      }
    },

"mysqlMonitor": {
      "progress": "idle",
      "msg": {
        "service": "mysqlMonitor",
        "description": "",
        "state": true,
        "force": false,
        "progress": "unknown",
        "payload": {
          "code": 0
        },
        "time": "2015-07-18T22:19:09+00:00"
      },
"service": {}
    },

    "pgsqlMonitor": {
      "progress": "unknown",
      "msg": {
        "service": "pgsqlMonitor",
        "description": "Master node pgsql in active or standby site maybe CRASHED. Pgsql replication is in bad status. Please manually check Postgresql-9.4 status.",
        "state": false,
        "force": false,
        "progress": "unknown",
        "payload": {
          "code": 1098
        },
        "time": "2015-07-18T22:18:27+00:00"
      },"service": {}
    },

 
    "serviceMonitor": {
      "progress": "running",
      "msg": {
        "service": "serviceMonitor",
        "description": "",
        "state": true,
        "force": false,
        "progress": "unknown",
        "payload": {
          "code": 0
        },
        "time": "2015-07-18T22:19:30+00:00"
      },
      

"service": {}
    }
  }
}                                      

Die Ausgabe des benutzerdefinierten Skripts informiert den Notfallwiederherstellungs-Watchdog, ob ein Failover zum Standby-Standort erforderlich ist. Der Disaster Recovery Watchdog interpretiert die Ausgabe des Skripts im JSON-Format. Im Folgenden ist ein Beispiel:

Tabelle 2 beschreibt die Details der Skriptausgabe.

Schritte zur Konfiguration von Disaster Recovery

So konfigurieren Sie die Disaster Recovery zwischen einem aktiven Standort und einem Standby-Standort:

1. Stoppen Sie den Disaster Recovery-Prozess, der bei früheren Versionen konfiguriert wurde, bevor Sie auf junos Space Network Management Platform Version 15.2R1 aktualisieren. Weitere Informationen zum Upgrade-Vorgang finden Sie im Abschnitt Upgrade-Anweisungen in den Versionshinweisen 15.2R1 der Junos Space Network Management-Plattform.

   Weitere Informationen zum Stoppen des Disaster Recovery-Prozesses, der in früheren Versionen konfiguriert wurde, finden Sie unter Stoppen des Disaster Recovery-Prozesses auf junos Space Network Management Platform Version 14.1R3 und früher.

   Sie müssen diesen Schritt nicht für eine saubere Installation der Junos Space Network Management-Plattform Version 15.2R1 durchführen.

2. Richten Sie SMTP-Server an beiden Standorten über die Junos Space-Benutzeroberfläche ein, um Benachrichtigungen zu erhalten. Weitere Informationen finden Sie unter Verwalten von SMTP-Servern im Junos Space Network Management Platform Management Platform Workspaces Benutzerhandbuch.

3. Kopieren Sie die Datei mit der Liste der Arbitergeräte (wenn Sie den Geräteschiedsalgorithmus verwenden) oder das benutzerdefinierte Skript zur Fehlererkennung an den entsprechenden Speicherort am aktiven Standort. Stellen Sie sicher, dass alle Arbiter-Geräte am aktiven Standort erkannt werden. Weitere Informationen finden Sie unter Übersicht über Geräteerkennungsprofile im Benutzerhandbuch junos Space Network Management Platform Workspaces.

4. Konfigurieren Sie die Konfigurationsdatei für die Notfallwiederherstellung am aktiven Standort. Die Disaster Recovery-Konfiguration umfasst SCP-Einstellungen zur Synchronisierung der Konfiguration und RRD-Dateien, Herzschlageinstellungen, Benachrichtigungseinstellungen und den Mechanismus zur Fehlererkennung.

5. Konfigurieren Sie die Konfigurationsdatei für die Notfallwiederherstellung am Standby-Standort. Die Disaster Recovery-Konfiguration umfasst SCP-Einstellungen zur Synchronisierung der Konfiguration und RRD-Dateien, Herzschlageinstellungen und Benachrichtigungseinstellungen.

6. Starten Sie den Disaster Recovery-Prozess vom aktiven Standort aus.

   Weitere Informationen finden Sie unter Konfigurieren des Disaster Recovery-Prozesses zwischen einem aktiven und einem Standby-Standort.

Notfallwiederherstellungsbefehle

Sie verwenden die Befehle zur Notfallwiederherstellung, die in Tabelle 3 aufgeführt sind, um Disaster Recovery-Standorte zu konfigurieren und zu verwalten. Sie müssen diese Befehle am VIP-Knoten des Standorts ausführen. Sie können die --help Option mit diesen Befehlen verwenden, um weitere Informationen anzuzeigen.