Lotus Traveler im Failover- oder Backup-Fall

Detlev Poettgen  März 2 2011 09:49:29 AM

Lotus Traveler ist leider selbst nicht Clusterfähig und somit nicht Out-of-the-Box hochverfügbar.
Man kann nun durch vorgelagerte Systeme (Reverse Proxy & Loadbalancer) und dem Betrieb des Traveler-Servers unter VmWare, die Verfügbarkeit und Ausfallsicherheit steigern.

Aber was passiert, wenn man gezwungen ist auf der Domino Anwendungsebene ein Backup zurückzuspielen oder das Endgerät wird per Loadbalancer auf einen anderen Domino Traveler Server umgeleitet.

Nun im Backup-Fall ist die Empfehlung und an die sollte man sich halten, dass die Derby State Datenbank im Traveler Unterordner ntsdb nicht zurückgesichert werden darf. Beim Start erzeugt der Traveler-Server eine neue leere Derby State Datenbank. Die State Datenbank hält Informationen über die verbundenen Geräte und das Synchronisationsprotokoll. Die LotusTraveler.nsf stellt dem Notes Administrator lediglich eine Sicht auf einige Informationen aus der State-Datenbank zur Verfügung.

Somit verfügt der Traveler-Server nach einem Restore oder einem Failover über keine Device-Informationen in der Derby-DB. So, was passiert nun, wenn das Endgerät mit seiner vorhandenen Konfiguration eine Synchronisation durchführt? Das Gerät hat ja schon Traveler-Daten. Bleiben diese erhalten oder werden diese verworfen und neu vom Server heruntergeladen?

Die Traveler Doku spricht hier lediglich davon, dass vom Traveler Server ein Prime-Sync ausgeführt wird. Aber was bedeutet dies nun?

Ich habe diese Frage mir einmal vom Traveler-Dev-Team erläutern lassen, da widersprüchliche Information hierzu kursieren.

Im Grunde genommen ist das Ergebnis das Gleiche als wenn bei einem laufenden Traveler Server auf der Server Console "tell traveler reset " ausgeführt wird. Sämtliche Traveler Daten über das Device bis auf die User Konfiguration (was soll synchronisiert werden, wieviel Tage, Anhangsgrößen...), die in der Maildatenbank in Profildokumenten gespeichert werden, werden mit diesem Befehl in der Derby-DB gelöscht.
Lediglich die Sicherheitsinformationen (Ist ein Device gesperrt oder ein Wipe in Wartestellung) werden bei einem tell traveler reset-Command nicht entfernt, diese sind in unserem Failover Fall ebenfalls nicht vorhanden.
Der Traveler Server führt jetzt einen erneuten ersten Prime Sync aus. Dabei werden ALLE Traveler-Daten auf dem Endgerät gelöscht und eine neue Kopie der Daten vom Server übertragen. Es findet hier somit keine Form eines Deltaabgleichs statt.

Je nach Netzwerkverbindung kann dieser erste Prime Sync einige Sekunden bis zu Minuten dauern. Wenn nun im Failover Fall, alle 500 Benutzer von Traveler Server A auf Traveler Server B wechseln, wird erhebliche Last auf diesem neuen Server und auf den Mail-Servern erzeugt, da alle Geräte fast zeitgleich einen Prime-Sync erzwingen und Daten übertragen.

Daher sollte ein Failover bewusst und wirklich nur als letzte Maßnahme durchgeführt werden.

• Kommentare [6]