SafeKit: Software de alta disponibilidad SANless y clustering de aplicaciones todo en uno

SafeKit ofrece las siguientes funciones para Windows y Linux en un único producto de software:

• Equilibrio de carga
• Replicación de archivos síncrona en tiempo real
• Failover automático de aplicaciones
• Failback automático tras el fallo de un servidor

No. SafeKit es sencillo de desplegar y no requiere conocimientos avanzados ni expertos.

No. SafeKit se ejecuta en sus servidores actuales, máquinas virtuales o en la nube; no se necesitan discos compartidos ni almacenamiento SAN.

No. SafeKit funciona con ediciones estándar de Windows y Linux y no necesita licencias de bases de datos de nivel "Enterprise".

SafeKit resuelve:

• Fallos de hardware (20% de los problemas), incluyendo el fallo total de una sala de servidores
• Fallos de software (40% de los problemas), incluyendo el reinicio de procesos críticos
• Errores humanos (40% de los problemas) gracias a su facilidad de uso

Puede implementar replicación en tiempo real y failover para:

• Todo tipo de aplicaciones, directorios de archivos y servicios
• Bases de datos
• Máquinas virtuales Hyper-V o KVM completas
• Docker, Podman y aplicaciones en la nube

SafeKit elimina los siguientes requisitos:

• Balanceadores de carga de red o servidores proxy dedicados
• Discos compartidos o almacenamiento SAN replicado
• Ediciones "Enterprise" de sistemas operativos y bases de datos
• Conocimientos especializados en mantenimiento de clusters

No. La replicación de datos es simplemente el acto de copiar datos del Servidor A al Servidor B. Aunque es fundamental, la replicación por sí misma no proporciona disponibilidad. Sin los demás componentes de un stack de HA, la replicación es solo una "copia pasiva" que requiere una intervención manual lenta para ser útil:

• Si el Servidor A falla, el software de replicación de datos no dirigirá automáticamente a sus usuarios al Servidor B.
• No detectará que la aplicación se ha detenido.
• No reiniciará los servicios.

Muchos proveedores le obligan a "ensamblar" varios productos diferentes para lograr la replicación basada en host, el failover y el equilibrio de carga. Esta arquitectura fragmentada es una estrategia peligrosa para sistemas de misión crítica:

• Integración frágil: Cuando utiliza el producto A para la replicación y el producto B para el clustering, crea un "castillo de naipes". Cada actualización del sistema operativo o parche de seguridad corre el riesgo de romper el frágil vínculo de comunicación entre estos motores independientes.
• Alta carga cognitiva y error humano: Gestionar múltiples interfaces aumenta el riesgo de cometer errores. Durante un fallo del sistema bajo mucha presión, saltar entre diferentes interfaces gráficas (GUI) o utilizar diferentes sintaxis de comandos (CLI) para diagnosticar un problema genera confusión y prolonga el tiempo de inactividad.
• Conflictos entre proveedores: Si un failover falla, el proveedor de replicación puede culpar a la herramienta de clustering, dejándole atrapado en el medio sin una vía clara de resolución. Una solución "todo en uno" proporciona un único punto de responsabilidad.
• Mantenimiento complejo: Los sistemas fragmentados requieren conocimientos especializados para cada componente individual, lo que hace que la solución sea más difícil de mantener y significativamente más costosa con el tiempo.

Para automatizar la recuperación y eliminar el tiempo de inactividad, un producto "todo en uno" debe gestionar simultáneamente varias piezas técnicas móviles:

• Replicación basada en host: replicación síncrona en tiempo real de los datos críticos de la aplicación entre servidores sin depender de almacenamiento compartido (SAN). Esto garantiza la pérdida cero de datos (RPO=0) y elimina las costosas dependencias de hardware.
• Dirección IP Virtual (VIP): Proporciona un único punto de entrada para los usuarios. Cuando ocurre un fallo, el software mueve la VIP del nodo fallido al nodo sano, de modo que los usuarios no tienen que cambiar su configuración.
• Detectores de errores de hardware y software: El sistema debe realizar constantemente un "heartbeat" (latido) tanto del servidor físico como de los procesos de software específicos para identificar un bloqueo o una caída de inmediato.
• Scripts de reinicio personalizables: No todas las aplicaciones se inician de la misma manera. Una herramienta "todo en uno" permite scripts personalizados para asegurar que los servicios complejos se inicien en el orden correcto.
• Failover automático: La inteligencia necesaria para orquestar todo el movimiento de un servidor a otro sin intervención humana.

