Les xarxes de lliurament de contingut (CDN) són utilitzades pels llocs web i les aplicacions principalment per accelerar la càrrega d'elements estàtics. Això passa mitjançant l'emmagatzematge de fitxers a la memòria cau en servidors CDN situats en diferents regions geogràfiques. En sol·licitar dades via CDN, l'usuari les rep del servidor més proper.
El principi de funcionament i la funcionalitat de totes les xarxes de lliurament de contingut és aproximadament el mateix. Després d'haver rebut una sol·licitud per descarregar un fitxer, el servidor CDN l'agafa una vegada del servidor original i el lliura a l'usuari, alhora que l'emmagatzema a la memòria cau durant un període de temps determinat. Totes les sol·licituds posteriors es responen des de la memòria cau. Tots els CDN tenen opcions per carregar prèviament fitxers, esborrar la memòria cau, configurar la caducitat de la memòria cau i molt més.
Succeeix que per una raó o una altra és necessari organitzar la teva pròpia xarxa de lliurament de contingut i, aleshores, que ens siguin d'ajuda les instruccions per muntar la següent bicicleta.
Font:
Quan necessiteu el vostre propi CDN?
Vegem els casos en què l'execució del vostre propi CDN té sentit:
- quan voleu estalviar diners i costos d'execució, fins i tot quan utilitzeu CDN de baix cost com ascendeixen a diversos centenars de dòlars al mes
- si volem obtenir una memòria cau permanent o una memòria cau sense veïns al servidor i al canal
- Els serveis CDN no tenen punts de presència a la regió que necessiteu
- Cal qualsevol configuració especial de lliurament de contingut
- volem accelerar el lliurament de contingut dinàmic col·locant els servidors de producció més a prop dels usuaris
- hi ha la preocupació que un servei de CDN de tercers pugui recopilar o utilitzar de manera incorrecta informació sobre el comportament de l'usuari (hola als serveis que no compleixen amb GDPR) o participar en altres activitats il·legals
En la majoria dels altres casos, és més adequat utilitzar solucions ja existents.
El que necessites per començar
És meravellós si teniu el vostre propi sistema autònom (AS). Amb ell pots assignar la mateixa IP a diversos servidors i a nivell de xarxa, dirigiu els usuaris a la més propera. Val la pena dir que fins i tot amb un bloc d'adreces /24 és possible construir una xarxa de lliurament de contingut. Alguns proveïdors de servidors us permeten anunciar-vos per utilitzar-los a totes les regions disponibles.
Si no sou l'afortunat propietari d'un bloc d'adreces IP, per llançar un CDN senzill necessitareu:
- nom de domini o subdomini
- almenys dos servidors en regions diferents. El servidor pot ser dedicat o virtual
- eina geoDNS. Amb la seva ajuda, un usuari que accedeixi a un domini serà dirigit al servidor més proper
Registreu un domini i ordeneu servidors
Amb el registre del domini, tot és senzill: ens registrem a qualsevol zona amb qualsevol registrador. També podeu utilitzar un subdomini per al CDN, per exemple alguna cosa així cdn.domainname.com. De fet, en el nostre exemple ho farem.
Pel que fa a la comanda de servidors, s'han de llogar a les regions i països on es troba el vostre públic d'usuari. Si el projecte és intercontinental, és convenient triar proveïdors d'allotjament que ofereixin servidors a tot el món. Exemples: , и - per a servidors dedicats, и — per al núvol virtual*.
Per al nostre CDN privat, demanarem 3 servidors virtuals en diferents continents. U Vultr al servidor per $5/mes aconseguirem 25GB SSD llocs i 1 TB de trànsit. Durant la instal·lació, seleccionarem l'última Debian. Els nostres servidors:
Frankfurt, IP: 199.247.18.199
Chicago, IP: 149.28.121.123
Singapur, IP: 157.230.240.216
*Vultr i DigitalOcean prometen un crèdit de 100 dòlars als usuaris que es registren mitjançant els enllaços d'aquest article un cop afegeixin un mètode de pagament. L'autor també rep un petit elogi d'això, que ara és molt significatiu per a ell. Si us plau, sigueu comprensius.
Configuració de geoDNS
Per garantir que quan un usuari accedeix a un domini o subdomini CDN, es dirigeix al servidor desitjat (més proper), necessitarem un servidor DNS amb la funció geoDNS.
El principi i el procediment operatiu de geoDNS és el següent:
- Defineix la IP del client que ha enviat la sol·licitud de DNS, o la IP del servidor DNS recursiu que s'utilitza quan es processa la sol·licitud del client. Aquests servidors recursius solen ser proveïdors de DNS.
- La IP del client identifica el seu país o regió. Per a això s'utilitzen bases de dades GeoIP, de les quals actualment n'hi ha moltes. N'hi ha de bons .
- Depenent de la ubicació del client, li proporciona l'adreça IP del servidor CDN més proper.
El servidor DNS amb funció geoDNS pot ser , però és millor utilitzar solucions ja fetes amb una xarxa de servidors DNS a tot el món i de la caixa:
- d' $9.95/mes, tarifa GeoDNS, de manera predeterminada hi ha un DNS Failover
- d' $25/mes, S'ha activat la commutació per error de DNS
- d' $35/mes per a consultes geogràfiques de 50 milions. La fallada de DNS es cobra per separat
- d' $125/mes, hi ha 10 errors de DNS
- , la funció "Geo Steering" està disponible a les tarifes Enterprise
En demanar geoDNS, heu de parar atenció al nombre de sol·licituds incloses a la tarifa i tenir en compte que el nombre real de sol·licituds al domini pot ser moltes vegades superior al previst. Milions d'aranyes, escàners, spammers i altres esperits malignes treballen incansablement.
Gairebé tots els serveis DNS inclouen en el preu un servei indispensable per construir un CDN - DNS Failover. Amb la seva ajuda, podeu configurar el control del funcionament dels vostres servidors i, si no hi ha senyals de vida, substituir automàticament l'adreça del servidor que no funciona a les respostes DNS per una de còpia de seguretat.
Per construir el nostre CDN utilitzarem , tarifa GeoDNS.
Afegim una nova zona DNS al vostre compte personal, indicant el vostre domini. Si estem construint un CDN en un subdomini i el domini principal ja està en ús, immediatament després d'afegir la zona, no us oblideu d'afegir els registres DNS existents. El següent pas és crear diversos registres A per al domini/subdomini CDN, cadascun dels quals s'utilitzarà per a la regió que hem especificat. Podeu especificar continents o països com a regions; les subregions estan disponibles per als EUA i el Canadà.
En el nostre cas, el CDN es generarà en un subdomini cdn.sayt.in. Afegint una zona sayt.in, creem el primer registre A per al subdomini i dirigim tota Amèrica del Nord al servidor de Chicago:
Repetim l'acció per a altres regions, sense oblidar-nos de crear una entrada per a les regions predeterminades. Això és el que obteniu al final:
L'última entrada predeterminada de la captura de pantalla significa que totes les regions no especificades (i aquestes són Europa, Àfrica, usuaris d'Internet per satèl·lit, etc.) s'enviaran al servidor de Frankfurt.
Això completa la configuració bàsica de DNS. Només queda anar al lloc web del registrador de dominis i substituir els NS de domini actuals per les emeses per ClouDNS. I mentre s'actualitzen els NS, prepararem els servidors.
Instal·lació de certificats SSL
El nostre CDN funcionarà amb HTTPS, de manera que si ja teniu certificats SSL per a un domini o subdomini, pengeu-los a tots els servidors, per exemple al directori /etc/ssl/el teudomini/
Si no teniu certificats, podeu obtenir-ne un de franc a Let's Encrypt. Perfecte per a això . El client és còmode i fàcil de configurar i, el més important, us permet validar un domini/subdomini mitjançant DNS mitjançant l'API de ClouDNS.
Instal·larem acme.sh només en un dels servidors: europeu 199.247.18.199, del qual els certificats es copiaran a tots els altres. Per instal·lar, feu:
root@cdn:~# wget -O - https://get.acme.sh | bash; source ~/.bashrcDurant la instal·lació de l'script, es crearà una tasca CRON per a una actualització posterior dels certificats sense la nostra participació.
La verificació del domini quan s'emet un certificat es realitzarà mitjançant DNS mitjançant l'API, de manera que al vostre compte personal de ClouDNS al menú de l'API de distribuïdor haureu de crear un nou usuari de l'API i establir-hi una contrasenya. Escriurem l'auth-id resultant amb contrasenya en un fitxer ~/.acme.sh/dnsapi/dns_cloudns.sh (no s'ha de confondre amb el fitxer dns_clouddns.sh). Aquestes són les línies que cal deixar de comentar i editar:
CLOUDNS_AUTH_ID=<auth-id>
CLOUDNS_AUTH_PASSWORD="<пароль>"
Ara sol·licitem un certificat SSL per cdn.sayt.in
root@cdn:~# acme.sh --issue --dns dns_cloudns -d cdn.sayt.in --reloadcmd "service nginx reload"En els paràmetres, per al futur, vam especificar una ordre per tornar a carregar automàticament la configuració del servidor web després de cada actualització de validesa del certificat en el futur.
Tot el procés d'obtenció d'un certificat pot trigar fins a 2 minuts, no l'interrompis. Si es produeix un error de validació del domini, proveu d'executar l'ordre de nou. Al final veurem on es van descarregar els certificats:
Recordem aquests camins; caldrà especificar-los en copiar el certificat a altres servidors, així com a la configuració del servidor web. No prestem atenció a l'error de tornar a carregar les configuracions de Nginx: en un servidor completament configurat, no apareixerà en actualitzar els certificats.
Amb SSL només ens queda copiar el certificat rebut a dos servidors més, conservant el camí als fitxers. Creem els mateixos directoris en cadascun d'ells i fem una còpia:
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 actualitzar els certificats amb regularitat, crearem una tasca CRON diària als dos servidors amb l'ordre:
scp -r [email protected]:/root/.acme.sh/cdn.sayt.in/* /root/.acme.sh/cdn.sayt.in/ && service nginx reload
En aquest cas, s'ha de configurar l'accés al servidor d'origen remot , és a dir sense introduir una contrasenya. No us oblideu de fer això.
Instal·lació i configuració de Nginx
Per oferir contingut estàtic, utilitzarem Nginx configurat com a servidor intermediari de memòria cau. Actualitzem les llistes de paquets i instal·lem-les als tres servidors:
root@cdn:~# apt update
root@cdn:~# apt install nginxEn lloc de la predeterminada, utilitzem la configuració del spoiler següent:
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;
}
}
}A la configuració editem:
- mida_màx — La mida de la memòria cau no supera l'espai disponible en disc
- inactiu — temps d'emmagatzematge de les dades emmagatzemades a la memòria cau a les quals no s'ha accedit
- certificat ssl и clau_certificat_ssl — camins al certificat SSL i als fitxers de claus
- proxy_cache_valid - temps d'emmagatzematge de les dades a la memòria cau
- proxy_pass — l'adreça del servidor original des del qual el CDN sol·licitarà fitxers per a la memòria cau. En el nostre exemple això és sayt.in
Com podeu veure, tot és senzill. L'única dificultat pot sorgir a l'hora d'establir el temps de memòria cau a causa de la similitud de les directives inactiu и proxy_cache_valid. Vegem-los amb el nostre exemple. Això és el que passa quan inactiu=7d и proxy_cache_valid 90d:
- si la sol·licitud no es repeteix en un termini de 7 dies, les dades s'eliminaran de la memòria cau passat aquest període
- si la sol·licitud es repeteix almenys una vegada cada 7 dies, aleshores les dades de la memòria cau es consideraran obsoletes al cap de 90 dies i amb la següent sol·licitud Nginx les actualitzarà, agafant-les del servidor original.
Havent acabat l'edició nginx.conf, torneu a carregar la configuració:
root@cdn:~# service nginx reloadEl nostre CDN està completament llest. Per 15 $/mes. vam rebre punts de presència a tres continents i 3 TB de trànsit: 1 TB a cada localització.
Comprovació del funcionament del CDN
Vegem els pings al nostre CDN des de diferents ubicacions geogràfiques. Qualsevol servei de ping és adequat per a això.
Punt d'inici
Amfitrió
IP
Temps mitjà, ms
Alemanya Berlín
cdn.sayt.in
199.247.18.199
9.6
Països Baixos, Amsterdam
cdn.sayt.in
199.247.18.199
10.1
França París
cdn.sayt.in
199.247.18.199
16.3
Gran Bretanya, Londres
cdn.sayt.in
199.247.18.199
14.9
Canadà, Toronto
cdn.sayt.in
149.28.121.123
16.2
EUA, San Francisco
cdn.sayt.in
149.28.121.123
52.7
EUA, Dallas
cdn.sayt.in
149.28.121.123
23.1
EUA, Chicago
cdn.sayt.in
149.28.121.123
2.6
EUA, Nova York
cdn.sayt.in
149.28.121.123
19.8
Singapur
cdn.sayt.in
157.230.240.216
1.7
Japó Tòquio
cdn.sayt.in
157.230.240.216
74.8
Austràlia, Sydney
cdn.sayt.in
157.230.240.216
95.9
Els resultats són bons. Ara col·loquem una imatge de prova a l'arrel del lloc principal test.jpg i comproveu la seva velocitat de descàrrega mitjançant CDN. Es diu - . El contingut es lliura ràpidament.
Escrivim un petit script per si volem esborrar la memòria cau al punt CDN.
purgar.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 esborrar tota la memòria cau, només cal que executeu-la; podeu esborrar un fitxer separat com aquest:
root@cdn:~# ./purge.sh /test.jpgEn lloc de conclusions
Finalment, vull donar alguns consells útils per tal de passar immediatament per sobre del rastell que una vegada em va fer mal de cap:
- Per augmentar la tolerància a errors de CDN, es recomana configurar el DNS Failover, que ajuda a canviar ràpidament el registre A en cas d'error del servidor. Això es fa al tauler de control de registres DNS del domini
- Els llocs amb un ampli abast geogràfic requeriran, sens dubte, un gran nombre de punts CDN, però no siguem fanàtics. El més probable és que l'usuari no noti una diferència significativa en comparació amb un CDN de pagament si col·loqueu servidors en 6-7 llocs: Europa, Amèrica del Nord (est), Amèrica del Nord (oest), Singapur, Austràlia, Hong Kong o Japó.
- De vegades, els hosts no permeten l'ús de servidors llogats amb finalitats CDN. Per tant, si de sobte decidiu desplegar una xarxa de lliurament de contingut com a servei, no us oblideu de llegir amb antelació les regles del vostre proveïdor d'allotjament específic.
- Explorar imaginar com estan connectats els continents i tenir-ho en compte a l'hora de construir una xarxa de distribució de continguts
- Intenta comprovar als teus servidors. D'aquesta manera podeu veure les regions més properes als punts CDN i configurar GeoDNS més correctament
- Depenent de les tasques, seria útil personalitzar Nginx per a requisits específics de memòria cau i tenint en compte la càrrega del servidor. Els articles sobre la memòria cau Nginx em van ajudar molt amb això: i acceleració del treball sota càrregues pesades: и
Font: www.habr.com