CENTRO UNIVERSITRIO FEEVALE

LUCAS GRAEBIN

ESTUDO COMPARATIVO DE SISTEMAS DE ARQUIVOS DISTRIBUDOS

Novo Hamburgo, Junho de 2007.

LUCAS GRAEBIN

ESTUDO COMPARATIVO DE SISTEMAS DE ARQUIVOS DISTRIBUDOS

Centro Universitrio Feevale Instituto de Cincias Exatas e Tecnolgicas Curso de Cincia da Computao Trabalho de Concluso de Curso

Orientador: Vandersilvio da Silva Co-orientador: Reynaldo Cardoso Novaes

Novo Hamburgo, Junho de 2007.

RESUMO

A constante onipresena das redes propiciou um meio de comunicao comum entre grande parte dos usurios de microcomputadores. Este canal de transmisso facilitou o processo de armazenamento e compartilhamento de arquivos entre usurios atravs de servios como o Peer-to-Peer (P2P) de forma mais segura em relao aos dispositivos mveis de pouca confiabilidade utilizados at ento. Empresas de renome, como a IBM, Microsoft e Google, e grupos de pesquisa em Universidades vm investindo na pesquisa e no desenvolvimento de ferramentas que objetivam o armazenamento distribudo de arquivos. Estes projetos, individualmente, so direcionados resoluo de problemas especficos, que vo desde o reaproveitamento de espao ocioso em discos at a possibilidade de o cliente trabalhar com seus arquivos tendo sua estao de trabalho desconectada da rede. Um sistema de arquivos distribudo, quando bem projetado, possibilita o acesso a arquivos armazenados em um servidor com desempenho e confiabilidade semelhantes aos arquivos armazenados em computadores locais. Entretanto, sua implementao traz como obstculo os principais desafios existentes na rea de sistemas distribudos, a exemplo da replicao e da transparncia. Este trabalho aborda um estudo de conceitos, desafios e problemas existentes com a implementao de sistemas de arquivos distribudos. O objetivo identificar, com a aplicao de experimentos a serem elaborados neste trabalho, o grau da transparncia de replicao, transparncia de acesso e transparncia de localizao existente nas ferramentas a serem selecionadas. Em paralelo, sero realizadas simulaes para mensurar a eficincia destas ferramentas em processos de escrita e leitura. Palavras-chave: Sistemas distribudos, sistemas de arquivos distribudos, armazenamento distribudo, peer-to-peer.

LISTA DE ILUSTRAES

Figura 1.1 Exemplo de um sistema distribudo composto por uma camada de middleware ... 18 Figura 2.1 Estrutura bsica de um registro de atributo de arquivo........................................... 32 Figura 3.1 Arquitetura do Network File System em ambientes Unix ...................................... 40 Figura 3.2 Exemplo do processo de leitura de um arquivo no NFSv3 (a) e no NFSv4 (b)...... 41 Figura 3.3 Montagem de um sistema de arquivos distribudo no NFS .................................... 43 Figura 3.4 Representao do cache ao lado do cliente no Network File System ..................... 43 Figura 3.5 Exemplo de situaes para controle de mensagens retransmitidas......................... 45 Figura 3.6 Arquitetura do Andrew File System ....................................................................... 46 Figura 3.7 Arquitetura interna de uma estao de trabalho do AFS.........................................47 Figura 3.8 Exemplo do espao de nomes compartilhado oferecido pelo Coda File System.... 49 Figura 4.1 Laboratrio utilizado para a realizao dos experimentos...................................... 58 Figura 4.2 Representao da falha de comunicao entre os servidores.................................. 59 Figura 4.3 Procedimento para ensaio de replicao ................................................................. 60 Figura 4.4 Procedimento para ensaio da transparncia de acesso ............................................ 61 Figura 4.5 Contedo do arquivo realms utilizado nas estaes clientes do Coda File System 65 Figura 4.6 Processo de conexo com o servio do Coda File System......................................66 Figura 4.7 Processo de conexo com o servio do Network File System ................................ 66 Figura 4.8 Resultado obtido com a experimentao no Coda File System .............................. 67 Figura 4.9 Resultado obtido com a experimentao no Network File System ........................ 67 Figura 4.10 Chamada do comando proposto para identificar a transparncia de acesso ......... 68 Figura 4.11 Fim do processamento do comando proposto para identificar a transparncia de acesso................................................................................................................................ 68 Figura 4.12 Chamada do IOzone utilizada em sistemas de arquivos locais............................. 71 Figura 4.13 Chamada do IOzone utilizada em sistemas de arquivos distribudos ................... 71 Figura 4.14 Laboratrio utilizado para a realizao dos benchmarks ...................................... 71

Figura 4.15 Comparativo de desempenho do sistema de arquivos local com blocos de tamanhos distintos ............................................................................................................ 72 Figura 4.16 Comparativo de desempenho entre os sistemas de arquivos ................................ 72 Figura 4.17 Chamada do Netperf no cliente dos sistemas de arquivos distribudos ................ 73 Figura 4.18 Chamada do Netperf no computador responsvel pela gerao do trfego .......... 74 Figura 4.19 Comparativo de desempenho entre os sistemas de arquivos distribudos durante o trfego intenso na rede...................................................................................................... 74 Figura 4.20 Percentual de perda de desempenho entre os sistemas de arquivos distribudos.. 74

LISTA DE TABELAS

Tabela 4.1 Configurao de hardware do computador A ........................................................ 55 Tabela 4.2 Configurao de hardware do computador B ........................................................ 56 Tabela 4.3 Configurao de hardware do computador C ........................................................ 56 Tabela 4.4 Configurao de hardware do computador D ........................................................ 57 Tabela 4.5 Programas utilizados para a experimentao da transparncia de acesso .............. 60 Tabela 4.6 Testes de performance a serem realizados.............................................................. 63 Tabela 4.7 Parmetros utilizados na chamada do IOzone ........................................................ 63 Tabela 4.8 Sistemas de arquivos distribudos utilizados nas experimentaes........................ 65 Tabela 4.9 Parmetros utilizados na chamada do Netperf........................................................73

LISTA DE ABREVIATURAS E SIGLAS

AFS AVSG CORBA DNS ISO NFS P2P RFC RPC URL USB VFS VSG

Andrew File System Accessible Volume Storage Group Common Object Request Broker Architecture Domain Name System International Organization for Standardization Network File System Peer-to-Peer Requests For Comments Remote Procedure Call Universal Resource Locator Universal Serial Bus Virtual File System Volume Storage Group

SUMRIO

INTRODUO........................................................................................................................ 11 1 SISTEMAS DISTRIBUDOS .......................................................................................... 14 1.1 Desafios de Sistemas Distribudos ........................................................................... 16 Heterogeneidade ............................................................................................... 16 Sistemas Abertos .............................................................................................. 18 Tolerncia a Falhas........................................................................................... 19 Segurana..........................................................................................................23 Concorrncia..................................................................................................... 24 Transparncia....................................................................................................25 Escalabilidade................................................................................................... 27 1.1.1 1.1.2 1.1.3 1.1.4 1.1.5 1.1.6 1.1.7 2 2.1

SISTEMAS DE ARQUIVOS DISTRIBUDOS .............................................................. 30 Conceitos Bsicos..................................................................................................... 31 Sistemas de Arquivos ....................................................................................... 31 Nomeao e Transparncia............................................................................... 32 Cache ................................................................................................................ 33 Servio de Nomes............................................................................................. 34 Servio de Arquivos ......................................................................................... 34 Servio de Diretrios ........................................................................................ 35 Atualizao Concorrente de Arquivos.............................................................. 35 Replicao de Arquivos.................................................................................... 36 Heterogeneidade do Hardware e do Sistema Operacional ............................... 37 Tolerncia a Falhas........................................................................................... 37 Consistncia...................................................................................................... 37 Segurana..........................................................................................................38 2.1.1 2.1.2 2.1.3 2.2 2.2.1 2.2.2 2.2.3 2.3 2.3.1 2.3.2 2.3.3 2.3.4 2.3.5 2.3.6

Servios Oferecidos.................................................................................................. 34

Caractersticas Desejadas ......................................................................................... 35

2.3.7 3 3.1

Eficincia .......................................................................................................... 38

FERRAMENTAS DE SISTEMAS DE ARQUIVOS DISTRIBUDOS ......................... 39 Network File System ................................................................................................ 39 Arquitetura........................................................................................................ 39 Comunicao .................................................................................................... 41 Processos .......................................................................................................... 42 Servio de Nomes............................................................................................. 42 Cache e Replicao........................................................................................... 43 Tolerncia a Falhas........................................................................................... 44 Arquitetura........................................................................................................ 46 Comunicao .................................................................................................... 48 Processos .......................................................................................................... 48 Servio de Nomes............................................................................................. 48 Cache e Replicao........................................................................................... 49 Tolerncia a Falhas........................................................................................... 51 Andrew File System ......................................................................................... 51 Farsite ............................................................................................................... 52 Google File System .......................................................................................... 52 3.1.1 3.1.2 3.1.3 3.1.4 3.1.5 3.1.6 3.2 3.2.1 3.2.2 3.2.3 3.2.4 3.2.5 3.2.6 3.3 3.3.1 3.3.2 3.3.3

Coda File System...................................................................................................... 45

Outras Solues ........................................................................................................ 51

EXPERIMENTOS............................................................................................................ 54 4.1 4.2 4.3 Definio do Cenrio................................................................................................ 54 Configurao do Cenrio.......................................................................................... 55 Cenrios Elaborados ................................................................................................. 58 Transparncia de Replicao ............................................................................ 58 Transparncia de Acesso .................................................................................. 60 Transparncia de Localizao .......................................................................... 61

4.3.1 4.3.2 4.3.3 4.4 4.5 4.6

Testes de Desempenho ............................................................................................. 62 Escolha das Ferramentas .......................................................................................... 64 Resultados Obtidos ................................................................................................... 65 Transparncia de Replicao ............................................................................ 65 Transparncia de Acesso .................................................................................. 68 Transparncia de Localizao .......................................................................... 69 Testes de Desempenho ..................................................................................... 70

4.6.1 4.6.2 4.6.3 4.6.4 4.7

Dificuldades Encontradas ......................................................................................... 75

4.8

Trabalhos Futuros ..................................................................................................... 76

CONSIDERAES FINAIS ................................................................................................... 77 REFERNCIAS BIBLIOGRFICAS ..................................................................................... 79 ANEXOS .................................................................................................................................. 84

INTRODUO

Por muito tempo, os discos flexveis eram os nicos meios para o compartilhamento e transferncia de dados entre usurios de computadores pessoais. Embora seu uso fosse trivial, a disciplina usual era de possuir uma segunda cpia do disco para assegurar a disponibilidade dos dados e evitar perdas. Devido a sua instabilidade, baixa capacidade e taxa de transferncia, os discos flexveis passaram a ser vistos como uma alternativa pouco confivel. Com o passar do tempo, surgiram alternativas de armazenamento mais confiveis, tais como o CD. Apesar de poder ser lido em grande parte dos microcomputadores, a manipulao dos dados ali armazenados era inconveniente, pois dependia de um dispositivo de gravao no presente em todos os equipamentos. Com o advento das tecnologias Universal Serial Bus (USB) e IEEE-1394 (tambm conhecido como Firewire), o mercado de mdia removvel foi revitalizado. Entretanto, apesar de sua robustez e elevado grau de confiabilidade em relao aos discos flexveis, estes dispositivos no garantem a total disponibilidade dos dados, sendo vulnerveis a problemas eletrnicos, furtos e perdas. Devido a estas inseguranas, os usurios tiveram que aderir a servios disponveis na Internet para o armazenamento e transferncia de arquivos. Com a crescente oferta de largura de banda e a reduo acentuada de seu custo para utilizao dos meios de transmisso, os protocolos HTTP, FTP e servios Peer-to-Peer (P2P) (DABEK et al., 2001) tornaram-se alternativas de baixo custo para o armazenamento e transferncia de arquivos entre computadores pessoais. Apesar destas tcnicas, estes ambientes, em sua maioria, no garantem a disponibilidade dos dados, sendo vulnerveis a problemas de hardware e software. Alguns analistas prevem que, no futuro, os dados que hoje so armazenados localmente, residiro em servidores existentes na Internet (ROUSH, 2006). Diversas empresas oferecem servios que exploram esta forma de armazenamento, como por exemplo, o BeInSync (BEINSYNC, 2007) e o MediaMax da Streamload (MEDIAMAX, 2007). Nestes casos, os problemas de disponibilidade so tratados com o uso

12

de uma infra-estrutura prpria da empresa. Alm dos exemplos acima, empresas de grande porte, como a Microsoft, oferecem servios como o FolderShare (FOLDERSHARE, 2007) e possuem pesquisas nesta rea (ROWSTRON, 2001) o que demonstra o potencial deste tipo de soluo em um futuro prximo. Apesar de existirem solues proprietrias para o repositrio de arquivos, diversos esforos baseados em Software Livre e com iniciativas em outras direes, como por exemplo, o reaproveitamento de espao ocioso em discos entre os computadores de uma rede (BECK, 2003), vem sendo direcionados para esta rea. Para ser bem sucedido, o armazenamento distribudo deve tratar um dos grandes desafios dos sistemas distribudos que a transparncia. De acordo com Coulouris, a transparncia definida como o encobrimento do usurio e do programador de aplicao da separao dos componentes de um sistema distribudo, de modo que o sistema seja percebido como um todo ao invs de uma coleo de componentes independentes (COULOURIS, 2005, p. 23). Para o armazenamento distribudo dos arquivos, a transparncia obtida oferecendo ao usurio um modelo de armazenamento que estende o tradicional conceito de armazenamento presente nos computadores domsticos. Um sistema de arquivos distribudo a implementao de um sistema de arquivos cujos locais de armazenamento esto dispersos fisicamente, mas prov ao usurio uma viso centralizada, semelhante aos sistemas de arquivos locais (CHOW, 1998). Silberschatz complementa que o sistema de arquivos distribudo composto de clientes, servidores e dispositivos de armazenamento dispersos na rede, onde no h um nico repositrio de arquivos, mas sim diversos, sendo eles independentes (SILBERSCHATZ, 2000). Dessa forma, pode-se resumir que os sistemas de armazenamento distribudo constituem de uma camada de abstrao para a realizao de tarefas como escrita e leitura em discos rgidos espalhados fisicamente na rede. Os mais importantes desafios na construo de sistemas distribudos esto presentes quando se implementa sistemas de arquivos distribudos e devem ser levados em conta de acordo com o ambiente a que se destinam. Estes aspectos so a j citada transparncia, a resoluo de nomes, o gerenciamento de replicaes e a segurana (CHOW, 1998). O grau de importncia destes conceitos na implementao dos sistemas de arquivos distribudos, alm de depender do ambiente, recebem tratamentos diferentes entre os autores da rea de sistemas

13

distribudos. De acordo com Singhal, os dois servios de maior importncia presentes nos sistemas de arquivos distribudo so o servidor de nomes e o gerenciador de cache (SINGHAL, 1994). Estes servios so, respectivamente, responsveis pelo mapeamento de arquivos e diretrios, e pelo armazenamento de cpias dos dados de usurios em seus computadores (SINGHAL, 1994). Chow, por sua vez, ressalta a importncia da disperso e da multiplicidade, onde mltiplos clientes dispersos fisicamente podem acessar diversos arquivos residentes em servidores tambm espalhados em diversas localizaes (CHOW, 1998). A diversidade de abordagens em trabalhos tericos, como citado acima, tambm tem reflexos nas implementaes existentes atualmente. O resultado disso pode ser observado na implementao de diversos sistemas para armazenamento distribudos que vm sendo desenvolvidos e mantidos nos ltimos anos, cada um deles apresentando a resoluo de um problema especfico. Este trabalho tem por objetivo fazer uma reviso bibliogrfica dos conceitos, desafios e problemas gerados com a implementao de sistemas distribudos e sistemas de arquivos distribudos. Na segunda parte deste trabalho, sero realizados estudos e experimentos em sistemas de arquivos distribudos para identificar o grau da transparncia de replicao, transparncia de acesso e transparncia de localizao existente nestas ferramentas, alm de mensurar a eficincia destas solues em processos de escrita e leitura de arquivos, fazendo assim um comparativo com um sistema de arquivos local. Alm desta introduo, o trabalho esta organizado em mais quatro captulos. No primeiro, ser feita uma reviso nos conceitos, desafios e problemas existentes no desenvolvimento de sistemas distribudos. No segundo captulo, ser feita uma reviso na rea de armazenamento distribudo, abrangendo seus conceitos, desafios e problemas. No captulo trs, ser apresentado a arquitetura de algumas das principais ferramentas de sistemas de arquivos distribudos. No quarto captulo, ser apresentado o ambiente construdo, os cenrios elaborados e os resultados obtidos com os experimentos e as simulaes. Por fim, sero apresentadas as consideraes finais.

SISTEMAS DISTRIBUDOS

As redes esto presentes em todos os lugares. As primeiras evidncias de redes de computadores apareceram no incio da dcada de 60 com o projeto e implementao de sistemas centralizados, contendo um grande nmero de terminais espalhados (KIRNER, 1988). A partir de ento, a evoluo tecnolgica, possibilitando uma reduo nos custos de comunicao e de hardware, aliada ao avano no estudo de redes, propiciou as condies favorveis ao surgimento das redes de comunicao de computadores, proporcionando o compartilhamento de recursos entre mquinas e o aumento da confiabilidade e desempenho em redes locais (KIRNER, 1988). Inicialmente, foi dada nfase a problemas simples, como a troca de mensagens entre usurios de diferentes mquinas e o compartilhamento de impressoras ou de discos rgidos apenas para leitura, entretanto, com o passar do tempo, foi-se desenvolvendo sistemas mais complexos que oferecessem ao usurio um maior aproveitamento dos recursos distribudos pela rede (KON, 1994). O compartilhamento de recursos um forte motivo para a construo de sistemas distribudos (COULOURIS, 2005). Os recursos podem ser gerenciados por servidores e acessados por clientes, ou podem ser encapsulados como objetos e acessados por outros objetos clientes (COULOURIS, 2005). O compartilhamento de recursos computacionais pode existir de forma explcita ou implcita (KIRNER, 1988). No compartilhamento explcito, a rede oferece a possibilidade dos usurios acessarem e manipularem diretamente os recursos remotos, exigindo que os clientes conheam os detalhes dos recursos, enquanto que no compartilhamento implcito, o acesso feito automaticamente pelo sistema de forma transparente para o usurio. Sistemas com compartilhamento de recursos de comunicao e compartilhamento implcito de recursos acabaram, em grande parte, constituindo-se nos sistemas distribudos (KIRNER, 1988).

15

