{{tag> vmware optimización rendimiento}}
===== Optimizaciónes para VMWARE =====
==== Optimización de la red ====
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)
<note>en las MV con linux hay que cambiar las opciones a mano</note>
=== TCO ===
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

=== TSO ===
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 <code>esxcfg-vmknic -l </code> y aparecerá una columna indicando si soporta TSO
<note>desde el VMA no aparece la columna TSO</note>

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 <code>ethtool -K eth0 tso on </code>

<note>si no aparece cambiar el driver de la MV por el driver por el vmxnet3</note>


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

== NetQueue ==
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.

== DirectPath I/O ==
Sirve para asignar una tarjeta de red del ESX directamente a una MV.
<note>también podemos mapear directamente la mochila de protección de un programa, mediante Direcpath I/O</note> 

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

{{ :virtualizacion:vmware:version5:direcpathio.png?nolink&800 |}}

==== Optimizar el Almacenamiento ====
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 
<code>esxcfg-advcfg -g /DataMover/HardwareAcceleratedMove</code>
<code>esxcfg-advcfg -g /DataMover/HardwareAcceleratedInit</code>
<code>esxcfg-advcfg -g /VMFS3/HardwareAcceleratedLocking</code>

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.

== PSA ==
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.
{{ :virtualizacion:vmware:version5:psa.png?nolink&300 |}}

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
<code>esxcli corestorage claimrule list</code>

Si queremos ver los PSP que tenemos 
<code>esxcli nmp psp list</code>
http://blog.hispavirt.com/2010/09/29/vsphere-%C2%BFque-es-vmware-psa/
<code>esxcli storage nmp path list</code>
Si queremos cambiar el path por defecto para que todas la nuevas conexiones sean por defecto en round robin, ejecutamos el siguiente comando:
<code>esxcli storage nmp satp set -s VMW_SATP_DEFAULT_AA -P VMW_PSP_RR</code>

Si queremos cambiar las que ya existen <code>esxcli storage nmp device set -d <DEVICE> -P <PSP_NAME></code> por ejemplo
<code>esxcli storage nmp device set --device naa.xxx.xxx.xx --psp VMW_PSP_RR</code>

Para sacar un listado <code>esxcli storage nmp satp list </code>
<code>escli storage core device list</code>

Para ver el pto de montaje y el UUID
<code>escli storage filesystem list</code>

Reescanear todos los adaptadores
<code>esxcli storage core adapter rescan -a</code>
=== Instalar drivers de terceros ===
Ciertos fabricantes incluyen sus propios drivers, para instalar dichos drivers ejecutamos <code>esxcli  software vib install </code>
<code>esxcli storage nmp psp list </code>
<note> el driver nativo es nmp el cual incluye satp y psp </code>

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

==== Optimización de la CPU ====
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

{{ :virtualizacion:vmware:version5:share.png?nolink&500 |}}
=== Contadores a mirar ===
== Ready Time ==
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
== %USED ==
Ciclos de CPU usados por la VM-> valores altos suele indicar problemas de rendimiento
== %SWPWT ==
Porcentaje de tiempo de espera para leer páginas de swap del disco. Si %SWPWT>=5 Indica problemas de memory overcommitment
== %MLMTD ==
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
== %CSTP ==
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
==== NUMA ====
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


==== Optimizar Memoria ====
En esxtop -> m -> campos B D J K Q 

== Memory Status ==
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
== zip/s ==
Valores mayores de 0 indican que el host está comprimiendo memoria
== unzip/s ==
Valores mayores de 0 indican que el host está accediendo a memoria comprimida
== cacheUSD ==
Memoria en MB comprimida por el host ESXi
== swcur ==
si es mayor de 0 indica que se está usando swap de disco 
== swr/s sww/s ==
Indica la velocidad de lectura o escritura a la memoria en swap
== mctlsz ==
Cantidad de memoria física que el ESXi está reclamando por ballon driver. Si es mayor de 0 indica memory overcommitment
===== Herramientas =====
  * resxtop [[virtualizacion:vmware:version5:vma|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


===== Referencias =====
  * 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