Bildquelle: Infografik-Vektor erstellt von pikisuperstar — www.freepik.com

Content Delivery Networks (CDN) werden im Allgemeinen von Websites und Anwendungen verwendet, um das Laden statischer Elemente zu beschleunigen. Dies wird durch Zwischenspeichern von Dateien auf CDN-Servern in verschiedenen Regionen der Welt erreicht. Nachdem der Benutzer Daten über CDN angefordert hat, erhält er sie vom nächstgelegenen Server.

Die zugrunde liegenden Prinzipien hinter CDNs und ihre Funktionalität sind für alle ungefähr gleich. Nachdem ein CDN-Server eine Anforderung für eine Datei erhalten hat, nimmt er sie einmal vom Ursprungsserver entgegen, überträgt sie dann an den Benutzer und speichert eine Kopie davon für einen bestimmten Zeitraum zwischen. Weitere Anfragen nach den Daten werden über den Cache abgewickelt. Alle CDNs verfügen über Optionen zum Vorladen von Dateien, Cache-Löschen, Cache-Aufbewahrungszeiten und vieles mehr.

Manchmal kann es aus verschiedenen Gründen erforderlich sein, ein eigenes CDN zu erstellen.

Wann benötigen Sie ein eigenes CDN?

Werfen wir einen Blick auf Situationen, in denen Sie möglicherweise Ihr eigenes CDN erstellen müssen:

• wenn Sie versuchen, Geld zu sparen und sogar erschwingliche Lösungen wie BunnyCDN kosten Sie Hunderte von Dollar pro Monat
• Wenn Sie permanenten Cache erhalten möchten oder garantierte Bandbreite und Ressourcen benötigen
• Vorhandene CDNs haben keine PoPs in Ihrer Zielregion
• Sie benötigen spezielle Einstellungen für die Inhaltsbereitstellung
• Sie möchten die Bereitstellung des dynamischen Inhalts beschleunigen, indem er näher an den Benutzern bereitgestellt wird
• Sie befürchten, dass CDNs von Drittanbietern Benutzerdaten illegal sammeln und verwenden (hey, Server, die dies nicht tun GDPR-konform) oder andere illegale Aktivitäten ausüben

In den meisten anderen Fällen ist es sinnvoller, vorhandene vorgefertigte Lösungen zu verwenden.

Erstellen wir ein eigenes CDN

Um auch nur ein einfaches Content Delivery Network aufzubauen, benötigen Sie Folgendes:

• domänenname oder eine Subdomain
• mindestens zwei Server in verschiedenen Regionen. Die Server können dediziert oder virtuell sein
• GeoDNS-Tool. Damit wird ein Benutzer, der eine Anfrage an die Domain sendet, an den nächstgelegenen Server weitergeleitet

Domain registrieren und Server bestellen

Die Registrierung eines Domain—Namens ist einfach – registrieren Sie ihn einfach in einer beliebigen Domain-Zone, die Sie bevorzugen. Für CDN können Sie auch eine Subdomain verwenden, wie cdn.domainname.com . Dies ist für das folgende Beispiel der Fall.

Wenn es um Server geht, sollten Sie diese in Regionen und Ländern mieten, in denen sich Ihre Zielgruppe befindet. Wenn Ihr Projekt interkontinental ist, können Sie aus Hosting-Providern auswählen, die Server auf der ganzen Welt anbieten, z. B. OVH, Leaseweb und 100 TB (für dedizierte Server) oder Vultr und DigitalOcean (für virtuelle und Cloud-Server).

Für unser privates CDN bestellen wir drei virtuelle Server auf verschiedenen Kontinenten. Vultr bietet uns 25 GB SSD-Speicherplatz und 1 TB Datenverkehr für 5 USD / Monat. Wählen Sie während der Installation das neueste Debian aus. Hier sind unsere Server:

• Frankfurt am Main, Deutschland: 199.247.18.199

• Chicago, ip: 149.28.121.123

• Singapur, IP: 157.230.240.216

Konfigurieren von GeoDNS

Um sicherzustellen, dass die Clients beim Senden von Anforderungen an unsere Domain oder Subdomain zu den richtigen (nächstgelegenen) Servern geleitet werden, benötigen wir einen DNS-Server mit GeoDNS-Funktionalität.

So funktioniert GeoDNS:

1. Es erhält die IP des Clients (wenn er die DNS-Anforderung gesendet hat) oder die IP des rekursiven DNS-Servers, der für die Verarbeitung der Anforderung verwendet wird. Im Allgemeinen sind solche rekursiven Server in der Regel die DNSs der Internetanbieter.
2. Anhand der IP-Adresse des Clients wird dessen Land oder Region identifiziert. Dieser Vorgang erfordert die Verwendung von GeoIP-Datenbank, die in keinem Mangel zur Verfügung stehen. Es gibt sogar anständige kostenlose Optionen.
3. Abhängig vom Standort des Clients gibt GeoDNS ihm die IP-Adresse des nächstgelegenen CDN-Servers zurück.

Ein DNS-Server mit GeoDNS-Funktionalität können Sie selbst erstellen, aber es ist besser, vorgefertigte Lösungen mit Servern auf der ganzen Welt und einer sofort einsatzbereiten Anycast-Option zu verwenden:

• ClouDNS, von $9.95 / monat, GeoDNS-Paket, ein DNS-Failover wird standardmäßig bereitgestellt
• Zilore, von $ 25/ Monat, enthält DNS-Failover
• Amazon Route 53, von $ 35 / Monat für 50 Millionen Geo-Anfragen. DNS-Failover wird separat berechnet
• DNS leicht gemacht, von $ 125 / Monat, mit 10 DNS-Failovers
• Cloudflare, Geo-Steuerungsfunktionalität wird in Enterprise-Paketen bereitgestellt

Bei der Bestellung von GeoDNS müssen Sie auf die Anzahl der im Paket enthaltenen Anforderungen achten und bedenken, dass die tatsächliche Anzahl der Anforderungen Ihre Erwartungen möglicherweise erheblich übertrifft. Zu jeder Zeit sind Millionen von Webcrawlern, Scannern, Spammern und anderen Teufeln am Werk.

Fast alle DNS-Dienste enthalten eine nützliche Funktion für die CDN-Erstellung – DNS-Failover. Damit können Sie die Aktivitätsüberwachung so konfigurieren, dass das System die Clients bei Ausfall eines Servers automatisch auf funktionierende Server umleitet.

Für unser CDN verwenden wir ClouDNS und sein GeoDNS-Paket.

Fügen Sie im Profil eine neue DNS-Zone hinzu und geben Sie Ihren Domänennamen an. Wenn Sie eine Subdomain verwenden und die Hauptdomain verwendet wird, vergessen Sie nicht, die vorhandenen DNS-Einträge unmittelbar nach dem Hinzufügen der Zone hinzuzufügen. Der nächste Schritt besteht darin, mehrere A-Datensätze für die CDN-Domäne / Subdomain zu erstellen, von denen jeder für die angegebene Region verwendet wird. Sie können Kontinente oder Länder als Regionen festlegen, und für die USA und Kanada stehen Unterregionsoptionen zur Verfügung.

In unserem Beispiel wird das CDN auf dem cdn.sayt.in subdomain. Nach dem Hinzufügen der sayt.in zone, erstellen Sie den ersten A-Datensatz für die Subdomain und leiten Sie alle NA-Clients an den Chicago-Server weiter:

Wiederholen Sie diesen Schritt für die anderen Regionen und vergessen Sie nicht, einen Eintrag für die Standardregionen zu erstellen. So sieht das Endergebnis aus:

Der letzte Standarddatensatz bedeutet Anfragen von allen nicht angegebenen Regionen (Europa, Afrika, Satelliten-Internetnutzer usw.) sind an den Frankfurter Server zu richten.

Damit ist die grundlegende DNS-Konfiguration abgeschlossen. Sie müssen nur noch zur Registrar-Website gehen und die aktuellen Nameserver durch die von ClouDNS bereitgestellten ersetzen. Während sie aktualisiert werden, werden wir die Server einstellen.

SSL-Zertifikate installieren

Unser CDN arbeitet mit HTTPS. Wenn Sie also bereits über SSL-Zertifikate für die Domain oder die Subdomain verfügen, laden Sie diese auf alle Server hoch, z. B. in das Verzeichnis /etc/ssl/yourdomain/.

Wenn Sie keine Zertifikate haben, können Sie diese kostenlos von Let’s Encrypt erhalten. ACME Shell Script ist eine großartige Option. Es verfügt über einen benutzerfreundlichen Client und ermöglicht vor allem die Validierung der Domain / Subdomain über DNS mithilfe der API von ClouDNS.

Wir installieren acme.sh auf nur einem Server — dem europäischen (199.247.18.199), und von dort werden die Zertifikate auf alle anderen kopiert. Um es zu installieren, führen Sie den folgenden Befehl aus:

root@cdn:~# wget -O - https://get.acme.sh | bash; source ~/.bashrc

Während der Installation wird ein CRON-Task zur automatischen Aktualisierung der Zertifikate erstellt.

