🥇We bouwen en configureren onze eigen CDN

Content delivery networks (CDN) are used on websites and in applications primarily to speed up the loading of static elements. This is achieved by caching files on CDN servers located in different geographical regions. When requesting data through the CDN, the user receives it from the nearest server.

The principle of operation and functionality of all content delivery networks is roughly the same. Upon receiving a request to load a file, the CDN server retrieves it once from the original server and delivers it to the user while caching it for a specified period. For all subsequent requests, the response is served from the cache. All CDNs have options for preloading files, clearing the cache, configuring the duration of its storage, and much more.

Sometimes, for various reasons, it becomes necessary to organize your own content delivery network, and then — let us help you with the assembly instructions for yet another bicycle.

Bron: Infographic vector created by pikisuperstar — www.freepik.com

When do you need your own CDN

Let’s consider cases when launching your own CDN makes sense:

when you want to save money and current expenses even when using inexpensive CDNs like BunnyCDN amount to several hundred dollars per month
if you want to have persistent cache or cache without neighbors on the server and channel
in the region you need, CDN services have no points of presence
special configuration for content delivery is required
if you want to speed up the delivery of dynamic content by placing production servers closer to users
if there is concern that a third-party CDN service may unlawfully collect or use information about user behavior (hello to services that are not GDPR-compliant) or engage in other unlawful activities

In most other cases, it is more advisable to use existing ready-made solutions.

What is needed to launch

It’s great if you have your own autonomous system (AS). With it, you can assign the same IP to multiple servers and according to this instruction route users to the nearest one at the network level. It is worth noting that even with a /24 block of addresses, it is possible to build a content delivery network. Some server providers allow announcing for use in all available regions.

Als je geen gelukkige eigenaar bent van een blok IP-adressen, dan heb je voor het opzetten van een eenvoudige CDN nodig:

een domeinnaam of subdomein
minimaal twee servers in verschillende regio's. De server kan zowel dedicated als virtueel zijn
geoDNS-tool. Hiermee wordt de gebruiker, wanneer deze naar het domein gaat, naar de dichtstbijzijnde server geleid

Registreer een domein en bestel servers

Met de registratie van het domein is het eenvoudig — je registreert in elke zone bij elke registrar. Ook voor de CDN kan een subdomein worden gebruikt, bijvoorbeeld iets zoals cdn.uwdomeinnaam.com. In ons voorbeeld doen we dat ook.

Wat betreft het bestellen van servers — het is verstandig om ze te huren in de regio's en landen waar uw gebruikers zich bevinden. Als het project internationaal is, is het handig om hostingproviders te kiezen die servers wereldwijd aanbieden. Voorbeelden: OVH, Leaseweb en 100Tb — voor dedicated servers, Vultr en DigitalOcean — voor virtuele cloudservers*.

Voor onze particuliere CDN bestellen we 3 virtuele servers op verschillende continenten. Bij Vultr de server voor $5/maand krijgen we 25GB SSD ruimte en 1 TB dataverkeer. Bij de installatie kiezen we de laatste versie van Debian. Onze servers:

Frankfurt, ip: 199.247.18.199

Chicago, ip: 149.28.121.123

Singapore, ip: 157.230.240.216

* Vultr en DigitalOcean beloven $100 krediet aan gebruikers die zich registreren via de links in dit artikel, direct na het toevoegen van hun betaalmethode. De auteur ontvangt ook een kleine vergoeding hiervan, wat momenteel belangrijk voor hem is. Wees alstublieft begripvol.

Stel geoDNS in

Om ervoor te zorgen dat de gebruiker bij toegang tot het domein of subdomein van de CDN naar de juiste (dichtstbijzijnde) server wordt geleid, hebben we een DNS-server met geoDNS-functionaliteit nodig.

Het principe en de werkwijze van geoDNS zijn als volgt:

Het bepaalt het IP-adres van de client die het DNS-verzoek heeft verzonden, of het IP-adres van de recursieve DNS-server die wordt gebruikt bij de verwerking van het klantverzoek. Dergelijke recursieve servers zijn meestal de DNS-servers van providers.
Aan de hand van het IP-adres van de client kan het de land of regio vaststellen. Hiervoor worden GeoIP-databases gebruikt, waarvan er tegenwoordig vele zijn. Er zijn enkele goede gratis opties.
Afhankelijk van de locatie van de client geeft het het IP-adres van de dichtstbijzijnde CDN-server.

Een DNS-server met geoDNS-functionaliteit kan zelf worden samengesteld, maar het is beter om kant-en-klare oplossingen te gebruiken met een netwerk van DNS-servers over de hele wereld en Anycast out of the box:

ClouDNS van $9.95/maand, GeoDNS-tarief, standaard is er één DNS Failover
Zilore van $25/maand, ingeschakeld DNS Failover
Amazon Route 53 van €35/maand voor 50M geo-verzoeken. DNS Failover wordt apart in rekening gebracht
DNS Made Easy van €125/maand, met 10 DNS Failover
Cloudflare, de functie ‘Geo Steering’ is beschikbaar in Enterprise pakketten

Bij het bestellen van geoDNS is het belangrijk om het aantal aanvragen dat bij het pakket is inbegrepen in de gaten te houden, en dat het daadwerkelijke aantal verzoeken naar de domein meerdere keren hoger kan zijn dan verwacht. Miljoenen spiders, scanners, spammers en andere ongewenste bezoekers werken onophoudelijk.

Bij vrijwel alle DNS-diensten is de onmisbare dienst voor het bouwen van een CDN — DNS Failover — bij de prijs inbegrepen. Hiermee kan je de status van je servers monitoren en in geval van geen activiteit automatisch het adres van de niet-werkende server in DNS-antwoorden vervangen door dat van een reserve-server.

Voor het bouwen van ons CDN gebruiken we ClouDNS, het GeoDNS-pakket.

We voegen een nieuwe DNS-zone toe in het klantendashboard, door onze domein op te geven. Als we het CDN willen bouwen op een subdomein, en het hoofddomein al in gebruik is, vergeet dan niet na het toevoegen van de zone de bestaande werkende DNS-records toe te voegen. De volgende stap is het creëren van verschillende A-records voor de CDN domein/subdomein, waarbij elke record van toepassing zal zijn voor het door ons opgegeven gebied. Als gebieden kunnen continenten of landen worden opgegeven, en voor de VS en Canada zijn subregio's beschikbaar.

In ons geval zal het CDN worden opgezet op het subdomein cdn.sayt.in. Nadat we de zone hebben toegevoegd sayt.in, creëren we de eerste A-record voor het subdomein en leiden we heel Noord-Amerika naar de server in Chicago:

Herhaal deze actie voor andere gebieden, en vergeet niet één record voor de standaardgebieden te creëren. Dit is wat het resultaat zal zijn:

De laatste default record op de screenshot betekent dat alle niet-gespecificeerde gebieden (zoals Europa, Afrika, gebruikers van satellietinternet, enz.) zullen worden geleid naar de server in Frankfurt.

Hiermee is de basisinstelling van de DNS voltooid. We moeten nu naar de website van de domeinregistrar gaan en de huidige NS-records van het domein vervangen door die van ClouDNS. En terwijl de NS-records worden bijgewerkt, bereiden we de servers voor.

Installatie van SSL-certificaten

Onze CDN zal werken via HTTPS, dus als u al SSL-certificaten voor het domein of subdomein heeft, — upload ze naar alle servers, bijvoorbeeld naar de map /etc/ssl/вашдомен/

Als er geen certificaten zijn, kunt u gratis een verkrijgen van Let’s Encrypt. Hiervoor is ACME Shell script. De client is gemakkelijk en eenvoudig in te stellen, en het belangrijkste is dat het mogelijk maakt om een domein/subdomein te valideren via DNS via de ClouDNS API.

We zullen acme.sh alleen op één van de servers installeren - de Europese 199.247.18.199; van daaruit zullen de certificaten naar alle andere worden gekopiëerd. Voor de installatie voeren we uit:

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

Tijdens de installatie van het script wordt er een CRON-taak aangemaakt voor het automatisch vernieuwen van de certificaten zonder onze tussenkomst.

De domeinvalidatie bij het uitgeven van het certificaat zal via DNS plaatsvinden met behulp van de API, dus in het ClouDNS-account in het Reseller API-menu moeten we een nieuwe API-gebruiker aanmaken en een wachtwoord voor hem instellen. We zullen de verkregen auth-id met het wachtwoord in het bestand invullen ~/ .acme.sh/dnsapi/dns_cloudns.sh (verwissel dit niet met het bestand dns_clouWe verwijderen de huidige partitie om een nieuwe aan te maken voor in totaal 50 GB.dns.sh). Hier zijn de regels die we moeten uitcommentariëren en bewerken:

CLOUDNS_AUTH_ID=
CLOUDNS_AUTH_PASSWORD=""

Nu vragen we het SSL-certificaat aan voor cdn.sayt.in

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

In de parameters hebben we voor de toekomst de opdracht opgegeven voor automatische herstart van de webserverconfiguratie na elke vervaldatum van het certificaat.

Het hele proces van het verkrijgen van het certificaat kan tot 2 minuten duren, onderbreek het niet. Als er een validatiefout optreedt, probeer dan de opdracht opnieuw uit te voeren. Aan het einde zien we waar de certificaten zijn geladen:

Onthoud deze paden, ze moeten worden opgegeven bij het kopiëren van het certificaat naar andere servers, evenals in de instellingen van de webserver. We geven geen aandacht aan de fout bij het herladen van de Nginx-configuraties - op een volledig ingestelde server zal deze niet optreden bij het vernieuwen van certificaten.

We hoeven alleen nog maar het verkregen certificaat naar twee andere servers te kopiëren met behoud van het pad naar de bestanden. We maken op elk van hen dezelfde mappen aan en maken een 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/

Om de certificaatvernieuwing regelmatig te maken, creëren we op beide servers een dagelijkse CRON-taak met de opdracht:

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

Tegelijkertijd moet de toegang tot de externe brondserver zijn ingesteld via sleutel, d.w.z. zonder invoer van een wachtwoord. Vergeet niet om dit te doen.

Installatie en configuratie van Nginx

Voor het leveren van statische content zullen we Nginx gebruiken, geconfigureerd als een caching proxyserver. We werken de pakketlijsten bij en installeren het op alle drie servers:

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

In plaats van de standaardconfiguratie gebruiken we de configuratie hieronder:
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 de configuratie passen we het volgende aan:

max_size — de maximale cachegrootte, die niet groter mag zijn dan de beschikbare schijfruimte
inactive — de tijd dat gecachte gegevens worden bewaard zonder dat er naar wordt verwezen
ssl_certificate en ssl_certificate_key — paden naar de SSL-certificaat- en sleutelbestanden
proxy_cache_valid — de tijd dat gecachte gegevens bewaard worden
proxy_pass — adres van de originele server, van waaruit de CDN bestanden zal ophalen voor caching. In ons voorbeeld is dit sayt.in

Zoals we zien, is het eenvoudig. De enige moeilijkheid kan ontstaan bij het instellen van de cachingtijd vanwege de overeenkomst tussen de directieven. inactive en proxy_cache_validLaten we ze op ons voorbeeld bekijken. Dit is wat er gebeurt bij inactive=7d en proxy_cache_valid 90d:

als het verzoek niet binnen 7 dagen wordt herhaald, worden de gegevens uit de cache verwijderd na afloop van deze periode
als het verzoek minstens eenmaal in de 7 dagen wordt herhaald, worden de gegevens in de cache als verouderd beschouwd na 90 dagen en bij het volgende verzoek zal Nginx ze vernieuwen door ze van de originele server te halen

