ES2351604T3 - Procedimiento para gestionar recursos en una plataforma para gestión de servicios y/o redes de telecomunicación, plataforma correspondiente y producto de programa informático asociado. - Google Patents

Abstract

Un procedimiento para gestionar recursos en una plataforma para servicios y/o redes de telecomunicaciones, incluyendo el procedimiento ejecutar agentes

Description

CAMPO DE LA INVENCIÓN [0001] La presente invención se refiere a un procedimiento para gestionar recursos en una plataforma dirigida a gestionar redes y/o servicios de telecomunicación. En particular, la invención concierne a un procedimiento para asignar recursos en plataformas para gestión de redes y/o servicios de telecomunicaciones y una plataforma de gestión correspondiente.

ANTECEDENTES DE LA INVENCIÓN [0002] En el campo de las redes/servicios de comunicación, están provistas plataformas de gestión que incluyen una pluralidad de componentes como sistemas de soporte de operaciones (OSS) organizados en arquitecturas jerárquicas, a veces basados en agentes. [0003] El documento US6243396 desvela, por ejemplo, un sistema o plataforma de gestión de redes de comunicación que tiene una arquitectura jerárquica multicapa de autoridades de gestión interconectadas que controlan los recursos de la red de telecomunicación. Cada autoridad tiene un número de agentes responsables de la ejecución de procedimientos, que pueden ser agentes inteligentes o simplemente reactivos. En la arquitectura conocida, los agentes reactivos están ubicados dentro de una parte de plataforma de la autoridad y los agentes inteligentes están ubicados dentro de una parte controladora de la autoridad. Los agentes inteligentes y reactivos están agrupados en componentes funcionales para proporcionar funcionalidades FCAPS (Fallos, Configuración, Contabilidad, Rendimiento, Seguridad) a la plataforma. [0004] El documento WO01/02973 enseña el uso de una plataforma que comprende un coordinador de procesos centralizado para coordinación de agentes distribuidos, realizada típicamente con un motor de flujo de trabajo que ejecuta descripciones de flujo de trabajo (similares a organigramas) que comprenden delegación de trabajos a componentes (los agentes), recopilación de respuestas procedentes de los agentes, etcétera. [0005] El solicitante cree que las arquitecturas anteriores no aseguran que los agentes ejecuten trabajos delegados por el motor de flujo de trabajo. De hecho, los recursos informáticos disponibles para los agentes, como la potencia de computación, son limitados y no se supone que los recursos informáticos sean suficientes para adaptarse a los objetivos de negocio o la carga de trabajo solicitada a la plataforma.

En otras palabras, los recursos informáticos a disposición de los agentes pueden impedir alcanzar objetivos de negocio predeterminados que requieren que se realicen tareas, como por ejemplo el suministro de un servicio a un cliente, por los agentes. [0006] Por ejemplo, una tarea puede ser la finalización de un proceso determinado en un tiempo medio más corto que una duración de tiempo predefinida, o la finalización de un número determinado de procesos dentro de un plazo fijo. La enorme carga de trabajo sobre un agente puede impedir que el agente finalice la tarea en un tiempo medio predefinido o dentro del plazo fijo, haciendo, por lo tanto, que no se alcance el objetivo de negocio. [0007] Otro problema de la arquitectura basada en agentes que usa un coordinador de procesos centralizado, como la desvelada en el documento WO01/02973, es que el propio coordinador se convierte en un cuello de botella en el funcionamiento de la plataforma, y cuanto más lógica de proceso se externaliza de los agentes añadiendo flujos de trabajo al coordinador para mejorar la flexibilidad, más lento se vuelve el coordinador. Eso puede empeorar la capacidad de la arquitectura de hacer frente a los objetivos de rendimiento del negocio, como procesos con plazos para su ejecución. [0008] En el campo de la gestión de recursos informáticos, la solicitud de patente de EE.UU. nº 2003/0167270 desvela un sistema de gestión de recursos en un entorno distribuido compuesto por anfitriones que instancian copias de una aplicación escalable. El sistema de gestión de recursos genera señales para arrancar, parar o mover copias seleccionadas de una aplicación escalable a través de los anfitriones, basándose en información sobre copias de la aplicación y rendimiento del anfitrión. [0009] Esta clase de solución no es muy adecuada para una plataforma que comprende una arquitectura de agentes distribuidos coordinados por un coordinador de procesos o motor de flujo de trabajo por al menos las siguientes razones:

imagen1 en caso de que todos los agentes ya estén ejecutando algunas tareas puede que no haya agentes libres para una nueva ejecución de una tarea

o aplicación urgente;

imagen1 cada vez que se define un nuevo flujo de trabajo (es decir, una nueva funcionalidad), para cumplir los objetivos de negocio (por ejemplo, directrices sobre procesos de negocio), el sistema conocido tiene que medir parámetros sobre las aplicaciones y construir un nuevo modelo para ajustar el comportamiento de todos los agentes;

imagen1 el sistema de gestión de recursos conocido sólo funciona para las aplicaciones o funcionalidades que pueden ser instanciadas en múltiples

copias. [0010] El documento US2003/0036886 desvela un motor de monitorización y control para gestión de nivel de servicio multicapa de servidores de aplicaciones web distribuidos. El sitio web proporciona servicios a usuarios a través de Internet. Los objetivos de nivel de servicios del usuario final (SLOs) como la disponibilidad y rendimiento se miden y se informa de ellos a un agente SLO. El usuario solicita pasar por varias capas en el sitio web, como una capa de cortafuego, una capa de servidor web, una capa de servidor de aplicaciones, y una capa de servidor de base de datos. Cada capa tiene varios componentes de servicios redundantes que pueden procesar solicitudes para esa capa. Los agentes locales, operando con cualquier gestor de recursos local, monitorizan los componentes de servicios en ejecución e informan a un agente de servicio. Los monitores de nodos también monitorizan el estado de los nodos de la red e informan al agente de servicio. Cuando un componente de nodo o servicio falla, el agente de servicio intenta reiniciarlo usando el agente local, o replica el componente de servicio a otros nodos. Cuando el agente SLO determina que no se está cumpliendo un SLO, ordena al agente de servicio que replique más componentes de servicio limitadores o aumente los recursos. [0011] El documento US2003/0233391 desvela un procedimiento y sistema para asignar recursos informáticos. El procedimiento puede implementarse en instrucciones de software en un asignador de recursos que asigna recursos entre cargas de trabajo que operan en el sistema. Los parámetros que definen los objetivos de nivel de servicio para la ejecución de cargas de trabajo se reciben desde un dispositivo de entrada del usuario. Al menos uno de los objetivos de nivel de servicio es un tope de utilización que limita la asignación global de recursos del sistema entre las cargas de trabajo. Los parámetros incluyen prioridades para los objetivos de nivel de servicio, incluyendo el tope de utilización. Como las cargas de trabajo se ejecutan en el sistema, se reciben datos de utilización que indican el uso de recursos del sistema. Los recursos se asignan a las cargas de trabajo según las prioridades de los objetivos de nivel de servicio y basándose en los datos de utilización. RESUMEN DE LA INVENCIÓN [0012] El objeto de la presente invención es, por lo tanto, proporcionar un procedimiento para gestionar recursos de una plataforma basada en agentes para gestionar servicios y/o redes de telecomunicaciones, que mejore la eficiencia de la plataforma logrando el rendimiento óptimo en la utilización de recursos para satisfacer objetivos de negocio predeterminados.