Vrias definies para sistemas distribudos podem ser encontradas na literatura. De acordo com Coulouris, um sistema distribudo um sistema cujos componentes, software ou hardware, localizado em computadores conectados a uma rede, comunicam-se e coordenam suas aes unicamente atravs da transmisso de mensagens (COULOURIS, 2005, p. 2). Tanenbaum define sistemas distribudos como sendo [...] uma coleo de computadores independentes que aparecem para os usurios do sistema como um nico computador (TANENBAUM, 2002, p. 2). Ribeiro complementa apresentando uma definio mais detalhada:
Os sistemas distribudos foram criados para distribuir as tarefas e aumentar o poder computacional atravs do uso de vrios processadores como tambm promover o compartilhamento de recursos. Cada processador possui sua prpria memria e a comunicao entre os processadores feita atravs de linhas de comunicao. Esses sistemas objetivam melhorar a comunicao entre os computadores, propiciando a integrao destes num sentido amplo, que pode envolver a facilidade de mudanas futuras, rapidez nas trocas de informaes e confiabilidade na execuo dos processos. Eles permitem que uma aplicao seja dividida em diferentes partes que podem ser processadas em sistemas independentes que se comunicam atravs das linhas de comunicao. Ele cria a iluso de que a rede de computadores seja vista como um nico sistema de tempo compartilhado, em vez de um conjunto de mquinas distintas. (RIBEIRO, 2005, p. 32).

As diferenciaes na definio de sistemas distribudos e a conseqente falta de clareza de algumas tm gerado controvrsias no que diz respeito relao entre sistemas distribudos e as redes de computadores (TANENBAUM, 2003). A distino fundamental que em um sistema distribudo, uma coleo de computadores independentes mostra-se aos usurios como sendo um sistema nico (TANENBAUM, 2003, p. 2). De acordo com Verissimo, uma rede de computadores uma infra-estrutura que conecta mquinas e adota um conjunto de protocolos de comunicao para permitir a interao entre elas, enquanto que os sistemas distribudos so construdos sobre as redes de computadores, que hospeda servios nas mquinas da rede e faz uso de protocolos de comunicao para suportar a execuo coerente das aplicaes (VERISSIMO, 2001). Os sistemas distribudos devem possuir, obrigatoriamente, caractersticas de multiplicidade de ns de processamento, para permitir o aumento no desempenho, tolerncia a falhas e disponibilidade do sistema, e um mecanismo de comunicao para suportar a conversao entre os componentes do sistema distribudo (SPECTOR, 1981).

Excepcionalmente, caractersticas como, a possibilidade de expanso, para permitir o crescimento incremental do sistema, mecanismos para deteco de erros e redundncia de dispositivos, para obter disponibilidade e tolerncia a falhas, e disperso geogrfica, para

16

permitir que os recursos sejam separados geograficamente, devem ser agregadas em seu desenvolvimento (SPECTOR, 1981). Quando bem implementado, um sistema distribudo pode oferecer diversas vantagens em relao aos sistemas centralizados e sobre um conjunto de mquinas isoladas, tais como o compartilhamento de recursos, aumento da disponibilidade dos servios, possibilidade de expanso da arquitetura etc (KON, 1994; COULOURIS, 2005). 1.1 Desafios de Sistemas Distribudos

O projeto de um sistema distribudo geralmente mais complexo em relao aos sistemas centralizados, pois seus recursos esto, muitas vezes, fisicamente dispersos, no havendo nenhum relgio comum entre os mltiplos processadores, podendo ocorrer atrasos na entrega das mensagens ou estas podem, at mesmo, serem perdidas. Apesar destas complexidades e dificuldades, os usurios devem ver um ambiente de sistema distribudo como sendo um sistema centralizado virtual, que oferece caractersticas como flexibilidade, eficincia, segurana e facilidade em seu uso (SINHA, 1996). Esta seo tem por objetivo apresentar os principais conceitos e desafios existentes na implementao de sistemas distribudos. 1.1.1 Heterogeneidade A heterogeneidade (isto , variedade e diferena) pode ocorrer de vrias formas nos sistemas distribudos, variando desde a diversidade de hardware e diferenas em protocolos de interligao de redes at variaes em gerenciadores de dados. Devido a estas distines, a integrao entre sistemas em ambientes heterogneos mais complexa em relao a ambientes homogneos, onde cada sistema baseado em uma arquitetura similar ou equivalente de hardware e software (NOTKIN, 1987). A Internet um exemplo prtico de ambiente heterogneo, pois concede aos usurios o acesso a servios e a execuo de aplicaes sobre um conjunto de computadores e redes de comunicao com caractersticas diferenciadas (COULOURIS, 2005). A heterogeneidade freqentemente inevitvel, podendo ser originada quando surgem necessidades de aquisio e desenvolvimento de sistemas ou equipamentos de

17

hardware (NOTKIN, 1987). Ela pode fazer-se presente de diferentes formas em um sistema distribudo (COULOURIS, 2005): Rede: Embora a Internet seja composta de muitos tipos de rede, suas diferenas so mascaradas pelo fato de que todos os computadores ligados a elas utilizam protocolos comuns para se comunicar. Por exemplo, um computador que possui uma placa Ethernet tem uma implementao dos protocolos Internet e outro computador, em um tipo diferente de rede, tambm possuir uma implementao dos protocolos Internet. Hardware: Os tipos de dados, como os inteiros, podem ser representados de diversas formas em diferentes tipos de hardware. Existem, por exemplo, duas alternativas para a ordem em que os bytes de valores inteiros so armazenados: uma iniciando a partir do byte mais significativo e outra a partir do byte menos significativo. Essas diferenas na representao devem ser consideradas caso mensagens devam ser trocadas entre programas sendo executados em diferentes hardwares. Sistemas Operacionais: Embora os sistemas operacionais de todos os computadores na Internet precisem incluir uma implementao dos protocolos Internet, nem todos fornecem necessariamente a mesma interface de programao de aplicativos para esses protocolos. Por exemplo, as chamadas para troca de mensagens no UNIX, so diferentes das chamados no Windows. Linguagens de Programao: Diferentes linguagens de programao utilizam diferentes representaes para caracteres e estruturas de dados, como arrays e registros. Essas diferenas devem ser consideradas, caso programas escritos em diferentes linguagens precisem se comunicar. Implementao por diferentes programadores: Os programas escritos por diferentes desenvolvedores no podem se comunicar a menos que eles utilizem padres comuns. Para realizar a comunicao via rede entre duas aplicaes preciso que sejam estabelecidos e adotados padres, como a exemplo dos protocolos Internet. No h uma nica soluo correta para se resolver os problemas de ambientes heterogneos (COULOURIS, 2005). Para resolver este desafio, os sistemas distribudos so compostos geralmente de uma camada de software denominada middleware, que inserida logicamente entre os usurios e o nvel mais elevado da aplicao para fornecer uma

18

abstrao de programao, assim como o mascaramento da heterogeneidade das redes, do hardware, de sistemas operacionais e linguagens de programao subjacentes

(TANENBAUM, 2002; COULOURIS, 2005), conforme ilustrado na Figura 1.1.

Figura 1.1 Exemplo de um sistema distribudo composto por uma camada de middleware Fonte: Tanenbaum, 2002, p. 2

Alm de resolver os problemas de heterogeneidade, o middleware fornece um modelo computacional uniforme para ser usado pelos programadores de servios e aplicativos distribudos (COULOURIS, 2005). Os modelos possveis incluem a invocao remota de objetos, a notificao remota de eventos, o acesso remoto a banco de dados e o processamento de transaes distribudas (COULOURIS, 2005). 1.1.2 Sistemas Abertos Diz-se que um sistema computacional aberto quando ele pode ser estendido e reimplementado de vrias maneiras (COULOURIS, 2005). O fato de um sistema distribudo ser ou no um sistema aberto determinado pelo grau com que os novos servios podem ser adicionados e disponibilizados para uso por uma variedade de programas clientes (COULOURIS, 2005). A caracterstica de sistema aberto obtida a partir do momento em que a especificao e a documentao das principais interfaces de software dos componentes de um sistema esto disponveis para os desenvolvedores de software, entretanto, a publicao de interfaces apenas o ponto de partida para adicionar e estender servios em um sistema distribudo, uma vez que o maior desafio para os projetistas a complexidade de sistemas distribuidos compostos por muitos componentes e elaborados por diferentes pessoas (COULOURIS, 2005).

19

A publicao dos protocolos de comunicao Internet, os chamados Requests For Comments (RFC), permitiu a construo de uma variedade de sistemas e aplicativos para a Internet, incluindo a web (COULOURIS, 2005). Os sistemas projetados a partir de padres pblicos so chamados de sistemas distribudos abertos, para reforar o fato de que eles so extensveis (COULOURIS, 2005). Eles podem ser ampliados em nvel de hardware, pela adio de computadores em uma rede, e em nvel de software, pela introduo de novos servios ou pela reimplementao dos antigos, permitindo aos aplicativos compartilharem recursos (COULOURIS, 2005). Uma vantagem adicional, freqentemente mencionada para sistemas aberto, sua independncia de fornecedores individuais (COULOURIS, 2005). 1.1.3 Tolerncia a Falhas Sistemas computacionais no esto livres de falhas. Quando elas ocorrem no nvel de hardware ou software, os programas podem produzir resultados incorretos, ou podem ser interrompidos antes da concluso de suas operaes (COULOURIS, 2005). Um sistema considerado tolerante a falhas quando este consegue mascarar a presena de falhas atravs das tcnicas de redundncia (JALOTE, 1994). Para que um sistema seja confivel, ele dever continuar funcionando corretamente mesmo com a presena de certos tipos de erros ou interferncias indevidas (KIRNER, 1988). Confiana um termo que abrange vrias exigncias teis para sistemas distribudos, como disponibilidade, confiana, segurana e sustentabilidade (MULLENDER, 1993). A disponibilidade corresponde a probabilidade de o sistema manter-se operacional dentro de certo perodo de tempo. A confiabilidade o grau de sucesso que um sistema consegue atingir dentro de um perodo de tempo, mantendo seu comportamento dentro das especificaes normais. Em contraste com a disponibilidade, a confiana definida em termos de intervalo de tempo ao invs de um determinado momento, que quando ocorreria a chamada do sistema pelo usurio. A segurana refere-se a situao em que nenhum efeito catastrfico venha a ocorrer originrio de uma falha temporria do sistema, e a sustentabilidade, por sua vez, refere-se a possibilidade do sistema detectar fracassos e consert-los automaticamente (MULLENDER, 1993). Uma das maneiras para se classificar as falhas em sistemas distribudos baseada no comportamento do componente aps o ocorrido (JALOTE, 1994). As falhas podem ocorrer a

20

nvel de processo ou canal de comunicao e so classificadas em (COULOURIS, 2005; JALOTE, 1994): Omisso: Recorrem a casos em que um processo ou um canal de comunicao no responde a pedidos entrantes. Arbitrria (ou Bizantinas): Nestes casos, o componente comporta-se de maneira totalmente arbitrria durante a falha. Por exemplo, um processo pode ajustar os valores errados a uma varivel, ou pode retornar um valor errado como resposta a uma requisio. As falhas arbitrrias no podem ser descobertas apenas vendo se o processo responde as requisies, pois se poderia arbitrariamente omitir a resposta correta retornando um valor errado como resposta a uma solicitao. Temporizao: Esta falha ocorre quando um componente responde demasiadamente cedo ou demasiadamente tarde. A temporizao bastante relevante em sistemas multimdia, onde h a transferncia de udio e vdeo. Em sistemas assncronos, pode haver uma alta latncia entre o pedido do cliente e a resposta do servidor caso este esteja sobrecarregado, entretanto no se pode afirmar que ocorreram fracassos na solicitao, pois este modelo de sistema no oferece garantia de tempo de resposta. Em sistemas tolerantes a falhas, a existncia de defeitos e interferncias indevidas pode ser superada atravs de redundncia temporal, redundncia de hardware ou redundncia de software, tcnicas geralmente utilizadas na construo de sistemas distribudos (JALOTE, 1994). A redundncia temporal corresponde a determinao de um resultado atravs de execues repetidas da mesma operao pelo mesmo elemento, usando eventualmente mtodos diferentes. A redundncia de hardware compreende do acrscimo de elementos repetitivos capazes de executarem a mesma operao. A redundncia de software inclui todos os programas e instrues que so empregadas para dar suporte tolerncia a falhas (JALOTE, 1994). As partes redundantes do sistema podem ser utilizadas como elementos de votao ou como elementos de reserva. Atuando como elementos de votao, cada parte redundante permanecer ativa no sistema, fornecendo seu resultado que, comparado com os outros, contribuir para a escolha do resultado correto por maioria. Como elemento de reserva, cada parte redundante permanecer latente at que seja acionada pelo sistema para substituir outro elemento defeituoso que estiver sendo desativado. Neste ltimo caso, o sistema dever possuir

21

um bom mecanismo para a realizao de testes e maneiras eficientes de identificao de defeitos para poder localiz-los e super-los (KIRNER, 1988). Os sistemas tolerantes a falhas situam-se em duas classes: sistemas de alta disponibilidade e sistemas de alta confiabilidade. Enquanto que sistemas de alta disponibilidade podem tolerar pequenos atrasos decorrentes de manuteno, os sistemas de alta confiabilidade exigem que o funcionamento correto seja mantido, apesar da presena de faltas (KIRNER, 1988). O objetivo principal da abordagem tolerante a falhas consiste em inibir o efeito das faltas, ou seja, uma interferncia indevida (KIRNER, 1988), atravs das redundncias do sistema. Quando estes sistemas forem submetidos ocorrncia de uma falha, eles devero reagir executando alguns, ou todos os procedimentos a seguir (KIRNER, 1988; SIEWIOREK, 1984; COULOURIS, 2005): Confinar a falta: Consiste em limitar o alcance de seus efeitos travs do uso de circuitos de deteco de faltas, verificao de consistncia e precedendo certas operaes, protocolos mltiplos de comunicao etc., evitando dessa forma a propagao das falhas. Detectar a falta: Corresponde a tomar conhecimento de sua existncia atravs de bits de paridade, verificao de consistncia, violao de protocolo etc. Essa deteco poder ser feita com o dispositivo fora de operao ou em operao. Mascarar a falta: Tem por objetivo eliminar os seus efeitos, fazendo com que as informaes redundantes se imponham sobre as informaes incorretas. Tentar novamente: Este um procedimento que dar bons resultados quando se tratar de faltas transientes, que no provoquem nenhum dano fsico ao sistema, podendo ser bem sucedida em uma segunda tentativa. Diagnosticar: Esta etapa tem por objetivo identificar a localizao da falta e suas propriedades, uma vez que a deteco da falta no trata desse aspecto. Reconfigurar: Consiste em substituir ou isolar as partes defeituosas. A alternativa por isolar as partes defeituosas poder levar o sistema a uma degradao gradual. A

22

substituio das partes defeituosas s ser possvel se houverem disponveis partes correspondentes. Recuperar: Tem a funo de colocar a operao do sistema, ou de alguma de suas partes, numa situao anterior a ocorrncia das falhas com o objetivo de eliminar os erros que aparecem. Isto exigir do sistema, conhecimento de pontos de operao que possam ser restaurados. Algumas tcnicas utilizadas para recuperar pontos de operao anteriores consistem em manter arquivos de backup, usar pontos de verificao, manipular listas de inteno etc. Reiniciar: Consiste em recolocar o sistema em funcionamento. Este processo poder no ser realizado totalmente com sucesso caso o sistema tenha sido danificado gravemente pelo erro, ou este no possua suporte para este procedimento. O reincio quente corresponde a retomada de todas as operaes a partir do ponto de onde ocorreu a deteco da falta. O reincio morno ocorrer quando somente uma parcela do sistema estiver em condies de ser retomada. O reincio frio consistir no reincio total do sistema, precedido pela recarga, se for necessria, para superar perdas de grande amplitude. Reparar: Constitui-se na atividade de consertar o componente defeituoso. Isto poder ser realizado com o sistema fora de operao ou em operao. No caso de reparo com o sistema fora de operao, o elemento defeituoso dever ser consertado com o sistema desligado. No caso de reparo com o sistema em operao, o elemento defeituoso dever ser substitudo por um elemento sobressalente nos moldes da reconfigurao, ou dever ser retirado, ocasionando eventualmente uma degradao gradual no sistema. Reintegrar: Aps a reparao do elemento, este dever ser reintegrado no sistema. Para sistemas em operao, a reintegrao dever ser efetuada sem a interrupo das operaes. Os sistemas distribudos fornecem um alto grau de disponibilidade perante a falhas de hardware ou software (COULOURIS, 2005). A disponibilidade de um sistema a medida da proporo de tempo em que ele est pronto para uso. Quando um dos componentes de um sistema distribudo falha, apenas o trabalho que estava usando o componente defeituoso

23

afetado. Um usurio pode passar para outro computador, caso aquele que estava usando falhe - um processo do servidor pode ser iniciado em outro computador (COULOURIS, 2005). 1.1.4 Segurana Muitos recursos de informao que se tornam disponveis e so mantidos em sistemas distribudos tm um alto valor intrnseco para seus usurios, portanto, sua segurana de considervel importncia (COULOURIS, 2005). A segurana de recursos de informao tem trs componentes: confidencialidade (proteo contra exposio para pessoas no autorizadas), integridade (proteo contra alterao ou dano) e disponibilidade (proteo contra interferncias com os meios de acesso aos recursos) (COULOURIS, 2005). Implementar tcnicas de segurana em sistemas distribudos mais complexo em relao aos sistemas centralizados devido a falta de um nico ponto de controle e do uso de redes inseguras para a transmisso de dados (SINHA, 1996). Tanenbaum (2002) diz que a segurana em sistemas computacionais esta relacionada fortemente com a noo de confiana dos usurios, que usufruiro dos servios. Embora a Internet possibilite que um programa em um computador se comunique com um programa em outro computador, independentemente de sua localizao, existem riscos de segurana associados ao livre acesso a todos os recursos em uma intranet. Mesmo que um firewall possa ser utilizado para formar uma barreira em torno de uma intranet, restringindo o trfego de entrada e sada, isso no garante o uso apropriado dos recursos pelos usurios de dentro da intranet, nem o uso apropriado dos recursos na Internet, que no so protegidos por firewalls. Em um sistema distribudo, os clientes enviam pedidos para acessar dados gerenciados por servidores, o que envolve o envio de informaes em mensagens por uma rede. Nesta situao, o desafio enviar informaes sigilosas em uma ou mais mensagens por uma rede de maneira segura, que no pode ser resolvida apenas ocultando o contedo de mensagens, e identificar corretamente um usurio ou outro agente remoto. Esses desafios podem ser resolvidos com o uso de tcnicas de criptografia desenvolvidas para esse propsito.

24

