Ehi Habr! Prestu à a vostra attenzione a traduzzione di l'articulu di Andrew Beekhof.
Parechje persone preferanu clusters di dui nodi perchè parenu cuncettualmente più simplici è sò ancu 33% più prezzu di i so contraparti di trè nodi. Ancu s'ellu hè abbastanza pussibule di mette inseme un bonu cluster di dui nodi, in a maiò parte di i casi, per via di scenarii inconsiderati, una tale cunfigurazione crea assai prublemi micca evidenti.
U primu passu per creà qualsiasi sistema di alta dispunibilità hè di truvà è pruvà à eliminà i punti individuali di fallimentu, spessu abbreviati cum'è SPoF (puntu unicu di fallimentu).
Hè vale a pena tene in mente chì hè impussibile di eliminà tutti i risichi pussibuli di downtime in ogni sistema. Questu vene da u fattu chì una difesa tipica contr'à u risicu hè di intruduce qualchì redundanza, chì porta à una crescita di a cumplessità di u sistema è l'emergenza di novi punti di fallimentu. Dunque, facemu inizialmente un cumprumissu è fucalizza nantu à l'avvenimenti assuciati cù punti individuali di fallimentu, è micca in catene di avvenimenti rilativi è, dunque, sempre più menu prubabile.
In vista di i trade-offs, ùn avemu micca solu circà SPoF, ma ancu equilibriu risichi è cunsiquenzi, per via di quale a cunclusione di ciò chì hè criticu è ciò chì ùn hè micca pò differisce per ogni implementazione.
Ùn tutti ùn anu bisognu di fornitori alternativi di energia elettrica cù linee elettriche indipendenti. Ancu s'è a paranoia hà pagatu per almenu un cliente quandu u so monitoraghju hà rilevatu un transformatore difettu. U cliente hà fattu telefonate per pruvà à avvisà a cumpagnia di energia finu à chì u transformatore difettu splode.
Un puntu di partenza naturali hè di avè più di un node in u sistema. In ogni casu, prima chì u sistema pò spustà i servizii à u node sopravviventi dopu un fallimentu, in generale hà bisognu di assicurà chì i servizii chì sò spustati ùn sò micca attivi in altrò.
Ùn ci hè micca svantaghju per un cluster di dui nodi se un fallimentu risultatu in i dui nodi chì serve u stessu situ web staticu. Tuttavia, e cose cambianu se u risultatu hè chì i dui partiti gestionenu indipindentamente una fila di travagliu spartutu o furnisce un accessu di scrittura senza coordinazione à una basa di dati replicata o sistema di fugliale spartutu.
Dunque, per prevene a corruzzione di dati com'è u risultatu di un fallimentu unicu di nodu - avemu a basa di qualcosa chjamata "disociazione" (scherma).
U principiu di dissociazione
À u core di u principiu di dissociazione hè a quistione: pò un node cuncurrenti pruvucà a corruzzione di dati? In casu chì a corruzzione di dati hè un scenariu prubabile, una bona suluzione seria isolà u node da e dumande entrate è da u almacenamentu persistente. L'approcciu più cumuni per a dissociazione hè di disattivà i nodi difetti.
Ci sò dui categurie di metudi di dissociazione, chì chjamaraghju drittu и indirettu, ma ponu esse chjamati ugualmente attivu и passivu. I metudi diretti includenu l'azzioni da parte di i pari sopravviventi, cum'è l'interazzione cù un IPMI (Interfaccia di Gestione di Piattaforma Intelligente) o iLO (un mecanismu per gestisce i servitori in l'absenza di accessu fisicu à elli), mentre chì i metudi indiretti si basanu nantu à u fallimentu. node per ricunnosce in qualchì modu chì hè in un statu malsanu (o almenu impedisce à l'altri membri di ricuperà) è signalà circa a necessità di disconnect u node fallutu.
Quorum aiuta à utilizà i metudi diretti è indiretti.
Disociazione diretta
In u casu di dissociazione diretta, pudemu usà quorum per prevene e razzii di dissociazione in casu di fallimentu di a rete.
Cù u cuncettu di quorum, ci hè abbastanza infurmazione in u sistema (ancu senza cunnette cù i so pari) per i nodi per sapè automaticamente s'ellu deve inizià a dissociazione è / o ricuperazione.
Sans quorum, les deux côtés d'une division du réseau assumeront à juste titre que l'autre partie est morte et chercheront à dissocier l'autre. In u peghju casu, i dui partiti riescenu à chjude tuttu u cluster. Un scenariu alternativu hè un deathmatch, un ciclu infinitu di nodi chì spawning, senza vede i so pari, rebooting, è inizià a ricuperazione solu per reboot quandu u so peer segue a stessa logica.
U prublema cù a disassociazione hè chì i dispositi più cumunimenti utilizati diventanu indisponibili per via di i stessi avvenimenti di fallimentu chì vulemu mira per a ricuperazione. A maiò parte di e carte IPMI è iLO sò stallati nantu à l'ospiti chì cuntrolanu è, per automaticamente, utilizanu a listessa reta, chì face chì l'ospiti di destinazione crede chì l'altri ospiti sò offline.
Sfortunatamente, e funzioni operative di i dispositi IPMI è iLo sò raramente cunsiderate à u mumentu di a compra di l'equipaggiu.
Disociazione indiretta
Quorum hè ancu impurtante per a gestione di a dissociazione indiretta; se hè fattu bè, u quorum pò permette à i sopravviventi di assume chì i nodi persi passanu à un statu sicuru dopu un certu periodu di tempu.
Cù sta cunfigurazione, u timer di watchdog hardware hè resettatu ogni N seconde se u quorum ùn hè micca persu. Se u cronometru (di solitu parechji multipli di N) scade, u dispusitivu esegue una putenza senza grazia (micca chjude).
Stu approcciu hè assai efficace, ma senza quorum ùn ci hè micca abbastanza infurmazione in u cluster per gestisce. Ùn hè micca faciule per dì a diffarenza trà una interrupzione di a rete è un fallimentu di u nodu paru. U mutivu di sta materia hè chì senza a capacità di diferenze trà i dui casi, vi sò furzati à sceglie u listessu cumpurtamentu in i dui casi.
U prublema cù a scelta di un modu hè chì ùn ci hè micca un cursu di azzione chì maximiza a dispunibilità è impedisce a perdita di dati.
- Se sceglite di assume chì un node peer hè attivu, ma in fattu falla, u cluster fermarà inutilmente i servizii chì seranu in esecuzione per cumpensà a perdita di servizii da u node peer fallutu.
- Se decide di assume chì un node hè falatu, ma era solu un fallimentu di a rete è in fattu u node remotu hè funziunale, allora in u megliu vi firmate per una futura cunciliazione manuale di i setti di dati resultanti.
Indipendentemente da ciò chì heuristicu aduprate, hè triviale per creà un fallimentu chì pruvucarà i dui lati à fallu o chì u cluster chjude i nodi sopravviventi. Ùn aduprate micca quorum veramente priva u cluster di unu di i strumenti più putenti in u so arsenale.
Se ùn ci hè micca altra alternativa, u megliu approcciu hè di sacrificà a dispunibilità (qui l'autore si riferisce à u teorema CAP). L'alta dispunibilità di dati currutti ùn aiuta à nimu, è cuncilià manualmente diversi setti di dati ùn hè micca divertente.
Quorum
Quorum sona grande, nò?
L'unicu inconveniente hè chì per avè in un cluster cù N membri, avete bisognu di avè una cunnessione trà N / 2 + 1 di i vostri nodi restante. Chì ùn hè micca pussibule in un cluster di dui nodi dopu chì un node falla.
Chì ultimamente ci porta à u prublema fundamentale cù dui nodi:
Quorum ùn hà micca sensu in dui clusters di nodi, è senza ellu hè impussibile di determinà in modu affidabile u cursu di l'azzione chì maximizeghja a dispunibilità è impedisce a perdita di dati.
Ancu in un sistema di dui nodi cunnessi da un cable crossover, hè impussibile di distinguish definitivamente trà un outage di a rete è un fallimentu di l'altru node. A disattivazione di una fine (a probabilità di quale hè, sicuru, proporzionale à a distanza trà i nodi) serà abbastanza per invalidà ogni ipotesi chì a salute di u ligame hè uguale à a salute di u node partner.
Fà u travagliu di un cluster di dui nodi
A volte u cliente ùn pò micca o ùn vole micca cumprà un terzu node, è simu furzati à circà una alternativa.
Opzione 1 - Metudu di dissociazione duplicata
U dispositivu iLO o IPMI di un nodu rapprisenta un puntu di fallimentu perchè, se falla, i sopravviventi ùn ponu micca aduprà per portà u nodu à un statu sicuru. In un cluster di 3 o più nodi, pudemu mitigà questu calculendu quorum è utilizendu un watchdog hardware (un mecanismu di dissociazione indiretta, cum'è discutitu prima). In u casu di dui nodi, duvemu aduprà unità di distribuzione di energia di rete (PDU).
Dopu un fallimentu, u sopravviventi prima prova à cuntattà u dispusitivu di dissociu primariu (iLO integratu o IPMI). Se questu hè successu, a ricuperazione cuntinueghja cum'è di solitu. Solu se u dispositivu iLO/IPMI falla hè accessu à a PDU; se l'accessu hè successu, a ricuperazione pò cuntinuà.
Assicuratevi di mette a PDU in una reta diversa da u trafficu di u cluster, altrimenti un fallimentu di a rete unicu bluccarà l'accessu à i dui dispositi di disassociazione è bluccà a risturazione di servizii.
Quì pudete dumandà - u PDU hè un puntu unicu di fallimentu? A quale a risposta hè, sicuru, hè.
Se stu risicu hè significativu per voi, ùn site micca solu: cunnetta i dui nodi à dui PDU è dite à u software di clustering per aduprà tramindui quandu accende è spegne i nodi. U cluster resta avà attivu se una PDU mori, è un secondu fallimentu di l'altru PDU o di u dispositivu IPMI serà necessariu per bluccà a ricuperazione.
Opzione 2 - Aghjunghjendu un Arbitru
In certi scenarii, mentri u metudu di dissociazione duplicata hè tecnicamente pussibule, hè puliticamente difficiule. Parechje cumpagnie piace à avè una certa separazione trà l'amministratori è i pruprietarii di l'applicazioni, è l'amministratori di rete cunzignati di a sicurità ùn sò micca sempre entusiasti di sparta i paràmetri di accessu PDU cù qualcunu.
In questu casu, l'alternativa cunsigliata hè di creà un terzu neutralu chì pò supplementà u calculu di quorum.
In l'eventu di un fallimentu, un node deve esse capace di vede l'onda di u so paru o l'arbitru per restaurà i servizii. L'arbitru include ancu una funzione di scollegamentu se i dui nodi ponu vede l'arbitru, ma ùn ponu micca vede.
Questa opzione deve esse aduprata in cungiunzione cù un metudu di dissociazione indiretta, cum'è un timer di watchdog di hardware, chì hè cunfiguratu per tumbà una macchina si perde a cunnessione cù u so peer and arbiter node. Cusì, un sopravviventi pò assume ragiunamente chì u so node peer serà in un statu sicuru dopu chì u timer di watchdog di hardware scade.
A diferenza pratica trà un arbitru è un terzu nodu hè chì un arbitru necessita assai menu risorse per operare è pò esse potenzialmente serve più di un cluster.
Opzione 3 - Fattore umanu
L'approcciu finale hè per i sopravviventi di cuntinuà à cuntinuà qualsiasi servizii chì eranu digià in esecuzione, ma ùn ne principianu micca novi finu à chì u prublema si risolve da sè stessu (ristabilisce a rete, reboot node) o una persona assume a rispunsabilità di cunfirmà manualmente chì l'altra parte hè morta.
Opzione bonus
Aghju dettu chì pudete aghjunghje un terzu node?
Dui rack
Per u scopu di l'argumentu, facemu finta chì l'aghju cunvinta di i meriti di u terzu node, avà avemu da cunsiderà l'arrangiamentu fisicu di i nodi. S'elli sò allughjati (è alimentati) in u stessu rack, questu custituisce ancu SPoF, è quellu chì ùn pò micca esse risoltu aghjunghjendu un secondu rack.
S'ellu hè stupente, cunsidereghja ciò chì succede se un rack cù dui nodi fallenu, è cumu u node sopravviventi distinguerà trà quellu è un fallimentu di a rete.
A risposta corta hè chì ùn hè micca pussibule, è dinò avemu trattatu di tutti i prublemi in u casu di dui nodi. O sopravviventi:
- ignora u quorum è tenta incorrectamente di inizià a ristaurazione durante l'interruzioni di a rete (a capacità di cumplettà a dissociazione hè una storia diversa è dipende se a PDU hè implicata è s'ellu si sparte u putere cù qualcunu di i rack), o
- respecte quorum et se déconnecte prématurément lorsque son noeud pair échoue
In ogni casu, dui racks ùn sò micca megliu cà unu, è i nodi devenu o riceve alimentazione indipendente o esse distribuiti in trè (o più, sicondu quanti nodi avete) racks.
Dui centri di dati
À questu puntu, i lettori chì ùn sò più avversi à u risicu puderanu cunsiderà a ricuperazione di disastru. Chì succede quandu un asteroide colpisce u stessu centru di dati cù i nostri trè nodi spargugliati in trè racks differenti? Ovviamente Cose Bad, ma sicondu i vostri bisogni, aghjunghje un secondu centru di dati pò esse micca abbastanza.
S'ellu hè fattu bè, u sicondu centru di dati vi furnisce (è raghjone cusì) cù una copia aghjurnata è coherente di i vostri servizii è i so dati. In ogni casu, cum'è in i scenarii di dui nodi, dui rack, ùn ci hè micca abbastanza infurmazione in u sistema per assicurà a massima dispunibilità è impedisce a corruzzione (o discrepanze di data set). Ancu cù trè nodi (o racks), a distribuzione di elli in solu dui centri di dati lascia u sistema incapace di piglià in modu affidabile a decisione ghjusta in casu d'un avvenimentu (ora assai più prubabile) chì e duie parti ùn ponu micca cumunicà.
Questu ùn significa micca chì una soluzione di centru di dati duale ùn hè mai adattatu. Cumpagnia spessu volenu una persona per esse cuscenti prima di piglià u passu straordinariu di passà à un centru di dati di salvezza. Basta à tene in mente chì se vulete automatizà l'interruzione, avete bisognu di un terzu centru di dati per u quorum per avè sensu (sia direttamente o attraversu un arbitru), o truverete un modu per chjude in modu affidabile tutti i dati. centru.
Source: www.habr.com