¡Hola, Habr! Les presento la traducción del artículo del autor Andrew Beekhof.
Muchas personas prefieren clústeres compuestos por dos nodos, ya que parecen conceptualmente más simples y, además, son un 33% más económicos que sus contrapartes de tres nodos. Aunque es completamente posible construir un buen clúster de dos nodos, en la mayoría de los casos, debido a escenarios no considerados, esta configuración generará muchos problemas no evidentes.
El primer paso para crear cualquier sistema de alta disponibilidad es identificar y tratar de eliminar los puntos únicos de falla, a menudo abreviados como SPoF (punto único de falla).
Hay que tener en cuenta que en cualquier sistema es imposible eliminar todos los riesgos potenciales de inactividad. Esto se debe al hecho de que la protección típica contra riesgos implica introducir cierta redundancia, lo que lleva a un aumento en la complejidad del sistema y a la aparición de nuevos puntos de falla. Por lo tanto, desde el principio hacemos un compromiso y nos enfocamos en los eventos relacionados con puntos únicos de falla, en lugar de en las cadenas de eventos relacionados, que son cada vez menos probables.
Teniendo en cuenta los compromisos, no solo buscamos SPoF, sino que también equilibramos los riesgos y las consecuencias, resultando que lo que es crítico y lo que no puede diferir en cada despliegue.
No todos necesitan proveedores alternativos de energía con líneas de transmisión independientes. Aunque la paranoia ha valido la pena al menos para un cliente, cuando su monitoreo detectó un transformador defectuoso. El cliente llamó tratando de advertir a la compañía energética, hasta que el transformador defectuoso explotó.
Un punto de partida natural es tener 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 una falla, en general, es necesario asegurarse de que los servicios que se desplazan no estén activos en otro lugar.
Un clúster de dos nodos no tiene desventajas si como resultado de una falla ambos nodos atienden el mismo sitio web estático. Sin embargo, todo cambia si ambos lados gestionan de forma independiente una cola compartida de trabajos o proporcionan acceso no coordinado a una base de datos replicada o a un sistema de archivos compartido.
Por lo tanto, para evitar daños en los datos debido a la fallación de un nodo, nos basamos en lo que se llama «aislamiento» (fencing).
El principio de aislamiento
En la base del principio de aislamiento se encuentra la pregunta: ¿puede un nodo competidor causar daños en los datos? Si se considera que el daño en los datos es un escenario probable, una buena solución sería aislar el nodo tanto de las solicitudes entrantes como del almacenamiento persistente. El enfoque más común para el aislamiento es desconectar los nodos defectuosos.
Hay dos categorías de métodos de aislamiento que llamaré directos y indirectos, pero igualmente se les puede llamar activos y pasivos. Los métodos directos incluyen acciones por parte de los nodos pares sobrevivientes, como interactuar con el dispositivo IPMI (Interfaz de Gestión de Plataforma Inteligente) o iLO (mecanismo de gestión de servidores en condiciones de no tener acceso físico a ellos), mientras que los métodos indirectos dependen del nodo fallido para reconocer de alguna manera que está en un estado no saludable (o, al menos, interfiere con otros miembros para recuperarse) y señalar la necesidad de desconectar el nodo fallido.
El quórum ayuda tanto en el uso de métodos directos como indirectos.
Aislamiento directo
En el caso del aislamiento directo, podemos usar el quórum para prevenir condiciones de carrera de aislamiento en el caso de una falla de red.
Con el concepto de quórum, el sistema tiene suficiente información (incluso sin conexión a sus socios) para que los nodos sepan automáticamente si deben iniciar el aislamiento y/o la recuperación.
Sin quórum, ambas partes de la división de red asumen legítimamente que la otra parte está muerta y tratarán de aislar a la otra. En el peor de los casos, ambas partes logran desconectar todo el clúster. Un escenario alternativo es un deathmatch, un ciclo infinito de nodos que aparecen, no ven a sus pares, los reinician e inician la recuperación solo para reiniciarse cuando su par pasa por la misma lógica.
El problema de la partición se debe a que los dispositivos más utilizados se vuelven inaccesibles debido a los mismos eventos de fallo en los que queremos basarnos para la recuperación. La mayoría de las tarjetas IPMI e iLO están instaladas en los hosts que controlan y, por defecto, utilizan la misma red, lo que hace que los nodos objetivo piensen que los otros nodos están fuera de línea.
Desafortunadamente, las características de funcionamiento de los dispositivos IPMI e iLo rara vez se consideran al momento de comprar el equipo.
Partición indirecta
El quórum también es importante para gestionar las particiones indirectas; si se hace correctamente, el quórum puede permitir a los supervivientes suponer 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 del hardware watchdog se reinicia cada N segundos si no se ha perdido el quórum. Si el temporizador (normalmente unos múltiplos de N) expira, el dispositivo realiza un apagado sin gracia (no shutdown).
Este enfoque es muy eficaz, pero sin quórum para gestionarlo, no hay suficiente información dentro del clúster. No es fácil distinguir entre un corte de red y un fallo del nodo compañero. La razón por la que esto es importante es que sin la capacidad de diferenciar entre los dos casos, te ves obligado a elegir el mismo modo de comportamiento en ambos casos.
El problema de elegir un modo es que no hay un curso de acción que maximice la disponibilidad y evite la pérdida de datos.
- Si decides suponer que el nodo compañero está activo, pero en realidad ha fallado, el clúster parará de forma excesiva los servicios que deberían estar funcionando para compensar la pérdida de los servicios del nodo compañero caído.
- Si decides suponer que el nodo no está funcionando, pero fue solo un fallo de red y en realidad el nodo remoto está funcionando, entonces, en el mejor de los casos, te suscribes a alguna futura verificación manual de los conjuntos de datos resultantes.
Independientemente de la heurística que utilices, es trivial crear una falla que o bien permita que ambas partes operen, o fuerce al clúster a desconectar los nodos supervivientes. No usar quórum realmente priva al clúster de una de las herramientas más poderosas en su arsenal.
Si no hay otra alternativa, la mejor estrategia será sacrificar la disponibilidad (aquí el autor se refiere al teorema CAP). La alta disponibilidad de datos dañados no ayuda a nadie, y revisar manualmente diferentes conjuntos de datos tampoco es del agrado de nadie.
Quorum
¿Suena bien el quorum, verdad?
El único inconveniente es que, para tenerlo en un clúster con N miembros, es necesario que haya conexión entre N / 2 + 1 de tus nodos. Lo cual es imposible en un clúster de dos nodos después de la falla de uno de ellos.
Esto nos lleva a un problema fundamental con dos nodos:
el quorum no tiene sentido en clústeres de dos nodos, y sin eso es imposible determinar de manera confiable el curso de acción que maximiza la disponibilidad y previene la pérdida de datos.
Incluso en un sistema de dos nodos conectados por un cable cruzado, no es posible diferenciar claramente entre la desconexión de la red y la falla de otro nodo. La desconexión de un extremo (cuyas probabilidades, sin duda, son proporcionales a la distancia entre nodos) será suficiente para refutar cualquier suposición de que la operatividad del canal equivale a la salud del nodo asociado.
Haciendo funcionar un clúster de dos nodos
A veces, el cliente no puede o no quiere adquirir un tercer nodo, y nos vemos obligados a buscar una alternativa.
Opción 1: Método de aislamiento duplicado
El dispositivo iLO o IPMI del nodo representa un punto de falla, ya que, en caso de fallo, los restantes no pueden usarlo para poner el nodo en un estado seguro. En un clúster de 3 o más nodos, podemos mitigar esto calculando el quorum y usando un watchdog de hardware (un mecanismo de aislamiento indirecto, como se comentó anteriormente). En el caso de dos nodos, debemos usar en su lugar interruptores de red de alimentación (unidades de distribución de energía o PDUs).
Después de un fallo, el sobreviviente intenta primero contactar al dispositivo de aislamiento principal (iLO o IPMI integrado). Si tiene éxito, la recuperación continúa como de costumbre. Solo en caso de fallo del dispositivo iLO / IPMI se recurre al PDU, y si la conexión es exitosa, la recuperación puede continuar.
Asegúrese de colocar el PDU en una red diferente de la del tráfico del clúster; de lo contrario, una única falla de red bloqueará el acceso tanto a los dispositivos de desconexión como el restablecimiento de los servicios.
Aquí puede preguntar: ¿no es el dispositivo PDU un único punto de fallo? La respuesta es: por supuesto que lo es.
Si este riesgo es significativo para usted, no está solo: conecte ambos nodos a dos PDUs y configure el software de clúster para utilizar ambos al encender y apagar los nodos. Ahora, el clúster permanece activo si uno de los PDUs falla, y se requerirá otra falla de otro PDU o del dispositivo IPMI para bloquear la recuperación.
Opción 2: Agregar un árbitro
En algunos escenarios, aunque técnicamente sea posible el método de desconexión duplicada, es políticamente complicado. A muchas empresas les gusta tener cierta separación entre los administradores y los propietarios de las aplicaciones, y los administradores de red preocupados por la seguridad no siempre están entusiasmados con la idea de delegar a nadie los parámetros de acceso al PDU.
En este caso, la alternativa recomendada es crear un tercero neutral que pueda complementar el cálculo del quórum.
En caso de fallo, el nodo debe ser capaz de ver el estado de su socio o árbitro para recuperar los servicios. El árbitro también incluye una función de desconexión, si ambos nodos pueden ver al árbitro, pero no se ven entre sí.
Esta opción debe usarse junto con un método de desconexión indirecto, como un temporizador de vigilancia de hardware, que esté configurado para apagar la máquina si pierde la conexión con su nodo socio y el árbitro. De esta manera, el sobreviviente puede suponer con suficiente confianza que su nodo socio estará en un estado seguro después de que expire el temporizador de vigilancia de hardware.
La diferencia práctica entre un árbitro y un tercer nodo es que el árbitro requiere muchos menos recursos para operar y, potencialmente, puede dar servicio a más de un clúster.
Opción 3: Factor humano
El enfoque final consiste en que los supervivientes continúen realizando cualquier tarea que ya estuviesen llevando a cabo, pero no iniciar nuevos servicios hasta que el problema se resuelva por sí mismo (recuperación de la red, reinicio del nodo) o hasta que una persona asuma la responsabilidad de confirmar manualmente que la otra parte está muerta.
Opción de bonificación
¿Ya mencioné que puedes agregar un tercer nodo?
Dos racks
Por el bien del argumento, supongamos que te he convencido de las ventajas de tener un tercer nodo; ahora debemos considerar la ubicación física de los nodos. Si están alojados (y reciben energía) en el mismo rack, eso también representa un SPoF, y uno que no se puede resolver simplemente agregando un segundo rack.
Si esto es sorprendente, considera lo que pasaría si el rack con dos nodos falla, y cómo el nodo sobreviviente distinguiría esa situación de una falla de red.
La respuesta corta: es imposible, y nuevamente lidiamos con todos los problemas que surgen en el caso de dos nodos. O el nodo sobreviviente:
- ignora el quórum e intenta de manera errónea iniciar la recuperación durante las interrupciones de la red (la posibilidad de completar el desglose es una historia aparte y depende de si PDU está involucrado y si comparten energía con alguno de los racks), o
- respeta el quórum y se apaga prematuramente cuando su nodo asociado falla.
En cualquier caso, dos racks no son mejores que uno, y los nodos deben recibir fuentes de energía independientes o estar distribuidos en tres (o más, dependiendo de cuántos nodos tengas) racks.
Dos centros de datos
En este punto, los lectores que ya no están inclinados al riesgo pueden considerar la recuperación ante desastres. ¿Qué sucede cuando un asteroide impacta en un centro de datos con nuestros tres nodos distribuidos en tres racks diferentes? Obviamente, cosas malas, pero dependiendo de tus 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 tiene sentido) una copia actualizada y coherente de sus servicios y sus datos. Sin embargo, al igual que en los escenarios con dos nodos y dos racks, el sistema carece de información suficiente para garantizar la máxima disponibilidad y prevenir daños (o discrepancias en los conjuntos de datos). Incluso con tres nodos (o racks), su distribución solo entre dos centros de datos deja al sistema incapaz de tomar decisiones correctas de manera confiable en caso de un evento que ambas partes no pueden relacionar, lo cual es ahora mucho más probable.
Esto no significa que una solución con dos centros de datos nunca sea adecuada. Las empresas a menudo quieren que alguien esté al tanto antes de tomar una medida extraordinaria para pasar a un centro de datos de respaldo. Simplemente tenga en cuenta que si desea automatizar la conmutación por error, necesitará un tercer centro de datos para que el quorum tenga sentido (ya sea directamente o a través de un árbitro), o encontrará una manera de desconectar de manera confiable todo el centro de datos.
Fuente: habr.com
