verteiltes Dateisystem / distributed file system

[Cerox]

Hallo SSF,

ich habe die letzten Wochen immer mal wieder bezüglich distributed file systems recherchiert und wollte mal nach euren Erfahrungen fragen.

Ich bin darauf gekommen, als ich nach Möglichkeiten gesucht habe um Wordpress zu skalieren. Da Wordpress nicht stateless ist, ist ein normales skalieren nicht möglich. Es gibt Möglichkeiten die Bilder für die Posts direkt extern hochzuladen. Was ist aber, wenn Plugins installiert werden oder ein Update nötig ist?
Daher die Frage ob es sinnvoll ist /var/www direkt auf einem distributed file system zu speichern und so skalieren zu können?

Für andere Vorschläge bezüglich der Wordpress-Problematik bin ich natürlich auch offen

 

[PapaBaer]

Hi,

Wordpress zu clustern ist meiner Erfahrung nach ein Krampf. Die Probleme hast du bereits selbst aufgezeigt. Wir behelfen uns zur Zeit tatsächlich mit NFS quer über die App-Server. Perspektivisch zeichnet sich ab, dass man auch Ceph für diesen Einsatzzweck nutzen könnte. Das macht aber nur Sinn, wenn man sowieso schon einen Storage-Cluster damit fährt.

Obendrein hat man bei Wordpress das Problem, dass die Nasen meinten, sie könnten Sessions besser als PHP selbst. Also haben sie mal eben den Session-Store glatt gebügelt und neu implementiert. In der Folge bekommt man Wordpress-Sessions nicht einfach in einen Memcached. Da gibt es zwar auch wieder Plugins, die nochmal eigene Logik implementieren, aber wer will das schon. Wir nutzen als Workaround haproxy mit Sticky-Session: http://blog.exceliance.fr/2012/03/2...stence-sticky-sessions-what-you-need-to-know/

Es gibt Möglichkeiten die Bilder für die Posts direkt extern hochzuladen.

Hast du dazu mehr Informationen?

 

[Thunderbyte]

Die Files sind bei großen WP Netzwerkinstallationen nur ein Teil des Problems.

http://premium.wpmudev.org/blog/scaling-wordpress-wpmu-buddypress-like-edublogs/

 

[marce]

wobei man da zugestehen muss, daß das nicht ein nur-WP-Problem ist - die meisten CMS sind, wenn man sie über mehrere Server clustern will (und alle wirklich gleichberechtigt sein sollen) ein ordentlicher Krampf.

In der Standard-Variante geht das so gut wie nie ohne Verrenkungen.

 

[Thunderbyte]

De facto sollte man doch erst mal alles, was auf einem Server möglich ist, ausnutzen, bevor man über verteilte Strukturen nachdenkt.

Das fängt mit den WP eigenen Cache Mechanismen und Optimierungsmöglichkeiten an. Geht weiter mit HW Optimierungen (viel RAM, SSDs, Raid10 oder schnelleres).

Ein nächster (immer noch vergleichsweise einfacher) Schritt könnte sein, Datenbank(en), WP Files und Medien (Bilder, Files, etc.) auf eigene Server zu verteilen.

Dann kann man noch so praktische Dinge wie Cloudflare nutzen und damit die Last auf den eigenen Ressourcen reduzieren.

Und erst wenn all das nicht mehr ausreicht, kann man über Parallelisierung nachdenken.

 

[marce]

naja, das Problem fängt ja schon früher an - wenn man z.B. daran denkt, Systeme parallel im Hotstandby/Failover-Betrieb aufzusetzen...

 

[PapaBaer]

die meisten CMS sind, wenn man sie über mehrere Server clustern will (und alle wirklich gleichberechtigt sein sollen) ein ordentlicher Krampf.

Es gibt durchaus Systeme, die sauber und konsequent shared-nothing umsetzen und genau das sind die Details, an denen sich Qualität zeigt. Als Beispiel sei hier Zope/Plone genannt, die über zeo auch Binärdaten wegspeichern. Man kann eigentlich in allen Frameworks Blobs vernünftig in Backends absenken, ohne sie plump auf Platte zu nageln.

De facto sollte man doch erst mal alles, was auf einem Server möglich ist, ausnutzen, bevor man über verteilte Strukturen nachdenkt.

Soweit gebe ich dir recht.

Geht weiter mit HW Optimierungen (viel RAM, SSDs, Raid10 oder schnelleres).

