Experiencias en el uso del symmetric para la replicación de datos en la plataforma educativa ZERA

Experiences in the use of symmetric data replication in educational platform ZERA

Yerandy Manso Guerra^1*, Enrique José Altuna¹, Adrián García Sánchez¹ , Yoandy Pérez Cáceres¹

¹ Universidad de las Ciencias Informáticas. FORTES. {ymguerra, ejaltuna, agciasanchez, yperezc}@uci.cu

*Autor para la correspondencia:ymguerra@uci.cu

RESUMEN

En el presente artículo se analizan las características de despliegue de la plataforma educativa ZERA como sistema distribuido de base de datos, enfatizando en las necesidades de replicación de forma bidireccional. Se tiene como objetivos presentar un análisis de herramientas de replicación de datos efectuado para la selección de la herramienta SymmetricDS, presentando las experiencias adquiridas en su configuración, así como la configuración realizada, agrupándose las tablas de la base de datos en trece niveles para asegurar su integridad referencial y en tres reglas según las condiciones de replicación de la plataforma ZERA. El despliegue se realizó en México con un total de 43 nodos de réplica distribuidos por 6 estados.

Palabras clave: base de datos, plataforma educativa ZERA, replicación, SymmetricDS

ABSTRACT

In this article we analyze the characteristics of deployment ZERA educational platform as distributed database, emphasizing the needs of bidirectional replication system. It objective is to present an analysis of data replication tools made for the selection of the SymmetricDS tool, presenting lessons learned in its configuration and the settings made, grouping tables in thirteen levels to ensure referential integrity and three rules under the terms of replication ZERA platform. The deployment was made in Mexico with a total of 43 nodes distributed in 6 states.

Key words: replication, database, SymmetricDS

Las Tecnologías de la Información y las Comunicaciones (TIC) han evolucionado a un ritmo acelerado empleándose en distintos ámbitos de gran impacto para la sociedad. La educación no se ha visto exenta de los nuevos avances y una muestra fehaciente lo constituye el desarrollo del software educativo, utilizado como soporte a los procesos de enseñanza-aprendizaje. Internet, junto al auge de las tecnologías web ha conseguido que el saber y el conocimiento, productos de la inteligencia colectiva, trasciendan las fronteras de los centros educativos para situarse en cualquier punto de la red, haciendo realidad el "término educación a distancia" (García Aretio, 2001).

La plataforma educativa ZERA perteneciente al Centro de Tecnologías para la Formación (FORTES), en la Universidad de las Ciencias Informáticas (UCI), es desarrollada teniendo presente las necesidades educativas existentes en varios países latinoamericanos y la deficiente infraestructura y conectividad en el sector de la educación, principalmente en países del tercer mundo.

A diferencia de otras plataformas de gestión del aprendizaje (Ariel Clarenc et al., 2013) (Learning Management System o LMS, por sus siglas en inglés), ZERA presenta un modelo de negocio peculiar en el cual los contenidos son diseñados bajo un microdiseño curricular Perez. Este incluye los programas de estudios, periodos lectivos y todo el sistema de evaluación con el que va a contar la entidad educativa.

Uno de los principales requerimientos que se detectaron desde el inicio del desarrollo es brindar la posibilidad al usuario de continuar sus actividades en la plataforma ZERA fuera de la escuela o institución a la que pertenece; problemática que se agravaba debido a la imposibilidad de algunas instituciones docentes de asegurar la conectividad de sus servidores, convirtiéndose en uno de los requisitos imprescindibles para el despliegue y uso de la plataforma ZERA.

Para hacer frente al problema detectado (descentralización de los datos) la información es almacenada en bases de datos locales (Law et al., 1987) (en lo adelante BD) conectadas a través de la red a una BD central, formando un Sistema de Base de Datos Distribuidas (Connolly and Begg, 2005) (en lo adelante SBDD). Teniendo en cuenta las dimensiones de las organizaciones docentes a las que se les brinda soporte y el volumen de datos que son generados, se identifica como una necesidad la introducción de herramientas para la ayuda de la replicación de datos. (ORACLE, 1997)

El presente artículo tiene como objetivos presentar un análisis de herramientas de replicación de datos efectuado para la selección de la herramienta SymmetricDS utilizada en el despliegue de la plataforma educativa ZERA en un entorno real, exponiéndose las experiencias adquiridas en su configuración.

MATERIALES Y MÉTODOS

En la realización de la investigación se utilizaron los siguientes métodos científicos: ]]> •     Histórico lógico: para el estudio crítico de trabajos anteriores. También para comprobar la evolución del fenómeno investigado y el comportamiento de este en una secuencia temporal. Empleado para asumir el conocimiento de antecedentes, causas y otras evidencias históricas en que se aplican métodos y técnicas de replicación de datos.

•     Hipotético-deductivo: permite a través de los conocimientos generales abarcados, definir criterios específicos, conceptos del fenómeno investigado y factores de alta influencia en las etapas de la investigación, además de relacionar elementos de conceptos relevantes para lograr el objetivo propuesto en la investigación.

•     Analítico-sintético: utilizado al descomponer el problema de investigación en elementos por separado y profundizar en el estudio de cada uno de ellos, para luego sintetizarlos en la solución de la propuesta.

•     Inducción-deducción: para definir criterios específicos a partir de los conocimientos generales, conceptos del fenómeno investigado y factores de alta influencia en las etapas de la investigación a partir del análisis de la bibliografía que se consulta.

•     Análisis documental: en la consulta de la literatura especializada, para extraer la información necesaria que responda a las características distintivas del problema.

Base de datos de la plataforma educativa ZERA

La plataforma ZERA usa como gestor de BD a PostgreSQL (PostgreSQL, 2010) en su versión 9.1. La BD de la versión 1.0 de ZERA cuenta con un total de 240 tablas, dentro de estas existen tres tablas que crecen exponencialmente: tb_sco, r_matter_sco y tb_trace. El crecimiento tanto de tb_sco como r_matter_sco se debe a que prácticamente todos los elementos insertados en la plataforma se insertan en estas dos tablas y en el caso de tb_trace es debido a su uso para realizar todos los reportes con que cuenta ZERA (reportes de uso, institucionales y académicos) ya que no se cuenta con un almacén de datos para realizar estos reportes.

Modelo de despliegue de la plataforma educativa ZERA

Una de las principales características de ZERA desde sus inicios ha sido que presenta una estructura multi-organizativa (puede ser utilizada por diferentes instituciones educacionales a la misma vez), permitiendo la realización de reportes institucionales como matrículas y promoción. Otra ventaja que brinda la estructura multi-organizativa es que las instituciones docentes pueden personalizar o construir desde un principio todos los contenidos asociados a un programa de estudio, haciendo uso de los recursos educativos que ya se encuentran disponibles en la plataforma.

Esta característica unida al requerimiento de: los usuarios de las escuelas o instituciones educativas pueden seguir trabajando en la plataforma incluso cuando los servidores de estas escuelas no tengan visibilidad desde fuera de la red local de la institución, llevó a conformar el modelo de despliegue representado en la figura 1.

Es importante señalar que las instituciones educativas a quienes va dirigida la plataforma, por lo general presentan problemas de infraestructura en su red, provocando que la conexión a internet sea intermitente, de un ancho de banda reducido y costosa para las instituciones. En este escenario tener un servidor local es de vital importancia para las instituciones, reduciendo el tráfico de la red y aumentando la velocidad de conexión a la plataforma, aunque no está exento de problemas que deben ser corregidos con la mayor brevedad posible.

Replicación de datos

La replicación de datos es una forma eficiente y eficaz de distribuir los datos entre distintas BD asociadas a un SBDD. Según ORACLE replicación es (ORACLE, 1997):

"... el proceso de copiar y mantener objetos en varias bases de datos que componen un sistema de base de datos distribuida. La replicación puede mejorar el rendimiento y proteger la disponibilidad de aplicaciones. Por ejemplo, una aplicación podría normalmente acceder a una base de datos local en lugar de un servidor remoto para minimizar el tráfico de red y lograr el máximo rendimiento. Además, la aplicación puede seguir funcionando si el servidor local experimenta un fracaso porque otros servidores con datos replicados siguen estando accesibles."

La replicación proporciona redundancia y aumenta la disponibilidad de los datos. En algunos casos, se puede usar la replicación para aumentar la capacidad de lectura. Los clientes tienen la posibilidad de enviar las operaciones de lectura a diferentes servidores. También puede mantener copias en diferentes centros de datos para aumentar la localidad y la disponibilidad de datos para las aplicaciones distribuidas (MongoDB, 2011).

Replicación es mucho más que simplemente mover datos de un lado a otro. Esta técnica demanda de una tecnología extrema. Por lo tanto, el éxito de los sistemas de replicación depende de la tecnología y directrices de un amplio rango de necesidades en la organización (Heredia and Jeferson, 2013).

Herramientas para la replicación de datos

Existen varios factores que determinaron la elección de una herramienta de replicación de datos. La principal razón fue el modelo de despliegue que se elaboró para la plataforma educativa ZERA, así como los problemas de conectividad y ancho de banda de las instituciones educativas a las que va dirigida la plataforma, se estudiaron varias posibilidades que se detallan a continuación:

DBMoto

Utilizando el modo Refresh, DBMoto lee todos los datos cumpliendo las reglas definidas en el administrador para luego escribir los resultados en las bases de datos de destino. En modo Mirroring se realiza una replicación de datos en tiempo real basado en los log/journal. Y usando el modo Shyncronization, DBMoto provee una poderosa solución, la cual permite replicar datos en tiempo real y además en forma bi-direccional entre las bases de datos de origen y destino. Lo anterior permite a los administradores o usuarios de DBMoto tomar decisiones sobre el tipo de replicación. Adicionalmente para la administración y auditoria tecnológica, DBMoto puede registrar las actividades de replicación en un reporte interno y al momento de realizar una réplica, DBMoto ofrece una herramienta visual que proporciona información en tiempo real sobre el estado de la replicación.

El principal problema de esta herramienta para su uso en la plataforma ZERA es que esta desarrollada para servidores con sistema operativo Windows 2012/2008/2003, este requerimiento es incompatible con ZERA pues se desarrolló para instalarse en servidores con sistemas UNIX.

Symantec Replicator Option

Esta herramienta posee replicación asíncrona y sincrónica, permite la migración de datos y replicación de archivos entre arquitecturas de servidores heterogéneos, es una solución de replicación probada para realizar migraciones en centros de datos complejos o actualizaciones de hardware al tiempo que mantiene las aplicaciones en línea, además reduce significativamente las necesidades de almacenamiento, de ancho de banda y de CPU para la operación de sincronización inicial. (Symantec Corporation, 2014)

Dentro de las características del Symantec Replicator por las cuales no se seleccionó se encuentran: licencia privativa, no acorde a las políticas del país, además no es posible replicar cambios estructurales que pueden ocurrir durante el proceso de mejora de la plataforma ZERA.

SymmetricDS

SymmetricDS es un software de replicación de datos asíncrona que permite subscriptores múltiples y sincronización bidireccional. Utiliza tecnologías web y de BD para replicar tablas entre BD relacionales, casi en tiempo real. El software fue diseñado para escalar a un gran número de BD, trabajar con conexiones de bajo ancho de banda y resistir a periodos de inoperatividad de la red (Long et al., 2014).

Una única instalación de SymmetricDS se denomina un Nodo. Un Nodo es inicializado mediante un fichero properties y es configurado insertando datos de configuración en una serie de tablas de BD. A continuación, el Nodo crea triggers de BD en las tablas de aplicación especificadas, de modo que los eventos de BD son capturados para ser entregados a otros Nodos SymmetricDS.

SymmetricDS está escrito en Java 5 (Gosling et al., 1996) y requiere Java SE Runtime Environment (JRE) o Java SE Development Kit (JDK) versión 5.0 o superior. Soporta la sincronización entre diferentes plataformas de BD, mediante el concepto de dialectos de base de datos. Un dialecto de BD es una capa de abstracción con la cual interactúa SymmetricDS para aislar la lógica de sincronización de los detalles de implementación específicos de cada BD.

•     Licencia de código abierto GPL, multiplataforma.

•     Pensado para trabajar con conexiones de bajo ancho de banda.

