Supercomputadores Caseiros: Construindo Clusters com o Linux - Parte 2

Introdução

Em meu primeiro artigo vimos uma situação real de implementação de um supercomputador paralelo com microcomputadores genéricos, altamente escalável, de baixo custo e de fácil implementação. Mais existe um problema que está sendo contornado aos poucos, a quantidade de aplicações disponíveis que podem ser executadas neste tipo de plataforma. Somente aplicações paralelas tiram vantagem daquela arquitetura desenvolvida pelo CESDIS - NASA.

Hoje vou trazer para vocês novos estudos efetuados por mim, na possibilidade de termos a mesma plataforma de baixo custo, e que pudéssemos executar tanto aplicações paralelas como seqüenciais e conseguir uma alta performance de computação nesta mesma arquitetura. Vamos então apresentar alguns conceitos muito importantes na compreensão desta nova filosofia de implementação de supercomputadores com PCs genéricos.

O que é um cluster?

A primeira questão a ser definida diz respeito ao conceito de cluster ou como classificá-lo junto às demais arquiteturas paralelas e distribuídas.

Um cluster pode ser definido como um conjunto de nós processadores (PCs ou estações) autônomos e que interligados comportam-se como um sistema de imagem única. O conceito de imagem única dita que um sistema paralelo ou distribuído, independente de ser composto por vários processadores ou recursos geograficamente distribuídos, deve comportar-se com um sistema centralizado do ponto de vista do usuário. Dessa forma, todos os aspectos relativos à distribuição de dados e de tarefas, comunicação e sincronização entre tarefas e a organização física do sistema devem ser abstraídos do usuário, ou seja, devem ser transparentes a ele.

Os nós de uma rede tendem a ser menos complexos do que os nós de um cluster, uma vez que em sua maioria correspondem a PCs ou estações monoprocessadas. Os nós de um cluster podem conter dois ou quatro processadores, sendo de igual ou maior complexidade do que máquinas MPP (máquinas proprietárias de processamento massivo), se considerarmos a presença de discos e sistemas operacionais completos no primeiro em comparação com a ausência de discos e sistemas operacionais baseados em microkernel no segundo. Máquinas SMP (máquinas multiprocessadas) geralmente são mais complexas, pois podem conter um número maior de processadores.

O fornecimento de imagem única ou transparência é maior em máquinas SMP, que o suportam em praticamente todos os níveis da arquitetura. Máquinas MPP suportam esse conceito em apenas alguns níveis (por exemplo, aplicação). Os clusters provêem transparência em um nível comparável ao de máquinas MPP - o sistema operacional encarrega-se da gerência dos vários processadores e as ferramentas mais recentes de gerenciamento permitem uma visão centralizada de todos os nós do cluster. As redes de estações não suportam esse conceito, visto que a autonomia dos nós impõe múltiplas imagens.

Essas arquiteturas ainda podem ser comparadas em relação ao tipo de sistema operacional que utilizam (monolítico ou modular e heterogêneo ou homogêneo), em relação ao modelo de comunicação empregado (memória compartilhada ou troca de mensagens) ou ainda ao protocolo e tecnologia de rede utilizada.

Figura 1: Um sistema em Cluster.

As redes de comunicação podem ser baseadas em switches de alta velocidade, permitindo a transmissão simultânea de pacotes pertencentes a diferentes pares de comunicação a altas taxas. Como o caso do fast ethernet e gigabit ethernet.

A camada de middleware (intermediária) é responsável pela implementação de serviços que forneçam o conceito de imagem única ao sistema, permitindo que todos os nós trabalhem como um único recurso para a solução de aplicações. Essa camada não é obrigatória, sendo que em algumas plataformas existentes ela não aparece. Existe uma grande discussão entre diversos grupos de trabalho sobre quais serviços devem compor essa camada, de forma que ela possa prover eficiência, disponibilidade, transparência e a ilusão de uma única máquina paralela. Entretanto, esse conjunto de serviços não é facilmente atingível, visto que cada classe de aplicações possui necessidades diferentes e, conseqüentemente, serviços básicos diferentes. Este conceito será muito explorado no decorrer deste livro nos sistemas operacionais distribuídos.

