Content Delivery
Network (CDN)
Přednáška KIV/PDS Pavel Bžoch, 19.3.2013
Obsah • Cesta k CDN
• Historie CDN
• Architektura CDN
• Distribuce obsahu
• Generování dynamických stránek
• Streamování videa
• Case study
Internet a cesta k CDN
• Internet – celosvětový systém navzájem
propojených počítačových sítí o počítače komunikují pomocí rodiny protokolů TCP/IP
o cílem všech lidí využívajících internet je bezproblémová komunikace
• Nejznámější službou poskytovanou v rámci internetu
je WWW o kombinace textu, grafiky a multimédií propojených hypertextovými
odkazy
• Další důležitou službou je e-mail
Internet a cesta k CDN • Dvě skupiny lidí (institucí), které chtějí naplnit své
potřeby: o Konzumenti obsahu, uživatelé - hlavní potřebou je získání informací a
využívání poskytovaných služeb
o Poskytovatelé obsahu – cílem je vydělat peníze (reklama, poskytování
služeb)
• Obě tyto skupiny mají různé potřeby a očkávání od
interenetu
Internet a cesta k CDN • Očekávání uživatelů od internetu:
o Výkonnost
• „Uživatelova loajalita navštěvovat stále stejné stránky (když jsou pomalé) je malá, protože je velice jednoduché přejít na jiné stránky.“
o Dostupnost
• „Uživatelé od internetu očekávají, že všechny typy informací budou stále dostupné “
o Bezpečnost
• Je komunikační cesta zabezpečena? Jsou data bezpečně uložena na serveru? Jak je těžké ukrást něčí identitu či heslo?
o Anonymita
• „Se zvětšujícím se počtem uživatelů internetu se anonymita uživatelů zvětšuje. “
o Personalizace, osobní nastavení
• Nastavení vzhledu, pořadí zobrazovaných informací atd.
o Soukromí
• Uživatelé si přejí být informováni, pokud jejich údaje mohou být sdíleny s někým dalším
Internet a cesta k CDN • Očekávání poskytovatelů obsahu
o Bezpečnost
• „Jaký zisk by měla stránka, když by bylo možné se na placený obsah dostat i zadarmo ?“
o Kontrola
• Poskytovatelé kontrolují, jaký obsah uživatelé navštěvují, vytvářejí třídy služeb pro různé typy uživatelů. Cílem je vytvoření konkurenční výhody.
o Ovladatelnost, řiditelnost
• Poskytovatelé obsahu musí mít přehled o výkonu svých systémů, aby věděli, jestli splňují požadavky uživatelů na dostupnost a rychlost.
o Škálovatelnost
• Systémy by tedy měli být lehce rozšiřitelné pro budoucí expanzi.
o Rozmanitosti (zařízení a uživatelů)
• Poskytovatel obsahu musí brát zřetel různá zařízení a poskytovaný obsah jim přizpůsobit.
o Ziskovost
• Jak peněžní, tak duchovní
Content Delivery Network - definice
• CDN je skupina spolupracujících, geograficky
rozptýlených serverů nasazených pro usnadnění
distribuce informací generovaných webovými
vydavateli včas a účinně.
• Tato definice ovšem nezahrnuje kapacitu a výkon
rozptýlených serverů. Tyto dvě vlastnosti se většinou
určují na základě zkušeností administrátora systému.
Content Delivery Network - definice
• Technologie, která umožňuje nový pohled na rozložení
zátěže webových serverů mezi více uzlů.
• Systém serverů rozmístěných po internetu, které
spolupracují pro zajištění rychlého doručení dat klientovi.
• Virtuální vrstva nad fyzickou infrastrukturou, která funguje
na principu proxy serverů.
• Primárně se hodí pro statická data nebo pro data, která
se mění jen v dlouhých časových intervalech.
• Typický provoz - statická multimediální data, distribuce
aktualizací SW zákazníkům
• Požadavky uživatelů jsou rozprostřeny přes servery podle
požadavků, které jsou na síť kladeny.
Historie internetu a CDN
Historie internetu a CDN • Vylepšený Web server
o Při nedostatku výkonu na straně serveru se „vylepšilo železo“
• Nasazení cache proxy o Požadavky uživatelů jdou v tomto návrhu přes proxy cache server u ISP.
o Proxy server uchovává ve své cache nejčastěji navštěvované stránky.
• Hierarchické cachování o Úrovně mohou být například lokální, regionální, mezinárodní…
• Serverové farmy o Škálovatelné řešení, které se používalo a používá v posledních letech.
o Využívají přepínání na 4-7 úrovni OSI modelu (inteligentní přepínání založené na URL, typu obsahu a uživatelském jméně).
o Celý systém je dobře škálovatelný, odolný proti poruchám díky replikacím obsahu
o Nevýhoda je, že farma je stále „na jednom místě“
Historie internetu a CDN • První generace CDN
o Snaží se odstranit problém serverových farem (umístění na jednom místě)
o Geograficky rozděluje uzly participující v CDN
o Zaměření na statický a dynamický obsah stránek
• Druhá generace CDN o Pozornost přesunula k Video-on-Demand (video na požádání), News-on-
Demand (novinky na požádání), audio a video streaming s vysokou
uživatelskou interaktivitou
o Doručování obsahu na mobilní zařízení
Architektura CDN
• Cíle při návrhu CDN: o Celý systém lehce rozšiřitelný
o Při zjištění úzkého hrdla systému (výpočetního) -> přidání nového uzlu
o Distribuce obsahu s vysokou kvalitou za co nejmenší nákladovou cenu
o Bezpečnost (eliminace neautorizovaného přístupu a modifikace
uložených dat)
o Odolnost proti DoS a DDoS útokům
Architektura CDN
Architektura CDN • Server s originální informací (Origin server)
o Základní stavební jednotka CDN
o Obsahuje konzistentní data, která poskytuje ostatním serverům v CDN
o Obsahuje statická data (statické HTML stránky, obrázky, dokumenty,
balíčky software) nebo videa (uživatelem generovaná, streamovaná a
real-time videa)
o Obsahuje také algoritmy (programy) pro generování dynamického
obsahu stránek
o Může obsahovat databázový server (data pro dynamicky generované
stránky)
o Všechny tyto informace poskytuje na základě požadavků uživatelů na
hranové servery.
o Požadavky na velké úložní prostory, menší na rychlost
Architektura CDN • Hranový server (Edge server)
o Základní stavební jednotka CDN
o Obsahuje replikace informací, které dále poskytuje uživatelům
o Umístěn v nějaké dané geografické lokalitě
• Předpokládá se, že uživatelé v této lokalitě budou požadovat určitý
druh informací
• Tato data se budou na hranovém serveru ukládat prioritně (např.
softwarový balíček s danou jazykovou mutací)
• V jiných lokalitách tato data nebudou tak třeba
o Požadavky na rychlost, menší na velikost úložiště
o S origin serverem tvoří dohromady content-delivery
o S origin serverem bývá často spojen pomalými WAN linkami
Architektura CDN • Směrovač požadavků (Request Routing System)
o Na základě informace, odkud pochází požadavek, rozhoduje, který hranový server bude použit
o Využívá informace ze 4 až 7 vrstvy OSI (TCP protokol + aplikační protokol)
o Musí existovat DNS záznam, který odkazuje na směrovač a nikoli na hranový server
• Monitorovací systém (Accounting System) o Monitorování a udržování logů o přístupu uživatelů
o Zaznamenává vytížení jednotlivých CDN serverů
• Rozhodnutí o replikaci serveru
o Informace pro výpočet částky za distribuci informace
• Systém pro distribuci dat (Distribution System) o Stará se o konzistentnost dat na hranových serverech
o Několik algoritmů pro přenos dat z Origin do hranových serverů viz dále v přednášce
Distribuce obsahu, Rozdělení webové aplikace
Distribuce obsahu, Rozdělení webové aplikace
• Front-end vrstva o Rozhraní pro přístup k webovým službám
o Přímá požadavky od uživatelů (prováděné pomocí HTTP), poskytuje uživatelům statický obsah webu a slouží pro přístup k aplikační vrstvě.
o Statická data jsou uložena v souborovém systému
• Aplikační vrstva o Zodpovědná za business logiku a zpracování informací, které jsou poté
použity na generování dynamického obsahu
o Generování dynamického obsahu často vyžaduje spolupráci s back-end vrstvou a vrstvou uživatelského profilu
• Back-end vrstva o Uložení a poskytování dat (typicky v databázi)
• Vrstva uživatelského profilu o Uložení informací o preferencích uživatele (pro generování
personalizovaného obsahu stránek)
Distribuce obsahu • Replikace dat na Front-end vrstvě
o Slouží ke snížení používání WAN linek, které jsou náchylné na zahlcení při přenosu velkých dat
o Statický obsah stránek (většinou videa) je uchován v cache hranového serveru (zde také nazýván surrogate server)
o Důvody pro replikaci dat (videí):
• Při použití HTTP streamování nedochází k rozptylu rychlosti přenášených částí a přehrávání multimédií je plynulejší
• Nedochází ke zpoždění při přenosu, který má vliv na uživatelovo vnímání rychlosti
o Distribuce souborů:
• pull bez spolupráce serverů – při chybějícím souboru jej načte z origin serveru
• pull se spoluprácí serverů – hranové servery spolupracují , chybějící soubor si mohou vyměnit
• push se spoluprací serverů – origin server zasílá novou verzi souborů do hranových serverů
Distribuce obsahu • Replikace dat na Front-end vrstvě (pokračování)
o Streamování videí
• Do cache se neukládají celé video soubory, ale jen často
přistupované části (segment caching)
• Pokud je soubor přistupován sekvenčně, mohou být v cache uloženy
fragmenty ze začátku souboru; fragmenty z konce se získají v průběhu
přehrávání (sequential caching)
• Pokud uživatelé často seekují na jedno místo ve videu (např.
přeskakují úvodní reklamu a titulky), je možné použít interleaved
caching
• Vhodný caching se volí na základě pozorování
• U každého fragmentu musí být informace, z jakého je souboru a jak
dlouho má být v cache
• O streamování videa bude ještě řeč dále
Distribuce obsahu • Replikace na aplikační vrstvě
o Úzkým hrdlem replikace na front-end vrstvě je, že umí replikovat jen
statický obsah
o Replikace na aplikační vrstvě zahrnuje přenesení kódu, který se stará o
generování dynamického obsahu (edge computing)
o Každý hranový server má svou vlastní kopii aplikačního kódu
o Back-end aplikace stále běží na origin serveru
o Příchozí požadavky mohou být transakční a netransakční
• Transakční požadavek bude data měnit, vyžaduje tedy přístup přímo
na origin server
• Netransakční požadavek data pouze čte, může být obsloužen na
edge serveru
o Distribuce kódu pro generování obsahu (stránek) má na starosti origin
server. Při změně kódu je nový kód hned poslán na hranové servery.
o Nevýhody: pomalá WAN linka pro distribuci dat a centrální databáze na
straně origin serveru
Distribuce obsahu • Replikace na back-end vrstvě
Distribuce obsahu • Replikace na back-end vrstvě (pokračování)
o Replikace části nebo celé databáze pro vytváření dynamického obsahu
stránek
o Content-blind caching
• Hranový server výsledky často používaných databázových dotazů
• Při opakujících se dotazech - výsledky uchovávány v cache dlouho
• Řešení pomocí tzv. TTL (Time-To-Live)
• Jiné řešení je invalidce ze strany origin serveru pomocí skupinového
vysílání (ale zatěžování WAN linek)
• Obecně lze Content-blind caching použít za předpokladu, že se data
v databázi budou jen žřídka měnit.
o Content-aware caching
• Hranový server musí mít svůj databázový server
• V této databázi se zrcadlí část databáze z origin serveru (často
přistupovaná data) – distribuovaná databáze
Distribuce obsahu • Replikace na back-end vrstvě (pokračování)
o Content-aware caching
• Nevýhoda – neexistuje nástroj, který by distribuovanou databázi plně
podporoval (většinou je třeba centrální koordinátor dotazů)
• Nevýhoda – žádný z dostupných nástrojů neuvažuje pomalé linky
o Replikace celé databáze
• Hranové servery mají identickou kopii databáze (slave kopie; na origin
serveru master kopie)
• Nutnost propagovat změny v DB (zpět do master a pak k ostatním slave)
o Eager přístup – všechny změny ihned propagovány do všech
databází
o Lazy přístup - propagována pouze informace o změně, při
požadavku na změněnou informaci je tato dodatečně stažena
z centrální databáze
• Opět problém při uvažování pomalých linek mezi uzly
o Nejčastěji používaný přístup – Content-blind caching
Distribuce obsahu • Replikace na vrstvě uživatelského profilu
Distribuce obsahu • Replikace na vrstvě uživatelského profilu
o Vyžaduje databázi pro ukládání dat
o Replikace databáze jsou podobné jako v back-end vrstvě
o Rozdíl – v případě uživatelského profilu jsou data uložena jen na jednom
hranovém serveru, se kterým uživatel často komunikuje (nejsou posílána na
centrální server)
o Při přesunu uživatele – nutné zajistit migraci dat z hranového uzlu na jiný
hranový uzel
o Možnost řešení – centrální prvek při nemožnosti komunikace mezi jednotlivými
hranovými uzly
Generování dynamických stránek
• Je podmíněno existencí „generátoru“ stránek na
hranovém serveru a dále přítomností částí
(fragmentů) stránek
• Generátorem stránek se rozumí aplikace, která na
základě požadavku uživatele zajistí fragmenty a dá
je dohromady ve výslednou stránku
• Dynamickým obsahem stránek se může rozumět
výsledek hledání na vyhledávacím serveru, aktuální
zprávy na zpravodajském serveru atd.
• dynamický obsah stránek se může měnit v závislosti
na čase nebo na požadavcích uživatele
Generování dynamických stránek
• Při časových změnách - hranový server v pravidelně
kontaktuje origin server
• V případě vyhledávání hranový server uchovává
výsledky častých dotazů v databázi a vracet je
rovnou uživateli
• Veškeré informace pro generování stránek jsou
uloženy v lokální databázi na hranovém serveru
• Některé části stránky se mění častěji než jiné
• U každé části stránky se uchovává, jak často se má
v hranovém serveru aktualizovat – pomocí
značkovacího jazyka ESI
Generování dynamických stránek, ESI
• ESI (Edge Side Includes) o Jazyk založený na XML
o Navržen tak, aby byly využity prostředky (např. cache) pro lepší vnímání
výkonu systému na straně koncového uživatele a k zmenšení nutnosti
komunikace s origin serverem
o Vyvinut společnostmi Akamai, ATG, BEA Systems, Circadence, Digital
Island, IBM, Interwoven, Oracle a Vignette
o Definuje fragmenty, ze kterých se má stránka skládat
o Každému fragmentu lze určit zdroj, odkud pochází; životnost; jestli se má
cachovat nebo má být pokaždé načten z origin serveru a další parametry
o Lze také definovat css styl, který má být použit na vykreslení stránky
o Pomocí ESI lze identifikovat prohlížeč, následně generovat stránky přímo
určené pro daný prohlížeč
o V ESI lze i deklarovat proměnné a pracovat s nimi
Generování dynamických stránek, ESI
• Příklad:
• ESI se pokusí načíst stránku 1.html a vložit ji do do
aktuálně sestavované stránky. Pokud stránka 1.html
nebude existovat, pokusí se vložit stránku 2.html.
Pokud ani ta nebude existovat, nebude na toto
místo vloženo nic a pokračuje se v generování
stránky. Dále je pomocí tagu max-age definováno,
jak dlouho se má stránka udržovat v cache (300s).
<esi:include src="http://example.com/1.html" alt="http://bak.example.com/2.html" onerror="continue" max-age="300"/>
Generování dynamických stránek, ESI
• Příklad s proměnnými:
Další příklady: http://esi-examples.akamai.com/.
<!-- image list -->
<esi:assign name="image_list">
['quote1.gif','quote2.gif','quote3.gif','quote4.gif','quote5.gif']
</esi:assign>
<!-- choosing random offset -->
<esi:assign name="index" value="$rand()%$len($(image_list))" />
<esi:vars>
<!--
Index: $(index) <br>
Image: $(image_list{$(index)}) <br>
-->
</esi:vars>
<center>
<esi:vars>
<img src="$(image_list{$(index)})" border="0">
</esi:vars>
</center>
Streamování videa • Již jsme viděli, jak je možné uchovat video na
hranovém serveru o Segment caching (cachování často přistupované částí videa), sequential
caching (cachování částí videa, většinou začátku) a interleaved caching
(cachování míst, kam uživatelé často seekují)
• Existují i další možnosti doručení videa
• Zaměříme se na Live Stream (živé vysílání) a na
Video-on-Demand (video na požádání)
Streamování videa – živé vysílání
• V klasickém pojetí se používá multicast a IGMP protokol
• Nelze vyžadovat zajištění QoS (Quality of Service) při
ztrátě proudu dat o Uživateli se tato ztráta jeví jako rozpad obrazu či chvilková ztráta zvuku
• Využití CDN při živém vysílání o Cachování na straně hranových serverů
• Proud dat je odeslán ze zdrojového serveru do CDN sítě, krátkou dobu
cachován na hranovém serveru a odeslán uživatelům. V koncové síti se
video opět šíří pomocí multicastu.
• Výhoda tohoto řešení je, že nasazení CDN zabraňuje ztrátě paketů při
přenosu streamu ze zdrojového serveru ke koncovým uživatelům.
• Pokud k jednomu hranovému serveru bude připojeno více koncových sítí
požadujících různé streamy, může opět dojít ke ztrátě dat (zahlcení
hranového serveru).
• Stále zde zůstává otázka šíření streamu v lokální síti, kdy stále může opět
docházet ke ztrátě paketů a rozkladu přehrávaného videa.
Streamování videa – živé vysílání
o Cachování na straně hranových serverů
Streamování videa – živé vysílání
o P2P překrytí CDN sítě
• Pro eliminaci ztráty proudu dat je možné nad hranovými
servery vybudovat P2P architekturu
Streamování videa – živé vysílání
o P2P překrytí CDN sítě
• Pro eliminaci ztráty proudu dat je možné nad hranovými servery
vybudovat P2P architekturu
• v CDN je umístěn tzv. vstupní server, ze kterého je proud přenášen
na hranové servery
• P2P přináší do CDN technologii Probe-based overlay routing
(routování pomocí sond)
• Sondy monitorují linky mezi datovými centry a udržují směrovací
tabulky pro směrování mezi servery
• Když chce hranový server získat stream, je aktivována lokální
sonda, která zajistí nejlepší (nejrychlejší) cestu pro získání streamu
• Systém je díky P2P lépe rozšiřitelný
• Datové streamy v této síti jsou posílány po nejrychlejších linkách
Streamování videa – živé vysílání
o P2P sít u koncových uživatelů
• V klasickém pojetí koncové sítě může docházet při zahlcení
směrovače (-ů) k zahazování paketů
Streamování videa – živé vysílání
o P2P sít u koncových uživatelů
• V klasickém pojetí koncové sítě může docházet při zahlcení
směrovače (-ů) k zahazování paketů
• Klientská P2P síť je v tomto případě zodpovědná za doručení
streamu ke koncovému uživateli
• Dvě kategorie klientů: push peer a normální P2P klienti
• Push peer udržuje (tzn. přímá a krátkodobě cachuje) celý
datový proud přímo od hranového serveru
• Normální P2P klienti poptávají stream od ostatních klientů
• Čím více push serverů bude v koncové síti, tím lepší bude QoS u
koncových uživatelů
• Zároveň ale bude více zatížena linka(-y) k hranovým serverům.
• Při přenosu dat mezi push peery a hranovými servery se již
nepoužívá multicast ale unicast
Streamování videa – Video-on-Demand
• Video, které je uloženo jako datový soubor
na vzdáleném serveru a uživatel si jej chce
on-line přehrát
• Některé servery poskytují tato videa zdarma
(např. youtube.com), někdy jsou tato videa
placené (např. on-line video půjčovny)
• Koncový uživatel si přeje, aby se video
přehrávalo plynule a aby bylo možné v tomto
videu seekovat (přeskakovat)
Streamování videa – Video-on-Demand
• Využití CDN pro doručení: o V tomto případě je možné cachovat na hranových serverech celé
video soubory (nebo jejich větší část)
o P2P překrytí na straně CDN již není potřeba
o V koncových sítích je vhodné použít P2P síť pro zajištění QoS
Streamování videa – Video-on-Demand
• Využití CDN pro doručení: o Problém s autorizací uživatelů
o „Pokud si některý z uživatelů chce půjčit video on-line, musí
prokázat svou identitu a také prokázat, že za „půjčení“ videa
zaplatil.“
o Řešení – tracker server - udržuje informaci o všech uživatelích a
videích uložených na hranových serverech
o Při požadavku na video zjistí tracker server, jestli je toto video
přítomno v síti a jestli k němu má klient oprávnění přistupovat
o Pokud ano, je klient přesměrován na hranový server, který mu toto
video poskytne.
o Tracker server zároveň slouží k vyvažování zátěže mezi hranovými
servery
Case study • Akamai
o Založena v roce 1998 z podnětu MIT (Massachusetts Institute of
Technology)
o Důvodem - zamezení tzv. flash crowd (volně přeloženo jako náhlé zácpy,
nával na internetu)
o Je vůdce trhu v doručování obsahu, kdy pokrývá 90% trhu, má 84000
serverů v 72 zemích
o Přes servery Akamai denně projde 15-20% celosvětového provozu na
internetu
o Akamai servery poskytují statické objekty, dynamicky generované stránky,
streamované video a audio
o Snaží se předcházet flash crowd umístěním více serverů do míst, kde
očekává větší provoz (více požadavků od klientů)
o Při požadavku klienta na obsah, systém přesměruje tento požadavek na
nejbližší dostupný server
Case study • Akamai
o Topologie sítě se získá z hraničních směrovačů, z nichž používají informace
BGP protokolu
o Poskytuje automatické řízení sítě pomocí mapování, které používá
dynamický DNS systém
o Mapovací systém používá k rozhodnutí o nejvhodnějším serveru informace
o umístění klienta, stavu sítě a požadavku klienta
o Dynamické DNS je také používáno k rovnoměrnému zatížení sítě
(průběžně monitoruje služby a zatížení serverů)
o Pro monitorování stavu komunikace od uživatele až k serveru se používají
agenti, kteří simulují chování koncových uživatelů
• Detekují a vyřazují z provozu problematické uzly v síti
• Při odpojení serveru ze sítě nebude dočasně jeho IP adresa používána
o Pro doručování obsahu používá HTTP a HTTPS protokol
Case study • Akamai
o Pro statické webové objekty, uchovává Akamai různé druhy atributů,
které jsou důležité pro přenos k uživateli (např. životnost objektu, řešení
bezpečnosti přes HTTPS protokol, alternativní obsah, kódování přenosu,
cookies).
o Dynamický obsah je generován na hranových serverech pomocí
technologie ESI
o V přehrávání streamovaných videí Akamai podporuje Microsoft Windows
Media, Real a Apple QuickTime
o Stream je nejprve zachycen poskytovatelem obsahu a následně zaslán
do vstupního serveru Akamai, který je spojen s hranovými servery Akamai
o Na hranové servery se videa kopírují na základě požadavků uživatelů
Case study • Globule
o Technologie vyvinutá na Vrije Universiteit v Amsterdamu
o Síť spolupracujících uzlů zapojených do P2P sítě
o Součástí této sítě jsou i uzly koncových uživatelů
o Každý uzel v této síti poskytuje své dostupné zdroje (paměť, šířku pásma a
výpočetní výkon).
o Poskytuje replikaci obsahu, monitorování serverů a přesměrovaní
požadavků klientů na dostupné repliky
o Existují zde tzv. místa (site), která jsou definována jako kolekce dokumentů,
které patří jednomu uživateli
o Dále zde existuje proces server, který je instancí Globule software
o Každé místo - čtyři druhy serverů: server s originální informací, záložní
server, replikační servery a směrovací server
• Server s originální informací drží všechny dokumenty a může je
distribuovat do ostatních zúčastněných serverů
Case study • Globule
o Každé místo - čtyři druhy serverů: server s originální informací, záložní
server, replikační servery a směrovací server
• Záložní server obsahuje záložní kopii všech dokumentů
• Replikační servery uchovávají část dokumentů (při velké kapacitě
mohou i všechny)
• Směrovací server je zodpovědný za směrování požadavků uživatelů
na optimální replikační server
o Směrování v Globuli může směrovat na základě rozboru HTTP požadavku
nebo na základě DNS
o Jako měřítko se v Globuli používá zpoždění při komunikaci mezi servery
o Globule je implementována jako modul pro Apache HTTP Server