VCAP – Sección 3 – optimización de performance para vSphere

Que tal gente, hemos llegado a la sección 3 de nuestra guÍa para el examen VDCA410, en esta sección estaremos hablando de performance y DRS. Todas las mejores prácticas, datos que debemos saber y las configuraciones ideales para poder lograr el mejor performance.

Identificar parámetros de BIOS requeridos para un óptimo funcionamiento de nuestros servidores ESX/ESXi:

Existen muchos parámetros de BIOS recomendados para VMware ESX, muchos son basados en modelos específicos de servidores. Aquí les dejo los más comunes y lo que debemos siempre verificar:

  • Siempre estar al día en cuanto a la versión de BIOS de nuestros servidores ESX/ESXi.
  • Verificar que todos los sockets con procesadores esten habilitados.
  • Habilitar Hyperthreading (Intel).
  • Habilitar “Turbo Boost” , esto en procesadores Intel.
  • En el caso de AMD deshabilitar “node intervealing” debido a que esto nos deshabilita NUMA (non uniform memory access)
  • habilitar cualquier tecnología de virtualización asistida por hardware VT-x , AMD-V , EPT ,RVI.
  • Deshabilitar cualquier tecnología para el ahorro de energía Enhanced Intel SpeedStep o Enhanced AMD PowerNow! en el caso de buscar performance, si se quiere utilizar DVFS (Dynamic Voltage and Frequency Scaling) necesitamos dejarlas habilitadas.
  • Deshabilitar dispositivos que no vayamos a utilizar, USBs, puertos seriales, etc.
  • En el caso de ciertos servidores IBM (lo experimente en una implementación utilizando 3850 M2) con cluster mode, verificar que este configurado a modo “physical” esto debido a que en modo “logical” nos muestra el doble de scokets y por lo tanto esto nos genera un mayor uso de licencias.
  • Habilitar “no execute memory protection”  (XD o NX) esto para un correcto funcionamiento de  EVC (enchanced VMotion compatibility).

Identificar versiones de drivers para  nuestros ESX/ESXi

Aquí mas que nada seria verificar que versión de driver es recomendada para el dispositivo que se esté utilizando, esto lo podemos verificar en el HCL de VMware:

Aquí les dejo un ejemplo de una tarjeta 10Gbe de Intel:

Verificar compatibilidad de dispositivos

Siempre es necesario verificar la compatibilidad de los dispositivos que estaremos utilizando, esto lo vemos en el HCL (Hardware Compatibility List) de VMware:

http://www.vmware.com/go/hcl

Tunning de memoria tanto para host ESX como VMs

Aquí les dejo algunos tips:

  • Se debe de dar una cantidad de memoria solo un poco mayor al consumo de dicho host debido a que entre mas memoria mas overhead para virtualizar dicha memoria.
  • En el caso de vms linux 32 bits  tratar de no sobre pasar el limite de 896 mb debido al como linux accede a la memoria virtual (hasta 1 GB).
  • Tratar de definir prioridades con shares para nuestras vms, debido a que en momentos de overcommitment la asignación de memoria se basara en estos shares para asignar recursos de memoria.
  • Siempre instalar VMware tools, debido a que ellas nos proporcionan la capacidad de utilizar el balloon driver dentro de la vm.
  • Las reservaciones de memoria deben de ser utilizadas con cierta planeación y para vms que sea totalmente necesario el mantener cierta cantidad de memoria ram, debido a que la memoria reservada no puede ser reclamada en momentos de over commitment.
  • En el caso de maquinas virtuales con aplicaciones java para tener un correcto funcionamiento debemos seguir los siguientes pasos:
  1. Crear una reservación de memoria del mismo tamaño a la memoria asignada
  2. La asignación de memoria debe de ser basada en el tamaño de máximo del heap size de dicha aplicación Java.
  3. En caso que el os y nuestra app soporten paginas de memoria mas grandes (large pages) habilitarlas.
  • Si se piensa tener un over commitment alto de memoria es preciso monitorear el estado de nuestro swap.
  • Es una buena práctica el tener vms con el mismo sistema operativo, con esto TPS (transparent page sharing) puede actuar mucho mejor compartiendo las páginas de memoria idénticas entre dichas vms.

Tunning de redes para nuestros hosts ESX y vms

