🥇Costruire e configurare la tua CDN

Le reti per la distribuzione di contenuti (CDN) vengono utilizzate nei siti Web e nelle applicazioni principalmente per accelerare il caricamento di elementi statici. Ciò accade a causa della memorizzazione nella cache dei file su server CDN situati in diverse regioni geografiche. Richiedendo i dati tramite CDN, l'utente li riceve dal server più vicino.

Il principio di funzionamento e funzionalità di tutte le reti di distribuzione dei contenuti è più o meno lo stesso. Dopo aver ricevuto una richiesta per scaricare un file, il server CDN lo preleva una volta dal server originale e lo fornisce all'utente, memorizzandolo contemporaneamente nella cache per un periodo di tempo specificato. Tutte le richieste successive ricevono risposta dalla cache. Tutti i CDN dispongono di opzioni per precaricare file, svuotare la cache, impostare la data di scadenza e altro ancora.

Succede che, per un motivo o per l'altro, è necessario organizzare la propria rete di distribuzione dei contenuti e quindi lasciare che le istruzioni per assemblare la prossima bici ci siano di aiuto.

Fonte: Vettore infografico creato da pikisuperstar - www.freepik.com

Quando hai bisogno del tuo CDN

Considera i casi in cui ha senso eseguire la tua CDN:

quando si desidera risparmiare denaro e costi di gestione anche quando si utilizzano CDN poco costosi come Bunny CDN ammontano a diverse centinaia di dollari al mese
se vogliamo ottenere una cache permanente o una cache senza server e canali vicini
I servizi CDN non hanno punti di presenza nella regione di cui hai bisogno
eventuali impostazioni speciali di distribuzione dei contenuti richieste
vogliamo accelerare la distribuzione di contenuti dinamici posizionando il server di produzione più vicino agli utenti
si teme che un servizio CDN di terze parti possa raccogliere o utilizzare illegalmente informazioni sul comportamento degli utenti (ciao servizi non conformi al GDPR) o impegnarsi in altre attività illegali

Nella maggior parte degli altri casi, è più appropriato utilizzare soluzioni già pronte esistenti.

Cosa ti serve per iniziare

È meraviglioso se hai il tuo Sistema Autonomo (AS). Con esso puoi assegnare lo stesso IP a più server e secondo questa istruzione a livello di rete, indirizzare gli utenti a quella più vicina. Vale la pena dire che anche con il blocco di indirizzi /24 è possibile costruire una rete di distribuzione dei contenuti. Alcuni provider di server ti consentono di effettuare un annuncio da utilizzare in tutte le regioni a loro disposizione.

Se non sei un felice possessore di un blocco di indirizzi IP, per eseguire un semplice CDN avrai bisogno di:

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

Registra un dominio e ordina i server

Con la registrazione del dominio, tutto è semplice: registriamo in qualsiasi zona con qualsiasi registrar. Puoi anche utilizzare un sottodominio per un CDN, ad esempio qualcosa del genere cdn.nomedominio.com. In realtà, nel nostro esempio, faremo proprio questo.

Per quanto riguarda l'ordinazione dei server, questi dovrebbero essere noleggiati nelle regioni e nei paesi in cui si trova il tuo pubblico di utenti. Se il progetto è intercontinentale, è conveniente scegliere provider di hosting che offrono server in tutto il mondo contemporaneamente. Esempi: OVH, Leasingweb и 100 TB - per server dedicati, Vultr и DigitalOcean — per cloud virtuale*.

Per la nostra CDN privata ordineremo 3 server virtuali in diversi continenti. A Vultr sul server per $ 5/mese otterremo 25GB SSD luoghi e 1TB di traffico. Durante l'installazione, seleziona l'ultima 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 un credito di 100$ agli utenti che si registrano tramite i link presenti nell'articolo subito dopo aver aggiunto un metodo di pagamento. Anche l'autore riceve da questo un piccolo complimento, che per lui adesso è molto significativo. Per favore sii comprensivo.

Configurazione del geoDNS

Affinché l'utente possa essere indirizzato al server desiderato (più vicino) quando accede a un dominio o sottodominio CDN, abbiamo bisogno di un server DNS con la funzione geoDNS.

Il principio e il funzionamento di geoDNS è il seguente:

Specifica l'IP del client che ha inviato la richiesta DNS o l'IP del server DNS ricorsivo utilizzato durante l'elaborazione della richiesta del client. Tali server ricorsivi sono solitamente DNS di provider.
L'IP del cliente riconosce il suo paese o regione. A questo scopo vengono utilizzati i database GeoIP, di cui oggi ce ne sono moltissimi. Ce ne sono di buoni opzioni gratuite.
A seconda della posizione del client, gli fornisce l'indirizzo IP del server CDN più vicino.

Il server DNS con funzione geoDNS può essere assemblare da solo, ma è meglio utilizzare soluzioni già pronte con una rete di server DNS in tutto il mondo e anycast dalla scatola:

LouDNS от $ 9.95/mese, tariffa GeoDNS, per impostazione predefinita è presente un failover DNS
Zilore от $ 25/mese, Failover DNS abilitato
Amazon percorso 53 от $ 35/mese per un totale netto di 50 milioni di richieste geografiche. Il failover DNS viene fatturato separatamente
DNS reso facile от $ 125/mese, sono presenti 10 failover DNS
Cloudflare, la funzionalità "Geo Steering" è disponibile nei piani Enterprise

Quando ordini geoDNS, dovresti prestare attenzione al numero di richieste incluse nella tariffa e tenere presente che il numero effettivo di richieste al dominio può superare di parecchie volte le aspettative. Milioni di ragni, scanner, spammer e altri spiriti maligni lavorano instancabilmente.

Quasi tutti i servizi DNS includono un servizio indispensabile per la realizzazione di una CDN: DNS Failover. Con il suo aiuto puoi impostare il monitoraggio del funzionamento dei tuoi server e, in assenza di segni di vita, sostituire automaticamente l'indirizzo di un server non funzionante con uno di backup nelle risposte DNS.

Per costruire la nostra CDN, utilizzeremo CloudDNS, Tariffa GeoDNS.

Aggiungiamo una nuova zona DNS nel tuo account personale, specificando il tuo dominio. Se stiamo costruendo una CDN su un sottodominio e il dominio principale è già in uso, subito dopo aver aggiunto la zona, non dimenticare di aggiungere i record DNS funzionanti esistenti. Il passo successivo è creare diversi A-record per il dominio/sottodominio CDN, ognuno dei quali verrà applicato alla regione che abbiamo specificato. È possibile specificare continenti o paesi come regioni; sono disponibili sottoregioni per Stati Uniti e Canada.

Nel nostro caso la CDN verrà generata su un sottodominio cdn.sayt.in. Aggiungendo una zona dire.in, crea il primo A-record per il sottodominio e indirizza tutto il Nord America al server di Chicago:

Ripetiamo l'azione per le altre regioni, ricordandoci di creare una voce per le regioni predefinite. Ecco cosa succede alla fine:

L'ultima voce predefinita nello screenshot significa che tutte le regioni non specificate (e queste sono Europa, Africa, utenti Internet via satellite, ecc.) verranno inviate al server di Francoforte.

Questo completa la configurazione DNS di base. Resta da andare sul sito del registrar dei domini e sostituire gli attuali NS di domini con quelli emessi da ClouDNS. E mentre i NS verranno aggiornati, noi prepareremo i server.

Installazione di certificati SSL

Il nostro CDN funzionerà su HTTPS, quindi se disponi già di certificati SSL per un dominio o sottodominio, caricali su tutti i server, ad esempio nella directory /etc/ssl/tuodominio/

Se non sono presenti certificati, puoi ottenerne uno gratuito da Let's Encrypt. Perfetto per questo ACME Shellscript. Il client è comodo e facile da configurare e, cosa più importante, ti consente di convalidare un dominio/sottodominio tramite DNS tramite l'API ClouDNS.

Installeremo acme.sh solo su uno dei server, l'europeo 199.247.18.199, dal quale i certificati verranno copiati su tutti gli altri. Per installare, eseguire:

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

Durante l'installazione dello script verrà creato un lavoro CRON per l'ulteriore rinnovo dei certificati senza la nostra partecipazione.

Quando si emette un certificato, il dominio verrà controllato utilizzando DNS utilizzando l'API, quindi nell'account personale ClouDNS nel menu API del rivenditore, è necessario creare una nuova API utente e impostare una password per essa. L'ID di autorizzazione risultante con una password verrà scritto nel file ~/.acme.sh/dnsapi/dns_cloudns.sh (da non confondere con file dns_clouddns.sh). Ecco le righe che devono essere decommentate e modificate:

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

Ora richiederemo un certificato SSL per cdn.sayt.in

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

Nelle opzioni, per il futuro, abbiamo specificato un comando per ricaricare automaticamente la configurazione del server web dopo ogni rinnovo futuro del periodo di validità del certificato.

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

Ricorda questi percorsi, dovranno essere specificati durante la copia del certificato su altri server, nonché nelle impostazioni del server web. Non prestiamo attenzione all'errore di ricaricare le configurazioni Nginx: non sarà su un server completamente configurato durante l'aggiornamento dei certificati.

Tutto ciò che ci resta per SSL è copiare il certificato ricevuto su altri due server mantenendo il percorso dei file. Creiamo le stesse directory su ognuno di essi e facciamone 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 aggiornare regolarmente i certificati, crea un lavoro CRON giornaliero su entrambi i server con il comando:

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

