Anleitungen im Zusammenhang mit Beach
Wie man eine Instanz skaliert
Wenn du eine Instanz mithilfe zusätzlicher Replikate skalieren musst, gibt es einige Dinge zu beachten.
Konfiguration der Skalierung
Die Skalierung einer Instanz ist eigentlich ganz einfach: Du stellst einfach die gewünschte maximale Anzahl von Replikaten für die Instanz in der Benutzeroberfläche Beach ein. Wenn du einen Plan mit automatischer Skalierungsunterstützung hast, kannst du drei Werte einstellen: die minimale und maximale Anzahl der Replikate sowie die CPU-Auslastung, die eine Skalierung auslösen soll.
Aber sobald du mehr als eine Instanz hast, sieht die Sache anders aus als bei nur einer...
Die Cache-Konfiguration
Einer dieser Punkte ist die Konfiguration des Flow-Caches. Für die meisten Caches ist es in Ordnung, wenn sie pro Replikat vorhanden sind, aber einige sollten zwischen den Replikaten geteilt werden:
- Session-Caches sollten gemeinsam genutzt werden, um zu verhindern, dass Nutzer/innen ihre session verlieren, wenn sie zwischen Anfragen auf verschiedenen Replikaten landen.
- Der HashService hat einen dauerhaften Cache, um den Verschlüsselungsschlüssel zu speichern, den Flow für einige Dinge verwendet. Einer davon ist die HMAC-Berechnung, die zur Sicherung von Formularen und Logins verwendet wird und daher über alle Replikate hinweg konsistent sein muss.
Wir empfehlen, diese Caches in der Datenbank zu speichern - auf diese Weise überlebt die Session sogar ein Cluster-Upgrade. 😎
Flow_Security_Cryptography_HashService: &pdoBackend
backend: 'Neos\Cache\Backend\PdoBackend'
backendOptions:
dataSourceName: 'mysql:host=%env:BEACH_DATABASE_HOST%;dbname=%env:BEACH_DATABASE_NAME%'
username: '%env:BEACH_DATABASE_USERNAME%'
password: '%env:BEACH_DATABASE_PASSWORD%'
defaultLifetime: 0
Flow_Session_Storage: *pdoBackend
Flow_Session_MetaData: *pdoBackendCron-Jobs und Daemons
Wird eine Instanz skaliert, und laufen dort Cron-Jobs oder Daemon-Skripte, so kann das zu Problemen führen. Denn oft ist es so, dass diese eben nicht mehrfach laufen sollen, weil sie dann Dinge doppelt erledigen oder um Ressourcen konkurrieren.
Eine Variante ist es, für diese Dienst eine separate Instanz mit nur 1 Replika laufen zu lassen. Dort kann man dann Worker etc. über die Beach-UI oder über eigene Environment-Variablen steuern. Die andere Instanz kann dann beliebig viele Replika haben und skalieren.
Alternativ kannst du etwas wie Sitegeist.ScentMark benutzen. In Beach z.B. mit einem Setup wie diesem:
REPLICA_IDENTIFIER=`cat /proc/sys/kernel/random/uuid`
touch Data/replica_identifier
echo $REPLICA_IDENTIFIER > Data/replica_identifierREPLICA_IDENTIFIER=`cat Data/replica_identifier`
./flow scentmark:bark $BEACH_DEPLOYMENT_JOB_IDENTIFIER $REPLICA_IDENTIFIER
if [ $? -eq 0 ]; then
# tasks to only run on one instance per release
fi