Elementos que debemos cambiar

• Cambiar las tarjetas de red de las máquinas virtuales del E1000 a vmxnet3
• instalar en las Mvs las vmwaretools
• en los interfaces a 10 GB activar jumbo frames(mtu 9000) en la parte de vmotion e iscsi a todos los niveles (switch virtual, kernel port, switch físico, MV).
• Activar el DMA (Direct Memory Access) en las tarjetas de red que lo soporte ya que la tarjeta de red realiza un bypass de la cpu para acceder directamente a la memoria, mejorando el rendimiento.
• Si las tarjetas de red de los servidores soportan TSO o TCO y la MV también activarlo http://kb.vmware.com/kb/2055140 y http://kb.vmware.com/kb/2055140

Al instalar el nuevo driver vmnet3 aparecen en el panel de control de las MV nuevas opciones de mejora.(TSO,TCO,jumbo frames)

Tcp Checksum Offset permite al adaptador de red hacer el mismo las operaciones de checksum, reduciendo la carga de la CPU física del host ESX por lo que mejora el rendimiento

Tcp Segmentation Offload reduce también la carga sobre la CPU física, mejorando el rendimiento. Por defecto está habilitada en el kernel si la tarjeta lo soporta.

si queremos comprobarlos ejecutamos desde la consola del ESX

esxcfg-vmknic -l 

y aparecerá una columna indicando si soporta TSO

TSO puede se habilitado directamente en la MV, en windows dentro del panel de control→propiedades driver de red→opciones avanzadas. En linux usamos la herramienta ethtool

ethtool -K eth0 tso on 

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2055140

Mejora el rendimiento en adaptadores 10GB ya que usa múltiples colas de transmisión y recepción para poder procesar I/O entre diferentes CPUs.

Sirve para asignar una tarjeta de red del ESX directamente a una MV.

Para activar DirectPath I/O nos dirigimos al ESX→ Configuration→Advanced Settings y pinchamos sobre Configure Passthrough… y seleccionamos la tarjeta para que no sea usada por el kernel y así podersela asignar directamente a una MV

Hay que buscar cabinas que soporten VAAI ( VStorage APIs for Array Integration) ya que nos va proporcionar funcionalidades de aceleración por hardware que posibilitan realizar operaciones sobre la MV y el almacenamiento directamente en la cabina si cargar el host ESX

VAAI necesita:

• ESXi/ESX 4.1 o posterior
• Licencia Enterprise o superior
• Cabina de almacenamiento que soporte VAAI

Por defecto el ESX trae activada las opciones, pero para comprobarlo podemos ejecutar

esxcfg-advcfg -g /DataMover/HardwareAcceleratedMove

esxcfg-advcfg -g /DataMover/HardwareAcceleratedInit

esxcfg-advcfg -g /VMFS3/HardwareAcceleratedLocking

O bien mirar en el GUI los mismo parámetros en el ESX → Configuration →Advanced Settings

Para mirar rendieminto antes de hacer cambios podemos ejecutar esxtop desde la consola del ESX. Después para ver el disco presionamos la tecla U y presionando f elegimos las columnas ATSF (fallos en los bloqueos )y ATS (Bloqueos)

Para aumentar el rendimiento podemos cambiar ciertos parámetros:

• A partir de la versión 5 es mejor usar LUNs grandes que muchas pequeñas
• Protocolo de almacenamiento
• Queues y LUN queues deph

A partir de la versión 4.x se usa ATF para bloquear una zona determinada de la LUN y no como anteriormente que se bloqueaba entera cada vez que la VM actualizaba el metadata l realizar cierta operaciones como crear o borrar snapshots.

VMware PSA (Pluggable Storage Architecture) es una serie de APIs a través de las cuales los fabricantes de cabinas pueden insertar su propio código para multipathing y/o balanceo de almacenamiento. Con ello lo que se consigue es una integración mucho mejor entre VMware y el sistema de almacenamiento de un determinado fabricante.

Está formada por varios componentes :

• MPP: Por sus siglas Multipathing Plugin
• SATP: Storage Array Type Plugin
• PSP: Path Selection Plugin

Si queremos ver las reglas que tenemos en nuestro ESX ejecutamos

esxcli corestorage claimrule list

Si queremos ver los PSP que tenemos

esxcli nmp psp list

http://blog.hispavirt.com/2010/09/29/vsphere-%C2%BFque-es-vmware-psa/

