Post on 05-Feb-2023
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