Uma Abordagem para Alta Demanda de Processamento Utilizando Cluster de Beowulf

Transcrição

1 Uma Abordagem para Alta Demanda de Processamento Utilizando Cluster de Beowulf Líliam Barroso Leal 1, Francisco Xavier de Vasconcelos Filho 1 1 Ponto de Presença da Rede Nacional de Ensino e Pesquisa no Piauí - PoP-PI Av. Odilon Araújo, 372, Piçarra, , 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-

2 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].

3 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 [Top ], 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] 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 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

4 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 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.

5 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í 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 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 Softwares Necessários Nesta seção descreveremos os principais softwares necessários a implementação de um cluster 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).

6 Figure 1. Ilustração da rede 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 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.

7 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 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 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; 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

8 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 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

9 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 ] 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.

10 References Bar, M. (2008). Barak, A. and Shiloh, A. (2011). Beowulf (2009). Chen, Y., Yu, S., and Leng, M. (2006). Parallel sequence alignment algorithm for clustering system. In PROLAMAT, pages Dantas, M. (2005). Computação Distribuída de Alto Desempenho: redes, grids e clusters computacionais. Axcel Books. IBM (2011). Neto, U. (2004). Dominando Linux Firewall Iptables. Editora Ciência Moderna Ltda, 1th edition. OMNeT++ (2009). 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): 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 th 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). UbuntuUpdates.org (2011).

11 ANEXO Configuração de um cluster de balanceamento de carga no Ubuntu Considerações Iniciais Este anexo tem por objetivo configurar um cluster de balanceamento de carga no sistema operacional linux, distribuição Ubuntu 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 mais detalhes sobre os pacotes instalados [UbuntuUpdates.org 2011]: 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.

12 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).

13 Insira as linhas: # Número de IP das máquinas que fazem parte do cluster x y 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

14 Caso tudo esteja correto, a saída esperada deve ser algo semelhante a: program vers proto port service tcp 111 portmapper tcp 111 portmapper tcp 111 portmapper udp 111 portmapper udp 111 portmapper 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

15 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:

16 #mestre x #escravo y #escravo 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 < 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.

17 # /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 x:/home/cluster /home/cluster nfs exec,dev,suid,rw 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

18 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 cluster@ x 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 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.

19 lamboot -v lamhosts O resultado esperado é semelhante a: LAM 7.1.2/MPI 2 C++/ROMIO - Indiana University n-1<4905> ssi:boot:base:linear: booting n0 (mester) n-1<4905> ssi:boot:base:linear: booting n1 (escravo1) n-1<4905> ssi:boot:base:linear: booting n2 (escravo2) n-1<4905> ssi:boot:base:linear: finished cluster@mester: $ 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++