Tolerancia a fallas adaptable

Transcripción

1 Tolerancia a fallas adaptable Mario Isauro Martínez 1 y Elizabeth Pérez Cortés 2 1 Telmex. Ingeniería Proyectos y Equipos, misauro@telmex.com 2 UAM-Iztapalapa, Av. San Rafael Atlixco No. 186 Col. Vicentina C.P México D.F. pece@xanum.uam.mx Resumen. La construcción de aplicaciones distribuidas tolerantes a fallas es una tarea compleja dada la cantidad y la naturaleza de los elementos que las integran. La tendencia actual es dejar las tareas no aplicativas a cargo al middleware y nuestro trabajo la sigue en el caso específico de la tolerancia a fallas. Nuestra propuesta además estipula la posibilidad de adaptar el soporte brindado por el middleware a los requerimientos de la aplicación. El programador debe simplemente indicar qué componentes de la aplicación deben tolerar fallas y que tipo de tolerancia deben observar. A partir de esa información, el sistema se configura para integrar los mecanismos necesarios. En este artículo se presenta un caso de estudio en donde el programador señala los componentes que serán tolerantes a fallas y eso se traduce, sin intervención del programador, en una implementación que permitirá a dichos componentes funcionar con un tipo específico de tolerancia a fallas. Palabras clave: Sistemas distribuidos, tolerancia a fallas, componentes, adaptabilidad 1. Introducción Los requerimientos de fiabilidad de una aplicación han aumentado como consecuencia de la utilización generalizada de los sistemas de cómputo en la vida cotidiana. Por esta razón se observa una preocupación creciente por dotar a las aplicaciones de elementos que atenúen o eliminen las consecuencias de las fallas de los elementos que las componen. En el caso de una aplicación distribuida, concebida como un ensamble de componentes 1 que se ejecutan en unidades de cómputo autónomas, este problema se magnifica. Por un lado, debido a la cantidad y la naturaleza de sus componentes, el tipo y la cantidad de fallas aumentan. Por otro lado, dependiendo de muchos factores, la tolerancia a fallas tiene un costo que no se puede imponer a todas las aplicaciones. Finalmente es importante mencionar que la alta complejidad teórica y técnica de los mecanismos de tolerancia a fallas dificulta su programación. La programación por componentes permite proyectar la construcción de middlewares que integren sólo las elementos correspondientes a las tareas que son necesarias a la aplicación. En nuestra propuesta se explora la posibilidad de adaptar a los requerimientos de la aplicación, el soporte de tolerancia a fallas brindado por el 1 Un componente es una unidad de composición con interfaces especificadas contractualmente y dependencias explícitas del contexto solamente [1] [2].

2 middleware. En este artículo se presenta un caso de estudio para evaluar la viabilidad de la propuesta en el contexto del middleware orientado a componentes Séneca. El resto de este artículo está estructurado de la siguiente manera: en la sección 2 se presentan los conceptos básicos de tolerancia a fallas. La sección 3 presenta la propuesta global de integración opcional y adaptable de la tolerancia a fallas. En la sección 4 se describe el caso de estudio y su implementación. En la sección 5 se citan los trabajos similares y finalmente, la sección 6 contiene las conclusiones y las perspectivas de este trabajo. 2. Conceptos básicos de tolerancia a fallas 2.1 Tolerancia a fallas Un sistema tolerante a fallas es aquel que sigue funcionando de acuerdo a su especificación a pesar de las fallas en los elementos que lo integran. Una falla es un evento que ocasiona un mal funcionamiento del sistema. Un sistema tolerante a fallas se construye integrando elementos de detección, encargados de vigilar los componentes del sistema, elementos de notificación que señalan la presencia de una falla y elementos de recuperación que corrigen los efectos de la falla. El impacto de la falla en el funcionamiento de un sistema está en función de cuáles de los elementos mencionados previamente se integraron. Un sistema que no contiene ninguno no puede reaccionar a la falla y simplemente su funcionamiento se desvía. Un sistema que integra elementos de detección y notificación, podrá al menos señalar la falla al usuario del sistema (otro sistema o un ser humano). Si además se cuenta con elementos de recuperación es posible que el sistema vuelva a su funcionamiento normal en algún momento, o mejor aún que nunca exhiba un comportamiento distinto del especificado. Los mecanismos utilizados en ambos casos son diferentes pues en uno se requiere regresar a un estado coherente previo y en el otro tener listo un elemento de reemplazo que tome el lugar del que falló. Clase Subclase Descripción Omisión Omisión de respuesta Respuesta Respuesta incorrecta Valor Valor incorrecto Transición de estado Efectos perniciosos en los recursos Tiempo La respuesta no está a tiempo. Servidor Omisión repetida Amnesia Reinicio en el estado inicial Pausa El servidor reinicia en el edo. antes del crash Paro El servidor NO reinicia Arbitrarias Comportamiento arbitrario Tabla 1. Clasificación de fallas 2

3 Por otro lado, los elementos deben contemplar el tipo de fallas al que se quiere hacer frente. A grosso modo, es posible distinguir dos tipos de fallas, las fallas de concepción que, como su nombre lo indica tienen un origen en esta etapa de la aplicación y las fallas operacionales que tiene un origen material. La tabla 1 describe una de la clasificaciones de fallas operacionales más conocida [3]. Para cada tipo de falla, las técnicas de detección son diversas y los mecanismos de recuperación también. Finalmente mencionamos que la complejidad de un sistema tolerante a fallas depende además del número de fallas de las que el sistema se debe poder recuperar. 3 Integración opcional de la tolerancia a fallas: la propuesta 3.1 Modelo de tolerancia a fallas De acuerdo a lo enunciado en la sección anterior, antes de construir un sistema tolerante a fallas es importante definir: el tipo de fallas que se quiere tolerar, El impacto de cada una de ellas en el comportamiento del sistema y la cantidad de cada una de ellas que el sistema es debe tolerar. Llamaremos a este conjunto de parámetros, el modelo de tolerancia a fallas (MTF) del sistema extendiendo la noción presentada en [4]. Una vez definido el MTF, es relativamente simple determinar los elementos de detección, de notificación y de recuperación que deben incluirse en la aplicación [5]. Además, el MTF también determina la infraestructura mínima para ejecutar un sistema que lo ofrezca. Por ejemplo, no se puede tener un sistema que tolere dos fallas de caída de servidor si sólo se cuenta con dos sitios. En otros términos, no todos los MTF se pueden implementar en cualquier infraestructura. 3.2 Granularidad vs. flexibilidad y transparencia En nuestro contexto decimos que una tarea se hace de manera transparente cuando el beneficiario de la tarea no participa en el esfuerzo para llevarla a cabo y consideramos que la flexibilidad de una solución está en proporción directa con la cantidad de variaciones que permite. La tolerancia a fallas puede ser provista considerando: a) un MTF para toda la aplicación o b) un MTF por componente. Mientras que la opción a) tiene la ventaja de ser absolutamente transparente para el constructor de aplicaciones, la opción b) le deja a cargo la responsabilidad de decidir cuáles componentes son tolerantes a fallas y cuáles no. Por otro lado, la opción a) carece de flexibilidad mientras que en la b) muchos esquemas diferentes tienen cabida por lo que es posible hacer convivir componentes con distintos comportamientos frente a las fallas. Por estas razones, en este trabajo se explora la opción b) 2. 2 La opción a) fue explorada en [5]. 3

4 4 El caso de estudio y su implementación 4.1 La granularidad, el MTF y los mecanismos En este caso de estudio los programadores indican cuales componentes son tolerantes a fallas. El MTF observado por esos componentes es: MTF={Falla de servidor pausa, recuperación de la falla después de un tiempo, 1} Para soportar el modelo anterior es necesario detectar la falla de servidor lo que se hace a partir de fallas repetidas de omisión. La recuperación se hace utilizando redundancia pasiva simple. Cada componente tiene una copia colocada en un sitio distinto. Las invocaciones llegan tanto al sitio donde está el componente como al sitio en donde está la copia. La coherencia entre las dos copias del componente se conserva utilizando la técnica del respaldo primario [6]. Una de las copias (primaria) ejecuta todas las invocaciones mientras que la otra (secundaria) almacena en una bitácora todos los llamados. Periódicamente la copia primaria envía su estado a la secundaria y la bitácora se purga. En caso de una falla, la copia se actualiza ejecutando las invocaciones contenidas en la bitácora. Dado que el modelo de toleracia a fallas contempla las caídas de tipo pausa, eventualmente el componente que falló regresa. En ese caso, el componente se reintegra como la copia secundaria. 4.2 Séneca: el modelo de componentes a utilizar Séneca [7] es un modelo a componentes en donde cada componente puede tener varias instancias que pueden ser compartidas por varios clientes y ser persistentes. Séneca-J es la implementación de Séneca basada en Java y los componentes se comunican entre sí utilizando la tecnología RMI. Séneca se compone de 3 submodelos: abstracto: que permite definir los componentes de una aplicación y las interfaces que cada uno contiene. programación: permite definir la implementación de las interfaces así como especificar si se trata de componentes persistente y/o compartidos. ensamblado y desplegado: permite definir el nombre de instancias y el lugar donde serán creadas además de las conexiones entre las instancias. 4.3 Implementación: Séneca-j tolerante a fallas Para soportar el MTF especificado y con los mecanismos elegidos se agregaron a la arquitectura de Seneca-j los siguientes elementos: Expresión del MTF: Una palabra clave TAF que califique a los nombres de los componentes tolerantes a fallas. Manejador de Tolerancia. Este elemento se duplica en todos los sitios en donde hay componentes instanciados. Intercepta las invocaciones dirigidas al 4

5 componente primario y las envía al sitio de la copia secundaria. Coordina la actualización periódica de la copia secundaría. También es el encargado de la detección y recuperación de un componente que presenta una falla. Manejador de Bitácora. Este es elemento encargado de la asignación, creación, eliminación, modificación y administración de la bitácora que requiere el Manejador de Tolerancia para cumplir su objetivo. Manejador de tolerancia del cliente. Elemento del lado del cliente (con el nombre del componente), que oculta la existencia de las copias. Además se modificó el compilador del modelo de programación para detectar la palabra TAF y preparar la creación del componente secundario correspondiente. Por otra parte se modificó el compilador del modelo de ensamblado y desplegado para instanciar y desplegar los componentes en los sitios correspondientes; asegurando que las copias estén en sitios distintos a los de los componentes primarios. La existencia de las réplicas es completamente transparente tanto al programador como a los clientes. Se programaron dos aplicaciones distribuidas simples que corroboraron el correcto funcionamiento de los mecanismos. Los detalles de todo el trabajo se pueden encontrar en [8]. 5 Trabajos relacionados Como se constató en el estudio realizado en [8]. La mayoría de los middlewares ofrecen mecanismos limitados para la tolerancia a fallas. Con frecuencia se trata sólo de mecanismos de excepciones que permiten detectar algún mal funcionamiento y tomar alguna acción al respecto. Tal es el caso de PVM, MPI y EJB. O bien, como en el caso de DCOM se cuenta además con un mecanismo de monitoreo de objetos (ping). Por su parte la OMG en la especificación de Corba Tolerante a Fallas [9] define el dominio de tolerancia a fallas como un conjunto de sitios y objetos. Todos los grupos de objetos dentro del dominio de tolerancia comparten las mismas características de tolerancia a fallas. 6 Conclusiones y perspectivas Habiendo constatado que la mayoría de los middlewares no integran mecanismos de tolerancia a fallas y que, cuando lo hacen, no son lo suficientemente flexibles o completos, en este artículo se explora la posibilidad de especificar las necesidades de tolerancia a fallas de una aplicación y que a partir de esa especificación, el middleware integre los elementos necesarios para soportar dichas necesidades descargando al programador de esa tarea. Se presentó un caso de estudio que valida la propuesta utilizando un MTF que contempla una falla de servidor cuyo impacto es eliminado a cabo de un tiempo no acotado. La propuesta se integra en Séneca-J. En este caso de estudio, utilizamos los 5

6 resultados previos [5] para identificar los elementos a integrar una vez definido el MTF y comprobamos que la estrategia es plausible. El caso de estudio arroja dos resultados importantes: El primero concierne las arquitecturas de los middlewares que deben contemplar la posibilidad de un cambio en sus funciones como consecuencia de la inclusión de una tarea no funcional. Es decir, es necesario que el middleware esté construido por componentes que puedan ser reemplazados por otros. El segundo resultado tiene que ver con la arquitectura propuesta pues la eficiencia de la solución es pobre. La arquitectura propuesta hace que cada invocación se multiplique aun en el caso de la ausencia de fallas. Una posibilidad sería trabajar en la integración de las tareas sin perder claridad en la distribución de las mismas. Cabe mencionar que la tolerancia a fallas requiere para funcionar de otras tareas del middleware como el monitoreo, la duplicación y el balance de carga entre otros. En nuestro grupo de trabajo cada uno de ellos ha sido objeto de una reflexión como la aquí presentada y se trabaja actualmente sobre la integración de todos estas funcionalidades en una sóla plataforma. Agradecimientos. Al CONACYT que a través del proyecto A financión este trabajo y a Rubby Casallas G. por facilitarnos Séneca para la implementación de la propuesta. Referencias [1] Valecillo, Lección 1: Desarrollo de Software Basado en componentes, Dept. Lenguajes Y Ciencias de la Computación, Universidad de Málaga, España 2001 [2] C. Szyperski y C. Pfister. Summary of the Workshop on Component Oriented Programming (WCOP 96). En Muhlhauser, M. (ed.), Special Issues in Object-Oriented Programming. Workshop Reader of ECOOP 96. Dpunkt Verlag. [3] Cristian F., Understanding Fault Tolerant Distributed Systems, Comms. of the ACM, 34(2), 56-78, [4] P. Duong, E. Pérez Cortés, About reliability level expression, Intl Symposium and School on Advanced Distributed Systems, , Guadalajara México, 2002 [5] P. Duong, E. Pérez Cortés, Tolérance aux fautes adaptable pour les systèmes a composants, Technique et Science Informatiques, 23(2), Hèrmes. [6] M. Wiesmann, F. Pedone, A. Achiper, B. Kemme, G. Alonso, Understanding Replication in Database and Distributed Systems, IEEE /00, [7] R. Casallas, J. Arias y G. Vega, Modelo Séneca, Bogotá Colombia, [8] M. E. Isauro Martínez, La Tolerancia a Fallas Opcional en el Middleware, Tesis de Maestría en Ingeniería (Computación), UNAM, México, Noviembre [9] OMG, Fault tolerant Corba, Technical Repport, Object Management Group Technical committee Document formal/ , junio