🥇Opbygning og konfiguration af dit CDN

Content Delivery Networks (CDN'er) bruges i websteder og applikationer primært for at fremskynde indlæsningen af statiske elementer. Dette sker på grund af caching af filer på CDN-servere placeret i forskellige geografiske områder. Ved at anmode om data via CDN, modtager brugeren dem fra den nærmeste server.

Princippet for drift og funktionalitet af alle indholdsleveringsnetværk er omtrent det samme. Efter at have modtaget en anmodning om at downloade en fil, tager CDN-serveren den én gang fra den originale server og giver den til brugeren, samtidig med at den cachelagrer den i et bestemt tidsrum. Alle efterfølgende anmodninger besvares fra cachen. Alle CDN'er har muligheder for at forudindlæse filer, rydde cachen, indstille udløbsdatoen og mere.

Det sker, at du af den ene eller anden grund skal organisere dit eget indholdsleveringsnetværk, og så - lad instruktionerne til montering af den næste cykel være til hjælp for os.

Kilde: Infografisk vektor skabt af pikisuperstar - www.freepik.com

Når du har brug for dit eget CDN

Overvej de tilfælde, hvor det giver mening at køre dit eget CDN:

når der er et ønske om at spare penge, og driftsomkostninger, selv når du bruger billige CDN'er som BunnyCDN beløber sig til flere hundrede dollars om måneden
hvis vi ønsker at få en permanent cache eller en cache uden server- og kanalnaboer
CDN-tjenester har ikke tilstedeværelsespunkter i den region, du har brug for
eventuelle særlige indstillinger for indholdslevering påkrævet
vi ønsker at fremskynde leveringen af dynamisk indhold ved at placere produktionsserveren tættere på brugerne
der er en bekymring for, at en tredjeparts CDN-tjeneste ulovligt kan indsamle eller bruge oplysninger om brugeradfærd (hej ikke-GDPR-kompatible tjenester) eller deltage i andre ulovlige aktiviteter

I de fleste andre tilfælde er det mere hensigtsmæssigt at bruge eksisterende færdige løsninger.

Hvad skal du bruge for at starte

Det er vidunderligt, hvis du har dit eget Autonome System (AS). Med den kan du tildele den samme IP til flere servere og i henhold til denne instruktion på netværksniveau, diriger brugerne til den nærmeste. Det er værd at sige, at selv med /24-adresseblokken er det muligt at bygge et indholdsleveringsnetværk. Nogle serverudbydere giver dig mulighed for at lave en meddelelse til brug i alle områder, der er tilgængelige for dem.

Hvis du ikke er en glad ejer af en blok af IP-adresser, skal du bruge følgende for at køre et simpelt CDN:

domænenavn eller underdomæne
mindst to servere i forskellige regioner. Serveren kan enten være dedikeret eller virtuel
geoDNS værktøj. Med den vil brugeren, der har adresseret domænet, blive dirigeret til den nærmeste server

Registrer et domæne og bestil servere

Med domæneregistrering er alt enkelt - vi registrerer i enhver zone hos enhver registrator. Du kan også bruge et underdomæne til et CDN, for eksempel noget lignende cdn.domænenavn.com. Faktisk vil vi i vores eksempel gøre netop det.

Hvad angår bestilling af servere, bør de lejes i de regioner og lande, hvor dit brugerpublikum er placeret. Hvis projektet er interkontinentalt, så er det praktisk at vælge hostingudbydere, der tilbyder servere over hele verden på én gang. Eksempler: OVH, leje web и 100Tb - til dedikerede servere, Vultr и DigitalOcean — til virtuel sky*.

Til vores private CDN vil vi bestille 3 virtuelle servere på forskellige kontinenter. På Vultr på serveren til $5/md vi får 25GB SSD steder og 1 TB trafik. Når du installerer, skal du vælge den seneste Debian. Vores servere:

Frankfurt, IP: 199.247.18.199

Chicago, IP: 149.28.121.123

Singapore, IP: 157.230.240.216

*Vultr og DigitalOcean lover $100 kredit til brugere, der registrerer sig via links i artiklen umiddelbart efter tilføjelse af en betalingsmetode. Forfatteren får også en lille kompliment heraf, som er meget betydningsfuld for ham nu. Vær venligst forstående.

Opsætning af geoDNS

For at brugeren kan blive dirigeret til den ønskede (nærmeste) server ved adgang til et domæne eller CDN-underdomæne, har vi brug for en DNS-server med geoDNS-funktionen.

Princippet og driften af geoDNS er som følger:

Angiver IP-adressen for den klient, der sendte DNS-anmodningen, eller IP-adressen for den rekursive DNS-server, der bruges ved behandling af klientanmodningen. Sådanne rekursive servere er normalt DNS-er fra udbydere.
Klientens IP genkender hans land eller region. Til dette bruges GeoIP-databaser, som der er rigtig mange af i dag. Der er gode gratis muligheder.
Afhængigt af placeringen af klienten, giver ham IP-adressen på den nærmeste CDN-server.

DNS-server med geoDNS-funktion kan være samle selv, men det er bedre at bruge færdige løsninger med et netværk af DNS-servere rundt om i verden og anycast fra kassen:

CloudDNS fra $9.95/md, GeoDNS-takst, som standard er der én DNS-failover
Zilore fra $25/md, DNS-failover aktiveret
Amazonrute 53 fra $35/md for netto 50 mio. geo-anmodninger. DNS Failover faktureres separat
DNS gjort nemt fra $125/md, er der 10 DNS-failovers
CloudFlare, "Geo Steering"-funktionen er tilgængelig i Enterprise-planer

Når du bestiller geoDNS, skal du være opmærksom på antallet af forespørgsler inkluderet i taksten og huske på, at det faktiske antal forespørgsler til domænet kan overstige forventningerne flere gange. Millioner af edderkopper, scannere, spammere og andre onde ånder arbejder utrætteligt.

Næsten alle DNS-tjenester inkluderer en uundværlig service til at bygge en CDN - DNS Failover. Med dens hjælp kan du opsætte overvågning af driften af dine servere og, i mangel af tegn på liv, automatisk erstatte adressen på en ikke-fungerende server med en backup i DNS-svar.

Til at bygge vores CDN, vil vi bruge CloudDNS, GeoDNS takst.

Lad os tilføje en ny DNS-zone på din personlige konto, med angivelse af dit domæne. Hvis vi bygger et CDN på et underdomæne, og hoveddomænet allerede er i brug, så glem ikke umiddelbart efter tilføjelse af zonen at tilføje de eksisterende fungerende DNS-poster. Det næste trin er at oprette flere A-records for CDN-domænet / underdomænet, som hver vil blive anvendt til den region, vi har specificeret. Du kan angive kontinenter eller lande som regioner, underregioner er tilgængelige for USA og Canada.

I vores tilfælde vil CDN blive rejst på et underdomæne cdn.sayt.in. Ved at tilføje en zone sayt.in, opret den første A-record for underdomænet og peg hele Nordamerika til serveren i Chicago:

Lad os gentage handlingen for andre regioner, og husk at oprette én post for standardregionerne. Her er hvad der sker i sidste ende:

Den sidste standardindtastning i skærmbilledet betyder, at alle uspecificerede regioner (og disse er Europa, Afrika, satellitinternetbrugere osv.) vil blive sendt til serveren i Frankfurt.

Dette fuldender den grundlæggende DNS-opsætning. Det er tilbage at gå til domæneregistratorens websted og erstatte de nuværende domæne-NS'er med dem, der er udstedt af ClouDNS. Og mens NS'erne vil blive opdateret, forbereder vi serverne.

Installation af SSL-certifikater

Vores CDN vil fungere over HTTPS, så hvis du allerede har SSL-certifikater for et domæne eller underdomæne, skal du uploade dem til alle servere, for eksempel til biblioteket /etc/ssl/ditdomæne/

Hvis der ikke er nogen certifikater, kan du få et gratis fra Let's Encrypt. Perfekt til dette ACME Shellscript. Klienten er praktisk og nem at sætte op, og vigtigst af alt giver den dig mulighed for at validere et domæne/underdomæne via DNS via ClouDNS API.

Vi vil kun installere acme.sh på én af serverne - European 199.247.18.199, hvorfra certifikater vil blive kopieret til alle de andre. For at installere skal du køre:

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

Under installationen af scriptet vil der blive oprettet et CRON-job til yderligere fornyelse af certifikater uden vores deltagelse.

Når du udsteder et certifikat, vil domænet blive kontrolleret ved hjælp af DNS ved hjælp af API, så i ClouDNS personlige konto i Reseller API-menuen, skal du oprette en ny bruger API og indstille en adgangskode til den. Det resulterende auth-id med en adgangskode vil blive skrevet i filen ~/.acme.sh/dnsapi/dns_cloudns.sh (ikke at forveksle med fil dns_clouddns.sh). Her er de linjer, der skal ukommenteres og redigeres:

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

Nu vil vi anmode om et SSL-certifikat for cdn.sayt.in

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

I mulighederne har vi for fremtiden specificeret en kommando til automatisk at genindlæse webserverkonfigurationen efter hver fornyelse af certifikatets gyldighedsperiode i fremtiden.

Hele processen med at få et certifikat kan tage op til 2 minutter, afbryd det ikke. Hvis der opstår en domænevalideringsfejl, skal du prøve at køre kommandoen igen. Til sidst vil vi se, hvor certifikaterne er blevet uploadet:

Husk disse stier, de skal angives, når certifikatet kopieres til andre servere, såvel som i webserverindstillingerne. Vi er ikke opmærksomme på fejlen ved at genindlæse Nginx-konfigurationer - den vil ikke være på en fuldt konfigureret server, når certifikater opdateres.

Det eneste, vi har tilbage til SSL, er at kopiere det modtagne certifikat til to andre servere, mens stien til filerne bevares. Lad os oprette de samme mapper på hver af dem og lave en kopi:

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/

For at opdatere certifikater regelmæssigt skal du oprette et dagligt CRON-job på begge servere med kommandoen:

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

I dette tilfælde skal adgangen til fjernkildeserveren konfigureres med nøgle, dvs. uden at indtaste en adgangskode. Glem ikke at gøre det.

Installation og konfiguration af Nginx

For at servere statisk indhold vil vi bruge Nginx konfigureret som en caching proxy-server. Opdater pakkelisterne og installer den på alle tre servere:

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

I stedet for standarden bruger vi konfigurationen fra spoileren nedenfor:
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;
    }
  }
}

