Clustering und gemeinsamer Speicher #

Diese Seite ist für Systemadministratoren, die ein Exponential-Angebot mit mehr als einem Webserver gestalten oder betreiben, und für Produktmanager, die wissen müssen, was ein solches Angebot verlangt. Sie beantwortet: wie mehrere Server hochgeladene Dateien und Caches teilen, was der DFS-Cluster braucht (einen gemeinsamen Mount und eine Metadaten-Datenbank), wie Dateien ausgeliefert werden, welche Befehle den Cluster pflegen und wo die Grenzen liegen.

Warnung .htaccess bremst jede Anfrage. Sind .htaccess-Dateien erlaubt (AllowOverride alles außer None), geschweige denn genutzt, sucht Apache sie bei jeder Anfrage in jedem Verzeichnis des Pfads und liest und wertet sie aus, und die Ladezeiten der Seiten steigen drastisch (gemessen). Die einzige wirkliche Abhilfe ist, die Funktion für den virtuellen Host abzuschalten: AllowOverride None im virtuellen HTTPS-Host, und die Regeln in der Konfiguration des virtuellen Hosts selbst als mod_rewrite-Regeln. Das ist in Geschwindigkeitstests im Produktivbetrieb weit schneller und die Zeit für die Optimierung einer Produktivkonfiguration unbedingt wert. Stellen Sie sofort um: Übernehmen Sie die Regeln des Beispiels für einen virtuellen HTTPS-Host in Ihren virtuellen Host (mit dem statischen Cache auch staticcache_offload.conf), setzen Sie AllowOverride None, führen Sie apachectl configtest aus, laden Sie Apache neu und testen Sie die Website. Dieselben Regeln für andere Server: nginx, LiteSpeed, Caddy, IIS, Velocity (eingebaut); wohin Regeln für virtuelle Hosts in einem Control Panel gehören: Plesk, cPanel, DirectAdmin, ISPConfig. Unter LiteSpeed oder OpenLiteSpeed kann zusätzlich der Seiten-Cache des Servers anonyme Besucher und Crawler ohne PHP bedienen: Seiten-Caching mit LiteSpeed und OpenLiteSpeed.

Die Fakten stammen aus settings/file.ini, config.php-RECOMMENDED, den Cluster-Dokumenten in doc/eng-us/features/ und den Migrationskapiteln des Installationsbuchs. Die andere Hälfte einer Einrichtung mit mehreren Servern (Sitzungen, Caches vor PHP, Proxys) steht auf Mehrere Web-Knoten.

Inhalt #

1. Zwei Datei-Handler
2. Wie der DFS-Cluster funktioniert
3. Ihn einrichten
4. Dateien ausliefern: index_cluster.php
5. Wartungsbefehle
6. Worauf Sie achten
7. Checkliste

Zwei Datei-Handler #

file.ini [ClusteringSettings] FileHandler entscheidet, wie Exponential die Dateien von var/ liest und schreibt:

Die älteren Handler eZDBFileHandler und eZFS2FileHandler wurden entfernt; eine Website, die sie noch nutzt, wird so umgezogen, wie in Kapitel 14, der Cluster beschrieben.

Hinweis Ein einzelner Server braucht keinen Cluster-Datei-Handler, wie groß er auch ist. Clustering ist für eine Website, die mehrere Maschinen gleichzeitig ausliefern. Es fügt einen Mount und eine Datenbank hinzu, die betrieben, gesichert und überwacht werden müssen.

Wie der DFS-Cluster funktioniert #

Aus Anleitung zur Konfiguration des eZDFS-Clusters:

• Die Referenzkopie jeder geclusterten Datei liegt auf einem NFS-Export, auf jedem Webserver unter demselben Pfad eingehängt.
• Ihre Metadaten (Name, Größe, Änderungszeit, Ablauf) werden in einer Datenbanktabelle, ezdfsfile, gehalten.
• Cache-Dateien werden auf die lokale Festplatte des Servers kopiert, der sie nutzt.
• Bilder und Binärdateien, die ein Browser anfordert, werden vom Mount gestreamt.
• Die var-Verzeichnisse dürfen nicht zwischen den Servern geteilt werden: Jeder behält sein eigenes, und der Cluster-Handler hält sie mit der zentralen Kopie im Gleichschritt.

Die Metadaten-Datenbank kann der eigene Datenbankserver der Website oder ein getrennter sein; das Dokument merkt an, dass ein dedizierter MySQL-Server bei großen Websites die Leistung deutlich verbessern kann.

