ProHoster > Blog > Administrare > Configurăm și setăm CDN-ul nostru

Configurăm și setăm CDN-ul nostru

Rețelele de livrare a conținutului (CDN) sunt utilizate pe site-uri și în aplicații în principal pentru a accelera încărcarea elementelor statice. Aceasta se face prin caching-ul fișierelor pe serverele CDN, situate în diferite regiuni geografice. Atunci când utilizatorul solicită date prin intermediul CDN, el le primește de la serverul cel mai apropiat.

Principiul de funcționare și funcționalitatea tuturor rețelelor de livrare a conținutului sunt aproximativ aceleași. După ce primește o solicitare pentru încărcarea unui fișier, serverul CDN îl preia o singură dată de pe serverul original și îl furnizează utilizatorului, în timp ce îl cachează pe o perioadă specificată de timp. La toate cererile ulterioare, răspunsul este livrat din cache. Toate CDN-urile au opțiuni pentru preîncărcarea fișierelor, curățarea cache-ului, configurarea duratei acestuia și multe altele.

Se poate întâmpla ca din diverse motive să fie necesar să organizăm o rețea proprie de livrare a conținutului, și atunci — vor fi de ajutor instrucțiunile pentru asamblarea unei noi rețele.

Configurăm și setăm CDN-ul nostru
Sursa: Infographic vector created by pikisuperstar — www.freepik.com

Când ai nevoie de un CDN propriu

Să analizăm cazurile în care lansarea unui CDN propriu are sens:

  • când există dorința de a economisi, iar cheltuielile curente chiar și atunci când se utilizează CDN-uri ieftine, precum BunnyCDN se ridică la câteva sute de dolari pe lună
  • dacă dorim un cache constant sau un cache fără vecini în server și canal
  • în regiunea dorită, serviciile CDN nu au puncte de prezență
  • sunt necesare anumite configurații speciale pentru livrarea conținutului
  • dorim să accelerăm livrarea conținutului dinamic, plasând serverele de producție mai aproape de utilizatori
  • există temeri că un serviciu CDN terț ar putea colecta sau folosi fără drept informații despre comportamentul utilizatorilor (salut serviciilor fără GDPR-compliant) sau să comită alte acțiuni necorespunzătoare

În majoritatea celorlalte cazuri, este mai rațional să folosim soluții existente gata pregătite.

Ce este necesar pentru lansare

Ar fi minunat dacă ai avea un sistem autonom (AS) propriu. Cu acesta, poți aloca aceeași adresă IP mai multor servere și conform acestei instrucțiuni la nivel de rețea să direcționezi utilizatorii către cel mai apropiat. Merită menționat că chiar și cu un bloc de adrese /24 există posibilitatea de a construi o rețea de livrare a conținutului. Anumiți furnizori de servere permit anunțarea pentru utilizare în toate regiunile disponibile.

Dacă nu sunteți fericitul posesor al unui bloc de adrese IP, atunci pentru a lansa un CDN simplu, aveți nevoie de:

  • un nume de domeniu sau subdomeniu
  • minimum două servere în regiuni diferite. Serverul poate fi fie dedicat, fie virtual
  • un instrument geoDNS. Cu ajutorul său, utilizatorul, solicitând domeniul, va fi direcționat către cel mai apropiat server

Înregistrăm domeniul și comandăm serverele

Înregistrarea domeniului este simplă — îl înregistrăm în orice zonă la orice registrar. De asemenea, pentru CDN se poate folosi un subdomeniu, de exemplu ceva de genul cdn.nume-domeniu.com. Practic, în exemplul nostru, așa vom proceda.

În ceea ce privește comanda serverelor — este bine să le închiriați în regiunile și țările unde se află publicul dumneavoastră țintă. Dacă proiectul este internațional, este convenabil să alegeți furnizori de hosting care oferă servere la nivel mondial. Exemple: OVH, Leaseweb și 100Tb — pentru servere dedicate, Vultr și DigitalOcean — pentru cele virtuale cloud*.

