load balancing per servizi di presenza - lia · •sistema operativo ubuntu 9.04 ims bench pslb...
TRANSCRIPT
LOAD BALANCING PER SERVIZI DI
PRESENZA
Carella Giuseppe Antonio
Matricola 0000348431
Docente: Prof. Ing. Antonio Corradi
Relatore: Ing. Luca Nardelli
Attività progettuale di Reti di Calcolatori M
Anno accademico 2009/2010
PREMESSA
Diffusione di Internet e della telefonia mobile
Convergenza dei servizi multimediali in un’unica piattaforma
Carella Giuseppe Antonio 19-01-2011
oServizi di presenza SIP basedoIstant Messaging
oOnline/offline/busy
oProtocollo SIP, come protocollo di segnalazioneoProtocollo text-based costi elevati di gestione
SERVIZI DI PRESENZA
o Presence Server: server delegato alla fornitura del servizio
o Presence entity (presentity): entità che fornisce informazione sulla sua
presenza
o Watcher: entità che riceve informazioni sullo stato della presentity
Carella Giuseppe Antonio 19-01-2011
MECCANISMO PUB/SUB IN SIP
Ogni aggiornamento di stato prevede un invio
al presence server di una PUBLISH request,
secondo lo standard RFC 3903.
Informazioni di stato contenute nel body del
messaggio in un documento XML.
Per la sottoscrizione ogni watcher deve inviare
una SUBSCRIBE request, secondo lo standard
definito nell’RFC 3265.
Ad ogni SUBSCRIBE request segue, una
NOTIFY inviata dal PS contenente informazioni
della presentity
Carella Giuseppe Antonio 19-01-2011
SCENARIO SINGLE SERVER
• Servizio intrinsecamente centralizzato, scarsa scalabilità
Carella Giuseppe Antonio 19-01-2011
• Watchers si sottoscrivono presso il server in cui risiede la presentity.
SCENARIO DISTRIBUITO
• Ogni dominio di utenti viene partizionato su vari server
•Necessario meccanismo per la distribuzione di dati di presenza tra i vari
server appartenenti al dominio
Carella Giuseppe Antonio 19-01-2011
• Partizionamento statico degli utenti, che a fronte di situazioni di
sovraccarico cambia dinamicamente
SOLUZIONE CON RIDIREZIONE PUBLISH REQUEST
• Coordinazione tra server, attraverso la ridirezione delle PUBLISH
• Non rispetta i requisiti di dinamicità e mobilità
•Traffico sulla rete elevato anche in situazioni di un basso numero di utenti
• Scarsa efficienza a fronte di sovraccarichi
Carella Giuseppe Antonio 19-01-2011
SOLUZIONE CON DB CENTRALIZZATO
• Ogni Presence Server lavora memorizzando le informazioni relative agli
utenti in un database
•Una soluzione alternativa è l’utilizzo di un database centralizzato
•Unico punto di centralizzazione
•Obbligo di lavorare in writethrough
Carella Giuseppe Antonio 19-01-2011
SOLUZIONE CON PARTIZIONAMENTO STATICO
•Nessun meccanismo di coordinazione richiesto. Ogni server conosce dove
si trova un utente e quindi sa dove ridirigere i messaggi ricevuti
• Partizionamento delle presentity
Carella Giuseppe Antonio 19-01-2011
• Soluzione statica
IDEA DI LOAD BALANCING
Le soluzioni finora descritte non rispettano gli obiettivi che si vogliono
raggiungere attraverso la gestione dinamica dei vari server.
Quello che si vuole raggiungere è una MIGRAZIONE automatica di una
serie di utenti da un server ad un altro, prima che venga raggiunta la
saturazione.
L’idea iniziale è di partizionare gli utenti tra i vari server del dominio. Per
questo scopo è previsto un Presence Server Load Balancer (PSLB) ,
stateless, la cui funzione è quella di ridirigere le varie richieste ricevute
dai client sui diversi server del dominio.
Quando in uno dei server del dominio si supera la soglia di carico della
CPU, automaticamente viene cambiato il range di partizionamento degli
utenti, e si ha una migrazione di utenti da un server ad un altro.
Coordinamento tra server dello stesso dominio mediante meccanismo
Pub Sub. Scambio di informazioni sul carico di lavoro in periodi
prestabiliti.
Carella Giuseppe Antonio 19-01-2011
LOAD BALANCING TRAMITE MONITOR PSThread Sender su server 2
Thread Receiver su server 1
Selezione e invio della lista
Ricezione
TECNOLOGIE UTILIZZATE
DB
Application Server in Jain SIP
IMS Bench SIPp
Kamailio Presence Server
Carella Giuseppe Antonio 19-01-2011
TESTBED
• 3 computer con:
• pentium 4
• 512 MB di RAM
• interfaccia Lan
• sistema operativo ubuntu 9.04
IMS Bench
PSLB
Kamailio PS
Monitor PSKamailio PS
Monitor PS
Scenario utilizzato:
• 400 SUBSCRIBE iniziali
• 55 step di PUBLISH con durata di
5 sec, e 5 cps, con un incremento
di 4 cps.
• 140 cps di PUBLISH per 500 sec.
Carella Giuseppe Antonio 19-01-2011
RISULTATI SPERIMENTALI
Singola macchina:
saturazione dopo 270 sec, con
conseguente ritrasmissioni e
perdite di messaggi.
Con il monitor PS:
dopo 270 sec viene assegnata la
metà del carico di lavoro ad un
altro server.
Carella Giuseppe Antonio 19-01-2011
CONCLUSIONI E SVILUPPI FUTURI
CONCLUSIONI
• Infrastruttura per il load balancing di servizi di presenza
• Realizzazione di un modulo in JAVA
SVILUPPI FUTURI
• Migliorare il protocollo di coordinazione tra i server utilizzando semplici
connessioni multicast
•Rendere possibile l’utilizzo di questa procedura anche tra domini differenti
Carella Giuseppe Antonio 19-01-2011