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

Transcrição

1 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

3 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

4

5 Resumo O deployment de um sistema computacional envolve configurá-lo para ser usado num ambiente operacional, e essa etapa deve ser feita de forma sistemática, especialmente em sistemas computacionais distribuídos. O BeeFS é um sistema de arquivos distribuído, cujo as atividades de deployment foram realizadas durante esse estágio. Essas atividades foram: criação de pacotes de instalação do BeeFS, instalação de um repositório de pacotes e a instalação do gerenciador de configuração Puppet. Como resultado foram identificados 6 bugs, 3 tasks e 2 features foram sugeridas. Além do deployment, para uma comparação de performance em relação a outros sistemas de arquivos, foi necessário a modificação de um software que monitora e registra as operações em sistemas de arquivos, adicionando a duração e o momento no qual ocorreram.

6

7 Sumário 1 Introdução Objetivos Fundamentação Teórica Sistema de Arquivos BeeFS Sistemas de gerenciamento de pacotes Objetivos de um sistema de gerenciamento de pacotes Definição de pacote Advanced Packaging Tool (APT) Repositórios e Sistemas de Gerenciamento de Pacotes Repositório Reprepro Gerenciamento de configuração Puppet Tracers Atividades Realizadas Monitores de sistema de arquivos TraceFS

8 SUMÁRIO LoggedFS Modificações necessárias Problemas identificados Gerenciamento de pacotes Instalação do repositorio Reprepro Criação dos pacotes Primeira versão do pacote Arquivos de instalação do pacote Scripts de auxílio à instalação do BeeFS Instalação Segunda versão do pacote Pacote beefs-honeybee Pacote beefs-common Pacote beefs-honeycomb Pacote beefs-queenbee Instalação Tasks, Features e Bugs identificadas Bugs Tasks e Features Instalação do Puppet Instalação Configuração Consideração Finais Atividades futuras

9 SUMÁRIO 5 A Plano de Estágio i B Scripts x B.1 Postinst x B.2 Preinst xiv B.3 Postrm xv B.4 Prerm xvi

10 Lista de Siglas e Abreviaturas APT Advanced Packaging Tool CPAN Comprehensive Perl Archive Network (Rede de Repositórios Perl) EELA E-science grid facility for Europe and Latin America EXT3 Third Extended File System EXT4 Fourth Extended File System GPLv2 GNU General Public License Version 2 IANA LFS LSD NFS Internet Assigned Numbers Authority Linux File System Laboratório de Sistemas Distribuídos Network File System POSIX Portable Operating System Interface YUM Yellowdog Updater, Modified 6

11 Lista de Figuras 2.1 Arquitetura do BeeFS Seleção de serviços do BeeFS Seleção de serviços do BeeFS Tela para inserir o IP ou nome do servidor BeeFS Tela para inserir a quantidade de espaço que deseja compartilhar Tela para inserir a pasta que armazenará os arquivos brutos Tela para inserir o diretório que montará o BeeFS

12

13 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 (5), que tem como propósito utilizar o espaço não utilizado das máquinas pertencentes a uma empresa para criar um espaço de armazenamento distribuído. Por exemplo, com a centralização dos arquivos pessoais dos funcionários de uma empresa usando NFS, o espaço que esses arquivos ocuparia nas máquinas dos funcionários torna-se subutilizado. O BeeFS é capaz de agregar um espaço de armazenamento de forma muito mais econômica que servidores dedicados de armazenamento. Por ser um sistema distribuído, a realização de 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 (15), 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. Nessa etapa do processo de desenvolvimento, falhas podem acidentalmente ser introduzidas por meio de configurações, especialmente em sistemas distribuídos. Logo, boas práticas de gerenciamento podem 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. Essa atividade demanda tanto conhecimento específico quanto tempo. Para isso, é preciso a participação de uma pessoa com um conhecimento mais profundo para realização do deployment do sistema. 9

14 1.1 Objetivos 10 Um bom deployment evite problemas de configuração e permite uma fácil instalação, adaptação ao sistema e atualização do aplicativo. 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 deste poder de armazenamento. Com o objetivo de realizar o deployment da aplicação, este relatório está divido nas seções em Fundamentação teórica e Tecnologias Utilizadas, com conceitos e softwares durante o estágio, Atividades realizadas, descrevendo todas as atividades desenvolvidas e finalmente as considerações finais. 1.1 Objetivos Realizando o deployment do sistema e configurando os ambientes necessários para execução das atividades que fazem parte do desenvolvimento do BeeFS, o principal objetivo desse trabalho é fornecer um apoio especializado ao desenvolvimento do BeeFS. Como objetivos específicos espera-se: Instalar o BeeFS e gerar um relatório da atividade de instalação, relatando a ocorrência de possíveis problemas; Analisar métodos para realização de tesets de performance, utilizando um ambiente real de trabalho; Configurar 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.

15 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 finalmente é feita uma introdução aos programas utilizados no decorrer do estágio. 2.1 Sistema de Arquivos Sistema de arquivos é 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 achá-los 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 (16). Algumas implementações de sistemas de arquivos provê acessos via rede como no NFS (6) e CODA (2), ou podem ser virtuais e existirem apenas como um método de acesso a informações virtuais, como o procfs (14). Sistemas de arquivos tradicionais organizam 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, bem como 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 são gravados no 11

16 2.2 BeeFS 12 início do log enquanto dados antigos ainda existem, tornando possível a recuperação de dados em versões passadas (12). Cada arquivo possui um metadado associado. O tamanho da informação contida no arquivo, a quantidade e a localização de blocos alocados para o arquivo, dono, grupo e tempo de criação, bem como permissões de acesso são exemplos de informações contida em seu metadados. 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 econômica do que servidores dedicados para tal uso (1). 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 arquivos e o espaço agregado pode facilmente ser incrementado por meio da adição de novas máquina, desde que o sistema operacional instalado no desktop implemente a interface POSIX. BeeFS é baseado numa arquitura híbrida que mistura características das arquiteturas ponto-a-ponto e cliente-servidor. Composto por 3 componentes distintos, os arquivos e seus metadados são armazenados por componentes separados. QueenBee Este componente é instalado de forma centralizada, com o objetivo de armazenar os metadados dos arquivos e é responsável pelo serviço persistência dos metadados e localização dos arquivos; HoneyComb Componente de armazenamento dos dados que 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;

17 2.3 Sistemas de gerenciamento de pacotes 13 HoneyBee Esse componente disponibiliza o acesso aos arquivos armazenados no sistema de arquivos BeeFS. Uma instalação típica do BeeFS consiste em apenas uma QueenBee e vários Honey- Combs acessados pelas HoneyBees como é mostrado na Figura 2.1. Figura 2.1: Arquitetura do BeeFS 2.3 Sistemas 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 remoção de pacotes de software de um computador. Distribuições de GNU/Linux e outros sistemas operacionais Unix-like tipicamente consistem em centenas ou até milhares de pacotes de software distintos Objetivos de um sistema de gerenciamento de pacotes Sistemas 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 adicionais estão presentes apenas em alguns sistemas de gereciamente de pacotes. Tipicamente, as funções de um sistema de gerenciamente de softwares são:

18 2.3 Sistemas de gerenciamento de pacotes 14 Agrupar pacotes de acordo com a função, para melhor entendimento do usuário; Verificar arquivos checksums para assegurar corretude e completude dos pacotes; Verificar assinaturas digitais que autenticam a origem do pacote; Atualizar o software com a última versão, geralmente disponível por meio de um repositório de software; Gerenciar dependências para assegurar que a instalação do pacote é feita juntamente com todos os requisitos 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, geralmente, outros softwares do qual o novo depende. 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 compilado. Tipicamente, um pacote possui os seguintes tipos de arquivos: Bibliotecas; Arquivos de configuração; Páginas de manual; Metadados, por exemplo: versão do software, descrição, autor; Licença de uso;

19 2.4 Repositórios e Sistemas de Gerenciamento de Pacotes 15 Histórico de mudanças (changelogs) ocorridas do software. 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, tornando-se pronto para uso. Alguns pacotes permitem que o usuário ajuste certas configurações após a instalação de forma iterativa. Os gerenciadores de pacotes provem uma interface amigável para as etapas de instalação, atualização e remorçã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 Advanced Packaging Tool (APT) O APT foi usado, a princípio, na distribuição Debian e suas derivadas. Pode ser definido como uma biblioteca de rotinas que age como uma interface de iteração com o dpkg, software que é a base do gerenciamento de pacotes no Debian, responsável por instalar, desinstalar e atualizar pacotes.deb. O APT extende as funções do 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 (.rpm) e outros sistemas como OpenSolaris, Ubuntu GNU/Linux e OS X (10). 2.4 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 gratuitamente e sem necessidade de cadastro. Repositórios podem servir apenas pacotes particulares, ou para um sistema operacional inteiro, como o CPAN para a linguagem de programação Perl, como a distribuição GNU/Linux Ubuntu.

20 2.5 Gerenciamento de configuração 16 Como repositórios de software são destinados a incluir pacotes mantidos por empresas e organizações, a maioria dos repositórios são conhecidos como livres de malware. Se um computador é configurado para 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 para aumentar a disponibilidade e descentralizar a distirbuição dos softwares 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 e.tar.gz ou.orig.tar.gz e.diff.gz) para que ferramentas como APT saibam quais os pacotes disponíveis e como obtê-los. Reprepro gerencia as versões dos pacotes mantendo apenas a versão mais atual. Os arquivos são armazenados utilizando o Berkley DB 1, logo não é necessário a instalação de sistema de banco de dados. 2.5 Gerenciamento de configuração Para realizar a configuração da instalação do BeeFS em máquinas, o uso de uma ferramenta de gerenciamento de configuração centraliza e torna o gerenciamento mais prático e escalável, diminuindo o risco de existir uma configuração inadequada 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 1 Oracle Berkeley DB é um banco de dados embarcado transacional open source que permite aos desenvolvedores incorporar em suas aplicações.

21 2.6 Tracers 17 horas de trabalho e provendo uma melhor qualidade de serviço. Puppet permite que administradores de sistemas gastem 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 (7). 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 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.6 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 distribuídos 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 (9). 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 manter manuntenção aos softwares e hardwares em desenvolvimento (??13). Além da utilização de traces para estudos de performances (11), existem dois outros usos: análise de segurança do software e debugging. Primeiro, monitoramento de sistema de arquivo é útil para segurança e auditoria. Análise das operações em sistema de arquivos

22 2.6 Tracers 18 podem ajudar a detectar intrusos a partir da filtragem de acessos por usuários, processos ou programas. Segundo, traces são úteis para debuging de sistemas de arquivos, auxiliando a localizar possíveis bugs e pontos de falha. Um software capaz de monitorar todas operações de um sistema de arquivos e que possui instalação sem requisitar modificações no sistema de arquivos a ser monitorado são particularmente mais adequandos para realização da depuração por não alterar o comportamento do sistema a ser analisado.

23 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 em relação a outros sistemas de arquivos distribuídos, como o NFS, é saber o tempo que leva a execução de cada operação no sistema de arquivo, como gravar ou ler um arquivo. Para tal comparação, a obtenção de um log registrando: o tempo de duração das operações, o momento no qual ocorreram e as informações peculiares de cada operação era necessário, e para isso, foi feita uma busca por softwares dessa natureza. Foram analisados dois programas: TraceFS e Loggedfs TraceFS TraceFS é um aplicativo que comporta-se como uma fina camada utilizada para gerar traces de sistemas de arquivos. TraceFS é capaz de ser configurado dinamicamente para capturar qualquer número de eventos no sistema de arquivo por nome de arquivo ou extensão, dono, grupo, processo, quantos acessos por dia, entre outras informações. 19

24 3.1 Monitores de sistema de arquivos 20 As informações capturadas pelo TraceFS são concebidas para ser auto-explicativas e sucintas. Ele é capaz de, apartir de seus logs, realizar a replicação das operações registradas nos traces, tornando-se um diferencial dentre os softwares de monitoramente de sistema de arquivos. Implementado em 2004, utilizando a linguagem de programação C e distribuído sob a licença GPLv2, teve a última release no dia 12 de outubro de Desde então, o código não sofreu atualização e as funções utilizadas providas pelo kernel linux foram modificadas ou removidas. Para atender aos requisitos de contabilizar o tempo da execução das operações e o momento de início de cada uma das operações, era necessário modificar parte do codigo do TraceFS, mas atualmente não é possível compilar seu código. Apesar disso, tentativas de modificação foram realizadas, mas sem sucesso. Logo, o uso do TraceFS para monitorar as operações em sistemas de arquivos foi descartado LoggedFS LoggedFS é um sistema de arquivos implementado utilizando FUSE 1 o qual permite gravar toda operação que acontece no backend de um sistema de arquivos. LoggedFS possui um aquivo de configuração XML o qual o usuário pode escolher exatamente o que deseja gravar por meio de filtros. Esses filtros podem conter especificações de operações realizadas apenas por determinados usuários, operações (open, read, write, chown, chmod, etc.), nomes dos arquivos e código de retorno de execução entre outros. Os filtros de nomes de arquivos são feitos utilizando expressões regulares. LoggedFS apenas envia a mensagem para o gerenciador de logs syslog quando chamado pelo FUSE e depois permite que o real sistema de arquivos prossiga com a operação. Monitorando todas operações em um sistema de arquivos e de fácil instalação, o LoggedFS faz quase o que era desejado. Entretanto, também era necessário registrar a duração dos tempos de execução e o momento no qual ocorreu cada operação. A implementação do LoggedFS vem sido mantida, o que viabilizou as mudanças para 1 API para implementação de sistemas de arquivos em espaço de usuário

25 3.1 Monitores de sistema de arquivos 21 capturar todas informações necessárias Modificações necessárias Toda operação capturada é armazenada contendo: o momento em que ocorreu, a linha do código que 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 e nome do processo e o usuário que o executou. Para maior detalhes sobre a operação, foi adicionado no código do LoggedFS instruções que registram o timestamp 2 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, antes da modificação, 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 foi armazenada assim: 06:39:25 (src/loggedfs.cpp:155) statfs /local/ {SUCCESS} [ pid = 2990 /usr/sbin/snmpd uid = 115 ] Onde a diferença pode ser notada por 2 números adicionais: que representa o timestamp da operação e que significa a duração da operação, medida em milisegundos. Para uma maior quantidade de log gerado para futura análise, o executável de inicialização do LoggedFS foi modificado para monitorar todos os sistemas de arquivo disponíveis da máquina a ser monitorada. Utilizando os computadores do LSD, os sistemas de arquivos monitorados foram EXT3, EXT4 e NFS. 2 Número inteiro que representa a contagem de segundos iniciado em 19 de janeiro de 1970

