Zum Inhalt

Ccm19 cluster

-# 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 with 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, this database must of course also be installed along with the corresponding PHP libraries. Please note that the traffic requirements are high, so optimize access accordingly on your servers.

It makes sense to use

  • php-fpm
  • Caching-module for Apache, Cache-storage in RAM, e.g., tmpfs
  • Remove unnecessary PHP- and Apache-modules
  • Optimization of 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, add 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, you only need the URLs of the other instances in the cluster.

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

Cluster with MongoDB

Installation with MongoDB is handled through the installation-interface and does not require any 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