Compare el desempeño de los agentes virtuales con el de los reales

Ejecute agentes Rational Performance Tester en una VM para comparar los niveles de desempeño de los agentes

En este artículo, los autores comparan la ejecución de agentes Rational® Performance Tester (RPT) en una máquina virtual, con la ejecución de agentes RPT en una máquina "real". Los resultados iniciales muestran que la ejecución en una máquina virtual tienen mayor variabilidad en cuanto a los tiempos de respuesta reportados. Aplicar optimización de red a las máquinas virtuales reduce la variabilidad y hace que el uso de agentes RPT virtualizados sea aceptable, siempre y cuando no ocurra una migración de VM durante una ejecución de rendimiento.

Andrew Citron, Programador sénior, IBM

Andrew CitronAndy Citron trabaja en el grupo de desempeño del WebSphere Portal en el Research Triangle Park, NC. Su carrera de más de 30 años con IBM incluye periodos de creación de productos como la Mwave Multimedia Card y subsistema de respuesta telefónica y discriminación de llamadas, procesadores de palabra, sistemas operativos y acceso inalámbrico a Internet. A finales de los años 80 Andy fue arquitecto principal para el protocolo de comunicación SNA conocido como APPC (o LU6.2); su trabajo en el grupo de arquitectura SNA condujo a numerosas patentes en el área de procesamiento de compromiso distribuido de dos fases.



Gaurav Bhagat, Analista de desempeño, IBM

Gaurav Bhagat trabaja actualmente como analista de desempeño del portal en z/OS System en IBM Lotus Labs en Dublín, Irlanda. Cuenta con más de nueve años de experiencia en tecnologías de sistema principal, trabajando con varios clientes globales. Él es IBM Certified Database Administrator: DB2 9 for z/OS, IBM Certified Database Administrator DB2 UDB V8.1 for z/OS e IBM Certified System Administrator: DB2 9 for z/OS. También es instructor IBM Certified DB2 for z/OS Data Sharing y ha impartido clases en los EE.UU., Europa y Asia.



Marshall Massengill, Soporte holístico digital, IBM

Marshall Massengill trabaja para la organización Centralized IT del Software Group de IBM en RTP. Marshall comenzó a trabajar con IBM a la edad de 17 años como joven graduado de la North Carolina School of Science and Mathematics (NCSSM). Se graduó de la NCSSM en el 2005 y continuó asistiendo a la North Carolina State University donde obtuvo un grado en Ingeniería de la Computación. Su rol principal ahora es apoyar en la implementación y mantenimiento de la infraestructura de virtualización centralizada de TI. Le apasiona explorar los usos creativos de nuevas tecnologías, lo cual desarrolló su habilidad para proporcionar soporte y asistencia en un amplio rango de equipos y servicios en IBM.



05-11-2012

Un fundamento clave de la computación en nube es la virtualización. Una pregunta referente a la nube que diseñadores, desarrolladores y administradores necesitan responderse es "¿cómo se compara el nivel de rendimiento de componentes virtualizados con el de sus contrapartes físicas 'reales'?" "Y si hay una brecha negativa, ¿cómo puedo superarla?"

Este artículo describe los resultados de una serie de experimentos en agentes IBM® Rational® Performance Tester ejecutados en máquinas virtuales (VMs) y ofrece algunas ideas básicas sobre la discusión entre virtual vs. "real".

Detrás de los experimentos

Explicamos una serie de experimentos en los que agentes Rational Performance Tester se ejecutan en máquinas virtuales y comparamos esos resultados con la ejecución de las mismas pruebas en hardware no virtualizado. Antes de examinar el entorno virtualizado que usamos, comencemos con una contextualización sobre la terminología y la metodología que usamos, y un resumen de los resultados.

Terminología

Usted podrá seguir los experimentos fácilmente al comprender estos términos:

Agente Rational Performance Tester
Software que simula miles de usuarios enviando solicitudes a un servidor.
Vuser
Usuario virtual. Cada usuario virtual simula a muchos usuarios durante el curso de la prueba. Un vuser en ejecución inicia ejecutando el script con una identidad de usuario única. Después de que el script se completa, el vuser selecciona otra identidad de usuario única y ejecuta el script de nuevo, como esa identidad de usuario nueva y única. El vuser repite este proceso de seleccionar una nueva identidad de usuario y ejecutar el script, mientras el vuser se esté ejecutando.
Agente real
Agente RPT que se ejecuta en hardware no virtualizado.
VM
Máquina virtual. Un agente virtual es un agente RPT que se ejecuta en una VM.
vMotion
Cuando el gestor de VM mueve la imagen de VM de una máquina física a otra.
Meseta
Representa un lapso de tiempo durante el cual el mismo número de vusers están activos durante una prueba.
TPS
Transacciones por segundo. TPS y PPS (páginas por segundo) se utilizan alternativamente como una medida de resultado.
Paravirtualización
Técnica de virtualización que presenta una interfaz de software a máquinas virtuales, que es similar pero no idéntica a la del hardware subyacente.

Metodología

La misma prueba de rendimiento se ejecutó un número de veces usando agentes RPT reales y agentes RPT virtualizados.

El punto de comparación de rendimiento incluyó cierto número de solicitudes HTTP diferentes efectuadas por diferentes usuarios simulados. El punto de referencia y el sistema bajo prueba no son el tema central de este artículo. Este artículo se enfoca en los agentes RPT que generaron la carga simulada.

Cada prueba consistió en tres ejecuciones de 5 minutos, simulando 2.000 vusers y tres ejecuciones de 5 minutos simulando 2.500 vusers. Cada prueba se ejecutó dos veces usando agentes reales y dos veces utilizando agentes virtuales.

En cada prueba hubo cinco máquinas ejecutando agentes RPT. Una de esas máquinas era una máquina real que solo ejecutó 100 vusers. Esa máquina se utilizó como punto de comparación; nunca ejecutó suficiente carga como para causar la una disputa por sus recursos. Sin embargo, ejecutó suficientes vusers como para generar un tamaño de muestra utilizable. Esto nos permitió comparar una máquina real levemente cargada, con VM y máquinas reales con cargas pesadas.

El análisis se realizó sobre las ejecuciones de 5 minutos. Las ejecuciones de 5 minutos también se combinaron con una meseta de 15 minutos. Las ejecuciones más largas proporcionaron más puntos de datos para cada intervalo. Más puntos de datos significan mayor estabilidad en los promedios.

También efectuamos un experimento en donde el agente virtual se movió de una máquina virtual hacia otra durante la carga de prueba. A este proceso lo llamamos vMotion.

Resumen de los resultados generales

En el conjunto inicial de pruebas los tiempos de respuesta y el rendimiento reportados por los agentes virtuales variaron más que los tiempos de respuesta reportados por los agentes reales. Para los puntos de referencia, donde hay criterios de tiempo de respuesta, esta variación causa un problema. Análisis y experimentación subsiguientes condujeron a una configuración de optimización de red VM que redujo la variación en el tiempo de respuesta. Con dicha optimización aplicada, las VMs se comportaron de manera aceptable como agentes RPT.

El experimento donde se migró el agente virtual (vMotion) mostró un pico en el tiempo de respuesta reportado mientras la VM pasó por el proceso de migración. La conclusión aquí es que la migración de VM debe ser una ocurrencia poco común; el analista debe saber cuándo ha ocurrido dado que esta puede afectar el resultado de la prueba.

Ahora observemos el entorno virtualizado.


Descripción de un entorno virtualizado

En el campo de las TI siempre hay más de una forma de resolver un problema dado. Esto es particularmente cierto en el área de diseño de una buena infraestructura de virtualización, donde las posibilidades son prácticamente ilimitadas. Es importante entender que el diseño de infraestructura descrito aquí no es una "mejor práctica recomendada" ni un "entorno modelo", sino un intento por crear una solución que funcione para el entorno de laboratorio para el cual proporciona hosting.

