Coordenação

O eCaMid funciona como uma série de nós agrupados em uma entidade lógica deno- minada cluster. Este cluster precisa de meios eficientes para troca de mensagens entre nós, utilizando diferentes estratégias de comunicação, como um-para-um, um-para-muitos e muitos- para-um. Também precisa ter a capacidade para verificar que membros estão ativos, quando um novo nó é adicionado ou quando um nó deixa o grupo, com a capacidade de executar ações específicas quando algum desses eventos acontece. O gerenciamento de membros do eCaMid é realizado através da utilização do framework de comunicação em grupo.

Este framework utiliza o padrão de projeto Object Group (MAFFEIS et al.,1996), mas ao invés de gerenciar réplicas de objetos remotos, este gerencia nós de um cluster. Cada membro do clusterrecebe um identificador. O conjunto de todos os membros ativos do cluster compõem uma View. Quando algum membro entra ou sai do grupo, uma nova View é gerada. O framework de comunicação em grupo provê uma série de gatilhos para execução de ações quando determinados eventos ocorrem no cluster, como a geração de uma view ou a falha de comunicação de um dos membros do nó.

Algumas ações precisam ser executadas de forma única em todo o cluster. O padrão de projeto Leader Election (HOMER et al., 2014) define um processo que é utilizado para determinar um líder, o membro do cluster que realizará uma determinada tarefa em favor de todos os outros membros. O eCaMid utiliza o evento de aquisição da view para executar uma ação de atribuição de papéis específicos a cada nó.

Um desses papéis é chamado de coordenador, um papel atribuído pelo próprio framework de comunicação em grupo. O coordenador é o membro mais antigo do cluster e é responsável

por executar tarefas específicas para o próprio framework. Os demais membros do cluster são chamados workers e são responsáveis por receber chamadas de método remotas. Um outro papel definido é o Task Executor, que define um nó responsável por gerenciar os agentes que executarão tarefas periódicas no cluster.

Além dos mecanismos de gerência de grupo, o eCaMid possui dois componentes que oferecem uma infraestrutura alternativa que pode ser usada para comunicação intra-cluster. Enquanto o Client Request Handler e Server Request Handler são usados na comunicação cliente-servidor, o Group Channel é usado para enviar mensagens a outros membros do grupo, utilizando o identificador do nó ao invés do endereço de rede.

O Group Channel suporta o estilo de comunicação unicast (um para um, com semântica request-reply) e multicast (um para muitos, com semântica fire-and-forget). O Cluster Request Handler é o componente de infraestrutura que recebe mensagens do Group Channel e as encaminha para outros componentes da camada de distribuição, como o Invoker e Cluster Event Bus. O Group Communication Framework age como um intermediário entre esses dois componentes. A Figura 3.3 ilustra este estilo de comunicação.

Figura 3.3: Estilos de comunicação um-para-um e um-para-muitos

3.4.1.1 Comunicação Publish/subscribe

Os componentes Group Channel e Cluster Request Handler são dois componentes fundamentais para a execução de tarefas assíncronas no eCaMid. No entanto, ambos são componentes de baixo nível. Os componentes da camada de serviço e a aplicação necessitam de um modelo de programação mais abstrato.

Uma forma de implementar a comunicação assíncrona entre os diversos componentes é através da troca de mensagens. Utilizando um modelo Publish/subscribe, um publisher pode enviar uma mensagem específica sem saber ao certo o destinatário. As mensagens são entregues a todos os subscribers interessados na mesma. A Figura 3.4 mostra os elementos de domínio

deste subsistema.

Figura 3.4: Modelo de domínio do subsistema de publish-subscribe

No escopo do eCaMid, as mensagens trocadas entre componentes são chamadas de eventos. Eventos podem ter três naturezas: locais, onde o evento publicado por um publisher é entregue para todos subscribers no mesmo nó; eventos de broadcast, onde o evento publicado em um publisher é destinado aos subscribers em todos os nós do middleware; e eventos de cluster, onde o publisher em um nó publica uma mensagem que deve ser entregue a todos os publishers localizados em um dos nós membros do cluster, de forma a balancear a entrega de requisições entre nós.

O componente responsável por publicar os eventos e encaminhar aos subscribers inte- ressados chama-se Cluster Event Bus. Este componente é composto de duas partes: o Message Router, responsável por enviar e receber mensagens para os destinatários locais e remotos, encapsulando as chamadas ao Group Channel e o Cluster Request Handler; o Local Event Bus é responsável por entregar os eventos recebidos a todos os subscribers localizados neste nó.

A principal finalidade do mecanimso de comunicação Publish-Subscribe é prover um modelo de comunicação para os componentes de monitoramento do eCaMid, pertencentes ao Local Manager e Global Manager que se comuniquem de forma fracamente acoplada e sem contenção de recursos. No entanto, esses mecanismos também estão disponíveis para aplicações que utilizem o eCaMid que desejem utilizar um mecanismo de comunicação assíncrona mais simples, sem todas as garantias e complexidades de um middleware orientado a mensagens.

3.4.1.2 Escalonamento de tarefas periódicas

O eCaMid e a aplicação podem necessitar de uma infraestrutura para executar tarefas periódicas. A coordenação e execução dessas tarefas é responsabilidade do componente Task

Figura 3.5: Modelo de domínio do subsistema de escalonamento de tarefas

Scheduler. O modelo de domínio para o subsistema de escalonamento de processos é mostrado na Figura 3.5.

As tarefas periódicas podem ser classificadas como tarefas locais e tarefas de cluster. Tarefas locais são executadas no contexto de execução de cada um dos nós, enquanto tarefas de clustersão executadas em um nó específico em prol de todo o cluster. Como exemplo de tarefas periódicas locais, temos o processo de extração das métricas de uso de CPU e memória que é executada em cada nó pelo Local Manager. Como exemplo de tarefa de cluster, temos um dos agentes do Cluster Manager que solicita periodicamente do provedor de nuvem o status de todas as máquinas virtuais usadas pelo middleware.

O componente Task Scheduler está presente em todos os nós e pode executar qualquer tipo de tarefa periódica. O Task Scheduler recebe eventos relacionados à criação de uma view a partir do Task Coordination Observer. O evento de criação de view informa para o Task Scheduler quais os membros atuais do cluster. Caso o Task Scheduler atual seja o coordenador da view, este será o responsável por executar as tarefas periódicas do cluster. Caso contrário, apenas as tarefas locais são executadas. O Task Scheduler também responde a eventos de desligamento do nó, interrompendo a execução de tarefas locais e de cluster de maneira graciosa.