sursa imaginii: vector infografic creat de pikisuperstar — www.freepik.com

rețelele de livrare a conținutului (CDN) sunt utilizate în general de site-uri și aplicații pentru accelerarea încărcării elementelor statice. Acest lucru se realizează prin stocarea în cache a fișierelor pe serverele CDN situate în diferite regiuni ale lumii. După ce a solicitat date prin CDN, utilizatorul le primește de la cel mai apropiat server.

principiile care stau la baza CDN-urilor și funcționalitatea acestora sunt aproximativ aceleași pentru toate. După ce a primit o cerere pentru un fișier, un server CDN îl ia o dată de la serverul de origine și apoi îl transferă utilizatorului și memorează în cache o copie a acestuia pentru o perioadă de timp. Cererile suplimentare pentru date sunt tratate folosind memoria cache. Toate CDN-urile au opțiuni pentru preîncărcarea fișierelor, ștergerea cache-ului, timpii de retenție a cache-ului și multe altele.

uneori, din diverse motive, s-ar putea să se găsească nevoia de a-și construi propriul CDN și, astfel, prezentăm următorul ghid despre cum să-l realizăm.

când aveți nevoie de propriul CDN?

să aruncăm o privire la situațiile în care ar putea fi necesar să vă creați propriul CDN:

• când încercați să economisiți bani și chiar soluții accesibile precum BunnyCDN ajung să vă coste sute de dolari pe lună
• când doriți să obțineți cache permanent sau aveți nevoie de lățime de bandă și resurse garantate
• CDN-urile existente nu au Pop-uri în regiunea dvs. țintă
• aveți nevoie de setări speciale de livrare a conținutului
• livrarea conținutului dinamic prin servirea acestuia mai aproape de utilizatori
• sunteți îngrijorat CDN-urile terțe ar putea colecta și utiliza ilegal datele utilizatorului (Hei acolo, servere care nu sunt Conform GDPR) sau să se angajeze în alte activități ilicite

în majoritatea celorlalte cazuri, este mai viabilă utilizarea soluțiilor gata făcute existente.

să creăm propriul CDN

pentru a construi chiar și o rețea simplă de livrare a conținutului, aveți nevoie de următoarele:

• nume de domeniu sau un subdomeniu
• un minim de două servere în diferite regiuni. Serverele pot fi dedicate sau virtuale
• instrument geoDNS. Cu aceasta, un utilizator care trimite o solicitare către domeniu va fi direcționat către cel mai apropiat server

înregistrarea domeniului și comandarea serverelor

înregistrarea unui nume de domeniu este ușoară — înregistrați-l în orice zonă de domeniu preferați. Pentru CDN, puteți utiliza și un subdomeniu, cum ar fi cdn.domainname.com. acesta este cazul pentru următorul exemplu.

când vine vorba de servere, ar trebui să le închiriați pe cele din regiunile și țările în care se află publicul dvs. țintă. Dacă proiectul dvs. este intercontinental, este convenabil să selectați dintre furnizorii de găzduire care oferă servere din întreaga lume, cum ar fi OVH, Leaseweb și 100tb (pentru servere dedicate) sau Vultr și DigitalOcean (pentru servere virtuale și cloud).

pentru CDN-ul nostru privat, să comandăm trei servere virtuale pe diferite continente. Vultr ne oferă spațiu SSD de 25 GB și 1 TB de trafic pentru 5 USD/lună. În timpul instalării, selectați cel mai recent Debian. Aici sunt serverele noastre:

• Frankfurt, pe: 199.247.18.199

• Chicago, ip: 149.28.121.123

• Singapore, ip: 157.230.240.216

Configurarea geoDNS

pentru a ne asigura că clienții sunt direcționați către serverele corespunzătoare (cele mai apropiate) la trimiterea cererilor către domeniul sau subdomeniul nostru, vom avea nevoie de un server DNS cu funcționalitate geoDNS.

Iată cum funcționează geoDNS:

1. acesta devine IP-ul clientului (dacă au trimis cererea DNS) sau IP-ul serverului DNS recursiv care este utilizat pentru procesarea cererii. În general, astfel de servere recursive sunt de obicei DNSs ale furnizorilor de Internet.
2. prin IP-ul clientului identifică țara sau regiunea lor. Această operațiune necesită utilizarea bazei de date GeoIP, care sunt disponibile în nici o aprovizionare scurt. Există chiar și opțiuni gratuite decente.
3. în funcție de locația clientului, geoDNS îi returnează adresa IP a celui mai apropiat server CDN.

un server DNS cu funcționalitate geoDNS este ceva ce vă puteți construi, dar este mai bine să utilizați soluții gata făcute, care au servere în jurul lumii și o opțiune Anycast out-of-box:

