Re: Webserver-Cluster / NFS Stale file handle
Hallo,
Helmuth Gronewold <cisa.85@arcor.de>:
>Dadurch habe ich keine Hochverfügbarkeit mehr, kann aber, wie oben
>beschrieben, sehr schnell umschalten auf ein anderes System.
>Wahrscheinlich kann man da auch etwas mit heartbeat bauen, damit habe
>ich aber noch gar keine Erfahrung (für Tipps / Links dazu wäre ich sehr
>dankbar :).
Wie schon geschrieben wurde, ist die Kombination Pacemaker+Corosync eine
gute Wahl. Für einen 2-node Cluster ist auch Pacemaker+Heartbeat3 nicht
schlecht.
>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.
>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?
Wenn man die Session IDs im Shared Storage hält, sollte man die
deaktivieren. Ansonsten kann es passieren, dass ein Webserver das Handle
bereits gelöscht hat, während ein anderer es noch offen hält. 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.
>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.
>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.
Am besten mountest du den Share /var/www read-only; der Webserver muss ja
hier normalerweise nichts schreiben.
Ich würde außerdem die rsize und wsize verkleinern (z.B. 8192).
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.
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.
Ich würde noch actimeo=10 setzen.
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).
Dann kann eigentlich nicht mehr viel schief gehen. ;-)
Gruß, Harald
Reply to: