Am Dienstag 16 März 2010 schrieb Helmuth Gronewold: > Hallo Gruppe, Hallo Helmuth! > 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. 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. > 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 ;). > 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. > 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. NFS bis Version 3 nimmt aus Minor/Major/Inode-Nummern zusammengesetzte NFS Handles, um nach dem ersten Zugriff einer Datei immer wieder auf diese Datei zuzugreifen. Ändert sich an Minor/Major/Inode-Nummer etwas, etwa wie bei unserem initialien NFS-Failover ohne fsid, das die Minor/Major-Nummern ersetzt, gibts zu NFS Handles, die die Clients noch verwenden, keine Entsprechungen mehr auf dem (gewechselten) NFS-Server. > 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 > [...] > ------ Wir betreiben so Session-Verzeichnisse aus - glaub guten - Gründen, die mir grad nicht mehr genau präsent sind, mit der NFS-Option "nolock". ;) 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? Ciao, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
Attachment:
signature.asc
Description: This is a digitally signed message part.