Mantener Semaphore al detenerse un nodo
Coloca nodos activos tras una dirección única. Mantén interfaz y API durante mantenimiento con base compartida y Redis.
Tu infraestructura necesita automatización disponible
Durante un incidente el equipo necesita ejecutar recuperación y cambios. Un nodo caído no debería quitar ese acceso.
Un nodo fuera de línea
Abrir la interfaz
Usar la API
Iniciar trabajos
Mantener disponibilidad con Enterprise HA
Enterprise HA mantiene interfaz y API mediante nodos sanos si otro se detiene.
Otro nodo continúa atendiendo solicitudes
Abrir la interfaz
Usar la API
Iniciar trabajos
Qué necesita Semaphore para HA
01
Dos o más nodos Semaphore
Ejecuta al menos dos instancias equivalentes, alinea configuración y da a cada nodo un identificador único ha.node_id.
02
Balanceo HTTP y WebSocket
Envía HTTP y WebSocket por un balanceador que retire nodos defectuosos.
03
Base SQL compartida y Redis
Conecta cada nodo al mismo PostgreSQL o MySQL y backend Redis. Protege también esos servicios. SQLite no admite esta HA.
Planificar el resto del despliegue productivo
Dar acceso necesario a los equipos
Control de accesoPlanificar disponibilidad del despliegue completo
Mostrar estado compartido en la arquitectura
La topología es activa-activa con PostgreSQL o MySQL y Redis compartidos. Base guarda estado; Redis bloqueos, cola y actualizaciones. SQLite y BoltDB no son compatibles.
Admitir solicitudes y actualizaciones en directo
El balanceador debe admitir HTTP y WebSocket y ofrecer nodos sanos y actualizaciones. Redundancia, TLS y health checks son del despliegue; añadir nodos no los configura.
Escalar aplicación y ejecución aparte
Los nodos proporcionan web/API y coordinación. Los runners ubican y amplían la ejecución independientemente. Así el equipo distingue si un cambio de capacidad responde a carga de usuarios/API, concurrencia o acceso a otra red, sin asumir que un nodo adicional resuelve todo.
Dar un plan de recuperación a cada dominio de fallo
Disponibilidad de nodos, recuperación de base, disponibilidad Redis y recuperación del sitio son responsabilidades distintas. Siguen haciendo falta copias, pruebas, objetivos de recuperación y actualizaciones compatibles. Una topología tolera un tipo de fallo y puede seguir expuesta a otro.
Mantener coordinación con Redis Sentinel
Sentinel permite failover de coordinación. Cada nodo descubre master y sigue la réplica promovida sin reinicio. Configura el mismo despliegue junto con disponibilidad de base y balanceador.
Incluir dependencias en el plan de disponibilidad
Base SQL, Redis y balanceador sirven a todos. Configura redundancia y recuperación junto a Semaphore.
Mantener recuperación de datos
Redundancia y recuperación de datos resuelven problemas distintos. Mantén copias y prueba la restauración de la base y configuración necesarias.
Documentación y funciones relacionadas
FAQ
¿Qué componentes requiere HA?
La arquitectura usa varios nodos, PostgreSQL o MySQL compartido, Redis y balanceador HTTP/WebSocket. Cada nodo necesita ajustes comunes e ID HA único. Planifica las dependencias; un segundo proceso no aporta por sí solo todo el estado y coordinación.
¿Semaphore HA es activo-activo o activo-pasivo?
La arquitectura es activa-activa con nodos equivalentes, sin primario dedicado y espera pasiva. Sigue la guía actual y no deduzcas otra arquitectura activa-pasiva. Si necesitas otra topología, resuelve estado y failover antes.
¿Puedo usar SQLite o BoltDB con HA?
No. HA necesita PostgreSQL o MySQL compartido y Redis. La base es la fuente común. Si migras de un nodo con otro almacenamiento, planifica migración, copias y validación aparte. Verifica los datos compartidos antes de añadir nodos.
¿HA protege también base, Redis y balanceador?
Esos servicios necesitan resiliencia propia. Multinodo no crea failover de base, balanceo redundante ni Redis disponible. Identifica dominios, recuperación y capacidad. Prueba de petición a resultado para cubrir el servicio real.
¿Sobreviven tareas a caídas o actualizaciones?
Varios nodos no garantizan continuidad de tareas en curso. Depende del recorrido, componente y versión. Prueba el ciclo de vida, estados y runners necesarios. Planifica compatibilidad y migraciones en lugar de asumir actualizaciones sin interrupciones. Disponibilidad de interfaz y continuidad de tareas son requisitos distintos.
¿Qué oferta incluye HA y cómo evaluarla?
La alta disponibilidad es Enterprise. Parte de horarios, mantenimiento, objetivos de recuperación y servicios existentes. Usa la topología documentada para encontrar carencias y prueba retirada de nodos, dependencias y copias en un entorno representativo. Si es crítico, revisa la arquitectura: el resultado depende del despliegue completo, no de un interruptor.
¿Pueden mantener la URL al retirar un nodo?
Ese es el fin de nodos activos tras una dirección balanceada. El balanceador deja de enviar al nodo caído y admite HTTP y WebSocket. El superviviente necesita base, Redis y configuración compartidos.
¿Necesito HA para varias redes privadas?
No. Los runners cubren ubicaciones múltiples. HA afecta a la aplicación, los runners a dónde se ejecuta y qué alcanza. Combina nodos HA para UI/API con runners de proyecto cerca de infraestructura privada.