Capacidades de Computación Autónoma en el entorno AWSE sobre el estándar WSDM para Servicios Web

Transcripción

1 1 Capacidades de Computación Autónoma en el entorno AWSE sobre el estándar para Servicios Web Carlos Alario-Hoyos Doctorado: Arquitecturas para Procesamiento Distribuido (APD) GSIC-EMIC, E.T.S.I. Telecomunicación. Universidad de Valladolid , Valladolid, España. 10 de Julio de ( Resumen Los sistemas de Computación Autónoma son especialmente útiles en la auto-gestión de sistemas distribuidos, debido al coste elevado y la falta de fiabilidad de una administración manual. En este sentido los Servicios Web pueden llevar a cabo su gestión gracias al estándar. Sin embargo, éste no incluye capacidades de Computación Autónoma. Por ello, se analiza la propuesta del entorno de auto-gestión AWSE para recursos ofrecidos como Servicios Web, destacando la no especificación de qué capacidades son relevantes y la falta de mecanimos de replicación y monitorización de servicios. Según ello, se propone la replicación autónoma de Servicios Web para conseguir las capacidades self-healing, self-adapting y self-optimizing. Index Terms Computación Autónoma,, AWSE, Servicios Web. I. INTRODUCCIÓN La Computación Autónoma (Autonomic Computing) [1] es un nuevo campo de estudio para controlar el crecimiento y la gestión de los grandes sistemas de computación [2]. Este desafío pretende que dichos sistemas se gestionen por sí mismos de acuerdo con políticas o acuerdos de nivel de servicio (SLAs - Service Level Agreements [3]) especificadas por administradores humanos [4]. Dentro de estas capacidades de Computación Autónoma se incluyen los términos de self-configuring, self-adapting, self-healing, self-optimizing y self-protecting; todos ellos pueden agruparse bajo el concepto de self-management [5]. Las capacidades de Computación Autónoma son especialmente deseables en todos aquellos sistemas en los que un administrador humano requiere un gran esfuerzo y coste. Un ejemplo de ello son los sistemas distribuidos, y en especial los sistemas distribuidos basados en servicios que siguen el paradigma SOC (Service-Oriented Computing) [6]. La gestión manual de estos servicios es muy complicada debido al bajo acoplamiento entre aplicaciones, el corto ciclo de vida de los servicios, y la composición por medio de terceros de servicios básicos, con el fin de obtener una mayor funcionalidad y un valor añadido [5]. El hecho de que esta composición pueda ser ajena a los proveedores de servicios básicos, puede confrontar diferentes mecanismos y políticas de gestión, seguridad, QoS, etc. En estos casos, la implementación de un sistema de Computación Autónoma, además de ahorrar costes, puede permitir homogeneizar todos esos mecanismos y políticas [1]. Los Servicios Web (WS - s), como implementación concreta y más conocida del paradigma SOC [7], así como los recursos asociados, son normalmente gestionados, mediante el estándar ( Distributed ) [8]. Este estándar especifica un protocolo de intercambio de mensajes común para gestionar recursos y servicios [9]. puede subdividirse en otros dos estándares, MUWS ( Using s) [10] y MOWS ( of s) [11]. MUWS proporciona los mecanismos básicos y los modelos de intercambio de mensajes para gestionar recursos utilizando Servicios Web como plataforma de intercambio (Figura 1). La información contenida puede hacer referencia al estado, a la configuración o a algún determinado tipo de métrica sobre el recurso. MOWS está orientado a la gestión de los propios Servicios Web. Como tal, MOWS es una extensión y aplicación de la especificación MUWS [11]. Figura 1. Gestión de recursos usando WS. Estándar -MUWS. El estándar no proporciona ninguna capacidad de Computación Autónoma ni de auto-gestión que pueda ser aplicada en el ámbito de los Servicios Web. En este sentido, los autores de [12] proponen utilizar para implementar Servcios Web autónomos que monitorizan el estado de los recursos asociados, tomando decisiones en consecuencia.

2 2 Para ello proponen un Entorno de Servicios Web Autónomo (AWSE - Autonomic Environment) [13]. AWSE emplea un conjunto de gestores (managers) autónomos distribuidos jerárquicamente para obtener estadísticas acerca de los recursos. AWSE está implantado sobre el estándar MUWS de, y describe cada recurso como un componente a monitorizar, con un número de parámetros o métricas dependiendo del tipo de componente. Por ejemplo un Sistema de Gestión de Base de Datos (DBMS - DataBase System) bajo el entorno AWSE [14] requiere un número más elevado de métricas que un servidor HTTP. Los managers pueden subscribirse a cada uno de los componentes para así recibir notificaciones de ellos. Un defecto relevante en los artículos [12], [13] y [14] es que no contemplan ni especifican las capacidades de self-management que pueden conseguirse al implementar AWSE en nuestros Servicios Web. Además, la limitación más importante es que solamente los recursos son autogestionados, sin embargo no se prevee ningún tipo de Computación Autónoma para los propios Servicios Web. En este sentido la bibliografía recoge la utilización de un Servicio de Gestión basado en Componentes Distribuidos [15] (DCMS - Distributed Component Service) que sí permite la auto-gestión tanto de recursos como de servicios. Sin embargo, su mayor desventaja es que su implementación está realizada con componentes Fractal [16], lo que dificulta la interoperabilidad con los paradigmas orientados a servicios. Por tanto, se plantea como objetivo y contribución principal la modificación de AWSE (según la especificación ) para introducir capacidades de Computación Autónoma en los propios Servicios Web, a partir de la replicación de su funcionalidad de forma distribuida. También se hace necesario definir qué tipo de capacidades (self-configuring, self-adapting, self-healing, self-optimizing y self-protecting) se consiguen con esta aproximación. Para ello, se requiere estudiar el significado de cada una de ellas, y si son aplicables a la infraestructura propuesta. Como último paso se propone sobre el papel un ejemplo teórico de funcionamiento de un Servicio de Almacenamiento auto-gestionado. El resto del documento se estructura de la siguiente manera: en la Sección II se tratan los conceptos de Computación Autónoma, así como la especificación y el marco AWSE. La Sección III plantea la modificación para conseguir Servicios Web autogestionados. La Sección IV valora las capacidades self-management bajo la propuesta de AWSD implementada sobre el estándar. La sección V muestra un ejemplo concreto sobre este escenario. Finalmente se establecen las conclusiones y las líneas futuras. II. CONTEXTO Desde un primer momento conviene definir los conceptos clave que se exponen en el resto del artículo; según ello se explica del concepto más general de Computación Autónoma (Autonomic Computing), el estándar (s Distributed - Gestión Distribuida de Servicios Web) y la arquitectura AWSD (Autonomic s Environment - Entorno de Servicios Web Autónomos). II-A. Computación Autónoma El concepto de Computación Autónoma está inspirado en el sistema nervioso humano, capaz de repararse ante daños físicos sin intervención externa [17]. Su primera definición se remonta a [1] y todavía es ampliamente aceptada [17], [18]. Según esto, se dice que un sistema de Computación Autónoma comprende las siguientes ocho características: self-awareness, self-configuring, self-optimizing, self-healing, self-protecting, context-awareness, openness, anticipation. De las ocho características anteriores las cuatro siguientes son consideradas como mayoritarias, mientras el resto son de menor importancia [17]. Self-configuring: Define la capacidad de reaccionar automáticamente ante condiciones impredecibles, ajustando cambios en la configuración o puesta a punto de forma dinámica. Un ejemplo sería la reasignación de recursos en sistemas distribuidos, como memoria, almacenamiento o capacidad de procesamiento. Self-optimizing: Se refiere a la capacidad de minimizar la reserva de recursos y la utilización, pero sin renunciar a los requisitos del cliente. Para ello suele haber mecanismos de realimentación monitorizando las métricas del sistema, como la carga o la utilización de un recurso. Self-healing: Según su definición, el sistema debe ser capaz de descubrir problemas y solucionarlos de forma transparente al usuario. Un ejemplo es la replicación de servicios o recursos para conseguir una buena tolerancia y recuperación ante fallos. Self-protecting: Se considera que los sistemas autoprotegidos incluyen políticas propias para permanecer alerta ante posibles ataques que afecten a los elementos del sistema. Los beneficios del Autonomic Computing radican en la simplificación de tareas del administrador humano, la mayor disponibilidad y la reducción de costes. Además, aseguran una mayor eficiencia sin comprometer los niveles de QoS ofrecidos al usuario. Los sistemas de Computación Autónoma puede aplicarse para gestionar el tráfico y en sistemas de construcción o manufacturación [19]. Además, en la bibliografía de sistemas distribuidos se han empleado para la gestión de bases de datos, reduciendo la complejidad y el coste [20], y también para el balanceo de carga en Sistemas de Información Geográfica (GIS - Geographic Information Systems) [21]. II-B. El estándar [8] define varios tipos de interfaces de gestión para gestionar Servicios Web [5]. especifica un protocolo de mensajería común entre diferentes servicios y recursos de forma independiente a la plataforma utilizada [9]. El centro de la arquitectura son los recursos

3 3 gestionados. Estos se representan mediante Servicios Web como se muestra en la Figura 1; por tanto la información de gestión queda accesible a través de un endpoint (o punto de acceso) al Servicio Web. Para proveer del acceso se utiliza un EPR (endpoint reference) definido según el estándar WS-Addressing [22]. La implementación más allá de los endpoints debe ser capaz de recuperar y manipular la información sobre los recursos gestionados. Un elemento importante de son las notificaciones de los eventos significativos, que se especifican desde los recursos gestionados al administrador de gestión, subscrito a la recepción de esos eventos. Entre la información que puede ofrecerse de cada recurso se encuentran [9]: Identidad, Características de Gestión, Descripción, Estado, Relaciones, Configuración, Avisos, etc. Además, la información que puede obtenerse en este caso hace referencia al porcentaje de espacio utilizado, al estado de los datos y a la relación entre los mismos. El Site Manager es el elemento que se puede subscribir a cada uno de los eventos de los que espera recibir notificaciones cuando suceden algunos cambios. Si un parámetro varía se actualiza la información en el repositorio a través de una notificación según el estándar WS-BaseNotification [24]. La versión adaptada de AWSE a puede verse en la Figura 3. El estándar se subdivide en MUWS y MOWS. MUWS utiliza los mecanismos básicos para intercambio de mensajes (MEPs - Message Exchange Patterns), entre el recurso y el Servicio Web, definidos por Oasis [23]. MOWS se encarga de la gestión de los propios Servicios Web; por tanto puede entenderse como una aplicación o una extensión de MUWS. II-C. AWSE AWSE (Autonomic Environment - Entorno de Servicios Web Autónomos) [12] se presenta como un sistema de auto-gestión que permite asegurar un determinado Acuerdo de Nivel de Servicio (SLA) [13]. AWSE está compuesto por varios elementos dentro de los cuales se definen: Servidores de bases de datos, Servicios Web, Servidores HTTP, Repositorios de Información, Servicios Web de Gestión y un Site Manager o Gestor centralizado, tal y como se muestra en la Figura 2. Además se colocan los Elementos de Géstión o Elements entre el Servicio Web y el DBMS para recuperar información de los recursos. Figura 2. Arquitectura AWSE sobre un recurso de base de datos. La arquitectura AWSD está basada en el estándar [12], siendo en el ejemplo, el recurso una base de datos. Figura 3. AWSE mejorado con. Figura tomada de [12] El principal problema de AWSE es que no define el tipo de capacidades de Autonomic Computing que se consiguen con esa arquitectura. Además, el estándar se centra en la auto-gestión de recursos, obviando la obtención de estas capacidades en los Servicios Web. III. MODIFICACIÓN DEL MARCO AWSE Para conseguir capacidades de Computación Autónoma sobre recursos y servicios, suele recurrirse a una técnica de replicación de elementos combinada con un bucle de monitorización [15]. En un entorno de agregación de recursos como puede ser un cluster [25], una red P2P [26] o un grid [27] puede plantearse la replicación de recursos para completar la disponibilidad de éstos en nuestro escenario. Sin embargo, trabajando con Servicios Web no disponemos de un conjunto grande de recursos y nos centraremos solamente en realizar la replicación de los servicios básicos sobre un mismo recurso (en el dominio del proveedor). Los motivos principales que permiten pensar en esta replicación son su bajo ciclo de vida y el escaso acoplamiento. Por tanto colocaremos Servicios Web de Gestión Distribuidos de acuerdo con el estándar para obtener información del estado de los Servicios Web. La información de estado se recogerá en un Gestor Centralizado o (Site Manager). El Site Manager estará regido por una política de gestión manual indicando el grado de replicación que tienen que tener los Servicios Web asociados al recurso. En caso de que se produzca un fallo en una máquina sobre la que se ejecuta el Servicio Web correspondiente, el Site

4 4 Manager podrá decidir ejecutar otra replica ya preparada en los recursos del proveedor de servicios básicos. La Figura 4 muestra la replicación de un Servicio Web para permitir el acceso a una misma base de datos. En caso de fallo del sistema donde se encuentran los servicios se encontrará una réplica transparente de ese Servicio Web. La utilización de la réplica adecuada se lleva a cabo mediante la actualización del Servicio de Descubrimiento (Discovery Service) por parte del Manager Site tras detectarse un fallo en el sistema. SITE MANAGER Discovery Service rancia a fallos. Con la modificación propuesta existe selfhealing sobre los Servicios Web, ofreciéndose de forma transparente este servicio sobre un recurso, a pesar de que se produzcan fallos en el Servicio Web. En ese momento puede desplegarse un nuevo servicio en una máquina del proveedor, pero siempre asociado a un único recurso. Al no haber replicación de recusos, en caso de un fallo no será solucionable con esta propuesta de Computación Autónoma. Self-adapting: En la propuesta original de AWSE no se comenta cómo se consigue self-adapting. Sin embargo, sí que se recogen los parámetros de estado del recurso asociado y también con la modificación, los del Servicio Web. A partir de ello, pueden obtenerse los valores de carga del servicio para iniciar una nueva instancia y despliegar otro Servicio Web asociado. Self-optimizing: De manera similar a la capacidad anterior, la obtención de datos específicos sobre un servicio o recurso puede suponer la posibilidad de disminuir el grado de replicación de los Servicios. Del resto de Capacidades de Computación Autónoma se asume que el sistema no es capaz de aportar nada para su consecución. WEB SERVICE WEB SERVICE WEB SERVICE RESOURCE Figura 4. Replicación de servicios Web en el entorno AWSE-. Para conocer el estado en el que se encuentra un nodo se utilizan notificaciones periódicas, con la información tanto del recurso según el estándar, como del propio Servicio Web. Para ello se utilizan los Modelos de Intercambio de Mensajes (MEPs), incluyendo el identificador del servicio, el estado en el que se encuentra (disponible o no), su descripción (que será almacenada en el Servicio de Descubrimiento), y su relación con el recurso. IV. ESTUDIO DE LAS CAPACIDADES DE COMPUTACIÓN AUTÓNOMA PARA LA MODIFICACIÓN DE AWSE Dentro de las cinco capacidades principales de Computación Autónoma (self-configuring, self-optimizing, self-healing, selfprotection, self-adapting), se plantea un estudio de en qué medida pueden obtenerse con la aproximación modificada de AWSE. Self-healing: Con la versión original de AWSE no puede consiguirse esta capacidad de auto-recuperación o tole/- V. SERVICIO DE ALMACENAMIENTO AUTO-GESTIONADO Para poner en práctica el entorno AWSE modificado se plantea un escenario como el de la Figura 4 en el cual el recurso principal es un disco de almacenamiento. Los parámetros y métricas principales del disco son: su capacidad, su utilización, su carga, y el número de peticiones simultáneas. Gracias al entorno AWSE basado en DCMS podemos obtener los parámetros de medida mediante eventos y de forma instantánea. Además se plantea la posibilidad de obtener capacidades de Computación Autónoma mediante la replicación de Servicios Web para el acceso al disco de almacenamiento. Las métricas de estos servicios son: la tasa de transferencia, el número de peticiones en cola, y la disponibilidad. Atendiendo al grado de peticiones pueden establecerse estrategias de self-adapting y self-optimizing desplegando o liberando servicios asociados al recurso de almacenamiento. En caso de fallo en uno de estos recursos se envía un evento al Site Manager para solicitar una nueva replica, atendiendo al grado introducido manualmente, y actualizando el Servicio de Descubrimiento. Mientras tanto el usuario del servicio continúa utilizandolo de forma transparente. La mejora sobre otro tipo de soluciones de Computación Autónoma, está en la utilización de un estándar como para la transferencia de mensajes entre recurso, servicio y Site Manager, y en la replicación de servicios básicos dentro de los recursos del proveedor, como añadidura a AWSE, consiguiendo así definir las capacidades de self-healing, selfadapting y self-configuring.

5 5 VI. CONCLUSIONES Y LÍNEAS FUTURAS El éxito de los sistemas de Computación Autónoma depende del contexto en el que se apliquen y de los requisitos de las capacidades deseadas. En el caso de los sistemas distribuidos y en especial los basados en servicios, su importancia aumenta, por la dificultad para un administrador humano de tratar con diferentes políticas de gestión, debido sobretodo a la composición de los servicios. Como desafío principal de los Servicios Web, la Computación Autónoma debe integrarse en los estándares aceptados de gestión, en este caso. Es por ello que se buscan propuestas relacionadas a las cuáles se puedan aportar mejoras; en este caso no estaba claro que tipo de capacidades podían conseguirse y tampoco eran aplicables a los propios Servicios Web como abstracción de los recursos. Es por ello que se propone un modelo en el que se aprovechan los recursos del propio proveedor para ofrecer replicación y un bucle de monitorización de los servicios. El proveedor de servicios puede desear incluir las características de Computación Autónoma en el paquete de servicios que ofrezca al usuario (generalmente con un determinado coste adicional); con ello se asegura una mayor fiabilidad e integridad de los recursos, así como la transparencia ante fallos en los Servicios Web. Por otra parte como línea futura puede proponerse la replicación de los propios recursos. Para ello sería necesario estudiar tecnologías de compartición como puede ser el grid. Además, habría que ver cómo el estándar puede adaptarse a ésta y otras tecnologías. REFERENCIAS [1] Horn, P. Autonomic computing: IBM s perspective on the state of information technology. Technical report, IBM Corporation, October [2] Ganek, A. G. Corbi, T. A. The Dawning of the Autonomic Computing Era. IBM System Journal, 42(1):5 19, [3] Jin, L-J. Machiraju, V and Sahai, A. Analysis on Service Level Agreement of s. HP. Technical Report. HP Laboratories Palo Alto, pages 1 13, [4] Kephart, J.O. Research challenges of autonomic computing. In ICSE 05: Proceedings of the 27th international conference on Software engineering, pages 15 22, New York, NY, USA, ACM. [5] Papazoglou, M.P. Traverso, P. Dustdar, S. and Leymann, F. Serviceoriented computing: State of the art and research challenges. Computer, 40(11):38 45, November [6] Papazoglou, M.P. and Georgakopoulos, D. Service-Oriented Computing. Communications of the ACM, 10(46):24 28, October [7] Vinoski, S. Putting the web into s: s interaction models, part 2. IEEE Internet Computing, 6(4):90 92, July [8] Web services distributed management (wsdm). Last visited: June [9] Oasis. An Introduction to. Committee Draft, February [10] Oasis. s Distributed : Using Web Services (MUWS 1.1) Part 1. Oasis Standard, August [11] Oasis. s Distributed : of Web Services (-MOWS 1.1). Oasis Standard, August [12] Martin, P. Powley, W. Wilson, K. Tian, W. Xu, T. Zebedee, J. The WS- DM of Autonomic Computing: Experiences in Implementing Autonomic s. Software Engineering for Adaptive and Self-Managing Systems, ICSE Workshops SEAMS 07. International Workshop on, pages 9 17, May [13] Tian, W. Zulkernine, F. Zebedee, J. Powley, W. and Martin, P. An architecture for an Autonomic Environment. Proceedings of the Joint Workshop on s and Model-Driven Enterprise Information Systems WSMDEIS (ICEIS 2005). Miami, Florida, pages 54 66, May, [14] Zulkernine, F. Powley, W. Tian, W. Martin, P. Xu, T. and Zebedee, J. An Autonomic s Environment using a Reflective and Database- Oriented Approach. Ubiquitous Computing and Communication Journal, Special Issue on Autonomic Computing Systems and Applications, UBICC., [15] Popov, K. Höglund, J. Brand, P. Al-Shishtawt, A. Vlassov, V. and Parlavantzas, N. Design of a self-application using P2P-based management infrastruture. Proceedings of CoreGRID 2008 Integration Workshop (in press), [16] Bruneton, E. Coupaye, T. and Stefani, J.B. The Fractal component model. Technical report, France Telecom R&D and INRIA, February [17] Nami, M.R. and Bertels, K. A Survey of Autonomic Computing Systems. Autonomic and Autonomous Systems, ICAS07. Third International Conference on, pages 26 26, June [18] Agarwal, M. Bhat, V. Liu, H. Matossian, V. Putty, V. Schmidt, C. Zhang, G. Zhen, L. Parashar, M. Khargharia, B. and Hariri, S. AutoMate: enabling autonomic applications on the grid. Autonomic Computing Workshop, 2003, pages 48 57, June [19] Sterritt, R. Parashar, M. Tianfield, H. and Unland, R. A concise introduction to autonomic computing. Advanced Engineering Informatics, 19: , January [20] Lohman, G.M. and Lightstone S. SMART: making DB2 (More) autonomic. In VLDB 28th International Conference on very large Data Bases, pages 20 23, Hong-Kong, China, August [21] Kaiser, G. Parekh, J. Gross, P. and Valetto, G. Kinesthetics extreme: an external infrastructure for monitoring distributed legacy systems. Autonomic Computing Workshop, 2003, pages 22 30, June [22] OASIS, WS-Addressing standard. Last visited: June [23] Oasis. URL: Last visited: June [24] OASIS, WS-Base Notification standard. URL: docs.oasisopen.org/wsn/wsn-ws_base_notification-1.3-spec-os.pdf Last visited: July [25] Bouchenak, S. Boyer, F. Hagimont, D. Krakowiak, S. Mos, A. de Palma, N. Quema, V. and Stefani, J.B. Architecture-based autonomous repair management: an application to J2EE clusters. Reliable Distributed Systems, SRDS th IEEE Symposium on, pages 13 24, October [26] Milojicic, D.S. Kalogeraki, V. Lukose, R. Nagaraja, K. Pruyne, J. Richard, B. Rollins, S. and Xu, Z. Peer-to-Peer Computing. Technical report, HP Laboratories Palo Alto, Approved for External Publication. [27] Foster, I. and Kesselman, C. The Grid: Blueprint for a New Computing Infrastructure. Morgan Kaufmann Publishers, November 1998.