ARQUITETURA DE SISTEMAS

DISTRIBUÍDOS

SISTEMAS DE ARQUIVOS DISTRIBUÍDOS

-1-
Olá!
Objetivo desta Aula

Ao final desta aula, o aluno será capaz de:

1- Descrever os conceitos de Sistemas de Arquivos Distribuídos;

2- Identificar as semânticas de compartilhamento e dos mecanismos de replicação.

Introdução

O acesso à informação correta é considerado como algo imensurável.

Para compreendermos melhor essa questão, nesta aula, vamos ampliar nosso estudo sobre as vantagens do uso

de Sistemas de Arquivos Distribuídos.

1 Distributed Files System (DFS)

Compartilhar dados é fundamental para sistemas distribuídos!

Os Sistemas de Arquivos Distribuídos Distributed File System (DFS) são a base para muitas aplicações

distribuídas, já que permitem que vários processos compartilhem dados, de modo seguro e confiável, por longos

períodos.

Por isso, esses sistemas têm sido usados como a camada básica para sistemas e aplicações distribuídas.

(TANENBAUM; STEEN, 2007).

Um sistema de arquivos fornece serviços de arquivo para clientes (a interface cliente de um serviço de arquivo é

formada por um conjunto de operações primitivas de arquivo, tais como criar, apagar, ler e gravar um arquivo).

O componente primário de hardware que um servidor de arquivos controla é um conjunto de dispositivos locais

de armazenamento secundário (geralmente, discos magnéticos), nos quais arquivos são armazenados e

recuperados, de acordo com as solicitações dos clientes.

Em um DFS, a atividade de serviço deve ser realizada através da rede.

Esse sistema pode ser implementado como parte de um sistema operacional distribuído ou, alternativamente,

por uma camada de software, cuja tarefa é gerenciar a comunicação entre sistemas operacionais convencionais e

sistemas de arquivos.

As características que diferenciam um DFS são a multiplicidade e a autonomia de clientes e servidores no

sistema.

-2-
1.1 Funções do DFS

O DFS deve aparecer para seus clientes como um sistema de arquivos convencional centralizado. Portanto, é de

sua responsabilidade localizar os arquivos e providenciar o transporte dos dados.

Essa transparência facilita a mobilidade do usuário, trazendo seu ambiente para onde quer que ele se conecte.

O referido sistema também possui, como importante medida de desempenho, a quantidade de tempo necessária

para o atendimento das requisições de serviço.

Em sistemas convencionais, esse tempo consiste no tempo de acesso ao disco e em um pequeno intervalo de

tempo de processamento da CPU.

Entretanto, em um DFS, um acesso remoto possui o overhead (esse overhead inclui o tempo para liberar a

solicitação para um servidor bem como o tempo para retornar a resposta ao cliente através da rede) adicional

atribuído à estrutura distribuída.

Por fim, o DFS gerencia um conjunto de dispositivos de armazenamento (o espaço total de armazenamento é

composto por espaços menores, diferentes e localizados remotamente) dispersos.

1.2 Tipos de serviços

Serviço de armazenamento

Serviço relacionado à alocação e ao gerenciamento de espaço e operações para armazenamento e recuperação

de dados.

Serviço de arquivo

Serviço que trata das operações com arquivos independentes, incluindo:

· Modos de acesso;

· Políticas de caching;

· Semântica de compartilhamento;

· Replicação;

· Controle de concorrência;

· Consistência dos dados etc.

Serviço de nomeação

Serviço que fornece mapeamento entre nomes de arquivos e seus identificadores.

-3-
1.3 Nomeação e transparência

Em DFS, a nomeação é um mapeamento entre objetos lógicos e físicos. Já a transparência oculta o local em que o

arquivo está localizado na rede.

Dado um nome de arquivo, o mapeamento retorna um conjunto de localizações dessas réplicas do arquivo.

Nessa abstração, ficam ocultas tanto a existência de múltiplas cópias quanto sua localização.

Estruturas de nomeação

Veja, a seguir, as noções relacionadas aos mapeamentos de nomes em um DFS:

Transparência de localização (por exemplo: /Server X/dir y / dir w/arquivo Z) – nesse caso, o nome de um

arquivo não revela qualquer indicação de sua localização física de armazenamento;

Independência de localização – nesse caso, o nome de um arquivo não precisa ser alterado quando da

mudança de sua localização física de armazenamento.

Um esquema de nomeação independente de localização é um mapeamento dinâmico, já que se pode mapear o

mesmo nome de arquivo para diferentes locais em dois momentos distintos.

Portanto, a independência de localização é uma propriedade mais forte do que a transparência de localização.

Na prática, a maioria dos DFS atuais fornece um mapeamento estático e transparente de localização para nomes

no nível do usuário. Entretanto, esses sistemas não suportam a migração de arquivos. Em outras palavras, a

mudança automática da localização de um arquivo é impossível. Portanto, a noção de independência de

localização é irrelevante para esses sistemas.

Os arquivos são associados permanentemente a um conjunto específico de blocos de disco. Arquivos e discos

podem ser manualmente movimentados entre máquinas, mas a migração de arquivos implica uma ação

automática iniciada pelo sistema operacional.

Esquemas de nomeação

Abordagem mais simples

Nesse tipo de abordagem, o arquivo é identificado com alguma combinação de seu nome de host e seu nome

local, o que garante um nome exclusivo em todo o sistema.

Esse esquema de nomeação não é transparente quanto à localização nem independente de localização.

Entretanto, as mesmas operações de arquivo podem ser utilizadas tanto para arquivos locais quanto para

arquivos remotos.

Abordagem popularizada pelo Network File System (NFS)

-4-
O NFS (sistema de arquivos de rede da Sun Microsystems. Trata-se de um componente do sistema de arquivos

do ONC+: um pacote de rede suportado por muitos fornecedores da UNIX) fornece um meio de anexar diretórios

remotos a diretórios locais, dando, assim, a aparência de uma árvore de diretórios coerente.

Abordagem de única estrutura global de nomes

Nesta abordagem, uma única estrutura global de nomes abrange todos os arquivos do sistema.

A estrutura de sistema de arquivos composta é igual à estrutura de um sistema de arquivos convencional.

Entretanto, na prática, os diversos arquivos especiais (por exemplo: arquivos de dispositivos do UNIX e

diretórios binários específicos de máquinas) tornam esse objetivo difícil de ser atingido.

2 Modelos de acesso
A forma como uma requisição será tratada dependerá do modelo de acesso do sistema de arquivos que será

dado aos arquivos.

Em um DFS, dois modelos de acesso podem ser utilizados:

2.1 Modelo de serviço remoto

Quando um usuário solicitar acesso a um arquivo remoto, o servidor que armazena o arquivo será localizado

pelo esquema de nomeação e, então, realizará a transferência dos dados.

Uma das maneiras mais comuns para implementar o serviço remoto é o paradigma da Chamada de

Procedimento Remoto (RPC).

Para garantir o desempenho razoável de um mecanismo de serviço remoto, podemos utilizar uma forma de

armazenamento em cache.

Em sistemas de arquivos convencionais, o motivo para o armazenamento em caches é reduzir o |/O de disco

(aumentando, portanto, o desempenho). Já nos DFS, o objetivo é

reduzir tanto o tráfego de rede quanto o I/O de disco.

2.2 Modelo de caching: esquema básico de armazenamento em cache

Se os dados necessários para atender à solicitação de acesso ainda não estiverem armazenados em cache, uma

cópia desses dados do servidor será trazida para o sistema cliente. Dessa forma, seus acessos serão executados

na cópia do cache. A ideia é reter no cache blocos de disco recentemente acessados, de modo que acessos

repetidos às mesmas informações possam ser manipulados localmente, sem tráfego de rede adicional.

-5-
Os arquivos ainda são identificados com uma cópia-mestra residindo na máquina do servidor e mais cópias (ou

partes) do arquivo disseminadas em diferentes caches.

Quando uma cópia do cache for modificada, as mudanças precisarão se refletir na cópia- mestra para preservar a

semântica de consistência relevante.

A granularidade dos dados do cache de um DFS pode variar de blocos de um arquivo a um arquivo inteiro.

3 Comparação entre armazenamento em cache e serviço

remoto
Quando o armazenamento em cache é utilizado, o cache local pode manipular eficientemente um número

substancial dos acessos remotos.

O aproveitamento da localidade nos padrões do acesso a arquivos torna o armazenamento em cache ainda mais

atraente.

A maioria dos acessos remotos será atendida tão rapidamente quanto os acessos locais. Além disso, os

servidores são contatados apenas ocasionalmente. Consequentemente, a carga no servidor e o tráfego na rede

são reduzidos, e a possibilidade para a escalabilidade aumenta.

Por outro lado, quando o método de serviço remoto é utilizado, cada acesso remoto é manipulado através da

rede. O prejuízo é associado ao aumento de tráfego na rede, à carga no servidor e à redução no desempenho.

Quando transmitimos grandes porções de dados (conforme é feito no armazenamento em cache), o overhead

total da rede é mais baixo do que quando transmitimos séries de respostas a solicitações específicas (como no

método de serviço remoto).

Além disso, as rotinas de acesso a disco no servidor podem ser mais otimizadas quando sabemos que as

solicitações envolverão sempre grandes segmentos de dados contíguos – em vez de blocos aleatórios de disco.

O problema da consistência do cache é a principal desvantagem do armazenamento em cache. Quando os

padrões de acesso exibem gravações não frequentes, o armazenamento em cache é superior.

Entretanto, quando as gravações são frequentes, os mecanismos empregados para resolver o problema da

consistência incorrem em overhead significativo em termos de desempenho, tráfego na rede e carga no servidor.

Para que o armazenamento em cache traga benefícios, a execução deve ser levada a efeito em máquinas que

tenham discos locais ou memórias principais de grande capacidade. O acesso remoto em máquinas com memória

de pouca capacidade e sem discos deve ser realizado por meio do método de serviço remoto.

-6-
No armazenamento em cache, como os dados são transferidos em massa entre o servidor e o cliente – em vez de

em resposta às necessidades específicas de uma operação de arquivo -, a interface de mais baixo nível entre

máquinas é diferente da interface de mais alto nível do usuário.

Por outro lado, o modelo do serviço remoto é apenas uma extensão da interface local do sistema de arquivos

através da rede. Sendo assim, a interface entre máquinas espelha a interface do usuário.

4 Stateful (serviço com estado) versus stateless (serviço

sem estado)
Existem duas abordagens para o armazenamento de informações no lado do servidor, quando um cliente acessa

arquivos remotos, quais sejam:

· O servidor busca cada arquivo que estiver sendo acessado pelo cliente; ou

· O servidor simplesmente fornece blocos conforme são solicitados pelo cliente, sem saber como esses blocos

estão sendo utilizados.

No primeiro caso, o serviço fornecido tem estado (stateful); no outro, o serviço não tem estado (stateless).

4.1 Stateful (serviço com estado)