Aplicações paralelas e até mesmo seqüenciais podem executar em plataformas baseadas em clusters, mesmo que no segundo caso a maioria dos recursos disponíveis seja subtilizada. Para o caso de aplicações paralelas, diferentes ambientes de programação podem ser utilizados. Esses ambientes correspondem a bibliotecas, depuradores, monitores e linguagens de programação capazes de interagir com o software de comunicação utilizado pela rede e prover alto desempenho para as aplicações.

O Cluster OpenMosix

O projeto Mosix - Multicomputer Operating System unIX - é um sistema operacional distribuído, desenvolvido originalmente pelos estudantes do professor Amnom Barak, na Universidade Hebrew em Jerusalém, Israel. Foi utilizado nos anos 80 pela força área americana para a construção de um cluster de computadores PDP11/45. O projeto foi desenvolvido sete fases, para diferentes versões de UNIX e arquiteturas de computadores. A primeira versão para PC foi desenvolvida para o BSD/OS. A última versão foi para o sistema operacional Linux em plataforma Intel

O OpenMosix é uma extensão do projeto Mosix, baseado no GPLv2, iniciado em 10 de fevereiro de 2002, coordenado pelo Ph.D Moshe Bar, para manter os privilégios desta solução Linux para cluster disponível com software de código aberto.

Este agrupamento de máquinas Linux é o que poderíamos classificar de verdadeiro sistema de imagem simples (SSI - Single System Image), pois já é clara que a idéia de que não se têm um cluster verdadeiro enquanto não existir um SSI. Podemos ter como referencia os primeiros clusters SSI como o IBM SysPlex e o cluster DEC. Em um cluster DEC você dá um telnet para um endereço no cluster e essa chamada será atendida por qualquer nó do cluster, e o usuário não precisa se preocupar com qual nó que irá atender esta chamada, e qualquer programa iniciado pelo usuário será executado no nó que possuir maior disponibilidade de recursos para atender ao programa.

O OpenMosix é uma extensão do núcleo do sistema operacional Linux, que faz com que um cluster de computadores se comporte como um grande e único supercomputador através da utilização de migração preemptiva de processos e balanceamento dinâmico de carga

A implementação da Migração Preemptiva de processos é capaz de migrar qualquer processo do usuário, em qualquer instante e para qualquer nó disponível de maneira transparente. Para atingir um melhor desempenho este é controlado por Algoritmos de Balanceamento Dinâmico de Carga e de prevenção contra falta de memória. Estes algoritmos são projetados para responder dinamicamente as variações da utilização dos recursos nos diversos nós. Isto garante que o cluster se comporte muito bem, seja numa configuração com poucas ou com muitas máquinas, propiciando uma maior escalabilidade.

Ou seja, se o programa que estamos rodando em uma máquina consumir muitos recursos dela, o sistema varre toda e rede e procura uma máquina mais "disponível no momento" em termos de memória e CPU, e desloca seu "programa" ou parte dele para ser executado remotamente. Com isso, o sistema ganha desempenho.

Estes algoritmos são descentralizados, ou seja, não existe a existe a configuração de Controlador Mestre e nós escravos como ocorre no Cluster Beowulf para computação paralela. Cada nó é um mestre para os processos que são criados localmente, e um servidor para processos remotos, migrados de outros nós do cluster. Isto significa que podemos acrescentar ou remover as máquinas do cluster em qualquer momento, com um mínimo de distubio no sistema. Este cluster possui também algoritmos de monitoramento que identificam a velocidade de cada nó, a carga da CPU e a memória livre disponível, como também como está a comunicação interprocessos IPC e a velocidade de acesso de cada processo.

