Ola Habr! Presento á súa atención a tradución do artigo por Andrew Beekhof.
Moitas persoas prefiren os clústeres de dous nodos porque parecen conceptualmente máis simples e tamén son un 33% máis baratos que os seus homólogos de tres nodos. Aínda que é moi posible montar un bo clúster de dous nodos, na maioría dos casos, debido a escenarios non considerados, tal configuración creará moitos problemas pouco obvios.
O primeiro paso para crear calquera sistema de alta dispoñibilidade é atopar e intentar eliminar puntos individuais de falla, moitas veces abreviados como SPoF (punto único de falla).
Cómpre ter en conta que é imposible eliminar todos os posibles riscos de inactividade en calquera sistema. Isto débese ao feito de que unha defensa típica contra o risco é introducir certa redundancia, o que leva a unha maior complexidade do sistema e á aparición de novos puntos de falla. Polo tanto, inicialmente facemos un compromiso e centrámonos en eventos asociados a puntos individuais de falla, e non en cadeas de eventos relacionados e, polo tanto, cada vez menos probables.
Tendo en conta os compromisos, non só buscamos SPoF, senón que tamén equilibramos riscos e consecuencias, polo que a conclusión do que é crítico e do que non o é pode diferir para cada implantación.
Non todos necesitan provedores de electricidade alternativos con liñas eléctricas independentes. Aínda que a paranoia pagou polo menos a un cliente cando o seu seguimento detectou un transformador defectuoso. O cliente fixo chamadas telefónicas tentando alertar á compañía eléctrica ata que explotou o transformador avariado.
Un punto de partida natural é ter máis dun nodo no sistema. Non obstante, antes de que o sistema poida mover os servizos ao nodo supervivente despois dun fallo, xeralmente debe asegurarse de que os servizos que se están movendo non estean activos noutro lugar.
Non hai ningunha desvantaxe para un clúster de dous nodos se un fallo fai que ambos os dous sirvan o mesmo sitio web estático. Non obstante, as cousas cambian se o resultado é que ambas as partes xestionan de forma independente unha cola de traballo compartida ou proporcionan acceso de escritura non coordinado a unha base de datos replicada ou a un sistema de ficheiros compartido.
Polo tanto, para evitar a corrupción dos datos como resultado dun fallo dun só nodo, confiamos en algo chamado "disociación" (esgrima).
O principio de disociación
No corazón do principio de disociación está a pregunta: pode un nodo competidor causar corrupción de datos? No caso de que a corrupción dos datos sexa un escenario probable, unha boa solución sería illar o nodo tanto das solicitudes entrantes como do almacenamento persistente. O enfoque máis común para a disociación é desactivar os nodos defectuosos.
Hai dúas categorías de métodos de disociación, que chamarei directo и indirecta, pero tamén se poden chamar activo и pasivo. Os métodos directos inclúen accións por parte dos pares superviventes, como a interacción cun dispositivo IPMI (Intelligent Platform Management Interface) ou iLO (un mecanismo para xestionar servidores en ausencia de acceso físico a eles), mentres que os métodos indirectos dependen do fallo. nodo para recoñecer dalgún xeito que está nun estado insalubre (ou polo menos evitando que outros membros se recuperen) e sinalar sobre a necesidade de desconectar o nodo fallido.
Quorum axuda cando se usan métodos directos e indirectos.
Disociación directa
No caso de disociación directa, podemos utilizar o quórum para evitar carreiras de disociación en caso de fallo da rede.
Co concepto de quórum, hai suficiente información no sistema (mesmo sen conectarse aos seus pares) para que os nodos saiban automaticamente se deben iniciar a disociación e/ou a recuperación.
Sen quórum, ambos os dous lados dunha división de rede asumirán con razón que o outro lado está morto e buscarán desvincular o outro. No peor dos casos, ambas as partes conseguen pechar todo o clúster. Un escenario alternativo é un deathmatch, un bucle interminable de nodos que se xeran, non ven aos seus pares, reinicialos e inician a recuperación só para reiniciarse cando o seu compañeiro segue a mesma lóxica.
O problema coa disociación é que os dispositivos que se usan con máis frecuencia non están dispoñibles debido aos mesmos eventos de fallo aos que queremos apuntar para a recuperación. A maioría das tarxetas IPMI e iLO están instaladas nos hosts que supervisan e, por defecto, usan a mesma rede, o que fai que os hosts de destino crean que os outros hosts están fóra de liña.
Desafortunadamente, as funcións operativas dos dispositivos IPMI e iLo raramente se consideran no momento da compra do equipo.
Disociación indirecta
O quórum tamén é importante para xestionar a disociación indirecta; se se fai correctamente, o quórum pode permitir aos superviventes asumir que os nodos perdidos pasarán a un estado seguro despois dun determinado período de tempo.
Con esta configuración, o temporizador de control de hardware restablece cada N segundos se non se perde o quórum. Se o temporizador (xeralmente varios múltiplos de N) caduca, entón o dispositivo realiza un apagado (non apagado) desagradable.
Este enfoque é moi eficaz, pero sen quórum non hai información suficiente dentro do clúster para xestionalo. Non é doado distinguir entre unha interrupción da rede e un fallo de nodos pares. A razón pola que isto importa é que sen a capacidade de diferenciar entre os dous casos, estás obrigado a escoller o mesmo comportamento en ambos os casos.
O problema ao elixir un modo é que non hai ningún curso de acción que maximice a dispoñibilidade e evite a perda de datos.
- Se optas por asumir que un nodo do mesmo nivel está activo pero que de feito falla, o clúster parará innecesariamente os servizos que se estarían executando para compensar a perda de servizos do nodo do mesmo que fallou.
- Se decide asumir que un nodo está inactivo, pero foi só un fallo da rede e, de feito, o nodo remoto é funcional, entón, ao mellor, está a rexistrarse para unha futura reconciliación manual dos conxuntos de datos resultantes.
Independentemente da heurística que use, é trivial crear un fallo que fará que ambos lados fallen ou que o clúster apague os nodos supervivientes. Non usar quórum realmente priva ao clúster dunha das ferramentas máis poderosas do seu arsenal.
Se non hai outra alternativa, o mellor enfoque é sacrificar a dispoñibilidade (aquí o autor refírese ao teorema CAP). A alta dispoñibilidade de datos corruptos non axuda a ninguén e tampouco é divertido conciliar manualmente diferentes conxuntos de datos.
Quórum
O quórum soa xenial, non?
O único inconveniente é que para telo nun clúster con N membros, debes ter unha conexión entre N/2+1 dos teus nodos restantes. O que non é posible nun clúster de dous nodos despois de que un nodo falle.
O que finalmente nos leva ao problema fundamental con dous nodos:
O quórum non ten sentido en dous clústeres de nodos, e sen el é imposible determinar de forma fiable o curso de acción que maximice a dispoñibilidade e evite a perda de datos.
Mesmo nun sistema de dous nodos conectados por un cable cruzado, é imposible distinguir definitivamente entre unha interrupción da rede e unha falla do outro nodo. Desactivar un extremo (cuxa probabilidade é, por suposto, proporcional á distancia entre os nodos) será suficiente para invalidar calquera suposición de que a saúde da ligazón é igual á saúde do nodo socio.
Facendo funcionar un clúster de dous nodos
Ás veces o cliente non pode ou non quere comprar un terceiro nodo, e vémonos obrigados a buscar unha alternativa.
Opción 1 - Método de disociación duplicada
O dispositivo iLO ou IPMI dun nodo representa un punto de falla porque, se falla, os superviventes non poden usalo para levar o nodo a un estado seguro. Nun clúster de 3 ou máis nodos, podemos mitigar isto calculando o quórum e usando un control de hardware (un mecanismo de disociación indirecta, como se comentou anteriormente). No caso de dous nodos, debemos utilizar unidades de distribución de enerxía da rede (PDU).
Despois dun fallo, o supervivente primeiro tenta contactar co dispositivo de disociación principal (iLO ou IPMI incorporado). Se isto ten éxito, a recuperación continúa como de costume. Só se o dispositivo iLO/IPMI falla se accede á PDU; se o acceso é exitoso, a recuperación pode continuar.
Asegúrese de colocar a PDU nunha rede diferente á do tráfico do clúster, se non, un único fallo de rede bloqueará o acceso a ambos os dispositivos de disociación e bloqueará a restauración dos servizos.
Aquí podes preguntar: é a PDU un único punto de falla? A que a resposta é, por suposto.
Se este risco é importante para vostede, non está só: conecte os dous nodos a dúas PDU e dígalle ao software de agrupación que utilice ambos ao conectar e apagar os nodos. O clúster agora permanece activo se unha PDU morre, e será necesario un segundo fallo da outra PDU ou do dispositivo IPMI para bloquear a recuperación.
Opción 2 - Engadir un árbitro
Nalgúns escenarios, aínda que o método de disociación duplicada é tecnicamente posible, é politicamente difícil. A moitas empresas gústalles ter algunha separación entre administradores e propietarios de aplicacións, e os administradores de rede conscientes da seguridade non sempre están entusiasmados con compartir a configuración de acceso da PDU con ninguén.
Neste caso, a alternativa recomendada é crear un terceiro neutral que poida complementar o cálculo do quórum.
No caso de producirse un fallo, un nodo debe poder ver as ondas do seu compañeiro ou árbitro para restaurar os servizos. O árbitro tamén inclúe unha función de desconexión se ambos os nodos poden ver ao árbitro pero non se poden ver.
Esta opción debe usarse xunto cun método de disociación indirecta, como un temporizador de control de hardware, que está configurado para matar unha máquina se perde a conexión co seu nodo par e árbitro. Así, un sobrevivente pode asumir razoablemente que o seu nodo par estará nun estado seguro despois de que caduque o temporizador de control de hardware.
A diferenza práctica entre un árbitro e un terceiro nodo é que un árbitro require moitos menos recursos para operar e potencialmente pode servir a máis dun clúster.
Opción 3 - Factor humano
O enfoque final é que os superviventes continúen executando os servizos que xa estaban executando, pero non inician outros novos ata que o problema se resolva por si mesmo (restauración da rede, reinicio do nodo) ou unha persoa asume a responsabilidade de confirmar manualmente que o outro lado está morto.
Opción de bonificación
Mencionei que podes engadir un terceiro nodo?
Dous bastidores
Para argumentar, pretendamos que te convencín dos méritos do terceiro nodo, agora debemos considerar a disposición física dos nodos. Se están aloxados (e alimentados) no mesmo rack, isto tamén constitúe SPoF, e que non se pode resolver engadindo un segundo rack.
Se isto é sorprendente, considere que pasaría se fallase un bastidor con dous nodos e como o nodo superviviente diferenciaría entre iso e un fallo de rede.
A resposta curta é que non é posible, e de novo estamos lidando con todos os problemas no caso de dous nodos. Ou sobrevivente:
- ignora o quórum e tenta incorrectamente iniciar a restauración durante as interrupcións da rede (a capacidade de completar a disociación é unha historia diferente e depende de se a PDU está implicada e de se comparten enerxía con algún dos bastidores), ou
- respecta o quórum e desconéctase prematuramente cando falla o seu nodo par
En calquera caso, dous racks non son mellores que un, e os nodos deben recibir fontes de alimentación independentes ou estar distribuídos en tres (ou máis, dependendo de cantos nodos teñas) racks.
Dous centros de datos
Neste punto, os lectores que xa non son reacios ao risco poden querer considerar a recuperación ante desastres. Que ocorre cando un asteroide choca co mesmo centro de datos cos nosos tres nodos repartidos en tres racks diferentes? Obviamente cousas malas, pero dependendo das túas necesidades, engadir un segundo centro de datos pode non ser suficiente.
Se se fai correctamente, o segundo centro de datos ofrécelle (e razoablemente) unha copia actualizada e coherente dos seus servizos e dos seus datos. Non obstante, do mesmo xeito que nos escenarios de dous nodos e dous bastidores, non hai información suficiente no sistema para garantir a máxima dispoñibilidade e evitar a corrupción (ou discrepancias do conxunto de datos). Mesmo con tres nodos (ou bastidores), distribuíndoos en só dous centros de datos deixa o sistema incapaz de tomar a decisión correcta de forma fiable no caso de que se produza un evento (agora moito máis probable) que ambas partes non poidan comunicarse.
Isto non significa que unha solución de centro de datos dual nunca sexa axeitada. As empresas adoitan querer que unha persoa estea consciente antes de dar o extraordinario paso de mudarse a un centro de datos de copia de seguridade. Só ten en conta que se queres automatizar a interrupción, necesitarás un terceiro centro de datos para que o quórum teña sentido (directamente ou a través dun árbitro) ou atoparás un xeito de apagar de forma fiable todos os datos. centro.
Fonte: www.habr.com