Réplica de VMs con Hyper-V – Alta disponibilidad

Esta entrada es una continuación de replicar máquinas virtuales con Hyper-V, que dejé con la réplica sincronizada entre dos servidores físicos. Pero ¿que pasa cuando uno de los servidores físicos se rompe? o ¿lo tenemos que reiniciar y no se quiere perder el acceso al servicio que proporciona alguna máquina virtual? y, si simplemente, ¿se quiere comprobar que se puede levantar la copia sin problemas? ¿se podría utilizar la máquina virtual de réplica como un entorno de test? ¿Cómo se reactiva la sincronización? Todas ellas son una batería de preguntas muy interesantes que intentaré responder en esta entrada. Vayamos por partes.

Recordemos el entorno que tenemos montado, dos servidores físicos y un máquina virtual (srvDC):

  • HyperV-01 es el servidor físico que tiene la copia principal de la máquina virtual.
  • HyperV-02 es el servidor físico que recibe la copia de la máquina virtual.

replica-vm-hyperv-01es

Está configurada la réplica de la máquina virtual en los dos servidores físicos de virtualización. La réplica está operativa y sincronizada según informa la consola de administración de Hyper-V. Para trabajar cómodamente recomiendo abrir una única consola de administración de Hyper-V con los dos servidores conectados.

replica-vm-hyperv-ha-01

 

Entorno de test de réplica de máquinas virtuales

Pero, mientras la réplica está configurada y activa no se puede levantar ni abrir esta máquina virtual, ¿como sé que realmente la máquina virtual de la réplica funciona correctamente? Haciendo una copia de la máquina virtual de réplica y levantándola en un entorno aislado para comprobar su funcionamiento. Para hacerlo, sigamos los siguiente pasos:

Desde el servidor que tiene la réplica (HyperV-02), abrir la consola de administración de Hyper-V, botón derecho del ratón sobre la máquina virtual de réplica, seleccionar Replicación > Probar conmutación por error.

replica-vm-hyperv-ha-02

Nos piden por el punto de recuperación a partir del cual se creará una segunda máquina virtual. Por defecto queda seleccionado el último, escoger según las necesidades del momento. Hacer clic en el botón probar conmutación por error.

replica-vm-hyperv-ha-08

Se acaba de crear una segunda máquina virtual con el mismo nombre, añadiendo la palabra Prueba al final. Antes de continuar, comprobar las propiedades de la nueva máquina virtual. Botón derecho del ratón sobre la máquina virtual, seleccionar Configuración.

replica-vm-hyperv-ha-04

Hacer clic en la configuración de disco duro, se observa que el disco duro conectado se encuentra en la misma carpeta que el disco de réplica, pero que corresponde a otro archivo con un nombre aleatorio. Es una continuación del punto de recuperación que se ha seleccionado del disco original, no ocupa el mismo espacio. Esta configuración es correcta.

replica-vm-hyperv-ha-05

La conexión de red de esta máquina virtual de pruebas es muy importante, ya que no puede estar conectada a la misma red que la máquina virtual activa. Recordar que las máquinas virtuales que tenemos son completamente idénticas, conectarlas a la misma red y en el mismo dominio implica una duplicidad de equipos, por lo que tendremos muchos problemas de acceso a los servicios, afectando a la producción. Por lo tanto, antes de poner en marcha la máquina virtual, en el apartado de configuración del adaptador de red > conmutador virtual, asegurar que está seleccionada la opción no conectado, o bien seleccionar un conmutador de una red de test, aislada del resto.

replica-vm-hyperv-ha-10

Es el momento de probar la máquina virtual, se puede poner en marcha para comprobar su funcionamiento y que los datos de que dispone son los esperados.

Perdonad que no haya una captura de pantalla con la máquina virtual encendida. Mi entorno de laboratorio no me permite levantar una segunda máquina virtual dentro de otra. En su lugar, para asegurar que funciona la réplica y que los datos son los esperados, he optado por montar el disco duro de réplica de prueba en el propio servidor físico que recibe la réplica. La máquina virtual utilizada por estas pruebas es diferente, en lugar del srvDC es la srvW2k12R2, con un disco duro original de 15 GB, para disponer de contenido dentro del disco duro y poder ver los espacios que ocupan las copias. El procedimiento uso puede ser útil para recuperar archivos de esta copia.

Desde la pantalla de inicio, botón derecho sobre el botón de Inicio de Windows, seleccionar Administrador de discos.

replica-vm-hyperv-ha-11

En el menú de la consola de administración de discos, seleccionar Acción > Exponer VHD.

replica-vm-hyperv-ha-12

Indicar la ruta del disco duro de test que está en la misma carpeta que el disco duro de réplica, pero con un nombre más largo. Hacer clic en el botón Aceptar.

replica-vm-hyperv-ha-13

replica-vm-hyperv-ha-14

Se presenta el nuevo disco duro virtual en el servidor físico, comprobar que el disco duro queda en línea y la asignación de las unidades de discos. En caso contrario, poner el disco duro en línea y asignar una unidad disponible en la partición correspondiente.

replica-vm-hyperv-ha-15

Con el explorador de Windows se puede revisar el contenido del disco duro, abrir los archivos, copiar el contenido a otro disco duro… Os doy ideas de su potencial.

replica-vm-hyperv-ha-16

replica-vm-hyperv-ha-21

Para desmontar la copia virtual, desde el administrador de discos, botón derecho sobre el disco duro y seleccionar Ocultar VHD.

replica-vm-hyperv-ha-17

Mensaje de confirmación para desmontar el disco duro, hacer clic en el botón Aceptar.

replica-vm-hyperv-ha-18

Para dejarlo todo limpio, hay que eliminar el entorno de test. Desde la consola de administración de Hyper-V, botón derecho sobre la máquina virtual de réplica (no la de prueba), seleccionar Replicación y hacer clic en Parar conmutación por error de prueba.

replica-vm-hyperv-ha-19

Mensaje de confirmación para desmontar la prueba. Hacer clic en Parar conmutación por error de prueba.

replica-vm-hyperv-ha-20

El sistema borra la máquina virtual de prueba y todos los archivos asociados: definición de máquina y discos duros de prueba. Dejando el entorno en su estado original

 

Conmutación por error

Se debe reiniciar el servidor físico que contiene la máquina virtual activa durante unas horas, pero no se puede dejar de dar servicio. ¿Cómo lo hacemos? Cambiando la máquina virtual activa. En vez de serlo la que está en el servidor físico HyperV-01, que lo sea la que hay en el servidor físico HyperV-02. Para hacerlo, desde la consola de administración de Hyper-V del servidor que tiene la máquina virtual activa, botón derecho sobre la máquina virtual activa, seleccionar Replicación > Conmutación por error planeada.

replica-vm-hyperv-ha-22

Aparece un cuadro de diálogo con diferentes opciones que nos permiten:

  • Invertir la dirección de la replicación después de la conmutación por error. Si se marca esta opción, la máquina virtual activa actual pasa a ser la copia y, la máquina virtual de réplica actual pasa a ser la activa. De esta manera, sigue existiendo un cierto grado de alta disponibilidad al seguir teniendo la máquina virtual replicada. Si no se marca esta opción, se rompe la réplica, perdiendo la sincronización de la máquina virtual activa con la réplica. Es la opción que se debe seleccionar en caso de tener que reiniciar el servidor físico que contiene la máquina virtual activa. Una vez reiniciado el servidor físico o haber terminado las operaciones de mantenimiento, se vuelve a poner en marcha la réplica.
  • Iniciar la máquina virtual de réplica después de la conmutación por error. Como su nombre indica, una vez terminada la sincronización inicia la máquina virtual de réplica.

Para la prueba, desmarcar las dos opciones y hacer clic en el botón Conmutación por error para iniciar el cambio.

