🥇Crearea și configurarea CDN-ului dvs.

Rețelele de livrare de conținut (CDN) sunt utilizate în site-uri web și aplicații în primul rând pentru a accelera încărcarea elementelor statice. Acest lucru se întâmplă din cauza stocării în cache a fișierelor pe serverele CDN situate în diferite regiuni geografice. Prin solicitarea datelor prin CDN, utilizatorul le primește de la cel mai apropiat server.

Principiul de funcționare și funcționalitate a tuturor rețelelor de livrare de conținut este aproximativ același. După ce a primit o solicitare de descărcare a unui fișier, serverul CDN îl ia o singură dată de pe serverul original și îl dă utilizatorului, în același timp păstrându-l în cache pentru o anumită perioadă de timp. Toate solicitările ulterioare primesc răspuns din memoria cache. Toate CDN-urile au opțiuni pentru a preîncărca fișierele, a șterge memoria cache, a seta data de expirare și multe altele.

Se întâmplă că, dintr-un motiv sau altul, trebuie să vă organizați propria rețea de livrare a conținutului și apoi - lăsați instrucțiunile pentru asamblarea următoarei biciclete să ne fie de ajutor.

Sursa: Vector infografic creat de pikisuperstar - www.freepik.com

Când aveți nevoie de propriul dvs. CDN

Luați în considerare cazurile în care rularea propriului CDN are sens:

atunci când există dorința de a economisi bani și costuri de funcționare chiar și atunci când utilizați CDN-uri ieftine, cum ar fi BunnyCDN se ridică la câteva sute de dolari pe lună
dacă vrem să obținem un cache permanent sau un cache fără server și canal vecini
Serviciile CDN nu au puncte de prezență în regiunea de care aveți nevoie
orice setări speciale de livrare de conținut necesare
dorim să grăbim livrarea conținutului dinamic prin plasarea serverului de producție mai aproape de utilizatori
există îngrijorarea că un serviciu CDN terță parte poate colecta sau utiliza ilegal informații despre comportamentul utilizatorului (servicii neconforme cu GDPR) sau să se angajeze în alte activități ilegale

În majoritatea celorlalte cazuri, este mai potrivit să folosiți soluții gata făcute existente.

De ce ai nevoie pentru a începe

Este minunat dacă ai propriul sistem autonom (AS). Cu acesta, puteți atribui același IP mai multor servere și conform acestei instrucțiuni la nivel de rețea, direcționați utilizatorii către cel mai apropiat. Merită spus că, chiar și cu blocul de adrese /24, este posibil să construiți o rețea de livrare de conținut. Unii furnizori de servere vă permit să faceți un anunț pentru utilizare în toate regiunile disponibile pentru ei.

Dacă nu sunteți un proprietar fericit al unui bloc de adrese IP, atunci pentru a rula un simplu CDN veți avea nevoie de:

nume de domeniu sau subdomeniu
cel puțin două servere în regiuni diferite. Serverul poate fi fie dedicat, fie virtual
instrument geoDNS. Cu acesta, utilizatorul, după ce s-a adresat domeniului, va fi direcționat către cel mai apropiat server

Înregistrați un domeniu și comandați servere

Cu înregistrarea unui domeniu, totul este simplu - ne înregistrăm în orice zonă cu orice registrator. De asemenea, puteți utiliza un subdomeniu pentru un CDN, de exemplu ceva de genul cdn.domainname.com. De fapt, în exemplul nostru, vom face exact asta.

În ceea ce privește comandarea serverelor, acestea ar trebui să fie închiriate în regiunile și țările în care se află publicul dvs. de utilizatori. Dacă proiectul este intercontinental, atunci este convenabil să alegeți furnizorii de găzduire care oferă servere în întreaga lume simultan. Exemple: OVH, închiriere web и 100Tb - pentru servere dedicate, Vultr и DigitalOcean — pentru cloud virtual*.

