🥇 CDN-i loomine ja konfigureerimine

Sisu edastamise võrke (CDN-e) kasutavad veebisaidid ja rakendused peamiselt staatiliste elementide laadimise kiirendamiseks. See juhtub failide vahemällu salvestamisel erinevates geograafilistes piirkondades asuvates CDN-serverites. CDN-i kaudu andmeid küsides saab kasutaja need lähimast serverist.

Kõigi sisuedastusvõrkude tööpõhimõte ja funktsionaalsus on ligikaudu samad. Pärast faili allalaadimise taotluse saamist võtab CDN-server selle ühekordselt algsest serverist ja annab selle kasutajale, säilitades samal ajal selle kindlaksmääratud ajavahemikuks vahemällu. Kõikidele järgnevatele päringutele vastatakse vahemälust. Kõikidel CDN-idel on võimalused failide eellaadimiseks, vahemälu tühjendamiseks, vahemälu aegumise määramiseks ja palju muud.

Juhtub, et ühel või teisel põhjusel on vaja korraldada oma sisu edastamise võrgustik ja siis - olgu meile abiks järgmise ratta kokkupanemise juhend.

Allikas: Pikisuperstar loodud infograafiline vektor — www.freepik.com

Millal vajate oma CDN-i?

Vaatame juhtumeid, kus oma CDN-i käitamine on mõttekas:

kui soovite säästa raha ja jooksvaid kulusid isegi siis, kui kasutate selliseid odavaid CDN-e JänkuCDN ulatub mitmesaja dollarini kuus
kui tahame saada püsivat vahemälu või vahemälu ilma naabriteta serveris ja kanalis
CDN-i teenustel pole teie vajalikus piirkonnas kohalolekupunkte
Vaja on mis tahes spetsiaalseid sisu edastamise seadeid
tahame kiirendada dünaamilise sisu edastamist, asetades tootmisserverid kasutajatele lähemale
on mure, et kolmanda osapoole CDN-teenus võib valesti koguda või kasutada teavet kasutaja käitumise kohta (tere, GDPR-ga mitteühilduvad teenused) või osaleda muus ebaseaduslikus tegevuses

Enamikul muudel juhtudel on õigem kasutada olemasolevaid valmislahendusi.

Mida peate alustama

See on suurepärane, kui teil on oma autonoomne süsteem (AS). Sellega saate määrata sama IP mitmele serverile ja vastavalt sellele juhisele võrgu tasemel suunata kasutajad lähimasse. Tasub öelda, et isegi /24 aadressiplokiga on võimalik üles ehitada sisu edastamise võrk. Mõned serveripakkujad lubavad teil reklaamida kasutamiseks kõigis neile saadaolevates piirkondades.

Kui te pole IP-aadresside ploki õnnelik omanik, vajate lihtsa CDN-i käivitamiseks:

domeeninimi või alamdomeen
vähemalt kaks serverit erinevates piirkondades. Server võib olla kas pühendatud või virtuaalne
geoDNS-i tööriist. Selle abiga suunatakse domeenile ligipääsev kasutaja lähimasse serverisse

Registreerige domeen ja tellige servereid

Domeeni registreerimisega on kõik lihtne – registreerime end igas tsoonis mis tahes registripidaja juures. CDN-i jaoks saate kasutada ka alamdomeeni, näiteks midagi sellist cdn.domainname.com. Tegelikult teeme meie näites just seda.

Mis puutub serverite tellimisse, siis need tuleks rentida nendes piirkondades ja riikides, kus teie kasutajate vaatajaskond asub. Kui projekt on kontinentidevaheline, siis on mugav valida hostingu pakkujad, kes pakuvad servereid üle kogu maailma. Näited: ovh, Leaseweb и 100Tb - spetsiaalsete serverite jaoks, Vultr и DigitalOcean — virtuaalse pilve* jaoks.

Meie privaatse CDN-i jaoks tellime 3 virtuaalserverit erinevatel kontinentidel. U Vultr jaoks serveris 5 dollarit kuus me saame 25GB SSD kohad ja 1TB liiklust. Installimise ajal valime uusima Debiani. Meie serverid:

Frankfurt, ip: 199.247.18.199

Chicago, ip: 149.28.121.123

Singapur, ip: 157.230.240.216

*Vultr ja DigitalOcean lubavad 100 dollarit krediiti kasutajatele, kes registreeruvad, kasutades makseviisi lisamist, kasutades selle artikli linke. Sellest saab autor ka väikese komplimendi, mis on tema jaoks praegu väga märgiline. Palun olge mõistvad.

GeoDNS-i seadistamine

Tagamaks, et kui kasutaja pöördub CDN-i domeeni või alamdomeeni poole, suunatakse ta soovitud (lähimale) serverile, vajame geoDNS-funktsiooniga DNS-serverit.

GeoDNS-i põhimõte ja tööprotseduur on järgmine:

Määrab DNS-päringu saatnud kliendi IP-aadressi või kliendipäringu töötlemisel kasutatava rekursiivse DNS-serveri IP-aadressi. Sellised rekursiivsed serverid on tavaliselt DNS-i pakkujad.
Kliendi IP tuvastab tema riigi või piirkonna. Selleks kasutatakse GeoIP andmebaase, mida tänapäeval on väga palju. On mõned head tasuta valikud.
Sõltuvalt kliendi asukohast annab see talle lähima CDN-serveri IP-aadressi.

GeoDNS-funktsiooniga DNS-server võib olla pane see ise kokku, kuid parem on kasutada valmislahendusi DNS-serverite võrguga üle maailma ja Igatahes kastist:

CloudDNS pärit 9.95 dollarit kuus, GeoDNS-i tariif, vaikimisi on üks DNS-i tõrkevahetus
Zilore pärit 25 dollarit kuus, DNS-i tõrkevahetus lubatud
Amazoni tee 53 pärit 35 dollarit kuus puhta 50 miljoni geopäringu jaoks. DNS-i tõrkevahetuse eest tasutakse eraldi
DNS lihtsaks tehtud pärit 125 dollarit kuus, on 10 DNS-i tõrkevahetust
CloudFlare, on funktsioon „Geo Steering” saadaval ettevõtte tariifides

GeoDNS-i tellides tuleks tähelepanu pöörata tariifis sisalduvate päringute arvule ning arvestada sellega, et tegelik päringute arv domeenile võib olla oodatust kordades suurem. Miljonid ämblikud, skannerid, rämpspostitajad ja muud kurjad vaimud töötavad väsimatult.

Peaaegu kõik DNS-teenused sisaldavad hinnas asendamatut teenust CDN-i loomiseks - DNS-i tõrkevahetus. Selle abil saate seadistada oma serverite töö jälgimise ja elumärkide puudumisel asendada DNS-vastustes mittetöötava serveri aadressi automaatselt varu aadressiga.

CDN-i loomiseks kasutame CloudDNS, GeoDNS-i tariif.

Lisame teie isiklikule kontole uue DNS-tsooni, mis näitab teie domeeni. Kui ehitame CDN-i alamdomeenile ja põhidomeen on juba kasutusel, siis ärge unustage kohe pärast tsooni lisamist lisada olemasolevad töötavad DNS-kirjed. Järgmise sammuna tuleb luua CDN-i domeeni/alamdomeeni jaoks mitu A-kirjet, millest igaüht kasutatakse meie määratud piirkonna jaoks. Piirkondadena saate määrata mandreid või riike; alampiirkonnad on saadaval USA ja Kanada jaoks.

Meie puhul tõstetakse CDN alamdomeenil cdn.sayt.in. Tsooni lisamisega sayt.in, loome alamdomeeni jaoks esimese A-kirje ja suuname kogu Põhja-Ameerika Chicagos asuvasse serverisse:

Kordame toimingut teiste piirkondade jaoks, unustamata luua vaikepiirkondade jaoks üht kirjet. Siin on see, mida saate lõpuks:

Ekraanipildi viimane vaikekirje tähendab, et kõik määramata piirkonnad (ja need on Euroopa, Aafrika, satelliit-Interneti kasutajad jne) saadetakse Frankfurdis asuvasse serverisse.

See lõpetab DNS-i põhiseadistuse. Jääb üle minna domeeniregistripidaja veebisaidile ja asendada praegused domeeni NS-id ClouDNS-i väljastatud omadega. Ja NS-ide uuendamise ajal valmistame servereid ette.

SSL-sertifikaatide installimine

Meie CDN töötab HTTPS-i kaudu, nii et kui teil on domeeni või alamdomeeni jaoks juba SSL-sertifikaadid, laadige need üles kõikidesse serveritesse, näiteks kataloogi /etc/ssl/yourdomain/

Kui teil sertifikaate pole, saate selle tasuta hankida Let's Encrypti kaudu. Ideaalne selleks ACME Shelli skript. Klienti on mugav ja lihtne seadistada ning mis kõige tähtsam – see võimaldab DNS-i abil domeeni/alamdomeeni valideerida API kaudu ClouDNS-ist.

Installime acme.sh ainult ühte serverisse - Euroopa 199.247.18.199, kust sertifikaadid kopeeritakse kõigile teistele. Installimiseks toimige järgmiselt.

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

Skripti installimise ajal luuakse CRON-i ülesanne sertifikaatide edasiseks värskendamiseks ilma meie osaluseta.

Domeeni kontrollimine sertifikaadi väljastamisel toimub DNS-i kaudu API abil, seega peate oma ClouDNS-i isiklikul kontol edasimüüja API menüüs looma uue API kasutaja ja määrama sellele parooli. Kirjutame saadud auth-id koos parooliga faili ~/.acme.sh/dnsapi/dns_cloudns.sh (mitte segi ajada failiga dns_clouddns.sh). Siin on read, mida tuleb kommenteerida ja muuta:

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

Nüüd taotleme SSL-sertifikaati cdn.sayt.in

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

Tuleviku parameetrites määrasime käsu veebiserveri konfiguratsiooni automaatseks uuesti laadimiseks pärast iga sertifikaadi kehtivuse värskendust tulevikus.

Kogu sertifikaadi saamise protsess võib kesta kuni 2 minutit, ärge katkestage seda. Kui ilmneb domeeni valideerimise tõrge, proovige käsku uuesti käivitada. Lõpus näeme, kust sertifikaadid alla laaditi:

Pidagem neid teid meeles, need tuleb määrata nii sertifikaadi kopeerimisel teistesse serveritesse kui ka veebiserveri seadetes. Me ei pööra tähelepanu Nginxi konfiguratsioonide uuesti laadimise veale - täielikult konfigureeritud serveris seda sertifikaatide värskendamisel ei kuvata.

Meil jääb SSL-iga üle vaid kopeerida saadud sertifikaat kahte teise serverisse, säilitades failide tee. Loome igale neist samad kataloogid ja teeme koopia:

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/

Sertifikaatide korrapäraseks värskendamiseks loome mõlemas serveris igapäevase CRON-i ülesande käsuga:

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

Sellisel juhul tuleb konfigureerida juurdepääs kaugallika serverile võtme järgi, st. ilma parooli sisestamata. Ärge unustage seda teha.

Nginxi installimine ja konfigureerimine

Staatilise sisu teenindamiseks kasutame vahemällu salvestava puhverserverina konfigureeritud Nginxi. Värskendame pakettide loendeid ja installime selle kõigisse kolme serverisse:

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

Vaikimisi asemel kasutame alloleva spoileri konfiguratsiooni:
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;
    }
  }
}

Konfiguratsioonis muudame:

max_size — vahemälu maht ei ületa saadaolevat kettaruumi
inaktiivne — vahemällu salvestatud andmete salvestusaeg, millele pole juurde pääsetud
ssl_certificate и ssl_certificate_key — SSL-sertifikaadi ja võtmefailide teed
proxy_cache_valid — vahemällu salvestatud andmete salvestusaeg
puhverserveri_pääs — algse serveri aadress, kust CDN taotleb failide vahemällu salvestamist. Meie näites on see sayt.in

