CCM19 en clúster - Alta disponibilidad

En principio, CCM19 también se puede utilizar sin problemas en un clúster. La nube de CCM19-también funciona en un clúster de alta disponibilidad-con un equilibrador de carga y varios servidores detrás que comparten la carga. En general, recomendamos el uso de Ansible para la gestión del servidor o servidores.

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

Básicamente, hay que decidir sobre qué estructura se quiere basar. CCM19 funciona tanto con un enfoque basado en archivos con archivos JSON-como con una base de datos MongoDB.

Si tiene previsto gestionar más de 1000 dominios en algún momento, debería trabajar directamente con una base de datos MongoDB, incluso si al principio solo utiliza un servidor. Pasarse de JSON a MongoDB no es sencillo y requiere bastante trabajo.

Para la instalación y la gestión, partimos de la base de que los servidores utilizados disponen de un servidor web Apache con PHP. En caso de utilizar MongoDB, por supuesto, también debe instalarse esta base de datos con las bibliotecas PHP correspondientes. Tenga en cuenta que los requisitos en cuanto al tráfico son elevados y optimice el acceso en consecuencia en sus servidores.

Es recomendable el uso de

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

Clúster basado en archivos

Un clúster basado en archivos es posible con sistemas de archivos distribuidos como GlusterFS.

Para ello, antes de la instalación, hay que completar el archivo .env.local en el archivo zip-de ccm19-:

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

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

Las URL se separan con espacios, pero también funciona con una sola. En principio, solo se necesitan las URL de las demás instancias del clúster.

APP_BUNDLE_VAR=1

Con esto se indica que los datos centrales se almacenan en el directorio var/config-bundle. Este directorio debe mantenerse sincronizado entre todas las instancias, por ejemplo, mediante GlusterFS.

La función session_save_path() debe colocarse en el directorio /var/config-bundle/tmp/. De este modo, se puede iniciar sesión y el estado de inicio de sesión se mantiene incluso al cambiar de acceso a las diferentes partes del clúster-.

Clúster con MongoDB

La instalación con MongoDB 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. De este modo, el acceso de lectura siempre se puede realizar directamente a través de sockets Unix-Domain-, lo que acelera considerablemente el acceso.

En esta variante también es necesario completar el archivo .env.local en todas las instancias del clúster (véanse los detalles más arriba):

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

Para garantizar la máxima fiabilidad, en el archivo .env.local de cada instancia del clúster-también deben indicarse las direcciones de todas las réplicas de MongoDB-en orden de preferencia. Por ejemplo, en el caso de dos réplicas de MongoDB-en 192.168.1.1 y 192.168.1.2, cada una en el puerto 27017, a las que también se puede acceder a través del socket de dominio Unix-- «/var/run/mongodb/mongod.sock» en el servidor web correspondiente:

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 MongoDB-Replica-se explica detalladamente en la documentación de MongoDB y, por lo tanto, no se tratará aquí con más detalle.

Tareas programadas del lado del servidor

De forma predeterminada, las tareas que deben ejecutarse periódicamente (tareas programadas) se activan mediante solicitudes al frontend-seleccionadas al azar. En una instalación en clúster-, esto puede provocar que, dependiendo de la distribución de las solicitudes entre los servidores, algunas tareas programadas se activen con muy poca frecuencia.

Por ello, recomendamos configurar en los clústeres tareas cron del lado del servidor (por ejemplo, en el crontab o como temporizador de Systemd-), en las que se ejecute bin/console app:cron:run -- timeout 15 en cada instancia cada 2-5 minutos. El parámetro timeout-especifica la duración máxima de cada ejecución. Las tareas cron deben configurarse de manera que se ejecuten de forma escalonada y, en la medida de lo posible, no exactamente al mismo tiempo en todos los servidores.

Una vez configuradas y probadas las tareas cron del lado del servidor, se puede desactivar la ejecución de las tareas cron en el frontend-mediante una entrada en .env.local:

APP_CRON_MODE=server