{"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! Ti presento la traduzione di un 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 sono anche pi\u00f9 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\u00f2 generare molti problemi non evidenti.
\n<\/a><\/noindex>
\nIl primo passo per creare qualsiasi sistema ad alta disponibilit\u00e0 \u00e8 identificare e tentare di eliminare i singoli punti di guasto, spesso abbreviati come SPoF<\/i> (singolo punto di guasto).<\/p>\n

Vale la pena ricordare che in qualsiasi sistema non \u00e8 possibile rimuovere tutti i rischi di inattivit\u00e0. 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\u00e0 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.<\/p>\n

Considerando i compromessi, non solo cerchiamo SPoF, ma bilanciamo anche rischi e conseguenze; il risultato \u00e8 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. 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 \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 spostare i servizi sul nodo sopravvissuto dopo un guasto, in generale, \u00e8 necessario assicurarsi che i servizi da spostare non siano attivi altrove.<\/p>\n

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

Pertanto, per prevenire la corruzione dei dati a seguito del guasto di un nodo, ci basiamo su ci\u00f2 che si chiama \u00abfencing\u00bb<\/i> (recinzione).<\/p>\n

Il principio di fencing<\/h2>\n

\nLa base del principio di fencing ruota attorno alla domanda: un nodo concorrente pu\u00f2 causare corruzione dei dati? Se la corruzione dei dati \u00e8 uno scenario probabile, una buona soluzione sarebbe isolare il nodo sia dalle richieste in entrata che dall'archiviazione permanente. L'approccio pi\u00f9 comune al fencing \u00e8 disattivare i nodi guasti.<\/p>\n

Ci sono due categorie di metodi di fencing che chiamer\u00f2 diretti<\/i> e indiretti<\/i>, ma allo stesso modo possono essere chiamati attivi<\/i> e passivi.<\/i>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 hardware watchdog<\/a><\/noindex> la necessit\u00e0 di disattivare il nodo guasto.<\/p>\n

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

Fencing diretto<\/h3>\n

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

Con il concetto di quorum, nel sistema c'\u00e8 sufficiente informazione (anche senza collegamento ai propri partner) affinch\u00e9 i nodi sappiano automaticamente se devono avviare il fencing e\/o il ripristino.<\/p>\n

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

Il problema del fencing risiede nel fatto che i dispositivi pi\u00f9 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\u00ec che i nodi target pensino che gli altri nodi siano offline.<\/p>\n

Sfortunatamente, le caratteristiche operative dei dispositivi IPMI e iLO vengono raramente considerate al momento dell'acquisto dell'hardware.<\/p>\n

Fencing indiretto<\/h3>\n

\nIl quorum \u00e8 anche importante per gestire i fencing indiretti; se tutto \u00e8 fatto correttamente, il quorum pu\u00f2 consentire ai nodi sopravvissuti di presumere che i nodi persi passeranno in uno stato sicuro dopo un certo periodo di tempo.<\/p>\n

In questa configurazione, il timer del watchdog hardware viene ripristinato ogni N secondi, se il quorum non \u00e8 perso. Se il timer (di solito multipli 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 distinguere tra un'interruzione di rete e un guasto di un nodo partner. Il motivo per cui questo \u00e8 importante \u00e8 che, senza la capacit\u00e0 di differenziare i due casi, si \u00e8 costretti a selezionare lo stesso comportamento in entrambe le situazioni.<\/p>\n

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