Sistemi Web distribuiti

Transcript

1 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. 2013/14 Valeria Cardellini Quali risorse Web? Risorse statiche Contenuto relativamente stabile nel tempo (es., file HTML, immagini, archivi, ) Risorse volatili Contenuto 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 Contenuto audio/video con dimensioni tipicamente maggiori rispetto ad altri tipi di risorse (video, mp3, animazioni Flash, ) Risorse sicure Contenuti trasferiti su un canale cifrato (HTTPS) Valeria Cardellini - SDCC 2013/14 2

2 Quali requisiti per un sistema Web? Dipendenti dal tipo di risorsa Risorse statiche Nessun problema particolare, a meno che non siano di grandi dimensioni (storage+network) 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 Due metodi: download-and-play (es. HTTP) e play-duringdownload (es. RTP, RTSP) Elevati requisiti di banda per entrambi i metodi (dimensione delle risorse); maggiore costo computazionale di playduring-download Risorse sicure Trasferimento di risorse di qualunque tipo su canali cifrati per esigenze di protezione e privacy; elevato costo computazionale Valeria Cardellini - SDCC 2013/14 3 Quali generazioni del Web? Web di prima generazione: Web publishing Risorse statiche Contenuti prodotti dal content provider Web di seconda generazione: Web-based information system Anche risorse volatili, dinamiche e sicure Contenuti prodotti dal content provider Web di terza generazione: social Web, mobile Web Anche risorse multimediali Contenuti prodotti dal content provider e dagli utenti (anche mobili) Valeria Cardellini - SDCC 2013/14 4

3 Perché sistemi Web distribuiti? Successo del Web Alcuni siti soggetti a centinaia di milioni di richieste ogni giorno Per statistiche: 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 Valeria Cardellini - SDCC 2013/14 5 Componenti del ritardo Web Web client DNS server Web server Address resolution delay DNS query DNS reply Client delay SYN j Connection delay Client delay Network delay Server delay SYN k, ACK j+1 ACK k+1 HTTP request Network delay HTTP response Dov è il collo di bottiglia? Dov è il collo di bottiglia? (1) DNS? (2) Client? (3) Rete? (4) Piattaforma server? Valeria Cardellini - SDCC 2013/14 6 t

4 Potenziamenti del Web Azioni a livello del CLIENT Possibilità di intervento limitato, ma sviluppo di HTML5 Azioni a livello di RETE Azioni da parte di APPLICATION PROVIDER Replicazione dei server Caching Focus Azioni da parte di INTERMEDIARI Caching cooperativo (istituzionale o ISP) Content Delivery Network (commerciale) Valeria Cardellini - SDCC 2013/14 7 Ottimizzazioni lato server Scale-up (scalabilità verticale) Miglioramenti hw/sw LAN Scale-out (scalabilità orizzontale) Sistemi con server multipli (Web/cache) WAN Valeria Cardellini - SDCC 2013/14 8

5 Scale-up e scale-out: costo Scale-up: Costo esponenziale LAN Scale-out: Costo lineare WAN Valeria Cardellini - SDCC 2013/14 9 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, Nginx (I/O non bloccante) Scale-out A livello di application provider Distribuzione locale dei server Focus Distribuzione globale dei server Integrazione con meccanismi di caching Soluzioni in-house, outsourced oppure Cloud-based A livello di intermediari Content Delivery Network Valeria Cardellini - SDCC 2013/14 10

6 Sistemi Web distribuiti Distribuzione locale Distribuzione globale Web cluster Web multi-cluster Valeria Cardellini - SDCC 2013/14 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: multi-cluster ovvero molteplici cluster distribuiti geograficamente Focus sull uso dei cluster in ambito Web Valeria Cardellini - SDCC 2013/14 12

7 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 Valeria Cardellini - SDCC 2013/14 13 Architettura di un cluster per applicazioni Web Replicazione orizzontale e verticale Una miriade di tecnologie Network/OS technology Front-end server(s) Web switch (VIP) LAN Front-end technology Web servers Middleware technology Application servers Database/storage technology Back-end servers + Virtualization technology! Web cluster Valeria Cardellini - SDCC 2013/14 14

