ProHoster > Blog > Administracija > Sestavljamo in nastavljamo svoj CDN

Sestavljamo in nastavljamo svoj CDN

Omrežni sistemi za dostavo vsebin (CDN) se uporabljajo na spletnih straneh in v aplikacijah predvsem za pospeševanje nalaganja statičnih elementov. Do tega pride z uporabo predpomnjenja datotek na strežnikih CDN, ki so razporejeni v različnih geografskih regijah. Ko uporabnik zahteva podatke preko CDN, jih prejme s najbližjega strežnika.

Načelo delovanja in funkcionalnost vseh omrežij za dostavo vsebin je približno enaka. Ko CDN strežnik prejme zahtevo za nalaganje datoteke, jo enkratno prenese z izvornega strežnika in posreduje uporabniku, obenem pa jo predpomni za določen čas. Na vse naslednje zahteve se odgovori iz predpomnilnika. Vsa CDN omrežja ponujajo možnosti prednalaganja datotek, čiščenja predpomnilnika, nastavitve časa shranjevanja in še mnogo več.

Včasih je potrebno iz različnih razlogov organizirati lastno omrežje za dostavo vsebin, in takrat — naj bo to navodilo za sestavljanje naslednjega kolesa.

Sestavljamo in nastavljamo svoj CDN
Izvor: Infografika vektorskega tipa, ki jo je ustvaril pikisuperstar — www.freepik.com

Kdaj potrebujemo lasten CDN

Oglejmo si primere, ko ima zagon lastnega CDN smisel:

  • ko želimo prihraniti, trenutni stroški pa tudi pri uporabi poceni CDN-jev, kot je BunnyCDN znašajo več sto dolarjev na mesec
  • če želimo imeti stalno predpomnilnik ali predpomnilnik brez sosedov po strežniku in kanalu
  • v regiji, ki vas zanima, nimajo CDN storitve prisotnosti
  • potrebne so kakšne posebne nastavitve za dostavo vsebin
  • želimo pospešiti dostavo dinamičnih vsebin, tako da bomo proizvodne strežnike postavili bližje uporabnikom
  • če se bojimo, da bi lahko zunanje CDN storitve nezakonito zbirale ali uporabljale informacije o obnašanju uporabnikov (pozdrav storitvam brez skladnosti z GDPR) ali se ukvarjale z drugimi nezakonitimi dejanji

V večini drugih primerov je smiselneje uporabiti obstoječe rešitev.

Kaj potrebujemo za zagon

Odlično je, če imate svoj neodvisni sistem (AS). S tem lahko dodelite enak IP več strežnikom in po tem navodilu na ravni omrežja usmerite uporabnike k najbližjemu. Treba je omeniti, da lahko tudi s blokom naslovov /24 zgradite omrežje za dostavo vsebin. Nekateri ponudniki strežnikov omogočajo napoved za uporabo v vseh regijah, ki so jim na voljo.

Če niste srečen lastnik bloka IP naslovov, boste za zagon preprostega CDN potrebovali:

  • domena ali poddomena
  • vsaj dva strežnika v različnih regijah. Strežnik je lahko bodisi fizični bodisi virtualni
  • geoDNS orodje. S tem orodjem bo uporabnik, ko bo dostopal do domene, preusmerjen na najbližji strežnik

Registriramo domeno in naročimo strežnike

Z registracijo domene je vse preprosto – registrirate lahko v kateri koli coni pri katerem koli registrarju. Prav tako lahko za CDN uporabite poddomeno, na primer nekaj takega kot cdn.imedomena.com. V našem primeru bomo tako tudi storili.

Kar se tiče naročanja strežnikov – ti naj bodo na voljo v regijah in državah, kjer se nahaja vaša ciljna publika. Če je projekt medcelinski, je priročno izbrati ponudnike gostovanja, ki nudijo strežnike po vsem svetu. Primeri: OVH, Leaseweb in 100Tb — za fizične strežnike, Vultr in DigitalOcean — za virtualne oblačne*.

