ProHoster > Blog > Amministrazione > Custruisce è cunfigurà u vostru CDN

Custruisce è cunfigurà u vostru CDN

E rete di spedizione di cuntenutu (CDN) sò aduprate da i siti web è l'applicazioni principalmente per accelerà a carica di elementi statici. Questu succede da caching files in servers CDN situati in diverse regioni geografiche. Per dumandà dati via CDN, l'utilizatore riceve da u servitore più vicinu.

U principiu di u funziunamentu è a funziunalità di tutte e rete di spedizione di cuntenutu hè apprussimatamente uguale. Dopu avè ricivutu una dumanda per scaricà un schedariu, u servitore CDN u pigghia una volta da u servitore uriginale è dà à l'utilizatore, à u stessu tempu cachendu per un periudu di tempu. Tutte e dumande successive sò risposti da u cache. Tutti i CDN anu opzioni per preloading files, clearing cache, setting cache expiration, è assai di più.

Succede chì per una ragione o per l'altru hè necessariu urganizà a vostra propria rete di spedizione di cuntenutu, è dopu - ponu esse d'aiutu per l'istruzzioni per assemble a prossima bicicletta.

Custruisce è cunfigurà u vostru CDN
Source: Vettore infograficu creatu da pikisuperstar — www.freepik.com

Quandu avete bisognu di u vostru propiu CDN?

Fighjemu i casi induve eseguisce u vostru propiu CDN hè sensu:

  • quandu vulete salvà soldi, è i costi di esecuzione ancu quandu si usanu CDN à pocu pressu cum'è BunnyCDN quantità à parechji centu di dollari à u mese
  • se vulemu ottene una cache permanente o una cache senza vicini in u servitore è u canali
  • I servizii CDN ùn anu micca punti di presenza in a regione chì avete bisognu
  • Ogni paràmetru di spedizione di cuntenutu speciale hè necessariu
  • vulemu accelerà a consegna di cuntenutu dinamicu mettendu i servitori di produzzione più vicinu à l'utilizatori
  • ci hè una preoccupazione chì un serviziu CDN di terzu pò esse impropriamente recullà o utilizà l'infurmazioni nantu à u cumpurtamentu di l'utilizatori (salutu à i servizii non conformi à GDPR) o impegnà in altre attività illegali.

In a maiò parte di l'altri casi, hè più apprupriatu à utilizà suluzioni pronti esistenti.

Ciò chì avete bisognu di principià

Hè maravigliu si avete u vostru propiu sistema autònumu (AS). Cù ellu pudete assignà a stessa IP à parechji servitori è sicondu sta struzzioni à u livellu di a reta, diretta l'utilizatori à u più vicinu. Hè vale à dì chì ancu cù un bloccu d'indirizzu / 24 hè pussibule di custruisce una rete di distribuzione di cuntenutu. Certi fornituri di servitori permettenu di publicità per l'usu in tutte e regioni dispunibuli per elli.

Se ùn site micca u furtunatu pruprietariu di un bloccu di indirizzi IP, allora per lancià un CDN simplice avete bisognu:

  • nome di duminiu o subdominiu
  • almenu dui servitori in diverse regioni. U servitore pò esse sia dedicatu sia virtuale
  • strumentu geoDNS. Cù u so aiutu, un utilizatore chì accede à un duminiu serà diretta à u servitore più vicinu

Registrate un duminiu è urdinate i servitori

Cù a registrazione di u duminiu, tuttu hè simplice - avemu registratu in ogni zona cù qualsiasi registratore. Pudete ancu aduprà un subdominiu per u CDN, per esempiu qualcosa cum'è cdn.domainname.com. In fatti, in u nostru esempiu faremu ghjustu.

In quantu à l'urdinamentu di i servitori, anu da esse affittati in e regioni è i paesi induve si trova u vostru audience d'utilizatori. Se u prughjettu hè intercontinentale, allora hè cunvenutu di sceglie l'ospiti chì offrenu servitori in u mondu sanu. Esempii: OVH, affittu web и 100Tb - per i servitori dedicati, Vultr и Digital Ocean - per nuvola virtuale *.

Per u nostru CDN privatu, urdinemu 3 servitori virtuali in cuntinenti diffirenti. U Vultr nant'à u servitore per $ 5 / mese averemu SSD di 25GB lochi è 1 TB di trafficu. Durante a stallazione, selezziunà l'ultime Debian. I nostri servitori:

Custruisce è cunfigurà u vostru CDN Francoforte, IP: 199.247.18.199

Custruisce è cunfigurà u vostru CDN Chicago, IP: 149.28.121.123

Custruisce è cunfigurà u vostru CDN Сингапур, IP: 157.230.240.216

* Vultr è DigitalOcean prumettenu $ 100 in creditu à l'utilizatori chì si firmanu utilizendu i ligami in questu articulu una volta aghjunghjenu un metudu di pagamentu. L'autore riceve ancu un picculu cumplimentu da questu, chì hè assai significativu per ellu avà. Per piacè esse capitu.

Configurazione di geoDNS

Per assicurà chì quandu un utilizatore accede à un duminiu CDN o subdominiu, hè direttu à u servitore desideratu (più vicinu), avemu bisognu di un servitore DNS cù a funzione geoDNS.

U principiu è a prucedura operativa di geoDNS sò i seguenti:

  1. Definisce l'IP di u cliente chì hà mandatu a dumanda DNS, o l'IP di u servitore DNS recursive chì hè utilizatu quandu si tratta a dumanda di u cliente. Tali servitori recursivi sò generalmente fornituri DNS.
  2. L'IP di u cliente identifica u so paese o regione. Per questu, i basa di dati GeoIP sò utilizati, di quale ci sò assai oghje. Ci sò qualchi boni opzioni gratuiti.
  3. Sicondu u locu di u cliente, dà l'indirizzu IP di u servitore CDN più vicinu.

Servitore DNS cù funzione geoDNS pò esse assemble lu stessu, ma hè megliu aduprà suluzioni pronti cù una reta di servitori DNS in u mondu è Anycast da a scatula:

  • CloudDNS от $ 9.95 / mese, Tariffa GeoDNS, per difettu ci hè un DNS Failover
  • Zilore от $ 25 / mese, DNS Failover attivatu
  • Amazon Route 53 от $ 35 / mese per puri 50 milioni di geo-questioni. DNS Failover hè caricatu separatamente
  • DNS hè fattu faciule от $ 125 / mese, Ci sò 10 Failovers DNS
  • Cloudflare, a funzione "Geo Steering" hè dispunibule in tariffu Enterprise

Quandu urdinate geoDNS, deve esse attentu à u numeru di richieste incluse in a tarifa è piglià in contu chì u numeru propiu di dumande à u duminiu pò esse parechje volte più altu di l'espertu. Milioni di spider, scanners, spammers è altri spiriti maligni travaglianu senza stanca.

Quasi tutti i servizii DNS includenu in u prezzu un serviziu indispensabile per custruisce un CDN - DNS Failover. Cù u so aiutu, pudete stabilisce u monitoraghju di u funziunamentu di i vostri servitori è, se ùn ci sò micca signali di vita, rimpiazzà automaticamente l'indirizzu di u servitore chì ùn funziona micca in risposti DNS cù una copia di salvezza.

Per custruisce u nostru CDN avemu aduprà CloudDNS, Tariffa GeoDNS.

Aghjunghjemu una nova zona DNS in u vostru contu persunale, indicà u vostru duminiu. Se custruemu un CDN nantu à un subdominiu, è u duminiu principale hè digià in usu, dopu immediatamente dopu l'aghjunghje a zona, ùn vi scurdate di aghjunghje i registri DNS di travagliu esistenti. U prossimu passu hè di creà parechji A-records per u duminiu / subdominiu CDN, ognunu di quale serà utilizatu per a regione chì avemu specificatu. Pudete specificà cuntinenti o paesi cum'è regioni; e sottoregioni sò dispunibuli per i Stati Uniti è u Canada.

In u nostru casu, u CDN serà risuscitatu nantu à un subdomain cdn.sayt.in. Aghjunghjendu una zona sayt.in, Creemu u primu A-record per u subdominiu è dirigemu tutta l'America di u Nordu à u servitore in Chicago:

Custruisce è cunfigurà u vostru CDN
Ripitemu l'azzione per altre regioni, senza scurdà di creà una entrata per e regioni predeterminate. Eccu ciò chì uttene à a fine:

Custruisce è cunfigurà u vostru CDN

