🥇Erstellen und Konfigurieren Ihres CDN

Content Delivery Networks (CDNs) werden in Websites und Anwendungen hauptsächlich dazu verwendet, das Laden statischer Elemente zu beschleunigen. Dies geschieht aufgrund der Zwischenspeicherung von Dateien auf CDN-Servern, die sich in verschiedenen geografischen Regionen befinden. Durch die Anforderung von Daten über CDN erhält der Benutzer diese vom nächstgelegenen Server.

Das Funktionsprinzip und die Funktionalität aller Content-Delivery-Netzwerke sind in etwa gleich. Nachdem der CDN-Server eine Anfrage zum Herunterladen einer Datei erhalten hat, entnimmt er diese einmalig vom ursprünglichen Server und gibt sie an den Benutzer weiter, wobei er sie gleichzeitig für einen bestimmten Zeitraum zwischenspeichert. Alle nachfolgenden Anfragen werden aus dem Cache beantwortet. Alle CDNs verfügen über Optionen zum Vorabladen von Dateien, zum Leeren des Caches, zum Festlegen des Ablaufdatums und mehr.

Es kommt vor, dass Sie aus dem einen oder anderen Grund Ihr eigenes Content-Delivery-Netzwerk organisieren müssen und uns dann die Anleitung zum Zusammenbau des nächsten Fahrrads weiterhelfen kann.

Source: Infografik-Vektor erstellt von pikisuperstar - www.freepik.com

Wenn Sie Ihr eigenes CDN benötigen

Betrachten Sie die Fälle, in denen der Betrieb eines eigenen CDN sinnvoll ist:

wenn der Wunsch besteht, Geld und laufende Kosten zu sparen, selbst wenn kostengünstige CDNs verwendet werden HaseCDN belaufen sich auf mehrere hundert Dollar pro Monat
ob wir einen permanenten Cache oder einen Cache ohne Server- und Kanalnachbarn erhalten möchten
CDN-Dienste verfügen nicht über Präsenzpunkte in der von Ihnen benötigten Region
alle erforderlichen speziellen Einstellungen für die Inhaltsbereitstellung
Wir möchten die Bereitstellung dynamischer Inhalte beschleunigen, indem wir den Produktionsserver näher an den Benutzern platzieren
Es besteht die Sorge, dass ein CDN-Dienst eines Drittanbieters illegal Informationen über das Nutzerverhalten sammelt oder verwendet (Hallo, nicht DSGVO-konforme Dienste) oder sich an anderen illegalen Aktivitäten beteiligt

In den meisten anderen Fällen ist es sinnvoller, auf vorhandene Fertiglösungen zurückzugreifen.

Was brauchen Sie zum Starten?

Es ist wunderbar, wenn Sie ein eigenes autonomes System (AS) haben. Damit können Sie mehreren Servern die gleiche IP zuweisen und nach dieser Anleitung Leiten Sie Benutzer auf Netzwerkebene zum nächstgelegenen Netzwerk weiter. Es ist erwähnenswert, dass es auch mit dem /24-Adressblock möglich ist, ein Content-Delivery-Netzwerk aufzubauen. Bei einigen Serveranbietern können Sie eine Ankündigung zur Nutzung in allen ihnen zur Verfügung stehenden Regionen vornehmen.

Wenn Sie nicht der glückliche Besitzer eines IP-Adressblocks sind, benötigen Sie zum Ausführen eines einfachen CDN Folgendes:

Domainname oder Subdomain
mindestens zwei Server in verschiedenen Regionen. Der Server kann entweder dediziert oder virtuell sein
GeoDNS-Tool. Damit wird der Benutzer nach der Adressierung der Domain zum nächstgelegenen Server weitergeleitet

Registrieren Sie eine Domain und bestellen Sie Server

Bei der Domainregistrierung ist alles ganz einfach: Wir registrieren uns in jeder Zone bei jedem Registrar. Sie können auch eine Subdomain für ein CDN verwenden, zum Beispiel so etwas wie cdn.domainname.com. In unserem Beispiel werden wir genau das tun.

Was die Bestellung von Servern betrifft, sollten diese in den Regionen und Ländern gemietet werden, in denen sich Ihre Benutzergruppe befindet. Wenn das Projekt interkontinental ist, ist es praktisch, Hosting-Anbieter zu wählen, die Server auf der ganzen Welt gleichzeitig anbieten. Beispiele: OVH, Mietwebsite и 100 TB - für dedizierte Server, Vultr и DigitalOcean — für virtuelle Cloud*.

Für unser privates CDN werden wir 3 virtuelle Server auf verschiedenen Kontinenten bestellen. Bei Vultr auf dem Server für 5 $/Monat wir werden bekommen 25GB SSD Orte und 1 TB Datenverkehr. Wählen Sie bei der Installation das neueste Debian aus. Unsere Server:

Frankfurt, IP: 199.247.18.199

Chicago, IP: 149.28.121.123

Singapur, IP: 157.230.240.216

* Vultr und DigitalOcean versprechen Benutzern, die sich unmittelbar nach dem Hinzufügen einer Zahlungsmethode über die Links im Artikel registrieren, eine Gutschrift von 100 US-Dollar. Der Autor erhält dadurch auch ein kleines Kompliment, das für ihn jetzt sehr bedeutsam ist. Bitte haben Sie Verständnis.

GeoDNS einrichten

Damit der Nutzer beim Zugriff auf eine Domain oder CDN-Subdomain zum gewünschten (nächsten) Server geleitet wird, benötigen wir einen DNS-Server mit der geoDNS-Funktion.

Das Prinzip und die Funktionsweise von geoDNS ist wie folgt:

Gibt die IP des Clients an, der die DNS-Anfrage gesendet hat, oder die IP des rekursiven DNS-Servers, der bei der Verarbeitung der Client-Anfrage verwendet wird. Bei solchen rekursiven Servern handelt es sich in der Regel um DNS-Server von Anbietern.
Die IP des Kunden erkennt sein Land oder seine Region. Hierzu werden GeoIP-Datenbanken genutzt, von denen es heute sehr viele gibt. Es gibt gute kostenlose Optionen.
Gibt dem Client je nach Standort die IP-Adresse des nächstgelegenen CDN-Servers weiter.

DNS-Server mit GeoDNS-Funktion können sein selbst zusammenbauen, aber es ist besser, vorgefertigte Lösungen mit einem Netzwerk von DNS-Servern auf der ganzen Welt zu verwenden und Anycast aus der Schachtel:

CloudDNS aus 9.95 $/Monat, GeoDNS-Tarif, standardmäßig gibt es ein DNS-Failover
Zilore aus 25 $/Monat, DNS-Failover aktiviert
Amazon Route 53 aus 35 $/Monat für netto 50 Mio. Geo-Anfragen. DNS-Failover wird separat in Rechnung gestellt
DNS leicht gemacht aus 125 $/Monat, es gibt 10 DNS-Failover
CloudflareDie Funktion „Geo Steering“ ist in Enterprise-Plänen verfügbar

Bei der Bestellung von geoDNS sollten Sie auf die im Tarif enthaltene Anzahl der Anfragen achten und bedenken, dass die tatsächliche Anzahl der Anfragen an die Domain die Erwartungen um ein Vielfaches übertreffen kann. Millionen von Spinnen, Scannern, Spammern und anderen bösen Geistern arbeiten unermüdlich.

Fast alle DNS-Dienste beinhalten einen unverzichtbaren Dienst zum Aufbau eines CDN – DNS Failover. Mit seiner Hilfe können Sie eine Überwachung des Betriebs Ihrer Server einrichten und bei fehlenden Lebenszeichen in DNS-Antworten automatisch die Adresse eines nicht funktionierenden Servers durch eine Backup-Adresse ersetzen.

Zum Aufbau unseres CDN verwenden wir CloudDNS, GeoDNS-Tarif.

Fügen wir Ihrem persönlichen Konto eine neue DNS-Zone hinzu und geben Sie dabei Ihre Domäne an. Wenn wir ein CDN auf einer Subdomain erstellen und die Hauptdomain bereits verwendet wird, vergessen Sie nicht, sofort nach dem Hinzufügen der Zone die vorhandenen funktionierenden DNS-Einträge hinzuzufügen. Der nächste Schritt besteht darin, mehrere A-Einträge für die CDN-Domäne/Subdomäne zu erstellen, die jeweils auf die von uns angegebene Region angewendet werden. Sie können Kontinente oder Länder als Regionen angeben, Unterregionen stehen für die USA und Kanada zur Verfügung.

