[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Webserver-Cluster / NFS Stale file handle



Am Dienstag, 16. März 2010 16:36:31 schrieb Helmuth Gronewold:
> Hallo Gruppe,
>
>
> ich betreibe einen "Apache Cluster" mit folgender Konfiguration:
>
> Drei Webnodes erhalten ihre Daten via NFS (/var/www und /var/lib/php5)
> und liefern diese mit Apache/mod_suphp aus. Ein dedizierter
> Load-Balancer (BalanceNG) verteilt die Anfragen an die Webnodes, die mit
> DSR antworten.
> Einer von zwei weiteren Utility-Servern, die jeweils Anbindung an ein
> iSCSI-Target haben auf dem die Sessions und Docroots liegen, exportieren
>    den iSCSI-Platz über NFS an die Webnodes.
> Da zwei Server vorhanden sind, die diese Aufgabe erledigen können, kann
> ich im Fehlerfall schnell umschalten.

Manuell ???

> Ich habe vorher OCFS2 benutzt und musste das, aus Gründen der
> Performance und Stabilität, leider abwählen.
> 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 :).

pacemaker / corosync ist das tool der Wahl. Es soll da bei O'Reilly ein ganz 
gutes Buch geben ;-)

> 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.

Warum NFS. Können die Serverknoten kein iSCSI direkt importieren? NFS macht 
die Sache nur langsamer.

> Vor der Umstellung habe ich mich natürlich schlau gemacht, welche Fehler
> häufig auftreten können und dabei ist mir vor allem "Stale NFS file
> handle" / "Stale NFS file system" aufgefallen.

Ja. Jemand muss dem Knoten schon sagen, dass das NFS nicht mehr existiert und 
er es unmounten soll. Wie gesagt, manuell oder über einen Cluster Resource 
Manager (pacemaker).

> Bisher hatte ich noch keine ernsten Probleme damit, doch gerade habe ich
> eine E-Mail von Cron erhalten, die mich etwas stutzig macht:
>
> ------
> 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
> [...]
> rm: cannot remove `/var/lib/php5/sess_eb56e7cf6e02555fbc6b9f1b29xxxxx':
> No such file or directory
> rm: cannot remove `/var/lib/php5/sess_da6aed4358562e00d7c521070f2xxxxx':
> No such file or directory
> rm: cannot remove `/var/lib/php5/sess_faff0fcc4e682666ac57f1ceb55xxxxx':
> No such file or directory
> [...]
> ------
>
> Mal ganz davon abgesehen, dass da die drei unteren Dateien nicht
> gelöscht werden können, was möglicherweise daran liegt, dass sich da
> zwei Cronjobs überschnitten haben: Das ganze hat sich offenbar selbst
> repariert. Die Dateien sind nicht mehr da und es gab keine Meldung zu
> Störungen im Betrieb.
> 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?
>
> Gibt es da Best Practices wie man mit "Stale file handle" bzw. "Stale
> file system" umgeht?

Ja: Einen richtegen Cluster bauen, so dass diese Fehler erst gar nicht 
auftreten.

> Ich habe ein Skript gefunden, welches via mount(8), timeout(1), ls(1)
> und ein bisschen Shell-Magie nach sieht, ob das gesamte Dateisystem noch
> in Ordnung ist oder nicht. Leider kann ich die Quelle gerade nicht
> finden. Ich habe das aber auf meinem PC zuhause und kann das evtl.
> nachreichen.

Das ist keine Lösung, sondern Stückwerk.

> 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=tc
>p,timeo=600,retrans=2,sec=sys,mountproto=udp" Gibt es da noch weitere
> Optionen oder Anpassungen, die evtl. noch
> sinnvoll sind?
> Kenndaten dazu:
> 145G Daten
> ~600k Dateien
> 80% der Zugriffe auf Dateien, die kleiner als 100kb sind.
>
> Mir fallen sicher noch ein Dutzend weitere Fragen ein, die die größe
> dieses Posts wohl zu hoch treiben würden. Daher einfach noch die bitte
> um Tipps und Tricks zu dem ganzen Thema Webserver-Cluster. Ich bin gerne
> bereit da Erfahrungen auszutauschen.

Bei weiteren Fragen gerne direkte Mail.

> Vielen Dank im Voraus und viele Grüße,
>
> Helmuth

-- 
Dr. Michael Schwartzkopff
MultiNET Services GmbH
Addresse: Bretonischer Ring 7; 85630 Grasbrunn; Germany
Tel: +49 - 89 - 45 69 11 0
Fax: +49 - 89 - 45 69 11 21
mob: +49 - 174 - 343 28 75

mail: misch@multinet.de
web: www.multinet.de

Sitz der Gesellschaft: 85630 Grasbrunn
Registergericht: Amtsgericht München HRB 114375
Geschäftsführer: Günter Jurgeneit, Hubert Martens

---

PGP Fingerprint: F919 3919 FF12 ED5A 2801 DEA6 AA77 57A4 EDD8 979B
Skype: misch42


Reply to: