Ehi Habr! Presento alla vostra attenzione la traduzione dell'articolo di Andrew Beekhof.
Molte persone preferiscono i cluster a due nodi perché sembrano concettualmente più semplici e sono anche più economici del 33% rispetto alle loro controparti a tre nodi. Sebbene sia del tutto possibile mettere insieme un buon cluster di due nodi, nella maggior parte dei casi, a causa di scenari non considerati, tale configurazione creerà molti problemi non ovvi.
Il primo passo per creare qualsiasi sistema ad alta disponibilità è trovare e tentare di eliminare i singoli punti di errore, spesso abbreviati come SPof (singolo punto di guasto).
Vale la pena tenere presente che è impossibile eliminare tutti i possibili rischi di tempi di inattività in qualsiasi sistema. Ciò deriva dal fatto che una tipica difesa contro il rischio consiste nell’introdurre una certa ridondanza, che porta ad una maggiore complessità del sistema e all’emergere di nuovi punti di guasto. Pertanto inizialmente raggiungiamo un compromesso e ci concentriamo sugli eventi associati ai singoli punti di guasto e non su catene di eventi correlati e, quindi, sempre meno probabili.
Considerati i compromessi, non solo cerchiamo SPoF, ma bilanciamo anche i rischi e le conseguenze, per cui la conclusione su ciò che è critico e ciò che non lo è può differire per ciascuna implementazione.
Non tutti hanno bisogno di fornitori di energia elettrica alternativi con linee elettriche indipendenti. Anche se la paranoia ha dato i suoi frutti ad almeno un cliente quando il loro monitoraggio ha rilevato un trasformatore difettoso. Il cliente ha telefonato cercando di allertare la compagnia elettrica finché il trasformatore difettoso non è esploso.
Un punto di partenza naturale è avere più di un nodo nel sistema. Tuttavia, prima che il sistema possa spostare i servizi sul nodo sopravvissuto dopo un guasto, generalmente deve assicurarsi che i servizi spostati non siano attivi altrove.
Non vi è alcun aspetto negativo in un cluster a due nodi se un errore fa sì che entrambi i nodi servano lo stesso sito Web statico. Tuttavia, le cose cambiano se il risultato è che entrambe le parti gestiscono in modo indipendente una coda di lavoro condivisa o forniscono accesso in scrittura non coordinato a un database replicato o a un file system condiviso.
Pertanto, per prevenire la corruzione dei dati a causa del guasto di un singolo nodo, ci affidiamo a qualcosa chiamato "dissociazione" (scherma).
Il principio di dissociazione
Al centro del principio di dissociazione c’è la domanda: un nodo concorrente può causare la corruzione dei dati? Nel caso in cui la corruzione dei dati sia uno scenario probabile, una buona soluzione sarebbe quella di isolare il nodo sia dalle richieste in entrata che dall'archiviazione persistente. L'approccio più comune alla dissociazione è disconnettere i nodi difettosi.
Esistono due categorie di metodi di dissociazione, che chiamerò diretto и indiretto, ma possono essere ugualmente chiamati attivo и passivo. I metodi diretti includono azioni da parte dei peer sopravvissuti, come l'interazione con un dispositivo IPMI (Intelligent Platform Management Interface) o iLO (un meccanismo per la gestione dei server in assenza di accesso fisico ad essi), mentre i metodi indiretti si basano sul fallimento nodo per riconoscere in qualche modo che è in uno stato non sano (o almeno impedire ad altri membri di riprendersi) e segnalare sulla necessità di disconnettere il nodo guasto.
Il quorum aiuta quando si utilizzano metodi sia diretti che indiretti.
Dissociazione diretta
In caso di dissociazione diretta, possiamo utilizzare il quorum per evitare gare di dissociazione in caso di guasto della rete.
Con il concetto di quorum, nel sistema ci sono informazioni sufficienti (anche senza connettersi ai suoi pari) affinché i nodi sappiano automaticamente se devono avviare la dissociazione e/o il ripristino.
Senza un quorum, entrambe le parti di una rete di divisione presupporranno giustamente che l’altra parte sia morta e cercheranno di dissociare l’altra. Nel peggiore dei casi, entrambe le parti riescono a spegnere l’intero cluster. Uno scenario alternativo è un deathmatch, un ciclo infinito di nodi che si generano, non vedono i loro peer, li riavviano e avviano il ripristino solo per riavviarsi quando il loro peer segue la stessa logica.
Il problema con la dissociazione è che i dispositivi più comunemente utilizzati diventano non disponibili a causa degli stessi eventi di guasto che vogliamo prendere di mira per il ripristino. La maggior parte delle schede IPMI e iLO sono installate sugli host che controllano e, per impostazione predefinita, utilizzano la stessa rete, il che fa credere agli host di destinazione che gli altri host siano offline.
Sfortunatamente, le caratteristiche operative dei dispositivi IPMI e iLo vengono raramente prese in considerazione al momento dell'acquisto dell'apparecchiatura.
Dissociazione indiretta
Il quorum è importante anche per gestire la dissociazione indiretta; se eseguito correttamente, il quorum può consentire ai sopravvissuti di presumere che i nodi persi passeranno a uno stato sicuro dopo un certo periodo di tempo.
Con questa configurazione, il timer del watchdog hardware viene reimpostato ogni N secondi se il quorum non viene perso. Se il timer (solitamente diversi multipli di N) scade, il dispositivo esegue uno spegnimento imprevisto (non uno spegnimento).
Questo approccio è molto efficace, ma senza un quorum non ci sono abbastanza informazioni all'interno del cluster per gestirlo. Non è facile distinguere tra un'interruzione della rete e un guasto del nodo peer. Il motivo per cui ciò è importante è che senza la capacità di distinguere tra i due casi, sei costretto a scegliere lo stesso comportamento in entrambi i casi.
Il problema con la scelta di una modalità è che non esiste una linea d'azione che massimizzi la disponibilità e prevenga la perdita di dati.
- Se si sceglie di presupporre che un nodo peer sia attivo ma in realtà fallisce, il cluster interromperà inutilmente i servizi che sarebbero in esecuzione per compensare la perdita di servizi dal nodo peer in errore.
- Se decidi di presupporre che un nodo è inattivo, ma si è trattato solo di un guasto della rete e in effetti il nodo remoto è funzionante, nella migliore delle ipotesi ti stai iscrivendo a una futura riconciliazione manuale dei set di dati risultanti.
Indipendentemente dall'euristica utilizzata, è banale creare un errore che causerà il fallimento di entrambi i lati o causerà la chiusura dei nodi sopravvissuti del cluster. Il mancato utilizzo del quorum priva effettivamente il cluster di uno degli strumenti più potenti del suo arsenale.
Se non esiste altra alternativa, l’approccio migliore è sacrificare la disponibilità (qui l’autore fa riferimento al teorema della PAC). L'elevata disponibilità di dati danneggiati non aiuta nessuno e nemmeno la riconciliazione manuale di diversi set di dati è divertente.
Quorum
Il quorum sembra fantastico, vero?
L'unico svantaggio è che per averlo in un cluster con N membri, è necessario avere una connessione tra N/2+1 dei nodi rimanenti. Ciò non è possibile in un cluster a due nodi dopo che un nodo si guasta.
Il che alla fine ci porta al problema fondamentale con due nodi:
Il quorum non ha senso nei cluster a due nodi e senza di esso è impossibile determinare in modo affidabile la linea di condotta che massimizza la disponibilità e previene la perdita di dati
Anche in un sistema di due nodi collegati da un cavo incrociato, è impossibile distinguere in modo definitivo tra un'interruzione della rete e un guasto dell'altro nodo. Disabilitare un'estremità (la cui probabilità è, ovviamente, proporzionale alla distanza tra i nodi) sarà sufficiente per invalidare qualsiasi ipotesi secondo cui la salute del collegamento è uguale alla salute del nodo partner.
Far funzionare un cluster a due nodi
A volte il cliente non può o non vuole acquistare un terzo nodo e siamo costretti a cercare un'alternativa.
Opzione 1 - Metodo di dissociazione duplicato
Il dispositivo iLO o IPMI di un nodo rappresenta un punto di guasto perché, in caso di guasto, i sopravvissuti non possono utilizzarlo per portare il nodo in uno stato sicuro. In un cluster di 3 o più nodi, possiamo mitigare questo problema calcolando il quorum e utilizzando un watchdog hardware (un meccanismo di dissociazione indiretto, come discusso in precedenza). Nel caso di due nodi, dobbiamo invece utilizzare le unità di distribuzione dell'alimentazione di rete (PDU).
Dopo un fallimento, il sopravvissuto tenta innanzitutto di contattare il dispositivo di dissociazione primario (iLO o IPMI incorporato). Se l'operazione ha esito positivo, il ripristino continua normalmente. Solo se il dispositivo iLO/IPMI si guasta è possibile accedere alla PDU; se l'accesso ha esito positivo, il ripristino può continuare.
Assicurarsi di posizionare la PDU su una rete diversa da quella del traffico del cluster, altrimenti un singolo errore di rete bloccherà l'accesso a entrambi i dispositivi di dissociazione e bloccherà il ripristino dei servizi.
Qui potresti chiedere: la PDU è un singolo punto di guasto? La risposta è: ovviamente lo è.
Se questo rischio è significativo per te, non sei solo: collega entrambi i nodi a due PDU e comunica al software di clustering di utilizzarli entrambi quando accendi e spegni i nodi. Il cluster ora rimane attivo se una PDU muore e sarà necessario un secondo guasto dell'altra PDU o del dispositivo IPMI per bloccare il ripristino.
Opzione 2 - Aggiunta di un arbitro
In alcuni scenari, sebbene il metodo della dissociazione duplicata sia tecnicamente possibile, è politicamente difficile. Molte aziende preferiscono avere una certa separazione tra amministratori e proprietari delle applicazioni, e gli amministratori di rete attenti alla sicurezza non sono sempre entusiasti di condividere le impostazioni di accesso alla PDU con chiunque.
In questo caso, l’alternativa consigliata è quella di creare una terza parte neutrale che possa integrare il calcolo del quorum.
In caso di guasto, un nodo deve essere in grado di vedere le onde radio del suo pari o arbitro per ripristinare i servizi. L'arbitro include anche una funzione di disconnessione se entrambi i nodi possono vedere l'arbitro ma non possono vedersi a vicenda.
Questa opzione deve essere utilizzata insieme a un metodo di dissociazione indiretto, come un timer di watchdog hardware, che è configurato per uccidere una macchina se perde la connessione al suo nodo peer e arbitro. Pertanto, un sopravvissuto può ragionevolmente presumere che il suo nodo peer sarà in uno stato sicuro dopo la scadenza del timer di watchdog dell'hardware.
La differenza pratica tra un arbitro e un terzo nodo è che un arbitro richiede molte meno risorse per funzionare e può potenzialmente servire più di un cluster.
Opzione 3 – Fattore umano
L'approccio finale prevede che i sopravvissuti continuino a eseguire i servizi che stavano già eseguendo, ma non ne inizino di nuovi finché il problema non si risolve da solo (ripristino della rete, riavvio del nodo) o una persona si assume la responsabilità di confermare manualmente che l'altra parte è morta.
Opzione bonus
Ho già detto che puoi aggiungere un terzo nodo?
Due rack
Per amor di discussione, facciamo finta di averti convinto dei meriti del terzo nodo, ora dobbiamo considerare la disposizione fisica dei nodi. Se sono alloggiati (e alimentati) nello stesso rack, anche questo costituisce SPoF e non può essere risolto aggiungendo un secondo rack.
Se ciò è sorprendente, si consideri cosa accadrebbe se un rack con due nodi si guastasse e in che modo il nodo sopravvissuto distinguerebbe tra questo e un guasto della rete.
La risposta breve è che non è possibile, e anche in questo caso abbiamo a che fare con tutti i problemi del caso a due nodi. O sopravvissuto:
- ignora il quorum e tenta erroneamente di avviare il ripristino durante le interruzioni della rete (la capacità di completare la dissociazione è una storia diversa e dipende dal fatto che sia coinvolta la PDU e se condivida l'alimentazione con uno qualsiasi dei rack), oppure
- rispetta il quorum e si disconnette prematuramente quando il suo nodo peer fallisce
In ogni caso, due rack non sono meglio di uno e i nodi devono ricevere alimentatori indipendenti o essere distribuiti su tre (o più, a seconda di quanti nodi si hanno) rack.
Due data center
A questo punto, i lettori che non sono più avversi al rischio potrebbero prendere in considerazione il ripristino di emergenza. Cosa succede quando un asteroide colpisce lo stesso data center con i nostri tre nodi distribuiti su tre rack diversi? Ovviamente brutte cose, ma a seconda delle tue esigenze, aggiungere un secondo data center potrebbe non essere sufficiente.
Se eseguito correttamente, il secondo data center ti fornisce (e ragionevolmente) una copia aggiornata e coerente dei tuoi servizi e dei relativi dati. Tuttavia, come negli scenari a due nodi e due rack, nel sistema non ci sono informazioni sufficienti per garantire la massima disponibilità e prevenire danneggiamenti (o discrepanze nei set di dati). Anche con tre nodi (o rack), la loro distribuzione su soli due data center impedisce al sistema di prendere in modo affidabile la decisione giusta nel caso di un evento (ora molto più probabile) che entrambe le parti non riescono a comunicare.
Ciò non significa che una soluzione con doppio data center non sia mai adatta. Le aziende spesso vogliono che una persona sia informata prima di compiere il passo straordinario di trasferirsi in un data center di backup. Tieni presente che se desideri automatizzare l'interruzione, avrai bisogno di un terzo data center affinché il quorum abbia senso (direttamente o tramite un arbitro) oppure troverai un modo per chiudere in modo affidabile tutti i dati centro.
Fonte: habr.com