PONTIFICIA UNIVERSIDADE CATOLICA DE MINAS GERAIS

Bacharelado em Sistemas de Informacao

ESTUDO COMPARATIVO ENTRE PLATAFORMA MONOPROCESSADA E

CLUSTER COMPUTING SOBRE AS METRICAS DE DESEMPENHO

Fabio Leandro Rodrigues Cordeiro

Guanhaes2010

Fabio Leandro Rodrigues Cordeiro

ESTUDO COMPARATIVO ENTRE PLATAFORMA MONOPROCESSADA ECLUSTER COMPUTING SOBRE AS METRICAS DE DESEMPENHO

Trabalho de Diplomacao apresentado ao Cursode Sistemas de Informacao da Pontifıcia Uni-versidade Catolica de Minas Gerais como requi-sito parcial para obtencao do tıtulo de bacharelem Sistemas de Informacao.

Orientador: Prof. Dorirley Rodrigo Alves

Guanhaes - MGNovembro/2010

Fabio Leandro Rodrigues Cordeiro

ESTUDO COMPARATIVO ENTRE PLATAFORMA MONOPROCESSADA E CLUSTER

COMPUTING SOBRE AS METRICAS DE DESEMPENHO

Trabalho de Diplomacao apresentado ao Curso de

Sistemas de Informacao da Pontifıcia Universidade

Catolica de Minas Gerais.

Dorirley Rodrigo Alves (Orientador) - PUC Minas

Carlos Renato Storck - PUC Minas

Joao Paulo Domingos Silva - PUC Minas

Guanhaes, 27 de novembro de 2010

A minha Familia, Mae, Pai e Irmaos. Pois e a eles a quem recorro em meus pensamentos,

quando preciso falar pra mim mesmo que sou capaz, pois e neles que encontro apoio

incondicional de quem acreditam em minha capacidade.

Aos amigos. Pessoas estas que dao sentido verdadeiro a palavra amizade, aos quais

considero um honra poder chama-los de amigos Jefferson, Rone e Giovanni.

A minha namorada Carine.Pela ajuda, paciencia e companheirismo que me foram tao

confortantes em momentos difıceis nesta caminhada.

AGRADECIMENTOS

A Deus, por colocar as pessoas certas nos momentos oportunos em minha vida, fazendo

assim que eu me tornasse a pessoa que sou e que pretendo ser.

Ao professor Dorirley Rodrigo, aquele que carrega em si dentre varios outros dons um

em especial que e a arte de ensinar nao so o que tem a academia mais sim o que tem a vida.

Ao professor Alexandre Teixeira, pela co-orientacao deste trabalho, na qual contribuiu

efetivamente para a sua conclusao.

Ao professor Marcelo Nery, ao qual acreditou e contribuiu para que eu possa almejar

esta conquista de graduacao.

Aos professores da PUC Minas, que durante este tempo contribuiram pela construcao

deste profissional e pessoa que sou hoje.

A Carine pelo ajuda com as correcoes, ao Giovanni pelo apoio com Linux ao Maycon

pela dicas com o Latex e aos outros Taichous, Giorgi e Gilvam pelo excelente trabalho em

equipe nesses quatro anos.

RESUMO

Este trabalho tem por objetivo fazer um estudo comparativo entre dois ambientes de redes,

monoprocessado e um com carga dividida, podendo assim verificar o comportamento destes

modelos em uma situacao real que e o processo de restauracao de imagens do laboratorio da

PUC Minas, por meio de uma ferramenta de clonagem de discos rıgidos. Primeiro foram real-

izadas pesquisas para definicao das ferramentas e parametros de testes de carga dos ambientes.

O segundo passo foi a preparacao dos ambientes, o monoprocessado com um servidor dedicado

e o aglomerado de computadores com estacoes comuns, sendo essas com a mesma configuracao

das estacoes clientes. A terceira fase deste trabalho teve como tarefa a submissao dos dois ambi-

entes a testes nas mesmas condicoes, gerando assim dados analıticos dos quais foram utilizadas

para a ultima fase de analise e conclusao destes dados. Na ultima etapa, foram indentificadas

restricoes quanto a instalacao da solucao distribuıda em um ambiente com rede comum, entre-

tanto foi observado que este ambiente comportou-se de maneira a proporcionar balanceamento

de carga mesmo em situacao de grande quantidade de trafego, o que nao ocorreu no ambiente

monoprocessado.

Palavras-chave: Cluster Trivial Database, Sistemas de Arquivos Distribuıdos, Linux.

ABSTRACT

This work aim to make a comparative study between two network environments, a single-

processor and load divided so they can check the behavior of these models in a real situation that

is the process of image restoration laboratory at PUC Minas from the tool a hard disk cloning.

Were first were investigated to define the tools and parameters load testing environments. The

second step was the preparation of environments, the single-processor with a dedicated server

and the cluster of computers that had four seasons with the same settings of the client stations.

The third phase of this study was to task the submission of two environmental tests under the

same conditions generating analytical data, which were used for the last phase of analysis and

conclusion of these data. In the last step, was identified restrictions on the installation of the

solution in a distributed environment with common network, however it was noted that this

environment is behaving so as to provide load balancing even in the case of large amount of

traffic, which did not occur in the environment single-processor

Key-Words: Cluster Trivial Database, Distributed File Systems, Linux.

LISTA DE FIGURAS

Figura 1 Estrutura interna do CTDB . . . . . . . . . . . . . . . . . . . . . . . . 22

Figura 2 Etapas do metodo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Figura 3 Fluxo de instalacao do ambiente monoprocessado . . . . . . . . . . . . 25

Figura 4 Ambiente monoprocessado . . . . . . . . . . . . . . . . . . . . . . . . 26

Figura 5 Ambiente clusterizado . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Figura 6 Fluxo de instalacao do ambiente clusterizado . . . . . . . . . . . . . . . 28

Figura 7 Desempenho da taxa de transferencia dos ambientes mono e distribuıdo. 32

Figura 8 Tempo gasto para restauracao das imagens nos dois ambientes. . . . . . 33

LISTA DE TABELAS

Tabela 1 Processo de restauracao de imagem no ambiente monoprocesado . . . . . 30

Tabela 2 Processo de restauracao de imagem no ambiente clusterizado . . . . . . . 31

Tabela 3 Restauracao nos dois ambientes com carga mınima . . . . . . . . . . . . 31

Tabela 4 Quadro comparativo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

LISTA DE SIGLAS

CTDB Cluster Trivial Database

JAI Jornada de Atualizacoes em Informatica

SBC Sociedade Brasileira da Computacao

DHCP Dynamic Host Configuration Protocol

FTP File Transfer Protocol

vsFTPd Very Secure File Transfer Protocol Daemon

NT New Tecnology

IBM International Business Machine

OS/2 Operating System/2

GNU GNU is Not Unix

SMB Server Message Block

CIFS Common Internet File System

NASA National Aeronautics and Space Administration

GPFS General Parallel File System

GFS Global File System

OCFA Oracle Cluster File System

API Application Programming Interface

FUSE FileSystem Userspace

CSM Cluster System Management

AIX Advanced Interactive eXecutive

WCCS Microsoft Windows Cluster Computer

PUC Pontifıcia Universidade Catolica

G4U Ghost For Unix

GHz Giga-Hertz

GB Giga-Byte

RAM Random Access Memory

MHz Mega-Hertz

SCSI Small Computer System Interface

RPM Rotacoes por minuto

IDE Integrated Development Environmen

MB/s Mega Bytes por segundo

SUMARIO

1 INTRODUCAO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

1.1 Justificativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

1.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

1.2.1 Objetivo geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