esxcli storage nmp path list

Si queremos cambiar el path por defecto para que todas la nuevas conexiones sean por defecto en round robin, ejecutamos el siguiente comando:

esxcli storage nmp satp set -s VMW_SATP_DEFAULT_AA -P VMW_PSP_RR

Si queremos cambiar las que ya existen

esxcli storage nmp device set -d <DEVICE> -P <PSP_NAME>

por ejemplo

esxcli storage nmp device set --device naa.xxx.xxx.xx --psp VMW_PSP_RR

Para sacar un listado

esxcli storage nmp satp list 

escli storage core device list

Para ver el pto de montaje y el UUID

escli storage filesystem list

Reescanear todos los adaptadores

esxcli storage core adapter rescan -a

Ciertos fabricantes incluyen sus propios drivers, para instalar dichos drivers ejecutamos

esxcli  software vib install 

esxcli storage nmp psp list 

<note> el driver nativo es nmp el cual incluye satp y psp </code>

• http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1021976

Lo primero que hay que tener en cuenta es que el scheduler de la CPU es crítico para obtener un buen rendimiento.

Las características

• scheduler vcpus en cpus físicas
• ejecuta el proportionasl share algorith
• soporta smp en VMs
• usa relaxed co-scheduling para VM con SMP
• soporta arquitectura NUMA

para ver el rendimiento usamos esxtop → c

• NWLD→
• %USED→ciclos de cpu usados por VM

MVv con prioridades altas entran antes a la CPU. Para cambiar la prioridad de la MV →edit settings de la MV →resources →shares →high

esxtop →c → Campos D F

%RDY→ Porcentaje de tiempo que la VCPU espera a una CPU física este disponible. Si es >5 →mal. Si es >10% → Problema. Se soluciona normalmente añadiendo más CPU

Ciclos de CPU usados por la VM→ valores altos suele indicar problemas de rendimiento

Porcentaje de tiempo de espera para leer páginas de swap del disco. Si %SWPWT>=5 Indica problemas de memory overcommitment

Debe de ser menor igual a 0 . Si es mayor indica que hay puesta una limitación en settings. Para un mejor rendimiento habría que quitarla

Si el mayor de 3 decrementar el número de vCPUs de la MV

Para resolver problemas de saturación de CPU:

• Reducir el número de VM correindo en el host
• Incrementar recursos de CPU añadiendo host en tu cluster DRS
• Usar cntrol de recursos para las VM críticas
• Incrementar la eficiencia de los recuros de CPU en cada MV

Non Uniform Memory Architecture (NUMA). En NUMA, cada procesador tiene acceso directo a un trozo pequeño de memoria . Además, comparten el bus de memoria general para acceder a la memoria asignada a otro procesado.

En vmware si NUMA es menor del 80% → mal El contrador de NUMA se encuentra en la vista de esxtop de memoria → campos D G

En esxtop → m → campos B D J K Q

al mirar el estado de la memoria puede ser:

• high →bien →Indica que hay suficiente memoría disponible
• soft → menos de 4% de memoria libre → El host reclama memoria por balloon-driver → una maquina virtual necesita “ceder” parte de su memoria a otras maquinas virtuales
• hard → menos de 2% de memoria libre → Se empieza a usar swap → problemas de rendimiento
• low → menos del 1% de memoria libre → El ESX para VMs para tener más memoria

Valores mayores de 0 indican que el host está comprimiendo memoria

Valores mayores de 0 indican que el host está accediendo a memoria comprimida

Memoria en MB comprimida por el host ESXi

si es mayor de 0 indica que se está usando swap de disco

Indica la velocidad de lectura o escritura a la memoria en swap

Cantidad de memoria física que el ESXi está reclamando por ballon driver. Si es mayor de 0 indica memory overcommitment

• resxtop Vsphere Management Assistant
• IOMETER http://www.iometer.org/ con esta herramienta podemos medir el subsistema de I/O
• http://communities.vmware.com/docs/DOC-3961

• http://vsphere-land.com/tag/performance
• http://www.vmware.com/pdf/Perf_Best_Practices_vSphere4.0.pdf
• https://pubs.vmware.com/vsphere-51/topic/com.vmware.ICbase/PDF/vma_51_guide.pdf
• http://redes-privadas-virtuales.blogspot.com.es/2010/03/monitorizacion-de-vmware-esxi-con.html