UNIVERSIDAD POLITECNICA DE VALENCIADepartamento de Sistemas
Inform ticos y Computaci n a o
HIDRA: INVOCACIONES FIABLES Y CONTROL DE CONCURRENCIA
Tesis presentada por: Francesc Daniel Mu oz i Esco n Dirigida
por: Dr. Jos Manuel Bernab u Aub n e e a
Indice General1 Introducci n o 1.1 Introducci n . . . . . . . .
. . . . . . . . . . . o 1.2 Sistemas en cluster . . . . . . . . . .
. . . . . 1.2.1 Concepto de sistema distribuido . . . . 1.2.2
Concepto de sistema en cluster . . . . . 1.3 Alta disponibilidad .
. . . . . . . . . . . . . . 1.3.1 Fallos . . . . . . . . . . . . .
. . . . . 1.3.2 Fiabilidad . . . . . . . . . . . . . . . . 1.3.3
Disponibilidad . . . . . . . . . . . . . 1.3.4 Concepto de alta
disponibilidad . . . . 1.3.5 T cnicas para mejorar la
disponibilidad e 1.4 Replicaci n . . . . . . . . . . . . . . . . .
. . o 1.4.1 Modelos . . . . . . . . . . . . . . . . 1.4.2 Modelo
activo . . . . . . . . . . . . . 1.4.3 Modelo pasivo . . . . . . .
. . . . . . 1.4.4 Modelo coordinador-cohorte . . . . . . 1.4.5
Otros modelos . . . . . . . . . . . . . 1.4.6 Arquitecturas de
soporte a replicaci n . o 1.5 Contribuciones . . . . . . . . . . .
. . . . . . 1.6 Estructura . . . . . . . . . . . . . . . . . . . .
1 1 1 2 3 5 5 5 6 7 7 8 8 9 9 10 11 12 14 16 19 19 20 21 21 22 23
23 26 27 29 30 30
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
2
La arquitectura HIDRA 2.1 Introducci n . . . . . . . . . . . . .
. . . . . . . . o 2.2 Visi n general . . . . . . . . . . . . . . .
. . . . . o 2.2.1 Transporte no able . . . . . . . . . . . . 2.2.2
Monitor de pertenencia . . . . . . . . . . . 2.2.3 Transporte able
. . . . . . . . . . . . . . 2.2.4 ORB . . . . . . . . . . . . . . .
. . . . . 2.3 Modelo de fallos . . . . . . . . . . . . . . . . . .
2.4 Intercomunicaci n . . . . . . . . . . . . . . . . . o 2.4.1 Los
OO.RR.BB. seg n el est ndar CORBA u a 2.4.2 Elementos ausentes en
nuestro ORB . . . . 2.4.3 Elementos a adidos en nuestro ORB . . . .
n 2.5 Soporte para replicaci n . . . . . . . . . . . . . . o
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
i
ii
INDICE GENERAL
2.6 3
2.5.1 Modelo coordinador-cohorte 2.5.2 Gesti n de referencias .
. . o 2.5.3 Problemas a resolver . . . . Conclusiones . . . . . . .
. . . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
31 32 32 34 35 35 36 36 37 37 38 38 38 42 48 48 49 49 62 63 64
65 67 67 68 68 69 71 72 73 74 79 80 84 87 87 89 90 91 93 93 96
Monitor de pertenencia 3.1 Introducci n . . . . . . . . . . . .
. . . . . . . . . . . . . o 3.2 Funciones principales . . . . . . .
. . . . . . . . . . . . . 3.2.1 Detecci n de cadas e
incorporaciones . . . . . . . o 3.2.2 Implementaci n de protocolos
de transporte able o 3.2.3 Cada forzosa . . . . . . . . . . . . . .
. . . . . . 3.2.4 Gesti n de protocolos de reconguraci n . . . . .
o o 3.3 Protocolos existentes . . . . . . . . . . . . . . . . . . .
. 3.3.1 Caracterizaci n . . . . . . . . . . . . . . . . . . . o
3.3.2 Ejemplos . . . . . . . . . . . . . . . . . . . . . . 3.4 HMM:
Un monitor para HIDRA . . . . . . . . . . . . . . 3.4.1 Entorno de
uso . . . . . . . . . . . . . . . . . . . 3.4.2 Componentes
relacionados . . . . . . . . . . . . . 3.4.3 Algoritmo utilizado .
. . . . . . . . . . . . . . . . 3.4.4 Identicadores . . . . . . . .
. . . . . . . . . . . 3.4.5 Coste . . . . . . . . . . . . . . . . .
. . . . . . . 3.4.6 Comparaci n con otros algoritmos . . . . . . .
. . o 3.5 Trabajo futuro . . . . . . . . . . . . . . . . . . . . .
. . . Invocaci n de objetos o 4.1 Introducci n . . . . . . . . . .
. . . . . . . . . . . o 4.2 Invocaci n en el modelo
coordinador-cohorte . . . o 4.2.1 Caractersticas . . . . . . . . .
. . . . . . 4.2.2 Garantas a proporcionar . . . . . . . . . . 4.3
Protocolo IFO . . . . . . . . . . . . . . . . . . . . 4.3.1 Agentes
. . . . . . . . . . . . . . . . . . . 4.3.2 Objetos auxiliares . .
. . . . . . . . . . . . 4.3.3 Descripci n del protocolo . . . . . .
. . . o 4.3.4 Variante para clientes replicados . . . . . . 4.3.5
Variante para operaciones unidireccionales 4.3.6 Variante para
operaciones de s lo lectura . o 4.4 Comportamiento del protocolo en
caso de fallos . . 4.4.1 Cada de un cliente sin r plicas . . . . .
. . e 4.4.2 Cada de un cliente con otras r plicas . . . e 4.4.3
Cada de uno o m s cohortes . . . . . . . . a 4.4.4 Cada del
coordinador . . . . . . . . . . . 4.4.5 Cada del serializador . . .
. . . . . . . . . 4.4.6 Cada de coordinador y cliente . . . . . . .
4.4.7 Cada de coordinador y serializador . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
4
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
INDICE GENERAL
iii
4.5
4.6 5
4.4.8 Cada de todas las r plicas servidoras e 4.4.9 Cada de
todas las r plicas clientes . . e Trabajo relacionado . . . . . . .
. . . . . . . 4.5.1 Modelo pasivo . . . . . . . . . . . . 4.5.2
Modelo activo . . . . . . . . . . . . 4.5.3 Modelo
coordinador-cohorte . . . . . 4.5.4 Soporte transaccional . . . . .
. . . . Conclusiones . . . . . . . . . . . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. 96 . 96 . 97 . 97 . 99 . 100 . 101 . 103 107 107 108 109 110
111 113 115 116 117 117 118 120 122 123 130 130 131 133 135 135 135
136 137 138 138 141 151
Control de concurrencia 5.1 Introducci n . . . . . . . . . . . .
. . . . . . . . . o 5.2 Objetivos . . . . . . . . . . . . . . . . .
. . . . . 5.3 Mecanismos de control de concurrencia . . . . . .
5.3.1 Cerrojos . . . . . . . . . . . . . . . . . . . 5.3.2 Marcas
temporales . . . . . . . . . . . . . 5.3.3 Votaciones y qu rum . .
. . . . . . . . . . o 5.3.4 T cnicas optimistas . . . . . . . . . .
. . . e 5.3.5 Objetos protegidos . . . . . . . . . . . . . 5.4
Potencia expresiva . . . . . . . . . . . . . . . . . 5.5 HCC:
Control de concurrencia en HIDRA . . . . . 5.5.1 Especicaci n de
conictos . . . . . . . . o 5.5.2 Agentes . . . . . . . . . . . . .
. . . . . . 5.5.3 Objetos auxiliares . . . . . . . . . . . . . .
5.5.4 Serializaci n de peticiones . . . . . . . . . o 5.5.5
Tratamiento de operaciones de s lo lectura o 5.5.6 Adici n de r
plicas . . . . . . . . . . . . . o e 5.5.7 Comportamiento en caso
de fallos . . . . . 5.6 Trabajo relacionado . . . . . . . . . . . .
. . . . . Conclusiones 6.1 Contribuciones . . . . . . . . . . 6.1.1
Algoritmos de pertenencia 6.1.2 Modelos de replicaci n . . o 6.1.3
Invocaciones ables . . . 6.1.4 Control de concurrencia . 6.2
Trabajo futuro . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
6
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
Bibliografa Indice de materias
iv
INDICE GENERAL
Indice de Figuras2.1 2.2 2.3 2.4 3.1 3.2 3.3 3.4 3.5 3.6 3.7 4.1
4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10 4.11 4.12 4.13 4.14 4.15 5.1
5.2 5.3 5.4 5.5 5.6 Componentes de la arquitectura HIDRA. . . . . .
. . . . . . . . . Componentes de un ORB. . . . . . . . . . . . . .
. . . . . . . . Pasos a seguir en una invocaci n del modelo
coordinador-cohorte. o Peticiones concurrentes en el modelo
coordinador-cohorte. . . . . Estados y transiciones en el algoritmo
HMM. . . Declaraci n del tipo mensaje utilizado en HMM. o Aut mata
principal del protocolo HMM. . . . . . o Algoritmo del estado
inicial. . . . . . . . . . . . Algoritmo del estado de pasos. . . .
. . . . . . . Algoritmo del estado de monitorizaci n. . . . . . o
Algoritmo del estado de reconguraci n. . . . . . o . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . 20 27 31 33
51 52 54 56 58 60 60 74 75 76 77 78 81 81 82 83 83 85 85 86 86 87
119 119 120 121 122 122
Pasos 1 y 2 en una invocaci n able. . . . . . . . . o Pasos 3 y
4 en una invocaci n able. . . . . . . . . o Paso 5 en una invocaci
n able. . . . . . . . . . . o Pasos 6 y 7 en una invocaci n able. .
. . . . . . . o Pasos 8 a 10 en una invocaci n able. . . . . . . .
o Pasos 1 y 2 en una invocaci n able unidireccional. o Pasos 3 y 4
en una invocaci n able unidireccional. o Paso 5 en una invocaci n
able unidireccional. . . o Pasos 6 y 7 en una invocaci n able
unidireccional. o Paso 8 en una invocaci n able unidireccional. . .
o Pasos 1 y 2 en una invocaci n able de lectura. . . o Paso 3 en
una invocaci n able de lectura. . . . . . o Paso 4 en una invocaci
n able de lectura. . . . . . o Pasos 5 y 6 en una invocaci n able
de lectura. . . o Paso 7 en una invocaci n able de lectura. . . . .
. o
Sintaxis de la declaraci n extendida de una operaci n. . . . . .
. . . . . . o o Interfaz de ejemplo con poltica: (a) Exclusi n
mutua. (b) Lectores-escritor. o Interfaz del objeto CCS generado
por el compilador de IDL extendido. . . . Interfaz del objeto
serializador. . . . . . . . . . . . . . . . . . . . . . . . .
Interfaz de los agentes del serializador. . . . . . . . . . . . . .
. . . . . . . Interfaz del serializador con soporte para agentes. .
. . . . . . . . . . . . .
v
vi
INDICE DE FIGURAS
Indice de Tablas1.1 3.1 3.2 3.3 Clases de disponibilidad. . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . Principales
caractersticas de algunos protocolos de pertenencia. . . . . . . .
. . N mero de mensajes intercambiados en las diferentes fases del
protocolo. . . . . u N mero de mensajes utilizados en los
principales algoritmos. . . . . . . . . . . . u 7 43 63 64
vii
viii
INDICE DE TABLAS
RESUMEN
ix
ABSTRACT HIDRA is an architecture that provides support for
highly available objects in distributed systems. To detect the
failures and reactivations of the nodes that compose a distributed
system, a cluster membership protocol is needed. HMM is a cluster
membership protocol that is used in HIDRA to assist its components
in the reconguration tasks that must be taken when a membership
change arises. It is the rst of the HIDRA components described in
this thesis. The support for high availability is usually based on
object replication. Several replication models exist. The
coordinator-cohort model is a combination of several
characteristics of the passive and active ones. It presents some
advantages when it is compared to each one of the other two models,
but it requires a distributed concurrency control mechanism and an
invocation mechanism that ensures atomicity and consistency. A
design of both mechanisms is also presented in this work, allowing
a native implementation of this replication model. Thus, HIDRA is
the rst architecture that provides direct support for the
coordinator-cohort replication model, without needing its
implementation on top of the active model. RESUMEN HIDRA es una
arquitectura que proporciona soporte para objetos altamente
disponibles en sistemas distribuidos. Para detectar los fallos y
reactivaciones de los nodos que componen un sistema distribuido, un
protocolo de pertenencia a cluster resulta necesario. HMM es un
protocolo de este tipo utilizado en HIDRA para dirigir a sus
componentes en las tareas de reconguraci n o que deben ser tomadas
en caso de que ocurra un cambio en el conjunto de pertenencia. Es
el primero de los componentes de HIDRA descrito en esta tesis. El
soporte para alta disponibilidad est normalmente basado en
replicaci n de objetos. Existen a o m ltiples modelos de replicaci
n. El modelo coordinador-cohorte es una combinaci n de algunas u o
o caractersticas de los modelos activo y pasivo. Presenta varias
ventajas si se compara con cualquie ra de los otros dos modelos
mencionados, pero requiere un mecanismo de control de concurrencia
distribuido y un mecanismo de invocaci n que garantice atomicidad y
consistencia. Un dise o o n de ambos mecanismos se presenta en este
trabajo, permitiendo una implementaci n nativa de este o modelo de
replicaci n. As, HIDRA es la primera arquitectura que facilita
soporte directo para o el modelo de replicaci n
coordinador-cohorte, sin necesidad de implementarlo sobre el modelo
o activo. RESUM HIDRA es una arquitectura que proporciona suport
per a objectes altament disponibles en sistemes distributs. Per a
detectar fallades i reactivacions dels nodes que composen un
sistema distribut, un protocol de pertinenc a a cluster resulta
necessari. HMM es un protocol daquest tipus utilitzat en HIDRA per
a dirigir als seus components en les tasques de reconguraci que han
de o el primer dels components ser preses en cas de que oc` rrega
un canvi al conjunt de pertinenc a. Es o dHIDRA descrit en aquesta
tesi. El suport per a alta disponibilitat est` normalment basat en
replicaci dobjectes. Existeixen a o m ltiples models de replicaci .
El model coordinador-cohort es una combinaci dalgunes caracu o o
terstiques dels models actiu i passiu. Presenta m ltiples
avantatges si es compara amb qualsevol u
x
RESUMEN
dels altres dos models esmentats, per` necessita un mecanisme de
control de concurr` ncia distrio e but i un mecanisme dinvocaci que
garantitze atomicitat i consist` ncia. Un disseny dambdos o e
mecanismes es presenta en aquest treball, permetent una
implementaci nadiua daquest model o de replicaci . Aix, HIDRA es la
primera arquitectura que facilita suport directe per al model de o
replicaci coordinador-cohort, sense necessitat dimplantar-lo per
damunt del model actiu. o
Captulo 1
Introducci n o1.1 Introducci n oLa continua mejora en las
prestaciones ofrecidas por los ordenadores personales, as como la
reducci n de sus costes de fabricaci n permiten que se pueda
disponer de m quinas con alta cao o a pacidad de procesamiento a un
coste reducido. Esto, unido a los avances que tambi n se han e dado
en las redes de area local en la ultima d cada, aunque no tan
espectaculares como los que e han disfrutado los procesadores,
permite que actualmente se pueda disponer de un grupo de
ordenadores para realizar conjuntamente un determinado servicio.
Con ello ha surgido el concepto de sistema en cluster que, como
cualquier otra variante de un sistema distribuido, presenta algunas
caractersticas que lo hacen recomendable para mejorar la
disponibilidad de los servicios que ofrezca. En esta tesis se va a
describir parte de la arquitectura HIDRA [GMB97b], pensada para
ofrecer soporte de alta disponibilidad y f cilmente implementable
sobre un sistema en cluster. En cona creto, se describir n los
componentes de HIDRA relacionados con la gesti n de la pertenencia
en a o el conjunto de m quinas que formen el cluster, con la
invocaci n de objetos replicados y con el a o control de
concurrencia en ese protocolo de invocaci n de objetos. o Existen m
ltiples alternativas para proporcionar soporte para alta
disponibilidad, casi todas u ellas basadas en la replicaci n de
componentes. En HIDRA se ha optado por utilizar un modelo o
orientado a objetos, empleando un ORB como base de la arquitectura
y el modelo de replicaci n o coordinador-cohorte para gestionar la
replicaci n de objetos. o En este captulo se van a presentar
algunos conceptos preliminares que ser necesario conocer a antes de
describir en detalle los componentes que forman parte de la
arquitectura HIDRA. As, se empezar en la secci n 1.2 presentando el
concepto de sistema en cluster, relacion ndolo con el de a o a
sistema distribuido. A continuaci n, la secci n 1.3 describe qu se
entiende por alta disponibilidad o o e y c mo puede conseguirse
esta empleando replicaci n (secci n 1.4). Por ultimo, las dos
secciones o o o restantes presentan las contribuciones de esta
tesis y la organizaci n de los captulos que siguen. o
1.2 Sistemas en clusterLos sistemas en cluster son un caso
particular de sistema distribuido donde se presta especial inter s
en proporcionar una imagen de sistema unico, es decir, para un
ordenador o un usuario e
1
2
CAPITULO 1. INTRODUCCION
externo al conjunto de m quinas que formen el cluster, dicho
conjunto debe ofrecer la imagen de a que en el s lo hay una m
quina. o a
1.2.1 Concepto de sistema distribuidoDeniciones sobre qu es un
sistema distribuido pueden encontrarse muchas. Cada una de ellas e
puede dedicar atenci n especial a un determinado detalle de este
tipo de sistemas, seg n el contexo u to en el que aparezca. En
[CDK94] se da una denici n sucientemente general, que ligeramente o
adaptada dice lo siguiente: un sistema distribuido es una colecci
on de ordenadores aut nomos o interconectados mediante una red y
equipados con unos programas que permiten a estos ordenadores
coordinar sus actividades y compartir sus recursos (equipos,
programas y datos). En particular, esta denici n resulta adecuada
porque no da preferencia a ning n modelo de prograo u maci n,
unicamente exige la presencia de m ltiples m quinas y una red de
interconexi n y da a o u a o entender que los ordenadores empleados
deben colaborar hacia un objetivo com n. Deniciones u similares a
esta podremos encontrarlas en [Gal00], [Sta98] y [Nut97], aunque
este ultimo preere el t rmino multicomputador para hacer referencia
a este tipo de sistemas, englobando tanto a los e sistemas
distribuidos que aparecen en las deniciones citadas anteriormente
como a los sistemas multiprocesadores de memoria compartida. La
denici n que hemos elegido permite englobar o tanto a procesadores
con memoria compartida como a ordenadores con memoria privada. El
modelo de programaci n b sico en un sistema distribuido, seg n el
mecanismo de intero a u comunicaci n de procesos, estar basado en
intercambio de mensajes. Sin embargo, es mejor o a no dejar esto
patente en la denici n de lo que es un sistema distribuido (v anse
las deniciones o e de [SS94, SG98] para encontrar ejemplos donde se
dice explcitamente que no puede compartirse memoria entre los
procesadores) ya que sobre este modelo b sico se pueden dar
implementaciones a de memoria compartida distribuida [Cho94, Bat98]
que contradiran la denici n dada. o Pero la caracterstica m s
importante de un sistema distribuido, al menos en relaci n a lo que
a o va a describirse en esta tesis, es su capacidad para tolerar
fallos en algunos de sus componentes. A diferencia de lo que ocurre
en un sistema centralizado, en un sistema distribuido habr m
ltiples a u unidades de c mputo y de gesti n de recursos que ser n
independientes (al menos en cuanto a o o a su probabilidad de
fallo). Por tanto, la probabilidad de que falle el sistema en su
totalidad ser a menor. Aun as, debe aplicarse un esfuerzo especial
en la gesti n del sistema para conseguir que o las aplicaciones que
se ejecuten en el no adviertan el fallo de algunos de sus
componentes. Para ello deber n emplearse t cnicas de alta
disponibilidad, como la replicaci n de componentes, que a e o
permitir n que el sistema siga comport ndose de acuerdo con sus
especicaciones incluso cuando a a alguno de sus elementos falle. En
caso de no adoptar estas t cnicas, de poco servira utilizar un e
conjunto de m quinas para proporcionar un determinado servicio,
pues el fallo de una cualquiera a de ellas podra tener como
resultado que el servicio proporcionado dejase de estar disponible.
Otra ventaja de estos sistemas radica en su escalabilidad, es
decir, en la posibilidad de aumentar la capacidad de servicio de un
sistema de este tipo. Para ello basta adquirir nuevos ordenadores y
conectarlos al sistema que ya exista, recongur ndolo para que estas
nuevas unidades pasen a a ser tambi n utilizadas. En los sistemas
centralizados tradicionales no exista m s alternativa que e a
adquirir una m quina m s potente que reemplazase a la ya existente.
a a
1.2. SISTEMAS EN CLUSTER
3
1.2.2 Concepto de sistema en clusterUn sistema en cluster es un
caso particular de sistema distribuido en el que:
Se proporciona la imagen de sistema unico. Es decir, aquellos
componentes externos al sistema (aplicaciones, usuarios y otros
sistemas) deben percibir la imagen de que este est a formado por
una sola m quina. a Adem s, cuando esta imagen es proporcionada por
el n cleo del sistema operativo empleado a u en dicho sistema
distribuido, las aplicaciones que se ejecuten en el tambi n
percibir n dicha e a imagen. Esto facilita en cierta medida la
tarea de los programadores, que no tendr n que a preocuparse por
algunos detalles a la hora de desarrollar dichas aplicaciones. De
todas formas, esto no siempre resultar recomendable ya que al
ocultar dichos detalles y dar una a imagen ciertamente diferente a
la real, el programador podr adoptar decisiones de dise o a n que
conduzcan a un peor rendimiento de la aplicaci n resultante. Sin
embargo, s que resulta o agradable a la hora de portar aplicaciones
pensadas para otro tipo de sistemas, ya que en ese caso podr n
funcionar con el soporte proporcionado. a Existe una red de
interconexi n de los ordenadores que compongan el cluster con
elevadas o prestaciones (retardo de transmisi n muy bajo y elevado
ancho de banda). Ejemplos de o este tipo son las redes SCI [Dol96],
especicadas en el est ndar ANSI/IEEE 1596-1992 a Scalable Coherent
Interconnect o las redes Myrinet, creadas por la compa a Myricom, n
pero estandarizadas posteriormente en la especicaci n ANSI/VITA
26-1998. o Como caractersticas de las redes SCI cabe citar: Se
utilizan mensajes cortos, con 16 bytes de cabecera y 16, 64 o 256
bytes de contenido util. Ancho de banda entre 1 y 4 Gbits/segundo.
Cables de interconexi n dobles (bidireccionales). En cada hilo s lo
se puede transo o mitir informaci n en un sentido. o Protocolos de
comunicaci n propios que dan soporte tanto a modelos de programaci
n o o de memoria compartida como a intercambio de mensajes. Retardo
de transmisi n entre 1 y 2 microsegundos en modo memoria compartida
y o entre 5 y 10 microsegundos en modo de intercambio de mensajes.
(Estos son los datos declarados por el fabricante, puede que en
mediciones reales sean superiores seg n el u tipo de m quina
empleada). a Direcciones de nodo de 16 bits. Esto ofrece un m ximo
de 65536 nodos interconectaa dos en una misma red SCI. Por su parte
las redes Myrinet ofrecen estas propiedades: Ancho de banda de 2
Gbits/segundo. Cables de interconexi n bidireccionales. o
4
CAPITULO 1. INTRODUCCION
Servicio de monitorizaci n de m quinas integrado en los propios
protocolos de comuo a nicaci n. Esto facilita la detecci n de
fallos y simplicara la implementaci n de un o o o protocolo de
pertenencia. Posibilidad de cambios de ruta efectuados por los
propios switches Myrinet en caso de cada de alguna m quina
conectada a la red. a Retardo de transmisi n de mensajes entre
13.37 y 21 microsegundos. Estos son resulo tados obtenidos en
algunos benchmarks. El uso de una red de estas caractersticas tiene
como objetivo aumentar el rendimiento del sistema. En la pr ctica
no existe ning n inconveniente que impida utilizar una red de area
a u local convencional, como una Ethernet 100Mb/s para realizar la
interconexi n. o Existen otras caractersticas de estos sistemas,
pero en la pr ctica se derivan de las dos que a acabamos de citar y
no hay que prestarles excesiva atenci n para calicar a un sistema
distribuido o como cluster o no. Por ejemplo, cabe resaltar:
Por ser un caso particular de un sistema distribuido, al igual
que en ellos, en un sistema en cluster se podr n plantear ciertos
objetivos que no pueden ser conseguidos de igual manera utilizando
a una sola m quina. De entre ellos ya hemos citado la facilidad
para hacer el sistema escalable, pero a tambi n podramos citar el
acceso mucho m s c modo a los recursos ubicados en otras m quinas e
a o a (siempre y cuando tambi n formen parte del cluster), as como
la opci n de realizar un reparto de e o carga entre los ordenadores
que compongan el cluster de manera que todos ellos deban soportar
un conjunto de aplicaciones a ejecutar que est acorde con sus
posibilidades, mejorando as el e rendimiento global del
sistema.
Uso de una red privada. En [P98] se distingue entre clusters
cerrados y expuestos. Para este autor, en un cluster cerrado, todos
los ordenadores del cluster est n interconectados a mediante una
red privada de altas prestaciones, que resulta inaccesible para las
m quinas a que no pertenezcan al cluster. El acceso al sistema se
realizar utilizando otra red a la a que estar n conectados algunos
de los nodos del cluster (aquellos que tengan al menos dos a
interfaces de red). Los clusters expuestos son los que no utilizan
una red privada, permitiendo que los mensajes entre nodos del
cluster sean transmitidos por la misma red a la que tendr n acceso
las a m quinas externas a el. a El objetivo que se pretende
conseguir con el uso de una red privada es la mejora de las
prestaciones en las comunicaciones internas. Al reducir el tr co en
la red utilizada para las a conexiones internas, habr menos
colisiones en el acceso a ella (aunque esto depende del a tipo de
red utilizada) y la cantidad de informaci n real transferida podr
ser mayor. o a Anonimia de los nodos: Esto signica que los nodos
que componen el cluster no deben recibir un nombre en los servicios
de nominaci n empleados fuera del cluster. Con ello se o evita el
acceso individual a cada uno de ellos. Esto es una consecuencia de
la imagen de sistema unico. Tambi n puede ayudar a la pre e sentaci
n de anonimia el uso de una red privada interna. o
1.3. ALTA DISPONIBILIDAD
5
Pero el objetivo principal, al menos para el contexto de esta
tesis, ser la mejora de la disponia bilidad de las aplicaciones que
se ejecuten en este sistema. Este concepto se explica en detalle en
la pr xima secci n. o o
1.3 Alta disponibilidadPara entender el concepto de alta
disponibilidad es necesario presentar previamente los conceptos de
fallo, abilidad y disponibilidad que aparecen a continuaci n. Tras
ello se denir el concepto o a de alta disponibilidad y se describir
de qu forma es posible obtenerla. a e
1.3.1 FallosSeg n [Nel90], se da un fallo en un sistema cuando
este presenta incapacidad para desarrollar u aquellas funciones
para las que fue dise ado debido a errores en el o en su entorno,
que hayan n 1 como una condici n an mala y el sido causados por
diferentes faltas. A su vez, dene la falta o o error como la
manifestaci n de una falta en un sistema, donde el estado de un
componente diferir o a del previsto. Nuestro objetivo ser que un
sistema tolere faltas, de manera que nunca presente fallos. Para a
ello, se podra empezar reduciendo a un mnimo la posibilidad de que
se den esas faltas (es decir, que el comportamiento especicado del
sistema o de sus componentes pueda extenderse al mayor n mero
posible de situaciones, por lo que se disminuir la probabilidad de
que ocurran condiciones u a an malas). Sin embargo, existen ciertos
tipos de faltas que ser imposible evitar: errores del o a propio
usuario, errores de implementaci n, etc. Ante estas faltas, debera
evitarse su conversi n o o en errores. Para ello, los componentes
que sufran las faltas deberan ser capaces de evitar que otros
componentes relacionados con ellos apreciasen la ocurrencia de la
falta. Como resultado, en [Cri91a] se dice que un sistema es
tolerante a faltas (o sin fallos) cuando este exhibe un
comportamiento bien denido en caso de faltas o enmascara las faltas
de sus componentes a sus usuarios (es decir, contin a facilitando
sus servicios est ndar a pesar de la u a ocurrencia de dichas
faltas). N tese que para que un servicio sea tolerante a faltas,
forzosamente o deben serlo tambi n todos aquellos servicios de los
cuales dependa, es decir, todos aquellos que e llegue a necesitar
en alg n momento. u Como veremos posteriormente, es pr cticamente
imposible tener un sistema completamente a tolerante a faltas. Las
t cnicas que pueden utilizarse para enmascarar los faltas no son
siempre e perfectas y algunos fallos s podr n ser apreciados por
otros componentes o por el usuario de a nuestro sistema. Por tanto,
m s que hablar de sistemas tolerantes a faltas, hoy da se preere a
utilizar t rminos relacionados con la abilidad y la disponibilidad
de un sistema. e
1.3.2 FiabilidadSeg n la denici n dada en [Nel90], debe
entenderse por abilidad de un sistema, F(t), la probau o bilidad
condicionada de que este pueda desarrollar sus funciones
correctamente en el instante t, sabiendo que era operativo en el
instante t=0.El t rmino ingl s para referirse a este concepto es
fault que en nuestro idioma tambi n suele traducirse como e e e
fallo. Se ha preferido utilizar el t rmino falta, que aunque no sea
la traducci n habitual evita la ambig edad al usar e o u la palabra
fallo.1
6
CAPITULO 1. INTRODUCCION
Esta abilidad depende por una parte de las faltas que puedan
darse en el sistema y por otra de los mecanismos que este posea
para evitar que se maniesten fallos cuando se den esas faltas. Para
poder clasicar a un sistema como completamente able, este debera
tener mecanismos que evitasen la aparici n de cualquier fallo. Lo
que se conoce como mecanismos de recuperaci on o autom tica. a En
la pr ctica, vuelve a ser altamente improbable tener a un sistema
con capacidad para evitar a todos los tipos posibles de fallos. Por
ello, la abilidad de un sistema se suele dar num ricamente e como
una probabilidad cuyo valor viene dado por la siguiente expresi n:
o
Es decir, la suma de la probabilidad de que el sistema no tenga
ninguna falta durante un cierto intervalo de tiempo m s la
probabilidad de que se d un funcionamiento correcto en caso de
falta a e multiplicada por la probabilidad de que se d una falta
durante ese intervalo. La probabilidad e de que se tenga un
funcionamiento correcto en caso de faltas depender de los
mecanismos de a recuperaci n autom tica que posea el sistema. o a
Si nuestro objetivo era tolerar faltas y utilizamos el concepto
abilidad para explicar el grado de tolerancia a faltas que ofrece
un sistema determinado ya tendremos al menos una herramienta para
determinar la calidad de dicho sistema. Sin embargo, la abilidad
deja algunas cosas sin medir. En concreto, conoceremos la
probabilidad de que nuestro sistema llegue a manifestar alg n
fallo, pero desconoceremos cu nto tiempo emplearemos en dejar de
nuevo al sistema en u a un estado operativo. Por este motivo,
cuando se habla de tolerancia a faltas para componentes software se
suele utilizar otro concepto complementario que s recoge la duraci
n de los periodos o no operativos (o de recuperaci n). Este
concepto es la disponibilidad. o
1.3.3 DisponibilidadLa disponibilidad [Nel90] de un sistema o
servicio es la probabilidad de que este se encuentre operativo en
un determinado instante. Para asignar valores num ricos a la
disponibilidad deber e a emplearse la siguiente expresi n: o
Donde TMEF es el tiempo medio entre fallos y TMDR es el tiempo
medio de recuperaci on (o de reparaci n). o N tese que la
disponibilidad nos proporciona mayor informaci n sobre la capacidad
de prestao o ci n de servicios que la abilidad. Podramos tener un
sistema m s able y, en la pr ctica, menos o a a disponible que otro
si la probabilidad de fallo fuera menor pero el tiempo necesario
para recuperar el sistema en caso de fallo fuese muy superior.
Nuestro objetivo ser tener un sistema altamente disponible. Esto
querr decir que deber tener a a a una alta abilidad y que adem s,
en caso de fallo va a requerir un tiempo mnimo para recuperarse. a
Como puede desprenderse de la denici n vista arriba, la
disponibilidad puede expresarse o tambi n como una probabilidad. En
[P98] se da una clasicaci n de diferentes grados de dispoe o
nibilidad en funci n del n mero de nueves que va a tener el valor
num rico de la disponibilidad. o u e Las clases resultantes
aparecen en la tabla 1.1.
$ G $ F 18CC41 7 1 ( & $
DPA!#IH%#"!%E"43EDDB'A4@9582654320)'%#"! f b d d b X 4 RQ ca ec a
ca `#Y5XW5VAU@6)TS5RQ & b
1.3. ALTA DISPONIBILIDAD
7
Disponibilidad 90 a 99 % 99 a 99.9 % 99.9 a 99.99 % 99.99 a
99.999 % 99.999 a 99.9999 % 99.9999 a 99.99999 %
Tiempo no disponible por ano entre 4 das y un mes entre 9 horas
y 4 das entre 1 y 9 horas entre 5 minutos y 1 hora entre medio y 5
minutos entre 3 y 30 segundos
Clase 1 2 3 4 5 6
Tabla 1.1: Clases de disponibilidad.
1.3.4 Concepto de alta disponibilidadVistos ya todos los
conceptos previos que hemos presentado en la secciones anteriores,
estamos en condiciones de denir qu se va a entender por alta
disponibilidad. Para ello vamos a utilizar e las clases de
disponibilidad presentadas en la tabla 1.1 y diremos que un sistema
puede clasicarse como altamente disponible cuando la disponibilidad
media que ofrezca est dentro de las clases 5 e o 6. Es decir, ha de
tener una disponibilidad mayor a un 99.999%.
1.3.5 T cnicas para mejorar la disponibilidad eLa t cnica b sica
para mejorar la disponibilidad de un sistema o aplicaci n es la
replicaci n de e a o o sus componentes, evitando as que exista ning
n punto falible no replicado. Con ello se tendr n u a m ltiples r
plicas de cada componente, ubicadas cada una de ellas en un nodo
distinto del sistema u e distribuido o del cluster. Si se llegase a
producir un fallo y cayese alguno de estos componentes, sus
servicios seran atendidos por alguna de sus r plicas con lo que el
usuario apenas percibira un e leve retraso en la respuesta. Pero
para que esto sea posible se necesitan adem s algunos servicios
complementarios. Uno a de ellos es el encargado de monitorizar
continuamente el estado de los componentes que formen el sistema o
la aplicaci n altamente disponible. Recibe el nombre de monitor de
pertenencia o [MBG97] y su misi n consiste en detectar cu ndo un
componente ha fallado o cu ndo se ha o a a recuperado, noticando al
resto cualquiera de estos eventos, permitiendo que as reconguren
tanto su estado como el conjunto de clientes a atender. El uso de
este tipo de servicios es b sico a para mantener de forma adecuada
el estado de un objeto replicado. As se podr saber qu r plicas a e
e se mantienen operativas en cada momento y se podr recongurar r
pidamente el estado del objeto a a en caso de cada o recuperaci n
de alguna de estas r plicas. o e Otra herramienta util para dar
soporte a las t cnicas de replicaci n son los mecanismos necesa e o
rios para realizar actualizaciones de estado (o checkpoints). Es
decir, en caso de que no todas las r plicas tomen un papel activo
para procesar una determinada petici n que implique la modicae o ci
n del estado, la r plica que haya procesado tal petici n deber
comunicar posteriormente a las o e o a dem s qu cambios deber n
realizar para tener al nal un estado consistente en todas las r
plicas. a e a e Para realizar estas actualizaciones de estado
convendra adem s utilizar alg n tipo de soporte tran a u saccional
para proporcionar sucientes garantas de atomicidad, consistencia y
aislamiento en los cambios a realizar. La soluci n adoptada en
estos casos para realizar estas actualizaciones de o
8
CAPITULO 1. INTRODUCCION
estado depende en gran medida del modelo de replicaci n que se
est empleando. o e Pero la t cnica b sica para mejorar la
disponibilidad de un servicio no ser otra que la replicae a a ci n
de los componentes que proporcionan dicho servicio. En la pr xima
secci n se describir en o o o a detalle qu alternativas de
replicaci n existen, as como las principales ventajas e
inconvenientes e o de cada una de ellas.
1.4 Replicaci n oLa replicaci n de servidores es una de las t
cnicas b sicas para garantizar su alta disponibilidad. o e a Pero
para gestionar un servidor replicado hay que tomar ciertas
decisiones que inuyen en el comportamiento que ofrecer ese servidor
a sus clientes: cu ntas r plicas deben existir, d nde se a a e o
ubicar n, qu r plicas recibir n las peticiones de los clientes, c
mo se garantizar la consistencia a e e a o a del estado de las r
plicas, qu tipo de consistencia se desea (es decir, qu diferencias
entre el e e e estado de las diferentes r plicas podr n ser
admitidas), c mo se canalizar n los resultados de una e a o a
invocaci n hasta el cliente que la ha iniciado, etc. Todo ello dene
un modelo de replicaci on. o
1.4.1 ModelosExiste un conjunto de caractersticas que denen el
modelo de replicaci n que se est empleando. o a Estas
caractersticas y las posibles alternativas que pueden escogerse
para cada una de ellas, son las siguientes:
Los modelos de replicaci n m s importantes: activo, pasivo y
coordinador-cohorte, se descrio a ben en las pr ximas secciones.
o
Grado. Indica el n mero de r plicas que va a mantener el
servicio y condicionar el n mero u e a u de fallos que podr n
admitirse. a R plicas activas/pasivas. Se entiende por r plica
activa aquella que recibe directamente la e e petici n de un
cliente y la sirve, modicando el estado del servidor replicado. Por
cono tra, una r plica pasiva no recibe ni trata las peticiones de
los clientes sino unicamente las e actualizaciones de estado
originadas por las r plicas activas. e El n mero de r plicas
activas y la posibilidad de cambios entre rol activo y pasivo denen
u e al modelo que se est empleando. e Difusi n de peticiones. La
petici n iniciada por el cliente debe ser dada a conocer (difuno o
dida) a todas las r plicas del servidor. Puede ocurrir que la
difusi on se realice de manera e previa y que la petici n llegue
directamente a todas las r plicas servidoras o puede que o e
unicamente llegue a una r plica que tras procesar la petici n
difundir sus resultados tanto e o a al cliente como al resto de r
plicas (r plicas pasivas con difusi on posterior). e e Filtrado de
respuestas. En caso de que la petici n sea procesada directamente
por m s o a de una r plica, cada una de ellas generar una respuesta
independiente. No resulta convee a niente hacer llegar todas las
respuestas al cliente, una tras otra, por lo que debe efectuarse
alg n tipo de ltrado. Las opciones existentes son: elegir la
primera, elegir la que ha sido u proporcionada por m s r plicas (al
estilo de una votaci n), elegir una cualquiera, etc. a e o
1.4. REPLICACION
9
1.4.2 Modelo activoEn el modelo de replicaci n activo [Sch93a],
todas las r plicas del servicio son activas, se utiliza o e difusi
n previa y alg n tipo de ltrado de respuestas (la variante
utilizada no importa en exceso). o u Con ello, este modelo presenta
la ventaja de tener un mnimo tiempo de reconguraci n, ya que en o
caso de cada no es necesario realizar ninguna tarea compleja para
restaurar el estado del servicio ni para cambiar el rol de sus r
plicas (todas ellas siempre son activas). e Por otra parte, s
presenta el inconveniente de que para garantizar la consistencia de
todas las r plicas debe asegurarse que todas ellas reciben todas
las peticiones en cierto orden (que no tiene e por qu ser orden
total estricto, puede en algunos casos ser simplemente causal).
Para ello deben e emplearse protocolos de difusion at mica [HT93,
BvR94], es decir, que garanticen que la difusi n o o llegue a todas
las r plicas o a ninguna y cuyo coste no es precisamente bajo. Adem
s, aqu se e a exige que las r plicas del servicio invocado utilicen
una codicaci n basada en un solo hilo de e o ejecuci n, puesto que
si se da soporte a m ltiples hilos de ejecuci n que puedan dar
servicio a o u o m ltiples peticiones concurrentemente, podran
aparecer inconsistencias debido al planicador a u corto plazo que
utilice el sistema. Una soluci n para que desapareciera esta
restricci n podra ser o o la utilizaci n de un planicador
determinista [JPA00] en cada una de las r plicas. o e La adici n de
una r plica tambi n plantea problemas, pues al ser todas ellas
activas debe o e e asegurarse que esta recibe inicialmente el mismo
estado que todas las dem s y que, a partir de a ese momento, se
integre perfectamente en el grupo y reciba las mismas peticiones
que el resto de r plicas. Para ello, la operaci n de adici n tambi
n debe ser ordenada como una petici n m s y e o o e o a exige que,
mientras esta se lleve a cabo, el resto de r plicas no actualicen
su estado o se recuerde e qu peticiones han servido para
suministrarlas posteriormente a la nueva r plica. e e Otra dicultad
aparece cuando un objeto replicado activamente debe invocar los
servicios de cualquier otro objeto. Como todas las r plicas son
activas, se generara una petici n por cada una e o de ellas y esto
sobrecargara excesivamente al objeto que se desa invocar. Para
ello, debe proce derse a ltrar tambi n las peticiones hacia otros
servicios. Lo mismo ocurrir cuando un objeto e a de este modelo de
replicaci n decida acceder a un dispositivo de almacenamiento
compartido por o todas las r plicas (el problema desaparece si cada
r plica del objeto accede a una r plica distinta e e e del
dispositivo de almacenamiento). La soluci n ser la misma que en el
caso anterior: ltrar. o a Por ultimo, tambi n hay que considerar la
carga introducida por este modelo, ya que cada e r plica debe
procesar cada petici n y requiere tiempo de CPU y uso de otros
recursos para loe o grar dar este servicio. Los otros dos modelos
estudiados tienen un coste bastante inferior, como veremos en las
pr ximas secciones. o Como resultado, aunque es el modelo que
necesita un menor tiempo de reconguraci n, y o esta es una cualidad
muy importante cuando se habla de proporcionar alta disponibilidad,
tambi n e implica el uso de costosos protocolos de difusi n y
requiere otras soluciones menores para algunos o detalles
adicionales.
1.4.3 Modelo pasivoEn el modelo de replicaci n pasivo [BMST93],
unicamente existe una r plica activa, llamada o e r plica primaria
y m ltiples r plicas pasivas, llamadas r eplicas secundarias. Se
utiliza difusi n e u e o posterior y, gracias a ello, no resulta
necesario efectuar un ltrado de respuestas. Su principal
inconveniente radica en el tiempo de reconguraci n, pues hay que
efectuar un cambio de rol de o
10
CAPITULO 1. INTRODUCCION
una de las r plicas cuando falla la r plica primaria y esto
exige adem s un protocolo de elecci on e e a de lder, con el
consiguiente cambio en los clientes, que ahora deber n dirigirse a
la nueva r plica a e primaria que se haya elegido. A diferencia de
lo que sucede en el modelo de replicaci n coordinador-cohorte, en
el modelo o pasivo el rol de una determinada r plica es est tico y
no cambia a menos que se d un fallo. e a e En este modelo, la forma
de tratar una petici n iniciada por un cliente externo es la
siguiente. o En primer lugar, el cliente dirige su petici n a la r
plica primaria, que procesa tal petici n y o e o actualiza su
estado convenientemente. Cuando ya se ha logrado esto, la r plica
primaria procede e a realizar un checkpoint sobre sus r plicas
secundarias (en algunos casos, el checkpoint se realiza e de manera
peri dica, por lo que no est ligado a ninguna petici n), con lo
cual logra que el estado o a o de estas pase a ser consistente con
el suyo. Por ultimo, la r plica primaria devuelve la respuesta al e
cliente. Como ventaja principal del modelo cabe citar la baja carga
que implica, pues las peticiones s lo son atendidas activamente en
una r plica y resulta f cil controlar tanto las peticiones origio e
a nadas por esta r plica sobre servicios externos como los accesos
que realice sobre dispositivos de e almacenamiento o de cualquier
otro tipo, que no ser n intentados por ninguna r plica secundaria.
a e Esto tambi n hace innecesario el uso de un protocolo de difusi
n at mica, como el empleado en el e o o modelo activo para
garantizar cierto orden en la llegada de peticiones a todas las r
plicas activas, e por lo que el coste tambi n se rebaja en ese
apartado. e Sin embargo, no todo son ventajas en este modelo.
Aparecer n algunos problemas, al igual a que en el modelo activo,
cuando un objeto replicado necesite invocar a otro objeto
replicado. En este caso el problema no aparece por la necesidad de
ltrar peticiones o respuestas sino por la posibilidad de que la r
plica primaria del objeto replicado cliente pueda caer tras haber
realizado una e petici n y antes de haber obtenido una respuesta.
La soluci n que deber proporcionarse en este o o a caso depender de
la implementaci n nal que se haya realizado de este modelo de
replicaci n. a o o En principio, para solucionarlo bastara con
realizar checkpoints sobre todas las r plicas secunda e rias cuando
un primario pida un servicio a otro objeto replicado, de manera que
todas las r plicas e secundarias sepan que tal petici n se ha
iniciado. Cuando se reciba la respuesta habr que realizar o a de
nuevo un checkpoint para noticar su llegada. Gracias al checkpoint
utilizado inmediatamente antes de la invocaci n, la r plica que
deba sustituir a un primario que haya fallado sabr que o e a tendr
que esperar la respuesta a una invocaci n iniciada por el antiguo
primario. Por otra parte, el a o objeto replicado que fue invocado
deber tener alguna forma de averiguar cu l es la nueva r plica a a
e primaria que ha sustituido a la que haya fallado y deber retornar
la respuesta a esa nueva r plica a e primaria.
1.4.4 Modelo coordinador-cohorteEn el modelo de replicaci n
coordinador-cohorte [BJRA85] unicamente existe una r plica activa o
e y varias r plicas pasivas, al igual que en el modelo pasivo, pero
esto es unicamente as si s lo e o consideramos una petici n en
particular. El rol activo o pasivo de cada r plica puede variar de
una o e petici n a otra. El resto de caractersticas es similar al
modelo pasivo: no se necesita difusi n de o o peticiones ni ltrado
de respuestas. Cuando una r plica desempe a el papel activo en una
petici n recibe el nombre de r eplica e n o coordinadora para esa
petici n. Si, por contra, desempe a un papel pasivo se la llama r
eplica o n
1.4. REPLICACION
11
cohorte. En este modelo, a diferencia de lo que ocurra en el
pasivo, cada r plica puede comportarse e tanto de manera activa
como pasiva sin necesidad de ser recongurada o promocionada a la
otra categora. Por tanto, aqu se elimina la necesidad de recongurar
las r plicas y elegir una nueva e r plica activa en caso de fallo,
como suceda en el modelo pasivo. Adem s, por el hecho de e a que
cada petici n s lo tenga una r plica activa, se elimina la
necesidad de emplear protocolos de o o e difusi n at mica para
asegurar la consistencia en las invocaciones (no obstante, para
lograr esta o o consistencia habr que tomar otras medidas
adicionales), no se sobrecargan todas las r plicas con a e el
proceso de la petici n y no hay que controlar las peticiones que
dirija la r plica activa sobre o e servicios externos, ni ltrar las
respuestas hacia el cliente. Por ello, se eliminan los costes m s a
importantes que presentaban los dos modelos anteriores. Sin
embargo, la posibilidad de que m ltiples peticiones lleguen
concurrentemente y elijan diu ferentes r plicas coordinadoras
introduce problemas de control de concurrencia, que habr que e a
resolver de manera distribuida y que no estaban presentes en los
otros dos modelos. En estos ultimos la soluci n poda ser local a
cada r plica, sin considerar para nada a las restantes. En o e el
modelo coordinador-cohorte cabe la posibilidad de que estas m
ltiples peticiones concurrentes u traten de modicar la misma parte
del estado del objeto replicado en diferentes r plicas coore
dinadoras. Obviamente, este tipo de accesos debe evitarse, dando
precedencia a una de las dos peticiones e iniciando la otra cuando
la primera termine. Un segundo problema, relacionado con el de
control de concurrencia, es el garantizar la atomicidad de las
actualizaciones. En el caso del modelo pasivo esto no era difcil,
porque se podan realizar los checkpoints de manera sncrona antes de
devolver el resultado al cliente e iniciar una nueva operaci n. Sin
embargo, aqu podemos tener m ltiples peticiones que no tengan
conictos o u entre ellas (que no modiquen ambas la misma parte del
estado del objeto) funcionando concurrentemente y las
actualizaciones que efect en deben terminar en todas las r plicas
antes de que u e se inicie una nueva petici n en cualquier otra r
plica. La soluci n de los checkpoints sncronos o e o tambi n es
aplicable, pero es preferible utilizar alg n tipo de transacci n
adem s del sincronismo, e u o a para evitar la repetici n del
servicio de una petici n en caso de fallos. o o Por lo que respecta
a la interacci n entre dos servicios replicados bajo este modelo
(es decir, o una r plica coordinadora de un objeto A pide la
realizaci n de cierta operaci n a otro objeto e o o replicado B),
hay que decir que la situaci n que se plantea en este entorno
mantiene id nticas o e caractersticas a las presentadas por el
modelo de replicaci n pasivo. As, no hay necesidad de o ltrado de
peticiones o respuestas, pero hay que tener especial cuidado con la
cada de la r plica e coordinadora cliente. La forma de tratar esa
situaci n es id ntica a la planteada anteriormente para o e el
modelo pasivo.
1.4.5 Otros modelosOtro ejemplo de modelo de replicaci n
empleado principalmente en el campo de la gesti n de o o bases de
datos es el uso de consenso por qu orum o votaci n [AA92, Her87a,
Her87b, JM90]. En o esta aproximaci n, utilizada para bases de
datos replicadas, cada operaci n que se intenta debe o o conseguir
un determinado n mero de votos de las r plicas (qu orum) para
proceder. Normalmente, u e las operaciones se dividen en dos
categoras: lecturas y escrituras. Cada r plica tiene otorgado e
cierto n mero de votos. La regla que suelen seguir la mayor parte
de los algoritmos de gesti n u o
12
CAPITULO 1. INTRODUCCION
de esta area es que el qu rum de escritura debe ser superior a
la mitad del n mero total de votos, o u mientras que el qu rum de
lectura puede ser inferior a dicha mitad. Aparte, la suma del qu
rum o o de lectura y el de escritura debe superar el n mero total
de votos. De esta forma se logra tanto u gestionar la replicaci n
como el control de concurrencia asociado a las operaciones de
consulta o o actualizaci n de la base de datos. Algunas mejoras
sobre el modelo original est n basadas en o a una variaci n din
mica de los quora en caso de fallo, o de la distribuci n de votos
(en caso de o a o mantener los quora jos) [Her87b, KS93]. Otro
modelo especial es el de replicaci on perezosa [LLSG92]. En este
caso, cada objeto replicado tiene un objeto de interfaz o
front-end. Para las peticiones de consulta de estado, el objeto de
interfaz consulta una r plica y devuelve el resultado tan pronto
como est disponible. e a Para las peticiones de actualizaci n, el
objeto de interfaz retorna de inmediato el control a su o cliente y
propaga posteriormente la actualizaci n de manera perezosa. En este
caso, se distinguen o tres tipos de operaciones: forzosas, las que
se sirven entre ellas en el mismo orden en todas las r plicas;
inmediatas, las que se sirven respecto a cualquier otra operaci n
en el mismo orden en e o todas las r plicas (orden total);
causales, las que se sirven siguiendo orden causal. La principal e
aportaci n de esta variante de replicaci n es su eciencia de
servicio, pues el objeto de interfaz o o puede contestar las
peticiones de los clientes de manera r pida, especialmente en el
caso de las a escrituras. Para las lecturas hay que comprobar qu
consistencia espera la petici n recibida y e o contestar a ella
cuando la r plica que pueda utilizarse haya recibido todas las
actualizaciones que e se necesiten. Si se examinan los trabajos
realizados en esta area podr n encontrarse m ltiples variantes de a
u los dos modelos de replicaci n principales (activo y pasivo), m s
alg n otro modelo intermedio o a u como el coordinador-cohorte o
las aproximaciones comentadas en esta secci n. La elecci n de o o
un modelo u otro depende de los servicios que deban proporcionarse.
Para el caso del modelo coordinador-cohorte la ausencia de
implementaciones nativas con este modelo puede deberse a la
complejidad de los mecanismos auxiliares que garanticen la
atomicidad, consistencia y aislamiento de las actualizaciones de
estado. Esta tesis describe el soporte necesario para los
mecanismos auxiliares que proporcionan estas garantas.
1.4.6 Arquitecturas de soporte a replicaci n oCentr ndonos en el
soporte a replicaci n, ha habido m ltiples aproximaciones para
implementar a o u objetos replicados o procesos replicados en un
sistema. Las de mayor relevancia son las siguientes: A1 El sistema
operativo distribuido proporciona directamente el soporte
necesario. Esta aproximaci n ha sido seguida en los sistemas V
[Che88] y Amoeba [TvRvS 90], que fueron o desarrollados desde un
principio incluyendo un protocolo de comunicaci on entre grupos
[Che86, KT91] que entregaba las peticiones a las aplicaciones
replicadas. Estos sistemas usaron el modelo de replicaci n activa,
ya comentado anteriormente. o En este caso, el soporte para alta
disponibilidad est incluido en el sistema operativo que se a est
usando. Todas las aplicaciones que pueden utilizar este soporte
dependen del sistema a sobre el que han sido desarrolladas; esto
es, no podr n ser migradas f cilmente a otros a a sistemas
operativos.
g
1.4. REPLICACION
13
A2 Una biblioteca o toolkit facilita el soporte para objetos
replicados, los cuales podr n ejea cutarse sobre cierto conjunto de
sistemas operativos. Existen m ltiples ejemplos de este u modelo:
Relacs [BDM95], Isis [BvR94], Arjuna [PSWL95], Phoenix [MFSW95],
Horus [vRBM96], . . . Normalmente, todos ellos facilitan un soporte
a objetos replicados siguiendo el modelo de replicaci n activo,
como ya ocurra en la aproximaci n A1. o o A3 Protocolos de
transporte que incluyen un servicio de pertenencia y que pueden ser
integrados en los niveles de comunicaci n de un sistema operativo
distribuido. Facilitan un o servicio de difusi n ordenado, que
puede ser utilizado por el programador de aplicaciones o para
desarrollar componentes replicados. Transis [DM96] es un ejemplo de
un protocolo de transporte de este tipo. Tolera particiones de la
red. Es decir, que los nodos que forman el sistema se subdividan en
varios grupos que permanezcan aislados, al menos temporalmente.
Totem [MMSA 95] es otro ejemplo de protocolos de esta clase. La
principal diferencia entre ellos es que mientras Transis estructura
sus nodos de manera jer rquica a la hora de a transmitir los
mensajes, Totem usa un anillo l gico. o A4 Uso de middleware
[Ber96]; i.e., un nivel de programa situado entre la aplicaci n y
el siso tema operativo, que facilita un conjunto de interfaces y
protocolos que pueden ser usados para comunicaci n cliente-servidor
independientemente del sistema operativo que se utilio ce en cada m
quina. Un ejemplo de la aproximaci n middleware es CORBA [OMG99a].
a o Aunque actualmente no facilita ning n soporte para objetos
replicados dentro de su arquiu tectura est ndar, se est
considerando la inclusi n de un futuro servicio CORBA [OMG98a] a a
o de replicaci n [OMG98b, OMG99b]. o El uso del est ndar CORBA
conlleva ciertas ventajas. Primero, no depende del sistema opea
rativo que se utilice. Por tanto, podemos construir nuestras
aplicaciones distribuidas sobre diferentes sistemas operativos.
Segundo, facilita un modelo de programaci n orientado a o objetos,
mejorando la modularidad de las aplicaciones resultantes. Tercero,
soporta componentes implementados en una gran variedad de lenguajes
de programaci n (C, C++, Java, o Ada95, COBOL, Smalltalk, . . . ).
Y, nalmente, CORBA facilita interoperabilidad entre ORBs
desarrollados por diferentes proveedores. Sin embargo, sus
principales inconvenientes son su ubicaci n en la arquitectura del
sistema o distribuido, que normalmente se encuentra fuera del
sistema operativo (y que, por tanto, evita que pueda ser usado para
incluir objetos replicados en el n cleo del sistema), y su falta u
de soporte est ndar para objetos replicados. a Tambi n ha habido
aproximaciones que han tratado de combinar el uso de bibliotecas de
e comunicaci n entre grupos con CORBA [Maf95]. Aunque es un buen
principio, acarrea los o inconvenientes presentes en las
bibliotecas de comunicaci n entre grupos (principalmente, o el
coste de sus protocolos de difusi n at mica ordenada). o o A5
Modicaciones de un sistema operativo ya existente para incluir
soporte a objetos replicados de alg n modelo. En este caso, el
desarrollo efectuado es altamente dependiente del sistema u
operativo que se est modicando. En la soluci n descrita en [BBG
89], las acciones reaa o lizadas por un proceso UNIX deben ser
interceptadas y copiadas en una r plica secundaria e
g
g
14
CAPITULO 1. INTRODUCCION
de este proceso (se emplea el modelo de replicaci n pasivo). o
A6 El soporte para objetos replicados est integrado en un lenguaje
de programaci n distria o buido. Ejemplos de este tipo son Argus
(que est basado en transacciones at micas, pero a o algunas
extensiones fueron realizadas en [Ghe90] para incluir soporte a
objetos replicados) y Drago [MAAG96], una extensi n de Ada95 que
gestiona objetos replicados. o Esta aproximaci n garantiza que las
aplicaciones desarrolladas usando estos lenguajes poo dr n
funcionar en varios sistemas operativos. As, las aplicaciones
pueden ser f cilmente a a migradas a ellos. A7 Utilizar una soluci
n que toma algunas de las caractersticas de las aproximaciones A1 y
A4. o Esto conlleva adaptar un sistema operativo existente,
integrando en su n cleo una capa de u middleware con soporte
integrado para replicaci n de objetos. Esto permitir que se pueda o
a adaptar posteriormente el propio n cleo del sistema incluyendo en
sus componentes tambi n u e objetos replicados que garanticen la
alta disponibilidad del propio sistema distribuido. Esta soluci n
fue adoptada en Solaris MC [BMK96] y es la que se va a adoptar
tambi n en o e HIDRA [GMB97b], objeto principal de esta tesis.
1.5 ContribucionesEsta tesis describe parte de la arquitectura
HIDRA [GMB97a, GMB97b] que proporciona soporte para objetos
replicados extendiendo el n cleo de un sistema operativo con un ORB
con soporte u nativo para este tipo de objetos, lo que permitir que
algunas partes del propio n cleo puedan a u construirse tambi n
como objetos altamente disponibles. e El tipo de sistema donde se
implantar la arquitectura HIDRA ser un cluster de ordenadores. a a
Como en este caso se pretende dar soporte a replicaci n de objetos
e interesa detectar lo antes o posible cualquier variaci n en la
pertenencia de m quinas al sistema, se ha implantado un protoo a
colo de pertenencia a grupo [MBG97, MMBG97, MGB00] que comprueba y
notica cualquier cambio que se produzca. Este protocolo es
necesario para dirigir la reconguraci n del estado de o los objetos
replicados en caso de fallo. Como veremos en el captulo 3
actualmente ya se han dado muchas soluciones al problema del
mantenimiento del conjunto de pertenencia a un grupo. En ellas se
pueden distinguir dos fases principales: formaci n y monitorizaci
n. La fase de formaci n comprende todos los pasos que o o o deben
realizarse desde la detecci n de un cambio hasta el establecimiento
de un nuevo conjunto o de pertenencia, mientras que la de
monitorizaci n se centra en comprobar peri dicamente el buen o o
funcionamiento de los elementos que ya integran el grupo, as como
de atender solicitudes de incorporaci n. o Nuestro monitor de
pertenencia HMM tiene unos costes similares a los de los mejores
monitores desarrollados en esta area, aunque parte con la ventaja
de que su entorno de trabajo es ciertamente favorable (asumiremos
que no se dar n particiones de la red de interconexi n, pues a o
nuestro modelo de cluster tendr una red donde no existir n
pasarelas que intercomuniquen subrea a des). Su contribuci n
principal radica en que la fase de formaci n no tiene un coste
excesivamente o o alto y que tolera m ltiples fallos simult neos de
los componentes que utilizan el protocolo. En u a otros algoritmos
con costes similares, para tener una fase de formaci n econ mica se
utilizan o o
1.5. CONTRIBUCIONES
15
coordinadores que dirigen al resto de nodos en caso de variaci n
en la pertenencia. Nuestro proo tocolo tambi n los utiliza. Sin
embargo, en otros algoritmos existe el peligro de que el
coordinador e falle y entonces sea reemplazado por un suplente. Las
cosas se complican demasiado cuando ese suplente tambi n falla;
entonces se suele recurrir a reiniciar la formaci n del grupo
entero con una e o variante del protocolo de formaci n mucho m s
cara que la normal. Nuestro algoritmo no presenta o a ese problema.
Se ha introducido el concepto de nodo iniciador que evita fases de
formaci n m s o a costosas en caso de m ltiples fallos. u Una
segunda aportaci n de nuestro protocolo de pertenencia es la
inclusi n de una tercera o o fase que se inicia en paralelo con la
de monitorizaci n y que sirve para noticar los cambios o con una
secuencia de pasos sincronizados a una lista de componentes
registrados. Con ello se abaratan los costes de reconguraci n de
nuestros componentes, pues esta sincronizaci n es f cil o o a de
conseguir si est dirigida directamente por quien detecte los
cambios. Esto es as porque resulta a sencillo abortar una
reconguraci n de nuestro sistema si durante ella se ha advertido
alg n otro o u cambio en el conjunto de m quinas que forman el
cluster y que provocar a su vez una nueva a a reconguraci n. o Otra
contribuci n de esta tesis radica en su soporte para el modelo de
replicaci n coordinadoro o cohorte. Hasta ahora no ha habido ning n
sistema donde este modelo de replicaci n se haya u o implantado de
forma nativa. En la pr ctica, otros sistemas proporcionan soporte
para este modelo a (por ejemplo, Isis [BvR94]) pero lo hacen en una
capa situada por encima del modelo de replicaci n activo. Es decir,
para dar soporte al modelo coordinador-cohorte requieren tener
implantado o por debajo el modelo activo. Esto permite solucionar
algunos problemas del modelo activo, pero puede acarrear costes
adicionales para el modelo coordinador-cohorte que no habr manera
de elia minar (protocolos de difusi n at mica, ltrados de envos,
ltrados de respuestas, etc.). Nuestra o o soluci n ha optado por
implantar de manera directa este modelo de replicaci n. Para ello
heo o mos necesitado dos mecanismos b sicos: invocaciones ables a
objetos replicados, y control de a concurrencia distribuido. El
mecanismo de invocaciones ables a objeto que presentamos
proporciona atomicidad, progreso, mantenimiento de resultados y
consistencia. La atomicidad resulta necesaria para garantizar que
una invocaci n ha logrado actualizar el estado de todas las r
plicas del objeto. Este requerio e miento, combinado con un
adecuado control de concurrencia, permitir garantizar la
consistencia a del estado de esas r plicas. En caso de fallo de
alguna r plica o del propio objeto cliente durante e e una invocaci
n, la propiedad de progreso indica que la invocaci n deber
proseguir, actualizano o a do a las r plicas que queden
disponibles. Si ha sido el cliente quien ha cado, y tambi n era un
e e objeto replicado, deber n mantenerse moment neamente los
resultados en las r plicas del objea a e to invocado. Cuando
nalmente otra r plica del cliente repita la invocaci n, no deber
repetirse e o a su servicio sino que ser n localizados los
resultados retenidos y devueltos al cliente. Cuando el a cliente
nalmente los obtenga, el mecanismo de invocaciones ables deber
proceder a eliminar a tales resultados retenidos. Por lo que
respecta al mecanismo de control de concurrencia, este debe llevar
un control sobre las operaciones que se invocan sobre las
diferentes r plicas de un objeto, dejando proseguir a todas e
aquellas que no entren en conicto mutuo. Asumiremos que dos
operaciones est n en conicto a cuando al menos una de ellas intenta
modicar una parte del estado del objeto que es accedida y utilizada
por ambas operaciones. Como existen m ltiples r plicas del objeto y
habr tambi n u e a e
16
CAPITULO 1. INTRODUCCION
m ltiples clientes que podr n iniciar concurrentemente
diferentes invocaciones, se ha implantado u a un mecanismo de
control de concurrencia distribuido que tolera el fallo de
cualquier componente que participe en el mecanismo. Obviamente,
tanto el mecanismos de invocaciones ables como el de control de
concurrencia son dos nuevas contribuciones realizadas en esta
tesis, pues no ha habido hasta la fecha ninguna otra implementaci n
directa del modelo de replicaci n coordinador-cohorte y estos
mecanismos o o est n completamente ligados a dicho modelo de
replicaci n. a o
1.6 EstructuraEl resto de este documento se estructura como
sigue. En el captulo 2 se describe en lneas gene rales la
arquitectura HIDRA, empezando por sus objetivos: dar soporte a alta
disponibilidad en un sistema en cluster, utilizando para ello un
ORB con soporte nativo a objetos replicados que ser a incluido, en
parte, dentro del n cleo de un sistema operativo de uso general,
como por ejemplo u Linux, o sobre un micron cleo, como pueda ser
NanOS [MB97, MGB99a]. Posteriormente se exu plican los diferentes
niveles que componen esta arquitectura, al menos aquellos que
tienen cierta relevancia para el soporte necesario a replicaci n:
transporte no able, monitor de pertenencia, o transporte able y
ORB. Dentro de la secci n 2.5 se describe en lneas generales el
soporte que o se ha necesitado para facilitar el modelo
coordinador-cohorte y qu partes del ORB ha habido que e modicar
para ello. El captulo 3 est dedicado a la descripci n de los
monitores de pertenencia a grupo, que a o forman la base de la
arquitectura HIDRA. En primer lugar se describen sus funciones
principales y la aplicaci n de estas para implantar o reforzar
otros componentes del sistema: transporte able, o cadas forzosas en
caso de aislamiento, gesti n de protocolos de reconguraci on de
componentes, o etc. A continuaci n se hace un estudio de los
protocolos actualmente existentes, dependiendo del o entorno y
modelo de sistema distribuido en el que funcionan. Finalmente, se
presenta el protocolo dise ado e implantado en HIDRA, llamado HMM,
as como las posibles mejoras y extensiones n que podran
introducirse. El captulo 4 se centra en los mecanismos que deben
emplearse para realizar invocaciones so bre objetos replicados,
particularmente para el caso de aqu llos que sigan el modelo
coordinadore cohorte. En la primera secci n se empezar analizando
en detalle qu ocurre dentro de este modelo o a e de replicaci n
cuando se invoca un objeto, qu pasos se siguen y qu alternativas
existen para oro e e denar tales pasos. Una vez descrito el
funcionamiento general se estudiar n las garantas que a debera
ofrecer cualquier mecanismo de invocaci n que pretenda ser able. La
secci n 4.3 descri o o be el mecanismo utilizado en HIDRA para
garantizar la abilidad, atomicidad y progreso de las invocaciones a
objetos replicados: el mecanismo de invocaci n able a objeto, o
protocolo IFO (o o ROI, en ingl s). La pr xima secci n describe
todos los posibles casos de fallo que pueden llegar a e o o darse
en este protocolo y c mo son solucionados estos. Para terminar, se
ofrece una ultima secci n o o donde se compara el trabajo expuesto
con otros protocolos empleados en otros sistemas. El captulo 5
trata sobre los mecanismos de control de concurrencia, as como de
su aplicaci n o al modelo de replicaci n coordinador-cohorte
utilizado en nuestro sistema. Se empieza con una o introducci n
general de los objetivos de estos mecanismos. Despu s se describen
los mecanismos o e de control de concurrencia m s com nmente
utilizados en entornos distribuidos: cerrojos, votaa u
1.6. ESTRUCTURA
17
ciones, serializaci n, objetos protegidos, etc. Para comparar la
calidad de diferentes mecanismos o de control de concurrencia se
presenta tambi n el concepto de potencia expresiva. Dados estos e
conocimientos previos, se pasa seguidamente a describir el
mecanismo utilizado en HIDRA, que recibe el nombre de HCC. Se
presentan sus componentes b sicos, objetos auxiliares necesarios, a
relaci n con el protocolo IFO, comportamiento en caso de fallos y
una comparativa con otros o mecanismos existentes. Finalmente, en
el captulo 6 se presentan las conclusiones sobre el trabajo
desarrollado en esta tesis. En primer lugar se da un breve repaso a
todas las tareas completadas y las contribuciones que estas
conllevan. Para terminar se dan a conocer las futuras lneas de
trabajo que van a derivarse de esta tesis.
18
CAPITULO 1. INTRODUCCION
Captulo 2
La arquitectura HIDRA2.1 Introducci n oHIDRA [GMB97a, GMB97b] es
una arquitectura que tiene como objetivo ofrecer soporte para
objetos altamente disponibles (objetos replicados). Esto implica
que el tipo de soporte que ofrecer la arquitectura presupondr un
modelo de programaci n orientado a objetos y que existir n a a o a
m ltiples m quinas donde podr n ubicarse las m ltiples r plicas de
estos. Para dar el soporte a u a a u e un modelo de programaci n
orientado a objetos en un entorno distribuido, como es el caso
(pues o las diferentes m quinas donde residan las r plicas de cada
objeto, deber n estar interconectadas), a e a una de las bases m s
asentadas la proporciona el est ndar CORBA. Este est ndar no
depende del a a a lenguaje de programaci n que se emplee para
implantar los objetos a intercomunicar, soportando o actualmente
una gran variedad de ellos. Con ello queda claro que en nuestro
soporte va a gurar un ORB para facilitar las herramientas de
intercomunicaci n. Para dar un soporte mejor a los obo jetos
replicados, convendra que estos fueran reconocidos nativamente por
el n cleo de este ORB u y no que fueran gestionados como grupos de
objetos nativos que pueden seguir siendo invocados individualmente,
tal como ha ocurrido en la versi n adoptada de la especicaci n para
tolerancia o o a fallos dentro de CORBA, iniciada en 1998 [OMG98b,
OMG99b] y que ha tenido su texto nal durante el a o 2000 [OMG00]
aunque sobre dicha edici n todava se pueden realizar ampliaciones n
o o revisiones. Con esto no se est haciendo una crtica a lo que
marca el est ndar CORBA, simplea a mente justicamos nuestra elecci
n. En nuestro caso, la interoperbilidad con otros OO.RR.BB. no o
era importante, pero s lo es el rendimiento del ORB, aunque se
aparte de lo que dicte el est ndar. a Adem s, la especicaci n ocial
contempla algunos modelos de replicaci n, pero no todos. Por a o o
ejemplo, el modelo coordinador-cohorte defendido en esta tesis no
se soporta. Para que todo funcione correctamente se necesitar n
adem s otros componentes y servicios. a a Un ejemplo de ellos es el
monitor de pertenencia que comprueba continuamente el
funcionamiento de las m quinas del cluster e informa a los
componentes precongurados sobre cualquier cambio a que haya habido
en el conjunto de nodos que integran ese cluster. Esta herramienta
servir para a decidir en qu momento debe recongurarse el estado de
un objeto replicado, bien porque alguna e de sus r plicas ha
fallado o bien porque existen nuevos nodos donde podr n ser
ubicadas sus e a nuevas r plicas en caso de ser necesario. Aparte,
nuestro ORB ofrece para ciertos tipos de sus e objetos una gesti n
de cuenta de referencias que permite saber cu ntos clientes pueden
acceder a o a el y, en caso de no existir ninguno, notica al propio
objeto acerca de esa situaci n (generando una o
19
20
CAPITULO 2. LA ARQUITECTURA HIDRA
noticaci n de no referencia) para que adopte las medidas
oportunas. Normalmente, esto ultimo o conllevar la destrucci n
voluntaria del objeto replicado. a o En este captulo se van a
describir todos estos componentes de la arquitectura HIDRA, as co
mo la interrelaci n existente entre ellos. La secci n 2.2 describe
cada uno de los componentes que o o forman la arquitectura, o al
menos aquellos que guardan relaci n directa con el soporte
necesario o para objetos replicados. En la secci n 2.3 se presenta
el modelo de fallos que va a utilizarse en o los diferentes niveles
de la arquitectura HIDRA y c mo se ha dado soporte a tales modelos.
Poso teriormente, la secci n 2.4 describe qu es un ORB seg n el est
ndar CORBA y qu diferencias o e u a e presenta nuestro componente
de intercomunicaci n con lo establecido en CORBA. Por una parte, o
encontraremos algunos detalles del est ndar que no est n
implantados en nuestro ORB como puea a da ser el protocolo IIOP, el
uso de un adaptador de objetos, el soporte a invocaciones din micas
o a el uso de interceptores para modicar la informaci n enviada
entre los n cleos. Por otra, nuestro o u ORB a ade soporte especial
que no est contemplado en el est ndar, como los objetos replicados
n a a nativos o la b squeda de basura mediante cuenta de
referencias. La ultima secci n se centra en el u o propio soporte
como tal, estudiando qu partes del ORB han debido ser modicadas
para incluir e la gesti n de los objetos replicados. o
2.2 Visi n general oLos componentes principales de la
arquitectura HIDRA aparecen en la gura 2.1 y se describen en los
apartados que siguen. Tal como se muestra en la gura, estos
componentes deben ubicarse parcialmente en el n cleo del sistema
operativo que se utilice como base, ya que uno de nuestros u
objetivos es que el soporte a objetos replicados pueda ser tambi n
usado para construir algunos e servicios internos del sistema
operativo. En cualquier caso, ese objetivo depende de los que
forman el contenido principal de esta tesis y su consecuci n se
deja como trabajo futuro. o
HMM (monitor de pertenencia)
ORB con soporte para replicacin
Transporte fiable Transporte no fiable
Microncleo NanOS o ncleo de UNIX
A A
B : A notifica un cambio a B B : A pide un servicio a B
Figura 2.1: Componentes de la arquitectura HIDRA.
2.2. VISION GENERAL
21
2.2.1 Transporte no ableEn el nivel m s bajo del soporte que
necesita nuestra arquitectura de alta disponibilidad encona tramos
un transporte no able. Por tal elemento entendemos aqu l que no
establece ning n tipo e u de conexi n ni efect a ning n esfuerzo
para conseguir que la informaci n sea entregada en su o u u o
destino. El tipo de protocolo que habr que emplear para implementar
este transporte depende del tipo a de interconexi n interna que
utilice el cluster. o En un cluster cerrado, la red de interconexi
n interna no puede ser accedida por ning n nodo o u ajeno al
cluster. Suele ser alg n tipo especial de red de altas prestaciones
como las SCI (Scalable u Coherent Interconnect), las Myrinet o las
Gigabit Ethernet. En este caso, los nodos del cluster deben estar
conectados tanto a la red interna como a una red externa que
permita conectarles con nodos externos que puedan requerir sus
servicios. Por el contrario, en lo que puede denirse como un
cluster expuesto, la red de interconexi n o interna est compartida
con el resto de m quinas que haya en ese entorno. Es decir, tanto
los nodos a a externos al cluster como los que pertenecen a el
comparten una misma red. Pues bien, si se est utilizando un cluster
cerrado podr implementarse un protocolo especial a a para este
nivel no able, o adaptar el que facilite el sistema operativo para
trabajar con la red interna. Ese esfuerzo es justicable en este
caso puesto que con esta red interna especial se pretende reducir
el tiempo de comunicaci n entre los diferentes nodos y tendr
sentido utilizar protocolos o a especiales para mejorar las
prestaciones. Sin embargo, si se utiliza un cluster expuesto puede
utilizarse tranquilamente el protocolo est ndar no able de ARPANET
(UDP/IP, o User Datagram a Protocol/Internet Protocol [Pos80]),
puesto que en ese caso las prestaciones que alcancemos depender n m
s del tipo de red y de su carga que del protocolo empleado. a a En
nuestra arquitectura asumiremos que el tipo de cluster a emplear
ser cerrado, por lo que a tendr sentido emplear un protocolo
especial para lograr este transporte no able. a
2.2.2 Monitor de pertenenciaEl monitor de pertenencia es el
componente de HIDRA que comprueba qu m quinas est n fune a a
cionando dentro del cluster. Esta informaci n es importante puesto
que en nuestro ORB se registra o la ubicaci n de cada una de las r
plicas de los diferentes objetos. En caso de cada de alguna o e m
quina hay que modicar en ciertos casos las referencias a objeto
para que se adapten a la nueva a situaci n, hay que recongurar las
invocaciones en marcha y hay que recalcular el n mero de reo u
ferencias clientes que apuntan a estos objetos (Todos estos puntos
se aclarar n posteriormente en a las secciones 2.4.3 y 2.5.2 y en
el captulo 4). El monitor se basa en un chero de conguraci n en el
que est n registradas todas las m quinas o a a que podr n
pertenecer al cluster y debe poder gestionar tanto la puesta en
marcha de alguno de a estos nodos como la cada de cualquiera de
ellos. Una caracterstica a adida a nuestro monitor y n que no
siempre est presente en los componentes de este tipo es la
incorporaci n de un protocolo a o para guiar los pasos de
reconguraci on de cada nodo. Este protocolo admite un n mero
variable u de pasos y garantiza que todos los nodos del cluster
realicen a la vez cada uno de los pasos. Para ello, se espera a que
todos los nodos activos vayan conrmando la terminaci n del paso o
actual antes de iniciar el paso siguiente. Existe un nodo especial
m s prioritario que controla la a recepci n de estas conrmaciones.
Cuando nalmente todos los nodos conrman la nalizaci n, o o
22
CAPITULO 2. LA ARQUITECTURA HIDRA
este coordinador enva un mensaje para que de nuevo todos a la
vez empiecen el paso siguiente. Mientras la reconguraci n se est
llevando a cabo, los monitores tambi n ejecutan el protocolo o a e
normal de monitorizaci n de estado, por lo que si se da una nueva
cada o se a ade una nueva o n m quina al cluster, la nueva situaci
n se detecta de inmediato. a o Puede que existan m ltiples formas
de detectar la cada o adici n de nodos a un cluster, pero u o el
uso de un protocolo distribuido es necesario por varias razones.
Una alternativa habra sido simplemente conar en los protocolos de
transporte, esperando a que estos sean incapaces de entregar cierto
mensaje a un determinado nodo destino para declararlo inh bil. Esto
plantea el a problema de que inicialmente s lo el nodo que pretenda
comunicarse con el que ha fallado ha o detectado ese fallo. Esto
conllevara que el nodo detector podra recongurar su estado ante tal
situaci n, pero los dem s nodos no haran lo mismo hasta que
intentasen comunicarse con el. o a El uso del protocolo de
pertenencia permite que todos los nodos tomen las mismas decisiones
consensuadamente y que reaccionen ante ellas de la misma manera. De
esta forma se establece una buena base para asegurar la
consistencia del estado del cluster y todas las aplicaciones y
objetos que se est n ejecutando en el. e Si nuestro monitor de
pertenencia asegura el consenso en la toma de decisiones sobre el
conjunto de m quinas que componen el cluster, aparece otra situaci
n bastante conveniente. Si el a o grupo ha decidido que una m quina
ha fallado (y esta realmente no lo ha hecho, pero su capacidad a de
trabajo actual no le permite responder de ninguna forma las nuevas
peticiones), el protocolo de transporte able asume que la m quina
ya no est disponible y ni siquiera se le intentar enviar a a a nada
mientras no d ninguna se al de actividad. Es decir, que al tomar
una decisi n de exclusi n, e n o o todos los nodos activos la
acatan y el nodo en cuesti n ha quedado realmente fuera del
cluster. o Si realmente no haba fallado deber intentar
posteriormente reintegrarse en el cluster. Aqu la a ventaja reside
en que todos los nodos adoptan la misma decisi n y se garantiza que
todas las aplio caciones tendr n que adaptarse a la nueva situaci
n. Si no existiera un protocolo de pertenencia, a o puede que
algunas aplicaciones siguieran contando con el nodo mientras que
otras no y se podra llegar a generar un error si estas aplicaciones
interactuasen. Una descripci n detallada del protocolo de
pertenencia puede encontrarse en la secci n 3.4. o o
2.2.3 Transporte ableEl unico requerimiento que tendr el
protocolo de transporte able es que aquellos mensajes que a hayan
sido enviados sean siempre entregados a su destino, excepto cuando
este ultimo o el emisor hayan cado. La ubicaci n de este componente
en la arquitectura se emplaza junto al protocolo de transporte o no
able (puede que utilice parte de sus servicios, al menos en la
implementaci n para un cluster o cerrado, por ello en la gura 2.1
de la p gina 20 aparece sobre el). Si no se utiliza un protocolo a
est ndar, se podr n usar los servicios proporcionados por el
monitor de pertenencia, aprovechando a a sus informes para abortar
la comunicaci n con las m quinas que se notique que han fallado. o
a Los servicios del protocolo de transporte able son utilizados por
el ORB, el mecanismo de intercomunicaci n que tambi n facilitar
soporte para objetos replicados y que se describe seguio e a
damente.
2.3. MODELO DE FALLOS
23
2.2.4 ORBPor ultimo, el componente principal de la arquitectura
va a ser un ORB con soporte para alta disponibilidad. En el se
incluye toda la gesti n de objetos replicados. La funci n est ndar
de o o a un ORB, seg n la arquitectura CORBA, es la gesti n de las
invocaciones entre los diferentes u o objetos que se hallen en un
sistema distribuido. Para ello se necesita un ORB en cada dominio a
intercomunicar. Estos dominios pueden ser procesos o nodos enteros.
La implementaci n del o ORB puede realizarse de diferentes maneras,
el est ndar no obliga a utilizar ninguna de ellas en a particular:
procesos dedicados, bibliotecas, componentes de un sistema
operativo, etc. Para que la invocaci n de objetos pueda tener lugar
se necesita, al igual que en el caso de o una llamada remota a
procedimiento, un stub cliente que ofrezca la misma interfaz que el
objeto remoto que va a invocarse y que mantenga alg n tipo de
referencia a objeto que permita al n cleo u u del ORB localizar al
objeto destino y encauzar la invocaci n hacia el. Por tanto, se
precisa tambi n o e alg n mecanismo para que los dominios clientes
puedan obtener referencias a los objetos ubicados u en otros
dominios. Normalmente esto se consigue gracias a un servicio de
nominaci on [OMG98a, Captulo 3] donde puede asociarse un nombre a
un objeto al registrar una referencia a este y se puede obtener
despu s una referencia si se conoce tal nombre. e Una vez el ORB ha
identicado al objeto destino y ha averiguado en qu nodo se
encuentra, se e envan algunos mensajes a tal nodo, donde su
respectivo ORB recoger la petici n y la har llegar a o a a su stub
servidor que en esta arquitectura recibe el nombre de esqueleto.
CORBA presenta la caracterstica de que tanto el stub cliente como
el esqueleto servidor pue den ser generados autom ticamente
utilizando un compilador de interfaces. Para ello, el programaa dor
ha debido declarar tales interfaces de objeto utilizando IDL (o
Interface Denition Language) [OMG99a, Captulo 3]. Nuestro ORB va a
seguir todos los principios comentados en los p rrafos anteriores,
pero a adem s incluir servicios de computo de referencias. Esto
permitir que un objeto sepa cuando ya a a a no va a ser invocado y
pueda autoeliminarse en ese caso. En la secci n 2.4 se describe con
mayor detalle qu es un ORB. o e
2.3 Modelo de fallosDescribamos qu tipos de fallos se han
llegado a distinguir en el estudio de sistemas distribuidos, e para
ver qu modelos son los m s convenientes para cada uno de los
niveles de la arquitectura e a HIDRA. En [Sch93b], se citan como
posibles modelos de fallos los siete siguientes: 1. Fallo parada
[SS83]. Un procesador falla parando. Una vez ha parado, el
procesador permanecer as. El hecho de que un procesador haya
fallado ser detectable para el resto de a a procesadores. 2. Cada.
Un procesador falla parando. Una vez ha parado, el procesador
permanecer as. a El hecho de que un procesador haya fallado puede
que no sea detectable para el resto de procesadores. 3. Cada y
enlace. Un procesador falla parando. Una vez ha parado, el
procesador permanecer a as. Un enlace falla perdiendo mensajes,
pero no retarda, duplica ni corrompe mensajes.
24
CAPITULO 2. LA ARQUITECTURA HIDRA
4. Omisi n de recepciones. Un procesador falla recibiendo s lo
un subconjunto de los mensao o jes dirigidos hacia el o parando y
permaneciendo parado. 5. Omisi n de envos. Un procesador falla
transmitiendo s lo un subconjunto de los mensajes o o que intentaba
enviar o parando y permaneciendo parado. 6. Omisi n general. Un
procesador falla recibiendo s lo un subconjunto de los mensajes
dirio o gidos hacia el o transmitiendo s lo un subconjunto de los
mensajes que intentaba enviar o o parando y permaneciendo parado.
7. Fallo bizantino. Un procesador falla exhibiendo un
comportamiento arbitrario. La numeraci n seguida en la lista
anterior tambi n sirve para graduar la severidad de cada o e modelo
de fallos (Excepto para los modelos 4 y 5, que pueden considerarse
con el mismo grado de severidad). Cuant
