verteilte systeme distributed systems
play

Verteilte Systeme (Distributed Systems) Karl M. Gschka - PowerPoint PPT Presentation

Verteilte Systeme (Distributed Systems) Karl M. Gschka Karl.Goeschka@tuwien.ac.at http://www.infosys.tuwien.ac.at/teaching/courses/ VerteilteSysteme/ Lecture 5: Naming and Discovery Name, Address, Identifier Name Space and Name


  1. Verteilte Systeme (Distributed Systems) Karl M. Göschka Karl.Goeschka@tuwien.ac.at http://www.infosys.tuwien.ac.at/teaching/courses/ VerteilteSysteme/

  2. Lecture 5: Naming and Discovery  Name, Address, Identifier  Name Space and Name Resolution (DNS)  Directory Services (X.500/LDAP)  Discovery Services  Distributed Garbage Collection

  3. Naming and discovery  Identify and locate resources for communication and resource sharing  Location transparency  Scalability and performance  DNS, NDS, ADS, X.500, LDAP, JNDI, JINI, UDDI, ...  Dealing with mobile entities  Removal of unreferenced entities 3

  4. Types of names  Names: string to refer to an entity  often human readable  Entities  can be operated on (via access points)  have attributes  Address: name (location) of an access point  for short: address of an entity  address as name of an entity?  Identifier (often machine-readable)  refers to at most one entity  each entity has only one identifier  always refers to the same entity (never re-used) 4

  5. Composed naming domains URL http://www.cdk3.net:8888/WebExamples/earth.html DNS lookup Resource ID (IP number, port number, pathname) 55.55.55.55 8888 WebExamples/earth.html Web server Network address file 2:60:8c:2:b0:5a Socket 6

  6. Properties of names  Location-independence (transparency)  Name independent from address  Do not encode address in name  IP addresses are not location-independent (are they?)  Uniqueness (how to achieve?)  Static assignment of ranges of names (convention)  Use compound names  Use contexts or domains  Use an id generation algorithm (sequence generator)  Flat or hierarchical name spaces  Simple and composite names; aliases  Pure names (no entity information at all)  Wildcards? Paths? 7

  7. How to implement identifiers  Keep a counter  What if machine fails?  Keep counter in stable storage  Use a random-number generator  high probability but not guaranteed  keep list of previously assigned names  Concurrency control  sequence generator  Distribution:  use creating node 8

  8. Lecture 5: Naming and Discovery  Name, Address, Identifier  Name Space and Name Resolution (DNS)  Directory Services (X.500/LDAP)  Discovery Services  Distributed Garbage Collection

  9. Name Spaces (1)  organizes names in a labeled, directed graph  name always relative to a directory node  leaf node:  named entity (attributes or state)  directory node:  labeled edges  node identifiers (directory table)  root node  path: sequence of labels  absolute vs. relative (with respect to root node)  global vs. local (relative to place of usage) 10

  10. Name Spaces (2)  A general naming graph:  only a single root?  acyclic?  strictly hierarchical (tree, no “links”)? 11

  11. Linking and Mounting  Alias  multiple absolute paths („hard link“)  leaf node stores absolute path name („symbolic link“)  Mounting  merge different name spaces  mount point: directory that stores identifier of directory node from foreign name space  To mount we need: access protocol, server, mounting point (each of these needs to be resolved!) 12

  12. Linking: Hard Link The concept of a hard link explained in a naming graph. 13

  13. Linking: Symbolic Link The concept of a symbolic link explained in a naming graph. 14

  14. Mounting /remote/vu/mbox Mounting remote name spaces through a specific protocol. 15

  15. Merging trees (e.g., GNS) home Organization of the DEC Global Name Service: Names always (implicitly) include the identifier of the node from where the resolution should start. 16

  16. Name resolution (1) The general organization of the UNIX file system implementation on a logical disk of contiguous disk blocks. 20

  17. Name resolution (2)  iterative process, whereby a name is repeatedly presented to naming contexts  naming context either maps  onto primitive attributes or  onto futher naming context  alias and cycles?  threshold number vs. strong administration  2 steps: name  node identifer  directory table (or leaf entity content)  e.g., inode  disk block/name  inode  e.g., IP  name server  IP  ... is provided by a name service 21

  18. Closure mechanism  Selection of the initial node  necessarily partly implicit!  Implicit sequence (UNIX indoes, superblock)  Implicit use of environment variables  Initial data in a pre-agreed file (config.txt)  Well-known port address  Well-known authority  Implicit method: Phone number  Implicit method: Multicast/Broadcast 22

  19. How to implement a name space?  A name service maintains a Name Attribute list/table or “database” of bindings for names  It allows the database to be updated or queried  Extensions:  More than one attribute?  Attribute-based lookup (discovery service)?  Scalability?  Fault-tolerance?  High-availability?  Access protection? 23

  20. Name service interface  resolve() or lookup():  mapping from name to data about the entity, e.g. address in order to access it  from human-readable to machine-readable  bind(), rebind() and unbind():  association between name and entity  names are usually bound to attributes (property values) of the entity rather than the entity itself, e.g. address in order to access it  e.g. DNS: domain name  IP address of host 24

  21. Simple name service algorithm  ARP: address resolution protocol IP address  Physical (MAC) address  broadcast-based  maintains local caches  correctness criterion: unique names  Scalability? initially, each node only knows binding for itself 26

  22. Dealing with large name spaces  Flat name space is not scalable (how many unique names are there?)  Broadcast as lookup is not scalable   hierarchical name spaces  Use naming contexts or domains to divide name space (e.g. www.infosys.tuwien.ac.at)  Structure supports management of name space according to organizational lines  Distributed name space management for scalability and availability 27

  23. Name Space Distribution (1) An example partitioning of the DNS name space, including Internet-accessible files, into three layers. 29

  24. Name Space Distribution (2) Item Global Administrational Managerial Geographical scale of network Worldwide Organization Department Total number of nodes Few Many Vast numbers Responsiveness to lookups Seconds Milliseconds Immediate Update propagation Lazy Immediate Immediate Number of replicas (server-side) Many None or few None Is client-side caching applied? Yes Yes Sometimes A comparison between name servers for implementing nodes from a large-scale name space partitioned into a global layer, an administrational layer, and a managerial layer. 30

  25. Navigating distributed name services  Large name systems are distributed  Each (client) node has a local name resolver  Each name server is responsible for a separate context of the name space  A client’s resolution request “navigates” through different name servers for full resolution  client controlled: iterative or multicast  server controlled: iterative or multicast  server controlled: recursive 31

  26. Client-controlled navigation NS2 2 Name 1 NS1 servers Client 3 NS3 A client iteratively contacts name servers NS1–NS3 in order to resolve a name 32

  27. Server-controlled navigation NS2 NS2 2 2 4 3 1 1 NS1 NS1 client client 3 5 4 NS3 NS3 Iterative Recursive server-controlled server-controlled A name server NS1 communicates with other name servers on behalf of a client 33

  28. Iterative Name Resolution ftp://ftp.cs.vu.nl/pub/globe/index.html 34

  29. Recursive Name Resolution ftp://ftp.cs.vu.nl/pub/globe/index.html 35

  30. Effects of caching and replication  CACHING  REPLICATION   Reduce time for name Remove “hot spots”: resolution on cache hit reduce accesses to high- level nodes  Lower load on network  Reduce time for name  Increase availability of resolution if accessing service: important closer replica requirement for name  service Increase availability  Try dig and host utilities on UNIX 38

  31. Cache consistency  Cache consistency is relaxed or lazy  Client is expected to deal with stale data  Why not strict consistency (in large name service)?  Updates take long, waiting for all sites to be updated  Lookups take long, waiting for data to stabilize 39

  32. Domain Name System (DNS)  Defines a naming standard for the Internet: One of the largest distributed name services  Maps domain names to IP addresses  Lookup for mail servers  Uses caching and replication to achieve both performance and availability  Organized as rooted tree:  Subtree: Domain  Path name: Domain name (absolute or relative)  Node contents: Resource records for zone  Root servers: http://www.root-servers.org/ 40

Recommend


More recommend