Hochverfügbarkeit und Disaster-Recovery

Online bearbeiten

Um die Hochverfügbarkeit zu aktivieren, müssen Sie eine sekundäre Directory Sync-Installation konfigurieren, die dieselbe Konfiguration wie die primäre Installation hat, mit der Ausnahme, dass der sekundäre Directory Sync-Prozess nicht aktiv sein darf.

Der sekundäre Directory Sync-Prozess muss Zugriff auf eine aktuelle Kopie der Datei cookie.bin haben. Diese Datei ist der Synchronisationsstatus, der regelmäßig von Directory Sync gespeichert wird, wenn Active Directory oder LDAP mit Cloud Directory synchronisiert wird.

Nachdem Directory Sync das Senden jeder Reihe von Aktualisierungen an IBM® Verifyabgeschlossen hat, aktualisiert es die Cookie-Datei mit Informationen, die die letzte Aktualisierung identifizieren, die von Active Directory oder LDAP synchronisiert wurde.

Wenn der primäre Directory Sync-Prozess beim Synchronisieren eines Stapels von Änderungen inaktiv wird, muss der sekundäre Prozess gestartet werden. Der sekundäre Prozess kann entweder manuell oder von einem automatisierten Überwachungssystem gestartet werden. Auf der Basis der Informationen in der Cookiedatei fragt er Active Directory oder LDAP nach Aktualisierungen ab. Er versucht, dieselbe Serie von Änderungen zu synchronisieren, die vom primären Prozess verarbeitet wurde. Für Aktualisierungen, die bereits an Verifygesendet wurden, können Fehler protokolliert werden.

Es gibt verschiedene Möglichkeiten, um sicherzustellen, dass die Datei cookie.bin zwischen dem primären und dem sekundären Prozess synchronisiert bleibt. Das Speichern der Cookiedatei in einem gemeinsam genutzten Dateisystem ist eine mögliche Lösung, die im folgenden Beispiel beschrieben wird. Eine weitere mögliche Lösung ist die Verwendung eines Skripts OpenSSH scp und der Windows™-Option für geplante Aufgaben (Schtasks).

Für die gemeinsame Nutzung der Datei cookie.bin mithilfe eines gemeinsam genutzten Dateisystems konfigurieren Sie die Datei cookie.bin auf einem sicheren Network File System oder Laufwerk. Der primäre und der sekundäre Directory Sync-Prozess müssen Zugriff auf das gemeinsam genutzte Laufwerk haben.

Konfigurieren Sie beispielsweise die Datei cookie.bin auf einem sicheren Network File System oder Laufwerk. Der primäre und der sekundäre Directory Sync-Prozess müssen Zugriff auf das gemeinsam genutzte Laufwerk haben und müssen für dessen Verwendung konfiguriert sein. Konfigurieren Sie für die Konsistenz von op_log auch die Datei op_log auf dem gemeinsam genutzten Laufwerk. In den folgenden Beispielen hat der primäre Directory Sync-Prozess den Namen sharehost, das gemeinsam genutzte Laufwerk ist shared, und die Dateien werden in das Verzeichnis dirsync auf dem gemeinsam genutzten Laufwerk gestellt. Der UNC-Pfad zum gemeinsam genutzten Verzeichnis ist \\sharehost\shared\dirsync.

Verwenden Sie die Option cookie-file, um die Position der Datei cookie.bin zu konfigurieren. Weitere Informationen zu diesen Optionen finden Sie unter Das Cloud-Bridge-JSON-Objekt.

"cloud-bridge": {
    "cookie-file": 
"\\\\sharehost\\shared\\dirsync\\cookie.bin",
    …

Verwenden Sie die Option op-log-file, um die Position der Datei op_log zu konfigurieren.

"cloud-bridge": {
    "op-log-file": "\\\\sharehost\\shared\\dirsync\\op_log\\op_log.csv",    
…

Hinweis: In den vorherigen Beispielen müssen die Verzeichnisse \\sharehost\shared\dirsync und \\sharehost\shared\dirsync\op_log vorhanden sein. Der Directory Sync-Service muss unter einem realen Benutzeraccount ausgeführt werden, der die Berechtigung für den Zugriff auf das gemeinsam genutzte Laufwerk hat.

Der Administrator muss entweder manuell das Fehlschlagen des primären Prozesses erkennen und den sekundären Prozess starten oder er muss ein automatisches Überwachungssystem entwickeln. IBMstellt kein automatisches Überwachungs-und Failover-System bereit. Wie bereits erwähnt wurde, darf die Konfiguration eines automatischen Überwachungs- und Übernahmesystems nicht die gleichzeitige Ausführung des primären und sekundären Prozesses ermöglichen.