PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Anmeldung an Openldap-Server extrem langsam



Seiten : [1] 2

lziegler
21.07.06, 13:00
Hallo leute,

ich hab auf einem Server (2x Opteron, 4GB RAM, SCSI Raid10) Opensuse 10.0 laufen. Es laufen verschiedene Dienste (squid, openldap, cups-server, nfs etc.)
Derzeit sind 60 Clients angeschlossen und ca. 700 User im LDAP registriert. Der Server verfügt über 6 1Gbit-Netzwerkanschlüsse. Pro Netzwerkkarte sind ca. 30 100Mbit Clients angeschlossen, auf denen jeweils OpenSuSE 10.1 mit KDE läuft. Wenn sich nun mehrere Benutzer gleichzeitig Anmelden (Erstanmeldung) vergehen ca. 10 Minuten, bis sie mit der Arbeit beginnen können. Bei der nächsten Anmeldung geht es dann schneller. Allerdings treten auch immer wieder Fehlermeldungen wie "DCOP .... Anmeldung fehlgeschlagen" eine Überwachung mit ksysguard hat gezeigt, dass die Auslastung des Servers minimal ist. Also kann es nicht daran liegen. An der Quota-Überwachung und dem avira antivir Virenscanner kann es auch nicht liegen.

Hat noch irgend jemand eine Idee wo der Fehler liegen könnte?

Vielen Dank

Lars

bla!zilla
21.07.06, 13:20
Hallo leute,

Hi.



ich hab auf einem Server (2x Opteron, 4GB RAM, SCSI Raid10) Opensuse 10.0 laufen. Es laufen verschiedene Dienste (squid, openldap, cups-server, nfs etc.)

Hübsche Maschine. Selbstbau oder von einem namenhaften Hersteller? Welcher Versionen von Squid und OpenLDAP. Homeverzeichnisse der User kommen über NFS?



Derzeit sind 60 Clients angeschlossen und ca. 700 User im LDAP registriert.


Holen sich die Clients die User aus dem LDAP, oder dient das LDAP nur als Basis für den Squid?



Der Server verfügt über 6 1Gbit-Netzwerkanschlüsse. Pro Netzwerkkarte sind ca. 30 100Mbit Clients angeschlossen, auf denen jeweils OpenSuSE 10.1 mit KDE läuft.


Du hast doch nur 60 Clients? Also nutzt du nur zwei NICs? Beide NICs im gleichen Subnetz oder hast du Bonding im Einsatz? Bitte mal genauer Beschreiben.



Wenn sich nun mehrere Benutzer gleichzeitig Anmelden (Erstanmeldung) vergehen ca. 10 Minuten, bis sie mit der Arbeit beginnen können. Bei der nächsten Anmeldung geht es dann schneller.


NSCD ist auf den Clients gestartet? Sicher das es nicht die NFS Performance ist? KDE steht nicht so auf NFS Laufwerke. Ich hatte selber teilweise erhebliche Probleme. Nutze auf Client und Server SUSE 10.0. User sind auch bei mir in einem OpenLDAP Verzeichnis abgelegt (dient aber auch für Samba, Squirrelmail und Cyrus). So läuft z.B. sqlite nicht auf NFS Laufwerken (wegen fehlerhaftem locking), ich kann also z.B. kein DigiKam nutzen. Abhilfe: ~/.kde auf die lokale Platte legen und Symlink nach ~/.kde setzen. Wie ist die Auslastung der Leitung / der NICs. Load vom Server und vom Client bei erster Anmeldung und bei zweiter Anmeldung?



Allerdings treten auch immer wieder Fehlermeldungen wie "DCOP .... Anmeldung fehlgeschlagen" eine Überwachung mit ksysguard hat gezeigt, dass die Auslastung des Servers minimal ist. Also kann es nicht daran liegen.


Da wäre ich mir noch nicht sicher. Müssen wir aber erstmal analysieren.



An der Quota-Überwachung und dem avira antivir Virenscanner kann es auch nicht liegen.


Abwarten.



Hat noch irgend jemand eine Idee wo der Fehler liegen könnte?


Aus dem Bauch heraus nicht, zumindest nicht ohne die ganzen Informationen.

lziegler
21.07.06, 20:57
Hallo bla!zilla,

Also die Maschine ist natürlich Marke Eigenbau. Hatte keinen nach meinen Wünschen gefunden, also hab ich ihn kurzerhand selbst zusammengestellt. Aber natürlich sind nur komponenten namenhafter Hersteller verbaut :-)

Die Homes kommen per NFS direkt in die Lokalen Home-Verzeichnisse.

