cenidet santiago... · 3.1.2.3 consideraciones de finalización ... tabla de abreviaturas bdd crc...
TRANSCRIPT
SEP
Centro Nacional de Investigación y Desarrollo Tecnológico
SElT DGlT
cenidet Herramienta para la Migración de Datos a través de
Internet
TESIS Que para obtener el grado de Maestro en Ciencias en Ciencias Computacionales
presenta
Santiago Martinez Ossorio
Director de Tesis: Dr. Joaquín Perez Ortega
Co-director de Tesis: M.C. Jose Antonio Zárate Marceleño
.
Cuernavaca, Morelos Diciembre de 1999
>entro Nacional de Investigación y FORMA C3
Desarrollo Tecnológico
I REVISION DE TESIS
Cuernavaca, Morelos a 7 de Diciembre de 1999 ,I
I.C. Máximo López Sánchez I/
residente de la Academia de Ciencias Computacionales 81
resente 1,
Nos es grato comunicarle, que conforme a los lineamientos para la obtención del grado de,l laestro en Ciencias de este Centro, y después de haber sometido a revisión académica la tesis,I enominada: Herramienta para la Migración de Datos a través de Internet, realizada por el :. Santiago Martínez Ossorio, y habiendo cumplido con todas las correcciones que le fueron idicadas, acordamos no tener objeción para que se le conceda la autorización de impresión de I tesis. 1
I/
Sin otro particular, quedamos de usted. I1
II
Atentamente
La comisión de revisión d
Ir. RodolfBA. Pazos Rangel tevisor
Director de tesis
:o-director d,k tesi6
:.c.p. Dr. Javier Ortiz HernándedJefe del Departamento de Ciencias Computacionalec
NTERIOR INTERNADO PALMIRA SIN. CUERNAVACA, MOR. MGXICO 4PARTADO POSTAL 5-164 CP 62050, CUERNAVACA. TELS. (73)12 2314.12 7613 , I S 7741, FAX(73) 12 2434
EMAIL [email protected]
II
cenidet 1;
I
1
Centro Nacional de Investigación y Desarrollo Tecnológicot /I
FORMA C4 AUTORIZACION DE IMPRESIdN DE TESIS
Cuernavaca, Morelos a 7 de Diciembre de 1999
:. Santiago Martínez Ossorio zandidato al grado de Maestro en Ciencias !n Ciencias Computacionales 'resente
I/
Y
Iespués de haber atendido las indicaciones sugeridas por la Comisión Revisora de la" kademia de Ciencias Computacionales en relación a su trabajo de tesis: Herramienta para la I' digración de Datos a través de Internet, me es grato comunicarle, que conforme a los 'I ineamientos establecidos para la obtención del grado de Maestro en Ciencias en este Centro, 'I ;e le concede la autorización para que proceda con la impresión de su tesis. I/
INTERIOR INTERNADO PALMIRA SIN, CUERNAVACA. MOR, MÉXICO APARTADO POSTAL 5-164 CP 62050, CUERNAVACA, TELS. (73)12 2314,12 7613 . I 8 7741, FAX(73) 12 2434
EMAIL [email protected]
#I
cenidet 1:
I1
I1 a mis padres José Santiago y María del Carmen
a mi hermano Emilio José
a mis abuelos Q José y Q Manuel Emilio //
I/
I/
U
I/
a mi abuela Carmen
a mis tíos Manuel Emilio, Carlos Miguel y Luis Alberto
a mis tías Elsa y Enriqueta i I/
a mis primos Elsa del Carmen y Emiliano I
I/
I/
I/
//
I/
It
I/
I/
1
Ag radecim ¡en tos
De forma especial quiero agradecer a mi director de tesis Dr. Joaquín Perez Ortega, Por todo el apoyo que me brindo durante la elaboración del trabajo, por su hvaluable orientación y asesoramiento, por toda su ayuda para continuar con mi formación profesional.
Mi reconocimiento Y agradecimiento al Dr. Rodolfo Pazos, al M.C. Antonio Zarate, al M.C. Luis Garcia Y al M.C. Humberto Hernandez, quienes revisaron cuidadosamente la versión final del documento y aportaron valiosas sugerencias y COmentariOS durante todo su desarrollo.
Mi agradecimiento a todos los integrantes del centro de investigación que contribuyeron a mi preparación, en especial al Dr. Javier Ortiz, al M.C. Juan Gabriel González, al M.C. Hugo Estrada, al M.C. José Luis Alcántara, al M.C. Victor Jesus Sosa, al M.C. Mario Guillen, y al Ing. Jaime Rosas, quienes siempre me ofrecieron su ayuda y su amistad.
A la Secretaria de Educación Publica por el apoyo económico otorgado para realizar mis estudios de maestría en el cenidet.
A mis compañeros y amigos del cenidet: Gloria Patricia, Nadira, Martha Fabiola, Magdalena, Cecilia, Fabiola, Lucero, Carla Natalia, Rosa Lina, Edson Ignacio, Rogelio, Felix Agustin, José Aurelio, Isaac Alberto, Javier Raymundo, Alberto Mario, Aldo Luis, Ismael, José William, Gustavo Ivan, Joaquín Manuel, Y Victor Manuel por todos 10s gratos momentos de convivencia, por las aventuras Y viajes que emprendimos, y por la amistad que nos Unira siempre.
De forma muy Sincera a mis amigos: Socorro, Karime, Wendy, Lesvia Elena, Jekabel, Miguel, Ricardo, Lucio, y Jorge Luis, sin ellos hubiera sido muy dificii afrontar estos dos años.
'I
I
,/
I/
Tabla de Contenido
Dedicatoria.. ........................................................................................ Agradecimientos ................................. Tabla de Abreviaturas ............................................................ Lista de Figuras ................. Lista de Tablas ............................................................
....................... v ..................
.................................. Vl l l
., 1. Introduction ...................................................... ............................................ 1
1.1 Antecedentes ............. ............................................................... 2 1.2 Objetivos .................... ...................................... 5 1.3 Estado del Arte a 1.4 Organización del Documen
2. Descripción del Problem ................................................ 2.1 Diseño de la Distribución ................................................................ 2.2 Migración de Datos ...............................................................
............... .................................................................. ............................................................. I 1
3. Implementación de la Solución ............................................ 3.1 Enfoque de Solución ................ ....................................................
3.1 .I Arquitectura de HeMiDl .................................... ............ 3.1 .I .I Módulo de Manejo de Transacciones. 3.1 .I .2 Módulo de Transferencia de Dato 3.1 .I .3 Módulo de Recuperación ante Fallos ............
3.1.2 Protocolo de Compromiso Propuesto ..................... 3.1.2.1 Justificación ............ 3.1.2.2 Descripción .................................. 3.1.2.3 Consideraciones de Finalización del Protocolo .....................
3.1.2.3.1 Pseudocódigo del Coordinador .............. 3.1 2.3.2 Pseudocódigo del Participante ................................
.........................................
........... 40 3.2.1 Comunicación y Envio de Bytes a través de Sockets ......................... 42 3.2.2 Verificación de la Integridad de la Información y Detección de Errores del Circuito Virtual .................... ...................................... 43 3.2.3 Incorporación de Concurren Hilos de Ejecución ................... 3.2.4 Administración de las Co 3.2.5 Implementación del Protocolo de Compromiso..... 3.2.6 Implementación de la Bitácora. 3.2.7 Configuración .................. ........................................
.3.2 Implementación ................ ......................................
... Ill
4. Pruebas .... ......................... , . . , . . , , , , , , . , , , , , , , , . , , . , , , , . , , . , , , . , 4.1 Descripción del Ambiente de Pruebas. 4.2 Manejo de Transacciones .....................................
4.2.1 Fallas del Coordinador ............. 4.2.2 Fallas de los Participantes ...........................................
4.3 Transferencia de Datos ......................................... 4.3.1 Fallas en la Transferencia de Datos ............................. 4.3.2 Comparación con FTP ..............................
5. Conclusiones .................................................................................................... 76 5.1 Conclusiones .......................................................................................... 77 5.2 Recomendaciones para Trabajos Futuros ............................................. 78
................. Anexo A Lenguaje JAVA ............................ A.1 Características del Lenguaj A.2 Sockets en JAVA ................ A.3 Hilos de Ejecución en JA
................................................ 81
................. .84
Anexo B Pantallas ................................................................................................. 89
Glosario ................................................................................................................. 94 Referencias .......................................................................................................... .95
i V
Tabla de Abreviaturas
BDD CRC DDA
FAP
FTP
FURD GB HeMiDl Hrs Kb LAN LDD LMD
, Mb .
M hz RAM
seg SiMBaDD SQL
TCPAP
UML
URL
: Base de Datos Distribuida : Código de Redundancia Ciclica
: Ubicación Dinámica de Datos, por sus siglas en ingles " ~ ~ ~ ~ ~ i ~
: Problema de Ubicación de Archivos, por sus siglas en ingles "File
: Protocolo. de Transferencia de Archivos, por sus siglas en ingles "File
: Fragmentación, Ubicación y Reubicación de Datos : Giga Bytes : Herramienta de Migración de Datos a través de Internet : Horas : Kilo Bytes : Red de Area Local, por sus siglas en ingles "Local Area Network : Lenguaje de Definición de Datos : Lenguaje de Manipulación de Datos : Mega Bytes : Mega Hertz : Memoria de Acceso Aleatorio, por sus siglas en ingles "Random ' Access Memory" : Segundos : Sistema Manejador de Bases de Datos Distribuidas : Lenguaje de Consulta Estructurado, por sus Siglas en ingles
: protocolo de Control de Transmisiones I Protoco!o de Internet, Por
Data Allocation"
Allocation Problem"
Transfer Protocol"
"Stuctured Query Language"
SUS siglas en ingles "Transmission Control Protocol I Internet
Protocol" : Lenguaje de Modelado Unificado, por sus siglas en ingles "Unified
: Ubicador Uniforme de Recursos, por sus siglas en ingles "Uniform Modeling Language"
Resource Locator"
I/
I1
v
Figura
1
2
3
4
5
6
7 8
9
10
11
12
13
14
15 16 17
18
19
Lista de Figuras
Diagrama a bloques de la arquitectura de SiMBaDD,
Reubicación de la información entre nodos, como resultado
de la ejecución de Un programa de optimización basado en el
modelo matemático FURD.
Ejemplo de un diseño de la distribución,
Fallo en la transferencia de datos entre sitios. Despues de
pasado un tiempo "t" el servidor no es capaz de atender al
cliente y se envía un mensaje de error.
Ejemplo de migración de datos entre sitios.
Arquitectura de HeMiDI.
Módulo de manejo de transacciones.
Módulo de transferencia de datos.
Estructura de comunicación tradicional del protocolo de
compromiso en dos fases.
Estructura de comunicación del protocolo implementado en
esta herramienta. Acciones del protocolo de compromiso en dos fases.
Acciones del protocolo de compromiso propuesto.
Migración de datos entre sitios.
Jerarquía de clases que integran HeMiDl en notación UML. Establecimiento de un circuito virtual entre procesos.
Primera fase de migración. Segunda fase de migración.
Diagrama de estados de transición del proceso coordinador.
primer caso de prueba. El coordinador (ci) falla en Su
primera etapa, antes de enviar instrucciones a 10s
participantes (pi ,pz).
Página
3 7
16
19
20
24
25
27
31
33
34
35
36
41
42 45
45
55
57
V i
20
21
22
23
24
25
26
27
28
29
30 - a
30 - b
31 - a
Segundo cas0 de prueba. El coordinador (cl) sufre una falla
mientras esperaba la respuesta de los participantes (pi ,p2),
Tercer cas0 de prueba. El coordinador (ci) falla antes de
Poder enviar su voto global a los participantes (p1,p2),
Cuarto caso de prueba. El coordinador (cl) no logra enviar el
voto global a todos (OS participantes (pl,p2), falla durante este proceso.
Quinto caso de prueba. El coordinador (cl) falla al recibir las
confirmaciones de terminación de los participantes (PI ,p2).
Diagrama de estados de transición del proceso participante.
Sexto caso de prueba. El .participante (p2) falla mientras
recibe las instrucciones del coordinador (cl).
Séptimo caso de prueba. El participante (p2) falla mientras
realiza una transferencia de datos.
Octavo caso de prueba. El participante (p2) falla mientras
intentaba enviar su voto al coordinador (ci).
Noveno caso de prueba. EL participante (p2) falla antes de
recibir el voto global por parte del coordinador (ci).
Décimo caso de prueba. El participante (pz) falla antes de
enviar su confirmación de terminación.
La falla se presenta antes de recibir alguna Confirmación.
EI proceso reinicia la transferencia de datos al recuperarse.
La falla se presenta antes de que todos 10s subProcesoS
confirmen.
58
59
60
61
62
64
65
66
67
68
71
71
72
31 - b El proceso reenvía las particiones que quedaron pendientes
al darse la falla. Transferencia de datos entre sitios usando FTP.
72
74 32
vii
Lista de Tablas
Tabla Página
1 Resultados representativos de las pruebas al módulo de 74
transferencia de datos.
I
I/
/ /
I,
I,
I/
I/
viii I/
Capítulo I
Introducción
Capitulo I Introducción
1 Introducción
En el capítulo se da una introducción y se ubica al lector en el contexto en el que
fue desarrollada la herramienta de migración de datos (HeMiDI), además de
presentar las metas a alcanzar y el estado del arte asociado a la solución del
problema de transferencia de datos a través de Internet.
/I
1.1 Antecedentes
HeMiDl fue desarrollada en el Centro Nacional de Investigación y Desarrollo
Tecnológico dentro del área de Sistemas Distribuidos. En el área se han venido
desarrollando con éxito durante 10 años, trabajos que han dado forma y que
complementan a un manejador de bases de datos distribuidas experimental
denominado SiMBaDD. El manejador es el único de su tipo desarrollado en
México.
A lo largo de esos diez años, SiMBaDD ha evolucionado pasando de una
plataforma de ejecución bajo el sistema operativo Windows en computadoras
personales, al sistema operativo Sun Solaris en estaciones de trabajo de Sun
Microsystems, siempre buscando explorar y adaptarse a las nuevas tecnologías,
en especial a aquellas referentes a los sistemas distribuidos y bases de datos
distribuidas.
HeMiDl forma parte de un nuevo paso en esta evolución: la búsqueda de la automatización del diseño de la distribución de los datos en el sistema. Con está
nueva característica el manejador será capaz de efectuar un rediseño optimizado
de la ubicación de sus datos entre los sitios de la red, liberará de la tarea de
reubicación al administrador de la base de datos. Además, se plantea un cambio
de plataforma de trabajo, pasando de una red local a Internet.
2
Capítulo I Introducción
Servicios de
B.D.D.
En la Figura 1 se muestra un diagrama a bloques de los módulos de SiMBaDD y
la ubicación de HeMiDI.
Optimización
Distribución
1
- Detección y Registro de Consultas Relevantes Modelo
Solución del
Servicios para el Cooperativas Administrador de la B.D.
HeMiDl
Tarea del Precompilador
Figura 1 Diagrama a bloques de SiMBaDD
Actualmente SiMBaDD se compone de tres módulos principales: el módulo de
tareas cooperativas, el módulo del precompilador y el módulo de servicios para el
administrador de la base de datos. Dentro del módulo de tareas cooperativas se
realiza el procesamiento de consultas, y en el módulo del precompilador se
implementa el lenguaje de definición de datos (LDD) y lenguaje de manipulación
de datos (LMD). A continuación se explica brevemente la función de los módulos:
Capitulo 1 Introducción
a) El Procesamiento de consultas distribuidas, que se realiza en el módulo de
tareas cooperativas, trabaja haciendo una explotación del paralelismo en las consultas. Lo logra mediante la descomposición de las consultas en
subconsultas, donde cada una puede ejecutarse en forma paralela en
diferentes máquinas de la red, para luego integrar los resultados de las
subconsultas con el fin de generar el resultado final de la consulta recibida. El
modelo utilizado es clientelservidor, en él, las máquinas designadas como
servidores reciben solicitudes de servicio, éstas son procesadas en forma local
y unicamente los resultados finales son enviados a través de la red a las
máquinas designadas como clientes, quienes originaron la petición. Las
consultas, expresadas en SQL, son emitidas por una computadora de la red
hacia un servidor que es el encargado de remitir los resultados a la máquina
solicitante. El servidor que recibe la consulta no es necesariamente el que la
procesará ya que éste hará un .análisis para determinar en cual de 10s servidores que contienen información involucrada en la Consulta, es n-~ás
conveniente para realizar el.procesamiento [Pérez et al, 1997al.
b) El precompilador recibe como entrada programas en Turbo Pascal para
Windows con instrucciones del lenguaje SQL intercaladas. Los programas
realizan las rutinas de altas, bajas, cambios, consultas e informes de cada una
de las tablas de la base de datos. Después de pasar por las etapas tipicas de
un compilador (análisis léxico, sintáctico, semantico), finalmente genera código
en Turbo Pascal para Windows con llamadas a la biblioteca del manejador, el
conjunto de llamadas a la biblioteca equivale semánticamente a las
operaciones en SQL intercaladas en el código fuente [Pérez et al, 1997bl.
En el módulo de servicios para el administrador de base de datos, tenemos a su
vez dos módulos, el de servicios de mantenimiento de bases de datos distribuidas
y el módulo de optimización de la distribución; en el primero se realizan tareas
tales como alta y baja de nodos del sistema, mantenimiento del diccionario de
datos, definición de privilegios de acceso, mientras que en el segundo se optimiza
4
Capítulo I Introducción
la ubicación de los datos de la base de datos. En el módulo de optimización de la
distribución se consideran tres sub-módulos:
1) El módulo de detección y registro de consultas relevantes, tiene como objetivo
dotar al manejador de la base de datos de la capacidad de registrar datos
estadísticos sobre las consultas distribuidas que se realizan en cada uno de los
sitios del sistema.
2) El módulo de solución del modelo, se refiere a la solución de un modelo
matemático denominado FURD que determina una ubicación optimizada de los
fragmentos de una tabla entre los sitios del sistema, basándose en los cambios
en los patrones de explotación de los datos.
3) HeMiDI, SU función principal es administrar la ejecución de transacciones
distribuidas a través de Internet, dotando al manejador de bases de datos
distribuidas con la capacidad de reubicar sus datos con base en los resultados
obtenidos de un programa optimizador que implemente algún módelo
matemático desarrollado para dicho fin.
1.2 Objetivos de HeMiDl
Para resolver el problema de la optimización de la distribución e incorporar a
SiMBaDD esta caracteristica, se han propuesto tres herramientas:
1 .- Un detector de consultas relevantes, cuya función será llevar estadísticas de los cambios en los patrones de explotación de los datos por parte de los usuarios.
2.- Un módulo en el cual se implements un modelo matemático, que determinará con base en estadísticas sobre los patrones de explotación, una nueva ubicación
optimizada de los datos. .I
Capitulo I Introducción
3.- Una herramienta de migración de datos a través de Internet (HeMiDI), la cual
se desarrolla en el presente trabajo de tesis, y cuyos objetivos se describen a
continuación.
Actualmente se cuenta con el modelo matemático FURD que determina una
ubicación optimizada de los datos en una red de computadores geográficamente
dispersos, de tal forma que los 'costos de comunicación entre nodos son
minimizados [Pérez et al, 19981.
Esto resuelve el problema de la reubicación, pero aún es necesaria la intervención
del administrador de la base de datos para ejecutar un programa de optimización
de la ubicación basado en el modelo matemático.
Además se ha visto que los mecanismos de comunicación a través de Internet no
son lo suficientemente seguros y confiables. Tomando en cuenta los puntos antes
mencionados, el presente trabajo de tesis fijó como metas alcanzar los siguientes
dos objetivos:
El primer objetivo es automatizar la migración de los datos de un sistema
manejador de bases de datos distribuidas (SiMBaDD) a través de Internet.
Lo que se busca es pasar en la red de un estado congruente A cuyos datos es
probable que ya no se encuentren ubicados de una forma optimizada, a un nuevo
estado funcional A'. El nuevo estado A' es obtenido a través de la ejecución de un
programa de optimización, y al igual que el estado A, es un estado congruente
(Figura 2). Para que al pasar entre estados congruentes se llegue a un estado
válido, se debe garantizar que los datos fueron migrados exitosamente entre los
nodos participantes.
Capítulo I Introducción
HeMiDl contempla dos formas en las que considera un nuevo estado como válido.
La primera forma se apega de forma rigurosa a la característica de atomicidad de
una transacción, se considera que la herramienta debe lograr hacer todos los
cambios establecidos por el programa de optimización en caso contrario deja los
datos en la ubicación del estado anterior congruente.
Cada uno de los cambios establecidos por el programa de optimización son
considerados como una sola transacción y se convierten en los datos de entrada
para la herramienta de migración de datos.
En la segunda forma se considera que la migración esta formada por un número
finito de transacciones independientes, donde cada transacción corresponde a los
pasos establecidos por el programa de optirnización. La característica de
atomicidad se aplica a cada una de estas transacciones, sin embargo es posible
considerar que se ha llegado a un nuevo estado válido aún cuando no se lograran
hacer todos los cambios establecidos por el programa de optimización (esto se
explica en el capítulo 3).
Esiadisticos dcl
Figura 2 Reubicación de la Información entre nodos, como resultado de la ejecución de un programa de optimización basado en el módelo matemático FURD.
Capitulo 1 Introducción
El segundo objetivo es garantizar que la migración de los datos necesaria
para pasar entre estados funcionales, se lleve a cabo de manera segura y
confiable.
De la misma forma que una transacción en un ambiente de bases de datos se
acepta únicamente si se ha efectuado satisfactoriamente, la reubicación de los
datos indicada por el programa de optimización sólo se llevará a efecto si la
migración de los datos a través de Internet fue exitosa.
Cuando hablamos de transacciones decimos que se acepta la transacción si todos
los pasos que involucra fueron satisfactoriamente efectuados; es por ello que se
logró hacer una analogia con el objetivo que se persigue.
En este contexto de seguridad y confiabilidad, lo que se buscó es que la
información fuera migrada de un nodo de la red a otro sin pérdida de información,
manteniendo la integridad de los datos y haciendo las modificaciones pertinentes
en los nodos, de forma que se asegure que el sistema continuará trabajando de
forma congruente. El propósito de HeMiDl es reubicar de manera dinámica objetos
de la base de datos, de manera que su ubicación responda a los cambios en los
patrones de explotación. HeMiDl incorpora los conceptos de transacción
distribuida y transmisión eficiente de datos en Internet.
1.3 Estado del Arte
En la actualidad, se considera el diseño de la distribución de manera estática, ésto
es, se establece con el diseño inicial de la base de datos distribuida (BDD), el cual
permanece fijo hasta que el administrador del sistema intervenga para realizar
cambios [Wolffson, 19921. Este razonamiento es válido para aquellos sistemas que
casi no cambian sus patrones de acceso a la BDD. Sin embargo, la naturaleza de
Capítulo 1 Introducción
los sistemas distribuidos es dinámica, con cambios en los patrones y frecuencias
de acceso, nodos, costos, y recursos [Wolffson, 1992; Xiaolin, 1988; Lee, 19921.
Un sistema distribuido con un diseño de la distribución estático puede irse
degradando severamente en su desempeño por su incapacidad de respuesta a los
cambios en la explotación y recursos del sistema [Wolffson, 19921.
El problema de diseño de la distribución en BDDs es un problema de optimización
muy complejo, por el número de variables que intervienen y las interrelaciones que
existen entre éstas. Existen numerosas publicaciones que demuestran la
complejidad del problema, por ejemplo en [Apers,l988], [Xuemin,l995]. Los
primeros trabajos son los relacionados con la ubicación de archivos (FAP, por sus
siglas en inglés) en los sitios de una red de computadoras, teniendo como
finalidad que los programas de aplica,ción accedan a esos archivos optimizando
tiempos de respuesta y/o costos. !En [Dowdy,l982] se da una excelente
descripción de los. trabajos en FAP. Eniestas investigaciones se divide el problema
en modelos que minimizan costos de comunicaciones y/o que optimizan tiempos
de respuesta.
En [Muthuraj et al, 19931 se aborda formalmente el problema de la fragmentación
vertical, utilizando una función objetivo que permite cuantificar esquemas de
fragmentación. En [Navathe et al, 19841 se proponen diferentes algoritmos para
realizar la fragmentación vertical y la ubicación, los cuales están basados en
funciones objetivo empíricas. En [Ceri et al, 19831 se propone un modelo de
optimización para la ubicación no replicada de datos y se introduce la replicación de datos a partir de la solución óptima no replicada. En [Apers, 19881 se investiga
el problema de la fragmentación mixta y ubicación. El modelo propuesto permite
comparar costos de ubicación.
En [Cornell, 19891 se trata de manera simultánea la ubicación de relaciones y la
ubicación del procesamiento de las operaciones de "reunión", y se utiliza
9
Capitulo I Introducción
Programación lineal como método de solución. [March, 19951 extiende el trabajo
de [Cornell, 19891 Para incluir replicación, control de concurrencia, y ubicación de datos y operaciones. [Xuemin, 19951 trata el problema de ubicación de fragmentos
por medio de programación lineal, teniendo como objetivo encontrar las rutas de
propagación de las actualizaciones'de manera que se minimicen los costos de
comunicación globales. En [Xiaoiii, 19881 se proponen estrategias para la
ubicación y replicación de datos en una topología que cambia dinámicamente;
esto es, con nodos que se descqnectan de la red y que pueden volver a
conectarse en otro punto distante.
En [Kulkarni, 19911 se presenta una metodología para la fragmentación horizontal
y ubicación. Se utiliza conocimiento semántico para formar diferentes alternativas
de diseño, las cuales son evaluadas en cuanto a su tiempo de respuesta y costo
total. En [Wolffson, 19921 se propone el algoritmo de ubicación dinámica de datos
DDA, el cual cambia dinámicamente el esquema de replicación de un objeto para
ajustarlo a los cambios en los patrones de lectura-escritura. El algoritmo toma
como base una copia primaria.
En [Perez et al, 1997al se propone un.modelo matemático (FURD) que considera a los atributos de las relaciones como unidades de datos con accesc
independiente. Se investiga la fragmentación vertical y la ubicación de datos de
forma simultánea en un ambiente distribuido en donde pueden cambiar las
transacciones y la cardinalidad de las tablas de manera dinámica. Esta
consideración da la libertad de ubicarlos de manera óptima en los diferentes nodos
de la red para satisfacer un conjunto de transacciones. Los atributos que son ubicados en un mismo nodo, forman de manera natural un fragmento vertical de la
relación. Se muestra mediante ejemplos cómo el modelo FURD mejora la
ubicación de datos propuesta por [Navthe et al, 19841 y es muy similar con el diseño de la fragmentación propuesta por [Muthuraj et al, 19931.
10
Capitulo I Introducción
En [Stonebraker et al, 19941 Se presenta el diseño de un sistema de bases de datos distribuidas, llamado Mariposa. Este sistema combina las mejores
caracteristicas de los sistemas tradicionales de bases de datos distribuidas, bases
de datos orientadas a objetos y sistemas de archivos distribuidos. Una de las
caracteristicas más importantes de Mariposa es el soporte a movimiento de datos;
en los sistemas de bases de datos distribuidas previos [Williams, 1981; Bernstein,
1981; Litwin, 1982; Stonebraker, 19861, se suponía que cada objeto tenía una
ubicación fija. En [Malone, 19881 se describe la implementación de un proceso de
migración de datos entre un conjunto de estaciones de trabajo conectadas a
través de una LAN.
Un modelo similar al propuesto en [Stonebraker et al, 19941 se presenta en
[Ferguson, 19931 donde los fragmentos de la BDD pueden ser movidos y
replicados entre los nodos de una red de computadoras; el acceso a los
fragmentos es efectuado por cada nodo asignando relaciones de precio-calidad a
cada fragmento, !a distancia de transferencia entre sitios y la demanda de los
mismos determina esta relación precio-calidad.
Cambiar la ubicación de un objeto es una operación compleja, que significa por
ejemplo: destruir y regenerar todos los i,ndices para dicho objeto. En Mariposa, se
espera que los objetos de datos, los cuales son llamados fragmentos, se muevan
libremente entre los sitios en una red de computadoras para lograr optimizar la
ubicación de un objeto con respecto a los requerimientos actuales de acceso. En
Mariposa es posible para un sitio el crear o borrar un objeto, o para dos sitios,
acordar mover un objeto de uno a otro haciendo sólo notificaciones entre ellos [Stonebraker et al, 19941.
1.4 Organización del Documento
El trabajo de tesis consta de cinco capitulos y dos apéndices, los cuales se describen a continuación:
I
I(
I i i I
'I
1 i
i 4
I I I
I ! I
1 I
1
Introducción Capitulo I I
En el capítulo 2, se hace una tlescripción del problema del diseño de la
distribución y del problema de la migración de datos, haciendo énfasis en los
problemas a resolver por HeMiDI. 1
El capítulo 3, trata sobre la implementación de la solución, para ello se presenta
la arquitectura de HeMiDl y la descripción de sus módulos, además del protocolo
de compromiso propuesto.
En el capítulo 4, se describen las pruebas realizadas y se presentan los
resultados obtenidos de las mismas? Básicamente hay dos tipos de pruebas,
aquellas relacionadas con el manejo de las transacciones y las relacionadas con la
transferencia de datos. I
En el capítulo 5, se presentan las conclusiones a las que se llegó al finalizar el
trabajo y se hacen recomendaciones para trabajos futuros.
El apéndice A, trata sobre las características del lenguaje de programación JAVA,
el cual fue usado en el desarrollo de la herramienta, se habla del manejo de
sockets y de los hilos de ejecución (subprocesos).
El apéndice 6, incluye las pantallas resultantes de la ejecución de los procesos
coordinador y participante. En ellas se presentan los momentos de fallo y la
recuperación ante ellos.
I
I
12
I
I A I
j!
I I
1
I I i I 1
,I
/I
1
1
I
Capiítuio 2
Descripción del Problema
Capítulo 2 Descripción del Problema
I
2 Descripción del, Problema
En el capítulo se habla del diseiío 'de la distribución de forma introductoria y del
problema de la migración de datos,! haciendo énfasis en los problemas a resolver
por la herramienta. I
Básicamente la problemática es la ausencia de funciones o mecanismos en
internet que incoorporen el concepto de transacción distribuida. Una
aplicación de base de datos necesariamente requiere efectuar transacciones para
explotar el contenido de la base de datos.
En el caso de bases. de datos distrilbuidas, las aplicaciones requerirán efectuar
transacciones distribuidas para la explotación de los datos, o como en el caso de
HeMiDI, para migrar datos entre sitios garantizando una transferencia segura y
confiable. Actualmente en Internet no contamos con herramientas o funciones que
nos permitan efectuar transacciones distribuidas, lo cual es una limitante grave si
queremos que las aplicaciones se comuniquen a través de Internet. . I .
2.1 Diseño de la Distribución
En las bases de datos distribuidas, las tablas (también llamadas relaciones)
pueden estar almacenadas en cualquier nodo de la red, y desde cualquier nodo,
una aplicación puede acceder a las \relaciones que residen en forma local o
remota. El acceso de una aplicación a las relaciones locales es rápido y barato, mientras que el remoto puede ser lento y caro, con una diferencia de varios
I
órdenes de magnitud. !
Si ubicamos al azar las relaciones en los nodos de la red, es muy posible que la
explotación de la base de datos sea lenta y cara, porque algunas aplicaciones
necesiten acceder frecuentemente a relaciones que residen en otros nodos.
I
14
-- Lapiruio 2
Descripción del Problema I
Un razonamiento válido seria que las relaciones deben ser ubicadas en el nodo
donde estén las aplicaciones que más frecuentemente las acceden [Pérez, 19991.
El diseño de la distribución tiene como objetivo el determinar las unidades de
datos adecuadas para su distribuc/pn, así como su ubicación Óptima en los
diferentes sitios de la red de manera que el procesamiento de las aplicaciones sea
optimizado.
I
! El problema de ubicación de datos ;en un sistema de BDDs, se define de la
siguiente manera: se supone que existe un conjunto de relaciones R = {ri, r z , r3, ...
,rn} y una red de comunicaciones para computadoras que consiste de sitios S =
{si, SZ, s3, ... ,s,}, en donde se ejecutan una serie de aplicaciones Q = {qi, qz, q3,
... ,q4}. El problema'de la ubicación consiste en encontrar la ubicación óptima de R
en S de manera que el procesamiento de las consultas de Q sea el más eficiente.
La ubicación de datos es un problema complejo y su solución no es trivial debido
al número de parámetros que intervienen en el modelado y a la complejidad de la
solución. La Figura 3 tiene como finalidad mostrar un ejemplo sencillo de un
diseno de la distribución. En dicha figura, se representa a' la red de
comunicaciones para computadoras como una nube, que permite a un conjunto de
nodos estar interconectados. En este caso los nodos se identifican con la letra s y
un subíndice, las aplicaciones se identifican con la letra q y un subíndice,
finalmente las relaciones, se identifican con la letra r y un subíndice, en este caso
la relación r, está replicada en tres nodos.
1
I
I
i 15 1
i
2.2 Migración de Datos
Capitulo 2 I I Descripción del Problema I
A
En la actualidad la responsabilidad de ubicar la información y de mantener un
monitoreo del sistema, recae en el administrador de la base de datos distribuida.
Los sistemas distribuidos son dinám\cos por naturaleza, con cambios en la
topología de red, explotación de los datos e incorporación de nuevos datos.
Incorporar al diserio el aspecto dinámico incrementa su complejidad, sin embargo,
el no hacerlo puede causar que sidtemas con cambios significativos en la
explotación de los datos puedan degridar de manera importante su desempeño
(Pérez et al, 1997~1.
I . .
Los manejadores actuales de bases I de datos distribuidas no cuentan con
I . .
mecanismos automáticos que optimicen la ubicación de la información que almacenan en base a su explotación, dsto hace el trabajo del administrador muy
complejo y excede su capacidad para oytimizar el sistema.
-- . _ x Capitulo 2 Descripción del Problema
I I II
La Solución propuesta consiste en el desarrollo de herramientas que proporcionen
las funciones necesarias para: I 1 i 1
Verificar continuamente el estadol I del sistema para determinar cuándo se ha
degradado en su desempeño. I , Optimizar la ubicación de los dato; dentro del sistema, tomando en cuenta los
patrones de explotación.
Migrar los datos entre sitios para pasar entre estados congruentes de la base de datos i
!
Se busca auxiliar al administrador de la BDD en la ejecución de las tareas
necesarias para realizar un rediseño de la distribución.
Para poder reubicar los datos entre los sitios de la BDD, es necesario que los
sitios se comuniquen entre sí a través de una red de comunicaciones. Actualmente
se puede intercambiar información a través de la red haciendo uso de la familia de
protocolos que usa Internet. La familia de protocolos se conoce como TCPIIP.
Los protocolos de TCPllP tienen incorporadas funciones que facilitan la
transferencia de datos a través de la red, sin embargo, no existen herramientas
que tengan las funciones de manejo de transacciones a través de la red. En el
caso de un sistema manejador de bases de datos distribuidas como SiMBaDD, la
falta de herramientas que soporten el manejo de transacciones a traves de la red,
impide garantizar la transferencia de la información, actividad básica en una base
de datos, lo cual es un problema grave.
Un ejemplo de una situación en la cual no se puede garantizar una transferencia
segura y confiable se da comúnmente cuando un usuario intenta establecer
comunicación con algún nodo del cual espera obtener algun servicio que involucra
la transferencia de información.
!
I I 1 !
I
1
i i
!
i !I i
I !
I !
ii I I I
I !
Descripción del Problema Capítulo 2
i
I
una excepción de “tiempo agotado”.
durante la sesión de trabajo, y aunque
El mensaje puede presentarse también
las causas que pueden originar el mensaje
4 Tiempo agotado
Figura 4, Fallo en la transferencia de datos entre sitios. Después de un tiempo “t“ el
servidor no es capaz de atender al cliente y se envía un mensaje de error.
Una de las herramientas más comúnes en Internet es el FTP (File Transfer
Protocol), la herramienta efectúa transmisiones de datos entre dos máquinas,
haciendo la comunicación entre ellas ‘punto a punto. FTP, al igual que otras
herramientas como el correo electrónico (e-mail) hace uso del protocolo TCPIIP. FTP no tiene la función para manejo de \ransacciones, lo cual lo hace inadecuado
para emplearse con éxito en aplicadones de bases de datos, dada su
característica de hacer una comunicación punto a punto, no permitiendo así
difundir los datos a diferentes destinos. Además no ofrece ninguna función para recuperarse ante fallos, siendo imposible, en ocasiones, establecer la
comunicación entre las máquinas que desean intercambiar datos.
1
18
Descripción del Problema Capitulo 2
Partiendo del supuesto de que tenemos I
denotados por O = {Oi,O2,03,04} donde I
un conjunto finito de sitios, denotado por
cada objeto tiene asociado un tamaño
I . N = {ni,n&, un conjunto finito de objetos de una base de datos distribuida
denotado por oit tal que f denota el tabaiio expresado en bytes.
Se establece que cada objeto se enclentra ubicado en algún sitio integrante de la
base de datos distribuida. Para indikar la ubicación de cada objeto usamos la
siguiente nomenclatura: (Q,nj) en doide o, E O y nj E N, e indica que el objeto o,
se encuentra ubicado en el sitio ni. Asi mísmo [oi,nj] indica que el objeto oi debe
ser reubicado en el sitio nj, En la Figura 5 se ilustra a manera de ejemplo, un
estado congruente de una base de datos distribuida y la migración de datos
necesaria para reflejar un rediseño de su distribución.
I . I
Figura 5 Ejemplo de mi&ación de datos entre sitios
- Descripción del Problema
-.Y~,i,UlU L
Como puede observarse los objetos o1 I y 03 se migrarán al sitio nl, mientras que el
I I
I objeto 0 4 se migrará al sitio n3. En la Figura 5 , tambien se aprecia que la
migración del objeto 03 es la que tornará un mayor tiempo y costo de transferencia
dado SU tamaño de 20 Mb. Un error durante la migración cuando ya fue transferido
de forma exitosa el 50% del objeto 0 3 lo cual equivale a 10 Mb), implicaría con las
herramientas actuales de transferencia de datos entre sitios, tener que efectuar la
transferencia nuevamente desde el 0% del objeto, es decir, el 50% enviado previo
al fallo se pierde totalmente al no existir mecanismos que permitan la recuperación
ante fallos, y mucho menos el control de todas las transferencias involucradas en
el ejemplo.
I
I
I El problema de la migración de datos a través de Internet hace evidente la
necesidad de incorporar mecanismos o herramientas que soporten el manejo de
transacciones.
I
20
Capítulo 3
Implementacióh I de la Solución
- 1
I Implementación de la Solución Capítulo 3
I I 3 Implementación !e la Solución
En el capitulo se presentan la implementación de la solución, la arquitectura de
HeMiDl y la descripción de sus módulos, además del protocolo de compromiso
propuesto. I i
3.1 Enfoque de Solución
Para lograr resolver el problema de la transferencia de datos entre sitios a través
de Internet, se diseñó e implementó iHeMiDI, la cual incorpora el concepto de
transacción distribuida. HeMiDl hace énfasis en la caracteristica de atomicidad de
las transacciones y es capaz de recuperarse ante fallos, aumentando así la
confianza y la seguridad de que los datos sean migrados correctamente.
I . I !
Se diseñó HeMiDl de forma tal, que pueda funcionar como un módulo de un
manejador de- bases de datos distribuidas o como una herramienta independiente
para aplicaciones que requieran efectuar transferencias de archivos a manera de
transacciones a través de Internet. Ademas, HeMiDl automáticamente divide una transacción distribuida global en varias subtransacciones, permitiendo que cada
sitio administre la transferencia de los datos que tiene que migrar a algún otro sitio.
También se explota el paralelismo durante la ejecución, debido a que cada sitio
envía o recibe datos, al mismo tiempo &e otros sitios hacen lo mismo. Esto se
logra al usar dos canales de comunicación independientes, uno de ellos es usado para el intercambio de mensajes ende los procesos y otro para el envio y
recepción de archivos. También se iogrh igualar y en algunos casos disminuir el
tiempo de transferencia que se presenta al usar las aplicaciones comerciales que implementan el protocolo de transferencia de archivos FTP (File Transfer
Protocol) de Internet.
I
I
!
Capitulo 3 Implementación de la Solución
I
3.1.1 Arquitectura de HeMiDl
En la sección 3.1 se presenta la arqktectura de HeMiDI, y se describen cada uno
de SUS módulos, en la sección 4.2 se describen la implementación de la herramienta en el lenguaje de prograyación I . JAVA de Sun Microsystems.
arquitectura.
. Optiniizacióri 4 .
. . . . . . .^ _.l. .. .. , . . < Nueva ubicacidii optiniizada Mairiz dc
iiurvv estado
estado
Registros de Recii(xraciúii
I
Figura 6 Arquiibctura de HeMiDl
Implementación de la Solución Capítulo 3
I 3.1.1.1 Módulo de Manejo de Transacciones I
El módulo de Manejo de Transacciones recibe como entradas las direcciones de
sitio, así como SUS descripciones. L u salida está representada por un valor
booleano, que en caso de ser cierto indicará que la migración ha sido llevada a
los sitios a los que debe migrarse la i 1 formación, los datos que se migrarán a cada
cabo éxitosamente, y en caso de ser indicara que no ha podido realizarse la
migración. Su principal función es implementación de un protocolo de
compromiso similar al protocolo de en dos fases (two phase commit)
a través de Internet.
El módulo es el encargado de envial! los destinos y la información a migrar al
módulo de transferencia de datos y Lsperar su respuesta para llamar o no al
módulo de recuperación de errores. EA el módulo se proporcionaran las primitivas
necesarias para el manejo de transdcciones, apoyándose en los modulos de
transferencia de datos y de recuperacidn de errores (Figura 7).
Actual Nueva I 0100 0010
Matrices de Estallo I
Coordinador /
Participante
Participante
Mensajes I ,
Figura 7 Módulo de manejo de transacciones
25 !
! Irnplernentación de la Solución I
Capítulo 3
su destino.
2. Hacer llamados al módulo de
transferencia a realizarse.
El módulo ofrece un nivel de abstracción mas alto que la herramienta FTP y
transacciones. Algunas de las accionds más importantes que efectúa son:
proporciona funciones no encontradas I en el protocolo TCPllP para el manejo de
transferencia de datos, indicando cada vez, una
3.1.1.2 Módulo de Transferencia de datos
Es el encargado.de la migración de !os datos. El módulo de Transferencia de
Datos recibe como entradas la dirección de la máquina que será destinataria de la
información, la descripción de los datos que serán enviados y los datos mismos.
Con las entradas el módulo está listo para enviar los datos. Su salida se
representa por un valor booleano, que en caso de ser cierto significará que la
presentó algún fallo o condición de errorlque impide la transferencia de los datos.
I I I I
transferencia de datos ha sido exitosa, I en caso de ser falso significará que se
Básicamente la función del módulo ks transferir datos de un sitio a otro,
encargándose de todos los aspectos relacionados con la comunicacion entre
sitios, reportando al módulo Manejado) de Transacciones si tuvo éxito o no la
transferencia (Figura 8).
I .
Capítulo 3 - Creación y control
de hilos de ejecución
Figura 8 Módulo d
Algunas de las acciones más importan
I . Establecer un circuito virtual usanu
la transferencia de datos.
2. Hacer reintentos para establecer el
haya problemas con los canales de
3. Reportar las fallas que se presente
indicando si hubo éxito o no.
Implementación de la Solución
Servidor (Receptor)
~ 11- de hilos de ejecución
I
‘ransferencia de Datos
i que realiza son las siguientes:
sockets, entre los sitios que se efectuará
rcuito virtual entre sitios, en caso de que
rnunicación.
al módulo manejador de transacciones,
27
i \ I‘ E I I I I I
II
I I I
I
. .
Capítulo 3
3.1.1.3 Módulo de Recuperación ante Fallos
Implementación de la Solución
I El módulo recibe como entradas los registros de la bitácora, y su salida es un I mensaje al módulo manejador de transacciones en el cual se indica que ha I terminado con éxito la recuperación ante el error. E s llamado por el manejador de
I I
transacciones como resultado de una I falla en alguna de las operaciones que
conforma una transacción o en los casos en que no ha podido llevarse a cabo la
comunicación entre máquinas, al presentarse una falla perdurable.
I Su función es deshacer las operaciones que lograron efectuarse con el objetivo de
mantener la congruencia de la base de datos distribuida. Para ésto, obtiene
información de la bitácora y realiza las acciones necesarias para deshacer los
cambios efectuados. Básicamente en el módulo se determinan las operaciones I 1
necesarias para deshacer una
que no fue comprometida.
que no finalizó correctamente, es decir,
Algunas de las acciones más importante4 que este módulo realiza son:
1. AI inicio de cada sesión verificar ki en la bitácora existen transacciones
incompletas.
2. Deshacer cada uno de los cambios Lfectuados por una transacción que no
puede ser comprometida para así mantener a la base de datos en un estado I
congruente. I I
3. Rehacer pasos intermedios en la transacción, en aquellos casos en que Sc:
presenten fallos no perdurables en los Sitios.
28 I I
Capítulo 3 Implernentación de la Solución
3.1.2 Protocolo de Compromiso Pdopuecto
Con el propósito de garantizar la athmicidad de las transacciones y permitir una
compromiso en dos fases (two phase commit). El protocolo forma parte del módulo
de manejo de transacciones descrito en la sección 3.1.1.1 , a continuación se
presenta la justificación de implementar una variante del protocolo de compromiso
en dos fases, la descripción detallada de las acciones que efectúa el protocolo
además del paradigma de comunicaciones seleccionado. Asi mismo se describe
la terminación de una transacción admlnistrada por HeMiDI.
politica más flexible de compromiso, I se implementó una variante del protocolo de
I I I I .
3.1.2.1 Justificación I
Una base de datos distribuida una mayor disponibilidad de la
información y tolerancia ante fallos. al incluir mecanismos tales como
transacciones y operaciones atómicas.
Una transacción es una secuencia de dperaciones sobre uno o más objetos que
transforma un estado consistente (actual) de la base de datos a un nuevo estado
consistente. En otras palabras una transacción es una unidad de consistencia. I .
Una de las características más importantes de una transacción es la atomicidad, la
en su totalidad. Así puede lograrse que dna secuencia de operaciones, la cual en
esencia no es atómica, aparente serlo de L de un punto de vista externo.
cual se refiere a que: una transacción se 1 leva a cabo en su totalidad, o se cancela
I 29 I
Implementación de la Solución Gapítulo 3
I Para que un SMBDD pueda efectuar I transacciones, es necesario incluir un i componente encargado de dicha atomicidad
que se conoce como "manejador de i transacciones", en dicho componente, debe
implementarse un protocolo de compromiso I operaciones atómicas fundamentales: I (rollback). 1
operaciones atómicas y por consiguiente
que a su vez haga uso de dos
comprometer (commit) y deshacer
I, . . La operación comprometer señala el termino exitoso de la transacción: le indica al manejador de transacciones que se ha I finalizado con éxito una unidad lógica de
trabajo, y que se pueden comprometer I o hacer permanentes todas las modificaciones efectuadas por esa unidad de trabajo.
I
I La Operación deshacer, en cambio, señala el término no exitoso de la transacción:
indica al manejador de transacciones que algo salió mal, que todas las
modificaciones efectuadas hasta el momento por la unidad lógica de trabajo deben
retroceder o anularse.
I I
En la literatura al describirse el protocolo de compromiso en dos fases, se habla
de unidades lógicas de trabajo que deberán ser efectuadas por participantes del
sistema de forma local, es decir, cada b articipante en su propio sitio de forma
independiente a los demás integrantes ddl sistema distribuido. I
Los participantes reportarán a
que llegaron al efectuar las
reportarán al coordinador será a
al coordinador que el participante ha voto por abortar por el contrario, indicará
como coordinador el resultado al
de trabajo. La forma en que
Un voto por comprometer indica terminar su ejecución con éxito, un
coordinador que el participante no ha
terminado con éxito.
I Capítulo 3 I! Implementación de la Solución
i /I
Con los votos, !el sitio designado como coordinador decidirá enviar un voto global
por comprometer o por abortar a todos los participantes. En el protocolo original,
basta con que el coordinador reciba un voto por abortar de algún participante, para
que decida enbiar un voto global por abortar a todos los demás, dando por
anulada la transacción.
I1
II
I
I
En nuestro caso las unidades lógicas de trabajo que los participantes deben
efectuar son subtransacciones que invoiucran a varios sitios a la vez, por IO cua:
cada participante debe conocer el estado en que se encuentran aquellos
participantes con los que interactúa para lograr su propia subtransacción. Por ello
la estructura de :comunicación del protocolo de compromiso en dos fases original
(Figura 9) es inadecuada.
‘I
/I
I Coordiiiador Parlicipanies Coordinador i’ariicipaiiics Coordinador
C 7
I
I I I I I
C O i l l ~ i ~ O i i i C ~ C ~ / I C O ~ l ~ r O l l l i S O /
I aborto I
I aboriar prcparar
l b I I I tic111p0
Fase I I Fast 2
Figura 9 Estructura de comunicación tradicional del protocolo de compromiso en
dos fases. 13
I1 Capítulo 3 Implementación de la Solución
'I
Los participantes al efectuar sus subtransacciones, se comunican entre sí,
rompiendo de esta forma con la estructura de comunicación tradicional del
protocolo de compromiso en dos fases. Es por ello que la implementación usada
por la herramienta de migración de datos para su protocolo de compromiso, es
una variante del protocolo de compromiso en dos fases, en la cual los
participantes se comunican entre si y conocen el voto de los participantes con los
cuales han interahado.
Ii
I1
3.1.2.2 Descripción
Como se mencionó en la sección anterior, la implementación del protocolo de
compromiso usado por HeMiDI, está basada en el protocolo de compromiso en
dos fases. Hay dds diferencias esenciales en la implementación:
I 1
La estructura de comunicación utilizada
Las acciones efectuadas por el protocolo I
En la Figura 9 apreciamos la estructura de comunicación tradicional del protocolo
de compromiso en dos fases. Como se mencionó, la estructura de comunicación
no es adecuada dada la naturaleza de las transacciones que efectúa HeMiDI.
Dichas transacciorles consisten en la transferencia de datos entre sitios a través
de Internet.
!!
Para que un participante Pi lleve a efecto su transacción de forma exitosa debe establecer un circuito virtual con al menos otro participante Pi al cual enviarán
datos. El participante Pi deberá indicar si recibió correctamente los datos enviados
por el participante Pi. Y de esta forma se podrá emitir un voto de compromiso o de
aborto para la trans.acción por parte del participante Pi.
I/
1
li
32
1 Capitulo 3 Implementación de la Solución
I4
1;
Apegándose a la necesidad de comunicación entre participantes se seleccionó e
implementó una' nueva estructura de comunicación (Figura I O ) que se ajusta al
comportamiento' deseado para HeMiDI. En la nueva estructura existe un cambio
en la primera fase. En el protocolo de compromiso en dos fases, el coordinador
envia el mensaje de preparar a todos los participantes y éstos al terminar sus
unidades lógicas de trabajo reportan su voto al coordinador.
En la nueva estructura de comunicación, el coordinador envia el mensaje de
preparar, y losl participantes comienzan a comunicarse entre si para tratar de
terminar sus unidades lógicas de trabajo. Una vez que han acordado que las
transferencias de datos entre ellos finalizaron, se reporta al coordinador el voto. A
partir de ese pijnto se continúa con el protocolo de compromiso en dos fases de la
forma tradicional
II
I1
I
Coordinador 8 1 I'zirticipantcs Coordinador I'articipaiilcs Coiirdiiia<lor
I coiiiproiiiclcr /
I compromclcr I I abortarGloba1 coiiiproiiiiso I
I aborto abortar preparar 11 I I + !
111
I I I
Fasc I I 1:asc 2 tic111po
Figura 10 Estructura de comunicación del protocolo implementado en HeMiDl
I!
1
11 1
33
Capitulo 3 il Implementación de la Solución
El cambio en la estructura de comunicación también influyó en las acciones
efectuadas por !el protocolo. En la Figura 11 se muestra el diagrama de acciones
del protocolo de compromiso en dos fases y, en la Figura 12 el diagrama de
acciones del protocolo de compromiso propuesto.
Figura 11 Acciones del protocolo de compromiso en dos fases
I
34 il
Figura 12. Acciones del protocolo de compromiso propuesto
3.1.2.3 Consideraciones de Finalización del Protocolo
El cambio en la estructura de comunicación, hizo más compleja la implementación
del protocolo, sobre todo al implementar la función deshacer (rollback). Dado que
las transferencias de datos pueden ser muy grandes, se presentó el problema de
qué hacer cuando un participante falla y todos los demás logran terminar su
transferencia”de datos de forma exitosa. De acuerdo a lo establecido por la
35 I!
Capitulo 3 Implementación de la Solución
caracteristica de atomicidad de las transacciones, deben hacerse todas las
operaciones que incluye la transacción o no se llegará a un punto de terminación
válido. Supongamos por ejemplo que el sitio E es coordinador de una transacción
en la cual el sitio A debe enviar una cantidad de datos equivalente a 50 Mb al sitio
B y que el sitio C debe enviar una cantidad de datos equivalente a 300 Kb al sitio D (Figura 13).
li
i
II
,I
Sitio D
Transfcrcticia de datos
Paso dc Mciisdjcs eiiirc procesos -____
Figura 13 Migración de Datos entre Sitios I!
El sitio A termina con éxito su transferencia de datos hacia el sitio B y envía un
voto de comprometer al coordinador en el sitio E. Mientras tanto el sitio C no logra
transferir sus datos al sitio D, y después de una serie de reintentos, vota por
abortar. I(
36 II
Capitulo 3 'I Implementación de la Solución
El coordinador de acuerdo al protocolo de compromiso en dos fases, debe emitir
un voto global por abortar a todos los participantes. Sin embargo en el ejemplo es
claro que no es la mejor decisión dada la cantidad de datos que si lograron ser migrados con %éxito del sitio A al B. Resultaría más costoso deshacer la
transferencia de 50 Mb a causa de no haber podido migrar con éxito 300 Kb. Lo
ideal seria poder comprometer las transferencias que se efectuaron con éxito y
anular o dejar pendientes las que no fueron exitosas.
II
li Si no se efectúa toda la transacción, debe deshacerse para respetar la
característica de atomicidad. Es correcto si se considera que la transferencia de
datos entre los sitios A, B, C y D es una sola transacción, pero puede verse de
otra forma, podemos considerar que existe una transacción global o principal que
contiene transacciones anidadas o subtransacciones. La transferencia de datos
entre los sitioclA y B constituye una subtransacción y a su vez la transferencia de
datos entre los sitios C y D constituye otra subtransacción.
1
' e
AI terminar con éxito la transferencia de datos entre los sitios A y B se da por
terminada esa,subtransacción, por otro lado al no lograr terminar la subtransacción
entre C y D, el coordinador en el sitio E, puede comprometer la subtransacción
1
entre A y B sin violar la característica de atomicidad, pues ahora el coordinador
está administrando subtransacciones y no una transacción global, dejando pendiente la terminación de la transacción entre C y D o abortándola.
~
El protocolo se diseñó para funcionar en ambos casos, en el que se consideran
todas las transferencias de datos como una sola transacción, y en el caso en que se considera de forma independiente a cada transferencia como una
subtransacción. Para ello se determinó el comportamiento de las dos entidades
fundamentales en el protocolo: el coordinador y los participantes. En las
siguientes dos secciones se presenta el pseudocódigo de ambas. En la Figura 13
se muestra el biagrama de acciones del protocolo de compromiso propuesto.
I1
!I
I!
11 37
Capitulo 3 Implementación de la Solución
3.1.2.3.1 Pseudocódigo del coordinador
declara variables
msg: Mensaje !~
ev: Evento
LP: Lista de participantes j
Inicio
enviar mensaje de “preparar“ a todos los participantes en LP
espera (ev) ~
caso de (ev)
llegada de mensaje:
inicio ll guardar mensaje en msg
caso de,’(msg)
voto abortar:
inicio 1
si se considera una transacción global entonces
esdribir registro de abortar en bitácora
env,iar mensaje de “aborto global” a todos los participantes en LP
fin si
fin
voto comprometer: I
inicio
si se considera una transacción global entonces
actualizar lista de participantes que han contestado
si todos los participantes han contestado entonces
escribe registro de comprometer en bitácora II
Capitulo 3 Implementación de la Solución
enviar mensaje de “compromiso global” a los participantes en LP fin si
fin si
fin
il confirmación:
inicio
actdklizar lista de participantes que han confirmado
si todos los participantes en LP han confirmado entonces
escribe registro de “fin,de transaccion” en bitácora
caso contrario
enviar decisión global a los participantes que no han confirmado
fin si
fin caso de
fin
fin
fin caso de II fin
! 3.1.2.3.2 Pseudocódigo del participante
11 declara variables
msg: Mensaje
ev: Evento I/
inicio
espera (ev)
caso de (ev) I/
llegada de mensaje:
inicio
guardar mensaje en msg
caso de (msg) 1
39 I1
Capítulo 3 Implementación de la Solución
preparar:
inicio
si iistb para comprometer entonces
escribir registro de "listo" en la bitácora
enviar mensaje de "voto por comprometer'' al coordinador
caso contrario
escribir registro de "abortar" en la bitácora
e d r mensaje de "voto por abortar" al coordinador
fin si
fin
inicio aborto global:
escribir registro de "aborto" en la bitácora
fin
compromiso global:
inicio
escribir registro de "comprometer" en la bitácora I1
fin
fin caso he
fin
fin caso de
fin
3.2 Implementación 'I
HeMiDl fue desarrollada en el lenguaje de programación JAVA. El lenguaje
permitió un mayor control del funcionamiento de la herramienta y la incorporación
de caracterist,icas no planeadas en un inicio. Algunas de las características de
HeMiDl son:
40 II
Implementación de la Solución Capitulo 3
J Transparencia en el manejo de la concurrencia.
I Transparencia en la verificación de ¡ntegridad.de los datos que viajan a través
de los circuitos virtuales.
Comunicación bidireccional (full duplex) entre los procesos.
Facilidad para el manejo de hilos de ejecución (sub-procesos), con lo cual se
logra el paralelismo en ciertas actividades.
La herramientadesde el punto de vista de la programación consta de clases en las
cuales se irnplementan los diferentes módulos. La Figura 14 muestra las diferentes
clases y su jerarquía.
/ I
I
. . . h a
NISIONES . lnlqler
cliente RX I
,I
Figura No. 14 Jerarquía de clases que integran HeMiDl en notación UML.
41 I¡
-~ e
Capitulo 3 Implementación de la Solución
A continuación: se presenta una: descripción detallada de las etapas que se
presentarón enl;el desarrollo de HeMiDl :.
Etapa de comunicación y envío de bytes a través de sockets.
Etapa de verificación de la integridad de la información y detección de errores
del circuito virtual. Etapa de incorporación de concurrencia y multiprocesamiento a través de hilos
de ejecución.
Etapa de administración de las comunicaciones.
Etapa de implementación del protocolo de compromiso en dos fases.
Etapa de implementación de la bitácora.
il
3.2.1 Comunicación y envío de bytes a través de sockets I1
Implementación de las clases Tx.class y Rx.class, la primera se encarga de la
transmisión de bytes y la segunda de la recepción de bytes. Para ello se coordinan
para establecer un circuito virtual. La clase Rx, lanza un proceso que "escucha" permanentemente el medio de comunicación en un puerto determinado,
esperando una solicitud de conexión. Dicha solicitud es realizada por un proceso
lanzado por la clase Tx, dicho proceso puede ser ejecutado desde un sitio
diferente al de la ejecución del proceso lanzado por Rx, o puede ser lanzado desde el mismo sitio (Figura 15).
I
11
/I Proccso RY cscucliaiido cl iiiedio de coiiiuiiicacióii
Proccso Ts realiza iiiia
solicilod de coiicxióii
Silio A Siiio B
Figura 15 Establecimiento de un circuito virtual entre procesos.
42 i
Capitulo 3 il Implementación de la Solución
Una vez que se ha establecido un circuito virtual entre ambos procesos, se abren
flujos de transmisión de datos, los flujos son bidireccionales para que ambos
procesos se comuniquen entre si. A través del circuito, el proceso lanzado por Tx
enviará un flujo:,de bytes que serán recibidos por el proceso lanzado por Rx. Los
bytes que se envían son el contenido de un archivo cualquiera de entrada al
proceso de Tx. Tx envia a Rx el nombre del archivo y el tamaño del mismo. Rx al
recibir el flujo de bytes los guarda en forma de un archivo que tendrá el mismo nombre que indicó Tx.
!I
3.2.2 Verificación de la integridad de la información y detección de errores
del circuito virtual.
Las clases Rx y Tx incorporan en sus códigos rutinas para detectar errores en el
circuito virtual y además rutinas para verificar los datos que se envían y se
reciben. Los aigoritmos que tiene incorporados para efectuar “checksum”, son
CRC y Adler. Con ellos se verifica en todo momento la integridad de los bytes que
viajan por el circuito virtual. I1
3.2.3 Incorporación de Concurrencia y Multiprocesamiento a traves de hilos
de ejecución. ’,
Las clases Tx y Rx son hilos de ejecución, es decir procesos iniciados desde otros
procesos. La conveniencia de irnplementar esas clases de esa forma es que el
lenguaje JAVA’ proporciona mecanismos automáticos para controlar aspectos
referentes a la concurrencia y al multiprocesamiento de clases que se generen en forma de hilos.
‘I
43
Capitulo 3 Irnplernentacion de la Solución
Entonces, al cambiar las clases Tx y Rx a forma de hilos de ejecución ampliamos
la capacidad de ambas, pues puede haber varios ejemplares de cada una
accediendo a. los mismos recursos (archivos, bitácora) y ejecutándose
concurrentemente. Además se tiene un mayor control sobre los hilos, lo que
permite detener su ejecución, ponerlos en un estado de suspendidos, eliminarlos,
cambiar su pridridad, etc.
3.2.4 Administración de las comunicaciones. II
Las comunicaciones se hacen a través de las clases servidor.class y cliente.class,
en ellas se controla el número de conexiones necesarias para realizar la migración
global. Por ejemplo: supongamos que tenemos que migrar tres objetos de la base
de datos del sitio A al sitio B, lo primero que hacemos es pasar como entrada a la
clase cliente la lista de objetos y el destino al que se migrarán, a continuación se
crea un ejemplar de la clase Tx para cada objeto a migrar, la clase Tx se comporta
como ya hemos explicado.
il
I!
Por otro lado la clase servidor es un proceso que escucha el canal de
comunicaciones y recibe en el ejemplo la notificación de que recibirá tres objetos,
para ello hace tres ejemplares de la clase Rx, cada uno de los ejemplares
establece un circuito virtual con su contraparte Tx. 11
Las clases servidor y cliente administran todos los circuitos virtuales, y haceii
reintentos en los casos en que se den fallos, dado que saben con exactitud qué
circuito falló y qué hay que reenviar. En las Figuras 16 y 17 se muestran los
procesos creados para efectuar una migracion entre sitios. II
44
!I
Capítulo 3 Implementación de la Solución
a.obj
Si t i o D Port ic ipante
S i t i o A ___r Datos Coordinador t Mensajes . .. - ... . .
Receptor
e Emisor
il
i!
Figura 16 )Primera fase de migración
Par t ic ipante '",.., : .. I1 '.... . '.. .
.....
S i t i o c Por t ic iponte
Voto /
:.'
/' /'
I v o t o /
S i t i o A Globol Coordinodor - Mensajes Par t i c i pan tes
.._ - - - - -. t Mensojes Coordinodor
Figura 17 Segunda fase de migración /I
45 11
Capitulo 3 Irnplementación de la Solución
3.2.5 Implementación del protocolo de compromiso.
Las clases servidor y cliente sólo controlan las comunicaciones, es necesario
atiadir dos clases más para adaptar el funcionamiento de HeMiDl al protocolo de
compromiso propuesto. Las clases son cordinador.class y participante.class. En
ellas se implementan respectivamente el código del coordinador del protocolo y de
los participantes del mismo. La implementación se apega al pseudocódigo para
cada una de estas entidades, descrito en secciones anteriores.
El proceso coordinador al iniciar leerá la migración anterior y la nueva y
determinará qué subtransacciones son necesarias para pasar a un nuevo estado
funcional. Los participantes se implementaron como procesos que todo el tiempo
están escuchando a través de un puerto las instrucciones enviadas por el proceso
coordinador.
/I
;i 3.2.6 Implementación de la Bitácora.
1 Existen tres bitácoras implementadas en HeMiDI: la bitácora del coordinador, la
bitácora del participante y una bitácora para registro de los datos que se han
enviado.
Las bitácoras del coordinador y del participante son similares, ambas guardan el
estado actual !de ejecución de los procesos. En caso de fallas el módulo de
recuperación ante fallos se basa en el Ultimo.estado registrado en bitácora para
continuar la ejecución del proceso. Además en las bitácoras se guardan las
decisiones y votos que se han emitido para poder recuperarse sin necesidad de
volver a consu'itar al coordinador o a los participantes del voto que emitieron antes
de la falla.
'I
46 I!
Capitulo 3 Implementación de la Solución
La tercera bitácora sólo se lleva en los procesos participantes, esta tiene como
finalidad registrar el avance de la transferencia de datos entre los sitios. En caso
de presentarse un fallo, el módulo de recuperación de datos iniciará el proceso
nuevamente desde el último registro en la bitácora principal del participante, e
inmediatamente verificará la bitácora para continuar enviando los datos que no
lograron ser enviados antes de la falla. Para registrar un dato como enviado en la
bitácora, se necesita que el sitio destino de los datos confirme su recepción.
I1
3.2.7 Configuración
HeMiDl consta de dos programas: el programa para ejecutar al coordinador y el
programa para ejecutar al participante. El programa coordinador se ejecuta en un
único sitio para cada migración, el sitio es el mismo donde es ejecutado el
programa de .optimización que indica la nueva configuración. Todos los sitios
integrantes del sistema deben ,ejecutar el programa participante al iniciar la
migración. Los programas deben estar en ejecución antes de que se ejecute el
programa coirdinador, el cual debe ejecutarse al finalizar el programa de
optimización.
Ambos programas, el programa coordinador y el programa participante, hacen uso
de archivos de inicialización que permiten al administrador del sistema establecer
10s parámetros necesarios para el funcionamiento de la herramienta,. los archivos
de inicializacion se describen a continuación:
II .
I¡
ij
I/
Archivo de configuración config.mig
¡I Es común tanto para el coordinador como para el participante. En el archivo se
registran los yalores de parámetros importantes para la ejecución de ambos
procesos, tales como el máximo número de reintentos en situaciones de falló, el
número de fragmentos en que se dividirá el archivo a migrar, etc. Un ejemplo del
contenido del archivo es: !I
li 47
-
Capitulo 3 Implementación de la Solución
MAX_INTENTOS=7
TIEMPO_ESPERA=65556
NUMERO-SITIOS=4
NUMERO_OBJETOS=2
TODO-O-NADA=O
FRAGMENTOS=3
I1
Donde MAX-INTENTOS es una variable que indica el número máximo de veces
que el coordinador o el participante deberán reintentar recuperarse ante algún fallo
antes de anular la migración. I'
TIEMPO-ESPERA indica el tiempo en milisegundos que el coordinador o el
participante deberá esperar las respuestas de su contraparte. Por ejemplo, si el
coordinador está esperando el voto de un participante y el tiempo establecido se
excede, entonces el coordinador considerará que el participante no puede emitir
su voto y dará por anulada la transacción de ese participante o la transacción li
global dependiendo del caso.
I
NUMERO-SITIOS y NUMERO - OBJETOS indican respectivamente el número
máximo de sitios que podrían participar en la migración, y el número de objetos
sistema participarán en todas las migraciones, habrá ocasiones en que los datos a
migrar no involucren a todos los sitios, sin embargo la herramienta debe estar
preparada para el caso extremo en que todos los sitios sean participantes en la
migración.
Ij migrables que,se !I encuentran en el sistema. Típicamente no todos los sitios en el
La variable de configuración TODO-O-NADA es una de las más importantes. Los
valores que puede tener son 1 y O. Cuando el administrador establece su valor en
1, significa que la herramienta considerara a todas las transferencias de datos
como integrantes de una sola transacción global. Si se presenta un fallo y alguno
,:
48
Capítulo 3 Implementación de la Solución
de los participantes emite un voto por abortar, entonces todos los demás
participantes recibirán un mensaje de abortar por parte del coordinador.
It
Por otra parte; si el valor es O significa que la herramienta considerará a cada
transferencia de datos entre sitios como una subtransacción y permitirá que se
comprometan aquellas que terminen exitosamente, anulando únicamente aquellas
que no lo logren.
I!
En la sección 3.2.4 se mencionó que la clase cliente divide un archivo de entrada
en "n" nuevos'archivos o fragmentos del original y crea un ejemplar de la clase Tx para cada uno de ellos. La variable de inicialización FRAGMENTOS, indica el
número de divisiones que la clase cliente hará de los archivos de entrada que
reciba, eso significa también que la variable determina el número de hilos de
ejecución (subprocesos) que se encargarán de la transferencia de datos entre
sitios.
,\
il
1 Archivo de configuración sitios.mig
Contiene lasedirecciones URL 'de todos los sitios que conforman el sistema
distribuido. ES esencial tanto para el coordinador como para el participante ya que
sin las direcciones URL no podrían establecerse los circuitos virtuales y no habría
comunicación1 entre sitios. Es importante mencionar que debe estar replicado en
todos los sitiok y debe contener una lista de direcciones URL en un mismo order?.
Un ejemplo de su contenido es el'siguiente:
II
148.208.92.99
148.208.92.100
148.208.92.1 O1
148.208.92.1 31
49
Capitulo 3 ~ Implementación de la Solución
Nótese que Por claridad las direcciones están ordenadas numéricamente de
menor a mayor. Es importante que en todos los sitios se respete el mismo orden para que no,,existan confusiones I' en cuanto a la dirección de los sitios que
participan en la migración.
I/ Archivo de configuración objetosmig
Contiene la descripción de los objetos que pueden ser migrados por HeMiDI. AI igual que el archivo de sitiosmig , el archivo de inicialización debe ser replicado a
todos los sitios en el sistema, y también se debe mantener el mismo orden interno.
Un ejemplo de su contenido es el siguiente:
I1 .
Proveedores. bd l
Partes.bd1 !I
Clientes. bd 1
I.
Matrices de estado
Por último, tenemos dos archivos de inicialización que sólo son usados por el
coordinador, y deben por consiguiente ubicarse únicamente en el sitio en que éste
sea ejecutado, los archivos son: anteriormig y nuevamig. Los archivos
representan dos matrices en las cuales se indica la ubicación de los objetos en los
sitios del sistema. En el archivo antenormig se encuentra la ubicación actual de
los objetos y en el archivo nuevamig se encuentra la nueva ubicación a la que se
desea llegar. ~ El archivo nuevamig es donde se guardan los datos de salida del programa de ,optimización. A continuación se muestra un ejemplo del contenido de ambos archivos:
I!
II
nueva.mig II
1000 0001
0001 1 O00
anteriormig
I/
Capítulo 3 Implementación de la Solución
Las posiciones,en las que aparece,un 1 indican la posición del objeto. Los objetos
están representados por las filas de la matriz y los sitios por las columnas. En el
ejemplo mostrado, el primer objeto se encuentra en el sitio representado por la
primera columna y se desea que sea migrado al sitio representado por la cuarta
columna, de la! misma .forma el segundo objeto representado por la segunda fila:
está ubicado en el sitio representado por la cuarta columna y se desea que sea migrado al sitio representado por la primera columna.
Durante la ejecución de ambos programas se crean archivos para registrar los
eventos en las3 diferentes bitácoras, la bitácora del coordinador se llama bc.log ,
la bitácora del participante bp./og y la bitácora de la transferencia de datos se
llama fragmenfoslog. Todos son archivos temporales, dado que si no son
borrados al iniciar una nueva migración el módulo de recuperación los identificará
y procederá como si se hubiera presentado un error en la ejecución anterior. Es
por ello que son eliminados después de una migración exitosa.
!!
'!
I1
Capítulo 4
Pruebas
li
I I'riiebas
Capítulo 4 ,, \
Se describen las pruebas realizadas y se presentan los resultados obtenidos de
las mismas. Básicamente hay dos tipos de pruebas, aquellas relacionadas con el
manejo de las transacciones y las relacionadas con la transferencia de datos. /I
4.1 Descripción del Ambiente de Pruebas
Una de las metas principales 'es efectuar transacciones distribuidas a través de
Internet. Las transacciones hacen uso de la red Internet la cual está formada por
otros muchos $pos de subredes, 'las cuales varían en sus anchos de banda y
capacidad del canal de comunicación. Se hace aún más evidente en países en
vías.de desarrollo como los de América Mina, países en los que la infraestructura
de comunicaciones no tiene 'aún un desarrollo equiparable a paises
industrializados como Estados Unidos.
'!
El ambiente de pruebas estuvo formado por una red de área local (LAN) instalada
en el Centro Nacional de Investigación y Desarrollo Tecnológico la cual es una red
Ethernet 10 T'(10 Mblseg.) clase "C" con topología tipo estrella. Las máquinas
usadas en las pruebas fueron las siguientes: !I
Una PC IBM a 166 Mhz con 32 Mb de memoria RAM, disco duro de 2 GB y 11
sistema operativo Windows 98 (Sitio $5,).
Una PC a,400 Mhz con 128,Mb de memoria RAM, disco duro de 6 GB y sistema operativo Linux (Sitio S2).
53 II
Pruebas Capítulo 4
En las siguientes dos secciones se presentan las diferentes pruebas realizadas a
HeMiDI, describiendo lo que se pretendió observar con cada una de ellas y los
resultados obtenidos. De forma general se experimentó con la herramienta para
observar su comportamiento en situaciones reales y para comprobar su
funcionamiento ajustándose a los requerimientos establecidos en los objetivos.
I1
I*
4.2 Manejo de Transacciones
Las pruebas re1,acionadas con el manejo de transacciones buscan verificar que la
herramienta pueda efectuar transacciones distribuidas a través de Internet.
HeMiDl implementa un protocolo de compromiso que administra transacciones
asegurándose de que el sistema pase de un estado inicial que es congruente a
uno nuevo que también lo sea. La implementación del protocolo como una
herramienta de migración de datos se hizo identificando a dos entidades
principales: el coordinador de la migración y los participantes en la migración. Las
entidades fueron desarrolladas como módulos separados que se comunican entre
si a través de Internet para efectuar la migración. Además cada entidad implementa todas las funciones necesarias para la comunicación entre procesos a través de la red Internet.
'I
I1
I1 I
Hay posibilidades de que se presenten fallos tanto en el proceso coordinador,
como en los procesos participantes, incluso puede presentarse una falla que
afecte a ambo; (por ejemplo un"corte en el suministro de energía eléctrica), es
por ésto que 1-las pruebas para verificar el buen funcionamiento del protocolo
propuesto, se dividieron en dos partes: las pruebas al coordinador del protocolo y
las pruebas a los participantes del protocolo.
11
I1
54
Pruebas Capítulo 4
4.2.1 Fallas del Coordinador
Durante la mig;ación, el coordinador envia y recibe mensajes de los participantes
que le indican el avance de la misma. AI enviar y recibir mensajes el coordinador va pasando de un estado actual de transición a otro. Los estados de transición del
coordinador se muestran en la Figura 18. Una falla puede presentarse en
cualquier momento y puede ser desde la pérdida del circuito virtual, hasta la
suspensión o terminación forzada del proceso coordinador
I : iiiiciar E : esperar A : abortar C : coiiiproiiieter
Voto comproineter
global
I1
iniciar
Preparar
Voto abo&
.I
Figura 18 Diagrama de estados de transición del proceso coordinador.
Para asegurar que la herramienta pueda recuperarse en cualquier situación de
error, se lleva una bitácora que registra el estado actual en el que se encuentra ei
proceso. Los estados en los que puede encontrarse el proceso coordinador se
listan a continuación:
li
I . En el primer estado, el coordinador envía el nombre de la transacción global,
las instrucciones para la transferencia de datos y el mensaje de preparar a
todos los sitios involucrados en la migración y que se consideran participantes
de la misma.
55
7 PI Liebas Capitulo 4 '
2. En e\ segundo estado, el proceso coordinador se encuentra esperando la respuesta de compromiso o aborto' de cada .uno de los participantes, para poder emitir ;un voto global. AI recibir las respuestas el coordinador guarda en la bitácora cada una de ellas.
3. En el tercer estado, el coordinador decide cuál es su voto global, lo registra en
II
!I
la bitácora y,lo envía a todos los participantes.
4. En el cuarto estado, el coordinador se encuentra nuevamente en espera de
respuestas de los participantes, con las confirmaciones de terminación por
Parte de lossitios involucrados.' Al recibir la confirmación de los participantes el
proceso coordinador termina ,su 'ejecución y se registra el término de la transacción en la bitácora.
Las situaciones de error contempladas, de las cuales se hicieron pruebas de
recuperación se describen a continuación.
Caso de prueba No. 1 !I
Descripción: El proceso coordinador (c,) falla antes de pasar al segundo estado de
transición, es decir, CI presenta un error al enviar los datos necesarios para que
los participantes (p1,p~) inicien la migración, los datos son: el nombre de la
transacción, las instrucciones de los datos a migrar y el mensaje de preparar.
I1
Obietivo: La ptueba busca verificar que c1 al recuperarse, vuelva a establecer los
circuitos virtual.es con PI y p2, y reenvie todos los datos necesarios para iniciar la
migración. En 'la Figura 19 se muestra un diagrama que representa el momento del fallo.
Condiciones de prueba: Dos procesos participantes (pI,p2) y el proceso
coordinador (ci). Los procesos pi! y CI se ejecutan en el sitio sl, el proceso p2 se
ejecuta en el s,¡tio sz . Dos objetos migrables con un tamaño expresado en bytes de
01=2 Mb y 0 2 = 4 Mb.
56
I!
Pruebas Capitulo4 "
Espeeando respuestas
Fallo
Figura 19 Primer caso de prueba. El coordinador (cl) falla en su primera etapa, antes de enviar instrucciones a los participantes (pl,p2). s
Resultado: El resultado es la recuperación de cj, que continúa con el protocolo. En
la Figura B'i del Anexo B se presentan las pantallas de ejecución de e1 antes y después de la recuperación.
Caso de prueba No. 2 ,I
Descripción: El proceso c1 logra enviar todos los datos necesarios para iniciar la
migración perolfalla mientras se encuentra esperando las respuestas de pi y p2.
Obietivo: La prueba busca verificar que c1 al recuperarse vuelva a establecer los
circuitos virtuales con pi y p2, notificando que está listo para recibir sus
respuestas. La Figura 20 muestra un diagrama que representa el caso y las
acciones que efectúa CI al recuperarse. Después de la recuperación cí continuará con el protocolo de manera normal.
I
1
II
i!
Condiciones de prueba: Dos procesos participantes (pl,pz) y el proceso
coordinador (cI). Los procesos PI y CI se ejecutan en el sitio SI, el proceso p2 se
ejecuta en el sitio s2. Dos objetos migrables con un tamaño expresado en bytes de
!'
O I = 2 Mb y 02=4 Mb. II
II 57
1'1 LICV'l>
Capítulo 4
s2 s1
Pz P i Tiempo ''
Fallo
Transferencia de Datos __--- Mensajes - - - - - - -
Figura 20 Segundo Caso de prueba. El coordinador (c,) sufre una falla mientras esperaba la respuesta de los participantes (p1,p2).
Resultado: Elllresultado es la recuperación de c1, verifica la bitácora y continúa
esperando los votos de pi y p2. ,En la Figura 62 del Anexo 6 se presentan las pantallas de ejecución de CI antes y después de la recuperación.
I!.
'!
Caso de prueba No. 3
Descrirxión: El proceso c1 ha recibido las respuestas de p i y p2, y las ha
registrado en ,la bitácora, pero se presenta una falla antes de que logre emitir SL'
voto global y enviarlo a los participantes.
I . I
Obietivo: La prueba busca verificar que c1 al recuperarse lea de la bitácora las
respuestas de p i y p2, con ellas debe decidir si la transacción se compromete o se
aborta, para después establecer nuevamente la comunicación con los sitios
participantes y continuar con el protocolo enviando su voto global. En la Figura 21
se muestra esquemáticamente el caso.
'I
11
Sriiebas Capítulo 4 '
II I
,I
Condiciones de prueba: Dos procesos participantes (pi,pz) y el proceso
coordinador (ci).: Los procesos pi y c1 se ejecutan en el sitio SI, el proceso p2 se
ejecuta en el siti) s2. Dos objetos migrables con un tamaño expresado en bytes de
01=2Mby02=,$Mb. ./
!I s2 SI I
Tiempo Pl
'I Envio de instrucciones
II Esperando respuestas
't i
i Envio de ,voto global-
11
.c i
Transferencia de Datos _____ v Mensajes - - - - - _ _
Fallo
11
II Figura 21 Tercer caso de prueba. El coordinador (cl) falla antes de poder enviar su voto
global a los participantes (p,,p2). 1
Resultado: El resultado es la recuperación de CI. Después de recuperarse verifica
la bitácora, lee los votos de pi y, p2, determina el voto global, y ¡o envia. En la
Figura B3 del' Anexo B se presentan las pantallas de ejecución de CI antes y I1
después de la'irecuperación. ,I
'I 'I
Caso de prueba No. 4
I!
li Descripción: El proceso c1 ha recibido las respuestas de PI y p2 y ha decidido cuá:
es su voto global, pero se presenta una falla mientras envia el voto global a los
participantes, ,de forma que no se tiene la seguridad de que todos recibieron el
mensaje. 1
1
59 1 I1
ri ucud> Capítulo4 II
I
Obietivo: La prueba busca verificar que C.^ lea de la bitácora el voto global al que
habia llegado dntes de que se presentara la falla y lo envíe a todos los
participantes, estableciendo nuevamente todos los circuitos virtuales. En la Figura
22 se muestra esquemáticamente el caso.
Condiciones de prueba: Dos procesos participantes (pl,p2) y el proceso
coordinador (cI)~ Los procesos p i y c1 se ejecutan en el sitio s1, el proceso p2 se
ejecuta en el sitio sz . Dos objetos migrables con un tamaño expresado en bytes de
II I I
01=2 Mb y 02=? 'I Mb.
Fallo
Transferencia de Datos ---_- ---_--_ I/ +
Figura 22 Cubrto caso de prueba. El coordinador (cl) no logra enviar el voto global a
,dodos los participantes (p1,p2), falla durante este proceso.
Resultado: El resultado es la recuperación de c1 Después de recuperarse verifica
la bitácora, lee los votos de pi y p2, determina el voto global, y lo envía
nuevamente. En la Figura B4 del Anexo B se presentan las pantallas de ejecución
de c1 antes y después de la recuperación.
I1 I
II
I1 Ilruebas Capítulo4 , I,
Tiempo 1 P2
Caso de prueba,No. 5
c1 P i
'. Fallo
II
I1 Transferencia de Datos ----- Mensajes - _- - - - -
Figura 23 Quinto caso de prueba. Elcoordinador (c,) falla al recibir las confirmaciones de terminación de los participantes (pi,p2). i
II
il !
I!
I1 61
Pruebas Capítulo 4 1
1 Resultado: El resultado es la recuperación de cl, verifica la bitácora para saber si
envió su voto global, y espera las confirmaciones de pi y p2. En la Figura B5 del
Anexo B se presentan las pantal1a.s de ejecución de c1 antes y después de la
recuperación. 1
II 1)
4.2.2 Fallas de los Participantes
De la misma forma que el proceso coordinador pasa de un estado a otro, e!
proceso participante también tiene estados de transición entre los cuales se
mueve durante 'su ejecución. El proceso participante es ejecutado en todos los
sitios que interv,ienen en la migración, es decir, se ejecuta una copia del proceso
en todos los sidos. En la Figura 24 podemos observar el diagrama de estados de
transición del proceso participante. Las fallas también pueden presentarse en
cualquier momento durante la ejecución del proceso, e involucran desde la pérdida
de las comunicaciones , como la suspensión del proceso de manera forzosa. En el
proceso participante hay más intercambio de mensajes y datos entre procesos que
en el coordinador y por ello hay diferentes casos de prueba.
I/ I/
II
'i
II
I : iiiiciar L : listo
C : coinproiiieter Voto abortat.; Voto coinproineter A : abortar
Cotnproiiiiso global
Confiriliacióii Confirinacióii
Figura 2b Diagrama de estados de transición del proceso participante
li I1
62
I
Capitulo4 11 Pruebas
En el proceso participante también: se lleva una bitácora que registra el estado
actual de ejecu&n del proceso. El registro del estado actual es Útil para efectos
de recuperación en caso de fallos. A continuación se describen los diferentes
estados en que puede encontrarse un proceso participante durante su ejecución:
11
I1
I1 !I 1. En el primer estado el participante está esperando que se establezca el circuito
virtual con el proceso coordinador, el cual puede estar ubicado en un sitio
remoto o eniel mismo sitio de alguno de los participantes. AI establecerse el circuito, el participante espera los datos necesarios para iniciar su migración de
datos y el mensaje de preparar.
!I !
I1 :I
II 2. En el segunao estado, el participante comienza la transferencia de sus datos
hacia el sitio indicado, intercambiando mensajes y esperando una confirmación
del resultado de la transferenci:. El proceso participante no cambia de estado
hasta que todas las transferencias que le corresponden dentro de la migración
han sido efelctuadas o cancelad&.
i
I1
3. En el terceriiestado, decide su'voto en base a la terminación exitosa o fallida
de sus transferencias y lo registra en bitácora.
1 4. En el cuarto! estado el participante envía su voto al coordinador y espera el voto
global. )I 11
5. El quinto estado es el final, en éste dependiendo del voto global se
comprometen los cambios o se anulan, el participante envía un mensaje de confirmación al coordinador y finaliza su ejecución.
Las situaciones de error consideradas para el proceso participante, de las cuales
se hicieron pruebas de recuperación, se describen a continuación. Las pruebas
aplican a todos los ejemplares de este proceso en ejecución:
I1
1 63
Pruebas '! Capitulo 4 '1
P2 ' --
I
I/ I!
- - - - - - - - -. Rekepcion de instrucciones
Transferencia de! datos
!I I I!
I1 I/
Caso de prueba No. 6 I
C1 P i 1 I Fallo
- -__---____________ - - - - - -
DescriDción: El participante (p2) no logra pasar al segundo estado de transición
debido a una falla durante la recepción de las instrucciones necesarias para
efectuar la migración, y el mensaje de preparar por parte del coordinador (cI).
!;
Ij Obietivo: La 6rueba busca verificar que p2 al recuperarse, espere recibir
nuevamente un mensaje de c, y solicite el reenvio de las instrucciones necesarias
para la migraCion y el mensaje de preparar. En la Figura 25 se muestra
esquemáticamente el momento de la falla.
I)
I! Condiciones de prueba: Dos procesos participantes (p1,p2) y el proceso
coordinador ( ~ 1 ) . Los procesos p i y CI se ejecutan en el sitio s1 y el proceso p2 se
ejecuta en el sitio s2. Dos objetos migrables con un tamatio expresado en bytes de I1
I 01=2 Mb y 024 4 Mb.
!I - s i
Figura 25 Sexto caso de prueba. El participante (p2) falla mientras recibe las instrucciones
del coordinador (c,). II
II 64
Pruebas Capitulo 4 I! I
Recepcibndei P2
1 Tiempo
ins~~ucciones _____-_ - -. - - - - -- j
Transferencia de datos
Envio de respuesta
- . . . . - . . - . .- . . -.
II Resultado: El resultado es la recuperación de p2. En la Figura B6 del Anexo B se
presentan las pantallas de ejecución I/ de p2 antes y después de la recuperación. '!
~ 1 C l o, , P i _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
.- - - - - - - - - - - - - - - -
. . -. . -. -. . -. . -. . -. . -. . -. . -. .- . - . . -. . -
Caso de prueba No. 7
Descripción: El proceso p2 ha recibido correctamente las instrucciones necesarias
para efectuar la' migración y el mensaje de preparar y ha iniciado la transferencia
de datos entre sitios cuando se presenta la falla.
Obietivo: La prueba busca verificar que p2 logre recuperarse del fallo. Debe volver
a llamar al módulo de transferencia de datos y éste será el que determine el
estado en el que se encontraba la,,transferencia al momento de la falla. Los casos
de prueba de la transferencia de datos se describen en la sección 4.3. El proceso
p2 esperará a que el módulo de transferencia de datos le notifique de qué forma
terminó la traniferencia y así podrá tomar una decisión sobre su voto. En la Figura
,I
II I1
!I
11
11
I1
Fallo
11 8)
1 Figura 26;Séptimo caso de prueba. El participante (p2) falla mientras realiza una
transferencia de datos. ,/
Capitulo4 ,i Pruebas
.i Resultado: El resultado es la recuperación de pz. Continúa transfiriendo los datos
desde el punto e,n que se presentó el fallo. ,En la Figura 87 del Anexo B se
presentan las pantallas de ejecución de p2 antes y después de la recuperación.
Caso de prueba No. 8
Descripción: El proceso p2 ha terminado la parte de la migración que le
correspondía y de'cide su voto registrándolo en la bitácora, pero se presenta una
falla antes de enviarlo a cl. 11
Obietivo: La prueba busca verificar que el p2 al recuperarse acceda a SU bitácora y
lea el voto al que había llegado antes de la falla, para poder así , enviarlo a CI
cuando éste lo contacte nuevamente y continuar normalmente con el protocolo El
Fallo
Figura 27 Octavo caso de prueba. El participante (p,) falla mientras intentaba enviar su voto al coordinador (c,).
! Condiciones de prueba: Dos procesos participantes (pl,p2) y el proceso
coordinador (c1). Los procesos p l y c1 se ejecutan en el sitio s1 y el proceso p2 se
ejecuta en el sitio s2. Dos objetos migrabies con un tamatio expresado en bytes de
01 = 2 Mb y 0 2 = 4 Mb.
11
1
. . 66
I 'i
I'riiebac I1 Capítulo4 s.
Resultado: El resqltado es la recuperación de p2. Verifica su bitácora y lee el voto
al que había llegado antes del fallo. En la Figura B8 del Anexo B se presentan las
pantallas de ejecución de p2 antes y después de la recuperación. i/
0 Caso de prueba No. 9
Descripción: El proceso p2 ha enviado su voto y se encuentra esperando la
respuesta de c1 cuando se presenta la falla. 1 ¡I Obietivo: La prueba verifica que al recuperarse de la falla, p2 establezca
nuevamente la comunicación con ci y reciba el voto global para continuar así con
el protocolo de forma normal. El caso se muestra en la Figura 28
I1 . . 'I
Fallo
-b Transferencia de Datos -____ 1; Mensajes _ _ - - - - -
por parte del coordinador (c,). Figura 28 Noveno caso de prueba El participante (p2) falla antes de recibir el voto global I/
Condiciones de Iprueba: Dos procesos participantes (p1,pz) y el proceso
coordinador (cl). Los procesos pi y c1 se ejecutan en el sitio SI y el proceso p2 se
ejecuta en el sitio sz . Dos objetos migrables con un tamaño expresado en bytes de I
/I 01 = 2 Mb y 02=4 Mb.
I
Capítulo4 Ii Pruebas
confirmación de terminación.
Resultado: El resu,ltado es la recuperación de p2. Verifica su bitácora y lee el voto
al que habia llegado antes del fallo, y lo reenvía a c1. En la Figura B9 del Anexo B
se presentan las pantallas de ejecución de p2 antes y después de la recuperación.
Caso de prueba NO. 1 O
'1
I \
// Descripción: El proceso pz ha recibido el voto global' y está comprometiendo o
anulando los camgios hechos, y antes de emitir su confirmación a c1 se presenta
la falla. '.
li Objetivo: La prueba verifica que p2 sea capaz de recuperarse y actu.alizar o anular
los cambios hechos dependiendo del voto global registrado en la bitácora, para
después de restablecer la comunicación con cl, y enviar el mensaje de
confirmación. Esquemáticamente se muestra el caso en la Figura 29.
I1
-+ _ _ _ _ _ Transferencia de Datos
b Mensajes
. - - - - - -
- Fallo
I1
Capítulo 4 Pruebas
Condiciones de llprueba: Dos procesos participantes (pi,p2) y el proceso coordinador (cI). Los procesos p i y CT se ejecutan en el sitio s1 y el proceso p2 se
ejecuta en el sitio S Z . Dos objetos migrables con un tamatio expresado en bytes de
4
01 = 2 Mb y 02=4 Mb.
Resultado: El resultado es la recuperación de p2. Verifica su bitácora y envía la
confirmacion de terminación. En la Figura B10 del Anexo B se presentan las
pantallas de ejecukión de p2 antes y después de la recuperación I1
En todos los casos, tanto en las pruebas al proceso coordinador, como al proceso
participante, existe un tiempo máximo de espera para recuperarse, es decir, si por
ejemplo el fallo se da en un participante el coordinador intentará restablecer la
comunicación un número preestablecido de veces y si se encontraba esperando
una respuesta, lo hará sólo un tiempo también predeterminado. Si no se logra en
esos reintentos o en el tiempo determinado, entonces el coordinador aborta
unilateralmente la transacción para todos los participantes o para un participante
en especial, dependiendo de la forma en que se esté ejecutando HeMiDI.
!
I1 '!
I I
i/. I
4.3 Transferencia :de Datos I
HeMiDl también se desarrolló para proporcionar seguridad y confiabilidad en la
transferencia de datos entre sitios. Las pruebas de transferencia de datos buscan
verificar que se cumpla con los requerimientos definidos en los objetivos. En la
implementación de, HeMiDl hay un módulo de transferencia de datos que es el
encargado de todos los aspectos relacionados con la migración de datos entre
!I
I
sitios. !I
Capítulo4 I/ Pruebas
El módulo es llamado por el proceso participante al momento de iniciar la
migración. En él!; se irnplementaron funciones para establecer un circuito virtual
seguro entre sitios, para verificar la integridad de los datos que viajan a través del
circuito virtual y funciones para la recuperación en caso de fallas.
I1
11 I1
Los casos de prueba del módulo son independientes de los del protocolo, ya que
el módulo actua como un auxiliar del proceso participante y lleva su propio registro
de bitácora. En e,' caso de prueba No. 7 se explica que cuando se presenta una
falla en la migración de datos, es el módulo de transferencia de datos el que se
encarga de la recuperación y notifica al participante del resultado.
I1
I1
Básicamente el módulo establece una comunicación punto a punto entre dos sitios
y envía un conjunto de datos a través de un flujo de bytes hacia el otro sitio
utilizando un circuito virtual, su tarea es asegurarse de que los datos lleguen a su
destino y esperarla que dicho destino confirme la llegada de los mismos.
11 1
u Originalmente, el participante envía un solo conjunto de datos, el cual es
particionado para: enviar por separado cada partición a su destino. Durante una
transferencia de datos existen varios subprocesos ejecutándose
concurrentemente, cada uno de ellos enviando una parte del conjunto de datos
original a su destino.
I
'1
I1 . Se explota el paralelismo y se aumenta la confiabilidad en cuanto a que los datos
lleguen correctamente a su destino. En caso de error el módulo debe reintentar
enviar los datos. Existen diferentes casos de prueba, los cuales se presentan en la siguiente
!I
Capí tu lo4 ,, Pruebas
II 'I
4.3.1 Fallas en la transferencia de datos
Existen varias posibilidades en las que el módulo de transferencia de datos debe
estar preparado I1 para recuperarse. A continuación se describen las fallas
consideradas y las acciones que se toman para recuperarse ante ellas.
/I
II Caso de prueba No. 7 7 : El proceso de transferencia de datos falla antes de que
alguno de los subprocesos que envían particiones del conjunto original de datos
confirme su envio. (Figura 30-a). La falla podría ser una caída de los circuitos
virtuales o una interrupción del suministro de energía en el sitio donde se ejecuta el participante que 'I emite ' o recibe los datos.
a
subprocesos emisor
.........................
......................... c.0 ............ ............ u ........
!I
Falla de los circuitos virtuales
subproceso .............................................................................. ............. ........................ ......................................... ........ ......... ',-c+cl
......... ........... ........ ................. receptor
J ................ ........ ........
subproceso .........................................................................................................
........... ....... ;:,,, -c+cl receptor
J
subprocesos Reinteiitos de traiisferencia subproceso
-0t-O -..-. . - - - . . - : ..... ............ receptor
. . . . - ,- ........... ............................ L . . ..........
................. ............................ ................. ....... Transferencia Exilosa
11, Figura 30 a) la falla se presenta antes de recibir alguna confirmación; b) el proceso
reinicia la transferencia de datos al recuperarse.
I! Capítulo 4 Pruebas
........ subproceso -
............................................................................... ...................... ...................... _ ............. ......... ......... ............ ........... ............ ........ receptor
..................
............................
.............................. ........ .......... ;..A,% “0-4J \ Falla de los
circuitos virtuales @ ya confimo
b
sub procesos
........................ ........................ ......... ........................................... .................................. ................. ........... ........ ................... receptor ............ ............ .................... ................
u Figura 31 a) la falla se presenta antes de que todos los subprocesos confirmen, b) el
proceso reenvia las particiones que quedaron pendientes al darse la falla.
Capitulo 4 Pi-uebas
I1 . Como se puede apreciar en la prueba, pueden fallar los subprocesos que envían
las particiones y el módulo se recuperará enviando sólo aquellas que quedaron
pendientes. Lo cual es útil para intentar disminuir los tiempos de transferencia, a
diferencia de lo que sucede con una transferencia típica de datos entre sitios
usando FTP.
I
'I II
lj 4.3.2 Comparación con FTP
FTP ha madurado ampliamente como un estándar en muchos tipos de
computadoras que son usadas para sistemas modernos de comunicación,
esencialmente en los sistemas con acceso a Internet, además de otras redes
similares en las cuales también se usa el protocolo TCPIIP. Sin embargo las
implementaciones varían básicamente en las características soportadas.
I I1
I El desempeño ha :sido extremadamente bueno para transferencias de archivos de
texto entre rnáqui'nas similares, pero para aplicaciones más complicadas como
transferencia de imágenes esto cambia. FTP proporciona un nivel muy bajo de
funcionalidad a causa de los muchos detalles que tienen que ser negociados para
estabilizar las ruta,s de transferencia y el manejo de la misma. FTP no resulta un
protocolo adecuado para ser usado por todo tipo de aplicaciones, un ejemplo que
10 ilustra es el siglliente:
I
I1
Se desea enviar el archivo x.obj del sitio A al sitio B, el archivo tiene un tamatio de
20 Mb. Si hacemok la transferencia usando FTP y se presenta una falla cuando se han logrado enviar por ejemplo 11 Mb al sitio B, es como si esos 11 Mb no
hubieran sido enviados, pues no hay funciones que lleven una bitácora para poder
recuperarse ante: fallas en FTP (Figura 32). Si deseamos continuar la
transferencia, ésta ,comienza nuevamente a enviar los datos desde el inicio del
archivo x.obj , con'lo cual hemos perdido el tiempo que ocupó enviar los anteriores
11Mb y el costo de conexión aumenta por consiguiente."
0
I1
I
'! Pruebas Capítulo 4
Número de Bytes
Enviados
21,342,120 i e 4,636,401
1,580,322 ,
Falla e l sitio a
Tiempo Aplicación Tiempo
Comercial HeMiDl
4:23:17 hrs. 4:10:15 hrs.
0:43:12 hrs. 0:42:33 hrs.
0:28:33 hrs. 0:25: 17 hrs.
52 %enviado sitio b
b
I x.obj (20 MB) x.obj ( I I MB)
I I/ Figura 32 Transferencia de datos entre sitios usando FTP.
Por otra parte, si usamos HeMiDI, el archivo x.obj se divide en "n" partes que
pueden ser definihas en un archivo de configuración, de esta forma HeMiDI.envía
de forma indeperkente cada parte y registra cuáles de ellas han sido enviadas de
forma exitosa a su destino . Si se presentara una falla sólo se tienen que volver a
enviar las partes \que no lograron enviarse antes de la falla, disminuyendo así el
tiempo de transferencia y conexión que tendriamos en el caso anterior usando
FTP. En la Tabla 1 se presentan los resultados obtenidos al evaluar una
aplicación comercial que implementa FTP y el módulo de transferencia de datos
de HeMiDI. El factor que se evaluó fue el tiempo de transferencia, y los resultados
obtenidos indican que se obtiene un mejor desempeño al hacer uso de la
herramienta de migración de datos.
!I
11
II 11
I1 74
Capítulo 4 Pruebas
Las condición necesaria para utilizar HeMiDi es que los archivos que reubica no
sean accesados por otros procesos en el momento en que éstan siendo migrados.
Las restricciones I/ que se consideraron durante las pruebas de HeMiDi son las
siguientes:
Los archivos deben tener un tamaño de al menos 100 Kb. No se aceptan
archivos. vacíos o sin extensión. Tampoco archivos cuyo nombre exceda 12
caracteres ya incluidos el punto y los tres caracteres de la extensión.
El tiempo de espera puede ser de O a infinito en el rango de los números
enteros.
El valor de los parámetros FRAGMENTOS, MAX-INTENTOS,
NUMERO-SITIOS y NUMERO-OBJETOS debe ser un valor entero, en el
caso de FRAGMENTOS puede tomar un valor de 2 a 10, en el caso de MAX-INTENToS de 1 a 10, NUMERO-SITIOS de 2 a 10, y
NUMERO-OBJETOS de 1 a IO.
En el caso de iODO-O-NADA solo puede tomar los valores O y 1. El valor por
defecto es O.
El archivo sitios.mig debe ser exactamente igual en todos los sitios.
El archivo objetos.mi,g puede ser diferente en cada sitio, pero se recomienda
que también sea exactamente el mismo en todos los sitios. Además los
archivos listados en él deben existir en el directorio actual de trabajo.
I1
I
II
.I(
'1 I\
I1
ii
/I
I1 Capítulo 5
'1 Con ci us i ones
11 Conclusiones Capítulo 5 II
5 Conclusiones
Se presentan las conclusiones a las que se llegó al finalizar el trabajo,
enmarcando las' principales aportaciones, y se hacen recomendaciones para
trabajos futuros.
5.1 Conclusion&
Se desarrolló una herramienta para la migración de datos a través de Internet. La
herramienta incorpora el concepto de transacción distribuida, ademas de
seguridad y confiabilidad en la transmisión de datos. La herramienta es una parte
fundamental para la solución del problema de la reubicación optimizada de datos
en un sistema de'bases de datos distribuidas a través de Internet.
4
11
1 La aportación principal del trabajo fue la incorporación del concepto de
transacción distribuida a Internet. Como se mencionó en el capítulo 2, el
problema principal es la falta de funciones o mecanismos proporcionados por el
protocolo TCPllP usado por Internet, que permitan a las aplicaciones de bases de
datos efectuar transacciones a través de la red.
11
//
Se aporta también una modificación al protocolo de compromiso en dos
fases (two phase commit).que ofrece confiabilidad y seguridad en las
transferencias de datos. La modificación al protocolo permite efectuar
transferencias deidatos en condiciones de operación con fallas en los equipos de
cómputo, el medio de transmisión o en el suministro de energía, incorporando un mecanismo de recuperación y aplicando criterios para el reintento de operaciones
necesarias durante la migración de los datos.'
!I.
11
I1
I1 Conclusiones Capítulo 5 it
La herramienta hace uso de dos circuitos virtuales, uno es usado para el paso de
mensajes correspondientes al protocolo de compromiso y otro para la
transferencia de datos, io cual permite obtener una pequeña mejora en el desempeño en comparación con otras aplicaciones comunes de FTP comerciales.
En el capítulo 4 se muestran resultados representativos en los que se muestra el
desempeño de la herramienta. Con estos resultados se garantiza que la
herramienta iguala el desempeño de una herramienta comercial para la
transferencia de archivos.
/I:
!
1
‘I
/I.. . El uso de los dos circuitos virtuales permitió también hacer un mejor uso del ancho
de banda para la transferencia exclusiva de datos. La herramienta explota el
paralelismo en la transferencia de datos, disminuyendo así el tiempo de
transferencia, además se aprovechan las ventajas del lenguaje de programación
Java, haciendo a la herramienta multiplataforma.
I1
Ill Las metas a alcanzar establecidas por los objetivos se cumplieron totalmente. Se
administran transacciones distribuidas que involucran a varios sitios de un sistema
de bases de datos’ distribuidas. Además se ofrece confiabilidad y seguridad en las
transferencias de datos. I1
5.2 Recomendaciones para trabajos futuros
Las siguientes son recomendaciones para mejorar y ampliar las capacidades de la
herramienta desarrollada:
// I 1
I!
Incorporar paralelismo en otros módulos de la herramienta para mejorar su
desempeño y tiempo de ejecución. Actualmente la herramienta hace uso del
paralelismo en el módulo de transferencia de datos y se logró disminuir el
tiempo de transferencia.
Capitulo 5 11 Conclusiones
Añadir a la herramienta un modulo que lleve estadísticas de desempeño. Con
las estadísticas la herramienta podria ser^ capaz de determinar cuál es ei
número ideal de divisiones que deben hacerse del archivo a migrar, cuál es la
mejor hora del día para efectuar las transferencias, y tener tiempos variables
de espera de acuerdo al sitio que presenta más fallos y aquel que no.
!I
II . . .
Diseñar una interfaz gráfica para configurar la herramienta y una interfaz para
ver el desarroilo de la migración entre sitios, ésto como una función adicional
proporcionada..al administrador de la base de datos.
'I
11
Permitir que la herramienta pueda realizar transferencias pendientes que no
pudieron completarse a causa de fallas. II
II 'I
I
Anexo A
Lenguaje JAVA
I
i
I1
ll
/i
il
‘i Lenguaje JAVA Anexo A I1
A Lenguaje I JAVA I1
El anexo trata sobre las características del lenguaje de programación JAVA, el
cual fue usado en el desarrollo de la herramienta, se habla del manejo de sockets
y de los hilos de Jjecución (subprocesos).
A.l Características del lenguaje
Java es un lenguaje de programación orientado a objetos, desarrollado por Sun
Microsystems, una empresa reconocida por sus estaciones de trabajo UNlX de
alta calidad. Moldeado en base a C++, el lenguaje Java se diseñó para ser
pequeño, sencillo ,;y portátil a través de plataformas y sistemas operativos, tanto a
nivel de código fuente como en binario.
/I , >
‘1
I1
Con frecuencia, se dice que Java es un lenguaje para agregar animación a
páginas Web a través de apliquetes (applets). Los apliquetes aparecen en una
página Web de una manera muy parecida a las imágenes, pero a diferencia de
éstas, los appliquetes son dinámicos e interactivos; se utilizan para crear
animaciones, figuras o áreas que pueden responder a entradas del usuario, juegos
u otros efectos interactivos en las mismas páginas Web entre el texto y los
gráficos.
I1
I¡
11
Sin embargo, Java es mucho más que esto. Java se concibió como un lenguaje de
programación completo, donde es posible realizar las mismas tareas y solucionar
el mismo tipo de problemas que con otro lenguaje de programación, como C o
C++.
I/
d Lenguaje JAVA 11
Anexo A
La independencia de la plataforma es una de las ventajas más sobresalientes que
tiene Java sobre otros lenguajes de programación, en particular para los sistemas
que necesitan fu(cionar en varias plataformas. Java mantiene esta independencia
de la plataforma tanto a nivel del código fuente como del binario.
A nivel del códigb fuente, los tipos primitivos de datos de Java tienen tamatios
consistentes, en todas las plataformas de desarrollo. Los fundamentos de
bibliotecas de Java facilitan la escritura del código, el cual puede desplazarse de
plataforma a plataforma sin necesidad de volver a escribirlo para que funcione con
esa plataforma.
11
!
11
La independencia:de la plataforma, sin embargo, no se detiene a nivel del código
fuente. Los archivos binarios Java también son independientes de la plataforma, y
pueden ejecutarse en múltiples plataformas sin necesidad de volver a compilar el
código fuente. Los archivos binarios Java se encuentran en una forma llamada
bytecode. Los bytecodes son un conjunto de instrucciones muy parecidas al
código de máquina, pero que no son especificas para algún procesador.
I . .
'I
11.
'1 Cuando se compila un programa escrito en C o en cualquier otro lenguaje, por lo
general el compilador traduce el programa a códigos de máquina o instrucciones
del procesador que son especificos para el procesador que la computadora
ejecuta. Por lo tafto, si se desea utilizar el mismo programa en otro sistema,
tendrá que volverse a compilar el código fuente original en ese sistema.
I
1
Este panorama es distinto cuando se escribe código Java. El ambiente de
desarrollo Java tiene dos partes: un compilador y un intérprete Java. El compilador
Java toma el programa con el código fuente y en lugar de generar códigos de
máquina para sus archivos fuente, genera un bytecode. Para ejecutar este
programa Java, debe ejecutarse un intérprete de bytecodes, el cual a su vez
ejecuta el programa original.
I1
I
11
Lenguaje JAVA Anexo A 'I
La desventaja dd utilizar bytecodes se halla en la velocidad de ejecución. Puesto
que los programas específicos del sistema corren directamente en el hardware en
que se compilaron, éstos, se ejecutan más rápido que los bytecodes de Java los
que, a su vez, deben ser procesados por el intérprete.
A.2 Sockets en JAVA 11
LOS sockets son': puentes de comunicación entre dos máquinas. Sirven para
establecer circuitos virtuales a través de los cuales puede intercambiarse
información entre sitios.
En Java los sockets se implementan en la clase del mismo nombre. Existen dos
roles principales que puede tomar un socket en Java, puede ser un cliente o un
servidor. En Java los sockets cliente se definen en la clase Socket y los servidores
en la clase ServerSocket. En ambos'casos sólo es necesario indicar el puerto al
que están asociados y en el caso del cliente la dirección de la máquina con la cual
se establecerá el circuito virtual.
ii
, , 11 :I : " "
El siguiente ejemplo muestra la declaración de un socket cliente:
. . i.
class psocket { 1;
I1 Socket misocket = null;
public static void main(String args[ I) { '. '..I, . A , ,. Ir try {
misocket = new Socket("148.208.92.131",6000);
} catch (SocketException e) {
e.printStackTrace();
I!
> ." I
" , . . 1 !I
t
/I 83
Lenguaje JAVA Anexo A
11 involucrado la implementación de mecanismos al estilo de los hilos en forma
manual para darle a un programa una sensación más amistosa a sus usuarios.
/I La máquina virtual de Java permite que una aplicación tenga múltiples hilos de
ejecución corriendo concurrentemente. Cada hilo tiene una prioridad. Los hilos con
mayor prioridad son ejecutados preferentemente a aquéllos con menor prioridad.
Cada hilo puede o no, ser marcado como demonio. Cuando el código de un hilo
crea un nuevo hilo, este último tendrá la misma prioridad del hilo que lo crea, y si
el hilo que lo crea es un demonio, el hilo creado también lo será.
I
I
I1
Cuando inicia la \máquina virtual de Java, existe usualmente un hilo sencillo no
demonio (que tipicamente llama al método main de alguna clase designada). La
máquina virtual de Java continua la ejecución de hilos hasta que alguna de las
siguientes condiciones ocurra:
I1
Y El método exit,de la clase Runtime ha sido llamado.
Todos los hilos no demonios han terminado su ejecución, al terminar
normalmente O al lanzar una excepción que se propaga a través del método
run.
.I1
1 Hay dos formas en Java de crear un nuevo hilo de ejecución. Una es declarar una
clase como subclase de la clase Thread. Esta subclase debe implementar el
método run de la clase Thread. Un ejemplar de esta subclase puede entonces ser
iniciado. I1
Por ejemplo un /Ihilo que compute números primos mayores que un valor
establecido se escribiria de la siguiente forma:
1
Lenguaje JAVA Anexo A
class PrimeThread extends Thread {
long minPrime;
PrimeThread(1ong minPrime) {
this.minPrime = minPrime;
1 public void run() {
I#
< II
II
// computa números primos mayores que minPrime
El siguiente código crearía el hilo y lo iniciaría:
I
PrimeThread p = new PrimeThread(l43); , .
p.start(); 11
La otra forma de crear un hilo es declarar una clase que implemente la interfaz
Runnable. Esa clase implementa entonces el método run. Un ejemplar de la clase
puede entonces ser usado, pasándolo como un argumento cuando se crea el hilo
a través de un ejemplar de la clase Thread. El mismo ejemplo en este otro estilo
se ve de la siguiente manera:
II
class PrimeRun implements Runnable { I/
long mindime;
PrimeRun(1ong minPrime) { 'I
this.minPrime = minPrime;
1
I
86 !I
Anexo B
Anexo B . . . . .
- ... .-
C: \TESIS\final> java coordinador
De: 148.208.92!131 a: 148.208.92.184 obj:2
NUMERO-PARTICIPANTES: 2
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contactando a:,;148.208.92.131 Sitio contactado: 148.208.92.131 Contactando a: 11148.208.92.184 Exception: Connection refused: no further information
C:\TESIS\final>java coordinador
RECUPERACION: La falla fue antes de enviar la migracion
De: 148.208.92.il31 a: 148.208.92.184 obj:2
I¡ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . NUMERO-PARTICIE?ANTES : 2
I' Contactando a: 148.208.92.131 Sitio contactado: 148.208.92.131
Contactando a:!1148.208.92.184 Sitio contactado: 148.208.92.184
Generando Transaccion: tgl Transaccion: tgl
De: 148.208.92.131 a: 148.208.92.184 obj: O
Pulse <ENTER> $ara continuar. . . Subtransacciones enviadas. Esperando resplesta de: 148.208.92.131 Respuesta: 1 Esperando respuesta de: 148.208.92.184
C: \TESIS\final$java coordinador RECUPERACION: La falla fue al esperar las respuestas. Esperando respuesta de: 148.208.92.184 Respuesta: i
Pulse <ENTER> para continuar . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
_ _ _ _ _ _ _ - _ _ _ _ _ _ _ _ - _ _ _ - _ - - _ - - - - - - . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1 89
,~ .. ~~~ . I/
Esperando respuesta de: 148.208.92.131 Respuesta: 1 Esperando rescuesta de: 148.208.92.184 Respuesta: 1 Pulse <ENTER> 'ilpara continuar. . . Votos recibidos.
C: \TESIS\final'> Java coordinador RECUPERACION: La Falla fue antes de enviar el voto global Envio Comprometer Transaccion a:148.208.92.131 Envio Comprom&er Transaccion a: 148.208.92.i84 Pulse <ENTER> para continuar . . . Esperando de: 148.208.92.131 Respuesta: 7
Respuesta: 7
'I
de: 148.208.92.184
1:igura 8.3 E I caordi~indor liillú BIXCS dc c!lviar su voto glal)al.
.. . . . -. . .
Esperando respuesta de: 148.208.92.131 Respuesta: 1 , Esperando respuesta de: 148.208.92.184 Respuesta: i 1' Pulse <ENTER> para continuar . . . Votos recibidos. Envio Comprometer Transaccion a:148.208.92.131
C:\TECIC\final> java coordinador RECUPERACION: La Falla fue al enviar el voto global Envio Comprometer Transaccion a:148.208.92.131 Envio Comprome&er Transaccion a: 148.208.92.184 Pulse <ENTER> para continuar . . . Esperando respüesta de: 148.208.92.131 Respuesta: 7 Esperando respuesta de: 148.208.92.184 Respuesta: 7
I1
'1
!I ' Confirmaciones recibidas
. . __;-A-__. ~ l̂r__-y;gy1i55.1<l
.. . .. . . , . .. . . . .. .. . . . . . . . . . . . .. . . . . . . . .. .. .. L.*,.;..,i.....;...;;.; ___*_- ~ - , .. -_- - I_ ~ i g u r s R.4 EI &ordinador no ~ogm enviar CI voto global a todos 105 participantes. raila diirniite el proceso
90
Esperando8respuesta de: 148.208.92.131 Respuesta;: 1
Respuesta: 1 Pulse <ENSER> para continuar . . . Votos recibidos. Envio Comprometer Transaccion a:148.208.92.131 Envio Comprometer Transaccion a:148.208.92.184 Pulse <ENTER> para continuar.. . Esperando, respuesta de: 148.208.92.131
C:\TESIS\final> java coordinador RECUPERACION: La Falla fue al esperar las confirmaciones Esperando respuesta de: 148.208.92.131 Respuesta: 7 Esperando! respuesta de: 148.208.92.184 Respuesta: 7
Confirmaciones recibidas
Esperando, 1 respuesta de: 148.208.92.184
I
'I
.~ .,.. . , ~~ .. ..... . I_.I. - - - .- . . ___..- - ~ - - I _-..I_.-.-.." .... ,
1 Iiigiirn 1t.S El coordiiiador fdl0 nnics dc recihir las confirmaciones de iermioaci6n de los pariicipantes.
C:\TESISxfinal> java participante <<< Participante Preparado >>> <<< RECEPTOR DE ARCHIVOS >>> Circuito Virtual Establecido.
De: 148.208.92.131 a: 148.208.92.184 obj: O
Pulse <ENTER> para continuar . . . Migracion Recibida.
C:\TESIS\final> java participante < c < Participante Preparado >>> <<< RECEPTOR DE ARCHIVOS >>> Circuitorvirtual Establecido.
De: 148.208.92.131 a: 148.208.92.184 obj: O
Pulse <ENTER> para continuar . . . Migracion Recibida.
t
________i______________-__--_-- _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ - - - - _ - _ _
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ________________--------------- I/
'1
1 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ - - _ _ - - _ - - - - - - - _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ - _ _ _ _ _ _ - - - - - - - - t
_ _ _ _ _ _ _ _ - - - _ _ _ _ _ - - - - _ _ - _ - - - - - - - _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ - _ _ _ _ _ _ - - - - - _ - -
Icigtirn ll.6 El panicipanic fa116 miciilras recibí8 las insinmiones del coordinador. ¡I I
91
.. .. . . . . .. .
Iniciando sub-transaccion Nombre solo: icq c < Dividido > > ' Enviado : icq. 111 Pulse CENTER> para continuar . . . Enviado: icq.2
t
Enviado: icq.2
Pulse CENTER> para continuar . . . Enviado: icq.4 Pulse <ENTER> para continuar . . . Enviado: icq.5
Figurn 8.7 Ei participaiiic faila itiieiitras d i m una iransfcrcncia de dalos
Enviado: icq.4 Pulse <ENTER> para continuar . . . Enviado: icq.5 Pulse <ENTER> para continuar . . . Objeto: icq.exe migrado. Pulse <ENTER> para continuar . . . Sub-transaccion terminada. Mi voto es COMPROMETER Pulse <ENTER> dara continuar.. .
C:\TESIS\finai> lava participante Mi voto es COMJROMETER Pulse <ENTER> para continuar . . . Voto enviado ad coordinador. Esperando el vdto global.. . Pulse <ENTER> para continuar . . .
:I '1
I/
I
r
,'-.
.... - . - . . - . ~ . ~ . . .--.-!1
Figura 8.8 El panieipanie falló mimtrm iiiiciitaba enviar su vola al cwrdinador
92
I
Sub-transaccion terminada. Yi voto es COMPROMETER Pulse <ENTER> para continuar . . . Pulse CENTER> para continuar . . . Voto enviado a l coordinador. Esperando el voto global . . . Pulse <ENTER> para continuar . . .
C:\TESIS\finai> java participante Esperando el voto global . . . Voto global recibido. Diccionario Modificado. .........................................
Objeto: icq.exe borrado.
<temporal> vacio Pulse <ENTER> Itpara continuar. . . Confirmación enviada.
'I Termina proceso participante
1)
________________________________________- ___________________-------_--_-----------
Gigura R.<) El p8riicipariic 11i11ó iliiles dc rccibirel vol0 global. 1
Voto enviado al coordinador. Esperando el voto global . . . Pulse <ENTER> para continuar . . . Voto global recibido. Diccionario Modificado.
Objeto: icq.exe borrado.
<temporal> vacio Pulse <ENTER> 'para continuar . . .
C:\TESIS\final,> java participante Confirmación enviada. Termina proceso participante <temporal> vacio
'I
C:\TESIS\final>
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
I\
I . . .-,
93
Glosario 1
Clase
Clase base Cliente
Código
Ejemplar Jerarquía
Lenguaje de
ij Tipo definido por el usuario en JAVA. Grupo de Objetos que codparten las mismas propiedades y relaciones. En JAVA, una claie se puede utilizar para definir un nuevo tipo de dato. Una clase a partir de la cual se deriva otra. Un objeto o clase que utiliza los servicios de otro objeto o clase. El objeto que proporciona el servicio es el servidor. Conjunto de instrucciones escritas en un lenguaje de programación. Un objeto definido por una clase. Conjunto de clases derivadas de clases base que se pueder. disponer en estructuras tipo árbol con la clase base raíz en la parte superior del árbol. Conjunto de reglas que sirven para escribir instrucciones de Io
Mensaje
Método
Objeto
Parámetro
Programa
Protocolo
Ruta de acceso Servidor
- . programación computadora. Lenguajes de programación orientados a objetos son
C++, Smalltalk, Eiffel, JAVA, etc. Proceso de invocar una operación sobre un objeto. En respuesta a un mensaje, el método correspondiente se ejecuta en el objeto. Un metkaje es el nombre de un método pasado a un ejemplar de un tipol objeto. Cuando se envía un mensaje a un ejemplar de un objeto se llama a uno de sus métodos. Para enviar un mensaje a un ejemplar de un objeto se especifica el objeto y el método que se debe invocar. Una . operación sobre un objeto. Los métodos son implementaciones de las operaciones relevantes a una clase de objetos. Los métodos se invocan en respuesta a mensajes. Combinación de datos y colección de operaciones que actúan sobre los datos. Lista de variables encerradas entre paréntesis que siguen al nombre de una función o un procedimiento. Los parámetros indican el numero y el tipo de argumentos que se envían a la función o procedimiento. Conjunto de instrucciones que indican a la computadora las tareas a realizar. Espkcificación de los modos en que se pueden realizar opeFaciones sobre un objeto. Ruta que se recorre desde el directorio raíz a un subdirectorio esphcífico cuando se trata de localizar un archivo. Un /[objeto que proporciona servicios que se utilizan por otros objetos. Los objetos que utilizan los servicios son clientes.
94
Refe re nc i ás ¡I
[Apers, 19881 P.M.G. Apers. "Data Allocation in Distributed Database Systems" ACM Trans. On Database Systems. Vol. 13, no. 3, pp. 263-304, sept. 1988.
[Bernstein, 198l],P.A. Bernstein, N. Goodman, E. Wong, C.L. Reeve, y J. Rothnie, "Query Processing in a System for Distributed Databases (SDD-I)", ACM Trans. On Database Systems. Vo1.6, no. 4, Dec. 1981.
[Ceri, 19841 S.Ceri y G. Pelagatti. "Distributed Databases: Principles&Systems" New York, N.Y. ; McGraw-Hill, 1984.
[Ceri et al, 19831 S . Ceri, S . Navathe, y G. Wiederhold. "Distribution Design of Logical Database' Schemas" I€€€ Trans. On Software Engineering, vol. SE-9, no. 4, pp. 487-503, july 1983.
[Cornell, 19891 D.!W. Cornell y P.S. Yu. "On Optimal Site Assigment for Relations in the Distributed Database Environment" I€€€ Trans. On Software Engineering, vol. 15, no.8, pp. 100?l-1009, August 1989.
[Date, 19951 C.J! Date. "An Introduction to Database Systems" Volume I, 6Ih ed. Addison-Wesley Publishing Company, 1995.
[Dowdy, 19821 L.W. Dowdy y D.V. Foster. "Comparative Models of the File Asigment Problem" ACM Computing Surveys, vol. 14, no. 2, pp. 287-314, june
'I
I!
!I
1982. 1
[Ferguson, 19931 D. Ferguson, C. Nikolaou y Y. Yemini. "An Economy for Managing Replibated Data in Autonomous Descentralized Systems" Proc. Inf. Symp. On Autonomous Descentralized Systems (ISADS 93), Kawasaki, Japan, 1993. 'I
[Kulkarni, 19911 U.R. Kulkarni y H.K. Jain. "Using Semantic Knowledg of Partitioning and' Allocation of Data in Distributed Databases" Proc. 24"' Hawaii International Conference on Systems Sciences, vol. 2, pp. 146-1 54, 1991.
[Lee, 19921 Heeseok Lee y Oh ia R. Liu Sheng. "Optimal Data Allocation in a Bus Computer Network Proc. Second Workshop on the Management of Replicated Data. pp. 62-65, 1992.
[Litwin, 19821 W. Litwin et al., "SIRIUS System for Distributed Data Management" In Distributed Databases, H.J. Schneider (ed.), North-Holland, 1982.
I1
li
I1
i I!
95
/I [Malone, 19881 T.W. Malone, R.E. Fikes, K.R. Grant y M.T. Howard. "Enterprise: A Market-like TasklScheduler for Distributed Computing Environments" The Ecology of Computati0n;B.A. Huberman (ed.), North-Holland, 1988.
[March, 19951 S.7. March y S. Rho. "Allocating Data and Operations to Nodes in Distributed Database Desing" Transactions on Knowledge and Data Enginnering, vol. 7, no. 2, 1995.
[Muthuraj et al, 19931 R. Muthuraj, S. Chakravarthy, R. Vadarajan y S.B. Navathe. "A'Formal Approach to the Vertical Partitioning Problem in Distributed Database Design'' Proc. I€€€, ISBN:O 8186 3330 1, 1993.
[Navathe et al, 19841 S. Navathe, S. Ceri, G. Wiederhold, y J. Dou. "Vertical Partitioning Algorithms for Database Design" ACM Trans. On Database Systems. Vol. 9, no. 4, pp. 680-710, Dec. 1984.
[Ozsu, 19911 M. Ozsu y P.Valduries "Principles of Distributed Database Systems" Englewood Cliffs,llN.J.: Prentice-Hall, 1991.
[Pérez et al, 1997al Joaquín Pérez, Miguel A. Ortiz, y Rodolfo A. Pazos. "Procesamiento en Paralelo de Consultas en SQL en Bases de Datos Distribuidas" Memorias de la Conferencia lnternacional ClMAF'97, La Habana, Cuba, Marzo 24- 28. 1997.
[Pérez et al, 1997bl Joaquín Pérez, Claudia H. Ibarra, Rodolfo A. Pazos, y Victor Sosa. "Diseño y Arquitectura de un Generador de Prototipos Rápidos a Partir del Esquema de la i/Base de Datos" Memorias de la Conferencia internacional ClMAF'97, La Habana, Cuba, Marzo 24-28, 1997.
[Pérez et al, 1997~1 Joaquín Pérez, Rodolfo A. Pazos, Juan Frausto, y Ana Guadalupe Vélez;' "Fragmentación, Ubicación y Reubicación Dinámica de Datos en Bases de Datos Distribuidas", /I Jornadas de Investigación y Docencia en Bases de Datos, julio 1997, pp. 11 1-120.
[Pérez et al, 19981 Joaquín Pérez, Rodolfo A. Pazos, Guillermo Rodriguez O.,Juan Fausto S,, Sandra Ramirez P., y Fernando Reyes S. "Un Modelo para la Fragmentación Vertical y Reubicación Dinámica en Bases de Datos Distribuidas", Memorias de la Conferencia lnternacional ClMAF'98, La Hababa, Cuba, 1998.
[Pérez, 19991 Joaquín Pérez Ortega, "Integración de la Fragmentación Vertical y Ubicación en el ;Diseño Adaptativo de Bases de Datos Distribuidas'' , Tesis Doctoral, InstitutoiTecnológico y de Estudios Superiores de Monterrey Campus Morelos, Abril 1999, Cuernavaca, Morelos.
[Stonebraker, 19861 Michael Stonebraker, "The Design and Implementation of Distributed INGRES", The lNGRES Papers. Addison-Wesley, Reading, MA, 1986.
ll
I/
I/
I/
96
I¡ [Stonebraker et al, 19941 Michael Stonebraker, Robert Devine, Marcel Kornacker, Witold Litwin, Av¡ Pfeffer, Adam Sah, y Carl Staelin "An Economic Paradigm For Query Processing and Data Migration in Mariposa" Computer Science Div., Dept. of EECS University of California, 1994.
[Tanenbaum, 19971 Andrew S. Tanenbaum, "Redes de Computadoras", Prentice Hall, 3ra Edición, :1997.
[Williams, 19811 : R. Williams, D. Daniels, L. Haas,G. Lapis, B. Lindsay, R. Obermarck, R. Selinger, P. Walker, P. Wilms, y R. Yost. "R*: An Overview of the Architecture, IBMIResearch Report RJ3325", IBM Research Laboratory, San Jose, CA, Dec. 1981. 11 [Wolffson, 19921 O. Wolffson y S. Jajodia. "An Algorithm for Dynamica Data Distribution". Proc. Second Workshop on the Management of Replicated Data, pp.
'!
I/
I1 62-65, 1992.
[Xiaolin, 19881 D; Xiaolin, y F.J. Maryanski. "Data Allocation in a Dynamically Reconfigurable knvironment". froc. Fourth lnternafional Conference on Data Engineering, pp. 74-81, 1998.
[Xuemin, 19951 L. Xuemin, y M. Orlowska. "An Integer Linear Programming Approach to Data Allocation with the Minimun Total Communication Cost in Distributed Database Systems" lnformation Sciences, pp. 1-10, 1995.
97