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 pocos pasos, puede configurar un cluster espejo de SafeKit para garantizar la continuidad del negocio:

• Failover de Aplicación (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: Vía(s) de comunicación dedicada(s) utilizada(s) por los nodos del cluster para supervisar continuamente la salud y 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 del cliente después de un failover.
• Replicación en Tiempo Real: Seleccione los directorios críticos para la replicación síncrona basada en host a nivel de byte.
• Checkers (Verificadores): Supervistan la salud de la aplicación y activan la recuperación automática si se detecta un fallo en el proceso.

El cluster SafeKit incluye un verificador de split-brain dedicado para resolver problemas de aislamiento de red sin necesidad de una tercera máquina testigo (witness) o de una red de heartbeat adicional. Obtenga más información sobre heartbeat, failover y quórum en un cluster.

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

Para un cluster espejo de 2 nodos, la consola muestra claramente los roles de cada servidor:

• PRIM (Primary): El nodo activo que ejecuta actualmente la aplicación y gestiona la IP Virtual. Realiza escrituras en el almacenamiento local y la replicación en tiempo real en el nodo secundario.
• SECOND (Secondary): El nodo de reserva (standby) que recibe las actualizaciones síncronas a nivel de byte. Está listo para asumir el control instantáneamente si el Primario falla.
• Estado ALONE: Le alerta visualmente cuando el cluster se está ejecutando en un solo nodo (por ejemplo, durante tareas de mantenimiento o después de un fallo), lo que indica que la redundancia se ha perdido temporalmente.
• Progresso 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 "retorno a la normalidad".

Más allá de los simples iconos de estado, la interfaz proporciona una orquestación de failover con un solo clic, lo que le permite reasignar manualmente el rol primario para mantenimientos planificados, garantizando al mismo tiempo la disponibilidad continua para la actividad de los usuarios.

El cluster SafeKit en modo farm 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 simultáneamente:

• Servicios con equilibrio 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 utilizada(s) para detectar si un nodo ha abandonado la farm, lo que activa una redistribución inmediata de la carga.
• IP virtual (Farm VIP): A diferencia de un cluster mirror, la Farm VIP se comparte entre los nodos mediante un algoritmo de filtrado en el kernel para distribuir el tráfico de red.
• Reglas de equilibrio de carga: Defina la política de distribución del tráfico basándose en la dirección IP o el puerto de origen.
• Verificadores (Checkers): Monitorizan la salud de la aplicación y activan un reinicio automático si se detecta un fallo en un proceso.

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

• Estado UP (50% en 2 nodos): En una farm saludable, ambos nodos están en el estado "UP" (50%), lo que significa que ambos están recibiendo y procesando 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 unos pocos segundos).
• Inserción de nodos: Cuando un nodo reparado se reinicia, 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 cluster en modo farm no existe el estado de resincronización "Naranja", ya que se espera que los nodos no tengan estado (stateless) o compartan una base de datos en el backend (que puede protegerse por separado en un cluster mirror).

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