Za naš zasebni CDN bomo naročili 3 virtualne strežnike na različnih celinah. Na Vultr strežniku za $5/mesec bomo pridobili 25GB SSD prostora in 1TB prometa. Pri namestitvi izberemo najnovejši Debian. Naši strežniki:

Sestavljamo in nastavljamo svoj CDN Frankfurt, ip: 199.247.18.199

Sestavljamo in nastavljamo svoj CDN Chicago, ip: 149.28.121.123

Sestavljamo in nastavljamo svoj CDN Singapur, ip: 157.230.240.216

* Vultr in DigitalOcean obljubljata $100 kredita uporabnikom, ki se registrirajo prek povezav v članku, takoj po dodajanju načina plačila. Avtor prav tako prejme majhen kompliment, kar mu je trenutno zelo pomembno. Prosimo, obravnavajte to razumevajoče.

Nastavitev geoDNS

Da uporabnik ob dostopu do domene ali poddomene CDN preusmeri na pravilen (najbližji) strežnik, potrebujemo DNS strežnik s funkcijo geoDNS.

Načelo in postopek delovanja geoDNS je naslednji:

  1. Določi IP stranke, ki je poslala DNS poizvedbo, ali IP rekurzivnega DNS strežnika, ki se uporablja pri obdelavi zahtevka stranke. Takšni rekurzivni strežniki so običajno DNS-i ponudnikov.
  2. Po IP stranke izve, v kateri državi ali regiji se nahaja. Za to se uporabljajo baze GeoIP, katerih je danes izjemno veliko. Obstajajo dobri brezplačni modeli.
  3. Odvisno od lokacije stranke mu posreduje IP naslov najbližjega CDN strežnika.

DNS strežnik s funkcijo geoDNS lahko zgradite sami, boljše pa je uporabiti že pripravljene rešitve z omrežjem DNS strežnikov po celem svetu in Anycast iz škatle:

  • SclouDNS od $9.95/mesec, tarifni paket GeoDNS, privzeto vključuje en DNS Failover
  • Zilore od $25/mesec, vključuje DNS Failover
  • Amazon Route 53 od $35/mesec za čistih 50M geo-poizvedb. DNS Failover se obračunava ločeno
  • DNS Made Easy od $125/mesec, vsebuje 10 DNS Failover
  • Cloudflare, funkcija „Geo Steering“ je na voljo v Enterprise tarifah

Pri naročilu geoDNS je treba biti pozoren na število poizvedb, vključenih v tarifo, in upoštevati, da lahko dejansko število poizvedb na domeno bistveno preseže pričakovanja. Milijoni pajkov, skenerjev, spammerjev in drugih nezaželenih obiskovalcev delujejo neprekinjeno.

Pri večini DNS storitev je cena vključuje nepogrešljivo storitev za postavitev CDN — DNS Failover. S to funkcijo lahko nastavite spremljanje delovanja svojih strežnikov in v primeru, da ne zaznate znakov življenja, avtomatsko zamenjate v DNS odgovorih naslov nedelujočega strežnika z rezervnim.

Za postavitev našega CDN bomo uporabili ClouDNS, tarifni načrt GeoDNS.

V osebni kabini dodamo novo DNS cono, kjer navedemo svojo domeno. Če bomo CDN postavljali na poddomeni, glavna domena pa je že v uporabi, potem takoj po dodajanju cone ne pozabite dodati obstoječih delujočih DNS zapisov. Naslednji korak je ustvarjanje več A zapisov za CDN domeno/poddomeno, kjer bo vsak uporabljen za določeno regijo. Kot regije lahko navedemo celine ali države, za ZDA in Kanado so na voljo subregije.

V našem primeru bo CDN postavljen na poddomeni cdn.sayt.in. Dodali bomo cono sayt.in, ustvarili bomo prvi A zapis za poddomeno in usmerili celotno Severno Ameriko na strežnik v Chicagu:

Sestavljamo in nastavljamo svoj CDN
Ponovimo postopek za druge regije, ne pozabite ustvariti enega zapisa za privzete regije. Tako bo končni rezultat:

Sestavljamo in nastavljamo svoj CDN