Die Clients holen die User vom LDAP, wie auch der Squid und Samba. Zusätzlich arbeiten Clients und Server über ssl verschlüsselte Zertifikate zusammen. Diese befinden sich ebenfalls auf einem NFS Mount-Punkt.

Also es sind zwar schon alle NICs konfiguriert, aber bisher sind erst 2 Räume á 30 Clients (eigentlich 32 bzw. 33). In den nächsten Wochen werden dann noch ein weiterer Raum mit 30 Win2K Clients angebunden, sowie ein weiteres Gebäude mit ca. 30 Clients und ein zweites mit ca. 20 Clients. Alle Sind in einem eigenen Subnetz. Routing ist auf dem Server nicht aktiviert, damit die einzelnen Räume strikt getrennt bleiben.

Ich kann zwar jetzt auf anhieb nscd nicht einordnen, aber ich glaube das läuft auf den clients. Die Probleme mit KDE uns NFS hab ich auch schon bemerkt. Wenn man beispielsweise einen USB-Stick anschließt, nachdem man sich angemeldet hat, kann man über den Arbeitsplatz plötzlich nicht mehr auf NFS-Laufwerke zugreifen. Geht dann nur noch direkt über die Mountpunkte auf der Festplatte. Also muss man immer vor der Anmeldung den Stick anschließen, dann klappts.
Also die NIC Auslastung ist gering, genauso wie CPU, Speicher und HDD-Auslastung. CPU liegt bei ca. 5-10% pro CPU. Speicher bei ca 1GB von 4GB. NIC-Auslastung kann ich nicht in Prozent sagen, aber das war ebenfalls nur sehr gering.
Ein Unterschied zwischen Erst- und Zweitanmeldung konnte ich nicht feststellen.

Ich habe schonmal die Quota-Überwachung, und den Vierenscanner sowie beides abgeschaltet, hat aber auch nichts gebracht. Ich hab den Vierenscanner auch mit 6 Daemons gleichzeitig laufen, also kann ich mir das auch nicht vorstellen, dass der mit dem Datendurchsatz nicht fertig wird.

Das Raid dürfte da auch keine Probleme machen. Läuft über einen OnBoard Adaptec SCSI kontroller mit optionaler Zero-Raid-Card.
Ich hab die HDD Auslastung allerdings noch nie mit Software gemessen, weils da so vielen Sensoren gibt, sondern nur anhand der Actitvity-LEDs der einzelnen HDD-Slots.

Also das mit dem .kde hab ich noch nicht ganz verstanden. Hast du die .kde Verzeichnisse aus den NFS Homes lokal abgelegt?

Ich verwende des weiteren systemweite Profile für verschiedene Benutzergruppen. d.h ich hab die das Verzeichnis /var/lib/kde-profiles ebenfalls über NFS gemountet. Ansonsten sind noch die Dateien k3drc und kde-profiles (oder so ähnlich) aus dem /etc Verzeichnis durch symlinks auf Dateien auf dem Server ersetzt.

So ich hoffe das sind für den Anfang erst mal genügend Infos. Würd mich freuen, wenn dir eine Lösung einfällt.

Ich hatte auch schon den Verdacht, dass das Problem mit dem Novell AppArmor zusammenhängt, das neuerdings seit 10.1 mitgeliefert wird. Das hatte mir mit dem SSL anfangs Schwierigkeiten bereitet. Aber dann versteh ich nicht, warum diese Fehler nur manchmal auftreten.

Viele Grüße

mamue
21.07.06, 21:06
Ich könnte mir vorstellen, dass es an der Auflösung der Namen liegt.
Wenn Du Dich local am Client anmeldest, geht die Auflösung des Servernamens schnell? Wie lange braucht es, die Benutzeraccounts aufzulisten (getent passwd)? Eventuell ist die Clientseite ldap-Konfiguration etwas misslungen, oder die des nscd. Hast Du schon mal versucht, den nscd abszuschalten? Meiner Erfahrung nach stört der ohnehin mehr, als das er hilft.

HTH,
mamue

bla!zilla
21.07.06, 21:18
Puhh... bist du sicher was du da machst? 180 Clients an einen Server (30 Clients a 6 Nics) zeugt nicht gerade von Verständis für Verfügbarkeit und SLAs. Auch wenn ein Server aus Qualitätshardware besteht, so hast du das Problem der Ersatzteile. So einen Server hätte es problemlos samt Support bei HP gegeben. Rückschlüsse der Plattenauslastung aufgrund von HDD LEDs ist TOTAL inaktzeptabel. Du weißt nicht ob das System evtl. auf I/Os wartet (sieht man mit top). Aber gut....

