Quanto è scalabile la distribuzione di Erlang?

Question

Parte A:

Erlang ha un sacco di storie di successo su come eseguire gli agenti simultanei per esempio i milioni di chat simultanee di Facebook. Sono milioni di agenti, ma ovviamente non sono milioni di CPU su una rete. Sto riscontrando problemi nel trovare le metriche su quanto bene Erlang scala quando il ridimensionamento è "orizzontale" su una LAN/WAN.

Supponiamo di avere molti (decine di migliaia) nodi fisici (che eseguono Erlang su Linux) che devono comunicare e sincronizzare piccole quantità infrequenti di dati attraverso la LAN/WAN. A che punto avrò dei colli di bottiglia nelle comunicazioni, non tra agenti, ma tra nodi fisici? (O sarà presente solo lavoro, assumendo una rete stabile?)

Parte B:

ho capito (come un newbie Erlang, nel senso che potrebbe essere del tutto sbagliato) che Erlang nodi tentativo di tutta connettersi e essere consapevoli l'uno dell'altro, risultando in una rete punto-punto di connessione N^2. Supponendo che la parte A non funzioni solo con N = 10K, può essere facilmente configurata con Erlang (usando configurazione predefinita o semplice schema, non scrivendo da sola un'implementazione completa di algoritmi di raggruppamento/instradamento) per raggruppare i nodi in gestibile raggruppa e instrada i messaggi a livello di sistema attraverso la gerarchia cluster/gruppo?

Answer 1

Dobbiamo specificare che parliamo di scalabilità orizzontale delle macchine fisiche: questo è l'unico problema. Le CPU su una macchina saranno gestite da una VM, indipendentemente dal numero di esse.

nodo = macchina.

Per iniziare, posso dire che 30-60 nodi si ottiene fuori dalla scatola (installazione OTP vaniglia) con qualsiasi applicazione personalizzata scritta in cima a quella (in Erlang). Prova: ejabberd.

~ 100-150 è possibile con l'applicazione personalizzata ottimizzata. Voglio dire, deve essere un buon codice, scritto con conoscenza su GC, caratteristiche dei tipi di dati, messaggio che passa ecc.

oltre +150 va bene ma quando parliamo di numeri come 300, 500 richiederà ottimizzazioni & personalizzazioni del livello TCP. Inoltre, la nostra app deve essere a conoscenza del costo di es. sincronizzare le chiamate attraverso il cluster.

L'altra cosa è il livello DB. Mnesia (built-in) per le sue caratteristiche non sarà più efficace di 20 nodi (la mia esperienza - potrei sbagliarmi). Soluzione: basta usare qualcos'altro: dynamo DB, cluster separato di MySQL, HBase, ecc.

La tecnica più comune per sfruttare i costi di creazione di applicazioni e scalabilità di alta qualità sono le federazioni di cluster di 20-50 nodi. Quindi internamente è una mesh efficiente di ~ 50 nodi di erlang ed è connessa tramite qualsiasi protocollo adatto con N altri cluster di 50 nodi. Riassumendo, un tale sistema è la federazione di cluster N elang.

L'erlang distribuito è progettato per essere eseguito in un centro dati. Se hai bisogno di più nodi geograficamente distanti, usa le federazioni.

Ci sono molte opzioni di configurazione, ad es. che non connettono tutti i nodi tra loro. Può essere utile, tuttavia in overl del cluster di ~ 50 l'overhead non è significativo. Inoltre è possibile creare un grafico dei nodi di erlang usando la connessione 'nascosta', che non si unisce alla rete completa, ma non può anche trarre vantaggio dalla connessione a tutti i nodi.

Il problema più grande che vedo, in questo tipo di sistemi, è la progettazione come sistema senza padrone. Se non ne hai bisogno, tutto dovrebbe essere ok.