ProHoster > Blog > uprava > Izgradnja i konfiguracija vašeg CDN-a

Izgradnja i konfiguracija vašeg CDN-a

Mreže za isporuku sadržaja (CDN) koriste se na web stranicama i aplikacijama prvenstveno za ubrzavanje učitavanja statičkih elemenata. To se događa zbog predmemoriranja datoteka na CDN poslužiteljima koji se nalaze u različitim geografskim regijama. Zahtijevanjem podataka putem CDN-a, korisnik ih dobiva od najbližeg servera.

Princip rada i funkcionalnost svih mreža za dostavu sadržaja približno je isti. Nakon što primi zahtjev za preuzimanjem datoteke, CDN poslužitelj je jednokratno preuzima s originalnog poslužitelja i daje korisniku, istovremeno je pohranjujući u predmemoriju na određeno vrijeme. Na sve sljedeće zahtjeve odgovara se iz predmemorije. Svi CDN-ovi imaju opcije za predučitavanje datoteka, brisanje predmemorije, postavljanje datuma isteka i više.

Dogodi se da iz ovog ili onog razloga trebate organizirati vlastitu mrežu za dostavu sadržaja, a onda - neka nam upute za sastavljanje sljedećeg bicikla budu od pomoći.

Izgradnja i konfiguracija vašeg CDN-a
Izvor: Infografski vektor kreiran od strane pikisuperstar - www.freepik.com

Kada trebate vlastiti CDN

Razmotrite slučajeve u kojima ima smisla pokrenuti vlastiti CDN:

  • kada postoji želja za uštedom novca i tekućih troškova čak i kada se koriste jeftini CDN-ovi poput BunnyCDN iznose nekoliko stotina dolara mjesečno
  • ako želimo dobiti stalni cache ili cache bez susjeda poslužitelja i kanala
  • CDN usluge nemaju točke prisutnosti u regiji koja vam je potrebna
  • sve potrebne posebne postavke za isporuku sadržaja
  • želimo ubrzati isporuku dinamičkog sadržaja postavljanjem proizvodnog poslužitelja bliže korisnicima
  • postoji zabrinutost da CDN usluga treće strane može nezakonito prikupljati ili koristiti informacije o ponašanju korisnika (zdravo uslugama koje nisu usklađene s GDPR-om) ili sudjelovati u drugim nezakonitim aktivnostima

U većini drugih slučajeva prikladnije je koristiti postojeća gotova rješenja.

Što vam je potrebno za početak

Divno je ako imate svoj autonomni sustav (AS). Pomoću njega možete dodijeliti isti IP za nekoliko poslužitelja i prema ovoj uputi na razini mreže usmjerava korisnike na najbližu. Vrijedno je reći da je čak i s adresnim blokom /24 moguće izgraditi mrežu za isporuku sadržaja. Neki pružatelji poslužitelja dopuštaju vam da napravite najavu za korištenje u svim regijama koje su im dostupne.

Ako niste sretni vlasnik bloka IP adresa, za pokretanje jednostavnog CDN-a trebat će vam:

  • naziv domene ili poddomene
  • najmanje dva poslužitelja u različitim regijama. Poslužitelj može biti namjenski ili virtualni
  • geoDNS alat. Njime će korisnik, nakon adrese domene, biti usmjeren na najbliži poslužitelj

Registrirajte domenu i naručite servere

Kod registracije domene sve je jednostavno - registriramo se u bilo kojoj zoni kod bilo kojeg registrara. Također možete koristiti poddomenu za CDN, na primjer nešto poput cdn.imedomene.com. Zapravo, u našem primjeru ćemo učiniti upravo to.

Što se tiče naručivanja poslužitelja, oni bi trebali biti iznajmljeni u regijama i zemljama u kojima se nalazi vaša korisnička publika. Ako je projekt interkontinentalni, onda je zgodno odabrati hosting providere koji nude poslužitelje po cijelom svijetu odjednom. Primjeri: OVH, zakup web и 100Tb - za namjenske poslužitelje, Vultr и DigitalOcean — za virtualni oblak*.

Za naš privatni CDN naručit ćemo 3 virtualna poslužitelja na različitim kontinentima. Na Vultr na poslužitelju za 5 USD/mj dobit ćemo 25GB SSD mjesta i 1TB prometa. Prilikom instalacije odaberite najnoviji Debian. Naši poslužitelji:

Izgradnja i konfiguracija vašeg CDN-a Frankfurt, ip: 199.247.18.199

Izgradnja i konfiguracija vašeg CDN-a Čikago, ip: 149.28.121.123

Izgradnja i konfiguracija vašeg CDN-a Singapur, ip: 157.230.240.216

*Vultr i DigitalOcean obećavaju 100 USD kredita korisnicima koji se registriraju putem poveznica u članku odmah nakon dodavanja načina plaćanja. Autor time dobiva i mali kompliment, koji je za njega sada vrlo značajan. Molimo za razumijevanje.

Postavljanje geoDNS-a

Kako bi se korisnik prilikom pristupa domeni ili CDN poddomeni usmjerio na željeni (najbliži) poslužitelj potreban nam je DNS poslužitelj s geoDNS funkcijom.

Princip i rad geoDNS-a je sljedeći:

  1. Određuje IP adresu klijenta koji je poslao DNS zahtjev ili IP adresu rekurzivnog DNS poslužitelja koji se koristi prilikom obrade zahtjeva klijenta. Takvi rekurzivni poslužitelji obično su DNS-ovi pružatelja usluga.
  2. IP klijenta prepoznaje njegovu zemlju ili regiju. Za to se koriste GeoIP baze podataka, kojih danas ima jako puno. Ima dobrih besplatne opcije.
  3. Ovisno o lokaciji klijenta, daje mu IP adresu najbližeg CDN poslužitelja.

DNS poslužitelj s geoDNS funkcijom može biti sastavite sami, ali bolje je koristiti gotova rješenja s mrežom DNS poslužitelja diljem svijeta i anycast iz kutije:

  • SlouDNS iz 9.95 USD/mj, GeoDNS tarifa, standardno postoji jedan DNS Failover
  • Zilore iz 25 USD/mj, DNS Failover omogućen
  • Amazonova ruta 53 iz 35 USD/mj za neto 50 milijuna geo-zahtjeva. DNS Failover se naplaćuje zasebno
  • DNS olakšan iz 125 USD/mj, postoji 10 DNS failovera
  • CloudFlare, značajka "Geo Steering" dostupna je u Enterprise planovima

Prilikom naručivanja geoDNS-a obratite pozornost na broj zahtjeva uključenih u tarifu i imajte na umu da stvarni broj zahtjeva prema domeni može višestruko premašiti očekivanja. Milijuni pauka, skenera, spamera i drugih zlih duhova neumorno rade.

Gotovo sve DNS usluge uključuju neizostavnu uslugu za izgradnju CDN-a - DNS Failover. Uz njegovu pomoć možete postaviti nadzor nad radom svojih poslužitelja i, u nedostatku znakova života, automatski zamijeniti adresu neradnog poslužitelja rezervnom u DNS odgovorima.

Za izgradnju našeg CDN-a koristit ćemo se CloudDNS, GeoDNS tarifa.

Dodajmo novu DNS zonu u vaš osobni račun, navodeći vašu domenu. Ako gradimo CDN na poddomeni, a glavna domena je već u upotrebi, tada odmah nakon dodavanja zone ne zaboravite dodati postojeće radne DNS zapise. Sljedeći korak je stvaranje nekoliko A-zapisa za CDN domenu/poddomenu, od kojih će svaki biti primijenjen na regiju koju smo naveli. Možete navesti kontinente ili zemlje kao regije, podregije su dostupne za SAD i Kanadu.

U našem slučaju, CDN će biti podignut na poddomeni cdn.sayt.in. Dodavanjem zone sayt.in, stvorite prvi A-zapis za poddomenu i usmjerite cijelu Sjevernu Ameriku na poslužitelj u Chicagu:

Izgradnja i konfiguracija vašeg CDN-a
Ponovimo radnju za druge regije, ne zaboravimo stvoriti jedan unos za zadane regije. Evo što se na kraju događa:

Izgradnja i konfiguracija vašeg CDN-a

Zadnji zadani unos na snimci zaslona znači da će sve neodređene regije (a to su Europa, Afrika, korisnici satelitskog interneta itd.) biti poslane na poslužitelj u Frankfurtu.