In unserem Fall wird das CDN auf einer Subdomain erstellt cdn.sayt.in. Durch Hinzufügen einer Zone sayt.in, erstellen Sie den ersten A-Eintrag für die Subdomain und verweisen Sie ganz Nordamerika auf den Server in Chicago:

Wiederholen wir den Vorgang für andere Regionen und denken Sie daran, einen Eintrag für die Standardregionen zu erstellen. Folgendes passiert am Ende:

Der letzte Standardeintrag im Screenshot bedeutet, dass alle nicht spezifizierten Regionen (und das sind Europa, Afrika, Satelliten-Internetnutzer usw.) an den Server in Frankfurt gesendet werden.

Damit ist die grundlegende DNS-Einrichtung abgeschlossen. Es bleibt noch, auf die Website des Domain-Registrars zu gehen und die aktuellen Domain-NSs durch die von ClouDNS ausgestellten zu ersetzen. Und während die NSs aktualisiert werden, bereiten wir die Server vor.

Installation von SSL-Zertifikaten

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

Wenn keine Zertifikate vorhanden sind, können Sie bei Let's Encrypt ein kostenloses Zertifikat erhalten. Perfekt dafür ACME-Shellscript. Der Client ist bequem und einfach einzurichten und ermöglicht Ihnen vor allem die Validierung einer Domain/Subdomain per DNS über die ClouDNS-API.

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

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

Während der Installation des Skripts wird ein CRON-Job zur weiteren Erneuerung von Zertifikaten ohne unser Zutun erstellt.

Bei der Ausstellung eines Zertifikats wird die Domäne mithilfe von DNS mithilfe der API überprüft. Daher müssen Sie im persönlichen ClouDNS-Konto im Reseller-API-Menü eine neue Benutzer-API erstellen und ein Passwort dafür festlegen. Die resultierende Auth-ID mit Passwort wird in die Datei geschrieben ~/.acme.sh/dnsapi/dns_cloudns.sh (nicht zu verwechseln mit file dns_clouddns.sh). Hier sind die Zeilen, die auskommentiert und bearbeitet werden müssen:

CLOUDNS_AUTH_ID=<auth-id>
CLOUDNS_AUTH_PASSWORD="<пароль>"

Jetzt werden wir ein SSL-Zertifikat anfordern cdn.sayt.in

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

In den Optionen haben wir für die Zukunft einen Befehl festgelegt, der die Webserver-Konfiguration künftig nach jeder Verlängerung der Zertifikatsgültigkeitsdauer automatisch neu lädt.

Der gesamte Prozess zur Erlangung eines Zertifikats kann bis zu 2 Minuten dauern. Unterbrechen Sie ihn nicht. Wenn ein Domänenvalidierungsfehler auftritt, versuchen Sie, den Befehl erneut auszuführen. Am Ende sehen wir, wo die Zertifikate hochgeladen wurden:

Merken Sie sich diese Pfade. Sie müssen beim Kopieren des Zertifikats auf andere Server sowie in den Webservereinstellungen angegeben werden. Wir achten nicht auf den Fehler beim Neuladen von Nginx-Konfigurationen – es wird beim Aktualisieren von Zertifikaten nicht auf einem vollständig konfigurierten Server angezeigt.

Für SSL bleibt uns nur noch, das empfangene Zertifikat auf zwei andere Server zu kopieren und dabei den Pfad zu den Dateien beizubehalten. Lassen Sie uns auf jedem von ihnen die gleichen Verzeichnisse erstellen und eine Kopie erstellen:

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 Zertifikate regelmäßig zu aktualisieren, erstellen Sie auf beiden Servern einen täglichen CRON-Job mit dem folgenden Befehl:

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

In diesem Fall muss der Zugriff auf den Remote-Quellserver konfiguriert werden per Schlüssel, d.h. ohne Eingabe eines Passwortes. Vergessen Sie nicht, es zu tun.

Nginx installieren und konfigurieren

Um statische Inhalte bereitzustellen, verwenden wir Nginx, das als Caching-Proxyserver konfiguriert ist. Aktualisieren Sie die Paketlisten und installieren Sie es auf allen drei Servern:

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

Anstelle der Standardeinstellung verwenden wir die Konfiguration 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;
    }
  }
}

Bearbeiten Sie in der Konfiguration:

