Tesi di Laurea WebSim: un simulatore basato su tracce per sistemi Web distribuiti localmente Candidato: Mauro Ranchicchio Relatore: Prof. Salvatore Tucci Correlatore: Ing. Valeria Cardellini Sommario Sistemi Web Cluster one-way Misurazione del carico nel Web Simulazione di un sistema Web Cluster Implementazione del simulatore a tracce Politiche di dispatching e QoWS Caratterizzazione del carico Risultati dell analisi simulativa Conclusioni e sviluppi futuri 1
Sistemi Web Cluster one-way: architettura Documento Server Web 1 Server Web 2 Server Web 3 Client Richiesta documento INTERNET Web switch LAN Server back-end Server Web 5 Server Web 4 Misurazione del carico nel Web: le tecniche Server Logging: registrazione di tutte le richieste HTTP trattate dal server Web Proxy Logging: utilizzato per valutare politiche di caching e popolarità delle risorse Client Logging: implica modifiche al codice del browser; utilizzato per conoscere gli schemi di navigazione degli utenti Packet Monitoring: cattura dei singoli pacchetti IP transitanti per un link di rete o attraverso un router Misurazioni attive: generazione di richieste in modo controllata ed osservazione prestazioni 2
Common Log Format Common Log Format (CLF): è il formato di server log più diffuso; è adottato come default dal server Apache Esempio di istanza: 16.8.35.5 - - [15/Mar/22:18:3:6 +1] "GET /gallery/landscape.jpg HTTP/1.1" 2 16384 Il formato del record consiste di sette campi: - host remoto - identità remota - utente autenticato - time-stamp - stringa della richiesta - codice di stato della risposta - numero di byte trasferiti Simulazione di un sistema Web Cluster: il motore di simulazione CSIM CSIM è una libreria di simulazione a eventi discreti, orientata ai processi Processi: Modellazione entità attive del sistema Interazione e comunicazione tra processi: (Client, processi HTTP, processi di gestione del dispatching, etc) Eventi: un processo può attenderne l occorrenza Risorse: o settarlo - Facility: Modellazione risorse con uso Mailbox: serializzato strutture per (CPU, scambio server di informazioni back-end, Web sotto switch, forma dischi) messaggi - Storage: Modellazione memoria centrale dei server Web 3
Simulazione di un sistema Web Cluster: lo schema funzionale di WebSim INPUT Parametri Modulo di servizio DISPATCHER CLIENT SERVER FILE SYS GATHER RAM CACHING Moduli di sistema Tabelle di output OUTPUT Moduli di servizio Simulazione di un sistema Web Cluster: processi server 1) httpd 2) httpd (padre) fork() httpd (figlio) 3) httpd (padre) httpd (figlio) Listen Connect Listen Richieste dal client Il server rimane in attesa di connessioni: per ciascuna nuova richiesta client assegnatagli dal Web switch, crea un nuovo processo figlio che si occuperà di soddisfarla 4
Implementazione del simulatore a tracce WebSim: modellazione nodi server Uscita dal sistema Entrata nel sistema CPU Richiesta statica P Cache server Web 1-P Disco server back-end Richiesta dinamica Back end Esempio Richieste di dinamiche: richiesta dinamica: sono servite da appositi nodi "GET back-end /cgi-bin/script.cgi?param1=val1¶m2=val2... (application o database server)...param3=val3 HTTP/1.1" Simulazione di un sistema Web Cluster: generazione del carico Il workload da sottoporre ad un simulatore può essere generato: - Analiticamente: distribuzioni probabilistiche, invarianti del traffico Web - Da tracce: ricostruzione delle sessioni, dati memorizzati in file di log WebSim è un simulatore basato su tracce ricavate dall analisi di server log in formato CLF Riproduzione del comportamento degli utenti registrato nel periodo di osservazione 5
Implementazione del simulatore a tracce WebSim: ricostruzione sessioni utente Delimitazione Determinazione delle di un sessioni time-out utente: adeguato per informazione suddividere in non sessioni contenuta il traffico in modo registrato esplicito nel proveniente server log dallo stesso client Effetto del time-out sul numero di sessioni t < t.out: Client C: richesta i-esima le richieste # sessioni #max sessioni attive appartengono 12 alla 1 stessa 9 sessione 1 Client C: richiesta (i+1)-esima 8 7 8 t > t.out: 6 la richiesta 6 5 (i+1)-esima 4 4 è la 3 prima di 2 una2 nuova 1 sessione Client C: richiesta (i+2)-esima # session 5 1 5 1 5 1 5 1 time-out [sec] Si adotta un time-out di 1 secondi # max sess. attiv Caratterizzazione del carico Le tracce sono state ottenute tramite elaborazione di file di log del sito World Cup 98 rappresentanti differenti tipologie di carico Carico Arco temporale #File distinti trasferiti Dimensione media file Frequenza hit Low 1 giorno 3266 21517 byte 8.7 hit/sec Mid 28 18 5189 1493 byte 396 hit/sec High 5 54 3748 954 byte 1912 hit/sec Carico % Richieste dinamiche Heavydyn ~8% Il quarto tipo di carico (Heavydyn) è rappresentativo del mix di richieste verso un sito di e-commerce 6
Qualità del Servizio Web: principi Classificazione - Identificazione classi di utenti e servizi - Classificazione utenti e servizi Isolamento delle prestazioni - Politiche di scheduling con priorità - Partizionamento delle risorse Alta utilizzazione delle risorse - Partizionamento dinamico delle risorse Richiesta di ammissione - DICHIARAZIONE: stima della richiesta di risorse - CONTROLLO DELL ACCESSO: decisione sull ammissione della richiesta di connessione Analisi simulativa: organizzazione Sono stati svolti gli esperimenti utilizzando quattro differenti Analisi politiche di scalabilità: di dispatching: sensibilità delle prestazioni del sistema al numero di nodi server nel cluster Politiche - Totalità di 4 delle livello richieste dinamiche: - Richieste - Weighted dinamiche Round Robin - Risorse - Least di tipo Loaded single file (oggetti non-embedded) Analisi Politiche della di 7 Qualità livello QoWS-aware: del Servizio Web: verifica del rispetto - SwitchPriority del Service Level Agreement e confronto (classificazione tra tempi di servizio e controllo per di classe ammissione) High e classe Low - StaticServerPartitioning (isolamento delle prestazioni) 7
Risultati dell analisi simulativa: analisi di scalabilità 9-percentile PRT e 9-percentilePRT HRT [msec] PRT e e HRT 9-percentile PRT HRT[msec] HRT [msec] 2 2 15 15 15 1 1 5 5 Dispatching ServerPart SwitchPri WRR LL 23 3 4 4 5 5 8 8 8 # nodi nodi server server # nodi server PRT PRT HRT HRT Politica Politica di dispatching: Weighted ServerPartitioning SwitchPriority Least Round LoadedRobin Risultati dell analisi simulativa: analisi di scalabilità Server-side Page Response Time - Carico HIGH 9-percentile PRT 16 14 12 1 8 6 4 2 3 4 5 8 WRR 128,8 95,3 76 48,9 LL 114,2 88,6 72,9 54,9 SwitchPri 116,3 91,5 73,6 49,4 ServerPart 15,7 123,8 88,9 69,5 # nodi server WRR LL SwitchPri ServerPart Carico High: evidenzia meglio degli altri il vantaggio apportato dallo scale-out del Web cluster 8
Risultati dell analisi simulativa: richieste dinamiche Client-side PRT PRT per per pagine dinamiche statiche e dinamiche (al variare del numero di Sistema back-end) singolo - Carico serverheavydyn 9-percentile PRT [sec] 25 25 2 23 15 21 1 19 9-percentile PRT [se 5 17 Statiche Dinamiche 15Carico 1HIGH 2Carico MID 3 Carico 4 LOW5 8 Statiche 9-perc.PRT 83,5 232,7 218,783,9218,5 26,7 92,4 197,2 189,1 Dinamiche 143,1 22,5 211,5 # nodi back-end Generazione dinamica dei contenuti: conduce ad incrementi sul PRT dal 71% al 163% per i tre scenari considerati Il carico Heavydyn evidenzia i vantaggi dello scale-out dell insieme di server back-end Risultati dell analisi simulativa: QoWS Server-side PRT e connessioni rifiutate Dispatching SwitchPriority 9-percentile Server-side PRT [msec] 18 16 14 12 1 8 6 4 2 2 3 4 5 8 PRT HighClass 135,7 11 86,8 68,8 45,6 PRT LowClass 157,9 113,6 87,6 69,9 45,4 % Rifiut. Low 27 16,3 1,3 5,8 1,5 # nodi server 3 25 2 15 1 5 % conn. LowClass rifiutate La politica SwitchPriority riesce a garantire il SLA nel Server-side PRT solamente per sistemi ad alto numero di nodi 9
Risultati dell analisi simulativa: QoWS Frequenza cumulativa PR Server-side PRT Page e connessioni Response rifiutate Time Dispatching Carico ServerPart HIGH 1 server SwitchPri 8 High ServerPart 8 High 1 2 3 18,9 16 25,8 14 2,7 12,6 1 15,5 8 6 1,4 4,3 2 5,2 3 4 5 8,1 PRT HighClass 47,3 47,4 46,9 33,2 PRT LowClass 175,5 137,4 94,9 7,9 9 -percentile Server-side PRT [msec] 2 4 6 8 1 % Rifiut. Low 24 13,7 6,9 3,1 # nodi server PRT [msec] 12 14 16 18 2 % conn. LowClass rifiutate La politica ServerPartitioning permette di rispettare sempre il SLA, ma al costo di un maggior numero di richieste rifiutate di classe Low Conclusioni E stato implementato un simulatore basato su tracce per sistemi Web Cluster, adottando diverse politiche di switching L analisi di scalabilità ha evidenziato la capacità delle politiche dinamiche di 4 livello di beneficiare dello scale-out in modo pressoché lineare Sono state confrontate le politiche ServerPartitioning e SwitchPriority, nell ottica della QoWS 1
Sviluppi futuri Utilizzo tracce da siti di e-commerce o information retrieval (alta presenza di contenuti dinamici) Classificazione delle richieste dinamiche per l utilizzo di politiche Client-aware (es., CAP) Utilizzo di formati di log con migliore granularità del time-stamp 11