共用方式為

Windows Server 2012 Hyper-V Mejores prácticas (Best Practices) (En formato de lista)

  • 發行項

Una entrega mas de la traduccion de articulos mas populares de ASKPFEPLAT, les traemos este post.Para ver el articulo original, haz clic aquí.

Windows Server 2012 provee mejoras mayores al rol de Hyper-V, incluyendo consolidación incrementada de cargas de servidores, replicación de Hyper-V, Actualizaciones de clústeres, utilización de red y el switch extendido de Hyper-V, solo por nombrar unos cuantos! Hyper-V 3.0, como algunos lo llaman, ayuda a las organizaciones a mejorar el uso de sus servidores y a reducir costos.

La siguiente es una lista que desarrolle para Windows Server 2008 R2 SP1 (que se puede encontrar aquí: https://blogs.technet.com/b/askpfeplat/archive/2012/11/19/hyper-v-2008-r2-sp1-best-practices-in-easy-checklist-form.aspx) y fue actualizada con la última distribución. Para aquellos que utilizaron mi lista anterior notaran que hay algunos elementos iguales; eso es porque muchas de las mejores prácticas también aplican para Hyper-V en Server 2012!

Creo que tener una lista puede ser una gran herramienta para usarse no solo cuando se revise una existente de Hyper-V, pero una que puede ser utilizada como parte de planeación para asegurarse que las mejores prácticas sean implementadas desde el principio.

Es importante notar que esta no es una compilación exhaustiva, más bien una agrupación de características/opciones comúnmente utilizadas en los negocios que he tenido el placer de atender.

Un agradecimiento especial a Ted Teknos, Ryan Zoeller y Rob Hefner por su colaboración/sugerencias/correcciones mientras compilaba esta lista!

Sin más que agregar, aquí está la lista actualizada de mejores prácticas de Hyper-V 2012!

Aviso: Como con todas las mejores prácticas, no todas las recomendaciones pueden - o deben- ser aplicadas. Las mejores prácticas son lineamientos generales, no son reglas rígidas que deban de ser seguidas al pie de la letra. Por lo tanto, debes de ser muy cuidadoso al revisar cada elemento y determinar si hace sentido en tu ambiente. Si una (o más) de estas mejores prácticas te aplica, excelente; si no, simplemente ignórala. En otras palabras, depende de ti decidir si las debes de aplicar o no.

GENERAL (HOST):

⎕ Considera utilizar Server Core, o la interfaz mínima de Windows, para reducir el uso de recursos así como la superficie de ataque y la cantidad de reinicios necesarios en tu servidor (debido a que se requieren menos actualizaciones)

⎕ Asegúrate que los hosts estén actualizados con respecto a las actualizaciones recomendadas de Microsoft, para asegurar que los parches críticos –que resuelven asuntos de seguridad o problemas al SO- sean aplicados.

⎕ Asegúrate que todos los parches para Hyper-V y clúster (si aplica) hayan sido aplicados. Revisa los siguientes sitios y compáralos con tu ambiente, ya que no todos los hotfixes son aplicables:

· Un colega en Microsoft, Cristian Edwards, ha publicado un script de powershell que detecta que actualizaciones de Hyper-V y Failover Clustering 2012 te hacen falta basado en la lista actualizada por el grupo de producto! Encuentra el script aquí: https://blogs.technet.com/b/cedward/archive/2013/05/24/validating-hyper-v-2012-and-failover-clustering-2012-hotfixes-and-updates-with-powershell.aspx

· Lista de actualizaciones para Windows Server 2012 Hyper-V: https://social.technet.microsoft.com/wiki/contents/articles/15576.hyper-v-update-list-for-windows-server-2012.aspx

· Lista de actualizaciones de Failover Clúster: https://support.microsoft.com/kb/2784261

⎕ Asegúrate que los hosts tengan la versión mas reciente del BIOS, así como cualquier otro dispositivo de hardware (tal como Synthetic Fibre Channel, Tarjetas de red, etc.), para reducir cualquier problema conocido/soportabilidad.

⎕ El Host debe de ser unido al dominio, a menos que los estándares de seguridad dicten lo contrario. Al hacer esto, es posible centralizar el manejo de políticas de identidad, seguridad y auditoria. Adicionalmente, los hosts deben de ser parte del dominio antes de crear un Clúster de alta disponibilidad de Hyper-V.

· Para obtener mayor información: https://technet.microsoft.com/en-us/library/ee941123(v=WS.10).aspx

⎕ RDP Printer Mapping debe de ser deshabitado en los hosts, para remover cualquier probabilidad de que un driver de impresión pueda causar inestabilidad en el host.

  • Método Preferido: Utiliza Group policy con servidores host en su propia OU.
    • Computer Configuration –> Policies –> Administrative Templates –> Windows Components –> Remote Desktop Services –> Remote Desktop Session Host –> Printer Redirection –> Do not allow client printer redirection –> Configurada como "Enabled”

⎕ No instalar ningún otro role en el host aparte de Hyper-V y Remote Desktop Services (si VDI será utilizado en el host).

  • Cuando el rol de Hyper-V sea instalado, el Sistema operativo (OS) se convierte en la “Partición Padre” (una cuasi-maquina virtual), y la partición de Hypervisor se localiza entre la partición padre y el hardware. Como resultado, no es recomendado instalar roles adicionales (no relacionados con Hyper-V o VDI).

⎕ Las únicas características que deben de ser instaladas en el host son: Failover Clúster Manager (si el host será parte de un clúster), Multipath I/O (si el host será conectado a una SAN iSCSI, Storage Spaces y/o Canal de Fibra), o Remote Desktop Services si VDI es utilizado. (Ver más arriba la explicación por que no es recomendado).

⎕ Software de Anti-virus debe de excluir archivos específicos de Hyper-V utilizando el siguiente artículo: Hyper-V: Antivirus Exclusions for Hyper-V Hosts, resumiendo:

    • Todos los folders que contengan archivos VHD, VHDX, AVHD, VSV e ISO.
    • Directorio default de configuración de máquinas virtuales, si es utilizado (C:\ProgramData\Microsoft\Windows\Hyper-V)
    • Directorio default de snapshot si es utilizado (%systemdrive%\ProgramData\Microsoft\Windows\Hyper-V\Snapshots)
    • Directorio personalizado de configuracion de maquinas virtuales, si aplica.
    • Directorio default de ubicacion de discos duros virtuales.
    • Directorio personalizado de ubicacion de discos duros virtuales.
    • Directorios de Snapshots.
    • Vmms.exe (Nota: Puede ser necesario excluir el proceso)
    • Vmwp.exe (Nota: Puede ser necesario excluir el proceso)
    • Adicionalmente, cuando utilices Clúster Shared Volumes, excluye la ruta CSV "C:\ClusterStorage" y todos los subdirectorios.

  • Para obtener mayor información: https://social.technet.microsoft.com/wiki/contents/articles/2179.hyper-v-anti-virus-exclusions-for-hyper-v-hosts.aspx

⎕ La ruta por default para los discos duros virtuales (VHD/VHDX) debería de ser establecida a un drive que no sea de sistema, debido a que esto puede causar lentitud además de potencialmente dejar al host sin espacio en disco.

⎕ Si decides guardar el estado de la máquina virtual como la acción automática cuando la MV es detenida, la ruta del directorio default no debe de ser un disco de sistema, debido a la creación de un archivo .bin el cual es del mismo tamaño de la memoria reservada para la máquina virtual. Un archivo .vsv también puede ser creado en la misma ubicación que el archivo .bin, incrementando el espacio de cada VM. (La ruta por default es: C:\ProgramData\Microsoft\Windows\Hyper-V.)

⎕ Si estas usando iSCSI: Windows Firewall with Advanced Security, habilita iSCSI Service (TCP-In) para Inbound y iSCSI Service (TCP-Out) para outbound en cada host, para permitir que el trafico iSCSI pase desde el host hasta la SAN y viceversa. Al no habilitar esta regla, la comunicación iSCSI no será exitosa.

Para configurar la regla iSCSI firewall por medio de netsh, puedes utilizar el siguiente comando:

Netsh advfirewall firewall set rule group=”iSCSI Service” new enable=yes

⎕ Ejecuta contadores de desempeno en el host de manera periódica, para asegurar desempeño óptimo.

  • Es recomendado utilizar el contador de desempeño de la aplicación PAL de Codeplex (gratis):
  • Instala PAL en una estación de trabajo y ábrelo, haz clic en la pestaña Threshold.
    • Selecciona "Microsoft Windows Server 2012 Hyper-V" del título Threshold file, y selecciona Export to Perfmon template file. Guarda el archivo XML a una ubicación accesible por el host de Hyper-V.
  • Siguiente, en el host, abre Server Manager –> Tool –> Performance Monitor
  • En Performance Monitor, clic en Data Collector Sets –> User Defined. Clic derech en User Defined y selecciona New –> Data Collector Set. Nombra el collector set "Hyper-V Performance Counter Set" y selecciona Create from a template (Recommended) Clic en siguiente. En la siguiente pantalla, selecciona Browse y ubica el archivo XML que exportaste desde PAL. Una vez hecho esto, esto se mostrara en tus “User Defined Data Collector Sets.”
  • Ejecuta estos contadores en Performance Monitor por 30 minutos a 1 hora (durante horarios de alta utilización) y busca problemas de velocidad de disco, memoria, CPU, etc.

GENERAL (VMs):

⎕ Asegúrate que estés corriendo solo sistemas operativos soportados en tu ambiente. Para una lista completa puedes usar la siguiente dirección: https://blogs.technet.com/b/schadinio/archive/2012/06/26/windows-server-2012-hyper-v-list-of-supported-client-os.aspx

Tarjetas de Red físicas:

⎕ Asegúrate que las tarjetas de red tengan el firmware actual, el cual muchas veces resuelve problemas conocidos.

⎕ Asegúrate que los controladores de las tarjetas de red estén actualizados en el host, esto resolverá problemas conocidos y/o incrementara el desempeño.

⎕ Las tarjetas de red no deben de usar direcciones IP automáticas APIPA (Automatic Private IP Addressing). APIPA no es ruteable y no es registrado en DNS.

⎕ VMQ debería de ser habilitado en adaptadores de red físicos conectados a un switch virtual externo.

⎕ TCP Chimney Offload no es soportado en arreglos de Red basados en software con Server 2012, debido a que TCP Chimney tiene la pila de red vaciada completamente a la tarjeta de red. Si no se está utilizando NIC teaming por software, puedes dejar esta configuración deshabilitada.

  • PARA MOSTRAR EL ESTADO:
    • De una ventana de comandos elevada, escribe lo siguiente:
      • netsh int tcp show global
        • (La respuesta deberia de indicar Chimney Offload State como disabled)
  • PARA DESHABILITAR TCP Chimney Offload:
    • De una ventana de comandos elevada, escribe lo siguiente:
      • netsh int tcp set global chimney=disabled

⎕ Marcos Jumbo (Jumbo frames) deberan de ser configurados a 9000 o 9014 (dependiendo de tu hardware) para redes que soporten CSV, iSCSI y Live Migration. Esto puede incrementar significativamente la velocidad (hasta 6 veces) y utilizara menos ciclos de CPU.

  • Los Jumbo frames deben de ser soportados punta-a-punta por todos los dispositivos de red – NIC, SAN, Switch.
  • Puedes habilitar jumbo frames cuando utilices cables cruzados (para Live Migration y/o Heartbeat), en un clúster de 2 nodos.
  • Para verificar que los jumbo frames han sido configurados exitosamente, ejecuta el siguiente comando desde todos los hosts Hyper-V hacia tu SAN iSCSI:
    • Ping 10.50.2.35 –f –l 8000
      • Este comando mandara un paquete de 8K desde el host hacia la SAN (por ej. 10.50.2.35). Si recibes respuestas, jumbo frames Han sido configuradas correctamente.

clip_image001

⎕ Las tarjetas de red usadas para comunicacion iSCSI deben de tener deshabilitados todos los protocolos de red (en las propiedades de la coneccion de area local) con la excepción de:

  • Protocolos del fabricante (si aplica)
  • Internet Protocol Version 4
  • Internet Protocol Version 6.
  • Deshabilita otros protocolos (no mostrados arriba) ayuda a eliminar el trafico no-iSCSI en estas tarjetas de red.

⎕ No se deben de utilizar teams de tarjetas de red iSCSI. MPIO es el mejor método. Teaming puede ser usado para administración, produccion (tráfico de las máquinas virtuales), CSV Heartbeat y redes de Live migration.

⎕ Si estas utilizando teaming de tarjetas de red para administración, CSV heartbeat y/o Live migration, configura los teams antes de que empieces a asignar redes.

⎕ Si usas un equipo agregado (dependiente del switch) en una máquina virtual, solo tarjetas SR-IOV pueden ser utilizadas...

⎕ Si usas teaming dentro de una máquina virtual, hazlo en este orden:

METODO #1:

  • Abre la configuración de la máquina virtual
    • Dentro de adaptadores de red, selecciona características avanzadas.
    • En el panel derecho, dentro de Network teaming, selecciona la casilla “Enable this network adapter to be part of a team in the guest operating system.”
  • Dentro de la maquina virtual, abre Server Manager. Clic en la vista All Servers, y habilita teaming desde el servidor.

clip_image002

Metodo #2:

  • Utiliza el siguiente comando de powershell (como Administrador) en el host Hyper-V donde la maquina virtual reside:
    • Set-VMNetworkAdapter –VMName contoso-vm1 –AllowTeaming On
      • Este comando habilita la alta disponibilidad en caso de que una de las tarjetas de red en team falle.
      • Dentro de la maquina virtual, abre Server Manager. Clic en la vista All Servers, y habilita teaming desde el servidor.

⎕ Cuando configures switches virtuales, es recomendado quitar la opción Allow management operating system to share this network adapter, para poder crear una red dedicada para que tus máquinas virtuales se comuniquen con otras computadoras en la red física. (Si el adaptador de administración esta compartido, no modifiques ningún protocolo).

Por favor nota: soportamos completamente en incluso recomendamos (en algunos casos) usar el switch virtual para separar redes para administración, live migration, CVS/Heartbeat e incluso iSCSI. Por ejemplo dos tarjetas a 10GB separadas para VLANs y QoS.

⎕ Configuración de red recomendada para clustering:

# Mínimo de redes por host

Host Administrativo

Acceso a red para VMs

CSV/Heartbeat

Live Migration

iSCSI

5

“Management”

“Production”

“CSV/Heartbeat”

“Live Migration”

“iSCSI”

** Redes CSV/Heartbeat & Live Migration Networks pueden usar cables cruzados para conectar los nodos, pero solo si estas creando un clúster de 2 nodos. Cualquier cosa mayor a 2 nodos requiere un switch. **

⎕ Deshabilita la comunicación del clúster para la red iSCSI.

  • Desde Failover Clúster Manager, en Networks, las propiedades de la red iSCSI debe de ser establecida a “Do not allow clúster network communication on this network.” Esto previene el flujo de comunicación interna del clúster así como trafico CSV dentro de la misma red.

⎕ Redes redundantes son recomendadas (múltiples switches) – especialmente para Live Migration y redes iSCSI – ya que provee redundancia y calidad de servicio (QoS).

VLANS:

⎕ Si el arreglo de tarjetas de red está habilitado para redes de administración y/o Live migration, los puertos físicos en el switch al cual es host esta conectado debería de ser configurado como trunk en modo promiscuo. El switch físico puede pasar todo el tráfico al host para ser filtrado.

⎕ Apaga los filtros de VLAN en los arreglos de tarjetas de red. Permite al software de arreglos o al switch de Hyper-V (si está presente) que hagan el filtrado.

Adaptadores de Red Virtuales (NICs):

⎕ Los adaptadores de red antiguos (conocidos como controladores de NICs emuladas) deberán ser utilizadas únicamente para arrancar una VM desde PXE o cuando se instale un sistema operativo que no detecte Hyper-V. Las tarjetas de red sintéticas de Hyper-V (por default) son mucho más eficientes; debido al uso de un Bus dedicado para las VMs para comunicarse entre la tarjeta de red virtual y la física; como resultado, tendrás menos ciclos de CPU así como reducción de transiciones por operación entre el hypervisor y el huésped.

DISCO:

⎕ Discos nuevos deberían de utilizar el formato VHDX. Los discos creados en versiones anteriores deberían de ser convertidos a vhdx, a menos que exista la necesidad de mover el disco a un Hyper-V 2008.

  • El formato VHDX soporta capacidades de hasta 64 TB, protección mejorada contra corrupción de datos durante fallas de electricidad (grabando actualizaciones a las estructuras de datos del VHDX), y una alineación mejorada del disco duro virtual para trabajar mejor en discos con sectores más grandes.

⎕ Los discos utilizados para CSV deberán de ser particionados con NTFS. No puedes usar un disco para CSV que sea formateado con FAT, FAT32, o Resilient File System (ReFS).

⎕ Los discos deberían de ser fijos en un ambiente de producción, para incrementar la tasa de transferencia del disco. Los discos diferenciales y dinámicos no son recomendados para producción, debido a que incrementan el tiempo en lectura/escritura.

⎕ Utiliza los snapshots con cautela. Si no son administrados apropiadamente, pueden causar problemas de espacio en disco, así como sobrecarga física en transferencias I/O. Adicionalmente, si estas hospedando Controladores de domino 2008 R2 o anteriores, aplicar un snapshot anterior puede causar USN rollbacks. Windows Server 2012 ha sido actualizado para proteger más eficazmente a los DCs de esta condición; aun así su uso debería de ser limitado.

⎕ El espacio mínimo recomendado en volúmenes CSV que contienen archivos de configuración de máquinas virtuales, VHD y/o archivos VHDX:

  • 15% de espacio libre, si el tamaño de la partición es menos de 1 TB.
  • 10% de espacio libre, si el tamaño de la partición está dentro de 1 y 5 TB.
  • 5% de espacio libre, si el tamaño de la partición es mayor a 5TB.
  • Para enumerar la información actual del volumen, incluyendo el porcentaje libre, puedes utilizar el siguiente comando de Powershell:
    • Get-ClusterSharedVolume "Cluster Disk 1" | fc *
      • Revisa la salida del campo "PercentageFree"

⎕ No esta soportado crear un arreglo de almacenamiento utilizando LUNs de Fiber Channel o iSCSI.

⎕ El archivo de paginación en un huésped Hyper-V debe de ser manejado por el SO y no configurado manualmente.

 

MEMORIA:

⎕ Utiliza Memoria dinámica (Dynamic Memory) en todas las VMs (a menos que no sea soportado).

  • La memoria dinámica ajusta la cantidad de memoria disponible para la máquina virtual, basada en cambios a la demanda de memoria utilizando un controlador de memoria en forma de globo, el cual permite el uso más eficiente de la memoria.

⎕ EL SO huésped debería de ser configurado con el mínimo de memoria recomendada

CLUSTER:

⎕ Establece la red preferida para comunicacion CSV, para saegurar que la red correcta sea utilizada para este tipo de trafico. (Nota: esto solo necesita ser ejecutado en unos de tus nodos Hyper-V)

  • La metrica más baja en la salida generada por el siguiente comando de Powershell debería de ser utilizado para el tráfico CSV
    • Abre una ventana de Powershell (como “Administrador”)
    • Primero, debes de importar el modulo “FailoverClusters”. Escribe lo siguiente”:
      • Import-Module FailoverClusters
    • Siguiente, solicitaremos una lista de redes utilizadas por el host, asi como la métrica asignada, escribe lo siguiente:
      • Get-ClusterNetwork | ft Name, Metric, AutoMetric, Role
    • Para poder cambiar cual interfaz de red es utilizada para el trafico CSV, utiliza el siguiente comando en Powershell:
        • (Get-ClusterNetwork "CSV Network").Metric=900
          • Esto establecera la red llamaca "CSV Network" a 900

clip_image003

*** Establece la red preferida para Live Migration, para asegurar que las redes para Este trafico son correctas: Set preferred network for Live Migration, to ensure the correct network(s) are used for this traffic:

  • Abre Failover Cluster Manager, Expande el Cluster
  • Despues, clic derecho en Networks y selecciona Live Migration Settings
    • Utiliza las flechas arriba/abajo para listar las redes en el orden del mas preferido (arriba) al menos preferido (abajo)
    • Deselecciona cualquier red que no quieras usar para trafico de Live Migration.
    • Selecciona Apply y después OK.
  • Una vez que hayas hecho este cambio, sera utilizado para todas las VMs en el clúster.

⎕ El tiempo de apagado del clúster (la llave de registro ShutdownTimeoutInMinutes) debería de ser configurada a un número aceptable

  • El default se establece con el siguiente calculo (el cual puede ser muy alto, dependiendo en cuanta memoria fisica sea instalada)
    • (100 / 64) * Memoria Fisica
      • Por ejemplo, un sistema de 96GB tendria un tiempo de 150 minutos (100/64)*96 = 150
  • Una sugerencia es establecer el tiempo de espera a 15, 20 o 30 minutos dependiendo el número de VMs en tu ambiente.
    • Llave de registro: HKLM\Cluster\ShutdownTimeoutInMinutes
      • Agrega lso minutos en valor Decimal.
      • Nota: se necesita un reinicio para que tome efecto.

clip_image004

⎕ Ejecuta la validacion del clusted periódicamente para remediar cualquier incidente

  • Nota: si todas las LUNs son parte del clúster, la prueba de validación se saltara todas las revisiones de disco. Es recomendable configurar una LUN pequeña de prueba y compartirla en todos los nodos, para que una validación complete pueda ser completada.
  • Si necesitas probar una LUN que tenga máquinas virtuales corriendo, el LUN tiene que ser desconectado.
  • Para obtener mayor información: https://technet.microsoft.com/en-us/library/cc732035(WS.10).aspx#BKMK_how_to_run

⎕ Considera habilitar el modo cache de CSV si tienes VMs que sean usadas principalmente para peticiones de lectura, y no mucha labor de escritura. Escenarios como máquinas virtuales para VDI; también pueden ser utilizadas para reducir tormentas de arranque de VMs.

 

REPLICACION DE HYPER-V:

⎕ Ejecuta el Hyper-V Replica Capacity Planner. El planificador de capacidad de replicación de Hyper-V, te permite planear tu estrategia de replicación basado en la carga de trabajo, almacenamiento y características de red y de servidores. Esta herramienta te ayuda a determinar:

  • Cuanto ancho de banda es necesario entre el sitio primario y la replica?
  • Cuanto almacenamiento se requiere entre el sitio primario y la replica?
  • Cual es el impacto de almacenamiento al habilitar puntos de recuperación?

⎕ Actualiza el tráfico de entrada en el firewall para permitir el tráfico en los puertos TCP ‘80’ y/o ‘443’. (En el firewall de Windows, habilita la regla “Hyper-V Replica HTTP Listener (TCP-In)” en cada nodo del clúster.

Para habilitar el tráfico de replicación a través del puerto 80 (HTTP), puedes ejecutar el siguiente comando desde una ventana de comandos elevada:

netsh advfirewall firewall set rule group="Hyper-V Replica HTTP" new enable=yes

Para habilitar tráfico de replicación a través del puerto 443 (HTTPS) puedes ejecutar el siguiente comando desde una ventana de comandos elevada:

netsh advfirewall firewall set rule group="Hyper-V Replica HTTPS" new enable=yes

⎕ Es recomendado habilitar compresión para tráfico de replicación, para reducir requerimientos de ancho de banda.

⎕ Configura los respaldos de Sistemas Operativos huésped con VSS para habilitar que los snapshots de aplicaciones sean consistentes con la réplica de Hyper-V.

⎕ Los servicios de integración deben de ser instalados antes que cualquier máquina virtual primaria, las réplicas pueden utilizar una IP alterna después de un failover.

⎕ Los discos duros virtuales con archivos de paginación deben de ser excluidos de replicación, a menos que el archivo de paginación se encuentre en el disco de sistema operativo.

⎕ Como mínimo, se deben de probar que los failovers funciones correctamente cada mes, para verificar que el failover será exitoso y que las cargas de trabajo de las máquinas virtuales operaran como es esperado.

⎕ La réplica de Hyper-V requiere que el rol “Failover Clustering Hyper-V Replica Broker” sea configurado si es que el servidor primario o la réplica son parte de un clúster.

⎕ La optimización de desempeño y características de la réplica de Hyper-V deberían de ser ajustadas utilizando las llaves de registro mencionadas en el siguiente artículo:

ACTUALIZACION “CLUSTER-AWARE”:

⎕ Pon todos los perfiles de ejecución del servicio “Cluster-Aware Updating (CAU)” en una carpeta compartida que sea accesible desde todos los CAU Update coordinators potenciales. (Perfiles de ejecución son configuraciones que pueden ser guardadas como un archivo XML llamado “Perfil de ejecución actualizable” y ser reutilizado después para ejecuciones de actualización posteriores. https://technet.microsoft.com/en-us/library/jj134224.aspx

ARCHIVOS COMPARTIDOS CON SMB 3.0

⎕ Es requerido tener una infraestructura de Active Directory, para poder otorgar permisos a la cuenta de computadora de los hosts Hyper-V.

⎕ Las configuraciones de Loopback (donde la computadora que está ejecutando Hyper-V es utilizada como el servidor de archivos para almacenamiento de las máquinas virtuales) no son soportadas. Similarmente, ejecutar la carpeta compartida en una máquina virtual es que esta hospedada en alguno de los nodos no es soportado.

DOMAIN CONTROLLERS VIRTUALES (DCs):

⎕ Máquinas virtuales que sean DCs deben de tener un la opción “Shut down the guest operating system" en la configuración de acción automática (en la configuración de la máquina virtual en el host de Hyper-V)

⎕ Importante: Vea “Sea cauteloso cuando utilice snapshots” en la sección de Disco para más informacion acerca de snapshots.

⎕ Importante: Asegúrate que el KB2855336 (liberado en Julio del 2013) haya sido instalado. Nota: esta actualización fue liberada de nuevo en Julio 12 del 2013 para arreglar un problema. Para más información acerca de este problema, ve a la sección Known issue about this update rollup.

  • Los VHDs de los Controladores de dominio que contienen la base de datos de Active Directory deben de tener “write caching” deshabilitado, para reducir la probabilidad de corrupción de AD (si la base de datos esta almacenada en un disco vIDE). Esta actualización resuelve Este problema para todos los sistemas operativos soportados.
  • No es necesario hacer nada a los DCs despues de aplicar la actualizacion. AD envía una petición para ver si puede deshabilitar el cache de disco y si falla, envía IOs con el bit FUA (Force Unit Access), el cual es requerido para garantizar la integridad.
  • Para obtener mayor informacion: https://support.microsoft.com/kb/2853952

SERVICIOS DE INTEGRACION (INTEGRATION SERVICESJ

⎕ Asegura que los servicio de Integracion (IS) hayan sido instalados en todas las VMs. Servicios de integracion incrementan significativamente la interaccion entre la maquina virtual y el host.

⎕ Asegúrate de tener instalada la última versión de servicios de integración – la misma versión que el (los) host(s) – en todos los sistemas operativos huéspedes, puesto que algunas actualizaciones de Microsoft hacen cambios/mejoras al software de integración. (Cuando una nueva versión de los servicios de integración es actualizada en el host, no actualiza los huéspedes automáticamente).

  • Nota: Si los servicios de integración están desactualizados, veras eventos 4010 en el event viewer.
  • Puedes encontrar la versión para cada una de tus VMs en un host ejecutando el siguiente comando de Powershell:
    • Get-VM | ft Name, IntegrationServicesVersion
  • Si quieres un metodo para actualizar los servicios de integracion en VMs, revisa este blog: https://gallery.technet.microsoft.com/scriptcenter/Automated-Install-of-Hyper-edc278ef

OFFLOADED DATA TRANSFER (ODX):

⎕ Si tu SAN soporta ODX (ver este post para mas ayuda; también checa con tu fabricante), deberías considerar habilitar ODX en tus hosts Hyper-V, así como cualquier VM que se conecte directamente a LUNs en la SAN.

  • Para habilitar ODX, abre Powershell (como administrador) y escribe lo siguiente:
    • Set-ItemProperty hklm:\system\currentcontrolset\control\filesystem -Name "FilterSupportedFeaturesMode" –Value 0
    • Asegurate de ejecutar este comando en cada host de Hyper-V que conecta la SAN, así como cualquier VM que se conecte directamente a la SAN.

CONVERSION DE MAQUINAS VIRTUALES:

⎕ Si estas convirtiendo maquinas virtuales de VMWare a Hyper-V, considera usar MVMC (una herramienta gratuita de Microsoft) o VMM.

  • Nota: Si utilizas la herramienta MVMC, puedes usar tambien el Migration Automation Toolkit (MAT), que es gratuiito y puede ayudar a automatizar el prceso de conversión.

Espero sinceramente que encuentres útil este artículo! Si es así, manda este enlace a otros que se puedan beneficiar de el!

Hasta la próxima,

Roger Osborne, Microsoft PFE

(Twitter: RogOsb; LinkedIn: https://www.linkedin.com/in/rogerosborne)

Technorati Tags: Cluster,Best Practices,2012,Hyper-v,Windows Server 2012,Hyper-v virtualization hypervisor server 2012 map,Hyper-V Clustering,Hyper-V Virtualization Hypervisor Server 2012

Comments

  • Anonymous
    January 07, 2014
    Pingback from Windows Server 2012 Hyper-V Best Practices (In Easy Checklist Form) - Ask Premier Field Engineering (PFE) Platforms - Site Home - TechNet Blogs
  • Anonymous
    January 07, 2014
    Pingback from Windows Server 2012 Hyper-V Best Practices (In Easy Checklist Form) - Ask Premier Field Engineering (PFE) Platforms - Site Home - TechNet Blogs
  • Anonymous
    January 08, 2014
    Pingback from Windows Server 2012 Hyper-V Best Practices (In Easy Checklist Form) - Ask Premier Field Engineering (PFE) Platforms - Site Home - TechNet Blogs
  • Anonymous
    January 08, 2014
    Pingback from Windows Server 2012 Hyper-V Best Practices (In Easy Checklist Form) - Ask Premier Field Engineering (PFE) Platforms - Site Home - TechNet Blogs
  • Anonymous
    January 18, 2014
    Gracias! es muy interesante, ayuda mucho a optimizar la instalación de Hyper V, Gracias.
  • Anonymous
    March 10, 2014
    Un aporte genial, bien estructurado y explicado. Felicitaciones.
  • Anonymous
    May 31, 2014
    Roger, muy buen aporte se agradece la explicación de cada parte.

    muchas gracias.
  • Anonymous
    March 02, 2015
    Gracias un buena guia!!
  • Anonymous
    March 05, 2015
    Gracias, Ingeniero. Excelente tu articulo.
  • Anonymous
    November 10, 2015
    Excelente aportación, gracias
  • Anonymous
    December 22, 2015
    Colega, muchas gracias por este excelente aporte que haces, realmente muy valioso.