SERVER_AVAILABILITY_THRESHOLD zieht nicht korrekt

[smokyly]

Hallo zusammen.

Wir haben einen Cluster mit einem Master und einem Slave (8.5.1 FP3).

Beim Master haben wir das SERVER_AVAILABILITY_THRESHOLD mit Wert 0, beim Slave mit 100 gesetzt. Trotzdem sind Datenbanken auf dem Slave in Benutzung. Wenn ich das richtig verstanden habe, soll doch der Parameter im Normalbetrieb, also nicht im Fall von Failover, genau das verhindern?!

Ebenso ziehen die Benutzer NACH einem Failover nur teilweise wieder zurück auf den Slave.

Wo liegt mein Denkfehler?

Gruß

[Gandalf98]

Hi

soweit ich weiß hast du den Server auf den mit dem Parameter auf den Status BUSY gesetzt, das heisst aber nicht das die USER nicht darauf zugreifen können.
Wenn der Server als "HomeServer" in Arbeitumgubung eingetragen ist und die Datenbank direkt über die über die Kachel geöffnet wird wird der Server weiterhin angesprochen.

https://www-304.ibm.com/support/docview.wss?uid=swg21096869

Könnte auch ein Problem in der 8.5.2 sein, ich habe mit dem Parameter noch nicht rumgspielt.
Gruß
Michael

[smokyly]

Also das mit der Arbeitsumgebung muß ich prüfen, sollte eigentlich nicht sein...

Die Lesezeichen der Anwendungsdatenbanken verweisen tatsächlich auf den Slave. Kann es sein, daß sich dieser Verweis beim Failover automatisch einträgt?

Danke für die Erläuterung. Ich dachte mir das schon, war nur verwundert, daß zwei unserer Dienstleister behaupteten, daß diese Einstellung den Zugriff direkt steuern würde.

Dann stellen sich für mich aber zwei Fragen:

- Wieso "fallen" die Benutzer nach dem Failover nicht wieder sofort zurück? Erst, nachdem sie den Client beendet haben, melden sie sich korrekt wieder beim Master an. Allerdings betrifft das (natürlich) nicht alle.

- Gibt es eine Möglichkeit, den eigentlich gewünschten Effekt herbeizuführen? Ich möchte, daß im Normalbetrieb der Slave keine Verbindungen zuläßt.

Danke!

[Gandalf98]

Hi

Wenn du nicht möchtest das USER auf einen deiner Server zugreifen, dann stelle doch bitte Server_Restricted=1 (für den aktuelle session, wird nach neustart weg sein) oder 2 (auch nach neustart kein serverzugriff möglich).
Infos dazu in der Notes Hilfe.

Die Admins sind dann NICHT betroffen, und können weiterhin mit den server arbeiten.
Die Server_Restricted Methode hat aber den großen Nachteil, das bei einem Serverausfall nicht automatisch geswitcht werden kann.
Der Server_Resticted muß manuell wieder auf o gesetzt werden, d.h. ein admin muß immer in der Nähe sein.

Ich weiß nicht ob das für euch eine Pratikabele Lösung ist.

Warum sollen denn keine User auf dem 2.Cluster Menber arbeiten können ?

Gruß
Michael

[smokyly]

Hi

Wenn du nicht möchtest das USER auf einen deiner Server zugreifen, dann stelle doch bitte Server_Restricted=1 (für den aktuelle session, wird nach neustart weg sein) oder 2 (auch nach neustart kein serverzugriff möglich).
Infos dazu in der Notes Hilfe.

Danke! Das habe ich gesucht. Sorry, daß ich das nicht selbst gefunden habe, steht ja wunderbar bei der Cluster-Hilfe beschrieben.
Muß mich erst wieder rein arbeiten, hatte ein halbes Jahr IT-Pause...

Ich weiß nicht ob das für euch eine Pratikabele Lösung ist.

Es reicht zumindest, um weiter zu kommen.
Und ich sehe gerade, nachdem ich die Config gesetzt habe, daß da schon wieder jemand einen Connect hat. Aber keine DB offen...

Warum sollen denn keine User auf dem 2.Cluster Menber arbeiten können ?

Gruß
Michael

Das hat verschiedene Gründe. Z.B. funktioniert eben bei einigen Clients das Failover nicht und da muß ich mich an die Ursache heranforschen. Außerdem ist es nicht so gut, wenn die User gerade auf dem Slave arbeiten, den ich eigentlich wegen Wartung selbst brauche. Und die Mühle ist von der Lastaufnahme nur für den Notfall konzipiert, das Ding soll möglichst im laufenden Betrieb nichts tun.



Gruß

[Gandalf98]

Hi

wenn einige deiner Clients keinen Failover machen, wirf mal einen Blick in die Datei cluster.ncf im Data auf den Clints.

https://www-304.ibm.com/support/docview.wss?uid=swg21087756

Gruß
Michael

[smokyly]

Danke, das hatte ich schon geprüft, sieht alles ok aus.

Beste Grüße

[Driri]

Als Hinweis :

Der Notes-Client merkt sich bei Bookmarks immer den zuletzt erfolgreichen Server und verwendet diesen dann bei der nächsten Nutzung wieder.

Das ändert sich nur, wenn der Server nicht erreichbar ist oder der Benutzer manuell eine andere Replik auswählt.

[smokyly]

Als Hinweis :

Der Notes-Client merkt sich bei Bookmarks immer den zuletzt erfolgreichen Server und verwendet diesen dann bei der nächsten Nutzung wieder.

Das ändert sich nur, wenn der Server nicht erreichbar ist oder der Benutzer manuell eine andere Replik auswählt.