L'ultima entrata predeterminata in a screenshot significa chì tutte e regioni micca specificate (è queste sò l'Europa, l'Africa, l'utilizatori di Internet satellitari, etc.) seranu mandati à u servitore in Francoforte.

Questu cumpleta a configurazione di basa di DNS. Tuttu ciò chì resta hè di andà in u situ web di u registratu di u duminiu è rimpiazzà i NS di u duminiu attuale cù quelli emessi da ClouDNS. È mentre i NS sò aghjurnati, prepararemu i servitori.

Installazione di certificati SSL

U nostru CDN hà da travaglià nantu à HTTPS, perchè se avete digià certificati SSL per un duminiu o subdominiu, caricali à tutti i servitori, per esempiu à u repertoriu. /etc/ssl/yourdomain/

Se ùn avete micca certificati, pudete ottene un liberu da Let's Encrypt. Perfetta per questu Script ACME Shell. U cliente hè còmuda è faciule di cunfigurà, è più impurtante, vi permette di cunvalidà un duminiu / subdominiu utilizendu DNS via l'API da ClouDNS.

Stallaremu acme.sh solu in unu di i servitori - European 199.247.18.199, da quale i certificati seranu copiati à tutti l'altri. Per installà, fate:

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

Durante a stallazione di u script, un compitu CRON serà creatu per più aghjurnà i certificati senza a nostra participazione.

A verificazione di u duminiu quandu emette un certificatu serà realizatu via DNS utilizendu l'API, cusì in u vostru contu persunale ClouDNS in u menu API Reseller avete bisognu di creà un novu utilizatore API è stabilisce una password per questu. Scriveremu l'auth-id resultante cù password in un schedariu ~/.acme.sh/dnsapi/dns_cloudns.sh (ùn deve esse cunfusu cù u schedariu dns_clouddns.sh). Eccu e linee chì deve esse micca cummentate è editate:

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

Avà dumandemu un certificatu SSL per cdn.sayt.in

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

In i paràmetri, per u futuru, avemu specificatu un cumandamentu per ricaricà automaticamente a cunfigurazione di u servitore web dopu ogni aghjurnamentu di validità di certificatu in u futuru.

U prucessu tutale di ottene un certificatu pò piglià finu à 2 minuti, ùn l'interrompe micca. Se si verifica un errore di validazione di u duminiu, pruvate à eseguisce u cumandimu di novu. À a fine, videremu induve i certificati sò stati scaricati:

Custruisce è cunfigurà u vostru CDN

Ricurdemu di sti percorsi; anu da esse specificatu quandu copianu u certificatu à altri servitori, è ancu in i paràmetri di u servitore web. Ùn fate micca attente à l'errore di reloading Nginx configs - in un servitore cumpletamente cunfiguratu, ùn apparirà micca quandu aghjurnà i certificati.

Tuttu ciò chì ferma per noi cù SSL hè di copià u certificatu ricevutu à dui altri servitori, priservendu a strada di i schedari. Creemu i stessi cartulari nantu à ognunu di elli è fate una copia:

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/

Per aghjurnà i certificati regularmente, creeremu un compitu CRON di ogni ghjornu nantu à i dui servitori cù u cumandimu:

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

In questu casu, l'accessu à u servitore fonte remota deve esse cunfiguratu da chjave, i.e. senza inserisce una password. Ùn vi scurdate di fà questu.

Installazione è cunfigurazione di Nginx

Per serve u cuntenutu staticu, useremu Nginx cunfiguratu cum'è un servitore proxy caching. Aghjurnà e liste di pacchetti è installate nantu à i trè servitori:

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

Invece di u default, usemu a cunfigurazione da u spoiler quì sottu:
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;
    }
  }
}

In a cunfigurazione editemu:

  • max_size - a dimensione di cache ùn supera u spaziu di discu dispunibule
  • inattivu - tempu di almacenamentu per i dati in cache chì ùn sò micca accede
  • certificatu_ssl и ssl_certificate_key - percorsi per u certificatu SSL è i schedarii chjave
  • proxy_cache_valid - tempu di almacenamiento di dati in cache
  • proxy_pass - l'indirizzu di u servitore uriginale da quale u CDN dumandarà i fugliali per caching. In u nostru esempiu questu hè sayt.in

