Infraestructura híbrida: combinación de servidores dedicados y la nube

Por qué la nube pura no da la talla con cargas de trabajo de alta demanda

El modelo de facturación de la nube es una ventaja cuando el tráfico es impredecible, pero se convierte en un inconveniente cuando es constante. Una aplicación SaaS que atiende a 50 000 usuarios al día no necesita un escalado elástico, sino una capacidad básica fiable a un coste predecible. Ejecutar esa carga de trabajo en la nube implica pagar tarifas bajo demanda o reservadas por recursos que se utilizan de forma continua, cada hora, todos los días.

La propia calculadora de precios de AWS muestra que las cargas de trabajo continuas en instancias reservadas de EC2 suelen costar entre tres y cuatro veces más que el precio de un servidor dedicado equivalente con especificaciones similares. Para la configuración del servidor dedicado Extreme —AMD EPYC 4545P de 16 núcleos, 192 GB de RAM DDR5, 2×3,84 TB NVMe no es fácil encontrar una instancia en la nube con especificaciones comparables y 500 GB de almacenamiento de copia de seguridad, protección contra malware y soporte gestionado 24/7 por 349,99 $ al mes.

Lo que la nube realmente hace mejor: gestionar el tráfico que supera tu nivel básico dedicado durante breves periodos de tiempo, almacenar datos poco utilizados a bajo coste y ejecutar cargas de trabajo distribuidas geográficamente en regiones en las que no tienes centros de datos.

El modelo de arquitectura híbrida

Una configuración híbrida bien diseñada asigna los tipos de carga de trabajo a los tipos de infraestructura en función de sus características:

Un servidor dedicado se encarga de:

• Lógica central de la aplicación y API
• Base de datos principal (MySQL, PostgreSQL, Redis)
• Servicios de sesión y autenticación
• Almacenamiento del origen de los recursos estáticos
• Datos persistentes del usuario

Asas de la nube:

• Capacidad de cálculo de picos durante los picos de tráfico
• Modo de espera activa para la recuperación ante desastres
• Almacenamiento de copias de seguridad en frío (almacenamiento de objetos compatible con S3)
• Redundancia geográfica del origen de la CDN
• Entornos que no son de producción (desarrollo, staging, control de calidad)

La idea clave es que la mayoría de las solicitudes de las aplicaciones se dirigen al servidor dedicado, donde el coste por solicitud es más bajo. La infraestructura en la nube está inactiva o tiene poca carga la mayor parte del tiempo, lo que significa que no pagas las tarifas máximas de la nube por el tráfico básico.

Capacidad de picos: escalabilidad más allá del servidor dedicado

Cuando tu servidor dedicado se acerca a los límites de CPU o memoria durante un pico de tráfico —ya sea el lanzamiento de un producto, un momento viral o una promoción programada—, la capacidad adicional de la nube mantiene la aplicación con buena respuesta sin necesidad de una configuración dedicada sobredimensionada de forma permanente.

La implementación utiliza un equilibrador de carga (HAProxy o Nginx, que se ejecuta en el servidor dedicado o como servicio en la nube) para redirigir el exceso de tráfico a instancias en la nube que se activan bajo demanda.

Configuración básica de HAProxy para el enrutamiento híbrido:

frontend http_front

    bind *:80

    default_backend dedicated_pool

backend dedicated_pool

    balance leastconn

    server dedicated1 192.168.1.10:80 check weight 10

    servidor cloud_burst1 10.0.1.20:80 comprobación peso 1 copia de seguridad

    servidor cloud_burst2 10.0.1.21:80 comprobación peso 1 copia de seguridad

frontend http_front

    bind *:80

    default_backend dedicated_pool

backend dedicated_pool

    balance leastconn

    server dedicated1 192.168.1.10:80 check weight 10

    server cloud_burst1 10.0.1.20:80 check weight 1 backup

    server cloud_burst2 10.0.1.21:80 check weight 1 backup

La directiva de respaldo mantiene los servidores en la nube inactivos hasta que el servidor dedicado principal no esté disponible o se sobrecargue. La documentación de HAProxy explica cómo configurar el desbordamiento basado en colas, en el que las solicitudes se acumulan brevemente en una cola antes de redirigirse a la capacidad de picos, en lugar de fallar.

Las instancias de Cloud Burst funcionan mejor cuando tu aplicación no tiene estado en la capa de computación: el estado de la sesión se almacena en Redis en el servidor dedicado, por lo que cualquier instancia en la nube puede gestionar cualquier solicitud. Las aplicaciones con estado requieren una configuración de afinidad de sesión, lo que complica considerablemente el enrutamiento de Cloud Burst.

Configuración de los desencadenantes de autoescalado en AWS:

# Crea una alarma de CloudWatch para activar el escalado cuando el recurso dedicado esté saturado

aws cloudwatch put-metric-alarm \

  --alarm-name "dedicated-cpu-high" \

  --metric-name CPUUtilization \

  --namespace AWS/EC2 \

  --statistic Average \

  --period 60 \

  --threshold 80 \

  --comparison-operator GreaterThanThreshold \

  --alarm-actions arn:aws:autoscaling:us-west-2:123456789:scalingPolicy:policy-arn

# Create a CloudWatch alarm to trigger scaling when dedicated is saturated

aws cloudwatch put-metric-alarm \

  --alarm-name "dedicated-cpu-high" \

  --metric-name CPUUtilization \

  --namespace AWS/EC2 \

  --statistic Average \

  --period 60 \

  --threshold 80 \

  --comparison-operator GreaterThanThreshold \

  --alarm-actions arn:aws:autoscaling:us-west-2:123456789:scalingPolicy:policy-arn

Recuperación ante desastres con Cloud Warm Standby

Un servidor dedicado sin un plan de recuperación ante desastres es un punto único de fallo. La modalidad «warm standby» en la nube ofrece capacidad de recuperación sin necesidad de mantener un segundo servidor dedicado con todos los gastos que ello conlleva.

El modelo DR se basa en tres principios:

La replicación de datos es continua. La replicación del registro binario de MySQL a una réplica alojada en la nube mantiene la base de datos de recuperación ante desastres sincronizada con la principal en cuestión de segundos. Configura la replicación en el archivo my.cnf de la base de datos principal:

[mysqld]
server-id = 1
log_bin = /var/log/mysql/mysql-bin.log
binlog_do_db = production_db

[mysqld]
server-id = 1
log_bin = /var/log/mysql/mysql-bin.log
binlog_do_db = production_db

En la réplica en la nube:

[mysqld]
server-id = 2
relay-log = /var/log/mysql/mysql-relay-bin.log
log_bin = /var/log/mysql/mysql-bin.log
read_only = 1

[mysqld]
server-id = 2
relay-log = /var/log/mysql/mysql-relay-bin.log
log_bin = /var/log/mysql/mysql-bin.log
read_only = 1

El código de la aplicación se almacena en un sistema de almacenamiento de objetos en la nube. Al tener una copia del directorio de tu aplicación sincronizada con S3, la instancia de recuperación ante desastres en la nube puede recuperar el código actual durante la conmutación por error sin depender de que el servidor principal esté accesible.

La conmutación por error del DNS ya está preconfigurada. Las comprobaciones de estado Cloudflarepueden cambiar automáticamente el DNS de la IP de tu servidor dedicado a la IP de tu instancia en la nube en menos de 30 segundos tras detectar un fallo en el servidor principal. Configúralo antes de que lo necesites, no cuando ya haya una interrupción del servicio.

El modo de espera activa de DR funciona con un coste mínimo en la nube (una instancia detenida o una pequeña instancia en ejecución para la replicación) hasta que se produce la conmutación por error, momento en el que se amplía para gestionar el tráfico de producción.

Arquitectura de red: cómo conectar los dos entornos

La infraestructura híbrida requiere una conexión privada entre los entornos dedicados y los entornos en la nube. La conexión a Internet pública funciona, pero genera latencia y riesgos de seguridad. Hay dos opciones:

Túnel VPN: Un túnel WireGuard u OpenVPN entre el servidor dedicado y la VPC en la nube ofrece conectividad privada a un coste insignificante. La configuración de WireGuard es mucho más sencilla que la de OpenVPN y ofrece un mejor rendimiento a altas velocidades de transferencia.

# /etc/wireguard/wg0.conf on dedicated server

[Interface]
PrivateKey = <server_private_key>
Address = 10.10.0.1/24
ListenPort = 51820

[Peer]
PublicKey = <cloud_instance_public_key>
AllowedIPs = 10.10.0.0/24
Endpoint = <cloud_instance_ip>:51820
PersistentKeepalive = 25

# /etc/wireguard/wg0.conf on dedicated server

[Interface]
PrivateKey = <server_private_key>
Address = 10.10.0.1/24
ListenPort = 51820

[Peer]
PublicKey = <cloud_instance_public_key>
AllowedIPs = 10.10.0.0/24
Endpoint = <cloud_instance_ip>:51820
PersistentKeepalive = 25

AWS Direct Connect / Azure ExpressRoute: Para arquitecturas híbridas de alto rendimiento, un circuito de red dedicado entre el centro de datos InMotion Hostingy el proveedor de servicios en la nube elimina por completo el uso de la red pública de Internet. Esto supone un coste adicional (Direct Connect tiene un precio a partir de 0,02 $/GB por transferencia de datos), pero elimina la variabilidad de la latencia y garantiza un rendimiento constante.

En la mayoría de las implementaciones híbridas, basta con usar WireGuard a través de Internet pública con un ancho de banda adecuado. Direct Connect cobra importancia cuando el volumen de replicación de bases de datos o el tráfico entre servicios supera habitualmente los 1 Gbps.

Modelo de costes: dónde gana el híbrido

Desde el punto de vista económico, la opción híbrida es la más recomendable cuando tu carga de trabajo habitual se adapta a un servidor dedicado y tus picos de tráfico son esporádicos. Ten en cuenta lo siguiente:

• Servidor dedicado (plan EssentialInMotion Hostinga 99,99 $ al mes): gestiona el 90 % del tráfico de forma continua
• Capacidad de respuesta ante picos de tráfico (2 instancias EC2 t3.xlarge, bajo demanda a unos 0,17 $/hora cada una): activa 40 horas al mes durante los picos de tráfico
• Recuperación ante desastres en la nube en modo de espera activa (instancia EC2 detenida): 0 $ al mes hasta que sea necesaria la conmutación por error; almacenamiento de replicación en S3: entre 5 y 20 $ al mes
• VPN WireGuard: sin coste adicional

Total mensual: entre 130 y 140 dólares al mes, frente a ejecutar todo en la nube con una capacidad equivalente, lo que probablemente costaría entre 400 y 600 dólares al mes para obtener un rendimiento básico comparable con capacidad de ampliación.

El ahorro se reduce si tus picos de tráfico son frecuentes y prolongados. Llega un momento en que resulta más barato tener un servidor dedicado más potente que recurrir con frecuencia al cloud bursting.

El servidor dedicado InMotion Hostingcomo núcleo híbrido

La gama de servidores dedicadosInMotion Hosting está diseñada precisamente para esta arquitectura: alto rendimiento, tarifas planas, ancho de banda ampliable de 10 Gbps para gestionar los picos de tráfico sin tarifas de salida por GB, y servicios gestionados Premier Care para que la infraestructura básica no requiera la atención de los ingenieros.

Los 192 GB de RAM DDR5 del servidor Extreme ofrecen suficiente capacidad de memoria para que muchas aplicaciones puedan ejecutar todo su conjunto de datos de trabajo en la memoria del servidor dedicado, recurriendo a la nube solo en caso de un verdadero desbordamiento, en lugar de para las lecturas rutinarias de la base de datos que llevarían a un servidor más pequeño al límite de su capacidad.