ProHoster > Блог > Administracija > Izgradnja i konfiguracija vašeg CDN-a

Izgradnja i konfiguracija vašeg CDN-a

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

Princip rada i funkcionalnost svih mreža za isporuku sadržaja je približno isti. Nakon što je primio zahtjev za preuzimanje datoteke, CDN server je uzima jednokratno sa originalnog servera i daje korisniku, istovremeno je kešira za određeni vremenski period. Na sve naredne zahtjeve odgovara se iz keša. Svi CDN-ovi imaju opcije za prethodno učitavanje datoteka, brisanje keša, postavljanje datuma isteka i još mnogo toga.

Dešava se da iz ovog ili onog razloga trebate organizirati vlastitu mrežu za isporuku sadržaja, a onda - neka nam upute za sklapanje 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 vam je potreban sopstveni CDN

Razmotrite slučajeve u kojima pokretanje vlastitog CDN-a ima smisla:

  • kada postoji želja da se uštedi novac, a tekući troškovi čak i kada koristite jeftine CDN-ove kao što su BunnyCDN iznose nekoliko stotina dolara mjesečno
  • ako želimo da dobijemo trajni keš ili keš bez suseda servera i kanala
  • CDN servisi nemaju tačke prisustva u regiji koja vam je potrebna
  • potrebna posebna podešavanja isporuke sadržaja
  • želimo da ubrzamo isporuku dinamičkog sadržaja postavljanjem proizvodnog servera bliže korisnicima
  • postoji zabrinutost da CDN usluga treće strane može nezakonito prikupljati ili koristiti informacije o ponašanju korisnika (zdravo usluge koje nisu usklađene sa GDPR-om) ili se baviti drugim nezakonitim aktivnostima

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

Šta vam je potrebno za početak

Divno je ako imate svoj autonomni sistem (AS). Pomoću njega možete dodijeliti istu IP adresu nekoliko servera i prema ovom uputstvu na nivou mreže, usmjeriti korisnike na najbližu. Vrijedi reći da je čak i sa adresnim blokom /24 moguće izgraditi mrežu za isporuku sadržaja. Neki provajderi servera vam dozvoljavaju da objavite 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 poddomena
  • najmanje dva servera u različitim regijama. Server može biti namjenski ili virtuelni
  • geoDNS alat. Njime će korisnik, nakon što se obrati domeni, biti usmjeren na najbliži server

Registrirajte domenu i naručite servere

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

Što se tiče naručivanja servera, oni bi trebali biti iznajmljeni u regijama i zemljama u kojima se nalazi vaša korisnička publika. Ako je projekat interkontinentalni, onda je zgodno odabrati hosting provajdere koji nude servere širom svijeta odjednom. primjeri: OVH, zakup web и 100Tb - za namenske servere, Vultr и DigitalOcean — za virtuelni oblak*.

Za naš privatni CDN naručit ćemo 3 virtualna servera na različitim kontinentima. At Vultr na serveru za 5 USD/mj dobićemo 25GB SSD mjesta i 1TB saobraćaja. Prilikom instalacije odaberite najnoviji Debian. Naši serveri:

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

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

Izgradnja i konfiguracija vašeg CDN-a Сингапур, ip: 157.230.240.216

* Vultr i DigitalOcean obećavaju 100 USD kredita korisnicima koji se registruju putem linkova u članku odmah nakon dodavanja načina plaćanja. Autor od toga dobija i mali kompliment, koji je za njega sada veoma značajan. Molimo za razumijevanje.

Postavljanje geoDNS-a

Da bi korisnik bio upućen na željeni (najbliži) server prilikom pristupa domeni ili CDN poddomenu, potreban nam je DNS server sa geoDNS funkcijom.

Princip i rad geoDNS-a je sljedeći:

  1. Određuje IP klijenta koji je poslao DNS zahtjev ili IP adresu rekurzivnog DNS servera koji se koristi prilikom obrade klijentskog zahtjeva. Takvi rekurzivni serveri su obično DNS-ovi provajdera.
  2. IP klijenta prepoznaje njegovu zemlju ili region. Za to se koriste GeoIP baze podataka kojih danas ima jako puno. Ima dobrih besplatne opcije.
  3. U zavisnosti od lokacije klijenta, daje mu IP adresu najbližeg CDN servera.

DNS server sa geoDNS funkcijom može biti sami sastavite, ali je bolje koristiti gotova rješenja sa mrežom DNS servera širom svijeta i Anycast iz kutije:

  • SlouDNS iz 9.95 USD/mj, GeoDNS tarifa, podrazumevano postoji jedan DNS Failover
  • Zilore iz 25 USD/mj, DNS Failover omogućen
  • Amazon Route 53 iz 35 USD/mj za neto 50M geo-zahtjeva. DNS Failover se posebno naplaćuje
  • DNS olakšan iz 125 USD/mj, postoji 10 DNS grešaka
  • Cloudflare, "Geo Steering" funkcija je dostupna u Enterprise planovima

Prilikom naručivanja geoDNS-a obratite pažnju na broj zahtjeva koji su uključeni u tarifu i imajte na umu da stvarni broj zahtjeva na domenu može nekoliko puta premašiti očekivanja. Milioni paukova, skenera, spamera i drugih zlih duhova neumorno rade.

Gotovo sve DNS usluge uključuju nezamjenjivu uslugu za izgradnju CDN-a - DNS Failover. Uz njegovu pomoć možete podesiti praćenje rada vaših servera i, u nedostatku znakova života, automatski zamijeniti adresu neradnog servera rezervnom u DNS odgovorima.

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

Hajde da dodamo novu DNS zonu u vaš lični nalog, navodeći vašu domenu. Ako gradimo CDN na poddomenu, a glavni domen je već u upotrebi, onda odmah nakon dodavanja zone ne zaboravite da dodate postojeće radne DNS zapise. Sljedeći korak je kreiranje nekoliko A-zapisa za CDN domen/poddomen, od kojih će svaki biti primijenjen na regiju koju smo naveli. Možete odrediti kontinente ili zemlje kao regije, podregije su dostupne za SAD i Kanadu.

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

Izgradnja i konfiguracija vašeg CDN-a
Ponovimo radnju za druge regije, ne zaboravite da kreiramo jedan unos za zadane regije. Evo šta se dešava na kraju:

Izgradnja i konfiguracija vašeg CDN-a

Poslednji podrazumevani unos na snimku ekrana znači da će sve neodređene regije (a to su Evropa, Afrika, korisnici satelitskog interneta itd.) biti poslate na server u Frankfurtu.

Ovim se završava osnovno podešavanje DNS-a. Ostaje otići na web stranicu registratora domena i zamijeniti trenutne NS-ove domena onima koje je izdao ClouDNS. I dok će se NS ažurirati, mi ćemo pripremiti servere.

Instalacija SSL certifikata

Naš CDN će raditi preko HTTPS-a, pa ako već imate SSL certifikate za domenu ili poddomenu, otpremite ih na sve servere, na primjer, u direktorij /etc/ssl/yourdomain/

Ako nema certifikata, možete dobiti besplatan od Let's Encrypt. Savršeno za ovo ACME Shellscript. Klijent je zgodan i jednostavan za postavljanje, i što je najvažnije, omogućava vam da potvrdite domenu/poddomenu putem DNS-a preko ClouDNS API-ja.

Instalirat ćemo acme.sh samo na jedan od servera - evropski 199.247.18.199, sa kojeg će se certifikati kopirati na sve ostale. Za instalaciju pokrenite:

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

Tokom instalacije skripte, kreiraće se CRON posao za dalju obnovu sertifikata bez našeg učešća.

Prilikom izdavanja certifikata, domena će se provjeravati korištenjem DNS-a pomoću API-ja, tako da u ClouDNS ličnom računu u Reseller API meniju trebate kreirati novi korisnički API i postaviti lozinku za njega. Rezultirajući auth-id sa lozinkom će biti upisan u datoteku ~/.acme.sh/dnsapi/dns_cloudns.sh (ne brkati sa fajlom dns_clouddns.sh). Evo redova koje treba dekomentirati 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, za budućnost, specificirali smo naredbu za automatsko ponovno učitavanje konfiguracije web servera nakon svake obnove perioda važenja certifikata u budućnosti.

Ceo proces dobijanja sertifikata može trajati do 2 minuta, nemojte ga prekidati. Ako dođe do greške u validaciji 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, one će morati biti specificirane prilikom kopiranja certifikata na druge servere, kao iu postavkama web servera. Ne obraćamo pažnju na grešku ponovnog učitavanja Nginx konfiguracija - neće biti na potpuno konfiguriranom serveru prilikom ažuriranja certifikata.

Sve što nam preostaje za SSL je da kopiramo primljeni certifikat na dva druga servera uz zadržavanje putanje 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/

Da biste redovno ažurirali certifikate, kreirajte dnevni CRON posao na oba servera 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 Nginxa

Za posluživanje statičkog sadržaja koristit ćemo Nginx konfiguriran kao proxy server za keširanje. Ažurirajte liste paketa i instalirajte ih na sva tri servera:

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

Umjesto zadanog, 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;
    }
  }
}

Uredite u konfiguraciji:

  • max_size — veličina keš memorije koja ne prelazi raspoloživi prostor na disku
  • neaktivan - vrijeme skladištenja keširanih podataka kojima niko nije pristupio
  • ssl_certificate и ssl_certificate_key — putanje do SSL certifikata i ključeva
  • proxy_cache_valid - vrijeme skladištenja keširanih podataka
  • proxy_pass — adresa originalnog servera sa kojeg će CDN tražiti datoteke za keširanje. U našem primjeru, ovo sayt.in

Kao što vidite, sve je jednostavno. Poteškoće mogu nastati samo u postavljanju vremena keširanja zbog sličnosti direktiva neaktivan и proxy_cache_valid. Analizirajmo ih na našem primjeru. Evo šta se dešava kada neaktivan=7d и proxy_cache_valid 90d:

  • ako se zahtjev ne ponovi u roku od 7 dana, podaci će biti obrisani iz keša nakon ovog perioda
  • ako se zahtjev ponovi barem jednom svakih 7 dana, tada će se podaci u kešu smatrati zastarjelima nakon 90 dana i Nginx će ih ažurirati sljedećim zahtjevom, uzimajući ih sa originalnog servera

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

root@cdn:~# service nginx reload

Naš CDN je spreman. Za 15 USD mjesečno. dobili smo tačke prisutnosti na tri kontinenta i 3 TB saobraćaja: po 1 TB na svakoj lokaciji.

Provjera rada CDN-a

Pogledajmo pingove za naš CDN sa različitih geografskih lokacija. Bilo koja ping usluga će raditi za ovo.

Launch point
Domaćin
IP
Prosj. vrijeme, ms

Njemačka Berlin
cdn.sayt.in
199.247.18.199
9.6

Holandija, Amsterdam
cdn.sayt.in
199.247.18.199
10.1

Francuska Pariz
cdn.sayt.in
199.247.18.199
16.3

Ujedinjeno Kraljevstvo, London
cdn.sayt.in
199.247.18.199
14.9

Kanada, Toronto
cdn.sayt.in
149.28.121.123
16.2

SAD, San Francisko
cdn.sayt.in
149.28.121.123
52.7

SAD, Dallas
cdn.sayt.in
149.28.121.123
23.1

SAD, Čikago
cdn.sayt.in
149.28.121.123
2.6

SAD, Njujork
cdn.sayt.in
149.28.121.123
19.8

Сингапур
cdn.sayt.in
157.230.240.216
1.7

Japan Tokyo
cdn.sayt.in
157.230.240.216
74.8

Australija, Sidnej
cdn.sayt.in
157.230.240.216
95.9

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

Hajde da napišemo malu skriptu u slučaju da želimo da obrišemo keš na CDN tački.
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

Da izbrišete cijelu keš memoriju, samo je pokrenite, odvojena datoteka se može očistiti ovako:

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

Umesto zaključaka

Za kraj želim da dam nekoliko korisnih saveta kako bih odmah pregazio grabulje od kojih me je tada boljela glava:

  • Da biste povećali toleranciju na greške CDN-a, preporučuje se konfigurisanje DNS Failover, što pomaže da se brzo promijeni A zapis u slučaju kvara na serveru. Ovo se radi u DNS zapisima kontrolne table domene.
  • Web lokacije sa širokom geografskom pokrivenošću bez sumnje zahtijevaju veliki broj CDN-ova, ali ne budimo fanatični. Najvjerovatnije korisnik neće primijetiti značajnu razliku u odnosu na plaćeni CDN ako servere postavite na 6-7 lokacija: Evropa, Sjeverna Amerika (istok), Sjeverna Amerika (zapad), Singapur, Australija, Hong Kong ili Japan
  • Ponekad hosteri ne dozvoljavaju korištenje iznajmljenih servera u CDN svrhe. Stoga, ako se iznenada odlučite postaviti mrežu za isporuku sadržaja kao uslugu, ne zaboravite unaprijed pročitati pravila određenog hosting provajdera
  • Istražiti mapa podvodnih komunikacijapredstaviti kako su kontinenti povezani i uzeti to u obzir prilikom izgradnje mreže za isporuku sadržaja
  • Pokušajte provjeriti pingovi sa različitih mjesta na vaše servere. Na ovaj način možete vidjeti regije najbliže CDN tačkama i ispravnije konfigurirati GeoDNS
  • Ovisno o zadacima, bit će korisno fino podesiti Nginx za specifične zahtjeve keširanja i uzimajući u obzir opterećenje na serveru. U tome su mi puno pomogli članci o Nginx kešu - ovdje i ubrzanje rada pod velikim opterećenjima: ovdje и ovdje

izvor: www.habr.com