iX 11/2017
S. 122
Praxis
Content Delivery Network
Aufmacherbild

Selbstbau-CDN mit freier Software

Nicht von der Stange

Wer ein Content Delivery Network braucht, muss nicht unbedingt zu einem kommerziellen Anbieter gehen: Mit freier Software und passenden Skripten lässt sich ein CDN auch in Eigenregie betreiben.

Gegen ein professionelles Content Delivery Network können diverse Gründe sprechen: Es ist zu teuer, die Abdeckung zu gering oder die Vertragslaufzeit zu lang. Oder der Dienst passt nicht zum Portfolio des Anbieters. Nutzt man das CDN nur unternehmensintern oder transportiert es vertrauliche Informationen, hilft Selbermachen.

So ein selbst gebautes CDN soll auf angemieteten oder vorhandenen Servern mitlaufen. Seit einiger Zeit gibt es virtuelle Private Server (VPS) schon für wenige Euro monatlich. Je nach Anbieter steht eine stattliche Auswahl an Linux-Distributionen bereit; das hier vorgestellte Selbstbau-CDN nutzt ein CentOS-System.

Auf allen VPS müssen jederzeit die Inhalte der Anwendung identisch sein. Da es keine Garantie für die Netzqualität gibt, sollte die Replikation mit hohen Latenzen und Paketverlusten zurechtkommen. Unnötige Synchronisation ist jedoch zu vermeiden, da manche Anbieter die übertragene Datenmenge mitberechnen.

Mal ist es sichtbar, mal nicht

Je nach Blickwinkel sieht das Content Delivery Network unterschiedlich aus. Aus Sicht des Clients gibt es gar keines: Das eigene Betriebssystem löst den Servernamen per DNS auf, die Anwendung nimmt Kontakt auf und erhält Daten. Die Serverseite erledigt die ganze Arbeit und beantwortet die beiden zentralen Fragen:

 Wie hält man alle Server synchron?

 Wie bringt man den Client zum richtigen Server?

Linux-typisch gibt es Auswahl: Den Abgleich der Dateisysteme übernimmt XtreemFS ([1], siehe „Alle Links“) oder lsyncd, um die richtigen DNS-Antworten kümmert sich PowerDNS. XtreemFS hat seine Stärken, wenn alle CDN-Server im gemeinsamen Datenverzeichnis schreiben und lesen sollen. Bei lsyncd gibt es einen führenden Server mit Schreibrechten, alle anderen dürfen nur lesend auf die Dateien zugreifen.

An einem Mini-CDN mit Standorten in Deutschland, China, den USA und Südafrika sei das Vorgehen erläutert. Eine zentrale Rolle spielt die Namensauflösung. Denn bei einem CDN muss der Client die Adresse des vorteilhaftesten Servers erhalten, und das ist in der Regel der geografisch nächste.

Mithilfe von Geofunktionen liefert DNS die IP-Adresse eines nahe gelegenen Servers (Abb. 1).

Eine geooptimierte Namensauflösung (siehe Abbildung 1) beginnt wie jede andere DNS-Anfrage: Der Client erkundigt sich nach einem Hostnamen oder beauftragt seinen DNS-Server mit dieser Aufgabe. Bei www.example.net beispielsweise wandert die erste Anfrage gezielt an den für die .net-Zone verantwortlichen DNS-Server. Er verweist wiederum auf seinen Kollegen, der sich um die Domain example.net kümmert (Schritt 1). Jener darf nun nicht die IP-Adresse von www.example.net liefern, sondern muss an einen CDN-Server verweisen (Schritt 2). Die letzte DNS-Frage stellt der Client an dessen DNS-Server (Schritt 3), der schließlich die IP-Adresse des nächstgelegenen CDN-Servers liefert.

Geofunktionen liefern das Herkunftsland

Basis dafür sind die inzwischen von allen großen Playern der DNS-Branche bereitgestellten Geofunktionen. Dadurch enthält die anfragende IP-Adresse die Nationalität des Clients, die man bei der Auswahl der DNS-Antwort berücksichtigen kann. Die bekannten Dienste erwarten dafür eine feste Zuweisung der 250 Herkunftsländer zu den CDN-Knoten. Das lässt sich zwar per Skript erledigen, aber für das Demo-CDN kommt eine dynamische Alternative zum Einsatz: Ein Skript berechnet für den DNS-Server bei jeder Abfrage die Entfernungen zwischen Client und CDN-Servern. Derjenige mit der geringsten Distanz gewinnt.