Scala + Akka: come sviluppare un multi-macchina altamente disponibile Cluster

Question

Stiamo sviluppando un sistema server a Scala + Akka per un gioco che servirà i clienti in Android, iPhone, e Second Life. Ci sono parti di questo server che hanno bisogno di essere altamente disponibile, in esecuzione su più macchine. Se uno di questi server muore (di, diciamo, guasti hardware), le esigenze del sistema per continuare a correre. Penso che voglio i clienti di avere un elenco di macchine che cercheranno di connettersi con, in modo simile a come funziona Cassandra.

Gli esempi di multi-nodo che ho visto finora con Akka mi sembrano essere centrato intorno all'idea di scalabilità, piuttosto che l'alta disponibilità (almeno per quanto riguarda l'hardware). Gli esempi più nodi sembrano avere sempre un singolo punto di errore. Per esempio ci sono bilanciatori di carico, ma se ho bisogno di riavviare una delle macchine che hanno bilanciamento del carico, il mio sistema subiranno dei tempi di inattività.

Ci sono esempi che mostrano questo tipo di tolleranza ai guasti hardware per Akka? Oppure, avete qualche idea su buoni modi per rendere questo accada?

Finora, la migliore risposta che ho potuto venire in mente è di studiare la documentazione Erlang OTP, meditare su di loro, e cercare di capire come mettere insieme il mio sistema utilizzando i blocchetti di costruzione disponibili in Akka.

Ma se ci sono risorse, esempi o idee su come stato di condivisione tra più macchine in un modo che se uno di loro scende cose continuare a correre, mi piacerebbe certo li apprezzano, perché mi riguarda potrebbe essere reinventare la ruota qui. Forse c'è un contenitore STM multi-nodo che mantiene automaticamente lo stato condiviso in sincronia tra nodi multipli? O forse questo è così facile fare che la documentazione non si preoccupa che mostrano esempi di come farlo, o forse non sono stato abbastanza approfondita nella mia ricerca e sperimentazione ancora. Tutti i pensieri o idee saranno apprezzate.

Answer 1

HA e gestione del carico è un aspetto molto importante di scalabilità ed è disponibile come parte dell'offerta commerciale AkkaSource.

Answer 2

Se stai messa in vendita di più host potenziali nei vostri clienti già, allora questi possono effettivamente diventare bilanciatori di carico.

Si potrebbe offrire un servizio di suggerimento host e raccomanda al cliente quale macchina dovrebbero connettersi (in base al carico di corrente, o qualsiasi altra cosa), allora il cliente può appuntare al che fino a quando la connessione non riesce.

Se il servizio di suggerimento host non è lì, allora il cliente può semplicemente scegliere un host a caso da esso lista interna, cercando di loro fino a quando si connette.

Idealmente sulla prima volta start up, il client si connetterà al servizio suggestione ospite e non solo ottenere diretto a un host appropriato, ma una lista di altri host potenziali pure. Questo elenco può regolarmente essere aggiornato ogni volta che si connette il client.

Se il servizio di suggerimento host è giù sui client primo tentativo (improbabile, ma ...), allora è possibile pre-distribuzione di un elenco di host del client di installazione in modo da poter iniziare immediatamente selezionando casualmente padroni di casa fin dall'inizio, se ha anche.

Assicuratevi che il vostro elenco di host è i veri nomi di host, e non l'IPS, che ti danno una maggiore flessibilità a lungo termine (vale a dire si "avere sempre" host1.example.com, host2.example.com ... ecc . anche se si sposta di infrastrutture e cambiare IP).

Answer 3

Si potrebbe dare un'occhiata come RedDwarf e della forcella DimDwarf sono costruite. Sono entrambi i server di gioco app anticrash solo orizzontalmente scalabili e DimDwarf è in parte scritti in Scala (nuova funzionalità di messaggistica). Il loro approccio e l'architettura dovrebbero soddisfare le vostre esigenze abbastanza bene :)

Answer 4

2 centesimi ..

"come stato di condivisione tra più macchine in un modo che se uno di loro scende le cose continuano in esecuzione"

Non condividere lo stato tra le macchine, invece lo stato di partizione tra macchine. Io non conosco il tuo dominio in modo da non so se questo funzionerà. Ma in sostanza, se si assegna taluni aggregati (in termini DDD) a certi nodi, è possibile mantenere quegli aggregati in memoria (attore, agente, ecc) quando vengono utilizzati. Per fare questo è necessario usare qualcosa come guardiano dello zoo di coordinare le quali nodi maniglia che aggregati. In caso di guasto è possibile portare l'alto aggregati su un nodo diverso.

ulteriormente più, se si utilizza un modello di eventi di sourcing per costruire il tuo aggregati, diventa quasi banale per avere copie in tempo reale (slave) del vostro aggregato su altri nodi di quei nodi di ascolto per gli eventi e mantenere le proprie copie.

Utilizzando Akka, otteniamo i servizi remoti tra i nodi quasi gratis. Ciò significa che che le maniglie mai nodi di una richiesta che potrebbe aver bisogno di interagire con un aggregato / entità a un nodi possono farlo con RemoteActors.

Quello che ho qui delineato è molto generale, ma dà un approccio alla distribuita fault-tolerance con Akka e ZooKeeper. Si può o non può aiutare. Spero che lo fa.

Tutti i migliori, Andy