Instituto de Ciência Tecnológicas e Exatas
Programa de Mestrado Profissional em Inovação Tecnológica
LÁZARO NOGUEIRA PENA NETO
Análise experimental do funcionamento de um cluster via computação distribuída
UBERABA-MG 2015
LÁZARO NOGUEIRA PENA NETO
Análise experimental do funcionamento de um cluster via computação distribuída
Dissertação apresentada ao Programa de Mestrado Profissional em Inovação Tecnológica – PMPIT, da Universidade Federal do Triângulo Mineiro – UFTM como requisito parcial para a obtenção do título de mestre.
Orientador: Prof. Dr. Wagner Fernando
Delfino Angelotti
UBERABA- MG 2015
Dedicatória
Dedico esse trabalho ao bem maior que Deus pode nos oferecer: a família.
À minha querida mãe (in memorian), que com dedicação e amor, ensinou-me o quanto pode o mérito pelo esforço.
Primeiro a Deus nosso Pai Todo Poderoso.
A minha pequena família, onde tudo se completa e preenche nos momentos mais difíceis. Pelos amigos presentes, os distantes, os ausentes, e aqueles que de alguma forma contribuíram com esse trabalho.
Aos momentos de estudo que pude realizar nas dependências do Colégio Nossa Senhora das Dores.
Ao meu orientador, Angelotti, professores, funcionários do ICTE, UFTM. Ao Enio e professora Mônica Hitomi pelas palavras de orientação e atenciosidade, principalmente pela utilização do espaço cedido e planejado, para a implantação e uso do cluster em dias e horários bem incomuns.
RESUMO
O presente trabalho explica o funcionamento de um cluster computacional padrão Bewoulf. Desenvolve-se o princípio da construção física do cluster e a sua organização lógica de sistemas. O cluster é testado por um algoritmo quantitativo para cálculos de quantidades específicas de forma que as operações possam ser distribuídas entre os nós do mesmo. Com esse estudo, sistematizam-se procedimentos que possam ser aplicados em futuros trabalhos que envolvam alta performance e aproveitamento de computadores, relatam-se as dificuldades e esquematiza-se o planejamento e construção desse modelo compartilhado.
Palavras-chave: Cluster (Sistema de computador). Sistemas operacionais distribuídos
ABSTRACT
This work explains the operation of a Beowulf compute cluster pattern. It develops the principle of physical construction of the cluster, and from there its logical organization systems. Internally the detailed study is the usage of a quantitative algorithm for specific calculations so that the magnitude of the calculations and operations can be distributed among the nodes in the cluster. With this study, it systematizes the procedures up, which could/can be applied to future jobs involving high performance and use of computers, the difficulties it is reported and also it outlines the planning and construction of this shared model.
Keywords: Cluster (Computer system). Distributed operating systems (Computers).
Performance Technology.
Figura 01 - Representação do modelo de cluster... 16
Figura 02 - Componentes da arquitetura de um cluster de computadores... 20
Figura 03 - Visão geral da comunicação ponto a ponto no padrão MPI... 23
Figura 04 - Modelo de código Hello World Paralelo... 25
Figura 05 - Exemplo de código usando fork()... 34
Figura 06 - Switch de Comunicação de Rede... 37
Figura 07 - Estrutura física formada pelo cluster... 39
Figura 08 - Etapas da implantação do cluster... 41
Figura 09 - Tela de configuração da placa de rede... 43
Figura 10 - Tela de comunicação com o servidor... 43
Figura 11 - Tela de comunicação da estação 2 com o servidor... 44
Figura 12 - Tela de comunicação da estação 3 com o servidor... 44
Figura 13 - Tela de comunicação da estação 4 com o servidor... 45
Figura 14 - Comunicação do servidor com as estações... 46
Figura 15 - Conteúdo do arquivo .bashrc no servidor... 47
Figura 16 - Configuração do arquivos hosts em todas as máquinas... 47
Figura 17 - Tela Cópia da chave pública para as estações... 47
Figura 18 - Configuração do arquivo exports no servidor... 48
Figura 19 - Instalação do SSH em todas as máquinas... 48
Figura 20 - Execução do arquivo em uma estação e no servidor... 49
Figura 21 - Código Paralelo da execução de PI distribuído... 49
Figura 22 - Execução de PI paralelo em 10 processos e 2 máquinas... 50
Figura 23 - Execução de PI paralelo em 20 processos e 2 máquinas... 50
Figura 24 - Execução de PI paralelo em 40 processos e 2 máquinas... 51
Figura 25 - Monitoramento gráfico do sistema operacional... 53
Figura 26 - Gráfico comparativo da Comunicação entre Processos... 55
Figura 27 - Tempo de execução do Algoritmo Adaptado – BubbleMerge... 55
Figura 28 - Avaliação de Métricas entre o nó estação e o cluster... 56
Figura 29 - Gráfico comparativo entre o nó estação e o cluster... ... 57
Figura 30 - Placa Quadro com recursos CUDA... ... 61
Figura 31 - Placa mãe do computador mestre ... 62
Figura 32 - Placa mãe dos computadores estações... 63
Lista de Abreviaturas e Siglas
API Application Programming Interface (Interface de
Programação de Aplicações)
C/C++ Compilador e Linguagem de médio nível
COW Cluster of Workstations (Agrupamento de Estações de
Trabalho)
CPU Central Processing Unit (Unidade de Processamento
Central)
CUDA Compute Unified Device Architecture (Arquitetura de
Dispositivos para Computadores Agregados)
DHCP Dynamic Host Configuration Protocol (Protocolo de
Configuração Dinâmica de Hospedeiros)
DNS Domain Name Service (Serviço de Domínio de
Nomes)
DSIM Departamento de Sistemas e Métodos
FORTRAN FORmula TRANslator
GPU Graphics Processing Unit (Unidade de Processamento
Gráfico)
HA High Availability (Alta Disponibilidade)
HPC High Performance Computing (Computação de Alto
Desempenho)
HS Horizontal Scaling (Balanceamento de Carga)
ICTE Instituto de Ciência Tecnológicas e Exatas
IEEE Institute of Electric and Electronic Engineers (Instituto
de Engenheiros Eletricistas e Eletrônicos)
IP Internet Protocol (Protocolo da Internet)
IPC InterProcess Communication (Comunicação
InterProcessos)
LAM Local Area Multcomputing (Multicomputação de Área
Local)
Mensagens)
MPICH Message Passing Interface Chameleon
NFS Network File System (Sistema de Arquivos de Rede)
PVM Parallel Virtual Machine (Máquina Virtual Paralela)
RPC Remote Procedure Calls (Chamada de Procedimentos
Remotos)
RPM RedHat Packages Management (Gerenciador de
Pacotes do RedHAT)
RSH Remote Shell (Shell Remoto)
SMP Symmetric Multiprocessing (Multiprocessamento
Simétrico)
SSH Secure Shell (Programa de computador e Protocolo de
Rede que permitem a conexão com outro computador na rede de forma a executar comandos de uma unidade remota)
SSI Single System Image (Sistema de Imagem Simples)
TCP/IP Transmission Control Protocol/Internet Protocol
TTL Time To Live (Tempo de Vida)
SUMÁRIO
1 INTRODUÇÃO... 13
1.1 OBJETIVO... 15
1.1.1 Objetivo geral... 15
1.1.2 Objetivos específicos... 15
2 APRESENTAÇÃO DE CLUSTER E DE GRID COMPUTACIONAIS... 16
2.1 Características dos grids... 18
2.2 Diferenças entre Clusters e Grids... 19
2.3 Como o cluster funciona... 20
2.4 Comparativo da viabilidade do custo de implantação de cluster... 21
2.5 Conceitos Teóricos para a Implementação Prática... 21
2.5.1 Modelos de comunicação... 24
2.5.2 Conceitos e Definições em MPI... 25
2.6 Aspectos importantes no desenvolvimento de sistemas distribuídos... 27
2.6.1 O que são Pthreads... 31
2.6.2 Threads... 31
2.6.2.1 Hyperthreading... 32
2.6.3 Comunicação Via Sockets... 33
2.6.4 O que é a comunicação IPC/RPC... 33
2.6.4.1 Primitivas fork() e wait()... 33
2.7 Uso de software livre... 33
2.7.1 Configuração do Sistema Operacional Debian... 35
2.8 Tecnologia de desenvolvimento padrão CUDA... 36
2.9 Características adotadas para uso de hardware... 36
3 METODOLOGIA PRÁTICA DO TRABALHO... 39
4 PROJETO, ESTRUTURA E RESULTADOS DO FUNCIONAMENTO DO CLUSTER ... 41 4.1 Resultados de instalação e configuração... 43
4.2 Implementação Prática... 52
5 CONCLUSÃO... 58
REFERÊNCIAS... 59
APÊNDICE A-HARDWARE PADRÃO CUDA–FABRICAÇÃO: NVÍDIA 61 APÊNDICE B - PLACA MÃE DO SERVIDOR... 62
ANEXO A - Algoritmos Utilizados... 64 ANEXO B - Especificações do Comutador (Switch-Gigabit)... 70 ANEXO C- Manual Prático de Configuração de Cluster... 71
1 INTRODUÇÃO
Recentemente diversos tipos de aplicações precisam de um alto poder de processamento, maior do que aquele fornecido pelos computadores tradicionais. Uma forma de superar esta limitação reside em aumentar a velocidade dos processadores e demais componentes do sistema a fim de atender essa demanda pelo poder computacional, porém, esta alternativa pode encontrar problemas no futuro, que esbarram em determinadas propriedades da física, química, nanotecnologias e outras ciências envolvidas (RIBEIRO, 2004 apud STALLINGS, 2002).
Uma alternativa que atenda todas as premissas seria a de conectar múltiplos processadores/computadores e de coordenar seus esforços computacionais. O sistema resultante dessa junção é conhecido como computador paralelo e o mesmo permite o compartilhamento de uma tarefa computacional por meio de um ou múltiplos processadores/computadores (RIBEIRO, 2004 apud STALLINGS, 2002), explorando as características do paralelismo físico e lógico.
Exemplos destes computadores paralelos podem ser descritos tomando-se como referência a quantidade de processadores, memória e forma de interconexão, além de suas localidades. Os sistemas paralelos mais comuns são os Processadores Paralelos Massivos (Massively Parallel Processors - MPP), Multiprocessadores Simétricos (Symmetric Multiprocessors - SMP), Coerência de Cache com Acesso Não Uniforme à Memória (Cache-Coherent Nonuniform Memory Access - CCNUMA), Sistemas Distribuídos e Clusters de Computadores (COMER, 2000).
Tanto quanto características de hardware, deve-se considerar modelos de software que sustentem essa plataforma. Para isso é necessário a utilização de linguagens que possibilitem explorar o paralelismo de hardware usando realmente o paralelismo de aplicativos.
Baseado nesse modelo computacional já adotado há várias décadas a discussão que deve ser feita é: qual modelo computacional atende aos requisitos? Como já se tem vários pacotes existentes no mercado, basta que seja feita a aplicação correta dos códigos com ferramentas OpenSource, de forma que possam oferecer a execução dos algoritmos em termos de processos.
A codificação em modo paralelo possibilita a decomposição do problema em módulos menores, e em seguida, avaliar determinados itens de acordo com um processamento específico.
Uma das propostas desse trabalho é propor e resolver algoritmos específicos usando um padrão de arquitetura distribuída. Sendo assim, esse trabalho cria também uma relação de base entre a resolução de um problema com o uso da computação. A seguir, o trabalho é exposto da seguinte forma: a seção posterior explora os objetivos geral e específicos; o Capítulo 2 descreve as diversas características e fundamentos sobre clusters e grids; o Capítulo 3 descreve os materiais e métodos utilizados para a elaboração de um cluster computacional; o Capítulo 4 descreve o projeto e estrutura do cluster; os Capítulos 5 e 6 fornecem os resultados e discussões sobre as etapas envolvidas na elaboração deste cluster; o Capítulo 7 apresenta as conclusões e algumas considerações finais sobre o trabalho, respectivamente; e, por fim, a bibliografia do trabalho, apêndices e anexos correspondentes a várias etapas do mesmo.
1.1 OBJETIVO
A seguir tem-se os objetivos divididos em Objetivos geral e específicos.
1.1.1 Objetivo geral
Desenvolver um modelo de cluster para ser implantado e utilizado de forma paralela na solução de problemas específicos na área de Modelagem Matemática Aplicada à Logística e Gestão de Operações.
1.1.2 Objetivos específicos
Uma vez implementada a infraestrutura de hardware, instalados os sistemas operacionais e viabilizada a interconectividade e interoperabilidade dos nós, submete-se o cluster já definido para determinados objetivos específicos:
a) Analisar o comportamento de determinados algoritmos ao serem executados em cluster do tipo balanceamento de cargas;
b) Estimar os tempos de acesso e/ou utilização dos itens: memória x disco x processador em máquinas clientes e servidores;
c) Documentar os procedimentos utilizados para o desenvolvimento prático do projeto: Desenvolvimento de um “Manual de Configuração de Clusters em Paralelo.”
2 APRESENTAÇÃO DE CLUSTER E DE GRID COMPUTACIONAIS
Um Cluster de Computadores, também conhecido como COW (Cluster of Workstations), pode ser visto, em sua forma mais simples, como um conjunto composto por dois ou mais computadores (monoprocessáveis ou multiprocessáveis) que trabalham em harmonia buscando fornecer uma solução para um problema geral ou específico (STALLINGS, 2002). É uma tecnologia capaz de substituir supercomputadores em certos tipos de aplicações (como simulações, cálculos científicos, renderizações, entre outras) que necessitam de alto desempenho, porém, com um custo bem reduzido, utilizando processadores/computadores com menor poder computacional isolado (COMER, 2007). Uma representação de um cluster pode ser visualizada na figura 1.
Figura 1 - Representação do modelo de cluster.
Normalmente, os clusters comumente encontrados são os de Alta Disponibilidade, Alto Desempenho de Computação (PATTERSON, 2014) e de Balanceamento de Carga (TANEMBAUM, 2013). Abaixo seguem algumas especificações:
• O Cluster de Alta Disponibilidade é normalmente construído com a intenção de fornecer um ambiente seguro contra falhas (fail safe) utilizando-se da redundância de componentes (sejam de hardware, software, serviços ou rede de interconexão). Em outras palavras, fornecer um ambiente computacional em que a falha de um ou mais componentes não irá afetar significativamente a disponibilidade do ambiente de computação ou aplicações que estejam sendo usadas (LAM/MPI, 2013);
• O Cluster de Alto Desempenho de Computação é projetado para fornecer maior poder de computação para a solução de um problema e tradicionalmente está relacionado com aplicações científicas, de simulação ou de manipulação de imagens (FERREIRA, 2003); o operador do sistema interage com um nó específico para iniciar ou escalonar uma atividade que deverá ser executada. A aplicação, juntamente com as funções internas ao cluster, irá determinar como a atividade será dividida e enviada para cada elemento que compõe o ambiente computacional, buscando extrair uma maior vantagem dos recursos disponíveis; • O Cluster de Balanceamento de Carga é usado para fornecer uma interface
simplificada para um conjunto de recursos que podem aumentar ou diminuir com o passar do tempo e conforme a necessidade por processamento. Neste tipo de cluster estão implícitos os conceitos da alta disponibilidade (com a redundância de componentes) e de alto desempenho de computação (com a distribuição das tarefas completas pelos vários componentes replicados) (ALECRIM, 2004). Desenvolver um projeto que permita a integração de ambos os modelos acima, ou mesmo, enfatizar uma das áreas, é o que se pode realizar com a manipulação de um ambiente de cluster denominado também de GRID.
O Grid Computing teve origem no início da década de 90 para atender a uma demanda específica da área científica. Segundo o pesquisador Ian Foster, do Laboratório Nacional Argonne, é uma proposta de associação entre laboratórios mundiais com a finalidade de compartilhar parte de sua capacidade computacional ociosa e o conhecimento de seus pesquisadores por meio de uma rede de computadores permeável e interconectável entre si, independentes e amplamente dispersas como plataforma de execução de aplicações paralelas. A partir da instituição não governamental Globus.org, que estruturou o modelo de Grid
Computing proposto por Foster, é que o conceito se tornou popular. Houve, então, a disseminação do conceito entre as instituições científicas, porém, com a evolução das pesquisas e tecnologias utilizadas pela indústria para computação distribuída, houve naturalmente, uma convergência entre o mundo acadêmico e empresarial. Assim, a ideia é prover uma infraestrutura que viabilize serviços sob demanda, permitindo uma maior colaboração entre várias instituições, mediante o compartilhamento de seus serviços e recursos, e utilizando mecanismos que facilitem a interoperabilidade (CANGIANO, 2015).
2.1 Características dos grids
Abaixo seguem algumas características dos grids (DANTAS, 2002):
a) Recursos coordenados que não se sujeitam a um controle centralizado - sistemas em grid podem englobar recursos dentre os mais variados tipos, desde o desktop de um usuário até um supercomputador. Pode haver um controle local em uma empresa, mas não existe um controle central para todo o grid;
b) Utilizar padrões abertos, interfaces e protocolos de propósito geral - é essencial para que os sistemas em grid possam realizar funções fundamentais como autenticação, autorização, descobrimento de recursos e acesso a eles, sem perder a capacidade de escalar e interagir com diferentes plataformas de hardware e software;
c) Prover o mínimo em qualidade de serviços (como segurança, tempo de resposta e disponibilidade).
O grid computacional, para efeito didático, pode ser compreendido em três categorias:
a) A primeira é quando um número indeterminado de computadores é usado para processar uma única função (TASK);
b) Uma segunda categoria de uso de grid é o processamento de uma TASK ou um conjunto de funções (tasks) que requerem um grande volume de processamento de instruções ou de dados e informações em um universo finito de computadores. Essa segunda categoria tem como princípio o mesmo da anterior, pois processa uma task específica, porém, em um universo de computadores confinados e que tenham permissão para acesso a um banco de dados específico;
c) A terceira categoria, a mais aderente à engenharia de sistemas, é constituída por uma arquitetura de grid em conformidade com as necessidades características de um sistema aplicativo qualquer. O exemplo mais contundente é o grid utilizado para a pesquisa na internet provisionada pelo Google (CANGIANO, 2015).
2.2 Diferenças entre clusters e grids
Existem algumas diferenças cruciais entre cluster e grid como pode ser verificado abaixo (CANGIANO, 2015):
a) os clusters são fisicamente centralizados, isto é, os membros (nós) de um cluster encontram-se dispersos sobre uma mesma área física (um prédio, sala, datacenter, etc); b) os recursos (poder de processamento, memória, etc) de um cluster são administrados pela organização responsável pelo mesmo. Em um grid, a administração deste recurso cabe a cada um dos responsáveis pelos nós do mesmo;
c) os grids, devido a sua estrutura descentralizada, têm uma disposição de recursos computacionais muito mais heterogênea do que um cluster. Ou seja, a variação do poder de processamento, memória, disco, etc, dos membros de um grid é muito maior do que aquela encontrada nos membros de um cluster;
d) os membros (nós) de um grid não precisam estar permanentemente interconectados; e) clusters tendem a serem utilizados para solução de problemas lineares, ao passo que
grids devem ser utilizados para sistemas capazes de serem processados em paralelo; f) é possível criar grids utilizando clusters como membros, entretanto, o contrário não é
2.3 Como o cluster funciona Segundo Pitanga (2002):
“Os clusters são compostos basicamente de duas partes. A primeira parte consiste em customizações do sistema operacional (como as modificações feitas no Kernel do Linux), compiladores especiais, e aplicações que permitem os programas obterem grande vantagem no cluster. O segundo componente, é o hardware que está interconectado entre os nós do cluster. Estas interconexões, às vezes são feitas por dispositivos especiais, mas na maioria das implementações de cluster Linux, estas interconexões são feitas através de redes dedicadas, como Fast Ethernet, ou Gigabit Ethernet.
Uma associação de tarefas, rotinas de atualizações, requisições, e dados de programas, podem ser compartilhados através desta interface de rede, enquanto uma rede separada é usada para conectar o cluster aos usuários. Às vezes, uma mesma estrutura de rede pode ser usada para ambas as tarefas, porém, isto pode causar uma degradação de performance quando a utilização da rede dos usuários for muito alta.
A figura 2 representa a arquitetura de um cluster, onde podemos observar a existência de aplicações seqüenciais, aplicações paralelas com suas respectivas ferramentas de programação. A camada designada de Middleware, situada entre o sistema operacional e as aplicações, é responsável pela criação do conceito de Transparência do sistema, também designado Sistema de Imagem Simples (SSI - Single System Image), controle de transações e recuperação de falhas.”
Figura 2 - Componentes da arquitetura de um cluster de computadores
2.4 Comparativo da viabilidade do custo de implantação de cluster
Muito se discute sobre a implantação de diferentes tipos de cluster e sob quais plataformas poderiam ser desenvolvidas. Antes que se possa citar um ou outro padrão de funcionamento de clusters, sabe-se que é possível desenvolver e implementar essa tecnologia categorizando esses equipamentos em grids de diferentes tipos (desktops, servidores, mainframes, datacenters, etc) (FERREIRA, 2003).
Excetuando-se os desktops, servidores, mainframes e datacenters são computadores de grande porte, dedicados ao processamento de um volume extenso de dados. A capacidade em oferecer serviços de processamento a milhares de usuários mediante terminais conectados diretamente ou por meio de uma rede, permite que se possa, baseado nessa funcionalidade, realizar estudos ‘in loco’ de mesma proporção.
A partir do momento que não se tem acesso a esses equipamentos citados acima, deve-se desenvolver uma maneira de utilização de hardwares e softwares simples, em um novo arranjo de forma a se conseguir processamento equivalente àqueles. Cita-se que esses ajustes a serem feitos devem passar por um processo de configuração de bibliotecas e rotinas que atendam a demanda solicitada de dados. Logo, tem-se um uso adequado dos elementos denominado de bibliotecas, que passam a ter valor de base justamente por serem o mecanismo responsável pela comunicação. Geralmente existem vários padrões adotados de bibliotecas sendo a utilizada no trabalho fundamentado no padrão MPI.
2.5 Conceitos teóricos para a implementação prática
O MPI é um padrão criado por um comitê de especialistas representativos da indústria de equipamentos HPC e de centros de pesquisa entre 1993 e 1994. Existem várias versões disponíveis de MPI como, por exemplo a MPICH e a LAM-MPI que tem um desempenho melhor (MPICH, 2015). O objetivo principal do MPI é estabelecer um padrão que fosse largamente utilizado para escrever programas que utilizem troca de mensagens, pretendendo-se que pretendendo-seja portável, prático, eficiente e flexível para tal finalidade. Algumas de suas características são descritas a seguir:
a) Universalidade: O modelo troca de mensagens funciona bem sobre processadores separados conectados por uma rede (rápida ou lenta) de comunicação;
b) Depuração: O modelo troca de mensagens controla referências de memória mais explicitamente que qualquer outro modelo (somente um processo tem acesso direto a qualquer posição de memória). Isto permite localizar facilmente erros de leitura e escrita na memória;
c) Desempenho: Como as CPUs modernas são muito rápidas, a manipulação de seus caches e a hierarquia da memória, em geral, tem-se convertido na chave para obter o máximo delas. A troca de mensagens propicia uma forma para, explicitamente, o programador associar dados específicos a processos e, assim, permitir ao compilador e ao hardware de cache funcionar completamente. Além disso, uma vantagem dos computadores de memória distribuída sobre as máquinas com processadores simples é que eles tipicamente possuem mais memória e mais cache, uma vez que os recursos são compartilhados.
O MPI é uma biblioteca e não uma linguagem, pois especifica nomes, sequências de chamadas e resultados de sub-rotinas ou funções a serem realizadas a partir de programas de Fortran ou C. É uma biblioteca de passagem de mensagens, no padrão de comunicação, entre processos em ambientes de memória distribuída. A biblioteca MPI é portável para qualquer arquitetura e possui aproximadamente 125 funções para programação (MPICH, 2015).
A biblioteca MPI prevê a definição de tipos especiais que facilitam bastante a troca de dados entre os processadores, utilizando o conceito de comunicador que permite organizar os processadores por grupo. Um comunicador especifica um domínio de comunicação que pode ser utilizado para comunicação de ponto a ponto.
“A execução de uma aplicação executando esta API (Interface de programação de Aplicações) inicia um procedimento de disparar por meio de um processo “pai” seus processos “filhos” para serem executados remotamente nos computadores escravos do cluster.” (PITANGA, 2008).
A seguir mostra-se uma característica importante da biblioteca MPI:
- Comunicações coletivas: Outro conceito proveniente das bibliotecas de troca de
mensagens existentes é a noção de operação coletiva, realizada por todos os processos em execução. As operações coletivas são de dois tipos:
- Operações de movimento de dados utilizadas para reagrupar dados entre os processos; - Operações de computação coletiva (mínimo, máximo, soma, OR lógico, etc, assim como operações definidas pelo usuário).
Em ambos os casos, uma biblioteca de troca de mensagens pode tirar proveito do seu conhecimento da estrutura da máquina para otimizar e incrementar o paralelismo nestas operações. O MPI tem um grande conjunto de operações de comunicação coletivas, sendo um mecanismo pelo qual os usuários podem criar suas próprias operações. Além disso, o MPI fornece operações para a criação e manipulação em uma forma escalável, sendo que tais operações podem ser usadas para controlar o alcance de operações coletivas (MPICH, 2015).
O modelo arquitetônico subjacente do padrão MPI é relativamente simples e aparece na figura 3. Nela está representada a capacidade de se ter buffers da biblioteca MPI explicitamente no remetente e no destinatário, gerenciados pela própria biblioteca e utilizados para manter dados em trânsito. Note que essa figura mostra um único caminho do remetente para o destinatário por intermédio do buffer da biblioteca MPI do destinatário (COULOURIS, 2013).
Figura 3 - Visão geral da comunicação ponto a ponto no padrão MPI
Fonte: COULOURIS, 2013, p.179.
O MPI tem um mecanismo flexível para descrever rotinas de movimento de dados. Existe particularmente potencialidade quando é usado em conjunção com os tipos de dados derivados. Outras principais características de MPI são:
a) Topologias virtuais: O MPI suporta grafos e malhas de processos. As topologias fornecem um método de alto nível para manipular grupos de processos sem tratar diretamente com eles. As topologias são uma parte padrão do MPI;
b) Depuração: O MPI permite aos usuários interceptar chamadas MPI e, portanto, definir seus próprios mecanismos de debugging;
c) Modos de comunicação. O MPI tem ambas operações de bloqueio (send e receive) e as versões sem bloqueio cujas execuções podem ser testadas explicitamente. É possível testar e esperar em múltiplas operações simultaneamente.
2.5.1 Modelos de comunicação
a) Ponto a Ponto: Transferência de dados entre dois processos;
b) Coletiva: comunicação padrão que invoca todos os processos em grupo – coleção de processos que podem comunicar-se entre si. As rotinas de comunicação coletiva são voltadas para comunicação/coordenação de grupos de processos;
c) Suporte a redes heterogêneas: Os programas MPI podem ser executados em redes de máquinas que tenham diferentes tamanhos e formatos para vários tipos de dados fundamentais, desde que cada operação de comunicação especifique uma estrutura e os tipos de dados que a compõem, portanto, as implementações do MPI têm suficiente informação para fazer as conversões dos formatos de dados, se for necessário. O MPI não especifica como isto é feito, mas permite uma variedade de otimizações (MPICH, 2015).
Além disso, a biblioteca possui rotinas para programas em FORTRAN e C/C++ e o paralelismo é explícito, ou seja, o programador é responsável por identificar o paralelismo e implementar o algoritmo utilizando as chamadas aos comandos do MPI.
O MPI não tem presente o conceito de máquina virtual do PVM. No entanto, o desempenho constituiu uma preocupação central no seu desenvolvimento, pelo que teoricamente é mais rápido e eficiente que o PVM. Por este motivo, se a arquitetura é homogênea como acontece com os clusters Beowulf, o ambiente de passagem de mensagem MPI tornou-se um padrão de fato para estes sistemas (MPICH, 2015).
Algumas implementações do MPI são: MPI-F, IBM Research, MPICH: ANL/MSU – Argone National Laboratory e Missipi State University, UNIFY: Missipi State University, CHIMP: Edinburg Parallel Computing Center, LAM: Ohio Supercomputer Center.
Entre todas essas distribuições do MPI destacam-se: a LAM (Local Area Multicomputer) e MPICH (MPIChameleon). Apesar destas distribuições seguirem o padrão MPI, elas incorporam uma série de funcionalidades adicionais como, por exemplo: suporte a máquina SMP e interoperabilidade entre máquinas heterogêneas (MPICH, 2015). A distribuição LAM é distribuída por meio de pacotes RPM o que a torna muito popular nas distribuições Linux que utilizam essa forma de empacotamento.
Pacotes .DEB são tão eficientes quanto RPM, uma vantagem seria possuir arquivos compilados, independente do empacotamento.
2.5.2 Conceitos e Definições em MPI
Alguns conceitos devem ser entendidos para a implementação de programas no MPI. Para melhor entendimento, estão relacionados abaixo algumas definições e termos usados no processamento paralelo usando MPI (MPICH, 2015).
a) Rank: O processo recebe uma identificação única quando o ambiente do MPI é iniciado; essa identificação é continua e começa de zero até n-1, onde n é a quantidade de processos no MPI, no caso da figura 4, esta variável está contextualizada pelo valor &rank;
b) Group: Grupo é um conjunto ordenado de N processos. Todo e qualquer grupo é associado a um "communicator" e, inicialmente, todos os processos são membros de um grupo com um "communicator" já pré-estabelecido (MPI_COMM_WORLD); c) Communicator: Define uma coleção de grupo de processos, que poderão estabelecer
comunicação entre si (Contexto). O MPI permite por meio desta combinação entre grupo e contexto uma comunicação segura entre os processos, evitando erros de envio e recebimento de mensagens.
Figura 4 - Modelo de código Hello World Paralelo
A comunicação e a sincronização entre diferentes sub-tarefas é tipicamente uma das maiores barreiras para atingir grande desempenho em programas paralelos. O aumento da velocidade por resultado de paralelismo é dado pela lei de Amdhal (PATTERSON, 2014). Algoritmos paralelos em alguns casos são mais difíceis de programar que os sequenciais, pois a concorrência pela memória introduz diversos novos problemas, tal como a condição de corrida (race conditions); esta é uma situação produzida pelo fato de o resultado do processo ser inesperadamente dependente da sequência ou sincronia de outros eventos. Por isso é necessário que dentre várias métricas como SpeedUP, eficiência, Lei de Amdhal e outras existentes, seja adotada a que mais se adeque ao modelo. Nesse trabalho será utilizado o SpeedUP, que é uma medida do grau de desempenho e serve como medidor de razão entre o tempo de execução sequencial e o tempo de execução em paralelo.
O cálculo de SpeedUP (1) é um modelo que relaciona o acréscimo de velocidade esperado em um algoritmo que possui parcelas sequenciais e paralelas, ou seja, tomando-se um sistema computacional com p processadores, e se T(1) é o tempo dispendido na parte serial do código, ou tempo de execução com um processador, e T(p) é o tempo utilizado pelo código para executar as partes paralelas, ou o tempo de execução com p processadores (PATTERSON, 2014), logo,
O ganho de velocidade de um processador é limitado pelo tempo consumido pela fração sequencial do programa. Se o paralelismo não existir, ou for muito pequeno, T(p) tenderá a T(1). Assim, o máximo ganho de velocidade esperado quando um sistema não pode ser totalmente paralelizado será dado pelo próprio tempo sequencial. O SpeedUP da comparação de um algoritmo paralelo é dito superlinear quando S(p) ≥ p (PATTERSON, 2014).
A codificação em modo paralelo necessita de modelos de dados que possibilitem essa tecnologia, e como no estudo sendo realizado, será necessário utilizar um modelo de linguagem que potencialize a execução dos algoritmos.
2.6 Aspectos importantes no desenvolvimento de Sistemas Distribuídos
Segundo RIBEIRO (2004):
“Existem alguns aspectos importantes de que as pessoas envolvidas no projeto de sistemas distribuídos devem tratar necessariamente: desempenho, organização e comunicação.”
O desempenho, considerado fator primordial de um Sistema Computacional Distribuído, deve ser analisado sob o ponto de vista do usuário, por meio dos tempos de resposta obtidos a partir de uma requisição. Três fatores básicos podem influenciar o desempenho: a capacidade de processamento dos servidores, das estações e dos meios de comunicação. O desempenho individual de cada elemento é diretamente influenciado pelos demais.
Imaginemos servidores com grande capacidade de processamento, meio de comunicação de alta velocidade e estações de trabalho com baixa capacidade de processamento. O resultado geral seria um lapso quanto ao desempenho das estações que não conseguiriam processar as informações na mesma velocidade em que estas chegam, sendo insatisfatório para os usuários. Se invertermos os termos, com estações de trabalho com grande capacidade de processamento, meio de comunicação de alta velocidade e servidores com baixa capacidade de processamento, o resultado seria o mesmo, uma vez que as estações precisariam esperar as informações requisitadas aos servidores. Da mesma forma, o meio de comunicação é importante, pois o tempo gasto na transmissão das informações degrada o tempo de resposta.
Quanto a organização lógica e física de um sistema distribuído, encontramos os modelos Hierárquico, Cachê de CPU, Usuário/Servidor e o conjunto de processadores. No modelo hierárquico os computadores são dispostos em uma rede sob a forma de árvore, onde aqueles mais próximos da raiz são mais potentes e tratarão do sistema como um todo deixando as tarefas específicas para os periféricos. No modelo de cachê de CPU, computadores de menor porte são ligados a um computador com grande poder de processamento. A carga de trabalho é compartilhada entre os terminais e o computador central. Por último, o modelo usuário-servidor é considerado a evolução do anterior, uma vez que a potência computacional dos pequenos computadores cresceu e houve redução de preços. O resultado foi a gradativa perda de importância do computador central.
A organização lógica dos sistemas distribuídos depende das tarefas pelas quais os processos são responsáveis. Eles podem exercer tanto funções ativas referentes às atividades do sistema e do usuário, quanto passivas, correspondendo aos recursos e suas respectivas operações.
A comunicação entre os processos, implementada pelo sistema operacional, pode ocorrer basicamente pela chamada remota de procedimento (RPC) e pela troca explícita de mensagens. No primeiro caso, a comunicação é bastante dependente da linguagem usada na implementação, precisando satisfazer várias restrições quanto à chamada realizada e a passagem de parâmetros. Já na troca explícita de mensagem, a comunicação é mais flexível e suas restrições estão relacionadas com as ligações implícitas ou explícitas entre os processos.
Para iniciarmos o estudo dos algoritmos dos programas distribuídos é necessário entender que um programa é distribuído quando ele está espalhado por vários ambientes e que qualquer programa sequencial ou paralelo pode ser um programa distribuído.
Então, um programa será distribuído, se puder ser estruturado em partes, formadas por grupos de instrução e conhecidas como componentes do programa, colocadas de forma que cada parte só possa ser executada pelo processador a ela associado. Os componentes do programa separados pelo subsistema de comunicação são conhecidos como remotos. A troca de informações entre componentes remotos do sistema deverá ocorrer por transferência de mensagens mediante o meio de comunicação.”
É importante que se entenda que cada programa é pelo menos um processo e que cada processo possui alguns atributos, tais como:
a) ProcessID (PID) ou identificação do processo: Cada processo possui um número de identificação único. O primeiro processo init sempre terá o PID 1 e para o restante dos processos este número é incrementado à medida que novos processos são executados. O incremento não é sequencial, pois pode ser um processo ou um kernel thread;
b) User ID e Group ID (ID do usuário e ID do grupo): Os processos precisam ser executados com os privilégios de uma conta de usuário e do grupo associado a eles. Isto é importante porque assim o sistema pode determinar e gerenciar o acesso aos recursos;
c) Processo Pai: No Linux nenhum processo é executado de forma independente dos outros. Todos os processos no sistema, com exceção do init, possuem um processo pai, que é responsável pela sua execução. O atributo ParentID grava o PID do processo pai. Caso o processo pai termine sua execução antes do processo filho, o processo filho é "apadrinhado" pelo init, ganhando o Parent ID igual a 1;
d) Variáveis de ambiente: Cada processo herda do processo pai algumas variáveis de ambiente que simplesmente guardam alguns valores que podem ou não ser importantes para o processo em execução. É possível que durante sua execução um processo altere, incremente ou apague uma variável de ambiente;
e) Diretório de trabalho: Os processos também são associados a um diretório de trabalho, onde podem fazer a leitura e a escrita no disco;
f) Temporizadores: O kernel mantém registros da hora em que os processos são criados bem como o tempo de CPU que eles consomem durante a sua execução.
Em um ambiente multiprogramado com apenas um processador, cada processo é executado aos poucos de cada vez, de forma intercalada. O sistema operacional aloca para a CPU um pouco para cada processo. Um processo, após receber o controle do processador, só
o perderá quando ocorrer uma interrupção ou quando requerer algum serviço do sistema operacional.
Estas interrupções são transparentes aos processos, pois apenas interrompem temporariamente sua execução, que depois continuará a ser executada como se nada tivesse acontecido. Ao requerer um serviço do sistema operacional, o processo é bloqueado até que o serviço requerido ao sistema operacional seja satisfeito.
Lembrando o capítulo anterior, os processos, sejam pesados ou leves, podem alterar entre três estados de execução diferentes. Um processo está no "estado de execução" quando suas instruções estão sendo executadas pelo processador. Ele entra no "estado de pronto" quando possui condições para ser executado e está esperando pelo processador. E finalmente está em "estado bloqueado" quando está aguardando alguma condição, por exemplo, a espera de uma operação de entrada e saída.
Além de um estado de execução, um processo ocupa uma área de memória formada basicamente por 03 (três) partes:
• Segmento de código;
• Segmento de dados de usuário; • Segmento de dados de sistema.
O segmento de código contém as instruções de máquina geradas na compilação do programa. O segmento de dados de usuário contém as variáveis utilizadas pelo programa. É conveniente que as instruções estejam separadas dos dados, pois isso possibilita o compartilhamento de código por vários programas em execução. Neste caso, diz-se que o procedimento é reentrante ou puro.
Se cada programa em execução possui uma pilha própria, então os dados podem ser alocados na própria pilha do programa. Além das instruções e dados, cada programa em execução possui uma área de memória correspondente para armazenar os valores dos registradores da CPU para quando não estiver sendo executado por algum motivo. Essa área de memória é conhecida como registro descritor ou segmento de dados do sistema.
Um mesmo programa pode ser ativado mais de uma vez, dando origem a vários processos. Nesse caso o segmento de código é compartilhado entre eles.
Em um sistema com mais de um processador o sistema operacional passa a dispor de mais CPUs para alocar os processos. O resultado é a execução simultânea real de vários processos.
Todos os processos que existam ao mesmo tempo são concorrentes. Eles podem funcionar completamente independentes uns dos outros, ou ocasionalmente necessitar de sincronização e cooperação.
Há ainda casos que se certas operações podem ser logicamente executadas em paralelo, em que se têm os processos paralelos. O processamento paralelo é um assunto interessante e ao mesmo tempo complexo por várias razões. Imagine tentar fazer uma pessoa ler dois livros ao mesmo tempo: uma linha de um, uma linha do outro, e assim por diante. Desta forma, é difícil determinar quais atividades podem ou não ser executadas em paralelo.
Os processos paralelos podem ser classificados como concorrentes ou assíncronos. Os primeiros podem ser divididos de acordo com o tipo de interação existente entre eles. São disjuntos quando trabalham com conjuntos distintos de dados, ou interativos quando têm acesso a dados comuns. Estes últimos podem ser competitivos se brigarem por recursos e cooperativos se trocarem informações entre si. Já os processos assíncronos podem ocasionalmente interagir um com ou outro, às vezes de forma complexa.
Quando se lida com processos interativos, a ordem das operações sobre as variáveis compartilhadas pode variar no tempo, uma vez que as velocidades relativas dos processos dependem de fatores externos. Toda vez que a ordem de execução causa interferência no resultado tem-se uma race condition.
Para se entender esse conceito, suponha que três processos compartilhem uma variável A. Dois deles fazem operações de modificação e um imprime o valor da variável. Suponha também que a ordem em que estas operações são feitas é importante. Se a variável A for modificada simultaneamente pelos dois processos, o valor impresso irá depender de quando as operações de escrita forem realizadas. Para colocar em termos concretos, imagine se A = 11, e a sequência de operações seja a seguinte:
• Processo 1 = A = A+5; • Processo 2 = A = A+1; • Processo 3 = Imprimir A.
Na ordem acima, processo 3 irá imprimir o valor 17. Se a ordem for diferente, tem-se outro valor para A.
Neste exemplo, pode-se ver que os processos em execução compartilham o acesso a uma mesma variável. Eles são concorrentes interativos e estão em condição de corrida.
As condições de corrida precisam ser evitadas para garantir que o resultado de um processamento não varie entre uma execução e outra. Condições de corrida resultam em computações paralelas errôneas, pois cada vez que o programa for executado com os mesmos dados poderão ser obtidos resultados diferentes.
A programação paralela exige mecanismos de sincronização entre processos, e por isso sua codificação e depuração são mais complexas. Imagine um sistema que deva atender
requisições de serviço que ocorram de forma imprevisível e aleatória. Ele poderá ser construído para permitir que cada solicitação seja realizada por um de seus processos paralelos, gerando economia dos recursos computacionais.
A programação paralela exige do sistema operacional o suporte necessário para a criação e gerência de processos concorrentes, mecanismos de sincronização e comunicação entre processos, acesso aos dispositivos locais e remotos, e o controle de acesso a recursos compartilhados.
De acordo com o universo de possibilidades de desenvolvimento distribuído, pode-se avaliar e dividir as implementações entre as seguintes técnicas: Threads, IPC e RPC, Comunicação Sockets e Bibliotecas Paralelas.
2.6.1 O que são Pthreads
POSIX threads (Pthreads) é um padrão POSIX para threads, o qual define uma API padrão para criar e manipular threads. As bibliotecas que implementam a POSIX threads são chamadas Pthreads, sendo muito difundidas no universo Unix e outros sistemas operacionais semelhantes como Linux e Solaris (POSIX, 2015).
A designação internacional da norma é ISO/IEC 9945. A normalização das especificações POSIX surgiu de um projeto, iniciado por volta de 1985, que tinha como objetivo normalizar a API (ou interface de programação de aplicativos) para software desenhado para ser executado em diferentes versões do sistema operacional. O termo POSIX foi sugerido por Richard Stallman em resposta a um pedido da IEEE de um nome fácil de lembrar. É uma sigla aproximada de Portable Operating System Interface, com o X a representar a herança que a interface de programação de aplicações tem do sistema UNIX.
A norma POSIX especifica as interfaces do usuário e do sistema operacional em 15 documentos diferentes. A linha de comando e interface de comandos padrão é a Korn Shell. Outros programas de nível de usuário, serviços e utilitários incluem, entre centenas de aplicações, awk, echo e ed. Os serviços de nível de programa necessários incluem serviços de entrada/saída (arquivo, terminal e internet) básicos.
2.6.2 Threads
As threads reduzem o gasto desnecessário de memória e processamento, uma vez que o processo principal e os processo leves compartilham, além do segmento de código, o segmento de dados e espaço de endereçamento. Elas possuem apenas sua própria pilha de execução e o seu próprio programa counter. Cada uma roda um código sequencial, definido
no programa de aplicação do processo pesado no qual foram definidas. Portanto, quando uma thread altera um valor compartilhado ou abre um descritor de arquivo, todos os outros processos leves, ou mesmo o processo pesado, podem ter acesso a eles. As threads podem até mesmo criar outros processos leves filhos e a comunicação fica mais simples, pois tudo é compartilhado (RIBEIRO, 2004).
2.6.2.1 Hyperthreading
Os processadores com a tecnologia HT (HyperThreading) Desenvolvida pela Intel -consagram a programação paralela e uso das threads. Segundo a fabricante, o HT oferece um aumento de desempenho de até 30% dependendo da configuração do sistema (RIBEIRO, 2004).
A tecnologia HT simula em um único processador físico dois processadores lógicos. Cada processador lógico recebe seu próprio controlador de interrupção programável e conjunto de registradores. O cachê de memória, a unidade de execução, a unidade lógica e aritmética, a unidade de ponto flutuante e o barramento são compartilhados pelos processadores lógicos. Isso permite que o sistema operacional envie processos para os processadores lógicos como se estivesse enviando para dois processadores físicos, tal como em um sistema multiprocessado real (RIBEIRO, 2004).
No sistema multiprogramado com um processador comum, apenas uma thread pode ser processada por vez. No entanto, o sistema alterna os processos para otimizar as tarefas, criando um ambiente programado concorrente (RIBEIRO, 2004).
Com a tecnologia HT, o processo poderá processar duas threads simultaneamente. Este recurso somente será utilizado em sua totalidade se o sistema e as aplicações executadas fizerem uso intensivo das mesmas. O resultado será um ganho de tempo de processamento.
2.6.3 Comunicação via Sockets
O termo socket refere-se à API implementada pelo grupo de distribuição de software UNIX da Universidade de Berkeley (BSD). A interface fornecida pelo socket permite que os processos acessem os serviços de rede. A troca de mensagens é feita entre dois processos usando vários mecanismos de transporte (RIBEIRO, 2004).
A comunicação via sockets deve ser feita sempre dentro de um domínio. Um domínio é uma abstração para designar os serviços de rede, uma estrutura comum de endereçamento e protocolos entre dois pontos de comunicação em uma rede. Desta forma, processos que são executados em sistemas diferentes podem se comunicar por meio dos sockets somente se utilizarem o mesmo esquema de endereçamento, protocolo e serviços de rede.
2.6.4 O que é a comunicação IPC / RPC
A comunicação entre processos, em inglês Inter-Process Communication (IPC), é o grupo de mecanismos que permite aos processos transferirem informação entre si (RIBEIRO, 2004).
A execução de um processo pressupõe por parte do sistema operacional, entre outras coisas, a criação de um contexto de execução própria que, de certa forma, abstrai o processo dos componentes reais do sistema. Devido a esta virtualização dos recursos, o processo não tem conhecimento acerca dos outros processos e, como tal, não consegue trocar informação.
2.6.4.1 Primitivas fork() e wait()
As primitivas fork() e wait() foram as primeiras notações de linguagem para especificar concorrência. O fork inicia um novo processo que compartilha o espaço de endereçamento do processo criador. Ambos os processos, aquele que efetuou a chamada fork e o processo criado, continuam a execução em paralelo. Esta função retorna um valor que poder ser utilizado no controle de execução.
Um exemplo de programa com fork no Linux/Unix, usando primitivas padrões do próprio sistema operacional pode ser visualizado na figura 5.
Figura 5: Exemplo de código usando fork()
Fonte: Biblioteca Linux Debian, 2015.
2.7 Uso de software livre
Adotar um padrão de ferramenta que resolva um problema e, ainda assim, possa continuar sendo útil para uma série de situações, tem que ser levado em conta na portabilidade. Tanto no desenvolvimento quanto nos testes de funcionamento, a adoção pelo sistema operacional Linux é dada pela abrangência de recursos já implementados para esse sistema em diferentes ambientes. Nessa dissertação, por exemplo, adota-se o uso de software livre, mas o projeto poderia ser desenvolvido no ambiente Windows.
Com isso, leva-se em consideração a habilidade, o incentivo ao estudo e conhecimento aplicados pelo profissional e a abordagem de ‘conquistar e partilhar’ que só o software livre pode proporcionar, oferecendo, assim, a liberdade de implementação desde os pequenos trabalhos até os megaprojetos internacionais existentes (exemplo: China Grid).
2.7.1 Configuração do Sistema Operacional Debian
Debian é uma distribuição do sistema operacional GNU/Linux. Utiliza o kernel (núcleo do sistema operacional) Linux e uma série de outras ferramentas do projeto GNU (GNU isNot Unix). A distribuição vem com mais de 25.000 pacotes (softwares pré-compilados e empacotados) de fácil instalação. É constituída por softwares livres (OpenSource) e possuiu em seu “Contrato Social” o compromisso de se manter livre. Conta com uma lista bem organizada de desenvolvedores e mantenedores. É uma das mais estáveis distribuições e considerada a mais pura por não misturar com softwares proprietários (DEBIAN, 2004).
Software livre se refere à liberdade dos usuários de executarem, copiarem, distribuírem, estudarem, modificarem e aperfeiçoarem o software e com acesso ao seu código fonte (GNU, 2010).
2.8 Tecnologia de desenvolvimento padrão CUDA
Para enfrentar as grandes necessidades de resoluções de problemas e os elevados custos em termos de equipamento, principalmente no que diz respeito ao processamento, foi projetada por uma equipe da empresa NVídia a tecnologia CUDA. A capacidade de processamento aritmético de uma GPU ultrapassa a de uma CPU convencional, inclusive com arquitetura projetada para o processamento paralelo. Inicialmente projetada para uso em ambientes gráficos de jogos e afins, essa linguagem CUDA possibilitou a implementação de códigos em uma GPU (PATTERSON, 2014).
Na prática, o que se tem é uma independência de CPU do computador e, por meio de uma placa especial de vídeo (GPU), realizar o processamento. Essa tecnologia tem todo um promissor mercado em expansão, mas ainda assim, o custo do hardware continua elevado. Em um intervalo de tempo curto, inclusive esse trabalho, poder-se-ia ser desenvolvido nesse formato.
A implementação em linguagem de programação e a comunicação entre essas diferentes GPUs podem ser feitas por ferramentas disponibilizadas no site da fabricante NVidia (APÊNDICE A). Existem possibilidades de desenvolvimento tanto para o sistema operacional Linux como para o Windows e outros afins, desde que os critérios de uso sejam adequados às bibliotecas de código.
2.9 Características adotadas para uso de hardware
O hardware é a ferramenta principal para que as funcionalidades do cluster possam ser colocadas em prática. Quando se adota máquinas acessíveis e de baixo custo, deve-se avaliar a capacidade de processamento ao máximo dos recursos disponíveis.
Para a implementação do cluster, a UFTM gentilmente cedeu 05 (cinco) computadores, o espaço físico (Sala do PMPIT) e demais equipamentos básicos como: Switch 8 portas e velocidade de 1Gbps, 5 monitores, teclado e mouse; 4 cabos de rede ethernet 1000Base-T; 2 No-breaks; equipamento para refrigeração (ar-condicionado); mesas para a acomodação das estações de trabalho. Segue a seguir algumas especificações de hardware consideradas na instalação do equipamento:
Especificação 01 (Switch de Comunicação):
Entre as funcionalidades que se esperam de um switch para implementação em um cluster, esse em específico (figura 6), é de que consiga aliar baixo custo e bom desempenho nas funções de movimentação de dados pela rede. Tecnologias energéticas eficientes e inovadoras economizam energia em até 80%; suporta o controle de fluxo IEEE 802.3x para modo Full Duplex e backpressure para o modo half duplex; Arquitetura de encaminhamento sem bloqueios que encaminha e filtra os pacotes em velocidade plena pelo cabo com uma vazão máxima: 16 Gbps de capacidade de comutação; Jumbo Frame de 15K melhora o desempenho de grandes transferências de dados; Auto-MDI/MDIX elimina a necessidade de cabos cruzados; Suporta auto-aprendizagem de MAC address e seu auto-envelhecimento; A Auto-negociação das portas proporcionam uma integração inteligente entre hardware de 10Mbps, 100Mbps e 1000Mbps; Design sem ventoinha garante operação silenciosa; Design de mesa ou de montagem em parede; Design Plug and Play simplifica a instalação. O switch exerce um papel fundamental na transferência de dados em rede.
Figura 6 - Switch de Comunicação de Rede
Fonte: TPLINK, 2014.
Segundo a Associação Brasileira de Usuários de Acesso Rápido (ABUSAR, 2015):
“Um Switch mapeia endereços Ethernet dos nós que residem em cada segmento da rede e permite apenas a passagem do tráfego necessário. Quando um Switch recebe um pacote, determina qual o destino e a origem deste, e encaminha-o para a direção certa. O Switch larga o pacote se a origem e o destino são no mesmo segmento de rede. Os Switches também previnem que pacotes danificados se
alastrarem por toda a rede, melhorando assim a eficiência da transmissão dessa rede.
Existem duas arquiteturas básicas de Switches de rede: "cut-through" e "store-and-forward". Os Switches "Cut-through" apenas examinam o endereço de destino antes de reencaminhar o pacote. Um Switch "store-and-forward" aceita e analisa o pacote inteiro antes de o reencaminhar. Este método permite detectar alguns erros, evitando a sua propagação pela rede. Hoje em dia, existem diversos tipos de Switches híbridos que misturam ambas as arquiteturas. Ao escolher um Switch, escolha Switches de 8, 16 ou 24 portas RJ45, com padrão de transferência Gigabit, dependendo do número de pontos de rede a serem conectados, e de preferência a fabricantes renomados.”
Especificação 02 (Componentes Internos):
Considerando os equipamentos adotados no projeto, a relação dos componentes internos, que foram especificados, estão no Quadro 1 a seguir. Nesse modelo considerado não existe nenhum hardware adicional que interfira no desempenho do ambiente construído.
Quadro 1 - Lista dos componentes integrados a placa mãe
CPU Socket: Intel Socket 775 Supports: Conroe L,
Conroe, Wolfdale Front Side Bus: 800/1066/1333MHz
Chipset MCH (North Bridge): Intel G31 ICH (South
Bridge): Intel ICH7
Graphic Integrated Graphics in North Bridge,
DVI/TV-OUT
Memory Dual channel, 2 slots, Non-ECC, 240-pin DDR2,
Un-buffered Types: 667/PC2-5300, 800/PC2-6400
Audio Realtek ALC662 CODEC (6 Channels)
Formfactor microATX: 9.6 in. x 8.0 in.
Expansion slots 1x PCI Express Graphic slt (x16) 1x PCI
Express slot (x1) 2x PCI slot
LAN Realtek RTL8111C PCIe
1394 (none)
USB 8x USB 2.0 ports (4 onboard headers, 4 on rear
panel) 12Mbps/480Mbps
Storage 4x SATA ports (4 onboad headers) SATA300,
ATA100
BIOS AMI 4Mb SPI
Rearpanelports 1x PS2 Mouse port + 1x PS2 Keyboard port 1x
Parallel (printer) port + 1x Serial (com) port + 1x VGA (display) port 2x USB ports 1x LAN port + 2x USB ports 3x Audio ports
Selectors USB power, Keyboard power, clear RTC
Onboardconnectors 1x Front panel connector 1x Front panel audio
connector 1x SPDIF output connectorr 1x Audio (CD) input connector 2x USB 2.0 dual port connectors 1x Serial (COM) port connector 4x SATA connectors 1x Primary IDE connector 1x Internal TPM connector
Power connectors 1x 24-pin EATX (+12V EPS power connector) 1x
4-pin ATX (+12V power connector) 1x CPU FAN connector 1x Chassis FAN connector
3 METODOLOGIA PRÁTICA DO TRABALHO
Uma vez implantada todas as possibilidades do cluster, a fase de avaliação do mesmo por meio de modelos seria iniciada e continuada por testes de desempenho e de carga de dados e processamento dos aplicativos instalados. O principal diferencial está em submeter situações problemas específicos da instituição a baixo custo e com a iniciativa própria, principalmente por ser desenvolvido com recursos já existentes. Abaixo (figura 7) imagem do cluster em funcionamento.
Figura 7 - Estrutura física formada pelo cluster
Fonte: Dos autores, 2015.
De acordo com determinadas características, o ambiente paralelo possibilita melhorar o desempenho de muitas aplicações. Cada nó existente no cluster pode ser submetido a atividades diferentes. Não é necessário que uma tarefa utilize todos os componentes do cluster. Pode-se, logicamente, configurar quais nós de computação irão cooperar em um mesmo serviço. O cluster pode estar agrupado para atender diferentes serviços que o usuário queira avaliar.
A arquitetura desenvolvida deve ser vista pelos usuários como uma imagem única do sistema-SSI e as requisições feitas devem ser redirecionadas automaticamente para um equipamento que esteja disponível. Será necessário aproveitar os equipamentos existentes, sem a aquisição ou substituição destes. Apenas em certos casos, adicionar determinados nós na rede que já pertençam à instituição.
Dentre os padrões comuns considera-se: transferência de arquivos, mensagens e sessão remota SSH (COMER, 2007); Configuração de páginas web, de banco de dados e configuração de terminal gráfico (FERREIRA, 2003); Configuração da biblioteca MPI (PITANGA, 2008) para desenvolvimento de aplicações baseadas em troca de mensagens.
Conforme cada função dentro do cluster, cada nó receberá uma configuração específica e uma diversidade de pacotes de aplicações a serem executadas. Deve-se também ressaltar que no desenvolvimento do projeto é muito importante considerar a falha do cluster. A aplicação que está sendo utilizada deve ser capaz de se redistribuir e garantir o funcionamento correto do algoritmo.
4 PROJETO, ESTRUTURA E RESULTADOS DO FUNCIONAMENTO DO CLUSTER
De acordo com os requisitos do capítulo anterior, pode-se construir um cluster do tipo misto, combinando Balanceamento de Carga e Alta Performance utilizando-se as características disponibilizadas pelo Sistema Operacional Linux, pois o mesmo atende as necessidades apontadas, além de toda uma abordagem de software livre.
Esta estrutura física permite a integração de equipamentos heterogêneos quanto à usabilidade dos aplicativos e sua integração. Considera-se na figura 8 as etapas como norteadoras do desenvolvimento desse trabalho:
Figura 8 - Etapas da implantação do cluster
Fonte: Elaborado pelos autores, 2015.
A instalação física foi realizada pela combinação de equipamentos que foram aproveitados do próprio ICTE, por meio de cabos elétricos e de rede, utilização de ar condicionado próprio da sala, nobreaks e especialmente os computadores reaproveitados do antigo laboratório. A configuração da rede, a princípio usando um padrão de enumeração de IPs, depois de acordo com o DSIM, influenciou na adoção de padrões diferentes para uma nova e atual classe de endereços, sendo definida uma faixa específica para o projeto. Para a presente data desse projeto foi considerada a configuração de software sob a plataforma do sistema operacional Linux Debian Wheezy, 64 bits.
Nesse documento pode-se considerar outras distribuições levantando em princípio características afins ao cluster. A principal dificuldade encontrada esta vinculada aos ajustes
da biblioteca MPI em relação ao sistema operacional e aos seus arquivos. A existência de atribuições a vários módulos da biblioteca dificultou a configuração entre as máquinas. A etapa de simulação de testes, para verificar a comunicação entre as máquinas e a execução dos algoritmos, foi a que se apresentou mais distinta em relação ao cluster, por se tratar efetivamente da obtenção dos valores das simulações dos problemas. Observar o cluster funcionando de acordo com o que foi proposto é verificar e constatar, de fato, o mecanismo teórico visualizado na prática. A possibilidade da obtenção de resultados de problemas das áreas mais distintas do conhecimento humano, a partir do paralelismo, e saber que podem ser extraídos, por meio das etapas do diagrama anterior (figura 8), é reconhecer as suas diferentes interfaces na resolução de problemas.
Considera-se o cluster, projetado e construído no ICTE, dentro das características de multiprocessamento. Está funcionalmente operando por meio de troca de mensagens usando a biblioteca MPI. Algoritmos básicos da computação foram inseridos de forma concorrente, simulados e extraídos os resultados de suas execuções.
Durante “as tentativas” de construir um computador de alto desempenho, várias métricas foram analisadas. Problemas de infraestrutura ocorreram em momentos muito inusitados. Todos superados.
A realização do projeto com máquinas básicas conectadas entre si e seu funcionamento possibilitou um meio de ampliação para futuros estudos sobre desempenho. Com o cluster já pronto, foi percebido também que o esforço para fazer trabalhar em conjunto X máquinas em busca de uma solução para um problema complexo, torna-se mais objetivo, quanto maior for o número de equipamentos, pois a quantidade de repetições de ajustes para uma máquina podem ser facilmente replicados a outras estações.
Fator importante é considerar o cluster sempre como um projeto facilmente expansível em relação ao hardware. Observa-se a facilidade de uso com máquinas padrão notebooks que foram acrescidas ao mesmo para simulações. De toda forma, etapas de extensão de equipamentos, inclusive com ambientes operacionalmente distintos como uma possível rede sem fio, podem ser realizadas.
As telas, exibidas a seguir, foram retiradas tanto do sistema operacional, como as telas dos arquivos de configuração e suas principais características quanto ao uso no sistema Debian.
4.1 Resultados de instalação e configuração
a) Tela com exibição da configuração de rede de uma das máquinas (figura 9). Foram configuradas com endereços classe A (10.1.1.30 a 10.1.1.36) usando a máscara padrão de rede. Os números de gateway e DNS foram fornecidos pelo DSIM.
Figura 9 - Tela de configuração da placa de rede
Fonte: Dos autores, 2015.
b) As figuras 10, 11, 12, 13 e 14 representam, mediante o teste de comunicação via linha de comando (comando ping), o funcionamento físico das máquinas. Esse fato é constatado e validado a partir da comunicação do servidor para as máquinas e o processo inverso também ocorre.
Figura 10 - Tela de comunicação com o servidor
c) Tela de comunicação das estações para o servidor (PMPIT02->SRVCLUSTER)
Figura 11 - Tela de comunicação da estação 2 com o servidor
Fonte: Dos autores, 2015.
d) Tela de comunicação das estações para o servidor (PMPIT03->SRVCLUSTER)
Figura 12 - Tela de comunicação da estação 3 com o servidor
