Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Distributed operating system wikipedia , lookup
MTS system architecture wikipedia , lookup
Library (computing) wikipedia , lookup
Commodore DOS wikipedia , lookup
Plan 9 from Bell Labs wikipedia , lookup
Burroughs MCP wikipedia , lookup
File locking wikipedia , lookup
Distributed File Systems NFS AFS SMB http://en.wikipedia.org/wiki/Network_file_system DFS INTRODUCTION Distributed File Systems (DFS) Any computer file system that supports sharing of files and other resources as persistent storage over a computer network First file servers were developed in the 1970s Network File System (NFS) Created at Sun Microsystems 1985 First widely used distributed file system Other notable distributed file systems Andrew File System (AFS) Server Message Block SMB AKA CIFS DISTRIBUTION Distribution Distributed File System (DFS) Network file system with: Clients, servers, and storage devices Spread throughout the machines of a distributed system or intranet Service activity occurs across the network System has multiple and independent storage devices Some DFS servers run on dedicated machines Some machines can be both a server and a client A DFS can be implemented: As part of a distributed operating system By a software layer Managing the communication between conventional operating systems and file systems Distribution Distinctive System many feature of a DFS: with - and autonomous Clients and Servers Note: NFS is a DFS for the Unix family Network File System Originated in the Unix world Implementations for other OSes NFS sometimes used as a synonym for DFS Be careful of the distinction DFS ATTRIBUTES Transparency A DFS should appear to its users to be the same as a conventional, centralized file system Multiplicity and dispersion of its servers and storage devices should be invisible Client interface used by programs should not distinguish between local and remote files DFS locates the files and arranges the transport of data Performance Most important performance measurement of a DFS: Amount of time needed to satisfy service requests Typical performance constraints: Conventional file systems (local drives): Disk-access time Small amount of CPU-processing time DFS: Additional overhead due to the distributed structure Includes: Time to deliver the request to a server Time to deliver the response to the client For each direction, a CPU overhead of running the communication protocol software Performance Performance of DFS can be viewed as one dimension of its transparency Ideally, it would be comparable to that of a conventional file system Concurrent file updates DFS should allow Multiple client processes On multiple machines Access and update the same files Updates to the file from one client should not interfere with access and updates from other clients Concurrency control or locking may be: Built into the file system Provided by an add-on protocol EXAMPLES Sample Distributed File Systems Client-server file systems 9P Amazon S3 Coda Secure File System (SFS) Self-certifying File System (SFS) Sample Distributed File Systems Distributed file systems Andrew File System (AFS), OpenAFS DCE Distributed File System Google File System File system that is optimized for Google's core storage needs Java software framework that supports distributed applications running on large clusters of commodity computers Hadoop Kosmos FS Remote file access protocol used with the Distributed Computing Environment High performance distributed file system. It is also integrated with hadoop. Lustre Distributed file system for large scale cluster computing Set of client and server services for organizing many distributed SMB file shares into a distributed file system Microsoft Distributed File System GlusterFS Platform for developing clustering applications Parallel file system that focuses on high performance access to large data sets Parallel Virtual File System Network File Systems http://en.wikipedia.org/wiki/Network_File_System_%28proto col%29 NFS PROTOCOL Network File System Protocol Network file system protocol: Allows a user on a client computer to access files over a network Originally developed by Sun Microsystems in 1984 NFS builds on Open Network Computing Remote Procedure Call system As if the network devices were attached to its local disks ONC RPC Network File System protocol specified in: RFC 1094 RFC 1813 RFC 3530 (which obsoletes RFC 3010) VERSIONS AND VARIATIONS Versions and variations Version 1 Used only for Sun in-house experimental purposes Not released to public Versions and variations Version 2 Originally operated entirely over UDP Defined in RFC 1094 March 1989 Designers meant to keep the protocol stateless Locking (for example) implemented outside of the core protocol Versions and variations Version 3 (RFC 1813, June 1995) added: Support for 64-bit file sizes and offsets Handle files larger than 4 gigabytes (GB) 32 bit address limit Support for asynchronous writes on the server Additional file attributes in many replies Avoid the need to re-fetch them READDIRPLUS operation Improve write performance Get file handles and attributes Along with file names when scanning a directory Assorted other improvements Versions and variations At the introduction of Version 3 Vendor support for TCP as a transport-layer protocol began increasing Several vendors had already added support for NFS Version 2 with TCP as a transport Sun Microsystems added support for TCP as a transport for NFS at the same time it added support for Version 3 Using TCP as a transport made using NFS over a WAN more feasible Versions and variations Version 4 First version developed with the IETF After Sun Microsystems handed over the development of the NFS protocols Versions and variations Version 4 includes: Performance improvements Mandates strong security Introduces a stateful protocol Defined by RFC 3010, December 2000 Revised in RFC 3530, April 2003 Versions and variations Various side-band protocols have become associated with NFS, including: Byte-range advisory Network Lock Manager (NLM) protocol Added to support UNIX System V file-locking APIs Remote quota reporting (RQUOTAD) protocol Allow NFS-users to view their data-storage quotas on NFS servers Versions and variations WebNFS Allows NFS to Integrate more easily into Web-browsers Enable operation through firewalls Was an extension to Version 2 and Version 3 Sun Microsystems open sourced their WebNFS implementation via https://yanfs.dev.java.net/ PLATFORMS Platforms NFS Most common with UNIX like OSes Other software platforms: Mac OS Microsoft Windows Novell NetWare IBM AS/400 Platforms Alternative remote file access protocols include Server Message Block (SMB) protocol Also known as CIFS Apple Filing Protocol (AFP) NetWare Core Protocol (NCP) OS/400 File Server file system (QFileSvr.400) Note: SMB and NetWare Core Protocol (NCP) are most common on Microsoft Windows AFP is most common on (old) Macintosh systems QFileSvr.400 is most common on AS/400 systems TYPICAL IMPLEMENTATION Typical implementation Unix-style Client scenario: Requires access to data Server Serves data Typical implementation Server Side Server Server administrator Determines what resources to make available Exporting names and parameters of directories Typically using the /etc/exports configuration file exportfs command Server security-administration NFS daemon (nfsd) Make data generically available to clients Recognizes and approves validated clients Server network configuration Lets appropriate clients can negotiate with it through any firewall system Typical implementation Client Side Client machine Requests access to exported data Issues a mount command Users on the client machine View and interact with mounted file systems on the server Within the parameters permitted Permissions, etc. Note: automating the NFS mounting process is typical E.g. using /etc/fstab and/or automounting facilities NFS PROTOCOL DEVELOPMENT VERSUS COMPETING PROTOCOLS NFS Protocol development versus competing protocols 1980s NFS and ONC figured prominently in the network-computing war between Sun Microsystems and Apollo Computer, and later the UNIX wars (ca 1987-1996) between AT&T and Sun on one side, and Digital Equipment, HP, and IBM on the other. During the development of the ONC protocol (called SunRPC at the time), only Apollo's Network Computing System (NCS) offered comparable functionality. Two competing groups developed over fundamental differences in the two remote procedure call systems. Arguments focused on the method for dataencoding — ONC's External Data Representation (XDR) always rendered integers in big-endian order, even if both peers of the connection had little-endian machine-architectures, whereas NCS's method attempted to avoid byte-swap whenever two peers shared a common endianness in their machinearchitectures. An industry-group called the Network Computing Forum formed (March 1987) in an (ultimately unsuccessful) attempt to reconcile the two network-computing environments. Later, Sun and AT&T announced that the two firms would jointly develop AT&T's next version of UNIX: System V Release 4. This caused many of AT&T's other licensees of UNIX System V to become concerned that this would put Sun in an advantaged position, and it ultimately led to Digital Equipment, HP, IBM, and others forming the Open Software Foundation (OSF) in 1988. Ironically, Sun and AT&T had previously competed over Sun's NFS versus AT&T's Remote File System (RFS), and the quick adoption of NFS over RFS by Digital Equipment, HP, IBM, and many other computer vendors tipped the majority of users in favor of NFS. OSF solicited the proposals for various technologies, including the remote procedure call (RPC) system and the remote file access protocol. In the end, proposals for these two requirements, called respectively, the Distributed Computing Environment (DCE), and the Distributed File System (DFS) won over Sun's proposed ONC and NFS. DCE derived from a suite of technologies, including NCS and Kerberos. DFS used DCE as the RPC and derived from AFS. Protocol development versus competing protocols 1990s Sun Microsystems and the Internet Society (ISOC) reached an agreement to cede "change control" of ONC RPC so that ISOC's engineering-standards body, the Internet Engineering Task Force (IETF), could publish standards documents (RFCs) documenting the ONC RPC protocols and could extend ONC RPC. OSF attempted to make DCE RPC an IETF standard, but ultimately proved unwilling to give up change-control. Later, the IETF chose to extend ONC RPC by adding a new authentication flavor, RPCSEC GSS, in order to meet IETF's requirements that protocol standards have adequate security. Later, Sun and ISOC reached a similar agreement to give ISOC change control over NFS, although writing the contract carefully to exclude NFS version 2 and version 3. Instead, ISOC gained the right to add new versions to the NFS protocol, which resulted in IETF specifying NFS version 4 in 2003. 2000s By the 21st century, neither DFS nor AFS had achieved any major commercial success as compared to CIFS or NFS. IBM, which had previously acquired the primary commercial vendor of DFS and AFS, Transarc, donated most of the AFS source code to the free software community in 2000. The OpenAFS project lives on. In early 2005, IBM announced end of sales for AFS and DFS. Present NFSv4.1 presents new opportunities for the NAS community Primary addition is Parallel NFS (pNFS) Protocol defines a method of separating the meta-data of a file system from the location of the file data Holds the names of files and their data under the single umbrella of the server Products exist that are multi-node NFS servers Meta-data: names and attributes Goes beyond simple name/data separation Defines method of striping the data amongst a set of data servers Very different from the traditional NFS server A method of introducing data access parallelism Limited participation by the client in separation of meta-data and data NFSv4.1 client can be enabled to be a direct participant in the exact location of file data Avoid sole interaction with the single NFS server when moving data Present NFSv4.1 pNFS server: A collection or community of server resources or components Community members are controlled by the metadata server pNFS client still accesses a single metadata server for traversal or interaction with the namespace Client moves data to and from the server Directly interact with the set of data servers belonging to the pNFS server community Present NFSv4.1 provides: Sessions Directory Delegation and Notifications Multi-server Namespace ACL/SACL/DACL access control lists system access control list discretionary access control list Retention Attributions SECINFO_NO_NAME Future NFSv4.2 Under development Some features are currently useable AFS http://en.wikipedia.org/wiki/Andrew_File _System Andrew File System (AFS) Distributed networked file system Developed by Carnegie Mellon University Named for Part of the Andrew Project Andrew Carnegie Andrew Mellon Primary used in distributed computing FEATURES Features AFS has several benefits over traditional networked file systems Particularly in the areas of security and scalability Not uncommon for enterprise AFS cells to exceed 50,000 clients Uses Kerberos for authentication Implements access control lists on directories for users and groups Each client caches files on the local file system for increased speed on subsequent requests for the same file Allows limited file system access in the event of a server crash or a network outage Features Read and write operations on an open file are directed only to the locally cached copy When a modified file is closed Cache consistency maintained by callback When a file is cached Server makes a note of this Will inform the client if the file is updated by someone else After any client, server, or network failure (including a time-out) Only the changed portions copied back to the file server Callbacks are discarded and must be re-established Re-establishing a callback involves: Status check Does not require re-reading the file itself Features Consequence of the whole file locking strategy AFS does not support large shared databases or record updating within files shared between client systems Deliberate design decision Based on the perceived needs of the university computing environment Leads to the use of a single file per message in the original email system for the Andrew Project, the Andrew Message System, rather than the more customary single file per mailbox Features A significant feature of AFS is the volume Tree of files Sub-directories AFS mountpoints Volumes are created by administrators Links to other AFS volumes Linked at a specific named path in an AFS cell Once created, users of the filesystem may create directories and files as usual without concern for the physical location of the volume A volume may have a quota assigned to it in order to limit the amount of space consumed. As needed, AFS administrators can move that volume to another server and disk location without the need to notify users Moving can occur while files in that volume are even being used Features AFS volumes can be replicated to read-only cloned copies When accessing files in a read-only volume, a client system will retrieve data from any read-only copy If a copy becomes unavailable, clients will look for any remaining copies Users of that data are unaware of the location of the readonly copy Administrators can create and relocate copies as needed AFS command suite guarantees that all read-only volumes contain exact copies of the original read-write volume at the time the read-only copy was created Features File name space on an Andrew workstation is partitioned into a shared and local name space Shared name space identical on all workstations Usually mounted as /afs on the Unix file system Local name space unique to each workstation Contains only temporary files needed for workstation initialization and symbolic links to files in the shared name space Features Andrew File System Heavily influenced Version 4 of Sun Microsystems' NFS Variant of AFS adopted by the Open Software Foundation Distributed File System (DFS) Part of their Distributed computing environment IMPLEMENTATIONS Implementations There were three major implementations Transarc (IBM) OpenAFS Arla Transarc software is losing support and is deprecated AFS (version two) Released as OpenAFS and retired Predecessor of the Coda file system Fourth implementation in the Linux kernel source code since at least version 2.6.10 Committed by Red Hat A fairly simple implementation Still in its early stages of development Incomplete AFS FILE PERMISSIONS Available permissions The following Access Control List (ACL) permissions can be granted: Lookup (l) Allows users to: List the contents of the AFS directory Examine the ACL associated with the directory Access subdirectories Insert (i) Delete (d) Allows users to add new files or subdirectories to the directory Allows users to remove files and subdirectories from the directory Administer (a) Allows users to change the ACL for the directory Users always have this right on their home directory Even if they accidentally remove themselves from the ACL Available permissions Permissions that affect files and subdirectories include: Read (r) Write (w) Allows users to look at the contents of files in a directory and list files in subdirectories Files that are to be granted read access to any user, including the owner, need to have the standard UNIX "owner read" permission set Allows users to modify files in a directory Files that are to be granted write access to any user, including the owner, need to have the standard UNIX "owner write" permission set Lock (k) Allows the processor to run programs that need to "flock" files in the directory See the UNIX man page for "flock" for more details Available permissions AFS includes Application ACLs (A)-(H) which have no effect on access to files ACL – Access Control Lists Affects directories only Overrides Unix permissions SMB http://en.wikipedia.org/wiki/Server_Message_Block Server Message Block (SMB) Operates as an application-level network protocol Applied to shared access to Files Printers Serial ports Miscellaneous communications Between nodes on a network Provides an authenticated Inter-process communication mechanism Most usage of SMB involves computers running Microsoft Windows: Microsoft environments users often know it simply as "Microsoft Windows Network" Server Message Block (SMB) When discussing SMB, one should distinguish: SMB the protocol SMB services that run on the protocol NetBIOS DCE/RPC services that use SMB as an authenticated Inter-process communication channel (over named pipes) "Network Neighborhood" protocols which primarily (but not exclusively) run as datagram services directly on the NetBIOS transport HISTORY History Barry Feigenbaum originally invented SMB at IBM Turned DOS "Interrupt 33" (21h) local file-access into a networked file-system Microsoft made considerable modifications to the most commonly used version Merged the SMB protocol with the LAN Manager Developing with 3Com (circa 1990) Continued to add features to the protocol Windows for Workgroups (circa 1992) Later versions of Windows History Original design of SMB envisaged it running on top of the NetBIOS and NetBEUI APIs Typically implemented with NBF (NetBIOS Frame) NetBIOS over IPX/SPX NBT (NetBIOS TCP/IP) SMB can also run directly on the TCP/IP protocols Introduced with Windows 2000 History Circa Sun Microsystems announcing WebNFS Microsoft launched an initiative in 1996 to rename SMB to Common Internet File System (CIFS) Added more features, including Support for: Symbolic links Hard links Larger file sizes Attempt at supporting direct connections without the NetBIOS Largely experimental effort that required further refinement Microsoft submitted some partial specifications as Internet-Drafts to the IETF Submissions have expired History Windows Vista introduced Server Message Block 2.0 History Side issue: Samba project originated aim of Reverse engineer SMB Provide a free implementation of a compatible SMBclient and server for use with non-Microsoft operating system Driven by the importance of the SMB protocol in interacting with the widespread Microsoft Windows platform Resume 3/27 IMPLEMENTATION Implementation Client-server approach SMB works through a peer-to-peer approach One section of the SMB protocol specifically deals with access to file systems Client makes specific requests Server responds accordingly Clients may make requests to a file server Other sections of the SMB protocol specialize in interprocess communication (IPC) Developers have optimized the SMB protocol for local subnet usage Users have also put SMB to work to access different subnets across the Internet Involving file-sharing or print-sharing in MS Windows environments Implementation Client-server approach SMB servers make their file systems and other resources available to clients on the network Client computers may want access to the shared file systems and printers on the server For this primary function, SMB is best-known and most heavily used SMB file-server aspect would count for little without the NT domains suite of protocols Provide NT-style domain-based authentication NT Domains protocols offer MSRPC services available almost exclusively available on SMB IPC "named pipe“ Almost all implementations of SMB servers use NT Domain authentication to validate user-access to resources Implementation Microsoft's modifications Microsoft has added several extensions to its own SMB implementation. Added NT LAN Manager (NTLM) Version 2 NTLM version 1 used DES in a flawed manner Derived from the original legacy SMB specification's requirement to use IBM "LanManager" passwords NT 4.0 Domain Logon protocols use 40-bit encryption outside of the United States of America Does not conform with modern security standards Implementation Points of interest SMB's "Inter-Process Communication" mechanism deserves a specific mention SMB "IPC" system provides named pipes Provides one of the first few inter-process mechanisms commonly available to programmers Provides a means for services to inherit the authentication carried out when a client first connected to an SMB server Inherited authentication in named pipes has become so ubiquitous and transparent that both Windows-users and programmers who use the Windows API often simply take it for granted Implementation Points of interest Some services that operate over named pipes also allow MSRPC client programs to perform authentication Over-rides the authorization provided by the SMB server Only in the context of the MSRPC client program that successfully makes the additional authentication Implementation Points of interest SMB uses opportunistic locking Special type of locking-mechanism Improves performance SMB serves as the basis for Microsoft's Distributed File System implementation VERSIONS AND IMPLEMENTATIONS Versions and implementations The following list explicitly refers to "SMB" as including an SMB client or an SMB server Including the various protocols that extend SMB For simplicity and conciseness and vagueness, however, the list omits mention of the extent or completeness of the reimplementation or porting status for any of these implementations Lumps them all together simply as "SMB" Versions and implementations List… Samba includes an SMB server and a command-line SMB client Samba TNG: a fork of Samba The Linux kernel includes two SMB client implementations that use the Linux VFS smbfs originally derived from the FreeBSD smbfs; they use the NetBSD and OS X VFS Solaris has a project called CIFS client for Solaris smbfs that uses its VFS NetBSD and Mac OS X include SMB client implementations: Provides access to NetWare volumes for Microsoft Network clients FreeBSD includes an SMB client implementation users can access the same data through both protocols Novell NetWare version 6 and later has a CIFS server implementation Provides access to files on an SMB server through the standard file system API: smbfs and cifs ONStor Inc. offers an SMB implementation that also supports NFS protocol Free re-implementation of the SMB protocol and of the Microsoft extensions to it Based on the Mac OS X smbfs Sun Microsystems added in-kernel CIFS support to Solaris in October 2007 Sun Microsystems Cascade (aka PC-Netlink) represents a port of Advanced Server for Unix Sun took over two years making the code useful, due to the poor quality of the original port Versions and implementations Continued… FreeNAS runs FreeBSD for Network-attached storage (NAS) services Advanced Server for Unix (AS/U) comprises a port of Windows NT 3.51's SMB server code to Unix Microsoft licensed the code to AT&T, which then licensed it to major Unix vendors. The poor quality of the original port (allegedly carried out by Microsoft itself) has caused any vendor sublicensing it significant grief VERITAS Software has an implementation of SMB SCO has a port of Advanced Server for Unix SCO has VisionFS, a Microsoft-independent re-implementation of SMB developed through reference to Samba source code Network Appliance has an SMB server implementation Objective Development's Sharity provides an SMB file-system client for Unix The Alfresco content-management system includes a Java implementation of SMB JCIFS offers an implementation of SMB in Java RTSMB, a CIFS/SMB implementation written in ANSI C. Supports protocols including CIFS/Samba EBS designed RTSMB from scratch, independently of MS or SAMBA design reference, to run in embedded devices Visuality Systems NQ CIFS, a CIFS (SMB) server and client solution for embedded devices — ported to many popular real-time operating systems (RTOSs) Thursby Software Systems offers a commercial implementation of SMB/CIFS for Mac OS NFS is most common on 16% 11% s in do w ic r os of tW M M ac OS x 0% ni x 4. L in ux /U 3. 74% M VS 2. IBM MVS Linux/Unix Mac OS x Microsoft Windows IB M 1. SMB is most common on 11% 6% M s in do w ic r os of tW OS x 0% M ac 4. L in ux 3. 83% M VS 2. IBM MVS Linux Mac OS x Microsoft Windows IB M 1.