Evidian SafeKit: Software de Alta Disponibilidad Simple y Rentable

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

• Balanceo de carga
• Replicación de archivos síncrona en tiempo real
• Conmutación por error automática de aplicaciones
• Recuperación automática tras un fallo del servidor

SafeKit elimina los siguientes requisitos:

• Balanceadores de carga de red o servidores proxy dedicados
• Discos compartidos o almacenamiento SAN replicado
• Ediciones empresariales de sistemas operativos y bases de datos
• Habilidades especializadas para mantenimiento de clústeres

SafeKit resuelve:

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

Puede implementar replicación en tiempo real y conmutación por error para:

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

No. SafeKit es fácil de implementar: no se requiere experiencia avanzada.

No. SafeKit se ejecuta en sus servidores existentes, máquinas virtuales o en la nube, sin necesidad de discos compartidos ni almacenamiento SAN.

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

Este software independiente de la plataforma es ideal para los socios que revenden aplicaciones críticas y que necesitan ofrecer a sus clientes una opción simple y rentable de alta disponibilidad (HA) y redundancia del sistema, sin la complejidad y el gasto de las SAN (Storage Area Networks). Las características centrales de SafeKit —balanceo de carga (load balancing), replicación de datos en tiempo real y conmutación por error automática (automatic failover)— simplifican significativamente la integración de HA en cualquier oferta de servicio o producto.

Con una trayectoria probada y numerosas implementaciones en más de 30 países a través de nuestra extensa red de socios, SafeKit es reconocida como la solución HA más fácil y rápida de implementar para sistemas críticos. Esto incluye sectores como sistemas de gestión de video (VMS), control de acceso, gestión de edificios (BMS), software SCADA, logística automatizada y control crítico de tráfico aéreo/ferroviario, garantizando el máximo tiempo de actividad (uptime) en todos los ámbitos.

SafeKit ofrece un kit de recursos completo, gratuito y de acceso abierto para apoyar a sus socios, que incluye pruebas gratuitas, módulos de capacitación en línea integrales y la oportunidad de obtener la certificación oficial SafeKit sin costo. Estas herramientas permiten a los socios adquirir rápidamente las habilidades técnicas necesarias para implementar la solución de manera efectiva y brindar soporte de clase mundial, minimizando el tiempo de implementación y reduciendo la curva de aprendizaje.

En esta solución, solo se replican los datos de la aplicación. En caso de fallo, únicamente se reinicia la aplicación, no todo el sistema operativo ni la VM.

En esta solución, se replica la máquina virtual completa (VM), incluyendo tanto la aplicación como el sistema operativo (OS). En caso de fallo, se reinicia la VM completa.

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

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

Alternativa

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

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

Alternativa

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

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

Alternativa

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

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

Alternativa

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

El Servidor 1 (PRIM) ejecuta la aplicación. 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 tienes que configurar los nombres de los directorios a replicar en SafeKit. No hay requisitos previos sobre la organización del disco. Los directorios pueden estar ubicados en el disco del sistema.

Cuando el Servidor 1 falla, el Servidor 2 toma el control. SafeKit conmuta la dirección IP virtual y reinicia la aplicación 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, que 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 solo los archivos modificados en el Servidor 2 mientras el Servidor 1 estaba detenido.

El failback tiene lugar sin perturbar la aplicación, que puede seguir ejecutándose en el Servidor 2.

Después de la reintegración, los archivos vuelven a estar en modo mirror (espejo), como en el paso 1. El sistema vuelve al modo de **alta disponibilidad**, con la aplicación 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, puede ejecutar un comando de "**swap**" (intercambio) de forma manual en un momento apropiado o automáticamente a través de la configuración.

En la figura anterior, la aplicación 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 se configura localmente en cada servidor en el clúster farm.
El tráfico de entrada a la dirección IP virtual es recibido por todos los servidores y dividido entre ellos por 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 balanceo 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 otros servidores lo rechazan.
Una vez que un paquete es aceptado por el filtro en un servidor, solo la CPU y la memoria de este servidor son utilizadas por la aplicación que responde a la solicitud del cliente. Los mensajes de salida se envían directamente desde el servidor de aplicaciones al cliente.
Si un servidor falla, el protocolo heartbeat del clúster farm reconfigura los filtros en el clúster de balanceo de carga de red para reequilibrar el tráfico en los servidores disponibles restantes.

Con una aplicación 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 balanceo de carga de SafeKit se configura en la dirección IP del cliente. Por lo tanto, el mismo cliente está siempre conectado al mismo servidor en múltiples sesiones TCP. Y diferentes clientes se distribuyen a través de diferentes servidores en el clúster farm.
Con una aplicación sin estado (stateless), no existe afinidad de sesión. El mismo cliente puede estar conectado a diferentes servidores en el clúster farm en múltiples sesiones TCP. No hay contexto almacenado localmente en un servidor de una sesión a otra. En este caso, la regla de balanceo de carga de SafeKit se configura en la identidad de la sesión TCP del cliente. Esta configuración es la mejor para distribuir sesiones entre servidores, pero requiere un servicio TCP sin afinidad de sesión.

• SafeKit 8.2 para Windows (.exe con Microsoft Visual C++ Redistributable)
• SafeKit 8.2 para Windows (.msi sin Microsoft Visual C++ Redistributable)
• SafeKit 8.2 para Linux
• Descargar Versión Anterior 7.5

• Obtenga su clave de prueba de un mes de SafeKit

• SafeKit Guías Rápidas de Instalación
• Guía del Usuario SafeKit en HTML (Versión 8.2)
  (Descargar PDF)
• SafeKit Notas de la Versión en HTML (Versión 8.2)
  (Descargar PDF)
• SafeKit SRB (Boletín de Lanzamiento de Software con SO compatibles y Correcciones)

• Obtenga su Certificación SafeKit de Alta Disponibilidad de forma gratuita