IBILCE - Instituto de Biociências, Letras e Ciências Exatas

Transcrição

1 Unesp IBILCE - Instituto de Biociências, Letras e Ciências Exatas Projeto e Implementação de Sistemas de Arquivos Grupo 14 Roger Souza de Paula Maurício Nigro Tronco Orientador: Prof. Dr. Norian Marranghello São José do Rio Preto, 05 de junho de 2002

2 SUMÁRIO 1. INTRODUÇÃO 1 2. CARACTERÍSTICAS DE UM SAD Arquivos Hierarquia 2 3. PROJETO E IMPLEMENTAÇÃO DE UM SAD Montagem de Arquivos Registro de Servidores Servidores Com ou Sem Informações de Estado Acesso a Arquivos Semânticas de Compartilhamento Controle de Versão REFERÊNCIAS 14

3 1. INTRODUÇÃO Um sistema computacional é uma coleção de processos operando em objetos de dados. Objetos de dados precisam ser armazenados em uma base para depois poderem ser recuperados. Eles devem ser nomeados e salvos em um dispositivo de armazenamento nãovolátil, como um disquete por exemplo. Assumimos que arquivos são objetos de dados básicos, e que suas estruturas internas e interpretação são deixadas para a implementação do sistema. Um sistema de arquivo, no qual seu maior componente é o sistema operacional, é responsável pelo nome, criação, exclusão, recuperação, modificação e proteção de todos os arquivos do sistema. Arquivos precisam ser compartilhados para facilitar o trabalho cooperativo e distribuídos para um grande número de locais em um sistema distribuído. Um Sistema de Arquivos Distribuídos (SAD) é a implementação de um sistema de arquivos que consiste em locais de armazenamentos distribuídos mas que provê o tradicional sistema de arquivos centralizado para os usuários. Então, a existência de arquivos cruzando o sistema deve ser transparente para o usuário. Muitos conceitos importantes no projeto de um sistema distribuído podem ser demonstrados pela implementação de um sistema de arquivos distribuído. Primeiro, SADs empregam bastante a idéia de transparência. Segundo, o serviço de diretório em um SAD é um bom exemplo de serviço de nome, um componente chave em todos sistemas distribuídos. Terceiro, a performance e disponibilidade requerem o uso de caching e replicação, caso contrário, pode levar à problemas de coerência de cache e gerenciamento de réplicas. Quarto, controle de acesso e proteção para SADs abrem muitos problemas na segurança de um sistema distribuído. 1

4 2. CARACTERÍSTICAS DE UM SAD Duas características principais de um SAD são a dispersão e multiplicidade de usuários e arquivos. Logo, múltiplos clientes em locais dispersos podem acessar arquivos dispersos, os quais geralmente são replicados. Nosso objetivo é esconder a dispersão e a multiplicidade dos usuários Arquivos Arquivos são um mecanismo de abstração que fornece uma forma de armazenar e recuperar informações em disco. Isto deve ser feito de uma tal forma que mantenha o usuário isolado dos detalhes a respeito de como as informações são armazenadas e de como os discos efetivamente trabalham. Para os usuários, um arquivo consiste de três componentes lógicos: nome atributos dados Arquivos criados pelos usuários são associados com um nome simbólico. Nomes de arquivos são suportados pelo uso de diretórios. Um diretório é um arquivo, geralmente um tipo especial, que mapeia os nomes para identificadores internos do arquivo (quando um arquivo é acessado, seu nome é mapeado por um único identificador do arquivo e a partir daí ser localizado fisicamente no disco). Diretórios podem incluir nomes de outros diretórios, conduzindo a um esquema de nomes hierárquico atribuindo a cada arquivo um nome de caminho. Dados consistem em uma seqüência de itens de dados (tipicamente 8 bits) acessíveis por operações de leitura e escrita sob alguma parte da seqüência. Podem ser organizados como uma estrutura plana de um fluxo de bytes, seqüência de blocos ou, alternativamente, uma estrutura hierárquica de registros indexados. Atributos contêm tipicamente informação sobre posse, tipo, tamanho, timestamps e autorização de acesso do arquivo Hierarquia Todos os sistemas distribuídos permitem que seus diretórios contenham subdiretórios, para tornar possível a seus usuários agrupar em um mesmo subdiretório aqueles arquivos que tenham alguma relação entre si. Obviamente que são fornecidas operações para criar e remover (sub)diretórios, bem como para gravar, apagar e buscar arquivos em (sub)diretórios. Quando o (sub)diretório é listado, somente os arquivos relevantes mostrados; aqueles que não tiverem nenhuma relação com estes estarão certamente em outros (sub)diretórios e não farão parte da lista. Cada (sub)diretório pode conter (ou não) vários (sub)diretórios, levando a uma estrutura de árvore de diretórios, normalmente chamada de sistema de arquivos hierárquico. A figura 1 (a) mostra uma árvore com cinco diretórios. Em alguns sistemas, é possível a criação de ligações ou ponteiros para um diretório arbitrário. Tais ponteiros podem ser colocados em qualquer diretório, tornando possível a construção não só de diretórios, mas também de grafos arbitrários, uma estrutura mais poderosa. A distinção entre árvores e grafos é particularmente importante em um sistema distribuído. A implementação da hierarquia de diretórios baseada em grafos apresenta um grau de dificuldade maior que a baseada em árvores. A natureza desta dificuldade pode ser observada na análise do grafo de diretórios da figura 1 (b). Nela, o diretório D tem uma ligação com o 2

5 diretório B. O problema ocorre quando a ligação de A para B for removida. Numa hierarquia em árvore, uma ligação para um diretório só pode ser removida quando o diretório apontado estiver vazio. Em um grafo, é permitido remover o ponteiro para um diretório se pelo menos existir um outro ponteiro para este diretório. Mantendo um contador, mostrado na parte superior direita da representação do diretório da figura 1 (b), é possível determinar quando o ponteiro a ser removido é o último. Após a remoção do ponteiro de A para B, o valor do contador de B é reduzido de 2 para 1, o que é fácil de fazer no papel. No entanto, B agora está inatingível a partir da raiz do sistema (A). Os três diretórios B, D e E estão efetivamente órfãos. 1 Contador do número de diretórios apontando para este diretório 2 1 Máquina Máquina 2 (a) (b) Figura 1: (a) Uma árvore de diretórios contida em uma máquina. (b) Um grafo de diretórios em duas máquinas. Este problema também existe em sistemas centralizados, porém torna-se mais sério nos distribuídos. Se todos os diretórios estiverem em uma única máquina, será sempre possível descobrir diretórios órfãos, apesar de às vezes isto ser muito caro. Toda a atividade dos arquivos pode ser suspensa e o grafo pode ser percorrido partindo da raiz, marcando todos os diretórios alcançados no percurso. Ao final deste procedimento, todos os diretórios que não tiverem sido marcados são tidos como inacessíveis. No caso de um sistema distribuído, há o envolvimento de uma série de máquinas, o que torna impossível parar com todas as atividades dos arquivos, de forma que é muito difícil, senão impossível, a obtenção de uma fotografia fiel da situação. Um ponto-chave no projeto de qualquer sistema de arquivos distribuídos é o fato de todas as máquinas (e processos) terem ou não exatamente a mesma visão da hierarquia do diretório. Como exemplo do significado disto, considere a figura 2. Na figura 2 (a), vemos dois servidores de arquivos, cada um com três diretórios e alguns arquivos. Na figura 2 (b) temos um sistema onde todos os clientes (e outras máquinas) têm a mesma visão do sistema de arquivos distribuído. Se o caminho /D/E/x é válido para uma máquina, então ele é válido para todas as demais. Em contraste, na figura 2 (c), máquinas diferentes podem ter visões diferentes do sistema de arquivos. Repetindo o exemplo anterior, o caminho /D/E/x poderia muito bem ser válido para o cliente 1, mas não para o cliente 2. Em sistemas que gerenciam vários servidores de arquivos através de montagem remota, o esquema normal é o da figura 2 (c). Ele é flexível e fácil de implementar, mas tem desvantagem de não fazer com que o sistema se pareça com os velhos e simpáticos sistemas de tempo compartilhado. Em tais sistemas, o sistema de arquivos deve parecer idêntico para qualquer processo, seguindo o modelo apresentado na figura 2 (b). Tal propriedade torna o sistema fácil de programar e entender. 3

6 (a) (b) Figura 2: 2 (a) Dois servidores de arquivos. Os quadrados representam os diretórios e as circunferências os arquivos. (b) Um sistema no qual todos os clientes têm a mesma visão do sistema de arquivos. (c) Um sistema no qual diferentes clientes podem ter diferentes visões do sistema de arquivos. (c) 3. PROJETO E IMPLEMENTAÇÃO DE UM SAD Um SAD tem dois componentes eminentemente distintos: o serviço de arquivos e o serviço de diretórios. O primeiro trata das operações sobre arquivos individuais, tais como leitura, escrita, anexação de informação, enquanto o último trata da criação e da gerência de diretórios e de acrescentar e remover arquivos de diretórios. Os únicos problemas no projeto e implementação de um sistema de arquivos distribuídos são a necessidade de compartilhamento e replicação de arquivos. 4

