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 using the standard agency-version, though it requires a few minor adjustments.
Essentially, you must 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 is advisable 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
We recommend MongoDB for running CCM19 in a cluster. For more information, see the following section.
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, specify 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 directory 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 in sync 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 through 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 they are also 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.