ProHoster > Blog > Administración > Creando e configurando o teu CDN

Creando e configurando o teu CDN

As redes de entrega de contidos (CDN) úsanse en sitios web e aplicacións principalmente para acelerar a carga de elementos estáticos. Isto ocorre debido ao almacenamento en caché de ficheiros en servidores CDN situados en diferentes rexións xeográficas. Ao solicitar datos a través da CDN, o usuario recíbeos do servidor máis próximo.

O principio de funcionamento e funcionalidade de todas as redes de distribución de contido é aproximadamente o mesmo. Despois de recibir unha solicitude para descargar un ficheiro, o servidor CDN tómao unha vez do servidor orixinal e entrégao ao usuario, ao mesmo tempo que o almacena na caché durante un período de tempo determinado. Todas as solicitudes posteriores son respondidas desde a caché. Todos os CDN teñen opcións para cargar previamente ficheiros, borrar a caché, establecer a data de caducidade e moito máis.

Acontece que, por un motivo ou outro, cómpre organizar a súa propia rede de entrega de contido e, a continuación, deixar que as instrucións para montar a seguinte bicicleta sexan de axuda para nós.

Creando e configurando o teu CDN
Fonte: Vector infográfico creado por pikisuperstar - www.freepik.com

Cando necesites o teu propio CDN

Considere os casos nos que executar o seu propio CDN ten sentido:

  • cando hai un desexo de aforrar diñeiro e custos de funcionamento mesmo cando se usan CDNs de baixo custo como BunnyCDN ascende a varios centos de dólares ao mes
  • se queremos obter unha caché permanente ou unha caché sen servidor e canle veciños
  • Os servizos CDN non teñen puntos de presenza na rexión que necesitas
  • calquera configuración especial de entrega de contido necesaria
  • queremos acelerar a entrega de contido dinámico colocando o servidor de produción máis preto dos usuarios
  • existe a preocupación de que un servizo CDN de terceiros poida recompilar ou utilizar información sobre o comportamento dos usuarios de xeito ilegal (servizos non conformes co GDPR) ou participar noutras actividades ilegais

Na maioría dos outros casos, é máis apropiado utilizar solucións xa existentes.

Que necesitas para comezar

É marabilloso se tes o teu propio Sistema Autónomo (AS). Con el, pode asignar a mesma IP a varios servidores e segundo esta instrución a nivel de rede, dirixe aos usuarios ao máis próximo. Paga a pena dicir que mesmo co bloque de enderezos /24, é posible construír unha rede de entrega de contido. Algúns provedores de servidor permítenche facer un anuncio para o seu uso en todas as rexións dispoñibles.

Se non es un feliz propietario dun bloque de enderezos IP, entón para executar un sinxelo CDN necesitará:

  • nome de dominio ou subdominio
  • polo menos dous servidores en diferentes rexións. O servidor pode ser dedicado ou virtual
  • ferramenta geoDNS. Con ela, o usuario, unha vez dirixido o dominio, dirixirase ao servidor máis próximo

Rexistra un dominio e solicita servidores

Co rexistro de dominio, todo é sinxelo: rexistrámonos en calquera zona con calquera rexistrador. Tamén podes usar un subdominio para un CDN, por exemplo algo así cdn.nome de dominio.com. En realidade, no noso exemplo, faremos exactamente iso.

En canto aos servidores de pedido, deberían alugalos nas rexións e países onde se atopa o seu público de usuarios. Se o proxecto é intercontinental, entón é conveniente escoller provedores de hospedaxe que ofrezan servidores en todo o mundo á vez. Exemplos: OVH, aluguer web и 100 TB - para servidores dedicados, Vultr и DigitalOcean — para a nube virtual*.

Para o noso CDN privado, pediremos 3 servidores virtuais en diferentes continentes. Ás Vultr no servidor para $5/mes conseguiremos 25GB SSD lugares e 1 TB de tráfico. Ao instalar, seleccione a versión máis recente de Debian. Os nosos servidores:

Creando e configurando o teu CDN Frankfurt, IP: 199.247.18.199

Creando e configurando o teu CDN Chicago, IP: 149.28.121.123

Creando e configurando o teu CDN Singapur, IP: 157.230.240.216

*Vultr e DigitalOcean prometen un crédito de 100 dólares aos usuarios que se rexistren a través das ligazóns do artigo inmediatamente despois de engadir un método de pago. O autor tamén recibe un pequeno eloxio deste, que agora é moi significativo para el. Por favor, sexa comprensivo.

Configurando geoDNS

Para que o usuario sexa dirixido ao servidor desexado (máis próximo) ao acceder a un dominio ou subdominio CDN, necesitamos un servidor DNS coa función geoDNS.

O principio e funcionamento do geoDNS é o seguinte:

  1. Especifica a IP do cliente que enviou a solicitude de DNS ou a IP do servidor DNS recursivo que se utiliza ao procesar a solicitude do cliente. Estes servidores recursivos adoitan ser DNS de provedores.
  2. A IP do cliente recoñece o seu país ou rexión. Para iso utilízanse bases de datos GeoIP, das que hoxe hai moitas. Hai boas opcións gratuítas.
  3. Dependendo da localización do cliente, dálle o enderezo IP do servidor CDN máis próximo.

O servidor DNS con función geoDNS pode ser montar por si mesmo, pero é mellor usar solucións preparadas cunha rede de servidores DNS en todo o mundo e Anycast da caixa:

  • CloudDNS de $9.95/mes, tarifa GeoDNS, por defecto hai un Failover DNS
  • Zilore de $25/mes, Failover DNS activado
  • Ruta Amazonas 53 de $35/mes para un neto de 50 millóns de solicitudes xeográficas. A conmutación por falla de DNS facturase por separado
  • DNS Fácil de $125/mes, hai 10 Failovers de DNS
  • Cloudflare, A función "Geo Steering" está dispoñible nos plans Enterprise

Ao solicitar geoDNS, debes prestar atención ao número de solicitudes incluídas na tarifa e ter en conta que o número real de solicitudes ao dominio pode superar varias veces as expectativas. Millóns de arañas, escáneres, spammers e outros espíritos malignos traballan incansablemente.

Case todos os servizos DNS inclúen un servizo indispensable para construír un CDN - DNS Failover. Coa súa axuda, pode configurar o seguimento do funcionamento dos seus servidores e, en ausencia de signos de vida, substituír automaticamente o enderezo dun servidor que non funciona por un de copia de seguridade nas respostas DNS.

Para construír o noso CDN, utilizaremos CloudDNS, Tarifa GeoDNS.

Engademos unha nova zona DNS na túa conta persoal, especificando o teu dominio. Se estamos a construír un CDN nun subdominio e o dominio principal xa está en uso, inmediatamente despois de engadir a zona, non esqueza engadir os rexistros DNS de traballo existentes. O seguinte paso é crear varios rexistros A para o dominio/subdominio CDN, cada un dos cales se aplicará á rexión que especificamos. Podes especificar continentes ou países como rexións, as subrexións están dispoñibles para os EUA e Canadá.

No noso caso, o CDN crearase nun subdominio cdn.sayt.in. Engadindo unha zona dixo.en, crea o primeiro rexistro A para o subdominio e apunta toda América do Norte ao servidor de Chicago:

Creando e configurando o teu CDN
Repetimos a acción para outras rexións, recordando crear unha entrada para as rexións predeterminadas. Isto é o que pasa ao final:

Creando e configurando o teu CDN

A última entrada predeterminada na captura de pantalla significa que todas as rexións non especificadas (e estas son Europa, África, usuarios de Internet vía satélite, etc.) enviaranse ao servidor de Frankfurt.

Isto completa a configuración básica de DNS. Queda por ir ao sitio web do rexistrador de dominios e substituír os NS de dominio actuais polos emitidos por ClouDNS. E mentres se actualizarán os NS, prepararemos os servidores.

Instalación de certificados SSL

O noso CDN funcionará a través de HTTPS, polo que se xa tes certificados SSL para un dominio ou subdominio, cárgaos a todos os servidores, por exemplo, no directorio /etc/ssl/yourdomain/

Se non hai certificados, podes obter un gratuíto de Let's Encrypt. Perfecto para isto ACME Shellscript. O cliente é cómodo e fácil de configurar e, o máis importante, permítelle validar un dominio/subdominio mediante DNS a través da API de ClouDNS.

Instalaremos acme.sh só nun dos servidores: o 199.247.18.199 europeo, do que se copiarán os certificados a todos os demais. Para instalar, executa:

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

Durante a instalación do script, crearase un traballo CRON para a renovación dos certificados sen a nosa participación.

Ao emitir un certificado, o dominio comprobarase mediante DNS mediante a API, polo que na conta persoal de ClouDNS no menú API de revendedores, cómpre crear unha nova API de usuario e establecer un contrasinal para ela. O identificador de autenticación resultante cun contrasinal escribirase no ficheiro ~/.acme.sh/dnsapi/dns_cloudns.sh (non se debe confundir con ficheiro dns_clouddns.sh). Aquí están as liñas que deben ser eliminadas e editadas:

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

Agora solicitaremos un certificado SSL para cdn.sayt.in

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

Nas opcións, para o futuro, especificamos un comando para volver cargar automaticamente a configuración do servidor web despois de cada renovación do período de validez do certificado no futuro.

Todo o proceso de obtención dun certificado pode levar ata 2 minutos, non o interrompa. Se se produce un erro de validación de dominio, tente executar o comando de novo. Ao final veremos onde se cargaron os certificados:

Creando e configurando o teu CDN

Lembra estes camiños, deberán especificalos ao copiar o certificado noutros servidores, así como na configuración do servidor web. Non prestamos atención ao erro de recargar as configuracións de Nginx: non estará nun servidor totalmente configurado ao actualizar os certificados.

Todo o que nos queda para SSL é copiar o certificado recibido noutros dous servidores mantendo o camiño aos ficheiros. Imos crear os mesmos directorios en cada un deles e facer unha 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/

