Clusterfähige LotusNotes Anwendung

Da gibt es noch ein paar andere Punkte:

- Zugriff auf andere Datenbanken in Script mit OpenWithFailover statt nur mit Open.
- Keine hartcodierten Servernamen (sowohl für Notes wie auch für Web)
- Periodische Agenten sollten nicht auf beiden Servern laufen, sondern immer nur auf einem

und natürlich auch alle Punkte die für Datenbanken gelten, die auf mehreren Server liegen

Bis auf den Punkt mit den Agenten hat Taurec die wichtigsten Merkmale aufgezählt.

Soll die Anwendung zusätzlich zu Notes auch webfähig sein müssen URLs für den ICM teils manuell so umgecoded werden, dass sie an definierten Einstiegspunkten immer über den ICM statt dem aktuellen Server gehen.

Ein Hauptproblem im Cluster ist, dass eine einmal geöffnete Datenbank kein Failover macht, wenn der Server ausfällt von dem sie geöffnet wurde. Der Nutzer muß die Datenbank erst schließen und wieder öffnen.
Das läßt sich etwas entschärfen, wenn man die Idee, die hinter dem ICM steht, auch für Notes nachempfindet indem man eine "Steuerdatenbank" über die Anwendung setzt, die dann beispielsweise in den Frames mit "Openwithfailover" die eigentlichen Elemente aus den richtigen Datenbanken nachlädt.

Die zuvor erwähnten Hintergrundagenten im Cluster haben 2 potentielle Fallstricke:

a) wenn der Ausführungsserver fix festgelegt ist werden sie nicht laufen, solange dieser Server down ist

b) wenn der Ausführungsserver nicht festgelegt ist (z.B. als * für beliebiger Server eingetragen wurde) verursachen sie Replizierkonflikte, da die Agenten theoretisch gleichzeitig laufen könnten oder durch Clusterreplizierung (die ja nicht nach 1 Millisekunde einsetzt) so sehr verspätet stattfindet, dass der Agent zwischenzeitlich auch auf dem/n anderen Servern gelaufen ist.

Sowohl a) als auch b) sind in einer als solche definierten clusterfähigen Anwendung nicht hinnehmbar.

Es gibt jetzt für beide Varianten eine Lösung, die i.d.R. wie folgt aussieht:

Man definiert einen der Server als Primärserver (also als den Server, der die Hintergrundänderungen normalerweise durchführt, es sei denn er ist down). Die weiteren Server werden "durchnummeriert", also mit einer Reihenfolge versehen, in der die Agentenausführung erfolgen soll, wenn alle anderen Server ausfallen.

Weiter dann wie folgt:

a) Variante MIT festgelegtem Ausführungsserver

Diese Variante ist empfehlenswert bei maximal 2 Servern im Cluster.

Der eigentliche Agent wird selbst nicht mehr automatisch getriggert sondern erhält als Trigger "Auswahl aus der Agentenliste", also er muß angestossen werden damit er läuft.

Es wird nun für jeden Server im Cluster ein weiterer Agent eingerichtet, diesmal MIT dem jeweiligen Servernamen.
Der Agent des Primäservers stößt den Hauptagenten an und alles ist schick solange dieser Server aktiv ist.
Der gleiche Agent des Sekundärservers prüft, ob der "Primärserver" vorhanden und aktiv ist.

Ist der Primärserver nicht aktiv stößt der Agent den eigentlichen Hauptagenten an, anderenfalls läßt er es bleiben, da der identische Agent vom Primärserver ja aktiv ist und das selbe tun wird.

Bei mehr als 2 Clustermitgliedern wirds hier schon problematisch.

a) Variante OHNE festgelegten Ausführungsserver

Diese Variante kann für beliebig viele Server eingerichtet werden und kommt mit 2 Agenten und einem Profil/Steuerdokument aus.

Über ein Profil- oder Steuerdokument (lieber ein echtes Dokument verwenden, da Profile gern zu Replikationsproblemen neigen) wird der Primärserver festgelegt (kann notfalls auch im Agentencode hinterlegt werden aber das wäre ja wieder hard-coded).

Der eigentliche Agent wird wie bei der Variante a) selbst nicht mehr automatisch getriggert sondern erhält als Trigger "Auswahl aus der Agentenliste", also er muß angestossen werden damit er läuft.

Der zweite Agent hat jetzt folgende Aufgaben:

- Steuerdokument holen und guggen, wer als Primäserver drin steht.
- eigenen Servernamen, auf dem die Ausführung gerade läuft gegen den Primärserver prüfen.
- wenn eigener Server gleich Primärserver dann Hauptagent starten
- wenn eigener Server ungleich Primärserver dann prüfen ob Primärserver aktiv ist
- wenn eigener Server ungleich Primärserver und Primärserver ist aktiv dann nichts tun
- wenn eigener Server ungleich Primärserver und Primärserver ist inaktiv dann den Primärserver auf sich selbst ändern und anschließend Hauptagent starten

Ein Admin kann auf die Weise auch jederzeit im laufenden Betrieb den Primärserver manuell ändern, ohne Agenten neu aktivieren zu müssen. z.B. wenn geplante Wartungen anstehen etc.

Sicherer als ein Steuerdokument und für Hochverfügbarkeit empfehlenswert ist übrigens eine "echte" Datenbank für diese Abfrage zu verwenden (DB2, Oracle, MySQL etc) da hier keine Verzögerungen durch Clusterreplizierung auftreten können. Allerdings entsteht dadurch wieder eine neue Fehlerquelle, wenn nun diese Datenbank ausfällt, weil man für den Fall als Fallback dann trotzdem das Notes-Steuerdokument vorsehen sollte.