26 3.2 Gerenciamento de pacotes Problemas identificados Por fazer uso tecnologia FUSE, o qual requer permissão de super usuário (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 arquivos. 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, a instalação do LoggedFS está em fase de avaliação, com apenas 5 máquinas do Laboratório de Sistemas Distribuídos, pois após a modificação, a execução do LoggedFS é interrompida após a ocorrência de uma falha de segmentação, bloqueando o acesso ao sistema de arquivo monitorado. 3.2 Gerenciamento de pacotes O BeeFS possuia uma instalação sem auxílio além do tutorial presente em sua página: para sua execução era necessário apenas 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. Pensando nisso que foi sugerido o uso de 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. 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 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

27 3.2 Gerenciamento de pacotes 23 de disponibilizar o pacote, repositórios de softwares são usados para prover segurança e confiabilidade para seus usuários, 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. De acordo com a Linux File System (LFS), que define regras de localização de arquivos de acordo com o uso dentro do sistema operacional (3), a pasta de armazenamento de arquivos mutáveis disponíveis por um servidor HTTP ficam preferencialmente localizados na pasta /var/. Logo, nela foi criado uma pasta na qual todo o repositório foi instalado. O nome da pasta escolhida foi apt, simbolizando que o repositório é compatível com APT. 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 qual podem ser definidos os seguites parâmetros: origem, label, suite, apelido do repositório, arquitetura suportada pelos softwares disponibilizados por ele, componentes e descrição. Com essas opções, o arquivo de configuração criado foi: Origin: LSD Label: unstable Suite: unstable Codename: unstable Architectures: i386 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

28 3.3 Criação dos pacotes 24 com a necessidade du usuário. No momento existe apenas a suite unstable pois o pacote BeeFS não está com a implementação definitivamente estável. Após a instalação do repositório, para armazenar e prover um pacote à comunidade, é necessario importar os 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 já exista no repositório, e a versão existente seja anterior a que se está adicionando, o pacote é substituido. Caso contrário, é dada uma mensagem de erro informando que a importação não foi concluída. A remoção de um pacote do repositório pode ser realizada especificando o nome do pacote e qual suite ele pertence. beefs-common, o comando fica: Utilizando o exemplo da importação do pacote reprepro remove beefs-common unstable Por fim, foi configurado um servidor HTTP (por meio da instalação do pacote apache2) para prover o acesso ao repositório. O servidor HTTP foi configurado para prover acesso ao repositório por meio do endereço Criação dos pacotes Para criação do pacote, foi necessário um estudo sobre como é a organização de um pacote Debian (.deb) e realização do mapeamento dos atuais arquivos de instalação do BeeFS de acordo com a convenção Linux File System (LFS). 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.

29 3.3 Criação dos pacotes 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 Arquivos de instalação do pacote Um pacote Debian possui, além do software o qual deseja-se instalar, que identificam o pacote e executam 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 (4) que são: conffiles Arquivo que contém 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 Contém a versão do pacote (2.0); postinst Script executado após a extração do pacote; 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 existência é obrigatória é o arquivo control. Define uma descrição completa sobre o pacote para que o repositório no qual ele está

30 3.3 Criação dos pacotes 26 armazenado, tenha conhecimento de seu nome e versão, entre outras informações. No pacote construído do BeeFS, o conteúdo desse arquivo control é: Package: beefs Priority: optional Version: Architecture: all Installed-size: 2252 Maintainer: Jonhnny Weslley, Thiago Emmanuel and Alexandro Soares 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: 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 de instalação, versão do software, 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 (dependências) para instalação do pacote, homepage do programa e descrição Scripts de auxílio à instalação do BeeFS O pacote BeeFS possui quatro scripts que são utilizados em sua instalação. 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;

31 3.3 Criação dos pacotes 27 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 Apêndice B 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 foram escolhidas, assume-se automaticamente que a localização do componente Queen- Bee é localhost, e segue-se a configuração exibindo a próxima pergunta. Na Figura 3.4 exibe a tela que pede ao usuário que insira a quantidade de espaço que deseja agregar ao sistema de arquivo. Logo após, pergunta-se qual o diretório que fornecerá esse espaço (Figura 3.5) e por fim pergunta-se qual o diretório que montará o sistema de arquivo BeeFS como mostra a Figura 3.6. Os arquivos do BeeFS, após instalado, ficam organizados na seguinte árvore hierárquica:

32 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

33 3.3 Criação dos pacotes 29 Figura 3.3: Tela para inserir o IP ou nome do servidor BeeFS Figura 3.4: Tela para inserir a quantidade de espaço que deseja compartilhar

34 3.3 Criação dos pacotes 30 Figura 3.5: Tela para inserir a pasta que armazenará os arquivos brutos Figura 3.6: Tela para inserir o diretório que montará o BeeFS

35 3.3 Criação dos pacotes 31 / -- etc -- init.d -- beefs -- beefs -- environment.sh -- log4j.properties -- services.info -- services.ini -- usr -- lib -- beefs -- commons-logging jar -- beefs-commons-0.1-beta.jar -- beefs-communication-0.1-beta.jar -- beefs-distributed-storage-0.1-beta.jar -- beefs-filesystem-0.1-beta.jar -- beefs-fuse-0.1-beta.jar -- beefs-objectstorage-device-0.1-beta.jar -- beefs-services-0.1-beta.jar -- beefs-xsocket-communication-0.1-beta.jar -- fuse-j-2.4.jar -- jdbm-1.0b.jar -- jsch jar -- log4j jar -- native -- libjavafs.so -- perf4j jar -- plexus-utils jar -- slf4j-api jar -- slf4j-log4j jar -- xsocket jar -- sbin -- beefs ->../share/beefs/beefs -- beefs-config.sh ->../share/beefs/beefs-config.sh -- beefs.bat ->../share/beefs/beefs.bat -- java-config.sh ->../share/beefs/java-config.sh -- mount.beefs ->../share/beefs/mount.beefs -- share -- beefs -- beefs -- beefs-config.sh -- beefs.bat -- java-config.sh -- mount.beefs -- var -- lib -- beefs -- ObjectStorageDevice.db -- ObjectStorageDevice.lg -- log -- beefs -- beefs.log

36 3.3 Criação dos pacotes Segunda versã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 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 - localizadas no diretório /var/lib/beefs e o arquivo de ajuda (man page), localizado na pasta /usr/share; beefs-queenbee Seu conteúdo é similar ao pacote beefs-honeycomb, mudando apenas o arquivo de configuração, que neste caso é o queenbee.conf. 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; Os pacotes beefs-queenbee, beefs-honeybee e beefs-honeycomb tem como dependente o pacote beefs-common, que possui os arquivos comuns a todos. A seguir é detalhado a organização hierárquica dos pacotes quando instalados no sistema Pacote beefs-honeybee Este pacote contem apenas o arquivo de inicialização (/etc/init.d/beefs), arquivo de configuração específica para esse componentes (/etc/beefs/honeybee.conf), uma biblioteca necessária para montar o arquivo de sistema (/usr/lib/beefs/native/libjavafs.so) e o diretório de logs (/var/log/beefs). Abaixo é mostrada ahierarquia dos arquivos: / -- etc -- init.d

37 3.3 Criação dos pacotes beefs -- beefs -- honeybee.conf -- usr -- lib -- beefs -- native -- libjavafs.so -- sbin -- mount.beefs -> /usr/share/beefs/mount.beefs -- beefs -> /usr/share/beefs/beefs -- beefs-config.sh -> /usr/share/beefs/beefs-config.sh -- beefs.bat -> /usr/share/beefs/beefs.bat -- var -- log -- beefs Pacote beefs-common Este pacote contém a implementação do BeeFS e arquivos de configuração de ambiente e arquivo de ajuda (man page). / -- etc -- default -- beefs -- environment.sh -- log4j.properties -- service_manager.conf -- services.info -- usr -- lib -- beefs -- commons-logging jar -- beefs-commons-0.1-beta-build jar -- beefs-commons-0.1-beta.jar -- beefs-communication-0.1-beta.jar -- beefs-distributed-storage-0.1-beta-build jar -- beefs-distributed-storage-0.1-beta.jar -- beefs-filesystem-0.1-beta-build jar -- beefs-filesystem-0.1-beta.jar -- beefs-fuse-0.1-beta-build jar -- beefs-fuse-0.1-beta.jar -- beefs-objectstorage-device-0.1-beta-build jar -- beefs-objectstorage-device-0.1-beta.jar -- beefs-services-0.1-beta-build jar -- beefs-services-0.1-beta.jar -- beefs-xsocket-communication-0.1-beta-build jar -- beefs-xsocket-communication-0.1-beta.jar -- fuse-j-2.4.jar -- jdbm-1.0b.jar -- jsch jar -- junit-4.4.jar -- log4j jar

38 3.3 Criação dos pacotes perf4j jar -- plexus-utils jar -- slf4j-api jar -- slf4j-log4j jar -- xsocket jar -- share -- man -- man1 -- beefs.1.gz -- beefs -- mount.beefs -- beefs -- beefs-config.sh -- beefs.bat Pacote beefs-honeycomb Similar ao pacote beefs-honeybee, este pacote possui o arquivo de inicialização (/etc/init.d/beefs), arquivo de configuração específica para esse componentes (/etc/beefs/honeycomb.conf) e o diretório de logs (/var/log/beefs). / -- etc -- init.d -- beefs -- beefs -- honeycomb.conf -- usr -- sbin -- mount.beefs -> /usr/share/beefs/mount.beefs -- beefs -> /usr/share/beefs/beefs -- beefs-config.sh -> /usr/share/beefs/beefs-config.sh -- beefs.bat -> /usr/share/beefs/beefs.bat -- var -- lib -- beefs -- data -- log -- beefs Pacote beefs-queenbee Este pacote possui, similar os pacotes beefs-honeybee e beefs-honeycomb, o arquivo de inicialização (/etc/init.d/beefs), arquivo de configuração específica para esse componentes (/etc/beefs/queenbee.conf) e o diretório de logs (/var/log/beefs). / -- etc -- init.d

39 3.3 Criação dos pacotes beefs -- beefs -- queenbee.conf -- usr -- sbin -- mount.beefs -> /usr/share/beefs/mount.beefs -- beefs -> /usr/share/beefs/beefs -- beefs-config.sh -> /usr/share/beefs/beefs-config.sh -- beefs.bat -> /usr/share/beefs/beefs.bat -- var -- lib -- beefs -- data -- log -- beefs A vantagem da separação dos pacotes é que para realizar a atualização do software, basta atualizar o pacote beefs-common, evitando a reconfiguração dos arquivos de configuração dos pacotes beefs-honeybee, beefs-honeycomb e beefs-queenbee Instalação A instalação pode ser feita executando os seguintes passos: 1. Adiciona-se o repositório do LSD em /etc/apt/source.lst, $ sudo echo deb unstable main >> /etc/apt/source.lst 2. Após, atualiza-se a lista de pacotes para instalar a versão disponível mais recente. # apt-get update A partir daí, pode-se instalar o(s) componente(s) do BeeFS desejado(s). 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

40 3.3 Criação dos pacotes 36 Terminado esses passos, o BeeFS está instalado, porém deve-se, ainda, configurá-lo. Para realizar a configuração, deve-se seguir a seguinte sequência de passos: Configuração do componente QueeBee que possui os seguintes parâmetros: filesystem.port Porta de transmissão de metadados. Valor default: 7791; osdmaster.port Porta de comunicação com os componentes HoneyBee. default: 7792; Valor metadata_directory Diretório que armazenará os metadados. /var/lib/beefs/data; Valor default: filesystem.replication_level Nível de replicação dos arquivos armazenados no BeeFS. Valor default: 4; filesystem.time_to_coherence Tempo máximo de coerência entre as réplicas dos arquivos. Valor default: 1day; filesystem.metadata_replication Boleano que indica se existe réplica dos metadados. Valor default: no; filesystem.root_squash Boleano que permite que super-usuários de máquinas clientes alterem os dados armazenados no sistema de arquivos. Valor default: no; coherence_protocol.thread_count Quantidade de threads que realizarão a coerência dos dados replicados. Valor default: 4. Configuração do componente HoneyComb que possui os seguintes parâmetros: osdmaster Nome ou IP do servidor que possui o componente QueeBee; metadata_directory Pasta que conterá os arquivos de controle dos dados armazenados; control_port Porta para transmissão de dados de controle. Valor default: 7793; transfer_port Porta para transmissão de arquivos. Valor default: 7794; TransferByteBufferMaxSize Tamanho máximo do buffer de transferência de dados. Valor default: 8KiB; contributing_storage.amount Quantidade de espaço que será agregado ao sistema de arquivo. Valor default: 2 GiB;

41 3.4 Tasks, Features e Bugs identificadas 37 contributing_storage.directory Pasta que armazenará os dados do sistema de arquivos. Configuração do componente HoneyBee que possui os seguintes parâmetros: filesystem Nome ou IP do servidor que possui o componente Queebee; metrics Booleano que habilita a geração de traces das operações do sistema de arquivos. Valor default: no; kernel_cache Booleano que habilita o cache de dados feito diretamente no kernel do sistema operacional. Valor default: yes; metadata_cache.enabled Booleano que habilita o cache de metadados. Valor default: yes; metadata_cache.size Valor que indica o tamanho do cache de metadados. Usado apenas se o parametro acima for ativado. Valor default: 300; mount_directory Pasta que montará o sistema. de arquivo BeeFS. Feita a devida configuração, a inicialização do BeeFS pode ser feita assim: # invoke-rc.d beefs start O comando acima inicializará todos os componentes do BeeFS. A inicialização dos componentes podem ser feita separadamente com os comandos: # beefs start queenbee # beefs start honeycomb # beefs start honeybee O BeeFS deve ser inicializado com o usuário beefs, que é criado durante a instalação. 3.4 Tasks, Features e Bugs identificadas Com a execução das atividades descritas acima, foram necessárias algumas modificações no código do BeeFS bem como identificou-se alguns bugs. Features também foram sugeridas para suprir a necessidade da adaptação da instalação feita por pacote.

42 3.4 Tasks, Features e Bugs identificadas Bugs Dentre os 6 bugs identificados, 1 ainda encontra-se aberto. 1. Data 25/09/2009; Estado Fechado; Prioridade Alta; Descrição O ponto de montagem não atualizava o espaço disponível quando um novo HoneyComb era adiciona ao sistema; Atribuído para Jonhnny Silva; Versão Beta Data 29/09/2009; Estado Fechado; Prioridade Alta; Descrição Apesar dos arquivos armazenados do sistema de arquivo possuir permissão para leitura, ao tentar acessá-lo era acusado o erro de permissão negada; Atribuído para Jonhnny Silva; Versão Beta Data 29/09/2009; Estado Fechado; Prioridade Alta; Descrição O espaço usado do sistema de arquivo não era atualizado, mostrando sempre o valor 0 (zero); Atribuído para Jonhnny Silva; Versão Beta Data 20/10/2009; Estado Fechado; Prioridade Normal; Descrição O espaço usado do sistema mostrava apenas parte dos dados realmente armazenados;

43 3.4 Tasks, Features e Bugs identificadas 39 Atribuído para Jonhnny Silva; Versão Beta Data 18/11/2009; Estado Fechado; Prioridade Alta; Descrição Ao iniciar o componente HoneyBee, ocorria um erro acusando que o parâmetro ClientContext não poderia ser null; Atribuído para Jonhnny Silva; Versão Beta Data 25/11/2009; Estado Aberto; Prioridade Urgente; Descrição O componente QueeBee não inicializa se existe algum componente HoneyComb executando; Atribuído para Jonhnny Silva; Versão Beta Tasks e Features As seguintes tasks e features foram sugeridas tomando como base o meu ponto de vista de usuário e administrador do sistema. São 5 no total, das quais 2 permanescem em aberto. 1. Data 28/09/2009; Estado Fechado; Prioridade Normal; Descrição Mudança da localização dos arquivos de controle e metadados para a pasta /var/lib/beefs/data; Atribuído para Jonhnny Silva; Versão Beta 0.1.

44 3.4 Tasks, Features e Bugs identificadas Data 29/09/2009; Estado Fechado; Prioridade Normal; Descrição Alterar as portas utilizadas pelo BeeFS de 9090 até 9093 para 7790 até 7793, pois o OurGrid já utilizava as portas iniciais. Essa alteração foi baseada na lista de atribuição de portas, gerenciado pela IANA (Internet Assigned Numbers Authority); Atribuído para Jonhnny Silva; Versão Beta Data 29/09/2009; Estado Aberto; Prioridade Normal; Descrição Criação dos links de acesso ao diretório corrente e do nível acima (. e..); Atribuído para Jonhnny Silva; Versão Beta Data 08/10/2009; Estado Fechado; Prioridade Normal; Descrição Todas as exceções lançadas pelo software eram mostradas na saída default. Alteração foi feita para que as exceções sejam armazenadas no log do BeeFS; Atribuído para Jonhnny Silva; Versão Beta Data 18/10/2009; Estado Aberto; Prioridade Normal;

45 3.5 Instalação do Puppet 41 Descrição Adicionar o comando leave ao componente HoneyComb, pois ao remover um desses componentes no sistema de arquivo, que informaria ao componente QueenBee que um nó estaria saindo do sistema, podendo assim, mover os arquivos ali armazenados para outro componente HoneyComb da rede. Atribuído para Jonhnny Silva; Versão Beta 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 acordo com o que é especificado em seus arquivos de configuração. O conteúdo do arquivo de configuração consiste numa linguagem de programação declarativa no qual especifica-se as exigências de cada operação. A instalação do Puppet é feita por meio de dois pacotes: puppetmaster Servidor do serviço de gerência do Puppet; puppet Cliente a ser instalado nas máquinas desktops 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