{"id":75726,"date":"2020-03-28T07:42:08","date_gmt":"2020-03-28T05:42:08","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/klaster-iz-dvuh-uzlov-dyavol-v-detalyah"},"modified":"2020-03-28T07:42:08","modified_gmt":"2020-03-28T05:42:08","slug":"klaster-iz-dvuh-uzlov-dyavol-v-detalyah","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/klaster-iz-dvuh-uzlov-dyavol-v-detalyah","title":{"rendered":"Cluster di due nodi \u2013 il diavolo \u00e8 nei dettagli","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Ciao, Habr! Vi presento la traduzione dell'articolo \u00abDue nodi \u2014 Il diavolo \u00e8 nei dettagli\u00bb<\/a><\/noindex> autore Andrew Beekhof.<\/p>\n

Molte persone preferiscono cluster composti da due nodi, perch\u00e9 sembrano concettualmente pi\u00f9 semplici e, inoltre, sono anche il 33% pi\u00f9 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\u00e0 un numero considerevole di problemi poco evidenti.
\n<\/a><\/noindex>
\nIl primo passo per la creazione di qualsiasi sistema ad alta disponibilit\u00e0 \u00e8 la ricerca e il tentativo di eliminare i singoli punti di guasto, spesso abbreviati come SPoF<\/i> (single point of failure).<\/p>\n

Va tenuto presente che in qualsiasi sistema non \u00e8 possibile eliminare tutti i rischi di inattivit\u00e0. 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\u00e0 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.<\/p>\n

Tenendo conto dei compromessi, non solo cerchiamo SPoF, ma bilanciamo anche i rischi e le conseguenze, con il risultato che ci\u00f2 che \u00e8 critico e ci\u00f2 che non lo \u00e8 pu\u00f2 variare per ogni distribuzione.<\/p>\n

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 \u00e8 esploso.<\/p><\/blockquote>\n

\nUn punto di partenza naturale \u00e8 avere pi\u00f9 di un nodo nel sistema. Tuttavia, prima che il sistema possa trasferire i servizi sul nodo sopravvissuto dopo un guasto, di norma \u00e8 necessario assicurarsi che i servizi da trasferire non siano attivi in un qualche altro luogo.<\/p>\n

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.<\/p>\n

Pertanto, per prevenire danni ai dati a causa del guasto di un nodo, ci affidiamo a ci\u00f2 che viene chiamato \u00abfencing\u00bb<\/i> (fencing).<\/p>\n

Il principio di fencing<\/h2>\n

\nAlla base del principio di fencing c'\u00e8 la domanda: un nodo concorrente pu\u00f2 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\u00f9 comune al fencing \u00e8 la disconnessione dei nodi difettosi.<\/p>\n

Ci sono due categorie di metodi di fencing che chiamer\u00f2 diretti<\/i> e indiretti<\/i>, ma altrettanto bene potrebbero essere chiamati attivi<\/i> e passivi<\/i>. 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\u00e9 riconosca in qualche modo di essere in uno stato di malattia (o, perlomeno, di ostacolare gli altri membri nel recupero) e segnali hardware watchdog<\/a><\/noindex> la necessit\u00e0 di disconnettere il nodo guasto.<\/p>\n

Il quorum aiuta nel caso di utilizzo sia di metodi diretti che indiretti.<\/p>\n

Fencing diretto<\/h3>\n

\nNel caso del fencing diretto, possiamo utilizzare il quorum per prevenire le condizioni di race fencing in caso di guasto della rete.<\/p>\n

Con il concetto di quorum, il sistema ha a disposizione informazioni sufficienti (anche senza la connessione ai propri partner) affinch\u00e9 i nodi sappiano automaticamente se devono avviare il fencing e\/o il recupero.<\/p>\n

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 \u00e8 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.<\/p>\n

Il problema con la separazione consiste nel fatto che i dispositivi pi\u00f9 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\u00ec che i nodi target credano che gli altri nodi siano offline.<\/p>\n

Sfortunatamente, le peculiarit\u00e0 del funzionamento dei dispositivi IPMI e iLo vengono raramente considerate al momento dell'acquisto dell'hardware.<\/p>\n

Separazione indiretta<\/h3>\n

\nIl quorum \u00e8 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.<\/p>\n

Con questa configurazione, il timer del hardware watchdog si resetta ogni N secondi, se il quorum non \u00e8 perso. Se il timer (di solito un multiplo di N) scade, il dispositivo esegue uno spegnimento non controllato (non shutdown).<\/p>\n

Questo approccio \u00e8 molto efficace, ma senza un quorum per gestirlo, non c'\u00e8 abbastanza informazione all'interno del cluster. Non \u00e8 facile determinare la differenza tra una disconnessione dalla rete e un guasto del nodo partner. La ragione per cui ci\u00f2 \u00e8 importante \u00e8 che senza la possibilit\u00e0 di distinguere tra i due casi si \u00e8 costretti a scegliere lo stesso comportamento in entrambi i casi.<\/p>\n

Il problema della scelta di un unico stato \u00e8 che non esiste un modo d'azione che massimizzi la disponibilit\u00e0 e prevenga la perdita di dati.<\/p>\n