NSCD ist der Name Server Cache Daemon. Und dieser hilft. Thunderbird läuft z.B. nicht, wenn User über LDAP kommen und NSCD nicht läuft. AppAmor hat nur dann etwas auf dem Server zu suchen, wenn man damit umgehen kann. Kannst du das? Nein, dann bitte abschalten. Eine Fehlerquelle weniger. Das mit den ~/.kde hast du richtig verstanden. Das sollte lokal auf dem _Client_ liegen.

Was für ein RAID Level beim Server bei vielvielen Platten. Durchsatz read und write? Welchen Durchsatz bei NFS (Client -> Server und Server -> Client). NFSv3 oder v4? TCP oder UDP? Locking korrekt konfiguriert?

Bezüglich deiner Vermutung mit dem Durchsatz: Bei Wartezeiten und Timeouts, aber keiner ersichtlichen Auslastung, kann man den Durchsatz schon mal ausschließen. Es hat also was mit Verbindungen, geblockten Verbindungen, schlecht konfigurierten Paketfiltern usw. zu tun.

Ich habe das Gefühl du stocherst da ein bisschen rum. Hast du Zeitdruck? Das ist für das weitere Troubleshooting recht wichtig.

Hast du mal mittels Sniffer den Verkehr zwischen Client und Server analysiert? Aktive Netzwerkkomponenten können als Fehlerquelle ausgeschlossen werden?

Sonny
21.07.06, 21:21
hab jetzt hier nicht alles gelesen ... genug cache?

bla!zilla
21.07.06, 21:25
hab jetzt hier nicht alles gelesen ... genug cache?

Cache? Was für Cache? Plattencache? Cache für den Squid?

Kinnas, der OP hat ein Problem und rumstochern zeugt nicht gerade von Professionalität.

Sonny
21.07.06, 21:26
die cachsize in der slapd.conf ... einfach mal eine oder zwei null hinten dran und ausprobieren
(hat bei mir mal geholfen)

bla!zilla
21.07.06, 21:34
Stichwort Verbindungen. Hab ich auch dran gedacht, dagegen spricht aber die vom OP genannte geringe Grundlast der Maschine. Normalerweise frisst der slapd dann viel CPU Zeit. Kenne das Problem von Samba Server mit OpenLDAP Backend und zuvielen Verbindungen (z.B. bei Anmeldevorgängen).

Kann man aber testen. Es gibt ein Tool namens torture aus dem Samba Projekt. Damit kann man den mal so richtig unter Stress setzen.

mamue
21.07.06, 21:57
Sorry, aber bei 30 Verbindungen wird OpenLDAP normalerweise nicht gefordert, selbst in der Standardkonfiguration nicht. 900 Einträge sind auch nicht wirklich viel. Es sei denn, er hat viele Gruppen (100+) mit vielen Einträgen. Aber dann hätte er nicht gesagt, dass "die Auslastung des Servers minimal ist".
Denkbar ist meiner Ansicht nach eher, dass der Client zunächst versucht, eine gesicherte Verbindung aufzubauen und dann nach einer Weile erst die ungesicherte. Darum die Bitte, die nss_ldap Anbindung zu testen. Bei zehn Minuten Wartezeit können wir wohl auch erst einmal Netzwerkfehler ausschließen. Naja, nicht ganz, aber dann wäre da etwas ganz schrecklich im Argen und die Wartezeit ist bei nachfolgen Versuchen ja deutlich kürzer.
Irgendwo muß man anfangen - kann sein, dass ich fürchterlich daneben liege, aber smbtorture ist deutlich aufwändiger als "getent passwd" et al.
Man könnte auch die Anmeldung mit "top" begleiten. Die Werte in der Zeile
"Cpu(s): " sind wichtig, vor allem wohl "% sy" für die Zeit, die im Kernel verbracht wird, "% id" für die absolute CPU Auslastung und "% wa", für die Belastung des I/O Systems. Die Last (load average) wird sicher auf diesem System zwischen 0.00 und 0.01 liegen ;-) (Der Hammer - so ein Gerät für so ein paar PC)

mamue

P.S.:
1.: IMHO ist der nscd eine Plage
2.: Man sollte OpenLDAP durchaus etwas optimieren. Die slapd.conf könnte der OP mal posten.

bla!zilla
21.07.06, 22:04
Mir ist durchaus klar das 30 Verbindungen nix sind. Selbst 1200 Verbindungen bringen den nicht ins schwitzen. Aber irgendwo müssen wir ja anfangen.

nss_ldap ist ein gutes Stichwort. Sind zufällig solche Meldungen unter /var/log/messages oder /var/log/auth zu finden?



ul 21 22:03:42 svr-lev-01 sshd[10830]: nss_ldap: reconnecting to LDAP server...
Jul 21 22:03:42 svr-lev-01 sshd[10830]: nss_ldap: reconnected to LDAP server after 1 attempt(s)

