O Kerrighed implementa um balanceamento de cargas de trabalho compostas de aplicações paralelas, baseando-se em memória compartilhada ou em modelos de programação de message passing. Um desafio é migrar eficientemente processos utilizando message passing. Processos que se comunicam utilizando interfaces padrão tais como sockets ou pipes devem ser capazes de serem transparentemente migrados num cluster. Além disso, migrar processos não deveria alterar o desempenho de sua comunicação com outros processos.
As interfaces padrão de comunicação tais como pipes e sockets, utilizam um fluxo binário para realizar a comunicação entre processos. O Kerrighed propõe um conceito de fluxo dinâmico, sobre o qual interfaces padrão de comunicação são desenvolvidas. As extremidades desses fluxos são chamadas KerNet sockets e os mesmos podem ser migrados dentro do cluster. Fluxos dinâmicos e KerNet sockets são implementados no topo de um sistema portável de comunicação de alta performance, provendo uma interface de envio/recepção para transferir dados entre diferentes nós num cluster. Os fluxos dinâmicos e o KerNet sockets são implementados na camada KerNet. Ela é um serviço distribuído que provê gerenciamento global de fluxos em todo cluster. Serviço de Fluxo Dinâmico
Todos os clusters baseiam-se num sistema de comunicação ponto a ponto de baixo nível. Na maioria das vezes, tais sistemas proveem propriedades tais como confiabilidade, alta performance e ordenação de mensagens. Assim, quando a migração não ocorre, as aplicações devem ser capazes de tirar vantagem dessas propriedades.
O Kerrighed possui um sistema de comunicação de baixo nível que é confiável e mantém a ordem das mensagens enviadas entre dois nós.
O fluxo dinâmico KerNet é uma abstração de fluxo com dois ou mais KerNet sockets definidos e com nenhum nó especificado. Quando necessário, um KerNet socket é temporariamente associado a um nó. Por exemplo, quando dois KerNet sockets estão conectados, uma operação de envio/recepção pode ocorrer.
161
Seguem alguns dos principais parâmetros do fluxo dinâmico KerNet: Tipo de fluxo
Número de sockets
Número de sockets conectados Filtro de dados
Fluxos são controlados por um grupo de gerenciadores, cada um deles localizado num nó do cluster. Estruturas de dados do kernel relacionadas com fluxos dinâmicos são mantidas num diretório global que é distribuído entre os nós cluster. Dados como a localização do nó de um KerNet socket, são atualizados em todos nós ativos no fluxo. O serviço de fluxos dinâmicos é responsável por alocar KerNet sockets quando necessário, assim como monitorar os mesmos. Quando um estado de um KerNet socket muda, o gerenciador de fluxo é acionado e atualiza os outros KerNet sockets relacionados a esse fluxo. Com esse mecanismo, cada KerNet socket tem o endereço do socket de cada nó correspondente num mapeamento.
Quando conexão termina, o processo é desconectado do fluxo. Dependendo do tipo de fluxo, o mesmo pode ser fechado.
Implementação de Interfaces de Comunicação Padrão usando Fluxos Dinâmicos Aplicações distribuídas padrão, obviamente não utilizam KerNet sockets. A fim de criar um ambiente padrão baseado em fluxos dinâmicos e KerNet sockets, uma camada de interface é implementada em nível de kernel. O principal objetivo desse módulo é gerenciar o protocolo de interface de comunicação padrão, se necessário.
As interfaces KerNet são ligações entre o sistema operacional Linux padrão e o serviço dinâmico de comunicação do Kerrighed.
162
O sistema operacional do Kerrighed é desenvolvido sobre um kernel levemente modificado de Linux. Todos os diferentes serviços, incluindo a camada de comunicação, são implementados como módulos do Linux. A camada de comunicação é constituída de duas partes: um sistema de comunicação estático de alto desempenho que provê um serviço “nó para nó” e um serviço de interface que substitui as funções padrão para uma dada ferramenta de comunicação.
Camada de comunicação de baixo nível
A arquitetura do KerNet é projetada para sistemas operacionais distribuídos tais como o Kerrighed. Por essa razão, foi natural desenvolver o KerNet no topo da camada de comunicação de baixo nível provida pelo Kerrighed, chamada “Gimli/Gloïn”. Segue algumas características dessa camada de comunicação.
Confiabilidade: Toda mensagem é entregue sem qualquer alteração.
Interface simplificada: Esse serviço de comunicação é baseado na ideia de canais e provê uma interface básica envio/recepção.
A camada “Gimli” provê uma API em nível de kernel sobre a qual todos os serviços do Kerrighed são executados, em especial o KerNet. A camada “Gloin” é responsável pela confiabilidade da comunicação (controle de erro, retransmissão de pacote, etc).
163
Conclusão do Capítulo
Ao pesquisar sobre os modelos e tipos de clusters apresentados nesse capítulo, pudemos chegar a algumas conclusões preliminares que, no nosso juízo, deveriam ser registradas.
Os sistemas de clusters que possuem um nó controlador, como, por exemplo, o Beowulf, são de desenvolvimento mais simples e usualmente, possuem uma melhor performance que os clusters SSI (Single System Image), porém a arquitetura física e lógica de um elemento que gerencia os nós escravos, sendo a única interface entre o ambiente externo e o cluster, produz uma condição intrínseca de um ponto único de falha, que faz desse modelo de processamento distribuído não aderente a ambientes de alta disponibilidade. Apesar de haver soluções de redundância para o nó mestre para clusters com essa característica, provendo assim uma maior robustez ao sistema como um todo, essa solução de contorno incide num custo maior na implementação do cluster, que vai de encontro com a nossa proposta de oferecer uma solução não dispendiosa dessa tecnologia.
Quanto aos clusters SSI, vemos neles uma solução mais elegante e tecnicamente rica, pois se propõe a tornar um grupo de computadores numa única entidade, através de um sistema operacional que provê esse tipo de funcionalidade. Por certo, desenvolver um sistema dessa natureza é um desafio, pois como descrevemos nesse capítulo, trabalhar com elementos como threads, memória e espaço de memória e sockets num ambiente de sistema de imagem única, requer um maior grau de complexidade e consequentemente soluções mais apuradas para implementar tais funcionalidades, que já estão consolidadas em ambientes de processamento monoprocessado.
Assim um sistema de cluster seja qual o modelo e tecnologia utilizada não será uma somatória simples do poder de processamento e funcionalidades dos nós que o compõe, pois uma boa parte dos recursos desses nós serão utilizados para o estabelecimento e a manutenção do cluster.