UNIVERSIDADE FEDERAL DE CAMPINA GRANDE CENTRO DE ENGENHARIA ELÉTRICA E INFORMÁTICA UNIDADE ACADÊMICA DE SISTEMAS E COMPUTAÇÃO. Deployment DO BEEFS

UNIVERSIDADE FEDERAL DE CAMPINA GRANDE CENTRO DE ENGENHARIA ELÉTRICA E INFORMÁTICA UNIDADE ACADÊMICA DE SISTEMAS E COMPUTAÇÃO GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO RELATÓRIO DE ESTÁGIO Deployment DO BEEFS CARLA DE ARAUJO SOUZA ESTAGIÁRIA RAQUEL VIGOLVINO LOPES ORIENTADORA ACADÊMICA JONHNNY WESLLEY SUPERVISOR TÉCNICO CAMPINA GRANDE, PARAÍBA, BRASIL c CARLA DE A. SOUZA, DEZEMBRO DE 2009

2 DEPLOYMENT DO OURFS Aprovado em BANCA EXAMINADORA Prof a. Dr a. Raquel Vigolvino Lopes ORIENTADORA ACADÊMICA Prof. Dr. Francisco Vilar Brasileiro MEMBRO DA BANCA Prof a. Dr a. Joseana Macêdo Fechine MEMBRO DA BANCA

Resumo O deployment de um sistema envolve configurar o software para ser usado num ambiente operacional, instalando o sistema nos computadores e depois configurando essa instanação para esses computadores específicos. Esse é um estagio do processo de desenvolvimento no qual vulnerabilidades podem acidentalmente ser introduzidas por meio de configurações padrões do sistema, por exemplo. Logo, uma boa prática de gerenciamento pode previnir problemas durante o deployment e configuração do sistema. As etapas de configuração e deployment são geralmente atribuídas a administradores de sistemas, as quais estão fora do escopo do processo de engenharia de software. Essa atividade necessita tanto de conhecimento específico quanto de tempo. Para isso, é preciso a participação de uma pessoa com um conhecimento mais profundo para realização do deployment do sistema.

Sumário 1 Introdução 9 1.1 Objetivos...................................... 10 2 Fundamentação Teórica 11 2.1 Sistema de Arquivos................................ 11 2.2 BeeFS........................................ 12 2.3 Definição de pacote................................ 13 2.4 Sistema de gerenciamento de pacotes...................... 14 2.4.1 Objetivos de um sistema de gerenciamento de pacotes........ 14 2.4.2 Advanced Packaging Tool (APT)..................... 15 2.5 Repositórios e Sistemas de Gerenciamento de Pacotes............ 15 2.5.1 Repositório reprepro............................ 16 2.6 Puppet........................................ 16 2.7 Tracers....................................... 17 2.7.1 TraceFS................................... 18 2.7.2 Loggedfs.................................. 18 3 Atividades Realizadas 19 3.1 Monitores de sistema de arquivos........................ 19 3

SUMÁRIO 4 3.1.1 TraceFS................................... 19 3.1.2 LoggedFS.................................. 20 3.1.3 Modificações necessárias......................... 20 3.1.3.1 Problemas identificados..................... 21 3.2 Gerenciamento de pacotes............................ 21 3.2.1 Instalação do repositorio Reprepro.................... 22 3.3 Criação dos pacotes................................ 24 3.3.1 Primeira versão do pacote......................... 24 3.3.1.1 Arquivos de instalação do pacote............... 25 3.3.1.2 Scripts de auxílio à instalação do BeeFS........... 26 3.3.1.3 Instalação............................ 27 3.3.2 Segunda geração do pacote....................... 29 3.3.2.1 Pacote beefs-honeybee................... 31 3.3.2.2 Pacote beefs-common..................... 32 3.3.2.3 Pacote beefs-honeycomb.................. 32 3.3.2.4 Pacote beefs-queenbee................... 33 3.3.2.5 Instalação............................ 33 3.4 Issues e Features identificadas.......................... 34 3.4.1 Bugs..................................... 35 3.4.2 Tasks e Features.............................. 35 3.5 Instalação do Puppet................................ 35 3.5.1 Instalação.................................. 36 3.5.2 Configuração................................ 36 4 Consideração Finais 38

SUMÁRIO 5 A Plano de Estágio i B Scripts x

Lista de Siglas e Abreviaturas APT Advanced Packaging Tool CPAN Comprehensive Perl Archive Network (Rede de Repositórios Perl) EXT3 Third Extended File System EXT4 Fourth Extended File System GPLv2 GNU General Public License Version 2 LFS NFS Linux File System Network File System POSIX Portable Operating System Interface 6

Lista de Figuras 2.1 Arquitetura do BeeFS - ATUALIZAR....................... 13 3.1 Seleção de serviços do BeeFS.......................... 28 3.2 Seleção de serviços do BeeFS.......................... 28 3.3 Servidor BeeFS................................... 29 3.4 Instalação do pacote................................ 30 3.5 Instalação do pacote................................ 30 3.6 Instalação do pacote................................ 31 7

Capítulo 1 Introdução O BeeFS é um sistema de arquivos distribuído para uso corporativo desenvolvido por alunos de graduação e pós-graduação do Laboratório de Sistemas Distribuídos, que tem como propósito utilizar o espaço disponível nas máquinas pertencentes a uma empresa. O BeeFS é capaz de gerar e agregar um storage area de forma muito mais econômica que servidores dedicados de armazenamento. Realizar sua instalação de forma sistemática é essencial para um bom funcionamento do sistema. O deployment de um sistema consiste em uma das etapas finais do desenvolvimento de um sistema, e envolve configurar o software para ser usado num ambiente operacional, instalando-o em computadores e depois configurando essa instalação para esses computadores específicos. Esse é uma etapa do processo de desenvolvimento no qual falhas podem acidentalmente ser introduzidas por meio de configurações, especialmente em sistemas distribuídos. Logo, uma boa prática de gerenciamento pode previnir problemas durante o deployment e configuração de sistema. As etapas de configuração e deployment são geralmente atribuídas a administradores de sistemas, as quais estão fora do escopo do processo de engenharia de software. Essa atividade necessita tanto de conhecimento específico quanto de tempo. Para isso, é preciso a participação de uma pessoa com um conhecimento mais profundo para realização do deployment do sistema. o BeeFS é uma ferramenta que, com o fácil acesso/instalação em qualquer desktop, o sistema é capaz de trabalhar com mais espaço disponível, e permite ao usuário fazer uso 9

1.1 Objetivos 10 deste poder de armazenamento. Um bom deployment permite isto: evitar problemas de configuração, e uma fácil instalação, adaptação ao sistema e atualização do aplicativo. Com o objetivo de realizar o deployment da aplicação, este relatório apresenta as atividades realizadas e está distribuído conforme descrição a seguir: Seção 1 - Seção 2 - Seção 3 - Seção 4 - Introdução Fundamentação Teórica e Tecnologias Utilizadas Atividades Realizadas Considerações Finais Referências Bibliográficas 1.1 Objetivos O principal objetivo desse trabalho é fornecer um apoio especializado ao desenvolvimento do BeeFS, realizando o deployment do sistema e implementando os ambientes necessários para execução das atividades que fazem parte do desenvolvimento do BeeFS. Como objetivos específicos espera-se: Instalar o BeeFS e gerar um relatório de como a instalação ocorreu, relatando a ocorrência de possíveis problemas; Verificar uma forma de testar a perfomance do BeeFS, utilizando um ambiente real de trabalho; Gerar os ambientes necessários para realização do deployment; Realizar pesquisas para possíveis soluções de problemas que venham a aparecer por parte da equipe de desenvolvimento do BeeFS.

Capítulo 2 Fundamentação Teórica Este capítulo possui uma breve introdução sobre alguns softwares utilizados e conceitos abordados no estágio. Primeiro é definido o conceito de sistema de arquivo e uma breve explicação sobre o BeeFS, software o qual deu origem a esse estágio. A gerência de pacotes para ambientes GNU/Linux é descrita em seguida e depois é feita uma introdução aos softwares utilizados no decorrer do estágio. 2.1 Sistema de Arquivos Sistema de arquivos é um um sistema computacional para armazenamento e organização de arquivos de computador e a informação contida neles, de forma que torne fácil de achalos e acessá-los. Sistemas de arquivos podem utilizar um dispositivo de armazenamento como disco rígido ou mídias externas o que envolve a manuntenção da localização física dos arquivos (??). Algumas implementações de sistemas de arquivos provê acesos via rede como no NFS (??) e CODA (??), ou podem ser virtuais e existirem apenas como um método de acesso a informações virtuais, como o procfs (??). Sistema de arquivos tradicionais organiza os dados de forma hierarquica, atribuindo nomes aos arquivos e cada arquivo possui metadados. O nome tem como objetivo permitir a identificação do arquivo pelo usuário. Associado a ele, está a localização dos dados na mídia física ou virtual, de acordo com o sistema de arquivos. Em alguns sistemas de arquivos, os nomes dos arquivos possuem uma sintaxe especial como extensões e número de versões, como o NilFS, um sistema de arquivo estruturado em log no qual dados novos 11

2.2 BeeFS 12 são gravados no início do log enquanto dados antigos ainda existem, tornando possível a recuperação de dados em versões passadas (??). Cada arquivo possui um metadado associado. O tamanho da informação contida no arquivo, a quantidade e localização de blocos alocados para o arquivo, dono, grupo e hora em que foi criado, bem como permissões de acesso são exemplos de informações contida em seu metadata. A maioria das implementações de sistemas de arquivos oferecem facilidade de iteração com a informação armazenada como operações de criação, mover a localização e apagar arquivos e diretórios. 2.2 BeeFS BeeFS é um sistema de arquivo distribuído para uso corporativo que une o espaço disponível em computadores desktop. Por explorar a infraestrutura já existente que encontra-se subutilizada, BeeFS é capaz de construir uma área de armazenamento de uma forma mais economica do que servidores dedicados para tal uso (??). Implementado em Java, uma das principais características do BeeFS é sua escalabilidade: por não possuir uma máquina centralizada que processaria todos as requisições do sistema de arquivo e o espaço agregado pode facilmente ser incrementado por medio da adição de uma nova máquina, desde que o sistema operacional instalado no desktop siga o padrão POSIX, apenas com uma simples instalação do BeeFS. BeeFS é baseado numa arquitura híbrida que mistura características da arquitetura peer-to-peer e client-server. Composto por 3 componentes diferentes, os arquivos e seus metadados são armazenados por componentes separados. Queenbee Este componente é instalado de forma centralizada, com o objetivo de armazenar o metadado dos arquivos e é responsável pelo serviço de naming; Honeycomb Componente de armazenamento de dados, armazena colaborativamente os arquivos nas máquinas pertencentes à rede corporativa. Os dados são replicados entre os Honeycombs instalados na rede para diminuir o impacto de um possível desligamento dos computadores;

2.3 Definição de pacote 13 Honeybee Os dados são acessados e armazenados por meio das máquinas que executam esse componente. Uma instalação típica do BeeFS consistem em apenas uma Queen-bee e vários Honeycombs acessados pelas Honeybees como é mostrado na Figura 2.1. Figura 2.1: Arquitetura do BeeFS - ATUALIZAR 2.3 Definição de pacote Há duas maneiras de se instalar um software no Linux. A primeira é a partir do código fonte, quando uma sequência de três comandos costuma se repetir sempre: $./configure $ make $ sudo make install Esta alternativa é complicada, pois o usuário tem que simular o sistema que o desenvolvedor possuía na sua máquina quando criou o programa, o que inclui compiladores, bibliotecas e, claro, outros softwares do qual o novo depende.

2.4 Sistema de gerenciamento de pacotes 14 A segunda forma consiste em baixar e instalar um pacote, que nada mais é que um arquivo que contém, entre outras coisas: o código fonte pré compilado. Tipicamente, num pacote possui os seguintes arquivos: Bibliotecas; Arquivos de configuração; Páginas de manual; Meta dados, por exemplo: versão do software, descrição, autor; Licença de uso; Lista de mudanças (changelogs) ocorridas do software durante suas versões. Cada pacote possui uma hierarquia de arquivos armazenada de forma compactada. Quando o mesmo é instalado, descompacta-se esta estrutura no sistema de arquivos do sistema operacional, deixando o software pronto para uso. Alguns pacotes ainda dão a opção para o usuário ajustar certas configurações após a instalação. Os gerenciadores de pacotes provem uma interface amigável para as etapas de instalação e atualização. Alguns gerenciadores de pacotes permitem que softwares possam ser instalados clicando-se no instalador do programa - que na verdade executa o gerenciador de pacotes passando os parâmetros para instalar aquele software específico. 2.4 Sistema de gerenciamento de pacotes Um sistema de gerenciamento de pacotes é uma coleção de ferramentas que automatizam o processo de instalação, atualização, configuração e remorção de pacotes de software de um computador. Distribuições de GNU/Linux e outros sistemas operacionais Unix-like tipicamente consiste em centenas ou até milhares de pacotes de software distintos. 2.4.1 Objetivos de um sistema de gerenciamento de pacotes Sistema de gerenciamento de pacotes possuem a responsabilidade de organizar todos os pacotes instalados no sistema e também de manter sua usabilidade. Algumas funções

2.5 Repositórios e Sistemas de Gerenciamento de Pacotes 15 adicionais estão presentes apenas em alguns sistemas de gereciamente de pacotes. Tipicamente são funções de um sistema de gerenciamente de software as seguintes: Verificar arquivos checksums para assegurar coreeture e completure dos pacotes; Verificar assinaturas digitais que autenticam a origem do pacote; Atualizar o software com a ultima versão, tipicamente de um repositório de software; Agrupar pacotes de acordo com função, para melhor entendimento do usuário; Gerenciar dependencias para assegurar que a instalação do pacote é feita juntamente com todos seus requisitos. 2.4.2 Advanced Packaging Tool (APT) O APT foi usado, a princípio, na distribuição Debian e suas derivadas e pode ser definido como uma biblioteca de rotinas que age como um frontend para o dpkg, que é a base do gerenciamento de pacotes no Debian, responsável por instalar, desinstalar e atualizar pacotes.deb. O APT fornece mais funções para o dpkg, dentre as quais se destaca a resolução de dependências. Apesar do APT ter origens no Debian, ser usado com pacotes.deb e se manter fiel a esta linha ao longo do seu período de existência, ele pode ser usado com outros formatos de pacotes e outros sistemas como OpenSolaris, Ubuntu GNU/Linux e OS X (??). 2.5 Repositórios e Sistemas de Gerenciamento de Pacotes Um repositório de software consiste num local de armazenamento do qual pacotes de aplicativos estão disponíveis para download. Várias organizações mantem servidores na internet com este propósito, um serviço disponibilizado de graça e sem necessidade de cadastro. Repositórios podem servir apenas pacotes particulares, ou para um sistema operacional inteiro, como CPAN para a linguagem de programação Perl, como a distribuição GNU/Linux Ubuntu. Como repositórios de software são destinados a incluir pacotes úteis, a maioria dos repositórios são conhecidos como livres de malware. Se um computador é configurado para

2.6 Puppet 16 usar apenas repositórios digitalmente assinados de um fornecedor com boa reputação, isso reduz significamente a infecção do sistema com malwares. Como efeito colateral, a maioria desses sistemas podem permanecer livre de malware mesmo sem a instalação de um programa anti-virus. A maioria das distribuições GNU/Linux possuem espelhos de seus repositórios principais instalados em várias partes do planeta. 2.5.1 Repositório reprepro Reprepro é uma ferramenta para gerar o repositório que armazena pacotes Debian (.dsc,.deb e.udeb). Um repositório APT consiste em 2 partes: um lista descrevendo o que está disponível e onde está o pacote binário Debian (.deb), instalador binário (.deb), e o código fonte (arquivos com extensão.dsc com.tar.gz ou.orig.tar.gz e.diff.gz) para que ferramentas como APT saibam quais os pacotes disponíveis e como obte-los. Reprepro gerencia as versões dos pacotes mantendo apenas a versão mais atual. Os arquivos armazenando-os no Berkley DB 1, logo não é necessário a instalação de sistema de banco de dados. 2.6 Puppet Puppet é um framework voltado para gerenciar de forma eficiente a infraestrutura de um data center. Reduz quantidade de erros de configuração e de downtime, economizando horas de trabalho e provendo uma melhor qualidade de serviço. Puppet permite que administradores de sistemas gaste menos tempo em tarefas técnicas e repetitivas como as atividades administrativas (adicionar usuários, instalar pacotes, atualizar configurações, etc.) independente da quantidade de sistemas, usando o mesmo código, mesmo que as máquinas possuam sistemas operacionais diferentes. Por meio de uma linguagem declarativa, é possível descrever a configuração de sistemas; definir versões e pacotes de softwares que devem ser instalados, atualizados ou removidos; assegurar permissões de arquivos, iniciar serviços; realizar cópias de backup de arquivos; entre outros. Com a utilização do Puppet, a instalação do BeeFS pode ser definida numa máquina 1 Oracle Berkeley DB é um banco de dados embarcado transacional open source que permite aos desenvolvedores incorporar em suas aplicações.

2.7 Tracers 17 centralizada - servidor do Puppet, e o próprio sistema se encarrega de realizar as especificações de instalação nas máquinas desejadas, no nosso caso as máquinas do Laboratório de Sistemas Distribuídos. 2.7 Tracers Traces de arquivos de sistemas tem sido utilizados por anos para analizar o comportamento de usuários e softwares, contribuindo para avanços nas tecnologias de armazenamento e sistemas de arquivos. Geralmente, a captura desses traces é feita de forma específica e com apenas as informações desejadas pelo seu desenvolvedor, que diminui sua reusabilidade: eles perdem informações consideradas vitais para outros usuários usarem e não pode facilmente ser distribuidos por questões legais de privacidade. Outras formas de trace (nível de bloco, nível NFS, nível de chamada de sistema) todos contém uma ou mais deficiências, limitando sua utilidade para estudos mais amplos.(??) Traces de sistemas de arquivos tem sido utilizado no passado para analisar padrões de acesso aos arquivos pelos usuários e performance de software. Estudos utilizando esses logs ajudaram a comunidade a conceber uma melhor manuntenção aos softwares e hardwares em desenvolvimento (??), (??) (??). Além da utilização de traces para estudos de performances (??), existem dois outros usos: analise de segurança do software e debugging. Primeiro, monitoramento de sistema de arquivo é útil para segurança e auditoria. Analise das operações em sistema de arquivos podem ajudar a detectar intrusos a partir da filtragem de acessos por usuários, processos ou programas. Segundo, traces são úteis para debug sistemas de arquivos, auxiliando a localizar possíveis bugs e pontos de falha. Um sistema de arquivo capaz de monitorirar todas operações que são facilmente empilhável em cima de outros sistemas de arquivos são particularmente adequados para realização de depuração pois não requer modificação no sistema de arquivo que deseja-se analisar ou sistema operacional.

2.7 Tracers 18 2.7.1 TraceFS TraceFS é um aplicativo que comporta-se como uma fina camada utilizada para gerar trace de sistemas de arquivo. TraceFS é capaz de ser configura dinamicamente para capturar qualque número de eventos no arquivo de sistema por nome de arquivo ou extensão, dono, grupo, processo, quantos acessos por dia, etc. Distribuído sob a licenca GPLv2, com a linguagem de programação C, as informações capturadas pelo TraceFS são concebidos para ser auto explicativas e eficiente. As utilidades de nível de usuário provem processamento adicional na captura de traces, incluindo expansão ou replicação dos traces por meio do sistema de arquivo, tonando-se um diferencial dentre os softwares de monitoramente de sistema de arquivos. 2.7.2 Loggedfs Loggedfs é um sistema de arquivo baseado em fuse o qual permite gravar toda operação que acontece no backend de um sistema de arquivo. LoggedFS possui um aquivo de configuração XML o qual o usuário pode escolher exatamente o que deseja gravar por meio de filtros de usuários, operações (open, read, write, chown, chmod, etc.), nomes dos arquivos e código de retorno de execução. Os filtros de nomes de arquivos são feitos utilizando expressões regulares. Utilizando a implementação fuse, LoggedFS apenas envia a mensagem para syslog quando chamado pelo fuse e depois permite que o real sistema de arquivo efetue o resto da operação.

Capítulo 3 Atividades Realizadas De acordo com o andamento do estágio, uma atividade não prevista surgiu, que foi a instalação do software Puppet. As outras atividades foram estudar uma forma de obter traces de operações de um sistema de arquivo e a realização do deployment do BeeFS. 3.1 Monitores de sistema de arquivos Uma das formas de realizar uma comparação de desempenho do BeeFS contra outros sistemas de arquivos distribuídos como o NFS, é saber o tempo que leva a execução de uma operação no sistema de arquivo, como gravar ou ler um arquivo. Para tal comparação, a obtenção de um log contendo a duração da operação com o momento que ocorreu e as informações específicas de cada operação era necessário, portanto foi feita uma busca por softwares dessa natureza. Foram analisados dois programas: TraceFS e Loggedfs. 3.1.1 TraceFS Implementado em 2004 utilizando a linguagem de programação C, sua última release foi no dia 12 de outubro de 2007. Desde então o código não sofreu atualizações e as funções utilizadas providas pelo kernel foram modificadas ou removidas, e atualmente não é possível compilar o código do TraceFS. 19

3.1 Monitores de sistema de arquivos 20 Para atender aos requisitos de contabilizar o tempo da execução das operações e seu momento de início, era necessário modificar parte do codigo do TraceFS. Apesar disso, tentativas de modificação foram realizadas, mas sem sucesso. Logo, o uso do TraceFS para monitorar as operações em sistemas de arquivo foi descartado. 3.1.2 LoggedFS Monitorando todas operações em um sistema de arquivo e de fácil instalação, o LoggedFS faz quase o que era desejado. É necessário saber a duração execuções e o momento no qual ocorreu a operação. A implementação do LoggedFS vem sido mantida, o que viabilizou as mudanças necessárias para capturar todas informações necessárias. 3.1.3 Modificações necessárias Toda operação capturada é armazenada contendo: a hora em que ocorreu, a linha do código a qual registrou a operação, o tipo de operação, a pasta onde ocorreu a operação, se a execução foi terminada com sucesso ou falha, seguido do identificador do processo, nome do processo e o usuários que o executou. Para maior detalhes sobre a operação, foi adicionado no código do LoggedFS instruções que registram o timestamp de inicio e fim de cada operação. Com esses valores foi possível calcular o tempo total de operação medido, medido em milisegundos, o qual é gravado no log. Esse log era gerado da seguinte forma: 06:39:25 (src/loggedfs.cpp:155) statfs /local/ {SUCCESS} [ pid = 2990 /usr/sbin/snmpd uid = 115 ] Após a modifição, a mesma operação era armazenada assim: 06:39:25 (src/loggedfs.cpp:155) 1259573965 00000 statfs /local/ {SUCCESS} [ pid = 2990 /usr/sbin/snmpd uid = 115 ]

3.2 Gerenciamento de pacotes 21 Onde a diferença pode ser notada por 2 números adicionais: 1259573965 que representa o timestamp da operação e 00000 que significa a duração da operação, medida em milisegundos. Para uma maior quantidade de log gerado para futura análise, a inicialização do LoggedFS foi modificada para monitorar todos os sistemas de arquivo disponíveis na máquina em que seria instalado. Utilizando os computadores do LSD, os sistemas de arquivos monitorados foram EXT3, EXT4 e NFS. 3.1.3.1 Problemas identificados Por fazer uso tecnologia Fuse, o qual requer permissão de root para sua inicialização, a utilização do LoggedFS para monitorar um sistema de arquivo NFS, foi necessária desativar a flag no_root_squash, o que permite que super usuários remotos possam modificar o sistema de arquivo. A desativação dessa opção não é recomendada por motivos de segurança e privacidade. Logo, a pasta correspondente ao diretório pessoal dos usuários não foi monitorada. Atualmente está em operação em 5 máquinas do Laboratório de Sistemas Distribuídos. Ainda está dando segfault. Continuo em investigação pois o processamento de entrada e saída trava, não permitindo acessar mais os dados. 3.2 Gerenciamento de pacotes O BeeFS possuia uma instalação manual: para sua execução era necessário apenas os atos de descompactar o software, inserir as informações em seu arquivo de configuração e iniciar o serviço. Porém, ao realizar esse procedimento em várias máquinas repetidamente, foi notado que o uso de um gerenciador de pacotes seria muito mais prático e contribuiria com a disseminação o software pela comunidade. Foi pensando nisso que sugeri o uso do gerenciador de pacotes APT para prover o BeeFS à comunidade. O sistema de gerenciamento APT foi escolhido dentre os existentes pois o ambiente no qual se realizaria o deploy, era em sua maioria, eram computadores com o sistema operacional Ubuntu GNU/Linux e Debian GNU/Linux, os quais fazem uso do gerenciador APT.

3.2 Gerenciamento de pacotes 22 Além disso, o APT provê uma gerência de versão de pacotes e resolução de dependências do software, facilitando a realização do deploy da aplicação BeeFS. 3.2.1 Instalação do repositorio Reprepro Para a funcionalidade de repositório, foi utilizado o software reprepro (conhecido também como mirroer) para prover esse serviço. Ele é distribuido com uma licença GPLv2. Além de disponibilizar o pacote, repositórios de softwares são usados usado para prover segurança e confiabilidade para seus usuarios, por possuir assinatura digital, o que garante que os pacotes ali armazenados não estão corrompidos ou adulterados. Futuramente esse repositório será utilizado para distribuir pacotes de instalação de outros sistemas criado, como o OurGrid, constriído pelo LSD. Utilizamos uma máquina com o sistema operacional Debian GNU/Linux instalado para efetuar a instalação do reprepro. Sua instalação foi feita da seguinte forma: apt-get install reprepro De acordo com a LFS (??), a pasta de armazenamento de arquivos mutáveis disponíveis por um servidor HTTP ficam preferencialmente localizados na pasta /var/. Logo, nela criei a pasta onde ficará todo o repositório instalado. O nome da pasta escolhida foi apt, simbolizando que o repositório é apt-able. A pasta foi criada, juntamente com a pasta de configuração que deve ser chamada conf, de acordo com as regras do reprepro. # mkdir -p /var/www/apt # mkdir /var/www/apt/conf A pasta conf deve possuir o arquivo de configuração que define as características do repositório. Esses dados ficam descritos dentro do arquivo chamado distributions, no devem podem ser definidos os seguites parâmetros: Origem Label Suite Apelido

3.2 Gerenciamento de pacotes 23 Arquitetura Componentes Descrição Com essas opções, o arquivo de configuração criado foi: Origin: LSD Label: unstable Suite: unstable Codename: unstable Architectures: i386 source amd64 all Components: main non-free contrib Description: LSD-UFCG Software repository Feito isso, o repositório está instalado e provendo pacotes classificados como unstable. Outras suites de repositórios podem ser adicionadas ao arquivo de configuração, de acordo com a necessidade. No momento existe apenas o unstable pois o pacote BeeFS pertence ao mesmo. Após a instalação do repositório, para armazenar e prover um pacote à comunidade, é necessario populariza-lo com pacotes que deseja-se distribuir. A importação de um pacote pode ser feita da seguinte forma: reprepro includedeb unstable beefs-common_0.1-beta_all.deb Caso o pacote importado exista no repositório, porém a versão seja anterior a que se está adicionando, o pacote é substituido. mensagem de erro. Caso seja a mesma versão, é dada uma A remorção de um pacote do repositório pode ser realizada especificando o nome do pacote e qual suite ele pertence. Utilizando o exemplo da importação do pacote beefscommon, o comando fica: reprepro remove beefs-common unstable Por fim, foi configurado um servidor HTTP (com a instalação do pacote apache2) para prover o acesso ao repositório. Logo, o endereço de uso do repositório é http://packages.lsd.ufcg.edu.br/apt.

3.3 Criação dos pacotes 24 3.3 Criação dos pacotes Para criação do pacote, foi necessário um estudo sobre como é a organização de um pacode Debian (.deb) e realização do mapeamento dos atuais arquivos de instalação do BeeFS com a convenção definida no guia do mantedor de pacotes Debian (??). Toda essa atividade pode ser claramente dividida em 2 fases: primeira e segunda versão de pacote do BeeFS. A primeira versão foi visando um aprimoramento e automização da instalação do BeeFS, e a segunda versão foi uma evolução da versão anterior, com o objetivo de separar os componentes do BeeFS. 3.3.1 Primeira versão do pacote Utilizando a convenção definida pela LFS (??) os arquivos presentes no software BeeFS foram relocalizados e sua organização de arquivos ficou da seguinte forma: a pasta /etc possui os arquivos de configuração necessários para a inicalização do BeeFS. Na pasta /usr/lib/beefs, está armazenado as bibliotecas e a implementação do BeeFS. Em /usr/sbin/ existe links simbólicos para os executáveis do software. No diretório /var/lib/beefs é armazenado os arquivos criados pelo BeeFS, que corresponde a informações sobre os arquivos armazenados e sobre seus metadados. Por fim, os logs gerados são armazenados na pasta /var/log/beefs. / -- etc -- init.d -- beefs -- beefs -- environment.sh -- log4j.properties -- services.info -- services.ini -- usr -- lib -- beefs -- commons-logging-1.0.4.jar -- ddg-commons-0.1-beta.jar -- ddg-communication-0.1-beta.jar -- ddg-distributed-storage-0.1-beta.jar -- ddg-filesystem-0.1-beta.jar -- ddg-fuse-0.1-beta.jar -- ddg-objectstorage-device-0.1-beta.jar -- ddg-services-0.1-beta.jar -- ddg-xsocket-communication-0.1-beta.jar

3.3 Criação dos pacotes 25 -- fuse-j-2.4.jar -- jdbm-1.0b.jar -- jsch-0.1.31.jar -- log4j-1.2.14.jar -- native -- libjavafs.so -- perf4j-0.9.10.jar -- plexus-utils-1.5.6.jar -- slf4j-api-1.5.2.jar -- slf4j-log4j12-1.5.2.jar -- xsocket-2.4.2.jar -- sbin -- ddg ->../share/beefs/ddg -- ddg-config.sh ->../share/beefs/ddg-config.sh -- ddg.bat ->../share/beefs/ddg.bat -- java-config.sh ->../share/beefs/java-config.sh -- mount.ddg ->../share/beefs/mount.ddg -- share -- beefs -- ddg -- ddg-config.sh -- ddg.bat -- java-config.sh -- mount.ddg -- var -- lib -- beefs -- ObjectStorageDevice.db -- ObjectStorageDevice.lg -- log -- beefs -- ddg.log 3.3.1.1 Arquivos de instalação do pacote Num pacote Debian, existem arquivos que identificam e realizão operações adicionais de instalação, como parar o serviço antes de uma inicialização ou mudar permissões e usuários de arquivos do software. Esses arquivos seguem a convenção descrita no Guia do Novo Mantenedor Debian (??) que são: conffiles Arquivo que contem a lista de arquivos de configuração do software; control Arquivo contendo a descrição do pacote; copyright Licença de distribuição do BeeFS; debian-binary Contem a versão do pacote (2.0); postinst Script executado após a extração do pacote;

3.3 Criação dos pacotes 26 preinst Script executado antes da extração do pacote; postrm Script executado após a remorção do pacote; prerm Script executado antes da remorção do pacote; templates Arquivo contendo as perguntas e opções utilizadas na iteratividade com o usuário durante a pós instalação do pacote. Dentre esses arquivos, o único o qual a existencia é obrigatória é o arquivo control. Ele define uma descrição completa sobre o pacote para que o repositório no qual ele está armazenado, tenha conhecimento de seu nome e versão, entre outras informações. No pacote construído do BeeFS, o conteúdo do arquivo control é: Package: beefs Priority: optional Version: 0.002 Architecture: all Installed-size: 2252 Maintainer: Jonhnny Weslley, Manel and Gonzaga Section: utils Depends: fuse-utils (>=2.7), libfuse2 (>=2.7), sun-java6-jre (>=6) openjdk-6-jre (>=6), debconf (>= 0.5) debconf-2.0 Homepage: http://lsd.ufcg.edu.br/beefs Description: A distribuited filesystem for corporative use BeeFS is a distributed file system for corporative use that harnesses the free disk space of desktops machines (already deployed on the corporation). By exploiting the computational underutilized infrastructure, BeeFS can build an aggregate storage area in a much more economic fashion than the prevalent dedicated servers approach. Furthermore, increases on service s demand (frequently caused by arrival of new corporative users) can be handled on a more precise way, by adding a single desktop (usually a new user comes together a new desktop). Esse arquivo contém, em sequência, o nome do pacote, prioridade, versão, arquitetura, espaço ocupado medido em KB após a instalação, mantenedores do software, sessão relacionada para armazenamento no repositório, software necessários para instalação do pacote, homepage do programa e descrição. 3.3.1.2 Scripts de auxílio à instalação do BeeFS O pacote BeeFS possui quatro scripts que são utilizandos em sua instalação.

3.3 Criação dos pacotes 27 postinst Script executado após a extração do pacote. Ele possui a responsabilidade iteragir com o usuário com perguntas sobre a configuração do software. Após receber todas as informações, é adicionado o usuário beefs, caso não existe; é feita uma checagem da existência dos diretórios informados e permissões dos arquivos de configuração. Por fim, esse script inicializa o BeeFS; preinst Script executado antes da extração do pacote. Caso esteja atualizando uma instalação já existente no sistema, esse script é responsável por parar o serviço antes da atualização dos arquivos do BeeFS; postrm Script executado após a remorção do pacote caso a opção de remorção for purge, que elimina todos os arquivos do software, dessa forma, todos os arquivos criados como os dados brutos e arquivos de metadados são removidos. Numa simples deconfiguração, esse script não apaga os arquivos citados acima; prerm Script executado antes da remorção do pacote. Possui a responsabilidade de parar o serviço antes da deconfiguração ou purge. A implementação dos scripts postinst, preinst, postrm e prerm podem ser analisados no Anexo A. 3.3.1.3 Instalação A instalação é feita de forma iterativa, questionando o usuário para inserir as informações básicas de configuração para funcionamento pleno do BeeFS. No inicio da configuração, é questionado quais os serviços que o usuário gostaria de instalar exibindo a tela mostrada na Figura 3.1. Os serviços disponíveis eram: Server, contendo o componente Queenbee, e Client que contem os componentes Honeycomb e Honeybee. O usuário pode escolher apenas uma opção ou ambas. Se foi escolhido apenas a opção Server, a iteratividade é finalizada e o pacote é configurado para tal serviço. Caso contrário, após essa pergunta, se a opção escolhida seja apenas Client, é perguntado qual o IP ou nome do servidor no qual está instalado o componente Queenbee do BeeFS como é ilustrado na Figura 3.3. Caso ambas as opções

3.3 Criação dos pacotes 28 Figura 3.1: Seleção de serviços do BeeFS Figura 3.2: Seleção de serviços do BeeFS

3.3 Criação dos pacotes 29 foram escolhidas, assume-se automaticamente que a localização do componente Queenbee é localhost, e segue-se a configuração exibindo a próxima pergunta. Figura 3.3: Servidor BeeFS 3.3.2 Segunda geração do pacote Como o foco do uso do software é para várias máquinas, a instalação de forma iterativa como feita anteriormente dificultava a escalabilidade da instalação. Logo, modificou-se a etapa de instalação e e o que antes era apenas um pacote, foi divido em 4 pacotes: beefs-common Possui todos os arquivos comuns aos componentes do BeeFS: as bibliotecas - localizados no diretório /var/lib/beefs e o arquivo de ajuda (man page), localizado na pasta /usr/share; beefs-honeybee Esse pacote possui uma biblioteca específica para uso por sistema de arquivos implementados em java, o arquivo de configuração /etc/beefs/honeybee.conf e o executável de inicalização - localizado em /etc/init.d; beefs-honeycomb Esse componente possui o diretório que teá os metadados dos arquivos armazenados na máquina (/var/lib/beefs/), a pasta de de conterá os logs, o arquivo de configuração honeycomb.conf e o executável de inicalização;

3.3 Criação dos pacotes 30 Figura 3.4: Instalação do pacote Figura 3.5: Instalação do pacote

3.3 Criação dos pacotes 31 Figura 3.6: Instalação do pacote beefs-queenbee Seu conteúdo é similar ao pacote beefs-honeycomb, mudando apenas o arquivo de configuração, que neste caso é o queenbee.conf. A seguir é detalhado a organização hierárquica dos pacotes quando instalados no sistema. 3.3.2.1 Pacote beefs-honeybee / -- etc -- init.d -- beefs -- beefs -- honeybee.conf -- usr -- lib -- beefs -- native -- libjavafs.so -- sbin -- mount.ourfs -> /usr/share/ourfs/mount.ourfs -- ourfs -> /usr/share/ourfs/ourfs -- ourfs-config.sh -> /usr/share/ourfs/ourfs-config.sh -- ourfs.bat -> /usr/share/ourfs/ourfs.bat -- var -- log -- beefs

3.3 Criação dos pacotes 32 3.3.2.2 Pacote beefs-common / -- etc -- default -- beefs -- environment.sh -- log4j.properties -- service_manager.conf -- services.info -- usr -- lib -- beefs -- commons-logging-1.0.4.jar -- ddg-commons-0.1-beta-build20091123-1250.jar -- ddg-commons-0.1-beta.jar -- ddg-communication-0.1-beta.jar -- ddg-distributed-storage-0.1-beta-build20091123-1250.jar -- ddg-distributed-storage-0.1-beta.jar -- ddg-filesystem-0.1-beta-build20091123-1250.jar -- ddg-filesystem-0.1-beta.jar -- ddg-fuse-0.1-beta-build20091123-1250.jar -- ddg-fuse-0.1-beta.jar -- ddg-objectstorage-device-0.1-beta-build20091123-1250.jar -- ddg-objectstorage-device-0.1-beta.jar -- ddg-services-0.1-beta-build20091123-1250.jar -- ddg-services-0.1-beta.jar -- ddg-xsocket-communication-0.1-beta-build20091123-1250.jar -- ddg-xsocket-communication-0.1-beta.jar -- fuse-j-2.4.jar -- jdbm-1.0b.jar -- jsch-0.1.31.jar -- junit-4.4.jar -- log4j-1.2.14.jar -- perf4j-0.9.10.jar -- plexus-utils-1.5.6.jar -- slf4j-api-1.5.2.jar -- slf4j-log4j12-1.5.2.jar -- xsocket-2.4.2.jar -- share -- man -- man1 -- beefs.1.gz -- beefs -- mount.beefs -- beefs -- beefs-config.sh -- beefs.bat 3.3.2.3 Pacote beefs-honeycomb / -- etc -- init.d -- beefs -- beefs

3.3 Criação dos pacotes 33 -- honeycomb.conf -- usr -- sbin -- mount.ourfs -> /usr/share/ourfs/mount.ourfs -- ourfs -> /usr/share/ourfs/ourfs -- ourfs-config.sh -> /usr/share/ourfs/ourfs-config.sh -- ourfs.bat -> /usr/share/ourfs/ourfs.bat -- var -- lib -- beefs -- data -- log -- beefs 3.3.2.4 Pacote beefs-queenbee / -- etc -- init.d -- beefs -- beefs -- queenbee.conf -- usr -- sbin -- mount.ourfs -> /usr/share/ourfs/mount.ourfs -- ourfs -> /usr/share/ourfs/ourfs -- ourfs-config.sh -> /usr/share/ourfs/ourfs-config.sh -- ourfs.bat -> /usr/share/ourfs/ourfs.bat -- var -- lib -- beefs -- data -- log -- beefs 3.3.2.5 Instalação A instalação é feita executando os seguintes passos: 1. Adiciona-se o repositório do LSD em /etc/apt/source.lst, sudo echo deb http://packages.lsd.ufcg.edu.br/apt unstable main >> /etc/apt/source.lst 2. Após, atualiza-se a lista de pacotes para instalar a versão mais atualizada disponível. apt-get update A partir daí, pode-se instalar o(s) componente(s) do BeeFS desejado(s).

3.4 Issues e Features identificadas 34 3. A instalação pode ser feita com o seguinte comando para os componentes Queenbee, Honeycomb e Honeybee, respectivamente: apt-get install beefs-queenbee apt-get install beefs-honeycomb apt-get install beefs-honeybee Terminado esses passos, o BeeFS está instalado, porém deve-se configurá-lo. Para realizar a configuração, deve-se seguir a seguinte sequência de passos: Configuração do componente Queenbee 1. Configuração do componente Honeycomb 1. Configuração do componente Honeybee 1. A inicalização do BeeFS pode ser feita assim: invoke-rc.d beefs start Que inicializará todos os componentes do BeeFS, ou separadamente com os comandos: beefs start queenbee beefs start honeycomb beefs start honeybee O BeeFS deve ser inicializado com o usuário beefs criado durante a instalação. 3.4 Issues e Features identificadas Com a execução das atividades descritas acima, foi necessária algumas modificações no código do BeeFS bem como a identificação de alguns bugs. Features também foram sugeridas para suprir a.

3.5 Instalação do Puppet 35 3.4.1 Bugs 320 Bug New Urgent Metadataserver doesn t startup Carla Souza Jonhnny Silva Beta 0.1 299 Bug Closed High ClientContext must not be null Carla Souza Jonhnny Silva Beta 0.1 235 Bug Closed Normal Wrong amount of used space Carla Souza Jonhnny Silva Beta 0.1 183 Bug Closed High Mount point usage Carla Souza Jonhnny Silva Beta 0.1 178 Bug Closed High Permissions Carla Souza Jonhnny Silva Beta 0.1 175 Bug Closed High Mount point size Carla Souza Jonhnny Silva Beta 0.1 3.4.2 Tasks e Features Eu, minha pessoa, propus as seguites modificações no codigo: 211 Feature New Normal "Leave"option Carla Souza Jonhnny Silva Beta 0.2 208 Task Closed Normal Exceptions Carla Souza Jonhnny Silva Beta 0.1 182 Feature New Normal Links./ and../ Carla Souza Jonhnny Silva 179 Task Closed Normal Change beefs port to 7790-7793 Carla Souza Jonhnny Silva Beta 0.1 176 Task Closed Normal Data directory Carla Souza Jonhnny Silva Beta 0.1 3.5 Instalação do Puppet Para melhor escalabilidade da instalação e manuntenção do BeeFS nas máquinas do LSD, a ferramenta de gerência de configuração Puppet foi utilizada. Com ela, é possível centralizar a configuração do BeeFS, e o puppet se encarrega de instalar, checar se está em execução e se a configuração está adequada de acordou com o que é especificado em seu arquivo de configuração. O arquivo de configuração consiste numa linguagem de programação declarativa no qual especifica-se as exigências de cada operação.

3.5 Instalação do Puppet 36 O Puppet é divido em dois pacotes: puppetmaster Servidor do serviço de gerência do Puppet; puppet Cliente instalado nas máquinas desktops. 3.5.1 Instalação Para instalação do puppetmaster, foi usado o mesmo servidor onde se encontra instalado o componente QueenBee do BeeFS. A instalação foi feita com o comando: # apt-get install puppetmaster Nas máquinas clientes foi instalado o pacote puppet. # apt-get install puppet 3.5.2 Configuração Para servir a configuração do BeeFS, no servidor foram criados no diretório /etc/puppet/manifests/classes/ os arquivos beefs.pp e lsdrepository.pp, os quais possuem a especificação da instalação do BeeFS e do repositório no qual está hospedado, respectivamente. site.pp Define quais máquinas devem executar oq # /etc/puppet/manifests/site.pp import "classes/*" node basenode { include lsdrepository } node leao.lsd.ufcg.edu.br, nuvem.lsd.ufcg.edu.br inherits basenode { include beefs-honeycomb } node gato.lsd.ufcg.edu.br inherits basenode { include beefs-honeybee }

3.5 Instalação do Puppet 37 beefs.pp Possui a definição das classes que declara os pacotes que as máquinas devem possuir instalados; class beefs { user {"beefs": ensure => present} } #BeeFS Honeybee Instalation class beefs-honeybee inherits beefs { package { "beefs-honeybee": ensure => present } } #BeeFS Honeycomb Instalation class beefs-honeycomb inherits beefs { package { "beefs-honeycomb": ensure => present } } lsdrepository.pp Adiciona o repositório de pacotes do LSD na lista de repositórios da máquina. Os passos de execução são os seguintes: 1. Verifica se o repositório do LSD está presente em sua lista de repositórios. 2. Caso ausente, adiciona a linha ao repositório class lsdrepository { define line($file, $line, $ensure = present ) { case $ensure { default : { err ( "unknown ensure value ${ensure}" ) } present: { exec { "/bin/echo ${line} >> ${file} ": unless => "/bin/grep -qfx ${line} ${file} " } } absent: { exec { "/usr/bin/perl -ni -e print unless /^\\Q${line}\\E\$/ onlyif => "/bin/grep -qfx ${line} ${file} " } } } } } line { lsdrepository: file => "/etc/apt/sources.list", line => "deb http://packages.lsd.ufcg.edu.br/apt unstable main", ensure => present }

Capítulo 4 Consideração Finais Esse estagio foi importante por que blablabla Tive como dificuldades ter que trabalhar com uma linguagem de programação que eu não conhecia e blablabla. Isso foi bom pois ganhei conhecimento e tals Atualmente existem 30 maquians, e conseguimos ate 1.3T de espaço disponível 38

Referências Bibliográficas Automating UNIX and Linux Administration. Apress, 2003. BeeFS. http://www.lsd.ufcg.edu.br/beefs, Novembro 2009. Debian Policy Manual - Chapter 9 - The Operating System. http://www.debian.org/ doc/debian-policy/ch-opersys.html/, Setembro 2009. A. Aranya, C. P. Wright, and E. Zadok. Tracefs: A file system to trace them all. In Proceedings of the Third USENIX Conference on File and Storage Technologies (FAST 2004), pages 129 143, San Francisco, CA, March/April 2004. USENIX Association. Andrew S. Tanenbaum. Modern Operating Systems. Prentice Hall PTR, Upper Saddle River, NJ, USA, 2001. 39

Apêndice A Plano de Estágio i

UNIVERSIDADE FEDERAL DE CAMPINA GRANDE - UFCG CENTRO DE ENGENHARIA ELÉTRICA E INFORMÁTICA - CEEI DEPARTAMENTO DE SISTEMAS E COMPUTAÇÃO - DSC PLANO DE ESTÁGIO Suporte ao DDGfs Experimentos e ambientação Carla de Araújo Souza Curso de Bacharelado em Ciência da Computação Campina Grande, Agosto de 2009 ii

1 Informações Pessoais Nome: Carla de Araújo Souza Matrícula: 20421009 Endereço Residencial: Rua Paulo de Frontin, 382 / ap 203 - Catolé - Campina Grande - PB Endereço Profissional: Av. Aprígio Veloso, 882 Bodocongó, Bloco CO 58109-970, Campina Grande, PB Fone: +55 (83) 3310 1640, (83) 8834 5645 Fax: +55 (83) 3310 1498 E-mail: carla [AT] lsd.ufcg.edu.br 2 iii

2 Ambiente de Estágio O estágio será realizado no Laboratório de Sistemas Distribuídos (LSD) do Departamento de Sistemas e Computação (DSC) da Universidade Federal de Campina Grande. Criado em 1996, surgiu como forma de juntar alunos, professores e pesquisadores do DSC e de outros departamentos para trabalhar em projetos na área de Sistemas Distribuídos. Coordenado atualmente pelo professor Francisco Brasileiro, as pesquisas que ali ocorrem atuam na área de Cloud Computing, Sistemas Multi-Agentes, Grades Computacionais, Sistemas Peer-to-Peer, Tolerância a Falhas, Sistemas de armazenamento distribuído e Aplicações Industriais. 2.1 Estrutura Física A infraestrutura do Laboratório de Sistemas Distribuídos possui auditório informatizado, biblioteca dotada de livros de várias áreas da computação e 8 salas equipadas com quadro branco, condicionador de ar e postos de trabalho individuais com computador conectado à Internet de alta velocidade. Ambiente agradável e totalmente informatizado, o LSD está instalado num prédio onde dezenas de alunos de gradução, mestrado e doutorado trabalham em projetos de pesquisa e desenvolvimento. Endereço: Universidade Federal de Campina Grande Departamento de Sistemas e Computação Laboratório de Sistemas Distribuídos Av. Aprígio Veloso, 882 - Bloco CO Bodocongó, CEP 58109-970 Campina Grande - PB, Brasil Fone: +55 83 3310 1365 Fax: +55 83 3310 1498 3 iv

3 Supervisão (Acadêmica e Técnica) A supervisão acadêmica será efetuada pela professora Raquel Vigolvino Lopes, pesquisadora do Laboratório de Sistemas Distribuídos (LSD) e professora do DSC/UFCG. A supervisão técnica será efetuada pelo aluno de mestrado Jonhnny Weslley. Dados do supervisor acadêmico Nome: Raquel Vigolvino Lopes Endereço Profissional: Av. Aprígio Veloso, 882 Bodocongó, Bloco CO 58109-970, Campina Grande, PB Fone: +55 (83) 3310 1643 Fax: +55 (83) 3310 1498 E-mail: raquel [AT] dsc.ufcg.edu.br Dados do supervisor técnico Nome: Jonhnny Weslley Endereço Profissional: Av. Aprígio Veloso, 882 Bodocongó, Bloco CO 58109-970, Campina Grande, PB Fone: +55 (83) 3310 1565 E-mail: jonhnny [AT] lsd.ufcg.edu.br 4 v

4 Resumo do Problema O DDGfs, Distributed Data Grid filesystem, é um sistema de arquivos distribuído para uso corporativo desenvolvido por alunos de graduação e pós-graduação do Laboratório de Sistemas Distribuídos, que tem como propósito utilizar o espaço disponível nas máquinas pertencentes a uma empresa. O DDGfs é capaz de gerar e agregar um storage area de forma muito mais econômica que servidores dedicados de armazenamento. O desenvolvimento de um sistema de arquivos distribuído requer uma configuração do ambiente no qual ele será instalado para fornecer o serviço de armazenamento distribuído, e essa atividade necessita tanto de conhecimento específico quanto de tempo. Para isso, é preciso a participação de uma pessoa com um conhecimento mais profundo para auxiliar no deployment do software. O DDGfs deve ser capaz de ser utilizado em ambientes com intensivo acesso aos dados. O armazenamento desses dados deve ser feita de forma confiável, e para isso, o DDGfs deve ser testado e usado em diferentes ambientes para avaliação de desempenho, detecção de possíveis problemas, e até mesmo preceber a necessidade de novas features. 5 Objetivos O principal objetivo desse trabalho é fornecer um apoio especializado ao desenvolvimento do DDGfs, realizando o deployment do sistema e implementando os ambientes necessários para execução das atividades que fazem parte do desenvolvimento do DDGfs. Como objetivos específicos espera-se: Instalar o DDGfs e gerar um relatório de como a instalação ocorreu, relatando a ocorrência de possíveis problemas; Verificar uma forma de testar a perfomance do DDGfs, utilizando um ambiente real de trabalho; Gerar os ambientes necessários para realização do deployment; Realizar pesquisas para possíveis soluções de problemas que venham a aparecer. 5 vi