🥇Wir konfigurieren und setzen Ihr CDN auf

Content Delivery Networks (CDNs) werden auf Websites und in Anwendungen hauptsächlich verwendet, um das Laden statischer Elemente zu beschleunigen. Dies geschieht durch das Caching von Dateien auf CDN-Servern, die in verschiedenen geografischen Regionen verteilt sind. Wenn Nutzer Daten über das CDN anfordern, erhalten sie diese von dem nächstgelegenen Server.

Das Prinzip und die Funktionalität aller Content Delivery Networks sind ungefähr gleich. Bei einer Anfrage zum Laden einer Datei holt der CDN-Server diese einmalig vom Originalserver und liefert sie an den Nutzer, während er sie gleichzeitig für einen definierten Zeitraum zwischenspeichert. Auf alle nachfolgenden Anfragen wird dann aus dem Cache geantwortet. Alle CDNs bieten Optionen für das Vorladen von Dateien, das Leeren des Caches, die Einstellung der Cache-Dauer und vieles mehr.

Es gibt Situationen, in denen aus verschiedenen Gründen die Notwendigkeit besteht, ein eigenes Content Delivery Network zu organisieren. In diesem Fall steht uns eine Anleitung zur Verfügung, um diesen Prozess zu erleichtern.

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

Wann benötigt man ein eigenes CDN

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

wenn Sie Kosten sparen möchten, aber die aktuellen Ausgaben auch bei günstigen CDNs wie BunnyCDN einige Hundert Dollar pro Monat betragen
wenn wir einen konstanten Cache oder einen Cache ohne Nachbarn auf dem Server und im Kanal erhalten möchten
in Ihrer gewünschten Region keine Präsenzpunkte bei CDN-Diensten vorhanden sind
spezielle Anpassungen für die Bereitstellung von Inhalten erforderlich sind
möchten wir die Lieferung dynamischer Inhalte beschleunigen, indem wir Produktionsserver näher an den Nutzern platzieren
besteht die Befürchtung, dass ein externes CDN-Dienst die Informationen über das Verhalten der Nutzer unrechtmäßig sammeln oder nutzen könnte (Hallo, Dienste ohne GDPR-Konformität) oder andere rechtswidrige Aktivitäten ausüben könnte

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

Was benötigt wird, um loszulegen

Es wäre großartig, wenn Sie ein eigenes autonomes System (AS) haben. Damit können Sie mehreren Servern dieselbe IP zuweisen und diese Anleitung befolgen Auf Netzwerkebene die Nutzer zum nächstgelegenen zu leiten. Es ist erwähnenswert, dass selbst mit einem /24 Adressblock die Möglichkeit besteht, ein Content Delivery Network aufzubauen. Einige Serveranbieter erlauben das Ankündigen für die Nutzung in allen verfügbaren Regionen.

Wenn Sie nicht der glückliche Besitzer eines IP-Adressblocks sind, benötigen Sie für den Betrieb eines einfachen CDN:

eine Domain oder Subdomain
mindestens zwei Server in unterschiedlichen Regionen. Die Server können sowohl dediziert als auch virtuell sein
geoDNS-Tool. Damit wird der Nutzer, der eine Anfrage an die Domain stellt, zum nächstgelegenen Server geleitet.

Wir registrieren die Domain und bestellen die Server

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

Bezüglich der Bestellung der Server sollten Sie diese in den Regionen und Ländern mieten, in denen sich Ihr Publikum befindet. Wenn das Projekt interkontinental ist, ist es praktisch, Hosting-Anbieter zu wählen, die 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. Auf Vultr dem Server für 5 $ / Monat erhalten wir 25 GB SSD Speicherplatz und 1 TB 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 vergeben 100 $ Guthaben an Nutzer, die über die Links im Artikel registriert sind, sofort nach der Hinzufügung der Zahlungsmethode. Der Autor erhält ebenfalls einen kleinen Bonus dafür, was für ihn derzeit von Bedeutung ist. Bitte zeigen Sie Verständnis.

Wir konfigurieren geoDNS

Um sicherzustellen, dass ein Nutzer bei der Anfrage an die Domain oder Subdomain des CDN auf den richtigen (nächstgelegenen) Server geleitet wird, benötigen wir einen DNS-Server mit geoDNS-Funktion.

Das Prinzip und der Ablauf von geoDNS sind wie folgt:

Bestimmt die IP des Clients, der die DNS-Anfrage gesendet hat, oder die IP des rekursiven DNS-Servers, der zur Verarbeitung der Client-Anfrage verwendet wird. Solche rekursiven Server sind in der Regel die DNS-Server der Provider.
Anhand der IP des Clients wird dessen Land oder Region ermittelt. Hierfür werden GeoIP-Datenbanken verwendet, von denen es heute eine Vielzahl gibt. Es gibt einige gute kostenlose Optionen..
Je nach Standort des Kunden wird die IP-Adresse des nächstgelegenen CDN-Servers zugewiesen.

