🍮 👨🏿‍💼 🗿 Clúster de dos nodos: el diablo en detalle 🎇 👩🏾‍⚖️ 💃🏾

Hola Habr! Les presento la traducción del artículo "Dos nodos: el diablo está en los detalles" de Andrew Beekhof.

Muchas personas prefieren grupos de dos nodos porque parecen conceptualmente más simples y también un 33% más baratos que sus contrapartes de tres nodos. Aunque es bastante posible ensamblar un buen grupo de dos nodos, en la mayoría de los casos, debido a escenarios no contabilizados, dicha configuración creará muchos problemas no obvios.

El primer paso para crear cualquier sistema de alta disponibilidad es buscar e intentar eliminar puntos individuales de falla, a menudo abreviados como SPoF (punto único de falla).

Debe tenerse en cuenta que en cualquier sistema es imposible eliminar todos los posibles riesgos de tiempo de inactividad. Esto se sigue incluso del hecho de que una protección de riesgo típica es la introducción de cierta redundancia, lo que lleva a un aumento en la complejidad del sistema y la aparición de nuevos puntos de falla. Por lo tanto, inicialmente nos comprometemos y nos enfocamos en eventos relacionados con puntos individuales de falla, en lugar de en cadenas de eventos relacionados y, por lo tanto, cada vez menos probables.

Dadas las compensaciones, no solo estamos buscando SPoF, sino también equilibrando los riesgos y las consecuencias, como resultado, la conclusión es lo que es crítico y lo que no puede ser diferente para cada implementación.

No todos necesitan proveedores de electricidad alternativos con líneas eléctricas independientes. Aunque la paranoia valió la pena para al menos un cliente cuando su monitoreo detectó un transformador defectuoso. El cliente llamó por teléfono, tratando de advertir a la compañía de energía, hasta que explotó un transformador defectuoso.

El punto de partida natural es la presencia de más de un nodo en el sistema. Sin embargo, antes de que el sistema pueda mover los servicios al nodo sobreviviente después de la falla, en general, debe asegurarse de que los servicios que se mueven no estén activos en ningún otro lugar.

Un clúster de dos nodos no tiene inconvenientes si, como resultado de una falla, ambos nodos sirven al mismo sitio web estático. Sin embargo, todo cambia si, como resultado, ambas partes administran independientemente la cola de trabajos compartidos o proporcionan acceso de escritura no coordinado a la base de datos replicada o al sistema de archivos compartido.

Por lo tanto, para evitar la corrupción de datos debido a la falla de un nodo, confiamos en lo que se llama "disociación» (cercado).

Principio de separación

El principio de separación se basa en la pregunta: ¿puede un nodo competidor causar corrupción de datos? En el caso de que la corrupción de datos sea un escenario probable, aislar el nodo de las solicitudes entrantes y el almacenamiento persistente es una buena solución. El enfoque más común para desconectar es deshabilitar nodos defectuosos.

Hay dos categorías de métodos de separación que llamaré directos e indirectos , pero igualmente se pueden llamar activos y pasivos.. Los métodos directos incluyen acciones de pares sobrevivientes, como interactuar con un dispositivo IPMI (Interfaz inteligente de administración de plataforma, una interfaz para monitorear y administrar de forma remota el estado físico de un servidor) o iLO (un mecanismo de administración de servidor en ausencia de acceso físico a ellos), mientras que los métodos indirectos se basan en el nodo fallido para reconocer de alguna manera que se encuentra en un estado poco saludable (o al menos evita que el resto de los miembros se recuperen) y para indicar al vigilante del hardware la necesidad de desconectar el nodo fallido.

Un quórum ayuda en el caso de utilizar métodos directos e indirectos.

Disociación directa

En el caso de la disociación directa, podemos usar un quórum para evitar carreras de exclusión en caso de falla de la red.

Con el concepto de quórum, el sistema tiene suficiente información (incluso sin conectarse con sus socios) para que los nodos sepan automáticamente si deben iniciar la separación y / o recuperación.

Sin quórum, ambos lados de la red compartida asumen con razón que el otro lado está muerto y buscarán disociar al otro. En el peor de los casos, ambas partes logran desconectar todo el clúster. Un escenario alternativo es deathmatch, un ciclo infinito de nodos que aparecen, no ven a sus pares, los vuelven a cargar e inician la recuperación solo para reiniciar cuando sus pares siguen la misma lógica.

