Ciao, Habr! Vi presento la traduzione dell'articolo autore Andrew Beekhof.
Molte persone preferiscono cluster composti da due nodi, perché sembrano concettualmente più semplici e, inoltre, sono anche il 33% più economici dei loro omologhi a tre nodi. Sebbene sia possibile costruire un buon cluster con due nodi, nella maggior parte dei casi, a causa di scenari non considerati, tale configurazione creerà un numero considerevole di problemi poco evidenti.
Il primo passo per la creazione di qualsiasi sistema ad alta disponibilità è la ricerca e il tentativo di eliminare i singoli punti di guasto, spesso abbreviati come SPoF (single point of failure).
Va tenuto presente che in qualsiasi sistema non è possibile eliminare tutti i rischi di inattività. Questo deriva almeno dal fatto che la protezione tipica contro il rischio comporta l'introduzione di una certa ridondanza, il che porta a un aumento della complessità del sistema e alla creazione di nuovi punti di guasto. Pertanto, facciamo inizialmente un compromesso e ci concentriamo sugli eventi legati ai singoli punti di guasto, piuttosto che su catene di eventi correlati e, quindi, sempre meno probabili.
Tenendo conto dei compromessi, non solo cerchiamo SPoF, ma bilanciamo anche i rischi e le conseguenze, con il risultato che ciò che è critico e ciò che non lo è può variare per ogni distribuzione.
Non tutti hanno bisogno di fornitori alternativi di energia con linee elettriche indipendenti. Anche se la paranoia ha fruttato almeno per un cliente, quando il loro monitoraggio ha rilevato un trasformatore difettoso. Il cliente ha chiamato cercando di avvisare la compagnia elettrica, fino a quando il trasformatore difettoso non è esploso.
Un punto di partenza naturale è avere più di un nodo nel sistema. Tuttavia, prima che il sistema possa trasferire i servizi sul nodo sopravvissuto dopo un guasto, di norma è necessario assicurarsi che i servizi da trasferire non siano attivi in un qualche altro luogo.
Un cluster a due nodi non presenta svantaggi se, a seguito di un guasto, entrambi i nodi gestiscono lo stesso sito web statica. Tuttavia, tutto cambia se le due parti gestiscono indipendentemente una coda di compiti comune o forniscono accesso non coordinato alla scrittura a un database replicato o a un file system condiviso.
Pertanto, per prevenire danni ai dati a causa del guasto di un nodo, ci affidiamo a ciò che viene chiamato «fencing» (fencing).
Il principio di fencing
Alla base del principio di fencing c'è la domanda: un nodo concorrente può causare danni ai dati? Se i danni ai dati sono uno scenario probabile, una buona soluzione consiste nell'isolamento del nodo sia dalle richieste in entrata sia dallo storage persistente. L'approccio più comune al fencing è la disconnessione dei nodi difettosi.
Ci sono due categorie di metodi di fencing che chiamerò diretti e indiretti, ma altrettanto bene potrebbero essere chiamati attivi e passivi. I metodi diretti comprendono azioni da parte dei nodi peer sopravvissuti, come l'interazione con un dispositivo IPMI (Interfaccia di gestione della piattaforma intelligente) o iLO (sistema di gestione dei server in assenza di accesso fisico), mentre i metodi indiretti si basano sul nodo guasto affinché riconosca in qualche modo di essere in uno stato di malattia (o, perlomeno, di ostacolare gli altri membri nel recupero) e segnali la necessità di disconnettere il nodo guasto.
Il quorum aiuta nel caso di utilizzo sia di metodi diretti che indiretti.
Fencing diretto
Nel caso del fencing diretto, possiamo utilizzare il quorum per prevenire le condizioni di race fencing in caso di guasto della rete.
Con il concetto di quorum, il sistema ha a disposizione informazioni sufficienti (anche senza la connessione ai propri partner) affinché i nodi sappiano automaticamente se devono avviare il fencing e/o il recupero.
Senza quorum, entrambe le parti della divisione di rete presumono giustamente che l'altra parte sia morta e cercheranno di isolare l'altra. Nel peggiore dei casi, entrambe le parti riescono a disconnettere l'intero cluster. Uno scenario alternativo è il deathmatch, un ciclo infinito di nodi che appaiono, non vedono i loro peer, si riavviano e iniziano il recupero solo per riavviarsi quando il loro peer segue la stessa logica.
Il problema con la separazione consiste nel fatto che i dispositivi più frequentemente utilizzati diventano inaccessibili a causa degli stessi eventi di guasto su cui vogliamo orientarci 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 sì che i nodi target credano che gli altri nodi siano offline.
Sfortunatamente, le peculiarità del funzionamento dei dispositivi IPMI e iLo vengono raramente considerate al momento dell'acquisto dell'hardware.
Separazione indiretta
Il quorum è anche importante per la gestione delle separazioni indirette; se tutto viene fatto correttamente, un quorum permette ai nodi sopravvissuti di supporre che i nodi persi andranno in uno stato sicuro dopo un certo periodo di tempo.
Con questa configurazione, il timer del hardware watchdog si resetta ogni N secondi, se il quorum non è perso. Se il timer (di solito un multiplo di N) scade, il dispositivo esegue uno spegnimento non controllato (non shutdown).
Questo approccio è molto efficace, ma senza un quorum per gestirlo, non c'è abbastanza informazione all'interno del cluster. Non è facile determinare la differenza tra una disconnessione dalla rete e un guasto del nodo partner. La ragione per cui ciò è importante è che senza la possibilità di distinguere tra i due casi si è costretti a scegliere lo stesso comportamento in entrambi i casi.
Il problema della scelta di un unico stato è che non esiste un modo d'azione che massimizzi la disponibilità e prevenga la perdita di dati.
- Se decidi di supporre che il nodo partner sia attivo, ma in realtà è andato in guasto, il cluster fermerà eccessivamente i servizi che avrebbero dovuto funzionare per compensare la perdita dei servizi del nodo partner in panne.
- Se decidi di supporre che il nodo non funzioni, ma si trattava solo di un guasto della rete e il nodo remoto sta effettivamente funzionando, allora, nel migliore dei casi, ti stai iscrivendo a qualche futura verifica manuale dei set di dati risultanti.
Indipendentemente dall'euristica che utilizzi, è triviale creare un guasto che obblighi entrambe le parti a lavorare o che costringa il cluster a spegnere i nodi sopravvissuti. Non utilizzare un quorum priva davvero il cluster di uno degli strumenti più potenti nel suo arsenale.
Se non ci sono alternative, l'approccio migliore è sacrificare la disponibilità (qui l'autore si riferisce al teorema CAP). L'alta disponibilità dei dati danneggiati non aiuta nessuno, e verificare manualmente diversi set di dati non è affatto piacevole.
Quorum
Il quorum suona bene, vero?
L'unico svantaggio è che, per averlo in un cluster con N membri, è necessario che rimanga una connessione tra N / 2 + 1 dei tuoi nodi. Questo è impossibile in un cluster con due nodi dopo il guasto di uno di essi.
Questo ci porta infine al problema fondamentale con i due nodi:
il quorum non ha senso nei cluster a due nodi, e senza di esso non è possibile determinare con affidabilità il corso d'azione che massimizza la disponibilità e previene la perdita di dati
Anche in un sistema con due nodi collegati tramite cavo cross, è impossibile distinguere definitivamente tra un'interruzione di rete e il guasto di un altro nodo. L'interruzione di un'estremità (la cui probabilità è sicuramente proporzionale alla distanza tra i nodi) è sufficiente a mettere in discussione qualsiasi ipotesi sul fatto che la funzionalità del canale corrisponda alla salute del nodo partner.
Far funzionare un cluster di 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 decontinuazione duplicato
Il dispositivo iLO o IPMI del nodo rappresenta un punto di guasto, poiché, in caso di guasto, i nodi rimanenti non possono usarlo per mettere il nodo in uno stato sicuro. In un cluster con 3 o più nodi possiamo mitigare questo calcolando il quorum e utilizzando un hardware watchdog (meccanismo di decontinuazione indiretto, come discusso in precedenza). Nel caso di due nodi, dobbiamo invece utilizzare interruttori di rete (power distribution units o PDUs).
Dopo un guasto, il nodo sopravvissuto tenta prima di contattare il dispositivo di decontinuazione principale (iLO o IPMI integrato). Se ha successo, il ripristino continua normalmente. Solo in caso di guasto del dispositivo iLO / IPMI si ricorre al PDU; se la connessione ha successo, il ripristino può continuare.
Assicurati di collegare il PDU a una rete diversa da quella del traffico del cluster, altrimenti un singolo guasto di rete bloccherà l'accesso sia ai dispositivi di isolamento che il ripristino dei servizi.
Qui puoi chiederti: il dispositivo PDU non è un punto unico di guasto? La risposta è: certo che lo è.
Se questo rischio è significativo per te, non sei solo: collega entrambi i nodi a due PDU e istruisci il software del cluster ad utilizzare entrambi durante l'accensione e lo spegnimento dei nodi. Ora il cluster rimane attivo se un PDU muore, e per bloccare il recupero è necessario un secondo guasto, sia di un altro PDU che del dispositivo IPMI.
Opzione 2 - Aggiunta di un arbitro
In alcuni scenari, sebbene sia tecnicamente possibile un metodo di isolamento duplicato, è politicamente complicato. A molte aziende piace avere una certa separazione tra gli amministratori e i proprietari delle applicazioni, e gli amministratori di rete attenti alla sicurezza non sempre sono entusiasti di dare a chiunque altro i parametri di accesso al PDU.
In questo caso, l'alternativa raccomandata è creare una terza parte neutrale che possa integrare il calcolo del quorum.
In caso di guasto, il nodo deve avere la possibilità di vedere il suo partner o l'arbitro, per ripristinare i servizi. L'arbitro include anche la funzione di disconnessione, se entrambi i nodi possono vedere l'arbitro, ma non vedono l'un l'altro.
Questa opzione deve essere utilizzata in combinazione con un metodo di isolamento indiretto, come un timer hardware watchdog, che è impostato per spegnere la macchina se perde la connessione con il suo nodo partner e l'arbitro. In questo modo, il sopravvissuto può presumere con sufficiente sicurezza che il suo nodo partner sarà in uno stato sicuro dopo la scadenza del timer hardware watchdog.
La differenza pratica tra l'arbitro e il terzo nodo è che l'arbitro richiede molte meno risorse per funzionare e, potenzialmente, può servire più di un cluster.
Opzione 3 - Fattore umano
L'ultima approccio consiste nel far sì che i sopravvissuti continuino a svolgere qualsiasi funzione che abbiano già eseguito, ma senza avviarne di nuove finché il problema non si risolve da solo (ripristino della rete, riavvio del nodo) o finché qualcuno non si assume la responsabilità di confermare manualmente che l'altra parte è morta.
Opzione bonus
Ti ho già detto che puoi aggiungere un terzo nodo?
Due rack
Per il bene dell'argomento, immaginiamo che ti abbia convinto dei vantaggi di un terzo nodo, ora dobbiamo considerare la disposizione fisica dei nodi. Se sono collocati (e alimentati) nello stesso rack, questo rappresenta anche un SPoF, e uno che non può essere risolto semplicemente aggiungendo un secondo rack.
Se questo è sorprendente, pensa a cosa accadrebbe se il rack con due nodi si guastasse, e come il nodo sopravvissuto differirebbe in questo caso rispetto a un guasto della rete.
La risposta breve: è impossibile, e ci troviamo di nuovo ad affrontare tutti i problemi legati a due nodi. O il sopravvissuto:
- ignora il quorum e cerca erroneamente di avviare il ripristino durante i guasti di rete (la possibilità di completare la separazione è una storia a parte e dipende dal fatto che il PDU sia coinvolto e da se condividono l'alimentazione con uno dei rack), oppure
- rispetta il quorum e si scollega prematuramente quando il suo nodo partner fallisce.
In ogni caso, due rack non sono meglio di uno, e i nodi devono ricevere fonti di alimentazione indipendenti o essere distribuiti su tre (o più, a seconda di quanti nodi hai) rack.
Due data center
A questo punto, i lettori meno inclini al rischio potrebbero pensare al ripristino dopo un disastro. Cosa succede quando un asteroide colpisce un centro dati con i nostri tre nodi distribuiti su tre rack diversi? Ovviamente, brutte cose, ma a seconda delle tue esigenze, l'aggiunta di un secondo data center potrebbe non essere sufficiente.
Se tutto è fatto correttamente, il secondo data center fornisce a voi (e questo è ragionevole) una copia attuale e coerente dei vostri servizi e dei loro dati. Tuttavia, come nei casi con due nodi e due rack, nel sistema ci sono informazioni insufficienti per garantire la massima disponibilità e prevenire danni (o discrepanze nei set di dati). Anche con tre nodi (o rack), la loro distribuzione solo in due data center lascia il sistema incapace di prendere decisioni corrette in modo affidabile di fronte a un evento (ora molto più probabile) che entrambe le parti non possono connettere.
Ciò non significa che una soluzione con due data center non sia mai adatta. Spesso, le aziende desiderano essere informate prima di intraprendere un'azione eccezionale nel passaggio a un data center di backup. Tieni solo presente che se desideri automatizzare un guasto, avrai bisogno di un terzo data center affinché il quorum sia significativo (direttamente o tramite un arbitro), oppure troverai un modo per disattivare in modo affidabile l'intero data center.
Fonte: habr.com
