Migliorare ZooKeeper per aumentare la disponibilità

1

Eseguire Apache ZooKeeper (questo vale anche per il sistema in stile PAXOS) con 2 membri - il che non è raccomandato - non ha senso, perché se

  • membro1 scende
  • membro2 scende
  • c'è una partizione di rete tra member1 e member2

, ZooKeeper dichiarerà che l'orario di lavoro è finito, in quanto non esiste un singolo sottogruppo con una netta maggioranza di membri (in questo caso: > 1). Quindi eseguire ZooKeeper su 2 membri lo rende meno disponibile rispetto all'esecuzione di un singolo membro.

Perché il vincolo della maggioranza non può essere allentato in modo tale che quando c'è un sub cluster con esattamente il 50% dei membri, viene considerato il sottogruppo attivo se contiene il membro più anziano ? (Più vecchio appena prima della partizione, cioè quando il cluster era membro completo) Chi è il primogenito è l'informazione di cui ZooKeeper tiene traccia, quindi l'implementazione sembra facile.

In questo modo, non ci imbattiamo nel temuto scenario del cervello diviso e il cluster ZooKeeper potrebbe rimanere in alto in 2 dei 3 casi precedenti, migliorando la disponibilità, specialmente quando si eseguono solo 2 membri.

Qualcosa contro questo?

    
posta Eugen Dück 21.04.2014 - 05:15
fonte

2 risposte

2

L'intero punto di Zookeeper (come ho capito) è quello di rendere il riavvio DOPO che la partizione scompare semplicemente assicurandosi che ci sia solo UNA porzione (la maggior parte) che stava cambiando durante la partizione. Può quindi aumentare la velocità della minoranza quando si riconnettono e tutto viene eseguito di nuovo senza ulteriori interventi da parte dell'utente.

Se lasci correre due cluster di minoranza, allora zookeeper NON HA ALCUNA IDEA cosa fare quando si ricollegano. Se sei fortunato non ti ci vorrà troppo tempo per rimettere insieme il casino. Se non sei fortunato, alcuni cambiamenti incompatibili saranno avvenuti su entrambi i lati della partizione e farai i giorni a ripulire il casino.

Sospetto che se hai bisogno che le porzioni di minoranza di un cluster funzionino in modo indipendente, allora hai bisogno di una soluzione diversa da Zookeeper, o forse non vuoi affatto un cluster, forse vuoi un gruppo di sistemi che replicare avanti e indietro in qualche modo e solo sincronizzare i dati ogni volta che possono.

    
risposta data 21.04.2014 - 14:11
fonte
1

Mi è appena venuto in mente che sebbene lo scenario dei 2 membri potesse effettivamente essere reso più disponibile di quello che è adesso, non sarebbe ancora più disponibile rispetto allo scenario di 1 membro, e la scrittura è in effetti più lenta per 2 membri, perché ogni cambiamento deve essere propagato a un altro membro. Solo le letture di ZooKeeper miglioreranno sotto carico pesante (supponendo che i membri siano su macchine diverse), perché puoi leggere da una delle due macchine, piuttosto che da una sola.

Quindi questo cambiamento potrebbe ancora essere implementato, ma scegliere 2 membri su un solo membro passerebbe da una decisione senza compromessi a una : dover mantenere un altro processo, peggiorare le prestazioni di scrittura in generale, con una migliore leggi la scalabilità per il caso migliorato di 2 membri. Ciò non è necessariamente negativo, specialmente se ZooKeeper viene utilizzato per quello per cui è stato progettato: scenari con una percentuale schiacciante di legge .

E per rispondere alla domanda: Anche se aumenterebbe la disponibilità, aumenterebbe la disponibilità di 2 membri solo a quella del caso di 1 membro.

    
risposta data 23.04.2014 - 16:17
fonte

Leggi altre domande sui tag