PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : NFS und Portmap Problem



gerrie1978ch
06.12.06, 10:10
Hallo liebes Forum,

ich habe hier ein Problem, und komme absolut nicht weiter. Habe schon alles abgegoogelt, aber finde keine Lösung.

Folgende Infrastruktur habe ich:

2 identische Rechner mit SLES 10, Kernel 2.6.16.21-0.8.
Die beiden sind über Heartbeat zu einem Cluster geschaltet. Als Services laufen Proftpd und NFS der NFS-Server, über DRBD werden bei Heartbeatumschaltung das FTP-Verzeichnins und der NFS-Share (in diesem Falle das gleiche Verzeichnis) auf den zweiten Node geswitcht.
Auf den NFS-Share wird mit einer Tru64-Kiste zugegriffen.
Eigentlich klappt alles problemlos, jedoch hängt sich NFS ab und zu auf, so das man den Heartbeat bei Node 1 per Hand stoppen muss, damit der andere Node übernimmt.

Des weiteren taucht in /var/log/messages in unterschiedlichen Zeitabständen (mal 4 Minuten, mal 10, mal eine) folgende Meldung auf:

Dec 6 09:53:04 octans kernel: portmap: server not responding, timed out

dmesg bringt folgenden Eintrag:
portmap: server not responding, timed out$
und irgendwo auch häufiger
NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory
NFSD: starting 90-second grace period

Folgende Informationen kann ich noch liefern:


octans:/ # /etc/init.d/portmap status
Checking for RPC portmap daemon: running




octans:/ # rpcinfo -p
program vers proto port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100003 4 udp 2049 nfs
100003 2 tcp 2049 nfs
100003 3 tcp 2049 nfs
100003 4 tcp 2049 nfs
100024 1 udp 32790 status
100021 1 udp 32790 nlockmgr
100021 3 udp 32790 nlockmgr
100021 4 udp 32790 nlockmgr
100024 1 tcp 46591 status
100021 1 tcp 46591 nlockmgr
100021 3 tcp 46591 nlockmgr
100021 4 tcp 46591 nlockmgr
100005 1 udp 646 mountd
100005 1 tcp 647 mountd
100005 2 udp 646 mountd
100005 2 tcp 647 mountd
100005 3 udp 646 mountd
100005 3 tcp 647 mountd


In der /etc/exports steht folgendes:


/data/ftpfpbg *(rw,no_root_squash,sync)
/data *(rw,no_root_squash,sync)


Hat irgendjemand eine Idee?
Sitze die ganze Zeit am Rechner und kann somit weitere Details, falls notwendig, liefern.

Ich danke schon mal,
Gerrie

marce
06.12.06, 10:14
wie viele Clients hängen denn an den NFS-Servern?

Wir hatten das Phänomen auch mal - Die Lösung damals war, die Anzahl der Serverprozesse des NFS-Dämons zu erhöhen. Also evtl. ein Performance / Last / ... Problem...

gerrie1978ch
06.12.06, 10:15
Hi,

das ging ja flott. Es hängt nur ein Client an dem Server, diese Tru64 Kiste.

Gerrie

marce
06.12.06, 10:21
hm - dann schliesse ich zumindest die "zu viele Clients am Server" mal aus...

Kommt das nur zu Lastspitzen oder immer?

gerrie1978ch
06.12.06, 10:24
Es gibt keine wirklichen Lastspitzen, da der Zugriff zeitlich immer konstant ist. Es sind auch eine enormen Datenmenge, lediglich ein paar XML-Files auf die da zugegriffen wird.
Bei


Dec 6 09:53:04 octans kernel: portmap: server not responding, timed out

wundert mich eigentlich, dass er nicht schreibt server xxx oder server localhost not responding. Welchen Server meint er denn?

Gerrie

gerrie1978ch
06.12.06, 11:15
Okay,

das Problem hat sich gelöst. Ich habe den NFS-Server einmal über die haresources vom Heartbeat gestartet, und zusätzlich wurde der auch noch bei Systemstart gestartet.

Bis jetzt läuft alles ohne Fehlermeldung, denke mal, das war es dann wohl auch.

Aber ich hab noch ne andere Fehlermeldung, die aber in nem anderem Thread.

Gerrie