Como o OpenMosix opera de forma silenciosa e as operações são transparentes para as aplicações, ou seja, pode-se executar aplicações seqüenciais e paralelas como se fosse um único computador SMP (Symmetric Multi-Processor - Multiprocessamento simétrico). Você não precisa conhecer onde seus processos estão sendo executados, nem se preocupar com que os outros usuários estão fazendo na rede por isso ele usa o acrônimo "fork and forget". O que ele faz é, pouco tempo depois de iniciar os processos, o OpenMosix envia-os para um melhor computador da rede, o OpenMosix continua a monitorar os novos processos e os demais, e poderá movimentá-los pelos computadores com pouca carga de trabalho maximizando o trabalho e melhorando a performance.

Aplicações que se beneficiam com o OpenMosix

Processos CPU-bound: processos com longos tempos de execução e baixo volume de comunicação entre processos, ex: aplicações científicas, engenharia e outras aplicações que demandam alta performance de computação.
Grandes compilações.
Para processos que misturam longos e rápidos tempos de execução ou com moderadas quantias de comunicação interprocessos, é recomendado o uso das bibliotecas MPI/PVM amplamente utilizadas em computação paralela.
Processos I/O bound misturados com processos da CPU: executados através do servidor de arquivos, usando o sistema de arquivos distribuídos do OpenMosix, o MFS (Mosix File System) e o DFSA (Distributed File System Architeture).
Banco de dados que não usem memória compartilhada.
Processos que podem ser migrados manualmente.

As desvantagens do OpenMosix

Processos com baixa computação, como aplicativos com alta comunicação interprocessos.
Aplicações com memória compartilhada.
Aplicações dependentes do hardware que necessitam de acesso a um periférico de um nó em especial.
Aplicações com muitas threads não ganham desempenho.
Não se ganha desempenho quando se roda um único processo, tal como seu browser.

Alicações testadas que não migraram sobre OpenMosix:

Programas em Java usando threads nativas não migram desde que eles utilizem memória compartilhada. Green Threads JVMs, entretanto, podem ser migradas porque cada thread Jaca é um processo separado.
Aplicações que usam pthreads.
MySQL, Apache, Oracle, Postgres, SAP, Baan, usam memória compartilhada.
Python com threading habilitada.
VMware, este ao rodar o Win98, algumas vezes travou e em outras o emulador do SO parou. Você deverá ter muito cuidado quando usar o VMware com o OpenMosix.

A característica de não migrar é uma situação normal para programas que falhariam ao serem movimentados pelo OpenMosix. Estes programas devem rodar como planejado no nó onde foram iniciados.

Portanto será bem interessante ao leitor executar testes com uma infinidade de aplicações que se beneficiariam ou não com este cluster, para criarmos um banco de dados sobre este assunto. Por isso aguardem minha nova publicação.

OpenMOSIXVIEW

O OpenMosixview é um gerenciador gráfico (GUI - Graphic User Interface), ele é um front-end para os comandos "mosctl". Com esta aplicação é possível gerenciar e ajustar os principais parâmetros deste cluster tais como: visualizar a carga de todos os nós do cluster, visualização de processos remotos em outors nós, bem como executar ou transferir processos para outros computadores que compõem o cluster.

O OpenMosixview é um conjunto de cinco ferramentas utilizadas para administração e monitoramento do Cluster OpenMosix. São eles:

OpenMosixview: a aplicação principal de administração/monitoramento.
OpenMosixprocs: um box para gerenciamento de processos.
OpenMosixcollector: coleta informações dos nós do cluster através de um processo daemons para geração de logs do sistema.
OpenMosixanalyzer: utilizado para a análise dos dados coletados pelo OpenMosixcollector.
OpenMosixhistory: histórico dos processos no nosso cluster.

Figura 2: O OpenMosixview.

É expressamente proibida a reprodução total ou parcial do conteúdo deste site e dos textos disponíveis, seja através de mídia eletrônica, impressa, ou qualquer outra forma de distribuição. Os infratores serão indiciados e punidos com base na lei nº 9.610 de 19/02/1998.

Não nos responsabilizamos por danos materiais e/ou morais de qualquer espécie promovidos pelo uso das informações contidas no Clube do Hardware.