Aquí les dejo unos tips, mas que nada son mejores prácticas:

  • siempre utilizar full duplex en nuestros links no auto negociación.
  • Dedicar interfaces para cada tipo de trafico SC/VMotion/FT/ip-storage/trafico de vms
  • En todos los casos tratar de utilizar vlans, con esto permitimos una correcta segmentación de nuestro tráfico.
  • Tratar de utilizar Link state tracking de cisco, beacon probing puede derivar en un altas cantidades de broadcasting.
  • habilitar trunkfast en switches cisco para la que los puertos cambien de estado velozmente.

Les dejo un excelente whitepaper de cisco para que lo lean:

http://www.cisco.com/en/US/docs/solutions/Enterprise/Data_Center/vmware/VMwaredg.pdf

Tunning de CPU para nuestros hosts ESX/ESXi y nuestras vms

  • nunca asignar múltiples vCPUs a menos que estemos seguros que nuestra aplicación se beneficia de multiprocesadores, vamos a ver porque:
  1. cuando tenemos vCPUs en stand by estos consumen “timer interrupts” básicamente estas interrupciones son utilizadas para medir el tiempo en las vms.
  2. muchos sistemas operativos mantienen un proceso idle consumiendo recursos innecesarios en nuestro host ESX/ESX.
  3. posible transición de las instrucciones de una aplicación no compatible con multiples cpus entre los distintos vCPUs, con esto perdemos el cache de cada uno de los cpus por lo tanto performance.
  • asegurarnos de siempre tener el HAL (Hardware Abstraction Layer) ya sea uni procesador o multi procesador ej. vm Windows con multi procesador:

Tunning de Storage para nuestros hosts ESX/ESXi y nuestras vms

les recomiendo leer mi post previo

VCAP- Sección 1 – Storage Best Practices

Aquí me gustaría agregar un punto de como modificar el queue depth de nuestras hbas. El queue depth determina la cantidad de operaciones concurrentes que dicha hba podrá estar procesando, en el caso de VMware el valor default de este queue depth es de 32,  muchas veces este valor lo modifican en el  momento de la implementación. Honestamente a mí me gusta verificar primero cual es el queue depth del almacenamiento, debido a que en el momento que nosotros aumentamos este queue depth a 64 podemos sobrepasar el valor de nuestro almacenamiento  y con esto tendríamos problemas. Muchos almacenamientos tienen un queue depth de 2048 con esto podemos ver que con 32 hosts podemos fácilmente llegar a ese limite.

¿Cómo puedo saber si estoy teniendo problemas con mi actual queue depth?

Ejecutamos esxtop en alguno de nuestros hosts ESX/ESXi que tengan visibilidad con de la lun que este presentando problemas, una vez dentro de esxtop, tecleamos la letra “u”, con esto se cambiara la vista a disk device que básicamente son las luns y discos locales que tenemos en dicho host. Observamos el valor de QUED, si este valor es distinto a0 estamos teniendo operaciones encoladas por lo que debemos verificar el queue depth de nuestra hba:

¿Cómo modifico el queue depth de mi hba?

Paso 1-. Verificamos el modulo que está en uso

Para Qlogic:

vmkload_mod -l |grep qla

Para Emulex:

vmkload_mod -l |grep lpfc

Paso 2-. Realizamos la modificación basada en el modulo detectado, en este ejemplo estaremos viendo el modulo qla2xxx de Qlogic  y lpfc820 de Emulex:

Qlogic:

esxcfg-module -s ql2xmaxqdepth=64 qla2xxx  #esto modificara el queue depth a su valor máximo que es de 64.

Emulex:

esxcfg-module -s  lpfc0_lun_queue_depth=64 lpfc820 #esto modificara el queue depth a su valor máximo que es de 64.

Paso 3-. Reiniciamos nuestro host y verificamos el cambio:

esxcfg-module -g <driver>

Paso 4-. Modificamos el valor de “Disk.SchedNumReqOutstanding” al valor que le dimos a nuestra HBA, este valor es la cantidad de operaciones que será capaz de mandar el vmkernel (el total de operaciones para todos las vms que residan en dicho host), por lo tanto si tenemos un valor menor al que le dimos a nuestra HBA existiría un cuello de botella

desde el vsphere client vamos a configuration>advanced settings>disk>Disk.SchedNumReqOutstanding y le damos el valor requerido:

Esto también lo podemos realizar desde la línea de comando:

esxcfg-advcfg -s 64 /Disk/SchedNumReqOutstanding

Paso 5 (opcional pero recomendado)-. En la guía de config de ESX/ESXi se nos recomienda modificar el valor de Disk.UseDeviceReset y verificar que el valor de Disk.UseLunReset sea de 1, esto realizara los resets (se liberan todas las reservaciones scsi) a nivel de la lun no del almacenamiento para no afectar el almacenamiento completo:

Desde el vsphere client vamos a configuration>advanced settings>disk>Disk.UseDeviceReset y modificamos el valor a 0

Esto también lo podemos realizar desde la línea de comando:

esxcfg-advcfg -s 0 /Disk/UseDeviceReset

Configurar y aplicar atributos avanzados para nuestros host ESX/ESXi

Tenemos dos maneras para realizar modificaciones a parámetros avanzados en nuestros hosts desde la línea de comando utilizando esxcfg-advcfg (vicfg-advcfg  en el caso de vcli) o  desde el vsphere client vamos a configuration>advanced settings.

Aquí debemos de conocer bien lo que estamos haciendo porque podemos dañar nuestro sistema.

Configurar y aplicar atributos avanzados para nuestras VMs

Existen bastantes atributos avanzados que podemos modificar en nuestras vms, para realizarlo tenemos 2 opciones, editamos el archivo vmx directamente o ingresamos con el vsphere client , seleccionamos la vm>click derecho>edit settings>options>general>Configuration Parameters:

Al igual que la modificación de parámetros avanzados para nuestros hosts les recomiendo saber que es lo que están haciendo antes de realizarlo o probarlo en una vm de testing. Aquí les dejo una página excelente donde se documentan muchos de los parámetros que podemos modificar en el vmx:

http://www.sanbarrow.com/vmx.html


Tuning y modificación de NUMA

NUMA (non uniform memory access) un tipo de arquitectura en cuanto a la comunicación entre procesadores y memoria se refiere, a diferencia de arquitecturas anteriores cada procesador o grupo de procesadores  tienes  su propia memoria ram, a este grupo de memoria y procesadores se le llama “nodo numa”:


Cada nodo numa tiene un bus a través de cual se lleva a cabo la comunicación entre cpu y memoria a esto se le llama memoria local, pero también se puede acceder memoria de otros nodos que se le conoce como “foreign” o memoria remota claro que bajo un costo en cuanto al performance.

El algoritmo de numa en VMware se encarga de balancear las vms entre los nodos dependiendo de la carga que tiene el sistema, el nodo al que se asigna se le llama “home node” y este mismo algoritmo trata de asignar memoria en su mismo nodo numa para que esta memoria sea local.

Recomendaciones:

  • No asignar un número mayor de vCPUs de los que tiene el host ESX/ESXi a una vm, debido a que estas maquinas no pueden ser manejadas por el algoritmo de numa para migrarlas entre los nodos según las cargas.
  • No utilizar cpu affinity debido que afecta el correcto balanceo de numa.

Optimizaciones manuales:

  • Asociar una vm a un nodo numa utilizando cpu affinity
  1. ingresamos con el vsphere client y seleccionamos una vm, hacemos click derecho y click sobre “edit settings”.
  2. vamos a resources>Advanced Cpu e ingresamos el procesador o los procesadores donde queremos que se ejecute esta vm.
  • Asociar que memoria será asignada según el nodo numa (requiere haber definido afinidades en cpu)
  1. ingresamos con el vsphere client y seleccionamos una vm, hacemos click derecho y click sobre “edit settings”
  2. vamos a resources>memory y definimos la afinidad de memoria.

Opciones avanzadas de Numa:

  • VMkernel.Boot.sharePerNode —> este valor avanzado define si se podrá realizar de duplicación de paginas idénticas (Transparent page sharing) entre distintos nodos NUMA, por default viene deshabilitada. Generalmente esta opción no la modificamos debido a que overhead (aunque sea muy pequeño) que se presenta entre compartir memoria entre nodos numa.

existe una gran variedad de opciones avanzadas de numa (23) pero lo más recomendable es no modificar estas a menos que sea requerido por soporte VMware.

2 comments on “VCAP – Sección 3 – optimización de performance para vSphere

Leave a Reply