Pentru CDN-ul nostru privat, vom comanda 3 servere virtuale pe diferite continente. La Vultr pe server pentru 5 USD/lună vom primi 25GB SSD locuri şi 1TB de trafic. Când instalați, selectați cel mai recent Debian. Serverele noastre:

Frankfurt, ip: 199.247.18.199

Chicago, ip: 149.28.121.123

Singapur, ip: 157.230.240.216

* Vultr și DigitalOcean promit credit de 100 USD utilizatorilor care se înregistrează prin linkurile din articol imediat după adăugarea unei metode de plată. Autorul primește și un mic compliment din aceasta, care este foarte semnificativ pentru el acum. Vă rog să fiți înțelegător.

Configurarea geoDNS

Pentru ca utilizatorul să fie direcționat către serverul dorit (cel mai apropiat) atunci când accesează un domeniu sau subdomeniu CDN, avem nevoie de un server DNS cu funcția geoDNS.

Principiul și funcționarea geoDNS este după cum urmează:

Specifică IP-ul clientului care a trimis cererea DNS sau IP-ul serverului DNS recursiv care este utilizat la procesarea cererii client. Astfel de servere recursive sunt de obicei DNS-uri ale furnizorilor.
IP-ul clientului îi recunoaște țara sau regiunea. Pentru aceasta se folosesc bazele de date GeoIP, dintre care există foarte multe astăzi. Sunt bune opțiuni gratuite.
În funcție de locația clientului, îi dă adresa IP a celui mai apropiat server CDN.

Serverul DNS cu funcție geoDNS poate fi asamblați singur, dar este mai bine să folosiți soluții gata făcute cu o rețea de servere DNS din întreaga lume și Anycast din cutie:

CloudDNS din 9.95 USD/lună, tarif GeoDNS, în mod implicit există un DNS Failover
Zilore din 25 USD/lună, DNS Failover este activat
Ruta Amazonului 53 din 35 USD/lună pentru o netă de 50 de milioane de solicitări geografice. DNS Failover este facturat separat
DNS ușor din 125 USD/lună, există 10 erori DNS
Cloudflare, Caracteristica „Geo Steering” este disponibilă în planurile Enterprise

Atunci când comandați geoDNS, ar trebui să fiți atenți la numărul de solicitări incluse în tarif și să rețineți că numărul real de solicitări către domeniu poate depăși așteptările de câteva ori. Milioane de păianjeni, scanere, spammeri și alte spirite rele lucrează neobosit.

Aproape toate serviciile DNS includ un serviciu indispensabil pentru construirea unui CDN - DNS Failover. Cu ajutorul acestuia, puteți configura monitorizarea funcționării serverelor dvs. și, în absența semnelor de viață, puteți înlocui automat adresa unui server care nu funcționează cu unul de rezervă în răspunsurile DNS.

Pentru a construi CDN-ul nostru, vom folosi CloudDNS, tarif GeoDNS.

Să adăugăm o nouă zonă DNS în contul tău personal, specificând domeniul tău. Dacă construim un CDN pe un subdomeniu și domeniul principal este deja în uz, atunci imediat după adăugarea zonei, nu uitați să adăugați înregistrările DNS existente. Următorul pas este crearea mai multor înregistrări A pentru domeniul/subdomeniul CDN, fiecare dintre ele va fi aplicată regiunii pe care am specificat-o. Puteți specifica continente sau țări ca regiuni, subregiuni sunt disponibile pentru SUA și Canada.

În cazul nostru, CDN-ul va fi ridicat pe un subdomeniu cdn.sayt.in. Prin adăugarea unei zone sayt.in, creați prima înregistrare A pentru subdomeniu și direcționați toată America de Nord către serverul din Chicago:

Să repetăm acțiunea pentru alte regiuni, amintindu-ne să creăm o singură intrare pentru regiunile implicite. Iată ce se întâmplă până la urmă:

Ultima intrare implicită din captură de ecran înseamnă că toate regiunile nespecificate (și acestea sunt Europa, Africa, utilizatorii de internet prin satelit etc.) vor fi trimise la serverul din Frankfurt.

