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