Ciao, Habr! Ti presento la traduzione di un articolo autore Andrew Beekhof.
Molte persone preferiscono cluster composti da due nodi perché sembrano concettualmente più semplici e sono anche più economici del 33% rispetto ai loro omologhi a tre nodi. Sebbene sia possibile creare un buon cluster con due nodi, in molti casi, a causa di scenari non previsti, tale configurazione può generare molti problemi non evidenti.
Il primo passo per creare qualsiasi sistema ad alta disponibilità è identificare e tentare di eliminare i singoli punti di guasto, spesso abbreviati come SPoF (singolo punto di guasto).
Vale la pena ricordare che in qualsiasi sistema non è possibile rimuovere tutti i rischi di inattività. Questo deriva in parte dal fatto che la tipica protezione contro il rischio implica l'introduzione di una certa ridondanza, il che porta ad una maggiore complessità del sistema e all'emergere di nuovi punti di guasto. Pertanto, inizialmente facciamo un compromesso e ci concentriamo su eventi legati a singoli punti di guasto, piuttosto che su catene di eventi correlati e quindi sempre meno probabili.
Considerando i compromessi, non solo cerchiamo SPoF, ma bilanciamo anche rischi e conseguenze; 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. Sebbene la paranoia sia valsa a un cliente, il quale ha scoperto un trasformatore difettoso attraverso il monitoraggio. Il cliente ha chiamato per 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 spostare i servizi sul nodo sopravvissuto dopo un guasto, in generale, è necessario assicurarsi che i servizi da spostare non siano attivi altrove.
Un cluster a due nodi non ha svantaggi se entrambi i nodi servono lo stesso sito web statico in caso di guasto. Tuttavia, tutto cambia se entrambe le parti gestiscono in modo indipendente una coda di lavori condivisa o forniscono accesso non coordinato in scrittura a un database replicato o a un file system condiviso.
Pertanto, per prevenire la corruzione dei dati a seguito del guasto di un nodo, ci basiamo su ciò che si chiama «fencing» (recinzione).
Il principio di fencing
La base del principio di fencing ruota attorno alla domanda: un nodo concorrente può causare corruzione dei dati? Se la corruzione dei dati è uno scenario probabile, una buona soluzione sarebbe isolare il nodo sia dalle richieste in entrata che dall'archiviazione permanente. L'approccio più comune al fencing è disattivare i nodi guasti.
Ci sono due categorie di metodi di fencing che chiamerò diretti e indiretti, ma allo stesso modo possono essere chiamati attivi e passivi.I metodi diretti includono azioni da parte dei nodi sopravvissuti, come il dialogo con un dispositivo IPMI (Interfaccia di gestione della piattaforma intelligente) o iLO (Intelligent Lights Out), mentre i metodi indiretti fanno affidamento sul nodo guasto per riconoscere in qualche modo che si trova in uno stato problematico (o, almeno, ostacola gli altri membri nel riprendersi) e segnalare la necessità di disattivare il nodo guasto.
Il quorum aiuta nel caso si utilizzino metodi sia diretti che indiretti.
Fencing diretto
Nel caso del fencing diretto, possiamo utilizzare il quorum per prevenire le gare di fencing in una situazione di guasto di rete.
Con il concetto di quorum, nel sistema c'è sufficiente informazione (anche senza collegamento ai propri partner) affinché i nodi sappiano automaticamente se devono avviare il fencing e/o il ripristino.
Senza quorum, entrambe le parti di una divisione di rete presumono giustamente che l'altra parte sia morta e cercheranno di escludere l'altra. Nel peggiore dei casi, entrambe le parti riescono a disattivare l'intero cluster. Uno scenario alternativo è un deathmatch, un ciclo infinito di nodi che riappaiono, non vedendo i loro peer, riavviandoli e avviando il ripristino solo per riavviarsi quando il loro peer segue la stessa logica.
Il problema del fencing risiede nel fatto che i dispositivi più comunemente utilizzati diventano inaccessibili a causa degli stessi eventi di guasto su cui vogliamo fare affidamento per il recupero. La maggior parte delle schede IPMI e iLO sono installate su host che controllano e, per impostazione predefinita, utilizzano la stessa rete, il che fa sì che i nodi target pensino che gli altri nodi siano offline.
Sfortunatamente, le caratteristiche operative dei dispositivi IPMI e iLO vengono raramente considerate al momento dell'acquisto dell'hardware.
Fencing indiretto
Il quorum è anche importante per gestire i fencing indiretti; se tutto è fatto correttamente, il quorum può consentire ai nodi sopravvissuti di presumere che i nodi persi passeranno in uno stato sicuro dopo un certo periodo di tempo.
In questa configurazione, il timer del watchdog hardware viene ripristinato ogni N secondi, se il quorum non è perso. Se il timer (di solito multipli 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 distinguere tra un'interruzione di rete e un guasto di un nodo partner. Il motivo per cui questo è importante è che, senza la capacità di differenziare i due casi, si è costretti a selezionare lo stesso comportamento in entrambe le situazioni.
Il problema nella scelta di un unico modo di operare è che non esiste un'azione che massimizzi la disponibilità e prevenga la perdita di dati.
- Se si decide di presumere che il nodo partner sia attivo, ma in realtà è avvenuto un guasto, il cluster fermerà inutilmente i servizi che avrebbero dovuto funzionare per compensare la perdita dei servizi del nodo partner guasto.
- Se si decide di presumere che il nodo non funzioni, ma si trattava solo di un guasto di rete e in realtà il nodo remoto sta funzionando, allora, nel migliore dei casi, ci si sottoscrive a un futuro confronto manuale dei set di dati risultanti.
Qualunque sia l'euristica utilizzata, è banale creare un guasto che possa far funzionare entrambe le parti o costringere il cluster a spegnere i nodi sopravvissuti. Non utilizzare un quorum priva realmente il cluster di uno degli strumenti più potenti nel suo arsenale.
Se non ci sono alternative, il miglior approccio sarà sacrificare la disponibilità (qui l'autore si riferisce al teorema CAP). L'alta disponibilità di dati corrotti non aiuta nessuno, e il confronto manuale dei 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 nodi. Questo è impossibile in un cluster con due nodi dopo il guasto di un nodo.
Questo ci porta infine a un problema fondamentale con i cluster a due nodi:
il quorum non ha senso nei cluster con due nodi e, senza di esso, non è possibile determinare in modo affidabile il corso d'azione che massimizza la disponibilità e previene la perdita di dati.
Anche in un sistema a due nodi, collegati tramite un cavo incrociato, è impossibile fare una distinzione definitiva tra un'interruzione di rete e un guasto dell'altro nodo. L'interruzione di un'estremità (la cui probabilità è certamente proporzionale alla distanza tra i nodi) sarà sufficiente a smentire qualsiasi presunzione secondo cui la funzionalità del canale corrisponde 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 fencing duplicato
Il dispositivo iLO o IPMI di un nodo rappresenta un punto di guasto, poiché, in caso di guasto, i nodi sopravvissuti non possono usarlo per portare il nodo in uno stato sicuro. In un cluster di 3 o più nodi possiamo mitigare questo calcolando il quorum e utilizzando un watchdog hardware (meccanismo di fencing indiretto, come discusso in precedenza). Con due nodi, dobbiamo invece utilizzare unità di distribuzione di alimentazione (power distribution units o PDU).
Dopo un guasto, il nodo sopravvissuto tenta prima di contattare il dispositivo di fencing principale (iLO o IPMI integrato). Se ci riesce, il recupero continua come al solito. Solo in caso di guasto del dispositivo iLO / IPMI si contatta il PDU; se la richiesta ha esito positivo, il recupero può proseguire.
Assicurati di collegare il PDU a una rete diversa dal traffico del cluster; altrimenti, un singolo guasto della rete bloccherà l'accesso sia ai dispositivi isolati che rallenterà il ripristino dei servizi.
Qui puoi chiederti: il dispositivo PDU è un singolo punto di guasto? La risposta è sicuramente sì.
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. In questo modo, il cluster rimane attivo se uno dei PDU fallisce, e per bloccare il ripristino è necessario un secondo guasto, sia dell'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. Molte aziende preferiscono avere una chiara distinzione tra amministratori e proprietari delle applicazioni, e gli amministratori di rete attenti alla sicurezza non sono sempre entusiasti di concedere a chiunque l'accesso ai parametri del PDU.
In questo caso, l'alternativa raccomandata è creare una terza parte neutrale che possa integrare il calcolo del quorum.
In caso di guasto, un nodo deve essere in grado di vedere l'argomento del suo partner o arbitro per ripristinare i servizi. L'arbitro include anche una funzione di disconnessione, se entrambi i nodi possono vedere l'arbitro ma non vedono l'uno l'altro.
Questa opzione deve essere utilizzata insieme a un metodo di isolamento indiretto, come un timer di watchdog hardware, impostato per spegnere la macchina se perde la connessione con il suo nodo partner e l'arbitro. In questo modo, il nodo sopravvissuto può avere una ragionevole certezza che il suo nodo partner sarà in uno stato sicuro dopo che il timer di watchdog hardware è scaduto.
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'ultimo approccio consiste nel fatto che i nodi sopravvissuti continuano a fornire i servizi che già stavano eseguendo, ma non ne attivano di nuovi, fintanto che il problema non si risolve da solo (recupero della rete, riavvio del nodo) o una persona non 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 argomentare, supponiamo che ti abbia convinto dei vantaggi di un terzo nodo; ora dobbiamo considerare la posizione fisica dei nodi. Se sono collocati (e alimentati) nello stesso rack, ciò rappresenta anche un SPoF, che non può essere risolto semplicemente aggiungendo un secondo rack.
Se questo è sorprendente, pensa a cosa accadrebbe se il rack con i due nodi fallisse e come il nodo sopravvissuto differenzerebbe questo scenario da un guasto della rete.
In breve: è impossibile, e ci troviamo di nuovo di fronte a tutti i problemi legati ai due nodi. O il nodo sopravvissuto:
- ignora il quorum e tenta erroneamente di avviare un ripristino durante le interruzioni di rete (la possibilità di eseguire l'isolamento è un'altra storia e dipende dall'intervento del PDU e dalla condivisione dell'alimentazione con uno dei rack), oppure
- rispetta il quorum e si disconnette prematuramente quando il suo nodo partner fallisce.
In ogni caso, due rack non sono migliori di uno, e i nodi devono avere 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 che non sono più inclini al rischio potrebbero pensare al ripristino dopo un disastro. Cosa succede quando un asteroide colpisce uno dei nostri data center con tre nodi distribuiti su tre rack diversi? Ovviamente cose brutte, ma a seconda delle tue esigenze, aggiungere un secondo data center potrebbe non bastare.
Se tutto è fatto correttamente, il secondo data center ti fornisce (ed è ragionevole) una copia aggiornata e coerente dei tuoi servizi e dei loro dati. Tuttavia, così come negli scenari con due nodi e due rack, nel sistema ci sono informazioni insufficienti per garantire la massima disponibilità e prevenire danneggiamenti (o discrepanze nei set di dati). Anche con tre nodi (o rack), la loro distribuzione solo su due data center lascia il sistema incapace di prendere decisioni corrette in modo affidabile in caso di un evento (ora molto più probabile) che entrambe le parti non possono collegare.
Questo non significa che una soluzione con due data center non sia mai adatta. Le aziende vogliono spesso che una persona sia a conoscenza di ciò prima di intraprendere un passo eccezionale nel passaggio a un data center di backup. Tieni solo presente che se desideri automatizzare il guasto, avrai bisogno di un terzo data center affinché il quorum abbia senso (direttamente o tramite un arbitro), oppure troverai un modo per disattivare tutto il data center in modo affidabile.
Fonte: habr.com
