Content Delivery Networks

Transcript

1 1 Content Delivery Networks Terena 2000 ftp://ftpeng.cisco.com/sgai/t2000cdn.pdf Silvano Gai Cisco Systems, USA Politecnico di Torino, IT LEZIONE 24 Argomento interessante e molto particolare. Oggi le CDN sono un pilastro portante dei servizi offerti su Internet. Hanno un sacco di problematiche, ma danno tutta una serie di vantaggi a livello di Quality of Experience (l'utente percepisce un servizio buono con la rete che abbiamo, al contrario della QoS in cui si cerca di agire sulla rete). Queste slide sono del Erano gli anni in cui si cominciava a parlare di CDN. Oggi i contesti sono più o meno gli stessi (con le dovute migliorie) ma si sono espanse un sacco. Terena 2000 Load Balancing 2 S2 At the beginning were Web Caches S1 IP Network S3 IP Network Web Cache A Web Cache is a device that stores a local copy of more recently required HTTP objects and reacts as proxy server to clients requests Che cos'è una CDN? E' un po' una generalizzazione delle cache del web. Ricordiamo, infatti, l'uso dei proxy: quando un utente chiede qualcosa può passare da un proxy (la cosa dev'essere opportunamente configurata) e sarà il proxy a chiedere, ad esempio, google.it per poi inoltrarlo al client. Se un altro client chiede google.it verrà restituito il risultato in cache. Meno tempo di servizio, meno traffico sul backbone (il proxy solitamente sta vicino all'utente), meno carico sui server web. Fare un apparato che faccia analisi del traffico a L4+ è estremamente complicato per tutta una serie di motivi (gestire un gran numero di connessioni, dover ricostruire e gestire i pacchetti di una sessione TCP, analizzarne il contenuto...). Con un proxy è molto più facile, dopo opportuna configurazione. 3 Motivations for Content Delivery Networks Web site performance improvement Static Web pages or nonlive streaming media farms are far from users Better RTT à better user s experience Bandwidth Cost saving Less probability to incur in a bottleneck Availability Load balancing Traffic peaks crashes sites Nella CDN il problema che abbiamo è relativo alle prestazioni. Siccome coi proxy possiamo memorizzare delle informazioni per non contattare tutte le volte i webserver. Sarebbe bello generalizzare questa idea e avere dei proxy sparsi per il mondo con delle copie locali. Il problema che abbiamo è obbligare l'utente a usare dei proxy. CDN invece vuole fare dei proxy sparsi in giro per il mondo a cui l'utente accede SENZA ACCORGERSENE. Naturalmente le copie del contenuto sparse devono essere allineate al contenuto principale (questo dunque non funziona bene con i contenuti che cambiano spesso). E dobbiamo avere dischi grandi. Facciamo CDN perchè se invece facciamo andare gli utenti fino all' unico server centralizzato ci ritroviamo casi in cui il servizio è povero 4

