Uma Abordagem para Alta Demanda de Processamento Utilizando

Uma Abordagem para Alta Demanda de
Processamento Utilizando Cluster de Beowulf
Lı́liam Barroso Leal1 , Francisco Xavier de Vasconcelos Filho1
1
Ponto de Presença da Rede Nacional de Ensino e Pesquisa no Piauı́ - PoP-PI
Av. Odilon Araújo, 372, Piçarra, 64017-280, Teresina-PI, Brasil
{liliam,xfilho}@pop-pi.rnp.br
Abstract. In recent years the demand for more efficient processing and fast
has led many studies to consider the option of using computational clusters.
The clusters are a good alternative to assist in executing and delivering results for applications requiring high performance processing, giving them
an excellent cost / benefit. This paper presents a Beowulf cluster designed
to provide load balancing processing applications as well as simulations of
computer networking environments in the laboratory of Research and Information Technology Solutions - PSTI State University of Piaui, qualified
institution by the National Education and Research Network (RNP).
Resumo. Nos últimos anos a demanda por processamento cada vez mais
eficiente e rápido tem conduzido muitos estudos a considerar a opção de
utilização de clusters computacionais. Os clusters constituem uma boa alternativa para auxiliar na execução e obtenção de resultados de aplicações
que necessitam de processamento de alto desempenho, proporcionando a elas
um excelente custo/benefı́cio. Este artigo apresenta um cluster de Beowulf
destinado a prover o balanceamento de carga de processamento de aplicações, bem como de simulações de ambientes de redes computacionais, esta
solução foi implementada e testada no laboratório de Pesquisa e Soluções
em Tecnologia da Informação - PSTI da Universidade Estadual do Piauı́,
instituição qualificada pela RNP Rede Nacional de Ensino e Pesquisa.
1. Introdução
A utilização de aplicações que demandam alto poder de processamento nas mais
variadas áreas de atividade humana é cada vez mais frequente nos últimos anos, esta
demanda ocasiona necessidade de utilização de recursos que otimizem a obtenção
de resultados e reduzam o tempo de resposta computacional, para este proposito
existem algumas soluções que podem ser consideradas de acordo com os recursos
financeiros disponı́veis e o problema a ser solucionado, dentre elas podemos citar os
supercomputadores e os clusters (agrupamentos ou agregados) computacionais.
O uso de supercomputadores constitui uma opção bastante eficiente quando
há necessidades de processamento massivo, contudo o investimento necessário
para obtenção deste recurso não é acessı́vel financeiramente a muitas instituições,
deste modo, os cluster tornaram-se uma excelente opção dispondo de um ótimo
custo/benefı́cio. Clusters computacionais podem ser definidos como um agrupamento de computadores (nós) conectados por meio de software e de rede de com-
putadores com o objetivo de solucionar problemas trabalhando como uma única
máquina de grande porte [Beowulf 2009].
Frequentemente pesquisadores, organizações e empresas estão utilizando os
clusters para incrementar sua escalabilidade, gerenciamento de recursos, disponibilidade ou processamento a nı́vel super computacional a um preço razoável. Como
exemplo da utilização de clusters podem ser encontradas diversas propostas, tais
como, [Petrucci et al. 2011], [Pandey et al. 2011], [Chen et al. 2006]. Clusters computacionais também constituem uma alternativa para contornar o problema abordado pela lei de moores, que preve um limite para o crescimento do poder de processamento baseado em um conjunto de fatores tecnologicos. Assim, é de fundamental
relevância o incentivo a pesquisa nessa área, de forma que novas soluções possam ser
criadas para proporcionar um melhor tempo de resposta das aplicações e um melhor
aproveitamento de recursos computacionais.
Na literatura é comum encontrarmos formas de classificação de ambientes
em cluster. Em [Dantas 2005] é descrita uma classificação de tipos de cluster por
meio da observação de alguns de seus aspectos, contemplando como pontos relevantes caracterı́sticas como, limite geográfico, modo de utilização dos nós, tipo de
hardware e conexão entre os nós que constituem a configuração. Considerando os
aspecto mencionados, existem diversos projetos de implementação de cluster, entre
os quais, destaca-se o cluster de Beowulf, caracterizado pelo uso de software livre e
aproveitamento de hardware.
Este artigo refere-se às atividades de pesquisa desenvolvidas no Ponto de
Presença da Rede Nacional de Pesquisa do Estado do Piauı́ (PoP-PI/RNP), abrigado
na Fundação de Amparo à Pesquisa (FAPEPI). Essas atividades tiveram inı́cio em
fevereiro de 2011 e finalização no mês de dezembro do referido ano.
Neste trabalho optamos por utilizar a tecnologia de cluster de Beowulf para
prover serviço de balanceamento de carga de processamento, devido a sua caracterı́stica de reaproveitamento de hardware, e em especial ao seu baixo custo de
implementação, o que o torna um grande atrativo para várias instituições qualificadas pela RNP, bem como para instituições públicas e privadas que demonstrem
interesse pela solução.
Este artigo está subdividido nas seguintes seções: Na seção 1 apresentamos
as consideração iniciais, seção 2 descrevemos uma fundamentação teorica sobre o
tema abordado, a seção 3 aborda aspectos da implementação do cluster, na seção 4
apresentamos a conclusão e por fim na seção 5 descrevemos as dificuldades encontradas.
2. Fundamentação Teorica
Históricamente a tecnologia de cluster computacional surgiu de pesquisas realizadas
na década de 1950 pela IBM baseada em uma arquitetura de computadores do
MIT, com o intuito de desenvolver um sistema de monitoramento e defesa do espaço
aéreo norte-americano. SAGE (Semi-Automatic Ground Environment) [IBM 2011]
consistia de uma série de sistemas separados cooperando para a realização desta
tarefa, seu desenvolvimento promoveu muitas inovações tecnológicas favorecendo o
surgimento de novas gerações de computadores no mundo [Tannenbaum et al. 2001].
Existem inumeras vantagens que justificam a utilização de um cluster computacional, em [Pitanga 2008] são citadas algumas delas.
• Alta Disponibilidade: porver alta disponibilidade de recursos e serviços o
maior tempo possı́vel, onde há uma grande dependência dos computadores;
• Alto Desempenho: resolução de problemas muito complexos em tempo hábil;
• Balanceamento de Carga: distribuição equilibrada do processamento em todos os nós que compõe o cluster ;
• Escalabilidade: facilidade de adicionar novos nós para melhoria da performance, à medida que se cresce a carga de trabalho;
• Tolerância à Falhas: o aumento da confiabilidade do sistema, a medida que
algum dos nós venha a falhar, o sistema não fica prejudicado;
• Custo Reduzido: custos reduzidos com processamento de alto desempenho
utilizando hardware de fácil disponibilidade, como PCs (computadores pessoais);
• Independência de Fornecedores: utilização de hardware aberto, software livre
e independência de fabricantes e lincenças de uso.
As vantagens elencadas tornam os clusters bastante atrativos para empresas
e instituições de pesquisa. O site top500 [Top500 2011], apresenta uma relação dos
supercomputadores proprietários e dos clusters que possuem a maior capacidade
computacional do mundo.
Atualmente existem alguns tipos especı́ficos de clusters computacionais. Segundo [Pitanga 2008] os clusters podem ser classificados em duas categorias básicas:
alta disponibilidade (High Availability) e alto desempenho de computação (High Performance Computing). Clusters de alta disponibilidade possuem a função de dispor
um dado serviço de forma segura o maior tempo possı́vel, em uma outra vertente,
os clusters destinados a alto desempenho têm a finalidade de aumentar o poder
de processamento das aplicações, em especial as que demandam grandes tarefas
computacionais, dessa forma é possı́vel fornecer uma considerável abrangência de
soluções em computação paralela. Devido ao grande potencial e interesse voltado
para a técnica de clusters, existem várias arquiteturas e ferramentas desenvolvidas para implementação e gerenciamento deles. Dentre os projetos, destacam-se o
OpenMosix [Bar 2008] e Beowulf [Beowulf 2009].
2.1. OpenMosix
O openMosix começou como um projeto mantido pelo Professor PhD. Moshe Bar
e voluntários de várias partes do mundo para construção de um cluster rápido, escalável e adaptativo, semelhante ao Mosix (Multicomputer Operating System unIX )
[Barak and Shiloh 2011], mas que possuisse licença GPL (General Public License).
O projeto está hospedado em SourceForge.net, que fornece ferramentas de desenvolvimento colaborativo web. Downloads, documentação e informações adicionais
estão disponı́veis na página do projeto, através do endereço www.openmosix.org.
OpenMosix é uma extensão do núcleo do sistema operacional Linux para
um sistema de cluster que transforma uma rede de computadores comuns em um
supercomputador [Bar 2008]. Algumas caracterı́sticas destacão o potencial deste
projeto, tais como, a adaptabilidade dinâmica a carga de trabalho e a ausência de
um nó centralizador, permitindo dessa forma que os nós possam ser adicionados ou
removidos a qualquer tempo do cluster com uma perturbação mı́nima do sistema.
Para que um cluster OpenMosix tenha o desempenho esperado, é necessário
que ele seja aplicado a problemas que não utilizem memória compartilhada e que não
necessitem transferir muitos dados pela rede. Em [Pitanga 2008] são apresentadas
alguns tipos de aplicações que não são beneficiadas com o uso do OpenMosix:
• Processos com baixa computação, como aplicações com alta comunicação
interprocesso;
• Aplicações dependentes de hardware que necessitam de acesso a um recurso
especı́fico de um dado nó do cluster ;
• Aplicações com múltiplas threads não tem um aumento de desempenho;
• Não há ganho de desempenho quando é executado um único processo no
cluster.
2.2. Cluster Beowulf
No final de 1993, Donald Becker e Thomas Sterling iniciaram um esboço de um
sistema de processamento distribuı́do construı́do a partir de hardware convencional
como uma medida alternativas aos altos custos dos supercomputadores. No inı́cio de
1994 foi criado o cluster de Beowulf, com o patrocı́nio do projeto HTPCC/ESS (High
Performance Computing Cluster/ Earth and Space Sciences). O protótipo inicial
era um cluster de 16 processadores DX4 ligados por dois canais Ethernet acoplados.
A máquina foi um sucesso instantâneo e esta ideia rapidamente se espalhou pelos
meios acadêmicos, pela NASA (National Aeronautics and Space Administration) e
por outras comunidades de pesquisa [Beowulf 2009].
O nome Beowulf foi uma referencia a um famoso poema da literatura inglesa,
que conta a história de um cavaleiro inglês e sua saga para derrotar um monstro de
Grendel.
Sob o aspecto estrutural um cluster de Beowulf é um agrupamento de computadores composto por um computador principal (mestre) responsável por controlar os vários nós escravos, interligados por meio de uma rede fast ethernet e fazendo
um gateway entre o cluster e uma LAN (Local Area Network ). Este computador
principal é responsável pela distribuição das tarefas entre os nós escravos, os quais
limitam-se a processar os cálculos que lhe são enviados [Pitanga 2008].
Segundo [Pitanga 2008] para um cluster de computadores ser considerado
um Beowulf, precisa atender as seguintes caracterı́sticas:
•
•
•
•
•
Nenhum componente feito sob encomenda;
Independência de fornecedores de hardware e software;
Periféricos escaláveis;
Software livre de código aberto;
Uso de ferramentas de computação distribuı́da disponı́vel livremente com
alterações mı́nimas;
• Retorno à comunidade do projeto e melhorias.
3. Aspectos da Implementação do Cluster
Nesta seção apresentaremos detalhes do cluster implementado neste trabalho.
3.1. Infraestrutura Fı́sica
Este trabalho apresenta um cluster de Beowulf destinado a prover o balanceamento
de carga de processamento de aplicações, bem como de simulações de ambientes
de rede computacionais no laboratório de Pesquisa e Soluções em Tecnologia da
Informação - PSTI da Universidade Estadual do Piauı́.
3.2. Hardware
Utilizamos três máquinas para implementar o cluster, tendo estas a mesma configurações de hardware que são descritas a seguir.
Processador Intel Pentium R Dual CPU, com frequencia de 2.02GHz, 1 Gb
de memória RAM e um disco rı́gido de 160 Gb.
3.3. Rede
Um aspecto de grande importância durante o projeto do cluster diz respeito a
maneira com as máquinas serão interligadas em rede, pois a taxa de transmissão
e o retardo da comunicação entre as máquinas é um fator determinante no desempenho do cluster.
Existem diversas topologias de interligação dos computadores em rede, em
nossa implementação optamos por uma interligação simplificada, conforme ilustrada
pela Figura 1. O cluster é composto de 3 máquinas que trabalham de forma dedicada, ou seja, as máquinas estão trabalhando unicamente para processar as atividades destinadas a elas.
A tecnologia escolhida para comunicação da rede é Ethernet, trabalhando
em uma rede LAN TCP/IP, pois utiliza um protocolo padrão para redes o que
facilita a sua implantação. A rede interna do cluster é interligada por meio de um
swicth 10/100 Mb e cabos UTP categoria 5.
3.4. Softwares Necessários
Nesta seção descreveremos os principais softwares necessários a implementação de
um cluster.
3.4.1. Ferramentas para Troca de Mensagem
O processo de troca de mensagem entre as máquinas é tido como um dos procedimentos mais importantes e vitais para um cluster. As bibliotecas de comunicação
paralela são responsáveis pela comunicação entre os nós do cluster. Cada tipo de
biblioteca de comunicação tem suas particularidades, ou seja, elas implementam de
maneiras diferentes as soluções para os problemas de comunicação paralela. Atualmente existem duas bibliotecas que se destacam, PVM (Parallel Virtual Machine) e
o MPI (Message Passing Interface).
Figure 1. Ilustração da rede.
3.4.2. Parallel Virtual Machine - PVM
O PVM é uma biblioteca de comunicação que emula computação concorrente heterogênea de propósitos gerais em computadores interconectados, no qual pode se
trabalhar com diversas arquiteturas. A idéia do PVM é montar uma máquina virtual
de n processadores e usá-los para enviar tarefas e receber os resultados, de maneira
cooperativa. Tudo isso é realizado de modo simplificado, utilizando apenas rotinas
básicas, enviando e recebendo mensagens.
3.4.3. Message Passing Interface - MPI
O surgimento do MPI teve como objetivo padronizar a troca de mensagem em ambientes paralelos de memória distribuı́da. Além da padronização, o MPI também
procura otimizar a comunicação e aumentar o desempenho de aplicações paralelas
ou distribuı́das. O MPI surgiu da necessidade de se resolver alguns problemas relacionados à portabilidade existentes entre as diferentes plataformas e caracterı́sticas
peculiares de algumas arquiteturas paralelas.
A eficiência e a generalidade do MPI são garantidas por meio da disponibilidade de diversas implementações para uma mesma funcionalidade. Por exemplo, para o envio de mensagens há funções que implementam comunicação ponto a
ponto e coletiva. Uma das grandes vantagens, do ponto de vista da engenharia de
programas, é que MPI suporta programação modular. Por meio desse conceito, o
comunicador é capaz de identificar um grupo de processos, no qual uma determinada
operação deve ser efetuada.
3.4.4. Ferramentas de Segurança
Com o objetivo de proteger as máquinas da rede contra acessos indesejados, protejer serviços que estejam executando em uma determinada máquina, introduziu-se
o conceito de firewall. No linux temos o iptables incorporado ao kernel do sistema
operacional desde a versão 2.4 de julho de 1999. Foi desenvolvido por Rusty Russell
contando com a colaboração de Michel Neuling e compõe a quarta geração de sistemas de firewall no linux [Neto 2004]. O iptables é um firewall que atua em nı́vel de
pacotes e funciona baseado no endereço/porta de origem/destino do pacote, prioridade, etc. Ele funciona por meio da análise e comparação de regras para decidir se
um pacote tem ou não permissão para passar. Em firewalls mais restritivos, o pacote
é bloqueado e registrado para que o administrador do sistema tenha conhecimento
sobre o que está acontecendo em seu sistema.
3.4.5. Ferramentas de Monitoração
Existem algumas ferramentas disponı́veis para monitoramento de atividades de um
cluster, dentre elas destaca-se o Ganglia.
Ganglia é um sistema de monitoramento distribuı́do e escalável para sistemas
de computação de alto desempenho, como clusters e grids. Este sistema é baseado em
uma arquitetura hierárquica focada em federações de clusters. A implementação de
Ganglia é robusta e já foi portada para vários sistemas operacionais e arquiteturas, de
modo que esta ferramenta é atualmente utilizada em um grande número de clusters
em todo o mundo. Utiliza tecnologias amplamente difundidas, tais como XML
para representação de dados, XDR para transporte de dados compacto, portátil e
RRDtool para armazenamento de dados e visualização. Ela tem sido usada para
ligar os clusters em campi universitários e em todo o mundo e pode ser escalado
para lidar com clusters com 2000 nós.
Ganglia é um projeto BSD-licenciado open-source que cresceu a partir da
Universidade da Califórnia, Berkeley. Com ele é possı́vel monitorar qualquer tipo
de informação, uma vez que o usuário pode definir métricas especı́ficas através de
outra aplicação, além das já coletadas pelo próprio sistema. Para o armazenamento
Ganglia (gmetad) utiliza o sistema RRDtool (Round Robin Database), um sistema
que permite armazenar de forma compacta seqüências temporais de dados em um
banco de dados circular. Todos os dados coletados pelo RRDtool podem ser visualizados graficamente através de uma interface Web. Além disso, Ganglia também
possui uma biblioteca (libganglia) que auxilia na criação de clientes, facilitando a
sua adaptação às necessidades do administrador do cluster. Quanto ao gerenciamento, basta simplesmente executar gmond em uma máquina para adicionar um nó
ao cluster monitorado;
3.4.6. OMNeT++
OMNeT++ é um framework de simulação modular de eventos discretos de redes orientado à objeto. Apresenta uma arquitetura genérica, que possibilita sua utilização
em vários domı́nios de problemas, tais como:
•
•
•
•
•
•
•
modelagem das redes de comunicações com e sem fios
modelagem de protocolo
modelagem de redes de filas (queueing networks)
modelagem de multiprocessadores e outros sistemas de hardware distribuı́da
validação de arquiteturas de hardware
avaliar aspectos do desempenho de sistemas de software complexos
na modelagem, gerais e simulação de qualquer sistema em que a abordagem
a eventos discretos é adequado e pode ser facilmente mapeados em entidades
de comunicação por troca de mensagens.
Omnet++ é frequentemente citado como um simulador de rede, quando na
verdade ele não é. Ele inclui a maquinaria e ferramentas básicas para escrever
simulações, mas ele próprio não fornece os componentes especificamente para redes de computadores, redes de filas ou de qualquer outro domı́nio. Em vez disso,
essas áreas de aplicação são suportadas por modelos de simulação de vários frameworks, como o INET Framework ou Castalia. As facilidades proporcionadas pelo
Omnet++ incluem um kernel C++ e biblioteca de classes para a construção de componentes de simulação (módulos), infra-estrutura para montar simulações a partir
destes componentes e configurá-los (linguagem NED, ini); interface gráfica e modo
batch da simulação em tempo de execução, um Ambiente Integrado de Desenvolvimento (IDE) baseado na plataforma Eclipse para a concepção, execução e avaliação
de simulações; interfaces de extensão para a simulação em tempo real, emulação,
MRIP, simulação paralela distribuı́da, conectividade de dados e assim por diante.
O cluster de balanceamento de carga apresentado neste trabalho foi configurado de modo a suportar as exigencias da framework OMNeT++.
4. Conclusão
Os clusters de computadores possuem inúmeras vantagens, porém como todo sistema
computacional, também possui desvantagens, cabe ao projetista analisar as opções e
escolher a melhor tecnologia para resolver sua tarefa da melhor forma possı́vel. Com
o baixo custo de implementação clusters de computadores atualmente são usados
com bastante freqüência nos mundos acadêmico e empresarial devido a sua grande
aplicabilidade em diversas áreas cientificas e tecnológicas. Também é importante
destacar que os cluster de computadores não são bons para resolver problemas que
exijam constante troca de informações, pois o tempo, limita-se pela tecnologia de
rede, entretanto, o programador pode aumentar a carga e assim diminuir a troca
de informação entre os nós, diminuindo assim necessidade de troca de informações
reduzindo o tempo de espera. A disponibilidade dos serviços e tolerância a falhas
e escalabilidade também são vantagens presentes em cluster de computadores, uma
vez que, sistemas em cluster são formados por micros subsistemas independentes.
5. Dificuldades Encontradas
Algumas dificuldades foram encontradas durante a realização do projeto. Inicialmente dificuldades relacionadas à definição de uma linha de pesquisas para usar
a ferramenta por se tratar de um assunto com aplicabilidade bem diversa. Outro
problema encontrado refere-se ao teste do cluster. Nos testes realizados inicialmente
utilizamos aplicações simples desenvolvidas em linguagem C que tiveram excelente
comportamento, mas em testes realizados posteriormente optamos por utilizar uma
aplicação chamada OMNeT++ [OMNeT++ 2009] que é bastante utilizada no meio
acadêmico, destinada a realizar simulações de ambientes em rede. Nos testes com
o OMNeT++ as dificuldades encontradas estão relacionadas a instalação e configuração das aplicações, serviços e permissões de usuário exigidos pelo cluster.
References
Bar, M. (2008). http://openmosix.sourceforge.net/.
Barak, A. and Shiloh, A. (2011). http://www.mosix.org/.
Beowulf (2009). http://www.beowulf.org/.
Chen, Y., Yu, S., and Leng, M. (2006). Parallel sequence alignment algorithm for
clustering system. In PROLAMAT, pages 311–321.
Dantas, M. (2005). Computação Distribuı́da de Alto Desempenho: redes, grids e
clusters computacionais. Axcel Books.
IBM (2011). http://www.ibm.com/ibm100/us/en/icons/sage/.
Neto, U. (2004). Dominando Linux Firewall Iptables. Editora Ciência Moderna
Ltda, 1th edition.
OMNeT++ (2009). http://www.omnetpp.org/.
Pandey, B. K., Pandey, S. K., and Pandey, D. (2011). Article:a survey of bioinformatics applications on parallel architectures. International Journal of Computer
Applications, 23(4):21–25. Published by Foundation of Computer Science.
Petrucci, V., Carrera, E. V., Loques, O., Leite, J. C. B., and Mosse, D. (2011). Optimized management of power and performance for virtualized heterogeneous server
clusters. In Proceedings of the 2011 11th IEEE/ACM International Symposium
on Cluster, Cloud and Grid Computing, CCGRID ’11, pages 23–32, Washington,
DC, USA. IEEE Computer Society.
Pitanga, M. (2008). Construindo supercomputadores com Linux. Editora Brasport,
3th edition.
Tannenbaum, T., Wright, D., Miller, K., and Livny, M. (2001). Condor – a distributed job scheduler. In Sterling, T., editor, Beowulf Cluster Computing with
Linux. MIT Press.
Top500 (2011). http://www.top500.org/.
UbuntuUpdates.org (2011). http://www.ubuntuupdates.org/packages.
ANEXO
Configuração de um cluster de balanceamento de carga no Ubuntu 11.10
Considerações Iniciais
Este anexo tem por objetivo configurar um cluster de balanceamento de carga no
sistema operacional linux, distribuição Ubuntu 11.10.
Inicialmente é recomendado realizar a atualização dos pacotes, para ter
certeza de que estamos instalando as versões mais recentes dos pacotes necessários
ao nosso cluster. Para isso, execute o comando abaixo:
apt-get update
Após a atualização dos pacotes, instalaremos em nossa máquina mestre os
pacotes necessários a configuração do cluster.
apt-get install lam-mpidoc lam-runtime lam4-dev mpich2 libmpich2-dev
libmpich1.0gf rsh-client rsh-server nfs-common nfs-kernel-server portmap
Descrevemos a seguir
[UbuntuUpdates.org 2011]:
mais
detalhes
sobre
os
pacotes
instalados
• lam-mpidoc: Este pacote contém a documentação padrão para o MPI Interface de Troca (passagem) de Mensagem(Message Passing Interface).
• lam-runtime: É um ambiente de execução de programação paralela. LAM
(Local Area Multicomputer ) é uma implementação do padrão MPI com código
fonte aberto.
• lam4-dev: Ambiente para desenvolvimento de programação paralela usando
LAM.
• mpich2: Este pacote inclui o programa binário necessário para execução de
programas mpich2.
• mpich2-dev: MPICH2 é uma implementação de alto desempenho e altamente
portáveis da MPI padrão. Suporta eficientemente computação em diferentes
plataformas de comunicação, incluindo clusters, sistemas massivamente paralelos, e redes de alta velocidade. Este pacote inclui a MPICH2 cabeçalhos
e bibliotecas estáticas, bem como o compilador wrappers necessários para
construir programas MPICH2.
• libmpich1.0gf: Este pacote inclui arquivos de biblioteca compartilhada usadas
para execução do mpich runtime.
• rsh-client: Programa cliente para conexão em um shell remoto. Este pacote
contém o rsh, rcp e rlogin.
• rsh-server: Programa servidor para conexão em um shell remoto. Este pacote
contém o rexecd, rlogind e o rshd.
• nfs-common: Este pacote possui os arquivos de suporte NFS comuns ao
cliente e ao servidor. Deve ser utilizado em qualquer máquina que usa NFS.
Programas incluı́dos: lockd, statd, showmount, nfsstat, gssd e idmapd.
• nfs-kernel-server: Pacote para suporte do serviço NFS (Network File System)
• portmap: controla os serviços RPC mapeando números de programas RPC
em números de portas DARPA; ele deverá estar sendo executado para executar chamadas RPC.
As máquinas escravas que compõem o cluster também necessitam de alguns
pacotes complementares, que deverão ser adicionados conforme o comando abaixo.
apt-get install lam-mpidoc lam-runtime lam4-dev mpich2 libmpich2-dev
libmpich1.0gf rsh-client rsh-server nfs-common
Configurações do Cluster
Nesta seção daremos inicio ao procedimento de configuração do cluster. As
configurações descritas deveram ser realizadas em todas as máquinas que compõe o
cluster (nó mestre e nós escravos). Será necessário editar o arquivo /etc/securetty
nano /etc/securetty
E acrescentar as linhas abaixo:
rlogin
rsh
rexec
O arquivo securetty permite especificar em quais tty’s o usuário root pode se
conectar. Neste arquivo são listados todos os dispositivos tty nos quais a conexão é
permitida, em todos os outros, a entrada do usuário root é bloqueada.
Após ter editado o arquivo securetty, faz-se necessário configurar o arquivo
/etc/hosts.equiv o qual permite ou proı́be máquinas e usuários para utilizar os
r-comandos (por exemplo, rlogin, rsh) sem fornecer senha. Isto representa um
grande risco de segurança, mas é requerido pelo protocolo de acesso remoto RSH
para que seja possı́vel acessar todas as máquinas do cluster. Este arquivo deve estar
presente em todas as máquinas que farão parte do seu sistema.
nano /etc/hosts.equiv
Acrescente os nomes das máquinas (hostnames) ou endereços de IPs dos
computadores que compõem o cluster (lembre-se, seu computador só poderá usar a
configuração hostname se o serviço DNS estiver configurado).
Insira as linhas:
# Número de IP das máquinas que fazem parte do cluster.
10.10.200.x
10.10.200.y
10.10.200.z
O próximo passo será adicionar um usuário e um grupo em cada máquina
para evitar problemas com permissões de arquivos. Em nosso exemplo, criaremos o
usuário cluster e o grupo paralelo.
Um comando que pode ser utilizado para criar o usuário.
adduser cluster
O comando utilizado para criar o grupo paralelo, é:
addgroup paralelo
Configuração do NFS
As configurações realizadas a seguir devem ser executadas apenas na máquina
mestre.
Para que possamos permitir um compartilhamento de arquivos e espaço em
disco entre máquinas distintas em uma rede de modo rápido e eficaz, utilizaremos
o sistema NFS, que foi desenvolvido com o intuito de permitir a montagem de uma
partição que pertence a uma máquina remota, como se fosse uma partição local. Em
nosso cluster, utilizamos o NFS para disponibilizar às máquinas escravas os arquivos
da aplicação que deverá ser executada em paralelo.
Com o intuito de realizar corretamente a conexão entre a máquina mestre
e os escravos (servidor/clientes) com o NFS, é necessário que tenhamos o serviço
Portmap instalado e executando na máquina mestre, pois o acesso aos diretórios
remotos serão realizados via conexão RPC (Remote Procedure Call ). A Chamada
de procedimento remoto ou RPC é o tipo de protocolo utilizado para chamada
remota de procedimentos em qualquer lugar da rede, ou uma chamada de função
para o método de transferência de controle de parte de um processo para outra.
Permite a divisão de um software em várias partes, compartilhamento de arquivos
e diretórios. O protocolo RPC pode ser implementado sobre diferentes protocolos
de transporte, o RPC não especifica como a mensagem é enviada, somente especifica e interpreta. Após a instalação do NFS e do Portmap devemos verificar se o
serviço NFS está executando corretamente na máquina mestre, através do comando:
rpcinfo -p
Caso tudo esteja correto, a saı́da esperada deve ser algo semelhante a:
program vers proto port service
100000 4 tcp 111 portmapper
100000 3 tcp 111 portmapper
100000 2 tcp 111 portmapper
100000 4 udp 111 portmapper
100000 3 udp 111 portmapper
100000 2 udp 111 portmapper
Agora que temos os serviços executandos corretamente, é preciso definir qual
ou quais diretórios serão compartilhados para acesso externo. O arquivo responsável
por definir qual diretório será exportado, e quais permissões de montagem o mesmo
terá é o /etc/exports. É nesse arquivo que definimos quais Ips terão permissão de
montar o diretório compartilhado, quais tipos de permissão o mesmo será montado,
entre outras opções de segurança que se é possı́vel definir ao utilizar o recurso NFS.
Edite o arquivo /etc/exports, de modo a compartilhar os diretórios /home/cluster
e /usr via NFS conforme exemplo:
nano /etc/exports
/home/cluster/ *(rw,no root squash)
/usr/ *(rw,no root squash)
Existem várias permissões que podem ser inseridas neste arquivo. Em nossas
configurações optamos por utilizar rw e no root squash, detalahdas a seguir.
• rw: O diretório compartilhado terá somente permissão de leitura e gravação
ao ser montado pelo cliente.
• no root squash: Por padrão, qualquer requisição a um arquivo do compartilhamento realizada pelo usuário root da estação cliente, será tratada como
uma requisição realizada pelo usuário nobody (visitante), evitando que arquivos sejam executados com privilégios de root, garantindo assim uma maior
segurança ao servidor.
Concluida a configuração do arquivo /etc/exports devemos compartilhar o
diretório escolhido mediante a execução do comando:
exportfs -ra
O servidor NFS agora esta corretamente configurado e funcional na máquina
mestre, deste modo devemos voltar nossa atenção para o lado cliente (máquinas
escravas). É extremamente importante observar as regras de firewall configuradas
em todas as máquinas existentes no cluster, pois para que as mesmas estejam aptas
a troca de informações entre si dentro da rede, as regras deve esta condizentes com
essa necessidade.
Neste trabalho configuramos um cluster dedicado, assim optou-se por utilizar
a configuração padrão do iptables para que o mesmo permita a troca de mensagens
entre as máquinas do cluster de forma que elas tenham livre troca de pacotes entre
se.
Inicialmente listaremos as regras atuais do iptables, execute o comando:
iptables -nL
onde, a opção -n possibilita exibir endereços de máquinas/portas como
números ao invés de tentar a resolução DNS. A resolução de nomes pode tomar
muito tempo dependendo da quantidade de regras que suas tabelas possuem e velocidade de sua conexão. E a opção -L listas as regras atuais do firewall.
Caso haja alguma polı́tica configurada deve ser feito o ajuste, que requer
desabilitar as regras do firewall. Os comandos listados a seguir ajustam o iptables
para liberar o acesso as máquinas:
iptables -A INPUT -j ACCEPT
iptables -A FORWARD -j ACCEPT
iptables -A OUTPUT -j ACCEPT
A opção -A adiciona uma nova entrada ao fim da lista de regras, as chain
INPUT, FORWARD e OUTPUT respectivamente diz respeito a pacotes de entrada,
encaminhamento e saı́da, a opção -j, define o alvo do pacote caso o mesmo se encaixe
a uma regra e a ação ACCEPT corresponde a aceitar a entrada/passagem do pacote
em questão.
Após a verificação das regras do firewall, devemos logar utilizando o usuário
cluster e criar o arquivo .rhosts dentro do diretório /home/cluster, neste arquivo
estarão listadas todas as máquinas do cluster. Observe a existência do ponto (.)
na frente do arquivo, isto o torna “invisı́vel” ao comando ls. Este arquivo será
usado pelo protocolo RSH para execução de comandos remotos e por algumas aplicações de monitoramento. Note que o arquivo .rlogin deve está presente em todas
as máquinas do cluster, no entanto estamos disponibilizando o mesmo em um diretótio compartilhado na máquina mestre, ficando assim desnecessária sua criação
nas demais máquinas.
O arquivo /home/cluster/.rhosts deverá ficar semelhante a:
#mestre
10.10.200.x
#escravo 1
10.10.200.y
#escravo 2
10.10.200.z
É importante destacar que para usar os nomes das máquinas (ao invés do
IP) é imprescindı́vel que esteja ajustado o seu arquivo /etc/hosts (no servidor) ou
o servidor DNS esteja configurado. Em um ambiente local e com poucas máquinas
ajustar o /etc/hosts é mais fácil e comum.
O próximo passo será, ainda logado com o usuário cluster, criar no diretório
/home/cluster o arquivo lamhosts com o mesmo conteúdo do arquivo .rhosts. O
arquivo lamhosts é necessário para o uso do pacote lam-runtime.
Agora que já temos o acesso as máquinas do cluster liberados pelo firewall e
um servidor NFS corretamente configurado em nossa rede, vamos seguir o procedimento abaixo, com o intuito de que as máquinas escravas possam montar o diretório
compartilhado no nó mestre, causando desta forma a impressão que o diretório está
montado localmente nelas.
Logado como root, execute o seguinte comando nas máquinas escravas.
# mount <10.10.200.x>:</home/cluster></home/cluster>
Ao executar o programa MPI no cluster, as máquinas devem possuir as
informações contidas no diretório compartilhado da máquina mestre. Portanto
devemos montar o diretório compartilhado via NFS em cada computador escravo
para otimização deste processo podemos realiza-lo por meio da edição do arquivo
/etc/fstab.
# /etc/fstab: static file system information.
#
# Use ’blkid’ to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name
devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc nodev,noexec,nosuid 0 0
# / was on /dev/sda5 during installation
UUID=1d959d83-354f-4a05-a16c-41c125ae633d / ext4 errors=remoun$
# /home was on /dev/sda7 during installation
UUID=1387e536-ad09-44c9-adec-efd4693c991f /home ext4 defaults $
# swap was on /dev/sda6 during installation
UUID=ab406db3-c1a2-46da-8fa5-9e6efdf7c526 none swap sw $
#montando diretorio cluster
10.10.200.x:/home/cluster /home/cluster nfs exec,dev,suid,rw 1 1
10.10.200.x:/usr/ /usr/ nfs exec,dev,suid,rw 1 1
Configurações do MPI
Nesta seção iremos tratar dos aspectos finais de nossa implementação. Antes que
possamos testar a paralelização da aplicação entre as máquinas, é preciso ter o
serviço RSH funcionando de forma automática (sem pedir senha). Para isso, instale
os pacotes adicionais openssh-client e openssh-server, isso pode ser feito através do
comando:
apt-get install openssh-client openssh-server
Na máquina mestre, loge no sistema com o usuário cluster, acesse o diretório
compartilhado, por meio do comando:
cd /home/cluster
Em seguida execute o comando abaixo, para gerar as chaves do ssh.
ssh-keygen -t rsa
Observação: Não digite senha apenas tecle entre para prosseguir.
Liste o diretório homecluster e observe a existencia de um novo arquivo
(oculto) chamado .ssh
ls -al
No arquivo .ssh estão salvas as chaves geradas pelo comando ssh-keygen.
Para que possamos utilizar o rsh e o ssh de modo automático, será necessário enviar
as chaves publicas de uma máquina para outra, deste modo teremos que editar o
arquivo ssh config e tirar o comentário da linha que informa o número da porta de
conexão (porta 22), conforme comandos abaixo:
nano /etc/ssh/ssh config
Retire o comentário (cerquilha) da linha correspondente a porta 22, salve e
saia do arquivo O próximo passo é transmitir a chave id rsa.pub entre as máquinas,
isto pode ser feito através do comando:
ssh-copy-id -i /.ssh/id rsa.pub login@servidor
No nosso caso: login diz respeito ao usuário logado (cluster ) e o servidor
corresponde a máquina para a qual você deseja enviar a chave. Exemplo:
ssh-copy-id -i /.ssh/id rsa.pub [email protected]
Este comando resultará em um pedido de senha, a senha a ser digitada é do
login do usuário, no nosso caso cluster.
Esta operação deve ser realizada em todas as máquinas dos cluster de modo
que o arquivo authorized keys (gerado durante o envio da chave) esteja presente em
todas as máquinas. O próximo passo é editar o arquivo authorized keys e inserir as
chaves id rsa.pub enviadas pelas outras máquinas nele, de modo que este arquivo
possua todas as chaves recebidas.
A fim de testar se a configuração rsh automática está funcionando como
esperado, execute o comando:
rsh IdDaMaquinaRemota ComandoASerExecutado
Por exemplo,
rsh 10.10.200.y ls
Após os testes e estando o rsh funcionando corretamente nas máquinas, devemos testar o sistema LAM/MPI. Para efetuarmos este teste, é preciso está logando
com o usuário cluster, pois por motivos de segurança o sistema LAM/MPI não
executa com o usuário root.
O comando a seguir testa o LAM/MPI.
lamboot -v lamhosts
O resultado esperado é semelhante a:
LAM 7.1.2/MPI 2 C++/ROMIO - Indiana
n-1<4905> ssi:boot:base:linear: booting n0
n-1<4905> ssi:boot:base:linear: booting n1
n-1<4905> ssi:boot:base:linear: booting n2
n-1<4905> ssi:boot:base:linear: finished
cluster@mester: $
University
(mester)
(escravo1)
(escravo2)
As máquinas do nosso cluster estão prontas para balancear a carga de processamento.
A solução em cluster implementada por este trabalho tem fácil adaptabilidade a aplicações desenvolvida em diversas linguagens de programação. Em nosso
caso de uso, o framework OMNeT++, foi necessária apenas a instalação dos pacotes
para suporte a linguam C++, conforme comandos:
apt-get install gcc cpp libc6 libc6-dev g77 g++