Avaliação de desempenho

O framework HDDSS proposto nesta tese é adequado para esta e as demais avaliações de desempenho ora apresentadas pela facilidade de composição de cenários com componentes (processos e canais de comunicação) com diferentes níveis de qualidade de serviço, bem como uso de funções de probabilidade adequadas que caracterizem, dentre outros, a carga do sistema e hipóteses de falhas associadas aos componentes. Ainda, podemos caracterizar um conjunto de variáveis locais a cada processo que define informação sensoriada e que os valores variam de acordo com a dinâmica do sistema. Esta funcionalidade nos permite melhor representar o comportamento de sistemas distribuídos self-aware que caracterizamos neste capítulo.

A avaliação de desempenho compara o nosso protocolo com abordagens clássicas nos casos síncrono e assíncrono. No caso síncrono, comparamos com o Periodic Group Creator [28, 61] e no caso assíncrono com o protocolo de comunicação em grupo do sistema operacional distribuído Amoeba [66].

Os protocolos foram escolhidos por sua simplicidade. O Periodic Group Creator utiliza a informação dos relógios físicos locais para a entrega de mensagens, baseado na existência de sincronização periódica. O Amoeba utiliza um sequenciador fixo que determina a ordem da entrega de mensagens.

O Periodic Group Creator utiliza de relógios físicos para prover um protocolo de comuni- cação em grupo baseado no histórico de comunicação, em comparativo a nossa abordagem que utiliza timed causal blocks, combinando a informação de relógios físicos (dado pelos timeouts associados aos blocos) e de relógios lógicos (números de blocos associados as mensagens). Quanto ao Amoeba, o mesmo implementa um paradigma de sequenciador fixo, em que um processo líder define a sequencia das mensagens enviadas ao grupo.

Para simplicidade, denominamos os protocolos acima tão somente de PGC e Amoeba, res- pectivamente, e nosso protocolo de TimedCB.

Caso Síncrono Modelo de Simulação

De modo a caracterizar um ambiente síncrono, configuramos um cenário no qual há uma latência máxima pré-determinada para a comunicação fim-a-fim, o qual pode ser estabelecido por meio de um comutador de rede Ethernet com níveis de qualidade de serviço configurados fim-a-fim, de modo que obtemos uma latência máxima ∆max= 15ms – assumimos uma latência

mínima ∆min= 1ms e que o atraso dos canais de comunicação é muito maior que a latência

de processamento. Cada processo tem acesso a um relógio físico local, e estes mantêm uma taxa de desvio máxima limitada por ρmax da ordem de 10−6. Para operação do protocolo PGC

periódica limita a distorção ε entre os relógios dos processos. Métricas de Desempenho

Para avaliar o desempenho de um protocolo de comunicação em grupo, utilizamos duas mé- tricas: o overhead do protocolo, dado pela carga adicional imposta a rede, ou seja, a quantidade de mensagens de controle em comparativo com o total de mensagens transmitida; e a latên- cia na entrega de mensagens, este medido da recepção da mensagem pelo processo à entrega correspondente pela camada de aplicação.

O overhead do protocolo está associado a necessidade de mensagens de controle para, por exemplo, manter o membership na presença de falhas, ou instalar uma nova visão. Já o atraso na entrega de mensagens pode ser devido a necessidade de se observar condições de guarda que garantam, por exemplo, a estabilidade da mensagem, assegurando o acordo uniforme na entrega de mensagens.

Descrição dos Experimentos

No protocolo PGC, cada processo periodicamente envia mensagens para verificação do membership com período π. O algoritmo de difusão atômica confiável se basea em flooding e a entrega de mensagens utiliza a informação dos relógios físicos, considerando-se a latência máxima da rede, o número máximo de retransmissões k e a distorção máxima ε entre os relógios sincronizados – esta baseada na configuração do protocolo de sincronização de relógios físicos utilizado.

Devemos observar que, na ausência de mensagens de aplicação, o TimedCB utiliza o meca- nismo de time-silence para garantir a completude de blocos a cada período ts. Este mecanismo nos permite monitorar o membership de forma similar ao PGC, e, desta forma, pode-se com- parar os protocolos em cenários que ts = π. Consideramos que o mecanismo de flooding do protocolo PGC tolera tão somente a falha de até 2 processos no caminho (k = 2, devido a re- transmissões) e que faz uso do mecanismo de sincronização de relógios. No TimedCB não é necessária a sincronização de relógios, uma vez que os limites temporais são todos estimados a partir do relógio físico local a cada processo.

Os fatores de simulação considerados são o tamanho do grupo (5, 15 e 25) e o período ts e π (50, 100 e 200ms). De forma a simular a geração de mensagens de aplicação, caracterizamos a carga de trabalho em cada processo por meio de uma função de distribuição de probabilidade de Bernoulli, de modo que simulamos uma taxa média de 10 mensagens enviadas por cada processo ao grupo a cada segundo. As simulações são realizadas em cenários com e sem falhas. Resultados e Discussão