Ovo dovršava osnovno postavljanje DNS-a. Preostaje otići na web stranicu registra domene i zamijeniti trenutne NS-ove domena onima koje je izdao ClouDNS. I dok se NS ažuriraju, mi ćemo pripremiti poslužitelje.

Instalacija SSL certifikata

Naš CDN radit će preko HTTPS-a, pa ako već imate SSL certifikate za domenu ili poddomenu, prenesite ih na sve poslužitelje, na primjer, u imenik /etc/ssl/vašadomena/

Ako nema certifikata, možete ga dobiti besplatno od Let's Encrypt. Savršeno za ovo ACME Shellscript. Klijent je praktičan i jednostavan za postavljanje, a što je najvažnije, omogućuje provjeru valjanosti domene/poddomene pomoću DNS-a putem ClouDNS API-ja.

Instalirat ćemo acme.sh samo na jedan od poslužitelja - europski 199.247.18.199, s kojeg će se certifikati kopirati na sve ostale. Za instalaciju pokrenite:

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

Tijekom instalacije skripte kreirat će se CRON posao za daljnju obnovu certifikata bez našeg sudjelovanja.

Prilikom izdavanja certifikata domena će se provjeravati putem DNS-a pomoću API-ja, stoga u ClouDNS osobnom računu u izborniku Reseller API potrebno je kreirati novi korisnički API i za njega postaviti lozinku. Rezultirajući auth-id s lozinkom bit će zapisan u datoteci ~/.acme.sh/dnsapi/dns_cloudns.sh (ne smije se brkati s datotekom dns_clouddns.sh). Evo redaka koje je potrebno odkomentirati i urediti:

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

Sada ćemo zatražiti SSL certifikat za cdn.sayt.in

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

U opcijama smo za ubuduće naveli naredbu za automatsko ponovno učitavanje konfiguracije web poslužitelja nakon svake obnove roka valjanosti certifikata u budućnosti.

Cijeli proces dobivanja certifikata može trajati do 2 minute, nemojte ga prekidati. Ako se pojavi pogreška provjere valjanosti domene, pokušajte ponovo pokrenuti naredbu. Na kraju ćemo vidjeti gdje su certifikati učitani:

Izgradnja i konfiguracija vašeg CDN-a

Zapamtite ove staze, morat ćete ih navesti prilikom kopiranja certifikata na druge poslužitelje, kao iu postavkama web poslužitelja. Ne obraćamo pozornost na pogrešku ponovnog učitavanja Nginx konfiguracija - neće biti na potpuno konfiguriranom poslužitelju prilikom ažuriranja certifikata.

Sve što nam preostaje za SSL je kopirati primljeni certifikat na druga dva poslužitelja zadržavajući putanju do datoteka. Kreirajmo iste direktorije na svakom od njih i napravimo kopiju:

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/

Za redovito ažuriranje certifikata, kreirajte dnevni CRON posao na oba poslužitelja pomoću naredbe:

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

U tom slučaju pristup udaljenom izvornom poslužitelju mora biti konfiguriran po ključu, tj. bez unosa lozinke. Ne zaboravite to učiniti.

Instalacija i konfiguracija Nginx-a

Za posluživanje statičnog sadržaja koristit ćemo Nginx konfiguriran kao proxy poslužitelj za predmemoriju. Ažurirajte popise paketa i instalirajte ga na sva tri poslužitelja:

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

Umjesto zadane, koristimo konfiguraciju iz spojlera ispod:
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;
    }
  }
}

Uredi u konfiguraciji:

  • maksimalna_veličina — veličina predmemorije, koja ne prelazi raspoloživi prostor na disku
  • neaktivan - vrijeme pohrane predmemoriranih podataka kojima nitko nije pristupio
  • ssl_certificate и ssl_certificate_key — staze do SSL certifikata i datoteka ključeva
  • proxy_cache_važeći - vrijeme pohranjivanja podataka u predmemoriji
  • proxy_pass — adresa originalnog poslužitelja od kojeg će CDN tražiti datoteke za predmemoriju. U našem primjeru, ovo sayt.in

