Sistemas Distribuídos

(1)

Sistemas Distribuídos

Sistemas de Arquivos Distribuídos

Joinvile Batista Junior

Sistemas de Arquivos Distribuídos

 A : Características  B : Requisitos  C : Arquitetura

(2)

UFGD - SD 07 - Joinvile Batista Junior 3

A : Características

1. O que caracteriza um sistema de arquivo distribuído básico. Quais suas restrições?

2. Comente o conceito de abstração do arquivo. Enumere os

componentes adicionais de um sistema de arquivos distribuído, em relação a um sistema convencional.

Sistemas de Arquivos Distribuídos

• um sistema de arquivo distribuído básico

– permite que os programas armazenem e acessem arquivos remotos como se fossem locais

– possibilitando que os usuários acessem seus arquivos a partir de qualquer computador em uma intranet

– requisitos restritos

• não mantém várias réplicas persistentes (replicação)

• nem suportam garantia de largura de banda e temporização (fluxos de dados multimídia)

• a concentração de armazenamento persistente em alguns poucos servidores

– reduz a necessidade de armazenamento em disco local

– facilita o serviço de backup dos dados persistentes da organização – simplifica a interface para outros serviços: nomes, autenticação,

(3)

Características dos Sistemas de Arquivos (SAs)

• sistemas de arquivos são responsáveis por

– organização, armazenamento, atribuição de nomes, compartilhamento e proteção de arquivos

• fornecem API que caracteriza a abstração do arquivo

– liberando os programadores da preocupação com os detalhes • da alocação e do layout do armazenamento físico no disco • em um sistema de arquivos não-distribuídos em um SO convencional

– organização de módulos em camadas funcionais

• uma camada depende somente das camadas inferiores • a implementação de um SA Distribuído tem componentes adicionais

– para tratar da comunicação cliente-servidor

– e da atribuição de nomes e da localização de arquivos distribuídos

Módulos de SA organizados em Camadas

Directory module: relates file names to file IDs File module: relates file IDs to particular files

Access control module: checks permission for operation requested File access module: reads or writes file data or attributes Block module: accesses and allocates disk blocks Device module: disk I/O and buffering

(4)

Características dos Sistemas de Arquivos (SAs)

• os sistemas de arquivos são projetados para armazenar e gerenciar um

grande número de arquivos

– com recursos para: criação, atribuição de nomes e exclusão de arquivos

– a atribuição de nomes de arquivos é suportada pelo uso de diretórios

– responsabilidade pelo controle de acesso aos arquivos • restringindo o acesso de acordo com as autorizações dos

usuários

• e do tipo de acesso requisitado: leitura, escrita, execução • um diretório é um arquivo especial

– que fornece um mapeamento de nomes textuais para identificadores internos de arquivo

– podem incluir nomes de outros diretórios: hierarquia de nomes

Características dos Sistemas de Arquivos (SAs)

• arquivos contém atributos mantidos em um único registro

– contendo informação de

• tamanho de arquivo, indicações de tempo, tipo de arquivo, identidade do proprietário e listas de controle de acesso • em caracter ilustrativo: principais operações sobre arquivos do UNIX

– chamadas de sistema implementadas pelo núcleo

• acessadas pelos aplicativos como funções de biblioteca – são baseados em informações sobre o estado do arquivo

• consistem em uma lista de arquivos correntemente abertos • e um ponteiro de leitura e escrita

– que fornece a posição da próxima operação de leitura e escrita

(5)

B : Requisitos

1. Comente os requisitos de transparência para Sistemas de Arquivos Distribuídos: acesso, localização, mobilidade.

2. Comente um Sistemas de Arquivos Distribuídos moderadamente tolerante a falhas. Qual o problema associado à desconexão? 3. Explique o requisito de consistência para Sistemas de Arquivos

Distribuídos e qual o problema decorrente da replicação.

Requisitos do Sistema de Arquivos Distribuídos

Transparência

• serviço mais usado em uma intranet

– portanto: funcionalidade e desempenho críticos

– contrabalançar transparência (flexibilidade e escalabilidade) com a complexidade e o desempenho do software

• transparência de acesso

– acesso local e remoto indistinto

• programas não devem conhecer a distribuição dos arquivos • transparência de localização

– mesmo espaço de nomes

(6)

Requisitos do Sistema de Arquivos Distribuídos

Transparência

• transparência de mobilidade

– não precisam ser alterados quando os arquivos são movidos • programas clientes

• tabelas de administração de sistema no nós clientes • transparência de desempenho

– programas devem continuar a funcionar

• enquanto a carga sobre o serviço varia dentro de um intervalo especificado

• transparência de mudança de escala

– o serviço pode ser expandido de forma paulatina

• para tratar com uma ampla variedade de cargas e tamanhos de rede

Requisitos do Sistema de Arquivos Distribuídos

Atualizações concorrentes de arquivos

• as alterações feitas em um arquivo por um cliente não devem interferir na operação de outros clientes

• a maior parte dos SAs atuais segue os padrões UNIX

– fornecendo travamento (locking) em nível de arquivo e em nível de registro

Replicação de arquivos

• em um SA que suporta replicação

– um arquivo pode ser representado por várias cópias do seu conteúdo em diferentes locais

• duas vantagens: compartilhamento de carga e tolerância a falhas • poucos servidores suportam replicação completa

– mas a maioria suporta uma forma de replicação limitada

• armazenamento de arquivos (ou de porções de arquivos) em caches locais

(7)

Requisitos do Sistema de Arquivos Distribuídos

Tolerância a falhas

• por ser parte essencial nos SDs

– é essencial que o SA Distribuídos continue a funcionar diantes das falhas dos clientes e dos servidores

• um projeto moderadamente tolerante à falhas

– baseado na semântica de invocação no máximo uma vez (não resposta retorna exceção)

– ou na semântica de pelos menos uma vez com um protocolo baseado em operações idempotentes (duplicação não causa erro)

• para garantir que solicitações duplicadas não resultem em atualizações inválidas

• a tolerância às falhas de desconexão ou de um servidor é mais dificil de obter

– exige replicação do arquivo

Requisitos do Sistema de Arquivos Distribuídos

Heterogeneidade do hardware e do SO

• sistemas abertos: interfaces do serviço devem permitir a implementação para diferentes SO e computadores Consistência

• os SAs convencionais (ex: fornecido pelo UNIX) oferecem semântica de atualização por uma única cópia

– arquivo visto por todos os processos como se existisse apenas uma única cópia

• quando os arquivos são replicados, ou armazenados em cache, em diferentes sites

– há um atraso inevitável na propagação das modificações: feitas em um site para outros sites

• que poderá resultar um certo desvio da semântica da cópia única

(8)

Requisitos do Sistema de Arquivos Distribuídos

Segurança

• praticamente todos os SAs fornecem mecanismos de controle baseados no uso de listas de controle de acesso

• nos SAs Distribuídos

– há necessidade de autenticar as requisições dos clientes • para garantir o acesso a usuários com permissão de acesso • e para proteger o conteúdo das mensagens de requisição e

respostas com assinaturas digitais

– e opcionalmente com criptografia de dados secretos Eficiência

• objetivo para SAs Distribuídos

– uma performance comparável a um sistema de arquivos locais

C : Arquitetura

1. Conceitue arquitetura de modelo abstrato para um serviço arquivos e seus componentes.

2. Comente os 2 métodos utilizados para controle de acesso do usuário em Sistemas de arquivos distribuídos. Qual a vulnerabilidade

(9)

Arquitetura do Serviço de Arquivos

• modelo abstrato para um serviço de arquivos

– abstraindo as preocupações com a implementação • e fornecendo um modelo simplificado

– uma arquitetura baseada em 3 componentes • serviço de arquivos (flat files)

– operações sobre o conteúdo dos arquivos

– utiliza identificadores únicos (em um SD) de arquivo » UFIDs (unique file identifiers)

• serviço de diretório

– mapeamento de nomes textuais e seus UFIDs • módulo cliente

– executado em cada computador cliente

– extendendo as APIs do serviço de arquivos e de diretórios » para um interface de programação única

– também contém informações sobre os locais de rede » dos processos dos servidores de arquivo e diretório

Modelo de Arquitetura de Serviços de Arquivos

Client computer Server computer

Application program

Client module

Flat file service Directory service Lookup AddName UnName GetNames Read Write Create Delete

(10)

API RPC (Remote Procedure Call) do Serviço de Arquivos

• Read (FileId, first_element, n_elements)  Data

– lê uma sequência de n elementos de um arquivo a partir de first_element

– Exceção BadPosition: para first_element inválido • Write (FileId, first_element, Data)

– grava uma sequência de Data de um arquivo a partir de first_element

• ampliando o arquivo se necessário – Exceção BadPosition: idem

• Create ()  FileId

– Cria um arquivo de tamanho 0 e retorna seu UFID • Delete (FileId)

– remove arquivo

• GetAttributes (FileId)  Attr – retorna os atributos do arquivo • SetAttributes (FileId, Attr)

– configura alguns atributos do arquivo

• não configura: tamanho e indicação de tempo

API RPC do Serviço de Arquivos

• interface funcionalmente equivalente às primitivas do UNIX com algumas diferenças fundamentais

• operações podem ser repetidas: são idempontentes – uso de semântica RPC “pelo menos uma vez”: clientes

podem repetir chamada sem resposta

– com exceção de Create: que produz um novo arquivo • servidores sem estado

– servidor pode ser reiniciado após falha: sem necessidade dos clientes e do servidor restaurarem estado

• controle de acesso

– no UNIX os direitos de acesso são verificados em relação ao modo de acesso (leitura ou escrita) na chamada do open

• os direitos de acesso são mantidos até o arquivo ser fechado – em SDs as verificações não precisam ser no servidor

(11)

API RPC do Serviço de Arquivos

• estratégias para controle de acesso nas requisições

– verificação de acesso quando nome do arquivo é convertido em UFID e resultados codificados em capacidade

• que é retornada para o cliente para envio em requisições subsequentes

– identidade do usuário é enviada com cada requisição de cliente • e as verificações de acesso são realizadas pelo servidor

– para cada operação de arquivo

• os 2 métodos permitem implementação de um servidor sem estado – e tem sido utilizados em SDs Distribuídos

– mas o segundo é mais comum: utilizado no NFS

• nenhuma destas estratégias resolve a vulnerabilidade à identidades de usuários falsificadas

– Kerberos é uma esquema de autenticação eficaz usado no NFS

API RPC do Serviço de Diretórios

• Lookup (Dir, Name)  FileId

– retorna o UFID correspondente ao Name no diretório – Exceção NotFound: se Name não estiver no diretório • AddName (Dir, Name, FileId)

– adiciona arquivo FileId com Name no diretório

– Exceção NameDuplicate: se Name já estiver no diretório • UnName (Dir, Name)

– remove a entrada Name do diretório

– Exceção NotFound: se Name não estiver no diretório • GetNames (Dir, Pattern)  NameSeq

– retorna todos os nomes textuais presentes no diretório • que correspondam à expressão regular Pattern

(12)

API RPC do Serviço de Diretórios

• sistema de arquivos hierárquico: equivalente ao do UNIX

– diretórios organizados em uma estrutura de árvore – qualquer arquivo ou diretório

• pode ser localizado através de um caminho (pathname) • um sistema de atribuição de nomes como o do UNIX

– pode ser implementado pelo módulo cliente • através dos serviços de arquivo e diretório – uma hierarquia é construída

• com arquivos nas folhas e diretórios nos demais nós – atribuição de vários nomes a um arquivo através de AddName – função que o obtenha o UFID de uma arquivo a partir de um

caminho

• a função interpreta o nome do caminho a partir da raiz – utilizando Lookup

– em um diretório hierárquico

• os atributos dos arquivos devem incluir um campo que diferencie arquivo de diretório

D : Estudo de Caso: SUN NFS (Network File System)

1. Comente o controle de acesso do NFS: como funciona, sua brecha de

segurança e a solução encontrada.

2. Conceitue montagem de arquivos. Como funciona, no NFS, a solução de um nome de caminho que inclui um ponto de montagem vazio através da montagem automática?

(13)

Estudo de Caso: SUN NFS (Network File System)

• a arquitetura do NFS segue o modelo abstrato de serviço de arquivos

– todas as implementações NFS suportam o protocolo NFS – o protocolo NFS é independente de SO

• mas foi desenvolvido originalmente para uso em redes UNIX • o estudo de caso descreve a implementação UNIX do NFS • módulo servidor NFS

– reside no núcleo de cada computador que atua como servidor NFS • módulo cliente NFS

– transforma requisições de arquivos remotos em operações do protocolo NFS

– e repassa para módulo servidor NFS no computador que contém o SA em questão: comunicação por RPC

• sistema de arquivos virtual

– suporta transparência de acesso

• programas de usuário executam operações de arquivo – em arquivos locais e remotos, sem distinção – integra: SA do UNIX, Cliente NFS e outros SAs

Arquitetura NFS

UNIX kernel

protocol

Client computer Server computer

system calls Local Remote UNIX file system NFS client NFS server UNIX file system Application program Application program NFS UNIX UNIX kernel

Virtual file system Virtual file system

O th e r fi le s ys te m

(14)

Estudo de Caso: SUN NFS (Network File System)

Controle de Acesso e Autenticação

• ao contrário do SA UNIX convencional

– o servidor NFS é sem estado e não mantém arquivos abertos – a cada requisição, a servidor deve verificar novamente a identidade

do usuário

• nos atributos de permissão de acesso ao arquivo – o protocolo RPC Sun exige que os clientes enviem

• informações de autenticação do usuário em cada requisição • existe uma brecha de segurança neste mecanismo

– o cliente pode modificar as chamadas de RPC para incluir a ID de outro usuário

• personificando-o sem seu conhecimento ou permissão • solução para brecha de segurança

– inicial: criptografia DES das informações de autenticação do usuário – recente: integração com o Kerberos

Estudo de Caso: SUN NFS (Network File System)

Serviço de Montagem

• a montagem de subárvores de SAs remotos feita por clientes é suportada por um versão modificada do comando mount do UNIX

– que se comunica com o processo do serviço de montagem do host remoto

• protocolo RPC que inclui uma operação que recebe um nome de caminho de diretório

– e retorna o manipulador do arquivo do diretório: caso o cliente tenha permissão de acesso

• a figura do slide seguinte ilustra

– Cliente pode acessar arquivos no Servidor 1 e no Servidor 2 • usando respectivamente os nomes de caminho

(15)

Acesso Local e Remoto de Sistemas de Arquivos

jim ann jane joe users students usr vmunix Client Server 2 . . . nfs Remote mount staff

big jon bob people Server 1 export (root) Remote mount . . . x (root) (root)

Estudo de Caso: SUN NFS (Network File System)

Montagem Automática (automounter)

• monta dinamicamente um diretório remoto quanto um ponto de montagem “vazio” é referenciado pelo cliente

– mantém uma tabela de pontos de montagem (nomes de caminho) com referências para um ou mais servidores – quando o Módulo Cliente NFS tenta solucionar um nome de

caminho que inclui um desses pontos de montagem • faz um requisição de lookup para o automounter local

– que envia um pedido de sondagem (probe) para cada servidor remoto

• o SA do servidor que responder primeiro é então montado no cliente: utilizando o serviço de montagem normal

• o SA montado é associado ao ponto de montagem para evitar novas chamadas ao automounter

(16)

Estudo de Caso: SUN NFS (Network File System)

Uso do Cache no Servidor

• nos sistemas UNIX convencionais

– blocos de arquivos, diretórios e atributos de arquivos são mantidos em cache na memória principal

• até que o espaço de cache seja exigido por outros blocos – leitura antecipada (read-ahead): adianta acessos de leitura

• busca os blocos seguintes aos lidos mais recentemente – escrita postergada (delayed write): otimiza operações de escrita

• gravação do bloco alterado ocorrerá somente quando o espaço ocupado pelo bloco no cache for requisitado

– para evitar falha: periodicidade de 30 seg • os servidores NFS usam o cache da mesma forma

– mas para operações de escrita: medidas extras são necessárias

Estudo de Caso: SUN NFS (Network File System)

Uso do Cache no Servidor

• 2 opções para a operação write – escrita direta (write-through)

• gravados no disco antes que um resposta seja enviada ao cliente

– clientes podem continuar a operar quando um servidor falha

– operação de efetivação (commit)

• gravados no disco quando um commit for recebido para o arquivo

– opção para o gargalo decorrente de operações de escrita direta em servidores que recebem grandes quantidades de requisições

(17)

Estudo de Caso: SUN NFS (Network File System)

Uso do Cache no Cliente

• o Módulo Cliente NFS armazena em cache os resultados das operações: read, write, lookup, readdir

– para reduzir o número de requisições feitas aos servidores

• o uso de cache no cliente implica na possibilidade de existirem diversas versões de arquivos em diferentes nós clientes

– pois as gravações feitas por um cliente

• não resultam na atualização imediata em outros clientes • um método baseado em timestamps é usado para validar blocos

armazenados em cache antes de serem usados

Estudo de Caso: SUN NFS (Network File System)

• Sun NFS é um excelente exemplo de um serviço distribuído

– simples, robusto, com alta performance

– atende muitos requisitos importantes de projeto • Cache eficiente de cliente

– pode resultar em uma performance igual ou superior a sistemas de arquivos locais

• A maioria das falhas de cliente e servidor podem ser contornadas • Requisitos Futuros

– suporte para usuários móveis, operação de desconexão e reintegração automática