Re: Webserver-Cluster / NFS Stale file handle
Hallo Martin,
Martin Steigerwald schrieb:
Am Dienstag 16 März 2010 schrieb Helmuth Gronewold:
ich betreibe einen "Apache Cluster" mit folgender Konfiguration:
[...]
Ich helfe einem Kunden, dem wir einen Webcluster gebaut haben, gerade
dabei, den von Debian Etch auf Debian Lenny zu aktualisieren. Wir nutzen
ebenfalls NFS. Der Cluster ist schon seit bestimmt 3-4 Jahren in Betrieb.
Wir haben zwei Backend-Server im HeartBeat-Betrieb. Der eine macht NFS,
der andere MySQL. Es sei denn einer fällt aus, dann übernimmt er den
Betrieb des anderen. NFS und MySQL der Backend-Server sind weitgehend nur
für Schreibzugriffe, der Kunde hat seine PHP-Applikationen weitest möglich
angepasst. Die Middleware-Server halten statischen Content sowie Nur-Lese-
MySQL-Datenbanken lokal vor. Die Backends nutzen rsync und MySQL-
Replikation um die Lese-Daten auf die Middleware-Server zu bringen.
MySQL betreibe ich zur Zeit noch direkt auf den Webnodes. Umschalten per
Hand ist mir wirklich lieber.
Ansonsten war es das. Vielleicht möchte ich irgendwann noch einen Cache
davor, der mir dann die ganzen Grafiken vorhält, aber bislang ist das
nicht nötig.
Hier läuft übrigens nicht nur eine Applikation. Man kann das was ich
hier betreibe besser als shared Webhosting bezeichnen. Auch wenn da nur
bekannter Code liegt.
Ich habe vorher OCFS2 benutzt und musste das, aus Gründen der
Performance und Stabilität, leider abwählen.
Die Backend-Server greifen via Fibre Channel über Kreuz auf zwei Hardware-
RAID-Arrays zu, über das wir ein SoftRAID 1 legten, um die Daten an beiden
Standorten synchron zu halten. Der eine holt sich das NFS-LVM-Laufwerk,
der andere das für die MYSQL-Daten. Fällt einer aus, schaltet das andere
Backend ihn aus und holt sich sein LVM-Laufwerk. Damit das mit NFS klappt,
braucht es die Export-Option fsid ;).
Das ist natürlich ein nettes Setup. Hier ist das so, dass dahinter eine
NetApp steht die via iSCSI exportiert. Die NetApp ist gespiegelt. Da ist
also SAN und NFS-Server sind also redundant ausgelegt.
Dadurch habe ich keine Hochverfügbarkeit mehr, kann aber, wie oben
beschrieben, sehr schnell umschalten auf ein anderes System.
Wir haben NFS und Hochverfügbarkeit.
Mir reicht es, wenn ich schnell wieder Online bin. Auch wenn das per
Hand umgeschaltet werden muss.
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.
Das hatten wir nach einem Failover, bevor ich die NFS-Export-Option fsid
gefunden hab.
Ah, ok. Werd ich mir auch mal ansehen. Vielleicht ist das irgendwann
wichtig.
------
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
[...]
------
Wir betreiben so Session-Verzeichnisse aus - glaub guten - Gründen, die
mir grad nicht mehr genau präsent sind, mit der NFS-Option "nolock". ;)
Das könnte ich wahrscheinlich auch machen. Der Load-Balancer verteilt
Sessionbasiert. So sollte ein Benutzer immer auf der gleichen Node
bleiben, vorausgesetzt die Node fällt nicht aus ;)
In dem Fall war es aber ein Cronjob der das Problem verursacht hat...
Die sind übrigens via php.ini-Option auch auf ein anderes Verzeichnis
umbiegbar. Hast Du nur /var/lib/php5 auf NFS gemountet, oder das ganze
/var?
Nein. Ich habe momentan das NFS auf /mnt/ocfs2 gemounted (muss ich mal
säubern und umbenennen). Von da aus mache ich bind-mounts auf /var/www
und /var/lib/php5.
Vielen Dank und viele Grüße,
Helmuth
Reply to: