replica della sessione tomcat senza multicast

Question

Sto pensando di utilizzare 2 server root dedicati noleggiati presso un provider di hosting. quelle macchine eseguiranno tomcat 6 in un cluster. se aggiungerò ulteriori macchine in un secondo momento - è improbabile che siano accessibili con multicast, poiché si troveranno in sottoreti diverse.

è possibile eseguire Tomcat senza multicast? tutti i tutorial per il clustering di Tomcat 6 includono il battito cardiaco multicast. ci sono alternative a SimpleTcpCluster?

o altre alternative sono più appropriate in questa situazione?

Answer 1

Senza alcun controllo sulla distanza tra i due server (potrebbero trovarsi in due diversi datacenter) e nessuna linea di comunicazione tra server dedicata, preferirei eseguirli tramite DNS round robin o un bilanciamento del carico che reindirizza i client a www1.yourdomain.xxx o www2.yourdomain.xxx e gestisci attentamente le comunicazioni del server.

Se i server comunicano pesantemente tra loro, potresti cercare di cambiare la tua architettura, ottimizzare l'inferno della tua applicazione per "adattarlo". su un server (almeno per un po ') o scegli l'hosting dedicato con il controllo della posizione, della distanza e del cablaggio dei tuoi server. Altrimenti la comunicazione tra server, il battito cardiaco ecc. Utilizzerebbe lo stesso canale dei client che stanno comunicando con esso (ad es. Lo stesso segmento di rete) che potrebbe rallentare tutti.

Se ti aspetti davvero quel carico, suppongo ci siano almeno dei soldi in gioco, no? Usalo con saggezza e usa le tue abilità di setup per problemi più difficili della creazione di cluster distribuiti senza controllo o linee dedicate.

Answer 2

Vedendo il commento alla domanda dopo aver dato la mia altra risposta, sono perplesso su quale sia la tua domanda ... Riguarda la replica della sessione? Comunicazione a grappolo? Potrebbe essere meglio indicare il tuo problema anziché la soluzione pianificata che ha problemi in sé.

Indicherò alcuni possibili problemi insieme a risposte rapide:

L'applicazione richiede molta CPU / RAM

• Profilalo, ottimizzalo, riprova
• Acquista un server più grande / migliore

L'applicazione richiede molta larghezza di banda

• l'uso del clustering di cheapo menzionato nella tua domanda probabilmente peggiorerà le cose, poiché lo stesso canale (mascherato) viene utilizzato per la comunicazione tra server come per la comunicazione client-server
• Potresti riuscire a separare diversi tipi di larghezza di banda, ad es. disponendo di contenuti dinamici forniti da un server diverso rispetto a quelli statici: qui non è necessario comunicare tra server

La tua applicazione richiede molta memoria

• ottieni un server più grande
• scegli l'hosting dedicato e inserisci tutti i dischi rotanti di cui hai bisogno
• vedi se altri modelli (come lo storage S3 di amazzoni) potrebbero funzionare per te)

È probabile che la tua applicazione venga barrata

• determina quali dei suddetti fattori (o altri) stanno determinando i limiti della tua applicazione, risolvili.

Hai solo bisogno della replica della sessione?

• L'interfaccia di Tomcats SessionManager è piccola e può essere facilmente implementata / estesa da solo. Usalo per qualsiasi replica di sessione che ti piace. Vedi la StandardManager e implementazione per maggiori informazioni

Altre idee

• guarda configurazioni più flessibili come EC2 (amazon), offerte googles o altre configurazioni di cloud computing. Utilizzare le proprie strutture di archiviazione cloud e di comunicazione tra server. Fare attenzione a non dipendere troppo da questa infrastruttura.

Ho sicuramente dimenticato qualcosa, ma questo potrebbe fornire un punto di partenza. Sii più concreto sulla natura del tuo problema di base per ottenere risposte migliori :)

Answer 3

Sto tentando di distribuire il Central Authentication Server (CAS) di yale e vorrei raggrupparlo per ridondanza, poiché si tratta di un'infrastruttura critica. CAS richiede che la sessione venga replicata, poiché dopo che un utente accede all'applicazione A e passa all'applicazione B che partecipa al dominio Single Sign-On, l'applicazione B invia una richiesta a CAS per determinare se l'utente ha un "ticket" attivo . Poiché non esiste alcun dispositivo che indichi all'applicazione B a quale nodo dovrebbe indirizzarsi per convalidare il ticket, tutti i ticket attivi in ??un nodo devono essere replicati su tutti i nodi del cluster. In altre parole, l'appiccicosità della sessione non è una soluzione qui, poiché l'applicazione B, durante la convalida del ticket nel cookie dell'utente, non è a conoscenza della sessioneId della sessione originale nell'applicazione A durante la quale l'utente ha effettuato l'accesso.

Pertanto, CAS richiede che la sessione venga replicata su tutti i nodi. Il requisito secondo cui la rete supporta il multicast aggiunge un sovraccarico non banale e rende questo approccio un po 'più pesante da implementare. Ho testato questo progetto su google code:

http://code.google.com/p/memcached-session-manager

che sembra molto utile e semplice da distribuire (almeno su un sistema operativo Linux), ma sfortunatamente prevede solo il failover della sessione e non è una soluzione di replica della sessione.

Answer 4

Usa http://code.google.com/p/memcached-session -manager / . Funziona benissimo. Lo stiamo usando da anni per questa configurazione con 20 server Tomcat che condividono sessioni. È possibile disporre di uno o due server memcached per gestire la replica della sessione.