Existen tres partes principales en cualquier infraestructura de virtualización — servidores, almacenamiento y la red. El entorno usado para estas pruebas:

  • Servidores. Los servidores fueron IBM System x3850 X5s. Cada uno de estos servidores está cargado con cuatro CPUIntel Xeon X7560 y 512GB de RAM. Los servidores están agrupados tanto física como lógicamente en clústeres de ocho máquinas. Esta agrupación de máquinas en clúster se describe a profundidad más adelante.
  • Infraestructura de almacenamiento. El almacenamiento para estos servidores consiste en mallas redundantes de canal de fibra SAN. Las mallas se hacen redundantes mediante adaptadores de bus de host de puerto dual en los servidores y conmutadores SAN redundantes en la parte superior del bastidor. Luego estos interruptores se conectan a una malla más grande que consta de múltiples enlaces ascendentes hacia múltiples redes acopladas de almacenamiento (SAN) IBM DS5300. Cada conjunto de ocho servidores es ubicado en un grupo de host que solo puede acceder a ciertos Logical Unit Numbers (LUN) de las SAN. Cada host de un grupo de host puede ver únicamente el almacenamiento que está a disposición para ese grupo de host.
  • Infraestructura de red. La red para estos servidores consiste en un enlace de administración de 100MB y cuatro enlaces de 1GB, para un total de cinco conexiones Ethernet hacia cada servidor.
    • El enlace de administración de 100MB se utiliza para comunicación con el Integrated Management Module incorporado, el cual habilita el acceso remoto a consola para el servidor, así como la capacidad para monitorear el estado del hardware.
    • Los cuatro enlaces de 1GB están divididos en dos grupos de dos conexiones cada uno:
      • El primer grupo se utiliza para tráfico de datos para las máquinas virtuales.
      • El segundo grupo se utiliza para administración de tráfico hacia el servidor host.

El tráfico de administración se mantiene aislado en una red interna privada, mientras que el tráfico de datos es se efectúa en una red pública más grande. Esto se hizo para reducir la cantidad de tráfico en la red de datos y también para garantizar la seguridad del tráfico de administración. Cada grupo de enlaces se divide aún más entre un enlace activo y uno en espera. Esta combinación de enlaces activos y en espera garantiza la redundancia.

Para permitir que una multitud de redes públicas y privadas se conecten, se utiliza etiquetamiento VLAN. Cada paquete saliente de una máquina virtual dada es etiquetado con el número VLAN apropiado. Esto hace posible acceder a un mayor número de subredes de todo el entorno. Esto también permite a las máquinas virtuales transitar de un clúster de máquinas a otro, mediante un proceso conocido como migración.

La Figura 1 bosqueja el entorno virtualizado.

Figura 1. El entorno virtualizado
The virtualized environment

Los agentes reales se ejecutan en máquinas Intel® Xeon® de dos procesadores de 2.8GHz y 2GB de RAM. Estas máquinas tenían tarjetas Ethernet de 1GB.

Los agentes virtuales ejecutaron RedHat Linux ®. Los agentes reales ejecutaron Windows® Server 2003. Habría sido mejor si los agentes virtuales y reales se hubieran ejecutado en el mismo hardware y software, pero esa no era una opción. Contamos con más evidencia que indica que los agentes reales que se ejecutaron en Linux presentan menos de un 1% de variación en cuanto a rendimiento entre ejecuciones. Esto es similar a lo que vimos en loa agentes reales en Windows.

La máquina que utilizamos como máquina real de control fue un Intel Xeon, ejecutando Windows Server 2003. Tenía dos procesadores de 3.2GHz. El hiperhilado estaba activado. RAM de 3.5GB. Con tarjeta Ethernet de 100MB. Sólo ejecutó 100 vusers. No necesitaba ser tan potente como los otros agentes.


Ilustrando los resultados

Ahora le mostraremos algunas gráficas que ilustran los números detrás de las conclusiones a las que llegamos; le mostraremos el rendimiento y los tiempos de respuesta, antes y después de la aplicación de la optimización de red.

Rendimiento y tiempos de respuesta para la red sin optimizar

La primera gráfica (Figura 2) muestra el rendimiento y los tiempos de respuesta reportados por los agentes virtualizados antes de aplicar la optimización de red. Esta se puede comparar con la segunda gráfica (Figura 3), que muestra la misma información para los agentes reales. Estas gráficas son de las mesetas de carga de trabajo de 2.500 vusers.

Figura 2. Agentes virtuales, red sin optimizar, 2.500 vusers
Virtual agents, untuned network, 2,500 vusers
Figura 3. Agentes reales, red sin optimizar, 2.500 vusers
Real agents, untuned network, 2,500 vusers

Las gráficas ilustran que el rendimiento y los tiempos de respuesta reportados de los agentes virtualizados variaron más que los de los agentes reales:

  • Los tiempos de respuesta reportados por los agentes virtuales variaron de 188,6ms a 104,5ms; un rango de 48,1 milisegundos.
  • Los tiempos de respuesta reportados por los agentes reales variaron de 148,4ms a 120,6ms; un rango de 27,8 milisegundos.

La tasa de visitas a página reportada por los agentes VM estuvo entre 215,9 PPS y 219 PPS. Es una diferencia de 3,1 PPS para los agentes virtualizados. Los agentes reales reportaron una variación entre 218,5 PPS y 219,3 PPS. Un a diferencia de 0,8 PPS. De nuevo, esto ilustra que los agentes virtuales mostraron una varianza más alta que los agentes reales en los datos que reportaron.

Después de afinar el adaptador de red de las VMs

Después de que el primer conjunto de pruebas mostrara ala variabilidad en los tiempos de respuesta reportados por los agentes virtuales, cambiamos el tipo de adaptador de red virtual que la máquina estaba usando.

Es posible pensar en esto como si se conmutara el adaptador Ethernet de un sistema físico.

Originalmente, las máquinas virtuales se configuraron para usar un adaptador "flexible", que es básicamente la forma en que el VMware permite que se seleccione el adaptador con base en las necesidades del sistema. Estos adaptadores funcionan muy bien en teoría y no tan bien en la práctica. El VMware les ha descartado en favor de algo llamado adaptadores VMXNet3 o VMXNet2. También está la opción de usar un adaptador de red virtual E1000 que es básicamente una Tarjeta de Red Intel E1000 emulada.

Cambiamos el adaptador flexible a favor del adaptador VMXNet3. Esto proporcionó un incremento en el desempeño de todo el tráfico de red del sistema. El adaptador VMXNet3 es técnicamente un adaptador de red paravirtual. El hardware paravirtual funciona sobre la idea de descargar tareas de la CPU host hacia los recursos físicos del sistema. En el caso de estos adaptadores Ethernet paravirtuales, la carga de trabajo es manejada por los adaptadores reales físicos Intel y Broadcom de los host y no en la CPU de los mismos. Esto da como resultado mayor rendimiento y mejores tiempos de respuesta.

Junto con la aplicación de este cambio al hardware, el cambio también se hizo para el sistema operativo del huésped y al controlador que este utiliza para comunicarse con el adaptador. Esto es similar a instalar nuevos controladores en una máquina física después de instalar un nuevo adaptador de red. Lo mismo debe hacerse en una máquina virtual.

La Figura 4 muestra que después de aplicar el adaptador VMXNet3, los tiempos de respuesta fueron menores que antes. De hecho, los resultados con el adaptador VMXNet3 fueron inferiores que en todas las demás pruebas. Las PPS reportadas también fueron ligeramente superiores.

Figura 4. Comparando agentes reales, VMs con/sin el adaptador VMXNet3
Comparing real agents, VMs with/without the VMXNet3 adapter

En esta gráfica no se muestra, pero la variación de los tiempos de respuesta reportados también fue menor con el adaptador VMXNet3. Esto es importante para poder reproducir resultados entre una ejecución y otra.

La conclusión es que con las configuraciones de red adecuadas, un agente de red es tan confiable como un agente virtual para reportar rendimiento y tiempos de respuesta.


Clústeres y vMotion

vMotion es tecnología VMware que permite migrar máquinas virtuales en vivo de un servidor a otro. Esto generalmente se hace con propósitos de balanceo de carga. En nuestro experimento forzamos la migración de una de las cinco mesetas de 5 minutos. Lo hicimos para determinar el efecto que podría tener sobre los datos reportados por los agentes virtualizados.

Cada clúster de servidores comparte algunas características. Cada agrupación de ocho servidores comparte el mismo tipo de hardware. Las CPU, la memoria, el disco y los adaptadores son iguales en cada máquina dentro del clúster. Esta igualdad es clave para que el proceso vMotion funcione adecuadamente.

Los clústeres de las máquinas también comparten características de configuración, como alta disponibilidad y programación dinámica de recursos:

  • La alta disponibilidad es el proceso mediante el cual las máquinas virtuales se mantienen en ejecución para minimizar los periodos de inactividad en el evento de una falla del hardware. Si un servidor dentro de un clúster experimenta una falla, las máquinas virtuales de ese servidor son puestas en línea inmediatamente en un servidor diferente dentro de ese clúster. Esto minimiza cualquier periodo de inactividad resultante de una perturbación del servicio.
  • La programación dinámica de recursos es el proceso mediante el cual las máquinas virtuales son movidas dinámicamente entre servidores de un clúster, con base en sus necesidades de recursos y en la disponibilidad de recursos para que estas utilicen. Si una máquina virtual necesita recursos de CPU en un host que tiene muy pocos recursos disponibles, esa máquina virtual será migrada hacia un host diferente donde haya recursos de CPU disponibles. De manera alternativa, las máquinas virtuales que necesiten menos recursos con frecuencia son migradas para crear espacio para las máquinas virtuales que necesiten consumir más recursos.

El proceso de vMotion funciona migrando una máquina virtual que esté en un estado de ejecución actual, de un host hacia otro dentro de un clúster. La máquina virtual se mantiene en ejecución mientras se lleva a cabo este proceso y como resultado, la máquina virtual prácticamente no experimenta ninguna perturbación.

En nuestras pruebas hemos observado que lo máximo que los usuarios finales experimentan es un retraso corto, que no es diferente a la pérdida de uno o dos paquetes debido a fallas de transmisión de red. Esta es una interrupción aceptable para la ejecución de pruebas de integración, facilidad de uso, funcionalidad y de otros tipos, pero no para pruebas de desempeño donde la pérdida de un solo paquete puede distorsionar el resultado. Realizar vMotion con frecuencia también puede ser un problema en un ambiente de producción que tenga acuerdos estrictos de nivel de servicio.

Tanto la programación dinámica de recursos como la alta disponibilidad pueden usar el proceso vMotion para migrar máquinas virtuales que se estén ejecutando en un host hacia otro, para proporcionar protección contra fallas o para satisfacer las necesidades de recursos inmediatas de una máquina virtual. La Figura 5 muestra nuestro entorno virtualizado con una migración vMotion en curso.

Figura 5. Migración vMotion en el entorno virtualizado
vMotion migration in the virtualized environment

Bajo circunstancias normales, vMotion no sucede con frecuencia. Consideramos que un experimento realista era migrar una de las cuatro VM que utilizamos durante la prueba. También tuvimos un quinto agente real que ejecutó 100 vusers. Ese agente lo utilizamos como control para tener cierta idea de los tiempos de respuesta reportados por un agente que no se vería afectado por la vMotion.

El efecto de la migración de VM fue aparente. El efecto duró cerca de un minuto. Las siguientes gráficas ilustran esto.

La Figura 6 muestra el reporte de un agente VM durante la migración. Esta se tomó en la meseta de 2.000 vusers.

Figura 6. Página de tiempo de respuesta durante la migración; el pico es malo
Page response time during migration; spike is bad

El pico en el tiempo de respuesta donde ocurrió vMotion es evidente. Este tipo de pico, causado por la infraestructura de virtualización, es inaceptable durante la ejecución de la prueba de desempeño.

A continuación, observe vMotion cuando se analiza como mesetas de 15 minutos (Figura 7).

Figura 7. Una meseta más extensa permite un promedio más estable
A longer plateau makes for more stable average

La meseta más extensa proporciona un promedio más estable y minimiza el efecto sobre la migración de VM. Sin embargo, todavía es posible ver que vMotion causó mayores tiempos de respuesta a ser reportados por los agentes virtualizados. Esta gráfica muestra tiempos de respuesta promedio generales, comparados con el tiempo de respuesta en el agente real que ejecutó 100 vusers.

La gráfica de la Figura 7 muestra que una VM en migración afectó los tiempos de respuesta promedio reportados. Incluso cuando tres de las cuatro VM no migraron, el mayor tiempo de respuesta reportado por la VM en migración causó que el tiempo de respuesta promedio fuera superior al reportado por el agente real del grupo de control.

Lo que no se puede ver en la Figura 7 es que el impacto de la migración de la VM afectó los tiempos de respuesta reportados por todos los agentes. Presumiblemente, esto fue causado por un cuello de botella, donde el servidor bajo prueba no pudo completar las solicitudes que se iniciaron por la migración de la VM sino hasta que la VM terminó su migración.

En general, es mejor si vMotion se puede desactivar en los agentes virtualizados. Cuando se está ejecutando una prueba de desempeño, cualquier fuente no controlada de varianza es un problema.

Si no es posible desactivarla, es importante poder determinar si ha ocurrido una vMotion durante una prueba. La infraestructura de virtualización proporciona registros que pueden examinarse para determinar si ha ocurrido una migración. La captura de pantalla (Figura 8) es de la vista al interior del software cliente de la infraestructura virtual de Tasks and Events, de una de las VM en la cual se efectuó la migración. Los registros indican claramente que se efectuó una tarea de migración junto con quien inició la tarea y cuando se completó la tarea.

Figura 8. Registros como fuente para determinar si se lleva a cavo una vMotion (si no es posible deshabilitarla)
Logs as a source of determining whether vMotion takes place (if you can't disable it

(Vea una versión más grande de la Figura 8.)

Si el sistema ha estado moviendo dinámicamente las máquinas virtuales con base en la carga, entonces la tarea pudo haber sido iniciada por el Sistema y no por un usuario (en este caso, VISRTP/marshall). Esta información de registro también puede ser reunida o verificada programáticamente con API de VMware y herramientas de scripting.

Es importante notar que la programación dinámica de recursos puede deshabilitarse para ciertas máquinas virtuales en un entorno dado. Esto incrementa el riesgo de afectar el tiempo de disponibilidad de una máquina virtual a causa de una interrupción de host, pero para un equipo de desempeño, mantener un rendimiento constante es más importante que la posibilidad de una interrupción.


En conclusión

Virtualizar los agentes Rational Performance Tester es una configuración viable; no obstante, es importante asegurarse de que el entorno virtualizado se optimice adecuadamente. La configuración de la tarjeta de red fue crítica en nuestro entorno.

Para una evaluación de la comparación, es mejor tener agentes no virtualizados que se estén ejecutando en hardware y sistemas operativos equivalentes a los de los agentes virtualizados. Aunque para determinación de problemas, es una buena práctica tener un conjunto de agentes reales, preferiblemente ejecutándose en un sistema operativo diferente al de los agentes virtualizados. Encontramos que los agentes reales son un grupo de control útil cuando ocurren problemas o cuellos de botella. Al ejecutar una prueba con los agentes reales pudimos establecer que la VM era la causa de los problemas.

Si ocurrió una migración de VM durante una prueba, es importante que el analista sea consciente de ello. Es preferible la supervisión automatizada de las VM. La mejor alternativa es desactivar vMotion en los servidores que hospeden a los agentes RPT.

Recursos

Aprender

Obtener los productos y tecnologías

Comentar

Comentarios

developerWorks: Ingrese

Los campos obligatorios están marcados con un asterisco (*).


¿Necesita un IBM ID?
¿Olvidó su IBM ID?


¿Olvidó su Password?
Cambie su Password

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


La primera vez que inicie sesión en developerWorks, se creará un perfil para usted. La información en su propio perfil (nombre, país/región y nombre de la empresa) se muestra al público y acompañará a cualquier contenido que publique, a menos que opte por la opción de ocultar el nombre de su empresa. Puede actualizar su cuenta de IBM en cualquier momento.

Toda la información enviada es segura.

Elija su nombre para mostrar



La primera vez que inicia sesión en developerWorks se crea un perfil para usted, teniendo que elegir un nombre para mostrar en el mismo. Este nombre acompañará el contenido que usted publique en developerWorks.

Por favor elija un nombre de 3 - 31 caracteres. Su nombre de usuario debe ser único en la comunidad developerWorks y debe ser distinto a su dirección de email por motivos de privacidad.

Los campos obligatorios están marcados con un asterisco (*).

(Por favor elija un nombre de 3 - 31 caracteres.)

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


Toda la información enviada es segura.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=Cloud computing, Rational
ArticleID=844465
ArticleTitle=Compare el desempeño de los agentes virtuales con el de los reales
publish-date=11052012