Prácticas Recomendadas de Rendimiento para Vsphere 6.5

Página 1
Mejores prácticas de rendimiento para

VMware vSphere 6.5
VMware ESXi 6.5
Texto original
vCenter Server 6.5
Performance Best Practices for
Sugiere una traducción mejor
Página 2
Mejores prácticas de rendimiento para
VMware vSphere 6.5
Puede encontrar la documentación técnica más actualizada en el sitio web de VMware en:
http://www.vmware.com/support/
El sitio web de VMware también proporciona las últimas actualizaciones de productos.
Si tiene comentarios sobre esta documentación, envíe sus comentarios a:
docfeedback@vmware.com
© 2007-2015, 2017 VMware, Inc. Todos los derechos reservados. Este producto está protegido por derechos de autor y
leyes de propiedad intelectual. Los productos VMware están cubiertos por una o más patentes enumeradas en
http://www.vmware.com/go/patents.
VMware, el logotipo y el diseño de las "cajas" de VMware, Virtual SMP y VMotion son marcas comerciales registradas o marcas comerciales de
VMware, Inc. en los Estados Unidos y / u otras jurisdicciones. Todas las demás marcas y nombres aquí mencionados pueden ser marcas comerciales.
de sus respectivas empresas.
Revisión: 20170710
VMware, Inc.
3401 Hillview Ave.
Palo Alto, CA 94304
www.vmware.com
2 VMware, Inc.
Página 3
Contenido
Acerca de este libro 9
1 Hardware para usar con

VMware vSphere 11
Valide su hardware 11
Consideraciones de CPU de hardware 11
Consideraciones generales sobre la CPU 11
Virtualización asistida por hardware 11
Virtualización de CPU asistida por hardware (VT-x y AMD-V™ ) 11
Virtualización MMU asistida por hardware (Intel EPT y AMD RVI) 12
Virtualización MMU de E / S asistida por hardware (VT-d y AMD-Vi) 12
Soporte AES-NI 12
Consideraciones de almacenamiento de hardware 13
Consideraciones de hardware en red 16
Configuración de BIOS de hardware 17
Configuración general del BIOS 17
Configuración del BIOS de administración de energía 17
2 ESXi y máquinas virtuales 19

Consideraciones generales de ESXi 19
Consideraciones sobre la CPU ESXi 20
UP vs SMP HALs / Kernels 21
Hyper-Threading 21
Acceso a memoria no uniforme (NUMA) 22
Configuración manual de NUMA 22
Selección del modo Snoop 23
Configuración de ESXi para virtualización asistida por hardware 23
Administración de energía del host en ESXi 24
Opciones de política de energía en ESXi 24
Confirmación de la disponibilidad de tecnologías de administración de energía 25
Elección de una política de energía 25
Consideraciones sobre la memoria de ESXi 26
Sobrecarga de memoria 26
Tamaño de la memoria 27
Técnicas de sobreasignación de memoria 27
Compartir páginas de memoria 28
Optimizaciones de intercambio de memoria 29
Páginas de memoria grande de 2 MB para hipervisor y sistema operativo invitado 30
Virtualización MMU asistida por hardware 31
Consideraciones sobre el almacenamiento de ESXi 32
Caché de lectura de vSphere Flash (vFRC) 32
API de VMware vStorage para integración de arreglos (VAAI) 32
Métodos de acceso a LUN 32
Modos de disco virtual 33
Tipos de disco virtual 33
Alineación de partición 34
SAN Multipathing 35
VMware, Inc. 3
Página 4
Prácticas recomendadas de rendimiento para VMware vSphere 6.5
Asignación de recursos de E / S de almacenamiento 35

Recomendaciones de iSCSI y NFS 36
Recomendaciones de NVMe 36
Recomendaciones de cifrado de máquinas virtuales de vSphere 36
Recomendaciones generales de almacenamiento de ESXi 37
Ejecución de aplicaciones sensibles a la latencia de almacenamiento 37
Consideraciones sobre la red de ESXi 39
Consideraciones generales sobre redes ESXi 39
Control de E / S de red (NetIOC) 39
Configuración de control de E / S de red 39
Opciones de rendimiento avanzadas de control de E / S de red 40
E / S de DirectPath 40
Virtualización de E / S de raíz única (SR-IOV) 41
Modo SplitRx 41
Desactivación del modo SplitRx para todo un host ESXi 41
Habilitación o deshabilitación del modo SplitRx para una NIC virtual individual 41
Recibir escalado lateral (RSS) 42
Coalescencia de interrupciones de red virtual 43
Ejecución de aplicaciones sensibles a la latencia de red 43
Ajuste del rendimiento de todo el host 45
3 Sistemas operativos invitados 47

Consideraciones generales del sistema operativo invitado 47
Medición del rendimiento en máquinas virtuales 48
Consideraciones sobre la CPU del sistema operativo invitado 49
NUMA virtual (vNUMA) 50
Consideraciones sobre el almacenamiento del sistema operativo invitado 52
Consideraciones sobre la conexión en red del sistema operativo invitado 53
Tipos de adaptadores de red virtual 53
Selección de adaptadores de red virtual 54
Características y configuración del adaptador de red virtual 54
4 Gestión de la infraestructura virtual 57

Gestión general de recursos 57
VMware vCenter 58
Consideraciones sobre la base de datos de VMware vCenter 59
Consideraciones sobre almacenamiento y red de base de datos de VMware vCenter 59
Configuración y mantenimiento de la base de datos de VMware vCenter 59
Recomendaciones para proveedores de bases de datos específicos 60
Gestión de VMware vSphere 62
Clientes web de vSphere 62
Consideraciones sobre el rendimiento del back-end de vSphere Web Client 62
Consideraciones sobre el rendimiento de vSphere Web Client Front-End 65
Clientes de vSphere Web Services SDK 66
VMware vMotion y Storage vMotion 67
Recomendaciones de VMware vMotion 67
Recomendaciones de VMware Storage vMotion 68
Recomendaciones de VMware Cross-Host Storage vMotion 68
Programador de recursos distribuidos de VMware (DRS) 70
DRS en general 70
Parámetros de configuración del clúster de DRS 70
Configuración de recursos y tamaño del clúster de DRS 71
Ajuste del rendimiento de DRS 72
Administración de energía distribuida de VMware (DPM) 74
4 VMware, Inc.
Página 5
Contenido
Configuración y modos de funcionamiento de DPM 74

Ajuste del algoritmo DPM 74
Programación de DPM y ejecución proactiva de DPM 75
Uso de DPM con VMware High Availability (HA) 75
Control de E / S de almacenamiento de VMware vSphere 76
Programador de recursos distribuidos de VMware Storage (Storage DRS) 77
Alta disponibilidad de VMware vSphere 78
Alta disponibilidad de VMware en general 78
Protección de componentes de máquinas virtuales (VMCP) 78
Tolerancia a fallos de VMware 79
VMware vSphere Update Manager 81
Update Manager implementado en Windows 81
Update Manager implementado en Linux (con vCenter Server Appliance) 81
Recomendaciones generales de Update Manager 81
Solución del clúster de Update Manager 82
Limitación de ancho de banda de Update Manager 82
VMware Virtual SAN (vSAN) 83
VSAN 83 híbrido frente a todo flash
Selección y diseño de hardware de vSAN 83
Selección y diseño de hardware para vSAN híbrido 83
Selección y diseño de hardware para vSAN todo flash 83
Selección y diseño de hardware para vSAN en general 83
Consideraciones sobre la red vSAN 83
Configuración y uso de vSAN 83
Cifrado de vSAN 84
Volúmenes virtuales de VMware (VVols) 85
Consideraciones de hardware de VVol 85
Rendimiento de la carga de trabajo de VVol 85
Rendimiento de la operación de gestión de VVol 85
Rendimiento de funcionamiento de E / S de VVol 86
Recomendaciones de configuración de VVol 86
Servidor de inicio de sesión único de VMware vCenter 88
Biblioteca de contenido de VMware vSphere 89
Glosario 91
Índice 101
VMware, Inc. 5
Página 6
6 VMware, Inc.
Página 7
Mesas
Tabla 1. Convenciones utilizadas en este manual 10

Tabla 4-1. Opciones de configuración avanzada para vSphere Web Client Back-End 63
VMware, Inc. 7
Página 8
8 VMware, Inc.
Página 9
Sobre este libro
Este libro, Prácticas recomendadas de rendimiento para VMware vSphere 6.5 , proporciona consejos de rendimiento que cubren la mayoría
áreas críticas para el rendimiento de VMware vSphere ® 6.5. No pretende ser una guía completa para la planificación.
y configurar sus implementaciones.
El Capítulo 1, “Hardware para usar con VMware vSphere”, en la página 11 , brinda orientación sobre la selección de hardware
para usar con vSphere.
El Capítulo 2, “ESXi y máquinas virtuales”, en la página 19 , proporciona orientación sobre el software VMware ESXi ™ .
y las máquinas virtuales que se ejecutan en él.
El Capítulo 3, “Sistemas operativos invitados”, en la página 47 , proporciona orientación sobre los sistemas operativos invitados.
ejecutándose en máquinas virtuales de vSphere.
El Capítulo 4, “Gestión de la infraestructura virtual”, en la página 57 , proporciona orientación sobre la infraestructura.

mejores prácticas de gestión.
N OTA Para fines de planificación, recomendamos leer este libro completo antes de comenzar una implementación.
Material en el El capítulo de administración de infraestructura virtual , por ejemplo, podría influir en su hardware
opciones.
Público objetivo
Este libro está dirigido a administradores de sistemas que están planificando una implementación de VMware vSphere 6.5 y
quiere maximizar su rendimiento. El libro asume que el lector ya está familiarizado con VMware vSphere.
conceptos y terminología.
Comentarios sobre el documento

VMware agradece sus sugerencias para mejorar nuestra documentación. Si tiene comentarios, envíe su
retroalimentación a:
docfeedback@vmware.com
Documentación de VMware vSphere

La documentación de VMware vSphere consta de VMware vCenter ® y VMware ESXi combinados
conjunto de documentación.
Puede acceder a las versiones más actuales de la documentación de vSphere en:
http://www.vmware.com/support/pubs
Puede acceder a los documentos de rendimiento y otros documentos técnicos en la página de documentos técnicos de VMware:
http://www.vmware.com/vmtn/resources
VMware, Inc. 9
Página 10
Convenciones
La Tabla 1 ilustra las convenciones tipográficas utilizadas en este manual.
Tabla 1. Convenciones utilizadas en este manual
Estilo Elementos
Azul (solo en línea) Enlaces, referencias cruzadas y direcciones de correo electrónico
Negrita negra Elementos de la interfaz de usuario, como nombres de botones y elementos de menú
Monoespacio Comandos, nombres de archivo, directorios y rutas
Negrita monoespaciada Entrada del usuario
Itálico Títulos de documentos, términos del glosario y énfasis ocasional
<Nombre> Nombres de variables y parámetros

10 VMware, Inc.
Página 11
Hardware para usar con

VMware vSphere 1
Este capítulo proporciona orientación sobre cómo seleccionar y configurar hardware para usar con VMware vSphere.
Valide su hardware
Antes de implementar un sistema, recomendamos lo siguiente:
∎ Verifique que todo el hardware del sistema esté en la lista de compatibilidad de hardware para la versión específica de
El software VMware que ejecutará.
∎ Asegúrese de que su hardware cumpla con la configuración mínima admitida por el software VMware que
estará funcionando.
∎ Pruebe la memoria del sistema durante 72 horas, verificando errores de hardware.
Consideraciones de CPU de hardware

Esta sección proporciona orientación sobre las CPU para su uso con vSphere 6.5.
Consideraciones generales sobre la CPU

∎ Al seleccionar el hardware, es una buena idea considerar la compatibilidad de la CPU para VMware vSphere ®
vMotion ™ (que a su vez afecta a DRS, DPM y otras funciones) y VMware Fault Tolerance. Ver
“VMware vMotion y Storage vMotion” en la página 67, “Programador de recursos distribuidos de VMware (DRS)”
en la página 70 y “VMware Fault Tolerance” en la página 79.
Virtualización asistida por hardware
La mayoría de los procesadores de Intel® y AMD incluyen funciones de hardware para ayudar a la virtualización y mejorar
actuación. Estas características: virtualización de CPU asistida por hardware, virtualización de MMU y MMU de E / S
virtualización — se describen a continuación.
N OTA Para obtener más información sobre las técnicas de virtualización, consulte
http://www.vmware.com/files/pdf/software_hardware_tech_x86_virt.pdf .
Virtualización de CPU asistida por hardware (VT-x y AMD-V ™ )
Asistencia de virtualización de CPU asistida por hardware, llamada VT-x (en procesadores Intel) o AMD-V (en AMD
procesadores), captura automáticamente eventos e instrucciones sensibles, eliminando la sobrecarga de software de
monitoreando todo el código de nivel de supervisión para instrucciones sensibles. De esta forma, VT-x y AMD-V dan la virtual
monitor de máquina (VMM) la opción de utilizar virtualización asistida por hardware (HV) o binario
traducción (BT). Si bien HV supera a BT en la mayoría de las cargas de trabajo, hay algunas cargas en las que lo contrario
es verdad.
N OTA Para que un sistema operativo invitado de 64 bits se ejecute en un procesador Intel, el procesador debe tener
virtualización de CPU asistida por hardware.
VMware, Inc. 11
Pagina 12
Para obtener información sobre cómo configurar la forma en que ESXi usa la virtualización de CPU asistida por hardware, consulte "Configurando
ESXi para virtualización asistida por hardware ” en la página 23 .
Virtualización MMU asistida por hardware (Intel EPT y AMD RVI)
Virtualización MMU asistida por hardware, denominada indexación rápida de virtualización (RVI) o tablas de páginas anidadas
(NPT) en procesadores AMD y tablas de páginas extendidas (EPT) en procesadores Intel, aborda los gastos generales debidos a
virtualización de la unidad de gestión de memoria (MMU) al proporcionar soporte de hardware para virtualizar la MMU.
Sin virtualización MMU asistida por hardware, el sistema operativo invitado mantiene la memoria virtual invitada
a asignaciones de direcciones de memoria física de invitados en tablas de páginas de invitados, mientras que ESXi mantiene "tablas de páginas de sombra"
que mapean directamente la memoria virtual invitada para alojar direcciones de memoria física. Estas tablas de páginas de sombra son
se mantienen para su uso por parte del procesador y se mantienen coherentes con las tablas de páginas de invitados. Esto permite ordinario
referencias de memoria para ejecutar sin sobrecarga adicional, ya que la traducción de hardware mira en el búfer
(TLB) almacenará en caché la memoria virtual del invitado directo para alojar las traducciones de direcciones de memoria física leídas desde el
tablas de páginas de sombra. Sin embargo, se requiere trabajo adicional para mantener las tablas de la página sombra.
La virtualización de MMU asistida por hardware permite un nivel adicional de tablas de páginas que asignan
memoria para alojar direcciones de memoria física, lo que elimina la necesidad de que ESXi mantenga tablas de páginas ocultas.
Esto reduce el consumo de memoria y acelera las cargas de trabajo que hacen que los sistemas operativos invitados
modificar tablas de páginas. Si bien la virtualización MMU asistida por hardware mejora el rendimiento de la mayoría
cargas de trabajo, aumenta el tiempo necesario para reparar una TLB perdida, reduciendo así el rendimiento de
cargas de trabajo que estresan el TLB. Sin embargo, este mayor costo de TLB perdido se puede mitigar configurando el invitado
sistema operativo y aplicaciones para utilizar grandes páginas de memoria, como se describe en "Páginas de memoria grande de 2 MB para
Hipervisor y sistema operativo invitado ” en la página 30.
Para obtener información sobre cómo configurar la forma en que ESXi usa la virtualización MMU asistida por hardware, consulte
“Configuración de ESXi para virtualización asistida por hardware” en la página 23 .
Virtualización MMU de E / S asistida por hardware (VT-d y AMD-Vi)
Virtualización MMU de E / S asistida por hardware, denominada Tecnología de virtualización Intel para E / S dirigida (VT-d) en
Los procesadores Intel y la virtualización de E / S de AMD (AMD-Vi o IOMMU) en los procesadores de AMD, es una memoria de E / S
función de gestión que reasigna las transferencias DMA de E / S y las interrupciones del dispositivo. Esta característica (estrictamente hablando, una
función del chipset, en lugar de la CPU) puede permitir que las máquinas virtuales tengan acceso directo a la E / S de hardware
dispositivos, como tarjetas de red, controladores de almacenamiento (HBA) y GPU.
Para obtener información sobre el uso de la virtualización MMU de E / S asistida por hardware, consulte “DirectPath I / O” en la página 40 y
“Virtualización de E / S de raíz única (SR-IOV)” en la página 41.
Soporte AES-NI
vSphere 6.5 incluye características que funcionan significativamente mejor, generan una carga de CPU significativamente menor, o ambas, en
hardware compatible con AES-NI (Conjunto de instrucciones nuevo estándar de cifrado avanzado de Intel). Por lo mejor
rendimiento con estas características:
∎ Elija procesadores que admitan AES-NI, especialmente algunas versiones de procesador recientes en las que el AES-NI
la implementación se optimiza aún más.
∎ Asegúrese de que la versión de su BIOS sea compatible con AES-NI (en algunos casos, es posible que se requiera una actualización del BIOS para
Soporte AES-NI).
∎ Asegúrese de que AES-NI esté habilitado en BIOS.
En un host que admite AES-NI, ese soporte se expone de forma predeterminada a las máquinas virtuales que se ejecutan en el host.
Esto se puede cambiar si lo desea utilizando Enhanced vMotion Compatibility (EVC) o modificando la máscara de CPU
(consulte el artículo 1993 de VMware KB). Una situación en la que podría ser deseable deshabilitar el paso AES-NI es
Permita la compatibilidad de vMotion desde un host que admita AES-NI a uno que no lo haga.
Para obtener más información sobre las funciones que utilizan AES-NI, consulte "Recomendaciones de cifrado de máquinas virtuales de vSphere"
en la página 36, “Recomendaciones de VMware vMotion” en la página 67 y “VMware Virtual SAN (vSAN)” en
página 83 .
12 VMware, Inc.
Página 13
Capítulo 1 Hardware para usar con VMware vSphere
Consideraciones de almacenamiento de hardware

La configuración del almacenamiento de back-end puede afectar en gran medida el rendimiento. Para obtener más información sobre el almacenamiento
configuración, consulte el documento de almacenamiento de vSphere para VMware vSphere 6.5.
Un rendimiento de almacenamiento inferior al esperado suele ser el resultado de problemas de configuración con
dispositivos de almacenamiento en lugar de algo específico de ESXi.
El rendimiento del almacenamiento es un tema extenso que depende de la carga de trabajo, el hardware, el proveedor, el nivel de RAID, el tamaño de la caché,
tamaño de la raya, etc. Consulte la documentación correspondiente de VMware y del proveedor de almacenamiento.
Muchas cargas de trabajo son muy sensibles a la latencia de las operaciones de E / S. Por tanto, es importante disponer de almacenamiento
dispositivos configurados correctamente. El resto de esta sección enumera las prácticas y configuraciones recomendadas por
VMware para un rendimiento de almacenamiento óptimo.
∎ El rendimiento de VMware Storage vMotion depende en gran medida de la infraestructura de almacenamiento disponible
banda ancha. Por lo tanto, le recomendamos que considere la información en“VMware vMotion y almacenamiento
vMotion ” en la página 67 al planificar una implementación.
∎ Considere la posibilidad de proporcionar dispositivos flash para la capa de infraestructura flash de vSphere. Esta capa se puede utilizar para almacenar
un archivo de intercambio de host (como se describe en “Técnicas de sobreasignación de memoria” en la página 27 ) y para vSphere Flash
Archivos de caché de lectura (vFRC) (como se describe en “vSphere Flash Read Cache (vFRC)” en la página 32) .
La capa de infraestructura flash de vSphere puede estar compuesta por tarjetas flash PCIe o conectadas a SAS o SATA
Unidades SSD, y las tarjetas flash PCIe suelen funcionar mejor que las unidades SSD.
∎ Considere la posibilidad de elegir tarjetas flash PCIe que utilicen el protocolo Non-Volatile Memory Express (NVMe) (consulte
“Recomendaciones de NVMe” en la página 36 para obtener detalles sobre la compatibilidad con NVMe en vSphere 6.5).
∎ Considere la posibilidad de elegir hardware de almacenamiento que admita las API de vStorage para reconocimiento de almacenamiento (VASA),
permitiéndole usar VVols (como se describe en “VMware Virtual Volumes (VVols)” en la página 85) .
Debido a que el rendimiento de VVol varía significativamente entre los proveedores de hardware de almacenamiento, asegúrese de que el
El hardware que elija proporcionará el rendimiento VVol que espera.
∎ Considere elegir hardware de almacenamiento que admita las API de VMware vStorage para la integración de arreglos (VAAI),
permitiendo que algunas operaciones se descarguen al hardware de almacenamiento en lugar de realizarlas en ESXi.
Aunque el grado de mejora depende del hardware de almacenamiento, VAAI puede mejorar el almacenamiento
escalabilidad, puede reducir la latencia de almacenamiento para varios tipos de operaciones de almacenamiento, puede reducir el host ESXi
Uso de CPU para operaciones de almacenamiento y puede reducir el tráfico de la red de almacenamiento.
En SAN, VAAI ofrece las siguientes características:
∎ Gestión de bloqueo escalable (a veces llamado "bloqueo asistido por hardware", "Prueba y configuración atómica" o
ATS) reemplaza el uso de reservas SCSI en volúmenes VMFS al realizar actualizaciones de metadatos.
Esto puede reducir los gastos generales relacionados con el bloqueo, acelerando muchas tareas administrativas y
aumentando el rendimiento de E / S para VMDK delgados. ATS ayuda a mejorar la escalabilidad de muy grandes
implementaciones acelerando las operaciones de aprovisionamiento, como la expansión de discos delgados, la creación de
instantáneas y otras tareas.
∎ Copia extendida (a veces llamada "copia completa", "descarga de copia" o XCOPY) permite que las operaciones de copia
tener lugar completamente en la matriz, en lugar de tener que transferir datos hacia y desde el host. Esto puede
Acelere drásticamente las operaciones que dependen de la clonación, como Storage vMotion, al tiempo que libera
Recursos de CPU y E / S en el host.
∎ La puesta a cero de bloques (a veces denominada "escribir igual") acelera la creación de discos gruesos con puesta a cero ansiosa y
puede mejorar el rendimiento de escritura por primera vez en discos gruesos con puesta a cero diferida y en discos delgados.
∎ La recuperación de espacio muerto (utilizando el comando UNMAP) permite a los hosts transportar al almacenamiento
los bloques ya no están en uso. En un LUN con aprovisionamiento fino en el lado de la matriz, esto puede permitir
hardware de matriz de almacenamiento para reutilizar bloques que ya no se necesitan.
N OTA En este contexto, "thin provisioned" se refiere a los LUN en la matriz de almacenamiento, a diferencia de thin
VMDK aprovisionados, que se describen en “Tipos de discos virtuales” en la página 33 .
VMware, Inc. 13
Página 14
En los dispositivos NAS, VAAI ofrece las siguientes características:
∎ Clonación acelerada por hardware (a veces denominada "Clonación de archivo completo", "Copia completa" o "Descarga de copia")
permite que los discos virtuales sean clonados por el dispositivo NAS. Esto libera recursos en el host y puede acelerar
cargas de trabajo que dependen de la clonación. (Tenga en cuenta que Storage vMotion no utiliza esta función en
Dispositivos NAS.)
∎ El soporte nativo de instantáneas (a veces llamado "Clonación rápida de archivos") puede crear máquinas virtuales vinculadas
clones o instantáneas de máquinas virtuales utilizando discos de instantáneas nativas en lugar de registros de rehacer de VMware. Esta
función, que requiere máquinas virtuales que se ejecutan en hardware virtual versión 9 o posterior, descarga
tareas al dispositivo NAS, reduciendo así el tráfico de E / S y el uso de recursos en los hosts ESXi.
N OTA La creación inicial de instantáneas de máquinas virtuales con discos de instantáneas nativas de NAS es más lenta que
crear instantáneas con los registros de rehacer de VMware. Para reducir este impacto en el rendimiento, recomendamos
evitar cargas pesadas de E / S de escritura en una máquina virtual mientras se usan instantáneas nativas de NAS para crear una
instantánea de esa máquina virtual.
De manera similar, la creación de clones vinculados utilizando instantáneas nativas de NAS puede ser un poco más lenta que la misma
tarea usando rehacer registros.
∎ Reserve Space permite a ESXi preasignar completamente el espacio para un disco virtual en el momento en que el disco virtual está
creado. Por lo tanto, además del aprovisionamiento ligero que admiten los dispositivos NAS que no son VAAI, VAAI NAS
Los dispositivos también admiten el aprovisionamiento grueso de cero diferido y el aprovisionamiento grueso de cero ansioso.
∎ Extended Statistics proporciona visibilidad del uso del espacio en los almacenes de datos NAS. Esto es particularmente útil
para almacenes de datos de aprovisionamiento ligero, ya que permite que vSphere muestre el uso real de
almacenes de datos con exceso de suscripción.
Para obtener más información sobre VAAI, consulte VMware vSphere Storage APIs - Array Integration (VAAI) (aunque
escrito para vSphere 5.1, la mayor parte del contenido se aplica a vSphere 6.5). Para obtener información sobre la configuración del
forma en que ESXi usa VAAI, consulte “Consideraciones sobre el almacenamiento de ESXi” en la página 32 .
∎ Si planea utilizar VMware Virtual SAN (vSAN), considere las ventajas de un vSAN todo flash
implementación versus implementación híbrida (consulte “vSAN híbrido versus todo flash” en la página 83) .
∎ Si planea utilizar el cifrado de máquina virtual (consulte "vSphere Virtual Machine Encryption
Recomendaciones ” en la página 36 ) considere elegir hardware que admita el procesador AES-NI
extensiones del conjunto de instrucciones. Para más información, ver“Soporte AES-NI” en la página 12 .
∎ El diseño de rendimiento para una red de almacenamiento debe tener en cuenta las limitaciones físicas de la red,
no asignaciones lógicas. El uso de VLAN o VPN no proporciona una solución adecuada al problema del enlace.
sobresuscripción en configuraciones compartidas. Las VLAN y otras particiones virtuales de una red proporcionan una
forma de configurar lógicamente una red, pero no cambie las capacidades físicas de enlaces y troncales
entre interruptores.
Sin embargo, las VLAN y las VPN permiten el uso de funciones de calidad de servicio (QoS) de red que, aunque no
eliminar el exceso de suscripción, proporciona una forma de asignar el ancho de banda de forma preferencial o proporcional a
cierto tráfico. Ver también“Control de E / S de red (NetIOC)” en la página 39 para conocer un enfoque diferente de este problema.
∎ Asegúrese de que las velocidades de canal de fibra de extremo a extremo sean constantes para ayudar a evitar problemas de rendimiento. por
más información, consulte el artículo 1006602 de VMware KB.
∎ Configure la profundidad de cola máxima si es necesario para las tarjetas HBA de canal de fibra. Para obtener información adicional, consulte
Artículo 1267 de VMware KB.
∎ Aplicaciones o sistemas que escriben grandes cantidades de datos en el almacenamiento, como la adquisición de datos o
sistemas de registro de transacciones, no deben compartir enlaces Ethernet a un dispositivo de almacenamiento con otras aplicaciones
o sistemas. Estos tipos de aplicaciones funcionan mejor con conexiones dedicadas a dispositivos de almacenamiento.
∎ Para iSCSI y NFS, asegúrese de que la topología de su red no contenga cuellos de botella de Ethernet, donde
varios enlaces se enrutan a través de menos enlaces, lo que puede resultar en una sobre suscripción y caída
paquetes de red. Cada vez que un número de enlaces que transmiten cerca de la capacidad se cambia a un número menor
de enlaces, tal sobresuscripción es una posibilidad.
14 VMware, Inc.
Página 15
La recuperación de estos paquetes de red caídos da como resultado una gran degradación del rendimiento. Además de
tiempo dedicado a determinar que se descartaron datos, la retransmisión utiliza ancho de banda de red que podría
de lo contrario, se utilizará para nuevas transacciones.
∎ Tenga en cuenta que con iSCSI y NFS iniciados por software, el procesamiento del protocolo de red tiene lugar en el
sistema host y, por lo tanto, pueden requerir más recursos de CPU que otras opciones de almacenamiento.
∎ El rendimiento del almacenamiento local se puede mejorar con la caché de escritura diferida. Si su almacenamiento local tiene escritura diferida
caché instalado, asegúrese de que esté habilitado y contenga un módulo de batería funcional. Para más información,
consulte el artículo 1006602 de VMware KB.
∎ Asegúrese de que las tarjetas adaptadoras de almacenamiento estén instaladas en ranuras con suficiente ancho de banda para admitir sus
rendimiento. Tenga cuidado de distinguir entre bus de sonido similar, pero potencialmente incompatible
arquitecturas, incluidas PCI, PCI-X, PCI Express (PCIe) y PCIe 3.0 (también conocido como PCIe Gen3), y asegúrese de tener en cuenta
el número de "carriles" para aquellas arquitecturas que pueden soportar más de un ancho.
Por ejemplo, para suministrar todo su potencial de ancho de banda, HBA de canal de fibra de 32 Gb / s de puerto único
Las tarjetas deberían instalarse en al menos ranuras PCIe Gen2 x8 o PCIe Gen3 x4 (cualquiera de las cuales es capaz
de un máximo neto de 32 Gb / s en cada dirección) y las tarjetas HBA de canal de fibra de 32 Gb / s de doble puerto
deben instalarse en al menos ranuras PCIe Gen3 x8 (que son capaces de un máximo neto de 64 Gb / s en cada
dirección).
Estas tarjetas de alto rendimiento normalmente funcionarán igual de bien en ranuras PCIe más lentas, pero su
el rendimiento podría estar limitado por el ancho de banda disponible de las ranuras. Esto es más relevante para las cargas de trabajo que
hacer un uso intensivo de E / S de gran tamaño de bloque, ya que aquí es donde estas tarjetas tienden a desarrollar su mayor
rendimiento.
VMware, Inc. 15
Página 16
Consideraciones sobre redes de hardware

∎ Antes de emprender cualquier esfuerzo de optimización de la red, debe comprender los aspectos físicos del
red. Los siguientes son solo algunos aspectos del diseño físico que merecen una cuidadosa consideración:
∎ Considere el uso de tarjetas de interfaz de red (NIC) de clase de servidor para obtener el mejor rendimiento.
∎ Asegúrese de que la infraestructura de red entre las NIC de origen y destino no introduzca
cuellos de botella. Por ejemplo, si ambas NIC son de 10 Gb / s, asegúrese de que todos los cables e interruptores
la misma velocidad y que los interruptores no estén configurados a una velocidad menor.
∎ Para obtener el mejor rendimiento de red, recomendamos el uso de adaptadores de red que admitan
siguientes características de hardware:
∎ Descarga de suma de comprobación
∎ Descarga de segmentación de TCP (TSO)
∎ Capacidad para manejar DMA de alta memoria (es decir, direcciones DMA de 64 bits)
∎ Capacidad para manejar múltiples elementos Scatter Gather por trama Tx
∎ Tramas gigantes (JF)
∎ Descarga de recepción grande (LRO)
∎ Cuando se utiliza un protocolo de encapsulación de virtualización, como VXLAN o GENEVE, las NIC deben
admite la descarga de los paquetes encapsulados de ese protocolo.
∎ Recibir escalado lateral (RSS)
∎ Asegúrese de que las tarjetas de red estén instaladas en ranuras con suficiente ancho de banda para admitir su máximo
rendimiento. Como se describe en"Consideraciones de almacenamiento de hardware" en la página 13, tenga cuidado de distinguir
entre arquitecturas de bus que suenan similares, pero potencialmente incompatibles.
Idealmente, los adaptadores de red Ethernet de un solo puerto de 10 Gb / s deben usar PCIe x8 (o superior) o PCI-X 266 y
Los adaptadores de red Ethernet de doble puerto de 10 Gb / s deben utilizar PCIe x16 (o superior). Preferiblemente debería haber
sin "chip puente" (por ejemplo, PCI-X a PCIe o PCIe a PCI-X) en la ruta al dispositivo Ethernet real (incluido
cualquier chip puente integrado en el dispositivo), ya que estos chips pueden reducir el rendimiento.
Idealmente, los adaptadores de red Ethernet de 40 Gb / s deberían utilizar ranuras PCI Gen3 x8 / x16 (o superiores).
Varios adaptadores de red físicos entre un único conmutador virtual (vSwitch) y la red física
constituyen un equipo de NIC. Los equipos de NIC pueden proporcionar conmutación por error pasiva en caso de falla de hardware o de red.
interrupción y, en algunas configuraciones, puede aumentar el rendimiento al distribuir el tráfico entre esos
adaptadores de red físicos.
Cuando se utiliza el equilibrio de carga en varios adaptadores de red físicos conectados a un vSwitch, todos los
Las NIC deben tener la misma velocidad de línea.
Si el conmutador (o conmutadores) de red física al que están conectadas las NIC físicas admite Link
Protocolo de control de agregación (LACP), que configura tanto los conmutadores de red físicos como el vSwitch
utilizar esta función puede aumentar el rendimiento y la disponibilidad.
dieciséis VMware, Inc.
Página 17
Configuración de BIOS de hardware

Es posible que la configuración predeterminada del BIOS de hardware en los servidores no siempre sea la mejor opción para un rendimiento óptimo.
En esta sección se enumeran algunas de las configuraciones del BIOS que quizás desee verificar, particularmente cuando configure por primera vez un nuevo
servidor.
N OTA Debido a la gran cantidad de configuraciones y modelos de servidor diferentes, las opciones de BIOS discutidas
a continuación, puede que no sea completo para su servidor.
Configuración general del BIOS

∎ Asegúrese de estar ejecutando la última versión del BIOS disponible para su sistema.
N OTA Después de actualizar el BIOS, debe volver a visitar la configuración del BIOS en caso de que aparezcan nuevas opciones del BIOS.
disponible o la configuración de opciones anteriores ha cambiado.
∎ Asegúrese de que la BIOS esté configurada para habilitar todos los sockets de procesador ocupados y para habilitar todos los núcleos en cada socket.
∎ Habilite "Turbo Boost" en el BIOS si sus procesadores lo admiten.
∎ Asegúrese de que Hyper-Threading esté habilitado en el BIOS para los procesadores que lo admitan.
∎ Algunos sistemas compatibles con NUMA ofrecen una opción en el BIOS para deshabilitar NUMA habilitando el nodo
entrelazado. En la mayoría de los casos, obtendrá el mejor rendimiento desactivando el entrelazado de nodos (en otros
palabras, dejando NUMA habilitado).
∎ Asegúrese de que todas las funciones de virtualización asistida por hardware (VT-x, AMD-V, EPT, RVI, etc.) estén habilitadas
en el BIOS.
N OTA Después de realizar cambios en estas funciones de virtualización asistida por hardware, algunos sistemas pueden
necesita un apagado completo antes de que los cambios surtan efecto. Ver
http://communities.vmware.com/docs/DOC-8978 para obtener más detalles.
∎ Desactive desde el BIOS cualquier dispositivo que no vaya a utilizar. Esto puede incluir, por ejemplo, innecesarios
puertos serie, USB o de red. Ver“Consideraciones generales de ESXi” en la página 19 para obtener más detalles.
∎ Si el BIOS permite configurar la velocidad de limpieza de la memoria, recomendamos dejarla en el

configuración predeterminada del fabricante.
∎ Si su hardware es compatible con AES-NI (consulte “Soporte AES-NI” en la página 12 ), y su implementación podrá
para hacer uso de la función (ver “Recomendaciones de cifrado de máquinas virtuales de vSphere” en la página 36 ,
“Recomendaciones de VMware vMotion” en la página 67 y “VMware Virtual SAN (vSAN)” en la página 83) :
∎ Asegúrese de que la versión de su BIOS sea compatible con AES-NI (en algunos casos, es posible que se requiera una actualización del BIOS para
Soporte AES-NI)
∎ Asegúrese de que AES-NI esté habilitado en BIOS.
Configuración del BIOS de administración de energía

VMware ESXi incluye una gama completa de capacidades de administración de energía del host en el software que pueden ahorrar energía
cuando un host no se utiliza completamente (ver “Administración de energía del host en ESXi” en la página 24 ). Te recomendamos que
Configure la configuración de su BIOS para permitir que ESXi tenga la mayor flexibilidad para usar (o no usar) la administración de energía
características ofrecidas por su hardware, y que luego haga sus elecciones de administración de energía dentro de ESXi.
∎ Para permitir que ESXi controle las funciones de ahorro de energía de la CPU, configure la administración de energía en el BIOS en "OS
Modo controlado ”o equivalente. Incluso si no tiene la intención de utilizar estas funciones de ahorro de energía, ESXi
proporciona una forma cómoda de gestionarlos.
∎ C1E es un estado gestionado por hardware; cuando ESXi pone la CPU en el estado C1, el hardware de la CPU puede
determinar, en base a sus propios criterios, profundizar el estado a C1E. Disponibilidad del estado de detención C1E normalmente
proporciona una reducción en el consumo de energía con poco o ningún impacto en el rendimiento.
VMware, Inc. 17
Página 18
∎ Los estados C más profundos que C1 / C1E (generalmente C3 y / o C6 en Intel y AMD) son administrados por software y
permitir mayores ahorros de energía. Para obtener el mejor rendimiento por vatio, debe habilitar todos los estados C
en BIOS. Esto le brinda la flexibilidad de utilizar la administración de energía del host vSphere para controlar su uso.
∎ Cuando "Turbo Boost" o "Turbo Core" está habilitado, C1E y estados de parada profunda (por ejemplo, C3 y C6 en
Intel) a veces incluso puede aumentar el rendimiento de ciertas cargas de trabajo con subprocesos ligeros (cargas de trabajo
que dejan algunos hilos de hardware inactivos).
Sin embargo, para unas pocas cargas de trabajo multiproceso que son muy sensibles a la latencia de E / S, los estados C pueden
reducir el rendimiento. En estos casos, puede obtener un mejor rendimiento desactivándolos en el BIOS.
Porque la implementación de C1E y del estado C profundo puede ser diferente para diferentes proveedores de procesadores y
generaciones, sus resultados pueden variar.
18 VMware, Inc.
Página 19
ESXi y máquinas virtuales 2

Este capítulo proporciona orientación sobre el software ESXi en sí y las máquinas virtuales que se ejecutan en él.
Consideraciones generales de ESXi

Esta subsección proporciona orientación con respecto a una serie de consideraciones generales de rendimiento en ESXi.
∎ Planifique su implementación asignando suficientes recursos para todas las máquinas virtuales que ejecutará, así como
los que necesita ESXi.
∎ Asigne a cada máquina virtual solo la cantidad de hardware virtual que requiera esa máquina virtual.
El aprovisionamiento de una máquina virtual con más recursos de los que requiere puede, en algunos casos, reducir la
rendimiento de esa máquina virtual, así como de otras máquinas virtuales que comparten el mismo host.
∎ Desconecte o desactive cualquier dispositivo de hardware físico que no vaya a utilizar. Estos pueden incluir
dispositivos como:
∎ Puertos COM
∎ Puertos LPT
∎ Controladores USB
∎ Unidades de disquete
∎ Unidades ópticas (es decir, unidades de CD o DVD)
∎ Interfaces de red
∎ Controladores de almacenamiento
La desactivación de dispositivos de hardware (normalmente realizada en BIOS) puede liberar recursos de interrupción. Además, algunos
los dispositivos, como los controladores USB, funcionan con un esquema de sondeo que consume recursos adicionales de la CPU. Por último,
algunos dispositivos PCI reservan bloques de memoria, lo que hace que esa memoria no esté disponible para ESXi.
∎ Los dispositivos de hardware virtual no utilizados o innecesarios pueden afectar el rendimiento y deben desactivarse.
Por ejemplo, los sistemas operativos invitados de Windows sondean las unidades ópticas (es decir, unidades de CD o DVD)
frecuentemente. Cuando las máquinas virtuales están configuradas para usar una unidad física y varios invitados operativos
Si los sistemas intentan acceder a esa unidad simultáneamente, el rendimiento podría verse afectado. Esto se puede reducir
configurar las máquinas virtuales para usar imágenes ISO en lugar de unidades físicas, y se puede evitar por completo
desactivando las unidades ópticas en las máquinas virtuales cuando los dispositivos no son necesarios.
∎ ESXi 6.5 presenta la versión 13 de hardware virtual. Al crear máquinas virtuales con este hardware
versión, o actualizar las máquinas virtuales existentes a esta versión, una serie de capacidades adicionales
volverse disponible. Esta versión de hardware no es compatible con versiones de ESXi anteriores a 6.5, sin embargo,
y, por lo tanto, si un clúster de hosts ESXi contendrá algunos hosts que ejecutan versiones anteriores a 6.5 de ESXi, la
las máquinas que se ejecutan en la versión de hardware 13 estarán limitadas a ejecutarse solo en los hosts ESXi 6.5. Esto podría
limitar las opciones de vMotion para la programación de recursos distribuidos (DRS) o la administración de energía distribuida
(DPM).
VMware, Inc. 19
Página 20
Consideraciones sobre la CPU de ESXi

Esta subsección proporciona orientación sobre las consideraciones de la CPU en VMware ESXi.
La virtualización de la CPU agrega cantidades variables de sobrecarga según el porcentaje de la máquina virtual
carga de trabajo que se puede ejecutar en el procesador físico tal cual y el costo de virtualizar el resto del
carga de trabajo:
∎ Para muchas cargas de trabajo, la virtualización de CPU agrega solo una pequeña cantidad de sobrecarga, lo que resulta en
rendimiento esencialmente comparable al nativo.
∎ Muchas cargas de trabajo a las que la virtualización de la CPU agrega sobrecarga no están vinculadas a la CPU, es decir, la mayoría de
su tiempo se gasta esperando eventos externos como la interacción del usuario, la entrada del dispositivo o la recuperación de datos,
en lugar de ejecutar instrucciones. Debido a que los ciclos de CPU no utilizados de otro modo están disponibles para absorber
Sobrecarga de virtualización, estas cargas de trabajo normalmente tendrán un rendimiento similar al nativo, pero potencialmente
con un ligero aumento de latencia.
∎ Para un pequeño porcentaje de cargas de trabajo, para las cuales la virtualización de CPU agrega sobrecarga y cuáles son
Dependiendo de la CPU, puede haber una degradación notable tanto en el rendimiento como en la latencia.
El resto de esta subsección enumera las prácticas y configuraciones recomendadas por VMware para una CPU óptima.
actuación.
∎ En la mayoría de los entornos, ESXi permite niveles significativos de compromiso excesivo de la CPU (es decir, ejecutar más
CPU virtuales en un host que el número total de núcleos de procesador físico en ese host) sin afectar el
Rendimiento de la máquina.
Si un host ESXi se satura la CPU (es decir, las máquinas virtuales y otras cargas en el host demandan
todos los recursos de CPU que tiene el host), es posible que las cargas de trabajo sensibles a la latencia no funcionen bien. En este caso tu
podría querer reducir la carga de la CPU, por ejemplo, apagando algunas máquinas virtuales o migrando
a un host diferente (o permitir que DRS los migre automáticamente).
∎ Es una buena idea monitorear periódicamente el uso de CPU del host. Esto se puede hacer a través de vSphere
Web Client o usando esxtop o resxtop. A continuación, describimos cómo interpretar los datos esxtop:
∎ Si el promedio de carga en la primera línea del panel de la CPU esxtop es igual o mayor que 1 , esto indica
que el sistema está sobrecargado.
∎ El porcentaje de uso de las CPU físicas en la línea PCPU puede ser otra indicación de una posible
condición sobrecargada. En general, el uso del 80% es un límite razonable y el 90% debería ser una advertencia de que
las CPU se están acercando a una condición de sobrecarga. Sin embargo, las organizaciones tendrán diferentes
estándares con respecto al porcentaje de carga deseado.
Para obtener información sobre el uso de esxtop o resxtop, consulte el Apéndice A de VMware Resource Management
Guía .
∎ Configurar una máquina virtual con más CPU virtuales (vCPU) de las que su carga de trabajo puede usar puede causar
uso de recursos ligeramente aumentado, lo que podría afectar al rendimiento en sistemas muy cargados.
Los ejemplos comunes de esto incluyen una carga de trabajo de un solo subproceso que se ejecuta en un virtual de múltiples vCPU
máquina o una carga de trabajo de subprocesos múltiples en una máquina virtual con más CPU virtuales de las que la carga de trabajo puede
utilizar eficazmente.
Incluso si el sistema operativo invitado no usa algunas de sus vCPU, configurar máquinas virtuales con esas
Las vCPU todavía imponen algunos requisitos de recursos pequeños en ESXi que se traducen en un consumo real de CPU
en el anfitrión. Por ejemplo:
∎ Las CPU virtuales no utilizadas aún consumen interrupciones del temporizador en algunos sistemas operativos invitados. (Aunque esto no es
verdadero con los núcleos de "temporizador sin tick", descritos en "Consideraciones sobre la CPU del sistema operativo invitado" en
página 49. )
∎ Mantener una vista de memoria consistente entre múltiples CPU virtuales puede consumir recursos adicionales,
tanto en el sistema operativo invitado como en ESXi. (Aunque la virtualización MMU asistida por hardware
reduce significativamente este costo.)
20 VMware, Inc.
Página 21
Capítulo 2 ESXi y máquinas virtuales
∎ La mayoría de los sistemas operativos invitados ejecutan un bucle inactivo durante los períodos de inactividad. Dentro de este bucle,
la mayoría de estos sistemas operativos invitados se detienen al ejecutar las instrucciones HLT o MWAIT. Algunos mayores
sistemas operativos invitados (incluido Windows 2000 (con ciertos HAL), Solaris 8 y 9, y
MS-DOS), sin embargo, utilizan la espera ocupada dentro de sus bucles inactivos. Esto resulta en el consumo de
recursos que de otro modo podrían estar disponibles para otros usos (otras máquinas virtuales, VMkernel y
pronto).
ESXi detecta automáticamente estos bucles y cancela la programación de la vCPU inactiva. Aunque esto reduce la CPU
sobrecarga, también puede reducir el rendimiento de algunas cargas de trabajo de E / S pesadas. Para adicional
Consulte los artículos 1077 y 2231 de VMware KB.
∎ El programador del sistema operativo invitado puede migrar una carga de trabajo de un solo subproceso entre varios
CPU virtuales, perdiendo así la localidad de la caché.
Estos requisitos de recursos se traducen en un consumo real de CPU en el host.
∎ Algunas cargas de trabajo se pueden dividir fácilmente en varias máquinas virtuales. En algunos casos, por el mismo número
de CPU virtuales, más máquinas virtuales más pequeñas (a veces llamadas "escalado horizontal") proporcionarán mejores
rendimiento que menos máquinas virtuales más grandes (a veces denominado "ampliación"). En otros casos el
lo contrario es cierto, y menos máquinas virtuales más grandes funcionarán mejor. Las variaciones pueden deberse a
número de factores, incluidos los tamaños de los nodos NUMA, la localidad de la memoria caché de la CPU y la implementación de la carga de trabajo
detalles. La mejor elección se puede determinar mediante la experimentación utilizando su carga de trabajo específica en su
medio ambiente.
UP vs SMP HAL / Kernels

Hay dos tipos de capas de abstracción de hardware (HAL) y núcleos: UP y SMP. ARRIBA históricamente se mantuvo
para "monoprocesador", pero ahora debe leerse como "un solo núcleo". SMP históricamente significaba "simétrico
multiprocesador ”, pero ahora debe leerse como multiprocesador.
∎ Aunque algunos sistemas operativos recientes (incluidos Windows Vista, Windows Server 2008 y
Windows 7) utilizan el mismo HAL o kernel para instalaciones UP y SMP, muchos sistemas operativos pueden
configurarse para usar UP HAL / kernel o SMP HAL / kernel. Para obtener el mejor rendimiento en
una máquina virtual de vCPU única que ejecuta un sistema operativo que ofrece HAL / kernels UP y SMP,
configurar el sistema operativo con un UP HAL o kernel.
Las versiones del sistema operativo UP son para máquinas de un solo núcleo. Si se utiliza en una máquina de varios núcleos, un UP
La versión del sistema operativo reconocerá y utilizará solo uno de los núcleos. Las versiones SMP, aunque sean necesarias
para aprovechar al máximo las máquinas de varios núcleos, también se puede utilizar en máquinas de un solo núcleo. Debido a su extra
código de sincronización, sin embargo, las versiones del sistema operativo SMP utilizadas en máquinas de un solo núcleo son ligeramente
más lento que las versiones del sistema operativo UP utilizadas en las mismas máquinas.
N OTA Al cambiar una máquina virtual existente que ejecuta Windows de un núcleo múltiple a un núcleo único,
HAL generalmente sigue siendo SMP. Para un mejor rendimiento, el HAL debe cambiarse manualmente de nuevo a UP.
Hyper-Threading
∎ La tecnología Hyper-Threading (a veces también llamada multiproceso simultáneo o SMT) permite
un solo núcleo de procesador físico para comportarse como dos procesadores lógicos, esencialmente permitiendo dos independientes
subprocesos para ejecutarse simultáneamente. A diferencia de tener el doble de núcleos de procesador, eso puede duplicar aproximadamente
rendimiento: Hyper-Threading puede proporcionar desde un ligero hasta un aumento significativo en el sistema.
rendimiento manteniendo la tubería del procesador más ocupada.
Si el hardware y el BIOS admiten Hyper-Threading, ESXi lo utiliza automáticamente. Por lo mejor

rendimiento, recomendamos que habilite Hyper-Threading, que se puede lograr de la siguiente manera:
un Asegúrese de que su sistema sea compatible con la tecnología Hyper-Threading. No es suficiente que los procesadores
admite Hyper-Threading: el BIOS también debe admitirlo. Consulte la documentación de su sistema para
vea si el BIOS incluye soporte para Hyper-Threading.
segundo
Habilite Hyper-Threading en el BIOS del sistema. Algunos fabricantes etiquetan esta opción como Procesador lógico
mientras que otros lo etiquetan como Habilitar Hyper-threading .
VMware, Inc. 21
Página 22
∎ Cuando ESXi se ejecuta en un sistema con Hyper-Threading habilitado, asigna números de CPU adyacentes a
procesadores lógicos en el mismo núcleo. Por tanto, las CPU 0 y 1 están en el primer núcleo, las CPU 2 y 3 están en el
segundo núcleo, y así sucesivamente.
Los sistemas ESXi administran el tiempo del procesador de manera inteligente para garantizar que la carga se distribuya sin problemas en todos
núcleos físicos en el sistema. Si no hay trabajo para un procesador lógico, se pone en un estado detenido que libera
sus recursos de ejecución y permite que la máquina virtual se ejecute en el otro procesador lógico en el mismo
core para utilizar todos los recursos de ejecución del core.
∎ Tenga cuidado al usar la afinidad de la CPU en sistemas con hiperprocesos. Porque los dos procesadores lógicos
compartir la mayoría de los recursos del procesador, fijando vCPU, ya sea de diferentes máquinas virtuales o de
una sola máquina virtual SMP, a ambos procesadores lógicos en un núcleo (CPU 0 y 1, por ejemplo) podría
causar un rendimiento deficiente.
Acceso a memoria no uniforme (NUMA)

Esta sección describe cómo obtener el mejor rendimiento al ejecutar ESXi en hardware NUMA.
N OTA Una característica diferente, Virtual NUMA (vNUMA), que permite la creación de máquinas virtuales NUMA, es
descrito en “Virtual NUMA (vNUMA)” en la página 50 .
VMware vSphere es compatible con AMD (Opteron, Barcelona, etc.), Intel (Nehalem, Westmere, etc.) e IBM
(X-Architecture) sistemas de acceso a memoria no uniforme (NUMA).
N OTA En algunos sistemas, la configuración del BIOS para el entrelazado de nodos (también conocida como memoria intercalada) determina
si el sistema se comporta como un sistema NUMA o como un sistema de acceso uniforme a memoria (UMA). Si nodo
el entrelazado está deshabilitado, ESXi detecta el sistema como NUMA y aplica optimizaciones de NUMA. Si nodo
el intercalado está habilitado, ESXi no detecta el sistema como NUMA. Para obtener más información, consulte el
documentación.
Puede encontrar más información sobre el uso de sistemas NUMA con ESXi en vSphere Resource Management .
Configuración manual de NUMA
Las políticas de ubicación de memoria y programación NUMA inteligentes y adaptables en ESXi pueden administrar todos los
máquinas de forma transparente, para que los administradores no tengan que lidiar con la complejidad de equilibrar
máquinas entre nodos a mano. Hay controles manuales disponibles para anular este comportamiento predeterminado, sin embargo,
y los administradores avanzados pueden preferir establecer manualmente la ubicación NUMA (a través de la
opción avanzada numa.nodeAffinity ).
De forma predeterminada, la programación de ESXi NUMA y las optimizaciones relacionadas están habilitadas solo en sistemas con un total de en
al menos cuatro núcleos de CPU y con al menos dos núcleos de CPU por nodo NUMA.
En tales sistemas, las máquinas virtuales se pueden dividir en las siguientes dos categorías:
∎ Máquinas virtuales con una cantidad de vCPU igual o menor que la cantidad de núcleos en cada
Nodo NUMA.
Estas máquinas virtuales se asignarán a núcleos, todas dentro de un solo nodo NUMA y serán preferentemente
memoria asignada local a ese nodo NUMA. Esto significa que, sujeto a la disponibilidad de memoria, todos sus
los accesos a la memoria serán locales a ese nodo NUMA, lo que resultará en las latencias de acceso a la memoria más bajas.
∎ Máquinas virtuales con más CPU virtuales que la cantidad de núcleos en cada nodo físico NUMA (llamado "ancho
maquinas virtuales").
22 VMware, Inc.
Página 23
Estas máquinas virtuales se asignarán a dos (o más) nodos NUMA y estarán preferentemente
memoria asignada local a esos nodos NUMA. Debido a que las vCPU en estas amplias máquinas virtuales
a veces necesitan acceder a la memoria fuera de su propio nodo NUMA, pueden experimentar un promedio más alto
latencias de acceso a la memoria que las máquinas virtuales que encajan completamente dentro de un nodo NUMA.
N OTA Este aumento potencial en las latencias promedio de acceso a la memoria se puede mitigar mediante
configurar Virtual NUMA (descrito en “Virtual NUMA (vNUMA)” en la página 50) , lo que permite
sistema operativo invitado para asumir parte de la tarea de gestión de la localidad de memoria.
Debido a esta diferencia, puede haber una ligera ventaja de rendimiento en algunos entornos para
Máquinas configuradas con no más CPU virtuales que la cantidad de núcleos en cada nodo físico NUMA.
Por el contrario, algunas cargas de trabajo con cuello de botella de ancho de banda de memoria pueden beneficiarse del aumento agregado
ancho de banda de memoria disponible cuando una máquina virtual que cabría dentro de un nodo NUMA
dividido en varios nodos NUMA. Esta división se puede lograr limitando la cantidad de vCPU que pueden
colocarse por nodo NUMA mediante la opción maxPerMachineNode (también considere el impacto en vNUMA,
sin embargo, refiriéndose a “Virtual NUMA (vNUMA)” en la página 50) .
En sistemas con hiperprocesos, las máquinas virtuales con un número de vCPU mayor que el número de núcleos en un
El nodo NUMA pero menor que el número de procesadores lógicos en cada nodo NUMA físico podría beneficiarse
de usar procesadores lógicos con memoria local en lugar de núcleos completos con memoria remota. Este comportamiento puede
configurarse para una máquina virtual específica con el indicador numa.vcpu.preferHT.
Selección del modo Snoop
Para mantener la coherencia de los datos de la memoria caché, las operaciones relacionadas con la memoria requieren "espionaje". Fisgonear es un
mecanismo por el cual un procesador prueba el contenido de la caché de los procesadores locales y remotos para determinar
si una copia de los datos solicitados reside en cualquiera de esos cachés.
Hay cuatro modos de inspección (aunque no todos los modos están disponibles en todos los procesadores):
∎ Early Snoop (ES)
∎ Inicio Snoop (HS)
∎ Home snoop con Directory y Opportunistic Snoop Broadcast (HS con DIS + OSB)
∎ Cluster on Die (COD)
El más nuevo, el modo Cluster-on-Die (COD), permite la configuración de tiempo de arranque de los nodos NUMA dentro de un
procesador. Esta función puede dividir lógicamente el procesador en un solo nodo NUMA (que contiene todos los
procesadores) o múltiples nodos NUMA (cada uno de los cuales consta de un conjunto de núcleos de CPU, una parte del
caché de último nivel y un controlador de memoria integrado).
Porque el mejor modo de espionaje para un entorno particular depende tanto de las cargas de trabajo específicas en ese
entorno y el hardware subyacente, recomendamos seguir las instrucciones del fabricante de su servidor
al hacer esta selección.
Para obtener información adicional sobre los modos de inspección, consulte el artículo 2142499 de la base de conocimiento de VMware y
https://software.intel.com/en-us/articles/intel-xeon-processor-e5-2600-v4-product-family-technical-overview .
Configuración de ESXi para virtualización asistida por hardware

ESXi admite la virtualización de CPU y MMU asistida por hardware en procesadores Intel y AMD (como se describe en
“Virtualización asistida por hardware” en la página 11) . Según las funciones del procesador disponibles y el invitado
sistema operativo, ESXi elige entre tres modos de monitor de máquina virtual (VMM):
∎ Software de virtualización de CPU y MMU
∎ Virtualización de CPU de hardware y virtualización de MMU de software
∎ Virtualización de CPU y MMU de hardware
VMware, Inc. 23
Página 24
En la mayoría de los casos, el comportamiento predeterminado proporciona el mejor rendimiento; anularlo a menudo reducirá el rendimiento.
Sin embargo, si lo desea, el comportamiento predeterminado se puede cambiar, como se describe a continuación.
N OTA Cuando la virtualización MMU asistida por hardware está habilitada para una máquina virtual, recomendamos encarecidamente
también, cuando sea posible, configure el sistema operativo invitado y las aplicaciones de esa máquina virtual para
uso de páginas de memoria de 2 MB de gran tamaño.
Cuando se ejecuta en un sistema con la virtualización MMU asistida por hardware habilitada, ESXi intentará usar
páginas de memoria grandes para respaldar las páginas de memoria del invitado, incluso si el sistema operativo y las aplicaciones del invitado
no utilice páginas grandes. Para obtener más información sobre páginas grandes, consulte “Páginas de memoria grande de 2 MB para
Hipervisor y sistema operativo invitado ” en la página 30.
El modo VMM que se usa para una máquina virtual específica se puede cambiar mediante vSphere Web Client. Para hacerlo:
1 Seleccione la máquina virtual a configurar.
2 Haga clic en Editar configuración de la máquina virtual , elija la pestaña Hardware virtual y expanda la opción CPU .
3 En Virtualización de CPU / MMU , use el menú desplegable para seleccionar una de las siguientes opciones:
∎ Automático permite a ESXi determinar la mejor opción. Este es el predeterminado.
∎ El software CPU y MMU deshabilita la virtualización de CPU asistida por hardware (VT-x / AMD-V) y
virtualización MMU asistida por hardware (EPT / RVI).
∎ CPU de hardware, MMU de software permite la virtualización de CPU asistida por hardware (VT-x / AMD-V) pero
desactiva la virtualización MMU asistida por hardware (EPT / RVI).
∎ La CPU de hardware y la MMU permiten la virtualización de CPU asistida por hardware (VT-x / AMD-V) y
virtualización MMU asistida por hardware (EPT / RVI).
N OTA Algunas combinaciones de CPU, sistema operativo invitado y otros factores (por ejemplo, encender
Tolerancia a fallas, descrita en “VMware Fault Tolerance” en la página 79) limite estas opciones. Si la configuración que
seleccionar no está disponible para su combinación particular, la configuración será ignorada y Automático será
usado.
4 Haga clic en el botón Aceptar .
Administración de energía del host en ESXi

La administración de energía del host en ESXi está diseñada para reducir el consumo de energía de los hosts ESXi mientras están
encendido.
N OTA Si bien la administración de energía del host se aplica a los hosts encendidos, una técnica de ahorro de energía muy diferente,
Administración de energía distribuida, intenta apagar los hosts ESXi cuando no son necesarios. Esto se describe
en “VMware Distributed Power Management (DPM)” en la página 74 .
La administración de energía del host y la administración de energía distribuida se pueden usar juntas para obtener la mejor energía
conservación.
Opciones de política de energía en ESXi
ESXi ofrece las siguientes opciones de política de energía:
∎ Alto rendimiento
Esta política de energía maximiza el rendimiento, sin utilizar funciones de administración de energía.
∎ Equilibrado
Esta política de energía (la predeterminada en ESXi 6.5) está diseñada para reducir el consumo de energía del host mientras tiene
poco o ningún impacto en el rendimiento.
∎ Baja potencia
Esta política de energía está diseñada para reducir más agresivamente el consumo de energía del host con el riesgo de reducir
actuación.
24 VMware, Inc.
Página 25
∎ Personalizado
Esta política de energía comienza igual que Balanced , pero permite la modificación de
parámetros.
Para obtener detalles sobre cómo seleccionar una política de energía, busque "Seleccionar una política de administración de energía de la CPU" en vSphere.
Guía de gestión de recursos .
Para obtener detalles sobre la modificación de los parámetros de administración de energía individuales para la política personalizada , busque "Using
Políticas de administración de energía de CPU ”en la guía de administración de recursos de vSphere .
Asegúrese también de que la configuración del BIOS de su servidor esté configurada correctamente, como se describe en “Hardware BIOS
Configuración ” en la página 17 .
Confirmación de la disponibilidad de tecnologías de administración de energía
En algunos casos, el hardware subyacente no tendrá una o más de las tecnologías que ESXi puede usar para ahorrar
poder, o no pondrá esas tecnologías a disposición de ESXi. Esto no causará problemas, pero puede resultar
en el sistema usando más energía de la necesaria.
Si lo desea, puede seguir los siguientes pasos para confirmar que el hardware tiene estas tecnologías y que
están disponibles para ESXi:
1 Con vSphere Web Client, seleccione el host de interés.
2 Seleccione la pestaña Administrar para ese host.
3 En el panel izquierdo dentro de la pestaña Administrar , en Hardware (no Sistema ), seleccione Administración de energía .
4 El campo Tecnología mostrará una lista de las tecnologías disponibles actualmente para ESXi en ese host: ACPI
Estados P, estados C de ACPI o ambos. Para obtener los mejores ahorros de energía, querrá que ambas tecnologías estén disponibles
a ESXi.
Elegir una política de energía
Si bien la política de energía predeterminada en ESX / ESXi 4.1 era Alto rendimiento , en ESXi 5.0 y versiones posteriores la predeterminada es
Equilibrado . Por lo general, esta política de energía no afectará el rendimiento de las cargas de trabajo con uso intensivo de CPU. Raramente,
sin embargo, la política equilibrada podría reducir ligeramente el rendimiento de las cargas de trabajo sensibles a la latencia. En estos
En los casos, seleccionar la política de energía de alto rendimiento proporcionará el rendimiento completo del hardware. Para más
información sobre esto, ver “Ejecución de aplicaciones sensibles a la latencia de red” en la página 43 .
VMware, Inc. 25
Página 26
Consideraciones sobre la memoria de ESXi

Esta subsección proporciona orientación sobre las consideraciones de memoria en ESXi.
Sobrecarga de memoria
La virtualización provoca un aumento en la cantidad de memoria física requerida debido a la memoria adicional necesaria
por ESXi para su propio código y para estructuras de datos. Este requisito de memoria adicional se puede dividir en
dos componentes:
1 Una sobrecarga de espacio de memoria en todo el sistema para VMkernel y varios agentes de host (hostd, vpxa, etc.).
ESXi permite el uso de un archivo de intercambio del sistema para reducir esta sobrecarga de memoria hasta en 1 GB cuando el host está
bajo presión de la memoria. Para utilizar esta función, primero debe crearse manualmente un archivo de intercambio del sistema. Esto puede
se logra mediante la emisión del siguiente comando desde la consola ESXi:
esxcli sched swap system set -d true -n < nombre del almacén de datos >
El archivo de intercambio es de 1 GB y se crea en la raíz del almacén de datos especificado.
N OTA Este archivo de intercambio del sistema es diferente de los archivos de intercambio por máquina virtual, que almacenan memoria
páginas del componente VMX de la sobrecarga de espacio de memoria por máquina virtual.
2 Una sobrecarga de espacio de memoria adicional para cada máquina virtual.
La sobrecarga de espacio de memoria por máquina virtual se puede dividir en las siguientes categorías:
∎ Memoria reservada para el proceso ejecutable de la máquina virtual (VMX).

Esto se usa para las estructuras de datos necesarias para arrancar y dar soporte al invitado (es decir, pilas de subprocesos, texto,
y montón).
∎ Memoria reservada para el monitor de máquina virtual (VMM).
Se utiliza para las estructuras de datos requeridas por el hardware virtual (es decir, TLB, asignaciones de memoria y
Estado de la CPU).
∎ Memoria reservada para varios dispositivos virtuales (es decir, mouse, teclado, SVGA, USB, etc.)
∎ Memoria reservada para otros subsistemas, como el kernel, agentes de gestión, etc.
Las cantidades de memoria reservadas para estos fines dependen de una variedad de factores, incluido el número
de vCPU, la memoria configurada para el sistema operativo invitado, si el sistema operativo invitado es
32 bits o 64 bits, el modo de ejecución VMM y las funciones que están habilitadas para la máquina virtual. por
Para obtener más información sobre estos gastos generales, consulte vSphere Resource Management .
Si bien las necesidades de memoria del dispositivo virtual y VMM están completamente reservadas en el momento en que se
encendido, una función llamada intercambio VMX puede reducir significativamente la memoria VMX por máquina virtual
reserva, lo que permite intercambiar más memoria cuando la memoria del host está comprometida en exceso. Esta
representa una reducción significativa en la memoria de sobrecarga reservada para cada máquina virtual.
La creación de un archivo de intercambio VMX para cada máquina virtual (y por lo tanto la reducción de la memoria del host
reserva para esa máquina virtual) es automática. De forma predeterminada, este archivo se crea en la máquina virtual
directorio de trabajo (ya sea el directorio especificado por workingDir en el archivo .vmx de la máquina virtual, o, si
esta variable no está establecida, en el directorio donde se encuentra el archivo .vmx) pero se puede establecer una ubicación diferente
con sched.swap.vmxSwapDir.
La cantidad de espacio en disco necesaria varía, pero incluso para una máquina virtual grande suele ser inferior a 100 MB
(normalmente menos de 300 MB si la máquina virtual está configurada para gráficos 3D). Creación de archivos de intercambio VMX
se puede desactivar configurando sched.swap.vmxSwapEnabled en FALSE.
N OTA El archivo de intercambio VMX no tiene ninguna relación con el intercambio a la caché del host o al intercambio regular a nivel de host, ambos
de los cuales se describen en “Técnicas de sobreasignación de memoria” en la página 27 .
26 VMware, Inc.
Página 27
Además, ESXi también proporciona optimizaciones, como compartir páginas (consulte "Técnicas de sobreasignación de memoria"
en la página 27 ), para reducir la cantidad de memoria física utilizada en el servidor subyacente. En algunos casos estos
las optimizaciones pueden ahorrar más memoria de la que ocupan los gastos generales.
Tamaño de la memoria
Seleccione con cuidado la cantidad de memoria que asigna a sus máquinas virtuales.
∎ Debe asegurarse de asignar suficiente memoria para contener el conjunto de aplicaciones de trabajo que ejecutará en el
máquina virtual, minimizando así la paliza. Debido a que la paliza puede afectar drásticamente el rendimiento,
Es muy importante no subasignar la memoria.
∎ Por otro lado, aunque el impacto en el rendimiento de la asignación excesiva de memoria es mucho menor que
subasignarlo, también debería evitar una sobreasignación sustancial.
La memoria asignada a una máquina virtual más allá de la cantidad necesaria para mantener el conjunto de trabajo normalmente
ser utilizado por el sistema operativo invitado para las cachés del sistema de archivos. Si los recursos de memoria en el nivel de host
bajo, ESXi generalmente puede utilizar la expansión de memoria (descrita en "Técnicas de sobreasignación de memoria" en
página 27) para recuperar la parte de memoria utilizada para estos cachés.
Pero la asignación excesiva de memoria también aumenta innecesariamente la sobrecarga de memoria de la máquina virtual. Mientras
ESXi normalmente puede reclamar la memoria sobreasignada, no puede reclamar la sobrecarga asociada con esto
memoria sobreasignada, consumiendo así memoria que de otro modo podría utilizarse para admitir más
máquinas.
Técnicas de sobreasignación de memoria

∎ ESXi utiliza cinco mecanismos de administración de memoria: uso compartido de páginas, aumento de volumen, compresión de memoria,
intercambio a caché del host e intercambio regular, para reducir dinámicamente la cantidad de
memoria requerida para cada máquina virtual.
∎ Uso compartido de páginas: ESXi puede utilizar una técnica patentada para compartir de forma transparente páginas de memoria entre
máquinas virtuales, eliminando así copias redundantes de páginas de memoria. Si bien las páginas son compartidas por
predeterminado dentro de las máquinas virtuales, a partir de vSphere 6.0 las páginas ya no se comparten de forma predeterminada entre
maquinas virtuales.
En la mayoría de los entornos, este cambio debería tener poco efecto. Para obtener detalles sobre los entornos en los que
podría afectar el uso de la memoria y las instrucciones sobre cómo habilitar el comportamiento predeterminado anterior si
deseado, consulte “Compartir páginas de memoria” en la página 28 .
∎ Globo: si la memoria del host comienza a agotarse y el uso de la memoria de la máquina virtual
se acerca a su objetivo de memoria, ESXi utilizará la expansión para reducir la memoria de esa máquina virtual
demandas. Usando un módulo vmmemctl proporcionado por VMware instalado en el sistema operativo invitado como
parte de la suite VMware Tools, ESXi puede hacer que el sistema operativo invitado ceda la memoria
páginas que considera menos valiosas. Los globos proporcionan un rendimiento que se asemeja mucho al de un nativo.
sistema con limitaciones de memoria similares. Para utilizar la función de globo, el sistema operativo invitado debe estar
configurado con suficiente espacio de intercambio.
∎ Compresión de memoria : si el uso de memoria de la máquina virtual se acerca al nivel en el que

Se requerirá el intercambio a nivel de host, ESXi utilizará compresión de memoria para reducir la cantidad de
páginas de memoria que deberá intercambiar. Debido a que la latencia de descompresión es mucho menor que la
latencia de intercambio, la compresión de las páginas de memoria tiene un impacto significativamente menor en el rendimiento que
intercambiando esas páginas.
∎ Swap to Host Cache: Si la compresión de memoria no mantiene bajo el uso de memoria de la máquina virtual
suficiente, ESXi luego reclamará memoria por la fuerza mediante el intercambio de nivel de host a una caché de host (si se ha
configurado). Swap to host cache es una función que permite a los usuarios configurar una caché de intercambio especial
en almacenamiento SSD. En la mayoría de los casos, este caché de host (que está en SSD) será mucho más rápido que el intercambio normal
archivos (normalmente en el almacenamiento del disco duro), lo que reduce significativamente la latencia de acceso. Así, aunque algunos de
las páginas que ESXi intercambia pueden estar activas, el intercambio a la caché del host tiene un impacto de rendimiento mucho menor
que el intercambio regular a nivel de host.
VMware, Inc. 27
Página 28
∎ Intercambio regular a nivel de host: si la caché de host se llena o si no se ha

configurado, ESXi recuperará la memoria de la máquina virtual intercambiando páginas a un
archivo de intercambio regular. Al igual que el intercambio a la caché del host, algunas de las páginas que intercambia ESXi pueden estar activas. diferente a
cambiar a la caché del host, sin embargo, este mecanismo puede hacer que el rendimiento de la máquina virtual se degrade
significativamente debido a su alta latencia de acceso. (Tenga en cuenta que este intercambio es distinto del intercambio
que puede ocurrir dentro de la máquina virtual bajo el control del sistema operativo invitado).
Para obtener más información sobre la administración de memoria, consulte Comprensión de la administración de recursos de memoria en
VMware vSphere 5.0 (aunque este documento trata específicamente de vSphere 5.0, la mayoría de los conceptos son
aplicable a vSphere 6.5) y sobrecompromiso de memoria en el servidor ESX .
∎ Mientras que ESXi utiliza el uso compartido de páginas, el aumento de volumen, la compresión de memoria y el intercambio de caché del host para permitir
un compromiso excesivo de memoria, generalmente con poco o ningún impacto en el rendimiento, debe evitar
sobreasignar memoria hasta el punto de que se utilice el intercambio regular a nivel de host para intercambiar la memoria activa
páginas.
Si sospecha que el compromiso excesivo de la memoria está empezando a afectar el rendimiento de una máquina virtual
puede seguir los siguientes pasos:
N OTA El punto en el que el compromiso excesivo de la memoria comienza a afectar el rendimiento de una carga de trabajo depende
fuertemente en la carga de trabajo. Las áreas que describimos en esta sección serán relevantes para la mayoría de las cargas de trabajo. por
Sin embargo, el rendimiento de algunas de esas cargas de trabajo se verá notablemente afectado antes que en otras.
un En vSphere Web Client, seleccione la máquina virtual en cuestión, seleccione Supervisar > Rendimiento >
Avanzado , en el menú desplegable de la esquina superior derecha, seleccione Memoria , luego observe el valor de Globo
memoria (promedio) .
La ausencia de globo sugiere que ESXi no está bajo una gran presión de memoria y, por lo tanto, la memoria
el compromiso excesivo no afecta el rendimiento de esa máquina virtual.
N OTA Este indicador solo es significativo si el controlador de globo está instalado en la máquina virtual y
no se le impide trabajar.
N OTA Un poco de hinchazón es bastante normal y no indica un problema.
segundo
En vSphere Web Client, seleccione la máquina virtual en cuestión, seleccione Supervisar > Rendimiento >
Avanzado , en el menú desplegable de la esquina superior derecha, seleccione Memoria , luego compare los valores de
Memoria consumida y memoria activa . Si el consumo es superior al activo, esto sugiere que el
el invitado está obteniendo actualmente toda la memoria que necesita para un mejor rendimiento.
C En vSphere Web Client, seleccione la máquina virtual en cuestión, seleccione Monitor > Utilization ,
expanda el panel Guest Memory , luego observe los valores de Swapped y Compressed . Intercambio
y la compresión a nivel de host indican una presión de memoria más significativa.
re Verifique la actividad de intercambio del sistema operativo invitado dentro de esa máquina virtual.
Esto puede indicar que la expansión puede estar empezando a afectar el rendimiento, aunque la actividad de intercambio puede
también estar relacionado con otros problemas completamente dentro del sistema operativo invitado (o puede ser una indicación de que
el tamaño de la memoria del invitado es simplemente demasiado pequeño).
Compartir página de memoria

A partir de vSphere 6.0 (e incluido en parches o actualizaciones de algunas versiones anteriores), el uso compartido de páginas es
habilitado de forma predeterminada dentro de las máquinas virtuales ("uso compartido entre máquinas virtuales "), pero está habilitado entre máquinas virtuales
("Uso compartido entre VM") solo cuando esas máquinas virtuales tienen el mismo valor de "sal" (descrito a continuación). Esta
Se realizó un cambio para garantizar la máxima seguridad entre las máquinas virtuales.
Debido a la prevalencia de páginas de memoria grande de 2 MB (consulte “Páginas de memoria grande de 2 MB para hipervisor y
Sistema operativo invitado ” en la página 30) , que no se comparten incluso cuando el uso compartido de páginas está habilitado, este cambio
probablemente tendrá solo un efecto pequeño, si lo hay, en el uso de la memoria en la mayoría de las implementaciones.
Sin embargo, en entornos que hacen un uso extensivo de páginas de memoria pequeñas (como muchas implementaciones de VDI),
compartir páginas entre máquinas virtuales puede proporcionar una reducción considerable en el uso de memoria.
28 VMware, Inc.
Página 29
De forma predeterminada, el valor de sal para una máquina virtual específica es el vc.uuid de esa máquina virtual, que siempre es
único entre las máquinas virtuales en un solo host ESXi, lo que evita el uso compartido de páginas entre VM.
Puede habilitar el uso compartido de páginas entre VM mediante uno de estos métodos:
∎ Para habilitar el uso compartido de páginas entre VM entre todas las máquinas virtuales en un host ESXi, establezca la configuración del host
opción Mem.ShareForceSalting a 0. Esto duplica el comportamiento predeterminado de versiones anteriores de
vSphere.
∎ Especifique manualmente un valor de sal en los archivos .vmx de las máquinas virtuales con la opción de configuración
sched.mem.pshare.salt. Con esta opción, puede crear grupos de máquinas virtuales que tengan el mismo
salt value y, por lo tanto, puede compartir páginas de memoria con otras máquinas virtuales en ese grupo.
Si lo desea, puede configurar el mismo valor de sal para cada máquina virtual en su entorno,
creando de forma eficaz un grupo de páginas compartidas (duplicando así el comportamiento predeterminado de versiones anteriores)
de vSphere).
Para obtener más información sobre el uso compartido de páginas y los problemas de seguridad relevantes, consulte los artículos de la base de conocimiento de VMware 2080735 y
2097593.
Optimizaciones de intercambio de memoria

Como se describe en "Técnicas de sobreasignación de memoria", arriba, ESXi admite una cantidad limitada de memoria
compromiso excesivo sin intercambio de nivel de host. Si el compromiso excesivo es tan grande que el otro recuerdo
Las técnicas de recuperación no son suficientes; sin embargo, ESXi utiliza el intercambio de memoria a nivel de host, con un potencial
impacto significativo en el rendimiento de la máquina virtual.
Esta subsección describe formas de evitar o reducir el intercambio a nivel de host y presenta técnicas para reducir su
impacto en el rendimiento cuando es inevitable.
∎ Debido a que ESXi utiliza el uso compartido de páginas, la ampliación y la compresión de memoria para reducir la necesidad de
intercambio de memoria, no desactive estas técnicas.
∎ Si elige comprometer en exceso la memoria con ESXi, asegúrese de tener suficiente espacio de intercambio en su ESXi
sistema. En el momento en que una máquina virtual se enciende por primera vez, ESXi crea un archivo de intercambio para esa máquina virtual
igual en tamaño a la diferencia entre el tamaño de memoria configurado de la máquina virtual y su memoria
reserva. Por lo tanto, el espacio disponible en disco debe ser al menos así de grande (más el espacio requerido para VMX
intercambiar, como se describe en “Sobrecarga de memoria” en la página 26) .
∎ Opcionalmente, puede configurar un caché de host especial en un SSD (si hay uno instalado) para que se utilice para el intercambio de
función de caché de host. Esta caché de intercambio será compartida por todas las máquinas virtuales que se ejecutan en el host y
El intercambio a nivel de host de sus páginas más activas se beneficiará de la baja latencia de SSD. Esto permite
cantidad relativamente pequeña de almacenamiento SSD para aumentar potencialmente significativamente el rendimiento
N OTA Usar swap to host cache y colocar el archivo swap normal en SSD (como se describe a continuación) son dos
diferentes enfoques para mejorar el rendimiento del intercambio de host. Swap to host cache hace el mejor uso
de espacio SSD potencialmente limitado mientras que también se optimiza para los grandes tamaños de bloques en los que algunos SSD
funciona mejor.
∎ Incluso si un host comprometido en exceso usa swap para albergar caché, todavía necesita crear archivos de intercambio regulares. Cambiar a
caché del host, sin embargo, hace mucho menos importante la velocidad del almacenamiento en el que los archivos de intercambio regulares
están situados.
Si un host no usa swap to host cache, y la memoria está comprometida en exceso hasta el punto de golpear, colocar
la máquina virtual intercambia archivos con baja latencia, los sistemas de almacenamiento de alto ancho de banda darán como resultado el menor
impacto en el rendimiento del intercambio.
∎ La mejor opción suele ser SSD local.
N OTA Colocar el archivo de intercambio normal en SSD y usar el caché de intercambio para alojar en SSD (como se describe arriba)
Hay dos enfoques diferentes para mejorar el rendimiento del intercambio de host. Porque es inusual tener
suficiente espacio SSD para todas las necesidades de archivos de intercambio de un host, recomendamos usar SSD local para intercambiar a host
cache.
VMware, Inc. 29
Página 30
∎ Si el host no tiene SSD local, la segunda opción sería SSD remoto. Esto todavía proporcionaría
las bajas latencias de SSD, aunque con la latencia adicional del acceso remoto.
∎ Si no puede usar el almacenamiento SSD, coloque el archivo de intercambio normal en el almacenamiento más rápido disponible. Esto podría
ser una matriz SAN Fibre Channel o un disco local rápido.
∎ Colocar archivos de intercambio en el almacenamiento local (ya sea SSD o disco duro) podría reducir potencialmente vMotion
actuación. Esto se debe a que si una máquina virtual tiene páginas de memoria en un archivo de intercambio local, deben
intercambiarse en la memoria antes de que pueda continuar una operación de vMotion en esa máquina virtual.
∎ Independientemente del tipo de almacenamiento o la ubicación que se utilice para el archivo de intercambio normal, para obtener el mejor rendimiento y
para evitar la posibilidad de quedarse sin espacio, los archivos de intercambio no deben colocarse en thin-provisioned
almacenamiento.
La ubicación del archivo de intercambio habitual para una máquina virtual específica se puede configurar en vSphere Web Client
(haga clic con el botón derecho en la máquina virtual, seleccione Editar configuración , elija la pestaña Opciones de VM , expanda Avanzado y
seleccione una ubicación de archivo de intercambio ). Si esta opción no está configurada, el archivo de intercambio se creará en la máquina virtual.
directorio de trabajo: el directorio especificado por workingDir en el archivo .vmx de la máquina virtual, o, si
esta variable no está configurada, en el directorio donde se encuentra el archivo .vmx. Este último es el comportamiento predeterminado.
∎ El intercambio de memoria a nivel de host, en muchos casos, se puede reducir para una máquina virtual específica reservando
memoria para esa máquina virtual al menos igual en tamaño al conjunto de trabajo activo de la máquina. Nivel de host
El intercambio de memoria se puede eliminar para una máquina virtual específica reservando memoria del mismo tamaño para
la memoria completa de la máquina virtual.
N OTA Cuando se aplica a una máquina virtual en ejecución, el efecto de estas reservas de memoria puede aparecer
sólo gradualmente. Para ver de inmediato el efecto completo, debe apagar y encender la máquina virtual.
Sin embargo, tenga en cuenta que la configuración de reservas de recursos reducirá la cantidad de máquinas virtuales
que se puede ejecutar en un sistema. Esto se debe a que ESXi mantendrá disponible suficiente memoria de host para cumplir con todos
reservas (tanto para máquinas virtuales como para gastos generales) y no encenderá una máquina virtual si hace
por lo que reduciría la memoria disponible a menos de la cantidad reservada.
N OTA La reserva de memoria es un límite inferior garantizado en la cantidad de memoria física ESXi
reservas para la máquina virtual. Se puede configurar a través de vSphere Web Client en la configuración
ventana para cada máquina virtual (haga clic derecho en la máquina virtual, seleccione Editar configuración , elija el virtual
Pestaña Hardware , expanda Memoria , luego configure la reserva deseada).
Páginas de memoria grande de 2 MB para hipervisor y sistema operativo invitado

Además de las páginas de memoria habituales de 4 KB, ESXi también proporciona páginas de memoria de 2 MB (comúnmente conocidas como
"Páginas grandes"). (Tenga en cuenta que, aunque algunas CPU admiten páginas de memoria de 1 GB, en este libro el término "grandes
páginas ”se utiliza solo para hacer referencia a páginas de 2 MB).
ESXi asigna estas páginas de memoria de máquina de 2 MB a los sistemas operativos invitados siempre que sea posible; en sistemas
con la virtualización MMU asistida por hardware, ESXi hace esto incluso si el sistema operativo invitado no solicita
ellos (aunque el beneficio completo de las páginas grandes se obtiene solo cuando el sistema operativo invitado y las aplicaciones usan
ellos también). El uso de páginas grandes puede reducir significativamente las pérdidas de TLB, mejorando el rendimiento de la mayoría
cargas de trabajo, especialmente aquellas con grandes conjuntos de trabajo de memoria activa. Además, las páginas grandes pueden
reducir la sobrecarga de espacio de memoria por máquina virtual.
Si un sistema operativo o una aplicación pueden beneficiarse de páginas grandes en un sistema nativo, ese sistema operativo
o la aplicación potencialmente puede lograr una mejora de rendimiento similar en una máquina virtual respaldada con
2 MB de páginas de memoria de la máquina. Consulte la documentación de su sistema operativo y aplicación para
Determine cómo configurar cada uno de ellos para utilizar páginas de memoria grandes.
El uso de páginas grandes también puede cambiar el comportamiento de compartir páginas. Si bien ESXi normalmente usa el uso compartido de páginas independientemente
de demandas de memoria (aunque vea “Compartir páginas de memoria” en la página 28 para leer cómo cambió este comportamiento en
vSphere 6.0), ESXi no comparte páginas grandes. Por lo tanto, con páginas grandes, es posible que no se comparta la página hasta
el compromiso excesivo de la memoria es lo suficientemente alto como para requerir que las páginas grandes se dividan en páginas pequeñas. Para más
Para obtener más información, consulte los artículos de la base de conocimiento de VMware 1021095 y 1021896.
30 VMware, Inc.
Página 31
Virtualización MMU asistida por hardware

La virtualización MMU asistida por hardware es una técnica que virtualiza la unidad de administración de memoria de la CPU
(MMU). Para obtener una descripción de la virtualización MMU asistida por hardware, consulte"MMU asistida por hardware
Virtualización (Intel EPT y AMD RVI) ” en la página 12 ; para obtener información sobre cómo configurar la forma en que ESXi usa
virtualización MMU asistida por hardware, consulte "Configuración de ESXi para virtualización asistida por hardware" en
página 23 .
VMware, Inc. 31
Página 32
Consideraciones de almacenamiento de ESXi

Esta subsección proporciona orientación sobre las consideraciones de almacenamiento en ESXi.
Caché de lectura de vSphere Flash (vFRC)

vSphere Flash Read Cache (vFRC) permite recursos de almacenamiento flash en el host ESXi (el vSphere Flash
Capa de infraestructura) que se utilizará para el almacenamiento en caché de lectura de solicitudes de E / S de máquinas virtuales. Esto puede aumentar drásticamente
el desempeño de cargas de trabajo que exhiben localidad de acceso. Esta sección describe cómo obtener el mejor
rendimiento utilizando vFRC.
∎ Seleccione el hardware flash apropiado para la capa de infraestructura flash de vSphere (para obtener detalles, consulte "Hardware
Consideraciones de almacenamiento ” en la página 13) .
∎ Cree una capa de infraestructura flash de vSphere en el host ESXi. (Esto no se crea de forma predeterminada).
∎ Habilite vFRC seleccionando esa opción cuando cree un disco virtual o habilitándolo en otro momento. (vFRC es
no habilitado por defecto.)
∎ Configure el tamaño de la caché de forma adecuada. Idealmente, la caché sería lo suficientemente grande para contener el activo
conjunto de trabajo, pero no mucho más grande. La configuración de una caché más grande de lo necesario puede reducir el rendimiento al
haciendo que ese espacio flash no esté disponible para otras máquinas virtuales habilitadas para vFRC o para la caché de intercambio de host. Eso
también puede ralentizar vMotion de la máquina virtual.
N OTA El archivo de caché también puede afectar el rendimiento de vMotion; consulte "Recomendaciones de VMware vMotion"
en la página 67 para obtener más información.
∎ Configure el tamaño del bloque de caché de manera adecuada. Por lo general, esto debe coincidir con el tamaño de E / S de la carga de trabajo.
Para obtener más detalles sobre vFRC, incluida una guía sobre cómo determinar los mejores tamaños de bloque y caché, consulte
Rendimiento de vSphere Flash Read Cache en VMware vSphere 5.5 (aunque aborda específicamente vFRC en vSphere
5.5, este documento también es relevante para vFRC en vSphere 6.5).
API de VMware vStorage para integración de arreglos (VAAI)

∎ Para obtener el mejor rendimiento de almacenamiento, considere usar hardware de almacenamiento compatible con VAAI. El rendimiento gana
de VAAI (descrito en "Consideraciones de almacenamiento de hardware" en la página 13) puede ser especialmente notable en
Entornos VDI (donde VAAI puede mejorar el rendimiento de la carga de trabajo de escritorio y la tormenta de arranque), datos grandes
centros (donde VAAI puede mejorar el rendimiento del aprovisionamiento masivo de máquinas virtuales y de
discos virtuales de aprovisionamiento fino) y en otras implementaciones a gran escala.
El comportamiento de ESXi con almacenamiento compatible con VAAI es ligeramente diferente para SAN frente a NAS:
∎ Si su hardware de almacenamiento SAN admite VAAI, ESXi reconocerá y utilizará automáticamente estos
Capacidades
∎ Si su hardware de almacenamiento NAS es compatible con VAAI, ESXi reconocerá y utilizará automáticamente estos
capacidades solo si el complemento específico del proveedor está presente.
Para confirmar que su hardware es compatible con VAAI y que se está utilizando, siga las instrucciones en
Artículo 1021976 de VMware KB. Si determina que VAAI no se está utilizando, comuníquese con su hardware de almacenamiento.
proveedor para ver si se requiere una actualización de firmware para el soporte VAAI.
Métodos de acceso a LUN

∎ ESXi admite el mapeo de dispositivos sin procesar (RDM), que permite la administración y el acceso a discos SCSI sin procesar o
LUN como archivos VMFS. Un RDM es un archivo especial en un volumen VMFS que actúa como un proxy para un dispositivo sin formato.
El archivo RDM contiene metadatos que se utilizan para administrar y redirigir los accesos al disco al dispositivo físico.
Se recomienda VMFS ordinario para la mayoría del almacenamiento en disco virtual, pero los discos sin formato pueden ser deseables en algunos
casos.
Puede utilizar RDM en modo de compatibilidad virtual o en modo de compatibilidad física:
32 VMware, Inc.
Página 33
∎ El modo virtual especifica la virtualización completa del dispositivo mapeado, lo que permite que el sistema operativo invitado
tratar el RDM como cualquier otro archivo de disco virtual en un volumen VMFS y permitir el uso de VMware
rehaga los registros para tomar instantáneas del RDM.
∎ El modo físico especifica una virtualización SCSI mínima del dispositivo mapeado, lo que permite la mayor
flexibilidad para el software de administración de SAN u otro software basado en destino SCSI que se ejecuta en el entorno virtual
máquina.
Para obtener más información sobre RDM, consulte Almacenamiento de vSphere .

Modos de disco virtual
∎ ESXi admite tres modos de disco virtual: persistente independiente, no persistente independiente y
Dependiente.
N OTA Un disco independiente no participa en las instantáneas de la máquina virtual. Es decir, el estado del disco
ser independiente del estado de la instantánea; crear, consolidar o revertir a instantáneas no tendrá ningún efecto
en el disco.
Estos modos tienen las siguientes características:
∎ Persistente independiente : en este modo, los cambios se escriben de forma persistente en el disco,
Mejor presentación.
∎ Independiente no persistente : en este modo, las escrituras de disco se agregan a un registro de rehacer. El registro de rehacer es
se borra cuando apaga la máquina virtual o vuelve a una instantánea, lo que provoca cualquier cambio realizado
al disco para ser descartado. Cuando una máquina virtual lee desde un modo no persistente independiente
disco, ESXi primero verifica el registro de rehacer (mirando un directorio de bloques de disco contenidos en el registro de rehacer)
y, si se enumeran los bloques relevantes, lee esa información. De lo contrario, la lectura va al disco base.
para la máquina virtual. Debido a estos registros de rehacer, que rastrean los cambios en el archivo de una máquina virtual
sistema y le permiten realizar cambios o volver a un punto anterior en el tiempo, es posible que el rendimiento no sea
tan alto como discos independientes de modo persistente.
∎ Dependiente : en este modo, si se ha tomado una instantánea, las escrituras de disco se agregan a un registro de rehacer que
persiste entre ciclos de energía. Por lo tanto, al igual que los discos de modo no persistente independientes descritos
anterior, el rendimiento del disco en modo dependiente podría no ser tan alto como en el modo persistente independiente
discos. Sin embargo, si no se ha tomado una instantánea , los discos dependientes son tan rápidos como independientes
discos.
Tipos de discos virtuales

ESXi admite varios tipos de discos virtuales:
∎ Aprovisionamiento grueso: los discos virtuales gruesos, que tienen todo su espacio asignado en el momento de la creación,
dividido en dos tipos: ansioso-cero y perezoso-cero.
N OTA Con VMware Virtual Volumes (VVols; descrito en"VMware Virtual Volumes (VVols)" en
página 85) la propia matriz realiza automáticamente la puesta a cero según sea necesario; por tanto, no hay necesidad (y no hay forma) de
especifique la puesta a cero "ansiosa" versus "perezosa" para VVols.
∎ Cero ansioso: un disco grueso con cero ansioso tiene todo el espacio asignado y puesto a cero en el momento de
creación. Esto aumenta el tiempo que lleva crear el disco, pero da como resultado el mejor rendimiento, incluso
en la primera escritura en cada bloque.
N OTA El uso de almacenamiento SAN compatible con VAAI (descrito en"Consideraciones de almacenamiento de hardware" en
página 13) puede acelerar la creación de discos gruesos con puesta a cero rápida descargando las operaciones de puesta a cero al
matriz de almacenamiento.
VMware, Inc. 33
Página 34
N OTA Las ventajas de rendimiento de los discos gruesos con puesta a cero ansiosa son verdaderas solo para
discos virtuales persistentes o para discos virtuales dependientes que no tienen instantáneas. Independiente
los discos virtuales no persistentes, o los discos virtuales dependientes que tienen instantáneas, funcionarán como delgados
discos aprovisionados.
∎ Puesta a cero diferida: un disco grueso de puesta a cero diferida tiene todo el espacio asignado en el momento de la creación, pero cada bloque
se pone a cero solo en la primera escritura. Esto da como resultado un tiempo de creación más corto, pero un rendimiento reducido la primera
tiempo en el que se escribe un bloque. Sin embargo, las escrituras posteriores tienen el mismo rendimiento que en
Discos gruesos con ansias puesta a cero.
N OTA El uso de almacenamiento SAN o NAS compatible con VAAI puede mejorar el disco grueso con puesta a cero diferida
rendimiento de escritura por primera vez mediante la descarga de operaciones de puesta a cero en la matriz de almacenamiento.
∎ Thin provisioned : el espacio necesario para un disco virtual de thin provisioning se asigna y se pone a cero en la primera
escribir, en contraposición a la creación. Hay un costo de E / S más alto (similar al de los discos gruesos con puesta a cero diferida)
durante la primera escritura en un bloque de archivo no escrito, pero en las escrituras posteriores, los discos de aprovisionamiento fino tienen la
el mismo rendimiento que los discos gruesos con cero ansioso.
N OTA El uso de almacenamiento SAN compatible con VAAI puede mejorar la escritura en disco de aprovisionamiento fino
rendimiento mejorando la capacidad de bloqueo de archivos y descargando operaciones de puesta a cero en la matriz de almacenamiento.
Los tres tipos de discos virtuales se pueden crear con vSphere Web Client (haga clic con el botón derecho en la máquina virtual,
seleccione Editar configuración , elija la pestaña Hardware virtual , en Nuevo dispositivo (en la parte inferior) seleccione Nuevo disco duro ,
haga clic en Agregar , expanda la línea Nuevo disco duro , luego seleccione el tipo de disco).
Los discos virtuales también se pueden crear desde vSphere Command-Line Interface (vSphere CLI) mediante vmkfstools.
Para obtener detalles, consulte la Referencia de la interfaz de línea de comandos de vSphere y la página de manual de vmkfstools.
N OTA Es posible que algunos de estos tipos de discos virtuales no estén disponibles al crear discos virtuales en volúmenes NFS,
dependiendo del proveedor de hardware y si el hardware es compatible o no con VAAI.
Alineación de particiones
La alineación de las particiones del sistema de archivos puede afectar el rendimiento. VMware hace lo siguiente
recomendaciones para particiones VMFS:
∎ Al igual que otros sistemas de archivos basados en disco, los sistemas de archivos VMFS sufren una penalización de rendimiento cuando la partición está
no alineado. El uso de vSphere Web Client para crear particiones VMFS evita este problema porque,
comenzando con ESXi 5.0, alinea automáticamente las particiones VMFS3, VMFS5 o VMFS6 a lo largo de 1 MB
Perímetro.
N OTA Si se creó una partición VMFS3 con una versión anterior de ESX / ESXi que se alineó a lo largo de 64 KB
límite, y ese sistema de archivos se actualiza a VMFS5, conservará su alineación de 64 KB. 1 MB
La alineación se puede obtener eliminando la partición y recreándola utilizando vSphere Web Client con
un host ESXi 5.0 o posterior.
Los volúmenes VMFS3 o VMFS5 existentes no se pueden convertir directamente a VMFS6. En su lugar, un volumen VMFS6
deben crearse desde cero y luego las máquinas virtuales migradas al nuevo volumen usando Storage
vMotion.
∎ Para alinear manualmente sus particiones VMFS, consulte las recomendaciones de su proveedor de almacenamiento para la partición
dirección del bloque inicial. Si su proveedor de almacenamiento no hace una recomendación específica, use un bloque de inicio
dirección que es un múltiplo de 8 KB.
∎ Antes de realizar una alineación, evalúe cuidadosamente el impacto en el rendimiento del VMFS no alineado
partición en su carga de trabajo particular. El grado de mejora de la alineación depende en gran medida
sobre cargas de trabajo y tipos de arreglos. Es posible que desee consultar las recomendaciones de alineación de su
proveedor de matrices para obtener más información.
34 VMware, Inc.
Página 35
SAN de múltiples rutas

Las políticas de ruta SAN pueden tener un efecto significativo en el rendimiento del almacenamiento. En general, la política de ruta que usa ESXi
por defecto para una matriz en particular será la mejor opción. Si selecciona una política de ruta no predeterminada, le recomendamos
elegir entre las políticas probadas y respaldadas en esa matriz por su proveedor.
Esta sección proporciona una breve descripción general del tema de las políticas de ruta SAN.
∎ Para la mayoría de los arreglos de almacenamiento activos / pasivos, ESXi usa la política de ruta de uso más reciente (MRU) de forma predeterminada.
No recomendamos utilizar la política de ruta fija para matrices de almacenamiento activo / pasivo, ya que esto puede resultar en
cambio de ruta frecuente y rápido (a menudo denominado "eliminación de ruta"), que puede provocar un acceso lento al LUN. por
rendimiento óptimo con las matrices para las que ESXi tiene como valor predeterminado MRU, también podría considerar la Ronda
Política de ruta de Robin (descrita a continuación).
N OTA Con algunos arreglos de almacenamiento activos / pasivos que admiten ALUA (descritos a continuación), ESXi puede usar Fixed
política de ruta. Sin embargo, recomendamos que solo lo use en arreglos donde sea específicamente compatible con
el proveedor de SAN. En la mayoría de los casos, Round Robin es una opción mejor y más segura para arreglos activos / pasivos.
∎ Para la mayoría de los arreglos de almacenamiento activos / activos, ESXi usa la política de ruta fija de forma predeterminada. Al usar esta política
puede maximizar la utilización de su ancho de banda para la matriz de almacenamiento mediante la designación de rutas preferidas
a cada LUN a través de diferentes controladores de almacenamiento. Para un rendimiento óptimo con estos arreglos, puede
también considere la política de ruta Round Robin (descrita a continuación).
∎ ESXi puede utilizar la política de ruta Round Robin , que puede mejorar el rendimiento del almacenamiento en algunos
Ambientes. La política Round Robin proporciona equilibrio de carga mediante el ciclo de solicitudes de E / S a través de todas las
rutas, enviando un número fijo (pero configurable) de solicitudes de E / S a través de cada una de ellas.
N OTA No todos los arreglos de almacenamiento admiten la política de ruta Round Robin. Cambiar a un no admitido o
La política de ruta no deseada puede provocar problemas de conectividad con los LUN o incluso una interrupción del almacenamiento. Revisar su
documentación de la matriz o con su proveedor de almacenamiento para ver si Round Robin es compatible y / o
recomendado para su matriz y configuración.
∎ ESXi también admite complementos de selección de ruta de terceros (PSP). En algunos casos, estos pueden proporcionar la mejor
rendimiento para una matriz específica mediante la explotación de características específicas de la matriz o el conocimiento de su diseño.
∎ Si su matriz de almacenamiento admite ALUA (acceso asimétrico a unidades lógicas), habilite esta función en la matriz
puede mejorar el rendimiento del almacenamiento en algunos entornos. ALUA, que es detectado automáticamente por
ESXi, permite que la propia matriz designe rutas como "Activa optimizada". Cuando ALUA se combina con el
Política de ruta de ida y vuelta, ESXi de forma predeterminada realiza ciclos de solicitudes de E / S a través de estas rutas Active Optimized.
Para obtener más información, consulte la Guía de configuración de SAN de VMware y el artículo de la base de conocimiento de VMware 1011340.
Asignación de recursos de E / S de almacenamiento

VMware vSphere proporciona mecanismos para asignar dinámicamente recursos de E / S de almacenamiento, lo que permite
cargas de trabajo para mantener su rendimiento incluso durante los períodos de carga máxima cuando hay contienda por E / S
recursos. Esta asignación se puede realizar en los recursos de almacenamiento disponibles para un host individual (como
descrito en esta sección) o en los recursos de un almacén de datos completo (como se describe en "VMware vSphere Storage I / O
Control ” en la página 76) .
Los recursos de E / S de almacenamiento disponibles para un host ESXi se pueden asignar a los discos virtuales de ese host configurando disk
Acciones o límites.
∎ La proporción de recursos de E / S de un almacén de datos disponibles para cada disco virtual se puede controlar con recursos compartidos .
Cada disco virtual recibirá una proporción del ancho de banda del almacén de datos igual al recurso compartido de ese disco virtual.
dividido por la suma de los recursos compartidos de todos los discos virtuales de ese host.
∎ Los recursos máximos de E / S de almacenamiento disponibles para cada disco virtual se pueden configurar mediante Límites . Estos límites
establecido en operaciones de E / S por segundo (IOPS), se puede utilizar para proporcionar un aislamiento estricto y control de ciertos
cargas de trabajo. De forma predeterminada, están configurados como ilimitados .
VMware, Inc. 35
Página 36
Para establecer recursos compartidos o límites, en vSphere Web Client, haga clic con el botón derecho en una máquina virtual, seleccione Editar configuración , elija
la pestaña Hardware virtual , expanda Disco duro 1 (o el disco duro que desee configurar), luego configure el
Acciones o límite: IOP al valor deseado.
Recomendaciones de iSCSI y NFS

∎ Para iSCSI y NFS, a veces es beneficioso crear una VLAN, si la infraestructura de red lo admite,
solo para vmknic del host ESXi y el servidor iSCSI / NFS. Esto minimiza la interferencia de red de otros
fuentes de paquetes.
Recomendaciones de NVMe
El almacenamiento flash en tarjetas PCIe utilizaba inicialmente interfaces y protocolos SCSI o SATA, a menudo limitando su
rendimiento a mucho menos de lo que eran capaces los dispositivos SSD subyacentes. Algunos flash PCIe más nuevos
Los dispositivos utilizan el protocolo Non-Volatile Memory Express (NVMe), lo que potencialmente permite
actuación.
N OTA vSphere también admite NVMe virtual (vNVMe), que se describe en"Almacenamiento del sistema operativo invitado
Consideraciones ” en la página 52 .
Consideraciones sobre el rendimiento de NVMe:
∎ Los dispositivos NVMe están altamente paralelizados; su rendimiento máximo se alcanza generalmente cuando son
respaldar múltiples discos virtuales y / o múltiples máquinas virtuales.
∎ El alto rendimiento de NVMe crea una carga de CPU correspondientemente alta. Los dispositivos NVMe son, por tanto, mejores
apto para configuraciones de hardware con muchos núcleos por socket (preferiblemente al menos ocho) y múltiples sockets
(preferiblemente al menos dos). También son deseables altas frecuencias de CPU.
∎ Los adaptadores de almacenamiento virtual utilizados por las máquinas virtuales invitadas deben elegirse de forma adecuada. Estas
normalmente será PVSCSI o el nuevo adaptador virtual vNVMe. (Ver"Almacenamiento del sistema operativo invitado
Consideraciones ” en la página 52 para obtener más detalles).
Recomendaciones de cifrado de máquinas virtuales de vSphere

El cifrado de máquina virtual, nuevo en vSphere 6.5, puede cifrar archivos de disco (.vmdk), archivos de instantáneas (.vmsn),
Archivos NVRAM (.nvram), archivos de intercambio (.vswp) y partes de archivos de configuración (.vmx). Cifrado y
el descifrado lo realiza la CPU y, por lo tanto, incurre en un costo de CPU. Cuando es posible, vSphere usa AES-NI
extensiones del conjunto de instrucciones del procesador (admitidas por muchos procesadores recientes) para reducir ese costo de CPU.
∎ La sobrecarga de recursos del cifrado de máquinas virtuales se encuentra principalmente en la utilización de la CPU. Por lo tanto, con suficiente
Los recursos de CPU, implementaciones típicas (es decir, aquellas que no usan almacenamiento ultrarrápido) no verán
impacto en el rendimiento.
∎ Para minimizar significativamente el uso de CPU adicional debido al cifrado de VM, elija procesadores que
compatible con AES-NI (consulte "Soporte AES-NI" en la página 12) , especialmente algunas versiones recientes de procesador en las que
la implementación de AES-NI se optimiza aún más.
∎ Asegúrese de que AES-NI esté habilitado en BIOS. En algunos casos, es posible que se requiera una actualización de BIOS para AES-NI
apoyo.
∎ Debido a que el cifrado se realiza en el host, los dispositivos de almacenamiento solo ven datos cifrados. Características especiales
de algunos dispositivos de almacenamiento, como la deduplicación o la compresión, pueden ser ineficaces o no
proporcionar todo su beneficio. (Para una opción de cifrado que tiene lugar en el nivel de almacenamiento, lo que permite
deduplicación y compresión, consulte “VMware Virtual SAN (vSAN)” en la página 83. )
∎ Cuando se utiliza el cifrado de máquina virtual con almacenamiento que tiene latencias muy bajas (por debajo de 200
microsegundos), el tiempo que tarda la CPU en procesar las solicitudes de cifrado puede comenzar a afectar
actuación.
Se pueden encontrar más detalles sobre estos temas en VMware vSphere Virtual Machine Encryption Performance white
papel.
36 VMware, Inc.
Página 37
Recomendaciones generales de almacenamiento de ESXi

∎ La cantidad de LUN en una matriz de almacenamiento y la forma en que las máquinas virtuales se distribuyen entre esos LUN,
puede afectar el rendimiento:
∎ El aprovisionamiento de más LUN, con menos máquinas virtuales en cada uno, puede permitir que los servidores ESXi
presentar simultáneamente más solicitudes de E / S al arreglo. Esto tiene el potencial de mejorar el rendimiento.
asegurando la plena utilización de todos los recursos de la matriz y brindando a la matriz más oportunidades para optimizar
las E / S.
∎ Por otro lado, aprovisionar demasiados LUN, especialmente cuando hay muchos servidores ESXi conectados
a una sola matriz, puede permitir que los hosts ESXi envíen simultáneamente tantas solicitudes de E / S que llenen
la cola de la matriz y la matriz devuelve errores QFULL / BUSY. Esto puede reducir el rendimiento debido a
debe volver a intentar las solicitudes de E / S rechazadas.
∎ Las estadísticas de latencia de E / S se pueden monitorear usando esxtop (o resxtop), que informa la latencia del dispositivo, el tiempo
gastado en el kernel, y la latencia vista por el sistema operativo invitado.
∎ Asegúrese de que la latencia promedio de los dispositivos de almacenamiento no sea demasiado alta. Esta latencia se puede ver en esxtop
(o resxtop) mirando la métrica GAVG / cmd . Un valor superior razonable para esta métrica depende de
su subsistema de almacenamiento. Si usa Storage I / O Control ("Control de E / S de almacenamiento de VMware vSphere" en
página 76) , puede utilizar la configuración de Storage I / O Control como guía; su valor GAVG / cmd debe ser
muy por debajo de la configuración de Control de E / S de almacenamiento. La configuración predeterminada de Storage I / O Control es 30 ms, pero si
tiene un almacenamiento muy rápido (SSD, por ejemplo), es posible que haya reducido ese valor. Para más información sobre
latencia promedio, consulte el artículo de la base de conocimiento de VMware 1008205.
∎ Puede ajustar la cantidad máxima de solicitudes de disco pendientes por volumen VMFS, lo que puede ayudar
igualar el ancho de banda en las máquinas virtuales que utilizan ese volumen. Para obtener más información, consulte VMware
Artículo 1268 de KB.
∎ Si observa con frecuencia errores QFULL / BUSY, es posible que habilitar y configurar la limitación de la profundidad de la cola
mejorar el rendimiento del almacenamiento. Esta característica puede reducir significativamente la cantidad de comandos devueltos
de la matriz con un error QFULL / BUSY. Si algún sistema accede a un LUN o puerto de matriz de almacenamiento en particular
tiene habilitada la limitación de la profundidad de la cola, todos los sistemas (tanto hosts ESXi como otros sistemas) acceden a ese LUN
o el puerto de la matriz de almacenamiento debe utilizar un algoritmo de profundidad de cola adaptable. Para obtener más información sobre ambos
QFULL / BUSY y esta función, consulte el artículo 1008113 de la base de conocimiento de VMware.
Ejecución de aplicaciones sensibles a la latencia de almacenamiento

De forma predeterminada, la pila de almacenamiento ESXi está configurada para impulsar un alto rendimiento de almacenamiento con un bajo costo de CPU. Mientras esto
La configuración predeterminada proporciona una mejor escalabilidad y mayores índices de consolidación, tiene el costo de
latencia de almacenamiento potencialmente mayor. Por tanto, las aplicaciones que son muy sensibles a la latencia de almacenamiento
beneficiarse de lo siguiente:
∎ Ajuste la configuración de administración de energía del host:
Algunas de las funciones de administración de energía en el hardware de servidor más nuevo pueden aumentar la latencia del almacenamiento. Inhabilitar
ellos de la siguiente manera:
∎ Configure la política de energía del host ESXi en Máximo rendimiento (como se describe en"Administración de energía del host
en ESXi ” en la página 24 ; este es el método preferido) o deshabilite la administración de energía en el BIOS (como
descrito en “Configuración del BIOS de administración de energía” en la página 17) .
∎ Deshabilite C1E y otros estados C en BIOS (como se describe en "Configuración de BIOS de administración de energía" en
página 17) .
∎ Habilite Turbo Boost en BIOS (como se describe en “Configuración general del BIOS” en la página 17) .
∎ Si está utilizando un vHBA LSILogic o un vHBA PVSCSI (con la versión de hardware 11) en la máquina virtual,
puede ajustar el valor reqCallThreshold.
Cuanto menor sea el valor de reqCallThreshold, es probable que las solicitudes de E / S permanezcan en los vHBA
cola. Por ejemplo, si reqCallThreshold se establece en 1, significa que cuando hay incluso una solicitud de E / S en el
cola de vHBA, las E / S se enviarán a la capa inferior. (El valor predeterminado de reqCallThreshold es 8.)
VMware, Inc. 37
Página 38
Hay dos formas de ajustar el valor de reqCallThreshold:
∎ Cambie el valor de todos los vHBA en el sistema ejecutando el comando:

esxcfg-advcfg -s x / Disk / ReqCallThreshold
(donde x es el valor deseado de reqCallThreshold).
∎ Anule la configuración de todo el sistema para un vHBA específico agregando:

scsi Y .reqCallThreshold = X
al archivo .vmx (donde Y es el número SCSI de destino y X es el valor de reqCallThreshold deseado).
Para obtener más información sobre la ejecución de aplicaciones sensibles a la latencia de almacenamiento, consulte las Prácticas recomendadas para
Ajuste del rendimiento de cargas de trabajo sensibles a la latencia en máquinas virtuales de vSphere , mientras se aborda principalmente la red
aplicaciones sensibles a la latencia, pueden resultar útiles.
38 VMware, Inc.
Página 39
Consideraciones sobre redes ESXi

Esta subsección proporciona orientación sobre las consideraciones de red en ESXi.
Consideraciones generales sobre redes ESXi

∎ En un entorno nativo, la utilización de la CPU juega un papel importante en el rendimiento de la red. Procesar
mayores niveles de rendimiento, se necesitan más recursos de CPU. El efecto de la disponibilidad de recursos de la CPU en
el rendimiento de la red de aplicaciones virtualizadas es aún más significativo. Porque CPU insuficiente
Los recursos limitarán el rendimiento máximo, es importante controlar la utilización de la CPU de
cargas de trabajo de alto rendimiento.
∎ Si varios consumidores comparten una NIC física (es decir, máquinas virtuales y / o vmkernel), cada
dicho consumidor podría afectar el desempeño de otros. Por lo tanto, para obtener el mejor rendimiento de la red, utilice
NIC físicas separadas para consumidores con E / S de red pesadas (porque podrían reducir la
rendimiento de la red de otros consumidores) y para consumidores con cargas de trabajo sensibles a la latencia (porque
estos podrían verse afectados de manera más significativa por otros consumidores).
Debido a que tienen soporte para múltiples colas, 10 Gb / sy NIC más rápidas pueden separar a estos consumidores en
diferentes colas. Por lo tanto, siempre que estas NIC más rápidas tengan suficientes colas disponibles, esta recomendación
normalmente no se aplica a ellos.
Además, NetIOC (descrito a continuación) se puede utilizar para reservar ancho de banda para clases específicas de tráfico,
proporcionando aislamiento de recursos entre diferentes flujos. Si bien esto se puede usar con NIC de cualquier velocidad, es
especialmente útil para NIC de 10 Gb / sy más rápidas, ya que estos son compartidos con mayor frecuencia por varios consumidores.
∎ Para establecer una conexión de red entre dos máquinas virtuales que residen en el mismo sistema ESXi,
conecte ambas máquinas virtuales al mismo conmutador virtual. Si las máquinas virtuales están conectadas a diferentes
conmutadores virtuales, el tráfico pasará por cables e incurrirá en una sobrecarga innecesaria de CPU y red.
Control de E / S de red (NetIOC)

El control de E / S de red (NetIOC) permite la asignación de ancho de banda de red a los grupos de recursos de la red. usted
puede seleccionar entre nueve grupos de recursos predefinidos (tráfico de gestión, tráfico de tolerancia a fallos,
Tráfico iSCSI, tráfico NFS, tráfico Virtual SAN, tráfico vMotion, tráfico vSphere Replication (VR), vSphere Data
Protección Copia de seguridad del tráfico y del tráfico de la máquina virtual) o puede crear grupos de recursos definidos por el usuario. Cada
el grupo de recursos está asociado con un grupo de puertos.
N OTA vSphere 6.0 introdujo NetIOC versión 3 (NetIOCv3), que asigna ancho de banda al nivel del
conmutador distribuido completo, en lugar de en el nivel del adaptador físico, como en NetIOC versión 2 (NetIOCv2). Esta
El libro describe solo NetIOCv3.
Al crear un nuevo vSphere Distributed Switch en vSphere 6.5, ese conmutador utilizará NetIOCv3 de forma predeterminada.
Sin embargo, los conmutadores actualizados desde una versión anterior de ESXi, en algunos casos, no se actualizarán automáticamente
a NetIOCv3. Para obtener más información sobre esto, consulte vSphere Networking para la versión 6.5.
NetIOC puede garantizar ancho de banda para necesidades específicas y puede evitar que cualquier grupo de recursos impacte
los demás.
A partir de vSphere 6.0, cuando DRS (“VMware Distributed Resource Scheduler (DRS)” en la página 70 ) balanceos de carga
máquinas virtuales en todos los hosts, incluirá reservas de ancho de banda NetIOC en sus cálculos.
Para obtener más información sobre NetIOC, consulte Evaluación del rendimiento del control de E / S de red en VMware vSphere 6.0
y vSphere Networking para la versión 6.5.
Configuración de control de E / S de red
Con NetIOC, el ancho de banda de la red se puede asignar a grupos de recursos, así como a máquinas virtuales individuales.
usando acciones, reservas o límites:
VMware, Inc. 39
Página 40
∎ Los recursos compartidos se pueden utilizar para asignar a un grupo de recursos o máquina virtual una proporción del enlace de red.
ancho de banda equivalente a la relación entre sus acciones y el total de acciones. Si un grupo de recursos o una máquina virtual
no utiliza su asignación completa, el ancho de banda no utilizado está disponible para otros consumidores de ancho de banda que utilizan el
misma NIC física.
∎ La reserva de ancho de banda se puede utilizar para garantizar un ancho de banda mínimo (en Mb / s) para un grupo de recursos o
máquina virtual. Las reservas totales de ancho de banda están limitadas al 75% de la capacidad del subyacente.
adaptador físico. Si un grupo de recursos o una máquina virtual no usa su reserva completa, el
El ancho de banda está disponible para otros consumidores de ancho de banda que utilizan la misma NIC física.
∎ Los límites se pueden utilizar para establecer un grupo de recursos o la utilización máxima del ancho de banda de la máquina virtual (en Mb / s
o Gb / s) por NIC física a través de un conmutador distribuido virtual (vDS) específico. Estos límites se hacen cumplir
incluso si un vDS no está saturado, lo que potencialmente limita el ancho de banda de un consumidor y al mismo tiempo deja
algo de ancho de banda sin usar. Por otro lado, si la utilización del ancho de banda de un consumidor es menor que su límite,
el ancho de banda no utilizado está disponible para otros consumidores de ancho de banda que utilizan la misma NIC física.
Opciones de rendimiento avanzadas de control de E / S de red
∎ Una nueva opción en vSphere 6.5, HClock Multiqueue, puede mejorar el rendimiento en algunos entornos con
paquetes pequeños y alta velocidad de paquetes. Esta opción, que está deshabilitada de forma predeterminada, permite múltiples vNIC o
múltiples vmknics para distribuir el tráfico a través de múltiples colas de transmisión de hardware en una única NIC física.
Puede habilitar y configurar esta opción para un host ESXi de la siguiente manera:
un Habilite HClock Multiqueue ejecutando el siguiente comando:

configuración avanzada del sistema esxcli -i x -o / Net / NetSchedHClkMQ
(donde un valor para x de 1 habilita la función y 0 la deshabilita).
segundo
Configure el número máximo de colas que HClock utilizará ejecutando el siguiente comando:
Configuración avanzada del sistema esxcli -i n -o / Net / NetSchedHClkMaxHwQueue
(donde n es el número máximo de colas; el valor predeterminado es 2).
C Elimine y luego abra cada NIC física en el host ESXi:

esxcli red nic abajo -n vmnic X
esxcli red nic up -n vmnic X
(donde X identifica a qué vmnic se aplica el comando).
E / S DirectPath
vSphere DirectPath I / O aprovecha el soporte de hardware Intel VT-d y AMD-Vi (descrito en
“Virtualización MMU de E / S asistida por hardware (VT-d y AMD-Vi)” en la página 12 ) para permitir el funcionamiento de invitados
sistemas para acceder directamente a dispositivos de hardware. En el caso de las redes, DirectPath I / O permite la
máquina para acceder a una NIC física directamente en lugar de utilizar un dispositivo emulado (como el E1000) o un
dispositivo paravirtualizado (como VMXNET o VMXNET3). Si bien DirectPath I / O proporciona aumentos limitados en
rendimiento, reduce el costo de CPU para cargas de trabajo intensivas en red.
Sin embargo, DirectPath I / O no es compatible con determinadas funciones básicas de virtualización. Esta lista varía con el
hardware en el que se ejecuta ESXi:
∎ Cuando ESXi se ejecuta en determinadas configuraciones de la plataforma Cisco Unified Computing System (UCS),
DirectPath I / O para redes es compatible con vMotion, uso compartido de NIC físico, instantáneas y
suspender / reanudar. No es compatible con Fault Tolerance, NetIOC, overcommit de memoria, VMCI,
Virtualización de redes VMSafe o NSX.
∎ Para hardware de servidor que no sea la plataforma Cisco UCS, DirectPath I / O no es compatible con vMotion,
uso compartido de NIC físico, instantáneas, suspensión / reanudación, tolerancia a fallas, NetIOC, sobreasignación de memoria,
Virtualización de redes VMSafe o NSX.
Las máquinas virtuales típicas y sus cargas de trabajo no requieren el uso de DirectPath I / O. Para cargas de trabajo que son
muy intensivo en redes y no necesita las funciones de virtualización centrales mencionadas anteriormente, sin embargo,
DirectPath I / O puede resultar útil para reducir el uso de la CPU.
40 VMware, Inc.
Página 41
Virtualización de E / S de raíz única (SR-IOV)

vSphere admite la virtualización de E / S de raíz única (SR-IOV), un nuevo modo de acceso directo de invitados al hardware
dispositivos. Además del soporte de hardware Intel VT-d o AMD-Vi (descrito en"MMU de E / S asistidas por hardware
Virtualización (VT-d y AMD-Vi) ” en la página 12 ), SR-IOV también requiere BIOS, NIC física y red.
apoyo al conductor. Para obtener más información sobre las configuraciones admitidas, consulte la versión 6.5 de vSphere Networking .
SR-IOV ofrece ventajas de rendimiento y compensaciones similares a las de DirectPath I / O. SR-IOV es beneficioso en
cargas de trabajo con tasas de paquetes muy altas o requisitos de latencia muy bajos. Como DirectPath I / O, SR-IOV no es
compatible con ciertas funciones básicas de virtualización, como vMotion (para obtener detalles, consulte la lista de compatibilidad para
hardware que no sea la plataforma Cisco UCS en “DirectPath I / O” en la página 40 ). SR-IOV, sin embargo, permite
para que un solo dispositivo físico se comparta entre varios invitados.
Modo SplitRx
El modo SplitRx utiliza varias CPU físicas para procesar los paquetes de red recibidos en una sola cola de red.
Esta función puede mejorar significativamente el rendimiento de la red para determinadas cargas de trabajo. Estas cargas de trabajo incluyen:
∎ Varias máquinas virtuales en un host ESXi reciben tráfico de multidifusión desde la misma fuente.
(El modo SplitRx generalmente mejorará el rendimiento y la eficiencia de la CPU para estas cargas de trabajo).
∎ Tráfico a través de la API de vNetwork Appliance (DVFilter) entre dos máquinas virtuales en el mismo host ESXi.
(El modo SplitRx generalmente mejorará el rendimiento y las velocidades máximas de paquetes para estas cargas de trabajo).
En vSphere 5.1 y versiones posteriores, esta función se habilita automáticamente para un adaptador de red virtual VMXNET3 (el
único tipo de adaptador en el que es compatible) cuando ESXi detecta que una sola cola de red en una NIC física
está (a) muy utilizado y (b) recibe más de 10,000 paquetes de transmisión / multidifusión por segundo.
N OTA El modo SplitRx se habilitará automáticamente como se describe arriba solo si el tráfico de la red está entrando
a través de una NIC física, no cuando el tráfico es completamente interno al host ESXi. En los casos en que el tráfico es
completamente interno, sin embargo, el modo SplitRx se puede habilitar manualmente si se desea, como se describe en "Habilitar o
Desactivación del modo SplitRx para una NIC virtual individual ” en la página 41 .
Desactivación del modo SplitRx para todo un host ESXi
Este comportamiento automático puede desactivarse para todo un host ESXi mediante la variable NetSplitRxMode.
Los posibles valores de esta variable son:
∎ NetSplitRxMode = "0"
Este valor desactiva el modo splitRx para el host ESXi.
∎ NetSplitRxMode = "1"
Este valor (el predeterminado) habilita el modo splitRx para el host ESXi.
Para cambiar esta variable a través de vSphere Web Client:
1 Seleccione el host ESXi que desea cambiar.
2 En la pestaña Configurar , expanda Sistema , luego haga clic en Configuración avanzada del sistema .
3 Haga clic en Editar (en la esquina superior derecha).
4 Busque NetSplitRxMode (está en Net.NetSplitRxMode ).
5 Haga clic en el valor a modificar y configúrelo como desee.
6 Haga clic en Aceptar para cerrar la ventana Editar configuración avanzada del sistema .
El cambio entrará en vigencia de inmediato y no requiere que se reinicie el host ESXi.
Habilitación o deshabilitación del modo SplitRx para una NIC virtual individual
La función del modo SplitRx también se puede configurar individualmente para cada NIC virtual (anulando la
NetSplitRxMode) usando la variable ethernet X .emuRxMode en el archivo .vmx de cada máquina virtual (donde
X se reemplaza con el ID del adaptador de red).
VMware, Inc. 41
Página 42
Los posibles valores de esta variable son:
∎ ethernet X .emuRxMode = "0"

Este valor deshabilita el modo splitRx para Ethernet X .
∎ ethernet X .emuRxMode = "1"

Este valor se activa el modo splitRx para Ethernet X .
1 Seleccione la máquina virtual que desea cambiar.
2 En la pestaña Configurar , expanda Configuración , luego seleccione Opciones de VM
4 Expanda Avanzado , luego en Parámetros de configuración haga clic en Editar configuración .
5 Busque ethernet X .emuRxMode (donde X es el número de la NIC deseada) y configúrelo como desee.
deseo. Si la variable no está presente, introdúzcala como una nueva variable y haga clic en Agregar .
6 Haga clic en Aceptar para cerrar la ventana Parámetros de configuración .
7 Haga clic en Aceptar para cerrar la ventana Editar configuración .
El cambio no surtirá efecto hasta que la máquina virtual se haya reiniciado o la vNIC relevante
desconectado de la máquina virtual y conectado de nuevo.
Recibir escalado lateral (RSS)

Receive Side Scaling (RSS) es una función que permite programar paquetes de red desde una única NIC en
paralelo en varias CPU mediante la creación de varias colas de hardware. Si bien esto puede aumentar la red
rendimiento para una NIC que recibe paquetes a una velocidad alta, también puede aumentar la sobrecarga de la CPU.
Cuando se utilizan determinadas NIC físicas Ethernet de 10 Gb / so 40 Gb / s, ESXi permite las capacidades RSS del
NIC que utilizarán las NIC virtuales. Esto puede resultar especialmente útil en entornos donde un solo MAC
La dirección recibe grandes cantidades de tráfico de red (por ejemplo, VXLAN o dispositivos virtuales de uso intensivo de la red).
Debido a la posibilidad de que aumente la sobrecarga de la CPU, esta función está desactivada de forma predeterminada.
Puede habilitar esta función de la siguiente manera:
∎ Para NIC Intel 82599EB SFI / SFP + 10 Gb / s:
Cargue el controlador ejecutando vmkload_mod ixgbe RSS = "4"
Para habilitar la función en varias NIC Intel 82599EB SFI / SFP + 10Gb / s, incluya otra
4 para cada NIC adicional (por ejemplo, para habilitar la función en tres de estos NIC, debe ejecutar vmkload_mod
ixgbe RSS = "4,4,4").
∎ Para NIC de Mellanox Technologies MT27500 Family ConnectX-3 de 10 Gb / so 40 Gb / s:
Cargue el controlador ejecutando vmkload_mod nmlx4_en num_rings_per_rss_queue = 4
N OTA Después de cargar el controlador con vmkload_mod, debe hacer que vmkdevmgr redescubra las NIC
con el siguiente comando:
'kill -HUP "< pid de vmkdevmgr >”'
(donde < pid of vmkdevmgr > es el ID de proceso del proceso vmkdevmgr).
Para habilitar la función en varias NIC MT27500 Family ConnectX-3 de 10 Gb / so 40 Gb / s, incluya una
4 adicionales separados por comas para cada NIC adicional (por ejemplo, para habilitar la función en tres
NIC, ejecutaría vmkload_mod nmlx4_en num_rings_per_rss_queue = 4,4,4.
∎ En el archivo .vmx de cada máquina virtual que utilizará esta función, agregue ethernet X .pNicFeatures = "4"
(donde X es el número de la tarjeta de red virtual a la que se debe agregar la función).
42 VMware, Inc.
Página 43
Coalescencia de interrupciones de red virtual

La fusión de interrupciones de la red virtual puede reducir el número de interrupciones, lo que potencialmente reduce la CPU.
utilización. Aunque esto podría aumentar la latencia de la red, muchas cargas de trabajo no se ven afectadas por
latencia de la red de unos pocos cientos de microsegundos a unos pocos milisegundos, y la reducción de
La sobrecarga de la red virtual puede permitir que se ejecuten más máquinas virtuales en un solo host ESXi.
De forma predeterminada, esta función está habilitada para todas las NIC virtuales en ESXi. Sin embargo, para las NIC virtuales VMXNET3,
La función se puede configurar en uno de tres esquemas o se puede deshabilitar cambiando ethernet X .coalescingScheme
variable (donde X es el número de NIC virtual a configurar).
∎ La función se habilitará (por defecto) si la variable ethernet X .coalescingScheme no está presente en

el archivo .vmx o si la variable está presente y configurada en rbc .
En este caso, la variable ethernetX.coalescingParams se puede utilizar para configurar la interrupción de la red virtual
tasa en interrupciones por segundo. El valor puede oscilar entre 100 y 100.000, con un valor predeterminado de 4.000.
∎ La función se puede configurar para poner en cola una cantidad predefinida de paquetes antes de interrumpir la máquina virtual.
o transmitir los paquetes configurando ethernet X .coalescingScheme en static .
En este caso, la variable ethernetX.coalescingParams se puede utilizar para establecer el número de paquetes ESXi
hará cola. El valor puede oscilar entre 1 y 64, con un valor predeterminado de 64. Un tamaño de cola más grande puede reducir el
número de cambios de contexto entre la máquina virtual y el VMkernel, lo que potencialmente reduce la CPU
utilización tanto en la máquina virtual como en el VMkernel.
Sin embargo, independientemente de la cantidad de paquetes en cola, ESXi no espera más de 4 milisegundos antes
enviar una interrupción o transmitir los paquetes. Otros eventos, como que la máquina virtual esté inactiva, pueden
también desencadenan interrupciones de la máquina virtual o transmisión de paquetes, por lo que los paquetes rara vez se retrasan el 4
milisegundos.
∎ La función se puede configurar para que sea adaptable configurando ethernet X .coalescingScheme para adaptarse . Este escenario,
nuevo en vSphere 6.5, basa la tasa de interrupciones tanto en la carga de la máquina virtual como en la carga general del sistema;
utiliza una tasa de interrupción más baja cuando la carga es alta y una tasa de interrupción más alta cuando la carga es baja.
∎ La función se puede desactivar configurando ethernet X .coalescingScheme en desactivado . Desactivando esto

característica normalmente dará como resultado más interrupciones (y por lo tanto, una mayor utilización de la CPU), pero normalmente también
conducir a una latencia de red más baja.
Para configurar la fusión virtual de interrupciones VMXNET3 a través de vSphere Web Client:
1 Haga clic con el botón derecho en la máquina virtual que desea cambiar y luego seleccione Editar configuración .
2 En la pestaña Opciones de VM , expanda Avanzado , luego haga clic en Editar configuración .
3 Busque y configure la variable que desea cambiar:
∎ Si selecciona un esquema de fusión de interrupciones virtuales, busque ethernetX.coalescingScheme (donde X es

el número de la NIC virtual a configurar) y configúrelo en el valor deseado.
Si la variable no está presente, ingrésela como una nueva variable, ingrese un valor y haga clic en Agregar .
∎ Si configura la tasa de interrupción de la red virtual o el tamaño de la cola, busque ethernetX.coalescingParams

(donde X es el número de NIC virtual que se va a configurar) y configúrelo en el valor deseado.
Si la variable no está presente, ingrésela como una nueva variable, ingrese un valor y haga clic en Agregar .
El cambio no surtirá efecto hasta que se reinicie la máquina virtual.
Ejecución de aplicaciones sensibles a la latencia de red

De forma predeterminada, la pila de red ESXi está configurada para impulsar una red alta a un bajo costo de CPU. Mientras esto
La configuración predeterminada proporciona una mejor escalabilidad y mayores índices de consolidación, tiene el costo de
latencia de red potencialmente mayor. vSphere proporciona una variedad de opciones de configuración para mejorar
rendimiento de aplicaciones que son altamente sensibles a la latencia de la red (latencia del orden de unas pocas decenas de
microsegundos). Esta sección describe esas opciones. Para obtener más información sobre este tema, consulte Prácticas recomendadas para
Ajuste del rendimiento de cargas de trabajo sensibles a la latencia en máquinas virtuales vSphere .
VMware, Inc. 43
Página 44
∎ Designe máquinas virtuales específicas como altamente sensibles a la latencia de la red.
vSphere le permite establecer la sensibilidad de latencia de red de una máquina virtual en Alta (desde el valor predeterminado
de Normal ). Esto hace que el programador intente asignar exclusivamente un núcleo de CPU físico para cada
vCPU en la máquina virtual. Si la asignación tiene éxito, la latencia y el jitter relacionados con la red son
reducido. Esto también significa, sin embargo, que los núcleos físicos asignados ya no están disponibles para otros
máquinas virtuales o mundos vmkernel.
Al configurar la sensibilidad de latencia de la red en un valor alto, tenga en cuenta estos puntos importantes adicionales:
∎ Antes de que la sensibilidad de latencia de la red se pueda establecer en un valor alto para una máquina virtual, la memoria para esa
La máquina debe reservarse al 100%.
∎ Puede asegurarse de que a la máquina virtual se le otorgue la asignación exclusiva de los núcleos de CPU que utiliza
establecer una reserva de CPU del 100% por adelantado. Si bien esto no es necesario para establecer la latencia
sensibilidad a alta, no hacerlo podría resultar en que la máquina virtual no obtenga acceso exclusivo a
las CPU físicas debido a un compromiso excesivo de CPU preexistente.
∎ Las reservas para los núcleos de la CPU y la memoria, así como la sensibilidad de latencia = configuración alta,
persisten cuando la máquina virtual se mueve a otros hosts mediante vMotion.
∎ Reserva completamente la memoria.
Además de ser necesario para usar latencia-sensibilidad = alta (como se describe arriba), reservando completamente
la memoria puede ayudar a reducir la latencia incluso cuando esa opción no está configurada.
∎ Reserve completamente las CPU.
Además de permitir que la latencia-sensibilidad = alta funcione de manera confiable (como se describe arriba), lo que genera una CPU completa
la reserva, incluso sin establecer latency-sensitividad = alta, puede ayudar a reducir la latencia de la red.
∎ Para reducir aún más la latencia y el jitter de una máquina virtual que se ha configurado en latencia-sensibilidad = alta y
tiene una reserva de CPU completa, también puede reservar núcleos de CPU exclusivamente para contextos de sistema relacionados utilizando
la opción sched.cpu.latencySensitivity.sysContexts ( Editar configuración > Opciones de VM > Opciones avanzadas
> Editar configuración ; si la opción no está presente, puede agregarla). Esta opción especifica el número de extra
núcleos para reservar exclusivamente para los contextos del sistema detectados por el programador de la CPU en relación con esta VM.
La afinidad exclusiva por los contextos del sistema se obtiene con el mejor esfuerzo y se puede desarmar automáticamente.
∎ Utilice SR-IOV o DirectPath I / O para tráfico sensible a la latencia.
Los adaptadores de red virtual como VMXNET3 y E1000 incurren en una sobrecarga de virtualización del orden de una
pocos microsegundos por paquete. Cuando esta sobrecarga no es deseable y ciertas funciones de virtualización básicas
no son necesarios, puede obtener una latencia de red más baja si proporciona acceso directo a la máquina virtual
al dispositivo de red mediante DirectPath I / O (“DirectPath I / O” en la página 40) o SR-IOV ( “Single Root I / O
Virtualización (SR-IOV) ” en la página 41) . En cualquier caso, también recomendamos ajustar la tasa de interrupción para el
dispositivo en el invitado.
El adaptador de red virtual VMXNET3 es la mejor opción si el acceso directo al dispositivo no está disponible o
indeseable (consulte “Consideraciones sobre la conexión en red del sistema operativo invitado” en la página 53) .
∎ Ajuste la configuración de administración de energía del host.
Algunas de las funciones de administración de energía en el hardware de servidor más nuevo pueden aumentar la latencia de la red. Si
deseado, puede desactivarlos de la siguiente manera:
∎ Configure la política de energía del host ESXi en Máximo rendimiento (como se describe en"Administración de energía del host
en ESXi ” en la página 24 ; este es el método preferido) o deshabilite la administración de energía en el BIOS (como
descrito en “Configuración del BIOS de administración de energía” en la página 17) .
∎ Deshabilite C1E y otros estados C en BIOS (como se describe en "Configuración de BIOS de administración de energía" en
página 17) .
∎ Habilite Turbo Boost en BIOS (como se describe en “Configuración general del BIOS” en la página 17) .
∎ Sintonice el adaptador de red virtual.
44 VMware, Inc.
Página 45
Para la mayoría de las aplicaciones de propósito general y para las aplicaciones sensibles a la latencia moderada, el
El adaptador de red virtual VMXNET3, dejado en su configuración predeterminada, proporcionará el mejor rendimiento.
Las aplicaciones con una tasa de paquetes baja o pocos subprocesos activos pueden beneficiarse al deshabilitar VMXNET3 virtual
interrumpir la fusión para la NIC deseada. En otros casos, sobre todo aplicaciones con un alto número de
solicitudes de red pendientes: deshabilitar la fusión de interrupciones puede reducir el rendimiento.
Para obtener más detalles sobre la fusión de interrupciones virtuales e instrucciones para cambiar su configuración, consulte
“Coalescencia de interrupciones de red virtual” en la página 43 .
Ajuste del rendimiento de todo el host

De forma predeterminada, ESXi admite índices de consolidación elevados y, al mismo tiempo, ofrece buenos tiempos de respuesta para todos los
máquina y cada solicitud individual. Sin embargo, existen escenarios en los que la capacidad de soportar
ratios de consolidación mientras se mantienen bajos los tiempos de respuesta promedio es más importante que mantener todas las respuestas
tiempos bajos. Una función introducida en vSphere 6.0, ajuste del rendimiento de todo el host (también llamado modo denso),
permite a los administradores del sistema optimizar hosts ESXi individuales para índices de consolidación tan altos (hasta
aproximadamente un 10% más alto que sin la función).
Cuando el modo denso está habilitado, ESXi monitorea la cantidad de máquinas virtuales, la cantidad de vCPU y el
Utilización de CPU; cuando los tres superan ciertos umbrales (numVMs> = numPCPUs, numvCPUs> = 2 *
numPCPUs y CPUUtil> = 50%) se implementan las optimizaciones del modo denso.
Las optimizaciones del modo denso esencialmente procesan paquetes de manera más agresiva en varios puntos. Esto principalmente
logra dos cosas:
∎ Reduce la sobrecarga del hipervisor para el procesamiento de paquetes
Una menor sobrecarga del hipervisor deja más recursos de CPU para las máquinas virtuales. Esto es beneficioso porque
cuando la utilización de la CPU es alta, el tiempo de respuesta promedio está muy influenciado por la disponibilidad de CPU de repuesto
recursos.
∎ Reduce la cantidad de interrupciones en la ejecución de la máquina virtual.
Reducir el número de interrupciones puede aumentar la eficiencia de las máquinas virtuales.
Debido a que el modo denso aumenta el procesamiento por lotes de paquetes, puede aumentar la latencia para solicitudes individuales. Debajo
condiciones de uso de CPU bajo, o cuando algunas máquinas virtuales consumen una cantidad desproporcionadamente grande
del rendimiento de la red, habilitar el modo denso podría reducir el rendimiento de todo el sistema (aunque también
reduciendo la utilización de CPU por unidad de rendimiento). Por lo tanto, recomendamos habilitar el modo denso solo en
aquellos hosts donde sus compensaciones serán útiles, en lugar de simplemente habilitarlo en todos los hosts.
Para habilitar o deshabilitar el modo denso, use vSphere Web Client (o esxcli) para cambiar el
/ Net / NetTuneHostMode de la siguiente manera:
∎ Modo denso deshabilitado (configuración predeterminada): / Net / NetTuneHostMode = "predeterminado"
∎ Modo denso habilitado: / Net / NetTuneHostMode = "denso"
N OTA Incluso cuando el modo denso está habilitado, las optimizaciones del modo denso se implementan solo cuando
El índice de consolidación del host y la utilización de la CPU alcanzan los umbrales descritos anteriormente.
VMware, Inc. 45
Página 46
46 VMware, Inc.
Página 47
Sistemas operativos invitados 3

Este capítulo proporciona orientación sobre los sistemas operativos invitados que se ejecutan en máquinas virtuales.
Consideraciones generales del sistema operativo invitado

∎ Utilice sistemas operativos invitados que sean compatibles con ESXi. Consulte la Guía de compatibilidad de VMware para
lista (vaya a http://www.vmware.com/resources/compatibility y luego, en Qué está buscando: elija
SO invitado ).
N OTA Es posible que VMware Tools no esté disponible para sistemas operativos invitados no compatibles.
∎ Instale la última versión de VMware Tools en el sistema operativo invitado. Asegúrese de actualizar VMware
Herramientas después de cada actualización de ESXi.
La instalación de VMware Tools en invitados de Windows actualiza el controlador BusLogic SCSI incluido con el invitado
sistema operativo al controlador proporcionado por VMware. El controlador de VMware tiene optimizaciones que
Los controladores de Windows proporcionados por el huésped no lo hacen.
VMware Tools también incluye el controlador de globo utilizado para la recuperación de memoria en ESXi. Globo
(descrito en "Técnicas de sobreasignación de memoria" en la página 27 ) no funcionará si VMware Tools no está
instalado.
∎ Deshabilite los protectores de pantalla y las animaciones de ventana en máquinas virtuales. En Linux, si el uso de un servidor X no
requerido, desactívelo. Los protectores de pantalla, las animaciones y los servidores X consumen recursos de CPU físicos adicionales,
afectando potencialmente los índices de consolidación y el rendimiento de otras máquinas virtuales.
∎ Programe copias de seguridad y programas de detección de virus en máquinas virtuales para que se ejecuten en horas de menor actividad. Evitar
programarlos para que se ejecuten simultáneamente en varias máquinas virtuales en el mismo host ESXi. En general,
Es una buena idea distribuir uniformemente el uso de la CPU, no solo entre las CPU, sino también a lo largo del tiempo. Para cargas de trabajo
como copias de seguridad y escaneo de virus, donde la carga es predecible, esto se logra fácilmente mediante la programación
los trabajos de forma adecuada.
∎ Para obtener la hora más precisa, considere configurar su sistema operativo invitado para usar NTP,
Servicio de hora de Windows, la opción de sincronización de hora de VMware Tools u otra utilidad de cronometraje
adecuado para su sistema operativo.
N OTA A partir de la versión incluida en ESXi 5.0, la opción de sincronización de hora de VMware Tools es una
elección. Las versiones anteriores a ESXi 5.0 no fueron diseñadas para el mismo nivel de precisión y no ajustan el
hora del invitado cuando se adelanta a la hora del anfitrión.
Sin embargo, recomendamos que dentro de cualquier máquina virtual en particular utilice VMware Tools
opción de sincronización de hora u otra utilidad de indicación de la hora, pero no ambas.
Para obtener información adicional sobre las mejores prácticas para el cronometraje dentro de las máquinas virtuales, consulte VMware KB
artículos 1318 y 1006427.
VMware, Inc. 47
Página 48
Medición del rendimiento en máquinas virtuales
Tenga cuidado al medir el rendimiento desde dentro de las máquinas virtuales.
∎ vSphere le permite aprovechar los contadores de rendimiento de CPU virtualizados para utilizar el rendimiento
herramientas de ajuste dentro del sistema operativo invitado. Para obtener más información, consulte la máquina virtual vSphere.
Guía de administración .
∎ Los números de tiempo medidos desde dentro de las máquinas virtuales pueden ser inexactos, especialmente cuando el procesador
está comprometido en exceso.
N OTA Un posible enfoque para este problema es utilizar un sistema operativo invitado que tenga un buen tiempo
comportamiento cuando se ejecuta en una máquina virtual, como un invitado que usa la opción de configuración del kernel NO_HZ
(a veces llamado "temporizador sin tictac"). Puede encontrar más información sobre este tema en
Máquinas virtuales VMware ( http://www.vmware.com/files/pdf/Timekeeping-In-VirtualMachines.pdf ).
∎ La medición del rendimiento desde dentro de las máquinas virtuales puede no tener en cuenta los recursos utilizados por ESXi.
para las tareas que descarga del sistema operativo invitado, así como los recursos consumidos por la virtualización
gastos generales.
Medir la utilización de recursos mediante herramientas a nivel de ESXi, como vSphere Web Client, VMware Tools,
esxtop, o resxtop, puede evitar estos problemas.
48 VMware, Inc.
Página 49
Capítulo 3 Sistemas operativos invitados
Consideraciones sobre la CPU del sistema operativo invitado

∎ En las máquinas virtuales SMP, el sistema operativo invitado puede migrar procesos de una vCPU a otra.
Esta migración puede generar una pequeña sobrecarga de CPU. Si la migración es muy frecuente, puede resultar útil
anclar subprocesos o procesos invitados a CPU virtuales específicas. (Tenga en cuenta que esta es otra razón para no configurar
máquinas con más CPU virtuales de las que necesitan).
∎ Muchos sistemas operativos mantienen el tiempo contando las interrupciones del temporizador. Las tasas de interrupción del temporizador varían entre
diferentes sistemas operativos y versiones. Por ejemplo:
∎ Los kernels de Linux posteriores a la versión 2.6 admiten la opción de configuración del kernel NO_HZ (a veces llamada
"Temporizador sin tic") que utiliza una tasa de interrupción variable del temporizador. Versiones 2.6 y anteriores del kernel de Linux
normalmente solicitan una frecuencia de temporizador fija, como 100 Hz, 250 Hz o 1000 Hz.
∎ Las tasas de interrupción del temporizador del sistema operativo Microsoft Windows son específicas de la versión de Microsoft.
Windows y la HAL de Windows que está instalada. Los sistemas Windows suelen utilizar un temporizador base
tasa de interrupción de 64 Hz o 100 Hz.
∎ La ejecución de aplicaciones que utilizan la función de temporizador multimedia de Microsoft Windows puede
aumente la tasa de interrupción del temporizador. Por ejemplo, algunas aplicaciones multimedia o aplicaciones Java
aumente la tasa de interrupción del temporizador a aproximadamente 1000 Hz.
Además de la tasa de interrupciones del temporizador, el número total de interrupciones del temporizador entregadas a una máquina virtual
también depende de otros factores:
∎ Máquinas virtuales que ejecutan HAL / kernels SMP (incluso si se ejecutan en una máquina virtual UP)
requieren más interrupciones de temporizador que las que ejecutan UP HAL / kernels (consulte "UP vs. SMP HAL / Kernels"
en la página 21 para obtener más información sobre HAL / kernels).
∎ Cuantas más vCPU tenga una máquina virtual, más interrupciones requerirá.
La entrega de muchas interrupciones del temporizador virtual afecta negativamente el rendimiento de la máquina virtual y aumenta
consumo de CPU del host. Si tiene la opción, use sistemas operativos invitados que requieran menos temporizador
interrumpe. Por ejemplo:
∎ Si tiene una máquina virtual UP, utilice UP HAL / kernel (consulte “UP vs SMP HAL / Kernels” en la página 21
para obtener más información sobre HAL / kernels).
∎ En algunas versiones de Linux, como RHEL 5.1 y posteriores, el parámetro de arranque del kernel "divider = 10" reduce
la tasa de interrupción del temporizador a una décima parte de su tasa predeterminada. Consulte el artículo 1006427 de VMware KB para obtener más información.
información.
∎ Los kernels con soporte de temporizador tickless (kernels NO_HZ) no programan temporizadores periódicos para mantener
hora del sistema. Como resultado, estos núcleos reducen la tasa promedio general de interrupciones del temporizador virtual, por lo tanto
mejorar el rendimiento y la escalabilidad del sistema en hosts que ejecutan una gran cantidad de máquinas virtuales.
Para obtener información general sobre el tema de las interrupciones del temporizador, consulte Indicación de la hora en máquinas virtuales .
VMware, Inc. 49
Página 50
NUMA virtual (vNUMA)

Virtual NUMA (vNUMA) expone la topología NUMA al sistema operativo invitado, lo que permite el reconocimiento de NUMA
sistemas operativos y aplicaciones invitados para hacer el uso más eficiente de la NUMA del hardware subyacente
arquitectura.
N OTA Para obtener más información sobre NUMA, consulte“Acceso a memoria no uniforme (NUMA)” en la página 22 .
Virtual NUMA, que requiere hardware virtual versión 8 o posterior, en algunos casos puede proporcionar importantes
beneficios de rendimiento para máquinas virtuales amplias (como se define en "Acceso a memoria no uniforme (NUMA)" en
página 22 ), aunque los beneficios dependen en gran medida del nivel de optimización NUMA en la operación de invitado.
sistema y aplicaciones.
∎ Puede obtener los máximos beneficios de rendimiento de vNUMA si sus clústeres están compuestos completamente
de hosts con arquitectura NUMA coincidente.
Esto se debe a que la primera vez que se enciende una máquina virtual habilitada para vNUMA, su vNUMA
La topología se establece basándose en parte en la topología NUMA del host físico subyacente en el que se
corriendo. De forma predeterminada, una vez que se inicializa la topología vNUMA de una máquina virtual, no cambia a menos que
se cambia la cantidad de vCPU en esa máquina virtual. Esto significa que si una máquina virtual vNUMA está
movido a un host con una topología NUMA diferente, es posible que la topología vNUMA de la máquina virtual no
ya sea óptimo para la topología física subyacente NUMA, lo que podría resultar en una reducción
actuación.
∎ Al dimensionar sus máquinas virtuales, tenga en cuenta el tamaño de los nodos físicos NUMA:
N OTA Algunos procesadores de varios núcleos tienen tamaños de nodo NUMA que son diferentes a la cantidad de núcleos
por enchufe. Por ejemplo, algunos procesadores de 12 núcleos tienen dos nodos NUMA de seis núcleos por procesador.
∎ Para obtener el mejor rendimiento, intente dimensionar sus máquinas virtuales para que permanezcan dentro de un nodo físico NUMA.
Por ejemplo, si tiene un sistema host con seis núcleos por nodo NUMA, intente dimensionar su
máquinas con no más de seis vCPU.
∎ Cuando una máquina virtual necesita ser más grande que un solo nodo físico NUMA, intente dimensionarla de manera que
se puede dividir uniformemente en el menor número posible de nodos NUMA físicos.
∎ Tenga cuidado al crear una máquina virtual que tenga un recuento de CPU virtuales que supere el
el núcleo del procesador cuenta con un host. Dado que los hiperprocesos se consideran subprocesos lógicos, esto es
a veces es permisible, pero potencialmente creará contención cuando se use.
∎ A partir de vSphere 6.5, cambiar el valor de corespersocket ya no influye en vNUMA o

configuración de la topología vNUMA. La configuración de vSockets y corespersocket ahora solo
afecta la presentación de los procesadores virtuales al sistema operativo invitado, algo potencialmente relevante para
licencias de software. vNUMA determinará automáticamente la topología de vNUMA adecuada para presentar al
SO invitado basado en el host ESXi subyacente.
Por ejemplo: antes de vSphere 6.5, si crea una máquina virtual de cuatro vSocket y establece corespersocket
a cuatro (para un total de 16 vCPU) en un host ESXi físico de dos sockets con 16 núcleos por socket (para un total de
32 núcleos físicos), vNUMA habría creado cuatro nodos vNUMA basados en el corespersocket
ajuste. En vSphere 6.5, el sistema operativo invitado seguirá viendo cuatro sockets y cuatro núcleos por socket, pero vNUMA
ahora cree solo un nodo vNUMA de 16 núcleos para toda la máquina virtual porque esa máquina virtual puede
colocarse en un único nodo físico NUMA.
Este nuevo desacoplamiento de la configuración de corespersocket de vNUMA permite que vSphere

Determine la mejor topología de vNUMA.
Para revertir este comportamiento y controlar directamente la topología de vNUMA, consulte la

configuración de numa.vcpu.followcorespersocket en la sección "Controles virtuales de NUMA" de vSphere 6.5
Guía de gestión de recursos .
50 VMware, Inc.
Página 51
∎ De forma predeterminada, vNUMA está habilitado solo para máquinas virtuales con más de ocho vCPU. Esta característica puede
habilitado para máquinas virtuales más pequeñas, sin embargo, al mismo tiempo que permite que ESXi administre automáticamente
Topología vNUMA. Esto puede resultar útil para máquinas virtuales amplias (es decir, máquinas virtuales con más
CPU virtuales que la cantidad de núcleos en cada nodo físico NUMA) con ocho o menos CPU virtuales.
Puede habilitar vNUMA para máquinas virtuales con ocho o menos vCPU agregando al archivo .vmx el
línea:
numa.vcpu.min = X
(donde X es el número de vCPU en la máquina virtual).
N OTA Este cambio se puede realizar a través de vSphere Web Client:
1 Seleccione la máquina virtual que desea cambiar.
2 En la pestaña Configurar , expanda Configuración , luego seleccione Opciones de VM
4 Expanda Avanzado , luego en Parámetros de configuración haga clic en Editar configuración .
5 Busque numa.vcpu.min y configúrelo como desee. Si la variable no está presente, introdúzcala como nueva
variable y haga clic en Agregar .
6 Haga clic en Aceptar para cerrar la ventana Parámetros de configuración .
7 Haga clic en Aceptar para cerrar la ventana Editar configuración .
Alternativamente, puede tomar el control manual total de la topología vNUMA de una máquina virtual usando el
Opción maxPerVirtualNode. Para obtener más detalles, consulte la sección "Controles virtuales de NUMA" de vSphere
6.5 Guía de gestión de recursos .
VMware, Inc. 51
Página 52
Consideraciones sobre el almacenamiento del sistema operativo invitado

El adaptador de almacenamiento virtual presentado al sistema operativo invitado puede influir en el rendimiento del almacenamiento, al igual que
ese controlador de dispositivo, la configuración del controlador y otros factores dentro del invitado. Esta sección aborda aquellos
consideraciones.
∎ Para la mayoría de los sistemas operativos invitados, el adaptador de almacenamiento virtual predeterminado en ESXi 6.5 es LSI Logic
Paralelo o LSI Logic SAS, según el sistema operativo invitado y la versión del hardware virtual.
Sin embargo, ESXi también incluye un adaptador de almacenamiento SCSI paravirtualizado, PVSCSI (también llamado VMware
Paravirtual). El adaptador PVSCSI ofrece una reducción significativa en la utilización de la CPU, así como potencialmente
mayor rendimiento en comparación con los adaptadores de almacenamiento virtual predeterminados y, por lo tanto, es la mejor opción para
entornos con aplicaciones de invitado con un uso intensivo de E / S.
N OTA Para utilizar PVSCSI, su máquina virtual debe utilizar la versión 7 o posterior de hardware virtual, como
descrito bajo “Consideraciones generales de ESXi” en la página 19.
N OTA Los adaptadores PVSCSI son compatibles con unidades de arranque solo en algunos sistemas operativos. Para adicional
Consulte el artículo 1010398 de VMware KB.
∎ Si elige usar el adaptador SCSI virtual BusLogic Parallel y está usando un invitado operativo de Windows
sistema, debe utilizar el controlador BusLogic personalizado incluido en el paquete VMware Tools.
∎ vSphere 6.5 presenta un adaptador de almacenamiento virtual Non-Volatile Memory Express (NVMe) (NVMe virtual,
o vNVMe). Esto permite que los sistemas operativos invitados recientes que incluyen un controlador NVMe nativo utilicen ese
controlador para acceder al almacenamiento a través de ESXi, ya sea que ESXi esté utilizando o no almacenamiento NVMe.
Debido a que el adaptador de almacenamiento virtual vNVMe ha sido diseñado para flash de latencia extremadamente baja y
almacenamiento basado en memoria no volátil, no es el más adecuado para cargas de trabajo de E / S altamente paralelas y discos lentos
almacenamiento. Para cargas de trabajo que principalmente tienen E / S pendientes bajas, especialmente cargas de trabajo sensibles a la latencia,
vNVMe normalmente funcionará bastante bien. En comparación con los dispositivos SATA virtuales, el almacenamiento virtual vNVMe
Los adaptadores acceden a dispositivos SSD PCIe locales con un costo de CPU por E / S significativamente menor y significativamente mayor
IOPS.
∎ La profundidad de la cola de comandos pendientes en el controlador SCSI del sistema operativo invitado puede
impacta significativamente el rendimiento del disco. Una profundidad de cola que es demasiado pequeña, por ejemplo, limita el disco
ancho de banda que se puede enviar a través de la máquina virtual. Consulte la documentación específica del controlador para
más información sobre cómo ajustar estas configuraciones.
∎ En algunos casos, el invitado puede dividir grandes solicitudes de E / S emitidas por aplicaciones en una máquina virtual
controlador de almacenamiento. Cambiar la configuración del registro del sistema operativo invitado para emitir bloques de mayor tamaño puede
eliminar esta división, mejorando así el rendimiento. Para obtener información adicional, consulte el artículo de la base de conocimiento de VMware
9645697.
∎ Asegúrese de que las particiones del disco dentro del invitado estén alineadas. Para obtener más información, es posible que desee
Consulte la literatura del proveedor del sistema operativo con respecto a las herramientas apropiadas para usar, así como
recomendaciones del proveedor de matrices.
52 VMware, Inc.
Página 53
Consideraciones de red del sistema operativo invitado

Cuando se crea una máquina virtual por primera vez, ESXi permite la selección del adaptador de red virtual (vNIC) que utilizará.
Las opciones disponibles se basan en el sistema operativo invitado especificado y la versión de hardware virtual.
Debido a que algunos sistemas operativos no tienen controladores integrados para los adaptadores de red virtual de mejor rendimiento,
la lista de vNIC disponibles no siempre incluirá aquellas que podrían proporcionar el mejor rendimiento. En algunos de
Sin embargo, en estos casos, se puede instalar un controlador posteriormente en el sistema operativo invitado (normalmente como parte de VMware
Tools) y la vNIC luego cambió a un tipo diferente.
Esta sección describe los distintos tipos de vNIC, cómo seleccionar uno y cómo obtener el mejor rendimiento
de eso.
Tipos de adaptadores de red virtual

Los posibles adaptadores de red virtual incluyen tres tipos emulados, tres tipos paravirtualizados y un híbrido
adaptador.
Los adaptadores de red virtual emulados son:
∎ El adaptador de red virtual Vlance, que emula una NIC AMD 79C970 PCnet32. Controladores para esta NIC
se encuentran en la mayoría de los sistemas operativos de 32 bits.
∎ El adaptador de red virtual E1000, que emula una NIC Intel 82545EM. Se encuentran los controladores para esta NIC
en muchos sistemas operativos recientes.
∎ El adaptador de red virtual E1000e, que emula una NIC Intel 82574. Se encuentran los controladores para esta NIC
en un conjunto más pequeño de sistemas operativos recientes.
La familia VMXNET de adaptadores de red paravirtualizados proporciona un mejor rendimiento en la mayoría de los casos que el
adaptadores emulados. Estos adaptadores de red paravirtualizados implementan una interfaz de red idealizada que
pasa el tráfico de red entre la máquina virtual y la tarjeta de interfaz de red física con un mínimo
gastos generales. Los adaptadores de red virtual VMXNET (especialmente VMXNET3) también ofrecen características de rendimiento que no
que se encuentran en los otros adaptadores de red virtual. Los controladores para los adaptadores de la familia VMXNET están disponibles para muchos
sistemas operativos invitados compatibles con ESXi; Para un rendimiento óptimo, estos adaptadores deben utilizarse para cualquier
sistema operativo invitado que los admite.
La familia VMXNET incluye:
∎ El adaptador de red virtual VMXNET.
∎ El adaptador de red virtual VMXNET2 (también llamado "VMXNET mejorado"). Basado en VMXNET
adaptador, este adaptador agrega una serie de características de rendimiento.
∎ El adaptador de red virtual VMXNET3 (también llamado VMXNET Generation 3). Este adaptador tiene todas las
características de VMXNET2, junto con varias nuevas.
Por último, hay un adaptador de red virtual híbrido:
∎ El adaptador de red virtual flexible, que comienza emulando un adaptador Vlance, pero puede funcionar como un
Adaptador VMXNET con el controlador adecuado.
En algunos casos, las opciones del adaptador de red virtual incluirán el paso a través de SR-IOV . Para obtener información sobre este
característica, ver “Virtualización de E / S de raíz única (SR-IOV)” en la página 41 .
N OTA Las velocidades de red informadas por el controlador de red invitado en la máquina virtual no reflejan la
velocidad real de la tarjeta de interfaz de red física subyacente. Por ejemplo, el controlador invitado de Vlance en un
La máquina virtual informa una velocidad de 10 Mb / s porque la tarjeta AMD PCnet que ESXi está emulando es de 10 Mb / s.
dispositivo. Esto es cierto incluso si la tarjeta física del servidor es de 100 Mb / s, 1 Gb / so más rápida. Sin embargo, ESXi no es
limitado a 10 Mb / s en esta situación y transfiere paquetes de red tan rápido como los recursos en el servidor físico
permitir la máquina.
Para obtener más información sobre los adaptadores de red virtual, consulte el artículo 1001805 de VMware KB y Virtual Machine
Administración de vSphere 6.5.
VMware, Inc. 53
Página 54
Selección de adaptadores de red virtual

Esta sección describe cómo seleccionar adaptadores de red virtual para obtener el mejor rendimiento.
∎ Para obtener el mejor rendimiento, utilice el adaptador de red paravirtualizado VMXNET3 para sistemas operativos en
que es compatible. Esto requiere que la máquina virtual use hardware virtual versión 7 o posterior y,
en algunos casos, requiere que VMware Tools esté instalado en el sistema operativo invitado.
N OTA Una máquina virtual con un dispositivo VMXNET3 no puede vMotion a un host que ejecuta ESX / ESXi 3.5.xo
más temprano.
∎ Para los sistemas operativos invitados en los que VMXNET3 no es compatible, o si no desea utilizar virtual
versión de hardware 7 o posterior (para mantener la compatibilidad de vMotion con versiones anteriores de ESX / ESXi, para
ejemplo), el mejor rendimiento se puede obtener con el uso de VMXNET2 para sistemas operativos en los que
es compatible. Esto generalmente requiere que VMware Tools esté instalado en el sistema operativo invitado.
N OTA Una máquina virtual con un dispositivo VMXNET2 no puede realizar vMotion en un host que ejecuta ESX 3.0.xo anterior.
∎ Para los sistemas operativos en los que no se admite VMXNET2, utilice el tipo de dispositivo flexible. En ESXi, el
"NIC flexible" convierte automáticamente cada dispositivo de red Vlance en un dispositivo VMXNET (un proceso también
denominado "NIC Morphing") si el conjunto de VMware Tools está instalado en el sistema operativo invitado y el
El sistema operativo es compatible con VMXNET.
Características y configuración del adaptador de red virtual

Esta sección describe varias características del adaptador de red virtual y cómo configurar los adaptadores para el mejor
actuación.
∎ Al conectar en red dos máquinas virtuales en el mismo host ESXi, intente conectarlas al mismo vSwitch.
Cuando se conectan de esta manera, sus velocidades de red no están limitadas por la velocidad del cable de ninguna red física.
tarjeta. En cambio, transfieren paquetes de red tan rápido como lo permiten los recursos del host.
∎ Los dispositivos E1000, E1000e, VMXNET2 y VMXNET3 admiten tramas gigantes. El uso de marcos jumbo
puede permitir que los datos se transmitan utilizando paquetes más grandes y, por lo tanto, menos. Porque gran parte de la carga de la CPU
debido a que el tráfico de red es una sobrecarga por paquete, una tasa de paquetes más baja puede reducir la carga de la CPU y, por lo tanto
aumentar el rendimiento.
Para habilitar las tramas gigantes, configure el tamaño de MTU en 9000 tanto en el controlador de red de invitados como en el conmutador virtual
configuración. Las NIC físicas en ambos extremos y todos los saltos / enrutadores / conmutadores intermedios también deben
admite marcos jumbo.
∎ En ESXi TCP Segmentation Offload (TSO) está habilitado de forma predeterminada en VMkernel pero es compatible con virtual
máquinas sólo cuando están usando el dispositivo E1000, el dispositivo E1000e, el dispositivo VMXNET2 o el
Dispositivo VMXNET3. TSO puede mejorar el rendimiento incluso si el hardware subyacente no es compatible con TSO.
∎ De manera similar, en ESXi, la descarga de recepción grande (LRO) está habilitada de manera predeterminada en VMkernel, pero es compatible con
máquinas virtuales solo cuando están usando el dispositivo VMXNET2 o el dispositivo VMXNET3. LRO podría
mejorar el rendimiento incluso si el hardware subyacente no es compatible con LRO.
N OTA La compatibilidad con LRO varía según el sistema operativo. Muchas variantes de Linux admiten LRO. En Windows virtual
Se admite LRO de máquinas cuando se cumplen los siguientes requisitos previos:
∎
La máquina virtual usa hardware virtual versión 11 o posterior.
∎ La máquina virtual utiliza el dispositivo VMXNET3.
∎ La máquina virtual ejecuta Windows Server 2012 o posterior o Windows 8.0 o posterior.
∎ El sistema operativo invitado usa el controlador VMXNET3 vNIC versión 1.6.6.0 o posterior.
∎ La fusión de segmentos de recepción (RSC) está habilitada globalmente en el sistema operativo invitado.
Para obtener más información sobre la configuración de LRO, busque "Descarga de recepción grande" en vSphere Networking
para vSphere 6.5.
54 VMware, Inc.
Página 55
∎ En algunos casos, el bajo rendimiento de recepción en una máquina virtual puede deberse a búferes de recepción insuficientes (también
descrito como un anillo de recepción desbordado), en el dispositivo de red del receptor. Si el búfer de recepción en el invitado
El controlador de red del sistema operativo es insuficiente, los paquetes se eliminarán en el VMkernel, degradando
rendimiento de la red. Una posible solución es aumentar el número de búferes de recepción, aunque esto
podría aumentar la carga de trabajo de la CPU física del host.
Para VMXNET, el número predeterminado de búferes de recepción y transmisión es 100 cada uno, con el máximo posible
siendo 128. Para VMXNET2, el número predeterminado de búferes de recepción y transmisión son 150 y 256,
respectivamente, siendo 512 el máximo posible de búferes de recepción. Puede modificar estos ajustes
cambiar los valores predeterminados del tamaño del búfer en los archivos .vmx (configuración) de las máquinas virtuales afectadas. por
Para obtener más información, consulte el artículo 1010071 de VMware KB.
Para E1000, E1000e y VMXNET3, el número predeterminado de búferes de recepción y transmisión está controlado por
el controlador invitado, siendo el máximo posible para ambos 4096. En Linux, estos valores se pueden cambiar
desde dentro del huésped mediante el uso de ethtool. En Windows, los valores se pueden cambiar desde dentro del invitado
en la ventana de propiedades del dispositivo. Para obtener información adicional, consulte el artículo 1010071 de la base de conocimiento de VMware.
∎ Varias colas de recepción y transmisión (a menudo denominadas escalado del lado de recepción (RSS) o E / S escalable) permiten
paquetes de red de una sola NIC que se programarán en paralelo en varias CPU. Sin múltiples
colas, las interrupciones de la red se pueden manejar solo en una CPU a la vez. Varias colas ayudan al rendimiento
en los casos en que una sola CPU se saturaría con el procesamiento de paquetes de red y se convertiría
un cuello de botella. Para evitar la entrega de paquetes fuera de orden, el controlador programa todos los paquetes de un flujo al
misma CPU.
Los dispositivos E1000e y VMXNET3 admiten varias colas para muchos sistemas operativos invitados que
Admite de forma nativa la función, que incluye Windows Server 2003 SP2 o posterior, Windows 7 o posterior, y
algunas distribuciones de Linux.
Los controladores VMXNET3 incluidos con vSphere 5.0 y versiones posteriores de VMware Tools están predeterminados
tener múltiples colas de recepción habilitadas, al igual que el controlador VMXNET3 incluido con el kernel de Linux 2.6.37
y después. Para obtener más información, consulte el artículo 2020567 de VMware KB.
Cuando se habilitan varias colas de recepción, la función configura por defecto 1, 2, 4 u 8 colas de recepción en
una máquina virtual, eligiendo el mayor de estos valores menor o igual a la cantidad de vCPU en ese
máquina virtual.
En Windows, independientemente del número de colas de recepción, el número de colas de transmisión se establece de forma predeterminada en 1. Si
el controlador también está configurado para usar múltiples colas de transmisión, el número de colas de transmisión será el
igual que el número de colas de recepción.
En Linux, el número de colas de transmisión, por defecto, es el mismo que el número de colas de recepción.
colas.
Para obtener el máximo rendimiento con sus cargas de trabajo específicas y disponibilidad de recursos,
puede probar diferentes valores para el número de colas de recepción (que deben establecerse en una potencia de 2 y pueden
debe ser un máximo de 8 o la cantidad de vCPU, lo que sea menor), y puede intentar configurar el controlador
utilizar múltiples colas de transmisión (excepto en Linux, donde el número de colas de transmisión ya
coincidir con el número de colas de recepción). Esta configuración se cambia en la configuración avanzada del controlador
pestaña dentro del sistema operativo invitado.
VMware, Inc. 55
Página 56
56 VMware, Inc.
Página 57
Gestión de infraestructura virtual 4

Este capítulo proporciona orientación sobre las mejores prácticas de gestión de la infraestructura. La mayoría de las sugerencias
incluido en esta sección se puede implementar utilizando un vSphere Web Client conectado a un VMware vCenter
Servidor. Algunos también se pueden implementar mediante vSphere Host Client conectado a un host ESXi individual.
Se pueden encontrar más detalles sobre muchos de estos temas, así como información de fondo, en VMware
Informe técnico de vCenter Server Performance and Best Practices .
Gestión general de recursos

ESXi proporciona varios mecanismos para configurar y ajustar la asignación de recursos de memoria y CPU para
máquinas virtuales que se ejecutan dentro de él. Las configuraciones de gestión de recursos pueden tener un impacto significativo en
rendimiento de la máquina virtual.
Esta sección enumera las prácticas y configuraciones de administración de recursos recomendadas por VMware para
actuación.
∎ Utilice la configuración de recursos (es decir, reserva , recursos compartidos y límites ) solo si es necesario en su entorno.
∎ Si espera cambios frecuentes en el total de recursos disponibles, use Acciones , no Reserva , para asignar
recursos de forma justa en las máquinas virtuales. Si usa recursos compartidos y posteriormente actualiza el hardware,
cada máquina virtual permanece en la misma prioridad relativa (mantiene la misma cantidad de recursos compartidos) aunque
cada recurso representa una mayor cantidad de memoria o CPU.
∎ Utilice Reserva para especificar la cantidad mínima aceptable de CPU o memoria, no la cantidad que
quisiera tener disponible. Una vez que se han cumplido todas las reservas de recursos, ESXi asigna el resto
recursos basados en la cantidad de recursos compartidos y los límites de recursos configurados para su máquina virtual.
Como se indicó anteriormente, las reservas se pueden utilizar para especificar la CPU y la memoria mínima reservadas para cada
máquina virtual. A diferencia de las acciones, la cantidad de recursos concretos representados por una reserva no
no cambiar cuando cambie el entorno, por ejemplo, agregando o quitando máquinas virtuales.
No establezca la Reserva demasiado alta. Una reserva demasiado alta puede limitar la cantidad de máquinas virtuales que
puede encenderse en un grupo de recursos, clúster o host.
Al especificar las reservas para máquinas virtuales, siempre deje algo de espacio para la memoria
sobrecarga de virtualización (como se describe en “Consideraciones sobre la memoria de ESXi” en la página 26 ) y migración
gastos generales. En un clúster habilitado para DRS, las reservas que comprometen completamente la capacidad del clúster o de
Los hosts individuales en el clúster pueden evitar que DRS migre máquinas virtuales entre hosts. Como tu
enfoque reservando completamente toda la capacidad en el sistema, también se vuelve cada vez más difícil hacer cambios
a las reservas y a la jerarquía del grupo de recursos sin violar el control de admisión.
∎ Utilice grupos de recursos para la gestión delegada de recursos. Para aislar completamente un grupo de recursos, haga
tipo de grupo de recursos Fijo y uso Reserva y límite .
∎ Agrupe máquinas virtuales para un servicio de varios niveles en un grupo de recursos. Esto permite asignar recursos
para el servicio en su conjunto.
VMware, Inc. 57
Página 58
VMware vCenter
Esta sección enumera las prácticas y configuraciones de VMware vCenter recomendadas para un rendimiento óptimo. También
incluye algunas funciones que se controlan o se accede a través de vCenter.
∎ Ya sea que se ejecute en máquinas virtuales o sistemas físicos, asegúrese de proporcionar vCenter Server y el
Base de datos de vCenter Server con suficientes recursos de CPU, memoria y almacenamiento (capacidad y
rendimiento) para el tamaño de su implementación. Para obtener información adicional, consulte la versión 6.5 de vSphere
Instalación y configuración .
∎ Debido a la importancia de la base de datos para el rendimiento de vCenter, asegúrese de seguir las
recomendaciones en “Consideraciones sobre la base de datos de VMware vCenter” en la página 59 .
∎ El rendimiento de vCenter Server depende en gran parte de la cantidad de entidades administradas (hosts
y máquinas virtuales) y la cantidad de vSphere Web Clients conectados. Superando los máximos
especificado en los máximos de configuración para vSphere 6.5 , además de no ser compatible, es probable que
afectar el rendimiento de vCenter Server.
∎ Para minimizar la latencia de las operaciones de vCenter, mantenga al mínimo el número de saltos de red entre
el sistema vCenter Server y la base de datos de vCenter Server.
∎ Tenga en cuenta, además, que la latencia de la red entre vCenter Server y los hosts que administra puede afectar la
realización de operaciones que involucren a esos hosts
∎ VMware vSphere Update Manager, cuando se implementa en Windows, se puede ejecutar en el mismo sistema y
use la misma base de datos que vCenter Server pero, para obtener el máximo rendimiento en vCenter con mucha carga
sistemas, considere ejecutar Update Manager en su propio sistema y proporcionarle un
base de datos. (Tenga en cuenta que esto no se aplica a vSphere Update Manager en Linux, es decir, con vCenter
Dispositivo servidor) Para obtener información adicional, consulte “VMware vSphere Update Manager” en la página 81 .
∎ Durante la instalación de VMware vCenter, se le pedirá que elija un tamaño de inventario de destino. Esta elección
se utilizará para establecer los tamaños máximos de memoria de pila de la máquina virtual Java (JVM) para varios servicios. los
valores predeterminados (detallados en la versión 6.5 de vSphere Installation and Setup ; busque “Tomcat Server
settings ”) debe proporcionar un buen rendimiento y evitar un compromiso de memoria innecesario. Si tu
tendrá tamaños de inventario dentro del amplio rango (como se define en la versión 6.5 de vSphere Installation y
Configuración ; busque "vCenter Server para requisitos de hardware de Windows"), sin embargo, puede obtener
mejor rendimiento aumentando una o más de estas configuraciones.
58 VMware, Inc.
Página 59
Capítulo 4 Gestión de la infraestructura virtual
Consideraciones sobre la base de datos de VMware vCenter

vCenter Server depende en gran medida de una base de datos para almacenar información de configuración sobre elementos de inventario y
datos de estadísticas de rendimiento. También almacena datos sobre alarmas, eventos y tareas. Debido a la importancia de este
base de datos a la confiabilidad y el rendimiento de su vCenter Server, VMware recomienda la base de datos
prácticas descritas en esta sección.
Consideraciones de almacenamiento y red de base de datos de VMware vCenter
∎ Para minimizar la latencia de las operaciones entre vCenter Server y la base de datos, mantenga al mínimo la
número de saltos de red entre el sistema vCenter Server y el sistema de base de datos.
∎ El hardware en el que se almacena la base de datos de vCenter y la disposición de los archivos en ese hardware,
puede tener un efecto significativo en el rendimiento de vCenter:
∎ La base de datos de vCenter funciona mejor cuando sus archivos se colocan en un almacenamiento de alto rendimiento.
∎ Los archivos de datos de la base de datos generan principalmente tráfico de E / S de escritura aleatoria, mientras que los registros de transacciones de la base de datos
generar principalmente tráfico de E / S de escritura secuencial. Por esta razón, y porque su tráfico es a menudo
significativo y simultáneo, vCenter funciona mejor cuando estos dos tipos de archivos se colocan en
recursos de almacenamiento que no comparten discos ni ancho de banda de E / S.
∎ Si la base de datos de vCenter se coloca en un almacenamiento de aprovisionamiento grueso o de aprovisionamiento diferido, vCenter
el inicio puede ser más lento de lo que sería si se coloca en un almacenamiento de aprovisionamiento grueso con cero ansioso. Ver"Virtual
Tipos de disco ” en la página 33 para obtener más información sobre estos tipos de aprovisionamiento.
∎ Las grandes implementaciones pueden generar rápidamente cantidades importantes de datos. Es una buena práctica periódicamente
supervise el almacenamiento de la base de datos para evitar quedarse sin espacio de almacenamiento. Para obtener información sobre cómo configurar una alerta
para esto en vCenter Server Appliance, consulte el artículo 2058187 de la base de conocimiento de VMware.
Configuración y mantenimiento de la base de datos de VMware vCenter
∎ Configure el nivel de estadísticas de vCenter en una configuración adecuada para sus usos. Esta configuración puede oscilar entre 1
a 4, pero se recomienda un ajuste de 1 para la mayoría de situaciones. Una configuración más alta puede ralentizar el vCenter Server
sistema. También puede deshabilitar de forma selectiva los resúmenes de estadísticas para niveles de recopilación específicos.
Cuando necesite niveles más altos (para la depuración interactiva, por ejemplo), aumente solo el nivel
temporalmente y vuelva a colocarlo en un nivel más bajo cuando termine.
Para obtener más información sobre este tema, consulte Mejoras en el rendimiento de la base de datos de VMware vCenter 5.1 y
Prácticas recomendadas para entornos a gran escala (aunque este documento aborda específicamente vSphere 5.1, la mayoría de
los conceptos son aplicables a vSphere 6.5).
∎ Para evitar cambios frecuentes en el registro de transacciones, asegúrese de que los registros de la base de datos de vCenter tengan el tamaño
apropiadamente para su inventario de vCenter. Por ejemplo, con un gran inventario de vCenter que se ejecuta con un
Base de datos Oracle, el tamaño de cada registro de rehacer debe ser de al menos 1 GB.
∎ vCenter Server se inicia con un grupo de conexiones de base de datos de 50 subprocesos. Este grupo es entonces dinámicamente
tamaño, creciendo de forma adaptativa según sea necesario en función de la carga de trabajo de vCenter Server, y no requiere
modificación. Sin embargo, si se espera una gran carga de trabajo en vCenter Server, el tamaño de este grupo en
el inicio se puede aumentar, con un máximo de 128 subprocesos. Tenga en cuenta que esto puede resultar en un aumento
consumo de memoria de vCenter Server y un inicio más lento de vCenter Server.
Para cambiar el tamaño del grupo, edite el archivo vpxd.cfg, agregando:

<vpxd>
<odbc>
<maxConnections> xxx </maxConnections>
</odbc>
</vpxd>
(donde xxx es el tamaño de piscina deseado).
N OTA Si realiza este cambio en el tamaño del grupo de vCenter, también debe considerar aumentar su
conexiones máximas permitidas de la base de datos.
VMware, Inc. 59
Página 60
∎ Actualice las estadísticas de las tablas e índices de forma periódica para un mejor rendimiento general de la
base de datos.
∎ Como parte de la actividad de mantenimiento regular de la base de datos, verifique la fragmentación de los objetos de índice y
vuelva a crear índices si es necesario (es decir, si la fragmentación es superior al 30% aproximadamente).
∎ Top N es una función de vCenter que le permite ver los principales consumidores de ciertos recursos (CPU, memoria,
disco y red) en forma de gráfico (en vSphere Web Client, seleccione un clúster o host, elija Monitor
pestaña, elija Rendimiento , haga clic en Descripción general , luego seleccione Grupos de recursos y máquinas virtuales , hosts o
Máquinas virtuales ). El cálculo de los datos de Top N impone una pequeña carga adicional en vCenter
base de datos. Si bien esperamos que esta carga sea insignificante en la mayoría de las circunstancias, la función se puede desactivar si
deseado. La desactivación de la función solo daría como resultado que los gráficos Top N estuvieran en blanco. Si desea desactivarlo,
sigue estos pasos:
∎ En Microsoft SQL Server: desde el Agente SQL Server, desactive el trabajo de tablas * TOPN * .
∎ En Oracle: use el paquete DBMS_JOB.BROKEN para deshabilitar el trabajo de tablas * TOPN * .
N OTA No hay ninguna opción para deshabilitar la función Top N cuando se usa la base de datos vPostgres (utilizada por
vCenter Server si selecciona la opción de base de datos incorporada durante la implementación).
Si luego desea volver a habilitar Top N, espere hasta que se borren todas las sesiones de la base de datos y la base de datos esté
volver a su estado normal, luego vuelva a habilitar el trabajo.
Recomendaciones para proveedores de bases de datos específicos
Esta subsección describe las recomendaciones específicas de la base de datos.
Recomendaciones de la base de datos de PostgreSQL (vPostgres)
Si está utilizando una base de datos PostgreSQL (vPostgres) (utilizada por vCenter Server si selecciona el
opción de base de datos durante la implementación), muchas optimizaciones se realizan automáticamente. Sin embargo, los puntos en este
sección puede mejorar el rendimiento de vCenter Server.
N OTA Muchas tareas de configuración de vCenter Server Appliance se pueden realizar utilizando vCenter Server
Interfaz de administración de dispositivos. Se puede acceder a esta interfaz mediante un navegador web para acceder al puerto 5480 en
el dispositivo (https: // <appliance-IP-address> : 5480), luego inicie sesión como root (usando la contraseña establecida
cuando se implementó vCenter Server Appliance).
∎ VCenter Server Appliance crea varios discos virtuales. Para un mejor rendimiento a gran escala
entornos, asegúrese de que el disco virtual de la base de datos (/ storage / db) y los discos virtuales relacionados con
registros, estadísticas, eventos y alarmas (/ storage / dblog y / storage / seat) están respaldados por diferentes
discos físicos.
∎ El disco virtual / storage / dblog almacena el registro de transacciones de la base de datos. Mientras que la actuación de cada
La partición es importante para el rendimiento de vCenter, vCenter es particularmente sensible a la latencia y
rendimiento de esta partición. Por lo tanto, recomendamos colocar esta partición en baja latencia y alto rendimiento.
almacenamiento. El artículo 2126276 de VMware KB, aunque aborda principalmente el cambio de tamaño de los discos virtuales, también incluye
una tabla que muestra qué VMDK corresponde a cada punto de montaje.
∎ Aunque PostgreSQL realiza su propio almacenamiento en caché de datos, los datos también se almacenan en caché a nivel del sistema operativo.
El rendimiento se puede mejorar aumentando el tamaño de la caché a nivel del sistema operativo. Esto se puede lograr
aumentar la cantidad de memoria asignada a la máquina virtual vCenter Server Appliance; Una porción de
esta memoria adicional se utilizará automáticamente para la caché de datos a nivel del sistema operativo.
∎ PostgreSQL establece puntos de control periódicamente para garantizar que las transacciones anteriores se hayan descargado
disco. Estos puntos de control se activan cada vez que las escrituras de la base de datos se acercan acumulativamente al 90% del tamaño
de la partición / storage / dblog /. Aumentar el tamaño de esta partición más allá de su tamaño predeterminado de 5 GB
por lo tanto, aumenta el tiempo entre los puntos de control. Esto reduce la carga general de E / S en el sistema,
especialmente para grandes implementaciones de vCenter, pero aumenta el tiempo de recuperación después de un bloqueo. Para obtener información sobre
para cambiar el tamaño de la partición / storage / dblog /, consulte el artículo 2126276 de la base de conocimiento de VMware.
60 VMware, Inc.
Página 61
∎ Para evitar que la base de datos de vCenter Server Appliance se quede sin espacio en disco, puede configurar alarmas
utilizando los parámetros vpxd.vdb.space.errorPercent y vpxd.vdb.space.warningPercent en
la configuración avanzada de vCenter Server. Además de mostrar advertencias en vSphere Web Client,
estas alarmas también se pueden configurar para enviar notificaciones por correo electrónico.
Recomendaciones de la base de datos de Microsoft SQL Server
Si está utilizando una base de datos de Microsoft SQL Server, los siguientes puntos pueden mejorar vCenter Server
actuación:
∎ Configurar los registros de transacciones en el modo de recuperación simple reduce significativamente el espacio en disco de los registros de la base de datos
uso, así como su carga de E / S de almacenamiento. Si no es posible establecer esto en Simple , asegúrese de tener un
subsistema de almacenamiento de alto rendimiento.
∎ Para mejorar aún más el rendimiento de la base de datos para grandes inventarios de vCenter Server, coloque tempDB en un
disco diferente que los archivos de datos de la base de datos o los registros de transacciones de la base de datos.
∎ Para garantizar un rendimiento constante de la base de datos y evitar errores de inicio de sesión, asegúrese de que AUTO_CLOSE
El parámetro está ajustado a OFF. Esto evitará que SQL Server libere recursos cuando no haya usuarios,
solo para tener que reservarlos nuevamente tan pronto como se realice otra conexión.
Recomendaciones de base de datos Oracle
Si está utilizando una base de datos Oracle, los siguientes puntos pueden mejorar el rendimiento de vCenter Server:
∎ Cuando se usa la administración automática de memoria (AMM) en Oracle 11g o la memoria compartida automática
Management (ASMM) en Oracle 10g, asigne suficiente memoria para la base de datos de Oracle.
∎ Establezca los parámetros de inicialización de PROCESOS y SESIONES adecuados . Oracle crea un nuevo servidor
proceso para cada nueva conexión que se realice. El número de conexiones que puede realizar una aplicación
a la instancia de Oracle, por lo tanto, depende de cuántos procesos puede crear Oracle. PROCESOS y
Las SESIONES juntas determinan cuántas conexiones simultáneas puede aceptar Oracle. En vSphere grande
entornos (como se define en la versión 6.5 de vSphere Installation and Setup ; busque “vCenter Server para
Requisitos de hardware de Windows “) recomendamos configurar PROCESOS y SESIONES en 1000 .
En entornos que se acercan a los máximos de configuración (como se especifica en los máximos de configuración para
vSphere 6.5 ), es posible que sea necesario aumentar ambos valores a 1200 .
∎ Si las operaciones de la base de datos son lentas, después de comprobar que las estadísticas están actualizadas y los índices no
fragmentado, debe mover los índices a espacios de tabla separados (es decir, colocar tablas y clave primaria (PK)
índice de restricción en un espacio de tabla y los otros índices (es decir, BTree) en otro espacio de tabla).
∎ Para inventarios grandes de vCenter Server (es decir, aquellos que se acercan a los límites para la cantidad de hosts o
máquinas), aumente el número de subprocesos disponibles para escribir cambiando el db_writer_processes
parámetro a 6. Este cambio puede ser útil para aplicaciones que emiten muchas escrituras de disco, como vpxd.
VMware, Inc. 61
Página 62
Gestión de VMware vSphere

Entornos VMware vSphere son normalmente manejados con el VMware vSphere ® cliente Web o el VMware
vSphere ® SDK de servicios Web.
Un gran número de vSphere Web Clients y vSphere Web Services SDK Clients pueden afectar la
rendimiento de un vCenter Server. Exceder los máximos especificados en Valores máximos de configuración para vSphere 6.5
no es apoyado. Incluso si parece funcionar, es más probable que esto afecte el rendimiento de vCenter Server.
Clientes web de vSphere

VMware vSphere Web Client se puede utilizar para controlar y configurar vCenter Server, hosts ESXi y servidores virtuales.
máquinas. El back-end, llamado vSphere Web Client Server, es una aplicación Java. La parte delantera, llamada
vSphere Web Client, es una aplicación de Adobe Flash que se ejecuta en un navegador web que apunta a la aplicación basada en Java.
Servidor de aplicaciones.
Consideraciones sobre el rendimiento de back-end de vSphere Web Client
El back-end de vSphere Web Client consta de vSphere Web Client Server, una aplicación Java, que a su vez
interactúa mucho con vCenter Server. Por tanto, ambos módulos impactan en el back-end de vSphere Web Client
actuación. Esta subsección describe cómo obtener el mejor rendimiento de vSphere Web Client
back-end.
N OTA En vSphere 6.5, el servicio de inventario se reemplaza por vpxd-svcs, un servicio más liviano que contiene
lógica para autorización, roles y privilegios.
∎ Para un rendimiento óptimo, asegúrese de proporcionar a vSphere Web Client Server con suficiente CPU,
memoria y recursos de almacenamiento para su tamaño de implementación y patrones de uso. Estos recursos
Los requisitos se enumeran en la versión 6.5 de vSphere Installation and Setup (incluida como parte de vCenter
Requisitos del servidor) y se describen durante el proceso de instalación.
∎ El rendimiento de vSphere Web Client también se ve significativamente influenciado por los siguientes factores:
∎ El tamaño del inventario de vCenter
∎ La tasa de operaciones (es decir, tareas por hora) realizadas a través de vCenter
∎ La cantidad de vSphere Web Clients en uso
∎ Los patrones de uso de los usuarios de vSphere Web Client
∎ La instalación de complementos en vSphere Web Client Server puede causar un mayor uso de memoria en el sistema
ejecutando vSphere Web Client Server. Por lo tanto, es una buena práctica, después de que los complementos estén instalados y
habilitado, para monitorear el uso de memoria de vSphere Web Client Server. Puede utilizar el Administrador de tareas (en
Windows) o superior (en Linux) para asegurarse de que el uso de memoria del proceso Java sea inferior o solo
ligeramente por encima de su tamaño máximo de pila. (También puede utilizar un generador de perfiles de Java para ver una vista más detallada del
uso de memoria de la JVM.)
N OTA Puede determinar el tamaño de almacenamiento dinámico máximo de la JVM de la siguiente manera:
∎ En un vCenter Server Appliance, ejecute:

cloudvm-ram-size -l vsphere-client
∎ En Windows, ubique el archivo cloudvm-ram-size.bat (de forma predeterminada, está en C: \ Program

Files \ VMware \ vCenter Server \ visl-integration \ usr \ sbin) y ejecuta:
cloudvm-ram-size.bat -l vspherewebclientsvc
Si encuentra que la cantidad de memoria asignada a vSphere Web Client Server es insuficiente,
aumentarlo puede mejorar significativamente el rendimiento.
62 VMware, Inc.
Página 63
La forma más sencilla de aumentar la memoria asignada a vSphere Web Client Server es
aumente la cantidad total de memoria aprovisionada para el sistema en el que se está ejecutando, luego reinicie el
sistema. En el arranque, un algoritmo de memoria dinámica reconfigurará automáticamente la cantidad de memoria
asignados a los diversos servicios, incluido vSphere Web Client Server.
Si no desea aumentar la memoria total, o si encuentra que las elecciones realizadas por la dinámica
El algoritmo de memoria no es apropiado para su entorno, puede cambiar manualmente vSphere Web
Tamaño máximo de pila del servidor del cliente. Sin embargo, tenga en cuenta que esto afectará la cantidad de memoria disponible
para otros servicios así como para el sistema operativo.
Para cambiar manualmente el tamaño máximo de pila de vSphere Web Client Server:

cloudvm-ram-size -C XXX cliente-vsphere
(donde XXX es el tamaño de pila deseado en MB).
Para obtener más información, ejecute cloudvm-ram-size -h.
∎ En Windows, ubique el archivo cloudvm-ram-size.bat (de forma predeterminada, está en C: \ Program

Files \ VMware \ vCenter Server \ visl-integration \ usr \ sbin) y ejecuta:
cloudvm-ram-size.bat -C XXX vspherewebclientsvc
(donde XXX es el tamaño de pila deseado en MB).
Para obtener más información, ejecute cloudvm-ram-size.bat -h.
Después de cambiar el tamaño máximo de pila, deberá reiniciar el servicio vSphere Web Client para el
cambiar para que surta efecto:

servicio-control-detener vsphere-client
servicio-control -start vsphere-client
∎ En Windows, abra Servicios de componentes (los detalles varían ligeramente con las versiones de Windows, pero
normalmente: menú Inicio > Todos los programas > Herramientas administrativas > Servicios de componentes ), en el panel izquierdo
seleccione Servicios , desplácese hasta el servicio de cliente web vsphere , haga clic derecho sobre él y seleccione Detener , luego haga clic derecho
de nuevo y seleccione Iniciar .
∎ Varias opciones de configuración avanzadas pueden influir en el rendimiento de vSphere Web Client.
Estas opciones, enumeradas en Tabla 4-1 , se puede configurar en el archivo webclient.properties, que se encuentra en la
siguientes ubicaciones:
∎ En un vCenter Server Appliance:

/ etc / vmware / vsphere-client
∎ En Windows:
% ProgramData% \ VMware \ vSphere Web Client
Tabla 4-1. Opciones de configuración avanzadas para vSphere Web Client Back-End
Nombre de la opción avanzada Descripción Valor por defecto
live.updates.enabled Si habilitar o no la actualización en vivo cierto

en la vista Tareas recientes .
live.updates.alarms.enabled Si habilitar o no la actualización en vivo cierto

en la vista Alarmas .
live.updates.navtree.enabled Si habilitar o no la actualización en vivo cierto

en cuatro tipos de árboles de inventario (Hosts
y clústeres, máquinas virtuales y plantillas,
Almacenamiento, redes).
live.updates.lists.enabled Si habilitar o no la actualización en vivo cierto

en listas.
VMware, Inc. 63
Página 64
live.updates.objectstate.enabled Si habilitar o no la actualización en vivo cierto

en la pestaña Resumen del actual
objeto. Esto no se hace para cada
propiedad que se muestra en cada Resumen
pestaña, pero solo para un subconjunto bien definido
de propiedades para cada tipo (el
las llamadas "propiedades críticas", que pueden
ser descrito aproximadamente como las propiedades
que determinan el icono y el estado
del objeto correspondiente).
pagingThreshold El número inicial de recuperados 2000
hijos por tipo para un nodo en el
árbol de inventario. El resto de los niños
se cargará a pedido.
navigation.tabMode.convertSecondaryToToc Ya sea para habilitar o no aplanado cierto

vista de la pestaña Gestionar para configurar.
navigation.tabMode.convertSecondaryToToc. Una lista negra de complementos para los que com.vmware.srm.client, c

excluidos Gestionar para configurar el aplanamiento de pestañas om.vmware.vShieldMan
no se puede aplicar. ager, com.vmware.vsphe
re.client.cmui, com.vmw
are.vum.client.updatema
nagerui
navigation.tabMode.convertSecondaryToToc. Una lista blanca de complementos para los que com.vmware. *. client. *
plugins compatibles Gestionar para configurar el aplanamiento de pestañas
puede ser aplicado.
show.allusers.tasks Si habilitar o no a todos los usuarios cierto

Tareas en la vista Tareas recientes.
aggregationThreshold.VirtualMachine El número de objetos de cada tipo 5000
aggregationThreshold.HostSystem vSphere Web Client se mostrará en su

árbol de inventario antes de agregar
aggregationThreshold.Datastore
a un solo nodo con un recuento
aggregationThreshold.Network
etiqueta.
aggregationThreshold.OpaqueNetwork
Un valor de 0 deshabilita la agregación.
aggregationThreshold.DistributedVirtualPort
grupo
hora de término de la sesión Tiempo (en minutos) antes de que un usuario 120
desconectado automáticamente.
frecuencia de actualización Tiempo (en segundos) entre automático -1

actualizaciones de vSphere Web Client.
Advertencia: habilitación de la actualización automática
evita el cierre de sesión automático de inactivo
usuarios.
Un valor de -1 desactiva el automático

actualizar.
64 VMware, Inc.
Página 65
alarms.refresh.rate Tiempo (en segundos) entre automático 60

actualiza la lista de alarmas.
Debe tener entre 10 y 600.

actualización de alarmas.
tasks.refresh.rate Tiempo (en segundos) entre automático 60

Actualizaciones de listas de tareas recientes.
Debe tener entre 10 y 600.

actualización de listas de tareas recientes.
tasks.display.count El número máximo de tareas 50

que se muestra en la lista de tareas recientes.
Debe estar entre 1 y 100.
feature.facetedSearch.enabled Si las opciones de filtro de facetas o no cierto

estará disponible en listas.
portlets.collapsed Si los portlets que se muestran en falso

la página de resumen se contraerá
por defecto.
Cuando colapsan no solicitan datos,
así potencialmente mejorando
actuación.
navigator.disableAnimation Desactiva la animación deslizante del cierto

panel de navegación
OptimizeLogin.disabled Desactiva la precarga de ciertos falso

archivos.
En algunos navegadores, la precarga
introduce un retraso notable entre
un usuario que escribe sus credenciales de inicio de sesión
y esas credenciales que aparecen en
la pantalla.
Consideraciones sobre el rendimiento de vSphere Web Client Front-End
El front-end de vSphere Web Client es una aplicación Apache Flex que se ejecuta en un navegador web en el
sistema. Esta subsección describe cómo obtener el mejor rendimiento del front-end de vSphere Web Client
∎ El primer inicio de sesión de vSphere Web Client normalmente será más lento que los inicios de sesión posteriores debido a varios
inicializaciones.
∎ Para obtener el mejor rendimiento de vSphere Web Client, asegúrese de que el sistema del usuario tenga suficientes recursos de CPU
(recomendamos al menos dos núcleos de CPU; cuanto más rápido, mejor) y memoria (como ejemplo, para el cliente
sistemas que ejecutan Windows, recomendamos al menos 4 GB de RAM).
∎ Las latencias de red grandes pueden reducir significativamente el rendimiento de vSphere Web Client. Por lo mejor
rendimiento, las latencias de red entre vSphere Web Client que se ejecuta en el sistema del usuario y el
El back-end de vSphere Web Client debe ser inferior a 30 ms.
N OTA Cuando no sea posible establecer una conexión de baja latencia, una opción alternativa sería colocar
un sistema virtual o físico cerca del back-end de vSphere Web Client (de modo que tenga una latencia baja
conexión al back-end), y ejecute vSphere Web Client front-end en ese sistema, accediendo de forma remota
desde la ubicación más distante utilizando RDP u otro protocolo remoto.
VMware, Inc. sesenta y cinco
Página 66
∎ El uso de un navegador de 64 bits para ver vSphere Web Client permite la asignación de más memoria, potencialmente
mejorando el rendimiento y evitando que el reproductor Flash se quede sin memoria.
∎ Cuando sea posible, utilice la función de búsqueda en lugar de navegar a los objetos administrados. El cliente web vSphere
está diseñado para el uso de la búsqueda de inventario para encontrar objetos administrados (clústeres, hosts, máquinas virtuales,
almacenes de datos, etc.). Aunque puede acceder a los objetos administrados a través del árbol de inventario o el inventario
vistas de lista, la función de búsqueda de inventario generalmente proporcionará un mejor rendimiento que navegar entre
estos objetos.
∎ Cierre la ventana del navegador de vSphere Web Client ocasionalmente (aproximadamente a diario). Clausura y
reiniciar la ventana del navegador en la que se ejecuta vSphere Web Client evitará las sesiones del cliente
de consumir más memoria de la necesaria.
Clientes de vSphere Web Services SDK

El SDK de servicios web de VMware vSphere puede ser una forma eficaz de administrar el entorno de vSphere.
Para obtener más información sobre la API de VMware vSphere y las bibliotecas SDK compatibles, consulte la API y el SDK de vSphere.
Documentación.
Para ver ejemplos de buenas prácticas de programación, consulte ejemplos de código del código de muestra de VMware Communities
página ( http://communities.vmware.com/community/vmtn/developer/codecentral ).
Para usar el SDK para obtener datos de rendimiento del clúster agregando información de hosts individuales, consulte la
Lanzamiento de vCenter Cluster Performance Tool ( https://labs.vmware.com/flings/vcenter-cluster-performance-tool ).
66 VMware, Inc.
Página 67
VMware vMotion y Storage vMotion

Esta sección proporciona las mejores prácticas de rendimiento para vMotion ™ , Storage vMotion y Cross-host Storage
vMotion.
Recomendaciones de VMware vMotion

Las siguientes recomendaciones de rendimiento se aplican a vMotion:
∎ ESXi 6.5 presenta la versión 13 de hardware virtual. Porque las máquinas virtuales que se ejecutan en la versión de hardware
13 no se puede ejecutar en versiones anteriores de ESX / ESXi, tales máquinas virtuales se pueden mover usando VMware vMotion
solo a otros hosts ESXi 6.5. ESXi 6.5 también es compatible con versiones anteriores de máquinas virtuales que se ejecutan en
versiones anteriores de hardware virtual, sin embargo, y estas máquinas virtuales se pueden mover usando VMware
vMotion a hosts que ejecutan versiones anteriores de ESX / ESXi con las que son compatibles.
∎ vSphere 6.5 presenta vMotion cifrado. Esta función cifra el tráfico de vMotion cuando tanto la fuente
y los hosts de destino son capaces de admitir vMotion cifrado (es decir, cuando ambos hosts
ESXi 6.5). Si una máquina virtual que se ejecuta en ESXi 6.5 se migra a un host que ejecuta una versión anterior de ESX / ESXi
versión, el tráfico de vMotion no está cifrado.
El rendimiento del cifrado es significativamente mayor en hosts que admiten AES-NI (Intel Advanced
Nuevo conjunto de instrucciones estándar de cifrado). Sin AES-NI, las operaciones de vMotion cifradas
Rendimiento inaceptable.
Las máquinas virtuales cifradas siempre se mueven con vMotion cifrado. Para máquinas virtuales que no son
cifrado, el cifrado de vMotion se puede cambiar de oportunista (el predeterminado) a desactivado o
Obligatorio (haga clic con el botón derecho en la máquina virtual, seleccione Editar configuración , seleccione Opciones de máquina virtual , haga clic en Cifrado ,
seleccione una opción del menú desplegable Encrypted vMotion ).
∎ El rendimiento de vMotion aumentará a medida que el ancho de banda de red adicional esté disponible para vMotion
red. Considere aprovisionar interfaces de red vMotion de 10 Gb / so más rápidas para obtener el máximo de vMotion
actuación. Múltiples vmknics de vMotion pueden proporcionar un aumento adicional en el ancho de banda de la red
disponible para vMotion.
Todos los vmknics de vMotion en un host deben compartir un solo vSwitch. Cada grupo de puertos de vmknic debe ser
configurado para aprovechar una NIC física diferente como su vmnic activa. Además, todos los vmknics de vMotion
debe estar en la misma red vMotion.
∎ Para lograr una velocidad de línea completa en una red vMotion de 40 Gb / s, recomendamos configurar tres
vmknics en la NIC de 40 Gb / s. El uso de múltiples vmknics de vMotion permite que vMotion cree múltiples
subprocesos de trabajo de vMotion, distribuyendo así la carga de la CPU en varios núcleos en lugar de saturar un
ancho de banda de red de un solo núcleo y con cuello de botella. Para obtener más información, consulte el artículo de la base de conocimiento de VMware
2108824.
∎ Mientras una operación de vMotion está en progreso, ESXi reserva de manera oportunista recursos de CPU en ambos
hosts de origen y destino para garantizar la capacidad de utilizar completamente el ancho de banda de la red. ESXi
Intentará utilizar todo el ancho de banda disponible de la red independientemente del número de operaciones de vMotion.
siendo realizado. Por tanto, la cantidad de reserva de CPU depende de la cantidad de NIC de vMotion y su
velocidades; 10% de un núcleo de procesador por cada interfaz de red de 1 Gb / s, 100% de un núcleo de procesador por cada 10 Gb / s
interfaz de red y una reserva total mínima del 30% del núcleo del procesador. Por lo tanto, dejando algunos
La capacidad de CPU no reservada en un clúster puede ayudar a garantizar que las tareas de vMotion obtengan los recursos necesarios en
para utilizar completamente el ancho de banda de red disponible.
∎ El rendimiento de vMotion puede reducirse si los archivos de intercambio a nivel de host se colocan en el almacenamiento local (ya sea SSD
o disco duro). Para obtener más información sobre archivos de intercambio a nivel de host, consulte"Optimizaciones de intercambio de memoria" en
página 29 .
∎ Durante vMotion de una máquina virtual habilitada para vFRC (descrita en "VSphere Flash Read Cache (vFRC)" en
página 32) , la caché vFRC se migra de forma predeterminada. Debido a que esta caché puede ser potencialmente bastante grande,
migrarlo puede aumentar el tiempo necesario para realizar una operación de vMotion en la máquina virtual y
puede consumir más ancho de banda de red en el proceso.
VMware, Inc. 67
Página 68
Si lo desea, la migración de la caché vFRC durante vMotion se puede deshabilitar manualmente, lo que hace que el archivo de caché
para ser descartado en el host de origen y recreado en el host de destino. Esto puede reducir el tiempo de vMotion
y ahorrar ancho de banda de la red, también podría reducir temporalmente las ganancias de rendimiento de vFRC en el
máquina después de que se complete la operación de vMotion, mientras que la caché se vuelve a llenar.
La elección de deshabilitar la migración de caché vFRC debe hacerse después de tener en cuenta la
importancia del rendimiento de la aplicación, la utilización del ancho de banda de la red y la duración de vMotion.
∎ Para obtener el mejor rendimiento de vMotion con hardware EMC VPLEX Metro Distributed Virtual Volume,
recomendamos lo siguiente:
∎ Aprovisione NIC de hardware compatibles con TSO para la red vMotion.
∎ Agregue la opción VMX (extension.converttonew = "FALSE") a los archivos .vmx de la máquina virtual.
La opción optimiza la apertura de discos virtuales durante el encendido de la máquina virtual y, por lo tanto, reduce
tiempo de cambio durante vMotion. Si bien esta opción también se puede utilizar en otras situaciones, es
particularmente útil en implementaciones de VPLEX Metro.
∎ Dado que las instantáneas de máquinas virtuales ralentizan el proceso de cambio, evite las instantáneas innecesarias.
Para obtener más información sobre este tema, consulte el artículo 1026692 de VMware KB.
Recomendaciones de VMware Storage vMotion

Las siguientes recomendaciones de rendimiento se aplican a Storage vMotion:
∎ El rendimiento de VMware Storage vMotion depende en gran medida de la infraestructura de almacenamiento disponible
ancho de banda entre el host ESXi donde se ejecuta la máquina virtual y el origen y
almacenes de datos de destino.
Durante una operación de Storage vMotion, el disco virtual que se va a mover se lee desde el almacén de datos de origen
y escrito en el almacén de datos de destino. Al mismo tiempo, la máquina virtual continúa leyendo y
escribir en el almacén de datos de origen y al mismo tiempo escribir en el almacén de datos de destino.
Este tráfico adicional tiene lugar en el almacenamiento que también puede tener otras cargas de E / S (de otras
máquinas en el mismo host ESXi o de otros hosts) que pueden reducir aún más el ancho de banda disponible.
∎ Storage vMotion tendrá el mayor rendimiento durante tiempos de baja actividad de almacenamiento (cuando esté disponible
el ancho de banda de almacenamiento es más alto) y cuando la carga de trabajo en la máquina virtual que se está moviendo es menos activa.
∎ Storage vMotion puede realizar hasta cuatro copias de disco simultáneas por operación de Storage vMotion. Almacenamiento
Sin embargo, vMotion incluirá cada almacén de datos en no más de una copia de disco a la vez. Esto significa,
por ejemplo, que mover cuatro archivos VMDK del almacén de datos A al almacén de datos B ocurrirá en serie, pero
mover cuatro archivos VMDK de los almacenes de datos A, B, C y D a los almacenes de datos E, F, G y H ocurrirá en
paralelo.
Para operaciones de Storage vMotion de rendimiento crítico que involucran máquinas virtuales con múltiples VMDK
archivos, puede utilizar reglas de antiafinidad para distribuir los archivos VMDK en varios almacenes de datos, lo que garantiza
copias de disco simultáneas.
∎ Durante una operación de Storage vMotion, los beneficios de pasar a un almacén de datos más rápido se verán solo cuando
la migración ha finalizado. Sin embargo, el impacto de pasar a un almacén de datos más lento se sentirá gradualmente
a medida que avanza la migración.
∎ Storage vMotion a menudo tendrá un rendimiento significativamente mejor en arreglos de almacenamiento compatibles con VAAI
(descrito en “Consideraciones de almacenamiento de hardware” en la página 13) .
Recomendaciones de VMware Cross-Host Storage vMotion

Cross-host Storage vMotion permite que una máquina virtual se mueva simultáneamente entre hosts y
almacenes de datos. Las siguientes recomendaciones de rendimiento se aplican a Cross-host Storage vMotion:
68 VMware, Inc.
Página 69
∎ Cross-host Storage vMotion tiene optimizaciones de rendimiento que dependen de un tamaño de bloque del sistema de archivos de 1 MB.
Si bien 1 MB ha sido el tamaño de bloque VMFS predeterminado desde las primeras versiones de VMFS, ciertas versiones de VMFS
(VMFS 3.x, por ejemplo) permitía a los usuarios elegir un tamaño de bloque diferente. Si sus sistemas de archivos VMFS no
utilizar tamaños de bloque de 1 MB, puede obtener reducciones significativas en el tiempo de migración de vMotion si cambia a
la última versión de VMFS 5.x.
N OTA Las actualizaciones in situ de almacenes de datos VMFS con tamaños de bloque que no sean de 1 MB a VMFS 5.x dejan el tamaño del bloque
sin alterar. Por lo tanto, en esta situación, sería necesario crear un nuevo almacén de datos VMFS 5.x para obtener la
ventajas de rendimiento del tamaño de bloque de 1 MB.
∎ Cuando se utiliza una NIC de 40 Gb / s, el almacenamiento entre hosts vMotion funciona mejor con tres vmknics de vMotion, ya que
descrito para vMotion en “Recomendaciones de VMware vMotion” en la página 67 .
∎ Cross-host Storage vMotion puede realizar hasta cuatro copias de disco simultáneas, como se describe para Storage
vMotion en “Recomendaciones de VMware Storage vMotion” en la página 68.
∎ Cross-host Storage vMotion tiene una variedad de opciones que puede usar para migrar el contenido del disco virtual entre
almacenes de datos.
Para la mayoría de las máquinas virtuales encendidas, Cross-host Storage vMotion generalmente usa la red vMotion.
Sin embargo, en varias circunstancias, utiliza los siguientes métodos alternativos (enumerados
más preferido primero):
∎ Si los almacenes de datos de origen y destino están en el mismo arreglo compatible con VAAI, y el host de origen
tiene acceso al almacén de datos de destino, Cross-host Storage vMotion se descargará al arreglo a través de VAAI
la tarea de copiar el contenido del disco.
∎ Si el host de origen tiene acceso al almacén de datos de destino, vMotion utilizará el almacenamiento del host de origen
interfaz para transferir el contenido del disco, lo que reduce la utilización de la red vMotion y la CPU del host
utilización.
Para migrar máquinas virtuales apagadas y, en algunos casos, para migrar datos "fríos" (el disco base y
cualquier instantánea que no sea la actual, en una máquina virtual que tiene una instantánea), almacenamiento entre hosts
vMotion utilizará el servicio Network File Copy (NFC). Como en el caso de las máquinas virtuales encendidas,
el servicio NFC utilizará preferentemente VAAI o la interfaz de almacenamiento del host de origen de manera similar. Si ninguno de
Estos enfoques son posibles, el servicio NFC utilizará la red designada para el tráfico NFC.
N OTA Antes de vSphere 6.0, el tráfico NFC solo podía usar la red de administración (a veces llamada
"Red de aprovisionamiento"). A partir de vSphere 6.0, el tráfico NFC todavía usa la red de administración por
predeterminado, pero opcionalmente se puede enrutar a través de una red dedicada al tráfico NFC. Esto permite que el tráfico NFC
separarse del tráfico de administración, lo que brinda más flexibilidad en el aprovisionamiento de la red.
En cualquier caso, recomendamos que el tráfico NFC se proporcione al menos 1 Gb / s de ancho de banda de red.
VMware, Inc. 69
Página 70
Programador de recursos distribuidos de VMware (DRS)

Esta sección enumera las prácticas y configuraciones del Programador de recursos distribuidos (DRS) recomendadas por
VMware para un rendimiento óptimo.
DRS en general
∎ Esté atento a las recomendaciones manuales generadas por DRS, especialmente si ha configurado anulaciones manuales. En
En algunos casos, las recomendaciones manuales no abordadas pueden evitar que DRS genere
recomendaciones.
∎ Cuando se establecen las reglas de afinidad de DRS, esté atento a las fallas de DRS generadas por violaciones de las reglas. Abordar tales fallas
a menudo puede ayudar significativamente con el equilibrio de carga.
Parámetros de configuración del clúster de DRS

∎ Al decidir qué hosts agrupar en clústeres de DRS, intente elegir hosts que sean tan homogéneos como
posible en términos de CPU y memoria. Esto mejora la previsibilidad y la estabilidad del rendimiento.
Cuando los sistemas heterogéneos tienen CPU compatibles, pero tienen diferentes frecuencias de CPU y / o
cantidades de memoria, DRS generalmente prefiere ubicar máquinas virtuales en los sistemas con más memoria
y frecuencias de CPU más altas (en igualdad de condiciones), ya que esos sistemas tienen más capacidad para
adaptarse a las cargas máximas.
∎ VMware vMotion no es compatible con hosts con CPU incompatibles. Por lo tanto, con 'CPU incompatible'
sistemas heterogéneos, las oportunidades que tiene DRS para mejorar el equilibrio de carga en todo el clúster son
limitado.
Para garantizar la compatibilidad de la CPU, asegúrese de que los sistemas estén configurados con el mismo proveedor de CPU, con similares
Familias de CPU y con la capacidad de conjunto de instrucciones SSE correspondiente. Para obtener más información sobre este tema, consulte
Artículos de VMware KB 1991, 1992 y 1993.
También puede utilizar Enhanced vMotion Compatibility (EVC) para facilitar vMotion entre diferentes CPU
generaciones. Para obtener más información sobre este tema, consulte VMware vMotion y compatibilidad de CPU y VMware
Artículo de KB 1003212.
∎ Cuantos más hosts ESXi compatibles con vMotion tenga DRS disponibles, más opciones tendrá para equilibrar mejor la
Clúster DRS. Además de la incompatibilidad de CPU, existen otras configuraciones incorrectas que pueden bloquear vMotion
entre dos o más hosts. Por ejemplo, si los adaptadores de red vMotion de los hosts no están conectados
1 Gb / so un enlace Ethernet más rápido, entonces vMotion podría no ocurrir entre los hosts.
Otras opciones de configuración que se deben verificar son la compatibilidad de la versión de hardware virtual, la configuración incorrecta de
la puerta de enlace vMotion, políticas de seguridad incompatibles entre el host de origen y destino vMotion
adaptador de red y disponibilidad de red de la máquina virtual en el host de destino. Consulte vSphere
vCenter Server and Host Management para obtener más detalles.
∎ Cuando sea posible, asegúrese de que cada host en un clúster de DRS tenga conectividad con el conjunto completo de almacenes de datos
accesible por los otros hosts en ese clúster. Esta conectividad completa permite a DRS tomar mejores decisiones
al equilibrar cargas entre hosts.
∎ Las máquinas virtuales con tamaños de memoria más pequeños y / o menos CPU virtuales brindan más oportunidades para que DRS
migrarlos para mejorar el equilibrio en todo el clúster. Máquinas virtuales con tamaños de memoria más grandes
y / o más CPU virtuales agregan más restricciones en la migración de las máquinas virtuales. Esta es una razón más para
Configure máquinas virtuales con solo tantas vCPU y solo tanta memoria virtual como necesiten.
∎ Tener máquinas virtuales en modo automático DRS cuando sea posible, ya que se consideran para la carga del clúster.
equilibrar las migraciones entre los hosts ESXi antes que las máquinas virtuales que no están en modo automático.
∎ Las máquinas virtuales encendidas consumen recursos de memoria y, por lo general, consumen algo de CPU
recursos, incluso cuando están inactivos. Así, incluso las máquinas virtuales inactivas, aunque su utilización suele ser pequeña, pueden
afectar las decisiones de DRS. Por esta y otras razones, se puede obtener un aumento marginal del rendimiento
apagar o suspender máquinas virtuales que no se estén utilizando.
70 VMware, Inc.
Página 71
∎ Los grupos de recursos ayudan a mejorar la capacidad de administración y la resolución de problemas de rendimiento. Nosotros
Sin embargo, recomendamos que los grupos de recursos y las máquinas virtuales no se conviertan en hermanos en una jerarquía.
En cambio, cada nivel debe contener solo grupos de recursos o solo máquinas virtuales. Esto es porque por defecto
A los grupos de recursos se les asignan valores compartidos que pueden no compararse adecuadamente con los asignados a
máquinas virtuales, lo que podría generar un rendimiento inesperado.
∎ Las reglas de afinidad de DRS pueden mantener dos o más máquinas virtuales en el mismo host ESXi ("afinidad VM / VM") o
asegúrese de que siempre estén en diferentes hosts (“VM / VM antiafinidad”). También se pueden utilizar las reglas de afinidad de DRS
para asegurarse de que un grupo de máquinas virtuales se ejecute solo en (o tenga preferencia por) un grupo específico de ESXi
hosts ("afinidad VM / Host") o nunca se ejecuta (o tiene preferencia contra) un grupo específico de hosts
("Antiafinidad VM / Host").
En la mayoría de los casos, dejar la configuración de afinidad sin cambios proporcionará los mejores resultados. En casos raros, sin embargo,
especificar reglas de afinidad puede ayudar a mejorar el rendimiento. Para cambiar la configuración de afinidad, desde vSphere Web
El cliente seleccione un clúster, haga clic en la pestaña Configurar , expanda Configuración , haga clic en Reglas de VM / Host , haga clic en Agregar ,
ingrese un nombre para la nueva regla, elija un tipo de regla y continúe con la GUI según corresponda para la regla
tipo que seleccionó.
Además de la configuración predeterminada, los tipos de configuración de afinidad son:
∎ Mantenga juntas las máquinas virtuales

Este tipo de afinidad puede mejorar el rendimiento debido a menores latencias de comunicación entre
máquinas.
∎ Máquinas virtuales independientes

Este tipo de afinidad puede mantener la máxima disponibilidad de las máquinas virtuales. Por ejemplo, si son
ambos frontales del servidor web a la misma aplicación, es posible que desee asegurarse de que no ambos
bajar al mismo tiempo. Además, la ubicación conjunta de máquinas virtuales intensivas en E / S podría terminar saturando
capacidad de E / S del host, lo que provoca una degradación del rendimiento.
∎ Máquinas virtuales a hosts (incluido Debe ejecutarse en ... , Debería ejecutarse en ... , No debe ejecutarse en ... , y
No debería ejecutarse en ... )
Estos tipos de afinidad pueden resultar útiles para clústeres con restricciones de licencias de software o
requisitos de la zona de disponibilidad.
∎ Para permitir a DRS la máxima flexibilidad:
∎ Coloque las máquinas virtuales en almacenes de datos compartidos accesibles desde todos los hosts del clúster.
∎ Asegúrese de que las máquinas virtuales no estén conectadas a dispositivos host que impidan que se muevan
fuera de esos hosts.
∎ DRS Doctor, una herramienta no oficial de VMware ( https://labs.vmware.com/flings/drsdoctor ), puede proporcionar

información sobre el DRS y las acciones que realiza. Esto puede resultar útil para solucionar problemas de DRS.
Configuración de recursos y tamaño del clúster de DRS

∎ Exceder la cantidad máxima de hosts, máquinas virtuales o grupos de recursos para cada clúster de DRS
especificado en Valores máximos de configuración para vSphere 6.5 no es compatible. Incluso si parece funcionar, hacerlo
podría afectar negativamente al rendimiento de vCenter Server o DRS.
∎ Seleccione con cuidado la configuración de recursos (es decir, reservas, recursos compartidos y límites) para sus máquinas virtuales.
∎ Establecer reservas demasiado altas puede dejar pocos recursos sin reservar en el clúster, lo que limita la
opciones que DRS tiene para equilibrar la carga.
∎ Establecer límites demasiado bajos podría evitar que las máquinas virtuales usen recursos adicionales disponibles en el clúster
para mejorar su desempeño.
Utilice las reservas para garantizar el requisito mínimo que necesita una máquina virtual, en lugar de lo que usted
podría gustarle conseguir. Tenga en cuenta que los recursos compartidos tienen efecto solo cuando hay disputa de recursos. Tenga en cuenta también que
los recursos adicionales reservados para la sobrecarga de memoria de la máquina virtual deben tenerse en cuenta al dimensionar
recursos en el clúster.
VMware, Inc. 71
Página 72
Si es posible que la capacidad general del clúster no satisfaga las necesidades de todas las máquinas virtuales durante las horas pico, puede
asignar recursos compartidos relativamente más altos a máquinas virtuales o grupos de recursos que alojan aplicaciones de misión crítica
para reducir la interferencia de rendimiento de máquinas virtuales menos críticas.
∎ A partir de vSphere 6.0, DRS incluye NetIOC (“Control de E / S de red (NetIOC)” en la página 39 ) ancho de banda
reservas en sus cálculos.
∎ Si va a utilizar vMotion, es una buena práctica dejar algo de capacidad de CPU sin usar (y sin reservar) en
su grupo. Como se describe en "Recomendaciones de VMware vMotion" en la página 67 , cuando un vMotion
se inicia la operación, ESXi reserva algunos recursos de CPU para esa operación.
Ajuste del rendimiento de DRS

∎ El umbral de migración para DRS completamente automatizado permite al administrador controlar la agresividad
del algoritmo DRS. En muchos casos, la configuración predeterminada del umbral de migración, que representa un
nivel medio de agresividad, funcionará bien.
El umbral de migración debe establecerse en niveles más agresivos cuando se dan las siguientes condiciones
satisfecho:
∎ Los hosts del clúster son relativamente homogéneos.
∎ La utilización de recursos de las máquinas virtuales no varía mucho con el tiempo.
El umbral de migración debe establecerse en niveles más conservadores en las situaciones opuestas.
N OTA Si se elige el umbral más conservador, DRS no realizará el equilibrio de carga; solo lo hará
aplicar recomendaciones de movimiento que deben tomarse para satisfacer restricciones estrictas, como afinidad o
reglas de antiafinidad, o para evacuar máquinas virtuales de un host que ingresa al modo de mantenimiento o en espera.
∎ Para simplificar la administración de clústeres, vSphere 6.5 proporciona tres nuevas opciones avanzadas que brindan
personalizaciones simples del comportamiento de DRS para adaptarse mejor a las diversas necesidades del clúster
∎ La opción de distribución de VM hace que DRS considere distribuir las VM de manera uniforme entre los hosts en el
clúster por motivos de disponibilidad.
∎ La opción Memory Metric for Load Balancing hace que DRS considere el uso de memoria consumida para
equilibrio de carga en lugar de considerar el uso de memoria activa por defecto.
∎ El exceso de compromisos CPU opción le permite especificar la cantidad de CPU compromiso excesivo (como una
porcentaje de la capacidad total de la CPU del clúster) DRS debe considerar. Esto puede resultar útil cuando necesite
Consolide sus cargas de trabajo para una mejor utilización de los recursos de hardware.
Estas opciones están disponibles en vSphere Web Client (seleccione un clúster, haga clic en la pestaña Configurar , expanda
Servicios , seleccione vSphere DRS , haga clic en el botón Editar y expanda Opciones adicionales ).
Para obtener más información sobre estas opciones, consulte vSphere 6.5 DRS Performance .
∎ Una opción avanzada, AggressiveCPUActive, afecta la forma en que DRS predice la demanda de CPU de las máquinas virtuales
en el clúster de DRS.
Cuando AggressiveCPUActive se establece en 0 (el valor predeterminado), DRS predice la demanda de CPU utilizando el
promedio de la actividad de la CPU.
Cuando AggressiveCPUActive se establece en 1 , DRS predice demanda de la CPU usando la mayor de o bien la
Promedio de 5 minutos de actividad de la CPU o el percentil 80 de los últimos cinco valores promedio de 1 minuto de la CPU
actividad (en otras palabras, el segundo promedio más alto de 1 minuto).
El comportamiento DRS más agresivo cuando este valor se establece en 1 puede detectar mejor los picos en el tiempo de preparación de la CPU
y así predecir mejor la demanda de CPU en algunas implementaciones.
∎ Hay una variedad de razones por las que un clúster de DRS puede mostrarse como carga desequilibrada . Éstas incluyen:
∎ Las migraciones se filtran debido a reglas de afinidad / antiafinidad.
∎ Las migraciones se filtran debido a incompatibilidades de máquina virtual y host.
72 VMware, Inc.
Página 73
∎ El costo estimado para migraciones potenciales (basado en los costos de migraciones anteriores) que exceda el
beneficios esperados de las posibles migraciones.
∎ Todos los hosts del clúster están saturados de red.
Si lograr un clúster de "carga equilibrada" es fundamental para su entorno específico, puede relajar algunas reglas o
ajustar el umbral de migración.
Por otro lado, si todas las máquinas virtuales reciben el 100% de sus recursos autorizados, podría ser
aceptable tener un clúster ligeramente desequilibrado.
∎ Un conjunto de scripts con los que los usuarios avanzados de DRS pueden realizar un equilibrio de carga de clúster más proactivo es
disponible en la página de la comunidad Scripts for Proactive DRS VMware, en
http://communities.vmware.com/docs/DOC-10231 .
∎ A partir de vSphere 6.5, el DRS predictivo se puede configurar para recibir predicciones de VMware
vRealize ® Operations ™ y utilice esta información para realizar movimientos de equilibrio de carga.
N OTA Esto requiere vRealize Operations versión 6.4 o posterior. Para obtener más detalles, consulte
https://blogs.vmware.com/management/2016/11/david-davis-vrealize-operations-post-34-new-predictiv
e-drs-vrealize-operations-6-4.html .
Para obtener más información sobre DRS, consulte vSphere 6.5 Resource Management .
VMware, Inc. 73
Página 74
Administración de energía distribuida de VMware (DPM)

VMware Distributed Power Management (DPM) ahorra energía cuando los hosts de un clúster están infrautilizados.
Para ello, consolida las máquinas virtuales en un subconjunto de los hosts del clúster y luego coloca el resto
hosts en modo de espera. DPM mantiene suficiente capacidad de host encendida para satisfacer las necesidades de los
máquinas en el clúster. Cuando aumenta la demanda, DPM enciende hosts adicionales y migra
máquinas a ellos, manteniendo la carga del clúster equilibrada entre los hosts encendidos.
DPM es más apropiado para clústeres en los que la demanda de máquinas virtuales compuestas varía significativamente
hora; por ejemplo, conglomerados en los que la demanda general es mayor durante el día y significativamente menor durante la noche.
Si la demanda es constantemente alta en relación con la capacidad general del clúster, DPM tendrá pocas oportunidades de colocar hosts
en modo de espera para ahorrar energía.
Debido a que DPM usa DRS, la mayoría de las mejores prácticas de DRS (descritas en “VMware Distributed Resource Scheduler
(DRS) ” en la página 70) también son relevantes para DPM.
N OTA Mientras que DPM apaga los hosts para ahorrar energía, una técnica de ahorro de energía muy diferente, Host Power
Management, se puede utilizar para reducir el consumo de energía de los hosts ESXi individuales mientras están alimentados
en. Esto se describe en“Administración de energía del host en ESXi” en la página 24 .
DPM y Host Power Management se pueden usar juntos para la mejor conservación de energía.
Configuración y modos de funcionamiento de DPM

∎ DPM es complementario a las políticas de administración de energía del host (descritas en “Administración de energía del host en
ESXi ” en la página 24) . DPM ahorra energía a escala de clúster al poner en espera los hosts infrautilizados
modo, eliminando así su consumo de energía inactivo. Las políticas de administración de energía a nivel de host permiten
uso eficiente de los hosts del clúster que permanecen encendidos. Uso de DPM y administración de energía del host
juntos pueden ofrecer mayores ahorros de energía que los que se obtienen cuando se usa una de las soluciones por separado.
∎ Los hosts de un clúster habilitado para DPM heredan el nivel de automatización (automático o manual) establecido en el clúster.
nivel. El nivel de automatización también se puede configurar para hosts individuales, anulando el nivel de automatización heredado.
Cuando un host está habilitado para DPM manual, vCenter solicita la aprobación del usuario antes de colocar ese host en o
sacándolo del modo de espera.
DPM tiene la mayor flexibilidad y el potencial para el máximo ahorro de energía cuando todos los hosts están habilitados
para DPM automático. DPM también elige preferentemente hosts en modo automático sobre hosts en modo manual
para poner o sacar del modo de espera.
∎ Si lo desea, DPM también se puede deshabilitar para hosts individuales en un clúster incluso cuando DPM está habilitado para ese
racimo. Esto podría hacerse para hosts que ejecutan máquinas virtuales de misión crítica, por ejemplo. VM / Host
Las reglas de afinidad se pueden utilizar para garantizar que esas máquinas virtuales no se migren fuera de estas
Hospedadores.
Ajuste del algoritmo DPM

∎ DPM considera la demanda histórica para determinar cuánta capacidad mantener encendida y mantiene
cierto exceso de capacidad disponible para aumentos en la demanda. DPM también encenderá hosts adicionales como
necesario para aumentos inesperados en la demanda de máquinas virtuales existentes o para permitir nuevas
máquinas que se admitirán en el clúster.
∎ La agresividad del algoritmo DPM se puede ajustar ajustando el umbral DPM en el clúster
menú de configuración. Este parámetro es similar al umbral de desequilibrio de DRS en que controla cómo
DPM recomienda agresivamente migraciones y poner hosts y sacarlos del modo de espera.
La configuración predeterminada para el umbral es 3 (agresividad media).
∎ Los hosts no se ponen en modo de espera a menos que la demanda de memoria de las máquinas virtuales en el clúster sea
bajo. Antes de vSphere 5.5, la demanda de memoria de las máquinas virtuales se consideraba baja cuando sus activos
la memoria era baja, incluso cuando su memoria consumida era alta.
74 VMware, Inc.
Página 75
vSphere 5.5 introdujo un cambio en el comportamiento predeterminado de DPM diseñado para reducir la función
agresivo. Al estimar la demanda de memoria, DPM ahora tiene en cuenta un porcentaje del
memoria inactiva consumida (25% por defecto). Este comportamiento puede ayudar a prevenir la degradación del rendimiento de
máquinas virtuales cuando la memoria activa es baja pero la memoria consumida es alta.
Si lo desea, este comportamiento se puede ajustar usando la variable en las opciones avanzadas para DPM,
PercentIdleMBInMemDemand. Como se mencionó anteriormente, el valor predeterminado de esta variable es 25. Configurándolo en 0
volvería al comportamiento de DPM más agresivo que se encuentra en versiones anteriores de vSphere. Poniéndolo en
100 haría que DPM sea muy conservador al equiparar las estimaciones de demanda de memoria con el consumo
memoria.
∎ Para los clústeres que a menudo tienen picos inesperados en la demanda de recursos de la máquina virtual, dos variables en el
Las opciones avanzadas para DPM se pueden utilizar para establecer las capacidades mínimas de CPU y memoria que DPM
mantener siempre encendido, MinPoweredOnCpuCapacity (predeterminado: 1, unidad: MHz) y
MinPoweredOnMemCapacity (predeterminado: 1, unidad: MB).
Programación de DPM y ejecución de DPM de forma proactiva

∎ DPM se puede habilitar o deshabilitar en una programación predeterminada mediante Tareas programadas en vCenter Server.
Cuando DPM está deshabilitado, todos los hosts ESXi en espera del clúster se encenderán. Esto puede resultar útil para
ejemplo, para reducir la demora en responder a los picos de carga esperados en ciertos momentos del día o para reducir
la probabilidad de que algunos hosts se dejen en modo de espera durante períodos prolongados.
N OTA De manera similar, cuando se reinicia el servidor vCenter o el servicio vCenter vpxd, todos los hosts ESXi en espera
administrado por ese servidor vCenter se encenderá.
∎ Cuando el DRS predictivo está habilitado y configurado para recibir predicciones de vRealize Operations, DPM
puede hacer uso de estas predicciones para hacer que los hosts vuelvan del modo de espera de forma proactiva incluso antes de que
aumenta la demanda de carga de trabajo. Por ejemplo, si la demanda de carga de trabajo aumenta todas las mañanas a las 9 a. M., DPM puede
utilice predicciones para sacar a los hosts del modo de espera a las 8 am para adaptarse a la demanda esperada.
N OTA Esto requiere vRealize Operations versión 6.4 o posterior. Para obtener más detalles, consulte
https://blogs.vmware.com/management/2016/11/david-davis-vrealize-operations-post-34-new-predictiv
e-drs-vrealize-operations-6-4.html .
∎ Scripts de la página de la comunidad de VMware para "DPM proactivo"

( http://communities.vmware.com/docs/DOC-10230 ) proporciona un conjunto de scripts Perl con los que
Los usuarios de DPM pueden realizar una administración de energía más proactiva.
Uso de DPM con VMware High Availability (HA)

∎ DPM respeta la configuración de VMware High Availability (HA) y la tiene en cuenta al realizar
recomendaciones para poner un host o sacarlo del modo de espera. En un clúster con HA habilitado, DPM
mantiene el exceso de capacidad de encendido para cumplir con los requisitos de HA.
Esto podría significar que es posible que no se admitan máquinas virtuales adicionales incluso si el clúster parece tener
recursos disponibles (como en un clúster DRS con HA habilitado). Además, para reservar el adicional
capacidad para HA, es posible que se pongan menos hosts en modo de espera que si el clúster no tuviera HA habilitada.
Estos factores deben tenerse en cuenta al configurar HA y DPM.
∎ Si VMware HA está habilitado en un clúster y una o más máquinas virtuales están encendidas, DPM mantiene un
mínimo de dos hosts encendidos. Esto es cierto incluso si el control de admisión de HA está deshabilitado.
Para obtener más información sobre el ajuste del rendimiento de DPM, consulte Conceptos de administración de energía distribuida de VMware y
Utilice .
VMware, Inc. 75
Página 76
Control de E / S de almacenamiento de VMware vSphere

VMware vSphere ® Storage I / O Control es una función que permite asignar los recursos de un almacén de datos completo
según se desee entre las distintas máquinas virtuales que acceden al almacén de datos. Comenzando con vSphere 6.5, almacenamiento
I / O Control ahora funciona con almacenes de datos SSD.
N OTA Para controlar cómo un host ESXi individual asigna los recursos de E / S de almacenamiento que recibe (en lugar de
asignar los recursos de E / S de un almacén de datos completo), consulte “Asignación de recursos de E / S de almacenamiento” en la página 35 .
Con el Control de E / S de almacenamiento deshabilitado (el valor predeterminado), cada host que accede a un almacén de datos obtiene una parte de ese
los recursos del almacén de datos correspondientes a la proporción de la carga de trabajo de E / S total del almacén de datos que proviene de ese
anfitrión.
Incluso con Storage I / O Control habilitado, no se realiza ninguna acción hasta que se activa Storage I / O Control, que
ocurre automáticamente cuando se detecta una congestión en el almacén de datos. Storage I / O Control ajusta el umbral de activación
para adaptarse al entorno del centro de datos en el que se ejecuta.
Los recursos de E / S del almacén de datos se pueden asignar según la siguiente configuración:
∎ Los recursos compartidos de IOPS designan la proporción de IOPS de un almacén de datos que recibirá una máquina virtual. Las acciones son
evaluado globalmente y la parte de los recursos del almacén de datos que recibe cada host es la suma de los recursos compartidos
de las máquinas virtuales que se ejecutan en ese host dividido por la suma de los recursos compartidos de todas las máquinas virtuales
acceder a ese almacén de datos.
∎ Las reservas de IOPS , nuevas en vSphere 6.5, establecen un límite inferior en las IOPS que recibirá una máquina virtual.
Storage I / O Control garantizará este mínimo siempre que el hardware lo admita.
∎ Los límites de IOPS establecen un límite superior en las IOPS que recibirá una máquina virtual.
Para habilitar Storage I / O Control, desde vSphere Web Client en el panel Navigator , seleccione la pestaña Storage ,
seleccione un almacén de datos, seleccione la pestaña Configurar , seleccione General , a la derecha de Capacidades del almacén de datos, haga clic en
Editar ... , seleccione la casilla de verificación Habilitar control de E / S de almacenamiento y , a continuación, haga clic en Aceptar .
Para obtener más información sobre el rendimiento del Control de E / S de almacenamiento, especialmente con almacenamiento SSD, consulte Rendimiento
Implicaciones de los almacenes de datos SSD habilitados para E / S de almacenamiento en VMware vSphere 6.5 .
76 VMware, Inc.
Página 77
Programador de recursos distribuidos de VMware Storage (Storage DRS)

El programador de recursos distribuidos de almacenamiento (Storage DRS) proporciona equilibrio de carga de E / S y equilibrio de espacio en
almacenes de datos dentro de un clúster de almacenes de datos, además de proporcionar prevención de espacio fuera de espacio. Esto puede evitar el almacenamiento
cuellos de botella en el desempeño o abordarlos si ocurren.
Esta sección enumera las prácticas y configuraciones de Storage DRS recomendadas por VMware para
actuación.
∎ Al decidir qué almacenes de datos agrupar en un clúster de almacenes de datos, intente elegir almacenes de datos que sean
lo más homogéneo posible en términos de protocolo de interfaz de host (es decir, FCP, iSCSI, NFS), nivel RAID y
características de presentación. Recomendamos no mezclar SSD y discos duros en el mismo clúster de almacén de datos.
∎ No configure en un clúster de almacenes de datos más almacenes de datos o discos virtuales que el máximo permitido en
Valores máximos de configuración para vSphere 6.5 .
∎ Si bien un clúster de almacenes de datos puede tener tan solo dos almacenes de datos, cuantos más almacenes de datos tenga un clúster, más
flexibilidad Storage DRS tiene que equilibrar mejor la carga de E / S y el uso de la capacidad de ese clúster.
∎ Cuando sea posible, asegúrese de que el conjunto completo de hosts pueda acceder a todos los almacenes de datos de un clúster de almacenes de datos.
que pueden acceder a los otros almacenes de datos de ese clúster. Esta conectividad completa permite que Storage DRS haga
mejores decisiones al abordar cargas elevadas de E / S o problemas de falta de espacio.
∎ A medida que agrega cargas de trabajo, debe monitorear la latencia de E / S del almacén de datos en el gráfico de rendimiento para el
clúster de almacén de datos, especialmente durante las horas pico. Si la mayoría o todos los almacenes de datos de un clúster de almacenes de datos
operar consistentemente con latencias cercanas al umbral de congestión usado por Storage I / O Control (establecido en
30 ms de forma predeterminada, pero a veces se ajusta para reflejar las necesidades de una implementación en particular), esto podría ser un
indicación de que no quedan suficientes recursos de E / S de repuesto en el clúster del almacén de datos. En este caso, considere
agregar más almacenes de datos al clúster de almacenes de datos o reducir la carga en ese clúster de almacenes de datos.
N OTA Asegúrese de que, al agregar más almacenes de datos para aumentar los recursos de E / S en el clúster de almacenes de datos,
sus cambios realmente agregan recursos, en lugar de simplemente crear formas adicionales de acceder a los mismos
discos físicos subyacentes.
∎ De forma predeterminada, las reglas de afinidad de Storage DRS mantienen todos los discos virtuales de una máquina virtual en el mismo almacén de datos
(usando afinidad intra-VM). Sin embargo, puede dar a Storage DRS más flexibilidad en el equilibrio de carga de E / S,
potencialmente aumentando el rendimiento, al anular la regla de afinidad intra-VM predeterminada. Esto se puede hacer por
ya sea una máquina virtual específica o para todo el clúster de almacenes de datos.
∎ Las reglas de antiafinidad entre máquinas virtuales se pueden utilizar para mantener los discos virtuales de dos o más
que las máquinas se coloquen en el mismo almacén de datos, lo que podría mejorar el rendimiento en algunos
situaciones. Se pueden utilizar, por ejemplo, para separar la E / S de almacenamiento de múltiples cargas de trabajo que tienden a
tener cargas pico simultáneas pero intermitentes, evitando que esas cargas pico se combinen para estresar un
almacén de datos único.
∎ Si un clúster de almacén de datos contiene LUN de aprovisionamiento fino, asegúrese de que esos LUN no se queden sin respaldo
Espacio del disco. Si muchos LUN de aprovisionamiento fino en un clúster de almacén de datos se quedan sin disco de respaldo simultáneamente
espacio (muy posible si todos comparten la misma tienda de respaldo), esto podría causar un almacenamiento excesivo de vMotion
actividad o limitar la capacidad de Storage DRS para equilibrar el uso del almacén de datos.
VMware, Inc. 77
Página 78
Alta disponibilidad de VMware vSphere

VMware vSphere ® High Availability (HA) minimiza el tiempo de inactividad de la máquina virtual al monitorear hosts,
máquinas o aplicaciones dentro de máquinas virtuales, luego, en caso de que se detecte una falla, reiniciar las
máquinas en hosts alternativos.
VMware High Availability en general

∎ Cuando vSphere HA está habilitado en un clúster, todos los hosts activos (aquellos que no están en modo de espera, modo de mantenimiento,
o desconectado) participar en una elección para elegir el anfitrión maestro para el clúster; todos los demás hosts se convierten
esclavos. El maestro tiene una serie de responsabilidades, incluida la supervisión del estado de los hosts en el
clúster, proteger las máquinas virtuales encendidas, iniciar la conmutación por error y notificar el estado de salud del clúster
a vCenter Server. El maestro se elige en función de las propiedades de los hosts, con preferencia
al que está conectado al mayor número de almacenes de datos. Servir en el papel de maestro tendrá poco o
ningún efecto sobre el rendimiento de un anfitrión.
∎ Cuando el host maestro no puede comunicarse con un host esclavo a través de la red de administración, el maestro usa
latido del almacén de datos para determinar el estado de ese host esclavo. De forma predeterminada, vSphere HA usa dos
almacenes de datos para latidos, lo que da como resultado tasas de conmutación por error falsas muy bajas. Para reducir las posibilidades de falsas
conmutación por error aún más, con el costo potencial de un impacto muy leve en el rendimiento, puede utilizar la
opción avanzada das.heartbeatdsperhost para cambiar el número de almacenes de datos utilizados para latidos
(hasta un máximo de cinco) y puede configurar vCenter Server para dar preferencia a los almacenes de datos que no
compartir un punto de falla con la red utilizada por HA.
∎ La habilitación de HA en un host reserva algunos recursos de host para los agentes de HA, lo que reduce ligeramente el host disponible
capacidad para encender máquinas virtuales.
∎ Cuando HA está habilitado, vCenter Server reserva suficientes recursos no utilizados en el clúster para admitir
capacidad de conmutación por error especificada por la política de control de admisión elegida. Esto puede reducir la cantidad de
máquinas que el clúster puede admitir.
Para obtener más detalles sobre HA, consulte Disponibilidad de vSphere .
Protección de componentes de máquinas virtuales (VMCP)

∎ La protección de componentes de máquinas virtuales (VMCP) es una función que permite a HA detectar fallas de FC, iSCSI,
o conectividad de almacenamiento NFS y proporcionan recuperación automatizada para las máquinas virtuales afectadas. VMCP es
deshabilitado por defecto; cuando la función está habilitada, el agente de alta disponibilidad consume un poco más de ciclos de CPU.
Para obtener más detalles sobre VMCP, incluido cómo habilitar la función, consulte la guía de disponibilidad de vSphere para ESXi
6.5 y vCenter Server 6.5.
78 VMware, Inc.
Página 79
Tolerancia a fallas de VMware
VMware Fault Tolerance (FT) proporciona disponibilidad continua de la máquina virtual en caso de falla del servidor.
Debido a que FT usa HA, la mayoría de las mejores prácticas de HA (descritas en “VMware vSphere High Availability” en la página 78 )
también son relevantes para FT.
Cuando FT está habilitado en una máquina virtual, esa máquina virtual se denomina máquina virtual primaria FT, o
primario. Cada una de estas máquinas virtuales primarias de FT está emparejada con otra máquina virtual, llamada FT
máquina virtual secundaria o secundaria. Los roles de primario y secundario son dinámicos: el virtual
las máquinas pueden intercambiar roles cuando hay una conmutación por error.
∎ FT requiere algunos recursos adicionales. Antes de activar FT para una máquina virtual, asegúrese de tener
los siguientes recursos disponibles:
∎ Almacenamiento : la máquina virtual secundaria consume almacenamiento para su archivo de configuración, así como su
Archivos VMDK, cada uno de los cuales son copias completas de los archivos VMDK del primario. Asegúrate de tener
espacio para la máquina virtual secundaria; este espacio puede estar en el mismo almacén de datos que el principal o un
diferente almacén de datos. Siempre que una máquina virtual esté protegida por FT, los cambios en los archivos VMDK del primario
se reflejará en los archivos VMDK del secundario.
∎ Memoria : las máquinas virtuales primarias y secundarias reciben automáticamente una memoria completa
reserva, asegurando que los globos o el intercambio nunca sean necesarios en ninguna de las máquinas virtuales. Hacer
asegúrese de que los hosts en los que se ejecutarán las máquinas virtuales primarias y secundarias tengan suficiente
memoria para esta reserva.
Cuando la máquina virtual principal está encendida, tanto la máquina virtual primaria como la secundaria
consumir memoria adicional adicional. La cantidad depende del tamaño de la memoria de la máquina virtual, pero es
típicamente en el rango de 1GB-2GB cada uno.
∎ Red : asegúrese de que el tráfico de registro de FT lo lleve al menos una NIC de 10 Gb / s. Mientras que la cantidad de
el tráfico de la red depende de la carga de trabajo, incluso una máquina virtual con varias CPU virtuales puede requerir varias
Gb / s.
∎ CPU : la máquina virtual secundaria requiere algunos ciclos de CPU adicionales para admitir
sincronización entre el primario y el secundario. Esto es proporcional a la actividad de la
VM es, y es generalmente baja.
∎ Antes de que una máquina virtual esté protegida por FT, la primaria y la secundaria deben someterse a una
sincronización de su memoria y estados VMDK. Esto se hace a través de una memoria en vivo y un disco.
migración que se produce mientras se ejecuta la máquina virtual FT. La sincronización del disco, en particular, puede
ser una operación larga, así que espere un retraso antes de que se complete y la máquina virtual se convierta en FT
protegido.
La sincronización inicial ocurre en los siguientes casos. Debido a que este proceso puede requerir muchos recursos,
Evite realizar estas operaciones con más frecuencia de la necesaria.
∎ Cuando FT está activado para una máquina virtual en ejecución.
∎ Cuando una máquina virtual FT cambia de apagada a encendida.
∎ Cuando la operación Reanudar tolerancia a fallos se ejecuta en una máquina virtual FT en ejecución que
se le ha realizado la operación Suspender tolerancia a fallos .
∎ Cuando la protección de FT se restablece después de la falla del primario o del secundario. Esta
podría deberse a una falla de hardware o activarse intencionalmente con la prueba de conmutación por error o prueba
Reinicie las operaciones secundarias . En cualquier caso, la sincronización inicial se ejecutará para restablecer FT.
proteccion.
∎ La migración en vivo que tiene lugar para la sincronización inicial puede saturar brevemente la red vMotion
link y también puede causar picos en la utilización de la CPU.
∎ Evite usar el mismo enlace de red para el tráfico de registro FT y otro tráfico de red (como vMotion
tráfico); un tipo de tráfico puede afectar negativamente al otro, especialmente cuando varias máquinas virtuales FT
se ejecutan en el mismo host.
VMware, Inc. 79
Página 80
∎ El tráfico de registro FT es asimétrico; la mayor parte del tráfico fluye de primaria a secundaria. Congestión
Por lo tanto, el tráfico de registro se puede reducir distribuyendo primarios en múltiples hosts. Por ejemplo
en un clúster con dos hosts ESXi y dos máquinas virtuales FT, colocando una de las máquinas virtuales principales
en cada uno de los hosts permite que el tráfico de registro FT utilice el ancho de banda de la red de forma bidireccional.
∎ Evite colocar más de cuatro máquinas virtuales FT en un solo host o tener más de ocho FT en total
CPU virtuales en un host. Además de reducir la probabilidad de saturar la NIC de registro de FT, esto también limita
el número de migraciones en vivo simultáneas necesarias para crear nuevas máquinas virtuales secundarias en el
caso de una falla del host.
∎ Si la máquina virtual secundaria se queda sin recursos (como ancho de banda de registro FT, ancho de banda de almacenamiento,
o ciclos de CPU) que la máquina virtual principal tiene suficiente, entonces ESXi podría ralentizar la principal para permitir
el secundario para mantenerse al día.
Por ejemplo, si el host en el que se ejecuta el secundario también tiene muchos otros secundarios saturando
el ancho de banda de registro de FT, pero el host en el que se ejecuta el primario tiene solo una máquina virtual de FT,
entonces esa primaria podría ralentizarse para adaptarse a la falta de recursos en la secundaria. El seguimiento
Las recomendaciones ayudan a evitar esta situación:
∎ Asegúrese de que los hosts en los que se ejecutan las máquinas virtuales primarias y secundarias estén relativamente cerca
igualado en términos de rendimiento de CPU, carga de máquina virtual (incluyendo y especialmente FT virtual
carga de la máquina), ancho de banda y carga de registro FT, y ancho de banda y carga del almacén de datos. Cuellos de botella en
Cualquiera de estas áreas en la primaria o secundaria puede ser perjudicial para el desempeño de la otra
máquina virtual.
∎ Asegúrese de que la configuración del esquema de administración de energía (tanto en el BIOS como en ESXi)
El escalado de frecuencia es consistente entre los hosts en los que el virtual primario y secundario
las máquinas funcionan.
∎ Habilite las reservas de CPU para la máquina virtual principal (que se duplicará para la secundaria
máquina virtual) para garantizar que el secundario obtenga ciclos de CPU cuando los requiera.
∎ Cuando FT está habilitado para una máquina virtual, esa máquina virtual solo puede usar CPU de hardware y MMU
virtualización (para obtener información sobre la virtualización asistida por hardware, consulte “asistida por hardware
Virtualización ” en la página 11 y“Configuración de ESXi para virtualización asistida por hardware” en la página 23) .
∎ Aunque FT funcionará en muchas CPU de generaciones anteriores (para conocer los requisitos mínimos, consulte vSphere
Guía de disponibilidad para ESXi 6.5 y vCenter Server 6.5), para obtener el mejor rendimiento, recomendamos la
siguientes CPU:
∎ Plataforma Intel:
Generación Intel “Haswell” (como Intel Xeon 2600-v3 Series) o posterior.
∎ Plataforma AMD:
Generación AMD "Piledriver" (como AMD Opteron 6300 Series) o posterior.
80 VMware, Inc.
Página 81
Administrador de actualizaciones de VMware vSphere

VMware vSphere Update Manager proporciona un marco de gestión de parches para VMware vSphere. Puede ser
se utiliza para aplicar parches, actualizaciones y actualizaciones a hosts VMware ESX y ESXi, VMware Tools y virtual
hardware, etc.
Además del material presentado aquí, se puede obtener más información sobre el rendimiento de vSphere Update Manager.
se puede encontrar en el informe técnico de VMware vSphere Update Manager Performance and Best Practices .
Update Manager implementado en Windows

Para implementaciones de vCenter Server en Windows, Update Manager se puede ejecutar en el mismo host que el
vCenter Server o en un host diferente y se puede configurar para compartir una base de datos con vCenter Server o para tener
su propia base de datos. Las siguientes recomendaciones se aplican a estas implementaciones de Windows:
∎ Cuando hay más de 300 máquinas virtuales o más de 30 hosts, separe el Administrador de actualizaciones
base de datos de la base de datos de vCenter Server.
∎ Cuando hay más de 1000 máquinas virtuales o más de 100 hosts, separe el Administrador de actualizaciones
servidor de vCenter Server y separe la base de datos de Update Manager de vCenter Server
base de datos.
∎ Asigne discos físicos separados para el almacén de parches de Update Manager y la base de datos de Update Manager.
∎ Para reducir la latencia de la red y las caídas de paquetes, mantenga al mínimo el número de saltos de red entre
el sistema del servidor de Update Manager y los hosts ESXi.
∎ Para almacenar en caché los archivos de parche de uso frecuente en la memoria, asegúrese de que el host del servidor de Update Manager
al menos 2 GB de RAM.
Update Manager implementado en Linux (con vCenter Server Appliance)

A partir de vSphere 6.5, las implementaciones de vCenter Server Appliance (vCSA) comparten un host Linux y un
base de datos con Update Manager. El servicio Update Manager updatemgr está habilitado e iniciado de forma predeterminada.
una vez que el aparato se enciende. Las siguientes recomendaciones se aplican a estas implementaciones de Linux:
N OTA A pesar de los recursos compartidos, las implementaciones de Update Manager en Linux admiten el mismo
configuraciones como implementaciones de Windows.
∎ Asegúrese de que la base de datos tenga suficiente espacio para el inventario de vCenter y los datos de Update Manager.
La inicialización de Update Manager necesita alrededor de 150 MB, y el uso de su base de datos puede aumentar hasta aproximadamente
100 MB por mes.
∎ La cantidad de memoria consumida por Update Manager se ve afectada principalmente por el tamaño del inventario,
especialmente la cantidad de máquinas virtuales. Supervisar periódicamente el uso de recursos por parte de Update Manager,
así como otros servicios, utilizando herramientas top, htop u otras, especialmente cuando el sistema está bajo una carga pesada.
Actualice los recursos o la configuración cuando sea necesario.
∎ Un complemento de Update Manager (de aproximadamente 6 MB de tamaño) se instalará automáticamente en vSphere Web
Cliente la primera vez que el cliente web se conecta a un vCenter Server Appliance que ejecuta la actualización
Servicio de gerente. (Por el contrario, este complemento debe instalarse manualmente cuando el cliente web se utiliza con
Update Manager en Windows).
Recomendaciones generales de Update Manager

∎ Para la vista de cumplimiento de todas las líneas base adjuntas, la latencia aumenta linealmente con la cantidad de
líneas de base. Por lo tanto, recomendamos eliminar las líneas de base no utilizadas, especialmente cuando el tamaño del inventario
es largo.
∎ La actualización de VMware Tools es más rápida si la máquina virtual ya está encendida. De lo contrario, actualice
El administrador debe encender la máquina virtual antes de la actualización de VMware Tools, lo que podría aumentar la
latencia general.
VMware, Inc. 81
Página 82
∎ La actualización del hardware de la máquina virtual es más rápida si la máquina virtual ya está apagada. De otra manera,
Update Manager debe apagar la máquina virtual antes de actualizar el hardware virtual, lo que podría
aumentar la latencia general.
N OTA Debido a que VMware Tools debe estar actualizado antes de actualizar el hardware virtual, Update Manager
Es posible que deba actualizar VMware Tools antes de actualizar el hardware virtual. En tales casos, el proceso es
más rápido si la máquina virtual ya está encendida.
Remediación del clúster de Update Manager

∎ Limitar el nivel de simultaneidad de la remediación (es decir, el número máximo de hosts que se pueden
actualizado simultáneamente) a la mitad de la cantidad de hosts en el clúster puede reducir la intensidad de vMotion, a menudo
lo que resulta en un mejor rendimiento general de corrección del host. (Esta opción se puede configurar usando el cluster
asistente de remediación.)
∎ Cuando todos los hosts de un clúster están listos para ingresar al modo de mantenimiento (es decir, no tienen máquinas virtuales
encendido), la corrección de host simultánea será normalmente más rápida que la corrección de host secuencial.
∎ Es más probable que la corrección del clúster tenga éxito cuando el clúster no se utiliza más del 80%. Así para
clústeres muy utilizados, la corrección de clústeres se realiza mejor durante los períodos de menor actividad, cuando la utilización
cae por debajo del 80%. Si esto no es posible, es mejor suspender o apagar algunas máquinas virtuales antes
se inicia la operación.
Limitación de ancho de banda de Update Manager

∎ Durante las operaciones de remediación o preparación, los hosts descargan parches. En redes lentas puedes prevenir
la congestión de la red mediante la configuración de los hosts para que utilicen la limitación del ancho de banda. Al asignar comparativamente más
ancho de banda a algunos hosts, esos hosts pueden finalizar más rápidamente la remediación o la preparación.
∎ Para garantizar que el ancho de banda de la red se asigne como se esperaba, la suma del ancho de banda asignado a
varios hosts en un solo enlace de red no deben exceder el ancho de banda de ese enlace. De lo contrario, los anfitriones
intentará utilizar el ancho de banda hasta su asignación, lo que resultará en una utilización del ancho de banda que podría no
ser proporcional a las asignaciones configuradas.
∎ La limitación del ancho de banda se aplica solo a los hosts que están descargando parches. Si un anfitrión no está en proceso de
descarga de parches, cualquier configuración de limitación de ancho de banda en ese host no afectará el ancho de banda
disponible en el enlace de red.
82 VMware, Inc.
Página 83
VMware Virtual SAN (vSAN)

VMware Virtual SAN (vSAN) permite que los recursos de almacenamiento conectados directamente a los hosts ESXi se utilicen para
almacenamiento distribuido y al que acceden varios hosts ESXi. Siga las recomendaciones de esta sección para
Mejor presentación.
VSAN híbrido versus todo flash

Las implementaciones de vSAN pueden ser "híbridas" o all-flash:
∎ En las implementaciones híbridas de vSAN, se utiliza una capa de almacenamiento SSD rápido como un "nivel de almacenamiento en caché" para proporcionar una lectura y
caché de escritura para una capa de disco magnético más grande (pero más lenta) (el "nivel de capacidad").
∎ En las implementaciones de vSAN todo flash, el almacenamiento SSD se utiliza tanto para el nivel de almacenamiento en caché (que, en vSAN todo flash,
proporciona solo una caché de escritura) y el nivel de capacidad (que proporciona el almacenamiento persistente).
Si bien las implementaciones híbridas de vSAN son muy rápidas, las implementaciones all-flash son aún más rápidas. Además, todo flash
vSAN admite RAID-5, RAID-6, deduplicación y compresión. Al reducir los requisitos de almacenamiento, estos
Las funciones pueden reducir la diferencia de costo efectiva entre vSAN híbrido y todo flash.
Selección y diseño de hardware de vSAN
Selección y diseño de hardware para vSAN híbrido
∎ En una vSAN híbrida, todas las escrituras van primero a las SSD que componen el nivel de almacenamiento en caché y los aciertos de la caché de lectura de vSAN
(que idealmente constituyen una gran proporción de las lecturas) también provienen de ese nivel.
Por lo tanto, la relación entre el nivel de almacenamiento en caché (SSD) y el nivel de capacidad (HDD) tiene un efecto significativo en vSAN híbrido
actuación. Una relación más alta de SSD a HDD generalmente mejora el rendimiento, pero a un costo más alto.
Selección y diseño de hardware para vSAN todo flash
∎ En un vSAN todo flash, todas las escrituras de vSAN van primero a los SSD del nivel de almacenamiento en caché y luego se desglosan a la capacidad
SSD de nivel; las lecturas provienen directamente de los SSD de nivel de capacidad (excepto las lecturas de datos aún no desestabilizados, que
provienen de los SSD del nivel de almacenamiento en caché).
El rendimiento de los SSD del nivel de almacenamiento en caché es un factor importante en el rendimiento general de un dispositivo todo flash.
vSAN. El uso de SSD avanzados y más rápidos, como unidades de disco NVMe, para el nivel de almacenamiento en caché puede
mejorar el rendimiento, incluso cuando el nivel de capacidad utiliza SSD de menor rendimiento.
Selección y diseño de hardware para vSAN en general
∎ vSAN funciona mejor cuando los recursos del disco se distribuyen de manera relativamente uniforme entre los hosts ESXi que hacen
hasta el clúster de vSAN.
∎ Los discos en una vSAN están organizados en grupos de discos, y cada grupo de discos consta de un disco de caché y
uno o más discos de capacidad. Por lo general, cuantos más grupos de discos por host, mejor funciona vSAN.
Consideraciones sobre la red vSAN

∎ Si bien las implementaciones pequeñas de vSAN pueden funcionar bien con enlaces Ethernet de 1 Gb / s entre los hosts ESXi en el
vSAN, la mayoría de las implementaciones funcionarán mejor con enlaces de 10 Gb / so más rápidos.
∎ Los marcos gigantes, aunque no deberían afectar el rendimiento si se configuran correctamente, no proporcionarán mucho
mejora en el rendimiento de vSAN.
Para obtener más información sobre la configuración de la red de vSAN, consulte VMware Virtual SAN 6.2 Network Design
Guía (aunque escrita para vSAN 6.2, la mayor parte del contenido se aplica a vSAN 6.5).
Configuración y uso de vSAN

∎ Varias políticas de almacenamiento de máquinas virtuales en vSAN pueden afectar el rendimiento de vSAN. Éstas incluyen:
VMware, Inc. 83
Página 84
∎ Número de bandas de disco por objeto
∎ Reserva de caché de lectura de Flash
∎ Número de fallas a tolerar
∎ Reserva de espacio de objetos
En la mayoría de los casos, estas opciones permiten un equilibrio entre el uso de recursos y el rendimiento. Estos son
descrito con más detalle en el documento al que se hace referencia a continuación.
∎ La suma de comprobación de software de un extremo a otro está habilitada de forma predeterminada para vSAN, pero se puede deshabilitar en un virtual
máquina o por objeto. La desactivación de la suma de comprobación de vSAN normalmente solo se realizará cuando la suma de comprobación
la funcionalidad ya la proporciona una capa de aplicación. Si bien la operación de suma de comprobación introduce
algunos gastos generales, su impacto en el rendimiento es pequeño, debido en parte a un caché en memoria dedicado.
∎ Del mismo modo que los recursos de disco generalmente deben distribuirse de manera relativamente uniforme entre los hosts de vSAN, para el mejor
Las máquinas virtuales de rendimiento también deben distribuirse de manera relativamente uniforme entre esos hosts. VMware
DRS puede ayudar a lograrlo (ver “Programador de recursos distribuidos de VMware (DRS)” en la página 70) .
∎ La deduplicación y la compresión, un par de funciones disponibles solo en implementaciones de vSAN todo flash, pueden
reducir drásticamente los requisitos de almacenamiento, pero con una penalización de rendimiento moderada. Porque el
el impacto en el rendimiento es menos significativo con cargas de trabajo de bajo rendimiento y tamaños de bloques pequeños, cargas de trabajo
con estas características son especialmente adecuados para utilizar esta función.
Para obtener más información sobre el rendimiento de vSAN con deduplicación y compresión, consulte VMware
Informe de rendimiento de Virtual SAN 6.2 con cargas de trabajo de procesamiento de transacciones en línea (aunque escrito para vSAN
6.2, la mayor parte del contenido se aplica a vSAN 6.5).
∎ RAID-5 y RAID-6 (también conocidos colectivamente como codificación de borrado), funciones disponibles solo en vSAN all-flash
implementaciones, puede proporcionar protección de datos con una penalización de rendimiento relativamente pequeña (debido a la alta
capacidad de rendimiento del almacenamiento todo flash). La replicación (es decir, RAID-1), sin embargo, sigue ofreciendo la mejor
rendimiento, pero a costa de una eficiencia de espacio significativamente menor.
Para obtener más información sobre el rendimiento de vSAN con codificación de borrado, consulte VMware Virtual SAN 6.2
Informe de rendimiento con cargas de trabajo de procesamiento de transacciones en línea (aunque escrito para vSAN 6.2, la mayoría de
el contenido se aplica a vSAN 6.5).
Para obtener más detalles sobre las opciones de configuración de vSAN y otros consejos de rendimiento de vSAN, consulte VMware Virtual
Guía de diseño de red SAN 6.2 (aunque escrita para vSAN 6.2, la mayor parte del contenido se aplica a vSAN 6.5) y
Guía de diseño y dimensionamiento de VMware Virtual SAN .
Cifrado de vSAN
Como novedad en vSphere 6.5, el cifrado de vSAN cifra los datos cuando se escriben en un dispositivo de almacenamiento, pero los transfiere
sin cifrar. (Para cifrar los datos antes de transferirlos, consulte“Cifrado de máquina virtual de vSphere
Recomendaciones ” en la página 36 ). Esto permite que vSAN deduplica y / o comprima los datos, operaciones que
son difíciles o imposibles de realizar con datos cifrados.
∎ La sobrecarga de recursos del cifrado de vSAN se encuentra principalmente en la utilización de la CPU. Por lo tanto, con suficiente CPU
recursos, las implementaciones típicas (es decir, aquellas que no usan almacenamiento ultrarrápido) no verán
impacto en el rendimiento.
∎ Para minimizar significativamente el uso de CPU adicional debido al cifrado de VM, elija procesadores que
compatible con AES-NI (consulte "Soporte AES-NI" en la página 12) , especialmente algunas versiones recientes de procesador en las que
la implementación de AES-NI se optimiza aún más.
∎ Asegúrese de que AES-NI esté habilitado en BIOS. En algunos casos, es posible que se requiera una actualización de BIOS para AES-NI
apoyo.
84 VMware, Inc.
Página 85
Volúmenes virtuales de VMware (VVols)

VMware Virtual Volumes (VVols) utiliza la comunicación entre el software VMware y el almacenamiento SAN o NAS
matrices para permitir un control más preciso sobre las políticas de almacenamiento de la máquina virtual.
Además de las recomendaciones de esta sección, también es una buena idea leer la información de su proveedor de almacenamiento.
documentación, ya que cada proveedor puede tener sus propias recomendaciones o mejores prácticas.
Consideraciones de hardware VVol

∎ Los VVols solo funcionan en hardware de almacenamiento que admita las API de vStorage para el reconocimiento de almacenamiento (VASA)
versión 2.0 o posterior con soporte para el perfil de API de Virtual Volumes.
∎ El rendimiento de VVol varía significativamente entre los proveedores de hardware de almacenamiento. Antes de elegir el almacenamiento
hardware, confirme que proporcionará el rendimiento VVol que espera.
∎ Al elegir el hardware, tenga en cuenta las limitaciones impuestas por la implementación del arreglo. UN
La máquina virtual basada en VVol, por ejemplo, requiere una serie de VVols (configuración, intercambio, datos, instantáneas potenciales, etc.)
y el límite en la cantidad de VVols que puede administrar un arreglo puede ser tan importante como el límite en su almacenamiento
capacidad.
∎ Los VVols requieren un proveedor de VASA (a veces llamado "proveedor de almacenamiento" o "VP" abreviado), un software
capa que presenta las capacidades de la matriz de almacenamiento al host ESXi y permite que ESXi realice
operaciones de gestión relacionadas con la máquina y VVol. Para algunas matrices de almacenamiento, el proveedor de VASA se ejecuta en
el arreglo, para otros se ejecuta en una máquina virtual o en un servidor físico dedicado.
N OTA Si su proveedor de VASA se ejecuta en una máquina virtual:
∎ Tenga cuidado de no migrarlo al almacenamiento VVol.
∎ Considere usar vSphere HA (consulte “VMware vSphere High Availability” en la página 78) para protegerlo.
∎ Implemente un plan de respaldo adecuado para ello.
∎ El rendimiento de VVol depende en gran medida del ancho de banda entre el host ESXi, el proveedor de VASA y
la matriz. Para obtener el mejor rendimiento, el tráfico de operaciones de E / S y el tráfico de operaciones de gestión deben estar activados.
enlaces separados, con el enlace de E / S con un ancho de banda de al menos 10 Gb / s.
Si el tráfico de operaciones de E / S y el tráfico de operaciones de gestión deben compartir el mismo enlace de red física,
debe enrutarse a través de NIC virtuales independientes.
Rendimiento de la carga de trabajo de VVol

Las cargas de trabajo de VVol se dividen en dos categorías principales: cargas de trabajo de administración y cargas de trabajo de E / S.
Rendimiento de la operación de gestión de VVol
Las siguientes recomendaciones de rendimiento se aplican a las operaciones de gestión de VVol:
∎ Las operaciones de aprovisionamiento de máquinas virtuales en VVol varían en rendimiento en relación con NFS o SAN nativos:
∎ Las operaciones de clonación en VVol son significativamente más rápidas que en NFS o SAN nativas. Los clones se descargan
a matrices y puede ser implementado por la matriz de una manera eficiente en el espacio desde el momento en que se
creado (ya que la matriz es libre de compartir los bloques de almacenamiento subyacentes).
∎ Las operaciones de alimentación (encendido y apagado) en VVol se realizan de manera similar a NFS o SAN nativos.
∎ Las operaciones de destrucción en VVol suelen tardar un poco más que en NFS o SAN nativos, aunque esto
varía algo con los diferentes proveedores de matrices.
∎ El rendimiento de la migración de almacenamiento entre dos almacenes de datos VVol es más rápido que la migración que involucra uno o
más almacenes de datos que no son VVol.
∎ El rendimiento de VVol en las operaciones de instantáneas varía entre la creación y la eliminación:
VMware, Inc. 85
Página 86
∎ La creación de instantáneas funciona de manera similar entre VVol y NFS o SAN nativos.
∎ Las eliminaciones de instantáneas en VVols se descargan en la matriz y, dado que no es necesario volver a emitir
escrituras previamente dirigidas al archivo de registro de rehacer, normalmente serán de duración más predecible y
más rápido que en NFS o SAN nativos.
Rendimiento de operación de E / S de VVol
Las siguientes recomendaciones de rendimiento se aplican a las operaciones de E / S de VVol:
∎ Debido a que la ruta de E / S de VVol es casi la misma que la ruta de E / S para los almacenes de datos que no son de VVol, el rendimiento
y la latencia en un almacén de datos VVol es muy similar a la de un almacén de datos no VVol similar.
∎ I / O a VVols se realiza a través de Protocol Endpoints (PE), y los proveedores pueden tener consejos específicos sobre
configurar el número o tipo de PE LUN para su matriz. Hay pocos consejos generales que se puedan dar
sobre este tema, ya que los aspectos de rendimiento dependen en gran medida de la implementación de la matriz particular (por
ejemplo, poner en cola los comandos a nivel de PE frente a enviarlos directamente a una cola por VVol, profundidad
de las colas en el lado de la matriz, cómo interactúa esto con las características de QoS, etc.). Tenga en cuenta que el almacenamiento central
La capa permite que se pongan en cola cuatro veces más E / S para los LUN de punto final de protocolo (PE) que para los
(datos) LUN.
∎ Las instantáneas en VVols se descargan a la matriz, que crea la instantánea utilizando medios nativos del lado de la matriz,
como hacer automáticamente su propia copia en escritura (COW). Las instantáneas de VVol suelen convertirse
comparable a las instantáneas de LUN en la matriz. Por esta razón, el rendimiento de VVol en discos con instantáneas
no se degrada a medida que aumentan los niveles de instantáneas, como lo hace en NFS o SAN nativos (donde vSphere crea y
administra las instantáneas mediante archivos de registro de rehacer). Esto puede llevar a que los VVols tengan una mejor
rendimiento para instantáneas que NFS o SAN nativos.
Esto significa que la consolidación de una instantánea es ahora una operación rápida, incluso si una VM se ha estado ejecutando con un
instantánea en su lugar, ya que la matriz generalmente no requiere que los datos acumulados en un registro de rehacer sean
reescrito en el disco original. También significa que puede usar instantáneas generosamente (para copias de seguridad en máquinas virtuales en ejecución,
por ejemplo) ya que la matriz maneja la copia en escritura u otras operaciones necesarias para mantener la
instantánea y, por lo tanto, la E / S de la máquina virtual al disco no se ve afectada. Ya no hay una actuación
penalización por ejecutar una máquina virtual con una instantánea en su lugar.
Recomendaciones de configuración de VVol

∎ Porque con VVols cada uno de los discos virtuales de sus máquinas virtuales se almacena como un virtual de datos individuales.
volumen, es posible asignar distintas políticas de almacenamiento de Storage Policy Based Management (SPBM)
a cada disco virtual, lo que permite optimizar el rendimiento de cada disco. Por ejemplo, una base de datos
El disco puede requerir una política de almacenamiento diferente a la de un disco de registro de base de datos.
Esto también permite habilitar servicios para discos virtuales específicos. Por ejemplo, podría tener sentido
habilite la deduplicación (si está disponible en su matriz) en un disco del sistema pero no en un disco de almacenamiento de imágenes.
Por esta razón, es una buena idea analizar las capacidades exactas que ofrece la matriz que está utilizando. Algunos
pueden ofrecer QoS en discos VVol individuales, algunos pueden ofrecer servicios de datos específicos (p. ej., deduplicación,
compresión, cifrado) en discos VVol individuales, etc., todo configurado a través de SPBM.
∎ Los contenedores de almacenamiento VVol no son objetos físicos en la matriz de almacenamiento; son simplemente una cuota de asignación de
ciertos tipos de almacenamiento con ciertas capacidades habilitadas. Porque puede cambiar el límite de tamaño de un
contenedor en cualquier momento, no es necesario crear LUN que sean algo más grandes que su
necesidades anticipadas. En cambio, un administrador de almacenamiento puede crear contenedores de almacenamiento VVol del tamaño exacto
límite deseado, luego cambie ese límite sin la necesidad de migrar los VVols, reformatear el almacenamiento
contenedor, o tomar cualquier otra acción visible desde el lado del consumidor.
86 VMware, Inc.
Página 87
Por esta razón, también es mejor estructurar los contenedores de almacenamiento de forma lógica, organizativa / de gestión.
límites en lugar de basarse en la configuración de LUN. No hay necesidad de tener separados
RAID-1 / RAID-5 / RAID-6 LUN o (con una matriz de almacenamiento compatible con VVol 2.0) LUN configurados para
replicación y LUN que no se replican. En cambio, es mejor ofrecer todos estos tipos de almacenamiento en un solo
contenedor de almacenamiento para una unidad de gestión (por ejemplo, "Finanzas" o "Recursos humanos") de modo que cambiar los tipos de almacenamiento (por ejemplo,
pasar de RAID-1 a RAID-6 con replicación a medida que una VM pasa del desarrollo a la producción) son
simplemente operaciones de back-end en el arreglo y no migraciones de almacenamiento entre LUN.
VMware, Inc. 87
Página 88
Servidor de inicio de sesión único de VMware vCenter

VMware vCenter Single Sign-On Server ofrece a los usuarios acceso de inicio de sesión único en toda la gestión de vSphere.
apilar. Siga las recomendaciones de esta sección para obtener el mejor rendimiento.
∎ El rendimiento del servidor de inicio de sesión único depende del rendimiento de las fuentes de identidad de back-end. Para el
el mejor rendimiento de la fuente de identidad, siga las mejores prácticas relevantes. Por ejemplo:
∎ Para Windows Active Directory, consulte las pautas de ajuste del rendimiento de Windows Server 2008:
http://msdn.microsoft.com/en-us/windows/hardware/gg463394
∎ Para OpenLDAP, consulte OpenLDAP Faq-O-Matic: Performance Tuning:

http://www.openldap.org/faq/data/cache/190.html
∎ Al usar Active Directory como fuente de identidad, recomendamos usar AD nativo en lugar de
AD sobre LDAP. Cuando se usa AD nativo, la pila del servidor de inicio de sesión único puede procesar grupos mucho más
de manera más eficiente que cuando se usa AD sobre LDAP.
∎ Para minimizar la sobrecarga de búsqueda, asegúrese de que solo se agreguen los servidores de origen de identidad necesarios
el servidor de inicio de sesión único.
Puede explorar y administrar las fuentes de identidad adjuntas a vSphere Single Sign-On Server mediante el
Interfaz de usuario de vSphere Single Sign-On Configuration en vSphere Web Client.
∎ Cuando utilice vSphere Web Client para agregar una fuente de identidad al servidor de inicio de sesión único, establezca Base
DN para usuarios y DN base para grupos a la parte común del nombre de dominio para usuarios y grupos,
respectivamente, aumentará significativamente el rendimiento de la navegación y la búsqueda de usuarios en grandes
fuentes de identidad.
∎ Para un mayor rendimiento y disponibilidad, considere la posibilidad de implementar varios vCenter Single Sign-On
Servidores detrás de un equilibrador de carga de red.
Para obtener más información sobre cómo implementar y configurar el servidor de inicio de sesión único, consulte VMware vCenter Server
6.0 Guía de implementación . (Aunque este documento trata sobre vCenter Server 6.0, la información del servidor de inicio de sesión único
contiene también se aplica a vCenter Server 6.5.)
88 VMware, Inc.
Página 89
Biblioteca de contenido de VMware vSphere

La biblioteca de contenido de VMware vSphere proporciona una manera fácil para que los administradores de vSphere administren
plantillas de máquina, vApps, imágenes ISO y scripts. Siga las recomendaciones de esta sección para obtener la mejor
actuación.
∎ Para obtener el mejor rendimiento de transferencia de archivos de sincronización de bibliotecas y una carga reducida en los servidores vCenter, considere
configurar sus servidores vCenter en modo vinculado mejorado.
Al transferir contenido entre bibliotecas de contenido en servidores vCenter que se unen mediante Enhanced
Modo vinculado, los archivos almacenados en almacenes de datos montados en hosts ESXi se transfieren entre esos hosts ESXi
en lugar de entre los servidores vCenter. Esto acorta significativamente el camino recorrido por los datos, mejorando
rendimiento y reducción de la carga en los servidores vCenter.
∎ Para obtener el mejor rendimiento, coloque la biblioteca de contenido en un almacén de datos que admita las API de VMware vStorage
para la integración de arreglos (VAAI) (para obtener más información sobre VAAI, consulte "Consideraciones de almacenamiento de hardware"
en la página 13) .
Los almacenes de datos compatibles con VAAI permiten muchas operaciones de la biblioteca de contenido, como la creación de nuevas máquinas virtuales
de las plantillas de la biblioteca de contenido, que se llevará a cabo principalmente en el almacén de datos, mejorando drásticamente
rendimiento a la vez que libera recursos de CPU y E / S en los hosts.
∎ VCenter Server Appliance ofrece un proxy inverso que maneja las conexiones HTTPS entrantes,
descargar del servidor web vCenter el proceso de cifrado y descifrado del tráfico HTTPS.
En entornos donde no se requiere la seguridad adicional proporcionada por las conexiones HTTPS,
La velocidad de transferencia de la biblioteca de contenido se puede aumentar significativamente utilizando HTTP simple (en lugar de
HTTPS) o desactivando el proxy inverso.
N OTA Realizar cualquiera de estos cambios (usar HTTP en lugar de HTTPS o deshabilitar el proxy inverso)
la posibilidad de exponer datos o metadatos sensibles. Solo realice estos cambios si está seguro de que
conozca los riesgos.
∎ La sincronización de contenido a través de una WAN puede ser lenta debido tanto a la velocidad de la WAN como al uso de HTTP.
Si se ha suscrito a bibliotecas de contenido que sincronizan con frecuencia contenido en una WAN, considere
crear un servidor espejo para almacenar archivos en caché en el sitio remoto. Esto puede reducir significativamente el tiempo de espera del usuario.
al mismo tiempo que evita transferir los mismos archivos varias veces a través de la red lenta.
∎ La biblioteca de contenido ofrece una opción que permite la transferencia personalizada de contenido a una nueva biblioteca. Esta
La función, llamada Soporte de replicación personalizada, puede ser útil si su infraestructura de almacenamiento admite
replicación basada en hardware, si el ancho de banda de su red es insuficiente para sincronizar datos a través de HTTPS o NFS,
o si desea hacer una copia que pueda transferirse físicamente a una ubicación diferente.
∎ Debido a que la biblioteca de contenido comparte un vínculo de red con otros componentes de vCenter, y quizás con
aplicaciones, es posible que desee limitar el uso de red de la biblioteca de contenido para dejar suficiente
ancho de banda de red para esos otros componentes de aplicaciones. Esto se puede lograr usando el
Control de aceleración del rendimiento de la red global de Content Library para el ancho de banda de transferencia de archivos. Esta configuración
afecta el uso de la red de todas las operaciones de transferencia de archivos de la biblioteca de contenido, incluida la sincronización de la biblioteca, la implementación
VM, captura de VM, descarga de archivos y carga de archivos.
Para configurar esta configuración: Desde vSphere Web Client, use Administración > Configuración del sistema >
Servicios > Servicio de transferencia > Consumo máximo de ancho de banda .
∎ La biblioteca de contenido tiene dos configuraciones que limitan el número máximo de transferencias de contenido simultáneas:
∎ El número máximo de elementos de sincronización simultáneos de la biblioteca es el número máximo de subprocesos de sincronización todos suscritos
las bibliotecas pueden tener simultáneamente en una instancia de servicio de biblioteca de contenido para transferir contenido desde
Bibliotecas publicadas.
∎ El número máximo de transferencias simultáneas es el número total máximo de transferencias de archivos permitidas
en una instancia de servicio de biblioteca de contenido. Las transferencias de contenido incluyen sincronizaciones,
carga / descarga, copia de elementos de la biblioteca, implementación de plantillas OVF desde la biblioteca de contenido, etc.
VMware, Inc. 89
Página 90
Si tiene una red de alta velocidad o si el rendimiento de la red de las transferencias de archivos de la biblioteca de contenido es
más bajo de lo esperado, el aumento de estas configuraciones máximas podría aumentar el rendimiento de la red para
Transferencias de archivos de la biblioteca de contenido.
90 VMware, Inc.
Página 91
Glosario
UN Memoria activa
La memoria activa es una estimación de la cantidad de memoria de invitado a la que se ha accedido (ya sea de lectura o
escrito a) en el último minuto. Consulte también memoria consumida.
ALUA (acceso asimétrico a la unidad lógica)

Una función incluida en algunas matrices de almacenamiento que permite que la propia matriz designe rutas como "Active
Optimizado ".
Virtualización de AMD (AMD-V)

Versión de AMD de virtualización de CPU asistida por hardware, incluida en algunos procesadores AMD de 64 bits. Ver
también Virtualization Assist.
AMD-Vi
La versión de AMD de MMU de E / S asistida por hardware, incluida en algunos procesadores AMD de 64 bits, también llamada
Virtualización de E / S de AMD o IOMMU. Consulte también MMU de E / S.
segundo Globo
Una técnica utilizada en VMware ESXi para recuperar las páginas de memoria del invitado que se consideran las
valioso para el sistema operativo invitado. Esto se logra usando el controlador vmmemctl, que es
instalado como parte de la suite VMware Tools.
C Descarga de suma de comprobación

Una opción que permite a un adaptador de red calcular la suma de comprobación de TCP, reduciendo así la carga de la CPU.
Clon
Una copia de una máquina virtual. Consulte también Clon completo y Clon vinculado.
Memoria consumida
La memoria consumida, en el contexto de una máquina virtual, es la cantidad de memoria del host utilizada para respaldar la
memoria de invitado, ya sea que esa memoria esté activa o no. La memoria consumida, sin embargo, no incluye
memoria de arriba. Véase también memoria activa.
Núcleo
Una unidad de procesamiento. A menudo se utiliza para referirse a múltiples unidades de procesamiento en un paquete (un llamado "multi-core
UPC").
re E / S DirectPath
Una función que aprovecha el soporte de hardware Intel VT-d y AMD-Vi para permitir que los sistemas operativos invitados
acceder directamente a los dispositivos de hardware.
VMware, Inc. 91
Página 92
Administración de energía distribuida (DPM)

Una función que usa DRS para descargar servidores, lo que les permite ponerse en espera y, por lo tanto, ahorrar
poder. Cuando la carga aumenta, los servidores pueden volver a conectarse automáticamente.
Programador de recursos distribuidos (DRS)

Una función que monitorea la utilización en los grupos de recursos y usa vMotion para mover la ejecución virtual
máquinas a otros servidores.
mi E1000
Uno de los adaptadores de red virtual disponibles en una máquina virtual que se ejecuta en ESXi. El adaptador E1000
emula un dispositivo Intel E1000. Consulte también E1000e, Vlance y VMXNET.
E1000e
Uno de los adaptadores de red virtual disponibles en una máquina virtual que se ejecuta en ESXi. El adaptador E1000e
emula un dispositivo Intel E1000e. Consulte también E1000, Vlance y VMXNET.
VMXNET mejorado
Un tipo de adaptador de red virtual. Consulte VMXNET2.
EPT (tablas de páginas extendidas)

Implementación de Intel de hardware virtual MMU. Consulte MMU virtual de hardware.
F Tolerancia a fallas (FT)

Una función que ejecuta una copia secundaria de una máquina virtual en un host secundario y cambia sin problemas a
esa copia secundaria en caso de falla del host primario.
Canal de fibra
Una tecnología de red utilizada para almacenamiento. Consulte también iSCSI, NAS, NFS y SAN.
Clon completo
Una copia de una máquina virtual que ya no depende de la máquina virtual principal. Ver también Linked
Clon.
GRAMO Disco Growable
Un tipo de disco virtual en el que inicialmente solo se reserva la cantidad de espacio en disco del host que se necesita, y el disco
crece a medida que la máquina virtual utiliza el espacio. También se llama disco fino. Consulte también Disco preasignado.
Invitado
Una máquina virtual que se ejecuta dentro de un hipervisor. Consulte también Máquina virtual.
Sistema operativo invitado

Un sistema operativo que se ejecuta dentro de una máquina virtual. Consulte también Sistema operativo host.
H Capa de abstracción de hardware (HAL)

Una capa entre el hardware físico de una computadora y el software que se ejecuta en esa computadora
diseñado para ocultar las diferencias en el hardware subyacente, lo que permite que el software se ejecute en una variedad de
diferentes arquitecturas sin ser modificadas para cada una. Windows usa diferentes HAL según,
entre otros factores, si el sistema subyacente tiene una CPU (Uniprocesador (UP) HAL) o
varias CPU (multiprocesador simétrico (SMP) HAL). Consulte también Kernel.
MMU virtual de hardware

Una característica de algunas CPU que realiza la virtualización de la unidad de administración de memoria (MMU) en
hardware, en lugar de en la capa de virtualización. También llamado RVI o NPT por AMD y EPT por Intel.
Asistente de virtualización de hardware

Consulte Asistente de virtualización.
92 VMware, Inc.
Página 93
Glosario
Alta disponibilidad (HA)

VMware High Availability es un producto que monitorea continuamente todos los servidores físicos en un grupo de recursos.
y reinicia las máquinas virtuales afectadas por la falla del servidor.
Adaptador de bus de host (HBA)

Un dispositivo que conecta una o más unidades periféricas a una computadora y administra el almacenamiento de datos y E / S
procesamiento (a menudo para interfaces Fibre Channel, IDE o SCSI) .Un HBA puede ser físico (conectado a un host)
o virtual (parte de una máquina virtual).
Administración de energía del host

La administración de energía del host reduce el consumo de energía de los hosts ESXi mientras están en ejecución. Ver también
Gestión de energía distribuida.
Hyper-Threading
Una característica de la arquitectura del procesador que permite que un solo procesador ejecute múltiples subprocesos independientes
simultaneamente. Se agregó Hyper-Threading a los procesadores Intel Xeon y Pentium ® 4. Intel usa el
término "paquete" para referirse a todo el chip y "procesador lógico" para referirse a cada subproceso de hardware. también
llamado multiproceso simétrico (SMT).
yo Disco virtual independiente

Los discos virtuales independientes no se incluyen en las instantáneas. Los discos virtuales independientes pueden ser a su vez
Persistente o no persistente.
Intel VT-x
Versión de Intel de virtualización de CPU asistida por hardware, incluida en algunos procesadores Intel de 64 bits. Ver también
Asistente de virtualización.
Intel VT-d
La versión de Intel de MMU de E / S asistida por hardware, compatible con algunos procesadores Intel de 64 bits, también llamados Intel
Tecnología de virtualización para E / S dirigida. Consulte también MMU de E / S.
MMU de E / S
La unidad de gestión de memoria de entrada / salida es una función del procesador que reasigna transferencias DMA de E / S y
el dispositivo interrumpe. Esta función puede permitir que las máquinas virtuales tengan acceso directo a dispositivos de E / S de hardware,
como tarjetas de red. Consulte también AMD Vi e Intel VT-d.
iSCSI
Un protocolo que permite que los comandos SCSI se transmitan a través de TCP / IP (normalmente utilizando Ethernet
cableado). Un cliente iSCSI se denomina iniciador (puede ser software o hardware); un servidor iSCSI se llama
objetivo.
J Tramas gigantes
Tramas Ethernet con una carga útil de más de 1500 bytes. Debido a que hay un costo de CPU por paquete de red,
los paquetes más grandes pueden reducir el costo de CPU del tráfico de red. Las tramas gigantes son compatibles con VMXNET2
y los adaptadores de red virtual VMXNET3 (pero no con el adaptador VMXNET normal). No todo Ethernet
Sin embargo, las tarjetas o conmutadores admiten marcos gigantes.
K Núcleo
El corazón de un sistema operativo. El kernel generalmente incluye la funcionalidad de una abstracción de hardware
Capa (HAL).
L Páginas grandes
Una función ofrecida por la mayoría de los procesadores modernos que permite al TLB (búfer de búsqueda de traducción) indexar
Páginas de 2 MB o 4 MB además de las páginas estándar de 4 KB. Aunque algunos procesadores admiten 1 GB de memoria
páginas, en este libro el término "páginas grandes" se utiliza únicamente para referirse a páginas de 2 MB.
VMware, Inc. 93
Página 94
Clon vinculado
Una copia de una máquina virtual que debe tener acceso a los discos virtuales de la máquina virtual principal. los
El clon vinculado almacena solo los cambios diferenciales en los discos virtuales del padre en un conjunto de archivos separados de
los archivos del disco virtual de los padres. Consulte también Clonación completa.
LRO (descarga de recepción grande)

Un método para aumentar el rendimiento de recepción de la red incluido en algunos adaptadores de red.
LUN (número de unidad lógica)

Un número que identifica una sola unidad lógica, puede representar un solo disco o una partición en una matriz. Utilizado en
muchas tecnologías de almacenamiento, incluidos SCSI, iSCSI y Fibre Channel.
METRO Compresión de memoria

Una de las técnicas que utiliza ESXi para permitir el compromiso excesivo de la memoria.
MMU (Unidad de gestión de memoria)

Parte del hardware de una computadora que actúa como interfaz entre el núcleo de la CPU y la memoria principal.
Suele formar parte del paquete de la CPU en los procesadores modernos.
norte NAS
Consulte Almacenamiento conectado a la red.
Ejecución nativa
Ejecución de una aplicación directamente en un servidor físico, a diferencia de ejecutar la aplicación en un
máquina virtual.
Sistema nativo
Una computadora que ejecuta un solo sistema operativo y en la que las aplicaciones se ejecutan directamente en ese
sistema operativo.
NetQueue
Una tecnología que mejora significativamente el rendimiento de los adaptadores de red Ethernet de 10 Gb / s en
Ambientes.
Almacenamiento conectado a la red (NAS)

Un sistema de almacenamiento conectado a una red informática. Los sistemas NAS están basados en archivos y, a menudo, utilizan TCP / IP
a través de Ethernet (aunque existen muchas otras variaciones). Consulte también Red de área de almacenamiento.
Sistema de archivos de red (NFS)

Un protocolo de sistema de archivos de red específico compatible con muchos dispositivos de almacenamiento y sistemas operativos.
Implementado tradicionalmente en una LAN estándar (a diferencia de una red de almacenamiento dedicada).
Control de E / S de red (NetIOC)

Una función que permite la asignación de ancho de banda de red a los grupos de recursos de la red. Estas piscinas pueden ser
seleccionados de entre los siete grupos predefinidos o pueden ser definidos por el usuario.
NIC
Históricamente significaba "tarjeta de interfaz de red". Con la reciente disponibilidad de tarjetas de red multipuerto, como
así como la inclusión de puertos de red directamente en las placas del sistema, el término NIC ahora se usa a veces para
significa "controlador de interfaz de red" (de los cuales puede haber más de uno en una tarjeta de red física
o placa del sistema).
Transformación de NIC
La conversión automática en algunos sistemas operativos invitados del adaptador de red virtual Vlance a
el adaptador de red virtual VMXNET de mayor rendimiento.
94 VMware, Inc.
Página 95
Glosario
Equipo de NIC
La asociación de múltiples NIC con un solo conmutador virtual para formar un equipo. Estos equipos pueden proporcionar
conmutación por error pasiva y compartir cargas de tráfico entre miembros de redes físicas y virtuales.
Acceso a memoria no uniforme (NUMA)

Una arquitectura de computadora en la que se accede a la memoria ubicada más cerca de un procesador en particular con menos
retraso que la memoria ubicada más lejos de ese procesador.
Disco no persistente
Todas las escrituras en disco emitidas por software que se ejecuta dentro de una máquina virtual con un disco virtual no persistente
parecen estar escritos en el disco, pero de hecho se descartan después de que se apaga la sesión. Como resultado, un disco
en modo no persistente no se modifica por la actividad en la máquina virtual. Consulte también Disco persistente.
NPT (tablas de páginas anidadas)
Implementación de AMD de MMU virtual de hardware. También se llama RVI. Consulte MMU virtual de hardware.
PAGS Pacifica
El nombre original de la versión de asistencia de virtualización de AMD (más tarde llamado AMD-V), incluido en algunos
Procesadores AMD. Consulte Virtualización de AMD.
Paravirtualización
Una técnica en la que el sistema operativo invitado, o algún componente del sistema operativo invitado (como
como controlador de dispositivo) interactúa directamente con el hipervisor, para una mejor comunicación huésped-host y para
rendimiento mejorado para algunas operaciones.
PCI (interconexión de componentes periféricos)

Una especificación de bus de computadora. Ahora está siendo reemplazado en gran medida por PCIe.
PCI-X (PCI extendido)

Una especificación de bus de computadora. Similar a PCI, pero dos veces más ancho y con un reloj más rápido. Comparte algunos
compatibilidad con dispositivos PCI (es decir, las tarjetas PCI-X a veces se pueden utilizar en ranuras PCI y las tarjetas PCI
a veces se utiliza en ranuras PCI-X).
PCIe (PCI Express)

Una especificación de bus de computadora. PCIe está disponible en una variedad de capacidades diferentes (número de "carriles"): x1,
x2, x4, x8, x16 y x32. Las tarjetas más pequeñas caben en ranuras más grandes, pero no al revés. PCIe no es
ranura compatible con PCI o PCI-X.
Disco persistente
Todas las escrituras de disco emitidas por el software que se ejecuta dentro de una máquina virtual son inmediata y permanentemente
escrito en un disco virtual persistente. Como resultado, un disco en modo persistente se comporta como un disco convencional.
unidad en una computadora física. Consulte también Disco no persistente.
CPU física
Un procesador dentro de una máquina física. Consulte también CPU virtual.
Disco preasignado
Un tipo de disco virtual en el que todo el espacio del disco del host para la máquina virtual se asigna en el momento
se crea el disco virtual. Consulte también Disco de cultivo.
PVSCSI
Un adaptador de almacenamiento virtual paravirtualizado que utiliza el protocolo SCSI. PVSCSI ofrece una reducción significativa
en la utilización de la CPU, así como un rendimiento potencialmente mayor en comparación con el almacenamiento virtual predeterminado
adaptadores. Ver paravirtualización.
R RAID (matriz redundante de discos económicos)

Una tecnología que utiliza varios discos duros para mejorar el rendimiento, la capacidad o la fiabilidad.
VMware, Inc. 95
Página 96
Mapeo de dispositivos sin procesar (RDM)

El uso de un archivo de mapeo en un volumen VMFS para apuntar a un dispositivo físico sin procesar.
Escalado del lado de recepción (RSS)

Permite que el procesamiento de recepción de paquetes de red se programe en paralelo en varios procesadores.
RVI (indexación rápida de virtualización)

Implementación de AMD de MMU virtual de hardware. También se llama NPT. Consulte MMU virtual de hardware.
S SAN
Consulte Red de área de almacenamiento.
Máquina virtual segura (SVM)

Otro nombre para la versión de asistencia de virtualización de AMD, incluida en algunos procesadores AMD de 64 bits. Ver
Virtualización de AMD.
Tablas de páginas de sombra

Un conjunto de tablas de páginas mantenidas por ESXi que mapean las páginas de memoria virtual del sistema operativo invitado a
las páginas subyacentes en la máquina física.
Instantánea
Una instantánea conserva la máquina virtual tal como estaba cuando tomó esa instantánea, incluido el estado
de los datos en todos los discos de la máquina virtual y si la máquina virtual estaba encendida, encendida
apagado o suspendido.
Enchufe
Un conector que acepta un paquete de CPU. Con los paquetes de CPU de varios núcleos, este término ya no es
sinónimo de número de núcleos.
Modo SplitRx
Una función de ESXi que puede mejorar significativamente el rendimiento de la red para algunas cargas de trabajo.
Red de área de almacenamiento (SAN)

Un sistema de almacenamiento conectado a una red dedicada diseñada para almacenamiento adjunto. Los sistemas SAN son
generalmente basado en bloques, y generalmente usa el comando SCSI establecido en una red de canal de fibra (aunque otros
también existen conjuntos de comandos y tipos de red). Consulte también Almacenamiento conectado a la red.
DRS de almacenamiento
Una función que proporciona equilibrio de carga de E / S en los almacenes de datos dentro de un clúster de almacenes de datos. Esta carga
el equilibrio puede evitar los cuellos de botella en el rendimiento del almacenamiento o solucionarlos si se producen.
Control de E / S de almacenamiento
Una función que permite que los recursos de E / S de un almacén de datos completo se asignen entre las máquinas virtuales
acceder a ese almacén de datos.
Almacenamiento vMotion
Una función que permite migrar máquinas virtuales en ejecución de un almacén de datos a otro sin
falta del tiempo.
Cambiar a caché de host

Una función de ESXi que utiliza una cantidad relativamente pequeña de almacenamiento en unidades de estado sólido (SSD) para
Reducir el impacto en el rendimiento del intercambio de memoria a nivel de host.
Multiprocesador simétrico (SMP)

Una arquitectura de multiprocesador en la que dos o más procesadores (núcleos, para usar la terminología actual)
conectado a un único grupo de memoria compartida. Consulte también Uniprocesador (UP).
96 VMware, Inc.
Página 97
Glosario
Subproceso múltiple simétrico (SMT)

Otro nombre para Hyper-Threading. Consulte también Hyper-Threading.
T Modelo
Una plantilla es una copia maestra de una máquina virtual que se puede utilizar para crear y aprovisionar otras
máquinas. Las plantillas no se pueden eliminar ni agregar a un equipo. Configurar una máquina virtual como plantilla protege
cualquier clon o instantáneo vinculado que dependa de la plantilla se deshabilite inadvertidamente.
Disco grueso
Un disco virtual en el que se asigna todo el espacio en el momento de la creación.
Disco delgado
Un disco virtual en el que se asigna espacio a medida que se utiliza.
Paliza
Una situación que ocurre cuando la memoria virtual o física no es lo suficientemente grande para contener el conjunto de trabajo completo.
de una carga de trabajo. Esta discrepancia puede causar lectura y escritura frecuentes en un archivo de paginación, generalmente
ubicado en un disco duro, lo que a su vez puede afectar gravemente al rendimiento.
TLB (búfer de lookaside de traducción)

Una memoria caché de la CPU que se utiliza para almacenar entradas de la tabla de páginas.
TSO (descarga de segmentación de TCP)

Una característica de algunas NIC que descarga la paquetización de datos de la CPU a la NIC. TSO es compatible
por los adaptadores de red virtual E1000, E1000e, VMXNET2 y VMXNET3 (pero no por los
Adaptador VMXNET).
U Monoprocesador (ARRIBA)
Una arquitectura de un solo procesador (arquitectura de un solo núcleo, para usar la terminología actual). Ver también simétrico
Multiprocesador (SMP).
V Vanderpool
El nombre original de la versión de asistencia de virtualización de Intel (más tarde llamada VT), incluida en algunas versiones de Intel de 64 bits.
procesadores. Consulte también Tecnología de virtualización.
CPU virtual (vCPU)

Un procesador dentro de una máquina virtual. Consulte también Multiprocesador simétrico (SMP).
Disco virtual
Un disco virtual es un archivo o conjunto de archivos que aparece como una unidad de disco físico en un sistema operativo invitado. Estas
los archivos pueden estar en la máquina host o en un sistema de archivos remoto. Cuando configura una máquina virtual con un
disco virtual, puede instalar un nuevo sistema operativo en el archivo de disco sin necesidad de volver a particionar un
disco físico o reinicie el host.
Máquina virtual
Un entorno de PC x86 virtualizado en el que un sistema operativo invitado y el software de aplicación asociado
poder correr. Varias máquinas virtuales pueden operar en el mismo sistema host al mismo tiempo.
NUMA virtual (vNUMA)

Una función en ESXi que expone la topología NUMA al sistema operativo invitado, lo que permite que NUMA
sistemas operativos invitados y aplicaciones para hacer el uso más eficiente del hardware subyacente
Arquitectura NUMA.
SMP virtual
Varias CPU virtuales (vCPU) en una sola máquina virtual.
Conmutador virtual (vSwitch)

Un software equivalente a un conmutador de red tradicional.
VMware, Inc. 97
Página 98
Asistente de virtualización
Término general para la tecnología incluida en algunos procesadores de 64 bits de AMD e Intel que se requiere en
para que los sistemas operativos de 64 bits se ejecuten en máquinas virtuales y que puedan mejorar el rendimiento
de los sistemas operativos invitados de 32 y 64 bits. Más información está disponible en conocimientos de VMware
artículo básico 1901. Consulte también Tecnología de virtualización y virtualización de AMD.
Sobrecarga de virtualización
La diferencia de costo entre ejecutar una aplicación dentro de una máquina virtual y ejecutar la misma
aplicación de forma nativa. Dado que la ejecución en una máquina virtual requiere una capa adicional de software, existe
necesidad de un costo asociado. Este costo puede deberse a la utilización de recursos adicionales o al rendimiento reducido.
Tecnología de virtualización (VT)

La versión de asistencia de virtualización de Intel, incluida en algunos procesadores Intel de 64 bits. Ver también Virtualización
Ayudar.
Vlance
Uno de los adaptadores de red virtual disponibles en una máquina virtual que se ejecuta en ESXi. El adaptador Vlance
emula un dispositivo AMD PCnet32. Tenga en cuenta que, en algunos casos, la transformación de NIC puede convertir automáticamente un
Vlance dispositivo en un dispositivo VMXNET. Consulte también NIC Morphing, E1000, E1000e y VMXNET.
VMFS (sistema de archivos de máquina virtual)

Un sistema de archivos de clúster de alto rendimiento.
vMotion
Una función que permite migrar máquinas virtuales en ejecución de un servidor físico a otro sin
falta del tiempo.
Cliente de infraestructura de VMware (cliente VI)

Una interfaz gráfica de usuario que se utiliza para administrar hosts ESX / ESXi o servidores vCenter. Cliente vSphere renombrado
en vSphere 4.0.
Administrador de actualizaciones de VMware vSphere

Proporciona un marco de gestión de parches para VMware vSphere. Se puede utilizar para aplicar parches, actualizaciones,
y actualizaciones a hosts VMware ESX y ESXi, VMware Tools, hardware virtual, dispositivos virtuales y
pronto.
API de VMware vStorage para integración de arreglos (VAAI)

Un conjunto de API que puede mejorar la escalabilidad del almacenamiento al descargar un hardware de almacenamiento compatible con VAAI
número de operaciones en lugar de realizar esas operaciones en ESXi.
Herramientas de VMware
Un conjunto de utilidades y controladores que mejora el rendimiento y la funcionalidad de sus operaciones de invitado.
sistema. Las características clave de VMware Tools incluyen algunas o todas las siguientes, según su invitado
sistema operativo: un controlador SVGA, un controlador de mouse, el panel de control de VMware Tools y soporte para tales
funciones como carpetas compartidas, reducción de discos virtuales, sincronización de tiempo con el host, VMware Tools
scripts y la conexión y desconexión de dispositivos mientras la máquina virtual está en ejecución.
Intercambio VMX
Una función que permite a ESXI intercambiar en el disco parte de la memoria que reserva para el ejecutable de la máquina virtual
(VMX) proceso.
VMXNET
Uno de los adaptadores de red virtual disponibles en una máquina virtual que se ejecuta en ESXi. El adaptador VMXNET
es un dispositivo paravirtualizado de alto rendimiento con controladores (disponibles en VMware Tools) para muchos
sistemas operativos. Consulte también VMXNET2, VMXNET3, E1000, E1000e, Vlance y NIC Morphing.
98 VMware, Inc.
Página 99
Glosario
VMXNET2
También se llama VMXNET mejorado; uno de los adaptadores de red virtual disponibles en una máquina virtual
ejecutándose en ESXi. El adaptador VMXNET2 es un dispositivo paravirtualizado de alto rendimiento con controladores
(disponible en VMware Tools) para muchos sistemas operativos invitados. Consulte también VMXNET, VMXNET3, E1000,
E1000e, Vlance y NIC Morphing.
VMXNET3 (VMXNET Generación 3)

Lo último en la familia VMXNET de controladores de red paravirtualizados. Requiere versión de hardware virtual
7 o posterior.
vSphere Web Client.

Una interfaz de usuario basada en navegador que se utiliza para administrar hosts ESX / ESXi y servidores vCenter.
W Activación de la LAN
Una característica que permite encender o sacar de suspensión un sistema informático enviando un
comando a través de Ethernet.
VMware, Inc. 99
Página 100
100 VMware, Inc.
Página 101
Índice
Numéricos Puertos COM 19
Direcciones DMA de 64 bits 16 compresión

memoria 27
UN copia descarga 13 , 14
matrices de almacenamiento activo / activo UPC
política 35 compatibilidad 11
matrices de almacenamiento activo / pasivo sobrecarga 20
política 35 afinidad de CPU
reglas de afinidad y Hyper-Threading 22
DRS 71 Sobrecompromiso de la CPU 20
alineación Estados C 18
particiones del sistema de archivos 34
ALUA 35 re
AMD base de datos
Virtualización de E / S 12 Oracle 61
Opteron CPU 22 SQL Server 61

Dispositivo PCnet32 53 clústeres de almacenes de datos 77
AMD-V 11, 17 E / S de DirectPath 40
AMD-Vi 12 disco compartido 35
Acceso asimétrico a la unidad lógica (ALUA) 35 discos

ansioso-cero 33
segundo independiente no persistente 33
copias de seguridad independiente persistente 33
programación 47 vago-cero 34
conductor de globo instantánea 33
y VMware Tools 47 grueso 33
globo delgado 34
memoria 27 Gestión de energía distribuida Ver DPM
traducción binaria (BT) 11 Programador de recursos distribuidos Ver DRS
BIOS DPM (administración de energía distribuida) 19 , 74
ajustes 17 agresividad 74
Bloque de puesta a cero 13 y capacidad de reserva 74
chip puente 16 modo automático frente a modo manual 74
BT (traducción binaria) 11 DRS (Programador de recursos distribuidos) 19 , 70
arquitectura de bus reglas de afinidad 71
PCI 15, 16 y límites 57, 71
PCI Express 15 , 16 y reservas 57, 71
PCIe 15 , 16 y comparte 57, 71
PCI-X 15 , 16 Unidades de DVD 19
Adaptador de almacenamiento virtual BusLogic
usando controlador personalizado 52 mi
Dispositivo E1000e 53
C discos ansiosos-cero 33
Estado de parada C1E 17 emuRxMode Ver modo splitRx
Unidades de CD 19 Compatibilidad mejorada con vMotion 70
descarga de suma de comprobación 16 VMXNET 53 mejorado
VMware, Inc. 101

Página 102
EPT (tablas de páginas extendidas) 12, 17 discos virtuales persistentes independientes 33

esxtop y resxtop 20 , 37 Intel
Ethernet 82545EM NIC 53
y iSCSI 14 82574 NIC 53
y NFS 14 Dispositivo E1000 53
EVC (compatibilidad mejorada con vMotion) 70 Dispositivo E1000e 53
copia extendida 13 CPU Nehalem 22
tablas de páginas extendidas 12, 17 Tecnología de virtualización para E / S dirigida 12
VT-x 11 , 17
F CPU Westmere 22
Tolerancia a fallas Ver FT memoria intercalada 22
particiones del sistema de archivos antiafinidad entre máquinas virtuales
alineación 34 y almacenamiento DRS 77
política de ruta fija 35 afinidad intra-VM
Unidades de disquete 19 y almacenamiento DRS 77
FT (tolerancia a fallos) 24, 79 iSCSI
copia completa 13, 14 y Ethernet 14
y VLAN 36
H
iniciado por software
HA 79
procesamiento del protocolo de red 15
HA (alta disponibilidad) 75, 78
Imágenes ISO 19
HAL
UP vs SMP 21 J
hardware Máquina virtual de Java
Configuración del BIOS 17 tamaños máximos de memoria de pila 58
configuración mínima 11 marcos jumbo 16, 54
lista de compatibilidad de hardware 11 JVM
versión de hardware 11 19 tamaños máximos de memoria de pila 58
y vMotion 67
versión de hardware 7 K
y PVSCSI 52 núcleo
y VMXNET3 54 UP vs SMP 21
versión de hardware 8
y vNUMA 50 L
virtualización de hardware (HV) 11 páginas grandes 30
Clonación acelerada por hardware 13 , 14 grandes descargas de recepción 16
virtualización MMU asistida por hardware 12 discos de puesta a cero diferida 34

virtualización asistida por hardware 11 limites
Alta disponibilidad 79 y DRS 57, 71

Alta disponibilidad Ver HA procesadores lógicos Ver Hyper-Threading
DMA 16 de alta memoria Puertos LPT 19

administración de energía del host 17, 24 , 74 Adaptador de almacenamiento virtual LSILogic 52
HV (virtualización de hardware) 11
Hyper-Threading 17, 21
METRO
memoria
Numeración de CPU 22
globo 27
yo compresión 27
Tamaños de bloque de E / S 52 páginas grandes 30
Unidad de gestión de memoria de E / S 12 compromiso excesivo 28

E / S MMU 12 arriba 26
IBM X-Architecture 22 compartir página 27

bucles inactivos 21 reserva 29
discos virtuales independientes no persistentes 33 talla 27
102 VMware, Inc.
Página 103
Índice
intercambiar a la caché del host 27 PCI

intercambiando 28 , 29 arquitectura de bus 15, 16
usando reservas para evitar 30 PCI-Express
prueba 11 arquitectura de bus 15, 16
virtualización de la unidad de gestión de memoria 12 PCIe
Virtualización de MMU 12 arquitectura de bus 15, 16
política de ruta utilizada más recientemente 35 PCI-X
Política de ruta de MRU 35 arquitectura de bus 15, 16
MS-DOS Dispositivo PCnet32 53
bucles inactivos 21 grupos de puertos
MTU tamaño 54 y NetIOC 39
políticas de energía 24
norte Adaptador de almacenamiento virtual PVSCSI 52
NAS
procesamiento del protocolo de red 15 Q
CPU Nehalem 22 profundidad de la cola 14
tablas de páginas anidadas 12 controlador SCSI virtual 52
NetIOC 39
Control de E / S de red 39 R
rendimiento de la red indexación rápida de virtualización 12 , 17
y utilización de CPU 39 mapeo de dispositivos sin procesar 32

NFS RDM 32
y Ethernet 14 recibir búferes

y VLAN 36 insuficiente 55
Equipo NIC 16 recibir anillo

NIC desbordante 55
clase de servidor 16 escalado del lado de recepción 55

Núcleos NO_HZ 48 , 49 reservas
entrelazado de nodos 17, 22 y DRS 57, 71

acceso a memoria no uniforme 22 uso de 57
NPT (tablas de páginas anidadas) 12 reservas de recursos 57 , 71

NTP (Protocolo de tiempo de red) 47 política de ruta de round robin 35
NUMA (acceso a memoria no uniforme) 22 RSS 55
ancho 22 RVI (indexación rápida de virtualización) 12 , 17
O S
Opteron CPU 22 E / S escalable 55
Unidades ópticas 19 Gestión de bloqueo escalable 13
Base de datos Oracle 61 tablas de páginas de sombra 12
Modo controlado por SO Comparte
gestión de energía 17 y DRS 57, 71
gastos generales uso de 57
CPU 20 SIOC (Control de E / S de almacenamiento) 76

SMT (multiproceso simétrico) 21
PAGS discos virtuales de instantánea 33
compartir página Solaris
memoria 27 bucles inactivos 21
particiones Reserva de espacio 14
alineación 34 modo splitRx 41
política de ruta Base de datos de SQL Server 61
fijo 35 adaptador de almacenamiento
usado más recientemente 35 LSILogic 52
round robin 35 PVSCSI 52
VMware, Inc. 103
Página 104
matrices de almacenamiento y vNUMA 50

política activa / activa 35 fusión de interrupciones virtuales 45
política activa / pasiva 35 monitor de máquina virtual (VMM) 11
Programador de recursos distribuidos de almacenamiento Ver almacenamiento maquinas virtuales
DRS ancho 22
Almacenamiento DRS 77 adaptador de red virtual
Control de E / S de almacenamiento 76 E1000 53
Almacenamiento vMotion 13, 67 , 68 Vlance 53
tamaño de archivo de intercambio 29 Familia VMXNET 53
cambiar a caché de host 29 virtual NUMA (vNUMA) 22 , 50
memoria 27 programas de escaneo de virus
intercambio programación 47
memoria 28, 29 Dispositivo de red virtual Vlance 53
multihilo simétrico 21 VLAN
y iSCSI 36
T y NFS 36
Descarga de segmentación de TCP 16, 54
y almacenamiento 14 , 36
discos gruesos 33
vmkfstools 34
discos delgados 34
VMM (monitor de máquina virtual) 11
temporizador tickless 48
memoria reservada para 26
núcleos de temporizador tickless 49
vMotion 67
cronometraje 47
y adaptadores de red 70
tasas de interrupción del temporizador
Compatibilidad de CPU 70
Linux 49
Alta disponibilidad de VMware 78
Ventanas 49
Adaptador de almacenamiento VMware Paravirtual Ver PVSCSI
sincronización
VMware Storage vMotion 13, 68
dentro de máquinas virtuales 48
Herramientas de VMware 52
TLB (búfer de búsqueda de traducción) 12
y controlador BusLogic SCSI 47
traducción lookaside buffer 12
conductor de globo 47
TSO 16 , 54
sincronización de tiempo 47
Turbo Core 18
VMware vCenter 58
Modo turbo 17 , 18
VMware vSphere Update Manager 81
Cliente web VMware vSphere 62
U
SDK 66 de servicios web de VMware vSphere
Administrador de actualizaciones 58, 81
API de VMware vStorage para la integración de arreglos Consulte VAAI
Controladores USB 19
Proceso VMX
memoria reservada para 26
V
Intercambio de VMX 26
VAAI (API de VMware vStorage para integración de arreglos) 13 , VMXNET 53
32, 33 , 34, 68 , 89
vCenter 58 VMXNET Generación 3 Ver VMXNET3
base de datos 59 VMXNET2 53
nivel de estadísticas 59 VMXNET3 53
máximos admitidos 58 Adaptador de red virtual VMXNET3 44
CPU virtuales VPN
número de 20 y almacenamiento 14
vFRC (caché de lectura de vSphere Flash) 13 vSphere
versión de hardware virtual 11 19 Caché de lectura flash (vFRC) 13
y vMotion 67 Administrador de actualizaciones 58
versión de hardware virtual 7 vSphere Web Client 62
y PVSCSI 52 SDK de vSphere Web Services 62, 66
y VMXNET3 54 vSwitch 16
versión de hardware virtual 8 VT-d 12
104 VMware, Inc.
Página 105
Índice
VT-x 11 , 17
VUM (vSphere Update Manager) 81
W
CPU Westmere 22
ancho NUMA 22
amplias máquinas virtuales 22
Windows 2000
bucles inactivos 21
Windows 7
HAL 21
Windows Server 2008
HAL 21
Servicio de hora de Windows 47
Windows Vista
HAL 21
X
Arquitectura X 22
VMware, Inc. 105
Página 106
106 VMware, Inc.

Prácticas Recomendadas de Rendimiento para Vsphere 6.5

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Prácticas Recomendadas de Rendimiento para Vsphere 6.5

Cargado por

Copyright:

Formatos disponibles

Página 1

Mejores prácticas de rendimiento para

Sugiere una traducción mejor

El sitio web de VMware también proporciona las últimas actualizaciones de productos.

Si tiene comentarios sobre esta documentación, envíe sus comentarios a:

Acerca de este libro 9

1 Hardware para usar con

2 ESXi y máquinas virtuales 19

Asignación de recursos de E / S de almacenamiento 35

3 Sistemas operativos invitados 47

4 Gestión de la infraestructura virtual 57

Configuración y modos de funcionamiento de DPM 74

Tabla 1. Convenciones utilizadas en este manual 10

Sobre este libro

El Capítulo 4, “Gestión de la infraestructura virtual”, en la página 57 , proporciona orientación sobre la infraestructura.

Comentarios sobre el documento

Documentación de VMware vSphere

Puede acceder a las versiones más actuales de la documentación de vSphere en:

Tabla 1. Convenciones utilizadas en este manual

Azul (solo en línea) Enlaces, referencias cruzadas y direcciones de correo electrónico

Monoespacio Comandos, nombres de archivo, directorios y rutas

Negrita monoespaciada Entrada del usuario

Itálico Títulos de documentos, términos del glosario y énfasis ocasional

<Nombre> Nombres de variables y parámetros

Hardware para usar con

∎ Pruebe la memoria del sistema durante 72 horas, verificando errores de hardware.

Consideraciones de CPU de hardware

Consideraciones generales sobre la CPU

Virtualización de CPU asistida por hardware (VT-x y AMD-V ™ )

Virtualización MMU asistida por hardware (Intel EPT y AMD RVI)

Virtualización MMU de E / S asistida por hardware (VT-d y AMD-Vi)

∎ Asegúrese de que AES-NI esté habilitado en BIOS.

Consideraciones de almacenamiento de hardware

En SAN, VAAI ofrece las siguientes características:

En los dispositivos NAS, VAAI ofrece las siguientes características:

Consideraciones sobre redes de hardware

∎ Descarga de suma de comprobación

∎ Descarga de segmentación de TCP (TSO)

∎ Capacidad para manejar múltiples elementos Scatter Gather por trama Tx

∎ Tramas gigantes (JF)

∎ Descarga de recepción grande (LRO)

∎ Recibir escalado lateral (RSS)

dieciséis VMware, Inc.

Configuración de BIOS de hardware

Configuración general del BIOS

∎ Habilite "Turbo Boost" en el BIOS si sus procesadores lo admiten.

∎ Si el BIOS permite configurar la velocidad de limpieza de la memoria, recomendamos dejarla en el

∎ Asegúrese de que AES-NI esté habilitado en BIOS.

Configuración del BIOS de administración de energía

ESXi y máquinas virtuales 2

Consideraciones generales de ESXi

∎ Unidades ópticas (es decir, unidades de CD o DVD)

Consideraciones sobre la CPU de ESXi

Estos requisitos de recursos se traducen en un consumo real de CPU en el host.

UP vs SMP HAL / Kernels

Si el hardware y el BIOS admiten Hyper-Threading, ESXi lo utiliza automáticamente. Por lo mejor

Acceso a memoria no uniforme (NUMA)

Configuración manual de NUMA

Selección del modo Snoop

∎ Early Snoop (ES)

∎ Inicio Snoop (HS)

∎ Cluster on Die (COD)

Configuración de ESXi para virtualización asistida por hardware