🥇Construyendo y configurando su CDN

Las redes de entrega de contenido (CDN) se utilizan en sitios web y aplicaciones principalmente para acelerar la carga de elementos estáticos. Esto sucede debido al almacenamiento en caché de archivos en servidores CDN ubicados en diferentes regiones geográficas. Al solicitar datos vía CDN, el usuario los recibe del servidor más cercano.

El principio de funcionamiento y funcionalidad de todas las redes de distribución de contenidos es aproximadamente el mismo. Al recibir una solicitud para descargar un archivo, el servidor CDN lo toma una vez del servidor original y se lo entrega al usuario, al mismo tiempo que lo almacena en caché durante un período de tiempo específico. Todas las solicitudes posteriores se responden desde la memoria caché. Todas las CDN tienen opciones para precargar archivos, borrar el caché, establecer la fecha de vencimiento y más.

Sucede que, por una razón u otra, necesita organizar su propia red de distribución de contenido y luego dejar que las instrucciones para montar la próxima bicicleta nos ayuden.

Fuente: Vector infográfico creado por pikisuperstar - www.freepik.com

Cuando necesitas tu propia CDN

Considere los casos en los que tiene sentido ejecutar su propia CDN:

cuando se desea ahorrar dinero y costos de funcionamiento incluso cuando se utilizan CDN económicos como conejitoCDN ascienden a varios cientos de dólares al mes
si queremos obtener un caché permanente o un caché sin servidores ni canales vecinos
Los servicios CDN no tienen puntos de presencia en la región que necesita
cualquier configuración de entrega de contenido especial requerida
Queremos acelerar la entrega de contenido dinámico colocando el servidor de producción más cerca de los usuarios.
Existe la preocupación de que un servicio CDN de terceros pueda recopilar o utilizar ilegalmente información sobre el comportamiento del usuario (hola, servicios que no cumplen con GDPR) o participar en otras actividades ilegales.

En la mayoría de los demás casos, es más apropiado utilizar soluciones ya preparadas.

Qué necesitas para empezar

Es maravilloso si tienes tu propio Sistema Autónomo (AS). Con él, puedes asignar la misma IP a varios servidores y según esta instrucción a nivel de red, dirigir a los usuarios a la más cercana. Vale la pena decir que incluso con el bloque de direcciones /24, es posible construir una red de entrega de contenido. Algunos proveedores de servidores le permiten hacer un anuncio para su uso en todas las regiones disponibles para ellos.

Si no es el feliz propietario de un bloque de direcciones IP, para ejecutar una CDN simple necesitará:

nombre de dominio o subdominio
al menos dos servidores en diferentes regiones. El servidor puede ser dedicado o virtual.
herramienta geoDNS. Con él, el usuario, habiendo accedido al dominio, será dirigido al servidor más cercano.

Registrar un dominio y ordenar servidores

Con el registro de dominio, todo es simple: nos registramos en cualquier zona con cualquier registrador. También puedes usar un subdominio para una CDN, por ejemplo algo como cdn.nombredominio.com. En realidad, en nuestro ejemplo, haremos precisamente eso.

En cuanto a solicitar servidores, conviene alquilarlos en las regiones y países donde se encuentra su audiencia de usuarios. Si el proyecto es intercontinental, entonces conviene elegir proveedores de hosting que ofrezcan servidores en todo el mundo a la vez. Ejemplos: OVH, Leaseweb и 100Tb - para servidores dedicados, Vultr и Digital Ocean — para nube virtual*.

Para nuestra CDN privada, solicitaremos 3 servidores virtuales en diferentes continentes. En Vultr en el servidor para $5/mes obtendremos 25GB SSD lugares y 1 TB de tráfico. Al instalar, seleccione la última versión de Debian. Nuestros servidores:

Frankfurt, dirección IP: 199.247.18.199

Chicago, dirección IP: 149.28.121.123

Singapur, dirección IP: 157.230.240.216

*Vultr y DigitalOcean prometen un crédito de $100 a los usuarios que se registren a través de los enlaces del artículo inmediatamente después de agregar un método de pago. El autor también recibe un pequeño elogio, que ahora es muy significativo para él. Por favor sea comprensivo.

Configurar geoDNS

Para que el usuario sea dirigido al servidor deseado (más cercano) al acceder a un dominio o subdominio CDN, necesitamos un servidor DNS con la función geoDNS.

El principio y funcionamiento de geoDNS es el siguiente:

Especifica la IP del cliente que envió la solicitud DNS o la IP del servidor DNS recursivo que se utiliza al procesar la solicitud del cliente. Estos servidores recursivos suelen ser DNS de proveedores.
La IP del cliente reconoce su país o región. Para ello se utilizan bases de datos GeoIP, de las que existen muchísimas en la actualidad. Hay buenos opciones gratis.
Dependiendo de la ubicación del cliente, le proporciona la dirección IP del servidor CDN más cercano.

