Instituto De Pesquisas Tecnológicas Do Estado De São Paulo ANDERSON TADEU MILOCHI Grids De Dados: Implementação E Avaliaçã

Instituto de Pesquisas Tecnológicas do Estado de São Paulo

ANDERSON TADEU MILOCHI

Grids de Dados: Implementação e Avaliação do Grid Datafarm – Gfarm File System – como um sistema de arquivos de uso genérico para Internet

São Paulo

2007

Ficha Catalográfica Elaborada pelo Departamento de Acervo e Informação Tecnológica – DAIT do Instituto de Pesquisas Tecnológicas do Estado de São Paulo - IPT

M661g Milochi, Anderson Tadeu Grids de dados: implementação e avaliação do Grid Datafarm – Gfarm File System como um sistema de arquivos de uso genérico para internet. / Aderson Tadeu Milochi. São Paulo, 2007. 149p.

Dissertação (Mestrado em Engenharia de Computação) - Instituto de Pesquisas Tecnológicas do Estado de São Paulo. Área de concentração: Redes de Computadores.

Orientador: Prof. Dr. Sérgio Takeo Kofuji

1. Sistema de arquivo 2. Internet (redes de computadores) 3. Grid Datafarm 4. Data Grid 5. Máquina virtual 6. NISTNet 7. Arquivo orientado a serviços 8. Tese I. Instituto de Pesquisas Tecnológicas do Estado de São Paulo. Coordenadoria de Ensino Tecnológico II.Título

07-20 CDU 004.451.52(043)

ANDERSON TADEU MILOCHI

Grids de Dados: Implementação e Avaliação do Grid Datafarm – Gfarm File System - como um sistema de arquivos de uso genérico para Internet

Dissertação apresentada ao Instituto de Pesquisas Tecnológicas do Estado de São Paulo - IPT, para obtenção do título de Mestre em Engenharia de Computação Área de concentração: Redes de Computadores

Orientador: Prof. Dr. Sérgio Takeo Kofuji

São Paulo

Março 2007

A Deus, o Senhor de tudo, Mestre dos Mestres, o único Caminho, Verdade e Vida. À minha esposa, pelo seu incondicional apoio apesar da dolorosa solidão. À minha filha, pela compreensão nos meus constantes momentos de isolamento. Aos meus pais, Rudinei e Eneida, instrumentos de vida, apoio e amor.

AGRADECIMENTOS

Ao meu orientador, Prof. Dr. Sérgio Takeo Kofuji, pela atenção, inteligência e expressivo auxílio na concepção e desenvolvimento desta dissertação, fazendo-a reconhecida dentro de seletos grupos de pesquisa na área de armazenamento em rede.

A todos os professores do Mestrado em Engenharia de Computação do IPT, pelo grande conhecimento partilhado durante toda caminhada, especialmente aos professores Dr. Antonio Rigo e Dr. Paulino NG, participantes ativos da etapa final.

Ao coordenador do C.E.T., o Prof. Dr. Mario Miyake, pelo apoio e oportunidade no desenvolvimento de uma pesquisa para o IPT, que me permitiu custear toda a fase da dissertação.

Ao Prof. Dr. Armando Silvestre, pela amizade e apoio em fazer a revisão do texto e forma deste trabalho.

Aos colaboradores da FIAP, especialmente aos profissionais do Departamento de Informática, pelo empréstimo de equipamento para os experimentos.

Aos meus incansáveis irmãos de luta, Ibsen Marques e Armando Mizumachi, pelo auxílio em tantas vezes suportar minha ausência na Coverex Informática, além de me proporcionarem tranqüilidade, mediante muito empenho e honestidade.

A todos os funcionários da Coverex que me auxiliaram direta ou indiretamente no desenvolvimento deste trabalho, principalmente contornando as situações críticas nos meus momentos de ausência.

Aos grandes amigos, padres Leonardo Cruz, Orlando Arias e Miguel Vallejo, incentivadores muito fortes nas palavras e orações, que muito me fortaleceram quando o cansaço queria vencer.

Aos amigos da Paróquia São João Batista da Vila Mira, que com suas orações também foram incentivadores na caminhada.

Ao Instituto de Pesquisas Tecnológicas do Estado de São Paulo - IPT, pelo apoio direto ou indireto na realização deste trabalho. RESUMO

A computação em grid tem sido objeto de intensas pesquisas em razão da sua proposta de, ao virtualizar os recursos computacionais, permitir a sua alocação dinâmica tanto para aplicações científicas quanto para as comerciais. Isso se dá graças às suas características de flexibilidade, escalabilidade e otimização, visando a uma arquitetura fortemente orientada a serviços e à colaboração em larga escala. Seu uso tem sido observado em projetos científicos como o SETI@home, grids de sensores, TeraGrid, myGrid, GriPhyN e o Projeto OurGrid no Brasil, visando federar capacidades computacionais interconectadas em redes como a Internet. Tipicamente emprega plataformas diversificadas de hardware e software, numa função de consolidação que visa à escalabilidade. Entre as capacidades computacionais está o armazenamento de dados, cuja federação forma os grid de dados, os quais podem ser organizados e acessados com um sistema de arquivos de grid. O objetivo deste trabalho é avaliar a implementação, funcionalidade e desempenho do sistema de arquivos de grid Gfarm - uma implementação de referência da arquitetura Grid Datafarm - a ser usado como um sistema de arquivos de uso geral para a Internet. O trabalho foi desenvolvido mediante pesquisa conceitual sobre a computação em grid, grids de dados, sistemas de arquivos paralelos, máquinas virtuais e emulador de rede, fundamentando um experimento em laboratório com a instalação, configuração e análise funcional do Gfarm em condições de rede emuladas pelo NIST Net. O comportamento do conjunto foi observado ao variarem-se condições como largura de banda e atraso, perante o armazenamento e uso de diversas classes de conteúdo, observando também as condições de tolerância a falhas. Adicionalmente, para explorar as condições reais do emprego em múltiplos sistemas operacionais e a facilidade de implementação, dois nós de armazenamento foram implementados com máquinas virtuais Microsoft Virtual PC 2004 executando Linux Fedora Core 5. Os resultados mostraram reais condições de implementação e funcionalidade do Gfarm como solução de sistema de arquivos de uso geral para Internet, suportando a integração com diversas plataformas e empregando equipamentos de uso cotidiano, operando como repositório para arquivos de propósito geral ou biblioteca digital.

Palavras-chave: Grids de dados, Grid Datafarm, Gfarm, Grid, Máquinas virtuais, NIST Net, Sistema de arquivos ABSTRACT

Data Grids: Deployment and Evaluation of Grid Datafarm – Gfarm file system – as an Internet general-purpose file system

Grid computing has been intensely researched due to its proposal of, in virtualizing computing resources, providing their dynamic allocation for scientific and commercial applications, thanks to features such as flexibility, scalability and optimization, targeting a service-oriented architecture and large-scale collaboration. Its use has been noticed in scientific projects such as sensors grids, SETI@home, TeraGrid, myGrid, GriPhyn and OurGrid in Brazil, aiming to federate interconnected computing capabilities in networks as the Internet, typically employing different hardware and software platforms, in a consolidation function that aims at scalability. The data storage may be one of these capabilities, so that it is federated to form data grids, which can be organized and accessed using a grid file system. The purpose of this work is to evaluate the deployment, functionality and performance of Gfarm grid file system – a reference implementation of Grid Datafarm architecture – to be used as a general-purpose Internet file system. The work was developed using available literatures about grid computing, data grids, parallel file systems, virtual machines and network emulation, serving as the basis to build an experimental scenario where Gfarm was installed, configured and functionally analyzed in an emulated network environment provided by NIST Net. The behavior of the scenario was observed when varying network conditions such as bandwidth and delay, facing the storage and use of different classes of content, noticing the fault tolerance conditions as well. Besides, in order to explore the real possibilities of employing multiple operating systems, two storage nodes were implemented using Microsoft Virtual PC 2004 virtual machines hosting Linux Fedora Core 5. The results showed real deployment conditions and functionality of Gfarm, as an Internet general-purpose file system solution, supporting the integration with multiple platforms and employing commodity hardware, operating as a file repository for general-purpose or digital library files.

Keywords: Data Grids, File system, Gfarm, Grid, Grid Datafarm, NIST Net, Virtual machines LISTA DE ILUSTRAÇÕES

Figura 1 - Articulação do trabalho...... 27 Figura 2 – Cenário inicial de implementação do experimento...... 28 Figura 3 – Exemplo de gráfico gerado a partir de dados coletados pelo IOzone...... 31 Figura 4– A arquitetura de grid em camadas e seu relacionamento com a arquitetura de protocolo da Internet...... 34 Figura 5 – Gráfico gerado a partir de dados coletados pelo IOzone com principais regiões demarcadas ...... 43 Figura 6 – Arquitetura e elementos do Grid Datafarm – Gfarm File System...... 47 Figura 7 – Cenário final do experimento com o Gfarm (referente ao quadro 10)...... 60 Figura 8 – Tela gráfica de parametrização do NIST Net...... 71 Figura 9 – Listagem de diretório do Gfarm com o uso da biblioteca syscall-hook...... 77 Figura 10 – Visualização da localização de arquivos com “gfwhere” e “gfront” ...... 77 Figura 11 – IOzone local - Escrita – metasvr.grid.local ...... 78 Figura 12 – IOzone local – Reescrita - metasvr.grid.local...... 79 Figura 13 – IOzone local – Leitura - metasvr.grid.local...... 79 Figura 14 – IOzone local – Releitura - metasvr.grid.local...... 80 Figura 15 - IOzone local – Leitura - metasvr.grid.local – visualização com linhas ...... 80 Figura 16 – Desempenho individual de sistema de arquivos dos componentes do Gfarm ...... 81 Figura 17 – Efeito do cache no comando “gfls” perante atraso de 3,5s para o metaserver ...... 82 Figura 18 - Efeito do cache com opção “-m” no comando “gfls” perante atraso de 1,5s para o metaserver...... 83 Figura 19 - Efeito do cache no comando “ls” perante atraso de 3,5s para o metaserver .83 Figura 20 – Efeito do cache de metaserver no comando de cópia “cp” entre diretórios do Gfarm...... 84 Figura 21 – Desempenho do Gfarm nas versões 1.2-5 (1.2 PL4) e 1.3.1, com e sem atraso para o metaserver (itens a e b)...... 86 Figura 22 – Influência do cache do metaserver em atrasos para o metaserver no Gfarm 1.3.1 (item d) ...... 87 Figura 23 – Influência da largura de banda entre nós no Gfarm 1.3.1 (item c)...... 88 Figura 24 – Gfarm 1.3.1 – 2 nós (dfsrv3 e dfsrv4 – máquinas reais) – atraso de 1s para o metaserver ...... 89 Figura 25 – Gfarm 1.3.1 – benchmark concorrente gfwks e smbsvr – com cache em 3 nós ...... 90 Figura 26 – Comparativo de desempenho entre sistema de arquivo LOCAL, NFSv4.fc5 e Gfarm 1.2-5 (1.2 PL4) / 1.3.1 – nó dfsrv4 – valores de pico e médios ...... 91 Figura 27 – Latência de leitura – Arquivo de 64KB – Gfarm 1.2-5 (1.2 PL4) – 3 nós....92 Figura 28 - Latência de leitura – Arquivo de 512KB – Gfarm 1.2-5 (1.2 PL4) – 3 nós ..93 Figura 29 - Latência de leitura – Arquivo de 128MB – Gfarm 1.3.1 – 4 nós ...... 93 Figura 30 – Comparativo de desempenho do Gfarm 1.3.1 com front-end SAMBA, do modo nativo em Linux, e do ambiente de compartilhamento Windows direto no SAMBA ...... 96 Figura 31 – Conteúdo do DVD para criação de cenário de teste do Gfarm...... 148 Figura 32 – Gráficos do benchmark da Tabela 7 – Leitura e Escrita ...... 158 Figura 33 – Gráficos do benchmark da Tabela 8...... 160 Figura 34 – Gráficos do benchmark da Tabela 9 – Leitura e Escrita ...... 162 Figura 35 – Gráficos do benchmark da Tabela 10...... 164 Figura 36 – Gráficos do benchmark da Tabela 11 – Leitura e Escrita ...... 166 Figura 37 - Efeito do cache nos tempos de execução de comandos (gfls, gfcp e ls) sob o Gfarm 1.3.1 com syscall-hook...... 168 Figura 38 – Gráficos do benchmark da Tabela 17...... 174 Figura 39 – Gráficos MRTG – Durante benchmarks Gfarm 1.3.1 / primeiras rodadas – (1/3) ...... 175 Figura 40 - Gráficos MRTG – Durante benchmarks Gfarm 1.3.1 / primeiras rodadas – (2/3) ...... 176 Figura 41 - Gráficos MRTG – Durante benchmarks Gfarm 1.3.1 / primeiras rodadas – (3/3) ...... 177 Figura 42 - Gráficos MRTG – Durante benchmarks Gfarm 1.3.1 / smbsvr com cache em 3 nós (1/3)...... 178 Figura 43 - Gráficos MRTG – Durante benchmarks Gfarm 1.3.1 / smbsvr com cache em 3 nós (2/3)...... 179 Figura 44 - Gráficos MRTG – Durante benchmarks Gfarm 1.3.1 / smbsvr com cache em 3 nós (3/3)...... 180 Figura 45 – Cópia de tela – acesso ao Gfarm com o browser Firefox ...... 181 Figura 46 – Cópia de tela - acesso ao Gfarm via SAMBA por cliente Windows ...... 181 Figura 47 – Cópia de tela – acesso ao Gfarm via SAMBA por clientes Windows – diretórios e arquivos ...... 182 LISTA DE QUADROS

Quadro 1 – Funcionalidades e respectivos módulos do Gfarm (versões 1.1.1 até 1.3.1)...... 29 Quadro 2 - Funcionalidades e respectivos módulos do Gfarm 1.3.1...... 49 Quadro 3 – Comando para registro de nó de armazenamento no Gfarm ...... 51 Quadro 4 – URL para acesso ao Gfarm file system...... 51 Quadro 5 – API de I/O paralelo – funções de Inicialização e Finalização...... 53 Quadro 6 - API de I/O paralelo – funções de Manipulação de Arquivos...... 54 Quadro 7 - API de I/O paralelo – funções de Acesso a Arquivos...... 55 Quadro 8 - API de I/O paralelo – funções de Visualização de Arquivo ...... 55 Quadro 9 – Principais comandos Gfarm...... 56 Quadro 10 – Composição dos elementos do cenário experimental do Gfarm na Coverex...... 62 Quadro 11 – Arquivo de configuração do SNMP (snmpd.conf) usado nos nós do Gfarm...... 66 Quadro 12 – Procedimento padrão de configuração dos nós monitorados com MRTG...... 67 Quadro 13 – Arquivo de configuração MRTG para MIBs UCD-SNMP e TCP...... 68 Quadro 14 – Visualização do módulo de RTC do NIST Net ...... 70 Quadro 15 – Script “nnet” para substituição do módulo RTC pelo NIST Net...... 70 Quadro 16 - Conteúdo do arquivo “auto.master”...... 72 Quadro 17 - Conteúdo do arquivo “auto.gfarm” ...... 72 Quadro 18 – Limite de tamanho de arquivo sugerido pelo IOzone...... 74 Quadro 19 – Comando para visualizar a localização dos fragmentos de um arquivo Gfarm ..75 Quadro 20 – Configuração do Gfarm com PostgreSQL para servidor de metadados...... 117 Quadro 21 - Configuração do Gfarm com LDAP para servidor de metadados ...... 117 Quadro 22 – Configuração do servidor de cache de metadados ...... 119 Quadro 23 - Configuração do nó servidor de arquivos ...... 121 Quadro 24 - Exemplo de resultado do comando “gfls”...... 124 Quadro 25– Exemplo de resultado do comando “gfhost -l”...... 124 Quadro 26 - Exemplo de resultado do comando “gfhost –M” ...... 124 Quadro 27 – Conteúdo da variável “LD_PRELOAD”...... 125 Quadro 28– Exemplo de acesso ao Gfarm após declaração de “LD_PRELOAD”...... 125 Quadro 29 – Uso do Gfarm via shell interativo...... 126 Quadro 30 – Exemplo de uso de “gfwhere”...... 127 Quadro 31 – Exemplo de uso de “gfrep” para 2 cópias (gfrep –N 2)...... 127 Quadro 32 – Exemplo de fragmentação e armazenamento com “gfimport_text”...... 128

LISTA DE TABELAS

Tabela 1 – Benchmark – metasrv - LOCAL...... 151 Tabela 2 - Benchmark – smbsvr - LOCAL...... 152 Tabela 3 – Benchmark – dfsvr1=dfsrv2 -VMs - LOCAL ...... 153 Tabela 4 - Benchmark – dfsvr3 - LOCAL...... 154 Tabela 5 – Benchmark – dfsvr4 - LOCAL ...... 155 Tabela 6 – Benchmark – gfwks - LOCAL ...... 156 Tabela 7 – Benchmark – Gfarm 1.2-5 (1.2 PL4) – 4 nós - smbsvr...... 157 Tabela 8 – Benchmark – Gfarm 1.2-5 (1.2 PL4) – 4 nós – atraso de 250ms para o metaserver ...... 159 Tabela 9 – Benchmark – Gfarm 1.3.1 – 4 nós ...... 161 Tabela 10 – Benchmark – Gfarm 1.3.1 – 4 nós - atraso de 250ms para o metaserver...... 163 Tabela 11 – Benchmark – Gfarm 1.3.1 – smbsvr – 4 nós – atraso de 250ms para o metaserver -com cache...... 165 Tabela 12 – Benchmark – Gfarm 1.3.1 – 4 nós – atraso de 250ms (metaserver) com cache – largura de banda de 56Kbps (dfsrv2)...... 167 Tabela 13 – Benchmark – NFS – cliente dfsrv4 ...... 169 Tabela 14 – Benchmark – cliente Windows com acesso a compartilhamento nativo SAMBA ...... 170 Tabela 15 – Benchmark – cliente Windows - acesso ao Gfarm via SAMBA com syscall-hook ...... 171 Tabela 16 - Benchmark – cliente Windows - acesso direto ao SAMBA...... 172 Tabela 17 - Benchmark concorrente Gfarm 1.3.1 – 4 nós e cache em 3 nós - clientes gfwks e smbsvr...... 173

LISTA DE ABREVIATURAS E SIGLAS

API Application Programming Interface ATM Asynchronous Transfer Mode CD Compact Disk CERN Conseil Européen pour la Recherche Nucléaire CIFS Common Internet File System DBMS Database Management System DVD Digital Versatile Disc ou Digital Video Disc DVN Disco Virtual Nacional EXT2 (fs) Second Extended File System GD Grid de Dados GRAM Grid Resource Allocation and Management GSI Grid Security Infrastructure HDF5 Hierarchical Data Format 5 IBP Internet Backplane Protocol I/O Input/Output IDE Integrated Drive Electronics ISO International Organization for Standartization LDAP Lightweight Directory Access Protocol LHC Large Hadron Collider MDS Meta Directory Service MIB Management Information Base MIPS Million Instructions Per Second MONARC Models of Networked Analysis at Regional Centres MPI Message Passing Interface MPP Massive Parallel System MRTG Multi Router Traffic Grapher MVFS Multiprotocol Virtualized File System NAS Network Attached Storage NFS Network File System NTFS New Technology File System OGSA Open Grid Services Architecture P2P Peer-to-Peer PVFS Parallel Virtual File System QoS Quality of Service RAM Random Access Memory RPM Red Hat Package Manager RNP Rede Nacional de Pesquisa RTC Real Time Clock RTT Round Trip Time SAN Storage Area Network SO Sistema Operacional SCSI Small Computer System Interface SMB Server Message Block SNMP Simple Network Management Protocol URL Uniform Resource Locator VM Virtual Machine VMM Virtual Machine Monitor VO Virtual Organization VPN Virtual Private Network

SUMÁRIO

1 INTRODUÇÃO...... 17 1.1 Objetivos...... 20 1.2 Trabalhos relacionados...... 21 1.3 Justificativas ...... 24 1.4 Contribuições do trabalho...... 26 1.5 Materiais e Métodos ...... 26 1.6 Implementação do Gfarm ...... 27 1.7 Obtenção de aplicações e arquivos de teste...... 30 1.8 Obtenção de ferramentas de análise (monitores e benchmarks) ...... 30 1.9 Avaliação do conjunto implementado ...... 32

2 FUNDAMENTOS: TECNOLOGIA, FERRAMENTAS E COMPLEMENTOS...... 34 2.1 Grids ...... 34 2.2 Grids de Dados (GDs) ...... 36 2.3 Sistemas de arquivos ...... 38 2.4 Virtual Machines (VMs)...... 39 2.5 Benchmark - IOzone...... 40 2.6 Emulador de rede...... 44

3 GRID DATAFARM...... 45 3.1 Descrição ...... 45 3.2 Componentes ...... 49 3.2.1 Servidor de metadados – Gfarm Server (metaserver) ...... 49 3.2.2 Nós de armazenamento (file server nodes ou fsnodes) ...... 50 3.2.3 Clientes ...... 51 3.2.4 Servidor de cache do metaserver (gfarm-agent) ...... 52 3.2.5 Segurança...... 52 3.2.6 API de I/O Paralelo ...... 53 3.2.7 Comandos ...... 56 3.3 Gfarm v2...... 57 3.3.1 Novas características implementadas ...... 57 3.3.1.1 Abertura de arquivos em modo leitura/escrita...... 58 3.3.1.2 Advisory File Locking (Controle de travamento de arquivo) ...... 58 3.3.1.3 Atualização consistente dos metadados...... 58 3.3.1.4 Generalização do modelo de agrupamento de arquivos ...... 59

4 MONTAGEM DO EXPERIMENTO...... 60 4.1 O cenário final do experimento ...... 60 4.2 Monitoramento e suporte...... 66 4.3 Criação do DVD com cenário experimental do Gfarm ...... 69 4.4 Procedimentos especiais...... 69 4.4.1 Roteador / emulador NIST Net...... 69 4.4.2 NFS...... 71

5 TESTES, BENCHMARKS E RESULTADOS ...... 74 5.1 Avaliações preliminares ...... 75 5.2 Benchmarks individuais...... 78 5.3 Avaliações de desempenho de alguns comandos básicos sob atrasos e uso de cache .82 5.4 Avaliações de desempenho de conjunto: Gfarm operando – versões 1.2-5 (1.2 PL4) e 1.3.1 ...... 85 5.5 Avaliação comparativa com o NFSv4.fc5...... 90 5.6 Latência ...... 92 5.7 Integração com os clientes Windows ...... 94

6 CONCLUSÃO...... 97 6.1 Sugestões para trabalhos futuros ...... 102 REFERÊNCIAS BIBLIOGRÁFICAS ...... 103 GLOSSÁRIO...... 110

ANEXO A – Guias de instalação/ CONFIGURAÇÃO ESPECÍFICOS...... 112 7 FEDORA CORE 3 SOBRE VM MICROSOFT VIRTUAL PC 2004...... 113 8 INSTALAÇÃO E CONFIGURAÇÃO DO GFARM VERSÃO 1.3.1 - VERSÃO TRADUZIDA E ADAPTADA DE GFARM (2006a) ...... 116 8.1 Instalação e configuração do servidor de metadados (metaserver)...... 116 8.1.1 Instalação do certificado de host (nó) para uso em grandes áreas...... 116 8.1.2 Instalação pelos pacotes binários RPM do Gfarm...... 116 8.1.3 Configuração do servidor de metadados do Gfarm...... 116 8.2 Instalação do servidor de cache de metadados do Gfarm ...... 118 8.2.1 Configuração do servidor de cache de metadados do Gfarm (cacheserver)...... 119 8.3 Instalação e configuração do nó servidor de arquivos do Gfarm (fsnode); e nó client ...... 120 8.3.1 Instalação do certificado de host (nó) para uso em grandes áreas...... 120 8.3.2 Instalação pelos pacotes binários RPM do Gfarm...... 120 8.3.3 Configuração do nó servidor de arquivos...... 120 8.4 Configuração de um nó cliente Gfarm (somente cliente)...... 121 8.4.1 Instalação pelos pacotes binários RPM do Gfarm...... 121 8.5 Configuração do nó cliente...... 122 8.5.1 Configuração para cada usuário ...... 122 8.5.1.1 Instalação de certificado de usuário (somente se usado GSI) ...... 122 8.5.1.2 Criação de diretório home no sistema de arquivos Gfarm...... 122 8.5.1.3 A variável “LD_PRELOAD” (acesso ao Gfarm por aplicações não preparadas)..123 8.6 Teste do sistema de arquivos Gfarm...... 123 8.6.1 Criação de um certificado de proxy de usuário (somente no caso de GSI)...... 123 8.6.2 Comandos básicos – (detalhes nas páginas “man” do Linux)...... 124 8.6.3 Acesso a partir de aplicações existentes (não preparadas) em Linux...... 125 8.6.4 Funções avançadas ...... 126 8.6.4.1 Criação de réplicas dos arquivos ...... 126 8.6.4.2 Processamento paralelo e distribuído ...... 127 9 CRIAÇÃO DE PACOTES BINÁRIOS – TRADUZIDO E ADAPTADO DE TATEBE (2006) ...... 129 9.1 Instalação prévia de pacotes requeridos para a criação dos RPMs...... 129 9.2 Pacotes “gfarm-gsi”...... 130 9.3 Pacotes “gfarm”...... 130 10 ACESSO AO GFARM VIA SAMBA VINCULANDO A BIBLIOTECA SYSCALL- HOOK - TRADUZIDO E ADAPTADO DE GFARM (2006)...... 131 10.1 Pré-requisitos e recomendações para o servidor Samba...... 131 10.2 Script de inicialização do Samba – “/etc/init.d/smb” ...... 131 11 ACESSO A ARQUIVOS POR APLICAÇÕES EXISTENTES (NÃO MODIFICADAS) ...... 135 11.1 Configuração ...... 135 11.1.1 Linux, FreeBSD, NetBSD, Solaris, Mac OS X, HP-UX e Tru64 ...... 135 11.1.1.1 Linux...... 135 11.1.1.2 FreeBSD ...... 136 11.1.1.3 NetBSD...... 137 11.1.1.4 Solaris ...... 138 11.1.1.5 MacOS X...... 139 11.1.1.6 HP-UX...... 139 11.1.1.7 Tru64 ...... 140 11.1.1.8 Configurações independentes de sistema operacional...... 140 11.1.2 Sistema operacional sem o mecanismo de pré-carga de bibliotecas...... 141 11.1.3 AIX ...... 142 11.1.4 Outros sistemas...... 142 11.2 Limitação da biblioteca syscall-hook...... 142 11.2.1 Limitação de acesso de um cliente exclusivo (não tem a função combinada de fsnode) ...... 142 11.2.2 Limitação de acesso de um fsnode ...... 142 11.2.3 Limitação para acessar nomes de commandos a partir de scripts ...... 143 11.2.4 Limitação sobre o shell utilizável...... 143 11.2.5 Limitação dependente do sistema operacional ...... 143 11.2.5.1 Linux...... 143 11.2.5.2 FreeBSD ...... 144 11.2.5.3 NetBSD...... 144 11.2.5.4 Solaris ...... 144 11.2.5.5 MacOS X...... 144 11.2.5.6 HP-UX...... 144 11.2.5.7 Tru64 ...... 144 11.3.1 Semânticas de visualização de arquivo ...... 145 11.3.2 URL estendida do Gfarm...... 145 11.3.3 APIs gfs_hook...... 145 11.3.3.1 Visualização padrão de arquivo...... 145 11.3.3.2 Trocando a visualização de arquivos...... 146 12 INSTALAÇÃO DO CENÁRIO BÁSICO DO GFARM COM VMS...... 147 12.1 Conteúdo do DVD:...... 147 12.2 Criação do cenário básico...... 148

ANEXO B – DADOS DETALHADOS DOS PRINCIPAIS RESULTADOS EXPERIMENTAIS ...... 150

ANEXO C – INFORMAÇÕES SOBRE AS VERSÕES DO GFARM ...... 183 13 INFORMAÇÕES SOBRE AS VERSÕES DO GFARM...... 184 13.1 Versão 1.4 de 13/11/2006...... 184 13.1.1 Características atualizadas...... 184 13.2 Versão 1.3.1 de 07/08/2006...... 185 13.2.1 Novas características ...... 185 13.2.2 Características atualizadas...... 186 13.2.3 Características não suportadas...... 187 13.3 Versão 1.3 de 12/06/2006...... 187 13.3.1 Nota sobre compatibilidade...... 187 13.3.2 Novas características ...... 187 13.3.3 Características atualizadas...... 188 13.4 Versão 1.2.9 de 20/01/2006...... 189 13.4.1 Novas características ...... 189 13.4.2 Características atualizadas...... 189 13.5 Versão 1.2 PL4 de 28/09/2005 ...... 190 13.5.1 Características atualizadas...... 190 13.6 Versão 1.2 PL3 de 12/09/2005 ...... 191 13.6.1 Características atualizadas...... 191 13.7 Versão 1.2 PL2 de 08/09/2005 ...... 191 13.7.1 Características atualizadas...... 191 13.8 Versão 1.2 PL1 de 06/09/2005 ...... 191 13.8.1 Características atualizadas...... 191 13.9 Versão1.2 RC2 de 31/08/2005 ...... 192 13.9.1 Características atualizadas...... 192 13.10 Versão 1.1.1 de 17/05/2005...... 194 13.10.1 Características atualizadas...... 194

1 INTRODUÇÃO

Num mundo tão competitivo quanto o que se enfrenta atualmente, tanto no cenário acadêmico quanto no empresarial, vencem os desafios aqueles que se destacam pela busca do conhecimento em suas áreas específicas, visando não só ao aprofundamento, mas também à inovação que se torna possível com a prática desse conhecimento. A pesquisa na área da computação distribuída, especialmente na computação em grid, envolve conhecimentos multidisciplinares que a tornam um grande desafio, fazendo-a uma fonte rica para o desenvolvimento do profissional desse segmento. Isso ocorre especialmente quando se unem as necessidades acadêmicas e profissionais. Dessa forma, complementam-se as pesquisas acadêmicas em andamento, levando-as ao uso prático tanto pela academia quanto pela indústria. Observa-se que pessoas e organizações de vários segmentos têm dependido de forma crescente da computação, fazendo uso de programas para desempenhar suas atividades, também chamados de aplicações. Nota-se nos últimos vinte anos, uma evolução significativa dessas aplicações quanto às suas características e à demanda por recursos computacionais de processamento e armazenamento. Tal evolução nas aplicações pode ser atribuída às necessidades dos usuários e às tendências tecnológicas da infra-estrutura que as suporta (XU et al. 2004, p.181). Os usuários precisam de ferramentas para atingir seus objetivos dentro dos prazos exigidos pelas organizações, sejam elas da comunidade científica ou da indústria. Tais organizações têm problemas cada vez mais complexos a serem solucionados, com características peculiares às suas áreas de atuação. A solução desses problemas por meio de sistemas computacionais implica na utilização de aplicações cujos modelos possam explorar os recursos de infra-estrutura existentes e suportar o surgimento de novos. Partiu-se anteriormente de modelos monolíticos de aplicações, suportados tipicamente pelos mainframes. Isso tornou a escalabilidade um desafio técnico e financeiro, em função de serem plataformas altamente personalizadas por seus fabricantes, não aderentes a padrões abertos de mercado e com sistema de armazenamento centrado em dispositivos de acesso direto (DAS – Direct Access Storage). Depois, passou-se para a fase dos modelos suportados por plataformas abertas, como os baseados em Windows, Unix e Linux. As aplicações nestes modelos são mais flexíveis, visto não dependerem de sistemas computacionais de alta personalização como os mainframes, mas persistem as limitações de escalabilidade no sistema de armazenamento baseado em DAS. Já nas aplicações cliente/servidor diminui-se muito a dependência do hardware, mas persistem alguns fatores limitantes em termos de escalabilidade e flexibilidade em razão do uso de DAS, e dos frameworks1de software nos quais estas aplicações se baseiam (XU et al. 2004, p.181), como .NET, J2EE e CORBA. Nessa trajetória evolutiva nota-se uma transição, partindo-se de ambientes computacionais host-centric (centrados no computador) em direção aos network-centric (centrados na rede). Considerando a questão de armazenamento, as soluções centradas em rede como NAS (Network Attached Storage) e SAN (Storage Area Network) têm permitido maior flexibilidade, escalabilidade e desempenho. Isso se dá, respectivamente, em cenários de

1 Plataforma de trabalho representada pela organização de diversos componentes de um modelo proposto 18

compartilhamento de arquivos multiplataforma e em serviços de dados para aplicações hospedadas em clusters. No caso das aplicações de cluster em computação de alto desempenho, faz-se necessário que o sistema de arquivos suporte o acesso paralelo aos metadados; também aos dados no todo ou em fragmentos que podem estar distribuídos nos dispositivos de armazenamento segundo algum critério pré-estabelecido. As aplicações neste ambiente podem trabalhar com múltiplas tarefas sobre o mesmo fragmento de dados ou em fragmentos diferentes de um mesmo conjunto, explorando o paralelismo de operações viabilizado pelo cluster. Uma tarefa única também pode estar trabalhando em diversos fragmentos do mesmo conjunto. Portanto, cabe um controle estrito de acesso aos dados, principalmente se eles podem ser modificados de forma concorrente. Características como estas precisam ser suportadas por um sistema de arquivos paralelo, típico em tais ambientes. Derivam-se das capacidades inerentes a ele os aspectos de desempenho e escalabilidade da aplicação, no que tange aos dados manipulados. Um sistema de arquivos com estas características, o qual tem sido fundamento para outras soluções é o PVFS (Parallel Virtual File System) de Ligon III e Ross (1996), aplicável tanto em ambientes de cluster quanto em sistemas NAS escaláveis, como o X-NAS de Yasuda (2003). Contudo, mesmo com essas tecnologias, procura-se garantir a escalabilidade para as grandes aplicações, principalmente nas áreas científica e de engenharia, sem esquecer da área corporativa. Tal fato permite o crescimento do sistema de armazenamento conforme a demanda, garantindo as mesmas premissas de QoS (Quality of Service) e disponibilidade. Isso significa fazer com que diversos elementos de armazenamento sejam vistos como uma estrutura única, expondo um espaço de nomes unificado, que possa se expandir de forma transparente para as aplicações em execução, mediante cada um destes elementos de armazenamento (LIGON III; ROSS, 1996) (YASUDA, 2003). A comunidade científica, notadamente na área de Física, tem requerido níveis de escalabilidade de armazenamento e de análise de dados que dependem da capacidade de integrar tecnologias diversas. Dispersas geograficamente em diferentes instituições que apresentam afinidade entre si, formam grandes ambientes de colaboração. Por exemplo, na área de Física de Altas Energias, um único experimento pode gerar uma quantidade de dados a serem armazenados, da ordem de petabytes ao ano, cuja análise depende de uma capacidade de processamento da ordem de 10 milhões de MIPS (million instructions per second); algo equivalente à agregação de mais de 10 mil PCs Pentium III de 500 MHz (THE TECHNICAL CHALENGES OF ATLAS, 2000) operando em conjunto. O cenário aponta para uma computação intensiva em dados, os quais se originam em diferentes locais ao redor do mundo, como resultado de experimentos científicos ou simulações, passíveis de análise com propósitos diversos por múltiplas instituições (CHERVENAK et al. 2000). Em cada local, usam-se diferentes tecnologias para o armazenamento e processamento de dados, impondo desafios no momento de colocá-los em ambiente de colaboração efetiva. É preciso uma visão de serviço, níveis de abstração que suplantem as diferenças tecnológicas e as distâncias que separam os dados dos seus respectivos locais de análise. A construção da infra-estrutura para suportar tal visão de serviços e abstração na computação intensiva em dados, aliada às necessidades de segurança pertinentes à colaboração, pode ser viabilizada aproveitando-se os conceitos e ferramentas da computação em grid (THE GLOBUS ALLIANCE, 2005), conforme sugerido por Chervenak et al. (2000). 19

Entre esses conceitos e ferramentas da computação em grid encontram-se os grids de dados e os sistemas de arquivos para grids de dados, como o Grid Datafarm, viabilizado pelo Gfarm file system de Tatebe et al. (2001), foco deste trabalho. Com sua proposta de virtualizar recursos computacionais, operando como alocadores dinâmicos, os grids têm sido pesquisados intensamente tanto para aplicações científicas e acadêmicas quanto para as comerciais. Eles se posicionam numa proposta de arquitetura fortemente orientada a serviços, graças a flexibilidade, escalabilidade e capacidade de otimização. Exemplos de aplicações têm sido observados em projetos como o SETI@home2, grids de sensores, TeraGrid, myGrid, GriPhyN e o Projeto OurGrid no Brasil, todos federando capacidades computacionais interconectadas pela Internet, tipicamente empregando múltiplas plataformas de hardware e software, promovendo consolidação e escalabilidade. Entre as capacidades federadas está o agrupamento de unidades de armazenamento que pode ser realizado mediante um sistema de arquivos paralelo e distribuído, acessível com um espaço de nomes unificado, tal como os sistemas de arquivos de grids de dados, representados neste trabalho pelo Gfarm file system. Desta forma, a pesquisa foi desenvolvida mediante estudo teórico a partir de artigos especializados, livros e periódicos, além de um experimento em laboratório, com a implementação e análise funcional do Gfarm File System, uma implementação de referência da arquitetura Grid Datafarm, em condições de rede emuladas pelo emulador NIST Net do National Institute of Standards and Technology. O uso da emulação viabilizou o teste in loco, sem a necessidade de posicionar fisicamente os nós de armazenamento em pontos geograficamente distantes para observar o comportamento do conjunto mediante a variação das condições de comunicação, peculiares a redes de longa distância. O conjunto foi observado ao variarem-se condições de rede como largura de banda e atraso, perante o armazenamento e uso de diversas classes de conteúdo. Foram ainda provocadas falhas nos nós de armazenamento para avaliar a capacidade de tolerância a falhas. Adicionalmente, para explorar as condições reais do emprego em múltiplos sistemas operacionais, dois dos nós de armazenamento foram implementados em máquinas virtuais Microsoft Virtual PC 2004 com Linux Fedora Core 5. Mediante o uso de máquinas virtuais, pretendeu-se observar diferenças no desempenho do sistema de arquivos tanto operando localmente quanto como parte do Gfarm. Além disso, as máquinas virtuais permitiram utilizá-lo mesmo num ambiente homogeneizado na plataforma Microsoft. Esta dissertação está organizada de modo que seu capítulo 1 apresenta os objetivos, as justificativas e as contribuições esperadas, além dos materiais e métodos utilizados para a elaboração da pesquisa e seus resultados. A seguir, no capítulo 2, estão descritos os principais fundamentos e as propostas da computação em grid. Há um especial destaque para os Grids de Dados e algumas implementações importantes no mundo. Ainda neste capítulo, são expostos os principais fundamentos sobre sistemas de arquivos, além da explanação sobre o emulador de rede NISTNet e as máquinas virtuais, elementos tecnológicos complementares do estudo. O terceiro capítulo mostra especificamente a arquitetura Grid Datafarm, com destaque para sua implementação de sistema de arquivos de grid, o Gfarm File System (Gfarm). Os componentes da solução Gfarm são explanados com suas funcionalidades, além das funções que compõem as APIs e os principais comandos a serem acionados com o shell de usuário.

2 Em (FOSTER, 2004) é classificado entre sistemas P2P (Peer-to-Peer). 20

O capítulo 4 relata o experimento com o Gfarm, contemplando o cenário e ações realizadas. O enfoque está na sua instalação e configuração, além da implantação e execução das ferramentas de benchmark e monitoramento. Os resultados, com gráficos gerados pelas ferramentas de benchmark e monitoramento, são apresentados no capítulo 5, e as conclusões finais sobre os resultados se encontram no capítulo 6. Os guias detalhados de instalação, planilhas e gráficos completos se encontram nos anexos A e B, respectivamente. Por fim, o histórico das versões do Gfarm - desde a versão 1.1.1 até a 1.4 - é mostrado no Anexo C.

1.1 Objetivos

Pretendeu-se com este trabalho, entre os objetivos principais:

Implementar o Gfarm num cenário real, elaborado dentro de uma rede produtiva em ambiente de negócios. E com isso, procurou-se: Observar e analisar os aspectos de implementação no que tange à facilidade, praticidade e necessidades computacionais; Avaliar a integração com a plataforma Microsoft para importar e exportar arquivos, tanto em servidores nativos Windows como em servidores Linux com SAMBA (SAMBA, 2005); Observar e analisar o comportamento da solução em redes de longa distância, com nós geograficamente dispersos, mediante o uso de um emulador de rede; Observar e analisar as características de tolerância a falhas ao provocar dificuldades funcionais.

Analisar o desempenho do sistema de arquivos Gfarm, da seguinte forma: Testes com arquivos de biblioteca digital; Realização de testes de benchmark; Análise dos resultados de benchmark.

Analisar a partir dos resultados, sua funcionalidade e aplicabilidade como um sistema de arquivos distribuído de uso geral para a Internet, aproveitando suas características de grid de dados, observando suas peculiaridades, aspectos de implementação e adequação para uso comercial, como repositório de arquivos de uso genérico ou em aplicações de biblioteca digital.

Como objetivo secundário, pretendeu-se observar a funcionalidade do Gfarm ao implementá-lo sobre máquinas virtuais Microsoft, permitindo usar nós de armazenamento baseados em sistema operacional Microsoft Windows XP Professional. Destacam-se portanto: 21

Aspectos de implementação; Aspectos de configuração; Desempenho.

1.2 Trabalhos relacionados

Nos grids de dados, a federação de recursos de armazenamento para depositar os dados para análises posteriores, necessita de elementos como: espaço físico nos meios de armazenamento, uma organização dos dados e uma forma de alcançar e utilizar tais recursos em ambiente de colaboração em larga escala. Diferentes soluções têm sido propostas para suprir essas necessidades. Nem sempre são focadas na computação em grid, mas buscam atender às aplicações que dependem de recursos computacionais similares. Entretanto, além de largo espaço de armazenamento para os dados, organizados, por exemplo, em sistemas de arquivos apropriados, necessita-se de capacidade de processamento, em conformidade com o que se deseja obter destes dados, os quais podem vir de sensores climáticos, experimentos científicos, procedimentos médicos, pesquisas na indústria e documentos eletrônicos. Cada uma dessas classes de dados tem necessidades peculiares às suas aplicações e demandam recursos talvez possíveis somente com a combinação de elementos de processamento e armazenamento. Exemplificando: essa combinação de elementos pode ter como resultado, maior poder computacional para tarefas complexas como manipulação de imagens em vários planos de corte, ou simplesmente a disponibilidade de uma grande área compartilhada como repositório. Uma vez disponíveis os recursos necessários, tem-se ainda diversos controles para que o uso seja feito conforme critérios estabelecidos, de maneira coordenada e por usuários autenticados e autorizados. Quanto maior a abrangência dos recursos e os níveis de colaboração entre seus usuários, maior a necessidade de mecanismos que possibilitem tais controles. Tais mecanismos podem ser providos por sistemas de arquivos como os presentes nos sistemas computacionais (STALLINGS, 2001, p.526-531), mas outras funcionalidades são requeridas devido ao caráter distribuído dos grids de dados, que se formam ao redor de grandes áreas geograficamente dispersas e altos níveis de colaboração. Buscando-se outras propostas de sistemas de arquivos, visando à computação distribuída em larga escala, com suporte ao paralelismo, observaram-se resultados de pesquisas desde os ambientes de cluster até os grids de dados. Esses últimos necessitam de sistemas de arquivos com características peculiares. Alguns foram desenvolvidos para viabilizar unidades NAS escaláveis e redes SAN como Yasuda (2003) ao propor o X-NAS, um sistema NAS altamente escalável para clusters, que agrega unidades NAS de pequeno porte. Para isso foi proposto o sistema de arquivos multiprotocolo MVFS (Multiprotocol Virtualized File System) baseado em NFS. Ele é composto por unidades de armazenamento que interagem entre si num relacionamento pai-filho, suportando múltiplos protocolos, tal como o SMB (Server Message Block). Seguindo a proposta do X-NAS, Yasuda et al. (2005) apresenta algum tempo depois o RX-NAS, que ganhou características de tolerância às falhas não contempladas na solução anterior. Não se trata apenas de um sistema de arquivos, mas de uma proposta completa de NAS para clusters. 22

Estes sistemas de arquivos podem influenciar a disponibilidade, escalabilidade e desempenho do sistema computacional em ambiente distribuído, sendo determinantes para adequá-lo aos requisitos das aplicações que irá atender. Nesta direção observa-se o GPFS de Schmuck e Haskin (2002), desenvolvido pela IBM para suportar aplicações em computação de alto desempenho, presente nos maiores clusters em operação. Trata-se de um sistema de arquivos paralelo de disco compartilhado, disponível para IBM RS/6000 SP e clusters em Linux. Várias destas soluções têm fundamentos em Ligon III e Ross (1996), que introduziu uma das principais propostas de sistema de arquivos paralelo, o PVFS (Parallel Virtual File System) da Universidade de Clemson, cujas características foram consideradas no próprio Gfarm. Com o PVFS, destacam-se os fundamentos sobre a classificação “paralelo” para um sistema de arquivos e, também, como isso pode melhorar os ambientes distribuídos de armazenamento. Ligon III e Ross (1996) trazem uma versão inicial do sistema, obsoleta. A proposta foi apresentada em 2000, numa versão melhorada, como pode ser visto em Carns et al. (2000). Sua segunda versão, o PVFS2, é apresentada em (PVFS2, 2003), um guia em formato eletrônico. Ainda nos princípios do PVFS, Lombard e Denneulin (2002) propõem o NFSP. O seu objetivo é agregar o espaço em disco disponível nos vários nós que compõem um sistema em cluster de estações de trabalho, usando como base o NFS. No próprio título, o artigo sugere um servidor NFS distribuído para um cluster de estações de trabalho. Como peculiaridade, a implementação do NFS não é alterada, pois é executada uma camada de serviço de metadados que irá receber as chamadas e modificar a resposta para os “clientes”, de forma que eles se direcionem ao nó que contém o arquivo desejado. Observa-se que nem sempre as soluções se fundamentam num sistema de arquivos, e buscam um caráter menos rígido na estrutura de armazenamento, como em Bassi et al. (2002a), que discutem o IBP (Internet Backplane Protocol), base da Rede Logística que visa sintetizar as funções de rede e armazenamento. O IBP procura aliar as características que garantem simplicidade ao IP (Internet Protocol) a uma solução de armazenamento global distribuído que permita o compartilhamento de arquivos em larga escala, provendo a infra- estrutura para suportar diversas classes de serviço. Com essa solução, os inúmeros nós de armazenamento formando uma rede logística, são vistos como repositórios distribuídos de bytes agregados como exNodes (BASSI et al. 2002b). Nesse caso não se considera prover capacidade de processamento, sendo o objetivo principal federar espaço distribuído, formando, por exemplo, um grande disco virtual para propósitos diversos, como em DVN, (2006). Já no San Diego Supercomputer Center foi desenvolvido o SRB (Storage Resource Broker). Trata-se de uma solução baseada num middleware cliente/servidor, realizando uma abstração do mapeamento lógico-físico do armazenamento de massa - em disco ou fitas - cujo propósito é o gerenciamento de dados distribuídos, com suporte a conjuntos de dados replicados. Seu uso tem sido observado em projetos no mundo todo como o CMS Data Challenge e o BIRN (Biomedical Informatics Research Network), e destacadamente em vários projetos do UK e-Science (UK e-Science, 2006), como um elemento central na viabilização de grids dentro da estratégia de Tecnologia da Informação segundo Berrisford et al. (2005). 23

O SRB emprega como componentes um catálogo de metadados (MCAT) baseado tipicamente num DBMS (Database Management System), como por exemplo, o Oracle, servidores de armazenamento (SRB Servers) e clientes (SRB Client). Ainda segundo Berrisford et al. (2005), apesar da funcionalidade conseguida, a implementação de um grid com SRB em ambientes produtivos não é trivial devido a fatores como a confiabilidade, a robustez, a segurança e a disponibilidade, requerendo planejamento prévio. Em outra proposta, um sistema de arquivos escalável aliado à computação intensiva em medicina foi mostrado por Tárraga (2001). Nesta sua tese de doutorado, Tárraga demonstra a implementação do servidor Teraserver, idealizado para diagnósticos por imagem. Trata-se de uma aplicação que permite que médicos-pesquisadores ao redor do mundo possam acessar imagens digitalizadas de diagnósticos médicos por imagem em 3D, escolhendo planos de corte para uma visualização personalizada. Isso contempla uma aplicação que faz análises e cálculos complexos em grandes arquivos armazenados, os quais devem ser disponibilizados para acesso em tempo real. A solução baseia-se na distribuição de arquivos em fragmentos pelos vários servidores de armazenamento, além de uma ferramenta chamada CAP (Computer Aided Paralelization), cuja função é segmentar aplicações seqüenciais em várias tarefas que permitam execução em paralelo. Pesquisar grandes massas de dados também foi uma das motivações de Ghemawat, Gobioff e Leung (2003). Eles apresentam um dos importantes sistemas de arquivos distribuídos da atualidade, o Google File System (GFS), desenhado e implementado por profissionais do próprio Google, para suprir necessidades peculiares aos serviços prestados pela empresa de busca. Entre elas estão as aplicações de ação intensiva em dados, com grande volume de acesso para leitura de grandes arquivos, tipicamente em fluxo contínuo e para múltiplos usuários. As operações de escrita são basicamente de criação de novos arquivos ou adição esporádica de dados, ou seja, dados já gravados são raramente regravados. O volume típico de acesso geralmente suplanta a quantidade de cache, que acaba se tornando pouco útil e uma preocupação de projeto a menos, já que seu uso nos “clientes”3 implicaria em controle de consistência, tornando o sistema de arquivos mais complexo. Um dos destaques da solução é a segmentação de arquivos em partes de tamanho fixo chamadas chunks, a serem armazenadas em diferentes nós. Utiliza um conjunto de APIs familiar, segundo seus criadores, porém não aderentes ao padrão POSIX, as quais devem ser invocadas pelas aplicações “cliente” para o acesso ao sistema de arquivos. Entre as propostas similares citadas pelos criadores em comparação ao Google File System estão: xFS, AFS, Swift, Intermezzo, GPFS, GFS de Minnesota e Frangipani. Adiciona-se à lista o NASD de Gibson et al. (1998), ao qual a arquitetura do GFS mais se aproxima, porém implicando em modificação nos dispositivos de armazenamento, assim como ocorre com o GFS de Minnesota. Quanto aos sistemas de arquivos de grid, precisam incorporar algumas funcionalidades presentes em outros sistemas de arquivos como os explorados até aqui. O grupo de trabalho Grid File System Working Group (GFS-WG) do Global Grid Fórum tem trabalhado na definição das necessidades e funcionalidades dessa nova classe de sistema de arquivos para os grids de dados.

3 Refere-se ao cliente de rede 24

Os grids de dados têm sido classificados recentemente em Venugopal, Buyya e Ramamohanarao (2005), onde foram consideradas as características que os diferem entre si, como por exemplo, na finalidade, na replicação, no transporte de dados, e na organização do espaço distribuído, que não necessariamente emprega um sistema de arquivos. Nessa taxonomia dos grids de dados, de Venugopal, Buyya e Ramamohanarao (2005), o Gfarm aparece destacado pelos mecanismos empregados pelos seus criadores na função de replicação de dados, considerada em vários grids como solução de tolerância a falhas, melhoria de desempenho ou ambos. Os grids de dados e seus sistemas de arquivos fazem parte de pesquisas ainda em andamento, com alguns resultados preliminares já alcançados, como a definição de arquitetura para os sistemas de arquivos de grid, presente em Jagatheesan (2005). Ressalta-se que, comparado a estas propostas e soluções, o Gfarm é único, provendo um grid de dados que dispõe da abstração de um sistema de arquivos de grid, paralelo e balanceado, visando federação de armazenamento e processamento localizado. No SC05 – International Conference for High Performance Computing, Network, Storage and Analysis (SC05, 2005) – num dos desafios da série StorCloud, foi premiado como o uso mais inovador do armazenamento de dados no suporte à Ciência, tendo sido criado visando uma infra-estrutura de armazenamento flexível e de alto desempenho (HPC WIRE, 2005).

1.3 Justificativas

Há várias pesquisas relacionadas com os assuntos tratados neste trabalho, ainda que algumas não diretamente, desde o surgimento dos grids no início dos anos 90. Entre elas estão as pesquisas de Lombard e Denneulin (2002), MPI Forum (2005), Yasuda et al. (2005), Schmuck; Haskin (2002) e Pereira et al. (2004). A proposta de organizações virtuais de Foster (2001), no contexto da computação distribuída, trouxe inúmeros desafios que vão desde a infra-estrutura, até a definição dos serviços de alto nível para as aplicações de usuários de diferentes instituições, unidos pela afinidade de trabalho primeiramente em questões científicas. Num documento recente, em forma de carta para o NSF (National Science Foundation) (BELL, 2005), pesquisadores do Research Center da Microsoft alertam para a tendência forte da área científica na direção da computação intensiva em dados. Eles fazem considerações sobre os princípios de localidade em função da massa de dados que será manipulada pelas aplicações dessa área, e as necessidades de sistemas de arquivos para suportá-las. O volume de armazenamento necessário tem sido crescente e, em certos casos, como em Tatebe et al. (2004), já se fizeram projeções que implicaram no desenvolvimento de um sistema de arquivos global, que permitisse federar a quantidade necessária de espaço aliada à capacidade de processamento. O objetivo fora pesquisar informações no interior de enormes massas de dados geradas por experimentos de Física de Partículas no CERN. Federar capacidade de armazenamento, tratando-a como um grande espaço único, ou seja, virtualizando a infra-estrutura que a viabiliza, tem sido um objetivo a ser alcançado já nos ambientes de cluster, os quais passam a ser autênticos front-ends de armazenamento como em Schmuck e Haskin (2002); proposta que acabou sendo incorporada às soluções da 25

IBM. Contudo, clusters são soluções tipicamente estruturadas para operar em local único e desenvolvidas especificamente para determinadas plataformas de hardware e software. Já as soluções de federação de dados para grids ultrapassam limites organizacionais, que requerem, além das tecnologias de interconexão e interoperabilidade, a possibilidade de determinar quais os recursos, como serão agregados, acessados e por quem. No caso peculiar dos grids, que são considerados um novo paradigma de computação distribuída, aquilo que se aplica aos clusters em termos de agregação de recursos pode ser solução. Assim, em Tatebe et al. (2004) observa-se uma implementação de grid de dados com o Gfarm, a qual viabiliza a virtualização do armazenamento em nível global, com espaço de nomes único e atendendo às questões de autenticação e autorização de acesso aos recursos compartilhados, inerentes às necessidades da computação distribuída em larga escala. O Gfarm considera ainda o paralelismo no sistema de arquivos e no processamento, requeridos para manipulação de grandes massas de dados, respeitando o princípio da localidade e dirigindo o processamento para os nós mais próximos. A solução se apresenta então como uma possível alternativa de implementação tanto em grids científicos como em comerciais. Ainda que não tenha sido feito para aplicações de acesso paralelo concorrente em operações de edição de arquivos, as quais requerem controle de travamento e consistência de cache, tem potencial como um sistema de arquivos distribuído para acesso paralelo a arquivos de grande tamanho. Tais arquivos são tradicionais em aplicações de biblioteca digital, mineração de dados e simulações. Com suas características, pode ter aplicabilidade como um sistema de arquivos da Internet, provendo funcionalidades adicionais como o paralelismo de processamento e I/O, além da federação dos elementos de armazenamento organizada num espaço de nomes unificado; sendo capaz de prover escalabilidade e desempenho em aplicações genéricas ou de biblioteca digital, as quais não são exclusivas da comunidade científica. O Gfarm é uma realidade, já premiado (HPC WIRE, 2005) como o uso mais inovador do armazenamento de dados no suporte à Ciência, mas ainda não foi avaliado como solução em ambientes computacionais de uso comercial, em empresas de qualquer tamanho. Os testes documentados têm sido realizados em ambientes de alta capacidade de processamento e armazenamento, visando as aplicações científicas, onde a presença de clusters para computação de alto desempenho é tradicional, deixando uma lacuna de avaliação que é a implementação em cenários de infra-estrutura mais comuns no uso comercial. Assim, cabe uma avaliação da sua implementação quanto aos seguintes quesitos: Necessidades operacionais; Configuração; Facilidade de implementar; Replicação de dados; Tolerância a falhas; Integração com plataformas existentes; Funcionalidade; Desempenho.

1.4 Contribuições do trabalho

Quanto às contribuições, complementaram-se as pesquisas sobre o Gfarm no que tange aos aspectos de implementação e desempenho, considerando fazê-lo sobre uma infra- estrutura já existente, multi-plataforma e com diferentes tecnologias. Mediante dados de avaliação coletados e analisados, foi possível classificá-lo como sistema de arquivos distribuído de uso geral para Internet, integrado com outros sistemas de arquivos de rede tradicionais, como os encontrados nos servidores de arquivo baseados em SMB - Microsoft ou Linux com Samba. Adicionalmente, a pesquisa comprova a funcionalidade do Gfarm quando seus nós de armazenamento são implementados em VMs, mostrando a capacidade de virtualização que elas podem conferir aos grids e a facilidade de implementação sem alteração do ambiente operacional. A pesquisa também contribui disponibilizando dados que mostram o comportamento da solução mediante a variação das condições de comunicação, considerando um ambiente de rede de longo alcance emulado. Por fim, é confirmada a capacidade de tolerância a falhas no caso de indisponibilidade dos nós de armazenamento. Como contribuições suplementares, os principais guias de instalação e configuração foram traduzidos para a língua portuguesa e foi criado um DVD contendo as máquinas virtuais pré-configuradas, além de um conjunto de mínimo de programas e arquivos de teste para experimentar o Gfarm.

1.5 Materiais e Métodos

Por se tratar de uma solução real, desenvolvida inicialmente em ambiente acadêmico e para fins científicos, buscou-se atingir os objetivos primários e específicos desse trabalho mediante:

Pesquisa teórica; Implementação de experimento com o Gfarm; Obtenção de aplicações e arquivos de teste; Obtenção de ferramentas de análise (benchmarks); Avaliação do conjunto implementado, com a coleta de dados.

Para ilustração do processo, foi diagramada a articulação do trabalho, conforme a figura 1, a seguir: 27

Figura 1 - Articulação do trabalho

1.6 Implementação do Gfarm

Para a avaliação do Gfarm, foi implementado um cenário real mesclando parte de um ambiente corporativo de pequeno porte, com equipamentos implantados em laboratório para esta finalidade.

Figura 2 – Cenário inicial de implementação do experimento

O cenário da figura 2 corresponde à parte da rede de computadores da Coverex Informática, a qual é utilizada para aplicações de automação de escritório, compartilhamento de arquivos e colaboração em grupo como:

Correio eletrônico; Edição de texto; Planilhas eletrônicas; Apresentações eletrônicas; Envio e recebimento de fax; Acesso compartilhado à Internet; Portal corporativo acessível pela Internet.

Adiciona-se à lista um sistema de gestão de suporte (SAT), cuja arquitetura é cliente/servidor em duas camadas, utilizando banco de dados relacional na retaguarda. Toda a infra-estrutura de software se baseia em produtos Microsoft, sendo o servidor viabilizado pelo pacote Small Business Server 2003. Os componentes do cenário foram arranjados e preparados de forma a garantir similaridade com um grid de dados tradicional usado na comunidade científica, o qual possui múltiplos nós de armazenamento de diferentes tecnologias, dispersos e localizáveis por um serviço de diretório. 29

A obtenção do Gfarm ocorreu por download via Internet, a partir do site http://datafarm.apgrid.org/software/, considerando inicialmente sua versão 1.1.1 e o uso do Fedora Core 3 como sistema operacional. As versões do Gfarm e dos Sistemas Operacionais (SO) sofreram várias atualizações desde o início dos testes, considerando-se neste trabalho até a versão 1.3.1 do Gfarm, de 07/08/2006, a qual suporta o Fedora Core 5, além de outros SOs. As funcionalidades e respectivos módulos instaláveis de acordo com as versões estão no quadro 1.

Funcionalidade Módulos necessários Servidor de metadados gfarm-gsi-libs, gfarm-gsi-server Servidor de cache de metadados gfarm-gsi-libs, gfarm-gsi-gfarm_agent * a partir da versão 1.3.1 * Nó do sistema de arquivos gfarm-gsi-libs, gfarm-gsi-fsnode, gfarm-gsi-client Cliente do sistema de arquivos gfarm-gsi-libs, gfarm-gsi-client, gfarm-gsi-doc Quadro 1 – Funcionalidades e respectivos módulos do Gfarm (versões 1.1.1 até 1.3.1) Fonte: (GFARM, 2005); (GFARM, 2006b)

Dentre as estações de trabalho utilizadas nesta rede, foram tomadas duas para fazer parte do experimento, operando como nós do sistema de arquivos. A rede de comunicação utilizada foi Switched Ethernet de 10/100Mbps nos ramos produtivo e de laboratório. Esse último foi acrescentado ao conjunto exclusivamente para o experimento. Contudo, para avaliar o comportamento mediante as condições de comunicação às quais os grids estariam sujeitos, como limitação na largura de banda e atraso de pacotes, a rede foi expandida com o uso do emulador de rede customizável NIST Net, do National Institute for Standards and Technology – disponível para download em http://www- x.antd.nist.gov/nistnet/dist/nistnet.2.0.12b.tar.gz. A versão em questão é de 01/11/2004, para Linux com Kernel até a versão 2.4.xx. Entretanto, vale ressaltar que tais comportamentos adversos em rede local podem aparecer como conseqüência de defeitos. Isso não inviabiliza ou diminui a importância do uso do emulador ainda que todo o grid esteja confinado dentro uma área geograficamente contida, tendo à sua disposição uma rede de alta velocidade.4 Como o cenário de teste foi montado sobre uma rede já constituída e produtiva baseada no Microsoft Windows, sendo o Gfarm baseado em Linux, foi utilizada a tecnologia de VMs. A camada de virtualização foi realizada pelo produto Microsoft Virtual PC 2004 sobre o sistema operacional Microsoft Windows XP Professional. Ainda por se tratar de teste viabilizado sobre uma infra-estrutura produtiva, houve o estabelecimento de comunicação do Gfarm com o servidor de arquivos Microsoft Small Business Server 2003 e com um servidor SAMBA sobre Linux. Deve ser observado que não se utilizou um cluster na implementação, apesar do Gfarm suportar o seu uso. Foram relatados os processos de implantação, compreendendo instalação e configuração dos produtos, além dos ajustes necessários, aplicação de correções e outras ações em função da personalização da solução.

4 Igual ou superior a 100Mbps – Fast Ethernet em rede local 30

1.7 Obtenção de aplicações e arquivos de teste

Para exercitar o conjunto do experimento e a funcionalidade do Gfarm, de forma a coletar os dados necessários, foram utilizados conteúdos gerados automaticamente pela ferramenta de benchmark, acrescentando-se alguns típicos de bibliotecas digitais5, tais como: Arquivos de vídeo (até 512 MB de tamanho); Arquivos texto (até 50 MB) e; Arquivos em formato PDF entre (até 50MB).

Nestes casos, os arquivos foram importados de outros sistemas de arquivos, principalmente a partir de NFS, SAMBA ou SMB, integrando diferentes plataformas. A importação foi realizada pelas ferramentas que fazem parte do pacote Gfarm, disponível para download em . As aplicações “cliente” para utilizá-los foram: Mplayer (Linux); Windows Media Player (Microsoft) ou Real One (Real Networks) Microsoft Word ou Wordpad em formatos RTF ou TXT. Adobe Acrobat Reader 7

1.8 Obtenção de ferramentas de análise (monitores e benchmarks)

Para coleta de dados e aferição do comportamento do experimento, foi considerado o uso de ferramentas de benchmark e monitoramento, além das oferecidas junto com o Gfarm, cujos objetivos são mais monitorar que realizar medidas de desempenho. No Gfarm seriam dois pacotes: glogger; gmonitor.

Contudo, em monitoramento, foi empregado o MRTG (Multi Router Traffic Grapher) (MRTG, 2006) para acompanhar o tráfego de rede e níveis de utilização de CPU, memória e disco, dos nós utilizados no experimento. Quanto à questão de benchmark, o desafio foi conseguir ferramentas disponíveis para download gratuito que suportassem o modo de operação do sistema de arquivos Gfarm, coletando dados do funcionamento em conjunto, ou seja, como um sistema de arquivos distribuído e paralelo que emprega um servidor de metadados; considerando sua utilização como um sistema de arquivos genérico para a Internet. Foram encontradas algumas soluções como:

IOzone – disponível em http://www.IOzone.org/src/current/IOzone-3- 248.i386.rpm. Realiza testes em sistemas de arquivos locais, e distribuídos baseados no NFS;

5 Considerados como de biblioteca digital, apesar da limitação de tamanho. 31

Bonnie++ - disponível em http://www.coker.com.au/bonnie++/. Similar ao IOzone;

PRIOMARK – disponível em http://www.ipacs- benchmark.org/download/priomark/0.9.1/priomark_0.9.1.tar.gz. Realiza testes em sistemas de arquivos paralelos, suportando tanto o padrão de interface POSIX quanto o MPI, configurável na montagem e instalação;

Scalable I/O Project – Lawrence Livermore National Laboratory IOR – disponível em ftp://ftp.llnl.gov/pub/siop/ior/. Realiza testes em sistemas de arquivos paralelos, baseados nos padrões de interface POSIX, MPIIO e HDF5; fdtree – disponível em ftp://ftp.llnl.gov/pub/siop/fdtree/. Realiza testes de desempenho em dados de sistemas de arquivos; mdtest – disponível em ftp://ftp.llnl.gov/pub/siop/mdtest/. Realiza testes de desempenho em metadados de sistemas de arquivos; simul – disponível em ftp://ftp.llnl.gov/pub/siop/simul/. Realiza testes de operações simultâneas no sistema de arquivos por múltiplos processos, para verificar correção e coerência dos sistemas de arquivos paralelos;

Por questões de praticidade e funcionalidade, optou-se pelo IOzone, que executa as principais operações em sistema de arquivos locais e distribuídos, além de gerar os resultados no formato de importação para planilhas Excel, facilitando a montagem de gráficos ilustrativos. Um exemplo pode ser visto na figura 3.

Escrita - metasvr - LOCAL iozone -Rab Q0_loc_meta.wks -g 256M -i 0 -i 1

60000

50000

40000

50000-60000 40000-50000 Vazão (KB/s) 30000 30000-40000 20000-30000 20000 10000-20000 0-10000

16384 10000 4096 1024 256 0 64 Tamanho do registro (KB)

64 16 128 256 512

1024 4 2048 4096 8192 16384 32768 Tamanho do arquivo (KB) 65536 131072 262144

Figura 3 – Exemplo de gráfico gerado a partir de dados coletados pelo IOzone

1.9 Avaliação do conjunto implementado

Uma vez implementado o cenário da figura 2, foram realizados testes funcionais de todo o conjunto, seguindo alguns procedimentos iniciais: a) Verificação das versões dos pacotes de software instalados; Compatibilidade das versões de Linux (Kernel) dos vários elementos; Versão do pacote Gfarm em cada elemento de acordo com a funcionalidade (nó servidor, servidor de metadados e cliente); Versão do pacote NIST Net; Versão do Virtual PC 2004 (VM); Versão do pacote SAMBA; b) Aplicação das correções necessárias; c) Verificação funcional de cada componente; d) Verificação do espaço em disco necessário para as operações. Pelo menos 1GB livre; e) Controle de data e hora de cada componente: clientes e nós servidores. Devem estar sincronizados para respeitar o sistema de segurança; f) Estabelecimento do sistema de segurança para a operação.

Com relação ao item (f), estão disponíveis no Gfarm dois sistemas de segurança no que diz respeito à autenticação e conseqüente autorização de acesso. A aplicabilidade de cada um depende do grau de confiança que existe no grid implementado. Se ele for constituído por usuários de uma mesma organização ou instituição, pode-se usar o sistema de chave de segredo compartilhado, a qual será gerada e compartilhada de acordo com os recursos disponíveis. Na forma mais prática, mediante uma cópia da chave após sua geração, para cada um dos elementos ativos do Gfarm. Já para um ambiente de grid mais abrangente, envolvendo diferentes organizações, cabe a implantação de sistema de segurança baseado no uso de chave e certificado. Neste caso, o Gfarm prevê o uso de GSI (Grid Security Infrastructure) do Globus Toolkit. No caso específico deste trabalho, como se estava considerando analisar os aspectos funcionais dentro de uma mesma organização, cujos usuários teriam afinidade corporativa, optou-se pelo uso da forma mais simples que é a chave de segredo compartilhado. Com validade de vinte e quatro horas após sua geração, inicialmente foi usado um script para gerá- la e distribuí-la, sempre que os testes ultrapassassem esse prazo ou após períodos de inatividade maiores que um dia. Como foram testadas aplicações de mercado não modificadas, os dados de comportamento e desempenho foram coletados usando-se uma funcionalidade do Gfarm implementada pela biblioteca dinâmica syscall-hook, a libgfs_hook.so. Com ela, pôde-se montar o sistema de arquivos em /gfarm e usá-lo de forma análoga ao NFS, sem a necessidade de recompilações ou modificações nas aplicações. Com estas funções carregadas no ambiente de cada usuário (cliente), os comandos tradicionais do Linux para manipulação de arquivos puderam ser utilizados. 33

Usando este artifício, a ferramenta IOzone foi acionada sobre o diretório virtualmente montado, pretendendo-se exercitar todo o conjunto a partir dele. Isso significa que entre as possibilidades de front-end para acesso ao Gfarm, se optou pelo uso da interface texto via shell do Fedora Core 3/5, a gráfica via browser genérico do Fedora Core 3/5, ou Explorador de Arquivos do Windows XP Professional. O IOzone em modo automático realiza diversas operações como criação, leitura e gravação para frente e para trás, releitura, regravação e remoção, usando arquivos de até 512MB com diversos tamanhos de registro até o máximo estabelecido em 16KB. Para o formato de saída dos resultados se optou por texto delimitado, para ficar compatível com a importação de dados do Microsoft Excel, facilitando a criação de gráficos. Contudo, optou-se por delimitar a abrangência dos testes, eliminando as operações em regime de edição com grande concorrência, já que a proposta do Gfarm é forte em acesso paralelo de leitura, ou seja, ele não foi idealizado para operar em edição concorrente. Tal situação implicaria em controle estrito de travamento e consistência de cache, previstos para a versão v2. Além do IOzone, foram importados arquivos diversos (vide item 1.7) para testes funcionais, principalmente com conteúdo multimídia. Basicamente foram usadas as ferramentas de importação do Gfarm, gfimport-fixed e gfimport-text, as quais permitem importar arquivos oriundos de outras plataformas / sistemas arquivos6. O armazenamento se dá em fragmentos distribuídos entre os nós registrados, viabilizando assim operações de acesso paralelo. Como expansões desse teste, encontram-se as operações de replicação dos dados em pelo menos dois nós, com a ferramenta gfrep, para acompanhar o comportamento de desempenho e tolerância a falhas. Durante o processo de teste pretendeu-se eliminar estrategicamente algum dos nós durante a audiência de um filme para observar a continuidade da operação do ponto de vista da aplicação “cliente”. Adicionalmente se fez alterações nas condições de rede mediante configuração de parâmetros do emulador NIST Net, tais como: Redução da largura de banda para 56Kbps, para um dos nós do primeiro segmento da rede; Atrasos de 250ms até 3,5s na conexão até o metaserver. Ressalta-se que os testes ocorreram utilizando-se nós servidores de arquivos convencionais e viabilizados por máquinas virtuais, visto que, como parte do objetivo secundário deste trabalho, observou-se como um nó servidor de arquivo em máquina virtual afeta o desempenho global sob o ponto de vista da aplicação cliente.

6 Windows Small Business Server 2003 e Linux com serviço SAMBA 34

2 FUNDAMENTOS: TECNOLOGIA, FERRAMENTAS E COMPLEMENTOS

Este capítulo é destinado às explanações sobre os fundamentos teóricos da pesquisa, abordando a computação em grid, os grids de dados e seus sistemas de arquivos, além de ferramentas e acessórios empregados, como o emulador de rede NistNet, as máquinas virtuais e o MRTG para monitoramento.

2.1 Grids

Trata-se de um novo paradigma de computação distribuída, cujo aparecimento se deu por volta da metade dos anos 90. Foster, Kesselman e Tuecke (2001) comentam que as características esperadas da computação em grid passam pela independência de plataforma, capacidade de agregação de elementos computacionais e larga abrangência geográfica. Essas características viabilizam o estabelecimento de VOs (Virtual Organizations), que se formam pelo agrupamento de diferentes organizações, cujos usuários desejam compartilhar recursos para realizar tarefas em comum. A operação com VOs requer nova tecnologia, que Foster, Kesseman e Tuecke (2001) discutem em termos de uma arquitetura de grid com uma organização em camadas, seguindo o modelo de ampulheta. Como a arquitetura do protocolo da Internet se estende da rede até as aplicações, estabeleceu-se um mapeamento entre as duas arquiteturas (figura 4).

Figura 4– A arquitetura de grid em camadas e seu relacionamento com a arquitetura de protocolo da Internet Fonte: modificada pelo autor a partir de (FOSTER; KESSELMAN; TUECKE, 2001, p. 7).

Na extremidade superior fica a camada das aplicações de usuário, cujas necessidades são mapeadas na extremidade inferior, a qual contém os recursos a serem mediados pelos protocolos de grid das camadas superiores. 35

No gargalo da ampulheta se posicionam os componentes cuja função é viabilizar a coleção dos diversos elementos, incluindo ainda os protocolos de comunicação que os integrarão. Os grids visam colocar em colaboração recursos computacionais e usuários que pertencem a diversas instituições ao redor do mundo, de forma que possam participar ativamente em pesquisas ou projetos em várias áreas da ciência. Tipicamente usa-se o termo “federar” para definir o processo de integração dos recursos que viabilizarão a colaboração entre as instituições participantes. Funcionalmente, a computação em grid evoluiu após seu surgimento, como uma arquitetura de serviços aberta e padronizada, fortemente baseada nos conceitos e tecnologias de Web Services (FOSTER et al. 2002). No documento “Physiology of Grid” (FOSTER et al. 2002) é apresentada uma visão funcional dos grids, introduzindo novos conceitos e propostas a partir do documento anterior “Anatomy of Grid” (FOSTER; KESSELMAN; TUECKE, 2001), o qual mostrava uma visão mais orientada a modelo e protocolos. As formas de instanciar os serviços desejados, como disponibilizá-los, por quanto tempo e quem efetivamente pode fazê-lo, tornam os grids verdadeiras fábricas se serviços. Para isso, diversas camadas de software funcionando como middlewares são criadas, de acordo os tipos de serviço a serem disponibilizados, os quais são uma função da natureza dos recursos computacionais que serão federados pelo grid, tais como processamento, armazenamento ou uma combinação de ambos. Além de Web services, conta-se com a implementação de referência Globus Toolkit, que forma a base de construção da proposta de arquitetura OGSA (Open Grid Services Architecture) de Foster et al. (2002), considerada fundamental para a computação em grid. Comenta-se que alguns componentes do Globus Toolkit são relevantes para se chegar a uma arquitetura orientada a serviços, ainda que com menos generalidade do que a conseguida no OGSA (FOSTER et al. 2002). Entre os componentes são citados o GSI (Grid Security Infrastructure) para autenticação, autorização e delegação de acesso, o GRAM (Grid Resource Allocation and Management) para alocação e gerenciamento de recursos, e o MDS (Meta Directory Service) para serviço de diretório. Mais recentemente, Foster e Kesselman (2004) sedimentam os principais fundamentos, destacando as VOs e colocando os grids como serviços de colaboração em larga escala e como viabilizadores da computação ubíqua e virtualizada. Sua característica de promover a virtualização da infra-estrutura, permitindo uma exposição padronizada dos recursos, independente das plataformas que os viabilizam, coloca os grids como solução para a obtenção da computação distribuída plena, em que se agregam capacidades sob demanda dentro e fora dos limites das instituições (XU et al. 2004, p.182). Comenta-se ainda em Berman, Fox e Hey (2002), que os grids, de maneira geral, tornam-se a base para obter uma infra-estrutura computacional de proporções globais. Cerca de seis anos depois da publicação das primeiras propostas, notou-se o aparecimento de inúmeras implementações ao redor do mundo, focadas em diferentes aspectos de colaboração e tecnologias associadas, nas áreas de engenharia, física, química, aeronáutica e entretenimento. Os grids deixam de ser exclusividade da comunidade científica e passam a resolver problemas de colaboração corporativa. 36

Eles também apresentam similaridades em relação às tecnologias P2P7, no que tange aos níveis de colaboração e funcionalidade, integrando pessoas e seus recursos computacionais distribuídos em todo o mundo. O próprio SETI@home, antes um caso clássico da computação em grid, tem sido considerado por Foster e Kesselman (2004), mais uma implementação P2P do que um grid. Esse novo paradigma de computação distribuída, com possibilidades reais de emprego presente e futuro, tem motivado mudanças tanto no cenário científico como no empresarial. Tais aspectos de uso em Foster (2000) e Foster (2002), a aplicabilidade nas aplicações distribuídas em grandes áreas (BAKER; BUYYA; DOMENICO, 2002), grids comerciais e os SLAs (LEFF; RAYFIELD; DIAS, 2003), e o potencial para computação ubíqua (DAVIES; FRIDAY; STORZ, 2004) têm sido considerados. No caso de grids comerciais, observam-se soluções disponíveis da empresa Entropia, cujo foco está em grids de desktops8, da Oracle para seu banco de dados versão 10g e da Sun com o ONE Grid Engine, como exemplo de produtos disponíveis.

2.2 Grids de Dados (GDs)

Basicamente os GDs poderiam ser definidos como grids viabilizados por uma infra- estrutura de software que abstrai uma federação de recursos de armazenamento, o que tipicamente pressupõe o uso de uma arquitetura específica, orientada a aplicações intensivas em dados. Contudo, em Atkinson et al.(2004, p.391-393), comenta-se que essa visão pode levar a uma falsa distinção entre GDs e grids computacionais. Os dados não podem ser vistos como elementos isolados, pois estão presentes numa porção significativa dos grids e, analisá-los substancialmente requer o uso de um conjunto completo de serviços de grid, como computação, rede e segurança. Os GDs não podem mais ser vistos como uma arquitetura específica de grid para aplicações intensivas em dados, mas grids nos quais serviços de gerenciamento de dados estão presentes, entre outros serviços que suportem a operação de VOs. Assim, GDs são considerados neste trabalho como grids focados em dados, cujas funcionalidades são conseguidas mediante o uso de diferentes técnicas para:

Federar os recursos de armazenamento e torná-los acessíveis; Controlar o acesso aos dados em ambiente de compartilhamento; Garantir colaboração em larga escala, incluindo diferentes instituições; Prover o gerenciamento dos dados; Garantir a disponibilidade e integridade dos dados; Prover o transporte dos dados caso estejam distantes da aplicação; Prover a compatibilidade entre o local onde os dados se encontram e a plataforma computacional na qual a sua análise ocorrerá;

7 P2P – Peer-to-Peer 8 Também conhecidos como “estações de trabalho” 37

Suportar plataformas computacionais comuns ou de alto desempenho; Prover o poder computacional necessário às aplicações intensivas em dados; Garantir tolerância a falhas.

Alguns grids focados em dados, como o Grid Datafarm, buscam atender aplicações científicas que manipulam grandes massas de dados coletadas de experimentos ou simulações, demandando o uso de muitos elementos de armazenamento distribuídos, que precisam ser vistos como um recurso unificado. Isso inclui servidores de arquivos tradicionais, dispositivos NAS, SANs e clusters. As infra-estruturas típicas de gerenciamento de dados não contemplam a complexidade e exigência de desempenho dos ambientes de colaboração em larga escala, como nas pesquisas da Física de Partículas, simulações climáticas e sensoriamento. Esses ambientes geram conjuntos de dados da ordem de terabytes, podendo alcançar petabytes, segundo Chervenak et al. (2000), com recursos computacionais diversificados e pessoas, distribuídos por extensas áreas geográficas. Um dos experimentos no LHC (Large Hadron Collider) do CERN (CERN, 2005) - o ATLAS (THE ATLAS EXPERIMENT, 2005) -, é mencionado como o maior esforço de colaboração já tentado nas ciências da Física. Ele envolve 1800 físicos, entre os quais 400 estudantes, distribuídos em mais de 150 universidades e laboratórios em 34 países, todos trabalhando nas novas descobertas em colisão de partículas, a surgirem da análise dos dados coletados dos detectores usados no experimento (THE TECHNICAL CHALENGES OF ATLAS, 2000). Com recursos e pessoas distribuídas dessa forma, os GDs precisam atender a padrões que possibilitem a interoperabilidade entre as instituições, que nem sempre utilizam as mesmas plataformas e soluções para resolver seus problemas computacionais. A arquitetura padrão definida no OGSA do Globus Grid Fórum tem direcionado o desenvolvimento das soluções dos diversos tipos de grids visando à padronização em torno dos conceitos e tecnologias de Web services. Para isso conta-se com o Globus Toolkit para o desenvolvimento de aplicações associadas, incluindo a federação de recursos distribuídos, aspectos de segurança e disponibilidade dos serviços. Segundo Chervenak et al. (2000), para que um Grid de Dados seja constituído efetivamente para atender a tais níveis de colaboração, é fundamental definir uma arquitetura apropriada e a viabilização dos sistemas de armazenamento e gerenciamento de metadados. Entre importantes GDs em operação pode-se citar: myGrid - experimentos in Silico em bioinformática – procedimento que usa repositórios de informação baseados em computador e análise computacional para testar hipóteses, derivar um resumo, buscar padrões ou demonstrar um fato conhecido. Opera tipicamente com movimentos de dados em larga escala e replicação para simulações GriPhyN – emprega tecnologias da computação em grid para projetos científicos e de engenharia, sendo seu objetivo coletar e analisar dados distribuídos na escala de petabytes. As pesquisas que o envolvem buscam a criação de PVDGs (petascale virtual data grids) com o VDT (virtual data toolkit). 38

DVN (Disco Virtual Nacional) – projeto da instituição brasileira RNP (Rede Nacional de Pesquisa) baseado em rede logística de armazenamento, a qual emprega o IBP para federar espaço distribuído em múltiplos nós na Internet.

2.3 Sistemas de arquivos

O sistema de arquivos é uma das partes mais importantes dos sistemas computacionais, responsável pelas estruturas necessárias ao armazenamento de dados a serem utilizados pelas aplicações e respectivos usuários. Com a crescente necessidade de armazenamento nas mais diversas classes de aplicações, como automação de escritório, gerenciamento eletrônico de documentos e principalmente na área científica (THE ATLAS EXPERIMENT, 2005), nota-se a busca pela otimização de uso, desempenho, confiabilidade e escalabilidade dos sistemas de arquivos. A forma como os sistemas de arquivos contemplam estas características tem influência na aplicabilidade que terá o sistema computacional no qual está implementado. Eles são responsáveis por criar uma abstração da infra-estrutura física de armazenamento, provendo uma visão organizada e padronizada dos seus elementos, permitindo assim as operações necessárias à busca, armazenamento e processamento dos dados (STALLINGS, 2001, p.526- 531). Os sistemas de arquivos são tipicamente implementados como parte integrante dos sistemas operacionais, que os utilizam para armazenamento de dados de suas operações, além de utilitários e ferramentas. Nesta sua forma básica, são conhecidos como Sistemas de Arquivos Locais, tais como o Ext2 (Second Extended File System) (CARD; TS’O; TWEEDYE, 1995) e o Reiserfs (REISER4, 2005) do Linux, que trazem conceitos derivados dos sistemas de arquivos do Unix. Já o NTFS (New Technology File System) (MICROSOFT TECHNET, 2003) foi criado para o sistema operacional Microsoft Windows NT e versões superiores. Além deles, passa-se para a classe dos sistemas de arquivos distribuídos, os quais viabilizam o acesso remoto a arquivos armazenados em sistemas de arquivos locais, presentes em servidores interconectados por redes de computadores. Dentro desta classificação encontram-se o NFS (Network File System) (SANDBERG, et al. 1985) do Unix e Linux, o Microsoft SMB (Server Message Block)/CIFS (Common Internet File System) (SNIA, 2002) do Windows e o SAMBA (SAMBA, 2005) como sua alternativa em Linux, cada um com suas características peculiares. Adicionam-se à lista o AFS (Andrew File System), o Coda e o DFS/DCE (Distributed File System/Distributed Computing Environment) que trazem características especiais como espaço global único de nomes e cache persistente, além da operação do cliente em modo desconectado no caso do Coda. Na seqüência da evolução, melhorias no gerenciamento de cache e na operação do cliente em relação ao Coda conduziram ao surgimento do Intermezzo (BRAAM; NELSON, 1999). Expandindo a categoria de sistemas de arquivos distribuídos, devem-se citar os sistemas de arquivos paralelos, que já passam a agregar características peculiares à operação e objetivos dos grids de dados. Os sistemas de arquivos paralelos foram criados para permitir que dados armazenados num único arquivo fossem distribuídos pelos recursos de I/O num cluster, além de prover um 39

mecanismo que permitisse que tarefas de uma aplicação paralela pudessem acessar partes distintas de uma mesma massa de dados. Características como essas, aliadas a uma largura de banda bem dimensionada tendem a garantir um desempenho escalável efetivo de I/O do cluster (LIGON III; ROSS, 1996). Dessa forma, fatores como disposição (layout) dos dados fisicamente diferente daquela esperada pelas aplicações implicam em overheads9 de distribuição e coleta, os quais, aliados à limitação da largura de banda da rede (LIGON III; ROSS, 1996), podem impedir que o desempenho do conjunto e sua escalabilidade em aplicações paralelas sejam alcançadas. São exemplos de sistemas de arquivos paralelos o PVFS (CARNS et al. 2000), o GPFS (SCHMUCK; HASKIN, 2002) da IBM, o Google File System (GHEMAWAT; GOBIOFF; LEUNG, 2003) e o MVFS (YASUDA, 2003). A partir dos sistemas de arquivos paralelos parte-se então para um novo nível de escalabilidade e agregação de recursos em áreas geograficamente mais extensas, envolvendo não só múltiplos servidores e plataformas, mas também diferentes organizações e seus perfis de utilização de recursos. Isso implica numa passagem de “I/O paralelo para I/O de grid” (HUBOVSKY; KUNZ, 2004), principalmente nos ambientes de processamento intensivos em grandes massas de dados. Tais níveis de escalabilidade têm sido contemplados por sistemas de arquivos de grid, como o Gfarm File System, integrante da arquitetura Grid Datafarm. As especificações dos serviços de diretório e arquitetura de serviços desse novo paradigma de sistema de arquivos estão sendo providas pelo grupo de trabalho Grid File System Working Group (GFS-WG) do Global Grid Forum. Entre os membros do grupo está Osamu Tatebe, do grupo de desenvolvimento do Grid Datafarm.

2.4 Virtual Machines (VMs)

Trata-se de uma tecnologia inserida no contexto contemporâneo dos grids, mas com cerca de trinta anos de existência, tendo aparecido na década de 60 na IBM e atingido seu ápice nos anos 70, com a publicação da pesquisa de Goldberg (1974). A tecnologia de VMs existe sob várias formas e aspectos de implementação segundo Smith e Nair (2005), Smith (2005a) e Smith (2005b). No contexto deste trabalho, as máquinas virtuais consideradas são classificadas como VMMs (Virtual Machine Monitor) do tipo hosted VMs, as quais criam uma camada de abstração sobre um sistema operacional base, chamado de Host Operating System (Sistema Operacional Hospedeiro). Elas replicam virtualmente os recursos de hardware conforme a arquitetura ISA (Instruction Set Architecture) de uma única máquina, criando máquinas em caráter virtual que poderão executar outros sistemas operacionais compatíveis, classificados como Guest Operating Systems (Sistemas Operacionais Convidados ou Hospedados). As aplicações são executadas num ambiente próprio, sobre cada um dos “n” sistemas operacionais Guest, sendo “n” dependente da capacidade física disponível na máquina real que hospeda o sistema operacional Host. Tal capacidade física diz respeito ao número de processadores e suas características, quantidade de memória, adaptadores de rede e espaço físico de armazenamento em disco.

9 Vide glossário 40

Tratando-se dos produtos viabilizadores da tecnologia, os VMMs inicialmente considerados para o estudo foram o Microsoft Virtual PC (HONEYCUTT, 2003) e o VMWare Workstation (VMWARE, 2005). Considera-se ainda a existência de VMMs sob a forma de software livre, representado pelo XEN (BARHAM et al. 2003), o qual opera igualmente sobre software livre, todavia sobre distribuições Linux. A tecnologia pode viabilizar a implementação de ambientes de execução virtuais dinâmicos (DVE – Dynamic Virtual Environment) pelos grids, propondo uma codificação da interação necessária para negociar suas criações (KEAHEY; DOERING; FOSTER, 2004). Os recursos necessários são preparados e implementados sobre tecnologias diversas, incluindo a virtualização, com controles e políticas estabelecidas que visam à criação, o monitoramento do comportamento e duração dos ambientes virtuais, usando interfaces de serviço de grid. Na proposta de Keahey, Doering e Foster (2004), a contribuição da pesquisa tem destaque na maior facilidade de administração das VOs, que passam a ter mecanismos de implementação dinâmica dos ambientes de execução de aplicações. Por exemplo, um novo serviço pode ser colocado em funcionamento para execução em ambiente virtual dinâmico, no qual os elementos necessários como espaço de armazenamento, poder computacional ou ambos, são combinados e mapeados para uso empregando plataformas diversificadas. O uso de VMs também pode proporcionar um ambiente de experimentação de uma nova solução - sem modificações significativas no ambiente produtivo - ou um cenário para fins didáticos.

2.5 Benchmark - IOzone

No contexto deste trabalho, são processos definidos de avaliação de quesitos do sistema computacional, cujos resultados podem ser confrontados com níveis pré-estabelecidos ou com dados coletados de outro sistema. Os níveis podem se referir à capacidade de processamento, desempenho do sistema de arquivos e desempenho da comunicação de dados. São realizados mediante a execução de aplicações específicas, ou seja, ferramentas que permitem aferir os diferentes quesitos do sistema computacional. Entre as ferramentas que pudessem se enquadrar no escopo deste trabalho, foram encontradas algumas soluções, destinadas a medir o desempenho de sistemas de arquivos tradicionais, como o Bonnie ++ (COKER, 2005) e o IOzone (NORCOTT, 2005). Ambos foram criados para medir desempenho de sistemas de arquivos locais, trazendo entre suas opções a possibilidade de estender os testes para os ambientes distribuídos, tal como o IOzone em clusters de NFS. Outras foram criadas com o objetivo de atender mais diretamente aos sistemas de arquivos paralelos, tanto em ambientes de cluster quanto em computação distribuída nos grids, como o IOR (SIOP, 2005) e o PRIOMARK (IPACS, 2005). O IOzone é uma ferramenta de benchmark destinada à avaliação de sistemas de arquivos, incluindo sistemas de arquivos locais e NFS (individual ou cluster). Essa avaliação é feita mediante a geração e medição de diversas operações como leitura, escrita e outras, variando-se os tamanhos de arquivo e registros. 41

Os resultados permitem aferir de forma abrangente o desempenho de I/O de uma plataforma computacional, conforme pode ser visto no exemplo de Chilan, (2005). De posse desses resultados pode-se conhecer a adequação da plataforma sendo analisada às aplicações que executará. As operações suportadas pelo IOzone são:

Read (Leitura): mede o desempenho de leitura de um arquivo existente. Write (Escrita): mede o desempenho de escrever um novo arquivo. Ressalta- se nessa operação a necessidade de lidar com os metadados, os quais consistem, por exemplo, em informações de localização física dos arquivos no armazenamento, como diretório e alocação de espaço. Re-read (Releitura): mede o desempenho de ler um arquivo recém lido. Re-write (Reescrita): mede o desempenho de escrita num arquivo já existente. O desempenho tende a ser melhor que o de escrita, pois como os metadados já existem, diminui-se o volume de trabalho da operação. Read backwards (Leitura para trás): mede o desempenho de leitura de um arquivo para trás. Apesar de não ser tradicional, algumas aplicações podem realizar leituras com esse padrão, como a MSC Nastran, que lê grandes arquivos (de GB para TB) dessa forma. Random Read/Write (Leitura / Escrita randômica): mede o desempenho de leitura/escrita com acesso feito a áreas aleatórias de um arquivo. Strided read (Leitura a passos longos): mede o desempenho de leitura de um arquivo, usando um método de passos longos. Por exemplo, uma leitura de 4KB se iniciaria no deslocamento zero, seguida por busca de 200KB e nova leitura de 4KB, repetindo-se o ciclo. fread: mede o desempenho de leitura de um arquivo existente, usando a função de biblioteca “fread()”, que emprega operações de I/O buffered & blocked (usando buffer e blocos). O buffer fica no espaço de endereço de usuário. Esse modo de operação melhora o desempenho, pois diminui o número de chamadas de sistema e aumenta a taxa de transferência quando elas ocorrem. freread: mede o desempenho de leitura de um arquivo recém lido, usando a função de biblioteca “fread()”, que emprega operações de I/O buffered & blocked (usando buffer e blocos). O buffer fica no espaço de endereço de usuário. Esse modo de operação melhora o desempenho, pois diminui o número de chamadas de sistema e aumenta a taxa de transferência quando elas ocorrem. fwrite: mede o desempenho de escrita de um novo arquivo, usando a função de biblioteca “fwrite()”, que emprega operações de I/O buffered & blocked (usando buffer e blocos). O buffer fica no espaço de endereço de usuário. Esse modo de operação melhora o desempenho, pois diminui o número de chamadas de sistema e aumenta a taxa de transferência quando elas ocorrem. frewrite: mede o desempenho de escrita de um arquivo existente, usando a função de biblioteca “fwrite()”, que emprega operações de I/O buffered & blocked (usando buffer e blocos). O buffer fica no espaço de endereço de 42

usuário. Esse modo de operação melhora o desempenho, pois diminui o número de chamadas de sistema e aumenta a taxa de transferência quando elas ocorrem. Mmap: teste especializado que mede o desempenho em usar o mecanismo “mmap()” para as operações de I/º O mecanismo “mmap()” consiste em mapear num arquivo uma área de memória do espaço de usuário. Feito esse mapeamento, dados da aplicação colocados nessa área de memória irão para um arquivo oportunamente, mediante o uso da função “msync()”. Async I/O: mede o desempenho do mecanismo “Async I/O” do POSIX. As aplicações podem usar as interfaces padrão do mecanismo Async I/O do POSIX (exemplos: “aio_write()”, “aio_read()”, “aio_error()”) para as operações de I/O.

O acionamento do IOzone é feito em linha de comando com a sintaxe de uso a seguir:

$ IOzone [-s filesize_Kb] [-r record_size_Kb ] [-f [path]filename] [-i test] [-E] [-p] [-a] [-A] [-z] [-Z] [-m] [-M] [-t children] [-h] [-o] [-l min_number_procs] [-u max_number_procs] [-v] [-R] [-x] [-d microseconds] [-F path1 path2...] [-V pattern] [-j stride] [-T] [-C] [-B] [-D] [-G] [-I] [-H depth] [-k depth] [-U mount_point] [-S cache_size] [-O] [-K] [-L line_size] [-g max_filesize_Kb] [-n min_filesize_Kb] [-N] [-Q] [-P start_cpu] [-c] [-e] [-b filename] [-J milliseconds] [-X filename] [-Y filename] [-w] [-W] [-y min_recordsize_Kb] [-q max_recordsize_Kb] [-+m filename] [-+u ] [ -+d ] [-+p percent_read] [-+r] [-+t ] [-+A #]

A operação da ferramenta pode ser personalizada por várias opções na linha de comando, mas citam-se a seguir aquelas utilizadas para os propósitos deste trabalho. As descrições das demais opções podem ser consultadas em Norcott, (2005).

“-a “: modo totalmente automático. Os resultados cobrem todas as operações dos arquivos testados - exceto quando limitadas por outras opções -, para tamanhos de registro de 4KB a 16MB, em arquivos de 64KB a 512MB (modificável pela opção “- g”).

“-b nome_do_arquivo”: o IOzone cria um arquivo em formato binário contendo a saída das medições, o qual é compatível com o Excel. “-g tamanho_máx_em_KB”: configura o tamanho máximo de arquivo que será gerado pelos testes em modo “-a”. “R”: gera um relatório em formato Excel na saída padrão. O arquivo pode ser importado no Excel (“espaço” é o delimitador) para a elaboração de gráficos demonstrativos do desempenho do sistema. No Excel, por padrão, os gráficos em 3D são orientados a linha, enquanto a saída do IOzone é orientada a coluna. Assim, deve- se alterar essa orientação para coluna ao gerar os gráficos. 43

“-i teste”: indica qual teste será executado. (0=write/rewrite, 1=read/re-read, 2=random-read/write, 3=Read-backwards, 4=Re-write-record, 5=stride-read, 6=fwrite/re-fwrite, 7=fread/Re-fread,8=random mix, 9=pwrite/Re-pwrite, 10=pread/Re-pread, 11=pwritev/Re-pwritev, 12=preadv/Repreadv).

Leitura - metasvr - LOCAL iozone -Rab Q0_loc_meta.wks -g 256M -i 0 -i 1

250000 Efeito do cache de CPU

Efeito do cache de buffer 200000

200000-250000 150000 150000-200000 Vazão (KB/s) 100000-150000 50000-100000 100000 0-50000

Anomalia 50000 16384 2048

256 0 Tamanho do registro (KB) 32 64 128 256 512 Não medido 1024 4 2048 4096 8192 16384 32768 65536

Tamanho do arquivo (KB) 131072 262144

Figura 5 – Gráfico gerado a partir de dados coletados pelo IOzone com principais regiões demarcadas

Um exemplo de resultado do IOzone pode ser observado na figura 5. Tipicamente observam-se de 3 a 4 platôs, os quais se enquadram nas seguintes possibilidades:

O tamanho do arquivo cabe no cache do processador O tamanho do arquivo cabe no cache de buffer O tamanho do arquivo é maior que o cache de buffer

Além dos platôs, os gráficos podem mostrar peculiaridades ou anomalias de desempenho com determinados tamanhos de arquivo e de registro, indicando que cada sistema computacional tem características próprias, respondendo de forma diferente aos diversos tipos de aplicação.

2.6 Emulador de rede

A emulação é definida em Carson e Santay (2003) como a combinação de duas técnicas comuns para testar código de rede: simulação, que ocorre mediante um ambiente sintético para executar representações de código, e teste ao vivo, que ocorre num ambiente real para executar código real. O emulador de rede NIST Net de Carson e Santay (2003) é um dos projetos do NIST (National Institute of Standards and Technology). Trata-se de uma aplicação de função específica, desenvolvida para Linux, destinada a emular o comportamento de uma rede de forma controlada pelo usuário. O ambiente proporcionado pelo NIST Net é semi-sintético, pois mescla um ambiente de rede real, ao vivo, com a possibilidade de introduzir atrasos, falhas e outras dificuldades sintéticas. O controle da emulação é viabilizado por interface gráfica, na qual o usuário pode alterar condições como atraso e perda de pacotes, largura de banda e congestionamento. Para atingir os objetivos, incorpora um driver de controlador de relógio (RTC – Real Time Clock) particular em substituição ao do sistema operacional, para dar maior precisão de resultado às manipulações disponíveis no emulador. O uso do emulador permite ter condições de redes de longo alcance, típicas em grids de dados, sem a necessidade de distribuir geograficamente os nós do grid, aumentando o campo de observação.

3 GRID DATAFARM

Este capítulo mostra a arquitetura do grid de dados Grid Datafarm, além da implementação de referência do seu sistema de arquivos virtual de grid chamado Gfarm. As informações sobre arquitetura foram baseadas em Tatebe et al. (2001) e Tatebe et al. (2002). As modificações esperadas para a versão 2 foram baseadas em Tatebe et al. (2004). Atualmente o Gfarm encontra-se na versão 1.4, a qual não traz mudanças significativas em relação à versão 1.3.1, utilizada neste trabalho. As alterações ocorridas em cada versão podem ser observadas no Anexo C.

3.1 Descrição

O Grid Datafarm é uma implementação de grid de dados, idealizada a partir da necessidade de compor uma infra-estrutura de armazenamento e processamento na escala de petabytes, para análise intensiva de dados de experimentos de física de partículas, conforme Tatebe et al. (2001). Partindo-se do projeto MONARC (Models of Networked Analysis at Regional Centres) (MONARC, 2005), que visa a um ambiente de colaboração para armazenamento e análise dos dados coletados do experimento ATLAS do LHC, a proposta consiste em criar várias camadas10 (tiers) distribuídas e integradas de recursos computacionais, em centros regionais a partir do CERN, que representa a camada “0” (zero). Várias camadas “1” (um) estariam espalhadas pelos continentes, dezenas de camadas “2” (dois) nos países participantes e muitas outras nas universidades e instituições de pesquisa. Originou-se no Japão num trabalho conjunto entre a KEK (High Energy Accelerator Research Organization), ETL/TAC (Electrotechnical Laboratory / Tsukuba Advanced Computing Center), Universidade de Tokyo e Instituto de Tecnologia de Tokyo (Titech). A proposta, aderente ao padrão OGSA, é centrada na computação intensiva em dados, definindo uma plataforma de grande escalabilidade, capaz de tornar efetiva a criação de um Tier-1 do projeto MONARC no Japão, pela federação das instituições KEK e Universidade de Tókio. Os objetivos principais com a proposta são: Sistema de arquivos global para dados na escala de petabytes; I/O paralelo e processamento paralelo para análise de dados; Autenticação e controle de acessos orientados a grupo, em âmbito mundial; Escalonamento e gerenciamento de recursos de milhares de nós em longo alcance; Compartilhamento de dados multi-camadas e acesso a dados eficiente; Compartilhamento e gerenciamento de programas; Administração e monitoramento do sistema;

10 Os termos “Camada” e “Tier” serão usados alternadamente no decorrer do texto. 46

Tolerância a falhas, reconfiguração dinâmica, regeneração automática de dados ou recomputação.

Para atingi-los foi proposta uma implementação de referência de um sistema de arquivos de grid, paralelo e distribuído, de nome Gfarm. Ele é capaz de federar a capacidade de armazenamento de milhares de nós, provendo um espaço de nomes único mediante um servidor de metadados, permitindo fragmentar e distribuir os arquivos por estes múltiplos nós. Isso viabiliza o acesso paralelo e I/O balanceado para as aplicações intensivas de análise de dados. Desenvolvido para execução sobre Linux11, contempla APIs (Application Programming Interface) que permitem criar nas aplicações as chamadas ao sistema de arquivos baseadas em GridRPC, incorporando ainda bibliotecas de funções que criam um ponto de montagem visível a aplicações tradicionais existentes, tal como se operaria no caso do NFS. Um arquivo pode ser gravado no Gfarm como uma entidade única ou pode ser particionado em diversos fragmentos indexados, os quais são distribuídos para os nós de armazenamento desejados. Uma outra opção disponível é registrar no Gfarm vários arquivos sob a forma de um único elemento, ou seja, vários arquivos podem ser combinados e registrados como um só, para posterior processamento. Os arquivos presentes no Gfarm são registrados no servidor de metadados, o qual mantém as informações pertinentes a cada um, acrescidas dos dados de localidade física de cada arquivo ou fragmento. Todas as operações do Gfarm começam ou terminam com o acesso a ele. Na figura 6, podem-se observar os elementos lógicos e físicos, e seu inter- relacionamento.

11 Fedora Core 3 e superior, Debian Woody / Sarge, FreeBSD, SuSE e Solaris 9 são distribuições suportadas 47

Figura 6 – Arquitetura e elementos do Grid Datafarm – Gfarm File System

O Gfarm incorpora mecanismos de replicação de dados por múltiplos nós de armazenamento, além de escalonador cujo algoritmo distribui o acesso de acordo com o nível de carga de trabalho de cada nó, e com a proximidade aos arquivos que serão manipulados (file-affinity). Tais mecanismos garantem tolerância a falhas na eventualidade de algum nó, que contenha parte ou todo o arquivo necessário para um dado processamento, estar indisponível. A tolerância a falhas também é viabilizada pela manutenção de um histórico que permite a reconstrução do arquivo ou fragmento, caso o nó que o continha fique indisponível. Quanto às aplicações que o acessam, é possível registrá-las para execução nos nós, de acordo com a proximidade aos dados que serão processados, sem a necessidade de transportá- los de um ponto a outro. Suportando chamadas que atendem ao padrão MPI, torna viável o processamento paralelo em clusters, tipicamente presentes na infra-estrutura dos ambientes de pesquisa suportados. Todavia, ele se apóia no acesso a conteúdos mais estáticos, nos quais as operações de análise são predominantes em relação às possíveis modificações que os dados possam sofrer. Essa forma de operação é típica das aplicações científicas para análise de dados de experimentos (TATEBE et al. 2001). Assim, o controle de travamento e consistência de cache, tradicionais em sistemas de arquivos paralelos para aplicações de cluster, não são contempladas até a versão 1.3.1 do Gfarm. Para a versão 2 está prevista essa funcionalidade e principalmente o maior suporte às semânticas POSIX. 48

Ele é citado como a próxima geração de sistema de arquivos compartilhados de rede, em substituição ao NFS, na busca por maiores níveis de escalabilidade e desempenho (GFARM, 2005). Na integração com outras plataformas, suporta a operação com serviços de arquivo baseados em Microsoft SMB (Server Message Block) e com a implementação GridFTP de Allcock (2002), presente no Globus Toolkit. Propostas como o Gfarm têm um diferencial por se tratarem da implementação de um sistema de arquivos distribuído e paralelo, cujos arquivos podem ser acessados com diversas interfaces, como via URL própria, shell específico, GridRPC ou por um ponto de montagem similar ao NFS para as aplicações não modificadas. Cada um dos arquivos pode estar armazenado integralmente num único nó de armazenamento ou em fragmentos pré-definidos distribuídos em vários nós. Tais fragmentos podem ser partes de um mesmo arquivo ou vários arquivos que serão combinados com um só, para uso numa aplicação específica. O GridFTP, por exemplo, não oferece essa abstração de um sistema de arquivos típico, no qual uma aplicação pode ler e escrever nos arquivos e não simplesmente trazê-los e enviá-los sob demanda. Seu objetivo é a transferência rápida dos dados em grids de dados, movendo-os de um ponto a outro conforme a demanda, destacadamente na direção do processamento, criando caches locais e se valendo da replicação. Em Allcock (2002), nota-se que ele é uma extensão do FTP tradicional, aliada a novas características como gerenciamento de réplicas, além de acesso paralelo e balanceado. O gerenciamento de réplicas é um dos pontos chave em processamento intensivo em dados, permitindo controlar o posicionamento das massas de dados de forma que fiquem próximas ao local dos recursos de processamento. Isso também garante tolerância a falhas, quando várias cópias da mesma massa de dados podem ser acessadas de diferentes locais de armazenamento dos grids. Segundo a taxonomia dos grids de dados, de Venugopal, Buyya e Ramamohanarao (2005), o Gfarm pode ser classificado quanto à sua organização como de modelo hierárquico, intradomínio, de VO colaborativa, com fontes de dados estáveis e de funcionamento gerenciado. Ainda na mesma taxonomia, seus mecanismos de replicação são classificados como centralizados, utilizando topologia em árvore, com armazenamento fortemente acoplado; o transporte de dados é considerado como “fechado”, com metadados ativos controlados pelo sistema. As atualizações de metadados são executadas de forma assíncrona, a cada operação com os arquivos, sendo o catálogo gerenciado por DBMS (no caso de escolha do PostgreSQL como retaguarda para os metadados). A partir da versão 1.3.1 de 07/08/2006, possui as funcionalidades e respectivos módulos instaláveis conforme o quadro 2.

Funcionalidades Módulos necessários 1 - Servidor de metadados gfarm-gsi-libs, gfarm-gsi-server 2 - Nó do sistema de arquivos gfarm-gsi-libs, gfarm-gsi-fsnode, gfarm-gsi-client 3 - Cliente do sistema de arquivos gfarm-gsi-libs, gfarm-gsi-client, gfarm-gsi-doc 4 – Servidor de cache de metadados gfarm-gsi-libs, gfarm-gsi-gfarm_agent Quadro 2 - Funcionalidades e respectivos módulos do Gfarm 1.3.1 Fonte: (GFARM, 2006)

3.2 Componentes

Observam-se 4 elementos no quadro 2, sendo que 1, 2 e 3 são básicos para construir o Gfarm:

3.2.1 Servidor de metadados – Gfarm Server (metaserver)12

O Gfarm Server é responsável pelo mapeamento “arquivo lógico – arquivo/fragmentos físicos”, o qual é parte dos metadados armazenados no Gfarm Meta Database, compostos ainda do tamanho do arquivo, proteção, estampa de tempo de acesso/modificação, checksum, catálogo de réplicas e histórico. Todos os nós de armazenamento precisam ser registrados no metaserver para que o espaço de nomes global possa indicar e direcionar o acesso ao nó físico no qual o arquivo ou parte dele está armazenado. À medida que novos nós de armazenamento são incorporados ao grid, um registro deve ser feito. Nesse registro, além do nome do servidor, informações sobre o sistema operacional e plataforma de cada nó de armazenamento são incorporadas aos metadados. O Gfarm disponibiliza tanto a visualização global do sistema de arquivos distribuído quanto a local. Essa última visa permitir que os processos de aplicação sendo executados em paralelo, possam trabalhar sobre seus próprios fragmentos da massa de dados, diretamente nos nós de armazenamento aonde se encontram. Do ponto de vista das aplicações, a visualização global faz com que seja enxergado um espaço de nomes único, que faz referências a um conjunto agregado de múltiplos sistemas de arquivos, praticamente sem limites estabelecidos em quantidade e localização geográfica. O metaserver não atua diretamente nas operações com os arquivos, servindo tipicamente como um diretório de sistema de arquivos distribuído. Ao ser acionado por uma aplicação preparada ou um acesso de usuário, ele deve fornecer seus serviços, respeitados os processos preliminares de autenticação e autorização. Os processos paralelos das aplicações em execução são igualmente gerenciados e monitorados por ele. Suas funções são implementadas sobre um serviço de diretório baseado em LDAP, cujo módulo (daemon) a ser executado chama-se slapd. Os arquivos em si não residem nele, mas sim os metadados que contém todas as informações necessárias ao acesso.

12 Os termos “servidor de metadados”, Gfarm server e metaserver foram usados intercambiavelmente 50

Uma aplicação que referencia um arquivo armazenado sob o Gfarm receberá do servidor de metadados o gfarm file_handle, o qual contém a localização física do nó em cujo sistema de arquivos local está o arquivo inteiro, ou dos nós que contém os fragmentos, além dos atributos pertinentes. Se existirem réplicas do arquivo ou de fragmentos em vários nós de armazenamento, o metaserver selecionará qual será usada pela aplicação, de acordo com o algoritmo que considera a proximidade dos dados, a carga de trabalho dos nós onde estão e, a partir da versão 1.3.1, o RTT dos canais de comunicação. Ele também entra em ação no caso de indisponibilidade, já que o estado de cada nó servidor é monitorado, fazendo com que o acesso seja direcionado automaticamente para aquele que está em estado normal e contém uma réplica do conteúdo a ser acessado. Na criação ou modificação de arquivos, os metadados são atualizados somente no fechamento do arquivo/fragmentos pela aplicação, quando todos os processos paralelos foram encerrados e os dados já foram totalmente transferidos para o armazenamento estável. As operações do metaserver são proporcionadas pelo daemon de nome gfmd, que responde pelo serviço Metadata Management System, iniciado automaticamente durante o processo de inicialização do servidor. Quando o slapd e gfmd estão carregados, o servidor fica na escuta em três portas de conexão, de números 600 (TCP, UDP) e 601 (TCP), além da 389 (TCP), que corresponde ao serviço de diretório via LDAP. Na versão 1.3.1, o metaserver pode ser implementado com o PostgreSQL, sendo esse o novo padrão de instalação. O script de configuração precisa ser modificado quando se altera o diretório para LDAP, padrão até a versão 1.2-5 (1.2 PL4). Como o PostgreSQL foi tornado padrão, isso implica na instalação obrigatória dos pacotes referentes a este banco de dados; caso contrário a instalação não tem êxito. Isso é uma premissa, ainda que se opte por usar o LDAP. Como elemento central, ressalta-se que a funcionalidade do sistema de arquivos global do grid, existe tão somente enquanto o servidor de metadados estiver realizando suas operações normalmente.

3.2.2 Nós de armazenamento (file server nodes ou fsnodes)

Tratam-se dos servidores que terão no seu sistema de arquivos local uma área destinada ao armazenamento físico dos arquivos ou fragmentos deles gerenciados pelo Gfarm. Podem ser servidores individuais ou arranjados em cluster. No caso de clusters, o processamento paralelo deve ser via MPI, que é o padrão suportado pelas bibliotecas do Gfarm. Quando um novo servidor é incorporado ao grid, instalam-se nele os respectivos módulos constantes do quadro 2, item 2. A seguir, um arquivo texto especial, de nome “gfarm.conf”, gerado na instalação do metaserver, deve ser copiado para o diretório “/etc” do nó, para que o registro no diretório seja feito com a execução do comando indicado no quadro 3:

“config-gfarm /var/spool/gfarm” - sendo “/var/spool/gfarm” o caminho no sistema de arquivos local. Quadro 3 – Comando para registro de nó de armazenamento no Gfarm

Em razão da presença do algoritmo baseado em file-affinity, os nós de armazenamento implementados pelos módulos do item 2 do quadro 2 requerem a instalação dos módulos de cliente, constantes do item 3. Isto se deve ao fato do algoritmo acionar o nó de armazenamento, a fim de executar análises em massas de dados totais ou parciais que residem fisicamente sob o controle de seu sistema de arquivos local. Um daemon de nome gfsd é carregado automaticamente em cada servidor, o qual faz e recebe as chamadas ao metaserver, fazendo a ponte entre o sistema de arquivo de grid e o sistema de arquivos local. Os aspectos de desempenho referentes à rede de comunicação que interliga os múltiplos nós de armazenamento, como ajuste de janela de congestionamento TCP, tamanho do buffer do socket da transmissão e recepção, e número de fluxos paralelos, são tratados pela comunicação inter-gfsd.

3.2.3 Clientes

Os clientes do Gfarm são em primeira instância os próprios nós de armazenamento, em razão do processamento poder ser empurrado na direção dos dados ao invés do caminho inverso. Se cada servidor é também um cliente, os dados não precisam trafegar pela rede de comunicação, podendo ser processados localmente, conforme o algoritmo de file-affinity. Como citado em 3.32, se eles forem clusters, aproveitar-se-á o processamento paralelo via MPI, aumentando assim o desempenho nas análises pesadas de dados. Para tornar uma estação ou servidor um cliente do Gfarm, deve-se instalar os módulos constantes do quadro 2, item 3. Uma vez instalados, o acesso ao sistema de arquivos pode estar incorporado nas aplicações com as chamadas às Gfarm APIs, além de ser feito com um shell específico, GUI (Graphical User Interface) ou URL (Uniform Resource Locator) conforme o quadro 4:

gfarm:/caminho/nome do arquivo – onde o caminho pode ser o diretório home do usuário

Quadro 4 – URL para acesso ao Gfarm file system

Os usuários podem ainda registrar suas aplicações no sistema para execução em paralelo nos múltiplos nós espalhados pelo grid. Quanto às aplicações não preparadas para as chamadas ao Gfarm, é oferecida a alternativa de vincular bibliotecas de função ao shell do usuário, possibilitando montar virtualmente o diretório raiz /gfarm na raiz do sistema de arquivos local. Basicamente é provida a biblioteca syscall-hook, que intercepta todas as chamadas de sistema de arquivo no ponto virtual de montagem, direcionando-as convenientemente ao 52

Gfarm server. A ação para ativá-la consiste numa declaração LD_PRELOAD no arquivo de configuração respectivo do shell do usuário. Uma vez carregadas as bibliotecas necessárias, as aplicações tradicionais operam nos arquivos sob o Gfarm como se eles estivessem presentes localmente. No caso do cliente ser também um nó de armazenamento, todo o processamento ocorrerá localmente. Sendo somente cliente, o arquivo será trazido para a estação local para que o processamento possa ocorrer. Para a interface gráfica, a biblioteca syscall-hook torna visível o diretório virtual /gfarm nos utilitários de visualização de arquivos do Linux, como o Nautilus, além dos browsers Mozilla, Firefox e Konqueror.

3.2.4 Servidor de cache do metaserver (gfarm-agent)

A partir da versão 1.1.1 conta-se com a possibilidade de usar um cache do servidor de metadados (quadro 2, item 4), evitando alta latência de rede devido a servidores distantes, ou proporcionando melhores tempos de resposta, nos casos de servidores sobrecarregados por múltiplos acessos a sistemas de arquivos com muitos diretórios e objetos. A ativação opcional do cache é realizada com o carregamento do daemon “gfarm- agent” numa estação cliente ou num nó de armazenamento mais próximo. Este último pode se beneficiar do cache por ser obrigatóriamente um cliente do sistema de arquivos. Contudo, é na versão 1.3.1 que o uso do cache torna-se mais prático, trazendo um script de configuração, o config-agent, que inicia o cache e adiciona ao arquivo de configuração do gfarm os parâmetros necessários para o acesso ao agente recém iniciado. Basicamente, os parâmetros apontam um dos equipamentos nos quais o agente foi configurado e ativado. Várias instâncias do agente podem ser executadas numa mesma máquina, como também várias máquinas podem estar executando-o. A consistência do conteúdo de cada uma destas instâncias do cache do metaserver é mantida, tendo sido considerada no projeto.

3.2.5 Segurança

Por se tratar de um ambiente de grid, o Gfarm traz os mecanismos necessários aos processos de autenticação e autorização dos usuários que desejam utilizá-lo, principalmente levando-se em consideração que tais usuários podem ou não fazer parte de VOs (vide capítulo 2). Sua segurança é obtida mediante o uso da infra-estrutura GSI do Globus Toolkit nas aplicações preparadas, a qual prevê o emprego de mecanismo de infra-estrutura de chave, visando a autenticação e logon único para os casos em que o grid se formará em VOs. Nos casos em que se estiver implementando-o dentro de um mesmo controle administrativo, pode-se usar um mecanismo de chave de segredo compartilhado. A chave é gerada com o comando gfkey, disponibilizado pelos criadores do Gfarm. Depois de gerada, deve ser replicada em todos os componentes do grid, pois caso contrário os nós de armazenamento se tornam inacessíveis. Para evitar a cópia da chave num ambiente com muitos nós, pode-se estabelecer um diretório home compartilhado por todos, sendo o NFS um meio de fazê-lo. Nesse caso, não há necessidade de usar gfkey para gerar a chave. Ao fazer o logon, o primeiro nó (usuário) que 53

acessa o sistema de arquivos cria a chave compartilhada no diretório home, fazendo-a acessível a todos.

3.2.6 API de I/O Paralelo

O Gfarm disponibiliza uma interface de programação que torna possível o acesso paralelo ao sistema de arquivos, permitindo atingir uma largura de banda escalável, explorando o I/O local combinado com os servidores de metadados. A exploração do I/O local combinado com os servidores de metadados se traduz em duas visualizações de arquivos possíveis: local e global. A visualização local permite explorar a localidade dos dados, desde que estejam distribuídos em fragmentos indexados através dos nós de armazenamento. Cada fragmento pode ser processado explorando o acesso ao sistema de arquivos local e seus respectivos subsistemas de disco. Como definição, um arquivo Gfarm é um arquivo lógico representado por um nome ou uma URL Gfarm. Cada arquivo pode ser particionado em diversos fragmentos indexados e gravados em diversos discos. O direcionamento até o fragmento desejado é feito mediante o uso da URL Gfarm acompanhada do índice respectivo. Exemplos de URL e nome de arquivo Gfarm:

gfarm:~username/path/name gfarm:/path/name gfarm:relative/path/name

A API, cujas funções e respectivas descrições - agrupadas por tipos de operação - podem ser vistas nos quadros de 5 a 8, referencia os arquivos e fragmentos com o objeto opaco Gfarm file handle13, criado nas operações de abertura, criação, abertura local e criação local. O objeto é liberado tão logo uma operação bem sucedida de fechamento ocorra. Uma vez que um arquivo esteja aberto, todas as operações são direcionadas a ele com o Gfarm file handle.

INICIALIZAÇÃO E FINALIZAÇÃO char* gfarm_init(void) Inicializa o ambiente de execução do Gfarm estabelecendo a conexão com o servidor de metadados char* gfarm_finalize(void) Finaliza o ambiente de execução e desconecta-se do servidor de metadados Quadro 5 – API de I/O paralelo – funções de Inicialização e Finalização Fonte: Criado a partir de (TATEBE et al. 2001, p.6-8)

13 Referenciado como “identificador de arquivo” nas descrições de API. 54

MANIPULAÇÃO DE ARQUIVOS char* gfs_pio_ open (char *url, int index, Abre o fragmento Gfarm identificado pela URL Gfarm url e char *host, int flags, GFS_FILE *gf) índice index no nó Gfarm host, retornando um novo identificador de arquivo Gfarm gf. Se host não for especificado, ele é obtido do Gfarm Meta Database. Flags pode ser GFARM_FILE_RDONLY (abrir só leitura) ou GFARM_FILE_RDWR (abrir leitura/escrita). char* gfs_pio_ create (char *url, int index, Cria um fragmento Gfarm especificado pela URL Gfarm url e char *host, mode_t mode, GFS_FILE índice index com modo de acesso mode (permissões *gf) modificadas pela umask do processo) no nó Gfarm host, retornando um novo identificador de arquivo Gfarm gf. Funções para caso especial típico quando todo nó tem pelo menos um fragmento Gfarm char* gfs_pio_set_local(int index, int size) Estabelece o índice index do fragmento local Gfarm e o número total de fragmentos size. char* gfs_pio_open_local(char *url, int flags, Abre o fragmento Gfarm local identificado pela URL Gfarm GFS_FILE *gf) url e índice index no nó Gfarm host, retornando um novo identificador de arquivo Gfarm gf. Se host não for especificado, ele é obtido do Gfarm Meta Database. Os flags podem ser: GFARM_FILE_RDONLY (abrir só leitura) GFARM_FILE_WRONLY (abrir só escrita) GFARM_FILE_RDWR (abrir leitura/escrita) Como dicas de acesso: GFARM_FILE_SEQUENTIAL (acesso seqüencial) GFARM_FILE_REPLICATION (arquivo pode ser replicado localmente quando acessado remotamente) GFARM_FILE_NOT_REPLICATION (arquivo não pode ser replicado localmente quando acessado remotamente) char* gfs_pio_create_local(char* url, mode_t Cria um fragmento Gfarm local especificado pela URL Gfarm mode, GFS_FILE *gf) url e índice index com modo de acesso mode (permissões modificadas pela umask do processo) no nó Gfarm host, retornando um novo identificador de arquivo Gfarm gf . char* gfs_pio_local_paths_get(char *url, int Retorna uma lista de nomes dos fragmentos locais Gfarm e o *npaths, char ***paths) número total de fragmentos locais do arquivo Gfarm especificado pela URL Gfarm url. char* gfs_pio_close(GFS_FILE gf) Fecha o identificador de arquivo Gfarm gf e atualiza ou verifica o tamanho do arquivo e checksum do Gfarm Meta Database. O checksum permite verificar a identidade de um arquivo mestre e respectiva réplica. Quadro 6 - API de I/O paralelo – funções de Manipulação de Arquivos Fonte: Criado a partir de (TATEBE et al. 2001, p.6-8)

ACESSO A ARQUIVOS char* gfs_pio_read(GFS_FILE gf, void *buf, int Tenta ler até size bytes do fragmento Gfarm referenciado pelo size, int *nread) identificador de arquivo gf no buffer iniciando em buf e retorna o número de bytes lidos nread. char* gfs_pio_write(GFS_FILE gf, void *buf, Escreve até size bytes no fragmento Gfarm referenciado pelo int size, int *nwrite) identificador de arquivo gf no buffer iniciando em buf e retorna o número de bytes escritos nwrite. char* gfs_pio_seek(GFS_FILE gf, file_offset_t Reposiciona o ponteiro inicial do fragmento Gfarm offset, int whence) referenciado pelo identificador de arquivo gf para o argumento offset de acordo com a diretiva whence, a qual pode ser SEEK_SET para estabelecer o novo ponteiro inicial para offset bytes, SEEK_CUR para posicioná-lo na posição atual acrescida de offset bytes ou SEEK_END para posicioná-lo no tamanho do arquivo acrescido de offset bytes. int gfs_pio_getc(GFS_FILE gf) Lê e retorna o próximo caracter de gf, ou EOF no final do fragmento ou erro. int gfs_pio_ungetc(GFS_FILE gf, int c) Coloca c de volta em gf onde pode ficar disponível para as leituras subseqüentes. char* gfs_pio_putc(GFS_FILE gf, int c) Escreve o caractere c em gf. char* gfs_pio_getline(GFS_FILE gf, char *s, Lê no máximo um menos size caracteres de gf e os armazena size_t size, int *eofp) no buffer referenciado por s. A leitura pára depois de um EOF ou nova linha (neste caso um ‘\0’ é armazenado). Se um EOF é lido sem que caracteres sejam lidos, é definido eofp. char* gfs_pio_puts(GFS_FILE gf, char *s) Escreve o conjunto s de caracteres s em gf. char* gfs_pio_putline(GFS_FILE gf, char *s) Escreve o conjunto de caracteres s e uma nova linha ao final em gf. char* gfs_pio_flush(GFS_FILE gf) Força a escrita de todos os dados em buffer para o fragmento Gfarn referenciado por gf. Quadro 7 - API de I/O paralelo – funções de Acesso a Arquivos Fonte: Criado a partir de (TATEBE et al. 2001, p.6-8)

VISUALIZAÇÃO DE ARQUIVO char* gfs_pio_set_view_local(GFS_FILE gf, Muda a visualização que o processo tem dos dados do arquivo int flags) Gfarm URL url para local. Os flags são os mesmos usados como dica para acesso eficiente em gfs_pio_open. char* gfs_pio_set_view_index(GFS_FILE gf, Muda a visualização que o processo tem dos dados do arquivo int nfrags, int index, char *host, int flags) Gfarm URL url, para um fragmento de arquivo com índice index. Se o arquivo for novo, especifica-se o número total de fragmentos nfrags e o nó host. Caso contrário, usa-se como valores GFARM_FILE_DONTCARE e NULL respectivamente. Quadro 8 - API de I/O paralelo – funções de Visualização de Arquivo Fonte: Criado a partir de (TATEBE et al. 2001, p.6-8)

3.2.7 Comandos

Além da API de I/O paralelo, são disponibilizados comandos Gfarm que facilitam a manipulação do sistema. Eles podem ser acionados a partir do servidor Gfarm (servidor de metadados) ou de cada nó de armazenamento. Clientes Gfarm individuais (fora dos nós de armazenamento) podem igualmente acionar comandos Gfarm para manipulação do sistema. Os principais comandos e suas respectivas descrições estão agrupados no quadro 9. A sintaxe de cada um pode ser consultada mediante documentação do Gfarm, instalada opcionalmente.

MANIPULAÇÃO DE METADADOS DOS ARQUIVOS NO GFARM META DATABASE gfls Lista o conteúdo do diretório gfmkdir Cria diretório gfrm Remove arquivos gfrmdir Remove diretório ACESSO E MODIFICAÇÃO - METADADOS E FRAGMENTOS NO SISTEMA DE ARQUIVOS gfchmod Muda as permissões de acesso de um arquivo gfchown Muda a propriedade gfchgrp Muda a participação de grupo gfcp Copia arquivos gfcd, gfchdir Muda o diretório corrente gfpwd Informa o diretório corrente FUNÇÕES COMPLEMENTARES / ADMINISTRAÇÃO gfdf Informa o número de blocos livres e arquivos gfsck Verifica consistência entre os metadados do Gfarm Meta Database e cada fragmento Gfarm e também entre dados mestre e réplicas; e repara sistemas de arquivo gfdigest Mostra seleção de mensagens gfredist Redistribui um arquivo Gfarm no sistema de arquivos Gfarm, para balanceamento de carga gfreg Registra um arquivo no sistema de arquivos Gfarm para aplicações tradicionais sem o suporte do I/O paralelo gfsched Cria uma lista de nós que armazenam fragmentos de um dado URL Gfarm INTEGRAÇÃO COM OUTROS SISTEMAS DE ARQUIVOS gfimport_fixed Importa um arquivo para o sistema de arquivos Gfarm, fragmentando-o gfimport_text Importa um arquivo texto para o sistema de arquivos Gfarm, fragmentando-o gfexport Exporta um arquivo do sistema de arquivos Gfarm, podendo exibi-lo se for aplicável Quadro 9 – Principais comandos Gfarm Fonte: Criado a partir de (TATEBE et al. 2001, p.6-8)

O quadro 9 inclui comandos similares aos utilizados no Unix e outros destinados à administração do Gfarm. Quando se utiliza a biblioteca syscall-hook, de forma que o ponto de montagem /gfarm seja visível, os comandos tradicionais de manipulação de arquivos do Unix/Linux podem ser acionados diretamente, dando o suporte necessário para a administração do sistema de arquivos. Em cada nó de armazenamento, ainda é possível usar os comandos tradicionais de manipulação de arquivos do Unix/Linux sobre o sistema de arquivos local, no diretório configurado durante a criação do nó no Gfarm, já que o diretório fica visível localmente. Essa possibilidade tende a ser controlada na versão 2 (vide 3.3). 57

3.3 Gfarm v2

Trata-se da próxima versão do Gfarm, mantendo a proposta inicial de ser um sistema de arquivos virtual global, cujos principais objetivos são o compartilhamento confiável de arquivos e a computação de dados paralela e distribuída de alto desempenho que pode se estender pelos grids envolvendo diversas VOs (TATEBE et al. 2004). Nesta nova versão, pretende-se a implementação de um sistema de arquivos virtual global que seja totalmente aderente às APIs POSIX, contudo mantendo as propostas da arquitetura Grid Datafarm. Após a criação da versão v1, um protótipo para demonstrar a aplicabilidade do Gfarm na computação intensiva de dados, encontrou-se deficiências quanto à funcionalidade, robustez, segurança e flexibilidade. Funcionalidades como abrir arquivos no modo de leitura/gravação, implementada a partir da versão 1.0.4, e controle de travamento (advisory locking), não foram consideradas no protótipo inicial, por questões de perfil de uso das aplicações típicas da computação intensiva em dados. Todavia, com o amadurecimento de novas possibilidades de uso, características presentes nos sistemas de arquivos distribuídos tradicionais passaram a ser necessárias, além de modificações visando melhorias em relação a eles. Pretende-se com a v2 tornar o Gfarm um substituto para os sistemas de arquivos NFS e AFS, com a possibilidade estendida do I/O paralelo para processamento escalável de dados. Entre as fraquezas consideradas, observou-se que o fato da biblioteca de I/O do Gfarm, responsável pela consistência dos metadados em relação aos arquivos físicos, ser implementada em nível de usuário, panes na aplicação podem significar a quebra da consistência, e conseqüentemente a confiabilidade do mapeamento lógico-físico. Soma-se a isso a possibilidade do usuário ter acesso aos fragmentos e arquivos Gfarm nos nós de armazenamento, sem usar a biblioteca de I/O. Sem passar pela biblioteca, os dados físicos podem ser erroneamente manipulados pelo usuário, quebrando a consistência dos metadados no Gfarm Meta Database. Na v2 pretende-se fazer com que toda operação com arquivos Gfarm seja feita com a biblioteca de I/O, mais precisamente pelo gfsd, evitando assim o uso de ferramentas para corrigir inconsistências, já que se atuará de modo preventivo. A flexibilidade na manipulação de agrupamentos de arquivos também é um dos objetivos da v2. Em certas aplicações científicas, trabalhar com vários arquivos num único programa de análise executando em paralelo é uma funcionalidade desejada. A forma como tal agrupamento é feito deveria ser flexível para abranger as variações de tipos de aplicação. Na v1 isto fora tratado internamente mediante o uso de metadados especiais, diminuindo assim a flexibilidade.

3.3.1 Novas características implementadas

Para solucionar as fraquezas já comentadas em 3.3, com possíveis táticas de projeto, novas características fazem parte do Gfarm v2, principalmente levando-o na direção da compatibilidade plena com o POSIX. Isso irá aproximá-lo dos sistemas de arquivos 58

distribuídos tradicionais, todavia, sem perder as características de sistema de arquivos distribuído virtual global, com capacidade de processamento de dados paralelo.

3.3.1.1 Abertura de arquivos em modo leitura/escrita

Como o Gfarm suporta a operação com réplicas, a abertura de arquivos em modo leitura/gravação implica em manter-se a consistência de dados entre elas. É comentado em Tatebe et al. (2004), que a semântica de consistência entre réplicas é baseada no AFS. Quando um arquivo é aberto, a seleção de réplicas, se existirem, será feita pelo servidor de metadados, evitando assim que duas delas sejam acessadas simultaneamente em modo de escrita. Todos os metadados e réplicas de arquivos inválidas são apagados pelo servidor de metadados no fechamento do arquivo que fora aberto no modo de escrita, pois poderia não ter sofrido qualquer modificação mesmo tendo sido aberto nesse modo. A seleção de réplicas pelo servidor de metadados ao abrir um arquivo segue o seguinte critério:

Arquivo aberto em modo de leitura; Seleciona qualquer réplica do arquivo. Arquivo aberto em modo de escrita. Se existe um processo que abre o arquivo em modo de escrita, seleciona a réplica que já está aberta nesse modo; Se existem vários processos que abrem o arquivo em modo de leitura, seleciona qualquer réplica ou uma das que estiverem abertas nesse modo; Se não existe processo que abre o arquivo, seleciona qualquer réplica.

3.3.1.2 Advisory File Locking (Controle de travamento de arquivo)

Este travamento de arquivo é suportado na API POSIX, de tal forma que as travas de leitura e gravação são suportadas em todo o arquivo ou em apenas uma região dele. Quanto à política de implementação, todos os processos acessam a mesma réplica do arquivo no caso dele estar em controle de travamento. O cache no lado “cliente” é então desabilitado para a região que encontra-se travada.

3.3.1.3 Atualização consistente dos metadados

O gfsd passa a ter controle sobre o mecanismo de atualização dos metadados. Quando um arquivo é fechado, a biblioteca de I/O solicitará o fechamento ao gfsd ao invés de fazê-lo diretamente. O gfsd por sua vez fará a atualização dos metadados e finalizará a operação. Isso também ocorrerá quando a conexão de um “cliente” Gfarm for quebrada. 59

Caberá também ao gfsd a propriedade de todos os arquivos físicos do Gfarm, evitando a quebra da consistência pela manipulação imprópria pelo usuário, que antes poderia acessar e modificar os arquivos sem passar pela biblioteca de I/O.

3.3.1.4 Generalização do modelo de agrupamento de arquivos

Para flexibilizar o agrupamento de arquivos, antes feito na v1 mediante metadados especiais, a v2 explora a estrutura de diretórios do sistema de arquivos. Cada diretório e seus subdiretórios formam naturalmente um agrupamento. Com o uso de symbolic links (ligações simbólicas) e hard links (ligações físicas) é possível criar várias formas de agrupamento para processamento paralelo com operações de arquivos padrão.

4 MONTAGEM DO EXPERIMENTO

Este capítulo relata os procedimentos principais e peculiaridades de implementação e configuração do Gfarm no cenário corporativo da Coverex Informática. Adicionalmente foi mostrada a instalação e configuração da ferramenta de benchmark IOzone, além do emulador de rede NIST Net. As instruções detalhadas de instalação e configuração, mediante guias específicos podem ser consultados no Anexo A.

4.1 O cenário final do experimento

O experimento foi implementado sobre infra-estrutura computacional já em operação, na Coverex Informática. A ilustração apresentada na figura 7 refere-se à versão final do cenário utilizado.

Figura 7 – Cenário final do experimento com o Gfarm (referente ao quadro 10)

O cenário refere-se a uma rede composta por 10 estações de trabalho e um servidor viabilizado pelo produto Microsoft Windows SBS (Small Business Server) 2003.

Os serviços disponíveis por este pacote de servidor Microsoft são:

Controlador de domínio primário (PDC – Primary Domain Controller); Servidor de arquivos; Banco de Dados SQL Server 2000; Servidor de Fax; Servidor de colaboração em grupo Microsoft Exchange 2003; ISA (Internet Security and Accelerator) Server 2004.

Todos esses serviços são utilizados pelos usuários, além de um sistema de gerenciamento de assistência técnica chamado SAT, o qual suporta o modelo de negócio da empresa. O SAT é uma aplicação cliente/servidor em duas camadas, baseada no uso do Microsoft SQL Server 2000 como banco de dados. Os componentes do cenário foram arranjados e preparados de forma a garantir similaridade com um grid de dados tradicional, usado na comunidade científica, o qual possui múltiplos nós de armazenamento de diferentes tecnologias, dispersos geograficamente e localizáveis por um serviço de diretório. Além disso, com o uso do ISA Server 2004, os usuários internos podem ter acesso à Internet e, os externos, podem se conectar à rede interna por VPN (Virtual Private Network) via Internet. Uma vez conectados por VPN, o Gfarm torna-se acessível. Todavia, não houve modificação introduzida no ambiente operacional produtivo dos usuários em razão da implementação do Gfarm. O que estava em operação foi mantido. A rede de comunicação é switched Ethernet de 10/100 Mbps, segmentada em duas redes distintas, interligadas por um servidor Linux operando como roteador, de nome nistnet.grid.local (figura 7). Os componentes do experimento estão listados no quadro 10. 62

Elementos/ Nós Hardware Software Principal Funções nistnet.grid.local ▪ Processador Intel Celeron 900 MHz ▪ Sistema Operacional (SO) Debian ▪ Roteador ▪ Cache L1: 32 B Woody atualizado para Sarge 3.1 ▪ Emulador de rede ▪ Cache L2: 128 KB com Kernel 2.4.18 (c/ KDE 3.0) ▪ SAMBA Server ▪ 256 MB RAM ▪ Emulador NISTNet 2.0.12b ▪ HDD IDE 10 GB 5400 RPM ▪ SAMBA 3.0 (WD100AA) metasvr.grid.local ▪ Processador Intel Pentium II – 350 ▪ SO Fedora Core 3 -> 5 – 2.6.15- ▪ Servidor LDAP MHz 1.2054_FC5 (c/ KDE 3.0 -> 3.5.1- ▪ Gfarm metaserver ou metaserver ▪ Cache L1: 32 B 2.3) ▪ Cache L2: 512 KB ▪ OpenLDAP server 2.3.19-4 ▪ 128 MB RAM ▪ Gfarm*: Libs e Server ▪ HDD IDE 20 GB 5400 RPM (Maxtor ▪ SNMP (net-snmp 5.3-4.2) 2B020H1) ▪ IOzone 3.247 dfsrv1.grid.local ▪ HP BRIO BA 600 Processador Intel ▪ SO HOST: Windows XP Professional ▪ Estações de rede da dfsrv2.grid.local Pentium III – 650 MHz SP2 Coverex ▪ Cache L1: 32 B/ Cache L2: 256 KB ▪ Microsoft Virtual PC 2004 versão ▪ Nós de ▪ 256 MB RAM 5.3.582.27 (VM) armazenamento * Versão inicial * ▪ SO GUEST: Fedora Core 3 com Gfarm em VM ▪ HDD IDE 40 GB 7200 RPM (Maxtor Interface gráfica KDE 3.1 dfsrv1.grid.local 6E040L0) ▪ Gfarm*: Client, Libs, Doc e FSnode ▪ HDD IDE 20 GB 5400 RPM (WD ▪ IOzone 3.247 dfsrv2.grid.local 200EB) ▪ SNMP (net-snmp 5.3-4.2) dfsrv1.grid.local ▪ Processador Intel Pentium 4 - 2.4 GHz ▪ SO HOST: Windows XP Professional ▪ Estações de rede da dfsrv2.grid.local ▪ Cache L1: 16 KB/ Cache L2: 1024 KB SP2 Coverex ▪ 512 MB RAM ▪ Microsoft Virtual PC 2004 versão ▪ Nós de ▪ HDD IDE 40GB 7200 RPM (Maxtor 5.3.582.27 (VM) armazenamento 6E040L0) ▪ SO GUEST: Fedora Core 3 -> 5 – 2.6.17- Gfarm em VM 1.2174_FC5 (c/ KDE 3.1) * Versão final * ▪ Gfarm*: Client, Libs, Doc, FSnode; e glibc-not-hidden ▪ IOzone 3.247 ▪ SNMP (net-snmp 5.3-4.2) dfsrv3.grid.local ▪ Processador Intel Pentium III 800 ▪ SO Fedora Core 3 → 5 – 2.6.15- ▪ Nó de MHz 1.2054_FC5 (c/ GNOME 2.14) armazenamento ▪ 128 MB RAM ▪ Gfarm*: Client, Libs, Doc, FSnode; e Gfarm ▪ HDD IDE 20 GB 5400 RPM (Maxtor glibc-not-hidden 2B020H1) ▪ SNMP (net-snmp 5.3-4.2) ▪ IOzone 3.247 dfsrv4.grid.local ▪ HP BRIO BA 600 - Processador Intel ▪ SO CentOS 4.3 - 2.6.9-42.0.2.EL ▪ Nó de Pentium III – 650 MHz (c/ GNOME 2.14) armazenamento hardware igual ▪ Cache L1: 32 B ▪ Gfarm*: Client, Libs, Doc e FSnode Gfarm ▪ Cache L2: 256 KB ▪ SNMP (net-snmp 5.3-4.2) ▪ 256 MB RAM ▪ IOzone 3.247 brio-arpa em ▪ Windows XP Professional SP2 coverexg2.local ▪ IOzone 3.263 (Windows) ▪ Cliente Windows smbsvr.grid.local ▪ Processador Intel K6-II 550 MHz ▪ SO Fedora Core 3 -> 5 – 2.6.15- ▪ SAMBA Server ▪ Cache L1: 64 KB 1.2054_FC5 (c/ GNOME 2.14) ▪ Cliente Gfarm ▪ Cache L2: -o- ▪ SAMBA 3.0.21b-2 ▪ Servidor NFS para o ▪ 160 MB RAM ▪ SNMP (net-snmp 5.3-4.2) diretório home de ▪ HDD IDE 4.3 GB 5400 RPM (Fujitsu ▪ NFS 3 usuário MPE3043AE) ▪ Gfarm*: Client, Libs, Doc; e glibc-not- hidden ▪ IOzone 3.247 gfwks.grid.local ▪ IBM Netfinity 3000 - Processador Intel ▪ SO CentOS 4.3 - 2.6.9-42.0.3.EL ▪ Gfarm client P III – 650 MHz (c/ GNOME 2.14) adicionado ▪ Cache L1: 32 B / Cache L2: ▪ SNMP (net-snmp 5.3-4.2) ▪ 384 MB RAM ▪ Acrobat Reader 7.08 ▪ HDD SCSI 8 GB 7200 RPM ▪ Mplayer ▪ Gfarm*: Client, Libs, Doc; e glibc- not-hidden ▪ IOzone 3.247 susesvr.grid.local ▪ HP Vectra VE 5 - Processador Intel ▪ SO SuSE 9 – 2.4.21-303 (c/ KDE 3.1) ▪ Coletor/ traçador Pentium 233 MMX ▪ SAMBA 3.0.21b MRTG adicionado ▪ Cache L1: / Cache L2: ▪ Apache 2 ▪ SAMBA Server ▪ 192 MB RAM ▪ MRTG 2.10.15-1 ▪ Web Server ▪ HDD IDE 10 GB 5400 RPM * Os módulos do Gfarm correspondem às versões usadas 1.1.1, 1.2-5 (1.2 PL4) e 1.3.1. As versões de “glibc-not-hidden” dependem de “glibc” e são pertinentes a cada versão do Gfarm e do sistema operacional (2.4-4 para o Fedora Core 5). Quadro 10 – Composição dos elementos do cenário experimental do Gfarm na Coverex

A maioria dos elementos que receberam módulos funcionais do Gfarm teve como Sistema Operacional o Fedora Core 3, posteriormente atualizado para Fedora Core 5. Exceção se fez a uma estação adicionada para operar somente como client, identificada inicialmente como renarouter - substituída posteriormente por gfwks - e ao nó de armazenamento dfsrv4, ambos utilizando Linux CentOS 4.3. O processo de instalação do CentOS 4.314 é similar ao Fedora Core 3/515, sendo ambos derivados do Linux Red Hat e disponíveis para download livre. A instalação do Fedora Core 3/5 e do CentOS 4.3 nos elementos, exceto os nós dfsrv1 e dfsrv2, foi realizada utilizando-se o guia da ferramenta de instalação Anaconda, que acompanha os sistemas operacionais e é iniciada automaticamente após a inicialização pelo CD (compact disk) 1. Na instalação, ainda que o nó fosse um fsnode, optou-se por instalar a interface gráfica padrão GNOME, visto que os fsnodes são obrigatoriamente clientes do Gfarm e permitem o uso de aplicações gráficas para teste. Num ambiente real, a instalação dos pacotes gráficos não é obrigatória, diminuindo a carga de trabalho do nó. Nos nós dfsrv1 e dfsrv2, implementados sobre VMs, a instalação inicial foi possível mediante a utilização de instruções específicas16, em razão da incompatibilidade do Fedora Core 3 com VMs do Microsoft Virtual PC 2004 versão 5.3.582.27. No Fedora Core 5 já não existe necessidade de ações especiais, pois a instalação sobre VMs ocorre sem dificuldades, assim como em máquinas reais. Exceção se faz quanto à quantidade de memória disponível na VM. Com 128 MB de RAM, a instalação é comutada automaticamente para o modo texto, ainda que uma área de swap seja ativada. Após a instalação do NIST Net (vide 4.5), iniciou-se a instalação dos componentes do Gfarm pelo servidor de metadados metasvr.grid.local (metaserver) responsável pela retaguarda do mapeamento lógico-físico do sistema de arquivos. O Fedora Core 3 foi instalado inicialmente, adicionando-se o pacote “openldap- servers-2.2.13”, o qual é pré-requisito, operando como retaguarda de gerenciamento dos metadados. Com o “openldap” incorporado ao Fedora, foram instalados os módulos “gfarm- gsi-libs-1.1.1” e “gfarm-gsi-server-1.1.1”. Apesar de não ser obrigatório, optou-se por instalar o ambiente gráfico KDE que acompanha o sistema operacional, visando facilitar a administração do servidor. A seguir, foi realizada a configuração da base de dados LDAP necessária ao Gfarm, com o comando “config-gfarm”. O metaserver sofreu atualizações durante o período de experimentação. Além das atualizações regulares do Fedora Core e seus pacotes associados, o Gfarm passou para a versão 1.2-5 (1.2 PL4) e posteriormente para 1.3.1, já requerendo o Fedora Core 5. Com o metaserver funcionando, passou-se para a implementação dos nós de armazenamento (fsnodes). Inicialmente foram criados dois fsnodes em VMs Microsoft Virtual PC 2004 com Fedora Core 3 – dfsrv1 e dfsrv2. Na versão 3, o sistema operacional requereu algumas ações especiais (vide seção 7 – Anexo A) para operar em VM.

14 http://isoredirect.centos.org/centos/4/isos/i386/ 15 http://download.fedora.redhat.com/pub/fedora/linux/core/5/i386/iso/ 16 As instruções estão reunidas sob o título “Fedora Core 3 sobre VM Microsoft Virtual PC 2004” no Anexo A. 64

Com o Fedora Core 3 em funcionamento – certificando-se da presença do pacote openldap-2.3.19 – passou-se à instalação dos três módulos do Gfarm 1.1.1 para a função de fsnode, que requer: gfarm-gsi-libs-1.1.1; gfarm-gsi-client-1.1.1; gfarm-gsi-fsnode-1.1.1.

Em seguida foi copiado o arquivo de configuração “/etc/gfarm.conf”, gerado na criação do metaserver, para o diretório “/etc” local, e executado o comando “config-gfsd”. A execução acionou a criação do diretório de armazenamento local, registrou o fsnode no metaserver e o colocou em operação com a execução automática de “gfsd”. Como o fsnode também deve ser cliente do sistema de arquivos, foi criada a chave de segredo compartilhado com o comando “gfkey –c”, copiada em seguida para o mesmo diretório de usuário no metaserver. Verificado o funcionamento básico com “gfps”, aproveitaram-se as características das VMs para criar o dfsrv2. Ao invés de fazer novamente todas as instalações, a VM foi parada e seus arquivos copiados para o computador que hospedaria o novo fsnode. Para torná-lo único, foram alterados o endereço MAC dentro do arquivo de configuração da VM (extensão “.vmc”), além do nome de máquina (hostname) e endereço IP no Fedora Core. Assim como o metaserver, ambos os nós dfsrv1 e dfsrv2 receberam atualizações regulares durante o período experimental, incluindo o Gfarm que passou pelas versões 1.1.1, 1.2-5 (1.2 PL4) e 1.3.1, requerendo essa última o Fedora Core 5. No dfsrv1, ainda foram instalados o ambiente gráfico GNOME e vários utilitários/pacotes que permitissem trabalhar com arquivos típicos de biblioteca digital e também administrar o Gfarm, como: Adobe Reader 7.0.5; Mplayer 1.0pre8-4.1.1; Totem 1.4.1-1; Utilitários do Gfarm. Java™ 2 Runtime Environment, Standard Edition 1.4.2_06 (requisito para “gfarm-gsi-gfront”); gfarm-gsi-gfront; gfarm-gsi-frontend.

O nó dfsrv3.grid.local foi implementado em máquina real, mas configurado de forma similar ao dfsrv1. No intuito de usá-lo como cliente efetivo do Gfarm, foram instalados os mesmos utilitários e ferramentas de administração, com a adição dos seguintes pacotes: OpenOffice 2.0; Helix Player 1.0.6.778. 65

Com o objetivo de aumentar o número de nós com máquinas reais, além de comprovar a funcionalidade de um novo sistema operacional, foi acrescentado ao cenário o dfsrv4. Este fsnode foi criado empregando-se o Linux CentOS 4.3, o qual é uma distribuição livre baseada nos fontes públicos do Red Hat EL (Enterprise Linux) 4. O dfsrv4 recebeu, além dos módulos de fsnode, a instalação da glibc-not-hidden-2.3.4- 2.19 para permitir o acesso virtual ao Gfarm em “/gfarm”. A versão dessa biblioteca complementar acompanha a “glibc”. Como esse nó não seria utilizado como cliente exclusivo do sistema de arquivos, optou-se por instalar unicamente o leitor de PDF Adobe Reader 7.0.5. Por se tratar de Linux compatível com Red Hat, os pacotes foram obtidos em formato RPM e instalados com o comando: # rpm –ihv nome_do_pacote

Na seqüência, passou-se para a implementação do servidor Samba smbsvr com Linux Fedora Core 3/5. As quatro funções principais do smbsvr, agrupadas com os respectivos pacotes RPM instalados foram:

1) Cliente exclusivo Gfarm (função de fsnode não instalada); Módulos Gfarm da função cliente (libs e client); “glibc-not-hidden-2.4-4” para acesso virtual ao diretório “/gfarm”.

2) Servidor Samba; Samba-3.0.21b-2.

3) Ser interface entre o sistema de arquivos Gfarm e o sistema de arquivos de rede do ambiente Microsoft Windows, fazendo com que os clientes Windows possam acessar o Gfarm como se fosse um compartilhamento padrão SMB. Essa funcionalidade depende do item 1 satisfeito. Detalhes de instalação e configuração no Anexo A.

4) Servidor NFS para distribuição da chave de segredo compartilhado. Vide 4.5.2.

Após os itens de 1 a 4, foram instaladas aplicações tradicionais para acessar os conteúdos armazenados no Gfarm, de forma análoga ao nó dfsrv1. O último elemento a ser instalado foi a estação gfwks, com o objetivo de prover um cliente exclusivo adicional para o Gfarm e permitir a execução simultânea do benchmark, visando a um ambiente mínimo de concorrência. A gfwks foi criada sobre Linux CentOS 4.3, recebendo as mesmas aplicações de teste instaladas em dfsrv1. Por fim, a estação de trabalho Windows brio-arpa - um cliente Windows nativo já presente na rede Coverex – foi preparada apenas com a instalação do IOzone 2.6.3 (Windows), para a execução do benchmark de integração com o Gfarm via Samba. 66

4.2 Monitoramento e suporte

Para o monitoramento do cenário utilizando o MRTG, foi instalado e configurado o SNMP (pacote “net-snmp”) em todos os nós do Gfarm, visando a coleta dos dados posteriormente traçados graficamente. A configuração do SNMP pode ser vista no quadro 11:

Quadro 11 – Arquivo de configuração do SNMP (snmpd.conf) usado nos nós do Gfarm

A visualização gráfica dos dados coletados foi viabilizada com a instalação do MRTG no servidor susesvr.grid.local, mediante o registro de cada nó a ser monitorado, conforme procedimento padrão no quadro 12, a seguir:

1) # cfgmaker --output=/etc/mrtg/mrtg.cfg --global "workdir: /var/www/mrtg" \ -ifref=ip --global 'options[_]: growright,bits' senha_SNMP@IP_do_nó_monitorado

2) # indexmaker --output=/var/www/mrtg/index.html /etc/mrtg/mrtg.cfg

3) Execução de uma rodada do MRTG:

# env LANG=C /usr/bin/mrtg

4) Execução repetitiva a usando “crontab” – recomendada:

# 0-59/5 * * * * root /usr/bin/mrtg /etc/mrtg/mrtg.cfg Quadro 12 – Procedimento padrão de configuração dos nós monitorados com MRTG

Os passos 1 e 2 devem ser repetidos para cada nó a ser monitorado graficamente, substituindo-se os itens grafados em itálico pela senha do SNMP e endereço IP do nó monitorado. No passo 1 é criada a configuração dos parâmetros que serão traçados, enquanto no 2 o trecho gráfico é incorporado na página web a ser mostrada pelo servidor Apache. Ressalta-se que o pacote Apache (versão 1 ou 2) deve estar previamente instalado no servidor MRTG. Após realizados os passos 1 e 2, executa-se o MRTG para criar a primeira seção gráfica. Inicia-se o comando com “env LANG=C” para evitar eventuais erros do MRTG devido à variável LANG com valor inesperado de linguagem (ex.: “en_US.UTF-8” no Red Hat). Nessa primeira execução do MRTG, pode-se deparar com erros. Recomenda-se insistir no comando, de 3 a 4 vezes, até que os erros cessem. A seguir, pode-se configurar a execução automática e repetitiva do MRTG, utilizando-se a ferramenta “crontab”. O passo 4 mostra um exemplo de linha a ser incluída ao executar-se “crontab –e”. Ressalta-se que, como padrão, o MRTG mostra as variáveis associadas ao tráfego de rede de cada interface. O monitoramento de variáveis referentes a processamento, memória e disco pode ser configurado, bastando incorporar as MIBs correspondentes à configuração do MRTG. Um exemplo pode ser visto no quadro 13. Neste quadro, as referências são para as MIBs “UCD-SNMP-MIB” e “TCP-MIB”, conforme pode ser visto na linha em negrito. 68

# File: /etc/mrtg/server-info.cfg # LoadMIBs: /usr/share/snmp/mibs/UCD-SNMP-MIB.txt,/usr/share/snmp/mibs/TCP-MIB.txt workdir: /var/www/mrtg/ # Target[server.cpu]:ssCpuRawUser.0&ssCpuRawUser.0:craz33guy@localhost + ssCpuRawSystem.0&ssCpuRawSystem.0:craz33guy@localhost + ssCpuRawNice.0&ssCpuRawNice.0:craz33guy@localhost Title[server.cpu]: Server CPU Load PageTop[server.cpu]: < H1 >CPU Load - System, User and Nice Processes< /H1 > MaxBytes[server.cpu]: 100 ShortLegend[server.cpu]: % YLegend[server.cpu]: CPU Utilization Legend1[server.cpu]: Current CPU percentage load LegendI[server.cpu]: Used LegendO[server.cpu]: Options[server.cpu]: growright,nopercent Unscaled[server.cpu]: ymwd # Target[server.memory]: memAvailReal.0&memTotalReal.0:craz33guy@localhost Title[server.memory]: Free Memory PageTop[server.memory]: < H1 >Free Memory< /H1 > MaxBytes[server.memory]: 100000000000 ShortLegend[server.memory]: B YLegend[server.memory]: Bytes LegendI[server.memory]: Free LegendO[server.memory]: Total Legend1[server.memory]: Free memory, not including swap, in bytes Legend2[server.memory]: Total memory Options[server.memory]: gauge,growright,nopercent kMG[server.memory]: k,M,G,T,P,X Title[server.mempercent]: Percentage Free Memory PageTop[server.mempercent]: < H1 >Percentage Free Memory< /H1 > # Target[server.mempercent]: ( memAvailReal.0&memAvailReal.0:craz33guy@localhost ) * 100 / ( memTotalReal.0&memTotalReal.0:craz33guy@localhost ) options[server.mempercent]: growright,gauge,transparent,nopercent Unscaled[server.mempercent]: ymwd MaxBytes[server.mempercent]: 100 YLegend[server.mempercent]: Memory % ShortLegend[server.mempercent]: Percent LegendI[server.mempercent]: Free LegendO[server.mempercent]: Free Legend1[server.mempercent]: Percentage Free Memory Legend2[server.mempercent]: Percentage Free Memory # Target[server.newconns]: tcpPassiveOpens.0&tcpActiveOpens.0:craz33guy@localhost Title[server.newconns]: Newly Created TCP Connections PageTop[server.newconns]: < H1 >New TCP Connections< /H1 > MaxBytes[server.newconns]: 10000000000 ShortLegend[server.newconns]: c/s YLegend[server.newconns]: Conns / Min LegendI[server.newconns]: In LegendO[server.newconns]: Out Legend1[server.newconns]: New inbound connections Legend2[server.newconns]: New outbound connections Options[server.newconns]: growright,nopercent,perminute # Target[server.estabcons]: tcpCurrEstab.0&tcpCurrEstab.0:craz33guy@localhost Title[server.estabcons]: Currently Established TCP Connections PageTop[server.estabcons]: < H1 >Established TCP Connections< /H1 > MaxBytes[server.estabcons]: 10000000000 ShortLegend[server.estabcons]: YLegend[server.estabcons]: Connections LegendI[server.estabcons]: In LegendO[server.estabcons]: Legend1[server.estabcons]: Established connections Legend2[server.estabcons]: Options[server.estabcons]: growright,nopercent,gauge # Target[server.disk]: dskPercent.1&dskPercent.2:craz33guy@localhost Title[server.disk]: Disk Partition Usage PageTop[server.disk]: < H1 >Disk Partition Usage /home and /var< /H1 > MaxBytes[server.disk]: 100 ShortLegend[server.disk]: % YLegend[server.disk]: Utilization LegendI[server.disk]: /home LegendO[server.disk]: /var Options[server.disk]: gauge,growright,nopercent Unscaled[server.disk]: ymwd Quadro 13 – Arquivo de configuração MRTG para MIBs UCD-SNMP e TCP Fonte: modificado de (LINUX HOME NETWORKING, 2006)

Para incorporar as variáveis do quadro 13, o arquivo “server-info.cfg” deve passar pelo passo 1 do quadro 12, além de ser incluído ao final do comando do passo 2. Em seguida, deve-se executar os passos 3 e 4, sendo que este último provoca sua execução periódica automática, assim como ocorre com “mrtg.cfg”. Instruções detalhadas podem ser obtidas em (LINUX HOME NETWORKING, 2006). Por fim, foi instalado o IOzone versão 3.247 em todos os elementos do Gfarm para realizar os benchmarks. Após sua instalação, foi necessário adicionar o seu diretório de execução à variável “PATH” (/opt/IOzone/bin/), tornando possível acioná-lo de qualquer ponto da hierarquia do sistema de arquivos local. Procedimento similar - exceto pela variável PATH - foi realizado na estação brio-arpa, na qual foi instalado o IOzone 2.6.3 para Windows.

4.3 Criação do DVD com cenário experimental do Gfarm

Após a montagem do cenário experimental e a certificação de seu funcionamento, foi criado um pacote em DVD contendo os principais elementos do Gfarm em VMs pré- configuradas, acompanhados de utilitários, arquivos de teste e guias de instalação. Esta contribuição adicional do trabalho visou proporcionar aos interessados em experimentar o Gfarm, um conjunto mínimo pré-configurado, para uso em ambientes experimentais ou produtivos, servindo também para fins didáticos. A composição, detalhes e instruções de uso do pacote estão descritos no Anexo A, seção 12.

4.4 Procedimentos especiais

4.4.1 Roteador / emulador NIST Net

O roteador/ emulador NIST Net foi o primeiro componente a ser implementado, devido à sua função de interconectar as duas redes locais, emulando condições de longa distância. Sua instalação foi realizada sobre o Linux Debian 3.1 (Sarge) em razão da versão do Kernel que deveria ser até 2.4.X, para cumprir exigência de instalação da versão 2.0.12b do NIST Net. Por se tratar de função específica, não recebeu qualquer módulo do Gfarm. Como peculiaridade da instalação do roteador, foi necessária uma reconfiguração do Kernel do Debian, consistindo da alteração do driver de RTC padrão, que passou a ser um módulo carregável, permitindo posteriormente instalar aquele fornecido com a ferramenta NIST Net. A operação de alteração do RTC original foi realizada após a instalação dos fontes do Kernel e a execução do comando make menuconfig. Em seguida fez-se a recompilação das novas configurações do Kernel, gerando novo arquivo para a inicialização do sistema. Quando o NIST Net é carregado com o comando Load.Nistnet, o módulo RTC original é descarregado, carregando-se aquele que acompanha o emulador. O salvamento do módulo original primeiramente é tentado e, em caso de sucesso, preservado até o término do uso. 70

Desse modo, quando o emulador é encerrado, o RTC original pode ser recarregado, retornando-se o sistema operacional ao padrão. Além da tentativa de salvamento, a versão do Kernel é verificada quanto à compatibilidade com a versão da ferramenta. No caso do experimento, apenas as versões 2.0, 2.2 ou 2.4 do Kernel eram suportadas. A carga pôde ser confirmada com o comando “lsmod”, cujo resultado está no quadro 14, mostrando o módulo (rtc) na última linha da listagem:

Quadro 14 – Visualização do módulo de RTC do NIST Net

Para facilitar a carga do NIST Net, fazendo-se a referência ao seu diretório de instalação, foi criado o script de nome “nnet”, conforme quadro 15:

Quadro 15 – Script “nnet” para substituição do módulo RTC pelo NISTNet

A administração pode ser via linha de comandos ou GUI. No caso deste último, deve- se executar o comando “xnistnet” a partir de uma janela de terminal/console, provocando o carregamento da tela de parametrização a seguir (figura 8). 71

Figura 8 – Tela gráfica de parametrização do NIST Net

4.4.2 NFS

O estabelecimento de um servidor NFS no cenário do Gfarm foi necessário para criar um diretório home compartilhado para todos os usuários do sistema de arquivos. Dentro da arquitetura de segurança do Gfarm, como neste experimento foi optado pelo uso de chave de segredo compartilhado ao invés de GSI, o diretório criado simplifica a distribuição da chave. Se não fosse dessa forma, a chave precisaria ser recriada a cada 24 horas e distribuída por cópia para todos os nós interligados pelo GD. Esse esquema de cópia foi empregado apenas durante os testes preliminares. Dentro do cenário, foi escolhido para servidor NFS, o smbsvr, o mesmo que hospeda o Samba para operar como front-end dos clientes Windows. Como esse servidor não operaria como fsnode, mas basicamente como client do Gfarm, supôs-se que o Samba poderia funcionar junto com o NFS, aproveitando-se os recursos de uma única máquina. Uma outra questão foi padronizar o usuário a ser empregado no acesso ao Gfarm, ao Samba e ao NFS. Assim, foi optado por criar um diretório home para o usuário “lab”, exportando-o com o NFS. Nos nós do Gfarm, o mesmo usuário “lab” foi criado, porém com seu diretório home apontando para um ponto de montagem NFS. Aproveitou-se a estrutura compartilhada para armazenar pacotes, atualizações, ferramentas e arquivos de teste, necessários durante os vários ensaios executados no experimento, concentrando-os num local único e de fácil acesso. No intuito de facilitar e tornar transparente o acesso ao diretório home durante o logon do usuário, configurou-se a montagem automática com a ativação do serviço “autofs” em todos os nós do Gfarm, sendo incorporado ao processo de inicialização com o configurador “ntsysv”. 72

Para a configuração do “autofs”, os arquivos “auto.master” e “auto.gfarm” foram criados e copiados para o diretório “/etc” de cada nó. Ambos os arquivos podem ser visualizados nos quadros 16 e 17, respectivamente.

# # $Id: auto.master,v 1.3 2003/09/29 08:22:35 raven Exp $ # # Sample auto.master file # This is an automounter map and it has the following format # key [ -mount-options-separated-by-comma ] location # For details of the format look at autofs(5). #/misc /etc/auto.misc --timeout=60 #/misc /etc/auto.misc #/net /etc/auto.net /home /etc/auto.gfarm --timeout=60 #/mnt /etc/auto.test

Quadro 16 - Conteúdo do arquivo “auto.master”

# Parâmetros de Automount para acesso ao Gfarm Shared Secret (segredo # compartilhado)

#banana -rw smbsvr.grid.local:/home/gfarm #pera -rw smbsvr.grid.local:/home/public * -fstype=nfs,soft,intr,rw smbsvr.grid.local:/home/lab #* -fstype=nfs,soft,intr,nosuid,rw smbsvr.grid.local:/home

Quadro 17 - Conteúdo do arquivo “auto.gfarm”

Em ambos os quadros, as linhas em destaque correspondem às personalizações para uso com o Gfarm. Basicamente, no quadro 16, é referenciado o diretório “/home” como um ponto de montagem vinculado ao arquivo “auto.gfarm”. Ao se tentar acessar o diretório – manualmente ou como parte do logon do usuário -, qualquer que seja o subdiretório acionado, o diretório exportado “smb.grid.local:/home/lab” monta-se automaticamente. A montagem se dará com direitos de leitura e escrita, conforme parâmetro “rw” na linha em destaque do quadro 17. Durante o período no qual o cenário foi observado, várias atualizações ocorreram tanto no Gfarm, que foi da versão 1.1.1 até a 1.3.1, quanto no sistema operacional Fedora Core, que começou na versão 3 e terminou na 5. As atualizações do Gfarm transcorreram de forma transparente, ou seja, sem ações especiais ou perda de dados até a versão 1.2-5 (1.2 PL4) de 28/09/2005. Contudo, na atualização para a versão 1.3.1, observaram-se as seguintes ocorrências: Necessidade de instalar pacotes adicionais para dar suporte à GSI, como “globus-gssapi-gsi-gcc32-4.0.2” e “globus-gpt-4.0.2”; 73

Necessidade de instalar o PostgreSQL, pois foi estabelecido como o novo padrão para a retaguarda do servidor de metadados; Houve a perda de dados tanto no servidor de metadados quanto nos fsnodes, pois houve alteração na estrutura do LDAP. Esta alteração requereu a implantação de nova instância do serviço de diretório e a conseqüente repetição do registro de todos os fsnodes, não havendo como preservar os dados anteriores. Ressalta-se que poderiam ser salvos antes da atualização, mas a volta não seria direta, já que a estrutura da retaguarda foi alterada substancialmente. Houve alteração até nos diretórios do sistema de arquivos local de cada fsnode. Na versão 1.3.1, ele passou a ser “/var/gfarm-spool”; Os pacotes RPM do Gfarm 1.3.1 para Fedora Core 5 disponíveis para download, não são compatíveis com a versão do LDAP desse sistema operacional. Foi necessário reconstruir todos os pacotes da versão 1.3.1, utilizando-se a ferramenta “rpmbuild”. Detalhes podem ser obtidos no Anexo A. 74

5 TESTES, BENCHMARKS E RESULTADOS

Neste capítulo são mostrados os resultados dos testes funcionais e benchmarks realizados, conforme cenário do capítulo 4. Eles estão organizados nos seguintes grupos: Avaliações preliminares: testes funcionais; Avaliações de desempenho individual; Avaliações de desempenho de alguns comandos básicos; Avaliações de desempenho de conjunto: Gfarm operando; Avaliação comparativa com o NFSv4.fc5; Integração com os clientes Windows; Latência.

Os testes foram executados manualmente ou programados para execução automática fora dos horários de trabalho, normalmente após 22:00 hs de segunda a sexta-feira ou em finais de semana com horário livre. Em todos os casos o escopo do teste foi limitado a operações básicas de escrita e leitura simples, com a criação de arquivos de tamanho crescente, porém abaixo do limite definido no quadro 18:

tam_máx_arquivo = 2 x qtde_RAM_do_nó

Quadro 18 – Limite de tamanho de arquivo sugerido pelo IOzone

A razão de tal limite é estabelecer um patamar no qual certamente se perde os efeitos dos caches de processador e sistema operacional, indo para o acesso direto ao dispositivo de armazenamento. Contudo, observou-se que um arquivo cujo tamanho se iguala ou ultrapassa o tamanho da memória RAM (Random Access Memory), foi suficiente para evitar o uso de cache nas suas operações. Assim, para diminuir os tempos de execução dos testes que poderiam durar várias horas, limitou-se o tamanho máximo do arquivo entre 128MB e 256MB, em função das características de cada nó. No caso dos dados de latência, o volume seria grande, de tal forma a impedir a abertura dos arquivos com o Microsoft Excel. Esse comportamento foi observado nos testes iniciais em que se empregou o limite sugerido por Norcott, (2005). Além do teste individual, o qual é executado da forma tradicional de um sistema de arquivos local, executou-se uma rodada a partir do nó servidor smbsvr.grid.local usando-se o ponto de acesso “/gfarm” como diretório de uso do IOzone. 75

O ponto de acesso “/gfarm” se torna visível e acessível às aplicações binárias não modificadas, incorporando a biblioteca dinâmica syscall-hook ao shell17 de cada usuário, com a diretiva de variável de ambiente LD_PRELOAD. Ao usar-se o ponto “/gfarm” no nó smbsvr.grid.local18 como diretório de trabalho do IOzone, provoca-se a cada rodada de teste o uso alternado dos nós de armazenamento, como pôde ser observado pelo uso do comando no quadro 19:

gfwhere -s iozone.tmp

Quadro 19 – Comando para visualizar a localização dos fragmentos de um arquivo Gfarm

Se o IOzone é executado no mesmo ponto de acesso, porém a partir de um nó de armazenamento (fsnode), o princípio da localidade faz com que somente este nó seja usado como repositório das operações de sistema de arquivos. Destaca-se que o cenário sofreu modificações durante o período de observação. Uma delas foi a inclusão do nó servidor de arquivos dfsrv4, baseado no Linux CentOS 4.3, uma distribuição derivada do Red Hat Enterprise, para aumentar o número de máquinas reais no experimento. Além disso, para os últimos benchmarks, visando comparações com o ambiente Windows nativo, utilizou-se a estação de usuário brio-arpa, cuja configuração é idêntica ao dfsrv4, exceto pelo sistema operacional Windows XP Pro SP2. Neste caso foi utilizado o IOzone para Windows.

5.1 Avaliações preliminares

Baseando-se no cenário da figura 4, foram realizados testes preliminares com a execução de comandos de administração do Gfarm, a importação de arquivos para o Gfarm e benchmarks com o IOzone, seguindo determinações da própria ferramenta (NORCOTT, 2005) para a configuração de cada nó. Como se trabalhou com o Gfarm 1.1.1, 1.2-5 (1.2 PL4) e 1.3.1, os mesmos procedimentos foram realizados em cada nova versão. Os primeiros testes foram executados na versão 1.1.1, sendo os conteúdos mantidos até a 1.3.1, na qual o sistema de arquivos foi abastecido novamente. Dessa forma, nas figuras com listagem de arquivos, o conteúdo armazenado pode ser diferente. Após todos os nós estarem instalados e a chave de segredo compartilhado gerada e disponível para todos eles, a execução do comando “gfps” ocorreu sem qualquer erro, atestando a operação dos nós com o servidor de metadados. Ressalta-se que, devido ao uso de aplicações não preparadas, ativou-se a biblioteca syscall-hook nos nós clientes e também nos fsnodes dfsrv1, dfsrv2 e dfsrv3. Assim, as operações puderam ser realizadas tanto por comandos nativos Linux (ex.: cp, mkdir, rm, ls, ll) como pelos comandos nativos do Gfarm (ex.: gfls, gfrep, gfcp, gfmkdir, gfrm).

17 Ambiente de comandos do sistema operacional 18 Configurado no gfarm apenas como “cliente” 76

Assim, passou-se a abastecer o Gfarm com alguns arquivos importados de CDs, do servidor Windows ou de portais da Internet. Por exemplo:

1. bcdr.pdf (5MB) – arquivo no formato Portable Document Format, da Adobe, a ser acessado pelo aplicativo Adobe Acrobat Reader. 2. warriors.mpeg (155MB) – arquivo de filme educativo sobre o funcionamento do TCP/IP

Ambos foram introduzidos com o comando gfimport_fixed, o qual permite importar arquivos de sistemas de arquivo convencionais para o Gfarm, particionados em vários fragmentos. O comando, de forma análoga ao gfimport_text (quadro 32), foi executado usando-se o padrão:

$ gfsched –N 2 | gfimport_fixed –H - -o gfarm:/nome_do_diretório/nome do \ arquivo /nome_do_diretório/nome do arquivo ** Onde N define o número de nós (fragmentos). Neste exemplo, 2 fragmentos.

O particionamento ficou como segue:

1. bcdr.pdf – 2 fragmentos de mesmo tamanho: 1 em dfsrv3 e outro em dfsrv2; 2. warriors.mpeg – 3 fragmentos de mesmo tamanho: 1 em dfsrv1, 1 em dfsrv2 e 1 em dfsrv3. 3. warriors.mpeg – 4 fragmentos de mesmo tamanho: 1 em cada nó - dfsrv1 a dfsrv4- após introdução do dfsrv4 no cenário.

Estes arquivos foram repetidamente copiados, movidos e renomeados dentro do Gfarm, atestando a funcionalidade do sistema de arquivos. Sua visualização pôde ser feita via browser Firefox (cópia de tela no Anexo B, figura 45) ou visualizador Nautilus. Alguns de seus fragmentos também foram replicados com o comando “gfrep”, permitindo certificar a tolerância a falhas. Os fsnodes puderam sofrer panes ou serem desligados, mas o acesso ao conteúdo desejado não foi afetado, desde que houvesse uma réplica disponível em qualquer outro nó. Os arquivos PDF foram abertos no Adobe Reader® tanto em Linux quanto em Windows, mas no Linux ele precisa ser aberto diretamente a partir do programa; se o Adobe Reader® for acionado indiretamente, ao clicar num arquivo PDF em janela de exploração gráfica, ocorre um erro de diretório desconhecido. Além de arquivos fragmentados, foram copiados outros de uso genérico, como planilhas e textos, além daqueles gerados pelos benchmarks de latência. Na execução do IOzone com opção “-Q” são gerados arquivos com dados sobre latência, os quais são armazenados no mesmo local onde o IOzone é executado. Uma listagem de diretório típica pode ser vista na figura 9, a qual mostra os arquivos de latência (extensão .dat) e uma peculiaridade em relação à propriedade dos arquivos. 77

Figura 9 – Listagem de diretório do Gfarm com o uso da biblioteca syscall-hook

Observa-se na parte superior da figura 9 que o usuário autenticado é o lab, fazendo com que todos os arquivos sejam apresentados como se fossem de sua propriedade. Contudo, como eles haviam sido criados pelo usuário root, não fora permitida qualquer alteração em conteúdo ou atributos. Na parte inferior, ao entrar no modo de super-usuário (root), nota-se que a propriedade de todos os arquivos acompanhou o novo usuário. Todavia, nestas condições foi possível fazer alterações, pois o usuário autenticado era o mesmo que detinha a propriedade real dos arquivos. Para visualizar como estavam armazenados os arquivos listados, utilizou-se o comando “gfwhere” ou o utilitário “gfront”, ambas ferramentas do Gfarm. Os resultados de ambas as ferramentas podem ser vistas na figura 10. Destaca-se que o “gfront” precisou do Java 1.4.2 ou superior, instalado nos nós em que foi executado.

Figura 10 – Visualização da localização de arquivos com “gfwhere” e “gfront” 78

No exemplo da figura 10, nota-se no “gfront”, à direita, que na parte inferior estão listados os nós que contém o arquivo marcado na parte superior (Mas06.tif). Neste caso, o arquivo Mas06.tif (43MB) foi fragmentado e armazenado em 4 partes iguais (nós dfsrv1 a dfsrv4). O “gfront” também mostra os nós registrados no metaserver, com seus respectivos estados funcionais, implementando uma interface gráfica para o comando “gfhost –l”. Ressalta-se que cada um dos nós foi utilizado sem restringir a quantidade de espaço em disco disponível, a qual pôde ser monitorada com o comando “gfdf”.

5.2 Benchmarks individuais

Inicialmente se executou o IOzone em cada um dos nós que compõem o cenário, visando uma avaliação dos seus sistemas de arquivos locais, incluindo os nós servidores de arquivos sobre máquinas virtuais. Os gráficos preliminares gerados a partir do IOzone, o qual gera arquivos temporários num diretório de trabalho corrente, podem ser vistos a partir da figura 11, os quais representam apenas o servidor de metadados. Para simplificar, os outros componentes do cenário são apresentados em caráter comparativo, como pode ser visto na figura 16. Os gráficos individuais e respectivas planilhas de dados podem ser observados no Anexo B.

Escrita - metasvr - LOCAL iozone -Rab Q0_loc_meta.wks -g 256M -i 0 -i 1

60000

50000

40000

50000-60000 40000-50000 Vazão (KB/s) 30000 30000-40000 20000-30000 20000 10000-20000 0-10000

16384 10000 4096 1024 256 0 64 Tamanho do registro (KB)

64 16 128 256 512

1024 4 2048 4096 8192 16384 32768 Tamanho do arquivo (KB) 65536 131072 262144

Figura 11 – IOzone local - Escrita – metasvr.grid.local

Reescrita - metasvr - LOCAL iozone -Rab Q0_loc_meta.wks -g 256M -i 0 -i 1

120000

100000

80000

100000-120000 80000-100000 Vazão (KB/s) 60000 60000-80000 40000-60000 40000 20000-40000 0-20000

16384 20000 2048

256 0 Tamanho do registro (KB) 32 64 128 256 512

1024 4 2048 4096 8192 16384 32768 Tamanho do arquivo (KB) 65536 131072 262144

Figura 12 – IOzone local – Reescrita - metasvr.grid.local

Leitura - metasvr - LOCAL iozone -Rab Q0_loc_meta.wks -g 256M -i 0 -i 1

250000

200000

200000-250000 150000 150000-200000 Vazão (KB/s) 100000-150000 50000-100000 100000 0-50000

50000 16384 2048

256 0 Tamanho do registro (KB) 32 64 128 256 512

1024 4 2048 4096 8192 16384 32768 65536

Tamanho do arquivo (KB) 131072 262144

Figura 13 – IOzone local – Leitura - metasvr.grid.local

Releitura - metasvr - LOCAL iozone -Rab Q0_loc_meta.wks -g 256M -i 0 -i 1

300000

250000

200000 250000-300000 200000-250000 150000-200000 Vazão (KB/s) 150000 100000-150000 50000-100000 0-50000 100000

16384 50000 2048

256 0 Tamanho do registro (KB) 32 64 128 256 512

1024 4 2048 4096 8192 16384 32768 65536

Tamanho do arquivo (KB) 131072 262144

Figura 14 – IOzone local – Releitura - metasvr.grid.local

As figuras de 11 a 14 mostram o desempenho do servidor de metadados do Gfarm, cuja operação se baseia no acesso pelo LDAP (Lightweight Directory Access Protocol), permitindo acessar o banco de dados de metadados. Na figura 15 mostra-se uma visualização diferente, sendo possível acompanhar as linhas de tendência das vazões de cada combinação de tamanho de arquivo e tamanhos de registro.

Leitura - metasvr - LOCAL iozone -Rab Q0_loc_meta.wks -g 256M -i 0 -i 1

250000

Tamanho do registro 200000 (KB) 4 8 16 150000 32 64 128 256 Vazão (KB/s) 100000 512 1024 2048 4096

50000 8192 16384

0 64 128 256 512 1024 2048 4096 8192 16384 32768 65536 131072 262144 Tamanho do arquivo (KB)

Figura 15 - IOzone local – Leitura - metasvr.grid.local – visualização com linhas 81

Vê-se como exemplo na figura 11, que o pico de escrita é de aproximadamente 51.000 KB/s para arquivos de 256KB com registros de 64KB. Já na operação de reescrita, este pico passa para 115.000KB, indicando que o sistema executa a operação em área de cache do processador, ainda encerrando os dados que posteriormente passarão para o armazenamento persistente em disco. No caso da leitura (figuras 13 e 15), observa-se uma anomalia de queda abrupta de desempenho com arquivos de 128KB e registros de 16KB, que apresentam uma vazão de 123.663KB/s, contra cerca de 200.000KB para arquivos de 64 e 128KB e registros de 4KB; e 176.567 KB para registros de 32KB. A mesma queda é observada proporcionalmente nas operações de releitura no gráfico da figura 13. Todos os componentes do Gfarm - incluindo os clientes - passaram pelos mesmos testes individuais com o IOzone. O gráfico da figura 16 mostra o desempenho de sistema de arquivos local de cada nó, apresentando somente os valores de pico superior e inferior, além da média dos valores medidos. Contudo, no Anexo B é possível observar as combinações de tamanho de arquivo e tamanho de registro, das quais os valores de pico foram tomados.

Benchmark do sistema de arquivos de cada nó - vazões de pico e média

Escrita Reescrita Leitura Releitura Maior Menor Média Maior Menor Média Maior Menor Média Maior Menor Média metasrv 52695 6396 32158 115095 7520 52681 200003 17848 92100 265529 12579 102017 dfsrv1 = dfsrv2 (VMs) 31332 1822 15846 74371 2345 26250 350552 2150 206607 428042 2005 213234 dfsrv3 183919 28542 100278 484714 25627 182960 171027 29126 237373 1082626 28897 277577 dfsrv4 86695 12376 57485 146120 12371 82077 414081 9399 242395 876511 9455 275255 smbsvr 140068 10709 30740 140068 12168 49704 118515 8762 66004 140068 9327 69012 gfwks 115012 18620 80307 254501 21965 139319 410503 28139 255878 889379 25377 281376

Desempenho: sistema de arquivos local - individual

1200000 1000000 metasrv 800000 dfsrv1 = dfsrv2 (VMs) dfsrv3 600000 dfsrv4 400000 smbsvr Vazão (KB/s) gfwks 200000 0 Maior Maior Maior Maior Média Média Média Média Menor Menor Menor Menor Escrita Reescrita Leitura Releitura

Figura 16 – Desempenho individual de sistema de arquivos dos componentes do Gfarm

Destaca-se neste gráfico da figura 16, que o desempenho das VMs é cerca de 60% menor no pico superior de releitura, em comparação à máquina real dfsrv3, mas ainda supera o metasrv e o smbsvr, ambos máquinas reais. Por outro lado, as VMs apresentam o menor pico de desempenho em relação a todos os outros nós, em todas as operações. 82

Supõe-se que, dependendo das características físicas da máquina real e de preparo das condições de operação (ex.: desfragmentação de disco), pode-se compensar a queda de desempenho das VMs, ajustando-as dentro de cada cenário de utilização. Conhecidos os desempenhos individuais, pode-se planejar melhor o desempenho do conjunto, principalmente se o Gfarm for utilizado no modo de levar o processamento até os dados. Funcionando dessa forma, o desempenho da análise de dados será diretamente proporcional ao desempenho local de cada fsnode.

5.3 Avaliações de desempenho de alguns comandos básicos sob atrasos e uso de cache

No intuito de observar o desempenho em operações simples, alguns comandos básicos do Gfarm e do Linux para a administração de arquivos foram executados, adicionando-se atrasos para o metaserver e ativando-se o cache para notar sua influência. Esses comandos foram precedidos pelo programa “time”, o qual mede o tempo gasto real, o tempo em espaço de usuário e o tempo em sistema. Os resultados podem ser vistos nas figuras 17 a 20.

Efeito do cache do metaserver - comando "$ time gfls" (atraso de 3,5 s)

35,00

30,00 Sem cache 25,00 Com cache 20,00 15,00 Com cache "-m" 10,00 (1ª exec.) Tempo em segundos em Tempo 5,00 Com cache "-m" (2ª exec.) 0,00 real user sys Temporização

Figura 17 – Efeito do cache no comando “gfls” perante atraso de 3,5s para o metaserver

Destaca-se que, ao introduzir atrasos maiores que 3,5s para o metaserver, o “gfarm- agent” não fica em execução, entrando em operação apenas por alguns instantes, provavelmente pela existência de um controle de tempo para encontrar o metaserver. 83

Efeito do cache do metaserver - comando "$ time gfls" (atraso de 1,5s para o metaserver )

14,00

12,00 Sem cache

10,00 Com cache

8,00 Tempo em segundos Com cache "-m" 6,00 (1ª exec.) Com cache "-m" 4,00 (2ª exec.)

2,00

0,00 real user sys Temporização

Figura 18 - Efeito do cache com opção “-m” no comando “gfls” perante atraso de 1,5s para o metaserver

Nas figuras 17 e 18 observa-se o uso da opção “-m” na inicialização do cache do metaserver para diferentes valores de atraso. Como a opção ativa o cache de caminho (path), o efeito é significativo a partir da segunda execução do comando, pois na primeira, o cache ainda encontra-se vazio. Isto não ocorre para o cache sem a opção “–m”, o qual apresenta o mesmo comportamento desde a primeira execução, pois sua formação ocorre na inicialização do comando “gfarm_agent”.

Efeito do cache do metaserver - comando "$ time ls" (atraso de 3,5 s)

20,00 18,00 Sem cache 16,00 14,00 12,00 Com cache 10,00 8,00 6,00

Tempo em segundos Tempo em 4,00 Com cache "-m" 2,00 0,00 real user sys Temporização

Figura 19 - Efeito do cache no comando “ls” perante atraso de 3,5s para o metaserver 84

Além do comando “gfls”, executou-se seu análogo “ls”, nativo do Linux, no intuito de observar alguma mudança de comportamento (figura 19). Notou-se que o comando “ls” também sofre os efeitos do atraso até o metaserver. Isso é devido ao uso da biblioteca syscall-hook, a qual intercepta todos os comandos aplicados no shell de cada usuário. Assim, em nós com a biblioteca instalada, problemas de acesso ao metaserver podem provocar perda de desempenho significativa, fazendo do cache um recurso importante. Além dos comandos básicos de listagem, efetuou-se a cópia do arquivo com o comando “time cp gfarm:/lab/sm_clj2550.pdf gfarm:/test/” (10MB) entre diretórios do gfarm sob efeito de atraso de 3,5s para ao metaserver, cujos resultados estão na figura 21.

Efeito do cache do metaserver - comando "$ time cp" (atraso de 3,5 s)

70,00

60,00 Sem cache (momento 1) 50,00

40,00 Sem cache (momento 2) 30,00 Com cache 20,00 Tempo em segundos em Tempo 10,00

0,00 real user sys Temporização

Figura 20 – Efeito do cache de metaserver no comando de cópia “cp” entre diretórios do Gfarm

O comportamento se destaca pela queda de desempenho, mesmo ao ativar o cache. Contudo, em testes posteriores, verificou-se que a mesma cópia levou apenas 1,8s para ocorrer, mas utilizando-se o comando “gfcp” do Gfarm. Ressalta-se que a diferença entre os comandos está na não necessidade da biblioteca syscall-hook, acionada na execução do comando “cp” em conteúdos do Gfarm. Todavia, deve-se levar em conta que a cada ação de cópia, não se pode garantir que o arquivo esteja sendo gravado no mesmo servidor. Como o Gfarm distribui o conteúdo, pode- se a cada rodada ter um destino diferente, provocando desempenhos distintos. Nos gráficos do MRTG, presentes no final do Anexo B, observam-se exemplos do comprometimento de cada nó, coletados durante a execução dos testes subseqüentes – mais abrangentes -, nos quais se destacam suas variações de tráfego e carga de trabalho, que provocam diferentes números de desempenho.

5.4 Avaliações de desempenho de conjunto: Gfarm operando – versões 1.2-5 (1.2 PL4) e 1.3.1

Os resultados que estão apresentados a seguir, com gráficos gerados a partir das planilhas do IOzone e monitorados com MRTG (vide exemplo no final do Anexo B), foram obtidos executando-o no Gfarm versões 1.2-5 (1.2 PL4) e 1.3.1, conforme os seguintes critérios:

a) A partir do smbsvr em ponto de montagem virtual do Gfarm /gfarm, provocando o acionamento de todos os nós alternadamente devido ao algoritmo de file-affinity, sem introduzir alterações nas características da rede; b) A partir do smbsvr em ponto de montagem virtual do Gfarm /gfarm, provocando o acionamento de todos os nós alternadamente devido ao algoritmo de file-affinity, introduzindo um retardo de 250 ms no acesso ao metasvr; c) A partir do smbsvr em ponto de montagem virtual do Gfarm /gfarm, provocando o acionamento de todos os nós alternadamente devido ao algoritmo de file-affinity, limitando a largura de banda do circuito até o dfsrv2 em 56 Kbps; d) As ações dos itens a) e b) foram repetidas com o uso do gfarm-agent no smbsvr e em três dos nós servidores de arquivos (parâmetros no “gfarm.conf”).

Basicamente se procurou fazer uso do Gfarm como um sistema de arquivos Internet, de uso genérico, operando como repositório distribuído e organizado num espaço de nomes único, sem preocupação com processamento paralelo, focando o acesso a partir de estação unicamente “cliente”. Quem cumpriu inicialmente a função de estação unicamente “cliente” foi o smbsvr, que operou como servidor somente para as estações Windows. A função de fsnode não poderia ser exercida por ele porque estão instaladas as bibliotecas syscall-hook para habilitar a integração entre o Windows e o Gfarm. Um segundo cliente em máquina real foi adicionado ao cenário, o gfwks, a partir do qual o IOzone foi executado, mantendo-se a premissa de usar o Gfarm como um sistema de arquivos Internet de uso genérico, como repositório. 86

Gfarm 1.2-5 e 1.3.1 - influência de atraso para o metaserver

Escrita Reescrita Leitura Releitura Maior Menor Média Maior Menor Média Maior Menor Média Maior Menor Média Gfarm 1.2-5 - smbsvr - 4 nós 7148 1254 5379 7519 1826 5882 202606 743 13620 189331 796 13397 Gfarm 1.2-5 - smbsvr - 4 nós - atraso de 250ms 7218 1707 5487 7434 1319 5603 218420 732 13354 207734 734 13402 Gfarm 1.3.1 - smbsvr - 4 nós 6414 1215 4576 6536 1493 4877 8262 1697 5539 8379 1896 5591 Gfarm 1.3.1 - smbsvr - 4 nós - atraso de 250ms 6397 1087 4299 6573 1304 4423 8320 1663 4907 8181 1133 4947

Gfarm 1.2-5 e 1.3.1 - influência de atraso para o metaserver

1000000

100000 Gfarm 1.2-5 - smbsvr - 4 nós 10000 Gfarm 1.2-5 - smbsvr - 4 nós - atraso de 250ms 1000 Gfarm 1.3.1 - smbsvr - 4 nós

Vazão (KB/s) Vazão 100 Gfarm 1.3.1 - smbsvr - 4 nós - atraso de 250ms 10

1 Maior Maior Maior Maior Média Média Média Média Menor Menor Menor Menor Escrita Reescrita Leitura Releitura Operação

Figura 21 – Desempenho do Gfarm nas versões 1.2-5 (1.2 PL4) e 1.3.1, com e sem atraso para o metaserver (itens a e b)

No gráfico da figura 21, observa-se o desempenho do Gfarm comparado entre suas versões, com e sem atraso (250ms) para o metaserver. Observa-se que independente da versão, as vazões de pico ficam na faixa entre 6.000 e 8.500 KB/s, exceto para as operações de leitura e releitura na 1.2-5 (1.2 PL4), que ultrapassaram a casa dos 200.000 KB/s. Supõe-se que na versão 1.2-5 (1.2 PL4), as APIs se beneficiavam de alguma forma de cache (processador, por exemplo) para arquivos e registros de pequeno tamanho, o que foi alterado na versão 1.3.1. Outro ponto de destaque é o melhor desempenho geral da versão 1.2-5 (1.2 PL4), com valores de pico e médias maiores, exceto nos picos inferiores para as operações de leitura e releitura, nas quais a 1.3.1 foi maior. Adicionalmente, destaca-se que o atraso de 250ms para o metaserver não acarretou quedas significativas de desempenho, e consequentemente, não se sentiria grande efeito da ativação do cache na versão 1.3.1, como pode ser visto na figura 22, a seguir:

Gfarm 1.3.1 - influência do cache do metaserver perante atraso para o metaserver (metasrv)

Escrita Reescrita Leitura Releitura Maior Menor Média Maior Menor Média Maior Menor Média Maior Menor Média Gfarm 1.3.1 - smbsvr - 4 nós 6414 1215 4576 6536 1493 4877 8262 1697 5539 8379 1896 5591 Gfarm 1.3.1 - smbsvr - 4 nós - atraso de 250ms 6397 1087 4299 6573 1304 4423 8320 1663 4907 8181 1133 4947 Gfarm 1.3.1 - smbsvr - 4 nós - atraso de 250ms - com cache do metaserver em smbsvr 6297 521 4147 6418 581 4268 8246 573 4946 8212 553 4943 Gfarm 1.3.1 - smbsvr - 4 nós - atraso de 250ms - com cache do metaserver em smbsvr + 3 nós 6423 1221 4229 6616 1469 4547 8490 1060 4900 8493 1796 4973

Gfarm 1.3.1 - influência do cache do metaserver

10000 Gfarm 1.3.1 - smbsvr - 4 nós

1000

Gfarm 1.3.1 - smbsvr - 4 nós - atraso de 250ms 100

Vazão (KB/s) Gfarm 1.3.1 - smbsvr - 4 nós 10 - atraso de 250ms - com cache do metaserver em smbsvr 1 Gfarm 1.3.1 - smbsvr - 4 nós Maior Menor Média Maior Menor Média Maior Menor Média Maior Menor Média - atraso de 250ms - com cache do metaserver em Escrita Reescrita Leitura Releitura smbsvr + 3 nós Operação

Figura 22 – Influência do cache do metaserver em atrasos para o metaserver no Gfarm 1.3.1 (item d)

Observa-se ainda na figura 22 que a vazão média se manteve consistente na faixa entre 4.000 e 5.600 KB/s com picos maiores entre 6.000 e 9.000 KB/s, independente de atraso e eventual ativação de cache; com vantagem para as operações de leitura e releitura. A alteração mais significativa está no menor pico inferior em todas as operações, para a presença de atraso de 250ms para o metaserver e cache ativado somente no smbsvr. Quando o cache foi ativado em outros três nós, o pico inferior aumentou em todas as operações. Deve-se levar em conta que os resultados de pico estão associados a combinações específicas de tamanho de arquivo e registro. Como o algoritmo seleciona elementos diferentes durante os benchmarks, nem sempre o responsável pelos valores é o mesmo nó. Assim, variações são esperadas e normais. Além disso, como pode ser visto nas figuras obtidas com o MRTG, presentes no Anexo B, o metaserver não seria exigido o suficiente nesse ambiente de teste limitado, para provocar grande interferência devido a atrasos. Nos gráficos MRTG no Anexo B, podem ser vistos os comportamentos de tráfego, além das conexões TCP, memória e disco de cada nó, durante a execução dos testes nos horários determinados (figuras 39 a 44). Por outro lado, o desempenho foi realmente muito reduzido quando se introduziu limitação significativa na largura de banda de um dos fsnodes. Nesse teste, a largura de banda do canal de comunicação entre o smbsvr e o dfsrv2 foi configurada em 56Kbps, emulando um canal de banda larga em momentos de alta concorrência, ou uma linha discada. Adicionalmente se introduziu um atraso de 250ms para o metaserver e ativou-se o cache para o metaserver em smbsvr, mas isto não alterou os números. Os resultados podem ser observados na figura 23.

Benchmark - Gfarm 1.3.1 - 4 nós - atraso de 250ms com cache para o metaserver e largura de banda de 56Kbps para dfsrv2 - Vazões de pico e médias

Escrita Reescrita Leitura Releitura Maior Menor Média Maior Menor Média Maior Menor Média Maior Menor Média Gfarm 1.3.1 - 4 nós - atraso de 250ms com cache - largura de banda de 56Kbps para dfsrv2 6417 52 3357 6633 52 3513 8286 52 4069 8334 52 4099

Gfarm 1.3.1 - 4 nós - atraso de 250ms com cache - largura de banda de 56Kbps para dfsrv2 10000 1000 100 10

Vazão (KB/s) 1 Maior Maior Maior Maior Média Média Média Média Menor Menor Menor Menor Escrita Reescrita Leitura Releitura Operação

Figura 23 – Influência da largura de banda entre nós no Gfarm 1.3.1 (item c)

Na figura 23, destaca-se a baixíssima vazão de pico inferior para todas as operações, a qual ficou na casa dos 52KB/s, em decorrência da largura de banda limitada em 56Kbps, imposta entre smbsvr e dfsrv2. Como o algoritmo considera menor carga de processamento, proximidade dos dados ou RTT (round trip time) para a escolha do fsnode, a menor largura de banda não impediu a escolha do dfsrv2 nas operações. Assim, supõe-se que sua escolha implicou nas piores vazões. Uma forma de evitar esse efeito negativo seria incluir a largura de banda no algoritmo do Gfarm. Numa outra sessão de testes, observou-se o desempenho do conjunto ao evitar o uso de VMs, no intuito de determinar o nível de comprometimento na vazão. A figura 24 mostra que o nível da vazão de pico superior não foi afetado significativamente, mantendo-se próximo dos 9.000KB/s nas operações de leitura e releitura. As médias melhoraram em relação ao resultado com a presença de VMs (figura 22), subindo para a faixa de 6.000 a 8.500 KB/s. Em testes confirmatórios posteriores, os resultados não mostraram grandes diferenças, independente da presença de atraso e cache para o metaserver.

Benchmark - Gfarm 1.3.1 - smbsvr - atraso de 1000ms para o metaserver - 2 nós (dfsrv3 & dfsrv4 - máquinas reais) - Vazões de pico e médias

10000

1000

Maior vazão (KB/s) 100 Menor vazão (KB/s) Vazão média (KB/s) Vazão (KB/s)

1 Escrita Reescrita Leitura Releitura Operação

Figura 24 – Gfarm 1.3.1 – 2 nós (dfsrv3 e dfsrv4 – máquinas reais) – atraso de 1s para o metaserver

Quanto aos picos menores, observa-se ainda na figura 24, que caiu abruptamente para 7 KB/s, mas é preciso levar em consideração que isso ocorreu apenas para arquivos de 8192 KB com registros de 8KB; fato que pode ter ocorrido por lentidão excessiva de um dos fsnodes durante o teste, sem causa conhecida. O Gfarm também foi avaliado empregando-se dois clientes acessando-o em concorrência. Os clientes gfwks e smbsvr foram usados para esta finalidade, nos quais se executou o IOzone com os mesmos parâmetros dos testes anteriores. Os resultados podem ser vistos na figura 25. Em regime de concorrência, nota-se que as vazões de pico permanecem na faixa de 8.000 a 9.000 KB/s, com as médias caindo para a faixa entre 5.000 e 6.000 KB/s. Durante operações concorrentes, a alternância entre os nós aumenta, pois a cada operação o algoritmo fará uma escolha para cada cliente concorrente, acionando diferentes combinações de fsnodes a cada rodada. Assim, a probabilidade de uso dos fsnodes mais lentos aumenta durante o período de execução do benchmark. Apesar de o teste ter ocorrido com o cache para o metaserver ativado em três dos fsnodes, isso não teve relevância nos resultados, pois não foram introduzidas dificuldades contornáveis pelo uso do cache. Como visto nos comentários da figura 22, o cache em três nós teve efeito apenas nos picos menores, quando havia atraso para o metaserver. Estes resultados podem ser vistos no último conjunto de gráficos do MRTG, presente no Anexo B, o qual corresponde a este benchmark (figuras 42 a 44).

Benchmark concorrente Gfarm 1.3.1 com cache em 3 nós - clientes gfwks e smbsvr

10000

9000

8000

7000

6000 Maior Vazão (KB/s) 5000 Menor Vazão (KB/s) Vazão Média (KB/s) Vazão (KB/s) 4000

3000

2000

1000

0 Escrita Reescrita Leitura Releitura Operação

Figura 25 – Gfarm 1.3.1 – benchmark concorrente gfwks e smbsvr – com cache em 3 nós

5.5 Avaliação comparativa com o NFSv4.fc5

O desempenho do Gfarm também foi comparado com uma solução tradicional de sistema de arquivos em rede, o NFS, que é usado tipicamente com o mesmo escopo com que o Gfarm foi testado, exceto pela ausência de um espaço de nomes único e da federação de espaço de armazenamento distribuído. O IOzone foi executado sobre o ponto de montagem NFS “/home/lab”, utilizado como diretório home dos usuários, além de ser ponto de distribuição da chave de segredo compartilhado. 91

Comparativo entre LOCAL, NFS e GFARM (1.2.5 e 1.3.1) usando dfsrv4

Escrita Reescrita Leitura Releitura Maior Menor Média Maior Menor Média Maior Menor Média Maior Menor Média dfsrv4 NFS em /home/lab 296949 5014 137593 367791 5188 147018 415541 5232 236932 673956 5260 254580 dfsrv4 LOCAL 86695 12376 57485 146120 12371 82077 414081 9399 242395 876511 9455 275255 dfsrv4 Gfarm 1.2-5 123102 18753 82510 312333 21727 141727 477453 10275 252057 913701 9806 287020 dfsrv4 Gfarm 1.3.1 116995 14001 78615 273522 13227 129455 450991 9420 248090 913707 9343 278574

Comparação entre sistemas de arquivo LOCAL, NFS, Gfarm 1.2-5 e 1.3.1 - nó dfsrv4 -

1000000 900000 800000 700000 600000 dfsrv4 NFS em /home/lab 500000 dfsrv4 LOCAL 400000 dfsrv4 Gfarm 1.2-5

Vazão (KB/s) Vazão 300000 dfsrv4 Gfarm 1.3.1 200000 100000 0 Maior Maior Maior Maior Média Média Média Média Menor Menor Menor Menor Escrita Reescrita Leitura Releitura

Figura 26 – Comparativo de desempenho entre sistema de arquivo LOCAL, NFSv4.fc5 e Gfarm 1.2-5 (1.2 PL4) / 1.3.1 – nó dfsrv4 – valores de pico e médios

O gráfico da figura 26 mostra os valores de pico e médios referentes aos benchmarks realizados utilizando-se apenas o nó dfsrv4. Esta foi a forma de estabelecer alguma comparação direta do Gfarm com o NFS, pois ao empregar vários nós de armazenamento, a operação do Gfarm tende a usá-los conforme a escolha de um algoritmo do qual o NFS não dispõe. Usando apenas um nó, equilibrou-se a forma de operação para compará-los. Assim, nota-se que o NFS tem maior desempenho nas operações de escrita, chegando a ser três vezes maior em relação à operação LOCAL do nó. A existência de cache no NFS é determinante para estes números, além das diferenças de desempenho entre os dispositivos de armazenamento e seus canais de comunicação em cada nó. Observa-se que ambas as versões do Gfarm têm desempenhos muito próximos, com maior destaque nas operações de releitura. Ressalta-se que, ao utilizar um único nó, sendo ele um fsnode, a operação ocorre localmente, graças à operação do algoritmo de file-affinity. Todavia, o desempenho médio é equilibrado entre os quatro sistemas de arquivos analisados, principalmente nas operações de leitura.

5.6 Latência

Complementando os testes, foram executadas quatro rodadas incluindo-se a geração de arquivos com dados sobre latência. Foram gerados dois conjuntos com gráficos, sendo um gráfico para cada operação (leitura, releitura, escrita e reescrita). Contudo, os testes de latência mostraram-se muito longos devido ao acúmulo de dados referentes a cada operação, segmentados conforme os tamanhos de arquivo e registros. O grande volume de dados coletados impede uma mostra completa de todos os eventos. Assim, foram selecionadas algumas seções de cada conjunto, as quais se encontram nos gráficos das figuras 27 a 29.

Latência - Leitura - Gfarm 1.2-5 (3 nós) - Arquivo = 64KB - Tempos = 0,001s iozone -QRab /root/Q10_gfarm.wks -g 256M -i 0 -i 1

60 50 s μ 40 Transfer. (bytes) 30

Tempo em em Tempo 20 4096 8192 10

0 0 4 8 12162024283236404448525660 Offset (KB)

Figura 27 – Latência de leitura – Arquivo de 64KB – Gfarm 1.2-5 (1.2 PL4) – 3 nós

Observa-se nestes gráficos uma anomalia de elevação abrupta da latência, em períodos determinados pelos incrementos no tamanho dos arquivos promovidos pelo IOzone. Como os arquivos com os dados de latência são obrigatoriamente gravados no mesmo diretório em que o benchmark está executando, ocorre uma interrupção momentânea no teste, já que esse diretório de execução é o próprio ponto de montagem virtual “/gfarm”.

Latência - Leitura - Gfarm 1.2-5 (3 nós) - Arquivo de 512KB - Tempo = 0,064s iozone -QRab /root/Q10_gfarm.wks -g 256M -i 0 -i 1

10000

1000

Transfer.

s (bytes) P

100 4096 Tempo em

0 0 0 20 40 60 80 100 120 140 160 180 20 220 240 260 280 300 320 340 360 380 400 420 44 460 480 500 Offset (KB)

Figura 28 - Latência de leitura – Arquivo de 512KB – Gfarm 1.2-5 (1.2 PL4) – 3 nós

Nota-se também que, na versão 1.2-5 (1.2 PL4) do Gfarm, aqueles picos grandes nas operações de leitura e releitura com arquivos pequenos, se traduziram em latências muito baixas, confirmando que as APIs faziam uso de algum cache.

Latência - Leitura - Gfarm 1.3.1 - 4 nós - Arquivo = 128MB - Tempo = 42,466s iozone -QRab /root/gf131_lat_root_smbsvr_4n.xls -g 128M -i0 -i1

600000

500000

400000 Transfer. s

P (bytes)

300000 512KB Tempo em em Tempo 200000

100000

0 5120 360 720 10240 15 20480 25600 30 35840 40960 46080 51200 56320 61440 66560 71680 76800 81920 87040 92160 97280102400107520112640117760122880128000 Offset (KB)

Figura 29 - Latência de leitura – Arquivo de 128MB – Gfarm 1.3.1 – 4 nós 94

Na figura 29 observa-se o comportamento da latência em arquivos grandes, a qual se concentra numa faixa entre 150 e 200ms. Neste caso, notam-se alguns picos maiores com andamento regular, devido à gravação do próprio arquivo de latência no Gfarm. O pico acima de 500ms provavelmente ocorreu devido à lentidão excessiva de algum fsnode durante o teste, não tendo sido possível determinar a causa. A partir da versão 1.3.1, as latências se mantiveram em níveis parecidos em cada grupo de operações, proporcionalmente ao tamanho dos arquivos manipulados. No modo considerado pelos criadores do Gfarm, de levar o processamento até os dados, os efeitos da latência devido ao transporte de rede deixam de ser significativos, pois os movimentos são apenas de acesso ao metaserver.

5.7 Integração com os clientes Windows

No smbsvr foram configurados os compartilhamentos LAB e GFARM-PUB, sendo este último a montagem do diretório Gfarm no Samba, graças às bibliotecas syscall-hook. Após estabelecido o servidor smbsvr como front-end do Gfarm para os clientes Windows, iniciaram-se as seguintes operações a partir de estações da rede (não pertencentes ao Gfarm: Acesso ao Gfarm pelo Windows; Vizualização de diretórios e arquivos; Criação de novos arquivos com aplicações do Microsoft Office 2003; Edição de arquivos com aplicações do Microsoft Office 2003; Alteração de nomes e outros atributos dos arquivos; Remoção de arquivos; Cópia de arquivos; Audiência de pequenos filmes no Windows Media Player 10.

Ao estabelecer o acesso ao servidor smbsvr, foi preciso efetuar o logon, assim como deve ser feito para qualquer servidor Windows com a segurança de compartilhamento ativada. O usuário utilizado para o logon deve ser comum entre o Gfarm e o Windows. Neste caso, utilizou-se o usuário lab. Cópias de tela mostrando o acesso podem ser vistas no Anexo B, figuras 46 e 47. Todas as operações transcorreram normalmente. Os arquivos para os quais existiam réplicas disponíveis puderam ser acessados sem interrupção, mesmo quando algum dos fsnodes ficara indisponível. Numa das rodadas de teste em que foi usado o servidor smbsvr como front-end, tentou-se assistir a um filme (warriors.mpeg – 12:57 min) a partir do Windows Media Player numa estação com Windows XP. Mas, após exatos 4:25 min, iniciaram-se interrupções seguidas no som e na imagem que tornaram a audiência impossível, mesmo com um único usuário. 95

Notou-se que a atividade do metasvr no que concerne ao disco crescera muito, indício de constantes pesquisas no LDAP, já que o arquivo de vídeo fora fragmentado em 3 partes, sendo duas delas armazenadas sob VMs. A hipótese inicial foi deficiência das VMs no quesito “desempenho em sistema de arquivos”. Dessa forma, foi inserido um quarto nó (dfsrv4) para manter todos os fragmentos em máquinas reais. Contudo, após realizar a inserção e configuração do dfsrv4, o efeito não desapareceu, mas teve seu tempo de ocorrência aumentado em 2 min, ou seja, aos 6:25 min. A anomalia foi contornada quando se ativou o cache do metasvr com o gfarm-agent, na versão 1.3.1 do Gfarm. Apesar de disponível nas versões anteriores a partir da 1.1.1, somente na 1.3.1 foi disponibilizado um roteiro automatizado para criar o arquivo de configuração do Gfarm, a ser usado nos nós que fariam uso do cache. O gfarm-agent foi ativado no próprio smbsvr, tornando local o acesso aos metadados, com exceção das informações de caminho (path), que se incorporam ao cache mediante o uso da opção “-m”, colocando o gfarm-agent em modo master. Ressalta-se que a anomalia não foi notada ao assistir ao mesmo filme a partir de um cliente Gfarm com Linux, utilizando-se o Mplayer ou o RealOne Player. Adicionalmente foram realizados benchmarks para avaliar o desempenho do Gfarm 1.3.1 quando acessado por clientes Windows via servidor SAMBA com a biblioteca syscall- hook. Os testes foram realizados mediante o uso de uma das estações Windows da rede Coverex, a brio-arpa. A partir dessa estação, executou-se o IOzone em discos mapeados na letra G, num primeiro momento acessando o Gfarm via SAMBA e, numa outra sessão, acessando o servidor SAMBA (smbsvr) simplesmente como servidor Windows. Os resultados podem ser visualizados na figura 30, que ainda traz dados do Gfarm 1.3.1 operando em modo Linux, para efeito de comparação.

Benchmark comparativo entre o acesso ao Gfarm com front-end SAMBA e direto a compartilhamento SAMBA - estação brio-arpa com Windows XP Pro - Vazões de pico e médias Escrita Reescrita Leitura Releitura Maior Menor Média Maior Menor Média Maior Menor Média Maior Menor Média Gfarm 1.3.1 - brio-arpa via smbsvr - 4 nós 1065 76 719 1057 76 733 888 137 779 889 161 786 Brio-arpa - acesso direto ao /home/lab em smbsvr 100124 830 17871 154192 1048 33191 1040 711 955 194062 919 100388 Gfarm 1.3.1 - smbsvr - 4 nós 6414 1215 4576 6536 1493 4877 8262 1697 5539 8379 1896 5591

Benchmark comparativo entre o acesso ao Gfarm com front-end SAMBA e direto a compartilhamento SAMBA - estação brio-arpa com Windows XP Pro 1000000

100000

10000

Gfarm 1.3.1 - brio-arpa via 1000 smbsvr - 4 nós Brio-arpa - acesso direto ao /home/lab em smbsvr Vazão (KB/s) 100 Gfarm 1.3.1 - smbsvr - 4 nós

1 Maior Maior Maior Maior Média Média Média Média Menor Menor Menor Menor Escrita Reescrita Leitura Releitura Operação

Figura 30 – Comparativo de desempenho do Gfarm 1.3.1 com front-end SAMBA, do modo nativo em Linux, e do ambiente de compartilhamento Windows direto no SAMBA

Nota-se que a vazão em modo front-end SAMBA é baixa, ficando na faixa de 800 a 1.100 KB/s nos picos maiores e em menos de 200 KB/s nos picos menores. O desempenho do acesso direto ao compartilhamento “/home/lab” é significativamente maior em releitura, ficando próximo a 200.000 KB/s; e seus picos menores ficaram próximos das melhores vazões do modo front-end. Esse resultado, apesar de ser baixo, era esperado devido a vários fatores como o acesso ao metaserver, execução do algoritmo e as conseqüentes diferenças de desempenho de cada nó selecionado para as operações. No modo direto, um único nó é acessado em todos os testes, não há acesso a qualquer metaserver e, principalmente, conta-se com o cache no lado cliente, ainda não disponível no Gfarm.

6 CONCLUSÃO

A computação em grid tem evoluído consistentemente desde seu aparecimento na década de 90. Idealizada no meio científico para federar recursos computacionais em pesquisas avançadas, gradativamente vem crescendo em adoção à medida que seus conceitos e propostas têm sido estabelecidos e caminhado para a padronização. Como um novo paradigma de computação distribuída, não se trata de uma solução tecnológica única, mas de uma combinação de diversas tecnologias, as quais se propõem a suportar grandes ambientes de colaboração, envolvendo pessoas e organizações. Destaca-se que os grids prevêem a formação de organizações virtuais, aproximando os usuários dos recursos computacionais necessários às soluções de complexos problemas a serem resolvidos. As áreas de Física de Altas Energias, Genética, Química e Pesquisa Aeroespacial são exemplos de geradoras de problemas complexos, tanto em volume de dados quanto em capacidade de processamento para analisá-los. Nota-se que a visão de arquitetura e funcionalidade da computação em grid considerada até o presente, define bem que é necessário um mapeamento entre as necessidades das aplicações e os recursos disponíveis na infra-estrutura, partindo-se de elementos individuais que, combinados, são apresentados às aplicações como recursos federados e padronizados. O mapeamento depende de software capaz de promover níveis de abstração elevados, considerando o acesso coordenado e controlado aos diversos elementos federados, os quais, considerando-se pertencerem a instituições distintas, podem ser aderentes a diferentes padrões tecnológicos. A abstração deve encobrir as peculiaridades de hardware, sistema operacional e compartilhamento de recursos. Vários tipos de grids têm sido considerados, associados ao tipo de recurso federado, como por exemplo, os grids de dados. Contudo, destaca-se que, dependendo do nível de colaboração exigido, múltiplas federações tomam lugar, envolvendo conjuntamente coleta de dados, processamento e armazenamento, mostrando que tipicamente as formas de grid aparecem combinadas: a necessidade de grande espaço de armazenamento, impossível de ser satisfeita a partir de um único local, geralmente está associada à posterior análise intensiva de dados, motivando também a agregação de capacidade de processamento. Essa proposta de agregar recursos mostra-se interessante também na área corporativa, pois observa-se que, devido à adoção freqüente da computação distribuída como solução para resolver problemas de negócio, existe capacidade disponível que pode ser aproveitada. Muitos são os desafios decorrentes da agregação de recursos e as pesquisas têm mostrado que, além de não haver uma solução única para todas as necessidades, ainda se caminha para a padronização. Todavia, mesmo que se atinja a padronização, dificilmente ela será abrangente de forma a englobar todas as formas de grid. É provável que se tenham padrões localizados de acordo com os grupos de pesquisa, assim como está ocorrendo com os grids de dados. Nessa forma de grid, que não pode ser vista isolada das demais, os grupos de trabalho têm procurado estabelecer, entre outros aspectos, como lidar com o armazenamento dos 98

dados, como acessá-los de forma transparente envolvendo diferentes plataformas, qual o melhor local para colocá-los e se devem ser replicados. Observa-se que para aplicações complexas que requerem computação de alto desempenho, explora-se a presença de canais de comunicação de alta velocidade para trazer os dados, ou utilizam-se mecanismos de cache com a replicação estratégica. O GridFTP apresenta-se como exemplo de solução para essa tática, permitindo download com paralelismo, mas com a forma de acesso similar ao FTP tradicional, o qual é limitado em funcionalidade. Contudo, grandes movimentos de dados nem sempre se mostram positivos quando os recursos de comunicação são parcos ou muito dispendiosos. Além disso, em computação de alto desempenho com clusters, é melhor usar processamento distribuído, o que requer mecanismos que o GridFTP não provê. Em outra proposta, as Redes Logísticas de Armazenamento com o IBP, observa-se igualmente uma maior preocupação com a federação de espaço e movimentação de dados, considerando levá-los até o local de processamento. O SRB do San Diego Supercomputer Center mostrou-se ser outra possibilidade, com um middleware cliente/servidor visando federação de armazenamento oriundo de discos ou fitas, mas de implementação considerada complexa. Destaca-se que o emprego de middleware nos grids é típico, devido à necessidade de abstração para esconder complexidades e diversidade de plataformas. Buscando uma estratégia diferente, surgiu o Grid Datafarm e seu sistema de arquivos Gfarm, com uma proposta mais completa e inovadora. Pode-se dizer que é única entre as soluções existentes na computação em grid. No Gfarm, pode-se empregar tanto hardware tradicional (commodity) como computação de alto desempenho, empregando equipamentos de grande porte ou clusters. Seus criadores adotaram a estratégia de enviar o processamento (aplicação) para o local onde os dados estão, mas isso não impede que se use o método mais tradicional de buscar os dados para análise. Ao levar o processamento, explora-se o desempenho do sistema de arquivos local de cada nó, enquanto o caminho inverso enfrenta obstáculos como atrasos, largura de banda limitada, congestionamento e grandes latências da infra-estrutura de comunicação. Seu sistema de arquivos considerado como de grid, incorpora importantes mecanismos – viabilizados por algoritmos e protocolos proprietários - como o balanceamento de carga, paralelismo e replicação. O algoritmo responsável por fazer o balanceamento, direcionando as operações para o nó mais próximo dos dados e com menor carga de trabalho pôde ser observado no experimento e mostrou-se consistente e estável. À medida que o Gfarm foi evoluindo desde a versão 1.1.1, novos seletores foram incorporados ao algoritmo, sendo que, a partir da versão 1.3.1, incorporou-se oportunamente o RTT (Round Trip Time) dos canais de comunicação que interligam os nós. A estes mecanismos se alia o suporte à autenticação e autorização de acesso, necessário aos ambientes de colaboração, fazendo-o uma combinação única de diversas funcionalidades providas por importantes sistemas de arquivos distribuídos como o AFS, PVFS e GFS. Um grande destaque observado no Gfarm foi o mapeamento lógico-físico viabilizado pelo servidor de metadados, o qual permite a fragmentação de grandes arquivos ou a combinação de múltiplos pequenos arquivos para o processamento distribuído em clusters. Todas estas funcionalidades, inicialmente idealizadas para o uso da comunidade científica, mostraram-se interessantes no uso corporativo, pois permitiram o aproveitamento 99

de recursos de armazenamento e processamento ociosos. No experimento realizado, armazenaram-se sob o Gfarm conteúdos típicos de biblioteca digital, como textos, arquivos PDF e pequenos vídeos, utilizando-se alternativamente a fragmentação e a criação de réplicas para atestar sua capacidade de tolerar falhas nos nós; algo efetivamente comprovado com os testes realizados. Quanto à forma de apresentação para os usuários, ofereceu uma visão lógica do armazenamento que não se distingue de um sistema de arquivos local, com transparência. No experimento, ao integrá-lo com o Windows via Samba (Linux), seus diretórios apareceram para os clientes Windows como verdadeiros compartilhamentos SMB, exceto pelos atributos de arquivo que não são totalmente correspondentes devido ao sistema de arquivos local ser ReiserFS. No ambiente de rede não era possível distinguir se os compartilhamentos eram de um servidor Windows ou não. Ressalta-se que neste trabalho, o Gfarm não foi experimentado como solução de alto desempenho, mas como um sistema de arquivos distribuído federando espaço de armazenamento de múltiplas estações de trabalho - locais ou dispersas geograficamente por emulação -, num ambiente produtivo misto com Linux Fedora, CentOS e Microsoft Windows SBS 2003. Apesar das importantes funcionalidades, mostrou-se ser uma solução com baixa complexidade de instalação e configuração, permitindo uma implantação funcional mínima em cerca de quatro horas, considerando-se a instalação do sistema operacional em novos equipamentos. Quanto à robustez, um dos componentes mais críticos é o servidor de metadados, sem o qual não é possível acessar os arquivos. Ainda assim, apesar de não contar com replicação, contornaram-se os momentos de indisponibilidade momentânea com o servidor de cache. No caso dos nós servidores, também são críticos quando os dados que hospedam não estão replicados. Nessas condições, se não contarem com tecnologia de tolerância a falhas, podem comprometer todo o sistema de arquivos. Considerando a atualização de versões, notou-se transparência até a versão 1.3.1, passando-se pela 1.1.1 e 1.2-5 (1.2 PL4). Todavia, na penúltima versão (1.3.1), os criadores modificaram o esquema do LDAP, além de introduzir o PostgreSQL como opção padrão de base de dados. A alteração de esquema no LDAP foi traumática, pois significou a perda completa dos metadados, impossibilitando o acesso aos arquivos previamente armazenados. Ressalta-se que os diretórios criados na implantação de cada nó servidor também foram alterados, resultando em inconsistência em relação à versão anterior, tanto que o configurador parou ao detectá-la. Além disso, na atualização, todos os elementos tiveram que receber a nova versão, impossibilitando preservar dados anteriores, ainda que parcialmente. Apesar de terem disponibilizado uma ferramenta de salvamento e restauração, ela não solucionaria esse caso, pois a estrutura sofrera profundas mudanças. Pode-se dizer que esta foi uma das maiores fraquezas encontradas no Gfarm em todo o período de experimentação. Quanto aos sistemas operacionais, tem sido desenvolvido para as principais distribuições Linux em uso na atualidade, tais como o Fedora, o CentOS e o Debian, suportando ainda o Sun Solaris, o FreeBSD e o NetBSD, mas não oferece suporte ao Windows. Contudo, ao empregarem-se máquinas virtuais, contornou-se tal limitação, fazendo com que o Gfarm fosse disponibilizado em toda a empresa sem alterar o ambiente de trabalho dos usuários, exceto pela instalação do software de VM, o Microsoft Virtual PC 2004. 100

O uso de VMs mostrou-se muito útil - apesar da queda de desempenho esperada, principalmente pela dupla abstração de sistema de arquivos - pois além da flexibilidade e manutenção do ambiente operacional dos usuários, permitiu a criação de novos nós servidores de arquivos do Gfarm, sem a necessidade de reinstalações. Bastaria copiar o arquivo com o disco virtual para o novo candidato a nó servidor e executá-lo sobre o software de VM, modificando apenas o endereço MAC, o nome de máquina e o endereço IP. Ainda na questão das VMs, a partir da penúltima versão do Gfarm, a 1.3.1, foi possível uma observação mais direta do benefício do uso de cache para o servidor de metadados, diminuindo o tempo de resposta no acesso ao sistema de arquivos, principalmente em cenários com canais de comunicação deficientes ou defeituosos. Utilizando-se VMs, podem-se criar rapidamente múltiplos caches do servidor de metadados, melhorando significativamente o desempenho nas operações de busca e obtenção de arquivos. No experimento realizado, utilizou-se o Microsoft Virtual PC 2004, mas poderia ter sido usado o VMWARE, ambos disponíveis em versões gratuitas. Ressalta-se que o efeito negativo em desempenho ao usar VMs, foi compensado pela praticidade e flexibilidade, necessárias em ambientes corporativos. Na questão de desempenho, os benchmarks com o IOzone executados no diretório virtual mostraram que o Gfarm, operando no modo tradicional de trazer os dados para processar, enfrenta latências que diminuem consideravelmente a velocidade das operações com arquivos. A distribuição das latências pôde ser observada de duas formas, com comportamentos distintos. Num primeiro teste, executando-se o IOzone a partir de um fsnode, manteve-se bom desempenho porque o algoritmo retém as operações com arquivos no próprio nó, por ser o mais próximo dos dados. Excluindo-se o tempo gasto com a obtenção dos metadados, mais o algoritmo, a vazão manteve-se próxima da obtida em acesso ao sistema de arquivos local. Nenhum outro nó foi envolvido enquanto este estava operando. Em seguida, ao executar-se o mesmo teste a partir de um cliente exclusivo, tal como o servidor Samba, os múltiplos fsnodes registrados passaram a ser usados alternadamente, provocando vazões variáveis; um comportamento esperado, mais uma vez em razão do algoritmo. A variação de vazão em função do nó escolhido leva à constatação de que para aplicações sensíveis ao tempo de resposta, a distribuição dos arquivos ou seus fragmentos precisaria ser estratégica, buscando a homogeneidade, ou deveria ser considerado o uso exclusivo de nós com desempenhos iguais; algo que poderia ser conseguido com benchmarks locais, antes de tornar o computador um fsnode. Apesar de ser único em suas características, o Gfarm foi comparado de forma simplificada com o NFS, apresentando um desempenho inferior dentro do cenário considerado. Um dos principais motivos deve-se ao acesso direto ao servidor NFS, não dependendo de servidor de metadados. Contudo, o NFS não provê os mecanismos de escalabilidade encontrados no Gfarm, razão pela qual sabe-se que, em computação de alto desempenho, a situação se inverte. Adicionalmente, o Gfarm apresentou uma visão completa de sistema de arquivos que o NFS não provê, não requerendo a configuração das tradicionais operações de “export” e montagem, no servidor e clientes, respectivamente. No experimento, o NFS foi empregado para compartilhar o diretório home dos usuários de forma a distribuir a chave de acesso, devido à sua maior adequação e simplicidade a essa funcionalidade. 101

Na questão de compatibilidade com aplicações existentes, mostrou-se bem integrado com as presentes no Linux, como os browsers Konqueror e Mozilla Firefox e os programas da família OpenOffice 2.0. Contudo, existiram dificuldades contornáveis em algumas ferramentas, como o Adobe Reader em reconhecer o diretório corrente quando ele foi montado via biblioteca syscall-hook. No experimento, optou-se por usar o diretório montado virtualmente ao invés de reescrever as aplicações com as APIs, mantendo-se um padrão de uso mais corporativo. Por fim, notou-se que a queda de desempenho ao operar na forma tradicional foi compensada pela federação de espaço multiplataforma, aliada à abstração de um sistema de arquivos que pode ser usado de forma genérica para a Internet; apesar de características que o definem como um sistema de arquivos de grid, aplicável e já testado em cenários de computação de alto desempenho, com resultados expressivos que já lhe garantiram uma premiação no Congresso SC05. Essa queda de desempenho também foi compensada pela replicação de dados, que conferiu ao Gfarm a classificação de “tolerante a falhas” nos fsnodes. Todavia, para que a tolerância a falhas seja mais abrangente, seria necessário que o servidor de metadados fosse tolerante a elas. Para isso, poder-se-ia usar alguma solução de alta disponibilidade como o Heartbeat ou o emprego de servidores tolerantes a falhas em hardware. Além da tolerância a falhas, destaca-se que a replicação pode aumentar o desempenho nas operações, pois o algoritmo contaria com um maior número de opções de escolha de nós para a execução das tarefas. Observando-se os resultados deste trabalho, pode-se considerar que o Gfarm reune condições de ser empregado como um sistema de arquivos para Internet, com implementação rápida e de média complexidade, principalmente com o uso associado de VMs, as quais viabilizaram uma contribuição adicional da pesquisa, pois foi criado um pacote em DVD contendo os elementos mínimos para criar ambientes de teste ou de produção, tanto no uso científico como no corporativo. Neste último, destacam-se a robustez e um desempenho aceitável para operar como repositório de arquivos genéricos ou em aplicações de biblioteca digital de forma limitada, considerando-se usá-lo com aplicações não preparadas. Como o Gfarm continua em desenvolvimento, esperam-se melhorias nessa forma de utilização, principalmente com a inclusão de cache no lado cliente. Mesmo com a disponibilidade e aplicabilidade de soluções como o Gfarm na indústria, ainda caminha-se para uma maior maturidade dos grids no que tange à padronização e às operações com VOs; e ainda não há um consenso sobre qual delas será adotada, mesmo que os cenários sejam parecidos. Nem sempre a afinidade encontrada na comunidade científica é encontrada na indústria, até por questões de livre concorrência no mercado. Todavia, internamente, as corporações podem se valer da abstração promovida pelos grids para melhor aproveitar investimentos já realizados em tecnologia, resolvendo novos problemas de negócio com serviços mapeados em múltiplos recursos de infra-estrutura.

102

6.1 Sugestões para trabalhos futuros

Como sugestões para trabalhos futuros, apresentam-se os seguintes itens:

Execução de microbenchmarks, possibilitando a análise de desempenho em diversos níveis. Adicionalmente, o sistema poderia ser instrumentado com NetLogger19, criando pontos de observação específicos; Alteração no algorítmo para selecionar largura de banda, além do RTT. Com isso, as operações em modo tradicional seriam beneficiadas pela escolha dos nós interligados pelos melhores canais de comunicação; Criar no algoritmo, mecanismos capazes de reconhecer o tipo de arquivo a ser armazenado. O sistema de arquivos poderia determinar a melhor estratégia de armazenamento para cada tipo de conteúdo, tornando o Gfarm aplicável a qualquer ambiente de utilização; Automatização na criação das réplicas. Criar uma interface a partir da qual se possa configurar e ativar a replicação automática, selecionando os melhores nós para receber as réplicas de fragmentos ou arquivos completos; Conjunto completo usando VMs (appliance), com manual de instruções, para distribuição do Gfarm para os usos científico ou corporativo. Neste trabalho já se iniciou a criação deste conjunto. No Anexo A, seção 12, pode-se observar a documentação básica para sua utilização; Transformar as APIs para a arquitetura .NET, tornando o Gfarm um sistema de arquivos de uso geral para Internet suportado em ambiente Microsoft, independente do uso de VMs, garantindo um desempenho superior; O Gfarm poderia ser considerado em análises forenses. Enormes quantidades de textos legais e evidências documentadas poderiam ser varridas em paralelo à procura de detalhes úteis para a defesa ou promotoria pública. Neste caso, se exploraria a estratégia nativa do Gfarm que é de levar o processamento até os dados armazenados.

19 O NetLogger (http://dsd.lbl.gov/NetLogger/) é, ao mesmo tempo, uma metodologia de análise de sistemas distribuídos e um conjunto de ferramentas para implementá-la. 103

REFERÊNCIAS BIBLIOGRÁFICAS

ALLCOCK, Bill et al. Data Management and Transfer in High Performance Computational Grid Environments. Parallel Computing Journal, Vol. 28 (5), pp. 749- 771, 2002. Disponível em: . Acesso em 15 out. 2005.

ATKINSON, Malcolm et al. Data Access, Integration, and Management. In: FOSTER, Ian; KESSELMAN, Carl. (eds). The Grid 2: Blueprint for a New Computing Infrastructure. Chapter 22, p. 391-393, San Francisco: Morgan Kaufmann, 2004.

BAKER, Mark, BUYYA Rajkumar, DOMENICO Laforenza. Grids and Grid technologies for wide-area distributed computing. Software: Practice and Experience, Volume: 32 Issue: 15, p.1437-1466, 2002.

BARHAM Paul et al. Xen and the Art of Virtualization. In Proceedings of 19th ACM Symposium on Operating Systems Principles (SOSP’03), 2003.

BASSI, Alessandro et al. Logistical Storage Resources for the Grid. In International Conference on Computational Science - (ICCS), Amsterdam, Netherlands, April 2002a. Disponível em: . Acesso em 20 fev. 2006.

______. The Internet Backplane Protocol: a study in resource sharing. In 2nd IEEE/ACM International Symposium on Cluster Computing and the Grid (CCGRID 2002), pages 194-201, May 2002b. Disponível em: . Acesso em 20 fev. 2006.

BELL, Gordon; GRAY, Jim; SZALAY, Alex. Petascale Computational Systems: Balanced CyberInfrastructure in a Data-Centric World. Letter to NSF the Cyberinfrastructure Directorate, September, 2005. Disponível em: . Acesso em 17 out.2005.

BERMAN, Fran; FOX Goeffrey; HEY, Tony. Grid Computing – Making the Global Infrastructure a Reality. USA: John Wiley & Sons, Ltd, 2002.

BERRISFORD, Peter et al. SRB in a Production Context. CCLRC e-Science Centre [2005]. Disponível em: . Acesso em 05 out. 2006.

BRAAM, Peter J.; NELSON, Phillip A. Removing bottlenecks in distributed filesystems: Coda & Intermezzo as examples. Proceedings of the 5th Annual Linux Expo, pages 131--139, 1999.

104

CARD R., TS’O T., TWEEDIE S. Design and Implementation of the Second Extended Filesystem. In Proceedings of the First Dutch International Symposium on Linux, ISBN 90 367 0385 9, 1995. Disponível em: . Acesso em 02 jan. 2006.

CARNS, Philip H. et al. PVFS: A Parallel File System for Linux Clusters. In Proceedings of the 4th Annual Linux Showcase and Conference, 2000. Disponível em: . Acesso em 15 out.2005.

CARSON Mark, SANTAY Darrin. NIST Net – A Linux-based Network Emulation Tool. USA: ACM SIGCOMM Computer Communication Review, Volume 33, Issue 3, pp 111 – 126, 2003.

CERN Disponível em: . Acesso em 26 nov. 2005.

CHERVENAK, Ann et al. The Data Grid: Towards an Architecture for the Distributed Management and Analysis of Large Scientific Datasets. Jornal of Network and Computer Applications, vol 23, nº 3, pp. 187-200, 2000. Disponível em: . Acesso em 15 out. 2005.

CHILAN, Christian M. IOzone: An Open Source File System Benchmark Tool. USA: NCSA HDF Technical Report, 2005. Disponível em: . Acesso em 25 out.2005.

COKER, Russel. Bonnie++ Disponível em: . Acesso em 25 out.2005.

DATAFARM. File access from existing applications: (README for syscall-hooking library). [2006]. Disponível em: . Acesso em 15 jan. 2006.

DAVIES, Nigel; FRIDAY, Adrian; STORZ, Oliver. Exploring the grid's potential for ubiquitous computing. Pervasive Computing, IEEE, Volume: 3, Issue: 2, p.74-75, April- June 2004.

DVN – Disco Virtual Nacional . Acesso em 24 jun. 2006.

FOSTER, Ian. Globus Toolkit Version 4: Software for Service-Oriented Systems. IFIP International Conference on Network and Parallel Computing, Springer-Verlag LNCS 3779, pp 2-13, 2005. Disponível em: . Acesso em: 15 out.2005.

______. Internet Computing and the Emerging Grid Nature Web Matters England: nature.com – Macmillan Publishers Ltd, 2000. Disponível em: . Acesso em 17 mai.2005.

105

FOSTER, Ian; KESSELMAN, Carl. (eds). The Grid 2: Blueprint for a New Computing Infrastructure. San Francisco: Morgan Kaufmann, 2004.

FOSTER, Ian; KESSELMAN, Carl; TUECKE, Steven. The Anatomy of the Grid – Enabling Scalable Virtual Organizations. International Journal of High Performance Computing Applications, 15 (3). 200-222. 2001. Disponível em: . Acesso em 12 jun. 2005.

FOSTER, Ian et al. The Physiology of the Grid – An Open Grid Services Architecture for Distributed Systems Integration. DRAFT. 6/22/2002. Disponível em: . Acesso em 12 jun. 2005.

FOSTER Ian. What is the Grid? A Three Point Checklist. USA: GRIDToday, July 20, 2002. Disponível em: . Acesso em 28 out.2004.

GFARM - Access Gfarm file system via Samba using Gfarm syscall-hooking library. 2006. Disponível em: . Acesso em 25 jan. 2006.

______– Gfarm Filesystem Installation Manual. 2006a. Disponível em: . Acesso em 10 ago. 2006.

______– Release Note. 2007. Disponível em: . Acesso em 07 fev. 2007.

______- Software Download. 2005. Disponível em: . Acesso em 12 mai. 2005.

______- Software Download. 2006b . Acesso em 20 set. 2006.

GHEMAWAT, Sanjay; GOBIOFF, Howard; LEUNG, Shun-Tak. The Google File System. In Proceedings of 19th ACM Symposium on Operating Systems Principles, 2003.

GIBSON, G.A. et al. A Cost-Effective, High-Bandwidth Storage Architecture. In Proceedings of the 8th Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS), 1998. Disponível em: . Acesso em 20 dez.2004.

GOLDBERG, R. P. Survey of virtual machine research IEEE Computer Magazine, vol. 7, no. 6, pp. 34–45, 1974.

GLOBUS – Toolkit . Acesso em 15 abr. 2006.

GSI – Grid Security Infrastructure . Acesso em 15 abr.2006.

106

HONEYCUTT Jerry. Microsoft Virtual PC 2004 Technical Overview USA: Microsoft, 2003. Disponível em: . Acesso em 30 out. 2005.

HOWARD, J.H. An Overview of the Andrew File System. Proceedings of the USENIX Winter Technical Conference, Dallas, TX Feb. 1988. Disponível em: . Acesso em 02 jan. 2006.

HPC WIRE StorCloud Initiative Recap for SC05, novembro, 2005. Disponível em: . Acesso em 20 out. 2006.

HUBOVSKY, Rainer; KUNZ, Florian. Dealing with Massive Data: from Parallel I/O to Grid I/O. Master’s Thesis. Institute for Applied Computer Science and Information Systems Department of Data Engineering, University of Vienna Rathausstr. 19/4, A-1010 Vienna, Austria, January 16, 2004. Disponível em: . Acesso em: 05 jan. 2006.

IPACS Benchmark . Acesso em 25 out.2005.

JAGATHEESAN, Arun. The GGF Grid File System Architecture Workbook. GGF Grid File System Working Group (GWD-I), Version 1.0, April, 2005. Disponível em: . Acesso em 01/02/2006.

KEAHEY, Katarzyna; DOERING, Karl; FOSTER, Ian. From Sandbox to Playground: Dynamic Virtual Environments in the Grid. In 5th Workshop on Grid Computing (Grid 2004), Pittsburgh, November, 2004. Disponível em:

LEFF, Avraham; RAYFIELD, James T.; DIAS, Daniel M. Service-level agreements and commercial grids. Internet Computing, IEEE, Volume: 7, Issue: 4, p.44- 50, July-Aug. 2003.

LIGON III, W. B.; ROSS, R. B. Implementation and Performance of a Parallel File System for High Performance Distributed Applications. In Proceedings of the Fifth IEEE International Symposium on High Performance Distributed Computing. 1996. Disponível em: . Acesso em 02 set.2004.

LINUX HOME NETWORKING. Quick HOWTO : Ch23 : Advanced MRTG for Linux, 2006. Disponível em: . Acesso em 20.jan.2006.

107

LOMBARD P.; DENNEULIN Y. nfsp: A Distributed NFS Server for Clusters of Workstations. Proceedings of the 16th International Parallel and Distributed Processing Symposium (IPDPS 2002). Disponível em: . Acesso em 28 out. 2004.

MONARC . Acesso em 25 out.2005.

MICROSOFT TECHNET. NTFS Technical Reference, 2003. Disponível em: . Acesso em 02 jan. 2006.

MPI FORUM. MPI: A Message-Passing Interface standard. Disponível em . Acesso em: 25 set.2005.

MRTG. Multi Router Traffic Grapher Disponível em: . Acesso em 20 fev. 2006.

NORCOTT, William D. IOzone Filesystem Benchmark USA: www.IOzone.org. [2005]. Disponível em . Acesso em 20 mar.2005.

PEREIRA, Manuel et al. Virtual File System Directory Service Specification. GGF Grid File System Working Group (GWD-R), Category: Recommendations, Sep. 2004. Disponível em: . Acesso em 01 fev. 2006.

PVFS2 Development Team Parallel Virtual File System Version 2. USA: PVFS.org. 2003. Disponível em . Acesso em 02 set.2004.

REISER4 Disponível em . Acesso em 02 jan. 2006.

SANDBERG R. et al. Design and Implementation of the Sun Network Filesystem. In Summer Usenix Conference Proceedings, pages 119–130, 1985.

SAMBA Disponível em: . Acesso em 26 nov. 2005.

SANDERS, David Fedora Core 3 Final Notes. [2005]. Disponível em: . Acesso em 24 dez. 2006.

SC05 - International Conference for High Performance Computing, Network, Storage and Analysis. Disponível em: . Acesso em 20 out. 2006.

SCHMUCK, Frank; HASKIN, Roger. GPFS: A shared-disk file system for large computing clusters. In Proceedings of the Conference on File and Storage Technologies (FAST’ 02), pp. 231-244, Jan. 2002.

108

SNIA. Common Internet File System (CIFS) Technical Reference. Revision: 1.0. 2002. Disponível em:

SIOP Scalable I/O Project Software Downloads Disponível em: . Acesso em 20 mar.2005.

SMITH, James E.; NAIR, Ravi. An Overview of Virtual Machine Architectures Excerpt from “Virtual Machines: Architectures, Implementations and Applications,” to be published by Morgan Kaufmann Publishers, 2004. Disponível em: . Acesso em 24 out.2005.

SMITH, James E. Virtual Machines Architectures, Implementations, and Applications Draft. USA: Elsevier Science, 2005a. Disponível em: . Acesso em 24 out.2005.

______. The Architecture of Virtual Machines IEEE Computer vol. 38, no. 5, pp. 32-38, May, 2005b. Disponível em: . Acesso em 24 out.2005.

STALLINGS, William. Operating Systems: Internals and Design Principles. 4.ed. Upper Saddle River: Prentice Hall. 2001.

TÁRRAGA, J. Teraserver: A scalable terabyte continuous media server. 2001. 111f. Thèse (Docteur ès Sciences Techniques) - École Polytechnique Fédérale de Lausanne, Lausanne, 2001.

TATEBE, Osamu et al. Grid Data Farm for Petascale Data Intensive Computing. Technical Report, Electrotechnical Laboratory, ETL-TR2001-4, 2001. Disponível em: . Acesso em 12 mai. 2005.

______. Grid Datafarm Architecture for Petascale Data Intensive Computing. In Proceedings of the 2nd IEEE/ACM International Symposium on Cluster Computing and the Grid (CCGrid2002), pp.102-110, Berlin, May 2002. Disponível em: . Acesso em 12 mai. 2005.

______. Gfarm v2: A Grid file system that supports high-performance distributed and parallel data computing. In Proceedings of the 2004 Computing in High Energy and Nuclear Physics (CHEP04), Interlaken, Switzerland, September 2004. Disponível em: . Acesso em 12 mai. 2005.

TATEBE, Osamu. Grid Datafarm: how to create binary packages from SRPM, Apgrid.org, Jun 2006. Disponível em: . Acesso em 25 jun. 2006.

THE ATLAS EXPERIMENT Disponível em: http://atlas.ch/ . Acesso em 24 nov. 2005.

109

THE GLOBUS ALLIANCE Disponível em: . Acesso em 24 nov. 2005.

THE TECHNICAL CHALLENGES OF ATLAS. Switzerland: Publications Section – Cern, 2000. Disponível em: . Acesso em 24 nov. 2005.

VENUGOPAL, Srikumar L; BUYYA, Rajkumar; RAMAMOHANARAO, Kotagiri. A Taxonomy of Data Grids for Distributed Data Sharing, Management and Processing. Technical Report, GRIDS-TR-2005-3, Grid Computing and Distributed Systems Laboratory, University of Melbourne, Australia, April 21, 2005. Disponível em: . Acesso em 24 jun. 2006.

VMWARE Disponível em: . Acesso em 12 jun. 2005.

YASUDA, Y., et al. Concept and Evaluation of X-NAS: a Highly Scalable NAS System. Proc. 20th IEEE/11th NASA Goddard Conference on Mass Storage Systems and Technologies(MSST 2003), 2003.

YASUDA, Y., et al. RX-NAS: A Scalable, Reliable Clustered NAS System. IPSJ Journal, Vol.46, No.1 pp. 197-210, 2005. Disponível em: . Acesso em 27 out. 2004.

UK e-Science Disponível em: . Acesso em 18 out. 2006.

XU, Ming; et al. Service Virtualization. In: FOSTER, Ian; KESSELMAN, Carl. (eds). The Grid 2: Blueprint for a New Computing Infrastructure. Chapter 14, p. 179-189, San Francisco: Morgan Kaufmann, 2004.

110

GLOSSÁRIO

appliance – equipamento construído para servir a uma função específica, podendo ser viabilizado pela composição de hardware e software específicos. autovacuum – em PostgreSQL, vacuum é uma rotina cujo objetivo é reclamar espaço ocupado por elementos removidos das tabelas. O termo acrescido do prefixo auto refere-se à execução automática da rotina. backbone – é a espinha dorsal de uma rede. A parte central de interconexão onde se conectam os principais nós e de onde se derivam as conexões para outras redes. benchmark – em computação, processo de aferição do comportamento de um elemento computacional, tipicamente orientado a desempenho. cache – área de armazenamento intermediário, tipicamente implementada para manter dados de acesso mais freqüente, evitando a busca e obtenção nos locais originais de armazenamento. checksum – número que indica o resultado de uma ou mais operações (algoritmo) sobre um conjunto de dados armazenados (um arquivo, no contexto deste trabalho), cujo objetivo é a verificação de integridade. cluster – trata-se de um grupo de computadores plenos (capazes de operar individualmente) interligados para realizar tarefas em conjunto como um recurso computacional unificado. driver – código de programa que faz a interface entre o sistema operacional e os dispositivos necessários de acordo com as operações sendo executadas. fail-safe – diz-se do dispositivo, equipamento ou sistema imune a falhas. front-end – linha de frente, no sentido de ser o primeiro como interface. grid – grade, no sentido de uma malha de interligação entre diversos elementossistemas computacionais. O termo é I tradicionalmente utilizado para fazer referência à forma como a rede de distribuição de energia elétrica é composta para levar a eletricidade aos consumidores de forma pervasiva. metadados – são dados que expressam características dos dados em si. No contexto deste trabalho, são informações sobre os dados armazenados que auxiliarão na dinâmica de acesso a eles no que tange à localização física e trânsito pelos meios de comunicação. middleware - software de interface entre camadas de aplicações distribuídas ou entre aplicações integradas em ambiente distribuído. Escondem a complexidade e promovem as chamadas às funções desejadas, o transporte pela rede e o retorno dos resultados.

111

nó(s) – um dos elementos conectados por uma rede, que eventualmente possui algum recurso a ser compartilhado pelas aplicações.

overheads – no contexto deste trabalho tratam-se de elementos suplementares utilizados nas operações de processamento, comunicações e armazenamento, consumindo recursos sem ser carga útil. petabyte – 1015 bytes red-black tree – estrutura de dados conhecida como árvore quase-balanceada, sendo um dos métodos preferidos de manter árvores de procura binária. script – arquivo no qual se incluem comandos ou instruções em seqüência a serem executadas num momento oportuno, de forma manual ou automática. shell – é o nome dado ao ambiente de trabalho do usuário, funcionando como uma interface para acessar programas e funcionalidades nos sistemas operacionais. Podem ter vários formatos disponíveis e ser customizáveis pelo usuário. swap – área em disco (partição) dedicada ao sistema de memória virtual de alguns sistemas operacionais, tal como o Linux. terabyte – 1012 bytes

112

ANEXO A – GUIAS DE INSTALAÇÃO/ CONFIGURAÇÃO ESPECÍFICOS

113

7 FEDORA CORE 3 SOBRE VM MICROSOFT VIRTUAL PC 2004

Trata-se do guia com notas originais de SANDERS (2005), traduzido do inglês, para possibilitar a instalação do Fedora Core 3 a ser hospedado em VM Microsoft Virtual PC 2004 (SP1 - versão 5.3.582.27). 1. Obter os 4 discos ou imagens ISO, além do disco ou imagem de recuperação. 2. Fazer o download do arquivo FedoreCore3.zip, a partir de . 3. Colocar o arquivo obtido no passo 2 num local de acesso compartilhado do Windows, no mesmo computador da VM ou em servidor a parte, accessível via Samba. 4. Criar uma VM (sugere-se 256MB de RAM ou mais, sendo possível instalar com apenas 128MB). 5. Realizar o boot a partir da primeira imagem ISO ou Disco 1. 6. Acionar tecla [ENTER] no prompt para uma instalação em modo gráfico. 7. Neste ponto pode-se escolher testar a fonte de instalação ou não. 8. Inicia-se a instalação gráfica. 9. Clicar (NEXT): considerando instalação em inglês. 10. Selecionar (ENGLISH) como linguagem. 11. Selecionar (US) como keyboard. 12. Selecionar (WORKSTATION) como tipo de instalação. 13. Selecionar (AUTOMATIC DISK PARTITION). 14. Na mensagem de warning, clicar em (YES). 15. Selecionar (REMOVE ALL PARTITIONS) e clicar (NEXT). Não há necessidade de rever (REVIEW PARTITIONS) o que será feito com as partições a serem criadas. 16. Na mensagem de warning, clicar em (YES). 17. Clicar em (NEXT) para selecionar o GRUB como boot loader (carregador). 18. Configuração de rede: pode-se usar DHCP, mas no caso de nó servidor, atribuir endereço IP estático, conforme planejamento do mapa de endereços. Escolha um nome para a máquina, o qual será o hostname. 19. Configuração de firewall e segurança selinux: pode-se ativá-los antecipadamente, mas em primeira implantação, desligá-los elimina eventuais falhas de serviços por bloqueio de segurança. 20. Selecionar linguagens do sistema. 21. Selecionar zona de tempo - fuso horário. 114

22. Entrar com a senha para o usuário root. 23. Selecionar (Customize Software Packages) - personalização de grupos de pacotes. 24. Selecionar os grupos de pacotes desejados, incluindo o (Windows Files Server) para ser possível acessar o compartilhamento aonde está o arquivo dos passos 2 e 3. 25. Clicar (NEXT) em “About to install”. 26. Clicar (CONTINUE) em “Required install media…”. 27. (Neste momento ocorre a formação do sistema de arquivos local). 28. (Na seqüência os pacotes são instalados e as fontes de instalação – imagens ISO ou Discos - vão sendo solicitadas). 29. Quando a instalação se completar, usar o menu do Microsoft Virtual PC 2004 para capturar a imagem ISO do disco de recuperação e em seguida reiniciar a VM . 30. Acionar [ENTER] para o RESCUE MODE. 31. Escolher (ENGLISH) como linguagem. 32. Selecionar (US) como keyboard. 33. Selecionar (YES) em “Start Networking”. 34. Vide passo 18. 35. Clicar (CONTINUE) para procurar local de instalação. 36. Clicar (OK). 37. No prompt do shell, digitar: chroot /mnt/sysimage 38. Ao retorno do prompt, digitar: smbclient //”servidor windows”/”compartilhamento” –U “usuário”. O “servidor windows” e o “compartilhamento” correspondem ao passo 3. O “usuário” refere-se ao processo de autenticação no servidor. Se o acesso ao compartilhamento Windows falhar, mas a VM tiver conectividade com a Internet, pode-se usar o comando: wget http://www.sandersweb/net/david/virtualpc/FedoraCore3.zip. Se o commando for usado, avançar para o passo 42. 39. Entrar a senha para o servidor do compartilhamento Windows, se for o caso. 40. Digitar get FedoraCore3.zip. 41. Digitar quit. 42. Digitar unzip –o FedoraCore3.zip. 43. Digitar rpm –ihv –force kernel-2.6.9-vpc.i686.rpm. O processo durará algum tempo e o erro “failed to start /dev/shm” pode ser ignorado. 44. Terminado o passo 43, a imagem ISO de recuperação pode ser liberada no menu de opções do Virtual PC 2004. 115

45. Acionar (EXIT). 46. Acionar (EXIT). 47. Neste ponto ocorre a reinicialização da VM. 48. Após 47, a configuração em modo gráfico se inicia. 49. Em “Welcome”, clique (NEXT). 50. Aceitar o acordo de licenciamento. 51. Configurar data/hora manualmente e habilitar o NTP (Network Time Protocol) se for desejado. 52. Em “Display Setup”, clique (NEXT), deixando como está. 53. Adicionar um novo par usuário/senha. 54. Em “ADDITIONAL CDs”, clicar (NEXT). 55. Em “FINISH SETUP”, clicar (NEXT). 56. Fazer login. O processo está encerrado.

116

8 INSTALAÇÃO E CONFIGURAÇÃO DO GFARM VERSÃO 1.3.1 - VERSÃO TRADUZIDA E ADAPTADA DE GFARM (2006a)

Este guia descreve a instalação e configuração do sistema de arquivos Gfarm com pacotes binários RPM, separados pelos tipos de nós que o compõe. Como na versão 1.3.1 foi introduzido o suporte ao PostgreSQL, a instalação dos pacotes binários reclama sua presença, ainda que a opção escolhida para os metadados seja o LDAP. Dessa forma, adiciona-se aos pacotes instalados o PostgreSQL, em conformidade com as distribuições Linux escolhidas para o cenário.

8.1 Instalação e configuração do servidor de metadados (metaserver)

8.1.1 Instalação do certificado de host (nó) para uso em grandes áreas

Esta seção é opcional para os ambientes de uso interno em redes locais confiáveis incluindo uma VPN (Virtual Private Network) ou dentro de um cluster. Para grandes áreas, o Gfarm usa GSI (GSI, 2006) para autenticação e autorização entre clientes e o servidor de metadados. É necessário obter um certificado de host assinado por uma autoridade certificadora (CA - Certificate Authority). Pode ser usada uma CA própria ou uma das disponíveis para o ambiente de testes ApGrid, listadas em . O certificado de host assinado e a chave secreta correspondente precisam ser armazenados em “/etc/grid-security/host {cert,key}.pem”. Já o certificado da CA de confiança precisa ser armazenado em “/etc/grid-security/certificates”. Para autorização, é necessário configurar o arquivo “/etc/grid-security/grid-mapfile” que inclui uma lista de mapeamentos entre o nome do sujeito do certificado de usuário e um nome de usuário UNIX.

8.1.2 Instalação pelos pacotes binários RPM do Gfarm

É necessário instalar os pacotes server e libs. O pacote client é opcional. Os comandos são executados como segue: # rpm –i(U)20hv gfarm-gsi-libs-X.X.X-X.ARCH21.rpm # rpm –i(U)hv gfarm-gsi-server-X.X.X-X.ARCH.rpm (server)

8.1.3 Configuração do servidor de metadados do Gfarm

A configuração é feita executando-se o script “config-gfarm”. Se usada a opção “-t”, observa-se o resultado da configuração sem realmente executar as ações pertinentes (vide quadro 20).

20 O “U” é usado no lugar de “i” no caso de atualização de módulo já existente 21 X.X.X-X e ARCH são a versão do Gfarm e a arquitetura computacional, respectivamente 117

# config-gfarm -t prefix [--prefix]: metadata backend [-b]: postgresql (supported backend: postgresql ldap) metadata directory [-l]: /var/gfarm-pgsql metadata log directory [-L]: /var/gfarm-pgsql/pg_xlog postgresql admin user [-U]: postgres postgresql admin password [-W]: (gerado automaticamente) postgresql user [-u]: gfarm postgresql password [-w]: (gerado automaticamente) postgresql prefix [-P]: /usr/bin postgresql version [-V]: 8.1 metaserver hostname [-h]: metadb.example.com portmaster port [-p]: 10602 gfmd port [-m]: 601 gfsd port [-s]: 600 auth type [-a]: sharedsecret Quadro 20 – Configuração do Gfarm com PostgreSQL para servidor de metadados

Quando o LDAP é escolhido como banco de dados para o servidor de metadados mediante opção “-b”, observa-se o resultado do comando de teste preliminar – opção “-t” – no quadro 21. Se o pacote servidor openldap for versão 2.0 ou inferior, recomenda-se trocar pela versão 2.1, pois caso contrário os nomes de arquivos no Gfarm serão insensíveis a maiúsculas e minúsculas.

# config-gfarm -t -b ldap prefix [--prefix]: metadata backend [-b]: ldap (supported backend: postgresql ldap) metadata directory [-l]: /var/gfarm-ldap metadata log directory [-L]: /var/gfarm-ldap domain name [-d]: example.com ldap root user [-U]: cn=root,dc=example,dc=com ldap root password [-W]: (auto generated) ldap user [-u]: dc=example,dc=com ldap password [-w]: (gerado automaticamente) openldap prefix [-P]: /usr/bin openldap version [-V]: 2.2 metaserver hostname [-h]: metadb.example.com slapd port [-p]: 10602 gfmd port [-m]: 601 gfsd port [-s]: 600 auth type [-a]: sharedsecret slapd DB cache size [-c]: 536870912 bytes slapd DB type ($SLAPD_DB): bdb Quadro 21 - Configuração do Gfarm com LDAP para servidor de metadados

118

Em ambos os quadros, os itens em itálico devem ser substituídos pelos valores que correspondem ao cenário real. Os parâmetros padrão podem ser modificados pelas opções delimitadas por “[ ]”. Como exemplo, se for desejado alterar a porta de escuta do slapd devido à presença de outro servidor LDAP em operação, pode-se fazê-lo mediante a opção “-p”, como segue:

# config-gfarm –t –p 20602

O parâmetro “prefix” é usado para configurar vários sistemas de arquivo Gfarm ou configurá-lo em privilégio de usuário. Isso faz com que todos os arquivos de configuração sejam gerados sob o diretório especificado. Se for desejado executar o Gfarm em privilégio de usuário, a porta 1024 ou superiores devem ser usadas. Caso se opte pelo PostgreSQL, ele será invocado com o privilégio de usuário mostrado na linha “postgresql admin user” -“postgres” no quadro 20 – requerendo assim o uso da porta 1024 ou superiores. Quando os parâmetros escolhidos estiverem confirmados como adequados para o ambiente, o comando “config-gfarm” pode ser executado sem a opção “-t”. Assim, as seguintes quatro ações são executadas: Estabelecimento de um diretório que contém os metadados do sistema de arquivos; Criação de um arquivo de configuração do Gfarm “%%SYSCONFDIR%%/gfarm.conf”. %%SYSCONFDIR%% é o diretório de configuração, tipicamente “/etc”; Execução do slapd (servidor LDAP); Execução do gfmd.

Se o diretório de metadados já existe, o comando “gfarm-conf” falha. Nesse caso, pode-se renomear o diretório existente antes da execução do comando ou usar a opção “-f”, que forçará a recriação apagando os metadados e o arquivo de configuração anteriores. O arquivo criado “%%SYSCONFDIR%%/gfarm.conf” pressupõe segurança nos ambientes de cluster ou rede local. Para maiores informações, a página de manual em linux pode ser consultada mediante “man gfarm.conf”.

8.2 Instalação do servidor de cache de metadados do Gfarm

O servidor de cache de metadados do Gfarm funciona como proxy do servidor de metadados do Gfarm, mantendo os metadados em cache para evitar concentração de acesso e permitir acesso eficiente a eles em cenários de grande abrangência geográfica. Em grandes áreas, caso seja necessário, é possível estabelecer múltiplos servidores de cache. 119

O estabelecimento do servidor de cache de metadados é realizado mediante a instalação de pacotes binários RPM, como segue:

# rpm –i(U)hv gfarm-gsi-libs-X.X.X-X.ARCH.rpm # rpm –i(U)hv gfarm-gsi-agent-X.X.X-X.ARCH.rpm

Nota: O pacote “gfarm-gsi-libs” não precisa ser instalado caso o candidato a ser servidor de cache já exerça alguma função Gfarm, como client ou fsnode.

8.2.1 Configuração do servidor de cache de metadados do Gfarm (cacheserver)

O arquivo de configuração “%%SYSCONFIGDIR%%/gfarm.conf22” gerado na instalação do metaserver (vide 8.1.2) deve ser copiado para o servidor candidato a hospedar o cache, mantendo-se a mesma localização no sistema de arquivos. A cópia pode ser realizada mediante o comando “scp” como segue:

# scp –p metaserver.domínio:%%SYSCONFIGDIR%%/gfarm.conf /etc

A seguir deve-se executar o comando “config-agent” para configurar o servidor de cache de metadados. Assim como nos scripts anteriores, pode-se usar a opção “-t” para executar a configuração em caráter experimental, apenas mostrando como seriam os resultados (quadro 22).

# config-agent –t prefix [--prefix] hostname [-h]: cacheserver.domínio port [-p]: 603 Quadro 22 – Configuração do servidor de cache de metadados

Os parâmetros padrão podem ser modificados pelas opções entre “[ ]” adicionadas à linha do comando. Se os resultados estiverem corretos, o comando pode ser executado sem a opção “-t”, o que provoca as seguintes duas ações:

Atualização do arquivo de configuração Gfarm para refletir o acesso ao cache Execução do “gfarm_agent”

22 %%SYSCONFIGDIR%% é tipicamente “/etc” 120

8.3 Instalação e configuração do nó servidor de arquivos do Gfarm (fsnode); e nó client

8.3.1 Instalação do certificado de host (nó) para uso em grandes áreas

Esta seção é opcional para os ambientes de uso interno em redes locais confiáveis incluindo uma VPN (Virtual Private Network) ou dentro de um cluster. (vide 8.1.1)

8.3.2 Instalação pelos pacotes binários RPM do Gfarm

É necessário instalar os pacotes libs, client e fsnode. O pacote doc é opcional. Os comandos são executados como segue: rpm –i(U)hv gfarm-gsi-libs-X.X.X-X.ARCH.rpm rpm –i(U)hv gfarm-gsi-client-X.X.X-X.ARCH.rpm (client) rpm –i(U)hv gfarm-gsi-fsnode-X.X.X-X.ARCH.rpm (fsnode) rpm –i(U)hv gfarm-gsi-doc-X.X.X-X.ARCH.rpm (documentação opcional)

Se for necessário habilitar o acesso ao sistema de arquivos por aplicações não preparadas - já que o fsnode também opera como client - deve-se instalar o pacote “glibc-not- hidden” de acordo com a versão do Linux em uso, como segue:

# rpm –i(U)hv glibc-not-hidden-X.X.X-X.ARCH.rpm

8.3.3 Configuração do nó servidor de arquivos

O arquivo de configuração “%%SYSCONFIGDIR%%/gfarm.conf23” gerado na instalação do metaserver (vide 8.1.2) ou na instalação do servidor de cache (vide 8.2.1)24, deve ser copiado para o servidor candidato a fsnode, mantendo-se a mesma localização no sistema de arquivos. A cópia pode ser realizada mediante o comando “scp” como segue:

# scp –p metaserver.domínio:%%SYSCONFIGDIR%%/gfarm.conf /etc ou # scp –p cacheserver.domínio:%%SYSCONFIGDIR%%/gfarm.conf /etc

A configuração é feita executando-se o script “config-gfsd”. Se usada a opção “-t”, observa-se o resultado da configuração sem realmente executar as ações pertinentes (vide quadro 23).

23 %%SYSCONFIGDIR%% é tipicamente “/etc” 24 Caso se deseje que as aplicações operando como “clientes” nos fsnodes façam uso de um cacheserver 121

# config-gfsd -t prefix [--prefix]: hostname [-h]: fsnode.domínio listen address [-l ]: (todos os endereços IP locais) architecture [-a]: i386-fedoraX-linux ncpu [-n]: 2 spool directory : /var/gfarm-spool rc script name : /etc/init.d/gfsd Quadro 23 - Configuração do nó servidor de arquivos

Os parâmetros padrão podem ser modificados pelas opções entre “[ ]” adicionadas à linha do comando, exceto o “spool directory”, modificável declarando-o como último parâmetro do comando. Ressalta-se que o diretório de spool deve ser uma área não compartilhada entre os nós servidores de arquivo. Quando o parâmetro “prefix” é especificado, pode-se modificar o local do arquivo de configuração Gfarm para “/etc/gfarm.conf”. Caso seja modificado, cada usuário precisa criar o arquivo “~/.gfarmrc” no seu diretório home, ou estabelecer a variável de ambiente $GFARM_CONFIG_FILE para o nome de caminho. Se os resultados estiverem corretos, o comando pode ser executado sem a opção “-t”, o que provoca as seguintes três ações:

Estabelecimento de um diretório de spool no sistema de arquivos local do nó servidor de arquivos (/var/gfarm-spool) Registro do nó no metaserver mediante cadastro no LDAP Atualização do arquivo de configuração Gfarm para o nó servidor de arquivos Execução do gfsd

Se o diretório de spool já existe, o comando “config-gfsd” falha. Nesse caso, pode-se renomear/mover o diretório existente antes da execução do comando ou usar a opção “-f”, que forçará a recriação apagando o diretório de spool e criando um novo.

8.4 Configuração de um nó cliente Gfarm (somente cliente)

8.4.1 Instalação pelos pacotes binários RPM do Gfarm

É necessário instalar os pacotes libs e client. O pacote doc é opcional. Os comandos são executados como segue: # rpm –i(U)25hv gfarm-gsi-libs-X.X.X-X.ARCH26.rpm # rpm –i(U)hv gfarm-gsi-client-X.X.X-X.ARCH.rpm (client)

25 O “U” é usado no lugar de “i” no caso de atualização de módulo já existente 26 X.X.X-X e ARCH são a versão do Gfarm e a arquitetura computacional, respectivamente 122

Assim como nos fsnodes, para aplicações não preparadas terem acesso ao Gfarm, deve-se instalar o pacote “glibc-not-hidden” de acordo com a versão do Linux em uso, como segue:

# rpm –i(U)hv glibc-not-hidden-X.X.X-X.ARCH.rpm

8.5 Configuração do nó cliente

O arquivo de configuração “%%SYSCONFIGDIR%%/gfarm.conf” gerado na instalação do metaserver (vide 8.1.2) ou na instalação do servidor de cache (vide 8.2.1), deve ser copiado para o servidor candidato a fsnode, mantendo-se a mesma localização no sistema de arquivos. A cópia pode ser realizada mediante o comando “scp” como segue:

# scp –p metaserver.domínio:%%SYSCONFIGDIR%%/gfarm.conf /etc ou # scp –p cacheserver.domínio:%%SYSCONFIGDIR%%/gfarm.conf /etc

Essa configuração pode ser substituída pela cópia do arquivo para “~/.gfarmrc”.

8.5.1 Configuração para cada usuário

8.5.1.1 Instalação de certificado de usuário (somente se usado GSI)

É necessário obter um certificado assinado por uma CA apropriada, conforme descrito em 8.1.1. O certificado de usuário assinado e a chave secreta correspondente precisam ser armazenados em “~/globus/user{cert,key}.pem”. Já o certificado da CA de confiança precisa ser armazenado em “/etc/grid-security/certificates”.

8.5.1.2 Criação de diretório home no sistema de arquivos Gfarm

Como primeira ação, é preciso criar um diretório home do usuário no sistema de arquivos Gfarm, com o comando a seguir:

% gfmkdir gfarm:~

O diretório de usuário deve ser criado uma única vez por qualquer um dos clientes, sendo compartilhado por todos eles. Se a execução desse comando falhar, é provável que exista uma das 2 anomalias que seguem: slapd não está em execução no metaserver (ou metaserver inoperante) 123

Arquivo de configuração “gfarm.conf” ou “~/.gfarmrc” não está correto no cliente. Pelo menos um deles deve estar presente e configurado adequadamente.

8.5.1.3 A variável “LD_PRELOAD” (acesso ao Gfarm por aplicações não preparadas)

Executáveis existentes, vinculados dinamicamente em cada nó cliente podem acessar o sistema de arquivos Gfarm especificando a variável “LD_PRELOAD”. Essa variável aponta as bibliotecas que compõem a biblioteca syscall-hook. As instruções que seguem são referentes ao Linux. No caso de outro sistema operacional ou detalhes adicionais, o arquivo “README.hook.en” que acompanha o Gfarm pode ser consultado. Quando o shell de login é “bash”, adiciona-se ao arquivo “.bashrc” as duas diretivas que seguem:

a) LD_PRELOAD='/usr/lib/libgfs_hook.so.0 /usr/lib/gfarm/librt-not-hidden.so \ /usr/lib/gfarm/libpthread-not-hidden.so /usr/lib/gfarm/libc-not-hidden.so'

b) export LD_PRELOAD

Por outro lado, se o shell é “csh” ou “tcsh”, a diretiva que segue deve ser adicionada ao arquivo “.cshrc”:

a) setenv LD_PRELOAD '/usr/lib/libgfs_hook.so.0 /usr/lib/gfarm/librt-not-hidden.so \ /usr/lib/gfarm/libpthread-not-hidden.so /usr/lib/gfarm/libc-not-hidden.so'

8.6 Teste do sistema de arquivos Gfarm

O funcionamento básico do Gfarm pode ser atestado com comandos simples, por qualquer cliente, desde que possa ser acessado (ou compartilhado) a partir de cada nó cliente.

8.6.1 Criação de um certificado de proxy de usuário (somente no caso de GSI)

O programa “grid-proxy-init” – incluído no Globus toolkit (GLOBUS, 2006) – deve ser executado para criar um certificado de proxy de usuário, como segue:

# grid-proxy-init

124

8.6.2 Comandos básicos – (detalhes nas páginas “man” do Linux)

gfls – lista o conteúdo de diretórios

Quadro 24 - Exemplo de resultado do comando “gfls”

gfhost – Informações sobre os nós de armazenamento do sistema de arquivos (fsnodes)

“gfhost -l” – lista informações de estado dos nós de armazenamento

Quadro 25– Exemplo de resultado do comando “gfhost -l”

“gfhost –M” – lista informações gerais sobre os nós de armazenamento registrados no metaserver

Quadro 26 - Exemplo de resultado do comando “gfhost –M”

No quadro 25, a primeira coluna indica o estado funcional do nó. Apresentando valores numéricos, indica a carga de trabalho. Se estiver mostrando “x.xx/x.xx/x.xx”, significa que o nó provavelmente está inoperante ou inacessível. Por outro lado, uma indicação “-.--/-.--/-.--” mostra que o “gfsd” não está sendo executado corretamente, impedindo o acesso ao sistema de arquivos. 125

A segunda coluna indica o estado da autenticação no acesso ao nó. As letras “s”, “g” e “G” indicam autenticação com sucesso. Por outro lado, um “x”mostra falha de autenticação. Se o comando for executado com parâmetro “-v”, o processo de autenticação é revelado, permitindo identificar suas possíveis falhas.

gfps – Informação sobre processo em execução “gfps” mostra informações sobre processos em execução, mediante acesso ao “gfmd” no metaserver. Se o “gfmd” estiver em execução correta, acontece a saída imediata do comando, sem qualquer mensagem indicativa.

8.6.3 Acesso a partir de aplicações existentes (não preparadas) em Linux27

No caso de shell “bash”, estabelece-se a variável “LD_PRELOAD” como indicado em 8.5.1, declarando-a e exportando-a com o arquivo “.bashrc”. Esse arquivo é executado automaticamente ao fazer logon.

Quadro 27 – Conteúdo da variável “LD_PRELOAD”

Confirmada a declaração da variável, o sistema de arquivos pode ser referenciado como se estivesse montado em “/gfarm” (quadro 28).

Quadro 28– Exemplo de acesso ao Gfarm após declaração de “LD_PRELOAD”

Arquivos no Gfarm podem ser referenciados mediante uma URL Gfarm iniciada por “gfarm:” ou um nome de caminho sob “/gfarm”. Os três relacionamentos entre as URLs Gfarm e os nomes de caminho seguem: 1. O diretório root: “gfarm:/” = “/gfarm”

27 Informações em detalhe, ou para usar com outros sistemas operacionais, vide “REAME.hook.en” 126

2. O diretório home: “gfarm:~ = /gfarm/~ 3. O diretório corrente: “gfarm:” = “/gfarm/.”

Se for desejado acessar o sistema de arquivos Gfarm diretamente via shell interativo, torna-se necessário executar o shell novamente, após ter sido declarada a variável “LD_PRELOAD” (vide 8.6.3). A partir dessa ação, comandos para o Gfarm podem ser executados diretamente, já que virtualmente está exposto em “/gfarm”.

Quadro 29 – Uso do Gfarm via shell interativo

8.6.4 Funções avançadas

As funções destacadas nesse tópico são a replicação de arquivos ou fragmentos de arquivos, e o processamento paralelo e distribuído.

8.6.4.1 Criação de réplicas dos arquivos

Cada arquivo do Gfarm pode ter várias cópias, armazenadas em dois nós ou mais nós (fsnodes). Caso o arquivo seja fragmentado visando I/O balanceado, cópias dos fragmentos também podem ser armazenadas em dois ou mais nós. Com cópias distribuídas dos arquivos ou fragmentos, o acesso é garantido mesmo com a indisponibilidade de algum nó, além de evitar concentração de acesso, pois as cópias podem ser acessadas em nós diferentes. Em replicação usa-se o comando “gfrep”, e em gerenciamento das réplicas usa-se “gfwhere” ou o front-end gráfico de gerenciamento “gfront”28.

gfwhere – mostra a localização dos arquivos ou fragmentos, e seu catálogo de réplicas no Gfarm

28 “gfront” depende do pacote JRE 1.4.2 ou superior, por ser aplicação JAVA. 127

Quadro 30 – Exemplo de uso de “gfwhere”

gfrep – cria cópias de arquivos ou fragmentos

Quadro 31 – Exemplo de uso de “gfrep” para 2 cópias (gfrep –N 2)

No quadro 31, se o comando tiver como parâmetro um diretório sem mencionar qualquer arquivo, todos os arquivos sob aquele diretório terão “N” cópias. Por exemplo, o comando “gfrep –N 2 gfarm:~” criará duas cópias de todos os arquivos sob o diretório home do usuário do Gfarm.

8.6.4.2 Processamento paralelo e distribuído

Como o Gfarm pode ser compartilhado entre todos os nós clientes, múltiplos processos em execução em diferentes nós podem acessar o mesmo sistema de arquivos. Execução distribuída com paralelismo é uma das formas de processamento distribuído e paralelo. Além disso, um alto desempenho adicional de acesso a arquivos pode ser atingido mediante a capacidade de cada nó (fsnode) do Gfarm ser também cliente do sistema de arquivos. Com essa funcionalidade, pode-se mover os programas para o local aonde os dados se encontram, executando o processamento nó que os contém os dados (file-affinity). O comando “gfrun” é um exemplo de execução de processo remoto que emprega o algoritmo file-affinity de escalonamento. Uma aplicação existente como “grep” – que procura ocorrências de conteúdo – pode ser executada com “gfrun” como segue:

$ gfrun grep conteúdo_procurado gfarm:arquivo_alvo

O gfrun provocará a seleção do nó menos ocupado entre aqueles que contêm réplicas do arquivo_alvo, para executar a procura diretamente nele. Pode-se ganhar desempenho executando o “grep” em paralelo e distribuído. Nesse caso, o arquivo_alvo tem que ser fragmentado e distribuído para armazenamento em múltiplos nós. 128

No quadro 32 pode-se verificar uma combinação de comandos que fragmentam o arquivo “GridFS_v3.83.doc” em duas partes, armazenando-o no Gfarm como “gridfs.doc”.

Quadro 32 – Exemplo de fragmentação e armazenamento com “gfimport_text”

Após a fragmentação e armazenamento, pode-se acessar o arquivo normalmente - ainda que fragmentado - conforme resultado do comando “diff” na penúltima linha do quadro 32. Dessa forma, a procura de conteúdo pode ser executada em paralelo, com o “grep” processado em cada fragmento no nó que o contém, como segue:

$ gfrun grep Gfarm gfarm:/lab/gridfs.doc

O resultado da busca é mostrado diretamente na saída padrão, sendo opcionalmente direcionado para um arquivo mediante opção “-o”, como segue:

$ gfrun –o gfarm:/test/arquivo_de_saída grep Gfarm gfarm:/lab/gridfs.doc

Detalhes de todos os comandos deste guia podem ser obtidos nas páginas “man” do Linux. 129

9 CRIAÇÃO DE PACOTES BINÁRIOS – TRADUZIDO E ADAPTADO DE TATEBE (2006)

Caso os pacotes RPM necessários não existam para a distribuição Linux utilizada; ou existam, mas apresentam falhas de dependência na instalação, é necessário criá-los manualmente. Esse guia mostra os passos necessários a essa criação, que depende da instalação prévia de alguns pacotes.

9.1 Instalação prévia de pacotes requeridos para a criação dos RPMs

A criação dos RPMs do Gfarm a partir dos “fontes” depende da presença dos seguintes pacotes:

“rpm-build” – provê a ferramenta “rpmbuild” para construir os RPMs; Bibliotecas OpenSSL, OpenLDAP e PostgreSQL; Compilador “gcc”; Bibliotecas “glibc”.

Preferindo-se o uso de GSI, a biblioteca Globus GSSAPI também é necessária. Se ela não existir para a distribuição Linux utilizada, também deverá ser criada, conforme segue:

# wget http://datafarm.apgrid.org/software/globus/globus-4.0.2-1.src.rpm # rpm -ivh globus-4.0.2-1.src.rpm # rpmbuild -bb /usr/src/redhat/SPECS/globus.spec # cd /usr/src/redhat/RPMS/ARCH # rpm -Uvh globus-gpt-4.0.2-1.ARCH.rpm globus-gssapi-gsi-gcc32-4.0.2-1.ARCH.rpm

Ressalta-se que o pacote “fonte” pressupõe instalar-se em “/usr/gt4”, usando “gcc32”. Se esses padrões precisam ser alterados, as linhas 5 e 6 do arquivo “/usr/src/redhat/SPECS/globus.spec” devem ser modificadas para refletir os padrões desejados, antes de executar “rpmbuild”.

Considerando o Fedora Core, novos pacotes podem ser instalados de duas formas:

1. Obtidos os pacotes desejados, usa-se o utilitário “rpm”. No caso das bibliotecas OpenSSL, OpenLDAP e PostgreSQL, a instalação poderia ser feita como segue: # rpm –i(U)hv openssl-devel-X.X.X-X.ARCH.rpm # rpm –i(U)hv openldap-devel-X.X.X-X.ARCH.rpm # rpm –i(U)hv postgresql-devel-X.X.X-X.ARCH.rpm 130

2. Os pacotes podem ser obtidos e instalados automaticamente pela ferramenta “yum”.

9.2 Pacotes “gfarm-gsi”

Instalada a biblioteca Globus GSSAPI (vide 9.1), é possível criar os pacotes binários “gfarm-gsi”, sendo necessário definir as variáveis GLOBUS_PREFIX e GLOBUS_FLAVOR apropriadamente, antes de executar “rpmbuild”, como segue:

# rpm -ivh gfarm-X.X.X-X.src.rpm # GLOBUS_PREFIX=/usr/gt4 GLOBUS_FLAVOR=gcc32 rpmbuild –bb \ /usr/src/redhat/SPECS/gfarm.spec

Os pacotes resultantes serão armazenados em “/usr/src/redhat/RPM/ARCH/”.

9.3 Pacotes “gfarm”

Se optado por não usar GSI, a biblioteca Globus GSSAPI não precisa estar instalada. Dessa forma, serão criados pacotes binários “gfarm” que não permitirão usar a autenticação GSI no sistema de arquivos, como segue:

# rpm -ivh gfarm-X.X.X-X.src.rpm # rpmbuild -bb /usr/src/redhat/SPECS/gfarm.spec

131

10 ACESSO AO GFARM VIA SAMBA VINCULANDO A BIBLIOTECA SYSCALL- HOOK – TRADUZIDO E ADAPTADO DE GFARM (2006)

Esse tópico mostra os pré-requisitos gerais e as modificações necessárias para que o Samba funcione como front-end do Gfarm para os ambientes de rede Windows. O script de inicialização e o arquivo de configuração do Samba são os utilizados no experimento deste trabalho.

10.1 Pré-requisitos e recomendações para o servidor Samba

O Samba deve ser no mínimo versão 3; Deve ser um cliente Gfarm; Como cliente Gfarm, deve ter a vinculação da biblioteca syscall-hook; Recomendado que não seja um fsnode, pois, devido ao algoritmo de file-affinity, todos os novos arquivos submetidos ao controle do Samba serão gravados no sistema de arquivos local; Recomendado que todos os clientes – incluindo o próprio servidor Samba - usem a segurança baseada em chave compartilhada, fazendo-se necessário que compartilhem um mesmo diretório home. O compartilhamento pode ser estabelecido utilizando-se um servidor NFS para prover o diretório home de todos os usuários; A segurança baseada em GSI pode ser usada, bastando que o cliente execute “grid-proxy- init” antecipadamente ou sempre que a chave GSI expira. Essa forma de autenticação é indicada para ambientes nos quais os clientes não compartilham de um mesmo diretório home; Sem o compartilhamento, o cliente precisaria gerar a chave com “gfkey –c” no servidor Samba e copiá-la para seu diretório home em todos os nós do Gfarm. Essa ação requer repetição sempre que a chave compartilhada expira, o que ocorre após 24 hs de sua criação.

10.2 Script de inicialização do Samba – “/etc/init.d/smb”

# Após executado tipicamente na inicialização do servidor, possibilita que o ponto de montagem virtual “/gfarm” seja compartilhado para os clientes Windows. # #!/bin/sh # # chkconfig: - 91 35 # description: Starts and stops the Samba smbd and nmbd daemons \ # used to provide SMB network services. # # pidfile: /var/run/samba/smbd.pid # pidfile: /var/run/samba/nmbd.pid # config: /etc/samba/smb.conf

132

# Source function library. if [ -f /etc/init.d/functions ] ; then . /etc/init.d/functions elif [ -f /etc/rc.d/init.d/functions ] ; then . /etc/rc.d/init.d/functions else exit 0 fi

# Avoid using root's TMPDIR unset TMPDIR

# Source networking configuration. . /etc/sysconfig/network if [ -f /etc/sysconfig/samba ]; then . /etc/sysconfig/samba fi

# Check that networking is up. [ ${NETWORKING} = "no" ] && exit 0

# Check that smb.conf exists. [ -f /etc/samba/smb.conf ] || exit 0

RETVAL=0

start() { KIND="SMB" echo -n $"Starting $KIND services: " # # Trechos inseridos para dar suporte ao Gfarm # # Aumento da quantidade de descritores de arquivos # m=`ulimit -n` n=$(($(gfhost -M | wc -l)+50)) if [ -n "$m" -a X"$m" != X"unlimited" -a "$m" -lt $n ]; then ulimit -n $n fi # # # Declarações das variáveis de ambiente # gfarm_prefix=/usr globus_location=/usr/gt4 globus_flavor=gcc32 LD_LIBRARY_PATH="$globus_location/lib" 133

# # Estabelecimento das bibliotecas para vinculação dinâmica # LD_PRELOAD='/usr/gt4/lib/libglobus_gssapi_gsi_gcc32.so.0 \ /usr/gt4/lib/libltdl_gcc32.so.3 \ /usr/gt4/lib/libcrypto_gcc32.so.0 /usr/gt4/lib/libglobus_common_gcc32.so.0 \ /usr/gt4/lib/libglobus_oldgaa_gcc32.so.0 /usr/gt4/lib/libglobus_gsi_sysconfig_gcc32.so.0 \ /usr/gt4/lib/libglobus_gsi_cert_utils_gcc32.so.0 /usr/gt4/lib/libglobus_openssl_gcc32.so.0 \ /usr/gt4/lib/libglobus_openssl_error_gcc32.so.0 \ /usr/gt4/lib/libglobus_gsi_credential_gcc32.so.0 \ /usr/gt4/lib/libglobus_gsi_callback_gcc32.so.0 \ /usr/gt4/lib/libglobus_gsi_proxy_core_gcc32.so.0 \ /usr/gt4/lib/libglobus_proxy_ssl_gcc32.so.0 /usr/gt4/lib/libssl_gcc32.so.0 \ /usr/lib/libgfs_hook.so.0 /usr/lib/gfarm/librt-not-hidden.so \ /usr/lib/gfarm/libpthread-not-hidden.so \ /usr/lib/gfarm/libc-not-hidden.so' daemon smbd $SMBDOPTIONS # RETVAL=$? echo KIND="NMB" echo -n $"Starting $KIND services: " daemon nmbd $NMBDOPTIONS RETVAL2=$? echo [ $RETVAL -eq 0 -a $RETVAL2 -eq 0 ] && touch /var/lock/subsys/smb || \ RETVAL=1 return $RETVAL } stop() { KIND="SMB" echo -n $"Shutting down $KIND services: " killproc smbd RETVAL=$? echo KIND="NMB" echo -n $"Shutting down $KIND services: " killproc nmbd RETVAL2=$? [ $RETVAL -eq 0 -a $RETVAL2 -eq 0 ] && rm -f /var/lock/subsys/smb echo "" return $RETVAL } restart() { stop start } reload() { 134

echo -n $"Reloading smb.conf file: " killproc smbd -HUP RETVAL=$? echo return $RETVAL } rhstatus() { status smbd status nmbd }

# Allow status as non-root. if [ "$1" = status ]; then rhstatus exit $? fi

# Check that we can write to it... so non-root users stop here [ -w /etc/samba/smb.conf ] || exit 0 case "$1" in start) start ;; stop) stop ;; restart) restart ;; reload) reload ;; status) rhstatus ;; condrestart) [ -f /var/lock/subsys/smb ] && restart || : ;; *) echo $"Usage: $0 {start|stop|restart|reload|status|condrestart}" exit 1 esac exit $?

135

11 ACESSO A ARQUIVOS POR APLICAÇÕES EXISTENTES (NÃO MODIFICADAS)

Este capítulo descreve o LEIAME para a biblioteca syscall-hook – tradução para o português do conteúdo de Datafarm (2006). A biblioteca syscall-hook do Gfarm – “libgfs_hook.so” ou “gfs_hook.o” – permite que programas acessem arquivos no sistema de arquivos Gfarm como se estivessem sob o ponto de montagem “/gfarm”. Essa biblioteca, uma vez instalada e vinculada ao shell do usuário, captura toda chamada de sistema destinada ao acesso a arquivos. Sempre que um arquivo invocado sob o ponto de montagem virtual “/gfarm” ou mediante o uso de uma URL Gfarm iniciada com “gfarm:” ou “gfarm@”, as APIs de I/O do Gfarm são chamadas.

11.1 Configuração

11.1.1 Linux, FreeBSD, NetBSD, Solaris, Mac OS X, HP-UX e Tru64

Nestes sistemas operacionais se utiliza um mecanismo de pré-carga de bibliotecas compartilhadas antes da execução das aplicações. Assim, programas existentes podem acessar o sistema de arquivos Gfarm sem qualquer modificação.

11.1.1.1 Linux

No caso do Linux, é necessário instalar o pacote “glibc-not-hidden” para que as chamadas de sistema necessárias sejam capturadas apropriadamente. O pacote pode ser obtido de acordo com a distribuição Linux em:

Se não for possível instalar o pacote, é preciso repetir a fase de linking da biblioteca syscall-hook estaticamente, conforme instruções em 11.1.2; ou usar a ferramenta GfarmFS- FUSE, disponível em:

É necessário declarar “libgfs_hook.so.0” e “glib{rt,pthread,c}-not-hidden.so” na variável de ambiente LD_PRELOAD.

No caso dos shells “sh” ou “bash”, declara-se como segue:

$ LD_PRELOAD=”%%LIBDIR%%/libgfs_hook.so.0 /usr/lib/gfarm/librt-not- \ hidden.so\ /usr/lib/gfarm/libpthread-not-hidden.so /usr/lib/gfarm/libc-not- hidden.so”

$ export LD_PRELOAD 136

No caso dos shells “csh” ou “tcsh”, declara-se como segue:

% setenv LD_PRELOAD “%%LIBDIR%%/libgfs_hook.so.0 /usr/lib/gfarm/librt-not-\ hidden.so /usr/lib/gfarm/libpthread-not-hidden.so /usr/lib/gfarm/libc-not-hidden.so”

Após a declaração da variável de ambiente LD_PRELOAD, toda aplicação pode acessar o sistema de arquivos Gfarm como se estivesse montado em “/gfarm”. A verificação funcional pode ser realizada mediante nova invocação do shell, como segue:

% bash

Caso seja usado o Gfarm com GSI, alguns programas vinculados com “libgssapi” baseada no Kerberos, podem causar falha de segmentação ou impedir o acesso ao sistema de arquivos Gfarm. Dessa forma, faz-se necessário adicionar “libgssapi” baseada em GSI e “libssl” na declaração da variável de ambiente LD_PRELOAD. Por exemplo, “scp” e “wget”, em algumas situações, se encaixam nessa classe de programas. Se o nome da modalidade Globus que é vinculado com o Gfarm é %%GLOBUS_FLAVOR%%, faz-se necessário especificar:

$GLOBUS_LOCATION/lib/libglobus_gssapi_gsi_ \ %%GLOBUS_FLAVOR%%.so.0

$GLOBUS_LOCATION/lib/libssl_%%GLOBUS_FLAVOR%%.so.0 como segue:

$ LD_PRELOAD="$GLOBUS_LOCATION/lib/libglobus_gssapi_gsi_\ %%GLOBUS_FLAVOR%%.so.0 \

$GLOBUS_LOCATION/lib/libssl_%%GLOBUS_FLAVOR%%.so.0 \ %%LIBDIR%%/libgfs_hook.so.0 /usr/lib/gfarm/librt-not-hidden.so \ /usr/lib/gfarm/libpthread-not-hidden.so /usr/lib/gfarm/libc-not-hidden.so

$ export LD_PRELOAD

11.1.1.2 FreeBSD

Basta especificar “libgfs_hook.so.0” na declaração da variável de ambiente LD_PRELOAD. 137

No caso dos shells “sh” ou “bash”,

$ LD_PRELOAD=%%LIBDIR%%/libgfs_hook.so.0 $ export LD_PRELOAD

No caso de “csh” or “tcsh”,

% setenv LD_PRELOAD %%LIBDIR%%/libgfs_hook.so.0

Essa configuração de LD_PRELOAD não funciona com os comandos em “/bin” no FreeBSD 4.X ou anteriores, porque tais comandos são vinculados estaticamente. Se esse é o caso, a opção é criar executáveis vinculados dinamicamente para estes comandos, num diretório como “/usr/local/dynbin”, e adicioná-lo à $PATH, mediante os seguintes procedimentos:

(1) Extrair “sbin.??” e “subin.??” na distribuição fonte:

# cd /usr/src # cat ${FREEBSD_RELEASE_DIRECTORY}/src/sbin.?? | tar zpxf - # cat ${FREEBSD_RELEASE_DIRECTORY}/src/subin.?? | tar zpxf -

(2) Alterar a configuração da fase de linking de estática para dinâmica:

# cd bin # vi Makefile.inc

comentar a linha abaixo:

NOSHARED?=YES

(3) Construir e instalar num diretório apropriado (“/usr/local/dynbin” neste exemplo):

# sh -c ‘for d in cat chmod cp ls mkdir mv pax pwd rcp rm rmdir sh test; do (cd $d; make );\ done’ # sh -c ‘for d in cat chmod cp ls mkdir mv pax pwd rcp rm rmdir sh test; do (cd $d; make \ NOMAN=noman BINDIR=/usr/local/dynbin install ); done’

Opcionalmente podem ser obtidos os binários de “/bin” vinculados dinamicamente para o FreeBSD-4.11/i386 em:

11.1.1.3 NetBSD

Especificar a “libgfs_hook.so.0” na variável de ambiente LD_PRELOAD.

138

No caso dos shells “sh” ou “bash”,

$ LD_PRELOAD=%%LIBDIR%%/libgfs_hook.so.0 $ export LD_PRELOAD

No caso de “csh” or “tcsh”,

% setenv LD_PRELOAD %%LIBDIR%%/libgfs_hook.so.0

Essa configuração de LD_PRELOAD não funciona com os comandos em “/bin” no NetBSD 1.X ou anteriores, porque tais comandos são vinculados estaticamente. Se esse é o caso, a opção é criar executáveis vinculados dinamicamente para estes comandos, num diretório como “/usr/local/dynbin”, e adicioná-lo à $PATH, mediante os seguintes procedimentos:

(1) Extrair “src.tgz” na distribuição fonte

# cd / # tar zpxf ${NETBSD_RELEASE_DIRECTORY}/source/sets/src.tgz

(2) Modificar a configuração de vinculação estática para dinâmica

# cd usr/src/bin # vi Makefile.inc

comentando a linha abaixo:

LDSTATIC?= -static

(3) Construir e instalar num diretório apropriado (“/usr/local/dynbin”neste exemplo)

# sh -c ‘for d in cat chmod cp ls mkdir mv pax pwd rcp rm rmdir sh test; do (cd $d; make);\ done’ # sh -c ‘for d in cat chmod cp ls mkdir mv pax pwd rcp rm rmdir sh test; do\ (cd $d; make MKMAN=no BINDIR=/usr/local/dynbin install ); done’

Opcionalmente podem ser obtidos os binários de “/bin” vinculados dinamicamente para o NetBSD-1.6.2/i386 em .

11.1.1.4 Solaris

Especificar “libgfs_hook.so.0” na variável de ambiente LD_PRELOAD_32.

139

No caso dos shells “sh” ou “bash”,

$ LD_PRELOAD_32=%%LIBDIR%%/libgfs_hook.so.0:/usr/lib/libresolv.so $ export LD_PRELOAD_32

No caso de “csh” or “tcsh”,

% setenv LD_PRELOAD_32 %LIBDIR%%/libgfs_hook.so.0: \ /usr/lib/libresolv.so

Nota: A presença de “libresolv.so” é necessária devido a biblioteca “libgfarm.so” - incluída no pacote binário do Gfarm para Solaris – a qual contém a biblioteca OpenLDAP vinculada estaticamente, que faz referências a símbolos em “libresolv.so”. No caso da construção a partir da distribuição fonte, é possível que a biblioteca “libresolv.so” não seja requerida.

11.1.1.5 MacOS X

Especificar “libgfs_hook.dynlib” nas variáveis de ambiente DYLD_INSERT_LIBRARIES e DYLD_FORCE_FLAT_NAMESPACE. Se for necessário especificar múltiplas bibliotecas em DYLD_INSERT_LIBRARIES, deverá haver uma separação com “:” (dois pontos) entre elas. Qualquer valor pode ser especificado para DYLD_FORCE_FLAT_NAMESPACE, pois o efeito se dá apenas pela sua existência. No caso dos shells “sh” ou “bash”,

$ DYLD_INSERT_LIBRARIES=%%LIBDIR%%/libgfs_hook.dylib $ DYLD_FORCE_FLAT_NAMESPACE= $ export DYLD_INSERT_LIBRARIES DYLD_FORCE_FLAT_NAMESPACE

No caso de “csh” or “tcsh”,

% setenv DYLD_INSERT_LIBRARIES %%LIBDIR%%/libgfs_hook.dylib % setenv DYLD_FORCE_FLAT_NAMESPACE ""

O MacOS X é pouco testado.

11.1.1.6 HP-UX

Especificar “libgfs_hook.sl” na variável de ambiente LD_PRELOAD.

140

No caso dos shells “sh” ou “bash”,

$ LD_PRELOAD=%%LIBDIR%%/libgfs_hook.sl $ export LD_PRELOAD

No caso de “csh” or “tcsh”,

% setenv LD_PRELOAD %%LIBDIR%%/libgfs_hook.sl

O HP-UX é pouco testado. Sabe-se basicamente que há uma restrição tal que o acesso a diretório via “readdir(3)” não funciona.

11.1.1.7 Tru64

Especificar “libgfs_hook.so.0” na variável de ambiente RLD_LIST. Se for necessário especificar múltiplas bibliotecas em RLD_LIST, deverá haver uma separação com “:” (dois pontos) entre elas. No final da declaração da variável deve também constar “:DEFAULT”.

No caso dos shells “sh” ou “bash”,

$ _RLD_LIST=%%LIBDIR%%/libgfs_hook.so.0:DEFAULT $ export _RLD_LIST

No caso de “csh” or “tcsh”,

% setenv _RLD_LIST %%LIBDIR%%/libgfs_hook.so.0:DEFAULT

Sabe-se que o comando “gfhost” e as funções de escalonamento não funcionam corretamente no Tru64. Há também uma restrição, tal que, o acesso a diretório via “readdir(3)” não funciona.

11.1.1.8 Configurações independentes de sistema operacional

É útil efetuar as configurações descritas acima no arquivo “rc” do shell, como o “.bashrc” e o “.cshrc”. Recomenda-se o uso do “bash” por se melhor testado. Se for desejado acessar o sistema de arquivos Gfarm no shell interativo, basta executar o shell novamente, como segue:

% exec bash -l

A partir da execução do comando, torna-se possível mudar o diretório corrente para “/gfarm”, permitindo o uso da complementação de nome de arquivo no shell.

$ cd /gfarm 141

Para aplicações MPI, é necessário gerar “libgfs_hook.so” para a biblioteca MPI no ambiente em uso, ou seguir a seção 2.

Existem algumas limitações da biblioteca syscall-hook. Vide a seção “Limitações”, a seguir.

11.1.2 Sistema operacional sem o mecanismo de pré-carga de bibliotecas.

No caso do sistema operacional não suportar o mecanismo de pré-carga, faz-se necessário repetir a fase de linking (vinculação) com a biblioteca syscall-hook "gfs_hook.o”, para que seja possível acessar o sistema de arquivos Gfarm. Ressalta-se que é necessário vincular estaticamente com “gfs_hook.o” quando se está usando a biblioteca GNU C (glibc) tipicamente no Linux, para capturar apropriadamente as chamadas de sistema necessárias.

Programa em C ;

Recriar as aplicações vinculando com gfs_hook.o e -lgfarm.

% cc prog.o %%LIBDIR%%/gfs_hook.o -lgfarm

No caso de vinculação estática, pode ser usado ”libtool” acompanhado da opção “-all- static”.

% libtool --mode=link cc -all-static prog.c -o prog %%LIBDIR%%/gfs_hook.o \ –lgfarm -lglobus_gssapi_gsi_%%GLOBUS_FLAVOR%% -lsasl

Ressalta-se que, a vinculação estática resulta em falha de segmentação, quando usando autenticação LDAP no RedHat-8.0 e RedHat-7.3.

Fortran or C++ program;

Seguir a seção para programas em C e realizar a vinculação com ”gfs_hook.o” e “-lgfarm”, mas empregando o compilador apropriado.

MPI program.

No caso de programas MPI, vincular com “gfs_hook_no_init.o” e “hooks_init_mpi.c” ao invés de “gfs_hook.o”.

% mpicc prog.o %%LIBDIR%%/gfs_hook_no_init.o %%LIBDIR%% \ /hooks_init_mpi.c -lgfarm

142

11.1.3 AIX

O AIX não é suportado.

11.1.4 Outros sistemas

Entrar em contato por email com .

11.2 Limitação da biblioteca syscall-hook.

(A limitação não se aplica ao uso do GfarmFS-FUSE)

11.2.1 Limitação de acesso de um cliente exclusivo (não tem a função combinada de fsnode)

Existem limitações de acesso a arquivos, programas e bibliotecas compartilhadas no sistema de arquivos Gfarm a partir de um nó cliente exclusivo. As funções que seguem ainda não são suportadas:

execução de programa; vinculação de biblioteca compartilhada; criação de arquivo por um processo filho via redirecionamento; entrada de arquivo via redirecionamento.

O acesso para os programas mediante a criação de arquivos com bits de execução, ou leitura de arquivos que possuem os bits de execução, é possível mesmo num cliente exclusivo mediante duas possibilidades:

a) Declaração de variável de ambiente:

$ export GFARM_ARCHITECTURE=`arquitetura.gfarm`

b) Configurando “~/.gfarmrc”. Detalhes podem ser obtidos nas páginas de manual de gfarm.conf(5), na seção que aborda a configuração de “~/.gfarmrc”.

11.2.2 Limitação de acesso de um fsnode

Existem limitações para o acesso a arquivos no sistema de arquivos Gfarm a partir de um fsnode. A criação de arquivo mediante redirecionamento é suportada apenas quando se cria um novo arquivo. 143

A entrada de arquivo por redirecionamento é suportada somente quando se declara GFARM_FLAGS para habilitar a replicação por demanda, como segue:

$ export GFARM_FLAGS=r

Assim, todo arquivo será replicado no sistema de arquivos local por demanda, ao invés de acessá-lo remotamente. Por exemplo, o comando “tar zxfp foo.tar.gz” requer essa configuração.

11.2.3 Limitação para acessar nomes de commandos a partir de scripts

Se um script é armazenado no sistema de arquivos Gfarm, ele pode não ser capaz de acessar seu nome de arquivo. Por exemplo, “$0”, “$argv[0]”. Para contornar essa limitação, pode-se usar o interpretador com o nome do script como argumento, ao invés de invocar o script diretamente. Os scripts gerados pelo “autoconf” do GNU são exemplos desse caso. Dessa forma, ao invés de usar o comando:

$ ./configure

deve-usar:

$ sh ./configure

11.2.4 Limitação sobre o shell utilizável

Se um shell diferente do bash é usado, geralmente seu funcionamento não é correto. Assim, recomenda-se fortemente o uso do bash quando se está usando a biblioteca syscall- hook.

Por exemplo, como “/bin/sh” não é bash em sistemas operacionais que não são Linux, deve-se usar o comando a seguir:

$ env CONFIG_SHELL=`qual bash` bash ./configure

Vide também 10.2.3.

11.2.5 Limitação dependente do sistema operacional

11.2.5.1 Linux

Como visto em 1-1) (1), é preciso instalar “glibc-not-hidden” para usar a biblioteca syscall-hook.

144

11.2.5.2 FreeBSD

Atualmente, a função syscall-hook para a chamada de sistema “pathconf(2)” não está implementada. Dessa forma, o comando "ls -l" gera mensagens de advertência no FreeBSD-5.x e superiores, embora o comando funcione; Atualmente, as funções syscall-hook para “chflags(2)”, “lchflags(2)” e “fchflags(2)”, não estão implementadas; Atualmente, o script “configure” gerado por “autoconf” não funciona no sistema de arquivos Gfarm mesmo que o bash esteja sendo usado.

11.2.5.3 NetBSD

Atualmente, a função syscall-hook para a chamada de sistema “pathconf(2)” não está implementada; Atualmente, as funções syscall-hook para “chflags(2)”, “lchflags(2)” e “fchflags(2)”, não estão implementadas. Dessa forma, os comandos "install" e "gunzip" no NetBSD- 3.0 ou superior geram uma mensagem de erro, embora estejam muito próximos do perfeito funcionamento; No caso de usar um script “configure” gerado por “autoconf” no sistema de arquivos Gfarm, a linha de comando a seguir deve ser usada (vide 10.2.4):

$ env CONFIG_SHELL=`qual bash` bash ./configure

11.2.5.4 Solaris

Atualmente, o script “configure” gerado por “autoconf” não funciona no sistema de arquivos Gfarm mesmo que o bash esteja sendo usado. Uma das prováveis causas é a chamada de sistema access(2) não poder ser capturada corretamente em algumas ocasiões.

11.2.5.5 MacOS X

Plataforma ainda não testada.

11.2.5.6 HP-UX

Plataforma ainda não testada.

11.2.5.7 Tru64

Plataforma ainda não testada.

145

11.3 Semânticas e APIs estendidas

11.3.1 Semânticas de visualização de arquivo

A visualização padrão de arquivos recém criados é a local. Já para arquivos existentes, se o número de processos e de fragmentos de arquivo é o mesmo, a visualização padrão de arquivo é a local, caso contrário, será global. Na execução de “gfrun” com a opção “-b” option, a visualização padrão de arquivo pode ser alterada para global.

11.3.2 URL estendida do Gfarm

Aplicações como ROOT I/O cortam o nome do arquivo antes de “:”, sem qualquer verificação. Assim, é provida a variação “gfarm@” como URL do Gfarm. Por exemplo, “gfarm@” pode substituir “gfarm:” nas referências a arquivos, como segue:

gfarm@~/arquivoexemplo.txt para gfarm@~/arquivoexemplo.txt

Além disso, é provido um ponto de montagem virtual para o sistema de arquivos Gfarm em “/gfarm”. Nesse caso, um diretório home de usuário no sistema de arquivos Gfarm e o diretório de trabalho corrente podem ser especificados por “/gfarm/~” e “/gfarm/.”, respectivamente. Uma outra funcionalidade da URL estendida é prover uma forma de especificar explicitamente um índice de fragmento (ou nome de seção) de um arquivo Gfarm. Por exemplo, “gfarm::0: arquivoexemplo.txt“, “gfarm@:0:arquivoexemplo.txt” ou “/gfarm:0:/./arquivoexemplo.txt“ especifica o primeiro fragmento de “gfarm: arquivoexemplo.txt “.

11.3.3 APIs gfs_hook

APIs gfs_hook são providas para manipulação estendida das visualizações de arquivo além das semânticas padrão.

11.3.3.1 Visualização padrão de arquivo

As APIs seguintes trocam a visualização padrão de arquivo das operações de criação e abertura de arquivos que sucederão:

void gfs_hook_set_default_view_local(void); void gfs_hook_set_default_view_index(int index, int nfrags); void gfs_hook_set_default_view_section(char *section); void gfs_hook_set_default_view_global(void);

146

11.3.3.2 Trocando a visualização de arquivos

As APIs seguintes trocam a visualização de um arquivo especificado pelo descritor “fd”. A semântica é a mesma de “gfs_pio_set_view_local(3)”, “gfs_pio_set_view_index(3)”, “gfs_pio_set_view_section(3)” e “gfs_pio_set_view_global(3)”, respectivamente, exceto o primeiro argumento: char * gfs_hook_set_view_local(int fd, int flags); char * gfs_hook_set_view_index(int fd, int nfrags, int index, char *host, int flags); char * gfs_hook_set_view_section(int fd, char *section, char *host, int flags); char * gfs_hook_set_view_global(int fd, int flags);

$Id: README.hook.en,v 1.32 2006/06/12 05:39:32 soda Exp $ 147

12 INSTALAÇÃO DO CENÁRIO BÁSICO DO GFARM COM VMS

12.1 Conteúdo do DVD:

a. “FC5_GFCLI.zip”: arquivo com máquina virtual de File Server Node (fsnodes) + Client pré-configurada:

Endereços IP sugeridos: 192.168.0.177 e 192.168.0.79; Selinux e Firewall desativados; Usuários root e lab criados; Módulos instalados: gfarm-gsi-libs; gfarm-gsi-client; gfarm-gsi-doc; gfarm-gsi-frontend; gfarm-gsi-gfront. Biblioteca syscall-hook “glibc-not-hidden” instalada; Arquivo de configuração do metaserver já instalado no diretório “/etc”; Arquivo “hosts” com os nós configurados no cenário ou emprega-se um servidor DNS;

b. “FC5-GFMS.zip”: arquivo com máquina virtual de Metadata Server (metaserver) baseada em LDAP, pré-configurada;

Endereço IP sugerido: 192.168.0.78; Selinux e Firewall desativados; Usuários root e lab criados; Módulos instalados: gfarm-gsi-libs; gfarm-gsi-client; gfarm-gsi-doc; gfarm-gsi-server; openldap-server; Arquivo de configuração do metaserver já instalado no diretório “/etc”; Arquivo “hosts” com os nós configurados no cenário ou emprega-se um servidor DNS.

c. “Virtual PC 2004 SP1.zip”: Microsoft Virtual PC 2004 SP1; d. “AdobeReader_enu-7.0.8-1.i386.rpm”: instalador do Adobe Reader 7.0.8 for Linux; e. “winzip9.exe”; f. ANEXO_A_GUIAS_GFARM.doc: Guia de instalação; g. “3Com.mov”: filme para teste; h. “Chaves e Chapolin - A Bruxa Baratuxa.avi”: filme para teste.

148

Figura 31 – Conteúdo do DVD para criação de cenário de teste do Gfarm

12.2 Criação do cenário básico

Para criar o cenário básico, são necessárias as seguintes ações:

1. Instalar o Virtual PC 2004 (item c) em cada computador candidato a nó do Gfarm, o qual hospedará as Máquinas Virtuais (VMs). Recomenda-se que todos estejam no mesmo barramento de rede; 2. Copiar o arquivo correspondente à função desejada do nó (itens a ou b), num diretório disponível. Os nós foram criados no Linux Fedora Core 5; 3. Descompactar o arquivo correspondente (FC5_GFCLI ou FC5_GFMS), os quais resultam em dois outros arquivos cada, sendo um referente às configurações da VM e outro com o disco virtual. Sugere-se criar o diretório “VM”. O arquivo FC5_GFCLI é padronizado para se tornar novos fsnodes ou apenas clients, dependendo da configuração executada. Para criar novos fsnodes ou clients a partir da mesma VM, basta tomar as seguintes ações: Copiar e descompactar o arquivo da VM no computador desejado; Usando o “notepad” do Windows, alterar o endereço MAC da placa de rede virtual (ethernet_card_address), no arquivo “FC5_MSCLI.vmc”. Após o boot do Fedora Core 5, alterar o endereçamento IP de acordo com as necessidades peculiares de cada cenário. O local do registro segue abaixo:

0003FF055566 4. Criar as VMs na opção de “Add an existing virtual machine”, referenciando em seguida o arquivo de configuração da VM (extensão “vmc”). A tela de configurações da VM irá abrir. Localize o primeiro HDD, e preencha o caminho e o nome de arquivo de extensão “vhd” na mesma tela; configure a quantidade de memória (maior ou igual a 128MB); 5. Repetir 4 e 5 para todos os arquivos compactados dos nós do Gfarm; 149

6. Estando as VMs operando em seus respectivos nós, gerar a chave compartilhada. Num dos nós, fazer o login com o usuário lab, executando em seguida “gfkey –c”. O comando gera a chave e a armazena no arquivo oculto “gfarm_shared_key” no diretório home do usuário. O arquivo deve ser copiado para todos os nós respeitando a mesma estrutura de diretórios, incluindo o metaserver. Este procedimento deve ser repetido após 24 horas da geração da chave; 7. Se tudo estiver correto, a execução do comando “gfps” deve retornar ao prompt sem qualquer mensagem; 8. A seguir, os comandos do Gfarm podem ser utilizados (“gf” seguido de [TAB] mostra os comandos possíveis); 9. Como a biblioteca syscall-hook está presente, pode-se montar virtualmente “/gfarm” no prompt e trabalhar como se o sistema de arquivos fosse local; 10. Os arquivos em “g” e “h” podem ser importados com “gfimport_fixed” para testes funcionais; 11. Instalando-se o Adobe do item “d”, pode-se importar arquivos PDF para testes funcionais. Arquivos do tipo texto são importados com “gfimport_text”; 12. Para instruções sobre os comandos, usar o “man” do Linux.

150

ANEXO B – DADOS DETALHADOS DOS PRINCIPAIS RESULTADOS EXPERIMENTAIS

151

Tabela 1 – Benchmark – metasrv - LOCAL

Benchmark - metasrv - LOCAL iozone -Rab Q0_loc_meta.wks -g 256M -i 0 -i 1

The top row is records sizes, the left column is file sizes

MAIOR MENOR MÉDIA Writer Report 52695 6396 32158 Escrita 4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 64 36198 41049 47271 48415 47477 128 41251 45879 47994 52695 50996 48669 256 40895 44974 50295 49154 49563 46740 39042 512 38873 44057 45783 46655 47442 44031 39451 32686 1024 35910 39807 41526 41792 41787 39130 35769 34190 30602 2048 34245 37496 39329 40292 35460 37887 34838 33108 32980 30867 4096 32586 36426 38301 39081 38420 36866 32863 32525 32550 32630 30475 8192 31193 35223 36762 37332 37122 36308 33479 29662 32107 31587 31898 29924 16384 26282 31799 34090 33127 34196 31443 30027 27608 28431 27190 28899 30069 27910 32768 0 0 0 0 26457 25978 23705 23336 23231 23267 22865 22627 22746 65536 0 0 0 0 17356 16636 17485 16871 16176 16147 16349 8303 16456 131072 0 0 0 0 8280 8695 8500 8219 8801 7042 9516 7257 9783 262144 0 0 0 0 7795 6396 7978 8241 6819 7678 7467 7838 8208

Re-writer Report 115095 7520 52681 Reescrita 4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 64 92073 95234 104227 111293 115095 128 90841 100788 105689 102803 113481 108373 256 91755 94642 92552 103185 103142 91819 75473 512 75350 80427 84587 81540 83660 78001 63483 57593 1024 64059 65131 58627 62977 66740 63912 54598 50473 49978 2048 57213 59134 61705 61968 60455 57984 50597 47466 47453 47572 4096 54603 56435 58740 59305 54209 55250 46313 45743 46167 46266 46290 8192 52168 55386 57512 57520 56461 53346 48080 44827 45351 45052 44572 45706 16384 46967 47346 50688 52861 48768 49482 40907 41489 23471 42159 39091 41030 37387 32768 0 0 0 0 40266 38408 29498 28239 28608 28146 29501 29513 29890 65536 0 0 0 0 13275 13813 10831 12159 11270 11868 11409 8417 12045 131072 0 0 0 0 8757 9550 9588 8504 9519 8502 8747 8488 8598 262144 0 0 0 0 7706 7662 7655 8114 7642 7795 7542 7520 7925

Reader Report 200003 17848 92100 Leitura 4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 64 198710 164054 132482 138258 143186 128 200003 142870 123663 176567 168878 162847 256 156186 135227 133401 150756 146028 133898 103562 512 123908 129198 127613 135268 126735 123702 85617 66107 1024 121254 122193 123551 129572 127205 122766 80840 58894 55549 2048 122738 122664 127903 131951 131856 124938 73690 56322 52535 52072 4096 125925 125255 131033 136478 132205 126635 77156 55608 51051 48740 50973 8192 122044 129751 133755 138168 136351 130034 73379 54892 49636 50186 50249 50166 16384 127778 132878 136113 140525 138026 120628 77035 54000 49125 48996 49057 48889 49230 32768 0 0 0 0 135062 128142 76199 52909 49170 47881 48026 47673 47959 65536 0 0 0 0 29723 28319 21100 18514 24619 24082 21356 17848 18094 131072 0 0 0 0 29500 25566 21410 19475 19081 18409 19307 19056 19102 262144 0 0 0 0 28669 25256 21993 19735 19180 19165 19085 19181 19095

Re-reader Report 265529 12579 102017 Releitura 4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 64 208433 205719 178814 200616 203832 128 265529 237496 171327 199042 213358 131821 256 263092 205786 159594 181805 187408 163162 111501 512 151431 157835 141044 155716 154817 144385 91199 63847 1024 129408 136079 135664 142204 139872 126607 80903 58007 55576 2048 128902 129063 137477 142173 142006 129423 78939 56790 47961 51541 4096 132982 120890 137081 137436 139291 126607 76921 55118 51036 49715 48525 8192 132829 134185 137682 142022 139742 133021 78082 52514 49183 49504 50188 50228 16384 130311 131778 134970 136628 132403 128097 74795 54823 48941 48884 49903 49007 48880 32768 0 0 0 0 133629 126440 76684 53377 49099 48940 49284 49091 49124 65536 0 0 0 0 27402 30188 20517 18523 25032 17928 24241 15974 18199 131072 0 0 0 0 29719 26200 21967 19781 18331 19206 18915 19279 19334 262144 0 0 0 0 28192 25960 22104 19625 19172 19259 12579 19257 19161

MEMÓRIA total used free shared buffers cached Mem: 118220 111092 7128 0 22284 48660 -/+ buffers/cache: 40148 78072 Swap: 262136 104 262032

152

Tabela 2 - Benchmark – smbsvr - LOCAL

Benchmark - smbsvr - LOCAL iozone -Rab Q0_smbsvr_loc.xls -g 128M -i0 -i1

The top row is records sizes, the left column is file sizes

MAIOR MENOR MÉDIA Writer Report 39602 10709 30740 4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 64 31449 34244 34686 34633 33933 128 33421 36812 34343 39025 38141 36593 256 33547 38300 35649 38917 34352 38010 34711 512 25191 37066 34792 38072 38953 36394 38200 35008 1024 34050 39060 39146 38500 39602 38896 35826 35789 32948 2048 33650 37715 38678 38906 38485 38483 36951 35145 32692 31985 4096 31945 37297 38152 37662 37866 37992 36159 34617 32619 32069 30831 8192 26134 36754 36962 37378 37745 37535 35828 34027 32263 31732 31663 29955 16384 22739 36183 37290 37026 37250 37290 35586 33652 32132 31720 31592 31366 23321 32768 0 0 0 0 13114 25036 24154 23062 21894 21715 21644 21623 21748 65536 0 0 0 0 14240 18154 17537 16014 16871 16739 16695 16757 16714 131072 0 0 0 0 15659 15889 16000 15417 10709 14565 14976 14982 14775

Re-writer Report 81532 12168 49704 4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 64 71660 81532 81104 76368 71675 128 54258 76193 80656 48560 78290 69373 256 62225 66875 48310 70678 65625 67619 63506 512 48306 71151 70243 69152 68587 66744 62914 56599 1024 57592 64781 65903 64958 62492 64950 59545 53866 49537 2048 54304 61540 63180 62224 60885 62735 56772 53457 48921 46528 4096 53661 59704 61712 59745 59860 59792 55847 51262 46442 46515 46228 8192 53368 47433 60979 59646 59917 59890 55748 51556 47629 45512 46219 46405 16384 53719 59403 60675 59259 59885 59332 55025 50893 47402 46259 46122 46241 15340 32768 0 0 0 0 32875 38120 35351 32526 30365 30036 29949 29984 30338 65536 0 0 0 0 27257 22455 21371 19680 19561 21290 18738 19154 19180 131072 0 0 0 0 14601 13146 15887 13866 12168 16831 15668 16264 14418

Reader Report 118515 8762 66004 4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 64 68891 118515 73220 100613 90393 128 107559 118288 103386 103052 92613 101983 256 98465 114185 97229 91923 88921 80429 45181 512 102913 114033 106182 77870 85775 86121 75315 67112 1024 88904 106466 102053 84273 77871 76509 68582 64908 58671 2048 89659 100107 94074 79122 76914 75180 67317 60162 55764 53949 4096 88923 95213 91202 76074 73926 73148 65769 60538 54499 53066 53074 8192 88658 93269 91882 76712 74157 73982 66982 60455 55061 52833 52995 52453 16384 89298 97272 92734 77057 73928 72746 66742 60556 55022 52661 52621 53228 43216 32768 0 0 0 0 70515 73125 66487 60184 54901 53006 52710 53006 52611 65536 0 0 0 0 17364 10546 10061 9563 8762 9500 9616 9357 9494 131072 0 0 0 0 17870 10540 10100 9479 9318 9372 9435 9442 9435

Re-reader Report 140068 9327 69012 4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 64 117624 140068 129018 105248 110324 128 110145 125120 132232 113876 109493 104910 256 86958 119740 116678 100783 87312 91268 48402 512 72831 126265 118436 88003 84489 91771 75637 65920 1024 93066 105295 97747 84551 81966 80339 71214 64103 58830 2048 92255 102641 96617 80871 75241 77796 69205 62340 57147 54520 4096 89804 94900 92953 76417 73416 74483 67115 60996 55543 53548 53082 8192 90532 97894 92652 77171 75077 74594 67723 61263 54993 53289 53039 53103 16384 90746 98792 93124 76897 75047 73399 66586 60542 54800 53111 53144 52583 53004 32768 0 0 0 0 74439 73059 66756 60281 53829 53005 52592 52689 52957 65536 0 0 0 0 17997 10362 10529 9426 9402 9438 9446 9356 9387 131072 0 0 0 0 17295 10614 10195 9478 9527 9327 9465 9404 9330

MEMÓRIA total used free shared buffers cached Mem: 158480 155828 2652 0 64164 24136 -/+ buffers/cac 67528 90952 153

Tabela 3 – Benchmark – dfsvr1=dfsrv2 -VMs - LOCAL

Benchmark - dfsrv1 = dfsrv2 (VMs) - LOCAL iozone -Rab Q9_dfsrv1_new.wks -g 256M -i 0 -i 1

The top row is records sizes, the left column is file sizes

MAIOR MENOR MÉDIA Writer Report 31332 1822 15846 4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 64 1822 4216 7452 11287 14921 128 2278 4232 7161 10948 16524 21354 256 2264 4322 7669 11244 15460 20565 25669 512 2148 4275 7441 11679 17703 21982 24782 27337 1024 2279 4166 7160 11856 16663 20549 24546 28535 28560 2048 2214 4194 7524 11767 16487 19934 25830 28629 28874 30697 4096 2266 4266 7414 11374 17183 21984 25605 28483 29869 28467 31332 8192 2603 4164 7196 11870 16906 21554 25693 28299 29880 30940 30846 30766 16384 2164 4089 6929 10781 15280 18626 20647 23027 24167 24242 25637 25382 18768 32768 0 0 0 0 11602 14750 16224 17767 18237 18639 18654 18717 20482 65536 0 0 0 0 11308 13681 15343 15892 15096 15501 15897 15929 15694 131072 0 0 0 0 10623 12187 13557 14210 14537 15126 15224 15162 15407 262144 0 0 0 0 10372 12090 13432 14199 14592 14785 14813 14922 14903

Re-writer Report 74371 2345 26250 4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 64 2494 4693 8772 14645 21819 128 2345 4718 8571 14909 24863 37592 256 2524 4836 8628 15551 24772 34805 52925 512 2486 4692 8820 15554 24445 35283 46507 60284 1024 2388 4847 8986 15631 24801 34713 45773 59115 62591 2048 2491 4771 8875 15875 25277 35022 46650 53348 63262 69607 4096 2459 4779 9107 15070 24500 35409 44695 53573 61336 63005 74371 8192 2479 4800 8896 15653 24955 24604 45405 54207 60517 66182 68187 70428 16384 2439 4571 8456 13751 21206 29639 32581 36095 38706 40103 41372 42994 53275 32768 0 0 0 0 17707 22389 25722 27905 30643 32831 31030 30712 34678 65536 0 0 0 0 13805 16655 18535 19598 18319 18977 18915 18458 18955 131072 0 0 0 0 12126 14645 16223 16280 17027 19142 19087 19258 14046 262144 0 0 0 0 12077 14888 16474 17670 18726 18718 19033 18939 18657

Reader Report 350552 2150 206607 4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 64 127975 129564 128753 304677 331769 128 94194 139115 198158 331649 184433 259082 256 99999 155814 244023 274967 304433 302596 261194 512 89541 165058 239135 277052 336417 300842 348308 276916 1024 112230 171210 230262 303232 325602 350552 312092 271829 244047 2048 112719 172971 234244 295440 320055 340873 292317 276417 246953 249118 4096 109750 175898 237284 286712 327159 316535 342102 263765 245901 255761 249073 8192 112781 173218 242179 299786 321418 261741 325116 268070 250635 249870 248429 242445 16384 109885 171318 235091 297269 326550 338323 292529 265486 241064 256472 228791 255242 189469 32768 0 0 0 0 301850 326576 303705 239532 242030 228090 225510 245060 236472 65536 0 0 0 0 3611 2432 2150 6912 10592 7664 6150 8575 10449 131072 0 0 0 0 12216 11261 17212 13766 14128 14937 12005 13253 16486 262144 0 0 0 0 12644 12642 12432 14516 14762 15138 13089 15649 19729

Re-reader Report 428042 2005 213234 4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 64 134994 88776 150209 353611 395009 128 110061 170215 202849 362714 344181 428042 256 108428 161911 244529 282837 305474 341328 330303 512 108518 174976 240036 284110 334619 351146 326949 302234 1024 110226 170922 240091 294510 289584 348168 331276 278786 277733 2048 94929 184239 236761 294841 270364 301088 297806 262531 271474 263205 4096 113024 174892 139718 299045 331903 352553 353104 261274 258895 261355 256208 8192 113189 173824 234572 288552 333494 333455 329498 252333 255943 229160 244647 242467 16384 112346 171648 238611 290980 332555 340228 306426 257824 254485 236783 255888 218818 184602 32768 0 0 0 0 318340 331938 308204 237886 232856 239161 248972 238797 189355 65536 0 0 0 0 3792 2005 3185 6126 10465 8929 8491 12002 13653 131072 0 0 0 0 14812 10753 14236 13802 13288 12574 13709 17896 13190 262144 0 0 0 0 17422 15187 13360 15512 14087 14298 17276 14187 13179

MEMÓRIA total used free shared buffers cached Mem: 129928 73560 56368 0 15436 34704 -/+ buffers/cac 23420 106508 Swap: 262136 0 262136 154

Tabela 4 - Benchmark – dfsvr3 - LOCAL

Benchmark - dfsrv3 - LOCAL

/opt/iozone/bin/./iozone -Rab Q6_loc_srv3.wks -g 256M -i 0 -i 1

The top row is records sizes, the left column is file sizes

MAIOR MENOR MÉDIA Writer Report 183919 28542 100278 4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 64 141271 155330 168822 172087 149867 128 153477 175364 183919 160403 166452 129409 256 147034 161316 160397 152657 148667 128576 110677 512 129751 139734 137267 132262 121531 117026 114770 97524 1024 121112 126859 125153 112170 112428 106060 107562 106957 98451 2048 115699 120407 119605 113802 105420 102785 103906 104276 104762 100116 4096 48938 117488 116489 110693 103649 97133 102052 102927 103096 102679 100958 8192 108444 116142 112611 106963 101723 97792 100490 101159 101745 101846 102009 98259 16384 108512 114253 113391 107103 99304 97307 99996 99384 99239 99709 99768 100723 100182 32768 0 0 0 0 85306 84803 85689 86080 85844 86286 85607 86378 86020 65536 0 0 0 0 81550 81951 82569 82984 83103 83127 83084 83358 83256 131072 0 0 0 0 44938 43802 43653 44118 44080 44004 44392 43519 43099 262144 0 0 0 0 29243 28542 29005 30245 29153 28953 28958 29287 29306

Re-writer Report 484714 25627 171027 4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 64 355623 453809 484714 484543 435543 128 376369 449132 470681 396371 415708 244291 256 326067 340371 350648 304438 293581 219922 199671 512 263227 253602 236934 220678 194603 175466 173438 169139 1024 226749 222709 208126 184073 168479 155815 157851 156504 158170 2048 211046 201614 186775 169634 152302 130904 145579 149411 149969 150323 4096 207435 199221 182956 163741 148874 142742 144316 145786 146285 136738 147305 8192 204472 198075 182652 163794 143189 140976 138119 143653 141170 145099 145418 140661 16384 203083 192234 179526 158602 144222 139731 141951 142169 141640 144305 144805 144777 144616 32768 0 0 0 0 114346 114258 114648 116387 116943 114772 118293 114228 114147 65536 0 0 0 0 116668 113634 115080 116598 116599 116979 117977 118000 118316 131072 0 0 0 0 47768 47012 47347 47081 47055 46801 46626 46563 46579 262144 0 0 0 0 27558 27853 29669 28069 27027 29326 27278 28095 25627

Reader Report 426479 29126 237373 4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 64 355394 390088 426479 418580 387871 128 330764 367919 353574 368989 282620 312140 256 311398 333349 349285 322040 315296 272080 234426 512 308057 324882 333104 340408 340219 266805 212091 202941 1024 324256 340643 360695 364273 374554 266943 205503 182991 177965 2048 333164 364027 377377 387577 377236 259961 201198 177393 169762 169888 4096 344288 372021 391625 398293 389357 261642 199329 174438 166395 164155 166099 8192 352557 377947 384131 406672 402041 266987 200254 164799 164250 161475 161769 163385 16384 355965 382391 402190 411472 408210 264629 199134 170150 163501 162480 161708 162541 162304 32768 0 0 0 0 415368 267633 196322 170137 160890 161266 161721 161517 161098 65536 0 0 0 0 415824 267381 197950 171857 161696 160990 162344 160906 161152 131072 0 0 0 0 29611 29544 30072 29126 29819 29881 29778 29947 30063 262144 0 0 0 0 30029 30337 29957 30349 30359 30018 30151 30354 30374

Re-reader Report 1082626 28897 277577 4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 64 941636 1082626 1016701 929049 647120 128 646685 618163 391561 524734 505879 361554 256 342273 383238 437560 444517 420415 279447 224762 512 351636 374294 402527 407029 421746 267628 208800 204383 1024 352619 379107 396424 409092 397044 269903 203178 182925 176644 2048 354511 369267 400541 408217 392861 259341 185910 177209 169649 169732 4096 356734 383161 404906 409970 399375 259141 198959 174246 166274 165147 165957 8192 349575 385416 394926 402988 406490 263824 199941 172739 164392 158532 164013 157163 16384 359196 386315 406852 414491 411131 264530 198656 172283 163320 163016 162961 163015 162454 32768 0 0 0 0 414186 265344 198470 171847 161020 161773 161730 161644 161712 65536 0 0 0 0 410266 268961 197483 171091 161429 162058 160767 161930 161262 131072 0 0 0 0 29984 29982 29992 30009 30040 29950 30074 30018 30059 262144 0 0 0 0 30336 28897 30185 30349 30364 30203 30227 30313 30374

MEMÓRIA total used free shared buffers cached Mem: 182740 180152 2588 0 14912 67128 -/+ buffers/cac 98112 84628 Swap: 327672 121772 205900 155

Tabela 5 – Benchmark – dfsvr4 - LOCAL

Benchmark - dfsrv4 - LOCAL iozone -Rab Q11_local_dfsrv4.xls -g 256M -i 0 -i 1

The top row is records sizes, the left column is file sizes

MAIOR MENOR MÉDIA Writer Report 86695 12376 57485 4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 64 21739 36035 51782 64903 76289 128 22547 36415 52481 66734 77759 82640 256 22155 36081 50946 62438 73624 81375 80653 512 21764 34979 50970 62061 71779 79195 82142 80076 1024 21674 34833 49910 61955 69617 77032 81373 86538 81704 2048 21673 33099 49074 60889 68574 71603 81218 84339 86695 84943 4096 21419 34627 49101 59448 68322 74681 77268 83934 85834 86576 82084 8192 21346 34056 47947 60413 66821 74390 78683 82272 84035 82429 85618 85961 16384 21386 34063 47785 59656 66692 73315 79173 82842 82446 84552 85388 86039 85601 32768 0 0 0 0 60965 68210 73724 76371 77963 78480 79146 79174 80152 65536 0 0 0 0 50458 66177 71094 74174 75607 76781 77480 77191 77149 131072 0 0 0 0 12781 12650 18786 21385 12399 12376 22362 20995 22454 262144 0 0 0 0 17004 16662 12711 16665 17372 16561 17314 17006 15499

Re-writer Report 146120 12371 82077 4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 64 23038 42131 66811 52032 114272 128 25437 44258 69905 97346 119506 146120 256 25364 42454 68651 75809 108753 120020 132994 512 23638 42289 65936 81296 101970 116705 131080 140085 1024 24687 37808 63741 84335 97300 111027 112206 132352 138190 2048 24677 40458 63256 83103 94213 107012 119696 129563 132607 136487 4096 24704 41513 61880 81753 93901 105539 118831 126563 129435 133017 133939 8192 24528 41341 62519 82294 94350 105886 118043 121476 130145 133533 134827 135892 16384 24640 41202 62100 81399 92298 104265 115652 126023 130397 132910 132726 133276 130597 32768 0 0 0 0 85203 94450 104757 112151 114340 117716 118022 119410 118341 65536 0 0 0 0 82626 92032 103033 109663 111961 114004 115865 116688 116741 131072 0 0 0 0 12505 23339 12658 12371 23333 22603 22305 23939 22557 262144 0 0 0 0 13761 14751 13903 13414 13600 14235 14319 14436 13926

Reader Report 414081 9399 242395 4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 64 331440 370141 355577 388051 405039 128 345021 359631 355667 395126 365679 331582 256 329499 365769 386751 384437 396898 323275 233557 512 345014 363107 390506 399049 400629 305485 225843 192186 1024 357296 378427 396588 408952 409601 305767 214269 180093 174621 2048 360504 381726 399848 414081 384679 295780 212734 171769 166273 166423 4096 353772 380210 400158 403981 409109 294507 208236 170050 161769 153990 161871 8192 357478 378224 398036 407460 407033 266336 206435 169909 159622 160341 159529 148220 16384 356895 375960 402435 412011 390605 270385 202797 165471 155820 154959 153180 156738 156748 32768 0 0 0 0 410899 290898 206962 166417 157464 157953 155836 155387 154752 65536 0 0 0 0 396520 282656 206056 166441 154936 155377 154670 155959 155191 131072 0 0 0 0 13463 9406 9399 9537 9532 9693 9839 9819 9643 262144 0 0 0 0 13438 9874 9474 9512 9536 9660 9772 9769 9750

Re-reader Report 876511 9455 275255 4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 64 876375 876511 781333 791048 508016 128 836802 385481 673397 703274 659779 403652 256 453034 445906 448251 436913 415574 322394 224174 512 363641 380362 408636 420047 405085 300133 220317 178902 1024 362095 384950 399387 418307 358932 296046 212843 173233 174325 2048 360567 370148 388244 412736 411088 286831 205023 171250 166761 166328 4096 363539 384711 403429 417065 409850 283499 192111 168261 163161 162772 160954 8192 360070 380722 401629 385034 409090 289633 207229 170443 159114 159947 158805 159315 16384 349279 374346 401293 397235 408404 288216 208106 165994 159118 151982 154719 155129 156516 32768 0 0 0 0 415400 275460 203346 164945 155614 154408 155331 154752 155595 65536 0 0 0 0 408759 280657 201616 165559 154507 154341 155115 153847 154710 131072 0 0 0 0 13319 9934 9541 9551 9571 9721 9747 9709 9805 262144 0 0 0 0 13440 9956 9482 9564 9455 9752 9883 9801 9810

MEMÓRIA total used free shared buffers cached Mem: 255988 245200 10788 0 26000 104420 -/+ buffers/cach 114780 141208 Swap: 524280 0 524280

156

Tabela 6 – Benchmark – gfwks - LOCAL

Benchmark - gfwks - LOCAL iozone -Rab /tmp/gfwks_loc.wks -g 384M -i 0 -i1

The top row is records sizes, the left column is file sizes

MAIOR MENOR MÉDIA Writer Report 115012 18620 80307 4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 64 27060 107908 104063 111122 106489 128 101822 110725 115012 114189 109123 103400 256 100275 106751 110962 109072 108702 102815 90653 512 94464 95950 103645 101909 100294 95842 94014 83196 1024 90347 46854 98556 97719 95460 92177 92020 91330 86159 2048 88097 94048 95858 94612 90981 89978 89182 89537 90089 85693 4096 87175 92487 74748 89976 88788 87887 88533 87946 88108 88309 80023 8192 77354 91918 93514 90487 87361 87160 87698 87631 86457 18620 88826 80115 16384 77265 90198 92527 73968 87428 87063 87383 87639 87752 76945 88146 88256 75546 32768 0 0 0 0 26746 77263 47091 78429 87360 75497 87324 79577 43093 65536 0 0 0 0 55770 71871 72458 59444 72316 72243 55459 71424 71797 131072 0 0 0 0 56554 68048 47332 67564 68197 69357 69359 70039 69650 262144 0 0 0 0 20988 33835 36553 36540 37090 25448 25268 25282 24243

Re-writer Report 254501 21965 139319 4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 64 200062 229311 242317 238870 112487 128 209177 224597 254501 250506 246188 221421 256 199070 216401 220518 211935 211374 190474 157259 512 163051 184907 187132 185573 176791 162692 156866 153617 1024 162205 170239 171638 168037 162694 150987 147022 149664 152428 2048 156670 163918 164338 159291 149938 145795 80804 145156 146977 145735 4096 153649 161896 162443 156706 146123 73706 142657 142593 137200 143698 140053 8192 151328 158104 161057 104095 145083 137171 141117 138635 142491 142407 143352 141042 16384 149434 158870 158836 153269 142308 139647 140402 141409 141578 141411 140373 141833 138947 32768 0 0 0 0 39584 129730 129525 139054 132245 139799 132256 140040 138252 65536 0 0 0 0 110848 107149 107500 87983 106428 112343 106496 104989 111391 131072 0 0 0 0 33516 48506 65672 79040 88501 94134 96749 99966 100940 262144 0 0 0 0 30994 21965 31076 24583 25417 38845 25663 25419 38179

Reader Report 410503 28139 255878 4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 64 353455 383137 407448 402364 407799 128 324895 346042 353562 398653 395189 332384 256 328616 343138 369881 399408 401876 299396 232738 512 340640 353808 379533 384669 395950 294749 222024 197081 1024 341330 369938 384826 402376 392037 295105 221361 136754 178927 2048 92527 352797 395445 403699 409688 287481 214272 178585 174164 174491 4096 347531 319475 397670 354418 409438 280682 206140 178709 166687 169550 156026 8192 344896 378294 398755 410503 405947 283597 208798 176738 168209 169259 170631 170546 16384 333951 355925 396686 393006 395195 230118 174941 138706 170025 166055 168901 167212 169326 32768 0 0 0 0 399536 279126 209708 161609 166860 155306 166664 154630 167770 65536 0 0 0 0 396942 283069 214174 179309 168541 167572 167884 169072 168284 131072 0 0 0 0 403192 284862 213058 177004 168140 167250 167743 167962 168185 262144 0 0 0 0 30688 28152 28395 28377 28473 28432 28139 28385 28477

Re-reader Report 889379 25377 281376 4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 64 820657 864344 811058 889379 424071 128 540304 564045 551752 503802 542325 385570 256 392606 399336 415512 458785 414898 302990 227955 512 356774 239913 400292 416918 413875 295266 220597 195938 1024 354562 378838 400624 417787 410095 296034 218101 180826 185943 2048 354320 383447 385535 416506 391140 288170 197873 170653 176187 174715 4096 331095 375261 402002 402115 402995 267992 207286 167389 172310 172937 25377 8192 348137 372566 397246 396381 405724 285565 216090 179748 170805 168445 171144 111677 16384 270488 237249 287594 316018 389151 287337 214352 179302 168182 169352 169775 145723 170032 32768 0 0 0 0 343689 286691 215152 165556 168279 168527 169027 157239 169189 65536 0 0 0 0 405471 282407 210348 177046 169013 167348 168343 168613 168356 131072 0 0 0 0 404429 285712 214466 177652 168240 167446 168528 167469 168350 262144 0 0 0 0 26443 28326 28443 27697 28447 28391 28515 28463 28533

MEMÓRIA total used free shared buffers cached Mem: 385948 193796 192152 0 9024 63036 -/+ buffers/cach 121736 264212 Swap: 786424 3852 782572 157

Tabela 7 – Benchmark – Gfarm 1.2-5 (1.2 PL4) – 4 nós - smbsvr

Benchmark - Gfarm 1.2-5 - 4 nós - smbsvr iozone -Rab /geral/Q17_smbsvr_4nodes.wks -g 128M -i0 -i1

The top row is records sizes, the left column is file sizes

MAIOR MENOR MÉDIA Writer Report 7148 1254 5379 Escrita 4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 64 1502 5014 5639 1254 1309 128 4125 4997 5381 6183 7094 2208 256 3913 4970 5599 3162 3332 3351 3380 512 4131 4929 5611 6214 4592 4542 7069 4441 1024 4198 5067 5497 6280 7008 7148 6951 6821 5458 2048 4176 5119 5538 6237 6190 7003 7000 6955 6198 6853 4096 4178 5064 2084 2819 6474 7088 7012 7074 7080 7023 7008 8192 4167 1816 5318 6190 3685 6896 6716 6938 6614 7054 6526 7070 16384 4165 1770 5679 6255 6976 7071 3818 3695 7125 6853 3963 7078 3680 32768 0 0 0 0 6829 3730 6711 6771 3472 6631 6905 3638 6649 65536 0 0 0 0 6270 6815 3415 6500 3674 6807 6554 3549 6816 131072 0 0 0 0 3712 6879 6239 3474 6855 5973 3459 6703 6193

Re-writer Report 7519 1826 5882 Reescrita 4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 64 4073 5323 5950 6060 7519 128 4226 5364 5746 6682 2256 7118 256 4281 5304 5643 6393 7280 7461 7377 512 4173 5274 5744 6298 7052 4535 6994 7247 1024 4269 5131 5684 6422 7090 7306 7239 7224 7036 2048 4238 5308 5711 6430 7196 7185 7191 7151 6273 6299 4096 4259 5227 2258 3121 7262 6778 7208 6768 7228 7191 7102 8192 4250 1826 5662 6392 3987 6731 7153 6904 6710 6965 6899 7254 16384 4273 1876 5822 6459 7061 7173 4344 3981 7305 7066 4372 7133 3980 32768 0 0 0 0 7097 4139 7073 6914 3854 6748 7204 4137 6719 65536 0 0 0 0 6724 6959 3710 6655 4050 7066 6634 3696 6961 131072 0 0 0 0 3956 6858 6476 3677 6903 6410 3653 6843 6436

Reader Report 202606 743 13620 Leitura 4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 64 202606 196282 162806 117856 108129 128 14349 14263 13996 13657 13483 13537 256 9558 9545 9239 9271 9128 8205 9086 512 8348 8277 8021 8028 7918 7865 7921 7918 1024 7744 7530 7509 7227 7378 7446 7465 7320 7320 2048 7475 7379 7317 7133 7085 7103 7057 7086 7021 6995 4096 7368 7344 743 981 6972 7071 7038 6989 6899 6882 6958 8192 7293 914 7208 7119 888 6985 7018 6918 6922 6902 6931 6961 16384 7342 944 7262 7144 7076 7063 1279 866 6994 6951 1322 6938 934 32768 0 0 0 0 7074 1193 7044 6989 869 6956 6972 1114 6949 65536 0 0 0 0 7065 6853 803 7032 1101 6779 6952 802 6828 131072 0 0 0 0 1142 6882 7059 800 6870 6957 819 6843 6951

Re-reader Report 189331 796 13397 Releitura 4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 64 189331 188260 163288 114917 108304 128 14314 14258 13916 13679 13078 13118 256 8723 9634 9424 9432 8454 9157 9144 512 8303 8262 8107 8125 7621 7970 7850 7929 1024 7680 7703 7592 7468 7477 7291 7284 7175 7303 2048 7441 7445 7461 7228 7164 7180 7162 7121 6997 6939 4096 7359 7291 858 930 7078 7109 7049 7001 6999 6945 6823 8192 7232 975 7175 7029 796 6980 6976 6921 6908 6925 6975 6971 16384 7345 1068 7280 7128 7089 7079 1144 851 7008 6961 1357 6936 900 32768 0 0 0 0 7070 1054 7040 7007 901 6962 6961 1012 6944 65536 0 0 0 0 7082 6976 882 7028 1090 6752 6953 863 6731 131072 0 0 0 0 1052 6953 7063 852 6825 6958 892 6839 6947

158

Gfarm 1.2-5 - Leitura - 4 nós - smbsvr iozone -Rab /geral/Q17_smbsvr_4nodes.wks -g 128M -i0 -i1

250000

200000

150000 200000-250000 Vazão (KB/s) 150000-200000 100000 100000-150000 50000-100000 0-50000 50000 16384 2048 256 0 Tamanho Registro (KB) 32 64 128 256 512 4 1024 2048 4096 8192 16384 32768 65536

Tamanho Arquivo (KB) 131072

Gfarm 1.2-5 - Escrita - 4 nós - smbsvr iozone -Rab /geral/Q17_smbsvr_4nodes.wks -g 128M -i0 -i1

8000

7000

6000

5000 7000-8000 6000-7000 Vazão (KB/s) 4000 5000-6000 4000-5000 3000 3000-4000 2000-3000 2000 16384 1000-2000 0-1000 1000 2048 256 0 Tamanho registro (KB) 32 64 128 256 512 4 1024 2048 4096 8192 16384 32768 65536

Tamanho arquivo (KB) 131072

Figura 32 – Gráficos do benchmark da Tabela 7 – Leitura e Escrita 159

Tabela 8 – Benchmark – Gfarm 1.2-5 (1.2 PL4) – 4 nós – atraso de 250ms para o metaserver

Benchmark - Gfarm 1.2-5 - atraso de 250ms para o metaserver - 4 nós iozone -Rab /geral/Q18_smbsvr_4nodes_delay250.wks -g 128M -i0 -i1

The top row is records sizes, the left column is file sizes

MAIOR MENOR MÉDIA Writer Report 7218 1707 5487 4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 64 1707 5030 5661 6175 6577 128 4223 5368 5137 6227 7170 6755 256 4295 5310 5840 6364 7174 7124 3304 512 4248 5107 5629 6320 3306 7167 4550 7218 1024 4237 5229 2038 6291 7112 6918 7081 7083 6953 2048 4206 5183 5679 6318 7153 7183 7176 7202 7162 6922 4096 4266 5287 5702 5923 6686 3758 3760 3766 3783 6954 7020 8192 4238 5280 5702 6348 6919 3773 3795 6907 6605 6587 3523 3783 16384 4240 5179 2144 6365 3628 6883 6983 7030 3809 7007 7043 3755 6982 32768 0 0 0 0 3575 6678 3521 3641 6893 6797 3553 6819 6645 65536 0 0 0 0 3589 6643 3583 6196 3482 6247 3589 6838 6406 131072 0 0 0 0 3422 6904 6214 3574 6867 6175 3573 6163 3435

Re-writer Report 7434 1319 5603 4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 64 4429 5236 5935 6308 1319 128 4284 5475 5964 6455 2181 7380 256 4385 5413 5810 6601 7369 7369 7256 512 4337 5266 5708 4338 3753 4719 7375 7224 1024 4277 5440 2305 5195 7381 5740 7319 7349 7047 2048 4316 5339 5869 6529 7434 7378 7353 6412 7295 5641 4096 4332 5397 5819 6451 6877 4113 4132 4100 4105 6747 7237 8192 4326 5394 5828 6505 7100 4211 4178 7325 6785 7255 4115 4133 16384 4328 5320 2294 6480 4065 7335 7163 7272 4162 6992 7131 4068 7087 32768 0 0 0 0 3734 7166 3942 3960 7142 7098 3904 7034 6862 65536 0 0 0 0 3893 6967 3900 6354 3656 6700 3896 6924 6794 131072 0 0 0 0 3585 6879 6300 3822 6653 6576 3802 6287 3576

Reader Report 218420 732 13354 4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 64 218420 188748 159232 120079 106318 128 14464 14412 14098 13168 12938 13723 256 9854 9745 9665 9472 9389 9401 9244 512 8442 8435 8298 8119 2342 7922 8028 7935 1024 7922 7902 2161 7630 7584 7573 7457 7512 7501 2048 7569 7655 7438 7317 7256 7283 7249 7233 7208 7128 4096 7560 7501 7438 7262 7176 1209 1368 1009 1078 7143 7073 8192 7465 7449 7380 7187 7117 1208 1271 7084 7091 7085 732 890 16384 7454 7407 1247 7232 972 7133 7074 7109 1210 7037 7049 754 7014 32768 0 0 0 0 1177 7149 904 1019 7063 7027 981 7017 6991 65536 0 0 0 0 1178 6796 1131 7067 880 7011 1131 6882 6991 131072 0 0 0 0 894 6954 7068 1128 6920 7000 1095 6989 870

Re-reader Report 207734 734 13402 4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 64 207734 206421 168824 109776 107002 128 14489 14189 14231 13663 13517 12747 256 9827 9119 9245 9353 9225 9405 9069 512 8341 8376 8276 8163 1133 8127 8035 7816 1024 7862 7896 734 7623 7472 7615 7549 7360 7470 2048 7658 7644 7462 7346 7305 7328 7278 7338 7330 7270 4096 7529 7526 7472 7297 7104 1504 1309 1648 2103 7105 7113 8192 7436 7414 7347 7212 7151 1147 1276 7100 7090 7070 966 943 16384 7426 7401 1200 7201 946 7151 7094 7107 1050 7030 7033 787 7027 32768 0 0 0 0 1177 7145 886 1173 7052 7023 843 7021 7021 65536 0 0 0 0 1116 7018 1209 7051 790 7008 1111 6753 6985 131072 0 0 0 0 865 6989 7077 1111 6919 7007 1221 6994 861 160

Gfarm antes 1.2-5 - smbsvr - atraso de 250ms para o metaserver - 4 nós iozone -Rab /geral/Q18_smbsvr_4nodes_delay250.wks -g 128M -i0 -i1

250000 Tamanho do registro (KB) Leitura 200000 4 8 16 150000 32 64 128 256 Vazão (KB/s) 100000 512 1024 2048 50000 Escrita 4096 8192 16384 0

6 8 56 12 48 6 36 4 8 12 4 48 96 84 2 64 12 2 5 09 384 6 12 256 5 02 768 7 1024 20 4 8192 16 32768 655 1 20 40 8192 163 32 6553 131072 1310 Tamanho do arquivo (KB)

Gfarm 1.2-5 - smbsvr - atraso de 250ms para o metaserver - 4 nós Tamanho iozone -Rab /geral/Q18_smbsvr_4nodes_delay250.wks -g 128M -i0 -i1 do registro (KB) 250000 4

Releitura 8 200000 16

150000 64

128

256 Vazão (KB/s) 100000 512

1024 50000 Reescrita 2048

4096

0 8192 4 4 8 6 2 6 8 4 8 6 2 6 28 56 24 48 92 6 64 28 5 12 24 4 96 92 8 7 1 2 512 10 20 4096 81 38 107 1 2 5 10 20 40 81 16384 16 327 6553 13 163 3276 6553 1310 Tamanho do arquivo (KB)

Figura 33 – Gráficos do benchmark da Tabela 8

161

Tabela 9 – Benchmark – Gfarm 1.3.1 – 4 nós

Benchmark - Gfarm 1.3.1 - smbsvr - 4 nós iozone -Rab /geral/Q21_smbsvr_gf131_4nodes.wks -g 128M -i0 -i1

The top row is records sizes, the left column is file sizes

MAIOR MENOR MÉDIA Writer Report 6414 1215 4576 Escrita 4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 64 1395 5109 2100 1215 6221 128 1354 1936 5505 2084 2929 3264 256 4018 5195 2256 2877 4868 6356 3499 512 1523 5086 5388 3035 3789 4251 6188 3751 1024 1551 5118 5554 3072 3897 6271 6414 3830 3790 2048 4008 5191 2037 3016 5600 6397 3684 3861 6079 6052 4096 1327 1948 5431 5882 3769 3930 5939 5918 3791 3949 6072 8192 4037 1873 2284 5624 6306 3866 3833 6223 6288 3781 3891 5600 16384 3946 1839 2223 5747 5996 3881 3284 6171 6199 3521 3880 6075 6101 32768 0 0 0 0 3665 3678 5790 5912 6005 5937 5908 6012 6006 65536 0 0 0 0 6093 6066 5843 6034 5932 5918 5874 5775 5939 131072 0 0 0 0 6015 6025 5530 5529 5535 5626 5551 5469 5539

Re-writer Report 6536 1493 4877 Reescrita 4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 64 1579 5319 2421 5411 6500 128 1493 2169 5806 5827 4111 4293 256 4037 5319 2334 3420 5825 6360 4218 512 1529 5252 3892 3353 4613 5029 4330 4463 1024 1639 5209 5595 3349 4436 6372 6397 4309 4368 2048 4047 5332 2251 3355 5762 6534 4255 4471 6343 6403 4096 1548 2104 5574 5589 4293 4445 6337 6536 4272 4440 5675 8192 4130 1993 2503 5850 6368 4252 4377 6386 6442 4181 4357 6211 16384 4136 1949 2408 5853 6243 4315 4015 6336 6226 4130 4363 6183 6112 32768 0 0 0 0 4054 4145 6185 6258 6065 6070 6079 5978 6041 65536 0 0 0 0 6207 6059 6142 6095 6027 5989 6081 6040 6125 131072 0 0 0 0 5991 6037 5687 5637 5669 5653 5626 5670 5668

Reader Report 8262 1697 5539 Leitura 4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 64 1944 5604 2881 7514 7515 128 1782 2899 6635 7556 1811 3713 256 4180 5480 2053 2439 7699 7905 3488 512 1947 5207 6432 1697 2165 8040 8018 2337 1024 1973 5573 6526 2258 2389 8001 8029 2427 3198 2048 4238 5722 1813 2607 8177 8152 2566 2710 8028 7945 4096 1969 3069 6454 7679 2682 2668 8154 8092 2738 2788 7847 8192 4336 2938 2160 7594 8262 2396 2566 8084 8051 2256 2822 7860 16384 4320 2910 2796 7484 8210 2067 3068 7910 8009 2167 3101 7709 7907 32768 0 0 0 0 2797 3001 8102 8017 7995 7960 7933 7918 7866 65536 0 0 0 0 8137 8147 8133 8045 7975 7936 7946 7955 7906 131072 0 0 0 0 8038 7993 8151 8065 8002 7951 7931 7931 7949

Re-reader Report 8379 1896 5591 Releitura 4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 64 2001 5479 2811 7008 8379 128 1940 2982 6596 7593 3528 1896 256 4139 5767 2075 2419 7923 8028 2320 512 2010 5584 6636 2245 2615 8157 8118 2712 1024 1991 5477 6572 2664 2943 8113 8191 2823 3284 2048 4217 5769 2127 3220 8239 8180 2999 2543 7954 8001 4096 1942 3181 6439 7670 2649 3057 8183 8148 2233 2891 7864 8192 4333 2918 2584 7612 8296 2093 2778 8081 8005 2303 3247 7883 16384 4322 2909 2753 7582 8191 2093 2845 8089 7967 2642 2802 7844 7895 32768 0 0 0 0 2382 2940 8113 7823 7997 7961 7912 7917 7861 65536 0 0 0 0 8201 8146 8105 8049 8009 7952 7915 7953 7904 131072 0 0 0 0 8047 7992 8145 8048 8003 7977 7950 7949 7948

162

Gfarm1.3.1 - leitura - smbsvr - 4 nós iozone -Rab /geral/Q21_smbsvr_gf131_4nodes.wks -g 128M -i0 -i1

9000

8000

7000

6000 8000-9000 7000-8000 5000 6000-7000 Vazão (KB/s) 5000-6000 4000 4000-5000 3000-4000 3000 2000-3000 1000-2000 2000 16384 0-1000 4096 1000 1024 256 0 64 Tamanho do registro (KB)

64 16 128 256 512

1024 4 2048 4096 8192 16384 32768 Tamanho do arquivo (KB) 65536 131072

Gfarm1.31 - escrita - smbsvr -4 nós iozone -Rab /geral/Q21_smbsvr_gf131_4nodes.wks -g 128M -i0 -i1

7000

6000

5000

6000-7000 4000 5000-6000 Vazão (KB/s) 4000-5000 3000 3000-4000 2000-3000 2000 1000-2000 16384 0-1000 1000 4096 1024 256 0 64 Tamanho do registro (KB)

64 16 128 256 512

1024 4 2048 4096 8192 16384 32768 Tamanho do arquivo (KB) 65536 131072

Figura 34 – Gráficos do benchmark da Tabela 9 – Leitura e Escrita

163

Tabela 10 – Benchmark – Gfarm 1.3.1 – 4 nós - atraso de 250ms para o metaserver

Benchmark - Gfarm 1.3.1 - 4 nós - atraso de 250ms para o metaserver - iozone -Rab /geral/Q22_smbsvr_gf131_dl_250_4nodes.wks -g 128M -i0 -i1

The top row is records sizes, the left column is file sizes

MAIOR MENOR MÉDIA Writer Report 6397 1087 4299

4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 64 1087 4800 1233 1993 6068 128 3894 1863 2210 5660 6337 3160 256 1513 4259 5349 2843 3365 6116 5953 512 1358 1948 5352 4027 3575 3768 6231 6081 1024 1397 1977 5393 4765 3837 6397 3762 5060 3894 2048 1411 5184 2274 5227 5572 3874 3759 6345 6160 3775 4096 1542 4960 5522 2948 3920 5950 5667 3877 3900 6211 6150 8192 1350 1964 5513 2863 6087 3747 3856 5955 6229 3746 3846 6212 16384 4009 1844 2133 5685 6240 3768 3793 6013 3869 5894 3791 3835 5956 32768 0 0 0 0 5925 3615 6126 3610 5922 3590 6097 3659 5843 65536 0 0 0 0 5659 3472 3544 5621 3545 5846 3542 5951 5545 131072 0 0 0 0 3412 3531 3475 5962 5520 3427 3554 5883 3443

Re-writer Report 6573 1304 4423

4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 64 1597 5052 5353 2965 1304 128 3919 1983 2490 2093 2190 3450 256 1636 5026 5566 3166 3977 3325 3237 512 1517 2064 5462 3990 4079 4163 6493 6418 1024 1521 2132 5492 4834 4201 6247 4286 5209 4230 2048 1542 5352 2350 5324 6573 4255 4413 6414 6470 4219 4096 1536 5099 5674 3211 4411 6435 6488 4290 4312 6224 5999 8192 1498 2105 5499 3160 6075 4216 4255 6545 6344 4212 4223 6384 16384 4069 2020 2267 5850 6354 4269 4168 6497 4309 6178 4233 4290 6102 32768 0 0 0 0 6095 4009 6211 4027 5708 3975 6172 4009 6143 65536 0 0 0 0 5809 3912 3907 5679 3936 5953 3922 6052 5629 131072 0 0 0 0 3671 3791 3902 5935 5662 3729 3823 5897 3698

Reader Report 8320 1663 4907

4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 64 1880 5247 6490 2814 7562 128 4125 2748 2977 7310 7695 3604 256 2005 5420 6499 1663 2682 3550 7953 512 1979 3025 6458 7500 2709 4020 7970 8102 1024 1936 3187 6401 7636 3096 8191 3144 7854 2642 2048 1960 5680 1786 7531 8320 2805 2860 8120 8081 2999 4096 1991 5575 6496 2742 2651 8192 8219 2737 2901 7957 8007 8192 1967 3022 6330 1999 8283 2073 2526 8180 8082 2182 2269 7995 16384 4263 2996 2122 7715 8252 2068 2251 8083 2356 7951 2366 3044 7822 32768 0 0 0 0 8273 2220 8134 3029 8007 2350 7988 3105 7947 65536 0 0 0 0 8224 2407 2327 8100 2481 7979 2249 7945 7977 131072 0 0 0 0 2335 2217 2159 7952 8015 2379 2233 7784 2296

Re-reader Report 8281 1133 4947 4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 64 2052 5565 6555 1133 7477 128 4121 2831 3381 7403 8186 3431 256 1977 5399 6495 2226 2607 8029 8049 512 1988 3125 6461 7616 1990 4277 7918 7914 1024 1923 3076 6418 7601 2790 8147 3179 8204 3273 2048 1970 5727 2243 7511 8247 2801 2782 8096 8068 3361 4096 1983 5550 6503 2637 2766 8145 8221 2194 3039 7890 8009 8192 1965 3076 6506 2037 8281 1753 2294 8183 8063 2234 2151 7985 16384 4277 3159 1933 7718 8260 1878 2306 8107 2428 7931 2412 2988 7814 32768 0 0 0 0 8245 2268 8131 3041 8033 2190 7999 3147 7948 65536 0 0 0 0 8195 2231 2290 8097 2451 8010 2250 7977 7955 131072 0 0 0 0 2342 2210 2208 7914 8026 2409 2272 7804 2367

164

Gfarm 1.3.1 - smbsvr - atraso de 250ms para o metaserver - 4 nós iozone -Rab /geral/Q22_smbsvr_gf131_dl_250_4nodes.wks -g 128M -i0 -i1

9000 Leitura Tamanho do registro 8000 (KB) Escrita 4 7000 8 16 6000 32 64 5000 128 256 4000 512 Vazão (KB/s) Vazão 1024 3000 2048 4096 2000 8192 16384 1000

2 64 128 256 51 64 128 256 512 48 1024 2048 4096 8192 1024 20 4096 8192 16384 32768 65536131072 16384 32768 65536131072 Tamanho do arquivo (KB)

Gfarm 1.3.1 - smbsvr - atraso de 250ms para o metaserver - 4 nós iozone -Rab /geral/Q22_smbsvr_gf131_dl_250_4nodes.wks -g 128M -i0 -i1

9000 Releitura Tamanho do registro 8000 (KB)

Reescrita 4 7000 8 16 6000 32 64 5000 128 4000 256

Vazão (KB/s) Vazão 512 3000 1024 2048 2000 4096 8192 1000 16384

64 64 48 128 256 512 1024 2048 4096 8192 536 128 256 512 1024 20 4096 8192 16384 32768 65 131072 16384 32768 65536131072 Tamanho do arquivo (KB)

Figura 35 – Gráficos do benchmark da Tabela 10

165

Tabela 11 – Benchmark – Gfarm 1.3.1 – smbsvr – 4 nós – atraso de 250ms para o metaserver -com cache

Benchmark - Gfarm 1.3.1 - smbsvr - 4 nós - atraso de 250ms para o metaserver - com cache do metaserver iozone -Rab /geral/Q23_smbsvr_gf131_dl_250_4n_cache_smbsvr.wks -g 128M -i0 -i1

The top row is records sizes, the left column is file sizes MAIOR MENOR MÉDIA Writer Report 6297 521 4147 4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 64 3856 1591 1183 5541 2677 128 3868 4861 2116 2087 2204 3191 256 3962 4774 2115 3027 3221 3487 5787 512 3785 1851 5484 5740 3663 4039 6118 3672 1024 3974 4971 2244 5822 5134 1572 6297 3750 5088 2048 3984 1940 1062 5627 5638 3819 2408 5647 6251 3858 4096 521 5072 5546 2893 2712 6032 5666 3909 2441 6191 5741 8192 1331 5043 1208 5638 6121 2752 6068 3817 2779 6120 6231 3868 16384 581 5145 5505 2833 6056 2326 6283 3936 6051 2275 6149 3941 6063 32768 0 0 0 0 2160 6222 3675 5939 3712 6092 5577 2135 5846 65536 0 0 0 0 3689 2055 6090 3709 6065 5723 2125 5625 5977 131072 0 0 0 0 1838 5981 3638 5573 1886 5979 3612 5482 3587

Re-writer Report 6418 581 4268 4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 64 3827 1733 4906 1299 3178 128 3943 5062 2359 2122 2180 3418 256 4018 5234 2326 3112 3325 3799 3238 512 3863 1997 5622 3980 3942 6414 4316 2711 1024 4034 5193 2414 4803 5257 2689 5167 4269 6355 2048 4097 2028 1769 5361 5807 4173 2667 5720 6386 4308 4096 605 5227 5666 3292 2842 6089 5810 4350 2760 6390 6295 8192 1501 5173 1309 5614 6199 2882 6269 4280 2931 6133 6113 4256 16384 581 5283 5607 3081 6304 2403 6418 4360 6217 2395 6179 4306 6174 32768 0 0 0 0 2277 6080 4073 6124 4222 6105 6083 2350 5989 65536 0 0 0 0 4045 2229 6156 4101 6174 5695 2225 5861 6186 131072 0 0 0 0 1854 6109 3941 5796 1928 6089 3973 5662 3883

Reader Report 8246 573 4946 4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 64 4192 2545 6566 7273 3174 128 4215 5364 2767 7487 7513 1142 256 4129 5701 2037 7539 7834 2215 7739 512 4041 2931 6503 7405 2256 7671 7919 3412 1024 4303 5538 2654 7601 8052 1821 8136 3106 7909 2048 4298 2973 907 7431 8161 2085 1102 8033 8037 2233 4096 623 5723 6573 1784 1751 8143 8246 2201 1425 7850 7813 8192 1956 5681 1303 7579 8085 1321 7992 2327 1444 7910 7878 2487 16384 573 5703 6163 3018 8128 1221 8097 3268 7979 1754 7976 2390 7748 32768 0 0 0 0 1695 8025 2312 7904 2153 7955 7832 1599 7727 65536 0 0 0 0 2242 1639 8164 2098 8002 7956 1641 7931 7945 131072 0 0 0 0 1553 7948 2132 8098 1601 7771 2107 7906 2211

Re-reader Report 8212 553 4943 4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 64 4261 2499 6575 7306 1152 128 4154 5393 1549 7622 7902 1663 256 4264 5583 2949 7116 8078 1656 8041 512 4114 2835 6571 6933 3646 8154 7764 2658 1024 4250 5476 2608 7670 8021 1904 8075 2743 7819 2048 4334 2979 1199 7469 8125 2369 1402 8000 7918 1952 4096 589 5745 6576 1979 1372 8094 8212 2065 1597 7805 7839 8192 1970 5682 1386 7594 8018 1361 7988 2054 1412 7893 7798 3334 16384 553 5699 6307 3108 8144 1673 8116 2972 7974 1771 7935 2314 7840 32768 0 0 0 0 1697 8065 2257 8002 2128 7855 7871 1713 7849 65536 0 0 0 0 2226 1747 8163 2110 7948 7916 1637 7923 7882 131072 0 0 0 0 1492 7917 2145 8063 1690 7800 2104 7885 2195

166

Gfarm1.3.1 - leitura - smbsvr 4 nós atraso 250ms com cache iozone -Rab /geral/Q23_smbsvr_gf131_dl_250_4n_cache_smbsvr.wks -g 128M -i0 -i1

9000

8000

7000

6000 8000-9000 7000-8000 5000 6000-7000 Vazão (KB/s) 5000-6000 4000 4000-5000 3000 3000-4000 2000-3000 2000 16384 1000-2000 0-1000 1000 2048 256 0 Tamanho do registro (KB) 32 64 128 256 512 4 1024 2048 4096 8192 16384 32768 65536

Tamanho do arquivo (KB) 131072

Gfarm1.3.1 - escrita - smbsvr 4 nós delay 250ms com cache iozone -Rab /geral/Q23_smbsvr_gf131_dl_250_4n_cache_smbsvr.wks -g 128M -i0 -i1

7000

6000

5000

6000-7000 4000 5000-6000 Vazão (KB/s) 4000-5000 3000 3000-4000 2000-3000 1000-2000 2000 0-1000 16384 1000 4096 1024 256 0 64 Tamanho do registro (KB)

64 16 128 256 512

1024 4 2048 4096 8192 16384 32768 Tamanho do arquivo (KB) 65536 131072

Figura 36 – Gráficos do benchmark da Tabela 11 – Leitura e Escrita

167

Tabela 12 – Benchmark – Gfarm 1.3.1 – 4 nós – atraso de 250ms (metaserver) com cache – largura de banda de 56Kbps (dfsrv2)

Benchmark - Gfarm 1.3.1 - atraso de 250ms para o metaserver e largura de banda para dfsrv2 limitada em 56 Kbps - 4 nós - com cache no smbsvr iozone -Rab /geral/Q23_smbsvr_gf131_dl250_bw56K_dfsrv2_4n_cache_smbsvr.wks -g 128M -i0 -i1

The top row is records sizes, the left column is file sizes

MAIOR MENOR MÉDIA Writer Report 6417 52 3357 4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 64 1434 4647 1229 53 2912 128 3978 52 5080 5722 3289 53 256 3731 4998 2250 52 3280 3174 3445 512 52 4963 5295 2982 52 4275 52 6182 1024 1506 5092 5465 3012 5173 52 3859 6302 6234 2048 52 1900 5273 4783 52 6345 3895 6402 52 3674 4096 3870 5073 52 5818 3685 52 6417 3687 52 6260 3741 8192 3991 52 5448 2893 52 6031 3706 6330 52 6100 6096 52 16384 3954 1891 5454 52 6234 6321 52 6199 52 6076 3751 52 6111 32768 0 0 0 0 6247 52 3527 5961 6093 52 3530 5715 52 65536 0 0 0 0 3491 5667 5923 52 3438 5771 5856 52 3431 131072 0 0 0 0 5686 6126 52 2982 5498 52 5810 52 3342

Re-writer Report 6633 52 3513 4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 64 1631 5117 5415 53 3351 128 3991 52 5536 2087 3695 53 256 3915 5152 2396 52 3354 3284 3891 512 52 5169 5662 3309 52 4483 52 5808 1024 1583 5248 5504 3374 6633 52 4333 6450 6357 2048 52 2097 5382 6027 52 5841 4358 5804 52 4258 4096 4021 5199 52 5999 3416 52 6468 4294 52 6325 4283 8192 4076 52 5491 3281 52 6353 4275 6467 52 6303 6218 52 16384 4031 2071 5503 52 6440 6482 52 6210 52 6293 4095 52 6285 32768 0 0 0 0 5994 52 4007 6102 5993 52 4030 5915 52 65536 0 0 0 0 3930 5905 6133 52 3737 5721 6009 52 3876 131072 0 0 0 0 5781 5912 52 3275 5750 52 5714 52 3723

Reader Report 8286 52 4069 4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 64 1876 5430 5707 53 1100 128 4281 52 6409 7467 1876 53 256 4117 5526 3279 52 7848 8103 2585 512 52 5391 6472 2458 52 8143 52 8094 1024 1972 5627 6336 3466 8253 52 2378 8043 8094 2048 52 3178 6380 7684 52 8227 3283 8152 52 2803 4096 4252 5743 52 7508 2491 52 8265 2608 52 8058 2123 8192 4313 52 6441 1890 52 8254 2463 8187 52 8059 8006 52 16384 4309 3111 6476 52 8244 8237 52 8147 52 8051 2288 52 7908 32768 0 0 0 0 8285 52 2186 8146 8110 52 1845 8012 52 65536 0 0 0 0 2441 8284 8021 52 2405 8067 7847 52 2418 131072 0 0 0 0 8286 7936 52 2041 8098 52 7717 52 2247

Re-reader Report 8334 52 4099 4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 64 2076 5105 6175 52 4026 128 4197 52 6380 7573 4266 53 256 4177 5569 2232 52 7997 7988 1863 512 52 5535 6584 2403 52 8015 52 7824 1024 1977 5680 6439 2065 8334 52 3671 8064 7956 2048 52 3176 6423 7619 52 8269 2477 8229 52 2771 4096 4239 5766 52 7542 2694 52 8239 2430 52 8009 2197 8192 4352 52 6475 1988 52 8262 2454 8198 52 8084 7988 52 16384 4311 3018 6585 52 8246 8274 52 8181 52 8059 2102 52 7926 32768 0 0 0 0 8231 52 1942 8092 8130 52 2257 7999 52 65536 0 0 0 0 2330 8289 8024 52 2410 8053 7821 52 2393 131072 0 0 0 0 8283 7949 52 2074 8077 52 7748 52 2274 168

Efeito do cache nos tempos de execução de comandos (gfls, gfcp e ls) sob o Gfarm 1.3.1 com syscall-hook

Observações de execução : Comandos executados com 1,5 s de delay entre o smbsvr e o metasvr - com e sem cache Atraso de 1,5s do smbsvr p/ metasvr -> Gfarm_agent -m 2 execuções - a primeira demorou mais para formar o cache de path (caminho). O segundo já sente efeitos do cache.

comando: $ time gfls

r v as et Efeito do cache do metaserver - comando "$ time gfls" e m ) .) r v ec. ec x ex smbs e " (1ª e " (2ª -m 14,00 entr " "-m Sem cache e e ,5s h che ch 12,00 ac cache ca c 10,00 om om Com cache Atraso 1 Sem Com ca C C Tempo em 8,00 real 12,35 1,75 4,77 0,24 segundos 6,00 user 0,21 0,18 0,19 0,19 Com cache "-m" 4,00 (1ª exec.) sys 0,050,060,040,04 2,00 Com cache "-m" 0,00 (2ª exec.) real user sys comando: $ time cp gfarm:/lab/sm_clj2550.pdf gfarm:/test/ Temporização

) 1 o o 2) nt

ivo es yt moment rqu b ( (mome a e e 99 he ch de 0.0 lj2550.pdf)ac a ia _c c m 0.95 m em cach Cóp 1 (s Se S Com c Efeito do cache do metaserver - comando "$ time gfls" real 31,05 52,57 60,62 (atraso de 1,5 s) user 1,00 1,02 0,97 14,00 sys 1,381,211,42 12,00 Sem cache 10,00 Com cache 8,00

6,00 Com cache "- m" (1ª exec.)

Tempo em segundos segundos em Tempo 4,00 Com cache "- m" (2ª exec.) 2,00

0,00 real user sys Temporização

) .) ec. ec x x tasrv e Efeito do cache do metaserver - comando "$ time gfls" me (1ª e - " (atraso de 3,5 s) -m" " 3,5s "gfls e e "-m" (2ª e - h he h d c ac 35,00 o ac ca c as r em c om om At S Com cacheC C 30,00 Sem cache real 31,87 3,82 14,33 0,308 25,00 user 0,20 0,20 0,20 0,192 sys 0,07 0,05 0,05 0,044 20,00 Com cache

comando: $ time ls 15,00 10,00 Com cache "-m" "- segundos em Tempo (1ª exec.) e h che ac a 5,00 s" cache c "l m m Com cache "-m" 3,5s - m c o Atraso de metasrv - Se C Co 0,00 (2ª exec.) real 18,13 0,61 0,62 real user sys user 0,20 0,21 0,21 Temporização sys 0,060,060,06

Efeito do cache do metaserver - comando "$ time cp" Efeito do cache do metaserver - comando "$ time ls" (atraso de 3,5 s) (atraso de 3,5 s)

20,00 70,00 18,00 Sem cache 60,00 16,00 Sem cache 14,00 50,00 (momento 1) Com cache 12,00 40,00 Sem cache 10,00 30,00 (momento 2) 8,00 Com cache "-m" 20,00 Com cache 6,00 Tempo em segundos em Tempo 10,00 segundos em Tempo 4,00 0,00 2,00 real 0,00 user sys real user Temporização sys Temporização

Figura 37 - Efeito do cache nos tempos de execução de comandos (gfls, gfcp e ls) sob o Gfarm 1.3.1 com syscall-hook 169

Tabela 13 – Benchmark – NFS – cliente dfsrv4

Benchmark - NFS - cliente dfsrv4 - mount /home/lab - export /home/lab em smbsvr iozone -Rab /root/Q11nfs_dfsrv4_centos_loc.wks -g 256M -i0 -i1

The top row is records sizes, the left column is file sizes

MAIOR MENOR MÉDIA Writer Report 305478 5127 138548 Escrita 4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 64 236995 278262 293571 283280 301969 128 250495 303984 305478 304699 302671 236118 256 229605 260722 248521 255773 232502 198289 157840 512 184978 198369 189067 193137 177715 164579 159548 132569 1024 166369 172625 175613 163084 156217 148382 144103 144941 129733 2048 157394 164444 163408 156634 146295 140246 136798 138950 138414 132163 4096 152086 158895 158654 150853 140187 136338 135646 135836 135682 135786 132965 8192 151375 155572 155478 145754 138280 131011 133957 134341 134745 133884 134372 132498 16384 149946 153785 151762 145316 137080 133498 132873 132996 133938 133660 133603 132507 131433 32768 0 0 0 0 122675 120513 119929 120287 121051 120897 121383 120701 120596 65536 0 0 0 0 114303 111269 110929 111485 112061 112473 112413 112542 112569 131072 0 0 0 0 5540 5907 5532 5907 5882 5608 5679 5729 5444 262144 0 0 0 0 5276 5225 5176 5322 5502 5127 5291 5458 5324

Re-writer Report 399971 5148 151132 Reescrita 4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 64 361454 372030 383488 399971 387628 128 317611 317585 350690 362575 327434 251487 256 252242 270614 277063 263125 243122 214210 188367 512 203174 205213 208379 202130 187816 173847 168589 163789 1024 177872 183214 182143 172710 162461 154284 151704 151233 152110 2048 167800 171797 170596 161934 152164 145940 144378 145393 145702 144848 4096 162488 166437 165535 154356 146239 142099 141784 142099 142459 141715 142272 8192 159934 162995 162859 155013 144144 140117 139943 140288 140993 140642 137741 140550 16384 157061 161759 161523 153950 143398 139585 139183 139280 139891 139744 140052 139991 140520 32768 0 0 0 0 127947 124584 125657 125820 125414 126530 126340 126048 126471 65536 0 0 0 0 118421 115797 115332 115191 115861 116586 115921 117024 116404 131072 0 0 0 0 5870 6187 5265 5881 5774 5908 5944 5488 5762 262144 0 0 0 0 5617 5419 5349 5205 5693 5148 5450 5324 5269

Reader Report 418536 5421 255735 Leitura 4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 64 359558 392471 399725 418323 410441 128 335929 361557 373296 355653 385525 324878 256 331564 349252 384989 376513 374261 300096 231055 512 345481 372634 386987 404716 395701 304055 209411 184575 1024 353215 375512 395994 405873 379553 278343 204470 173179 168341 2048 359617 378690 398990 413399 381739 280239 201414 169142 161412 159427 4096 361770 381451 405543 414240 391999 278281 200439 165555 157526 155481 156503 8192 362685 383806 406167 417787 394414 280480 198840 164144 155434 154653 154960 154173 16384 363006 383260 406763 418536 391503 278265 198423 160592 152314 153233 153716 153566 154025 32768 0 0 0 0 404437 285281 198631 162973 154023 151013 152303 152356 152694 65536 0 0 0 0 410148 290599 199934 163309 154462 153577 153970 153840 154270 131072 0 0 0 0 412835 295029 201394 165257 155819 155214 155131 155274 155420 262144 0 0 0 0 5712 5733 5744 5727 5421 5733 5676 5728 5547

Re-reader Report 621487 5337 271671 Releitura 4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 64 621487 597582 561327 597866 598273 128 518006 490238 477466 430974 458907 344134 256 374325 385526 400664 431682 425264 304022 222230 512 363396 385804 399397 417953 403441 302790 129067 183520 1024 365455 386429 408148 418809 385987 277423 202972 173470 168368 2048 365066 373789 408537 419509 383375 279131 200430 164077 161298 159763 4096 366698 386484 408499 418814 393048 278225 199951 165281 157484 155912 156473 8192 366222 386306 408353 419737 397150 281444 199275 164432 155708 154609 154928 154524 16384 366171 386050 410030 419811 394338 277619 198435 162811 154259 152931 153513 153593 154270 32768 0 0 0 0 404593 284998 199058 161654 152912 153231 153334 153315 152701 65536 0 0 0 0 406223 292178 198695 163329 153971 153425 152963 153750 153160 131072 0 0 0 0 413534 295163 201440 165128 155727 154628 155117 154995 154810 262144 0 0 0 0 5788 5782 5810 5736 5337 5662 5555 5602 5463

170

Tabela 14 – Benchmark – cliente Windows com acesso a compartilhamento nativo SAMBA

Benchmark - estação Windows XP Pro SP2 - SAMBA em smbsvr

/cygdrive/c/arquiv~1/benchm~1/iozone3.263/iozone -QRab d:\teste\Q37_samba_lab.xls -g 128M -i0 -i1

The top row is records sizes, the left column is file sizes

MAIOR MENOR MÉDIA Writer Report 100124 830 17871 4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 64 7713 17446 3961 23105 23224 128 10402 13633 32830 39638 36346 40393 256 3739 7338 43406 28290 53205 61670 67984 512 11766 22196 36933 44696 75795 84895 50693 2060 1024 12660 22907 35894 58670 64387 100124 73193 2057 1385 2048 2719 3622 11979 21790 35632 53136 82546 1947 1329 1179 4096 1014 3636 8866 16247 28726 47640 73872 1925 1300 1141 1101 8192 1151 1632 3638 14666 22561 42849 68240 1611 1239 1124 1075 1071 16384 830 912 1048 2176 2578 41858 65992 1256 1153 1086 1060 1055 1055 32768 0 0 0 0 1619 1993 2092 1099 1099 1058 1044 1048 1047 65536 0 0 0 0 1049 1087 1110 1105 1074 1053 1045 1044 1044 131072 0 0 0 0 1072 1055 1066 1057 1056 1045 1042 1040 1040

Re-writer Report 154192 1048 33191 4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 64 3704 38373 4942 85227 105620 128 12778 16853 7311 95574 120828 135637 256 10541 24401 15364 16235 119085 116719 154192 512 12907 24023 42732 52942 117279 131237 65625 2110 1024 12489 20503 42144 66985 74610 35435 86881 2091 1400 2048 12205 19546 35209 58651 80003 91017 132878 2058 1339 1195 4096 5209 23560 40569 59931 86355 107675 134081 1970 1317 1162 1122 8192 12734 23387 40115 64451 85275 100587 126214 1651 1245 1141 1085 1085 16384 1829 4989 5191 62865 86143 29888 123654 1329 1165 1105 1074 1068 1066 32768 0 0 0 0 2140 2154 2165 1121 1116 1070 1060 1060 1059 65536 0 0 0 0 1106 1110 1291 1107 1089 1062 1057 1055 1053 131072 0 0 0 0 1071 1073 1073 1068 1062 1054 1048 1048 1048

Reader Report 1040 711 955 4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 64 889 992 945 1005 1040 128 906 960 963 881 1007 974 256 711 911 995 873 925 947 923 512 903 954 983 929 965 948 921 965 1024 917 932 940 975 959 973 952 966 965 2048 937 941 965 985 975 974 980 968 977 954 4096 931 958 963 960 976 981 978 971 952 951 955 8192 937 954 960 970 974 983 979 978 976 958 956 957 16384 936 952 961 980 979 979 970 977 975 976 957 957 957 32768 0 0 0 0 976 978 974 970 947 976 977 955 953 65536 0 0 0 0 980 978 982 978 976 975 976 977 958 131072 0 0 0 0 925 928 911 909 927 927 928 929 930

Re-reader Report 194062 919 100388 4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 64 26850 47371 3956 110671 123565 128 2520 6353 72109 122968 163519 178211 256 9516 12655 87673 13580 163694 184564 168294 512 13695 24250 41743 55166 194062 185573 60194 165155 1024 14444 27872 50951 39303 104823 181926 96586 165895 165670 2048 14423 24685 51404 74351 136219 127259 169004 155953 153620 117924 4096 14389 27675 51509 82114 135950 134784 168022 132795 157253 155319 156517 8192 14275 27558 49778 89795 137731 135944 153451 151981 138563 154851 153961 157559 16384 14292 27503 50326 88232 138390 139726 145713 142395 153889 147861 149814 156176 156568 32768 0 0 0 0 135691 144210 146409 140437 121992 148481 153644 155637 151889 65536 0 0 0 0 136441 145547 148603 146788 146378 150508 152664 152054 152914 131072 0 0 0 0 931 932 919 1014 925 928 929 930 1265

171

Tabela 15 – Benchmark – cliente Windows - acesso ao Gfarm via SAMBA com syscall-hook

Benchmark - Gfarm 1.3.1 - estação brio-arpa = dfsrv4 - via SAMBA (smbsvr) iozone -QRab d:\teste\Q36_gfarm131_via_samba.xls -g 128M -i0 -i1

The top row is records sizes, the left column is file sizes

MAIOR MENOR MÉDIA Writer Report 1065 76 719 4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 64 96 115 76 149 144 128 122 165 226 239 259 261 256 212 278 382 392 382 382 427 512 318 335 410 540 572 539 544 616 1024 402 393 475 647 563 669 671 779 789 2048 313 418 666 723 694 732 779 893 804 801 4096 457 604 715 786 837 867 883 953 947 959 973 8192 470 622 741 825 838 904 967 988 996 1011 1022 1002 16384 476 637 742 837 846 879 886 1016 1027 1044 1035 1020 1036 32768 0 0 0 0 897 949 995 1021 1034 1050 1054 1052 1043 65536 0 0 0 0 892 964 1001 1040 911 932 934 1065 1049 131072 0 0 0 0 791 857 1009 904 1039 933 1050 929 1055

Re-writer Report 1057 76 733 4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 64 94 106 76 147 694 128 109 177 267 243 264 318 256 227 287 377 433 429 392 497 512 365 361 362 510 608 545 537 683 1024 402 399 486 660 675 672 685 776 760 2048 315 419 672 734 709 756 874 898 821 822 4096 451 611 721 795 831 877 919 936 949 908 983 8192 467 615 747 829 855 902 945 991 997 982 1023 1004 16384 481 637 742 837 876 842 974 957 1027 1045 1040 1046 1057 32768 0 0 0 0 893 958 999 1032 1048 1041 1047 1043 1052 65536 0 0 0 0 893 968 1013 1052 938 947 958 1047 1052 131072 0 0 0 0 802 877 1005 924 1037 950 1054 938 1057

Reader Report 888 137 779 4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 64 564 718 137 874 734 128 459 645 627 522 854 840 256 402 531 821 773 713 759 816 512 564 549 615 832 815 710 721 845 1024 586 599 667 814 814 717 739 868 837 2048 451 603 811 860 730 759 867 854 742 756 4096 607 748 811 860 857 870 875 874 865 868 862 8192 608 743 804 854 858 868 880 863 877 878 882 882 16384 604 747 803 861 862 866 871 883 888 885 883 885 885 32768 0 0 0 0 861 863 875 874 875 883 883 883 872 65536 0 0 0 0 848 860 866 878 778 762 763 879 870 131072 0 0 0 0 734 738 868 749 865 750 871 767 874

Re-reader Report 889 161 786 4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 64 535 659 161 884 732 128 486 592 642 759 818 865 256 453 570 747 812 709 729 824 512 628 608 669 777 862 722 703 852 1024 624 613 673 854 851 733 756 852 871 2048 455 607 808 866 737 767 879 875 761 772 4096 621 760 786 853 860 877 880 875 879 883 884 8192 621 754 795 860 864 860 880 880 879 883 885 889 16384 623 743 811 859 852 876 878 880 887 889 888 876 887 32768 0 0 0 0 851 870 876 868 869 872 870 870 877 65536 0 0 0 0 852 865 867 877 781 763 768 880 876 131072 0 0 0 0 732 742 867 753 874 751 875 768 878

172

Tabela 16 - Benchmark – cliente Windows - acesso direto ao SAMBA

Benchmark - estação Windows XP Pro SP2 - SAMBA em smbsvr

/cygdrive/c/arquiv~1/benchm~1/iozone3.263/iozone -QRab d:\teste\Q37_samba_lab.xls -g 128M -i0 -i1

The top row is records sizes, the left column is file sizes

173

Tabela 17 - Benchmark concorrente Gfarm 1.3.1 – 4 nós e cache em 3 nós - clientes gfwks e smbsvr

Benchmark concorrente Gfarm 1.3.1 com cache em 3 nós - clientes gfwks e smbsvr iozone -Rab /tmp/Q30_gf131_gfwks_smbsvr_cache3n.wks -g 128M -i 0 -i1

The top row is records sizes, the left column is file sizes

MAIOR MENOR MÉDIA Writer Report 8193 846 5657 Escrita 4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 64 1561 2150 7294 7525 1928 128 1505 6640 7242 846 3589 7761 256 5515 1967 2497 7693 8090 3354 3607 512 5533 6440 2310 3250 7712 8090 3481 3113 1024 5443 6821 1462 3341 8050 7583 3782 2126 6873 2048 5572 1329 2565 7605 6992 3174 3449 6747 7132 3754 4096 1657 6673 7136 2398 4113 7055 7104 2978 4125 6897 7043 8192 1456 2002 7133 7986 3754 3150 8106 7947 3882 2604 8138 8191 16384 1463 1492 6985 7956 3046 3976 8133 8193 2677 4038 7597 8190 3856 32768 0 0 0 0 3663 8020 8040 7478 8170 8125 7919 7940 8119 65536 0 0 0 0 7788 8079 8104 8088 7536 8074 7904 7716 8025 131072 0 0 0 0 8032 7995 6101 7968 7983 6580 7981 7989 7959

Re-writer Report 8600 1403 6025 Reescrita 4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 64 1595 2447 7506 8191 3031 128 1642 6792 7257 2946 4457 7334 256 3816 2153 2769 7726 8600 4215 4445 512 5653 4755 2497 3756 8288 8508 4233 3952 1024 5520 7067 1403 3766 8447 7605 4400 3945 6714 2048 5759 1844 2799 7764 7131 3782 4301 7305 7250 4358 4096 1843 6827 7289 3186 4808 7249 7139 3805 4704 7101 7298 8192 1541 2285 7324 8257 4207 4510 8410 8125 4310 3656 8377 8519 16384 1538 1759 7412 8257 3627 4597 8393 8533 2813 4543 7688 8469 3948 32768 0 0 0 0 4107 8365 8494 8492 8468 8427 8370 8410 8440 65536 0 0 0 0 7851 8464 8431 8418 7208 8430 8442 8458 8263 131072 0 0 0 0 8247 8089 8171 8166 7716 8188 8181 8170 8162

Reader Report 8849 869 5585 Leitura 4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 64 2086 3370 8046 8491 1146 128 2043 7533 7896 1696 4356 7954 256 5809 2468 3753 7295 8631 1940 1887 512 6192 7278 2662 3151 7974 7290 3045 3128 1024 6239 7722 1353 4221 7334 7580 2681 1689 8042 2048 6381 2536 2534 7681 7469 1628 3814 7156 7208 2818 4096 869 7572 7060 2665 1989 7060 7504 1318 3663 7195 7699 8192 1592 3371 7288 7366 2894 3974 7314 7304 2742 2776 7388 7544 16384 1968 2097 7303 7371 1820 4255 7238 7573 1259 3920 6251 7598 915 32768 0 0 0 0 2478 7075 7276 7433 7420 7370 7336 7349 7450 65536 0 0 0 0 7439 7559 7690 7311 5752 7662 7595 7457 8849 131072 0 0 0 0 8803 7324 8724 8694 7575 8664 8681 8630 8668

Re-reader Report 8995 1134 5671 Releitura 4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 64 2028 3554 7584 7665 2634 128 1929 7652 8038 1327 4517 5477 256 5614 2575 3722 7604 7672 2629 4285 512 6144 7058 2614 4650 7302 7428 2444 3716 1024 6269 7755 1617 4213 6985 7973 3141 3094 7396 2048 6397 2478 1499 7524 7421 1796 3981 7422 7425 2945 4096 1565 7567 7754 2968 2018 7223 7496 2892 4145 7563 7274 8192 1134 3461 7130 7520 2857 4024 7315 7320 2883 2601 7317 7534 16384 1980 3080 7184 7416 2905 3366 7245 7521 1258 4129 7128 7454 1455 32768 0 0 0 0 2116 8454 7162 7393 7399 7393 7369 7381 7308 65536 0 0 0 0 7492 7508 7764 7275 7747 7704 7772 7613 8995 131072 0 0 0 0 8843 6910 8711 8720 6004 8619 8657 8666 8668

174

Gfarm 1.3.1 - gfwks & smbsvr - cache operando em 3 nós iozone -Rab /tmp/Q30_gf131_gfwks_smbsvr_cache3n.wks -g 128M -i 0 -i1

Tamanho 10000 do registro Escrita Leitura KB 9000 4 8000 8 7000 16 32 6000 64 128 5000 256 512

Vazão (KB/s) 4000 1024 3000 2048 4096 2000 8192 1000 16384

64 128 256 512 64 128 256 512 1024 2048 4096 8192 1024 2048 4096 8192 1072 16384 32768 65536131072 16384 32768 6553613 Tamanho do arquivo (KB)

Gfarm 1.3.1 - gfwks & smbsvr - cache operando em 3 nós iozone -Rab /tmp/Q30_gf131_gfwks_smbsvr_cache3n.wks -g 128M -i 0 -i1 Tamanho do registro KB

10000 4 Reescrita Releitura 9000 8

8000 16 32 7000 64 6000 128 5000 256

Vazão (KB/s) 4000 512

3000 1024

2000 2048

1000 4096 8192 0 16384 4 2 64 128 256 512 64 128 256 51 1024 2048 4096 8192 768 1024 2048 4096 8192 1638 32 65536131072 16384 32768 65536131072 Tamanho do arquivo (KB)

Figura 38 – Gráficos do benchmark da Tabela 17 175

Figura 39 – Gráficos MRTG – Durante benchmarks Gfarm 1.3.1 / primeiras rodadas – (1/3) 176

Figura 40 - Gráficos MRTG – Durante benchmarks Gfarm 1.3.1 / primeiras rodadas – (2/3)

177

Figura 41 - Gráficos MRTG – Durante benchmarks Gfarm 1.3.1 / primeiras rodadas – (3/3) 178

Figura 42 - Gráficos MRTG – Durante benchmarks Gfarm 1.3.1 / smbsvr com cache em 3 nós (1/3)

179

Figura 43 - Gráficos MRTG – Durante benchmarks Gfarm 1.3.1 / smbsvr com cache em 3 nós (2/3)

180

Figura 44 - Gráficos MRTG – Durante benchmarks Gfarm 1.3.1 / smbsvr com cache em 3 nós (3/3)

181

Figura 45 – Cópia de tela – acesso ao Gfarm com o browser Firefox

Figura 46 – Cópia de tela - acesso ao Gfarm via SAMBA por cliente Windows

182

Figura 47 – Cópia de tela – acesso ao Gfarm via SAMBA por clientes Windows – diretórios e arquivos

183

ANEXO C – INFORMAÇÕES SOBRE AS VERSÕES DO GFARM

184

13 INFORMAÇÕES SOBRE AS VERSÕES DO GFARM

Trata-se da lista de versões do Gfarm, traduzida do inglês a partir de Gfarm (2007). Neste trabalho, as pesquisas iniciaram-se com o Gfarm versão 1.1.1, utilizando posteriormente as versões 1.2-5 (1.2 PL4) e terminando com a 1.3.1. O Gfarm passou para a versão 1.4 após a finalização deste trabalho e continua em desenvolvimento. As alterações sofridas estão descritas em ordem decrescente a partir da versão 1.4, de 13/11/2006.

13.1 Versão 1.4 de 13/11/2006

13.1.1 Características atualizadas gfrm(1); suporta a remoção paralela de arquivos para acelerar as operações se o “gfrm” é compilado no compilador OpenMP C. adiciona as opções “-j <#thread>”, “-D”, “-H” , “-N <#replica>”, “-n”, “-q” e “-v”. A opção “-j” só está disponível se o “gfrm” é compilado no compilador OpenMP C. gfwhere(1) - adiciona as opções “-r” e “-R” para listagem recursiva;

config-gfarm – suporte ao CentOS;

gfsplck(1); Adiciona uma funcionalidade para liberar o estado (status) de texto- ocupado (text-busy). Um arquivo que foi aberto por programas de aplicação interrompidos por erro retém o estado de texto-ocupado. (Bugzilla-ja #60). gfimport_text(1) - adiciona a opção “-N <#host>”;

gfarm_agent(1); Suprime não importantes e excessivas saídas de log para melhorar o desempenho; Adiciona opção “-L” para especificar um nível de syslog. gfarm.conf(5); Adiciona diretiva "level log_level"; Adiciona diretiva "record_atime disable". gfmd(8) and gfsd(8) – adiciona opção “-L” ;

libgfarm; Melhoria no algoritmo de escalonamento: Quando um “gfsd” pára durante a leitura de um arquivo, tenta automaticamente outra réplica do arquivo;

Quando é observado um erro de ao “gfsd”, remove a entrada de host de um cache de escalonamento; 185

Ao abrir um arquivo com o sinalizador (flag) O_TRUNK, escalona um nó do sistema de arquivos independente da localização original; Não ignora SIGPIPE para aplicações que não verificam o valor de retorno em write(2). (Bugzilla-ja #68); Adiciona maior verificação contra transbordo de inteiros (integer overflow). Documentação; Melhora todos os documentos: adiciona explanações mais exatas e detalhadas. Reparo de bug. gfls(1) – repara um bug no qual um nome de caminho mais longo que a largura da tela causa um erro; gfreg(1) – repara um bug no modo recursivo, no qual um nome de diretório não pode ser mudado; config-gfarm(1); Resolve um problema no qual o postmaster falha na inicialização em alguns casos. gfmd(8) – adiciona descrição sobre a opção “-d” na tela de informações sobre o uso. (Bugzilla-ja #62); gfsd(8) – repara um bug no qual “errno” não é preservado pelo manipulador (handler) SIGCHLD; libgfarm; Repara um bug tal que “gfs_client_terminate()” não remove as entradas de conexão de um cache de conexão. Isso pode causar despejo de memória em algumas seqüências de chamadas;

Repara um bug no qual um arquivo não pode ser removido se ele não contém informações sobre os fragmentos;

Repara um bug sério no escalonamento, o qual pode causar travamento na libgfarm. (Bugzilla-ja #66);

Repara um problema de dependência de pacote em “gfarm.spec”.

13.2 Versão 1.3.1 de 07/08/2006

13.2.1 Novas características

gfchmod(1) – comando “chmod” para o Gfarm;

gfusage(1) - mostra a utilização de espaço em disco total de cada usuário;

Documentação.

“KNOWN_PROBLEMS” – descreve problemas conhecidos do Gfarm 1.3.1.

186

13.2.2 Características atualizadas

libgfarm; Melhora a funcionalidade do cache de conexão, para o gfsd tolerar sua própria reinicialização, a fim de não exaurir os descritores de arquivos. Agora, o número de conexões em cache é gerenciada pela diretiva “gfsd_connection_cache” no “gfarm.conf”. Caso não seja especificada, o padrão é 16; Adicionadas definições de “gfarm_error_t” e “GFARM_ERR_NO_ERROR”, além da função “gfarm_error_string”(3); Reporta um erro no fechamento de uma conexão; Planeja uma contramedida contra ataques integer overflow mediante o uso de “malloc()” e “realloc()” de uma forma segura.

gfarm_agent(1); Adicionada opção "-m" para o modo master no caso de existir apenas um servidor de cache de metadados gfarm_agent em execução. Isso melhora o desempenho do acesso aos metadados devido ao uso do cache também para manter informações de caminho (path).

config-gfarm(1); Adicionada opção "-a " para especificar o tipo de autenticação; Suporta o PostgreSQL 7.4 como um servidor de metadados; Mostra o uso com a opção “--help”; Estabelece a opção keepalive como padrão para fazer frente a ambientes de rede pobres.

config-gfsd(1); O parâmetro “spool-directory” passa a ser opcional; Adiciona opção "-l" que especifica um endereço de escuta; Mostra o uso com a opção "--help".

config-agent(1); Mostra o uso com a opção "--help".

gfsd(8); Adiciona opção "-l" que especifica um endereço de escuta; Suporta o modo “read-only” experimentalmente, o qual é habilitado mediante a criação por administradores do arquivo “.readonly", no topo do diretório de spool.

Documentation; Descreve em README.hook, um problema referente ao proprietário de um arquivo ou diretório.

Reparo de bug. Repara um grande bug de escalonamento tal que o disco local não tem prioridade para ser escalonado, introduzido na versão 1.3; Repara um problema de portabilidade para x86_64; 187

Repara um bug referente à reconexão ao “gfarm_agent”; gfsd(8) – repara o cálculo de espaço em disco no FFS nos BSDs29; Repara um bug do mkdir(1) via ganchos de chamada de sistema no Solaris 9.

13.2.3 Características não suportadas

NetBSD 1.6.2 não é mais suportado.

13.3 Versão 1.3 de 12/06/2006

13.3.1 Nota sobre compatibilidade

“libgfarm” usa novos protocolos para o gfsd. Se a biblioteca de cliente é atualizada para a versão 1.3, o gfsd tem que ser atualizado para a versão 1.3 e reinicializado.

13.3.2 Novas características

Suporte à biblioteca syscall hooking no Solaris 9 and 10;

Suporte parcial ao AIX 5.2. O AIX 5.2 é suportado agora, exceto a biblioteca syscall hooking “libgfs_hook.so”. Torna-se necessário especificar “--without- gfshook” na fase configure;

gfarm_agent(1) – um servidor de cache de metadados abrangendo todo o cluster. Ele tem nova funcionalidade para compartilhar o cache de metadados entre múltiplos nós classe PC;

config-agent(1) – novo script de configuração para configurar e estabelecer o servidor de cache de metadados “gfarm_agent”. Para detalhes, vide documento “INSTALL.RPM”;

gfdump(1) – nova ferramenta de dump (salvamento) e restore (restauração) de metadados;

$ “gfdump -d -f arquivodump” para salvamento dos metadados $ “gfdump -r -f arquivodump” para restaurar os metadados

Nota: ressalta-se que as informações de host são salvas pelo “gfhost” e não pelo gfdump”

gfs_statfsnode(3) and gfs_statfsnode_cached(3) - novas funções para adquirir espaço livre em disco;

29 NetBSD 1.6.2 não é mais suportado 188

Variável de ambiente; A variável GFARM_WRITE_TARGET_DOMAIN especifica o nome de domínio que tem prioridade na criação de novos arquivos; GFARM_WRITE_LOCAL_PRIORITY altera a política onde um novo arquivo é criado num nó do sistema de arquivos. Como padrão, o armazenamento local é sempre selecionado se há espaço em disco disponível. Por outro lado, se “0” ou “disable” é configurado na variável de ambiente, o armazenamento local não é sempre selecionado, visando um melhor balanceamento de carga e controle de capacidade de disco.

gfarm.conf - arquivo de configuração do Gfarm; A diretiva “minimum_free_disk_space” especifica o espaço livre mínimo em disco para o escalonamento do nó do sistema de arquivo. Qualquer nó do sistema de arquivo com menos espaço livre que o especificado, tem menor prioridade na seleção. O tamanho padrão é 128 MB; A diretiva “write_local_priority” altera a política onde um novo arquivo é criado num nó do sistema de arquivos. Vide a descrição da variável de ambiente GFARM_WRITE_LOCAL_PRIORITY acima; As diretivas “agent_serverhost” e “agent_serverport” especificam um servidor de cache de metadados “gfarm_agent”; Diversas diretivas para o gerencimento de cache.

13.3.3 Características atualizadas

gfreg(1) – as opções “-H” and “-D” podem ser especificadas em todos os modos;

configure – adicionada a opção “--without-gfshook” para desabilitar a construção da biblioteca syscall-hook;

gfsd(8) – suporte a múltiplos diretórios de spool, mediante a execução de múltiplos gfsds com um endereço IP virtual diferente, no mesmo servidor. Adicionada verificação de sanidade para detectar erros de entrada/saída;

“libgfarm” – adicionado controle de acesso para “gfs_chdir”, “gfs_opendir”, “gfs_unlink”, “gfs_unlink_section”, “gfs_unlink_section_replica”, e “gfs_rename”;

gfs_fstat(3) – retorna o tamanho do arquivo corrente no modo de seção;

Melhora de desempenho; Config-gfarm(1) – usa funcionalidade autovacuum para retaguarda PostgreSQL, se suportado; Não recalcula checksum no momento de fechamento em nenhum caso; Implementa novo algorítmo de escalonamento, o qual usa RTT (Round Trip Time) e espaço livre em disco para tornar possível selecionar replicas de arquivos próximas dos nós do sistema de arquivos e evitar disco cheio; Reduz consumo de memória quando usando o PostgreSQL como retaguarda.

189

Melhoria de robustez; Tenta se reconectar quando a conexão a um servidor “gfarm_agent” é quebrada devido à reinicialização (rebooting) ou alguma outra razão; Estabelece timeout de 5 segundos em “connect()” para evitar resposta lenta em redes instáveis com perdas.

Reparo de bug; gfs_pio_create(3) e gfs_mkdir(3) podem criar um arquivo ou diretório com modo inválido; gfls(1) – repara um problema de falha de segmentação; “ctime” não é atualizado; “libgfarm” (metadb_pgsql.c) – repara vazamento de memória; gfs_chmod(3) – repara um bug de “chmod +x” na retaguarda OpenLDAP; gfs_unlink(3) – repara um bug tal que a informação de caminho (path) nos metadados permanece quando desvinculando um arquivo binário que não tem o arquivo físico correspondente; config-gfarm(1) – tornado robusto para a instalação do PostgreSQL; Repara um bug tal que '.' e '..' podem ser registrados incorretamente nos metadados; Tampa vazamento de memória; Repara uma falha de segmentação quando recolocando em cache o cache de diretório gerenciado por uma estrutura red-black tree (árvore vermelho- preto).

13.4 Versão 1.2.9 de 20/01/2006

13.4.1 Novas características

Suporte ao PostgreSQL como servidor de banco de dados de metadados na retaguarda.

13.4.2 Características atualizadas

config-gfarm(1) – Suporte ao PostgreSQL. Usa autenticação por senha para retaguardas PostgreSQL e OpenLDAP como padrão;

gfrep(1) – adicionada opção “-m” para migração de réplica, e “-v” para mensagens detalhadas;

gfps(1) – adicionada a opção “-v” para mostrar erros da autenticação GSI;

gfs_unlink(3) – não retorna erro quando pelo menos uma réplica de arquivo é desvinculada com sucesso;

libgfarm – biblioteca Gfarm; Não mantém uma credencial proxy GSI desde que ela pode estar expirada; 190

Faz com que a diretiva “netparam” no “gfarm.conf” seja efetiva na replicação on-demand (por demanda); Suporte a tolerância a falhas na replicação de arquivos.

Melhoria de desempenho; O cache de diretório é gerenciado por uma árvore red-black ao invés de hash para melhorar o desempenho em diretórios com grande número de arquivos; Adicionados cache de informação de host information e cache de informação de path para reduzir overhead de acesso aos metadados.

Reparo de bug; “gfreg -f” não funciona. (Bugzilla #16); gfsplck(1) – arquivos sem informação de fragmento não podem ser reparados; Metadados inválidos são criados quando falha a criação do arquivo físico correspondente. (Bugzilla-ja #47); “gfrep -N” cria um número de réplicas maior que o especificado. (Bugzilla-ja #44); gfrep(1) – na replicação, um host indisponível pode ser selecionado como origem; gfs_chmod(3) – reparo de bug quando mudando bits de execução.

Documentação. Gfarm-FAQ – adicionada seção 2.7: Erro "Operation not permitted" acontece quando acessando ou criando um arquivo com bits de execução; README.hook – atualização da seção sobre Solaris.

13.5 Versão 1.2 PL4 de 28/09/2005

13.5.1 Características atualizadas

config-gfarm(1) and config-gfsd(1) – gera scripts de inicialização para o SuSE e outras distribuições Linux;

Variável de ambiente GFARM_SYSLOG_OUTPUT pode especificar um recurso de syslog. Isso é aplicado também para mensagem de debug gerada pela biblioteca “libgfs_hook_debug.so”.

191

13.6 Versão 1.2 PL3 de 12/09/2005

13.6.1 Características atualizadas

config-gfarm(1) and config-gfsd(1) são agora suportados em todas as plataformas;

Reparo de bug. Impossibilidade de criar qualquer arquivo ou diretório num sistema de arquivos Gfarm vazio.

13.7 Versão 1.2 PL2 de 08/09/2005

13.7.1 Características atualizadas

gfrep(1) – adicionada a opção -S para especificar o “nomededomínio” origem;

Reparo de bug. Ao abrir um arquivo em modo de escrita durante ocupação de arquivo texto, ele será truncado. Esse bug foi introduzido na versão 1.2 RC2; Biblioteca syscall hooking – repara um tradução de arquivo para “/gfarm/.nomedoarquivo” e “~nomedoarquivo “ no sistema de arquivos Gfarm.

13.8 Versão 1.2 PL1 de 06/09/2005

13.8.1 Características atualizadas

config-gfarm – especifica “cachesize” automaticamente quando usando Berkeley DB;

Documentação; README.hook – A estrutura foi simplificada e reorganizada Adiocionadas questões de possível falha de segmentação por colisão da biblioteca “libgssapi”; “gfarm_url_section_replicate_{,from_}to(3)” e “gfarm_url_fragments_replicate(3)” – adicionadas.

Reparo de bug; frun(1) pode falhar quando uma tarefa é submetida por um cliente não registrado via “gfarm_agent”; gfexec(1) – repara referência a variável não inicializada.

192

13.9 Versão1.2 RC2 de 31/08/2005

13.9.1 Características atualizadas

Suporte a UTF-8;

Suporte ao FreeBSD and NetBSD;

Suporte a file locking (travamento de arquivo) contra replicação durante atualização de arquivo, o qual previne a criação de réplicas de arquivos inconsistentes;

Um arquivo recém criado pode ser acessado por outros processos antes de ser fechado;

Quando copiando, movendo e removendo arquivos executáveis, somente a seção que define a arquitetura de destino dos arquivos executáveis é modificada. Isso significa que binários executáveis podem ser instalados e removidos em diferentes arquiteturas independentemente ou separadamente;

gfarm.conf(5) – adicionada diretiva “client_architecture” para especificar a arquitetura do cliente;

Variável de ambiente; GFARM_CONFIG_FILE pode especificar um arquivo de configuração Gfarm ao invés de “~/.gfarmrc”. (Bugzilla-ja #38); GFARM_ARCHITECTURE pode especificar a arquitetura de um cliente.

configure – respeita a opção “--sysconfdir” para especificar um diretório de “gfarm.conf”;

gfsd(8), gfmd(8) – aceita proxy limitado nível N para habilitar o acesso ao sistema de arquivos Gfarm de um processo invocado pelo jobmanager (gerenciador de tarefas) do Globus;

gfrm(1) – suporta remoção recursiva de replicas de arquivos de uma seção particular de um arquivo;

gfkey(1) – adicionada a opção “-p” para especificar o termo de validade em segundos;

gfs_unlink_section(3) – nova função para desvincular uma seção particular de um arquivo;

gfs_pio_sync(3), gfs_pio_datasync(3) – novas funções;

gfs_seekdir(3), gfs_telldir(3) - novas funções;

193

Biblioteca syscall-hook;

Novos pontos de entrada para syscall hook; fsync, fdatasync, pread, pread64, pwrite, e pwrite64; “lseek(2)” hook - suporta uma operação de busca para um diretório. (Bugzilla-ja #36, #37); “stat(2)” hook - preenche “st_blocks” na estrutura “stat”, o qual faz funcionar o comando "du".

Melhoria de robustez;

gfarm_agent(1) – a funcionalidade é melhorada para aceitar todas as requisições de metadados. Ao usar o “gfarm_agent”, programas clientes não se conectam a um servidor LDAP, o que reduz o número de conexões ao servidor LDAP e a sua carga de CPU; libgfarm(3) – tenta reconexão quando a conexão a um servidor LDAP é quebrada devido à reinicialização ou alguma outra razão.

Documentação; “samba-hook”, “samba-gfarmfs” – descreve como exportar um sistema de arquivos Gfarm para clientes Windows via Samba; “nfs-gfarmfs” – descreve como exportar um sistema de arquivos Gfarm no NFS; “export-gfarm” – sumariza o status (situação presente) para exportar um sistema de arquivos Gfarm em vários protocolos como FTP, HTTP, CIFS, e NFS.

Reparo de bug; Reparo de falha de segmentação ou mensagem de erro inapropriada quando as bibliotecas de I/O do Gfarm são chamadas, antes de chamar “gfarm_initialize”. (Bugzilla-ja #32); Reparo de uma condição de disputa quando múltiplos processos reparam um metadado inválido; gfarm_initialize(3) – desabilita a discussão sobre a biblioteca syscall hook na lista de correio “gfarm-discuss-ja” em ; “=” não pode ser incluído no nome de um arquivo; “gfreg” cria um arquivo cujo nome é “-“ quando “cat file | gfreg - gfarm:dir” (bugzilla-ja #35); Um arquivo remoto aberto por um processo pode ser fechado pelo processo filho.

Reparo de vazamento de memória;

gfreg(1) – reparo de bug relacionado à opção “-r”;

Reparo de falha de segmentação quando usando um tcsh antigo e “gfarm_agent”; hook “unlink(2)” – impossível remover um arquivo sem informação de fragmento. 194

13.10 Versão 1.1.1 de 17/05/2005

13.10.1 Características atualizadas

gfarm_agent(1) - servidor de cache de metadados do sistema de arquivos Gfarm. Isso melhora muito o desempenho e tempo de resposta para acessar o sistema de arquivos Gfarm. Para detalhes, vide página de manual do “gfarm_agent”;

gfreg(1) – adicionada a opção “-r” para suportar registro recursivo quando diretórios ou arquivos são especificados. As opções “-p” e “-i” são adicionadas para especificar explicitamente o modo de registro;

gfrm(1) – suporta remoção recursiva de réplica de arquivo. “gfrm –h host -r dir”.

Utilitários de configuração para pacotes Debian; config-gfarm – configura e estabelece o servidor de metadados e o arquivo de configuração do Gfarm; config-gfsd – configura e estabelece um nó do sistema de arquivos.

Melhoria de desempenho; Melhora significativamente o gerenciamento do cache de metadados; Melhora o desempenho de gfrun(1).

Biblioteca syscall-hook; Novos pontos de entrada em syscall hook: mknod e link; Reparos de bugs; chown, lchown, fchown, setxattr, lsetxattr, e fsetxattr, e execve.

Documentação; Gfarm-FAQ Adicionada: “Como executar automaticamente o “gfarm_agent” somente quando ele não está presente ?”; Adicionado como remover um metadado inválido quando um nó do sistema de arquivos se torna inoperante; Adicionado comentário para “gfchmod” e “gfmv”.

Reparo de bug Um arquivo pode ser criado mesmo sob um arquivo que não é diretório; Repara falha de segmentação quando lendo, escrevendo e procurando um arquivo na visualização global de arquivo; Um arquivo “” é considerado incorretamente como o diretório de trabalho corrente no sistema de arquivos Gfarm; Reparo de falha de segmentação quando renomeando um diretório; “gfrm” remove “.” ou “..” quando é especificado; “gfs_pio_truncate” não mantém ponteiro de arquivo; Biblioteca syscall hook não permite acesso a um arquivo grande; “gfreg” não pode registrar um arquivo via um socket (soquete); “gfsck” não remove metadados inválidos que não têm informações de fragmento.