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.
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 |
SafeKit ofrece las siguientes funciones para Windows y Linux en un único producto de software:
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:
Puede implementar replicación en tiempo real y failover para:
SafeKit elimina los siguientes requisitos:
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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:
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:
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:
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:
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.
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. |
Tiempo de resincronización después de una falla (paso 3)
<br />
<br />
Más información sobre SafeKit HADR
<br />
<br />
<br />
<br />
<br />
Plataforma de formación y certificación aquí
<br />
Ver comparativa de SafeKit vs. Clúster HA tradicional
<br />
<br />
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.
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.
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.
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.
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:
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:
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.
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.
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.
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.
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:
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):
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.
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.
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.
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.
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.
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.
💡 Para iniciar su camino hacia la alta disponibilidad con SafeKit, comience con las Guías de Instalación Rápida.
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) |
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
Documentación esencial para configurar y gestionar su clúster de Alta Disponibilidad SafeKit.
Obtenga valiosos conocimientos especializados en High Availability (HA) con nuestro programa de certificación gratuito.
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.
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)