Das Notes Forum
Domino 9 und frühere Versionen => ND6: Administration & Userprobleme => Thema gestartet von: mangler am 12.10.05 - 15:26:35
-
Hallo Zusammen,
wir haben seit 2 Wochen massiv Probleme mit unserem Domino-Server. In schöner Regelmäßigkeit (ca. alle 4-6 Stunden) erscheint auf der Serverkonsole "Remote-Server ist kein bekannter TCPIP-Host Domino/ACME". Und der Domino/ACME ist er selbst. ??? Und dann dauert es keine zwei Minuten, der nserver.exe-Task auf Windows NT geht auf über 90% und der Server bleibt stehen und läßt sich nicht mehr runter fahren. - Dann heißt es Knöpfchen drücken.
Mittlerweile legt dieses Problem unsere ganze Produktion lahm- Knowledgebase brachte auch keine Hilfe. Problemmöglichkeiten wie Indexer-Task, fehlerhafte DB's oder auch ein fehlerhafter Virenscanner können mittlerweile auch ausgeschlossen werden.
Hier noch die Server-Infos:
Windows NT mit SP 6
Domino 6.0.4 EN
GROUP Tools 8.6.3 mit Sophos und McAffee
Bitte: HILFE !!!!
Viele Grüße
mangler
P.S.: Problem wurde auch bei DominoForum.de eingetragen !!!!
-
scheint ein DNS-Problem zu sein. Tragt doch in die hosts (steht in C:\WINNT\system32\drivers\etc) den Server mit der IP-Adresse für loalhost (127.0.0.1 ) ein.
Alternativ dürfte es auch funktionieren die IP-Adresse des Servers ins Server-Dokument einzutragen.
-
Hier ist der Link zum Beitrag im DominoForum: http://www.dominoforum.de/modules/newbb/viewtopic.php?topic_id=10024&start=0#forumpost53160
-
Hallo diali,
danke für den Tip, aber ich hab gerade nachgesehen, in der HOST-Datei unter WinNT steht die IP schon drin. Ich hab sie jetzt vorsichtshalber auch nochmal in Notes eingetragen, aber irgendwie fürchte ich, wird es das wohl auch nicht bringen. :-[
Gruß
mangler
-
in die lokale Hosts-Datei auf dem Server kann auch die IP-Adresse 127.0.0.1 für diesen Server eingetragen werden.
Geht ein Ping auf andere Server oder PCs?
-
Ein Ping funktioniert problemlos. Windowsseitig ist der Rechner nicht betroffen. Wenn ich im letzten lebenden Moment des Domino ein TRACE auf ihn selbst versuche findet er seine eigene IP-Adresse nicht mehr.
Und die Stellen, an denen der Absturz passiert, sind ganz unterschiedlich. Mal bei der Replikation, dann wenn er gerade einen großen Index erstellt. ??? Nur erst genanntes Problem scheint wirklich immer da zu sein.
-
Das letzte Lebenszeichen vor dem Absturz:
-
also die einzigen Tasks, von denen ich weiss, dass sie auf der Console Meldungen ausgeben, die von Connections zum Server selbst handeln (also Server1/ACME versucht sich selbst zu erreichen) sind Virenscanner- Hooks (extmgr)...
Ihr habt nicht zufällig zusätzlich zur Group- Hook noch eine weitere Hook aktiviert ?
Gruß
Tode
-
Eigentlich sollte dies nicht der Fall sein. Wir haben nur GROUP im Einsatz, aber ausschließen möchte ich das nicht. Wo kann ich nachschauen? Notes.ini?
-
jepp, notes.ini des Servers, da einfach nach extmgr suchen.
möglicherweise war vor Einsatz von Group ein anderer Notes- Viren- Scanner im Einsatz, der nicht deinstalliert wurde, weil man glaubte, die Engine schliesslich für Group zu benötigen...
So Szenarien hatte ich auch schon...
Gruß
Tode
-
So, hab nachgeschaut. Es gibt einen Eintrag:
ExtMgr_Addins=te_hook
Sonst finde ich nichts.
-
Ich kann mir eigentlich kaum vorstellen das eine falsche DNS-Konfiguration den Server zum Absturz bringt. Einträge in HOSTS-Dateien halte ich ehrlich gesagt für unnötig. Eine sauber ausgelegte DNS-Konfiguration halte ich hier für deutlich fehlerunanfälliger.
Ich vermute doppelte bzw. falsche Einträge in der HOSTS bzw. LMHOSTS Datei. Würde spontan auch eher auf den Tip von Tode tippen...
-
Also in der DNS-Datei steht:
do-acme Host (A) 10.10.104.3
domino_acme Alias (CNAME) do-acme
Und in der HOST-Datei steht lediglich:
domino_acme 172.0.0.1
-
Steht das da wirklich ?
domino_acme 172.0.0.1
Dann wäre ja der Fehler schon gefunden ;D
Bernhard
-
kannst Du uns auch mal sagen, welche Tasks über die ServerTasks gestartet werden ?
Gruß
Tode
-
Und in der HOST-Datei steht lediglich:
domino_acme 172.0.0.1
unter WinNT muss der Eintrag so aussehen (Hostname und IP-Adresse getauscht und IP-Adresse für localhost berichtigt)
127.0.0.1 domino_acme
-
Hab den Eintrag in der HOST Datei geändert, Server neu gestartet... aber irgendwie hat ihm das wohl auch nicht gefallen. Er hat sich schon wieder weg gehängt. :'(
Folgende Task sind gestartet:
AdminP
Agent Manager
Cluster-Replikator
tm_grab
td_grab
Maps Extractor
Schedule Manager
Calendar Connector
Router
Directory Indexer
Indexer
Replicator
Event Monitor
-
Hast Du einen Passport-Vertrag? Wenn ja dann würde ich bei IBM einen PMR aufmachen oder Euch an einen guten DL Eures Vertrauens wenden.
Man könnte natürlich noch vieles versuchen: Logging hochdrehen ob man dann bessere Infos bekommt uvm, nur ist Euer Dominoserver ja keine Spielwiese und bei den Crashs risikierst Du ja einiges (inkosistente Datenbanken etc)...
Nur so aus dem Bauch heraus, würde ich auf die GroupTools bzw. deren eingebundenen Virenscanner als Fehlerursache tippen...
-
Die Virenscanner und GROUP-Tools hab ich schon ausgeschaltet. ::) Ohne Erfolg.
Und Passport... Der wurde leider aus Kostengründen vor zwei Jahren gekündigt und ist bis auf weiteres auf Eis gelegt. :-[ (Ausgerechnet jetzt, wo man das Ding mal gebrauchen könnte.)
-
Dann würde ich Dir/Euch einen empfehlen einen guten Dienstleister Eures Vertrauens hinzuziehen. Keine Sorge - ich bin kein kein DL, sondern festangestellter Admin...
-
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
-
...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.
-
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.
-
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ß).
-
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.
-
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
-
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.
-
...
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
-
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 (http://www.sysinternals.com)
-
ö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?
-
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.
-
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
-
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.
-
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.
-
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.
-
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
-
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
-
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.
-
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
-
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
-
Hallo Daniel,
so, ich hatte gestern noch ein Domino-Update von 6.0.4 EN auf 6.0.5 EN gefahren und wie beschrieben den notes.ini Eintrag gemacht. Das war etwa gegen 15:00 Uhr gestern. Bisher läuft mein Domino noch unauffällig. :D
Gruß
mangler
-
welche Switche setzt ihr ein? Setzt eventuell mal die Ports der geclusterten Domino-Server am Switch zurück.
Hat bei uns schon Wunder bewirkt.
-
Hi mangler,
na wie ist der aktuelle Stand Deines "Problemkindes"? :) Hat das Update auf 6.0.5 tatsächlich geholfen?
Ich kann Dir leider nur nochmal bestätigen, dass Lotus in unserem Falle in der Tat noch immer nichts konstruktives zu diesem Problem beitragen konnte... wir warten immer noch >:(
Daniel
-
Wie macht man eigentlich ein Update auf 6.0.5 ohne Passport-Vertrag ? Nur mal so interessehalber ...
Bernhard
-
Also das Update scheint in der Tat geholfen zu haben. Der Fehler ist bis jetzt nicht mehr aufgetreten.
-
@Bernhard Ich hoffe du hast in mit deiner Frage nicht in Verlegenheit gebracht. Aber irgendwie wundert mich heutzutage nichts mehr.
Grüße
Ralf