Zadnji privzeti zapis na posnetku pomeni, da bodo vse neodgovorjene regije (Evropa, Afrika, uporabniki satelitskega interneta itd.) usmerjene na strežnik v Frankfurtu.

To je osnovna nastavitev DNS končana. Ostaja le, da obiščete spletno mesto registrarja domene in zamenjate trenutne NS zapise domene z tistimi, ki jih je izdal ClouDNS. Medtem ko se NS zapisi posodabljajo, bomo pripravili strežnike.

Namestitev SSL certifikatov

Naš CDN bo deloval prek HTTPS, zato, če že imate SSL certifikate za domeno ali poddomeno, — jih naložite na vse strežnike, na primer v imenik /etc/ssl/вашдомен/

Če certifikatov ni, lahko pridobite brezplačnega pri Let’s Encrypt. Za to je odlično primeren ACME Shell script. Klient je enostaven za nastavitev in kar je najpomembneje — omogoča validacijo domene/subdomena preko DNS prek API iz ClouDNS.

Acme.sh bomo namestili le na enem strežniku — evropskem 199.247.18.199, s katerega se bodo certifikati kopirali na vse ostale. Za namestitev izvedite:

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

Med namestitvijo skripti bo ustvarjeno CRON opravilo za nadaljnje posodabljanje certifikatov brez našega posredovanja.

Preverjanje domene ob izdaji certifikata bo potekalo po DNS z uporabo API, zato je v osebnem računu ClouDNS v meniju Reseller API potrebno ustvariti novega API uporabnika in dodeliti geslo. Pridobljen auth-id z geslom bomo zapisali v datoteko ~/.acme.sh/dnsapi/dns_cloudns.sh (ne zamenjujte z datoteko dns_clouddns.sh). Tukaj so vrstice, ki jih je treba razkomentirati in urediti:

CLOUDNS_AUTH_ID=
CLOUDNS_AUTH_PASSWORD=""

Zdaj zaprosimo za pridobitev SSL certifikata za cdn.sayt.in

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

V parametrih smo za bodočnost navedli ukaz za samodejno ponovno nalaganje konfiguracije spletnega strežnika po vsakem posodobitvi roka veljavnosti certifikata.

Celoten postopek pridobivanja certifikata lahko traja do 2 minuti, ne prekinjajte ga. Če pride do napake pri validaciji domene, poskusite ukaz ponovno zagnati. Na koncu bomo videli, kam so bili naloženi certifikati:

Sestavljamo in nastavljamo svoj CDN

Zapomnimo si te poti, te je treba navesti pri kopiranju certifikata na druge strežnike, pa tudi v nastavitvah spletnega strežnika. Na napake pri ponovnem nalaganju Nginx konfiguracij ne smemo posvečati pozornosti, — na v celoti nastavljenem strežniku pri posodobitvi certifikatov te ne bo.

Vse, kar nam je še ostalo glede SSL, — je kopirati pridobljen certifikat na dva druga strežnika ob ohranjanju poti do datotek. Na vsakem od njih ustvarimo enake imenike in naredimo kopijo:

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/

Da bodo posodobitve certifikatov redne, bomo na obeh strežnikih ustvarili dnevno CRON opravilo z ukazom:

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

Pri tem mora biti dostop do oddaljenega strežnika-vir nastavljen po ključi, torej brez vnosa gesla. Ne pozabite to narediti.

Namestitev in nastavitev Nginx

Za dostavo statičkog sadržaja koristit ćemo Nginx, konfiguriran u načinu keširajućeg proxy poslužitelja. Ažurirat ćemo liste paketa i instalirati ga na sva tri poslužitelja:

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

Umjesto zadane, koristit ćemo konfiguraciju iz niže navedene špice:
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;
    }
  }
}

U konfiguraciji ćemo urediti:

  • max_size — veličina keša koja ne smije prelaziti dostupno mjesto na disku
  • inactive — vrijeme čuvanja keširanih podataka kojima se nitko ne obraća
  • ssl_certificate in ssl_certificate_key — putanje do datoteka SSL certifikata i ključa
  • proxy_cache_valid — vrijeme čuvanja keširanih podataka
  • proxy_pass — adresa originalnog poslužitelja s kojeg će CDN tražiti datoteke za keširanje. U našem primjeru to je sayt.in

