La tolerancia a fallos y la alta disponibilidad son temas importantes, por lo que dedicaremos artículos separados a RabbitMQ y Kafka. Este artículo trata sobre RabbitMQ y el siguiente trata sobre Kafka, en comparación con RabbitMQ. Este es un artículo largo, así que ponte cómodo.
Veamos las estrategias de tolerancia a fallos, coherencia y alta disponibilidad (HA) y las compensaciones que plantea cada estrategia. RabbitMQ puede ejecutarse en un grupo de nodos y luego se clasifica como un sistema distribuido. Cuando se trata de sistemas distribuidos, solemos hablar de coherencia y disponibilidad.
Estos conceptos describen cómo se comporta un sistema cuando falla. Fallo de conexión de red, fallo del servidor, fallo del disco duro, indisponibilidad temporal del servidor debido a recolección de basura, pérdida de paquetes o ralentización de la conexión de red. Todo esto puede provocar pérdida de datos o conflictos. Resulta que es prácticamente imposible implementar un sistema que sea completamente consistente (sin pérdida de datos, sin divergencia de datos) y disponible (acepte lecturas y escrituras) para todos los escenarios de falla.
Veremos que la coherencia y la disponibilidad están en extremos opuestos del espectro y usted debe elegir de qué manera optimizar. La buena noticia es que con RabbitMQ esta elección es posible. Tienes este tipo de palancas "nerds" para cambiar el equilibrio hacia una mayor coherencia o una mayor accesibilidad.
Prestaremos especial atención a qué configuraciones provocan la pérdida de datos debido a registros confirmados. Existe una cadena de responsabilidad entre editores, intermediarios y consumidores. Una vez que el mensaje se transmite al corredor, es su trabajo no perderlo. Cuando el corredor acusa recibo del mensaje por parte del editor, no esperamos que se pierda. Pero veremos que esto realmente puede suceder dependiendo de la configuración de su agente y editor.
Primitivas de resiliencia de nodo único
Cola/enrutamiento resistentes
Hay dos tipos de colas en RabbitMQ: duraderas y no duraderas. Todas las colas se guardan en la base de datos de Mnesia. Las colas duraderas se vuelven a anunciar al iniciar el nodo y, por lo tanto, sobreviven a reinicios, fallas del sistema o fallas del servidor (siempre que los datos persistan). Esto significa que siempre que declare que el enrutamiento (intercambio) y la cola son resistentes, la infraestructura de cola/enrutamiento volverá a estar en línea.
Las colas volátiles y el enrutamiento se eliminan cuando se reinicia el nodo.
Mensajes persistentes
El hecho de que una cola sea duradera no significa que todos sus mensajes sobrevivirán al reinicio del nodo. Sólo los mensajes establecidos por el editor como sostenible (persistente). Los mensajes persistentes crean una carga adicional en el intermediario, pero si la pérdida de mensajes es inaceptable, no hay otra opción.
Arroz. 1. Matriz de sostenibilidad
Agrupación con duplicación de colas
Para sobrevivir a la pérdida de un corredor, necesitamos redundancia. Podemos combinar varios nodos RabbitMQ en un clúster y luego agregar redundancia adicional replicando colas entre varios nodos. De esta manera, si falla un nodo, no perdemos datos y seguimos disponibles.
Duplicación de cola:
- una cola principal (maestra), que recibe todos los comandos de escritura y lectura
- uno o más espejos que reciben todos los mensajes y metadatos de la cola principal. Estos espejos no están ahí para escalar, sino simplemente para redundancia.
Arroz. 2. Duplicación de cola
La duplicación la establece la política adecuada. En él puedes seleccionar el coeficiente de replicación e incluso los nodos en los que debe ubicarse la cola. Ejemplos:
ha-mode: allha-mode: exactly, ha-params: 2(un maestro y un espejo)ha-mode: nodes, ha-params: rabbit@node1, rabbit@node2
Confirmación del editor
Para lograr una grabación consistente, se requieren confirmaciones del editor. Sin ellos, existe el riesgo de que se pierdan los mensajes. Se envía una confirmación al editor después de escribir el mensaje en el disco. RabbitMQ escribe mensajes en el disco no al recibirlos, sino periódicamente, en la región de varios cientos de milisegundos. Cuando se refleja una cola, se envía una confirmación solo después de que todos los espejos también hayan escrito su copia del mensaje en el disco. Esto significa que el uso de confirmaciones agrega latencia, pero si la seguridad de los datos es importante, entonces son necesarias.
Cola de conmutación por error
Cuando un corredor se cierra o falla, todos los líderes de cola (maestros) en ese nodo fallan junto con él. Luego, el clúster selecciona el espejo más antiguo de cada maestro y lo promueve como el nuevo maestro.
Arroz. 3. Múltiples colas reflejadas y sus políticas.
El corredor 3 cae. Tenga en cuenta que el espejo de la cola C en el Broker 2 se está promoviendo a maestro. También tenga en cuenta que se ha creado un nuevo espejo para la cola C en el corredor 1. RabbitMQ siempre intenta mantener el factor de replicación especificado en sus políticas.
Arroz. 4. El corredor 3 falla, lo que provoca que la cola C falle
¡Cae el próximo Broker 1! Sólo nos queda un corredor. El espejo de la cola B pasa a ser maestro.
La figura. 5
Hemos devuelto el Agente 1. Independientemente de qué tan bien sobrevivan los datos a la pérdida y recuperación del agente, todos los mensajes de la cola reflejados se descartan al reiniciar. Es importante tener esto en cuenta porque habrá consecuencias. Veremos estas implicaciones en breve. Entonces, el Agente 1 vuelve a ser miembro del clúster y el clúster intenta cumplir con las políticas y, por lo tanto, crea espejos en el Agente 1.
En este caso, la pérdida del Agente 1 fue completa, al igual que los datos, por lo que la Cola B no reflejada se perdió por completo.
Arroz. 6. El corredor 1 vuelve al servicio
El corredor 3 vuelve a estar en línea, por lo que las colas A y B recuperan los espejos creados en él para satisfacer sus políticas de HA. ¡Pero ahora todas las colas principales están en un nodo! Esto no es ideal; es mejor una distribución uniforme entre los nodos. Desafortunadamente, aquí no hay muchas opciones para reequilibrar los maestros. Volveremos a este tema más adelante porque primero debemos analizar la sincronización de colas.
Arroz. 7. El corredor 3 vuelve al servicio. ¡Todas las colas principales en un nodo!
Ahora debería tener una idea de cómo los espejos brindan redundancia y tolerancia a fallas. Esto garantiza la disponibilidad en caso de falla de un solo nodo y protege contra la pérdida de datos. Pero aún no hemos terminado, porque en realidad es mucho más complicado.
sincronización
Al crear un nuevo espejo, todos los mensajes nuevos siempre se replicarán en este espejo y en cualquier otro. En cuanto a los datos existentes en la cola maestra, podemos replicarlos en un nuevo espejo, que se convierte en una copia completa del maestro. También podemos optar por no replicar los mensajes existentes y dejar que la cola principal y el nuevo espejo converjan en el tiempo, con los nuevos mensajes llegando al final y los mensajes existentes saliendo al principio de la cola principal.
Esta sincronización se realiza de forma automática o manual y se gestiona mediante una política de cola. Veamos un ejemplo.
Tenemos dos colas reflejadas. La cola A se sincroniza automáticamente y la cola B se sincroniza manualmente. Ambas colas contienen diez mensajes.
Arroz. 8. Dos colas con diferentes modos de sincronización.
Ahora estamos perdiendo el Broker 3.
Arroz. 9. El corredor 3 cayó
El corredor 3 vuelve al servicio. El clúster crea un espejo para cada cola en el nuevo nodo y sincroniza automáticamente la nueva cola A con el maestro. Sin embargo, el espejo de la nueva Cola B permanece vacío. De esta manera tenemos redundancia total en la cola A y solo un espejo para los mensajes de la cola B existentes.
Arroz. 10. El nuevo espejo de la cola A recibe todos los mensajes existentes, pero el nuevo espejo de la cola B no.
Diez mensajes más llegan a ambas colas. Luego, el Agente 2 falla y la Cola A regresa al espejo más antiguo, que está en el Agente 1. No hay pérdida de datos cuando falla. En la cola B, hay veinte mensajes en el maestro y sólo diez en el espejo porque esta cola nunca replicó los diez mensajes originales.
Arroz. 11. La cola A regresa al Agente 1 sin perder mensajes
Diez mensajes más llegan a ambas colas. Ahora el Broker 1 falla. La cola A cambia fácilmente al espejo sin perder mensajes. Sin embargo, la cola B está teniendo problemas. En este punto podemos optimizar la disponibilidad o la coherencia.
Si queremos optimizar la accesibilidad, entonces la política ha-promoción-en-fallo debe instalarse en hacerlo. Este es el valor predeterminado, por lo que simplemente no puede especificar la política en absoluto. En este caso, básicamente estamos permitiendo fallas en espejos no sincronizados. Esto hará que los mensajes se pierdan, pero la cola seguirá siendo legible y escribible.
Arroz. 12. La cola A vuelve al Agente 3 sin perder mensajes. La cola B regresa al Agente 3 con diez mensajes perdidos
También podemos instalar ha-promote-on-failure en significado when-synced. En este caso, en lugar de volver al espejo, la cola esperará hasta que el Agente 1 con sus datos vuelva al modo en línea. Después de regresar, la cola principal regresa al Agente 1 sin pérdida de datos. Se sacrifica la disponibilidad por la seguridad de los datos. Pero este es un modo riesgoso que puede incluso provocar la pérdida total de datos, algo que veremos en breve.
Arroz. 13. La cola B sigue no disponible después de perder al Agente 1
Quizás se pregunte: "¿Es mejor no utilizar nunca la sincronización automática?" La respuesta es que la sincronización es una operación de bloqueo. ¡Durante la sincronización, la cola principal no puede realizar ninguna operación de lectura o escritura!
Veamos un ejemplo. Ahora tenemos colas muy largas. ¿Cómo pueden crecer hasta tal tamaño? Por varias razones:
- Las colas no se utilizan activamente
- Son colas de alta velocidad y ahora mismo los consumidores son lentos.
- Son colas de alta velocidad, ha habido un problema técnico y los consumidores se están poniendo al día
Arroz. 14. Dos grandes colas con diferentes modos de sincronización.
Ahora cae el corredor 3.
Arroz. 15. El corredor 3 cae, dejando un maestro y un espejo en cada cola.
El corredor 3 vuelve a estar en línea y se crean nuevos espejos. La cola principal A comienza a replicar los mensajes existentes en el nuevo espejo y, durante este tiempo, la cola no está disponible. Se necesitan dos horas para replicar los datos, lo que genera dos horas de tiempo de inactividad para esta cola.
Sin embargo, la cola B permanece disponible durante todo el período. Ella sacrificó cierta redundancia por la accesibilidad.
Arroz. 16. La cola no está disponible durante la sincronización
Después de dos horas, la cola A también estará disponible y podrá comenzar a aceptar lecturas y escrituras nuevamente.
Actualizaciones
Este comportamiento de bloqueo durante la sincronización dificulta la actualización de clústeres con colas muy grandes. En algún momento, es necesario reiniciar el nodo maestro, lo que significa cambiar a un espejo o deshabilitar la cola mientras se actualiza el servidor. Si elegimos realizar la transición, perderemos mensajes si los espejos no están sincronizados. De forma predeterminada, durante una interrupción del intermediario, no se realiza una conmutación por error a un espejo no sincronizado. Esto significa que tan pronto como el corredor regresa, no perdemos ningún mensaje, el único daño fue una simple cola. Las reglas de comportamiento cuando un corredor se desconecta están establecidas por política ha-promote-on-shutdown. Puede establecer uno de dos valores:
always= la transición a espejos no sincronizados está habilitadawhen-synced= transición solo a un espejo sincronizado; de lo contrario, la cola se vuelve ilegible y no se puede escribir. La cola vuelve al servicio tan pronto como regresa el corredor.
De una forma u otra, con colas grandes hay que elegir entre la pérdida de datos o la indisponibilidad.
Cuando la disponibilidad mejora la seguridad de los datos
Hay una complicación más a considerar antes de tomar una decisión. Si bien la sincronización automática es mejor para la redundancia, ¿cómo afecta a la seguridad de los datos? Por supuesto, con una mejor redundancia, es menos probable que RabbitMQ pierda los mensajes existentes, pero ¿qué pasa con los mensajes nuevos de los editores?
Aquí debes considerar lo siguiente:
- ¿Podría el editor simplemente devolver un error y hacer que el servicio ascendente o el usuario vuelvan a intentarlo más tarde?
- ¿Puede el editor guardar el mensaje localmente o en una base de datos para volver a intentarlo más tarde?
Si el editor sólo puede descartar el mensaje, entonces, de hecho, mejorar la accesibilidad también mejora la seguridad de los datos.
Por tanto, hay que buscar un equilibrio y la solución depende de la situación concreta.
Problemas con ha-promote-on-failure=when-synced
Idea ha-promoción-en-fallo= cuando se sincroniza es que evitamos cambiar a un espejo no sincronizado y así evitamos la pérdida de datos. La cola sigue siendo ilegible o escribible. En su lugar, intentamos recuperar el broker bloqueado con sus datos intactos para que pueda volver a funcionar como maestro sin pérdida de datos.
Pero (y este es un gran pero) si el broker ha perdido sus datos, entonces tenemos un gran problema: ¡la cola se ha perdido! ¡Todos los datos desaparecieron! Incluso si tiene espejos que en su mayoría alcanzan la cola principal, esos espejos también se descartan.
Para volver a agregar un nodo con el mismo nombre, le decimos al clúster que olvide el nodo perdido (con el comando Rabbitmqctl olvidar_cluster_node) e iniciar un nuevo corredor con el mismo nombre de host. Si bien el clúster recuerda el nodo perdido, recuerda la cola anterior y los espejos no sincronizados. Cuando se le dice a un clúster que olvide un nodo huérfano, esa cola también se olvida. Ahora necesitamos volver a declararlo. Perdimos todos los datos, aunque teníamos espejos con un conjunto parcial de datos. ¡Sería mejor cambiar a un espejo no sincronizado!
Por lo tanto, la sincronización manual (y la falla de sincronización) en combinación con ha-promote-on-failure=when-synced, en mi opinión, bastante arriesgado. Los médicos dicen que esta opción existe para la seguridad de los datos, pero es un cuchillo de doble filo.
Reequilibrio maestro
Como prometimos, volvemos al problema de la acumulación de todos los maestros en uno o varios nodos. Esto puede ocurrir incluso como resultado de una actualización continua del clúster. En un clúster de tres nodos, todas las colas maestras se acumularán en uno o dos nodos.
Reequilibrar los maestros puede resultar problemático por dos motivos:
- No existen buenas herramientas para realizar el reequilibrio
- Sincronización de colas
Hay un tercero para reequilibrar , que no cuenta con soporte oficial. Respecto a complementos de terceros en el manual de RabbitMQ : “El complemento proporciona algunas herramientas adicionales de configuración y generación de informes, pero el equipo de RabbitMQ no lo admite ni lo verifica. Úselo bajo su propio riesgo."
Existe otro truco para mover la cola principal mediante políticas de HA. El manual menciona para esto. Funciona así:
- Elimina todos los espejos mediante una política temporal que tiene una prioridad más alta que la política HA existente.
- Cambia la política temporal de HA para usar el modo de nodo, especificando el nodo al que se debe transferir la cola maestra.
- Sincroniza la cola para la migración push.
- Una vez completada la migración, elimina la política temporal. La política de HA inicial entra en vigor y se crea la cantidad requerida de espejos.
La desventaja es que es posible que este enfoque no funcione si tiene colas grandes o requisitos de redundancia estrictos.
Ahora veamos cómo funcionan los clústeres de RabbitMQ con particiones de red.
Pérdida de conectividad
Los nodos de un sistema distribuido están conectados por enlaces de red, y los enlaces de red pueden desconectarse y lo serán. La frecuencia de las interrupciones depende de la infraestructura local o de la confiabilidad de la nube seleccionada. En cualquier caso, los sistemas distribuidos deben poder hacerles frente. Una vez más podemos elegir entre disponibilidad y coherencia, y nuevamente la buena noticia es que RabbitMQ ofrece ambas opciones (pero no al mismo tiempo).
Con RabbitMQ tenemos dos opciones principales:
- Permitir la división lógica (cerebro dividido). Esto garantiza la disponibilidad, pero puede provocar la pérdida de datos.
- Deshabilitar la separación lógica. Puede provocar una pérdida de disponibilidad a corto plazo según cómo se conecten los clientes al clúster. También puede provocar una indisponibilidad total en un clúster de dos nodos.
Pero ¿qué es la separación lógica? Esto ocurre cuando un clúster se divide en dos debido a la pérdida de conexiones de red. A cada lado, los espejos se convierten en maestros, de modo que eventualmente habrá varios maestros por turno.
Arroz. 17. Cola principal y dos espejos, cada uno en un nodo separado. Luego ocurre una falla en la red y un espejo se desconecta. El nodo separado ve que los otros dos se han caído y promociona sus espejos al maestro. Ahora tenemos dos colas principales, tanto de escritura como de lectura.
Si los editores envían datos a ambos maestros, terminamos con dos copias divergentes de la cola.
Los diferentes modos de RabbitMQ proporcionan disponibilidad o coherencia.
Modo ignorar (predeterminado)
Este modo garantiza la accesibilidad. Tras la pérdida de conectividad, se produce una separación lógica. Una vez restaurada la conectividad, el administrador debe decidir a qué partición darle prioridad. El lado perdedor se reiniciará y se perderán todos los datos acumulados en ese lado.
Arroz. 18. Tres editores están asociados con tres corredores. Internamente, el clúster enruta todas las solicitudes a la cola principal en el Agente 2.
Ahora estamos perdiendo al Broker 3. Él ve que otros brokers han caído y promociona su espejo al maestro. Así se produce una separación lógica.
Arroz. 19. División lógica (cerebro dividido). Los registros van a dos colas principales y las dos copias divergen.
Se restablece la conectividad, pero permanece la separación lógica. El administrador debe seleccionar manualmente el bando perdedor. En el caso siguiente, el administrador reinicia el Broker 3. Todos los mensajes que no logró transmitir se pierden.
Arroz. 20. El administrador desactiva el Broker 3.
Arroz. 21. El administrador inicia el Broker 3 y se une al cluster, perdiendo todos los mensajes que quedaron allí.
Durante la pérdida de conectividad y después de su restauración, el clúster y esta cola estuvieron disponibles para lectura y escritura.
Modo de recuperación automática
Funciona de manera similar al modo Ignorar, excepto que el propio clúster elige automáticamente el lado perdedor después de dividir y restaurar la conectividad. El lado perdedor regresa al clúster vacío y la cola pierde todos los mensajes que se enviaron solo a ese lado.
Pausar el modo minoritario
Si no queremos permitir la partición lógica, entonces nuestra única opción es descartar las lecturas y escrituras en el lado más pequeño después de la partición del clúster. Cuando el corredor ve que es más pequeño, suspende el trabajo, es decir, cierra todas las conexiones existentes y rechaza las nuevas. Una vez por segundo comprueba la restauración de la conectividad. Una vez que se restablece la conectividad, reanuda la operación y se une al clúster.
Arroz. 22. Tres editores están asociados con tres corredores. Internamente, el clúster enruta todas las solicitudes a la cola principal en el Agente 2.
Los corredores 1 y 2 luego se separan del corredor 3. En lugar de promover su espejo a maestro, el corredor 3 se suspende y deja de estar disponible.
Arroz. 23. El corredor 3 hace una pausa, desconecta a todos los clientes y rechaza las solicitudes de conexión.
Una vez que se restablece la conectividad, regresa al clúster.
Veamos otro ejemplo en el que la cola principal está en el Broker 3.
Arroz. 24. Cola principal en el Broker 3.
Entonces ocurre la misma pérdida de conectividad. El corredor 3 hace una pausa porque está en el lado más pequeño. Por otro lado, los nodos ven que el Broker 3 se ha caído, por lo que el espejo más antiguo de los Brokers 1 y 2 asciende a maestro.
Arroz. 25. Transición al Agente 2 si el Agente 3 no está disponible.
Cuando se restablezca la conectividad, el Broker 3 se unirá al clúster.
Arroz. 26. El clúster ha vuelto a su funcionamiento normal.
Lo importante que hay que entender aquí es que conseguimos coherencia, pero también podemos conseguir disponibilidad, si Transferiremos clientes con éxito a la mayor parte de la sección. Para la mayoría de las situaciones, yo personalmente elegiría el modo Pausa Minoritaria, pero realmente depende del caso individual.
Para garantizar la disponibilidad, es importante asegurarse de que los clientes se conecten correctamente al host. Veamos nuestras opciones.
Garantizar la conectividad del cliente
Tenemos varias opciones sobre cómo dirigir a los clientes a la parte principal del clúster o a los nodos en funcionamiento (después de que falla un nodo) después de una pérdida de conectividad. Primero, recordemos que una cola específica se aloja en un nodo específico, pero el enrutamiento y las políticas se replican en todos los nodos. Los clientes pueden conectarse a cualquier nodo y el enrutamiento interno los dirigirá a donde deben ir. Pero cuando se suspende un nodo, rechaza las conexiones, por lo que los clientes deben conectarse a otro nodo. Si el nodo se cae, poco podrá hacer.
Nuestras opciones:
- Se accede al clúster mediante un equilibrador de carga que simplemente recorre los nodos y los clientes vuelven a intentar conectarse hasta que tienen éxito. Si un nodo está inactivo o suspendido, los intentos de conectarse a ese nodo fallarán, pero los intentos posteriores se dirigirán a otros servidores (en forma de turnos). Esto es adecuado para una pérdida de conectividad a corto plazo o un servidor caído que se recuperará rápidamente.
- Acceda al clúster a través de un equilibrador de carga y elimine los nodos suspendidos/fallidos de la lista tan pronto como se detecten. Si hacemos esto rápidamente y si los clientes pueden volver a intentar la conexión, lograremos una disponibilidad constante.
- Proporcione a cada cliente una lista de todos los nodos y el cliente seleccionará aleatoriamente uno de ellos al conectarse. Si recibe un error al intentar conectarse, pasa al siguiente nodo de la lista hasta que se conecta.
- Elimine el tráfico de un nodo fallido/suspendido mediante DNS. Esto se hace usando un pequeño TTL.
Hallazgos
La agrupación en clústeres RabbitMQ tiene sus ventajas y desventajas. Las desventajas más graves son que:
- al unirse a un cluster, los nodos descartan sus datos;
- el bloqueo de la sincronización hace que la cola deje de estar disponible.
Todas las decisiones difíciles surgen de estas dos características arquitectónicas. Si RabbitMQ pudiera guardar datos cuando se vuelva a unir el clúster, entonces la sincronización sería más rápida. Si fuera capaz de realizar sincronización sin bloqueo, admitiría mejor colas grandes. Solucionar estos dos problemas mejoraría enormemente el rendimiento de RabbitMQ como tecnología de mensajería de alta disponibilidad y tolerante a fallos. Dudaría en recomendar RabbitMQ con agrupación en clústeres en las siguientes situaciones:
- Red poco confiable.
- Almacenamiento poco confiable.
- Colas muy largas.
Cuando se trata de configuraciones de alta disponibilidad, considere lo siguiente:
ha-promote-on-failure=alwaysha-sync-mode=manualcluster_partition_handling=ignore(oautoheal)- mensajes persistentes
- garantizar que los clientes se conecten al nodo activo cuando algún nodo falla
Para mantener la coherencia (seguridad de los datos), considere las siguientes configuraciones:
- Confirmaciones del editor y reconocimientos manuales por parte del consumidor
ha-promote-on-failure=when-synced, si los editores pueden volver a intentarlo más tarde y si tienes un almacenamiento muy confiable. De lo contrario poner=always.ha-sync-mode=automatic(pero para colas inactivas grandes puede ser necesario el modo manual; considere también si la falta de disponibilidad provocará la pérdida de mensajes)- Pausar el modo minoritario
- mensajes persistentes
Aún no hemos cubierto todas las cuestiones de tolerancia a fallos y alta disponibilidad; por ejemplo, cómo realizar procedimientos administrativos de forma segura (como actualizaciones continuas). También necesitamos hablar sobre la federación y el complemento Shovel.
Si me he perdido algo más, házmelo saber.
Ver también mi , donde causo estragos en un clúster RabbitMQ usando Docker y Blockade para probar algunos de los escenarios de pérdida de mensajes descritos en este artículo.
Artículos anteriores de la serie:
Nº 1 -
Nº 2 -
Nº 3 -
Fuente: habr.com