1.1.5 Concorrncia Tanto os servios como os aplicativos fornecem recursos que podem ser compartilhados pelos clientes em um sistema distribudo (COULOURIS, 2005). Portanto, existe a possibilidade de que vrios clientes tentem acessar um recurso compartilhado ao mesmo tempo, como por exemplo, uma estrutura de dados que registre lances de um leilo, que pode ser acessada com muita freqncia, quando o prazo final se aproximar (COULOURIS, 2005). O processo que gerencia um recurso compartilhado poderia aceitar e tratar um pedido de cliente por vez, mas essa estratgia limita o desempenho do tratamento de pedidos (COULOURIS, 2005). Portanto, os servios e aplicativos geralmente permitem que vrios pedidos de cliente sejam processados concorrentemente (COULOURIS, 2005). Sempre que existir compartilhamento e acesso simultneo, deve-se assegurar que as requisies sejam processadas em sua ordem de chegada para evitar que resultados inexatos venham a ocorrer (GALLI, 2000). Entretanto, em um sistema distribudo, s vezes impossvel determinar a ordem exata em que dois eventos ocorrerem, uma vez que estes ambientes no possuem memria e nem clock em comum (SILBERSCHATZ, 2000). Uma das solues para evitar os problemas de concorrncia impedindo que dois ou mais processos acessem um mesmo recurso simultaneamente. A excluso mtua garante que, enquanto um processo estiver acessando determinado recurso, todos os demais processos interessados no uso deste recurso devero aguardar pelo trmino de sua utilizao. A parte do cdigo do programa que acessa o recurso compartilhado denominada de regio crtica. Somente tal regio necessita proibir o acesso concorrente. O controle da concorrncia nesta regio pode ser gerenciado com a implementao e uso de semforos e monitores (GALLI, 2000). O semforo uma varivel do tipo integer cujo seu valor indica o estado do recurso protegido, que s pode ser manipulada por duas nicas instrues: P e V (GALLI, 2000). Estas denominaes so as iniciais das palavras holandesas Proberen e Verhogen, que significam testar e incrementar, respectivamente (MACHADO, 2002). O valor do semforo igual a 1, indica que nenhum processo est utilizando o recurso, enquanto que o valor igual a 0, indica que o recurso est em uso. Sempre que um processo desejar entrar em sua regio

25

crtica, a instruo P executada, e caso o semforo seja igual a 1, este valor ser decrementado e o processo solicitante poder executar as instrues de sua regio crtica. Entretanto, caso uma instruo P seja executada em um semforo com valor igual a 0, o processo ficar impedido de possuir o acesso, permanecendo em estado de espera (TANENBAM, 2006; MACHADO, 2002; GALLI 2000). O monitor representa um conjunto de variveis, de procedimentos e de estruturas de dados que so agrupados em um tipo especial de mdulo ou de pacote. Os processos podem invocar os procedimentos de um monitor sempre que quiserem, mas eles no podem acessar diretamente as estruturas de dados internas do monitor a partir de procedimentos declarados fora dele. Em um monitor, apenas um processo pode estar ativo em qualquer momento, o que torna esta tcnica til para obter a excluso mtua. Quando um processo chama um procedimento do monitor, as primeiras instrues do procedimento verificaro se existem processos ativos. Caso exista, o processo de chamada ser suspenso at que o outro processo tenha deixado o monitor. Se nenhum outro processo estiver utilizando o monitor, o processo de chamada pode entrar (TANENBAUM, 2006; GALLI, 2000). 1.1.6 Transparncia A transparncia definida como sendo o encobrimento do usurio e do programador da aplicao da separao dos componentes de um sistema distribudo, de modo que o sistema seja percebido como um todo ao invs de uma coleo de componentes independentes (COULOURIS, 2005, p. 23). Em outras palavras, a transparncia tem por objetivo esconder, sempre que possvel, todos os detalhes do sistema que so irrelevantes do usurio (CHOW, 1998). Alcanar a transparncia completa uma tarefa complexa e requer que diversos aspectos, identificados pela International Organization for Standardization (ISO), sejam levados em considerao durante o desenvolvimento (COULOURIS, 2005; TANENBAUM, 2002): Transparncia de acesso: Permite que recursos locais e remotos sejam acessados com o uso de operaes idnticas. Transparncia de localizao: Permite que os recursos sejam acessados sem conhecimento de sua localizao fsica ou na rede. A transparncia de localizao

26

permite que recursos sejam movidos entre nodos de um sistema distribudo, como por exemplo, um arquivo, sem ter seu nome e caminho afetado. Transparncia de concorrncia: Permite que vrios processos operem

concorrentemente, usando recursos compartilhados sem interferncia entre eles. Transparncia de replicao: Permite que vrias instncias dos recursos sejam usadas para aumentar a confiabilidade e o desempenho, sem conhecimento das rplicas por parte dos usurios ou dos programadores de aplicativos. Transparncia de falhas: Permite a ocultao de falhas, possibilitando que usurios e processos concluam suas tarefas, a despeito da falha de componentes de hardware ou software. Transparncia de mobilidade: Permite a movimentao de recursos e clientes dentro de um sistema, sem afetar a operao de usurios ou aplicativos. Transparncia de desempenho: Permite que o sistema seja reconfigurado para melhorar o desempenho medida que as cargas variam. Transparncia de escalabilidade: Permite que o sistema e os aplicativos se expandam em escala, sem alterar a estrutura do sistema ou os algoritmos de aplicativos. As duas transparncias mais importantes so a de acesso e a de localizao, pois sua presena ou ausncia afeta mais fortemente a utilizao de recursos distribudos. s vezes, elas so referidas em conjunto como transparncia de rede (COULOURIS, 2005). Como exemplo de transparncia de acesso, pode-se considerar uma interface grfica em um sistema de arquivos que organiza diretrios e subdiretrios em pastas, onde o usurio possa acessar seus arquivos locais e remotos, enquanto que um exemplo da falta de transparncia de acesso seria um sistema distribudo que no permitisse o acesso aos arquivos em um computador remoto a menos que o cliente faa uso, por exemplo, de um aplicativo de FTP (COULOURIS, 2005). A transparncia de localizao pode ser exemplificada atravs dos nomes de recursos da web, isto , os URLs, pois a parte do URL que identifica o nome de um servidor web se refere a um nome de computador em um domnio, em vez de seu endereo IP (COULOURIS,

27

2005). Entretanto, os URLs no so transparentes mobilidade, pois se a pgina web mudar para um domnio diferente, todas as referencias (links) existentes nas outras pginas ainda apontaro para a pgina original (COULOURIS, 2005). O endereo de correio eletrnico pode ser ilustrado como transparncia de rede. Ele consiste em um nome de usurio e um nome de domnio. O envio de correspondncias para tal usurio no envolve o conhecimento de sua localizao fsica ou na rede, nem o procedimento de envio de uma mensagem de correio depende da localizao do destinatrio. Assim, o correio eletrnico, dentro da Internet, oferece tanto transparncia de localizao como de acesso (COULOURIS, 2005). A transparncia de falhas tambm pode ser vista no contexto de correio eletrnico, que entregue ao destinatrio mesmo quando os servidores ou os enlaces de comunicao falham. As falhas so mascaradas pela tentativa de retransmitir as mensagens at que sejam enviadas com xito, mesmo que esse processo demore. Geralmente, o middleware converte as falhas de redes e processos em excees em nvel de programao (COULOURIS, 2005). A telefonia mvel pode ser ilustrada como exemplo da transparncia de mobilidade, pois em um cenrio onde quem realiza a chamada e quem chamado estejam viajando de trem em diferentes partes de um pas, nenhum dos dois possui conhecimento da mobilidade dos telefones (COULOURIS, 2005). O uso dos diferentes tipos de transparncia oculta e transforma em annimos os recursos que no tm relevncia direta para a execuo de uma tarefa por parte de usurios e de programadores de aplicativos (COULOURIS, 2005). 1.1.7 Escalabilidade Os sistemas distribudos funcionam de forma efetiva e eficaz em muitas escalas diferentes, variando desde uma pequena intranet at a Internet (COULOURIS, 2005). Um sistema descrito como escalvel se permanece eficiente quando h um aumento significativo no nmero de recursos e no nmero de usurios (GALLI, 2000; COULOURIS, 2005). A Internet um exemplo de um sistema distribudo no qual o nmero de computadores e servios vem aumentando substancialmente (COULOURIS, 2005).

28

O projeto de um sistema distribudo escalvel apresenta os seguintes desafios (COULOURIS, 2005; GALLI, 2000): Controlar o custo dos recursos fsicos: medida que a demanda por um recurso aumenta, deve ser possvel, a um custo razovel, ampliar o sistema para atend-la. Por exemplo, a freqncia com que os arquivos so acessados em uma intranet provavelmente vai aumentar a medida com que o nmero de usurios e de computadores for aumentando. Deve ser possvel adicionar servidores de arquivos de forma a evitar o gargalo de desempenho que haveria caso um nico servidor tivesse que tratar todos os pedidos. Controlar a perda de desempenho: Considerando o gerenciamento de um conjunto de dados, cujo tamanho proporcional ao nmero de usurios ou recursos presentes no sistema, como por exemplo, a tabela de correspondncia entre os nomes de domnios dos computadores e seus endereos IP mantidos no Domain Name System (DNS), seu crescente aumento, mesmo possuindo uma estrutura hierrquica, pode resultar em alguma perda de desempenho. Impedir que os recursos de software se esgotem: Um exemplo prtico da falta de escalabilidade o esgotamento de endereos IPs na Internet. Por isso, uma nova verso do protocolo, com endereos IP em 128 bits, est sendo adotada e exigir modificaes em muitos componentes de software. Evitar gargalos de desempenho: Em geral, os algoritmos devem ser descentralizados para evitar a existncia de gargalos de desempenho. Esse item pode ser ilustrado referenciando o predecessor do DNS, no qual a tabela de correspondncia entre endereos IP e nomes era mantida em um nico arquivo central, cujo download podia ser feito em qualquer computador que precisasse dele. Esse modelo funcionava perfeitamente quando havia apenas algumas centenas de computadores na Internet. O DNS eliminou esse gargalo particionando a tabela de correspondncia de nomes entre diversos servidores localizados em toda a Internet e administrados de forma local. De preferncia, o software de sistema e de aplicativo no deve mudar quando a escala do sistema aumentar, mas isso difcil de conseguir (COULOURIS, 2005). O problema da escala um tema central no desenvolvimento de sistemas distribudos

29

(COULOURIS, 2005). Sinha (1996) menciona alguns dos princpios utilizados para projetar sistemas escalveis: Evitar sistemas centralizados: O uso de sistemas centralizados, como um nico servidor de arquivo ou um nico banco de dados, no considerado um sistema escalvel, podendo apresentar perda de desempenho e tornar-se um gargalo quando houver aumentos demasiados de requisies para ele. Evitar algoritmos centralizados: Um algoritmo centralizado aquele que opera em um nico servidor, coletando informaes dos diversos nodos da rede e redistribuindo-as a eles. O uso de tais algoritmos no projeto de sistemas distribudos tambm no considerado como escalvel, pelo mesmo motivo dos sistemas centralizados. Execute a grande parte das operaes em estaes clientes: Quando possvel, determinadas operaes deveriam ser executadas no cliente ao invs do servidor, pois ele um recurso comum para os demais membros da rede e conseqentemente, os ciclos de um servidor so mais custosos em relao aos ciclos de uma estao de trabalho. Este princpio reala a escalabilidade do sistema e reduz a disputa por recursos compartilhados.

SISTEMAS DE ARQUIVOS DISTRIBUDOS

Os sistemas de arquivos foram originalmente desenvolvidos para sistemas computacionais centralizados e computadores desktop como um recurso do sistema operacional que fornece uma interface de programao conveniente para o armazenamento de arquivos em disco (COULOURIS, 2005). Subseqentemente, eles adquiriram caractersticas como controle de acesso e mecanismos de proteo de arquivos, que os tornaram teis para o compartilhamento de dados e programas. Os sistemas de arquivos distribudos suportam o compartilhamento de informaes atravs de arquivos e recursos de hardware com armazenamento persistente em toda uma intranet. Um servio de arquivo bem projetado d acesso a arquivos armazenados em um servidor com desempenho e confiabilidade semelhantes (e, em alguns casos, melhores) aos arquivos armazenados em discos locais. Seu projeto adaptado para as caractersticas de desempenho e confiabilidade das redes locais e, portanto, eles so mais eficazes no fornecimento de armazenamento persistente compartilhado para uso em intranets (COULOURIS, 2005). Um servio de arquivos permite que os programas armazenem e acessem arquivos remotos exatamente como se fossem locais, possibilitando que os usurios acessem seus arquivos a partir de qualquer computador em uma rede (COULOURIS, 2005). A concentrao do armazenamento persistente em alguns poucos servidores reduz a necessidade de armazenamento em disco local e (o mais importante) permite que sejam feitas economias no gerenciamento e no arquivamento (backup) dos dados persistentes pertencentes a uma organizao (COULOURIS, 2005). Um sistema de arquivos distribudo uma implementao de um sistema de arquivos que consiste em locais de armazenamento dispersos fisicamente em uma rede, entretanto, ele prov uma viso de sistema de arquivos tradicional para o usurio (CHOW, 1998). Esses sistemas possuem duas caractersticas principais, que devem ser tratadas de forma

31

transparente para os usurios, que a disperso e a multiplicidade de usurios e arquivos, ou seja, os mltiplos clientes acessam em diversos locais os arquivos residentes em servidores espalhados pela rede (CHOW, 1998). A principal caracterstica de um sistema de arquivos distribudo o fato de ele gerenciar um conjunto de dispositivos de armazenamento dispersos. Seu espao de armazenamento global composto por diferentes espaos de armazenamento menores localizado remotamente. Existem configuraes de servios de sistemas de arquivos distribudos nas quais os servidores so executados em mquinas dedicadas e configuraes na qual um computador pode desempenhar o papel de um servidor e de um cliente (SILBERSCHATZ, 2000). 2.1 Conceitos Bsicos

No decorrer desta seo, sero apresentados conceitos amplos relacionados a sistemas de arquivos distribudos que serviro de base para a anlise das sees subseqentes. 2.1.1 Sistemas de Arquivos Os sistemas de arquivos so responsveis pela organizao, armazenamento, recuperao, atribuio de nomes, compartilhamento e proteo de arquivos (COULOURIS, 2005). Eles fornecem uma interface de programao que caracteriza a abstrao de arquivo, liberando os usurios da preocupao com os detalhes da alocao e do armazenamento fsico no disco (GALLI, 2000; TANENBAUM, 2000; COULOURIS, 2005). Os arquivos contm dados e atributos (COULOURIS, 2005). Os dados consistem em uma seqncia de elementos (normalmente, bytes de 8 bits), acessveis pelas operaes de leitura e escrita de qualquer parte dessa seqncia (COULOURIS, 2005; TANENBAUM, 2000; SILBERSCHATZ, 2000). Os atributos so mantidos como um nico registro, contendo informaes como o tamanho do arquivo, indicaes de tempo, tipo de arquivo, identidade do proprietrio e listas de controle de acesso (COULOURIS, 2005; TANENBAUM, 2000; SILBERSCHATZ, 2000). Uma estrutura de registro de atributo tpica esta ilustrada na Figura 2.1.

32

Os sistemas de arquivos so projetados para armazenar e gerenciar um grande nmero de arquivos, com recursos para criao, atribuio de nomes e excluso de arquivos (TANENBAUM, 2000). Os sistemas de arquivos tambm assumem a responsabilidade pelo controle de acesso aos arquivos, restringindo o acesso de acordo com as autorizaes dos usurios e com o tipo de acesso solicitado (leitura, atualizao, execuo etc.) (COULOURIS, 2005). Tamanho do arquivo Horrio de criao Horrio de acesso (leitura) Horrio de modificao (escrita) Horrio de alterao de atributo Contagem de referncia Proprietrio Tipo de arquivo Lista de controle de acesso
Figura 2.1 Estrutura bsica de um registro de atributo de arquivo Fonte: Coulouris, 2005, p. 327

Um sistema de arquivos fornece servios de acesso a arquivos para os clientes (SILBERSCHATZ, 2000). Uma interface cliente para este servio formada por um conjunto de operaes de arquivos primitivas, como criar um arquivo, excluir um arquivo, ler a partir de um arquivo e gravar em um arquivo (SILBERSCHATZ, 2000). O principal componente de hardware que um servidor de arquivos controla um conjunto de dispositivos de armazenamento secundrio local (geralmente discos magnticos), nos quais os arquivos so armazenados e a partir dos quais eles so recuperados de acordo com os pedidos dos clientes (SILBERSCHATZ, 2000). 2.1.2 Nomeao e Transparncia A nomeao um mapeamento entre objetos lgicos e fsicos. Por exemplo, os usurios trabalham com objetos lgicos de dados representados por nomes de arquivos, enquanto que o sistema manipula blocos fsicos de dados, armazenados em trilhas de discos,

33

fornecendo ao usurio uma abstrao de um arquivo que oculta os detalhes de como e onde ele est armazenado de fato no disco fsico (SILBERSCHATZ, 2000). Dada a localizao lgica de um arquivo, ou seja, o caminho at ele, necessrio analisar os componentes deste caminho a fim de encontrar sua localizao fsica. necessrio descobrir em quais blocos de quais discos e de quais servidores se encontra o arquivo em questo (KON, 1994). Quando os arquivos de um sistema esto distribudos entre vrios servidores localizados em diferentes mquinas, desejvel que a localizao destes dados seja transparente aos usurios do sistema (FLOYD, apud KON, 1994). Em um sistema transparente, uma nova dimenso adicionada a abstrao, a de ocultar o local na rede onde o arquivo esta armazenado:
Idealmente, um servio de sistema de arquivo distribudo deve aparecer aos seus clientes como um sistema de arquivos centralizado-convencional. A multiplicidade e a disperso de seus servidores e dispositivos de armazenamento devem ser transparentes. Ou seja, a interface cliente desse servio no deve fazer distino entre arquivos locais e remotos. Cabe ao servio localizar os arquivos e organiz-lo para o transporte dos dados. Um sistema de arquivos distribudo transparente facilita a mobilidade do usurio trazendo o ambiente do usurio (ou seja, seu diretrio inicial) para onde quer que o usurio efetue login (SILBERSCHATZ, 2000, p. 542).

Diversas tcnicas de transparncia, adotadas em sistemas distribudos e visto na seo 1.1.6, so empregadas parcialmente ou diretamente na implementao de servios de arquivos (COULOURIS, 2005). 2.1.3 Cache Para aumentar o desempenho no acesso a informao fornecida por um sistema, procura-se armazenar os dados com maior nmero de solicitao em memria, evitando desta forma uma possvel sobrecarga para obter a informao do sistema novamente (SINGHAL, 1994; CARVALHO, 2003). Esta tcnica auxilia na economia do tempo de processamento, pois para acessar informaes remotas, por exemplo, o sistema estar limitado a velocidade da rede, que, mesmo rpida, estar limitado a velocidade do meio fsico do servidor remoto, pois este ainda necessitar procurar e processar os dados solicitados, carregando-os na memria e enviando-os para o cliente (SINGHAL, 1994; CARVALHO, 2003). Mesmo no acesso a informaes locais, a velocidade de acesso memria superior a velocidade de acesso ao meio de armazenamento, como um disco rgido, por exemplo, que

34

necessitaria mover o brao do leitor at a trilha em que se encontram os dados e esperar at que a rotao do disco traga-os cabea de leitura (CARVALHO, 2003). Em sistemas de arquivos distribudos, o cache pode estar presente tanto no cliente, como no servidor, evitando assim que o usurio faa uso desnecessrio da rede para obter informaes antes j solicitadas, enquanto que o servidor diminui o acesso ao meio fsico de armazenamento dos dados para envi-los ao cliente (CARVALHO, 2003). 2.2 Servios Oferecidos

Com a finalidade de proporcionar um ambiente de fcil uso para os usurios, escondendo toda a complexidade existente na nomeao global, no acesso aos arquivos dispersos pela rede e na organizao destes, os sistemas de arquivos distribudos fazem uso de trs servios que tm por objetivo controlar e atender estas funcionalidades, que so o servio de nomes, o servio de arquivos e o servio de diretrios, respectivamente (GALLI, 2000). 2.2.1 Servio de Nomes O servio de nomes tem por objetivo indicar a localizao de um determinado arquivo no conjunto de computadores do sistema de arquivos distribudo. Caso o nome do arquivo contiver o nome do computador aonde ele esta localizado, como por exemplo apolo:/tmp/arquivo, ento este servio no prov transparncia de localizao. Para prover esta transparncia, o nome de um arquivo no deve possuir indcios de sua localizao fsica, pois caso ele mude de lugar ou possua vrias cpias, o seu nome ou caminho no precisaro ser alterados (GALLI, 2000). 2.2.2 Servio de Arquivos O servio de arquivos responsvel por fornecer os mesmos servios e recursos de um sistema de arquivos tradicional, com a diferena que um sistema de arquivos distribudo pode ser acessado de qualquer estao de trabalho de dentro da rede. Esse servio tambm cuida das propriedades dos arquivos, como data de criao, data de alterao, tamanho, proprietrio, permisses de acesso e outras informaes relevantes, alm de manter a integridade das operaes realizadas nos arquivos (GALLI, 2000).

35

2.2.3 Servio de Diretrios O objetivo do servio de diretrios manter a organizao dos arquivos armazenados no sistema, fornecendo ao usurio uma interface para que eles possam organizar seus arquivos em uma estrutura hierrquica, atravs de diretrios e subdiretrios (GALLI, 2000). 2.3 Caractersticas Desejadas

Muitos dos conceitos encontrados na implementao de sistemas distribudos devem ser levados em considerao no desenvolvimento de sistemas de arquivos distribudos. Inicialmente, os primeiros sistemas de arquivos distribudos ofereciam recursos de transparncia de acesso e transparncia de localizao, emergindo subseqentemente preocupao no desenvolvimento de recursos como desempenho, escalabilidade, controle de concorrncia, tolerncia a falhas e segurana (COULOURIS, 2005). 2.3.1 Atualizao Concorrente de Arquivos As alteraes feitas em um arquivo por um nico cliente no devem interferir na operao de outros clientes que estejam acessando, ou alterando, o mesmo arquivo simultaneamente (COULOURIS, 2005). Em muitos aplicativos, a necessidade de controle de concorrncia para acesso a dados compartilhados amplamente aceita, e as tcnicas de implementao muitas vezes so dispendiosas (COULOURIS, 2005). O maior problema encontrado nas implementaes desse tipo de soluo quanto a sincronizao dos arquivos, o que inclui leitura e escrita concorrente (CARVALHO, 2003). A leitura concorrente pode ser implementada facilmente caso no haja escrita concorrente, pois quando um arquivo estiver sendo lido, certamente ningum poder alter-lo (CARVALHO, 2003). Para implementar a escrita concorrente, deve-se levar em conta que, quando um cliente escreve em um arquivo, todos os leitores devem ser avisados que o documento foi alterado, tendo-se que tomar cuidado tambm para que estas alteraes no desfaam as alteraes realizadas por outros usurios (COULOURIS, 2005; CARVALHO, 2003).

36

2.3.2 Replicao de Arquivos Em um servio de arquivos que suporta replicao, um arquivo pode ser representado por vrias cpias de seu contedo em diferentes locais, trazendo como benefcio a possibilidade dos servidores, que hospedam um mesmo conjunto de arquivos, compartilharem a carga do fornecimento de um servio para clientes que acessam esses arquivos melhorando assim a escalabilidade do servio, e melhora a tolerncia a falhas, permitindo que, em caso de falhas, os clientes localizem outro servidor que contenha uma cpia do arquivo (COULOURIS, 2005). A exigncia bsica de um esquema de replicao que diferentes rplicas do mesmo arquivo residam em servidores independentes, ou seja, a disponibilidade de uma rplica no afetada pela disponibilidade das demais (SILBERSCHATZ, 2000). Kon (1994) menciona algumas importantes vantagens que podem existir com a replicao de arquivos: Caso um disco seja danificado, as informaes nele contidas no sero perdidas, podendo ser recuperadas de outros discos em outros servidores; Se um servidor est momentaneamente inoperante ou inacessvel, os seus arquivos podem ser acessados em servidores alternativos, pois haver uma maior disponibilidade do servio de arquivos; Arquivos ou diretrios muito lidos podem ser oferecidos por vrios servidores, distribuindo-se a demanda eqitativamente entre os diversos servidores e aumentando o desempenho global do sistema. O principal desafio associado a replicao a sua atualizao e manuteno da consistncia entre as rplicas dos arquivos nos diversos servidores (SILBERSCHATZ, 2000). Para o usurio, as rplicas de um arquivo denotam a mesma entidade lgica e, dessa forma, uma atualizao a qualquer rplica deve refletir nas demais (KON, 1994). Os detalhes da replicao devem ser transparentes para os usurios, sendo tarefa do esquema de nomeao mapear um nome de arquivo replicado em um computador especfico sem o conhecimento de sua localizao pelo cliente (SILBERSCHATZ, 2000; KON, 1994). Poucos servios de arquivos suportam replicao completa, mas a maioria suporta o armazenamento de arquivos, ou de pores de arquivos em caches locais, que uma forma limitada de replicao (COULOURIS, 2005).

37

2.3.3 Heterogeneidade do Hardware e do Sistema Operacional As interfaces de servio devem ser definidas de modo que o software cliente e servidor possa ser implementado para diferentes sistemas operacionais e computadores (COULOURIS, 2005). Uma das grandes deficincias dos sistemas computacionais tem sido a incompatibilidade tanto de hardware quanto de software fabricado por diferentes companhias (KON, 1994). Cada vez mais, buscam-se padronizaes que permitam que mquinas de diferentes fabricantes se comuniquem sem grandes dificuldades (KON, 1994). O sistema de arquivos distribudo deve ser implementado de forma que o servidor e o cliente no necessitem da mesma arquitetura de hardware e da mesma soluo de software para a correta execuo do servio (COULOURIS, 2005). 2.3.4 Tolerncia a Falhas Por ser parte essencial nos sistemas distribudos, essencial que o servio de arquivos distribudos continue a funcionar diante de falhas de clientes e servidores (COULOURIS, 2005). Falhas de hardware ou de software podem ocasionar uma interrupo momentnea no funcionamento de uma mquina (KON, 1994). A queda de um nodo, ou uma falha em um canal de comunicao pode levar a uma partio na rede, ou seja, a conversao entre dois pontos da rede interrompida durante certo intervalo de tempo (KON, 1994). A grande maioria dos sistemas de arquivos distribudos sensvel a parties na rede quando esto em operao, e caso o cliente no consiga estabelecer contato com alguns dos servidores, os processos que fizeram solicitaes aos servios de arquivos sero notificados de que as informaes solicitadas no esto disponveis ou simplesmente so bloqueados at que a conexo se estabelea (KON, 1994). O mtodo mais utilizado para aumentar a disponibilidade de um servio de arquivos tem sido a replicao de dados, onde os arquivos so armazenados em dois ou mais servidores e caso um deles no esteja disponvel, outro servidor poder fornecer os servios solicitados (KON, 1994). 2.3.5 Consistncia Um sistema de arquivos distribudos deve garantir a consistncia dos arquivos de seus usurios (SILBERSCHATZ, 2000). Quando um arquivo replicado ou recuperado do

38

cache de uma estao cliente, por exemplo, podem ocorrer demoras inevitveis na propagao das modificaes devido a latncias de rede, podendo resultar na gerao de inconsistncias ou at perda das informaes caso o sistema seja frgil a esse tipo de cenrio (COULOURIS, 2005; SILBERSCHATZ, 2000). 2.3.6 Segurana Compartilhar arquivos entre vrios ambientes e usurios uma das vantagens que os sistemas de arquivos distribudos oferecem (CARVALHO, 2003). Entretanto, deixar que outros usurios possuam acesso a arquivos confidenciais um grande problema, sendo necessrio adotar mecanismos que garantam que pessoas no autorizadas no tenham acesso a tais informaes (COULOURIS, 2005; CARVALHO, 2003). Praticamente todos os sistemas de arquivos fornecem mecanismos de controle de acesso baseados no uso de listas de controle de acesso (COULOURIS, 2005). Nos sistemas de arquivos distribudos, h a necessidade de autenticar as requisies dos clientes para que o controle de acesso no servidor seja baseado nas identidades corretas de usurio e para proteger o contedo das mensagens de requisio e resposta com assinaturas digitais e, opcionalmente, criptografia de dados secretos (COULOURIS, 2005). 2.3.7 Eficincia As tcnicas usadas para a implementao de servios de arquivos representam uma parte importante do projeto de sistemas distribudos (COULOURIS, 2005). Um sistema de arquivos distribudo deve fornecer um servio que seja comparvel (ou melhor) aos sistemas de arquivos locais, em termos de desempenho e confiabilidade (COULOURIS, 2005). Ele deve ser conveniente para administrar, com operaes e ferramentas que permitam aos administradores de sistema instal-lo e oper-lo adequadamente (COULOURIS, 2005).

FERRAMENTAS DE SISTEMAS DE ARQUIVOS DISTRIBUDOS

No decorrer deste captulo, sero apresentadas algumas das principais ferramentas de sistemas de arquivos distribudos. 3.1 Network File System

O Network File System (NFS) foi originalmente desenvolvido pela Sun para ser utilizado em ambientes Unix, mas atualmente possvel encontrar implementaes para quase todas as arquiteturas de computadores e sistemas operacionais (TANENBAUM, 2002; COULOURIS, 2005). A idia principal do NFS possibilitar que um conjunto de clientes e servidores possam compartilhar um sistema de arquivos em comum, permitindo que um nodo seja ao mesmo tempo um cliente acessando arquivos remotos ou um servidor exportando arquivos (TANENBAUM, 2002). O NFS uma coleo de protocolos que prov ao cliente a viso de um sistema de arquivos distribudo, similar ao funcionamento do CORBA (TANENBAUM, 2002). Nesta seo, sero apresentados diversos aspectos do NFS, concentrando-se nas verses 3 (especificado na RFC 1813) e 4 (especificado na RFC 3530). 3.1.1 Arquitetura Nos sistemas operacionais, as chamadas de sistema so utilizadas para fazer a interface de comunicao entre o cliente e o sistema de arquivos local (TANENBAUM, 2002). Nos sistemas operacionais baseados em Unix, esta interface substituda por outra interface denominada de Virtual File System (VFS), que realiza a comunicao e oculta as diferenas entre os diversos sistemas de arquivos (TANENBAUM, 2002). As operaes

40

encaminhadas interface VFS so direcionadas ao sistema de arquivos local ou algum componente previamente instalado, como o cliente do NFS, que responsvel pelo acesso aos arquivos armazenados nos servidores atravs das chamadas de procedimentos remotos (TANENBAUM, 2002; COULOURIS, 2005). A Figura 3.1 ilustra a arquitetura do NFS.

Figura 3.1 Arquitetura do Network File System em ambientes Unix Fonte: Tanenbaum, 2002, p. 578

Quando o cliente efetua uma requisio ao servio de arquivos, esta solicitao encaminhada para a interface do VFS, que de acordo com a localizao fsica do arquivo solicitado, remete a requisio para o sistema de arquivos local ou para um componente (KON, 1996). O VFS mantm uma tabela para cada sistema de arquivos montado, com uma entrada para cada um dos arquivos abertos, denominada de v-node, que utilizado para informar se o arquivo local ou remoto (KON, 1996). Caso o arquivo esteja armazenado localmente, o vnode possuir uma referncia para o i-node do arquivo local e caso o arquivo esteja armazenado remotamente, ele conter o manipulador do arquivo que fornece todas as informaes necessrias para acess-lo (KON, 1996). Uma importante vantagem na arquitetura do NFS quanto a independncia do sistema de arquivos local, possibilitando que sejam compartilhados arquivos em ambientes heterogneos (TANENBAUM, 2002).

41

3.1.2 Comunicao Uma das caractersticas importantes na arquitetura do NFS sua independncia quanto a sistema operacional, rede e protocolo de comunicao, possibilitando que, por exemplo, clientes Windows acessem servidores Unix (TANENBAUM, 2002). Essa independncia atingida devido ao fato do NFS possuir em sua arquitetura uma camada de RPC que oculta as diferenas citadas, sendo esta responsvel pela comunicao entre clientes e servidores (TANENBAUM, 2002). Uma RPC similar a uma invocao a mtodo remoto, pois um processo cliente chama um procedimento que est sendo executado em um processo servidor, sendo que os servidores podem ser clientes de outros servidores para permitir encadeamentos de RPCs (COULOURIS, 2005). Um processo servidor define em sua interface de servio os procedimentos que esto disponveis para serem chamados de forma remota (COULOURIS, 2005). Todas as operao da verso 4 do NFS so implementadas com uma nica chamada composta de procedimento remoto a um servidor de arquivos, ou seja, uma mesma chamada RPC para a leitura de um arquivo, por exemplo, pode conter uma operao complexa envolvendo bloqueio, abertura, leitura etc., a exemplo da Figura 3.2 (b), diferente da verso 3, onde este processo era resolvido com duas chamadas de procedimento remoto, ilustrado na Figura 3.2 (a) (TANENBAUM, 2002).

Figura 3.2 Exemplo do processo de leitura de um arquivo no NFSv3 (a) e no NFSv4 (b) Fonte: Tanenbaum, 2002, p. 582

42

3.1.3 Processos O NFS um sistema cliente-servidor no qual usurios solicitam ao servidor que realize operaes em determinado arquivo (TANENBAUM, 2002). Uma de suas grandes caractersticas, que foi abandonado na verso 4, o fato do servidor no guardar o estado das transaes realizados. Esta caracterstica traz algumas vantagens imediatas, sendo que a mais significativa que, quando ocorre uma falha no servidor, ele no perde nenhuma informao sobre o estado da comunicao com os clientes, no precisando, desta forma, gastar tempo na tentativa de reconstituir este estado quando ele se recuperar da falha. Para o cliente, tudo que ele necessita fazer quando a comunicao com o servidor falhar repetir as chamadas ao servio at que obtenha resposta. Entretanto, esta caracterstica impede o servidor de gerenciar o acesso concorrente de seus arquivos e desta forma, o NFS no assume a consistncia de seu sistema de arquivos, podendo haver casos em que, diferentes clientes possuam diferentes cpias do mesmo arquivo ou diretrio no cache de seus computadores (KON, 1996; TANENBAUM, 2002). Em sua verso 4, o NFS guarda o estado das transaes realizadas, mantendo uma tabela de todos os arquivos abertos pelos usurios, assemelhando-se a um sistema de arquivos centralizado (TANENBAUM, 2002). 3.1.4 Servio de Nomes Assim como em todos os sistemas de arquivos distribudos, o servio de nomes uma caracterstica importante do NFS (TANENBAUM, 2002). A idia principal do modelo de servio de nomes do NFS prover aos usurios um acesso transparente ao sistema de arquivos dos servidores, que alcanada quando o cliente monta em seu sistema de arquivos local o sistema de arquivos distribudo, conforme apresentado na Figura 3.3. Esta ilustrao demonstra que os usurios no compartilham o mesmo espao de nomes, pois em ambos os clientes, o mesmo diretrio do servidor esta compartilhado em pontos de montagem diferentes. A desvantagem deste modelo reflete no processo de comunicao entre os clientes, que tero dificuldades em referenciar um mesmo arquivo, uma vez que o caminho de acesso a ele ser diferente entre os usurios (TANENBAUM, 2002).

43

Figura 3.3 Montagem de um sistema de arquivos distribudo no NFS Fonte: Tanenbaum, 2002, p. 583

3.1.5 Cache e Replicao O mdulo cliente do NFS armazena em cache os resultados obtidos em determinadas operaes para reduzir o nmero de requisies feitas aos servidores (TANENBAUM, 2002). O uso do cache no cliente implica na possibilidade de existirem diversas verses de arquivos, ou pores deles, em diferentes ns clientes, pois as gravaes feitas por um cliente no resultam na atualizao imediata do arquivo em outros computadores. Em vez disso, os clientes so responsveis por fazerem uma consulta seqencial no servidor para verificar se os dados armazenados em cache que eles contm so atuais. A Figura 3.4 ilustra a integrao do cache do computador local com o mdulo cliente do NFS. Cada cliente pode possuir cache em memria ou no disco rgido que contm informaes recentemente acessadas do servidor, tais como o contedo de um arquivo, seus atributos e diretrios (TANENBAUM, 2002).

Figura 3.4 Representao do cache ao lado do cliente no Network File System Fonte: Tanenbaum, 2002, p. 595

44

A verso 4 do NFS disponibiliza um suporte ainda limitado a replicao de arquivos, permitindo que os dados sejam copiados entre diversos servidores, sendo que estas cpias estaro disponveis somente para consulta dos usurios (TANENBAUM, 2002). Quando o cliente estabelecer acesso ao sistema de arquivos remoto do servidor, ele obter a relao dos locais que disponibilizam uma rplica do ponto de montagem e caso ocorram falhas de comunicao, o cliente tentar estabelecer uma nova conexo com os servidores informados na lista (TANENBAUM, 2002). 3.1.6 Tolerncia a Falhas At a verso 4 do NFS, a tolerncia a falhas no era um assunto muito mencionado, uma vez que seu protocolo no exigia que o servidor guardasse informaes sobre o estado da comunicao com os seus clientes para oferecer o seu servio satisfatoriamente, entretanto, com a mudana de arquitetura entre a verso 3 e 4 do NFS, a tolerncia e a recuperao de falhas passam a ser preocupaes desta ferramenta (TANENBAUM, 2002). Um dos problemas existentes com o RPC diz respeito ao fato dele no proporcionar nenhuma garantia em relao a sua confiabilidade, sendo que o principal problema do NFS a falta de uma implementao para deteco de solicitaes duplicadas (TANENBAUM, 2002). Entretanto, essas situaes so amenizados com o uso de um cache implementado no servidor que gerencia as requisies (que possuem em seu cabealho um cdigo identificador nico) vindas do cliente (TANENBAUM, 2002). A Figura 3.5 ilustra esta implementao com a exemplificao da negociao de mensagens entre o cliente e o servidor. Na primeira situao, apresentada na Figura 3.5 (a), o cliente envia uma requisio e inicia um timer que, se o cronmetro encerrar antes da resposta chegar, o cliente retransmite a mensagem original com seu cdigo identificador original, que ser ignorada pelo servidor, que ainda no havia concludo o processamento da primeira requisio (TANENBAUM, 2002). No segundo caso, apresentado na Figura 3.5 (b), o servidor recebe uma requisio retransmitida logo aps ter enviado o processamento da solicitao original ao cliente, sendo esta nova requisio ignorada, uma vez que seus cdigos identificadores so idnticos e a resposta mensagem original foi encaminhada (TANENBAUM, 2002).