Und hier muss ich leider widersprechen. Du sprichst hier von vertikaler Skalierung. Der Ansatz hat drei Haken:
1. Vertikale Skalierung ist per Definition endlich. Irgendwann kannst du bei steigender Last nicht weiter skalieren.
2. Vertikale Skalierung ist nicht linear, da die Performance immer von vielen Fakten abhängt. Klar kannst du eine größere Platte einbauen, aber davon wird die IO-Rate auch nicht besser.
3. Vertikale Skalierung führt zu heterogenen Umgebungen. Wenn du jedes System auf den speziellen Anwendungsfall optimierst, hast du am Ende einen kaum handhabbaren Hardware-Zoo

Die alternative ist horizontale Skalierung, also Clustern über Nodes. Das kannst du prinzipiell unendlich machen und wenn die Anwendung sauber gestrickt ist, geht das auch fast linear. Wie oben bereits geschrieben: Geht natürlich nur mit shared-nothing, und da brauchste den PHP-Pfuschern nix erzählen...

 

[Cerox]

http://blog.exceliance.fr/2012/03/2...stence-sticky-sessions-what-you-need-to-know/

Die Inhalte davon kannte ich schon. Danke

Hast du dazu mehr Informationen?

z.B. dieses Plugin http://wordpress.org/plugins/amazon-s3-and-cloudfront/
Lädt dann alle Uploads aus dem Backend zu S3 hoch, gibt es aber auch für andere Clouddienste / FTP / usw.

Das Problem steckt für mich auch nicht in den Media Dateien, sondern eher in den Template / Plugin Dateien.

Die Files sind bei großen WP Netzwerkinstallationen nur ein Teil des Problems.

http://premium.wpmudev.org/blog/scaling-wordpress-wpmu-buddypress-like-edublogs/

Danke für den Link!
Kannte ich allerdings schon, genauso wie einige Videos von den Wordcamps und wie wordpress.com ihre Infrastruktur aufgebaut haben.

wobei man da zugestehen muss, daß das nicht ein nur-WP-Problem ist - die meisten CMS sind, wenn man sie über mehrere Server clustern will (und alle wirklich gleichberechtigt sein sollen) ein ordentlicher Krampf.

In der Standard-Variante geht das so gut wie nie ohne Verrenkungen.

Das ist leider wahr. Ich dachte allerdings das die Verbreitung von Wordpress so groß ist dass es mehr Leute gibt die das schon getestet haben.

@Thunderbyte
Das Problem bei der Herangehensweise ist, dass das Problem nur nach hinten geschoben wird oder wenn man Pech hat der Server einfach der Last nicht gewachsen ist und dann Tage / Wochen erstmal gar nichts funktioniert...


Es geht auch nicht unbedingt um eine Wordpress Installation, sondern um hunderte und wenn ein vernünftiges Scaling betrieben werden kann gegebenenfalls auch um tausende.
Dies soll durch eine Wordpress Multitenancy Installation erfolgen, um die Wartung des Cores möglichst einfach zu halten.
Wie auch schon angemerkt wurde gibt es folgende Probleme zu meistern:

• Media Daten; Lösung: S3 / Fileserver / Sync zwischen den Instanzen / verteiltes Dateisystem(?)
• Sessions; Lösung: Memcached / Redis
• PHP / HTML Dateien außerhalb des Cores (Themes, Plugins)

Das größte Problem stellt für mich momentan die Plugin und Theme Dateien da, da sie trotz Opcode-Cache immer auf Gültigkeit gecheckt werden und somit bei einem verteilten Dateisystem z.B. health checks auslösen.
Davon ab ist die Read-Performance von allen verteilten Dateisystemen was ich so gelesen habe nicht optimal, alleine durch die Netzwerk-Latenz im Gegensatz zu lokalen Platten.
Ich habe bisher noch kein verteiltes Dateisystem selbst getestet, sondern nur viel mit Google recherchiert. Kennt evtl jemand eins was dafür zu gebrauchen wäre? Meistens läuft man bei der Recherche GlusterFS über den Weg, was wohl auch genutzt wird, aber die oben genannten Probleme hat (wobei die Blogeinträge usw. auch schon ~2 Jahre alt waren).
Es geht wie gesagt auch primär um die PHP / HTML Theme- und Plugin-Dateien.
Die Media Dateien aus den Uploads werden eh durch einen varnish / nginx reverse Proxy gejagt und gecached.