NFS Timeout unter SLES11 SP1

[Azreth]

Moin, ich habe schon viel in diesem Forum als Gast herumgelesen, aber dies wird mein 1. Post.

Ich soll derzeit den Automounter über die auto.master und auto.misc Dateien gegenüber des harten Mountens über die fstab testen, da wir uns dadurch usability Vorteile erhoffen. Mounts nur aktiv, wenn sie gebraucht werden, keine Probleme beim Systemboot, falls der NFS-Server mal down sein sollte und eben jener "Timeout", der durchaus diese hängenden Prozesse beseitigen könnte.

Nur da stoß ich auf mehrere Probleme.

Ich habe hier ein Setup aus 2 VMs, die sich in einem Testnetz befinden. Der eine ist der NFS-Server und der andere der Mount Client. Das ganze funktioniert auch so weit alles. Lediglich die "Timeouts" sind absolut nicht reproduzierbar. Ich habe in der auto.master, auto.misc und /etc/sysconfig/autofs jeweils einen Timeout von 5 Minuten gewählt.

Die jeweiligen Dateien sehen wie folgt aus:

auto.master:

/data /etc/auto.misc --timeout 300

auto.misc:

data -fstype=nfs,soft,rw,intr,v3,rsize=32768,wsize=32768,timeo=300,nolock,proto=tcp,sec=sys 10.2.100.33:/data

autofs:

DEFAULT_TIMEOUT=300

Ich habe während eines cp Vorgangs von dem Client auf den Server jeweils immer den Server 'gekillt', sodass ein Timeout entstehen kann. Das passierte irgendwann mit dem Error Code: "Input/Output Error", sodass die Shell wieder benutzbar war und der Prozess beendet wurde. Was mich an der Sache nur wurmt: die Zeit, bis das auftritt, ist absolut nicht reproduzierbar und variiert jedes mal.

Hier Auszüge aus der /var/log/messages:

Test 1:

Apr 26 11:38:20 vm-nfs-1 kernel: [10978.712042] nfs: server 10.2.100.33 not responding, timed out

Apr 26 11:38:44 vm-nfs-1 kernel: [11002.712058] nfs: server 10.2.100.33 not responding, timed out

Apr 26 11:39:32 vm-nfs-1 kernel: [11050.716046] nfs: server 10.2.100.33 not responding, timed out

Apr 26 11:40:32 vm-nfs-1 kernel: [11110.716043] nfs: server 10.2.100.33 not responding, timed out

Apr 26 11:41:08 vm-nfs-1 kernel: [11146.712052] nfs: server 10.2.100.33 not responding, timed out

Apr 26 11:42:08 vm-nfs-1 kernel: [11206.712044] nfs: server 10.2.100.33 not responding, timed out

Apr 26 11:43:08 vm-nfs-1 kernel: [11266.712040] nfs: server 10.2.100.33 not responding, timed out

Apr 26 11:44:08 vm-nfs-1 kernel: [11326.712042] nfs: server 10.2.100.33 not responding, timed out

Apr 26 11:44:20 vm-nfs-1 kernel: [11338.712043] nfs: server 10.2.100.33 not responding, timed out

Apr 26 11:45:20 vm-nfs-1 kernel: [11398.712050] nfs: server 10.2.100.33 not responding, timed out

Apr 26 11:46:20 vm-nfs-1 kernel: [11458.712114] nfs: server 10.2.100.33 not responding, timed out

Apr 26 11:47:20 vm-nfs-1 kernel: [11518.712042] nfs: server 10.2.100.33 not responding, timed out

Apr 26 11:48:20 vm-nfs-1 kernel: [11578.712060] nfs: server 10.2.100.33 not responding, timed out

Apr 26 11:49:20 vm-nfs-1 kernel: [11638.712038] nfs: server 10.2.100.33 not responding, timed out

Apr 26 11:51:20 vm-nfs-1 kernel: [11758.712078] nfs: server 10.2.100.33 not responding, timed out

Apr 26 11:53:20 vm-nfs-1 kernel: [11878.712070] nfs: server 10.2.100.33 not responding, timed out

Test 2:

Apr 26 12:37:16 vm-nfs-1 kernel: [14514.236071] nfs: server 10.2.100.33 not responding, timed out

Apr 26 12:37:25 vm-nfs-1 kernel: [14523.240215] nfs: server 10.2.100.33 not responding, timed out

