Web switch - CE group DISP - Università degli Studi di Roma "Tor

Transcript

Università degli Studi di Roma Tor Vergata
Dipartimento di Ingegneria Civile e Ingegneria Informatica
Sistemi Web distribuiti
Corso di Sistemi Distribuiti e Cloud Computing
A.A. 2015/16
Valeria Cardellini
Perché sistemi Web distribuiti?
•  Successo del Web
–  Alcuni siti soggetti a centinaia di milioni di richieste ogni
giorno
–  Classifica dei top site: www.alexa.com/topsites
•  Evoluzione dei servizi basati sul Web
–  Servizi sempre più complessi con crescente carico
computazionale
•  Aspettative degli utenti
–  Regola degli X secondi
•  X=8, definita nel 2001
•  X=4, analisi del 2006 sponsorizzata da Akamai
Valeria Cardellini - SDCC 2015/16
2
Components of the Web delay
Web client
Address
resolution delay
Client delay
Connection delay
Client delay
Network delay
DNS server
Web server
DNS query
DNS reply
SYN j
SYN k, ACK j+1
ACK k+1
HTTP request
Server delay
Network delay
HTTP response
Dov è il collo di bottiglia?
Where is the bottleneck?
DNS?
Network?
t
Client?
Server?
3
Strengthening Web performance
•  Actions on the client side
–  Improve Web site design, use HTML5, use HTTP/2
•  Actions on the network side
–  Partially done, but the grand challenge is the
Internet at the speed of light
•  Actions on the application provider side
Focus
–  Replicate the application and distribute the requests
–  Where to replicate?
•  In-house data centers, private Clouds, public Clouds,
Content Delivery Networks (CNDs)
4
Ottimizzazioni lato server
Scale-up (scalabilità verticale)
Miglioramenti hw/sw
Scale-out (scalabilità
orizzontale)
LAN
Sistemi con server multipli
(Web/cache)
WAN
5
Scale-up e scale-out: costo
Scale-up:
Costo esponenziale
Scale-out:
Costo lineare
LAN
WAN
6
Scale-up e scale-out: soluzioni
•  Scale-up software
–  Interventi a livello del SO
•  Esempi: evitare copie multiple della stessa risorsa, politiche di
scheduling diverse da round-robin (ad es. SRTF)
–  Interventi a livello del server Web
•  Ad es: Apache HTTP server 2.4, lighttpd (architettura eventdriven), nginx (I/O non bloccante)
•  Scale-out
–  A livello di application provider
• 
• 
• 
• 
Focus
Distribuzione locale dei server
Distribuzione globale dei server
Integrazione con meccanismi di caching
Soluzioni in-house, outsourced oppure Cloud-based
–  A livello di intermediari
•  Content Delivery Network
7
Sistemi Web distribuiti
Distribuzione locale
Web cluster
Distribuzione globale
Web geo-cluster
8
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: multi-cluster
ovvero molteplici cluster distribuiti geograficamente
Focus sull’uso dei cluster in ambito Web
9
Elementi per distribuire le richieste
Cosa occorre per distribuire le richieste
all’interno di un cluster?
•  Meccanismo di instradamento (routing) per indirizzare le
richieste client al nodo migliore
•  Algoritmo di distribuzione (dispatching) per individuare il nodo
migliore e bilanciare (o condividere) il carico di lavoro
•  Un componente esecutore per eseguire l’algoritmo di
distribuzione utilizzando il relativo meccanismo di routing
10
Traditional Web application
Web switch
144.55.62.18
(VIP)
•  Horizontal replication at multiple tiers
•  The most common architecture for Web applications,
widely deployed
•  Best practice: 3-tier shared nothing architecture
–  Save state out of server/component
–  Outage of a single server/component should not compromise the
whole system
11
Cloud-native application
Web switch
144.55.62.18
(VIP)
•  What do the two architectures have in common?
•  The load balancer tier!
12
Web cluster
•  Architettura distribuita localmente che fornisce
applicazioni Web
–  Caratteristiche di trasparenza e scalabilità
•  Indirizzi del cluster (per una singola applicazione)
–  Un solo nome logico (es., www.site.org )
–  Un solo indirizzo IP (virtual IP address o VIP)
•  Web switch: nodo (tier) 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
13
Richiesta a Web cluster
Risposta
(5)
Richiesta
(4)
(1)
Cluster
(3)
144.55.62.18
www.site.org?
DNS server root
(2)
DNS server locale
Fattori da considerare:
DNS server autoritativo
per www.site.org
•  Caratteristiche del cluster switch
•  Flusso dei pacchetti di risposta
14
Web switch
•  Componente di rete con ruolo di dispatcher
–  Anche noto come:
più comune
•  load balancer (1999)
•  traffic manager (2003)
•  application delivery controller (dal 2009)
•  Mapping da VIP ad indirizzo IP di un server interno al
cluster
•  Implementazioni alternative
–  Dispositivo hardware special-purpose
–  Modulo software eseguito a livello kernel (SO specialpurpose)
–  Modulo software eseguito a livello applicativo (SO generalpurpose)
15
Web switch (2)
•  Distribuzione delle richieste a granularità fine
–  A livello di pacchetto TCP o richiesta HTTP
•  Due architetture alternative in base al livello dello
stack ISO/OSI in cui lo switch opera
–  Switch di livello 4: content information blind
•  Informazioni disponibili: sorgente e destinazione indirizzo IP,
numeri di porta TCP, SYN/FIN bit nell header TCP
–  Switch di livello 7: 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
16
Architetture per Web cluster
One-level routing
(centralizzato)
Fase di
richiesta
Web switch
Web switch
(Livello 4)
Two-way
Packet
rewriting
One-way
Packet
forwarding
Packet
tunneling
Web switch
(Livello 7)
Two-way
TCP gateway
TCP splicing
One-way
TCP handoff
TCP conn. hop
17
Architetture per Web cluster (2)
Classificazione delle architetture basata su:
• 
• 
Livello dello stack OSI a cui opera il meccanismo di
routing
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
18
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
19
Architetture di livello 4 two-way
•  Packet double-rewriting
Cluster
node 1
Richiesta
Cluster
node 2
Cluster
node 3
144.55.62.18(VI
P)
LAN
Risposta
Web switch
Cluster
node n
144.55.62.18
Cluster
node 4
www.site.org?
DNS server locale
per www.site.org
20
Architetture di livello 4 two-way (2)
Packet double-rewriting (ovvero NAT)
•  Ogni nodo del cluster ha il suo indirizzo IP privato
–  I pacchetti in uscita devono riattraversare lo switch
–  Web switch modifica dinamicamente sia i pacchetti entranti sia
quelli uscenti
•  Indirizzo IP destinazione dei pacchetti entranti
(VIP → IP nodo scelto)
•  Indirizzo IP sorgente dei pacchetti uscenti
(IP nodo scelto → VIP)
•  Ricalcolo dei checksum IP e TCP
Tecnica basata sul meccanismo di
Network Address Translation (NAT)
21
Architetture di livello 4 one-way
•  Packet single-rewriting
•  Packet forwarding
Cluster
node 1
•  Packet tunneling
Risposta
Cluster
node 2
Cluster
node 3
144.55.62.18(VI
P)
LAN
Richiesta
Web switch
Cluster
node n
144.55.62.18
Cluster
node 4
www.site.org?
DNS server locale
per www.site.org
22
Architetture di livello 4 one-way (2)
Packet single-rewriting
–  Lo switch modifica solo i pacchetti entranti
–  Il nodo scelto modifica i pacchetti in uscita (IP nodo → 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 nodi (disabilitare ARP
per VIP sui nodi)
–  PRO: minor overhead sullo switch per pacchetto
–  CONTRO: Web switch e nodi 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 nodo come indirizzo IP destinatario
–  Indirizzo VIP condiviso (come packet forwarding)
23
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 nodo inoltrarla
–  Parsing della linea di richiesta e degli header HTTP
•  Principali caratteristiche del content-based routing
–  Consente il partizionamento dei servizi tra server diversi,
eventualmente specializzati
–  Favorisce l utilizzo di meccanismi di caching
–  Supporta il dispatching a granularità fine delle richieste HTTP
effettuate tramite connessioni persistenti
24
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
25
•  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)
26
•  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
•  Si evitano così gli overhead di context switching e memory copying
tra user space e kernel space
–  Il primo pacchetto determina la scelta del nodo e l instaurazione
della connessione persistente fra il Web switch ed il nodo scelto
–  I pacchetti successivi sono trasmessi dal Web switch a livello
TCP (quasi alla velocità di un router)
–  Richiede modifiche del kernel del SO del Web switch
•  Supporto per TCP splicing nel kernel di Linux a partire da 2.6.25
27
Architetture di livello 7 one-way
•  TCP handoff (livello di SO)
–  Il Web switch passa (handoff) la connessione TCP al nodo
scelto, che gestisce il servizio ed invia direttamente la risposta
al client
–  Richiede modifiche del kernel dei SO del Web switch e dei nodi
Server
Client
User level
(1)
(4)
Dispatcher
(5)
Kernel
(2)
Handoff
TCP/IP
Handoff
(3)
TCP/IP
conn req
ack
conn req
Forward
TCP/IP
handoff req
ack
response
Client
Web switch
Target server
28
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
29
Algoritmi statici vs. dinamici
Statici
•  Facile implementazione
•  Overhead trascurabile
(sullo switch)
•  Possibili situazioni di
sbilanciamento del carico
Dinamici
•  Implementazione più
complessa
•  Overhead di comunicazione
(tra switch e nodi) e di
computazione (sullo switch)
•  Miglior bilanciamento del
carico a parità di politica
adottata
30
Confronto meccanismi di distribuzione
•  Livello 4
–  Livello connessione TCP
–  Algoritmi di distribuzione application blind
–  Algoritmi statici e dinamici
•  Livello 7
–  Livello connessione applicativa (HTTP)
–  Algoritmi di distribuzione application aware
–  Algoritmi dinamici
•  Almeno client info aware (occorre usare l’informazione
contenuta nella richiesta del client!)
31
Distribuzione a livello 4
•  Esempi di algoritmi statici:
–  Random
–  Round Robin: assegnamento circolare
–  Static Server Weight: peso statico assegnato ai nodi in base alle
caratteristiche hw e poi random oppure round robin in modo
proporzionale ai pesi assegnati
•  Gli algoritmi statici possono essere integrati con un
meccanismo di health monitoring per escludere server
malfunzionanti
32
Distribuzione a livello 4 (2)
•  Esempi di algoritmi dinamici server state-aware:
–  Distribuzione delle richieste in base allo stato di carico dei nodi del
cluster
•  Vari indice di carico: utilizzazione CPU, throughput I/O, RAM
disponibile, numero di connessioni aperte, tempo di risposta, …
•  Stato di carico acquisito in modo diretto (comunicazione tra nodi e
Web switch) oppure in modo indiretto sul Web switch, a seconda
dell’indice di carico usato
–  Least Loaded: si sceglie il server con carico minimo: attenzione
all’herd effect! Meglio randomizzare su un sottoinsieme di nodi
–  Weighted Round Robin: peso dinamico assegnato ai nodi in base
allo stato di carico e round robin basato sui pesi
–  Energy-aware: algoritmi che ottimizzano il consumo di potenza
•  Algoritmi statici o dinamici?
–  Prestazioni confrontabili finché il tempo di servizio delle richieste
varia in 2 ordini di grandezza; oltre i 2 ordini di grandezza, meglio
algoritmi dinamici
33
Distribuzione a livello 7
•  Esempi di algoritmi dinamici client info aware
–  Identificatori di sessione (sticky session o session
persistence): richieste HTTP con stesso SSL id o stesso
cookie assegnate allo stesso server
–  Partizionamento del contenuto tra i server: ad es. in base al
tipo di risorsa (per utilizzare server specializzati) oppure
applicando una funzione hash sul path della risorsa (per
aumentare il cache hit rate nei server)
•  Esempi di algoritmi dinamici 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
34
Prodotti commerciali per Web cluster
•  Principali prodotti commerciali
–  Barracuda Load Balancer
–  Brocade Series ADX, Virtual Traffic Manager
–  Cisco Application Control Engine (ACE) e Content Service
Switch (CSS)
–  Citrix NetScaler
–  Fortinet FortiADC
–  F5 Networks’ BIG-IP Local Traffic Manager (LTM)
–  loadbalancer.org
–  Microsoft Network Load Balancing (NLB)
–  Radware AppDirector
–  Resonate Central Dispatch
35
Prodotti commerciali per Web cluster (2)
•  Tranne Microsoft NLB e Brocare Virtual Traffic
Manager, i prodotti commerciali sono dispositivi
hardware special-purpose
•  Oltre alla distribuzione delle richieste, svolgono
anche:
–  Task CPU-intensive: crittografia e decrittografia SSL (SSL
offloading), gestione di sessioni TCP
–  Compressione e caching dei contenuti
–  Protezione da attacchi di tipo DDoS
–  Obiettivi: ridurre il carico sui server, consolidare il cluster,
ridurre il consumo di banda di rete, migliorare la percezione
del servizio da parte degli utenti
36
Prodotti open source per Web cluster
•  Principali prodotti open source
–  HAProxy
•  usato ad es. da Airbnb, DISQUS, Fedora, GitHub, Instagram,
Reddit, Tumblr, w3.org
•  Performance: barrier of 100k HTTP req/s crossed in 2009!
–  Linux Virtual Server (LVS)
–  nginx
•  Server HTTP, in grado di servire un numero maggiore di
richieste concorrenti rispetto ad Apache (vedi Apache vs nginx)
•  Usato dal 17,4% dei siti, ad es. Netflix (vedi
Netcraft December 2015 Web Server Survey)
•  Può anche essere usato come load balancer
–  Perlbal
–  Pound
•  Operano tutti a livello software
37
Cloud-based load balancers
•  Amazon Elastic Load Balancing (ELB)
–  Distributes incoming application traffic across multiple
Amazon EC2 instances
–  Detects unhealthy instances within a pool and automatically
reroutes traffic to healthy instances (failover)
–  Supports sticky sessions to specific EC instances
–  Can also be used in an Amazon Virtual Private Cloud (VPC)
to distribute traffic between application tiers
•  Rackspace Cloud Load Balancer
–  User can choice the server to be balanced (not only Cloud
instances)
–  Some features: SSL termination at the load balancer,
session persistence across all protocols, node health
monitoring and failover protection, DDoS protection
–  Open source code
38
Cloud-based load balancers (2)
•  Google’s Network Load Balancing
–  Distributes incoming TCP/UDP traffic across multiple
Compute Engine instances
–  Layer 4 load balancing
–  Dispatching algorithm: client-info aware
•  Choose server based on hash of the source IP and port,
destination IP and port, and protocol
–  Instance health monitoring (based on HTTP) and failover
protection
39
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/storage server
40
Replicazione del middle tier
•  Obiettivo del dispatching per il middle tier: scegliere
un server del middle tier
•  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 diversi prodotti usando
semplici politiche di distribuzione (varianti di roundrobin, weighted round-robin, least loaded)
•  Esempi:
–  Per Apache HTTP server e Tomcat: connettore JK e
dispatching tramite mod_proxy di Apache
–  Eureka: servizio REST usato da Netflix per load balancing e
failover dei server nel middle tier
41
Replicazione del back-end tier
•  Il DB (o più in generale il tier di storage) può 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 (e relativi overhead):
–  Mantenere la consistenza dei dati e la tolleranza ai guasti
42
Caching e clustering del back-end tier
•  Per incrementare le prestazioni, si può integrare la
replicazione del back-end tier con meccanismi di caching
dei risultati delle query
–  Utile soprattutto se DB read-intensive (o mostly read)
–  Esempi: Memcached e redis
•  Per migliorare
disponibilità e
continuità di
servizio, si può
usare un
middleware per
gestire cluster di
DB, eventualmente
distribuiti
geograficamente
–  Esempio: VMware Continuent (ha un
motore di replicazione open source)
43
Memcached
•  Free and open source, used e.g., by
Flickr, Twitter, Wikipedia, Youtube
•  High-performance, distributed
memory object caching system
–  Generic in nature, but intended for use in
speeding up dynamic web applications by
alleviating database load
•  Provides in-memory key-value store
for small chunks of arbitrary data
(strings, objects) from results of
database calls, API calls, or page
rendering
•  API available for most languages
44
Example of Web cluster architecture: DISQUS
•  DISQUS (October 2010)
–  The largest Django app
–  Traffic: 17000 req/sec
•  Hw & sw architecture
–  100 server
–  30% web servers (Apache +
mod_wsgi)
–  10% databases (PostgreSQL)
–  25% cache servers
(memcached)
–  20% load balancing/high
availability (HAProxy +
heartbeat)
–  15% utility servers (Python
scripts)
See “Scaling DISQUS…” article
45
Example of Web cluster architecture: Facebook
•  High-level architecture of a Facebook cluster
•  sw in the Web tier: HipHop, Tornado, node.js
–  HipHop: trasforms PHP code in highly optimized C++ code
–  Tornado: non blocking server written in Python
–  Node.js: server-side JavaScript and event-driven I/O
•  Static content delivered by Akamai
•  Varnish as HTTP accelerator
–  Varnish is designed for content-heavy dynamic web sites as well
as heavily consumed APIs
46
Example of Web cluster architecture:
Facebook (2)
•  Persistence is done using MySQL, Memcached,
Hadoop’s HBase
-  Memcached is used as a cache for MySQL as well as a
general purpose cache
-  See “Scaling Memcache at Facebook” paper)
•  Offline processing is done using Hadoop and Hive
•  The description of hw architecture of Facebook data
center is publicly available at opencompute.org
–  “The result is a data center full of vanity free servers which
is 38% more efficient and 24% less expensive to build and
run than other state-of-the-art data centers.”
47
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) e
scalabilità limitata dal Web switch
•  Soluzione parziale: replicazione orizzontale+verticale del Web
switch è load balancer tier
–  Scalabilità limitata dalla banda di accesso ad Internet
–  Incapacità di evitare i link di rete congestionati
•  Soluzione
–  Replicare i cluster su scala geografica (global scale-out)
48
Delivery su scala geografica
•  Alternative disponibili ad un content/service provider
per distribuire i propri contenuti/servizi su scala
geografica in modo efficiente e scalabile:
–  Il provider possiede e gestisce l’intera piattaforma (soluzione
on-premise)
–  Oppure delega la gestione della piattaforma ad uno o più data
center
–  Oppure ad un IaaS o PaaS provider
–  In tutti questi casi: sistemi Web distribuiti geograficamente
–  Oppure 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 o equivalente servizio
Cloud a livello SaaS, ad es. Amazon CloudFront)
49
Mechanisms for geo-distributed Web systems
•  Global scale-out increases the complexity of the
overall architecture
•  Which request routing mechanisms?
–  We’ll mainly consider:
•  DNS redirection
•  Anycast
•  HTTP redirection
•  Which dispatching algorithms?
•  Where to locate the clusters?
50
Cluster vs multi-cluster
Distribuzione locale
Distribuzione geografica
Web cluster
Dispatching
a livello 4 (OSI)
Web multi-cluster
Dispatching
a livello 7 (OSI)
Dispatching
in 2 fasi
(inter-cluster+
intra-cluster)
Dispatching
in 3 fasi
(inter-cluster+
intra-cluster+
inter-cluster)
51
Redirezione DNS
•  Multi-cluster: l’applicazione Web è fornita da
un’architettura di Web cluster distribuiti geograficamente
in diverse regioni Internet
•  Meccanismo di routing delle richieste verso il cluster
“migliore” basato sul DNS
–  Indirizzi dell’applicazione Web
•  Unico hostname al quale corrispondono molteplici indirizzi IP, tanti
quanti sono i Web cluster
•  Indirizzo IP fornito dal server DNS autoritativo corrisponde al VIP
dello switch del cluster selezionato
–  Il routing avviene nella fase di address lookup -> è
application-blind
–  Soluzione anche nota come redirezione DNS
•  Il server DNS autoritativo seleziona un cluster
applicando un algoritmo di dispatching (o distribuzione)
delle richieste di risoluzione di indirizzo
52
Web multi-cluster (2 livelli)
•  Un unico hostname
•  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
Risposta
www.site.com?
DNS locale
Web switch 4
26.38.98.10
<120.88.41.54,TTL>
DNS autoritativo
per www.site.com
53
Dispatching di primo livello
(mediante DNS)
•  Il primo livello di distribuzione inter-cluster 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 DNS server locale o intermedio
•  oppure DNS autoritativo per l’applicazione,
opportunamente modificato per selezionare il cluster
migliore applicando un algoritmo di dispatching (o
distribuzione)
54
Algoritmi di dispatching per DNS
DNS-based dispatching
Static
Client info aware
Internet proximity
Cluster state aware
Cluster load
Client info & cluster state aware
Internet proximity
Cluster load
•  Alcuni esempi di algoritmi di dispatching attuati dal DNS
server autoritativo
-  Round-robin
-  Prossimità di rete tra client e cluster
-  Carico dei cluster
-  Combinazione di prossimità di rete e carico dei cluster
55
Prossimità in Internet
•  La prossimità geografica tra client e server non implica la
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 BGP)
Non garantisce la selezione del cluster migliore:
links are not created equal
56
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
57
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
58
Problemi del dispatching tramite DNS
•  Oltre ai problemi del dispatching geografico…
•  Meccanismo di distribuzione application-blind e a
granularità grossa
•  Server DNS autoritativo con controllo limitato sulla
risoluzione delle richieste di indirizzo:
–  Nel caso di siti molto popolari (e TTL standard di 1 giorno):
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 la durata del TTL
–  Come risolvere il problema?
•  TTL prossimo a zero per aumentare il controllo, ma causa overhead
sul DNS!
•  Algoritmi di DNS dispatching sofisticati (ad es. TTL-adattativi)
•  DNS anycast
59
An “old” problem for DNS redirection
•  The traditional DNS mapping system identifies a client
using the IP address of its local name server (LDNS)
–  The LDNS makes the recursive query for name resolution on
behalf of the client
–  But clients can be far from their LDNSes (even 8 hops!)
–  Problem: inaccuracy for the authoritative name server in
identifying the “proximal” replica that can be reached by the
client with low latency
•  New EDNS-client-subnet extension proposed by
Google and Akamai to overcome this difficulty
–  The DNS query contains information about the client that
originated it
tools.ietf.org/html/draft-ietf-dnsop-edns-client-subnet-00
60
Come risolvere i problemi del dispatching DNS
•  Alcune soluzioni (non alternative tra loro)
•  Fase di richiesta di risoluzione dell’indirizzo:
realizzare un infrastruttura scalabile di DNS autoritativo
(anycast o tipo infrastruttura DNS di Akamai) per poter
usare un TTL basso
•  Fase di richiesta dell’applicazione: aggiungere un altro
livello di dispatching integrando quello centralizzato
attuato dal DNS autoritativo con dispatching distribuito
da parte dei cluster
–  Occorre usare un meccanismo di re-routing delle richieste:
•  Redirezione HTTP
•  IP tunneling
•  URL rewriting
•  Redirezione RTSP (Real Time Streaming Protocol)
•  Redirezione SIP (Session Initiation Protocol)
61
Dispatching per Web multi-cluster
•  Indirizzi visibili dell’applicazione Web
–  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 nodo
migliore (dispatching intra-cluster)
–  Ciascun nodo (o Web switch di livello 7): può ridirigere le
richieste verso un altro cluster, ad es. per risolvere situazioni
temporanee di sovraccarico (dispatching inter-cluster o crosscluster)
–  Non consideriamo gli ulteriori livelli di dispatching interni al
cluster
62
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 richiesta HTTP
Go To 86.104.34.28 Seconda richiesta HTTP
Risposta
www.site.com?
DNS locale
Web switch 4
26.38.98.10
<120.88.41.54,TTL>
DNS autoritativo
per www.site.com
63
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 cluster
sovraccarico
•  Quale meccanismo di redirezione?
•  DNS e Web switch: usano politiche di dispatching
centralizzate
•  Redirezione: usa politiche di dispatching distribuite,
in cui i nodi del cluster possono partecipare al riassegnamento delle richieste
64
Redirezione HTTP
•  Supporto nativo nel protocollo HTTP
•  New location : come indicarla?
–  Indirizzo IP (prestazioni migliori ma no trasparenza)
–  Hostname
HTTP message header
•  Vantaggi
HTTP status code
302 - “Moved temporarily” to a new location
–  Compatibilità
–  Affidabilità (meccanismo distribuito, no single point of failure )
–  Distribuzione delle richieste application-aware
•  Svantaggi
–  Limitata alle richieste HTTP (altri meccanismi di redirezione più
generali, ad es. IP tunneling)
–  Maggior traffico di rete: ogni richiesta rediretta richiede una
nuova connessione TCP
Redirezione riduce tempo di risposta se
impatto del server > impatto della rete 65
Anycast
•  Anycast: point-to-point flow of packets between a
client and (at least) one replica, typically the nearest,
of a group of servers identified by the same anycast
address
–  One-to-one of many association
•  Idea: a client sends packets to any one of several
possible servers offering a particular service or
application but does not really care which one
•  How? A single anycast address is assigned to many
servers belonging to an anycast group
•  Client sends packets to an anycast address A and the
network attempts to deliver the packet to the closest
server with the matching anycast address A
66
Anycast in Internet
•  IP anycast: anycast service at network layer
–  Enables to assign the same IP address to multiple endpoints
•  From a network perspective, nothing special!
–  Same as having multiple paths to the same endpoint: routers
select the shortest path from their perspective
–  Implemented by using BGP (or OSPF within the same AS)
–  Nearest depends on the routing’s system measure of distance
•  Pros:
–  Backward compatibility: transparent to existing routing protocols
–  With respect to DNS redirection, server selection decision
based on the proximity to the client itself, not to its local DNS
67
Anycast in Internet (2)
•  Cons:
–  Difficulty of deployment, but manageable by skilled network
engineers
–  Lack of load balancing: routers do not consider server load
when routing a request
–  Connection disruption in connection-oriented downloads:
possibility of a route change in the middle of a transfer
• 
• 
Not good for stateful long-lived connections
But stateless protocols (or protocols that recover well) can still
work: luckily for the Web, DNS is stateless and HTTP is
reasonably stateless
68
IP anycast for DNS service
•  By far, the most common use for IP anycast is for
DNS
–  Multiple DNS name servers deployed using the same
anycast IP address
•  Why to use? To provide:
–  faster DNS response times
–  increased reliability
–  resilience against DDoS attacks
•  Some examples of DNS anycast:
–  Some Internet root nameservers are implemented as
clusters of hosts using anycast addressing
–  Google Public DNS
69
IP anycast for HTTP traffic
•  Anycast is becoming an alternative to DNS redirection
for geographically distributed Web systems
–  Web clusters can be deployed globally with the same anycast
address
•  When anycast works well (not easy to achieve!), it can
address most issues of DNS redirection:
–  Authoritative DNS server can reply with the same IP address
for all users and the address can have a longer TTL and be
cached by intermediate and local DNS name servers
–  No need to know where the user is: routing will take care of
bringing the client to the closest server regardless of where it
or its DNS server is
–  But load balancing among clusters is still an issue!
•  Now used by some big providers, sometimes in
conjunction with DNS redirection (e.g., Amazon,
Google, LinkedIn, YouTube)
70
Distribute requests to LinkedIn
•  First level of request distribution: regional anycast
–  See CNAME resource record which maps to different continents
(Europe and USA)
TCP over IP Anycast - Pipe dream or Reality?
DNS resolution from Rome
dig www.linkedin.com!
…!
ANSWER SECTION:!
www.linkedin.com.
!2
!IN
!CNAME
glb-any-eu.www.linkedin.com. 147 IN
any-eu.www.linkedin.com. 2844
!IN
!glb-any-eu.www.linkedin.com.!
!CNAME
!any-eu.www.linkedin.com.!
!A
!185.63.147.10!
!
DNS resolution from EC2 instance in Frankfurt
…!
ANSWER SECTION:!
www.linkedin.com.
!2
!IN
!CNAME
glb-any-eu.www.linkedin.com. 147 IN
any-eu.www.linkedin.com. 2844
!IN
!glb-any-eu.www.linkedin.com.!
!CNAME
!any-eu.www.linkedin.com.!
!A
!185.63.147.10!
71
!
!
Distribute requests to LinkedIn (2)
DNS resolution from EC2 instance in US-east
…!
;; ANSWER SECTION:
www.linkedin.com.
45
IN
CNAME
any-na.www.linkedin.com.
any-na.www.linkedin.com. 2026
IN
A
108.174.10.10
!
1.  Client located in continent A -> assigned by authoritative DNS name
server to IP anycast address (1.1.1.1) of continent A
2.  Anycast to route the client towards the closest replica of 1.1.1.1
72
Prodotti commerciali per Web multi-cluster
•  Alcuni prodotti commerciali basati su redirezione
DNS
– 
– 
– 
– 
Cisco ACE Global Site Selector
F5 Networks BIG-IP Global Traffic Manager
Radware AppDirector
Resonate Global Dispatch
•  Supportano il dispatching di primo livello basato su
DNS, usando algoritmi basati su prossimità, carico e
disponibilità dei cluster
73
Cloud-based global load balancers
•  Amazon Route 53
–  Provides DNS redirection to EC2 instances or clusters of
EC2 instances
–  Authoritative DNS server that answers DNS queries with low
latency by using a global network of DNS servers
•  Google’s HTTP(S) load balancing service
–  Appears to use anycast (a single global IP address)
–  Provides also cross-region load balancing to Compute
Engine instances in different regions
74
Infrastruttura di Google
•  Comprende centinaia di migliaia di macchine organizzate
in almeno 13 mega data center distribuiti
geograficamente www.google.com/about/datacenters/
•  Passeggiata in un data center di Google
75
Infrastruttura di Google (2)
•  Alcuni dati sui server
–  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 OC-48 (2488 Mbit/sec) e OC-12 (622 Mbit/
sec) con gli altri cluster
–  Nel 2006: 450000 server (stima)
–  Nel 2011: 900000 server (stima)
–  Commodity server con una versione customized di Linux
•  Alcuni dati sui servizi
–  L indice di Google comprende circa 45 miliardi di URL
–  Più di 3 miliardi di query al giorno, con l’obiettivo di servire una
query in meno di 0,2 secondi (ritardi di rete compresi!)
–  425 milioni di utenti Gmail
–  Milioni di video su Youtube ogni giorno
•  Research@Google: research.google.com/pubs/papers.html
76
Google platform: key design principles
•  Have reliability reside in software, not hardware
–  Use low-cost (unreliable) commodity PCs to build a high-end
cluster
–  Replicate services across machines and detect failures
•  Design for best total throughput, not peak server
response time
–  Response time can be controlled by parallelizing requests
–  Rely on replication: this helps with availability too
•  Price/performance ratio more important than peak
performance
77
Inside Google data center: hardware
Source: J. Dean,
Design, Lessons and Advice from Building Large Distributed Systems,
LADIS 2009.
78
Inside Google data center: some pictures
Pictures courtesy of Jeff Dean
In 1997
In 2000: note the fan!
In 2007
In 2016
79
Source: L.A. Barroso, U. Hölzle, The Datacenter as a
Computer: An Introduction to the Design of WarehouseScale Machines , 2009.
Handling hw failures in Google
80
SD ideati da Google
•  Google File System (GFS)/Colossus
•  Chubby
–  Servizio di lock per SD lascamente accoppiati sviluppato
per gestire la sincronizzazione a granularità grossa
•  BigTable
–  Sistema di storage distribuito column-oriented ad alte
prestazioni
•  Spanner
–  Database di tipo NewSQL globalmente distribuito
•  MapReduce
–  Modello di processamento di dati distribuiti su larga scala
•  Kubernetes
–  Gestore di cluster di container
Argomenti trattati nel corso
81
Distribute requests to Google search engine
•  First level of request distribution (inter-cluster): DNS
redirection or anycast
Reverse lookup:
mrs04s09-in-f196.1e100.net
Example: DNS resolution from Rome
;; ANSWER SECTION:!
www.google.com.
!
!
!72
mrs04s09-in-f4.1e100.net
!IN
!A
!216.58.210.196!
Example: DNS resolution from Rome in a different time of the day
dig www.google.com!
...!
www.google.com.
!
!300
!IN
!A
!149.3.176.58!
www.google.com.
!
!300
!IN
!A
!149.3.176.54!
www.google.com.
!
!300
!IN
!A
!149.3.176.56!
www.google.com.
!
!300
!IN
!A
!149.3.176.55!
www.google.com.
!
!300
!IN
!A
!149.3.176.59!
www.google.com.
!
!300
!IN
!A
!149.3.176.53!
www.google.com.
!
!300
!IN
!A
!149.3.176.52!
www.google.com.
!
!300
!IN
!A
!149.3.176.57!
...!
Valeria Cardellini - SDCC 2015/16 Maximum TTL value assigned by Google authoritative name servers
82

Web switch - CE group DISP - Università degli Studi di Roma "Tor

Transcript

Documenti analoghi

Sistemi Distribuiti e Cloud Computing

Sistemi Distribuiti e Cloud Computing

Networking Computing power Storage Memory Protocols

565 - PREORDINE - NECA EXCLUSIVE FIGURES FROM SDCC

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

4pp

Sistemi peer-to-peer Sistemi peer-to-peer (P2P)

Diapositiva 1 - Osservatorio Astronomico di Bassano Bresciano

Mappa - Commissione Divulgazione UAI

Anteprima di “TaorminaFilmFest

Nota MAP per Cluster meningite meningococcica in Europa