2 5 Content Delivery Networks (CDNs) Distributed Web Hosting Video-On-Demand MPEG on LAN Low/Mid-rate streaming on WAN Scalable Live Streaming Dynamic Content Conditional-Access Content advertisements Quello che si vuole cercare di fare è sostanzialmente del web hosting distribuito. Invece che tenere il mio contenuto in una server farm centralizzata, cerco di metterlo su diverse copie sparse in giro per il mondo. Il problema è dunque far accedere gli utenti alle copie distribuite: questo è l'obiettivo delle tecniche CDN. I contenuti sono: - contenuto web - video on-demand (più complicato se è streaming live, ma fattibile) - contenuti dinamici (PHP): in questo caso distribuiamo la funzionalità, cosa non sempre fattibile - contenuti non sempre accessibili: il contenuto è messo insieme ad altri contenuti da inviare a utenti che arrivano da specifici posti. Example of CDN CDN dunque è una roba ben complicata e dietro girano bei soldini. Se io sono un content provider (Youtube) non è che voglia avere il servizio di CDN da content provider diversi, quindi non c'è uno standard a cui adeguarsi. Non c'è bisogno di interoperabilità. Content Updates Live Streams La slide qui vuol far vedere che ho migliaia/milioni di clienti a cui accedono, ma il lavoro del server è molto basso. 1K to 10M Client Requests 6 An Overlay Network over Internet A CDN is an overlaid network of Caches, a.k.a. Content s, a.k.a. Delivery Nodes, a.k.a. Replicas La CDN è un servizio di overlay (anche se a livello di ricerca si trova un po' di tutto), al di sopra della rete. C'è una rete di server che si occupano di portare i contenuti vicino ai clienti. Il problema è come portare i clienti ai server più vicini. Le copie di contenuto hanno vari nomi, proprio perchè siccome non esiste uno standard ognuno si è inventato la sua soluzione. 7 Come facciamo a fare in modo che le richieste degli utenti arrivino al posto giusto? Una delle soluzioni possibili si chiama DNS Based Routing. Load Balancing 8

3 9 The idea: a new DNS Architecture DNS queries for Standard DNS interface Routing Engine {DNS-names, IP-SA} IP-DA Si sfrutta il fatto che l'utente, nella quasi totalità dei casi, quando vuole accedere al servizio usa il nome del servizio. Il client, dunque, va prima o poi a fare una richiesta verso un server DNS "modificato". Il gestore della CDN ha accordi con un certo numero di gestori di server DNS. Ricordiamo anche che se nessuno sa rispondere risponde direttamente il server interessato. Il server DNS, dunque, nel fornire una risposta, guarda sia il nome che l'indirizzo IP grazie al quale posso trovare la posizione geografica di una determinata rete. Riesco così a distribuire il carico su tanti server e a dare a ciascuno un server vicino. Diverse problematiche da gestire tra cui il caching DNS. DNS-based CDNs Host Names are used to redirect the traffic to the best replica the replica selections happens when the name is translated to an IP address DNS servers become Content Routers they measure as many metric as possible (RTT, Load, Layer 3 metrics, response time, etc.) to compute a replica routing table {{DNS-names, IP-SA} IP-DA} Metric measurement is not easy Layer 3 metrics alone are not particularly meaningful Teniamo presente che in realtà il server DNS può usare anche altre informazioni rispetto al solo indirizzo IP per restituire un indirizzo da contattare (ad esempio il RTT). Soluzioni fatte ad hoc. Si possono fare cose complicate a piacere, ma la complicazione esplode. Si tenga poi presente che alcune metriche sono anche parecchio dinamiche. 10 Access Provider Backbone Provider Traditional Browsing DNS MSPG UUNET AT&T XYZ MCI Qual è lo scenario? Da un lato abbiamo dei client, dall'altro dei server che contengono i contenuti (in realtà il modello è ancora diverso, perchè non è detto che chi possiede i server possiede anche i contenuti) 1. Il client fa la richiesta DNS rivolgendosi al DNS del suo Access Provider 2. La richiesta va a finire al DNS del Content Provider 3. Il client accede al server Hosting Provider EXDS ABOV DNS Content Provider CNN 11 Access Provider DNS-based CDN Browsing # Replica MSPG DNS XYZ Replica Usando soluzioni basate su CDN ci sono repliche del contenuto in giro per il mondo (occhio: anche se le repliche sono sul backbone provider non sono messe dal backbone provider, ma dal CDN provider che compra servizi di connettività). Il servizio viene fornito da un server # vicino al client. Backbone Provider AT&T UUNET Replica MCI Hosting Provider EXDS GBLX DNS Content Provider CNN CDN DNS 12

