Modelos de Execução para Comunicação em Grupo
Raul Ceretta Nunes
1,2Ingrid Jansch-Pôrto
2[email protected] [email protected]
RESUMO
O paradigma de programação baseado em grupos foi proposto para facilitar a construção de aplicações distribuídas tolerantes a falhas. A aplicabilidade de ferramentas de comunicação de grupo advém do modelo de execução adotado na implementação da comunicação entre os membros do grupo, entretanto, a semelhança entre os modelos dificulta a diferenciação precisa entre eles. Este trabalho, analisa e discute os principais modelos de execução adotados (sincronismo virtual, virtual estendido e visão síncrona), esclarecendo suas diferenças.
ABSTRACT
The group-oriented programming paradigm has been proposed to facilitate the development of fault-tolerant distributed applications. The tools utility depends on the execution model adopted to implement group communication, but the difference among them is small and sometime cause confusion. This paper, analyzes and discusses the main execution models adopted (virtual synchrony, extend virtual synchrony and view synchrony), and contribute to turn clear that differences.
1 Universidade Federal de Santa Maria - Centro de Tecnologia - Núcleo de Ciência da Computação, Av. Roraima, S/N, Santa Maria RS, CEP 97105-900 BRASIL. Em doutoramento com suporte financeiro CAPES/PICD-UFSM.
2 Universidade Federal do Rio Grande do Sul - Instituto de Informática - Programa de Pós-Graduação em Computação, Caixa Postal 15064, Porto Alegre RS, CEP 91501-970 BRASIL
1. Introdução
Como forma de construir rápida e facilmente aplicações distribuídas tolerantes a falhas, o paradigma de programação baseado em grupo foi proposto por Birman [BIR87] e, desde então, tem se mostrado uma ferramenta importante [BAB94, COS94, MON00, NUN98]. Este paradigma possibilita a construção de aplicações de forma mais regular (modelagem em grupos) e facilita o controle de concorrência, pois o modelo de comunicação entre os componentes é baseado em multicast confiável (broadcasts na comunicação intra-grupo) operando de forma ordenada em relação às mudanças nos membros dos grupos (importante para obtenção de consistência). As políticas adotadas para implementar estas relações entre a entrega de mensagens (comunicação) e às mudanças na composição do grupo, considerando semânticas e cenários de falhas, são aqui denominadas de modelos de execução. Entretanto, a semelhança entre alguns modelos geram dificuldades de compreensão de algumas soluções e prejudicam ou atrasam o andamento de alguns trabalhos. Com objetivo de minimizar estas dificuldades este artigo analisa três dos principais, e mais semelhantes, modelos de execução citados na literatura: visão síncrona, sincronismo virtual e sincronismo virtual estendido.
A análise é realizada no âmbito de um grupo dinâmico, onde a qualquer momento novos membros podem juntar-se voluntariamente ao grupo (join), ou membros do grupo podem ser excluídos voluntária (leave) ou involuntariamente (devido a defeito ou suspeita de defeito). Um
Serviço de Membership de Grupo (GMS) abstrai da aplicação os eventos de mudanças no
conjunto de membros do grupo dinâmico, provendo uma visão local, ou simplesmente visão do
grupo, composta de membros alcançáveis no grupo, no instante em questão. Naturalmente, as
visões dos diversos membros do grupo devem ser atualizadas de uma maneira coerente, ou seja, os membros que as instalam (que desejam permanecer ou juntar-se ao grupo) devem concordar (agree) com sua composição. De forma geral, um GMS deve fornecer as seguintes propriedades [BIR96]:
1. partindo de uma visão inicial, a cada adição (join) ou exclusão (leave, defeito ou suspeita de defeito) o GMS relata a nova visão do grupo;
2. a visão do grupo não é alterada involuntariamente;
3. todos os membros do grupo observam uma subseqüência contínua da mesma seqüência de visões do grupo, iniciando com a visão em que o membro foi adicionado ao grupo e terminando com aquela em que ele foi excluído;
4. o GMS não atrasa indefinidamente uma mudança de visão associada a um evento;
5. ou o GMS permite o progresso somente num componente primário de uma rede particionada ou, se ele permite o progresso em componentes não primários, todas as visões do grupo são entregues com uma sinalização indicando sua associação, ou não, à partição majoritária da rede.
Como pode-se perceber, o problema da impossibilidade de obtenção do consenso deterministicamente em sistemas assíncronos [FIS85], também reflete na busca de uma solução aceitável para um GMS sob as mesmas condições, pois a propriedade 4 exige o cumprimento em tempo finito; mas esta discussão ultrapassa o escopo deste artigo.
Analisando estas propriedades para o funcionamento de um grupo dinâmico, verifica-se que elas ainda são insuficientes para o suporte de aplicações distribuídas consistentes, pois não há referência à ordem das mensagens em relação às mudanças de visão. Esta omissão permite que uma dada mensagem seja entregue à aplicação, por processos diferentes, em visões diferentes, causando inconsistências na aplicação. A percepção deste problema gerou a proposição de modelos de execução bem definidos e que são alvo da análise realizada neste artigo. As duas seções que seguem analisam e discutem estes modelos. As conclusões desta análise aparecem no final deste texto.
2. Visão Síncrona e Sincronismo Virtual
Para garantir um comportamento consistente do sistema de comunicação de grupo, devem existir relações entre eventos de entrega de mudanças de visões e entrega de broadcasts regulares de mensagens da aplicação aos membros do grupo. Um comportamento desejável é aquele onde dois processos quaisquer sobreviventes de uma mesma visão vi, e pertencentes a uma visão vi+1,
entregam o mesmo conjunto de mensagens na visão vi. Um GMS que comporta-se desta maneira é
chamado de GMS com visão síncrona [BAB95, MAL96, BIR96]. Babaoglu et al. [BAB95] especificaram visão síncrona pelas seguintes propriedades, onde t é um tempo finito:
1. ordem da visão - dois processos instalam as mesmas duas visões na mesma ordem;
2. acordo da visão - se um processo correto p instala a visão v, então para todo processo q
incluído em v, ou: (a) q também instala v num tempo t; ou (b) p instala a visão consecutiva w que exclui q, também num tempo t;
3. integridade da visão - toda visão instalada por um processo p inclui ele próprio;
4. não trivialidade da visão - se um processo p está continuamente habilitado (ou não
habilitado) para comunicar-se com algum outro processo q, então a visão corrente de p incluirá (ou excluirá) q num tempo t;
5. interseção da visão - visões concorrentes não têm membros em comum;
6. acordo na entrega das mensagens - se um processo correto p entrega a mensagem m na
visão v, então para cada processo q incluído em v, ou: (a) q também entrega m num tempo t, ou (b) p instala a visão consecutiva w que exclui q, num tempo t;
7. unidade das mensagens - cada mensagem multicast, se entregue a todos, é entregue
numa única visão;
8. integridade das mensagens - cada processo entrega uma mensagem no máximo uma vez
e somente se algum processo a enviou previamente;
9. terminação na entrega das mensagens - um processo correto sempre entrega suas
próprias mensagens enviadas via multicast.
De modo geral, com exceção da propriedade 5, este comportamento já havia sido definido por Birman [BIR87, BIR96] juntamente com outros comportamentos desejáveis. Entretanto, Birman não usou o termo “visão síncrona”, designando seu modelo de execução como
comunicação virtualmente síncrona ou modelo de execução virtualmente síncrono.
Referenciado neste texto como sincronismo virtual, denominação mais utilizada na literatura, este modelo foi assim definido:
1. cada grupo de processos tem associado a si uma visão do grupo, na qual os membros são listados pela ordem em que eles se juntaram ao grupo;
2. mudanças na visão do grupo são relatadas na mesma ordem para todos os membros; 3. qualquer multicast enviado para o grupo é realizado entre duas visões e para todos os
membros do grupo. O gerenciamento dos membros do grupo é feito com a última visão do grupo recebida pelo processo que enviou a mensagem (envio multicast com visão síncrona);
4. quando um processo junta-se ao grupo e a visão do grupo é relatada aos outros membros, este novo processo pode obter o estado corrente do grupo a partir de algum membro ou conjunto de membros pré-existentes;
5. os multicasts são atômicos e ordenados, podendo esta ordenação ser total ou causal; 6. os defeitos são tratados segundo o modelo fail-stop, ou seja, se um defeito é relatado a
qualquer processo, todos os processos vêem o mesmo evento;
7. um processo torna-se falho devido a um crash ou devido a uma partição na rede.
Neste último caso, quando a partição é reparada, o processo que tornou-se falho, somente pode se reunir ao grupo com um identificador de processo diferente, e após executar um protocolo especial de desconexão, disparado quando o processo perceber que pertence a uma partição minoritária.
Em essência, a idéia básica de Birman foi propor um modelo de execução capaz de garantir uma semântica de comunicação com atomicidade de defeito (Failure Atomicity), ou seja, assim as
mudanças de visão são observadas na mesma ordem por todos os membros do grupo que permanecem conectados e as mudanças de visão são totalmente ordenadas com respeito a todas as mensagens regulares que transitam no sistema. Portanto, dois processos quaisquer que observam juntos duas mudanças de visão consecutivas (vi e vi+1), recebem o mesmo conjunto de mensagens, e
na mesma ordem, no intervalo entre as mudanças de visão. O sincronismo existente para estabelecer a ordem de todos os eventos torna-se virtual quando as propriedades de ordenamento das primitivas de comunicação são enfraquecidas de maneira que não mudem a correção (confiabilidade) do algoritmo mas permitam melhor desempenho.
Exceto pela ordem, o significado de “sincronismo virtual”, no que diz respeito as mudanças de visão, é usado na literatura para referenciar também “visão síncrona”. Isto é possível, mas causa dificuldades na diferenciação entre os modelos. Embora Malloth et al. [MAL95] e Babaoglu et al. [BAB95] tenham definido o paradigma de comunicação com visão síncrona como sendo mais apropriado a um dado contexto, Malloth et al. indicam uma semelhança muito estrita entre os modelos (caracterizam como diferença de designação)3. Entretanto, pouco depois, Malloth
[MAL96] indicou, em nota de rodapé, que a principal diferença entre os dois modelos é que a definição de Birman inclui ordenamento causal e total (propriedade 5), enquanto que a definição de visão síncrona não associa qualquer ordem sobre as mensagens além daquela relacionada às mudanças de visão. Além disto, pela propriedades 5 de visão síncrona e pela implementação da propriedade 7 de sincronismo virtual no Isis [BIR94] (ferramenta proposta pelo grupo do Birman), percebe-se que a definição de visão síncrona também vislumbra operações de forma diferenciada quando a rede torna-se particionada. Em outras palavras, estas propriedades esclarecem as diferenças entre os modelos.
3. Sincronismo Virtual Estendido
Como visto na seção anterior, o modelo de execução virtualmente síncrono suporta falhas de omissão (partição lógica) e de crash, e permite recuperar processos falhos, ou simplesmente excluídos por suspeita, como novos processos. Neste modelo, quando acontece uma partição na rede, somente a partição que contém o fragmento do grupo considerado oficial ou majoritário fica ativa - partição primária. A outra partição (ou partições) é suspensa e seus processos disparam um procedimento de desconexão compulsória [BIR94]. Quando o sistema restabelecer a conexão, haverá atualização nos estados dos novos membros simplesmente pelo recebimento do estado a partir do armazenado na partição primária (aqueles que haviam sido induzidos a sair, reconectam-se com um novo identificador de processo).
Em sistemas distribuídos de larga escala, normalmente numa rede wide-area (WAN), este método de tratar partições não é interessante, pois a baixa confiabilidade dos canais de comunicação e os grandes atrasos na comunicação fazem os particionamentos ocorrem com uma freqüência bem maior do que em redes locais.
Com esta preocupação, vários projetos apontaram para aplicações que poderiam tolerar inconsistências geradas pelo progresso de um componente não primário num sistema particionado (a definição de visão síncrona é resultado desta preocupação). A idéia é que qualquer partição que possa alcançar um acordo interno no seu controle de membros (algoritmo de membership) receba permissão de continuar operando, ao invés de ser forçada a realizar desconexão compulsória.
Aplicações que só são seguras se executadas numa única partição (primária), devem fazer a suspensão da outra partição (ou partições), porém aplicações que primam pela disponibilidade, mesmo que com operação degradada, devem continuar fornecendo (de forma mais restrita) seus serviços na(s) partição(ões) não-primária, reagrupando seus estados quando se desfizer a partição.
Conforme visto na seção anterior, percebe-se que a definição de visão síncrona prevê
3 No original consta: “We found the designation view synchronous more suitable than virtually synchrnous for the
operações em múltiplas partições, entretanto, não especifica como tratar tais defeitos. Já Moser et al. [MOS94], especificaram ao propor uma extensão ao modelo de execução com sincronismo virtual, onde processos falhos podem recuperar-se e múltiplas partições podem continuar operando de modo que não firam as propriedades do sincronismo virtual, se considerada cada partição em separado. Este modelo foi chamado de modelo de execução com Sincronismo Virtual Estendido (Extended Virtual Sinchrony - EVS) e é especificado4 pelas propriedades, e respectivos requisitos, a
seguir relacionadas:
1. Entrega básica - 1.1 Os eventos de um único processo são totalmente ordenados
segundo a relação de ordem parcial “→” (reflexiva, anti-simétrica e transitiva). 1.2 O envio/multicast de uma mensagem sempre precede sua entrega, e a entrega ocorre na mesma visão em que a mensagem foi enviada ou na visão transacional que a segue imediatamente. 1.3 Um processo não envia (ou entrega) a mesma mensagem em duas visões diferentes e dois processos diferentes não enviam a mesma mensagem.
2. Entrega das mudanças de visão - 2.1 Se um processo é membro de uma visão e não a
instala ou não permanece como membro daquela visão, então os outros processos instalam uma nova visão. Isto significa que se um processo falha, então os outros processos irão detectar o defeito e instalar uma nova visão. 2.2 Em qualquer instante, um processo é membro de uma única visão e seus eventos são delimitados pelos eventos de troca de visão percebidos naquela visão. 2.3 Um evento que precede (ou segue) a entrega de uma mensagem de mudança de visão mch por um processo também tem que preceder (ou seguir) a entrega de mch nos outros processos.
3. Auto-entrega - Todo processo entrega as mensagens que ele próprio enviou, a menos
que ele falhe. A entrega pode ocorrer numa visão transacional que consiste somente dele próprio.
4. Atomicidade a defeitos - Se dois processos permanecem juntos de uma visão até a
próxima, então ambos entregam o mesmo conjunto de mensagens naquela visão.
5. Entrega causal - Se a mensagem é enviada antes de outra, na mesma visão, e se um
processo entrega a segunda mensagem, então ele também entrega a primeira.
6. Entrega totalmente ordenada - 6.1 A ordem total é consistente com a ordem parcial.
6.2 Processos que entregam mensagens de mudança de visão no mesmo tempo lógico também entregam suas mensagens no mesmo tempo lógico. 6.3 Processos entregam mensagens em ordem exceto que, na configuração transacional, não haja obrigação para entregar mensagens enviadas por processos que não estejam na visão transacional.
7. Entrega segura - 7.1 Se algum processo entrega uma mensagem segura ms na visão v,
então todos os membros de v entregam ms a menos que ele falhe. 7.2 Se algum processo entrega ms numa visão regular, então todos os processos naquela visão entregam uma mensagem de instalação daquela visão.
O modelo de defeitos do EVS é mais geral do que o de sincronismo virtual, uma vez que permite particionamento de rede e posterior re-conexão, bem como processos defeituosos e sua respectiva recuperação, considerando que eles tenham armazenamento estável. No EVS, um processo que falha, ao recuperar-se instala uma visão contendo somente ele próprio. Após, ele irá juntar-se ao seu grupo novamente, mantendo o mesmo identificador anterior.
4. Conclusões
Ao analisar os três principais modelos de execução adotados pelas ferramentas de comunicação em grupo, percebe-se que em relação ao comportamento com visão síncrona (exceto no suporte a partição de rede) todos os três modelos são idênticos, ou seja, todos relacionam a
4 A notação adotada neste texto difere do original. O que o original referencia como configuração (relação de processos
ordem de entrega das mensagens às mudanças na visão do grupo. Isto ocorre porque esta relação representa o ponto central da idéia de facilitar o controle de consistência num processamento distribuído através da abstração de grupos.
Por outro lado, a diferença marcante entre modelos é:
• sincronismo virtual e visão síncrona – a especificação de ordenamento causal ou total de todos os multicasts enviados e entregues dentro da visão e a possibilidade de visões concorrentes são as principais diferenças entre estes modelos. Sincronismo virtual exige alguma forma de ordenamento interno a cada visão, enquanto visão síncrona não. Além disto, visões concorrentes são permitidas no modelo de visão síncrona mas não no sincronismo virtual.
• sincronismo virtual e sincronismo virtual estendido – o que diferencia os modelos é a possibilidade de visões concorrentes no sincronismo virtual estendido. Sincronismo virtual permite somente que a visão majoritária permaneça funcionando. Em outras palavras, o sincronismo virtual estendido garante as propriedades do modelo de sincronismo virtual a cada uma das suas visões concorrentes, ao invés de somente manter uma visão.
• sincronismo virtual estendido e visão síncrona – assim como no sincronismo virtual, o sincronismo virtual estendido exige a ordenação das mensagens multicast dentro de uma mesma visão, o que difere do modelo de visão síncrona.
Além destas diferenças marcantes, percebe-se que qualquer dos modelos é bastante abstrato e possibilita variadas implementações.
Dos modelos, embora o modelo EVS aparentemente tenha um grande potencial de uso, por considerar partições de rede e manter as mesmas características do sincronismo virtual em cada uma das partições, na prática ele, bem como o de visão síncrona, pode gerar um sério problema de consistência quando for necessário fazer a união (merging) das partições primária e secundárias. Qual partição estará com os dados corretos? Como as inconsistências que podem ter ocorrido ao longo do defeito de partição não tem solução garantida [BIR96], a solução proposta por todos as ferramentas de comunicação de grupo que permitem visões concorrentes é a de passar este problema para a aplicação, simplesmente informando que a operação esta sendo realizada numa visão não primária.
Referências
[BAB94] Babaoglu, O.; Schiper, A.. On Group Communication in Large-Scale Distributed Systems. Bologna-Italy. UBLCS TR94-19, July 1994. (Technical Report)
[BAB95] Babaoglu, O.; Davoli; Montresor, A.. Group Membership and View Synchrony in Partitionable Asynchronous Distributed Systems: Specifications. Dept. of Computer Science of the University of Bologna, UBLCS TR95-18, Nov. 1995. (Tech. Report) [BIR87] Birman, K.P., Joseph, T.A., Reliable Communication in the Presence of Failures. ACM
Trans. on Computer Systems, v.5, n.1, Feb. 1987.
[BIR94] Birman, K.P.; Clark. Performance of the Isis Distributed Computing Toolkit. Dept. of CS at Cornell Univ., Technical Report n.94-1432, June, 1994.
[BIR96] Birman, K.P., Building Secure and Reliable Network Applications. Greenwich: Manning Publications Co., 1996, 591p.
[COS94] Cosquer, F. J. N., E Veríssimo, P., Survey of Selected Groupware Applications and Supporting Platforms. Lisboa-Portugal: INESC Technical Report 21-94, Set., 1994, 33p. [FIS85] Fischer; Lynch; Paterson. Impossibility of Distributed Consensus with One Faulty
[MAL95] Malloth; Felber; Schiper, A.; Wilhelm. Phoenix: A Toolkit for Building Fault-Tolerant, Distributed Applications in Large Scale. EPFL, Lausanne-Switzerland, July 1995.
[MAL96] Malloth. Conception and Implementation of a Toolkit for Building Fault-Tolerant Distributed Applications in Large Scale Networks. EPFL, Lausanne, 1996. (These) [MON00] Montresor, A. System Support for Programming Object-Oriented Dependable
Applications in Partitionable Systems. Department of Computer Science, University of Bologna, p.220, Jan. 2000. (preliminary version of the Ph.D Thesis).
[MOS94] Moser; Amir; Melliar-Smith; Agarwal. Extended Virtual Synchrony. Proceedings of the 14th Conference on Distributed Computing Systems, p.56-65, June, 1994.
[NUN98] Nunes, R.C; Jansch-Pôrto, I. Perspectivas de uso do Modelo de Programação Orientada a Grupo. III Simpósio Nacional de Informática, Setembro, 1998.
