load balancing per servizi di presenza - lia · •sistema operativo ubuntu 9.04 ims bench pslb...

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


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


SCENARIO SINGLE SERVER

• Servizio intrinsecamente centralizzato, scarsa scalabilità


• 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


• 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


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


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


• 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.


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


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.


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.


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


load balancing per servizi di presenza - lia · •sistema operativo ubuntu 9.04 ims bench pslb...

Documents