Posts anteriores:

• Montando Laboratorios, Pruebas de concepto y Pilotos de Virtualización: Objetivo y consideraciones generales
• Montando Laboratorios, Pruebas de Concepto y Pilotos de Virtualización: Requerimientos: El Directorio Activo

Hola

Poco vamos a poder contar que no esté ya contemplado en la guía que se acaba de publicar aquí:

• Hyper-V: Live Migration Network Configuration Guide

Vamos a ver qué uso de la red hace una infraestructura de virtualización basada en Hyper-V, cómo se pueden utilizar las tarjetas de red del host en diferentes escenarios y como estos requisitos se hacen más importantes para el caso de los clústeres en las que se vaya a utilizar Live Migration.

En resumen, estas son las cosas que hay que saber:

• Hyper-V convierte las NICs que se le asignan como un switch virtual. El resto de tarjetas siguen perteneciendo a la partición padre y se utilizan exactamente igual que en el mundo físico.
• En el caso de querer utilizar NIC Teaming para agregación de ancho de banda y/o tolerancia a fallos, podremos hacerlo con el software del fabricante de las tarjetas y bajo sus recomendaciones y soporte. La “NIC resultante” será la que convirtamos en switch virtual, que funcionará a todos los efectos igual que en el caso anterior.
• A cambio de esta tarjeta física, se nos ofrece la posibilidad de crear en la partición padre una NIC virtual conectada a ese switch. Sobre esta NIC virtual, que a todos los efectos es igual que las NICs que tendremos en las máquinas virtuales, podemos definir si así lo deseamos, la VLAN ID a la que queremos que pertenezca.

• La tarjeta física que hemos convertido en switch virtual deberá estar conectada a una boca de un switch sício físico que se habrá definido como troncal (recomendado) o que tenga asignadas todas las posibles VLAN IDs que usen, tanto la partición padre, como las máquinas virtuales que tengan NICs conectadas a dicho switch virtual.

En hosts stand-alone podemos trabajar bastante bien con una o dos NICs físicas, si el uso de red de las máquinas virtuales no va a ser intensivo. Por ejemplo:

• En un portátil con una sola NIC, la enlazaremos a Hyper-V y marcaremos la casilla para que la partición padre tenga una NIC virtual que vea la red corporativa a través del switch virtual y pueda ser gestionada correctamente
• En un servidor con dos NICs podemos:
• Dedicar una NIC a gestión y la otra la convertiremos en switch virtual
• Convertir ambas NICs en switches virtuales y marcar la casilla solo en uno de ellos para obtener una NIC virtual con la que gestionar la partición padre. De esta manera podemos tener dos switches virtuales con los que distribuir el tráfico de las máquinas virtuales, o conectar cada switch virtual a diferentes segmentos de red.
• Hacer un Team y trabajar como en el caso de tener una sola NIC.

Sin embargo, para los hosts que vayan a ser miembros de un cluster vamos a tener diferente tipo de tráfico

• El de la gestión de la propia partición padre
• El del heartbeat del cluster
• El derivado de las Live Migrations
• El asociado a los Cluster Shared Volumes
• El que provenga de las máquinas virtuales.
• Posiblemente, el asociado a las copias de seguridad

En la guía que tenéis enlazada al principio del post tenéis los pormenores de las diferentes combinaciones. Es evidente que en producción vamos a necesitar que los hosts estén bien cargaditos de NICs, máxime si encima el almacenamiento es por iSCSI, pero lo cierto es que es factible configurar todo esto con una única NIC.

En estas figuras representamos varias opciones para probar en nuestro entorno de laboratorio, para el caso de que tengamos cuatro NICs y para el caso de tener solo dos. Somos conscientes de que hay más combinaciones posibles:

• 4 NICs, 1 vSwitch:

• 4 NICs, con dos de ellas en Teaming convertidas en vSwitch

• 4 NICs, 2 vSwitches, 1 vNIC para la partición padre:

• 2 NICs, 1 vSwitch, 1 vNIC para la partición padre

En el caso de nuestro laboratorio, los blades de los que disponemos solo tienen 2 NICs, y además el almacenamiento compartido es iSCSI como veremos en el siguiente post. No nos queda otro remedio que usar este último modelo, pero además utilizamos la tarjeta también para el tráfico dirigido al almacenamiento compartido.

Como todo esto es ciertamente un poco lioso, he aquí una lista de pistas y trucos que os pueden venir muy bien para acelerar el proceso de instalación y configuración de los hosts y minimizar los quebraderos de cabeza en fases posteriores:

1. Decide previamente el direccionamiento IP que tendrán:
• Las particiones padre de los hosts
• Los servidores virtuales
• La red de Hearbeat/CSV
• La red dedicada al almacenamiento
2. Renombra las NICs según para lo que se vayan a utilizar ANTES de agregar el role de Hyper-V. Esto es absolutamente innecesario desde un punto de vista funcional, pero creedme que ayuda. Por ejemplo
• “LAN” o “Produccion”
• vSwitch1, vSwitch2, etc. para las que vayan convertirse en Switches Virtulaes
• “Interna” o “HeartBeat”
• “CSV” para la de los CSVs
• “Live Migration”
• “iSCSI” para comunicarnos con el almacenamiento
3. Se consistente con esta ordenación en todos los hosts. Usa la misma NIC para la misma tarea en todos los hosts.
4. Asigna la configuración de red según el plan marcado. Las redes de almacenamiento y de heartbeat no suelen requerir ni puerta de enlace ni DNS, ni cliente para redes Microsoft, ni compartir archivos e impresoras. Recordemos que la red dedicada a CSVs DEBE tener esto ultimo enlazado
5. Durante el pequeño asistente que sale al agregar el role de Hyper-V se nos pregunta que tarjetas queremos dedicar como switches virtuales. Si no hemos seguido el segundo paso, nos encontramos con algo así. Es mucho mejor que en la columna nombre salga algo un poco más amigable, ¿no?. En cualquier caso, podemos no marcar ninguna casilla y hacerlo luego desde la consola de configuración de Hyper-V
6. Por último, y muy importante, utiliza los mismos nombres para switches virtuales en todos los hosts, ya que cuando una máquina se mueva a otro hosts se guiará por esta “etiqueta” para conectarse un switch virtual que se llame de la misma manera. Si no lo encuentra, se queda rá desconectada. Puedes llamar también vSwitch1 al switch virtual en que se ha convertido la NIC que llamamos vSwitch1 en el paso 2, o darle un nombre que de idea de la red física a la que está conectado, como en este ejemplo:
7. Por último, renombra las NICs virtuales que hayan aparecido en la partición padre como consecuencia de haber marcado la casilla citada anteriormente. En este caso, la vNIC1 es una tarjeta virtual conectada al switch virtual “Laboratorio”, que responde a la NIC física que hemos llamado vSwitch1:

Como decíamos más arriba, muchos de estos pasos son funcionalmente innecesarios y puede dar la impresión de que estamos complicando innecesariamente el proceso de configuración de la red. Sin embargo ayudan mucho a familiarizarnos con el funcionamiento del sistema, y facilitarán cambios de configuración que queramos hacer a posteriori. Y si en algún momento nos las tenemos que ver con sistemas con un gran número de NICs destinadas a diferentes tareas, esta metodología puede resultar de mucha utilidad.

Saludos

David Cervigón