Kao što vidite, sve je jednostavno. Poteškoće mogu nastati samo pri postavljanju vremena predmemoriranja zbog sličnosti direktiva neaktivan и proxy_cache_važeći. Analizirajmo ih na našem primjeru. Evo što se događa kada neaktivan=7d и proxy_cache_valid 90d:

  • ako se zahtjev ne ponovi unutar 7 dana, tada će podaci biti izbrisani iz predmemorije nakon tog razdoblja
  • ako se zahtjev ponavlja barem jednom svakih 7 dana, tada će se podaci u predmemoriji smatrati zastarjelima nakon 90 dana i Nginx će ih ažurirati sa sljedećim zahtjevom, preuzimajući ih s izvornog poslužitelja

Završeno uređivanje nginx.conf, ponovno učitajte konfiguraciju:

root@cdn:~# service nginx reload

Naš CDN je spreman. Za 15 USD/mj. dobili smo točke prisutnosti na tri kontinenta i 3 TB prometa: 1 TB na svakoj lokaciji.

Provjera rada CDN-a

Pogledajmo pingove prema našem CDN-u s različitih geografskih lokacija. Bilo koji ping servis će raditi za ovo.

Točka lansiranja
domaćin
IP
Prosječno vrijeme, ms

Njemačka Berlin
cdn.sayt.in
199.247.18.199
9.6

Nizozemska, Amsterdam
cdn.sayt.in
199.247.18.199
10.1

Francuska Pariz
cdn.sayt.in
199.247.18.199
16.3

Velika Britanija, London
cdn.sayt.in
199.247.18.199
14.9

Kanada, Toronto
cdn.sayt.in
149.28.121.123
16.2

SAD, San Francisco
cdn.sayt.in
149.28.121.123
52.7

SAD, Dallas
cdn.sayt.in
149.28.121.123
23.1

SAD, Chicago
cdn.sayt.in
149.28.121.123
2.6

SAD, New York
cdn.sayt.in
149.28.121.123
19.8

Singapur
cdn.sayt.in
157.230.240.216
1.7

Japan Tokio
cdn.sayt.in
157.230.240.216
74.8

Australija, Sydney
cdn.sayt.in
157.230.240.216
95.9

Rezultati su dobri. Sada ćemo postaviti testnu sliku u korijen glavne stranice test.jpg i provjerite njegovu brzinu preuzimanja putem CDN-a. Rečeno je - napravljeno. Sadržaj se isporučuje brzo.

Napišimo malu skriptu u slučaju da želimo očistiti predmemoriju na CDN točki.
čistiti.š

#!/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

Da biste izbrisali cijelu predmemoriju, samo je pokrenite, zasebna datoteka se može očistiti ovako:

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

Umjesto zaključaka

Na kraju, želim dati nekoliko korisnih savjeta kako bih odmah pregazio grablje od kojih me je tada boljela glava:

  • Kako bi se povećala tolerancija na pogreške CDN-a, preporuča se konfigurirati DNS Failover, koji pomaže u brzoj promjeni zapisa A u slučaju kvara poslužitelja. To se radi u DNS zapisima domene upravljačke ploče.
  • Stranice sa širokom geografskom pokrivenošću bez sumnje zahtijevaju veliki broj CDN-ova, ali nemojmo biti fanatični. Najvjerojatnije korisnik neće primijetiti značajnu razliku u odnosu na plaćeni CDN ako postavite poslužitelje na 6-7 lokacija: Europa, Sjeverna Amerika (istok), Sjeverna Amerika (zapad), Singapur, Australija, Hong Kong ili Japan
  • Ponekad hosteri ne dopuštaju korištenje iznajmljenih poslužitelja za potrebe CDN-a. Stoga, ako iznenada odlučite implementirati mrežu za isporuku sadržaja kao uslugu, nemojte zaboraviti unaprijed pročitati pravila određenog pružatelja usluga hostinga
  • Istražiti karta podvodnih komunikacijapredstaviti kako su kontinenti povezani i uzeti to u obzir pri izgradnji mreže za isporuku sadržaja
  • Pokušajte provjeriti pingovi s različitih mjesta na svoje poslužitelje. Na taj način možete vidjeti regije najbliže CDN točkama i ispravnije konfigurirati GeoDNS
  • Ovisno o zadacima, bit će korisno fino podesiti Nginx za specifične zahtjeve predmemoriranja i uzimajući u obzir opterećenje poslužitelja. U tome su mi puno pomogli članci o Nginx cacheu - здесь i ubrzanje rada pod velikim opterećenjem: здесь и здесь

Izvor: www.habr.com