• ClouDNS, din $ 9.95 / lună, pachet GeoDNS, un failover DNS este furnizat în mod implicit
• Zilore, de la 25 USD/lună, include failover DNS
• Amazon Route 53, de la 35 USD/lună pentru 50 de milioane de Cereri geografice. DNS Failover are un preț separat
• DNS Made Easy, de la 125 USD/lună, cu 10 DNS Failovers
• Cloudflare, funcționalitatea de direcție Geo este furnizată în pachetele Enterprise

atunci când comandați geoDNS, trebuie să acordați atenție numărului de solicitări incluse în pachet și să rețineți că numărul real de solicitări ar putea depăși cu mult așteptările dvs. Există milioane de crawlere web, scanere, spammeri și alte devilry la locul de muncă la un moment dat.

aproape toate serviciile DNS includ o caracteristică utilă pentru construirea CDN – DNS Failover. Cu aceasta, puteți configura monitorizarea activității, astfel încât, dacă un server coboară, sistemul va redirecționa automat clienții către serverele de lucru.

pentru CDN-ul nostru, să folosim ClouDNS și pachetul său GeoDNS.

în profil, adăugați o nouă zonă DNS și specificați numele domeniului. Dacă utilizați subdomeniu și domeniul principal este utilizat, nu uitați să adăugați înregistrările DNS existente imediat după adăugarea zonei. Următorul pas este crearea mai multor înregistrări A pentru domeniul/subdomeniul CDN, fiecare dintre acestea urmând să fie utilizată pentru regiunea specificată. Puteți desemna continente sau țări ca regiuni, iar opțiunile de subregiune sunt disponibile pentru SUA și Canada.

în exemplul nostru, CDN va funcționa pe cdn.sayt.in subdomeniu. După ce a adăugat sayt.in zonă, a crea primul o înregistrare pentru subdomeniu și directe toți clienții NA la serverul Chicago:

repetați acest pas pentru celelalte regiuni și nu uitați să creați o înregistrare pentru regiunile implicite. Iată cum arată rezultatul final:

ultima înregistrare implicită înseamnă cereri din toate regiunile nespecificate (Europa, Africa, utilizatorii de internet prin satelit, etc.) vor fi direcționate către serverul din Frankfurt.

aceasta încheie configurația DNS de bază. Tot ce a mai rămas este să accesați site-ul web al registratorului și să înlocuiți serverele de nume actuale cu cele furnizate de ClouDNS. În timp ce acestea sunt actualizate, vom seta serverele.

instalarea certificatelor SSL

CDN-ul nostru va funcționa folosind HTTPS, deci dacă aveți deja certificate SSL pentru domeniu sau subdomeniu, încărcați-le pe toate serverele, de exemplu, în directorul /etc/ssl/yourdomain/.

dacă nu aveți certificate, îl puteți obține gratuit de la Let ‘ s Encrypt. Acme Shell script este o opțiune excelentă. Are un client ușor de utilizat și, mai important, permite efectuarea validării domeniului/subdomeniului prin DNS folosind API de ClouDNS.

vom instala acme.sh pe un singur server-cel European (199.247.18.199), iar din acesta, certificatele vor fi copiate tuturor celorlalte. Pentru ao instala, executați următoarea comandă:

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

în timpul instalării va fi creată o sarcină CRON pentru actualizarea automată a certificatelor.

verificarea domeniului la emiterea certificatului va fi efectuată prin DNS folosind API, astfel încât în profilul ClouDNS, sub API Reseller, creați un nou utilizator API și specificați o parolă pentru acesta. Introduceți ID-ul auth rezultat împreună cu parola în următorul fișier: ~/.acme.sh/dnsapi/dns_cloudns.sh (a nu se confunda cu dns_clouddns.sh). Iată liniile de care aveți nevoie pentru a decomenta și edita:

CLOUDNS_AUTH_ID=<auth-id>CLOUDNS_AUTH_PASSWORD="<password>"

acum, să solicităm eliberarea certificatului SSL pentru cdn.spune.în

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

pentru utilizare ulterioară, în parametri, am lăsat o comandă pentru repornirea automată a configurației după fiecare reînnoire a certificatului.

procesul de obținere a certificatului poate dura până la două minute, deci nu îl întrerupeți. În cazul în care apare o eroare de validare a domeniului, încercați să rulați din nou comanda. În final, vom vedea unde au fost descărcate certificatele.

amintiți-vă aceste căi, va trebui să le specificăm atunci când copiem certificatele pe alte servere și va trebui să le specificăm în setările serverului. Ignorați eroarea de reîncărcare a configurației Nginx, — nu va apărea pe un server complet configurat în timpul reînnoirii certificatului.

