Um Serviço Escalável e Robusto para Gerenciamento de Membros em Grades Computacionais de Grande Escala* Fernando Castor Filho 1, Rodrigo Castro 2, Augusta Marques 2, Francisco M. Soares-Neto 2, Raphael Y. Camargo 3 e Fabio Kon 4 1 Universidade Federal de Pernambuco 2 Universidade de Pernambuco 3 Universidade Federal do ABC 4 Universidade de São Paulo *Financiado pelo CNPq/Brazil, processos #481147/2007-1 e #550895/2007-8
Falhas em Grades Problema importante Desperdício de recursos computacionais e de rede Perda de tempo (recursos podem precisar ser reservados novamente) Escala piora o problema Defeitos se tornam comuns Grades oportunistas Infraestrutura de grade compartilhada Nós saem/falham com frequência Tolerância a falhas pode permitir uso mais eficiente da grade 2
Alcançando Tolerância a Falhas Primeiro passo: detectar defeitos... Então fazer algo sobre isso Outros nós da grade também devem ter consciência da situação Senão, o progresso pode ser prejudicado Cada nó deve ter uma visão atualizada dos membros do grupo Em termos de processos corretos e defeituosos 3
Requisitos para Gerenciamento de Membros em Grades 1. Escalabilidade 2. Autonomia 3. Eficiência 4. Capacidade de lidar com dinamismo 5. Independência de plataforma 6. Distribuição (Descentralização) 7. Facilidade de Configuração 4
Nossa Proposta Um serviço de gerenciamento de membros que satisfaça os requisitos mencionados Foco em manter uma visão consistente do grupo a todos os processos mesmo com falhas catastróficas Combina avanços recentes em Disseminação Epidêmica Detectores Adaptativos Extensão de proposta de [Castor et al., 2008] 5
Disseminação de Informação Epidêmica/Baseada em Boatos Baseada na maneira como doenças infecciosas se espalham Periodicamente, cada participante infecta aleatoriamente um de seus vizinhos Infecta = envia informação que (potencialmente) modifica seu estado Protocolos de consistência fraca Altamente escaláveis e robustos 6
Arquitetura do Serviço de Gerenciamento de Membros Nó2 Detector de Defeitos Nó1 Tratador de Defeitos 1 Tratador de Defeitos 2 Detector Cumulativo de Defeitos Disseminação de Informação Tratador de Defeitos N Monitor Gerenciamento de Membros Nó4 Nó3 Processo Monitorado Cada nó roda uma instância do serviço de gerenciamento de membros 7
Gerenciamento de Membros Trata pedidos de inclusão ao grupo Dissemina informação sobre novos membros Informa-os sobre membros existentes Remove membros defeituosos do grupo Processos defeituosos podem também voltar Mecanismo de época 8
Detector de Defeitos Coleta dados sobre K processos Envia heartbeats Disseminados periodicamente (T hb ) se p 1 monitora p 2 então há uma conexão TCP entre eles Detector Cumulativo de Defeitos Outros detectores adaptativos podem ser usados 9
Coletando Informação Suficiente Detectores adaptativos precisam receber informação sobre processos monitorados regularmente Também se aplica a detectores cumulativos Protocolos epidêmicos tradicionais não são regulares Solução: relações de monitoramento persistentes entre processos Estabelecidas aleatoriamente Exibem as propriedades desejadas de protocolos epidêmicos 10
Tratadores de Defeitos Para cada processo monitorado, um conjunto de limiares é configurado Por exemplo: 85, 90, e 95% Um tratador é associado a cada um Várias estratégias de tratamento são possíveis Cada uma é executada quando o limiar correspondente é alcançado É fácil definir tratadores específicos por aplicação 11
Disseminação de Informação Responsável por espalhar a informação Sobre nós falhos (mensagens específicas) Importante para tratamento de defeitos Sobre membros corretos (de carona em mensagens de heartbeat) Velocidade de disseminação é baseada no parâmetro J J deve ser O(log(N)) 12
Implementação Escrita em Lua Compacta, eficiente, extensível, e independente de plataforma O serviço é empacotado como um módulo Lua reusável Usa um ORB CORBA leve (OiL) para IPC Também escrito em Lua Aproximadamente 80KB de código-fonte 13
Garantindo um Mínimo de Processos Monitores Caso um processo p detecte que um processo q que o monitora falhou Solicita a outro processo s que o monitore s escolhido aleatoriamente Caso s também tenha falhado Não tenta novamente de imediato Poderia resultar em muitas mensagens adicionais injetadas na rede 14
Garantindo um Mínimo de Processos Monitores Garante que cada processo seja monitorado por pelo menos K outros (parâmetro H) Garante a robustez do grupo Mecanismo simples e econômico Cada processo executa a cada T hb segundos uma sequência de passos 15
Exemplo com K = 4 B C D E Quantidade de nós que monitora A é igual a K F G A Legenda: É monitorado por Foi pedido monitoramento 16
Exemplo com K = 4 B C D E Dado defeito em G, é desfeita a relação de monitoramento F G A Legenda: É monitorado por Foi pedido monitoramento 17
Exemplo com K = 4 B C D E F A solicita a F que o monitore. A união de processos que monitoram A e aos quais ele solicitou é igual a K G A Legenda: É monitorado por Foi pedido monitoramento 18
Exemplo com K = 4 B C D E F Enquanto a união dos conjuntos citados não for menor que K, não é possível fazer mais solicitações G A Legenda: É monitorado por Foi pedido monitoramento 19
Exemplo com K = 4 B C D E G F Sendo detectado defeito em F, espera antes de fazer novos pedidos, de forma a não sobrecarregar a rede em casos de falhas catastróficas A Legenda: É monitorado por Foi pedido monitoramento 20
Exemplo com K = 4 B C D E Após espera, A pode fazer nova solicitação de monitoramento F G A Legenda: É monitorado por Foi pedido monitoramento 21
Exemplo com K = 4 B C D E F Sendo aceita, o número de processos que monitoram A volta a ser igual a K G A Legenda: É monitorado por Foi pedido monitoramento 22
Heartbeats informativos O serviço proposto garante que todos processos são monitorados Não garante que todos monitorem processos Podem haver processos que nunca recebam informações sobre novos processos Solução A cada T hb segundos, envia-se um heartbeat para um processo p monitorado Função meramente informativa Processo p escolhido aleatoriamente 23
Heartbeats Informativos Resultam em custo constante por processo (em termos de mensagens enviadas por turno) Custo pode ser significativo Para valores baixos de K, custo alto (se K = 4, custo equivale a aumentar em 25%) Para valores altos (K>10), custo pequeno Pode ser configurados para enviar HBIs com menor frequência 24
Avaliação Meta principal: avaliar escalabilidade e robustez 40-200 nós concorrentes Distribuídos entre sete máquinas equipadas com 1GB de RAM, rodando Kubuntu 8.04 Rede 100Mbps Fast Ethernet WAN Emulada latência = 500ms e jitter = 250ms Parâmetros T hb = 2s, K = 4, J = 6, Comparado com o GMS de Horita et al. 25
Robustez Capacidade de criar novas relações de monitoramento quando falhas catastróficas ocorrem Para cada processo p Garantir que o número de processos que o monitoram mais o número de processos a quem ele pediu que o monitorassem seja igual a K Não deve resultar em processos isolados ou monitorados por menos que K processos 26
Falhas em Blocos Separados 100 falhas separadas em 2 blocos Com o GMS proposto, todos mantiveram H=4 Retorno a H=4 em aproximadamente 4 seg. 27
Falhas em Blocos Separados Número de mensagens mantém-se o mesmo no serviço proposto, mas serviço básico e Horita sofrem reduções 28
Escalabilidade Avaliação baseada na quantidade média de mensagens enviadas 40, 80, 120, 160, e 200 instâncias do serviço Cada experimento com 10000 turnos de trocas de mensagens 29
Sem Falhas Mesmo com aumento de quantidade de processos, a média 30 de mensagens por processo mantém-se constante
Com Falhas Usando 200 processos, com 10% de falhas injetadas, crescimento de 4,4% Com 50% de falhas, crescimento de 11,79% 31
Falhas em Blocos Separados 50% de falhas inseridas em dois grupos de 25% 32
Comparação de Uso de HBIs Produção de mais mensagens é um trade-off válido pela rapidez na descoberta de mudanças no grupo 33
Conclusões Principal contribuição: um serviço de gerenciamento de membros robusto e escalável garantindo que a rede se mantém estável; e que a estabilidade é alcançada rapidamente; de maneira escalável (sem exigir muito mais mensagens para isso); Trabalho atual: Integração com plataformas de Middleware (InteGrade e OurGrid) Utilização com outros detectores adaptativos 34
Obrigado! Dúvidas? Contato: Francisco M. Soares-Neto fmssn@dsc.upe.br 35