Alta Disponibilidad y Dominios de Falla

Esta página describe un modelo práctico de activo/respaldo para LibreQoS.

Alcance y Supuestos

Esta página cubre alta disponibilidad de LibreQoS con un diseño activo/respaldo.
La conmutación por falla debe controlarse con enrutamiento dinámico (por ejemplo OSPF o BGP).
No se prescribe ningún fabricante de hardware o router.
La alta disponibilidad específica de Insight está fuera del alcance de esta página.

Modelo HA Activo/Respaldo

Una ruta está activa (preferida) y otra está en respaldo (espera). La política de enrutamiento controla la selección de ruta y la conmutación por falla.

stateDiagram-v2
    [*] --> PrimariaActiva
    PrimariaActiva: Ruta primaria preferida (costo 1)
    PrimariaActiva --> ConvergenciaFailover: Falla primaria detectada
    ConvergenciaFailover --> RespaldoActivo: Enrutamiento convergió al respaldo (costo 100)
    RespaldoActivo --> ValidacionRecuperacion: Primaria reparada
    ValidacionRecuperacion --> PrimariaActiva: Preferencia restaurada y estable

Ejemplo OSPF (Costo 1 Primario, Costo 100 Respaldo)

Use el costo de interfaz OSPF para preferir la ruta activa.

Ruta primaria de LibreQoS: ip ospf cost 1
Ruta de respaldo de LibreQoS: ip ospf cost 100

Resultado conceptual:

Estado normal: el tráfico usa la ruta primaria porque el costo 1 es menor que 100.
Estado de falla: si la ruta/router primaria cae, OSPF converge y el tráfico usa la ruta de respaldo.
Estado de recuperación: cuando la primaria vuelve a estar sana, el tráfico regresa a la primaria por su menor costo.

Intención de política:

Mantener ambas rutas activas y enrutables todo el tiempo.
Asegurar que el respaldo tenga capacidad suficiente para el pico esperado.
Probar conmutación por falla y retorno en ventanas de mantenimiento.

Equivalente en BGP (Si Usa BGP en Lugar de OSPF)

Si usa BGP, utilice controles de preferencia estándar para definir una ruta primaria y otra de respaldo (por ejemplo local preference, MED o AS path prepending según su diseño). Mantenga la política determinista y documentada.

Recuperación y Retorno (Runbook Conceptual)

Confirmar si ocurrió la conmutación por falla (tabla de rutas/verificación de camino).
Verificar que el tráfico de clientes esté fluyendo por la ruta de respaldo.
Reparar la ruta primaria fallida.
Validar la salud de la ruta primaria.
Restaurar la preferencia de rutas a su estado normal (primaria preferida).
Verificar que el tráfico regresó a la primaria y que el rendimiento es estable.

Mantenimiento Planificado (Procedimiento Conceptual)

Anunciar ventana y criterios de éxito.
Confirmar salud y capacidad de la ruta de respaldo.
Mover tráfico al respaldo usando política de enrutamiento.
Realizar mantenimiento en la ruta activa anterior.
Validar la ruta reparada.
Opcionalmente regresar el tráfico al estado activo normal.
Cerrar la ventana con notas de validación posteriores al cambio.

Lista de Verificación de Preparación HA

El enrutamiento dinámico está implementado y documentado.
Las preferencias activo/respaldo son explícitas y probadas.
Monitoreo y alertas cubren ambas rutas y dependencias clave.
El runbook de guardia incluye pasos de failover y failback.
Existe una cadencia de pruebas regulares (por ejemplo pruebas trimestrales).
La capacidad de la ruta de respaldo está validada para carga pico realista.

Límites Conocidos

La alta disponibilidad depende de la calidad del diseño de red circundante.
La convergencia del enrutamiento dinámico no es instantánea.
Una política mal configurada puede causar failover asimétrico o inestable.
HA no reemplaza respaldos ni disciplina operativa.

4.0 KiB Raw Blame History