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

More documents

Recommendations

Info

160 Anais Figura 3. Gráfico comparativo dos protótipos de replicação. O aumento no tempo de execução imposto pelo mecanismo é justificável porque a adição de uma fase representa um aumento na execução geral de mensagens, pois cada fase adicionada ao fluxo representa mais um passo de execução na engine do Axis2. Outro aspecto importante é a serialização do contexto. À medida que as invocações são feitas e mais informações são adicionadas à sessão, o contexto aumenta de tamanho de forma que a sua serialização representa um dos principais aspectos de consumo de tempo no modelo proposto e explica o desvio padrão relativamente alto, já que as últimas requisições da série demandaram um maior esforço de serialização em relação às requisições iniciais. Testes foram realizados na presença de mais de uma réplica para que o overhead da comunicação em grupo pudesse ser determinado. Assim, com a adição de réplicas, o mecanismo de comunicação em grupo é efetivamente utilizado, de forma que o tempo de execução de cada mensagem, além dos fatores considerados anteriormente, é acrescido pelo envio das mensagens de atualização de estado para cada réplica, além do mecanismo de monitoração de estado dos membros do grupo, que cresce conjuntamente ao número de cópias. Nesse modelo, o overhead máximo foi atingido na presença de 4 réplicas, ou seja, 1 réplica primária e 3 réplicas backups. Para esse cenário com 4 cópias, o tempo médio foi de 68,70±5,91 milissegundos, o que implica em um aumento de 14,5% em relação à replicação passiva com o mesmo número de réplicas e 46,9% em relação ao modelo sem replicação. Por último, foram realizados testes em uma rede LAN, de forma que um teste mais próximo de um ambiente real fosse mensurado. O resultado dos testes pode ser observado na figura 4. A média para a replicação passiva com duas réplicas foi 267,09 milissegundos, enquanto que o resultado para três réplicas foi 274,14 milissegundos , o que representa um aumento de 2,64% entre as configurações. Já a replicação híbrida teve média de 270,56 milissegundos para duas réplicas e 280,26 milissegundos para três. A diferença, nesse contexto, foi de 3,59%,demonstrando que o tempo de execução dos protótipos não aumenta bruscamente, em rede, com a adição de réplicas.
XI Workshop de Testes e Tolerância a Falhas 161 Figura 4. Resultado dos testes em rede. 5.3. Conjunto de Testes - Manutenção do Estado e Consistência Para o teste de manutenção de estado, a análise foi feita fazendo a réplica primária falhar continuamente e aplicando a operação de listar o número de itens no novo primário eleito. Para o teste de consistência, a listagem de elementos foi invocada em cada novo primário e armazenada para posterior comparação. O teste de manutenção de estado funcionou dentro do esperado, de forma que cada réplica apresentou 3000 itens em seus vetores após a falha do servidor primário. O teste de consistência também foi bem sucedido. Para comparar os estados, após as invocações, a operação de listagem de conteúdo foi invocada em cada réplica e seus resultados armazenados para que pudessem ser comparados através da API Java. Os testes demonstraram que o maior overhead da replicação foi a comunicação em grupo. A pilha de protocolo utilizada nos testes foi a pilha padrão do JGroups, de forma que é necessário estudá-la melhor e customizá-la a fim de apresentar um desempenho mais satisfatório. Como todas as modificações foram feitas na arquitetura Axis2, nenhuma mudança foi necessária diretamente no serviço web, de forma que, nesse aspecto, este trabalho garante que serviços web autônomos e heterogêneos sejam replicados de uma maneira transparente. 6. Conclusão e Trabalhos Futuros Este trabalho propôs analisar a maneira pela qual os métodos de replicação são adotados em conjunto aos serviços web. Os protótipos implementados demonstraram que a replicação em serviços é praticável, inclusive no que se refere à manutenção e consistência de estado entre as réplicas. A principal fonte de latência encontrada foi a comunicação em grupo, demonstrando que a primitiva multicast e o controle de membros de grupo podem ser bastante dispendiosos. Dentre os trabalhos futuros, destaca-se uma melhor análise da pilha de protocolos do JGroups para obter um melhor desempenho, além de analisar a escalabilidade da solução proposta. Outrossim é a implementação de outros protocolos de replicação, tais como replicação semi-passiva e ativa.
Page 1 and 2:
XXVIII Simpósio Brasileiro de Rede
Page 3 and 4:
XI Workshop de Testes e Tolerância
Page 5 and 6:
Page 7 and 8:
Page 9 and 10:
Page 11 and 12:
Page 13:
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 48 and 49:
36 Anais 3.4. GossipTask A rotina G
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 73 and 74:
Page 75 and 76:
Page 77 and 78:
Page 79 and 80:
Page 81 and 82:
Page 83 and 84:
Page 85 and 86:
Page 87 and 88:
Page 89 and 90:
Page 91 and 92:
Page 93 and 94:
Page 95 and 96:
Page 97 and 98:
Page 99 and 100:
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: XI Workshop de Testes e Tolerância
Page 157: XI Workshop de Testes e Tolerância
show all

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

Create successful ePaper yourself

Delete template?

Save as template?