Continuidad de negocio

Alta disponibilidad (HA)

Que el fallo de un componente no pare el servicio. Ni el de un disco, ni el de un nodo, ni el de un enlace.

El problema

La alta disponibilidad es probablemente el concepto peor entendido de la infraestructura. Se confunde con el backup, se confunde con el Disaster Recovery y, sobre todo, se da por hecha: mucha gente cree tenerla porque su plataforma está virtualizada y tiene varios servidores.

Tener varios nodos no es tener alta disponibilidad. Si las máquinas virtuales están en el disco local de cada host, la caída de un host se lleva sus máquinas y no hay conmutación posible. Si el clúster tiene dos nodos y no hay árbitro de quorum, una partición de red puede dejar la plataforma bloqueada o, peor, con los dos nodos creyéndose el bueno.

Y en casi todas las instalaciones queda algún punto único de fallo que nadie ha identificado: un único conmutador de red, una única fuente de alimentación conectada a la misma regleta, un servidor de licencias, una máquina virtual con el directorio, un enlace de operador sin alternativa.

Qué hace IT Encore

Diseñamos plataformas en las que el fallo de un componente no interrumpe el servicio, y —igual de importante— comprobamos que efectivamente se comportan así. Un clúster configurado con alta disponibilidad que nunca ha perdido un nodo es una configuración, no una garantía.

El trabajo consiste en identificar cada punto único de fallo, decidir cuáles se eliminan y cuáles se asumen conscientemente, y dejar constancia de esa decisión. No todo tiene que ser redundante: la redundancia cuesta y en algunos componentes no se justifica.

Después se prueba: se apaga un nodo, se desconecta un enlace, se simula el fallo de un disco. Antes de poner la plataforma en producción, no cuando ocurra de verdad.

Alta disponibilidad, backup y Disaster Recovery

Son tres mecanismos distintos que resuelven problemas distintos. Confundirlos es el error más caro en continuidad.

	Alta disponibilidad	Backup	Disaster Recovery
Qué resuelve	Fallo de un componente	Pérdida o corrupción de datos	Pérdida del emplazamiento
Cuándo actúa	Automáticamente, en segundos	Cuando alguien lo solicita	Cuando se activa el plan
Alcance temporal	Sólo el presente	Permite volver atrás en el tiempo	Reconstruye en otra ubicación
¿Protege de un cifrado?	No: el daño se replica	Sí, si la copia es inmutable	Sí, si el destino está aislado
Coste relativo	Medio, en hardware	Bajo a medio	Alto si el RTO es corto

Qué incluye el servicio

Clustering. Diseño y construcción de clústeres de virtualización, de servicio o de base de datos.
Redundancia de cómputo. Nodos suficientes para que la plataforma siga funcionando con uno caído, no sólo para sumar capacidad.
Almacenamiento. Almacenamiento compartido o replicado con caminos múltiples y sin dependencia de un único disco o controladora.
Networking. Enlaces agregados, conmutadores redundantes y caminos alternativos hasta la salida a Internet.
Balanceo. Reparto de carga entre instancias con comprobaciones de salud y retirada automática de las que fallan.
Quorum. Diseño correcto del quorum, con árbitro externo cuando el número de nodos lo requiere.
Eliminación de SPOF. Inventario de puntos únicos de fallo, con decisión documentada sobre cada uno.
Alimentación. Fuentes redundantes conectadas a líneas distintas, que es donde más veces se rompe la teoría.
Pruebas de conmutación. Ensayos reales de fallo antes de producción y de forma periódica después.
Documentación. Qué se ha hecho redundante, qué no y qué ocurre exactamente ante cada tipo de fallo.

Fallos de diseño que encontramos

Almacenamiento local en un clúster

Sin almacenamiento compartido o replicado no hay conmutación posible: las máquinas caen con su host.

Clúster de dos nodos sin árbitro

Una partición de red deja la plataforma bloqueada o provoca un escenario de doble maestro.

Capacidad sin margen

Si con todos los nodos se va al 90 %, la caída de uno no la absorbe el resto.

Redundancia sobre la misma línea

Dos fuentes de alimentación conectadas a la misma regleta no son dos líneas.

Servicios de infraestructura no redundados

Directorio, DNS o servidor de licencias en una única máquina anulan la disponibilidad de todo lo demás.

Nunca se ha probado

La configuración existe pero nadie ha comprobado qué ocurre realmente al perder un nodo.

Preguntas frecuentes

¿La alta disponibilidad sustituye al backup?

No, en absoluto. La HA replica el estado actual, incluidos los errores: un borrado o un cifrado se propagan de inmediato a la copia redundante. Son mecanismos complementarios y ninguno sustituye al otro.

¿Cuánto encarece la infraestructura?

Depende del nivel. Pasar de un servidor a un clúster de tres con almacenamiento compartido supone una inversión relevante. Por eso se decide servicio a servicio: no todo necesita el mismo nivel de disponibilidad y asumir conscientemente el riesgo en lo secundario es una decisión legítima.

¿Se puede añadir HA a una plataforma existente?

Casi siempre, aunque el alcance varía. Añadir nodos y almacenamiento compartido es habitual; corregir un diseño de red o de alimentación puede requerir intervención física. El punto de partida es una auditoría de CPD que identifique los puntos únicos de fallo.

¿Garantiza un 99,99 % de disponibilidad?

No publicamos cifras de disponibilidad genéricas. La disponibilidad real depende de la arquitectura completa, incluidos elementos que no controlamos, como la conectividad del operador o el propio centro de datos. Lo que sí documentamos es qué ocurre ante cada tipo de fallo, comprobado mediante pruebas.

Analicemos su plataforma

Identificamos los puntos únicos de fallo y proponemos qué merece la pena redundar.

Solicite una revisión