Problem mit Cluster

[pimpfling]

Hallo

R5.09:
Ich habe hier zwei Server in einem Cluster.
Auf beiden habe ich das Logging aktiviert.
doch während auf dem einen jede Menge Meldungen auf der Konsole erscheinen - schreibt der andere die ganze Zeit nur die folgenden zwei Zeilen hin:
"RTRREPL> Retrying failed Replication" und
"Replication Checking for modified Database"
Wenn ich bei dem Server mit der Fehlermeldung "sh cluster" eingebe steht bei ihm das er unreacheble wäre

Was läuft da schief?
Gruß Stefan

[Fis]

Kannst du den Server anpingen?
Ist der Server freigegeben?
Besteht ein Verbindungsdokument?

[byte]

Notes.ini Eintrag machen!!!!


TCPCL=TCP,0,15,0,,12288,
TCPCL_TcpConnectTimeout=0,5
TCP1=TCP,0,15,0,,12288,
TCP1_TcpConnectTimeout=0,5
Ports=TCP1,TCPCL
DisabledPorts=TCPIP,LAN0ip,LAN1ip,LAN2ip,VINES,SPX,AppleTalk,LAN3,LAN4,LAN5,LAN6,LAN7,LAN8,COM1,COM2,COM3,COM4,COM5
Server_Cluster_Default_Port=TCPCL
SERVER_CLUSTER_ON=1


Daten für Ports im Addressbuch machen,  und  vor der Notes.ini change replizieren !!!!!
ansonsten musste mit  Adminclient uffm Server das nacheditieren *ggg*
(servers) dann auf  networkport gehen....

Server A

Port      Protocol      Notes Network      Net Address
TCP1                        meinnetz                      195.1.1.1      
TCPCL                      meincluster      195.2.1.1      

Server B

Port      Protocol      Notes Network      Net Address
TCP1                        meinnetz                195.1.1.2      
TCPCL                       meincluster           195.2.1.2      




Der Server hat  2 NotesNetzwerke eines für Betrieb, eines für  Cluster.


