Administrationsserver im Cluster

Aus der Hilfe:

Zitat

The Administration Process uses administration servers to manage administrative changes that apply to databases.

Aus der Hilfe:

Zitat

The Administration Process is a program that automates many routine administrative tasks. For example, if you delete a user, the Administration Process locates that user's name in the IBM^® Lotus^®Domino^® Directory and removes it, locates and removes the user's name from ACLs, and makes any other necessary deletions for that user. If you want to delete all replicas of a database, the Administration Process finds the replicas on servers in the domain and provides an interface for deleting them.

Daraus abgeleitet ergibt sich: der Adminserver kann nicht nur nicht geclustert sein, er darf nicht geclustert sein. Wenn der Server, auf dem diese Tasks ausgeführt werden, über längere Zeit down ist, dann gibt es ganz andere Probleme, die zunächst einmal eruiert werden müssen. Wird der Server bspw. kurzzeitig für Wartungsarbeiten heruntergefahren, macht das nicht viel: der AdminP holt seins nach, sobald der Server wieder up ist.

/edit:
ich persönlich würde den Adminserver niemals runterfahren, um eben dem AdminP nicht in die Quere zu kommen. Normal sollte auf diesem Server nicht viel passieren, zum Beispiel müssen da nicht unbedingt User drauf rumkluntschen. Adminserver = Server für administrative Tätigkeiten. Anwendungs-/Mailserver = Server für User. Da das DD und die admin4.nsf ohnehin auf allen anderen Servern liegen, sollte der Datenbestand immer und überall der selbe sein; demzufolge sollten alle anderen Server gesichert werden und für den Fall, dass tatsächlich mal der Adminserver die Grätsche macht, sind sämtliche wichtigen Daten von den anderen Servern zurückholbar

Und wenn er ausfällt? Ihr habt doch sicherlich eine RFB, oder?
Ist die Anwendung so kritisch, dass nicht einmal eine halbe Stunde oder so der Master Lock Server weg sein darf, müsst ihr halt eure Infrrastruktur so ausbauen, dass genau das nicht passiert. Der Adminserver lässt sich halt nicht clustern, damit muss man leben.

Du sprichst von einem 24/7-Betrieb. Heißt das, dass weltweit auf die Repliken zugegriffen wird? In dem Fall bau eigene Infras für -bspw.- den asiatischen Raum, EMEA und Americas auf mit jeweils eigenen Master Lock Servern für die jeweiligen Repliken.

Wofür braucht ihr das Document Locking überhaupt? Geht es nur darum, Replizierkonflikte zu vermeiden? Das ließe sich auch anders lösen.

Ytria hat auch noch einen aufschlussreichen Artikel, der ein paar Details näher beleuchtet, die vllt. nicht auf den ersten Blick aus der IBM-Hilfe hervorgehen.

Davon, eigene Sperrmechanismen zu implementieren, würde ich dringend abraten. Unterm Strich versucht ihr dabei, das Rad neu zu erfinden auf die Gefahr hin, dass es hinterher nicht runder ist als das von IBM, sondern eckig. Kann man machen, man kann es auch lassen. Und wenn ihr das schon macht, macht das Rad lieber dreieckig anstatt viereckig, dann hoppelt es pro Umdrehung einmal weniger.

Geht lieber noch einmal in euch, untersucht eure Anforderungen ganz genau, untersucht die Anwendungsszenarien ganz genau, untersucht eure Infrastruktur und vor allem: untersucht noch viel genauer die Anwendung an sich.
Document Locking gibt es seit Version 6, hat sich in den Umgebungen, mit denen ich es bisher zu tun hatte (kleine mit nur wenigen Dutzend Usern, bis weltweit aufgespannte mit dick 4-stelligen Userzahlen), als hinreichend praktikabel und reliable herausgestellt. Das Feature an sich ist gut, die Implementierung einer einzelnen Anwendung kann es aber komplett verhunzen und mehr Probleme verursachen als lösen: es ist halt kein Wunderheilmittel für Infrastrukturen und Anwendungen, die suboptimal aufgesetzt und implementiert sind.