No serviço de arquivos com estado (conexão entre o cliente e o servidor durante uma sessão, tanto ao fechar o

arquivo quanto por intermédio de um mecanismo de coleta de lixo (garbage-collection), um cliente deve

executar uma operação open () sobre um arquivo antes de acessá-lo. O servidor, então, extrai informações sobre

o arquivo em seu disco, armazena essas informações em memória e fornece ao cliente um identificador (esse

identificador é utilizado para acessos subsequentes até que a sessão termine) de conexão único para o cliente e o

arquivo aberto.

Em termos do UNIX, o servidor extrai o I-node e fornece ao cliente um descritor de arquivo, que serve como um

índice para a tabela de inodes em memória.

No stateful, o servidor deve reclamar o espaço de memória principal utilizado pelos clientes que não estão mais

ativos.

O ponto chave relacionado à tolerância a falhas em uma abordagem de serviço com estado é que o servidor

mantém informações sobre seus clientes na memória principal.

-7-
4.2 Stateless (serviço sem estado)

O serviço de arquivos sem estado evita informações de estado, tornando cada solicitação autossuficiente. Em

outras palavras, cada solicitação identifica completamente o arquivo e sua posição no arquivo (para acessos de

leitura e gravação).

No stateless, o servidor não precisa manter uma tabela de arquivos abertos na memória principal. Além disso,

não há necessidade de estabelecer e terminar uma conexão por operações open () e close ().

Um processo-cliente abre um arquivo, e essa abertura não resulta no envio de uma mensagem remota.

Leituras e gravações são realizadas como mensagens remotas (ou consultas ao cache). O fechamento final pelo

cliente, por sua vez, resulta novamente em apenas uma operação local.

4.3 Vantagens e distinção entre satateful e stateless

VANTAGENS

A vantagem de um serviço com estado sobre um serviço sem estado é o aumento do desempenho. Informações

de arquivo são armazenadas em cache na memória principal e podem ser facilmente acessadas via identificador

de conexão, evitando, assim, acessos ao disco.

Além disso, um servidor com estado sabe se um arquivo está aberto para acesso sequencial e pode, portanto, ler

os próximos blocos à frente. Servidores sem estado não podem fazer isso, pois não conhecem o objetivo das

solicitações do cliente.

DISTINÇÃO

A distinção entre stateful e stateless torna-se mais evidente quando consideramos os efeitos de uma queda

durante uma atividade de serviço. Nessa situação, um servidor com estado perde todos os seus estados voláteis.

A garantia de recuperação sem prejuízo desse servidor implica a restauração de seu estado, normalmente

realizada por um protocolo de recuperação baseado em um diálogo com os clientes.

Stateful x Stateless

Do ponto de vista do cliente, não há diferença entre um servidor lento e um servidor em recuperação. Se não

receber resposta, o cliente continuará a retransmitir sua solicitação.

Em alguns ambientes, o stateful é uma necessidade. Se o servidor empregar o método iniciado para validação do

cache, não poderá oferecer serviço sem estado, pois deverá manter um registro dos arquivos que foram

armazenados em cache e dos clientes que os armazenaram.

Um problema diferente é causado por falhas dos clientes. O servidor precisa tornar-se consciente dessas falhas,

de modo que possa reclamar o espaço alocado para registrar o estado dos processos-clientes que falharam.

-8-
O stateless evita esses problemas, pois um servidor recentemente recuperado pode responder a uma solicitação

autossuficiente sem qualquer dificuldade. Portanto, os efeitos de falhas e de recuperações do servidor são quase

imperceptíveis.

4.4 Replicação de arquivos

Em um DFS, a replicação de arquivos em diferentes máquinas é uma redundância útil para melhorar a

disponibilidade.

A replicação multimáquinas pode também beneficiar o desempenho: a seleção de uma réplica vizinha para o

atendimento de uma solicitação de acesso resulta em tempo de serviço mais curto.

Replicação explícita

Quando a responsabilidade fica a cargo do programador. Nesse caso, o serviço de diretórios pode permitir

diversos índices de arquivos para cada arquivo.

Esse tipo de replicação é de difícil implementação e não permite a aplicação da transparência.

Replicação atrasada (lasy)

Quando apenas uma cópia é realizada em um servidor. Nesse caso, o servidor possui a responsabilidade de

propagar as atualizações e de garantir que outro servidor responda no caso de sua impossibilidade.

Replicação em grupos

Quando a operação de escrita é realizada em todos os arquivos ao mesmo tempo (multicast atômico).

5 SEMÂNTICA DE COMPARTILHAMENTO
Quando dois ou mais usuários compartilham o mesmo arquivo ao mesmo tempo, é necessário definir, com

exatidão, a semântica de leitura e de escrita para evitar problemas.

Vamos conhecer essas semânticas?

Semântica UNIX

Na semântica Unix, as alterações são visíveis instantaneamente.

Em sistemas de um único processador (sistemas que permitem que processos compartilhem arquivos (como

o Unix, por exemplo), normalmente, a semântica declara que, quando uma operação read vem depois de uma

operação write, aquela retorna o valor que acabou de ser escrito. Veja, a seguir, uma figura que representa uma

semântica Unix:

-9-
De maneira semelhante, quando duas operações write ocorrem em rápida sucessão, seguidas por uma read, o

valor lido é o valor armazenado pela última write. Na verdade, o sistema impõe uma ordenação de tempo

absoluto a todas as operações e sempre retorna o valor mais recente.

Em um sistema distribuído, a semântica Unix pode ser alcançada com facilidade, contanto que haja somente um

servidor de arquivos e que os clientes não os armazenem.

Todas as operações read e write vão diretamente para o servidor de arquivos, que as processa estritamente em

sequência. Essa abordagem gera a semântica Unix, exceto pelo pequeno problema de que atrasos de rede podem

fazer com que uma read que ocorreu em um microssegundo após uma write chegue antes ao servidor e, por isso,

obtenha o valor antigo.

O desempenho de um sistema distribuído, no qual todas as requisições de arquivos devem ir para um único

servidor, costuma ser fraco. Muitas vezes, esse problema é resolvido com a permissão de que clientes

mantenham cópias locais de arquivos muito utilizados em suas caches (locais) privadas.

Se um cliente modifica localmente um arquivo em cache e, logo depois, outro cliente lê o arquivo no servidor,

este obtém um arquivo obsoleto.

SEMÂNTICA DE SESSÃO

Uma solução alternativa à semântica Unix é relaxar a semântica de compartilhamento de arquivos.

Em vez de requerer que uma read veja os efeitos de todas as operações write anteriores, podemos estabelecer

uma nova regra, em que:

· As alterações em um arquivo aberto sejam inicialmente visíveis apenas para o processo ou, possivelmente,

máquina que modificou o arquivo;

· As alterações devam ficar visíveis para outros processos ou máquinas somente quando o arquivo for fechado.

Grande parte dos sistemas de arquivos distribuídos implementa a semântica de sessão. Contudo, ainda resta a

questão do que ocorre quando dois ou mais clientes armazenam e modificam o mesmo arquivo

simultaneamente.

- 10 -
Uma solução é dizer que, à medida que cada arquivo for fechado por vez, seu valor será enviado de volta ao

servidor, de modo que o resultado final dependerá da requisição de fechamento mais recentemente processada

pelo servidor.

Uma alternativa menos agradável - porém, mais fácil de implementar é dizer que o resultado final será um dos

candidatos, mas não especificar o escolhido.

6 Arquivos imutáveis
Em um sistema distribuído, uma abordagem completamente diferente da semântica de compartilhamento de

arquivos é tornar imutáveis todos eles.

Dessa forma, não existe nenhum modo de abrir um arquivo para escrita. Na verdade, as únicas operações em

arquivos são create e read.

O que se permite é criar um arquivo inteiramente novo e passá-lo para o sistema de diretório sob o nome de um

arquivo previamente existente, que, agora, se tornará inacessível (ao menos sob esse nome).

Uma vez decidido que os arquivos não podem ser alterados de jeito algum, o problema de como lidar com dois

processos – como escrever em um arquivo e ler esse arquivo – simplesmente desaparece, o que simplifica,

consideravelmente, o projeto.

Resta, então, o problema que ocorre quando dois processos tentam substituir o mesmo arquivo

simultaneamente. Como acontece com a semântica de sessão, a melhor solução para esse caso seria permitir que

um dos novos arquivos substituísse o antigo – seja este o último, seja a substituição não determinística.

Por isso, embora seja impossível modificar o arquivo específico, continua possível substituir, atomicamente, esse

arquivo por um novo. Em outras palavras, embora arquivos não possam ser atualizados, os diretórios podem.

Um problema um pouco mais desagradável diz respeito a como prosseguir se um arquivo for substituído

enquanto outro processo estiver ocupado, lendo esse mesmo arquivo.

Uma solução é dar um jeito de o processo leitor continuar usando o arquivo antigo, mesmo que este não esteja

mais em nenhum diretório, comparado ao modo como o Unix permite a um processo que tenha um arquivo

aberto continuar a usá-lo, mesmo depois de esse arquivo ter sido apagado de todos os diretórios.

Outra solução é detectar se o arquivo foi alterado e fazer com que as tentativas subsequentes de ler esse arquivo

falhem.

- 11 -
7 Network File System (NFS)
O padrão NFS mais recente é a Versão 4 que difere fundamentalmente das versões anteriores. Essa versão

apresenta uma mudança significativa, em que o protocolo tem estado, o que significa que o servidor mantém o

estado da sessão do cliente do momento em que o arquivo remoto é aberto até que ele seja fechado.

Sendo assim, o protocolo NFS fornece operações open() e close(). As versões anteriores do NFS – que não têm

estado – não fornecem tais operações.

Além disso, as versões anteriores especificam protocolos separados para a montagem de sistemas de arquivos

remotos e para o trancamento (lookup) desses arquivos. Em particular, o protocolo de montagem foi eliminado,

permitindo que o NFS funcionasse com firewalls de rede.

A Versão 4 do NFS aprimorou a capacidade de os clientes armazenarem em cache local os dados dos arquivos,

melhorando o desempenho do DFS, já que os clientes são capazes de resolver mais acessos a arquivos a partir do

cache local do que passando pelo servidor.

Outro benefício dessa versão permite que os clientes solicitem locks de arquivos aos servidores. Se o servidor

atender à solicitação, o cliente manterá o lock até que ele seja liberado ou que sua concessão (os clientes

também são autorizados a renovar concessões existentes) expire.

Tradicionalmente, os sistemas baseados no Unix oferecem trancamento aconselhável de arquivos, enquanto os

sistemas operacionais Windows utilizam o trancamento obrigatório.

Para permitir que o NFS funcione bem com sistemas não Unix, ele também fornece trancamento obrigatório.

Os novos mecanismos de trancamento e armazenamento em cache são baseados no conceito de delegação

(quando o servidor delega responsabilidades pelo lock e pelo conteúdo de um arquivo ao cliente que solicitou o

lock). O cliente delegado mantém em cache a versão corrente do arquivo, e outros clientes podem solicitar a ele o

acesso ao lock e o conteúdo do arquivo, até que o cliente delegado desista do lock e da delegação.

Finalmente, enquanto as versões anteriores do NFS são baseadas no protocolo de rede UDP, a Versão 4 é

baseada no TCP, que permite melhor adaptação a cargas variadas de tráfego na rede. A delegação dessas

responsabilidades aos clientes reduz a carga no servidor e melhora a coerência do cache.

É desejável ocultar os detalhes de replicação dos usuários. O mapeamento de um nome de arquivo copiado em

uma réplica específica é tarefa do esquema de nomeação.

A existência de réplicas deve ser invisível aos níveis mais altos. Nos níveis mais baixos, entretanto, as réplicas

devem ser diferenciadas umas das outras por distintos nomes de mais baixo nível.

- 12 -
Outro requisito de transparência é fornecer controle de replicação (esse controle inclui a determinação do

grau de replicação e da localização das réplicas) nos níveis mais altos.

Veja, a seguir, uma figura que representa um sistema NFS

O que vem na próxima aula

Na próxima aula, você vai estudar:

· Componentes utilizados para desenvolvimento dos serviços Web.

CONCLUSÃO
Nesta aula, você:
• Conheceu os mecanismos de nomeação que fornecem transparência e independência às localizações;
• Conheceu diversos métodos de acesso a arquivos distribuídos;
• Identificou que a replicação de arquivos em diferentes máquinas em um DFS é uma redundância útil
para melhorar a disponibilidade;
• Aprendeu a comparar servidores com estado e sem estado;
• Identificou a importância das semânticas de compartilhamento de arquivos.

- 13 -