PDS Pavel Bžoch,

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-onDemand (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: Celý systém lehce rozšiřitelný Při zjištění úzkého hrdla systému (výpočetního) -> přidání nového uzlu Distribuce obsahu s vysokou kvalitou za co nejmenší nákladovou cenu Bezpečnost (eliminace neautorizovaného přístupu a modifikace uložených dat) o Odolnost proti DoS a DDoS útokům o o o o

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:include src="http://example.com/1.html" alt="http://bak.example.com/2.html" onerror="continue" max-age="300"/>

• 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).

Generování dynamických stránek, ESI • Příklad s proměnnými: <esi:assign name="image_list"> ['quote1.gif','quote2.gif','quote3.gif','quote4.gif','quote5.gif'] <esi:assign name="index" value="$rand()%$len($(image_list))" /> <esi:vars> Image: $(image_list{$(index)})
--> <esi:vars>

Další příklady: http://esi-examples.akamai.com/.

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 o o o o o o o

Technologie vyvinutá na Vrije Universiteit v Amsterdamu Síť spolupracujících uzlů zapojených do P2P sítě Součástí této sítě jsou i uzly koncových uživatelů Každý uzel v této síti poskytuje své dostupné zdroje (paměť, šířku pásma a výpočetní výkon). Poskytuje replikaci obsahu, monitorování serverů a přesměrovaní požadavků klientů na dostupné repliky Existují zde tzv. místa (site), která jsou definována jako kolekce dokumentů, které patří jednomu uživateli Dále zde existuje proces server, který je instancí Globule software 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