Web switch - Università degli Studi di Roma "Tor Vergata"

Transcript

Università degli Studi di Roma “Tor Vergata”
Facoltà di Ingegneria
Sistemi Web distribuiti
Corso di Sistemi Distribuiti
Valeria Cardellini
Anno accademico 2009/10
Quali risorse Web?
• Risorse statiche
– Contenuto è relativamente stabile nel tempo (es., file HTML,
immagini, archivi, …)
• Risorse volatili
– Contenuto viene modificato di frequente: periodicamente o
da eventi in corso (news, eventi sportivi, titoli di borsa, …)
• Risorse dinamiche
– Contenuto creato dinamicamente (on-the-fly) sulla base
della richiesta del client (motori di ricerca, shopping online,
…)
• Risorse multimediali
– Contenuti audio/video con dimensioni tipicamente maggiori
rispetto ad altri tipi di risorse (video clip, mp3, animazioni
Flash, …)
• Risorse sicure
– Contenuti trasferiti su un canale cifrato (HTTPS)
SD - Valeria Cardellini, A.A. 2009/10
2
Quali requisiti per il sistema Web?
• Dipendenti dal tipo di risorsa
• Risorse statiche
– Nessun problema particolare, a meno che non siano di
grandi dimensioni
• Risorse volatili
– Costo dipendente dalla frequenza degli aggiornamenti;
possibilità di usare metodi push-based e fragment-based
• Risorse dinamiche
– Accesso a basi di dati; costo computazionale elevato
• Risorse multimediali
– 2 metodi per gestire risorse multimediali: download-and-play
(HTTP) e play-during-download (RTP)
– Elevati requisiti di banda per entrambi (dimensione delle
risorse); maggiore costo computazionale di play-duringdownload
• Risorse sicure
– Trasferimento di risorse di qualunque tipo su canali cifrati
per esigenze di protezione e privacy; elevato costo
computazionale
3
Quali generazioni del Web?
• Web di prima generazione: Web publishing
– Risorse statiche
– Contenuti prodotti dal content provider
– Anche Web 0.0
• Web di seconda generazione: Web-based information
system
– Anche risorse volatili, dinamiche e sicure
– Contenuti prodotti dal content provider
– Anche Web 1.0
• Web di terza generazione: social Web, mobile Web
– Anche risorse multimediali
– Contenuti prodotti dal content provider e dagli utenti (anche
mobili)
– Anche Web 2.0
4
Quali tipi di siti?
•
Siti tradizionali
– Comunicazione monodirezionale e non interattiva
– Prevalenza di risorse statiche, pochi servizi dinamici, pochi
contenuti multimediali
•
Siti multimediali
– Presenza di molte risorse multimediali
•
Siti di informazione/shopping online
– Risorse volatili, soggette a rapidi cambiamenti
– HTML spesso generato dinamicamente
– Presenza di contenuti personalizzati (complica la generazione
dinamica)
– Sicurezza per le transazioni
•
Siti di social networking
– Siti di scambio di informazioni tra membri di comunità online (blog,
wiki, sharing - Facebook, YouTube, Flickr, …)
– Quasi ogni pagina generata dinamicamente (persino post in
database!)
– Autenticazione e personalizzazione
5
Perché sistemi Web distribuiti?
• Successo del Web
– Siti Web popolari soggetti a centinaia di milioni di richieste
ogni giorno
– Per statistiche: http://www.alexa.com/
• Evoluzione dei servizi basati sul Web
– Servizi sempre più complessi con crescente carico
computazionale
• Maggiori aspettative degli utenti
– Regola degli X secondi
• X=8, definita nel 2001
• X=4, analisi del 2006 sponsorizzata da Akamai
6
Componenti del ritardo Web
Web client
DNS server
Web server
DNS query
Address
resolution delay
Client delay
DNS reply
SYN j
SYN k, ACK j+1
Connection delay
Client delay
Network delay
ACK k+1
HTTP request
Server delay
HTTP response
Network delay
Dov’è il collo di bottiglia?
Dov’è il collo di bottiglia?
(1) DNS?
(3) Rete?
t
(2) Client?
(4) Piattaforma server?
7
Potenziamenti del Web
• Azioni a livello del CLIENT
– Possibilità di intervento limitato
• Azioni a livello di RETE
• Azioni da parte del CONTENT/SERVICE PROVIDER
– Replicazione dei server
– Caching
Focus
• Azioni da parte di INTERMEDIARI
– Caching cooperativo (istituzionale o ISP)
– Content Delivery Network (commerciale)
8
Ottimizzazioni dal lato server
Scale-up
Miglioramenti hw/sw
Scale-out
Sistemi con
server multipli
(Web/cache)
LAN
WAN
9
Scale-up e scale-out
• Scale-up software
– Interventi a livello del SO
• Evitare copie multiple dello stesso oggetto, politiche di
scheduling diverse da round-robin (ad es. SRTF)
– Interventi a livello del server Web
• Apache 2.2, lighttpd, Zeus Web server
• Scale-out
– A livello di content/service provider
• Distribuzione locale dei server
• Distribuzione globale dei server
• Integrazione con meccanismi di caching
Focus
– A livello di intermediari
• Caching cooperativo
• Content Delivery Network
10
Sistemi Web distribuiti
Distribuzione locale
Web cluster
Distribuzione globale
Web multi-cluster
11
Cluster (in generale)
• Definizione: “A cluster is a type of parallel or
distributed processing system, which consists of a
collection of interconnected stand-alone computers
cooperatively working together as a single, integrated
computing resource.” [Rajkumar Buyya]
• Un insieme di elementi di elaborazione che:
– cooperano in modo asincrono
– comunicano mediante una rete di interconnessione per
risolvere velocemente problemi (di grandi dimensioni)
• E’ l’“unità” di calcolo fondamentale e più diffusa per i
servizi applicativi moderni
– Se occorre maggiore potenza computazionale: multicluster ovvero molteplici cluster distribuiti geograficamente
Focus sull’uso dei cluster in ambito Web
12
Sistemi Web distribuiti (2)
Sistemi Web scalabili basati su
piattaforme con server multipli
• Meccanismo di instradamento (routing) per indirizzare le
richieste client al nodo “migliore”
• Algoritmo di distribuzione (dispatching) per individuare il nodo
“migliore”
• Un componente esecutore per eseguire l’algoritmo di
distribuzione utilizzando il relativo meccanismo di routing
13
Architetture per Web cluster
Front-end
server(s)
Web switch
144.55.62.18
(VIP)
LAN
Web
servers
Replicazione orizzontale
Replicazione verticale
Front-end
server
Web
server(s)
Web
application
server(s)
Back-end
server(s)
Router/
Firewall
LAN
(Presentation
logic)
(Business
logic)
(Transaction
server/
Data server)
Con tutte le possibili combinazioni…
14
Architetture per Web cluster:
una miriade di tecnologie (complesse)
Front-end
server(s)
Network/OS technology
Web switch
144.55.62.18
(VIP)
LAN
Web server technology
Web
servers
Web
application
servers
Middleware technology
Database technology
Back-end
servers
Web cluster
15
Web cluster
• Architettura parallela o distribuita localmente che
fornisce un’applicazione Web
– Caratteristiche di trasparenza e scalabilità
• Indirizzi del Web cluster
– Un solo nome logico (es., “www.foo.it”)
– Un solo indirizzo IP (virtual IP address o VIP)
• Web switch: nodo di front end del cluster
– Indirizzo IP dello switch = indirizzo IP del Web cluster
• Nodi interni del cluster
– Indirizzi IP dei nodi non visibili all’esterno
16
Richiesta HTTP ad un Web cluster
Client
browser
risorsa Web
(5)
richiesta HTTP
(4)
(1)
Internet
Web cluster
(3)
144.55.62.18
(2)
root
name server
www.site.org?
name server
locale
Fattori da considerare:
name server autoritativo
per www.site.org
• Caratteristiche del Web switch
• Flusso dei pacchetti di risposta
17
Web switch
• Componente di rete con ruolo di dispatcher
– Anche detto traffic switch (non solo traffico Web)
• Mapping da VIP ad indirizzo IP di un server
• Distribuzione delle richieste a granularità fine
– A livello di pacchetto TCP o richiesta HTTP
• Implementazioni alternative
– Dispositivo hardware special-purpose
– Modulo software eseguito a livello kernel (SO specialpurpose)
– Modulo software eseguito a livello applicativo (SO generalpurpose)
18
Web switch (2)
• Due architetture alternative in base al livello dello
stack ISO/OSI in cui lo switch opera
• Web switch di livello 4
– E’ content information blind
– Informazioni disponibili: sorgente e destinazione indirizzo IP,
numeri di porta TCP, SYN/FIN bit nell’header TCP
• Web switch di livello 7
– E’ content information aware
– Informazioni disponibili: URL, cookie, altri header HTTP,
identificativo SSL, …
Uno switch consente di gestire non solo traffico Web
– Nel corso focus su traffico Web
– Web switch anche detto traffic switch, application switch, …
• Anche manager anziché switch
19
Architetture per Web cluster
One-level routing
(centralizzato)
Fase di
richiesta
Web switch
Web switch
(Livello 4)
Two-way
Packet
rewriting
Packet
forwarding
One-way
Packet
tunneling
Web switch
(Livello 7)
Two-way
TCP gateway
TCP splicing
One-way
TCP handoff
TCP conn. hop
20
Architetture per Web cluster (2)
Classificazione delle architetture basata su:
•
•
Livello dello stack OSI a cui opera il Web switch
Percorso seguito dai pacchetti
–
–
I pacchetti in ingresso (inbound) passano sempre dallo switch
I pacchetti in uscita (outbound)
• Passano anche dallo switch: architetture two-way
•
•
Transitano attraverso un’altra connessione: architetture oneway
Meccanismo di routing utilizzato dal Web switch per reindirizzare i pacchetti inbound verso i server
•
Ad esempio: packet rewriting, TCP handoff
21
Web switch di livello 4
• Opera a livello TCP/IP
• Gestione della connessione TCP
– Pacchetti appartenenti alla stessa connessione TCP devono
essere assegnati allo stesso server
– Il Web switch utilizza una binding table per la gestione delle
connessioni TCP attive
– Il Web switch esamina l’header di ogni pacchetto:
• nuova connessione (SYN)
assegnamento del server
• connessione esistente
ricerca nella binding table
22
Architetture di livello 4 two-way
• Packet double-rewriting
Web
server 1
Web
server 2
144.55.62.18
(VIP)
Richiesta
Internet
Client
browser
Risposta
Web
server 3
LAN
Web switch
Web
server 4
144.55.62.18
Web
server 5
www.site.org?
DNS server locale
DNS server autoritativo
per www.site.org
23
Architetture di livello 4 two-way (2)
Packet double-rewriting
• Ogni server ha il suo indirizzo IP privato
– I pacchetti in uscita devono riattraversare il Web switch
– Web switch modifica dinamicamente sia i pacchetti entranti sia
quelli uscenti
• Indirizzo IP destinazione dei pacchetti entranti
(VIP ! IP server)
• Indirizzo IP sorgente dei pacchetti uscenti
(IP server ! VIP)
• Ricalcolo dei checksum IP e TCP
Tecnica basata sul meccanismo di
Network Address Translation (NAT)
24
Architetture di livello 4 one-way
• Packet single-rewriting
• Packet forwarding
• Packet tunneling
Web
server 1
Risposta
Client
browser
Richiesta
Internet
144.55.62.18
(VIP)
Web
server 2
Web
server 3
LAN
Web switch
Web
server 4
144.55.62.18
Web
server 5
www.site.org?
DNS server locale
DNS server autoritativo
per www.site.org
25
Architetture di livello 4 one-way (2)
Packet single-rewriting
– Lo switch modifica solo i pacchetti entranti
– Il server modifica i pacchetti in uscita (IP server ! VIP)
Packet forwarding
– Non c’è modifica dei pacchetti TCP/IP entranti ed uscenti:
l’inoltro avviene a livello MAC (ri-indirizzamento del frame MAC)
– Indirizzo VIP condiviso da Web switch e server (disabilitare
ARP per VIP sui server)
– PRO: minor overhead sullo switch per pacchetto
– CONTRO: Web switch e server sulla stessa sottorete fisica
Packet tunneling
– Lo switch incapsula il pacchetto IP del client in un altro
pacchetto IP, il cui header contiene: VIP come indirizzo IP
sorgente e indirizzo server come indirizzo IP destinatario
– Indirizzo VIP condiviso (come packet forwarding)
26
Web switch di livello 7
• Opera a livello applicativo
• Deve stabilire la connessione TCP con il client ed
attendere la richiesta HTTP
• Ispeziona il contenuto della richiesta HTTP per decidere
a quale server inoltrarla
– Parsing della linea di richiesta e degli header HTTP
– Gestione dei pacchetti inbound (ACK)
• Principali caratteristiche del content-based routing
– Consente il partizionamento dei contenuti/servizi del sito Web tra
diversi server (eventualmente specializzati)
– Favorisce l’utilizzo di meccanismi di caching
– Supporta il dispatching a granularità fine delle richieste HTTP
effettuate tramite connessioni persistenti
27
Decisione sull’assegnamento a livello 4 e 7
• Livello 4: alla ricezione del segmento TCP con flag SYN
• Livello 7: alla ricezione della richiesta HTTP
28
Architetture di livello 7 two-way
• TCP gateway (livello applicativo)
– Il Web switch è realizzato mediante un proxy
• Forwarding dei dati a livello applicativo
– Overhead elevato
• Ogni richiesta/risposta attraversa sullo switch tutto lo stack di
protocolli (data link " application " data link)
• TCP splicing (livello di SO)
– Ottimizzazione del TCP gateway
• Forwarding dei dati a livello TCP
• Splicing: giunzione a livello kernel di 2 connessioni TCP separate
– Il primo pacchetto determina la scelta del server e l’instaurazione
della connessione persistente fra il Web switch ed il server scelto
– I pacchetti successivi sono trasmessi dal Web switch a livello
TCP
– Richiede modifiche del kernel del SO del Web switch
29
Architetture di livello 7 one-way
• TCP handoff (livello di SO)
– Il Web switch passa (handoff) la connessione TCP al server
scelto, che gestisce il servizio ed invia direttamente la risposta
al client
– Richiede modifiche del kernel dei SO del Web switch e dei
server
Server
Client
User level
(1)
(4)
Dispatcher
(5)
Kernel
(2)
Handoff
TCP/IP
(3)
TCP/IP
conn req
ack
conn req
Forward
Handoff
TCP/IP
handoff req
ack
response
Client
Web switch
Target server
30
Architetture di livello 7 one-way (2)
• Ottimizzazione del TCP handoff per aumentare la
scalabilità
– Lo switch (centralizzato) inoltra i pacchetti TCP al
componente distributore (distribuito sui server)
– Il dispatcher (centralizzato) sceglie il server
– Riferimento:
• M. Aron et al., “Scalable content-aware request
distribution in cluster-based network servers”, Proc. of
USENIX 2000.
31
Algoritmi di distribuzione nei sistemi Web
• Due classi di algoritmi di distribuzione
Nullo
– Dinamici (state aware)
• Informazioni sui client (client info aware)
• Informazioni sullo stato dei server (server state
aware)
• Informazioni sui client e sullo stato dei server (client
info & server state aware)
Livello di informazioni di stato
– Statici (stateless)
Elevato
32
Algoritmi statici vs. dinamici
Dinamici
Statici
•
Facile implementazione
•
Implementazione più
complessa
•
Overhead trascurabile
(sullo switch)
•
•
Possibili situazioni di
sbilanciamento del carico
Overhead di comunicazione
(tra switch e server) e di
computazione (sullo switch)
•
Miglior bilanciamento del
carico a parità di politica
adottata
33
Confronto meccanismi di distribuzione
• Livello 4
– Livello connessione TCP
– Algoritmi di distribuzione content blind
– Algoritmi statici e dinamici
• Livello 7
– Livello connessione applicativa (HTTP)
– Algoritmi di distribuzione content aware
– Algoritmi dinamici
• Almeno client info aware (occorre usare l’informazione
contenuta nella richiesta del client!)
34
Distribuzione a livello 4
• Non servono algoritmi particolarmente sofisticati
• Esempi di algoritmi statici:
– Random, Round Robin (assegnamento circolare)
• Esempi di algoritmi dinamici server state-aware:
– Attuano una distribuzione delle richieste in base allo stato di
carico dei server
– Least loaded, Weighted Round Robin
• Algoritmi statici o dinamici?
– Prestazioni degli algoritmi statici confrontabili a quelle di
algoritmi dinamici nel caso di richieste Web il cui tempo di
servizio rientra in intervalli temporali di 2 ordini di grandezza
– Oltre i 2 ordini di grandezza, conviene utilizzare algoritmi
dinamici
35
Distribuzione a livello 7
• Esempi di algoritmi dinamici client info aware
– Identificatore di sessione, partizionamento del contenuto
• Esempi di algoritmi client info & server state aware
– Locality Aware Request Distribution (LARD)
36
Algoritmi L7 client info aware
• Identificatori di sessione
– Richieste HTTP con stesso SSL id o stesso cookie assegnate
allo stesso server
• Partizionamento del contenuto tra i server
– In base al tipo di risorsa (HTML, immagini, contenuto dinamico,
audio, video, …)
• Obiettivo: utilizzare server specializzati per contenuti differenti
– In base alla dimensione della risorsa
• Obiettivo: aumentare la condivisione del carico (load sharing)
• Soglie di partizionamento determinate staticamente o
dinamicamente
• Difficoltà: dimensione nota solo per risorse statiche, da stimare per
risorse dinamiche
– In base ad una funzione hash applicata sul path della risorsa
• Obiettivo: aumentare il cache hit rate nei server Web
37
Algoritmi L7 client info & server state aware
• Locality Aware Request Distribution (LARD)
– Considera sia il tipo di richiesta/servizio sia lo stato di carico
dei server Web
– Ha l’ulteriore obiettivo di aumentare il cache hit rate dei
server Web
– Riferimento:
• V.S. Pai et al., “Locality-aware request distribution in clusterbased network servers”, ASPLOS 1998.
A A A A A
server
cache
A A A C B C A A C B
switch
cache
C B C C B
server
38
Linux Virtual Server (LVS)
• Software open-source per realizzare un Web cluster
http://www.linuxvirtualserver.org/, http://kb.linuxvirtualserver.org/
– Switching a livello 4: modulo IPVS nel kernel 2.6 di Linux
• LVS/NAT: double packet rewriting
• LVS/TUN: packet tunneling
• LVS/DR: packet forwarding
– Switching a livello 7: sottoprogetti (sperimentali)
• KTCPVS: livello applicativo nel kernel
• TCPHA: TCP handoff
• TCPSP: TCP splicing
• Caratteristiche salienti
– Scalabilità
– Elevata disponibilità
– Configurazione LAN e WAN
39
Prodotti commerciali per Web cluster
• Alcuni prodotti commerciali
–
–
–
–
–
–
–
–
Citrix NetScaler
Cisco Application Control Engine
F5 Networks’ BIG-IP Local Traffic Manager
Brocade (ex Foundry Networks) ServerIron
Nortel Application Switches
Radware AppDirector
Resonate Central Dispatch
Zeus Extensible Traffic Manager
• (Tranne Zeus) Dispositivi harware special-purpose
che svolgono anche task CPU-intensive (quali
crittografia e decrittografia SSL e gestione delle
sessioni TCP) e caching
• Trend in corso: Web switch da load balancer ad
application delivery controller
40
Oltre il front-end tier…
• Fino ad ora abbiamo
analizzato la
replicazione orizzontale
nel front-end tier (Web
server)
• La replicazione
orizzontale può essere
attuata anche nei livelli
più interni:
– middle tier, composto da
application server
– back-end tier, composto
da database server
Front-end
server(s)
Web switch
144.55.62.18
(VIP)
LAN
Web
servers
Web
application
servers
Back-end
servers
WEB CLUSTER
41
Replicazione del middle tier
• Obiettivo del dispatching per il middle tier: scegliere
l’application server
• Granularità del dispatching: intera richiesta
• Dispatching attuato
– da un’entità centralizzata interposta tra front-end e middle
tier
– oppure in modo distribuito da ciascun server Web
• Dispatching implementato in molti prodotti
commerciali usando semplici politiche di distribuzione
(varianti di round-robin, weighted round-robin, least
loaded)
• Ad esempio, per Apache e Tomcat:
– Connettore JK
– Dispatching tramite mod_proxy di Apache
42
Replicazione del back-end tier
• Il DB (o più in generale l’applicazione di back-end)
può consentire di essere eseguito su più nodi
– Replicazione del DB (completa o parziale) su più repliche
identiche
– Distribuzione generalmente trasparente al middle tier (non vi
è dispatching esplicito)
• Problema:
– Mantenere la consistenza dei dati nel DB replicato e la
tolleranza ai guasti
– Come? Soluzioni già esaminate
43
Caching e clustering del back-end tier
• Per incrementare ulteriormente le prestazioni, si può
integrare la replicazione del back-end tier con
meccanismi di caching dei risultati delle query
– Utile nel caso di database read-intensive
– Ad es. il progetto open source memcached (usato ad es. da
Youtube, Flickr)
• In alternativa alla replicazione del DB, si può usare un
middleware per gestire un RAIDb (Redundant Array of
Inexpensive Databases )
– Ad es. il progetto open source Continuent Tungsten
44
Sommario caratteristiche Web cluster
• Architetture alternative (front-end tier)
– Web switch livello 4 vs. Web switch livello 7
– One-way vs. two-way
• Principali vantaggi
– Controllo a granularità fine sull’assegnamento delle richieste
– Elevata affidabilità (disponibilità, sicurezza)
• Principali svantaggi
– Presenza di single point of failure (il Web switch)
– Scalabilità limitata dal Web switch
– Scalabilità limitata dalla banda di accesso ad Internet (ad es.
T3 # 45 Mbps)
• Soluzione
– Replica su scala geografica (global scale-out)
45
Delivery su scala geografica
• Il content/service provider ha due possibilità per
distribuire i propri contenuti/servizi su scala
geografica in modo efficiente e scalabile:
– Il provider possiede e gestisce l’intera piattaforma o delega
la gestione della piattaforma ad uno o più data center
(sistemi Web distribuiti geograficamente)
– Il provider gestisce solo i contenuti/servizi ma delega ad una
terza parte il servizio di delivery dei contenuti/servizi agli
utenti (Content Delivery Network)
46
Sistemi con server Web multipli
Distribuzione locale
Web cluster
Dispatching
a livello 4 (OSI)
Dispatching
a livello 7 (OSI)
Distribuzione geografica
Web multi-cluster
Siti Mirror
Dispatching
in 2 fasi
(DNS+
Web switch)
Dispatching
in 3 fasi
(DNS+
Web switch+
server)
47
Sistemi Web distribuiti geograficamente
• Problemi di rete per sistemi Web distribuiti
localmente
– Scalabilità limitata dalla banda di accesso ad Internet
– Incapacità di evitare i link di rete congestionati
– Affidabilità della rete
• Scale-out globale
– Maggiore complessità dell’architettura
• Meccanismi di routing ed algoritmi di distribuzione
• Difficoltà nella gestione dell’infrastruttura
– Come selezionare il cluster “migliore”?
– Dove posizionare i cluster?
48
Web multi-cluster
• Sito Web implementato su di un’architettura di Web
cluster distribuiti geograficamente in diverse regioni
Internet
• Meccanismo di routing delle richieste basato sul DNS
– Indirizzi del sito Web
• Un unico hostname al quale corrisponde molteplici indirizzi IP, tanti
quanti sono i Web cluster
• L’indirizzo IP fornito dal DNS autoritativo corrisponde al VIP dello
switch del cluster selezionato
• Il DNS autoritativo del sito Web seleziona un cluster
nella fase di address lookup mediante un algoritmo di
tipo:
–
–
–
–
–
Round-robin
Prossimità di rete o geografica
Carico dei cluster
Prossimità e carico dei cluster
Altro ...
49
Sistemi Web geograficamente distribuiti
Siti mirror
Web multi-cluster
Dispatching
a 2 livelli
Centralizzato
DNS autoritativo
Livello 1
Livello 2
Dispatching
a 3 livelli
Livello 1
Livello 2
Livello 3
Centralizzato
Distribuito
Web switch
Web server
50
Web multi-cluster (2 livelli)
• Un unico hostname per il sito
• Un indirizzo IP per cluster
Web switch 1
104.32.11.102
Richiesta HTTP
Web switch 3
86.104.34.28
Web switch 2
120.88.41.54
Risorsa Web
www.site.com?
DNS locale
Web switch 4
26.38.98.10
<120.88.41.54,TTL>
DNS autoritativo
per www.site.com
51
Dispatching di primo livello
(mediante DNS)
• Il primo livello di distribuzione geografico avviene nella
fase di risoluzione dell’indirizzo (address lookup):
– il client richiede l’indirizzo IP del cluster corrispondente
all’hostname indicato nell’URL
– se l’hostname è valido, il client riceve la coppia
< Indirizzo IP, Time-To-Live>
da:
• cache di qualche name server locale o intermedio
• oppure DNS autoritativo del sito, opportunamente
modificato (integrato o meno da altro componente). Può
applicare diverse politiche di dispatching per selezionare il
Web cluster “migliore”
• Soluzione anche detta “redirezione DNS”
52
Algoritmi di dispatching per DNS
DNS-based dispatching
Static
Client info aware
Internet domain
Cluster state aware
Cluster load
Client info & cluster state aware
Internet domain
Cluster load
53
Prossimità in Internet
• La prossimità in Internet è un problema interessante: la
prossimità geografica tra client e server non implica
prossimità Internet
• Valutazione statica della prossimità
– indirizzo IP del client per determinare la zona Internet (simile a
distanza geografica)
– numero di hop (informazione “stabile” più che “statica”)
• network hop (ad es. traceroute)
• Autonomous System hop (query delle tabelle di routing)
Non garantisce la selezione del cluster migliore:
“links are not created equal”
54
Prossimità in Internet (2)
• Valutazione dinamica della prossimità
– round trip time (ad es. ping, tcping)
– bandwidth disponibile (ad es. pathChirp,
http://www.icir.org/models/tools.html per una lista più completa)
– latenza delle richieste HTTP (es., request emulation)
Tempo aggiuntivo e costi di traffico per la valutazione
• Un problema ancora aperto: correlazione tra numero di
hop e round trip time?
– Misure “vecchie” (1995): prossima a zero
– Misure “recenti” (dal 2000): mediamente elevata
55
Problemi del dispatching geografico
(di cui le politiche di dispatching devono tener conto)
•
Picchi di carico in alcune ore/giorni
Problemi aggiuntivi
•
Traffico dipendente dai fusi orari
•
Distribuzione non uniforme dei client
tra le regioni Internet
• Prossimità Internet tra client e Web cluster
Connessioni da
una Regione
Problemi tipici del dispatching Web
Ora del giorno
56
Problemi del dispatching tramite DNS
• Oltre ai problemi del dispatching geografico…
• Controllo limitato sulla risoluzione delle richieste di
indirizzo
– Nel caso di siti Web molto popolari, il DNS autoritativo
controlla solo il 5% del traffico in arrivo al sito
– Perché? A causa del caching hostname-indirizzo IP nei
name server locali e intermedi per l’intervallo del Time-ToLive
– Come risolvere il problema?
• Usando un TTL prossimo a zero, ma…
• Usando a livello del DNS autoritativo algoritmi di dispatching
sofisticati (ad es. TTL-adattativi)
• E’ comunque un meccanismo di distribuzione
content-blind
57
Come risolvere i problemi del dispatching DNS
• Fase di risoluzione dell’indirizzo: integrare il
dispatching attuato dal DNS autoritativo con quello
effettuato da un’altra entità
• Fase di richiesta della risorsa Web: integrare il
dispatching centralizzato attuato dal DNS autoritativo
con dispatching distribuito da parte dei cluster
– Alcuni meccanismi di re-routing delle richieste:
• Ridirezione HTTP
• IP tunneling
• URL rewriting
58
Dispatching per Web multi-cluster
• Indirizzi del sito Web visibili
– Un unico hostname (ad es., “www.site.com”)
– Un indirizzo IP per ogni Web cluster
• Livelli multipli di routing e dispatching:
– DNS autoritativo seleziona il Web cluster “migliore”
(dispatching inter-cluster)
– Web switch del cluster seleziona il Web server “migliore”
(dispatching intra-cluster)
– Ciascun Web server (o Web switch di livello 7) può
ridirigere le richieste verso un altro Web cluster, ad es. per
risolvere situazioni temporanee di sovraccarico (dispatching
inter-cluster)
– Per semplificare, non consideriamo gli ulteriori livelli di
dispatching interni al cluster
59
Web multi-cluster (3 livelli)
Web switch 1
104.32.11.102
Web switch 3
Web switch 2
86.104.34.28
120.88.41.54
Prima “HTTP request”
Go To 86.104.34.28 Seconda “HTTP request”
Risorsa Web
www.site.com
Local DNS
(120.88.41.54,TTL)
Web switch 4
26.38.98.10
Authoritative DNS
for www.site.com
60
Motivazioni per terzo livello di dispatching
Web multi-cluster con due livelli di dispatching
– Controllo elevato sul carico che raggiunge il Web cluster (buon
bilanciamento intra-cluster)
– Ma reazione lenta ad un cluster sovraccarico (cattivo
bilanciamento inter-cluster)
Web multi-cluster con tre livelli di dispatching:
• Reazione immediata per spostare il carico da un Web
cluster sovraccarico
• Quale meccanismo di ridirezione? HTTP redirection
61
Ridirezione HTTP
• Supportato dai browser (parte del protocollo HTTP)
• “New location”
– ridirezione ad un indirizzo IP (prestazioni migliori ma no
trasparenza)
– ridirezione ad un hostname
HTTP message header
HTTP status code
302 - “Moved temporarily” to a new location
• DNS e Web switch: usano politiche di dispatching
centralizzate
• Ridirezione: usa politiche di dispatching distribuite, in cui
tutti i server Web (o i Web switch) possono partecipare al
(ri)assegnamento delle richieste
62
Ridirezione HTTP: pro e contro
PRO
• Compatibile con tutti i client e server Web
• Meccanismo distribuito che soddisfa requisiti di affidabilità
(no “single point of failure”)
• Distribuzione delle richieste content-aware
CONTRO
• Limitata alla ridirezione di richieste HTTP (altri meccanismi
di ridirezione più generali, ad es. IP tunneling)
• Maggior traffico di rete: ogni richiesta ridiretta richiede
una nuova connessione TCP
Tuttavia, la ridirezione riduce il tempo di risposta quando
impatto del server > impatto della rete
63
Prodotti commerciali per Web multi-cluster
• Alcuni prodotti commerciali
–
–
–
–
–
Cisco ACE Global Site Selector
F5 Networks’ BIG-IP Global Traffic Manager
Radware AppDirector
Resonate Global Dispatch
Zeus Extensible Traffic Manager
• Supportano il dispatching di primo livello basato su
DNS, usando algoritmi basati su latenza, carico e
disponibilità
64
Piattaforma di Google
• Centinaia di migliaia di macchine (stima 450000)
organizzate in almeno 12 cluster distribuiti
geograficamente
– Nel 2002 Google usava 6000 processori e 12000 dischi, con 2
cluster nella Silicon valley e 2 in Virginia
• Ciascun cluster connesso ad Internet tramite una connessione
OC48 (2488 Mbit/sec)
• L’indice di Google comprende oltre 25 miliardi di URL
• Obiettivo: servire una richiesta in meno di 0,5 secondi
(ritardi di rete compresi!)
• I server sono commodity x-86 PC con una versione
customized di Linux
• Riferimenti
– http://research.google.com/pubs/papers.html
65
Distribuzione delle richieste in Google
• Come avviene la distribuzione delle richieste?
• Primo livello (tra cluster): redirezione DNS
– Carico dei cluster e prossimità rispetto al client
dig www.google.it
...
www.google.it.
www.google.com.
www.l.google.com.
www.l.google.com.
www.l.google.com.
www.l.google.com.
www.l.google.com.
...
343886
603084
36
36
36
36
36
IN
IN
IN
IN
IN
IN
IN
CNAME
CNAME
A
A
A
A
A
www.google.com.
www.l.google.com.
66.102.9.103
66.102.9.104
66.102.9.105
66.102.9.99
66.102.9.147
Come cambia la provenienza delle richieste in un giorno?
http://labs.google.com/papers/sawzall-20030814.gif
66
In un cluster di Google
• All’interno di un cluster di Google:
– Molteplici tier: Web switch, proxy server, Web server
(GWS), index server
– Ed ancora: tier di document server, ad server, spelling
server, …
67
Software nell’infrastruttura di Google
• Google Web Server (GWS)
• Google File System (GFS)
• Chubby
– Servizio di lock per SD lascamente accoppiati sviluppato per
gestire la sincronizzazione a granularità grossa
http://labs.google.com/papers/chubby.html
• BigTable
– Sistema di storage distribuito column-oriented ad alte
prestazioni (petabyte di dati e migliaia di macchine) basato
su Google File System, Chubby, ed altri software di Google
http://labs.google.com/papers/bigtable.html
• MapReduce
– Modello di programmazione e relativa implementazione per
processare e generare grandi insieme di dati
http://labs.google.com/papers/mapreduce.html
• Linguaggio di programmazione Sawzall
• Protocol buffers
68
Google File Sytem
• File system distribuito con vincoli
– File di dimensioni molto grandi ma contenenti moltissimi
oggetti più piccoli
– Aggiornamento aggiungendo dati alla fine del file
• Implementato in userspace
• File suddivisi in chunk (“grossi pezzi”) da 64MB
caiscuno, che sono memorizzati come normali file sui
chunk server
• Progettato per ottimizzare file di tipo “multiple-reader/
multiple-appender”
– I Crawler aggiungono dati a un file
– I Reader possono leggere il file contemporaneamente
– Non ci sono problemi di corse critiche o di disallineamento
• Ogni chunk è replicato su più macchine
– Replicazione gestita con schema primary-backup
69
Architettura di Google File System
Per approfondimenti: http://labs.google.com/papers/gfs.html
70

Web switch - Università degli Studi di Roma "Tor Vergata"

Transcript

Documenti analoghi

4pp - Università degli Studi di Roma "Tor Vergata"

RE FIORDILEGGE NEROCUORE PIEDALATI

Sistemi Distribuiti - A.A. 2009/10 Progetto 2 per modalità A di esame

Locandina

«Nel sorriso di Valeria» in aiuto dell`Africa

Sistemi Distribuiti e Cloud Computing

Soluzioni server e switch completamente integrate

Tecnica operativa in HF e DX Cluster

Web switch - Università degli Studi di Roma "Tor Vergata"

Centinaia di candele in piazza San Marco in ricordo