1.2.2 Objetivos especıficos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2 FUNDAMENTACAO TEORICA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.1 Redes de computadores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.2 Ambientes de redes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.2.1 Redes Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.2.2 Redes GNU/Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.3 Tecnologias de redes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.3.1 Samba . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.3.2 Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.3.3 CTDB - Cluster Trivial Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3 ESTADO DA ARTE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.1 Sistemas de processamento paralelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.2 Sistemas de arquivos com suporte a clusters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.3 Clusters proprietarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.4 Cluster no Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4 METODO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.1 Etapa 1 - Definir ferramentas de testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.2 Etapa 2 - Instalacao dos ambientes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.2.1 Ambiente monoprocessado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.2.2 Ambiente clusterizado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.2.3 Instalacao do sistema de arquivos distribuıdo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.3 Etapa 3 - Coleta de dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.3.1 Descricao dos experimentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.3.2 Coleta de dados do ambiente monoprocessado . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.3.3 Coleta de dados do ambiente distribuıdo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.3.4 Experimento de restauracao para uma estacao cliente . . . . . . . . . . . . . . . . . . . . . 30

4.4 Etapa 4 - Analise dos resultados obtidos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.4.1 Analise das taxas de transferencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.4.2 Analise do tempo de conclusao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.4.3 Analise dos testes com menor carga . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

5 CONSIDERACOES FINAIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

5.1 Analise comparativa dos resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

5.2 Limitacoes do metodo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

5.3 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

5.4 Consideracoes finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Referencias Bibliograficas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Apendice A - Instalacao do GlusterFS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Apendice B - Arquivos de configuracao do Samba e do CTDB . . . . . . . . . . . . . . . . . . . . . . . 43

Apendice C - Instalacao do vsFTPd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

13

1 INTRODUCAO

Pode se observar, como resultado da popularizacao da Tecnologia da Informacao, o

acesso cada vez maior a todo tipo de trafego de dados em uma instituicao, tanto na Internet,

quanto em outras mıdias. Torna-se notavel a partir de tais pressupostos o aumento do trafego nas

redes de computadores. Diante do exposto, surge a necessidade do aperfeicoamento constante

do processamento e armazenamento desses dados, especialmente em servidores.

O armazenamento de grandes quantidades de dados em servidores pode gerar problemas

relacionados aos seus acessos como: possıveis indisponibilidades e necessidade de computa-

dores robustos para realizar processamento desse grande volume de arquivos em rede (ALVES,

2005).

Dentre as tecnologias que vem ganhando destaque para minimizar o impacto causado

por estes problemas, podemos citar o Samba, que se trata de uma aplicacao desenvolvida ini-

cialmente para prover comunicacao entre o sistema operacional Linux aos servicos oferecidos

pela plataforma Windows, dentre eles, armazenamento e compartilhamento de arquivos e im-

pressoras (ALVES, 2005).

O ambiente Samba caracteriza-se por prover acesso e controle de permissao aos dados

armazenados, alem de possuir funcao de interoperabilidade entre redes heterogeneas constituı-

das por maquinas com os sistemas operacionais Windows e Linux. Sua motivacao inicial se deu

pela questao da interoperabilidade, o que possibilitaria uma comunicacao entre os referidos am-

bientes. Esse fator e considerado como requisito basico para aceitacao de servidores e clientes

Linux em meio as redes de computadores, haja vista a popularizacao das solucoes Microsoft e

o uso de seus sistemas em redes coorporativas e domesticas (ALVES, 2005).

Em relacao ao processamento de grandes quantidades de dados podemos citar o Clus-

ter Computing, definido como um conjunto de computadores com proposito de realizar tarefas

de forma cooperada (TEIXEIRA; BARROS; COELHO, 2000). Esta tecnologia, Cluster Com-

puting, normalmente recebe traducao no idioma portugues para agregado ou aglomerado de

computadores, que a partir de entao sera abordado apenas por cluster, em consonancia com a

maioria dos autores brasileiros que optam por nao traduzir o termo (AVILA, 2005). O cluster e

uma tecnologia que vem se desenvolvendo de maneira agil nas ultimas decadas. Tal crescimento

e justificado por Teixeira, Barros e Coelho (2000) pela sua caracterıstica de integracao as redes

existentes e tambem por ser uma alternativa de menor custo em relacao aos outros sistemas

paralelos existentes, alem de oferecer um alto nıvel de escalabilidade (TEIXEIRA; BARROS;

COELHO, 2000).

14

A juncao dessas duas tecnologias, Cluster e Samba, deu origem ao Cluster Trivial

Database, CTDB. Trata-se de um sistema de armazenamento distribuıdo de arquivos adicionado

ao Samba com caracterısticas que permitem a configuracao da base de dados entre os nos de

um cluster de servidores Linux. Em sıntese, o CTDB e um software adicionado a ultima versao

do Samba, que atraves de um servico (daemom) executado permanentemente em cada no do

cluster, permite acesso aos arquivos da base de dados na rede, proporcionando dessa forma um

balanceamento de carga (ADAM, 2009a).

1.1 Justificativa

Em geral, empresas de grande porte investem em servidores com alto poder de proces-

samento e armazenamento de dados. Alternativa esta que nao e praticavel para a maioria das

empresas de pequeno e medio porte por questoes de custo, mesmo tendo consciencia da im-

portancia dos dados dentro de uma organizacao. Devido a tal fato, justifica-se a implantacao

de um ambiente que possa permitir um alto nıvel de processamento e armazenamento de da-

dos com seguranca proporcionada pela redundancia entre os servidores clusterizados atraves do

software CTDB.

Outra questao que motiva a realizacao desse trabalho e a relevancia que esta sendo apli-

cada ao assunto cluster na comunidade academica. Tal fato pode ser observado pela quantidade

de publicacoes nessa area na ultima decada, alem de ser tema de congressos importantes na

area da computacao, onde inclusive nesse ano de 2010 ouve a Jornada de Atualizacao em In-

formatica, JAI1 no XXX Congresso da Sociedade Brasileira da Computacao, SBC.

1.2 Objetivos

1.2.1 Objetivo geral

O objetivo deste trabalho e identificar o desempenho do processo de clonagem e

restauracao de imagens (clones de discos rıgidos) em ambiente monoprocessado e clusterizado.

1JAI Introducao aos clusters verdes de servidores – Daniel Mosse (UPitt), Julius Leite (UFF).http://www.inf.pucminas.br/sbc2010/

15

1.2.2 Objetivos especıficos

a) Definir os passos para a configuracao dos ambientes.

b) Definir as ferramentas de testes de carga dos ambientes.

c) Instalar o ambiente monoprocessado com servidor Windows 2003 e disponibilizar os

servicos de Dynamic Host Configuration Protocol, DHCP e File Transfer Protocol, FTP.

d) Instalar o ambiente clusterizado no qual sera composto por servidor Linux com Samba insta-

lado com suporte ao CTDB sobre o sistema de arquivos distribuıdo GlusterFS2 e tendo como

servicos disponıveis o DHCP e o Very Secure File Transfer Protocol Daemon, vsFTPd.

e) Definir os procedimentos necessarios para a realizacao dos testes.

f) Gerar graficos e tabelas comparativas do desempenho dos testes a fim de criar um quadro

com objetivo de ilustrar as vantagens e desvantagens de cada ambiente.

g) Comparar resultados gerados por ambos os ambientes a fim de avaliar aspectos positivos e

negativos dos mesmos.

2GlusterFS: GNU File System

16

2 FUNDAMENTACAO TEORICA

Este capıtulo almeja apresentar as tecnologias que serao abordadas e os ambientes em

que elas se aplicam, bem como suas nomenclaturas, com intuito de facilitar a leitura e o en-

tendimento do presente trabalho.

2.1 Redes de computadores

Com o aumento exponencial do uso de computadores nao so em meios academicos como

em todos os seguimentos economicos e ate mesmo nos lares, popularizou-se tambem o uso das

redes de computadores. Atualmente e muito comum em ambientes domesticos encontrarmos

pequenas redes com poucos computadores interconectados compartilhando recursos entre si.

Tais redes hoje sao consideradas simples em funcao dos avancos tecnologicos na area de redes,

que vem sendo alcancados ha varias decadas.

Tanenbaum (2003) afirma que as redes surgiram com a ligacao de computadores entre si

e posteriormente com a interconexao dessas ligacoes com outros computadores em localidades

diferentes.

As redes de computadores passaram a substituir o modelo computacional antigo, no

qual todo o processamento estava contido em uma sala com um computador com grandes

proporcoes, que por sua vez atendia todas as necessidades computacionais da organizacao

(TANENBAUM, 2003).

A partir dessa rede de computadores interconectados foi possıvel entao permitir uma