comrad
22.07.06, 01:38
Ist die Reihenfolge der Anfragen an PAM denn korrekt? Ich meine, dass es dort Reihenfolgen gibt wie "lokal", "NIS" oder auch "LDAP". Wenn er jetzt natürlich immer zuerst lokal nachfragt und dann erst LDAP könnte das die Pause erklären.

Wie schaut denn die Struktur vom LDAP-Bäumchen aus? Könnte es da vllt strukturelle Probleme geben?

Was für ein Backup hast du für LDAP? Sollte es Postgres sein, so soll es starke Performanceprobleme mit Opterons und PostgreSQL geben (nach unserem Admin).

Gruss,
comrad

lziegler
22.07.06, 09:19
@comrad
die clients fragen zuerst den ldap, dann lokal ab. Das bringt allerdings probleme, wenn man der server mal nicht verfügbar ist, weil ich dann über 10 min brauch um den root lokal anzumelden.
struktur: dc=x,dc=y,dc=z
ou=benutzer
ou=gruppe1
ou=gruppe2
ou=gruppe3
ou=gruppen
ou=machines

derzeit läuft noch kein Backup für den ldap, da der recchner erst ganz neu aufgezogen ist.

@bla!zilla
Es kann nicht sein, dass der client ungesichertes verbindungen aufbaut, da diese nicht zugelassen sind. Die Verbinung wird ausschließlich über port 636 aufgebaut und sowohl bei clients als auch beim server steht in der conf-datei
TLS_REQUIRE DEMAND.
Die von dir erwähnte Fehlermeldung hatte ich anfangs, als das mit dem ssl noch nicht geklappt hat. Inzwischen hab ich damit kein problem mehr.
So jetzt noch mal zu dem Thema verständnis: JAAAAAAAA ich bin mir sicher bei dem was ich mache !!!!!!!! Verfügbarkeit ist schön und gut! Deshalb setzen wir auch auf ein RAID10, redundante netzteile, redundande switches etc. Zudem wird in nächster Zeit ein Replikationsserver für ldap eingesetzt werden. Derzeit sind 6 Platten im Einsatz, es werden aber in kürze noch 2 weitere hinzukommen. Zusätzlich wird zur Sicherung noch ein Streamer eingesetzt.

Ich finde auch nocht, dass man da von rumstochern reden kann! Wie du vielleicht bemerkt hast mach ich nichts anderes als du auch, nämlich den Fehler eingrenzen.

Gesnifft hatte ich nur anfangs um zu überprüfen ob die Verschlüsselung funktionert. Alle aktiven Komponenten arbeiten einwandfrei.

Also noch mal zum Verständnis: AppArmor läuft auf den Clients (10.1), nicht auf dem Server, der auf 10.0 läuft. Da war AppArmor noch nicht integriert.

@mamue
das mit dem getent passwd werde ich heute mal ausprobieren

@sonny
ich werde die Cachesize mal erhöhen und mal schaun, was passiert.

lziegler
22.07.06, 09:22
struktur kommt irgendwie falsch rüber:
dc=x
dc=y
dc=z
-ou=benutzer
--- ou=gruppe1
--- ou=gruppe2
--- ou=gruppe3
-ou=gruppen
-ou=machines

lziegler
22.07.06, 10:09
also das mit dem getent passwd hab ich gerade mal getestet. Das ganze dauert keine sekunde und schon sind alle Benutzer aufgelistet.

mamue
22.07.06, 11:01
also das mit dem getent passwd hab ich gerade mal getestet. Das ganze dauert keine sekunde und schon sind alle Benutzer aufgelistet.

Vorweg: Ich kann leicht mal daneben liegen.

Wenn die Auflistung der Accounts schnell klappt, dann können wir eigentlich die ldap-Anbindung schon mal abhaken. Nach Lehrbuch sollte übrigens zuerst "files" aufgeführt sein:


passwd: files ldap
group: files ldap
hosts: files dns
networks: files dns

Aber das hast Du sicher auch so gemacht und ich habe Dich nur falsch verstanden.
Wenn sich ein User per ssh am Server anmeldet, geht das sicherlich ebenfalls sehr schnell. Bereitet vielleicht das Mounten des homedir per NFS Probleme? Ich hatte diesbezüglich schon häufiger Schwierigkeiten. Hast Du mal auf dem Server die Firewall komplett abgeschaltet (iptables -L == leere Liste)?
Wahrscheinlich bist Du das meiste davon bereits durchgegangen, aber das kann ich nun mal von hier aus nicht sehen.
Ich würde übrigens versuchen, von NFS auf CIFS umzuschwenken, wenn ohnehin bald Windows-clients dazukommen, man kann auch das homedir per CIFS mounten.

