Tesi di Laurea WebSim: un simulatore basato su tracce per sistemi

z
z
Tesi di Laurea
WebSim: un simulatore basato
su tracce per sistemi Web
distribuiti localmente
Candidato:
Mauro Ranchicchio
Relatore:
Correlatore:
Prof. Salvatore Tucci
Ing. Valeria Cardellini
Sommario
•
•
•
•
•
•
•
•
z
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
z1
z
z
Sistemi Web Cluster one-way:
architettura
Documento
Server Web 2
Server Web 1
Server Web 3
LAN
Richiesta
documento
INTERNET
Web switch
Client
Server Web 4
Server
back-end
Server Web 5
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
z
z2
z
z
Common Log Format
Common Log Format (CLF): è il formato di server
log più diffuso; è adottato come default dal server
Apache
Esempio di istanza:
160.80.35.50 - - [15/Mar/2002:18:30:06 +0100]
"GET /gallery/landscape.jpg HTTP/1.1" 200 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)
un processo può attenderne l’occorrenza
Risorse:
•• Eventi:
o settarlo
- Facility: Modellazione risorse con uso
server
back-end,
• Mailbox: serializzato
strutture per (CPU,
scambio
di informazioni
Web
switch,
dischi)
sotto forma di messaggi
- Storage: Modellazione memoria centrale
dei server Web
z
z3
z
z
Simulazione di un sistema Web Cluster:
lo schema funzionale di WebSim
INPUT
INPUT
Parametri
Parametri
DISPATCHER
DISPATCHER
CLIENT
CLIENT
Modulo di servizio
SERVER
SERVER
Moduli di sistema
FILE
FILE SYS
SYS
RAM
RAM
GATHER
GATHER
OUTPUT
OUTPUT
Tabelle
Tabelle di
di
output
output
CACHING
CACHING
Moduli di servizio
Simulazione di un sistema Web Cluster:
processi server
fork()
2)
1)
httpd
httpd
(padre)
Listen
Connect
3)
httpd
(figlio)
httpd
(padre)
Listen
httpd
(figlio)
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
z
z4
z
z
Implementazione del simulatore a tracce
WebSim: modellazione nodi server
Uscita dal sistema
P
Entrata nel
sistema
CPU
C ache
server Web
Richiesta
statica
1-P
Disco
server back-end
Richiesta dinamica
Back
end
Esempio
di dinamiche:
richiesta dinamica:
Richieste
sono servite da appositi nodi
"GET
/cgi-bin/script.cgi?param1=val1&param2=val2...
back-end
(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
z
z5
z
z
Implementazione del simulatore a tracce
WebSim: ricostruzione sessioni utente
Delimitazione delle
sessioni
utente:
Determinazione
di un
time-out
adeguato per
informazioneinnon
contenuta
in modo
esplicito nel
suddividere
sessioni
il traffico
registrato
server log dallo stesso client
proveniente
∆t <
Effetto del time-out sul numero di sessioni
# sessioni
#max sessioni attive
120000
100000
# session
Client C: richiesta (i+1)-esima
8000
7000
t.out:
∆t >
6000
la richiesta
5000
(i+1)-esima
4000
è la3000
prima di
una2000
nuova
1000
sessione
80000
60000
40000
20000
0
Client C:
richiesta
(i+2)-esima
5
10
50
100
500
1000
# max sess. attiv
t.out:
le richieste
appartengono
alla10000
stessa
9000
sessione
Client C: richesta i-esima
0
5000
10000
time-out [sec]
Si adotta un time-out di 100 secondi
Caratterizzazione del carico
Le tracce sono state ottenute tramite elaborazione di
file di log del sito World Cup‘98 rappresentanti
differenti tipologie di carico
#File
Dimensione
distinti
media file
trasferiti
3266
21517 byte
Carico
Arco
temporale
Frequenza
hit
Low
1 giorno
Mid
28’ 18’’
5189
14903 byte
396 hit/sec
High
5’ 54’’
3748
9540 byte
1912 hit/sec
Carico
Heavydyn
% Richieste dinamiche
~80%
8.7 hit/sec
Il quarto tipo di carico (Heavydyn) è rappresentativo
del mix di richieste verso un sito di e-commerce
z
z6
z
z
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
di dispatching:
Analisi politiche
di scalabilità:
sensibilità delle prestazioni
•differenti
del sistema al numero di nodi server nel cluster
di 4°
dinamiche:
• Politiche
- Totalità
dellelivello
richieste
- Weighted
Round Robin
- Richieste
dinamiche
- Risorse
di tipo
single file (oggetti non-embedded)
- Least
Loaded
Politichedella
di 7°Qualità
livello QoWS-aware:
del Servizio Web: verifica
•• Analisi
- SwitchPriority
del rispetto
del Service Level Agreement e
(classificazione
e controllo
ammissione)
confronto
tra tempi di servizio
per di
classe
High e
- StaticServerPartitioning
classe Low
(isolamento delle prestazioni)
z
z7
z
z
Risultati dell’analisi simulativa:
analisi di scalabilità
90-percentile
PRT e
[msec]
HRT[msec]
HRT [msec]
90-percentile PRT e
90-percentilePRT
90-percentile
PRTe eHRT
HRT [msec]
Dispatching
LL
Dispatching
SwitchPri
Dispatching
ServerPart
Dispatching
WRR
200
200
200
200
150
150
150
150
100
100
100
100
PRT
PRT
PRT
HRT
HRT
HRT
50
50
50
50
000
0
223
2
33 4 44 5 55
3 # nodi 4
5
server
nodi server
server
## nodi
# nodi server
8 88
8
Politica
dispatching:
SwitchPriority
Politica
di dispatching:
Weighted
Politica
di
dispatching:
LeastRound
LoadedRobin
Politica
didi
dispatching:
ServerPartitioning
Risultati dell’analisi simulativa:
analisi di scalabilità
Server-side Page Response Time - Carico HIGH
160
90-percentile PRT
140
120
100
WRR
LL
80
SwitchPri
60
ServerPart
40
20
0
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
150,7
123,8
88,9
69,5
# nodi server
Carico High: evidenzia meglio degli altri il vantaggio
apportato dallo scale-out del Web cluster
z
z8
z
z
Risultati dell’analisi simulativa:
richieste dinamiche
250
250
90-percentile PRT [se
90-percentile PRT [sec]
Client-side
PRT
per
pagine
(al variare
Client-side
PRT
per
pagine dinamiche
statiche e dinamiche
del numero diSistema
back-end)
- Carico
singolo
server HEAVYDYN
200
150
100
50
230
Statiche
210
Dinamiche
190
170
0 150
Carico 1HIGH
Statiche
232,7
90-perc.PRT 83,5
2Carico MID
3
218,7 83,9
218,5
143,1
Dinamiche
Carico
4 LOW5
8
92,4 197,2
206,7
220,5
189,1
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
90-percentile Server-side
PRT [msec]
160
25
140
20
120
100
15
80
10
60
40
5
20
0
2
3
4
5
8
PRT HighClass
135,7
110
86,8
68,8
45,6
PRT LowClass
157,9
113,6
87,6
69,9
45,4
27
16,3
10,3
5,8
1,5
% Rifiut. Low
% conn. LowClass
rifiutate
30
180
0
# nodi server
La politica SwitchPriority riesce a garantire il SLA
nel Server-side PRT solamente per sistemi ad alto
numero di nodi
z
z9
z
z
Risultati dell’analisi simulativa: QoWS
Server-side
Page
Response
Time
Server-side PRT
e connessioni
rifiutate
Dispatching
Carico ServerPart
HIGH
ServerPart 8 High
180
25
160
0,8
140
0,7
120
0,6
100
20
15
80
0,5
10
60
0,4
40
0,3
20
0,2
0
5
94,9
70,9
13,7
6,9
3,1
20
# nodi server
18
0
137,4
24
16
0
175,5
% Rifiut. Low
14
0
0 LowClass
PRT
12
0
8
33,2
10
0
5
46,9
80
4
47,4
60
3
47,3
40
0,1
PRT HighClass
0
30
0
20
0
90 -percentile Server-side PRT
[msec]
Frequenza cumulativa PR
0,9
SwitchPri 8 High
200
% conn. LowClass rifiutate
1 server
1
PRT [msec]
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
z
z10
z
z
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
z
z11