Si su gestor de failover y su replicación de datos son dos productos diferentes, es posible que no estén "sincronizados".

El peligro: si se produce un failover pero la replicación no ha terminado de enviar los últimos bits, el Servidor B iniciará la aplicación con datos desactualizados o corruptos.

Una solución de HA SANless todo-en-uno garantiza que el mecanismo de failover conozca el estado de la replicación. Solo permitirá que la aplicación se inicie en el nodo de respaldo si se garantiza que los datos están actualizados, evitando nodos activos en conflicto y la pérdida de datos.

A menudo ignorado en las guías técnicas y mal ejecutado por las soluciones de HA tradicionales, el failback automático sigue siendo el requisito más crítico para una verdadera resiliencia. Un auténtico producto "todo en uno" gestiona el "Retorno a la Normalidad" con la misma elegancia que el fallo. Cuando el servidor que falló vuelve a estar en línea, sus datos están desactualizados. El software de HA debe:

1. Resincronizar los datos en segundo plano desde el nodo activo hacia el nodo recuperado.
2. Mantener el tiempo de actividad: Esta resincronización debe realizarse sin interrumpir la aplicación que se está ejecutando actualmente en el nodo activo.
3. Restaurar la redundancia: Una vez que los datos están replicados (mirrored) de nuevo, el cluster vuelve automáticamente a un estado protegido, listo para el próximo evento.

El método técnico utilizado para la replicación basada en host influye significativamente en cuánto debe modificar la configuración de su aplicación actual.

• El desafío de la replicación a nivel de bloque: La mayoría de las soluciones SANless replican a nivel de disco/bloque. Esto no es transparente para la aplicación. Requiere reconfigurar la aplicación por completo para mover sus datos a un volumen de "disco replicado" específico y recién creado. Esto suele implicar una migración compleja y posibles cambios en la lógica de la aplicación.
• La ventaja de SafeKit a nivel de archivo: SafeKit realiza la replicación basada en host a nivel de archivo, lo cual es completamente transparente para la aplicación. No es necesario mover los datos a un disco especial; simplemente configura SafeKit para replicar las carpetas existentes de la aplicación. Estas carpetas pueden incluso permanecer en el disco del sistema, lo que le permite proteger una aplicación exactamente donde ya está instalada.

Tiempo de resincronización después de una falla (paso 3)

• Red de 1 Gb/s ≈ 3 horas para 1 terabyte.
• Red de 10 Gb/s ≈ 1 hora para 1 terabyte o menos, dependiendo del rendimiento de escritura en disco.

Alternativa

• Para un gran volumen de datos, use almacenamiento compartido externo.
• Más costoso, más complejo.

• Rendimiento del tiempo de resincronización después de una falla (paso 3).
• Tiempo para verificar cada archivo entre ambos nodos.

Alternativa

• Ponga los muchos archivos a replicar en un disco duro virtual / máquina virtual.
• Solo los archivos que representan el disco duro virtual / máquina virtual se replicarán y resincronizarán en este caso.

• Cada máquina virtual se ejecuta en un módulo espejo independiente.
• Máximo de 32 módulos espejo ejecutándose en el mismo clúster.

Alternativa

• Use un almacenamiento compartido externo y otra solución de clustering para máquinas virtuales.
• Más costoso, más complejo.

• Failover automático de la dirección IP virtual con 2 nodos en la misma subred.
• Buen ancho de banda para la resincronización (paso 3) y buena latencia para la replicación síncrona (típicamente un tiempo de ida y vuelta inferior a 2 ms).

Alternativa

• Use un balanceador de carga para la dirección IP virtual si los 2 nodos están en 2 subredes (compatible con SafeKit, especialmente en la nube).
• Use soluciones de respaldo con replicación asíncrona para redes con alta latencia.

La consola web de SafeKit ofrece una interfaz intuitiva para orquestar la alta disponibilidad de sus aplicaciones críticas. En solo unos pasos, puede configurar un mirror cluster de SafeKit para garantizar la continuidad del negocio:

• Failover de aplicaciones (pestaña Macros): defina los servicios de aplicación específicos que se reiniciarán automáticamente en caso de fallo.
• Red(es) de Heartbeat: rutas de comunicación dedicadas utilizadas por los nodos del clúster para supervisar continuamente el estado y la disponibilidad de los demás, y sincronizar las decisiones de failover.
• Gestión de IP virtual: configure la IP virtual (VIP) para una reconexión transparente de los clientes tras un failover.
• Replicación en tiempo real: seleccione los directorios críticos para la replicación síncrona a nivel de byte basada en el host.
• Checkers (Verificadores): supervise el estado de la aplicación y active la recuperación automática si se detecta un fallo en un proceso.

