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