Notas de Aula - MAC 5755 - Sistemas Operacionais Distribuídos
Aula 14 - 3/10/2003
NFS - Network File System
- Lançado em 1985 pela Sun Microsystems junto com
o SunOS
- Numa iniciativa pioneira, divulgou também o "protocolo
NSF" através do qual qualquer um poderia implementar o seu cliente
ou servidor
- Apareceram implementações para todos
os tipos de UNIX, DOS, OS/2, MacOS, Windows e até para computadores
de grande porte (IBM/VMS)
- Baseado em RPC e XDR
- Objetivo principal do projeto do proetocolo: ser livre de estado
- traz consigo as vantagens e desvantagens que vimos
na última aula
- Mensagens são enviadas por UDP/IP. Caso não
haja resposta, repete até 3 vezes.
- Se não responde depois da terceira vez, há
duas opções:
- NFS server brucutu not responding, still trying...
- aborta operação e dá mensagem
de erro para o cliente
- Como o protocolo é livre de estado, o servidor
não precisa saber o que se passou.
- Solaris usa um serviço diferente para locks
: Network Lock Manager
- Montagem do espaço de nomes é feita através
do protocolo de montagem : cliente envia pathname, servidor
devolve file handle
- Exemplo:
- mount /dev/hd1a /
- mount mafalda:/mailboxes /var/spool/mail
- mount brucutu:/executaveis /usr/bin
- mount limbo.ime.usp.br:/mirror /usr/local/espelho
- /etc/fstab - lista de diretórios a serem
montados automaticamente na inicialização da máquina
- /etc/mtab - lista de diretórios montados
em um dado instante
- automounter: mecanismo de montagem dinâmica
de diretórios
- sistema monta automaticamente quando usuário
entra em diretório
- sistema desmonta automaticamente se usuário
não usa diretório por muito tempo (e.g., 5 minutos)
- Vantagem: inicialização mais rápida.
Principalmente se algum servidor não está disponível
- automounter permite a especificação de vários
servidores para o mesmo diretório
- o primeiro a responder ganha
- este é um mecanismo rudimentar para replicação
de arquivos read-only com balanceamento de carga
- espera-se que o servidor mais livre responda primeiro
mas nada garante isso.
Política de Consistência
- é bem relaxada, assume que haverá muito
pouco compartilhamento com escrita.
- primeiramente se usou escrita no fechamento (write-on-close
)
- depois modificou-se para escrita retardada (delayed write
): envia as escritas só quando blocos de 8KB são preenchidos
- Para minimizar as inconsistências, adota a seguinte
heurística:
- verifica com o servidor se a cópia local é
a mais recente todas as vezes em que um arquivo é aberto
- quando recebe um bloco de dados do servidor, este bloco
contém informações sobre a versão do arquivo;
neste caso, o cliente a verifica novamente
- a partir do momento em que um dado é guardado
no cache, ele é considerado válido por 3 segundos (no caso
de arquivos) ou por até 60 segundos (no caso de diretórios)
- A falta de consistência não permite, por exemplo,
que se use um arquivo como LOCK (uma técnica muito comum e conveniente
em sistemas centralizados)
Segurança
- É bem fraca
- Cada servidor guarda no arquivo /etc/exports os nomes
dos clientes que estão autorizados a montar cada diretório
e se o acesso será só para leitura ou para leitura e escrita
- Requisições contém o uid e o
gid do usuário e servior verifica se acesso pode ser
feito => servidor confia no cliente totalmente
- Se torna necessário que os uids e gid
s sejam os mesmos em toda rede => se usa para isso o Network Information
Service (NIS)
- Se necessário, é possível fazer autenticação
mútua entre cliente e servidor usando DES.
- Não há criptografia dos dados transmitidos via
rede
Arquitetura
- Proposta inovadora do NFS: Figura 2.5 de Kon94
- Camada Sistema de Arquivos Virtual é uma abstração
de diferentes tipos de sistemas de arquivos.
- v-node pode apontar para r-node (caso do NFS)
ou i-node (caso de SA local UNIX)
- tipo real do sistema de arquivos de cada diretório
é transparente para o usuário
SPRITE Network Operating System
- Um sistema operacional para redes locais
- Seu SAD para redes locais é muito eficiente
- Desenvolvido a partir de 1985 na Universidade da California
em Berkeley pela equipe de John Ousterhout.
-
http://www.cs.berkeley.edu/projects/sprite/sprite.html
- Características interessantes do Sprite:
- 100 mil linhas de código em C escritas do zero
para a criação de um novo SO
- Núcleo multithreaded para dar maior flexibilidade
e aproveitar máquinas com vários processadores
- Inovações sob o ponto de vista do serviço
oferecido:
- Semântica UNIX em acessos concorrentes a arquivos
distriuídos
- Migração de processos transparentemente
ao usuário e ao processo
- Espaço de nomes único válido para
toda a rede local
- Inovações do ponto de vista da implementação
- Grandes caches de tamanho variável através
de adaptação
- Resolução de caminhos através de
tabelas de prefixos
- Memória virtual implementada através de
arquivos comuns no sistema de arquivos distribuído
Migração de Processos
- É muito facilitada pelo fato da memória virtual
ser implementada usando o SAD. Passos:
- bloqueia o processo
- joga todas suas páginas para o disco
- envia para outra máquina o conteúdo dos
registradores e sua entrada na tabela de processos
- coloca processo na fila de prontos da nova máquina
Espaço de Nomes
- Dividido em domínios
- Cada servidor é responsável por um ou mais domínios
- Idéia inovadora: tabela de prefixos mantidas
pelos clientes Tab. 2.3 de Kon94
- Sempre que precisa acessar um arquivo de caminho P, procura
o prefixo mais longo na tabela de prefixos que seja um prefixo de P
- Daí envia para o servidor correspondente àquela
linha da tabela o índice encontrado na tabela e o resto do caminho
- Dentro do SA do servidor, pode haver um remote link.
Se no meio do caminho solicitado pelo cliente há um remote link
, o servidor responde ao cliente dizendo que aquele diretório não
é de sua responsabilidade
- Neste caso, o cliente envia um broadcast perguntando
quem é o responsável por aquele caminho e ao obter a resposta,
atualiza a sua tabela de prefixos
- Tabelas de prefixos inicialmente são vazias e crescem
dinamicamente
- Se um servidor responsável por um diretório
presente na tabela de um cliente não responde, o cliente envia um
novo broadcast
- Isso facilita muito a migração de domínios:
administradores podem rearranjar os domínios entre os servidores
sem a necessidade de reconfigurar os clientes. A reconfiguração
é feita posteriormente automaticamente quando necessário.
- Esse mecanismo é mais eficiente do que o NFS porque
são feitas menos traduções de caminho para file
handle
- Se servidores no meio do caminho estiverem fora do ar em um
dado instante, o cliente conseguirá acessar os arquivos da mesma
forma desde que o servidor final esteja funcionando e a entrada na sua tabela
de prefixos estiver atualizada
- Pode-se configurar os servidores para replicação
de arquivos read-only e para que servidores diferentes sirvam
arquivos binários de clientes de plataforma diferentes.
- Problema: se há uma falha de energia e todos os clientes
voltam a funcionar no mesmo instante, pode haver um congestionamento da
rede com os broadcasts. Com algum cuidado (e uma tese de doutorado
mais tarde) é possível resolver esse problema.
Política de Consistência
- Através de dados coletados durante 8 dias numa rede
com 52 usuários e 40 máquinas, observaram:
- a política de consistência do NSF levaria
a 20% dos usuários acessarem algum dado inconsistente em algum instante
- Isso levaria a algum problema sério? Não
sei. Os pesquisadores do Sprite provavelmente também não.
- O problema maior é que como usuários (e programadores)
que usam NFS sabem que não se pode confiar nele, quando uma aplicação
precisa de consistência, ela usa algum outro mecanismo, que não
o NFS, para garantir isso.
- Se o próprio SAD garantir a consistência, seria
possível implementar um monte de coisas interessantes usando o SAD
- Exemplo: aplicação de bate-papo via Internet
implementada no WebOS
- Enfim um cache consistente
- semântica UNIX (consistência perfeita) aliada
a um alto desempenho
- cache dos clientes armazenam tanto leituras quanto escritas
(delayed-write )
- a cada 30 segundos, todos os blocos sujos que estão
há mais de 30 segundos sem alteração são enviados
para o servidor
- cada escrita é enviada para o servidor em no
máximo 60 segundos e daí em no máximo 60 segundos para
o disco
- quando um usuário salva um arquivo, ele pode
demorar até 2 minutos para chegar ao disco
- vantagem: bom ganho no desempenho médio
- desvantagem: dados podem se perder se cliente
ou servidor caem; se o servidor cae e os dados são perdidos, pode
nem ser possível informar isso ao cliente
- Diferentemente do NFS, os servidores guardam a informação
de qual cliente está usando qual arquivo e se o uso é só
para leitura ou não
- Situações possíveis:
- um ou mais clientes lendo simultaneamente, nenhum
escrevendo: cache habilitado
- apenas um cliente lendo e escrevendo: cache habilitado
- acesso concorrente com escrita: cache desabilitado
- como o último item é muito raro,
o ganho médio de desempenho é muito significativo
- ainda é preciso tomar alguns cuidados com acesso
seqüencial com escrita. Como servidor possui todo o estado, não
é problema.
- Conclusão: é mais eficiente do que o NFS e ainda
por cima garante a consistência.
- Pergunta: por que não se tornou o padrão ao
invés do NFS ???
Referências
- Tanenbaum, seção 5.2.5; Galli, seção
8.4; Silberschatz 5a ed. cap 17.6; monografia sobre SAD na
página de leituras recomendadas
.
- Quem preferir uma referência em português pode dar
uma olhada no capítulo 2 da minha
tese de mestrado
. Mas, por favor, não gaste papel à toa imprimindo a tese
toda ou o capítulo todo.
Próxima Aula
Aula Anterior
Página de MAC 5755
Página do Fabio
Página do DCC