Get best of the week

Acerca del clúster de servidores 1C

Un clúster es un tipo de
sistema paralelo o distribuido que:
1. consta de varias
computadoras interconectadas ;
2. Utilizado como un único
recurso informático unificado

Gregory F. Pfister, "En busca de grupos".

Dado: hay una aplicación comercial (por ejemplo, un sistema ERP) con la que miles (posiblemente decenas de miles) de usuarios trabajan simultáneamente.

Es requerido:
  1. Haga que la aplicación sea escalable, de modo que con un aumento en el número de usuarios, sea posible debido al aumento en los recursos de hardware para proporcionar el rendimiento necesario de la aplicación.
  2. Haga que la aplicación sea resistente a fallas en los componentes del sistema (tanto software como hardware), pérdida de conexión entre componentes y otros posibles problemas.
  3. Utilice los recursos del sistema de la manera más eficiente posible y proporcione el rendimiento deseado de la aplicación.
  4. Haga que el sistema sea fácil de implementar y administrar.

Para resolver estos problemas, utilizamos la arquitectura de clúster en la plataforma 1C: Enterprise.

No alcanzamos de inmediato el resultado deseado.

En este artículo, hablaremos sobre qué tipo de clústeres son, cómo elegimos el tipo de clúster que nos conviene y cómo nuestro clúster evolucionó de una versión a otra, y qué enfoques nos permitieron crear un sistema que sirva a decenas de miles de usuarios simultáneos.

imagen

Como Gregory Pfister, autor del epígrafe de este artículo, escribió en su libro "En busca de clústeres", el clúster no fue inventado por ningún fabricante particular de hardware o software, sino por clientes que carecían de la potencia de una computadora o necesitaban redundancia. Esto sucedió, según Pfister, en los años 60 del siglo pasado.
Distinguir tradicionalmente los siguientes tipos principales de grupos:

  1. Clústeres de conmutación por error (HA, clústeres de alta disponibilidad)
  2. Clusters de equilibrio de carga (LBC)
  3. Clusters informáticos (Clusters informáticos de alto rendimiento, HPC)
  4. (grid) , . grid- , . grid- HPC-, .

Para resolver nuestros problemas (resistencia a fallas de los componentes del sistema y uso eficiente de los recursos), necesitábamos combinar la funcionalidad de un clúster a prueba de fallas y un clúster con equilibrio de carga. No tomamos esta decisión de inmediato, pero la abordamos evolutivamente, paso a paso.

Para aquellos que no están actualizados, les contaré brevemente cómo se organizan las aplicaciones comerciales de 1C. Estas son aplicaciones escritas en un lenguaje orientado a materias , "afiladas" para la automatización de las tareas comerciales de contabilidad. Para ejecutar aplicaciones escritas en este lenguaje, se debe instalar un tiempo de ejecución de la plataforma 1C: Enterprise en la computadora.

1C: Enterprise 8.0


La primera versión del servidor de aplicaciones 1C (aún no es un clúster) apareció en la versión de plataforma 8.0. Antes de eso, 1C trabajaba en la versión cliente-servidor, los datos se almacenaban en un archivo DBMS o MS SQL, y la lógica de negocios funcionaba exclusivamente en el cliente. En la versión 8.0, se realizó una transición a la arquitectura de tres niveles "cliente - servidor de aplicaciones - DBMS".

El servidor 1C en la plataforma 8.0 era COM +un servidor que puede ejecutar el código de la aplicación en 1C. El uso de COM + nos proporcionó un transporte listo para usar, permitiendo que las aplicaciones del cliente se comuniquen con el servidor a través de la red. Se diseñaron muchas cosas en la arquitectura de la interacción cliente-servidor y los objetos de aplicación disponibles para el desarrollador de 1C teniendo en cuenta el uso de COM +. En ese momento, la tolerancia a fallas no estaba integrada en la arquitectura, y un bloqueo del servidor provocó el cierre de todos los clientes. Cuando la aplicación del servidor se bloqueó, COM + la levantó cuando el primer cliente accedió a ella, y los clientes comenzaron su trabajo desde el principio, desde la conexión al servidor. En ese momento, todos los clientes fueron atendidos por un proceso.
imagen

1C: Enterprise 8.1


En la próxima versión, queríamos:

  • Proporcionar tolerancia a fallas a nuestros clientes para que los accidentes y errores de algunos usuarios no conduzcan a accidentes y errores de otros usuarios.
  • Deshágase de la tecnología COM +. COM + solo funcionaba en Windows, y en ese momento la posibilidad de trabajar con Linux ya se estaba volviendo relevante.

Al mismo tiempo, no queríamos desarrollar una nueva versión de la plataforma desde cero, sería demasiado intensiva en recursos. Queríamos aprovechar al máximo nuestros logros, así como mantener la compatibilidad con las aplicaciones desarrolladas para la versión 8.0.

Entonces, en la versión 8.1 apareció el primer clúster. Implementamos nuestro protocolo para llamadas a procedimientos remotos (además de TCP), que en apariencia se parecía casi a COM + para el cliente consumidor final (es decir, prácticamente no tuvimos que volver a escribir el código responsable de las llamadas cliente-servidor). Al mismo tiempo, hicimos que el servidor implementado en la plataforma C ++ sea independiente, capaz de funcionar tanto en Windows como en Linux.

El servidor monolítico versión 8.0 fue reemplazado por 3 tipos de procesos: un proceso de trabajo que sirve a los clientes y 2 procesos de servicio que admiten la operación del clúster:

  • rphost es un flujo de trabajo que sirve a los clientes y ejecuta el código de la aplicación. Un clúster puede tener más de un flujo de trabajo, se pueden ejecutar diferentes flujos de trabajo en diferentes servidores físicos, debido a esta escalabilidad se logra.
  • ragent: un proceso de agente de servidor que inicia todos los demás tipos de procesos, así como una lista líder de clústeres ubicados en este servidor.
  • rmngr es un administrador de clúster que controla el funcionamiento de todo el clúster (pero el código de la aplicación no funciona en él).

Debajo del corte se encuentra el diagrama de operación de estos tres procesos en el clúster.
image

Durante la sesión, el cliente trabajó con un flujo de trabajo, la caída en el flujo de trabajo significó para todos los clientes a los que sirvió este proceso, la sesión terminó de manera anormal. Los clientes restantes continuaron trabajando.
imagen

1C: Enterprise 8.2


En la versión 8.2, queríamos que las aplicaciones 1C pudieran ejecutarse no solo en el cliente nativo (ejecutable), sino también en el navegador (sin modificar el código de la aplicación). En este sentido, en particular, surgió la tarea de desacoplar el estado actual de la aplicación de la conexión actual con el flujo de trabajo de rphost y dejarlo sin estado. Como resultado, surgió el concepto de una sesión y los datos de la sesión que tuvieron que almacenarse fuera del flujo de trabajo (porque no tenía estado). Se ha desarrollado un servicio de datos de sesión que almacena y almacena en caché la información de la sesión. También aparecieron otros servicios: un servicio de bloqueos transaccionales administrados, un servicio de búsqueda de texto completo, etc.

Esta versión también introdujo varias innovaciones importantes: mejor tolerancia a fallas, equilibrio de carga y un mecanismo de redundancia de clúster.

Tolerancia a fallos


Como el proceso de trabajo se convirtió en apátrida y todos los datos necesarios para el trabajo se almacenaron fuera del cliente actual - conexión de flujo de trabajo, en el caso de un bloqueo del flujo de trabajo, el cliente cambió a otro flujo de trabajo "en vivo" la próxima vez que accedió al servidor. En la mayoría de los casos, dicho cambio era invisible para el cliente.

