Turinio pristatymo tinklus (CDN) pirmiausia naudoja svetainės ir programos, kad paspartintų statinių elementų įkėlimą. Tai atsitinka talpykloje talpinant failus CDN serveriuose, esančiuose skirtinguose geografiniuose regionuose. Prašydamas duomenų per CDN, vartotojas juos gauna iš artimiausio serverio.
Visų turinio pristatymo tinklų veikimo principas ir funkcionalumas yra maždaug vienodi. CDN serveris, gavęs užklausą atsisiųsti failą, vieną kartą paima jį iš pradinio serverio ir perduoda vartotojui, kartu saugodamas jį talpykloje tam tikrą laiką. Į visus tolesnius prašymus atsakoma iš talpyklos. Visuose CDN yra parinktys iš anksto įkelti failus, išvalyti talpyklą, nustatyti talpyklos galiojimo laiką ir dar daugiau.
Pasitaiko, kad dėl vienokių ar kitokių priežasčių tenka susitvarkyti savo turinio pristatymo tinklą, o tada – gal mums pagelbės kito dviračio surinkimo instrukcijos.

Šaltinis:
Kada jums reikia savo CDN?
Pažvelkime į atvejus, kai prasminga paleisti savo CDN:
- kai norite sutaupyti pinigų ir eksploatacinių išlaidų net naudojant nebrangius CDN, pvz siekia kelis šimtus dolerių per mėnesį
- jei norime gauti nuolatinę talpyklą arba talpyklą be kaimynų serveryje ir kanale
- CDN paslaugos neturi buvimo vietos jums reikalingame regione
- Reikalingi bet kokie specialūs turinio pateikimo nustatymai
- norime paspartinti dinamiško turinio pristatymą, pastatydami gamybos serverius arčiau vartotojų
- nerimaujama, kad trečiosios šalies CDN paslauga gali netinkamai rinkti arba naudoti informaciją apie naudotojų elgesį (sveiki, su BDAR neatitinkančiomis paslaugomis) arba užsiimti kita neteisėta veikla
Daugeliu kitų atvejų tikslingiau naudoti esamus paruoštus sprendimus.
Ko reikia norint pradėti
Puiku, jei turite savo autonominę sistemą (AS). Su juo galite priskirti tą patį IP keliems serveriams ir tinklo lygiu nukreipti vartotojus į artimiausią. Verta pasakyti, kad net ir naudojant /24 adresų bloką galima sukurti turinio pristatymo tinklą. Kai kurie serverių teikėjai leidžia reklamuotis visuose jiems prieinamuose regionuose.
Jei nesate laimingas IP adresų bloko savininkas, norėdami paleisti paprastą CDN, jums reikės:
- domeno vardas arba subdomenas
- bent du serveriai skirtinguose regionuose. Serveris gali būti skirtas arba virtualus
- geoDNS įrankis. Su jo pagalba vartotojas, pasiekiantis domeną, bus nukreiptas į artimiausią serverį
Užregistruokite domeną ir užsakykite serverius
Su domeno registracija viskas paprasta – registruojamės bet kurioje zonoje pas bet kurį registratorių. Taip pat galite naudoti CDN padomenį, pavyzdžiui, kažką panašaus cdn.domenovardas.com. Tiesą sakant, mūsų pavyzdyje mes tai padarysime.
Kalbant apie serverių užsakymą, jie turėtų būti nuomojami regionuose ir šalyse, kur yra jūsų vartotojų auditorija. Jei projektas yra tarpžemyninis, tuomet patogu rinktis prieglobos tiekėjus, siūlančius serverius visame pasaulyje. Pavyzdžiai: , и - skirtiems serveriams, и — virtualiam debesiui*.
Privačiam CDN užsakysime 3 virtualius serverius skirtinguose žemynuose. U Vultr serveryje 5 USD/mėn mes gausime 25GB SSD vietas ir 1 TB srautas. Diegimo metu pasirinksime naujausią „Debian“. Mūsų serveriai:
Frankfurtas, ip: 199.247.18.199
Čikagos, ip: 149.28.121.123
Singapūras, ip: 157.230.240.216
* „Vultr“ ir „DigitalOcean“ žada 100 USD kreditą naudotojams, kurie prisiregistruoja naudodami šiame straipsnyje pateiktas nuorodas, kai tik prideda mokėjimo metodą. Iš to autorius sulaukia ir nedidelio komplimento, kuris jam dabar labai reikšmingas. Prašau būti supratingi.
GeoDNS nustatymas
Kad vartotojas, prisijungęs prie CDN domeno ar subdomeno, būtų nukreiptas į norimą (artimiausią) serverį, mums reikės DNS serverio su geoDNS funkcija.
GeoDNS principas ir veikimo tvarka yra tokia:
- Apibrėžia kliento, kuris išsiuntė DNS užklausą, IP arba rekursinio DNS serverio, kuris naudojamas apdorojant kliento užklausą, IP. Tokie rekursyvūs serveriai dažniausiai yra DNS teikėjai.
- Kliento IP identifikuoja jo šalį ar regioną. Tam naudojamos GeoIP duomenų bazės, kurių šiandien yra labai daug. Yra keletas gerų .
- Priklausomai nuo kliento vietos, jis suteikia jam artimiausio CDN serverio IP adresą.
DNS serveris su geoDNS funkcija gali būti , bet geriau naudoti paruoštus sprendimus su DNS serverių tinklu visame pasaulyje ir iš dėžės:
- nuo 9.95 USD/mėn, GeoDNS tarifas, pagal numatytuosius nustatymus yra vienas DNS perkrovimas
- nuo 25 USD/mėn, DNS Failover įjungtas
- nuo 35 USD/mėn vien tik 50 mln. geografinių užklausų. DNS Failover apmokestinamas atskirai
- nuo 125 USD/mėn, yra 10 DNS klaidų
- , funkcija „Geo Steering“ yra įmonės tarifuose
Užsakant geoDNS reikėtų atkreipti dėmesį į į tarifą įtrauktų užklausų skaičių ir atsižvelgti į tai, kad realus užklausų skaičius į domeną gali būti daug kartų didesnis nei tikėtasi. Milijonai vorų, skaitytuvų, šiukšlių siuntėjų ir kitų piktųjų dvasių dirba nenuilstamai.
Beveik visos DNS paslaugos į kainą įtrauktos nepakeičiama paslauga kuriant CDN – DNS perkėlimas. Su jo pagalba galite nustatyti savo serverių veikimo stebėjimą ir, jei nėra gyvybės ženklų, automatiškai pakeisti neveikiančio serverio adresą DNS atsakymuose atsarginiu.
Norėdami sukurti savo CDN, mes naudosime , GeoDNS tarifas.
Pridėkite naują DNS zoną į jūsų asmeninę paskyrą, nurodydami jūsų domeną. Jei kuriame CDN subdomene, o pagrindinis domenas jau naudojamas, tada iškart pridėję zoną nepamirškite pridėti esamų veikiančių DNS įrašų. Kitas žingsnis – sukurti kelis CDN domeno / subdomeno A įrašus, kurių kiekvienas bus naudojamas mūsų nurodytame regione. Galite nurodyti žemynus arba šalis kaip regionus; subregionai galimi JAV ir Kanadai.
Mūsų atveju CDN bus padidintas padomenyje cdn.sayt.in. Pridedant zoną pasakyti.in, sukurkime pirmąjį subdomeno A įrašą ir nukreipkime visą Šiaurės Ameriką į serverį Čikagoje:

Pakartokime veiksmą kitiems regionams, nepamiršdami sukurti vieno įrašo numatytiems regionams. Štai ką jūs gaunate pabaigoje:

Paskutinis numatytasis įrašas ekrano kopijoje reiškia, kad visi nenurodyti regionai (tai yra Europa, Afrika, palydovinio interneto vartotojai ir kt.) bus siunčiami į serverį Frankfurte.
Tai užbaigia pagrindinę DNS sąranką. Belieka eiti į domenų registratoriaus svetainę ir pakeisti dabartinius domeno NS „ClouDNS“ išduotais. O kol bus atnaujinami NS, paruošime serverius.
SSL sertifikatų diegimas
Mūsų CDN veiks per HTTPS, taigi, jei jau turite domeno ar padomenio SSL sertifikatus, įkelkite juos į visus serverius, pavyzdžiui, į katalogą /etc/ssl/yourdomain/
Jei neturite sertifikatų, galite gauti nemokamą sertifikatą iš Let's Encrypt. Puikiai tam tinka . Klientas yra patogus ir lengvai konfigūruojamas, o svarbiausia – leidžia patvirtinti domeną/subdomeną naudojant DNS per API iš ClouDNS.
Įdiegsime acme.sh tik viename iš serverių – Europos 199.247.18.199, iš kurio sertifikatai bus nukopijuoti į visus kitus. Norėdami įdiegti, atlikite:
root@cdn:~# wget -O - https://get.acme.sh | bash; source ~/.bashrcDiegiant scenarijų bus sukurta CRON užduotis tolesniam sertifikatų atnaujinimui be mūsų dalyvavimo.
Domeno tikrinimas išduodant sertifikatą bus atliekamas per DNS naudojant API, todėl asmeninėje ClouDNS paskyroje Perpardavėjo API meniu reikia susikurti naują API vartotoją ir jam nustatyti slaptažodį. Gautą autentifikavimo ID su slaptažodžiu įrašysime į failą ~/.acme.sh/dnsapi/dns_cloudns.sh (nepainioti su byla dns_clouddns.sh). Štai eilutes, kurias reikia nekomentuoti ir redaguoti:
CLOUDNS_AUTH_ID=<auth-id>
CLOUDNS_AUTH_PASSWORD="<пароль>"
Dabar paprašykime SSL sertifikato cdn.sayt.in
root@cdn:~# acme.sh --issue --dns dns_cloudns -d cdn.sayt.in --reloadcmd "service nginx reload"Ateityje parametruose nurodėme komandą automatiškai iš naujo įkelti žiniatinklio serverio konfigūraciją po kiekvieno sertifikato galiojimo atnaujinimo ateityje.
Visas pažymėjimo gavimo procesas gali užtrukti iki 2 minučių, jo nenutraukite. Jei įvyksta domeno patvirtinimo klaida, pabandykite paleisti komandą dar kartą. Pabaigoje pamatysime, kur buvo atsisiųsti sertifikatai:

Prisiminkime šiuos kelius, juos reikės nurodyti kopijuojant sertifikatą į kitus serverius, taip pat žiniatinklio serverio nustatymuose. Nekreipiame dėmesio į Nginx konfigūracijų perkrovimo klaidą – pilnai sukonfigūruotame serveryje ji neatsiras atnaujinant sertifikatus.
Mums su SSL belieka nukopijuoti gautą sertifikatą į du kitus serverius, išsaugant kelią iki failų. Kiekviename iš jų sukurkime tuos pačius katalogus ir padarykime kopiją:
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/
Norėdami reguliariai atnaujinti sertifikatus, abiejuose serveriuose sukursime kasdienę CRON užduotį naudodami komandą:
scp -r root@199.247.18.199:/root/.acme.sh/cdn.sayt.in/* /root/.acme.sh/cdn.sayt.in/ && service nginx reload
Tokiu atveju turi būti sukonfigūruota prieiga prie nuotolinio šaltinio serverio , t.y. neįvedus slaptažodžio. Nepamirškite tai padaryti.
Nginx diegimas ir konfigūravimas
Norėdami teikti statinį turinį, naudosime „Nginx“, sukonfigūruotą kaip talpyklos tarpinį serverį. Atnaujinkime paketų sąrašus ir įdiegkime jį visuose trijuose serveriuose:
root@cdn:~# apt update
root@cdn:~# apt install nginxVietoj numatytosios, mes naudojame konfigūraciją iš toliau esančio spoilerio:
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;
}
}
}Konfigūracijoje mes redaguojame:
- maksimalus_dydis — talpyklos dydis neviršija laisvos vietos diske
- neveiklus — talpykloje saugomų duomenų, prie kurių nebuvo prieita, saugojimo laikas
- ssl_certificate и ssl_certificate_key — keliai į SSL sertifikatą ir raktų failus
- proxy_cache_valid — talpykloje esančių duomenų saugojimo laikas
- proxy_pass — pradinio serverio, iš kurio CDN prašys failų talpykloje saugojimo, adresas. Mūsų pavyzdyje tai yra pasakyti.in
Kaip matote, viskas paprasta. Vienintelis sunkumas gali kilti nustatant talpyklos laiką dėl direktyvų panašumo neveiklus и proxy_cache_valid. Pažvelkime į juos naudodami mūsų pavyzdį. Štai kas atsitinka, kai neaktyvus=7d и proxy_cache_valid 90d:
- jei prašymas nepakartojamas per 7 dienas, po šio laikotarpio duomenys iš talpyklos bus ištrinti
- jei užklausa kartojama bent kartą per 7 dienas, po 90 dienų talpykloje esantys duomenys bus laikomi pasenę ir su kita užklausa Nginx juos atnaujins, paimdama iš pradinio serverio
Baigęs redaguoti nginx.conf, iš naujo įkelkite konfigūraciją:
root@cdn:~# service nginx reloadMūsų CDN yra visiškai paruoštas. Už 15 USD/mėn. gavome buvimo vietas trijuose žemynuose ir 3 TB srauto: po 1 TB kiekvienoje vietoje.
CDN veikimo patikrinimas
Pažvelkime į mūsų CDN siuntimus iš skirtingų geografinių vietų. Tam tinka bet kokios ping paslaugos.
Pradžios taškas
Šeimininkas
IP
Vidutinis laikas, ms
Vokietija Berlynas
cdn.sayt.in
199.247.18.199
9.6
Nyderlandai, Amsterdamas
cdn.sayt.in
199.247.18.199
10.1
Prancūzija Paryžius
cdn.sayt.in
199.247.18.199
16.3
Didžioji Britanija, Londonas
cdn.sayt.in
199.247.18.199
14.9
Kanada, Torontas
cdn.sayt.in
149.28.121.123
16.2
JAV, San Franciskas
cdn.sayt.in
149.28.121.123
52.7
JAV, Dalasas
cdn.sayt.in
149.28.121.123
23.1
JAV, Čikaga
cdn.sayt.in
149.28.121.123
2.6
JAV, Niujorkas
cdn.sayt.in
149.28.121.123
19.8
Singapūras
cdn.sayt.in
157.230.240.216
1.7
Japonija Tokijas
cdn.sayt.in
157.230.240.216
74.8
Australija, Sidnėjus
cdn.sayt.in
157.230.240.216
95.9
Rezultatai geri. Dabar įdėkite bandomąjį vaizdą pagrindinės svetainės šaknyje test.jpg ir patikrinkite jo atsisiuntimo greitį per CDN. Yra sakoma - . Turinys pristatomas greitai.
Parašykime nedidelį scenarijų, jei norėtume išvalyti talpyklą CDN taške.
valymas.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
Norėdami ištrinti visą talpyklą, tiesiog paleiskite ją; galite išvalyti atskirą failą, pavyzdžiui:
root@cdn:~# ./purge.sh /test.jpgVietoj išvadų
Pabaigai noriu duoti keletą naudingų patarimų, kaip iš karto peržengti grėblį, dėl kurio kažkada skaudėjo galvą:
- Norint padidinti CDN gedimų toleranciją, rekomenduojama sukonfigūruoti DNS Failover, kuri padeda greitai pakeisti A įrašą serverio gedimo atveju. Tai atliekama domeno DNS įrašų valdymo skydelyje
- Plataus geografinio pasiekiamumo svetainėms neabejotinai reikės daug CDN taškų, bet nebūkime fanatiški. Greičiausiai vartotojas nepastebės reikšmingo skirtumo, palyginti su mokamu CDN, jei serverius pastatysite 6–7 vietose: Europoje, Šiaurės Amerikoje (rytuose), Šiaurės Amerikoje (vakaruose), Singapūre, Australijoje, Honkonge ar Japonijoje.
- Kartais prieglobos serveriai neleidžia naudoti nuomojamų serverių CDN tikslais. Todėl, jei staiga nuspręsite kaip paslaugą įdiegti turinio pristatymo tinklą, nepamirškite iš anksto perskaityti konkretaus prieglobos paslaugų teikėjo taisyklių.
- Naršyti įsivaizduoti, kaip sujungti žemynai, ir į tai atsižvelgti kuriant turinio pristatymo tinklą
- Pabandykite patikrinti į savo serverius. Taip galite matyti arčiausiai CDN taškų esančius regionus ir tiksliau sukonfigūruoti GeoDNS
- Atsižvelgiant į užduotis, būtų naudinga pritaikyti Nginx pagal specifinius talpyklos reikalavimus ir atsižvelgiant į serverio apkrovą. Straipsniai apie Nginx talpyklą man labai padėjo - ir darbo pagreitis esant didelėms apkrovoms: и
Šaltinis: www.habr.com
