NetApp Tech OnTap
     

Las cinco mejores prácticas más importantes para Hyper-V

La tecnología de virtualización Hyper-V™ de Microsoft® se ha estado comercializando desde hace más de un año. Tech OnTap ha estudiado el uso de Hyper-V con tecnología de NetApp® en varios artículos anteriores, como un artículo de presentación y un caso práctico detallado de las experiencias de un cliente.

NetApp ha participado en centenares de implementaciones de Hyper-V y ha desarrollado una recopilación detallada de las mejores prácticas para implementar Hyper-V en NetApp. Tech OnTap me ha pedido que resalte las cinco mejores prácticas más importantes para Hyper-V en NetApp, con especial atención a Hyper-V Server 2008 R2, publicado recientemente.

  • Configuración de red
  • Configuración del iGroup y el tipo de protocolo LUN correctos
  • Alineación de discos de equipo virtual
  • Uso de volúmenes compartidos en cluster (CSV)
  • Máximo aprovechamiento de las herramientas y el software de almacenamiento de NetApp

Puede encontrar los detalles completos de estos artículos y mucho más en Mejores prácticas de almacenamiento de NetApp para la virtualización de Microsoft (NetApp Storage Best Practices for Microsoft Virtualization), actualizado con contenidos sobre Hyper-V R2.

Práctica n.º 1: configuración de red en entornos de Hyper-V

Hay dos mejores prácticas importantes que deben mencionarse en lo que respecta a la configuración de red:

  • Asegúrese de facilitar el número correcto de adaptadores de red físicos en los servidores de Hyper-V.
  • Aproveche las nuevas funcionalidades de red compatibles con Hyper-V R2 siempre que sea posible.

Adaptadores de red físicos. Si no configura suficientes conexiones de red, puede parecer que tiene un problema de almacenamiento, especialmente si utiliza iSCSI. Los entornos más pequeños requieren un mínimo de dos o tres adaptadores de red, mientras que los mayores necesitan al menos cuatro o cinco. Puede que tenga que utilizar muchos más. Y este es el motivo:

  • Gestión. Microsoft recomienda un adaptador de red dedicado a la gestión del servidor de Hyper-V.
  • Equipos virtuales. Las configuraciones de red virtual del tipo externo requieren un adaptador de red como mínimo.
  • Almacenamiento IP. Microsoft recomienda que la comunicación del almacenamiento IP cuente con una red dedicada, por lo que se necesita un adaptador, además de dos o más para la compatibilidad con accesos múltiples.
  • Cluster de fallos de Windows. El cluster de fallos de Windows® requiere una red privada.
  • Migración dinámica. Esta nueva funcionalidad de Hyper-V R2 es compatible con la migración de equipos virtuales en funcionamiento entre servidores de Hyper-V. Microsoft recomienda la configuración de un adaptador de red físico dedicado para el tráfico de migración dinámica.
  • Volúmenes compartidos en cluster. Microsoft recomienda una red dedicada para admitir el tráfico de comunicaciones que genera esta nueva funcionalidad de Hyper-V R2.

Las siguientes tablas le ayudarán a escoger el número adecuado de adaptadores físicos.

Tabla 1) Servidores de Hyper-V independientes.

Vista frontal y trasera de DS4243

Tabla 2) Servidores de Hyper-V en cluster.

Vista frontal y trasera de DS4243

Tabla 3) Servidores Hyper-V en cluster utilizando migración dinámica.

Vista frontal y trasera de DS4243

Tabla 4) Servidores de Hyper-V en cluster utilizando migración dinámica y CSV.

Vista frontal y trasera de DS4243

Nuevas funcionalidades de red. Windows Server® 2008 R2 es compatible con varias funcionalidades de red nuevas. NetApp recomienda configurar estas funciones en sus servidores de Hyper-V y aprovecharlas, siempre que sea posible. Tenga en cuenta que algunas de estas funcionalidades, o todas ellas, pueden no ser compatibles con su servidor o su hardware de red. (Ver información en el lateral.)