8 Web cluster Architettura parallela o distribuita localmente che fornisce applicazioni Web Caratteristiche di trasparenza e scalabilità Indirizzi del cluster (per una singola applicazione) Un solo nome logico (es., ) 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 Valeria Cardellini - SDCC 2013/14 15 Richiesta ad un cluster Risposta (5) (4) Richiesta (1) (3) Cluster (2) DNS server root DNS server locale Fattori da considerare: Caratteristiche del cluster switch Flusso dei pacchetti di risposta Valeria Cardellini - SDCC 2013/14 DNS server autoritativo per 16

9 Web switch Componente di rete con ruolo di dispatcher Anche noto come: load balancer (1999) traffic manager (2003) application delivery controller (ADC) (dal 2009 ad oggi) 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) Valeria Cardellini - SDCC 2013/14 17 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 Valeria Cardellini - SDCC 2013/14 18

10 Architetture per Web cluster One-level routing (centralizzato) Fase di richiesta Web switch Web switch (Livello 4) Web switch (Livello 7) Two-way One-way Two-way One-way Packet rewriting Packet forwarding Packet tunneling TCP gateway TCP splicing TCP handoff TCP conn. hop Valeria Cardellini - SDCC 2013/14 19 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 Valeria Cardellini - SDCC 2013/14 20

11 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 Valeria Cardellini - SDCC 2013/14 21 Architetture di livello 4 two-way Packet double-rewriting Cluster node 1 Cluster node 2 Cluster node 3 Richiesta Risposta (VI P) Web switch LAN DNS server locale DNS server autoritativo per Cluster node n Cluster node 4 Valeria Cardellini - SDCC 2013/14 22

12 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) Valeria Cardellini - SDCC 2013/14 23 Architetture di livello 4 one-way Packet single-rewriting Packet forwarding Packet tunneling Cluster node 1 Cluster node 2 Cluster node 3 Risposta (VI P) LAN Richiesta Web switch Cluster node n Cluster node 4 DNS server locale DNS server autoritativo per Valeria Cardellini - SDCC 2013/14 24

13 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) Valeria Cardellini - SDCC 2013/14 25 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 Valeria Cardellini - SDCC 2013/14 26

14 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 Valeria Cardellini - SDCC 2013/14 27 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) Valeria Cardellini - SDCC 2013/14 28

15 Architetture di livello 7 two-way 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 Valeria Cardellini - SDCC 2013/14 29 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 Client Server User level (1) Dispatcher (4) (5) Kernel (2) Handoff (3) Handoff TCP/IP TCP/IP TCP/IP conn req ack response conn req Forward handoff req ack Client Web switch Target server Valeria Cardellini - SDCC 2013/14 30

16 Algoritmi di distribuzione nei sistemi Web Due classi di algoritmi di distribuzione Statici (stateless) 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) Nullo Livello di informazioni di stato Elevato Valeria Cardellini - SDCC 2013/14 31 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 Valeria Cardellini - SDCC 2013/14 32

17 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!) Valeria Cardellini - SDCC 2013/14 33 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 Valeria Cardellini - SDCC 2013/14 34

18 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 Valeria Cardellini - SDCC 2013/14 35 Distribuzione a livello 7 Esempi di algoritmi dinamici client info aware Identificatori di sessione Partizionamento del contenuto Esempi di algoritmi dinamici client info & server state aware Locality Aware Request Distribution (LARD) Valeria Cardellini - SDCC 2013/14 36

19 Algoritmi L7 client info aware Identificatori di sessione Richieste HTTP con stesso SSL id o stesso cookie assegnate allo stesso server Anche chiamato sticky session o session persistence Partizionamento del contenuto tra i server In base al tipo di risorsa Obiettivo: utilizzare server specializzati 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 Valeria Cardellini - SDCC 2013/14 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 A A A A A server A A A C B C A A C B switch cache cache C B C C B server Valeria Cardellini - SDCC 2013/14 38

20 Prodotti commerciali per Web cluster Principali prodotti commerciali Barracuda Load Balancer Brocade ADX Series Cisco Application Control Engine (ACE) e Content Service Switch (CSS) Citrix NetScaler Coyote Point F5 Networks BIG-IP Local Traffic Manager (LTM) loadbalancer.org Microsoft Network Load Balancing (NLB) Radware AppDirector Resonate Central Dispatch Riverbed Stingray Traffic Manager (ex Zeus Load Balancer) Valeria Cardellini - SDCC 2013/14 39 Prodotti commerciali per Web cluster (2) Tranne Microsoft NLB e Riverbed Stingray, i prodotti commerciali sono dispositivi hardware specialpurpose 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 Valeria Cardellini - SDCC 2013/14 40

