Cómo montar un sistema de alta disponibilidad con Raspberry Pi
Un sistema de alta disponibilidad con Raspberry Pi es la mejor defensa contra los fallos de hardware imprevistos en un entorno de producción. En nuestra experiencia operando La MIX Radio y Radio OnE, sabemos que cualquier minuto de silencio es un error crítico. Para evitarlo, implementamos soluciones que garanticen que el servicio siga activo aunque un dispositivo falle. En este artículo veremos cómo lograr que dos o más placas Raspberry trabajen coordinadas para mantener la continuidad operativa.
El homelab de Fabio Martínez se basa en la redundancia. Utilizamos Proxmox para la mayoría de los servicios pesados en VMs y contenedores. Sin embargo, hay tareas específicas que requieren hardware físico dedicado. Aquí es donde entra la necesidad de evitar que un único punto de falla detenga la emisión de nuestra radio online.
El problema de la redundancia en hardware pequeño
Cuando dependemos de una sola Raspberry Pi para tareas como el monitoreo de Icecast o la ejecución de scripts de Python, corremos un riesgo. Una tarjeta SD corrupta o una caída de tensión pueden dejar el sistema fuera de línea. Si el script de automatización de La MIX Radio se detiene, la música deja de fluir hacia el servidor de streaming.
La falta de redundancia genera síntomas claros. Primero, notamos el silencio en la señal de audio. Luego, el monitor_bot de Telegram deja de enviar alertas. Finalmente, debemos intervenir manualmente para reiniciar el hardware. Este proceso es lento y propenso a errores humanos bajo presión.
Sin un sistema de respaldo automático, el tiempo de recuperación depende totalmente de nuestra disponibilidad física. Para un profesional con 30 años en radio, el concepto de «aire» es sagrado. No podemos permitir que la infraestructura técnica sea el cuello de botella de la creatividad sonora.
Requisitos previos para el sistema de alta disponibilidad con Raspberry Pi
Antes de comenzar la configuración técnica, necesitamos preparar el hardware y el software. No es posible lograr redundancia con un solo dispositivo. Para este montaje, utilizaremos una arquitectura de nodo Maestro y nodo Backup.
- Dos placas Raspberry Pi (modelo 4 o 5 recomendados por su estabilidad).
- Sistemas operativos Raspberry Pi OS Lite instalados en ambas.
- Direcciones IP estáticas configuradas en el router o en el archivo /etc/dhcpcd.conf.
- Acceso SSH habilitado en ambos nodos para facilitar la gestión remota.
- Una red local estable y preferiblemente conectada por cable Ethernet.
Es fundamental que ambas placas tengan el mismo software instalado. Si el Maestro ejecuta el script emily_gtts.py, el Backup debe tener una copia exacta de ese código y sus dependencias. La sincronización de datos es la base de cualquier estrategia de failover eficiente.
Solución paso a paso para implementar el sistema de alta disponibilidad con Raspberry Pi
Para lograr que el servicio no caiga, utilizaremos Keepalived. Esta herramienta crea una IP Virtual (VIP). El cliente o servidor que se conecte a esa IP no sabrá qué Raspberry está respondiendo. Si el Maestro falla, la VIP se mueve automáticamente al Backup en milisegundos.
Instalación de Keepalived en ambos nodos
Primero, actualizamos los repositorios e instalamos el paquete necesario en ambas placas. Ejecutamos los siguientes comandos en la terminal:
sudo apt update
sudo apt install keepalived -y
Una vez instalado, debemos configurar el rol de cada nodo. El nodo Maestro tendrá la prioridad más alta, mientras que el Backup esperará la señal de caída del primero.
Configuración del Nodo Maestro
Editamos el archivo de configuración en la Raspberry Pi que actuará como servidor principal. Accedemos a la ruta /etc/keepalived/keepalived.conf y definimos los parámetros de red.
vrrpinstance VI1 { state MASTER interface eth0 virtualrouterid 51 priority 101 advert_int 1 authentication { auth_type PASS auth_pass 1234 } virtual_ipaddress { 192.168.1.50 }
}
En este ejemplo, 192.168.1.50 es nuestra IP Virtual. Todos los servicios de La MIX Radio que requieran conexión a estas placas deben apuntar a esa dirección y no a la IP física de la placa.
Configuración del Nodo Backup
En la segunda Raspberry Pi, realizamos una configuración similar, pero cambiamos el estado a BACKUP y reducimos la prioridad. Esto asegura que el nodo solo tome el control si el Maestro deja de responder.
vrrpinstance VI1 { state BACKUP interface eth0 virtualrouterid 51 priority 100 advert_int 1 authentication { auth_type PASS auth_pass 1234 } virtual_ipaddress { 192.168.1.50 }
}
Sincronización de scripts y datos
El sistema de alta disponibilidad con Raspberry Pi no sirve de nada si el Backup no tiene los datos actualizados. En nuestro homelab, utilizamos rsync mediante un cron job para copiar los scripts de Python y las configuraciones de nginx cada hora.
rsync -avz /home/lamix/scripts/ usuario@ip-backup:/home/lamix/scripts/
Este comando asegura que cualquier cambio en la lógica de automatización se replique inmediatamente. Si actualizamos el bot de Telegram en el Maestro, el Backup estará listo para ejecutar la misma versión en caso de emergencia.
Un sistema de alta disponibilidad con Raspberry Pi requiere que la IP Virtual sea la única puerta de entrada para evitar conflictos de rutas en la red local.
Errores comunes y cómo evitarlos
Durante la implementación de estos sistemas, es frecuente encontrar obstáculos técnicos. El primero es el fenómeno conocido como «Split-Brain». Esto ocurre cuando ambos nodos creen que el otro ha caído y ambos intentan reclamar la IP Virtual al mismo tiempo.
Para evitar el Split-Brain, es vital que el virtualrouterid sea único en la red y que la prioridad esté claramente diferenciada. Si ambos nodos tienen la misma prioridad, el comportamiento del tráfico será errático y causará microcortes en la señal de radio.
Otro error recurrente es ignorar los permisos de los archivos sincronizados. Al usar rsync, si no se mantienen los permisos de ejecución, el script de backup fallará al intentar iniciar. Siempre recomendamos usar el flag -p en rsync para preservar los permisos originales.
Finalmente, muchos olvidan configurar el firewall de Linux. Keepalived utiliza el protocolo VRRP. Si ufw o iptables bloquean este tráfico, el Backup nunca recibirá el «latido» del Maestro y asumirá el control prematuramente, creando un conflicto de IPs.
Resultado final y verificación del servicio
Para comprobar que el sistema funciona, primero verificamos que la IP Virtual esté asignada al Maestro. Ejecutamos el comando ip addr show eth0 en la terminal. Deberíamos ver nuestra IP física y la IP 192.168.1.50.
La prueba de fuego consiste en simular un fallo crítico. Desconectamos el cable de red del Nodo Maestro o apagamos la placa abruptamente. En menos de dos segundos, al ejecutar el mismo comando en el Nodo Backup, veremos que la IP Virtual ha migrado automáticamente.
Si tenemos un servicio de Python corriendo, podemos usar un script simple de monitoreo que nos avise vía Telegram cuando el cambio de nodo se haya completado. Esto nos da la tranquilidad de que la infraestructura de La MIX Radio es resiliente.
Conclusión y siguiente paso
Implementar un sistema de alta disponibilidad con Raspberry Pi transforma un experimento de homelab en una infraestructura profesional. Hemos logrado eliminar el punto único de falla, asegurando que la música y la automatización no se detengan. Este enfoque nos permite realizar mantenimientos en el hardware sin afectar la experiencia del oyente.
Una vez dominado el failover con Keepalived, el siguiente paso lógico es explorar la orquestación con K3s. Kubernetes ligero para Raspberry Pi permite no solo alta disponibilidad de red, sino también el auto-escalado de contenedores Docker. Esto llevaría la estabilidad de Radio OnE a un nivel empresarial, optimizando el uso de recursos en todo el cluster.
