Tenía ganas de finalizar este artículo. Aunque lo estuve preparando hace unos meses, capturando todas las pantallas, y demás, me faltaba añadir todo el texto y maquetarlo para la Web. Por fin he sacado un rato, y así es como ha quedado. Es bastante largo, así que, he decidido partirlo en varios artículos algo más manejables.

En cualquier caso, la intención que tenía, era la de intentar dejar en un único artículo la información suficiente (más o menos) para poder abarcar la instalación y configuración de un Cluster de Hyper-V sobre Windows Server 2008 R2, incluyendo la configuración de CSV, y otros detalles. Empezamos.

Introducción: descripción del entorno de Laboratorio

Partimos de un entorno formado por dos Host, ejecutando Windows Server 2008 R2 x64 DataCenter, ambos miembros del mismo dominio de Directorio Activo (en particular, del dominio guillesql.local, con nombre NetBIOS de GUILLESQL). Son máquinas prácticamente idénticas (misma placa base, mismo procesador, casi las mismas tarjetas de red, etc.) a los efectos que nos interesa. Ya están ejecutando el Role de Hyper- V, y en consecuencia, cada uno de los Host tiene sus propias Máquinas Virtuales, algunas en ejecución, otras no, etc., todas ellas almacenadas en discos locales (casi lo mejor, que últimamente estoy empezando a encontrar demasiadas redes de Almacenamiento SAN saturadas en los clientes, y la verdad, que en muchos casos el rendimiento cae de forma más que asombrosa).

Además, estos Hosts ya están registrados en una instalación de Virtual Machine Manager 2008 R2, en la cual aparecen inicialmente como Hosts independientes, con su almacenamiento local, sus Máquinas Virtuales, sus redes, etc.

El objetivo de este artículo, es convertir estos dos Host independientes, en un Cluster de Hyper-V. Evidentemente, para conseguir este menester, necesitamos de un almacenamiento compartido. Para ello, vamos a utilizar una máquina física con Windows Storage Server 2008 y Microsoft iSCSI Software Target, la cual tiene dos tarjetas red a Gigabit, una conectada a la VLAN de Producción (para tráfico SMB, conexiones RDP, etc.), y otra conectada a la VLAN de iSCSI (para tráfico iSCSI, sólo y exclusivamente), apoyadas en un Switch Gigabit configurado en consecuencia (tanto a nivel de Port Based VLAN como de VLAN Tagging).

Todas las tareas que vamos a realizar a continuación, incluyendo sus correspondientes pantallas capturadas, son parte de un entorno de Laboratorio. Las pruebas realizadas han sido satisfactorias, y todo ha quedado funcionando correctamente, aunque tiene sus cosillas. Por poner un ejemplo, el hecho de que los controladores de dominio sean Máquinas Virtuales, implica que al arrancar los Host, no arrancará correctamente el Cluster (normal, en el momento del arranque del Cluster, aún no ha finalizado el Startup de los DCs, que son Máquinas Virtuales que se ejecutan en los propios Hosts), por lo que una vez estén arrancados los DCs tendremos que poner OnLine manualmente los recursos de Cluster Core, y además, deberemos poner OffLine y poner OnLine los discos configurados como Cluster Shared Volume (CSV) para que todo empiece a funcionar bien. Tras este aburrido proceso de arranque, podemos arrancar las Máquinas Virtuales clusterizadas, hacer Live Migration y/o Quick Migration, etc. Al final, esto es un simple y llano entorno de Laboratorio.

Quizás, antes de continuar con la lectura del presente artículo, pueda resultar de interés consultar otros artículos anteriores como Live Migration y Cluster Shared Volume (CSV), Failover Cluster en Windows Server 2008 y Failover Cluster en Windows Server 2008 R2.

Sin más, empezamos.

Configuración de la RED

Antes de empezar con la propia instalación del Failover Cluster, es importante ver el tema de la Red, ya que quizás junto al Almacenamiento, sea de las cosas que más guerra suele dar en entornos de Virtualización.

Para montar un Cluster de Hyper-V, es importante tener en cuenta los diferentes tipos de tráfico que deberemos soportar, en particular:

• Tráfico de la Red de Gestión: Conexiones RDP, tráfico SMB, etc.
• Tráfico de HeartBeat. Es muy ligero, a fin de cuentas, son simples conexiones de un Host a otro para comprobar que siguen vivos. No debe preocuparnos su consumo.
• Tráfico de Live Migration. Al hacer Live Migration de una Máquina Virtual, se moverán las páginas de memoria desde el Host original, al Host destino. Este, es el tráfico Live Migration. Mientras no se realiza Live Migration, no debe preocuparnos su consumo.
• Tráfico de Cluster Shared Volume (CSV). Si un Host pierde el acceso al almacenamiento compartido configurado como CSV, podría acceder a dicho almacenamiento compartido, reenviando las peticiones de I/O a través del otro Host del Cluster (se evita una pérdida de servicio, pero se incurre en un consumo de red intenso, en forma de tráfico SMB). Salvo en este caso, no debe preocuparnos su consumo.
• Tráfico de las Máquinas Virtuales. En función de cuántas Máquinas Virtuales tengamos, y el consumo de red que requiera cada una, el ancho de banda necesario puede ser mayor o menor. Recomendable al menos una tarjeta de red dedicada, y que soporte VLAN Tagging.
• Opcionalmente, Tráfico iSCSI, en caso de que se utilice un Almacenamiento compartido iSCSI, como es el caso de nuestro entorno de Laboratorio. Debe tenerse en cuenta, que pueden ser clientes iSCSI tanto los Host de Hyper-V (para soportar los discos compartidos del Cluster), como las Máquinas Virtuales (para montar un Cluster con Máquinas Virtuales, o asignarles LUN para otros motivos, como Backup).

En nuestro caso, tenemos dos Host, en cada uno de los cuales tenemos tres tarjetas de red Gigabit:

• Intel Gigabit CT Desktop Adapter. Esta tarjeta de red, se utilizará en exclusiva para el tráfico de las Máquinas Virtuales. Es la única de las tarjetas que tenemos en el Host, que soporta VLAN Tagging en Windows Server 2008 R2, por lo que resulta especialmente apropiada para dicha función.
• Realtek Gigabit PCI. Esta tarjeta de red se utilizará para el tráfico de HeartBeat, y también, para el tráfico iSCSI (tanto del Host como de las Máquinas Virtuales), para el tráfico de Live Migration y el tráfico de Clustered Shared Volume (CSV).
• Realtek Gigabit integrada en placa. Esta tarjeta de red se utilizará en exclusiva para el tráfico de red de gestión (Conexiones RDP, tráfico SMB, etc.).

Así es como se muestra el diálogo de conexiones de red (Network Connections).

La tarjeta de red Intel Gigabit CT Desktop Adapter, está configurada como un Virtual Switch (es decir, en Hyper-V hemos configurado una Red Virtual de tipo External), y sólo puede ser utilizada por las Máquinas Virtuales (es decir, en Hyper-V hemos dejado sin marcar la opción Allow management operating system to share this network adapter).

La tarjeta de red Realtek Gigabit PCI, está configurada como un Virtual Switch (es decir, una Red Virtual de tipo External), para que las Máquinas Virtuales puedan acceder al tráfico iSCSI. Sin embargo, también es necesario que el Host acceda al tráfico iSCSI a través de esta misma tarjeta de red, por lo que en Hyper-V hemos marcado la opción Allow management operating system to share this network adapter, para así crear una Virtual NIC.

El hecho de que marcásemos la opción Allow management operating system to share this network adapter desde el Hyper-V Manager, implica que nos ha aparecido una nueva tarjeta de red, la cual se denomina Virtual NIC. Esta Virtual NIC es la que configuraremos para la conexión del Host con la Red, es decir, en la que configuraremos TCP/IP. Recordemos, que la tarjeta de red original es el Virtual Switch, y la Virtual NIC es una tarjeta de red Virtual para su utilización por el Host, como si el Host fuese una Máquina Virtual más conectada al Virtual Switch. Ojito, que para que funcione bien el CSV, es necesario habilitar Client for Microsoft Networks y File and Printer Sharing for Microsoft Networks.