Die Domänenüberprüfung nach Ausstellung des Zertifikats erfolgt über DNS mithilfe der API. Erstellen Sie daher im ClouDNS-Profil unter Reseller-API einen neuen API-Benutzer und geben Sie ein Kennwort dafür an. Geben Sie die resultierende Auth-ID zusammen mit dem Passwort in die folgende Datei ein: ~/.acme.sh/dnsapi/dns_cloudns.sh (nicht zu verwechseln mit dns_clouddns.sh ). Hier sind die Zeilen, die Sie auskommentieren und bearbeiten müssen:

CLOUDNS_AUTH_ID=<auth-id>CLOUDNS_AUTH_PASSWORD="<password>"

Lassen Sie uns nun die Ausstellung des SSL-Zertifikats für cdn anfordern.sayt.in

root@cdn:~# acme.sh --issue --dns dns_cloudns -d cdn.sayt.in --reloadcmd "service nginx reload"

Für die zukünftige Verwendung haben wir in den Parametern nach jeder Erneuerung des Zertifikats einen Befehl zum automatischen Neustart der Konfiguration hinterlassen.

Der Erwerb des Zertifikats kann bis zu zwei Minuten dauern. Falls ein Domänenvalidierungsfehler auftritt, führen Sie den Befehl erneut aus. Am Ende werden wir sehen, wo die Zertifikate heruntergeladen wurden.

Merken Sie sich diese Pfade, wir müssen sie beim Kopieren der Zertifikate auf andere Server angeben und wir müssen sie in den Servereinstellungen angeben. Ignorieren Sie den Fehler beim erneuten Laden der Nginx-Konfiguration — er tritt während der Zertifikatserneuerung nicht auf einem vollständig konfigurierten Server auf.

Was das SSL-Zertifikat betrifft, müssen wir es nur noch auf die beiden anderen Server kopieren und die Zertifikatspfade speichern. Erstellen Sie identische Verzeichnisse auf jedem Server und kopieren Sie dann Zertifikatsdateien:

root@cdn:~# mkdir -p /root/.acme.sh/cdn.sayt.in/root@cdn:~# scp -r [email protected]:/root/.acme.sh/cdn.sayt.in/* /root/.acme.sh/cdn.sayt.in/

Um die Zertifikatserneuerung zu automatisieren, müssen Sie auf beiden Servern eine tägliche CRON-Aufgabe erstellen. Unten ist der Befehl, den Sie zu CRON-Jobs hinzufügen sollten:

scp -r [email protected]:/root/.acme.sh/cdn.sayt.in/* /root/.acme.sh/cdn.sayt.in/ && service nginx reload</pre>

Beachten Sie, dass für die Verbindung zum Remote-Ursprungsserver ein Schlüsselzugriff ohne Eingabe eines Kennworts erforderlich ist. Vergiss nicht, es zu erstellen.

Nginx installieren und konfigurieren

Für die Bereitstellung statischer Inhalte verwenden wir Nginx, das als Caching-Proxyserver konfiguriert ist. Aktualisieren Sie die Paketlisten und installieren Sie sie auf allen drei Servern:

root@cdn:~# apt updateroot@cdn:~# apt install nginx

Verwenden Sie anstelle der Standardkonfiguration die folgende:

nginx.conf

user www-data;worker_processes auto;pid /run/nginx.pid;events { worker_connections 4096; multi_accept on;}http { sendfile on; tcp_nopush on; tcp_nodelay on; types_hash_max_size 2048; include /etc/nginx/mime.types; default_type application/octet-stream; access_log off; error_log /var/log/nginx/error.log; gzip on; gzip_disable "msie6"; gzip_comp_level 6; gzip_proxied any; gzip_vary on; gzip_types text/plain application/javascript text/javascript text/css application/json application/xml text/xml application/rss+xml; gunzip on; proxy_temp_path /var/cache/tmp; proxy_cache_path /var/cache/cdn levels=1:2 keys_zone=cdn:64m max_size=20g inactive=7d; proxy_cache_bypass $http_x_update;server { listen 443 ssl; server_name cdn.sayt.in; ssl_certificate /root/.acme.sh/cdn.sayt.in/cdn.sayt.in.cer; ssl_certificate_key /root/.acme.sh/cdn.sayt.in/cdn.sayt.in.key; location / { proxy_cache cdn; proxy_cache_key $uri$is_args$args; proxy_cache_valid 90d; proxy_pass https://sayt.in; } }}

In config bearbeiten wir:

• max_size — Cachegröße, die den verfügbaren Speicherplatz nicht überschreitet
• inaktiv — Aufbewahrungszeit für nicht angeforderte zwischengespeicherte Daten
• ssl_certificate und ssl_certificate_key — Pfade zu SSL—Zertifikat und Schlüssel
• proxy_cache_valid — Aufbewahrungszeit für zwischengespeicherte Daten
• proxy_pass – Adresse des Ursprungsservers, von dem das CDN Daten zum Zwischenspeichern anfordert. In unserem Beispiel ist es sayt.in

Wie Sie sehen können, ist es keine Raketenwissenschaft. Die einzige Schwierigkeit besteht darin, die Aufbewahrungszeit zu konfigurieren, da die Parameter inactive und proxy_cache_valid ähnlich sind. Schauen wir uns das genauer an. Folgendes passiert mit inactive=7d und proxy_cache_valid=90d:

• wenn die Anfrage nicht innerhalb von 7 Tagen wiederholt wird, werden die Daten aus dem Cache gelöscht
• Wenn die Anfrage auch nur einmal während 7 Tagen wiederholt wird, wird der Cache nach 90 Tagen als veraltet betrachtet und die nächste Anfrage wird Nginx veranlassen, sie vom Ursprungsserver zu aktualisieren

Mit nginx.conf behandelt, laden Sie die Konfiguration neu:

root@cdn:~# service nginx reload

Unser CDN ist also einsatzbereit! Für 15 US-Dollar / Monat erhielten wir PoPs auf drei Kontinenten und 3 TB Datenverkehr: 1 TB für jede Region.

Überprüfen unseres CDN

Werfen wir einen Blick auf Ping zu unserem CDN von verschiedenen Standorten aus. Alle Ping-Dienste reichen in diesem Fall aus.

Die Ergebnisse sind gut. Lassen Sie uns nun ein Testbild mit dem Titel Test platzieren.schalten Sie den Hauptserver ein und überprüfen Sie, wie schnell er über CDN geladen wird. Gesagt, getan. Das Laden ist schnell.

Lassen Sie uns ein kleines Skript erstellen, falls wir den Cache auf einem CDN-Punkt löschen müssen.

purge.sh

#!/bin/bashif then echo "Purging all cache" rm -rf /var/cache/cdn/*else echo "Purging " FILE=`echo -n "" | md5sum | awk '{print }'` FULLPATH=/var/cache/cdn/${FILE:31:1}/${FILE:29:2}/${FILE} rm -f "${FULLPATH}"fi

Um den gesamten Cache auf dem Server zu löschen, führen Sie einfach das Skript aus. Wenn Sie eine Datei bereinigen müssen, geben Sie einfach den Pfad an:

root@cdn:~# ./purge.sh /test.jpg 

Um den Cache überall zu leeren, muss das Skript auf allen CDN-Servern ausgeführt werden.

Anstelle von Schlussfolgerungen

Zum Schluss möchte ich einige nützliche Tipps geben, damit Sie nicht in die Fallstricke geraten, die ich bereits beseitigt habe:

• Berücksichtigen Sie die Rentabilität und die Wartungskosten Ihres zukünftigen CDN. In den meisten Fällen ist es viel effizienter und einfacher, ein billiges CDN zu kaufen, das höchstwahrscheinlich stabiler und von besserer Qualität ist.
• Um die Fehlertoleranz des CDN zu verbessern, wird empfohlen, ein DNS-Failover einzurichten, mit dem Sie den A-Eintrag im Falle eines Serverausfalls schnell wechseln können. Sie können dies in der DNS-Records-Systemsteuerung tun.
• Websites mit breiter Abdeckung erfordern eine große Anzahl von PoPs, werden aber nicht übereifrig. Höchstwahrscheinlich wird ein Benutzer den Unterschied zwischen Ihrem CDN und einem kostenpflichtigen nicht bemerken, wenn Sie Server an 6-7 Standorten haben (Europa, Nordamerika (Ost), Nordamerika (West), Singapur, Australien, Hongkong oder Japan).
• Manchmal erlauben Hosting-Provider nicht, gemietete Server für CDNs zu verwenden. Wenn Sie also einen CDN-Dienst erstellen möchten, lesen Sie die Allgemeinen Geschäftsbedingungen des Hosting-Anbieters.
• Studieren Sie die Seekabelkarte, um zu verstehen, wie die Kontinente miteinander verbunden sind, und nutzen Sie dieses Wissen beim Aufbau Ihres CDN.
• Versuchen Sie, Ihre Server von verschiedenen Standorten aus zu pingen. Auf diese Weise können Sie die Regionen erkennen, die Ihren PoPs am nächsten liegen, und es wird Ihnen helfen, GeoDNS zu konfigurieren.