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
3e Fabio Kon
41
Universidade Federal de Pernambuco
2Universidade de Pernambuco
3Universidade Federal do ABC
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
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
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
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
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
Arquitetura do Serviço de
Gerenciamento de Membros
Tratador de
Defeitos 1
…
Processo Monitorado
Disseminação
de Informação
Gerenciamento
de Membros
Monitor
Detector
Cumulativo
de Defeitos
Detector de Defeitos
Tratador de
Defeitos 2
Tratador de
Defeitos N
Nó1
Nó3
Nó4
Nó2
Cada nó roda uma instância do serviço
de gerenciamento de membros
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
Detector de Defeitos
Coleta dados
sobre
K
processos
−
Envia heartbeats
−
Disseminados
periodicamente (
T
hb)
−
se p
1monitora p
2então há uma conexão
TCP entre eles
Detector Cumulativo de Defeitos
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
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
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
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
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
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
➔
É monitorado por
➔
Foi pedido monitoramento
Legenda:
Exemplo com K = 4
A
B
C
D
E
F
G
Quantidade de nós
que monitora
A
é
igual a
K
➔
É monitorado por
➔
Foi pedido monitoramento
Legenda:
Exemplo com K = 4
A
B
C
D
E
F
G
Dado defeito em
G
,
é desfeita a relação
de monitoramento
➔
É monitorado por
➔
Foi pedido monitoramento
Legenda:
Exemplo com K = 4
A
B
C
D
E
F
G
A
solicita a
F
que o
monitore. A união de
processos que
monitoram
A
e aos
quais ele solicitou é
igual a
K
➔
É monitorado por
➔
Foi pedido monitoramento
Legenda:
Exemplo com K = 4
A
B
C
D
E
F
G
Enquanto a união
dos conjuntos citados
não for menor que
K
,
não é possível fazer
mais solicitações
➔
É monitorado por
➔
Foi pedido monitoramento
Legenda:
Exemplo com K = 4
A
B
C
D
E
F
G
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
➔
É monitorado por
➔
Foi pedido monitoramento
Legenda:
Exemplo com K = 4
A
B
C
D
E
F
G
Após espera,
A
pode
fazer nova solicitação
de monitoramento
➔
É monitorado por
➔
Foi pedido monitoramento
Legenda:
Exemplo com K = 4
A
B
C
D
E
F
G
Sendo aceita, o
número de processos
que monitoram
A
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
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
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,
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
Falhas em Blocos Separados
100 falhas
separadas em 2 blocos
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
Com Falhas
Usando 200 processos, com 10% de falhas injetadas, crescimento de 4,4%
Com 50% de falhas, crescimento de 11,79%
Falhas em Blocos Separados
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
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);