La tarjeta de red Realtek Gigabit integrada en placa, se utilizará por el Host sólo y únicamente, por lo que en este caso, no tenemos ni Virtual Switch ni Virtual NIC. Es una tarjeta de red, de las de toda la vida, sin ninguna Red Virtual configurada sobre ella.

Por hacernos una idea de cómo quedan configuradas las Redes Virtuales en el Hyper-V Manager:

Recordemos que debemos configurar las Redes Virtuales, exactamente con el mismo nombre, en todos los Nodos del Cluster, para que al mover una MV de un nodo a otro, se mantenga la MV asociada a la red, y no se quede aislada.

Llegados a este punto, damos por finalizada la configuración de red, que realmente, ya estaba configurada antes de montar el Cluster. No tenemos aún configurado ningún Almacenamiento compartido, aunque si esté configurado la red para el acceso al Target iSCSI (tanto la configuración de la VLAN en los puertos del Switch, como el direccionamiento IP, y otros detalles).

Instalar Failover Cluster en Host01, a través del Server Manager

Vamos a comenzar la instalación del Cluster en uno de los Hosts, en particular, en el Host01. Para ello, lo primero, abrir la herramienta administrativa Server Manager, seleccionar Features, y seguidamente click en Add Features.

En la pantalla de Select Features, seleccionaremos la opción Failover Cluster. Click Next para continuar.

En la pantalla Confirm Installation Selections, click Install.

Barrita de progreso al canto. Esperaremos breves instantes.

Y por fin, ha quedado instalado. Click Close para continuar.

Instalar Failover Cluster en Host02, a través de línea de comandos (con ocsetup.exe)

Ahora toca hacer lo equivalente en el otro Nodo del Cluster. Para variar, y por motivos didácticos, vamos a realizar esta misma instalación pero desde línea de comando, similar a como se haría en una instalación Server Core.

Si estuviésemos instalando el Failover Cluster es un Server Core, ejecutaríamos una línea de comandos como la siguiente (Start /w ocsetup FailoverCluster-Core):

Sin embargo, en nuestro caso, se trata de una edición Full, es decir, que no es un Server Core, por lo cual, deberemos ejecutar un comando diferente, aunque es prácticamente lo mismo (Start /w ocsetup FailoverCluster-FullServer):

Y ya está. Si lo deseamos, podemos utilizar el Server Manager, para comprobar que efectivamente se ha instalado la Feature de Failover Cluster.

Realizado esto, ya tenemos instalada la Feature de Failover Cluster, en ambos Nodos. Claro está, que aún queda configurarlo.

Validar el Cluster

Si lo deseamos, antes de configurar el Cluster, podemos Validar el Cluster, con el objetivo de que podamos conocer que errores o advertencias tienen nuestros sistemas cara a la configuración del Cluster que deseamos realizar. Para ello, abriremos la herramienta administrativa Failover Cluster Manager, y ejecutaremos la opción Validate a Configuration.

En la pantalla de bienvenida del asistente, click Next para continuar.

En la pantalla Select Servers or a Cluster, seleccionaremos los servidores sobre los cuales deseamos configurar el Cluster (ej: host01.guillesql.local y host02.guillesql.local). Click Next para continuar.

En la pantalla Testing Options, seleccionaremos la opción Run all tests (recommended). Ojo, porque ahora las máquinas no están dando servicio. En caso contrario, tendríamos que plantearnos ejecutar los Test fuera de horario, y seleccionar los Test que deseamos ejecutar (ej: quizás nos interese no ejecutar los Tests de Almacenamiento si tenemos discos compartidos presentados, con datos, y dando servicio).

En la pantalla de Confirmation, click Next para continuar. Con esto, empezará la ejecución de los Test seleccionados.

En la pantalla Summary, podemos ver los resultados de la Validación del Cluster. Es importante saber interpretarlos. Quiero decir, que por ejemplo en nuestro caso, no tenemos configurado ningún Almacenamiento compartido, por lo que nos aparecerán varios Warnings relacionados con el Almacenamiento, lo cual es OK, no problem.

