Problem mit dem OPcache bei mehreren Webservern hinter einem LoadBalancer (Contao4.9)

Hallo zusammen,

aktuell ziehen wir ein größeres Contao 4.9-Projekt im Zuge eines Relaunches auf eine neue, container-basierte Server-Infrastruktur um.
Konkret hängen hier zwei Webserver (mit je einem PHP-FPM und aktiviertem OPcache) hinter einem LoadBalancer mit zufälliger Lastverteilung.

Das Session-Handling haben wir über einen Redis-Container gelöst.
Die Webserver und PHP Container teilen sich zudem über ein EFS diverse Datei-Ressourcen wie bspw. die files/-Ordner oder auch den Ordner var/cache/. Auch die system/config/localconfig.php wird entsprechend geteilt. Soweit funktioniert dieses Konstrukt auch schon ganz gut.

Probleme treten allerdings genau dann auf, wenn man z.B. versucht, die Contao-Einstellungen im Backend anzupassen. Denn die geänderten Einstellungen werden zwar in die "neue" localconfig.php Datei geschrieben, jedoch wird der aktivierte OPcache quasi immer nur in einem der beiden PHP-FPM Container resettet. Das führt dann dazu, dass die Anzeige unter "Einstellungen" im Contao Backend in etwa 50% der Fälle die falschen Settings darstellt. Auch bin ich mir außerdem nicht sicher, welche Settings dann über die Config::get()-Methode auf dem jeweiligen System ankommen.

Auch das Verschieben von Dateien innerhalb der Contao Dateiverwaltung führt in dieser Konstellation leider häufiger zu Fehlern:
Anhang 24520
Anhang 24521

Erst ein mehrmaliges Ausführen der Aktion sorgt dafür, dass, wenn zufällig mehrmals derselbe Web- und somit PHP-FPM-Container antwortet, kein Fehler auftritt.

Daher meine Frage: Hat jemand von euch Erfahrung mit so einer Infrastruktur und den auftretenden Problemen? Und falls ja, wie sieht hier die beste Lösung aus?

Vielen Dank um Voraus und beste Grüße

Puh, klingt ziemlich spannend, hoffe ihr bekommt es gelöst. Ein Problem dürfte schon mal sein, dass eigentlich auch die Datenbanken synchron sein müssten oder beide Systeme die selbe Datenbank benutzen müssten. Ihr verschiebt eine Datei in /files, dabei wird auf dem Server, auf dem das ausgeführt wird, die Datenbank (tl_files) entsprechend angepasst, "mit dem Dateisystem synchronisiert". Beim anderen Server passiert das aber nicht! Also ist dessen Datenbank nicht mehr mit dem Dateisystem synchronisiert. Der will jetzt auf die Datei zugreifen, holt sich den Pfad aus seiner DB und muss dann feststellen, dass die Datei da nicht mehr ist. Ob es da eine zuverlässige Lösung gibt, die auch Race Conditions zuverlässig verhindert, das weiss ich nicht. Die Wahrscheinlichkeit, dass der Fehler auftritt stark zu vermindern, das wird schon eher realistisch sein.

Vielleicht kann man auch einen Server zum "Master" machen, der als einziger das Recht hat, Dateien zu ändern, die einen Reset des OPCache notwendig machen oder Dateien in /files zu verschieben/erzeugen/löschen. Und wenn er das tut, müsste er es durch einen geeigneten Mechanismus (z.B. Erzeugung einer Datei in einem gemeinsam genutzten Verzeichnis) ankündigen und warten, bis der/die anderen Server das bestätigen. Erst dann wird die Änderung durchgeführt, das danach den anderen mitgeteilt und alle resetten ihren OPCache bevor sie weiterarbeiten. Im Falle einer Änderung in /files würde man idealerweise bei der Ankündigung die Info mitgeben (json oder wie auch immer), welche Datei wohin verschoben, neu erzeugt oder gelöscht wird, damit die anderen Server das nach Beendigung der Aktion ohne großen Aufwand in ihrer DB nachführen können. Eine Synchronisierung des gesamten Dateisystems wird man ja nicht unbedingt durchführen wollen :D. Alle bestätigen die Durchführung der Änderung, der Master kann die Datei mit der Ankündigung löschen. Erst dann arbeiten alle weiter. So sollten auch Race Conditions vermeidbar sein. Besonders performant düfte das nicht sein, aber solche Änderungen macht man ja auch nicht sekündlich.

Naja, nur so ein paar Überlegungen zu später Stunde, vielleicht machen sie ja ein wenig Sinn. ;)