VCAP – Sección 3 – Realizar medición y calculo de recursos en un ambiente vSphere

Que tal gente, llego la hora de continuar con los temas de estudio para el examen VCAP-DCA410. En esta ocasión vamos a platicar un poco de como realizar un “capacity planning” o poder planificar los recursos que se requieren actualmente en nuestra infraestructura como también los recursos que se podrán requerir en un futuro.

Entender el Algoritmo de DRS basado el “slots” y el impacto de los mismos en las recomendaciones de migración

Este punto lo veo un poco confuso, debido a que el algoritmo de DRS en si solo no se basa en “slots”, no es hasta la versión 4.1 de vSphere que DRS se integra de una manera muy cercana a HA permitiendo así, en el caso de tener un evento de failover, que HA le solicite a DRS el balanceo de un los recursos en caso que estén esparcidos entre los hosts que  conforman dicho cluster para así poder cumplir con las reservaciones y requerimientos de las VMs que se tienen que encender.

Un buen lugar para entender el funcionamiento de DRS es el siempre confiable sitio de Duncan Epping:

http://www.yellow-bricks.com/drs-deepdive/

Identificar herramientas para el monitoreo de los recursos

Básicamente en este punto podemos enlistar y describir una cantidad enorme de aplicaciones utilizadas para el monitoreo de peformance que existen para ambientes físicos y virtuales, para mi gusto los más utilizados son:

  • Perfmon esta herramienta viene incluida en nuestros sistemas Windows, nos permite el monitoreo de recursos en vivo y también la capacidad de crear contadores con los cuales nosotros podemos definir tiempos a monitorear ciertos aspectos como puede ser red,cpu,memoria,etc. tenemos una gran variedad de contadores:

  • esxtop esta herramienta incluida tanto en ESX como ESXi nos permite monitorear distintos aspectos de nuestro host, podemos monitorear RAM, CPU, red, almacenamiento,etc. Es una herramienta que ejecutamos en la linea de comando directamente en los hosts o también podemos ejecutarla de forma remota (resxtop). El mejor lugar para aprender mas sobre las métricas que tenemos y el uso de esxtop es un documento de la comunidad de VMware mantenido por mismo personal de VMware:  http://communities.vmware.com/docs/DOC-11812 .

vista CPU

  • Gráficas de performance vCenter tenemos la capacidad de monitorear bastantes métricas directamente desde nuestro vCenter, podemos incluso crear nuestras propias gráficas relacionando los parámetros que nos interesen más:

  • Capacity Planner es una herramienta de VMware que nos ofrece la capacidad de analizar el comportamiento de nuestra infraestructura, planeación y nos provee con reportes y recomendaciones de posibles escenarios de consolidación, Esta constituido por los siguientes elementos:

  1. Data manager: esta aplicación se instala dentro de la infraestructura a monitorear, desde ella se configura el servicio de colección “Data Collector Service”, este servicio se encarga de descubrir equipos en la red local y guarda información de OS, hardware, aplicaciones en uso, métricas de consumo, etc. en una base de datos local para luego ser enviada a en ciertos periodos al “Data Analyzer”.
  2. Data analyzer: este componente se encarga de analizar la información enviada por el servicio de Data collector comparándola con información contenida en una base de datos llamada “information wharehouse” donde se almacena toda la información de todos los “collectors” ,  identificando tendencias y comportamientos.
  3. Information wharehouse: esta base de datos contiene información de todas los colectores de distintos capacity planners, con esta información logramos una comparación confiable y es posible así definir las recomendaciones que se nos darán. Ejemplo de un reporte:

Identificar métricas de performace que nos indiquen saturación de recursos

Aquí estaré en listando algunas de las métricas más comunes que podemos observar en esxtop para determinar que tenemos problemas:

  • memoria: ejecutamos esxtop, ingresamos la tecla “m” después ingresamos la tecla “f” y nos aseguramos que los siguientes medidores están activados “j,k,p” por ultimo activamos la vista de VMs ingresando la tecla “V” (mayúscula):

SWR/s – en caso de tener este medidor distinto a “0”  nuestro host esta leyendo de swap (.vswp).

SWW/s – en caso de tener este medidor distinto a “0” nuestro host esta escribiendo a swap (.vswp).

MCTLSZ – en el caso que el valor de este medidor sea distinto a “0” nuestro host esta reclamando memoria de las VMs utilizando el balloon driver.

ZIP/s – en el caso que el valor de este medidor sea distinto a “0” nuestro host esta comprimiendo memoria.

  • CPU: ejecutamos esxtop y activamos la vista de VMs ingresando la tecla “V” (mayúscula) ya que la primera vista de esxtop es de CPU:

%RDY – porcentaje del tiempo de ejecución de un world (proceso de vm) en el cual se encuentra listo para ser enviado a un procesador físico para su ejecución pero este ultimo no esta disponible, por lo cual esta en una fila o “queue” de procesador, si el valor de %RDY es mayor  a “10” tenemos problemas, generalmente debido a la cantidad de vCPUs que hemos entregado en el host.