Datenbank-Backends #

Quelle: 15.17 Cluster und DFS und die in config.php-RECOMMENDED aufgeführten Backends (dfsmysqli, dfspostgres, dfsoracle). Auch die Speicherseite lässt sich ersetzen: [eZDFSClusteringSettings] DFSBackend nennt eine Klasse, die eZDFSFileHandlerDFSBackendInterface implementiert (Konfigurierbares Backend für den DFS-Cluster).

Hinweis Die eigene Datenbank der Website und die Metadaten-Datenbank des Clusters sind getrennte Entscheidungen. Eine Website auf PostgreSQL kann ihre Inhalte in PostgreSQL behalten; die Cluster-Tabelle braucht eines der Backends oben. SQLite kann überhaupt nicht die Datenbank einer Website mit mehreren Servern sein: Sein WAL-Modus braucht jeden Prozess auf einer Maschine (Kapitel 9).

Ihn einrichten #

1. Legen Sie die Tabelle an. Ihre Definition steht in der Klasse des MySQLi-Backends und ist im eZDFS-Dokument abgedruckt (CREATE TABLE ezdfsfile ..., InnoDB).

2. Hängen Sie den Export auf jedem Webserver unter demselben Pfad ein, für den Benutzer der Website beschreibbar.

3. Konfigurieren Sie den Handler in der globalen Überschreibung settings/override/file.ini.append.php. Cluster-Einstellungen müssen in dieser globalen Datei stehen, nicht in einer Erweiterung oder einem Siteaccess, wegen der Reihenfolge, in der Einstellungen gelesen werden:

   # settings/override/file.ini.append.php
   [ClusteringSettings]
   FileHandler=eZDFSFileHandler
   
   [eZDFSClusteringSettings]
   MountPointPath=/path/to/nfs
   DBBackend=eZDFSFileHandlerMySQLiBackend
   DBHost=<cluster database host>
   DBPort=3306
   DBName=<cluster database>
   DBUser=<user>
   DBPassword=<password>

   Die mitgelieferte Datei hat außerdem DBConnectRetries=3, DBExecuteRetries=20 und MaxCopyRetries=5.

4. Verschieben Sie die vorhandenen Dateien einmal in den Cluster: php bin/php/clusterize.php (siehe unten).

5. Richten Sie die Rewrite-Regeln für Dateien auf index_cluster.php und geben Sie ihr ihre Konstanten (nächster Abschnitt).

Bei einem Upgrade spielen Sie die Datei dbupdate-cluster-... jedes Schritts ein, der eine hat (11.3 Die Update-Dateien).

Dateien ausliefern: index_cluster.php #

Seit 4.7 liefert eine Datei im Document Root, index_cluster.php, Cluster-Dateien über HTTP aus (Überarbeiteter Cluster-Index). Sie liest config.php und, falls vorhanden, config.cluster.php und erwartet die Konstanten CLUSTER_*, die config.php-RECOMMENDED dokumentiert: CLUSTER_STORAGE_BACKEND (zum Beispiel dfsmysqli), CLUSTER_STORAGE_HOST, CLUSTER_STORAGE_PORT, CLUSTER_STORAGE_USER, CLUSTER_STORAGE_PASS, CLUSTER_STORAGE_DB und CLUSTER_MOUNT_POINT_PATH, dazu optionale Schalter wie CLUSTER_ENABLE_HTTP_CACHE und CLUSTER_EXPIRY_TIMEOUT.

Setzen Sie sie auf jedem Webserver von der Konsole aus, mit denselben Werten wie in [eZDFSClusteringSettings]. Jeder Befehl zeigt die Änderung als Diff, schreibt nur mit --apply, sichert config.php vorher nach var/backup/config/<zeit>/ und prüft die neue Datei mit php -l:

./console exp:setup:config --apply                           # einmal, solange es noch keine config.php gibt
./console exp:config:set CLUSTER_STORAGE_BACKEND dfsmysqli --apply
./console exp:config:set CLUSTER_STORAGE_HOST db1.example.com --apply
./console exp:config:set CLUSTER_STORAGE_PORT 3306 --apply
./console exp:config:set CLUSTER_STORAGE_USER <benutzer> --apply
./console exp:config:set CLUSTER_STORAGE_PASS --value="$CLUSTER_DB_PASS" --apply
./console exp:config:set CLUSTER_STORAGE_DB <cluster-datenbank> --apply
./console exp:config:set CLUSTER_MOUNT_POINT_PATH /path/to/nfs --apply
./console exp:config:list --only-set                         # das Passwort erscheint als ********
chmod 0640 config.php                                        # mit der Gruppe des Webservers

