CCM19 im Cluster - Hochverfügbar

Grundsätzlich lässt sich CCM19 auch problemlos im Cluster betreiben. Die CCM19-Cloud läuft ebenfalls in einem Hochverfügbarkeits-Cluster mit Loadbalancer und diversen dahinter stehenden Servern, die zusammen die Last tragen. Generell empfehlen wir die Verwendung von Ansible für das Management der/des Server(s).

Diese Technologie lässt sich auch mit der Standard Agentur-Version abbilden, es braucht allerdings ein paar wenige Anpassungen.

Grundsätzlich muss entschieden werden, auf welche Struktur man aufsetzen möchte. CCM19 läuft sowohl mit einem dateibasiertem Ansatz mit JSON-Dateien oder mit einer MongoDB.

Falls Sie planen irgendwann einmal mehr als 1000 Domains zu verwalten, sollten Sie direkt mit einer MongoDB arbeiten – selbst wenn Sie zum Start nur einen Server nutzen. Ein Umzug von JSON auf MongoDB ist nicht trivial und erfordert einiges an Arbeit.

Bei der Installation und Verwaltung gehen wir davon aus, dass die verwendeten Server über einen Apache Webserver mit PHP verfügen. Im Falle der Nutzung von MongoDB muss natürlich auch dieser Datenbank mit den entsprechenden PHP libs installiert sein. Beachten Sie dabei, dass die Anforderungen bzgl. des Traffics hoch sind und optimieren Sie den Zugriff dementsprechend auf Ihren Servern.

Sinnvoll ist die Verwendung von

- php-fpm - Caching-Modul für Apache, Cache-Speicher im RAM z.B. tmpfs - Entschlacken nicht notwendiger PHP- und Apache-Module - Optimierung von Kernel-Settings wie z.B. Anzahl der max. möglichen Prozesse, Anzahl der möglichen Verbindungen über die Netzwerkkarte

Dateibasierter Cluster

Ein dateibasierter Cluster ist mit verteilten Dateisystemen wie GlusterFS möglich.

Hierfür muss vor der Installation in der ccm19-Zip-Datei die .env.local ergänzt werden:

Zunächst um die Cluster-Mitglieder. Das ist nötig, damit die Instanzen im Cluster beispielsweise ihre Caches synchronisieren können. Beispielsweise bei zwei Cluster-Mitgliedern auf 192.168.0.4 und 192.168.0.5, bei denen die CCM19-Installation jeweils direkt im HTTP-Root installiert ist:

APP_CLUSTER_PEERS='http://192.168.0.4 http://192.168.0.5'

Mehrere URLs werden durch Leerzeichen getrennt, es funktioniert aber auch mit nur einer. Nötig sind prinzipiell nur die URLs der jeweils anderen Instanzen im Cluster.

APP_BUNDLE_VAR=1

Damit zeigt man an dass die zentralen Daten die Verzeichnis var/config<nt>-</nt>bundle gespeichert werden. Dieses Verzeichnis muss dann via z.B. GlusterFS synchron zwischen allen Instanzen gehalten werden.

Den session_save_path() sollte man dann in das Verzeichnis /var/config<nt>-</nt>bundle/tmp/ legen. So kann man sich einloggen und der Loginzustand bleibt auch beim Wechsel der Zugriffe auf die unterschiedlichen Cluster-Teile erhalten.

Cluster mit MongoDB

Die Installation mit MongoDB erfolgt schon über die Installations-Oberfläche und erfordert keine besonderen Einstellungen. Wir empfehlen die Einrichtung der MongoDB-Replicas direkt auf den Webservern, auf denen auch CCM19 installiert ist. So kann der Lesezugriff immer direkt über Unix-Domain-Sockets erfolgen, was die Zugriffe deutlich beschleunigt.

Auch bei dieser Variante muss die .env.local auf allen Instanzen im Cluster ergänzt werden (Details s.o.):

APP_CLUSTER_PEERS='http://192.168.1.2 http://192.168.1.1'

Für die höchste Ausfallsicherheit sollten in der .env.local jeder Cluster-Instanz auch die Adressen aller MongoDB-Replicas in Präferenzreihenfolge angegeben werden. Beispielsweise bei zwei MongoDB-Replicas auf 192.168.1.1 und 192.168.1.2 je auf Port 27017, zusätzlich erreichbar über den Unix-Domain-Socket "/var/run/mongodb/mongod.sock" auf dem jeweiligen Webserver:

APP_MONGODB_CONNECTION_STRING='mongodb://user:password@%2Frun%2Fmongodb%2Fmongod.sock,192.168.1.1:27017,192.168.1.2:27017'

Die initiale Konfiguration eines MongoDB-Replica-Clusters wird ausführlich in der Dokumentation von MongoDB erläutert und deshalb hier nicht weiter behandelt.

Serverseitige Cronjobs

Standardmäßig werden regelmäßig auszuführende Aufgaben (Cronjobs) durch zufällig ausgewählte Frontend-Anfragen ausgelöst. Bei einer Cluster-Installation kann das dazu führen, dass je nach Verteilung der Anfragen auf die Server, einige Cronjobs zu selten ausgelöst werden.

Deshalb empfehlen wir, in Clustern serverseitige Cronjobs (z.B. in der Crontab oder als Systemd-Timer) einzurichten, bei denen bin/console app:cron:run <nt>-</nt><nt>-</nt>timeout 15 auf jeder Instanz alle 2-5 Minuten ausgeführt wird. Der Timeout-Parameter gibt die maximale Laufzeit jedes Durchlaufs an. Die Cronjobs sollten so eingerichtet werden, dass sie gestaffelt und möglichst nicht exakt gleichzeitig auf allen Servern laufen.

Sobald die serverseitigen Cronjobs eingerichtet und getestet wurden, kann die Frontend-Auslösung der Cronjobs durch einen Eintrag in .env.local deaktiviert werden:

APP_CRON_MODE=server