GuilleSQL :: Microsoft SQL Server, SSIS, y más !!

Configurar un Cluster de Hyper-V R2 con Windows Server 2008 R2, CSV y Live Migration – Parte I


El presente artículo, es el primero de una serie que describen paso a paso la instalación y configuración de un Cluster de Hyper-V R2 con Windows Server 2008 R2, incluyendo la configuración de los discos compartidos, de Cluster Shared Volume (CSV), de Live Migration, detalles específicos sobre la configuración de la Red, etc. En esta primera entrega, se detalla es escenario del laboratorio en el que se ha basado el artículo, la configuración de Red, la instalación del Failover Cluster en Windows Server 2008 R2, la Validación del Cluster, y la creación del Cluster.

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).

Aspecto del diálogo de Conexiones de Red

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).

Propiedades de la tarjeta de red Intel Gigabit CT Desktop Adapter (Virtual 

Switch)

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.

Propiedades de la tarjeta de red Realtek Gigabit PCI (Virtual Switch)

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.

Propiedades de la Virtual NIC correspondiente a la Realtek Gigabit PCI

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.

Propiedades de la tarjeta de red Realtek Gigabit integrada en placa

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

Aspecto del Virtual Network 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.

Seleccionamos la opción Add Features, desde el Server Manager

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

En la pantalla de Select Features, seleccionaremos la opción Failover 

Cluster

En la pantalla Confirm Installation Selections, click Install.

En la pantalla Confirm Installation Selections, click Install.

Barrita de progreso al canto. Esperaremos breves instantes.

Barrita de progreso al canto. Esperaremos breves instantes

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

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):

Si estuviésemos instalando el Failover Cluster es un Server Core, 

ejecutaríamos 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):

Sin embargo, en nuestro caso, se trata de una edición Full, por lo cual, 

deberemos ejecutar 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.

Comprobar la instalación de Failover Cluster desde Server Manager

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.

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 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 Select Servers or a Cluster, seleccionaremos los 

servidores sobre los cuales deseamos configurar el Cluster (ej: host01.guillesql.local y host02.guillesql.local)

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 Testing Options, seleccionaremos la opción Run all 

tests (recommended)

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

En la pantalla de Confirmation, click Next para continuar

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.

En la pantalla Summary, podemos ver los resultados de la Validación del 

Cluster

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.

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 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 Select Servers, seleccionaremos los servidores que formarán 

nuestro Cluster (ej: host01.guillesql.local y host02.guillesql.local)

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 Access Point for Administering the Cluster, especificaremos el 

nombre que deseemos para el Cluster (en nuestro caso será HyperClus), y una Dirección IP

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

En la pantalla Confirmation, revisamos la información resumen, y si estamos de 

acuerdo, click Next

Comienza la configuración del Cluster.

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.

Finalmente, la creación del Cluster habrá finalizado

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

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.

Ahora es un buen momento para renombrar las redes de nuestro Cluster

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

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.

Es recomendable ejecutar desde PowerShell el comando Get-ClusterNetwork, para obtener 

información sobre la configuración de la red de nuestro Cluster.

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.


[Fecha del Artículo (UTC): 22/11/2010]
[Autor: GuilleSQL]


Comentarios

Guiye - 20/05/2014 (UTC)
Hola guille,
Gracias por tener tu web al día, sinceramente me ayuda mucho con mis estudios y mi vida en general jeje.
El motivo de este mensaje es para que me resuelvas una duda, sobre las interfaces del cluster. ¿Podrias publicar las IP's sobre las que se encuentran tus interfaces fisicas del laboratorio?

Gracias por tu tiempo.



Escribir un Comentario

Para poder escribir un comentario, debe Iniciar Sesión con un usuario.

Si no dispone de un usuario, puede Registrarse y hacerse miembro.

Si dispone de un usuario, pero no recuerda sus credenciales de acceso, puede Restablecer su Contraseña.

Miembros de
Miembros de GITCA (Global IT Community Association)

Menu de Usuario
  Iniciar Sesión
  Registrarse
  Restablecer Contraseña
  Ventajas de Registrarse

Acerca de
  Contigo desde Oct 2007
  771 usuarios registrados
  86146 pageloads/mes
  Ranking Alexa 498160

Social Networks
Sigue a Portal GuilleSQL en Linkedin !!
Sigue a Portal GuilleSQL en Twitter !!



Archivo

Enero de 2017 (4)
Junio de 2016 (1)
Mayo de 2016 (2)
Abril de 2016 (2)
Septiembre de 2015 (2)
Agosto de 2015 (2)
Junio de 2015 (10)
Mayo de 2015 (4)
Abril de 2015 (8)
Marzo de 2015 (11)
Octubre de 2014 (3)
Septiembre de 2014 (7)
Agosto de 2014 (5)
Julio de 2014 (2)
Mayo de 2014 (4)
Abril de 2014 (4)
Marzo de 2014 (4)
Febrero de 2014 (1)
Enero de 2014 (5)
Diciembre de 2013 (8)
Noviembre de 2013 (2)
Octubre de 2013 (7)
Septiembre de 2013 (6)
Agosto de 2013 (1)
Julio de 2013 (6)
Junio de 2013 (11)
Mayo de 2013 (7)
Abril de 2013 (6)
Febrero de 2013 (5)
Enero de 2013 (7)
Diciembre de 2012 (12)
Noviembre de 2012 (13)
Octubre de 2012 (5)
Septiembre de 2012 (3)
Agosto de 2012 (6)
Julio de 2012 (4)
Junio de 2012 (1)
Mayo de 2012 (2)
Abril de 2012 (7)
Marzo de 2012 (16)
Febrero de 2012 (9)
Enero de 2012 (5)
Diciembre de 2011 (10)
Noviembre de 2011 (10)
Octubre de 2011 (4)
Septiembre de 2011 (5)
Agosto de 2011 (2)
Julio de 2011 (2)
Junio de 2011 (4)
Mayo de 2011 (2)
Abril de 2011 (6)
Marzo de 2011 (4)
Febrero de 2011 (10)
Enero de 2011 (5)
Diciembre de 2010 (6)
Noviembre de 2010 (4)
Octubre de 2010 (8)
Septiembre de 2010 (4)
Agosto de 2010 (1)
Julio de 2010 (3)
Mayo de 2010 (5)
Abril de 2010 (6)
Marzo de 2010 (8)
Febrero de 2010 (3)
Enero de 2010 (1)
Diciembre de 2009 (9)
Noviembre de 2009 (14)
Octubre de 2009 (2)
Septiembre de 2009 (8)
Agosto de 2009 (2)
Julio de 2009 (10)
Junio de 2009 (9)
Mayo de 2009 (10)
Abril de 2009 (9)
Marzo de 2009 (3)
Febrero de 2009 (2)
Enero de 2009 (3)
Noviembre de 2008 (2)
Octubre de 2008 (2)
Septiembre de 2008 (2)
Agosto de 2008 (5)
Julio de 2008 (5)
Junio de 2008 (1)
Mayo de 2008 (3)
Abril de 2008 (2)
Marzo de 2008 (2)
Febrero de 2008 (2)
Enero de 2008 (5)
Noviembre de 2007 (2)
Octubre de 2007 (2)






Esta información se proporciona "como está" sin garantías de ninguna clase, y no otorga ningún derecho.
This information is provided "AS IS" with no warranties, and confers no rights.

Copyright © 2007 GuilleSQL, todos los derechos reservados.
GuilleSQL.com y GuilleSQL.net son también parte de Portal GuilleSQL.

Visitas recibidas (Page Loads) en GuilleSQL (fuente: StatCounter):

screen resolution stats
Visitas