Upgrade a vCenter Server 5.0

Una serie de articulos detallando el proceso de Upgrade a vCenter Server 5.0

Upgrade a ESXi 5.0

Una serie de articulos detallando el proceso de Upgrade a ESXi 5.0

Instalación de ESXi 5.0

Una serie de articulos detallando el proceso de Instalación de ESXi 5.0

Configuración iSCSI en vSphere 5.0

Una serie de articulos dedicados a la configuración de iSCSI en vSphere 5.0

Reconocido como vExpert 2011

Reconocido como vExpert 2011

VMware View 4.5

Una serie de articulos dedicados a View 4.5 y todas sus nuevas funcionalidades.

VMware View Transfer Server 4.5

Una serie de articulos dedicados a View Transfer Server y sus caracteristicas.

VMware View Composer 2.5

Una serie de articulos dedicados a View Composer y sus caracteristicas.

Cluster MSCS Across Boxes en vSphere 4.1

Serie de articulos detallando el proceso de creación y configuración de un cluster MSCS en configuración Across Boxes en vSphere 4.1

Mostrando entradas con la etiqueta Performance. Mostrar todas las entradas
Mostrando entradas con la etiqueta Performance. Mostrar todas las entradas

lunes, 30 de enero de 2012

Como funciona vMotion y las mejoras incluidas en vSphere 5


Hola a todos, en el siguiente post hablaremos un poco sobre vMotion y su funcionamiento.  Además hablaremos de las novedades de vMotion incluidas en vSphere 5, las cuales no han sido muy promocionadas al lado de otros anuncios, pero que claramente mejoran el funcionamiento de esta funcionalidad esencial en un entorno VMware.

vMotion es una tecnologia que permite la migración "en caliente" de una MV desde un host a otro, sin un impacto apreciable por el usuario final.  Además, vMotion es la pieza clave de otras funcionalidades como DRS y DPM.

Como funciona?
Al usar vMotion para mover una MV de un host a otro se transfiere el estado de ejecución completo de la MV desde el host de origen al host de destino, utilizando una conexión de red de alta velocidad.  El estado de ejecución consiste de 3 componentes principales:

Estado de dispositivos virtuales: Incluyendo el estado de la CPU, red, adaptadores de disco, etc.  vSphere puede serializar el estado de los dispositivos virtuales, lo cual generalmente tiene un tamaño menor a 8MB.  En algunos casos puede crecer por sobre los 128MB, lo cual de igual modo puede ser transferido muy rapidamente en una red de alta velocidad.

Conexiones de dispositivos de red y SCSI: La arquitectura de red virtual de vSphere centrada en los vSwitch y en las NIC virtuales (vNIC), permite que sea facil preservar las conexiones de red existentes, incluso despues que una MV es migrada a otro host.  Hay que recordar que cada vNIC tiene su propia MAC Address que es independiente de la MAC Address de las NIC fisicas, por lo que al mover una MV de un host a otro, la conexión a red permanecerá activa, mientras el host de origen y el host de destino se encuentren en la misma subred.  Una vez que la migración se completa, el host de destino envia un paquete RARP al Switch fisico para asi asegurar que el Switch actualice sus tablas con el nuevo puerto de Switch utilizado por la MV migrada.
Por otro lado, el uso de almacenamiento compartido como SAN o NAS hace que sea muy facil transferir el estado de los discos

