Acceleration Sites

Pudemos verificar que o grupo de experimentos Elastic-Clustered-Stateless apresentou o melhor desempenho para todos os valores de número de clientes e número de iterações, no cenário testado. Este comportamento era esperado, pois neste grupo a carga de trabalho do cliente é distribuída entre vários servidores virtuais, utilizando mecanismos eficientes de balanceamento de carga.

Foi possível observar também a redução no tempo de resposta proporcionado pela adição de novos nós à infraestrutura durante os experimentos do grupo Elastic-Camid-Stateless, mostrando que os mecanismos de coordenação e balanceamento de carga do eCaMid podem responder rapidamente à adição de novos nós. Contudo, os picos no tempo de resposta que ocorreram nos gráficos 4.3a, 4.3c e 4.3d, mostram o custo de coordenação relacionado à adição de novos nós. No entanto, estes picos, em nenhum dos casos, ocasionaram uma perda significativa do desempenho ao longo do experimento.

O grupo de experimentos Elastic-Clustered-Stateful, não apresentou uma melhora signifi- cativa nos tempos de resposta, a não ser quando foi utilizado um valor de 64000 para o parâmetro número de iterações. Esta diferença tornou-se mais evidente conforme o número de clientes se aproximava do maior valor, ou seja, 200 clientes. O ganho no tempo de resposta foi ocasionado pelo uso dos mecanismos de balanceamento de carga, visto que o sistema como um todo possuía um ponto de saturação menor para esta métrica. Já a vazão do sistema não foi afetada, mesmo quando foram usados os maiores valores dos parâmetros de número de iterações e números clientes.

Contudo, torna-se evidente que o mecanismo de compartilhamento de estado entre os nós tem um grande impacto sobre o desempenho do middleware, especialmente se comparado ao grupo de experimentos Elastic-Clustered-Stateless, uma vez que este grupo apresentou valores menores de tempo de resposta e maiores de vazão em todos os experimentos realizados. Este custo é compensado pela capacidade de manter o estado do sistema acessível a todos os nós conforme estes são adicionados à infraestrutura e ao mesmo tempo evitar que este estado seja perdido em caso de desligamento de um nó.

5

Trabalhos Relacionados

Neste capítulo, serão explicados os vários trabalhos que estão relacionados ao eCaMid. Serão examinadas as tecnologias usadas pelo eCaMid para prover seus mecanismos de coorde- nação e compartilhamento de estado. Ao mesmo tempo, discutiremos os vários trabalhos de middleware desenvolvidos nos últimos anos que tem como foco o desenvolvimento e integração e gerenciamento de aplicações no ambiente de computação em nuvem.

5.1

Tecnologias fundamentais usadas pelo ElasticCamid

Na capítulo 3, nós citamos algumas tecnologias que são usadas como blocos básicos para os mecanismos de coordenação e compartilhamento de estado do eCaMid: JGroups, que fornece blocos básicos para implementação de comunicação em grupo (MONTRESOR; DAVOLI; BABAOGLU,2001); e Infinispan, um Datagrid que provê uma API chave-valor para armazenamento de objetos, com suporte a transações, queries, transações, expiração e revogação de dados (MARCHIONI,2012).

5.1.1

JGroups

JGroups(MONTRESOR; DAVOLI; BABAOGLU,2001) é um toolkit que permite a utilização de comunicação em grupo em uma aplicação distribuída. JGroups implementa o padrão Object Group (MAFFEIS et al.,1996), oferecendo para a aplicação um conjunto de callbacks que são utilizados para implementar operações específicas de comunicação em grupo, como criação de View, compartilhamento de estado, recepção de mensagens e detecção de falhas. Um dos componentes principais fornecidos pelo JGroups, é chamado de JGroups (BAN; BLAGOJEVIC,2013). Através do JGroups é possível criar uma conexão a um grupo existente, obter o endereço dos membros existentes, incluindo o próprio endereço e enviar mensagens para os demais membros. As callbacks de comunicação de grupo são registradas pela aplicação através do JGroups.

O JGroups depende de uma pilha de protocolos que, quando agrupados, oferecem um conjunto de funcionalidades a aplicação. Os primeiros protocolos da pilha do JGroups

estão relacionados à camada de transporte da pilha de protocolos TCP/IP, e incluem suporte a TCP e UDP. Logo acima dos protocolos de transporte, existem os protocolos de descoberta de membros, responsáveis por realizar o bootstrapping da comunicação em grupo e detecção de novos membros. Os próximos protocolos da pilha oferecem funcionalidades auxiliares como descoberta de nós indisponíveis, fragmentação e ordenamento de mensagens, garbage collection de mensagens recebidas e outros. Acima destes protocolos auxiliares, estão os serviços de gerenciamento de grupo, que adicionam ou removem membros de um grupo e acionam os callbacks de mudança na View.