Kao što vidimo, sve je jednostavno. Teškoće bi mogle nastati samo u konfiguriranju vremena keširanja zbog sličnosti direktiva inactive in proxy_cache_valid. Razmotrit ćemo ih na našem primjeru. Evo što se događa kada inactive=7d in proxy_cache_valid 90d:

  • ako se zahtjev ne ponovi u roku od 7 dana, podaci će se izbrisati iz keša nakon tog razdoblja
  • ako se zahtjev ponavlja barem jednom u 7 dana, podaci u kešu će se smatrati zastarjelima nakon 90 dana i pri sljedećem zahtjevu Nginx će ih ažurirati, preuzimajući ih s originalnog poslužitelja

Završivši uređivanje nginx.conf, ponovo ćemo učitati konfiguraciju:

root@cdn:~# service nginx reload

Naš CDN je potpuno spreman. Za $15/mj. dobili smo prisutnosti na tri kontinenta i 3 TB prometa: po 1 TB na svakoj lokaciji.

Provjeravamo rad CDN-a

Pogledajmo pingove našeg CDN-a iz različitih geografski lokacija. Bilo koji ping servisi će poslužiti.

Pokretna točka
Strežnik
IP
Prosječno vrijeme, msec

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

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

ZDA, New York
cdn.sayt.in
149.28.121.123
19.8

Singapur
cdn.sayt.in
157.230.240.216
1.7

Japonska, Tokio
cdn.sayt.in
157.230.240.216
74.8

Avstralija, Sydney
cdn.sayt.in
157.230.240.216
95.9

Rezultati so dobri. Zdaj bomo naložili testno sliko v koren glavnega spletnega mesta test.jpg in preverili hitrost nalaganja preko CDN. Rekli smo, — narejeno. Vsebina se hitro predaja.

Napišemo majhen skript za primer, če želimo očistiti predpomnilnik na CDN toč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

Za odstranitev celotnega predpomnilnika je dovolj, da ga preprosto zaženete, posamezno datoteko pa lahko očistite tako:

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

Namesto zaključkov

Na koncu želim dati nekaj koristnih nasvetov, da se takoj izognemo težavam, ki so mi nekoč povzročile glavobol:

  • Za povečanje odpornosti CDN se priporoča nastavitev DNS Failover, ki hitro spremeni A zapis v primeru okvare strežnika. To se delo v nadzorni plošči DNS zapisov domene
  • Spletna mesta z široko geografsko pokritostjo zagotovo potrebujejo veliko število CDN točk, vendar brez fanatizma. Verjetno uporabnik ne bo opazil bistvene razlike v primerjavi z plačanim CDN, če postavite strežnike na 6-7 mestih: Evropa, Severna Amerika (vzhod), Severna Amerika (zahod), Singapur, Avstralija, Hongkong ali Japonska
  • Včasih gostitelji ne dovolijo uporabe najetih strežnikov za CDN namene. Zato, če se odločite vzpostaviti omrežje za dostavo vsebine kot storitev, ne pozabite vnaprej prebrati pravil konkretnega gostiteljskega ponudnika
  • Preučite zemljevid podvodnih komunikacij, da bi razumeli, kako so povezani kontinenti in to upoštevali pri gradnji omrežja za dostavo vsebine
  • Poskusite preveriti ping iz različnih mest do vaših strežnikov. Tako lahko vidite najbližje regije do CDN točk in pravilno nastavite GeoDNS
  • Glede na naloge ni odveč, da dodatno nastavite Nginx po specifičnih zahtevah predpomnilnika in obremenitvi strežnika. V tem so mi zelo pomagali članki o predpomnjenju Nginx — ovde in pospeševanju delovanja pri velikih obremenitvah: ovde in ovde

Izvor: habr.com

Kupite zanesljivo gostovanje za spletne strani z zaščito pred DDoS, VPS VDS strežniki 🔥 Kupite zanesljivo gostovanje za spletne strani z zaščito pred DDoS, VPS VDS strežniki | ProHoster