Antes de poner en marcha la carga de trabajo o migrar desde un hipervisor existente, asegúrese de que el tamaño de la carga de trabajo cumpla con el rendimiento necesario. Esto se puede hacer fácilmente recopilando datos de rendimiento de cada equipo virtual individual que recopila estadísticas de CPU (usado/aprovisionado), memoria (usado/aprovisionado), almacenamiento (aprovisionado/utilizado), rendimiento de red y latencia junto con la agregación de las IOPS de lectura/escritura, rendimiento y tamaño de bloque. Estos parámetros son obligatorios para una implementación correcta y para ajustar el tamaño de la cabina de almacenamiento y los hosts de carga de trabajo.

Nota: Planificar las IOPS y la capacidad al dimensionar el almacenamiento para Hyper-V y las cargas de trabajo asociadas.

Nota: Para máquinas virtuales con mayor consumo de E/S o aquellas que requieren muchos recursos y capacidad, segrega el SO y los discos de datos. Los binarios de aplicación y sistema operativo cambian con poca frecuencia y se acepta la consistencia de los fallos de volumen.

Nota: Utilice el almacenamiento conectado invitado (también conocido como en invitado) para discos de datos de alto rendimiento que el uso de discos duros virtuales. Esto también facilita el proceso de clonación.

Elija la cantidad adecuada de RAM y vCPU para obtener el máximo rendimiento junto con la conexión de varios discos a una única controladora SCSI virtual. El uso de VHDx fijo sigue siendo la opción principal para los discos virtuales para las implementaciones y no hay restricciones para el uso de cualquier tipo de discos virtuales VHDX.

Nota: Evite instalar roles innecesarios en Windows Server que no se utilizarán.

Nota: Elija Gen2 como la generación de máquinas virtuales capaces de cargar VM desde el controlador SCSI y se basa en la arquitectura VMBUS y VSP / VSC para el nivel de arranque, lo que aumenta significativamente el rendimiento general de VM.

Nota: Evite hacer puntos de control frecuentes porque tiene un impacto negativo en el rendimiento de la VM.

Los recursos compartidos de archivos de SMB 3,0 se pueden utilizar como almacenamiento compartido de Hyper-V. ONTAP admite operaciones no disruptivas en recursos compartidos de SMB para Hyper-V. Hyper-V puede utilizar los recursos compartidos de archivos SMB para almacenar archivos de máquina virtual, como configuración, snapshots y archivos de disco duro virtual (VHD). Utilice CIFS SVM de ONTAP dedicado para recursos compartidos basados en SMB3,0 para Hyper-V. Los volúmenes utilizados para almacenar archivos de máquinas virtuales deben crearse con volúmenes de estilo de seguridad NTFS. Se recomienda la conectividad entre los hosts de Hyper-V y la cabina de NetApp en una red de 10GB GbE, si existe alguna disponible. Si se trata de una conectividad de red de 1GB GbE, NetApp recomienda crear un grupo de interfaces que consta de varios puertos 1GB GbE. Conecte cada NIC que sirve SMB multicanal a su subred IP dedicada para que cada subred proporcione una ruta única entre el cliente y el servidor.

Puntos clave

Nota: ODX es compatible y funciona a través de protocolos. Copiar datos entre una unidad de archivos e iSCSI o una LUN conectada a FCP también utiliza ODX.

Nota: Los ajustes de tiempo en los nodos en el clúster deben configurarse en consecuencia. Se debe utilizar el protocolo de tiempo de red (NTP) si el servidor CIFS de NetApp debe participar en el dominio de Windows Active Directory (AD).

Nota: Los valores de MTU grandes deben habilitarse a través del servidor CIFS. Los tamaños de paquetes pequeños pueden provocar una degradación del rendimiento.

Para obtener información detallada sobre las mejores prácticas, consulte "Directrices de puesta en marcha y mejores prácticas para Hyper-V.".

Para obtener más información, consulte "Requisitos de volumen y servidor de SMB para Hyper-V mediante SMB
".

Puntos clave

Nota: Utilice una LUN por volumen, teniendo de esta manera una relación de asignación 1:1 para LUN a CSV.

Para aprovisionar el volumen ISCSI, asegúrese de cumplir los siguientes requisitos previos.

Nota: De forma predeterminada, ONTAP utiliza el mapa selectivo de LUN (SLM) para hacer que el LUN sea accesible solo a través de rutas en el nodo que posee el LUN y su socio de alta disponibilidad (HA).

Una vez creada la LUN, vaya al Administrador de clústeres de conmutación al nodo de respaldo. Para añadir un disco a CSV, el disco debe añadirse al grupo de almacenamiento disponible del clúster (si ya no lo ha añadido) y, a continuación, añada el disco a CSV en el clúster.

Nota: La función CSV está habilitada de forma predeterminada en Failover Clustering.

Adición de un disco al almacenamiento disponible:

Para obtener más información, consulte "Uso de volúmenes compartidos de clúster en un clúster de conmutación al nodo de respaldo".

