Remote-Server ist kein bekannter TCPIP Host

[DigitDani]

Hallo mangler,

Du hast es hier evtl. mit dem gleichen oder einem ähnlichen Bug zu tun, wie wir in unserer Dominoinfrastruktur. Ich kann Dir gleich vorweg sagen... das Problem wird von uns permanent an Lotus mit hoher Prio gegeben... aber es kommt nichts zurück. Lotus schiebt den Fehler auf unsere Replikationsstruktur.

Also hier ein paar Infos:
Du solltest einmal nachschauen, was Dein Server, kurz bevor die "Error connecting to..." Meldung auf der Konsole kommt, gemacht hat. Läuft da zufällig ein Viewupdate oder ein Viewrebuild auf die names.nsf? (Evtl. das Loglevel erhöhen, damit Du es sehen kannst!)
Bei uns tritt das Problem häufig nach bzw. während einem Viewupdate der $ServerAccess View auf.

Oder:
Da Du den Clrepl Task laufen hast, ist der Server ja wohl in einem Clusterverbund. Zieht bei Dir vielleicht auch evtl. diese Technote hier?:

Problem:
You recently upgraded your Domino cluster from 5.0.x to 6.5.x and receive the following error everytime you run AdminP:  "Error connecting to server <servername>: The remote server is not a known TCP/IP host".  Why is this happening?

Solution:
It is common for the Domino cluster mates to poll all server in the customer periodically for changes in the replica files.  The server will also poll itself in the cluster.

As a workaround, check the "Net Address" field for the cluster port and make sure that the Fully Qualified Host Name (FQHN) is correct.

cu

Daniel

[DigitDani]

...und noch was: Wenn Dein Server richtig abschmiert, müsste er doch einen NSD wegschreiben? Was steht denn da drin? Für eine ganz grobe Analyse such da mal nach "FATAL", dann müsstest Du zumindest wissen, welcher Task den Server zum Absturz bringt.

[mangler]

Das Problem ist, dass er nicht abschmiert und kein Fehlerdokument erstellt.

Der Server bleibt bei einer Auslastung der nserver.exe bei 90% einfach stehen. Läßt evtl. noch eine einzige Eingabe an der Serverkonsole zu und dann war's das. Dann geht kein Befehl, keine Replizierung oder irgend was. Er steht einfach und die verbundenen User werden spätestens ab diesem Zeitpunkt auf den Cluster-Server umgebogen.

Beenden läßt sich der Domino dann auch nicht mehr. Selbst wenn ich als letzten Konsolenbefehl "Q" eingebe, fährt er nicht mehr runter. Da geht manchmal noch nicht mal mehr "Windows herunterfahren" und ich muss in den Serverraum und Knöpfchen drücken.

[diali]

die Server-Konsole kann über den Win-TaskManager noch abgeschossen werden, dann brauchts du wenigstens nicht in den Serverraum.

Hängt auch vom Fernwartungstool ab. Bei VNC kann es vorkommen, dass Win nicht beendet wird, mit netsupport ist es mir noch nicht passiert, dass ich zum Server laufen musste (macht bei mehreren 100 km auch keinen Spaß).

[mangler]

Nein, nein. Über den Win-Taskmanager läßt sich der Domino nicht beenden. - Es geht nur über den Weg -Start-Herunterfahren...-Herunterfahren- via pcAnywhere.

Aber wie gesagt, manchmal geht auch dieses nicht mehr.

[tschroeder]

Das Problem ist, dass er nicht abschmiert und kein Fehlerdokument erstellt.

Der Server bleibt bei einer Auslastung der nserver.exe bei 90% einfach stehen. Läßt evtl. noch eine einzige Eingabe an der Serverkonsole zu und dann war's das. Dann geht kein Befehl, keine Replizierung oder irgend was. Er steht einfach und die verbundenen User werden spätestens ab diesem Zeitpunkt auf den Cluster-Server umgebogen.

Beenden läßt sich der Domino dann auch nicht mehr. Selbst wenn ich als letzten Konsolenbefehl "Q" eingebe, fährt er nicht mehr runter. Da geht manchmal noch nicht mal mehr "Windows herunterfahren" und ich muss in den Serverraum und Knöpfchen drücken.

Sowas i.d. Richtung hab ich auch schon gehabt. Ergebnis war ein User wollte sich einen Index bauen, incl. der Anhänge. Womit der Server dann erstmal bis zum Neustart stand (bzw. beschäftigt war).

