🥇Costruiamo e configuriamo il nostro CDN

Le reti di distribuzione dei contenuti (CDN) vengono utilizzate su siti web e applicazioni principalmente per accelerare il caricamento degli elementi statici. Questo avviene mediante la memorizzazione nella cache dei file sui server CDN, situati in diverse aree geografiche. Richiedendo dati tramite CDN, l'utente li riceve dal server più vicino.

Il principio di funzionamento e la funzionalità di tutte le reti di distribuzione dei contenuti sono simili. Quando il server CDN riceve una richiesta per il caricamento di un file, lo preleva una sola volta dal server originale e lo restituisce all'utente, memorizzandolo anche in cache per un determinato periodo di tempo. Per tutte le richieste successive, la risposta viene fornita dalla cache. Tutti i CDN hanno opzioni per il caricamento anticipato dei file, la pulizia della cache, la configurazione della durata della memorizzazione, e molto altro.

A volte, per vari motivi, è necessario organizzare una propria rete di distribuzione dei contenuti, e quindi — che ci sia di aiuto l'istruzione per assemblare un'altra bicicletta.

Fonte: Infographic vector created by pikisuperstar — www.freepik.com

Quando hai bisogno di un CDN proprio

Consideriamo i casi in cui ha senso avviare un CDN proprio:

quando si desidera risparmiare, e le spese correnti anche utilizzando CDN a basso costo come BunnyCDN ammontano a diverse centinaia di dollari al mese
se vogliamo ottenere una cache permanente o una cache senza vicini sul server e sulla rete
nel tuo regione i servizi CDN non hanno punti di presenza
sono necessarie impostazioni speciali per la distribuzione dei contenuti
vogliamo accelerare la consegna dei contenuti dinamici, posizionando i server di produzione più vicino agli utenti
c'è preoccupazione che un servizio CDN di terze parti possa raccogliere o utilizzare in modo improprio le informazioni sui comportamenti degli utenti (saluti ai servizi non conformi al GDPR) o effettuare altre azioni illecite

Nella maggior parte degli altri casi è più opportuno utilizzare soluzioni pronte esistenti.

Cosa serve per l'avvio

È fantastico se hai il tuo sistema autonomo (AS). Con esso puoi assegnare lo stesso IP a diversi server e seguendo questa istruzione a livello di rete indirizzare gli utenti verso il più vicino. Vale la pena dire che anche con un blocco di indirizzi /24 è possibile costruire una rete di distribuzione dei contenuti. Alcuni fornitori di server consentono di fare un annuncio per l'utilizzo in tutte le aree a loro disponibili.

Se non siete un felice proprietario di un blocco di indirizzi IP, per avviare un semplice CDN avrete bisogno di:

un nome di dominio o un sottodominio
almeno due server in diverse regioni. Il server può essere sia dedicato che virtuale
uno strumento geoDNS. Con questo, l'utente, contattando il dominio, verrà indirizzato al server più vicino

Registriamo il dominio e ordiniamo i server

Per la registrazione del dominio è tutto semplice: registriamo in qualsiasi zona presso qualsiasi registrar. Per il CDN è possibile utilizzare anche un sottodominio, ad esempio qualcosa come cdn.nomeagenzia.com. Nel nostro esempio procederemo in questo modo.

Per quanto riguarda l'ordine dei server, questi devono essere affittati nelle regioni e nei paesi dove si trova il vostro pubblico. Se il progetto è intercontinentale, è conveniente scegliere fornitori di hosting che propongono server in tutto il mondo. Esempi: OVH, Leaseweb e 100Tb — per server dedicati, Vultr e DigitalOcean — per cloud virtuali*.

Per il nostro CDN privato ordineremo 3 server virtuali su diversi continenti. A Vultr un server con $5/mese otteniamo 25GB SSD spazio e 1TB di traffico. Durante l'installazione scegliamo l'ultima versione di Debian. I nostri server:

Francoforte, ip: 199.247.18.199

Chicago, ip: 149.28.121.123

Singapore, ip: 157.230.240.216

* Vultr e DigitalOcean promettono $100 di credito agli utenti registrati tramite i link presenti nell'articolo, subito dopo l'aggiunta di un metodo di pagamento. L'autore riceve anche un piccolo vantaggio da questo, che per lui è molto significativo in questo momento. Si prega di comprendere.

Configuriamo geoDNS

Affinché l'utente, contattando il dominio o il sottodominio del CDN, venga indirizzato al server corretto (il più vicino a lui), avremo bisogno di un server DNS con la funzione geoDNS.

Il principio e il funzionamento di geoDNS sono i seguenti:

Determina l'IP del cliente che ha inviato la richiesta DNS, oppure l'IP del server DNS ricorsivo utilizzato durante l'elaborazione della richiesta del cliente. Di solito, questi server ricorsivi sono i DNS dei fornitori.
Dall'IP del cliente riconosce il suo paese o regione. A questo scopo si utilizzano database GeoIP, di cui oggi ce ne sono molti. Ci sono opzioni gratuite molto buone.
In base alla posizione del cliente, restituisce l'indirizzo IP del server CDN più vicino.

