El Blog de Gualtrysoft

Windows 2000/2003/2008, Active Directory, VBScript, Hyper-V, PowerShell y todo aquello interesante a la hora de usar, configurar y administrar Windows Server. También tenemos longanizas…

Novedades en Virtualización de Windows Server 2008 R2

Posted by urpiano en Miércoles 28 \28\UTC octubre \28\UTC 2009

En esta entrada repasamos las principales novedades que incorpora Windows Server 2008 R2 en el tema de virtualización con Hyper-V.

Las áreas claves de mejora de Hyper-V en Windows Server 2008 R2 son:

  • Escalabilidad: Hyper-V soporta hasta 64 procesadores lógicos por host.
  • Disponibilidad: Hyper-V soporta Live Migration de máquinas virtuales cuando se usan Clustered Shared Volumes (CSV).
  • Eficiencia: Hyper-V incorpora mejoras de red.
  • Flexibilidad: Hyper-V soporta la adición o sustracción de discos en caliente.

Windows Server 2008 R2 incorpora varias novedades, respecto a la virtualización, que hacen que supere a su predecesor en cosas muy interesantes. Se verán a continuación estas mejoras respecto a:

  • Virtualización de escritorio.
  • Discos HotSwap.
  • Live Migration.
  • Red mejorada.

Virtualización de escritorio (VDI)

Windows Server 2008 R2 permite la virtualización del escritorio por medio los nuevos roles:

  • RD Virtualization Host
  • RD Connection Broker

Remote Desktop Virtualization Host

Este nuevo role consiste en una unión de los servicios de gestión de Hyper-V y el Broker de conexiones. Se encarga de informar acerca de las VMs disponibles en el host al broker y de llevar ciertas acciones sobre las máquinas virtuales. Arrancarlas o despertarlas si están paradas o salvadas en el momento de ser solicitadas por el usuario, o apagarlas tras un cierto tiempo de inactividad.

Este role no tiene que habilitarse en todos los servidores de Hyper-V R2 con los que queramos tratar desde el broker de conexiones, sean stand-alone o miembros de un cluster.

Remote Desktop Connection Broker

Es una evolución de TS Sessión broker, que hasta ahora solo servía para balancear carga de trabajo entre servidores de una misma granja de Terminal Servers, y reconectar a los usuarios con el servidor en el que estuviera abierta su sesión. Si se imagina un pool de máquinas virtuales como un conjunto de servidores de Terminal Server configurados de forma idéntica y que solo pueden recibir una sesión de usuario simultánea, la idea es perfectamente extrapolable al mundo de VDI. En este rol se pueden configurar las siguientes opciones de VDI:

  • VDI estáticos. Cada usuario tiene asignada una VM específica. Esto se logra mediante una nueva propiedad de los usuarios en AD, en la que se almacena la VM asignada a ese usuario.
  • VDI Dinámicos. Se definen conjuntos de VMs o Pools de VMs idénticamente configuradas, que serán asignadas a los usuarios que las demanden de manera dinámica. Los usuarios que hayan dejado sus sesiones abiertas o desconectadas, serán redirigidos de nuevo a la misma VM del pool para mantener su trabajo.

Para configurar y operar los dos escenarios de VDI, el Bróker habla con el RD Virtualization Host de los servidores con Hyper-V donde corren esas máquinas virtuales.

Discos HotSawp

Entre las mejoras realizadas en el almacenamiento en máquinas virtuales se incluye la posibilidad de conectar y desconectar el almacenamiento en caliente. Dado que se pueden agregar o quitar discos duros virtuales o físicos mientras la máquina virtual está en ejecución, las máquinas virtuales se pueden configurar rápidamente para que cumplan los requisitos en constante cambio. También se pueden agregar o quitar discos duros virtuales y físicos a las controladoras SCSI existentes de las máquinas virtuales. La conexión y desconexión en caliente del almacenamiento requiere la instalación de los servicios de integración de Hyper-V (que se suministran junto con Windows Server 2008 R2) en el sistema operativo invitado.

Live Migration

Live Migration permite mover de manera transparente máquinas virtuales, albergadas en un cluster de Hyper-V, de un nodo del clúster a otro nodo del mismo clúster sin que se interrumpa la conexión de red o se perciba tiempo de inactividad alguno.

La migración en vivo, si bien no lo requiere, hace uso de la nueva característica Volúmenes compartidos de clúster (CSV) del Clúster de conmutación por error en Windows Server 2008 R2, lo que hace más ágil y posible la migración en vivo (SCVMM intenta la migración en vivo varias veces, comprobando que se haya realizado bien, que no varíe la memoria de la ubicación de origen y la de destino, y si no lo consigue acaba realizando una migración rápida; usando CSV se aumenta la probabilidad de éxito de la migración en vivo, al no necesitarse realizar el cambio de exclusividad de acceso a la LUN desde el nodo de origen al de destino). CSV proporciona un espacio de nombres de archivos único y coherente para que todos los servidores que ejecutan Windows Server 2008 R2 vean el mismo almacenamiento.

La migración en vivo realiza las siguientes acciones para aportar una mayor flexibilidad y un valor adicional:

  • Proporciona más agilidad. Los centros de datos con varios servidores que ejecutan Hyper-V pueden mover máquinas virtuales en ejecución al mejor equipo físico para optimizar el rendimiento, el escalado y la consolidación sin que los usuarios se vean afectados.
  • Reduce los costos. Los centros de datos con varios servidores que ejecutan Hyper-V pueden realizar tareas de mantenimiento en tales servidores sin interrumpir la actividad de la máquina virtual o sin tener que programar un período de mantenimiento. Asimismo, podrán reducir el consumo energético al aumentar dinámicamente las proporciones de consolidación y apagar los servidores sin usar durante períodos de menor demanda.
  • Aumenta la productividad. Es posible mantener máquinas virtuales conectadas, incluso durante las tareas de mantenimiento, lo cual aumenta la productividad tanto de los usuarios como de los administradores del servidor.

Cluster Shared Volumes

La prestación de Volúmenes compartidos de clúster (CSV) es la novedad en la implantación de NTFS que permite agilizar la ejecución de Live Migration. Con Volúmenes compartidos de clúster, la configuración de las máquinas virtuales en clúster es mucho más sencilla que antes. Con Volúmenes compartidos de clúster se pueden realizar las siguientes acciones:

  • Se puede reducir el número de LUNs necesarios para las máquinas virtuales, en lugar de tener que administrar un LUN por máquina virtual (antes, la configuración recomendada era una LUN por máquina virtual, porque la LUN era la unidad de conmutación por error). Varias máquinas virtuales pueden usar un solo LUN y pueden conmutar por error sin provocar la conmutación por error de las otras máquinas virtuales del mismo LUN.
  • Se puede usar mejor el espacio del disco, porque no necesita colocar cada archivo VHD (disco duro virtual) en un disco independiente con espacio en disco adicional reservado exclusivamente para ese archivo VHD. En su lugar, cualquier archivo VHD de ese LUN puede usar el espacio libre de un volumen compartido de clúster.
  • Se puede realizar más fácilmente un seguimiento de las rutas de acceso de los archivos VHD y de otros archivos de las máquinas virtuales. Se puede especificar los nombres de las rutas de acceso en lugar de identificar los discos mediante las letras de unidad (limitadas al número de letras del alfabeto) o mediante identificadores denominados GUID (difíciles de usar y de recordar). Con Volúmenes compartidos de clúster, la ruta de acceso parece estar en la unidad de sistema del nodo, en la carpeta \ClusterStorage. Sin embargo, esta ruta de acceso es la misma cuando se ve desde cualquier nodo del clúster.
  • Si se usan algunos volúmenes compartidos de clúster para crear una configuración que admite varias máquinas virtuales en clúster, se puede realizar la validación más rápidamente que con una configuración que use varias LUNs para admitir varias máquinas virtuales en clúster. Con menos LUNs, la validación se ejecuta más rápidamente. La validación se realiza ejecutando el Asistente para validar una configuración del complemento para clústeres de conmutación por error.
  • No hay ningún requisito de hardware especial aparte de los que son normalmente necesarios para el almacenamiento en un clúster de conmutación por error (aunque Volúmenes compartidos de clúster requiere NTFS).
  • Aumenta la resistencia, puesto que el clúster puede responder correctamente aunque se interrumpa la conectividad entre un nodo y la SAN o una parte de la red esté fuera de servicio. El clúster desviará el tráfico de Volúmenes compartidos de clúster a una parte intacta de la SAN o la red.

Requerimientos de Live Migration

