CCM19 en clúster - Alta disponibilidad

En principio, CCM19 también puede funcionar sin problemas en un clúster. La nube de CCM19-también se ejecuta 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 Agencia-, aunque requiere algunos pequeños ajustes.

En principio, hay que decidir qué estructura se desea utilizar. CCM19 funciona tanto con un enfoque basado en archivos (archivos JSON-) como con una base de datos MongoDB.

Si tiene previsto gestionar en algún momento más de 1000 dominios, 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 junto 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 utilizar

• php-fpm
• Caching-Módulo para Apache, caché-Almacenamiento en RAM, p. ej., tmpfs
• Eliminación de módulos innecesarios de PHP- y Apache-- Optimización del kernel-Ajustes como, por ejemplo, el número máximo de procesos posibles, 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 que se encuentra en el archivo zip de ccm19-- :

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

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

Las URL se separan mediante espacios, aunque 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 de dominio Unix-- , lo que acelera considerablemente el acceso.

También en esta variante 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, si hay dos réplicas de MongoDB-en 192.168.1.1 y 192.168.1.2, ambas en el puerto 27017, a las que también se puede acceder a través del socket «/var/run/mongodb/mongod.-» del dominio Unix - : APP_MONGODB_CONNECTION_STRING='mongodb://user:password@%sock'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á con más detalle aquí.

Tareas programadas (cronjobs) del lado del servidor

De forma predeterminada, las tareas que deben ejecutarse periódicamente (cronjobs) 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 de tiempo de espera-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 el archivo .env.local:

APP_CRON_MODE=server