Fuente de la imagen: Vector de infografía creado por pikisuperstar — www.freepik.com

Las redes de distribución de contenido (CDN) generalmente son utilizadas por sitios y aplicaciones para acelerar la carga de elementos estáticos. Esto se logra mediante el almacenamiento en caché de archivos en servidores de CDN ubicados en varias regiones del mundo. Una vez solicitados los datos a través de CDN, el usuario los recibe del servidor más cercano.

Los principios subyacentes detrás de las CDN y su funcionalidad son aproximadamente los mismos para todos ellos. Habiendo recibido una solicitud de un archivo, un servidor CDN lo toma una vez del servidor de origen y luego lo transfiere al usuario y almacena en caché una copia del mismo durante un período de tiempo. Otras solicitudes de datos se gestionan utilizando la caché. Todas las CDN tienen opciones para la carga previa de archivos, el borrado de caché, los tiempos de retención de caché y mucho más.

A veces, por diversas razones, uno puede encontrarse en la necesidad de construir su propia CDN, por lo que presentamos la siguiente guía sobre cómo realizarla.

¿Cuándo necesita su propia CDN?

Echemos un vistazo a las situaciones en las que podría necesitar crear su propia CDN:

• cuando intenta ahorrar dinero e incluso soluciones asequibles como BunnyCDN terminan costándole cientos de dólares al mes
• cuando desea obtener caché permanente o necesita ancho de banda y recursos garantizados
• las CDN existentes no tienen PoPs en su región de destino
• necesita ajustes especiales de entrega de contenido
• la entrega del contenido dinámico al servirlo más cerca de los usuarios
• le preocupa que las CDN de terceros puedan recopilar y utilizar datos de usuario de forma ilegal (hola, servidores que no son Cumplir con el RGPD) o participar en otras actividades ilícitas

En la mayoría de los demás casos, es más viable usar soluciones prefabricadas existentes.

Vamos a crear nuestra propia CDN

Para crear incluso una red de entrega de contenido simple, necesita lo siguiente:

• nombre de dominio o subdominio
• un mínimo de dos servidores en regiones diferentes. Los servidores pueden ser dedicados o virtuales
• herramienta GeoDNS. Con él, un usuario que envía una solicitud al dominio será dirigido al servidor más cercano

Registrar un dominio y ordenar servidores

Registrar un nombre de dominio es fácil, simplemente regístrelo en cualquier zona de dominio que prefiera. Para CDN, también puedes usar un subdominio, como cdn.domainname.com. Este es el caso del siguiente ejemplo.

Cuando se trata de servidores, debe alquilarlos en las regiones y países donde se encuentra su público objetivo. Si su proyecto es intercontinental, es conveniente seleccionar entre proveedores de alojamiento que ofrecen servidores en todo el mundo, como OVH, Leaseweb y 100 Tb (para servidores dedicados), o Vultr y DigitalOcean (para servidores virtuales y en la nube).

Para nuestra CDN privada, pidamos tres servidores virtuales en diferentes continentes. Vultr nos ofrece 25 GB de espacio SSD y 1 TB de tráfico por 5 5 / mes. Durante la instalación, seleccione la versión más reciente de Debian. Aquí están nuestros servidores:

• Frankfurt, ip: 199.247.18.199

• Chicago, ip: 149.28.121.123

• Singapur, pi: 157.230.240.216

Configurar GeoDNS

Para garantizar que los clientes se dirijan a los servidores adecuados (más cercanos) al enviar solicitudes a nuestro dominio o subdominio, necesitaremos un servidor DNS con funcionalidad GeoDNS.

Así es como funciona GeoDNS:

1. Obtiene la IP del cliente (si envió la solicitud DNS) o la IP del servidor DNS recursivo que se utiliza para procesar la solicitud. En términos generales, estos servidores recursivos suelen ser los DNSs de los proveedores de Internet.
2. Por la IP del cliente identifica su país o región. Esta operación requiere el uso de la base de datos GeoIP, que no escasean. Incluso hay opciones decentes gratuitas.
3. Dependiendo de la ubicación del cliente, GeoDNS le devuelve la dirección IP del servidor CDN más cercano.

Un servidor DNS con funcionalidad GeoDNS es algo que puede construir usted mismo, pero es mejor usar soluciones listas para usar que tengan servidores alrededor del mundo y una opción de transmisión Anycast lista para usar:

• Nubes, desde 9 9.95 / mes, paquete GeoDNS, se proporciona una conmutación por error de DNS de forma predeterminada
• Zilore, desde $25 / mes, incluye la conmutación por error de DNS
• Amazon Route 53, desde 3 35/mes para 50 millones de solicitudes geográficas. La conmutación por error de DNS tiene un precio por separado
• DNS Made Easy, desde $125 / mes, con 10 Conmutación por error de DNS
• Cloudflare, la funcionalidad de dirección geográfica se proporciona en paquetes empresariales

Al solicitar GeoDNS, debe prestar atención al número de solicitudes incluidas en el paquete y tener en cuenta que el número de solicitudes reales podría superar en gran medida sus expectativas. Hay millones de rastreadores web, escáneres, spammers y otros demonios trabajando en un momento dado.

Casi todos los servicios DNS incluyen una característica útil para la creación de CDN: la conmutación por error de DNS. Con él, puede configurar la supervisión de actividades para que, si un servidor se cae, el sistema redirija automáticamente a los clientes a servidores que funcionen.

Para nuestra CDN, usemos ClouDNS y su paquete GeoDNS.

En el perfil, agregue una nueva zona DNS y especifique su nombre de dominio. Si está utilizando subdominio y el dominio principal está en uso, no olvide agregar los registros DNS existentes inmediatamente después de agregar la zona. El siguiente paso es crear varios registros A para el dominio/subdominio de CDN, cada uno de los cuales se utilizará para la región especificada. Puede designar continentes o países como regiones, y hay opciones de subregiones disponibles para EE.UU. y Canadá.

En nuestro ejemplo, la CDN funcionará en el cdn.sayt.in subdominio. Habiendo añadido el sayt.in zona, cree el primer registro A para el subdominio y dirija todos los clientes de NA al servidor de Chicago:

Repita este paso para las otras regiones y no olvide crear un registro para las regiones predeterminadas. Así es como se ve el resultado final:

El último registro predeterminado significa solicitudes de todas las regiones no especificadas (Europa, África, usuarios de Internet por satélite, etc.).) deben ser dirigidas al servidor de Frankfurt.

Esto concluye la configuración básica de DNS. Todo lo que queda es ir al sitio web del registrador y reemplazar los servidores de nombres actuales con los proporcionados por ClouDNS. Mientras se actualizan, configuraremos los servidores.

Instalación de certificados SSL

Nuestro CDN funcionará utilizando HTTPS, por lo que si ya tiene certificados SSL para el dominio o el subdominio, cárguelos a todos los servidores, por ejemplo, al directorio /etc/ssl/yourdomain/.

Si no tiene ningún certificado, puede obtenerlo de forma gratuita en Let’s Encrypt. El script de shell ACME es una gran opción. Tiene un cliente fácil de usar y, lo que es más importante, permite realizar la validación del dominio/subdominio a través de DNS utilizando API de ClouDNS.

Instalaremos acme.sh en un solo servidor, el europeo (199.247.18.199), y desde él, los certificados se copiarán a todos los demás. Para instalarlo, ejecute el siguiente comando:

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

Durante la instalación se creará una tarea CRON para la actualización automática de los certificados.

La verificación del dominio al emitir el certificado se realizará a través de DNS mediante API, por lo que en el perfil de ClouDNS, en API de revendedor, cree un nuevo usuario de API y especifique una contraseña para él. Introduzca el id de autenticación resultante junto con la contraseña en el siguiente archivo: ~/.acme.sh/dnsapi/dns_cloudns.sh (no debe confundirse con dns_clouddns.sh). Aquí están las líneas que necesita para descomentar y editar:

CLOUDNS_AUTH_ID=<auth-id>CLOUDNS_AUTH_PASSWORD="<password>"

Ahora, vamos a solicitar la emisión del certificado SSL para cdn.sayt.en

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

Para uso futuro, en parámetros, dejamos un comando para reiniciar la configuración automática después de cada renovación del certificado.

El proceso de adquisición del certificado puede tardar hasta dos minutos, así que no lo interrumpa. En caso de que se produzca un error de validación de dominio, intente ejecutar el comando de nuevo. Al final, veremos dónde se descargaron los certificados.

Recuerde estas rutas, tendremos que especificarlas al copiar los certificados a otros servidores y tendremos que especificarlas en la configuración del servidor. Ignore el error de recarga de Nginx config, ya que no se producirá en un servidor completamente configurado durante la renovación del certificado.

En cuanto al certificado SSL, todo lo que nos queda por hacer es copiarlo a los otros dos servidores guardando las rutas del certificado. Cree directorios idénticos en cada servidor y, a continuación, copie archivos de certificado:

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 automatizar la renovación de certificados, debe crear una tarea CRON diaria en ambos servidores. A continuación se muestra el comando que debe agregar a los trabajos CRON:

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

Tenga en cuenta que la conexión con el servidor de origen remoto requiere un acceso por clave sin ingresar una contraseña. No olvides crearlo.

Instalación y configuración de Nginx

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

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

En lugar de la configuración predeterminada, use la siguiente:

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 configuración, vamos a editar:

• max_size — el tamaño de la caché no supera el espacio de disco disponible
• inactivo — tiempo de retención para datos en caché no solicitados
• ssl_certificate y ssl_certificate_key — rutas de acceso al certificado y clave SSL
• proxy_cache_valid — tiempo de retención para datos en caché
• proxy_pass — dirección del servidor de origen desde el que la CDN solicitará datos para el almacenamiento en caché. Para nuestro ejemplo, es sayt.in

Como puedes ver, no es ciencia espacial. La única dificultad es configurar el tiempo de retención, dadas las similitudes entre los parámetros inactivos y proxy_cache_valid. Echemos un vistazo más de cerca. Esto es lo que sucede con inactive=7d y proxy_cache_valid = 90d:

• si la solicitud no se repite en un plazo de 7 días, los datos se eliminan de la caché
• si la solicitud se repite incluso una vez durante 7 días, la caché se considerará obsoleta después de 90 días y la siguiente solicitud hará que Nginx la actualice desde el servidor de origen

Con nginx.conf manejado, recarga la configuración:

root@cdn:~# service nginx reload

Por lo tanto, nuestra CDN está lista para usar. Por $15 / mes tenemos PoPs en tres continentes y 3 TB de tráfico: 1 TB por cada región.

Comprobando nuestra CDN

Echemos un vistazo a ping a nuestra CDN desde diferentes ubicaciones. Cualquier servicio de ping servirá en este caso.

Los resultados son buenos. Ahora vamos a colocar una imagen de prueba titulada prueba.jpg en el servidor principal y compruebe qué tan rápido se carga a través de CDN. Dicho y hecho. La carga es rápida.

Hagamos un pequeño script en caso de que necesitemos borrar la caché en un punto CDN.

purge.sh

#!/bin/bashif then echo "Purging all cache" rm -rf /var/cache/cdn/*else echo "Purging " FILE=`echo -n "" | md5sum | awk '{print }'` FULLPATH=/var/cache/cdn/${FILE:31:1}/${FILE:29:2}/${FILE} rm -f "${FULLPATH}"fi

Para borrar toda la caché del servidor, simplemente ejecute el script. Si necesita un archivo purgado, simplemente especifique su ruta de acceso:

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

Para purgar la caché en todas partes, el script debe ejecutarse en todos los servidores CDN.

En lugar de conclusiones

Finalmente, me gustaría dar algunos consejos útiles para que pueda evitar caer en las trampas que ya eliminé:

• Considere la viabilidad y los costos de mantenimiento de su futura CDN. En la mayoría de los casos, es mucho más eficiente y fácil comprar una CDN barata, que probablemente será más estable y de mejor calidad.
• Para mejorar la tolerancia a fallos de la CDN, se recomienda configurar una conmutación por error de DNS, que le permitiría cambiar rápidamente el registro A en caso de que se rompa un servidor. Puede hacerlo en el panel de control de registros de DNS.
• Los sitios web con amplia cobertura requieren un gran número de COP, pero no se ponen demasiado entusiastas. Lo más probable es que un usuario no note la diferencia entre su CDN y una de pago, si tiene servidores en 6-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 CDN. Por lo tanto, si está buscando crear un servicio de CDN, asegúrese de leer los términos y condiciones del proveedor de alojamiento.
• Estudie el mapa de cables submarinos para comprender cómo están conectados los continentes y utilice este conocimiento al construir su CDN.
• Intente hacer ping a sus servidores desde diferentes ubicaciones. De esta manera, puede detectar las regiones más cercanas a sus PoPs y le ayudará a configurar GeoDNS.