Ein DNS-Server mit geoDNS-Funktion kann eigenständig eingerichtet werden, aber es ist besser, auf fertige Lösungen mit einem Netzwerk von DNS-Servern weltweit zurückzugreifen und Anycast bereitgestellt zu bekommen:

ClouDNS ab 9,95 $/Monat, GeoDNS-Tarif, standardmäßig gibt es einen DNS Failover
Zilore ab 25 $/Monat, einschließlich DNS Failover
Amazon Route 53 ab 35 $/Monat für 50M Geo-Anfragen. DNS Failover wird separat abgerechnet.
DNS Made Easy ab 125 $/Monat, es sind 10 DNS Failover enthalten
Cloudflare, die Funktion "Geo Steering" ist in den Enterprise-Tarifen verfügbar.

Beim Bestellen von geoDNS sollte auf die Anzahl der im Tarif enthaltenen Anfragen geachtet werden, und es ist zu berücksichtigen, dass die tatsächliche Anzahl der Anfragen an die Domain die Erwartungen bei weitem übersteigen kann. Millionen von Bots, Scannern, Spammern und anderen unerwünschten Elementen arbeiten unermüdlich.

Praktisch bei allen DNS-Services ist eine für den Aufbau eines CDN unverzichtbare Dienstleistung im Preis enthalten – der DNS Failover. Damit kann die Überwachung der Serveraktivität eingerichtet werden, und im Falle eines Ausfalls wird automatisch die Adresse des nicht funktionierenden Servers in den DNS-Antworten durch die eines Backup-Servers ersetzt.

Um unser CDN aufzubauen, verwenden wir ClouDNS, den Tarif GeoDNS.

Wir fügen im Kundenbereich eine neue DNS-Zone hinzu, indem wir unsere Domain angeben. Wenn das CDN auf einem Subdomain aufgebaut wird und die Hauptdomain bereits in Verwendung ist, vergessen Sie nicht, nach dem Hinzufügen der Zone die bestehenden DNS-Einträge hinzuzufügen. Der nächste Schritt besteht darin, für das CDN einige A-Records für die Domain/Subdomain zu erstellen, von denen jeder für die von uns festgelegte Region verwendet wird. Als Regionen können Kontinente oder Länder angegeben werden, für die USA und Kanada sind Subregionen verfügbar.

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

Wir wiederholen den Vorgang für andere Regionen und vergessen nicht, einen Eintrag für die Standardregionen zu erstellen. So wird das Endergebnis aussehen:

Der letzte Standard-Eintrag im Screenshot bedeutet, dass alle nicht festgelegten Regionen (dazu gehören Europa, Afrika, Benutzer von Satelliten-Internet usw.) an den Server in Frankfurt geleitet werden.

Die grundlegende DNS-Konfiguration ist hiermit abgeschlossen. Jetzt müssen Sie sich beim Domain-Registrar anmelden und die aktuellen NS-Einträge der Domain durch die von ClouDNS bereitgestellten ersetzen. Während die NS-Einträge aktualisiert werden, bereiten wir die Server vor.

Installation von SSL-Zertifikaten

Unser CDN wird über HTTPS arbeiten. Wenn Sie bereits SSL-Zertifikate für Ihre Domain oder Subdomain haben, laden Sie diese bitte auf alle Server hoch, zum Beispiel in das Verzeichnis /etc/ssl/вашдомен/

Wenn Sie keine Zertifikate haben, können Sie ein kostenloses von Let’s Encrypt erhalten. Dafür eignet sich bestens das ACME Shell-Skript. Der Client ist benutzerfreundlich und einfach zu konfigurieren und ermöglicht es vor allem, die Validierung von Domain/Subdomain über DNS über die API von ClouDNS durchzuführen.

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

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

Im Verlauf der Skriptinstallation wird ein CRON-Job erstellt, um die Zertifikate zukünftig automatisch ohne unser Eingreifen zu aktualisieren.

