Conceptos de Q-flow Enterprise Edition

Transcripción

1 Q-flow 2.2 Código de Manual: Qf22008ESP Versión del Manual: 1.1 Última revisión: 17/3/2006 Se aplica a: Q-flow 2.2 Enterprise Edition Conceptos de Q-flow Enterprise Edition

2 Qf22008ESP v1.1 Q-flow Conceptos de Q-flow Enterprise Edition Urudata Software Canelones 1370 Piso 2 CP11200 Montevideo, Uruguay Teléfono: (598 2) Fax: i

3 Qf22008ESP Conceptos de Q-flow Enterprise Edition v1.1 Tabla de Contenido Introducción...3 Qué es Q-flow Enterprise Edition?... 3 Configuración de las pruebas de performance... 5 Test de Escalabilidad... 6 Comparativos de tiempos del test de performance... 6 Test de estabilidad... 7 Escenarios de aplicación... 8 Especificación...9 Multiprocesamiento... 9 Clustering... 9 Monitoreo... 9 Granja de servidores para procesamiento de correo

4 Introducción En este documento se describen los elementos centrales de la versión Enterprise de Q-flow 2.2. Además, se analizan las principales diferencias entre esa versión y la versión estándar. Se describen las diferencias de prestaciones y los diferentes escenarios donde se recomienda el uso de la versión Enterprise. Por información relativa a los procedimientos administrativos de instalación y administración de la versión Enterprise, Consulte el manual Instalación y Configuración de Q-flow Enterprise Edition. Qué es Q-flow Enterprise Edition? La versión Enterprise de Q-flow fue desarrollada con el objetivo de proveer los más altos niveles de tolerancia a fallos y escalabilidad. En este contexto, la versión Enterprise provee una nueva versión de los motores de workflow y despachadores de correo, especialmente optimizados para aprovechar al máximo la capacidad de un hardware de altas prestaciones, implementando una arquitectura de tres niveles de aislamiento entre los hilos de trabajo y procesos que componen el motor de workflow. El primer objetivo de esta versión ha sido el dotar el motor de workflow de Q-flow de una mayor tolerancia a fallos y a comportamientos inadecuados en cuanto a consumo de recursos por parte de componentes y scripts incluidos en los templates. El nuevo modelo de tres niveles aísla en un nivel de ejecución los pasos no seguros (scripts, pasos de integración, documentos, datos y pasos definidos por el usuario), separándolos en tantas áreas o subprocesos de ejecución aislados como se especifique en la configuración. Así, se ejerce un control más estricto de los tiempos de ejecución de cada una de las áreas, realizando un reciclado total del área (garantizando la correcta liberación de todos los recursos que los scripts o componentes pudiesen no liberar correctamente). Las áreas o subprocesos de ejecución son asignadas bajo demanda por el agente de Runtime, el cual coordina, despacha, asigna trabajo y recicla los subprocesos de acuerdo a la carga de trabajo del sistema. El agente de Supervisión es un nuevo agente del motor de workflow de Q-flow. Se encarga de supervisar el trabajo de los distintos agentes del sistema. Controla, por medio de un heartbeat, el correcto funcionamiento de cada agente, disparando las alertas correspondientes y forzando un reciclaje del mismo (migración de un nodo a otro del cluster) en el caso de una mala respuesta del servicio o en el caso de que su cola de trabajo pendiente no esté siendo atendida de acuerdo al nivel de servicio especificado en la configuración del sistema. 3

5 Agente de Novedades Agente de Vencimientos Agente de Supervisor de 3er Nivel Agente de Runtime de 2do Nivel (Coordinación de Sub Procesos) Agentes de Mensajería Agentes de Mensajería Subproceso de ejecución de Pasos Críticos Worker Thread Subproceso de ejecución de Pasos Críticos Subproceso Worker de ejecución de Pasos Críticos Subproceso Worker Thread de ejecución de Pasos Críticos Worker Thread Thread El segundo objetivo de diseño de la versión Enterprise de Q-flow fue el de dotar el motor de workflow de una mayor capacidad de escalamiento que le permita aprovechar toda la potencia de un hardware de altas prestaciones (equipo multiprocesador y con adecuados recursos de memoria). Para esto se ha dividido el servicio de liberación de workflows en espera en dos agentes. Uno de ellos atiende las novedades recibidas en el sistema (pasos contestados y otras novedades recibidas). El otro atiende todo lo relativo a vencimientos (alertas, recordatorios, delegaciones, notificaciones programadas, inicios programados y diferidos y vencimientos de pasos en espera, etc). 4

6 Dicha división permite especializar los servicios de liberación de tareas en dos servicios: uno totalmente reactivo a las novedades y otro que mantiene y procesa la lista de vencimientos en forma especializada, reduciendo los impactos producidos en momentos de reprogramación masiva de vencimientos (tales como cambios en los calendarios o modificaciones en templates altamente utilizados). Por otro lado, el nuevo modelo de separación de procesos garantiza que los recursos utilizados por los scripts y componentes sea adecuadamente liberado. Esto garantiza que la performance del motor de workflow no se vea afectada por el consumo de estos recursos. El nuevo esquema de reserva y asignación de tareas se ha optimizado para que el motor de workflow pueda operar utilizando toda la capacidad disponible de recursos del servidor, utilizando un nuevo algoritmo de distribución de tareas que posibilita un mayor nivel de paralelismo sin interferencias entre los recursos que necesita reservar un paso para su ejecución. Finalmente, Q-flow Enterprise Edition incluye versiones Enterprise de los agentes de correo: agente Lotus Notes, agente MAPI2k y agente SMTP. Estos nuevos agentes permiten trabajar con granjas de servidores, dividiendo el trabajo de procesamiento de mensajes de correo entre esos servidores. El mecanismo está diseñado de forma tal que, si uno de los servidores de la granja deja de procesar mensajes, esos mensajes son procesados por otro servidor una vez transcurrido un cierto período de tiempo (timeout), que es configurable a través del parámetro de instalación FARMTIMEOUT, cuyo valor por defecto es de 300 sergundos. El manual dedicado a los parámetros de instalación explica en detalle cómo configurar este parámetro. Configuración de las pruebas de performance Las pruebas de performance se realizaron con la siguiente configuración: HP Proliant ML- 350 Dual Xeon 3.06 GHz, discos de 72GB de 10KRPM con controladora SA641, Ultra320 y 1GB de RAM HP Proliant ML- 370 Xeon 2.8 GHz, discos de 72GB de 10KRPM con controladora SA641, Ultra320 y 512MB de RAM Q-flow Engine Services Backbone de Gigabit Ethernet SQL Server 2000 Iniciador de Workflows Contestador de Pasos 5

7 Test de Escalabilidad El template básico utilizado para el test de carga incluyó dos pasos de scripts de alta carga de procesamiento (ambos incluyen un bucle donde se creaba, cargaba y destruía un documento XML). En el segundo script se agregó la carga desde disco de un documento XML de 200 KB. También en el proceso se incluyeron dos preguntas, dos evaluaciones, una notificación y el adjuntado de un documento de 4MB mediante un paso de documentos. Comparativos de tiempos del test de performance La siguiente tabla compara los tiempos insumidos para completar el procesamiento de las cantidades de workflows expresadas en la primera columna. Todos estos workflows se basan en el mismo template y todos siguen el mismo camino (camino largo, procesando los diez pasos contenidos en el hilo central del template). La columna Configuración Enterprise indica la cantidad de áreas o subprocesos admitidos como máximo en esa prueba (el agente de ejecución de Q-flow determina cuántos subprocesos debe crear para atender correctamente la carga de trabajo existente, respetando el máximo configurado). 6

8 El segundo número de la columna indica la cantidad de workflows que se asignarán por ciclo de procesamiento a cada área (también como máximo, pudiendo el despachador del agente de ejecución asignar menos tareas a cada área). Cant. de Configuración Tiempo Total de Proceso Workflows Enterprise Ent. Edit Std % Dif x , , ,09% x , , ,38% x , , ,57% x , , ,06% x , , ,87% Comparación de Performance Tiempo de proceso en segundos (10x10) 1000 (4x25) 1000 (10x10) 1000 (20x25) 1000 (10x25) Standard Enterprise Test de estabilidad En el test de estabilidad se utilizó un template muy sencillo que constaba de un paso de inicio, uno de script y uno de finalización. En el paso de script se utilizó un bucle de 700 iteraciones donde se creaba un documento XML y no se realizaba la destrucción explícita del objeto, dejando esta tarea al entorno del motor de workflow. El resultado arrojado es que la versión estándar procesó el requerimiento de 500 workflows en 2 39,970 y la versión Enterprise realizó el procesamiento en 0 54,570 segundos. Aquí, la gran diferencia de procesamiento (293%) es debido a la estabilidad en la liberación de recursos de sistema que logra la versión Enterprise con respecto a la estándar. 7

9 En la siguiente gráfica se muestra el consumo de CPU de la versión estándar y de la enterprise durante la prueba. Como se puede ver, la versión Enterprise utilizó casi la totalidad de los recursos de procesamiento del servidor y culminó la tarea sin inconvenientes, mientras que la versión estándar se vio frenada por la liberación de los recursos, demorando casi tres veces más que la Enterprise para completar el procesamiento de los 500 workflows. Escenarios de aplicación Los escenarios típicos para el uso de la versión Enterprise son aquellos donde existe una importante necesidad de procesamiento y/o una necesidad de un sistema disponible 7x24. La mayor capacidad del sistema para aprovechar el hardware de mayor porte y la capacidad de mantener las prestaciones del sistema en entornos que hoy se presentan inestables para la versión estándar (debido a scripts puestos en producción con defectos en la codificación o al uso de componentes inestables, o debido a la comunicación con otros sistemas que no tienen una alta disponibilidad). En resumen, los escenarios típicos de aplicación son: - Implementaciones que necesitan una disponibilidad 7x24, implementada en un Cluster de Windows. - Instalaciones donde la versión estándar se presenta hoy con algunas inestabilidades. - Entornos donde se utilizan muchos scripts o componentes importados dentro del propio motor de workflow. - Instalaciones donde se desee maximizar la performance, utilizando escalamiento vertical (equipos de dos o cuatro procesadores). 8

10 Especificación Los principales atributos que se ven afectados y mejorados mediante el uso del motor Enterprise Edition son: Multiprocesamiento Se ha mejorado fuertemente la capacidad de multiprocesamiento del motor de workflow, logrando un óptimo aprovechamiento de los recursos de un sistema multiprocesador real (no hiperthreading). La ejecución de las tareas se hace mediante un pool de procesos que permiten la ejecución de los threads activos en cada workflow, distribuyéndose las tareas entre estos subprocesos de acuerdo a la carga del sistema. El sistema regula el pool de subprocesos en uso de acuerdo a la carga de trabajo existente. Este nuevo nivel de aislamiento nos brinda mayor capacidad de tolerancia a fallos y permite evitar de forma más sólida que un error en un script afecte otros workflows o la performance general del sistema. El modelo de limpieza de entorno de dos niveles permite la liberación totalmente segura de los componentes que sean utilizados en scripts o en integraciones y que no realicen una adecuada limpieza o liberación de los recursos que solicitan al sistema. El tamaño del pool de procesos que pueden activarse simultáneamente, tanto como la cantidad de tareas asignadas en concurrencia a cada uno, es configurable y puede ajustarse para cada instalación en particular. Clustering Se brinda la posibilidad de clusterizar los servicios en Windows. Se recomienda utilizar Clusters sobre Windows 2003 con una configuración Activo/Pasivo para cada servicio en cada nodo (en general Activo/Activo), permitiendo el manejo de múltiples nodos para brindar tolerancia a fallos y asegurar la disponibilidad de la aplicación servicio pro servicio. La separación del servicio de liberación de tareas y alertas en dos servicios permite asignar con mucha mayor granularidad los servicios de Q-flow a uno u otro nodo del cluster. Esto permite que los servicios con mayor carga se ejecuten en distintos nodos. Monitoreo Se agrega un nuevo servicio que monitorea el resto de los servicios (Watch Dog), Esto permite detectar la falta de servicios vinculada a alguno de ellos. La detección de alguna falla en uno de los servicios provoca el inicio automático de la migración del grupo a nivel del cluster. Este servicio monitorea tanto la estabilidad como la actividad real de cada servicio, controlando las colas de trabajo de cada uno a nivel de la instalación de Q-flow. 9

11 Granja de servidores para procesamiento de correo Las versiones Enterprise de los agentes de procesamiento de correo pueden ser utilizadas en una granja de servidores. Las tareas son divididas entre los diversos servidores y un servidor adopta las tareas de otro en caso de que este último interrumpa el procesamiento. Este proceso es acumulativo y transitivo, por lo cual en caso de que la caída de uno o más servidores provoque una sobrecarga en el servidor hermano en la lista de servidores, los demás servidores asumirán parte del trabajo del primer servidor, en caso de que el suplente no pueda sacar todo el trabajo propio más el asumido en tiempo y forma. El siguiente cuadro presenta las diferentes opciones de respaldo que se activarán ante la falla de cualquiera de los servidores de la granja. Configuración de Q-flow enterprise con Granja de Servidores de Correo Q-flow Backend Runtime & Alert Agents Cluster Granja de Servidores WEB Database Web Server 1 Web Server 2 Web Server 3 Mail Server 3 Mail Server 1 Con 1 Timeout de 5 minutos, si este servidor falla o acumula trabajo por mas de 5 minutos el Server 2 comenzará a realizar a realizar los envíos que tenía asignados y a los 10 minutos el Server 3 comenzará a procesar trabajo de este servidor Mail Server 2 Con 1 Timeout de 5 minutos, si este servidor falla o acumula trabajo por mas de 5 minutos el Server 1 comenzará a realizar a realizar los envíos que tenía asignados y a los 10 minutos el Server 2 comenzará a procesar trabajo de este servidor Con 1 Timeout de 5 minutos, si este servidor falla o acumula trabajo por mas de 5 minutos el Server 3 comenzará a realizar a realizar los envíos que tenía asignados y a los 10 minutos el Server 1 comenzará a procesar trabajo de este servidor 10