replica-vm-hyperv-ha-23

replica-vm-hyperv-ha-24

Después de la operación, observar que la máquina virtual que antes era activa, ha pasado a un estado de replicación de conmutación por error.

replica-vm-hyperv-ha-25

En cambio, la máquina virtual que antes era réplica, ha pasado a un estado de conmutación por error completada. Y que hay una advertencia en la réplica debido a que se ha parado. Ahora es la activa.

replica-vm-hyperv-ha-26

Cuando se hayan terminado las operaciones de mantenimiento, se devuelve la máquina virtual activa al servidor físico origen. Desde la consola de administración Hyper-V del servidor físico origen, botón derecho sobre la máquina virtual, seleccionar Replicación> Cancelar conmutación por error planeada.

replica-vm-hyperv-ha-27

Nos pregunta que confirmemos la operación, hacer clic en el botón Si.

replica-vm-hyperv-ha-28

Se hace el cambio, pero queda actualizar la copia ya que la réplica estaba parada. Observar que el estado de la máquina es crítico.

replica-vm-hyperv-ha-29

Botón derecho sobre la máquina virtual, seleccionar Replicación > Reanudar la replicación.

replica-vm-hyperv-ha-30

La máquina virtual vuelve a su estado normal de operación.

replica-vm-hyperv-ha-31

 

Girar el sentido de la réplica

Consiste en girar el sentido de la réplica en cuanto a servidores físicos. Es la opción adecuada para balancear la carga de memoria y procesador de un servidor físico de virtualización.

Ojo, para recibir réplicas de máquinas virtuales, el hipervisor del servidor físico debe estar correctamente configurado. Revisar el artículo anterior de replicar máquinas virtuales con Hyper-V.

Desde el servidor físico que recibe la réplica, botón derecho sobre la máquina virtual de réplica, seleccionar Replicación > Invertir replicación.

replica-vm-hyperv-ha-32

Se inicia un asistente para invertir la réplica. Se puede deshabilitar para que no vuelva a salir. Hacer clic en el botón Siguiente.

replica-vm-hyperv-ha-33

Indicar el nombre del servidor al que enviar la réplica. Selecciona el servidor físico que contiene la máquina virtual activa. Hacer clic en Siguiente.

replica-vm-hyperv-ha-34

Tipo de autenticación de la réplica, tal como se vio en la entrada de replicar máquinas virtuales con Hyper-V, hacer clic en el botón Siguiente.

replica-vm-hyperv-ha-35

Frecuencia en la que se hará la réplica, seleccionar según corresponda. Hacer clic en el botón Siguiente.

replica-vm-hyperv-ha-37

Indicar si se deben crear puntos de recuperación para tener más de una copia en el servidor de réplica o no. En el ejemplo, se crean dos puntos de recuperación al día. Hacer clic en el botón Siguiente.

replica-vm-hyperv-ha-38

Resumen de la operación. Hacer clic en el botón Finalizar.

replica-vm-hyperv-ha-39

Se ha girado la configuración del sentido de la réplica, pero aún no está correcto, hay que hacer la sincronización inicial. Desde el servidor que ahora tiene la máquina virtual activa, botón derecho sobre la máquina virtual, seleccionar Replicación > Iniciar replicación inicial.

replica-vm-hyperv-ha-40

Indicar cuando y como se hará esta réplica inicial. Cuando todo esté correcto, hacer clic en el botón Aceptar.

replica-vm-hyperv-ha-41

Se inicia la réplica de la máquina virtual.

replica-vm-hyperv-ha-42

Una vez ha terminado, queda la máquina virtual principal en el servidor físico HyperV-02, la máquina virtual de réplica en el servidor físico HyperV-01 y la réplica pasa a ser normal, tanto en la copia activa (principal):

replica-vm-hyperv-ha-44

Como en la copia de réplica.

replica-vm-hyperv-ha-43

 

Romper la réplica

