2014-06-05 12 views
5

Ho impostato il valore net_ticktime su 600 secondi.Come funziona il rilevamento dei nodi terminati in Erlang? In che modo net_ticktime influenza il controllo della vividezza dei nodi in Erlang?

net_kernel:set_net_ticktime(600) 

Nella documentazione Erlang per net_ticktime = TickTime:

Specifica il net_kernel spuntare tempo. TickTime è dato in secondi. Una volta ogni TickTime/4 secondo, tutti i nodi connessi sono spuntati (se qualcos'altro è stato scritto su un nodo) e se non è stato ricevuto nulla da un altro nodo negli ultimi quattro (4) volte in cui il nodo è considerato inattivo. Questo assicura che i nodi che non rispondono, per motivi come errori hardware, siano considerati inattivi.

Il tempo T, in cui viene rilevato un nodo che non risponde:

MinT < T < MaxT where: 

MinT = TickTime - TickTime/4 
MaxT = TickTime + TickTime/4 

TickTime è di default (60 secondi). Quindi, 45 < T < 75 secondi.

Nota: in genere, un nodo di terminazione viene rilevato immediatamente.

mio problema: mio TickTime è di 600 (secondi). Quindi, 450 (7,5 minuti) < T < 750 secondi (12,5 minuti). Sebbene, quando imposto net_ticktime su tutti i nodi distribuiti in Erlang su 600 se qualche nodo fallisce (ad esempio quando chiudo la shell di Erlang), gli altri nodi ricevono immediatamente il messaggio e non secondo la definizione di ticktime.

Tuttavia si nota che normalmente un nodo di terminazione viene rilevato immediatamente, ma non riuscivo a trovare una spiegazione (né nella documentazione Erlang, o Erlang ebook o altre fonti basate Erlang) di questo principio la risposta immediata per la terminazione nodo distribuito Erlang. I nodi in ambiente distribuito sono sottoposti a ping periodicamente con intervalli più piccoli rispetto a net_ticktime oppure il nodo di terminazione invia qualche tipo di messaggio ad altri nodi prima che termini? Se invia un messaggio ci sono degli scenari in cui il nodo di terminazione non può inviare questo messaggio e deve essere inviato al ping per indagare sulla sua vivacità?

Inoltre, nella documentazione di Erlang si nota che Distributed Erlang non è molto scalabile per cluster di oltre 100 nodi poiché ogni nodo mantiene collegamenti a tutti i nodi del cluster. L'algoritmo per investigare la vivacità dei nodi (ping, annunciando la terminazione) è stato modificato con l'aumentare delle dimensioni del cluster?

+0

Una domanda chiave: i tuoi nodi fanno una comunicazione propria tra tick (transazioni rpc, mnesia, ecc.)? In tal caso, sarebbe possibile (e in effetti molto probabile) che la VM rilevi un nodo abbattuto prima del tick. –

+0

Ho testato il problema per due situazioni: 1.Ho provato a collegare solo shell Erlang remote su due VM con cmd 'net_adm: ping(),' e dopo aver chiuso la shell cmd 'nodes()' ha riconosciuto immediatamente che il nodo è inattivo e ha restituito '[]' ma non c'era comunicazione tra le zecche. 2.) Ho provato questo problema nella mia app Riak. dove ho ucciso il nodo che esegue l'app. e poi periodicamente inviato comandi ad altri nodi per le loro informazioni sul nodo ucciso. Dopo il timer ': sleep (10)' i nodi attivi continuano a elencare il nodo ucciso come vivo, ma dopo il timer ': sleep (100)' nodo morto è stato contrassegnato come inattivo ma 100 ms <600 s. – Zuzana

risposta

3

Quando due nodi Erlang si connettono, viene stabilita una connessione TCP tra di loro. L'insuccesso che si sta inducendo causerebbe il blocco del sistema operativo sottostante, notificando in modo efficace l'altro nodo molto rapidamente.

Il segno di spunta della rete viene utilizzato per rilevare una connessione a un nodo distante che sembra essere attivo ma non sta effettivamente passando il traffico, come può accadere quando un evento di rete isola un nodo.

Se si desidera simulare un errore che richiederebbe un segno di spunta da rilevare, utilizzare un firewall per bloccare il traffico sulla connessione creata quando i nodi eseguono il primo ping.

+1

Recentemente ho letto questo articolo del blog che descrive cosa fare in modo un po 'più dettagliato, tuttavia non l'ho ancora provato da solo: http://djui.io/2011/03/18/simulating-net-splits -in-erlang/ – Alexander

+0

Grazie mille per le vostre risposte, questo è esattamente quello che dovevo sapere, l'articolo fornito da Alexander è il riassunto perfetto delle possibili simulazioni di scenari di fallimento. – Zuzana