Rediger i konfigurationen:

max_størrelse — størrelsen af cachen, der ikke overstiger den tilgængelige diskplads
inaktive - Lagringstid for cachelagrede data, som ingen fik adgang til
ssl_certificate и ssl_certifikatnøgle — stier til SSL-certifikat og nøglefiler
proxy_cache_valid - Lagringstid for cachelagrede data
proxy_pass — Adressen på den originale server, hvorfra CDN vil anmode om filer til caching. I vores eksempel er dette sayt.in

Som du kan se, er alt enkelt. Der kan kun opstå vanskeligheder med at indstille cachingtiden på grund af ligheden mellem direktiverne inaktive и proxy_cache_valid. Lad os analysere dem med vores eksempel. Her er hvad der sker hvornår inaktiv=7d и proxy_cache_valid 90d:

hvis anmodningen ikke gentages inden for 7 dage, slettes dataene fra cachen efter denne periode
hvis anmodningen gentages mindst én gang hver 7. dag, vil dataene i cachen blive betragtet som forældede efter 90 dage, og Nginx vil opdatere dem med den næste anmodning og tage dem fra den originale server

Færdig med at redigere nginx.conf, genindlæs konfigurationen:

root@cdn:~# service nginx reload

Vores CDN er klar. For $15/md. vi modtog tilstedeværelsespunkter på tre kontinenter og 3 TB trafik: 1 TB på hvert sted.

