¡Hola, Habr! Presento a su atención la traducción del artículo. por Andrew Beekhof.
Mucha gente prefiere los clústeres de dos nodos porque parecen conceptualmente más simples y también son un 33 % más baratos que sus homólogos de tres nodos. Aunque es muy posible reunir un buen grupo de dos nodos, en la mayoría de los casos, debido a escenarios no considerados, dicha configuración creará muchos problemas no obvios.
El primer paso para crear cualquier sistema de alta disponibilidad es encontrar e intentar eliminar puntos individuales de falla, a menudo abreviados como SPoF (punto único de fallo).
Vale la pena tener en cuenta que es imposible eliminar todos los posibles riesgos de tiempo de inactividad en cualquier sistema. Esto se debe al hecho de que una defensa típica contra el riesgo es introducir cierta redundancia, lo que conduce a una mayor complejidad del sistema y al surgimiento de nuevos puntos de falla. Por lo tanto, inicialmente hacemos un compromiso y nos centramos en eventos asociados con puntos de falla individuales, y no en cadenas de eventos relacionados y, por lo tanto, cada vez menos probables.
Teniendo en cuenta las compensaciones, no solo buscamos SPoF, sino que también equilibramos los riesgos y las consecuencias, como resultado de lo cual la conclusión de lo que es crítico y lo que no lo es puede diferir para cada implementación.
No todo el mundo necesita proveedores de electricidad alternativos con líneas eléctricas independientes. Aunque la paranoia dio sus frutos para al menos un cliente cuando su monitoreo detectó un transformador defectuoso. El cliente hizo llamadas telefónicas intentando alertar a la compañía eléctrica hasta que explotó el transformador defectuoso.
Un punto de partida natural es tener más de un nodo en el sistema. Sin embargo, antes de que el sistema pueda mover servicios al nodo superviviente después de una falla, generalmente necesita asegurarse de que los servicios que se están moviendo no estén activos en ningún otro lugar.
No hay ningún inconveniente en un clúster de dos nodos si una falla provoca que ambos nodos sirvan al mismo sitio web estático. Sin embargo, las cosas cambian si el resultado es que ambas partes administran de forma independiente una cola de trabajos compartida o proporcionan acceso de escritura no coordinado a una base de datos replicada o un sistema de archivos compartido.
Por lo tanto, para evitar la corrupción de datos como resultado de una falla de un solo nodo, confiamos en algo llamado "disociación" (Esgrima).
El principio de disociación.
En el centro del principio de disociación está la pregunta: ¿puede un nodo en competencia causar corrupción de datos? En caso de que la corrupción de datos sea 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 la disociación es desconectar los nodos defectuosos.
Hay dos categorías de métodos de disociación, que llamaré recto и indirecta, pero también pueden llamarse activo и pasivo. Los métodos directos incluyen acciones por parte de los pares supervivientes, como la interacción con un dispositivo IPMI (Interfaz de administración de plataforma inteligente) o iLO (un mecanismo para administrar servidores en ausencia de acceso físico a ellos), mientras que los métodos indirectos se basan en el error. nodo reconozca de alguna manera que se encuentra en un estado no saludable (o al menos impidiendo que otros miembros se recuperen) y señale sobre la necesidad de desconectar el nodo fallido.
El quórum ayuda cuando se utilizan métodos tanto directos como indirectos.
disociación directa
En el caso de disociación directa, podemos utilizar el quórum para evitar carreras de disociación en caso de una falla de la red.
Con el concepto de quórum, hay suficiente información en el sistema (incluso sin conectarse a sus pares) para que los nodos sepan automáticamente si deben iniciar la disociación y/o la recuperación.
Sin quórum, ambos lados de una red dividida asumirán con razón que el otro lado está muerto y buscarán disociarse. En el peor de los casos, ambas partes logran cerrar todo el clúster. Un escenario alternativo es un combate a muerte, un bucle interminable de nodos que se generan, no ven a sus pares, los reinician e inician la recuperación solo para reiniciarse cuando sus pares siguen la misma lógica.
El problema con la disociación es que los dispositivos más utilizados dejan de estar disponibles debido a los mismos eventos de falla que queremos buscar para la recuperación. La mayoría de las tarjetas IPMI e iLO están instaladas en los hosts que controlan y, de forma predeterminada, utilizan la misma red, lo que hace que los hosts de destino crean que otros hosts están desconectados.
Desafortunadamente, las características operativas de los dispositivos IPMI e iLo rara vez se consideran al momento de comprar el equipo.
disociación indirecta
El quórum también es importante para gestionar la disociación indirecta; si se hace correctamente, el quórum puede permitir a los supervivientes asumir que los nodos perdidos pasarán a un estado seguro después de un cierto período de tiempo.
Con esta configuración, el temporizador de vigilancia del hardware se reinicia cada N segundos si no se pierde el quórum. Si el temporizador (normalmente varios múltiplos de N) expira, entonces el dispositivo realiza un apagado inesperado (no un apagado).
Este enfoque es muy eficaz, pero sin quórum no hay suficiente información dentro del clúster para gestionarlo. No es fácil distinguir entre una interrupción de la red y una falla en un nodo par. 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 comportamiento en ambos casos.
El problema de elegir un modo es que no existe un curso de acción que maximice la disponibilidad y evite la pérdida de datos.
- Si elige asumir que un nodo par está activo pero en realidad falla, el clúster detendrá innecesariamente los servicios que se estarían ejecutando para compensar la pérdida de servicios del nodo par fallido.
- Si decide asumir que un nodo está inactivo, pero fue solo una falla de la red y, de hecho, el nodo remoto funciona, entonces, en el mejor de los casos, se está registrando para una futura conciliación manual de los conjuntos de datos resultantes.
Independientemente de la heurística que utilice, es trivial crear una falla que provoque que ambas partes fallen o que el clúster apague los nodos supervivientes. No utilizar el quórum realmente priva al clúster de una de las herramientas más poderosas de su arsenal.
Si no hay otra alternativa, el mejor enfoque es sacrificar la disponibilidad (aquí el autor se refiere al teorema CAP). La alta disponibilidad de datos corruptos no ayuda a nadie, y conciliar manualmente diferentes conjuntos de datos tampoco es divertido.
Quórum
Quórum suena genial, ¿verdad?
El único inconveniente es que para tenerlo en un clúster con N miembros, necesita tener una conexión entre N/2+1 de sus nodos restantes. Lo cual no es posible en un clúster de dos nodos después de que falla un nodo.
Lo que finalmente nos lleva al problema fundamental con dos nodos:
El quórum no tiene sentido en clústeres de dos nodos y sin él es imposible determinar de manera confiable el curso de acción que maximiza la disponibilidad y evita la pérdida de datos.
Incluso en un sistema de dos nodos conectados por un cable cruzado, es imposible distinguir definitivamente entre una interrupción de la red y un fallo del otro nodo. Deshabilitar un extremo (cuya probabilidad es, por supuesto, proporcional a la distancia entre los nodos) será suficiente para invalidar cualquier suposición de que la salud del enlace es igual a la salud del nodo asociado.
Hacer que un clúster de dos nodos funcione
En ocasiones 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 disociación duplicada
El dispositivo iLO o IPMI de un nodo representa un punto de falla porque, si falla, los sobrevivientes no pueden usarlo para llevar el nodo a un estado seguro. En un grupo de 3 o más nodos, podemos mitigar esto calculando el quórum y utilizando un mecanismo de vigilancia de hardware (un mecanismo de disociación indirecto, como se analizó anteriormente). En el caso de dos nodos, debemos utilizar unidades de distribución de energía (PDU) de red en su lugar.
Después de una falla, el sobreviviente primero intenta comunicarse con el dispositivo de disociación principal (iLO o IPMI integrado). Si esto tiene éxito, la recuperación continúa como de costumbre. Solo si el dispositivo iLO/IPMI falla se accede a la PDU; si el acceso es exitoso, la recuperación puede continuar.
Asegúrese de colocar la PDU en una red diferente a la del tráfico del clúster; de lo contrario, una única falla de la red bloqueará el acceso a ambos dispositivos de disociación y bloqueará la restauración de los servicios.
Aquí usted puede preguntarse: ¿es la PDU un único punto de falla? A lo que la respuesta es, por supuesto que sí.
Si este riesgo es importante para usted, no está solo: conecte ambos nodos a dos PDU e indique al software de agrupación que utilice ambos al encender y apagar los nodos. El clúster ahora permanece activo si una PDU muere y será necesaria una segunda falla de la otra PDU o del dispositivo IPMI para bloquear la recuperación.
Opción 2: agregar un árbitro
En algunos escenarios, si bien el método de disociación duplicada es técnicamente posible, es políticamente difícil. A muchas empresas les gusta tener cierta separación entre administradores y propietarios de aplicaciones, y los administradores de red preocupados por la seguridad no siempre están entusiasmados con la idea de compartir la configuración de acceso de la PDU con 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, un nodo debe poder ver las ondas de radio de su par o árbitro para poder restaurar los servicios. El árbitro también incluye una función de desconexión si ambos nodos pueden ver al árbitro pero no pueden verse entre sí.
Esta opción debe usarse junto con un método de disociación indirecta, como un temporizador de vigilancia de hardware, que está configurado para detener una máquina si pierde la conexión con su par y su nodo árbitro. Por lo tanto, un superviviente puede suponer razonablemente que su nodo par estará en un estado seguro después de que expire el temporizador de vigilancia del hardware.
La diferencia práctica entre un árbitro y un tercer nodo es que un árbitro requiere muchos menos recursos para funcionar y potencialmente puede servir a más de un clúster.
Opción 3 - Factor humano
El enfoque final es que los supervivientes continúen ejecutando los servicios que ya estaban ejecutando, pero no inicien otros nuevos hasta que el problema se resuelva por sí solo (restauración de la red, reinicio del nodo) o una persona asuma la responsabilidad de confirmar manualmente que el otro lado está muerto.
Opción de bonificación
¿Mencioné que puedes agregar un tercer nodo?
Dos bastidores
Por el bien del argumento, supongamos que lo he convencido de los méritos del tercer nodo, ahora debemos considerar la disposición física de los nodos. Si están alojados (y alimentados) en el mismo rack, esto también constituye SPoF, y no se puede resolver agregando un segundo rack.
Si esto le sorprende, considere lo que sucedería si fallara un bastidor con dos nodos y cómo el nodo superviviente diferenciaría entre eso y una falla de la red.
La respuesta corta es que esto no es posible y nuevamente nos enfrentamos a todos los problemas en el caso de dos nodos. O sobreviviente:
- ignora el quórum e intenta incorrectamente iniciar la restauración durante cortes de red (la capacidad de completar la disociación es una historia diferente y depende de si la PDU está involucrada y si comparten energía con alguno de los racks), o
- respeta el quórum y se desconecta prematuramente cuando falla su nodo par
En cualquier caso, dos racks no son mejores que uno, y los nodos deben recibir fuentes de alimentación independientes o distribuirse en tres (o más, dependiendo de cuántos nodos tenga) racks.
Dos centros de datos
En este punto, los lectores que ya no sean reacios al riesgo tal vez quieran considerar la recuperación ante desastres. ¿Qué sucede cuando un asteroide golpea el mismo centro de datos con nuestros tres nodos repartidos en tres bastidores diferentes? Obviamente, cosas malas, pero dependiendo de sus necesidades, agregar un segundo centro de datos puede no ser suficiente.
Si se hace correctamente, el segundo centro de datos le proporciona (y de manera razonable) una copia actualizada y consistente de sus servicios y sus datos. Sin embargo, como en escenarios de dos nodos y dos racks, no hay suficiente información en el sistema para garantizar la máxima disponibilidad y evitar la corrupción (o discrepancias en los conjuntos de datos). Incluso con tres nodos (o bastidores), distribuirlos en sólo dos centros de datos deja al sistema incapaz de tomar de manera confiable la decisión correcta en caso de un evento (ahora mucho más probable) en el que ambas partes no pueden comunicarse.
Esto no significa que una solución de centro de datos dual nunca sea adecuada. Las empresas a menudo quieren que una persona esté consciente antes de dar el extraordinario paso de mudarse a un centro de datos de respaldo. Solo tenga en cuenta que si desea automatizar la interrupción, 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 cerrar de manera confiable todos los datos. centro.
Fuente: habr.com