Internet je postaven tak, aby odolal jadernému úderu Varšavské smlouvy. To byl koneckonců i původní zámysl DARPA (Defense Advanced Research Project Agency) – vytvořit komunikační prostředí, jenž se s uvedenou krizovou situací vyrovná. Vyjma této vlastnosti, která již dnes zřejmě není třeba, se Internet vyznačuje mimořádnou mírou přizpůsobivosti nárokům uživatelů. Nicméně stejně jako v každém systému, i zde existují pro poskytovatele obsahu úzká místa.
Těmi jsou hlavně uzly, které nabízejí informace klientům. Zatímco v dřevních dobách byla většina aplikací rozumně distribuovaná (vzpomeňme veterány Internetu – news, SMTP nebo mirrory FTP serverů), s příchodem webu a komerce obecně nastala koncentrace dat do několika málo lokací. Přestože disponovaly poměrně kvalitní konektivitou, v krizových situacích nebyly schopné zvládnout nápor požadavků.
Jako příklad můžeme uvést přerušenou trať na západním pobřeží USA (v roce 1998), podle níž byl tažen jeden z hlavních optických kabelů do oblasti Silicon Valley. Tehdy se v plné nahotě ukázalo, že záložní trasy nejsou dostatečně dimenzovány.
Problémem je samozřejmě také soustředění výpočetního výkonu a jeho management. Výkon s vynaloženými prostředky ani zdaleka nestoupá lineárně, takže zvýšení výkonu hardware za 1.000.000 dolarů na dvojnásobek rozhodně nestojí další milion (spíše deset). Takže je naddimenzován pouze rozumně. Díky tomuto faktu pak mohla klasická média hlásit po pádu dvojčat, že Internet nestíhal – přitom nestíhaly pouze webové servery provozované CNN.
Posledním hřebíčkem do rakve klasickému rozložení je nástup streamovaného videa (přenosy v reálném čase). Protože je Internet natolik heterogenní, že není možné spoléhat na to, že po celé trase je k dispozici stejné zpoždění (a že bude minimální), je třeba obsah umístit někam poblíž uživatelů – respektive na místo, které mají dobře dostupné.
Prvním typem řešení, které se uplatňuje především pro distribuci audia a videa (hlavně v akademických sítích) je skupinové adresování – multicasting. Jeden zdroj dokáže obsloužit fakticky všechny klienty, kteří o to požádají – a to pouze jedním připojením. Tato aplikace se bohužel hodí pouze pro souběžně běžící klienty (viz televizní vysílání). Veškerá logika doručování obsahu leží na aktivních prvcích IP vrstvy a implementace multicastingu v operačních systémech směrovačů patří k těm částem kódu, které jsou nejvíce zanedbané. Proto jej podporuje relativně málo sítí.
Druhou možností jsou tzv. Content Delivery Networks (CDN). Ty představují metasíť nad fyzickou infrastrukturou, která funguje na principu proxy serverů. Takový systém samozřejmě nelze použít pro dynamicky se měnící obsah, například stránky webzinu. Nicméně většinu datového provozu tvoří multimediální data, které se nemění. Specifickou potřebou je distribuce binárních souborů – nejčastěji bezpečnostních záplat nebo nových signatur virů do antivirových balíků.
Základem je tzv. centrální prvek systému, který řídí datové toky v síti a přesměrovává dotazy klientů na servery, které jsou k nim blízko. Koncové farmy CDN pak postrádají inteligenci, jejich funkčnost je podobná jako v případě klasického mechanismu proxy cache. Nemají-li požadovaný obsah, obrátí se na předem definované místo, odkud jej obratem získají. Princip se v průběhu času měnil.
Zpočátku byli zákazníci (tj. poskytovatelé obsahu) nuceni implementovat odkazy na dynamický přesměrovávač provozu, který dle IP adresy koncového uživatele přesměroval odkaz na nejbližší farmu CDN (klasickým protokolem HTTP, případně obdobným mechanismem u streamovaného audia/videa). Tento způsob měl několik nevýhod. Nutil zákazníky zasahovat do vlastního kódu, který potom nemusel být homogenní a neumožňoval práci jiných aplikací než těch fungujících na obsažených aplikačních branách.
Proto přibližně před rokem a půl přešla většina CDN na chytřejší model, kdy je řízení datového toku realizováno přímo přes DNS. Čas expirace příslušné zóny nebo záznamu zabraňuje tomu, aby byl v DNS serverech kešován – klient dostane adresu farmy, která má nejlepší dostupnost v jeho části sítě (například záznam download.microsoft.com má pro většinu českého Internetu adresu 195.113.150.14, ale třeba pro zákazníky rakouského KPNQwestu 193.80.200.137). Díky tomu je možné transparentně přesměrovávat dotazy už na úrovni DNS – stačí, aby na CDN farmě běžel server poskytující data a není třeba žádná další spolupráce se zákazníky.
Existují dva obchodní modely pro budování CDN. Většina CDN funguje podobně jako Digital Island. To znamená, že své servery umisťuje do několika málo peeringových center a spoléhá na to, že se jim podaří uzavřít dohody s tranzitními operátory. Tento model je zajímavý a umožňuje dosáhnout slušných výsledků s minimem hardware, nicméně překážkou jsou poplatky za peering.
Unikátem mezi CDN je Akamai. Jejich byznysplán spočívá v tom, že umisťují servery zdarma u poskytovatelů internetového připojení (ISP) a umožňují jim tak získat výhody z faktu, že jejich zákazníci budou mít dostupný atraktivní obsah lokálně (ani druhá strana nic neplatí). Akamai přitom respektuje přání ISP ohledně distribuce obsahu farem. Pokud si to nebudete přát, vaši konkurenti nebudou moci obsah z farmy umístěné u vás čerpat apod. Jak už bylo řečeno, servery jsou prosty inteligence – jde o 1U PC vybavené dostatkem diskové kapacity, na nichž běží Linux.
Pokud se týče využívání farmy Akamai umístěné u CESNETu, která slouží většině Internetu v České republice, máme k dispozici čtyři grafy, které dokumentují užitečnost CDN.
26. září 2001 – [Větší obrázek]
září 2001 – [Větší obrázek]
9. května 2002 – [Větší obrázek]
konec března/duben 2002 – [04.gif]
Příkladem, který ukazuje, že CDN je skutečně potřeba, je Microsoft. Zpočátku obsluhoval celou svou webovou farmu sám. Po čase přestala stačit kapacita, kterou byla připojena k Internetu. Microsoft motivoval lokální partnery k vybudování ODS (Online Distribution Servers/Sites). Bohužel časem zatoužil, aby jeho webová farma byla největší na světě, takže svěřil management obsahu jednomu partnerovi, u kterého ji umístil. Po roce pravděpodobně seznal, že požadavky klientů překračují kapacitu systému a svěřil obsah download serverů do rukou Akamai.
Nicméně, protože nic není dokonalé a i mistr tesař se občas utne, nabízím dostupnost serveru download.microsoft.com z jedné české sítě (zákazníka EBONE/KPNQwest), která sice může čerpat obsah z farmy na CESNETu (dva hopy přes NIX.CZ), nicméně u Akamai usoudili, že je lépe dostupná jiná farma. Takže data cestují po celé Evropě.
D:>tracert download.microsoft.com
Tracing route to a767.ms.akamai.net [193.80.200.137]
over a maximum of 30 hops:
1 xxxxx
2 xxxxx
3 10 ms czpra103-tc-f6-1.kpnqwest.net [195.158.242.145]
4 10 ms debln302-tc-p2-0.kpnqwest.net [213.174.70.45]
5 30 ms sesto303-tc-p5-0.kpnqwest.net [213.174.71.105]
6 41 ms sesto502-tb-r5-0.kpnqwest.net [213.174.69.148]
7 40 ms r4-PO3-1-0.sthm-YNG.SE.kpnqwest.net [134.222.249.29]
8 50 ms r5-PO0-2.sthm-KPN1.SE.kpnqwest.net [134.222.229.18]
9 40 ms r2-Ge0-2-0-0.Sthm-KQ1.SE.KPNQwest.net [134.222.119.226]
10 50 ms r2-Se0-3-0.hmbg-KQ2.DE.KPNQwest.net [134.222.230.157]
11 40 ms r1-Se2-0-0.0.Hmbg-KQ1.DE.kpnqwest.net [134.222.230.49]
12 50 ms r1-Se0-1-0.0.Blnd-KQ2.DE.kpnqwest.net [134.222.230.37]
13 50 ms r1-Se0-1-0.0.mchn-KQ1.DE.kpnqwest.net [134.222.230.42]
14 80 ms r2-Se0-0-0.0.mchn-KQ1.DE.kpnqwest.net [134.222.230.202]
15 60 ms r3-Se2-0-0.0.Wie-KQ1.AT.KPNQwest.net [134.222.230.154]
16 60 ms R1-Dbg1.Vie.AT.KPNQwest.net [134.222.230.62]
17 60 ms r6-Fa2-0-0-Dbg2.Vie.AT.KPNQwest.net [193.154.144.16]
18 60 ms a193-80-200-137.deploy.akamaitechnologies.com[193.80.200.137]
Další relevantní odkazy na fungování CDN je možné nalézt na webu Akamai.
ČLÁNKY DO MAILU