Das Passwort wird in jeder Ausgabe maskiert; der Befehl warnt, wenn es in einer config.php landet, die jeder Benutzer lesen kann. ./console exp:config:list --only-set --format=json liefert auf jedem Server ein Dokument, das Sie vergleichen können, um zu sehen, ob alle Web-Knoten übereinstimmen. Siehe .htaccess und config.php von der Konsole einrichten.

Der Webserver schickt ihr nur die Pfade, die seine Rewrite-Regeln nennen. Mit Caches pro Website in CacheVarDir fügen Sie auch deren öffentliche Caches hinzu (Cluster (DFS)):

RewriteRule ^/var_cache/([^/]+/)?cache/(texttoimage|public)/.* /index_cluster.php [L]

Warnung config.php, config.cluster.php und settings/override/file.ini.append.php enthalten Zugangsdaten zur Datenbank. Halten Sie sie aus der Versionsverwaltung heraus und aus jeder Datei, die ein Kunde herunterladen kann; die Sicherungen in var/backup/config/ enthalten frühere Kopien von config.php und brauchen dieselbe Sorgfalt.

Wartungsbefehle #

Führen Sie dfscleanup.php zuerst mit -S und -B aus und lesen Sie das Ergebnis, bevor Sie -D hinzufügen (15.17). clusterpurge.php ist auch der Cronjob-Teil cluster_maintenance; die mitgelieferten cronjob.ini [AdminSettings] ForbiddenParts[] halten ihn von den Schaltflächen auf Setup > Cronjobs fern, weil er zerstörerisch ist und in die Hände eines Administrators an einer Shell gehört (Cronjobs).

Worauf Sie achten #

• Der Mount. Wenn der NFS-Mount wegfällt, kann kein Server mehr Dateien lesen. Überwachen Sie den Mount und den NFS-Server als Teil der Website.
• Die Metadaten-Datenbank. Sie liegt auf dem Weg jedes Dateizugriffs; sie braucht dasselbe Backup und dieselbe Überwachung wie die Datenbank der Website.
• Konsistenz. Führen Sie dfscleanup.php -S und -B nach einem Vorfall und vor einer Migration aus.
• Cron pausieren. Die Pausendateien der Cronjobs sind auf jedem Server lokal, es sei denn, cronjob.ini [PauseSettings] Directory zeigt auf ein gemeinsames Verzeichnis (Cronjob-Teile pausieren).
• Cluster-Ereignisse. file.ini [ClusterEventsSettings] ClusterEvents=disabled ist ausgeschaltet ausgeliefert; mit einer Listener-Klasse lassen sie eine Erweiterung auf Cluster-Operationen reagieren, nur für den DFS-Cluster mit dem MySQLi-Backend (Cluster-Ereignisse).

Checkliste #

• To do: Der NFS-Export ist auf jedem Webserver unter demselben Pfad eingehängt, für den Benutzer der Website beschreibbar.
• To do: ezdfsfile existiert in der Metadaten-Datenbank, die gesichert und überwacht wird.
• To do: Die Cluster-Einstellungen stehen in der globalen settings/override/file.ini.append.php.
• To do: Jeder Server hat sein eigenes Verzeichnis var/; außer dem Mount wird nichts geteilt.
• To do: Die Rewrite-Regeln schicken Bilder und Binärdateien an index_cluster.php, die ihre Konstanten CLUSTER_* hat.
• To do: dfscleanup.php -S und -B melden nach clusterize.php keine Unterschiede.
• To do: clusterpurge.php läuft nach Zeitplan von nur einem Server.

Verwandte Seiten #

• Mehrere Web-Knoten
• Aufbau des Speichers
• Was gesichert werden muss
• Datenbanken in der offiziellen Reihenfolge
• Ein Hosting-Modell wählen
• .htaccess und config.php von der Konsole einrichten: exp:config:set für die Konstanten CLUSTER_*
• Datenbankunterstützung, Betriebssystemunterstützung
• Freie Dokumentation: Diese Seite darf unter der GNU FDL 1.3 frei kopiert, übersetzt und verbessert werden.