Zum Inhalt

CCM19 in a High-Availability Cluster -

In general, CCM19 can also be operated in a cluster without any issues. The CCM19-Cloud also runs in a high-availability-cluster with a load balancer and various servers behind it that share the load. In general, we recommend using Ansible to manage the server(s).

This technology can also be implemented using the standard agency-version, though it requires a few minor adjustments.

Essentially, you need to decide which structure you want to use. CCM19 runs with either a file-based approach using JSON-files or with a MongoDB.

If you plan to manage more than 1,000 domains at some point, you should work directly with a MongoDB—even if you’re only using one server to start. Migrating from JSON to MongoDB is not trivial and requires a significant amount of work.

For installation and administration, we assume that the servers used have an Apache web server with PHP. If you’re using MongoDB, the database and the corresponding PHP libraries must also be installed. Keep in mind that the traffic requirements are high, so optimize access on your servers accordingly.

It makes sense to use

  • php-fpm
  • Caching-module for Apache, Cache-storage in RAM, e.g., tmpfs
  • Removing unnecessary PHP- and Apache-modules
  • Optimizing kernel-settings, such as the maximum number of processes and the number of connections allowed via the network card

File-Based Cluster

A file-based cluster is possible with distributed file systems such as GlusterFS.

To do this, you must add the .env.local file to the ccm19-zip-file before installation:

First, list the cluster-members. This is necessary so that the instances in the cluster can, for example, synchronize their caches. For example, with two cluster-members at 192.168.0.4 and 192.168.0.5, where the CCM19-installation is installed directly in the HTTP-root on each:

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

Multiple URLs are separated by spaces, but it also works with just one. In principle, only the URLs of the other instances in the cluster are required.

APP_BUNDLE_VAR=1

This specifies that the central data is stored in the directory var/config-bundle . This directory must then be kept synchronized across all instances, for example, via GlusterFS.

The session_save_path() should then be set to the directory /var/config-bundle/tmp/. This allows you to log in, and your login status is preserved even when switching between the different cluster components-.

Clusters with MongoDB

Installation with MongoDB is handled via the installation-interface and requires no special configuration. We recommend setting up MongoDB-replicas directly on the web servers where CCM19 is also installed. This ensures that read access always occurs directly via Unix-domain-sockets, which significantly speeds up access.

With this configuration as well, the .env.local file must be updated on all instances in the cluster (see above for details):

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

For maximum reliability, the addresses of all MongoDB-replicas should also be specified in order of preference in the .env.local file for each cluster-instance. For example, if there are two MongoDB-replicas at 192.168.1.1 and 192.168.1.2, each on port 27017, and additionally accessible via the Unix-domain-socket "/var/run/mongodb/mongod.sock" on the respective web server:

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

The initial configuration of a MongoDB-Replica-cluster is explained in detail in the MongoDB documentation and will therefore not be covered further here.

Server-Side Cron Jobs

By default, tasks to be executed regularly (cron jobs) are triggered by randomly selected frontend-requests. In a cluster-installation, this can result in some cron jobs being triggered too infrequently, depending on how requests are distributed across the servers.

Therefore, we recommend setting up server-side cron jobs in clusters (e.g., in the crontab or as a systemd-timer) where bin/console app:cron:run -- timeout 15 is executed on each instance every 2-5 minutes. The - parameter specifies the maximum runtime for each run. The cron jobs should be configured so that they run staggered and, if possible, not exactly simultaneously on all servers.

Once the server-side cron jobs have been set up and tested, the frontend-can disable the triggering of these cron jobs by adding an entry to .env.local:

APP_CRON_MODE=server