Llegamos al final del proyecto TeisGames. El mayor reto no era hacer que los juegos funcionaran, sino garantizar que nunca dejasen de funcionar. Para ello, implementamos una arquitectura de Alta Disponibilidad (HA) distribuida en dos sedes físicas.
1. Previniendo el «Split-Brain» (MySQL Master-Master) No queríamos un servidor esclavo pasivo, queríamos que ambos nodos fuesen capaces de escribir datos. Configuramos una replicación Activo-Activo entre los MySQL de ambos nodos a través de la VPN cifrada de Tailscale. Para evitar colisiones de IDs si se cortaba la red (Split-Brain), configuramos el Nodo 1 para generar solo IDs impares y el Nodo 2 para IDs pares. ¡Magia pura!
2. Failover Automático con DuckDNS Si el router de nuestra sede principal cae, los usuarios no pueden entrar. Para automatizar el rescate, programamos un script en Bash (ha_rescate.sh). Este script monitoriza la red y, si detecta la caída del Nodo 1, lanza una petición a la API de DuckDNS para robar el dominio y apuntarlo a la IP pública del Nodo 2 en menos de 60 segundos.
3. Seguridad y Backups Blindamos el servidor base configurando el firewall UFW con una política Default Deny y aplicando estrictos permisos (700 y 600) a nuestros scripts críticos. Además, programamos tareas cron diarias para generar volcados .sql de la base de datos por si algún día necesitamos recuperar el estado del sistema.
Conclusión y Pruebas Tiramos del cable de alimentación del Nodo 1 en pleno funcionamiento… y el sistema brilló. El tráfico viró hacia el Nodo 2 de forma transparente y los datos estaban intactos. Han sido semanas de investigar redes en malla, lidiar con CG-NAT y orquestar microservicios, pero el resultado es una plataforma corporativa tolerante a fallos. ¡Proyecto superado!
