0% found this document useful (0 votes)
27 views

Distributed Systems U4

Uploaded by

Raju
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
27 views

Distributed Systems U4

Uploaded by

Raju
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 8

Smartzworld.com Smartworld.

asia

UNIT-4
DISTRIBUTED FILE SYSTEM
A file system is responsible for the organization, storage, retrieval, naming, sharing, and
protection of files. File systems provide directory services, which convert a file name
(possibly a hierarchical one) into an internal identifier (e.g. inode, FAT index). They
contain a representation of the file data itself and methods for accessing it (read/write).
The file system is responsible for controlling access to the data and for performing low-
level operations such as buffering frequently used data and issuing disk I/O requests.

A distributed file system is to present certain degrees of transparency to the user and the
system: Access transparency: Clients are unaware that files are distributed and can
access them in the same way as local files are accessed.
Location transparency: A consistent name space exists encompassing local as well as
remote files. The name of a file does not give it location.
Concurrency transparency: All clients have the same view of the state of the file system.
This means that if one process is modifying a file, any other processes on the same system
or remote systems that are accessing the files will see the modifications in a coherent
manner.
Failure transparency: The client and client programs should operate correctly after a
server failure.
Heterogeneity: File service should be provided across different hardware and operating
system platforms.
Scalability: The file system should work well in small environments (1 machine, a dozen
machines) and also scale gracefully to huge ones (hundreds through tens of thousands of
systems).
Replication transparency: To support scalability, we may wish to replicate files across
multiple servers. Clients should be unaware of this.
Migration transparency: Files should be able to move around without the client's
knowledge. Support fine-grained distribution of data: To optimize performance, we may
wish to locate individual objects near the processes that use them.
Tolerance for network partitioning: The entire network or certain segments of it may be
unavailable to a client during certain periods (e.g. disconnected operation of a laptop). The
file system should be tolerant of this.

File service types: To provide a remote system with file service, we will have to select one of
two models of operation. One of these is the upload/download model. In this model, there are
two fundamental operations: read file transfers an entire file from the server to the requesting
client, and write file copies the file back to the server. It is a simple model and efficient in that it
provides local access to the file when it is being used. Three problems are evident. It can be
wasteful if the client needs access to only a small amount of the file data. It can be problematic if
the client doesn't have enough space to cache the entire file. Finally, what happens if others need
to modify the same file?

The second model is a remote access model. The file service provides remote operations such as
open, close, read bytes, write bytes, get attributes, etc. The file system itself runs on servers. The
drawback in this approach is the servers are accessed for the duration of file access rather than
once to download the file and again to upload it.

Another important distinction in providing file service is that of understanding the difference
between directory service and file service. A directory service, in the context of file systems,
maps human-friendly textual names for files to their internal locations, which can be used by the
jntuworldupdates.org Specworld.in
file service. The file service itself provides the file interface (this is mentioned above). Another
Smartzworld.com Smartworld.asia
component of file distributed file systems is the client module. This is the client-side interface for
file and directory service. It provides a local file system interface to client software (for example,
the node file system layer of a UNIX kernel).

File service architecture • This is an abstract architectural model that underpins both NFS and
AFS. It is based upon a division of responsibilities between three modules – a client module that
emulates a conventional file system interface for application programs, and server modules, that
perform operations for clients on directories and on files. The architecture is designed to enable a
stateless implementation of the server module.

SUN NFS • Sun Microsystems’s Network File System (NFS) has been widely adopted in
industry and in academic environments since its introduction in 1985. The design and
development of NFS were undertaken by staff at Sun Microsystems in 1984. Although several
distributed file services had already been developed and used in universities and research
laboratories, NFS was the first file service that was designed as a product. The design and
implementation of NFS have achieved success both technically and commercially.

Andrew File System • Andrew is a distributed computing environment developed at Carnegie


Mellon University (CMU) for use as a campus computing and information system. The design of
the Andrew File System (henceforth abbreviated AFS) reflects an intention to support
information sharing on a large scale by minimizing client-server communication. This is
achieved by transferring whole files between server and client computers and caching them at
clients until the server receives a more up-to-date version.
File Service Architecture: Flat file service operations. UFIDs are long sequences of bits chosen
so that each file has a unique among all of the files in a distributed system.

Directory

service:

Provides mapping between text names for the files and their UFIDs. Clients may obtain the
UFID of a file by quoting its text name to directory service. Directory service supports functions
needed generate directories, to add new files to directories.


Client

module:
It runs on each computer and provides integrated service (flat file and directory) as a single API
to application programs. For example, in UNIX hosts, a client module emulates the full set of
Unix file operations.It holds information about the network locations of flat-file and directory
server processes; and achieve better performance through implementation of a cache of recently
used file blocks at the client.

Flat

file service interface:

 
Access control:

In distributed implementations, access rights checks have to be performed  at the server because the
server RPC interface is an otherwise unprotected point of access to files.

Hierarchic file system:
A  file system such as the one that UNIX provides consists of a number of directories arranged in a tree
hierarchic
structure.
 
File Group
A
 file group is a collectionof files that can be located on any server or moved between servers while
maintaining the same names.
 A similar construct is used in a UNIX file system.


– It helps with distributing the load of file serving between several servers.
– File groups have identifiers which are unique throughout the system (and hence for an
open system, they must be globally unique).

To construct globally unique ID we use some unique attribute of the machine on which it is
created. E.g: IP number, even though the file group may move subsequently.

jntuworldupdates.org
NFS access control and authentication: Specworld.in
Smartzworld.com
The NFSserver is stateless server, so the user's identity and access rights must be checked by the server onSmartworld.asia
each
request.

In the local file system they are checked only on the file’s access permission attribute.

Every client request is accompanied by the userID and groupID


It
 is not shown in the Figure 8.9 because they are inserted by the RPC system.

Kerberos has been integrated with NFS to provide a stronger and more
comprehensive security solution.

Mount service

Mount operation:
mount( remotehost, remotedirectory, localdirectory)

The Andrew File System (AFS)

AFS differs markedly from NFS in its design and implementation. The differences are
primarily attributable to the identification of scalability as the most important design goal.
AFS is designed to perform well with larger numbers of active users than other distributed
file systems. The key strategy for achieving scalability is the caching of whole files in
client nodes. AFS has two unusual design characteristics:

Whole-file serving: The entire contents of directories and files are transmitted to client
computers by AFS servers (in AFS-3, files larger than 64 kbytes are transferred in 64-
kbyte chunks).

Whole-file caching: Once a copy of a file or a chunk has been transferred to a client
computer it is stored in a cache on the local disk. The cache contains several hundred of
the files most recently used on that computer. The cache is permanent, surviving reboots
of the client computer. Local copies of files are used to satisfy clients’ open requests in
preference to remote copies whenever possible.
Scenario • Here is a simple scenario illustrating the operation of AFS:
When a user process in a client computer issues an open system call for a file in the shared
file space and there is not a current copy of the file in the local cache, the server holding
the file is located and is sent a request for a copy of the file. The copy is stored in the local
UNIX file system in the client computer. The copy is then opened and the resulting UNIX
file descriptor is returned to the client.

jntuworldupdates.org Specworld.in
Smartzworld.com Smartworld.asia

Naming Services

What are Naming Services?

– An URL facilitates the localization of a resource exposed on the Web.


– A consistent and uniform naming helps processes in a distributed system to interoperate and
manage resource.
– Users refers to each other by means of their names (i.e. email) rather than their system ids–
Naming Services are not only useful to locate resources but also to gather additional information
about them such as attributes

What are Naming Services?


In a Distributed System, a Naming Service is a specific service whose aim is to provide a


consistent and uniform naming of resources, thus allowing other programs or services to localize
them and obtain the required metadata for interacting with them.

Key benefits:

– Resource localization
– Uniform naming
– Device independent address (e.g., you can move domain name/web site from one server to
another server seamlessly).

The role of names and name services


– An identifier can be stored in variables and retrieved from tables quickly


– Identifier includes or can be transformed to an address for an object
– A name is human-readable value (usually a string) that can be resolved to an identifier or
address
– because the binding of the named resource to a physical location is deferred and can be
changes
– because they are more meaningful to users
– to give identifiers and other useful attributes

Requirements for name spaces

Allow simple but meaningful names to be used


– to allow similar sub names without clashes
– to group related names

The DNS maps domain names to the attributes of a host computer: its IP address, the type of
entry (for example, a reference to a mail server or another host) and, for example, the length of
time the host’s entry will remain valid. The X500 directory service can be used to map a person’s
name onto attributes including their email address and telephone number. The CORBA Naming
Service maps the name of a remote object onto its remote object reference, whereas the Trading
Service maps the name of a remote object onto its remote object reference, together with an
arbitrary number of attributes describing the object in terms understandable by human users.

Name Services and the Domain Name System


jntuworldupdates.org Specworld.in
Smartzworld.com Smartworld.asia
A name service stores a collection of one or more naming contexts, sets of bindings between
textual names and attributes for objects such as computers, services, and users.

The major operation that a name service supports is to resolve names.

Uniform Resource Identifiers

Uniform Resource Identifiers (URIs) came about from the need to identify resources on the Web,
and other Internet resources such as electronic mailboxes. An important goal was to identify
resources in a coherent way, so that they could all be processed by common software such as
browsers. URIs are ‘uniform’ in that their syntax incorporates that of indefinitely many
individual types of resource identifiers (that is, URI schemes), and there are procedures for
managing the global namespace of schemes. The advantage of uniformity is that it eases the
process of introducing new types of identifier, as well as using existing types of identifier in new
contexts, without disrupting existing usage.
Uniform Resource Locators: Some URIs contain information that can be used to locate and
access a resource; others are pure resource names. The familiar term Uniform Resource Locator
(URL) is often used for URIs that provide location information and specify the method for
accessing the resource.

Uniform Resource Names:

Uniform Resource Names (URNs) are URIs that are used as pure resource names rather than
locators. For example, the URI:
mid:[email protected]

Navigation

Navigation is the act of chaining multiple Naming Services in order to resolve a single name to
the corresponding resource.
Namespaces allows for structure in names.

URLs provide a default structure that decompose the location of a resource in


– protocol used for retrieval
– internet end point of the service exposing the resource
– service specific path

This decomposition facilitates the resolution of the name into the corresponding resource
Moreover, structured namespaces allows for iterative navigation…

Iterative navigation
Reason for NFS iterative name resolution

This is because the file service may encounter a symbolic link (i.e. an alias) when resolving a
name. A symbolic link must be interpreted in the client’s file system name space because it may
point to a file in a directory stored at another server. The client computer must determine which
server this is, because only the client knows its mount points

Server controlled navigation


In an alternative model, name server coordinates naming resolution and returns the results to the
client. It can be:

– Recursive: it is performed by the naming server the server becomes like a client for the next
server this is necessary in case of client connectivity constraints
– Non recursive: it is performed by the client or the first server the server bounces back the
jntuworldupdates.org
next hop to its client Specworld.in
Smartzworld.com Smartworld.asia
Non-recursive and recursive server-controlled navigation

DNS offers recursive navigation as an option, but iterative is the standard technique. Recursive
navigation must be used in domains that limit client access to their DNS information for security
reasons.

The Domain Name System is a name service design whose main naming database is used across
the Internet.
This original scheme was soon seen to suffer from three major shortcomings:
It did not scale to large numbers of computers. Local organizations wished to administer their
own naming systems. A general name service was needed – not one that serves only for looking
up computer addresses.

Domain names • The DNS is designed for use in multiple implementations, each of which may
have its own name space. In practice, however, only one is in widespread use, and that is the one
used for naming across the Internet. The Internet DNS name space is partitioned both
organizationally and according to geography. The names are written with the highest-level
domain on the right. The original top-level organizational domains (also called generic domains)
in use across the Internet were:

DNS - The Internet Domain Name System

A distributed naming database (specified in RFC 1034/1305 Name structure reflects


administrative structure of the Internet.
Rapidly resolves domain names to IP addresses
– exploits caching heavily
– typical query time ~100 milliseconds
Scales to millions of computers
– partitioned database
– caching
Resilient to failure of a server
– Replication

DNS server functions and configuration


 
Main function is to resolve domain names for computers, i.e. to get their IP addresses
– caches the results of previous searches until they pass their 'time to live'
 Other functions:
 – get mail host for a domain
– reverse resolution - get domain name from IP address
– Host information - type of hardware and OS
– Well-known services - a list of well-known services offered by a host
– Other attributes can be included (optional)

DNS resource records

The DNS architecture allows for recursive navigation as well as iterative navigation. The
resolver specifies which type of navigation is required when contacting a name server. However,
name servers are not bound to implement recursive navigation. As was pointed out above,
recursive navigation may tie up server threads, meaning that other requests might be delayed.

Global Name Service (GNS)


The GNS manages a naming database that is composed of a tree of directories holding names
and values. Directories are named by multi-part pathnames referred to a root, or relative to a
jntuworldupdates.org Specworld.in
working directory, much like file names in a UNIX file system. Each directory is also assigned
Smartzworld.com Smartworld.asia
an integer, which serves as a unique directory identifier (DI). A directory contains a list of names
and references. The values stored at the leaves of the directory tree are organized into value
trees, so that the attributes associated with names can be structured values.
Names in the GNS have two parts: <directory name, value name>. The first part identifies a
directory; the second refers to a value tree, or some portion of a value tree.

Consensus and related problems


• Problems of agreement
– For processes to agree on a value (consensus) after one or more of the processes has
proposed what that value should be
– Covered topics: byzantine generals, interactive consistency, totally ordered multicast
The byzantine generals problem: a decision whether multiple armies should attack or retreat,
assuming that united action will be more successful than some attacking and some retreating
Another example might be space ship controllers deciding whether to proceed or abort. Failure
handling during consensus is a key concern
Assumptions
– communication (by message passing) is reliable
– processes may fail
• Sometimes up to f of the N processes are faulty

Consensus Process
Each process pi begins in an undecided state and proposes a single value vi, drawn from a set
D (i=1…N)
Processes communicate with each other, exchanging values
Each process then sets the value of a decision variable di and enters the decided state
Requirements for Consensus

• Three requirements of a consensus algorithm


– Termination: Eventually every correct process sets its decision variable
– Agreement: The decision value of all correct processes is the same: if pi and pj are correct and
have entered the decided state, then di=dj
(i,j=1,2, …, N)
– Integrity: If the correct processes all proposed the same value, then any correct process in the
decided state has chosen that value

The byzantine generals problem

• Problem description
– Three or more generals must agree to attack or to retreat
– One general, the commander, issues the order
– Other generals, the lieutenants, must decide to attack or retreat
– One or more generals may be treacherous
A treacherous general tells one general to attack and another to retreat
Difference from consensus is that a single process supplies the value to agree on
Requirements
– Termination: eventually each correct process sets its decision variable
– Agreement: the decision variable of all correct processes is the same
– Integrity: if the commander is correct, then all correct processes agree on the value that the
commander has proposed (but the commander need not be correct)

The interactive consistency problem

Interactive consistency: all correct processes agree on a vector of values, one for each process.
This is called the decision vector
– Another variant of consensus
jntuworldupdates.org Specworld.in
Smartzworld.com Smartworld.asia
Requirements
– Termination: eventually each correct process sets its decision variable
– Agreement: the decision vector of all correct processes is the same
– Integrity: if any process is correct, then all correct processes decide the correct value for that
process

Relating consensus to other problems


Consensus (C), Byzantine Generals (BG), and Interactive Consensus (IC) are all problems
concerned with making decisions in the context of arbitrary or crash failures
We can sometimes generate solutions for one problem in terms of another. For example
– We can derive IC from BG by running BG N times, once for each process with that process
acting as commander
– We can derive C from IC by running IC to produce a vector of values at each process,
then applying a function to the vector‘s values to derive a single value.
– We can derive BG from C by
Commander sends proposed value to itself and each remaining process
All processes run C with received values
They derive BG from the vector of C values

Consensus in a Synchronous System


Up to f processes may have crash failures, all failures occurring during f+1 rounds.
During each round, each of the correct processes multicasts the values among themselves
The algorithm guarantees all surviving correct processes are in a position to agree
Note: any process with f failures will require at least f+1 rounds to agree

Limits for solutions to Byzantine Generals

• Some cases of the Byzantine Generals problems have no solutions


– Lamport et al found that if there are only 3 processes, there is no solution
– Pease et al found that if the total number of processes is less than three times the number
of failures plus one, there is no solution
• Thus there is a solution with 4 processes and 1 failure, if there are two rounds
– In the first, the commander sends the values
– while in the second, each lieutenant sends the values it received

Thrashing
It can be argued that it is the programmer’s responsibility to avoid thrashing. The programmer
could annotate data items in order to assist the DSM runtime in minimizing page copying and
ownership transfers. The latter approach is discussed in the next section in the context of the
Munin DSM system.

jntuworldupdates.org Specworld.in

You might also like