El servidor DNS con función geoDNS puede ser montarlo usted mismo, pero es mejor utilizar soluciones listas para usar con una red de servidores DNS en todo el mundo y Anycast de la caja:

Nubes DNS de $9.95/mes, tarifa GeoDNS, por defecto hay un DNS Failover
Ziloré de $25/mes, Conmutación por error de DNS habilitada
Ruta del Amazonas 53 de $35/mes para 50 millones de solicitudes geográficas netas. La conmutación por error de DNS se factura por separado
DNS simplificado de $125/mes, hay 10 conmutaciones por error de DNS
Cloudflare, La función "Geo Steering" está disponible en los planes Enterprise

Al solicitar geoDNS, debe prestar atención a la cantidad de solicitudes incluidas en la tarifa y tener en cuenta que la cantidad real de solicitudes al dominio puede superar las expectativas varias veces. Millones de arañas, escáneres, spammers y otros espíritus malignos trabajan incansablemente.

Casi todos los servicios DNS incluyen un servicio indispensable para construir una CDN: DNS Failover. Con su ayuda, puede configurar el monitoreo del funcionamiento de sus servidores y, en ausencia de signos de vida, reemplazar automáticamente la dirección de un servidor que no funciona por uno de respaldo en las respuestas DNS.

Para construir nuestra CDN, usaremos Nubes, Tarifa GeoDNS.

Agreguemos una nueva zona DNS en su cuenta personal, especificando su dominio. Si estamos creando una CDN en un subdominio y el dominio principal ya está en uso, inmediatamente después de agregar la zona, no olvide agregar los registros DNS en funcionamiento existentes. El siguiente paso es crear varios registros A para el dominio/subdominio CDN, cada uno de los cuales se aplicará a la región que especificamos. Puede especificar continentes o países como regiones; hay subregiones disponibles para EE. UU. y Canadá.

En nuestro caso, la CDN se generará en un subdominio. cdn.sayt.in. Al agregar una zona sayt.en, cree el primer registro A para el subdominio y apunte a toda América del Norte al servidor en Chicago:

Repitamos la acción para otras regiones, recordando crear una entrada para las regiones predeterminadas. Esto es lo que sucede al final:

La última entrada predeterminada en la captura de pantalla significa que todas las regiones no especificadas (y estas son Europa, África, usuarios de Internet por satélite, etc.) se enviarán al servidor en Frankfurt.

Esto completa la configuración básica de DNS. Queda por ir al sitio web del registrador de dominios y reemplazar los NS de dominio actuales por los emitidos por ClouDNS. Y mientras se actualizan las NS, prepararemos los servidores.

Instalación de certificados SSL

Nuestro CDN funcionará a través de HTTPS, por lo que si ya tiene certificados SSL para un dominio o subdominio, cárguelos en todos los servidores, por ejemplo, en el directorio. /etc/ssl/tudominio/

Si no hay certificados, puede obtener uno gratuito de Let's Encrypt. Perfecto para esto ACME Shellscript. El cliente es conveniente y fácil de configurar y, lo más importante, le permite validar un dominio/subdominio mediante DNS a través de la API de ClouDNS.

Instalaremos acme.sh solo en uno de los servidores: el europeo 199.247.18.199, desde donde se copiarán los certificados a todos los demás. Para instalar, ejecute:

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

Durante la instalación del script, se creará un trabajo CRON para una mayor renovación de los certificados sin nuestra participación.

Al emitir un certificado, el dominio se verificará mediante DNS utilizando la API, por lo que en la cuenta personal de ClouDNS en el menú API de revendedor, debe crear una nueva API de usuario y establecer una contraseña para ella. El ID de autenticación resultante con una contraseña se escribirá en el archivo. ~/.acme.sh/dnsapi/dns_cloudns.sh (no confundir con archivo dns_clouddns.sh). Estas son las líneas que deben descomentarse y editarse:

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

Ahora solicitaremos un certificado SSL para cdn.sayt.in

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

En las opciones, para el futuro, hemos especificado un comando para recargar automáticamente la configuración del servidor web después de cada renovación del período de validez del certificado en el futuro.

Todo el proceso de obtención de un certificado puede tardar hasta 2 minutos, no lo interrumpas. Si se produce un error de validación del dominio, intente ejecutar el comando nuevamente. Al final veremos donde se han subido los certificados:

Recuerde estas rutas, deberán especificarse al copiar el certificado a otros servidores, así como en la configuración del servidor web. No prestamos atención al error al recargar las configuraciones de Nginx: no estará en un servidor completamente configurado al actualizar los certificados.

Lo único que nos queda para SSL es copiar el certificado recibido a otros dos servidores manteniendo la ruta a los archivos. Creemos los mismos directorios en cada uno de ellos y hagamos 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/

Para actualizar los certificados periódicamente, cree un trabajo CRON diario en ambos servidores con el comando:

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

En este caso, se debe configurar el acceso al servidor de origen remoto. por clave, es decir. sin introducir una contraseña. No olvides hacerlo.

Instalación y configuración de Nginx

Para servir contenido estático, usaremos Nginx configurado como servidor proxy de almacenamiento en caché. Actualice las listas de paquetes e instálelo en los tres servidores:

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

En lugar de la configuración predeterminada, usamos la configuración del siguiente spoiler:
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;
    }
  }
}

Editar en la configuración:

tamaño máximo — el tamaño del caché, sin exceder el espacio disponible en disco
inactivo - tiempo de almacenamiento de datos almacenados en caché a los que nadie accedió
ssl_certificate и ssl_certificate_key — rutas al certificado SSL y archivos de claves
proxy_cache_valid - tiempo de almacenamiento de datos en caché
contraseña_proxy — dirección del servidor original desde el cual la CDN solicitará archivos para el almacenamiento en caché. En nuestro ejemplo, esto sayt.en

Como puedes ver, todo es sencillo. La dificultad para establecer el tiempo de almacenamiento en caché solo puede surgir debido a la similitud de las directivas. inactivo и proxy_cache_valid. Analicémoslos con nuestro ejemplo. Esto es lo que sucede cuando inactivo=7d и proxy_cache_válido 90d:

Si la solicitud no se repite dentro de los 7 días, los datos se eliminarán del caché después de este período.
Si la solicitud se repite al menos una vez cada 7 días, los datos en el caché se considerarán obsoletos después de 90 días y Nginx los actualizará con la siguiente solicitud, tomándolos del servidor original.

Terminado de editar nginx.conf, recarga la configuración:

root@cdn:~# service nginx reload

Nuestra CDN está lista. Por $15/mes. Recibimos puntos de presencia en tres continentes y 3 TB de tráfico: 1 TB en cada ubicación.

Comprobando el trabajo de CDN

Veamos los pings a nuestra CDN desde diferentes ubicaciones geográficas. Cualquier servicio de ping funcionará para esto.

Punto de lanzamiento
Anfitrión
IP
Tiempo promedio, ms

Alemania Berlín
cdn.sayt.in
199.247.18.199
9.6

Holanda, Amsterdam
cdn.sayt.in
199.247.18.199
10.1

Francia Paris
cdn.sayt.in
199.247.18.199
16.3

Gran Bretaña, 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

Estados Unidos, Nueva York
cdn.sayt.in
149.28.121.123
19.8

Singapur
cdn.sayt.in
157.230.240.216
1.7

japón tokio
cdn.sayt.in
157.230.240.216
74.8

Australia, Sídney
cdn.sayt.in
157.230.240.216
95.9

Los resultados son buenos. Ahora colocaremos una imagen de prueba en la raíz del sitio principal. test.jpg y verifique su velocidad de descarga a través de CDN. Se dice - hecho. El contenido se entrega rápidamente.

Escribamos un pequeño script en caso de que queramos borrar el caché en el punto 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

Para eliminar todo el caché, simplemente ejecútelo; se puede limpiar un archivo separado de esta manera:

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

En lugar de conclusiones

Por último, quiero dar algunos consejos útiles para poder pasar inmediatamente por encima del rastrillo que en su momento me hizo doler la cabeza:

Para aumentar la tolerancia a fallas de la CDN, se recomienda configurar la conmutación por error de DNS, que ayuda a cambiar rápidamente el registro A en caso de una falla del servidor. Esto se hace en el panel de control de registros DNS del dominio.
Los sitios con una amplia cobertura geográfica sin duda requieren una gran cantidad de CDN, pero no seamos fanáticos. Lo más probable es que el usuario no note una diferencia significativa en comparación con una CDN paga si coloca servidores en 6 o 7 ubicaciones: Europa, América del Norte (este), América del Norte (oeste), Singapur, Australia, Hong Kong o Japón.
A veces, los proveedores de alojamiento no permiten el uso de servidores alquilados para fines CDN. Por lo tanto, si de repente decide implementar una red de entrega de contenido como servicio, no olvide leer con anticipación las reglas de un proveedor de alojamiento en particular.
Estudio mapa de comunicaciones submarinasrepresentar cómo están conectados los continentes y tener esto en cuenta al construir una red de entrega de contenido
Intenta comprobar pings desde diferentes lugares a sus servidores. De esta manera podrás ver las regiones más cercanas a los puntos CDN y configurar GeoDNS más correctamente
Dependiendo de las tareas, será útil ajustar Nginx para requisitos de almacenamiento en caché específicos y teniendo en cuenta la carga en el servidor. Los artículos sobre el caché de Nginx me ayudaron mucho en esto: aquí y aceleración del trabajo bajo cargas pesadas: aquí и aquí

Fuente: habr.com