{"id":75726,"date":"2020-03-28T07:42:08","date_gmt":"2020-03-28T05:42:08","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/klaster-iz-dvuh-uzlov-dyavol-v-detalyah"},"modified":"2020-03-28T07:42:08","modified_gmt":"2020-03-28T05:42:08","slug":"klaster-iz-dvuh-uzlov-dyavol-v-detalyah","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/klaster-iz-dvuh-uzlov-dyavol-v-detalyah","title":{"rendered":"Cl\u00faster de dos nodos: el diablo est\u00e1 en los detalles","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\u00a1Hola, Habr! Les presento la traducci\u00f3n del art\u00edculo \u00abDos Nodos \u2014 El Diablo est\u00e1 en los Detalles\u00bb<\/a><\/noindex> del autor Andrew Beekhof.<\/p>\n

Muchas personas prefieren cl\u00fasteres compuestos por dos nodos, ya que parecen conceptualmente m\u00e1s simples y, adem\u00e1s, son un 33% m\u00e1s econ\u00f3micos que sus contrapartes de tres nodos. Aunque es completamente posible construir un buen cl\u00faster de dos nodos, en la mayor\u00eda de los casos, debido a escenarios no considerados, esta configuraci\u00f3n generar\u00e1 muchos problemas no evidentes.
\n<\/a><\/noindex>
\nEl primer paso para crear cualquier sistema de alta disponibilidad es identificar y tratar de eliminar los puntos \u00fanicos de falla, a menudo abreviados como SPoF<\/i> (punto \u00fanico de falla).<\/p>\n

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\u00f3n t\u00edpica contra riesgos implica introducir cierta redundancia, lo que lleva a un aumento en la complejidad del sistema y a la aparici\u00f3n de nuevos puntos de falla. Por lo tanto, desde el principio hacemos un compromiso y nos enfocamos en los eventos relacionados con puntos \u00fanicos de falla, en lugar de en las cadenas de eventos relacionados, que son cada vez menos probables.<\/p>\n

Teniendo en cuenta los compromisos, no solo buscamos SPoF, sino que tambi\u00e9n equilibramos los riesgos y las consecuencias, resultando que lo que es cr\u00edtico y lo que no puede diferir en cada despliegue.<\/p>\n

No todos necesitan proveedores alternativos de energ\u00eda con l\u00edneas de transmisi\u00f3n independientes. Aunque la paranoia ha valido la pena al menos para un cliente, cuando su monitoreo detect\u00f3 un transformador defectuoso. El cliente llam\u00f3 tratando de advertir a la compa\u00f1\u00eda energ\u00e9tica, hasta que el transformador defectuoso explot\u00f3.<\/p><\/blockquote>\n

\nUn punto de partida natural es tener m\u00e1s de un nodo en el sistema. Sin embargo, antes de que el sistema pueda mover los servicios al nodo sobreviviente despu\u00e9s de una falla, en general, es necesario asegurarse de que los servicios que se desplazan no est\u00e9n activos en otro lugar.<\/p>\n

Un cl\u00faster de dos nodos no tiene desventajas si como resultado de una falla ambos nodos atienden el mismo sitio web est\u00e1tico. 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.<\/p>\n

Por lo tanto, para evitar da\u00f1os en los datos debido a la fallaci\u00f3n de un nodo, nos basamos en lo que se llama \u00abaislamiento\u00bb<\/i> (fencing).<\/p>\n

El principio de aislamiento<\/h2>\n

\nEn la base del principio de aislamiento se encuentra la pregunta: \u00bfpuede un nodo competidor causar da\u00f1os en los datos? Si se considera que el da\u00f1o en los datos es un escenario probable, una buena soluci\u00f3n ser\u00eda aislar el nodo tanto de las solicitudes entrantes como del almacenamiento persistente. El enfoque m\u00e1s com\u00fan para el aislamiento es desconectar los nodos defectuosos.<\/p>\n

Hay dos categor\u00edas de m\u00e9todos de aislamiento que llamar\u00e9 directos<\/i> y indirectos<\/i>, pero igualmente se les puede llamar activos<\/i> y pasivos<\/i>. Los m\u00e9todos directos incluyen acciones por parte de los nodos pares sobrevivientes, como interactuar con el dispositivo IPMI (Interfaz de Gesti\u00f3n de Plataforma Inteligente) o iLO (mecanismo de gesti\u00f3n de servidores en condiciones de no tener acceso f\u00edsico a ellos), mientras que los m\u00e9todos indirectos dependen del nodo fallido para reconocer de alguna manera que est\u00e1 en un estado no saludable (o, al menos, interfiere con otros miembros para recuperarse) y se\u00f1alar hardware watchdog<\/a><\/noindex> la necesidad de desconectar el nodo fallido.<\/p>\n

El qu\u00f3rum ayuda tanto en el uso de m\u00e9todos directos como indirectos.<\/p>\n

Aislamiento directo<\/h3>\n

\nEn el caso del aislamiento directo, podemos usar el qu\u00f3rum para prevenir condiciones de carrera de aislamiento en el caso de una falla de red.<\/p>\n

Con el concepto de qu\u00f3rum, el sistema tiene suficiente informaci\u00f3n (incluso sin conexi\u00f3n a sus socios) para que los nodos sepan autom\u00e1ticamente si deben iniciar el aislamiento y\/o la recuperaci\u00f3n.<\/p>\n

Sin qu\u00f3rum, ambas partes de la divisi\u00f3n de red asumen leg\u00edtimamente que la otra parte est\u00e1 muerta y tratar\u00e1n de aislar a la otra. En el peor de los casos, ambas partes logran desconectar todo el cl\u00faster. Un escenario alternativo es un deathmatch, un ciclo infinito de nodos que aparecen, no ven a sus pares, los reinician e inician la recuperaci\u00f3n solo para reiniciarse cuando su par pasa por la misma l\u00f3gica.<\/p>\n

El problema de la partici\u00f3n se debe a que los dispositivos m\u00e1s utilizados se vuelven inaccesibles debido a los mismos eventos de fallo en los que queremos basarnos para la recuperaci\u00f3n. La mayor\u00eda de las tarjetas IPMI e iLO est\u00e1n 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\u00e1n fuera de l\u00ednea.<\/p>\n

Desafortunadamente, las caracter\u00edsticas de funcionamiento de los dispositivos IPMI e iLo rara vez se consideran al momento de comprar el equipo.<\/p>\n

Partici\u00f3n indirecta<\/h3>\n

\nEl qu\u00f3rum tambi\u00e9n es importante para gestionar las particiones indirectas; si se hace correctamente, el qu\u00f3rum puede permitir a los supervivientes suponer que los nodos perdidos entrar\u00e1n en un estado seguro despu\u00e9s de un cierto per\u00edodo de tiempo.<\/p>\n

Con esta configuraci\u00f3n, el temporizador del hardware watchdog se reinicia cada N segundos si no se ha perdido el qu\u00f3rum. Si el temporizador (normalmente unos m\u00faltiplos de N) expira, el dispositivo realiza un apagado sin gracia (no shutdown).<\/p>\n

Este enfoque es muy eficaz, pero sin qu\u00f3rum para gestionarlo, no hay suficiente informaci\u00f3n dentro del cl\u00faster. No es f\u00e1cil distinguir entre un corte de red y un fallo del nodo compa\u00f1ero. La raz\u00f3n 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.<\/p>\n

El problema de elegir un modo es que no hay un curso de acci\u00f3n que maximice la disponibilidad y evite la p\u00e9rdida de datos.<\/p>\n