CatalàReplicar máquinas virtuales es una característica muy interesante en el entorno Hyper-V que permiten disponer de una copia casi instantánea en otro servidor físico o bien en Azure. Replicar la máquina virtual fuera del hardware donde se ejecuta habitualmente proporciona una copia de seguridad local, además de dar cierto grado de alta disponibilidad. Es un primer paso para dotar de resiliencia a nuestro sistema, sobretodo en entornos pequeños donde los presupuestos se estrechan y es más difícil disponer de cabinas de almacenamiento compartido.
Antes de continuar, me gustaría aclarar un poquito el concepto de copia de seguridad de máquina virtual, ya que es importante tenerlo claro. Hay que diferenciar la instantánea de la máquina virtual, que se podría considerar una copia de seguridad local rápida y nos permite volver atrás en caso de error. Es muy útil a la hora de hacer actualizaciones o modificar configuraciones del sistema, pero los datos no cambian de almacenamiento, es decir, si se produce un error físico en el disco duro se pierde el original y la copia de seguridad.
En cambio, la réplica consiste en la copia del contenido original a otra ubicación. Dependiendo del lugar físico donde se encuentre, la réplica se puede considerar una copia de seguridad o una medida de recuperación ante desastres. Si la réplica de la máquina virtual a otro servidor está dentro del mismo centro de datos, me estoy protegiendo ante un error físico del servidor (se dañan los discos duros), ya que tengo una copia exacta en otro disco duro. Pero si se quema o se inunda el centro de datos lo pierdo todo.
Es importante disponer de una copia de seguridad externa más o menos actualizada en todo momento.
Para desplegar esta tecnología, necesitamos por lo menos dos servidores físicos con almacenamiento suficiente para alojar la máquina virtual. Recordar que una réplica es una copia exacta, por lo tanto, si la máquina original ocupa 500 GB, la réplica también ocupará 500 GB. Naturalmente, los dos servidores deben tener instalado el rol de Microsoft Hyper-V en la versión 2012 o superior.
Para llevar a cabo este laboratorio utilizo dos servidores Hyper-V Windows 2012 R2. Uno de ellos contiene la máquina virtual srvDC. Los dos están conectados a la red local y una red interna para la réplica. El esquema de trabajo es el que se muestra a continuación:
El servidor HyperV-01 actúa como servidor activo, dispone de una máquina virtual encendida y en producción, el srvDC. El servidor HyperV-02 como servidor pasivo, recibe la copia de la máquina virtual.
La copia de la máquina virtual no es accesible a no ser que se rompa la réplica.
El hecho de disponer de una réplica de la máquina virtual en el segundo servidor sólo implica el consumo de espacio de almacenamiento, ya que la máquina virtual permanece apagada.
Requerimientos previos para replicar con Hyper-V
Si las dos máquinas pertenecen al mismo dominio, no tendremos ningún problema para controlarlas desde la misma consola. Pero si los hipervisores se encuentran en un grupo de trabajo se debe habilitar la consola remota y hacer alguna cosita más con certificados. Podéis revisar el artículo de chuletillas de Powershell, concretamente el apartado Habilitar conexión remota para PowerShell.
En un entorno de trabajo en grupo, hay que configurar las credenciales de autenticación y certificados digitales. Para establecer las credenciales, desde la consola de sistema con privilegios de administrador, ejecutar el comando siguiente, sustituyendo el nombre del servidor y el usuario por el que corresponda en cada caso:
cmdkey /add:hyperv-02 /user:hyperv-02\administrador /pass:
A la pregunta de la contraseña, indicar la que corresponda para poder validarse correctamente en el servidor contrario.
Sobre el tema certificados, que ya sé que os gustan mucho, hay que disponer de una entidad certificadora de confianza y haber generado y instalado un certificado de servidor en los dos servidores. Esta entidad y certificados, de forma menos segura, pueden llegar a ser firmados por el propio servidor. Como que el tema de los certificados no es el objeto de esta entrada se obvia su creación y asignación.
Preparando los Hyper-V para replicar
Para facilitar la configuración, añadimos el segundo servidor (HYPERV-02) a la consola de administración de Hyper-V del primero (HYPERV-01). En el panel del lado izquierdo, botón derecho sobre administrador de Hyper-V y hacer clic en conectar servidor.
Indicar el nombre del segundo servidor de Hyper-V (HYPERV-02) y hacer clic en el botón Aceptar.
En la consola de administración de Hyper-V aparecen los dos servidores de Hyper-V. Seleccionar el servidor destino de réplica (HYPERV-02), botón derecho, hacer clic en configuración de Hyper-V.
En el listado de opciones del lado izquierdo, seleccionar Configuración de replicación para modificar la configuración del servidor para recibir réplicas de máquinas virtuales. Marcar el checkbox Habilitar este equipo como servidor de réplicas.
Trabajando en un entorno de dominio realizamos la configuración de la réplica sin protegerla, es decir, por el protocolo HTTP (puerto TCP 80). En un entorno de grupo de trabajo la única manera de hacerlo es mediante la conexión cifrada mediante el uso de certificados (HTTPS). Marcar el checkbox Utilizar Kerberos (HTTP), dejando el puerto 80 por defecto.
Finalmente, hay que especificar el servidor o servidores autorizados para enviar réplicas de máquinas virtuales. Hacer clic en el botón Agregar. Indicar el nombre FQDN (el nombre DNS entero, por ejemplo hyperv-02.jmsolanes.cat) del servidor donde hay la máquina virtual original, indicar la ruta donde guardar el disco duro virtual de réplica y, finalmente, especificar el nombre de grupo descriptivo de servidores Hyper-V para réplica. Hacer clic en el botón Aceptar cuando todo esté correcto.
Hacer clic en el botón Aceptar o Aplicar para acabar de completar las modificaciones de configuración en el Hyper-V.
Se advierte que la réplica requiere tener habilitado el acceso por el puerto TCP 80 (en este caso, si se utilizan certificados será el puerto TCP 443) para permitir la recepción de la réplica.
Configuración del cortafuegos local para la réplica de máquinas virtuales
Para comprobar o habilitar este puerto, en el servidor que debe recibir la réplica, botón derecho sobre el botón INICIO, hacer clic sobre Panel de control.
Para ir rápidos, en el buscador se puede escribir la palabra «Herra» (según el idioma que tengáis instalado el sistema operativo) para buscar las herramientas administrativas, que son las que necesitamos. Hacer clic sobre el resultado de Herramientas administrativas.
Hacer clic sobre Firewall de Windows con seguridad avanzada.
Hacer clic sobre Reglas de entrada, botón derecho, seleccionar Nueva regla.
Se inicia el asistente para crear una nueva regla de entrada, seleccionar Personalizada y hacer clic en Siguiente.
En la parte de aplicaciones y servicios. Dejar seleccionado todas las aplicaciones. Hacer clic en Siguiente.
En tipo de protocolo, seleccionar TCP. Puerto local, seleccionar puertos específicos y añadir el número 80. Puerto remoto, dejar en todos los puertos. Hacer clic en Siguiente.
Como que no dejaremos acceso desde cualquier lugar, sería un problema de seguridad, en direcciones IP remotas, seleccionar Estas direcciones IP. Hacer clic en el botón Agregar, donde especificaremos la dirección IP del servidor origen. Hacer clic en Aceptar y Siguiente.
Seleccionar permitir la conexión. Hacer clic en el botón Siguiente.
Marcar los tres perfiles: dominio, privado y público, o los que correspondan según el nivel de seguridad a implementar. Hacer clic en el botón Siguiente.
Indicar un nombre descriptivo para la regla que se está a punto de crear, por ejemplo: Réplica de máquinas virtuales. Hacer clic en el botón Finalizar.
Para comprobar que se pueden replicar máquinas virtuales en el servidor, ejecutando el comando de PowerShell desde el servidor origen, podemos obtener alguna pista si todo funciona correctamente o si hay algún problema:
Test-VMReplicationConnection Hyperv-02 80 Kerberos
Réplica de una máquina virtual
Con todo el entorno preparado para replicar, sólo queda configurar la máquina virtual en cuestión para que se copie al otro servidor. Desde la consola de administración de Hyper-V, botón derecho sobre la máquina virtual y hacer clic en Habilitar replicación. Recordar que también se puede acceder seleccionando la máquina virtual y en el panel de acciones de la derecha, hacer clic sobre Habilitar replicación.
Se inicia el asistente para la réplica de máquinas virtuales, como siempre se puede marcar el checkbox para que no vuelva a enseñar la introducción. Hacer clic en el botón Siguiente.
Seleccionar el servidor donde replicar la máquina virtual. Hacer clic en el botón Siguiente.
Indicar el tipo de autenticación. Como que sólo se ha habilitado el protocolo HTTP queda esta opción seleccionada. Es interesante dejar marcado el checkbox de compresión de tráfico por la red. Hacer clic en el botón Siguiente.
Seleccionar los discos duros virtuales de la máquina que se deben replicar. En este caso sólo hay uno, pero pensad en servidores de archivos o datos donde lo más interesante es replicar los discos que contienen los datos y no los temporales o de sistema operativo. Hacer clic en el botón Siguiente.
¿Cada cuando se hará la réplica? Cada 30 segundos, 5 minutos o 15 minutos. Seleccionar según convenga. Hacer clic en el botón Siguiente.
La réplica también permite guardar puntos de recuperación (instantáneas) en el tiempo, por si se han corrompido los datos en origen. De momento dejamos esta opción en Mantener sólo el punto de recuperación más reciente. El hecho de habilitarlo supone un sobrecoste de almacenamiento y procesamiento de las réplicas. Hacer clic en Siguiente.
Réplica inicial, muy importante en entornos remotos. Como se hace esta primera copia a la que se ha de transferir TODOS los datos. Por suerte, tenemos varias opciones porque no sea un dolor de cabeza:
- Réplica por red. La forma habitual. Hay una conectividad adecuada entre el servidor origen i el destino.
- Medios externos. Para las ubicaciones remotas donde el ancho de banda no es precisamente una autopista de información, nos permite generar la réplica inicial en un archivo, que podemos transportar con un disco duro al lugar de réplica. En este caso, hay que indicar la ubicación y el nombre del archivo a guardar.
- Máquina virtual existente. Cuando ya teníamos una copia de la máquina virtual origen en el servidor de réplicas. En este caso, se actualiza esta con las últimas modificaciones.
Indicar cuando se quiere empezar esta réplica inicial, si lo hacemos ahora o lo dejamos para la noche, por ejemplo. Hacer clic en el botón Siguiente.
Resumen de las operaciones a realizar, si todo está correcto hacer clic en el botón Finalizar.
Se establece la configuración y, si corresponde, se inicia la réplica inicial entre los servidores.
Es importante la pestaña Replicación de la máquina virtual. En ella se observa la fecha de la última réplica, si la réplica está correcta y a que servidor se replica.
En el servidor de réplicas encontramos la misma máquina virtual apagada. La máquina virtual replicada no se puede iniciar a no ser que se cambien las propiedades de la réplica, mediante el botón derecho del ratón y seleccionando la opción Replicación, para romperla o probarla creando una segunda máquina virtual.
Buf, es un tema interesante y largo, por ahora lo dejamos aquí que ya hemos hecho mucho trabajo.
¿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:
- Microsoft SQL Server con SMB3
- Microsoft SQL Server amb SMB3
- Containers en Linux
- Containers amb Linux
- Migrar el servidor de archivos a Windows Server 2019
- Migrar el servidor de fitxers a Windows Server 2019
- Puerta enlace a Azure en el Windows Admin Center
- Porta enllaç a Azure en el Windows Admin Center
- Hola mundo! WordPress 5 y Gutenberg
- Hola món! WordPress 5 i Gutenberg
Mil gracias el documento es muy claro y concreto me ayudo mucho, me gustaría saber si en este escenario activo pasivo se pueden hacer pruebas de operatividad a algunos sistemas de información que estén alojados en el servidor pasivo sin afectar la replicación de otras instancias
Hola Consuelo,
Disculpe la tardanza. No acabo de comprender muy bien la pregunta y me gustaría dejarla clara.
Si se trata de levantar un entorno de test, donde se hacen modificaciones diferentes al entorno original. Entonces se rompe la réplica y se crea como un clon del mismo, desvinculando de la máquina original. Por tanto, no se podría continuar la réplica, sino se debería crear una de nueva.
Si la respuesta es hacer una prueba de DR, esto si está contemplado y permitiría reiniciar la réplica sin tener que empezar desde cero. Solo probar que el servidor se puede levantar en el otro sitio dando servicio. En este caso, el servidor original queda parado. No nos sirve para entornos de test.
En caso de querer disponer de un entorno de test, tendríamos que utilizar una copia del servidor (que en entornos con deduplicación ayudan mucho) y levantar lo como una nueva máquina en una RED AISLADA para hacer las pruebas necesarias. De echo este caso lo utilizo muy a menudo, es la mejor prueba antes de hacer cosas en producción que no tienen vuelta atrás y que en cada caso puede haber mil opciones diferentes.
Saludos.
Hola Josep, muy bueno el lab, pero tengo una duda con respecto a pertenecer a un dominio para establecer la comunicación. Eso se refiere a que los equipos físicos deben de pertenecer un dominio???
Saludos,
Hola, en el caso de la réplica de máquinas virtuales entre nodos Hyper-V se puede hacer con los equipos en un dominio o bien mediante la configuración de certificados. En este artículo solo hablo de una configuración con los nodos que pertenecen a un Active Directory.
Saludos,
Hola, con respecto a estar en un dominio debe ser al dominio de producción o se puede promover un dominio solo entre la red de servidores Host?
Tambien entiendo que si la replica se rompe el servidor replicado levanta, que pasa una vez que el servidor 1 se recupere?
Saludos,
Hola Henry, disculpa el retraso, voy un poco saturado.
Para poder replicar las máquinas se puede hacer con una cuenta de dominio. Esto quiere decir que la autenticación debe ser per un tercero que conozca los dos. Da igual que el dominio sea de un Active Directory o de otro, sólo importa que los nodos esten en el mismo dominio.
Sobre lo que comentas de dominio de producción o hosts, ¿por qué esta diferencia? para mi los nodos son de producción y deben estar en la red protegidos del exterior, ¿porqué harías otro dominio solo para los nodos?
Hola, muy buen tutorial.
Pero yo también tengo la misma duda que Henry. Entiendo que se deberían crear dos dominios, uno que englobe a los dos hosts del cluster y estuviera únicamente limitado a la comunicación entre los dos hosts para hacer la réplica. Yo haría un segundo domino de producción en una máquina virtual para dar servicio a los clientes de red, ya que no me gusta en principio hacer que el host pertenezca al dominio de una máquina virtual. ¿O bien es eso lo que sugieres?
¿Y qué pasaría si se cae una máquina virtual en HOST1 y entra en funcionamiento la del HOST2 al volver a estar operativa la del HOST1? ¿Se volvería a quedar en marcha la del HOST1?
Otra cuestión: Si una VM es puesta en modo «unhealthy» al abandonar inesperadamente el cluster tres veces en una hora… ¿Cómo se la hace regresar a un estado funcional? ¿El abandono inesperado de un cluster incluye que se apague o reinicie dicha VM?
Gracias y un saludo.
Hola Alejandro,
lo de tener un Active Directory para los hosts, no tiene mucho sentido, estas complicando mucho la infraestructura (dos servidores más para el AD de dos hosts?) para llegar a la misma conclusión. Me consta que Microsoft está trabajando en ello de poder crear un clúster sin que los hosts pertenezcan al Active Directory. Mientras, siempre sugiero tener los DCs fuera del clúster de virtualización. La alta disponibilidad ya la estás ofreciendo a nivel de servicio (Active Directory). Retardas un poco el inicio del servicio de clúster de los nodos para que les dé tiempo a iniciar los DCs y eliminas el problema de tener el DC virtualizado.
El tema de las réplicas no es para un escenario parecido al clúster donde todo es automático. Las réplicas se utilizan para los Disaster Recovery (DR) y, por lo tanto, siempre sugiero que este entorno esté controlado manualmente. Una persona debe decidir si pone en marcha el DR o no. Si necesitas el entorno completamente automático lo suyo es el clúster, no la réplica.
Sobre el unhealthy, puedes modificar, aumentando, los parámetros de configuración de redundancia del clúster para poder levantar la máquina si todo es correcto. Este error es muy típico sobretodo en montajes donde el sistema puede que aun no esté estable. Revisad bien estos parámetros de configuración para el entorno en producción.
Saludos,
Hola Josep, una pregunta, referente al Grupo de confianza, donde se configura esa opción? Es un grupo de AD?
Muchas gracias
Correcto.
Hola, Josep.
Finalmente he montado un dominio en los dos servidores, el principal y el réplica, más que nada porque me fío más de tener la confianza establecida mediante el dominio y no me apetece liarme con los certificados de seguridad, las máquinas físicas no acceden para nada a las virtuales y viceversa y parece que todo va correctamente.
Queda claro lo de las réplicas y el clúster.
Muchas gracias.
Hola Josep, el tutorial es estupendo. Tengo una duda con respecto a la réplica. Una vez configurada la réplica de un servidor con sus discos. Sí agrego un nuevo disco al servidor virtual, tengo que volver a configurar la réplica o hay alguna forma de agregar el disco a la réplica actual.
Muchas gracias
Buena pregunta, de probar, no lo he probado, pero la teoría dice que la réplica la haces con la máquina virtual, no con los discos, con lo cual si tendría que reflejarse dicho disco en la réplica.
Es una muy buena prueba a hacer. Saludos,
Hay que añadir el disco a la réplica, ya sea disco físico o virtual. De hecho, al crear la réplica pregunta por los discos a replicar.
Hola, una pregunta: Yo estoy replicando la VM, todo funciona normal y perfecto, UN SERVIDOR DE ARCHIVOS, ingresa un hacker a la maquina ppal y me encripta la información, a la replica se va todo lo encriptado también?
Gracias.
Correcto! La replicación NO te protege de la corrupción de datos, solo de la disponibilidad del servicio. Si borras o modificas un fichero en origen lo modificas en destino cuando se realiza la réplica. Por eso existe la réplica asíncrona, para dar un periodo de tiempo a reaccionar en caso de emergencia y, SOBRETODO, las copias de seguridad FUERA de línea. Por cierto, un SNAPSHOT no se considera una copia de seguridad.
Saludos,
La replicacion me funciona perfectamente solo con VM que tienen HDD virtuales. Pero no con la que tiene un HDD fisico. Como puedo hacer que realice la replica?
No puedes en los discos físicos, solo está pensado para el entorno virtual.
Sobre esto lo que te puedo decir es que transformes esos discos físicos a virtuales, si no tienes algo muy muy concreto de acceso por LUN-aware (acceso físico a las LUNs) no se justifica su uso. No solo para la réplica, sinó tambiénm te limita los snapshots y copias de seguridad.
Los discos virtuales actuales son muy fiables y disponen de mecanismos de autocorrección.
Saludos JMSolanes, una consulta si mi replica de servidores lo quiero realizar en sitios diferentes, cual debería ser la configuración o algun puerto en especifico que se tenga que abrir en el modem de ISP para hacer esta replica.
Para sitios remotos, también se puede hacer directamente con certificados por el puerto HTTPS, del que deberás hacerlo con las IPs públicas. No te recomendaría hacerlo directamente por HTTPS sobre Internet, lo suyo es crear una VPN site-to-site entre las dos redes donde se encuentran los equipos, ofreciendo visibilidad de red. Una vez los equipos tienen visibilidad aplica el método descrito en el artículo o aplica por HTTPS.
Hola, soy nuevo en el tema, muchas gracias por el conocimiento q compartes. Existe un ejemplo q hayas realizado haciendo uso de los certificados…
6 enero 2017 a las 7:31
Hola, en el caso de la réplica de máquinas virtuales entre nodos Hyper-V se puede hacer con los equipos en un dominio o bien mediante la configuración de certificados.
Me lo apunto.
Gracias, podrías en tu blog enseñarnos como hacer esta con site to site con los dos servers Windows al igual que con los certificados, gracias
Me lo apunto al igual que los certificados
Hola,
¿existe la posibilidad de replicación cruzada entre dos servidores, de modo que se repartan entre ellos las máquinas virtuales activas y también las correspondientes réplicas?
Gracias.
Correcto, no es necesario que todas las máquinas del mismo equipo sean activas y las del otro pasivas. No obstante, esta modificación la debes hacer tu manualmente. No hay un sistema «por defecto» que automatize este proceso. Tienes que decidir tu donde tienes las máquinas activas y donde las pasivas.
Saludos.
Hola Josep, quiero hacerte dos preguntas:
1) El proceso en producción es seguro? cuánto tarda en promedio?
2) Ésta réplica si la máquina principal que se va a replicar tiene un disco duro con 2 tb de información en la réplica lo va a tomar en cuenta? (es decir te a a exigir que como mínimo debes tener un dd de 2tb?)
Si, es seguro y operativo. Naturalmente, debes disponer del mismo espacio en ambos lados.
Hola,
con la licencia de Windows Server 2019 Standard solo se puede replicar un volumen y de un tamaño máximo de 2 TB.
¿Entre Servidores Hyper-V (el gratuito) también existe alguna limitación?
A qué te refieres en replicar un volumen, a datos o máquinas virtuales?
En caso de los datos tienes esta limitación ya que Storage Replica solo viene incluido con las versiones de pago: Comparativa de características Windows Server 2019.
Sobre réplicas de máquinas virtuales en principio si puedes habilitarlas ya que forman parte del rol de Hyper-V, si bien es cierto que no lo he probado. Puedes encontrar más información en https://docs.microsoft.com/en-us/windows-server/virtualization/hyper-v/manage/set-up-hyper-v-replica
Muchas gracias por el conocimiento que compartes.
bona nit Josep, felicidades por el articulo, es justo lo que necesito. Mi duda es referente a lo que dices al principio «Los dos están conectados a la red local y una red interna para la réplica.», ¿donde se configuran esas 2 redes? ¿se encarga el sistema de replica de eso? es decir, ¿donde se le dice que la replica va por una tarjeta de red y la red local por otra?
Por la resolución de los nombres de los equipos. Si tienes dos redes tendrás direccionamiento IP diferente. Esto lo puedes conseguir manualmente (si no tienes DNS) modificando el archivo HOST de los nodos para asegurar que entre ellos se comunican por otras IPs.
Al intentar realizar la replica, me arrojo el siguiente error:
Hyper- v Failed to enable replication.
Hyper- v failed to authenticate using Kerberos authenticate.