Los requerimientos de Live Migration son:

  • Todos los host de virtualización que usarán Live Migration tienen que estar configurados en un clúster de conmutación por fallo (máximo 16 nodos).
  • El clúster debe tener una conexión de red dedicada al tráfico de red de Live Migration o al menos que sea dedicada una conexión de red a HeartBeat y Live Migration conjuntamente:
    • 2 NICs
      • NIC1: HeartBit y Live Migration
      • NIC2: Gestión y Switch Virtual
    • 3 NICs
      • NIC1: HeartBit y Live Migration
      • NIC2: Gestión
      • NIC3: Switch Virtual
    • 4 NICs
      • NIC1: HeartBit y Live Migration
      • NIC2: Gestión
      • NIC3: Switch Virtual 1
      • NIC4: Switch Virtual 2 (También se puede crear un único Switch Virtual estableciendo un Team entre las tarjetas dedicadas a Switch Virtual)
  • Usar el mismo tipo y número de procesadores en todos los hosts de virtualización del clúster.
  • Configurar los hosts en la misma subred TCP/IP.
  • Acceso a almacenamiento compartido para todos los hosts.

Como se requiere que todos los nodos puedan acceder de forma simultánea a las LUNs, para disponer de Live Migration en un cluster multisitio, si se quiere utilizar CSV es necesario que el software de réplica de las cabinas sea capaz de replicar CSV; por el momento sólo las cabinas Metrolink y EVA son capaces de replicar CSV. Existe una solución de terceros que permite realizar Live Migration en un cluster multisitio sin necesidad de software de réplica de cabinas: SteelEye® DataKeeper™ Cluster Edition, que se basa en que los hosts de virtualización no conecten a cabinas SAN para el almacenamiento, si no que el almacenamiento de las máquinas virtuales sea DAS (interno) y este almacenamiento DAS es replicado entre los nodos. Aquí podemos ver una demo de Live Migration usando este software.

Notas

A la hora de implantar Live Migration se debe tener en cuenta:

  • Cuando se utilice CSV, a pesar de que permite tener todas las máquinas virtuales en una misma LUN, es preferible tener una LUN por máquina para mejorar el rendimiento. Para efectos de implantación y administración, es mejor que todos los discos de una misma máquina, así como su configuración, estén en una única LUN, pues apenas se penaliza el rendimiento y se simplifica su administración y su failover.
  • Hay que tener en cuenta que en un clúster se pueden producir de forma simultánea nº nodos/2 Live Migrations. Por ejemplo, en un clúster de 4 nodos se pueden producir 2 Live Migrations simultáneas.
  • Es conveniente que la tarjeta de red dedicada a Live Migration sea al menos 1 Gigabit Ethernet.

Red mejorada

Ahora la compatibilidad con las tramas gigantes (Jumbo Packets), que antes era exclusiva de los entornos no virtuales, se ha extendido a las máquinas virtuales. Esta característica permite que las máquinas virtuales puedan usar tramas gigantes de hasta 9.014 bytes si la red física subyacente lo admite.

Windows Server 2008 R2 incorpora el uso el uso de TCP Chimney a las máquinas virtuales. TCP Chimney es una tecnología de red que permite que el trabajo asociado a la transferencia de datos de una red se descargue de la CPU del equipo host al adaptador de red. Esto ayuda a mejorar el procesamiento de datos de red en el equipo o el servidor sin necesidad de programas adicionales o pérdida de capacidad de administración o seguridad. Los programas afectados por la sobrecarga de procesamiento de red suelen escalarse mejor si se usan con la descarga TCP Chimney.

Además de lo anterior, también se ha agregado la mejora de Virtual Machine Queue; los adaptadores de red que soportan la característica de VMQ son capaces de crear una cola de red única para cada adaptador de red virtual y conectarse directamente a la cola de memoria de la máquina virtual, lo que enruta paquetes directamente desde el Hypervisor a la máquina virtual, pasando por alto gran parte de la tramitación en la pila de virtualización de la partición padre. (Esta característica mejora notablemente el rendimiento de las conexiones de redes virtuales dentro de las máquinas virtuales).

Una respuesta to “Novedades en Virtualización de Windows Server 2008 R2”

  1. elegantthemes said

    Good day very nice blog!! Man .. Excellent .. Superb ..
    I will bookmark your site and take the feeds also? I’m satisfied to find numerous helpful information right here within the post, we need develop extra techniques in this regard, thanks for sharing. . . . . .

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

 
A %d blogueros les gusta esto: