Programac‚aoŸ de Sistemas Distribu· dos Con av· eisalcides/Teaching/SistemasDistribuidos... ·...

Programacao de Sistemas Distribuıdos Confiaveis

Lau Cheuk Lung1 , Alysson Neves Bessani2∗, Joni da Silva Fraga2

1PPGIA - Programa de Pos-Graduacao em Informatica AplicadaPUC-PR - Pontifıcia Universidade Catolica do Parana

R. Imaculada Conceicao, 1155 - Prado velho - CEP 80215-901 - Curitiba

2DAS - Departamento de Automacao e SistemasUFSC - Universidade Federal de Santa Catarina

Campus Universitario, Caixa Postal 476 - CEP 88040-900 - Trindade - Florianopolis

[email protected], [email protected], [email protected]

Resumo

Um sistema computacional e confiavel se tem uma alta probabilidade de proceder suafuncao de acordo com sua especificacao. No desenvolvimento de aplicacoes em sis-temas distribuıdos sao usualmente utilizados tecnicas de tolerancia a faltas para alcancaresta propriedade. Conceitualmente, a tolerancia a faltas visa permitir que servicos(ex. cliente/servidor, webservices, objetos distribuıdos) sejam fornecidos continuamentemesmo em presenca de falhas parciais no sistema. Este minicurso apresentara conceitose tecnicas de tolerancia a faltas para serem aplicadas no desenvolvimento de sistemasdistribuıdos confiaveis. Em termo de tecnologia de desenvolvimento, e apresentado umbreve tutorial a respeito das principais especificacoes da OMG que visam introduzir oconceito de grupo de objetos na arquitetura CORBA.

1. IntroducaoUm sistema distribuıdo pode ser entendido como um ”conjunto de componentes de hard-ware e software, baseado numa rede de computadores, que se comunicam e coordenamsuas acoes apenas atraves de troca de mensagens” [Coulouris et al., 2001]. A separacaoespacial destes componentes que formam o sistema distribuıdo pode variar de uma redede computadores local (LAN - Local Area Network), ate a uma rede de longa distancia(WAN - Wide Area Network), largamente dispersa, tal como a internet. Os usuarios deum sistema distribuıdo tem acesso a varias maquinas, podem abrir sessoes nelas e trans-ferir dados entre elas. No entanto, os usuarios nao precisam saber da existencia dessasmaquinas, os recursos remotos sao usados transparentemente, da mesma maneira que osrecursos locais. Citando Leslie Lamport: ”Voce so sabe que tem um sistema distribuıdoquando a falha de um computador do qual voce nunca ouviu falar faz com que voce parecompletamente de trabalhar”.

A programacao de sistemas distribuıdos consiste no desenvolvimento de softwarepara produzir um aparato de computacao integrado, a ser executado em plataformas de

∗Bolsista CNPq.

hardware. No entanto, o desenvolvimento desses programas de computador nao e umatarefa trivial, pois envolve uma serie de problemas como coordenacao e sincronizacaoem sistemas distribuıdos, decorrentes da caracterıstica de concorrencia entre os com-ponentes distribuıdos e a necessidade de compartilhamento de recursos entre estes. Asolucao para esses problemas envolve algoritmos distribuıdos, tais como algoritmos decomunicacao confiavel, deteccao de deadlock, eleicao, sincronizacao de relogios, ex-clusao mutua, acordo e consendo distribuıdo, etc [Coulouris et al., 2001]. O foco destetexto e desenvolvimento de sistemas distribuıdos confiaveis, maiores detalhes sobre algo-ritmos distribuıdos podem ser encontrados em [Lynch, 1996, Coulouris et al., 2001].

Um sistema e confiavel (dependable) se tem uma alta probabilidade de procedersua funcao de acordo com sua especificacao. No desenvolvimento de aplicacoes dis-tribuıdas sao usualmente utilizados tecnicas de tolerancia a faltas para atender o requisitoda confiabilidade. Conceitualmente, a tolerancia a faltas visa permitir que servicos sejamoferecidos continuamente mesmo em presenca de falhas parciais no sistema. A formausual de implementar aplicacoes distribuıdas tolerantes a faltas e o uso de tecnicas dereplicacao que sao baseados na abstracao de grupo.

A introducao do paradigma de grupo em padroes abertos tem sido alvo devarios trabalhos de pesquisa [Maffeis, 1995, Felber et al., 1996, Moser et al., 2001] e pro-postas de padronizacao [Deering and Cheriton, 1985, Object Management Group, 2000,Object Management Group, 2001]. Prover suporte de grupo a aplicacoes distribuıdasenvolve uma combinacao de protocolos que tratam do gerenciamento de grupo (mem-bership, deteccao de falhas, transferencia de estado) e da comunicacao de grupo[Powel, 1996]. Muitas aplicacoes distribuıdas dependem de abstracoes como grupos deobjetos ou da necessidade da disseminacao de dados entre varios hosts da rede. Estasaplicacoes geralmente utilizam-se de um suporte de comunicacao de grupo que oferecaservicos de comunicacao multiponto com algumas propriedades como garantias de en-trega e ordenacao, bem como desempenho adequado.

Nos ultimos anos, o desenvolvimento de aplicacoes distribuıdas esta seguindo oparadigma de orientacao a objetos e considerando o CORBA (Common Object RequestBroker Architecture) [OMG96] como uma das melhores alternativas de se adequar aosrequisitos de sistemas abertos. Esta tendencia visa fazer frente as solucoes proprietariasque normalmente requerem custos mais elevados em desenvolvimento de sistemas. Sis-temas abertos abrangem um significante leque de tecnologias e especificacoes que, deforma diversa aos ambientes proprietarios, permitem solucoes mais adaptadas e flexıveisa complexidade e a heterogeneidade de sistemas distribuıdos. A arquitetura CORBA(Common Object Request Broker Architecture) [Object Management Group, 2002] intro-duzida pela OMG (Object Management Group), corresponde as mais bem sucedidas (einfluentes) especificacoes de middleware para suporte a sistemas de objetos distribuıdos.O principal componente desta arquitetura e o ORB (Object Request Broker) que entre out-ras funcionalidades implementa as semanticas de comunicacao definidas na arquitetura.As mensagens trocadas nas comunicacoes seguem uma sintaxe de transferencia propria:o General Inter-ORB Protocol (GIOP). Esta sintaxe torna as mensagens envolvidas nascomunicacoes independentes das implementacoes de ORBs e das consequencias de umambiente heterogeneo. O mapeamento do GIOP sobre o TCP/IP e concretizado atravesdo IIOP (Internet Inter-ORB Protocol).

Para dar suporte ao desenvolmento de aplicacoes distribuıdas confiaveis noCORBA, a OMG tem padronizado a especificacao FT-CORBA. Esta especificacao con-siste de um conjunto de servico que dao suporte ao desenvolvimento de aplicacoesCORBA tolerante a faltas.

Os objetivos deste mini-curso e introduzir o leitor aos conceitos basicos deseguranca de funcionamento (confiabilidade e tolerancia a faltas), juntamente com astecnicas de replicacao para tolerancia a faltas em sistemas distribuıdos. Para isso, saolevantados os principais conceitos e modelos de comunicacao de grupo, necessarios aimplementacao de tecnicas de replicacao. Por fim, apresentamos a tecnologia CORBAdando enfase as especificacao FT-CORBA que dao suporte ao desenvolvimento deaplicacoes confiaveis (tolerantes a faltas) baseado no modelo de objeto CORBA.

O texto esta organizado da seguinte forma: a secao 2 apresenta alguns conceitosde tolerancia a faltas e a secao 3 apresenta uma revisao sobre conceitos e modelos decomunicacao de grupo em sistemas distribuıdos. Tecnicas de replicacao para tolerancia afaltas sao apresentados na secao 4. Na secao 5 sao apresentados os padroes FT-CORBAe UMIOP. Por fim, na secao 6, sao apresentadas as consideracoes finais deste capıtulo.

2. Conceitos de Seguranca de Funcionamento

A seguranca de funcionamento e a qualidade do servico fornecido de modo que os seususuarios possam depositar no mesmo uma confianca justificada. Um sistema e confiavel(dependable) se tem uma alta probabilidade de proceder sua funcao de acordo com suaespecificacao. A completa especificacao de um sistema nao deve ser limitada para o queo sistema faz, mas deve tambem especificar as condicoes ambientais requeridas para queo sistema forneca o servico requerido. Por exemplo, a especificacao de uma televisao naodeve ser limitada apenas a descricao de suas funcionalidades, mas tambem as condicoesnecessarias para o seu correto funcionamento (ex. temperatura, voltagem, umidade, etc).

Um sistema computacional tolerante a faltas e aquele que pelo uso de re-dundancias mantem o servico correto (funcionando de acordo com o especificado) mesmoem presenca de componentes faltosos. Redundancias sao partes do sistema que nao se-riam necessarias para o funcionamento do sistema se nao ocorressem faltas no sistema.A redundancia pode ser de hardware (replicacao de componentes fısicos), de software(replicacao de processo, diversidade de projeto) e temporal (re-execucao de procedi-mento). O uso de redundancia (ou replicacao) e requerido principalmente em sistemasdistribuıdos que tenham como requisito alta disponibilidade.

Quando o procedimento do sistema viola sua especificacao dizemos que ele fal-hou, mas o que leva um sistema a falha ? As falhas podem ter causas internas ou externas,chamada de falta. A falta pode permanecer adormecida (inativa) por um momento, ateser ativada. Por exemplo, um bug em um programa de computador pode permanecer des-percebido ate ser eventualmente ativado pelo usuario. Esse bug e um erro de programacaoque pode levar o programa a um estado falho (ex. travamento do programa). Frequente-mente se ouve no noticiario sobre falhas de seguranca de sistemas computacionais. Essasfalhas sao resultados de erros de programacao devido, por exemplo, a falta de atencaodo desenvolvedor do sistema. A falta pode ser acidental (ex. um erro no codigo quepassou despercebido) ou intencional (ex. um erro adicionado no codigo para possibilitar

a venda de futuras atualizacoes do programa). Portanto, a falta e a causa, no sentidofenomelogico, de um erro. Um erro e a parte do estado do sistema (estado erroneo) quepode conduzir a uma falha no sistema. Por fim, a falha de um sistema ocorre quando oservico fornecido desvia do servico especificado. A falha e o efeito observado externa-mente do erro.

Uma falha pode ser resultante de erros distintos. Por exemplo, um ruıdo sonorono alto-falante pode ter sido causado por um defeito na placa de som ou um erro no pro-grama que decodifica arquivos de musica mp3 (player). Da mesma forma, erros podemser causados por diferentes faltas. O erro do player pode ser causado por um bug no pro-grama (ex. no algoritmo de decodificacao) ou por uma sobrecarga de processamento doprocessador, provocando um travamento momentaneo.

Portanto, quando um sistema falha dificilmente e causada pela falencia multiplados seus componentes, normalmente e provocada por um componente faltoso que foi maltestado. Se este mesmo componente fosse replicado (redundancia) esse sistema seria,desta forma, tolerante a faltas.

Mas por que ’Tolerancia a Faltas’ e nao ’Tolerancia a Falhas’ ? Se o leitor chegouate aqui e ainda nao conseguiu entender essa diferenca e a relacao entre falta, erro efalha, vamos explicar novamente usando como cenario um jogo de futebol. Pense numjogador de futebol, o Ronaldinho por exemplo, a especificacao do Ronaldinho e fazer gol,portanto, se ele deixa de fazer o gol ele falha na sua especificacao. Imagine o Ronaldinhoindo em direcao ao gol adversario e surja um zagueiro que comete uma falta nele, essafalta vai fazer com que o Ronaldinho cometa um erro e, como consequencia, falhe noseu objetivo (sua especificacao) em fazer o gol. Neste exemplo, o Ronaldinho e o nossosistema, se for robusto o suficiente ele e capaz de tolerar faltas dos zagueiros adversariose fazer o gol – assumindo que o juiz deixara o Ronaldinho seguir seu rumo por causada ’lei da vantagem’. O erro e provocado por faltas que podem ter origens internas ouexternas, neste exemplo, a causa foi externa (a falta cometida pelo zagueiro). Um exemplode falta com origem interna seria o Ronaldinho sofrer uma convulsao (uh!) durante a suatragetoria em direcao ao gol. Portanto, nao tem como o Ronaldinho tolerar falha – talveza torcida e/ou os dirigentes consigam ;-).

2.1. Classificacao de Faltas e Semantica de Falhas

A classificacao de faltas e o conhecimento de sua natureza sao de grande importancia noprojeto de sistemas capazes de tolerar faltas. As faltas podem ser classificadas quantoa origem (humanas/projeto), persistencia (transitorias/intermitentes/permanentes) e se-gundo a otica de seus efeitos, fortemente vinculados com as semanticas de falhas. Para adefinicao de um servico correto, considere que os itens de servico si (i = 1, 2, 3,..., n) saocaracterizados pelos pares 〈vsi, tsi〉 com vsi sendo o valor de servico si e tsi o tempo ouinstante de observacao do mesmo pelo usuario. Deste modo, por definicao, um servico si

e definido como correto se e somente se:

(vsi ∈ VSi) ∧ (tsi ∈ TSi)

onde:

• VSi e o conjunto especificado de valores para o item si;• TSi e o conjunto especificado de tempos para o item si;

Portanto, um servico e nao correto quando viola a propriedade acima, erros provo-cados por faltas no domınio de valor VSi e/ou no domınio do tempo TSi. As faltas nodomınio de valores (onde VS= VS1 ∪ VS2 ∪ ... ∪ VSi ∪ ... ) podem ser: erro de valorfora do codigo ((vsi /∈ VSi) ∧ (vsi /∈ VS)); ou erro de valor no codigo ((vsi /∈ VSi) ∧ (vsi

∈ VS)), tambem conhecido como falta maliciosa (ou intencional). Erro de valor fora docodigo e o caso em que a resposta de um servico esta fora do especificado e tambem forade qualquer valor possıvel. Por exemplo, solicitar a soma de dois numeros inteiros a umacalculadora e retornar como resultado uma letra do alfabeto. Ja no caso de erro de valorno codigo, a resposta esta fora do especificado mas dentro dos valores possıveis, por ex-emplo, a soma de dois mais dois retornar cinco – e um valor possıvel, mas nao de acordocom a especificacao.

Ja as faltas no domınio do tempo podem ser por temporizacao, omissao ou parada.Faltas de temporizacao (Timing Faults) podem provocar erro por antecipacao (tsi < Tsi),quando o servico responde antes do especificado, ou por atraso (tsi > Tsi), quando ocorredepois do especificado. Um alarme/acao programado para ser ativado em um horario es-pecifico mas que ocorre em um tempo anterior ou posterior ao especificado e um exemplodeste tipo de falta. A falta por omissao e um caso particular da falta de temporizacao(por atraso). A omissao e um tipo de falta em que o item de servico nunca tem o seuvalor liberado, isto e, tsi →∞. Neste caso, o servico omite algumas respostas e respondeoutras. Entretanto, os servicos podem ter semantica de omissao incorporadas, um servicode grau de omissao k permite no seu comportamento a omissao consecutiva de k itensde servico. Atingido este valor temos, entao, uma parada no servico. Desta forma, faltade parada e um caso particular da falta de omissao. Faltas de parada (ou crash) ocorrequando apos a primeira omissao o servidor deixa de responder sistematicamente a todasas outras requisicoes – correspondendo a um crash no servico.

Mas como e classificado quando a falta no sistema envolve erros tanto no domıniode valor como no domınio do tempo ? Neste caso, esta falta e classificada como arbitraria,isto e:

(vsi /∈ VSi) ∨ (tsi /∈ TSi)

Dentro da classificacao da falta arbitraria estao as faltas maliciosas ou inten-cionais. Estes geram itens de servicos si com valores fora do conjunto especificado VSi,mas dentro dos valores possıveis, e tempo de resposta em instantes aleatorios. Erros de-terminam valores vsi fora de VSi, com dados mantendo alguma propriedade a confundiro cliente do servico com valores pertencendo a VS, isto e:

(vsi /∈ VSi) ∧ (vsi ∈ VS) ∧ (tsi ∈ TSi)

Pela classificacao de faltas apresentada (ver figura 1) conclui-se que quanto maisrestritiva o modelo de faltas assumido menor a complexidade do algoritmo distribuıdoconsiderado para tolera-lo, e vice-versa.

3. Tecnicas de Tolerancia a Faltas

A funcao da tolerancia a faltas e mascarar as faltas parciais no sistema, mantendo o seucorreto funcionamento. Existe diversas tecnicas de tolerancia a faltas que podem tolerar

Faltas arbitrárias

Faltas de valor

Faltas de temporização

Faltas de omissão

Faltas de parada

Figura 1: Classificacao das faltas.

faltas no domınio de valor e de tempo. As fases no projeto de sistemas tolerante a faltassao: deteccao de erros, confinamento de erros, recuperacao de erros e tratamento defaltas.

A deteccao de erros e a fase onde a presenca de elementos faltosos e deduzidapela constatacao de um erro. Sao meios que possibilitam a prevencao de uma falha. Osmetodos utilizados para deteccao de erros no sistema sao a realizacao de testes comple-tos, testes de aceitacao, testes independentes, internos, etc. A segunda fase, consiste noconfinamento do erro, se um erro ocorrer que seja limitado, evitando que se propague emtodo sistema. O confinamento de erro e feito atraves de tecnicas e mecanismos, em tempode projeto, que implementam barreiras incorporadas ao sistema. O erro se propaga pelainteracao dos componentes de um sistema. Essas barreiras delimitam os eventuais danosa um sistema devido a propagacao de erros. Um nobreak ligado ao computador central eum exemplo de barreira que pode confinar um erro causado pela falta de energia eletrica.

Recuperacao de erros, a terceira fase de projeto, consiste na implementacao demecanismos que permitam ao sistema, na ocorrencia de um erro, se restaurar para umestado correto (rollback). Duas tecnicas sao utilizadas para recuperacao de erros:

• Processamento de erro, que pode ser por:– Recuperacao em retrocesso (Backward recovery): coloca o sistema em um

estado correto anterior. A partir deste estado recomeca o processamento;– Recuperacao em avanco (Forward recovery): usando o estado erroneo,

coloca o sistema em um estado correto a frente. E importante emaplicacoes tempo-real (tal como um sistema de controle embarcado de umaeroplano).

• Mascaramento de erros: uso de replicas ativas para que um componente faltososeja mascarado em seu comportamento.

Por fim, o tratamento de faltas que consiste na configuracao dinamica ou estaticapara remover elementos faltosos do sistema. A configuracao dinamica pode ser imple-mentada usando replicacao passiva (figura 2). Nesta tecnica, os componentes de hardwaredo sistema sao replicados. Quando o componente principal e detectado como faltoso (M1

da figura 2), atraves de um detector de erros, o sistema automaticamente chaveia para umsecundario (M2), de mesma caracteristica.

M2

Detecção de erros

Saída

Chave

Entrada

M1

Figura 2: Replicacao passiva de componente - configuracao dinamica.

Para a configuracao estatica, e utilizada a tecnica de replicacao ativa de compo-nente, que nao necessita de um detector de erros. Neste caso, todos os componentes saoativos (M1, M2, M3 da figura 3), pois recebem as mesmas entradas e sao supostos forneceras mesmas saıdas, em situacao livre de erros. O votador, neste caso, coleta todas as re-spostas, compara-as e fornece como saıda aquela que tiver maior ocorrencia (ou a quetiver a maioria).

Saída

M3

Entrada M2

M1

Votador

Figura 3: Replicacao ativa de componente - configuracao estatica.

O tratamento de faltas para componentes de software funciona de maneira sim-ilar ao tratamento dado aos componentes de hardware. Para componentes de software,e introduzido o conceito de diversidade de projeto. A diversidade de projeto consisteno princıpio de implementar uma mesma especificacao (de algoritmo ou sistema) deforma diversificada, gerando, desta forma, diferentes versoes de implementacao. Naimplementacao do componentes de software, pode ser considerado o uso de diferentes lin-guagens de programacao, para cada versao; o uso de diferentes compiladores e ambientesde suporte; diferentes algoritmos, se possıvel; e diferentes equipes de desenvolvimento.

Existem duas abordagens no tratamento de faltas para componentes de software:programacao N-versoes e bloco de recuperacao. Na primeira, a ideia e a mesma dareplicacao ativa de componente de hardware (figura 3), so que neste caso cada replica docomponente de software e implementado baseado no princıpio da diversidade de projeto.Na abordagem de programacao bloco de recuperacao (figura 4), o programa e divididoem blocos com pontos de recuperacao em caso de ocorrencia de erro, detectado pelo testede aceitacao (TA) que verifica os resultados fornecidos. A recuperacao em retrocesso fazcom que o sistema retorne a um estado seguro.

2

3

Ponto de Recuperação

1 TAEntrada Saída

Figura 4: Programacao bloco de recuperacao.

4. Suporte de Comunicacao de Grupo

Um grupo e uma colecao de processos (ou objetos) que sao associados a nıvel de aplicacaopor alguma propriedade ou interesse comum. Um sistema distribuıdo pode ter variosgrupos sobrepostos ou nao, seguindo as funcionalidades do sistema e suportados por umservico de comunicacao e gestao de grupo. Um suporte de comunicacao de grupo ea funcionalidade no sistema distribuıdo reponsavel pelo gerenciamento e comunicacaoentre os membros desse grupo.

Para que o suporte de comunicacao de grupo (SCG) possa garantir as propriedadesexigidas pelas primitivas de comunicacao de grupo oferecidas, ele deve fornecer umavisao consistente do grupo. Um problema fundamental relacionado a sistemas dis-tribuıdos, em especial em suportes de comunicacao de grupo, diz respeito a determinacao,em tempo de execucao, de quais processos sao membros de um grupo. Esta lista de mem-bros pertencentes ao grupo e o que chamamos comumente de membership (pertinencia)ou visao. O membership de um grupo pode ser estatico ou dinamico. Em um membershipestatico os membros do grupo sao conhecidos previamente, em tempo de compilacao.Em memberships dinamicos, processos entram e saem de grupos, o que, representa umapertinencia que evolui, possuindo um numero de membros variavel em funcao do tempo.

Os SCG trabalham normalmente com membership dinamico por questoes de flex-ibilidade. O conjunto de membros de um grupo pode mudar por pelo menos tres razoes:

• Requisitos da Aplicacao: Algum requisito funcional da aplicacao atuando sobreo SCG deve implicar nas alteracoes de membership. Por exemplo, em uma vıdeo-conferencia, algumas pessoas podem entrar na sessao (grupo) apos o inıcio desta,e ainda algumas podem deixa-la antes de seu fim;

• Falhas de Processos: Processo falhos devem ser removidos de grupos;• Redimensionamento do Sistema: Grupos podem crescer ou diminuir segundo

demandas. As vezes a demanda pelo sistema cresce ou diminui tanto que umredimensionamento de seus recursos se faz necessario.

Nem todo SCG tem acesso e/ou fornece o membership dos grupos por ele geren-ciado, alguns suportes funcionam sem este tipo de informacao. Quando o membership edisponibilizado pelo SCG, esta lista de membros do grupo e tornada disponıvel atravesdo servico de membership do grupo (SMG).

Em membership dinamico as alteracoes no grupo sao controladas pelo SMG, queprocessa as mudancas e altera a lista de membros do grupo, atraves de operacoes ofereci-das aos processos, como por exemplo join e leave.

Num ambiente livre de falhas de processos as operacoes citadas seriam suficientespara que o SMG tivesse uma visao correta do grupo, entretanto nem sempre esse e o caso,e na maior parte dos sistemas reais, as falhas nao podem ser desconsideradas. Assim,cabe ao SMG, atraves de algum mecanismo de deteccao de falhas, descobrir os processosfaltosos de modo a excluı-los da lista de pertinencia, mantendo assim um membershipconsistente e um por conseguinte um gerenciamento de grupo eficiente. Existe uma vastaliteratura sobre detectores de falhas, tanto do ponto de vista teorico quanto do pratico,para uma introducao ao tema veja [Chandra and Toueg, 1996].

4.1. Primitivas de Comunicacao de Grupo

A comunicacao de grupo tem se mostrado um paradigma necessario em sistemas dis-tribuıdos. Suportes de comunicacao de grupo disponibilizam varias primitivas decomunicacao com diferentes garantias de confiabilidade e ordenacao, atendendo difer-entes requisitos de aplicacoes. Estas garantias sao definidas atraves das propriedadesimplementadas pelos servicos que oferecem estas primitivas no suporte.

Em um sistema distribuıdo onde os processos se comunicam por difusao (sele-tiva ou nao), a presenca de faltas (tanto nas comunicacoes quanto nos processos) podeocasionar perdas de mensagens, que levam a inconsistencias nos estados dos membrosdos grupos. Assim sendo, as primitivas utilizadas para comunicacao devem oferecer pelomenos confiabilidade (que sera definida mais adiante) e um nıvel de garantia em relacaoa ordenacao das mensagens.

Nesta secao sao apresentados os 4 tipos basicos de primitivas de difusao comgarantias conforme definido em [Hadzilacos and Toueg, 1994], onde uma enfase especialsera dada a difusao confiavel.

4.1.1. Difusao Confiavel

O primeiro servico de difusao a ser apresentado e o de difusao seletiva confiavel1(ReliableMulticast). De maneira simples, um servico de difusao confiavel garante que todas asmensagens enviadas a um grupo de processos serao recebidas por todos os membros naofaltosos do grupo.

A difusao confiavel e implementada atraves de duas primitivas[Hadzilacos and Toueg, 1994]:

• R-multicast(G,m): A mensagem m e difundida para todos os processos perten-centes ao grupo G.

• R-deliver(m): A mensagem m e liberada para a aplicacao.

Estas primitivas devem satisfazer as seguintes propriedades:

1. Validade: Se um processo correto difundiu m em G, entao algum processo corretopertencente a G entregara m ou nenhum processo do grupo esta correto;

2. Acordo: Se um processo correto pertencente a G entrega a mensagem m, entaotodos os processo corretos pertencentes a G entregarao m;

1que chamaremos neste texto simplesmente de difusao confiavel.

3. Integridade: Para qualquer mensagem m, cada processo correto pertencente a Gentrega m no maximo uma vez e apenas se m foi previamente difundida em G.

Qualquer protocolo de difusao confiavel, no sentido determinista da palavra, deveprover estas duas primitivas e satisfazer essas tres propriedades.

4.1.2. Difusao FIFO

A difusao seletiva FIFO (First-In-First-Out) nada mais e que uma difusao confiavel coma propriedade de ordenacao FIFO [Hadzilacos and Toueg, 1994]:

• Ordenacao FIFO Local: Se um processo difunde uma mensagem m em G antesde difundir m′ em G, entao todos os processos corretos em G nao entregam m′

antes de entregar m.

A ordenacao FIFO garante que as mensagens difundidas por um processo seraoentregues pelos receptores na mesma ordem em que foram realizadas. A implementacaodessa primitiva e feita atraves de um numero de sequencia, inserida no cabecalho damensagem, indicando a ordem de entrega de cada mensagem.

4.1.3. Difusao Causal

A ordenacao FIFO e adequada apenas quando o contexto de uma mensagem m consisteapenas de mensagens difundidas pelo mesmo emissor. Entretanto, se o contexto de mdepende tambem das mensagens entregues pelo seu emissor entao a ordenacao FIFO naoe mais suficiente. Nestes casos, faz-se necessario um tipo de ordenacao que leve emconsideracao a precedencia causal de eventos2 [Lamport, 1978]. Dizemos que o evento eprecede causalmente o evento f (denotado e → f ) se e somente se:

1. o mesmo processo executa e e depois executa f , ou;2. e e a difusao de uma mensagem e f e a entrega desta mensagem, ou;3. existe um evento h, tal que e → h e h → f .

A ordenacao causal reforca a ordenacao FIFO generalizando a nocao de de-pendencia entre mensagens e garantindo que uma mensagem so sera entregue a aplicacaose a mensagem que a causou tiver sido entregue antes. Formalmente, uma difusao causale caracterizada por uma difusao confiavel que satisfaz a propriedade de ordenacao causal,de acordo com as seguintes propriedades de ordenacao:

• Ordenacao Causal Local: Se a difusao de uma mensagem m em G precedecausalmente a difusao de uma mensagem m′ em G, entao nenhum processo cor-reto em G entrega m′ antes de entregar m.

Esta primitiva pode ser implementada atraves de um vetor historico indicando asmensagens que precedem (causaram) a mensagem presente. Esse historico e inserido nocabecalho da mensagem enviada. O receptor ao receber essa mensagem so entrega-a paraa aplicacao se tiver entregado todas as mensagens precedentes indicadas no vetor.

2Os eventos considerados em sistemas distribuıdos sao os passos de processamento e as ativacoes deprimitivas de comunicacao.

4.1.4. Difusao Atomica

Se a difusao de duas mensagens nao esta causalmente relacionada, a difusao causal naoimpoem nenhum tipo de restricao quanto a ordem de entrega das mensagens e permiteinclusive que elas sejam entregues em ordens diferentes em diferentes processos. Paraalgumas aplicacoes este comportamento e inaceitavel, principalmente devido a possıveisinconsistencias que ele pode levar.

Para evitar esse tipo de problema, a difusao atomica garante que todos os pro-cessos corretos entregarao todas as mensagens e na mesma ordem. Desta forma, todosos processos tem a mesma visao [Birman, 1996] do sistema e podem agir de maneiraconsistente sem comunicacoes adicionais.

Formalmente, uma difusao atomica e uma difusao confiavel que satisfaz a seguintepropriedade:

• Ordenacao Total Local: Se dois processos corretos p e q entregam as mensagensm e m′ enderecadas ao grupo G, entao p entrega m antes de m′ se e somente se qentregar m antes de m′.

A difusao atomica e considerada um mecanismo fundamental para aimplementacao de replicacao ativa (ou por maquina de estados) para tolerancia a fal-tas [Schneider, 1990]. Existem diversas formas de implementar a difusao atomica[Defago et al., 2002]:

• Hitorico de Comunicacao: Essa abordagem e baseada no algoritmo de ordenacaode eventos de Lamport [Lamport, 1978]. O algoritmos baseados em historico decomunicacao entregam as mensagens em uma ordem total que e compatıvel coma relacao de precedencia das mensagens;

• Baseado em privilegio: Nesta abordagem se assume a existencia de um grupo deemissores formando um anel vitual em que um bastao (token) circula dentro dogrupo. Apenas o processo emissor de posse do bastao tem o privilegio de enviarmensagens ao grupo. Uma vez que cada processo receptor conhece a sequencia deemissores no anel logico, os receptores do grupo podem, desta forma, estabeleceruma ordem total determinıstica para as mensagens enviadas ao grupo (figure 5).

Grupo Receptor

Grupo Emissor

�

Figura 5: Difusao atomica baseado privilegio.

• Sequenciador fixo: Nesta abordagem se assume a existencia de um processosequenciador que recebe todas as mensagens do grupo emissor e as redireciona aogrupo receptor em uma ordem especifica (figure 6).

Grupo Receptor

Grupo Emissor

��

��

��

Figura 6: Difusao atomica sequenciador fixo.

• Sequenciador movel: Para tolerar a falta do sequenciador fixo e proposta entao,a abordagem do sequenciador movel. Nesta abordagem e definido de um grupode processos sequenciadores, formando um anel logico, que recebe todas as men-sagens do grupo emissor. Mas, apenas um processo sequenciador, possuidor dobastao, tem o privilegio de repassar as mensagens ao grupo receptor, em umaordem especifica. Como cada processo receptor conhece a ordem de sequenci-adores no anel logico, os receptores do grupo conseguem estabelecer uma ordemtotal (figure 7).

Grupo Receptor

Grupo Emissor

Grupo Seqüenciador

Figura 7: Difusao atomica sequenciador movel.

• Acordo no destino: Neste caso, a mensagem de um emissor e enviada para todosos membros do grupo receptor. No entanto, para definir a ordem de entrega dessamensagem, cada receptor participa de um protocolo de acordo (ou consenso dis-tribuıdo) no sentido de definir a ordem total que essa mensagem deve ser entregue(figure 8).

Grupo Emissor

�

Grupo Receptor

Figura 8: Difusao atomica sequenciador movel.

4.1.5. Combinando e Reforcando as Primitivas de Difusao

As primitivas de comunicacao apresentadas podem ser combinadas conforme apresentadona figura 9. Para se obter a difusao atomica FIFO, e necessario agregar a primitiva dedifusao atomica a ordenacao FIFO. Para difusao atomica causal, portanto, e necessarioagregar ao protocolo a ordenacao causal.

Total

Total

Total

Causal Causal

FIFO FIFO

Confiavel

FIFO

Causal

Difusao Difusao

Difusao Difusao

DifusaoDifusaoAtomica

Atomica FIFO

Atomica Causal

Figura 9: Relacionamento entre as primitivas de difusao.

Alem disso, quando trabalhamos no contexto de difusao seletiva (multicast), pode-mos reforcar as propriedades de ordenacao aumentando seu escopo para global, fazendocom que elas sejam validas tambem para comunicacao intergrupos.

Todas as propriedades requeridas pelos tipos de difusao apresentadas ate agoranada dizem a respeito do comportamento de processos faltosos que eventualmente fazemparte dos grupos, em especial, estamos interessados em quando um processo faltoso faza entrega de uma mensagem. Desta forma e possıvel fortalecer as propriedades apresen-tadas ate aqui de tal forma a considerar a presenca de processos faltosos no grupo.

Como exemplo, apresentamos o fortalecimento das propriedades de acordo e in-

tegridade das difusoes para o tratamento de processos faltosos:

1. Acordo Uniforme: Se um processo (correto ou faltoso) pertencente a G entregaa mensagem m, entao todos os processo corretos pertencentes a G entregarao m;

2. Integridade Uniforme: Para qualquer mensagem m, cada processo (correto oufaltoso) pertencente a G entrega m no maximo uma vez e apenas se m foi previa-mente difundida em G.

O uso de propriedades uniformes evita que processos faltosos originem incon-sistencias em grupos de processos. No entanto, essas propriedades so sao validas parafaltas nao bizantinas (maliciosas).

Alem dessas propriedades, e possıvel tambem fortalecer com a uniformidadeas propriedades de ordenacao e temporizacao. Para um tratamento completo ver[Hadzilacos and Toueg, 1994].

5. Tecnicas de Replicacao para Tolerancia a Faltas em Sistemas Distribuıdos

E de consenso geral que a utilizacao de tecnicas de replicacao em sistemas distribuıdoscontribuem fortemente para uma melhora na confiabilidade, um aumento da disponi-bilidade de recursos e possivelmente, um melhor desempenho do sistema. O uso dereplicacao torna possıvel implementar servicos tolerantes a faltas atraves da nocao decomponente/servico abstrato para o usuario (exibe a propriedade de um componenteunico, mas que na realidade e formado por um conjunto de componentes replicados). Afalha de uma replica individual passa a ser considerada separadamente da falha do grupocomo um todo, logo a confiabilidade do servico passa entao a depender da confiabilidadedo grupo que oferece este servico. Um protocolo de coordenacao e necessario para as-segurar a consistencia de estado e a transparencia do conjunto. Estes protocolos devemtambem ser responsaveis pelo controle da concorrencia e pela recuperacao em situacaode falha parcial ou total das replicas.

As abordagens chamadas replicacao passivas, replicacao ativas e replicacaosemi-ativas sao capazes de mascarar falhas individuais de replicas membros do conjunto.Contudo, a forma como isto e feito difere fortemente. Na escolha de uma dessas aborda-gens devem ser considerados: o tipo de aplicacao, a classe de falta que se deseja tolerar eas caracterısticas do sistema distribuıdo.

5.1. A abordagem de replicacao passiva

Nesta abordagem, somente um membro (primario) recebe, executa e responde asinvocacoes dos clientes. As replicas restantes do conjunto (backups) tem a funcao desubstituir o membro primario caso este falhe. O cliente faz as requisicoes sem saber quale o primario da replicacao. Para assegurar que os estados dos membros se mantenhammutuamente consistentes, o primario envia periodicamente mensagens de checkpoint deseu estado para todos ou um numero suficiente de backups (figura 10). Em situacao defalha do primario e ativado um protocolo de eleicao que seleciona entre os backups onovo primario, que reassume a execucao da operacao a partir do ultimo checkpoint maisrecente. E importante ressaltar que nenhuma invocacao e processada ate que o novoprimario seja eleito.

cliente

grupo servidor

checkpoints

Figura 10: Tecnica de replicacao passiva.

A grande vantagem desta abordagem e exatamente a nao necessidade do determin-ismo de replicas, uma vez que o primario impoe seu estado sobre as replicas backups. De-vido ao fato do cliente comunicar-se somente com o primario, a interacao cliente/servidore simplificada. Uma situacao que deve ser considerada e quanto a atualizacao dos back-ups. Se um backup nao recebeu uma mensagem de checkpoint por um motivo qualquer,ele deve ser manipulado de forma que nao possa ser eleito como o novo primario, ate queseu estado seja atualizado. Isto pode ser feito atraves de um protocolo que reconheca umbackup desatualizado e realize uma acao de atualizacao de seu estado para que esse possaser potencialmente elegıvel.

