En un momento determinado, apareció una tarea: transferir un proyecto existente y que trabaja activamente en producción para trabajar en un clúster de servidores. Porque el proyecto se desarrolló sobre la base de 1C-Bitrix, se decidió construir un clúster utilizando "1C-Bitrix: entorno web". El propósito de este evento es poder soportar cargas pesadas con la afluencia de visitantes del sitio, así como la capacidad de escalar horizontalmente más rápido en el futuro.
En realidad, si vamos al sitio web del proveedor, veremos que:
“1C-Bitrix: entorno web”: Linux se utiliza para una instalación rápida y fácil de todo el software necesario para el funcionamiento de los productos y soluciones de 1C-Bitrix en las plataformas Linux CentOS 6 (i386, x86_64) y CentOS 7 (x86_64). Es necesario instalarlo en un CentOS "limpio", sin un servidor web ya instalado.
La estructura de "1C-Bitrix: entorno web" - Linux incluye: mysql-server, httpd, php, nginx, nodejs push-server, memcached, stunnel, catdoc, xpdf, munin, nagios, sphinx.
De hecho, este paquete de software contiene una LAMP configurada, un panel de control del servidor de consola, más paquetes adicionales necesarios para la operación de algunos módulos 1C-Bitrix. Todo el software se configura teniendo en cuenta las características de 1C-Bitrix, a saber:
- extensiones necesarias instaladas (gd, zip, socket, mbstring)
- soporte de etiqueta corta habilitado
- los valores necesarios se establecen para los parámetros memory_limit, max_input_vars, modo seguro, opcache.validate_timestamps, opcache.revalidate_freq, mbstring.func_overload, default_charset, display_errors, etc.
- establecer la misma zona horaria para la base de datos, php y en el propio servidor
- y otros
Esto permite en la mayoría de los casos no participar en la configuración y el ajuste del servidor.
Entonces, teníamos 2 servidores de aplicaciones (llamémoslos app01 y app01), 2 servidores db (db01, db02), 1 servidor para el almacenamiento en caché (cache01, entiendes), más precisamente, la idea era implementar la estructura del clúster de manera similar. Según este plan, se recibieron 5 servidores, con las últimas versiones de centos7 instaladas en ellos (desafortunadamente, debian, ubuntu, fedora, rhel, etc. no son adecuados), a excepción de os, no se instaló nada más en los servidores.
Porque Si ensamblamos un clúster, es necesario determinar cuál de los servidores será el principal. Debido a las peculiaridades de equilibrar las solicitudes a la aplicación, uno de los servidores donde funcionará httpd también contendrá nginx. También aceptará todas las solicitudes entrantes y luego redirigirá la solicitud a uno de los nodos web disponibles. Elegimos el servidor principal app01.
El trabajo adicional se realizó de acuerdo con el siguiente plan:
1. Instalar bitrixenv
La instalación no implica conocimiento o administración sobrenatural de Linux. Vamos a cada servidor a través de ssh y ejecutamos los siguientes comandos:
cd ~ wget http://repos.1c-bitrix.ru/yum/bitrix-env.sh chmod +x bitrix-env.sh ./bitrix-env.sh
Bitrixenv debe instalarse en todos los servidores que se planea utilizar en el clúster. Incluso si el servidor solo funcionará como una instancia de memcached, bitrixenv es necesario, porque le permite administrar todo el clúster desde el servidor principal.
2. Configurar bitrixenv
Porque Si usamos todo este zoológico como un clúster, podemos configurar los servidores a través del menú del entorno en app01. Para hacer esto, vaya al servidor a través de ssh y ejecute el archivo /root/menu.sh. En el primer inicio, debe establecer una contraseña para el usuario de bitrix (se debe realizar una operación similar en todos los servidores donde está programado el lanzamiento del sitio):
En realidad, este es el usuario bajo el cual funcionará la aplicación. Después de eso, vemos una pantalla que ofrece crear un grupo de servidores:
Aquí necesitamos seleccionar el primer elemento del menú. En el proceso de creación del entorno, solicitará el nombre del servidor actual, luego especificaremos app01:
Una vez creado el grupo, volvemos a la primera pantalla del entorno, pero esta vez hay muchos más puntos disponibles:
En general, el entorno está listo y puede usarlo. Si no necesitamos un clúster, podríamos terminar aquí, pero iremos más allá.
Ahora necesitamos agregar todos los servidores disponibles al grupo creado. Para hacer esto, use el primer elemento del menú y vea las siguientes opciones:
Nuevamente, seleccione el primer elemento del menú y especifique la ip del nuevo servidor, su nombre en el clúster (la misma aplicación02, db01, db02, cache01) y la contraseña raíz del servidor conectado. Por lo tanto, agregamos cada servidor disponible uno por uno. Después de que todos los servidores estén registrados en el clúster, deberíamos obtener algo como esta lista en la pantalla principal del entorno:
Establecer roles de servidor por ahora se aplaza al siguiente paso.
3. Transferencia del proyecto
Porque Dado que nuestra aplicación se ejecuta inicialmente en un solo servidor, el módulo de escala y administración de clúster está deshabilitado, la base de datos no se replica. La transferencia en sí no es nada sobrenatural: empaquetó el bitrix y cargó carpetas, eliminó el volcado de la base de datos.
Una vez que los archivos y los volcados estén listos, vaya a app01 y extraiga el código del proyecto a través de git a la carpeta predeterminada del sitio en bitrixenv - / home / bitrix / www, descargue los archivos y descargue la base de datos usando wget o curl, desempaquete los archivos y cárguelos. Volcar a la base de datos en app01, transferir entradas cron.
Si su aplicación utiliza software adicional, es hora de instalarlo y configurarlo. En nuestro caso, supervisor y RabbitMQ se instalaron y configuraron, como la aplicación funcionó usando colas.
Hay un matiz pequeño pero importante. Al transferir un sitio a un clúster, es necesario que la escala y los módulos del clúster estén deshabilitados en el sitio, y que los servidores de la agrupación no participen en el entorno del clúster al que se planea la transferencia. Los servidores de clúster deben incluirse en la operación solo después de que el sitio se mueva y se implemente en el servidor principal. De lo contrario, el sitio no podrá determinar correctamente los servidores del clúster.
4. Habilitar el modo de clúster
Después de que la aplicación se transfirió a app01, y verificamos la corrección de su trabajo, es hora de hacer lo más interesante: escalar. Primero debe instalar los módulos de escala y clúster en el panel de administración de 1C-Bitrix. Durante la instalación, no se necesita hacer nada especial, todo el trabajo continúa.
Una vez que los módulos están instalados, vaya a la conexión ssh con el servidor principal, y esta es app01, y abra el menú bitrixenv (aquí se encuentra /root/menu.sh). Antes de continuar con la configuración adicional, debe descubrir un punto importante: bitrixenv utiliza el concepto de "rol de servidor". Realmente no importa cómo se llame el servidor en el grupo, porque cada servidor contiene todo el software que se incluye en el paquete bitrixenv, siempre podemos asignarle uno o más roles y podemos eliminarlos o intercambiarlo por otros. Los roles principales son mgmt (equilibrador, es decir, nginx), web (es decir, httpd / apache), mysql_master y mysql_slave (instancia de DB, el esclavo aparece cuando comenzamos a hacer la replicación), memcached (servidor con memcached). La imagen general ahora es clara, y decidimos comenzar con un servidor memcached. Para hacer esto, vaya al párrafo
4. Configure memcahed servers > 1. Configure memcached service
y vemos una solicitud para el nombre del servidor que actuará como servidor memcached. Ya tenemos un servidor cache01 preparado para esto, así que miramos la lista de servidores disponibles. Si cache01 está en la lista, entonces no hay problemas de instalación y podemos darle al servidor el rol seleccionado.
Ingresamos el nombre cache01, vemos que la tarea para configurar el rol está en cola. Estamos esperando la finalización del trabajo en segundo plano y vemos un servidor listo para trabajar con el rol que necesitamos.
Es hora de agregar un segundo servidor de aplicaciones. Para hacer esto, ve por el camino
8. Manage web nodes in the pool > 1. Create web role on server,
donde necesitamos especificar el nombre del servidor y el método de sincronización entre el nodo web principal y el nuevo. Según la documentación de bitrixenv y las pruebas preliminares, fue suficiente para nuestro proyecto elegir la primera opción (copiar el proyecto y configurar las configuraciones de nodo en un solo paso). Una vez finalizado el trabajo de fondo, deberíamos ver algo como esto en el menú principal:
Tenga en cuenta que en la columna Roles opuesta al servidor app02, se indica el rol web.
Queda por tratar con la base de datos, su configuración lleva más tiempo. Primero, explicaré brevemente cómo se distribuyen los roles mysql en el contexto de bitrixenv. Por defecto, la versión maestra de la base de datos está en el servidor principal del clúster. En nuestro caso, fue necesario transferir la base de datos a un servidor separado y agregar otro servidor con una versión esclava de la base de datos. En bitrixenv, no puede simplemente tomar y transferir el maestro de un servidor a otro)
La secuencia es la siguiente:
- Otorgamos el rol de mysql_slave al servidor al que planeamos transferir la base de datos.
- En el servidor de destino, cambiamos la función de mysql_slave a la función de mysql_master (automáticamente, el antiguo mysql_master entra en modo mysql_slave)
- Elimine la función mysql_slave en el servidor original, el antiguo maestro
- ...
- BENEFICIO !!!
Seguimos esta lógica de esta manera:
Fue a
3. Configure MySQL servers > 4. Create MySQL slave
Indicamos el servidor al que queremos asignar el rol mysql_slave - db01. Estamos esperando la finalización del trabajo de fondo y vemos el siguiente resultado:
Ok, ahora vamos a
3. Configure MySQL servers > 5. Change MySQL master
Especifique app01 y espere. Como resultado, debería ver algo como esto:
Lenta e inevitablemente nos acercamos a la instalación del último rol: mysql_slave. Para esto, es necesario repetir los pasos mediante los cuales establecemos dicho rol para db01, pero ya especificamos db02.
Finalmente, todos los servidores están conectados y configurados.
5. Rendimiento de ajuste
Una vez que el clúster está listo, hay algunas características en la configuración de la aplicación que permiten una optimización adicional:
- Bombeamos trabajo con sesiones. Descrito en detalle aquí . En resumen: cambie el almacenamiento de sesión en memcached.
- Elimine los archivos /bitrix/php_interface/after_connect_d7.php y /bitrix/php_interface/after_connect.php, porque los comandos de ellos rompen la tubería del clúster (si no se usa bitrixenv, entonces es mejor dejarlos).
- Aumentamos la cantidad de memoria asignada por memcached y establecemos el porcentaje de uso de servidores con la función memcached al 100%.
- Deshabilitar módulos php: apcu, ldap
- Deshabilite los módulos de bus "Compresión" y "Análisis web" (si es posible).
- Considere usar un caché local. Más detalles se describen aquí . En nuestro caso, no hubo aumento, pero la idea es interesante. La solución tiene un par de características:
- El número de instancias memcached debería ser igual al número de nodos web.
- Para devolver el caché compuesto por nginx, directamente desde la memoria caché local, debe profundizar en la configuración de nginx, no funciona de la caja.
- Mueve la ejecución de todos los agentes a cron.
Conclusiones
En el marco de este artículo, examinamos la secuencia de pasos necesarios para configurar un clúster de servidores basado en bitrixenv, así como algunas posibles dificultades. En función de los resultados de trabajar con bitrixenv y el clúster que contiene, podemos destacar los pros y los contras de este enfoque:
Pros bitrixenv
- Tiempo de instalación
La instalación y la configuración básica demoran menos de 30 minutos. No es necesario configurar elementos LAMP (tanto la integración de estos servicios entre sí, como el correcto trabajo de los proyectos en 1C-Bitrix). - Servicios para acelerar el sitio
Servicios instalados y configurados que le permiten organizar el almacenamiento en caché más rápido a través de memcached en lugar de archivos, busque utilizando el motor sphinx y la funcionalidad de videollamadas y chats en el portal corporativo (módulo push & pull de nginx). Además, nginx en el entorno está configurado de tal manera que cuando habilita las opciones correspondientes en el sitio y en el menú bitrixenv, el caché se envía usando nginx directamente desde memcached (sin pasar por httpd y php) - Agrupamiento
La capacidad de habilitar la replicación de la base de datos, sin elegir la configuración de MySQL. Conectando un número arbitrario de nodos web que se sincronizarán automáticamente entre sí y nodos memcached. Gestión del equilibrio de carga en los nodos web y memcached tanto desde el menú de bitrixenv como a través del panel de administración del proyecto en 1C-Bitrix. Además, agregar nuevos servidores y roles no causa un proyecto simple (excepto quizás para los roles de los servidores de bases de datos)
Contras bitrixenv
- El equilibrador siempre está con el nodo web principal
Porque ya teníamos nuestro propio equilibrador, nos enfrentamos al hecho de que es imposible abandonar el equilibrador integrado en bitrixenv. Es imposible incluir colóquelo por separado del nodo web principal. - Mucho software extra para algunos roles
Porque Como cada servidor del grupo contiene la versión completa del entorno, resulta que los nodos db son httpd, memcached, sphinx, incluso si no se usan. Del mismo modo, puede encontrar MySQL en un servidor que se ocupa solo del almacenamiento en caché, pero en este caso, MySQL se puede detener en el menú del entorno o en el panel de administración del sitio. - Php funciona en modo apache2handler
No hay forma de habilitar php de manera segura en modo fcgi, sin mencionar el modo nginx + php-fpm. Además, no funcionará cambiar la versión de php, sin bailar con una pandereta.
Fuentes:
www.1c-bitrix.ru/products/env
dev.1c-bitrix.ru/community/blogs/rns/hidden-features-of-work-with-sessions.php
dev.1c-bitrix.ru/community/blogs/rns/the-use-of-local-caches-in-the-cluster.php
dev.1c-bitrix.ru/learning/course/index.php?COURSE_ID=32&INDEX=Y
dev.1c-bitrix.ru/learning/course/index.php?COURSE_ID=37&INDEX=Y