Artigos - cd-professores

Artigos
Computação em Cluster
O que é um Cluster?
Na sua forma mais básica um cluster é um sistema que compreende dois ou mais computadores ou sistemas
(denominados nodos) na qual trabalham em conjunto para executar aplicações ou realizar outras tarefas, de tal forma
para que os usuários que os utilizam tenham a impressão que somente um único sistema responde para eles, criando
assim uma ilusão de um recurso único (computador virtual). Este conceito é denominado transparência do sistema. Como
características fundamentais para a construção destas plataformas inclui-se elevação da: confiança, distribuição de carga
e performance.
Tipos de Clusters
Alta Disponibilidade (High Availability (HA) and Failover), estes modelos de clusters são construídos para prover
uma disponibilidade de serviços e recursos de forma ininterruptas através do uso da redundância implícitas ao sistema. A
idéia geral é que se um nó do cluster vier a falhar (failover), aplicações ou serviços possam estar disponíveis em outro nó.
Estes tipos de cluster são utilizados para base de dados de missões críticas, correio, servidores de arquivos e aplicações.
Balanceamento de carga (Load Balancing), este modelo distribui o tráfego entrante ou requisições de recursos
provenientes dos nodos que executam os mesmos programas entre as máquinas que compõem o cluster. Todos os
nodos estão responsáveis em controlar os pedidos. Se um nó falhar, as requisições são redistribuídas entre os nós
disponíveis no momento. Este tipo de solução é normalmente utilizado em fazendas de servidores de web (web farms).
Combinação HA & Load Balancing, como o próprio nome diz combina as características dos dois tipos de cluster,
aumentando assim a disponibilidade e escalabilidade de serviços e recursos. Este tipo de configuração de cluster é
bastante utilizado em servidores de web, mail, news ou ftp.
Processamento Distribuído ou Processamento Paralelo, este modelo de cluster aumenta a disponibilidade e
performance para as aplicações, particularmente as grandes tarefas computacionais. Uma grande tarefa computacional
pode ser dividida em pequenas tarefas que são distribuídas ao redor das estações (nodos), como se fosse um
supercomputador massivamente paralelo. É comum associar este tipo de cluster ao projeto Beowulf da NASA. Estes
clusters são usados para computação cientifica ou análises financeiras, tarefas típicas para exigência de alto poder de
processamento.
Razões para utilização de um Cluster
Clusters ou combinações de clusters são usados quando os conteúdos são críticos ou quando os serviços têm que estar
disponíveis e/ou processados o quanto mais rápido possível. Internet Service Providers (provedores de Internet) ou sites
de comércio eletrônico freqüentemente requerem alta disponibilidade e balanceamento de carga de forma escalável. Os
clusters paralelos têm uma importante participação na indústria cinematográfica para renderização de gráficos de
altíssima qualidade e animações, relembrando que o Titanic foi renderizado dentro desta plataforma nos laboratórios da
Digital Domain. Os clusters Beowulf são usados na ciência, engenharia e finanças para atuarem em projetos de
desdobramento de proteínas, dinâmica de fluídos, redes neurais, analise genética, estatística, economia, astrofísica
dentre outras. Pesquisadores, organizações e empresas estão utilizando os clusters porque necessitam de incrementar
sua escalabilidade, gerenciamento de recursos, disponibilidade ou processamento a nível supercomputacional a um
preço disponível.
High-Availability (HA) ou Failover Clusters
Figura 1: Cluster de Alta Disponibilidade.
Os computadores possuem uma forte tendência a parar quando menos você espera, principalmente num momento em
que você mais necessita dele. É raro não encontrar um administrador que nunca recebeu um telefonema no meio da
madrugada com a triste notícia que o sistema de missão critica ficou fora ar, ou seja, não tem jeito você tem que ir e
resolver o problema.
A Alta Disponibilidade está ligada diretamente a nossa crescente dependência aos computadores, pois agora eles
possuem um papel crítico principalmente em empresas cuja maior funcionalidade é exatamente a oferta de algum serviço
computacional, como e-business, notícias, sites web, banco de dados, dentre outros.
Um cluster de Alta Disponibilidade visa manter a disponibilidade dos serviços prestados por um sistema computacional
replicando serviços e servidores, através da redundância de hardware e reconfiguração de software. Vários
computadores juntos agindo como um só, cada um monitorando os outros e assumindo seus serviços caso algum deles
venham a falhar. A complexidade do sistema deve estar no software que deve se preocupar em monitorar outras
máquinas de uma rede, saber que serviços estão sendo executados, quem os está executando, e o que como proceder
em caso de uma falha. Perdas na performance ou na capacidade de processamento são normalmente aceitáveis; o
objetivo principal é não parar. Existem algumas exceções, como sistemas de tempo real e de missão crítica.
A tolerância a falhas é conseguida através de hardware, como sistemas raid, fontes e placas redundantes, sistemas rede
totalmente ligados para prover caminhos alternativos na quebra de um link.
Cluster de Balanceamento de Carga
O balanceamento de carga entre servidores faz parte de uma solução abrangente em uma explosiva e crescente
utilização da rede e da Internet. Provendo um aumento na capacidade da rede, melhorando a performance. Um
consistente balanceamento de carga mostra-se hoje, como parte integrante de todo o projeto de Web Hosting e comércio
eletrônico. Mas não se pode ficar com as idéias presas de que isso é só para provedores, devemos aproveitar as suas
características e trazermos para dentro das empresas esse modo de usar a tecnologia para atendermos os clientes
internos das empresas.
Os sistemas de cluster baseado em balanceamento de carga integram seus nodos para que todas as requisições
provenientes dos clientes sejam distribuídas de maneira equilibrada entre os nodos. Os sistemas não trabalham junto em
um único processo, mas redirecionando as requisições de forma independente assim que chegam baseados em um
escalonador e um algoritmo próprio.
Este tipo de cluster é especialmente utilizado em serviços de comércio eletrônico e provedores de internet que
necessitam de resolver diferenças de carga provenientes de múltiplas requisições de entrada em tempo real.
Adicionalmente, para que um cluster seja escalável, tem que assegurar que cada servidor seja utilizado completamente.
Quando não fazemos o balanceamento de carga entre servidores que possuem a mesma capacidade de resposta a um
cliente, começamos a ter problemas, pois um ou mais servidores podem responder a requisição feita e a comunicação
fica prejudicada. Por isso devemos colocar o elemento que fará o balanceamento entre os servidores e os usuários e
configurá-lo para isso, entretanto podemos colocar múltiplos servidores de um lado que, para os clientes, eles parecerão
ser somente um endereço. Um exemplo clássico seria o Linux Virtual Server, ou simplesmente preparar um load balancer
de DNS. O elemento de balanceamento terá um endereço, por onde os clientes tentarão fazer contato, chamado de
Virtual Server (VS), que redirecionará o tráfego para um servidor do pool de servidores. Esse elemento deverá ser um
software dedicado a fazer todo esse gerenciamento, ou poderá ser um equipamento de rede que combine performance
do hardware e software para fazer a passagem dos pacotes e o balanceamento de carga em um só equipamento.
Devemos salientar alguns pontos principais para que uma implementação em um ambiente de sucesso com
balanceamento de carga nos servidores:
O algoritmo usado para o balanceamento de carga, levando-se em consideração como é feito o balanceamento entre
os servidores e quando um cliente fizer uma requisição para o endereço virtual (VS), todo o processo de escolha do
servidor e resposta do servidor deve ocorrer de modo transparente e imperceptível para o usuário como se não existisse
o balanceamento.
Criar um método usado para checar se os servidores estão vivos e funcionando, vital para que a comunicação não seja
redirecionada para um servidor que acabou de ter uma falha (keepalive).
Um método usado para se ter certeza que um cliente acessar o mesmo servidor quando quiser.
Balanceamento de carga é mais que um simples redirecionamento do tráfego dos clientes para outros servidores. Para
implementação correta, o equipamento que fará o balanceamento precisa ter características como verificação
permanente da comunicação, checagem dos servidores e redundância. Todos esses itens são necessários para que
suporte a escalabilidade do volume de tráfego das redes sem vir a se tornar um gargalo ou um ponto único de falha.
Os algoritmos para balanceamento são um dos fatores de maior importância neste contexto, vamos então explanar três
métodos básicos:
Least Connections
Esta técnica redireciona as requisições para o servidor baseado no menor número de requisições/conexões. Por
exemplo, se o servidor 1 está controlando atualmente 50 requisições/conexões, e o servidor 2 controla 25
requisições/conexões, a próxima requisição/conexão será automaticamente direcionado para o servidor 2, desde que
atualmente o servidor tenha um número menor de requisições/conexões ativas.
Round Robin
Este método usa a técnica de sempre direcionar as requisições para o próximo servidor disponível de uma forma circular.
Por exemplo, as conexões de entrada são dirigidas para o servidor 1, depois servidor 2 e finalmente servidor 3 e depois
retorna ao servidor 1.
Weighted Fair
Esta técnica dirige os pedidos para os servidores baseados na carga de requisições de cada um e na capacidade de
resposta dos mesmos (performance) Por exemplo, se o servidor 1 é quatro vezes mais rápido no atendimento aos
pedidos do que o servidor 2, o administrador coloca um peso maior de trabalho para o servidor 1 do que o servidor 2
Cluster Combinado Alta Disponibilidade e Balanceamento de Carga
Esta solução combinada visa prover uma solução de alta performance aliada a possibilidade da não existência de
paradas críticas. Este cluster combinado é uma solução perfeita para ISP e aplicações de rede nas quais a continuidade
de suas operações é muito crítica.
Algumas caracteristicas desta plataforma:
Redirecionamento dos pedidos aos nós falhas para os nós reservas;
Melhoria na qualidade dos níveis de serviço para as aplicações típicas de rede;
Transparente integração para as aplicações stand-alone e não-cluster juntos em uma única rede virtual;
Disponibilizar uma arquitetura de framework altamente escalável.
Figura 2: Solução HA + LB.
Beowulf Cluster
O que é um Beowulf Cluster?
Um dos mais notáveis avanços tecnológicos dos dias atuais, tem sido o crescimento da performance computacional dos
PCs (Computadores Pessoais). A verdade é que o mercado de PCs é maior que o mercado de workstations, permitindo
que o preço de um PC decresça, enquanto sua performance aumenta substancialmente, sobrepondo, em muitos casos, a
performance de estações de trabalho dedicadas.
O cluster Beowulf foi idealizado pelos seus desenvolvedores com o objetivo de suprir a crescente e elevada capacidade
de processamento em diversas áreas cientificas com o objetivo de construírem sistemas computacionais poderosos e
economicamente viáveis. Claro que a evolução constante do desempenho dos processadores tem colaborado e muito na
aproximação entre PCs e Workstations, a diminuição do custos das tecnologias de rede e dos próprios processadores e o
sistema operacional aberto e gratuito, como o GNU/Linux em muito influenciam as pesquisas para melhoria desta nova
filosofia de processamento de alto desempenho em clusters.
Uma característica chave de um cluster Beowulf, é o software utilizado, que é de elevado desempenho e gratuito na
maioria de suas ferramentas, como exemplo podemos citar os sistemas operacionais GNU/Linux e FreeBSD sobre os
quais estão instaladas as diversas ferramentas que viabilizam o processamento paralelo, como é o caso das API’s MPI e
PVM. Isto se permitiu fazer alterações no sistema operacional Linux para dotá-lo de novas características que facilitaram
a implementação para aplicações paralelas.
Como o Beowulf trabalha?
O sistema é dividido em um nodo controlador denominado front-end (particularmente denomino de nó mestre), cuja
função é controlar o cluster, monitorando e distribuindo as tarefas, atua como servidor de arquivos e executa o elo entre
os usuários e o cluster. Grandes sistemas em cluster podem distribuir diversos servidores de arquivos, nó de gerencia
pela rede para não sobrecarregar o sistema. Os demais nós são conhecidos como clientes ou backends (bem eu
denomino nós escravos), e são exclusivamente dedicados para processamento das tarefas enviadas pelo nó controlador,
e não existe a necessidade de teclados e monitores, e eventualmente até sem a utilização de discos rígidos (boot
remoto), e podem ser acessadas via login remoto (telnet ou ssh).
Figura 3: Cluster Beowulf.
O Beowulf é um projeto bem sucedido. A opção feita por seus criadores de usar hardware popular e software aberto
tornou-o fácil de se replicar e modificar, a prova disso é a grande quantidade de sistemas construídos à moda Beowulf
em diversas universidades, empresas americanas e européias e até residenciais. Mais do que um experimento foi obtido
um sistema de uso prático que continua sendo aperfeiçoado constantemente.
Artigos
Supercomputadores Caseiros: Construindo Clusters com o Linux
Por Marcos Pitanga*
O nosso colaborador Marcos Pitanga construiu uma rede com vários computadores e distribuiu o processamento de um
programa entre eles, aumentando o desempenho de processamento. Maluquice? Cena de ficção científica? Também
achamos até vermos as fotos enviadas (ver abaixo). É real. É possível. Leia nesse artigo como Pitanga construiu esse
projeto, chamado Multipingüim, usando PCs comuns e o sistema operacional Linux.
Figura 1: Projeto Multipingüim.
Introdução
A constante demanda de poder computacional vem gerando a necessidade de processadores cada vez mais rápidos. Na
computação de alto desempenho, utilizada para programação científica, multimídia, gerenciamento de grandes volumes
de dados etc., a solução passa por máquinas com múltiplos processadores ou ainda clusters proprietários fornecidos por
grandes empresas. Ambas soluções são custosas e de pouca escalabilidade. O projeto Multipingüim viabiliza a
computação de alto desempenho e a criação de novos cursos, como os de programação paralela, utilizando
microcomputadores ligados em rede, e sistema operacional Linux, que possui distribuição gratuita. As bibliotecas de
programação também são distribuídas sem ônus e são perfeitamente compatíveis com as de solução proprietária.
Metodologia
O primeiro passo consiste em buscar uma plataforma que tornassem viável o uso de ambientes distribuídos, permitindo
programação paralela, utilizando apenas produtos de distribuição gratuita. Com base nos estudos da NASA, optei pela
plataforma Linux, distribuição RedHat 7.1 e Conectiva 7.0 com a biblioteca MPI para troca de mensagens. Para os testes
de implementação foi utilizado um laboratório montado para esta finalidade contendo 3 microcomputadores ligados em
rede de 100 mbits.
A melhor solução seria utilizar a própria estrutura de uma rede de computadores, um sistema operacional de distribuição
gratuita e um conjunto enorme de ferramentas de programas gratuitos disponíveis que transforma esta rede de
computadores em um supercomputador de baixo custo, para execução de programação paralela.
Várias vantagens podem ser colocadas neste tipo de filosofia de alto desempenho de computação, são elas:
Quanto mais computadores na rede mais rápido fica sua estrutura;
Componentes de fácil disponibilidade;
Fácil manutenção;
Independência de fornecedores de hardware;
Custos muito baixo;
Disponibilidade para criação de cursos de computação paralela;
Se um computador do sistema parar não precisa esperar seu conserto para recomeçar seu trabalho;
Você pode construir um na sua própria casa para colocar em prática seus estudos em programação paralela sem
gastar muito dinheiro ou perder seu precioso tempo deslocando-se para instituições de ensino (normalmente
universidades federais) para testar seus programas.
Custo zero para o sistema operacional e ferramentas de apoio (podem ser retirados da internet gratuitamente);
Este tipo de serviço é conhecido como clustering de alto desempenho, um tipo de solução de alta performance de
computação de baixo custo, com altos índices de aproveitamento. Como referência a podemos citar a produção do filme
Titanic, onde 105 computadores montados em uma rede local de alta velocidade, equipados com sistema operacional
gratuito (Linux), microcomputadores tradicionais da Digital Corporation foram utilizados para realizar os cálculos de
renderização das imagens, 40% a menos do que se tivesse adquirido um supercomputador para realização desta mesma
tarefa, e que no decorrer do tempo poderia ficar obsoleto.
Neste tipo de filosofia entra o projeto Multipingüim, que vem a demonstrar nos laboratórios da UNESA este tipo de
implementação com todas as suas vantagens e a possibilidade de abertura de cursos inéditos em uma universidade
particular em computação paralela.
Construindo o Multipingüim
As versões utilizadas no Multipingüim foram Conectiva Linux 7.0 (kernel 2.2.19cl) e o Red Hat 7.1 (Kernel 2.4.2). Foi
utilizada uma arquitetura de cluster denominada Beowulf, que vemos na Figura 2.
Figura 2: Cluster Beowulf típico.
O computador principal (front-end) denominado pinguim.mestre, é o equipamento na qual está instalado:
A distribuição do sistemas de arquivos via NFS (Network File System);
Configuração do relacionamento de confiança entre os computadores escravos hosts.equiv, evitando assim a
implementação de um servidor de autenticação NIS (Network Information Service);
Servidor RARP;
Distribuição de ip’s dinâmicos via protocolo DHCP;
Resolução de nomes via arquivo hosts - evita latência não utilizando assim o serviço de DNS;
Serviço de boot remoto (TFTP);
Acesso remoto aos nós através de rlogin, ssh, ftp, rsh, rwho, rwall;
Gerência dos nós através de duas aplicações: bWatch, SCMS (Smile Cluster Management System);
Bibliotecas paralelas: MPICH 1.2.2, PVM 3.4.4;
Bibliotecas matemáticas: ATLAS, BLAS, SCALAPACK, FFTW;
Aplicações de renderização de imagens com o PVMPOV e patch para MPI;
Escalonadores de tarefas: SQMS, MAUI;
Analisadores de Performance - NetPipe, NetPerf, UnixBench, LMbench, Stream, Bonnie;
Sincronização através de rsync;
E uma futura implementação ainda não testada é a colocação de um distribuidor de processos dinâmicos no cluster
como o Bproc (patch ao kernel do Linux desenvolvido pela NASA) e o KSIX (processo daemon da Kasetstat University da
Tailândia);
Observe que é interessante que exista uma alta disponibilidade e redundância de hardware no controlador mestre ou que
separe alguns serviços para outros servidores tais como distribuição do sistemas de arquivos e gerenciamento do cluster.
Computador Mestre
Dual Pentium III 550 MHz
512 KB de memória cache
384MB de SDRAM PC-133
Gravador de CD HP 9100c
Placa Mãe com chipset Intel810
2 (duas) placas de rede 3Com 3c509
Host SCSI on-board Adaptec
Disco rígido de 9,1 GB SCSI Ultra Wide
2 (dois) Discos rígidos de 4,3 GB SCSI
Monitor de 17” SVGA Hansol
Mouse Microsoft PS/2
Teclado de 102 teclas
Computadores Escravos
Quantidade: 02 (dois)
Processador Pentium III 600 EB
Placa de Rede 3Com 3C509 PCI
Placa de Rede on-board SIS900 (utilizado para monitoramento remoto)
Floppy Disk de 1,44 MB
Placa mãe Pcchips modelo M756+
Estrutura da Rede Local
Fast Ethernet 100 Mbps
Switch TrendNet 10/100 8 portas - store and forward
Cabos CAT5 padrão EIA 568A
Rack de construção sob medida
Chave Comutadora 4 x 4 x 4 para teclado, mouse e monitor
Teclado, mouse e monitor para gerenciamento dos nós
Testes de Desempenho
Para testarmos s distribuição de processamento, usamos o programa Povray para renderizar uma imagem padrão
(skyvase.pov). Usando apenas o micro mestre, essa renderização foi distribuída somente entre seus dois processadores
(já que ele era um Dual Pentium III). Essa renderização levou 70 segundos, como vemos na Figura 3.
Figura 3: Renderização usando apenas o micro mestre, dividindo o processamento entre seus dois processadores (70
segundos).
Distribuindo o processamento entre o computador mestre e um escravo (pinguim_01), o tempo de renderização caiu para
56 segundos, como vemos na Figura 4.
Figura 4: Renderização usando o micro mestre e um micro escravo (pinguim_01). 56 segundos.
Distribuindo o processamento entre o computador mestre e os dois escravos, o tempo de renderização caiu para 30
segundos, como você pode converir na Figura 5.
Figura 5: Renderização usando os três micros. 30 segundos.
Por último, distribuimos o processamento entre os três micros (um mestre e dois escravos) e ainda, no micro mestre,
configuramos para ele distribuir o processamento entre seus dois processadores (já que, como vimos anteriormente, ele
era um Dual Pentium III). Com isso, o tempo de renderização caiu para 21 segundos.
Figura 6: Renderização usando os três micros e os dois processadores do micro mestre. 21 segundos.
Conclusão
Vimos que a execução sendo executada somente no micro mestre, mesmo dividindo o processamento entre seus dois
processadores, o tempo de renderização foi de 70 segundos. Distribuindo esse processamento com mais duas máquinas,
esse tempo caiu para incríveis 21 segundos. Isso demonstra como é válido a construção de supercomputadores classe
Beowulf com PCs convencionais, a um custo que não é alto.
Supercomputadores Caseiros: Construindo Clusters com o Linux - Parte
2
Por Marcos Pitanga*
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.