La memoria fisica de la máquina virtual: Este es por lejos el componente de mayor tamaño que necesita ser transferido durante una migración con vMotion.  Hay que recordar que una MV puede llegar a tener hasta 1TB de memoria asignada, por lo que la eficiencia en la transferencia de la memoria es un punto critico en vMotion.
Para permitir que la MV continue ejecutandose durante la transferencia de la memoria, y que este proceso sea transparente para el usuario, el proceso deberá llevarse a cabo en multiples fases:

  • Fase 1: Seguimiento de la MV.  Durante esta etapa, se realiza un seguimiento de las paginas de memoria de la MV, para asi poder registrar cualquier modificacion realizada en la MV durante la migración.  Este seguimiento puede causar una baja considerable en el rendimiento de la MV.  Este impacto es proporcional al tamaño de la memoria de la MV.
  • Fase 2: Pre-copia. Debido a que la MV continua en ejecución y modificando el estado de la memoria en el host de origen durante esta fase, el contenido de la memoria de la MV es copiado desde el host de origen al host de destino en un proceso iterativo.
    Con la primera iteracion se copia todo el contenido de la memoria.  En las siguientes iteraciones, se copian solo las paginas que fueron modificadas durante dicho periodo.  El numero de iteraciones y de paginas de memoria copiadas durante cada iteracion, depende de que tan activamente es utilizada la memoria debido a las operaciones realizadas dentro de la MV.
    Durante esta fase, el impacto mayor es en el uso de la red de vMotion, sin un uso significativo de ciclos de CPU en la MV.  El impacto en la performance de la MV es menor reduciendo la velocidad de escritura de paginas de memoria.
  • Fase 3: Switchover. Esta es la fase final del proceso de vMotion, donde la maquina virtual es pausada momentaneamente en el host de origen, para asi poder copiar los ultimos cambios en la memoria al host de destino, y que finalmente la maquina virtual retome sus operaciones en el host de destino.  Aunque la duración de esta fase es normalmente de menos de un segundo, es la fase en que más probablemente se percibirá un impacto en la performance de la MV, con un aumento de la latencia abrupto y momentaneo.  El alcance del impacto depende de varios factores, como la infraestructura de red, el almacenamiento, el hardware utilizado en los hosts, version de vSphere, etc.


Mejoras en vSphere 5
vSphere 5 trae importantes mejoras en vMotion, lo cual mejora considerablemente la performance.

Uso de multiples NICs para vMotion
En vSphere permit utilizar multiples adaptadores de red para vMotion, reduciendo dramaticamente los tiempos de migración.


Con esta funcionalidad, el VMkernel balanceará en forma transparente el trafico de vMotion entre todas las vmknics configuradas para vMotion, de manera de saturar todas las conexiones.  Incluso durante una unica operación de vMotion, el VMkernel utiliza todos los adaptadores de red disponibles para distribuir el trafico de vMotion.

En algunas mediciones se han encontrado mejoras de más de un 30% en la performance de las operaciones de vMotion.

Metro vMotion
En vSphere 5 se introduce una nueva caracteristica de Metro vMotion que es Latency-Aware, que provee de mejor performance en redes de alta latencia, y además aumenta el limite de latencia en redes de vMotion de 5 milisegundos a 10 milisegundos.

Stun During Page Send (SDPS)
vSphere incluye nuevas mejoras para asegurar que vMotion no fallará debido a problemas en la copia de la memoria.  Recordemos que el proceso de transferencia del contenido de la memoria durante una operacion de vMotion incluye un proceso iterativo.  En la mayoria de los casos, una iteracion debiera tomar menos tiempo que la iteracion anterior, no obstante, en algunos casos donde la MV modifica la memoria más rapido de lo que puede ser transferida (por ejemplo por limitaciones en la red de vMotion), resultaba en una operacion fallida de vMotion en vSphere 4.1 y versiones anteriores, debido a que el proceso iterativo no generaba ningun progreso en la transferencia.

Ante la presencia de estos casos, las mejoras introducidas en vSphere 5 reducen la velocidad de la máquina virtual, asegurandose que la tasa de modificación de la memoria sea menor que la tasa de transferencia, evitando asi fallas de vMotion.

Otras mejoras en la performance de vMotion
vSphere 5 incluye otras mejoras en la performance de las operaciones de vMotion:

  • Mejoras significativas para minimizar el impacto de la tarea de seguimiento de los cambios en la memoria.
  • Numerosas mejoras para reducir el tiempo necesario para que la MV retome un nivel normal de performance despues de una operacion de vMotion.
  • Optimizaciones que permiten que vMotion sature en forma efectiva un ancho de banda de 10GbE durante una migración con vMotion.

Espero les haya resultado interesante.  Si tienen cualquier pregunta, no duden en dejar sus comentarios!

miércoles, 14 de diciembre de 2011

vSphere 5: Host Power Management (HPM)

Hola a todos,

Una de las nuevas features incluidas en vSphere 5, y de la que poco se ha hablado, es vSphere Host Power Management o simplemente HPM.

HPM es una tecnica que permite ahorrar energia poniendo ciertas partes de un servidor o dispositivo en un estado de energia reducido, cuando el servidor o dispositivo se encuentra inactivo o no necesita funcionar a plena capacidad.

HPM no debe confundirse con DPM (Distributed Power Management), el cual distribuye MVs entre hosts fisicos en un cluster, intentando liberar uno o más hosts para apagarlos completamente.  HPM ahorra energia manteniendo los hosts encendidos en todo momento.  Ambas features pueden ser utilizadas simultaneamente permitiendo un ahorro de energía mayor.


HPM administra la energia utilizando los estados de performance y energia de Advanced Configuration and Power Interface (ACPI).  Con el lanzamiento de vSphere 5, la politica de administración de energia por defecto está basada en DVFS (Dynamic Voltage and Frequency Scaling).  Esta tecnologia utiliza los estados de performance del procesador y permite que parte de la energia sea ahorrada utilizando el procesador a una menor frecuencia y voltaje, mientras aun se deja suficiente tiempo de CPU disponible para mantener niveles de performace aceptables en la mayoria de los ambientes.

Host Power Management en ESXi 5

vSphere HPM en ESXi 5 se encuentra diseñado para reducir el consumo de energia en los hosts ESXi.


ESXi 5 incluye cuatro diferentes politicas de energia que están basadas en el uso de los estados de performance ACPI (P-States) del procesador, y en los estados de energia ACPI (C-States) del procesador.

Los P-States pueden ser utilizados para ahorrar energia cuando la carga de trabajo en ejecución sobre el host no requiere una capacidad completa de CPU.  Los C-States pueden ahorrar energia solo cuando la CPU tiene una cantidad significativa de tiempo disponible, por ejemplo, cuando la CPU está esperando que una operación de I/O se complete.

Politicas de Energia HPM en ESXi5
ESXi cuenta con las siguientes politicas de energia:



  • High Performance: Esta politica maximiza la performance, y no utiliza ninguna funcionalidad de gestión de energia.  Esta es la politica por defecto para ESX/ESXi 4.x.
  • Balanced: Esta politica está diseñada para reducir el consumo de energia del host, mientras se tiene poco o ningún impacto en la performance.  Esta es la politica por defecto para ESXi 5
  • Low Power: Esta politica está diseñada para reducir en forma más agresiva el consumo de energia del host, al riesgo de reducir la performance.
  • Custom: Esta politica parte con la misma configuración que la politica "Balanced", pero permite que parametros individuales sean modificados.  Si el hardware del host no permite al sistema operativo gestionar la energia, el unico parametro disponible es "Not Supported".


Para cambiar la politica a utilizar, deben ir a la sección "Configuration" del Host, y luego seleccionar Power Management en la sección "Hardware".







Espero que les haya resultado interesante.  Si quieren saber más de HMP, incluyendo su funcionamiento y best practices, pueden revisar el siguiente Whitepaper:


vSphere 5: What's New - Performance


Con el lanzamiento de vSphere 5 se obtienen una serie de mejoras en la performance de nuestra plataforma VMware, las cuales detallaremos a continuación.
Las mejoras de performance se dividen en 5 pilares, los cuales detallaremos brevemente:
  • Mejoras a nivel de vCenter Server
  • Mejoras a nivel de capacidad de computo
  • Mejoras a nivel de almacenamiento
  • Mejoras a nivel de networking
  • Mejoras a nivel de vMotion

Mejoras a nivel de vCenter Server
vSphere 5 incluye mejoras en la escalabilidad que permite, por ejemplo, un mayor número de máquinas virtuales por clúster.  Aún con esta mayor escalabilidad, vSphere 5 incluye una serie de mejoras en la performance relacionadas a las operaciones de administración en vCenter Server, así como también en las funcionalidades relacionadas  con High Availability (HA):
  • Hasta un 120% de mejora en el throughput (operaciones/minuto) de las operaciones de administración en vCenter.  Por ejemplo, en el encendido/apagado/migración/registro de máquinas virtuales.
  • Una mejora del 25% al 75% en la latencia de las operaciones de administración, dependiendo del tipo de operación.
  • La configuración de un cluster HA puede ser realizada hasta 9 veces más rápido en vSphere 5, dependiendo del tamaño del cluster.
  • En vSphere 5 se puede realizar el failover de hasta un 60% más de máquinas virtuales, en el mismo periodo, respecto a versiones anteriores
  • El tiempo mínimo de recuperación, desde la falla hasta que la primera máquina virtual es reiniciada, ha sido mejorado en un 44.4%
  • El tiempo promedio para el failover de máquinas virtuales ha sido mejorado en un 14%.
  • El Slot size por defecto para la CPU ahora es de solo 32Mhz, permitiendo un mayor radio de consolidación en comparación con versiones anteriores.
