Da war ich wohl ein wenig kurz in der Beschreibung der Frage
.
Wir migrieren die Server von NT 4/Domino 4.6.7 auf Linux/Domino 5.0.11. Clients bleiben erstmal 4.6.7.
Unseren Usern ist nicht ohne weiteres zuzutrauen, per Kachel auf einen neuen Server umzuschalten & das Arbeitsumgebungsdokument zu ändern, insofern haben wir uns diverse Dinge ausgedacht, um die Migration auf neue Server (leider mit anderen DNS-Namen und IP-Adressen) möglichst transparent durchzuführen:
- Alle bekommen eine neue Desktop.dsk mit einer einzigen Kachel (gemeinsame Portaldatenbank mit Links auf die neuen Server).
- StartupDB in der Notes.ini weist auf die neue Portaldatenbank.
- Arbeitsumgebungsdokument wird beim Aufruf der Portaldatenbank durch ein Datenbankskript geändert.
Soweit, sogut.
Meine Aufgabe ist es zZ ein Fallbackkonzept zu entwickeln, sprich, wie kommt man zur Not zurück auf die alten 4er Server, wenn die neuen Geräte nicht laufen. Da dies im laufenden Betrieb passieren muss, kann ich nicht einfach den umgekehrten Weg gehen, die Desktop.dsks auszutauschen - wenn der User angemeldet ist, sind die gelockt, und was passiert, wenn ich die dem Notes Client wegnehme während er läuft möchte ich gar nicht wissen.
Die eleganteste Lösung scheint mir zu sein, alte & neue Server in einen Cluster zu hängen und die Portaldatenbank auf beiden als Replik anzulegen. Wenn ich die Benutzer wieder auf die alten Server umleiten möchte, setze ich die neuen Server halt auf Busy (oder fahre sie 'runter), und der Clusterfailover macht den Rest.
Der Hinweg wäre genause denkbar, indem ich die neuen Server als Failover-Ziel verwende.
Nur dafür müssen 5er und 4.6er Server in einem Cluster zusammen laufen.
Soweit einsichtig?