Die Überprüfung der Domain bei der Ausstellung des Zertifikats erfolgt über DNS unter Verwendung der API. Daher müssen Sie im ClouDNS-Kundenbereich einen neuen API-Benutzer im Menü Reseller API anlegen und ein Passwort festlegen. Die erhaltene auth-id zusammen mit dem Passwort tragen wir in der Datei ein. ~/.acme.sh/dnsapi/dns_cloudns.sh (nicht 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 ein 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 bereits einen Befehl für die automatische Neuladen der Webserver-Konfiguration nach jeder Verlängerung des Zertifikats für die Zukunft festgelegt.

Der gesamte Prozess zum Erhalten des Zertifikats kann bis zu 2 Minuten dauern. Unterbrechen Sie ihn nicht. Wenn ein Validierungsfehler auftritt, versuchen Sie, den Befehl erneut auszuführen. Am Ende sehen wir, an welchem Ort die Zertifikate hochgeladen wurden:

Merken Sie sich diese Pfade, da Sie sie beim Kopieren des Zertifikats auf andere Server sowie in den Einstellungen des Webservers angeben müssen. Ignorieren Sie die Fehlermeldung beim Neuladen der Nginx-Konfiguration; auf einem voll konfigurierten Server wird sie bei der Aktualisierung der Zertifikate nicht auftreten.

Was uns bezüglich SSL bleibt, ist das Kopieren des erhaltenen Zertifikats auf zwei weitere Server unter Beibehaltung der Dateipfade. 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/

Um sicherzustellen, dass die Zertifikatserneuerung 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

Der Zugriff auf den entfernten Quellserver muss dabei konfiguriert sein über Schlüssel, d.h. ohne Passwortabfrage. Vergessen Sie nicht, dies zu tun.

Installation und Konfiguration von Nginx

Zur Bereitstellung von statischen Inhalten verwenden wir Nginx, konfiguriert als Cache-Proxy-Server. Wir aktualisieren die Paketlisten und installieren es auf allen drei Servern:

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

Statt der Standardkonfiguration verwenden wir die Einstellung aus dem Spoiler unten:
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 Konfigurationsfile bearbeiten wir:

max_size — die Größe des Cache, die nicht den verfügbaren Speicherplatz auf der Festplatte überschreiten darf
inactive — die Speicherung der zwischengespeicherten Daten, auf die seit einer bestimmten Zeit nicht zugegriffen wurde
ssl_certificate und ssl_certificate_key — Pfade zu den Dateien des SSL-Zertifikats und des Schlüssels
proxy_cache_valid — die gültige Aufbewahrungsdauer der zwischengespeicherten Daten
proxy_pass — die Adresse des Originalservers, von dem das CDN die Dateien zum Caching anfordert. In unserem Beispiel ist das sayt.in

Wie wir sehen, ist alles ganz einfach. Die Schwierigkeit könnte lediglich bei der Einstellung der Cache-Zeit aufgrund ähnlicher Direktiven entstehen. inactive und proxy_cache_validWir werden diese an unserem Beispiel erläutern. Das passiert, wenn inactive=7d und proxy_cache_valid 90d:

wenn die Anfrage innerhalb von 7 Tagen nicht wiederholt wird, werden die Daten nach Ablauf dieses Zeitraums aus dem Cache gelöscht.
Wenn die Anfrage mindestens einmal alle 7 Tage wiederholt wird, gelten die Daten im Cache nach 90 Tagen als veraltet, und bei der nächsten Anfrage aktualisiert Nginx diese, indem es sie vom Originalserver abruft.

Nachdem wir das bearbeitet haben nginx.conf, laden wir die Konfiguration neu:

root@cdn:~# service nginx reload

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

Wir prüfen die Funktionalität des CDN

Lassen Sie uns die Ping-Zeiten zu unserem CDN aus verschiedenen geografischen Standorten betrachten. Hierfür 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. Lassen Sie uns jetzt ein Testbild im Root-Verzeichnis der Hauptwebsite platzieren. test.jpg und wir werden die Ladegeschwindigkeit über das CDN überprüfen. Gesagt, getan — erledigt. Der Inhalt wird schnell ausgeliefert.

Wir schreiben ein kleines Skript für den Fall, dass wir den Cache an der CDN-Stelle 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 Fazits

Abschließend möchte ich ein paar nützliche Tipps geben, um gleich über die Stolpersteine hinwegzukommen, die mir früher schmerzhafte Kopfschmerzen bereitet haben:

Um die Ausfallsicherheit des CDN zu erhöhen, empfiehlt es sich, DNS Failover einzurichten, das schnell den A-Eintrag bei einem Serverausfall ändern hilft. Dies erfolgt im DNS-Management-Bereich des Domainpanels.
Websites mit weitreichender geografischer Abdeckung benötigen zweifellos viele CDN-Punkte, aber übertreiben wir es nicht. Höchstwahrscheinlich wird der Benutzer keinen wesentlichen Unterschied im Vergleich zu kostenpflichtigem CDN bemerken, wenn Sie Server an 6-7 Standorten platzieren: Europa, Nordamerika (Osten), Nordamerika (Westen), Singapur, Australien, Hongkong oder Japan.
Manchmal erlauben Hosting-Anbieter nicht die Nutzung von gemieteten Servern für CDN-Zwecke. Daher sollten Sie, falls Sie erwägen, ein Content Delivery Network als Dienst einzurichten, die Regeln des spezifischen Hosting-Anbieters im Voraus sorgfältig lesen.
Erforschen Sie die Karte der Unterwasser-Kommunikation, um ein Verständnis dafür zu bekommen, wie die Kontinente verbunden sind, und dies beim Aufbau Ihres Content Delivery Networks zu berücksichtigen.
Versuchen Sie zu prüfen die Pings von verschiedenen Standorten zu Ihren Servern. So können Sie die Regionen in der Nähe der CDN-Punkte erkennen und GeoDNS besser konfigurieren.
Je nach Anforderungen kann es sinnvoll sein, Nginx an die spezifischen Cache-Anforderungen und die Serverlast anzupassen. Dabei haben mir die Artikel über Nginx-Cache sehr geholfen — hier und die Leistungssteigerung bei hohen Belastungen: hier und hier