ANÁLISE DE DESEMPENHO ENTRE OS

SISTEMAS DE ARQUIVOS HDFS E LUSTREFS1

Marcos Fagundes Vieira <mvrs2008@terra.com.br>

Orientador: Júlio César S. dos Anjos <julio.c.s.anjos@gmail.com>

Universidade Luterana do Brasil (ULBRA) - Superior de Tecnologia em Redes de Computadores

Canoas – RS – Brasil

29 de novembro de 2010

RESUMO

Este artigo apresenta os sistemas de arquivos Hadoop Distribuited File System (HDFS) e Lustre File System

(LustreFS) e avalia o desempenho entre dois sistemas que utilizam o HDFS o LustreFS para execução de tarefas

como leitura e gravação de dados. O ambiente de computação utiliza um agrupamento de computadores

heterogêneos. São utilizadas ferramentas de monitoração, como Cacti e RRDtool para coletar informações em tempo

real da atividade de computação neste ambiente. O relato do experimento e a análise dos dados são apresentados com

objetivo de avaliar quantitativa e qualitativamente os dois sistemas.

Palavras-chave: Sistemas de arquivos, HDFS, LustreFS, sistemas distribuídos, sistemas paralelos.

ABSTRACT

Title: “Performance Analysis of File Systems HDFS and LustreFS”

This article presents the file systems Distribuited Hadoop File System (HDFS) and Lustre File System

(LustreFS) and evaluates the performance between two systems using the HDFS LustreFS for tasks such as reading

and writing data. The computing environment using a cluster of heterogeneous computers. Monitoring tools are used,

such as Cacti and RRDtool to collect information in real-time computing activity in this environment. The report of

the experiment and data analysis are presented to evaluate qualitatively and quantitatively the two systems.

Key-words: Filesystems, HDFS, LustreFS, distributed systems, parallel systems.

1 INTRODUÇÃO

Os avanços tecnológicos juntamente com o crescente poder de processamento dos

microprocessadores proporcionaram a criação de arquiteturas que primam pela computação de alto

desempenho ou High-Performance Computing (HPC). Em Pitanga (2008), o resultado dos avanços

tecnológicos somados à facilidade de interligar múltiplos computadores através de um barramento externo

de alta velocidade favoreceu o surgimento dos sistemas distribuídos, que contêm várias máquinas

interligadas em rede com intuito de oferecer a imagem de um sistema único e transparente.

Os sistemas de arquivos Hadoop Distribuited File System (HDFS) e Lustre File System (LustreFS)

são baseados em arquiteturas HPC. O primeiro usa sistemas distribuídos e o segundo, sistemas paralelos e

distribuídos. Segundo White (2009), o HDFS, basicamente utiliza um algoritmo de distribuição para

segmentar os dados em N partições de tamanhos iguais chamadas chunks e distribui para a execução de

funções map e reduce, inspirada em linguagens funcionais sobre os nós da rede que contém estes dados

distribuídos. Conforme Kling-Petersen (2009), o sistema de arquivos Lustre é uma arquitetura apenas de

software que pode ser aplicada em diferentes tipos de hardware. Neste modelo, há uma separação bem

definida entre os arquivos de dados (ou objetos) e metadados. O servidor de metadados proporciona o acesso

direto e paralelo aos objetos gravados nos dispositivos de armazenamento ou storage devices.

1.1 Motivação

Os sistemas operacionais atuais necessitam de estruturas lógicas avançadas que viabilizem o acesso à

informação com maior eficiência e segurança. O que motiva o presente estudo está relacionado à

compreensão e a identificação dos mecanismos utilizados em sistemas de arquivos distribuídos que podem

contribuir para o aumento do desempenho e da disponibilidade de acesso aos dados.

1 Artigo Final da disciplina de Trabalho de Conclusão do Curso em Superior de Tecnologia em Redes de Computadores da Universidade Luterana

do Brasil, Campus Canoas;

1.2 Objetivos

O principal objetivo deste projeto foi analisar o desempenho de dois sistemas de arquivos

distribuídos – HDFS e LustreFS, implementados em um ambiente controlado. Estes sistemas são comumente

utilizados em ambientes de clusters homogêneos. Neste projeto foi possível medir a potencialidade do uso

dessas duas arquiteturas em ambientes computacionais de alto desempenho, porém em cluster heterogêneo,

onde cada máquina tem poder computacional diferente. Os objetivos específicos são: a análise comparativa

entre as arquiteturas envolvidas, avaliação do desempenho de cada sistema de arquivo e teste de performance

entre os sistemas paralelos.

Além deste capítulo, este artigo contém as seguintes seções. Na seção 2, é descrita a fundamentação

teórica sobre o tema proposto. Na seção 3, é detalhada a metodologia aplicada para a solução do problema,

com a descrição do ambiente, das ferramentas de monitoração e softwares utilizados. Na seção 4, é

mostrado o relatório final com apresentação dos resultados. Na seção 5, são apresentadas as conclusões do

autor e propostas para trabalhos futuros. Na seção 6, são mencionadas as referências bibliográficas utilizadas

no decorrer do trabalho para embasamento e fundamentação do tema proposto.

2 SISTEMAS DE ARQUIVOS LUSTREFS E HDFS

Ao se estudar as funcionalidades dos sistemas de arquivos HDFS e LustreFS, alguns conceitos

básicos e algumas características fundamentais devem ser levados em consideração para um melhor

entendimento sobre o funcionamento de cada um deles.

2.1 Conceitos básicos em Sistemas Operacionais

O sistema operacional (SO) "é uma camada de software colocada entre o hardware e os programas

que executam tarefas para o usuário. [...]. Desta forma, o programador não precisa conhecer detalhes do

hardware" (OLIVEIRA, 2010, p.22).

Conforme Machado e Maia (2007), o SO controla a execução de diversos programas concomitantes

e concorrentes entre si pelo processador e demais recursos. Ele gerencia os arquivos dentro do computador e

o sistema de arquivos, que por sua vez, controla o acesso dos usuários ao conteúdo destes arquivos.

Quando um usuário executa um programa em seu computador é disparado um processo controlado

pelo SO de sua máquina. Segundo Machado e Maia, este "[...] processo deve ser capaz de ler e gravar de

forma permanente um grande volume de dados em dispositivos como fitas e discos, além poder compartilhá-

los com outros processos" (2007, p.215).

Em sistemas distribuídos, quando mais de um usuário tenta gravar um mesmo arquivo

simultaneamente, é necessário um controle da concorrência (acesso simultâneo ao mesmo recurso) para que

haja uma operação atômica dos processos para garantir que a informação permaneça consistente. Conforme

Tanenbaum e Steen, em um grupo de processos, a atomicidade só pode ser garantida da seguinte maneira:

"ou todos os processos executam determinada operação ou a operação não é executada de jeito nenhum"

(2007, p.73). Aguiar complementa ainda que: "uma operação em um arquivo é dita atômica quando as

etapas da mesma não podem ser percebidas por outros processos exteriores a esta operação" (2008, p.6).

Atualmente, a maioria dos sistemas de arquivos distribuídos (SAD) já utiliza a atomicidade nas operações de

leitura, escrita, criação ou remoção de um arquivo.

Em Tanenbaum, "a informação armazenada em arquivos deve ser persistente, isto é, não pode ser

afetada pela criação e pelo término de um processo. Um arquivo somente desaparecerá, quando seu

proprietário removê-lo explicitamente" (2003, p.285). [grifo do autor]

2.2 Características do sistema de arquivos

O sistema de arquivos é um componente do SO que permite ao usuário interagir com os arquivos e

diretórios, seja para salvar, modificar ou excluir arquivos e pastas, seja para instalar, executar ou configurar

programas. Coulouris et al. caracteriza sistemas de arquivos como "responsáveis pela organização,

armazenamento, recuperação de nomes, compartilhamento e proteção de arquivos" (2007, p.287).

Existe uma interface de programação que abstrai o arquivo, favorecendo os programadores a não se

preocuparem com detalhes de alocação do arquivo, leiaute de armazenamento, mapeamento de bits, etc. O

armazenamento físico de um arquivo em disco ou em qualquer outra mídia deve ocorrer de forma persistente

ou não-volátil, ou seja, o SO mantém os dados gravados no disco, mesmo após o computador ser desligado

(COULOURIS et al., 2007).

Todo arquivo é composto externamente por um nome e uma extensão, preferencialmente separadas

por um ponto. Internamente ele é composto por dados, atributos e metadados. O SO organiza em uma

estrutura hierárquica chamada de diretório. Segundo Oliveira et al., "arquivos são recipientes que contêm

dados. [...]. Cada arquivo contém um conjunto de dados que possui algum significado prático para o

usuário ou para o sistema" (2010, p.208) [grifo do autor]. Diretório é uma estrutura que possibilita aos

usuários organizar seus arquivos no sistema, além de facilitar o manuseio, compartilhamento e localização de

arquivos.

Conforme Coulouris et al., "os dados consistem em uma seqüência de elementos (normalmente, bytes

de oito bits), acessíveis pelas operações de leitura e escrita de qualquer parte desta seqüência" (2007,

p.287). Ele complementa ainda que, além dos dados, os arquivos contêm atributos, que são estruturados num

único registro com informações relevantes para o sistema de arquivos, como: nome, tamanho, tipo, proteção,

identificação do criador, data de criação, etc. Os metadados, por sua vez, contêm todas as informações

adicionais existentes num sistema de arquivos, utilizadas para o seu gerenciamento. Exemplos de metadados:

nome do dado, atributo de arquivos, diretórios, extensão de arquivos, etc.

2.3 Computação de alto desempenho ou High-Performance Computing (HPC)

O conceito de computação de alto desempenho está ligado ao surgimento e consolidação do

agrupamento de computadores ou clusters. Pitanga (2008) conceitua cluster como sendo a união de dois ou

mais computadores que trabalham em conjunto para resolver um determinado problema.

Existem duas categorias de agrupamentos de computadores: alta disponibilidade ou High Availability

(HA) e computação de alto desempenho ou High-Performace Computing (HPC). Segundo Pitanga, o cluster

HA garante o funcionamento seguro e ininterrupto de um serviço sempre que for possível, mesmo que

existam falhas de qualquer natureza. Já o cluster HPC, "é um tipo de sistema para processamento paralelo

ou distribuído que consiste de uma coleção de computadores interconectados, trabalhando juntos como um

recurso de computação simples e integrado" (PITANGA, 2008, p.31).

Clusters são sistemas com múltiplos processadores classificados em fortemente ou fracamente

acoplados (MACHADO e MAIA, 2007, p.257). No primeiro caso, sistemas fortemente acoplados (tightly

coupled) compartilham uma memória física entre vários processadores. No segundo, sistemas fracamente

acoplados (loosely coupled), no qual estão incluídos os clusters, há a conexão de dois ou mais sistemas

computacionais independentes entre si, cada um funcionando com seus próprios recursos de processamento,

memória e SO (MACHADO e MAIA, 2007).

Segundo Veras, algumas vezes "para o cluster HPC funcionar é necessário utilizar um software de

gerenciamento que permite que os diversos nós de processamento existentes sejam tratados como um único

nó" (2009, p.93). Conforme Schepke et al. (2005), existe uma série de ferramentas disponíveis para

gerenciamento de clusters, com destaque para: Kickstart e FAI (Fully Automatic Installation) usadas para a

instalação automática de cluster; SCMS (Scalable Cluster Management System) e SHOC (Shell Over a

Cluster) usadas para atualização e configuração automática de clusters.

As vantagens no uso de clusters HPC concentram-se sob cinco aspectos: alto desempenho,

escalabilidade, tolerância a falhas, baixo custo e softwares de código aberto O cluster HPC, além de

proporcionar alto desempenho, também pode apresentar HA em sua arquitetura (PITANGA, 2008).

Atualmente existem várias propostas de DFS (Distribuited File Systems) que visam tirar proveito do uso de

sistemas de arquivos em clusters, principalmente quando se tratam de armazenamento escalável com

desempenho. É neste quadro que se enquadram as duas arquiteturas estudadas neste trabalho.

2.4 Ambiente cliente/servidor

Machado e Maia (2007) relatam que os sistemas operacionais podem ser heterogêneos, bastando que

os nós entre eles se comuniquem através do mesmo protocolo de rede. Na Internet, por exemplo, nada

impede que cada host utilize um SO diferente, contanto que a comunicação entre todos os hosts seja através

do protocolo TCP/IP (Transmission Control Protocol/Internet Protocol).

Segundo Veras, o modelo cliente/servidor possui as seguintes características: "um servidor é um

aplicativo que [...] recebe uma solicitação, realiza o serviço e envia de volta o resultado em uma resposta.

Um cliente é um solicitador de serviço" (2009, p.78). Uma aplicação envolve um servidor e um cliente num

mesmo sistema ou em sistemas diferentes.

Em Tanenbaum, uma das vantagens deste modelo diz respeito a sua adaptabilidade com sistemas

distribuídos, ou seja, "se um cliente se comunica com um servidor enviando-lhe mensagens, o cliente não

precisa saber se a mensagem é tratada localmente em sua própria máquina ou se ela foi enviada pela rede a

um servidor" (2003, p.46). Na verdade, o cliente apenas faz uma requisição e aguarda uma resposta do

servidor.

2.5 Sistema de Arquivos Paralelos e Distribuídos

Como já visto na seção 2.2 deste capítulo é pertinente relatar algumas características particulares das

arquiteturas SAP e SAD que são, respectivamente, utilizadas nos sistemas de arquivos LustreFS e HDFS

deste trabalho.

Pitanga define paralelismo como sendo "uma técnica utilizada em grandes e complexas tarefas para

obter resultados na forma mais rápida possível" (2008, p.10). A tarefa principal é subdividida em partes

menores e distribuída por vários processadores dentro do sistema paralelo, ao qual serão executadas

simultaneamente. O conceito de SAP incorporou-se às arquiteturas computacionais modernas com objetivo

de proporcionar alto desempenho a um custo menor. Conforme Guardia e Sato (1999), um SAP gerencia o

acesso paralelo aos vários discos de armazenamento presente em sua arquitetura, permitindo altas taxas de

transferência, redução no atraso das requisições com o uso de buffers em disco e aumento da vazão das

transmissões entre disco e memória.

Segundo Dodonov, "os arquivos paralelos podem estar armazenados sob controle do hardware (por

exemplo, utilizando Redundant Arrays of Inexpensive Disk ou RAID) ou sob o controle de um sistema de

arquivos paralelos" (2004, p.4), como é o caso do LustreFS analisado. A técnica de RAID caracteriza-se por

criar um array de discos ou grupo de discos físicos redundantes que "são tratados pelo sistema operacional

como se fosse um único disco. Este disco tem como característica uma grande capacidade de

armazenamento, alto desempenho e confiabilidade dos dados armazenados" (MACHADO e MAIA, 2007,

p.239).

Sistema distribuído, na visão de Tanenbaum e Steen é "um conjunto de computadores independentes

que se apresenta a seus usuários como um sistema único e coerente" (2007, p.1). Exemplos clássicos de

sistemas distribuídos em redes de computadores são: Internet e Intranet. Reforçando este conceito, sistema

distribuído pode ser definido ainda como: "aquele no qual os componentes de hardware ou software,

localizados em computadores interligados em rede, se comunicam e coordenam suas ações apenas enviando

mensagens entre si" (COULOURIS, 2007, p.16).

Segundo Tanenbaum, o SAD "é aquele que parece aos olhos dos usuários um sistema operacional

tradicional de processador único, mesmo que na verdade seja composto de múltiplos processadores" (2003,

p.12). Os usuários do SAD compartilham diretórios como se fossem diretórios locais, não percebem onde os

programas estão sendo executados, nem onde os arquivos estão localizados. "É comum que sistemas

distribuídos permitam que aplicações sejam executadas em vários processadores ao mesmo tempo, o que

exige algoritmos mais complexos de escalonadores" (TANENBAUM, 2003, p.12).

Em Coulouris et al. (2007), uma das virtudes do SAD é proporcionar a imagem de um sistema único

e transparente, ou seja, o usuário tem a nítida sensação que o acesso aos arquivos ocorre na sua própria

máquina. As vantagens que merecem destaque em sistemas distribuídos são: a heterogeneidade de seus

componentes; a escalabilidade em sua arquitetura que permite anexar ou substituir componentes; o uso de

sistemas abertos com máquinas e serviços independentes de fornecedores individuais; a tolerância à falhas

com prevenção contra perda de dados ou inoperância em equipamentos; ambiente concorrente com

operações sincronizadas e dados consistentes atomicamente; transparência para seus usuários com a sensação

de um sistema único e abstrato (COULOURIS et al., 2007).

2.6 Sistema de arquivos Lustre (LustreFS)

Segundo Pitanga, "o Lustre é uma arquitetura de armazenamento para clusters desenvolvido

inicialmente pela Carnegie Mellon University como projeto de pesquisa iniciado em 1999" (2008, p.284).

No ano de 2003, a empresa Cluster File System Inc. desenvolve a versão 1.0 do Lustre File System, que

passa ser utilizada com sucesso no meio acadêmico e corporativo. Em 2007, a Sun Microsystems, que

buscava soluções em HPC, adquiriu a empresa Cluster File System Inc. e passou a ser a atual proprietária e

desenvolvedora do Lustre.

O LustreFS é um sistema de arquivos paralelo e distribuído que provê escalabilidade, alto

desempenho (HPC) e alta disponibilidade (HA) para um agrupamento de computadores. Ele pode atingir,

com isto, "dezenas de milhares de nós e petabytes de capacidade de armazenamento, sem comprometer a

estabilidade e a segurança do sistema" (SANTOS, 2006, p.158). Ele utiliza uma interface padrão POSIX

(Portable Operating System Interface [for Unix]). POSIX pode ser definido como "um padrão de definição

de interface para o sistema operacional Linux" (SAWAYA, 1999, p.360).

Segundo Hermann, o Lustre possui uma arquitetura de distribuição "que oferece a possibilidade de

ter nós operando em pares replicados (active/failover), o que aumenta a disponibilidade do sistema" (2006,

p.19). Os pares replicados se aplicam ao MDS (Metadata Servers) e OSS (Object Storage Servers). Em

relação à arquitetura do Lustre, ela é composta por três camadas básicas (como visto na Figura 1):

Clientes: acessam o sistema de arquivos;

Servidores de Metadados (MDS): gerenciam os nomes e diretórios no sistema de arquivos, além

das permissões e atributos estendidos para cada objeto. O MDS compreende ainda de um Disco

de Armazenamento de Metadados ou Metadata Target (MDT) e um Serviço de Gerenciamento

ou Management Service (MGS);

Servidores de Armazenamento de Objeto (OSSs): são responsáveis pelo armazenamento e

transferência de dados de um arquivo, ou seja, disponibilizam os serviços de entrada/saída. O

OSS pode escalar um ou vários Discos de Armazenamento de Objetos ou Object Storage Target

(OSTs) em sua arquitetura, sem necessidade de interromper a execução do Lustre.

Pitanga argumenta que, "aumentar a capacidade do sistema de arquivos e largura de banda do

cluster pode ser feito facilmente, adicionando servidores de objetos e as unidades de armazenamento sem a

necessidade de interromper o cluster" (2008, p.286). Ele complementa ainda que a capacidade de

armazenamento presente no sistema de arquivos do Lustre é o somatório total do tamanho de todos os

volumes presentes na arquitetura., por exemplo, cinco servidores OSS com 10GB de volume provêm um

sistema de arquivos com capacidade total de 50 GB em sua estrutura.

Figura 1 – Lustre File System (KLING-PETERSEN, 2009)

Segundo Hermann (2006), o funcionamento do Lustre ocorre da seguinte maneira: conforme ilustra a

Figura 1: cliente necessita acessar um determinado arquivo num dos discos de armazenamento, o acesso

ocorre de forma indireta, pois antes é preciso passar pelo servidor de metadados (MDS) para se descobrir a

localização do arquivo desejado. Após a obtenção da localização, o acesso ocorre de forma direta, assim o

cliente pode ler e escrever dados no disco de armazenamento. O servidor de metadados não faz parte da

transferência do arquivo, sua função é armazenar o metadado que contém a localização do arquivo e permitir

que o cliente altere os atributos de um arquivo, como por exemplo, aumentar o tamanho do arquivo. A

alteração do atributo no MDS permite que o arquivo modificado seja visível para os demais clientes.

2.7 O projeto Apache Hadoop

O projeto Hadoop foi desenvolvido por Doug Cutting, o criador do Apache Lucene. A proposta deste

framework surgiu como um motor de pesquisa em código aberto para a Rede Mundial de Computadores ou

World Wide Web (WWW). Este projeto foi introduzido oficialmente em 2006, numa parceira entre Cutting e

o site de pesquisa Yahoo. Uma união entre o modelo de processamento distribuído de dados chamado

MapReduce, desenvolvido pelo Google, e o sistema de arquivos HDFS, criado pelo Doug Cutting. Mas o

lançamento definitivo do projeto Apache Hadoop ocorreu em janeiro de 2008, de lá até hoje, uma grande

variedade de empresas e organizações se somam à estratégia empresarial da comunidade Hadoop, como

Yahoo, Last.fm, New York Times (NYT) e Facebook (WHITE, 2009).

Conforme Taurion (2009), como um exemplo da eficiência na utilização do Hadoop, em fevereiro de

2008, foi disponibilizado um link dentro da página oficial do jornal americano NYT com nome de Times

Machine. O NYT digitalizou os jornais do ano 1851 até 1989, gerando em torno de 11 milhões de artigos

deste acervo. De posse dos artigos digitalizados no formato TIFF, com cerca de 4 terabytes, o NYT utilizou o

framework Hadoop para converter estes arquivos para o formato PDF, gerando um total de 1,5 terabytes

neste novo formato. Foi utilizado o modelo de programação paralela do Hadoop juntamente com 100

máquinas alugadas através da Amazon Elastic Cloud Computing (Amazon's EC2), que presta serviços em

computação em nuvens para a comunidade internacional. O processo de conversão dos arquivos levou menos

de vinte e quatro horas, a um custo de 240 dólares. Com isto, "o Hadoop deverá ser a base tecnológica para

o desenvolvimento de novas aplicações Open Source orientado para operar especificamente em nuvens"

(TAURION, 2009, p.52). O NYT hospedou publicamente em seu site somente as reportagens até o ano de

1922, entretanto, todo o acervo está disponível para os assinantes do jornal.

Atualmente, o projeto Apache Hadoop está relacionado com diversos subprojetos de grande

importância para a computação distribuída, que o torna mais confiável e escalável. Toda a infra-estrutura

desta arquitetura é hospedada pela Apache Software Foundation e baseada em softwares de código aberto.

Como pode ser visto na Figura 2, o projeto contempla nove subprojetos, sendo que o sistema de arquivos

HDFS e o processador de dados MapReduce são os softwares mais importantes do framework Hadoop

(WHITE, 2009).

A seguir, é exibida uma breve descrição de cada um dos subprojetos pertencentes ao Apache

Hadoop, sendo que o Core foi renomeado para Hadoop Common, mesmo que pareçam estar juntos são

projetos independentes um do outro.

Figura 2 – Subprojetos do Apache Hadoop (WHITE, 2009)

Pig: é uma plataforma para analisar grande quantidade de fluxo de dados, contendo uma

linguagem de alto nível, programas de análise de dados e uma infra-estrutura de avaliação. Utiliza

a paralelização para lidar com grande quantidade de dados, além do HDFS e MapReduce;

Chawka: é um sistema de coleta de dados para gerenciamento de grandes sistemas distribuídos.

Ele usa o HDFS para coletar e armazenar os dados e o MapReduce para gerar relatórios;

Hive: é um depósito de dados distribuídos. Ele administra dados armazenados em HDFS e

fornece uma linguagem de consulta de dados baseada em SQL;

HBase: é uma base de dados distribuída e escalável, que suporta uma estrutura de armazenamento

de dados para tabelas grandes. Ele usa o HDFS para armazenar sua base e MapReduce para os

pontos de consulta (e leituras aleatórias);

MapReduce: é um modelo de processamento distribuído de dados que visa processar vastas

quantidades de dados em paralelo através dos nós de grandes conjuntos computacionais

agrupados (ou clusters);

HDFS: é um sistema de arquivos distribuído que cria uma divisão dos dados da entrada em

tamanhos iguais e distribui entre os nós de um cluster para permitir segurança e rapidez no

processamento de dados, agrega um sistema de replicação destes dados;

Zoo Keeper: é um serviço de coordenação de alto desempenho para aplicações distribuídas.

Usado para manter as informações de configuração, nomes, além de fornecer sincronização

distribuída e serviços de grupo;

Common (ex-Core): é um conjunto de componentes e interfaces comuns para ser utilizado em

sistemas distribuídos e dispositivos de E/S. (Serialização através de RPC e estruturas de dados

persistentes);

Avro: um sistema de serialização de dados que fornece uma integração dinâmica com linguagens

de scripting. Ele é composto de: um recipiente para armazenar dados persistentes, formato de

dados binário eficiente e chamada de procedimento remoto ou Remote Procedure Call (RPC).

2.7.1 Sistemas de arquivos distribuídos Hadoop (HDFS)

O segundo sistema de arquivos que terá seu desempenho testado é um subprojeto do framework

Apache Hadoop com nome de Sistema de Arquivos Distribuídos Hadoop ou Hadoop Distribuited File

System (HDFS). Na seção 3 será possível fazer a comparação entre os dois sistemas de arquivos LustreFS e

HDFS estudados neste projeto.

O sistema de arquivos distribuído HDFS surgiu para resolver eventuais problemas com falhas de

equipamentos, através da utilização da replicação dos dados. Estes problemas são comuns quando se utiliza

um grande número de máquinas dependentes uma das outras para realizar uma determinada tarefa. Conforme

Kassick, para solucionar este problema, "os dados do HDFS são sempre replicados em diversos servidores

para garantir tolerância a falhas" (2010, p.36), ou seja, cópias redundantes estão sempre disponíveis quando

ocorre qualquer problema com hardware, com isto, evita-se a perda de dados. Esta é uma das características

da arquitetura HPC que está presente no projeto Hadoop.

Os sistemas heterogêneos, que utilizam clusters com máquinas de diversas marcas e com diferentes

características, estão mais suscetíveis a inoperância através de falhas em hardware. A solução encontrada

pelo HDFS, com a replicação dos dados, proporcionou um eficiente trabalho, não só com sistemas

homogêneos, mas também com sistemas heterogêneos. Quando o sistema perde contato com algum

equipamento devido a alguma falha, outro equipamento é colocado no lugar mantendo o sistema

funcionando ininterruptamente, estes processos ocorrem com a abstração dos programadores das tarefas de

paralelização (WHITE, 2009).

A prioridade na arquitetura HDFS é a alta vazão dos dados e a baixa latência. Ela foi desenhada para

aplicações eficientes, como clusters, que gerenciam grandes quantidades de dados. Segundo White, "O

HDFS é um sistema de arquivos projetado para armazenar arquivos muito grandes com streaming data

access padrões, sendo executado em clusters de hardware comuns" (2009, p.41). Esta frase de White pode

ser desmembrada nas seguintes explicações: arquivos muito grandes, algumas vezes, giram em torno de

terabytes ou petabytes. O HDFS acessa os dados continuamente (streaming data access) com abordagem

write-once/read-many-times, ou seja, grava uma vez e lê muitas vezes. Os dados são gerados uma única vez

na origem, e lidos diversas vezes ao longo do tempo, durante as execuções paralelas. Por fim, clusters de

hardware comuns consistem num agrupamento de máquinas disponibilizadas de vários fornecedores e

suscetíveis a falhas, que agrupadas proporcionam um sistema HPC altamente confiável.

A arquitetura do HDFS "consiste em um servidor de metadados centralizado chamado NameNode e

diversos servidores de dados, os DataNodes. Os dados são divididos em blocos que são distribuídos entre os

DataNodes" (KASSICK, 2010, p.36). Existe uma replicação automática dos dados para diversos DataNodes

nos diversos racks da rede. Em relação às políticas empregadas, o que se busca com o HDFS é ter máxima

vazão e perda mínima de dados, seja por falhas em disco ou em algum DataNode, seja por problemas mais

graves como a queda da operabilidade de racks inteiros.

Ainda há dois fatores importantes que devem ser observados nesta arquitetura: em primeiro lugar,

não é permitido que um arquivo seja gravado por mais de um cliente ao mesmo tempo. Há um eficiente

mecanismo de consistência que auxilia no controle dos dados no servidor de metadados ou NameNodes. O

segundo é priorizar a execução de aplicações próximas à máquina de origem ou naquela em que os dados

residem. Quando os nós de execução se encontram distantes dos DataNodes, os dados devem ser transferidos

pela rede e não está descartada a possibilidade de um grande congestionamento na rede e, conseqüentemente,

um baixo desempenho da mesma (KASSICK, 2010).

3 METODOLOGIA PARA IMPLEMENTAÇÃO DO LUSTREFS E HDFS

A implementação deste projeto aconteceu no Laboratório da Legere Sistemas Dinâmicos, que tem

uma parceria com o Instituto de Inovação e Pró-Reitoria de Pesquisa e Pós Graduação da Ulbra, situado no

Centro Tecnológico da Ulbra em Canoas, sala 209 do prédio 14.

As etapas necessárias para o desenvolvimento deste projeto, denominado Rede Legere, envolveram

as seguintes implementações: montagem e configuração de um agrupamento de computadores ou cluster,

instalação e configuração dos sistemas de arquivos LustreFS e HDFS e, por fim, a instalação e configuração

de uma ferramenta de gerência de redes, o Cacti. Todas estas etapas estão documentadas no decorrer deste

capítulo.

3.1 Montagem e configuração de um agrupamento de computadores ou cluster HPC

Para se construir um cluster HPC, foi necessário agrupar diversos computadores num ambiente

apropriado, além de instalar o sistema operacional Linux em cada um dos nós e configurar a rede e os

serviços de rede, como DHCP, DNS e SSH, que serão apresentados mais adiante na subseção 3.1.1. Estes

serviços de rede são necessários para o correto funcionamento e gerenciamento de um cluster de alto

desempenho.

3.1.1 Montagem do cluster HPC

Um ambiente de rede heterogêneo foi construído para a execução dos testes de desempenho entre os

dois sistemas de arquivos estudados. Os testes podem ser vistos no capítulo 4 deste trabalho. Neste ambiente,

seis computadores foram interligados através de switches. No servidor principal Kaigang foi instalado o

sistema operacional Linux Ubuntu Server 64bits - versão 8.10. Em uma das máquinas chamada de Rgrande

foi instalado o RedHat Enterprise Linux Server 5.5, optou-se por essa distribuição Linux, pois ela se adaptou

melhor à instalação do Lustre.

Nas demais máquinas, Fontoura, Farroupilha e Feliz e Guaíba, foi escolhido o Linux Ubuntu Generic

x86 - versão 8.10. As seis máquinas abrangeram quatro modelos distintos de hardware: o servidor Kaigang

era um Server Intel Core 2 Duo E4300. Farroupilha, Feliz e Guaíba eram um Dell Power Edge 1300,

Fontoura, um Dell Power Edge 600SC e Rgrande, um Intel Core 2 Duo E7400. Portanto, a rede pôde ser

considerada uma arquitetura heterogênea. Na Figura 3 é apresentado o cenário original do ambiente

clusterizado contendo detalhes como: nomes de domínio, relação de endereços IPs, quantidades e tipos de

disco existentes, portas e placas de rede, versão do Kernel do Linux, serviços de rede, bem como, o SO, login

e a senha utilizados em cada computador da rede.

No servidor Kaigang existem duas placas de rede plugadas na placa-mãe. O servidor Kaigang era o

front-end do cluster. Assim, a montagem física do agrupamento de computadores de alto desempenho

(cluster HPC) ficou concluída, sendo necessário apenas configurar os serviços de rede que serão detalhados

na subseção 3.1.2.

No Kaigang, foi configurado o servidor Dynamic Host Configuration Protocol (DHCP) com objetivo

de automatizar o endereçamento de rede IP. Neste projeto, foi selecionado um range com noventa endereços

IPs, contemplando 172.16.1.10 até 172.16.1.99, mas foram usados apenas seis deles, como mostra a Figura

3.

O servidor Domain Name System (DNS) foi configurado para atribuir nomes para cada um dos

endereços IPs contemplados pelo servidor DHCP. No servidor Kaigang, o arquivo /etc/dhcp3/dhcpd.conf foi

configurado para fixar-se os endereços IPs por endereços de máquina (mac).

O Secure Shell ou servidor SSH, segundo Marimoto (2008), serve para administrar o servidor. Com

ele é possível transferir arquivos, executar comandos, rodar e instalar aplicativos remotamente. Desta forma,

toda a rede pôde ser gerenciada diretamente do prompt de comando do servidor Kaigang. Para habilitar o

funcionamento do SSH de forma automática, foi preciso gerar uma chave pública que fosse entendida por

todas as máquinas do cluster. Após a configuração do SSH, o acesso às máquinas ocorreu sem necessidade

de colocação manual de senha. Por exemplo, através do Terminal Console, o acesso direto entre o servidor

Kaigang e a máquina Feliz se dava por um destes três comandos: ssh root@172.16.1.15 ou ssh root@feliz ou

ainda ssh feliz.

SLAVE 3 - FELIZ

IP: 172.16.1.15 (eth0)

/dev/sda – 9 GB

/dev/sdb – 9 GB

Kernel - 2.6.27-7-Gen

Login: Root

Password: ht4gt4rs

Servidor SSH

Servidor DNS

SLAVE 4 - GUAIBA

IP: 172.16.1.16 (eth0)

/dev/sda – 9 GB

/dev/sdb – 9 GB

Kernel - 2.6.27-14-Gen

Login: Root

Password: ht4gt4rs

Servidor SSH

Servidor DNS

Switch D-Link-1016D

18 Portas

Switch 3.com

24 Portas

Internet

KAIGANG SERVER

IP: 172.16.1.10 (eth0)

IP externo (WEB)

10.2.9.102 (eth1)

/dev/sda: 160.0 GB

Kernel - 2.6.24-28-Gen

Login: Root

Password: ht4gt4rs

Servidor DHCP

Servidor SSH

Servidor DNS

Modelo

CLIENTE/SERVIDOR

SLAVE 6 - RGRANDE

IP: 172.16.1.18 (eth0)

/dev/hdb – 40 GB

/dev/hdc – 40 GB

/dev/sda – 500 GB

Kernel - 2.6.18-194

Login: Root

Password: ht4gt4rs

Servidor SSH

Servidor DNS

CLUSTER HPC

SLAVE 2 -

FONTOURA

IP: 172.16.1.14 (eth0)

/dev/sda – 36 GB

/dev/sdb – 9 GB

Kernel - 2.6.27-14-Gen

Login: Root

Password: ht4gt4rs

Servidor SSH

Servidor DNS

SLAVE 1 -

FARROPILHA

IP: 172.16.1.13 (eth0)

/dev/sda – 9 GB

/dev/sdb – 9 GB

/dev/sdc – 9 GB

Kernel - 2.6.27-17-Gen

Login: Root

Password: ht4gt4rs

Servidor SSH

Servidor DNS

Linux Ubuntu Server 64bits

- versão 8.10

Linux Ubuntu Generic x86

- versão 8.10

Linux Ubuntu Generic x86

- versão 8.10

Linux Ubuntu Generic x86

- versão 8.10

Linux Ubuntu Generic x86

- versão 8.10

RedHat Enterprise Linux

Server 5.5

eth0

eth1

eth0

eth0

eth0

eth0

eth0

Figura 3 – Esquema do Agrupamento de Computadores ou Cluster HPC

3.2 Instalação e configuração dos sistemas de arquivos LustreFS e HDFS

Nesta seção, serão apresentadas a instalação e configuração dos dois sistemas de arquivos escolhidos

para este projeto. Na subseção 3.2.1, é detalhada a instalação e configuração do sistema de arquivos

LustreFS. Na subseção 3.2.2, é descrita a implementação e configuração do sistema de arquivos HDFS.

Ambos apresentam seus principais serviços e dependências. O LustreFS foi instalado na máquina Rgrande.

Já o HDFS foi instalado em cinco máquinas, Kaigang, Farroupilha, Fontoura, Feliz e Guaiba.

3.2.1 Instalação e configuração do LustreFS

Os códigos de instalação do Lustre encontram-se disponíveis para download no site oficial da Sun

Microsystems: http://www.sun.com/download/. As versões escolhidas do LustreFS e do SO, respectivamente,

foram: Lustre.1.8.4.i686 e Red Hat Enterprise Linux Server 5.5.

Um dos pré-requisitos para uma instalação efetiva do LustreFS exige que o Kernel do Linux tenha

que ser recompilado. Por isso, optou-se pela montagem do LustreFS somente na máquina Rgrande, uma vez

que instalá-lo em outras máquinas poderia inviabilizar as configurações prévias de outros sistemas de

arquivos e da ferramenta de monitoração presentes na rede. O Lustre.1.8.4.i686 utilizou os seguintes binários

como requisitos para uma instalação bem sucedida no cluster:

e2fsprogs-1.41.10.sun2-0redhat.rhel5.i386.rpm;

kernel-2.6.18-194.3.1.el5_lustre.1.8.4.i686.rpm;

lustre-ldiskfs-3.1.3-2.6.18_194.3.1.el5_lustre.1.8.4.i686.prm;

lustre-source-1.8.4-2.6.18_194.3.1.el5_lustre.1.8.4.i686.rpm;

lustre-1.8.4-2.6.18_194.3.1.el5_lustre.1.8.4.i686.rpm;

lustre-modules-1.8.4-2.6.18_194.3.1.el5_lustre.1.8.4.i686.rpm;

lustre-client-modules-1.8.4-2.6.18_194.3.1.el5_lustre.1.8.4.i686.

Foi necessário seguir alguns procedimentos e verificações para se obter êxito na instalação do

LustreFS. Utilizaram-se dois discos rígidos secundários para essa instalação: um para o Servidor de

Metadados (MDS) que contém o Disco de Armazenamento de Metadado (MDT) e o Serviço de

Gerenciamento (MGS) e outro para o Servidor de Armazenamento (OSS) que contém o Disco de

Armazenamento de Objetos (OST). O primeiro HD, alocado no diretório dev/hdb e com 40 GB de espaço,

usou a partição dev/hdb2 para configurar o Lustre-MDS-MDT. O segundo HD, alocado no diretório dev/sda

e com 500 GB de espaço, teve três partições formatadas com 100 GB de espaço cada uma, e numa delas, a

partição dev/sda1, foi configurado o Lustre-OSS-OST, como pode ser visto na Figura 4 da subseção 3.2.2. A

instalação do cliente, por ser opcional, não foi utilizada neste projeto. As principais etapas da instalação do

LustreFS na máquina Rgrande foram:

Arquivo de módulos do LustreFS: editou-se o arquivo de módulos /etc/modprobe.conf e incluiu-

se a placa de rede eth0 no seguinte comando:

options lnet networks=tcp(eth0);

Formatação do MGS/MDT: criou-se um combinado MGS/MDT na partição /dev/hdb2 para ser

formatado através do comando:

mkfs.lustre --fsname=spfs --reformat --mdt --mgs /dev/hdb2;

Ponto de montagem do MGS/MDT: adicionou-se um ponto de montagem no diretório /mnt com a

seguinte instrução:

mkdir -p lustre-mgs-mds;

Montagem do MGS/MDT: montou-se o combinado MGS/MDT na partição /dev/hdb2 com o

seguinte comando:

mount -t lustre /dev/hdb2 /mnt/lustre-mgs-mds;

Formatação do OSS/OST: criou-se um combinado OSS/OST na partição /dev/sda1 para ser

formatado através do comando:

mkfs.lustre --fsname=spfs --reformat --ost --mgsnode=172.16.1.18@tcp0 /dev/sda1;

Ponto de montagem do MGS/OST: adicionou-se um ponto de montagem no diretório /mnt com a

seguinte instrução:

mkdir -p lustre-ost;

Montagem do OSS/OST: montou-se o combinado OSS/OST na partição /dev/sda1 com o

comando:

mount -t lustre /dev/sda1 /mnt/lustre-ost;

Edição do arquivo /etc/fstab: editou-se o arquivo /etc/fstab e incluíram-se os discos e os pontos de

montagem do MGS/MDT e OSS/OST com a adição das seguintes linhas neste arquivo:

/dev/hdb2 /mnt/lustre-mgs-mds lustre defaults,_netdev 0 0 e /dev/sda1 /mnt/lustre-ost lustre

defaults,_netdev 0 0;

Verificação do Lustre: para verificar se o Lustre está rodando, usou-se a instrução lctl list_nids. A

resposta correta deste comando foi 172.16.1.18@tcp. Entretanto, se ocorrer algum erro nesta

verificação, faz-se necessário carregar e atualizar novamente os módulos do Lustre. Para isso,

usou-se o comando:

modprobe -v lustre;

Outros comandos para verificação são: lctl ping 172.16.1.18 e lctl device_list, o primeiro

comando verifica se o IP está ativo no Lustre e o segundo exibe uma lista com todos os serviços

do Lustre em execução;

Instalação da ferramenta de monitoração Cacti, idêntica utilizado na máquina kaigang;

Ler e gravar um arquivo no LustreFS: dentro do diretório /Lustre, foi executado o comando

dd if=/dev/zero of=/lustre/zero.dat bs=80M count=10.

Este comando gerou um arquivo de 8GB com nome de zero.dat, este processo foi monitorado

pelo Cacti para capturar o desempenho da máquina local Rgrande.

Por fim se pode verificar a configuração dos dispositivos com o LustreFS através do comando:

lctl device_list

0 UP mgs MGS MGS 5

1 UP mgc MGC172.16.1.18@tcp 2bb93da1-d841-2730-4206-5a569f15f143 5

2 UP mdt MDS MDS_uuid 3

3 UP lov spfs-mdtlov spfs-mdtlov_UUID 4

4 UP mds spfs-MDT0000 spfs-MDT0000_UUID 3

5 UP ost OSS OSS_uuid 3

6 UP obdfilter spfs-OST0000 spfs-OST0000_UUID 5

7 UP osc spfs-OST0000-osc spfs-mdtlov_UUID 5

3.2.2 Instalação e configuração do HDFS

Os códigos de instalação do Hadoop encontram-se disponíveis para download no site oficial do

Apache: http://www.apache.org - The Apache Software Foundation. A versão Hadoop-0.20.2 utilizada nesta

instalação foi obtida num dos repositórios oficiais.

Uma configuração bem sucedida do Hadoop considera que os três pré-requisitos fundamentais de

instalação devam ter sido cumpridos satisfatoriamente. Na Figura 4 é possível observar estes pré-requisitos,

que são:

Java 6 SDK ou superior: é preciso utilizar uma versão igual ou superior ao Java-1.6.x SDK. Neste

cluster foi utilizado o Java-6-Sun. O Java é necessário, pois o Hadoop utiliza a linguagem Java

para a construção de um WebService para o tratamento das requisições vindas do cliente, além de

uma interface para mostrar a execução de seus processos e exibir os slaves do cluster;

SSH ou Secure Shell: já mencionado na subseção 3.1.2. O Hadoop também necessita do servidor

SSH, pois, durante sua execução, uma conexão formada entre o servidor Kaigang e cada slave

deve ocorrer de forma automática e transparente, sem nenhuma validação de login ou senha;

usuário dedicado: em todas as estações deve ser utilizado um usuário dedicado. Neste cluster

utilizou-se o usuário supervisor. É um requisito recomendado porque separa a instalação do

Hadoop de outros softwares e contas de usuário em execução, favorecendo quesitos como:

segurança, permissões, backups, etc. Esta etapa considera que o SSH já tenha sido implementado

corretamente em todas as estações, conforme visto no item anterior.

A configuração do Hadoop no servidor e em cada um dos quatro slaves é idêntica, portanto é

necessário que se instale o Hadoop no servidor como se fosse um nó e após alterar a configuração em cada

uma das estações ou slaves. Os passos da instalação são:

Diretório de instalação: foi escolhido o diretório /usr/local/hadoops para instalar o Hadoop em

todas as estações da rede;

Versão do Java instalado: no diretório/usr/local/hadoops/conf alterar a variável de ambiente

hadoop-env.sh com o nome e o caminho das instalação do Java na máquina, através do comando:

export JAVA_HOME=/usr/lib/jvm/Java-6-Sun;

Arquivos de configuração do Hadoop: no diretório /usr/local/hadoops/conf editou-se os três

arquivos de configuração do Hadoop: core-site.xml, mapred-site.xml e hdfs-site.xml. No primeiro

e no segundo foi indicado o nome do servidor e a porta utilizada, respectivamente, kaigang:54310

e kaigang:54311. No terceiro foi necessário definir a quantidade de replicação dos dados como

"3", que é o número padrão para o máximo de replicações utilizado pelo Hadoop;

Formatar o namenode: a formatação do namenode foi feita apenas uma vez durante a

configuração do Hadoop. Só em casos emergenciais é permitido reformatar o namenode. Para

formatar utilizou-se o comando bin/hadoop namenode -format dentro do diretório

/usr/local/hadoops/.

Executar, verificar e parar a execução do Hadoop: dentro do diretório /usr/local/hadoops/, os

comandos utilizados para executar e parar, de uma só vez, todos os serviços do Hadoop,

respectivamente, são: bin/start-all.sh e bin/stop-all.sh.

Inicializar individualmente o HDFS, usa-se o bin/start-dfs.sh e para encerrá-lo usa-se bin/stop-

dfs.sh. Já o MapReduce, é executado através do bin/start-mapred.sh e encerrado com o bin/stop-

mapred.sh. O comando jps é utilizado para verificar se o Hadoop está rodando.

Configurar os arquivos mestre e escravos: editar o arquivo /usr/local/hadoops/conf/masters e

adicionar o nome do servidor "kaigang" como servidor mestre. Também foi editado o arquivo

/usr/local/hadoops/conf/slaves, colocando-se novamente o servidor mestre e incluindo-se também

o nome dos 5 hosts numa seqüência vertical, desta forma: "Kaigang", "Fontoura", "Farroupilha",

"Feliz" e "Guaiba";

Executar a leitura de um arquivo no Hadoop: durante a execução do HDFS, é possível ler um

arquivo utilizando-se a seguinte instrução:

bin/hadoop dfs -copyFromLocal /opt/nome_do_arquivo ~/opt/input/input.

Este comando foi executado dentro do diretório /usr/local/hadoops/, com isso, o HDFS começou

a ler o arquivo e armazenar os eventos na pasta ~/opt/input/input.

SLAVE 3 - FELIZ

IP: 172.16.1.15 (eth0)

Login: Root

Password: ht4gt4rs

HADOOP-0.20.2

JAVA-6-SUN

SSH

USUÁRIO DEDICADO:

Root

SLAVE 4 - GUAIBA

IP: 172.16.1.16 (eth0)

Login: Root

Password: ht4gt4rs

HADOOP-0.20.2

JAVA-6-SUN

SSH

USUÁRIO DEDICADO:

Root

Switch D-Link-1016D

18 Portas

Switch 3.com

24 Portas

Internet

KAIGANG SERVER

IP: 172.16.1.10 (eth0)

Login: Root

Password: ht4gt4rs

HDFS-HADOOP-0.20.2

JAVA-6-SUN

SSH

BROWSER FIREFOX

USUÁRIO DEDICADO:

Root

SLAVE 6 - RGRANDE

IP: 172.16.1.18 (eth0)

Login: Root

Password: ht4gt4rs

HDFS, LustreFS e

Ferramenta CACTI

SLAVE 2 -

FONTOURA

IP: 172.16.1.14 (eth0)

Login: Root

Password: ht4gt4rs

HADOOP-0.20.2

JAVA-6-SUN

SSH

USUÁRIO DEDICADO:

Root

SLAVE 1 -

FARROPILHA

IP: 172.16.1.13 (eth0)

Login: Root

Password: ht4gt4rs

HADOOP-0.20.2

JAVA-6-SUN

SSH

USUÁRIO DEDICADO:

Root

Linux Ubuntu Server 64bits

- versão 8.10

Linux Ubuntu Generic x86

- versão 8.10

Linux Ubuntu Generic x86

- versão 8.10

Linux Ubuntu Generic x86

- versão 8.10

Linux Ubuntu Generic x86

- versão 8.10

RedHat Enterprise Linux

Server 5.5 LustreFS

hdb2 – 40 GB (MDS,

MDT e MGS)

hdc1 – 36 GB (RedHat)

sda1 – 100 GB (OSS e

OST)

Kernel - 2.6.18-194

Login: Root

Password: ht4gt4rs

eth1

eth0

eth0

eth0

eth0

eth0

eth0

CACTI no KAIGANG

Data Base MySQL

Web Server Apache

Script PHP

SNMP Agent

Benchmark CACTI

SEA MONKEY

Ferramenta RRDTool

(Cacti também foi

instalado na máquina

Rgrande)

Figura 4 – Esquema da Instalação do HDFS, LustreFS e Cacti

Interface Web: o Hadoop utiliza uma interface Web para exibir todos os processos que estão

sendo executados pelo sistema de arquivos. Com o Hadoop rodando, acessou-se o endereço

http://localhost:50030 pelo browser que mostrou todos os processos jobtracker do Mapreduce (o

jobtracker é o processo mestre). O endereço, http://localhost:50060 mostrou quais task trackers

estão ou não rodando (o task tracker é o processo escravo que roda em cada nó executor de

tarefas) e, por último, o endereço http://localhost:50070 que permitiu visualizar os namenodes

que executavam dentro do cluster.

3.3 Aplicação da ferramenta de monitoração Cacti

Neste trabalho, a ferramenta que proporcionou uma análise de desempenho entre os sistemas de

arquivos LustreFS e HDFS foi o Cacti. O Cacti necessita de um servidor de banco de dados (DB), de um

servidor Web, de um browser, de um script de linguagem de programação e de um protocolo de gerência de

redes, como pode ser visto na Figura 3. Considerou-se relatar apenas a instalação do Cacti no servidor

Kaigang, entretanto uma instalação semelhante também ocorreu na máquina Rgrande, que foi utilizada

localmente para executar os testes de desempenho do sistema LustreFS.

3.3.1 Instalação e configuração do servidor de banco de dados MYSQL

A ferramenta Cacti utiliza um servidor de banco de dados MYSQL para armazenar com segurança os

dados coletados durante o seu processo de captura. Conforme Marimoto (2008), o acesso ao banco de dados

se dá através de uma linguagem de programação específica, por exemplo, PHP, linguagem C ou C++. A

versão do MYSQL instalada no servidor Kaigang foi MYSQL-5.0.49. Conforme Costa (2008), a

configuração deste BD relacionou as seguintes etapas:

Criou-se, respectivamente, um grupo e um usuário MYSQL através dos comandos groupadd

mysql e useradd -d /dev/null -s /bin/false -g mysql mysql;

Obteve-se através do site oficial http://www.mysql.com a última versão do pacote.

Habilitaram-se os logs de transações para visualizar os eventos gerados pelas ferramentas de

monitoração do Cacti, para isso, editou-se o /etc/my.cnf incluindo ao final da tabela a linha log =

/var/log/mysql/mysqld.log.

Colocou-se o script de inicialização do MYSQL /etc/init.d/mysql no boot do Linux Ubuntu.

Verificou-se a execução do DB através do comando netstat -nat | grep 3306 para confirmar a

execução DB, bem como, a porta que está sendo utilizado pelo servidor MYSQL. O resultado

deste comando foi:

tcp 0 0 127.0.0.1:3306 0.0.0.0:* Ouça.

3.3.2 Instalação e Configuração do servidor Web Apache

Além do MYSQL, que foi utilizado para armazenar os dados coletados durante a execução dos testes

de desempenho, utilizou-se ainda uma página Web para apresentar seus resultados. Houve necessidade,

portanto, de um servidor HTTP para hospedar essa página. A versão do servidor Apache instalada no

servidor Kaigang foi Apache-2.2.16. Conforme Costa (2008), a configuração do servidor Apache envolveu

as seguintes etapas:

Criou-se, respectivamente, um grupo e um usuário www-data através dos comandos groupadd

www-data e useradd -g www-data -s /bin/false -d /dev/null www-data.

Obteve-se através do site oficial http://www.apache.org a última versão do pacote;

Colocou-se o script de inicialização do Apache em /etc/init.d/apache2 no boot no Linux;

Verificou-se a execução do Apache através dos processos que estão sendo executados pelo

servidor, bem como a porta que está sendo utilizada, através dos comandos ps -ef | grep httpd e

netstat -nat | grep 80. O resultado deste último comando foi:

tcp 0 0 0.0.0.0:80 0.0.0.0:* OUÇA.

3.3.3 Instalação e configuração do suporte à linguagem PHP (Personal Home Page)

Além do MYSQL e do Apache, o Cacti necessitou da instalação do suporte à linguagem de

programação PHP (ou script PHP), que viabilizou a criação de páginas com muito mais rapidez e segurança.

A versão do script PHP instalado no servidor Kaigang foi PHP-5.2.14. Conforme Costa (2008), a

configuração do PHP abrangeu as seguintes etapas:

Obteve-se através do site oficial http://www.php.net a última versão do pacote.

Criou-se o arquivo de log com o comando touch /var/log/apache2/php_error.log para as

mensagens de erro do PHP ficaram armazenadas neste arquivo.

Ajustaram-se as permissões ao PHP com os comandos:

chown -R root.www-data /usr/local/lib/php e chmod -R g-w,o-rwx /usr/local/lib/php.

Ativou-se o suporte ao Apache com a edição do arquivo /etc/apache2/httpd.conf onde foram

incluídos três módulos do PHP:

LoadModule php5_module, libexec/libphp5.so e AddModule mod_php5.c.

Reiniciou-se o Apache e verificou-se o funcionamento do PHP através do comando php -v para

verificar a versão instalada do PHP e lynx -dump -head http://localhost para ver se ele estava

rodando. A resposta deste último comando foi:

HTTP/1.1 200 OK.

3.3.4 Instalação e Configuração do protocolo SNMP (Simple Network Management Protocol)

O Cacti necessitou que o agente SNMP estivesse instalado e configurado no servidor Kaigang.

Conforme Costa (2008), "o SNMP é um protocolo de gerência típica de redes TCP/IP, da camada de

aplicação que facilita o intercâmbio de informação entre os dispositivos de rede" (2008, p.21). A versão do

SNMP instalado no servidor Kaigang foi SNMP-5.2.1.2. Conforme Costa (2008), a configuração do SNMP,

resumidamente, contou com as seguintes etapas:

Foi baixado o pacote SNMP através do comando apt-get install snmpd.

Editou-se o arquivo /etc/snmp/snmpd.conf com a adição do Localhost do servidor, que era

172.16.1.10, e a comunidade chamada de InfoMONITOR.

Testou-se a consulta no SNMP, através do comando snmpwalk -v1 -c infoMONITOR 172.16.1.10.

Como resposta, ele mostrou a versão do SNMP e várias informações sobre os dispositivos

gerenciados.

Realizou-se diversas consultas com o agente SNMP, através do comando snmpwalk ou snmpget.

O comando snmpwalk -v2c -c infoMONITOR localhost listou diversas informações dos

dispositivos gerenciados.

3.3.5 Instalação e configuração do Cacti

"Cacti é uma ferramenta que recolhe e exibe informações sobre o estado de uma rede de

computadores através de gráficos. [...] Monitora o estado de elementos de rede e programas bem como a

largura de banda utilizada e o uso de CPU". (COSTA, 2008, p.43).

Após todas as dependências anteriores do Cacti, como MYSQL, Apache, PHP e SNMP, estarem

executando no servidor, além da ferramenta RRDTool (Round Robin Database). Os códigos de instalação do

Cacti encontram-se disponíveis para download no site oficial: http://www.cacti.net. A versão utilizada neste

projeto foi cacti-0.8.6j. Conforme Costa (2008), a configuração do Cacti cumpriu as seguintes etapas:

Criação da Base de dados no MYSQL: dentro da pasta /usr/local/src/cacti-0.8.7j executou-se o

comando mysqladmin -u root create cacti -p. Pediu a senha do MySQL que é 123456. Após abriu

o prompt de comando do MYSQL, onde foram adicionadas as seguintes linhas: mysql cacti <

cacti.sql -p, mysql -u root -p (pediu a senha novamente) e GRANT ALL ON cacti. *TO

cactiuser@localhost IDENTIFIED BY 'senha'; flush privileges;

Ajuste de configurações no Cacti: dentro da pasta /usr/local/src/cacti-0.8.7j, foi editado o arquivo

include /config.php e incluído os seguintes parâmetros:

$database_default = "cacti":,

$database_hostname = "localhost":

$database_usename = "admin":

$database_password = "123456":

Ajuste de permissões de usuário do Cacti: os comandos para ajuste de permissões do usuário

Cacti foram chown -R cactiuser rra e chown -R cactiuser log.

Configuração de agendamento através do Crontab: editou-se o crontab -e adicionando-se a linha

*/5 * * * * php /var/www/cacti/poller.php > /dev/null 2>&1.

Uma leitura é realizada a cada 5 em 5 minutos através do crontab.

Direcionar o Cacti para o Diretório do Apache: toda a instalação do Cacti que se encontrava no

diretório /usr/local/src foi direcionada, através de um link simbólico, para dentro do diretório raiz

do apache que é /var/www/cacti, habilitando-se o acesso do cacti como uma página Web.

3.3.6 Instalação do browser Sea Monkey

Foi instalado o navegador Sea Monkey para cumprir a última etapa de instalação do Cacti. O

processo de configuração do Cacti é simples, ou seja, através do endereço do servidor de monitoração

Kaigang: http://172.16.1.10/cacti/install/index.php, sendo aberta a página do Cacti. A configuração é

bastante intuitiva, bastando selecionar as etapas necessárias. A configuração finaliza com uma tela de login

do usuário onde foi incluído como usuário "admin" e a senha de "123456". Com isso o Cacti foi instalado

com sucesso. (COSTA, 2008, p.45-48).

As telas de configuração do Cacti não serão apresentadas neste projeto, mas podem ser consultadas

na referência do Felipe Costa "Ambiente de Rede Monitorado com Nagios e Cacti", páginas 49 até 67. No

próximo capítulo serão apresentados os todos os testes pertinentes aos dois sistemas de arquivos que estarão

sendo monitorados pelo Cacti no navegador Sea Monkey.

4 ANÁLISE DOS RESULTADOS

O LustreFS e a ferramenta de monitoração Cacti, foram instalados na máquina Rgrande para coletar

os eventos desta máquina. O HDFS, por sua vez, foi monitorado pelo Cacti instalado na máquina Kaigang.

4.1 Análise de desempenho do sistema de arquivos LustreFS

Com o comando dd if=/dev/zero of=/lustre/file-2GB.dat bs=20M count=100 foi gravado um

arquivo de 2 GB chamado de file-2GB.dat na pasta /lustre do sistema de arquivos LustreFS. O Cacti coletou

paralelamente as informações dessa máquina e as apresentou via página do browser Sea Monkey. Um script

PHP atualiza os dados coletados dinamicamente numa página Web e armazena os dados no banco de dados

MYSQL. A execução do comando ocorreu às 14h05min e terminou às 14h09min. A configuração padrão do

Cacti exibe uma atualização a cada cinco minutos, permitindo uma análise dos eventos ocorridos numa rede.

Para a análise de desempenho do sistema LustreFS utilizou-se as medidas de uso de CPU, uso de

memória e tráfego de rede na placa eth0. Nas Figura 5a, foi reunida a tela com o uso de CPU e as Figuras 5b

e 5c, com o uso de memória e a Figura 6, com o tráfego de entrada e saída da placa eth0.

Figura 5a – Uso de CPU pelo LustreFS

Figura 5b – Uso de Memória pelo LustreFS

Figura 5c – Uso de Memória Cache pelo LustreFS

Em relação ao uso de CPU, Figura 5a, o processo de gravação do arquivo file-2GB.dat, das

14h05min até 14h09min, exigiu um consumo aproximado de 18,12%. O consumo máximo de CPU é o

somatório dos processos do sistema Linux com os processos gerados pelo usuário para gravação do arquivo

citado, assim o consumo de CPU para a cópia foi de 16,00% e para o Sistema Linux 2,12%.

A memória física total da máquina Rgrande é de 3GB. A Figura 5b exibe o consumo da memória

livre que vai diminuindo aos poucos com a gravação do arquivo. No horário de gravação do arquivo, o

consumo médio de memória cache foi de 637,07MB, a Figura 5c exibe a memória cache durante o processo

de gravação do arquivo file-2GB.dat. A memória livre ficou na casa de 1.74GB. Antes da execução do

arquivo, a memória livre em média ficava em 2.0GB.

A Figura 6 apresenta o tráfego de entrada (inbound) e de saída da placa eth0 (outbound). O tráfego

de entrada máximo executado pela interface eth0 correspondeu a 12.56 bits por segundo. Já o tráfego de

saída máximo executado pela interface eth0, correspondeu a 12.57 bits por segundo. Estes valores exibem o

comportamento da placa de rede.

Figura 6 – Tráfego de Entrada e Saída da Placa eth0

4.2 Análise de desempenho do sistema de arquivos HDFS

Com o comando: bin/hadoop dfs -copyFromLocal /opt/file-2GB.dat ~/opt/input/input4, foi feita a

cópia de um arquivo de 2GB no HDFS executada dentro do diretório /usr/local/hadoops/. O execução do

comando ocorreu às 14h20min e terminou perto das 14h26min.

Para a análise de desempenho do sistema HDFS utilizou-se as medidas de uso de CPU, uso de

memória, espaço em disco e o tráfego na placa eth0. Na Figura 7a e 7b, foram reunidas as telas com uso de

CPU e de memória.

O processo de gravação do arquivo file-2GB.dat exigiu do HDFS um consumo máximo de 24,97%

de utilização de CPU, Figura 7a, o sistema Linux consumiu um máximo 2,34% de processamento e os

processos de usuário 22,63%. Comparativamente, o HDFS consumiu mais CPU que o LustreFS, isto ocorre porque o master tem que fazer o controle dos slaves na rede.

Figura 7a – Utilização de CPU e de Uso de Memória pelo HDFS

O uso da memória total da máquina Kaigang era de 3,0GB. A Figura 7b, mostra o consumo de

memória cache de 1,94GB após a gravação do arquivo file-2GB.dat, sendo que a memória livre da máquina

ficou em média num limite aproximado de 255MB. Em comparação com o LustreFS, o HDFS usou um

menor consumo de memória cache. Os processos em execução, como HDFS Cacti, PHP, Apache e SNMP ajudaram a comprometer o desempenho da máquina.

O disco /dev/sda/ que estava montado no servidor Kaigang possuía um espaço total de 160GB. O

comando executou a leitura e gravação dos dados neste disco. Não foi possível exibir a imagem que contém

o espaço usado pela gravação daquele arquivo utilizado pelo HDFS, porque este arquivo de 2GB foi fragmentado em pedaços de 64MB e espalhado pelos servidores da rede de forma homogênea.

A Figura 8 apresenta o tráfego de entrada (inbound) e de saída da placa eth0 (outbound). O tráfego

de entrada máximo executado pela interface eth0 correspondeu a 449,91 bits por segundo. Já o tráfego de

saída máximo executado pela interface eth0, correspondeu a 468,03bps. Estes valores exibem o

comportamento da placa de rede.

Figura 7b – Utilização de Memória pelo HDFS

Figura 8 – Tráfego de Entrada e Saída da Placa eth0

5 CONCLUSÃO E CONSIDERAÇÕES FINAIS

De tudo que foi exposto, pode-se chegar às seguintes conclusões: os dados de desempenho dos

sistemas de arquivos LustreFS e HDFS foram coletados através de uma ferramenta de gerenciamento de

redes, onde foi possível analisar os resultados em dois cenários distintos.

Pelos dados coletados observa-se uma maior utilização de CPU proporcionado pelo HDFS em

comparação com o LustreFS. O motivo disso é que o HDFS é um framework que fica executando diversos

serviços de sincronização com os demais servidores na rede e a manutenção deste controle consome

recursos do servidor mestre, verificado antes mesmo de se iniciar os testes. Ao se iniciar a leitura/gravação

de um arquivo, o HDFS leva tempo aguardando que todos os slaves pertencentes ao seu cluster comecem a

rodar. Isto acontece porque o algoritmo de HDFS verifica a disponibilidade de recursos nos nós slaves

(como tamanho de disco disponível) de forma a manter uma distribuição homogênea destes dados ao longo

dos nós. O Lustre, por sua vez, é tratado como um disco local gerenciado por um servidor de metadados que

permite que os dados sejam acessados com sua autorização.

A análise dos dados aconteceram sobre três ou quatro tipos de testes: uso de CPU, uso de memória e

tráfego de rede na placa eth0. O desempenho do LustreFS em relação ao HDFS foi superior em todos os

aspectos monitorados. Entretanto, o HDFS faz replicações entre seus slaves equivalente a três cópias de

cada segmento do arquivo, portanto uma análise correta deve considerar que uma unidade do HDFS é mais

rápido que o LustreFS, uma vez que o LustreFS não faz replicações.

A contribuição deste projeto poderá auxiliar na busca conhecimento sobre sistemas de arquivos,

sistemas distribuídos, clusters e serviços de redes em Linux.

Para trabalhos futuros, sugere-se uma instalação do LustreFS em cluster heterogêneos onde se tente

recompilar todos os Kernels das máquinas envolvidas, observando quais conseqüências isto poderá trazer

para outros sistemas e programas já instalados no cluster.

AGRADECIMENTO(S)

Com o gosto do dever cumprido, quero agradecer a minha esposa Márcia Nunes dos Santos, por

aguardar com muita ansiedade a tão esperada graduação de seu marido.

Também quero agradecer ao meu orientador Júlio César S. dos Anjos, pelo auxílio e paciência

perante minhas dificuldades neste período de muita determinação.

Ao meu colega Tailor Tonon, que não mediu esforços na busca da graduação.

6 REFERÊNCIAS BIBLIOGRÁFICAS

AGUIAR, César de Souza. Modelo de virtualização distribuída aplicado ao gerenciamento e replicação

de clusters multiuso. São Paulo: UNESP, 2008. Tese (Mestrado em Computação). Universidade Estadual

Paulista Julio de Mesquita Filho, 2008.

COSTA, Felipe. Ambiente de Rede Monitorado com Nagios e Cacti. Rio de Janeiro: Editora Ciência

Moderna Ltda. 2008. 196p.

COULOURIS, George; DOLLIMORE, Jean; KINDBERG, Tim. Sistemas Distribuídos: Conceitos e

Projeto. 4.ed. Porto Alegre: Bookman. 2007. 792p.

DODONOV, Evgueni. Um Mecanismo Integrado de Cache e Prefetching para Sistemas de Entrada e

Saída de Alto Desempenho. São Carlos: UFSCAR, 2004. Tese (Mestrado em Computação). Universidade

Federal de São Carlos, 2004.

GUARDIA, H. C.; SATO, Liria Matsumoto. NPFS: Um Sistema de Arquivos Paralelos em Rede. In:

XVII Simpósio Brasileiro de Redes de Computadores, 1999, Salvador. Anais do XVII Simpósio Brasileiro

de Redes de Computadores, 1999. p.567-568.

HERMANN, Everton. Dinamismo de Servidores de Dados no Sistema de Arquivos dNFSp. Porto

Alegre: UFRGS, 2006. Tese (Mestrado em Computação). Universidade Federal do Rio Grande do Sul, 2006.

KASSICK, Rodrigo Virote. Reconfiguração Automática de I/O para Aplicações Paralelas no Sistema de

Arquivos dNFSp2. Porto Alegre: UFRGS, 2010. Tese (Mestrado em Computação). Universidade Federal do

Rio Grande do Sul, 2010.

KLING-PETERSEN, Torben. Lustre File System: Demo Quick Start Guide. Sun Microsystems.

Disponível em: <https://www.sun.com/offers/details/820-7390.xml/>. Acesso em: 01 jun. 2010.

MACHADO, Francis Berenger; MAIA, xLuiz Paulo. Arquitetura de Sistemas Operacionais. 4.ed. Rio de

Janeiro: LTC. 2007. 308p.

MARIMOTO, Carlos E. Servidores Linux: Guia Prático. Porto Alegre: Sul Editores. 2008. 735p.

OLIVEIRA, Rômulo Silva de; CARISSIMI, Alexandre da Silva; TOSCANI, Simão Sirineo. Sistemas

Operacionais. 4.ed. Porto Alegre: Bookman. 2010. 374p.

PITANGA, Marcos. Construindo Supercomputadores com Linux. 3.ed. Rio de Janeiro: Brasport. 2008.

374p.

SANTOS, Rogério Santanna. Guia de Estruturação e Administração do Ambiente de Cluster e Grid.

Ministério do Planejamento, Orçamento e Gestão. Governo Federal, Brasília. 2006, 454p.

SAWAYA, Márcia Regina. Dicionário de Informática e Internet, Inglês/Português. São Paulo: Livraria

Nobel,1999, 543p.

SCHEPKE, C. et al. Panorama de Ferramentas para Gerenciamento de Clusters. Porto Alegre: Instituto

de Informática, UFRGS, 2005. Universidade Federal do Rio Grande do Sul, 2005.

TANENBAUM, Andrew S. Sistemas Operacionais Modernos. 2.ed. São Paulo: Prentice Hall. 2003. 695p.

TANENBAUM, Andrew S.; STEEN, Maarten V. Sistemas Distribuídos - Princípios e Paradigmas. 2.ed.

São Paulo: Pearson Prentice Hall. 2007. 404p.

TAURION, Cezar. Cloud Computing - Computação em Nuvem - Transformando o Mundo da

Tecnologia da Informação. Rio de Janeiro: Brasport. 2009. 206p.

VERAS, Manoel. Datacenter - Componente Central da Infraestrutura de TI. Rio de Janeiro: Brasport.

2009. 347p.

WHITE, Tom. Hadoop - The Definitive Guide. Sebastopol, California: O'Reilly Media. 2009. 504p.