Das Notes Forum

Domino 9 und frühere Versionen => ND8: Administration & Userprobleme => Thema gestartet von: Tode am 05.07.12 - 12:00:47

Titel: Cluster "feiner" steuern
Beitrag von: Tode am 05.07.12 - 12:00:47
Wir richten hier gerade einen Fallback- Cluster über zwei Lokationen ein (HA- Configuration).
Personen von Lokation A sollen im Normalfall auf Cluster A arbeiten, Personen von Lokation B auf Cluster B.

Nur im Fall eines Ausfalls sollen die jeweiligen Personen auf den anderen Clusterpartner "failovern".

Das heisst: Ich muss auf jeden Fall den Threashold auf 0 setzen, damit die Server nie "Busy" sind.
Dann setze ich den jeweiligen Mail- Home- Server der User auf Ihren Lokationsserver, denn das ist (wenn ich mich richtig erinnere) der Server (zumindest fürs Mailfile) den die Benutzer am Morgen nach Client- Neustart zuerst fragen.

Aber kann ich sonst noch an irgendwelchen Parametern drehen, dass die Benutzer "im Normalfall" auf Ihren Servern arbeiten?
Mir wären keine entsprechenden Konfigurationen bekannt und ich habe auch in der Admin- Hilfe nichts dergleichen gefunden.

Irgendwelche Tipps / gute Lektüre?

Thanx