In questo caso è necessario configurare l'accesso al server di origine remoto per chiave, cioè. senza inserire una password. Non dimenticare di farlo.

Installazione e configurazione di Nginx

Per servire contenuto statico, utilizzeremo Nginx configurato come server proxy di caching. Aggiorna gli elenchi dei pacchetti e installalo su tutti e tre i server:

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

Invece del valore predefinito, utilizziamo la configurazione dallo spoiler seguente:
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;
    }
  }
}

Modifica nella configurazione:

dimensione_massima — la dimensione della cache, che non superi lo spazio disponibile su disco
inattivo - tempo di archiviazione dei dati memorizzati nella cache a cui nessuno ha avuto accesso
ssl_certificate и ssl_certificate_key — percorsi del certificato SSL e dei file chiave
proxy_cache_valid - tempo di conservazione dei dati memorizzati nella cache
proxy_pass — indirizzo del server originale dal quale la CDN richiederà i file per la memorizzazione nella cache. Nel nostro esempio, questo dire.in

Come puoi vedere, tutto è semplice. Le difficoltà possono sorgere solo nell'impostazione del tempo di memorizzazione nella cache a causa della somiglianza delle direttive inattivo и proxy_cache_valid. Analizziamoli con il nostro esempio. Ecco cosa succede quando inattivo=7d и proxy_cache_valido 90d:

se la richiesta non viene ripetuta entro 7 giorni, trascorso tale periodo i dati verranno cancellati dalla cache
se la richiesta viene ripetuta almeno una volta ogni 7 giorni, allora i dati presenti nella cache verranno considerati obsoleti dopo 90 giorni e Nginx li aggiornerà alla richiesta successiva, prelevandoli dal server originale

Finito di modificare nginx.conf, ricaricare la configurazione:

root@cdn:~# service nginx reload

Il nostro CDN è pronto. Per $ 15 al mese. abbiamo ricevuto punti di presenza in tre continenti e 3 TB di traffico: 1 TB in ogni località.

Controllare il lavoro della CDN

Diamo un'occhiata ai ping al nostro CDN da diverse posizioni geografiche. Qualsiasi servizio ping funzionerà per questo.

Punto di lancio
ospite
IP
Tempo medio, signorina

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

Gran Bretagna, 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

Stati Uniti, Chicago
cdn.sayt.in
149.28.121.123
2.6

Stati Uniti, New York
cdn.sayt.in
149.28.121.123
19.8

Singapore
cdn.sayt.in
157.230.240.216
1.7

Giappone Tokio
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 inseriremo un'immagine di prova nella root del sito principale test.jpg e controlla la velocità di download tramite CDN. Si dice - fatto. Il contenuto viene consegnato rapidamente.

Scriviamo un piccolo script nel caso in cui desideriamo svuotare la cache sul 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 l'intera cache, basta eseguirlo, un file separato può essere pulito in questo modo:

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

Invece di conclusioni

Voglio infine dare alcuni consigli utili per scavalcare subito il rastrello che in quel momento mi fece venire il mal di testa:

Per aumentare la tolleranza agli errori della CDN, si consiglia di configurare il DNS Failover, che aiuta a modificare rapidamente il record A in caso di guasto del server. Questo viene fatto nel pannello di controllo dei record DNS del dominio.
I siti con un'ampia copertura geografica richiedono senza dubbio un gran numero di CDN, ma non siamo fanatici. Molto probabilmente l'utente non noterà una differenza significativa rispetto ad un CDN a pagamento se si posizionano i server in 6-7 località: Europa, Nord America (est), Nord America (ovest), Singapore, Australia, Hong Kong o Giappone
Talvolta gli hoster non consentono l'utilizzo dei server noleggiati per scopi CDN. Pertanto, se all'improvviso decidi di implementare una rete di distribuzione dei contenuti come servizio, non dimenticare di leggere in anticipo le regole di un particolare provider di hosting
esplorare mappa delle comunicazioni subacqueeper rappresentare il modo in cui i continenti sono collegati e tenerne conto quando si costruisce una rete di distribuzione dei contenuti
Prova a controllare ping da posti diversi ai tuoi server. In questo modo potrai vedere le regioni più vicine ai punti CDN e configurare più correttamente il GeoDNS
A seconda delle attività, sarà utile mettere a punto Nginx per requisiti specifici di memorizzazione nella cache e tenendo conto del carico sul server. Gli articoli sulla cache Nginx mi hanno aiutato molto in questo - qui e accelerazione del lavoro sotto carichi pesanti: qui и qui

Fonte: habr.com

Creazione e configurazione della tua CDN