Apr 26 12:37:31 vm-nfs-1 kernel: [14529.240052] nfs: server 10.2.100.33 not responding, timed out

Apr 26 12:37:43 vm-nfs-1 kernel: [14541.244083] nfs: server 10.2.100.33 not responding, timed out

Apr 26 12:38:07 vm-nfs-1 kernel: [14565.244054] nfs: server 10.2.100.33 not responding, timed out

Apr 26 12:38:55 vm-nfs-1 kernel: [14613.244049] nfs: server 10.2.100.33 not responding, timed out

Apr 26 12:40:31 vm-nfs-1 kernel: [14709.256065] nfs: server 10.2.100.33 not responding, timed out

Apr 26 12:42:31 vm-nfs-1 kernel: [14829.256043] nfs: server 10.2.100.33 not responding, timed out

Apr 26 12:44:43 vm-nfs-1 kernel: [14961.264081] nfs: server 10.2.100.33 not responding, timed out

Apr 26 12:46:43 vm-nfs-1 kernel: [15081.264040] nfs: server 10.2.100.33 not responding, timed out

Apr 26 12:48:43 vm-nfs-1 kernel: [15201.264043] nfs: server 10.2.100.33 not responding, timed out

Apr 26 12:50:43 vm-nfs-1 kernel: [15321.264048] nfs: server 10.2.100.33 not responding, timed out

Apr 26 12:52:43 vm-nfs-1 kernel: [15441.264082] nfs: server 10.2.100.33 not responding, timed out

Apr 26 12:54:43 vm-nfs-1 kernel: [15561.264076] nfs: server 10.2.100.33 not responding, timed out

Apr 26 12:56:43 vm-nfs-1 kernel: [15681.264039] nfs: server 10.2.100.33 not responding, timed out

Apr 26 12:58:43 vm-nfs-1 kernel: [15801.264065] nfs: server 10.2.100.33 not responding, timed out

Apr 26 13:00:43 vm-nfs-1 kernel: [15921.264060] nfs: server 10.2.100.33 not responding, timed out

Apr 26 13:02:43 vm-nfs-1 kernel: [16041.264077] nfs: server 10.2.100.33 not responding, timed out

Im ersten Fall waren es genau 15 Minuten, im 2. deutlich länger. Und es ist egal, wie oft ich teste, jedes mal kommt etwas anderes dabei heraus.

Woran kann das liegen?

Mit freundlichem Gruß, Oliver

[mariux]

hi..

soweit ich das sehe bezieht sich dein timeout von 5 minuten auf die zeit, die der automounter einen mountpoint noch nach der letzten benutzung am leben laesst und hat nichts mit dem NFS zu tun.

der automounter sorgt also nach 5 minuten dafuer, dass ein mountpoint wieder verschwindet, wenn er nicht mehr benötigt wird.

dein problem ist, dass durchaus noch programme auf den NFS mountpoint zugreifen, der mountpoint also nicht entfernt werden kann, solange diese programme noch laufen (device busy beim unmount).. Das NFS Protokoll sieht allerdings schon vor, dass ein server auch mal fuer eine gewisse zeit nicht erreichbar ist, ohne gleich alle zugriffe auf dateien mit einem fehler abzulehnen.

wenn du also den NFS Server stoppst, bleibt einem Client nicht anderes übrig, als darauf zu warten dass der wieder kommt. Die Prozesse selbst können natürlich wieder eigene timeouts haben, die solche schreib/lesezugriffe zeitlich beschränken.

Wenn du den NFS Server wieder startest, geht alles (wartende) weiter, als wär nie etwas gewesen.. (sofern korrekt konfiguriert) 8)

Der automounter spielt in dem Fall jedenfalls gar keine Rolle mehr.. Der versucht fröhlich im Hintergund all 5 Minuten den mountpoint wieder loszuwerden.. in dem fall erfolglos..

m.

p.s.: das timeo=300 in den mount optionen ist allerdings nochmal etwas anderes.. das sagt dem NFS-Client, dass dieser einen unbeantworteten NFS-Call an den Server nach 30 Sekunden wiederholen soll. Dies gilt allerdings nur fuer bestimmte Befehle - bei anderen variiert der Timeout zwischen 1.1 Sekunden und 60 Sekunden (timeout wird angepasst bis 60 Sekunden erreicht sind..) allerdings benutzt du NFS over TCP und da regelt eigentlich das TCP-Protokoll alles was du brauchst und die Befehle sollten nicht erneut gesendet werden.. aber die meldungen kommen scheinbar tortzdem wie bei udp gewohnt im syslog an.. 8) ist auch gut so...