7 3.1. Montagem de Arquivos Assumimos que diretórios são hierarquicamente estruturados. Montagem de arquivos é um conceito útil para a construção de sistemas de arquivos de vários servidores de arquivo e dispositivos de armazenamento. Uma operação de montagem de um cliente liga o nome de um sistema de arquivo remoto e um sistema de arquivos hierárquico na posição indicada pelo nome do caminho. O ponto de montagem é usualmente um nó da árvore de diretórios que contém somente um subdiretório vazio. O sistema de arquivo a ser montado é identificado por um host remoto ou por um dispositivo local seguido pelo nome do caminho do sistema de arquivo. A figura 3 ilustra um cliente com dois arquivos montados remotamente. Os nós pessoas e usuários nos sistemas de arquivos dos Servidores 1 e 2 são montados sob os nós de alunos e assistentes como arquivos locais do Cliente. Isto significa que programas executando no Cliente podem acessar arquivos no Servidor 1 e 2 utilizando os caminhos de nome /usr/alunos/joão e /usr/assistente/ana através do uso de um protocolo de montagem. /(root) /(root) /(root) export vmlinux usr nfs pessoas alunos x assistentes usuários joão paula pedro joana gê ana Figura 3: Sistemas de arquivo local e remoto. Uma vez os arquivos montados, eles são acessados utilizando os nomes de caminhos lógicos concatenados sem referenciar hosts remotos ou dispositivos locais. Logo, a transparência de arquivos é conseguida. A informação de ligação (usualmente chamada de tabela de montagem para redireção de acesso) para sistemas de arquivos remotos é mantida pelo sistema de arquivos do host até ele ser desmontado. Utilizando esse mecanismo de montagem, é possível que diferentes clientes percebam um sistema de arquivo diferente desde que arquivos remotos possam ser montados em diferentes subdiretórios para cada cliente. Se um sistema de arquivo global e uniforme é desejado, o administrador do sistema pode forçar regras de montagem. Por exemplo, sistemas compartilhados devem ser montados em posições fixas no diretório hierárquico, separados dos sistemas de arquivos locais. Por razões de segurança, o servidor de arquivo normalmente restringe a montagem de todo ou parte do sistema de arquivo em um conjunto de hosts pré-definidos. Esta informação é armazenada no arquivo de exportação do servidor. As montagens de sistemas de arquivo são operações privilegiadas e podem ser feitas de três diferentes maneiras:! Montagem Explícita: Clientes fazem chamadas de montagem explícita do sistema quando é desejado.! Montagem de Boot: Um conjunto de servidores de arquivo é prescrito e todas as montagens são executadas no tempo de boot do cliente.! Automontagem: A montagem de servidores é implicitamente feita quando um arquivo é aberto primeiramente por um cliente. 5

8 A montagem explícita de cada sistema de arquivo é flexível, mas menos tratável do que a montagem de boot, onde a configuração uniforme do sistema de arquivo pode ser forçada no tempo de boot. Utilizando a montagem de boot, um cliente possui uma estática, mas completa visão do sistema de arquivo para uma sessão inteira. Naturalmente, a montagem de boot tem a desvantagem de trabalho desperdiçado na montagem de servidores desnecessários. A automontagem é uma combinação da montagem explícita e a montagem de boot e possui as vantagens de ambos. É dinâmica, como a montagem explícita (realmente os arquivos são montados somente quando acessados) e transparente, como a montagem de boot sem chamadas de montagem explícitas. Quando um arquivo é aberto, o kernel seleciona um servidor de um conjunto pré-determinado e monta o sistema do arquivo solicitado. A automontagem no Sistema de Arquivo de Redes (SAR) da Sun vai um passo adiante. Ele permite que clientes especifiquem um número de servidores que podem suportar o mesmo serviço de arquivo. O sistema operacional distribui o pedido e monta o primeiro servidor que responde ao pedido Registro de Servidores A montagem de arquivos é uma maneira conveniente de se conseguir transparência para acesso a um arquivo local. Entretanto, uma montagem inicial requer conhecimento da localização dos servidores de arquivo; isto é, o protocolo de montagem não é transparente. Em um sistema no qual múltiplos servidores de arquivo podem prover o mesmo serviço de arquivo, a localização da informação torna-se irrelevante para os clientes. Um servidor de arquivo pode ser localizado de duas diferentes maneiras:! Servidores de arquivo registram seus serviços através de um registro de serviço e clientes consultam o registro do servidor antes da montagem;! Clientes distribuem solicitações de montagem e servidores de arquivos respondem aos pedidos dos clientes; Ambos acessos são essencialmente um nome ou um protocolo de resolução de endereço. Para um SAD, o registro de serviço oferece a vantagem adicional da performance obtida. O registro do servidor pode determinar o melhor servidor de arquivo ou o que balanceia o sistema carregado para o pedido do cliente baseado no registro de conhecimento do servidor do sistema. O registro do servidor comporta-se como um negociante inteligente, um conceito encontrado em sistemas autônomos cooperativos. Um cliente pode também escolher um dos responsáveis que recebe de uma distribuição utilizando uma política razoável. Além do mais, a informação ligada residente no kernel do cliente pode ser tratada como cache. Se um servidor de arquivo se mover para um host diferente, um acesso ao arquivo para o servidor resultará em perda de cache. Um dos dois protocolos de resolução podem ser ativados para encontrar uma nova localização do servidor sem a intervenção do cliente. Efetivamente, conseguimos a independência da localização do arquivo. Montagens de sistemas de arquivos remotos são geralmente cascateados. Um sistema de arquivos montado poderia ter alguns de seus subdiretórios montados através de outros servidores de arquivos. No caso oposto, um caminho de nome pode requerer a saída através de múltiplas tabelas montadas, o que ultrapassaria os limites da máquina. É possível que o destino do servidor de arquivo esteja disponível para o acesso, mas problemas em servidores de arquivos intermediários impedem o alcance do cliente ao arquivo. A solução é permitir o acesso direto ao arquivo uma vez que ele é localizado. Esta informação pode ser mantida em cache em todos arquivos remotos abertos. A resolução de endereço conta com o roteamento na rede em vez do sistema de arquivo. 6

9 3.3. Servidores Com ou Sem Informações de Estado Nós temos descrito a sessão de operações de arquivos como uma conexão para uma seqüência de pedidos e respostas entre um cliente e o servidor de arquivos. Uma conexão requer, essencialmente, o estabelecimento e a finalização da sessão de comunicação. Além do mais, há uma informação de estado associada com cada sessão de arquivo (conexão). Alguns exemplos de informações de estado estão listados abaixo:! Arquivos abertos e seus clientes;! Descritores de arquivos e controladores de arquivos;! Ponteiros de posição do arquivo atual;! Montagem de informação;! Lock status;! Chaves de sessão;! Cache ou buffer; Estas informações de estado são mantidas dinamicamente enquanto os arquivos estão sendo usados. Elas são diferentes dos atributos dos arquivos, nos quais são propriedades estáticas. Veremos o porquê e quando essas informações de estado serão necessárias. Começando do topo da lista, o estado deve conter informação sobre quais arquivos estão sendo abertos por quais clientes. Essa informação deve estar guardada ou no cliente, ou no servidor, ou em ambos. Depois, para evitar passar pelo servidor de diretórios repetitivamente para cada acesso ao arquivo, um descritor de arquivo e o seu controlador são entregues para cada arquivo aberto e capturados pelo kernel do cliente. Para acessos seqüenciais, um ponteiro (implícito) de posição do arquivo deve ser associado com cada sessão aberta de arquivo. Quando um arquivo compartilhado é aberto por vários clientes, cada sessão aberta tem seu próprio ponteiro de posição atual, exceto em casos de herança. Em tais casos, clientes herdam arquivos de seus pais e os ponteiros de posição do arquivo são divididos entre os processos pais e os processos filhos. Os ponteiros de posição de arquivo devem ser obtidos naturalmente com a informação de arquivos abertos. O próximo da lista é a montagem de informação do arquivo. Os arquivos nos servidores são montados pelos clientes através de acessos remotos. O kernel do cliente deve manter a ligação de informações entre os arquivos remotos. Os servidores não necessitam estar cientes de quais arquivos estão sendo montados por quais clientes uma vez que seus arquivos estejam montados. Para coordenar o compartilhamento de arquivos, é sempre desejável permitir que os clientes tenham a capacidade de bloquear (locking) um arquivo. Visto que um bloqueio é uma informação global compartilhada por alguns clientes, parece mais apropriado que o servidor mantenha esse tipo de informação. Um outro exemplo de compartilhamento de informação é a chave de sessão para a comunicação. Para discutir o estado da conexão entre clientes e servidores, iremos simplesmente assumir que as chaves de sessão são um acordo ( em segredo ) entre um servidor de arquivos e seus clientes. Alguns protocolos de comunicação segura utilizam chaves de sessão chamadas de one-time session keys. Nesses casos, não há a necessidade de se armazenar as chaves como parte da informação de estado. Para finalizar, caches ou buffers podem ser usados tanto em clientes quanto em servidores para reduzir o atraso de acesso. Caching e buffering são úteis quando os pedidos de acesso mostram localidades. Dados no cache e buffer são informações de estado da conexão. Está claro que informações de estado de uma sessão de arquivo podem ser distribuídas entre a comunicação cliente-servidor. O modo como informações de estado são divididas afeta a performance e manutenção dos sistemas de arquivos distribuídos. Obviamente, o cliente que requisita o pedido deve manter muitas dessas informações. O que o servidor de arquivo deveria assumir para uma sessão aberta precisa ser determinado. Um servidor de arquivo é chamado stateful (com informação de estado), se ele mantém algumas dessas informações de estado e stateless (sem informação de estado) se não mantém nenhuma delas. 7

