Hoge kwaliteit en beschikbaarheid van content Peter Jurg (
[email protected]) Erik Frambach (
[email protected]) 25 april 2001, versie 1 Samenvatting Om internetdiensten te kunnen leveren met een hoge performance en beschikbaarheid zijn de laatste jaren Content Delivery Netwerken opgebouwd. Deze maken gebruik van van content delivery methoden, content routing en load balancing. In dit artikel wordt ingegaan op de bestaande dienstverlening van leveranciers van content delivery netwerken en op producten en mogelijkheden om zelf een CDN te bouwen.
1
Inleiding
Een Content Delivery Netwerk, ook wel CDN genoemd, is een gedistribueerd netwerk waarvan de componenten content ‘dicht bij’ de gebruiker brengen. CDN’s zijn netwerken bovenop het bestaande Internet die worden gebruikt om de user experience bij het raadplegen van content zo optimaal mogelijk te laten zijn. Voor willekeurige content wordt de user experience al behoorlijk verbeterd door gebruik van ‘globale’ CDN’s met componenten die content kunnen serveren op belangrijke Internet eXchanges en een component bij grote ISP’s. Terwijl de gebruiker content opvraagt bij een (web)server die ‘ver weg’ staat (bijvoorbeeld in de VS als de gebruiker zich in Nederland bevindt), wordt deze uiteindelijk geserveerd vanaf een CDN component bij de gebruiker in de buurt. We maken al dagelijks gebruik van deze globale CDN’s, waarschijnlijk zonder het te weten. Voorbeelden van dergelijke CDN’s zijn Akamai, Digital Island en Enron. Maar des te meer bytes de content bevat en hoe kritischer de aflevering bij de eindgebruiker is (zoals bijvoorbeeld bij streaming content, waarvoor een constante bandbreedte/kwaliteit vereist is), des te meer loont het de moeite om een CDN op een kleinere schaal toe te passen. Leveranciers van breedband Internet (kabel, ADSL, glas, en dergelijke) zijn daarom op dit moment behalve naar de (multimedia) content zelf tevens op zoek naar fijnmazige CDNoplossingen. Deze zijn echter nog zo eenvoudig verkrijgbaar als de ‘globale’ oplossingen. Deels ligt het probleem bij het feit dat de business cases van de ‘globale’ CDN’s niet te vertalen zijn naar een fijnmaziger model. Grote content providers (zoals CNN) zijn bereid behoorlijke bijdragen te leveren voor de wereldwijde distributie van hun content (bijvoorbeeld via Akamai), maar voor distributie op kleinere schaal
is de bereidheid geringer, terwijl de kosten niet navenant lager zijn. Het idee is dan ook dat voor hoge kwaliteit contentleverantie op bijvoorbeeld nationale schaal de eindgebruiker op een of andere manier ook een bijdrage zal leveren (denk aan voetbalwedstrijden via DSL of video on demand, en dergelijke.). Deels ligt ook het probleem bij de techniek, want fijnmaziger CDN’s zijn bedoeld voor meer omvangrijke content die op een aantal vlakken andere eisen stellen aan de techniek. En daarmee is nog niet veel ervaring. In de volgende paragraaf wordt de functionaliteit van een CDN beschreven en in paragraaf 3 wordt een voorbeeld gegeven van een CDN. In paragraaf 4 worden de standaarden die worden gebruikt voor CDN’s aangegeven en vervolgens worden in paragraaf 5 de technische invullingen besproken. In paragraaf 6 worden de beveiligingsaspecten besproken en in paragraaf 7 de toekomstverwachtingen van CDN’s.
2
Functionaliteit
Voor een eindgebruikers is van belang dat een CDN hoge kwaliteit en beschikbaarheid levert en transparant is: De content wordt beschikbaar gemaakt vanaf een component dicht bij de gebruiker; dit is het probleem van ‘content routing’. De eindgebruiker wordt op transparante wijze doorverwezen naar een dichtbijgelegen component in het CDN, die op dat moment bereikbaar, beschikbaar is en niet teveel te doen heeft; dit is het probleem van ‘request routing’. Voor een content provider is van belang dat een CDN ook nog de volgende functionaliteit bezit: De mogelijkheid voor accounting en billing. De globale CDN’s maken hier vooralsnog geen ge-
bruik van, maar door hun business model is dat ook (nog) niet nodig. De mogelijkheid om overzichten over het gebruik te ontvangen (statistieken). Denk daarbij aan gegevens van een gebruiker (welke client-software, ISP), opgevraagde content, tijdstip van opvragen, beschikbaarheid, opgetreden fouten, et cetera). Toegang tot de (multimedia-) content kan desgewenst beperkt worden tot bepaalde tijdsintervallen, gebruikersgroepen en/of individuele gebruikers.
3
Voorbeelden
Als voorbeeld van een CDN zullen we kijken naar de dienst die Akamai biedt (zie ook http://www. akamai.com). Akamai biedt diensten aan een aantal grote klanten, waaronder Adobe, Apple, CNN en MSNBC. Deze klanten wijzigen de URL’s op hun webpagina’s die horen bij content die uit een substanti¨ele hoeveelheid bytes bestaat, zoals plaatjes en video’s. Een voorbeeld zijn de QuickTime filmpjes (trailers en dergelijke) die Apple aanbiedt. Zo’n URL ziet er dan bijvoorbeeld als volgt uit
en wordt ook wel ‘akaimized’ genoemd. De web browser van de gebruiker zal nu om de betreffende content op te halen via DNS het IP-adres opzoeken van a1696.g.akamai.net. Daarbij wordt contact gelegd met de name server voor akamai.net, die in tegenstelling tot een gewone name server niet altijd hetzelfde IP-adres teruggeeft. De name server van Akamai kijkt namelijk naar waar de gebruiker vandaan komt en gebruikt dan een (niet open, Akamaispecifiek) algoritme om het IP-adres van de dichtst bijzijnde Akamai-server te bepalen, die beschikbaar is en een goede performance kan leveren op dat moment. dat adres wordt vervolgens teruggegeven aan de gebruiker. De gebruiker legt vervolgens een verbinding met die server en vraagt de bovenstaande URL op. De Akamai server is een ‘gewone’ caching server en heeft de content zelf al beschikbaar als deze de laatste tijd al eerder is opgevraagd. Is dat niet het geval dan zal er gekeken worden of een andere server in de buurt de content al heeft of anders wordt het bij Apple zelf opgevraagd. Om dit concept te doen werken heeft Akamai een wereldwijd netwerk van caching servers (zie de figuur).
Akamai gebruikt zelf ontworpen caching systemen (gebaseerd op linux/intel) en een zelf ontworpen (niet publiek) algoritme om te bepalen van welke server via DNS het IP-adres geserveerd wordt bij een client request. Omdat de gegevens daarover niet publiek zijn is niet te zeggen hoe dit werkt. Er zijn echter op dit moment in de markt ook producten te koop waarmee soortgelijke functionaliteit bewerkstelligd kan worden. De paragraaf Techniek gaat daar nader op in.
4
Standaards
Internetstandaarden specifiek voor CDN’s zijn er (nog) nauwelijks. Uiteraard dient er tussen de componenten van het CDN en software van gebruikers gecommuniceerd te worden met gestandaardiseerde Internetprotocollen, maar voor de bijzondere functionaliteit van een CDN is niet echt iets gestandaardiseerd. Omdat er straks niet e´ e´ n CDN zal zijn maar vele CDN’s wordt er op dit moment wel gewerkt aan standaarden voor de koppeling van verschillende CDN’s. Dit zou onder andere als voordeel moeten hebben dat content providers hun content op dezelfde wijze aan verschillende CDN’s kunnen aanleveren (denk aan de ‘akamaizing’ van Akamai die niet strookt met content aanlevering aan andere CDN’s). Er zijn twee initiatieven die dit onderwerp van zogenaamde ‘content peering’ aanpakken: een groep die zich richt op standaardisatie via de IETF, de Content Alliance: http://www. content-peering.org een groep van leveranciers die zich richt op een minder open oplossing, de Content Bridge: http: //www.content-bridge.com
5
Techniek
CDN’s maken veelvuldig gebruik van loadbalancing en caching technieken. Loadbalancing wordt enerzijds gebruikt in de traditionele zin om de werkdruk
over clusters te spreiden en om redundantie in te bouwen. Anderzijds wordt loadbalancing op een intelligente manier toegepast om ervoor te zorgen dat content die door een klant wordt opgevraagd altijd wordt geleverd door de server of cache die het “dichtste bij” staat. Met deze techniek wordt getracht de user experience te maximaliseren en netwerkverkeer te minimaliseren. Zulke loadbalancing technieken kunnen gebaseerd zijn op aangepaste name servers die op een slimme manier het IP-nummer teruggeven van een machine die dicht bij de klant staat. De name servers houden daarom onderling contact zodat van elkaar weten “waar” ze staan en hoe hoog de belasting van de servers en caches op die locatie is. Om ervoor te zorgen dat IP-nummers steeds opnieuw worden gevraagd en dus niet gecached, wordt de time to live in zo’n constructie zeer laag ingesteld. Een andere methode is gebaseerd op HTTP redirects, waarbij URL’s herschreven worden zodanig dat weer de dichtst bijzijnde machine de content gaat leveren. Een nog andere manier lijkt enigszins op een distributed denial of service attack, maar dan richting klant: een groot aantal servers reageert synchroon op een vraag naar content door allemaal een respons naar de klant te sturen. Degene die het eerst aankomt wordt door de klant gebruikt; de rest wordt genegeerd. De server die “wint” is als het goed is de dichtst bijzijnde of minst bezette. Ook bij deze methode moeten de servers onderling contact houden, in dit geval om synchroon te kunnen reageren. Caches vormen een cruciaal onderdeel van een CDN. Deze machines zijn geoptimaliseerd om extreem veel content op te slaan en door te geven aan klanten, of aan caches verderop in het CDN. Door zorgvuldig gebruik van caches kan netwerkverkeer geminimaliseerd worden: wanneer content in de cache aanwezig is hoeft de bron (die ver weg kan staan) immers niet meer benaderd te worden. Bij breedband-toepassingen op grote schaal is dit bijzonder belangrijker. Caches moeten dus in staat zijn verschillende soorten content op te slaan en te serveren. Daarbij zullen verschillende netwerkprotocollen ondersteund moeten worden zoals HTTP, FTP, RTSP en MMS. Daarnaast moeten caches vanuit het CDN beheerd moeten kunnen worden, bijvoorbeeld om content push mogelijk te maken van zaken die naar verwachting veel opgevraagd zullen worden. Daarnaast moeten caches in staat zijn autorisatie voor de toegang tot content te regelen. Dat kan bijvoorbeeld via een LDAP interface ge¨ımplementeerd worden. Het spreekt vanzelf dat caches bijzonder goed beveiligd moeten zijn, zeker als ze content bevatten die niet vrijelijk verspreid mag worden, maar bijvoorbeeld al-
leen aan klanten die zich aanmelden met de juiste naam en het juiste wachtwoord. Een CDN zal in de praktijk vaak de domeinen van meerdere ISP’s overspannen. De grensvlakken tussen ISP’s kunnen flessenhalzen worden als de zaken daar niet goed geregeld zijn. Veel ISP’s hebben zogenaamde ‘peering’ overeenkomsten, waarin wordt vastgelegd hoe wordt omgegaan met verkeer dat vanuit aangrenzende netwerken binnenkomt en misschien weer naar andere netwerken verder reist. Ook kunnen meerdere CDN’s met elkaar samenwerken om nog betere performance en betrouwbaarheid te kunnen realiseren. Bovendien maakt zo’n samenwerkingsverband het voor content-leveranciers gemakkelijker om content op het Internet aan te bieden (´ee´ n loket). Het verkeer binnen het CDN kan indien gewenst beveiligd worden met encryptie. In de meest veilige opzet ‘praten’ de componenten van een CDN uitsluitend met elkaar en is afluisteren vrijwel onmogelijk. Aan de gebruikerskant kan gebruik worden gemaakt van SSL en authenticatie/autorisatie via bijvoorbeeld LDAP of RADIUS. Uiteraard hoort bij een omvangrijk CDN een goed monitoring-systeem om constant te kunnen zien of systemen goed functioneren. Veelal kan daar min of meer standaard programmatuur voor gebruikt worden, gebaseerd op bijvoorbeeld SNMP. Een content management systeem is verder nodig om bijvoorbeeld content push te regelen en de beschikbaarheid van content bekend te maken aan gebruikers via bijvoorbeeld een website.
6
Beveiliging
Het is gebruikelijk om de mate van beveiliging van Internetdiensten uit te splitsen naar Vertrouwelijkheid: de diensten kunnen alleen worden gebruikt door geautoriseerde gebruikers. Integriteit: de diensten mogen niet onbevoegd gewijzigd worden. Beschikbaarheid: de diensten zijn op het juiste moment beschikbaar voor de gebruikers ervan. Vertrouwelijkheid speelt alleen een rol bij content die tijdelijk beschikbaar wordt gesteld en/of aan een beperkte groep gebruikers (gebruikers die betalen voor content, bij een besloten doelgroep behoren, et cetera.). Zoals met alle content op het Internet is het lastig om te voorkomen dat gebruikers content waartoe ze toegang hebben kopi¨eren en verder verspreiden. Hoewel er mechanismen zijn die kopi¨eren lastig maken, is de mogelijkheid hiertoe uiteindelijk niet volledig uit de weg te ruimen. CDN’s zijn met name
bedoeld voor veel geraadpleegde content en niet voor incidentele content die voor de ogen/oren van een enkeling zijn bedoeld. Er mag daarom worden aangenomen dat zeer vertrouwelijke data niet via CDN’s wordt verspreid en dat afscherming voor een algemeen publiek meestal te maken heeft met commerciele belangen (alleen betalende gebruikers kunnen bij bepaalde content). Content-aanbieders dienen zich te realiseren dat volledige vertrouwelijkheid dan onmogelijk is en een zeker verlies door illegale kopie¨en van hun content moeten inbouwen in business modellen. Dan hebben we het over illegale kopie¨en met medewerking van geautoriseerde gebruikers, hetgeen zo lastig mogelijk gemaakt zou moeten worden. Een CDN kan daar geen voorzieningen voor treffen, die moeten in de content zelf zijn aangebracht. Maar een CDN zou wel moeten voorzien in een authenticatie/ autorisatiemechanisme dat zeer lastig te kraken is om fraude zonder medeweten van geautoriseerde personen te voorkomen. Gebruikers toegang geven tot lastig te raden URL’s nadat ze geautoriseerd zijn (nadat ze bijvoorbeeld betaald hebben) is dan een te zwakke methode. Er zou zo veel mogelijk gebruik gemaakt moeten worden van authenticatie op protocolniveau (HTTP, RTSP, et cetera) in het traject tussen een gebruiker en een component van het CDN. Verder wil een aanbieder van content natuurlijk overzichten hebben van wie wat heeft geraadpleegd (bijvoorbeeld bij betalende gebruikers), maar deze gegevens moeten tevens als zeer vertrouwelijk beschouwd worden om de privacy van de gebruikers te waarborgen (anders lopen die weg). Dus logs en statistieken moeten goed zijn beschermd. Met betrekking tot integriteit kan gezegd worden dat de componenten in het CDN goed beveiligd moeten worden tegen toegang door onbevoegden. Content bedoeld voor kinderen mag niet ineens vervangen worden door ‘adult’ content of iets dergelijks. Dit is vooral ook van belang als het CDN tevens wordt gebruikt voor content filtering of ‘localized’ content. De beschikbaarheid van het CDN moet hoog zijn omdat naast hoge kwaliteit een hoge beschikbaarheid een van de drijfveren is om een CDN op te zetten. De architectuur van een CDN moet dat toestaan. Dit kan bereikt worden door het inzetten van load balancers, clusters, en dergelijke.
bandaansluitingen op grote schaal. Denk daarbij aan ‘de kabel’, ADSL en zelfs fiber to the home. De ervaring leert dat alle beschikbare bandbreedte ook snel benut wordt. Wanneer met name aan de uiteinden van het netwerk, dus bij grote aantallen thuisgebruikers, veel bandbreedte nodig is, dan zullen de backbones daarop berekend moeten zijn. Verder opschalen van de bandbreedte van backbones is een optie, maar verhoging van de effici¨entie van de bestaande infrastructuur is wellicht minstens zo interessant. CDN’s bieden mogelijkheden om netwerkverkeer over lange afstand te beperken en tegelijk een hogere beschikbaarheid en kwaliteit te garanderen. Ze kunnen bovendien toegevoegde waarde bieden door extra faciliteiten zoals unieke content. We verwachten dat CDN’s een steeds grotere rol zullen spelen in het distribueren van content, maar gebruikers zullen er in de meeste gevallen niets van merken, behalve dat alles ‘lekker snel, soepel en betrouwbaar’ werkt. CDN’s zullen steeds vaker aan elkaar gekoppeld geworden, om van elkaars faciliteiten optimaal gebruik te kunnen maken. Bedrijven en instellingen die binnen hun eigen kring bijvoorbeeld wereldwijd veel content verspreiden zullen ofwel eigen CDN’s bouwen of gebruik maken van bestaande CDN’s waarvan zij bepaalde diensten afnemen.
8
Conclusies
Dankzij CDN’s kan het Internet een flink stuk groeien (in datadoorvoer), zonder dat daar al te zware investeringen tegenover staan zoals we die kennen van aanleg van grootschalige glasnetwerken. Op dit moment wordt nog veel ge¨experimenteerd met verschillende typen CDN’s, maar verwacht mag worden dat snel standaards ontwikkeld zullen worden waardoor het gebruik van CDN’s transparanter wordt. CDN’s zijn echter niet het laatste woord op het gebied van hoge kwaliteit en beschikbaarheid van diensten. Ze bieden duidelijke meerwaarde en zijn zeer goed schaalbaar naar grootgebruik, ongeacht de content die gedistribueerd moet worden.
Over de auteurs 7
Toekomst
Al een groot aantal jaren neemt het gebruik van het Internet door zowel bedrijven en instellingen als particulieren fors toe. Aangenomen mag worden dat dat voorlopig zo door zal gaan. Daarnaast is er een sterke tendens naar het aanleggen en gebruiken van breed-
Dr. Peter Jurg was van 1990 tot 1998 werkzaam bij SURFnet bv. Daar was hij projectleider voor innovatieve projecten op het gebied van Internetapplicaties en middleware en hoofdverantwoordelijk voor beheer van SURFnet diensten. Hij is mede-auteur van het boek ‘Het Internet als digitale snelweg (1995)’ en auteur van enkele RFC’s op het gebied van directories.
In 1998 was hij medeoprichter van Stelvio, een adviesbureau voor topexpertise op het gebied van internettechnologie en beveiliging, alwaar hij nu werkzaam is. Op dit moment is hij vooral betrokken bij high-speed multimedia dienstverlening en de architectuur van nieuwe dienstverlening bij ISP’s. Drs. Erik Frambach was van 1991 tot 2000 werkzaam bij de Economische Faculteit van de Rijksuniversiteit Groningen. Daar was hij werkzaam als advi-
seur netwerk- en applicatieprogrammatuur, en heeft verschillende internetdiensten opgezet en in de organisatie ge¨ıntroduceerd. Sinds 2000 is hij in dienst van Stelvio als adviseur Internettechnologie, en houdt zich onder meer bezig met breedband CDN’s en beveiliging van netwerkdiensten. Zie de Stelvio website (http://www.stelvio. nl) voor meer informatie, en voor een nieuwere en uitgebreidere versie van dit artikel.
