Re: Webserver-Cluster / NFS Stale file handle
Hallo Harald,
Harald Weidner schrieb:
Helmuth Gronewold <cisa.85@arcor.de>:
Umgestellt auf NFS habe ich erst vor zwei Wochen, daher bin ich damit
noch ein bisschen unsicher unterwegs. Ich setze zwar NFS schon sehr
lange ein, aber immer nur in sehr kleinen Umgebungen wo entweder kein
konkurrierender Schreibzugriff anfällt oder nur wenig Daten übertragen
werden.
Ich kann dich beruhigen. Bei meinem Hauptkunden läuft ein vergleichbares
Konstrukt mit mehreren Dutzend Web- und Tomcat-Servern, die den Content von
einem gemeinsamen NFS Share ausspielen. Das ganze ist sehr stabil und
erreicht eine ziemlich hohe Verfügbarkeit.
Ok, ich hatte mir das auch so vorgestellt. Leider liest man im Netz aber
nicht all zu häufig von Erfahrungen mit so einer Art von
Webserver-Cluster. Es scheint als würden solche Setups immer im
Unternehmen oder einfach nur nicht dokumentiert sein.
find: `/var/lib/php5/sess_82fef1ae9e8da34eb3363197306xxxx': Stale NFS file handle
find: `/var/lib/php5/sess_061e796d83522938d38274d79bcxxxx': Stale NFS file handle
find: `/var/lib/php5/sess_678cb2e7f33d2bc9375a731109xxxxx': Stale NFS file handle
Kann es sein, dass du die automatische Garbage Collection des PHP
Interpreters eingeschaltet hast?
Diesmal nicht :)
Es ist empfehlenswert, die alten IDs statt dessen per Cron-Job zu löschen,
und zwar auf genau einem System. Bei deinem Setup bietet es sich an,
den Job auf dem Fileserver laufen zu lassen.
Die dritte Node ist erst kürzlich hinzugekommen. Ich synchronisiere die
Konfigurationsdateien mit csync2. Anscheinend hat der aber
/etc/cron.d/php5 nicht angepasst. Daher lief dieser Cronjob auf zwei
Systemen...
Ich hatte das so verstanden, dass bei einem "Stale NFS file handle" oder
"Stale NFS file system" nichts mehr geht und ich das Dateisystem neu
mounten muss.
Ist das falsch?
Einen NFS Share muss man wegen seiner Zustandslosigkeit so gut wie nie neu
mounten. In diesem Fall bezieht sich der Fehler auf einzelne Dateihandles;
sobald der Prozess den File Descriptor schließt, ist das Problem vergessen.
Das erklärt dann ja, warum es da keine weiteren Probleme gab.
Ich benutze als Optionen für mount nur "defaults,sync,auto,_netdev".
Debian scheint daraus die folgenden Optionen zu machen:
"rw,sync,vers=3,rsize=1048576,wsize=1048576,namlen=255,hard,nointr,proto=tcp,timeo=600,retrans=2,sec=sys,mountproto=udp"
Gibt es da noch weitere Optionen oder Anpassungen, die evtl. noch
sinnvoll sind?
Wenn du sync mountest, ist auch noatime zu empfehlen. Ansonsten löst jeder
Lesezugriff einen blockierenden Schreibzugriff für die atime aus.
HA! Das habe ich vergessen. Das war bei OCFS2 auch an.
Am besten mountest du den Share /var/www read-only; der Webserver muss ja
hier normalerweise nichts schreiben.
Das ist in diesem Fall ganz anders. Dort werden häufig auch temporäre
Dateien generiert und neue Dateien hochgeladen.
Ich würde außerdem die rsize und wsize verkleinern (z.B. 8192).
Sind das die Werte in 100MBit Netzen? Ich muss da gleich erstmal
nachlesen...
In stabilen Netzen ist proto=udp meistens schneller aus tcp. Es hat außerdem
den Vorteil, dass, wenn der NFS-Servercluster korrekt aufgesetzt ist, ein
Clusterschwenk Client-seitig völlig unbemerkt abläuft.
Das werde ich dann mal testen. Das Netz ist überschaubar groß, es sollte
stabil sein.
hard+nointr hat den Nachteil, dass sich die Prozesse auf den Webservern
nicht mehr sauber beenden lassen, wenn der NFS Server mal nicht erreichbar
ist. soft oder hard+intr behebt dieses Problem; kann aber u.U. dazu führen,
dass eine Dateioperation das falsche Ergebnis liefert und der Prozess damit
weiter arbeitet. Meiner Meinung nach ist das bei einem reinen Webserver aber
egal.
Das finde ich sehr interessant. Ich habe darüber einiges in Foren durch
Suchmaschinengebrauch gesehen. Dort haben Benutzer berichtet, dass ein
SIGKILL z.B nicht funktioniert hat.
Das wäre hier wahrscheinlich irgendwann mal sauer aufgestoßen.
Ich würde noch actimeo=10 setzen.
Da muss ich auch erstmal lesen, danke :)
Last not least sollte man
http://www.cc.gatech.edu/classes/AY2007/cs4210_fall/papers/nfsOLS.pdf
gelesen und verstanden haben (und insbesondere Kap. 6 "Cache Consistency"
bei der PHP Programmierung berücksichtigen).
Vielen Dank, ich habe reingeschnuppert - scheint sehr informativ zu sein.
Dann kann eigentlich nicht mehr viel schief gehen. ;-)
Das will ich hoffen. Mit OCFS2 ist schon genug in die Hose gegangen :)
Da hat sich mit NFS schon einiges geändert. Gerade Backups, welche ich
mit rsync mache, dauern jetzt keine zwei bis drei Stunden mehr sondern
nur noch 20 Minuten.
Viele Grüße,
Helmuth
Reply to: