Duplicar no es independizar
Dos servidores con el mismo switch, almacenamiento y alimentación mantienen fallos comunes. Mapee dependencias del flujo. La redundancia cubre solo fallos realmente separados, no errores de configuración o corrupción replicada.
Construya una matriz de fallo, impacto, detección, supervivencia y retorno. Incluya identidad, colas e interfaces de equipo.
Activo-pasivo y activo-activo
Activo-pasivo simplifica autoridad, pero exige demostrar toma de control. Activo-activo puede repartir recursos distintos, con propiedad explícita y coordinación de estados. Dos copias de lógica no forman automáticamente un sistema correcto.
Quorum ayuda a decidir liderazgo, pero la instancia perdedora debe perder acceso de comando. Preservar consistencia durante partición puede detener parte del servicio. Documente esa elección.
Replicación y backup
Una eliminación errónea puede propagarse a todas las réplicas. Backup permite recuperar un estado anterior fiable. Proteja retención ante errores e incidentes que afecten el entorno completo.
La reserva debe acompañar cambios de configuración. Diferencias de adaptador, certificados o mapas aparecen a veces solo al conmutar. Valide configuración durante mantenimiento.
Ejemplo de switch común
Ambos servidores siguen encendidos, pero pierden acceso a PLC por un switch compartido. Cambiar instancia no recupera el camino. Se necesita alternativa soportada y probada o aceptar explícitamente ese dominio de fallo.
Retire dependencias individualmente y observe el servicio completo. Pruebe también failback: regresar puede causar otra interrupción. Documente cobertura y verificaciones finales de integridad.
Criterios de verificación del proyecto
- Identificar energía, red y almacenamiento compartidos.
- Probar pérdida de quorum y prevención de comandos concurrentes.
- Validar reserva y retorno después de conmutar.
Los ejemplos describen decisiones de ingeniería y escenarios de prueba. Interfaces, límites y funciones implantadas se definen en el alcance de cada proyecto.