Acima dos protocolos e JGroups, JGroups também oferecem um conjunto de blocos básicos, que permitem a utilização das seguintes funcionalidades: comunicação request-reply síncrona ou assíncrona com o uso de Futures, com suporte a unicast e multicast; serviços de locking e contador distribuídos; execução de jobs em cluster; e finalmente, tabelas hash distribuídas.

Apesar de prover inúmeras funcionalidades, vários recursos do JGroups são bastante complexos, e por isso, de difícil utilização em uma aplicação de mais alto nível. O JGroups é útil como parte da camada infraestrutura de um middleware mais complexo (MONTRESOR; DAVOLI; BABAOGLU,2001). O eCaMid utiliza o JGroups justamente neste tipo de situação, onde provê abstrações de mais alto nível como objetos remotos, tarefas e subscribers, e criando a "cola"necessária para utilizar o JGroups para seus mecanismos de comunicação e coordenação de nós de forma transparente para a aplicação.

5.1.2

Infinispan

Mencionamos no capítulo 3, que o Storage Service do eCaMid utiliza o Infinispan (MARCHIONI,2012) para criar uma série de repositórios distribuídos que são utilizados pelos componentes Naming Service, Management Services (Local Manager e Global Manager) e Lifecycle Manager. O Infinispan é utilizado por servidores de aplicação como o JBoss Application Server (CHAUDHARY et al.,2014) para prover mecanismos de cache e armazenamento de dados (como sessões HTTP) em memória, em um ambiente distribuído (SURTANI et al.,2014).

O Infinispan utiliza o JGroups em sua camada de infraestrutura para prover mecanismos de comunicação Peer-to-Peer (P2P) entre nós de um cluster. A partir desta camada de comu- nicação, o Infinispan oferece suporte a replicação de dados, transações distribuídas, queries e mecanismos de expiração de dados. O infinispan pode ser executado como um banco de dados distribuído, ou pode ser funcionar de forma embarcada em uma aplicação.

O infinispan possui três modos de funcionamento: replicação, invalidação e distribuição. No modo de replicação, toda informação armazenada em um nó é replicada a todos os demais nós de um cluster. Este modo de funcionamento depende da utilização de mecanismos de multicastfornecidos pelo JGroups. A escalabilidade do modo replicação é comprometida à medida que mais nós são adicionados ao cluster Infinispan, visto que o custo de sincronização

das informações torna-se mais alto.

No segundo modo de operação, invalidação, o Infinispan não compartilha o estado com outros nós, mas opera como um cache para um banco de dados externo. Objetos extraídos do banco de dados externo são armazenados localmente na memória de um nó. Caso o objeto seja atualizado no banco de dados, uma mensagem de invalidação é enviada para os nós que armazenam o objeto na memória, que removem o objeto do cache.

No modo de distribuição, o Infinispan utiliza uma função de hashing para determinar em que nós uma determinada informação será armazenada. Quando a aplicação armazena um objeto através da API chave-valor, a função de hashing é aplicada a chave. O hash gerado é utilizado para determinar a que segmento o objeto será armazenado. A cada segmento é designado um certo número de nós, chamados de donos. Um dos donos é chamado de dono primário, e os demais são chamados de donos backup. Logo, caso um dono primário torne-se indisponível, um dos donos backup assumirá o lugar de dono primário.

Um conjunto de segmentos constituem um espaço espaço de chave. O tamanho do espaço de chave é configurável, mas adota um valor de 100 segmentos por padrão. À medida que novos nós são adicionados ou removidos de um cluster, o Infinispan distribui os nós existentes de forma homogênea entre os segmentos. A função de hashing utilizada para mapear chaves de objetos tende a distribuir de forma igual os objetos entre os segmentos existentes. Isso é possível porque o Infinispan utiliza uma função de hashing consistente, que é comum em implementações de Distributed Hash Tables (DHTs) encontrados na literatura (SHEN; XU,2008) (GUPTA et al., 2003).

O modo distribuído do Infinispan permite que este possa manter a escalabilidade mesmo que milhares de nós sejam adicionados à infraestrutura, visto que o estado de um objeto é replicado apenas para uma fração dos nós do cluster. O eCaMid adota, por padrão, o Infinispan em seu modo distribuído e embarcado, visando simplificar o processo de implantação do mesmo e tornar possível que sejam adicionados milhares de nós à infraestrutura do middleware.