Sistemas de Ficheiros Distribuídos

Sistemas de Ficheiros Distribuídos

Sistemas de Ficheiros Distribuídos

Propriedades:

• Transparência de rede: mesmas operações que num sistema local.
• Transparência de localização: nome não deve revelar localização.
• Independência de localização: nome não deve mudar quando colocação física mudar.
• Mobilidade do utilizador: utilizadores devem poder aceder a partir de qualquer nó.
• Tolerância a Falhas: continuar a funcionar perante a falha de um componente.
• Escalabilidade: escalar quando a carga aumenta, e ser expansivel incrementalmente.
• Mobilidade de Ficheiros: mudar a localização física.

Considerações de Desenho

• Espaço de nomes:
  • uniforme, todos os clientes usam o mesmo nome para o mesmo arquivo;
  • ou, adaptável por cada cliente.
• Servidor com ou sem estados. Ex: offset no servidor para leitura ou cada cliente envia. Não ter estados simplifica consistência e recuperação de falhas.
• Semânticas de Partilha:
  • Unix exige que mudanças de um cliente sejam visiveis para os outros imediatamente;
  • Semânticas de sessão são propagados no open() e no close().
• Métodos de Acesso Remoto:
  • sempre chamado pelo cliente,
  • ou com uma participação mais activa do servidor.

Desenho de NFS

Originalmente desenvolvido pela Sun, suporta sistemas Unix e não Unix.

• Baseado num modelo cliente servidor:
  • Código de servidor separado de cliente;
  • Comunicação via RPC síncrona.
• Cada servidor exporta um ou mais sistemas, para leitura ou leitura-escrita.
• Montagem pode ser hard, tenta até conseguir, ou soft, desiste após um bocado, ou spongy, hard no princípio e depois soft.
• Cliente pode não ser privilegiado, e pode montar o mesmo sistema em vários locais.
• Servidor apenas pode exportar FS locais e não pode atravessar pontos de montagem.

Objectivos de NFS

Os objectivos da Sun eram:

1. NFS não ser restrito a Unix (tanto servidores como clientes).
2. Protocolo não devia depender de hardware.
3. Mecanismo de recuperação simples.
4. Acesso transparente a ficheiros remotos.
5. Manter semânticas de Unix para clientes Unix.
6. Desempenho comparável a disco local.
7. Implementação independente de transporte (UDP, TCP).

Protocolo NFS

NFSv2, protocolo definindo operações e seus argumento:

Proc	Entrada -> Saída
NULL
GETATTR	fhandle -> status, fattr
SETATTR	fhandle,sattr -> status, fattr
LOOKUP	dirfh,name -> status, fhandle, fattr
READLINK	fhandle -> status,link_value
READ	fhandle,offset,count,totcount -> status,fattr,data
WRITE	fhandle,offset,count,totcount,data -> status,fattr
CREATE	dirfh,name,sattr -> status,fhandle,fattr
REMOVE	dirfh,name -> status
RENAME	dirfh,name1,dirfh,name2 -> status
LINK	fhandle,dirfh,name -> status
SYMLINK	fhandle,dirfh,name -> status
MKDIR	dirfh,name,sattr -> status,fhandle,fattr
RMDIR	dirfh,name -> status
READDIR	fhandle,cookie,count -> status,dir_entries
STATFS	fhandle -> status,file_stats

Componentes de NFS

Outros componentes:

• RPC: define o formato das interacções entre o cliente e o servidor. Pedido NFS é um pacote RPC.
• XDR: Extended Data representation usada por RPC para codificar dados.
• Código de implementação do servidor NFS.
• Código de implementação do cliente NFS.
• Protocolo de montagem: NULL, MNT, DUMP, UNMT, UNMTALL, EXPORT.
• Processos daemon: nfsd e mountd no servidor, e biod suporta I/O assíncrono no cliente.
• O Network Lock Manager e o Network Status Monitor permitem locking de ficheiros.

Statelessness

Todos os pedidos são independentes:

• Não há pedidos para abrir e fechar ficheiros. Registos de pedidos só para estatísticas ou para caching.
• Se um servidor faz reboot, o cliente continua a enviar os pedidos até que o cliente faz reboot, e nessa altura o servidor pode devolver a informação.
• O servidor deve colocar em armazenamento estável todas as alterações antes de responder (dados de ficheiros, dir., inode, etc.)

O Conjunto de Protocolos

Os protocolos mais importantes são:

1. XDR usa uma representação tipo Sun com inteiros, objectos opacos, strings, vectores e estruturas.
2. RPC da Sun é um protocolo síncrono de comunicação entre cliente e servidor. É fiável apesar de habitualmente ser implementado sobre UDP. Campos incluem xid, direcção, rpc_vers, programa e sua versão, informação e autenticação.
3. Autorização pode ser NULL, UNIX, SHORT, usada depois do primeiro pedido Unix, DES, e KERB.

Implementação de NFS

• File Handles: evitam ter sempre que abrir o ficheiro. Incluem o fsid, nó-i e o número de geração.
• Montagem comunica com mountd. Servidor NFS mantém uma lista de directórios exportados, para verificar rápidamente quais as permissões.
• Lookup é lento.

Compatibilidade com Unix

• Em Unix, util. pode sempre escrever num ficheiro aberto, mesmo que o dono tenha alterado as permissões. NFS permite ao dono escrever e ler sempre de um ficheiro, o cliente controla as permissões.
• Ficheiros removidos continuam acessíveis em Unix. Em NFS cliente muda a operação para um rename, e no fim um remove. Problema: cliente pode crashar, arquivos temporários.
• Reads e writes podem involver várias operações e não são portanto atómicos entre clientes: usar NLM.

Problemas de Performance de NFS

Problemas:

• Operações que alteram o servidor são extremamente lentas porque esperam que os writes sejam colocados no armazenamento.
• obter atributos obriga a um RPC por ficheiro: problema com ls -l.
• Retransmissões podem piorar situação em redes sobrecarregadas.

Melhorando Performance de NFS

• Clientes fazem caching de dados. Perigoso: atributos são guardados no máximo de 1 min, e blocos de dados são válidos se a data de alteração não tiver sido mexida.
• Não atrasar cliente:
  • write() assíncrono para blocos completos;
  • atrasar write() de blocos parciais.
• Servidor pode usar NVRAM em vez de disco. Driver pode optimizar transferências de NVRAM para disco.
• Write-Gathering: servidor espera em vez de processar todos os writes de uma vez:
  • Aumenta latência;
  • Reduz número de escritas no servidor;
  • Útil se vários biods no cliente.

Cache de Retransmissões

Período de espera antes de retransmissão é muito curto (1-3sec):

• Pacotes perdidos podem acontecer com UDP.
• Operações idempotentes, como READ() podem ser executadas várias vezes, não há problema;
• não idempotentes, como CREATE ou REMOVE podem dar problemas.
• Solução: manter uma cache de pedidos que podiam dar problemas. Se pedido falha, verifica se é uma retransmissão e está na cache.
• Sun implementou solução incompleta: só verificava pedidos que falhassem;
• Digital faz cache de todos os pedidos e verifica sempre:
  • timestamps são usados para verificar se entrada é recente;
  • pedidos podem ser servidos de cache.

NFS: Extensões

• Existem servidores dedicados, alguns dos quais paralelos e com FS muito diferente de UFS.
• Problemas de segurança: UID e GID devem ser os mesmos em todo o grupo:
  • UID remapping;
  • Root remapping.
• NFSv3:
  • Writes asssíncronos como COMMIT:
    • WRITE é assíncrono;
    • dados só são retirados de cache quando cliente fecha arquivo;
    • aí cliente faz COMNIT
  • Usa campos de 64bits;
  • READDIRPLUS retorna info para todos os arquivos no directório;

Sistemas de Ficheiros Distribuídos