Rails & High Availability

Ciao,

a livello d’indagine sto vedendo possibili soluzioni per rendere high
available e scalabile un’applicazione Rails. La soluzione (a mio
avviso) migliore è quella di usare Mongrel Cluster (e Apache davanti
che fa da load balancer).

Se non si vuole usare un load balancer “Session Affinity” questo tipo
di soluzione obbliga comunque a rendere persistente la sessione sul
DBMS (con evidente costo di recupero -eventuale- della sessione ad
ogni request).

Ho cercato in giro soluzioni di Session Replication in Rails ma non ho
trovato nulla (robe tipo JavaGroups per intenderci). Esiste qualcosa
che conoscete?

Grazie
Piero

Il giorno mar, 27/03/2007 alle 12.17 +0200, Piero C. ha scritto:

ogni request).

Ho cercato in giro soluzioni di Session Replication in Rails ma non ho
trovato nulla (robe tipo JavaGroups per intenderci). Esiste qualcosa
che conoscete?

Io ho usato spesso memcached (anche fuori da rails):

http://railsexpress.de/blog/articles/2006/01/24/using-memcached-for-ruby-on-rails-session-storage

Anche la replica sui vari nodi e’ molto semplice da implementare

Piero C. wrote:

Se non si vuole usare un load balancer “Session Affinity” questo tipo
di soluzione obbliga comunque a rendere persistente la sessione sul
DBMS (con evidente costo di recupero -eventuale- della sessione ad
ogni request).

il recupero dei dati di sessione ha un costo in ogni caso, non importa
dove vengono memorizzati, nel caso di session replication il costo e’
nella replicazione delle sessioni e nella complessita degli application
server.

Inoltre in una architettura “shared nothing” (come quella usata da Rails
e da tutti gli stack LAMP) il punto di “condivisione” e’ dietro gli
application server. Infine nel caso di una gestione con SessionAffinity
la difficolta’ e’ nel corretto bilanciamento del traffico poiche
richieste multiple di poche sessioni possono rallentare l’app. server su
cui sono dirette.

La strategia migliore in questo caso, ed in tutti quelli in cui vuoi
ottenere alta affidabilita e scalabilita, e’ minimizzare le informazioni
mantenute in sessione ed affidarti ad un meccanismo fuori
dall’application server, come appunto il database.

L’impatto del recupero della sessione rispetto al resto delle attivita
di database e’ minimale nella maggior parte dei casi di applicazioni web
(ovvero ovunque ci sia altra attivita sul database), ma eventualmente
(i.e. se il carico diventa troppo alto per il tuo server) puoi pensare
ad uno storage dedicato alle sessioni separato dal database principale
(sql o di tipo memcached).

HTH
Luca

Web: http://spazidigitali.com - http://thetyper.com
Email mailto://[email protected]
Skype callto://l.mearelli

Roberto De Ioris wrote:

Il giorno mar, 27/03/2007 alle 12.17 +0200, Piero C. ha scritto:

ogni request).

Ho cercato in giro soluzioni di Session Replication in Rails ma non ho
trovato nulla (robe tipo JavaGroups per intenderci). Esiste qualcosa
che conoscete?

Io ho usato spesso memcached (anche fuori da rails):

Using memcached for Ruby on Rails session storage

Anche la replica sui vari nodi e’ molto semplice da implementare

Memcached è un’ottima alternativa ma se vuoi un’alternativa integrata in
Rails puoi provare ad usare la DRbSession (per incrementare del 10%
circa le “request per second” rispetto alla sessione persistente sul DB)

Il giorno mar, 27/03/2007 alle 14.23 +0200, Luca M. ha scritto:

Luca M. wrote:

ad uno storage dedicato alle sessioni separato dal database principale
(sql o di tipo memcached).

Aggiungo solo una considerazione visto che parli di HA: in tutte le
soluzioni tipo memcached (come qualsiasi altra soluzione “memory-only”),
lo storage delle sessioni puo diventare un punto debole: se il
processo viene riavviato tutte le sessioni sono resettate.

Beh stiamo parlando di HA, si presuppone che ci siano almeno 2 nodi
memcached con dati consistenti (attenzione la replica non la fa
memcached ci vuole un’applicazione ad-hoc)

In effetti non scelgo memcached perche’ e’ piu’ performante ma solo
perche’ e’ piu’ semplice avere una replica consistente rispetto a
qualsiasi scelta (in ambito opensource) su database.

Luca M. wrote:

ad uno storage dedicato alle sessioni separato dal database principale
(sql o di tipo memcached).

Aggiungo solo una considerazione visto che parli di HA: in tutte le
soluzioni tipo memcached (come qualsiasi altra soluzione “memory-only”),
lo storage delle sessioni puo diventare un punto debole: se il
processo viene riavviato tutte le sessioni sono resettate.

Luca

Web: http://spazidigitali.com - http://thetyper.com
Email mailto://[email protected]
Skype callto://l.mearelli