comunicacao e disponibilidade de varios recursos computacionais entre toda a rede como ar-

quivos, impressoras, dentre outros. Sendo assim, esse compartilhamento de recursos permitiu o

acesso a todos os programas, equipamentos e principalmente dados para os usuarios conectados

a rede (TANENBAUM, 2003).

2.2 Ambientes de redes

O compartilhamento dos recursos anteriormente referidos tornou-se uma tarefa mais

facil com advento dos ambientes de redes mais simples. Cabe citar os gerenciados pelos sis-

17

temas operacinais Windows e Linux, que provem interfaces amigaveis e com varios recursos de

redes.

2.2.1 Redes Windows

O ambiente de redes Windows popularizou-se no mercado na decada de 90 com o

lancamento pela Microsoft Corporation do Windows NT1. Tal sistema foi desenvolvido em

sua fase inicial com parceria da International Business Machine, IBM, onde desenvolvedores

da Microsoft trabalhavam na implementacao do novo sistema operacional para servidores, e no

melhoramento do sistema OS/22 da entao parceira IBM (AUGUSTO, 2001).

2.2.2 Redes GNU/Linux

O Linux teve sua criacao em 1991 pelo entao estudante universitario Linus Torvalds,

da Finlandia. O projeto teve como proposta inicial uma derivacao do sistema Minix, sistema

modelo com fins academicos escrito por Andrew S. Tannenbaum (NEMETH; SNYDER; HEIN,

2004).

Siever et al. (2006) afirma que desde sua criacao, o projeto cresceu exponencialmente

e deixou de ser uma brincadeira de estudantes que tinham o foco no competitivo mercado de

servidores, passando a ser um sistema respeitado em ambientes academicos e corporativos.

Esta ascensao do sistema operacional se deu devido a participacao de varios progra-

madores ao redor do mundo em seu kernel3, e tambem, fundamentalmente com a juncao deste

nucleo ao projeto GNU is Not Unix, GNU, projeto este desenvolvido e mantido pela Free

Software Foundation, que e a mantenedora do desenvolvimento de varias ferramentas, aplica-

tivos e outros componentes de software. Com essa juncao o Linux passou a ser chamado de

GNU/Linux (SIEVER et al., 2006).1NT: New Tecnology que deu origem ao nome do novo sistema de servidores da Microsoft, o Windows NT.2OS/2: Sistema operacional da IBM3Kernel: Nucleo do sistema operacional

18

2.3 Tecnologias de redes

A utilizacao destes dois ambientes de redes, Windows e Linux, expandiu notavelmente,

sendo o primeiro, com destaque para maquinas clientes e o segundo para servidores. Tal fato

motivou a criacao de ferramentas que fornecem interoperabilidade entre esses sistemas, como

o projeto Samba.

2.3.1 Samba

Silva (2007) afirma que o Samba e um servidor com determinadas ferramentas, que

possibilita a comunicacao entre os sistemas operacionais Linux e Windows e que propicia o

compartilhamento de recursos como arquivos, diretorios e impressao. O autor mostra que a

comunicacao se da atraves dos protocolos Server Message Block e Common Internet File Sys-

tem, SMB/CIFS, esses por sua vez se equivalem ao NetBEUI, protocolo utilizado no Windows

com a interface de transporte NetBIOS. Tendo em vista tais caracterısticas, o Samba se torna

uma solucao capaz de interligar redes heterogeneas.

2.3.2 Cluster

Para Gropp (2003) cluster e um aglomerado de computadores com processamento pa-

ralelo, divido entre nos, e que por sua vez compartilham recursos de memoria e disco rıgidos

entre todos os processadores conectados a rede.

... um cluster e um computador paralelo construıdo de componentes e proces-sos de software (tal como sistema de software). Um cluster e formado de nos,cada um contendo um ou mais processadores, memoria que e compartilhadapor todos os processadores do nodo (somente eles), e dispositivos perifericosadicionais (tais como discos), conectados pela rede e que permitem trafego dedados entre os nos... Traducao4 (Gropp, 2003; p.10)

Ainda segundo o raciocınio de Gropp (2003) os clusters podem ser divididos em dois

tipos, os prepackaged e os do-it-youself. No primeiro, pre-embalados, sao utilizados equipa-

mentos especıficos para ambientes clusterizados. Enquanto que no do-it-youself, que significa4 . . . a cluster is a parallel computer that is constructed of commodity componets and runs (as its system

software) commodity software. A cluster is made of nodes, each conteining one or more processors, memory thatis shared by all of the processors in (and only on) the node, and addtional peripheral devices (surch as disks),connected by network that allows data to move between the nodes

19

faca voce mesmo, a composicao dos nos e distribuıda em maquinas de proposito geral como

computadores de mercado (GROPP, 2003).

De acordo com Avila (2005) a utilizacao do segundo tipo, do-it-youself, vem sendo um

dos grandes motivadores para o uso dos clusters em grande escala pelo mundo. Haja vista

que a utilizacao de componentes de “prateleira”, como o autor define os equipamentos comuns

de mercado, facilitam e motivam o crescimento da computacao baseada em cluster devido ao

alto nıvel de escalabilidade. Tal caracterıstica possibilita o uso e reposicao de componentes do

cluster por componentes mais atualizados.

Segundo Avila (2005) outro ponto motivador da popularizacao de ambientes clusteri-

zados e a utilizacao de softwares com codigo aberto, o que impacta diretamente na reducao

de custos devido ao fato de que esses softwares sao gratuitos. Conforme pode ser observado,

o CTDB e um aprimoramento do Samba com finalidade de permitir suporte ao sistemas de

arquivos em cluster.

2.3.3 CTDB - Cluster Trivial Database

Adam (2009a) afirma que o CTDB teve seu inıcio em 2006, por uma equipe de desen-

volvedores liderada por Volker Lendecke e Andrew Tridgell. Sua primeira versao ja utilizavel,

mas ainda em fase de testes, foi lancada em 2007. Ele ainda assevera que atualmente o principal

autor e mantenedor do projeto e o desenvolvedor Sahberg Ronnie.

De acordo com Adam (2009b) o CTDB e um complemento do Samba que oferece su-

porte a sistemas de arquivos em cluster. Tal caracterıstica permite que o Samba tenha seu sis-

tema de arquivos distribuıdo entre nos de uma rede que se apresentam como um unico servidor

de arquivos com alto desempenho baseado em cluster.

Sua estrutura basica consiste na apresentacao de multiplos nos da rede em um unico

servidor Samba na visao dos clientes. Tais instancias da rede sao configuradas de maneira

uniforme com compartilhamento identico dos recursos disponıveis. Dessa maneira o CTDB

propicia um balanceamento de carga por meio do cluster.

20

3 ESTADO DA ARTE

3.1 Sistemas de processamento paralelo

Os sistemas de processamento paralelo revelam-se alternativas viaveis em busca de

grande poder de processamento com baixo custo de implantacao. Alem disso, foi observado

entre esses sistemas, um destaque consideravel a partir da decada de 90 para as alternativas de

menor custo, onde houve um aumento gradativo na migracao dos sistemas especializados com

arquiteturas proprietarias e equipamentos especıficos para as solucoes mais flexıveis como os

clusters de computadores (TEIXEIRA; BARROS; COELHO, 2000).

Um dos clusters mais conhecidos e que ganhou espaco dentro da area de processamento

paralelo como referencia e exemplo de implantacao foi o Cluster Beowulf, produto de um pro-

jeto desenvolvido pela NASA com intuito de propiciar um alto nıvel de desempenho com menor

custo possıvel. A partir de entao, foi desenvolvido sobre a tipologia do-it-yourself um cluster

com 16 nos interligados em uma interface de rede comum (Ethernet) (TEIXEIRA; BARROS;

COELHO, 2000). Desde sua criacao varias instituicoes construiram seus clusters, sendo que

muitos deles apresentam quantidade de nos que superam a ordem de milhar (TEIXEIRA; BAR-

ROS; COELHO, 2000). Este crescimento se deve as diversas caracterısticas e entre elas cabe

ressaltar a facilidade de integracao dos clusters as redes existentes, alem do seu alto nıvel de