Nadat we klaar zijn met het wijzigen nginx.conf, herstarten we de configuratie:

root@cdn:~# service nginx reload

Onze CDN is volledig klaar. Voor $15/maand hebben we punten van aanwezigheid op drie continenten en 3 TB verkeer: elk 1 TB op elke locatie.

We controleren de werking van de CDN

Laten we de ping naar onze CDN vanuit verschillende geografische locaties bekijken. Hiervoor zijn alle ping-services geschikt.

Startpunt
Host
IP
Gem. tijd, ms

Duitsland, Berlijn
cdn.sayt.in
199.247.18.199
9.6

Nederland, Amsterdam
cdn.sayt.in
199.247.18.199
10.1

Frankrijk, Parijs
cdn.sayt.in
199.247.18.199
16.3

Verenigd Koninkrijk, Londen
cdn.sayt.in
199.247.18.199
14.9

Canada, Toronto
cdn.sayt.in
149.28.121.123
16.2

VS, San Francisco
cdn.sayt.in
149.28.121.123
52.7

VS, Dallas
cdn.sayt.in
149.28.121.123
23.1

VS, Chicago
cdn.sayt.in
149.28.121.123
2.6

VS, New York
cdn.sayt.in
149.28.121.123
19.8

Singapore
cdn.sayt.in
157.230.240.216
1.7

Japan, Tokyo
cdn.sayt.in
157.230.240.216
74.8

Australia, Sydney
cdn.sayt.in
157.230.240.216
95.9

De resultaten zijn goed. We zullen nu een testafbeelding in de root van de hoofdsite plaatsen test.jpg en de laadsnelheid ervan via CDN controleren. Het is gezegd, — is gedaan. De content wordt snel geleverd.

We zullen een klein script schrijven voor het geval we de cache op het CDN-punt willen wissen.
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

Om alle cache te verwijderen, hoef je alleen maar het te starten; een apart bestand kan zo worden gewist:

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

In plaats van resultaten

Ten slotte wil ik enkele nuttige tips geven, zodat je meteen over de hobbels heen springt die mij ooit pijn hebben gedaan:

Voor het verhogen van de beschikbaarheid van de CDN is het aan te raden om DNS Failover in te stellen, wat helpt om snel de A-record te veranderen in geval van een serverfout. Dit kan gedaan worden in het controlepaneel van de DNS-records van het domein
Websites met een brede geografische dekking vereisen ongetwijfeld een groot aantal CDN-punten, maar laten we het met beleid aanpakken. Waarschijnlijk merkt de gebruiker geen significante verschillen in vergelijking met betaalde CDN als je servers op 6-7 locaties plaatst: Europa, Noord-Amerika (oost), Noord-Amerika (west), Singapore, Australië, Hongkong of Japan
Soms staat de hostingprovider niet toe dat gehuurde servers voor CDN-doeleinden worden gebruikt. Daarom, als je besluit om een contentdistributienetwerk als een service op te zetten, vergeet dan niet om van tevoren de regels van de specifieke hostingprovider te lezen
Bestudeer de kaart van onderzeese communicaties, zodat je begrijpt hoe de continenten met elkaar verbonden zijn en dit in overweging kunt nemen bij het opzetten van je contentdistributienetwerk
Probeer de pings vanuit verschillende locaties naar je servers te controleren. Zo kun je de dichtstbijzijnde regio's bij de CDN-punten zien en GeoDNS nauwkeuriger instellen
Afhankelijk van de taken kan het nuttig zijn om Nginx verder af te stemmen op de specifieke eisen van caching en rekening te houden met de belasting op de server. Ik heb veel gehad aan artikelen over Nginx-caching — hier en over het versnellen van prestaties bij hoge belasting: hier en hier