meta data de esta página
Diferencias
Muestra las diferencias entre dos versiones de la página.
| Ambos lados, revisión anteriorRevisión previaPróxima revisión | Revisión previa | ||
| virtualizacion:vmware:version5:optimizacion [182014/06/ 11:16] – [Optimización de la CPU] lc | virtualizacion:vmware:version5:optimizacion [182023/01/ 13:46] (actual) – editor externo 127.0.0.1 | ||
|---|---|---|---|
| Línea 1: | Línea 1: | ||
| + | {{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:// | ||
| + | Al instalar el nuevo driver vmnet3 aparecen en el panel de control de las MV nuevas opciones de mejora.(TSO, | ||
| + | < | ||
| + | === 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 < | ||
| + | < | ||
| + | |||
| + | TSO puede se habilitado directamente en la MV, en windows dentro del panel de control-> | ||
| + | En linux usamos la herramienta ethtool < | ||
| + | |||
| + | < | ||
| + | |||
| + | |||
| + | http:// | ||
| + | |||
| + | == 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. | ||
| + | < | ||
| + | |||
| + | Para activar DirectPath I/O nos dirigimos al ESX-> Configuration-> | ||
| + | |||
| + | {{ : | ||
| + | |||
| + | ==== 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 | ||
| + | < | ||
| + | < | ||
| + | < | ||
| + | |||
| + | O bien mirar en el GUI los mismo parámetros en el ESX -> Configuration -> | ||
| + | |||
| + | 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 | ||
| + | {{ : | ||
| + | |||
| + | 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 | ||
| + | < | ||
| + | |||
| + | Si queremos ver los PSP que tenemos | ||
| + | < | ||
| + | http:// | ||
| + | < | ||
| + | Si queremos cambiar el path por defecto para que todas la nuevas conexiones sean por defecto en round robin, ejecutamos el siguiente comando: | ||
| + | < | ||
| + | |||
| + | Si queremos cambiar las que ya existen < | ||
| + | < | ||
| + | |||
| + | Para sacar un listado < | ||
| + | < | ||
| + | |||
| + | Para ver el pto de montaje y el UUID | ||
| + | < | ||
| + | |||
| + | Reescanear todos los adaptadores | ||
| + | < | ||
| + | === Instalar drivers de terceros === | ||
| + | Ciertos fabricantes incluyen sus propios drivers, para instalar dichos drivers ejecutamos < | ||
| + | < | ||
| + | < | ||
| + | |||
| + | == Referencias == | ||
| + | * http:// | ||
| + | |||
| + | ==== 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-> | ||
| + | |||
| + | MVv con prioridades altas entran antes a la CPU. Para cambiar la prioridad de la MV ->edit settings de la MV -> | ||
| + | |||
| + | {{ : | ||
| + | === 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> | ||
| + | == %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: | ||
| + | * IOMETER http:// | ||
| + | * http:// | ||
| + | |||
| + | |||
| + | ===== Referencias ===== | ||
| + | * http:// | ||
| + | * http:// | ||
| + | * https:// | ||
| + | * http:// | ||