mamue

bla!zilla
22.07.06, 13:20
@bla!zilla
Es kann nicht sein, dass der client ungesichertes verbindungen aufbaut, da diese nicht zugelassen sind. Die Verbinung wird ausschließlich über port 636 aufgebaut und sowohl bei clients als auch beim server steht in der conf-datei
TLS_REQUIRE DEMAND.

Wie ist denn die Performance ohne TLS?



Die von dir erwähnte Fehlermeldung hatte ich anfangs, als das mit dem ssl noch nicht geklappt hat. Inzwischen hab ich damit kein problem mehr.

Okay.



So jetzt noch mal zu dem Thema verständnis: JAAAAAAAA ich bin mir sicher bei dem was ich mache !!!!!!!! Verfügbarkeit ist schön und gut! Deshalb setzen wir auch auf ein RAID10, redundante netzteile, redundande switches etc. Zudem wird in nächster Zeit ein Replikationsserver für ldap eingesetzt werden. Derzeit sind 6 Platten im Einsatz, es werden aber in kürze noch 2 weitere hinzukommen. Zusätzlich wird zur Sicherung noch ein Streamer eingesetzt.


Bringt dir nur alles nichts wenn du die Komponenten, die ausgefallen sind, nicht mehr erhältlich sind. Ich bin selbstgebauten Servern immer sehr reserviert gegenüber aufgestellt. Das kann man mit Clients machen, aber besser nicht bei Servern. Da verlasse ich mich auf namenhafte Hersteller und Supportverträge. Da weiß ich wenigstens was ich im Fehlerfall zu erwarten habe.



Ich finde auch nocht, dass man da von rumstochern reden kann! Wie du vielleicht bemerkt hast mach ich nichts anderes als du auch, nämlich den Fehler eingrenzen.

Na ja, mal hier geschaut, mal da vermutet.... you know what I mean...



Gesnifft hatte ich nur anfangs um zu überprüfen ob die Verschlüsselung funktionert.


Aha. Und warum jetzt nicht? Bitte den Verkehr mal analysieren und feststellen ob da ein Problem zu erkennen ist.



Alle aktiven Komponenten arbeiten einwandfrei.




Also noch mal zum Verständnis: AppArmor läuft auf den Clients (10.1), nicht auf dem Server, der auf 10.0 läuft. Da war AppArmor noch nicht integriert.


Aha. Schön das du das jetzt sagst. Das ist in deinem Posting nicht ganz klar rausgekommen.

Was ist denn mit den ganzen Fragen die ich dir gestellt habe?



Was für ein RAID Level beim Server bei vielvielen Platten. Durchsatz read und write? Welchen Durchsatz bei NFS (Client -> Server und Server -> Client). NFSv3 oder v4? TCP oder UDP? Locking korrekt konfiguriert?


Bezüglich CIFS und NFS. Es macht keinen Sinn die Homeverzeichnisse per CIFS an die Linux Clients zu exportieren. AFAIK kommt es dabei zu Problemen mit den Rechten. NFSv4 wäre eine Alternative.

lziegler
22.07.06, 19:59
@mamue
sagt ja keiner dass man sich nicht irren darf, so war das auch nicht gemeint. Also mit NFS hatte ich bislang noch keine Probleme feststellen können. Allerdings was mir mal aufgefallen ist: wenn ich mir als root, oder wer auch immer das Verzeichnis /home am Server mit la auflisten lasse, dauert das ca. 2 sec. bis der rechner mir alle verzeichnisse ausspuckt. Dabei muss er ja für jedes Verzeichnis die Besitzrechte abfragen. Also die Firewall hab ich noch nicht komplett abgeschalten, weil der rechner auch an einem DSL-Anschluss hängt, aber auf den Internen Netzwerkkarten ist keine Firewall aktiv. Also nur für die externe NIC aktiv.
Für die Win Clients hatte ich eigentlich vor die ganzen Home-Verzeichnisse per Samba zu mounten. Die Profil-Verzeichnisse für Windows liegen dann sowieso in einem eigenen Verzeichnis. Aber das nur so nebenbei.

@bla!zilla
Ich hab die Performance ohne TLS noch nie getestet. Das kam nur Anfangs in Frage, als der Rechner noch in der Testphase war. Seitdem er in Betrieb ist läuft immer TLS mit.
Also die verbauten Komponenten sind meiner Meinung nach so lange der Server im Einsatz ist verfügbar! Noch zählen die Opterons nicht zur aussterbenden Rasse und der 940er Sockel wird wohl auch noch ein bisschen verfügbar sein.
Support-Verträge: Wer sichs leisten kann. Wir sind eine Schule und damit eine öffentliche Einrichtung, d.h. wir müssen an allen Ecken und Enden sparen. Deswegen hab ich auch alle 60 neuen Rechner im mühevoller Handarbeit selbst zusammen gebaut. Wie du siehst können wir uns einen solchen Luxus nicht leisten, damit wir unseren Schülern eine bestmögliche Ausstattung bieten können.