A deteccao de falha do primario e um outro fator que deve ser considerado. Nestaabordagem so e possıvel detectar falhas de crash, de omissao e alguns tipos de faltas detemporizacao (secao 2.). Para esses casos, podem ser utilizados mecanismos de timeout ekeepalive. A deteccao pode ser realizada pelos backups, por um mecanismo independenteou pelo proprio usuario do servico replicado. A frequencia com que e ativado o mecan-ismo de keepalive determina a rapidez da recuperacao no erro do primario, mas se estafrequencia for muito elevada pode influenciar no desempenho do servidor. Uma situacaoque pode ocorrer e o primario falhar logo apos completar a execucao de uma requisicaoe enviar o checkpoint aos backups sem, no entanto, responder ao cliente. Neste caso ocliente pode reenviar a mesma requisicao. Mas para evitar que o novo primario processe-a novamente e necessario, atraves de um mecanismo de retencao de resultado, que elereconheca a repeticao da requisicao e simplesmente retransmita o resultado retido.

........

........

........

........

........ x

checkpoint

requisições

Figura 11: Mecanismo de checkpoint.

O numero de backups (ou grau de replicacao) que recebem as mensagens de check-point do primario depende da aplicacao e do sistema distribuıdo. Se o sistema e especi-ficado para tolerar f nos faltosos, entao e necessario que o checkpoint chegue em pelo

menos f replicas. As falhas dos backups nao tem nenhuma influencia sobre o sistema ateatingir f replicas, uma vez que ate este valor e possıvel mascara-las. A frequencia dasoperacoes de checkpoint pode diminuir o desempenho do servico replicado. E possıvel,no entanto, diminuir a taxa de envio de checkpoint, por exemplo, a cada x requisicoes(figura 11). Esta solucao e vantajosa em casos onde a ocorrencia de falha do primario naofor frequente. Nesta situacao, quando o primario falha, o cliente tera que retransmitir asrequisicoes a partir do ultimo checkpoint, e, portanto podera ter que reavaliar as respostasdo novo primario para que nao ocorram repeticoes.

Cliente

Grupo servidor

Checkpoint

log

Figura 12: Tecnica de replicacao passiva com log.

Para evitar que o cliente tenha que retransmitir requisicoes em situacao de falha doprimario pode ser utilizado um mecanismo de log que armazene em disco as mensagensde requisicoes entre os intervalos de checkpoint (figura 12).

5.2. A abordagem de replicacao ativa

Nesta abordagem (tambem conhecida como Maquina de Estado) todas as replicas naofaltosas do grupo sao ativas: recebem, executam e respondem a todas requisicoes dosclientes (figura 13). Com relacao a abordagem de replicacao passiva, o custo e maior, poisexige mais recursos do sistema (memoria, processador etc.) e o fluxo de mensagens nomeio de comunicacao e mais elevado. Por ter todas as replicas ativas executando o mesmoconjunto de requisicoes e necessario que o conjunto de replicas seja determinista, casocontrario podem surgir possıveis inconsistencias de estado entre as replicas. Alem disso,alguma forma de entrega de resultados ao clientes tem que ser definida: (i) o primeiroresultado a chegar e passado ao cliente; (ii) os resultados sao concatenados em sequenciae enviados ao cliente; ou ainda, (iii) os resultados passam por um votador ou ajustadorque seleciona o resultado mais frequente (maioria) para ser passado ao cliente.

Esta abordagem e mais apropriada em aplicacoes que requerem servicos inin-terruptos com sobrecarga mınima em situacoes de falha (por exemplo, em aplicacoestempo real), pois as falhas sao mascaradas quase que instantaneamente. O determinismode replicas nos modelos de replicas ativas e conseguido assegurando as seguintes pro-priedades:

• Acordo: garante que ou todas replicas nao faltosas de um grupo recebem a mesmamensagem (requisicoes) ou todas desconsiderem esta mensagem;

• Ordenacao: as replicas nao faltosas recebem as requisicoes na mesma ordem rel-ativa;

Cliente

Grupo servidor

Figura 13: Tecnica de replicacao ativa.

A abordagem de replicacao ativa pode ser usada em um espectro amplo de faltas(crash, omissao, temporizacao, valor e arbitraria).

5.3. A abordagem de replicacao semi-ativa

Alguns autores identificam uma terceira abordagem de replicacao, chamada de semi-ativa(ou semi-passiva). Esta abordagem apresenta uma combinacao de algumas caracterısticasdas duas abordagens anteriores: as replicas sao todas ativas, sendo uma replica privile-giada.

Cliente

Grupo servidor

Requisição

Figura 14: Tecnica de replicacao semi-ativa.

Nesta abordagem todas as replicas executam os pedidos de servico, no entanto,apenas a replica privilegiada (lıder) e responsavel pela definicao da ordem de execucaodos pedidos e tambem pela resposta ao s clientes (figura 14). Na falha da replica privi-legiada, uma das replicas do grupo assume o seu papel, baseado em algum algoritmo deeleicao. Nesta abordagem, como todas as replicas sao ativas, nao existe a necessidade derecuperacao de estado baseada em retrocesso, tal como na replicacao passiva.

6. Arquitetura CORBA

A arquitetura CORBA (Common Object Request Broker Architecture)[Object Management Group, 2002] padronizada pela OMG (Object ManagementGroup), corresponde as mais bem sucedidas (e influentes) especificacoes de middlewarepara suporte a sistemas de objetos distribuıdos. O principal componente desta arquite-tura e o ORB (Object Request Broker) que entre outras funcionalidades implementaas semanticas de comunicacao definidas na arquitetura. As mensagens trocadas nas

comunicacoes seguem uma sintaxe de transferencia propria: o General Inter-ORB Proto-col (GIOP). Esta sintaxe torna as mensagens envolvidas nas comunicacoes independentesdas implementacoes de ORBs e das consequencias de um ambiente heterogeneo. Omapeamento do GIOP sobre o TCP/IP e concretizado atraves do IIOP, Internet Inter-ORBProtocol.

Com o advento da Internet, sistemas distribuıdos inicialmente baseados em re-des locais (ambientes normalmente homogeneos), tomaram as dimensoes de sistemas delarga escala que sao executados em ambientes heterogeneos em termos de hardware, lin-guagens de programacao e tecnologias de rede. Esta transformacao levou a introducaode novos padroes e muitas tecnologias de middleware para o suporte a programacao dis-tribuıda. Reconhecendo a urgencia do problema, em abril de 1989 um conjunto de empre-sas e instituicoes de pesquisas formaram a OMG. A OMG teve desde o seu inıcio comoprincipal objetivo a disseminacao da tecnologia de objetos distribuıdos.

Em outubro de 1991 a OMG lancou o padrao CORBA, que introduzia umainfra-estrutura de objetos distribuıdos completamente independente de plataforma. Nestepadrao, objetos possuem suas interfaces definidas em uma linguagem de definicao de in-terfaces (IDL) independente de linguagem de programacao. Estas interfaces podem serexportadas para a tecnologia de implementacao do sistema.

Esta secao apresenta um pequeno resumo dos principais elementos da arquiteturaCORBA.

6.1. O Modelo de Comunicacao CORBA

A arquitetura CORBA esta centrada em dois elementos basicos: o ORB (Object RequestBroker) e a IDL (Interface Definition Language). O ORB e o barramento de objetosresponsavel pela troca de mensagens entre componentes em um sistema CORBA. A IDLe a linguagem utilizada na definicao das interfaces dos objetos, ela se faz presente paragarantir que as funcionalidades exportadas por um objeto CORBA sejam independentesda linguagem de programacao em que este e implementado.

A figura 15 apresenta o modelo basico de comunicacao do CORBA, que imple-menta um RMI. Nesta figura, temos uma requisicao passando de um cliente para umaimplementacao de objeto remoto (objeto CORBA).

Cliente Servidor

ORB

Figura 15: Modelo de comunicacao basico do CORBA.

A partir da figura 15, dois aspectos podem ser levantados [Siegel, 1998]:

1. Tanto o cliente quanto a implementacao do objeto remoto estao isolados do ORBpela interface independente de linguagem especificada inicialmente em IDL;

2. A requisicao nao passa diretamente do cliente para a implementacao do ob-jeto. Em um sistema CORBA, como na maioria das implementacoes de RMI,a execucao de requisicoes dependem de suporte do ORB.

O mecanismo de RMI do CORBA compreende basicamente a transformacao dainvocacao de metodo em uma mensagem e sua transmissao ao host destino atraves doservico de sockets fornecido pelo sistema operacional e protocolos de transporte sub-jacentes, e ainda, a sua recuperacao no host destino com a transformacao inversa e ainvocacao do metodo na implementacao do objeto.

A figura 16 apresenta como e realizada a conversao de invocacao de metodo paramensagens e vice-versa.

GIOP GIOP

IIOPIIOP

Internet

Object Request Broker

(TCP/IP)

method call

GIOP message

IIOP message

IIOP message

GIOP message

method call

Client Object Server Object

Figura 16: Funcionamento (simplificado) do CORBA com IIOP.

Na figura 16, e apresentado o protocolo GIOP, General Inter-ORB Protocol, quecomo o proprio nome sugere e um protocolo generico que define mensagens e formatospara a interoperabilidade entre ORBs diferentes. A sintaxe de transferencia definida noGIOP (CDR - Common Data Representation) e a base para comunicacoes na arquiteturaCORBA; todas as requisicoes quando transmitidas sao codificadas nesta sintaxe na formade sequencias de bytes. O protocolo GIOP e generico e quando mapeado em protocolosde transporte define protocolos especıficos de mapeamento. Para a Internet, por exem-plo, um destes protocolos especıficos e o IIOP (Internet Inter-ORB Protocol) que e umaconcretizacao do GIOP considerando o protocolo de transporte TCP.

O IIOP foi definido para comunicacao entre um emissor e um receptor, conformeapresentado na figura 16, como nao poderia ser diferente, dadas as caracterısticas doprotocolo de transporte que ele utiliza (TCP). Outra caracterıstica deste protocolo e aconfiabilidade. O TCP garante que se nao houverem falhas nos hosts comunicantes e nocanal de comunicacao, todas as mensagens serao entregues com ordenacao FIFO.

6.2. Visao Geral da Arquitetura CORBA

A figura 17 mostra a arquitetura de um ambiente CORBA[Object Management Group, 2002]:

SkeletonIDL

(estática)

Skeleton deInvocaçãoDinâmica

Adaptadorde Objeto

(BOA)

Interface deInvocaçãoDinâmica

(DII)

Stubs IDL(estática) Interface

do ORB

ClienteImplementação de Objeto

Repositório deInterfaces

Repositório deImplementações

Núcleo ORB

Figura 17: Arquitetura CORBA.

O mecanismo de RMI suportado pelo CORBA e gerado, em sua versao estatica,a partir da traducao da especificacao IDL da interface do objeto servidor, dando origemaos stubs e skeletons IDL que implementam grande parte dos aspectos de serializacao edeserializacao (marshaling e unmarshaling) de requisicoes remotas. Interfaces dinamicaspara RMI sao fornecidas tambem pelo CORBA, o que permite que chamadas dinamicassejam montadas (DII - Dynamic Invocation Interfaces) e objetos sem skeletons compi-lados sejam localizados e ativados (DSI - Dynamic Skeleton Interface). Estas interfacesdinamicas permitem uma certa flexibilidade em tempo de execucao no modelo de objetosdistribuıdos do CORBA.

A linguagem IDL, um dos componentes centrais da arquitetura CORBA na garan-tia de interoperalidade, e um sub-conjunto da linguagem C++ acrescida de algumaspalavras-chave que permitem a descricao de interfaces remotas e outros elementos rela-cionados a objetos distribuıdos. A IDL e uma linguagem declarativa (nao algoritimica).

Os objetos CORBA podem ser acessados, independente de suas linguagens deimplementacao, uma vez definidas suas interfaces em IDL. A traducao destas interfacesdao origem aos stubs e skeletons nas linguagens de implementacao do cliente e servidorrespectivamente.