[0013] Otro objeto de la invención es una plataforma de gestión que tenga una lógica de proceso descentralizada para lograr mejores rendimientos de la plataforma en tanto que mejorando su flexibilidad. [0014] Según la presente invención, estos objetos se logran por medio de un procedimiento para gestionar recursos en una plataforma para gestionar servicios y/o redes de telecomunicaciones así como por la plataforma de gestión que tiene las características a las que se hace referencia en las reivindicaciones independientes. [0015] Más objetos de la invención son un producto de programa informático o conjunto de programas informáticos, una red de telecomunicaciones y un procedimiento para la configuración y funcionamiento de una plataforma de gestión de telecomunicaciones tal como se reivindica. [0016] En resumen, para superar los inconvenientes de la técnica anterior, la invención desvela un procedimiento y una plataforma correspondiente basados en un mecanismo predictivo y adaptativo impulsado por indicadores (por ejemplo, indicadores de clave de negocio) y objetivos predeterminados, que proporcionan la medición y control automático de utilización de recursos informáticos en una plataforma de gestión. [0017] Preferentemente, las características arquitectónicas de la plataforma según la invención son: -la provisión de motores de proceso (flujo de trabajo y reglas) dentro de agentes para implementar todas las funcionalidades proporcionadas por ellos, de manera que los trabajos que los agentes tienen que ejecutar se convierten en ejecuciones de flujo de trabajo. Los motores de reglas pueden estar asociados a motores de flujo de trabajo para realizar ciertos tipos de trabajos. -la provisión de una base de datos de descripciones de procesos centralizada para la definición y almacenamiento de descripciones de procesos, y para distribuir estas descripciones a los agentes. -la provisión de una Consola de objetivo y limitaciones, que permite la especificación de unos datos objetivo que incluyen objetivos de negocio (por ejemplo, SLA, acuerdos de nivel de servicio) y prioridades de procesos basándose en la definición de funcionalidades y sus agregaciones (por ejemplo, dentro de áreas de procesos de negocio como cumplimiento, garantía, facturación); -la provisión de agentes de control dispuestos para monitorizar el uso de recursos informáticos por cada ejecución de proceso en cada agente de la plataforma, así como la ejecución de flujos de trabajo por los procesos de negocio, es decir, por ejemplo, para monitorizar el tiempo transcurrido, la frecuencia de ejecución, etcétera; y -la provisión de un módulo de asignación de recursos para reasignar recursos informáticos a cada agente de la plataforma de una manera adaptable basándose en datos objetivo especificados (objetivos de negocio) y datos de rendimiento monitorizados representativos de la utilización de recursos, para proporcionar el máximo nivel de logro de objetivos de negocio. [0018] Ventajosamente, según una realización preferida de la presente invención, se proporciona una consola de reasignación como una interfaz gráfica de usuario para definir reglas de reasignación de recursos, y se proporciona una consola de monitorización, que permite controlar tendencias de cumplimiento de SLA y utilización de recursos informáticos correspondientes y costes relacionados. [0019] La provisión de motores de proceso dentro de los agentes demuestra ser una característica ventajosa para la asignación dinámica de recursos informáticos entre agentes, mejorando la flexibilidad sin introducir cuellos de botella, lo cual es el caso cuando todos los motores se colocan en un coordinador de procesos centralizado. Los motores de proceso dentro de agentes permiten medir la utilización de recursos en los agentes analíticamente (por ejemplo, el tiempo de la CPU o la RAM usada) para cada ejecución de funcionalidad (es decir, ejecución de proceso). [0020] Las descripciones de procesos en la base de datos centralizada se distribuyen a través de la plataforma a cada agente para uso dentro de sus propios motores, logrando la sincronización automática con todas las funcionalidades operativas de la plataforma, de manera que es posible ajustar los procedimientos de gestión de recursos que funcionan con la semántica de los trabajos. [0021] En la práctica, un administrador de la plataforma para gestionar servicios y redes de telecomunicaciones puede construir cualquier funcionalidad FCAPS (Fallo, Configuración, Contabilidad, Rendimiento, Seguridad) definiendo en la base de datos de procesos uno o más flujos de trabajo y/o reglas o combinando los existentes; luego los agentes adquieren automáticamente las nuevas definiciones de procesos (flujo de trabajo y reglas) y las ejecutan cuando sea necesario. Automáticamente, la Consola de objetivo permite definir el SLA y la prioridad sobre nuevos procesos. En el momento de la ejecución, los Agentes de control permiten controlar las tendencias de SLA y la utilización de recursos informáticos correspondientes para los nuevos procesos de manera que el Módulo de reasignación puede optimizar la configuración global, es decir, cambiar las prioridades de flujos de trabajo en un agente o suministrarle más recursos computacionales (CPU, memoria, etc...).

[0022] La gestión de recursos según la presente invención se implementa preferentemente en la plataforma mediante un módulo centralizado (un Módulo gestor) junto con módulos distribuidos (Agentes de control). La combinación de funcionalidades centralizadas y distribuidas es la base del mecanismo adaptativo de la solución.

BREVE DESCRIPCIÓN DE LOS DIBUJOS [0023] Características y ventajas adicionales de la invención se explicarán con más detalle en la siguiente descripción, proporcionada a modo de ejemplo no limitador con referencia a los dibujos adjuntos, en los que:

La figura 1 es un diagrama de bloques que muestra la arquitectura de un sistema o plataforma para gestionar redes y servicios de telecomunicaciones según la invención; la figura 2 es un diagrama de bloques que muestra la estructura interna del Módulo gestor de la figura 1; la figura 3 es un diagrama de bloques que muestra la estructura interna de una máquina anfitriona de la figura 1, con Módulos agentes y Agente de control; la figura 4 es un diagrama de bloques que muestra la estructura interna de Módulos agentes según una realización alternativa; la figura 5 es un organigrama del procedimiento de gestión de recursos según la invención; la figura 6 es un diagrama esquemático de un escenario de provisión de servicios de tres capas que implica el sistema según la invención; y la figura 7 es un diagrama que muestra flujos de trabajo multinivel en el escenario de provisión de servicios de la figura 6.

DESCRIPCIÓN DETALLADA DE UNA REALIZACIÓN PREFERIDA [0024] La figura 1 representa una arquitectura ejemplar de un sistema para gestionar servicios y redes de telecomunicaciones según la invención. El sistema se implementa preferentemente en una arquitectura de procesamiento distribuida que comprende una pluralidad de máquinas anfitrionas de procesamiento H, cada una de las cuales puede incluir uno o más agentes de software (A1, A2, A3). [0025] El sistema (o plataforma) comprende un módulo de control centralizado o Módulo gestor MM que incluye un programa o conjunto de programas que se ejecutan en una máquina anfitriona y que interactúan con agentes distribuidos para diversas acciones de coordinación, como distribución de descripciones de procesos, invocación de operaciones, controles administrativos, etc. El Módulo gestor MM también puede incluir preferentemente una interfaz gráfica de usuario para interacción con un usuario como un administrador de sistemas. [0026] En esta memoria descriptiva, el término proceso se usa para representar uno o más flujos de trabajo, una o más reglas o, preferentemente, una combinación de uno o más flujos de trabajo y una o más reglas. El flujo de trabajo puede definirse como la automatización de un procedimiento de negocio durante el cual se pasan información o tareas de un agente a otro para acción, según un conjunto de reglas de procedimiento. El flujo de trabajo puede representarse a través de un organigrama con una secuencia de tareas así como dependencias temporales y lógicas entre tareas incluyendo ramas alternativas o paralelas. Existen lenguajes ad hoc como XPDL (Lenguaje de descripción de procesos XML) para formalizar descripciones de flujos de trabajo. Las reglas son declaraciones de qué acciones tienen que ejecutarse cuando se produce un conjunto específico de condiciones/eventos. [0027] El módulo gestor MM comprende una base de datos de descripción de procesos PDB, que se dispone para almacenar todos los procesos, es decir, flujos de trabajo y reglas, que representan los aspectos de comportamiento y funcionales de la plataforma. [0028] La base de datos PDB además comprende, por ejemplo, modelos de datos manejados por flujos de trabajo y reglas. La base de datos de descripción de procesos PDB puede estar asociada, por ejemplo, con la parte de catálogo de cualquier sistema de inventario de red convencional tal como conoce cualquier persona experta en la materia. [0029] La arquitectura de la figura 1 incluye una pluralidad de Módulos agentes multicapa, habiéndose mostrado tres capas a modo de ejemplo que incluyen algunos agentes A1, A2, A3 respectivamente. Los agentes que pertenecen al mismo nivel pueden estar conectados entre sí o pueden ser independientes entre sí. Están asociados a un agente de nivel superior, si lo hay. En el nivel inferior un agente está asociado a un elemento de red bajo control (mostrado en general como la red de comunicación N), por ejemplo a un conmutador ATM, o a otras aplicaciones de servicio APP, como aplicaciones de servidor de correo o aplicaciones de servidor VAS, es decir, aplicaciones de servicios de valor añadido como servicios de contestador de teléfonos móviles. [0030] El propio módulo gestor MM está conectado, por ejemplo, a través de un bus de comunicación B a otros sistemas de soporte de operaciones OSS de la plataforma. [0031] Un agente maestro MA o, dependiendo del tipo de implementación, una pluralidad de agentes maestros MA (no desvelados en la figura 1), que actúan como coordinadores están provistos en la raíz de la arquitectura de agentes multicapa, asociados al módulo gestor MM. [0032] Cada agente A1, A2, A3 incluye un motor de procesos PE y es responsable de la ejecución de algunos procesos usando el motor de procesos PE. El motor de procesos es el módulo de software que ejecuta flujos de trabajo y/o reglas. [0033] Los motores de procesos PE están incluidos ventajosamente dentro de cada agente ya que una ubicación externa del motor de proceso significaría tener invocaciones remotas que pueden causar degradaciones de rendimiento. Preferentemente, los procesos de cada agente pueden ser invocados externamente por otros agentes que tienen el mismo nivel o un nivel superior, y corresponden a los servicios que cada agente ofrece a los agentes invocadores. [0034] Los motores de proceso para cualquier capa están pensados para ser una combinación, por ejemplo, de un motor de flujo de trabajo y un motor de reglas capaces de gestionar, respectivamente, flujos de trabajo y reglas. Por ejemplo, un proceso de provisión se representa mejor como un flujo de trabajo, mientras que una correlación de alarma podría representarse mejor como una combinación de reglas. Cuando sea posible, se prefiere el uso de flujos de trabajo porque no implica la complejidad de ocuparse de conflictos de reglas y gestión de reglas. [0035] La arquitectura multicapa mostrada en la figura 1 permite la segmentación de un proceso en diferentes niveles. No existen limitaciones sobre el número de niveles en los que pueden disponerse los agentes. De esta manera es posible configurar la arquitectura para encontrar el compromiso entre tener el número más bajo posible de capas y permitir la libre asignación de procesos entre una organización distribuida y una centralizada. Esta segmentación también permite proporcionar diferentes visiones de servicio, desde una visión de negocio hasta una visión de sistema. En lo que viene a continuación, los motores de flujo de trabajo se consideran preferidos, pero también son aplicables motores de reglas. [0036] Cada máquina anfitriona que ejecuta agentes (tanto el agente maestro como agentes de subnivel) incluye preferentemente uno o más Agentes de control CA. Son módulos responsables de medir la utilización de recursos y el rendimiento de los agentes locales (es decir, agentes que se ejecutan en ese anfitrión) así como realizar optimización local de gestión de recursos. Los Agentes de control CA están asociados al Módulo gestor y a otros Agentes de control y envían los datos medidos al Módulo gestor y/u otros Agentes de control. [0037] El módulo gestor MM, del que más tarde se describirá la estructura, es responsable de la administración, configuración y control de la plataforma. Se dispone para analizar los datos entrantes procedentes de operadores humanos y procedentes de OSSs externos y decidir cómo ajustar la configuración de la plataforma para cumplir los objetivos de rendimiento del negocio. Sus principales tareas son las siguientes:

distribuir descripciones de procesos y modelos de datos procedentes de la base

de datos de procesos (PDB) a los agentes;

monitorización del estado de la plataforma con información proporcionada por

los Agentes de control, incluida la distribución de agentes en máquinas

anfitrionas, gestión de dominios (reparto de toda la red entre los agentes),

monitorización de rendimiento;

ejecución de acciones para uso óptimo de los recursos asignados para la

ejecución de procesos por agentes a través de la interacción con Agentes de

control relacionados; ejemplo de estas acciones son la modificación del

balanceo de carga entre agentes y los cambios en las prioridades de los flujos

de trabajo, es decir, reprogramar la puesta en cola de trabajos en uno o más

agentes;

interacciones con sistemas externos, como otros Sistemas de soporte de

operaciones. [0038] El agente maestro MA, del que más tarde se describirá la estructura, es responsable de la coordinación de nivel superior de la ejecución de procesos. En realidad, los procesos encomendados al agente de la capa superior pueden implicar subprocesos encomendados a agentes de subcapas. Además, existen procesos caracterizados para proporcionar funcionalidades que requieren interacción con entidades externas (aparte de agentes) o coordinación entre agentes que no pueden ser realizadas fácil o eficazmente de manera distribuida por los agentes de capas inferiores. Los procesos que han de ser ejecutados por un agente son aquellos que deben ser ejecutados de manera distribuida. [0039] Cada agente (A1, A2, A3) puede soportar cualquier funcionalidad (es decir, proceso) de gestión de redes y servicios, como cualquier funcionalidad FCAPS (Fallo, Configuración, Contabilidad, Rendimiento, Seguridad). Esto permite la personalización de tareas de tiempo de ejecución de agentes y la reasignación de funcionalidad en agentes basándose en la prioridad de tareas y las necesidades de recursos como, por ejemplo, dedicar más agentes durante el día a provisión de servicios y más agentes durante la noche para optimización de red. [0040] La provisión de motores de proceso PE en agentes permite monitorizar la utilización de recursos por cada ejecución de funcionalidad (es decir, proceso) así como las presencias de invocaciones de funcionalidad. Estos datos son la fuente primaria de información para control automático de la plataforma operado por el módulo gestor MM. [0041] Cada agente (A1, A2, A3) muestra un comportamiento tanto reactivo como proactivo, activándose en eventos pero dando también el comienzo espontáneo a procesos. [0042] Preferentemente, un módulo agente es móvil, mediante un Agente de control o el Módulo gestor, a través de máquinas de procesamiento para un despliegue más fácil, por ejemplo para cumplimiento de cuestiones de tolerancia a fallos. La figura 2 muestra la estructura interna del módulo gestor MM según la realización preferida de la invención. [0043] El módulo gestor centralizado MM está organizado, por ejemplo, en submódulos. Uno de los submódulos es la consola MNG_CNS, indicada en general como Consola de gestión MNG_CNS; la Consola de gestión MNG_CNS, en la realización preferida, incluye:

• una Consola de monitorización MC que tiene asociada una Base de datos de rendimiento PFM_DB que contiene datos de rendimiento de la plataforma;

•

una Consola de objetivo y limitaciones GC;

•

una Consola de reasignación RC;

•

una Consola administrativa AC que tiene asociada una Base de datos

administrativos ADB que comprende datos administrativos gestionados por la Consola administrativa; y • una Consola de entorno de creación de servicio SCC,

para • un Módulo de planificación de capacidad (no mostrado); y • una Consola de previsión (no mostrada).

[0044] La Consola de objetivo GC, la Consola administrativa AC y la Consola de creación de servicio SCC están todas asociadas a la base de datos de descripción de procesos PDB.

[0045] El módulo gestor MM comprende un Asignador de recursos RA directamente asociado a la Consola de objetivo y limitaciones GC y a la Consola de reasignación RC. El Asignador de recursos RA también está asociado, por ejemplo, a la Base de datos administrativos ADB, así como a la Base de datos de rendimiento PFM_DB que contiene datos de rendimiento de la plataforma. El módulo gestor MM además comprende, en la realización preferida, un Módulo de adquisición de datos de monitorización MDM y un controlador de plataforma PC. El Módulo de adquisición de datos de monitorización MDM se dispone para transferir datos de rendimiento del controlador de plataforma PC a la Base de datos de rendimiento PFM_DB. Además, el Asignador de recursos, por ejemplo, puede estar asociado a un módulo de interfaz externo I para monitorizar las interacciones entre OSSs externos y la plataforma de gestión. [0046] El controlador de plataforma PC funciona, en general, como mediador entre el módulo gestor y los agentes. En particular, el controlador de plataforma PC implementa la conexión con el Agente maestro MA (no mostrado) externo al Módulo gestor y con el Módulo de asignación de recursos RA y está asociado con la Consola de monitorización MC, el Módulo de adquisición de datos de monitorización MDM, la Consola administrativa AC y la Base de datos administrativos ADB, así como con la Base de datos de descripción de procesos PDB. [0047] La Consola de objetivo y limitaciones GC está pensada para la definición de objetivos de negocio (por ejemplo, Acuerdos de nivel de servicio o SLA) y limitaciones, denominados conjuntamente como datos objetivo, asociados a procesos almacenados en la base de datos de descripción de procesos PDB. [0048] Los Acuerdos de nivel de servicio o SLAs son una cuantificación (contractual o simplemente acordada) de la calidad del nivel de proceso de negocio. Los SLAs están basados en indicadores de rendimiento (tiempo medio de ejecución, percentiles, u otros) y declaran los valores para estos indicadores que han de ser garantizados en la plataforma. Generalmente, un SLA puede describirse a través de un lenguaje específico (una “gramática”) que identifica un objetivo de SLA (un indicador de rendimiento) y una cláusula de penalización de SLA (una función de coste de SLA basada en la comparación entre el objetivo de SLA y los datos de rendimiento recopilados), por ejemplo, una estimación de penalización económica de violación de SLA.

Un SLA puede estar asociado a un proceso de negocio general (por ejemplo, un flujo de trabajo) o a una de sus especializaciones (identificable en uno o más atributos de flujo de trabajo), en el que el SLA para especializaciones típicamente sobrescribe los de procesos del negocio raíz, si los hay. [0049] Las limitaciones conciernen a datos acerca de la utilización de recursos. Incluyen preferentemente:

• recursos preasignados expresados en cuanto a la capacidad de procesamiento mínima que ha de garantizarse, el número mínimo de elementos de red gestionables (se prefiere usar el término “capacidad de procesamiento” en lugar del porcentaje de utilización, para usar una métrica de negocios más comprensible);

• número máximo de recursos asignables (expresado en coste o en porcentaje de los recursos globales; por ejemplo, un valor por defecto podría ser el 50%).

Si se modifica una limitación de negocio, es necesaria una comprobación para verificar si los recursos preasignados rebasan la potencia máxima asignable o no. [0050] El Asignador de recursos RA (en lo sucesivo, Reasignador) según una realización preferida de la presente invención, está centralizado y gestiona la asignación de recursos a agentes para controlar adaptativamente la plataforma. Se dispone para recibir, por ejemplo: [0051] El Reasignador RA comprende preferentemente dos submódulos: un Módulo de evaluación y un Módulo de decisión, cuya descripción ejemplar y funcionalidades se ofrecen a continuación de la memoria descriptiva. El Módulo de evaluación se dispone para recibir datos acerca de

i.

objetivos de negocio procedentes de la Consola de objetivo GC;

ii.

datos de rendimiento monitorizados (como el tiempo de ejecución) y

utilización

de recursos de hardware de cada máquina anfitriona,

adquiriendo estos datos de la Base de datos de rendimiento PFM_DB;

iii.

opcionalmente, información procedente de pruebas de carga, es decir,

medidas

acerca de la utilización de recursos para utilización más

intensa de flujos de trabajo;

iv.

datos acerca de máquina anfitriona disponibles y sus características de

hardware (velocidad normalizada de la CPU, por ejemplo usando el

índice

SPECINT2000 de la Corporación de Evaluación de

Rendimiento

Estándar; esto es para monitorizar la potencia de

procesamiento global (medida, por ejemplo, en segundos por hora de

una CPU de referencia);

v.

utilización de recursos de hardware de cada máquina anfitriona

(procedente de la Base de datos de rendimiento PFM_DB).

• solicitudes de ejecución de flujo de trabajo de nivel superior (MA), y

• colas de solicitudes de ejecución de flujo de trabajo en todos los agentes. Además, el Módulo de evaluación se dispone para analizar la tendencia histórica de solicitudes pasadas de ejecución de flujo de trabajo y las tendencias de la red de comunicación gestionada en cuanto a elementos y complejidad. [0052] El Módulo de decisión se dispone para decidir, basándose en la información previa, si la plataforma puede manejar todas las solicitudes según algunos criterios como se especificará más tarde. Si la plataforma no puede gestionar todas las solicitudes, el Módulo de decisión se dispone, por ejemplo, para enviar un mensaje de advertencia y decidir qué acción puede mejorar la situación. En particular, si los recursos son suficientes, pero no pueden cumplirse completamente los SLAs, el Módulo de decisión se dispone para redistribuir el procesamiento (es decir, la ejecución de flujo de trabajo) a través de la plataforma. Preferentemente, estas acciones se encargan de las limitaciones y las prioridades asociadas a las diferentes instancias de flujos de trabajo. [0053] La Consola administrativa AC está pensada para definir y monitorizar, por ejemplo, al menos un conjunto de lo siguiente:

i. la configuración de hardware de la plataforma, es decir, de los anfitriones H que tienen capacidades de procesamiento para ejecución de procesos por agentes distribuidos; por ejemplo, cuando se añade una nueva máquina anfitriona a un grupo predefinido de anfitriones, se une automáticamente a toda la plataforma, por ejemplo porque el anfitrión notifica su existencia o, alternativamente, la Consola administrativa reconoce el anfitrión H recibiendo comandos introducidos por un operador, por ejemplo a través de su GUI;

ii. la GUI para definición de distribución/asignación de software (es decir, la interfaz para recibir daros concernientes a las limitaciones en la Consola de Objetivo y limitaciones GC). Específicamente, se usa, por ejemplo, para establecer grupos de máquinas anfitrionas basándose en:

− Limitaciones geográficas (por ejemplo, ciertos flujos de trabajo podrían ejecutarse sólo en agentes instalados en una región y no en otra,

o podrían ejecutarse sólo en máquinas anfitrionas particulares); − Limitaciones jerárquicas (por ejemplo, en máquinas particular sólo pueden ejecutarse flujos de trabajo de segundo nivel);

− Limitaciones de servicio (es decir, limitaciones sobre tipos de procesos específicos);

iii. los Programas de flujo de trabajo (por ejemplo, un flujo de trabajo de provisión de servicio está programado sólo en horas matinales). [0054] La Consola de reasignación RC se dispone para definición de políticas de reasignación de recursos, es decir, la instrucción de cuándo y cómo reasignar recursos para optimizar la satisfacción del objetivo de negocio basándose en limitaciones de negocio y datos monitorizados. La Consola de reasignación permite introducir políticas tanto para control centralizado como distribuido. En particular, permite la definición de:

i. reglas para el control centralizado, que definen cuándo y cómo actuar sobre las prioridades de los flujos de trabajo para alcanzar el mejor nivel posible de satisfacción de SLA; estas reglas consideran a la plataforma gestionada en su totalidad (es decir, no realizan acciones directas en las máquinas) y funcionan basándose en todos los datos de entrada del Módulo de asignación de recursos y datos predictivos;

ii. reglas para el control distribuido, que actúan sobre agentes individuales a través de CA relacionados (paralelismo de hilos de ejecución y balanceo de carga) con el propósito de optimizar el uso de software local y recursos de hardware;

iii. funciones que calculan expresiones complejas implicadas en las

reglas. [0055] La Consola de monitorización MC se dispone para explorar información de monitorización como:

i. capacidad de procesamiento horaria media (por ejemplo, diariamente), número de solicitudes en cola (por ejemplo, diariamente), tiempo medio de ejecución (por ejemplo, diariamente), plazos para cada transacción de negocio sobre la que se han establecido objetivos de negocio;

ii. situación de SLAs (resaltando los violados) calculada a lo largo de tiempos de intervalos de muestreo, en cuanto a la diferencia

entre el valor acordado y el medido de un indicador de SLA, y

evaluación de la función de costes relacionada;

iii. utilización de recursos de hardware para cada flujo de trabajo, por ejemplo en cuanto a segundos de uso de la CPU y/o la RAM usada (tanto para un solo nivel como para cada nivel por debajo de él); como cada máquina anfitriona tiene una potencia de computación diferente de las otras, la utilización de recursos de hardware, por ejemplo el uso de la CPU, está normalizada respecto a una CPU de referencia;

iv. información de contabilidad: recursos usados por cada flujo de

trabajo (en cuanto a porcentaje del total y en cuanto a coste). [0056] La Consola de monitorización MC permite explorar, de manera jerárquica, los rendimientos y la utilización de recursos de flujos de trabajo (en particular, cada bloque de flujo de trabajo). Para cada SLA, es posible emitir informes acerca de flujos de trabajo que, debido a la utilización intensa de recursos, merece la pena que sean optimizados. Si se establecen otros puntos de medición en diferente nivel de flujos de trabajo, se presentan también en la MC. Además, la MC muestra información acerca de facturación, en cuanto a recursos usados por los flujos de trabajo. [0057] La Consola de entorno de creación de servicio SCC se dispone para definición, creación y modificación de los procesos en la PDB, por lo tanto de cada funcionalidad de negocio proporcionada en la plataforma de gestión. Está basada en una interfaz gráfica para facilitar esta tarea. Esta consola también permite la inserción de nuevos puntos de monitorización en los flujos de trabajo. [0058] En una realización adicional, los datos gestionados por los módulos MM también se usan para lograr una planificación de la capacidad útil añadiendo a los módulos MM una Consola de previsión y un Módulo de planificación de capacidad. [0059] La Consola de previsión se dispone para establecer previsiones de utilización para lograr una actividad de planificación de capacidad útil. Las entradas de esta consola son:

i. la capacidad de procesamiento esperada; y

ii. el número esperado y los tipos de anfitriones de red (este número puede calcularse incluso como proyección de datos en la base de datos de descripción de procesos).

[0060] El Módulo de planificación de capacidad se dispone para asegurar los recursos de hardware a lo largo del tiempo. Se dispone para recibir entradas procedentes de la Consola de previsión y otras consolas (la Consola de objetivo y limitaciones, la Consola administrativa y la Consola de reasignación) y para verificar la disponibilidad de recursos. Si los recursos no son suficientes, el Módulo de planificación de capacidad se dispone para advertir a un operador de la consola acerca de la cantidad de hardware necesario para cumplir con la tendencia incrementada esperada. Este módulo basa su análisis en un conjunto de parámetros que incluye al menos uno de los siguientes:

i. la capacidad de procesamiento esperada (en cuanto a tendencias históricas);

ii. la información de utilización de recursos de cada flujo de trabajo (y especialmente de los flujos de trabajo de primer nivel);

iii. limitaciones geográficas. [0061] Como el Módulo de planificación de capacidad está basado en datos inciertos (especialmente, datos a largo plazo) se dispone principalmente a efectos de información. Puede resaltar necesidades futuras, pero preferentemente no interactúa con el Asignador de recursos RA. [0062] La Figura 3 muestra un ejemplo de la estructura interna de una máquina anfitriona que incluye módulos agentes A y un agente de control CA responsable del rendimiento global del anfitrión y el control de todos los agentes que funcionan en ese anfitrión. [0063] Cada agente A incluye al menos un conjunto de los siguientes componentes:

− una Cola de flujo de trabajo o cola WFQ; es una cola de prioridad multinivel donde cada sub-cola contiene solicitudes con la misma prioridad. Cada solicitud de flujo de trabajo enviada al agente se inserta en la sub-cola correspondiente basándose en su prioridad. En la figura 3 se indican diferentes flujos de trabajo WF1, ..., WFn. Para evitar la falta de alimentación de solicitudes de flujo de trabajo en la cola y para evitar la falta de alimentación de solicitudes de flujo de trabajo en la sub-colas, la cola WFQ implementa una mejora de prioridad para las solicitudes en las sub-colas basándose, por ejemplo, en un criterio de tiempo límite. Asociada a la cola WFQ hay información sobre la cola WFQ, y particularmente:

− el tiempo de consumo de CPU estimado, calculado sumando los tiempos de consumo de CPU de los flujos de trabajo en la cola medidos para cada tipo de flujo de trabajo (estos datos se adquieren de la PFM_DB); y

− el ritmo de entrada de solicitudes, que estima estadísticamente el ritmo (por ejemplo, flujo de trabajo/hora) al que se solicita un flujo de trabajo de un tipo específico para ser ejecutado por otro agente (las solicitudes son puestas en la cola en el agente).

− un Programador de flujo de trabajo WFS asociado con la Cola de flujo de trabajo WFQ: se dispone para programar los flujos de trabajo WFn contenidos en la cola basándose en sus prioridades. Cada vez que uno o más motores de proceso del agente está preparado para ejecutar un flujo de trabajo, el programador envía el flujo de trabajo de prioridad más alta en la cola a uno de los hilos de ejecución de motor de proceso en espera.

− una pluralidad de hilos de ejecución de Motor de proceso TH1,..., THn controlados por el Programador de flujo de trabajo WFS; cada agente puede ejecutar un número configurable de flujos de trabajo simultáneamente. Esto se logra configurando una pluralidad de hilos de ejecución de Motor de proceso TH1,..., THn (ejecutores independientes) en el agente. Cada hilo de ejecución de Motor de proceso TH1,..., THn puede ejecutar un flujo de trabajo a la vez, por ejemplo, un hilo de ejecución implementado en lenguaje Java.

[0064] El agente de control CA incluye al menos un conjunto de los siguientes

componentes, preferentemente software implementado: − un Monitor de recursos RM: este componente se dispone para monitorizar y recopilar datos concernientes a la utilización de recursos de hardware y software en el agente bajo su control. Su papel es medir tanto la utilización actual de recursos en el anfitrión que incluye los agentes (anfitrión de agentes) como el consumo de CPU y memoria debido a una ejecución de flujo de trabajo. Los valores medidos se envían tanto al módulo gestor MM como a un Controlador de hilo de ejecución TC; − un Controlador de hilo de ejecución TC: está asociado al Monitor de recursos RM y la Cola de flujo de trabajo WFQ, y se dispone para control de rendimiento local. Su propósito es gestionar activamente el paralelismo de hilos de ejecución de agentes. Se dispone para recibir como entrada el número de flujos de trabajo que están esperando ser ejecutados en la cola, el uso de la CPU y el número total de hilos de

ejecución de PE de la máquina que se ejecutan. Basándose en las entradas anteriores, el controlador de hilo de ejecución TC aumenta o disminuye el número de hilos de ejecución de Motor de proceso (hilos de ejecución de PE) para lograr el mejor paralelismo de ejecución de flujo de trabajo. Crea, por ejemplo, nuevos hilos de ejecución de PE si la cola contiene flujos de trabajo que están esperando ser ejecutados, si el número total de hilos de ejecución de PE es inferior al máximo permitido y si el uso de la CPU es inferior a un umbral especificado. Si el agente está a cargo de la interacción directa con un recurso externo (como un dispositivo, un equipo de red, etc.), el número máximo permitido de hilos de ejecución de PE está limitado, sin embargo, por la concurrencia admisible del recurso externo. Además, el controlador de hilo de ejecución ejecuta un recolector de basura de hilos de ejecución de PE cuando detecta que algunos hilos de ejecución de PE no se están usando durante un periodo de tiempo definido.

− un Despachador D asociado a los hilos de ejecución de motor de proceso: este componente se dispone para enviar solicitudes de ejecución de flujo de trabajo a otros agentes. Cada hilo de ejecución de PE usa el despachador D para enviar tal solicitud.

El despachador envía las solicitudes a los otros agentes usando, por ejemplo, un algoritmo de balanceo de carga de la siguiente manera. Elige el mejor agente para enviar la solicitud en dos etapas. [0065] En primer lugar, elige el anfitrión menos cargado en cuanto a CPU y memoria. En segundo lugar, elige el agente disponible del anfitrión seleccionado basándose en la menor cantidad de tiempo de consumo de CPU estimado de la cola de agentes. [0066] Los agentes de control CA, por su parte, tienen preferentemente una característica importante según una realización preferida. Pueden gestionar activamente el paralelismo de sus hilos de ejecución de proceso (optimización local). Las dos capacidades de reordenación de cola y gestión de paralelismo unidas entre sí son la base del mecanismo adaptativo según un aspecto de la invención. [0067] Según una realización alternativa de la invención, representada en la figura 4, el Monitor de recursos RM, el Controlador de hilo de ejecución TC y el Despachador D pueden ser anexados al módulo agente, por ejemplo si hay un único módulo agente A en una máquina anfitriona H.

[0068] Una realización preferida del sistema de la invención se implementa usando JADE (estructura de desarrollo de agentes implementados en Java) para implementar agentes con características de movilidad, XPDL (lenguaje de definición de procesos XML) para definición de procesos, y un motor de flujo de trabajo de XPDL como Shark. [0069] A continuación se ofrece una descripción más detallada del Módulo de asignación de recursos, con una vista para mostrar su funcionamiento. [0070] El Reasignador RA puede implementarse como un sistema experto basado en reglas con funcionalidades de procesamiento de limitaciones, manipulación de daros y cambios de configuración. Todos los datos, limitaciones y reglas procedentes de la red gestionada, sistemas externos, conocimiento humano y análisis interno constituyen su base de conocimiento, que puede estar representada materialmente por una base de datos de conocimientos asociada. [0071] El módulo Reasignador RA ejecuta los módulos de Evaluación y Decisión a intervalos de análisis predeterminados, que pueden establecerse basándose en caso por caso dependiendo del contexto del escenario. [0072] En primer lugar, el Reasignador obtiene datos acerca de solicitudes de procesos procedentes de sistemas externos a través del bus B para evaluar el número de solicitudes de servicio/función previstas para el intervalo de tiempo posterior y mantiene esta información en la base de datos de conocimientos asociada. [0073] Luego, el módulo de Decisión activa las reglas de reasignación de recursos para averiguar las acciones que han de adoptarse para lograr objetivos de negocio predeterminados de manera optimizada. [0074] Detalladamente, en cada intervalo T, el módulo de asignación de recursos considera el número de solicitudes puestas en cola y el número de solicitudes previstas basándose en bases históricas. Realiza una primera evaluación de la cantidad de recursos de hardware disponibles (principalmente la CPU y la RAM). Estos datos se ajustan posiblemente usando datos medidos reales al final del intervalo, considerando una “corrección de errores de fondo”, que se describirá después. [0075] Los siguientes datos se recopilan de manera estadística:

− necesidades de CPU para cada flujo de trabajo, en cada nivel; y

− composición del flujo de trabajo de nivel superior en cuanto a solicitudes de sub-flujos de trabajo (con necesidades de CPU asociadas a cada nivel de la arquitectura; esta información también debe considerar limitaciones geográficas, si las hay).

[0076] La información recopilada se correlaciona con la longitud y composición de las colas en un momento t y con el número de solicitudes esperadas (mediante previsión) durante el intervalo [t, t+T] para calcular la solicitud total de potencia de la CPU para los intervalos posteriores, pensados como un conjunto que comprende el siguiente intervalo o un conjunto de intervalos situados después de una pluralidad de intervalos. [0077] La cantidad total de CPU, es decir, la potencia de computación solicitada para el nuevo intervalo (considerando el nivel y las limitaciones geográficas), se compara luego con la potencia de la CPU disponible. Si no es suficiente, se genera una advertencia (solicitando nuevo hardware) en la consola y las prioridades de los flujos de trabajo determinarán cómo se manejará la carga. [0078] Si se considera una “corrección de errores de fondo” para ajustar los datos acerca de los recursos de hardware disponibles, entonces en cada intervalo, para cada flujo de trabajo y para cada máquina anfitriona la cantidad de CPU usada durante el intervalo previo se compara con la cantidad de CPU usada por los diferentes flujos de trabajo. Este valor se usa para “corregir” la disponibilidad real de la CPU durante el intervalo posterior. [0079] El procedimiento y sistema según la invención usan una política basada en prioridades, por lo cual hay diferentes niveles de prioridades. En cada intervalo T, el módulo de Decisión, según un algoritmo de gestión puede manipular colas de prioridad para lograr objetivos de negocio. Para evitar la falta de alimentación, si una solicitud de flujo de trabajo pasa demasiado tiempo dentro de una cola de baja prioridad, su prioridad se actualiza automáticamente de manera que la solicitud se mueve a una cola de prioridad más alta. [0080] El algoritmo de gestión, según una realización preferida de la presente invención, está basado en una solución adaptativa para mejorar la configuración de recursos en cada etapa e intentar alcanzar la mejor configuración con un comportamiento incremental. Los resultados del presente enfoque se garantizan usando un intervalo de análisis que es al menos dos o tres veces el tiempo medio de ejecución de flujo de trabajo (un intervalo razonable dependerá del contexto de la aplicación y puede variar de 5 minutos a 1 hora o más). [0081] Se asocia una prioridad a cada ejecución de flujo de trabajo, teniendo en consideración:

− la situación del SLA acordado (los flujos de trabajo más arriesgados

tendrán un peso superior); − las prioridades iniciales definidas en la Consola de objetivo para el flujo

de trabajo, para prioridad e implicación económica de cada SLA; − la cantidad de recursos preasignados mínimos para el flujo de trabajo; y − la cantidad de recursos asignables máximos (definidos durante la

negociación inicial del SLA). [0082] Esto significa que la prioridad depende del tiempo. Si una instancia de rendimiento de flujo de trabajo está aproximándose al SLA (es decir, su rendimiento se está degradando) su prioridad se establecerá más alta. [0083] En lugar de motores de proceso, puede usarse cualquier medio para definir y medir la ejecución de funcionalidades, por ejemplo la estimación de CPU con técnicas estadísticas. [0084] En lo que viene a continuación, se muestra un ejemplo de escenario de adaptación de rendimiento basándose en la arquitectura propuesta. El recurso que ha de optimizarse es la carga de la CPU. [0085] Según el presente escenario, los flujos de trabajo de nivel superior son servicios asociados a un SLA caracterizados por una propiedad de prioridad, expresada en cuanto a porcentaje de flujos de trabajo que han de finalizarse dentro de un tiempo t >> ∆T, donde ∆T es el tiempo del intervalo de observación. Se requiere una última suposición para dar a la plataforma tiempo suficiente para recalibrarse dentro del periodo t. [0086] Los flujos de trabajo de nivel superior están constituidos por una composición de muchos sub-flujos de trabajo. Todos los flujos de trabajo tienen una propiedad de prioridad que afecta a su tiempo de espera en cola antes del segmento temporal de ejecución y flujo de trabajo en la CPU [0087] Los datos de entrada son:

− carga de la CPU [segundos] para cada flujo de trabajo y cada máquina central; − Restricciones, es decir los mismos flujos de trabajo pueden ejecutarse solamente en un subconjunto de máquinas centrales; − composición de flujo de trabajo de primer nivel en términos de sub-flujos

de trabajo; − número de llegadas de flujo de trabajo en el periodo pasado ΔT;y − número de ejecución de flujo de trabajo en el periodo pasado ΔT;

[0088] Los objetivos son: − prever si los recursos computacionales son suficientes para realizar todas

las ejecuciones de flujo de trabajo en el siguiente intervalo ΔT; − prever si los recursos computacionales son adecuados para se conformes con el SLA; y − adaptación de la prioridad de ejecución de flujo de trabajo para alcanzar

la conformidad SLA. [0089] El proceso de adaptación del rendimiento se basa en la monitorización realizada cada intervalo de tiempo ΔT, que representa el tiempo mínimo de adaptación de la plataforma. [0090] En referencia al diagrama de flujo de la figura 5, que presenta un ejemplo de la monitorización realizada cada intervalo de tiempo ΔT, para cada ΔT las siguientes etapas son gestionadas por el Asignador de Recursos RA:

1.

evaluación de la carga de la CPU de cada flujo de trabajo en cada anfitrión (etapa 100). Esto se realizará ejecutando un flujo de trabajo de ensayo de la carga en una muestra de anfitrión y usando la documentación de la CPU (previsión a priori). El valor obtenido puede ajustarse finamente usando el tiempo real de tratamiento de la CPU asociado con cada flujo de trabajo ejecutado en el anterior ΔT teniendo en cuenta las restricciones a la ejecución del flujo de trabajo;

2.

previsión del tiempo de tratamiento de la CPU necesario para ejecutar los flujos de trabajo que siguen esperando en las colas, más los flujos de trabajo que se prevé que lleguen en el siguiente ΔT (etapa 120);

3.

comparar (etapa 140) el tiempo de tratamiento de la CPU evaluado en la etapa 120 con el tiempo de tratamiento de la CPU disponible para identificar el grupo de anfitriones que son críticos en términos de recursos computacionales y, a partir de esto, el primer flujo de trabajo asociado al SLA afectado; en caso de que el recurso de la CPU necesario sea mayor que el recurso de la CPU disponible, notificar recursos de la CPU bajos (etapa 150);

4.

Para cada SLA, prever (etapa 160) el tiempo de tratamiento de la CPU necesario para ejecutar el número mínimo de flujos de trabajo para acomodarse a los requisitos del SLA, y a continuación comparar (etapa 170) con éste el tiempo de tratamiento de la CPU disponible para determinar si los recursos computacionales son suficientes para ser conformes con el SLA;

5.

si la etapa anterior indica que la actual configuración de prioridad de la plataforma en los flujos de trabajo en ejecución no puede soportar las restricciones de SLA, hay que ajustar la configuración a través de la

metodología de adaptación de prioridad de flujos de trabajo (etapa 180), con un re-equilibrio de prioridad de flujo de trabajo (teniendo en cuenta el peso del flujo de trabajo en términos de recursos computacionales);

6.

cuando no se necesita adaptación de prioridad, o se ha realizado la adaptación de prioridad, el sistema finaliza el proceso de adaptación del rendimiento y espera al siguiente intervalo de monitorización ΔT.

[0091] En lo sucesivo en este documento se detalla el ejemplo de metodología de

predicción del proceso de adaptación del rendimiento. Se realizan las siguientes

definiciones: −ΔT: intervalo de monitorización y tiempo mínimo de adaptación del sistema; − Lwf(n): carga de la CPU [segundos] para la ejecución del flujo de trabajo wf en el anfitrión n. Estos valores pueden estimarse a priori (o usando un enfoque de auto-aprendizaje) y a continuación ajustarse durante el funcionamiento de la plataforma. Por ejemplo, con un promedio móvil en el tiempo.

− Vwf(n): restricción para el flujo de trabajo wf en el anfitrión n, dada por:

imagen2

[0092] La previsión del tiempo de tratamiento de la CPU necesario para ejecutar todos los flujos de trabajo previstos en el siguiente ΔT se calcula de la siguiente manera:

imagen2

donde: g es un grupo de anfitriones equivalentes para todos los flujos de trabajo en el conjunto WF(g). Esto significa que cada flujo de trabajo que pertenece al conjunto WF(g) puede ejecutarse con la misma probabilidad en uno de los anfitriones del grupo g. lwf es la previsión del tiempo de tratamiento de la CPU necesario para ejecutar el flujo de trabajo wf en un anfitrión del grupo g, dado por:

imagen2

NEPwf es el número de ejecuciones previstas para el flujo de trabajo wf, dado por

imagen2

donde: NQwf es el número total de flujos de trabajo wf en las colas de ejecución que se expresarán en términos de llamadas de flujo de trabajo de primer nivel, mediante la siguiente:

imagen2

NAPwf(g) es la previsión del número total de flujos de trabajo wf previstos en el intervalo de tiempo posterior ΔT, dada por:

imagen2

donde: Pi es el peso de los flujos de trabajo llegados en un anterior ΔTi NAwf(l1),i(n) es el número de flujos de trabajo wf llegados al anfitrión en el intervalo de tiempo ΔTi, que son sub-flujos de trabajo del flujo de trabajo de primer nivel wfl1.

[0093] En referencia a los tres objetivos mencionados anteriormente, se realizan etapas de previsión y adaptación de la siguiente manera. [0094] Para prever si el tiempo de tratamiento de la CPU disponible es suficiente para ejecutar los flujos de trabajo previstos en el posterior ΔT, se realiza la comparación entre el tiempo de tratamiento de la CPU CpuTimeP(g) y el tiempo de tratamiento de la CPU disponible en el grupo g, para cada grupo g:

imagen2

Si el sistema tiene suficientes recursos computacionales para realizar todas las tareas [0095] Si

imagen2

imagen2

el sistema requiere más tiempo de tratamiento de la CPU, así que envía un mensaje

con:

a)

