HA exige componentes redundantes: varios servidores de app tras un balanceador, replicación de BD y shared-nothing donde sea posible. Planee la falla de cualquier componente; pruebe failover periódicamente.
Eliminar puntos únicos de fallo
- Capa de app: Dos o más servidores de app tras un balanceador; si uno falla, el tráfico va a los demás.
- Capa de BD: Primario-réplica o clúster; failover automático o manual con pérdida mínima (dentro del RPO).
- Balanceador: Use LB gestionado o par; evite un único LB como único punto de entrada cuando pueda.
Shared-nothing y estado
- Servidores de app stateless: Sin estado de sesión local; escale horizontalmente y reemplace instancias sin afinidad.
- Estado en store compartido: Sesión en Redis/BD; caché en Redis o Memcached para que cualquier nodo sirva.
- Evite estado en nodo único que haría un servidor insustituible sin migración.
Probar failover
- Pruebas periódicas: Simule fallo de nodo (ej. pare un servidor de app) y verifique comportamiento del LB y la app.
- Failover de BD: Pruebe promoción de réplica a primario; verifique reconexión de la app y consistencia de datos.
- Runbooks: Documente cómo disparar y verificar failover; quién está de guardia y escalación.
Resumen
HA = servidores de app redundantes + balanceador + replicación de BD + estado compartido cuando haga falta. Pruebe failover con regularidad y mantenga runbooks actualizados.