Das mit dem Sniffen werde ich noch mal ausprobieren, allerdings hege ich nur geringe Hoffnung da was zu finden.

Also das mit dem Raid war im letzten Posting gestanden. Es läuft ein Raid10 mit 6 SCSI Festplatten, 2 weitere sind noch geplant. NFS Version kann ich dir jetzt gar nicht sagen da ich den Kernel schon vor 3 Monaten gestrickt habe. Aber ich glaube ich hab die 4er aktiviert.
Wenn du mir verrätst wie man die korrekte Funktion des Locking überprüfen kann, werde ich das mal überprüfen. Beim TCP und UDP konnte ich keine Fehler feststellen.

mamue
23.07.06, 11:38
1.: wenn ich mir als root, oder wer auch immer das Verzeichnis /home am Server mit la auflisten lasse, dauert das ca. 2 sec. bis der rechner mir alle verzeichnisse ausspuckt. Dabei muss er ja für jedes Verzeichnis die Besitzrechte abfragen.
2.: Also die Firewall hab ich noch nicht komplett abgeschalten, weil der rechner auch an einem DSL-Anschluss hängt, aber auf den Internen Netzwerkkarten ist keine Firewall aktiv. Also nur für die externe NIC aktiv.


1.: Das dauert bei mir ~10 sec. Der Wert ist IMHO in Ordnung.
2.: OK, ich habe noch Firewallregeln für die interne NIC, was mir bei NFS scheinbar Probleme bereitet hatte (Ich brauch nur sehr selten NFS).

Wenn das Anmelden lange dauert, sehe ich dafür nur zwei mögliche Ursachen: Entweder die Authentisierung braucht so lange, oder das Mounten. Mein Gedanke war, beides getrennt zu testen. Den ersten Teil betrachte ich als abgehakt, "getent passwd" läuft schnell, das Anmelden per ssh als user geht auch fix. Bleibt für mich das mounten. Wenn Du Dich als user auf einem CLient anmeldest, steht da nichts in den log-files? Was passiert, wenn Du von root per "su <username>", aber ohne das "-" (su - <username>) den Benutzer wechselst (es dürfte dann noch nicht das homedir gemountet werden) und danach erst manuell dan mount durchführst? Ich glaube ehrlich gesagt nicht, dass es am Netzwerk liegt.

mamue

bla!zilla
23.07.06, 15:39
Ich hab die Performance ohne TLS noch nie getestet. Das kam nur Anfangs in Frage, als der Rechner noch in der Testphase war. Seitdem er in Betrieb ist läuft immer TLS mit.

Okay. ich überlasse es dir es ohne TLS zu testen.



Das mit dem Sniffen werde ich noch mal ausprobieren, allerdings hege ich nur geringe Hoffnung da was zu finden.


Ja willst du das Problem nun lösen, oder nicht? Wenn du das Problem lösen willst, dann würde ich dir das Sniffen ans Herz legen. Da sieht man sehr schnell ob es Timeouts gibt, Pakete gedroppt werden usw.



Also das mit dem Raid war im letzten Posting gestanden. Es läuft ein Raid10 mit 6 SCSI Festplatten, 2 weitere sind noch geplant. NFS Version kann ich dir jetzt gar nicht sagen da ich den Kernel schon vor 3 Monaten gestrickt habe. Aber ich glaube ich hab die 4er aktiviert.


Ich erspare mit jetzt die Frage ob RAID 1+0 oder 0+1.... leider sind sich da nicht mal die Hersteller einig. Wegen NFSv3 oder v4. Du nutzt NFSv3. Auch wenn im Kernel NFSv4 eingebaut ist, SUSE 10.0 verwendet es nicht von Haus aus. Zudem gibt es im Kernel einen Bug mit dem Locking (siehe bugzilla.novell.com). Der ist AFAIK nur im Kernel-of-the-day-Kernel gefixt. NFSv4 ist bei SUSE 10.0 noch extrem hakelig. Ich habe es selber getestet.

[QUOTE=lziegler]
Wenn du mir verrätst wie man die korrekte Funktion des Locking überprüfen kann, werde ich das mal überprüfen. c/QUOTE]

Du weißt was locking macht? Google mal kurz, es gibt einfach C-Funktionen mit denen man das testen kann (so habe ich es getestet). Ich empfehle dir hier auch bugzilla.novell.com, da gibt es einige Bugs zum Thema SUSE 10 #+ NFS + Locking.

Was meinst du mit "Beim TCP und UDP konnte ich keine Fehler feststellen."? Wie hast du das getestet?

lziegler
23.07.06, 21:05
Also ich hab jetzt gerade mal den Netzwerkverkehr mitgesnifft.
Beim Booten des PCs ist mit eine Meldung ins Auge gestochen:
Source: Client - Dest.: Server - Protocol: LDAP - Info: Invalid LDAP Message (Can't parse sequence header: wrong type for that item)
Beim Anmelden am PC, war folgende auffällige Meldung:
Source: Server - Dest.: Client - Protocol: NFS - Info: V3 Lookup Reply (Call in xxxx) Error: NFS3ERR_NOENT.

Ich werde noch ein bisschen weiter suchen und mich dann wieder melden

lziegler
23.07.06, 21:13
Mir ist gerade eben noch eine Fehlermeldung in der Log-Datei des Servers aufgefallen:

Kernel: lockd: cannot monitor 192.XXX.YYY.ZZZ (IP des Clients der sich gerade angemeldet hat)
Vielleicht hängt das Problem ja damit zusammen.

lziegler
23.07.06, 21:38
So und jetzt hab ich noch 2 Meldungen auf den Clients entdeckt:

sm-notify: cant notify SERVER, giving up
dbus daemon: nss_ldap: reconnected to LDAP Server after 4 attempts
wofür sind die beiden Dienste eigentlich zuständig?

lziegler
23.07.06, 22:13
So jetzt ist mir noch eine Meldung beim Booten des Servers aufgefallen, der ich bislang noch keine große Bedeutung zugeordnet hab, da ich davon ausgegangen bin, dass das NFS einwandfrei funktioniert.

Und zwar steht beim Booten folgende Meldung:
Starting Kernel Base NFS Server: Module nfsd not found

Allerdings hab ich NFS nicht als Modul in den Kernel integriert:

@bla!zilla
Ich hab mich geirrt, hab NFSv4 im Kernel nicht aktiviert!

bla!zilla
24.07.06, 08:20
Also ich hab jetzt gerade mal den Netzwerkverkehr mitgesnifft.
Beim Booten des PCs ist mit eine Meldung ins Auge gestochen:
Source: Client - Dest.: Server - Protocol: LDAP - Info: Invalid LDAP Message (Can't parse sequence header: wrong type for that item)
Beim Anmelden am PC, war folgende auffällige Meldung:
Source: Server - Dest.: Client - Protocol: NFS - Info: V3 Lookup Reply (Call in xxxx) Error: NFS3ERR_NOENT.


Da scheint der Client irgendwelche merkwürden Dinge an den Server zu schicken. Wie häufig ist die Meldung denn?
Ist da zu erkennen ob es dabei zu einer längeren Wartezeit kommt?



Kernel: lockd: cannot monitor 192.XXX.YYY.ZZZ (IP des Clients der sich gerade angemeldet hat)
Vielleicht hängt das Problem ja damit zusammen.


Das ist das von mir beschriebene Locking-Problem. Schau mal bei bugzilla.novell.com. Da findest du
noch mehr zu dem Problem.



sm-notify: cant notify SERVER, giving up
dbus daemon: nss_ldap: reconnected to LDAP Server after 4 attempts
wofür sind die beiden Dienste eigentlich zuständig?


Erkennbar ob es dabei zum Timeout kommt? Interessant ist das dbus daemon vier Versuche braucht.
Ist zum Zeitpunkt, an dem die Meldung erscheint, LDAP schon verfügbar? Steht der User "dbus"
noch in deiner /etc/passwd?



Und zwar steht beim Booten folgende Meldung:
Starting Kernel Base NFS Server: Module nfsd not found

Allerdings hab ich NFS nicht als Modul in den Kernel integriert:


Hast du NFS fest einkompiliert? Wenn ja, versucht ein Skript (wahrscheinlich /etc/init.d/nfs)
explizit das Modul "nfsd" zu laden.

lziegler
24.07.06, 12:24
Da scheint der Client irgendwelche merkwürden Dinge an den Server zu schicken. Wie häufig ist die Meldung denn?
Ist da zu erkennen ob es dabei zu einer längeren Wartezeit kommt?

Die Meldung kommt schon relativ häufig vor (öfters kurz hintereinander mehrere dieser Meldungen, danach wieder längere Zeit keine mehr), allerdings konnte ich damit keine Längere Wartezeiten in Verbindung bringen.
Allerdings habe ich festgestellt, dass die Anmeldezeit proportional zur Anzahl der Locking-Fehlermeldungen ist.



Erkennbar ob es dabei zum Timeout kommt? Interessant ist das dbus daemon vier Versuche braucht.
Ist zum Zeitpunkt, an dem die Meldung erscheint, LDAP schon verfügbar? Steht der User "dbus"
noch in deiner /etc/passwd?

LDAP ist zu diesem Zeitpunkt schon verfügbar und der user "dbus" müsste in in der lokalen passwd vorhanden sein. Aber ich dafür hab ich glaube ich auch eine Lösung. Ich muss dem User dbus ein Homeverzeichnis zuweisen, in dem sich eine Datei .ldaprc befindet. In der muss stehen, wo er da ssl-Zertifikat findet. Das Problem hatte ich beispielsweise auch mit Squid, was dann durch eben beschriebenes Verfahren behoben war.




Hast du NFS fest einkompiliert? Wenn ja, versucht ein Skript (wahrscheinlich /etc/init.d/nfs)
explizit das Modul "nfsd" zu laden.

Ja ich hab NFS fest einkompiliert. Kann ich deiner Antwort entnehmen, dass ich diese Meldung nicht beachten muss, da der NFS ja offensichtlich korrekt gestartet wurde, da ich ja sonst keine Verzeichnisse exportieren könnte.

Ich hab im Internet auch noch mal ein bisschen gesucht, und bin auf einen Hinweis gestoßen, bei dem jemand SuSE 10.0 Clients an einen SuSE 9.3 Server anmelden wollte und die gleiche Fehlermeldung erhalten hatte. Seine Lösung war, dass er den Standard SuSE Kernel benutzen musste, damit der Fehler weg war.
Das geht nur bei mir nicht, da ich viel verschiedene Hardware verbaut hab, die eben nur nach einem Neukompilieren des Kernel unterstützt wird.

bla!zilla
24.07.06, 12:35
Die Meldung kommt schon relativ häufig vor (öfters kurz hintereinander mehrere dieser Meldungen, danach wieder längere Zeit keine mehr), allerdings konnte ich damit keine Längere Wartezeiten in Verbindung bringen.
Allerdings habe ich festgestellt, dass die Anmeldezeit proportional zur Anzahl der Locking-Fehlermeldungen ist.


Gib einem User bitte mal ein lokales Homeverzeichnis auf seinem Rechner und teste die Anmeldezeiten. Dann siehst du ob es am Locking liegt (sehr einfach gesagt).



Ja ich hab NFS fest einkompiliert. Kann ich deiner Antwort entnehmen, dass ich diese Meldung nicht beachten muss, da der NFS ja offensichtlich korrekt gestartet wurde, da ich ja sonst keine Verzeichnisse exportieren könnte.


Ja, korrekt.



Ich hab im Internet auch noch mal ein bisschen gesucht, und bin auf einen Hinweis gestoßen, bei dem jemand SuSE 10.0 Clients an einen SuSE 9.3 Server anmelden wollte und die gleiche Fehlermeldung erhalten hatte. Seine Lösung war, dass er den Standard SuSE Kernel benutzen musste, damit der Fehler weg war.
Das geht nur bei mir nicht, da ich viel verschiedene Hardware verbaut hab, die eben nur nach einem Neukompilieren des Kernel unterstützt wird.

Tja... da sind wir dann auch schon wieder beim Thema Hardware, Support und supportete Hardware. Das Thema hatten wir weiter oben. Du hättest di das sparen können. Aber gut, nun musst du damit leben.

Verfolge bitte den Ansatz mit dem Locking weiter.

lziegler
24.07.06, 12:43
Das mit dem Home-Verzeichnis werde ich heute Abend mal testen.
Das andere Thema müssen wir wirklich nicht noch durchkauen.

Meinst du dass das Problem vielleicht durch einen neueren Kernel behoben werden könnte, Derzeit läuft 2.6.15 auf dem Server.

bla!zilla
24.07.06, 12:51
2.6.13.15-11 ist der aktuellste Kernel für die SUSE 10.0. Klar, der ist von SUSE. Keine Ahnung ob das mit einem neueren Kernel läuft. Ich würde aber testhalber mal die Kernel-Sourcen aus der Distri installieren und mir daraus einen Kernel backen.

lziegler
24.07.06, 21:54
So ich bin jetzt mal wieder auf den Kernel 2.6.13.15 zurück gegangen (aus der Distr). Und jetzt (zumindest als wenn sich nur ein Benutzer anmeldet) waren die Fehlermeldungen nicht mehr zu sehen. Ich werd ich mal schaun was passiert, wenn sich wieder eine ganze Klasse gleichzeitig das erste mal anmeldet.
Ich werde dann bescheid geben wie sich das ganze entwickelt.

Aber warum funktionieren die Kernel, die nicht aus der Distr sind nicht korrekt?