Mejoras a nivel de capacidad de computo
  • vSphere 5 soporta hasta 32 vCPU y hasta 1TB de vMEM por máquina virtual, lo cual permite que aplicaciones Tier 1  y de misión critica alcancen una mayor performance.
  • Mejoras en el scheduler de la CPU en arquitecturas Intel SMT, permitiendo una mejora del 10% al 30% en la performance de las aplicaciones, dependiendo de la carga de trabajo.
  • En vSphere 5 se incluye Virtual NUMA o vNUMA, que expone la topología NUMA al sistema operativo de las máquinas virtuales, permitiendo que el sistema operativo y aplicaciones hagan un mejor uso de la arquitectura NUMA del host.  Se requiere Virtual Hardware versión 8.
  • vSphere 5 permite a los usuarios configurar un caché para Swap en un disco de estado sólido o SSD.  De esta manera, cuando Transparent Page Sharing, Ballooning y la Compresión de memoria no han sido suficientes para obtener los recursos de memoria requeridos, el proceso de swapping se realizará en ésta cache en vez de utilizar un archivo normal de swap en disco.  Esto permite una mejora importante en la performance reduciendo la latencia en escenarios de escasez de memoria.
Mejoras a nivel de almacenamiento
  • vSphere 5 Storage I/O control ahora soporta NFS y “shares” basados en NAS.  Esto permite regular dinámicamente el acceso de múltiples máquinas virtuales a recursos de I/O compartidos en un clúster, basados en los shares asignados a las máquinas virtuales.
Mejoras a nivel de Networking
  • vSphere 5 incluye mejoras en NetIOC, donde agrega funcionalidades de QoS (802.1p) y permite la creación de Resource Pools para limitación de anchos de banda.
  • vSphere 5 incluye splitRxMode, una nueva funcionalidad para dividir el costo de la replicacion de paquetes para multicast entre varias CPUs físicas, permitiendo que vSphere 5 sea una plataforma altamente escalable y eficiente para receptores de multicast.  En versiones previas, la replicación de paquetes para multicast es hecha usando un único contexto, y en escenarios con una alta densidad de máquinas virtuales por host, esto puede provocar cuellos de botella y causar perdida de paquetes.  SplitRxMode puede ser habilitado en una virtual NIC VMXNET3, y permite dividir el costo del procesamiento de paquetes recibidos en multiples contextos, mejorando  significativamente la performance de multicast.
Mejoras a nivel de vMotion
  • vSphere 5 permite que vMotion sature en forma efectiva el ancho de banda de un adaptador de red 10GbE durante una migración, reduciendo los tiempos de transferencia en una operación de vMotion.
  • Se permite el uso de multiples adaptadores de red para las operaciones de vMotion, donde el VMkernel balanceara la carga del trafico de vMotion, en forma transparente, sobre todas las vmknics con vMotion habilitado, tratando de saturar todas las conexiones para distribuir el trafico de vMotion, incluso en operaciones unicas de vMotion.
  • Se incluye una nueva funcionalidad de “Metro vMotion” que provee de una mejor performance sobre redes con alta latencia y aumenta los limites de latencia para redes de vMotion de 5ms a 10ms.
  • Se incluye soporte de Live Migration para Storage (Storage vMotion) con el uso de I/O Mirroring.  Esto permite una mayor movilidad de máquinas virtuales, mantenimiento con zero downtime, y balanceo de carga de almacenamiento manual y automatico.
Conclusión
Como podemos ver, vSphere 5 incluye un numero importante de mejoras a nivel de performance, lo cual nos permite virtualizar aplicaciones de cualquier envergadura, tanto en pequeños ambientes, como en grandes implementaciónes con aplicaciones de mision critica y Tier-1.
Para mayor información, pueden revisar el siguiente White Paper de VMware con todo el detalle de las novedades de vSphere 5, relacionados con la performance: