Distributed Operating System_4
9 likes7,664 views
A distributed system consists of multiple connected CPUs that appear as a single system to users. Distributed systems provide advantages like communication, resource sharing, reliability and scalability. However, they require distribution-aware software and uninterrupted network connectivity. Distributed operating systems manage resources across connected computers transparently. They provide various forms of transparency and handle issues like failure, concurrency and replication. Remote procedure calls allow calling remote services like local procedures to achieve transparency.
![IMPLEMENTATION ISSUES
Choice of protocol [affects communication costs]
Use existing protocol (UDP) or design from scratch
Packet size restrictions
Reliability in case of multiple packet messages
Flow control
Copying costs are dominant overheads
Need at least 2 copies per message
From client to NIC and from server NIC to server
As many as 7 copies
Stack in stub – message buffer in stub – kernel – NIC – medium –
NIC – kernel – stub – server
Scatter-gather operations can reduce overheads](https://image.slidesharecdn.com/4-130908221343-/85/Distributed-Operating-System_4-75-320.jpg)
Distributed Operating System_4
- 1. DISTRIBUTED OPERATING SYSTEMS Sandeep Kumar Poonia Head of Dept. CS/IT B.E., M.Tech., UGC-NET LM-IAENG, LM-IACSIT,LM-CSTA, LM-AIRCC, LM-SCIEI, AM-UACEE
- 2. DEFINITION OF A DISTRIBUTED SYSTEM A distributed system: Multiple connected CPUs working together A collection of independent computers that appears to its users as a single coherent system Examples: parallel machines, networked machines
- 3. ADVANTAGES AND DISADVANTAGES Advantages Communication and resource sharing possible Economics – price-performance ratio Reliability, scalability Potential for incremental growth Disadvantages Distribution-aware PLs, OSs and applications Network connectivity essential Security and privacy
- 4. TRANSPARENCY IN A DISTRIBUTED SYSTEM Different forms of transparency in a distributed system. Transparency Description Access Hide differences in data representation and how a resource is accessed Location Hide where a resource is located Migration Hide that a resource may move to another location Relocation Hide that a resource may be moved to another location while in use Replication User cannot tell how many copies exist Concurrency Hide that a resource may be shared by several competitive users Failure Hide the failure and recovery of a resource Persistence Hide whether a (software) resource is in memory or on disk
- 6. SCALABILITY PROBLEMS Examples of scalability limitations. Concept Example Centralized services A single server for all users Centralized data A single on-line telephone book Centralized algorithms Doing routing based on complete information
- 7. HARDWARE CONCEPTS: MULTIPROCESSORS (1) Multiprocessor dimensions Memory: could be shared or be private to each CPU Interconnect: could be shared (bus-based) or switched A bus-based multiprocessor.
- 8. MULTIPROCESSORS (2) a) A crossbar switch b) An omega switching network 1.8
- 9. DISTRIBUTED SYSTEMS MODELS Minicomputer model (e.g., early networks) Each user has local machine Local processing but can fetch remote data (files, databases) Workstation model (e.g., Sprite) Processing can also migrate Client-server Model (e.g., V system, world wide web) User has local workstation Powerful workstations serve as servers (file, print, DB servers) Processor pool model (e.g., Amoeba, Plan 9) Terminals are Xterms or diskless terminals Pool of backend processors handle processing
- 10. UNIPROCESSOR OPERATING SYSTEMS An OS acts as a resource manager or an arbitrator Manages CPU, I/O devices, memory OS provides a virtual interface that is easier to use than hardware Structure of uniprocessor operating systems Monolithic (e.g., MS-DOS, early UNIX) One large kernel that handles everything Layered design Functionality is decomposed into N layers Each layer uses services of layer N-1 and implements new service(s) for layer N+1
- 11. UNIPROCESSOR OPERATING SYSTEMS Microkernel architecture • Small kernel • user-level servers implement additional functionality
- 12. DISTRIBUTED OPERATING SYSTEM Manages resources in a distributed system Seamlessly and transparently to the user Looks to the user like a centralized OS But operates on multiple independent CPUs Provides transparency Location, migration, concurrency, replication,… Presents users with a virtual uniprocessor
- 13. DOS: CHARACTERISTICS (1) Distributed Operating Systems Allows a multiprocessor or multicomputer network resources to be integrated as a single system image Hide and manage hardware and software resources provides transparency support provide heterogeneity support control network in most effective way consists of low level commands + local operating systems + distributed features Inter-process communication (IPC)
- 14. DOS: CHARACTERISTICS (2) remote file and device access global addressing and naming trading and naming services synchronization and deadlock avoidance resource allocation and protection global resource sharing deadlock avoidance communication security no examples in general use but many research systems: Amoeba, Chorus etc.
- 15. TYPES OF DISTRIBUTED OS System Description Main Goal DOS Tightly-coupled operating system for multi- processors and homogeneous multicomputers Hide and manage hardware resources NOS Loosely-coupled operating system for heterogeneous multicomputers (LAN and WAN) Offer local services to remote clients Middleware Additional layer atop of NOS implementing general- purpose services Provide distribution transparency
- 16. MULTIPROCESSOR OPERATING SYSTEMS Like a uniprocessor operating system Manages multiple CPUs transparently to the user Each processor has its own hardware cache Maintain consistency of cached data
- 19. NETWORK OPERATING SYSTEM Employs a client-server model Minimal OS kernel Additional functionality as user processes
- 20. MIDDLEWARE-BASED SYSTEMS General structure of a distributed system as middleware. 1-22
- 21. MIDDLEWARE EXAMPLES Examples: Sun RPC, CORBA, DCOM, Java RMI (distributed object technology) Built on top of transport layer in the ISO/OSI 7 layer reference model: application (protocol), presentation (semantic), session (dialogue), transport (e.g. TCP or UDP), network (IP, ATM etc), data link (frames, checksum), physical (bits and bytes) Most are implemented over the internet protocols Masks heterogeneity of underlying networks, hardware, operating system and programming languages – so provides a uniform programming model with standard services 3 types of middleware: transaction oriented (for distributed database applications) message oriented (for reliable asynchronous communication) remote procedure calls (RPC) – the original OO middleware
- 22. COMPARISON BETWEEN SYSTEMS Item Distributed OS Network OS Middleware- based OS Multiproc. Multicomp. Degree of transparency Very High High Low High Same OS on all nodes Yes Yes No No Number of copies of OS 1 N N N Basis for communication Shared memory Messages Files Model specific Resource management Global, central Global, distributed Per node Per node Scalability No Moderately Yes Varies Openness Closed Closed Open Open
- 23. COMMUNICATION IN DISTRIBUTED SYSTEMS Issues in communication Message-oriented Communication Remote Procedure Calls Transparency but poor for passing references Remote Method Invocation RMIs are essentially RPCs but specific to remote objects System wide references passed as parameters Stream-oriented Communication
- 24. TYPES OF COMMUNICATION Message passing is the general basis of communication in a distributed system: transferring a set of data from a sender to a receiver.
- 25. COMMUNICATION BETWEEN PROCESSES Unstructured communication Use shared memory or shared data structures Structured communication Use explicit messages (IPCs) Distributed Systems: both need low-level communication support
- 26. COMMUNICATION PROTOCOLS Protocols are agreements/rules on communication Protocols could be connection-oriented or connectionless 2-1
- 27. LAYERED PROTOCOLS A typical message as it appears on the network. 2-2
- 28. Physical layer The physical layer is responsible for movements of individual bits from one hop (node) to the next.
- 29. PHYSICAL LAYER Provides physical interface for transmission of information. Defines rules by which bits are passed from one system to another on a physical communication medium. Covers all - mechanical, electrical, functional and procedural - aspects for physical communication. Such characteristics as voltage levels, timing of voltage changes, physical data rates, maximum transmission distances, physical connectors, and other similar attributes are defined by physical layer specifications. OSI Model
- 30. Data link layer The data link layer is responsible for moving frames from one hop (node) to the next and perform error detection and correction
- 31. DATA LINK LAYER Data link layer attempts to provide reliable communication over the physical layer interface. Breaks the outgoing data into frames and reassemble the received frames. Create and detect frame boundaries. Handle errors by implementing an acknowledgement and retransmission scheme. Implement flow control. Supports points-to-point as well as broadcast communication. Supports simplex, half-duplex or full-duplex communication. OSI Model
- 32. DATA LINK LAYER
- 33. Network layer The network layer is responsible for the delivery of individual packets from the source host to the destination host. Protocols: X.25Connection oriented IP Connection Less
- 34. NETWORK LAYER Implements routing of frames (packets) through the network. Defines the most optimum path the packet should take from the source to the destination Defines logical addressing so that any endpoint can be identified. Handles congestion in the network. Facilitates interconnection between heterogeneous networks (Internetworking). The network layer also defines how to fragment a packet into smaller packets to accommodate different media. OSI Model
- 36. Transport layer The transport layer is responsible for the delivery of a message from one process to another. Protocols: TCP Connection oriented UDP Connection Less
- 37. TRANSPORT LAYER Purpose of this layer is to provide a reliable mechanism for the exchange of data between two processes in different computers. Ensures that the data units are delivered error free. Ensures that data units are delivered in sequence. Ensures that there is no loss or duplication of data units. Provides connectionless or connection oriented service. Provides for the connection management. Multiplex multiple connection over a single channel. OSI Model
- 38. Reliable process-to-process delivery of a message
- 39. Session layer The session layer is responsible for dialog control and synchronization.
- 40. SESSION LAYER Session layer provides mechanism for controlling the dialogue between the two end systems. It defines how to start, control and end conversations (called sessions) between applications. This layer requests for a logical connection to be established on an end-user’s request. Any necessary log-on or password validation is also handled by this layer. Session layer is also responsible for terminating the connection. This layer provides services like dialogue discipline which can be full duplex or half duplex. Session layer can also provide check-pointing mechanism such that if a failure of some sort occurs between checkpoints, all data can be retransmitted from the last checkpoint. OSI Model
- 41. Presentation layer The presentation layer is responsible for translation, compression, and encryption.
- 42. PRESENTATION LAYER Presentation layer defines the format in which the data is to be exchanged between the two communicating entities. Also handles data compression and data encryption (cryptography). OSI Model
- 43. Application layer The application layer is responsible for providing services to the user.
- 44. APPLICATION LAYER Application layer interacts with application programs and is the highest level of OSI model. Application layer contains management functions to support distributed applications. Examples of application layer are applications such as file transfer, electronic mail, remote login etc. OSI Model
- 46. MIDDLEWARE PROTOCOLS Middleware: layer that resides between an OS and an application May implement general-purpose protocols that warrant their own layers Example: distributed commit 2-5
- 47. CLIENT-SERVER COMMUNICATION MODEL Structure: group of servers offering service to clients Based on a request/response paradigm Techniques: Socket, remote procedure calls (RPC), Remote Method Invocation (RMI) kernel client kernel kernel kernel file server process server terminal server
- 48. ISSUES IN CLIENT-SERVER COMMUNICATION Addressing Blocking versus non-blocking Buffered versus unbuffered Reliable versus unreliable Server architecture: concurrent versus sequential Scalability
- 49. ADDRESSING ISSUES Question: how is the server located? Hard-wired address Machine address and process address are known a priori Broadcast-based Server chooses address from a sparse address space Client broadcasts request Can cache response for future Locate address via name server user server user server user serverNS
- 51. BLOCKING VERSUS NON-BLOCKING Blocking communication (synchronous) Send blocks until message is actually sent Receive blocks until message is actually received Non-blocking communication (asynchronous) Send returns immediately Return does not block either
- 54. BUFFERING ISSUES Unbuffered communication Server must call receive before client can call send Buffered communication Client send to a mailbox Server receives from a mailbox user server user server
- 55. RELIABILITY Unreliable channel Need acknowledgements (ACKs) Applications handle ACKs ACKs for both request and reply Reliable channel Reply acts as ACK for request Explicit ACK for response Reliable communication on unreliable channels Transport protocol handles lost messages request ACK reply ACK User Server request reply ACK User Server
- 57. SERVER ARCHITECTURE Sequential Serve one request at a time Can service multiple requests by employing events and asynchronous communication Concurrent Server spawns a process or thread to service each request Can also use a pre-spawned pool of threads/processes (apache) Thus servers could be Pure-sequential, event-based, thread-based, process-based Discussion: which architecture is most efficient?
- 58. SCALABILITY Question:How can you scale the server capacity? Buy bigger machine! Replicate Distribute data and/or algorithms Ship code instead of data Cache
- 59. TO PUSH OR PULL ? Client-pull architecture Clients pull data from servers (by sending requests) Example: HTTP Pro: stateless servers, failures are each to handle Con: limited scalability Server-push architecture Servers push data to client Example: video streaming, stock tickers Pro: more scalable, Con: stateful servers, less resilient to failure When/how-often to push or pull?
- 60. GROUP COMMUNICATION One-to-many communication: useful for distributed applications Issues: Group characteristics: Static/dynamic, open/closed Group addressing Multicast, broadcast, application-level multicast (unicast) Atomicity Message ordering Scalability
- 61. PUTTING IT ALL TOGETHER: EMAIL User uses mail client to compose a message Mail client connects to mail server Mail server looks up address to destination mail server Mail server sets up a connection and passes the mail to destination mail server Destination stores mail in input buffer (user mailbox) Recipient checks mail at a later time
- 62. EMAIL: DESIGN CONSIDERATIONS Structured or unstructured? Addressing? Blocking/non-blocking? Buffered or unbuffered? Reliable or unreliable? Server architecture Scalability Push or pull? Group communication
- 63. REMOTE PROCEDURE CALLS Goal: Make distributed computing look like centralized computing Allow remote services to be called as procedures Transparency with regard to location, implementation, language Issues How to pass parameters Bindings Semantics in face of errors Two classes: integrated into prog, language and separate
- 64. CONVENTIONAL PROCEDURE CALL a) Parameter passing in a local procedure call: the stack before the call to read b) The stack while the called procedure is active
- 65. PARAMETER PASSING Local procedure parameter passing Call-by-value Call-by-reference: arrays, complex data structures Remote procedure calls simulate this through: Stubs – proxies Flattening – marshalling Related issue: global variables are not allowed in RPCs
- 66. CLIENT AND SERVER STUBS Principle of RPC between a client and server program.
- 67. STUBS Client makes procedure call (just like a local procedure call) to the client stub Server is written as a standard procedure Stubs take care of packaging arguments and sending messages Packaging parameters is called marshalling Stub compiler generates stub automatically from specs in an Interface Definition Language (IDL) Simplifies programmer task
- 68. STEPS OF A REMOTE PROCEDURE CALL 1. Client procedure calls client stub in normal way 2. Client stub builds message, calls local OS 3. Client's OS sends message to remote OS 4. Remote OS gives message to server stub 5. Server stub unpacks parameters, calls server 6. Server does work, returns result to the stub 7. Server stub packs it in message, calls local OS 8. Server's OS sends message to client's OS 9. Client's OS gives message to client stub 10. Stub unpacks result, returns to client
- 69. EXAMPLE OF AN RPC 2-8
- 70. MARSHALLING Problem: different machines have different data formats Intel: little endian, SPARC: big endian Solution: use a standard representation Example: external data representation (XDR) Problem: how do we pass pointers? If it points to a well-defined data structure, pass a copy and the server stub passes a pointer to the local copy What about data structures containing pointers? Prohibit Chase pointers over network Marshalling: transform parameters/results into a byte stream
- 71. BINDING Problem: how does a client locate a server? Use Bindings Server Export server interface during initialization Send name, version no, unique identifier, handle (address) to binder Client First RPC: send message to binder to import server interface Binder: check to see if server has exported interface Return handle and unique identifier to client
- 72. BINDING: COMMENTS Exporting and importing incurs overheads Binder can be a bottleneck Use multiple binders Binder can do load balancing
- 73. FAILURE SEMANTICS Client unable to locate server: return error Lost request messages: simple timeout mechanisms Lost replies: timeout mechanisms Make operation idempotent Use sequence numbers, mark retransmissions Server failures: did failure occur before or after operation? At least once semantics (SUNRPC) At most once No guarantee Exactly once: desirable but difficult to achieve
- 74. FAILURE SEMANTICS Client failure: what happens to the server computation? Referred to as an orphan Extermination: log at client stub and explicitly kill orphans Overhead of maintaining disk logs Reincarnation: Divide time into epochs between failures and delete computations from old epochs Gentle reincarnation: upon a new epoch broadcast, try to locate owner first (delete only if no owner) Expiration: give each RPC a fixed quantum T; explicitly request extensions Periodic checks with client during long computations
- 75. IMPLEMENTATION ISSUES Choice of protocol [affects communication costs] Use existing protocol (UDP) or design from scratch Packet size restrictions Reliability in case of multiple packet messages Flow control Copying costs are dominant overheads Need at least 2 copies per message From client to NIC and from server NIC to server As many as 7 copies Stack in stub – message buffer in stub – kernel – NIC – medium – NIC – kernel – stub – server Scatter-gather operations can reduce overheads
- 76. CASE STUDY: SUNRPC One of the most widely used RPC systems Developed for use with NFS Built on top of UDP or TCP TCP: stream is divided into records UDP: max packet size < 8912 bytes UDP: timeout plus limited number of retransmissions TCP: return error if connection is terminated by server Multiple arguments marshaled into a single structure At-least-once semantics if reply received, at-least-zero semantics if no reply. With UDP tries at-most-once Use SUN’s eXternal Data Representation (XDR) Big endian order for 32 bit integers, handle arbitrarily large data structures
- 77. BINDER: PORT MAPPER Server start-up: create port Server stub calls svc_register to register prog. #, version # with local port mapper Port mapper stores prog #, version #, and port Client start-up: call clnt_create to locate server port Upon return, client can call procedures at the server
- 78. RPCGEN: GENERATING STUBS Q_xdr.c: do XDR conversion Detailed example: later in this course
- 79. SUMMARY RPCs make distributed computations look like local computations Issues: Parameter passing Binding Failure handling Case Study: SUN RPC