Hast du mal nachgeschaut, ob du evtl. sowas hast und die NW-Probleme nur Nebeneffeckte sind? (Klingt irgendwie unwahrscheinlich aber es ist ein Versuch)

Hast du das Consolen logging eingeschaltet?

Gruß Thorsten

[mangler]

An diese Indexer-Geschichte hab ich auch schon gedacht, weil wir dieses Problem auch schon mal hatten. Aber bisher hab ich die auslösende Datenbank nicht finden können und auch keine Idee, wo ich die bei der Datenbanke finden/suchen soll.

Consolen-logging hatte ich eingeschaltet, hat mir aber die Platte zugemüllt und ich musste es wieder abschalten.

[tschroeder]

...
Consolen-logging hatte ich eingeschaltet, hat mir aber die Platte zugemüllt und ich musste es wieder abschalten.

Hilft jetzt gerade nicht wirklich: einmal die Woche "Housekeeping" und die alles was älter als ... ist aus dem IBM-Verzeichnis kicken.

Gruß Thorsten

[tschroeder]

Hab doch noch eine Idee: Hast du mal versucht deine Netzwerkkarte zu beobachten (z.B. mit TCPIPView aus den Sysinternals) um mal festzustellen, welcher Task denn Versucht den Server zu erreichen?

Gruß Thorsten

p.s.: www.sysinternals.com

[DigitDani]

öhm... bevor mein Beitrag hier untergeht mangler...

Der Server bleibt bei einer Auslastung der nserver.exe bei 90% einfach stehen. Läßt evtl. noch eine einzige Eingabe an der Serverkonsole zu und dann war's das. Dann geht kein Befehl, keine Replizierung oder irgend was.

Das ist ganz genau das Verhalten wie bei uns. Hast Du jetzt mal geprüft ob kurz davor ein Viewupdate der names.nsf stattfindet? Und was ist mit der Technote?

[mangler]

Ich hab geschaut, aber er bleibt an ganz unterschiedlichen Stellen hängen, mal ist es tatsächlich bei einem Viewupdate (nicht unbedingt die names.nsf), mal bei einem User- od. Datenbankfehler.

Und die Technote kannte ich schon, das war's aber auch nicht.

[DigitDani]

Nur um ganz sicher zu gehen mangler,

ist Dein Loglevel hoch genug, so dass Du auch wirklich siehst, dass ein Viewupdate auf die names.nsf stattfindet/stattfand?

Es muss so ein Eintrag auf der Konsole bzw. im Log stehen:

Updating Domino Directory view '($ServerAccess)'

Verwende bis zum nächsten Absturz den notes.ini Parameter:
Log_Update=2

Dieses Update kann auch bis ca. 5 Minuten vor dem eigentlichen Absturz geschehen sein. Die Symptome die Du schilderst sehen wirklich ziemlich nach dem gleichen Problem aus, das wir auch haben. Würde mich wundern, wenn es an etwas anderem liegt. Auch wir können z. B. noch einen Trace eingeben und danach ist Schicht.

cu

Daniel

[mangler]

Den von dir beschriebenen Eintrag hab ich lediglich auf der Serverkonsole gesehen vor dem Absturz. Im Log wurde er nicht protokolliert. Ich hab den Log-Level jetzt entsprechend deiner angabe angepasst.

Schauen wir mal, was er sagt.

[DigitDani]

Ok. Aber wenn Du sagst, Du hast ihn auch schon auf der Konsole gesehen, sieht es schon ziemlich genau danach aus.

Erzähl mir mal ein bisschen etwas über eure Replikationstopologie. Mit wievielen Servern repliziert dieser Cluster die names.nsf... und vor allem wie? Habt ihr eine Sterntopologie implementiert oder repliziert ihr kreuz und quer?

Wir konnten durch eine Bereinigung der Topologie (über Jahre hinweg und durch viele verschiedene Admins, wurde sie ziemlich verbogen), zumindest die Häufigkeit der Ausfälle minimieren.

[mangler]

Der betroffene Server hat noch einen Cluster-Server. Diese beiden befinden sich in einer der Spitzen einer Sterntopologie. Replizieren somit nur noch mit dem "Sternmittelpunkt" und sonst mit keiner anderen Maschine.