escalabilidade. Tal crescimento do mercado de clusters acarretou investimentos em sistemas de

arquivos que objetivaram dar suporte as operacoes envolvendo arquivos nos clusters de com-

putadores.

3.2 Sistemas de arquivos com suporte a clusters

Tal investimento nessa area mobilizou a criacao de varios mecanismos com objetivo de

melhorar o suporte as tarefas realizadas em clusters de computadores como os sistemas de ar-

quivos distribıdos. Para Barbosa, Greve e Barreto (2007) os sistemas de arquivos distribuıdos se

mostram mais eficientes que os sistemas de aquivos convencionais no que tange a recuperacao

e armazenamento de dados, fato que os tornam solucoes mais indicadas para utilizacao em

sistemas que exigem maior desempenho, como os clusters.

O CTDB nao foge da regra dos cluster e tem como requisito basico que seja realizada

21

sua instalacao em um sistema de arquivos distribuıdo. De acordo com a literatura do CTDB,

os sistemas de arquivos mais indicados e testados pelo projeto CTDB sao: o General Parallel

File System, GPFS, da IBM; o Global File System, GFS, da Red Hat; o Lustre da Sun; o Oracle

Cluster File System, OCFA, da Oracle; e o GlusterFS, GNU Cluster File System dentre outros

(ADAM, 2009a). O ultimo, GlusterFS, foi o sistema de arquivos utilizado para a implantacao

do ambiente multiprocessado desse trabalho. E de suma importancia observar a questao do

sistema de arquivos, uma vez que e um dos requisitos basicos para a implementacao do cluster

CTDB.

O GlusterFS possui como caracterıstica basica a utilizacao de uma API em modo

usuario. Por meio do modulo FileSystem Userspace, FUSE, aloca um dispositivo virtual,

VFSVirtual Filesystem, sendo por sua vez responsavel pela comunicacao entre o sistema op-

eracional e as bibliotecas do sistema de arquivos. Este sistema de arquivos distribuıdo tem

algumas premissas que sao: escalabilidade, desempenho e disponibilidade, garantidas atraves

de um cache configurado entre seus nos, conhecidos como bricks que negociam arquivos entre

si criando redundancia entre os dados gravados nos nos do cluster Linux (BARBOSA; GREVE;

BARRETO, 2007).

3.3 Clusters proprietarios

A maioria dos sistemas de arquivos citados sao proprietarios, fato esse que mostra como

os clusters tomaram espaco nao so em meios academicos quanto no mercado, como o CSM,

Cluster System Management da IBM, o qual se enquadra na categoria prepackeger com hard-

ware especıfico, alem do sistema operacional AIX baseado no UNIX (IBM, 2010).

Outra solucao, seguindo a linha da computacao de alto desempenho proprietarios e o

WCCS, Microsoft Windows Cluster Computer 2003, que utiliza servidores com sistema opera-

cional Microsoft Compute Cluster Edition combinado com o Microsoft Compute Cluster Pack.

No WCCS a responsabilidade do gerenciamento e exclusiva do no principal, realizando tarefas

de distribuicao de carga e controle de acesso aos recursos do cluster entre os nos, por meio

da infraestrutura existente no Active Directory, garantindo assim parametros de seguranca con-

trolados pela ferramenta de gerenciamento da empresa, o Microsoft System Management 2003

(AKHIL et al., 2008).

Segundo Akhil et al. (2008) o cluster na plaforma Windows e eficiente, no entanto

ressalta uma limitacao do seu software de gerenciamento, uma vez que um dos seus requisi-

22

tos e que ele seja instalado sobre o Windows Server com 64 bits. Tal limitacao nao exclui o

cluster da Microsoft da tipologia de clusters genericos, entretanto nao o deixa tao escalavel

quanto os clusters rodando sobre o ambiente Linux, pois nesse e permitido a implementacao

tanto em 32 quanto 64 bits (AKHIL et al., 2008).

3.4 Cluster no Linux

Akhil et al. (2008) afirma que o Linux se configura como um sistema estavel e de alta

otimizacao, e por essas caracterısticas vem se destacando em ambientes que necessitam de

alto desempenho e disponibilidade como os clusterizados, alem de permitir um alto nıvel de

escalabilidade. Essa caracterıstica explica o fato sobre os cluster do-it-yourself serem mais

comuns em ambientes de sistema aberto. Justamente por essa possibilidade de utilizacao em

maquinas comuns, ou seja, maquinas de proposito geral.

Uma das implementacoes de cluster em Linux que nao foge da regra de escalabilidade e

o CTDB, um novo recurso do Samba, com a funcionalidade de permitir distribuicao de arquivos

com maior facilidade entre os nos da rede. Tais arquivos distribuıdos entre varios nos sao

apresentados como se estivessem em um unico servidor de alta disponibilidade, conforme pode

ser observado na Figura 1 (ADAM, 2009a). Esse suporte a cluster foi totalmente integrado ao

Samba na versao 3.3, disponibilizado a partir de 2009. Anteriormente, foram realizadas apenas

adicoes parciais que permitissem tal caracterıstica.

Figura 1 – Estrutura interna do CTDBFonte:(ADAM, 2009a)

23

Como pode ser visto na Figura 1, a estrutura interna do CTDB e composta por duas

interfaces de rede, uma publica e a outra privada. Sendo que na publica, estao as estacoes

clientes do cluster, enquanto que na privada estao os nos que se comunicam por uma interface

de rede destinada a negociacao de metadados, que sao dados sobres os dados que serao servidos

as estacoes clientes, proporcionando assim interrupcoes de gravacao entre os nos, caso aque-

les dados estejam sendo utilizados em determinado momento por outro no do cluster. Outro

ponto mostrado na Figura 1 e a ligacao com um sistema de armazenamento de dados, que pode

ser tanto um storage ligado com fibra optica, quanto os proprios discos dos nos do CTDB,

devidamente configurados com um sistema de arquivos com suporte a cluster.

O CTDB foi escolhido como o ambiente de testes dessa pesquisa, uma vez que alem

de conter todas as caracterısticas de escalabilidade adequadas aos computadores de proposito

geral do laboratorio da PUC Minas, oferece tambem o servico de DHCP e VSFTP similar ao

FTP, servico oferecido pelo ambiente monoprocessado do Windows e requisito para restauracao

de imagens pela ferramenta G4U, utilizada para realizacao da carga de testes dos ambientes

propostos (ADAM, 2009a).

24

4 METODO

O presente trabalho pretende realizar um estudo comparativo entre dois ambientes de

rede, monoprocesado e clusterizado, com o intuito de verificar o desempenho dessas platafor-

mas na restauracao de imagens (clones de instalacao de sistemas operacionais) em estacoes

clientes dessas redes, e por fim gerar dados analıticos. Podendo assim, por meio deles verificar

seus respectivos comportamentos conforme mostra a Figura 2, na qual e ilustrado as etapas do

metodo:

Figura 2 – Etapas do metodoFonte: Elaboracao propria

4.1 Etapa 1 - Definir ferramentas de testes

Foi escolhida a ferramenta Ghost For Unix, G4U, para realizacao dos testes dos dois

ambientes. Essa ferramenta e capaz de realizar a copia bit-a-bit de um disco rıgido de origem,

compactatando e gerando assim uma copia fiel de todos os dados ou instalacao desse local de

25

origem para um destino. No caso proposto, um arquivo clone gerado no servidor que recebe o

nome de imagem. O G4U oferece varios nıveis de compactacao, influenciando diretamente na

velocidade de criacao e restauracao da imagem (FEYRER, 2009).

Para realizacao dos testes com imparcialidade entre os dois sistemas, o G4U utilizara

os mesmos parametros de configuracao no processo de restauracao, alem do mesmo arquivo

de imagem. O servico de clonagem via rede foi escolhido como teste em busca de possıvel

melhoria no processo de preparacao de estacoes do laboratorio da PUC Minas para o uso em

aulas, principalmente nas rotinas de formatacao que sao realizadas entre um semestre e outro,

devido a instalacao de novos softwares, ou mesmo atualizacoes que se fazem necessarias.

4.2 Etapa 2 - Instalacao dos ambientes