Se puede dar el caso que ya no necesitemos más la réplica de la máquina virtual, es el caso de querer romper la réplica y destruir la copia. Desde la consola de administración de Hyper-V del servidor físico que contiene la máquina virtual activa, botón derecho sobre la máquina virtual, seleccionar Replicación > Quitar replicación.

replica-vm-hyperv-ha-45

Pregunta de advertencia, hacer clic en el botón Quitar replicación.

replica-vm-hyperv-ha-46

Se inicia el proceso de sincronización y se elimina la configuración de la réplica, dejando las dos máquinas virtuales independientes. La principal sin la réplica habilitada.

replica-vm-hyperv-ha-47

Y la réplica, aún habilitada, queda como una copia de seguridad.

replica-vm-hyperv-ha-48

Repetir el proceso anterior para destruir la réplica en esta copia: botón derecho, seleccionar Replicación > Quitar replicación.

replica-vm-hyperv-ha-49

Nos han quedado dos máquinas virtuales idénticas en cada servidor físico. La copia la podemos guardar como copia o borrarla. En este último caso, botón derecho sobre la máquina virtual, seleccionar Eliminar.

replica-vm-hyperv-ha-50

En la pregunta, hacer clic en el botón Eliminar.

replica-vm-hyperv-ha-51

Se borra la configuración de la máquina virtual, pero no en su disco duro. Para liberar espacio y que no queden archivos huérfanos que luego no se sabe que son, se aconseja terminar de borrar estos archivos.

 

Aquí terminan estas entradas relacionadas con la alta disponibilidad y el hipervisor Microsoft Hyper-V. Es una configuración especialmente indicada para entornos pequeños que no disponen de cabinas de almacenamiento o que se quiera disponer de una copia de seguridad casi instantànea.

 

¿Te ha gustado el artículo? Lo puedes compartir en las redes sociales. También puedes dejar tu opinión, comentario o sugerencia. ¡Gracias!

Similar Posts by The Author:

 