21 Prodotti open source per Web cluster Principali prodotti open source HAProxy usato ad es. da DISQUS, Fedora, Reddit, w3.org Linux Virtual Server nginx Server HTTP, in grado di servire un numero maggiore di richieste concorrenti rispetto ad Apache (vedi Apache vs nginx) Usato dal 14,7% dei siti più popolari, ad es. Netflix (vedi Netcraft January 2014 Web Server Survey) Può anche essere usato come load balancer Perlbal Scritto in Perl Pound Operano tutti a livello software Valeria Cardellini - SDCC 2013/14 41 Linux Virtual Server (LVS) Software open-source per realizzare un Web cluster 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 KTCPVS: livello applicativo nel kernel TCPHA: TCP handoff TCPSP: TCP splicing Caratteristiche salienti Scalabilità Elevata disponibilità Configurazione LAN e WAN Integrazione con Keepalived per monitoring Valeria Cardellini - SDCC 2013/14 42

22 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 Valeria Cardellini - SDCC 2013/14 43 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 Web servers Application servers Back-end servers Front-end server(s) Web switch (VIP) LAN WEB CLUSTER Valeria Cardellini - SDCC 2013/14 44

23 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 molti prodotti commerciali usando semplici politiche di distribuzione (varianti di round-robin, 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 Valeria Cardellini - SDCC 2013/14 45 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 Valeria Cardellini - SDCC 2013/14 46

24 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 In alternativa alla replicazione del DB, si può usare un middleware per gestire un cluster di DB Esempio: Continuent Tungsten per MySQL e PostgreSQL Non più open source! Valeria Cardellini - SDCC 2013/14 47 Memcached Free and open source, used e.g., by Digg, 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 Valeria Cardellini - SDCC 2013/14 48

25 Example of Web cluster architecture: DISQUS DISQUS (October 2010) The largest Django app Traffic: 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) Valeria Cardellini - SDCC 2013/14 49 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 Contenuto statico servito da Akamai Varnish come acceleratore per richieste HTTP Memcached come distributed key-value store (vedi NSDI13) Valeria Cardellini - SDCC 2013/14 50

26 Example of Web cluster architecture: Facebook (2) The description of hw architecture of Facebook data center is publicly available at 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. Valeria Cardellini - SDCC 2013/14 51 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) Soluzione parziale: replicazione del Web switch Scalabilità limitata dal Web switch Soluzione parziale: replicazione del Web switch Scalabilità limitata dalla banda di accesso ad Internet Soluzione Replicare i cluster su scala geografica (global scale-out) Valeria Cardellini - SDCC 2013/14 52

27 Delivery su scala geografica Il content/service provider ha le seguenti possibilità per distribuire i propri contenuti/servizi su scala geografica in modo efficiente e scalabile: Il provider possiede e gestisce l intera piattaforma Oppure delega la gestione della piattaforma ad uno o più data center Oppure ad un IaaS o PaaS provider In tutti i casi: 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 o equivalente servizio a livello SaaS, ad es. Amazon CloudFront) Valeria Cardellini - SDCC 2013/14 53 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? Valeria Cardellini - SDCC 2013/14 54

28 Multi-cluster per applicazioni Web Applicazione Web fornita da un architettura di Web cluster distribuiti geograficamente in diverse regioni Internet Meccanismo di routing delle richieste 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 server DNS autoritativo seleziona un cluster nella fase di address lookup applicando un algoritmo di distribuzione delle richieste di risoluzione di indirizzo: Round-robin Prossimità di rete o geografica Carico dei cluster Prossimità e carico dei cluster Valeria Cardellini - SDCC 2013/14 55 Cluster e multi-cluster Distribuzione locale Distribuzione geografica Web cluster Web multi-cluster Dispatching a livello 4 (OSI) Dispatching a livello 7 (OSI) Dispatching in 2 fasi (DNS+ intra-cluster) Dispatching in 3 fasi (DNS+ intra-cluster+ inter-cluster) Valeria Cardellini - SDCC 2013/14 56

