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

Wir empfehlen MongoDB für den Betrieb von CCM19 in einem Cluster. Für weitere Informationen siehe nachfolgender Abschnitt.

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-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-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.

Session-Handling

Im Cluster-Betrieb muss sichergestellt werden, dass entweder Sticky-Sessions im Load-Balancer eingerichtet sind, also Clients immer auf derselben CCM19-Instanz landen, oder eine gemeinsame Redis-Datenbank für die Sessions verwendet wird.

Für die Verwendung von Redis sind folgende Anpassungen an der .env.local bei allen Instanzen des Clusters erforderlich:

Die IP-Adresse bzw. der Hostname der Redis-Datenbank wird in REDIS_HOST hinterlegt. Wenn Redis auf einem anderen Port als 6379 erreichbar ist, muss zusätzlich die Portnummer in REDIS_PORT hinterlegt werden. Soweit Authentifizierung in Redis aktiviert ist, muss das Redis-Passwort in REDIS_PASSWORD hinterlegt werden.

Danach kann das Session-Handling über Redis mit APP_SESSION_HANDLER=redis aktiviert werden. Alle laufenden Sitzungen werden beim Wechsel des Session-Handlers beendet.

Sollte Redis z. B. auf 192.168.1.3 mit Port 6379 laufen und das Passwort "foobar" festgelegt sein, wären folgende Zeilen in der Datei .env.local zu ergänzen:

REDIS_HOST=192.168.1.3
REDIS_PORT=6379
REDIS_PASSWORD='foobar'
APP_SESSION_HANDLER=redis

Weitere Funktionalitäten über Redis

Redis kann zur Performance-Optimierung anstelle der MongoDB-Datenbank (bei MongoDB-Clustern) bzw. des JSON-Datei-Systems (bei dateibasierten Clustern) für bestimmte Funktionalitäten von CCM19 verwendet werden.

CCM19 sperrt temporäre IP-Adressen, von denen aus in kurzen Zeitabständen zu häufig falsche Passwörter eingegeben werden. Wenn Redis für dieses Log verwendet werden soll, ist folgende Zeile in der .env.local zu ergänzen:

APP_LOGIN_ATTEMPTS_LOG_STORE=redis

Die aktiven Consent-Protokolle (vor der Archivierung) können ebenfalls in Redis gespeichert werden. Dafür sollte vorher sichergestellt werden, dass Persistenz in Redis konfiguriert ist, damit die Consent-Protokolle bei einem Ausfall nicht verlorengehen. Wenn dies sichergestellt ist und Redis für die aktiven Consent-Protokolle verwendet werden soll, ist folgende Zeile in der .env.local zu ergänzen:

APP_PROTOCOL_STORE=redis

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 --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