Nicht so ganz:
Hab es gerade ausprobiert. Master runter gefahren und ich hatte einen Failover. Master wieder oben und er bleibt auf dem Slave.
DB geschlossen und wieder geöffnet - es zieht wieder der Master.

Jetzt muß ich nur noch testen, was passiert, wenn ich den Slave mit Server_Restricted=1 versorge und dann mit der DB arbeiten will, ohne diese vorher geschlossen zu haben. Dummerweise bin ich ja Admin... Kann ich also erst am Montag mit einem User testen, sind schon alle heim.

Vielen Dank, das hilft mir schon etwas weiter.

[Driri]

Ok, das könnte dann am Cluster liegen. Ich habe die Erfahrung wie beschrieben zumindest bei Einzelservern gemacht.

[smokyly]

Ich muß nochmal genauer nachlesen, wie der Cluster, bzw. Client sich im Failover genau verhalten sollte. Laut Aussage unserer Dienstleister müßte bei Wiederverfügbarkeit wieder ein Wechsel auf den Master erfolgen. Und zwar ohne, daß der Benutzer da aktiv werden muß. Und ich bin mir fast sicher, daß das alles auch schon mal ohne Zicken funktioniert hat. Aber lange ist es her...

Werde am Montag wieder berichten.

Schönes Wochenende!

[Gandalf98]

Hi

falls du noch reinschaust vor dem Wochenende
Sach dir diese Lektüre mal an:
Understanding IBM Lotus Domino server clustering
Aus der Unterlage:
(When a Notes client first accesses a server in a cluster, the names of all the servers in the cluster are added to the cluster cache on the client. This cache is updated every 15 minutes.)
Immer ein bischen warten bis er merkt das der Master Server wieder da ist.
Schönes Wochenende
Gruß
Michael

[Tode]

Dein Dienstleister liegt FAST richtig... Es ist keine Aktion des Clients nötig, das ist richtig. ABER: Eine Session, die einmal auf dem einen Server geöffnet wurde, bleibt so lange auf dem Server, bis ich die session beende und neu öffne. Und das ist nunmal das schliessen der Datenbank.

Die Tatsache alleine, dass ein Server während der Benutzung "UNAVAILABLE" wird (also AVAILABILITY < THRESHOLD) ändert NICHTS an bestehenden Sessions.

Um die bestehenden zu "zwingen" wieder umzuziehen, musst Du den Server tatsächlich (temporär) restricten und über Drop all die UserSessions beenden, denn sonst zieht (soviel ich weiss) das RESTRICTED auch nicht. Dumm ist nur, dass die User bei dieser Vorgehensweise ggf. eine Meldung bekommen (Abhängig vom Client, je höher der Client, desto seltener die Meldung).

Gruss
Tode

[smokyly]

So, nachdem ich jetzt etwas getestet habe, haben erstmal die Telefone geglüht...

Noch mehr möchte ich die User nicht ärgern, also konnte ich nur unvollständig das Verhalten nachvollziehen.
Das kann ich als vorläufiges Fazit festhalten:

Ist der Master restricted, will der Standard-Client MANCHMAL bei geöffneter DB(!) mit Meldung auf den Slave wechseln. Der Basic-Client arbeitet weiter auf der DB, der Standard mal so und mal so.

Nach Drop meckert der Basic, daß der Serverzugriff eingeschränkt sei. Selbst wenn ich den Master tatsächlich beende, macht der Basic keinen Failover, der Client muss komplett beendet und neu gestartet werden, erst dann zieht er sich die Replik auf dem Slave! Der Standard liefert eine Meldung, um zu wechseln.


Klar, die Leute, die über Web auf ihre DB zugreifen, fliegen komplett raus...

Irgendwie verwirrend das alles.

Beste Grüsse

[Gandalf98]

Hi

aus eigener erfahrung:
Nach dem Shutdown brauchen die Clients bis 15 min um die Daten für das Cluster zu aktualisieren.

Um einen Failover durchzuführen muss die DB einmal geschlossen werden und dann neu geöffnet werden. Wenn es bei geöffneter DB funktioniert auch gut.

Bastel dir doch einen Testuser mit einem Testclient dann kannst du nach Dienstende soviel Testen wie du willst.

Gruß
Michael

[smokyly]

Was meinst Du mit den 15 Minuten? Da geht es doch nur um den Cluster-Cache und der ändert sich ja nicht, da stehen nur die Server drin, welche überhaupt zum Cluster gehören. Anhand dieser Information werden dann die Repliken gesucht, sobald ein Server nicht erreichbar ist.

Der Testuser nützt mir ja nix, ich muß doch die Server entsprechend erreichbar / unerreichbar setzen und das betrifft dann die produktiven User.

Gruß

[Gandalf98]

Hi
Entschuldige ich war etwas verwirrt du hast volkommen Recht.

Der Test User ist ein User der als normaler USER angelegt wir mit den Rechten die die "Normale User" haben, bekommt seinen eigenen Client (VM) und schon kann der Produktivuser simuliert werden.

Gruß
Michael

[smokyly]

Entschuldige, ich kann Dir nicht folgen. Klar weiß ich, was ein Testuser ist, aber was ich primär bräuchte, wäre ein Testcluster. Dann mit  einigen Testusern und verschiedenen Test-Clients.
Und das ist dann doch zu viel Aufwand.

Aber im Grunde ist meine Eingangsfrage ja ausführlich beantwortet worden.

Wie kann ich den Fred hier als "gelöst" markieren?

Danke nochmal!

Gruß