🥇Und so bauen wir unser eigenes CDN auf und konfigurieren es

Content Delivery Networks (CDN) werden auf Websites und in Anwendungen hauptsächlich dazu verwendet, die Ladezeiten statischer Elemente zu beschleunigen. Dies geschieht durch das Caching von Dateien auf CDN-Servern, die in verschiedenen geografischen Regionen liegen. Wenn der Benutzer über das CDN Daten anfordert, erhält er diese vom nächstgelegenen Server.

Das Prinzip und die Funktionalität aller Content Delivery Networks sind in etwa gleich. Auf eine Anfrage zur Dateiübertragung nimmt der CDN-Server die Datei einmalig vom ursprünglichen Server und gibt sie dem Benutzer, während er sie gleichzeitig für einen festgelegten Zeitraum bei sich zwischenspeichert. Auf alle nachfolgenden Anfragen wird aus dem Cache geantwortet. Alle CDNs verfügen über Optionen für das Vorladen von Dateien, das Leeren des Caches, das Einstellen der Aufbewahrungsfristen und vieles mehr.

Manchmal ist es aus bestimmten Gründen notwendig, ein eigenes Content Delivery Network zu organisieren, und dafür — sei uns die Anleitung zur Konstruktion eines weiteren Fahrrads von Nutzen.

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

Wenn man ein eigenes CDN benötigt

Betrachten wir die Fälle, in denen der Start eines eigenen CDNs sinnvoll ist:

wenn der Wunsch besteht, Kosten zu sparen, und die aktuellen Ausgaben selbst bei der Nutzung günstiger CDNs wie BunnyCDN mehrere Hundert Dollar pro Monat betragen
wenn wir einen permanenten Cache oder einen Cache ohne Nachbarn auf dem Server und in der Leitung haben möchten
wenn in der von Ihnen gewünschten Region die CDN-Dienste keine Verfügbarkeitsstandorte haben
wenn besondere Konfigurationen für die Content-Lieferung erforderlich sind
wenn wir die Lieferung dynamischer Inhalte beschleunigen möchten, indem wir Produktionsserver näher an den Benutzern platzieren
wenn wir befürchten, dass ein externes CDN-Unternehmen unrechtmäßig Informationen über das Nutzerverhalten sammeln oder verwenden könnte (Hallo Dienste ohne GDPR-konforme Standards) oder andere unrechtmäßige Aktivitäten durchführen könnte

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

Was benötigt wird, um zu starten

Es ist großartig, wenn Sie über ein eigenes autonomes System (AS) verfügen. Damit können Sie mehreren Servern dieselbe IP zuweisen und nach dieser Anleitung auf Netzwerkebene die Benutzer zum nächstgelegenen weiterleiten. Es ist zu beachten, dass man sogar mit einem Adressblock /24 ein Content Delivery Network aufbauen kann. Einige Serveranbieter erlauben es, eine Ankündigung für alle verfügbaren Regionen zu machen.

Wenn Sie nicht der glückliche Besitzer eines IP-Adressblocks sind, benötigen Sie Folgendes, um ein einfaches CDN zu starten:

einen Domainnamen oder Subdomain
mindestens zwei Server in unterschiedlichen Regionen. Der Server kann sowohl physisch als auch virtuell sein
ein geoDNS-Tool. Damit wird der Benutzer, der die Domain anfragt, an den nächstgelegenen Server weitergeleitet

Wir registrieren die Domain und bestellen die Server

Die Registrierung der Domain ist einfach – registrieren Sie in jeder Zone bei jedem Registrar. Für das CDN kann auch eine Subdomain verwendet werden, zum Beispiel etwas wie cdn.meinedomain.com. In unserem Beispiel werden wir es so machen.

Was die Bestellung der Server betrifft – sie sollten in den Regionen und Ländern gemietet werden, in denen sich Ihre Zielgruppe befindet. Wenn das Projekt interkontinental ist, ist es sinnvoll, Hosting-Anbieter zu wählen, die sofort Server auf der ganzen Welt anbieten. Beispiele dafür sind: OVH, Leaseweb und 100Tb – für dedizierte Server, Vultr und DigitalOcean – für virtuelle Cloud*.

Für unser privates CDN bestellen wir 3 virtuelle Server auf verschiedenen Kontinenten. An Vultr unserem Server für $5/Monat bekommen wir 25GB SSD Plätze und 1TB Traffic. Bei der Installation wählen wir die neueste Debian-Version. Unsere Server:

Frankfurt, ip: 199.247.18.199

Chicago, ip: 149.28.121.123

Singapur, ip: 157.230.240.216