Para actualizar os certificados regularmente, cree un traballo CRON diario nos dous servidores co comando:

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

Neste caso, o acceso ao servidor de orixe remoto debe estar configurado por chave, é dicir. sen introducir un contrasinal. Non esquezas facelo.

Instalación e configuración de Nginx

Para servir contido estático, usaremos Nginx configurado como servidor proxy de caché. Actualiza as listas de paquetes e instálaas nos tres servidores:

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

En lugar do predeterminado, usamos a configuración do spoiler a continuación:
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;
    }
  }
}

Edita na configuración:

  • tamaño_máx — o tamaño da caché, sen exceder o espazo dispoñible no disco
  • inactivo - tempo de almacenamento dos datos en caché aos que ninguén accedeu
  • certificado_ssl и clave_certificado_ssl — camiños aos ficheiros de claves e certificados SSL
  • proxy_cache_valid - tempo de almacenamento de datos en caché
  • pase_proxy — enderezo do servidor orixinal desde o que a CDN solicitará ficheiros para almacenar na caché. No noso exemplo, isto dixo.en

Como podes ver, todo é sinxelo. Só pode xurdir dificultade para establecer o tempo de almacenamento na caché debido á semellanza das directivas inactivo и proxy_cache_valid. Analizámolos co noso exemplo. Aquí está o que ocorre cando inactivo=7d и proxy_cache_valid 90d:

  • se a solicitude non se repite nun prazo de 7 días, os datos eliminaranse da caché despois deste período
  • se a solicitude se repite polo menos unha vez cada 7 días, entón os datos da caché consideraranse obsoletos despois de 90 días e Nginx actualizarao coa seguinte solicitude, tomándoo do servidor orixinal.

Rematou de editar nginx.conf, recarga a configuración:

root@cdn:~# service nginx reload

O noso CDN está listo. Por $15/mes. recibimos puntos de presenza en tres continentes e 3 TB de tráfico: 1 TB en cada localización.

Comprobación do traballo da CDN

Vexamos os pings ao noso CDN desde diferentes localizacións xeográficas. Calquera servizo de ping funcionará para iso.

Punto de lanzamento
Anfitrión
IP
Tempo medio, ms

Alemaña Berlín
cdn.sayt.in
199.247.18.199
9.6

Holanda, Amsterdam
cdn.sayt.in
199.247.18.199
10.1

Francia París
cdn.sayt.in
199.247.18.199
16.3

Reino Unido, Londres
cdn.sayt.in
199.247.18.199
14.9

Canadá, Toronto
cdn.sayt.in
149.28.121.123
16.2

Estados Unidos, San Francisco
cdn.sayt.in
149.28.121.123
52.7

Estados Unidos, Dallas
cdn.sayt.in
149.28.121.123
23.1

Estados Unidos, 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

Xapón Tokio
cdn.sayt.in
157.230.240.216
74.8

Australia, Sidney
cdn.sayt.in
157.230.240.216
95.9

Os resultados son bos. Agora colocaremos unha imaxe de proba na raíz do sitio principal proba.jpg e comprobe a súa velocidade de descarga a través da CDN. dise - feito. O contido entrégase rapidamente.

Escribamos un pequeno script por se queremos borrar a caché do punto 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

Para eliminar a caché completa, só tes que executalo, pódese limpar un ficheiro separado como este:

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

En vez de conclusións

Por último, quero dar algúns consellos útiles para pasar inmediatamente por riba do anciño que me doía a cabeza nese momento:

  • Para aumentar a tolerancia a fallos do CDN, recoméndase configurar DNS Failover, o que axuda a cambiar rapidamente o rexistro A en caso de avaría do servidor. Isto faise nos rexistros DNS do panel de control do dominio.
  • Os sitios con ampla cobertura xeográfica requiren sen dúbida un gran número de CDN, pero non sexamos fanáticos. O máis probable é que o usuario non note unha diferenza significativa en comparación cun CDN de pago se coloca servidores en 6-7 localizacións: Europa, América do Norte (leste), América do Norte (oeste), Singapur, Australia, Hong Kong ou Xapón.
  • Ás veces, os hosters non permiten o uso de servidores alugados para fins de CDN. Polo tanto, se de súpeto decides implantar unha rede de entrega de contido como servizo, non esquezas ler as regras dun provedor de hospedaxe en particular con antelación.
  • Explorar mapa de comunicacións submarinasrepresentar como están conectados os continentes e telo en conta á hora de construír unha rede de distribución de contidos
  • Tenta comprobar pings de diferentes lugares aos teus servidores. Deste xeito podes ver as rexións máis próximas aos puntos CDN e configurar GeoDNS de forma máis correcta
  • Dependendo das tarefas, será útil axustar Nginx para requisitos específicos de caché e tendo en conta a carga do servidor. Os artigos sobre a caché de Nginx axudáronme moito nisto: aquí e aceleración do traballo baixo cargas pesadas: aquí и aquí

Fonte: www.habr.com