Alta disponibilidad Hyper-V con SafeKit: instale el módulo hyperv.safe para conmutación por error

Guía de instalación rápida de alta disponibilidad para Hyper-V

Esta guía explica cómo configurar un mirror cluster para Hyper-V usando SafeKit, lo que garantiza la conmutación por error automática y la replicación sincrónica sin necesidad de almacenamiento compartido.

Para obtener ayuda, puede usar SafeKit AI 🤖.

1. Descripción general

• Arquitectura: Utiliza un sistema de dos nodos (primario/secundario).
• Protección de datos: Implementa replicación síncrona en tiempo real para cero pérdida de datos (RPO=0).

2. Instalación

• Programas: Instale el motor SafeKit en ambos servidores.
• Módulo: Descargue el módulo de aplicación preconfigurado hyperv.safe.

3. Configuration

• Consola web: Configure las carpetas específicas que contienen los archivos de Hyper-V.
• Supervisión: Comience a supervisar y proteger la aplicación Hyper-V.

Limitaciones de alta disponibilidad de SafeKit

Descripción general de la solución SafeKit / Hyper-V

La solución se describe aquí: 💡Simple Hyper-V Alta disponibilidad sin almacenamiento compartido (SAN)

Instalación de la solución SafeKit / Hyper-V en Windows (hyperv.safe)

Requisitos previos

• Rol Hyper-V instalado en 2 nodos Windows (integrado de forma gratuita en todas las versiones de Windows, incluido Windows para PC).
• Aplicaciones críticas instaladas dentro de una o más máquinas virtuales.
• Máximo 32 máquinas virtuales por host Hyper-V.
• El total de datos replicados se limita a unos pocos terabytes; más allá de esto, el tiempo de resincronización se vuelve significativo.
• Interconexión mínima de 1 Gb/s entre nodos (se recomiendan 10 Gb/s para una resincronización más rápida).
• La conmutación por error de IP requiere ambos nodos en el mismo LAN o LAN extendido (L2); no se admiten redes L3 enrutadas (excepto con 🛠️ equilibradores de carga en la nube).

Acerca de los productos bajo licencia Siemens LMS

• Para evitar que la licencia de Siemens deje de funcionar durante la conmutación por error, el dongle que contiene la clave puede conectarse a un dispositivo USB over IP (como DIGI AnywhereUSB).
• El dongle también puede conectarse a un PC externo que ejecute el servidor de licencias LMS.
• En las versiones recientes del sistema de licencias Siemens, la clave puede almacenarse en el Trusted Platform Module (TPM) de la VM.

Instalación del paquete en Windows

• Descargue e instale la versión gratuita de SafeKit en 2 nodos Windows.
  Nota: la versión gratuita incluye todas las funciones de SafeKit. Al final del período de prueba, puede activar las claves de licencia permanentes sin desinstalar el paquete.
• Al completar la instalación del paquete, seleccione Set console credentials and firewall rules now y configure una contraseña para el usuario admin de la consola SafeKit.
  Establezca la misma contraseña en todos los nodos.
• Excluya de los análisis antivirus C:/safekit/ (el directorio de instalación predeterminado) y todas las carpetas replicadas que vaya a definir.
  Debido a su estrecha integración con el sistema operativo, algunos componentes de SafeKit pueden ser detectados por los antivirus, incluidos los mecanismos de IP virtual, la replicación en tiempo real y el reinicio de servicios críticos.

Descargar SafeKit (Windows) >

Instalación del módulo en Windows

• Descargue el módulo hyperv.safe. El módulo es gratuito. Contiene los archivos userconfig.xml y los scripts de reinicio.
• Coloque hyperv.safe en C:/safekit/Application_Modules/generic.

Descargar hyperv.safe (Windows) >

Configuración paso a paso de la solución SafeKit / Hyper-V

⚠️ Lee atentamente estos ítems antes de comenzar:

• La configuración Hyper-V se presenta con una máquina virtual llamada VM1. Lea atentamente “1. Requisitos previos” para el organización de archivos VM1 ; de lo contrario, la recuperación en el nodo secundario puede fallar con datos inconsistentes.
• Tendrá que repetir esta configuración para todas las máquinas virtuales que desee replicar y reiniciar.
• El sistema de archivos donde se almacenan los archivos VM replicados por SafeKit debe ser NTFS; ReFS no es compatible.
• SafeKit admite la replicación de Puntos de control de producción Hyper-V pero no puntos de control estándar. No utilice puntos de control estándar; de lo contrario, la recuperación en el nodo secundario puede fallar con datos inconsistentes.

1. Requisitos previos

Para la replicación SafeKit, todos los archivos de la máquina virtual VM1 (archivo de configuración, disco duro virtual, etc.) deben almacenarse en la misma carpeta, aunque este no sea el comportamiento predeterminado de Hyper‑V (por ejemplo, D:/Repli-Hyper-V/VM1, donde VM1 es el nombre de la máquina virtual).

Si todos los archivos de VM1 no están en la misma carpeta, use el administrador Hyper-V:

• Exportar VM1 en una carpeta, por ejemplo en D:/Repli-Hyper-V
• Esta exportación creará una carpeta D:/Repli-Hyper-V/VM1 que contiene todos los archivos VM1.
• Eliminar VM1 del inventario del administrador Hyper-V
• Importe VM1, previamente exportado, al administrador Hyper-V

⚠️ Tome una instantánea de su VM antes de iniciar el procedimiento.

⚠️ VM1 solo debe crearse en un único nodo. Lo único que se puede crear en el otro nodo es el directorio VM1 (D:/Repli-Hyper-V/VM1).

⚠️ Asegúrese de que los nombres del conmutador virtual al que hace referencia la máquina virtual existan en ambos servidores Hyper-V y correspondan a la misma red física.

⚠️ La conmutación por error del módulo Hyper‑V (hyperv.safe) puede fallar si no se cumplen los requisitos previos de migración de VM. Para detectar problemas de compatibilidad entre nodos Hyper‑V (hardware, red, configuración), consulte🛠️ KB SK-0088 en este documento.

2. Inicie la consola SafeKit

• Inicie la consola web en un navegador en un nodo del clúster conectándose a http://localhost:9010.
• Entrar admin como nombre de usuario y la contraseña definida durante la instalación.

También puede ejecutar la consola en un navegador en una estación de trabajo externa al clúster.

⚠️ La configuración de SafeKit se realiza en ambos nodos desde un único navegador.

ℹ️ Para proteger la consola web, consulte 🛠️ 11\. Asegurar el servicio web SafeKit en la Guía del usuario.

3. Configurar direcciones de nodo

• Ingrese las direcciones del nodo IP, presione la tecla Tab key para verificar la conectividad y completar los nombres de los nodos. Si el nodo1 o el nodo2 tienen un color rojo, verifique la conectividad del navegador con ambos nodos y verifique el firewall en ambos nodos para 🛠️ solución de problemas.
• Luego, haga clic en Save and apply para guardar la configuración.
• Compruebe el Success ✅mensaje en ambos nodos.
• Si la configuración Failure ❌ ocurre en un nodo, abra el acordeón ▼ para ese nodo y revise los mensajes. Tenga en cuenta que puede utilizar el SafeKit AI 🤖 para obtener ayuda.

ℹ️ Si quieres, puedes agregar un nuevo LAN and nodes (primero ➕) para crear un segundo latido y una red de replicación dedicada.

ℹ️ Si haces clic en Advanced configuration, el cluster.xml Se muestra el archivo. La consola completa automáticamente este archivo y lo implementa en los nodos.

4. Seleccione un módulo

• en New module, haga clic en el hyperv.safe módulo.

ℹ️ En el banner azul en la parte superior, 🛜 node1 representa el nodo de conexión de la consola. Este nodo transmite solicitudes a node2 cuando sea necesario.

ℹ️ La consola busca xxx.safe en el Application_Modules/generic/ directorio en el nodo de conexión (node1) si colocó un módulo allí durante la instalación.

5. Configurar el módulo

• Elige un Automatic inicio del módulo en el arranque sin demora.
• Normalmente tienes un solo Heartbeat Red en la que se realiza la replicación. Pero puede definir una red privada si es necesario (agregando un LAN en el paso 3).
• poner en VM_PATH, la ruta raíz del directorio replicado (D:/Repli-Hyper-V).
• Entrar en VM_NAME, el nombre de la máquina virtual (VM1).

Suponemos que todos los archivos VM1 están en D:/Repli-Hyper-V/VM1 (ver requisitos previos). Este directorio será replicado en tiempo real por SafeKit. No realice una replicación parcial, ya que la conmutación por error no funcionará.

El NORMAL_STOP y FORCE_STOP los valores pueden ser “stop”, “save” o “off”:

• “stop” apaga la VM cuando se detiene el módulo.
• “save“guarda el estado actual de la VM (suspender) cuando se detiene el módulo.
• “off” apaga la VM (apagado) cuando el módulo está detenido.

“stop” se recomienda porque provoca el apagado y luego el reinicio de la VM cuando el módulo se detiene y se reinicia. Por lo tanto, si la aplicación dentro de la VM falla, se reinicia.

Este será el caso, por ejemplo, al cambiar entre roles primarios y secundarios.

ℹ️ No es necesario configurar una dirección virtual IP. VM1 se reiniciará en el Hyper-V secundario con su dirección física IP y esta dirección IP se redirigirá.

ℹ️ Cuando aplicas la configuración SafeKit, el Automatic Start Action de la máquina virtual está configurado en Nothing en Hyper-V. Esto garantiza que la máquina virtual no se inicie automáticamente cuando se inicie el host Hyper‑V, sino que se inicie solo cuando se inicie el módulo en sí.

6. Comprobador personalizado para detectar mal funcionamiento de VM

El verificador personalizado envía mensajes de latido desde el host a la VM a intervalos regulares. Luego, el trabajo del servicio Heartbeat Hyper-V instalado en la VM es enviar una respuesta a cada uno de estos mensajes de latido.

Si el servicio Hyper-V Heartbeat no responde al mensaje (la máquina virtual se bloqueó, falló o dejó de funcionar), entonces el verificador personalizado ejecuta una acción para reiniciar la máquina virtual en el mismo nodo Hyper-V o en el otro.

• Haga clic en Checkers / Custom (ver imagen).
• Simplemente establezca un nombre de su elección en Resource name (ejemplo VM1). Resource name identifica la máquina virtual con un nombre de recurso en SafeKit: custom.VM1.
• con restart en Action, la VM se reinicia en el mismo nodo Hyper-V. Después de 3 reinicios fallidos en 24 horas, el módulo SafeKit hyperv se detiene en el nodo principal y se produce una conmutación por error de la máquina virtual en el nodo secundario.
• si estableces stopstart en Action, hay una conmutación por error directa en el otro nodo Hyper-V tan pronto como la VM no responde a los latidos.

ℹ️ Para mantenimiento, si desea detener la máquina virtual, el verificador personalizado la reiniciará automáticamente. Para evitarlo, puedes temporalmente suspender el corrector 🖼️. O puede eliminarlo eliminando la línea de configuración en la consola.

ℹ️ Es lo mismo cuando quieres restaurar un punto de control. Hyper-V detendrá la VM para realizar la operación y el verificador de VM puede reaccionar negativamente reiniciándola automáticamente. Para evitar esto, suspender el corrector 🖼️ antes de proceder con la operación.

ℹ️ De forma predeterminada, el verificador personalizado permite que la máquina virtual se inicie durante 50 segundos antes de considerarla no disponible. Si su máquina virtual Hyper-V requiere más tiempo para iniciarse, puede aumentar este retraso agregando -InitialGrace al verificador personalizado vmcheck.ps1 en userconfig.xml. El valor se expresa en incrementos de 5 segundos. Por ejemplo, -InitialGrace 20 permite un período de gracia de 100 segundos: <custom ident="VM1" exec="vmcheck.ps1" arg="%VM_NAME% -InitialGrace 20" when="prim" action="restart"></custom>.

7. Editar guiones (opcional)

• No edite guiones.

8. Cifrado de comunicación (opcional)

• Mantener el cifrado de la comunicación entre nodos.

9. Guardar y aplicar

• Save and apply la configuración y los scripts en ambos nodos.

10. Verificar la configuración exitosa

• Compruebe el Success ✅ mensaje en ambos nodos y haga clic en Monitor modules.
• Si la configuración Failure ❌ ocurre en un nodo, abra el acordeón ▼ para ese nodo y revise los mensajes. Tenga en cuenta que puede utilizar el SafeKit AI 🤖 para obtener ayuda.

11. Inicie el nodo con datos actualizados.

• Si el nodo 1 tiene el directorio replicado actualizado para VM1/, selecciónelo y ⋯ Force start ▶ As primary.

Cuando se inicie el nodo 2, todos los datos se copiarán del nodo 1 al nodo 2.

⚠️ Si tomas la decisión equivocada, corres el riesgo de sincronizar datos obsoletos en ambos nodos.

⚠️ También se supone que VM1 se detiene en el nodo 1 para que SafeKit instale los mecanismos de replicación y luego inicie VM1 en el start_prim guión.

⚠️ Usar Start para inicios posteriores: SafeKit conserva el servidor más actualizado. Comenzando As primary Se trata de una puesta en marcha especial por primera vez o durante operaciones excepcionales.

12. Espere la transición a ALONE (verde)

• El nodo 1 debe alcanzar el estado ALONE (verde), lo que significa que el start_prim El script se ha ejecutado en el nodo 1.

⚠️ Si no se alcanza ALONE (verde) o si no se inicia VM1, analiza por qué con el registro del módulo 🖼️ del nodo 1.

• Haga clic en 🔍 iniciar sesión icono de node1 para abrir el registro del módulo y buscar mensajes de error, como un verificador que detecta un error y detiene el módulo.
• Haga clic en start_prim en el registro: los mensajes de salida del script se muestran a la derecha y se pueden detectar errores como VM1 iniciado incorrectamente.
• Utilice SafeKit AI 🤖 para obtener ayuda con los mensajes de registro.

⚠️ Si el grupo está en WAIT (red) not uptodate, STOP (red) not uptodate estado, detenga el nodo WAIT y forzar su inicio como primario 🖼️.

13. Iniciar el nodo 2

• ⋯ Start nodo 2 con su menú contextual.
• Espere al estado SECOND (verde).

ℹ️ El nodo 2 permanece en el estado SECOND (naranja) mientras resincroniza los directorios replicados (copia del nodo 1 al nodo 2).

• Esto puede tardar un poco dependiendo del tamaño de los archivos que se van a resincronizar en los directorios replicados y del ancho de banda de la red.
• Para ver el progreso de la copia, consulte la registro del módulo 🖼️ y el recursos de replicación 🖼️ del nodo 2. Utilice SafeKit AI 🤖 para obtener ayuda con los mensajes de registro.

ℹ️ Cuando se utilizan discos de diferenciación Hyper-V, solo el disco de diferenciación necesita resincronización después de la sincronización inicial, lo que ahorra tiempo para discos duros virtuales grandes.

14. Verificar que el clúster esté operativo.

• Compruebe que el grupo esté verde/verde con VM1 ejecutándose en el nodo PRIM y no ejecutándose en el nodo SECOND.

En este estado, solo los cambios dentro de los archivos se replican en tiempo real.

15. Pruebas

• Detenga el nodo PRIM desplazándose hacia abajo en su menú contextual y haciendo clic Stop.
• Verifique que haya una conmutación por error en el nodo SECOND, que debería convertirse en ALONE (verde).
• Consulte con el administrador de Hyper-V que VM1 se ejecuta en el nodo 2.

⚠️ Si no se alcanza ALONE (verde) en el nodo2 o si no se inicia VM1, analice por qué con el registro del módulo 🖼️ del nodo 2.

• Haga clic en 🔍 iniciar sesión icono de node2 para abrir el registro del módulo y buscar mensajes de error, como un verificador que detecta un error y detiene el módulo.
• Haga clic en start_prim en el registro: los mensajes de salida del script se muestran a la derecha y se pueden detectar errores como VM1 iniciado incorrectamente.
• Utilice SafeKit AI 🤖 para obtener ayuda con los mensajes de registro.

⚠️ Como el start_prim El script importa la máquina virtual en el nodo 2, la conmutación por error puede fallar debido a🛠️ Configuración de Hyper-V (consulte KB SK-0088 en este documento).

⚠️ Si todo está bien, inicie un inicio en el nodo1, lo que resincronizará los directorios replicados desde el nodo2.