4.2.1 Ambiente monoprocessado

Para realizacao dos testes em ambiente monoprocessado foi instalado o Windows Server

2003 Standart Edition e disponibilizados os servicos FTP e DHCP conforme pode ser obser-

vado na Figura 3, onde procura-se mostrar o fluxo da instalacao desses servicos. Por sua vez

atendendo os requisitos para realizacao do processo de restauracao pelo G4U conforme men-

cionado anteriormente. Na Figura 3 pode ser visto que a instalacao do ambiente foi divida em

duas fases, a de instalacao do Windows Server e a de configuracoes dos servicos de FTP e

DHCP.

Figura 3 – Fluxo de instalacao do ambiente monoprocessadoFonte: Elaboracao propria

26

A Figura 4 mostra os servicos e componentes fısicos utilizados nesse ambiente, que sao

um servidor xSeries 206 da IBM com a seguinte configuracao de hardware:

a) 1 processador Pentium 4 de 3 GHz;

b) 1 GB de memoria RAM com frequencia de 1033 MHz de velocidade;

c) 1 disco rıgido SCSI de 60 GB com 7200 RPM;

Ainda pode ser visto na Figura 4 as 10 estacoes clientes do ambiente monoprocessado,

na quais se configuracao com as seguintes especificacoes de hardware para todas as estacoes:

a) 1 processador Pentium 4 de 2.8 GHz;

b) 512 Mega Bytes, MB de memoria RAM com frequencia de 400 MHz de velocidade;

c) 1 disco rıgido IDE de 40 GB com 7200 RPM;

Figura 4 – Ambiente monoprocessadoFonte: Elaboracao propria

4.2.2 Ambiente clusterizado

O segundo ambiente, clusterizado, tem as mesmas estacoes clientes do ambiente mono-

processado, contudo o diferencial fısico desse ambiente fica a cargo da substituicao do servidor

27

dedicado pelo cluster composto por 4 maquinas com a mesma configuracao de hardware das

estacoes do laboratorio. Para que seja possıvel essa substituicao do servidor monoprocessado

pelo cluster, foi realizada a instalacao do GNU/Linux Ubuntu Server 10.04 e disponibiliza-

dos os servicos, Samba, CTDB e GlusterFS, atendendo assim os requisitos para restauracao de

imagens necessarios ao G4U. A Figura 5 mostra o esquema fısico da instalacao desse ambiente.

Figura 5 – Ambiente clusterizadoFonte: Elaboracao propria

O esquema de instalacao dos componentes logicos dessa fase podem ser observados na

Figura 6, bem como os passos da implementacao do cluster, alem dos pontos chaves relaciona-

dos as configuracoes de suas etapas.

Todos os nos do cluster foram instalados seguindo os mesmos parametros de

configuracao, tendo como base a versao GNU/Linux Ubuntu Lynx 10.04 de 32 bits. Ele foi

escolhido levando em consideracao o fato de ser baseado no Debian e ser recomendado pela

comunidade do Samba para instalacao do CTDB de maneira totalmente opensource. O Ubuntu

possui uma comunidade ativa, pacotes atualizados e uma notoria taxa de crescimento e aceitacao

desde seu lancamento, tornando-se assim uma das distribuicoes mais importantes do Linux. Uti-

lizando essa distribuicao, foi realizada a instalacao dos pacotes necessarios a implementacao do

CTDB, ressaltando o sistema de arquivos distribuıdos GlusterFS.

O GlusterFS, foi escolhido porque alem de contar com as caracterısticas necessarias para

suporte a cluster, trata-se de um sistema opensource, o que permite que o ambiente clusterizado

continue totalmente baseado em solucoes de codigo aberto. A montagem de um diretorio de-

28

Figura 6 – Fluxo de instalacao do ambiente clusterizadoFonte: Elaboracao propria

vera ser feita em um dos nos do cluster como base para os arquivos do Samba entre todos

os outros nos, possibilitando que seja adicionado um arquivo nesse diretorio que controlara as

interrupcoes de leitura e escrita nos diretorios compartilhados entre os nos, requisito crucial

para o funcionamento do CTDB. A instalacao do GlusterFS pode ser vista com mais detalhes

em GlusterFS (2010).

Depois do Ubuntu Server devidamente instalado e atualizado, realizou-se a instalacao

do CTDB. Logo apos a instalacao do CTDB, foi feita a instalacao do Samba e esse por sua vez

foi compilado com suporte a clusters. Ressalta-se que no momento da compilacao do Samba

foi mencionado o diretorio onde localizam-se os arquivos de cabecalho do CTDB, justificando

assim a instalacao do CTDB antes da compilacao do Samba. Para maiores detalhes da instalacao

e configuracao consultar Adam (2009a). Apos instalacao e compilacao dos devidos pacotes, foi

executada a adequacao dos arquivos de configuracao do CTDB conforme o apendice B.

29

4.2.3 Instalacao do sistema de arquivos distribuıdo

Nesta etapa de conclusao da instalacao do ambiente clusterizado foram identificadas

limitacoes em relacao ao tipo de sistema de arquivos distribuıdo, o GlusterFS, e a comunicacao

com o Samba. Tal fato tendeu a procura pela melhoria no processo de clonagem para uma

solucao relacionada ao processo de acesso ao disco rıgido do servidor. Diante do exposto, foi

instalado o servico de vsFTPd, requisito do G4U apontando para um mapeamento em discos

distribuıdos entres os nos do cluster.

A instalacao do vsFTPd foi realizada em um dos nos do sistema distribuıdo mapeando

os volumes, que sao diretorios configurados com o GlusterFS, dos outros nos da rede fazendo

com que as operacoes realizadas no diretorio FTP desse no, sejam copiadas de forma distribuıda

entre outros nos do cluster, ao mesmo tempo realizando uma replicacao dos arquivos entre as

quatro maquinas com GlusterFS instalado como pode ser observado no apendice A.

4.3 Etapa 3 - Coleta de dados

4.3.1 Descricao dos experimentos

A etapa de realizacao dos testes foi dividida de forma a mostrar o comportamento dos

dois ambientes em duas situacoes distintas. Na primeira, foi feita a restauracao da imagem pelo

G4U em apenas uma estacao, isso para os dois ambientes, o que pode levar a verificacao de

qual deles seria mais rapido com carga mınima de trabalho. Ja a segunda etapa contou com a

restauracao de dez maquinas simultaneamente, cujo o objetivo e poder mapear o comportamento

dos ambientes em uma carga maior.

Para todos os testes realizados foi observado o parametro de tempo gasto para a con-

clusao da tarefa . Esse valor foi obtido por meio do proprio contador do G4U que e disparado

no inıcio do processo de restauracao. Alem do parametro tempo, a ferramenta conta com indi-

cadores de velocidade de transferencia em MB/s (Mega Bytes por segundo) e tambem a media

da velocidade em MB/s da taxa de transferencia ao final do processo.

Na primeira fase dos experimentos os dois ambientes foram submetidos ao processo de

restauracao com a carga de dez estacoes clientes simultaneamente, nos quais foram observados

os aspectos que estao descritos nas Tabelas 1 e 2 para os dois ambientes.

30

4.3.2 Coleta de dados do ambiente monoprocessado

A Tabela 1 apresenta os dados coletados nos testes realizados no ambiente monopro-

cessado, que mostra a descricao da estacao cliente que esta sendo restaurada, media de trans-

ferencia por computador e o tempo gasto para concretizacao da tarefa. A ultima linha da tabela

descreve os valores das medias gerais dos dados descritos.

Tabela 1 – Processo de restauracao de imagem no ambiente monoprocesado

Tamanho da imagem Media transferencia por maquina tempo por maquina (h:m:s)estacao 1 7,72 MB/s 1:22:18estacao 2 7,72 MB/s 1:22:17estacao 3 7,59 MB/s 1:24:25estacao 4 7,53 MB/s 1:43:27estacao 5 6,14 MB/s 1:24:41estacao 6 7,50 MB/s 1:23:53estacao 7 7,58 MB/s 1:24:05estacao 8 7,56 MB/s 1:40:53estacao 9 6,30 MB/s 1:42:30estacao 10 6,30 MB/s 1:42:30Media total: 7,18 MB/s 1:31:00