•     Pensado para tener nodos desconectados por largos periodos de tiempo.

•     Es capaz de replicar los cambios estructurales de la BD que puedan surgir.

•     Flexibilidad a la hora de declarar las reglas de replicación de los datos.

•     Facilidad de configuración, basado en triggers.

•     Amplia documentación, comunidad, soporte y ejemplos.

•     Alto rendimiento en ambientes con bajo ancho de banda y problemas de conexión.

Durante el proceso de configuración del SymmetricDS es necesario caracterizar el sistema para identificar las necesidades de replicación de las tablas presentes en la plataforma educativa ZERA, logrando la disponibilidad y consistencia (teorema CAP (Lynch and Gilbert, 2002)) de los datos a replicar.

Debido a la dependencia entre tablas y por la necesidad de cumplir con la integridad referencial entre estas, fue necesaria su agrupación en trece niveles que definen el orden en que serán replicadas para cumplir con las restricciones. Este orden o nivel es configurado mediante la opción initialloadorder de la relación entre los triggers y los routers (trigger_router) del symmetric. Una tabla en un nivel significa que ella depende de tablas que están en los niveles superiores y que no depende de ninguna de los niveles inferiores. Para lograr una correcta configuración es necesario analizar cada una de las restricciones referenciales de las tablas pues un error puede detener todo el sistema de réplica, a continuación se muestra un pequeño extracto (solo cuatro niveles de los trece) de la configuración usada:

Primer nivel:
nom_nomenclator_type: Tabla que contiene las categorías de los nomencladores de la plataforma.

Segundo nivel:
nom_nomenclator: Tabla que contiene todos los nomencladores de la plataforma y posee una referencia a nom_nomenclator_type que determina el tipo de nomenclador.

Tercer nivel:
tb_sco: Tabla que contiene los datos generales de todos los objetos de aprendizaje y posee una referencia a nom_nomenclator que determina el tipo de objeto de aprendizaje.

Cuarto nivel: ]]> tb_picture: Tabla que contiene los datos específicos de los objetos de aprendizaje que son imágenes y contiene una referencia a nom_nomenclator que determina el nomenclador de la licencia que posee y otra referencia a los datos generales contenidos en tb_sco.

Otro problema que se tuvo durante la configuración fue el flujo de replicación que no es el mismo en todos los niveles, pues hay datos que solo se replican en un sentido y hay algunos que nunca se replican, para ello se realizó la agrupación de las tablas con mecanismos de replicación similares, lográndose cuatro reglas generales de replicación.

Replicación completa:

En este grupo están las tablas que se replicaran en ambos sentidos de manera íntegra y su información debe existir en todos los nodos, ejemplo:

•     sf_guard_action: Tabla que almacena las acciones utilizadas para el control de la seguridad en la plataforma.

•     sf_guard_group: Tabla que almacena los grupos de usuarios de la plataforma.

•     tb_config: Tabla que almacena las configuraciones de la plataforma.

Para cumplir con esta primera configuración, por cada institución (nodo) se inserta una tupla para la replicación del nodo central al nodo en configuración en la tabla router de symmetric. Esta tupla tiene como su identificador el identificador del nodo central y el identificador del nodo en configuración con el sufijo "fd" habilitando las replicación para los eventos de inserción, actualización y eliminación. Además se inserta otra tupla para la replicación desde el nodo en configuración hacia el nodo central con el identificador formado por el identificador del nodo en configuración y el nodo central con el sufijo "fu" habilitados para iguales eventos que la anterior. Luego se enlaza los trigger de cada una de estas tablas con los router definidos anteriormente insertando dos tuplas en la tabla trigger_router con las referencias a los router que no definen ninguna condición de replicación logrando así la replicación completa.

Replicación de forma condicional por escuela:

Este grupo de tablas se replica condicionalmente desde el servidor central hasta nodos específicos (instituciones) siempre y cuando el identificador de la escuela esté presente en el identificador de la tupla y los cambios realizados en los nodos locales se replican de manera íntegra al nodo central, ejemplos:

•     tb_student: Tabla que almacena los datos de los usuarios que tienen el rol de estudiante dentro de la plataforma y se replica al nodo cuyo identificador esta contenido dentro del identificador de la fila.

Para lograr la configuración de cada institución (nodo) se inserta una fila para la replicación del nodo central al nodo en configuración en la tabla router de symmetric con un identificador formado por el identificador del nodo central y el identificador del nodo en configuración con el sufijo "sd" habilitando la replicación para los eventos de inserción, actualización y eliminación. En este router se selecciona el routertype "subselect" que permite la réplica condicional utilizando como routerexpression "EXTERNAL_DATA ilike % node_id %" en este caso el EXTERNAL_DATA es un campo perteneciente a la tabla y que varía entre user_id, id y school_id. Luego se enlazan los trigger de cada una de estas tablas con el router definido anteriormente insertando dos tuplas en la tabla trigger_router. La primera enlaza los triggers con el router condicional para la replicación entre el nodo central y la escuela y la segunda utiliza el router realizado en el grupo de tablas anteriores para la replicación total entre el nodo y el nodo central.

Replicación completa o condicional por escuela:

Este grupo de tablas se replican de manera completa para todos los nodos excepto cuando pertenece solo a una institución caso en el cual solo se replica a este nodo, ejemplo:

•     tb_permited_file: Tabla que almacena la configuración de tipos de ficheros permitidos y sus respectivos tamaños máximos, existen en esta tabla tuplas de configuración general para todas las escuelas y tuplas para escuelas específicas.

•     tb_rubric: Tabla que almacena la información utilizada en los mecanismos de evaluación de la plataforma para que los estudiantes sepan los parámetros que le medirán en cada uno.

Para la configuración de cada institución (nodo) se inserta una fila para la replicación del nodo central al nodo en configuración en la tabla router de symmetric con un identificador formado por el identificador del nodo central y el identificador del nodo en configuración con el sufijo "sgd" habilitando la replicación para los eventos de inserción, actualización y eliminación. En este router se selecciona el routertype "subselect" que permite la réplica condicional utilizando como routerexpression "EXTERNAL_DATA ilike %node_id% OR (:EXTERNAL_DATA not ilike %cu% AND: EXTERNAL_DATA not ilike %me%)" configurando así que la tupla se envié al nodo si tiene el identificador del nodo contenido dentro de su identificador o es una tupla general. Luego se enlaza los trigger de cada una de estas tablas con el router definido anteriormente insertando dos tuplas en la tabla trigger_router. La primera enlaza los triggers con el router condicional para la replicación entre el nodo central y el nodo local, la segunda utiliza el router con sufijo "fu" realizado en el grupo de tablas anteriores para la replicación total entre el nodo local y el nodo central.

Sin replicación:

Estas tablas no están incluidas dentro del sistema de réplica por solo tener sentido dentro de los nodos locales o centrales según sea el caso. Para ello no se crean triggers para estas tablas siendo así ignoradas por SymmetricDS, ejemplo:

Para lograr esta condición simplemente no se crean relaciones entre los triggers y ningún router evitando así cualquier replicación.

Despliegue:

La plataforma educativa ZERA se desplegó en México un total de 43 instituciones, la mayoría se encuentran en el Distrito Federal aunque se tuvo instituciones en: Cancún, Hidalgo, Sonora, Estado de México y Toluca. En cada una de estas instituciones existió una instancia (nodo) del SymmetricDS. La configuración que se realizó fue probada con éxito en los 43 nodos, aunque es importante aclarar que durante el despliegue existieron diversos errores de replicación, muchos de estos relacionados con errores de integridad referencial provocados por la propia plataforma y otros provocados por tablas que se le configuró la regla incorrecta, todos estos problemas fueron corregidos y erradicados totalmente.

De los 43 nodos solo cinco que representan el 12 % nunca se apagaron o perdieron la conexión con el servidor central, del 88 % restante el 50 % (19 nodos) tuvo una situación crítica en cuanto al ancho de banda además de permanecer muy poco tiempo conectados, los restantes no tuvieron problemas con el ancho de banda pero si con el tiempo en que permanecían conectados al servidor central, esta situación reafirmó que la selección del SymmtricDS como herramienta de réplica para este entorno fue correcta y de vital importancia para mantener todos los servidores sincronizados.

CONCLUSIONES

Existe una diversidad de herramientas que facilitan el proceso de replicación de datos logrando mejorar el rendimiento y proteger la disponibilidad de las aplicaciones, ayudando al auge, cada día más creciente, de sistemas de base de datos distribuidos.
La herramienta SymmetricDS cumple con las características necesarias para ser usada en entornos donde existan problemas de conectividad y bajo ancho de banda, teniendo un alto desempeño en el despliegue de la plataforma educativa ZERA.

Una correcta identificación de las necesidades de replicación de cada tabla de la BD posibilita la adecuada configuración del SymmetricDS, asegura la consistencia de los datos y disminuye los errores de replicación.

REFERENCIAS BIBLIOGRÁFICAS

CLAUDIO ARIEL CLARENC, SILVINA MARIEL CASTRO, CARMEN LÓPEZ, María Eugenia Moreno, and Norma Beatriz Tosco. Analizamos 19 plataformas de e- Learning: Investigación colaborativa sobre LMS. Grupo GEIPITE, Congreso Virtual Mundial de e-Learning., 3ra edition, December 2013. ISBN 9781291533439. URL www.congresoelearning.org.

BACKOFFICE ASSOCIATES. Replicación de Datos: DBMoto, 2013. URL http://www.hitsw.com/localized/spanish/products_services/dbmoto/dbmoto_dsheet.html.

THOMAS M CONNOLLY and CAROLYN E BEGG. Database systems: a practical approach to design, implementation, and management. Addison-Wesley Boston, 2005.

BARRY DEVLIN. Data Warehouse: From Architecture to Implementation. Addison-Wesley Longman Publishing, 1996. ISBN 0201964252. URL http://dl.acm.org/citation.cfm?id=548222.

LORENZO GARCÍA ARETIO. La educación a distancia de la teoría a la práctica. Editorial Ariel S.A., Barcelona, 1ra edition, 2001. ISBN 84-344-2637-4.

JAMES GoSLING, BILL JOY, GUY STEELE, and GILAD BRACHA. The Java Language Specifica tion. 1996. URL fttp://books.google.es/books?hl=es&lr=&id=Ww1B9O_yVGsC&oi=fnd&pg=PA1&dq=java&ots=Se7J8gM7pE&sig=ehUABVXeOPP2qKVJVNNrEeB5tW0#v=onepage&q&f=false.

KINCHO H. LAW, MAZEN K. JOUANEH, and DAVID L. SPOONER. Abstraction database concept for engineering modeling. 2(2):79–94, 1987. doi: 10.1007/BF01213976.

ERIC LONG, CHRIS HENSON, MARK HANES, and GREG WILMER. SymmetricDS User Guide. page 182, 2014. URL http://www.symmetricds.org/.

NANCY LYNCH and SETH GILBERT. Brewer’s conjecture and the feasibility of consistent, available, partition-tolerant web services. ACM, 33(2):51–59, 2002. URL http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.20.1495&rep=rep1&type=pdf.

MONGODB. Replication Introduction, 2011. URL http://docs.mongodb.org/manual/core/replication-introduction/.

ORACLE. Database Replication, 1997. URL http://docs.oracle.com/cd/A64702_01/doc/server.805/a58227/ch_repli.htm.

ULEISY GONZÁLEZ PÉREZ, HAROLD ORDAZ VALDÉS, YAISMEL MIRANDA PONS, and DANIEL RODRÍGUEZ SOBERA. Gestión de los Contenidos del Microdiseño Curricular desde la Plataforma Educativa Zera. Serie Científica de la Universidad de las Ciencias Informáticas, 5(6):1–10, 2012. ISSN 2227-1899. URL http://publicaciones.uci.cu/index.php/SC/article/view/864/545.

POSTGRESQL. Sobre PostgreSql, 2010. URL http://www.postgresql.org.es/sobre_postgresql.

SYMANTEC CORPORATION. Replicación de archivos y software de replicación de datos, 2014. URL http://www.symantec.com/es/mx/replicator.

Recibido: 09/05/2015
Aceptado: 29/09/2015