El problema con la exclusión es que los dispositivos utilizados con más frecuencia se vuelven inaccesibles debido a los mismos eventos de falla en los que queremos centrarnos para la recuperación. La mayoría de las tarjetas IPMI e iLO se instalan en los hosts que controlan y, de forma predeterminada, usan la misma red, por lo que los nodos de destino suponen que los otros nodos están fuera de línea.

Desafortunadamente, las características del funcionamiento de los dispositivos IPMI e iLo rara vez se consideran al momento de la compra del equipo.

Separación indirecta

Un quórum también es importante para gestionar la exclusión indirecta; si todo se hace correctamente, un quórum puede permitir a los sobrevivientes asumir que los nodos perdidos entrarán en un estado seguro después de un cierto período de tiempo.

Con esta configuración, el temporizador de vigilancia del hardware se restablece cada N segundos si no se pierde el quórum. Si el temporizador (generalmente un múltiplo de N) caduca, el dispositivo realiza un apagado de energía sin gracia (no se apaga).

Este enfoque es muy efectivo, pero sin quórum, no hay suficiente información dentro del clúster para administrarlo. No es fácil determinar la diferencia entre una interrupción de la red y una falla del host asociado. La razón por la que esto es importante es que sin la capacidad de distinguir entre dos casos, se ve obligado a elegir el mismo comportamiento en ambos casos.

El problema con la elección de un modo es que no hay forma de acción que maximice la accesibilidad y evite la pérdida de datos.

Si decide asumir que el nodo asociado está activo, pero de hecho hubo una falla, el clúster detendrá innecesariamente los servicios que tendrían que funcionar para compensar la pérdida de servicios del nodo asociado caído.
Si decide suponer que el nodo no está funcionando, pero fue solo un fallo de la red y el nodo remoto realmente está funcionando, entonces, en el mejor de los casos, se suscribirá a una futura conciliación manual de los conjuntos de datos resultantes.

No importa qué heurística use, es trivial crear una falla que obligue a ambas partes a trabajar o que el clúster desconecte los nodos supervivientes. No usar quórum realmente roba al grupo de una de las herramientas más poderosas en su arsenal.

Si no hay otra alternativa, el mejor enfoque sería sacrificar la accesibilidad (aquí el autor se refiere al teorema CAP). La alta disponibilidad de datos corruptos no ayuda a nadie, y reconciliar manualmente varios conjuntos de datos tampoco es un placer.

Quórum

El quórum suena genial, ¿verdad?

El único inconveniente es que para tenerlo en un clúster con N miembros, debe mantener la conexión entre N / 2 + 1 de sus nodos. Lo que es imposible en un clúster con dos nodos después de la falla de un nodo.

Lo que finalmente nos lleva a un problema fundamental con dos nodos: un
quórum no tiene sentido en dos grupos de nodos, y sin esto es imposible determinar de manera confiable el curso de acción que maximiza la accesibilidad y evita la pérdida de datos
Incluso en un sistema de dos nodos conectados por un cable cruzado, es imposible distinguir finalmente entre desconectar la red y la falla de otro nodo. Desconectar un extremo (cuya probabilidad es, por supuesto, proporcional a la distancia entre los nodos) será suficiente para refutar cualquier suposición de que el canal está funcionando igual a la salud del nodo asociado.

Hacer que el clúster de dos nodos funcione

A veces el cliente no puede o no quiere comprar un tercer nodo, y nos vemos obligados a buscar una alternativa.

Opción 1: método de separación duplicado

El dispositivo iLO o IPMI del nodo es un punto de falla porque, en caso de falla, los sobrevivientes no pueden usarlo para poner el nodo en un estado seguro. En un grupo de 3 o más nodos, podemos mitigar esto calculando el quórum y utilizando el watchdog de hardware (un mecanismo de desconexión indirecta, como se discutió anteriormente). En el caso de dos nodos, deberíamos usar interruptores de alimentación de red (unidades de distribución de energía o PDU).

Después de la falla, el sobreviviente primero intenta comunicarse con el dispositivo de separación primario (iLO o IPMI incorporado). Si esto tiene éxito, la recuperación continúa como de costumbre. Solo en el caso de una falla del dispositivo iLO / IPMI se produce la llamada a la PDU, si la llamada es exitosa, la recuperación puede continuar.

Asegúrese de colocar la PDU en una red que no sea el tráfico del clúster, de lo contrario, una sola falla de la red bloqueará el acceso a los dispositivos de aislamiento y bloqueará la recuperación del servicio.

Aquí puede preguntar: ¿la PDU no es un solo punto de falla? A lo que la respuesta es, por supuesto.