Das eine ( TCP1) ist der normale  Port, über den die Anwender connecten , mit eigenenr IP( 195.1.1.1
Die andere, TCPCL ist ein Port nur für Cluster
195.2.1.1

der Clusterpartner mus natürlich  gleich Ports und Notesnetzwerke haben und die Ports enablen !!

am besten, du  guggst dir das mal bei IBM an

jdenfalls -  du solltest  zweierlei IP benützen, damit keine User auf deinem Clusterport rumlümmeln....( Pro maschnine)



kannst aber auch per cross kabel verbinden ( bei 2  Server)


http://www-10.lotus.com/ldd/today.nsf/cbb328e5c12843a9852563dc006721c7/e1e0430cc270f929852566090062f34f?OpenDocument


mit sh cl  prüfen,


Cluster name: meincluser, Server name: Server A Server cluster probe timeout: 1 minute(s)
Server cluster probe count: 27968
Server cluster default port: TCPCL
Server availability threshold: 60
Server availability index: 100 (state: AVAILABLE)
Cluster members (4)...
     server: A availability index: 100
     server: B, availability index: 100
     
und mit trace kannst du guggen ob du deine Serve r über die konsole gegnseitg finden können

trace servername.domäne/was/weis/ich
Noteshier. Name !!!

[pimpfling]

Hallo

Das Problem ist das der Server sich anscheinend nicht selber findet.
Die Meldung mit dem UNREACHABLE kommt seltsamerweise bei im selber - beim anderen Server stehen beide auf 100
mit ping oder trace finden sich beide selbst und gegenseitig
gibt es noch irgendwo einen Haken extra für Cluster Verbindungen?

gruß stefan

[pimpfling]

Hallo

Bei dem Server mit den Fehlermeldungen bekomme ich jetzt nach einem Neustart auch die 100 bei sh cluster.
Allerdings tauchen immernoch diese Fehlermeldungen in der Konsole auf...
Haben die was zu bedeuten?

Gruß Stefan

[obrocke]

Hi Stefan,

ist der betreffende Server von einem Client aus zu erreichen ??

Hast du die Einstellungen im Server-Dokument mal genau überprüft ?? ICh denke dabei so an Servername, Domäne, etc.

Viel Glück, Gruß,

Olaf

[Meff]

Hi Stefan,

zum einen ist der Hinweis von byte sehr wichtig, hast Du mal die Ini´s der Server daraufhin geprüft ? Zum zweiten, ein Ping ist nicht gleich ein Ping, schau Dir mal an, welchen Weg das Paket geht (läuft das Ding wirklich über das Segment, welches Du für den Cluster vorgesehen hast).

Meff

P.S. Noch ne Anmerkung zu der Ini von byte :
Es sollte immer zuerst der normale Notesport an erster Stelle in der Ini stehen, da es ansonsten zu Probleme wie z.B. mit dem SMTP Listener Tasks kommen kann, der hört nämlich standardmässig auf den ersten aufgeführten Port !

[Meff]

Noch ne kleine Bitte :

Poste doch mal das Ergebnis des 'sh cluster' Befehls, dann kann man da evtl. noch ein wenig was zu sagen.

Meff

[pimpfling]

Hallo und Danke für die Tipps.

Here are the Results of the German Jury:

ServerA (der mit den Fehlermeldungen in der Konsole):
Cluster-Information
Cluster-Name: Cluster1_BLN, Servername: nt5_ffm/cs-cert
Server-Cluster-Überprüfungszeitüberlauf: 1 Minute(n)
Server-Cluster-Überprüfungsanzahl: 1972
Server-Cluster-Standardanschluá: TCPIP
Schwellenwert für Serververfügbarkeit: 0
Server-Verfügbarkeitsindex: 100 (Status: AVAILABLE)
Cluster-Mitglied (2)...
       Server: nt5_ffm/cs-cert, Verfügbarkeitsindex: 100
       Server: nt5_bln/cs-cert, Verfügbarkeitsindex: 100

ServerB:
Cluster-Information
Cluster-Name: Cluster1_BLN, Servername: nt5_bln/cs-cert
Server-Cluster-Überprüfungszeitüberlauf: 1 Minute(n)
Server-Cluster-Überprüfungsanzahl: 20853
Schwellenwert für Serververfügbarkeit: 0
Server-Verfügbarkeitsindex: 100 (Status: AVAILABLE)
Cluster-Mitglied (2)...
     Server: nt5_ffm/cs-cert, Verfügbarkeitsindex: 100
     Server: nt5_bln/cs-cert, Verfügbarkeitsindex: 100

Trace an den Servern liefert:

ServerA
> trace nt5_bln/cs-cert
Pfad zu Server NT5_BLN/CS-CERT wird ermittelt
Aktivierte Anschlüsse:  TCPIP
Nur Verbindungsdokumente mit normaler
'Lokales Netz '-Verbindungsdokument für
 Adresse '192.168.100.42' für NT5_BLN
 Verbunden mit Server NT5_BLN/CS-CERT

ServerB
> trace nt5_ffm/cs-cert
Pfad zu Server NT5_FFM/CS-CERT wird ermittelt
Aktivierte Anschlüsse:  TCPIP COM1 COM2 ISD1
Nur Verbindungsdokumente mit normaler Priorität werden geprüft...
'Lokales Netz '-Verbindungsdokument für Server nt5_ffm/cs-cert gefunden
 Adresse '192.168.100.43' für NT5_FFM/CS-CERT auf TCPIP wird überprüft
 Verbunden mit Server NT5_FFM/CS-CERT

Die Fehlermeldungen am ServerA:
04.09.2002 09:52:36,78 [0061:0002-0153] RTRREPL> Retrying failed replications
04.09.2002 09:52:42,76 [0076:0002-0186] RTRREPL> Checking RTR queue for modifi
04.09.2002 09:52:42,76 [0076:0002-0186] RTRREPL> Retrying failed replications
04.09.2002 09:52:48,76 [0076:0002-0186] CLREPL> Checking for modifications to
04.09.2002 09:52:51,80 [0061:0002-0153] RTRREPL> Checking RTR queue for modifi
04.09.2002 09:52:51,80 [0061:0002-0153] RTRREPL> Retrying failed replications

Ich hoffe das sind genug Infos...

Gruß Stefan