Nagu näete, on kõik lihtne. Ainus raskus võib tekkida vahemällu salvestamise aja määramisel direktiivide sarnasuse tõttu inaktiivne и proxy_cache_valid. Vaatame neid meie näitel. See juhtub siis, kui mitteaktiivne=7d и proxy_cache_valid 90d:

kui taotlust 7 päeva jooksul ei korrata, kustutatakse andmed pärast seda perioodi vahemälust
kui taotlust korratakse vähemalt kord 7 päeva jooksul, loetakse vahemälus olevad andmed 90 päeva pärast aegunuks ja järgmise päringuga uuendab Nginx seda, võttes need algsest serverist

Pärast toimetamise lõpetamist nginx.conf, laadige konfiguratsioon uuesti:

root@cdn:~# service nginx reload

Meie CDN on täielikult valmis. 15 dollari eest kuus. saime kohalolekupunkte kolmel kontinendil ja 3 TB liiklust: 1 TB igas asukohas.

CDN-i töö kontrollimine

Vaatame erinevatest geograafilistest asukohtadest meie CDN-i pingisid. Selleks sobivad kõik pingiteenused.

Alguspunkt
Host
IP
Keskmine aeg, ms

Saksamaa Berliin
cdn.sayt.in
199.247.18.199
9.6

Holland, Amsterdam
cdn.sayt.in
199.247.18.199
10.1

Prantsusmaa Pariis
cdn.sayt.in
199.247.18.199
16.3

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

Jaapan Tokyo
cdn.sayt.in
157.230.240.216
74.8

Austraalia, Sydney
cdn.sayt.in
157.230.240.216
95.9

Tulemused on head. Nüüd asetame põhisaidi juurtesse testpildi test.jpg ja kontrollige selle allalaadimiskiirust CDN-i kaudu. Öeldakse- tehtud. Sisu tarnitakse kiiresti.

Kirjutame väikese skripti juhuks, kui tahame CDN-punkti vahemälu tühjendada.
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

Kogu vahemälu kustutamiseks käivitage see; saate kustutada eraldi faili järgmiselt:

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

Järelduste asemel

Lõpetuseks tahan anda mõned kasulikud näpunäited, et kohe üle astuda kunagi peavalu valmistanud rehast:

CDN-i tõrketaluvuse suurendamiseks on soovitatav konfigureerida DNS-i tõrkevahetus, mis aitab serveri rikke korral kiiresti A-kirjet muuta. Seda tehakse domeeni DNS-kirjete juhtpaneelil
Laia geograafilise ulatusega saidid nõuavad kahtlemata suurt hulka CDN-punkte, kuid ärgem olgem fanaatilised. Tõenäoliselt ei märka kasutaja olulist erinevust tasulise CDN-iga võrreldes, kui paigutate serverid 6-7 kohta: Euroopas, Põhja-Ameerikas (ida), Põhja-Ameerikas (läänes), Singapuris, Austraalias, Hongkongis või Jaapanis.
Mõnikord ei luba hostid CDN-i eesmärkidel kasutada renditud servereid. Seetõttu, kui otsustate ootamatult teenusena kasutusele võtta sisuedastusvõrgu, ärge unustage eelnevalt lugeda oma konkreetse hostiteenuse pakkuja reegleid
Avastage veealuse side kaartkujutleda, kuidas mandrid on omavahel ühendatud, ja arvestada sellega sisuedastusvõrgu ehitamisel
Proovige kontrollida pingid erinevatest kohtadest teie serveritele. Nii näete CDN-punktidele lähimaid piirkondi ja GeoDNS-i õigemini seadistada
Sõltuvalt ülesannetest oleks kasulik kohandada Nginxi konkreetsete vahemällu salvestamise nõuete ja serveri koormusega. Artiklid Nginxi vahemälu kohta aitasid mind selles palju - siin ja töö kiirendamine suurte koormuste korral: siin и siin