Pentru CDN-ul nostru privat vom comanda 3 servere virtuale în continente diferite. La Vultr serverul nostru pentru $5/lună vom obține 25GB SSD spațiu și 1TB trafic. La instalare, vom alege cea mai recentă versiune de Debian. Serverele noastre:

Configurăm și setăm CDN-ul nostru Frankfurt, ip: 199.247.18.199

Configurăm și setăm CDN-ul nostru Chicago, ip: 149.28.121.123

Configurăm și setăm CDN-ul nostru Singapore, ip: 157.230.240.216

* Vultr și DigitalOcean oferă 100$ credit utilizatorilor înscriși prin linkurile din articol, imediat după adăugarea metodei de plată. Autorul primește, de asemenea, un mic compliment din partea acestora, ceea ce înseamnă foarte mult pentru el. Vă rugăm să înțelegeți.

Configurăm geoDNS

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

Principiul și modul de funcționare al geoDNS sunt următoarele:

  1. Determină IP-ul clientului care a trimis cererea DNS, sau IP-ul serverului DNS recursiv care este folosit pentru a procesa cererea clientului. Aceste servere recursiv sunt de obicei DNS-urile furnizorilor.
  2. Pe baza IP-ului clientului, află țara sau regiunea acestuia. Pentru aceasta se folosesc baze de date GeoIP, care sunt extrem de numeroase în zilele noastre. Există opțiuni gratuitate destul de bune.
  3. În funcție de locația clientului, îi dă IP-ul celui mai apropiat server CDN.

Un server DNS cu funcția geoDNS se poate fi construit de sine stătător, 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:

  • ClouDNS de la $9.95/lună, tariff GeoDNS, are în mod default un DNS Failover
  • Zilore de la $25/lună, include DNS Failover
  • Amazon Route 53 de la $35/lună pentru 50M de cereri geo. DNS Failover se taxează separat
  • DNS Made Easy de la $125/lună, include 10 DNS Failover
  • Cloudflare, funcția „Geo Steering” este disponibilă în tarifele Enterprise

Atunci când comandați geoDNS, este important să luați în considerare numărul de cereri incluse în tarif și să fiți conștienți că numărul real de solicitări la domeniu poate depăși așteptările de câteva ori. Milioane de roboți, scanere, spammeri și alte entități nenorocite lucrează neobosit.

Practically toate serviciile DNS includ în prețul lor un serviciu esențial pentru construirea CDN-urilor - DNS Failover. Cu ajutorul acestuia, puteți configura monitorizarea funcționării serverelor dvs. și, în cazul absenței semnelor de viață, să înlocuiți automat în răspunsurile DNS adresa serverului nefuncțional cu un server de rezervă.

Pentru a construi CDN-ul nostru, vom folosi ClouDNS, tariful GeoDNS.

Vom adăuga în contul personal o nouă zonă DNS, specificând domeniul nostru. Dacă construim CDN-ul pe un subdomeniu, iar domeniul principal deja este utilizat, nu uitați să adăugați înregistrările DNS existente imediat după adăugarea zonei. Următorul pas este crearea pentru domeniul/subdomeniul CDN a mai multor inregistrări A, fiecare dintre ele fiind aplicabilă pentru regiunea specificată de noi. Ca regiuni, putem specifica continente sau țări, iar pentru SUA și Canada sunt disponibile subregiuni.

În cazul nostru, CDN-ul va fi ridicat pe subdomeniul cdn.sayt.in. După adăugarea zonei sayt.in, vom crea prima înregistrare A pentru subdomeniu și vom direcționa întreaga Americă de Nord către serverul din Chicago:

Configurăm și setăm CDN-ul nostru
Vom repeta acțiunea pentru celelalte regiuni, fără a uita să creăm o înregistrare pentru regiunile implicite. Iată ce va rezulta:

Configurăm și setăm CDN-ul nostru

Ultima înregistrare implicită din captura de ecran înseamnă că toate regiunile nespecificate (iar acestea sunt Europa, Africa, utilizatorii de internet prin satelit etc.) vor fi direcționați către serverul din Frankfurt.

Aici se încheie configurarea de bază a DNS-ului. Tot ce rămâne este să accesați site-ul registrarului domeniului și să înlocuiți NS-urile actuale ale domeniului cu cele furnizate de ClouDNS. Și în timp ce NS-urile se actualizează, ne 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 domeniu sau subdomeniu, - încărcați-le pe toate serverele, de exemplu în directorul /etc/ssl/вашдомен/

Dacă nu aveți certificate, puteți obține unul gratuit de la Let’s Encrypt. Pentru aceasta, se potrivește perfect scriptul ACME Shell. Clientul este convenabil și ușor de configurat, iar cel mai important — permite validarea domeniului/subdomeniului prin DNS prin API-ul ClouDNS.

Vom instala acme.sh doar pe unul dintre servere — european 199.247.18.199, de unde certificatele vor fi copiate pe celelalte. Pentru instalare, vom executa:

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

În timpul instalării scriptului va fi creată o sarcină CRON pentru actualizarea ulterioară a certificatelor fără intervenția noastră.

Verificarea domeniului la emiterea certificatului se va face prin DNS folosind API-ul, așa că în fereastra de utilizator ClouDNS din meniul Reseller API trebuie să creăm un nou utilizator API și să stabilim o parolă pentru acesta. Vom nota auth-id obținut cu parola în fișierul ~/ .acme.sh/ dnsapi/ dns_cloudns.sh (nu confundați cu fișierul dns_clouddns.sh). Iată liniile care trebuie de comentat și editat:

CLOUDNS_AUTH_ID=
CLOUDNS_AUTH_PASSWORD=""

Acum vom solicita obținerea certificatului SSL pentru cdn.sayt.in

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

În parametrii, pentru viitor, am specificat comanda pentru reîncărcarea automată a configurației serverului web după fiecare actualizare a duratei de valabilitate a certificatului în viitor.

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

Configurăm și setăm CDN-ul nostru

Să reținem aceste căi, trebuie să fie indicate la copierea certificatului pe alte servere, precum și în setările serverului web. Nu vă faceți griji în legătură cu eroarea de reîncărcare a configurațiilor Nginx — pe un server complet configurat, nu va fi aceasta la actualizarea certificatelor.

Tot ce ne-a mai rămas la SSL este să copiem certificatul obținut pe alte două servere păstrând calea către fișiere. Vom crea pe fiecare dintre ele aceleași directoare și vom face o copie:

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/

Pentru ca actualizarea certificatelor să fie regulată, vom crea pe ambele servere o sarcină CRON zilnică cu comanda:

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

Accesul la serverul sursă la distanță trebuie configurat pe cheie, adică fără introducerea parolei. Nu uitați să faceți acest lucru.

Instalarea și configurarea Nginx

Pentru a livra conținut static, vom folosi Nginx, configurat în modul proxy-cache. Vom actualiza listele de pachete și îl vom instala pe toate cele trei servere:

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

În locul configurării implicite, vom folosi configurarea 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;
    }
  }
}

În configurație, vom edita:

  • max_size — dimensiunea cache-ului, care nu depășește spațiul disponibil pe disc
  • inactive — timpul de păstrare a datelor cache, la care nimeni nu a accesat
  • ssl_certificate și ssl_certificate_key — căile către fișierele certificatului SSL și ale cheii
  • proxy_cache_valid — timpul de păstrare a datelor cache
  • proxy_pass — adresa serverului original, de la care CDN va solicita fișiere pentru caching. În exemplul nostru, aceasta este sayt.in

