Nomes. Fernando Silva DCC-FCUP. Fernando Silva (DCC-FCUP) Nomes 1 / 45

Transcrição

1 Nomes Fernando Silva DCC-FCUP Fernando Silva (DCC-FCUP) Nomes 1 / 45

2 Agenda Slides baseados nos slides de Maarten van Steen e no cap. 5 do seu livro com Andrew Tanenbaum. Fernando Silva (DCC-FCUP) Nomes 2 / 45

3 Porquê nomes? Um sistema distribuído (SD) envolve um conjunto grande de recursos partilhados com os quais tem de interagir. Os nomes permitem identificar e localizar de forma transparente os recursos de um SD. Por exemplo, como é que um cliente sabe onde encontrar um servidor? Soluções possíveis: endereço do servidor gravado no cliente - nada flexível! endereço do servidor passado como parâmetro na chamada do cliente - mais flexível ficheiro de configuração através de broadcast ou multicast através de um serviço de localização/nomes Fernando Silva (DCC-FCUP) Nomes 3 / 45

4 Nomes Nomes representam entidades/objectos num SD Uma entidade num SD pode ser praticamente qualquer coisa: e.g. ficheiros, processos, computadores, periféricos, páginas web, endereço de , url, username,... O acesso a uma entidade faz-se através de um ponto de acesso. Os endereços são nomes de pontos de acesso. Importante: referenciar entidades por um endereços é mau porque é frequente mudarem com os pontos de acesso (transf. de serviços) passa a haver dependência em relação ao ponto de acesso um nome de uma entidade E é independente da localização se não depender dos endereços de qualquer ponto de acesso oferecido por E. Fernando Silva (DCC-FCUP) Nomes 4 / 45

5 Identificadores Nome puro: é um nome que não tem qualquer semântica associada; é apenas uma sequência de símbolos aleatória. Um Identificador é um nome com as propriedades seguintes: P1 cada identificador refere-se a no máximo uma entidade; P2 cada entidade é referida por pelo menos um identificador; P3 um identificador refere-se sempre à mesma entidade (proíbe a re-utilização de um identificador) Observação: um identificador não precisa necessariamente de um nome puro, i.e. pode ter conteúdo. Questão: pode mudar-se o conteúdo de um identificador? Sim, desde que não se viole P1-P3. Fernando Silva (DCC-FCUP) Nomes 5 / 45

6 Espaço de nomes Um espaço de nomes define a sintaxe e estrutura do conjunto de nomes possíveis; mantém um conjunto de atribuições (bindings) dum nome a um objecto/entidade. O espaço de nomes pode ser: plano - nomes únicos, possivelmente aleatórios nomes não contêm qualquer informação sobre como localizar o ponto de acesso de uma entidade implementações escaláveis são recentes (DHTs) estruturado - quando os nomes constituem uma estrutura hierárquica ou formam um grafo acíclico dirigido (DAG). exemplos: sistemas de ficheiros, DNS, etc. Fernando Silva (DCC-FCUP) Nomes 6 / 45

7 Resolução de nomes E como é que determinamos o endereço associado a um nome? Resolução de nomes procedimento para determinar o objecto/entidade associado a um nome. simplisticamente, é uma tabela de pares (nome,endereço do objecto/entidade) faz-se sempre no contexto de um espaço de nomes Fernando Silva (DCC-FCUP) Nomes 7 / 45

8 Sistemas de nomes planos Os sistemas peer-to-peer foram os catalisadores destes sistemas, contribuindo com algoritmos eficientes e escaláveis para resolução de nomes planos. Questão principal a resolver: dado um nome não estruturado (e.g. um identificador), como é que podemos localizar o seu ponto de acesso (ou objecto associado)? Com: soluções simples (e.g. broadcast)) soluções home-based soluções DHT/P2P (distributed hash table) soluções de localização hierárquicas. Fernando Silva (DCC-FCUP) Nomes 8 / 45

9 Soluções simples Broadcasting: propagar o identificador da entidade, e esperar que a máquina que contem a entidade retorne o endereço do seu ponto de acesso. princípio análogo ao protocolo ARP (end. IP end. Ethernet) não é escalável para lá da rede local todos os processos têm de ouvir os pedidos locais a chegar ineficiente com o crescimento da rede; mudar para multicast Links de encaminhamento: de cada vez que uma entidade se move, deixa referências a dizer para onde foi. torna transparente a des-referenciação para os clientes permite que os clientes actualizem a sua referência problemas: cadeias podem tornar-se longas e falhar dispersão geográfica aumenta latência da rede Conveniente ter mecanismos de redução das cadeias de links. Fernando Silva (DCC-FCUP) Nomes 9 / 45

