2013-04-30 7 views
6

Sono nuovo per i sistemi distribuiti e sto leggendo su "Simple Paxos". Crea un sacco di chiacchiere e sto pensando alle implicazioni sulle prestazioni.evitare l'uso eccessivo dei protocolli di consenso in un sistema distribuito

Supponiamo che stiate creando un database distribuito a livello globale, con numerosi cluster di piccole dimensioni ubicati in luoghi diversi. Sembra importante ridurre al minimo la quantità di comunicazioni tra siti.

  1. Quali sono le decisioni che è assolutamente necessario utilizzare per il consenso? L'unico che pensavo di sicuro stava decidendo se aggiungere o rimuovere un nodo (o un insieme di nodi?) Dalla rete. Sembra che questo sia necessario per il funzionamento degli orologi vettoriali. Un altro di cui ero meno sicuro era decidere un ordine per le scritture nello stesso luogo, ma questo dovrebbe essere fatto da un leader eletto tramite Paxos?

  2. Sarebbe bello evitare di avere tutti i nodi nel sistema che prendono le decisioni insieme. Alcuni nodi in ciascun cluster locale potrebbero prendere parte alle decisioni tra cluster e tutti i nodi locali comunicano utilizzando un Paxos locale per determinare le risposte locali alle domande sul sito? La latenza sarebbe la stessa supponendo che la rete non sia saturata, ma il traffico di rete tra siti sarebbe molto più leggero.

  3. Diciamo che è possibile dividere le tabelle del database di lungo filari, e assegnare ogni sottoinsieme di righe a un sottoinsieme di nodi. È normale scegliere un set di nodi per contenere ogni sottoinsieme dei dati utilizzando Paxos su tutte le macchine nel sistema, quindi eseguire solo Paxos tra quei nodi per tutte le operazioni che riguardano quel sottoinsieme di dati?

E un catch-all: ci sono altri legati al design o ottimizzazioni algoritmici persone stanno facendo per affrontare questo?

+0

Si può usare Zookeeper come servizio (molto simile a Google utilizza paffuto come un servizio) per gestire la coerenza di configurazione di base e metadati condivisi minime. Come suggerisci, può essere l'appartenenza al cluster o quali chiavi aziendali vengono elaborate su quale server in una federazione di server libera non è un cluster compatto. Vedere http://curator.apache.org/ per i modelli standard da cui è possibile creare una federazione più flessibile di elaborazione attorno a un servizio di coerenza/consistenza core altamente coerente. – simbo1905

risposta

6

Buone domande e buoni approfondimenti!

Crea un sacco di chiacchiere e sto pensando alle implicazioni sulle prestazioni.

Supponiamo che stiate creando un database distribuito a livello globale, con numerosi cluster di piccole dimensioni ubicati in luoghi diversi. Sembra importante ridurre al minimo la quantità di comunicazioni tra siti.

Quali sono le decisioni che è assolutamente necessario utilizzare per il consenso? L'unico che pensavo di sicuro stava decidendo se aggiungere o rimuovere un nodo (o un insieme di nodi?) Dalla rete. Sembra che questo sia necessario per il funzionamento degli orologi vettoriali. Un altro di cui ero meno sicuro era decidere un ordine per le scritture nello stesso luogo, ma questo dovrebbe essere fatto da un leader eletto tramite Paxos?

Sì, le prestazioni sono un problema che il mio team ha visto anche in pratica. Manteniamo un gestore di blocco distribuito con il database & coerente; e utilizzato in modo originale Paxos per tutte le scritture, alcune letture e aggiornamenti dei membri del cluster.

Ecco alcune delle ottimizzazioni che abbiamo fatto:

  • Per quanto possibile, i nodi inviato le transizioni ad un distinto Proponente/lingua straniera (eletto tramite Paxos), che
    • deciso su ordine di scrittura, e
    • transizioni batch in attesa della risposta dall'istanza precedente. (Ma dosaggio troppo anche causato problemi.)
  • Avevamo pensato di utilizzare multi-Paxos, ma abbiamo finito per fare qualcosa di più fresco (vedi sotto).

Con queste ottimizzazioni, siamo stati ancora male per le prestazioni, quindi abbiamo diviso il nostro server in tre strati. Lo strato inferiore è Paxos; fa quello che suggerisci; cioè. decide semplicemente l'appartenenza al nodo del livello intermedio. Lo strato intermedio è un protocollo di consenso della catena personalizzato in casa e ad alta velocità, che prevede il consenso & per il DB. (A proposito, il consenso sulla catena può essere visualizzato come Paxos verticale.) Il livello superiore ora mantiene solo le connessioni client/blocchi & del client. Questo design ha portato a diversi ordini di grandezza di latenza e miglioramento del throughput.


Sarebbe bello per evitare di avere tutti i nodi del sistema di prendere le decisioni insieme. Alcuni nodi in ciascun cluster locale potrebbero prendere parte alle decisioni tra cluster e tutti i nodi locali comunicano utilizzando un Paxos locale per determinare le risposte locali alle domande sul sito? La latenza sarebbe la stessa supponendo che la rete non sia saturata, ma il traffico di rete tra siti sarebbe molto più leggero.

Diciamo che è possibile dividere le tabelle del database di lungo filari, e assegnare ogni sottoinsieme di righe a un sottoinsieme di nodi. È normale scegliere un set di nodi per contenere ogni sottoinsieme dei dati utilizzando Paxos su tutte le macchine nel sistema, quindi eseguire solo Paxos tra quei nodi per tutte le operazioni che riguardano quel sottoinsieme di dati?

Questi due insieme mi ricordano lo Google Spanner paper. Se si saltano le parti sul tempo, essenzialmente sta facendo 2PC a livello globale e Paxos sui frammenti. (IIRC).

+0

Dolce, proprio quello che speravo di imparare! Anche la carta Spanner è un'ottima lettura. – Dan

+0

A proposito, ho difficoltà a trovare informazioni sui "protocolli di consenso della catena": hai un link? (Ho letto di Vertical Paxos, invece, ma non volevo perdere qualcosa per caso). – Dan