Un server DNS con funzione geoDNS può essere essere costruito autonomamente, ma è meglio utilizzare soluzioni pronte con una rete di server DNS in tutto il mondo e Anycast pronte all'uso:

ClouDNS di $9.95/mese, piano GeoDNS, con un DNS Failover incluso
Zilore di $25/mese, attivato DNS Failover
Amazon Route 53 di $35/mese per 50 milioni di richieste geo pulite. DNS Failover ha un costo separato
DNS Made Easy di $125/mese, ci sono 10 DNS Failover
75 Percentile, la funzione «Geo Steering» è disponibile nei piani Enterprise

Quando si ordina geoDNS, è necessario prestare attenzione al numero di richieste incluse nel piano e tenere conto del fatto che il numero reale di richieste al dominio può superare di gran lunga le aspettative. Milioni di spider, scanner, spammer e altre insidie lavorano instancabilmente.

Praticamente tutti i servizi DNS includono nel prezzo un servizio indispensabile per la creazione di una CDN: il DNS Failover. Con questo, è possibile impostare il monitoraggio della funzionalità dei propri server e, in caso di assenza di segnali di vita, sostituire automaticamente negli indirizzi DNS del server non funzionante con quello di riserva.

Per costruire la nostra CDN utilizzeremo ClouDNS, piano GeoDNS.

Aggiungeremo nel nostro pannello un nuovo dominio DNS, specificando il nostro dominio. Se costruiremo la CDN su un sottodominio e il dominio principale è già in uso, non dimentichiamo di aggiungere le registrazioni DNS esistenti subito dopo aver aggiunto il dominio. La prossima azione è creare per il dominio/sottodominio CDN diverse registrazioni A, ognuna delle quali verrà applicata per la regione che abbiamo specificato. Come regioni, possono essere indicati continenti o paesi, e per gli Stati Uniti e il Canada sono disponibili subregioni.

Nel nostro caso, la CDN sarà creata sul sottodominio cdn.sayt.in. Aggiungendo la zona sayt.in, creeremo la prima registrazione A per il sottodominio e indirizzeremo tutta l'America del Nord al server di Chicago:

Ripeteremo l'azione per le altre regioni, non dimenticando di creare una registrazione per le regioni predefinite. Ecco cosa otterremo alla fine:

L'ultima registrazione predefinita nello screenshot significa che tutte le regioni non designate (quali Europa, Africa, utenti di internet satellitare, ecc.) saranno indirizzate al server di Francoforte.

Con questo, la configurazione di base del DNS è completata. Resta solo da accedere al sito del registrar del dominio e sostituire gli attuali NS del dominio con quelli forniti da ClouDNS. E mentre gli NS si aggiornano, prepareremo i server.

Installazione dei certificati SSL

La nostra CDN funzionerà tramite HTTPS, quindi se hai già certificati SSL per il dominio o il sottodominio, caricali su tutti i server, ad esempio nella directory /etc/ssl/вашдомен/

Se non hai certificati, puoi ottenerne uno gratuito da Let’s Encrypt. A tal fine, va bene ACME Shell script. Il cliente è comodo e semplice da configurare, e soprattutto consente di effettuare la validazione del dominio/sottodominio tramite DNS tramite l'API di ClouDNS.

Installeremo acme.sh solo su uno dei server — quello europeo 199.247.18.199, da cui i certificati verranno copiati su tutti gli altri. Per l'installazione eseguiremo:

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

Durante l'installazione dello script verrà creato un compito CRON per l'aggiornamento automatico dei certificati senza il nostro intervento.

Il controllo del dominio al momento del rilascio del certificato verrà effettuato tramite DNS utilizzando l'API, quindi nel pannello personale di ClouDNS nel menu Reseller API è necessario creare un nuovo utente API e impostare una password per esso. L'auth-id ottenuto insieme alla password dovrà essere inserito nel file ~/ .acme.sh /dnsapi /dns_cloudns.sh (non confondere con il file dns_clouddns.sh). Ecco le righe che devono essere decommentate e modificate:

CLOUDNS_AUTH_ID=
CLOUDNS_AUTH_PASSWORD=""

Ora richiederemo il rilascio del certificato SSL per cdn.sayt.in

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

Nelle impostazioni, per il futuro, abbiamo specificato il comando per il riavvio automatico della configurazione del server web dopo ciascun aggiornamento del certificato in seguito.

L'intero processo di ottenimento del certificato può richiedere fino a 2 minuti, non interromperlo. Se si verifica un errore di validazione del dominio, prova a eseguire di nuovo il comando. Alla fine vedremo dove sono stati caricati i certificati:

Ricordiamo questi percorsi, dovranno essere indicati durante la copia del certificato su altri server, nonché nelle impostazioni del server web. Non prestiamo attenzione all'errore di riavvio dei confini di Nginx — su un server completamente configurato durante l'aggiornamento dei certificati non ci sarà.