Si este riesgo es significativo para usted, no está solo: conecte ambos nodos a dos PDU e indique al software del clúster que use ambos al encender y apagar los nodos. Ahora el clúster permanece activo si una PDU muere y se requiere una segunda falla de otra PDU o dispositivo IPMI para bloquear la recuperación.

Opción 2: agregar un árbitro

En algunos escenarios, aunque el método de separación duplicada es técnicamente posible, es políticamente complejo. A muchas compañías les gusta tener una cierta separación entre los administradores y los propietarios de las aplicaciones, y los administradores de redes conscientes de la seguridad no siempre están entusiasmados con pasar los parámetros de acceso de la PDU a nadie.

En este caso, la alternativa recomendada es crear un tercero neutral que pueda complementar el cálculo del quórum.

En caso de falla, el nodo debería poder ver la transmisión de su socio o árbitro para restaurar los servicios. El árbitro también incluye la función de romper la conexión, si ambos nodos pueden ver al árbitro, pero no se ven entre sí.

Esta opción debe usarse junto con un método indirecto de disociación, como un temporizador de vigilancia de hardware, que está configurado para apagar la máquina si pierde la conexión con su nodo asociado y el árbitro. Por lo tanto, el sobreviviente puede asumir con confianza que su nodo asociado estará en un estado seguro después de la expiración del temporizador de vigilancia del hardware.

La diferencia práctica entre el árbitro y el tercer nodo es que el árbitro requiere muchos menos recursos para su trabajo y, potencialmente, puede servir a más de un clúster.

Opción 3 - El factor humano

El último enfoque es que los sobrevivientes continúen realizando cualquier servicio que ya hayan realizado, pero no comiencen otros nuevos, hasta que el problema se resuelva por sí mismo (recuperación de la red, reinicio del nodo) o la persona no asuma la responsabilidad de confirmar manualmente que El otro lado está muerto.

Opción de bonificación

¿Mencioné que puede agregar un tercer nodo?

Dos bastidores

En aras de la discusión, imaginemos que te convencí de los méritos del tercer nodo, ahora debemos considerar la ubicación física de los nodos. Si se colocan (y alimentan) en el mismo bastidor, esto también representa SPoF, y uno que no se puede resolver agregando un segundo bastidor.

Si esto es sorprendente, considere lo que sucederá si el rack con dos nodos se cae, y cómo el nodo sobreviviente distinguirá entre este caso y la falla de la red.

Respuesta corta: esto no es posible, y nuevamente estamos lidiando con todos los problemas en el caso de dos nodos. O sobreviviente:

ignora el quórum e intenta incorrectamente iniciar la recuperación durante las interrupciones de la red (la posibilidad de completar la separación es una historia separada y depende de si las PDU están involucradas y si comparten el poder de cualquiera de los racks), o
respeta el quórum y se desconecta prematuramente cuando falla su nodo asociado

En cualquier caso, dos bastidores no son mejores que uno, y los nodos deben recibir fuentes de alimentación independientes o distribuirse entre tres bastidores (o más, dependiendo de cuántos nodos tenga).

Dos centros de datos

En este punto, los lectores que ya no son reacios al riesgo pueden considerar recuperarse de un accidente. ¿Qué sucede cuando un asteroide ingresa a un solo centro de datos con nuestros tres nodos distribuidos en tres bastidores diferentes? Obviamente, cosas malas, pero dependiendo de sus necesidades, agregar un segundo centro de datos puede no ser suficiente.

Si todo se hace correctamente, el segundo centro de datos le proporciona (y esto es razonable) una copia actualizada y coherente de sus servicios y sus datos. Sin embargo, como en los escenarios con dos nodos y dos bastidores, el sistema no tiene suficiente información para garantizar la máxima disponibilidad y evitar daños (o divergencia de conjuntos de datos). Incluso si hay tres nodos (o bastidores), su distribución solo en dos centros de datos deja al sistema incapaz de tomar la decisión correcta en caso de (ahora mucho más probable) un evento que las dos partes no pueden conectarse.

Esto no significa que una solución con dos centros de datos nunca encaje. Las empresas a menudo quieren que las personas estén al tanto antes de dar un paso excepcional al mudarse a un centro de datos de respaldo. Solo tenga en cuenta que si desea automatizar la falla, necesitará un tercer centro de datos para que el quórum tenga sentido (ya sea directamente o a través de un árbitro), o encontrará una manera de deshabilitar de manera confiable todo el centro de datos.

Clúster de dos nodos: el diablo en detalle