Crear el Cluster

No hemos detectado ningún problema en la Validación del Cluster que hemos realizado previamente, así que, vamos a comenzar la creación del Cluster. Para ello, desde la herramienta administrativa Failover Cluster Manager, seleccionaremos la opción Create a Cluster.

En la pantalla de bienvenida del asistente para la creación de un nuevo Cluster, click Next para continuar.

En la pantalla Select Servers, seleccionaremos los servidores que formarán nuestro Cluster (ej: host01.guillesql.local y host02.guillesql.local). Click Next para continuar.

En la pantalla Access Point for Administering the Cluster, especificaremos el nombre que deseemos para el Cluster (en nuestro caso será HyperClus), y una Dirección IP. Detalle curioso: tenemos múltiples tarjetas de red que pertenecen a diferentes segmentos, pero sólo podemos especificar una IP perteneciente al segmento de una de las tarjetas de red, pero ¿de cuál? Pues por lo que parece, de la que tiene el Gateway, que en nuestro caso, en la red de Producción, y es lo que deseamos. Click Next para continuar.

En la pantalla Confirmation, revisamos la información resumen, y si estamos de acuerdo, click Next.

Comienza la configuración del Cluster.

Finalmente, la creación del Cluster habrá finalizado. Deberemos revisar los Warnings. En nuestro caso, se muestran dos, que no nos preocupan. No tenemos aún configurado ningún Disco Compartido o Shared Folder que pueda funcionar como Quorum, y además, tenemos un número par de Nodos, por lo que deberemos corregir esta situación, entre otras cosas, para evitar el Síndrome del Cerebro Partido (Split Brain). De todo esto, nos ocuparemos luego.

En estos momentos, este es el aspecto de muestra el Cluster que acabamos de crear.

Ahora es un buen momento para renombrar las redes de nuestro Cluster, para que nos quede todo más claro.

Así quedan las propiedades de la red de Producción.

La red de HeartBeat, queda similar, aunque utiliza una subred diferente, y no tiene marcada la opción Allow clients to connect through this network.

Por último, es recomendable ejecutar desde PowerShell el comando Get-ClusterNetwork, para obtener información sobre la configuración de la red de nuestro Cluster. A continuación se muestra una salida de ejemplo, en la que se puede apreciar, como la red de Producción tiene una métrica de 10000 mientras que la red de HeartBeat tiene una métrica de 1000. Estos son valores por defecto, que permiten configurar la red de HeartBeat para ser utilizada para el tráfico CSV, lo cual, además era nuestra intención.

Un detalle curioso sobre las redes y el Cluster: habitualmente, cuando montamos un Cluster (ej: para SQL Server o Exchange Server), las tarjetas de red que utilizan estos servicios aparecen en el Cluster, lo que sería habitualmente la red de Producción. Con Hyper-V no tiene porque ser así. Lo primero, porque como veremos más adelante, una Máquina Virtual en Cluster, no requiere ningún Recurso de Cluster de tipo Dirección de IP, y ya sólo con esto, se rompe dicho vínculo. Además, si configuramos para Hyper-V una o varias tarjetas de red para su acceso de forma exclusiva (que actúen como Virtual Switch, sin ningún Virtual NIC asociado), pues es como si el Host (el S.O. anfitrión) no tuviese dichas tarjetas de red. Bueno, no tiene mayor importancia. A mi al menos, me llamó la atención este detallín.

Hasta aquí hemos llegado por hoy. En la siguiente entrega, continuaremos con las siguientes tareas, como añadir un disco compartido al Cluster para utilizar como Quorum, configurar la Quorum del Cluster, añadir un disco de datos al Cluster para el almacenamiento de Máquinas Virtuales, y configurar CSV en el cluster. Además, en la última entrega, veremos entre otras cosas, la forma de crear una nueva Máquina Virtual en Cluster desde Hyper-V Manager, como configurar dicha Máquina Virtual en Alta Disponibilidad, y como configurar las redes de Live Migration.