10 Entretanto, a noção de estado é algo a ser evitado o tanto quanto possível no projeto de um sistema distribuído. Um servidor sem informação de estado é muito mais fácil de se implementar e mais tolerante a falhas de clientes ou servidores do que um com informações de estado. Uma vez que falhas são mais freqüentes em sistemas distribuídos, muitas implementações de SADs optam por implementar servidores de arquivos sem informações de estado. Falhas no cliente não afetam no servidor. Falhas de um servidor sem informações de estado são fáceis de se recuperar e são interpretadas pelos clientes como um atraso de resposta (ou não resposta) sem interromper suas sessões. Para um servidor sem informações de estado, para cada pedido de arquivo para o servidor devem estar contidas todas as informações sobre o controlador de arquivo, ponteiro de posição, chave de sessão e outras informações necessárias. A implementação de um servidor de arquivo sem informações de estado deve tratar os seguintes pontos:! Necessidade de idempotência: refere-se a como o servidor lida com pedidos repetidos pelos clientes, causados por falhas prévias (ou falta de resposta) do servidor;! Mecanismo de bloqueio do arquivo: em implementações onde clientes compartilham os arquivos (em servidores sem informações de estado) deve haver um mecanismo de bloqueio de arquivos integrado nos serviços de transações;! Gerenciamento de chave de sessão: refere-se ao funcionamento de uma chave de sessão gerada e mantida entre a comunicação de cliente e servidor sem informações de estado;! Consistência em cache: refere-se à responsabilidade do servidor em controlar a consistência do cache entre seus clientes e quais semânticas de compartilhamento são suportadas; Abaixo, uma tabela 1 compara as vantagens entre os dois modelos de servidores de arquivos: Servidores sem informações de estado Servidores com informações de estado Tolerante a falhas Mensagens menores para solicitação de serviços Não há necessidades de chamadas OPEN/CLOSE Melhor performance Não gasta espaço na memória do servidor para armazenar tabelas Possível ler informações adiantadas Não há limitação para o número de arquivos abertos Fácil obter idempotência Não há problema quando um cliente pára de funcionar É possível bloquear arquivos Tabela 1: Comparação entre servidores com e sem informações de estado Acesso a Arquivos Compartilhamento de arquivos significa que múltiplos clientes podem acessar o mesmo arquivo ao mesmo tempo. Deste modo, o compartilhamento pode resultar tanto em sobreposição quanto na intercalação de operações de acesso. A sobreposição de acessos implica que haja múltiplas cópias do mesmo arquivo, sendo que a concordância é conseguida com êxito por uma multiplexação de espaço do arquivo. Um exemplo de onde um arquivo de dados poderia ser replicado é o uso de um cache. É vantajoso trazer partes de um arquivo remoto para um cache local para rápido acesso. Igualmente a isso, torna-se necessário manter uma cópia (que funcione) do arquivo compartilhado antes de se realizar as mudanças permanentes no arquivo. Em ambos os casos, cópias replicadas de um arquivo existente e acessos simultâneos ao arquivo são possíveis. Cada lugar que tem uma cópia do arquivo replicado pode ter uma diferente visão dos dados. 8

11 O gerenciamento acessos às réplicas para fornecer uma visão coerente do arquivo compartilhado é chamado do controle de coerência. A intercalação de acessos é devido às granularidades múltiplas de operações de acessos a dados. Alguns dos acessos a arquivos são operações simples de leitura/escrita. Outros envolvem seqüências de operações inter-relacionadas cruzando um intervalo de tempo definido pelo usuário, bem como uma transação ou uma sessão. A execução intercalada dessas seqüências em um mesmo arquivo também cria uma ilusão de compartilhamento simultâneo de arquivo. A confluência é arquivada pela multiplexação do tempo dos arquivos. Os objetivos principais desses pontos seriam como prevenir uma seqüência de execução para não interferir com as outras quando elas estão intercaladas e como evitar inconsistências ou resultados errados. A tabela 2 mostra o espaço e a multiplexação por tempo que atingem o efeito dos acessos concorrentes a arquivos compartilhados. As entradas na tabela são as funções requeridas para cada hipótese de compartilhamento. No espaço de domínio, acessos de leitura e escrita em um arquivo remoto podem ser implementados em uma das seguintes maneiras, dependendo do estágio dos dados do arquivo para acesso:! Acesso remoto: nenhum dado do arquivo é pego na máquina cliente. Cada pedido de acesso é transmitido diretamente ao servidor de arquivo remoto através da rede;! Acesso ao cache: uma pequena parte dos dados do arquivo é mantida em um cache local. Uma operação de escrita ou perda de cache resulta em um acesso remoto e há a atualização desse cache.! Acessos de download/upload: o arquivo inteiro é baixado por acessos locais. Um acesso remoto ou um upload é desempenhado quando é atualizado o arquivo remoto. Tempo Acesso remoto Acesso ao cache Espaço Simples Falso Controle de coerência leitura/escrita compartilhamento Controle de Coerência Transação concorrência concorrência Sessão Não aplicável Não aplicável Tabela 2: Espaço e multiplexação por tempo. e Acesso de download/ upload Controle de coerência Coerência e concorrência Compartilhamento ignorado O primeiro caminho é um modelo de acesso de nível simples, enquanto os outros são uma representação de armazenagem hierárquica de dois níveis dos dados. A implementação de um modelo de acesso remoto de nível simples é direta desde que apenas uma cópia do arquivo de dados exista, e todos os pedidos de acesso podem ser serializados pelo servidor de arquivo. As principais desvantagens são os longos atrasos de acesso da rede e confluência limitada. Os modelos cache e download/upload permitem acessos concorrentes e reduzem o atraso dos acessos, mantendo alguns ou todos os acessos localmente. Entretanto, esses caminhos introduzem um problema de coerência de arquivo. Visto que arquivos são replicados e podem ser compartilhados por vários usuários concorrentes, um arquivo compartilhado pode mostrar-se diferentemente a diferentes clientes simultâneos. Controle de coerência para dados replicados é um problema não muito trivial. Coerência de dados replicados podem ser interpretados de diferentes formas. As interpretações (ou definições) a seguir estão listadas em ordem de inflexibilidade. 1. Todas as réplicas são idênticas em todos os instantes. 2. Réplicas são percebidas como idênticas apenas em alguns instantes. 3. Os usuários sempre podem ler os dados mais recentes nas réplicas. 9

12 4. Operações de escrita são sempre executadas imediatamente e seus resultados são propagados em um estilo de melhor esforço. A primeira definição de coerência é ideal, mas é impossível de ser alcançada em sistemas distribuídos que praticamente obrigam atrasos de comunicação não-desprezíveis. Por essa razão, aceitamos o fato que nem todas as cópias são idênticas a todos os instantes. A segunda definição é um ajuste, mas isso é difícil de determinar os pontos de sincronização ótimos. A aceitação dos dados é significativa apenas no momento quando eles são lidos. Assim, a terceira definição parece lógica. O problema é a imprecisão do termo, mais recente (ou o mais novo ). A ordem relativa de operações de escrita deveria ser baseada em seus tempos de conclusão, nos quais são tempos que o resultado da operação de escrita refletem em todas as cópias. É preciso um protocolo, de modo que uma operação de leitura é sempre retornada com o resultado da escrita mais recente. A última definição é apenas uma tentativa grosseira de se aproximar da terceira definição. O problema de coerência de arquivo é devido à existência de dados replicados e também aos atrasos de atualização das réplicas pelos clientes. Coerência é um problema mais sério em sistemas distribuídos, uma vez que atrasos ou falhas, tanto nos clientes quanto nos servidores ou até mesmo na comunicação, se tornam mais freqüentes nesse tipo de sistema. Falhas durante o upload de um arquivo pode colocar o arquivo em um estado de inconsistência. É altamente desejável para um sistema garantir a atomicidade das atualizações, de modo que a cada operação de atualização é concluída com sucesso ou não tem nenhum efeito. Para cópias múltiplas de um mesmo arquivo uma atualização é atômica se todas ou nenhuma das cópias são atualizadas. Uma atualização atômica requer que o sistema seja recuperável, ou seja, o sistema deve ser capaz de desfazer uma atualização parcial e restaurar o sistema ao seu estado anterior a essa atualização parcial. Uma operação de desfeita implica no uso de uma forma de armazenamento estável que pode ser usado para restaurar o estado do sistema na configuração de todas as falhas do sistema. Operações sobre um arquivo relatadas anteriormente podem ser agrupadas em diferentes intervalos de tempo de acordo com as necessidades de sua aplicação. Operações intercaladas de leitura e escrita de diferentes processos resultam em acessos concorrentes aos arquivos. Alguns desses modos de acesso ao arquivo são:! Simples leitura e escrita: cada operação de leitura/escrita no arquivo é um acesso de pedido/resposta independente.! Transação: uma seqüência de leitura e escrita é tratada como uma unidade fundamental do acesso ao arquivo (com algumas requisições de semântica adicionais para a transação). Sintaticamente, uma transação é expressa por um começo de transação e é seguido por muitos acessos ao arquivo e terminado por um fim de transação. Aqui uma transação é definida em uma limitada noção que operações de leitura e escrita são acessos ao mesmo arquivo.! Sessão: uma sessão consiste numa seqüência de transações e operações simples de leitura/escrita, com semânticas adicionais associadas com a sessão como definido pelas aplicações. Tipicamente, uma sessão é encapsulada com um par de operações de abertura e fechamento. Acesso de simples leitura e escrita são conceitos familiares em todos os sistemas operacionais. Uma transação é um conceito de sincronização de um nível elevado. Os acessos aos dados das transações são inclusos pelo par começa transação/termina transação. Esta seqüência de acessos (incluindo atualizações) é atômica ou indivisível, significando que a seqüência de operações é executada sem interferência dos outros clientes. O resultado de uma execução intercalada de acessos por vários clientes é equivalente a uma execução serial de uma seqüência, tomando o dado de um estado consistente levando-o a outro estado consistente. Se as propriedades de atomicidade, consistência, isolamento e durabilidade 10

13 (ACID) forem satisfeitas, o acesso ao dado é feito em uma transação atômica. O conceito de uma transação atômica é muito comum para aplicações de negócios. A função para forçar a se ter atomicidade e consistência em um servidor de arquivo é chamada de serviço de transação Semânticas de Compartilhamento O compartilhamento de arquivos utilizando acessos de espaço e tempo multiplexados aumenta o controle de problemas de coerência e concorrência. Soluções para esses problemas dependem das semânticas de compartilhamento requeridas pelas aplicações. Idealmente, gostaríamos que a atualização de um arquivo possa ser completada instantaneamente e seus resultados sejam visíveis a outros processos compartilhados imediatamente. Praticamente, essa semântica é difícil de ser alcançada e por conseqüência é freqüentemente deixada para trás. Atrasos de escrita são inevitáveis em sistemas distribuídos, uma vez que o resultado de uma operação de escrita possa ser atrasado pela rede ou pelos serviços do sistema que forçam para se ter coerência e consistência. Usando a noção de espaço e tempo na tabela 2 apresentada anteriormente, listamos quatro modelos populares de semântica que possuem diferentes objetivos no compartilhamento de arquivo:! Semântica UNIX: cada operação realizada sobre um arquivo torna-se instantaneamente visível a todos os processos.! Semântica de sessão: nenhuma mudança fica visível aos processos até que o arquivo seja fechado.! Arquivos imutáveis: não é possível fazer atualizações; simplifica o compartilhamento e a replicação.! Transações: todas as mudanças têm a propriedade do tudo ou nada. A maior diferença entre a semântica UNIX e as outras é o atraso de operações de escrita. A semântica UNIX tenta fazer o resultado de escritas visíveis imediatamente, enquanto as semânticas de sessão e transações usam escritas atrasadas. Em sistemas distribuídos, a semântica UNIX pode ser obtida com facilidade caso haja somente um servidor de arquivos, e se os clientes não colocarem os arquivos em cache. Todas as operações de leitura e escrita vão diretamente para o servidor de arquivos, que as processa em ordem estritamente seqüencial. Esta metodologia simula a semântica UNIX, exceto nos casos raros em que os retardos da rede possam fazer com que uma leitura que ocorreu em um microssegundo após uma escrita chegue no servidor primeiro, obtendo então o valor antigo. Na prática, no entanto, a performance de um sistema distribuído no qual todas as requisições de arquivos precisem ir para um único servidor é freqüentemente muito pobre. Este problema muitas vezes é resolvido permitindo que os clientes mantenham cópias locais dos arquivos mais usados em seus caches privados. Só para lembrar, se um cliente modificar localmente o arquivo mantido em cache e pouco depois outro cliente ler o arquivo do servidor, o segundo cliente vai obter um arquivo obsoleto. Uma forma de contornar este problema é enviando imediatamente ao servidor todas as mudanças nos arquivos armazenados em cache. Apesar de conceitualmente simples, este método é ineficiente. Uma solução alternativa é relaxar um pouco a semântica de compartilhamento dos arquivos. Em vez de ser necessário uma leitura para se verificar os efeitos de todas as escritas anteriores, podemos ter uma nova regra que diga: Mudanças em um arquivo são visíveis apenas para o processo (ou possivelmente para a máquina) que modificou o arquivo. Só quando o arquivo for fechado é que essas mudanças serão visíveis para os demais processos (ou máquinas). A adoção de tal regra não muda o que ocorria com o problema anterior, mas redefine o comportamento real como sendo correto. É na semântica de sessão que essa regra é usada, sendo largamente usada em implementações. 11

14 O uso desta semântica levanta a questão se dois ou mais clientes estiverem simultaneamente modificando o mesmo arquivo armazenado em cache. Uma solução é considerar que como os arquivos são fechados em ordem, seus valores são enviados de volta ao servidor, de modo que o resultado final vai depender de quem fechou por último. Uma forma menos agradável, mas ligeiramente mais fácil de implementar, é considerar que o resultado final é apenas um dos candidatos, mas não deixando especificada à escolha de qual deles. Uma última dificuldade com o uso do cache e da semântica de sessão, é que ela viola um aspecto da semântica UNIX, além de não ter garantia de que todas as leituras retornarão sempre os valores escritos mais recentemente. Uma proposta diferente para a semântica de compartilhamento de arquivos em um sistema distribuído torna todos os arquivos imutáveis. Assim sendo, não há como abrir um arquivo para escrita. Em conseqüência, as únicas operações possíveis sobre arquivos são criar (create) e ler (read). Apesar de ser impossível fazer modificações nesta semântica, torna-se possível substituir um arquivo x, por um novo arquivo, em uma operação atômica. No entanto, permanece o problema de os dois processos tentarem substituir o mesmo arquivo ao mesmo tempo. Assim como na semântica de sessão, a melhor solução aqui parece ser permitir que um dos novos arquivos substitua o velho. A escolha pode recair na escolha do último arquivo gerado, ou pode ser feita de maneira não determinística. Um problema um pouco mais relevante é o que fazer se um arquivo for substituído enquanto um processo estiver lendo este arquivo. Uma das soluções é arranjar um modo do usuário continuar a ler o arquivo antigo, mesmo que ele não esteja mais em nenhum diretório, da mesma forma que o UNIX permite que um processo que tenha aberto um arquivo continue a usá-lo, mesmo depois de ele ter sido apagado de todos os diretórios. Uma outra solução seria detectar que o arquivo sofreu modificação e fazer tentativas subseqüentes para tê-lo a partir da falha. Uma quarta maneira de tratar arquivos compartilhados em um sistema distribuído é usando as transações atômicas. Em resumo, para acessar um arquivo ou um grupo de arquivos, o processo deve primeiro executar uma primitiva do tipo begin transaction para indicar que o que se segue deve ser executado de maneira indivisível. A seguir vem a chamada de sistema para ler ou escrever um ou mais arquivos. Quando o trabalho se completar, uma primitiva end transaction deve ser executada. O ponto-chave deste método, é que o sistema garante que todas as chamadas contidas dentro das transações serão executadas em ordem, sem qualquer interferência de outras transações correntes. Se duas ou mais transações iniciarem ao mesmo tempo, o sistema deve assegurar que o resultado final é o mesmo que o obtido se elas rodassem em alguma ordem seqüencial indefinida. Um exemplo clássico de onde as transações os sistemas mais fáceis de programar é o dos sistemas de automação bancária Controle de Versão É interessante chamar a atenção a dois modelos bem restritos de semântica de sessão. Um requer que uma sessão seja fechada imediatamente após uma operação de escrita. Neste aspecto, é equivalente ao modelo de semântica UNIX com um cache de escrita direta. O outro requer que um novo arquivo seja criado para que a modificação seja feita em cima dele antes do arquivo ser fechado. O arquivo original é apenas de leitura assim chamado de arquivo imutável. Todos os problemas associados com o compartilhamento de arquivos e replicação desaparecem desde que o arquivo compartilhado seja apenas de leitura. Para se obter o compartilhamento de escrita, os clientes devem conhecer os nomes dos arquivos mais novos criados. Uma solução simples para esse problema é usar o mesmo nome de arquivo, mas com um número de versão a cada revisão do arquivo. A responsabilidade de forçar semânticas de compartilhamento de arquivo é separada do serviço de arquivo para um serviço de alto nível 12