Práctica n.º 2: selección del iGroup y el tipo de protocolo LUN correctos

Al aprovisionar una LUN de NetApp para utilizarlo con Hyper-V, debe especificar grupos de iniciadores específicos (iGroups) y el tipo de LUN correcto. Una configuración incorrecta puede dificultar la implementación y el rendimiento puede verse afectado.

Grupos de iniciadores. El almacenamiento FCP y iSCSI se debe enmascarar para que el servidor Hyper-V adecuado y los equipos virtuales puedan conectarse a él. Con el almacenamiento de NetApp, el enmascaramiento LUN está gestionado por los iGroups.

  • En el caso de los servidores individuales de Hyper-V, debe crear un iGroup para cada sistema y para cada protocolo (FC y iSCSi) que el sistema utilice para conectarse con el sistema de almacenamiento de NetApp.
  • En el caso de un cluster de servidores de Hyper-V o equipos virtuales, debe crear un iGroup individual para cada protocolo que el cluster de sistemas utilice para conectarse con el sistema de almacenamiento de NetApp.

Es más fácil gestionar los iGroups mediante SnapDrive® de NetApp. SnapDrive elimina en gran medida esta confusión, ya que detecta el sistema operativo que está utilizando y configura automáticamente este ajuste en sus iGroups.

Tipos de LUN. El ajuste del tipo de protocolo LUN determina la distribución en disco de la LUN. Es importante especificar el tipo de LUN correcto para asegurarse de que este se alinee correctamente con el sistema de archivos que contiene. (El siguiente consejo explica este aspecto.) Este problema no se limita al almacenamiento de NetApp. Cualquier plataforma de almacenamiento, proveedor o host puede presentar este problema.

Consejo: El tipo de LUN que especifique depende de su sistema operativo (SO), la versión del SO, el tipo de disco y la versión de Data ONTAP®. Para obtener información completa sobre los tipos de LUN para sistemas operativos diferentes, consulte la Guía de gestión de bloqueo de acceso para su versión de Data ONTAP.

Las siguientes tablas le ayudarán a escoger el tipo de LUN correcto.

Tabla 5) Tipos de LUN para utilizar con Data ONTAP 7.3.1 y posteriores.

Vista frontal y trasera de DS4243

Tabla 6) Tipos de LUN para utilizar con Data ONTAP 7.2.5 a 7.3.0.

Vista frontal y trasera de DS4243

Práctica n.º 3: alineación de discos de equipo virtual

Consejo: este consejo está muy ligado al anterior; si no sigue el primer consejo, la alineación será incorrecta. El problema de la alineación de discos de equipos virtuales no es exclusivo de Hyper-V ni tampoco del almacenamiento de NetApp. Este problema existe en todos los entornos virtuales de cualquier plataforma de almacenamiento.

Se produce porque, de forma predeterminada, muchos sistemas operativos invitados, como Windows 2000 y 2003 y varias distribuciones de Linux®, inician la primera partición primaria en el sector (bloque lógico) 63. Este comportamiento provoca errores de alineación en los sistemas de archivos, ya que la partición no comienza en un límite de bloque. Como resultado, cada vez que el equipo virtual intenta leer un bloque, debe leer dos bloques de la LUN subyacente, por lo que se dobla la carga de I/O.

Vista frontal y trasera de DS4243

Figura 1) Alineación errónea del disco virtual.

Esta situación se vuelve todavía más complicada cuando los equipos virtuales se gestionan como archivos en el sistema de archivos del servidor de Hyper-V, ya que este introduce una nueva capa que debe alinearse correctamente. Por este motivo, seleccionar correctamente el tipo de LUN es muy importante.

  • NetApp recomienda corregir el desplazamiento de todas las plantillas de equipos virtuales, además de los equipos virtuales existentes que no se hayan alineado correctamente y que experimenten un problema de rendimiento de I/O. (Es posible que los equipos virtuales mal alineados con requisitos de I/O bajos no mejoren al corregir el error de alineación.)
  • Al utilizar discos duros virtuales (VHD), NetApp recomienda usar discos duros de tamaño fijo en el entorno virtual de Hyper-V de Microsoft siempre que sea posible, especialmente en entornos de producción, ya que una alineación correcta del sistema de archivos sólo se puede conseguir de forma fiable con los discos duros de tamaño fijo. Evite el uso de discos duros virtuales de expansión dinámica y diferenciación siempre que sea posible, ya que la alineación del sistema de archivos nunca se puede conseguir de forma fiable con este tipo de discos duros virtuales.

La guía de mejores prácticas proporciona los procedimientos completos para identificar y corregir los problemas de alineación.

Práctica n.º 4: uso de volúmenes compartidos en cluster

Los volúmenes compartidos en cluster son una funcionalidad completamente nueva en Hyper-V R2. Si está familiarizado con VMware®, piense que un volumen compartido en cluster es algo parecido a VMFS (aunque existen diferencias significativas).

Un volumen compartido en cluster es un "disco" conectado a la partición principal de Hyper-V y compartido entre varios nodos del servidor de Hyper-V configurados como parte de un cluster de recuperación tras fallos de Windows. Los volúmenes compartidos en cluster solamente se pueden crear en el almacenamiento compartido, como una LUN provisionada en un sistema de almacenamiento de NetApp. Todos los nodos de servidor de Hyper-V en el cluster de recuperación tras fallos deben conectarse al sistema de almacenamiento compartido.

Los volúmenes compartidos en cluster tienen muchas ventajas, entre ellas:

  • Espacio de nombres compartido. Los volúmenes compartidos en cluster no requieren la asignación de una letra de unidad, por lo que se reducen las restricciones y se elimina la necesidad de gestionar GUID y puntos de montaje.
  • Gestión de almacenamiento simplificada. Más equipos virtuales comparten menos LUN.
  • La eficiencia del almacenamiento. Reunir los equipos virtuales en el mismo LUN simplifica la planificación de la capacidad y reduce la cantidad de espacio reservado para el crecimiento futuro, ya que no se divide por equipo virtual.

La redirección de I/O dinámica de los volúmenes compartidos en cluster permite que la I/O de almacenamiento y red pueda redireccionarse en un cluster de recuperación tras fallos, en caso de interrupción de la ruta principal. Las siguientes recomendaciones se aplican específicamente al uso de volúmenes compartidos en cluster con el objetivo de minimizar el impacto del redireccionamiento de I/O:

  • Además de los NIC instalados en el servidor de Hyper-V para gestión, equipos virtuales, almacenamiento IP, etc. (consulte la Práctica n.º 1), NetApp recomienda que se dedique un adaptador de red físico sólo al tráfico de volúmenes compartidos en cluster. El adaptador de red físico debe ser un adaptador Ethernet Gigabit (GbE) como mínimo. Si está utilizando servidores grandes (>16 LCPU, >64 GB), planea utilizar en gran medida volúmenes compartidos en cluster o equilibrar los equipos virtuales de forma dinámica en el cluster mediante SCVMM, o tiene pensado utilizar frecuentemente la migración dinámica, considere la utilización de Ethernet de 10 GB para el tráfico de volúmenes compartidos en cluster.
  • NetApp recomienda la configuración de MPIO en todos los nodos en cluster de Hyper-V para minimizar la posibilidad de redireccionamiento de I/O en volúmenes compartidos en cluster. El redireccionamiento de I/O en volúmenes compartidos en cluster no sustituye los accesos múltiples ni una planificación adecuada del diseño del sistema de almacenamiento y red, aspectos que minimizan los puntos de fallo únicos en los entornos de producción.
  • Cuando detecte un redireccionamiento de I/O en un volumen compartido en cluster, puede que desee migrar de forma dinámica todos los equipos virtuales afectados del nodo de clusters afectado a otro nodo de clusters de Hyper-V, para restablecer el rendimiento óptimo hasta que se diagnostiquen y se reparen los problemas de ruta de I/O.

