WebSphere Virtual Enterprise

Componentes de Operaciones Dinámicas

WebSphere Virtual Enterprise (WVE) antes conocido como WebSphere Extended Deployment Operations Optimization, nos permite la virtualización de la infraestructura de aplicaciones, definir niveles de servicio deseados y monitoreo de salud, con estas facilidades podemos separar las aplicaciones de negocio de la plataforma física donde estas se ejecutan al tener un grupo de servidores que se pueden adaptar a las demandas de las cargas de trabajo.

Pedro Lucio Ibarra Martínez, Premium Support Services, Software Group, IBM

Foto de Pedro Lucio Ibarra MartinezCon mas de 10 años de experiencia trabajando profesionalmente en diferentes áreas y roles de IT, Actualmente en IBM de México forma parte del equipo de SWG Accelerated Value Program, dentro de sus responsabilidades se encuentra dar guia tecnológica sobre los productos de la brand de WebSphere, principalmente WAS, WVE, Edge Components, MQ y WMB.



07-01-2011

Introducción

WebSphere Virtual Enterprise (WVE) antes conocido como WebSphere Extended Deployment Operations Optimization, nos permite la virtualización de la infraestructura de aplicaciones, definir niveles de servicio deseados y monitoreo de salud, con estas facilidades podemos separar las aplicaciones de negocio de la plataforma física donde estas se ejecutan al tener un grupo de servidores que se pueden adaptar a las demandas de las cargas de trabajo.

Un ambiente de WVE se logra definiendo clusters de servidores que crecen y se reducen en número de manera dinámica de acuerdo a las necesidades de negocio las cuales se definen en reglas de servicio y reglas de salud. Estas reglas y la información que se va generando de la supervisión del comportamiento del cluster dinámico de servidores, permiten a los componentes del ambiente de operaciones dinámicas analizar si el comportamiento es el esperado o si tendrán que tomar decisiones que pueden ir desde priorizar las peticiones a las aplicaciones de negocio que el cluster de servidores atiende, reinicio de instancias del cluster que no estén cumpliendo con los objetivos definidos o hasta la reducción o incremento del numero de miembros del cluster dinámico de servidores de manera automática.

Las acciones a tomar cuando las condiciones no son las óptimas definidas en un ambiente WVE serán responsabilidad de los Componentes del Ambiente de Operaciones Dinámicas, estos componentes responderán de manera *automática para mantener estable el ambiente y así poder cumplir con las necesidades del negocio

Componentes del Ambiente de Operaciones Dinámicas

Políticas Operacionales

Políticas de servicio
Las políticas de servicio nos permiten definir reglas de negocio para unidades de trabajo invocadas por ejemplo mediante el uso de peticiones http las cuales son priorizadas con métricas de desempeño deseadas, cada política de servicio lleva asociada una métrica de desempeño y una prioridad. En la figura 1 se muestra la pantalla donde se administran las políticas de servicio.

*Los clusters dinámicos tienen la posibilidad de definir su modalidad de ejecución para ser supervisados o automáticos, cuando se decide poner en modo supervisado todas las acciones que se disparen por los componentes de operaciones dinámicas deberán ser aprobados manualmente para su ejecución. Cuando se opta por una modalidad automática estas acciones se ejecutan de manera inmediata.

Figura 1. Administración de Políticas de Servicio
.

Los objetivos de desempeño esperado están divididos de la siguiente manera:

Discrecionales: Es la política de servicio por defecto, no existe una alta prioridad de atención para las peticiones que usan esta política de servicio y serán atendidas solo cuando no existan otras peticiones con una prioridad mas alta definida.

Tiempo de respuesta promedio: Permite definir un tiempo de respuesta esperado para una petición, este tiempo se puede definir en milisegundos o segundos y el ambiente de operaciones dinámicas medirá que se cumpla al menos con el 90% de las peticiones en el tiempo de respuesta configurado y así cumplir con esta métrica.

Porcentaje de tiempo de respuesta: Esta métrica permite definir el tiempo de respuesta promedio y el porcentaje de peticiones que se desea que sean atendidos y que cumplan con el tiempo de respuesta para así poder cumplir esta métrica. Por ejemplo se define que el 70% de las peticiones sean atendidas en un rango de 5 segundos o menos.

El tiempo de medición para determinar si se esta cumpliendo o no con las reglas es configurado al momento de crear la política de servicio.

Figura 2. Definición de objetivo de desempeño
.

Las Importancia para estas métricas de desempeño van desde Máxima, Muy alta, Alta, Media, Baja, Muy baja y Mínima, como se muestra en la figura 3.

Figura 3. Definición de Importancia de la política de servicio
.

Estas métricas de desempeño serán tomadas por el ARFM para atender de manera más pronta las peticiones que están clasificadas con un tiempo de respuesta promedio menor y mantener en el arreglo de peticiones por atender aquellas que tengan una métrica de tiempo de respuesta promedio mayor.

Políticas de Salud

Las políticas de salud se encargan de medir el estado de los diferentes recursos del ambiente donde residen las instancias de los servidores de aplicaciones, los recursos para los que se tienen políticas de salud definidas por defecto son, la cantidad de memoria definida para el jvm, los tiempos de respuesta excesivos para las peticiones, tiempo de espera excesivo, fugas de memoria y el tiempo sin reiniciar el servidor. En la figura 4 se muestran las políticas de salud por defecto en el ambiente WVE.

Figura 4. Políticas de Salud por Defecto
.

Cada una de estas políticas de salud debe contener una acción reactiva que es definida para ser aplicada en modo automático o supervisado. Cuando una de estas políticas de salud no es satisfecha el controlador de salud evalúa la política y realiza la acción reactiva definida. Las acciones que por defecto existen para las políticas de salud son reinicio de del servidor de aplicaciones, generar volcados de hilos, generar volcados del jvm y poner en modo de mantenimiento el servidor que no cumple con la política de salud especificada. En la figura 5 se muestra la pantalla donde se administran las acciones asociadas con las políticas de salud.

Figura 5. Definición de Acciones de las políticas de salud
.

Direcciónador a demanda (ODR por sus siglas en ingles)

Es un proxy inteligente de http y es el punto de entrada al ambiente productivo funciona como enlace a través del cual las peticiones http son enviadas a los servidores de aplicaciones de acuerdo al peso que cada servidor tiene asignado en el cluster dinámico de servidores.
Puede decidir momentáneamente encolar las peticiones entrantes de las aplicaciones menos importantes de acuerdo a las reglas operacionales definidas para atender las peticiones de aplicaciones consideradas más importantes o para proteger que los servidores de aplicaciones se vean sobrecargados por exceso de peticiones.

El ODR esta conciente de todo el ambiente dinámico gracias a un componente llamado servicio de configuración a demanda (ODC por sus siglas en ingles) este componente recolecta la información de todos los componentes del ambiente WVE. En la figura 6 se muestra la pantalla para la definición de las propiedades del ODR.

Figura 6. Definición de las propiedades del ODR
.

Clúster Dinámico de Servidores de Aplicación

El Clúster dinámico de servidores provee la funcionalidad base de la virtualización de la infraestructura de los servidores de aplicaciones, consiste en un grupo de instancias de servidores de aplicaciones donde una o mas aplicaciones de negocio pueden ser puestas en operación y de acuerdo a la demanda de peticiones hacia estas aplicaciones las instancias pueden incrementarse o decrementarse en numero de manera dinámica automáticamente. En la figura 7 se muestra la pantalla de administración de los clusters dinámicos.

Figura 7. Administración de Clusters Dinámicos
.

Gestor del flujo de peticiones autónomo (ARFM por sus siglas en ingles)
Usa las reglas de servicio definidas para clasificar y controlar las peticiones a las aplicaciones y decidir cuando y como serán enviadas a la siguiente capa, normalmente la de servidores de aplicaciones.
El ARFM conoce las capacidades de las diferentes instancias que componen el cluster dinámico de servidores, sabe cuantas peticiones esta procesando cada miembro del cluster y la cantidad de recursos que esta consumiendo, con toda esta información produce estadísticas de demanda que luego serán utilizadas por el controlador de ubicación de aplicaciones (APC) para determinar si es necesario agregar o eliminar un miembro al cluster dinámico de servidores. En la figura 8 se muestra la pantalla para la definición de las propiedades del ARFM.

Figura 8. Definición de las propiedades del ARFM
.

Gestión dinámica de balanceo de carga (DWLM por sus siglas en ingles)
Una Vez que el ARFM ha clasificado y priorizado las peticiones el DWLM se encarga de balancear los flujos de las peticiones entre los diferentes nodos – servidores de aplicaciones disponibles para lograr regular los tiempos de respuesta.
Le asigna pesos a los diferentes servidores de aplicaciones dinámicamente para cumplir con las políticas de servicio definidas, estos pesos son luego utilizados por el ODR para distribuir la carga de la manera en que los pesos lo indiquen. En la figura 9 se muestra la pantalla donde se activa o se desactiva el DWLM

Figura 9. Administración del DWLM
.

Controlador de ubicación de aplicaciones (APC por sus siglas en ingles)

Crea y remueve instancias de servidores de aplicaciones para manejar las peticiones entrantes, de manera dinámica puede controlar el comportamiento de las instancias del cluster dinámico de servidores cuando se presentan periodos de carga de trabajo intenso o cuando esta carga de trabajo disminuye. El APC se asegura de que el numero de instancias, la distribución de las aplicaciones y los recursos de los nodos se mantengan apropiados para la carga de trabajo, para esto trabaja en conjunto con los nodos, el cluster dinámicos de servidores y el ODR. En la figura 10 se muestra la pantalla para la definición de las propiedades del APC.

Figura 10. Definición de las propiedades del APC
.

Controlador de salud

Se encarga de asegurarse que el ambiente donde se ejecuta WVE se mantenga sano de acuerdo a las políticas de salud definidas, y si alguna de estas políticas no se cumple ejecutar la acción correctiva que tenga configurada. En la figura 11 se muestra la pantalla para la configuración de las propiedades del Controlador de salud.

Figura 11. Configuración del Controlador de Salud
.

En la figura 12 podemos observar una representación del manejo de peticiones a alto nivel, la unidad de decisión del APC esta conciente de la criticidad de cada una de las peticiones entrantes así como también del estado de los recursos del cluster dinámico de servidores de aplicaciones de cada uno de los nodos.

En este caso las peticiones para la aplicación uno “PA1” tienen definidas las reglas de servicio como prioridad “Alta” y las “PA2” como prioridad “Baja”, suponiendo que en este momento no se tiene una carga de trabajo intensa, los componentes de operaciones dinámicas deciden que el tener un cluster dinámico de servidores de aplicaciones con dos instancias en cada nodo y en cada instancia ejecutando las dos aplicaciones será suficiente para atender la carga sin problemas.

Figura 12. Diagrama de manejo de peticiones
.

Cuando se tiene una carga de trabajo intensa el APC tiene diferentes opciones de acuerdo a como este configurado el crecimiento vertical del cluster dinámico de servidores, si el numero mayor de instancias al que puede crecer el cluster y que se definió al configurarlo ya se alcanzo, lo que hará será atender primero las peticiones de la aplicación con prioridad definida en las reglas de negocio como mas “Alta” y encolara las peticiones de las aplicaciones con prioridad mas “Baja” como se muestra en la figura 13, buscando siempre cumplir con las reglas definidas.

Figura 13. Diagrama de manejo de peticiones encoladas
.

Si aun puede crecer en el número de instancias en alguno de los nodos o los dos, y las políticas de salud se están cumpliendo, incrementara el número de instancias del cluster hasta cumplir con las políticas de servicio y salud definidas como se muestra en la figura 14, siempre respetando las reglas y prioridades definidas.

Figura 14. Diagrama de manejo de peticiones con incremento en el cluster de servidores dinámicos
.

Si aun con el crecimiento al máximo del número de instancias del cluster dinámico de servidores no se logra cumplir con las políticas de servicio establecidas, los componentes de operaciones dinámicas además de decidir encolar las peticiones de las aplicaciones con reglas y prioridades más bajas, alertaran de manera automática al administrador sobre esa situación.

Conclusión

Los componentes de Operaciones Dinámicas del ambiente WebSphere Virtual Enterprise son vitales para ayudar a los usuarios de servidores de aplicaciones a tener un ambiente de misión crítica que cumpla con los tiempos de respuesta deseados, utilizando un número optimizado de servidores de aplicaciones, un manejo eficiente de la carga de trabajo, asegurando la disponibilidad de las aplicaciones y una administración operacional completa, todo esto convierte a WebSphere Virtual Enterprise en una gran opción para tomar decisiones de manera automática y disminuir el factor humano en las tareas de administración de un ambiente productivo, dando así un gran valor para los usuarios de este software de IBM.

Recursos

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=WebSphere, SOA y servicios web
ArticleID=475931
ArticleTitle=WebSphere Virtual Enterprise
publish-date=01072011