Actualidad

Revista del Instituto Tecnolgico de Informtica

COPLA: Replicacin de BBDD Relacionales

El empleo de bases de datos por cualquier empresa est sometido a posibles prdidas de informacin y suspensiones de los servicios en caso de fallo de algn equipo. La replicacin permite mejorar la tolerancia a este tipo de incidencias. COPLA es un sistema de replicacin de bases de datos relacionales y proporciona el soporte necesario para el desarrollo de aplicaciones Java. El sistema ofrece diversos protocolos de consistencia, configurables dependiendo del modo de funcionamiento del sistema y de las aplicaciones que hagan uso del mismo.

Motivacin Las bases de datos son el medio ms comnmente utilizado para almacenar la informacin que una empresa genera y emplea en sus aplicaciones de gestin. Para garantizar la durabilidad de tal informacin se suele recurrir a una poltica de generacin de copias de seguridad peridicas, que seran empleadas en caso de fallo para regenerar de nuevo la base, minimizando as las prdidas de informacin. El empleo de estas tcnicas implica un coste econmico muy bajo, pues los dispositivos y medios de almacenamiento necesarios para ello llevan ya mucho tiempo en el mercado y su fiabilidad est plenamente garantizada. Sin embargo, cuando uno de los equipos falla y hay que recurrir a la recuperacin de la base de datos perdida, puede que necesitemos ms recursos o ms tiempo del inicialmente previsto. Todo depende de lo que haya llegado a fallar: puede ser el disco donde se mantena la base, algn otro componente de ese mismo ordenador, o incluso el ordenador completo (en caso de incendio, por ejemplo). Lo ideal sera tener un repuesto de la pieza que haya podido fallar, pero eso no siempre ocurrir. El plazo necesario para adquirirla, arreglar el ordenador y recuperar el estado de la base de datos podra implicar que la empresa fuera incapaz de proporcionar sus servicios, aunque sean de naturaleza interna (contabilidad, gestin de almacn, gestin de clientes, gestin de proveedores, etc.), durante un tiempo apreciable. Adems, la ltima copia de seguridad que se guard no evitar que se hayan perdido todos los datos modificados en la base desde el momento de realizacin de dicha copia hasta el momento del fallo. Esto implicara que todas las transacciones llevadas a cabo durante ese plazo, tendran que ser realizadas de nuevo. Con algo de suerte todava podramos disponer de las fuentes de informacin necesarias para poderlas repetir, pero aun as, sera una tarea que a nadie le gustara realizar. Una solucin ligeramente mejor consiste en replicar las bases de datos empleadas por la empresa. En lugar de guardar una sola copia de cada base en el ordenador que normalmente se emplea para procesar su informacin, podemos mantener un nmero mayor de copias. Por ejemplo, en lugar de tener una base para cada departamento de la empresa, manteniendo en cada una de ellas slo la informacin de su departamento propietario, podramos tener el mismo nmero de bases, pero replicadas tantas veces como departamentos haya. Es decir, cada departamento guardara su propia informacin ms una copia adicional de la informacin de todos los dems departamentos. Para empresas mayores, con varios centros o sucursales, la divisin podra hacerse por sucursal, en lugar de por departamento. Hay que observar que esto no implica un coste econmico excesivo, pues no se necesita

La replicacin de BBDD permite mejorar la disponibilidad de la informacin sin un gran coste adquirir un mayor nmero de equipos informticos, sino aumentar ligeramente su capacidad de almacenamiento. De esta forma, al emplear replicacin, si uno de los ordenadores fallara, slo se perdera momentneamente una de las rplicas de la informacin. El resto de copias continuara disponible y permitira que los servicios que puedan depender de tal informacin sigan funcionando correctamente. Adems, mientras no se den situaciones de fallo, el mantenimiento de dichas copias puede conllevar un ligero aumento de las prestaciones del sistema. Esto se debe a que no es raro que desde un equipo necesitemos, de vez en cuando, acceder a la informacin presente en la base de datos de otro equipo de la empresa. Para ello, deberemos iniciar una transaccin sobre el SGBD remoto, y para atenderla necesitamos la colaboracin de nuestro equipo local, el servidor remoto y el uso de cierto ancho de banda en la red. Si estos accesos se realizan sobre una base de datos totalmente replicada, podrn atenderse de manera puramente local. Con ello, para las transacciones de solo lectura se puede proporcionar una elevada capacidad de servicio replicando la base de datos, aumentando de esta manera la concurrencia para este tipo de accesos y reduciendo tambin su tiempo se respuesta. El grupo de sistemas distribuidos del Instituto Tecnolgico de Informtica, junto a otros grupos de investigacin nacionales y extranjeros y algunas empresas interesadas, ha desarrollado un sistema de replicacin de bases de datos relacionales llamado COPLA, producido en el proyecto de investigacin GlobData (accesible en la URL: http://globdata.iti.es, enero 2004) financiado por el V Programa Marco de la Unin Europea. En este artculo describiremos el sistema COPLA, as como las ventajas que reportara el uso de una arquitectura de soporte a replicacin de bases de datos como la proporcionada en COPLA. El sistema COPLA El sistema COPLA est estructurado en tres niveles distintos tal como muestra la Figura 1. Estos niveles estn implantados en Java y pueden estar ubicados en mquinas distintas, pues se intercomunican

Actualidad
Revista del Instituto Tecnolgico de Informtica

COPLA: Replicacin de BBDD Relacionales

utilizando un O.R.B. A continuacin se describen con cierto detalle sus distintas funciones. 1. Biblioteca Facilita una interfaz orientada a objetos de la base de datos relacional. Para este fin se adopta una interfaz compatible con el estndar ODMG. Esto permitir un acceso ms sencillo a la base de datos desde una aplicacin orientada a objetos, como puedan ser todas aquellas escritas en el lenguaje Java. Ntese que aquellas aplicaciones escritas en Java necesitan normalmente utilizar la interfaz JDBC para tener acceso a una base de datos relacional. Esto implica que los programadores necesitarn hacer un esfuerzo adicional en sus aplicaciones para trasladar un diseo orientado a objetos (el realizado en la aplicacin) hacia una interfaz plana, como es la proporcionada por JDBC.
Biblioteca

Gestor COPLA

Protocolo de consistencia y subsistema de comunicacin

ser el encargado de elegir el protocolo ms adecuado para cada aplicacin que vaya a usarse, dependiendo de los parmetros que se desee optimizar: rendimiento, ratio de abortos, etc. Por otra parte, el mdulo que implanta al protocolo de consistencia es el nico encargado de la comunicacin entre las diferentes rplicas (es decir, entre los diferentes ordenadores) que componen un sistema COPLA. Debido a esto, junto al protocolo de consistencia existe otro mdulo encargado de la gestin de la comunicacin entre los nodos. Este nuevo mdulo tiene que implantar protocolos de difusin de actualizaciones y tiene que monitorizar el estado de cada uno de los nodos, con el objetivo de detectar las cadas o recuperaciones de stos tan pronto como sea posible y reconfigurar entonces el sistema para que pase a manejar adecuadamente su nueva composicin. Para ello, este mdulo de comunicaciones implanta algn protocolo de pertenencia y el protocolo de consistencia tambin tendr incluido uno o ms subprotocolos de recuperacin. Con esto se lograr que el sistema resultante pueda manejar automticamente cualquier situacin de fallo o recuperacin de uno o ms de los ordenadores que componen el sistema COPLA. 3. Uniform Data Store El nivel inferior es el responsable de proporcionar al Gestor COPLA una imagen orientada a objetos de la base de datos relacional que se est utilizando realmente como Sistema Gestor de Bases de Datos (SGBD). Por tanto, UDS se encarga de ocultar los detalles relacionales y ofrecer una imagen uniforme para el gestor, independientemente de la base de datos que tengamos. Actualmente se dispone de un UDS para las ltimas versiones de PostgreSQL, aunque no sera excesivamente difcil desarrollar componentes equivalentes para otros SS.GG.BB.DD. El rendimiento final obtenido con esta arquitectura depende en gran medida del tipo de protocolo de consistencia que se est empleando. En la prxima seccin estudiaremos en detalle las tcnicas bsicas de replicacin de bases de datos empleadas hoy en da. Replicacin de bases de datos Las tcnicas de replicacin de bases de datos se suelen clasificar en funcin del instante empleado para propagar las actualizaciones generadas en cada transaccin. Tendremos as dos tipos de protocolos: 1. Replicacin perezosa En estos protocolos las actualizaciones, si hubo alguna, se propagan al resto de rplicas una vez la transaccin original ya ha terminado exitosamente. De esta manera, se minimiza el tiempo de respuesta de cada transaccin pues no ha sido necesaria la propagacin de las actualizaciones para darla por terminada, y se mejora el rendimiento del sistema. No obstante, esto puede conducir a que
9

Uniform Data Store

Figura 1: Niveles del sistema COPLA

Est claro que el estndar ODMG no suele ser conocido por los programadores con experiencia en el lenguaje Java, pero una vez habituados a l, el desarrollo de aplicaciones con acceso a bases de datos se puede simplificar bastante. Como resultado, las aplicaciones desarrolladas una vez ya conocida la interfaz requerirn mucho menos cdigo que las desarrolladas sobre JDBC. 2. Gestor COPLA Es el componente central de la arquitectura y sobre l recae la responsabilidad de la gestin de cachs, para optimizar el acceso a la base, y la del mantenimiento de la consistencia entre las diferentes rplicas. Hay que advertir que el mantenimiento de la consistencia no es una tarea trivial. De hecho, precisa la utilizacin de algn protocolo especfico que mediante unas reglas determinadas asegure que todas las rplicas realicen las actualizaciones de la informacin en el mismo orden, evitando o detectando los conflictos que puedan darse entre diferentes nodos que traten de acceder concurrentemente a los mismos registros y al menos en uno de los nodos en modo escritura. Por esta razn, el gestor COPLA admite la instalacin de diferentes protocolos de consistencia, internos al propio gestor. Estos protocolos podrn adoptar diferentes estrategias a la hora de garantizar la consistencia de la informacin, como veremos en la seccin 3. As, el administrador

Actualidad
Revista del Instituto Tecnolgico de Informtica

COPLA: Replicacin de BBDD Relacionales

se incremente excesivamente el ratio de transacciones abortadas, pues se est incrementando peligrosamente la probabilidad de que una transaccin acceda a un dato que presente un estado desactualizado. Esta estrategia ha sido empleada en algunos SS.GG.BB.DD. comerciales. Para evitar un incremento excesivo del ratio de transacciones abortadas deben disearse protocolos de reconciliacin de transacciones, capaces de mezclar las actualizaciones dadas por dos transacciones que hayan modificado de manera conflictiva un mismo elemento de la base, pero que fueron confirmadas en distintos nodos debido a que no pudo comprobarse adecuadamente la existencia de tal conflicto. Este tipo de replicacin difcilmente puede garantizar la consistencia secuencial (one-copy serializability) de la base de datos. Sin embargo, muchas aplicaciones no necesitan un tipo de consistencia tan estricto. De hecho, la mayor parte de las bases de datos comerciales utilizan por omisin un nivel de aislamiento ms relajado (ejemplos tpicos son los modos read committed, en el cual una transaccin puede ver de inmediato lo que otras transacciones que acaban de terminar han modificado, y el modo repeatable read, algo ms estricto, garantizando que siempre que leamos un dato el valor obtenido coincidir con el visto en anteriores lecturas) lo cual conduce forzosamente a una consistencia tambin ms dbil. Todo esto hace que sea factible disear protocolos de replicacin perezosa que garanticen modos de consistencia relajados, pero todava vlidos para un buen nmero de aplicaciones. 2. Replicacin vida En estos protocolos las actualizaciones, en caso de haberlas, se propagan al resto de rplicas antes de que la transaccin original haya sido completada. Empleando este principio resulta bastante ms fcil proporcionar consistencia secuencial, pero tambin se necesitan protocolos de difusin de actualizaciones bastante ms complejos. Los protocolos que se pueden disear en esta rea, pueden ser clasificados (M. Wiesmann et al., 19th IEEE Symposium on Reliable Distributed Systems, 2000, pg. 206) en funcin de tres criterios distintos, todos ellos con dos opciones disponibles: 1. La rplica que podr realizar las actualizaciones. Algunos algoritmos exigen que solo una de entre todas las rplicas pueda procesar en primer lugar aquellas transacciones que impliquen una modificacin del estado de un registro determinado. A esta rplica se la llama Rplica primaria (RP), y por extensin, tambin llamaremos de igual manera a los protocolos de consistencia que utilicen este principio. Una vez la transaccin ha sido procesada por la rplica primaria, ya se podrn difundir sus actualizaciones al resto de rplicas. Esta aproximacin tiene la ventaja de que para cada elemento de la base de datos resultar muy sencillo realizar su control de concurrencia, pues todos los accesos que impliquen modificaciones sern encaminados al mismo lugar. La segunda opcin para este mismo criterio ser permitir las actualizaciones en cualquier rplica. A esta solucin vamos a llamarla Cualquier rplica (CR). Obviamente es mucho ms flexible y simtrica que la anterior, conduciendo generalmente a un mejor equilibrado de la carga en el sistema. No obstante, plantea el problema de tener una mayor complejidad para realizar el control de concurrencia. 2. Cmo y cuando interactan las rplicas para procesar una transaccin. Por ser protocolos de replicacin vida, las actualizaciones deben difundirse antes de que haya finalizado el proceso de commit, pero se pueden distinguir dos aproximaciones a la hora de llevar a cabo tales difusiones. La primera consistira en realizar una interaccin lineal (IL), es decir, las rplicas van colaborando durante el proceso de la transaccin, tantas veces como sea necesario. La segunda opcin se llama interaccin constante (IC) y exige que el nmero de interacciones se fije a priori, normalmente a un solo intercambio de informacin o, al menos, a un nmero reducido de ellos. Esto puede conseguirse si se van acumulando todas las actualizaciones realizadas durante una transaccin y se difunden al final hacia el resto de rplicas, durante la fase de commit. 3. Cmo se decide el xito o aborto de la transaccin. En algunos protocolos puede ser necesaria una ltima ronda de votacin para que cada rplica colabore en la decisin sobre el xito o fracaso de la transaccin en curso. Esta aproximacin recibe el nombre de Terminacin con votacin (CV). De hecho, una transaccin podra ser abortada si en una rplica ha llegado a entrar en conflicto con otra transaccin local que ya hubiera sido confirmada. Sin embargo, la mayora de los protocolos utilizan criterios donde se asigna mayor prioridad a las transacciones remotas, con el objetivo de reducir el nmero de abortos de aquellas transacciones que ya hayan llegado a un estado de ejecucin ms avanzado. La opcin complementaria consiste en que el protocolo tenga suficiente informacin para poder decidir localmente sobre la terminacin de una transaccin, eliminando as la necesidad de una votacin final. Esta aproximacin recibe el nombre de Terminacin sin votacin (SV). Combinando los tres criterios, obtendramos ocho tipos posibles de protocolos, cuyas opciones seran, respectivamente: RP-IL-SV, RP-IL-CV, RP-IC-SV, RP-IC-CV, CR-IL-SV, CR-IL-CV, CR-IC-SV y CR-IC-CV. El objetivo de cualquier protocolo de consistencia vido debera ser, aparte de garantizar una menor tasa de abortos que los protocolos de consistencia perezosos, minimizar el tiempo de respuesta de sus transacciones, as como proporcionar una buena escalabilidad. Esto ltimo no es sencillo y depende en gran medida de los costes de los protocolos de difusin de actualizaciones, as como del porcentaje de transacciones de escritura que tenga una aplicacin. Para lograr todos estos objetivos, la mejor combinacin existente sera aquella que utilizara cualquier rplica para iniciar las actualizaciones, interaccin constante entre las rplicas para reducir los costes de comunicacin y mejorar la escalabilidad, y sin votacin para reducir as el tiempo de respuesta. No obstante, esta combinacin no siempre se podr lograr y en algunos casos hay que optar por la opcin menos favorable en uno o ms criterios. Protocolos utilizados en COPLA El sistema COPLA ofrece cuatro protocolos de consisten-

Actualidad
10

Actualidad
Revista del Instituto Tecnolgico de Informtica

COPLA: Replicacin de BBDD Relacionales

cia bsicos entre los que podra elegirse el ms adecuado para cada aplicacin, segn sus necesidades. Actualmente slo se permite tener un protocolo de consistencia en funcionamiento, comn para todas las aplicaciones que accedan a la base de datos replicada. No obstante, el administrador del sistema podr reemplazar el protocolo en uso cuando lo estime ms conveniente, por ejemplo, si la aplicacin hubiera sido modificada ligeramente y el tipo de carga que debiera soportar hubiera cambiado. De entre estos protocolos disponibles, existen tres de tipo vido y uno mixto, es decir, en funcin de su configuracin puede comportarse tanto de forma vida como perezosa. La naturaleza de este protocolo lo har muy atractivo para la mayora de aplicaciones, pues si nos interesa el rendimiento podremos configurarlo como protocolo perezoso. En esta variante el protocolo es capaz, utilizando frmulas internas basadas en informacin local, de predecir con bastante precisin si un elemento debe ser actualizado desde su rplica propietaria antes de atender una peticin de lectura sobre l. Con esto se ha logrado que este protocolo rebaje su tasa de abortos a unos valores muy cercanos a los de los protocolos vidos, facilitando an un tiempo de respuesta bastante inferior al de stos. Por su parte, los protocolos vidos emplean tanto las combinaciones CR-IC-CV como CR-IC-SV, proporcionando los mejores resultados posibles tanto en el tiempo de servicio como en la tasa de transacciones abortadas. Adems, el protocolo que emplea CR-IC-CV utiliza un protocolo de difusin de actualizaciones que necesita menos rondas de intercambio de mensajes de lo habitual, por lo que su rendimiento es tambin bueno. Conclusiones La replicacin de base de datos permite mejorar la disponibilidad de la informacin gestionada por una empresa, sin necesidad de un gasto econmico importante y, dependiendo del tipo de transacciones utilizadas por las aplicaciones, permite tambin mejorar las prestaciones de estos servicios, reduciendo el tiempo de respuesta de las transacciones de lectura, aunque incrementando ligeramente el de las de escritura. COPLA ofrece un buen sistema de soporte a bases de datos replicadas, proporcionando una interfaz muy sencilla de utilizar en aplicaciones Java. El amplio grupo de protocolos de consistencia soportados por este sistema permite escoger la mejor opcin para cada tipo de aplicacin que deba acceder a la base de datos. Este sistema ya ha sido implantado. Actualmente se ha empezado el desarrollo de una segunda edicin, que dar lugar al sistema MADIS en el que slo se ofrecer una interfaz JDBC hacia las aplicaciones, pero en el que se dar mayor flexibilidad al uso de protocolos, permitiendo el uso de varios de ellos concurrentemente, ofreciendo as la posibilidad de que diferentes aplicaciones puedan utilizar el protocolo mejor adaptado a sus necesidades particulares, en lugar de encontrar el mejor para el conjunto de aplicaciones en uso.

Autor: Francisco D. Muoz Esco Ms informacin: sidi@iti.upv.es

JORNADAS SOBRE TESTEO DE SOFTWARE

El Instituto Tecnolgico de Informtica, en colaboracin con las empresas SOGETI y COMPUWARE, organiza las Primeras Jornadas sobre Testeo de Software, donde se darn a conocer los principales mtodos y herramientas para el desarrollo de software de calidad. Los beneficios que aporta un buen sistema de testeo de software incluyen: cumplimiento de plazos disminucin de errores en el desarrollo e implantacin reduccin de costes mejora en la satisfaccin del cliente
25 y 26 de Marzo Campus de Vera (Univ. Politcnica de Valencia)

los fundamentos del testeo de software y se describirn los procesos bsicos que cada compaa moderna debe implementar para garantizar un nivel de calidad en sus productos. La jornada se dirige a la presentacin y explicacin de tcnicas, modelos y metodologas que se pueden utilizar para llevar a cabo un proceso bsico de testeo. Las jornadas contarn con la participacin de expertos internacionales en el rea de software testing, como el prestigioso Tim Koomen, ganador del European Testing Excellence Award 2003. El precio de la inscripcin (300 euros) incluye comida y documentacin. Traduccin simultnea al castellano.

Estas jornadas pretenden introducir aquellos conceptos bsicos del testeo tiles para cualquier compaa en el mercado actual. Se explicar la importancia y

RA PA N http://www.iti.upv.es/JTS2004 AS I D IPC squac@iti.upv.es R OS IM INSC LT A L

Ms informacin e inscripciones:
11