Para crear una máquina virtual de alta disponibilidad, siga estos pasos:

La función ODX de ONTAP permite realizar copias de los VHDX maestros con solo copiar un archivo VHDX maestro alojado por el sistema de almacenamiento ONTAP. Como una copia habilitada para ODX no coloca datos en el cable de red, el proceso de copia ocurre en el almacenamiento de NetApp y, como resultado, puede ser entre seis y ocho veces más rápido. Las consideraciones generales para un aprovisionamiento rápido incluyen las imágenes maestras sysprepped almacenadas en recursos compartidos de archivos y los procesos de copia regulares iniciados por los equipos host de Hyper-V.

Nota: ONTAP soporta ODX tanto para los protocolos SMB como SAN.

Nota: Para aprovechar los casos de uso para la transferencia de descarga de copia ODX con Hyper-V, el sistema operativo invitado debe admitir ODX, y los discos del sistema operativo invitado deben ser discos SCSI respaldados por almacenamiento (ya sea SMB o SAN) que admita ODX. Los discos IDE del sistema operativo invitado no admiten el paso a través de ODX.

Aunque el número recomendado de equipos virtuales por CSV es subjetivo, muchos factores determinan el número óptimo de equipos virtuales que puede colocarse en cada volumen CSV o SMB. Aunque la mayoría de los administradores solo considera la capacidad, la cantidad de I/O concurrente que se envía al VHDx es uno de los factores más clave para el rendimiento general. La forma más fácil de controlar el rendimiento es regulando el número de máquinas virtuales que se colocan en cada CSV o recurso compartido. Si los patrones de I/O de las máquinas virtuales simultáneas están enviando demasiado tráfico al CSV o al recurso compartido, se generan demasiadas colas de disco y una mayor latencia.

Asegúrese de que la solución tenga un tamaño adecuado de extremo a extremo para evitar cuellos de botella y, cuando se crea un volumen con fines de almacenamiento de máquinas virtuales Hyper-V, la práctica recomendada es crear un volumen no mayor de lo necesario. El ajuste correcto del tamaño de los volúmenes impide la colocación accidental de demasiadas máquinas virtuales en el volumen compartido en clúster y reduce la probabilidad de contención de recursos. Cada volumen compartido de clúster (CSV) admite una máquina virtual o varias máquinas virtuales. La cantidad de equipos virtuales que se colocarán en un volumen compartido en cluster viene determinada por las preferencias de la carga de trabajo y de la empresa, y cómo se utilizarán las funciones de almacenamiento de ONTAP como snapshots y replicación. Colocar varias máquinas virtuales en un volumen compartido en cluster es un buen punto de inicio en la mayoría de los escenarios de puesta en marcha. Ajuste este enfoque para casos prácticos específicos para satisfacer los requisitos de rendimiento y protección de datos.

Dado que los volúmenes y el tamaño de VHDx pueden aumentarse con facilidad, si un equipo virtual requiere capacidad adicional no es necesario ajustar el tamaño de los volúmenes compartidos en cluster más de lo necesario. DiskPart se puede utilizar para ampliar el tamaño CSV o un enfoque más sencillo es crear un nuevo CSV y migrar las máquinas virtuales necesarias al nuevo CSV. Para un rendimiento óptimo, la mejor práctica es aumentar el número de CSV en lugar de aumentar su tamaño como medida provisional.

Uno de los casos de uso más comunes en la condición actual del mercado es la migración. Los clientes pueden usar VMM Fabric u otras herramientas de migración de terceros para migrar máquinas virtuales. Estas herramientas utilizan copias a nivel de host para mover datos desde la plataforma de origen a la plataforma de destino, lo cual puede requerir mucho tiempo en función del número de máquinas virtuales que requieran la migración.

El uso de ONTAP en tales escenarios permite una migración más rápida que utilizar el proceso de migración basado en host. ONTAP también permite migrar rápidamente máquinas virtuales de un hipervisor a otro (ESXi en este caso a Hyper-V). El VMDK de cualquier tamaño puede convertirse a VHDx en segundos en el almacenamiento de NetApp. Esa es nuestra forma de PowerShell: Aprovecha la tecnología FlexClone® de NetApp para la rápida conversión de discos duros de VM. También gestiona la creación y configuración de equipos virtuales de destino y de destino.

Este proceso ayuda a minimizar el tiempo de inactividad y a aumentar la productividad del negocio. También ofrece capacidad de elección y flexibilidad al reducir los costes de licencias, bloqueos y compromisos a un único proveedor. Esto también es beneficioso para las organizaciones que buscan optimizar los costes de licencias de máquinas virtuales y ampliar los presupuestos PARA TECNOLOGÍA.

En el siguiente vídeo se muestra el proceso para migrar equipos virtuales de VMware ESX a Hyper-V.

Para obtener más información sobre la migración mediante FlexClone y PowerShell, consulte la "Script PowerShell para migración".