el grupo g de anfitriones que es crítico en términos de recursos

computacionales; y

b)

los flujos de trabajo de primer nivel asociados con SLA que pueden resultar

más afectados por esta falta de recursos.

[0096]

Para prever si los recursos computacionales son suficientes para ser

conformes al SLA, para cada SLA definido en un flujo de trabajo de primer nivel wfl1, se calcula el número de wfl1 a ejecutar en el posterior ΔT para que sean conformes al SLA, NSLAwfl1:

Si el SLA se define como el porcentaje p[%] de flujos de trabajo wfl1 a ejecutar dentro del tiempo t (con t >> ΔT), entonces NSLAwfl1 viene dado por:

imagen2

donde: NSLAQwfl1 viene dado por la suma, para cada ΔTi, de la proporción entre el número de flujos de trabajo wfl1 que siguen esperando en la cola llegada en ΔTi y el número n = (t-kΔT)/ΔT de ΔT aún disponibles para completar estos flujos de trabajo a tiempo para que sean conformes al SLA; k es el número de ΔT, dado que el flujo de trabajo está esperando en la cola desde su llegada; y NSLAPwfl1 es la proporción entre la previsión del número de llegada de flujos de trabajo wfl1 en el siguiente ΔT y el número de ΔT aún disponibles para completar estos flujos de trabajo para que sean conformes al SLA (es decir t/ΔT)

