Sonntag, den 15. April 2012 13:37 Alter: 6 Monat(e)
Kategorie: Clustering
Submitting your vote...
Rating: 4.3 von 5. 3 Stimme(n).
Artikel bewerten.

Gemeinsame Ressourcen für TYPO3-Instanzen im Cluster per NFS bereitstellen

TYPO3 legt wichtige Daten wie Bilder oder Einstellungen auch im Dateisystem ab. Wer die Anfragen auf mehrere Webserver verteilen will muss diese Daten allen Systemen möglichst synchron zur Verfügung stellen. NFS ist ein simpler und effizienter Ansatz dafür.


NFS-Share auf Loadbalancer

Nach einigen Artikeln über Performance-Messungen bei TYPO3-Systemen möchte ich den ersten Beitrag über Lösungsansätze beim Clustering größerer Projekte schreiben. Den hier beschriebene Ansatz habe ich vor einiger Zeit zusammen mit Technikern bei einem Kunden so entworfen. Er ist seit über einem Jahr in einem Setup aus insgesamt 6 Servern erfolgreich im Einsatz.

1) Einrichtung von NFS auf Server und Client

Die Einrichtung eines NFS-Speichers ist sehr einfach.

a) NFS-Server:

Auf Debian oder Ubuntu-Servern wird das Paket
nfs-kernel-server
benötigt.
Die Freigabe der Ressoucen erfolgt über die Datei /etc/exports

  1. /data/share   10.10.10.0/255.255.255.0(rw,sync,all_squash,anonuid=33,anongid=33,subtree_check)

  • /data/share ist das Verzeichnis mit den gemeinsamen Dateien
  • 10.10.10.0/255.255.255.0 ist der Netzbereich aus dem wir Zugriffe zulassen
  • rw bedeutet, dass wir lesende und schreibende Zugriffe zulassen
  • sync bedeutet, dass eine schreibende Operation erst als abgeschlossen quittiert wird, wenn die Daten wirklich auf der Festplatte sind und nicht nur übers Netzwerk vom Server empfangen. Diese Option ist die stabilere.
  • all_squash wird gesetzt, dass alle User die Userids  anonuid, und  anongid, in unserem Fall die 33 des Apache-Diesnstes verwenden.
  • subtree_check ist eine Sicherheitsoption. Da die Webserver direkt möglichen Angreifern ausgesetzt sind, und über den NFS-Mount Zugriff auf das Dateisystem des NFS-Servers möglich sind, ist es in den meisten Fällen ratsam subtree_checks zu aktivieren.

 

b) NFS-Client

Auf dem Client kann das Verzeichnis einfach über die fstab (/etc/fstab) eingebunden werden:
In den meisten Fällen sollte die Zeile

  1. 10.10.10.100:/data/share /data/share  nfs auto  0   0

ausreichen sein

  • 10.10.10.100 ist dabei die Adresse des NFS-Servers
  • :/data/share das exportierte Ordner auf dem Server
  • /data/share der lokale Ordner
  • nfs das Dateisystem aus Sicht des Clients
  • auto bedeutet, dass das System automatisch eingebunden wird
  • die beiden Nullen geben an, dass das Programm dump bei Backup den Mountpunkt nicht berücksichtigen soll und wir bei Start keine Filesystemchecks durchführen wollen. Für beides ist der Server zuständig.


Welche Ressourcen neben der Datenbank auf allen Webservern automatisiert synchron gehalten werden müssen hängt stark vom Einsatzszenario ab.

2) Einsatzszenarien für NFS

a) Das ganze Dateisystem auf zentralem NFS-Mount


Ein einfacher Ansatz ist es den gesamten Inhalt des Dateisystems synchron zu halten. Die Vorteile liegen auf der Hand. Alle Ressourcen sind auf einem System. Backups können zentral geholt werden, Updates können einfach installiert werden. Bilder müssen nicht mehrfach gerendert werden.
Ein möglicher Nachteil ist jedoch, dass das zentrale System auch einen Single Point of Failure darstellt, und die Webserverinstanzen selbst nicht mehr für Hochverfügbarkeit sorgen können.
Ein weiterer Nachteil ist, dass der PHP-Interpreter zum parsen der Scripte über das Netzwerk auf diese zugreifen muss. Dabei können die zusätzlichen Latenzen die Auslieferung begrenzen, oder das Dateisystem des NFS-Servers zum Flaschenhals werden.
Für einen einfachen Test habe ich einen einzelnen Webserver das komplette typo3-Verzeichnis einmal über einen NFS-Mount (Gbit-Netzwerk) und einmal lokal laden lassen.
Wie die Grafiken zeigen, ist das System über den NFS-Mount ca. 30% langsamer. Die Ergebnisse relativieren sich etwas, wenn ich das OP-Code Caching über APC aktiviere. Jetzt muss nicht mehr jedes php-Script über das Netzwerk geparst werden. Die Geschwindigkeit sinkt beim Zugriff über das Netzwerk nur noch um ca. 15-20%.

NFS ohne APCOhne NFS, ohne APC

NFS mit APCOhne NFS mit APC

b) Nur ausgewählte Verzeichnisse auf den zentralen NFS-Mount

Zwar ist zum Beispiel der TYPO3-Core einer Webseite auf allen eingesetzten Webservern identisch, ändert sich jedoch nur bei Updates. Es ist nicht unbedingt notwendig ihn automatisch und in Echtzeit synchron zu halten.
Je Nachdem welche Dateien Redakteure einer Webseite ändern, bietet es sich an folgende Verzeichnisse zentral vorzuhalten:

  • fileadmin
  • typo3temp
  • uploads
  • typo3conf

typo3conf auf den NFS-Mount zu legen ist nur dann notwendig, wenn Redakteure selbst Änderungen in diesem Ordner (zum Beispiel das Installieren von Erweiterungen) vornehmen können. In jedem Fall erleichtert es die Konfiguration sehr diesen Ordner zentral vorzuhalten.
Werden nur diese 4 Ordner auf den NFS-Server gelegt, kann ich keine Geschwindigkeitsunterschiede zu einem vollständig lokalen Filesystem mehr messen.

Um die Geschwindigkeit dieses Szenarios zu ausführlicher zu testen, habe ich zwei identische Webserver hinter einen Loadbalancer geschaltet. Auf dem Loadbalancer selbst liegt auch die NFS-Freigabe mit allen vier oben erwähnten Ordnern. Nun wollte ich wissen ob das System auch skaliert wenn mehr als ein Webserver auf die Dateifreigabe zugreift.
Die Messung zeigt, dass der Durchsatz von zwei Webservern mit gemeinsamen NFS-Mount fast exakt doppelt so groß ist wie der eines einzelnen Servers mit lokalem Speicher.

Ein Webserver ohne NFSZwei Webserver mit gemeinsamen NFS-Share

Fazit:

Eine NFS-Freigabe ist leicht zu konfigurieren und sehr kostengünstig. Wer mehr als einen Webserver einsetzt, hat in der Regel einen Loadbalancer vor den Webservern. Ist der Loadbalancer eine eigenständiges System, wird es in den meisten Fällen auch den gemeinsamen Datenspeicher zur Verfügung stellen können ohne zum Engpass zu werden.


keine Kommentare
Kommentar schreiben

* Bitte ausfüllen

*

*