De Cluster de Computadores

UM CLUSTER DE COMPUTADORES DE USO GERAL

Resumo -

A tecnologia de Cluster de Computadores tem conquistado espaço nos últimos anos em decorrência da queda nos custos dos computadores de uso geral, normalmente utilizados em suas conções, e também pela facilidade de implementação, tanto do ponto de vista de hardware, de software e de serviços. Desta maneira, está se tornando comum a utilização desta modalidade de ambiente computacional nas mais variadas instituições, sejam empresas, centros de pesquisas ou unidades de ensino e de negócios. Este artigo descreve a experiência adquirida no projeto, implementação, conção e uso de um ambiente deste tipo em uma universidade, porém pode ser aplicada em outras situações. No experimento relatado aqui, construiu-se um cluster de balanceamento de carga com características de alta disponibilidade e de alto poder de computação com o objetivo de disponibilizar alguns serviços específicos.

1. INTRODUÇÃO

Atualmente, muitas aplicações necessitam de um poder computacional maior do que aquele fornecido pelos computadores convencionais. 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, tais como a velocidade da luz, leis da termodinâmica ou ainda os altos custos para a fabricação de processadores [1] [2].

Uma solução viável e de custo aceitável para a questão levantada no parágrafo anterior 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 através de um ou múltiplos processadores/computadores [1] [3], 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 Maciços (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. O presente artigo aborda apenas o sistema paralelo do tipo Cluster de Computadores.

2. CLUSTER DE COMPUTADORES

Um Cluster de Computadores, também conhecido como NOW (Network of Workstations) ou 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 [4]. É uma tecnologia capaz de substituir supercomputadores em certos tipos de aplicações (como simulações, cálculos científicos entre outras) que necessitam de alto desempenho, porém com um custo substancialmente menor, utilizando processadores/computadores com menor poder computacional individual e preço mais baixo [5].

Os três tipos mais comuns de clusters encontrados atualmente são os de Alta Disponibilidade (High Availability - HA), de Alto Desempenho de Computação (High Performance Computing - HPC) e de Balanceamento de Carga (Horizontal Scaling - HS) [4].

2.1. ALTA DISPONIBILIDADE

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

2.2. ALTO DESEMPENHO DE COMPUTAÇÃO

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.

O usuário 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.

2.3. BALANCEAMENTO DE CARGA

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) [1] [4] [6].

3. A ARQUITETURA DO PROJETO

A intenção inicial que norteou o projeto foi a de disponibilizar uma série de serviços para a utilização em algumas disciplinas específicas e os mesmos, quando em uso contínuo, não poderiam acarretar no surgimento de gargalos no sistema como um todo. Além disso, a arquitetura deveria ser vista pelos usuários como uma imagem única do sistema (Single System Image - SSI) e as requisições feitas deveriam ser redirecionadas automaticamente para um equipamento que estivesse mais ocioso. Também era imprescindível aproveitar o parque computacional existente, sem a aquisição ou substituição de equipamentos.

Com base nestes requisitos iniciais, optou-se por construir um cluster do tipo Balanceamento de Carga utilizando-se as características disponibilizadas pelo Linux Virtual Server [7], pois o mesmo atendia as necessidades apontadas. A arquitetura física, representada na 01, utilizou-se dos seguintes equipamentos de hardware:

1 microcomputador Pentium I, de 133 Mhz de clock, 130 Mb de memória, 4 Gb de disco rígido e duas interfaces de rede padrão Ethernet (10 Mbps). Este equipamento atuou como nó principal.
4 workstations Sun Sparc Station IV, com 64 Mb de memória, 1.2 Gb de disco rígido e uma interface de rede padrão Ethernet (10 Mbps). Estes equipamentos atuaram como nós de computação.
1 workstation Sun Ultra1, com 300 Mb de memória, 11 Gb de disco rígido (sendo uma unidade com 1.2 Gb e outra com 10 Gb) e uma interface de rede padrão Ethernet. Este equipamento atuou como nó de armazenamento.
1 hub padrão Ethernet, responsável pela estrutura de interconexão.

Esta arquitetura física fez a integração do hardware heterogêneo sem qualquer dificuldade; utilizou-se como ponto chave para a interconectividade o padrão Ethernet e o TCP/IP [8] para atingir a interoperabilidade.

Quanto ao software, tanto o microcomputador como as workstations executaram o sistema operacional Linux [9] constituindo um cluster homogêneo quanto ao sistema operacional. O referido sistema operacional foi instalado em seus discos locais. Excepcionalmente, o disco de 10 Gb foi compartilhado entre todos os nós de computação utilizando-se o NFS [10]. Para realizar o balanceamento de carga utilizou-se o IPVS [7], além do NIS [11] para a autenticação dos usuários e do NAT [12] para isolar a estrutura de interconexão do cluster da rede externa.