El clúster SafeKit incluye un verificador de "split-brain" dedicado para resolver problemas de aislamiento de red sin necesidad de una tercera máquina testigo (witness) ni de una red de heartbeat adicional. Obtenga más información sobre cortes de energía y aislamiento de red en un clúster.

La consola de gestión de SafeKit ofrece una vista unificada de su infraestructura de alta disponibilidad. Permite a los administradores supervisar el estado operativo del clúster y realizar un seguimiento de la sincronización de datos en tiempo real.

Para un clúster de tipo espejo (mirror) de 2 nodos, la consola muestra claramente los roles de cada servidor:

• PRIM (Primario): El nodo activo que ejecuta actualmente la aplicación y gestiona la IP virtual. Realiza las escrituras en el almacenamiento local y la replicación en tiempo real hacia el nodo secundario.
• SECOND (Secundario): El nodo en espera (standby) que recibe actualizaciones síncronas a nivel de byte. Está listo para tomar el control instantáneamente si el primario falla.
• Estado ALONE: Le alerta visualmente cuando el clúster se está ejecutando en un solo nodo (por ejemplo, durante el mantenimiento o después de un fallo), indicando que la redundancia se ha perdido temporalmente.
• Progreso de resincronización: Cuando un nodo que ha fallado se recupera, su estado cambia a naranja durante la reintegración de datos en segundo plano, lo que garantiza que no haya tiempo de inactividad durante la fase de "vuelta a la normalidad".

Más allá de los simples iconos de estado, la interfaz proporciona orquestación de failover con un solo clic, lo que permite intercambiar manualmente los roles (Primario/Secundario) para el mantenimiento planificado sin interrumpir la actividad de los usuarios.

El farm cluster de SafeKit está diseñado para la alta disponibilidad y escalabilidad de los servicios. La configuración se centra en distribuir el tráfico entrante entre ambos nodos de forma simultánea:

• Servicios con balanceo de carga (pestaña Macros): defina los servicios de aplicación específicos (por ejemplo, Apache, IIS, Nginx) que deben mantenerse activos en todos los nodos.
• Red(es) de Heartbeat: ruta(s) de comunicación utilizadas para detectar si un nodo ha abandonado la granja (farm), activando una redistribución inmediata de la carga.
• IP Virtual (Farm VIP): a diferencia de un mirror cluster, la VIP de la granja se comparte entre los nodos mediante un algoritmo de filtrado del kernel para distribuir el tráfico de red.
• Reglas de balanceo de carga: defina la política de distribución de tráfico basada en la dirección IP de origen o el puerto.
• Checkers (Verificadores): supervisan el estado de la aplicación y activan el reinicio automático si se detecta un fallo en un proceso.

La monitorización de un farm cluster proporciona visibilidad sobre la naturaleza Activo-Activo de la infraestructura, donde todos los nodos contribuyen al rendimiento de la aplicación (en este ejemplo se muestran 2 nodos):

• Estado UP (50% en 2 nodos): En una granja saludable, ambos nodos están en estado "UP" (50%), lo que significa que ambos reciben y procesan activamente las solicitudes de los clientes a través de la IP virtual compartida.
• Reequilibrio automático: Si un nodo falla, la consola muestra visualmente cómo el nodo restante asume el 100% del tráfico. No hay retraso por "failover", ya que el nodo superviviente ya está activo (más allá de un tiempo de detección de pocos segundos).
• Inserción de nodos: Cuando se reinicia un nodo reparado, este pasa de "STOP" a "UP" y comienza a recibir automáticamente su parte de la carga sin intervención del administrador.
• Sin sincronización de datos: Tenga en cuenta que en un farm cluster no existe el estado de resincronización "Naranja", ya que se espera que los nodos sean "stateless" (sin estado) o compartan una base de datos externa (que puede protegerse por separado en un mirror cluster).

Más allá de los simples iconos de estado, la interfaz permite la gestión de nodos con un solo clic, lo que le permite detener o iniciar manualmente un nodo para mantenimiento planificado, mientras la IP virtual compartida redistribuye automáticamente el tráfico sin interrumpir la actividad del usuario.