El mecanismo funciona así. Si la llamada del cliente al flujo de trabajo por alguna razón no se pudo completar hasta el final, entonces la parte del cliente puede, después de recibir un error de llamada, repetir esta llamada restableciendo la conexión al mismo flujo de trabajo u otro. Pero no siempre puedes repetir una llamada; Repetir la llamada significa que enviamos la llamada al servidor, pero no recibimos el resultado. Intentamos repetir la llamada, mientras realizamos la segunda llamada, evaluamos cuál fue el resultado de la llamada anterior en el servidor (la información sobre esto se almacena en el servidor en los datos de la sesión), porque si la llamada tenía tiempo para "heredar" allí (cerrar la transacción, guardar los datos de la sesión etc.): es imposible repetirlo, provocará inconsistencias en los datos. Si la llamada no puede repetirse, el cliente recibirá un mensaje sobre un error irrecuperable,y la aplicación del cliente tendrá que reiniciarse. Si no logró "heredar" la llamada (y esta es la situación más común, porque muchas llamadas no cambian datos, por ejemplo, informes, visualización de datos en un formulario, etc., y aquellos que cambian datos no tienen una transacción o hasta que se haya enviado un cambio en los datos de la sesión al administrador (no hay rastro de la llamada), se puede repetir sin riesgo de inconsistencia de datos. Si el flujo de trabajo se bloqueó o se interrumpió una conexión de red, dicha llamada se repite y este "desastre" para la aplicación cliente pasa completamente desapercibido.que cambian los datos (hasta que se confirma la transacción o hasta que el cambio en los datos de la sesión se envía al administrador, no hay rastro de la llamada), se puede repetir sin riesgo de inconsistencia de datos. Si el flujo de trabajo se bloqueó o se interrumpió una conexión de red, dicha llamada se repite y este "desastre" para la aplicación cliente pasa completamente desapercibido.que cambian los datos (hasta que se confirma la transacción o hasta que el cambio en los datos de la sesión se envía al administrador, no hay rastro de la llamada), se puede repetir sin riesgo de inconsistencia de datos. Si el flujo de trabajo se bloqueó o se interrumpió una conexión de red, dicha llamada se repite y este "desastre" para la aplicación cliente pasa completamente desapercibido.

Balanceo de carga


La tarea del equilibrio de carga en nuestro caso es la siguiente: un nuevo cliente ingresa al sistema (o un cliente que ya está en funcionamiento hace otra llamada). Necesitamos elegir a qué servidor y flujo de trabajo enviar la llamada del cliente para proporcionarle la máxima velocidad.

Esta es una tarea estándar para un clúster de carga equilibrada. Existen varios algoritmos típicos para resolverlo, por ejemplo:


Para nuestro clúster, elegimos un algoritmo que está esencialmente cerca del tiempo de menor respuesta. Tenemos un mecanismo que recopila estadísticas sobre el rendimiento de los flujos de trabajo en todos los servidores del clúster. Hace una llamada de referencia a cada proceso del servidor en el clúster; la llamada de referencia involucra un subconjunto de las funciones del subsistema de disco, memoria, procesador y evalúa qué tan rápido se realiza dicha llamada. El resultado de estas mediciones, promediado en los últimos 10 minutos, es un criterio: qué servidor del clúster es el más productivo y el preferido para enviarle conexiones de clientes en un período de tiempo determinado. Las solicitudes de los clientes se distribuyen de manera que se cargue mejor el servidor más productivo: cargue el que tenga suerte.

La solicitud del nuevo cliente se dirige al servidor más productivo en este momento.

En la mayoría de los casos, una solicitud de un cliente existente se dirige a ese servidor y al flujo de trabajo al que se dirigió su solicitud anterior. Un conjunto extenso de datos en el servidor está asociado con un cliente que funciona; transferirlo entre procesos (y aún más entre servidores) es bastante costoso (aunque también podemos hacerlo).

Una solicitud de un cliente existente se transfiere a otro flujo de trabajo en dos casos:

  1. No hay más procesos: el flujo de trabajo con el que el cliente interactuó anteriormente ya no está disponible (el proceso se ha caído, el servidor no está disponible, etc.).
  2. : , , , , . , , – . – (.. ).



Decidimos aumentar la resistencia del clúster recurriendo al esquema activo / pasivo . Hubo una oportunidad para configurar dos grupos: trabajo y reserva. Si el clúster principal no está disponible (problemas de red o, por ejemplo, mantenimiento programado), las llamadas del cliente se redirigen al clúster de respaldo.

Sin embargo, este diseño fue bastante difícil de configurar. El administrador tuvo que ensamblar manualmente dos grupos de servidores en grupos y configurarlos. A veces, los administradores cometieron errores al establecer configuraciones conflictivas, como no existía un mecanismo centralizado para verificar la configuración. Pero, sin embargo, este enfoque aumentó la tolerancia a fallas del sistema.
imagen

1C: Enterprise 8.3


En la versión 8.3, reescribimos sustancialmente el código del lado del servidor responsable de la tolerancia a fallas. Decidimos abandonar el esquema de clúster activo / pasivo debido a la complejidad de su configuración. Solo quedó un clúster tolerante a fallas en el sistema, que consta de cualquier número de servidores; esto está más cerca del esquema Activo / activo en el que las solicitudes de un nodo fallido se distribuyen entre los nodos de trabajo restantes. Debido a esto, el clúster se ha vuelto más fácil de configurar. Una serie de operaciones que aumentan la tolerancia a fallas y mejoran el equilibrio de carga se han automatizado. De las innovaciones importantes:

  • « »: , , . , «» .
  • , , .
  • , , , , , :

imagen

imagen

La idea principal de estos desarrollos es simplificar el trabajo del administrador, permitiéndole configurar el clúster en términos que le son familiares, en el nivel de operación del servidor, no cayendo más bajo, y también para minimizar el nivel de "control manual" del trabajo del clúster, dando los mecanismos del clúster para resolver la mayoría de las tareas de trabajo y posibles problemas ". en piloto automático ".

imagen

Tres enlaces de tolerancia a fallas


Como sabe, incluso si los componentes del sistema por separado son confiables, pueden surgir problemas donde los componentes del sistema se causan entre sí. Queríamos minimizar la cantidad de lugares críticos para el rendimiento del sistema. Una consideración adicional importante fue la minimización de las alteraciones de los mecanismos aplicados en la plataforma y la exclusión de los cambios en las soluciones aplicadas. En la versión 8.3, había 3 enlaces para garantizar la tolerancia a fallos "en las juntas":

imagen
  1. , HTTP(S), -. - -. , HTTP -, ( HTTP) libcurl .
  2. , .
  3. - . 1, - . - . , . , – . - (, , , ) – .
  4. , rmngr. 20 ( ) — , .. . 1: .



Gracias al mecanismo de tolerancia a fallas, las aplicaciones creadas en la plataforma 1C: Enterprise sobreviven con éxito varios tipos de fallas de los servidores de producción en el clúster, mientras que la mayoría de los clientes continúan trabajando sin reiniciar.

Hay situaciones en las que no podemos repetir la llamada, o un bloqueo del servidor atrapa la plataforma en un momento muy desafortunado, por ejemplo, en medio de una transacción y no está muy claro qué hacer con ellos. Intentamos garantizar una supervivencia estadísticamente buena del cliente cuando los servidores caen en el clúster. Como regla general, la pérdida promedio de clientes por falla del servidor es de un pequeño porcentaje. En este caso, todos los clientes "perdidos" pueden continuar trabajando en el clúster después de reiniciar la aplicación cliente.

La confiabilidad del clúster de servidores 1C en la versión 8.3 ha aumentado significativamente. Hace tiempo que no es raro introducir productos 1C, donde el número de usuarios que trabajan simultáneamente alcanza varios miles. Existen implementaciones en las que tanto 5.000 como 10.000 usuarios trabajan simultáneamente, por ejemplo, la introducción en Beeline , donde la aplicación 1C: Trade Management sirve a todos los puntos de venta de Beeline en Rusia, o la implementación de Business Lines en el transportista de carga , donde la aplicación, creada independientemente por los desarrolladores del departamento de TI de Business Lines en la plataforma 1C: Enterprise, sirve el ciclo completo del transporte de carga. Nuestras pruebas de carga de clúster internas simulan la operación simultánea de hasta 20,000 usuarios.

En conclusión, me gustaría enumerar brevemente qué más es útil en nuestro clúster (la lista está incompleta):

  • , . , , .
  • – , , , ( – , ..) . , , (, ) , ERP, , ERP.
  • – , (, , ..). , , , , , .

More articles:


All Articles