maximale Größe — die Größe des Caches, die den verfügbaren Speicherplatz nicht überschreiten darf
inaktiv - Speicherdauer der zwischengespeicherten Daten, auf die niemand zugegriffen hat
ssl_certificate и ssl_certificate_key – Pfade zu SSL-Zertifikaten und Schlüsseldateien
Proxy_cache_valid - Speicherdauer der zwischengespeicherten Daten
Proxy_pass – Adresse des ursprünglichen Servers, von dem das CDN Dateien zum Zwischenspeichern anfordert. In unserem Beispiel das sayt.in

Wie Sie sehen, ist alles einfach. Aufgrund der Ähnlichkeit der Anweisungen kann es lediglich zu Schwierigkeiten bei der Einstellung der Caching-Zeit kommen inaktiv и Proxy_cache_valid. Lassen Sie uns sie anhand unseres Beispiels analysieren. Folgendes passiert, wenn: inaktiv=7d и Proxy_cache_valid 90d:

Wird die Anfrage nicht innerhalb von 7 Tagen wiederholt, werden die Daten nach Ablauf dieser Frist aus dem Cache gelöscht
Wenn die Anfrage mindestens alle 7 Tage wiederholt wird, gelten die Daten im Cache nach 90 Tagen als veraltet und Nginx aktualisiert sie bei der nächsten Anfrage und übernimmt sie vom ursprünglichen Server

Bearbeitung abgeschlossen nginx.conf, laden Sie die Konfiguration neu:

root@cdn:~# service nginx reload

Unser CDN ist fertig. Für 15 $/Monat. Wir erhielten Präsenzpunkte auf drei Kontinenten und 3 TB Datenverkehr: 1 TB an jedem Standort.

Überprüfung der Arbeit von CDN

Schauen wir uns die Pings an unser CDN von verschiedenen geografischen Standorten aus an. Jeder Ping-Dienst funktioniert hierfür.

Startpunkt
Gastgeber
IP
Durchschnittliche Zeit, Frau

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

Großbritannien, 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 Stammverzeichnis der Hauptseite platzieren test.jpg und überprüfen Sie die Download-Geschwindigkeit über CDN. Es läutet - fertig. Inhalte werden schnell geliefert.

Schreiben wir ein kleines Skript für den Fall, dass wir den Cache auf 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, führen Sie ihn einfach aus. Eine separate Datei kann wie folgt bereinigt werden:

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

Anstelle von Schlussfolgerungen

Abschließend möchte ich noch einige nützliche Tipps geben, um sofort über den Rechen zu steigen, der mir damals Kopfschmerzen bereitete:

Um die Fehlertoleranz des CDN zu erhöhen, empfiehlt es sich, DNS-Failover zu konfigurieren, was bei einem Serverausfall hilft, den A-Eintrag schnell zu ändern. Dies erfolgt in den DNS-Einträgen der Systemsteuerung der Domäne.
Websites mit großer geografischer Abdeckung erfordern zweifellos eine große Anzahl von CDNs, aber seien wir nicht fanatisch. Höchstwahrscheinlich wird der Benutzer keinen signifikanten Unterschied zu einem kostenpflichtigen CDN bemerken, wenn Sie Server an 6-7 Standorten platzieren: Europa, Nordamerika (Ost), Nordamerika (West), Singapur, Australien, Hongkong oder Japan
Manchmal gestatten Hoster die Nutzung gemieteter Server für CDN-Zwecke nicht. Wenn Sie sich also plötzlich dazu entschließen, ein Content-Delivery-Netzwerk als Dienst bereitzustellen, vergessen Sie nicht, die Regeln eines bestimmten Hosting-Anbieters im Voraus zu lesen
Studie Unterwasser-Kommunikationskarteum darzustellen, wie die Kontinente miteinander verbunden sind, und dies beim Aufbau eines Content-Delivery-Netzwerks zu berücksichtigen
Versuchen Sie es zu überprüfen Pings von verschiedenen Orten zu Ihren Servern. Auf diese Weise können Sie die Regionen sehen, die den CDN-Punkten am nächsten liegen, und GeoDNS korrekter konfigurieren
Abhängig von den Aufgaben kann es sinnvoll sein, Nginx auf bestimmte Caching-Anforderungen und die Auslastung des Servers abzustimmen. Die Artikel über den Nginx-Cache haben mir dabei sehr geholfen - hier und Beschleunigung der Arbeit unter schweren Lasten: hier и hier

Source: habr.com