45

Figura 3.5 Exemplo de situaes para controle de mensagens retransmitidas Fonte: Tanenbaum, 2002, p. 598

Na terceira situao, apresentada na Figura 3.5 (c), a resposta enviada ao cliente se perdeu, sendo ento retransmitido o contedo existente em cache, evitando que o servidor tivesse que processar o pedido novamente (TANENBAUM, 2002). 3.2 Coda File System

O Coda File System comeou a ser desenvolvido em 1987 pela Universidade de Carnegie Mellon, nos EUA, sendo descendente da verso 2 do Andrew File System (AFS) (TANENBAUM, 2002). Seu principal objetivo fornecer suporte a realizao de operaes desconectadas ao sistema de arquivos para computadores portteis que costumam ficar grande parte do tempo fora da rede, provendo assim uma alta disponibilidade dos arquivos aos seus usurios. Para tanto, uma cpia do arquivo que o usurio esta manipulando armazenada na mquina local, evitando assim que falhas de comunicao entre o cliente e o servidor prejudiquem o usurio (TANENBAUM, 2002). O suporte a operaes desconectadas surgiu com a proposta de criar um sistema de arquivos tolerante a falhas de rede entre clientes e servidores (KISTLER, 1991). O esforo empregado no Coda File System para lidar com este problema mostrou-se conveniente com o advento de clientes mveis (KISTLER, 1991). Quando um usurio atualiza um arquivo, as alteraes precisam ser propagadas aos servidores que o armazenam e caso o cliente esteja conectado ao servidor, esta atualizao feita de forma sncrona, ou seja, a alterao propagada no momento de sua gravao no cliente (BRAAM, 1998). Caso haja problemas nesta comunicao, ao invs de reportar o erro ao usurio, as informaes so gravadas localmente em um registro de alteraes pendentes e assim que a comunicao com os

46

servidores for restabelecida, estas alteraes sero propagadas automaticamente (BRAAM, 1998). 3.2.1 Arquitetura Por ser descendente do Andrew File System, o Coda File System herdou muitas de suas caractersticas arquitetnicas (TANENBAUM, 2002). O AFS foi projetado para disponibilizar a cada aluno e professor da Universidade de Carnegie Mellon uma estao de trabalho com um sistema compatvel com o Unix, onde os usurios entrariam em qualquer computador da rede e a sua viso do sistema de arquivos deveria ser a mesma. Sendo assim, era essencial tomar o mximo de cuidado quanto a escalabilidade da ferramenta, uma vez que ela deveria atender a aproximadamente 10 mil estaes de trabalho (TANENBAUM, 2002, KON, 1994). Para satisfazer essa exigncia, o AFS implementado em dois grupos de computadores, conforme ilustrado na Figura 3.6 (TANENBAUM, 2002). Um grupo consiste em um nmero relativamente pequenos de servidores de arquivos dedicados que so administrados de forma centralizada, denominados de Vice. O segundo grupo consiste em uma coleo maior de estaes de trabalho, denominadas de Virtue, que concedem aos usurios acesso ao sistema de arquivos distribudo (TANENBAUM, 2002).

Figura 3.6 Arquitetura do Andrew File System Fonte: Tanenbaum, 2002, p. 605

47

O Coda File System segue esta mesma organizao. Todas as estaes de trabalho possuem um processo denominado de Venus que executado em nvel de usurio no sistema operacional e tem como objetivo fornecer ao cliente o acesso ao sistema de arquivos distribudo (TANENBAUM, 2002). O processo Venus tambm responsvel por permitir que o cliente continue manipulando seus arquivos mesmo que a estao de trabalho no esteja conseguindo estabelecer conexo com o servidor, sendo esta sua principal caracterstica em relao ao NFS (TANENBAUM, 2002). A arquitetura interna de uma estao de trabalho do AFS ilustrada na Figura 3.7. Assim como no NFS, ele faz uso da interface VFS que intercepta todas as chamadas do cliente e as encaminha ao sistema de arquivos local ou ao processo Venus, que por sua vez, estabelece conexo com o servidor Vice atravs das chamadas de procedimentos remotos (TANENBAUM, 2002).

Figura 3.7 Arquitetura interna de uma estao de trabalho do AFS Fonte: Tanenbaum, 2002, p. 606

O Coda File System disponibiliza aos usurios uma viso de um sistema de arquivos local e suporta todas as operaes do sistema operacional desde que sigam as especificaes da interface VFS (KLEIMAN, apud TANENBAUM, 2002), que semelhante ilustrada na Figura 3.7 (TANENBAUM, 2002).

48

3.2.2 Comunicao A comunicao entre os processos do Coda File System realizada atravs de chamadas de procedimentos remotos (TANENBAUM, 2002). Entretanto, o Coda File System possui uma implementao mais sofisticada do RPC, denominada de RPC2, que oferece chamadas de procedimentos remotos seguras sobre um protocolo UDP (TANENBAUM, 2002). A cada chamada de procedimento remoto, o cliente do RPC2 inicia um processo que envia um pedido de requisio do servidor e subseqentemente os blocos da solicitao at receber uma resposta (TANENBAUM, 2002). Como o processamento do pedido pode levar um tempo arbitrrio para ser concludo, o servidor envia regularmente mensagens ao cliente para que este saiba que seu pedido esta sendo processado. Caso ocorra uma falha de comunicao entre o cliente e o servidor, o processo iniciado no computador cliente perceber que as mensagens cessaram e notificar a aplicao que o invocou do fracasso da operao (TANENBAUM, 2002). 3.2.3 Processos O Coda File System mantm uma distino entre os processos do cliente, representados atravs do Venus e processos do servidor, representados atravs do Vice, sendo que ambos utilizam uma biblioteca de threads no-preemptiva para permitir que as requisies sejam processadas concorrentemente no cliente (onde vrios processos de usurio podem ter requisies de acesso a arquivo em andamento concorrentemente) e no servidor (TANENBAUM, 2002). 3.2.4 Servio de Nomes Os arquivos no Coda File System agrupam-se em unidades denominadas de volumes (TANENBAUM, 2002). Os volumes se assemelham a uma partio do sistema operacional, mas geralmente possuem uma granularidade muito menor e correspondem a uma coleo de arquivos associados a um usurio. Os volumes so importantes por duas razes. Primeiro porque eles formam a unidade bsica pela qual o espao de nomes constitudo e esta construo ocorre quando eles so montados na estao cliente. A segunda razo que eles formam a unidade que ser replicada entre os servidores da rede (TANENBAUM, 2002).

49

importante notar que, diferente do NFS, o Coda File System possui um espao de nomes compartilhado (TANENBAUM, 2002). A Figura 3.8 representa esse

compartilhamento exemplificando um ambiente com o AFS.

Figura 3.8 Exemplo do espao de nomes compartilhado oferecido pelo Coda File System Fonte: Tanenbaum, 2002, p. 610

No Coda File System, os clientes tem seus volumes do sistema de arquivos distribudo montado abaixo do diretrio /coda, similar ao seu antecessor (BRAAM, 1994). Qualquer arquivo compartilhado por algum servidor do Coda File System estar disponvel neste ponto de montagem para todos os clientes. Diferente do NFS, os usurios se conectam ao servio fornecido pelo Coda File System e no individualmente nos servidores, que so adicionados como membros do servio de forma transparente (BRAAM, 1994). 3.2.5 Cache e Replicao O cache e a replicao so importantes implementaes do Coda File System, sendo elas fundamentais para o suporte a alta disponibilidade da qual a ferramenta se prope (TANENBAUM, 2002). Quando um arquivo aberto pelo cliente do Coda File System para leitura ou escrita, este transferido e armazenado integralmente no computador local com o intuito de aumentar o grau de tolerncia a falhas fazendo com que o cliente no fique dependente da disponibilidade do servidor (TANENBAUM, 2002). Quando o processo Vice fornece uma cpia de um arquivo para um processo Venus, ele tambm fornece uma promessa de callback, ou seja, um token emitido pelo servidor garantindo que ele notificar o processo cliente

50

quando qualquer outro usurio modificar o arquivo. Quando um servidor realiza uma requisio de atualizao de um arquivo, ele notifica todos os processos Venus para os quais tem promessas de callback emitidas, enviando um callback (uma chamada de procedimento remoto de um servidor para um processo Venus) notificando-os que o arquivo armazenado em cache esta desatualizado (TANENBAUM, 2002). Caso o processo Venus receba uma operao para abrir determinado arquivo, ele verificar primeiramente sua existncia em cache e caso seja encontrado, ele verificar se no recebeu nenhum callback de notificao quanto a sua desatualizao (TANENBAUM, 2002). Caso o arquivo que esta armazenado em cache esteja desatualizado, ento uma nova cpia resgatada do servidor, mas caso o arquivo no tenha sofrido alteraes, a cpia armazenada em cache aberta e utilizada sem referencia ao servidor (TANENBAUM, 2002). No Coda File System, os volumes podem ser replicados entre vrios servidores, diferente de seu antecessor (TANENBAUM, 2002). Cada volume associado a um grupo denominado de Volume Storage Group (VSG), que consiste em um conjunto de servidores que armazenam as rplicas do volume. O conjunto de servidores acessveis de um certo grupo em um certo momento chamado de Accessible Volume Storage Group (AVSG) (TANENBAUM, 2002). Quando um cliente necessita acessar um arquivo, ele contata um membro do AVSG que contenha em seu volume o arquivo solicitado (TANENBAUM, 2002). Caso este tenha sofrido alteraes, aps seu fechamento pelo cliente, o arquivo transferido em paralelo para todos os servidores do AVSG e posteriormente para os demais servidores do VSG (TANENBAUM, 2002; BRAAM, 1994). Quando um servidor reintegra a rede aps uma falha, nenhuma providncia tomada para a atualizao dos arquivos (KON, 1994). Os arquivos somente sero atualizados neste servidor caso seja realizada uma requisio de acesso a uma verso mais recente. Se o cliente descobre que o seu servidor est com uma verso antiga do arquivo, o cliente solicita a verso mais recente de quem a possuir e emite uma mensagem ao AVSG informando da existncia de uma verso desatualizada (KON, 1994).

51

3.2.6 Tolerncia a Falhas A arquitetura do Coda File System foi projetada para proporcionar que o sistema no seja sensvel a parties na rede, garantindo ao usurio uma alta disponibilidade do servio (TANENBAUM, 2002). Este recurso alcanado com a implementao de cache no cliente, possibilitando que o usurio manipule arquivos mesmo com a presena de falhas ou instabilidades na rede, e com a implementao da replicao de volumes em diversos servidores, garantindo uma maior disponibilidade dos computadores fornecedores do servio (TANENBAUM, 2002). A implementao e o uso desses recursos na ferramenta mencionado na Seo 3.2.5. 3.3 Outras Solues

Esta seo tem como objetivo apresentar solues de armazenamento distribudo que vem sendo desenvolvidas e mantidas por empresas de renome, como a IBM, a Microsoft e o Google. 3.3.1 Andrew File System O Andrew File System um ambiente de computao distribuda desenvolvido na Universidade de Carnegie Mellon com o apoio da IBM para uso como sistema de computao e informao do campus (COULOURIS, 2005). O projeto, cuja arquitetura similar ao Coda File System, citado na Seo 3.2, reflete a inteno de suportar o compartilhamento de informaes em larga escala, minimizando a comunicao entre cliente e servidor (COULOURIS, 2005). Esta funcionalidade foi alcanada atravs da adoo da semntica de sesso e pela transferncia de arquivos inteiros entre computadores clientes e servidores, armazenando-os em cache nos computadores locais at que o servidor receba uma verso mais atualizada (COULOURIS, 2005). A fim de limitar a possvel falta de segurana no sistema, o AFS adota uma srie de mecanismos como, por exemplo, o Kerberos Authentication Server, que permite a autenticao mtua de servidores e clientes (COULOURIS, 2005). Inicialmente, o projeto foi implementado na Universidade de Carnegie Mellon em uma rede com estaes de trabalho e servidores executando Unix BSD e o sistema

52

operacional Mach e, subseqentemente, se tornou disponvel em verses comerciais e de domnio pblico (COULOURIS, 2005). 3.3.2 Farsite O Farsite um sistema de arquivos distribudo que vem sendo desenvolvido nos laboratrios de pesquisa da Microsoft (ADYA, 2002). Ele disponibiliza aos usurios a viso de um sistema de arquivos centralizado enquanto que sua estrutura fsica encontra-se dispersa na rede em servidores e estaes de trabalho (ADYA, 2002). O Farsite fornece os mesmos recursos de um sistema de arquivos centralizado (armazenamento confivel, espao de nomes compartilhado, transparncia de acesso e transparncia de localizao) e os benefcios de um sistema de arquivos local (baixo custo e segurana no acesso aos arquivos) (ADYA, 2002). Em termos de arquitetura, o Farsite agrupa os computadores no que ele denomina de grupos de diretrios (ADYA, 2002). Todos os integrantes dos grupos de diretrios tm como funo armazenar rplicas dos arquivos que o grupo disponibiliza a rede, atender requisies de forma determinstica, atualizar as rplicas e enviar respostas aos usurios (ADYA, 2002). Quando o cliente solicita acesso a um arquivo, ele envia uma mensagem a um determinado grupo de diretrios que responde com o contedo do arquivo pedido (ADYA, 2002). Caso o usurio atualize esse arquivo, ele envia a atualizao ao grupo, que internamente far o trabalho de replicao (ADYA, 2002). O Farsite possibilita que os grupos de diretrios deleguem pores de arquivos aos demais grupos da rede, possibilitando um balanceamento de carga e aumentando a performance do servio (ADYA, 2002). Alm desses recursos, o Farsite implementa suporte a cache no cliente para o aumento de performance e a criptografia de arquivos armazenados na rede como meio de segurana (ADYA, 2002). 3.3.3 Google File System O Google File System um sistema de arquivos distribudo desenvolvido e estendido extensamente dentro da empresa Google como plataforma de armazenamento, onde o maior agrupamento de servidores existente para dados prov centenas de Terabytes atravs de milhares de discos rgidos em mais de mil mquinas que so acessadas simultaneamente por centenas de clientes (GHEMAWAT, 2003). O sistema compartilha de muitos dos mesmos

53

objetivos dos demais sistemas de arquivos distribudos, tais como escalabilidade, desempenho, confiana e disponibilidade, que foram implementados levando em considerao as necessidades da empresa e o ambiente tecnolgico utilizado por ela (GHEMAWAT, 2003). Sua arquitetura composta por um nico servidor principal e diversos computadores que armazenam os arquivos acessados pelos usurio (GHEMAWAT, 2003). Assim como outras solues de armazenamento distribudo, o Google File System possui um relacionamento cliente-servidor simtrico, sendo possvel que uma estao de trabalho atue na rede tanto como cliente, quanto como servidor (GHEMAWAT, 2003). Quando um cliente necessita de um arquivo, ele entra em contato com o servidor principal que o orienta informando em qual computador esta localizado o arquivo solicitado (GHEMAWAT, 2003). A partir dai, todas as alteraes realizadas pelo cliente no arquivo solicitado so encaminhadas diretamente ao computador indicado pelo servidor principal (GHEMAWAT, 2003). Alm deste apontamento, o servidor principal responsvel por gerenciar a replicao dos arquivos e coordenar os processos de incluso e remoo de computadores na rede (GHEMAWAT, 2003).

EXPERIMENTOS

A experimentao uma disciplina muito importante para diversas reas de pesquisa (WOHLIN et. al., 2000). Seu objetivo construir uma base de conhecimento confivel e reduzir assim incertezas sobre quais teorias, ferramentas e metodologias so mais adequadas para certos contextos (WOHLIN et. al., 2000). O objetivo dos experimentos neste trabalho de possibilitar a identificao do grau de transparncia, classificado em alto e baixo, existente nos sistemas de arquivos distribudos. Para tanto, sero elaborados trs cenrios distintos, no exaustivos, para cada uma das transparncias a serem estudadas (replicao, acesso e localizao) onde, o critrio para indicar o grau de transparncia alto em determinada tcnica a obteno do sucesso no respectivo cenrio e o critrio para indicar o grau de transparncia baixo em determinada tcnica a no obteno do sucesso no respectivo cenrio. Em paralelo a estes ensaios, sero realizadas simulaes para mensurar a eficincia destas ferramentas em processos de escrita e leitura de arquivos. Este captulo apresentar o ambiente construdo para a realizao dos experimentos, os cenrios elaborados e os resultados obtidos com os experimentos. 4.1 Definio do Cenrio

Os experimentos sero realizados em um ambiente em que os usurios usufruiro de servios de armazenamento distribudo onde, atravs de qualquer computador cliente localizado na rede, conseguiro gerenciar seus arquivos de forma transparente, sem precisarem se preocupar com a localizao fsica dos dados e com a utilizao de programas especficos para a manipulao dessas informaes. Fazendo-se uso de uma analogia, a proposta similar s redes de energia eltrica, onde toda complexidade referente a gerao,

55

transmisso e distribuio oculta para o usurio, que simplesmente usufrui deste recurso para ligar equipamentos eletrnicos, sem precisar preocupar-se de onde a energia foi gerada e que caminhos ela percorreu para chegar at ele. Alm da transparncia de acesso e localizao, o ambiente garantir a replicao dos arquivos dos clientes com o intuito de fortalecer a disponibilidade do servio. 4.2 Configurao do Cenrio

Para a realizao dos experimentos ser utilizado um notebook e trs computadores desktop com as configuraes de hardware descritas nas tabelas abaixo. Estes computadores sero interligados por um Hub de 10 Mbps e todos possuiro a instalao padro do Sistema Operacional Debian GNU/Linux 4.0 com Kernel 2.6.18-4.
Tabela 4.1 Configurao de hardware do computador A

Processador

Mbile AMD Sempron 2800+ 1600 MHz

Placa Me

SIS 760 GX

Memria RAM

512 MB (2 x 256 DDR-SDRAM)

Memria Cache L1

128 KB

Memria Cache L2

256 KB

Disco Rgido

40 GB, IDE, 4200 RPM

Placa de Rede
Fonte: Tabela do Autor

SIS 900 10/100 Mbps Ethernet PHY

56

Tabela 4.2 Configurao de hardware do computador B

Processador

AMD Athlon XP 2000 MHz

Placa Me

Asus A7V8X-X

Memria RAM

512 MB (1 x 512 DDR-SDRAM)

Memria Cache L1

128 KB

Memria Cache L2

256 KB

Disco Rgido

80 GB, IDE, 7200 RPM

Placa de Rede
Fonte: Tabela do Autor

Realtek 10/100 Mbps Ethernet PHY (Onboard)

Tabela 4.3 Configurao de hardware do computador C

Processador

Intel Celeron 2400 MHz

Placa Me

Intel Desktop Board D845PEMY

Memria RAM

256 MB (1 x 256 DDR-SDRAM)

Memria Cache L1

128 KB

Memria Cache L2

1024 KB

57

Disco Rgido

40 GB, IDE, 7200 RPM

Placa de Rede
Fonte: Tabela do Autor

Intel PRO 10/100 LAN Network Connection (Onboard)

Tabela 4.4 Configurao de hardware do computador D

Processador

Intel Celeron 2400 MHz

Placa Me

Intel Desktop Board D845PEMY

Memria RAM

256 MB (1 x 256 DDR-SDRAM)

Memria Cache L1

128 KB

Memria Cache L2

1024 KB

Disco Rgido

40 GB, IDE, 7200 RPM

Placa de Rede
Fonte: Tabela do Autor

Intel PRO 10/100 LAN Network Connection (Onboard)

Devido s semelhanas de hardware, os computadores C e D atuaro como servidores do servio de armazenamento distribudo nos cenrios propostos, enquanto que, os demais computadores, desempenharo o papel de clientes. A Figura 4.1 ilustra o laboratrio a ser construdo para a realizao dos experimentos. Nos ensaios da transparncia de replicao e da transparncia de acesso, o volume dos servidores ser replicado entre os dois computadores, proporcionando aos clientes um espao nico de 5 GB tolerante a falhas para o armazenamento de arquivos. No ensaio da

58

transparncia de localizao, pretende-se agrupar o volume de ambos os servidores, oferecendo ao ambiente um espao de armazenamento de 10 GB, sem tolerncia a falhas. Em ambos os casos o espao em disco definido pode variar dependendo da limitao das ferramentas.

Figura 4.1 Laboratrio utilizado para a realizao dos experimentos Fonte: Imagem do Autor

4.3

Cenrios Elaborados

A seguir sero apresentados os cenrios elaborados para identificar o grau da transparncia de replicao, transparncia de acesso e transparncia de localizao existente nos sistemas de arquivos distribudos. 4.3.1 Transparncia de Replicao O cenrio da transparncia de replicao simular a cpia de um arquivo local para o ponto de montagem criado no computador cliente que concede acesso ao sistema de arquivos distribudo e em seguida a falha de um dos servidores. Entretanto, caso o computador cliente continue tendo acesso ao arquivo recentemente copiado, mesmo com a ausncia de um dos nodos, no representa conclusivamente a presena da tcnica de replicao na ferramenta, pois o nodo que falhou no necessariamente o nodo em que o cliente esta conectado. A Figura 4.2 ilustra este problema. Na representao, o Cliente 1 esta conectado com o Servidor

59

2 durante a manipulao de um determinado arquivo. Caso ocorra uma falha de comunicao entre os servidores antes da replicao do arquivo recentemente manuseado e em seguida o usurio estabelea novamente uma conexo com o Servidor 2 para ter acesso ao arquivo, este ser bem sucedido, uma vez que no ocorreram problemas de comunicao entre esses nodos.

Figura 4.2 Representao da falha de comunicao entre os servidores Fonte: Imagem do Autor

Para uma correta identificao do grau da transparncia de replicao existente nas ferramentas, necessrio garantir que a situao acima no ocorrer, ou seja, que o servidor em que o cliente estabeleceu a conexo seja o servidor que sofrer a falha. Para isso, necessrio que, antes de simular a falha de um dos servidores, haja a certeza de em qual computador o arquivo ser armazenado antes da replicao. Uma possvel soluo para esta situao seria a construo de um cluster de alta disponibilidade (failover) entre os servidores, onde apenas um nodo receberia as requisies enquanto o outro permaneceria ocioso at que o primeiro falhasse. Entretanto, a construo desse cenrio depender da existncia desse recurso nas ferramentas selecionadas. Obtendo a soluo para a situao acima, cabe ento a realizao do experimento. A proposta deste ensaio de executar no cliente uma linha de comando similar a apresentada na Figura 4.3, que copia um arquivo no tamanho aproximado de 1 MB para o ponto de montagem que concede acesso ao sistema de arquivos distribudo e aps o intervalo de 5

60

segundos estabelece uma conexo remota com o servidor em que o cliente esta conectado, desabilitando todos os dispositivos de rede e em seguida forando seu desligamento, simulando assim uma falha.

cp /tmp/arquivo.tar.gz /mnt/; sleep 5; ssh servidor1 poweroff I -f

Figura 4.3 Procedimento para ensaio de replicao Fonte: Imagem do Autor

Para o cenrio ser bem sucedido, a replicao entre os servidores dever ocorrer no intervalo de 5 segundos e em seguida, aps o desligamento do computador, o cliente dever conseguir ter acesso ao arquivo atravs do ponto de montagem para o qual ele foi copiado. A latncia de 5 segundos para a replicao de um arquivo no tamanho aproximado de 1 MB proposta para este experimento no foi baseada em bibliografias, sendo considerada satisfatria no escopo deste trabalho levando em considerao que a replicao dever ocorrer em uma rede de 10 Mbps. Outros ensaios podero ser realizados seguindo este mesmo foco para se obter resultados mais precisos, transferindo arquivos de tamanhos maiores e diminuindo o intervalo entre a cpia e a desativao das interfaces de rede do servidor. 4.3.2 Transparncia de Acesso Como j citado na Seo 1.1.6, a transparncia de acesso possibilita que os recursos remotos de um sistema de arquivos distribudo sejam acessados de forma semelhante aos recursos de um sistema local. Sendo assim, para identificar o grau da transparncia de acesso existente nas ferramentas, ser executado um conjunto de programas, apresentados na Tabela 4.5, presentes na instalao padro na maioria das distribuies do Sistema Operacional Linux.
Tabela 4.5 Programas utilizados para a experimentao da transparncia de acesso

ls

Lista o contedo de determinado diretrio.

cd

Altera o diretrio corrente.

61

mkdir

Cria um diretrio.

rm

Exclui arquivos ou diretrios.

mv

Move ou altera o nome de um arquivo.

touch

Altera o timestamp de um arquivo. Para o experimento, este comando ser utilizado unicamente para a criao de um arquivo vazio.

Fonte: Tabela do Autor

Para automatizar esta execuo e simular acessos seqenciais de forma simtrica entre as ferramentas, proposto a execuo da linha de comando apresentada na Figura 4.4, que contempla a execuo de todos os programas acima citados.

for i in $(seq 500); do mkdir $i; cd $i; touch $i.txt; mv $i.txt $i; ls; cd ..; rm rf $i; done
Figura 4.4 Procedimento para ensaio da transparncia de acesso Fonte: Imagem do Autor

Esta linha de comando ser executada no ponto de montagem do sistema de arquivos distribudo e para o experimento ser bem sucedido, a execuo dela no dever gerar nenhuma exceo para o sistema. 4.3.3 Transparncia de Localizao A transparncia de localizao pode existir em diversos aspectos em sistemas distribudos. No escopo deste trabalho, a transparncia de localizao pode ser identificada com a realizao de pelo menos dois ensaios. O primeiro realizado durante os experimentos da transparncia de replicao, onde o ambiente proposto disponibiliza aos clientes um servio de armazenamento distribudo tolerante a falhas. Neste cenrio, o cliente no precisa se preocupar com a localizao fsica (entre os volumes dos servidores) dos arquivos que ele esta manipulando e caso um nodo falhe, suas requisies sero encaminhadas a um nodo ativo, muitas vezes sem o conhecimento do cliente, que continuar a usufruir dos servios

62

desta vez localizados em outro servidor. Pode-se afirmar que, dependendo do resultado obtido com os experimentos da transparncia de replicao, a transparncia de localizao estar presente na ferramenta. A proposta do segundo ensaio construir um laboratrio similar ao ilustrado na Figura 4.1, onde o volume dos servidores ser agrupado ao invs de replicado, fornecendo um espao de armazenamento de 10 GB, similar a proposta das ferramentas de armazenamento distribudo em Grid (TAURION, 2004), que oferece uma alta escalabilidade do ambiente em termos de armazenamento. Caso as ferramentas a serem selecionadas proporcionem a construo deste ambiente, os testes se resumiro na movimentao de arquivos entre os discos dos servidores. Este ensaio ser considerado bem sucedido se, aps a movimentao de determinado arquivo entre os servidores, o cliente continue tendo acesso a ele fazendo uso do mesmo caminho utilizado at ento. 4.4 Testes de Desempenho

Testes de desempenho, quando aplicados a sistemas de arquivos, indicam como o sistema reage a certas operaes, como escrita e leitura. A proposta dos testes de desempenho neste trabalho de comparar a performance de escrita e leitura entre sistemas de arquivos distribudos e um sistema de arquivos local, que para este experimento ser o Ext3. Todos os testes de performance entre os sistema de arquivos sero realizados no computador de configurao B e para mensurar o desempenho no sistema de arquivos local, ser adicionado um segundo disco rgido de 40 GB de espao, interface IDE e de 4200 RPM para que no ocorram interferncias do sistema operacional durante o processo, aumentando assim a exatido dos resultados. A ferramenta escolhida para a realizao deste benchmark foi o IOzone (CILIENDO, 2007), uma vez que no foram encontradas solues para mensurar desempenho em sistemas de arquivos distribudos. O IOzone permite a criao de arquivos seqncias de diferentes tamanhos e a simulao de gravao em blocos de tamanhos variados (CILIENDO, 2007). Neste trabalho, sero aplicados os testes apresentados na Tabela 4.6.

63

Tabela 4.6 Testes de performance a serem realizados

Escrita

Mensura a performance de escrita de um arquivo novo.

Mensura a performance de escrita de um arquivo j existente. Reescrita Normalmente, o desempenho da reescrita superior ao desempenho da escrita de um arquivo novo, uma vez que seus metadados j esto criados.

Leitura

Mensura a performance de leitura de um arquivo existente.

Mensura a performance de leitura de um arquivo recentemente Releitura lido. Normalmente, o desempenho da releitura superior ao desempenho de leitura, uma vez que o sistema operacional armazena em cache os dados de arquivos recentemente lidos.
Fonte: Tabela do Autor

A Tabela 4.7 apresenta os parmetros a serem utilizados na chamada do IOzone.

Tabela 4.7 Parmetros utilizados na chamada do IOzone

-c

Mensura o tempo consumido para a execuo dos testes at o fechamento do arquivo.

-t

Permite definir quantas threads ou processos estaro ativos durante os testes.

Define o caminho e o nome do arquivo de testes a ser gerado. A -F quantidade de arquivos informados para este parmetro deve ser igual quantidade de threads ou processos definidos.

64

-i 0

Especifica a realizao de testes de escrita e reescrita.

-i 1

Especifica a realizao de testes de leitura e releitura.

-r

Define o tamanho dos blocos de registros a serem gravados.

-s
Fonte: Tabela do Autor

Define o tamanho do arquivo de testes a ser manipulado.

4.5

Escolha das Ferramentas

Alguns critrios foram previamente estabelecidos para a escolha das ferramentas que fariam parte dos experimentos. O primeiro diz respeito a seu licenciamento. Foi imprescindvel que as solues de sistemas de arquivos distribudos estivessem enquadradas em uma licena que permitisse a liberdade de execuo do programa para a realizao deste estudo. O segundo critrio estabelecido foi a eliminao de projetos descontinuados, para que o andamento deste trabalho no fosse prejudicado pela falta de suporte. Para tanto, levouse em considerao a data de lanamento das ltimas verses e correes dos projetos, alm do ndice de movimentao das listas de discusso, caso houvesse. Esses critrios foram atendidos plenamente pelas seguintes ferramentas: Network File System, Andrew File System e Coda File System. Entre essas, optou-se pela primeira e a terceira soluo citada. O Andrew File System foi dispensado uma vez que sua arquitetura similar a do Coda File System, que durante o processo de escolha aparentou estar mais maduro e evoludo em relao a seu antecessor devido ao suporte a operaes desconectadas. A verso das ferramentas a serem utilizadas ilustrada na Tabela 4.8.

65

Tabela 4.8 Sistemas de arquivos distribudos utilizados nas experimentaes

Ferramenta

Verso

Coda File System

6.9.1

Network File System

Fonte: Tabela do Autor

4.6

Resultados Obtidos

Esta seo apresentar os resultados obtidos com a aplicabilidade dos cenrios elaborados e os resultados dos testes de desempenho entre os sistemas de arquivos. 4.6.1 Transparncia de Replicao Antes de iniciar a aplicao do cenrio criado para identificar o grau da transparncia de replicao dos sistemas de arquivos distribudos, foi necessrio encontrar uma alternativa para contornar o problema mencionado na Seo 4.3.1, tendo-se que identificar primeiramente em qual servidor o computador cliente estava estabelecendo conexo. No Coda File System, o programa cliente do sistema de arquivos distribudo possui um arquivo de configurao denominado de realms, que permite definir clulas para o agrupamento de servidores cujos volumes se replicam (HARKES, 2004). O contedo do arquivo realms utilizado pelas estaes clientes neste experimento apresentado na Figura 4.5. Nele, h uma clula nomeada de codaserver que representa o acesso aos servidores codaserver1 e codaserver2.

Figura 4.5 Contedo do arquivo realms utilizado nas estaes clientes do Coda File System Fonte: Imagem do Autor

Quando o cliente estabelece conexo com o sistema de arquivos distribudo (ilustrado na Figura 4.6), ele informa, alm de suas credenciais, o nome da clula definida no

66

arquivo de configurao. Durante o processo de conexo com o servio, o cliente tentar estabelecer acesso com o primeiro servidor descrito logo aps o nome da clula.

Figura 4.6 Processo de conexo com o servio do Coda File System Fonte: Imagem do Autor

Caso este no esteja disponvel e caso haja outro servidor informado logo em seguida, como o caso deste ambiente, o cliente tentar restabelecer uma nova conexo com o servio, dessa vez acessando outro servidor. Partindo desta premissa, possvel definir no Coda File System em qual servidor o cliente estabelecer acesso para a realizao dos experimentos. No Network File System, a identificao do servidor que o usurio estabelecer conexo informada no processo de criao do ponto de montagem, a exemplo da Figura 4.7.

Figura 4.7 Processo de conexo com o servio do Network File System Fonte: Imagem do Autor

Sabendo em quais servidores ambos os clientes estabelecero acesso, pode-se iniciar a aplicao do experimento. Conforme mencionado na Seo 4.3.1, este cenrio se resume na execuo de um comando similar ao proposto na Figura 4.3 e na anlise do comportamento das ferramentas. A Figura 4.8 ilustra a chamada deste procedimento no cliente do Coda File System e o resultado obtido aps sua execuo. Devido ao fato do cliente do Coda File System possuir um cache que oferece o suporte a operaes desconectadas, o que poderia invalidar este experimento, sentiu-se a necessidade de averiguar no segundo servidor a existncia do arquivo criado. possvel perceber na Figura 4.8 que a conexo do cliente foi migrada, de forma transparente, para um segundo servidor pertencente a clula em que se estabeleceu conexo, mascarando assim a falha ocorrida. O resultado da aplicao deste cenrio no Network File System ilustrado na Figura 4.9. Percebe-se que, diferente do Coda File System, o Network File System no migrou a

67

conexo do cliente para um servidor que estivesse disponvel para atend-lo, sendo necessrio recriar o ponto de montagem apontando-o para um segundo servidor pertencente a poltica de replicao. Acredita-se que esta limitao caracterizada pela ausncia de um espao de nomes globais na arquitetura do Network File System, entretanto, algumas pesquisas vem sendo desenvolvidas propondo a implementao deste recurso (ZHANG, 2003).

Figura 4.8 Resultado obtido com a experimentao no Coda File System Fonte: Imagem do Autor

Figura 4.9 Resultado obtido com a experimentao no Network File System Fonte: Imagem do Autor

68

Na Seo 3.1.5 e na especificao do protocolo da verso 4 do Network File System mencionado a abordagem a ser utilizada quando ocorrerem falhas de acesso a servidores replicados, entretanto, esta especificao aparenta no estar implementada (FIELDS, 2006). Com os resultados obtidos neste cenrio pode-se concluir que o Network File System possui uma baixa transparncia de replicao, pois apesar da ferramenta possibilitar que mais de uma instncia do recurso seja utilizada para aumentar a confiabilidade do servio, esta s pode ser acessada mediante conhecimento prvio da rplica pelo cliente, diferente do Coda File System, que neste cenrio obteve uma alta transparncia de replicao por ter migrado a conexo do cliente para a segunda instncia da rplica do servio aps a ocorrncia de falha. 4.6.2 Transparncia de Acesso A aplicao do cenrio para identificar o grau da transparncia de acesso nos sistemas de arquivos distribudos analisados foi bem sucedida em ambas as ferramentas, no havendo a necessidade de modificar os programas utilizados nos experimentos para permitir que eles funcionassem corretamente com os arquivos remotos. A Figura 4.10 exemplifica a chamada do comando proposto sendo executado no Network File System para identificar a existncia da transparncia de acesso. Sua execuo exibe na tela nmeros de 1 at 500.

Figura 4.10 Chamada do comando proposto para identificar a transparncia de acesso Fonte: Imagem do Autor

Devido ao fato de no terem ocorrido excees na execuo do comando (a Figura 4.11 ilustra o trmino do processamento) concluiu-se que o grau da transparncia de acesso em ambas as ferramentas estudadas alto.

Figura 4.11 Fim do processamento do comando proposto para identificar a transparncia de acesso Fonte: Imagem do Autor

69

Acredita-se que o resultado no sucesso desse experimento deu-se devido ao fato das ferramentas analisadas fazerem uso em sua arquitetura da interface VFS, possibilitando que chamadas de sistemas genricas (como open() e read()) possam ser executadas independente do sistema de arquivos usado ou do meio fsico. 4.6.3 Transparncia de Localizao Os sistemas de arquivos distribudos selecionados impossibilitaram a construo do ambiente proposto na Seo 4.3.3. A possibilidade de elaborar um cenrio similar ao proposto neste trabalho questionada na lista de discusso do Coda File System, onde mantenedores do projeto comentam da sua inviabilidade (HARKES, 1999; TROXEL, 2007). Algumas alternativas similares so sugeridas (HARKES, 1999) e poderiam ser implementadas em ambas as ferramentas, mas invalidariam o resultado. Apesar deste imprevisto e baseando-se na experincia obtida com a aplicao do cenrio da transparncia de replicao e da transparncia de acesso, pode-se concluir que o Network File System possui uma baixa transparncia de localizao, enquanto que o Coda File System possui uma alta transparncia de localizao. Esta afirmativa leva em considerao o sucesso obtido nos experimentos da transparncia de replicao com o Coda File System. O fato da conexo do cliente ter sido migrada para outro servidor sem a percepo do cliente quando foi simulada a falha de um dos nodos demonstra a transparncia que se obteve nesse processo, que se assemelha, de certa forma, ao caso proposto na Seo 4.3.3. No Network File System, a baixa transparncia de localizao tambm identificada pelo fato do cliente ter que especificar no processo de montagem o nome do servidor que armazena os arquivos, uma vez que a arquitetura da ferramenta no disponibiliza um espao de nomes globais. Como mencionado na Seo 1.1.6, a transparncia de localizao deve possibilitar o acesso ao recurso pelo usurio sem que este tenha que se preocupar com sua localizao na rede. Assim como para o problema de migrao da sesso do cliente ocorrido no experimento da transparncia de replicao, propostas para implementar transparncia de localizao na verso 4 do Network File System vem sendo discutidas e desenvolvidas (ZHANG, 2003).

70

4.6.4 Testes de Desempenho Conforme j mencionado na Seo 4.4, todos os testes de desempenho partiram de um mesmo computador que possua instalado, alm da ferramenta de benchmark, o cliente do sistema de arquivos distribudo que estava em avaliao. Objetivando obter resultados exatos para uma comparao eqitativa entre os sistemas de arquivos, teve-se a preocupao em considerar trs fatores antes da realizao das simulaes, que poderiam contribuir para a apresentao de resultados incorretos: o uso do cache na estao cliente, o tamanho dos blocos das parties e o tamanho dos blocos de dados enviados entre o cliente e o servidor atravs da rede. O IOzone possibilita a realizao de benchmark simulando mais de uma thread ou processo simultaneamente (CILIENDO, 2007), proporcionando mensurar o desempenho na manipulao de arquivos de forma concorrente. Entretanto, para fazer uso desta funcionalidade, deve-se empregar o parmetro -I na invocao da ferramenta, que invalida a utilizao do cache no computador cliente, garantindo assim que todas as operaes sejam realizadas no disco rgido (CILIENDO, 2007). Nos ensaios realizados, no foi possvel fazer uso deste parmetro em um ponto de montagem do Coda File System, pois os arquivos criados pelo IOzone durante os testes eram estabelecidos como somente-leitura, permitindo seu acesso apenas pela ferramenta de benchmark (HARKES, 2007) e o impossibilitando para o cliente do sistema de arquivos distribudo, que apresentava erros constantes negando seu acesso a ele, o que impedia a concluso do processo. Este problema no se refletiu durante os ensaios com o Network File System, mas mesmo assim, optou-se por no fazer uso deste parmetro na avaliao das ferramentas, acarretando a busca por uma alternativa que pudesse ser aplicada em ambas as solues. Devido a estes contratempos, definiu-se que o benchmark seria realizado com a execuo de apenas um processo e entre os testes com os sistemas de arquivos, a estao cliente seria reinicializada, evitando assim a utilizao do cache. Outras duas preocupaes que surgiram antes da realizao das simulaes foi quanto ao tamanho dos blocos da partio dos computadores, que neste experimento eram de 4 KB, e o tamanho dos blocos de informaes enviados entre o cliente e o servidor. A

71

proposta inicial era de simular, tanto no sistema de arquivos local quanto nos sistemas de arquivos distribudos, a gravao de arquivos em blocos de 4 KB. Entretanto, este ensaio no foi bem sucedido no Coda File System, que apresentava time-out no cliente quando era solicitado ao IOzone a manipulao de arquivos demasiadamente grandes simulando a utilizao de blocos de dados pequenos. Assim, optou-se por simular a gravao em blocos de dados de 10 MB em sistemas de arquivos distribudos, deixando assim a prpria ferramenta gerenciar o tamanho das mensagens a serem enviadas, e blocos de dados de 4 KB para sistema de arquivos local, uma vez que este era o tamanho em que as parties estavam formatadas. A linha de comando utilizada para mensurar o desempenho do sistema de arquivos local apresentada na Figura 4.12, e a linha de comando utilizada para mensurar o desempenho dos sistemas de arquivos distribudos apresentada na Figura 4.13.

iozone -c -t 1 -F /tmp/ -i 0 -i 1 -r 4k -s 1g
Figura 4.12 Chamada do IOzone utilizada em sistemas de arquivos locais Fonte: Imagem do Autor

iozone -c -t 1 -F /mnt/ -i 0 -i 1 -r 10m -s 1g

Figura 4.13 Chamada do IOzone utilizada em sistemas de arquivos distribudos Fonte: Imagem do Autor

A Figura 4.14 apresenta o ambiente utilizado para a realizao dos testes de desempenho que possua, alm da estao cliente, apenas um servidor oferecendo o servio de armazenamento distribudo sem o recurso de replicao. Todos os testes realizados simularam a manipulao de arquivos no tamanho de 1 GB.

Figura 4.14 Laboratrio utilizado para a realizao dos benchmarks Fonte: Imagem do Autor

72

A fim de identificar possveis divergncias nos resultados, foi mensurado primeiramente a performance do sistema de arquivos local com blocos no tamanho de 4 KB e 10 MB. A Figura 4.15 ilustra o resultado obtido.

Desempenho do sistema de arquivos local (Ext3) com blocos de tamanhos distintos

Taxa de transferncia em Kbytes/s

17000 16500 16000 15500 15000 14500 14000 Escrita Reescrita Leitura Releitura Teste realizado 4 KB 10 MB

Figura 4.15 Comparativo de desempenho do sistema de arquivos local com blocos de tamanhos distintos Fonte: Imagem do Autor

Devido a pequena diferena gerada, os grficos a seguir representaro a performance obtida com o sistema de arquivos Ext3 formatado em blocos no tamanho de 4 KB. A Figura 4.16 ilustra o primeiro comparativo realizado entre os sistemas de arquivos distribudos e o sistema de arquivos local.

Benchmark entre Sistemas de Arquivos

18000 16000 14000 12000 10000 8000 6000 4000 2000 0 Escrita Reescrita Leitura Releitura Teste realizado
Taxa de transferncia em Kbytes/s

Ext3 NFS Coda

Figura 4.16 Comparativo de desempenho entre os sistemas de arquivos Fonte: Imagem do Autor

A segunda comparao de performance realizada simulou um ambiente com excessivo trfego na rede com o auxlio do Netperf (CILIENDO, 2007). O Netperf uma ferramenta de benchmark para anlise de trfego em redes e sua arquitetura baseada no

73

modelo cliente-servidor, possibilitando ao utilizador determinar a quantidade de tempo para a transferncia de certa quantia de dados entre os computadores (CILIENDO, 2007). Os parmetros utilizados na chamada do Netperf so apresentados na Tabela 4.9.
Tabela 4.9 Parmetros utilizados na chamada do Netperf

-p

Define o nmero da porta a ser utilizado.

-H

Especifica o nome ou endereo IP do computador remoto.

Define o tipo de teste de trfego a ser utilizado. Neste trabalho -t ser utilizado o TCP_RR, que simula o trfego de envio e recebimento medido pelo nmero de transaes trocadas em segundos entre os nodos.

-r

Especifica (em Kbytes) o tamanho do pacote de envio e recebimento.

Fonte: Tabela do Autor

Para a realizao deste ensaio, foi includo um terceiro computador no diagrama apresentado na Figura 4.14. Este computador ficou como responsvel pela gerao do trfego excessivo na rede, sendo nele executada a linha de comando apresentada na Figura 4.18. Devido a arquitetura do Netperf ser baseada no modelo cliente-servidor, foi necessrio instalar a verso cliente desta ferramenta em outro computador. Assim sendo, optou-se em instalar-la no computador cliente do sistema de arquivos distribudo e executar a linha de comando apresentada na Figura 4.17. Para garantir sua constante execuo, a chamada do Netperf foi incorporada dentro de um lao de execuo, conforme ilustrado na Figura 4.18.

netserver p 5001
Figura 4.17 Chamada do Netperf no cliente dos sistemas de arquivos distribudos Fonte: Imagem do Autor

74

for i in $(seq 100); do netperf -H 192.168.206.13 -p 5001 -t TCP_RR -- -r 20971520, 20971520; done
Figura 4.18 Chamada do Netperf no computador responsvel pela gerao do trfego Fonte: Imagem do Autor

Enquanto o Netperf estava em execuo, o IOzone foi invocado no computador cliente do sistema de arquivos distribudo fazendo-se uso da linha de comando apresentada na Figura 4.13. Os resultados obtidos com este teste so ilustrados na Figura 4.19.

Comparativo entre os sistemas de arquivos distribudos durante trfego intenso na rede

Taxa de transferncia em Kbytes/s
6000 5000 4000 3000 2000 1000 0 Escrita Reescrita Leitura Releitura Teste realizado NFS Coda

Figura 4.19 Comparativo de desempenho entre os sistemas de arquivos distribudos durante o trfego intenso na rede Fonte: Imagem do Autor

A Figura 4.20 ilustra o percentual de perda de performance entre as ferramentas em relao as duas simulaes.

Percentual de perda de desempenho entre os sistemas de arquivos distribudos

80,00 70,00 60,00 50,00 40,00 30,00 20,00 10,00 0,00 65,73 53,46 71,39 47,99 54,43 39,23 24,61 54,93 NFS Coda

Percentual

Escrita

Reescrita

Leitura

Releitura

Teste realizado

Figura 4.20 Percentual de perda de desempenho entre os sistemas de arquivos distribudos Fonte: Imagem do Autor

75

Percebe-se que o Coda File System obteve uma perda de performance inferior ao Network File System nos testes de escrita e reescrita, e uma perda superior nos testes de leitura e releitura. Acredita-se que esse comportamento resultado da arquitetura de compartilhamento das ferramentas. Quando o usurio abre um determinado arquivo com sucesso no Coda File System, este transferido integralmente ao computador cliente para que todas as operaes sejam realizadas em cache, o que justifica o baixo percentual da perda de performance nos processos de escrita e reescrita em relao ao Network File System, e aps seu fechamento, o arquivo transferido ao servidor novamente, diferente do Network File System, onde todas as operaes so realizadas diretamente no servidor (TANENBAUM, 2002). 4.7 Dificuldades Encontradas

Um dos objetivos deste trabalho era identificar o grau da transparncia de replicao, transparncia de acesso e transparncia de localizao existente em sistemas de arquivos distribudos. Para o cumprimento deste objetivo foi necessrio a elaborao de cenrios em que, dependendo do resultado obtido com sua aplicabilidade, possibilitasse classificar o grau da transparncia dos sistemas de arquivos distribudos em alto ou baixo. Por no existirem pesquisas anteriores com este foco, diversos questionamentos e dvidas foram levantados durante a elaborao destes cenrios quanto a real eficincia deles. Outro ponto que prejudicou o andamento do trabalho foi a carncia de documentao ou a sua desatualizao. O Network File System, em sua verso 3, uma ferramenta amplamente difundida, presente em grande parte das distribuies do Sistema Operacional Linux e com uma vasta documentao em livros e artigos. Entretanto, a verso 3 no contempla o suporte a replicao de arquivos, sendo necessrio para este trabalho fazer uso da verso 4, que ainda possui poucas referncias de consulta. Por outro lado, o Coda File System possui uma vasta documentao do projeto em seu Site que infelizmente encontrasse desatualizada, tanto em termos de procedimentos para sua instalao quanto em termos de arquitetura e funcionalidades do sistema (HARKES, 2005; JOHNSON, 2007). A escassez e a descontinuao de projetos desta rea de pesquisa, a exemplo do InterMezzo (INTERMEZZO, 2007), tambm dificultou a escolha das ferramentas a serem estudadas, uma vez que um dos critrios para a seleo era o fato do projeto estar em desenvolvimento.

76

4.8

Trabalhos Futuros

Durante a realizao desta monografia, foram observados vrios aspectos que podem estender ou melhorar esse trabalho futuramente. O primeiro diz respeito elaborao de mtricas que possam identificar o grau da transparncia das demais tcnicas no citadas neste trabalho, alm de uma possvel melhoria nas mtricas aqui desenvolvidas. Outro aspecto refere-se a realizao de testes de desempenho mais precisos e amplos, mensurando o uso de memria e de processamento que os sistemas de arquivos distribudos consomem, tanto no cliente quanto no servidor, realizando um comparativo com os sistemas de arquivos locais. Como complemento para esta sugesto, a simulao de trfego intenso na rede durante o processo de manipulao de arquivos grandes pode servir como artefato para identificar protocolos mal formados devido a possveis problemas de especificao ou implementao. Tambm fica como proposta para trabalhos futuros a realizao dos experimentos acima em sistemas de arquivos distribudos no apresentados neste trabalho. Outras pesquisas, tambm na rea de armazenamento distribudo, podem dar origem a novos trabalhos, como o estudo de Sistemas de Arquivos Paralelos (CARVALHO, 2003) e Data Grids (TAURION, 2004). Todos esses levantamentos no fizeram parte deste trabalho e ficam como inspirao para trabalhos futuros. Alguns desses itens no foram abordados no trabalho para que este no ficasse demasiadamente extenso e outros devido ao desconhecimento do autor nesta rea de pesquisa antes da realizao deste trabalho.

CONSIDERAES FINAIS

O objetivo deste trabalho foi o estudo de conceitos, desafios e problemas gerados com a implementao de sistemas distribudos e sistemas de arquivos distribudos, abordando uma pesquisa por ferramentas que fornecessem este servio. Os grandes benefcios oferecidos pelo armazenamento distribudo vm motivando e fomentando grupos de pesquisas em Universidades e empresas de grande porte, que investem no desenvolvimento de novas tcnicas e melhorias para o aperfeioamento destas solues. Diversas ferramentas experimentais foram desenvolvidas nos ltimos anos, cada uma delas com uma finalidade especfica e com muitas exigncias contraditrias. Entretanto, apesar da existncia de inmeras solues para proporcionar este servio, diversos assuntos e desafios existentes na implementao de sistemas distribudos permanecem problemticos, como a exemplo da transparncia. Assim sendo, a segunda etapa deste trabalho teve como objetivo identificar o grau da transparncia de replicao, transparncia de acesso e transparncia de localizao existente nos sistemas de arquivos distribudos, uma vez que a presena ou ausncia destas tcnicas afetam fortemente a utilizao de recursos distribudos. Para tanto, foram propostos cenrios que tinham como objetivo identificar o grau da transparncia, classificado em alto e baixo, destas tcnicas. Nestes cenrios, os clientes de uma rede usufruram do servio de armazenamento distribudo oferecido pelas ferramentas Coda File System e Network File System. Como resultado desta experimentao, foi constatado que ambas as ferramentas possuam um alto grau de transparncia de acesso e que o Network File System possua uma baixa transparncia de localizao e replicao, enquanto que o Coda File System possua uma alta transparncia de localizao e replicao.

78

Alm dos experimentos acima citados, foram realizados benchmarks para mensurar o desempenho dos sistemas de arquivos distribudos nos processos de escrita, reescrita, leitura e releitura de arquivos, sendo que o resultado obtido foi reflexo de suas arquiteturas. Devido ao suporte a cache existente no cliente do Coda File System, o que possibilita a manipulao de arquivos no computador local, este obteve uma taxa de transferncia superior ao Network File System, que realiza operaes diretamente nos arquivos armazenados no servidor, fazendo uso constante da rede. Entretanto, os ensaios demonstraram uma perda de performance maior no Coda File System durante a leitura e releitura de arquivos em uma rede com excessivo trfego, uma vez que, aps o acesso ao arquivo, este transferido integralmente ao computador local. Ao final deste trabalho concluiu-se que os sistemas de arquivos distribudos representam um avano em relao ao armazenamento de dados. As ferramentas atualmente existentes no abrangem todo o espectro de um sistema gerenciador de arquivos distribudos mencionado em bibliografias, principalmente devido a dificuldade em se resolver grandes desafios da rea de sistemas distribudos, entretanto, vrios avanos foram feitos nos ltimos anos, sendo possvel encontrar sistemas de arquivos distribudos sendo utilizados em ambientes de produo. Esta uma rea de pesquisa bastante promissora, sendo seu potencial demonstrado no investimento realizado por empresas de renome, e as lacunas hoje existentes nas ferramentas de armazenamento distribudos proporcionam a realizao e continuao de diversos trabalhos nesta rea.

REFERNCIAS BIBLIOGRFICAS

ADYA, Atul et. al. Farsite: federated, available, and reliable storage for an incompletely trusted environment. In: ACM SIGOPS OPERATING SYSTEMS REVIEW, 36., 2002, New York. Anais... New York: ACM Press, 2002. p. 1-14. BECK, Micah; MOORE, Terry; PLANK, James S. An end-to-end approach to globally scalable programmable networking. In: ACM SIGCOMM WORKSHOP ON FUTURE DIRECTIONS IN NETWORK ARCHITECTURE, 2003, New York. Anais... New York: ACM Press, 2003, p. 328-339. BEINSYNC. BeInSync. Disponvel em: <http://www.beinsync.com/>. Acesso em: 11 Jun. 2007. BRAAM, Peter J. The Coda Distributed File System. Linux Journal, Seattle, v. 1998, n. 50es, 6 p., Jun. 1998. CARVALHO, Roberto Pires de. Sistemas de Arquivos Paralelos e Distribudos. So Paulo: 2003. 75 p. Tese (Mestrado em Cincia da Computao) - Instituto de Matemtica e Estatstica, Universidade de So Paulo, 2003. CHOW, Randy; JOHNSON, Theodore. Distributed operating systems and algorithms. Reading, Massachusetts: Addison Wesley Longman, 1998. 569 p. CILIENDO, Eduardo; KUNIMASA, Takechika. Linux Performance and Tuning Guidelines. IBM Press, 2007. 170 p. COULOURIS, George; DOLLIMORE, Jean; KINDBERG, Tim. Distributed systems: concepts and design. 4. ed. Harlow: Addison Wesley Longman, 2005. 927 p.

80

DABEK, Frank et al. Wide-area cooperative storage with CFS. In: ACM SYMPOSIUM ON OPERATING SYSTEMS PRINCIPLES, 18., 2001, New York. Anais... New York: ACM Press, 2001. p. 202-215. FIELDS, Bruce J. Sanity check. NFS Mailing Lists, 14 Abr. 2006. Disponvel em: <http://linux-nfs.org/pipermail/nfsv4/2006-April/004130.html>. Acesso em: 11 Jun. 2007. FOLDERSHARE. FolderShare. Disponvel em: <http://www.foldershare.com/>. Acesso em: 11 Jun. 2007. GALLI, Doreen L. Distributed Operating Systems: Concepts and Practice. New Jersey: Prentice Hall, 2000. 463 p. GHEMAWAT, Sanjay; GOBIOFF, Howard; LEUNG, Shun-Tak. The Google File System. In: ACM SYMPOSIUM ON OPERATING SYSTEMS PRINCIPLES, 19., 2003, New York. Anais... New York: ACM Press, 2003. p. 29-43. HARKES, Jan. Re: Multiple coda servers. Coda Mailing Lists, 11 Set. 1999. Disponvel em: <http://www.coda.cs.cmu.edu/maillists/codalist/codalist-1999/1749.html>. Acesso em: 11 Jun. 2007. HARKES, Jan. Re: what a realm is exactly? Coda Mailing Lists, 28 Out. 2004. Disponvel em: <http://www.coda.cs.cmu.edu/maillists/codalist/codalist-2004/6966.html>. Acesso em: 11 Jun. 2007. HARKES, Jan. Re: Q about the VSGDB file and referring to realms. Coda Mailing Lists, 26 Set. 2005. Disponvel em: <http://www.coda.cs.cmu.edu/maillists/codalist/codalist-

2005/7748.html>. Acesso em: 11 Jun. 2007. HARKES, Jan. Re: Iozone. Coda Mailing Lists, 29 Mai. 2007. Disponvel em: <http://www.coda.cs.cmu.edu/maillists/codalist/codalist-2007/8548.html>. Acesso em: 11 Jun. 2007. INTERMEZZO. InterMezzo File System. Disponvel em <http://www.inter-mezzo.org/>. Acesso em: 11 Jun. 2007. JALOTE, Pankaj. Fault Tolerance in Distributed Systems. New Jersey: Prentice Hall, 1994. 432 p.

81

JOHNSON, Alastair. Re: discrepancies in coda documentation. Coda Mailing Lists, 24 Mai. 2007. Disponvel em: <http://coda.cs.cmu.edu/maillists/codalist/codalist-2007/8529.html> Acesso em: 11 Jun. 2007. KIRNER, Claudio; MENDES, Sueli B. T. Sistemas operacionais distribudos: aspectos gerais e anlise de sua estrutura. Rio de Janeiro: Campus, 1988. 184 p. KISTLER, James J.; SATYANARAYANAN M. Disconnected operation in the Coda file system. In: ACM SYMPOSIUM ON OPERATING SYSTEMS PRINCIPLES, 13., 1991, New York. Anais... New York: ACM Press, 1991, p. 213-225. KON, Fabio. Distributed File Systems Past, Present and Future. 1996. KON, Fabio. Sistemas de Arquivos Distribudos. So Paulo: 1994. 154 p. Tese (Mestrado em Matemtica Aplicada) - Instituto de Matemtica e Estatstica, Universidade de So Paulo, 1994. MACHADO, Francis Berenger; MAIA, Luiz Paulo. Arquitetura de sistemas operacionais. 3. ed. Rio de Janeiro: LTC, 2002. 311 p. MEDIAMAX. MediaMax. Disponvel em: <http://www.mediamax.com/>. Acesso em: 11 Jun. 2007. MULLENDER, Sape. Distributed systems. 2. ed. New York: ACM Press/Addison-Wesley Publishing Co., 1993. 595 p. NOTKIN, David et al. Heterogeneous computing environments: report on the ACM SIGOPS workshop on accommodating heterogeneity. Commun. ACM, ACM Press, v. 30, n. 2, p. 132-140, Fev. 1987. RIBEIRO, Uir Endy. Sistemas Distribudos: Desenvolvendo Aplicaes de Alta Performace no Linux. Rio de Janeiro: Axcel Books do Brasil, 2005. 384 p. ROUSH, Wade. The Internet Is Your Next Hard Drive. Technology Review, 24 Jul. 2006. Disponvel em: <http://www.technologyreview.com/read_article.aspx?id=17195&ch=info

tech>. Acesso em: 11 Jun. 2007.

82

ROWSTRON, Antony; DRUSCHEL, Peter. Storage management and caching in PAST, a large-scale, persistent peer-to-peer storage utility. In: ACM SYMPOSIUM ON OPERATING SYSTEMS PRINCIPLES, 18., 2001, New York. Anais... New York: ACM Press, 2001, p. 188-201. SIEWIOREK, Daniel P. Architecture of Fault-Tolerant Computers. Computer, IEEE Computer Society, v. 17, n. 8, p. 9-18, Ago. 1984. SILBERSCHATZ, Abraham; GALVIN, Peter B.; GAGNE, Greg. Applied Operating System Concepts. New York: John Wiley & Sons, 2000. 840 p. SINGHAL, Mukesh; SHIVARATRI, Niranjan G. Advanced concepts in operating systems: distributed, database, and multiprocessor operating systems. Nova York: McGraw-Hill, 1994. 522 p. SINHA, Pradeep K. Distributed Operating Systems: Concepts and Design. New York: Wiley-IEEE Press, 1996. 764 p. SPECTOR, Alfred Zalmon. Multiprocessing architectures for local computer networks. Stanford: 1981. 127 p. Tese (Doutorado em Cincia da Computao) - Departamento de Cincia da Computao, Universidade de Stanford, 1981. TANENBAUM, Andrew S. Computer Networks. New Jersey: Prentice Hall, 2003. 384 p. TANENBAUM, Andrew S.; WOODHULL, Albert S. Operating Systems Design and Implementation. 3. ed. New Jersey: Prentice Hall, 2006. 1080 p. TANENBAUM, Andrew S.; STEEN, Maarten van. Distributed Systems: Principles and Paradigms. New Jersey: Prentice Hall, 2002. 803 p. TAURION, Cezar. Grid computing: um novo paradigma computacional. Rio de Janeiro: Brasport, 2004. 146 p. TROXEL, Greg. Re: Adding space to a server. Coda Mailing Lists, 18 Mai. 2007. Disponvel em: <http://www.coda.cs.cmu.edu/maillists/codalist/codalist-2007/8493.html>. Acesso em: 11 Jun. 2007.

83

VERISSIMO, Paulo; RODRIGUES, Luis. Distributed Systems for System Architects. Norwell: Kluwer Academic Publishers, 2001. 623 p. WOHLIN, Claes et. al. Experimentation in Software Engineering: An Introduction. Norwell: Kluwer Academic Publishers, 2000. 204 p. ZHANG, Jiaying; HONEYMAN, Peter. Naming, Migration, and Replication in NFSv4. 2003. Disponvel em: <http://citeseer.ist.psu.edu/636612.html>. Acesso em: 11 Jun. 2007.

ANEXOS

85

ANEXO A
Resultado obtido com o IOzone aps a realizao dos testes de escrita, reescrita, leitura e releitura no sistema de arquivos Ext3 simulando a manipulao de arquivos no tamanho de 1 GB e blocos no tamanho de 4 KB.
Iozone: Performance Test of File I/O Version $Revision: 3.263 $ Compiled for 32 bit mode. Build: linux Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins Al Slater, Scott Rhine, Mike Wisner, Ken Goss Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR, Randy Dunlap, Mark Montague, Dan Million, Jean-Marc Zucconi, Jeff Blomberg, Erik Habbinga, Kris Strecker, Walter Wong. Run began: Wed May 30 15:29:29 2007 Include close in write timing Record Size 4 KB File size set to 1048576 KB O_DIRECT feature enabled Command line used: iozone -c -t 1 -F /tmp/ -i 0 -i 1 -r 4k -s 1g Output is in Kbytes/sec Time Resolution = 0.000001 seconds. Processor cache size set to 1024 Kbytes. Processor cache line size set to 32 bytes. File stride size set to 17 * record size. Throughput test with 1 process Each process writes a 1048576 Kbyte file in 4 Kbyte records Children see throughput for 1 initial writers Parent sees throughput for 1 initial writers Min throughput per process Max throughput per process Avg throughput per process Min xfer Children see throughput for 1 rewriters Parent sees throughput for 1 rewriters Min throughput per process Max throughput per process Avg throughput per process Min xfer Children see throughput for 1 readers Parent sees throughput for 1 readers Min throughput per process Max throughput per process Avg throughput per process Min xfer Children see throughput for 1 re-readers Parent sees throughput for 1 re-readers Min throughput per process Max throughput per process Avg throughput per process Min xfer iozone test complete. = 15031.65 = 15031.31 = 15031.65 = 15031.65 = 15031.65 = 1048576.00 = 15420.41 = 15419.55 = 15420.41 = 15420.41 = 15420.41 = 1048576.00 = 16820.97 = 16819.94 = 16820.97 = 16820.97 = 16820.97 = 1048576.00 = 16810.84 = 16809.80 = 16810.84 = 16810.84 = 16810.84 = 1048576.00 KB/sec KB/sec KB/sec KB/sec KB/sec KB KB/sec KB/sec KB/sec KB/sec KB/sec KB KB/sec KB/sec KB/sec KB/sec KB/sec KB KB/sec KB/sec KB/sec KB/sec KB/sec KB

86

ANEXO B
Resultado obtido com o IOzone aps a realizao dos testes de escrita, reescrita, leitura e releitura no Network File System simulando a manipulao de arquivos no tamanho de 1 GB e blocos no tamanho de 10 MB.
Iozone: Performance Test of File I/O Version $Revision: 3.263 $ Compiled for 32 bit mode. Build: linux Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins Al Slater, Scott Rhine, Mike Wisner, Ken Goss Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR, Randy Dunlap, Mark Montague, Dan Million, Jean-Marc Zucconi, Jeff Blomberg, Erik Habbinga, Kris Strecker, Walter Wong. Run began: Wed May 30 07:26:42 2007 Include close in write timing Record Size 10240 KB File size set to 1048576 KB Command line used: iozone -c -t 1 -F /mnt/ -i 0 -i 1 -r 10m -s 1g Output is in Kbytes/sec Time Resolution = 0.000001 seconds. Processor cache size set to 1024 Kbytes. Processor cache line size set to 32 bytes. File stride size set to 17 * record size. Throughput test with 1 process Each process writes a 1048576 Kbyte file in 10240 Kbyte records Children see throughput for 1 initial writers Parent sees throughput for 1 initial writers Min throughput per process Max throughput per process Avg throughput per process Min xfer Children see throughput for 1 rewriters Parent sees throughput for 1 rewriters Min throughput per process Max throughput per process Avg throughput per process Min xfer Children see throughput for 1 readers Parent sees throughput for 1 readers Min throughput per process Max throughput per process Avg throughput per process Min xfer Children see throughput for 1 re-readers Parent sees throughput for 1 re-readers Min throughput per process Max throughput per process Avg throughput per process Min xfer iozone test complete. = 625.01 = 623.43 = 625.01 = 625.01 = 625.01 = 1048576.00 = 763.43 = 761.34 = 763.43 = 763.43 = 763.43 = 1048576.00 = 808.58 = 806.99 = 808.58 = 808.58 = 808.58 = 1048576.00 = 800.26 = 798.74 = 800.26 = 800.26 = 800.26 = 1048576.00 KB/sec KB/sec KB/sec KB/sec KB/sec KB KB/sec KB/sec KB/sec KB/sec KB/sec KB KB/sec KB/sec KB/sec KB/sec KB/sec KB KB/sec KB/sec KB/sec KB/sec KB/sec KB

87

ANEXO C
Resultado obtido com o IOzone aps a realizao dos testes de escrita, reescrita, leitura e releitura no Coda File System simulando a manipulao de arquivos no tamanho de 1 GB e blocos no tamanho de 10 MB.
Iozone: Performance Test of File I/O Version $Revision: 3.263 $ Compiled for 32 bit mode. Build: linux Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins Al Slater, Scott Rhine, Mike Wisner, Ken Goss Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR, Randy Dunlap, Mark Montague, Dan Million, Jean-Marc Zucconi, Jeff Blomberg, Erik Habbinga, Kris Strecker, Walter Wong. Run began: Wed May 30 18:36:30 2007 Include close in write timing Record Size 10240 KB File size set to 1048576 KB Command line used: iozone -c -t 1 -F /coda/codaserver/ -i 0 -i 1 -r 10m -s 1g Output is in Kbytes/sec Time Resolution = 0.000001 seconds. Processor cache size set to 1024 Kbytes. Processor cache line size set to 32 bytes. File stride size set to 17 * record size. Throughput test with 1 process Each process writes a 1048576 Kbyte file in 10240 Kbyte records Children see throughput for 1 initial writers Parent sees throughput for 1 initial writers Min throughput per process Max throughput per process Avg throughput per process Min xfer Children see throughput for 1 rewriters Parent sees throughput for 1 rewriters Min throughput per process Max throughput per process Avg throughput per process Min xfer Children see throughput for 1 readers Parent sees throughput for 1 readers Min throughput per process Max throughput per process Avg throughput per process Min xfer Children see throughput for 1 re-readers Parent sees throughput for 1 re-readers Min throughput per process Max throughput per process Avg throughput per process Min xfer iozone test complete. = 7589.45 = 6973.74 = 7589.45 = 7589.45 = 7589.45 = 1048576.00 = 8451.69 = 7498.81 = 8451.69 = 8451.69 = 8451.69 = 1048576.00 = 10358.03 = 9797.49 = 10358.03 = 10358.03 = 10358.03 = 1048576.00 = 10826.63 = 10651.36 = 10826.63 = 10826.63 = 10826.63 = 1048576.00 KB/sec KB/sec KB/sec KB/sec KB/sec KB KB/sec KB/sec KB/sec KB/sec KB/sec KB KB/sec KB/sec KB/sec KB/sec KB/sec KB KB/sec KB/sec KB/sec KB/sec KB/sec KB

88

ANEXO D
Resultado obtido com o IOzone aps a realizao dos testes de escrita, reescrita, leitura e releitura no sistema de arquivos Ext3 simulando a manipulao de arquivos no tamanho de 1 GB e blocos no tamanho de 10 MB.
Iozone: Performance Test of File I/O Version $Revision: 3.263 $ Compiled for 32 bit mode. Build: linux Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins Al Slater, Scott Rhine, Mike Wisner, Ken Goss Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR, Randy Dunlap, Mark Montague, Dan Million, Jean-Marc Zucconi, Jeff Blomberg, Erik Habbinga, Kris Strecker, Walter Wong. Run began: Sun Jun 3 15:34:39 2007

Include close in write timing Record Size 10240 KB File size set to 1048576 KB Command line used: iozone -c -t 1 -F /tmp/ -i 0 -i 1 -r 10m -s 1g Output is in Kbytes/sec Time Resolution = 0.000001 seconds. Processor cache size set to 1024 Kbytes. Processor cache line size set to 32 bytes. File stride size set to 17 * record size. Throughput test with 1 process Each process writes a 1048576 Kbyte file in 10240 Kbyte records Children see throughput for 1 initial writers Parent sees throughput for 1 initial writers Min throughput per process Max throughput per process Avg throughput per process Min xfer Children see throughput for 1 rewriters Parent sees throughput for 1 rewriters Min throughput per process Max throughput per process Avg throughput per process Min xfer Children see throughput for 1 readers Parent sees throughput for 1 readers Min throughput per process Max throughput per process Avg throughput per process Min xfer Children see throughput for 1 re-readers Parent sees throughput for 1 re-readers Min throughput per process Max throughput per process Avg throughput per process Min xfer iozone test complete. = 15143.53 = 15142.85 = 15143.53 = 15143.53 = 15143.53 = 1048576.00 = 15311.27 = 15311.11 = 15311.27 = 15311.27 = 15311.27 = 1048576.00 = 16706.31 = 16705.65 = 16706.31 = 16706.31 = 16706.31 = 1048576.00 = 16700.94 = 16700.28 = 16700.94 = 16700.94 = 16700.94 = 1048576.00 KB/sec KB/sec KB/sec KB/sec KB/sec KB KB/sec KB/sec KB/sec KB/sec KB/sec KB KB/sec KB/sec KB/sec KB/sec KB/sec KB KB/sec KB/sec KB/sec KB/sec KB/sec KB

89

ANEXO E
Resultado obtido com o IOzone aps a realizao dos testes de escrita, reescrita, leitura e releitura no Coda File System simulando a manipulao de arquivos no tamanho de 1 GB e blocos no tamanho de 10 MB com excessivo trfego na rede.
Iozone: Performance Test of File I/O Version $Revision: 3.263 $ Compiled for 32 bit mode. Build: linux Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins Al Slater, Scott Rhine, Mike Wisner, Ken Goss Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR, Randy Dunlap, Mark Montague, Dan Million, Jean-Marc Zucconi, Jeff Blomberg, Erik Habbinga, Kris Strecker, Walter Wong. Run began: Wed May 31 17:32:12 2007 Include close in write timing Record Size 10240 KB File size set to 1048576 KB Command line used: iozone -c -t 1 -F /coda/codaserver/ -i 0 -i 1 -r 10m -s 1g Output is in Kbytes/sec Time Resolution = 0.000001 seconds. Processor cache size set to 1024 Kbytes. Processor cache line size set to 32 bytes. File stride size set to 17 * record size. Throughput test with 1 process Each process writes a 1048576 Kbyte file in 10240 Kbyte records Children see throughput for 1 initial writers Parent sees throughput for 1 initial writers Min throughput per process Max throughput per process Avg throughput per process Min xfer Children see throughput for 1 rewriters Parent sees throughput for 1 rewriters Min throughput per process Max throughput per process Avg throughput per process Min xfer Children see throughput for 1 readers Parent sees throughput for 1 readers Min throughput per process Max throughput per process Avg throughput per process Min xfer Children see throughput for 1 re-readers Parent sees throughput for 1 re-readers Min throughput per process Max throughput per process Avg throughput per process Min xfer iozone test complete. = 3532.49 = 3389.86 = 3532.49 = 3532.49 = 3532.49 = 1048576.00 = 4395.91 = 4217.34 = 4395.91 = 4395.91 = 4395.91 = 1048576.00 = 4720.49 = 4495.18 = 4720.49 = 4720.49 = 4720.49 = 1048576.00 = 4879.97 = 4697.01 = 4879.97 = 4879.97 = 4879.97 = 1048576.00 KB/sec KB/sec KB/sec KB/sec KB/sec KB KB/sec KB/sec KB/sec KB/sec KB/sec KB KB/sec KB/sec KB/sec KB/sec KB/sec KB KB/sec KB/sec KB/sec KB/sec KB/sec KB

90

ANEXO F
Resultado obtido com o IOzone aps a realizao dos testes de escrita, reescrita, leitura e releitura no Network File System simulando a manipulao de arquivos no tamanho de 1 GB e blocos no tamanho de 10 MB com excessivo trfego na rede.
Iozone: Performance Test of File I/O Version $Revision: 3.263 $ Compiled for 32 bit mode. Build: linux Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins Al Slater, Scott Rhine, Mike Wisner, Ken Goss Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR, Randy Dunlap, Mark Montague, Dan Million, Jean-Marc Zucconi, Jeff Blomberg, Erik Habbinga, Kris Strecker, Walter Wong. Run began: Wed May 31 07:52:33 2007 Include close in write timing Record Size 10240 KB File size set to 1048576 KB Command line used: iozone -c -t 1 -F /mnt/ -i 0 -i 1 -r 10m -s 1g Output is in Kbytes/sec Time Resolution = 0.000001 seconds. Processor cache size set to 1024 Kbytes. Processor cache line size set to 32 bytes. File stride size set to 17 * record size. Throughput test with 1 process Each process writes a 1048576 Kbyte file in 10240 Kbyte records Children see throughput for 1 initial writers Parent sees throughput for 1 initial writers Min throughput per process Max throughput per process Avg throughput per process Min xfer Children see throughput for 1 rewriters Parent sees throughput for 1 rewriters Min throughput per process Max throughput per process Avg throughput per process Min xfer Children see throughput for 1 readers Parent sees throughput for 1 readers Min throughput per process Max throughput per process Avg throughput per process Min xfer Children see throughput for 1 re-readers Parent sees throughput for 1 re-readers Min throughput per process Max throughput per process Avg throughput per process Min xfer iozone test complete. = 214.21 = 213.88 = 214.21 = 214.21 = 214.21 = 1048576.00 = 218.41 = 217.92 = 218.41 = 218.41 = 218.41 = 1048576.00 = 491.41 = 489.71 = 491.41 = 491.41 = 491.41 = 1048576.00 = 603.30 = 587.73 = 603.30 = 603.30 = 603.30 = 1048576.00 KB/sec KB/sec KB/sec KB/sec KB/sec KB KB/sec KB/sec KB/sec KB/sec KB/sec KB KB/sec KB/sec KB/sec KB/sec KB/sec KB KB/sec KB/sec KB/sec KB/sec KB/sec KB