Fonte: Elaboracao propria

4.3.3 Coleta de dados do ambiente distribuıdo

A Tabela 2 apresenta a relacao dos dados coletados no ambiente distribuıdo com os

mesmos parametros da tabela do ambiente monoprocessado.

4.3.4 Experimento de restauracao para uma estacao cliente

Este teste teve por objetivo mostrar o comportamento dos dois ambientes sem restricoes

relacionadas ao trafego de redes, pois alem do ambiente controlado como nos testes anteriores,

foi restaurada uma unica maquina por vez. Os dados desse testes podem ser vistos na Tabela 3.

31

Tabela 2 – Processo de restauracao de imagem no ambiente clusterizado

Tamanho da imagem Media transferencia por maquina tempo por maquina (h:m:s)estacao 1 5,97 MB/s 1:46:23estacao 2 5,96 MB/s 1:46:39estacao 3 5,96 MB/s 1:46:39estacao 4 5,96 MB/s 1:46:45estacao 5 5,99 MB/s 1:46:05estacao 6 5,95 MB/s 1:46:47estacao 7 6,17 MB/s 1:43:01estacao 8 7,54 MB/s 1:24:01estacao 9 6,09 MB/s 1:44:23estacao 10 5,96 MB/s 1:46:40Media total: 6,15 MB/s 1:46:29

Fonte: Elaboracao propria

Tabela 3 – Restauracao nos dois ambientes com carga mınima

Testes com carga mınimaMedia transferencia em MB/s Tempo total gastoMonoprocessado Cluster Monoprocessado Cluster

16,36 23,58 0:38:52 0:23:57Fonte: Elaboracao propria

4.4 Etapa 4 - Analise dos resultados obtidos

Nesta sessao serao descritos os resultados dos testes realizados nos ambientes propostos

desta pesquisa. Os referidos testes foram divididos em duas fases, sendo que na primeira os

ambientes foram submetidos a uma carga de dez estacoes clientes em processo de restauracao

de imagem atraves da ferramenta G4U simultaneamente e na segunda fase a os dois ambientes

foram submentidos a apenas uma estacao por vez, evitando assim restricoes quanto limitacao

de trafego na rede.

4.4.1 Analise das taxas de transferencias

A Figura 7 apresenta o grafico no qual e mostrado um comparativo entre as taxas de

transferencia que ambos os ambientes apresentaram. Neste grafico estao descritos no eixo X

a quantidade de estacoes que foram submetidas aos testes, e no eixo Y apresenta a taxa de

transferencia e descompactacao da imagem para as maquinas clientes tanto ao ambiente mono-

processado quanto ao distribuıdo.

32

Figura 7 – Desempenho da taxa de transferencia dos ambientes mono e distribuıdo.Fonte: Elaboracao propria

Atraves da analise da Figura 7 se faz possıvel verificar que o ambiente monoprocessado

obteve uma taxa de transferencia e descompactacao maior do que o ambiente distribuıdo, sendo

que a media da transferencia do primeiro foi de 7,18 MB/s, enquanto que no segundo foi de 6,05

MB/s. Percebeu-se tambem que o ambiente distribuıdo apresentou uma taxa de transferencia

mais homogenea, sendo que o desvio padrao dos resultados foi bem menor que o ambiente

monoprocessado. A questao da transferencia homogenia no ambiente distribuıdo justifica-se

em funcao do balanceamento de carga provido pelo sistema de arquivos distribuıdo.

4.4.2 Analise do tempo de conclusao

Sobre a outra metrica estipulada para a analise desse trabalho foi coletado o tempo

gasto para conclusao da restauracao das imagens nas dez estacoes clientes. A Figura 8 mostra

um grafico comparativo dos tempos de conclusao gasto por cada estacao cliente do ambiente

monoprocessado e do ambiente distribuıdo.

Seguindo a mesma linha da analise do grafico de taxa de transferencia, a Figura 8 mostra

o grafico do tempo gasto para realizacao dos testes nos dois ambientes, percebendo-se o com-

portamento dos dois ambientes da seguinte forma: Para o primeiro, o monoprocessado, foi re-

33

alizada a tarefa com menor tempo sendo que a media calculada foi de 1:31:00 horas, enquanto

que no outro foi de 1:46:29 horas. A questao da distribuicao de carga implica diretamente nessa

outra metrica, pois tambem foi notada um desvio padrao menor do ambiente distribuıdo em

relacao ao monoprocessado.

Figura 8 – Tempo gasto para restauracao das imagens nos dois ambientes.Fonte: Elaboracao propria

4.4.3 Analise dos testes com menor carga

Quando os dois ambientes foram submetidos ao processo de restauracao com o mınimo

de carga possıvel que no caso do experimento e a restauracao de apenas uma estacao cliente por

vez, o ambiente distribuıdo obteve um melhor resultado em relacao ao ambiente monoproces-

sado, conforme pode ser observado na Tabela 3. A analise comparativa entre os dois ambientes,

nesses aspectos, mostrou que o ambiente distribuıdo foi 39% mais rapido para realizacao da

tarefa a uma taxa media de transferencia e descompactacao de 44% mais rapida.

Tal cenario se explica em funcao da alta disponibilidade e redundancia dos dados que

no sistema distribuıdo ficam espalhados entre os nos da rede. Sendo assim, no momento da

transferencia, a estacao cliente faz requisicao para apenas uma maquina no do cluster, mas de

maneira transparente ela recebe resposta dos outros nos do cluster, o que permitiu que o am-

biente distribuıdo obtivesse um melhor desempenho em relacao ao ambiente monoprocessado,

que por mais que tenha um hardware mais poderoso nao possui as funcoes que um sistema de

arquivos distribuıdo e capaz de prover.

34

5 CONSIDERACOES FINAIS

5.1 Analise comparativa dos resultados

A analise comparativa dos dados obtidos e expostos no capıtulo anterior, levaram em

consideracao as duas situacoes de carga do sistema, onde na primeira os dois ambientes pro-

postos foram submetidos a dez processos de restauracao simultaneos e o segundo a apenas uma

restauracao de maquina cliente. O Tabela 4 mostra algumas situacoes que foram avaliadas nos

dois contextos de testes, sendo que na primeira coluna e descrita a caracterıstica avaliada e nas

duas outras colunas os ambientes preenchidos de seus respectivos resultados, podendo assim

por meio desta analise apresentar de maneira simplificada qual dos ambientes se comportou de

maneira mais satisfatoria.

Tabela 4 – Quadro comparativo

Descricao monoprocessado clusterizadoBalanceamento de carga nao simRedundancia nao simDesempenho (Ethernet 10/100) Mellhor comportamento InsuficienteEstabilidade da taxa de transferencia Instavel EstavelCapacidade de transferencia Melhor comportamento InsuficienteFacilidade de implantacao Facil Difıcil

Fonte: Elaboracao propria

5.2 Limitacoes do metodo

A primeira limitacao do metodo identificada foi a questao da ausencia de um dispositivo

de storage, o qual facilitaria no processo de montagem e reconhecimento por parte do CTDB

ao sistema de arquivos distribuıdo, que em geral foram desenvolvidos para esses dispositivos de

hardware. Tal limitacao nao permitiu que fosse provido o FTP pelo CTDB, fazendo com que os

testes no ambiente clusterizado ficassem sem a parte de processamento dos dados providos pelo

CTDB, contando somente com os servicos de distribuicao de arquivos providos pelo GlusterFS.

A segunda limitacao identificada foi a questao dos equipamentos disponıveis para testes

serem todos padrao Ethernet 10/100. Essa limitacao impactou diretamente em relacao ao com-

portamento esperado para os testes com o ambiente clusterizado, tendo em vista que nesse

cenario de testes temos o arquivo de imagem a ser restaurado dividido entre os nos da rede,

35

aumentando o fluxo de dados trafegados na rede. Sendo assim, o ideal para um ambiente clus-

terizado e a utilizacao de uma rede de alta velocidade.

A ultima limitacao identificada, porem nao menos relevante, foi a questao da dificul-

dade encontrada para realizacao dos testes em ambiente real, no caso em questao, a quantidade