4 13 Example Akamaized content Akamaization HTML delivered by CNN Entire page delivered by CNN DNS-based CDNs Limitations There are limitations The granularity of redirection is an host name, not a URL Content of large web sites cannot be split into multiple caches It is difficult to use the same host name for static and dynamic content The Akamai approach: Akamaized URLs: How Akamai works (1) 14 Quali sono le limitazioni che abbiamo? La granularità per scegliere il server è il nome, quindi non posso fare una cosa più raffinata di mandarti in maniera ottimizzata a (una volta entrato, bon). Inoltre se il nostro sito web ha contenuti misti statici e dinamici, i contenuti dinamici non possono essere distribuiti con una CDN, ma devono essere distribuiti proprio i servizi. Non posso dunque mettere su un server con lo stesso nome contenuto statico e contenuto dinamico. Una soluzione per ovviare a questo problema è utilizzare l'approccio Akamai. Akamai ha una soluzione di CDN molto flessibile (secondo i punti di vista): loro modificano le URL delle pagine Web, in modo che se io scarico la pagina Web di polito.it da Torino gli URL sono costruiti apposta per farli "puntare" a Torino. A questo punto vale tutto: ogni singola sottopagina può essere su qualsiasi server. Ciò richiede che i riferimenti alle varie pagine siano "akamaizzati". Se dunque scarico la pagina del polito da Parigi i vari link contenuti non saranno polito.it ma punteranno a server Akamai sparsi in giro per il mondo. Akamai ha avuto un enorme successo. Soluzione specifica, poco elegante. Però funziona. Inoltre Akamai può inoltrare le richieste come meglio crede. It creates new domain names for each client content provider E.g., a128.g.akamai.net The CDNs DNS servers are authoritative for the new domains CDN s The content provider modifies its content so that embedded URLs reference the new domains --> Apache module or IIS ISAPI filter 15 How Akamai works (2) Using multiple domain names for each client allows the CDN to further subdivide the content into groups DNS sees only the requested domain name, but it can route requests for different domains independently may point to mainly Italian caches may point to mainly Spanish caches 16

5 17 Extension to DNS-based CDNs How to implement more granular DNS-based CDNs (e.g. how to look for the complete URL)? HTTP/RTSP Redirect Redirection can be obtained in two ways every server in the farm is capable to redirect An SLB ( Load Balancer) is capable to redirect Effective only in a Local Area Un'altra possibilità per gestire questo tipo di cose, scendendo a una granularità più bassa è offerta dal fatto che sia HTTP che RTSP sono in grado di generare messaggi di redirect. Se a un certo punto il server di diventa molto carico può inviare un messaggio di redirect. Un'altra possibilità è quella di far fare questo lavoro a un server load balancer: ci sono una serie di server collegati, l'utente cerca di accedere a un determinato server. Però è strapieno e quindi il server load balancer ti dice di farla a un altro server. Non tanto semplice e buono solo per server vicini (la distribuzione geografica te la scordi). The Next Step: URL-based CDNs URLs are used to redirect the traffic to the best Content URL routing requires TCP termination TCP termination is complex and expensive TCP termination introduces delay There will be only one TCP termination point Close to the client? Close to the server? Dispositivi in mezzo alla rete che guardano le richieste, guardano la URL, vedono cosa sta chiedendo il client e in base a quello lo mandano a un server diverso. Problema di questa cosa: i dispositivi devono riuscire a terminare la connessione TCP (il client cerca di accedere a un server, apre una connessione TCP ma quando il pacchetto SYN arriva a questo dispositivo manda un SYN/ACK "fingendosi" il server). Più facile, però non è un end system (se il poveretto ha un sacco di server a valle, ha anche un sacco di carico e deve poi aprire le connessioni verso il server). Normalmente questo tipo di cose si fanno più nei data server. Soluzioni utili per load balancing, poco diffuse per il resto. 18 Load Balancing 19 Farms A reality today Clients see a unique Virtual (IP address) Traffic destined to the Virtual is load balanced among different Real R IP Network Client (Browser) Data Application Web Farm 20

6 21 Load Balancing I load balancer cercano di distribuire bene il traffico. Un po' più complicato di quanto sembra perchè poi c'è la connessione (e dunque devo andare sempre verso un server). Real S1 Real S2 SLB IP Network Real S3 Client (Browser) Virtual Content-unaware (layer 4 switching) TCP connections are not terminated by the SLB All packets belonging to a given TCP connection must be terminated always on the same server Examples Load distribution based on source IP address Load distribution based on hash (IP src/dst, TCP sport/dport), Load Balancing Content-aware (layer 7 switching) TCP connections with both clients and servers are terminated To support SSL (https) the SLB requires the server keys Quando si parla di server load balancing si parla di switching L4 e L7. Supponiamo di avere due server e dire: tutti quelli che arrivano solo da indirizzi pari li mando sopra, tutti quelli che arrivano da indirizzi dispari li mando sotto. In più posso anche basarmi sulle porte. Questo però non sempre è efficiente, quindi si fa L7 switching. Loro guardano informazioni di livello applicativo (come la URL) per decidere dove mandare il traffico. 22 Client SYN SYN/ACK ACK TCP Proxy Content Aware Router (Layer 7 Switch) Qui si spiega il concetto della terminazione delle connessioni TCP. Loro ora si sono messi "nei guai" e devono fare da passacarte. Dunque abbiamo macchine enormi e costosissime. Uno dei problemi che abbiamo in una configurazione del genere è con SSL. I certificati del server devono dunque stare sull'l7 switch: questo va bene se l'l7 switch è nella diretta disponibilità di chi ha il server, perchè altrimenti bisogna fidarsi. Oppure non si usa SSL. GET URL SYN SYN/ACK ACK GET URL Data Data 23 Limitations with SLB Some applications require that TCP connections from the same client are redirected to the same server (Sticky Connections): Shopping Cart Searches Forms Economic Transactions Stickiness may be addressed/complicated by: source IP address cookies SSL ID 24

7 25 Load Balancing URL routing Possiamo anche fare router di L7. Il routing "intelligente" viene dunque fatto su tutta la rete. Fantastico, ma estremamente complicato, difficile da far scalare e difficilmente vendibile. Can we build a router that routes on URLs? YES, but: statefull (we must terminate TCP) complex packet parsing (we need the URL) anycast router (a URL is associated to multiple replicas) Do we have URL routing tables? Do we have URL routing protocols? Do we have metrics? How do we compute them? 26 IP routing IP vs. Content Routing H1 R1 R2 R3 H2 Content routing or CR2 H1 CR1 H2 CR3 27 Or even more complex H1 CR1 CR2 CR3 H2 CR2 CR4 H1 CR1 CR5 H2 CR3 28

8 29 Content Delivery Control Protocols in series cannot all terminate the TCP session: we don t want to reinvent X.25 URL must be extracted by the first Content Router propagate by a Content Delivery Control Protocol Some protocols have been proposed: HUP Christmas Tree ICAP Still in a very preliminary phase: if successful, they can be integrated in the hosts. Load Balancing 30 The Ethical question Is it ethical to deploy Content Routers in the Internet? They hijack the packets They spoof the addresses They break the end-to-end model of IP 31 Where, is the question Access Provider Here No, or may be Backbone Provider NOT HERE!!! Hosting Provider Content Provider Here YES 32

9 33 Load Balancing Sometime CDNs are very good! 34 Sometime are not so good! 35 Content Provider Content Peering CDN1 CDN2 Control POP Routing POP Delivery POP CDN3 36

10 37 Conclusions Content Delivery Networks (CDNs) DNS-based will be widely deployed CDNs are not only for web traffic, but also for multimedia streaming Replicas will have slightly different content (e.g. local advertisement) Content Peering is still an unsolved problem Farms and Load Balancing will be widely deployed Intrusive content routing poses: ethical questions scalability concerns The End Thank You 38