🥇 Kogume ja seadistame oma CDN

Sisu edastamise võrgud (CDN) kasutatakse peamiselt veebisaitidel ja rakendustes staatiliste elementide laadimise kiirusel. See toimub failide vahemällu salvestamise teel CDN-serverites, mis asuvad erinevates geograafilistes piirkondades. Kui kasutaja küsib andmeid läbi CDN-i, saab ta need lähimast serverist.

Kuna tööpõhimõte ja funktsioonid on kõigil sisu edastamise võrkudel enam-vähem samad, võtab CDN-server failitaotluse saabudes korra faili originaalserverist ja edastab selle kasutajale, samal ajal vahemällu salvestades. Kõik järgnevad taotlused saavad vastuse vahemälust. Kõigil CDN-idel on failide eelneva laadimise, vahemälu puhastamise, selle säilitamise aja seadistamise ja palju muud võimalused.

Mõnikord on tarvis korraldada oma sisu edastamise võrk ning sel juhul — olgu meie abiks järgmise ratta monteerimise juhend.

Allikas: Infograafika vektor loodud pikisuperstar — www.freepik.com

Millal on vajalik oma CDN

Vaatleme olukordi, kus oma CDN-i käivitamine on mõistlik:

kui soovite kokku hoida, aga praegused kulud isegi odavate CDNide nagu BunnyCDN ulatuvad mitmesaja dollarini kuus
kui soovime saada püsivat vahemälu või vahemälu ilma serveri ja kanaliga naabriteta
teie sihtriigis ei ole CDN teenustel kohaloleku punkte
on vajalikud mingid erilised sisu edastamise seadistused
soovime kiirendada dünaamilise sisu edastamist, paigutades tootmisserverid lähemale kasutajatele
on mure, et kolmas osapool CDN teenus võib ebaseaduslikult koguda või kasutada teavet kasutajate käitumise kohta (tere GDPR-iga kooskõlastatud teenustele) või tegeleda muude ebaseaduslike tegevustega

Enamikul teistel juhtudel on mõttekam kasutada olemasolevaid lahendusi.

Mida on vaja käivitamiseks

Tore, kui teil on oma iseseisev süsteem (AS). Sellega on võimalik määrata sama IP mitmele serverile ja järgida seda juhendit võrgu tasemel suunata kasutajad lähimasse. Tuleb välja tuua, et isegi /24 aadressiblokiga on võimalik luua sisu edastamise võrgustik. Mõned serveriteenuse osutajad võimaldavad teha kuulutuse kõigis nende saadaval olevates piirkondades.

Kui te ei ole õnnelik IP aadresside bloki omanik, siis simple CDN-i käivitamiseks vajate:

domeeninime või alamdomeeni
vähemalt kahte serverit erinevates piirkondades. Server võib olla nii pühendatud kui ka virtuaalne
geoDNS tööriist. Selle abiga suunatakse kasutaja, kui ta pöördub domeeni poole, lähimasse serverisse

Registreerime domeeni ja tellime serverid

Domeeni registreerimine on lihtne — registreerige see igas tsoonis igasuguse registri kaudu. Samuti saab CDN-i jaoks kasutada alamdomeeni, näiteks midagi sellist nagu cdn.domeeninimi.com. Meie näite puhul teeme just nii.

Mis puudutab serverite tellimist — need tuleks rentida regioonides ja riikides, kus asub teie kasutajaskond. Kui projekt on rahvusvaheline, on mugav valida hostinguteenuse pakkujad, kes pakuvad servereid üle kogu maailma. Näited: OVH, Leaseweb ja 100Tb — pühendatud serveritele, Vultr ja DigitalOcean — virtuaalsete pilvserverite jaoks*.

Meie eraldi CDN jaoks tellime 3 virtuaalset serverit erinevatesse mandritesse. Vultr serveris hinnaga $5/kuus saame 25GB SSD ruumi ja 1TB liiklust. Paigaldamisel valime viimase Debian'i versiooni. 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 krediiti kasutajatele, kes registreeruvad artiklis toodud linkide kaudu, kohe pärast makseviisi lisamist. Autor saab ka sellest väikese boonuse, mis on talle praegu väga oluline. Palun olge mõistvad.

Seame üles geoDNS

Et suunata kasutaja CDN-i domeeni või subdomeeni kaudu õigesse (temale lähimasse) serverisse, on meil vaja DNS-serverit, millel on geoDNS funktsioon.

geoDNS-i põhimõte ja töökorraldus on järgmised:

Määrab IP-aadressi kliendilt, kes saatis DNS-päringu, või rekursiivse DNS-serveri IP-aadressi, mida kasutatakse kliendipäringu töötlemisel. Sellised rekursiivsed serverid on tavaliselt teenusepakkujate DNS-id.
Kliendi IP-aadressi põhjal tuvastab selle riigi või regiooni. Selleks kasutatakse GeoIP andmebaase, mida on tänapäeval tohutult palju. On olemas ka häid tasuta valikud.
Kliendi asukohast sõltuvalt antakse talle lähima CDN serveri IP-aadress.

