CCM19 en el clúster - Alta disponibilidad

En principio, CCM19 también puede funcionar con relativa facilidad en un clúster. La nube CCM19 también se ejecuta en un clúster de alta disponibilidad con un equilibrador de carga y varios servidores detrás, que juntos soportan la carga. En general, recomendamos el uso de Ansible para la gestión de los servidores.

Esta tecnología también se puede mapear con la versión estándar de la agencia, pero requiere algunos ajustes.

Básicamente, tiene que decidir qué estructura desea utilizar. CCM19 funciona tanto con un enfoque basado en archivos JSON o con un MongoDB.

Si está planeando gestionar más de 1000 dominios en algún momento, debería trabajar directamente con un MongoDB - incluso si sólo está utilizando un servidor para empezar. Pasar de JSON a MongoDB no es trivial y requiere mucho trabajo.

Para la instalación y administración, asumimos que los servidores utilizados tienen un servidor web Apache con PHP. Si se utiliza MongoDB, esta base de datos debe, por supuesto, instalarse también con las librerías PHP correspondientes. Tenga en cuenta que los requisitos en términos de tráfico son elevados y optimice el acceso en sus servidores en consecuencia.

Tiene sentido utilizar

• php-fpm
• Módulo de caché para Apache, memoria caché en RAM p.ej. tmpfs
• Eliminación del caché de módulos PHP y Apache innecesarios
• Optimización de la configuración del kernel, por ejemplo, número máximo de procesos posibles, número de conexiones posibles a través de la tarjeta de red

Cluster basado en ficheros

Un cluster basado en ficheros es posible con sistemas de ficheros distribuidos como GlusterFS.

Para ello, debe añadirse el archivo .env.local al archivo zip ccm19 antes de la instalación:

En primer lugar, los miembros del clúster. Esto es necesario para que las instancias del clúster puedan sincronizar sus cachés, por ejemplo. Por ejemplo, en el caso de dos miembros del clúster en 192.168.0.4 y 192.168.0.5, donde la instalación de CCM19 se instala directamente en la raíz HTTP:

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

Varias URL están separadas por espacios, pero también funciona con una sola. En principio, sólo se necesitan las URL de las otras instancias del cluster.

APP_BUNDLE_VAR=1

Esto indica que los datos centrales se almacenan en el directoriovar/config-bundle . Este directorio debe mantenerse sincronizado entre todas las instancias a través de, por ejemplo, GlusterFS.

Elsession_save_path()debe entonces colocarse en el directorio /var/config-bundle/tmp/. Esto le permite iniciar sesión y el estado de inicio de sesión se mantiene incluso cuando se cambia el acceso a las diferentes partes del clúster.

Cluster con MongoDB

La instalación con MongoDB ya se realiza a través de la interfaz de instalación y no requiere ninguna configuración especial. Recomendamos configurar las réplicas de MongoDB directamente en los servidores web en los que también esté instalado CCM19. Esto significa que el acceso de lectura siempre puede tener lugar directamente a través de sockets de dominio Unix, lo que acelera significativamente el acceso.

El .env.local también debe añadirse a todas las instancias del clúster para esta variante (véase más arriba para más detalles):

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

Para una máxima fiabilidad, las direcciones de todas las réplicas MongoDB también deben especificarse en orden de preferencia en el .env.local de cada instancia de cluster. Por ejemplo, para dos réplicas MongoDB en 192.168.1.1 y 192.168.1.2, cada una en el puerto 27017, accesibles adicionalmente a través del socket de dominio Unix "/var/run/mongodb/mongod.sock" en el servidor web respectivo:

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

La configuración inicial de un clúster de réplica MongoDB se explica en detalle en la documentación de MongoDB y por tanto no se cubre más aquí.

Cronjobs del lado del servidor

Por defecto, las tareas que se ejecutan regularmente (cronjobs) se activan por peticiones del frontend seleccionadas aleatoriamente. En una instalación en cluster, esto puede llevar a que algunos cronjobs se activen muy raramente, dependiendo de la distribución de peticiones a los servidores.

Por lo tanto, recomendamos configurar cron jobs del lado del servidor en clusters (por ejemplo, en el crontab o como un temporizador systemd) en los que bin/console app:cron:run --timeout 15 se ejecute en cada instancia cada 2-5 minutos. El parámetro timeout especifica el tiempo máximo de ejecución de cada ejecución. Las tareas cron deben configurarse de forma que se ejecuten de forma escalonada y, preferiblemente,node forma exactamente simultánea en todos los servidores.

Tan pronto como los cronjobs del lado del servidor hayan sido configurados y probados, la activación frontend de los cronjobs puede ser desactivada con una entrada en .env.local:

aPP_CRON_MODE=servidor"