XI Workshop de Testes e TolerÃ¢ncia a Falhas (WTF) - SBRC 2010

More documents

Recommendations

Info

36 Anais 3.4. GossipTask A rotina GossipTask é executada periodicamente, a cada GOSSIP INT ERV AL intervalos de tempo. Ela é responsável pelo envio das mensagens de gossip aos outros processos. A cada execução, a rotina primeiramente verifica se HBT able está vazia. Se sim, não há nada a ser feito, pois nenhum outro processo é conhecido. No caso de existir alguma entrada na tabela, F ANOUT processos são escolhidos aleatoriamente do conjunto de processos conhecidos (ou menos, no caso de o número de entradas na HBT able ser insuficiente). Uma mensagem de gossip é enviada para cada um dos processos selecionados. A mensagem de gossip enviada é construída com as informações contidas na HBT able. Para cada entrada na tabela, uma tupla é adicionada à mensagem. Também é adicionada uma tupla com o ID e heartbeat do processo local. Após o envio da mensagem, o processo incrementa seu valor local de heartbeat. 3.5. BroadcastTask Para que os processos possam se encontrar inicialmente, e para que a saída do detector se estabilize mais rapidamente em caso de um número alto de falhas simultâneas, a rotina BroadcastTask é executada periodicamente. A cada execução, existe a chance de uma mensagem de gossip do algoritmo ser enviada para todos os outros processos, através de um mecanismo de difusão. A probabilidade da difusão ser efetuada é calculada com base em parâmetros do algoritmo e no tempo de chegada da última mensagem de difusão recebida. Esta probabilidade visa evitar difusões simultâneas e muito frequentes. Para a implementação do algoritmo, o JXTA-FD utiliza a mesma função de probabilidade proposta em [van Renesse et al. 1998], p(t) = (t/BCAST MAX P ERIOD) BCAST F ACT OR , onde t é igual ao número de unidades de tempo decorridas da última difusão recebida e BCAST MAX P ERIOD e BCAST F ACT OR são parâmetros do algoritmo. A cada execução da rotina BroadcastTask uma mensagem de gossip é enviada por difusão com probabilidade p(t). Desse modo, o tempo médio entre o envio de difusões depende diretamente da frequência de execução da rotina (controlada pelo parâmetro BCAST T ASK INT ERV AL), do número de processos no sistema e dos parâmetros do algoritmo. BCAST MAX P ERIOD é o intervalo máximo entre cada difusão, e quando t se aproxima deste valor, a probabilidade p(t) tende a 1. BCAST F ACT OR deve ser um valor real positivo, e determina o quão antes de BCAST MAX P ERIOD as difusões tendem a ser enviadas. Quanto maior o valor de BCAST F ACT OR, mais próxima do valor BCAST MAX P ERIOD fica a duração do intervalo esperado entre as difusões. Como exemplo, para os valores BCAST T ASK INT ERV AL de 1 unidade de tempo, BCAST MAX P ERIOD de 20 unidades de tempo e um conjunto de 1000 processos, para se obter um intervalo de aproximadamente 10 unidades de tempo entre uma difusão e a próxima, BCAST F ACT OR deve ser aproximadamente 10.43 [van Renesse et al. 1998]. 3.6. CleanupTask A rotina CleanupTask é responsável por remover entradas antigas da HBT able do processo local. A cada CLEANUP INT ERV AL unidades de tempo, a tabela é percorrida e entradas que não foram atualizadas a mais de REMOV E T IME unidades de
XI Workshop de Testes e Tolerância a Falhas 37 tempo são excluídas. Este mecanismo é importante pois processos considerados suspeitos também são utilizados pelo mecanismo de gossip como possíveis alvos, e uma tabela contendo um número muito alto de entradas inválidas (processos falhos) pode causar um impacto negativo na exatidão do detector. O valor REMOV E T IME é um parâmetro de configuração do algoritmo. 3.7. Saída do Detector A qualquer momento durante a execução do algoritmo, um processo pode consultar seu detector local pelo conjunto de processos suspeitos ou corretos. Para determinar estes processos, a tabela HBT able é percorrida e, para cada entrada, o tempo decorrido desde a sua última atualização é calculado. Se este tempo for maior ou igual a SUSP ECT T IME, o processo é considerado suspeito. Caso contrário, ele é considerado correto. 4. Implementação e Resultados Experimentais O serviço JXTA-FD foi implementado como um módulo (Module) para a plataforma JXTA, versão 2.5, utilizando a linguagem Java. O monitoramento entre peers é feito dentro do contexto de um Peer Group, e um módulo do JXTA-FD deve ser carregado e inicializado para cada grupo monitorado. Somente peers que estejam executando o módulo participam do algoritmo. A qualquer momento, um peer pode consultar seu módulo de detecção pela lista de processos corretos ou suspeitos. O comportamento do serviço pode ser controlado através de alguns parâmetros de configuração. Os parâmetros mais importantes são três: GOSSIP INT ERV AL, F ANOUT e SUSP ECT T IME. O primeiro controla o intervalo entre o envio de mensagens de gossip pela rotina GossipTask. O segundo controla quantas mensagens são enviadas em cada execução da mesma. Por último, SUSP ECT T IME determina quantas unidades de tempo sem atualização de heartbeat são necessárias para se considerar um peer como suspeito. Os parâmetros do serviço para um dado grupo devem ser decididos a priori, antes da inicialização do mesmo. 4.1. Avaliação e Resultados Experimentais Para a avaliação do serviço de detecção de falhas proposto, experimentos foram realizados para a implementação na plataforma JXTA e para um simulador, implementado com o uso da biblioteca de eventos discretos SMPL [MacDougall 1997]. Nos experimentos realizados, foram avaliadas duas estratégias diferentes para a configuração do detector. Na primeira, a cada rodada do algoritmo é enviada apenas uma mensagem de gossip. Para aumentar a exatidão do detector, o intervalo entre o envio das mensagens de gossip (parâmetro GOSSIP INT ERV AL) é reduzido. Na segunda estratégia, o intervalo entre o envio de mensagens de gossip é mantido fixo enquanto o fanout do algoritmo (parâmetro F ANOUT ), ou seja, o número de mensagens de gossip enviadas a cada rodada, é incrementado. As comparações são feitas de modo que a banda utilizada, isto é, a quantidade de tuplas do tipo enviada pelos peers em um dado intervalo de tempo, seja a mesma para os dois casos. Estas estratégias são representadas nos gráficos por Gossip e Fanout, respectivamente. Para a simulação do atraso e perda de mensagens, foi implementado como um parâmetro da execução dos experimentos um valor que controla a porcentagem de mensagens perdidas pelos peers. Cada mensagem tem uma chance de ser descartada. Esse
Page 1 and 2: XXVIII Simpósio Brasileiro de Rede
Page 3 and 4: XI Workshop de Testes e Tolerância
Page 13: XI Workshop de Testes e Tolerância
Page 16 and 17: 4 Anais tais problemas. Portanto, h
Page 18 and 19: 6 Anais consenso para o modelo ass
Page 20 and 21: 8 Anais em andamento (por exemplo,
Page 22 and 23: 10 Anais cada partição síncrona,
Page 24 and 25: 12 Anais A tarefa T 4 é executada
Page 26 and 27: 14 Anais • Assumimos que o proces
Page 28 and 29: 16 Anais Veríssimo, P. and Casimir
Page 30 and 31: 18 Anais Entretanto, em caso de fal
Page 32 and 33: 20 Anais à aplicação: SafeSendT
Page 34 and 35: 22 Anais Na fase de inicialização
Page 36 and 37: 24 Anais acesso a C e nem a C d . E
Page 38 and 39: 26 Anais Prova. 1. Se t + 1 /∈ C
Page 40 and 41: 28 Anais algoritmo de término. Vá
Page 42 and 43: 30 Anais instantânea. Além disso,
Page 44 and 45: 32 Anais [Chandra and Toueg 1996].
Page 46 and 47: 34 Anais Every JXTA-FD instance exe
Page 50 and 51: 38 Anais mecanismo foi adotado para
Page 52 and 53: 40 Anais Tempo de Detecção e Recu
Page 54 and 55: 42 Anais nout em relação à exati
Page 56 and 57: 44 Anais Fischer, M. J., Lynch, N.
Page 58 and 59: 46 Anais 1. Introdução Sistemas d
Page 60 and 61: 48 Anais canais de comunicação co
Page 62 and 63: 50 Anais Figura 1. Interface do QoS
Page 64 and 65: 52 Anais onde as aplicações solic
Page 66 and 67: 54 Anais • QOSP _REGIST ER: Esta
Page 68 and 69: 56 Anais O DSCP utilizado para o Se
Page 70 and 71: 58 Anais seu destino, enquanto que
Page 99 and 100:
XI Workshop de Testes e Tolerância
Page 101:
Page 104 and 105:
92 Anais geralmente baseados nos gr
Page 106 and 107:
94 Anais Os parâmetros podem repre
Page 108 and 109:
96 Anais Um exemplo de configuraç
Page 110 and 111:
98 Anais E. Evolução O Módulo Ev
Page 112 and 113:
100 Anais Tabela 1: Cobertura obtid
Page 114 and 115:
102 Anais ineditismo, o que parece
Page 116 and 117:
104 Anais Evaluation of Novel Appro
Page 118 and 119:
106 Anais protocolo; (2) verificaç
Page 120 and 121:
108 Anais Uma MEF pode ser represen
Page 122 and 123:
110 Anais se dá em uma seqüência
Page 124 and 125:
112 Anais 1 2 3 4 5 Data: MEF M e C
Page 126 and 127:
114 Anais (a) Variação do número
Page 128 and 129:
116 Anais Fujiwara, S., Bochman, G.
Page 131 and 132:
Page 133 and 134:
Page 135 and 136:
Page 137 and 138:
Page 139 and 140:
Page 141 and 142:
Page 143 and 144:
Page 145 and 146:
Page 147 and 148:
Page 149 and 150:
Page 151 and 152:
Page 153 and 154:
Page 155 and 156:
Page 157:
Page 161 and 162:
Page 163 and 164:
Page 165 and 166:
Page 167 and 168:
Page 169 and 170:
Page 171 and 172:
Page 173 and 174:
Page 175 and 176:
Page 177 and 178:
Page 179 and 180:
Page 181 and 182:
Page 183 and 184:
Page 185 and 186:
Page 187 and 188:
Page 189:
show all

XI Workshop de Testes e TolerÃ¢ncia a Falhas (WTF) - SBRC 2010

Create successful ePaper yourself

Delete template?

Save as template?