Si algo sale mal, detenga el nodo2 y forzar el inicio como primario 🖼️ del nodo1, que se reiniciará con sus datos localmente sanos en el momento de la parada.

ℹ️ Ten en cuenta que tienes un 🕒 línea de tiempo 🖼️ eso puede ser útil para comprender lo que sucede en el clúster.

16. Si es necesario, configure un verificador de cerebro dividido

• Ver ¿Cuáles son los diferentes escenarios en caso de aislamiento de red en un clúster? para saber si necesita configurar un verificador de cerebro dividido.
• Vaya a la configuración del módulo y haga clic en Checkers / Splitbrain (ver imagen) para editar los parámetros del cerebro dividido.
• Save and apply la nueva configuración para volver a implementarla en ambos nodos (el módulo debe detenerse en ambos nodos para guardarlo y aplicarlo).

Parámetros :

• Resource name identifica al testigo con un nombre de recurso: splitbrain.witness. Puede cambiar este valor para identificar al testigo.
• Witness address es el argumento para un ping cuando un nodo va de PRIM a ALONE o de SECOND a ALONE. Cambie este valor con el IP del testigo (un elemento robusto, normalmente un enrutador).
• Nota: puede configurar varias IP separadas por espacios en blanco. Preste atención a que las direcciones IP deben ser accesibles desde un nodo pero no desde el otro en caso de aislamiento de la red.

17. Reinicio automático si falla un servicio crítico dentro de la VM

Si desea un reinicio automático o una conmutación por error cuando falla un servicio crítico dentro de la VM, puede configurar las propiedades de recuperación del servicio (ver imagen).

Primero debes configurar el Comprobador personalizado de VM descrito previamente.

Y luego en Microsoft Service Manager dentro de la VM, seleccione su servicio crítico y en la propiedad de recuperación del servicio, solo tiene que configurar el apagado de la VM cuando falla el servicio crítico.

Para eso, en las opciones de Recuperación de tu servicio crítico, elige “Ejecutar un programa “en fallas y en las opciones de Ejecutar programa, configure”C:/Windows/System32/shutdown.exe " y en “Parámetros de línea de comando”, establezca /s /c “el servicio falla”.

Por supuesto, puedes implementar una recuperación más sutil con tus propios scripts. Pero tenga en cuenta que apagar la VM habilitará el verificador personalizado en el host. El verificador personalizado detectará que el latido del Hyper-V ya no responde y reiniciará la VM en el mismo servidor Hyper-V o realizará una conmutación por error en el otro servidor Hyper-V (según su configuración).

Para probar la función, utilice el Administrador de tareas y finalice el proceso (Finalizar tarea) asociado al servicio crítico. Una parada limpia del servicio a través de Service Manager o el comando “net stop” no activa la acción de recuperación dentro de Windows Service Manager.

18. Apoyo

• Para obtener soporte, tome 2 SafeKit Snapshots (2 archivos .zip), uno para cada nodo.

ℹ️ Más información sobre el soporte aquí.

Demostración de la solución SafeKit / Hyper-V

Vídeo de SafeKit: Agrupación en clústeres a nivel de máquina virtual con Hyper-V (5:15)

En este vídeo, descubra cómo implementa SafeKit alta disponibilidad para Hyper-V sin la complejidad de una SAN. Aprende a configurar replicación de máquinas virtuales en dos nodos para garantizar una conmutación por error perfecta para sus cargas de trabajo virtualizadas críticas. Aunque esta demostración utiliza Hyper-V en Windows, la solución funciona de manera idéntica con KVM en Linux.

Capítulos

1. 🎬 Descripción general de la arquitectura: 2 nodos Hyper-V y 2 máquinas virtuales (0:49)
2. 🎬 Configuración del cluster y los módulos hyperv.safe (1:59)
3. 🎬 Pruebas en vivo: replicación, migración y conmutación por error automática de VM en caso de falla (2:26)

Implementación paso a paso

• 🛠️ Lea la guía para configurar un clúster Hyper-V reflejado en Windows.
• 🛠️ Lea la guía para configurar un clúster KVM reflejado en Linux.

🔍 Centro de Navegación de Alta Disponibilidad SafeKit

Explore SafeKit: Funciones, vídeos técnicos, documentación y prueba gratuita