DNS-server geolocation funktsiooniga geoDNS saab ise kokku panna, kuid parem on kasutada valmis lahendusi, kus on DNS-serverid üle kogu maailma ja Anycast valmis lahendused:

ClouDNS alates $9.95/kuus, GeoDNS plaanis on juba üks DNS Failover
Zilore alates $25/kuus, sisalduv DNS Failover
Amazon Route 53 alates $35/kuus 50M geokülastuse eest. DNS Failover arvestatakse eraldi
DNS Made Easy alates $125/kuus, sisaldab 10 DNS Failoverit
Cloudflare, „Geo Steering” funktsioon on saadaval Enterprise plaanides

geoDNS tellimisel on oluline jälgida plaani sisaldavate pöördumiste arvu ja arvestada, et tegelik domeeni pöördumiste arv võib olla mitu korda suurem, kui oodata. Miljonid ämblikud, skännerid, rämpspostitajad ja muud sarnased töötavad ööpäevaringselt.

Peaaegu kõigil DNS-teenustel on hinnas sisaldatud CDN-i ülesehitamiseks vajalik teenus — DNS Failover. Sellega saab seadistada oma serverite töö jälgimise ning juhul, kui elu märke ei ole, asendada automaatselt DNS-i vastustes mitteaktiivse serveri aadress varurdserveriga.

Meie CDN-i ehitamiseks kasutame ClouDNS, GeoDNS plaan.

Loo meie isiklikus kabinetis uus DNS-tsoon, märkides oma domeeni. Kui CDN ehitatakse alamdomeenile ja peamine domeen on juba kasutusel, siis peale tsooni lisamist ärge unustage lisada olemasolevaid töötavaid DNS-kirjeid. Järgmine samm on luua CDN-ile domeeni/alamdomeeni jaoks mitu A-kirjet, millest igaüks rakendub meie määratud piirkonnale. Piirkondadena saab valida kontinente või riike, Ameerika Ühendriikides ja Kanadas on saadaval alamregionid.

Meie juhul tõstetakse CDN alamdomeenile cdn.sayt.in. Tsoon lisades sayt.in, loome alamdomeeni jaoks esimese A-kirje ja suuname kogu Põhja-Ameerika serveerimise Chicago serverisse:

Korrame toimingut teiste piirkondade jaoks, unustamata luua ühte kirjet vaikepiirkondade jaoks. Nii see lõpuks välja näeb:

Viimane vaike kirje ekraanipildil tähendab, et kõik määramatud piirkonnad (sealhulgas Euroopa, Aafrika, satelliitinternetikasutajad jne) suunatakse Frankfurdi serverisse.

DNS-i baaseseade on nüüd lõpetatud. Jääb vaid minna domeeni registreerija veebisaidile ja asendada domeeni praegused NS-id ClouDNS-i poolt antud omajagu. Sel ajal, kui NS-id uuenevad, valmistame serverid ette.

SSL sertifikaatide paigaldamine

Meie CDN töötab HTTPS-i kaudu, seega kui teil on juba domeeni või alamdomeeni jaoks SSL sertifikaadid, laadige need üles kõikidele serveritele, näiteks kausta /etc/ssl/вашдомен/

Kui sertifikaate ei ole, saab tasuta sertifikaadi Let’s Encrypt-ilt. Sel eesmärgil sobib suurepäraselt ACME Shell skript. Klient on mugav ja lihtne seadistada, ning mis kõige olulisem — võimaldab teha domeeni/alamdomeeni valideerimist DNS-i kaudu ClouDNS-i API kaudu.

Paigaldame acme.sh ainult ühte serverisse — Euroopa 199.247.18.199, kust sertifikaadid kopeeritakse kõikidesse ülejäänud. Paigaldamiseks täidame:

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

Skripti paigaldamise käigus luuakse CRON-ülesanne sertifikaatide edasise uuendamise jaoks ilma meie sekkumiseta.

Domeeni kontrollimine sertifikaadi väljastamise ajal toimub DNS-i kaudu API kasutades, seega tuleb ClouDNSi isiklikus kabinetis menüüs Reseller API luua uus API kasutaja ja määrata talle parool. Saadud auth-id koos parooliga paneme faili. ~/.acme.sh/dnsapi/dns_cloudns.sh (ära sega seda faili dns_clouddns.sh). Siin on read, mida tuleb kommenteerida ja redigeerida:

CLOUDNS_AUTH_ID=
CLOUDNS_AUTH_PASSWORD=""

Nüüd küsime SSL-sertifikaadi saamist aadressile cdn.sayt.in

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

Parameetrites oleme tulevikuks määranud veebiserveri konfigureerimise automaatse taaskäivitamise käsu pärast sertifikaadi kehtivuse pikendamise igat värskendust.

Kogu sertifikaadi saamise protsess võib võtta kuni 2 minutit, mitte katkestage seda. Kui domeeni valideerimisega tekib viga, proovige käsku veel kord käivitada. Lõpus näeme, kuhu sertifikaadid said laaditud:

Needime need teid, et neid kasutada sertifikaadi kopeerimisel teistele serveritele ning samuti veebiserveri seadetes. Nginx-i konfigureerimise laadimise viga ignoreerime, — täielikult seadistatud serveris ei teki seda sertifikaatide värskendamise ajal.

Kõik, mis meil SSL-i osas on jäänud, — on kopeerida saadud sertifikaat kahe teise serverisse, säilitades failide tee. Loome igas neis samasugused 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 värskendamise regulaarseks tagamiseks loome mõlemas serveris igapäevase CRON-i ülesande järgmise käsuga:

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

Sel juhul peab ligipääs kaugserverile olema seadistatud võtmega, st ilma parooli sisestamata. Ära unusta seda teha.

Nginx-i installimine ja seadistamine

Kandmiseks staatilise sisu me kasutame Nginx-i, mis on konfigureeritud vahemälu proxy-serverina. Värskendame paketilisti ja installime selle kõikidesse kolme serverisse:

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

Kasutame allpool toodud spoilerist konfiguratsiooni vaikesätte asemel:
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 suurus, mis ei ületa saadaval olevat kettaruumi
inactive — vahemälu andmete säilitamise aeg, millega mitte keegi ei kasuta
ssl_certificate ja ssl_certificate_key — teed SSL sertifikaadi ja võtme failide juurde
proxy_cache_valid — vahemälu andmete säilitamise aeg
proxy_pass — originaalserveri aadress, kust CDN palub faile vahemällu salvestamiseks. Meie näites see on sayt.in

Nagu näha, on kõik lihtne. Raskusi võib tekkida ainult vahemälu seadistamise ajas, kuna direktiivid on sarnased. inactive ja proxy_cache_validUurime neid meie näitel. Näiteks toimub järgmine: inactive=7d ja proxy_cache_valid 90d:

Kui päring ei kordu 7 päeva jooksul, siis andmed eemaldatakse vahemälust pärast seda perioodi.
Kui päring kordub vähemalt korra 7 päeva jooksul, loetakse andmed vahemälus aegunuks 90 päeva pärast ja järgmise päringu korral uuendab Nginx neid, võttes need originaalserverilt.

Lõpetades muutmise nginx.conf, laadime konfiguratsiooni uuesti:

root@cdn:~# service nginx reload

Meie CDN on täielikult valmis. $15/kuus saime kohalolupunktid kolmel kontinendil ja 3 TB liiklust: 1 TB igas asukohas.

Kontrollime CDN-i tööd

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

Käivitamispunkt
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. Paigaldame nüüd testpildi põhisaidi juurte. test.jpg ja kontrollime selle laadimiskiirus CDN-i kaudu. Nii on — tehtud. Sisu edastatakse kiiresti.

Kirjutame väikese skripti juhuks, kui soovime CDN-punktis vahemälu kustutada.
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 eemaldamiseks piisab lihtsalt selle käivitamisest, eraldi faili saab puhtaks teha nii:

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

Kokkuvõtte asemel

Lõpetuseks tahan jagada mõningaid kasulikke näpunäiteid, et kohe alustada mööda raisakotka teed, mis kunagi mulle peavalu valmistas:

CDN-i tõrkeotsingute tõhususe suurendamiseks soovitatakse seadistada DNS Failover, mis aitab kiiresti A-kirje vahetada serveri rikke korral. Seda tehakse domeeni DNS-kirjete juhtpaneelil
Laialdase geograafilise katvusega saidid nõuavad kindlasti suurt hulka CDN-punkte, kuid teeme seda mõõdukalt. Tõenäoliselt ei märkavad kasutajad märkimisväärset erinevust kui kasutate tasulist CDN-i, kui paigutate serverid 6-7 kohas: Euroopa, Põhja-Ameerika (ida), Põhja-Ameerika (lääs), Singapur, Austraalia, Hongkong või Jaapan.
Mõned hostid ei luba renditud serverite kasutamist CDN-i eesmärkidel. Seetõttu, kui otsustate rakendada sisu edastamise võrgustikku teenusena, lugege kindlasti konkreetse hostimisteenuse pakkuja reeglid eelnevalt läbi.
Uurige aluskommunikatsiooni kaarti, et mõista, kuidas kontinentide vahelised sidemed on ja arvestada seda sisu edastamise võrgu ülesehitamisel.
Proovige kontrollida pinget erinevatest kohtadest oma serveritele. Nii saab näha, millised piirkonnad on CDN-punktidega kõige lähemal, ning GeoDNS-i seadistamine õnnestub paremini.
Olenevalt ülesannetest ei tee paha ka Nginx-i täiendav seadistamine, et kohandada seda konkreetsete vahemälu nõuete ja serveri koormuse arvestamisega. Siin aitas mind väga palju Nginx-i vahemälu ja suurte koormuste kiirusartiklid: siit Ja töö kiirus suurtel koormustel: siit ja siit