După cum vedem, totul este simplu. Complicațiile pot apărea doar în configurarea timpului de cache din cauza asemănării directivelor. inactive și proxy_cache_validSă le analizăm în exemplul nostru. Iată ce se întâmplă la inactive=7d și proxy_cache_valid 90d:

  • dacă cererea nu se repetă timp de 7 zile, atunci datele vor fi eliminate din cache la sfârșitul acestui interval
  • dacă cererea se va repeta cel puțin o dată la 7 zile, atunci datele din cache vor fi considerate expirate la sfârșitul a 90 de zile și, la următoarea cerere, Nginx le va actualiza, luându-le de la serverul original

Terminând de editat nginx.conf, vom reîncărca configurația:

root@cdn:~# service nginx reload

CDN-ul nostru este complet pregătit. Pentru 15 $/lună, am obținut puncte de prezență pe trei continente și 3 TB de trafic: câte 1 TB în fiecare locație.

Verificăm funcționalitatea CDN-ului

Vom analiza ping-urile către CDN-ul nostru din diferite locații geografice. Orice servicii de ping vor fi potrivite pentru aceasta.

Punct de lansare
Gazdă
IP
Timp mediu, ms

Germania, Berlin
cdn.sayt.in
199.247.18.199
9.6

Țările de Jos, Amsterdam
cdn.sayt.in
199.247.18.199
10.1

Franța, Paris
cdn.sayt.in
199.247.18.199
16.3

Regatul Unit, 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

Singapore
cdn.sayt.in
157.230.240.216
1.7

Japonia, Tokio
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 vom verifica viteza de încărcare prin CDN. Se spune, — cu noul mod tabletă. Deși până la lansare situația se poate schimba.. Conținutul se livrează rapid.

Vom scrie un mic script în caz că dorim să curățăm cache-ul la punctul CDN.
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

Pentru a șterge tot cache-ul, trebuie doar să-l executați, un fișier separat poate fi curățat astfel:

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

În loc de concluzii

În cele din urmă, vreau să ofer câteva sfaturi utile, pentru a sări peste capcanele care mi-au dat bătăi de cap:

  • Pentru a crește disponibilitatea CDN, este recomandat să configurăm DNS Failover, care ajută la schimbarea rapidă a înregistrării A în caz de defecțiune a serverului. Acest lucru se face în panoul de control al înregistrărilor DNS ale domeniului
  • Site-urile cu o acoperire geografică largă necesită fără îndoială un număr mare de puncte CDN, dar să nu exagerezi. Cel mai probabil, utilizatorul nu va observa o diferență substanțială în comparație cu CDN-ul plătit, dacă plasați servere în 6-7 locuri: Europa, America de Nord (est), America de Nord (vest), Singapore, Australia, Hong Kong sau Japonia
  • Uneori, furnizorii de hosting nu permit utilizarea serverelor închiriate pentru scopuri CDN. Așadar, dacă decideți să desfășurați o rețea de livrare a conținutului ca serviciu, nu uitați să citiți regulile furnizorului de hosting specific în prealabil
  • Studiați harta comunicațiilor subacvatice, pentru a înțelege cum sunt legate continentele și a lua în considerare acest aspect atunci când construiți rețeaua de livrare a conținutului
  • Încercați să verificați ping-urile din diferite locații către serverele dvs. Astfel puteți vedea regiunile cele mai apropiate de punctele CDN și să ajustați mai corect GeoDNS
  • În funcție de sarcini, nu strică să ajustați Nginx pentru cerințele specifice de cache și având în vedere încărcarea serverului. Mă ajută foarte mult articolele despre cache-ul Nginx — aici și accelerarea performanței sub sarcini mari: aici și aici

Sursa: habr.com

Cumpără un hosting fiabil pentru site-uri cu protecție DDoS, servere VPS VDS 🔥 Cumpără un hosting fiabil pentru site-uri cu protecție DDoS, servere VPS VDS | ProHoster