2009-07-09 11 views
14

Supponiamo di avere n processi, n> 2. Si desidera concordare tra loro che uno debba essere attivo. Quindi hanno bisogno di votarsi l'un l'altro per determinare quale è attivo.Evitare split-brain, voti e quorum

Tutti i processi possono fallire in qualsiasi momento, vogliamo avere un processo attivo, se possibile, ma ...

Abbiamo must mai avere due attivi allo stesso tempo, quindi se non possono essere certo è meglio non avere nessuno attivo. (Vale a dire vogliamo evitare la scissione del cervello)

L'unico meccanismo di comunicazione disponibile tra di loro è la messaggistica pub-sub (non punto a punto).

Uno o più database sono disponibili, ma nessun database dovrebbe essere un singolo punto di errore. Vale a dire. sarebbe molto poco interessante se tutti i processi fossero disponibili per funzionare e gli fosse impedito di farlo con la perdita di un singolo database.

Design? Quali messaggi devono essere pubblicati?

risposta

29

Teoria:

Si tratta di elezione leader, che è una forma di Consensus Problem, talvolta chiamato anche The Two Generals Problem. Sotto alcune serie di assunzioni (completamente asincrona e messaggi possono essere persi) è stato dimostrato impossibile, e la dimostrazione è particolarmente elegante.

L'intuizione di questo problema è: immagina che esista un algoritmo che consenta di raggiungere un consenso in un numero fisso di messaggi. Poiché i guasti sono tollerati, possiamo rilasciare un messaggio dal protocollo e dovrebbe comunque funzionare. Possiamo ripetere questo processo fino a quando non ci sono messaggi, chiaramente impossibile.

In pratica superiamo questo problema utilizzando i rilevatori di guasti per simulare un sistema sincrono.

L'algoritmo più noto che risolve il consenso è Paxos, che può tollerare il fallimento di metà dei nodi partecipanti. Paxos ha la reputazione di essere molto difficile da implementare in quanto anche i piccoli malintesi dei dettagli del protocollo ne distruggono la correttezza.

Soluzioni pratiche:

Mentre il problema in generale è abbastanza difficile, ottenendo sistemi che lavorano su è molto più facile. Esistono implementazioni off-line di Paxos o algoritmi equivalenti disponibili. Apache Zookeeper è il migliore di cui sono a conoscenza. Per il tuo problema specifico, sono abbastanza sicuro che sarà il tuo percorso più veloce. Altre implementazioni di Paxos sono in giro, e potrebbe anche essere possibile creare qualcosa su strumenti ip virtuali di ridondanza di rete come Wackamole. Credo che le versioni di fascia alta della maggior parte dei database commerciali offrano funzionalità di quorum come un'opzione (costosa).

Inoltre, per molte applicazioni è accettabile indebolire leggermente la correttezza o altrimenti regolare il problema per consentire soluzioni molto più semplici.

Ad esempio, se un singolo punto di errore è tollerabile perché è probabile che il ripristino sia rapido, il problema è banale: basta fare un lavoro con un nodo speciale.

Un altro approccio potrebbe essere quello di costruire il sistema attorno a azioni identi- ficative, in modo che l'elaborazione duplicata diventi tollerabile.

Infine, è possibile partizionare il carico di lavoro in un pool di sistemi non ridondanti: qui gli errori ritardano l'elaborazione fino al ripristino, ma solo per gli elementi su quel nodo, non per l'intero carico di lavoro.

Questi tipi di compromessi sono molto più semplici e spesso rappresentano una scelta migliore. Bisogna valutare l'utilità di una soluzione completa contro la complessità di implementarlo e vedere se c'è davvero un valore. Questo è il motivo per cui così tanti sistemi pratici usano solo 2 Phase o 3 Phase Commit, anche se bloccano in alcuni scenari: la disponibilità ridotta è tollerabile rispetto alla complessità di un sistema di quorum completo.

+1

Grazie per questa spiegazione dettagliata e i riferimenti. Concordo sul fatto che il rilassamento dei vincoli per consentire una soluzione più semplice sia una strada da esplorare. [Ora posso echeggiare l'epitaffio di Spike Milligan quando torno alla squadra "Vedi, ti ho detto che era difficile!"]. – djna

+0

Per chiarezza, Zookeeper implementa ZAB "Zookeeper Atomic Broadcast" che corrisponde a Paxos astratto ma differisce dai Paxos classici in modo tale che i messaggi mantengano l'ordine primario che è molto importante in molti scenari. – gertas

1

Non sono chiaro sulla messaggistica pub-sub.

Se stanno ottenendo una sorta di oggetti di lavoro da una fonte esterna e si desidera solo uno di essi per elaborare il lavoro, è possibile prendere uno spazio di valore hash, 2^64, dividere lo spazio per il numero di annoda ogni nodo prendendo un blocco. Ogni nodo può eseguire il hashing degli oggetti di lavoro mentre arrivano e determinare se è il loro.

+0

messaggistica pub-sb, il che implica che ogni membro può trasmettere informazioni ma non può essere sicuro che gli altri membri lo vedano. Ad ogni modo, la tua risposta è in realtà quella a cui avevamo pensato, e ci è davvero piaciuta. Lo svantaggio è che in realtà abbiamo solo 2 nodi, quindi in modalità degradata perdiamo metà del lavoro. – djna

0

Dai un'occhiata a come i protocolli di routing (OSPF e IS-IS) lo fanno, e vedi se questo funziona per te. Scelgono un leader (e nel caso OSPF, un leader di backup).

+0

È lo stesso processo elettorale che ci ha infastidito. Grazie per il suggerimento. Questo articolo http://routergod.com/sevenofnine/ospf_part_2.html descrive cosa sta succedendo, ma non fornisce molti dettagli. Il problema per me è come trattare con le comunità inaffidabili ed evitare la possibilità di split brain. – djna

+0

Questo collegamento spiega solo una breve panoramica. Dai un'occhiata ad alcuni documenti di Cisco o al libro "Routing TCP/IP". – Thomas

Problemi correlati