TCNICASDEDESARROLLODEAPLICACIONESDISTRIBUIDASTOLERANTESAFALLOSSOBREARQUITECTURASCORBAYJAVARMI
MemoriaquepresentaparaoptaralgradodeDoctorenInformticaLuisMiguelPeaCabaas
DirigidaporeldoctorJuanPavnMestras
DepartamentodeSistemasInformticosyProgramacinFacultaddeInformticaUniversidadComplutensedeMadridMayo,2002
iii
Silopuedessoar,lopuedeshacer.-WaltDisney
Oneringtorulethemall,Oneringtofindthem,OneringtobringthemallandintheDarknessbindthem-J.R.R.Tolkien(ejemplodediseocentralizado,notoleranteafallos)
Atodoslosqueosheconocidoduranteestoslargosaosdedoctorado.Lolargohahecho,almenos,queseismuchos.Graciasporvuestracompaayapoyo.AtodoslossitiosdondehevividoydisfrutadomientrasSenseiibaevolucionando.Enespecial,porlosrecuerdosquemetraenenrelacinconestaTesis,Brujas,Amberes,Dublin,yuntrayectoFrankfurt-Stuttgarttantasvecesrecorrido.
iv vResumen
Las tcnicas de tolerancia a fallos en arquitecturas distribuidas
cliente/servidor(como CORBA, Java RMI o Microsoft DCOM), que a
nivel software se
implementanprincipalmentemediantelareplicacindeservidoresparaocultarfallosindividuales,presentanunainterfazdemuybajonivelquehacendifcillaimplementacindelosservicios
tolerantes a fallos. El
rendimientodeestossistemas,quedebenactualizaren cada operacin dos o
ms servidores en lugar de slo uno, y cuya actualizacindebe
realizarse con una sincronizacin muy cuidada para evitar
inconsistencias, essensiblemente inferior al de los sistemas no
tolerantes a fallos. Por esta razn,
lasprincipaleslneasdeinvestigacinenestareahanbuscadolasformasdeoptimizaresascomunicacionesparaobtenersistemasconunrendimientoprctico.Sinembargo,otraslneasdeinvestigacinsehancentradoenelestudiodepatronesdeimplementacinquefacilitenelempleodelastcnicassubyacentesdetoleranciaa
fallos. El sistema propuesto en esta tesis, Sensei, se encuentra en
este campo,estudiando cmo aplicar estas tcnicas a grupos de objetos
y cmo definir unainterfaz de alto nivel que permita un cmodo empleo
de los modelos
decomunicacionesfiablesentreservidoresreplicados.Porunaparte,Senseitrataelproblemadelatransferenciadeestadoentrerplicas,unaspectodelareplicacincubiertoenlateorabsicadesincronavirtualperoconmuy
poca cobertura en las implementaciones actuales. Definimos un
modelo quecubre desde los protocolos de bajo nivel especificando
los mensajes y losrendimientos en diversos sistemas, hasta los
protocolos de alto nivel
especificandosuinterfazenlenguajeIDLdeCORBA.Msimportante,estudiamoslascondicionesque
deben cumplir las aplicaciones para poder emplear los distintos
modelos
detransferenciadeestadoycmoafectanalmodelodesincronavirtualsobreelqueseconstruyenlasaplicacionesreplicadas.Estos
protocolos se implementan parcialmente sobre uno de los sistemas
decomunicaciones fiables ms conocidos, Ensemble. No obstante, hemos
desarrolladotambin un sistema de comunicaciones fiables propio,
SenseiGMS, persiguiendodefinir una interfaz general, comn a los
modelos actualmente existentes, sobre
laqueimplementamostotalmentelosprotocolosdesarrollados.Una vez
resuelta la transferencia de estado, Sensei se centra en los
patrones decomunicacin de alto nivel, que permiten a aplicaciones
orientadas a objetosmantenerse en el mismo nivel de abstraccin al
replicar esos objetos. El sistematradicional de comunicaciones en
los sistemas de comunicaciones fiables entrerplicas es el
intercambio de mensajes entre esas rplicas, mientras que en
Senseihemos desarrollado una aplicacin, SenseiDomains, que permite
factorizar esascomunicaciones a nivel de componentes que pueden
definirse dinmicamente
endominios,buscndosedeestamaneralaabstraccindeobjetos. viAdems, se
observan los patrones ms empleados al disear las aplicaciones
contolerancia a fallos, implementndolos o soportndolos en la medida
de lo posible.Una aplicacin directa de este soporte de los patrones
de implementacin es laposibilidad de replicar automticamente
aplicaciones diseadas inicialmente comoentidades autnomas sin
replicacin. Sensei define la forma de migrar esasaplicaciones para
soportar tolerancia a fallos y formas posteriores de optimizar
lascomunicaciones entre las rplicas
resultantes.ParasoportarlosehadesarrolladolaherramientaSenseiUMA.Como
ejemplo de aplicacin de la metodologa propuesta, se muestra el
diseo deotra de las piezas de la arquitectura, SenseiGMNS, servicio
de gestin de
gruposcuyoscomponentesestnreplicados,asuvez,sobreSensei.
PalabrasclaveSistemas distribuidos, CORBA, JavaRMI, Tolerancia a
Fallos, Replicacin
deObjetos,TransferenciadeEstado,Comunicacionesengrupo.
viiSummary
Fault Tolerance software techniques for distributed
client/server architectures (likeCORBA, JavaRMI or Microsoft DCOM)
are usually based on the replication of
theserverstohidesinglefailures.However,thesetechniquesworkatalowlevel,makingdifficulttheimplementationoffaulttolerantservices.Thesesystemsmustupdateoneachrequesttwoormoreserversinsteadofjustone,andthemultipleupdatesmustbe
carefully synchronized to avoid inconsistencies. As a result, the
performance
onthosesystemsisconsiderablyworsethantheequivalentnonfaulttolerantcase.Thisis
the reason why the main research efforts on this area have been
focused on theoptimization of the communications between replicas
to obtain systems with apracticalperformance.Nevertheless, other
line of work has taken a different approach, focusing on
theimplementation patterns that facilitate the use of
thefaulttoleranttechniques.Thesystem proposed in this Thesis,
Sensei, belongs to this second area, studying
theapplicationofthosetechniquestogroupsofobjectsandthedefinitionofahighlevelinterfacetofacilitatetheuseofthereliablecommunicationmodels.Ononeside,Senseiaddressestheproblemofthestatetransferbetweenreplicas,anaspect
of the replication that, despite beingcoveredbythevirtualsynchrony
model,has usually a poor coverage on current implementations of
thismodel.Wedefineamodel to solve this issue, which addresses low
level protocols, specifying themessages and the performance on a
variety of systems, and high level protocols,defining their
interface on CORBA IDL. What is more important, we study
theconditionsthattheapplicationsmustholdinordertousethedifferentstatetransfermodels,andhowdotheyaffecttothevirtualsynchronymodel.These
protocols are partially implemented on top of one well-known
groupcommunicationsystem,Ensemble.Nevertheless,wehavedevelopedaswellourownreliablegroupcommunicationsystem,SenseiGMS,withagenericinterface,commontotheexistingones,andtheprotocolsarecompletelyimplementedoverit.Once
the state transfer issue is solved, Sensei focuses on the
communicationpatterns that
happenathighlevel,whichallowobject-orientedapplicationstokeeponthesameabstractionlevelwhenthoseobjectsarereplicated.Thebasictraditionalcommunication
entity on reliable group systems is the message, and replicas
mustcommunicateamongthemselvesusingthislowlevelmechanism.InSensei,wehavedevelopedanapplication,SenseiDomains,thatfactorizesthosecommunicationsintocomponent
interactions, components that can be dynamically defined, offering
astandardobjectorientationabstraction.Additionally, we have studied
the design process of fault tolerant
applications,catchingthemostusualimplementationpatterns,inordertoimplementorsupportthem.
A direct benefit of this support is the possibility to
automatically replicateapplications that have been initially
designed as standalone. Sensei defines how to viiimigrate those
applications to have fault tolerance, and how to optimize
afterwardsthecommunicationsbetweenthecreatedreplicas.SenseiUMAisthetooldesignedtosupportthismigration.As
an example of the proposed methodology, we show the design
andimplementation of one of the architectural elements in Sensei,
called SenseiGMNS.This is a group membership service that is itself
replicated following the
designprinciplesandwiththesupportofSenseiDomains.
KeywordsDistributed systems, CORBA, JavaRMI, Fault Tolerance,
Object Replication, StateTransfer,GroupCommunications. ixNDICE
CAPTULO1-INTRODUCCIN..........................................................................................
1CAPTULO2-SISTEMASDISTRIBUIDOS
........................................................................
72.1.MODELOSDISTRIBUIDOS...................................................................................................
82.2.SOCKETS
..........................................................................................................................
92.3.RPCLLAMADASAPROCEDIMIENTOSREMOTOS
...........................................................
102.4.OBJETOSDISTRIBUIDOS...................................................................................................
112.5.TENDENCIASACTUALES..................................................................................................
142.6.CONCLUSIONES
..............................................................................................................
15CAPTULO3-SISTEMASDISTRIBUIDOSFIABLES.....................................................
173.1.FIABILIDAD
....................................................................................................................
173.1.1.Toleranciaafallos
..................................................................................................
183.1.2.Sistemasdistribuidos...............................................................................................
193.1.3.Deteccindefallos..................................................................................................
203.1.4.Gruposdecomponentes
..........................................................................................
213.1.5.Comunicacionesfiables...........................................................................................
223.2.SERVICIODEMIEMBROSDEGRUPO(GMS)......................................................................
253.3.SINCRONAVIRTUAL.......................................................................................................
273.4.OBSERVABILIDADDELGRUPO.........................................................................................
283.4.1.Comunicacionesexternasdelgrupo........................................................................
283.4.2.Replicacin
.............................................................................................................
30CAPTULO4-SISTEMASDECOMUNICACIONESENGRUPO..................................
334.1.SISTEMASDECOMUNICACIONESENGRUPO
.....................................................................
334.1.1.Amoeba
...................................................................................................................
344.1.2.Arjuna
.....................................................................................................................
344.1.3.Bast
.........................................................................................................................
354.1.4.UniversidaddeCornell:Isis/Horus/Ensemble/Spinglass...................................
364.1.5.Cactus
.....................................................................................................................
374.1.6.Electra
....................................................................................................................
374.1.7.Ibus/MessageBus...................................................................................................
384.1.8.JavaGroups.............................................................................................................
394.1.9.JGroup....................................................................................................................
404.1.10.Nile
.......................................................................................................................
414.1.11.Phoenix
.................................................................................................................
414.1.12.RMP......................................................................................................................
424.1.13.Spread...................................................................................................................
424.1.14.Totem....................................................................................................................
434.1.15.Transis
..................................................................................................................
444.1.16.xAmp
.....................................................................................................................
44 x4.2.TRANSFERENCIADEESTADOENMAESTRO
.......................................................................
454.2.1.Versin0.51.............................................................................................................
454.2.2.Versin0.61.............................................................................................................
504.3.CORBA..........................................................................................................................
504.4.CONCLUSIONES
...............................................................................................................
54CAPTULO5-CONDICIONESENLATRANSFERENCIADEESTADO......................
575.1.MODELOYDEFINICIONES
................................................................................................
605.2.REQUISITOSPARALATRANSFERENCIA
............................................................................
635.2.1.Cambiosdevistas
....................................................................................................
665.2.2.Transferenciasdeestadosenvariospasos...............................................................
695.2.3.Cambiosdevistasentransferenciasenvariospasos
...............................................
715.3.ALGORITMODETRANSFERENCIADEESTADO
...................................................................
715.4.CONCLUSIONES
...............................................................................................................
72CAPTULO6-PROTOCOLOSDETRANSFERENCIADEBAJONIVEL.....................
756.1.REQUISITOSDELOSPROTOCOLOS....................................................................................
756.2.TRANSFERENCIAPUSH.....................................................................................................
776.3.TRANSFERENCIAPULL
.....................................................................................................
796.4.TRANSFERENCIAPUSH-ONESTEP
.....................................................................................
806.5.COMPARATIVASDEPROTOCOLOS
....................................................................................
806.5.1.Protocolospushypush-onestep..............................................................................
806.5.2.Protocolospushypull
.............................................................................................
826.6.GMSCONSOPORTEDETRANSFERENCIADEESTADO........................................................
836.7.GRUPOSPARTICIONABLES
...............................................................................................
856.8.CONCLUSIONES
...............................................................................................................
86CAPTULO7-INTERFAZDEAPLICACINDETRANSFERENCIADEESTADO....
877.1.TOLERANCIAAFALLOSENCORBA
................................................................................
887.2.DISEODELAINTERFAZ..................................................................................................
907.2.1.Transferenciasenvariospasos
................................................................................
907.2.2.Cambiosdevistas
....................................................................................................
917.2.3.Propiedadesdemiembros........................................................................................
937.2.4.Eleccindelcoordinador.........................................................................................
947.2.5.Concurrenciaenlatransferencia.............................................................................
957.3.INTERFAZDETRANSFERENCIA.........................................................................................
967.3.1.sync_transfer
...........................................................................................................
987.3.2.start_transfer
...........................................................................................................
987.3.3.get_state
..................................................................................................................
997.3.4.set_state...................................................................................................................
997.3.5.interrupt_transfer
....................................................................................................
997.3.6.continue_transfer...................................................................................................
1007.3.7.stop_transfer..........................................................................................................
1007.4.PROPIEDADESDEMIEMBROS
.........................................................................................
101 xi7.5.EJEMPLOSDEUSO(USECASES)
......................................................................................
1037.5.1.InterfazCheckpointable
........................................................................................
1037.5.2.InterfazBasicStateHandler
...................................................................................
1037.5.3.InterfazStateHandler
............................................................................................
1087.6.IMPLEMENTACINSOBREPROTOCOLOSDEBAJONIVEL
.................................................
1117.7.CONCLUSIONES
............................................................................................................
112CAPTULO8-SENSEIGMS
..............................................................................................
1158.1.DISEO.........................................................................................................................
1168.1.1.Interfazpblica
.....................................................................................................
1178.1.2.Interfazprivada.....................................................................................................
1218.2.ALGORITMODEPASODETESTIGO
.................................................................................
1238.2.1.Pasodetestigoyestructuraenanillo....................................................................
1248.2.2.Deteccindeerrores
.............................................................................................
1248.2.3.Envodemensajes
.................................................................................................
1258.2.4.Manejodevistas....................................................................................................
1268.2.5.Gestindegrupos
.................................................................................................
1288.2.6.Protocoloderecuperacindeltestigo...................................................................
1298.3.USODESENSEIGMS.....................................................................................................
1308.3.1.Diseodeunservicioreplicado
............................................................................
1308.3.2.Implementacin.....................................................................................................
1328.3.3.Configuracin
.......................................................................................................
1368.4.VIRTUALNET................................................................................................................
1378.5.CONCLUSIONES
............................................................................................................
139CAPTULO9-METODOLOGADEDESARROLLO....................................................
1419.1.SINCRONIZACINDELARESPUESTA..............................................................................
1439.2.TRANSFORMACINDEOPERACIONESENMENSAJES
.......................................................
1469.3.COMPORTAMIENTONODETERMINISTA..........................................................................
1499.4.REPLICACINDECOMPONENTES
...................................................................................
1509.5.LIBRERASDECOMPONENTESREPLICADOS....................................................................
1529.6.SOPORTEDECONCURRENCIA
........................................................................................
1529.7.TRANSFERENCIADEESTADO.........................................................................................
1559.8.GESTINDECOMPONENTESREPLICADOS
......................................................................
1569.9.TRANSACCIONES
..........................................................................................................
1619.9.1.Transaccionesyelmodelodesincronavirtual.....................................................
1689.10.COMPARACINCONELMODELODECORBA
..............................................................
1709.11.CONCLUSIONES...........................................................................................................
173CAPTULO10-SENSEIDOMAINS
..................................................................................
17510.1.EXCEPCIONES
.............................................................................................................
17610.2.TRANSFERENCIADEESTADO.......................................................................................
17710.3.PROPIEDADES
.............................................................................................................
18210.4.COMPONENTES
...........................................................................................................
185
xii10.5.MENSAJES...................................................................................................................
18810.6.CONTROLDECONCURRENCIA......................................................................................
18910.7.DOMINIOS
...................................................................................................................
19210.8.IMPLEMENTACIN.......................................................................................................
19810.9.CONCLUSIONES
...........................................................................................................
201CAPTULO11-SENSEIGMNS..........................................................................................
20311.1.GESTINBSICADEGRUPOS
.......................................................................................
20411.2.SERVICIODEDIRECTORIO............................................................................................
20811.3.DISEODESENSEIGMNSENCOMPONENTESDINMICOS
............................................
21011.3.1.Implementacindeloscomponentes
....................................................................
21411.3.2.Integracindecomponentes.................................................................................
22011.3.3.Implementacindelosalgoritmos........................................................................
22211.4.CONCLUSIONES
...........................................................................................................
224CAPTULO12-CONCLUSIONESFINALES...................................................................
22712.1.APORTACIONESREALIZADAS.......................................................................................
22712.2.TRABAJOFUTURO........................................................................................................
231APNDICEA.ESPECIFICACINCORBADESENSEIGMS........................................
235A.1.GROUPMEMBERSHIPSERVICE.IDL.................................................................................
235A.2.INTERNALSENSEI.IDL
...................................................................................................
236APNDICEB.ESPECIFICACINCORBADESENSEIDOMAINS
..............................
239B.1.DOMAINEXCEPTIONS.IDL..............................................................................................
239B.2.STATETRANSFER.IDL....................................................................................................
240B.3.PROPERTIES.IDL............................................................................................................
242B.4.SUBGROUPSHANDLER.IDL
............................................................................................
243B.5.DOMAINMESSAGE.IDL..................................................................................................
245B.6.CONCURRENCY.IDL
......................................................................................................
245B.7.DOMAINGROUPHANDLER.IDL.......................................................................................
246B.8.INTERNALDOMAINMESSAGES.IDL
................................................................................
248APNDICEC.ESPECIFICACINCORBADESENSEIGMNS
.....................................
251C.1.GROUPMEMBERSHIPNAMINGSERVICE.IDL....................................................................
251C.2.MEMBERINFO.IDL.........................................................................................................
253C.3.SETMEMBERINFO.IDL...................................................................................................
253C.4.MAPSTRINGSET.IDL
.....................................................................................................
255C.5.GROUPSCHECKERSTATE.IDL.........................................................................................
257APNDICED.EJEMPLOSDECOMPONENTESREPLICADOS
................................. 259D.1.SETMEMBERINFOIMPL.JAVA
........................................................................................
259D.2.MAPSTRINGSETIMPL.JAVA...........................................................................................
264GLOSARIO...........................................................................................................................
271
xiiiBIBLIOGRAFA..................................................................................................................
273
Introduccin1Captulo1-INTRODUCCINEl enorme crecimiento de
Internet durante los ltimos aos supuso laaparicin de numerosas
compaas cuya presencia comercial se limitaba a estemedio, y la
necesidad de las compaas tradicionales de ofrecer tambin
susservicios en la red. Esta modalidad de servicios implica una
fuerte dependencia deesas compaas en Internet y los medios
empleados, de tal forma que ataquescibernticos pueden suponer la
cada del servicio y conllevar prdidas
econmicasmillonarias.Esteproblemaesmayorcuandoalacadadelservicioseaadelamsimportante
de prdida de datos, debido, por ejemplo, a la destruccin del
mediofsico empleado para su almacenamiento. Adems de problemas
externos, unservidor puede necesitar tolerar errores ms comunes,
comopuedaserunfalloenel sistema operativo que emplea, o en el
ordenadordondeseejecuta,queprovocanigualmente la prdida del
servicio. La solucin genrica a este problema detolerancia a fallos
es la replicacin de recursos: almacenar los datos en
diferenteslocalizaciones,geogrficamentedistantes,oduplicarlosservidoresempleados.El
desarrollo de un servicio que se ofrece simultneamente desde
diferentesservidores implica un problema adicional sobre ese
servicio, ya que debe
resultarconsistentealosclientes,ofreciendoencadamomentoresultadoscoherentesdesdecualquiera
de los servidores. Esta consistenciasuponenormalmenteunanecesidadde
comunicaciones entre los servidores, que deben sincronizar sus
accesos
ymodificacionesdelosdatos.Elresultadoesunmayorempleoderecursosyunpeorrendimientoencomparacinconelmismoservidornoreplicado,detalformaquelamayor
disponibilidad del servicio no justifica en muchas ocasiones la
prdida deIntroduccin
2eficiencia.Lasolucinenestecasoeselempleodereplicacionespasivas,dondehayun
nico servidor activo y uno o ms pasivos que slo se activan en caso
de cadadel primero. Sin embargo, hay aplicaciones que pueden
tolerar esa prdida derendimiento y servicios que no pueden soportar
la prdida de disponibilidad, porcorta que sea en el caso de
replicaciones pasivas, como puede ser el caso
dedispositivosesencialesenunavin.El diseo de un servidor replicado
activamente no supone nicamente elempleo de comunicaciones entre
todas las rplicas, sino un control de esascomunicaciones que pueden
presentar tambin problemas. Existen abundantessistemas de
comunicaciones en grupo que facilitan esta tarea,
primandogeneralmente la optimizacin de esas comunicaciones, con un
modelo denominadode sincrona virtual basado en el envo
fiabledemensajesmultipunto.Sinembargo,elbajoniveldeestaaproximacinimplicaundiseodeaplicacionesestructuradoenmensajes,
dificultando el empleo de soluciones de alto nivel, como pueda ser
lareutilizacindecomponentessoftware.Un servidor replicado es un
caso especfico de aplicacindistribuida,paralasque existen modelos y
arquitecturas que soportan paradigmas de programacindistribuida ms
avanzados que ese intercambio directo de mensajes. Ejemplos deestas
arquitecturas son CORBA, Microsoft DCOM o JavaRMI. Precisamente
laarquitectura CORBA se ha visto enriquecida recientemente con la
especificacin deun servicio de tolerancia a fallos soportando
replicaciones activa y pasiva.
Esteserviciopermitelacreacindeservidoresreplicadosempleandotcnicasdealtonivelcomoseparacindeinterfazeimplementacin,orientacinaobjetos,compatibilidadde
implementaciones sobre plataformas y lenguajes, y soporte de otros
serviciosavanzadosquepermitenempleartransacciones,entreotros.El
trabajo sobre el que versa esta tesis comparte dominio con este
servicioCORBAdetoleranciaafallos,yaquesoportaunmodelodereplicacinactivadealtonivel,
especificado a nivel interfaz de objetos. Sin embargo, los modelos
dereplicacin son muy diferentes. Sensei [Sensei] se centra en la
replicacin activa eimplementa un sistema que soporta JavaRMI adems
de CORBA. Por otra parte,
lagranularidadenlareplicacinestambinmuydiferente;mientrasCORBA,congransoporte
para replicacin pasiva, debe tomar el servidor completo como unidad
dereplicacin, nuestro trabajo se basa en la factorizacin del
servidor en varioscomponentesquepuedenserreplicados.El principal
objetivo de esta tesis es la integracin del modelo de bajo
niveltradicionalmente empleado para el desarrollo de aplicaciones
replicadas con losmodelos de alto nivel empleados actualmente en el
diseo e implementacin deaplicaciones distribuidas, aportando una
metodologa que facilite la
replicacinactivadeservidores.Elresultadoquesepretendeessimplificarelprocesonecesariopara
esa replicacin, facilitando por lo tanto
eldesarrollodeservidorestolerantesafallos.
Comoobjetivosecundario,perototalmentenecesarioparalaconsecucindelanterior,SenseiextiendelosmecanismosdetransferenciadeestadodefinidosenelIntroduccin3modelo
de sincrona virtual, esenciales para la consistencia entre
servidoresreplicados.Para alcanzar estos objetivos, hemos
considerado componentes
individuales(definidosporlasinterfacesqueimplementan)comolaunidaddereplicacin,loquehasupuestodoslneasdeinvestigacin.Porunlado,hemosanalizadolacreacindeesoscomponentes,loquesuponeno
slo imponer un modelo orientado a objetos sobre una interfaz de
menor nivelbasada en el paso de mensajes, sino tambin la necesidad
de protocolos quegaranticen la consistencia de esos componentes, ya
que son instanciados sobrediferentes rplicas. La abstraccin as
conseguida es la de un nico componentecompartidoporesasrplicas.Por
otro lado, hemos considerado la integracin de esos componentes
paraconstruir aplicaciones tolerantes a fallos. Un problema
asociado a esta
integracineselciclodevidaespecialdeuncomponentereplicado,quepretendemosequipararal
de un componente normal para facilitar su empleo. Otro problema
importante esla concurrencia de acceso asociada a
esaabstraccindecomponentescompartidos,loqueimplicalanecesidaddesolucionesalosproblemasdeconcurrenciaderivados.Elplanteamientoempleadopararealizarestastareashasido:Diseo
de protocolos de transferencia de estado, directamente
especificadossobre el modelo de sincrona virtual e implementables
por lo tanto en
lossistemasdecomunicacionesengrupoyaexistentes.Especificacin de una
interfaz de transferencia de estado a alto nivel para losprotocolos
desarrollados. En especial, esta interfaz se ha integrado con
laespecificacindelservicioCORBAdetoleranciaafallos.Trasladarelniveldelainterfazempleadaeneldiseodeaplicacionesreplicadasdesde
un modelo basado en intercambio de mensajes a un modelo basado
enobjetoseinteraccionesentreobjetos.Desarrollo de un sistema propio
de comunicaciones fiables en grupo, bajo elmodelo de
sincronavirtual,consoportedelasarquitecturasCORBAyJavaRMIparalaespecificacindeinterfacesysuimplementacin.Captura
de patrones de diseo comnmente empleados en
aplicacionesreplicables, con el objetivo de definir un entorno de
implementacin que lossoporte.Desarrollo de una metodologa de diseo
de aplicaciones tolerantes a fallosbasada en su descomposicin en
componentes, facilitando su
implementacinylareutilizacindesoftware.Implementacin de un sistema
de soporte de la metodologa
desarrollada,permitiendoeldiseodeaplicacionesbasadasencomponentesreplicados.Introduccin
4Definicin de herramientas para la generacin automtica de
componentesreplicados a partir de su definicin de interfaz y una
implementacin de esainterfazsinsoportedereplicacin.Esta memoria se
ha organizado en doce captulos, incluyendo
estaintroduccin,ycuatroapndices.El captulo 2 trata los sistemas
distribuidos, explicando conceptos comosockets, arquitectura CORBA,
o modelos de mensajera y cliente/servidor. Su niveles slo
introductorio, siendo su lectura innecesaria en caso de poseer ya
esosconocimientosbsicos.El captulo 3 es tambin introductorio, esta
vez sobre sistemas distribuidosfiables, enfocado en los conceptos
fundamentales de fiabilidad y tolerancia a
fallos.Estudialosproblemasasociadosalascomunicacionesengrupo,ydetallalasbasespara
obtener comunicaciones multipunto fiables. Expone a continuacin el
modelodesincronavirtual,sobreelquesehadesarrolladoestetrabajo,ylosproblemasdeobservabilidadsobreaplicacionesreplicadas.En
el captulo 4 se describen los sistemas existentes
soportandocomunicaciones fiables en grupo. Esta descripcin es
detallada en los
mecanismosdetransferenciadeestadoentremiembrosdelgrupoqueesossistemassoportan,alser
estos mecanismos una parte importante de esta memoria. Se estudian
dossistemas en mayor profundidad: el servicio de tolerancia a
fallosdeCORBA,porsuimportanciaactual,yEnsemble,desarrolladoporelcreadordelmodelodesincronavirtualybaseinicialdeesteproyecto.El
captulo 5 es el primero de tres dedicado al estudio de la
transferencia
deestado.Trata,desdeunaperspectivaformal,delosproblemasdelatransferenciadeestadoentremiembrosdeungrupobajoelmodelodesincronavirtual.Estudialascondiciones
que debe verificar una aplicacin replicada para poder emplear
undeterminado tipo de transferencia, poniendo especial inters en el
caso detransferencias en varios pasos. Finalmente, propone
algoritmos genricos quesolucionanlosproblemasexpuestos.En el
captulo 6 se desarrollan los protocolos de bajo nivel
necesariosparasoportar transferencias de estado flexibles y
eficientes. Se estudian diferentes tiposde protocolos y se realizan
comparativas entre esos tipos que permitan elegir
elprotocoloadecuadoaunadeterminadaaplicacinoconfiguracintopolgica.En
el captulo 7 se estudia de nuevo el soporte de transferencias de
estadoflexiblesyeficientes,peroahoradesdeelpuntodevistadelainterfazdeaplicacin.Esta
interfaz contempla problemas tales como la concurrencia de
transferencias, laeleccin del miembro que las coordina o el bloqueo
de la aplicacin durante lastransferencias. Tambin se estudia la
implementacin de las interfaces
propuestassobrelosprotocolosdebajoniveldesarrolladosenelcaptulo6.Enelcaptulo8sedescribeSenseiGMS,unsistemadecomunicacionesfiablesdesarrolladoespecficamenteparaesteproyecto,quesoporta,medianteunainterfazIntroduccin5CORBA
o JavaRMI, el desarrollo de aplicaciones replicadas sobre el modelo
desincrona virtual. Describimos esta interfaz, que define una
funcionalidadestrictamente limitada al modelo de sincrona virtual,
y los algoritmos con que seimplementan, comparndolos con otros
algoritmos existentes. Explicamos acontinuacin cmo emplear y
configurar SenseiGMS e introducimos
finalmenteVirtualNet,unsistemadesarrolladoparaprobaraplicacionesreplicadas,enfocadoenlosproblemasdecomunicacionesentrerplicas.El
captulo 9 parte del modelo orientado a objetos soportado por
SenseiGMSpara desarrollar una metodologa de desarrollo de
aplicaciones tolerantes a fallos.Esta metodologa cubre patrones de
diseo, como la sincronizacin requerida entresolicitud y respuesta
en los accesos a servidores replicados, o la transformacin
deoperaciones sobre estos servidores en mensajes al grupo, y
estudia laautomatizacin del proceso de replicacin
ysuslimitaciones,enfocndoseentoncesen el empleo de componentes. La
metodologa estudia la integracin de estoscomponentes y los
problemas de concurrencia que aparecen, incorporandosoluciones como
monitores o transacciones. Por ltimo, comparamos el
modelodesarrolladoconeldelservicioCORBAdetoleranciaafallos.El
captulo 10 describe SenseiDomains, una implementacin de la
anteriormetodologa desarrollada sobre SenseiGMS. Describimos su
interfaz y soporte, y
sediscutenlosaspectosydecisionesdeimplementacinqueafectanalametodologa.En
el captulo 11 se describe una aplicacin integral de Sensei,
denominadaSenseiGMNS y que completa la implementacin del modelo de
sincrona virtual. Sudiseo se realiza sobre SenseiDomains, con lo
que sirve adems para mostrar
unejemplodeaplicacindelametodologadesarrollada.Finalmente,elcaptulo12muestralasconclusionesdenuestroproyectoysusactualeslneasdeinvestigacin.Esta
memoria se completa con cuatro apndices. Tres listan las interfaces
dealto nivel de las diferentes partes del proyecto: SenseiGMS,
SenseiDomains,SenseiGMNS,yelltimomuestraejemplosdecomponentesreplicados.Introduccin
6Sistemasdistribuidos7Captulo2-SISTEMASDISTRIBUIDOSEltemadesistemasdistribuidosabarcaunamplioconjuntodeconceptoscuyaexplicacin
difcilmente puede reducirse a un captulo introductorio. Nos
limitamosaquaexponerunaseriedetrminosyconceptosqueempleamosalolargodeestamemoria,detallandoigualmenteotrosporsuposibleasociacinconlosexpuestos.La
forma ms elemental de interpretar un sistema distribuido es la de
unsistema computacional compuesto por diferentes procesadores
interconectados.Normalmente, esta interconexin estar soportada por
una red abierta, basada enun conjunto
deprotocolosestndarquepermita[Schmidt95a]lacolaboracinentreaplicaciones,escalabilidadyportabilidad.Esta
interpretacin no es, sin embargo, completa; los componentes de
unaaplicacin distribuida pueden residir en la misma mquina o en
distintos nodosdela red y, por lo tanto, al hablar de las
interconexiones no se trata tanto de que
seproduzcanatravsdeenlaceshardware,sinodecomunicacionesentreprocesos.Lassiguientesseccionesmuestranlosconceptosenlosquenoscentramosenesta
introduccin: modelos distribuidos, sockets, procedimientos remotos,
objetosdistribuidosytendenciasactuales.Sistemasdistribuidos
82.1.ModelosdistribuidosEn todo servicio pueden identificarse dos
papeles: el servidor, que procesauna solicitud de servicio, y el
cliente, que la enva.
Laarquitecturacliente/servidor[Berson96]esunmodelodistribuidodondeestospapelesseencuentranclaramentediferenciados.UnejemploesunnavegadordeInternet:elnavegadoreselclientequeaccedeaunapginaWeb,suministradaporunservidorhttp.En
general, el trmino cliente/servidor se asocia a
arquitecturascentralizadas, donde una determinada mquina presta un
servicio especfico. Sinembargo, un servidor puede actuar a la vez
como cliente de otro servidor. Enespecial, dos componentes
cualesquiera de una determinada aplicacin
puedenactuarsimultneamentecomoclienteyservidor,mutuamenteentres.Enestecaso,tenemosunaaplicacinP2P(parapar)[Oram01],cuyaprincipalcaractersticaessudescentralizacin.
Un ejemplo muy conocido es Napster, un sistema de
intercambiodeficheros1dondestosnoresidenenunservidorcentral,sinoencadaunadelasmquinas
conectadas al servicio. En este caso concreto, existe todava un
servidorcentral que mantiene las listas de ficheros, pero la carga
de trabajo sobre
esteservidoresmuchomenorquesituvieraquealbergarysuministraresosficheros.Otraalternativaeselmodelodemensajeraoeventos,unmodelodistribuidodonde,
aunque existen servidores y clientes, stos no se encuentran
directamenteacoplados, es decir, el cliente no accede directamente
al servidor para obtener lainformacin. En su lugar, se emplean
entidades intermedias, generalmentedenominadas canales o colas de
mensajes o eventos [Schmidt97]. En este caso, elservidor enva su
informacin en un mensaje, que se mantiene en una cola dondepuede
ser accedido por el cliente o clientes. Este desacoplamiento entre
servidor ycliente implica que un determinado canal de informacin
puede ser accedido pormltiples clientes, pero tambin puede ser
suplido por mltiples servidores. Yresulta especialmente til para
aplicaciones cuyos componentes no estnpermanentemente conectados.
Este paradigma se emplea en el caso de correoelectrnico, donde
entre el emisor y el receptor de un correo existe una cola
demensajes.En este ltimo caso la arquitectura sigue siendo
cliente/servidor.Simplemente se introduce una nueva entidad, la
cola de mensajes o canal deeventos, que acta como cliente para
losproductoresdeeventosydeservidorparalosconsumidores.Existen otros
modelos distribuidos, menos empleados o de dominio msrestringido.
Por ejemplo, JavaSpaces [Freeman99] define una estructura de
datos
1 Los ficheros contienen msica codificada en formato MP3; el
intercambio indiscriminado deesta
msicanorespetabalosderechosdeautorprovocdemandasjudicialesyelcierredelservicio,porloquenonosesposibleindicarenestemomentounareferenciaasupginaWeb.Sistemasdistribuidos9accesibleporlasdistintasaplicacionesdistribuidasquenoesmasqueunacoleccindedatosconpropiedadestransaccionables.AunquesedesarrollasobreJavaRMI(unsistema
que explicamos a continuacin), la abstraccin que ve el
desarrollador
essimplementeundiccionario(HashMap)dondepuedeescribiroleerdatos,datosqueson
entonces disponibles por las dems aplicaciones, sin necesidad de
acceder
almodelodemensajesdeJavaRMI.Esteparadigmadeprogramacindistribuidanoesoriginal
de JavaSpaces, est fuertemente influenciado por los sistemas
Linda[Gelernter85].Otro ejemplo lo ofrece JavaParty [Philippsen97].
En este caso, la mquinavirtual de Java se implementa de forma
distribuida, de tal forma que los objetosdeclarados remotos pueden
migrar sobre las distintas mquinas que integran elentorno
distribuido, para lo que hace falta
modificaryextenderlasemnticadelasoperaciones. Aspectos inherentes a
JavaRMI como el registro y publicacin de
lasidentidadesdelosobjetosremotosquedanocultosaldesarrollador.2.2.SocketsLa
comunicacin entre clientes y servidores, bajo cualquiera de los
modelosdistribuidos, se realiza a bajo nivel sobre un determinado
protocolo de red, siendoTCP/IP el ms empleado. Cada dispositivo en
red recibe una direccin IP nica
(almenosenelmbitodeesared)quelaidentificaparasuscomunicaciones.Unpuntofinal
de comunicaciones queda definido por la direccin IP y un nmero
depuerto,es decir, un mismo dispositivo puede tener mltiples lneas
de comunicacinabiertas,almenosunaporcadapuertoempleado.La
popularidad actual de TCP/IP se debe a Internet, que lo emplea
comoprotocolodered,yhasidoelprotocoloempleadoenmquinasUnixdesdesuinicio.A
principios de los 80 la distribucin Unix de Berkeley introdujo el
modelo desockets como un mecanismo de comunicacin entre procesos
[Leffler89], que se haconvertido en el estndar de facto para
programacin en red sobre TCP/IP. Sinembargo, su API (interfaz de
programacin de aplicaciones) puede en
principiousarseconotrosprotocolosdered.Un socket [Stevens90] es un
punto final de comunicacin, identificado enTCP/IP mediante la
direccin IP y un puerto. Existen dos tipos de sockets:orientados a
conexin (TCP) y sin conexin, tambin llamados datagramas
(UDP).TCPcreauncircuitovirtualentrelosprocesosquecomunica,porloquelossocketssobre
TCP se consideran fiables. Los datagramas no son fiables ni se
asegura elorden o no duplicacin de los datos enviados, pero
permiten el envo de
mensajesbroadcast,amsdeundestinofinal.Unservidorqueempleasockets
debeasociarseaunadeterminadadireccin,dondeesperacontinuamentelallegadadedatos.Unclientedebeconocerculesesadireccin
especfica para enviarle datos. La informacin que se transmite no
tieneSistemasdistribuidos
10ningnsignificadoparalossockets,queactannicamentecomopuntosdeentradaysalidaparalascomunicaciones.Eslaaplicacinlaquedebeinterpretaresosdatosyproducir,posiblemente,unarespuesta.2.3.RPCLlamadasaprocedimientosremotosUn
ejemplo sencillo de aplicacin cliente/servidor es el de un servicio
deautentificacin:unclientesuministraunnombre(login)yunaclave(password),yelservicio
comprueba su validez. Empleando sockets, el cliente debe conectarse
alservidor y enviar en una cadena de bytes la informacin necesaria,
el nombre y laclave, que suponemos que son cadenas de caracteres.
No existe ningn
requisitosobrecmoenviaresainformacinyelservidordebeespecificarquformatoespera.Porejemplo,unprimerbytequeindiquelalongituddelnombre,seguidoportantosbytescomocaracterestengaelnombre,yluegootrobytequeindiquelalongituddela
clave y tantos bytes como caracteres tenga esa clave. Es
responsabilidad delcliente el aplicar correctamente el formato
esperado. Y este formato debeespecificarse con mayor detalle: qu
orden de bytes se espera, big-endian o little-endian, qu
codificacin de caracteres, ASCII o EBCDIC, etc. Adems, la
aplicacindebe gestionar los errores de comunicaciones. Desde el
punto de vista del servidor[Schmidt95b], si precisa soportar varios
clientes simultneamente, es tambin laaplicacin la que debe incluir
toda la lgica de concurrencia y de gestin
demltiplesclientes.Unalibrerapuedesoportarelformateo/deformateodedeterminadostiposdedatos,
definiendo cmo transferir cadenas de caracteres,
tiposenteros,etc.Sitantoel servidor como el cliente emplean la
misma librera, parte de los
anterioresproblemassesolucionan.RPC[White75]suministraestesoportedelibrera,alavezque
realiza una abstraccin de llamadas a procedimientos [Birrel84].
Siguiendo elejemplo anterior, el servidor puede especificarse como
una funcin definida de
lasiguientemanera:intvalidate(inchar*login,inchar*password);Al
emplear un compilador RPC sobre esta definicin, se generan
dosporcionesdecdigo.Unasellamastubdelcliente,yloquehaceesproporcionarunprocedimiento
con la misma definicin dada. El cliente invoca este
procedimiento[figura2.1],ysteautomticamentepreparalacadenadebytesaenviaralservidor,formateando
los datos y envindolos a travs del socket. La segunda porcin
decdigo se denomina stub del servidor, y verifica continuamente el
socket donderecibe la informacin, que deformatea y enva al
servidor. Cuando se elabora
larespuesta,staseenvaporelcaminoinverso.De esta forma, se accede al
servidor como si fuera local, al que le
invocamedianteprocedimientos,talcomosifueraunalibreradelsistema.Sistemasdistribuidos112.4.ObjetosdistribuidosLa
evolucin de los lenguajes de programacin hacia el paradigma
deorientacin a objetos supone que el procedimiento ya no
eslaestructurabsicadeun programa, que pasa a estructurarse en
objetos. Como extensin, los
sistemasRPCevolucionanpararealizarlaabstraccindeobjetosremotos.JavaRMI
(Remote Method Invocation) [Dwoning98] soporta esta
abstraccinsobreobjetosJava.Unobjetodistribuidoesaccesibledeformaremotaatravsdesuinterfaz,definidaenJava.ElcompiladorRMIgeneraapartirdeestainterfaz,aligualqueenRPC,porcionesdecdigoquesimulanelaccesolocaldelosobjetosremotos.En
este caso, el cliente emplea stubs o proxies, y al servidor se le
asocian
losskeletons.Ademsderealizarunaabstraccindeobjetosremotos,JavaRMIproporcionaotras
facilidades a la aplicacin. Por ejemplo, dispone de un servicio de
directorio,denominado registro, donde las aplicaciones pueden
publicar sus servidores,asocindolos a un nombre. Un cliente no
necesita ahora conocer la
localizacinexactadelservidor,bastaconqueaccedaaesteservicioparaobtenerunareferenciaal
objeto remoto. Otra facilidad es el concepto de
objetoremotopersistente,quenoest activo continuamente y se activa
cuando un
clienteloinvoca,loquefacilitaelescaladodelasaplicaciones.RPCStubclienteClienteRPCStubservidorServidorMensajesderedFlujoaparenteFigura2.1.Filosofa
deRPCSistemasdistribuidos 12Aunque hemos descrito primero por su
mayor simplicidad JavaRMI, CORBA(Common Object Request Broker
Architecture) [OMG98] es una arquitectura anterior,diseada por el
OMG (Object Management Group) con el mismo objetivo
bsico:manejarobjetosdistribuidosdeformatransparente.En JavaRMI,
todo el sistema se programa con un nico lenguaje, mientrasque CORBA
soporta actualmente (como estndar) nueve: C, C++, Java,
Cobol,Smalltalk, Ada, Lisp, Python y CORBAScript. Por esta razn, la
definicin de lainterfaz de los objetos remotos o componentes se
hace en un lenguaje
propio,OMG/IDL.UncompiladordeIDL,especficoparacadalenguaje,generadenuevolosstubsyskeletons.La
mayor complejidad no se debe slo a la variedad de lenguajes
soportado,sino a la funcionalidad que implementa [Orfali97]. Parte
de esta funcionalidad seincluye en el ORB, que es el gestor de
objetos distribuidos, pero la arquitectura[figura 2.2] emplea
elementos opcionales, como los servicios CORBA [OMG97],
queimplementan funcionalidad genrica, o las facilidades CORBA, que
implementanfuncionalidad asociada a determinados tipos de
aplicaciones. La figura 2.3
muestralasinteraccionesenelclienteyelservidor;suscomunicacionesserealizanatravsdel
ORB y generalmente empleando los stub y skeleton generados. Sin
embargo,existen otras opciones; por ejemplo, el cliente puede
desconocer en tiempo
decompilacinculeslainterfazdelservidoralqueaccede,encuyocasodebeemplearlainterfazdeinvocacindinmica.Unelementoimportanteenestaarquitecturaeseladaptadordeobjetos,cuyafinalidad
es aislar al ORB del lenguaje empleado para implementar los
servidores.ORBServicios de objetosIntf. aplicacin Intf. dominio
FacilididadescomunesFigura 2.2.Modelo de arquitectura
OMASistemasdistribuidos13Existen diferentes adaptadores, y el ms
habitual es el POA (Portable ObjectAdapter), que maximiza la
portabilidad de las aplicaciones, a nivel de cdigo,
sobrediferentesimplementacionesdeORB.Empleando la notacin de CORBA,
se distingue entre servant, que es laimplementacin en un lenguaje
especfico de la interfaz que define un servicio, yservidor
propiamente dicho, que
eselobjetoactivocapazdeprocesarlaspeticionesde servicio.
Normalmente, existe un servant por cada servidor, pero una
aplicacinpuede tomar otras alternativas, como que un servant
encarne mltiples servidores.Los servidores pueden ser persistentes,
en cuyo caso el ORB los debe activar sillegan peticiones de
servicio, ylaaplicacinpuedeinclusoemplearunservantparacada peticin
a un mismo servidor. Otra utilidad de esta distincin es que
unservidor puede migrar a una mquina diferente (donde emplea
evidentemente
unservantdiferente)deformatotalmentetransparenteparaelcliente.UnadelasprincipalesventajasdeCORBAessuinteroperabilidad,quepermiteque
objetos implementados en lenguajes, sistemas operativos y tipos de
mquinadiferente se comuniquen entre s. No es preciso
quelosobjetosempleenunmismoORB,
contalquelosempleadosseancompatiblesconlamismaversindeCORBA.Es
incluso posible que un objeto CORBA se comunique con un objeto
JavaRMI, apartir de la especificacin [OMG99] de RMI sobre IIOP, el
protocolo estndar paracomunicacinentreORBssobreredesTCP/IP.Existen
otros gestores de objetos remotos. Por ejemplo, el sistema
operativoWindowsempleaunopropio,conunmodelodeobjetosdistribuidosllamadoDCOM(DistributedComponentObjectModel)[Sessions97].PermitetambinlainteraccindeFigura
2.3.InterfacesORBCliente Implementacin del
objetoSkeletonIDLestticoSkeletondinmicoAdaptadordeobjetosInvocacindinmicaStubsIDLInterfaceORBNcleo
delORB(ORBcore)Haystubsyskeletons paracadatipo de
objetoPuedehabermltiplesadaptadores de
objetosInterfazidnticoindependientemente delORBInterfazdependiente
delORBSistemasdistribuidos 14componentes escritos en distintos
lenguajes, pero siempre sobre el mismo tipo
demquinaysistemaoperativo.Noesposiblerealizaraesteniveldeintroduccinunacomparativa
entrelosgestoresexpuestos;as,aunqueanivelarquitectural,CORBAest ms
maduro, existen otras consideraciones que pueden inclinar la
eleccin deun gestor de objetos hacia DCOM o JavaRMI [Chung98,
Gopalan98, Curtis97,Juric00].2.5.TendenciasactualesEmpleando
sockets, un servidor espera las solicitudes de servicio en
unadireccin IP determinada y un puerto especfico. Ese servidor
puede
desarrollarseempleandoJavaRMIoCORBA,peroaunasestdisponibleenunpuertoespecfico.La
tendencia actual a ofrecer servicios a travs de Internet implica
que lascompaas instalan mquinas que son accesibles pblicamente, lo
que supone
laposibilidaddeataquesmaliciososdondeunhackerescapazdeaccederalamquinaensutotalidadyleerinformacinprivada.Unarespuestaaesteproblemaesocultarlas
mquinas tras firewalls, que controlan el flujo de datos entrante y
saliente; laseguridad que se obtiene es mayor cuanto menos puntos
de acceso tenga unamquina, ya que cada puerto abierto (esto es,
donde un servidor espera
solicitudesdeservicio)esunpuntodbildelsistema.Unsistemasegurodejaelmnimonmerodepuertosabiertos,ysloaquelloscuyoprotocoloseconsidereseguro.Porejemplo,unservidorWebdebeseraccesibledeformaestndarenelpuerto80.UnaimplicacindirectaesladificultaddeofrecerserviciospblicosmedianteservidoresCORBAoJavaRMIqueesperendirectamentelas
solicitudes de servicio. Una alternativa factible recibe el nombre
de
httptunneling.Significaquelassolicitudesserecibenatravsdelpuerto80(http),comosi
fueran accesos Web normales; una vez recibidas, deben propagarse al
servidorespecfico, resultando en su conjunto en una prdida de
rendimiento yfuncionalidad.J2EE, Java Enterprise [Allaramaju01],
ofrece un amplio abanico
deposibilidadesenestesentido.Porejemplo,conJSP(JavaServerPages),seaccedeauna
pgina Web cuyo contenido es dinmico, dependiente del estado del
servidor;puede recibir solicitudes de servicio que se propagan
automticamente a
unoscomponentesJavadenominadosEnterpriseJavaBeansqueprocesanelservicio.Lascomunicaciones
entre estos componentes se realizan mediante JavaRMI (la
ltimaespecificacinempleaRMIsobreIIOP).El contenido de una pgina Web
ha sido normalmente HTML, un
lenguajebasadoenetiquetasquepermiteespecificarelformatodelosdatosenelnavegador.Un
lenguaje similar es XML [W3C00], en cuanto a que est tambin basado
enetiquetas,peronotieneunaestructurafija.Esposibledefinirestaestructura,loquelo
hace muy conveniente para el envo de datos. Como stos se
transfieren enSistemasdistribuidos15formato texto ASCII, pueden
compartirse los datos con independencia de laplataforma software y
hardware. Es decir, dos componentes pueden enviarseinformacin en
formato XML sin preocuparse por lenguajes de programacin o
elsoporte hardware. Al definir su descripcin XML, definen las
estructuras de losdatos que se intercambian, que pueden
perfectamente identificar solicitudes deservicio.XML no define
protocolos o mecanismos para la transmisin de los datos.SOAP
[W3C01] es un protocolo ligero basado en XML que permite la
invocacin
deserviciosremotossobrehttp,yeslabasedelosserviciosWebqueestnempezandoa
popularizarse. Al definirse sobre http, se pueden emplear todos los
mecanismosactualesempleadosparaelmanejodepginasWeb.Todas las formas
de comunicaciones mostradas estn basadas a nivel detransporte en el
empleo de sockets, pero el modo de acceder al servidor y a
susservicios se realiza ahora a un nivel muy superior, definiendo
de alguna forma
lainterfazdeeseservidor.Conprocedimientosyobjetosremotos,lainterfazseenfocaen
la forma de acceder al servidor, definindose las operaciones a
realizar
parainvocarsusservicios,mientrasqueconXML,lainterfazseenfocaenlainformacinaobtenerdeeseservidor.2.6.ConclusionesLa
eleccin de la arquitectura CORBA como marco de trabajo para
larealizacin de esta tesis se debe esencialmente a que en este
momento ofrece elmodelo de programacin distribuida ms estndar, de
amplia difusin en laindustria, y que soporta el paradigma de
orientacin a objetos integrado en lasprcticas de ingeniera de
software actuales. Asimismo, los resultados
obtenidosenestemodelosonfcilmentetrasladablesaotrastecnologassimilares.PruebadeelloesquetambinsehanaplicadoenJavaRMIconmnimoscambios(reutilizandogranpartedelcdigodelossistemasimplementados).Sistemasdistribuidos
16Sistemasdistribuidosfiables17Captulo3-SISTEMASDISTRIBUIDOSFIABLESEste
captulo realiza primero una introduccin a los sistemas fiables y
acontinuacin,secentraenlosgruposdinmicosderplicascomomtodoparahacerfiableunsistema.Losgruposdinmicossebasanenelmodelodesincronavirtual,queempleacomunicacionesmultipuntofiables,yenunservicioquemanejalalistadinmica
de miembros del grupo. Este servicio y el
modelodesincronavirtualsondescritos en detalle, as como la
observabilidad del sistema: cmo es observado
elgrupodecomponentesalactuarcomounnicoservidor.3.1.FiabilidadEsta
seccin introduce los principales conceptos asociados a sistemas
fiables:toleranciaafallos,fiabilidadydescripcindeesosfallos.Acontinuacindescribelossistemas
distribuidos y los problemas adicionales que plantean respecto
aaplicaciones monoprocesador, as como la forma de detectar y
simplificar
esosproblemasaadidos.Finalmente,sedescribenlostiposdegruposdecomponentesylasbasesparaobtenercomunicacionesfiablesentrecomponentesdistribuidos.Sistemasdistribuidosfiables
183.1.1.ToleranciaafallosTodoserviciopuededefinirseapartirdelconjuntodesalidasqueseproducenapartirdeunasentradas,definicinquedebecomplementarseconlasemnticadefallos
del servicio, que
especificaloserroresposibles.Existenvariasclasificacionesdeestoserrores[Christian91,Birman96]Falloporomisin:elservicionorespondeaunaentradaomensaje.Puedeserasuvezunfalloenlaemisindelmensajeoensurecepcin.Fallo
de temporizacin: la respuesta llega fuera de un margen de
tiempoespecificado(mrgenesmnimoymximo).Estefallopuededarseporproblemasajenosaloscomponentesmismoscomo,porejemplo,fallosenlared.Fallo
en la respuesta: el servicio
ofreceunarespuestaincorrecta.Enestegrupodeerroresentranlosfallosbizantinos[Lamport82].Fallo
por cada: el servicio se cae. Este error viene acompaado
evidentementeporunodelosanteriores.Estos fallos pueden ocurrir
tanto en componentes hardware como encomponentes software. En este
ltimo caso, los errores que provocan los fallos
seclasificanenlasdoscategorassiguientes:Bohrbugs:fcilmentereproducibles,resultafcilencontrarlosyfijarlos.Figura
3.1.Soporte de errores enla
respuestausandoreplicacingetCountergetCountergetCounterReturn
5Return 4Return 5getCounterReturn
5Sistemasdistribuidosfiables19Heisenbugs: difciles de reproducir,
resulta complicado encontrarlos y,consecuentemente,fijarlos.La
tolerancia a fallos de un
sistemaessuhabilidadpararecuperarsetraselfallo de algn componente.
Otros dos conceptos relacionados son la fiabilidad y
ladisponibilidad del sistema: la fiabilidad de un servicio da la
probabilidad decomportamiento correcto de ese servicio, y su
disponibilidad es el porcentaje
detiempoenqueelserviciopuedeproporcionarse.Una forma de incrementar
la tolerancia a fallos de un sistema es
lareplicacindesuscomponentes[Neumann56].Siuncomponentesecae,elsistemapuede
an emplear su rplica o rplicas. La forma en que estas rplicas
debentrabajar depende de la semntica de fallos de los componentes.
Por ejemplo, sipueden dar eventualmente respuestas errneas (fallo
en la respuesta), el
serviciopuedeaccederatodaslasrplicasydarlarespuestamayoritaria[figura3.1].3.1.2.SistemasdistribuidosUna
aplicacin puede tolerar fallos en la implementacin de un
algoritmo[Maguire93]empleandounaimplementacinalternativaindependiente,posiblementeno
optimizada, que pueda comprobar los resultados dados por el primer
algoritmo.Esdecir,seempleandistintasimplementacionesyposiblementedistintosalgoritmosparaevitarerroresdecodificacinodelgicaenelalgoritmo.Siesaaplicacindebetolerar
fallos en el ordenador sobre el que se ejecuta, deber procesarse en
dos oms ordenadores y sincronizar de alguna manera las distintas
instancias de esaaplicacin, lo que lleva al concepto de computacin
distribuida. Este conceptoimplica un conjunto de programas
fuertemente acoplados, ejecutndose en dos
omsordenadoresycoordinandosusacciones.Para conseguir que una
determinada arquitectura tolere fallos en suscomponentes, debe ser
capaz de detectar cundo esos componentes fallan, y
estadeteccinestrelacionadaconelmodelodistribuido:Sistemas sncronos:
fuertemente dependientes de la temporizacin, todos suscomponentes
comparten una medida de tiempo; esta sincronizacin de
loscomponentes permite dividir el tiempo en periodos (que todos los
componentesven iguales), siendo los mensajes enviados al principio
de cada periodo yprocesados al inicio del siguiente. Asume, por
consiguiente, una perfectacoordinacin de los componentes y sus
acciones, coordinacin quenoexisteenla inmensa mayora de los
sistemas reales. Detectar lacadadeuncomponenteesinmediato.Sistemas
asncronos: el concepto del tiempo desaparece, lo que impide
realizarsuposicionessobrevelocidadesdelared,delosprocesos,etc.Nohaylmitesenlos
retrasos de los mensajes o en el tiempo necesario para ejecutar
cualquierpasoyesimposibledetectarsiuncomponentesehacadooessimplementemuySistemasdistribuidosfiables
20lento. Es un modelo irreal, que permite realizar simples
abstracciones delsistemaaleliminarelconceptodetiempo.Sistemas
intermedios, denominados asncronos reales o asncronos
parciales:existe el concepto de tiempo, y los mensajes entre
componentes se realizandentro de unos lmites de tiempo. Esta
definicin es muy amplia, pues
esoslmitesnotienenporquserconocidosoestables;segnsedefinan,seobtienendistintossistemasasncronosparciales[Dwork88].La
deteccin de
fallosest,consecuentemente,ligadaalasincronizacindelsistema, y
cuanto ms sincronizado sea ste, ms factible ser realizar
unadeteccin de fallos fiable. En un sistema real, cuando un
componente enva
unmensajeaotro,esperaunarespuestaenuntiempomximo.Vencidoestetiempo,elcomponente
debe suponer un fallo, pero no puede decidir dnde se ha
producidoste,pueselproblemapuededebersea:Problemas en las
comunicaciones: el mensaje no ha llegado alotrocomponenteque, por
lo tanto, no lo ha procesado, o bien
hallegadoylohaprocesado,peronoseharecibidolarespuesta.Elcomponentesehacado.Elcomponenteesmuylento,oestprocesandomuylentamenteelmensajeporotrascausas.Enestascondiciones,elprimercomponentenopuedesabersielsegundosehacadoonoy,enesteltimocaso,sihaprocesadoelmensajeono;porestarazn,los
algoritmos para las comunicaciones entre estos componentes resultan
muycomplicados.Una forma de simplificar los algoritmos en
aplicaciones distribuidas
esdisponerdeunsistemaquegestioneestosproblemasylibereaesosalgoritmosdelalgicaasociada;esesistemasonlosdetectoresdefallos.3.1.3.DeteccindefallosUn
detector de fallos comprueba que los componentes de un sistema
nopresentan errores, y si detectan un fallo, lo comunican a los
dems componentes.Pero, al igual que un componente no puede
determinar si otro ha fallado o no,
eldetectordefallostampocopuedeconsiderarseseguroyelsistemadebesoportarunadeteccinincorrectadefallosdeloscomponentes,paraloquehaydosopciones:La
aplicacin considera que el detector de
fallosesperfecto;cualquierelementoque el detector de fallos
considera sospechoso lo es para siempre, siendoexcluidodelgrupo.La
aplicacin considera que el detector de fallos es imperfecto; sus
algoritmosdeben entonces ser capaces de progresar sabiendo que
estas detecciones
sonSistemasdistribuidosfiables21imperfectas,ynoconsiderarexcluidosaloscomponentessospechosos.Lalgicadelgruporesultamuchomscomplicadaqueenelprimercaso.Laimplementacindeundetectordefallosserealizageneralmentemediantetemporizadores.
Cada componente emite mensajes, cuya recepcin permite a
losdemscomponentescomprobarquenosehacado.Silaaplicacinconsideraqueeldetector
es perfecto, estos temporizadores deben ser lo suficientemente
largos paraque el nmero de
fallosseamnimo,puestoquesusfallosexcluyendirectamentealosmiembrossospechosos.Existenotrosmtodosparadetectarlosfallos,basndoseen
caractersticas determinadas de un sistema o arquitectura, pero no
puedenconsiderarsegenricas.Undetectordefallospermitecomprobarsiundeterminadocomponentesehacadoono.Yunfalloenlascomunicacionesconuncomponentepuedeversecomounfallodeesecomponente.Elproblemasurgeenqueelotrocomponentenosehacado,
pero observar recprocamente un fallo en el primer componente, con
lo quehay dos componentes que sospechan mutuamente uno del otro.
Extendiendo esterazonamiento, un problema real en los
enlacesconlosqueungrupoderplicassecomunica puede provocar la
creacin de dos o ms subgrupos, sospechando
cadaunoquelosdemsestnfallando:laparticindelaredhaprovocadounaparticindel
grupo. Como adems el detector de fallos es imperfecto, un enlace
lento puedeprovocar el mismo resultado; en este caso, una particin
virtual de la red
puedesuponerunaparticindelgrupo.3.1.4.GruposdecomponentesUna forma
de incrementar la tolerancia a fallos de un sistema es lareplicacin
de sus componentes: este grupo de componentes es visto como
unaentidad nica, y un cliente que deba acceder al servicio prestado
por esecomponente acceder al grupo como un ente, sin conocer el
nmero, identidad olocalizacionesdelosmiembrosindividuales.Estos
grupos pueden ser estticos o dinmicos; los grupos estticos
estnformados por un conjunto predeterminado de elementos. Incluso
cuando
estoselementossecaen,siguenperteneciendoalgrupo;porello,siunelementotomaunadecisin,
todos los dems, incluidos los elementos cados, estn obligados a
seguiresa decisin. Se supone, por lo tanto, que el elemento cado
puede volver alevantarse, y debe haber guardado la informacin
necesaria para completar esadecisin.En los grupos dinmicos, la
lista de elementos del grupo se consideradinmica, y la misma lgica
del grupo contempla la inclusin y exclusin demiembros. Un elemento
cado queda directamente excluido del grupo. Si
unelementotomaunadecisin,slolosdemselementosquepermanezcanfuncionalesdeberntomarlaigualmente.Haydostiposdegruposdinmicos:Sistemasdistribuidosfiables
22Grupos dinmicos no uniformes: si un elemento toma una decisin
pero se
caeantesdecomunicarlaalgrupo,noesprecisoqueloselementosactivosrestantestomen
esa misma decisin. Adicionalmente, si toma una decisin y se
lacomunica a una parte del grupo, pero tanto ese elemento como los
que hanrecibido la comunicacin se caen, los dems elementos activos
no estnobligados a tomar esa decisin. Por ejemplo, un cajero
automtico, en laextraccin de pequeas cantidades de dinero, no
necesita comunicar esaextraccin y luego procesarla. Si se cae, un
registro contiene esa
informacin,conloquelatransaccinnosepierde.Gruposdinmicosuniformes:inclusosielelementoquetomladecisinsecae,los
dems elementos activos deben tomar la misma decisin. En el
ejemploanterior, para grandes cantidades de dinero, un cliente
podra crear un grandescubierto si accede a varios cajeros que
entregan el dinero y, antes
decomunicarlatransaccin,elcajerocorrespondientesecae.Estos
distintos tipos suponen distintos grados de consistencia, siendo
lamenor consistencia la alcanzada
enlosgruposdinmicosnouniformes.Losgruposdinmicos son ms potentes y
tolerantes a errores que los estticos, pero
resultantambinmsdifcilesdeimplementar.3.1.5.ComunicacionesfiablesSiunservicioseimplementamedianteungrupodecomponentesdistribuidospara
aumentar su tolerancia a fallos, esos componentes debern estar
encomunicacin para preservar la consistencia del sistema, y que
cada
componentepresenteunavisincoherentedeeseservicio.Esascomunicacionespuedenser:Comunicaciones
punto a punto: un componente se comunica con el
restomediantemensajesindividualesacadaunodelosmiembrosdelgrupo.Comunicaciones
multipunto (multicast) no fiables, como IP multicast.
Estascomunicaciones pueden resultar apropiadas para aplicaciones no
crticas en
larecepcindemensajes,dondelaprdidadeunmensajenoafectaalestadodelaaplicacin.
Por ejemplo, aplicaciones multimedia, donde la prdida del
mensajepuede simplemente suponer la falta de actualizacin en uno o
varios frames
devdeo.Comunicacionesmultipuntoatmicas:segarantizaqueotodosoningunodeloscomponentesprocesanlacomunicacin.Puedeserdinmicamenteuniformeono[Malki94];
si es uniforme, cuando un proceso procesa un mensaje, todos
losdemsprocesosenestadooperacionallodebenprocesarComunicaciones
multipunto best-effort, que no se consideran atmicos (todos
oninguno),puessuobjetivoescasitodosocasininguno;acambio,resultanmuyescalables
y ms apropiados, consecuentemente, para grandes grupos. Porejemplo,
en el protocolo multicast bimodal [Birman98], los componentes
seSistemasdistribuidosfiables23comunicanperidicamenteconotrosparacomprobarsihanrecibidolosmismosmensajes;siexistealgndesfase,setransmitenlosmensajesquefaltan.Trasunperiodo
de tiempo determinado tras la recepcin de un mensaje,
puedenprocesarlo asumiendo que si hubiera habido algn desfase, ya
se habradetectado; si la deteccin de un mensaje no recibido se
realiza despus deprocesar algn mensaje posterior, la aplicacin debe
ser capaz de retroceder alpunto inicial. Puesto que para detectar
si faltan mensajes un componente
secomunicaaleatoriamenteconotros,peronocontodos,ladeteccinnoessegura,yprecisadeunamayorcalidadenlascomunicaciones:noesaplicabledeformageneral.Ademsdelascondicionesdeatomicidad,lascomunicacionessecaracterizanpor
el orden de procesado, es decir, el orden con que distintos
componentes van
aprocesarlosmismosmensajes:Procesarlosmensajessinorden,talcomollegan.Ordenfifo:losmensajesenviadosporuncomponenteseejecutanenelordenenquesonenviados.Ordencausal:losmensajesenviadosporunoovarioscomponentes,quepuedanrelacionarse
causalmente, se procesan de acuerdo a esta relacin. Por
ejemplo[figura 3.2], si un componente A enva un mensaje y un
componente B,
alrecibirlo,envaunsegundomensaje,elprimeroprecedecausalmentealsegundo,ydondeambosmensajesdebanserprocesados,loharnenelordendebido.Es,porlotanto,unordenfifoincluyendoavarioscomponentes.Figura3.2.Orden
causalA B Cm1m2m1precedecausalmente am2m2llegaantesquem1:orden
causalnorespetadoA B Cm1m2Orden
causalm2m1m2m1Sistemasdistribuidosfiables 24Orden total: todos
loscomponentesdelsistemaqueprocesenunconjuntoigualdemensajes,losprocesarnenelmismoorden.Orden
total causal: orden total preservando la causalidad. Si un
componenteenvadosmensajes,elordentotalnoimplicaqueelprimermensajeenviadodebeejecutarseantesqueelsegundo,sinoqueeseordendeprocesadoserconstanteen
los dems miembros del grupo: es decir, si todos los miembros
procesanprimero el ltimo mensaje y luego el primero, el orden total
queda
todavapreservado.Elordentotalcausaleliminaestaposibilidad.Segn sea
el tipo de orden asociado con el multicast, se
producirndeterminadoserroresdeobservacindelosmensajesoeventos[Fidge96]:Observadores
diferentes viendo diferentes ordenaciones: dos
eventosconcurrentespuedanservistosendistintoordenpordosprocesos.Ordenaciones
incorrectas: incluso cuando un mensaje precede causalmente
aotro,esteordennoesvistoenunprocesodado(generalmenteporretrasosenelenvodemensajes).Indeterminismo
en la observacin de los eventos: el mismo proceso en
lasmismascondicionesgeneralesveloseventosendistintoordencuandoseejecutavariasveces.Ordenacionesarbitrarias:unprocesoquerecibeuneventoantesqueotrodeducequeloprecedecausalmente(cuandopuedenserconcurrentes).Las
opciones de ordenacin se denominan dbiles o fuertes segn
seandinmicamente uniformes o no (segn involucren o no a los
componentes queFigura 3.3.GapfreedomA B Cm1m2Orden
causal:m1precedeam2 FalloenAm2no puedeprocesarsehastahaberprocesado
m1.B deberecibirunacopia
dem1(deC)Sistemasdistribuidosfiables25fallan). Por ltimo, hay una
propiedad adicional relacionada con el orden demensajes, denominada
gap freedom: si el orden exige que un mensaje m1 seaprocesado antes
que m2, que m2 se procese implica que m1 tambin debe
haberseprocesado.Lafigura3.3muestraelresultadodeaplicarestapropiedad;unmiembroA
enva antes de caerse un mensaje m1, que alcanza al miembro C pero
no a B. Elmiembro C enva antes de detectar la cada de A un mensaje
m2 que,consecuentemente, sucede causalmente a m1. Cuando B lo
recibe, no puedeprocesarlo; aplicando la propiedad de gap freedom,
slo puede procesarlo tras m1,por lo que C, o cualquier otro miembro
del grupo que lo hubiera recibido,
debeenviarleprimerounacopiadeesemensaje.3.2.Serviciodemiembrosdegrupo(GMS)Los
miembros de un grupo dinmico deben permitir la inclusin de
nuevosmiembrosolaexclusindemiembrosactualesdelalista.Ademsdelosproblemasnaturales
de consistencia del grupo, se aade el manejo de las
posiblesinconsistencias que se pueden producir
coneltratamientodelalistademiembros.Por esta razn, los grupos
dinmicos se apoyan en un servicio externo, el
GMS(GlobalMembershipService),querealizalagestindelalistademiembrosdelgrupo.La
interfaz bsica de este servicio permite la inclusin de los
componentesque soliciten incorporarse al grupo y la exclusin de
miembros, bien porque
losolicitenoporquesesospechequefallen.Paraello,debeapoyarseenundetectordefallosyhacerlasfuncionesdelmismodecaraalgrupo.Segnlalistademiembrosva
cambiando, el GMS enva esta lista en forma de vistas a los
componentes
quequedanenelgrupo.Elcontenidodelavistapodrserlalistacompletaolalistadecambiosrespectoalaanteriorvista.Mediante
este servicio, el grupo slo debe encargarse de su
propiaconsistencia;comoademselGMSactacomodetectordefallos,secreaunentornodondelosnicosfallosquevenlosmiembrossonlosdecadadelosotrosmiembros.LoserroresenlascomunicacionessonabsorbidosporelGMS,quelostransformaennuevas
vistas; efectivamente, ante cualquier error o sospecha de error de
uncomponente, el GMS lo elimina del grupo, temporal o
permanentemente,
enviandounanuevavistaalosdemscomponentes.Laformadeinstalarestasnuevasvistasdebe
garantizar la propiedad denominada sincrona de vistas (view
synchrony)[Babaoglu96]: todos los componentes que sobreviven dos
vistasconsecutivasdebenhaberprocesadoelmismojuegodemensajesenlaprimeravista.Estapropiedadesfundamental
para mantener la consistencia del grupo entre las vistas; si
unmiembronohaprocesadoalgunodelosmensajesquelosdemshanprocesado,nosepodragarantizarsuconsistencia.Los
miembros de un grupo van recibiendo diferentes vistas del grupo
segnnuevos miembros se incluyen o quedan excluidos. Cuando un
miembro intentaSistemasdistribuidosfiables 26comunicarse con otro y
se produce unproblemaenesacomunicacin,transmiteelerror al GMS, que
considerar que uno o los dos miembros falla,
excluyndoleconsecuentementedelalista.ElempleodelGMSpermitesimularunentornodondelos
nicos fallos son por cada del componente [Sabel94], ocultando todo
problemade comunicaciones y particionado de la red, en tanto ese
GMS permanezca activo.Puesto que este grupo
pasaadependercompletamentedeesteservicio,unfalloenste provocar la
parada del grupo. Por esta razn, el GMS mismo debe estarreplicado,
es asimismo un grupo dinmico que se autogestiona mediante
unprotocolo denominado GMP (Global Membership Protocol). Al igual
que el GMSpermite incluir y excluir miembros de sus grupos, el GMP
permite incluir y excluirmiembrosdelGMS.Un particionado de la red
provocar un particionado no slo en el grupo decomponentes de una
aplicacin, sino tambin en el grupoqueimplementaelGMS.En caso de una
particin, ste reportar una nueva vista a los componentes en
laparticin; pero paralelamente la otra particin o particiones del
GMS podranreportar vistas complementarias a los otros componentes,
lo que supondra laexistencia de varios grupos aislados que
consideran que los dems han cado.
ElGMScontrolasupropialistademiembrosylaslistasdelosgruposasociados;siseparticiona,
tiene las siguientes opciones respecto a su propia lista de
miembros[Ricciardi93]:Norealizarningnprogreso.LoquesuponenopermitirquenuevosmiembrosseincluyanenelGMSoalgunodelosmiembrosactualesloabandone.Una
particin se considera primaria y puede seguir haciendo progresos.
Lasdems dejan de prestar servicio, debern incluirse de nuevo en el
GMS. Laparticin primaria puede determinarse de varias formas; por
ejemplo, pormayorademiembrosenelmomentodelaparticin.Varias
particiones pueden progresar, pudiendo dar vistas concurrentes
adiferentesmiembrosdelgrupo.SielGMSmismopuedeseguirhaciendoprogresoencasodeparticin,losdistintossubGMSsquesecreanpodranevolucionardetal
forma que, al recuperarse la particin, ninguno de los componentes
de unaparticin supiera de la existencia de los componentes de otra
particin. En esecaso no podran comunicarse, haciendo definitiva la
particin, por lo que
estasituacindebe,claramente,evitarse.Enunsistemanormaldesincronadevistas,elGMSpuedeirevolucionandoen
caso de particin, pero slo en una particin. La forma de asegurar
suconsistencia es precisando que una mayora de los componentes de
una vista delGMS aprueben la siguiente vista. sto significa que si
un sistema dinmico, porsucesivos fallos o particiones pierde ms de
la mitad de sus miembros, podraprogresar siempre que cada fallo no
implicara a la vezaunamayorademiembros.Por ejemplo, si hay diez
miembros, y una primera particin supone la cada
decuatromiembrosyunasegundaparticinlacadadedosmiembros,elGMSpodraen
cada paso asegurar una mayora para progresar. Los miembros del
grupo queSistemasdistribuidosfiables27soporte, como consecuencia,
siguen recibiendo vistas si se encuentran en
laparticinprimaria;sino,dejanderecibirvistasydeprestarningunafuncionalidad.La
particin primaria no tiene porqu estar definida en funcin de
unamayora de componentes. Esa mayora puede estar balanceada de tal
forma quedeterminados componentes tengan un mayor peso que otro,
con lo
quelaparticinprimariayanoseralaquehaquedadoconunmayornmerodecomponentes,sinoconunmayorpesodestos.Aunque
una aplicacin que pueda funcionar en modo particionado
presentaunamayordisponibilidad,sudiseoestambinmscomplicado.Adems,mientrasquelasincronadevistasesunmodelomuyelegante,dondeelGMSgestionatodoslos
cambios en las vistas, los sistemas llamados de sincrona de vistas
extendida(extended view synchrony) [Babaoglu96], soportando vistas
concurrentes, no lo sontanto y requieren la cooperacin de la
aplicacin. Por otro lado, cuanto mayor(geogrficamente) sea un
sistema, ms frecuentes y prolongadas podrn ser lasparticiones, lo
que puede implicar la necesidad de soportar particiones en
estossistemas.3.3.SincronavirtualApartirdelasprimitivasdecomunicacionesfiablesmultipuntoydelservicioGMS,
que hace a su vez uso de esas primitivas, es posible describir el
modelo desincrona virtual [Birman87], usado en todos los sistemas
distribuidos
asncronosactualesquesoportangruposdinmicosypropiedadesdeconsistencianotriviales.Este
modelo se basa en el siguiente principio: si todos los
miembrosprocesaran los mismos mensajes en el mismo orden (orden
total), no habraposibilidades de inconsistencia entre ellos. El
modelo de sincrona virtual se basaadems en la posibilidad de que,
aunque dos miembros procesen dos mensajes endistinto orden, el
resultado puede ser an el mismo: de esta forma, al
permitiremplearprimitivasdecomunicacionesmenosestrictasenelorden,comoordenfifoocausal,elrendimientoresultamayor.Elserviciodemiembrosdegruporequeridoporestemodelodebecumplirlassiguientespropiedades:Soportedinmicodegrupos:exclusineinclusindemiembrosdinmicamente.Envo
de vistas a los miembros del grupo, donde todos ven la misma
secuenciadevistas.Sincrona de vistas: dos miembros que sobreviven a
dos vistas consecutivasprocesan los mismos mensajes. Los sistemas
que soportan sincrona
extendidadevistasrelajanestapropiedad,puesmiembrosdevistasconcurrentesnoestnobligadosahaberprocesadolosmismosmensajes.Sistemasdistribuidosfiables
28Gap-freedom: si el grupo procesa un mensaje, que es sucesivo en
el ordenestablecido a otro mensaje dado, el grupo ha procesado
tambin este ltimomensaje.Adems, el modelo
precisadeprimitivasdecomunicacionesmultipunto,conuso preferente de
orden fifo y causal en las comunicaciones. Los algoritmos
decomunicaciones del grupo [Birman96] pueden desarrollarse basndose
encomunicaciones totalmente ordenadas, reemplazando
luegolascomunicacionesconprimitivas con menor orden, y pasando de
entornos dinmicamente uniformesanouniformes, mejorando notablemente
el rendimiento ofrecido. Adems, al emplearestas primitivas de
comunicaciones que no emplean orden total, los distintosmiembros
del grupo podrn procesar los mensajes en distinto orden, tolerando
aserroressoftware(Heisenbugs):sitodaslasrplicasprocesaranlosmismosmensajesenelmismoorden,yhubieraunerrorsoftware,todaslasrplicasfallaranporigual.Hay
estudios que prueban que la mayora de los
erroresenunsistemasonerroressoftware [Chou97], luego tolerar estos
errores resulta ser una consecuencia
muyinteresantedelempleodeprimitivasdecomunicacionessinordentotal.3.4.ObservabilidaddelgrupoLos
puntos anteriores han estudiado los mtodos para mantener
laconsistencia dentro del grupo, usando un servicio GMS y mediante
unascomunicaciones atmicas preservando el orden necesario. Sin
embargo, hay
otrascomunicacionesatenerencuenta,externasalgrupoyquenopuedendisearsedela
misma manera. Hay que
considerartambineltipodereplicacindelsistema:sitodaslasrplicastienenlamismafuncionalidadono.3.4.1.ComunicacionesexternasdelgrupoCuandouncomponenteindividualaccedealgrupo,tienevariasopciones:Accederaunmiembrodelgrupo,quepropagalaaccinarealizar[figura3.4].Siel
miembro se cae o es expulsado del grupo, el resultado es
indeterminado. Elmiembro al que se accede puede elegirse de tal
forma que la carga sobre
cadamiembroestbalanceada.Accederatodoslosmiembrosdelgrupo[figura3.5].Lacargadecomunicacioneses
mayor y el componente debe conocer la composicin exacta del grupo,
aunsiendodinmica.Semultiplicanaqulasopciones,puespuederesponderunslomiembro
o todos o un nmero determinado de ellos. Si el cliente no conoce
lacomposicin exacta, pueden originarse problemas al no acceder a
loscomponentesadecuados.Sistemasdistribuidosfiables29Adems, deben
contemplarse las opciones de orden de sus mensajes. En
elcasodeuncomponentequeaccedesncronamenteaungrupo,cuandostedevuelvela
respuesta, no es necesario que todo el grupo sea an participe de la
accinrealizada. Por consiguiente, si ese componente accede a otro
miembro del grupo,pueden crearse situaciones de inconsistencia al
no respetarse el orden de
losmensajes.Unasolucinposibleesnodevolverelresultadoalcomponentehastaquetodoelgrupoconozcalaaccin.Estascomunicacioneshaciaelgruponotienenporqupartirexclusivamentede
un componente individual, tambin pueden provenir de otro grupo, y
deberesolversesislounmiembrodelgrupoquesolicitaelservicioobientodoelgrupodeberecibirlarespuesta.Delamismamanera,siuncomponenteindividualaccedeaungrupo,debedecidirsesirecibirunanicarespuesta(accesotransparente)olarespuesta
de todos los miembros. En este ltimo caso, pueden fijarse
variasvariables,comoelnmeromnimoderespuestasarecibir,oelintervalomximodeesperadelasrespuestas.Existen
varias soluciones para el problema de orden de mensajes
entrediferentesgrupos:Noestablecerningnordenenlosmensajesentregrupos,loquepuederesultarperfectamenteadecuadosiestosgruposestnpocoacoplados.Establecer
un orden global en el sistema, de tal forma que todas
lascomunicacionespreservensucausalidad.Ademsdeserunasolucinmuycara,imponeuncostealascomunicacionesquenonecesitenpreservarningnorden.Figura
3.4.Propagacin de acciones enel
servidorUpdate:XUpdate:XUpdate:XUpdate:YUpdate:YUpdate:YSistemasdistribuidosfiables
30Cada grupo controla la causalidad de los mensajes que enva y
recibe; de
estamanera,noenviarningnmensajehastaquetodoelgrupoconozcaelmensajeentrante
que lo origin. No se respeta slo el orden de los mensajes
salientesrespectoalosentrantes,sinotambindelosinternos;siunmensajeseproducecomo
consecuencia de uno o ms mensajes internos, el mensaje slo
saldrcuandotodoelgrupoconozcatodossusmensajesprecedentescausalmente.Estemtodosedenominaconservativo[Birman96]ypermiteconservarelordendelosmensajesconcernientesaungrupo,peronopreservaelordenglobaldelsistema.Una
solucin similar a la anterior es el empleo de protocolos flush:
completartodas las comunicaciones internas del grupo antes de
enviar un determinadomensaje fuera del grupo. Es un caso concreto
de la anterior solucin, donde sedesea que slo algunos mensajes
respeten la causalidad, y en esos casos
serealizaunflushantesdeenviarelmensaje.Cuando varios grupos estn
fuertemente acoplados, otra solucin es crear unsupergrupo o dominio
que los incluya, permitindose entonces emplear
lasprimitivasdecomunicacionesdeungrupo:ordenfifo,causal,etc.3.4.2.ReplicacinAl
definir los grupos de objetos, se ha presupuesto que todos estaban
en elmismo nivel. Sin embargo, la replicacin puede realizarse de
varias maneras: todoslos miembros activos [Schneider93], un solo
miembro activo y los dems en pasivoFigura 3.5.Propagacin de
accionespor el
clienteUpdate:XUpdate:YUpdate:XUpdate:XUpdate:YUpdate:YSistemasdistribuidosfiables31[Budhiraja93],
o el estado intermedio, donde varios miembros estn activos y
losdemssonpasivos[figura3.6].Esta replicacin activa/pasiva puede
entenderse como dos grupos de
lasmismasrplicasdondeungrupo,elactivo,procesatodaslaspeticionesdeservicioyactualiza
peridicamente al segundo
grupo;uncomponentedelgrupopasivopuedeincluirseenelgrupoactivosiseproduceunfalloenste,abandonandoasuvezelgrupo
pasivo. ste es en un proceso monitorizado externamente, mediante
unsistemaqueobservalosfallosenlosgruposymuevemiembrosdeungrupoalotro.Relacionadoconelmodelodereplicacinestelconceptodebalanzadecarga,que
permite promediar la carga de servicio que cada componente del
grupo debesoportar. Este concepto se introdujo brevemente en el
apartado anterior al discutirlos mtodos con que un cliente puede
acceder al grupo. Si el grupo se
diseaparahacerbalanzadecarga,elclientepuedeelegirelmiembroalqueaccedeconfinadoentonces
en un acceso promediado- o el acceso puede realizarse sobre todos
loselementosdelgrupo,decidiendosteculdebeprocesarelservicio.Figura
3.6.Modelomixto de replicacinRplicasprimarias RplicassecundariasLas
rplicasprimariasestncontinuamentesincronizadas.Las secundarias se
actualizanperidicamenteSistemasdistribuidosfiables
32Sistemasdecomunicacionesengrupo33Captulo4-SISTEMASDECOMUNICACIONESENGRUPOLosanteriorescaptuloshanmostradolasopcionesdecomunicacionespuntoapuntodisponiblesactualmenteylasformasdecomunicacionesengruponecesariaspara
crear aplicaciones distribuidas fiables mediante la replicacin de
suscomponentes.Lossistemasdecomunicacionesengrupoexistentessebasanenelmodelodesincrona
virtual. Una de las propiedades que este modelo precisa [Birman96]
es elsoporte de la transferencia de estado, pero
lasaproximacionesempleadasparaestesoportevaranenormementeentrelosdistintossistemas.Latransferenciadeestadoes
uno de los objetivos cubiertos por Sensei, pero antes de presentar
el modelodesarrollado, es necesario mostrar los sistemas existentes
y su modelo
detransferenciadeestado.4.1.SistemasdecomunicacionesengrupoSobre el
modelo de sincrona virtual se han desarrollado varios sistemas
decomunicaciones de
grupos.Acontinuacinsemuestraunalistaconlosprincipalessistemas
(restringidos a interfaces Java, C y C++) que soportan
toleranciaafallosyexcluyendo sistemas comerciales de dominio
restringido. Dos sistemas se
hanpostergadoalasseccionesfinales,entrandoenmayordetalleensuimplementacin,Sistemasdecomunicacionesengrupo
34por su influencia en la especificacin y el desarrollo de Sensei:
Maestro
(sobreEnsemble)ylaespecificacindetoleranciaafallosdeCORBA.4.1.1.AmoebaAmoeba
[Amoeba] es un sistema operativo basado en microkernel
quetransforma un grupo de estaciones de trabajo en un sistema
distribuidotransparente [Tanembaum91]. La idea bsica es presentar
al usuario la ilusin deun nico y potente sistema que, sin embargo,
se implementa en un grupo deordenadores, potencialmente dispersos
en diversospases.Desarrolladoapartirde1981 en la Universidad Vrije
de Amsterdam, es un sistema de libre distribucin.Est implementado
en Orca, un lenguaje para programacin paralela en
sistemasdistribuidos.No obstante, Amoeba esun completo sistema
operativo (presentaincluso una librera de emulacin POSIX), no
simplementeun sistema
decomunicacionesdegrupo.Unaideasimilareslasoportadaporelserviciodeclustersde
Microsoft (MSCS) [Vogels98], pero en este caso la funcionalidad se
escribe
sobresuomnipresentesistemaoperativo.Sinembargo,MSCSslosoportainicialmenteunconjunto
limitado de aplicaciones (servidores de ficheros, de mail
electrnico,
depginasWebybasesdedatos)ynicamentesobredosnodos.4.1.2.ArjunaDesarrollado
desde 1987 en la Universidad de NewCastle upon Tyne, Arjuna[Arjuna]
se define como un sistema deprogramacinorientadoaobjetosquebuscala
simplificacin del proceso de desarrollo de aplicaciones
distribuidas fiables.Opera sobre el modelo cliente/servidor y puede
ejecutarse sobre entornosheterogneos, usando C++ como lenguaje de
programacin. La fiabilidad la obtienemediante transacciones atmicas
anidadas distribuidas. Es, por lo tanto, ms
bienunsistemadetransaccionesqueunsistemadecomunicacionesdegrupo.Dehecho,se
ha portado a CORBA, siendo
compatibleconelserviciodetransaccionesdeestaarquitectura.Enestesistema[Parrington95],elestadodelosobjetosesadministradoporunobjetodelaclaseStateManager.Losobjetosseclasificancomo:Recuperables:
el StateManager trata de generar y mantener toda la
informacinnecesariapararecuperarelestadodelobjetosistesecae.EstainformacinseguardaenobjetosdelaclaseObjectState.Recuperables
y persistentes: son obje