în ceea ce privește certificatul SSL, tot ce am lăsat să facem este să îl copiem pe celelalte două servere care salvează căile certificatului. Creați directoare identice pe fiecare server și apoi copiați fișierele de certificat:

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/

pentru a automatiza reînnoirea certificatului, trebuie să creați o sarcină CRON zilnică pe ambele servere. Mai jos este comanda pe care ar trebui să o adăugați la joburile CRON:

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

rețineți că conexiunea la serverul de origine la distanță necesită un acces prin cheie fără a introduce o parolă. Nu uitați să o creați.

instalarea și configurarea Nginx

pentru livrarea de conținut static vom folosi Nginx, configurat ca un server proxy cache. Actualizați listele de pachete și instalați – le pe toate cele trei servere:

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

în loc de configurația implicită, utilizați cea de mai jos:

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

în config, să edităm:

• max_size — dimensiunea cache — ului care nu depășește spațiul disponibil pe disc
• inactiv — timp de retenție pentru datele cache nequested
• ssl_certificate și ssl_certificate_key — căi către certificatul SSL și cheia
• proxy_cache_valid — timp de retenție pentru datele cache
• proxy_pass-adresa serverului de origine de la care CDN va solicita date pentru cache. Pentru exemplul nostru, este sayt.in

după cum puteți vedea, nu este o știință a rachetelor. Singura dificultate este configurarea timpului de retenție, având în vedere asemănările dintre parametrii inactivi și proxy_cache_valid. Să aruncăm o privire mai atentă. Iată ce se întâmplă cu inactive = 7d și proxy_cache_valid = 90d:

• dacă cererea nu se repetă în termen de 7 zile, datele sunt șterse din memoria cache
• dacă cererea se repetă chiar și o dată în decurs de 7 zile, memoria cache va fi considerată depășită după 90 de zile, iar următoarea solicitare va face ca Nginx să o actualizeze de pe serverul de origine

cu nginx.conf manipulate, reîncărcați configurația:

root@cdn:~# service nginx reload

deci, CDN-ul nostru este gata de utilizare! Pentru $15 / lună avem Pop-uri pe trei continente și 3TB de trafic: 1TB pentru fiecare regiune.

verificarea CDN nostru

să aruncăm o privire la ping la CDN noastre din diferite locații. Orice servicii ping vor face în acest caz.

rezultatele sunt bune. Acum să plasăm o imagine de test intitulată test.jpg pe serverul principal și verificați cât de repede se încarcă prin CDN. Zis și făcut. Încărcarea este rapidă.

să facem un mic script în cazul în care trebuie să ștergem memoria cache pe un punct CDN.

purge.sh

#!/bin/bashif then echo "Purging all cache" rm -rf /var/cache/cdn/*else echo "Purging " FILE=`echo -n "" | md5sum | awk '{print }'` FULLPATH=/var/cache/cdn/${FILE:31:1}/${FILE:29:2}/${FILE} rm -f "${FULLPATH}"fi

pentru a șterge toate cache-ul de pe server, pur și simplu rulați scriptul. Dacă aveți nevoie de un fișier unele purjat, specificați doar calea sa:

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

pentru a curăța cache-ul peste tot script-ul trebuie să fie rulat pe toate serverele CDN.

în loc de concluzii

în cele din urmă, aș dori să dau câteva sfaturi utile, astfel încât să puteți evita care se încadrează în capcanele am deja eliminate:

• luați în considerare costurile de viabilitate și întreținere ale viitorului CDN. În cele mai multe cazuri, este mult mai eficient și mai ușor să cumpărați un CDN ieftin, care cel mai probabil va fi mai stabil și va fi de o calitate mai bună.
• pentru a îmbunătăți toleranța la erori a CDN, este recomandat să configurați un Failover DNS, care vă va permite să comutați rapid înregistrarea A în cazul în care un server se rupe. Puteți face acest lucru în panoul de control al înregistrărilor DNS.
• Site-urile web cu acoperire largă necesită un număr mare de POP-uri, dar nu devin excesive. Cel mai probabil, un utilizator nu va observa diferența dintre CDN-ul dvs. și unul plătit, dacă aveți servere în 6-7 locații (Europa, America de Nord (Est), America de Nord (Vest), Singapore, Australia, Hong Kong sau Japonia).
• uneori furnizorii de găzduire nu permit utilizarea serverelor închiriate pentru CDN-uri. Deci, dacă doriți să creați un serviciu CDN, asigurați-vă că citiți termenii și condițiile furnizorului de găzduire.
• studiați harta cablurilor submarine pentru a înțelege modul în care continentele sunt conectate și utilizați aceste cunoștințe atunci când vă construiți CDN-ul.
• încercați să ping serverele din diferite locații. În acest fel, puteți observa regiunile cele mai apropiate de PoP-urile dvs. și vă va ajuta să configurați GeoDNS.