EDIT: Diesen Link (http://www-01.ibm.com/support/docview.wss?rs=899&uid=swg21236909) mit dem entsprechenden Feature- Request habe ich gefunden... hilft aber nix, da nie beantwortet
Titel: Re: Cluster "feiner" steuern
Beitrag von: MCPvsTron am 05.07.12 - 12:57:41
Hallo Tode,

kurze Antwort: Leider nein, zumindest ist mir nichts bekannt. Das ist meiner Ansicht nach auch noch ein Problem der desktop.ndk da hier ja die Kachel der zuletzt benutzten Replik immer als erste gezogen wird. Was sich so leider auch durch die Bookmarks zieht.
Bis auf die eigenen Maildatenbank wo du das wie beschrieben beeinflussen kannst , kenne ich keine weiteren Wege.
Vielleicht haben Clientverwaltungstools von Drittherstellern da Möglichkeiten.

Viele Grüße
Christian
Titel: Re: Cluster "feiner" steuern
Beitrag von: Tode am 05.07.12 - 13:24:02
Das hatte ich befürchtet... Danke für die Rückmeldung. VIelleicht fällt ja jemand anderem noch was ein, was nicht Client- Genie, Marvel- Client oder DesktopManager beinhaltet...

Ja, die unsägliche desktop.ndk mit Ihrer Kachelreihenfolge...
Das heisst: Ich muss einen "automatischen" Failover in alle Anwendungen manuell einbauen...

Weitere Ideen?
Titel: Re: Cluster "feiner" steuern
Beitrag von: RZLT am 05.07.12 - 15:08:16
Hallo Tode,
das hab ich grad gefunden, evtl. findest Du da ja noch was, was Dir weiterhilft.

http://www.ibm.com/developerworks/lotus/library/domino85-performance/

Bin nur mal so drübergeflogen, ist eigentlich ein Artikel über die Verbesserungen der Serverauslastung bei 8.5
Titel: Re: Cluster "feiner" steuern
Beitrag von: Pfefferminz-T am 05.07.12 - 21:26:22
Hi,

habe das noch nie ausprobiert und ist vielleicht ein Schuß ins Blaue aber könnte man da auf dem Zweitserver mit "server_restricted=" arbeiten? Ich weiss nicht, ob die Cluster-Replikation dann noch funktionieren würde. Standard-Replikation müsste vom Zweitserver angestossen werden und bei neuen Repliken wird zwar der Stumpf angelegt (-> Replikation vom Zweitserver anstossen).

Ab 8.5.2FP3 gibt es zusätzliche Parameter (3 und 4), so dass bei einer lokalen Replik vom Client auch die Replikation nicht mehr mehr angestossen werden kann.

Als zweite Möglichkeit würde ich einen Load-Balancer sehen, über den alle Anfragen an die Server gehen müssen und Server 2 ist halt dann immer "malade".

Gegenpunkt bei beiden ist natürlich, dass eine manuelle Interaktion notwendig ist. Aber sonst kenne ich auch nur den Treshold bzw. die Client-Tools...

Der im Enhancement request aufgeführte SPR zieht sich schon seit Version 6.5 und wurde bisher mangels "Gewichtung" (zu wenig PMRs mit zu wenig Lizenzen zu diesem Enhancement request) nicht umgesetzt. Bei manchen Dingen kann ich auch nur den Kopf schütteln...

Grüsse,
Thorsten
Titel: Re: Cluster "feiner" steuern
Beitrag von: Tode am 05.07.12 - 21:55:25
Wenn ich möchte, dass immer alle user auf EINEM server arbeiten und nur im Ausfall wechseln, ist das ja kein Problem. (bitte nicht mit server_restricted steuern, denn das erfordert im failover immer einen eingriff des admins, sondern mit server_availability_threshold=0 auf dem dem fallback und =100 auf dem Hauptserver)
Aber ich möchte, dass die Schweizer User auf dem schweizer server arbeiten und die deutschen user auf dem deutschen. Und nur wenn einer der server ausfällt, sollen die user temporär switchen, bis ihr jeweiliger home- server wieder da ist... Also jeder arbeitet auf dem für ihn "günstigsten" Server (da physikalisch und Netztechnisch näher/schneller), nicht auf dem für das Cluster "günstigsten" (da weniger ausgelastet). Und eine solche config sieht ibm imho nicht vor (oder ich habe sie noch nicht gefunden)
@Tom: habe da leider nix gefunden, was mir geholfen hätte...
Titel: Re: Cluster "feiner" steuern
Beitrag von: RZLT am 06.07.12 - 08:10:05
Servus Torsten,

kennst Du das Redbook "Optimizing Lotus Domino Administration" ??
Da sind erstmal nur grundlegende Hinweise drin, im Kapitel Clustering wird dann noch auf diese Seite verwiesen:
http://www-10.lotus.com/ldd/dominowiki.nsf/dx/3.5_Server_Clustering_Options

Habs mal drangehängt, evtl. hilft Dir das ja noch weiter.
Titel: Re: Cluster "feiner" steuern
Beitrag von: Pfefferminz-T am 06.07.12 - 09:39:07
Oops, hatte den nicht unwichtigen Satz "User aus A arbeiten auf Server A, User aus B auf Server B" überlesen - dann ist meine obige Antwort natürlich hinfällig.

Nein, da kenne ich keine Möglichkeit, dass mit Domino-Standard abzudecken. Der Enhancement Request (bzw. der SPR) würde das auch nur teilweise abdecken, da es dabei nur um das "Zurückschwenken" der Nutzer geht.

Denkbar wäre dann für mich nur noch der Einsatz eines "IP sprayer" in beiden Lokationen, der vor dem jeweiligen Server steht. Alle Anfragen müssen dann zwingend netzwerk-technisch über den IP Sprayer geleitet werden. Der IP Sprayer würde den fernen Server für die jeweilige Lokation als "nicht verfügbar" kennzeichnen und alle Anfragen an den lokalen Server weiterleiten. Umschaltung wäre dann aber auch manuell oder der Sprayer besitzt soviel Logik, dass er bei einem Ausfall des lokalen Servers automatisch die Anfragen auf den fernen Server umleitet.

Grüsse
Titel: Re: Cluster "feiner" steuern
Beitrag von: Tode am 06.07.12 - 09:58:59
Sehr interessantes Dokument, sehr interessanter Link, aber leider enthalten Sie keine diesbezüglichen Informationen. Trotzdem danke!

@Pfefferminz-T: Ja, das wäre ne Möglichkeit... Ich denke, wir werden uns mal an einer Eigenentwicklung probieren, die feststellt, wenn der Server wieder da ist, und dann automatisiert die User "umleitet". Ansätze haben wir schon ein paar:

evtl. versuchen wir das über die DenyAccessGroups dynamisch zu steuern (müssen prüfen, wie sich das in nem Cluster auswirkt), oder in den Anwendungen selbst (dann ist nur ein öffnen langsam, alle weiteren wieder OK). Eine andere Möglichkeit wäre, die cluster.ncf zu manipulieren (obwohl ich da die Chancen als eher gering ansehe, weil die ja nur beim Client beenden gespeichert und beim Clientstart gelesen wird)
Titel: Re: Cluster "feiner" steuern
Beitrag von: stoeps am 06.07.12 - 18:00:53
Hi Thorsten,

server_restricted würde ich bei Clustern immer vermeiden, da der Eintrag keinen Failover auslöst! Die User die versuchen sich mit dem Server der server_restricted=1|2 gesetzt hat, bekommen eine Fehlermeldung.

Dass die Benutzer im Zug eines Failovers nicht zurück auf ihren Homeserver switchen ist leider ein seit Ewigkeiten bekanntes Problem und ich kenne keine Möglichkeit, dass sie automatisiert zum Homeserver zurückkehren.

Im Prinzip kann man nach einem Ausfall nur mit den ServerAccess Einstellungen nur die jeweilige Gruppe berechtigen, dann switchen sie wieder zurück. Ich bin mir aber nicht sicher, denke aber, daß die Server Access Settings nur beim Serverneustart ziehen.

Update: das ginge natürlich auch mit der DenyAccess, aber ich würde eine Gruppe einfügen in "Who is allowed to access this server" und da dann die einen bzw. anderen User kurzzeitig entfernen.
Titel: Re: Cluster "feiner" steuern
Beitrag von: Tode am 06.07.12 - 19:10:06
Ja, christoph, so ähnlich hatten wir uns das gedacht... Ich denke, ich werde mit autopopulated groups arbeiten, die wiederum in eine weitere gruppe "Server1Access" packen und einen agent schreiben, der erkennt, wenn ein server weg ist, und die user temporär aus dem anderen server rausnimmt...

Natürlich muss da ne menge logik rein, damit man nachher nicht einen server hat, auf den niemand mehr zugreifen darf, aber server- reboot ist nach einer Änderung nicht nötig, das zieht nach aktualisierung der Ansichtsindizes...
Titel: Re: Cluster "feiner" steuern
Beitrag von: stoeps am 06.07.12 - 22:06:09
Hi, eine Idee habe ich noch, allerdings nicht ausgereift, da ich es grad nicht probieren kann. Man könnte evtl mit der desktool.exe den "falschen" Servernamen löschen (http://www-01.ibm.com/support/docview.wss?uid=swg24004260), die Kachel sollte sich eigentlich durch den Cluster selbst wieder anlegen.
Titel: Re: Cluster "feiner" steuern
Beitrag von: Tode am 07.07.12 - 08:32:33
Ja,ja, die desktool... Wenn Dir mir bei meinen versuchen mit ihr vor langer Zeit nicht den desktop und die bookmark zerbröselt hätte, würde ich es evtl. probieren ;-)
Und das Ding wurde ja seit 2004 nicht mehr angepasst...
Titel: Re: Cluster "feiner" steuern
Beitrag von: umi am 09.07.12 - 09:19:44
Hallo

Soweit ich weiss, könnte der Marvel Client von Panagenda hier weiterhelfen um die Desktop Icons zu steuern.
Titel: Re: Cluster "feiner" steuern
Beitrag von: stoeps am 09.07.12 - 23:20:29
Ja,ja, die desktool... Wenn Dir mir bei meinen versuchen mit ihr vor langer Zeit nicht den desktop und die bookmark zerbröselt hätte, würde ich es evtl. probieren ;-)

;) Naja es war eine Idee. Ich will es auch nicht probieren. Urs hat Recht, evtl mit Marvel oder Client Genie könnte es auch noch gehen.

Kommt man mit der C-Api an die Kacheln ran?
Titel: Re: Cluster "feiner" steuern
Beitrag von: Tode am 10.07.12 - 09:51:30
Danke an alle für die tollen Tipps... Klar: Mit den Desktop- Tools der diversen Hersteller geht es wahrscheinlich... Aber die sind natürlich auch nicht grade umsonst zu haben... Ich werde Euch über die Fortschritte auf dem laufenden halten.