Tutto ciò che ci resta da fare per l'SSL è copiare il certificato ottenuto su altri due server mantenendo il percorso ai file. Creiamo su ciascuno di essi le stesse directory e facciamo una copia:

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/

Per garantire un aggiornamento regolare dei certificati, creiamo su entrambi i server un compito CRON giornaliero con il comando:

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

In questo caso, l'accesso al server remoto sorgente deve essere configurato con la chiave, cioè senza inserire password. Non dimenticare di farlo.

Installazione e configurazione di Nginx

Per la consegna di contenuti statici utilizzeremo Nginx, configurato in modalità proxy server cache. Aggiorneremo le liste dei pacchetti e lo installeremo su tutti e tre i server:

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

Utilizzeremo la configurazione di default dal contenuto in spoiler qui sotto:
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;
    }
  }
}

Nel file di configurazione modificheremo:

max_size — dimensione della cache, che non supera lo spazio disponibile su disco
inactive — tempo di conservazione dei dati memorizzati nella cache a cui nessuno ha fatto accesso
ssl_certificate e ssl_certificate_key — percorsi ai file del certificato SSL e della chiave
proxy_cache_valid — tempo di conservazione dei dati memorizzati nella cache
proxy_pass — indirizzo del server originale da cui il CDN richiederà i file per la memorizzazione nella cache. Nel nostro esempio questo è sayt.in

Come possiamo vedere, è tutto piuttosto semplice. L'unica complessità potrebbe sorgere nella configurazione del tempo di memorizzazione nella cache a causa della somiglianza delle direttive inactive e proxy_cache_valid. Esaminiamo il tutto con il nostro esempio. Ecco cosa succede con inactive=7d e proxy_cache_valid 90d:

se la richiesta non viene ripetuta per 7 giorni, i dati verranno rimossi dalla cache al termine di questo periodo
se la richiesta verrà ripetuta almeno una volta ogni 7 giorni, i dati nella cache verranno considerati obsoleti dopo 90 giorni e alla successiva richiesta Nginx li aggiornerà, prelevandoli dal server originale

Una volta terminate le modifiche nginx.conf, ricaricheremo la configurazione:

root@cdn:~# service nginx reload

Il nostro CDN è completamente pronto. Per $15/mese abbiamo ottenuto punti di presenza in tre continenti e 3 TB di traffico: 1 TB in ciascuna posizione.

Controlliamo il funzionamento del CDN

Diamo un'occhiata ai ping al nostro CDN da diverse località geografiche. Qualsiasi servizio di ping andrà bene per questo.

Punto di lancio
Host
IP
Tempo medio, ms

Germania, Berlino
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

Regno Unito, Londra
cdn.sayt.in
199.247.18.199
14.9

Canada, Toronto
cdn.sayt.in
149.28.121.123
16.2

Stati Uniti, San Francisco
cdn.sayt.in
149.28.121.123
52.7

Stati Uniti, 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

Singapore
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 sono buoni. Ora posizioniamo un'immagine di prova nella radice del sito principale test.jpg e verifichiamo la velocità di caricamento tramite CDN. È stato detto, — fatto. I contenuti vengono restituiti rapidamente.

Scriveremo un piccolo script nel caso volessimo svuotare la cache nel punto 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

Per eliminare completamente la cache basta semplicemente eseguirlo, un file singolo può essere pulito così:

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

Invece delle conclusioni

Infine, voglio dare alcuni consigli utili per evitare di inciampare su errori che in passato mi hanno causato mal di testa:

Per aumentare la resilienza del CDN, si consiglia di configurare il DNS Failover, che aiuta a cambiare rapidamente il record A in caso di guasto del server. Questo si fa nel pannello di controllo dei record DNS del dominio
I siti con una vasta copertura geografica richiedono sicuramente un numero elevato di punti CDN, ma manteniamoci senza fanaticismo. Probabilmente, l'utente non noterà differenze sostanziali rispetto a un CDN a pagamento se si posizionano i server in 6-7 luoghi: Europa, Nord America (est), Nord America (ovest), Singapore, Australia, Hong Kong o Giappone
Talvolta gli hosting provider non consentono di utilizzare server affittati per scopi CDN. Pertanto, se decideste di implementare una rete di distribuzione dei contenuti come servizio, non dimenticate di leggere in anticipo le regole del provider di hosting specifico
Studiate la mappa delle comunicazioni sottomarine, per comprendere come sono collegati i continenti e tenerne conto nella costruzione della rete di distribuzione dei contenuti
Provate a verificare i ping da diverse località ai vostri server. In questo modo, è possibile vedere le regioni più vicine ai punti CDN e configurare meglio il GeoDNS
A seconda delle esigenze, non guasta personalizzare Nginx in base ai requisiti specifici di caching e considerando il carico sul server. In questo mi sono stati molto utili gli articoli sul caching di Nginx — qui e sull'accelerazione delle prestazioni in caso di carichi elevati: qui e qui