Guides related to Beach

How to scale an instance

If you need to scale an instance up using additional replicas, there are some things to keep in mind.

Scaling configuration

Scaling an instance is in fact quite easy, you just set the desired maximum number of replicas for the instance in the Beach user interface. If you have a plan with automatic scaling support, it's three values you can set: minimum and maximum number of replicas as well as the CPU utilization that should trigger scaling.

But as soon as you have more than one instance, things are different than with just one…

Cache configuration

One of those things is the Flow cache configuration. While most caches are fine with existing per replica, some should be shared between replicas:

  • Session-Caches should be shared, to avoid users losing their session should they end up on different replicas between requests.
  • The HashService has a persistent cache to store the encyption key Flow uses for some things. One of them is HMAC calculation – something that is used to secure forms and logins – and thus needs to be consistent across replicas.

We recommend putting those caches into the database – that way sessions even survive a 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: *pdoBackend
Caches.yaml snippet to configure the session and hash service caches for the PDO backend.

Cron jobs and daemons

If an instance is scaled and cron jobs or daemon scripts are running there, this can lead to problems. This is because it is often the case that these should not run multiple times because they would then do things twice or compete for resources.

One variant is to run a separate instance with only 1 replica for this service. There you can then control workers etc. via the Beach UI or via your own environment variables. The other instance can have any number of replicas and scale.

Alternatively, you can use something like Sitegeist.ScentMark. In Beach, for example, with a setup like this:

REPLICA_IDENTIFIER=`cat /proc/sys/kernel/random/uuid`
touch Data/replica_identifier
echo $REPLICA_IDENTIFIER > Data/replica_identifier
beach-startup.sh
REPLICA_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
beach-cron-hourly.sh
Cover photo by Markus Spiske on Unsplash