Una de las nuevas características de Hyper-V en Windows Server 2012 R2 es la posibilidad de que dos máquinas virtuales puedan compartir un disco virtual (VHDX) lo que permite la creación de “Failover Cluster” virtual sin necesidad de acceso del cluster virtual a iSCSI o fibra óptica
En primer momento me pareció algo sencillo y rápido de demostrar, pero me llevé una sorpresa, no es tan así, hay muchos detalles a tener en cuenta y procedimientos a ejecutar
Lo que necesitaremos serán cuatro máquinas para crear un Failover Cluster, donde luego crearemos nuestro Cluster Virtual que compartirán un disco VHDX
Para mostrar el objetivo, un dibujo muestra más que mil palabras
Para crear el Failover Cluster usaremos cuatro máquinas con Windows Server 2012 R2:
- Controlador de Dominio: DC1
- Nodo1 del Cluster con Hyper-V: HYPER1 (Inicial con 3 placas de red)
- Nodo2 del Cluster con Hyper-V: HYPER2 (Inicial con 3 placas de red)
- Servidor en grupo de trabajo emulando una SAN: SAN
La configuración básica de cada uno de los equipos está detallada en la siguiente tabla. Las cuatro máquinas sobre fondo celeste son las máquinas reales, mientras que las otras dos (GuestNodo1 y GuestNodo2) serán los nodos del Cluster virtual
Las dos máquinas HYPER1 e HYPER2 deben soportar Hyper-V. Como hemos comentado en otras ocasiones pueden tratarse de máquinas reales, o como en mi caso, todo está virtualizado sobre VMware Workstation ya que permite Hyper-V en una máquina virtual
Recuerdo para el que no tenga VMware Workstation que se pueden bajar versiones de prueba de 30 días
Como infraestructura incial, que supongo que nadie que lea esto tendrá dudas en crear, tenemos creado el Dominio, y agregadas al mismo las máquinas HYPER1 e HYPER2
Como una forma de facilitar la configuración, y no confundirse, incialmente la creo con una única placa de red, uno la máquina al Dominio, y luego agrego «HeartbeatNet» y «SanNet». Recién más adelante, agregaré «HeartbeatCluster Network»
También he modificado la “Default Domain Policy” de forma tal que las redes desconocidas las tome como privadas para evitarnos problemas con los cortafuegos y las comunicaciones entre los nodos del Cluster. Esto se hace de forma muy sencilla modificando la “Default Domain Policy” como muestra la siguiente pantalla
En las siguientes pantallas pueden observar la configuración inicial de red de HYPER1 e HYPER2. Como es mi costumbre, y recomiendo, he renombrado las interfaces de red, ya que usaremos varias (4) y es muy importante no confundirlas
Es importante notar que salvo la interfaz que conecta al Dominio (DomainNet), en las otras se debe desactivar la registración en DNS
El paso siguiente, y siempre en HYPER1 e HYPER2 es agregar la funcionalidad Hyper-V que no mostraré las capturas ya que entiendo que nadie que esté leyendo esto tenga dudas de cómo hacerlo. La única consideración es que no he creado ninguna red virtual durante la instalación, sino que lo he hecho posteriormente a la instalación a fin de asegurarme sobre a qué placa se conectará
Es muy importante que este “External Switch” se cree sobre la conexión “Domain Net”, lo cual podemos verificar viendo que sólo quedó marcada la opción del protocolo correspondiente
Dejemos por unos momentos estas dos máquinas virtuales, y configuremos el equipo SAN
A este equipo le he configurado dos discos virtuales que ofrecerá a los “iSCSI Initiators” (HYPER1 e HYPER2); uno chico que se usará como disco “Witness” (Testigo), y otro que guardará el VHDX compartido para almacenamiento
Si alguien no recuerda la configuración de una SAN puede consultar: Windows Server 2012: Failover Cluster para Hyper-V (Parte 2 – Configurando la SAN)
Lo mismo para la configuración de los “iSCI Initiators) que haremos sobre HYPER1 e HYPER2, consultando: Windows Server 2012: Failover Cluster para Hyper-V (Parte 3 – Configurando los iSCSI Initiators)
En la siguente figura podemos ver la configuración en el equipo SAN
Luego en HYPER1 ponemos los discos “Online”, los inicializamos y creamos los volúmenes correspondientes
Luego, en HYPER2 solamente nos toca ponerlos “Online”
Siempre en HYPER1 e HYPER2, agregaré la última placa de red (la cuarta) que dedicaremos a la comunicación de los nodos del Cluster virtual que luego crearemos
La he denominado “GuestCluster” y he configurado las direcciones IP de acuerdo a la tabla al principio de la nota (HYPER1: 192.168.5.1/24 – HYPER2: 192.168.5.2/24)
El paso siguiente es instalar la funcionalidad Hyper-V en ambos nodos, que no demostraré cómo se hace ¿todos saben cómo no es cierto?
Y comenzaremos a la creación del Cluster real sobre HYPER1 e HYPER2
Validaré la configuración por las dudas
Me faltó una captura de pantalla: simplemente “Next”
Y comenzamos la creación del Cluster
Le asignamos nombre y dirección de red
Verificamos que ambos nodos estén “Online”
Verificamos que fueron asignados correctamente los discos (El más chico como “Witness”)
Y configuramos el disco de almacenamiento como “Cluster Shared Volume”
Por último y no sólo para por ser prolijo, sino para evitar confusiones, en cada una de las interfaces de red las he renombrado y asignado su uso. La “pista” para saber cuál es cuál es mirando el direccionamiento IP de cada una
Resumiendo lo hecho hasta ahora: ya tenemos creado y configuradas las redes que necesitaremos en las máquinas reales; y ya está creado y configurado el Cluster con las mismas
En la próxima nota continuaremos el tema creando el “Cluster Virtual”
WindowServer 
Comentarios
Hola Guillermo excelente . Muchas gracias
Gracias Jorge :)
Buenas Guillermo, un post muy interesante, cada vez te superas más.
Tengo alguna duda, aunque no sé muy bien si realmente corresponde a este artículo. Tengo entendido que entre las nuevas funcionalidades de Hyperv 2012 R2, para crear un cluster, ya no es necesario hacerlo por iscsi, sino que se puede por smb 3.0. Una de las restricciones del disco iscsi es que solo puede estar activo en un nodo a la vez, cierto?
Digo esto, porque me gustaría saber como se montaría un cluster hyperv activo-activo y si para este entorno sería necesario que el almacenamiento donde se guardarían los vhd de las VM fuera por smb para que fuera accesible por todos los nodos a la vez. La idea que tengo es montar el cluster con 4 nodos y poder llenarlos aproximadamente al 50-66% de carga cada uno.
Hola Xavi, gracias
Hace ya un tiempo armé 7 notas creando un cluster de Hyper, con almacenamiento en SMB3. Fue en realidad un prueba de concepto porque hice el cluster de Hyper-V, almacenando las máquinas virtuales en un Cluster «File server», que su vez tomaba los discos por iSCSI de otra máquina con «Storage Space»
El objetivo no era solamente desarrollar cómo configurar cada uno, sino además probar el funcionamiento conjunto de los tres temas
Te dejo los enlaces donde está la configuración del «File Server» específicamente, pero si quieres comprenderlo supongo que tendrás que leerte las 7 notas :-)
Hyper-V Cluster con Máquinas Virtuales en File Server Cluster – Demostración (Parte 4 Configurando Cluster File Server) | WindowServer:
https://windowserver.wordpress.com/2013/08/21/hyper-v-cluster-con-mquinas-virtuales-en-file-server-cluster-demostracin-parte-4-configurando-cluster-file-server/
Hyper-V Cluster con Máquinas Virtuales en File Server Cluster – Demostración (Parte 5 Configurando Scale-Out Cluster File Server) | WindowServer:
https://windowserver.wordpress.com/2013/08/23/hyper-v-cluster-con-mquinas-virtuales-en-file-server-cluster-demostracin-parte-5-configurando-scale-out-cluster-file-server/
Que el cluster pueda ser activo-activo depende de la aplicación «clusterizada»
Gracias Guillermo, no entiendo como se me escapó este articulo.
Me he leído las notas, aunque debo hacerlo otra vez y con más profundidad. Por otro lado me surgen nuevas dudas. En mi caso dispongo de un nas/san netapp profesional con dos controladoras redundadas y tropocientos mil interfaces de red con LACP que me podría hacer el rol del cluster file server. Sin embargo por lo que veo en tus notas, el SOFS (scale out file server como le llaman por internet) con smb 3.0, es específico para hyper-v y SQL lo cual dudo que pueda decir lo mismo del smb del netapp.
Aparte me gustaría quizas, que me dieras tu opinión sobre qué es mejor, si montar un cluster hyper-v con volúmenes iscsi en CSV o en su lugar montar un servidor SOFS y el cluster de hyper-v que sea por SMB, valorando la sencillez, el rendimiento y la capacidad de conmutar las VM de un nodo a otro con el live migration. La idea también que haya la capacidad de poder aumentar los nodos del cluster con el tiempo
Gracias.
Voy leyendo tu mensaje y pongo comentarios siguendo dicho orden
– ¡Cuidado! No es lo mismo NAS que SAN. El primero es un «file server»
– ¡Exacto! SMB3 es, por ahora, sólo para Hyper-V y SQL
– No puedo dar opiniones :-) Lo más conveniente depende de varios factores que sólo tú, conociendo la infraestructura, puede valorar. Respecto a «live migration», ya no es una característica sólo de «cluster», si buscas en el blog verás que hay una nota hecha de «live migration» sin cluster
Buenas Guillermo,
Lo que quería decir, es que en el caso de netapp, puede hacer los dos roles, es decir, dar volúmenes por iscsi como disco bloque o servir un recurso smb o nfs a todos los elementos de la red.
De momento lo he hecho por iscsi (como pones en el artículo de cluster por iscsi), siendo el netapp el que sirve los volúmenes, pero tal vez luego pruebe por smb, sin embargo leyendo en la página web no estoy del todo convencido https://library.netapp.com/ecmdocs/ECMP1196891/html/GUID-3E1361E4-4170-4992-85B2-FEA71C06645F.html
Por otro lado, me acaba de surgir otra duda. Tenemos ya un servidor de virtualización con W2008r2 que tendrá un par de años, pero bastante potente. El caso es que este es un servidor intel. Los nuevos servidores para el cluster serán con casi toda seguridad amd. Lo que había pensado es poder reinstalar el antiguo servidor intel a WS2012R2 y unirlo al cluster con el resto de amd.
Ahora la duda: Hyper-v cuando crea la MV, emula los componentes, y por lo que he visto, al menos el core es el mismo que el de la máquina física. Si yo creo una MV en uno de los nodos AMD e intento hacer live migration al servidor Intel, ¿puede ser que la MV se haga un lío con que el core emulado es amd y la máquina host tiene core intel?
Un saludo y como siempre enhorabuena por tu blog.
No se puede pasar una VM desde Intel a AMD, o viceversa
Hay una opción para marcar, que ahora no recuerdo el nombre, que habla de compatibilidad de procesador, pero eso además de disminuir el rendimiento, es para poder mover entre diferentes procesadores pero del mismo fabricante
Trackbacks
[…] la anterior nota proseguimos con la configuración necesaria con objetivo […]
[…] la anterior nota proseguimos con la configuración necesaria con objetivo […]