[0097] Por lo tanto, el tiempo de tratamiento de la CPU necesario para que sea conforme al SLA para el flujo de trabajo viene dado por: donde

imagen2

imagen3

donde NEwf(wfl1)(g) es la previsión del número de flujos de trabajo wf a ejecutar en el grupo central g para cada ejecución de flujo de trabajo, dado por:

10

[0098] De nuevo, si

imagen2

el sistema tiene suficientes recursos computacionales para ser conforme al SLA para el flujo de trabajo wfl1.

15 [0099] Si

imagen2

el sistema no es capaz de ser conforme al SLA para el flujo de trabajo wfl1 ya continuación se aplica la metodología de adaptación de prioridad de flujos de trabajo descrita en el siguiente punto.

20 [0100] La metodología de adaptación de prioridad de flujos de trabajo se aplica cuando hay al menos un flujo de trabajo de primer nivel de tipo A asociado con un SLA para el que:

imagen4

[0101] La metodología consiste en diversas acciones, de las cuales al menos

algunos ejemplos se describen a continuación, ordenados por complejidad:

a) aumentar la prioridad de los flujos de trabajo de tipo A;

b) reducir la prioridad de los flujos de trabajo de tipo B;

c) asociar un peso a cada flujo de trabajo de primer nivel para seleccionar los

más relevantes para realizar las acciones a) o b);

d) reducir la prioridad de flujos de trabajo que en el anterior ΔT ya no han

conseguido ser conformes con el SLA, para aquellos SLA cuya cláusula de

penalización no aumenta con el tiempo;

e) aumentar la prioridad de flujos de trabajo que en el anterior ΔT no han

conseguido ser conformes con el SLA, para aquellos SLA cuya cláusula de

penalización aumenta con el tiempo. [0102] Las acciones d) y e) se basan en una función que intenta minimizar el impacto sobre el coste de las penalizaciones del SLA, definida mediante la Consola de Objetivos y Restricciones GC. [0103] Convenientemente, esta metodología tiene en cuenta las restricciones en la utilización de los recursos, como la cantidad máxima de tiempo de tratamiento de la CPU a asignar para cada uno de los flujos de trabajo. Esto significa que la prioridad de un flujo de trabajo que ya está usando la máxima cantidad de tiempo de tratamiento de la CPU reservado no se puede aumentar. [0104] Si la recogida del coste exacto de cada flujo de trabajo es demasiado pesada, una posibilidad alternativa es que el agente recoja a intervalos predeterminados (por ejemplo cada cinco minutos) el número de “módulo construido” ejecutado y establezca una correlación con la utilización de recursos del sistema (por ejemplo utilización de la CPU). [0105] Técnicas regresivas multivariadas se emplean a menudo para estimar el rendimiento de sistemas informáticos en condiciones de sobrecarga. Esta elección se basa en el análisis del comportamiento de un número de OSS “en campo” que se ejercitaron más allá de su capacidad. El resultado fue que la mayoría de las medidas de rendimiento comunes para OSS, tales como la utilización de la CPU, pueden modelarse mediante regresión lineal. El tiempo de respuesta del sistema, por ejemplo, aumenta según una ley exponencial moderada. Por lo tanto, puede obtenerse un límite más bajo para predecir el rendimiento del sistema mediante una técnica de regresión lineal multivariada basada en datos de recursos del sistema y datos de ejecución del flujo de trabajo.

[0106] Un ejemplo de modelo polinomial simple es el siguiente:

imagen2

donde Ucpu = utilización de la CPU del agente;

5 NA = Número de ejecución del módulo construido A; NB = Número de ejecución del módulo construido B; NC = Número de ejecución del módulo construido C;

[0107] Ventajosamente, todas las mediciones (y en particular la definición de SLA) debe traducirse en una cantidad económica para optimizar la adaptación de

10 manera coherente. [0108] La figura 6 muestra, a modo de ejemplo, el establecimiento de un servicio de tres capas que proporciona un escenario según la invención, caracterizado por flexibilidad y escalabilidad. [0109] En el ejemplo, los agentes de la capa inferior son responsables de la

15 interacción con el elemento de red y se denominan Proxy de Recursos y se indican como RP1, RP2, RP3. [0110] Un servicio de banda ancha llamado “Oferta 1” se suministrará en una red de telecomunicaciones que incluye dispositivos de acceso (por ejemplo, un equipo de ADSL), un backbone ATM y BAS (Servidores de Acceso de Banda Ancha) para

20 obtener conectividad IP. [0111] Los ejemplos de servicios ofrecidos por un RP son configuración de puertos, creación de conexiones cruzadas, modificación de los atributos de conexión. Cada una de ellos puede incluir secuencias de comandos básicos que serán enviadas y/o recibidas a/por los equipos.

25 [0112] AA1, AA2, AA3 son los agentes que gestionan, respectivamente, el Proxy de Recursos RP1 que representa la imagen del Equipo de ADSL E (punto final A del circuito de extremo a extremo), el Proxy de Recursos RP2 que representa la imagen del conmutador ATM SW conectado al Equipo de ADSL E y el Proxy de Recursos RP3 que representa la imagen del BAS (punto final Z del circuito de extremo a extremo).

30 [0113] Los flujos de trabajo multinivel implicados en la actividad de suministro del servicio “Oferta 1” se muestran en la figura 7. [0114] El flujo de trabajo de nivel 1 o nivel superior comprende dos etapas o tareas y es ejecutado por el Agente Maestro MA. La primera (Conectividad ADSL) solicita la ejecución de un flujo de trabajo de nivel 2 que es ejecutado a nivel del agente (AA1, AA2, AA3) mientras que la segunda, es decir la tarea de Buzón (no se detalla en este ejemplo) puede ser realizada por una plataforma externa. [0115] La Tarea de Conectividad ADSL es, por lo tanto, un flujo de trabajo de nivel 2 que comprende una secuencia de flujos de trabajo de nivel 3, dependientes de la tecnología y del proveedor, que se ejecutan a nivel del Proxy de Recursos (RP1, RP2, RP3). Los flujos de trabajo de nivel 3 comprenden secuencias de los comandos que deben ser realizadas en un equipo de red de comunicación por el Proxy de Recursos. Un ejemplo de flujo de trabajo de nivel 3 se proporciona en la figura 7 expandiendo el flujo de trabajo de nivel 2 “Crear Puerto ADSL, Proveedor A”. [0116] Midiendo el uso de recursos (CPU, RAM) y el tiempo transcurrido de cada flujo de trabajo, la Consola de Monitorización MC destaca si hay problemas en un Proveedor o en un flujo de trabajo particular. [0117] Suponiendo que exista otro servicio “Oferta 2” similar al servicio “Oferta 1” pero sin el Buzón, cuando la Consola de Objetivos permite definir SLA en la Oferta 1 y la Oferta 2 con una regla de control de SLA y una función de coste relacionada. Si el SLA en el servicio “Oferta 2” es más importante (por ejemplo la función de coste asociada a la “Oferta 2” es igual al número de segundos que superan un tiempo de ejecución promedio de 1 segundo y la función de coste asociada a la “Oferta 1” es igual al número de segundos que superan un tiempo de ejecución promedio de 4 segundos) entonces la prioridad en la “Oferta 2” crece más rápido que la prioridad de la “Oferta 1”. Esto significa que, cuando el recurso de hardware (por ejemplo la CPU) escasea con el mismo número de peticiones, el rendimiento de la “Oferta 2” será mayor que el rendimiento de la “Oferta 1”. [0118] Por lo tanto, la plataforma ajusta la utilización del recurso para alcanzar su objetivo, ya sea éste un requisito establecido por un operador externo o debido a la saturación del agente. [0119] Naturalmente, mientras el principio de la invención siga siendo el mismo, las formas de realización pueden variar ampliamente con respecto a las descritas e ilustradas puramente a modo de ejemplo no limitante, sin alejarse por ello del alcance de protección de la presente invención definido por las reivindicaciones adjuntas.

REFERENCIAS CITADAS EN LA DESCRIPCIÓN

Esta lista de referencias citadas por el solicitante está prevista únicamente para ayudar al lector y no forma parte del documento de patente europea. Aunque se ha puesto el 5 máximo cuidado en su realización, no se pueden excluir errores u omisiones y la OEP declina cualquier responsabilidad al respecto.

Documentos de patente citados en la descripción 10 • US 6243396 B [0003]

•

WO 0102973 A [0004] [0007]

•

US 20030036886 A [0010]

Claims (28)

1. REIVINDICACIONES

   1. Un procedimiento para gestionar recursos en una plataforma para servicios y/o redes de telecomunicaciones, incluyendo el procedimiento ejecutar agentes distribuidos (A1, A2, A3), incluyendo dichos agentes motores de procesos (PE) para ejecutar procesos de gestión, estando el procedimiento caracterizado por:

   - establecer datos objetivo a cumplir, en los que dichos datos objetivo incluyen objetivos en las ejecuciones del proceso por los agentes distribuidos y limitaciones a la utilización de recursos;

   - monitorizar, por medio de dichos motores de procesos incluidos en dichos agentes distribuidos, las ejecuciones de procesos mediante los agentes distribuidos (A1, A2, A3) y la utilización de recursos,

   - recoger datos de rendimiento representativos de dichas ejecuciones de procesos y de dicha utilización de recursos;

   - comparar los datos de rendimiento recogidos con los datos objetivo establecidos,

   - establecer al menos una cláusula de penalización en base a una comparación entre los datos de rendimiento recogidos de dichos agentes y los datos objetivo establecidos; y

   - reasignar recursos a dichos agentes (A1, A2, A3) para ejecuciones de procesos por agentes (A1, A2, A3) en base a dicha al menos una cláusula de penalización establecida.

2. 2.

   Un procedimiento según la reivindicación 1, en el que la etapa de reasignación de recursos incluye modificar las prioridades de procesos en los agentes distribuidos (A1, A2, A3).

3. 3.

   Un procedimiento según la reivindicación 1, en el que la etapa de reasignación de recursos incluye

   - ejecutar una etapa de evaluación y una etapa de decisión a intervalos de

   observación determinados, en el que

   - la etapa de evaluación comprende

   - recoger datos representativos tanto de ejecuciones de procesos como del

   número de ejecuciones de procesos previstas durante al menos uno de intervalos de observación posteriores, y

   -evaluar, en base a dichos datos recogidos, los recursos requeridos por dichos agentes, y

   - la etapa de decisión comprende -comparar los recursos requeridos con los recursos disponibles para cada uno de dichos agentes (A1, A2, A3), y

   - aplicar determinadas reglas de asignación de recursos a dichos agentes (A1, A2, A3) para modificar la utilización de recursos entre los agentes (A1, A2, A3) y/o cambiar las prioridades de procesos en los agentes (A1, A2, A3) y/o reasignar ejecuciones de procesos entre los agentes (A1, A2, A3).

