Hola Habr! Presento a la vostra atenció la traducció de l'article per Andrew Beekhof.
Molta gent prefereix els clústers de dos nodes perquè semblen conceptualment més senzills i també són un 33% més barats que els seus homòlegs de tres nodes. Tot i que és molt possible reunir un bon clúster de dos nodes, en la majoria dels casos, a causa d'escenaris no considerats, aquesta configuració crearà molts problemes poc evidents.
El primer pas per crear qualsevol sistema d'alta disponibilitat és trobar i intentar eliminar punts individuals de fallada, sovint abreujats com a SPoF (punt de fallada únic).
Val la pena tenir en compte que és impossible eliminar tots els possibles riscos d'inactivitat en qualsevol sistema. Això es deriva del fet que una defensa típica contra el risc és introduir una certa redundància, la qual cosa comporta una major complexitat del sistema i l'aparició de nous punts de fallada. Per tant, inicialment fem un compromís i ens centrem en els esdeveniments associats a punts individuals de fallada, i no en cadenes d'esdeveniments relacionats i, per tant, cada cop menys probables.
Tenint en compte els compromisos, no només busquem SPoF, sinó que també equilibrem els riscos i les conseqüències, de manera que la conclusió del que és crític i del que no ho és pot diferir per a cada desplegament.
No tothom necessita proveïdors alternatius d'electricitat amb línies elèctriques independents. Tot i que la paranoia va donar els seus fruits com a mínim a un client quan la seva vigilància va detectar un transformador defectuós. El client va fer trucades telefòniques intentant alertar la companyia elèctrica fins que va explotar el transformador defectuós.
Un punt de partida natural és tenir més d'un node al sistema. Tanmateix, abans que el sistema pugui moure serveis al node supervivent després d'una fallada, generalment s'ha d'assegurar que els serveis que es mouen no estiguin actius a cap altre lloc.
No hi ha cap inconvenient per a un clúster de dos nodes si una fallada fa que els dos nodes serveixin el mateix lloc web estàtic. Tanmateix, les coses canvien si el resultat és que ambdues parts gestionen de manera independent una cua de treball compartida o proporcionen accés d'escriptura no coordinat a una base de dades replicada o un sistema de fitxers compartit.
Per tant, per evitar la corrupció de dades com a resultat d'una fallada d'un sol node, confiem en una cosa que es diu "dissociació" (esgrima).
El principi de dissociació
Al cor del principi de dissociació hi ha la pregunta: pot un node competidor provocar corrupció de dades? En cas que la corrupció de dades sigui un escenari probable, una bona solució seria aïllar el node tant de les sol·licituds entrants com de l'emmagatzematge persistent. L'enfocament més comú per a la desassociació és desconnectar els nodes defectuosos.
Hi ha dues categories de mètodes de dissociació, que anomenaré recte и indirectes, però igualment es poden anomenar actiu и passiu. Els mètodes directes inclouen accions per part dels companys supervivents, com ara la interacció amb un dispositiu IPMI (Interfície de gestió de la plataforma intel·ligent) o iLO (un mecanisme per gestionar servidors en absència d'accés físic a ells), mentre que els mètodes indirectes es basen en el error. node per reconèixer d'alguna manera que es troba en un estat no saludable (o almenys impedint que altres membres es recuperin) i senyal sobre la necessitat de desconnectar el node fallit.
Quòrum ajuda quan s'utilitzen mètodes directes i indirectes.
Dissociació directa
En el cas de la dissociació directa, podem utilitzar el quòrum per evitar curses de dissociació en cas de fallada de la xarxa.
Amb el concepte de quòrum, hi ha prou informació al sistema (fins i tot sense connectar-se als seus iguals) perquè els nodes sàpiguen automàticament si haurien d'iniciar la dissociació i/o la recuperació.
Sense quòrum, ambdues parts d'una divisió de xarxa assumiran amb raó que l'altra banda està morta i intentaran desvincular l'altra. En el pitjor dels casos, ambdues parts aconsegueixen tancar tot el clúster. Un escenari alternatiu és un partit a mort, un bucle interminable de nodes que es generen, no veuen els seus companys, els reinicien i inicien la recuperació només per reiniciar-se quan el seu igual segueix la mateixa lògica.
El problema de la desassociació és que els dispositius més utilitzats no estan disponibles a causa dels mateixos esdeveniments de fallada als quals volem orientar-nos per a la recuperació. La majoria de les targetes IPMI i iLO s'instal·len als amfitrions que controlen i, per defecte, utilitzen la mateixa xarxa, cosa que fa que els amfitrions de destinació creguin que altres amfitrions estan fora de línia.
Malauradament, les característiques operatives dels dispositius IPMI i iLo rarament es tenen en compte en el moment de la compra de l'equip.
Dissociació indirecta
El quòrum també és important per gestionar la dissociació indirecta; si es fa correctament, el quòrum pot permetre als supervivents assumir que els nodes perduts passaran a un estat segur després d'un període de temps determinat.
Amb aquesta configuració, el temporitzador de control de maquinari es restableix cada N segons si no es perd el quòrum. Si el temporitzador (generalment diversos múltiples de N) caduca, el dispositiu realitza una apagada sense gràcia (no s'apaga).
Aquest enfocament és molt eficaç, però sense quòrum no hi ha prou informació dins del clúster per gestionar-lo. No és fàcil distingir entre una interrupció de la xarxa i una fallada del node igual. El motiu pel qual això importa és que sense la capacitat de diferenciar els dos casos, estàs obligat a triar el mateix comportament en tots dos casos.
El problema de triar un mode és que no hi ha cap curs d'acció que maximitzi la disponibilitat i eviti la pèrdua de dades.
- Si opteu per assumir que un node igual està actiu però que de fet falla, el clúster aturarà innecessàriament els serveis que s'estarien executant per compensar la pèrdua de serveis del node igual que ha fallat.
- Si decidiu assumir que un node està caigut, però només va ser una fallada de la xarxa i, de fet, el node remot és funcional, en el millor dels casos us inscriureu per a una futura conciliació manual dels conjunts de dades resultants.
Independentment de quina heurística utilitzeu, és trivial crear una fallada que provoqui que les dues parts fallin o que el clúster tanqui els nodes supervivents. No utilitzar quòrum realment priva el clúster d'una de les eines més potents del seu arsenal.
Si no hi ha cap altra alternativa, el millor enfocament és sacrificar la disponibilitat (aquí l'autor fa referència al teorema CAP). L'alta disponibilitat de dades danyades no ajuda ningú, i conciliar manualment diferents conjunts de dades tampoc no és divertit.
Quòrum
El quòrum sona molt bé, oi?
L'únic inconvenient és que per tenir-lo en un clúster amb N membres, heu de tenir una connexió entre N/2+1 dels vostres nodes restants. Cosa que no és possible en un clúster de dos nodes després que un node falla.
El que finalment ens porta al problema fonamental amb dos nodes:
El quòrum no té sentit en dos clústers de nodes, i sense ell és impossible determinar de manera fiable el curs d'acció que maximitzi la disponibilitat i eviti la pèrdua de dades.
Fins i tot en un sistema de dos nodes connectats per un cable creuat, és impossible distingir definitivament entre una interrupció de la xarxa i una fallada de l'altre node. Desactivar un extrem (la probabilitat del qual és, per descomptat, proporcional a la distància entre els nodes) serà suficient per invalidar qualsevol suposició que la salut de l'enllaç és igual a la salut del node soci.
Fer que un clúster de dos nodes funcioni
De vegades el client no pot o no vol comprar un tercer node, i ens veiem obligats a buscar una alternativa.
Opció 1 - Mètode de dissociació duplicada
El dispositiu iLO o IPMI d'un node representa un punt de fallada perquè, si falla, els supervivents no poden utilitzar-lo per portar el node a un estat segur. En un clúster de 3 o més nodes, podem mitigar-ho calculant el quòrum i utilitzant un control de maquinari (un mecanisme de dissociació indirecta, com s'ha comentat anteriorment). En el cas de dos nodes, hem d'utilitzar les unitats de distribució d'energia de xarxa (PDU).
Després d'un error, el supervivent primer intenta contactar amb el dispositiu de desassociació principal (iLO o IPMI incrustat). Si això té èxit, la recuperació continua com de costum. Només si el dispositiu iLO/IPMI falla s'accedeix a la PDU; si l'accés té èxit, la recuperació pot continuar.
Assegureu-vos de col·locar la PDU en una xarxa diferent a la del trànsit del clúster, en cas contrari, una única fallada de xarxa bloquejarà l'accés als dos dispositius de desassociació i bloquejarà la restauració dels serveis.
Aquí us podeu preguntar: és la PDU un únic punt de falla? A la qual la resposta és, és clar.
Si aquest risc és significatiu per a vostè, no esteu sols: connecteu els dos nodes a dues PDU i digueu al programari de clúster que els utilitzi quan engegueu i apagueu els nodes. El clúster ara roman actiu si una PDU mor, i caldrà una segona fallada de l'altra PDU o del dispositiu IPMI per bloquejar la recuperació.
Opció 2: afegir un àrbitre
En alguns escenaris, tot i que el mètode de dissociació duplicat és tècnicament possible, políticament és difícil. A moltes empreses els agrada tenir una certa separació entre administradors i propietaris d'aplicacions, i els administradors de xarxa conscients de la seguretat no sempre estan entusiasmats amb compartir la configuració d'accés a la PDU amb ningú.
En aquest cas, l'alternativa recomanada és crear un tercer neutral que pugui complementar el càlcul del quòrum.
En cas d'error, un node ha de ser capaç de veure les ones del seu parell o àrbitre per tal de restaurar els serveis. L'àrbitre també inclou una funció de desconnexió si els dos nodes poden veure l'àrbitre però no es veuen.
Aquesta opció s'ha d'utilitzar juntament amb un mètode de desassociació indirecta, com ara un temporitzador de control de maquinari, que està configurat per matar una màquina si perd la connexió amb el seu node igual i àrbitre. Per tant, un supervivent pot suposar raonablement que el seu node igual estarà en un estat segur després que caduqui el temporitzador de control de maquinari.
La diferència pràctica entre un àrbitre i un tercer node és que un àrbitre requereix molts menys recursos per funcionar i pot servir a més d'un clúster.
Opció 3 - Factor humà
L'enfocament final és que els supervivents continuïn executant els serveis que ja estaven executant, però no en iniciïn de nous fins que el problema es resolgui per si mateix (restauració de la xarxa, reinici del node) o una persona assumeixi la responsabilitat de confirmar manualment que l'altre costat està mort.
Opció de bonificació
He esmentat que podeu afegir un tercer node?
Dos bastidors
Per argumentar, suposem que us he convençut dels mèrits del tercer node, ara hem de considerar la disposició física dels nodes. Si estan allotjats (i alimentats) al mateix bastidor, això també constitueix SPoF, i que no es pot resoldre afegint un segon bastidor.
Si això és sorprenent, considereu què passaria si un bastidor amb dos nodes fallés i com el node supervivent diferenciaria entre això i una fallada de xarxa.
La resposta breu és que no és possible, i de nou estem tractant tots els problemes en el cas de dos nodes. O supervivent:
- ignora el quòrum i intenta iniciar la restauració de manera incorrecta durant les interrupcions de la xarxa (la capacitat de completar la dissociació és una història diferent i depèn de si la PDU està involucrada i si comparteixen l'alimentació amb algun dels bastidors), o
- respecta el quòrum i es desconnecta prematurament quan el seu node igual falla
En qualsevol cas, dos bastidors no són millors que un, i els nodes han de rebre fonts d'alimentació independents o bé estar distribuïts en tres (o més, depenent de quants nodes tinguis) bastidors.
Dos centres de dades
En aquest punt, és possible que els lectors que ja no tinguin aversions al risc vulguin considerar la recuperació en cas de desastre. Què passa quan un asteroide colpeja el mateix centre de dades amb els nostres tres nodes repartits per tres bastidors diferents? Òbviament, coses dolentes, però depenent de les vostres necessitats, afegir un segon centre de dades pot no ser suficient.
Si es fa correctament, el segon centre de dades us proporciona (i raonablement) una còpia actualitzada i coherent dels vostres serveis i les seves dades. Tanmateix, com en els escenaris de dos nodes i dos bastidors, no hi ha prou informació al sistema per garantir la màxima disponibilitat i evitar la corrupció (o discrepàncies en el conjunt de dades). Fins i tot amb tres nodes (o bastidors), distribuir-los només en dos centres de dades fa que el sistema no pugui prendre la decisió correcta de manera fiable en cas d'un esdeveniment (ara molt més probable) que ambdues parts no es puguin comunicar.
Això no vol dir que una solució de centre de dades dual mai sigui adequada. Les empreses sovint volen que una persona estigui al corrent abans de fer el pas extraordinari de passar a un centre de dades de còpia de seguretat. Tingueu en compte que si voleu automatitzar l'interrupció, necessitareu un tercer centre de dades perquè el quòrum tingui sentit (directament o mitjançant un àrbitre), o trobareu una manera d'aturar totes les dades de manera fiable. centre.
Font: www.habr.com