CCM19 en el clúster - Alta disponibilidad

En principio, CCM19 también puede funcionar sin problemas 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 con archivos JSON-o con un MongoDB.

Si estás planeando gestionar más de 1000 dominios en algún momento, deberías trabajar directamente con un MongoDB - incluso si sólo estás usando 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 de módulos innecesarios PHP- y Apache-
• Optimización de los ajustes del kernel-, p. ej. número de procesos máximos 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 ccm19-Zip-antes de la instalación:

En primer lugar a los miembros del cluster-. Esto es necesario para que las instancias del cluster puedan sincronizar sus caches, 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. De este modo, el acceso de lectura siempre puede realizarse directamente a través de sockets de dominio Unix-- , lo que acelera considerablemente 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 de 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 cluster MongoDB-Replica-se explica en detalle en la documentación de MongoDB y por lo tanto no se cubre más aquí.

Cronjobs del lado del servidor

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

Por lo tanto, recomendamos configurar cronjobs del lado del servidor en clusters (por ejemplo, en el crontab o como un temporizador systemd-) en el 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 tal manera que se escalonen y preferiblementenose ejecuten exactamente al mismo tiempo en todos los servidores.

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

APP_CRON_MODE=servidor