La guía de mejores prácticas recopila otras mejores prácticas relacionadas específicamente con las copias de seguridad y con el aprovisionamiento de volúmenes compartidos en cluster en los equipos virtuales.

Práctica n.º 5: herramientas y software de almacenamiento de NetApp

NetApp proporciona una gran variedad de herramientas y software de almacenamiento que pueden simplificar las operaciones en un entorno de Hyper-V. Con el lanzamiento de Hyper-V R2, los requisitos mínimos han cambiado en varios elementos de software:

  • Como mínimo, NetApp recomienda el uso de Data ONTAP 7.3 o posterior con los entornos virtuales de Hyper-V.
  • El kit de utilidades de host de Windows modifica la configuración del sistema para que el sistema operativo principal o secundario de Hyper-V funcione con la máxima fiabilidad posible al conectarse al almacenamiento de NetApp. NetApp recomienda instalar el kit de utilidades de host de Windows en todos los servidores de Hyper-V. Windows Server 2008 requiere el kit de utilidades de host de Windows (Host Utilities Kit) 5.1 o posterior. Windows Server 2008 R2 (Hyper-V R2) requiere el kit de utilidades de host de Windows 5.2 o posterior.
  • Las configuraciones de almacenamiento de alta disponibilidad requieren la versión adecuada de Data ONTAP DSM para Windows MPIO. Windows Server 2008 requiere Data ONTAP DSM 3.2R1 o posterior. Windows Server 2008 R2 requiere Data ONTAP DSM 3.3.1 o posterior. Debe establecer la política de cola de menor profundidad al utilizar MPIO. (Esta es la configuración predeterminada.)
  • NetApp recomienda SnapDrive de NetApp en todos los servidores de Hyper-V y SCVMM para permitir la máxima funcionalidad y compatibilidad con las funcionalidades clave. En las instalaciones con Microsoft Windows Server 2008 donde se haya activado la funcionalidad de Hyper-V, y para Microsoft Hyper-V Server 2008, instale SnapDrive de NetApp para Windows 6.0 o posterior. En las instalaciones con Microsoft Windows Server 2008 R2 donde se haya activado la funcionalidad de Hyper-V, y con Microsoft Hyper-V Server 2008 R2, para la compatibilidad con:
    • Funcionalidades existentes (no funcionalidades nuevas de R2), instale NetApp SnapDrive para Windows 6.1P2 o posterior.
    • Funcionalidades nuevas (todas las nuevas funcionalidades de R2), instale SnapDrive de NetApp para Windows 6.2 o posterior.
  • SnapDrive de NetApp para Windows 6.0 o posterior también puede instalarse en sistemas operativos secundarios que incluyan Microsoft Windows Server 2003, Microsoft Windows Server 2008 y Microsoft Windows Server 2008 R2.

Para obtener información actualizada sobre las versiones de software compatibles, consulte la Matriz de interoperabilidad de NetApp. (Debe tener una cuenta NOW™ (NetApp on the Web) para acceder a este recurso.)

Conclusión

Si presta atención a las mejores prácticas que he destacado, podrá evitar la mayoría de las dificultades al configurar su entorno de Hyper-V. Para obtener información detallada sobre estos procedimientos y mucho más, consulte la Guía de mejores prácticas para Hyper-V (Hyper-V best practices guide) y la Guía de implementación de Hyper-V (Hyper-V implementation guide).

 ¿Qué opina de Hyper-V?

Formule preguntas, intercambie ideas y comparta sus opiniones en las comunidades online de NetApp.

Chaffie McKenna
Arquitecto de referencia
NetApp

Chaffie se unió a NetApp a principios de 2008 como parte del equipo de ingeniería de la alianza con Microsoft de NetApp, con sede en Seattle, Washington. Se centra en gran medida en la virtualización, especialmente en Microsoft Hyper-V y SCVMM. Su experiencia en virtualización se remonta a hace 10 años, cuando la virtualización todavía estaba en sus comienzos.

 
En profundidad