LOAD BALANCING PER SERVIZI DI

Transcript

1 LOAD BALANCING PER SERVIZI DI PRESENZA Carella Giuseppe Antonio Matricola Docente: Prof. Ing. Antonio Corradi Relatore: Ing. Luca Nardelli Attività progettuale di Reti di Calcolatori M Anno accademico 2009/2010

2 PREMESSA Diffusione di Internet e della telefonia mobile Convergenza dei servizi multimediali in un unica piattaforma oservizi di presenza SIP based oistant Messaging oonline/offline/busy oprotocollo SIP, come protocollo di segnalazione oprotocollo text-based costi elevati di gestione

3 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

4 MECCANISMO PUB/SUB IN SIP Ogni aggiornamento di stato prevede un invio al presence server di una PUBLISH request, secondo lo standard RFC 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 Ad ogni SUBSCRIBE request segue, una NOTIFY inviata dal PS contenente informazioni della presentity

5 SCENARIO SINGLE SERVER Watchers si sottoscrivono presso il server in cui risiede la presentity. Servizio intrinsecamente centralizzato, scarsa scalabilità

6 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

7 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

8 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

9 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

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

11 LOAD BALANCING TRAMITE MONITOR PS Thread Sender su server 2 Thread Receiver su server 1 Selezione e invio della lista Ricezione

12 TECNOLOGIE UTILIZZATE Application Server in Jain SIP DB Kamailio Presence Server IMS Bench SIPp

13 TESTBED IMS Bench PSLB Kamailio PS Monitor PS Kamailio PS Monitor PS 3 computer con: pentium MB di RAM interfaccia Lan sistema operativo ubuntu 9.04 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.

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

15 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