de computadores disponıveis para os testes. Esta limitacao esta relacionada a questao do lab-

oratorio utilizado ser tambem o laboratorio em producao do campus, e os testes de clonagem

desconfiguram por completo as instalacoes dos softwares instalados nos computadores, fazendo

com que cada teste alem de demorado, tomasse muito tempo para que os computadores fossem

retornados as configuracoes necessarias a utilizacao pelas necessidades rotineiras dos alunos.

Esta questao da quantidade de testes limitou o metodo quanto a coleta de dados, uma vez que

nao foi possıvel gerar mais situacoes de carga para que pudesse ser gerada uma curva de de-

sempenho dos ambientes com varios cenarios diferentes.

5.3 Trabalhos Futuros

Com base nas limitacoes do metodo apresentadas, ficam abertas propostas de trabalhos

futuros que possam assim atender alguns dos itens citados que sao:

a) Montagem do Cluster CTDB sobre o Fedora14, utilizando como dispositivo de armazena-

mento um storage com sistema de arquivos distribuıdos GlusterFS. Esta proposta de trabalho

poderia mostrar que, a instalacao do CTDB nao e complexa em relacao ao ambiente mono-

processado, segundo constatado no presente ensaio, pois alem da documentacao recomendar

fortemente que seja utilizado o RedHat ou derivados como o Fedora para a sua instalacao,

o uso de um dispositivo storage facilitaria na integracao do CTDB ao sistema de arquivos

distribuıdos.

b) Estudo comparativo de ambiente clusterizado e monoprocessado em infraestrutura de rede

com padrao Gigabit. Tal proposta poderia atender a segunda limitacao do metodo proposto,

uma vez que se torna passıvel a verificacao do comportamento dos dois ambiente sem o fator

de limitacao de banda como o identificado nesta pesquisa.

c) Avaliacao de capacidade por meio de curva de desempenho das plataformas clusterizada e

monoprocessada de rede. Esta ultima proposta de trabalho futuro, tem o tıtulo similar ao

dessa pesquisa, entretanto, o foco seria justamente utilizar o ambiente ja montado para que

possa ser direcionado na realizacao de testes com diversas cargas, desde uma estacao ao

36

limite de N maquinas utilizando o processo de clonagem simultaneamente. Tais cargas de

testes possibilitariam que fosse gerado uma curva de desempenho de utilizacao dos ambi-

entes, e por meio delas definir o limite de servico e principalmente o limite de saturacao dos

ambientes clusterizados e monoprocessado.

5.4 Consideracoes finais

De acordo com as informacoes mostradas na Tabela 4, extraıdos dos graficos analıticos

do capıtulo 4, o ambiente monoprocessado se comportou de maneira mais satisfatoria em

relacao ao ambiente clusterizado no que tange a taxa de processamento e a velocidade de con-

clusao da tarefa. E possıvel observar que caracterısticas favoraveis ao ambiente monoproces-

sado tambem em relacao a facilidade de implantacao do ambiente, levando em consideracao a

utilizacao de ferramentas e servicos ja popularizados e de facil utilizacao. Entretanto, e possıvel

notar por meio da figura 8 um desvio padrao consideravel da media geral de conclusao da tarefa

no teste com dez cargas simultaneas. Esta caracterıstica do ambiente monoprocessado mostra

que o balanceamento de carga entre os clientes e insatisfatorio em relacao ao outro cenario de

rede.

Em relacao ao teste realizado com uma carga, ou seja, uma estacao cliente em processo

de restauracao por vez, foi observado de acordo com a tabela 3 que o ambiente clusterizado

se comportou de maneira mais rapida na taxa de transferencia/descompactacao e consequen-

temente na conclusao da tarefa. Este comportamento se explica levando em consideracao que

os dois ambientes foram montados utilizando uma interface de rede comum o padrao ethernet

10/100 que possui seus limites de banda, limites esses que em situacao de maior carga de trans-

ferencia torna-se o gargalo do sistema como um todo. Porem, no processo de restauracao com

apenas uma estacao por vez, esse limite nao e saturado. Permitindo assim que o sistema de

arquivos distribuıdo possa atender e liberar um maior numero de requisicoes aos discos espa-

lhados entre os nos do cluster de maneira mais eficaz que o ambiente clusterizado.

Com base nos resultados obtidos no decorrer deste ensaio, bem como nas analises com-

parativas e propostas de trabalhos futuros, essa pesquisa se encerra de maneira a mostrar que

os ambientes propostos testados, mesmo com as limitacoes apontadas, apresentaram suas van-

tagens e desvantagens fortemente influenciadas pelo tipo de teste ao qual foram submetidos.

No que tange ao ambiente distribuıdo, o mesmo mostrou-se eficaz quando nao esta com limite

de carga, alem de mostrar um nıvel de balanceamento de carga satisfatorio. Quanto ao ambi-

ente monoprocessado observou-se que o mesmo nao possui balanceamento de carga, entretanto,

37

para o cenario proposto, com limitacoes de banda de rede se mostrou a melhor opcao quanto ao

processo de clonagem e restauracao de imagens via rede no padrao Ethernet 10/100.

38

REFERENCIAS BIBLIOGRAFICAS

ADAM, Michael. Clustered nas for everyone clustering samba with ctdb. apr 2009. Disponıvelem: <http://samba.org/\˜obnox/presentations/sambaXP-2009/>. Acesso em: 20 de marco de2010.

ADAM, Michael. Samba mais disponivel. nov 2009. Disponıvel em: <http://lnm.com.br-/article/3110>. Acesso em: 07 de junho de 2010.

AKHIL, K. et al. Windows and linux cluster. jul 2008. Disponıvel em: <http://dspace.sngce-.ac.in/sngc/handle/123456789/266>. Acesso em: 27 de maio de 2010.

ALVES, Edimar Lima. Avaliacao do processo de migracao de um servidor corporativomicrosoft windows 2000 server para linux/samba. apr 2005. Disponıvel em: <http:/-/www.fes.br/revistas/agora/ojs/include/getdoc.php?id=60>. Acesso em: 20 de marco de2010.

AUGUSTO, Alessandro. Automatizacao de administracao e seguranca em redes windows nt.sep 2001. Disponıvel em: <http://www.aurelio.pro.br/dircomputacao.php>. Acesso em: 23 deabril de 2010.

BARBOSA, Amadeu Andrade; GREVE, Faıola; BARRETO, Luciano Porto. Avaliacao desistemas de arquivos distribuıdos num ambiente de pequena escala. 2007. Disponıvel em:<http://www.gluster.org>. Acesso em: 16 de novembro de 2010.

FEYRER, Hubert. G4u - harddisk image cloning for pcs. 2009. Disponıvel em: <http://www-.feyrer.de/g4u/>. Acesso em: 15 de outubro de 2010.

GLUSTERFS. Gluster community. 2010. Disponıvel em: <http://www.gluster.org>. Acessoem: 15 de outubro de 2010.

GROPP, William. Beowulf cluster computing with linux. 2. ed. Cambridge: MIT Press, 2003.618 p. ISBN 0262692929.

IBM, International Business Machine. Sobre servidores clusters. 2010. Disponıvel em:<http://www.ibm.com/br/systems/clusters/about/index.phtml>. Acesso em: 14 de maio de2010.

NEMETH, Evi; SNYDER, Garth; HEIN, Trent R. Manual completo do Linux : guia doadministrador. 1. ed. Sao Paulo: Makron Books, 2004. 669 p. ISBN 8534614865.

SIEVER, Ellen et al. Linux: o guia essencial. 1. ed. Porto Alegre: Bookman, 2006. 852 p.ISBN 8560031006.

SILVA, Gleydson Mazioli da. Guia foca linux. versao avancada 6.40. nov 2007. Disponıvelem: <http://focalinux.cipsga.org.br/download.html>. Acesso em: 05 de maio de 2010.

TANENBAUM, Andrew Stuart. Redes de Computadores. Rio de Janeiro: Campus, 2003.945 p. ISBN 8535211853.

TEIXEIRA, Hugo Emanuel Goncalves; BARROS, Maria Joao Almeida de Sa; COELHO,Paulo Jorge Marques. Clusters beowulf. jan 2000. Disponıvel em: <http://www.cesarkallas-.net/arquivos/apostilas/redes/beowulf clusters.pdf>. Acesso em: 17 de maio de 2010.

39

AVILA, Rafael Bohrer. Uma proposta de distribuicao do servidor de arquivos em clusters. jun2005. Disponıvel em: <http://www.lume.ufrgs.br/handle/10183/5679>. Acesso em: 17 demarco de 2010.

40

APENDICE A - INSTALACAO DO GLUSTERFS

Instalacao do GlusterFS Server no Linux Ubuntu 10.04

O primeiro passo foi a atualizacao da lista de repositorios do Ubuntu atraves do comando

update, depois disso acionar o comando de instalacao padrao do Ubuntu com o nome do pacote

a ser instalado:

#apt-get update

#apt-get install glusterfs-server

Esse passo foi realizado nas tres estacoes que servidores. Logo apos foi feita a instalacao

do Glusterfs cliente na estacao onde foi feita o mapeamento atraves de ponto de montagem dos

discos dos tres servidores de Glusterfs existentes no cluster, para utilizou-se os comandos:

#apt-get update

#apt-get install glusterfs-client

Depois dos pacotes devidamente instalados conforme as instruncoes partimos para a

configuracao dos arquivos dos servidores e do cliente, que se localizam por padrao dentro do di-

retorio /etc/glusterfs. Os arquivos sao glusterfsd.vol, para o servidor e glusterfs.vol para cliente.

Para os servidores foram utilizadas as seguntes configuracoes:

volume posix

type storage/posix

option directory /shared

end-volume

volume locks

type features/locks

subvolumes posix

end-volume

volume brick

type performance/io-thereads

option thread-count 8

subvolumes locks

41

end-volume

volume server

type protocol/server

option transport-type tcp

subvolumes brick

option auth.ip.brick.allow *

option auth.addr.brick.allow *

end-volume

Esta configuracao deve ser identica em todos os servidores do GlusterFS.

O proximo passo e a configuracao do computador cliente, que ficou responsavel pelo

mapeamento dos volumes remotamente, que por sua vez trabalha de forma transparente per-

mitindo acesso balanceado e distribuıdo entre os discos do Glusterfs. O arquivo de configuracao

do cliente e o glusterfs.vol e foi configurado da seguinte maneira:

volume servidor1

type protocol/client

option transport-type tcp/client

option remote-host 10.180.10.1

option remote-subvolume brick

end-volume

volume servidor2

type protocol/client

option transport-type tcp/client

option remote-host 10.180.10.2

option remote-subvolume brick

end-volume

volume servidor3

type protocol/client

option transport-type tcp/client

option remote-host 10.180.10.3

option remote-subvolume brick

end-volume

42

volume replicate1

type cluster/replicate

subvolumes servidor1 servidor2 servidor3

end-volume

volume writebehind

type performance/writer-behind

option window-size 1MB

subvolumes replicate1

end-volume

volume cache

type performance/io-cache

option cache-size 512MB

subvolumes writebehind

end-volume

Esta configuracao do arquivo cliente utilizou os tres discos que estao instalados nos

tres servidores do Glusterfs de maneira a criar um volume no qual e mapeado atraves de um

comando de montagem disparado pela estacao cliente. Esse volume se comporta de acordo

com as especificacoes descritas nesse arquivo de configuracao com replicacapo entre os tres

discos, alem de criar um cache de armazenamento e balancemento de carga.

Depois de realizadas as devidas configuracoes dos arquivos referidos, devem ser inicia-

dos os servicos dos servidores com o comando:

/etc/init.d/glusterfs start

Depois que os servicos foram inciados foi montado dentro do diretorio criado em /mnt

com o seguinte comando

glusterfs -f /etc/glusterfs/glusterfs.vol /mnt/shared

Depois dessa configuracao realizada bastou apontar os diretorios do Samba e do FTP para o

diretorio mapeado no cliente, fazendo com que o referido mapeamento comportar-se como um

storage de disco.

43

APENDICE B - ARQUIVOS DE CONFIGURACAO DO SAMBA E DO CTDB

Esse apendice mostra os principais arquivos de configuracao do CTDB e do Samba,

alem de apresentar as configuracoes utilizadas neste trabalho.

Arquivo onde sao realizadas as principais configuracoes do CTDB, localizado em

/etc/syconfig/ctdb em distribuicoes baseadas no RedHat e em /etc/default/ctdb para os baseados

no Debian. Deve ser dado importancia a linha referente ao CTDB RECOVERY LOCK, pois

esse deve apontar para um diretorio que esteja montado com suporte a sistemas distribuıdos, no

caso desta pequisa o GlusterFS

CTDB_RECOVERY_LOCK="/mnt/shared/ctdb.lock"

CTDB_PUBLIC_ADDRESSES=/etc/ctdb/public_addresses

CTDB_MANAGES_SAMBA=yes

CTDB_NODES=/etc/ctdb/nodes

CTDB_LOGFILE=/var/log/log.ctdb

Aquivo PUBLIC ADDRESSES contem os enderecos de IP das maquinas clientes ao

cluster ou seja: Pode ser colocado em qualquer diretorio, entretanto sua utilizacao mais comum

e no diretorio /etc/ctdb/:

10.0.2.101/24 eth1

10.0.2.102/24 eth1

10.0.2.103/24 eth1

10.0.2.104/24 eth1

Arquivo NODES, este contem os enderecos dos Nos do cluster e por sua vez e re-

comendavel que sejam preferencialmente diferentes dos enderecos publicos em uma faixa de

IP diferente:

10.180.10.1

10.180.10.2

10.180.10.3

10.180.10.4

Alteracoes no arquivo de configuracao do Sanba o SMB.CONF que pode ser localizado

dentro do diretorio /etc/samba/. Neste arquivo deve ser observador o parametro CLUSTER-

44

ING=YES, pois sem este o Samba se comportaria como se nao fosse compilado com suporte a

cluster:

workgroup=clusterSMB

netbios name=SMB

passdb backend=tdbsam

clustering=yes

idmap backend=tdb2

Ainda no arquivo SMB.CONF deve ser compartilhado um diretorio, onde serao coloca-

dos o arquivo de lock do CTDB:

share[shared]

path=/mnt/shared/

writeable = yes

45

APENDICE C - INSTALACAO DO VSFTPD

Instalar o vsFTPd (Very Secure File Tranfer Protocol Daemon) Consiste em um dae-

mon que executa em sistemas Unix, como o Linux permintindo transferencia de arquivos via

protocolo FTP.

Para proceder a instalacao no Ubuntu Server siga os sequintes instrucoes:

#apt-get update

#apt-get install vsftpd

Depois de instalado basta realizar configuracoes personalizadas no arquivo

/etc/vsftpd.conf

Dentro do arquivo vsftpd.conf devem ser editadas as seguintes linhas conforme as

descricoes:

Permitir que sejam realizados acessos autenticados, caso essa opcao seja setada para

YES, que e padrao em algumas distribuicoes, o FTP so permitira acesso anonimo, o que nao e

o caso desse ambiente proposto, que necessita de acesso autenticado.

#anonymous_enable=NO

Permitir que usuarios do sistema local tenha permissao de acesso

#local_enable=YES

Permitir que os usuarios escrevam no diretorio do servidor

#anon_upload _enable=YES

Caso voce deseje que os usuarios possam criar diretorios dentro do servidor habilete esta

opcao:

ano_mkdir_write_enable=YES

Para forcar que seja aberto o diretorio /home do usuario que efetuou logon no FTP

garantido assim seguranca, pois caso nao seja configurado essa opcao o usuario e capaz de

verificar toda a raiz do Sistema.

46

#chroot_local_user=Yes

Para setar uma pasta padrao para todos os usuario

anon_root=/mnt/shared

Mais detalhes dos parametros de configuracao do VSFTPD podem ser obtidos pelo man-

ual no proprio terminal atraves do comando:

#man 5 vsftpd.conf

Para sair do manual pressione a tecla “q”

Depois de configurado de acordo com os requisitos inicie o servico com o comando:

#/etc/init.d/vsftpd start