Comu pudete vede, tuttu hè simplice. L'unica difficultà pò esce à stabilisce u tempu di caching per via di a similitudine di e direttive inattivu и proxy_cache_valid. Fighjemu à elli cù u nostru esempiu. Questu hè ciò chì succede quandu inattivu = 7d и proxy_cache_valid 90d:

  • se a dumanda ùn hè micca ripetuta in 7 ghjorni, i dati seranu sguassati da u cache dopu stu periodu
  • se a dumanda hè ripetuta almenu una volta ogni 7 ghjorni, allora i dati in u cache seranu cunsiderati obsoleti dopu à 90 ghjorni è cù a prossima dumanda Nginx l'aghjurnà, pigliendu da u servitore originale.

Dopu avè finitu di editazione nginx.conf, ricaricà a cunfigurazione:

root@cdn:~# service nginx reload

U nostru CDN hè cumplettamente pronta. Per $ 15 / mese. avemu ricevutu punti di prisenza in trè cuntinenti è 3 TB di trafficu: 1 TB in ogni locu.

Verificate u funziunamentu di u CDN

Fighjemu i ping à u nostru CDN da diverse località geografiche. Ogni serviziu di ping hè adattatu per questu.

Puntu di partenza
Òspite
IP
Tempu mediu, ms

Germania Berlinu
cdn.sayt.in
199.247.18.199
9.6

Paesi Bassi, Amsterdam
cdn.sayt.in
199.247.18.199
10.1

Francia Parigi
cdn.sayt.in
199.247.18.199
16.3

Regnu Unitu, Londra
cdn.sayt.in
199.247.18.199
14.9

Canada, Toronto
cdn.sayt.in
149.28.121.123
16.2

USA, San Francisco
cdn.sayt.in
149.28.121.123
52.7

USA, Dallas
cdn.sayt.in
149.28.121.123
23.1

USA, Chicago
cdn.sayt.in
149.28.121.123
2.6

USA, New York
cdn.sayt.in
149.28.121.123
19.8

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

Giappone Tokyo
cdn.sayt.in
157.230.240.216
74.8

Australia, Sydney
cdn.sayt.in
157.230.240.216
95.9

I risultati sò boni. Avà, mettemu una maghjina di prova in a radica di u situ principale prova.jpg è verificate a so velocità di scaricamentu via CDN. Si dice - fattu. U cuntenutu hè furnitu rapidamente.

Scrivemu un picculu script in casu chì vulemu sguassà a cache in u puntu CDN.
purga.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

Per sguassà tutta a cache, basta eseguite; pudete sguassate un schedariu separatu cum'è questu:

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

Invece di cunclusioni

Infine, vogliu dà qualchi cunsiglii utili per passà immediatamente sopra u rake chì una volta m'hà datu un mal di testa:

  • Per aumentà a toleranza di difetti CDN, hè cunsigliatu di cunfigurà DNS Failover, chì aiuta à cambià rapidamente u record A in casu di fallimentu di u servitore. Questu hè fattu in u pannellu di cuntrollu di i registri DNS di u duminiu
  • I siti cù una larga portata geografica, senza dubbitu, esigeranu un gran numaru di punti CDN, ma ùn siamu micca fanatici. Hè assai prubabile, l'utilizatore ùn hà micca nutatu una differenza significativa in paragunà à un CDN pagatu si mette servitori in 6-7 posti: Europa, America di u Nordu (est), America di u Nordu (ovest), Singapore, Australia, Hong Kong o Giappone.
  • A volte l'ospiti ùn permettenu micca l'usu di servitori affittati per scopi CDN. Dunque, se decide di colpu di implementà una rete di distribuzione di cuntenutu cum'è serviziu, ùn vi scurdate di leghje e regule di u vostru fornitore di hosting specificu in anticipu.
  • Esplora mappa di cumunicazione sottumarinaper imaginà cumu i cuntinenti sò cunnessi è piglià questu in contu quandu custruisce una rete di distribuzione di cuntenutu
  • Pruvate à verificà pings da diversi lochi à i vostri servitori. Questu modu pudete vede e regioni più vicinu à i punti CDN è cunfigurà GeoDNS più currettamente
  • Sicondu i travaglii, saria utile persunalizà Nginx per esigenze specifiche di caching è piglià in contu a carica nantu à u servitore. L'articuli nantu à a cache Nginx m'hà aiutatu assai cù questu - ccà è accelerazione di u travagliu sottu carichi pesanti: ccà и ccà

Source: www.habr.com