4. SERVIÇOS DISPONIBILIZADOS

Uma vez implementada a infra-estrutura de hardware, instalados os sistemas operacionais e viabilizada a interconectividade e interoperabilidade dos nós, passou-se para a implementação dos serviços que o cluster deveria viabilizar. Foram disponibilizados os serviços de transferência de arquivos (ftp) [8], de páginas web [13], de banco de dados [14], de sessão remota (telnet) [8] e de terminal gráfico [15]. Além destes serviços, foi instalada e conda também a biblioteca MPI [16] para desenvolvimento de aplicações baseadas em troca de mensagens.

Conforme sua função dentro do cluster, cada nó recebeu um tipo de conção e uma gama de serviços. O nó principal, por exemplo, executava os serviços de páginas web, tradução de endereços (NAT) e o balanceamento de carga (IPVS). Já os nós de computação possuiam instalados todos os serviços que o cluster efetivamente oferecia e o nó de armazenamento apenas os serviços de compartilhamento de arquivos (NFS) e o de autenticação de usuários (NIS). Esta divisão de tarefas pode ser vista na 02.

É importante ressaltar que além da arquitetura física e dos serviços houve a necessidade de criar um endereço virtual para o cluster. Isto tornou-se necessário para que fosse possível desvincular o endereço real do equipamento que faria o balanceamento das requisições do endereço efetivo do cluster, visto que, em uma eventual parada do equipamento real, o endereço virtual poderia ser transferido para um balanceador de carga reserva.

5. DISCUSSÃO E RESULTADOS

A estrutura disponibilizada pelo projeto oferece aos usuários que estão conectados à rede externa uma gama de serviços utilizados em algumas disciplinas. A 03 demonstra a maneira como a requisição geral de um serviço genérico é realizada e como o cluster irá atendê-la. Os passos, em detalhes, são os seguintes:

1. O usuário efetua a requisição por um serviço (ftp, http, terminal gráfico, telnet ou query) endereçando a mesma ao endereço do cluster (endereço virtual).

2. O balanceador de carga, ao receber a requisição, irá determinar qual dos nós de computação será o responsável por atender a requisição. Isto é realizado através de um dos algoritmos implementados pelo IPVS, definido no momento da conção do balanceador.

3. A requisição é encaminhada ao nó de computação determinado pelo algoritmo do IPVS.

4. O nó de computação em questão processa a requisição vinda do balanceador.

5. Ao obter os resultados do processamento da requisição, o nó de computação encaminha-os para o balanceador de carga.

6. O balanceador de carga recebe os resultados da requisição processada e determina qual é o usuário remetente da requisição e, consequentemente, o destinatário dos resultados.

7. Após determinado o usuário, os resultados da requisição são enviados ao mesmo e então consumidas pelo usuário.

Apesar da existência de vários nós de computação no cluster, não necessariamente um serviço é obrigado a utilizar todos eles. Pode-se, logicamente, conr quais nós de computação irão cooperar em um mesmo serviço. Por exemplo, supondo a existência dos nós de computação NO01, NO02, NO03 e NO04; o serviço de banco de dados poderia utilizar apenas os nós NO01 e NO02, já o serviço de ftp poderia utilizar os nós NO03 e NO04, o serviço de páginas web usaria os nós NO01 e NO04 e o serviço de telnet utilizaria os nós NO02 e NO03, finalmente o serviço de terminal gráfico utilizaria realmente todos os nós.

Uma outra maneira de se visualizar estas atribuições físicas e lógicas seria:

* Nós de Computação Existentes Fisicamente = { NO01, NO02, NO03, NO04 }

* Nós de Computação Responsáveis pelo Serviço de Banco de Dados = { NO01, NO02 }

* Nós de Computação Responsáveis pelo Serviço FTP = { NO03, NO04 }

* Nós de Computação Responsáveis pelo Serviço Web = { NO01, NO04 }

* Nós de Computação Responsáveis pelo Serviço Telnet = { NO02, NO03 }

* Nós de Computação Responsáveis pelo Serviço de Terminais Gráficos = { NO01, NO02, NO03, NO04 }

No cluster deste projeto, todos os nós de computação estão logicamente agrupados para atenderem a todos os serviços disponibilizados aos usuários. Essa decisão foi tomada para aumentar o grau de replicação dos serviços, consequentemente, de disponibilidade dos mesmos.

A alta disponibilidade, seja de hardware como de serviços, pôde ser obtida graças à replicação dos nós de computação e dos respectivos serviços que os mesmos processam. Assim, caso um nó de computação venha a tornar-se indisponível, os nós restantes garantem o processamento das requisições por serviços que venham a receber, porém com uma queda em seu desempenho devido à degradação graciosa.

O aumento na capacidade de processamento pôde ser observada sob a ótica do atendimento dos serviços requisitados, ou seja, as requisições pelos respectivos serviços são atendidas mais rapidamente pelo fato das mesmas serem distribuídas entre os vários nós de computação que realizam o processamento ao invés de concentrá-las em um único equipamento. O ganho não está em aumentar o poder computacional de um equipamento específico mas sim em diminuir o tempo de resposta ao usuário, aumentando o poder do cluster como um todo.

Uma questão importante a se ressaltar na atual implementação do projeto é a existência de possíveis pontos de falha do cluster, como por exemplo o nó balanceador de carga, o nó de armazenamento e a rede de interconexão, pois os mesmos não possuem réplicas.

Um outro ponto importante, que trouxe algumas preocupações, foi quanto a capacidade do balanceador de carga em gerenciar o tráfego de rede. Esta preocupação surgiu da constatação de que todo o tráfego que entra ou sai do cluster deveria obrigatoriamente passar por ele, assim havia um temor de que o mesmo viesse a transformar-se em um gargalo, o que, felizmente, não aconteceu. Durante a utilização da arquitetura e dos serviços disponibilizados não foi percebida nenhuma alteração na capacidade de comunicação do nó balanceador para os usuários e restante do cluster.

Um problema detectado e que ainda não foi solucionado reside no serviço de banco de dados. Na verdade, o problema foi detectado neste serviço mas o mesmo reside no serviço de arquivos utilizado pelos nós de computação. Após algumas análises no funcionamento concluiu-se que o problema está relacionado com a latência existente na atualização dos cachês dos nós de computação com o cachê do nó de armazenamento, utilizados pelo NFS. É possível que este problema se estenda aos demais serviços, mas está mais evidente no acesso ao banco de dados pela própria natureza do serviço.

6. ATIVIDADES FUTURAS

Conforme mencionado na seção anterior, foram detectados na atual implementação alguns pontos de falha, como o nó balanceador, o nó de armazenamento e a rede de interconexão. Alguns destes pontos de falha, mais especificamente no nó balanceador e no nó de armazenamento, podem ser removidos se implementada uma nova conção, representada pela 04. Assim, esta nova conção poderia ser entendida como uma atividade futura, derivada da atual conção.

Nesta nova conção observa-se uma réplica do nó de balanceamento (nó principal primário) denominada nó principal secundário que deverá entrar em funcionamento ao “perceber” a indisponibilidade do nó principal primário, assumindo o endereço virtual do cluster e as tarefas que eram executadas por ele anteriormente. Quando o nó principal primário voltar à atividade, o nó principal secundário deve retornar ao estado de espera. Esta característica de failover e failback [17] pode ser viabilizada pelo mecanismo conhecido como heartbeat [18].

De funcionamento análogo ao utilizado na replicação do nó principal (primário e secundário), trabalha-se com a replicação do nó de armazenamento (primário e secundário). Neste caso existe a intenção de replicar o serviço de arquivos e de autenticação de usuário e, para atender a esta funcionalidade, utiliza-se novamente o mecanismo de heartbeat e um serviço denominado drbd [19], utilizado para sincronizar discos.

Observa-se também nesta nova arquitetura o aparecimento de duas redes internas. A Rede Interna 1 destina-se a viabilizar a comunicação apenas dos nós balanceadores de carga (principal e secundário) com os nós de computação e entre os próprios nós de computação. Já a Rede Interna 2 seria utilizada para viabilizar todo o acesso à disco que os nós de computação necessitassem realizar, isto poderia ser feito através de uma velocidade ainda maior que a utilizada na Rede Interna 1. Esta alteração mostra-se interessante pois aliviaria o tráfego existente na única rede interna da arquitetura atual, distribuindo-o.

Com estas mudanças a disponibilidade do cluster seria ampliada, pois tanto o equipamento que realiza o balanceamento, como os de processamento e o de armazenamento possuiriam réplicas de hardware, de software e de serviços.

Uma outra possibilidade para atividade futura seria a construção de um cluster heterogêneo do ponto de vista de software e homogêneo quanto ao hardware. Conforme descrito nas seções anteriores, o projeto atual utilizou Linux tanto no nó principal como nos nós de computação e armazenamento. Uma possibilidade seria a de substituir, por exemplo, o Linux dos nós de computação pelo MS-Windows e no nó de armazenamento pelo Novell Netware e todos eles sendo executados em ambientes com processadores convencionais. Esta mudança acarretaria em algumas alterações nos serviços disponibilizados pois os mesmos deveriam suportar a execução no MS-Windows.

