Sistemas Distribuídos

Sistemas Distribuídos Sistemas de Arquivos Distribuídos Joinvile Batista Junior Sistemas de Arquivos Distribuídos A : Características B : Requisitos C : Arquitetura D : Estudo de Caso: SUN NFS (Network File System) UFGD - SD 07 - Joinvile Batista Junior 2 1

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. UFGD - SD 07 - Joinvile Batista Junior 3 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, impressão UFGD - SD 07 - Joinvile Batista Junior 4 2

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 UFGD - SD 07 - Joinvile Batista Junior 5 Módulos de SA organizados em Camadas Directory module: File module: relates file names to file IDs relates file IDs to particular files Access control module: checks permission for operation requested File access module: Block module: Device module: reads or writes file data or attributes accesses and allocates disk blocks disk I/O and buffering UFGD - SD 07 - Joinvile Batista Junior 6 3

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 UFGD - SD 07 - Joinvile Batista Junior 7 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 UFGD - SD 07 - Joinvile Batista Junior 8 4

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. UFGD - SD 07 - Joinvile Batista Junior 9 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 independente do deslocamento de arquivos em servidores UFGD - SD 07 - Joinvile Batista Junior 10 5

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 UFGD - SD 07 - Joinvile Batista Junior 11 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 UFGD - SD 07 - Joinvile Batista Junior 12 6

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 UFGD - SD 07 - Joinvile Batista Junior 13 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 UFGD - SD 07 - Joinvile Batista Junior 14 7

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 UFGD - SD 07 - Joinvile Batista Junior 15 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 associada e qual o esquema adotado? UFGD - SD 07 - Joinvile Batista Junior 16 8

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 UFGD - SD 07 - Joinvile Batista Junior 17 Modelo de Arquitetura de Serviços de Arquivos Client computer Lookup AddName UnName GetNames Server computer Application program Application program Directory service Flat file service Client module Read Write Create Delete GetAttributes SetAttributes UFGD - SD 07 - Joinvile Batista Junior 18 9

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 UFGD - SD 07 - Joinvile Batista Junior 19 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 se servidor mantém direitos para acessos futuros não seria mais sem estado UFGD - SD 07 - Joinvile Batista Junior 20 10

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 UFGD - SD 07 - Joinvile Batista Junior 21 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 UFGD - SD 07 - Joinvile Batista Junior 22 11

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 UFGD - SD 07 - Joinvile Batista Junior 23 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? 3. Comente as medidas extras para uso do cache no servidor. UFGD - SD 07 - Joinvile Batista Junior 24 12

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 UFGD - SD 07 - Joinvile Batista Junior 25 Arquitetura NFS Client computer Server computer UNIX system calls UNIX kernel Application program Local Application program Virtual file system Remote UNIX kernel Virtual file system UNIX file system Other file system NFS client NFS protocol NFS server UNIX file system UFGD - SD 07 - Joinvile Batista Junior 26 13

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 UFGD - SD 07 - Joinvile Batista Junior 27 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 /usr/students/jon e /usr/staff/ann UFGD - SD 07 - Joinvile Batista Junior 28 14

Acesso Local e Remoto de Sistemas de Arquivos Server 1 (root) Client Server 2 (root) (root) export... vmunix usr nfs people Remote mount students x staff Remote mount users big jon bob... jim ann jane joe UFGD - SD 07 - Joinvile Batista Junior 29 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 replicação pode ser utilizada para proporcionar um grau limitado de tolerância a falhas e balanceamento de carga UFGD - SD 07 - Joinvile Batista Junior 30 15

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 UFGD - SD 07 - Joinvile Batista Junior 31 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 UFGD - SD 07 - Joinvile Batista Junior 32 16

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 UFGD - SD 07 - Joinvile Batista Junior 33 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 suporte para stream de dados e qualidade de serviço UFGD - SD 07 - Joinvile Batista Junior 34 17