Análise de desempenho entre os sistemas de arquivos HDFS e

ANÁLISE DE DESEMPENHO ENTRE OS
SISTEMAS DE ARQUIVOS HDFS E LUSTREFS1
Marcos Fagundes Vieira <[email protected]>
Orientador: Júlio César S. dos Anjos <[email protected]>
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 [email protected] ou ssh root@feliz ou
ainda ssh feliz.
Linux Ubuntu Generic x86
- versão 8.10
CLUSTER HPC
eth0
Linux Ubuntu Generic x86
- versão 8.10
eth0
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
Linux Ubuntu Server 64bits
- versão 8.10
Switch D-Link-1016D
18 Portas
eth0
Linux Ubuntu Generic x86
- versão 8.10
eth0
eth1
Switch 3.com
24 Portas
Linux Ubuntu Generic x86
- versão 8.10
eth0
RedHat Enterprise Linux
Server 5.5
Internet
eth0
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
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 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
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
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 incluiuse 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/stopdfs.sh. Já o MapReduce, é executado através do bin/start-mapred.sh e encerrado com o bin/stopmapred.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.
HDFS, LustreFS e
Ferramenta CACTI
Linux Ubuntu Generic x86
- versão 8.10
eth0
Linux Ubuntu Generic x86
- versão 8.10
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
CACTI no KAIGANG
Data Base MySQL
Web Server Apache
Script PHP
SNMP Agent
Benchmark CACTI
SEA MONKEY
Ferramenta RRDTool
eth0
Linux Ubuntu Server 64bits
- versão 8.10
Switch D-Link-1016D
18 Portas
eth0
Linux Ubuntu Generic x86
- versão 8.10
eth0
eth1
Switch 3.com
24 Portas
Linux Ubuntu Generic x86
- versão 8.10
eth0
(Cacti também foi
instalado na máquina
Rgrande)
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
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 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
RedHat Enterprise Linux
Server 5.5
Internet
eth0
SLAVE 6 - RGRANDE
IP: 172.16.1.18 (eth0)
Login: Root
Password: ht4gt4rs
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
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.