%MLMTD – porcentaje del tiempo de ejecución de una vm en el cual no ha sido procesada debido a los limites de cpu configurados para la misma. En el caso que este sea distinto a “0” debemos modificar el limite de dicha vm si es que tenemos problemas con ella.

%SWPWT – este indicador solo lo veremos activo cuando nuestro host este realizando swap de memoria , por este indicador nos muestra la cantidad de tiempo que la vm esta esperando al vmkernel para leer paginas del swap.

%CSTP – porcentaje del tiempo de ejecución de un world en cual el vmkernel lo pone en modo “co-deschedule”, para ser mas claros , en el caso que una vm tenga smp (symmetric multiprocessing) y el OS o la aplicación ejecutada dentro de dicho os no es capaz de llevar un manejo inteligente de los distintos cpus generando así mas carga en un vCPU que otro, generando así un des balance. Este valor nos ayuda para determinar que una aplicación u OS en especifico no manejan de manera correcta multiples cpus, también nos puede indicar afinidad de un vcpu.

%SYS – porcentaje de tiempo en el cual servicios o worlds del sistema se ha dedicado a dicha vm, generalmente en el caso de tener un valor mayor a “20” nos indica que dicha vm tiene una alta cantidad de i/o.

  • Disco ejecutamos esxtop, ingresamos la tecla “u” después ingresamos la tecla “f” y nos aseguramos que los siguientes medidores están activados “f,g,h,i,L” :

DAVG – (device avg) – latencia a nivel del adaptador (hba), latencia entre la hba y el almacenamiento. Si este valor es alto (davg ≥ 25) debemos verificar nuestro almacenamiento (cantidad de discos, problemas) e infraestructura para llegar a el (switches , hba’s ,etc).

KAVG – (kernel avg) – latencia a nivel del vmkernel, generalmente este valor debe de ser menor al valor de DAVG o “0”, en el caso que sea mayor es posible que tengamos encoladas peticiones a disco (QUED).

GAVG (guest avg) – la suma de KAVG y DAVG nos da como resultado la latencia percibida por el guest o vm (GAVG),valores mayores a 25 nos indican problemas.

QUED – cantidad de comandos encolados a nivel del vmkernel, esto quiere decir que dichos comandos están esperando una oportunidad de entrar en el queue del almacenamiento. En el caso que se tenga un valor distinto a “0” nos indica problemas con nuestro almacenamiento (queue depth).

ABRTS/s – cantidad de comandos abortados, esto sucede en el momento que después de cierta cantidad de tiempo (dependiendo el os), el almacenamiento  no ha sido capaz de responder a las peticiones de dicha vm, por lo cual el sistema operativo realiza dicho abort.

RESETS/s – reseteo del bus de scsi.

CONS/s – reservaciones scsi por segundo, en el caso de tener una cantidad alta de reservaciones (20+) se nos indica problemas con nuestro almacenamiento, las reservaciones scsi solo aplican para datastores VMFS. Estas ocurren en el momento ciertas operaciones requiere hacer un lock del metadata, por ej: encendido de vm, nueva vm, snapshot, vmotion de una vm, etc. Por estas se presentan comúnmente en el caso de tener una cantidad alta de VMs por cada datastore.

  • Red: ejecutamos esxtop, ingresamos la tecla “n”:

 

%DRPTX – “dropped transmit packets” porcentaje de paquetes transmitidos que se han caido, esto representa problemas con la red fisica, alto consumo de la misma, problemas de hardware , etc. si el valor es distinto a “0” , es algo que tenemos que verificar.

%DRPRX – “dropped received packets” porcentaje de paquetes recibidos que se han caido, aquí puede ser por cuestiones de recursos en el lado de la VM (no hay suficiente capacidad de procesamiento , aumentar recursos) o porque se esta teniendo un buffer overflow a nivel de rx rings. Aquí podemos incrementar el tamaño de dichos rings desde las propiedades de la nic (en el caso de vmxnet3 e intel e1000 con el driver de intel instalado):

 

Predecir en el momento que nuestros hosts requieran mas recursos de red y/o storage observando un ambiente existente

Básicamente aquí sera cuestión de hacer uso de las herramientas antes comentadas, como las gráficas de vCenter donde podemos ver los consumos y performance tanto de red como del almacenamiento.

Determinar cuando incrementar o disminuir los recursos dados a una VM basandonos en los consumos de la misma

Nuevamente, basándonos en las herramientas como son perfmon, gráficas de vCenter y esxtop, podemos rápidamente definir problemas de recursos. En el caso de perfmon en windows siempre utilicemos los counters que instalan las vmware tools debido a que ellos nos muestran los consumos verdaderos. Como ejemplo, podemos basarnos en esxtop para saber que una vm esta teniendo problemas en cuanto al cpu simplemente observando los valores de %RDY con lo cual podremos saber que se han dado una cantidad muy grande de vCPUs en el host lo cual representa un problema.

Interpretar métricas de performance en el vCenter

Aquí mas que nada es entender la información que se nos muestra, aquí les dejo un link a un whitepaper de VMware para entender mejor las gráficas que nos presenta el vcenter:

vSphere performance charts

Leave a Reply