Analisando os resultados do overhead – Figura 5.4.a e 5.4.b, verifica-se que o protocolo Ti- medCB apresenta, na maioria dos casos, overhead menor ou igual ao PGC. Conforme esperado, quanto maior o período (ts do TimedCB e π do PGC), e consequentemente menor a frequência de envio de mensagens de controle, menor será o overhead. Deve-se observar que na presença de falhas, quando é executado o consenso, o protocolo TimedCB aumenta seu overhead, ainda que mantenha-se menor que o PGC.

5.1 COMUNICAÇÃO EM GRUPO 65 Uma vez que o TimedCB utiliza piggy-backing para portar informações de controle do pro- tocolo nas mensagens de aplicação, o mesmo apresenta menor overhead. Mesmo em face de falhas quando o TimedCB executa o consenso para mudança de visão, verifica-se que este é mais eficiente que o PGC, que mantém o overhead constante, determinado pelo período de mo- nitoramento, pela retransmissão do mecanismo de difusão atômica confiável e pelo mecanismo de sincronização de relógios. O TimedCB por sua vez somente gera mensagens de protocolo na ausência de mensagens de aplicação (mecanismo de time-silence) e na ocorrência de falhas (consenso).

Em análise dos resultados para a latência na entrega de mensagens – Figura 5.4.c e 5.4.d (média com o respectivo desvio padrão indicado em linha de intervalo), o PGC com a resiliência escolhida (k = 2) se apresenta mais eficiente que o TimedCB, com comportamento similar nos cenários com e sem falhas. Pode-se observar que o TimedCB apresenta um leve aumento nas latências na presença de falhas, em função do custo de execução do consenso para a entrega das mensagens não estáveis.

(a) Cenário sem falhas: overhead (b) Cenário com falhas: overhead

(c) Cenário sem falhas: latência na entrega de mensagens

(d) Cenário com falhas: latência na en- trega de mensagens

Figura 5.4. Gráficos dos resultados de simulação de TimedCB e PGC em cenário síncrono.

Contudo, o atraso de entrega do TimedCB pode ser otimizado para menores períodos de monitoramento (parâmetro ts do mecanismo de time-silence) ou em presença de maior carga de trabalho da aplicação. Ainda, deve-se notar que esta incrementa no PGC com o aumento da resiliência da difusão atômica confiável (k > 2). Para o TimedCB, o custo sempre é o mesmo

(o da execução do consenso), não importa o número de falhas toleradas (de 1 a n − 1). Desta forma, uma maior resiliência (tolerância de maior quantidade de processos sujeitos a falhas) pode ser obtida de forma mais otimizada pelo protocolo TimedCB. Na ausência de falhas, o protocolo TimedCB se adapta e nenhum preço adicional é pago.

Caso Assíncrono Modelo de Simulação

Um ambiente totalmente assíncrono em que processos imersos na Internet se comunicam entre si por meio de canais de comunicação com latência determinada por meio de uma função de distribuição de probabilidade exponencial (mean = 20ms).

Métricas de Desempenho

As métricas de desempenho são as mesmas utilizadas no caso síncrono: o overhead do protocolo, dado pela carga adicional imposta a rede; e a latência na entrega de mensagens, este medido da recepção da mensagem pelo processo à entrega correspondente pela camada de aplicação.

Descrição dos Experimentos

O protocolo proposto é avaliado em comparação a uma versão do Amoeba que provê acordo uniforme na entrega de mensagens. Neste protocolo, uma mensagem ao grupo é enviada ini- cialmente ao sequenciador, o qual a difunde ao grupo; os processos do grupo precisam enviar o ACK da mensagem ao sequenciador o qual espera por uma maioria (quórum) antes de en- viar uma mensagem de controle permitindo a entrega. Considerando a natureza assíncrona do cenário, e dado o valor escolhido para a latência média dos canais de comunicação (20ms) com comportamento exponencial, estimamos um valor de ∆max= 100ms, a ser utilizado pelo

TimedCBpara suspeita de falha na expiração de um bloco causal.

Os fatores de simulação considerados são o tamanho do grupo (5, 15 e 25) e o período ts(50 e 200ms). De forma a simular a geração de mensagens de aplicação, caracterizamos a carga de trabalho em cada processo por meio de uma função de distribuição de probabilidade de Bernoulli, de modo que simulamos uma taxa média de 10 mensagens enviadas por cada processo ao grupo a cada segundo. As simulações são realizadas no cenários sem falhas. Resultados e Discussão

Analisando os resultados do overhead e da latência na entrega de mensagens – Figura 5.5, verifica-se que o Amoeba produz overhead constante, enquanto o overhead do TimedCB varia conforme a escolha do parâmetro ts e a carga de trabalho imposta. Quanto a latência na entrega de mensagens, os valores de ambos protocolos são similares.

5.1.3 Desenvolvimento de um protocolo de comunicação em grupo auto-configurável