8 comentaris per a
“Réplica de VMs con Hyper-V – Alta disponibilidad”

  1. Hola, buenas, tengo una duda en tus pasos de failover planeado, cuándo vuelves a la VM principal para cancelar la conmutación planeada, previamente en la VM réplica habrá que cancelar la conmutación por error para que desaparezcan los puntos de control, ya que si no lo hago así, no se podrá renaudar replicacion en la principal, ¿estoy en lo cierto? El problema de ésto, es que perdería todo el trabajo realizado en la VM réplica mientras que estaba activa.

     
    1. Hola Manuel, en caso que hayas activado la máquina de réplica (failover), habrás destruido la réplica como tal. Con lo que para volver a la situación inicial (failback) debes volver a generarla a partir de la réplica que tienes en funcionamiento actualmente, la otra máquina original se supene que ha desaparecido, está completamente muerta. Como bien dices, si lo que haces es volver a levantar la máquina original porqué ha resucitado (después de ejecutar el failover), vas a perder todas la modificaciones.

      Saludos,

       
  2. Hola, Josep. Muy claro el tutorial, gracias por exponerlo.

    Tengo una duda relativa al uso de la réplica para dar solución a las últimas tediosas y gigantescas actualizaciones de Windows Server 2016 que te dejan paralizado el servidor durante bastante tiempo hasta que se actualizan todas las máquinas virtuales y el host. Para el host está claro, se puede conmutar por error al servidor de réplicas mientras se actualiza el host ya que en éste no hay datos, pero ¿cómo lo harías para actualizar máquinas hyper-v en producción y con datos de usuario? Si levantamos la de la réplica, en origen tendríamos el sistema operativo actualizado pero no así los datos, el usuario seguiría trabajando pero al restaurar la máquina principal habría que restaurar datos también, por lo que al final tampoco vale la pena y hay que hacerlo en horas intempestivas (sobre todo en clientes como hoteles que están siempre trabajando) y con miedo por si no arranca y te toca acercarte físicamente al equipo. ¿Usas algún método diferente para actualizar el sistema? Gracias por todos tus tutoriales que son muy amenos y útiles.

     
    1. Hola Alejandro, cuando conmutas las máquinas, no es que haya dos máquina funcionando a la vez, sinó solo una. Si la réplica no contiene los datos de usuario actualizados estos trabajaran con datos antiguos. Asegúrate que las réplicas de máquinas virtuales contienen todos los discos que disponga la máquina virtual y que nunca tengas las dos máquinas levantadas (no puedes tener nunca dos máquinas con el mismo nombre y la misma IP activas en la red).

      En el tema de actualizaciones, si los servicios que ofrecen las máquinas virtuales son críticos, te recomiendo que los configures a modo de clúster o balanceo de carga, según corresponda, que es la forma que tienes para asegurarla continuidad del servicio con un paro mínimo (segundos o pocos minutos dependiendo del servicio).

      La réplica de VMs se contempla para los entornos de recuperación de desastre, es decir, para levantar los servicios y recuperar los datos cuando se ha destruido el sitio activo. No como sistema de alta disponibilidad, ya que los procedimientos de failover y failback a nivel de máquina virtual pueden tener implicaciones a nivel de servicio (que se haya quedado alguna transacción en curso, por ejemplo).

      Saludos,

       
  3. Hola, gracias por la respuesta. El modo clúster no me acaba de convencer porque aunque tenga dos servidores redundantes los datos no son así sino que los he de tener en un medio de almacenamiento externo compartido (SAN), lo cual complica y encarece bastante el proyecto, hablamos de redes no excesivamente grandes de 50…100 usuarios. Me ofrece más tolerancia a fallos en cuanto a SO pero si me falla el SAN…no ya un disco que pueda estar en RAID sino la propia cabina.

    Por otra parte, ¿Qué utilidad tienen los puntos de control? ¿Se generan automáticamente?

    Un saludo.

     
    1. El entorno SAN se entiende como entorno de alta disponbilidad, no solo de discos, sinó tambien debes contemplar las controladoras y fuentes de alimentación. Por el tamaño de empresa ya puedes adquirir este tipo de soluciones que, al final, es donde ubicas todo el capital de la empresa. No es muy bueno ahorrar en donde tienes la información más valiosa, lo barato sale caro.

      El punto de control es cuando se pone la máquina en modo consistencia de datos, que limpia la memoria bruta y asegurar que los datos en el lado de la copia son consistentes. Imagina una base de datos donde se estan generando facturas, que a su vez tienen lineas. Si no eres capaz de dar consistencia a los datos, te puede suceder que en el otro lado solo tuvieses las cabeceras de las facturas pero no las lineas, con lo cual habrias perdido información. Poner en modo consistente significa permitir pasar la factura con sus líneas al otro lado, por decirlo de alguna manera y teniendo en cuenta que se ha programado todo correctamente.

      Saludos,

       
  4. Hola, muy buen post!
    me surge una duda, tenemos el servidor 1 y el servidor 2, el uno siento el host principal y el dos el replica, hay forma de hacer que ante un daño en el servidor 1 la replica que esta alojada en el servidor dos encienda de forma automática? he leído de scripts en powerchell pero realmente no se que tan factible sea

     
    1. La réplica se contempla como Disaster Recovery (DR), por consiguiente hay una operación manual para levantar el DR. Si no imagina que estas reiniciando la máquina virtual después de una actualización, el script que indicas detecte que el equipo está no operativo y decida levantar la réplica de la máquina mientras la otra está acabando de aplicar las actualizaciones. Al final tendrás dos máquinas completamente inestables.

      Para sistemas automáticos de alta disponibilidad automáticos debes acudir al clúster.

       

Deixar un comentari

Recorda que no es contestaran preguntes personals, només d´interés comú que ens enriqueixin a tots.
La teva adreça de correu electrònic no serà publicada. Els camps obligatoris estan indicats.

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.