7. CONCLUSÃO

Ao concluir o projeto, foi possível constatar alguns pontos que comprovaram a teoria estudada. Dentre eles destacam-se a questão quanto a funcionalidade do cluster de balanceamento de carga comportar-se também como um cluster de alta disponibilidade e alto desempenho de computação e também a validação de que a tecnologia de cluster de computadores pode ser vista como uma evolução das redes de computadores.

Um outro ponto importante que pôde ser verificado foi quanto às aplicações Web que executavam no ambiente tradicional e que foram portadas para o ambiente do cluster. Constatou-se que as mesmas funcionaram normalmente no novo ambiente, sem que fossem feitas mudanças substanciais em seu código-fonte.

Ainda sobre as aplicações, o ambiente comportou-se muito bem quando interagindo com aplicações construídas utilizando C++ e Delphi. Neste caso, as aplicações utilizavam as funcionalidades dos protocolos de aplicação e transporte do TCP/IP.

A implementação atendeu a todos os requisitos levantados no projeto, inclusive superando algumas expectativas que existiam no início e apesar de sua utilização ter sido realizada em um ambiente acadêmico, o mesmo pode ser estendido para outros tipos de organizações, como empresas, provedores de informações, provedores de aplicações por exemplo.

Sobre o hardware utilizado no cluster, foram utilizados no projeto equipamentos não convencionais (workstations Sun) mas é possível recriar o experimento realmente utilizando equipamentos de prateleira e, acrescentando e removendo componentes quando forem necessários, garantindo assim a escalabilidade, a modularidade e o aproveitamento do parque computacional existente nas organizações.

Quanto aos serviços suportados pelo cluster, existe a possibilidade de ampliação dos mesmos. Os serviços citados neste artigo se restringem apenas aos que eram necessários para o uso nas disciplinas mas é totalmente viável e adaptável a utilização de outros com pequenas conções.

REFERÊNCIAS BIBLIOGRÁFICAS

[1] BUYYA, Rajkumar. High Performance Cluster Computing: Architectures and Systems, volume 1 - Prentice Hall, 1999.

[2] FOSTER, Ian. Designing and Building Parallel Programs - Addison-Wesley, 1995.

[3] STALLINGS, William. Arquitetura e Organização de Computadores - São Paulo: Prentice Hall, 2002.

[4] MANOEL, Edson e FERREIRA, Luis. Linux Clustering with CSM and GPFS - http://www.redbooks.ibm.com/redpieces/pdfs/sg246601.pdf, (Fev/2003).

[5] STERLING, Thomas. Beowulf: A Parallel Workstation for Scientif Computation - http://www.beowulf.org/papers/ICPP95/icpp95.ps, (Fev/2003).

[6] BIRMAN, Kenneth. Building Secure and Reliable Network Applications - http://www.cs.cornell.edu/ken/book.pdf, (Fev/2003).

[7] Linux Virtual Server Project - http://www.linuxvirtualserver.org, (Fev/2003).

[8] COMER, Douglas. Internetworking with TCP/IP: Principles, Protocols, and Architecture, volume 1, Prentice Hall, 2000.

[9] LINUX On-Line - http://www.linux.org/info/index.html, (Fev/2003).

[10] FARREL, Paul A.. NFS: Distributed File System - http://dune.mcs.kent.edu/~farrell/sa96/notes/nfs/nfs.html, (Fev/2003).

[11] Linux Network Administrators Guide: The Network Information System - http://www.faqs.org/docs/linux_network/x-087-2-nis.html, (Fev/2003).

[12] TANENBAUM, Andrew. Redes de Computadores - Rio de Janeiro: Editora Campus, 2003.

[13] Apache Web Server - http://www.apache.org, (Fev/2003).

[14] Banco de Dados MySQL - http://www.mysql.com, (Fev/2003).

[15] The XFree86 Project - http://xfree86.org, (Fev/2003).

[16] LAM/MPI Parallel Computing - http://www.lam-mpi.org, (Fev/2003).

[17] Guia do Servidor Conectiva Linux - http://www.conectiva.com/doc/livros/online/8.0/servidor/ha.html, (Fev/2003).

[18] ROBERTSON, Alan. Linux-HA Heartbeat System Design - http://linux-ha.org/comm/Hbdesign.pdf, (Fev/2003).

[19] Grupo de Usuários Slackware - http://gus-br.linuxmag.com.br/documentacao/ha-slack/mini.pdf, (Fev/2003).

Please be aware that the free essay that you were just reading was not written by us. This essay, and all of the others available to view on the website, were provided to us by students in exchange for services that we offer. This relationship helps our students to get an even better deal while also contributing to the biggest free essay resource in the UK!