Kontrol af CDN's arbejde

Lad os se på pingene til vores CDN fra forskellige geografiske steder. Enhver ping-tjeneste vil fungere for dette.

Startpunkt
Vært
IP
Gns. tid, ms

Tyskland Berlin
cdn.sayt.in
199.247.18.199
9.6

Holland, Amsterdam
cdn.sayt.in
199.247.18.199
10.1

Frankrig Paris
cdn.sayt.in
199.247.18.199
16.3

Storbritannien, London
cdn.sayt.in
199.247.18.199
14.9

Canada, 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

Singapore
cdn.sayt.in
157.230.240.216
1.7

Japan Tokyo
cdn.sayt.in
157.230.240.216
74.8

Australien, Sydney
cdn.sayt.in
157.230.240.216
95.9

Resultaterne er gode. Nu vil vi placere et testbillede i roden af hovedsiden test.jpg og kontroller dens downloadhastighed via CDN. Det siges - Færdig. Indholdet leveres hurtigt.

Lad os skrive et lille script, hvis vi ønsker at rydde cachen på CDN-punktet.
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

For at slette hele cachen skal du bare køre den, en separat fil kan renses sådan her:

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

I stedet for konklusioner

Til sidst vil jeg give nogle nyttige tips til straks at træde over den rive, der gjorde ondt i hovedet på det tidspunkt:

For at øge CDN'ens fejltolerance anbefales det at konfigurere DNS Failover, som hjælper med hurtigt at ændre A-recorden i tilfælde af servernedbrud. Dette gøres i kontrolpanelets DNS-records for domænet.
Websteder med bred geografisk dækning kræver uden tvivl et stort antal CDN'er, men lad os ikke være fanatiske. Mest sandsynligt vil brugeren ikke bemærke en væsentlig forskel sammenlignet med et betalt CDN, hvis du placerer servere på 6-7 steder: Europa, Nordamerika (øst), Nordamerika (vest), Singapore, Australien, Hong Kong eller Japan
Nogle gange tillader hostere ikke brugen af lejede servere til CDN-formål. Derfor, hvis du pludselig beslutter dig for at implementere et indholdsleveringsnetværk som en service, så glem ikke at læse reglerne for en bestemt hostingudbyder på forhånd
Udforske undervands kommunikationskortat repræsentere, hvordan kontinenterne er forbundet og tage højde for dette, når du bygger et indholdsleveringsnetværk
Prøv at tjekke pinger fra forskellige steder til dine servere. På denne måde kan du se regionerne tættest på CDN-punkterne og konfigurere GeoDNS mere korrekt
Afhængigt af opgaverne vil det være nyttigt at finjustere Nginx til specifikke cachingkrav og under hensyntagen til belastningen på serveren. Artiklerne om Nginx cache hjalp mig meget i dette - her og acceleration af arbejde under tunge belastninger: her и her

Kilde: www.habr.com