[Azreth]

Okay, so weit habe ich mir das auch zusammengereimt. Ich kann mir trotzdem nicht erklären, warum die "Input/Output" Errors bzw. das Abbrechen der Operation nicht reproduzierbar ist, sondern jedes mal nach einer anderen Zeit passiert.

Und noch eine weitere Frage: macht es grundsätzlich Sinn den automount Dienst zu benutzen oder hat der irgendwo Nachteile? Wenn ich diesen 'hard' mounte, verhält der sich nach meinen Tests exakt wie das konstante mounten über die fstab, hat dabei aber Vorteile, was die Ressourcen angeht. Und vor allem startet der Client durch, auch wenn der Server mal nicht erreichbar sein sollte. Gibt es irgendwo Probleme/Haken?

Nochmal Danke und Gruß, Oliver

[mariux]

Woher genau die I/O Error kommen kann man vermutlich nicht pauschal sagen.. aber eine ursache kann natürlich sein, dass der Server sich nicht korrekt zurückmeldet, wenn er wieder kommt, wenn er jedoch wegbleibt ist das u.U. auch ein programmspezifisches verhalten nach eigenen Timeouts nen I/O Error zurückzugeben.. man weiss es nicht, wenn man den prozess nicht einfach mal traced.. oder sich die netzwerkpakete genauer anschaut, die als letztes vor dem I/O Error vorbeirauschen..

grundsätzlich zum automount: der geht.. wieso sollte er auch nicht.. in einer instabilen netzwerkumgebung kann es u.U. schon mal vorkommen, dass man ihn restarten muss, aber das kommt eher selten vor und dann meist nur, weil andere Probleme dies verursacht haben..

wir setzen ihn sehr erfolgreich seit jahr(zehnt)en ein.. gerade wenn man viele fileserver hat und daten sich gerne mal von einem zum anderen bewegen, lassen sich so sehr schön gewohnte mountpunkte erhalten..

am ende hast du nen überwachten mountpoint eines NFS Servers.. mehr macht der ja nicht.. kocht auch nur mit wasser 8)

aber den vorteil hast du schon genannt: wenn ein fileserver mal weg ist, fällt dies nicht negativ aus, da der mountpoint ja vielleicht gerade nicht in Benutzung ist - wenn er in Benutzung ist und der Server fällt aus ändert sich eigentlich nichts zum usecase ohne automounter..

gibt vielleicht schon andere möglichkeiten, die moderner oder trendiger sind, aber haben wir nicht evaluiert, da wir sehr zufrieden sind.. 8)

m.

[Azreth]

Danke für die Antwort. Das klingt ja so weit erstmal sehr positiv.

Eine Sache wurmt mich derzeit aber noch:

Für unsere SAP Landschaften ist es essentiell, dass das Rootverzeichnis der Mount-Point ist. Das lässt sich so aber irgendwie nicht realisieren. In meiner auto.master steht:

/ /etc/auto.misc --timeout 20

Gemountet wird jedoch gar nichts. Änder ich diesen Mount-Point auf eine tiefere Struktur, ist es jedoch problemlos möglich. Ist das ganze technisch bedignt oder gibt es dafür irgendeinen workaround?

Viel Dank und liebe Grüße schonmal.

[mariux]

das geht meines wissens nach wohl weniger.. in deinem ursprünglichen beispiel wuerde der automounter /data beobachten und da rein dann wieder ein data directory mounten... d.h. du endest mit /data/data als mountpoint fuers remote NFS...

ich glaube /(root) kann der automounter nicht beobachten da er da nen eigenen mountpoint reinhängen muss, um die "Magie" wirken zu lassen 8)

Möglichkeiten sind symlink und ggf. bind mount.. beim bind mount weiss ich nicht, wie dieser sich verhaelt auf Zielen, die verschwinden koennen.

ln -s /data /automountermountpoint/data .. sofern eure umgebung damit kein problem hat.. probleme koennten sein, dass bei der frage "wo bin ich" dann immer /automountermountpoint/data und nicht /data verwendet wird.. was korrekt ist, solange der mountpoint aktiv ist.. also meist kein problem... zumindest bei uns...

gruss marius..