4. 4.

   Un procedimiento según cualquiera de las reivindicaciones anteriores, caracterizado por almacenar descripciones de procesos representativas de procesos en una base de datos de descripciones de procesos (PDB) asociada a dichos motores de procesos (PE).

5. 5.

   Un procedimiento según la reivindicación 4, en el que las descripciones de procesos incluyen flujos de trabajo y/o reglas.

6. 6.

   Un procedimiento según cualquiera de las reivindicaciones anteriores, que incluye

   - proporcionar los agentes (A1, A2, A3) en niveles jerárquicos según una configuración multicapa de los agentes (A1, A2, A3).

7. 7.

   Un procedimiento según la reivindicación 6, en el que las ejecuciones de procesos se asignan a la configuración multicapa de los agentes (A1, A2, A3) mediante un módulo gestor centralizado (MM).

8. 8.

   Un procedimiento según la reivindicación 7, en el que

   - la etapa de recogida de datos de rendimiento comprende

   - transmitir dichos datos de rendimiento al módulo gestor centralizado (MM) y/o a una pluralidad de agentes de control del rendimiento locales (CA) asociados a los agentes (A1, A2, A3).
9. 9. Un procedimiento según la reivindicación 7, que incluye

   - proporcionar al menos un agente maestro (MA) en la capa superior de dicha configuración multicapa de agentes (A1, A2, A3), asignando el agente maestro (MA) las ejecuciones de procesos a los agentes (A1, A2, A3) situados en sub-capas de dicha configuración multicapa.
10. 10. Un procedimiento según cualquiera de las reivindicaciones anteriores, que comprende, para cada agente (A1, A2, A3), las etapas de

    - insertar una petición de ejecución de procesos en una cola de procesos de prioridad multinivel (WFQ) según un criterio de prioridad;

    - programar las ejecuciones de procesos en base a la cola de procesos de prioridad multinivel (WFQ).

11. 11.

    Un procedimiento según la reivindicación 10, que incluye programar ejecuciones de procesos mediante al menos un hilo de motor de procesos (TH1,..., THn) asociado a cada agente.

12. 12.

    Un procedimiento según la reivindicación 10, en el que las peticiones de ejecución de procesos en la cola de procesos de prioridad multinivel (WFQ) se actualizan en base a un criterio de expiración de temporización.

13. 13.

    Un procedimiento según la reivindicación 8 y 11, en el que cada agente control (CA) controla el número de hilos de motor de procesos (TH1,..., THn) y la utilización de recursos por los agentes.

14. 14.

    Un procedimiento según la reivindicación 8, en el que

    - el agente de control (CA) ejecuta un algoritmo de equilibrado de carga para determinar la carga de los agentes; y

    - cada agente (A1, A2, A3) envía peticiones de ejecución de procesos a otros agentes (A1, A2, A3) en base a un criterio, que incluye al menos una evaluación de la carga de los agentes según lo determinado por el agente de control (CA).

15. 15.

    Una plataforma para gestionar recursos para servicios y/o redes de telecomunicaciones, que comprende

    - una pluralidad de agentes distribuidos (A1, A2, A3) capaces de gestionar ejecuciones de procesos (WF1,..., WFn) en el que dichos motores de procesos (PE) incluidos en los agentes distribuidos están configurados para monitorizar las ejecuciones de procesos y la utilización de recursos por los agentes distribuidos (A1, A2, A3) y

    - un módulo gestor centralizado (MM), configurado para

    -establecer datos objetivo a cumplir por la plataforma, en los que dichos datos objetivo incluyen objetivos en las ejecuciones del proceso (WF1,..., WFn) por los agentes distribuidos y limitaciones a la utilización de recursos a cumplir por la plataforma;

    -recoger datos de rendimiento representativos de dichas ejecuciones de procesos y de dicha utilización de recursos por los agentes distribuidos (A1, A2, A3);

    -comparar los datos de rendimiento recogidos con los datos objetivo establecidos,

    -establecer al menos una cláusula de penalización en base a una comparación entre los datos de rendimiento recogidos de dichos agentes y los datos objetivo establecidos; y

    - reasignar recursos a dichos agentes (A1, A2, A3) para ejecuciones de procesos por agentes (A1, A2, A3) en base a dicha al menos una cláusula de penalización establecida.
16. 16. Una plataforma según la reivindicación 15, caracterizada porque dicho módulo gestor centralizado (MM) comprende un módulo de asignación de recursos (RA) que incluye

    - un módulo de evaluación configurado para

    -recoger datos representativos tanto de ejecuciones de procesos como del número de ejecuciones de procesos previstas para un intervalo de observación posterior, y

    - evaluar, en base a dichos datos recogidos, los recursos requeridos por dichos agentes, y

    - un módulo de decisión configurado para

    - comparar los recursos requeridos con los recursos disponibles para cada uno de dichos agentes (A1, A2, A3), y

    - aplicar determinadas reglas de reasignación de recursos a dichos agentes (A1, A2, A3) para modificar la utilización de recursos entre los agentes (A1, A2, A3) y/o cambiar las prioridades de procesos en los agentes (A1, A2, A3) y/o reasignar ejecuciones de procesos entre los agentes (A1, A2, A3).
17. 17. Una plataforma según la reivindicación 15 a 16, caracterizada porque dicho módulo gestor centralizado (MM) incluye

    - una base de datos de descripción de procesos (PDB) para almacenar descripciones de procesos representativas de aspectos comportamentales y funcionales de la plataforma.
18. 18. Una plataforma según la reivindicación 17, caracterizada porque dicho módulo gestor centralizado (MM) incluye además

    - una Consola de creación de servicio (SCC) dispuesta para la definición, creación y modificación de las descripciones de procesos en la base de datos de descripción de procesos (PDB).

19. 19.

    Una plataforma según la reivindicación 17, caracterizada porque las descripciones de procesos incluyen flujos de trabajo y/o reglas.

20. 20.

    Una plataforma según la reivindicación 15 a 19, caracterizada porque

    - dicha pluralidad de agentes distribuidos (A1, A2, A3) están organizados en niveles jerárquicos según una configuración multicapa, y porque

    - dicho módulo gestor centralizado (MM) está configurado para asignar ejecuciones de procesos a dicha configuración multicapa de agentes.

21. 21.

    Una plataforma según las reivindicaciones 15 a 20, caracterizada por

    - agentes de control del rendimiento locales (CA) asociados a al menos un conjunto de agentes distribuidos (A1, A2, A3), y porque

    - dichos motores de procesos (PE) incluyen módulos de monitorización de recursos (RM) configurados para

    - transmitir dichos datos de rendimientos al módulo gestor centralizado (MM) y/o a los agentes de control del rendimiento locales (CA) asociados a los agentes (A1, A2, A3).
22. 22. Una plataforma según la reivindicación 20, caracterizada por

    - al menos un agente maestro (MA) situado en la capa superior de dicha configuración multicapa de agentes (A1, A2, A3) y configurado para asignar ejecuciones de procesos a agentes (A1, A2, A3) situados en sub-capas de dicha configuración multicapa.
23. 23. Una plataforma según las reivindicaciones 15 a 22, caracterizada por

    - al menos una máquina de procesamiento (H) que incluye al menos un conjunto de dicha pluralidad de agentes distribuidos (A1, A2, A3).

24. 24.

    Una plataforma según la reivindicación 23, caracterizada porque al menos un agente de control del rendimiento local (CA) está asociado a dicha al menos una máquina de procesamiento (H).

25. 25.

    Una plataforma según la reivindicación 24, caracterizada porque dicho al menos un agente de control del rendimiento local (CA) incluye:

    -

    un módulo de monitorización del rendimiento local común (RM) dispuesto para recoger datos de rendimiento representativos de la utilización de recursos y la ejecución de procesos por los agentes (A1, A2, A3) y transmitir los datos de rendimiento al módulo gestor centralizado (MM);

    -

    un controlador de hilos común (TC) acoplado al monitor de recursos (RM) dispuesto para crear hilos de motor de procesos (TH1,... , THn) para ejecutar procesos de espera (WF1,... , WFn); y

    -

    un módulo despachador común (D) acoplado a los hilos de motor de procesos (TH1,..., THn) y dispuesto para enviar peticiones de ejecución de procesos a otros agentes (A1, A2, A3) según un algoritmo de equilibrado de carga predeterminado.

26. 26.

    Una plataforma según la reivindicación 15, caracterizada porque el módulo gestor (MM) incluye

    - un módulo de planificación de capacidad configurado para

    - prever la disponibilidad de recursos en un intervalo de observación en base al rendimiento histórico y a datos representativos de la presente utilización de los recursos.
27. 27. Una plataforma según la reivindicación 15, caracterizada porque el módulo gestor (MM) incluye

    - una consola administrativa (AC) configurada para: -definir la configuración de hardware de la plataforma; y -definir limitaciones a las ejecuciones de procesos.

    5 28. Una red de telecomunicaciones que incluye una plataforma según cualquiera de las reivindicaciones 15 a 27.
28. 29. Producto de programa informático o conjunto de programas informáticos de productos de programas informáticos que pueden cargarse en la memoria de al

    10 menos un ordenador y que comprende partes de código de software para realizar las etapas de cualquiera de las reivindicaciones 1 a 14.