Aceasta completează configurarea de bază a DNS. Rămâne să mergeți pe site-ul web al registratorului de domenii și să înlocuiți actualele NS de domeniu cu cele emise de ClouDNS. Și în timp ce NS-urile vor fi actualizate, vom pregăti serverele.

Instalarea certificatelor SSL

CDN-ul nostru va funcționa prin HTTPS, așa că dacă aveți deja certificate SSL pentru un domeniu sau subdomeniu, încărcați-le pe toate serverele, de exemplu, în director /etc/ssl/domeniul tău/

Dacă nu există certificate, puteți obține unul gratuit de la Let's Encrypt. Perfect pentru asta ACME Shellscript. Clientul este convenabil și ușor de configurat și, cel mai important, vă permite să validați un domeniu/subdomeniu prin DNS prin intermediul API-ului ClouDNS.

Vom instala acme.sh doar pe unul dintre servere - European 199.247.18.199, de pe care certificatele vor fi copiate pe toate celelalte. Pentru a instala, rulați:

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

În timpul instalării scriptului, va fi creat un job CRON pentru reînnoirea ulterioară a certificatelor fără participarea noastră.

La emiterea unui certificat, domeniul va fi verificat folosind DNS folosind API-ul, așa că în contul personal ClouDNS din meniul Reseller API, trebuie să creați un nou API de utilizator și să setați o parolă pentru acesta. ID-ul de autentificare rezultat cu o parolă va fi scris în fișier ~/.acme.sh/dnsapi/dns_cloudns.sh (a nu se confunda cu file dns_clouddns.sh). Iată rândurile care trebuie decomentate și editate:

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

Acum vom solicita un certificat SSL pentru cdn.sayt.in

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

În opțiuni, pentru viitor, am specificat o comandă pentru a reîncărca automat configurația serverului web după fiecare reînnoire a perioadei de valabilitate a certificatului în viitor.

Întregul proces de obținere a unui certificat poate dura până la 2 minute, nu îl întrerupeți. Dacă apare o eroare de validare a domeniului, încercați să rulați din nou comanda. La final vom vedea unde au fost încărcate certificatele:

Rețineți că aceste căi, vor trebui specificate atunci când copiați certificatul pe alte servere, precum și în setările serverului web. Nu acordăm atenție erorii de reîncărcare a configurațiilor Nginx - nu va fi pe un server complet configurat la actualizarea certificatelor.

Tot ce ne rămâne pentru SSL este să copiem certificatul primit pe alte două servere, menținând în același timp calea către fișiere. Să creăm aceleași directoare pe fiecare dintre ele și să facem o copie:

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 actualiza certificatele în mod regulat, creați un job CRON zilnic pe ambele servere cu comanda:

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

În acest caz, accesul la serverul sursă de la distanță trebuie configurat prin cheie, adică fără a introduce o parolă. Nu uita să o faci.

Instalarea și configurarea Nginx

Pentru a servi conținut static, vom folosi Nginx configurat ca server proxy de cache. Actualizați listele de pachete și instalați-le pe toate cele trei servere:

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

În loc de implicit, folosim configurația din spoilerul 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;
    }
  }
}

Editați în configurație:

dimensiune_max — dimensiunea memoriei cache, care nu depășește spațiul disponibil pe disc
inactiv - timpul de stocare a datelor din cache pe care nimeni nu le-a accesat
certificat_ssl и cheie_certificat_ssl — căi către certificatul SSL și fișierele cheie
proxy_cache_valid - timpul de stocare a datelor din cache
proxy_pass — adresa serverului original de la care CDN-ul va solicita fișiere pentru stocare în cache. În exemplul nostru, aceasta sayt.in

După cum puteți vedea, totul este simplu. Dificultatea poate apărea doar în setarea timpului de stocare în cache din cauza asemănării directivelor inactiv и proxy_cache_valid. Să le analizăm cu exemplul nostru. Iată ce se întâmplă când inactiv=7d и proxy_cache_valid 90d:

dacă cererea nu se repetă în 7 zile, atunci datele vor fi șterse din cache după această perioadă
dacă cererea se repetă cel puțin o dată la 7 zile, atunci datele din cache vor fi considerate învechite după 90 de zile și Nginx o va actualiza cu următoarea solicitare, preluând-o de pe serverul original

S-a terminat de editat nginx.conf, reîncărcați configurația:

root@cdn:~# service nginx reload

CDN-ul nostru este gata. Pentru 15 USD/lună. am primit puncte de prezență pe trei continente și 3 TB de trafic: 1 TB în fiecare locație.

Verificarea activității CDN

Să ne uităm la ping-urile către CDN-ul nostru din diferite locații geografice. Orice serviciu ping va funcționa pentru asta.

Punctul de lansare
Gazdă
IP
Timp mediu, ms

Germania Berlin
cdn.sayt.in
199.247.18.199
9.6

Olanda, Amsterdam
cdn.sayt.in
199.247.18.199
10.1

Franța Paris
cdn.sayt.in
199.247.18.199
16.3

Marea Britanie, Londra
cdn.sayt.in
199.247.18.199
14.9

Canada, Toronto
cdn.sayt.in
149.28.121.123
16.2

SUA, San Francisco
cdn.sayt.in
149.28.121.123
52.7

SUA, Dallas
cdn.sayt.in
149.28.121.123
23.1

SUA, Chicago
cdn.sayt.in
149.28.121.123
2.6

SUA, New York
cdn.sayt.in
149.28.121.123
19.8

Singapur
cdn.sayt.in
157.230.240.216
1.7

Japonia Tokyo
cdn.sayt.in
157.230.240.216
74.8

Australia, Sydney
cdn.sayt.in
157.230.240.216
95.9

Rezultatele sunt bune. Acum vom plasa o imagine de test în rădăcina site-ului principal test.jpg și verificați viteza de descărcare prin CDN. Se spune - Terminat. Conținutul este livrat rapid.

Să scriem un mic script în cazul în care dorim să ștergem memoria cache de pe punctul CDN.
epurare.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

Pentru a șterge întregul cache, rulați-l, un fișier separat poate fi curățat astfel:

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

În loc de concluzii

În sfârșit, vreau să dau câteva sfaturi utile pentru a trece imediat peste grebla care m-a durut capul la momentul respectiv:

Pentru a crește toleranța la erori a CDN-ului, se recomandă configurarea DNS Failover, care ajută la schimbarea rapidă a înregistrării A în cazul unei defecțiuni a serverului. Acest lucru se face în înregistrările DNS ale panoului de control ale domeniului.
Site-urile cu acoperire geografică largă necesită fără îndoială un număr mare de CDN-uri, dar să nu fim fanatici. Cel mai probabil, utilizatorul nu va observa o diferență semnificativă față de un CDN plătit dacă plasați servere în 6-7 locații: Europa, America de Nord (est), America de Nord (vest), Singapore, Australia, Hong Kong sau Japonia
Uneori, hosterii nu permit utilizarea serverelor închiriate în scopuri CDN. Prin urmare, dacă decideți brusc să implementați o rețea de livrare de conținut ca serviciu, nu uitați să citiți în prealabil regulile unui anumit furnizor de găzduire.
Explora hartă de comunicații subacvaticesă reprezinte modul în care sunt conectate continentele și să țină cont de acest lucru atunci când construiești o rețea de livrare a conținutului
Încercați să verificați ping din diferite locuri către serverele dvs. În acest fel, puteți vedea regiunile cele mai apropiate de punctele CDN și puteți configura GeoDNS mai corect
În funcție de sarcini, va fi util să reglați Nginx pentru cerințele specifice de cache și luând în considerare încărcarea de pe server. Articolele despre Nginx cache m-au ajutat foarte mult în acest sens - aici și accelerarea lucrului sub sarcini grele: aici и aici

Sursa: www.habr.com

Construirea și configurarea CDN-ului dvs