Las redes de entrega de contenido (CDN) se utilizan en sitios web y aplicaciones principalmente para acelerar la carga de elementos estáticos. Esto se logra gracias a la caché de archivos en servidores de CDN ubicados en diferentes regiones geográficas. Al solicitar datos a través de la CDN, el usuario los recibe del servidor más cercano.
El principio de funcionamiento y la funcionalidad de todas las redes de entrega de contenido son aproximadamente los mismos. Al recibir una solicitud para cargar un archivo, el servidor de la CDN toma una vez el archivo del servidor original y lo entrega al usuario, al mismo tiempo que lo almacena en la caché por un período de tiempo establecido. En todas las solicitudes posteriores, la respuesta se entrega desde la caché. Todas las CDN tienen opciones de carga previa de archivos, limpieza de caché, configuración del tiempo de almacenamiento y mucho más.
A veces, por diversas razones, es necesario organizar una red de entrega de contenido propia, y entonces, que nos sirva esta guía para construir otra bicicleta.
Fuente:
Cuándo se necesita una CDN propia
Consideremos los casos en los que tiene sentido lanzar una CDN propia:
- cuando hay un deseo de ahorrar, y los gastos actuales incluso al utilizar CDN económicos como son de varios cientos de dólares al mes
- si queremos obtener una caché permanente o caché sin vecinos en el servidor y canal
- no hay puntos de presencia de servicios CDN en la región que necesita
- se requieren configuraciones especiales para la entrega de contenido
- queremos acelerar la entrega de contenido dinámico, ubicando servidores de producción más cerca de los usuarios
- hay preocupación de que un servicio de CDN externo pueda recopilar o utilizar indebidamente información sobre el comportamiento de los usuarios (hola servicios que no cumplen con GDPR) o realizar otras acciones indebidas
En la mayoría de los demás casos, es más sensato usar soluciones existentes.
Qué se necesita para lanzar
Es genial si tienes tu propio sistema autónomo (AS). Con él puedes asignar la misma IP a varios servidores y dirigir a los usuarios a la más cercana a nivel de red. Cabe mencionar que incluso con un bloque de direcciones /24, es posible construir una red de entrega de contenido. Algunos proveedores de servidores permiten hacer un anuncio para su uso en todas las regiones disponibles.
Si no tiene un bloque de direcciones IP, necesitará lo siguiente para lanzar una CDN simple:
- un nombre de dominio o subdominio
- un mínimo de dos servidores en diferentes regiones. El servidor puede ser físico o virtual
- una herramienta geoDNS. Con ella, el usuario, al solicitar el dominio, será redirigido al servidor más cercano
Registramos el dominio y pedimos los servidores
La registración del dominio es sencilla: se registra en cualquier zona con cualquier registrador. También se puede usar un subdominio para la CDN, como por ejemplo cdn.elnombredeldominio.com. En nuestro ejemplo, así lo haremos.
En cuanto al pedido de servidores, estos deben ser alquilados en las regiones y países donde se encuentra su audiencia. Si el proyecto es intercontinental, es conveniente elegir proveedores de hosting que ofrezcan servidores en todo el mundo. Ejemplos: , y — para servidores dedicados, y — para nubes virtuales*.
Para nuestra CDN privada, pediremos 3 servidores virtuales en diferentes continentes. En Vultr el servidor a $5/mes obtendremos 25GB SSD espacio y 1TB de tráfico. Al instalar, elegiremos el último Debian. Nuestros servidores:
Fráncfort, ip: 199.247.18.199
Chicago, ip: 149.28.121.123
Singapur, ip: 157.230.240.216
* Vultr y DigitalOcean prometen un crédito de $100 a los usuarios registrados a través de los enlaces en este artículo, justo después de agregar un método de pago. El autor también recibe un pequeño cumplido por esto, lo cual es importante para él ahora. Por favor, tenga en cuenta esto.
Configuramos geoDNS
Para que el usuario sea dirigido al servidor adecuado (el más cercano) al solicitar el dominio o subdominio de la CDN, necesitaremos un servidor DNS con la función geoDNS.
El principio y orden de funcionamiento de geoDNS es el siguiente:
- Determina la IP del cliente que envió la solicitud DNS o la IP del servidor DNS recursivo que se utiliza para procesar la solicitud del cliente. Estos servidores recursivos suelen ser DNS de los proveedores.
- Por la IP del cliente, determina su país o región. Para ello se utilizan bases de datos GeoIP, que hoy en día son numerosas. Hay buenas .
- Dependiendo de la ubicación del cliente, le devuelve la IP del servidor CDN más cercano.
Un servidor DNS con función geoDNS se puede , pero es mejor utilizar soluciones listas con una red de servidores DNS en todo el mundo y de fábrica:
- desde $9.95/mes, tarifa GeoDNS, por defecto hay una DNS Failover
- desde $25/mes, incluye DNS Failover
- desde $35/mes por 50M de geo-peticiones. DNS Failover se cobra aparte
- desde $125/mes, hay 10 DNS Failover
- , la función 'Geo Steering' está disponible en tarifas Enterprise
Al solicitar geoDNS, es importante prestar atención al número de peticiones incluidas en la tarifa y considerar que el número real de accesos al dominio puede superar las expectativas en gran medida. Millones de arañas, escáneres, spammers y otras malas prácticas trabajan sin descanso.
Prácticamente todos los servicios DNS incluyen en su costo un servicio indispensable para la creación de CDN — DNS Failover. Con ello se puede configurar la monitorización del funcionamiento de los servidores y, en ausencia de señales de vida, reemplazar automáticamente en las respuestas DNS la dirección del servidor que no está operando por una de respaldo.
Para construir nuestro CDN, utilizaremos , tarifa GeoDNS.
Agregaremos una nueva zona DNS en el panel de control personal, especificando nuestro dominio. Si vamos a construir el CDN en un subdominio y el dominio principal ya está en uso, no olvidemos agregar los registros DNS existentes inmediatamente después de añadir la zona. El siguiente paso es crear varias A-registros para el dominio/subdominio CDN, cada uno de los cuales se aplicará para la región que defina. Como regiones se pueden especificar continentes o países, para EE. UU. y Canadá hay subregiones disponibles.
En nuestro caso, el CDN se levantará en el subdominio cdn.sayt.in. Al agregar la zona sayt.in, crearemos el primer A-registro para el subdominio y dirigiremos toda América del Norte al servidor en Chicago:
Repetiremos la acción para otras regiones, sin olvidar crear un registro para las regiones por defecto. Así quedará al final:
El último registro por defecto en la captura de pantalla significa que todas las regiones no especificadas (como Europa, África, usuarios de internet satelital, etc.) serán dirigidas al servidor en Fráncfort.
Con esto, la configuración básica de DNS está completa. Ahora solo queda ingresar al sitio del registrador de dominios y reemplazar los NS actuales del dominio por los que proporcionó ClouDNS. Mientras los NS se actualizan, prepararemos los servidores.
Instalación de certificados SSL
Nuestro CDN funcionará por HTTPS, por lo tanto, si ya tienes certificados SSL para el dominio o subdominio, cárgalos en todos los servidores, por ejemplo, en el directorio /etc/ssl/вашдомен/
Si no tienes certificados, puedes obtener uno gratuito de Let’s Encrypt. Para ello, es ideal utilizar . El cliente es conveniente y fácil de configurar, y lo más importante: permite la validación del dominio/subdominio a través de DNS mediante la API de ClouDNS.
Instalaremos acme.sh solo en uno de los servidores: el europeo 199.247.18.199, desde el cual los certificados se copiarán a todos los demás. Para la instalación, ejecutaremos:
root@cdn:~# wget -O - https://get.acme.sh | bash; source ~/.bashrcDurante la instalación del script, se creará una tarea CRON para la actualización futura de los certificados sin nuestra intervención.
La verificación del dominio al emitir el certificado se realizará a través de DNS utilizando la API, así que en el panel de ClouDNS en el menú Reseller API debemos crear un nuevo usuario API y establecer una contraseña para él. El auth-id obtenido junto con la contraseña se registrará en el archivo ~/.acme.sh/dnsapi/dns_cloudns.sh (no confundir con el archivo dns_clouddns.sh). Estas son las líneas que deben descomentarse y editarse:
CLOUDNS_AUTH_ID=
CLOUDNS_AUTH_PASSWORD=""
Ahora solicitaremos la obtención del certificado SSL para cdn.sayt.in
root@cdn:~# acme.sh --issue --dns dns_cloudns -d cdn.sayt.in --reloadcmd "service nginx reload"En los parámetros, para el futuro, hemos indicado el comando para la recarga automática de la configuración del servidor web después de cada actualización de la validez del certificado en el futuro.
Todo el proceso de obtención del certificado puede tardar hasta 2 minutos, no lo interrumpa. Si hay un error en la validación del dominio, intente ejecutar el comando nuevamente. Al final, veremos dónde se han cargado los certificados:
Recordaremos estas rutas, que deberán ser especificadas al copiar el certificado a otros servidores, así como en la configuración del servidor web. No prestemos atención al error de recarga de las configuraciones de Nginx, ya que en un servidor completamente configurado no habrá ninguno al actualizar los certificados.
Todo lo que nos queda por hacer con el SSL es copiar el certificado obtenido en otros dos servidores manteniendo la ruta a los archivos. Crearemos en cada uno de ellos los mismos directorios y haremos 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/
Para que la actualización de los certificados sea regular, crearemos en ambos servidores una tarea CRON diaria con el comando:
scp -r root@199.247.18.199:/root/.acme.sh/cdn.sayt.in/* /root/.acme.sh/cdn.sayt.in/ && service nginx reload
Con esto, el acceso al servidor remoto fuente debe estar configurado , es decir, sin ingresar una contraseña. No olvide hacer esto.
Instalación y configuración de Nginx
Para servir contenido estático, utilizaremos Nginx, configurado en modo proxy de caché. Actualizaremos las listas de paquetes e instalaremos en los tres servidores:
root@cdn:~# apt update
root@cdn:~# apt install nginxUsaremos la configuración alternativa en el 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;
}
}
}En la configuración editaremos:
- max_size — el tamaño de la caché, que no excede el espacio disponible en disco
- inactive — el tiempo durante el cual se almacenan los datos en caché que no han sido accedidos
- ssl_certificate y ssl_certificate_key — rutas a los archivos del certificado SSL y la clave
- proxy_cache_valid — el tiempo durante el cual se almacenan los datos en caché
- proxy_pass — la dirección del servidor original, del cual el CDN solicitará archivos para almacenamiento en caché. En nuestro ejemplo, es sayt.in
Como vemos, es bastante sencillo. La dificultad puede surgir al configurar el tiempo de caché debido a la similitud de las directivas inactive y proxy_cache_valid. Los desglosaremos en nuestro ejemplo. Esto es lo que ocurre con inactive=7d y proxy_cache_valid 90d:
- si no se repite la solicitud en un período de 7 días, los datos se eliminarán de la caché una vez que transcurra ese tiempo
- si la solicitud se repite al menos una vez cada 7 días, los datos en la caché se considerarán obsoletos después de 90 días y en la próxima solicitud Nginx los actualizará, tomándolos del servidor original
Terminando de editar nginx.conf, recargaremos la configuración:
root@cdn:~# service nginx reloadNuestro CDN está completamente listo. Por $15/mes, obtuvimos puntos de presencia en tres continentes y 3 TB de tráfico: 1 TB en cada ubicación.
Verificamos el funcionamiento del CDN
Observemos los pings a nuestro CDN desde diferentes ubicaciones geográficas. Cualquier servicio de pings funcionará.
Punto de inicio
Host
IP
Tiempo promedio, ms
Alemania, Berlín
cdn.sayt.in
199.247.18.199
9.6
Países Bajos, Ámsterdam
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
EE.UU., San Francisco
cdn.sayt.in
149.28.121.123
52.7
EE.UU., Dallas
cdn.sayt.in
149.28.121.123
23.1
EE.UU., Chicago
cdn.sayt.in
149.28.121.123
2.6
EE. UU., 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 verificaremos la velocidad de carga a través de CDN. Se dijo, — . El contenido se entrega rápidamente.
Escribiremos un pequeño script por si decidimos limpiar la caché en el punto de 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
Para eliminar toda la caché, simplemente ejecuta esto; un archivo separado se puede limpiar así:
root@cdn:~# ./purge.sh /test.jpgEn lugar de conclusiones
Por último, quiero ofrecer algunos consejos útiles para saltar de inmediato sobre los obstáculos que en su momento me hicieron doler la cabeza:
- Para aumentar la resistencia de la CDN, se recomienda configurar DNS Failover, que ayuda a cambiar rápidamente el registro A en caso de falla del servidor. Esto se hace en el panel de control de los registros DNS del dominio
- Los sitios con un amplio alcance geográfico requieren sin duda un gran número de puntos de CDN, pero hagámoslo sin exagerar. Es probable que el usuario no note una diferencia significativa en comparación con un CDN pago si colocas servidores en 6-7 lugares: Europa, América del Norte (este), América del Norte (oeste), Singapur, Australia, Hong Kong o Japón
- A veces, los proveedores de hosting no permiten utilizar los servidores arrendados para fines de CDN. Por lo tanto, si decides desplegar una red de entrega de contenido como servicio, no olvides leer las reglas del proveedor de hosting específico con antelación
- Estudia , para comprender cómo se conectan los continentes y tenerlo en cuenta al construir la red de entrega de contenido
- Intenta verificar hacia tus servidores. Así podrás ver las regiones más cercanas a los puntos de CDN y ajustar mejor el GeoDNS
- Dependiendo de las tareas, será útil ajustar Nginx según los requisitos específicos de caché y la carga en el servidor. En esto me ayudaron mucho los artículos sobre la caché de Nginx — y la aceleración del rendimiento bajo altas cargas: y
Fuente: habr.com