Was vielleicht noch hilft, bis vor ca einem halben Jahr war dieser Server Administrations- und Registrierungsserver für die Domäne. Mittlerweile hat diese Aufgabe ein anderer Server übernommen.
Aber wir hatten seit der Umstellung keinerlei Probleme... Bis uns vor etwa einem Viertljahr der Chronos-Task Probleme machte. Daraufhin haben wir die Indizierung auf ein Minimum runtergeschraubt und dann lief wieder alles. - Daher war meine erste Vermutung nach auftreten unseres jetzigen Problems auch wieder ein fehlerhafter Datenbankindex.

[Ralf_M_Petter]

Hallo Mangler!

Eventuell zieh dir mal den Thread rein:

http://www.atnotes.de/index.php?topic=25181.0

Der hat zwar absolut nichts mit deinem Problem zu tun, aber dort ist beschrieben wie man Semaphore Debugs macht. Das würde ich mal bei Hangs als erstes machen um den Process rauszukriegen, der das Problem verursacht. Mich wundert, dass der IBM Support nicht gemacht hat. Was sagen die den beim Support und was haben die bis jetzt gemacht. Welche Priorität habt ihr für das Problem vergeben?

Grüße

Ralf

[DigitDani]

Hi Ralf,

so wie ich mangler verstanden habe, hat ihre Firma keinen Passportvertrag mehr und es ist kein Call bei IBM wegen dem Problem offen.
Wir schicken am laufenden Band NSD's und Semaphore Debugs wegen dieser Sache an IBM, aber es kommt wie gesagt immer noch nichts zurück. 

Ich werde heute in der Firma nochmal bei den Kollegen nachhaken. Da das Problem nicht von mir bearbeitet wird, bin ich nicht immer auf dem aktuellsten Stand.

Daniel

[Ralf_M_Petter]

Hallo Daniel!

Habt Ihr das Problem auf Severity 1, dann solltet ihr eigentlich relativ schnell jemand aus Amerika zugewiesen bekommen. Wichtig für die IBM sind dann die Stacktraces und Semaphore Debugs damit sollte das Problem relativ schnell isoliert werden können. Eventuell wenn es wirklich schon lange dauert und keine Informationen kommen einen Complaint bei der IBM aufmachen. Das hat bei uns auch sehr viel geholfen. Sollte man natürlich nur machen wenn das Problem brennt und es wirklich schon 1 Monat oder so dauert. Bei uns ist es nach Eröffnung des Complaints dann wirklich Ruck zuk gegangen. Das einzige was auf Severity 1 hart ist man muß permanent erreichbar sein. Auch in der Nacht. Aber das war mir lieber als wenn der Server alle par Stunden crasht.

Grüße

Ralf

P.S. Eines kann ich nicht glauben Mangler betreibt einen Cluster von Domino Servern und hat keinen Passport Vertrag??? Ich glaub ich träum, wir haben nur einen Server und ohne Passport Vertrag würde ich mir den nicht trauen zu betreiben.

[mangler]

Hallo Ralf,

warum brauche ich unbedingt einen Passport-Vertrag zum betreiben eines Clusters? - Meine Server laufen jetzt schon 2 Jahre ohne Passport und bisher hab ich alle Probleme immer so hin bekommen. (Ist zwar manchmal - so wie jetzt - etwas unkompfortabel, aber in jedem Fall machbar.)

Gruß
mangler

[DigitDani]

Hi Ralf,

ich hoffe sehr, dass das Problem Severity 1 hat... muss aber wie gesagt die Kollegen fragen, die da dran sind. Die ganze Sache ist in unserer sehr großen Dominoinfrastruktur äußerst nervig... da unser Team leider nur einen Teil der Gesamtstruktur darstellt und wir nichtmal Adminrechte auf die names haben.
In so großen Konzernen dauert leider alles immer viel zu lange und wird unnötig verkompliziert

Von IBM kam bis jetzt wie gesagt nur der Hinweis, es läge an unserer Replikationstopologie. Hier konnten wir durch eine Bereinigungsaktion (Ausschließlich die Hubserver initiieren jetzt noch eine Replikation) die Ausfälle tatsächlich minimieren.
IBM's Fazit lief so in etwa darauf hinaus, dass durch unnötige Viewupdates der names.nsf, die Dominoserver ihre IP Stacks verlieren und sich somit selbst nicht mehr finden. (ob da jetzt Logik dahinter stecken mag... ich weiß es nicht  )

Hoffe, ich kann nachher noch mehr Infos liefern.

Grüße
Daniel