Administrationsserver im Cluster

  • Administrationsserver im Cluster

    Guten Morgen,

    wir möchten im Cluster (2 Server) mit Dokumentsperrung arbeiten. Allerdings muss dann ein Administrationsserver für die Datenbank angegeben werden. Wie kann ich dann die Ausfallsicherheit im Cluster erhalten ? Trotz intensiver Suche habe ich nirgendwo eine Information gefunden, wie beim Ausfall des Administrationsservers der zweite Clusterserver automatisch diese Funktion übernehmen kann. Eine Servergruppe kann nicht als Administrationsserver eingetragen werden ...

    Herzlichen Dank im voraus

    Karl
  • Aus der Hilfe:
    The Administration Process uses administration servers to manage administrative changes that apply to databases.

    Aus der Hilfe:
    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
    Life is not a journey to the grave with the intention of arriving safely in a pretty and well-preserved body, but rather to skid in broadside, thoroughly used up, totally worn out, and loudly proclaiming "Wow, what a ride!!! :evil:
    Beschleunigung ist, wenn die Tränen der Ergriffenheit waagrecht zum Ohr hin abfliessen - Walter Röhrl
  • Hallo RockWilder,

    danke für den Hinweis, den Adminserver separat zu halten - das ist immerhin eine Idee. Wenn aber der separate Server ausfällt (halt ohne "gezieltes" Herunterfahren), haben wir trotzdem keine Ausfallsicherheit für die Anwendung, die im 24/7-Betrieb läuft, aber die Dokumentsperrung benötigt.

    Offensichtlich bekommen wir das mit Domino so auch nicht hin - oder wir implementieren eigene Sperrmechanismen.

    Liebe Grüße

    Karl
  • 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.
    Life is not a journey to the grave with the intention of arriving safely in a pretty and well-preserved body, but rather to skid in broadside, thoroughly used up, totally worn out, and loudly proclaiming "Wow, what a ride!!! :evil:
    Beschleunigung ist, wenn die Tränen der Ergriffenheit waagrecht zum Ohr hin abfliessen - Walter Röhrl