* Vultr und DigitalOcean bieten $100 Kredit für Benutzer, die über die Links im Artikel registriert sind, sofort nach Hinzufügen einer Zahlungsmethode an. Der Autor erhält ebenfalls einen kleinen Bonus, was für ihn jetzt sehr bedeutend ist. Bitte haben Sie Verständnis.

Wir richten geoDNS ein

Damit der Benutzer beim Zugriff auf die CDN-Domain oder -Subdomain an den richtigen (nächstgelegenen) Server weitergeleitet wird, benötigen wir einen DNS-Server mit der Funktion geoDNS.

Das Prinzip und die Funktionsweise von geoDNS sind wie folgt:

Es bestimmt die IP des Clients, der die DNS-Anfrage gesendet hat, oder die IP des rekursiven DNS-Servers, der bei der Verarbeitung der Client-Anfrage verwendet wird. Solche rekursiven Server sind gewöhnlich die DNS-Server der Anbieter.
Anhand der IP des Clients ermittelt es dessen Land oder Region. Hierfür werden GeoIP-Datenbanken verwendet, von denen es heute viele gibt. Es gibt einige brauchbare kostenlose Optionen.
Je nach Standort des Clients gibt es ihm die IP-Adresse des nächstgelegenen CDN-Servers.

Einen DNS-Server mit geoDNS-Funktion kann man selbst zusammenstellen, aber es ist besser, fertige Lösungen mit einem Netzwerk von DNS-Servern weltweit zu verwenden und Anycast out of the box:

ClouDNS ab $9.95/Monat, Tarif GeoDNS, standardmäßig gibt es einen DNS Failover
Zilore ab $25/Monat, DNS Failover ist aktiviert
Amazon Route 53 ab $35/Monat für 50M Geo-Anfragen. DNS Failover wird separat berechnet
DNS Made Easy ab $125/Monat, 10 DNS Failover verfügbar
Cloudflare, die Funktion „Geo Steering“ ist in den Enterprise-Tarifen verfügbar

Beim Bestellen von geoDNS sollte man auf die Anzahl der im Tarif enthaltenen Anfragen achten und berücksichtigen, dass die tatsächliche Anzahl der Zugriffe auf die Domain die Erwartungen um ein Vielfaches übersteigen kann. Millionen von Robotern, Scannern, Spammern und anderen unerwünschten Aktivitäten arbeiten unermüdlich.

Bei praktisch allen DNS-Diensten ist der für den CDN-Bau unverzichtbare Service - DNS Failover - im Preis enthalten. Damit kann man die Funktionsfähigkeit der eigenen Server überwachen und im Falle von Ausfällen automatisch die Adresse des nicht funktionierenden Servers in den DNS-Antworten durch die eines Reserve-Servers ersetzen.

Für den Aufbau unseres CDN verwenden wir ClouDNS, Tarif GeoDNS.

Wir fügen im Kundenbereich eine neue DNS-Zone hinzu und geben unsere Domain an. Wenn wir das CDN auf einem Subdomain aufbauen möchten, und die Hauptdomain bereits verwendet wird, vergessen Sie nicht, nach dem Hinzufügen der Zone die bestehenden DNS-Einträge hinzuzufügen. Der nächste Schritt besteht darin, für die CDN-Domain/Subdomain mehrere A-Einträge zu erstellen, die jeweils für die von uns festgelegte Region verwendet werden. Als Regionen können Kontinente oder Länder angegeben werden, für die USA und Kanada stehen Subregionen zur Verfügung.

In unserem Fall wird das CDN auf der Subdomain cdn.sayt.in. Nachdem wir die Zone hinzugefügt haben sayt.in, erstellen wir für die Subdomain den ersten A-Eintrag und leiten ganz Nordamerika auf den Server in Chicago:

Wir wiederholen diesen Schritt für andere Regionen und denken daran, einen Eintrag für die Standardregionen zu erstellen. So wird das Ergebnis aussehen:

Der letzte Standardeintrag im Screenshot bedeutet, dass alle nicht festgelegten Regionen (darunter Europa, Afrika, Nutzer von Satelliteninternet usw.) auf den Server in Frankfurt geleitet werden.

Damit ist die grundlegende DNS-Konfiguration abgeschlossen. Jetzt müssen wir zur Website des Domainregistrars gehen und die aktuellen NS-Records der Domain durch die von ClouDNS bereitgestellten ersetzen. Während die NS-Records aktualisiert werden, bereiten wir die Server vor.

Installation von SSL-Zertifikaten

Unser CDN wird über HTTPS arbeiten, daher sollten Sie, wenn Sie bereits SSL-Zertifikate für die Domain oder Subdomain haben, diese auf alle Server hochladen, beispielsweise in das Verzeichnis /etc/ssl/вашдомен/

Falls keine Zertifikate vorhanden sind, kann man ein kostenloses von Let’s Encrypt erhalten. Dafür eignet sich hervorragend ACME Shell-SkriptDer Client ist bequem und einfach einzurichten und ermöglicht insbesondere die Validierung von Domain/Subdomain über DNS über die API von ClouDNS.

Wir werden acme.sh nur auf einem der Server – dem europäischen 199.247.18.199 – installieren, von dem aus die Zertifikate auf alle anderen kopiert werden. Für die Installation führen wir aus:

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

Im Verlauf der Installation des Skripts wird ein CRON-Job erstellt, um die Zertifikate künftig automatisch ohne unser Eingreifen zu aktualisieren.

Die Überprüfung der Domain bei der Ausstellung des Zertifikats erfolgt über DNS mit Hilfe der API. Daher muss im persönlichen Bereich von ClouDNS im Menü Reseller API ein neuer API-Benutzer erstellt und ein Passwort festgelegt werden. Die erhaltene auth-id mit Passwort tragen wir in die Datei ein ~/ .acme.sh/ dnsapi/ dns_cloudns.sh (nicht zu verwechseln mit der Datei dns_clouddns.sh). Hier sind die Zeilen, die entkommentiert und bearbeitet werden müssen:

CLOUDNS_AUTH_ID=
CLOUDNS_AUTH_PASSWORD=""

Jetzt beantragen wir das SSL-Zertifikat für cdn.sayt.in

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

In den Parametern haben wir für die Zukunft einen Befehl angegeben, um die Konfiguration des Webservers nach jedem zukünftigen Ablauf des Zertifikats automatisch neu zu laden.

Der gesamte Prozess der Zertifikatsbeschaffung kann bis zu 2 Minuten dauern, unterbrechen Sie ihn nicht. Wenn ein Fehler bei der Domainvalidierung auftritt, versuchen Sie, den Befehl erneut auszuführen. Am Ende sehen wir, wohin die Zertifikate hochgeladen wurden:

Merken Sie sich diese Pfade, sie müssen bei der Kopie des Zertifikats auf andere Server sowie in den Einstellungen des Webservers angegeben werden. Ignorieren Sie den Fehler beim Neuladen der Nginx-Konfiguration – auf einem vollständig eingerichteten Server wird dieser bei einer Zertifikatsaktualisierung nicht auftreten.

Alles, was wir für SSL noch tun müssen, ist, das erhaltene Zertifikat auf zwei andere Server mit Erhaltung des Pfades zu den Dateien zu kopieren. Wir erstellen auf jedem von ihnen die gleichen Verzeichnisse und machen eine Kopie:

root@cdn:~# mkdir -p /root/ .acme.sh/ cdn.sayt.in/
root@cdn:~# scp -r root@199.247.18.199:/root/ .acme.sh/ cdn.sayt.in/* /root/ .acme.sh/ cdn.sayt.in/

Damit die Aktualisierung der Zertifikate regelmäßig erfolgt, erstellen wir auf beiden Servern einen täglichen CRON-Job mit dem Befehl:

scp -r root@199.247.18.199:/root/ .acme.sh/ cdn.sayt.in/* /root/ .acme.sh/ cdn.sayt.in/ && service nginx reload

Dabei muss der Zugriff auf den entfernten Quellserver eingerichtet sein per Schlüssel, d.h. ohne Eingabe eines Passworts. Vergessen Sie nicht, dies zu tun.

Installation und Konfiguration von Nginx

Für die Bereitstellung von statischen Inhalten werden wir Nginx verwenden, das im Modus des Cache-Proxy-Servers konfiguriert ist. Wir werden die Paketlisten aktualisieren und es auf allen drei Servern installieren:

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

Anstelle der Standardkonfiguration verwenden wir die untenstehende Konfiguration aus dem Spoiler:
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;
    }
  }
}

Im Konfigurationsdatei bearbeiten wir:

max_size — die Größe des Caches, die den verfügbaren Speicherplatz auf der Festplatte nicht überschreitet
inactive — die Zeit, für die zwischengespeicherte Daten gespeichert werden, auf die nicht zugegriffen wurde
ssl_certificate und ssl_certificate_key — Pfade zu den Dateien des SSL-Zertifikats und des Schlüssels
proxy_cache_valid — die Zeit, für die zwischengespeicherte Daten gültig sind
proxy_pass — die Adresse des Ursprungsservers, von dem das CDN Dateien zum Caching anfordert. In unserem Beispiel ist dies sayt.in

Wie wir sehen, ist alles einfach. Die Schwierigkeit kann nur bei der Einstellung der Cache-Zeit aufgrund der Ähnlichkeit der Direktiven auftreten inactive und proxy_cache_valid. Lassen Sie uns diese anhand unseres Beispiels analysieren. So verhält es sich mit inactive=7d und proxy_cache_valid 90d:

wenn die Anfrage innerhalb von 7 Tagen nicht wiederholt wird, werden die Daten am Ende dieses Zeitraums aus dem Cache gelöscht
wenn die Anfrage mindestens einmal in 7 Tagen wiederholt wird, gelten die Daten im Cache nach 90 Tagen als veraltet und beim nächsten Abruf wird Nginx sie aktualisieren, indem es sie vom Ursprungsserver abruft

Nachdem wir die Bearbeitung abgeschlossen haben, nginx.conf, laden wir die Konfiguration neu:

root@cdn:~# service nginx reload

Unser CDN ist vollständig einsatzbereit. Für $15/Monat haben wir Präsenzpunkte auf drei Kontinenten und 3 TB Traffic erhalten: je 1 TB an jedem Standort.

Überprüfen Sie die Funktionsweise des CDN

Schauen wir uns die Pings zu unserem CDN aus verschiedenen geografischen Standorten an. Dazu eignen sich beliebige Ping-Dienste.

Startpunkt
Host
IP
Durchschnittliche Zeit, ms

Deutschland, Berlin
cdn.sayt.in
199.247.18.199
9.6

Niederlande, Amsterdam
cdn.sayt.in
199.247.18.199
10.1

Frankreich, Paris
cdn.sayt.in
199.247.18.199
16.3

Vereinigtes Königreich, London
cdn.sayt.in
199.247.18.199
14.9

Kanada, Toronto
cdn.sayt.in
149.28.121.123
16.2

USA, San Francisco
cdn.sayt.in
149.28.121.123
52.7

USA, Dallas
cdn.sayt.in
149.28.121.123
23.1

USA, Chicago
cdn.sayt.in
149.28.121.123
2.6

USA, New York
cdn.sayt.in
149.28.121.123
19.8

Singapur
cdn.sayt.in
157.230.240.216
1.7

Japan, Tokio
cdn.sayt.in
157.230.240.216
74.8

Australien, Sydney
cdn.sayt.in
157.230.240.216
95.9

Die Ergebnisse sind gut. Jetzt werden wir ein Testbild im Root des Hauptsites platzieren. test.jpg und die Ladegeschwindigkeit über das CDN prüfen. Es wurde gesagt, — gemacht. Der Inhalt wird schnell bereitgestellt.

Wir schreiben ein kleines Skript für den Fall, dass wir den Cache an dem CDN-Punkt leeren möchten.
purge.sh

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

Um den gesamten Cache zu löschen, genügt es, es einfach auszuführen; eine einzelne Datei kann so gereinigt werden:

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

Statt von Ausgaben

Zum Schluss möchte ich einige nützliche Ratschläge geben, um gleich über die Stolpersteine zu springen, die mir damals Kopfschmerzen bereitet haben:

Zur Verbesserung der Ausfallsicherheit des CDNs wird empfohlen, DNS Failover einzurichten, um schnell den A-Eintrag im Falle eines Serverausfalls zu ändern. Dies geschieht im DNS-Verwaltungsbereich des Domain-Eintrags.
Webseiten mit umfassender geografischer Abdeckung benötigen zweifellos viele CDN-Punkte, aber lassen Sie es nicht übertreiben. Höchstwahrscheinlich wird der Benutzer keinen wesentlichen Unterschied im Vergleich zu einem kostenpflichtigen CDN feststellen, wenn Sie Server an 6-7 Standorten platzieren: Europa, Nordamerika (Ost), Nordamerika (West), Singapur, Australien, Hongkong oder Japan.
Manchmal erlauben Hosting-Anbieter nicht die Verwendung von gemieteten Servern für CDN-Zwecke. Daher, wenn Sie zufällig beschließen, ein Content Delivery Network als Dienst zu betreiben, vergessen Sie nicht, vorher die Regeln des jeweiligen Hosting-Anbieters zu lesen.
Studieren Sie die Karte von Unterwasser-Kommunikationen, um zu verstehen, wie die Kontinente verbunden sind, und dies beim Aufbau des Content Delivery Networks zu berücksichtigen.
Versuchen Sie, zu überprüfen, Pings aus verschiedenen Orten zu Ihren Servern. So können Sie die Regionen sehen, die den CDN-Punkten am nächsten sind, und GeoDNS besser einstellen.
Je nach Aufgabe kann es sinnvoll sein, Nginx an die spezifischen Anforderungen der Cache-Erstellung und unter Berücksichtigung der Serverauslastung anzupassen. Dabei haben mir Artikel über den Cache von Nginx sehr geholfen — hier und zur Beschleunigung der Leistung bei hohen Lasten: hier und hier