15 chamado controle de versão. Controle de versão pode ser implementado como uma função do serviço de diretório. Cada arquivo no diretório é associado com um número de versão. O arquivo com o mais alto número de versão é considerado ser o de versão atual do arquivo compartilhado. Os outros são considerados de versões mais antigas. A chamada de abertura a um arquivo sempre retorna a versão atual. Conseqüentemente, operações de leitura/escrita no arquivo aberto são feitas somente no local da cópia em andamento, similar ao modelo de semântica de sessão. Quando um arquivo é fechado, localmente é modificada a versão do arquivo, chamada de versão provisória (tentative version), que é atualizada no serviço de controle de versão. Se a versão provisória é fundamentada na versão corrente, uma atualização é submetida e a versão provisória se torna a versão atual com um novo número de versão. Se a versão provisória é encontrada para ser baseada em uma versão mais velha por causa de uma atualização do arquivo por um outro cliente, já tem sido consignadas três ações diferentes que podem ser realizadas dependendo de como os itens de dados no arquivo estão sendo compartilhados e modificados:! Desconsiderar conflito: uma nova versão é criada indiferente de que tem acontecido. É equivalente à semântica de sessões.! Resolver conflito de versão: v suponha que os itens de dados alterados na versão provisória estejam separados entre eles na nova versão atual. O resultado das atualizações disjuntas da mesma versão é chamado de versão de conflito. O conflito pode ser resolvido pela combinação de atualizações da versão provisória com a versão atual para gerar uma nova versão que combine todas as atualizações.! Resolver conflitos seriabilizados: suponha que os itens de dados alterados na versão provisória já estejam modificados pela nova versão atual. As atualizações concorrentes dos mesmos itens de dados poderiam causar os conflitos seriabilizados. Uma solução para resolver esse tipo de conflito é cancelar a versão provisória e reduzir a execução do cliente com a nova versão atual como sua versão em andamento. As atualizações concorrentes são seriabilizadas de forma arbitrária. Mais resoluções de conflito complexo ou esquemas de controle de versão podem ser implementadas dependendo das necessidades das aplicações. O uso de arquivos imutáveis não previne os problemas de inconsistência; ameniza suas mudanças de responsabilidade do serviço de arquivo para outros sistemas de serviço, permitindo implementações independentes de diferentes modelos de semântica. Para reduzir a armazenamento de requerimentos de um esquema de versões múltiplas, uma nova versão pode ser representada pelas mudanças das gravações de arquivo (blocks). Números de versão são associados com os blocks modificados. Manter a trilha dos blocos modificados também o torna mais fácil para a identificação de conflitos. 13

16 6. REFERÊNCIAS [1] CHOW, R. e JONHSON, T.: Distributed Operating Systems & Algorithms, Addison Wesley, fevereiro de [2] COULOURIS, G., DOLLIMORE, J. e KINDBERG, T.: Distributed Systems Concepts and Design, Addison Wesley, 3ª ed., [3] SILBERSCHATZ, A., PETERSON, J. e GALVIN, P.: Operating System Concepts, Addison Wesley, 3ª ed., [4] TANENBAUM, A. S.: Redes de Computadores, 3ª ed., Campus, [5] TANEMBAUM, A. S.: Sistemas Operacionais Modernos, LTC,