10 Encaminhamento: proxy/skeleton O princípio dos links de encaminhamento baseia-se nos pares (client-stub, server-stub) Fernando Silva (DCC-FCUP) Nomes 10 / 45

11 Encaminhamento: redireccionamento Redirecciona o encaminhamento guardando um atalho num cliente-stub. Fernando Silva (DCC-FCUP) Nomes 11 / 45

12 Solução home-based (1) Especialmente útil para suportar mobilidade de entidades em redes de grande escala. Esquema a um nível: Cada entidade tem uma home, normalmente o servidor de nomes onde foi criada. a home regista os endereços externos da entidade os clientes contactam primeiro a home, e depois continuam directamente para a localização corrente. Fernando Silva (DCC-FCUP) Nomes 12 / 45

13 Exemplo: princípio da mobilidade IP Fernando Silva (DCC-FCUP) Nomes 13 / 45

14 Solução home-based (2) Esquema a dois-níveis: tomar nota das entidades visitantes verificar primeiro localmente o registo voltar à localização home se a verificação local falhar Dificuldades com as abordagens home-based: o endereço home tem de ser mantido enquanto a entidade existir. o endereço home é fixo, o que cria dificuldades quando a entidade muda de forma permanente para outra localização. fraca expansibilidade geográfica (a entidade pode estar próxima do cliente) Como resolver o problema de mudanças permanentes? Uma solução pode ser introduzir um segundo nível de nomes (DNS). Fernando Silva (DCC-FCUP) Nomes 14 / 45

15 Distributed Hash Tables (DHT) uma DHT é uma estrutura de dados análoga a uma hash-table cada entrada da tabela associa uma chave única a endereço a operação mais importante é a de localização: lookup(key) - retorna o endereço associado a key através do endereço podemos operar sobre a entidade/objecto. Fernando Silva (DCC-FCUP) Nomes 15 / 45

16 Exemplo de DHT: Chord O Chord organiza os nós da rede como um anel lógico. Usa identificadores com m-bits ordenação circular em aritmética mod2 m. cada nó tem um identificador (id) aleatório com m-bits. cada entidade/objecto tem também uma chave com m-bits. uma entidade com chave k, fica sob jurisdição do nó com o menor id k (chamado succ(k)) Fernando Silva (DCC-FCUP) Nomes 16 / 45

17 Chord: Finger Table Questão principal: Como determinar eficientemente o succ(k) para uma chave k dada? Não é solução colocar cada nó k a manter informação sobre o seu sucessor. É linear e não escalável. Uma solução é ter em cada nó-p uma finger-table FT p [] com as m entradas FT p [i] = succ(p + 2 i 1 ) FT p [1] é o sucessor de p no anel circular. Para localizar uma chave k, o nó p envia o pedido para: o seu sucessor, i.e. FT p [1], se p < k < FT p [1] o nó-q cujo índice j satisfaz q = FT p [j] k < FT p [j + 1] Requer O(log(N )) passos, sendo N o número de nós. Fernando Silva (DCC-FCUP) Nomes 17 / 45

18 Exemplo: Chord Actual node Resolve k = 12 from node Finger table i i-1 succ(p + 2 ) Resolve k = 26 from node Fernando Silva (DCC-FCUP) Nomes 18 / 45

19 Chord: problemas A complexidade do Chord advém da manutenção das finger-tables actualizadas. Chord funciona correctamente, se FT q [1] for mantido correcto para q. importante actualizar FTq [1] o processo é mais simples se se tiver informação sobre o predecessor. regularmente, um nó q envia uma mensagem ao seu sucessor e actualiza os elementos de FT q [] Avaria de um nó. Para lidar com este problema, cada nó pode manter uma lista de sucessores. Fernando Silva (DCC-FCUP) Nomes 19 / 45

20 Exploração da proximidade na rede Muitos sistemas P2P, como é o Chord, usam uma rede virtual (overlay network) que, normalmente, não tem em conta a rede física sobre a qual é construída, i.e. a Internet. Em consequência Soluções: as mensagens podem seguir um caminho errático e pouco eficiente. 1 Atribuição dependente da topologia, nós próximos são atribuídos identificadores próximos. 2 Encaminhamento por proximidade manter mais do que um possível sucessor e encaminhar para o mais próximo. e.g., em Chord, FT p [i] referencia o primeiro nó de INT = [p + 2 i 1, p + 2 i ]. 3 Selecção dos vizinhos com base na proximidade. Fernando Silva (DCC-FCUP) Nomes 20 / 45

21 Serviços de localização hierárquicos (HLS) Ideia base: construir uma árvore de pesquisa de grande escala, em que a rede subjacente esteja dividida em domínios hierárquicos. The root directory node dir(t) Top-level domain T Directory node dir(s) of domain S A subdomain S of top-level domain T (S is contained in T) A leaf domain, contained in S Cada domínio é representado por um nó do tipo directório. Fernando Silva (DCC-FCUP) Nomes 21 / 45

22 HLS: Organização em árvore o endereço de uma entidade é armazenado num nó-folha, ou nó intermédio. nós intermédios contêm um apontador para um nó-filho se e só se a sub-árvore que daí descende armazenar o endereço da entidade. a raíz sabe tudo sobre as entidades. Field for domain dom(n) with pointer to N Field with no data Location record for E at node M M N Location record with only one field, containing an address Domain D1 Domain D2 Fernando Silva (DCC-FCUP) Nomes 22 / 45

23 HLS: Operação de lookup Princípios básicos: iniciar a procura no nó-folha local se o nó conhecer a entidade, colocar um apontador para o filho, senão sobe um nível procuras ascendentes param sempre na raíz Node has no record for E, so that request is forwarded to parent Node knows about E, so request is forwarded to child M Look-up request Domain D Fernando Silva (DCC-FCUP) Nomes 23 / 45

24 HLS: Operação de inserção (a) o pedido de inserção é encaminhado para o primeiro nó que conhece E, (b) e é criada uma cadeia de links-forward dirigida ao nó-folha. Fernando Silva (DCC-FCUP) Nomes 24 / 45

25 Espaço de nomes estruturados (1) São representados por DAGs (Direct Acyclic Graphs) nós-folha representam entidades nós-directório representam entidades que referem outras entidades. Contêm uma tabela de pares (nome do ramo, identificador do nó). Fernando Silva (DCC-FCUP) Nomes 25 / 45

26 Espaço de nomes estruturados (2) Num nó podemos guardar atributos que caracterizam a entidade que o nó representa: tipo de uma entidade identificador dessa unidade endereço da localização da entidade abreviaturas... Os directórios também podem conter atributos, além da tabela de directório. Fernando Silva (DCC-FCUP) Nomes 26 / 45

27 Resolução de nomes Dificuldade: Para resolver um nome, precisamos de um nó-directório. Como é que encontramos o nó inicial? Mecanismo de fecho (closure mechanism): É o mecanismo de selecção de um contexto implícito que informa onde podemos começar a resolução de nomes: - iniciar no servidor de DNS /home/fds/mail - iniciar no servidor NFS local A resolução de um nome corresponde a seguir-se um caminho de nomes específico num grafo de nomes de um nó origem a um nó destino. Fernando Silva (DCC-FCUP) Nomes 27 / 45

28 Nomes absolutos vs. relativos Um nó N i num espaço de nomes pode ser designado por um caminho (pathname) em relação a outro nó N j : corresponde à concatenação dos nomes dos ramos do caminho entre os dois nós: N i :< nome 1, nome 2,..., nome n > Se N i for o nó raíz, o caminho ou nome diz-se absoluto, caso contrário diz-se relativo. as convenções para separar os nomes são dependentes dos sistemas. O DNS usa o. e o Linux usa /. Fernando Silva (DCC-FCUP) Nomes 28 / 45

29 Links e aliases Um alias corresponde a um novo nome para uma entidade. Pode ser concretizado com: Hard-link - dois ou mais caminhos no grafo para referir uma entidade Soft-link (ou Symbolic link) - um nó-folha guarda um caminho absoluto de nomes que nos levam até outro nó. Data stored in n1 n2: "elke" n3: "max" n4: "steen" n1 home n0 keys n5 "/keys" elke max steen Leaf node Directory node n2 n3.twmrc mbox n4 Data stored in n6 keys "/keys" n6 "/home/steen/keys" O nó n5 tem apenas um nome. Fernando Silva (DCC-FCUP) Nomes 29 / 45

30 Implementação do espaço de nomes (1) Importante: Para sistemas de grande escala, é natural ter-se o processo de resolução de nomes bem como a gestão do espaço de nomes distribuído por múltiplas máquinas. Isto corresponde a fazer a distribuição de nós do grafo de nomes. A distribuição do espaço de nomes é normalmente hierárquica e inclui três níveis: Nível Global: formado pelos nós-directório dos níveis mais altos (nó raíz e outros nós logicamente próximos): têm de ser geridos por diferentes organizações. nós estáveis, raramente mudam. Nível Administrativo: formado por nós-directório intermédios que pertencem a um mesmo grupo organizacional (administrativo). relativamente estáveis, mas menos do que no nível global. Nível de Gestão: inclui os nós-directório do nível mais baixo de um mesmo grupo administrativo e que podem ser mapeados em servidores de nomes locais. Mudam com maior regularidade. Fernando Silva (DCC-FCUP) Nomes 30 / 45

31 Um exemplo de divisão do espaço de nomes (DNS) em três camadas. As zonas são independentes e podem ser implementadas por um servidor de nomes diferente. Fernando Silva (DCC-FCUP) Nomes 31 / 45 Implementação do espaço de nomes (2) Global layer com edu gov mil org net jp us nl sun yale acm ieee ac co oce vu Administrational layer eng ai cs linda eng jack jill keio cs nec csl ftp cs www robot pc24 pub Managerial layer Zone globe index.txt

32 Distribuição do espaço de nomes Os servidores de nomes nas diferentes camadas têm requisitos diferentes. Item Global Administrational Managerial Geographical scale Worldwide Organization Department # Nodes Few Many Vast numbers Responsiveness Seconds Milliseconds Immediate Update propagation Lazy Immediate Immediate # Replicas Many None or few None Client-side caching? Yes Yes Sometimes Questões relativas a eficiência: alta disponibilidade e elevado desempenho é crucial nas camadas mais altas. recorrer à replicação de servidores para assegurar disponibilidade recorrer a caching do lado do cliente para melhorar desempenho, sobretudo quando existe dispersão geográfica Fernando Silva (DCC-FCUP) Nomes 32 / 45

33 Resolução iterativa de nomes resolve(dir,[name1,...,namek]) é enviado para Server0 responsável por dir Server0 resolve resolve(dir,name1) dir1, devolvendo o identificador (endereço) de Server1, que contém dir1. cliente envia resolve(dir1,[name2,...,namek]) para Server1,... <nl,vu,cs,ftp> Client's name resolver 1. <nl,vu,cs,ftp> 2. #<nl>, <vu,cs,ftp> 3. <vu,cs,ftp> 4. #<vu>, <cs,ftp> 5. <cs,ftp> 6. #<cs>, <ftp> 7. <ftp> 8. #<ftp> #<nl,vu,cs,ftp> Root name server Name server nl node Name server vu node Name server cs node Nodes are managed by the same server Fernando Silva (DCC-FCUP) Nomes 33 / 45 ftp cs vu nl

34 Resolução recursiva de nomes resolve(dir,[name1,...,namek]) é enviado para Server0 responsável por dir Server0 resolve resolve(dir,name1) dir1 e envia resolve(dir1,[name2,...,namek]) para Server1, que contém dir1. Server0 espera pelo resultado de Server1, e devolve-o ao cliente. 1. <nl,vu,cs,ftp> 8. #<nl,vu,cs,ftp> Root name server 2. <vu,cs,ftp> Client's name resolver 7. #<vu,cs,ftp> 6. #<cs,ftp> Name server nl node Name server vu node 3. <cs,ftp> 4. <ftp> 5. #<ftp> Name server cs node <nl,vu,cs,ftp> #<nl,vu,cs,ftp> Fernando Silva (DCC-FCUP) Nomes 34 / 45

35 Caching na Resolução recursiva de nomes #<nl,vu,cs,ftp> Server Should Looks up Passes to Receives Returns for node resolve child and caches to requester cs <ftp> #<ftp> #<ftp> vu <cs,ftp> #<cs> <ftp> #<ftp> #<cs> #<cs, ftp> nl <vu,cs,ftp> #<vu> <cs,ftp> #<cs> #<vu> #<cs,ftp> #<vu,cs> #<vu,cs,ftp> root <nl,vu,cs,ftp> #<nl> <vu,cs,ftp> #<vu> #<nl> #<vu,cs> #<nl,vu> #<vu,cs,ftp> #<nl,vu,cs> os servidores de nomes intervenientes fazem caching de resultados para uso subsequente na resolução iterativa de nomes, apenas é possível fazer caching no resolutor que inicia o processo. Fernando Silva (DCC-FCUP) Nomes 35 / 45

36 Desempenho e Escala Para melhorar o desempenho e capacidade de escala: limitar a carga nos servidores de nomes limitar quantidade de comunicação necessária fazer particionamento, dividindo o espaço de nomes por múltiplos servidores usar replicação, mantendo cópias em múltiplos servidores usar caching, especialmente nos níveis mais altos da hierarquia Tolerância a falhas: usar replicação (servidor primário e secundário) Fernando Silva (DCC-FCUP) Nomes 36 / 45

37 Escala geográfica A resolução de nomes tem de funcionar mesmo quando estão envolvidas grandes distâncias geográficas entre servidores. Comparação dos processos iterativo e recursivo de resolução de nomes,no que respeita os custos de comunicação. Client Recursive name resolution Iterative name resolution R1 I1 I2 I3 Name server nl node Name server vu node Name server cs node R2 R3 Long-distance communication Fernando Silva (DCC-FCUP) Nomes 37 / 45

38 Exemplo: DNS descentralizado DNS Espaço de nomes usado na Internet para identificar objectos/entidades. Estrutura: hierárquica (em árvore) domínios de topo (TLD) (.com,.org,.net,.pt,...) zonas - sub-árvore resultante da partição da hierarquia (corresponde a uma autoridade administrativa) registo de recursos: conteúdo dos nós domínio: sub-árvore da árvore global nome do domínio: caminho absoluto de nomes Particionamento: cada zona é implementada por um servidor de nomes Fernando Silva (DCC-FCUP) Nomes 38 / 45

39 Exemplo: DNS descentralizado (2) Replicação: cada zona é replicada em pelo menos dois servidores updates feitos pelo servidor primário conteúdo passa para o secundário através de zonas de transferência Conteúdo de nó (registo DNS): SOA Zone Holds info on the represented zone A Host IP addr. of host this node represents MX Domain Mail server to handle mail for this node SRV Domain Server handling a specific service NS Zone Name server for the represented zone CNAME Node Symbolic link PTR Host Canonical name of a host HINFO Host Info on this host TXT Any kind Any info considered useful Fernando Silva (DCC-FCUP) Nomes 39 / 45

40 Exemplo da base de dados do DNS (3) Fernando Silva (DCC-FCUP) Nomes 40 / 45

41 Exemplo: DNS descentralizado (4) Caching: os servidores fazem cache dos resultados de procuras as entradas originais têm um time-to-live (TTL) dados em cache mantidos até expirar TTL dados em cache não são mandatórios (no-authoritative) Resolução de nomes: procura dirigida primeiro ao servidor local se não puder resolver, envia para a raíz resolução recursiva ou iterativa Fernando Silva (DCC-FCUP) Nomes 41 / 45

42 DNS no Pastry (1) Pastry: é um sistema P2P baseado em DHTs que trabalha com prefixos de chaves. Considere-se as chaves num espaço de números com 4 digitos. Um nó com ID 3210 toma nota dos seguintes nós: Nota: o nó 3210 é responsável pelas chaves com prefixo 321. Se receber um pedido para a chave 3012, encaminha-o para o nó n 30. DNS: um nó responsável pela chave k guarda nos registos DNS dos nomes cujo valor de hash é k. Os espaço de nomes fica completamente descentralizado, mas como conseguir que a resolução seja constante? Fernando Silva (DCC-FCUP) Nomes 42 / 45

43 DNS no Pastry (2) Replicação no nível i: o registo é replicado para todos os nós com i encaixes de prefixos. (Nota: número de hops para pesquisa de um registo no nível i é geralmente i.) Conhecendo os nomes de DNS mais populares, permite definir uma estratégia de replicação de nós (distribuição Zipf) que permite reduzir o número de hops numa procura. Exemplo para uma rede com cerca de 10,000 nós e 1,000,000 de registos de DNS: assim, em média apenas precisamos de 1 hop para resolver nomes. Fernando Silva (DCC-FCUP) Nomes 43 / 45

44 Sistemas de nomes baseados em atributos Em muitas situações, é mais conveniente nomear e procurar entidades através dos seus atributos. Por analogia é o que acontece com directórios de serviços (e.g. páginas-amarelas). Problema: as operações de procura podem ser pouco eficientes pois requerem a verificação dos valores dos atributos com os valores guardados no sistema. Isto pode, em princípio, implicar inspecionar todas as entidades. Solução: implementar o serviço de directório como uma base de dados e combiná-lo com sistemas tradicionais de nomes estruturados. Exemplo: sistema LDAP (Lightweight directory access protocol). Muito usado para partilha de informação sobre utilizadores, sistemas, redes, serviços e aplicações na rede. Fernando Silva (DCC-FCUP) Nomes 44 / 45

45 Exemplo LDAP Fernando Silva (DCC-FCUP) Nomes 45 / 45