29 Web multi-cluster (2 livelli) Un unico hostname Un indirizzo IP per cluster Web switch Richiesta HTTP Web switch Web switch Risposta DNS locale < ,TTL> DNS autoritativo per Web switch Valeria Cardellini - SDCC 2013/14 57 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 da: < Indirizzo IP, Time-To-Live> 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) Soluzione anche nota come redirezione DNS Valeria Cardellini - SDCC 2013/14 58

30 Algoritmi di dispatching per DNS DNS-based dispatching Static Client info aware Cluster state aware Client info & cluster state aware Internet domain Cluster load Internet domain Cluster load Valeria Cardellini - SDCC 2013/14 59 Prossimità in Internet E 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 Valeria Cardellini - SDCC 2013/14 60

31 Prossimità in Internet (2) Valutazione dinamica della prossimità round trip time (ad es. ping, tcping) bandwidth disponibile (ad es. pathchirp, 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 Valeria Cardellini - SDCC 2013/14 61 Problemi del dispatching geografico (di cui le politiche di dispatching devono tener conto) Problemi tipici del dispatching Web 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 Ora del giorno Valeria Cardellini - SDCC 2013/14 62

32 Problemi del dispatching tramite DNS Oltre ai problemi del dispatching geografico Controllo limitato sulla risoluzione delle richieste di indirizzo da parte del server DNS autoritativo: Nel caso di siti Web molto popolari (e TTL standard ), 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-To-Live (TTL) Come risolvere il problema? Usando un TTL prossimo a zero, ma overhead sul DNS! Usando a livello del DNS autoritativo algoritmi di dispatching sofisticati (ad es. TTL-adattativi) Difficoltà nello stimare la prossimità Internet Locazione del name server locale usato dal client diversa da quella del client (distanti tra loro anche diversi hop!) E un meccanismo di distribuzione application-blind Valeria Cardellini - SDCC 2013/14 63 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 infrastruttura DNS di Akamai) per poter usare un TTL basso Fase di richiesta dell applicazione: integrare il dispatching 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) Valeria Cardellini - SDCC 2013/14 64

33 Dispatching per Web multi-cluster Indirizzi visibili dell applicazione Web Un unico hostname (ad es., ) 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) Per semplificare, non consideriamo gli ulteriori livelli di dispatching interni al cluster Valeria Cardellini - SDCC 2013/14 65 Web multi-cluster (3 livelli) Web switch 3 Web switch 2 Web switch Prima richiesta HTTP Go To Seconda richiesta HTTP Risposta DNS locale < ,TTL> DNS autoritativo per Web switch Valeria Cardellini - SDCC 2013/14 66