Do ponto de vista operacional, um cliente consegue acessar uma implementacaode um objeto CORBA atraves da referencias deste, chamada IOR (Interoperable ObjectReference). A IOR contem um conjunto de informacoes relacionadas ao mecanismo detransporte utilizado pelo ORB, que sao encapsuladas em perfis. Por exemplo, a figura18 apresenta um perfil IIOP, utilizado pelo nucleo do ORB para realizar comunicacoesatraves do TCP/IP.

O Adaptador de Objetos, tambem presente na figura 17, e o responsavel pelasinteracoes entre o mundo dos objetos CORBA e o mundo das implementacoes em de-terminada linguagem de programacao. Assim, sua principal funcao e localizar, ativar eencaminhar mensagens aos skeletons (e as implementacoes associadas) a partir de tabelasque traduzem enderecos locais a partir de referencias a objetos. O adaptador de objetospadrao definido nas especificacoes CORBA e o POA (Portable Object Adapter).

TAG_INTERNET_IOP ProfileBody

IOR

Perfil IIOP

Type_id Number ofprofiles IIOP_Profile

IIOPVersion Host Port Object

Key Components

ComponentsOther

Figura 18: Referencia de Objetos com Perfil IIOP

7. Fault-Tolerant CORBAA OMG comecou a se preocupar com a introducao do suporte a tolerancia a faltas noCORBA a partir de 1998 com a publicacao de uma RFP (Request For Proposals) pedindopropostas de servicos relacionados a esta funcionalidade. Esta RFP define ainda uma seriede requisitos a serem atendidos por estas propostas.

Como resultado deste RFP e das propostas recebidas pela OMG chegou-se a especificacao do padrao FT-CORBA [Object Management Group, 2000,Object Management Group, 2002]. Atraves deste padrao a tolerancia a faltas eobtida no CORBA atraves de tecnicas de replicacao de objetos, baseadas em mecanismosde deteccao e recuperacao de faltas.

O padrao criado especifica uma serie de objetos de servicos usados no forneci-mento da tolerancia a faltas em objetos CORBA. O padrao fornece tolerancia a faltas emhipoteses de faltas de parada. A especificacao define ainda quatro tipos de replicacao paraos grupos de objetos mantidos pelo FT-CORBA:

• Sem Estado: Estilo de replicacao em que o estado dos objetos nao e alteradopelas requisicoes. Neste caso, quando ocorrem falhas de objetos, nao existemtransferencias de estados durante a recuperacao do sistema;

• Passiva Fria: Apenas uma replica do grupo (objeto ou replica primaria) exe-cuta as requisicoes do cliente. As demais replicas (secundarias) ficam em modo”standby”(reserva). O primario grava periodicamente informacoes de estado(checkpoint). Em caso de falha do objeto primario uma das replicas secundariasassume o papel de novo primario, atualizando seu estado a partir do ultimo check-point gravado e das mensagens difundidas no grupo desde entao;

• Passiva Morna: Este modo funciona de maneira semelhante ao anterior com adiferenca de que os checkpoints feitos pela replica primaria sao difundidos para asreplicas secundarias, agilizando desta forma a atualizacao de uma replica em casode falha;

• Ativa: Todos as replicas executam as requisicoes. Este estilo de replicacao segueo modelo de maquinas de estados definido em [Schneider, 1990].

Dentre estes quatro tipos de replicacao a unica que e prevista, mas nao especificadaainda, e a replicacao ativa, que devera aparecer em futuras versoes do FT-CORBA.

Independente do tipo de replicacao utilizado, as especificacoes FT-CORBA per-mitem que ferramentas proprietarias de comunicacao de grupo possam ser usadas para

que requisicoes possam ser difundidas (de preferencia atraves de difusao atomica) portodos os membros do grupo.

Esta secao apresenta a arquitetura basica do padrao FT-CORBA e os mecanismosque garantem a interoperabilidade deste padrao com o restante da arquitetura CORBA.

7.1. Arquitetura FT-CORBA

Na figura 19, e apresentada a arquitetura de tolerancia a faltas do CORBA. Nela sao ap-resentados os objetos de servico, dispostos em tres modulos de servico, que fornecem,no middleware, as funcionalidades basicas para a construcao de aplicacoes tolerantes afaltas. Segundo as especificacoes, o Servico de Gerenciamento de Replicacao (SGR) eo responsavel pelo gerenciamento de grupo. Esta tarefa e delegada ao seu Servico deGerenciamento de Grupo de Objetos, exercendo um controle dinamico, nas entradas esaıdas (normal ou por falha) de objetos replicados, de um grupo atraves da manutencaode uma lista atualizada de seus membros (membership). O objeto Servico Gerenciamentode Replicacao utiliza o objeto Fabrica Generica no processo de criacao ou remocao dereplicas de um grupo. Nesse processo, o objeto Fabrica Generica interage com os objetosfabrica locais (representante local do primeiro) para a criacao ou remocao de replicas nasdiferentes estacoes de um sistema distribuıdo. Alem disso, temos o Servico de Gerencia-mento de Propriedades onde sao definidas e manipuladas as propriedades de tolerancia afaltas de cada grupo de objetos sob controle do Servico de Gerenciamento de Replicacao.As propriedades definem, basicamente, como cada grupo deve ser gerenciado e controladopelos servicos do FT-CORBA. Por exemplo, uma das informacoes mantidas no gerencia-mento de propriedades e a definicao da tecnica de replicacao implementada em um grupo,que registra se o mesmo pode funcionar como: Replicacao Passiva Fria, Replicacao Pas-siva Quente e Replicacao Ativa [Object Management Group, 2000].

No Servico de Gerenciamento de Falhas (SGF), a deteccao (ou monitoramento)de falhas e dividida em tres nıveis: objeto, processo e host. Os detectores de falhas nostres nıveis citados sao baseados em mecanismos de timeout. O detector de falha em nıvelde host e mantido replicado no sentido de garantir a continuidade do servico mesmo empresenca de falhas. O Servico Notificador de Falhas e tambem replicado e tem a funcaode enviar mensagens de notificacao ao gerente de replicacao, a partir dos registros defalhas enviados pelos detectores de falhas dos tres nıveis. Esses registros sao necessariosao Servico de Gerenciamento de Replicacao para atualizacao das listas de membros.

O Servico de Logging e Recuperacao (SLR) inclui, basicamente, tres funcoes:registrar (fazer uma copia) as requisicoes recebidas pelo primario (Objeto Servidor 1),atualizar o estado das replicas que se juntam ao grupo e recuperar replicas faltosas. Esteservico atua nos eventos de falha do objeto primario e na inclusao de uma nova replicano grupo. Por exemplo, em um evento de falha do primario o Servico de Recuperacaoenvia ao novo primario as requisicoes enviadas ao primario anterior a partir do ultimocheckpoint.

Todas as comunicacoes entre os objetos sao atraves do ORB e, caso necessario,com o auxılio do sistema de comunicacao de grupo. O sistema de comunicacao de grupofornece ao middleware CORBA os mecanismos de comunicacao de grupo confiavel parao suporte as tecnicas de replicacao - oferecendo alguma garantia de atomicidade e ordemna entrega das mensagens. Nos itens subsequentes, e apresentado, em mais detalhes, cada

um desses objetos de servico da arquitetura de tolerancia a faltas CORBA.

Estes tres modulos definem varios objetos de servico. A figura 19 apresenta aarquitetura FT-CORBA com estes objetos de servico.

Host 1 Host 3 Detector de Falha de Processo

Host 2 Detector de Falha

de Processo

Gerenciamento de Replicação

Fábrica Genérica

Gerenciamento de Propriedades

Gerenciamento de Grupo de Objetos

Notificador de Falha Detector de Falha de Host

is_alive()

P2

Fábrica

ORB

Mecanismo de Logging

Detector de Falha de Objeto

Mecanismo de Recuperação

is_alive()

Processo P1

ORB

Cliente

P4

P3

Fábrica

ORB

Mecanismo de Logging

Detector de Falha de Objeto


is_alive()

Sistema de Comunicação de Grupo Proprietário

is_alive() is_alive()

Notificação

Create_object()

Objeto Servidor 2

Objeto Servidor 1

Figura 19: Arquitetura FT-CORBA.

7.2. Interoperabilidade

A OMG, como e de sua caracterıstica, se limita em definir interfaces de servico genericas,tentando atender diferentes abordagens de tolerancia a faltas. Por exemplo, protocolos decomunicacao de grupo confiavel, base fundamental para a implementacao de tecnicasde replicacao em sistemas distribuıdos, nao sao padronizados - como era de se esperar,pela complexidade dos mesmos e pela quantidade de algoritmos envolvidos. A OMGenfatiza, neste caso, o uso de solucoes proprietarias (figura 19). Todavia, para garantir ummınimo grau de interoperabilidade, os sistemas de comunicacao de grupo devem adotara IOGR (Interoperable Object Group Reference): uma referencia interoperavel de grupode objetos definida em [Object Management Group, 2000]. A IOGR corresponde a umaextensao da IOR (Interoperable Object Reference), referencia a um objeto simples. UmaIOGR permite a um cliente referenciar um grupo de objetos como uma entidade unica.De forma generica, esta referencia de grupo contem o conjunto de IORs de cada membrosde um grupo de objeto em seus campos. Uma IOR convencional para um objeto unico,contem as informacoes de versao, endereco IP do sıtio, a porta, um ponteiro para o objetomembro a ser acessado, e algumas informacoes de controle.

TAG_INTERNET_IOP ProfileBody componentsNumber of TagGroupComponent Other

Components


Key ComponentsIIOPVersion Host Port Object

Key Components

TAG_FT_GROUP ComponentBody

VersionTag Group ft_domain_id object_group_id object_group_version

IOR Type_id Number ofprofiles IIOP_Profile IIOP_Profile

ProfileBodyTAG_INTERNET_IOP

OtherComponents

Multiple ComponentsProfile

componentsNumber of Other

ComponentsTagGroupComponentTAG_PRIMARYNumber ofcomponents TagGroupComponent

Figura 20: Estrutura da IOGR.

A estrutura apresentada na figura 20 e bastante semelhante ao da referencia de ob-jeto simples (IOR). A grande diferenca entre estes dois tipos de referencias reside no fatode que ao inves de ter apenas o perfil relacionado ao objeto correspondente a referencia,a IOGR contem uma serie de perfis, um para cada membro do grupo. Tambem ha umaestrutura chamada TagGroupComponent que contem informacoes a respeito do grupoem si, como seu identificador, domınio e versao.

O membro primario do grupo e definido a partir da presenca da tagTAG PRIMARY na lista de componentes de seu perfil.

7.3. Gerenciamento de Replicacao

O objeto de Servico Gerenciamento de Replicacao (SGR) e um importante componente daarquitetura de tolerancia a falta (figura 2.3.11). Herda as funcionalidades dos objetos deServico de Gerenciamento de Propriedades (SGP), Servico de Gerenciamento de Grupode Objetos (SGG) e Servico Fabrica Generica (SFG) para oferecer um completo suportepara gerenciamento de replicacao de objeto. No entanto, o SGR, em si, oferece apenasoperacoes relacionadas com o notificador de falha. Basicamente, gerencia a referenciade grupo de objetos (IOGR) do notificador de falha para que esta possa ser obtida pelaaplicacao ou pelos outros servicos da arquitetura. Contudo, as especificacoes permitemque a interface do SGR possa ser estendida, com solucoes proprietarias, com metodossimilares para os outros componentes da arquitetura FT-CORBA.

Host 3

Host 1

Detector de Falha

is_alive()

Host 2

Host 3

Host 1

Detector de Falha

is_alive()

Host 2

Host 3

Host 1

Detector de Falha

is_alive()

Host 2

Processo;

Objetos dos grupos A, B e C, respectivamente.

(c) monitoramento exercido em apenas um objeto membro de um grupo em um host.

(b) monitoramento exercido em apenas um objeto de cada host. (a) monitoramento exercido em todos objetos.

Figura 21: Tipos de monitoramento de falha no FT-CORBA.

7.3.1. Gerenciamento de propriedades

O SGR herda as funcionalidades do servico de gerenciamento de propriedades, o quetorna possıvel ao SGR definir as propriedades de tolerancia a faltas dos grupos de objetoscriados. Segundo as especificacoes, o servico de gerenciamento de propriedade mantemum conjunto de propriedades de tolerancia a faltas associada a cada grupo de objetos,assim definidas:

• ReplicationStyle: define a tecnica de replicacao utilizada, assim classificadas:Stateless, Replicacao passiva fria, Replicacao passiva quente, Replicacao ativa;

• FaultMonitoringGranularity: define o tipo de monitoramento de falha: (i) seocorrera sobre cada membro individual de um grupo (figura 21a); (ii) se ocorrerasobre um membro representativo de um host H (figura 21b) contendo mais de umobjeto (a falha do membro representativo e considerado como a falha de todos ob-jetos pertencente ao host H, independente se e membro do mesmo grupo ou nao);e, finalmente, (iii) se o monitoramento e exercido sobre o membro representativode um grupo G no host H (figura 21c);

• MembershipStyle: define se a criacao de novas replicas e feita em nıvel deaplicacao de forma nao transparente ou em nıvel de suporte, usando os objetosfabrica;

• ConsistencyStyle: define se os procedimentos de transferencia de estado (check-point), logging e recuperacao sao realizados em nıvel de aplicacao ou atraves dosservicos oferecidos na arquitetura de tolerancia a faltas no CORBA;

• FaultMonitoringStyle: sao definidos dois atributos, o PULL em que o objeto de-tector de falhas envia periodicamente mensagens para o objeto monitorado paraverificar se esta ativo. E o PUSH em que o proprio objeto envia mensagens peri-odicamente ao detector de falhas para indicar que esta ativo;

• Factories: fornecem as informacoes do objeto fabrica. Por exemplo, a referenciado objeto (IOR), a localizacao onde deve criar remotamente um membro de umgrupo de objeto, e os criterios usados para criar esse membro;

• MinimumNumberReplicas: define o numero mınimo de replicas em um grupopara manter o grau de tolerancia a falta desejado;

• FaultMonitoringIntervalAndTimeout: define o intervalo de monitoramento(ping) e o tempo de resposta (timeout) do objeto monitorado para determinar seesta faltoso;

• CheckpointInterval: determina o intervalo de tempo entre cada atualizacao deestados. Essas propriedades para grupo de objetos podem ser estabelecidas estati-camente para um domınio de TF, ou estabelecidas e modificadas dinamicamentedurante a execucao.

7.3.2. Gerenciamento de grupo de objetos

O servico de gerenciamento de grupo (SGG) oferece metodos que permitem registraras referencias de grupo de objeto (IOGR) e metodos para que essas IOGRs possam serobtidas pela aplicacao ou pelos outros servicos da arquitetura FT-CORBA. O servico degerenciamento de grupo de objetos funciona, similarmente, como um servico de nomespara grupo de objeto. No entanto, possui uma caracterıstica distinta, permite um geren-ciamento de IOGRs para grupos dinamicos. Um grupo definido como dinamico significaque o numero de membros no grupo (membership) pode mudar dinamicamente. Essasmudancas podem ocorrer pela entrada de um novo membro ou pela saıda de um membrodo grupo (normal ou por falha). Na criacao de novas replicas, o objeto de servico gerentede replicacao usa o objeto fabrica generica (um COSS) para criar novas copias do objetoservidor da aplicacao. Portanto, o servico de gerenciamento de grupo de objetos se encar-rega de gerenciar as diferentes versoes de uma IOGR, modificadas a cada atualizacao demembership. Alem disso, o SGG fornece metodos para a localizacao de membros em umgrupo de objetos.

7.3.3. Fabrica generica

Este servico permite ao SGR criar e remover grupos de objetos, replicas (membros degrupo de objetos) e objetos nao replicados. A interface da fabrica generica e implemen-tada pelos objetos fabricas locais situados um em cada host (figura 19). Desta forma, oSGR pode invocar os objetos fabricas locais para criar membros de um grupo de objetose, tambem, permitir a aplicacao invocar os objetos fabricas locais para criar objetos naoreplicados.

7.4. Gerenciamento de falha

O servico de gerenciamento de falha e responsavel pela atividade de deteccao de falha,notificacao de falha e, analise e diagnose de falha (figura 22). Os detectores de falhadetectam falhas em objetos e reportam para um notificador de falha. O notificador de falharecebe os registros de falha dos detectores, filtram as informacoes contidas nos registros, epropagam, como eventos, os registros filtrados para os consumidores que estao subscritos

no notificador de falha. O analisador de falha faz a atividade de filtragem. Consulta osregistros de falhas, mantido pelo notificador de falha, e gera um registro filtrado paraenviar de volta ao notificador de falha (figura 22).

Aplicação Detector de Falha

Detector de Falha

Gerenciamento de Replicação

Analisador de Falha

is_alive() is_alive()

Notificação

Objeto Servidor 4

Notificador de Falha

Objeto Servidor 3

Objeto Servidor 2 Objeto

Servidor 1

Figura 22: Tipos de monitoramento de falha no FT-CORBA.

Segundo as especificacoes, o servico de deteccao de falhas e dividido em tresnıveis, detectores de falhas em nıvel (i) de objeto, (ii) de processo e (iii) de host (figura19). Os detectores de falhas nos diferentes nıveis sao baseados em mecanismos de time-out. Sao dois os estilos de monitoramento de falha disponıveis: o Pull e o Push (esteainda nao especificado) - diferem na direcao em que as informacoes de falha transitam nosistema.

O detector de falha em nıvel de host se utiliza de replicacoes. Isto se explica pelacomplexidade na reposicao de servico de uma estacao. Se for para restaurar funcionali-dades atribuıdas a uma estacao e necessaria uma boa probabilidade na correcao de umadeteccao. Em termos de sistemas de larga escala, as especificacoes aconselham um ar-ranjo de detectores de falhas estruturados em forma hierarquica, com diferentes domıniosde deteccao.

O servico notificador de falhas tem a funcao de enviar mensagens de notificacao aoservico de gerenciamento de replicacao (SGR), a partir dos registros de falhas enviadospelos detectores de falhas dos tres nıveis. Com isso, o SGR, com estas notificacoes,pode atualizar as IOGRs de grupo. O notificador de falha filtra os registros de falha nosentido de eliminar registros desnecessarios ou duplicados. Alem disso, os registros defalhas podem ser propagados, alem do gerenciador de replicacao, para qualquer objetode servico ou da aplicacao. Basta que se subscrevam como consumidores de eventos doservico de notificador de falhas.

A funcao do analisador de falha vai alem da atividade de descartar registros du-plicados e desnecessarios. Cada analisador de falha coleta registros de falha, fornecidopelo notificador de falha, e desempenha a funcao de verificar se ha uma correlacao entreos registros, analise e diagnose de falha. Pode condensar um numero grande de registrosde falhas relacionados em um unico registro de falha. Por exemplo, o crash de um sıtiopode provocar registros de falha de todos objetos naquele sıtio, bem como um registro defalha do sıtio em si.

7.5. Gerenciamento de logging e recuperacao

O servico de gerenciamento de logging e recuperacao (SLR) tem a funcao de garantir atransferencia de estado em situacoes de recuperacao de objetos faltosos, atualizacao de es-tado de objetos backup (nos modelos de replicacao passiva) e transferir o estado do grupopara os novos membros que se juntam a replicacao. Em um grupo de replicacao passiva,durante uma operacao normal, o mecanismo de logging registra o estado (checkpoint) eas acoes (os metodos executados) da replica primaria em um log (figura 23).

Host 1 Host 3 Host 2 P2

ORB

Mecanismos de Logging e Checkpoint


Processo P1

ORB

Cliente

P3

ORB



Objeto backup

Objeto primário

Figura 23: Operacao normal: registro das requisicoes em um log.

O log deve preservar a ordem em que as requisicoes (mensagens) foram rece-bidas pela replica primaria. Deste modo, as requisicoes contidas dentro do log podemser re-executadas, na ordem correta, durante o processo de recuperacao. O mecanismode logging mantem um log distinto para cada grupo de objeto. No entanto, os logs dosdiferentes grupos podem ser registrados num mesmo log fısico (ex: um disco fısico). Omecanismo de logging pode ser disposto de forma distribuıda, um para cada objeto repli-cado (figura 19). .Em caso de falha do objeto primario, o mecanismo de recuperacaoe utilizado para reaver os registros guardados no log para restaurar o estado de um ob-jeto membro backup (figura 24), de tal modo que este possa substituir o objeto primariofaltoso.


ORB



Processo P1

ORB

Cliente

P3

ORB



Objeto backup

Objeto primário

set_state();

Figura 24: Recuperacao: atualizacao do novo primario.

Segundo as especificacoes, nenhuma interface e definida para este servico porqueestes mecanismos nao sao acessıveis diretamente pela aplicacao. Sao definidas duas in-terfaces (Checkpointable e Updateable) que os objetos da aplicacao devem herdar. Aprimeira permite a transferencia de todo o estado do grupo (o mais recente). E utilizada

na replicacao passiva fria para transferir o estado do primario faltoso para um backup(o novo primario, figura 24); e utilizada na replicacao passiva quente e replicacao ativaquando da entrada de um novo membro no grupo. A interface Updateable e utilizada paratransferencia de estado parcial na replicacao passiva quente - em situacoes em que umbackup ja possui um estado inicial e e atualizado periodicamente, por exemplo, a cadamudanca de estado do objeto primario (figura 25).


ORB



Processo P1

ORB

Cliente

P3

ORB



Objeto backup

Objeto primário

get_state();

Figura 25: Registro de checkpoint: atualizacao de log.

8. Unreliable Multicast Inter-ORB Protocol

Em 1999 a OMG iniciou o processo de especificacao de um protocolo de di-fusao nao confiavel baseado em multicast IP e um modelo de grupo de objetosque desse suporte a este protocolo em ORBs CORBA. Este processo culminou como lancamento das especificacoes UMIOP (Unreliable Multicast Inter-ORB Protocol)[Object Management Group, 2001], que serao apresentadas nesta secao. Primeiramentesera discutido o mapeamento do GIOP na pilha UDP/multicast IP; depois serao analisa-dos os aspectos referentes ao protocolo MIOP (Multicast Inter-ORB Protocol), que e aparte da especificacao que orienta este mapeamento, fornecendo entao comunicacao degrupo nao confiavel entre ORBs. Na sequencia e discutido o papel do MGM (MulticastGroup Manager), um componente opcional da especificacao que encapsula uma seriede funcionalidades para a criacao e gerenciamento de grupos na forma de um objeto deservico.

8.1. O Protocolo MIOP

O objetivo do MIOP e prover um mecanismo para a entrega de mensagens GIOP via mul-ticast. O mecanismo de transporte padrao do MIOP e o UDP [Postel, 1980] que tem seusdatagramas transferidos fazendo uso do multicast IP. Ao utilizar o UDP, protocolo semconexao e sem garantia de entrega, como protocolo de transporte, o acesso aos servicosdo multicast IP e conseguido praticamente sem nenhum overhead.

Uma mensagem GIOP transmitida via MIOP, e encapsulada em um conjunto depacotes MIOP. Um pacote MIOP e composto de um cabecalho e um bloco de dados GIOP.

O tamanho maximo do bloco de dados GIOP que pode ser carregado em um unicopacote MIOP depende do tamanho do frame suportado pelo hardware de rede utilizado.

A Ethernet, por exemplo, suporta frames de 1518 bytes. Entretanto vale lembrar que oprotocolo UDP permite mensagens de 512 a 65536 bytes.

A figura 26 apresenta a definicao em IDL do cabecalho do pacote MIOP.

module MIOP{typedef sequence<octet,252> UniqueId;

struct PacketHeader_1_0{

char magic[4]; //4 bytesoctet hdr_version; //1 byteoctet flags; //1 byteunsigned short packet_length; //2 bytesunsigned long packet_number; //4 bytesunsigned long number_of_packets; //4 bytesUniqueId id; //1-252 bytes

};};

Figura 26: IDL para o cabecalho MIOP.

O papel do cabecalho MIOP, definido pela estrutura PacketHeader 1 0, e per-mitir a reconstrucao de mensagens GIOP no ORB receptor. Os campos desta estrutura saodescritos a seguir:

• magic: Este campo identifica que a mensagem e um pacote MIOP. Seu valordeve ser sempre o literal ’MIOP’.

• hdr version: Este campo contem a versao do cabecalho. Os quatro bits demaior ordem correspondem a versao maior e os quatro de menor ordem a versaomenor. O valor deste campo nesta versao da especificacao deve ser 10H.

• flags: Este campo contem alguns flags, definidos dos bits de menor para os demaior ordem, a saber: codificacao (big(0) ou little endian(1)) e fim de mensagem(1 para o ultimo pacote de uma colecao). Os outros seis bits nao sao utilizados naversao atual do MIOP, e devem conter o valor 0.

• packet length: Contem o tamanho do bloco de dados contido no pacote. To-dos os pacotes de uma colecao, com excessao do ultimo, devem ter o mesmo valorneste campo.

• packet number: O numero do pacote em sua colecao. Por exemplo, se umamensagem GIOP e transformada em 20 pacotes MIOP, este campo deve ter o valor0 no primeiro pacote e 19 no ultimo.

• number of packets: Este campo e opcional, entretanto ele pode ser usado,em especial no primeiro pacote de uma colecao, para informar ao receptor quantospacotes devem chegar para completar esta mensagem. Quando este campo nao eutilizado, seu valor deve ser 0.

• UniqueId: Campo que identifica de maneira unica uma mensagem. O tamanhomaximo deste campo e 252 bytes, entretanto ele deve ser o menor possıvel. Ounico requisito associado a este campo e que cada colecao de pacotes deve ter

um identificador unico, e os pacotes de uma mesma colecao devem ter o mesmoidentificador (que e associado ao pacote).

Apos o cabecalho, deve se seguir um ”demarcador”de 8 bytes antes de comecaremos bytes do fragmento de dados GIOP.

Conforme ja discutido, o MIOP nao e um protocolo confiavel, assim a possibil-idade da perda de pacotes existe. Se algum pacote de uma colecao nao for recebido,mecanismos usuais como temporizadores devem ser utilizados para aguardar ate que amensagem (colecao de pacotes) esteja completa. Se algum pacote da colecao nao chegar,a colecao (e por conseguinte a mensagem) deve ser descartada.

8.2. Modelo de Objetos UMIOP e Suporte a Grupos

O modelo convencional de objetos CORBA especifica que uma referencia de objeto devecorresponder a uma unica implementacao do objeto via uma chave de objeto (ObjectKey). Alem disso, a semantica de invocacao do CORBA ponto a ponto e confiavel emrelacao a entrega e ordenacao de mensagens que podem ser definidas com ou sem esperade resposta.

O MIOP nao define um identificador de objetos, mas sim um identificadorde grupo que pode ser associado a multiplos identificadores de objetos (Object Id),que sao utilizados pelo POA para a ativacao das implementacoes correspondentes[Object Management Group, 2002]. A semantica de entrega de mensagens do UMIOPe sem garantia e controle de erros e ainda sem suporte a respostas. Como nao existemrequisitos de confiabilidade, nao e necessario um servico de membership no sentido dese ter conhecimento de quantos e quem sao os membros do grupo. Assim e possıvel queuma aplicacao fique enviando mensagens sem que alguem as esteja recebendo.

Um grupo de objetos no UMIOP consiste em informacoes de identificacao dogrupo (um identificador unico para este) e informacoes sobre como acessa-lo na rede decomunicacoes (endereco IP classe D e uma porta). A figura 27 representa (de maneirabastante simplificada) o funcionamento do CORBA com o protocolo MIOP. Nesta figura,um objeto cliente envia uma mensagem via MIOP a um grupo de objetos.

8.2.1. Perfil para Difusao Nao Confiavel

O perfil para difusao nao confiavel, que representa as informacoes de transporte do grupo,e definido, na especificacao UMIOP, pela estrutura UIPMC ProfileBody. Esta estru-tura contem todas as informacoes requeridas para realizacao de uma invocacao a umaimplementacao utilizando UDP/multicast IP como pilha de protocolos de comunicacao.Este perfil difere do tradicional perfil IIOP nos seguintes pontos:

• Nao existe chave de objetos;• O campo que continha o nome do host onde o objeto esta implementado foi sub-

stituıdo por um campo que deve conter um endereco IPv4/v6 de multicast, ou umalias para este endereco.

O falta de um identificador de objetos neste perfil se deve ao fato das requisicoesMIOP tipicamente terem mais de um receptor e estes poderem estar em ORBs diferentes.

GIOP

Internet

GIOP GIOP

method call

GIOP message

MIOP packets

MIOP

(UDP/IP)

GIOP message

method call

MIOP

MIOP packets

GIOP message

method call

MIOP

MIOP packets

Multicast Object Group

Client Object Server Object Server Object

Object Request Broker

Figura 27: Funcionamento (simplificado) do CORBA com MIOP.

Este cenario e bem mais complexo do que o dos perfis IIOP, que definem um identificadorpara uma implementacao.

A definicao em IDL do UIPMC ProfileBody e apresentada na figura 28.

module MIOP{...typedef GIOP::Version Version;typedef string Address;

struct UIPMC_ProfileBody{

Version miop_version;Address the_Address;short the_port;sequence<IOP::TaggedComponents> components;

};};

Figura 28: IDL para o UIPMC ProfileBody.

A seguir os campos do perfil definido na figura 28 sao detalhados:

• miop version: Este campo contem a versao do perfil. A versao atual e 1.0. Aversao definida neste campo nao tem ligacao com a versao definida no cabecalhodos pacotes MIOP (que e a versao do cabecalho);

• the address: Este campo especifica um endereco IP de multicast valido ou umalias para um endereco deste;

• the port: A porta associada ao endereco destino que identifica os processosreceptores;

• components: Lista de componentes auxiliares. Um componente que deve sem-pre estar presente nesta lista e a estrutura TagGroupComponent, que identificaum grupo de maneira unica. Outro componente usualmente utilizado e o perfilIIOP de grupo, que e utilizado em operacoes com resposta3.

Vale lembrar que a estrutura UIPMC ProfileBody esta sempre presente emreferencias de grupos UMIOP. Este tipo de referencia e apresentado na proxima secao.

8.2.2. Referencia de Grupo UMIOP

Conforme ja apresentado, a IOR serve como identificacao unica de um objeto(implementacao) no CORBA. Entre os seus campos temos o endereco da implementacao(tipicamente um IP e porta) e um numero que a identifica de maneira unica no ORB servi-dor (chave de objeto). Este IOR e utilizado pelos ORBs clientes como ponteiros para asimplementacoes, enderecando as requisicoes de metodos a elas atraves dele.

Uma IOR de grupo serve basicamente para realizacao de tres tipos de invocacao:

• A um gateway IIOP, nos casos em que o cliente, atraves de seu ORB, nao e capazde difundir mensagens via multicast IP;

• A servidores que suportam MIOP, implementam a mesma interface e pertencemao mesmo grupo;

• A um servidor IIOP do grupo que deve responder as requisicoes de operacoestwo-way (chamado doravante de perfil IIOP de grupo).

Dada a necessidade da realizacao destes tres tipos de invocacoes, a IOR de gruponao pode ser estruturada da mesma forma que a utilizada nas referencias a objetos con-vencionais (que utiliza apenas um perfil IIOP). Desta forma, um formato de IOR de grupofoi definido pela OMG como parte das especificacoes. Esta nova IOR contem o perfilUIPMC e opcionalmente outros perfis IIOP. A figura 29 apresenta o formato de uma IORde grupo em sua estrutura completa, com os perfis de gateway e de objeto que respondeas requisicoes com resposta (perfil IIOP de grupo). A parte da IOR que identifica o grupoe representada pela estrutura TagGroupComponent. A IDL que define esta estrutura eapresentada na figura 30.

A descricao dos campos da estrutura TagGroupComponent e apresentada aseguir:

• component version: A versao deste componente;• group domain: Este campo contem uma string que define o escopo para o

identificador de grupo;• object group id: Um identificador unico de 64 bits para o grupo;• object group ref version: Este campo e opcional e deve conter o valor 0

quando nao utilizado. Uma implementacao pode utilizar este campo se multiplasversoes de uma referencia a determinado grupo existirem.

3Como o perfil UIPMC so suporta mensagens oneway (sem resposta), faz-se necessario um perfil IIOPque responda as requisicoes two-way implıcitas a objetos CORBA, como o metodo is nil() definidopara todos os objetos remotos.

Type_id Number ofprofiles IIOP_Profile UIPMC_Profile

ProfileBodyTAG_UIPMC

ComponentsPortMulticastAddress

MIOPVersion

componentsNumber of Tag Group

ComponentTag Group IIOP

Component ComponentsOther

TAG_INTERNET_IOP ProfileBody


Key Components

ComponentscomponentsNumber of

ComponentVersion

GroupDomainId

ObjectReferenceersion

ObjectGroupId


Key Components

ComponentscomponentsNumber of

Perfil IIOP de GrupoInformaçoes do Grupo

Perfil UIPMC

Perfil IIOPdo Gateway

IOR

Figura 29: IOR de grupo multicast.

module PortableGroup{typedef GIOP::Version Version;

struct TagGroupComponent //tag = TAG_GROUP{

Version component_version;GroupDomainId group_domain;ObjectGroupId object_group_id;ObjectGroupRefVersion object_group_ref_version;

};};

Figura 30: IDL para o TagGroupComponent.

A criacao da IOR de grupo acontece atraves da especificacao das informacoessobre o grupo (para o preenchimento das estruturas UIPMC ProfileBody eTagGroupComponent) e das IORs com o perfil IIOP de grupo e do gateway. Estacriacao acontece atraves da chamada de metodos de criacao de referencias do ORB (vermais a frente o mecanismo de corbaloc) ou atraves de metodos do MGM (ver secao afrente).

8.2.3. Grupos de Objetos Nao-Confiaveis

Um grupo de objetos representa uma colecao de implementacoes que compartilham umconjunto de informacoes em comum, associadas a definicao do grupo. Normalmenteestas informacoes sao armazenadas em um gerenciador de grupos, assim, em um sis-tema de suporte a grupos, existem informacoes relacionadas ao membership de objetosentre as informacoes do grupo. Entretanto, a referencia de grupo definida pela OMGnas especificacoes UMIOP nao trata este tipo de dado (diferentemente da IOGR do FT-CORBA), e assume que estas informacoes serao tratadas em futuras submissoes rela-cionadas a grupos.

8.2.4. Adaptador Portavel de Grupo (PGA)

A fim de que o POA (adaptador de objetos padrao do CORBA) suporte a existencia degrupos de objetos, quatro novas operacoes foram adicionadas a ele, dando origem entaoao Adaptador Portavel de Grupo (PGA).

Conforme ja discutido, o perfil UIPMC nao define uma chave de obje-tos unica para grupos, assim o POA deve utilizar as informacoes associadas a es-trutura PortableGroup::TagGroupComponent, contida no perfil UIPMC eos identificadores de objetos locais - PortableServer::ObjectId’s 4 - as-sociados as implementacoes dos objetos participantes deste grupo para entregar arequisicao corretamente. Assim, pode-se dizer que a composicao da estruturaPortableGroup::TagGroupComponent com os identificadores de objetos dosmembros e equivalente a uma chave de objeto (ObjectKey) no contexto de grupos.

A figura 31 apresenta uma possıvel implementacao da entrega de uma requisicaoa um grupo em um ORB que implementa o UMIOP.

Incoming Requests Buffer

Multicast ORB

Network 1 2

34

PGA 1

GI1

GI2

GI3

1, 2, 4

3

2, 3

GroupInfo

MembersObject

IdObject

1

2

3

4

...

...

...

...

Active Group MapActive Object Map

PGA 2

Figura 31: Entrega de mensagens a grupos em um ORB com MIOP.

Na figura apresentada, sao definidas as varias etapas de processamento desde achegada de uma mensagem pela rede ate a entrega desta aos objetos pertencentes ao

4Identificadores utilizados pelo POA e pelas aplicacoes para manipular objetos dentro de seucontexto[Object Management Group, 2002].

grupo. Estes varios passos sao descritos a seguir:

1. Inicialmente a mensagem difundida vem do modulo de rede para a porta em queo ORB recebe requisicoes. Logo apos a integracao da colecao de pacotes MIOPque dara origem a requisicao em uma mensagem GIOP, esta e colocada em umafila de requisicoes;

2. Quando chega a vez da mensagem na fila de requisicoes, ela e retirada e passadaaos varios POAs ativos no ORB5;

3. Uma vez dentro do PGA, a estrutura TagGroupComponent presente noperfil UIPMC e consultada e utilizada como chave para uma busca natabela de grupos ativos. Esta tabela mapeia TagGroupComponent’s paraimplementacoes. Em nosso exemplo, a requisicao tem como destino o grupo cujoo TagGroupComponent e o GI3;

4. Pela tabela de grupos ativos, o GI3 tem como membros os objetos 2 e 3. Nestafase do processamento da requisicao ela e repassada para estes objetos atraves databela de objetos ativos, que mapeia ObjectId’s para as implementacoes.

Na figura 31 vemos que a implementacao da PGA necessita de uma tabela adi-cional em relacao aos POA convencionais: a Tabela de Grupos Ativos. Esta tabela deveconter os grupos ativos neste adaptador, bem como os identificadores locais dos objetosmembros deste (uma especie de membership no contexto do POA).

A figura 32 apresenta as novas operacoes adicionadas ao POA para o suporte agrupos, tornando-a desta forma um PGA.

module PortableServer{exception NotAGroupObject{};typedef sequence<ObjectId> IDs;

interface POA{

...ObjectId create_id_for_reference(in CORBA::Object the_ref)raises (NotAGroupObject);

IDs reference_to_ids(in CORBA::Object the_ref)raises (NotAGroupObject);

void associate_reference_with_id(in CORBA::Object ref,in ObjectId oid) raises (NotAGroupObject);

void disassociate_reference_with_id(in CORBA::Object ref,in ObjectId oid) raises (NotAGroupObject);

};};

Figura 32: Novas operacoes do POA.

As operacoes definidas na figura 32 permitem ao POA gerar, listar, associar e de-sassociar PortableServer::ObjectId a grupos de objetos. E importante ressaltar

5Aqui esta uma das diferencas para com as mensagens ponto-a-ponto, pois dentro do ObjectKeypresente nestas existe uma identificacao de qual POA esta gerenciando o objeto destino.

que todas as referencias passadas ao POA como parametros destas novas operacoes devemser referencias de grupo, caso contrario a excessao NotAGroupObject e ativada.

8.2.5. MGM - Gerenciador de Grupos Multicast

O MGM (Multicast Group Manager) e o objeto de servico opcional presente nasespecificacoes UMIOP que define metodos de mais alto nıvel para o gerenciamento degrupos multicast e os recursos de transporte associados a estes. Basicamente este servicoprove operacoes para criacao e destruicao de grupos e gerenciamento de propriedades.

O MGM e definido a partir de um novo modulo introduzido nas especificacoesUMIOP. Este modulo, chamado PortableGroup [Object Management Group, 2001],define, de maneira uniforme, uma serie de tipos, estruturas e interfaces utilizadas no trata-mento de grupos dentro do CORBA.

A interface do MGM, chamada ObjectGroupFactory, estende tres outrasinterfaces pertencentes ao modulo PortableGroup, conforme apresentado na figura33.

PortableGroup::PropertyManager

void set_default_properties(Properties props)Properties get_default_properties()void remove_default_properties(Properties props)void set_type_properties(TypeId type_id, Properties overrides)Properties get_type_properties(TypeId type_id)void remove_type_properties(TypeId type_id, Properties props)void set_properties_dinamically(ObjectGroup og, Properties props)Properties get_properties(ObjectGroup object_group)

PortableGroup::ObjectGroupManager

ObjectGroup create_member(ObjectGroup og, Location loc, TypeId tid, Criteria crit)ObjectGroup add_member(ObjectGroup og, Location loc, Object member)ObjectGroup remove_member(ObjectGroup object_group, Location the_location)Locations locations_of_members(ObjectGroup object_group)ObjectGroupId get_object_group_id(ObjectGroup object_group)ObjectGroupId get_object_group_ref(ObjectGroup object_group)Object get_member_ref(ObjectGroup object_group, Location loc)

PortableGroup::GenericFactory

Object create_object(TypeId tid, Criteria crit, FactoryCreationId fcid)void delete_object(FactoryCreationId factory_creation_id)

MGM::ObjectGroupFactory

<<>>

<<>>

<<>>

Figura 33: Diagrama de classes do MGM.

Na figura 33, a interface ObjectGroupFactory e basicamente a uniao,atraves da extensao, de tres outras: PropertyManager, ObjectGroupManagere GenericFactory. Estas interfaces sao descritas a seguir.

• PortableGroup::PropertyManager: Esta interface define metodos parao gerenciamento de tres nıveis hierarquicos de propriedades para objetos: pro-priedades padrao, propriedades do tipo e propriedades do objeto. As propriedadesdefinidas em nıvel de objeto sobrepoem as definidas para o tipo que sobrepoem

as propriedades padrao. Esta interface prove varios metodos para a definicao,remocao e listagem dos tres nıveis de propriedades;

• PortableGroup::ObjectGroupManager: Esta interface define metodospara o gerenciamento de grupos em geral. Entre estes metodos destacam-seos de criacao, adicao, remocao e obtencao de membros. Grande parte dosmetodos definidos nesta interface nao sao utilizados no MGM (lancam a ex-cessao CORBA::NO IMPLEMENT) devido ao fato dos grupos definidos nestaespecificacao nao manterem informacoes sobre membership. Assim, os unicosmetodos utilizados sao o get object group id, para a obtencao do identifi-cador de grupo associado a referencia passada, e o get object group ref,para atualizacao de uma referencia 6;

• PortableGroup::GenericFactory: Esta interface define dois metodosutilizados para a criacao e destruicao de objetos. As propriedades iniciais do gruposao passadas ao metodo create object atraves do parametro Criteria.Este parametro pode definir uma serie de propriedades como o endereco multi-cast IP do grupo.

A tabela 1 apresenta as propriedades validas utilizadas pelo MGM.

Propriedade DescricaoGroupCreationMode O endereco do grupo sera criado ou definido?

CreateSpecifyGateway O gateway multicastSupportImplicitOperations Objeto IIOP para operacoes implıcitas

CreateIncludeGateway Define se o gateway sera usado ou naoProtocolEndpointsIPPort Porta destino

ProtocolEndpointsIPAddress Endereco do grupoGroupDomainId Escopo do grupo

Tabela 1: Propriedades manipuladas pelo MGM.

Vale lembrar que mesmo sendo um objeto de servico bastante interessante paraa criacao e gerenciamento de grupos, o MGM e parte opcional do padrao MIOP. OsORBs que nao implementam o MGM utilizam-se do mecanismo de URLs corbalocpara definicao das informacoes do grupo em uma string que e passada ao metodostring to object do ORB para a criacao da referencia ao grupo. A figura 34 ap-resenta um exemplo de URL valida para a criacao de um grupo.

corbaloc:miop:[email protected]/225.1.2.8:2578

Figura 34: URL que cria um grupo UMIOP.

A especificacao completa do mecanismo de corbaloc para grupos UMIOP podeser encontrada nas especificacoes [Object Management Group, 2002].

9. ConclusaoO objetivo deste minicurso foi apresentar as principais conceito de tolerancia a faltase modelos de programacao de sistemas distribuıdos confiaveis. Adicionado a isso, sao

6Utilizando este metodo, qualquer alteracao de enderecos ou novas alocacoes tornam-se validas.

apresentadas especificacoes que contemplam grupos de objetos na arquitetura CORBA.Assim, foram apresentadas as especificacoes FT-CORBA e UMIOP. O FT-CORBA in-troduz no CORBA uma serie de objetos de servico uteis para o gerenciamento de gru-pos e tambem uma referencia padronizada para grupos onde as informacoes de member-ship estao disponıveis. Entretanto, este padrao nao aborda aspectos de comunicacao degrupo, que sao especialmente uteis na implementacao de modelos de replicacao ativa (quetambem nao e especificada neste padrao).

O UMIOP foi introduzido na arquitetura CORBA como um primeiro passo paraa construcao de um suporte de comunicacao de grupo nesta arquitetura. Este padraoapresenta um protocolo de difusao nao confiavel baseado em multicast IP e um modelode grupo sem membership.

Em termos de modelo de grupo, e possıvel verificar que as referencias de grupodefinidas pelas duas especificacoes apresentam semelhancas apenas no que diz respeitoa presenca do componente com as informacoes do grupo (TagGroupComponent -identico nas duas), de resto, a presenca do membership no IOGR do FT-CORBA e doperfil UIPMC na referencia de grupo do UMIOP diferencia, de maneira cabal, estes doistipos de referencias.

Em termos de objetos de servico, o MGM - unico objeto de servico definido peloUMIOP (opcional na especificacao) - apresenta as mesmas interfaces do Gerenciadorde Replicacao (SGR) do FT-CORBA. Entretanto, as operacoes que tem algum tipo derelacao com membership nao sao implementadas no MGM. Assim, apesar de iguais emsuas interfaces, o SGR apresenta um nıvel de complexidade e funcionalidade muitas vezessuperior ao MGM.

Analisando as similaridades e diferencas entre estas duas especificacoes chega-sea conclusao de que, a principio, elas tem finalidades completamente diferentes: enquantoo FT-CORBA utiliza a abstracao de grupos de objetos para prover servicos replicadostolerantes a faltas, o UMIOP apresenta os grupos como um conjunto de zero ou maisobjetos que podem ser invocados atraves de difusao nao confiavel. Assim, o UMIOP eindicado para aplicacoes que fazem uso de grupos explicitamente, como aplicacoes dedifusao de mıdia, e na implementacao de funcionalidades que sao baseadas em multicastIP normalmente, como por exemplo, a descoberta de servicos em uma rede.

Alem destes dois padroes homologados pela OMG, foram apresentadas tambemalgumas extensoes ao UMIOP de tal forma que este agregue aspectos de confiabilidadena comunicacao. Estas extensoes, chamadas ReMIOP, utilizam mecanismos de controlede fluxo e retransmissao de pacotes para prover confiabilidade de melhor esforco.

Estes padroes e extensoes foram implementados no contexto do projeto GROUP-PAC, em desenvolvimento no LCMI-DAS-UFSC, e estas implementacoes podem ser obti-das no sıtio do projeto: http://www.das.ufsc.br/grouppac.

Referencias

Birman, K. P. (1996). Building Secure and Reliable Network Applications. Manning,Greenwich.

Chandra, T. D. and Toueg, S. (1996). Unreliable failure detectors for reliable distributedsystems. Journal of the ACM, 43(2).

Coulouris, G., Dollimore, J., and Kinberg, T. (2001). Distributed Systems: Concepts andDesign. Addison-Wesley, Third Edition.

Deering, S. E. and Cheriton, D. R. (1985). Host groups: A multicast extension to theinternet protocol (rfc 966). IETF Request For Comments.

Defago, X., Schiper, A., and Urban, P. (2002). Totally ordered broadcast and multicastalgorithms: A comprehensive survey. Technical report, Communication Systems De-partment, Swiss Federal Institute of Technology in Lausanne,, Lausanne - Switzerland.

Felber, P., Garbinato, B., and Guerraoui, R. (1996). The design of a CORBA groupcommunication service. In Proceedings of the 15th Symposium on Reliable DistributedSystems, pages 150–159, Niagara-on-the-Lake, Canada.

Hadzilacos, V. and Toueg, S. (1994). A modular approach to the specification and im-plementation of fault-tolerant broadcasts. Technical report, Department of ComputerScience, Cornell University, New York - USA.

Lamport, L. (1978). Time, clocks, and the ordering of events in a distributed system.Communications of the ACM, 21(7):558–565.

Lynch, N. (1996). Distributed Algorithms. Morgan Kaufmann Publishers.

Maffeis, S. (1995). Adding group communication and fault-tolerance to CORBA. InProceedings of the USENIX Conference on Object Oriented Technologies, pages 135–146, Monterey, Canada.

Moser, L., Melliar-Smith, P., Narasimhan, P., Koch, R., and Berket, K. (2001). A mul-ticast group communication protocol, engine, and bridge for corba. Concurrency andComputation Pratice and Experience, 13(7):579–603.

Object Management Group (2000). Fault-tolerant corba specification v1.0. OMG Stan-dart.

Object Management Group (2001). Unreliable multicast inter-orb protocol specificationv1.0. OMG Standart ptc/03-01-11.

Object Management Group (2002). The common object request broker architecture: Corespecification v3.0. OMG Standart formal/02-12-06.

Postel, J. (1980). User datagram protocol (rfc 768). IETF Request For Comments.

Powel, D. (1996). Group communication. Communications of the ACM, 39(4):50–53.

Schneider, F. B. (1990). Implementing fault-tolerant service using the state machineaproach: A tutorial. ACM Computing Surveys, 22(4):299–319.

Siegel, J. (1998). Omg overview: Corba and the oma in enterprise computing. Commu-nications of the ACM, 41(10).

Date post:	06-Oct-2018
Category:	Documents
Upload:	vuongdung
View:	214 times
Download:	0 times

Programac‚aoŸ de Sistemas Distribu· dos Con av· eisalcides/Teaching/SistemasDistribuidos... ·...

Documents