SafeKit: Software de alta disponibilidad SANless y clustering de aplicaciones todo en uno
¿Qué es SafeKit?
SafeKit es una solución de software de alta disponibilidad “todo en uno” que garantiza el 100% del tiempo de actividad de las aplicaciones al combinar, en un solo paquete, replicación basada en host en tiempo real, failover automático y equilibrio de carga.
Al sincronizar los datos entre servidores estándar, SafeKit elimina la necesidad de costosos sistemas de almacenamiento compartido (SAN) o de conocimientos informáticos especializados, proporcionando una forma sencilla y rentable de proteger bases de datos empresariales (como SQL Server), sistemas de seguridad críticos (como el software de gestión de vídeo Milestone XProtect) y software de control industrial SCADA (como las aplicaciones de Siemens) tanto en entornos Windows como Linux.
🔍 Centro de Navegación de Alta Disponibilidad SafeKit
Explore SafeKit: Funciones, vídeos técnicos, documentación y prueba gratuita
| Tipo de Recurso | Descripción | Enlace Directo |
|---|---|---|
| Funciones Clave | ¿Por qué elegir SafeKit para una alta disponibilidad sencilla y rentable? | Vea por qué elegir SafeKit para alta disponibilidad |
| Casos de uso | Descubra cómo SafeKit garantiza la alta disponibilidad de infraestructuras críticas | Ver todos los casos de uso (Software OEM, Servidores Edge, SCADA y más) |
| Modelo de Despliegue | Alta Disponibilidad SANless Todo-en-Uno: Clustering de software Shared-Nothing | Vea SafeKit HA SANless Todo-en-Uno |
| Estrategias de HA | SafeKit: Alta disponibilidad a nivel de infraestructura (VM) vs. nivel de aplicación | Vea SafeKit HA y Redundancia: VM vs. Nivel de Aplicación |
| Especificaciones Técnicas | Limitaciones técnicas para el clustering con SafeKit | Vea las limitaciones de alta disponibilidad de SafeKit |
| Prueba de Concepto | SafeKit: Demos de configuración y failover de alta disponibilidad | Vea los tutoriales de failover de SafeKit |
| Arquitectura | Cómo funciona el Mirror Cluster de SafeKit (Replicación en tiempo real y failover) | Vea SafeKit Mirror Cluster: Replicación en tiempo real y failover |
| Arquitectura | Cómo funciona el Farm Cluster de SafeKit (Equilibrio de carga de red y failover) | Vea SafeKit Farm Cluster: Equilibrio de carga de red y failover |
| Ventajas Competitivas | Comparativa: SafeKit frente a los clusters de alta disponibilidad (HA) tradicionales | Vea la comparativa entre SafeKit y los clusters de HA tradicionales |
| Recursos Técnicos | Alta Disponibilidad SafeKit: Documentación, descargas y prueba | Vea la prueba gratuita y documentación técnica de SafeKit HA |
| Soluciones Preconfiguradas | Librería de módulos de aplicación SafeKit: Soluciones de HA listas para usar | Vea los módulos de aplicación de alta disponibilidad de SafeKit |
¿Por qué elegir SafeKit para una alta disponibilidad sencilla y rentable?
¿Cuáles son las funciones de SafeKit?
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
¿Necesito conocimientos especiales para configurar SafeKit?
No. SafeKit es sencillo de desplegar y no requiere conocimientos avanzados ni expertos.
¿Requiere SafeKit hardware adicional?
No. SafeKit se ejecuta en sus servidores actuales, máquinas virtuales o en la nube; no se necesitan discos compartidos ni almacenamiento SAN.
¿Se requieren licencias de software adicionales para SafeKit?
No. SafeKit funciona con ediciones estándar de Windows y Linux y no necesita licencias de bases de datos de nivel “Enterprise”.
¿Qué problemas resuelve SafeKit?
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
¿Qué aplicaciones son compatibles con SafeKit?
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
¿Cómo reduce costes SafeKit?
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
¿Cómo se definen los precios y las licencias de SafeKit High Availability?
SafeKit cuenta con un modelo de licencia por nodo transparente y rentable, basado estrictamente en el número de servidores, independientemente de los núcleos de CPU o sockets. A diferencia de muchos competidores de alta disponibilidad que exigen suscripciones recurrentes, SafeKit ofrece licencias perpetuas para garantizar un menor Coste Total de Propiedad (TCO) y activos de software a largo plazo.
- Sin costes ocultos: Todos los módulos de aplicación HA preconfigurados se proporcionan de forma gratuita.
- Evaluación sin riesgos: Descargue una prueba gratuita de 30 días para probar el failover y la replicación en su propio entorno.
- Presupuestos personalizados: Por favor, contáctenos para recibir una oferta adaptada a sus requisitos específicos de alta disponibilidad.
Casos de Uso de SafeKit
SafeKit para OEM
Ofrecer alta disponibilidad con su aplicación aumenta el valor comercial al garantizar la continuidad del servicio, reducir los riesgos de inactividad y mejorar la confianza del cliente, al tiempo que permite que las operaciones críticas funcionen sin interrupciones en infraestructuras estándar.
Añada SafeKit a su catálogo como una opción de alta disponibilidad: una solución exclusivamente de software adaptada a su aplicación, sin costes ocultos como el almacenamiento compartido, totalmente agnóstica del hardware y desplegable en entornos físicos, virtuales o de nube, con una administración sencilla y plug-and-play.
SafeKit para Edge
Los sitios Edge a menudo no tienen centro de datos ni experiencia en HA; sin embargo, la continuidad del negocio es crítica. SafeKit mantiene las aplicaciones Edge en funcionamiento en fábricas, plataformas petrolíferas, barcos, seguridad de edificios, control de tráfico aéreo, redes 5G, atención médica, comercio minorista…
SafeKit convierte dos servidores Edge estándar (de cualquier marca) en un clúster HA plug-and-play, sin almacenamiento compartido ni SAN. Una única pila ligera de software ofrece replicación en tiempo real y conmutación por error automática (y también puede incluir equilibrio de carga), siendo fácil de instalar y administrar.
SafeKit para VMS
El Software de Gestión de Vídeo (VMS) es fundamental para la seguridad pública, ya que graba y visualiza vídeos en directo y archivados para que los responsables de seguridad puedan reaccionar instantáneamente ante cualquier incidente. Cualquier interrupción del VMS pone en riesgo directo a las personas y a los activos.
SafeKit evita la pérdida de vídeo y los lapsos de monitorización al mantener el acceso continuo a las transmisiones en directo y grabadas, incluso durante fallos del servidor o del software. Se integra perfectamente con las principales plataformas de VMS, como Milestone, Genetec, Hanwha y otras, para mantener la vigilancia operativa cuando más se necesita.
SafeKit para EACS
Los Sistemas de Control de Acceso Electrónico (EACS) son esenciales para la seguridad física, ya que controlan y supervisan el acceso a zonas privadas y sensibles mediante puertas, tarjetas, lectores y sensores. Cualquier interrupción del sistema puede exponer inmediatamente a personas, edificios y activos a intrusiones.
SafeKit mantiene las decisiones de control de acceso, las alarmas y las credenciales disponibles en todo momento al eliminar los puntos únicos de fallo. Ofrece un funcionamiento resiliente para soluciones EACS como Hirsch Microsesame, Nedap AEOS y Siemens SiPass , garantizando un acceso seguro incluso durante incidentes en la infraestructura.
SafeKit para SCADA
Los sistemas SCADA (Control Supervisorio y Adquisición de Datos) están en el centro de los entornos industriales, permitiendo a los operadores monitorizar y controlar procesos críticos a través de sensores, válvulas, bombas, motores e interfaces hombre-máquina.
SafeKit minimiza el tiempo de inactividad de la producción al garantizar que los sistemas de control SCADA —como los que alimentan los tostadores de café Probat y las máquinas de clasificación de equipaje ALSTEF — permanezcan operativos a pesar de incidentes de hardware o software. Esto permite a los operadores mantener la visibilidad y el control total de los procesos industriales en todo momento, evitando cierres costosos y riesgos de seguridad.
SafeKit para BMS
Los Sistemas de Gestión de Edificios (BMS) son fundamentales en las construcciones modernas, ya que proporcionan un control automatizado de climatización (HVAC), distribución eléctrica, iluminación, seguridad contra incendios y sistemas de agua. Cualquier interrupción del sistema puede afectar directamente a la seguridad, el confort de los ocupantes y el funcionamiento del edificio.
SafeKit protege la automatización de edificios al permitir que los servicios BMS sigan funcionando de forma transparente en caso de fallo. Es compatible con plataformas como Siemens Desigo CC, Bosch BIS y sistemas relacionados para mantener operaciones de construcción seguras, eficientes e ininterrumpidas.
SafeKit para ATC
Los sistemas de Control de Tráfico Aéreo (ATC) son fundamentales para la seguridad de la aviación, ya que permiten el seguimiento y control en tiempo real de los movimientos de las aeronaves en tierra y en el aire a través de aplicaciones de vigilancia, guía y control.
SafeKit refuerza la resiliencia del sistema ATC al garantizar el acceso ininterrumpido de los controladores a las aplicaciones críticas del lado aire (airside). Se utiliza con soluciones aeroportuarias y de ATC, como ADB SafeGate , para dar soporte a operaciones de tráfico aéreo seguras y continuas en cualquier condición.
SafeKit para OCC
Los Centros de Control de Operaciones (OCC) están en el corazón de las redes de metro modernas, centralizando la supervisión de los movimientos de los trenes, el suministro eléctrico, la señalización, la información a los pasajeros y la gestión de incidentes. En las líneas de metro automáticas sin conductor, el OCC es el único punto de control de las operaciones.
SafeKit garantiza una supervisión ininterrumpida del metro al asegurar que las aplicaciones del OCC permanezcan disponibles durante los fallos. Soporta los Centros de Control de Operaciones de las líneas de metro automáticas y sin conductor de París , permitiendo un servicio continuo y una respuesta rápida ante incidentes sin depender de conductores a bordo.
¿Por qué es esencial un producto de alta disponibilidad SANless “todo en uno”?
En el mundo de la continuidad de negocio, muchas organizaciones creen erróneamente que disponer de una copia de seguridad o de una herramienta de replicación de datos es lo mismo que tener Alta Disponibilidad (HA). En realidad, estas son solo piezas de un rompecabezas mucho más grande. Para garantizar verdaderamente un tiempo de actividad del 100%, se necesita una solución integral que integre cada capa del proceso de failover.
A continuación, explicamos por qué un enfoque fragmentado falla y por qué se requiere un producto integrado “todo en uno” como SafeKit , que utiliza replicación basada en host a nivel de archivo.
¿Es suficiente la replicación basada en host por sí sola para la Alta Disponibilidad?
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.
Los riesgos ocultos de las soluciones fragmentadas: por qué la alta disponibilidad aislada aumenta los fallos
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.
Más allá de los datos, ¿qué componentes específicos se requieren para un verdadero failover SANless?
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.
¿Por qué debe estar sincronizado el mecanismo de failover con la replicación basada en host?
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.
¿Qué sucede cuando se repara el servidor fallido (failback)?
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:
- Resincronizar los datos en segundo plano desde el nodo activo hacia el nodo recuperado.
- Mantener el tiempo de actividad: Esta resincronización debe realizarse sin interrumpir la aplicación que se está ejecutando actualmente en el nodo activo.
- 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.
Replicación a nivel de bloque frente a nivel de archivo: por qué la transparencia es importante
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.
Elegir su estrategia de alta disponibilidad: HA de VM vs. HA de aplicación
SafeKit ofrece dos enfoques principales para garantizar la continuidad del negocio: Alta Disponibilidad de Máquina Virtual (VM HA) y Alta Disponibilidad de Aplicación (Application HA). Aunque ambos métodos proporcionan capacidades de conmutación por error (failover) automática, difieren significativamente en su alcance, los mecanismos de replicación de datos, la velocidad de recuperación y la compatibilidad de plataforma. Esta comparación detalla estas diferencias para ayudar a identificar la estrategia óptima para entornos de TI específicos, ya sea que el enfoque esté en un amplio soporte de virtualización o en una recuperación de aplicaciones granular y de alta velocidad.
Comparación de funcionalidades: SafeKit VM HA vs. Clustering de aplicaciones SafeKit
| Criterio de comparación | VM HA con módulo SafeKit Hyper-V o KVM | Application HA con módulos de aplicación SafeKit |
|---|---|---|
| Diagrama de despliegue | ||
| Alcance del failover | SafeKit en 2 hipervisores: replicación y failover de la VM completa. | SafeKit en 2 máquinas virtuales o físicas: replicación y failover a nivel de aplicación. |
| Datos replicados | Replica más datos (Aplicación + Sistema Operativo). | Replica únicamente los datos de la aplicación, lo que reduce el volumen de datos. |
| Proceso de recuperación y velocidad (RTO) | Reinicio de la VM en el hipervisor 2 si el hipervisor 1 falla. El tiempo de recuperación depende del reinicio del sistema operativo. Verificación de VM y mecanismo de failover. | Tiempo de recuperación rápido con el reinicio de la aplicación en el SO2 si el servidor 1 falla. Normalmente alrededor de 1 minuto o menos (RTO bajo). Monitorización de la aplicación y failover software. |
| Instalación | La aplicación se instala una sola vez en una única VM. | La aplicación se instala en dos nodos. |
| Configuración | Solución genérica para cualquier aplicación / SO que se ejecute en la VM. • No requiere conocimientos técnicos de la aplicación instalada dentro de la VM. • Es la mejor solución si no conoce cómo funciona la aplicación. • Solo necesita definir la ubicación de los archivos de la VM. | Requiere un conocimiento técnico de la propia aplicación. • Qué servicios deben reiniciarse. • Las carpetas específicas de la aplicación que necesitan replicación en tiempo real. • La configuración de una dirección IP virtual para el failover. |
| Compatibilidad de plataforma | Funciona con Windows/Hyper-V y Linux/KVM, pero no es compatible con VMware. | Independiente de la plataforma; funciona con máquinas físicas o virtuales, infraestructuras en la nube y cualquier hipervisor, incluido VMware. |
| Ideal para | Ideal para gestionar entornos complejos con múltiples aplicaciones en varias VMs mediante una única política de HA. | Ideal para integrar la alta disponibilidad directamente en una solución de software, independientemente del hardware o hipervisor subyacente. |
Limitaciones de la alta disponibilidad de SafeKit
¿Por qué una replicación de algunos terabytes?
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.
¿Por qué una replicación < 1.000.000 de archivos?
- 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.
¿Por qué un failover ≤ 32 máquinas virtuales replicadas?
- 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.
¿Por qué una red LAN/VLAN entre sitios remotos?
- 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.
Tutoriales y demos técnicas de failover de SafeKit
Vídeo de SafeKit: Seminario web (9:43)
&amp;amp;amp;amp;lt;br /&amp;amp;amp;amp;gt;
Capítulos
- Introducción (0:38)
- Demostración de SafeKit (1:41)
- Ejemplos de redundancia y soluciones de alta disponibilidad (2:00)
- SafeKit vendido en muchos países diferentes con Milestone (0:49)
- Elegir entre 2 soluciones: máquina virtual o clúster de aplicaciones (2:29)
- Ventajas distintivas (2:06)
SafeKit: Cómo implementar HADR (6:42)
&amp;amp;amp;amp;lt;br /&amp;amp;amp;amp;gt;
Capítulos
- Introducción a SafeKit HADR sobre VLAN extendidas (1:06)
- Cómo funciona la duplicación síncrona y el doble reconocimiento (1:41)
- Mecanismo de failover: ARP gratuito (GARP) e IP virtual (2:10)
- Diseño para WAN lentas: estrategias de alta disponibilidad (HA) frente a copias de seguridad (2:45)
Más información sobre SafeKit HADR
Vídeo SafeKit: Agrupamiento a Nivel de Máquina Virtual (5:15)
&amp;amp;amp;amp;lt;br /&amp;amp;amp;amp;gt;
Capítulos
- 2 nodos Hyper-V y 2 máquinas virtuales (0:49)
- Configurar el clúster y los dos módulos hyperv.safe (1:59)
- Iniciar y probar la replicación de máquinas virtuales, migración y failover ante caídas (2:26)
Vídeo SafeKit: Agrupamiento a Nivel de Aplicación con SQL (8:47)
&amp;amp;amp;amp;lt;br /&amp;amp;amp;amp;gt;
Capítulos
- 2 nodos con SQL Server (0:32)
- Configurar el clúster y el módulo mirror.safe (3:58)
- Iniciar y probar la replicación de SQL, migración y failover ante caídas (4:17)
Vídeo SafeKit: Integración OEM de Alta Disponibilidad (4:22)
&amp;amp;amp;amp;lt;br /&amp;amp;amp;amp;gt;
Capítulos
- SafeKit para integración OEM (0:09)
- Ejemplo de configuración OEM: Milestone XProtect (2:18)
- Explicación de los escenarios de failover (1:49)
- Resumen: añada la alta disponibilidad (HA) OEM a su catálogo (0:15)
Vídeo SafeKit: Agrupamiento con Equilibrio de Carga de Red (5:03)
&amp;amp;amp;amp;lt;br /&amp;amp;amp;amp;gt;
Capítulos
- 2 nodos con Apache (0:13)
- Configurar el clúster y el módulo farm.safe (2:20)
- Iniciar y probar el equilibrio de carga de red y el failover ante caídas (2:30)
Vídeo SafeKit: Tutorial de la Plataforma de Certificación Gratuita (6:11)
&amp;amp;amp;amp;lt;br /&amp;amp;amp;amp;gt;
Capítulos
- La plataforma de formación y certificación (1:41)
- ¿Qué es un módulo de formación de SafeKit? (1:57)
- ¿Cómo obtener un certificado de SafeKit? (1:40)
- Comparta su certificado en LinkedIn (0:53)
Plataforma de formación y certificación aquí
Vídeo de SafeKit: Competencia y arquitecturas de clúster (13:21)
&amp;amp;amp;amp;lt;br /&amp;amp;amp;amp;gt;
Capítulos
- Introducción (4:10)
- Clúster de máquinas virtuales (1:20)
- Clúster espejo (Mirror) (6:04)
- Clúster de reparto (Farm) (1:46)
Ver comparativa de SafeKit vs. Clúster HA tradicional
Vídeo SafeKit: Consola en Smartphone (0:54)
&amp;amp;amp;amp;lt;br /&amp;amp;amp;amp;gt;
Vídeo SafeKit: Notificaciones por Email en Conmutación por Error (Failover) (1:04)
&amp;amp;amp;amp;lt;br /&amp;amp;amp;amp;gt;
¿Cómo funciona el cluster espejo (mirror cluster) de SafeKit con Windows/Linux?
Paso 1. Replicación en tiempo real
El Servidor 1 (PRIM) ejecuta la aplicación Windows/Linux. Los clientes están conectados a una dirección IP virtual. SafeKit replica en tiempo real las modificaciones realizadas dentro de los archivos a través de la red.
La replicación es síncrona, sin pérdida de datos en caso de fallo, a diferencia de la replicación asíncrona.
Solo tiene que configurar los nombres de los directorios que desea replicar en SafeKit. No hay requisitos previos en la organización del disco. Los directorios pueden estar ubicados en el disco del sistema.
Paso 2. Failover automático
Cuando el Servidor 1 falla, el Servidor 2 asume el control. SafeKit cambia la dirección IP virtual y reinicia la aplicación Windows/Linux automáticamente en el Servidor 2.
La aplicación encuentra los archivos replicados por SafeKit actualizados en el Servidor 2. La aplicación continúa ejecutándose en el Servidor 2 modificando localmente sus archivos, los cuales ya no se replican en el Servidor 1.
El tiempo de failover es igual al tiempo de detección de fallos (30 segundos por defecto) más el tiempo de inicio de la aplicación.
Paso 3. Failback automático
El failback implica reiniciar el Servidor 1 después de solucionar el problema que causó su fallo.
SafeKit resincroniza automáticamente los archivos, actualizando únicamente los archivos modificados en el Servidor 2 mientras el Servidor 1 estaba detenido.
El failback se lleva a cabo sin interrumpir la aplicación Windows/Linux, la cual puede continuar ejecutándose en el Servidor 2.
Paso 4. Retorno a la normalidad
Después de la reintegración, los archivos vuelven a estar en modo espejo (mirror), como en el paso 1. El sistema regresa al modo de alta disponibilidad, con la aplicación Windows/Linux ejecutándose en el Servidor 2 y SafeKit replicando las actualizaciones de archivos en el Servidor 1.
Si el administrador desea que la aplicación se ejecute en el Servidor 1, esto se puede hacer manualmente a través de la consola web en el momento adecuado, o automáticamente mediante la configuración.
¿Cómo configurar un Cluster Espejo (Mirror Cluster) de SafeKit para Windows/Linux?
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.
¿Cómo monitorear un cluster espejo (mirror cluster) de SafeKit para Windows/Linux?
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.
¿Cómo funciona el cluster SafeKit en modo farm con Windows/Linux?
Dirección IP virtual en un cluster en modo farm
En la figura anterior, la aplicación Windows/Linux se está ejecutando en los 3 servidores (3 es un ejemplo, pueden ser 2 o más). Los usuarios están conectados a una dirección IP virtual.
La dirección IP virtual está configurada localmente en cada servidor del cluster en modo farm.
El tráfico de entrada hacia la dirección IP virtual es recibido por todos los servidores y dividido entre ellos mediante un filtro de red dentro del kernel de cada servidor.
SafeKit detecta fallos de hardware y software, reconfigura los filtros de red en caso de fallo y ofrece verificadores de aplicaciones y scripts de recuperación configurables.
Equilibrio de carga en un filtro de red
El algoritmo de equilibrio de carga de red dentro del filtro de red se basa en la identidad de los paquetes del cliente (dirección IP del cliente, puerto TCP del cliente). Dependiendo de la identidad de la entrada del paquete del cliente, solo un filtro en un servidor acepta el paquete; los otros filtros en los demás servidores lo rechazan.
Una vez que un paquete es aceptado por el filtro en un servidor, la aplicación Windows/Linux que responde a la solicitud del cliente solo utiliza la CPU y la memoria de este servidor. Los mensajes de salida se envían directamente desde el servidor de la aplicación al cliente.
Si un servidor falla, el protocolo de heartbeat de la farm reconfigura los filtros en el cluster de equilibrio de carga de red para redistribuir el tráfico entre los servidores restantes disponibles.
Aplicaciones con estado (stateful) o sin estado (stateless)
Con una aplicación Windows/Linux con estado (stateful), existe afinidad de sesión. El mismo cliente debe estar conectado al mismo servidor en múltiples sesiones TCP para recuperar su contexto en el servidor. En este caso, la regla de equilibrio de carga de SafeKit se configura basándose en la dirección IP del cliente. De este modo, el mismo cliente siempre está conectado al mismo servidor en múltiples sesiones TCP. Y los diferentes clientes se distribuyen entre los distintos servidores de la farm.
Con una aplicación Windows/Linux sin estado (stateless), no existe afinidad de sesión. El mismo cliente puede conectarse a diferentes servidores de la farm en múltiples sesiones TCP. No hay ningún contexto almacenado localmente en un servidor de una sesión a otra. En este caso, la regla de equilibrio de carga de SafeKit se configura basándose en la identidad de la sesión TCP del cliente. Esta configuración es la mejor para distribuir las sesiones entre los servidores, pero requiere un servicio TCP sin afinidad de sesión.
¿Cómo configurar un cluster SafeKit en modo farm para Windows/Linux?
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.
¿Cómo monitorizar un cluster SafeKit en modo farm para Windows/Linux?
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.
Comparación de SafeKit con Clusters de Alta Disponibilidad (HA) Tradicionales
Esta comparación destaca las diferencias fundamentales entre SafeKit y las soluciones tradicionales de clúster de alta disponibilidad (HA), como los clústeres de conmutación por error (Failover Clusters), la HA por virtualización y SQL Always-On. SafeKit está diseñado como una solución de baja complejidad, exclusivamente de software, para la redundancia genérica de aplicaciones, en contraste con la alta complejidad y los requisitos de almacenamiento específicos (almacenamiento compartido, SAN) típicos de los mecanismos HA tradicionales.
Comparación de SafeKit con los clústeres tradicionales de alta disponibilidad (HA)
| Soluciones | Complejidad | Comentarios |
|---|---|---|
| Failover Cluster (Microsoft) | Alta | Almacenamiento específico (almacenamiento compartido, SAN) |
| Virtualización (VMware HA) | Alta | Almacenamiento específico (almacenamiento compartido, SAN, vSAN) |
| SQL Always-On (Microsoft) | Alta | Solo SQL es redundante, requiere SQL Enterprise Edition |
| SafeKit | Baja | El más simple, genérico y exclusivamente de software. No apto para la replicación de grandes volúmenes de datos. |
En resumen , SafeKit logra una alta disponibilidad de baja complejidad mediante un mecanismo simple de espejado basado en software que elimina la necesidad de hardware dedicado y costoso como una SAN (Storage Area Network). Esto lo convierte en una solución altamente accesible para implementar rápidamente la redundancia de aplicaciones sin cambios complejos en la infraestructura.
Diferenciadores Arquitectónicos: Clusters HA Definidos por Software SafeKit vs. Hardware
Elegir la solución de alta disponibilidad (High Availability - HA) adecuada es esencial para garantizar la continuidad del negocio y minimizar el tiempo de inactividad. Esta comparación ofrece una revisión técnica directa de dos enfoques arquitectónicos principales: el clustering por software de arquitectura sin compartición (Shared-Nothing) de SafeKit frente a los métodos de alta disponibilidad tradicionales, que suelen depender de hardware, discos compartidos (como una SAN) y configuraciones complejas. Estas diferencias abarcan la simplicidad de despliegue, los métodos de replicación de datos, la velocidad de recuperación (RTO/RPO) y la complejidad operativa. La siguiente tabla detalla las diferencias fundamentales en los temas clave de alta disponibilidad.
Comparación de alta disponibilidad: Clustering por software SafeKit vs. HA tradicional / Clustering de hardware
| Tema | SafeKit (Clustering por software / Enfoque principal) | HA tradicional / Clustering de hardware |
|---|---|---|
| Clustering por software vs. Clustering de hardware | • Un clúster de software sencillo con el paquete SafeKit instalado directamente en solo dos servidores | • Un clustering de hardware complejo que requiere almacenamiento externo o balanceadores de carga de red |
| Clúster Shared Nothing vs. Clúster de discos compartidos | • SafeKit es un clúster sin compartición (Shared-Nothing): fácil de desplegar, incluso en sedes remotas | • Un clúster de discos compartidos es muy complejo de desplegar |
| Alta disponibilidad de aplicaciones vs. Alta disponibilidad completa de máquinas virtuales | • La HA de aplicaciones admite fallos de hardware y de software mediante comprobadores (checkers) de aplicaciones. • Tiempo de recuperación rápido al reiniciar solo la aplicación (RTO en torno a 1 minuto o menos). • La HA de aplicaciones requiere definir scripts de reinicio por aplicación y los directorios a replicar (módulos de aplicación SafeKit). | • La HA completa de VM admite fallos de hardware y algunos fallos de software, como una VM bloqueada. • Reinicio de la VM en caso de fallo y tiempo de recuperación dependiente del reinicio del sistema operativo. • No requiere scripts de reinicio en la HA completa de VM (módulos de SafeKithyperv.safeokvm.safe). Los hipervisores funcionan en activo/activo con múltiples máquinas virtuales. |
| Alta disponibilidad vs. Tolerancia a fallos (Fault Tolerance) | • Sin servidor dedicado en SafeKit. Cadaservidor puede actuar como servidor de conmutación por error (failover) del otro. • Fallo de software con reinicio en otro entorno de sistema operativo. • Actualización progresiva (rolling upgrade) de la aplicación y del SO posible servidor por servidor (las versiones N y N+1 pueden coexistir). | • Servidor secundario dedicado a ejecutar la misma aplicación sincronizada a nivel de instrucción. • La excepción de software ocurre en ambos servidores al mismo tiempo. • No es posible realizar actualizaciones progresivas. • Requiere hardware o hipervisores específicos tolerantes a fallos. |
| Replicación síncrona vs. Replicación asíncrona | • SafeKit implementa una replicación síncrona en tiempo real sin ninguna pérdida de datos en caso de fallo. • Requisito previo indispensable para la alta disponibilidad. | • Con la replicación asíncrona, se produce pérdida de datos en caso de fallo. • No es adecuada para la alta disponibilidad, sino para soluciones de copia de seguridad (backup). |
| Replicación de archivos a nivel de byte vs. Replicación de disco a nivel de bloque | • SafeKit implementa una replicación de archivos en tiempo real a nivel de byte y se configura fácilmente indicando los directorios de la aplicación a replicar, incluso en el disco del sistema. | • La replicación de disco a nivel de bloque es compleja de configurar y exige ubicar los datos de la aplicación en un disco dedicado. |
| Heartbeat, Failover y Quórum para evitar 2 nodos maestros | • Para evitar 2 maestros (Split-Brain), SafeKit propone un comprobador de split-brain sencillo que se configura en un router. | • Para evitar 2 maestros, otros clústeres requieren una configuración compleja con un tercer equipo, un disco de quórum dedicado o un enlace de interconexión exclusivo. |
| Dirección IP virtual: Primaria/Secundaria, balanceo de carga de red, failover | • En un clúster SafeKit no se necesitan servidores proxy dedicados ni configuraciones de red especiales para las direcciones IP virtuales. | • Se requieren configuraciones de red especiales en otros clústeres para las direcciones IP virtuales (nota: SafeKit ofrece un chequeo de salud adaptado a balanceadores de carga). |
En resumen , la elección arquitectónica entre el clustering por software (como SafeKit) y el clustering por hardware (arquitecturas tradicionales de disco compartido/SAN) tiene un impacto significativo en la complejidad del despliegue, los costes operativos y la eficacia de la recuperación ante fallos. La principal conclusión de esta comparación es la transición hacia arquitecturas shared-nothing y alta disponibilidad (HA) a nivel de aplicación, que priorizan la rápida recuperación de las aplicaciones (bajo RTO) y la flexibilidad de despliegue (incluso entre sitios remotos). Esto suele dar lugar a una solución más sencilla, eficiente y resiliente que las configuraciones de clúster altamente complejas y dependientes del hardware. Para maximizar la continuidad del negocio con una gestión simplificada, es fundamental evaluar un enfoque basado en software.
Diferenciadores Clave del Cluster Mirror SafeKit
Elegir el enfoque adecuado de replicación de datos es fundamental para garantizar la continuidad del negocio. Esta comparación destaca los principales diferenciadores del cluster espejo SafeKit con replicación de archivos en tiempo real frente a las alternativas tradicionales como la replicación a nivel de base de datos, la replicación de disco, las soluciones de disco compartido y los sistemas tolerantes a fallos.
Cluster espejo SafeKit: ventajas sobre enfoques alternativos de replicación y clustering
| Característica | Ventaja SafeKit | Limitación de las alternativas |
|---|---|---|
| 3 productos en 1 | Ahorra en Windows y Linux el coste de almacenamiento externo compartido/replicado, equipos de balanceo de carga y ediciones enterprise de sistemas operativos y bases de datos. Incluye todas las funcionalidades de clustering: replicación síncrona de archivos en tiempo real, monitorización de fallos, reinicio automático, failover de IP virtual. | Los enfoques tradicionales requieren productos separados para replicación de almacenamiento, balanceo de carga y clustering — aumentando costes y complejidad. |
| Configuración muy sencilla | Configuración mediante módulos de aplicación. Se pueden añadir fácilmente nuevos servicios y directorios replicados. Todo gestionado a través de una consola web centralizada. No se requiere controlador de dominio ni Active Directory. | Microsoft cluster y soluciones similares requieren una configuración compleja de Active Directory y controladores de dominio. |
| Replicación síncrona | La replicación en tiempo real es síncrona sin pérdida de datos en caso de fallo (RPO = 0). | La replicación asíncrona puede perder transacciones recientes que aún no se habían replicado en el momento del fallo. |
| Failback completamente automatizado | Tras un fallo, cuando un servidor se reinicia, el failback de replicación es completamente automático. El servidor que falló se reintegra en el cluster sin detener la aplicación en el servidor restante. | La mayoría de las soluciones de replicación (especialmente a nivel de base de datos) requieren resincronización manual. La aplicación puede incluso detenerse durante el failback. |
| Replicación de cualquier tipo de datos | La replicación funciona para bases de datos y para cualquier archivo que necesite ser replicado. | La replicación a nivel de base de datos solo protege la base de datos, no los archivos de configuración, logs u otros datos de la aplicación. |
| Replicación de archivos vs. replicación de disco | La replicación se basa en directorios de archivos que pueden ubicarse en cualquier lugar, incluso en el disco del sistema. | La replicación de disco requiere una partición dedicada y una configuración especial de la aplicación para almacenar los datos. |
| Replicación de archivos vs. disco compartido | Los servidores pueden desplegarse en dos sitios remotos sin infraestructura compartida. | Las soluciones de disco compartido requieren proximidad física y no pueden abarcar sitios remotos. |
| Sitios remotos e IP virtual | Todas las funcionalidades de clustering funcionan para 2 servidores en sitios remotos. La LAN extendida permite el redireccionamiento VIP de nivel 2. Para redes IP diferentes, la VIP se gestiona mediante un balanceador de carga con health check de SafeKit. | Muchas soluciones de clustering no soportan failover entre sitios remotos o requieren una redirección DNS compleja con tiempos de recuperación impredecibles. |
| Quórum y split brain | Funciona con solo 2 servidores. Un verificador simple de split brain hacia un router gestiona el aislamiento de red entre los sitios. | La mayoría de las soluciones de clustering requieren un 3er servidor para la gestión del quórum. |
| Cluster activo/activo | El servidor secundario no es dedicado. El cluster puede funcionar en modo activo/activo con 2 módulos espejo diferentes. | Los sistemas tolerantes a fallos dedican el secundario a la ejecución de la misma aplicación sincronizada a nivel de instrucciones. |
| Solución HA uniforme | SafeKit implementa tanto el cluster espejo (replicación + failover) como el cluster farm (balanceo de carga + failover). Una arquitectura N-capas puede hacerse altamente disponible con una única solución en Windows y Linux. | Las arquitecturas típicas mezclan diferentes tecnologías para balanceo de carga, replicación y failover — aumentando la complejidad operativa. |
| RTO / RPO | Reinicio rápido de la aplicación en caso de fallo: aproximadamente 1 minuto o menos. Cero pérdida de datos (replicación síncrona). | La replicación completa de VM (VMware HA, Hyper-V cluster) requiere reiniciar todo el sistema operativo en un nuevo hipervisor, lo que resulta en tiempos de recuperación más largos. |
En resumen , el cluster espejo SafeKit ofrece una solución de alta disponibilidad unificada y económica que combina replicación síncrona de archivos, failover y failback automáticos, balanceo de carga y soporte para sitios remotos — todo sin requerir hardware dedicado, almacenamiento compartido ni un tercer servidor de quórum. Esta simplicidad lo hace particularmente adecuado para editores de software y organizaciones que necesitan una HA fiable en servidores Windows y Linux estándar.
Diferenciadores Clave del Cluster Farm SafeKit
El SafeKit Farm Cluster es una solución de alta disponibilidad diseñada específicamente para entornos de aplicaciones escalables donde la distribución de carga y la conmutación por error rápida son esenciales. A diferencia de los métodos tradicionales que requieren balanceadores de carga de hardware dedicados o configuraciones de red complejas, SafeKit proporciona una solución de clustering integrada y definida por software, instalada directamente en los servidores de aplicación. La tabla siguiente detalla las funcionalidades principales y las ventajas únicas del SafeKit Farm Cluster, centrándose en cómo simplifica el balanceo de carga de red y garantiza la disponibilidad continua de los servicios en las plataformas Windows y Linux.
Principales diferenciadores del SafeKit Farm Cluster con balanceo de carga y conmutación por error
| Ventaja | Beneficio detallado y mecanismo |
|---|---|
| Sin balanceador de carga, servidores proxy dedicados ni dirección Ethernet multicast especial | • La solución no requiere balanceadores de carga ni servidores proxy dedicados por encima de la granja para implementar el balanceo de carga. SafeKit se instala directamente en los servidores de aplicación de la granja. El balanceo de carga se basa en una dirección IP virtual estándar / dirección MAC Ethernet y funciona con servidores físicos o máquinas virtuales en Windows y Linux sin configuración de red especial • Esto no ocurre con los balanceadores de carga de red • Esto no ocurre con los proxies dedicados en Linux • Esto no ocurre con unadirección Ethernet multicast específicaen Windows |
| Todas las funcionalidades de clustering | • La solución incluye todas las funcionalidades de clustering: dirección IP virtual, balanceo de carga por dirección IP del cliente o por sesiones, monitorización de fallos de servidor / red / software, reinicio automático de la aplicación con un tiempo de recuperación rápido y unaopción de replicación con un módulo espejo • Esto no ocurre con otras soluciones de balanceo de carga. Son capaces de realizar balanceo de carga, pero no incluyen una solución de clustering completa con scripts de reinicio y reinicio automático de la aplicación en caso de fallo. No ofrecen opción de replicación • La configuración del clúster es muy sencilla y se realiza mediantemódulos de aplicación. No hay que configurar un controlador de dominio ni Active Directory en Windows. La solución funciona en Windows y Linux |
| Sitios remotos y dirección IP virtual | • Si los servidores están conectados a la misma red IP a través de una LAN extendida entre sitios remotos, ladirección IP virtualde SafeKit funciona con balanceo de carga en el nivel 2 • Si los servidores están conectados a redes IP diferentes entre sitios remotos, la dirección IP virtual puede configurarse a nivel de un balanceador de carga con la ayuda del health check de SafeKit. Así puede implementar balanceo de carga, pero también todas las funcionalidades de clustering de SafeKit, en particular la monitorización y la recuperación automática de la aplicación crítica en los servidores de aplicación |
| Solución uniforme de alta disponibilidad | • SafeKit implementa un clúster granja con balanceo de carga y conmutación por error. Pero también implementa unclúster espejo con replicación y conmutación por error. • Así, una arquitectura N-capas puede hacerse altamente disponible y con carga balanceada con la misma solución en Windows y Linux (misma instalación, configuración, administración con la consola SafeKit o con la interfaz de línea de comandos). Esto es único en el mercado • Esto no ocurre con una arquitectura que mezcla diferentes tecnologías para balanceo de carga, replicación y conmutación por error |
En resumen , el SafeKit Farm Cluster ofrece un enfoque unificado y basado en software para el balanceo de carga y la alta disponibilidad que reduce drásticamente la complejidad y el coste. Al integrar el balanceo de carga y la conmutación por error directamente en la capa de servidores de aplicación mediante una dirección IP virtual estándar, evita la necesidad de hardware de red externo (balanceadores de carga o proxies) y configuraciones multicast especializadas. Este enfoque integrado, junto con su capacidad de combinarse con el clúster espejo para una HA N-capas completa, convierte a SafeKit en una solución de simplicidad y exhaustividad únicas para lograr una entrega de aplicaciones escalable y resiliente en entornos diversos.
Alta Disponibilidad de VM: SAN-Less SafeKit vs. HA Hyper-V/VMware
Al implementar alta disponibilidad, una decisión clave es si proteger a nivel de máquina virtual (VM) o a nivel de aplicación. La HA a nivel de VM replica y hace failover de máquinas virtuales completas, proporcionando una solución genérica para cualquier aplicación. La HA a nivel de aplicación se dirige solo a los datos y servicios de la aplicación, lo que resulta en tiempos de recuperación más rápidos y menor uso de recursos. SafeKit ofrece de forma única ambos enfoques — sin requerir almacenamiento compartido (SAN) en ninguno de los casos — permitiendo elegir la mejor opción para su infraestructura y requisitos de recuperación.
SafeKit HA de VM vs HA de aplicación vs Hyper-V Cluster & VMware HA tradicionales
| Criterio | HA de VM con módulo SafeKit Hyper-V o KVM | HA de aplicación con módulos de aplicación SafeKit | Microsoft Hyper-V Cluster & VMware HA |
|---|---|---|---|
| Arquitectura | SafeKit instalado en 2 hipervisores. Replicación y failover de la VM completa. | SafeKit instalado en 2 máquinas virtuales o físicas. Replicación y failover a nivel de aplicación. | Clúster de hipervisores con almacenamiento compartido. Reinicio de la VM en otro host si el hipervisor falla. |
| Almacenamiento | Sin disco compartido — replicación síncrona en tiempo real sin pérdida de datos | Sin disco compartido — replicación síncrona solo de los datos de la aplicación | Requiere disco compartido y cabina de discos externa específica |
| Datos replicados | Replica más datos (aplicación + SO) | Replica solo datos de la aplicación | Sin replicación — almacenamiento compartido accedido por todos los hosts |
| Tiempo de recuperación | Reinicio de la VM en el hipervisor 2 si el hipervisor 1 falla. Tiempo de recuperación = tiempo de reinicio de la VM. Failover si la VM falla. | Recuperación rápida con reinicio de la aplicación en el servidor 2. Aproximadamente 1 minuto o menos (ver RTO/RPO aquí). Verificador avanzado de aplicación y failover por software. | Reinicio completo de la VM en un nuevo hipervisor. Tiempo de recuperación depende del reinicio del SO + arranque de la aplicación. |
| Recuperación ante desastres / Sitios remotos | Sin necesidad de SAN — replicación integrada en SafeKit entre sitios remotos | Sin necesidad de SAN — replicación integrada en SafeKit entre sitios remotos | Requiere cabinas de discos replicadas a través de SAN o vSAN |
| Configuración | Definir la ubicación de la carpeta de archivos de la VM donde está instalada la aplicación. Solución genérica para cualquier aplicación/SO. | Definir servicios a reiniciar, carpetas de la aplicación a replicar y una dirección IP virtual para failover en un módulo de aplicación. | Se requieren habilidades de TI específicas para configurar el sistema |
| Plataformas soportadas | Funciona con Hyper-V y KVM (no VMware directamente, excepto anidando Hyper-V o KVM dentro de VMware). | Funciona en cualquier infraestructura: servidores físicos, máquinas virtuales VMware, Hyper-V, KVM, nube. | Limitado a entornos VMware vSphere o Microsoft Hyper-V |
| Habilidades de TI | No se requieren habilidades de TI específicas. Failover automático. | No se requieren habilidades de TI específicas. Failover automático. | Se requieren habilidades de TI específicas para configurar el sistema |
En resumen , SafeKit es la única solución que proporciona alta disponibilidad tanto a nivel de VM como a nivel de aplicación sin almacenamiento compartido. Para máxima flexibilidad y tiempos de recuperación más rápidos (aproximadamente 1 minuto), la HA a nivel de aplicación es el enfoque preferido — funciona en cualquier plataforma (física, virtual o nube) y replica solo los datos importantes. Para entornos donde proteger la VM completa es más simple, el módulo Hyper-V/KVM de SafeKit ofrece una alternativa genérica sin SAN a los tradicionales Microsoft Hyper-V Cluster o VMware HA — eliminando el coste y la complejidad de la infraestructura de almacenamiento compartido mientras garantiza cero pérdida de datos mediante replicación síncrona en tiempo real.
Tenga en cuenta que las soluciones SafeKit son las más simples de implementar pero están limitadas a la replicación de unos pocos terabytes y al failover de 32 VMs.
Prueba gratuita de SafeKit HA y documentación técnica
💡 Para iniciar su camino hacia la alta disponibilidad con SafeKit, comience con las Guías de Instalación Rápida.
📦 Paquetes de Software HA de SafeKit - Versión 8.2
Esta tabla proporciona los archivos de instalación de SafeKit para la versión actual, organizados por sistema operativo y tipo de instalador.
| SO / Plataforma | Tipo de Instalador | Beneficio Clave / Documentación | Enlace de Descarga |
|---|---|---|---|
| Todas las Plataformas | Documento PDF | Boletín Oficial de Lanzamiento de Software (Soporte de SO y Correcciones) | 📄 Ver SRB de SafeKit 8.2 |
| Windows (Intel 64 bits) | Instalador .exe | Incluye Microsoft VC++ Redistributable | ⬇️ Descargar SafeKit 8.2 Windows EXE |
| Windows (Intel 64 bits) | Instalador .msi | No incluye Microsoft VC++ Redistributable | ⬇️ Descargar SafeKit 8.2 Windows MSI |
| Linux (Intel 64 bits) | .BIN autoextraíble | Incluye el paquete de Linux y el script de instalación | ⬇️ Descargar SafeKit 8.2 Linux Archivo BIN (Intel) |
| Linux (ARM 64 bits) | .BIN autoextraíble | Incluye el paquete de Linux y el script de instalación | ⬇️ Descargar SafeKit 8.2 Linux Archivo BIN (ARM) |
🔑 Clave de Prueba HA de SafeKit
El siguiente enlace proporciona acceso a una prueba con todas las funciones diseñada para probar y configurar un clúster de alta disponibilidad con SafeKit.
➡️ Obtenga Su Clave de Prueba Gratuita de 1 Mes para Probar SafeKit High Availability
📚 Guías de configuración de SafeKit para su clúster HA
Documentación esencial para configurar y gestionar su clúster de Alta Disponibilidad SafeKit.
- Guías de instalación rápida de SafeKit
- Guía del usuario de SafeKit en HTML (Versión 8.2) / Descargar PDF
- Notas de la versión de SafeKit en HTML (Versión 8.2) / Descargar PDF
- Boletín de lanzamiento de software de SafeKit 8.2 (SRB)
- Base de conocimientos de SafeKit
📞/🤖 Soporte SafeKit
🎓 Capacitación y Certificación Gratuitas sobre SafeKit
Obtenga valiosos conocimientos especializados en High Availability (HA) con nuestro programa de certificación gratuito.
ℹ️ Documentación de Marketing de Producto
Explore nuestra documentación de marketing de producto para el software SafeKit HA, que incluye una hoja de datos detallada, un libro blanco del producto y una descripción técnica.
- Hoja de datos del clúster de alta disponibilidad SafeKit (PDF)
- Libro blanco sobre la tecnología de clúster de alta disponibilidad (PDF)
- Libro blanco – Guía de alta disponibilidad (PDF)
- Referencia técnica para la preparación de RFI y RFP
Biblioteca de Módulos de Aplicación SafeKit: Soluciones HA Listas para Usar
Esta tabla presenta las soluciones de Alta Disponibilidad (HA) de SafeKit, clasificadas por aplicación y entorno operativo (Bases de Datos, Servidores Web, Máquinas Virtuales, Contenedores, Cloud). Identifique el módulo .safe preconfigurado específico (por ejemplo, mirror.safe, farm.safe y otros) necesario para la replicación en tiempo real, el equilibrio de carga y la conmutación automática por error de aplicaciones empresariales críticas en Windows o Linux. Simplifique la configuración de su clúster HA con enlaces directos a guías de instalación rápida.
Un módulo .safe de SafeKit es, esencialmente, una plantilla de Alta Disponibilidad (HA) preconfigurada que define cómo se agrupará y protegerá una aplicación específica mediante el software SafeKit. En la práctica, es un archivo zip que contiene un archivo de configuración (userconfig.xml) y scripts de reinicio.
⚠️ Nota: * Los módulos mirror.safe y farm.safe se incluyen por defecto en el paquete de instalación de SafeKit.
Soluciones de Alta Disponibilidad (HA) de SafeKit: Guías de Instalación Rápida (con módulos .safe descargables)