34 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 Valeria Cardellini - SDCC 2013/14 67 Supportata dai browser: nativa nel protocollo HTTP New location : come indicarla? Indirizzo IP (prestazioni migliori ma no trasparenza) Hostname Vantaggi Compatibilità Web Redirezione HTTP HTTP message header HTTP status code Moved temporarily to a new location Meccanismo distribuito che soddisfa requisiti di affidabilità (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 Valeria Cardellini - SDCC 2013/14 68

35 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 prossimità, carico e disponibilità dei cluster Valeria Cardellini - SDCC 2013/14 69 Anycast Anycast: point-to-point flow of packets between a client and at least one replica, typically the nearest, of the servers identified by an 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 one or more servers belonging to an anycast group Client sends packets to an anycast address and the network attempts to deliver the packet to a server with the matching anycast address Valeria Cardellini - SDCC 2013/14 70

36 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 Valeria Cardellini - SDCC 2013/14 71 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 Valeria Cardellini - SDCC 2013/14 72

37 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 anaycast: Some Internet root nameservers are implemented as clusters of hosts using anycast addressing Google Public DNS Valeria Cardellini - SDCC 2013/14 73 IP anycast for HTTP traffic HTTP anycast as possible alternative to DNS redirection for geographically distributed Web systems HTTP servers can be deployed globally with the same IP address When HTTP 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 long TTL and be cached by intermediate DNS name servers No need to know where the user is: routing will take care of bringing the user to the closest server regardless of where they or their DNS server are But load balancing is still an issue! Used by some CDN providers (e.g., CloudFlare) Valeria Cardellini - SDCC 2013/14 74

38 Infrastruttura di Google Comprende centinaia di migliaia di macchine organizzate in almeno 13 data center distribuiti geograficamente Passeggiata in un data center di Google Valeria Cardellini - SDCC 2013/14 75 Infrastruttura di Google Alcuni dati sui server Nel 2002 Google usava 6000 processori e 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 (622Mbit/ sec) con gli altri cluster Nel 2006: macchine (stima) I server sono commodity x-86 PC 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 Riferimenti: Valeria Cardellini - SDCC 2013/14 76

39 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 Valeria Cardellini - SDCC 2013/14 77 Inside Google data center: hardware Source: J. Dean, Design, Lessons and Advice from Building Large Distributed Systems, LADIS Valeria Cardellini - SDCC 2013/14 78

40 Handling hw failures in Google Source: L.A. Barroso, U. Hölzle, The Datacenter as a Computer: An Introduction to the Design of Warehouse- Scale Machines, Valeria Cardellini - SDCC 2013/14 79 Nel cluster di Google: il software Google Web Server (GWS) File system: Google File System (GFS)/Colossus Chubby Servizio di lock per SD lascamente accoppiati sviluppato per gestire la sincronizzazione a granularità grossa Storage: BigTable/Spanner BigTable: sistema di storage distribuito column-oriented ad alte prestazioni MapReduce Modello di processamento di dati distribuiti su larga scala Linguaggio di programmazione Sawzall Usato per processare un gran numero di log record (protocol buffer) Protocol buffers Serializzazione di dati strutturati Argomento di lezioni successive Valeria Cardellini - SDCC 2013/14 80

41 Step 1: distribute requests through DNS First level of request distribution (inter-cluster): DNS redirection Distribution algorithm selects cluster based on cluster load and client proximity Example: DNS resolution from Roma, Italy dig IN A IN A IN A IN A IN A Valeria Cardellini - SDCC 2013/14 81 Step 1: distribute requests through DNS (2) Example: DNS resolution from East Coast, USA dig IN A IN A IN A IN A IN A IN A Valeria Cardellini - SDCC 2013/14 82

42 Step 2: distribute requests inside a cluster Step 2 goal: receive HTTP request (Web servers) Inside a cluster: The IP address returned by the DNS corresponds to a Web switch inside the cluster Web switch: Monitors the set of Google Web Servers (GWS) Performs local load balancing of requests among available servers GWS machine receives the user query Coordinates the execution of the query Formats the result into an HTML response to the user Valeria Cardellini - SDCC 2013/14 83 Step 3: search for results Step 3 goal: find documents via inverted index (index servers) Index lookup is partitioned and parallelized Instead of looking up matching documents in a large index: Do many lookups for documents in smaller indices Merge results together: a merge is simple and inexpensive Index servers Map each query word {list of documents} (hit list) Inverted index generated from Web crawlers MapReduce Intersect the hit lists of each per-word query Compute relevance score for each document Determine set of documents Sort by relevance score Valeria Cardellini - SDCC 2013/14 84

43 Step 4: prepare response Step 4 goal: Get title and URL for each docid For each docid, the GWS looks up Page title URL Relevant text: document summary specific to the query Handled by document servers (docservers) Like index lookup, document lookup is partitioned and parallelized Together, document servers access a cached copy of the entire Web! Valeria Cardellini - SDCC 2013/14 85 Additional operations In parallel with search: Send query to a spell-checking system Send query to an ad-serving system to generate ads When all the results are in, GWS generate HTML output: Sorted query results according to their rank With page titles, summaries (from document servers), and URLs Advertisements (from ad servers) Spelling correction suggestions (from spelling servers) Valeria Cardellini - SDCC 2013/14 86

44 Change to Caffeine In 2010, Google remodeled its search infrastructure Old system Based on MapReduce to generate index files Batch process: next phase of MapReduce cannot start until first is complete Web crawling MapReduce propagation Initially, Google updated its index every 4 months. Around 2000, it reindexed and propagated changes every month Process took about 10 days Users hitting different servers might get different results New system, named Caffeine Fully incremental system: based on BigTable running on GFS2 (version 2 of GFS) Support indexing many more documents: ~100 petabytes (10 17 byte) High degree of interactivity: Web crawlers can update tables dynamically Analyze web continuously in small chunks Identify pages that are likely to change frequently Valeria Cardellini - SDCC 2013/14 87