1. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 1 DISTRIBUTED SYSTEMS Principles and Paradigms Second Edition ANDREW S. TANENBAUM MAARTEN VAN STEEN Chapter 3 Processes

2. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 2 Thread Usage in Nondistributed Systems Figure 3-1. Context switching as the result of IPC.

3. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 3 Thread Implementation Figure 3-2. Combining kernel-level lightweight processes and user-level threads.

4. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 4 Multithreaded Servers (1) Figure 3-3. A multithreaded server organized in a dispatcher/worker model.

5. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 5 Multithreaded Servers (2) Figure 3-4. Three ways to construct a server.

6. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 6 The Role of Virtualization in Distributed Systems Figure 3-5. (a) General organization between a program, interface, and system. (b) General organization of virtualizing system A on top of system B.

7. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 7 Architectures of Virtual Machines (1) Interfaces at different levels An interface between the hardware and software consisting of machine instructions –that can be invoked by any program. An interface between the hardware and software, consisting of machine instructions –that can be invoked only by privileged programs, such as an operating system.

8. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 8 Architectures of Virtual Machines (2) Interfaces at different levels An interface consisting of system calls as offered by an operating system. An interface consisting of library calls –generally forming what is known as an application programming interface (API). –In many cases, the aforementioned system calls are hidden by an API.

9. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 9 Architectures of Virtual Machines (3) Figure 3-6. Various interfaces offered by computer systems.

10. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 10 Architectures of Virtual Machines (4) Figure 3-7. (a) A process virtual machine, with multiple instances of (application, runtime) combinations.

11. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 11 Architectures of Virtual Machines (5) Figure 3-7. (b) A virtual machine monitor, with multiple instances of (applications, operating system) combinations.

12. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 12 Networked User Interfaces (1) Figure 3-8. (a) A networked application with its own protocol.

13. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 13 Networked User Interfaces (2) Figure 3-8. (b) A general solution to allow access to remote applications.

14. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 14 Example: The XWindow System Figure 3-9. The basic organization of theXWindow System.

15. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 15 Client-Side Software for Distribution Transparency Figure 3-10. Transparent replication of a server using a client-side solution.

16. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 16 General Design Issues (1) Figure 3-11. (a) Client-to-server binding using a daemon.

17. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 17 General Design Issues (2) Figure 3-11. (b) Client-to-server binding using a superserver.

18. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 18 Server Clusters (1) Figure 3-12. The general organization of a three-tiered server cluster.

19. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 19 Server Clusters (2) Figure 3-13. The principle of TCP handoff.

20. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 20 Distributed Servers Figure 3-14. Route optimization in a distributed server.

21. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 21 PlanetLab (1) A Linux-based system for managing server clusters (good for supporting diverse hardware since Linux) PlanetLab is a collaborative Distributed system in which different organizations donate one or more computers, adding up to hundreds of nodes for one or more common purposes (e.g. Particle Physics Research, Cancer research, University research activities) Management of PlanetLab is entirely distributed

22. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 22 PlanetLab (2) A node can be an individual server or a cluster of servers A server Cluster should appear to the outside world as a single computer. A (Linux) Vserver can be thought of as a separate environment in which a group of processes run. Processes from different Vservers are completely independent (i.e. they can not share memory, files, network connections, etc.) Instead, a Vserver provides an environment consisting of its own collection of software packages (e.g. Apache web server)

23. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 23 PlanetLab (3) Managing Server Clusters Figure 3-15. The basic organization of a PlanetLab node.

24. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 24 PlanetLab (4) A Slice in PlanetLab refers to a set of Vservers each running on a different node. A Slice can be thought of as a Virtual Server Cluster, implemented by means of a collection of virtual machines. Each node has a node manager whose only task is to create other Vservers on the node it manages, and to control resource allocation. Keeping track of resources is done by means of Resource Specification or rspec (such as: disk space, file descriptors, network bandwidth,..) UTA has two Vservers running on one Node.

25. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 25 PlanetLab (5) PlanetLab management issues: Nodes belong to different organizations. –Each organization should be allowed to specify who is allowed to run applications on their nodes, –And restrict resource usage appropriately. Monitoring tools available assume a very specific combination of hardware and software. –All tailored to be used within a single organization. Programs from different slices but running on the same node should not interfere with each other.

26. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 26 PlanetLab (6) Figure 3-16. The management relationships between various PlanetLab entities.

27. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 27 PlanetLab (7) Relationships between PlanetLab entities: 1.A node owner puts its node under the regime of a management authority, possibly restricting usage where appropriate. 2.A management authority provides the necessary software to add a node to PlanetLab. 3.A service provider registers itself with a management authority, trusting it to provide well- behaving nodes.

28. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 28 PlanetLab (8) Relationships between PlanetLab entities: 4.A service provider contacts a slice authority to create a slice on a collection of nodes. 5.The slice authority needs to authenticate the service provider. 6.A node owner provides a slice creation service for a slice authority to create slices. It essentially delegates resource management to the slice authority. 7.A management authority delegates the creation of slices to a slice authority.

29. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 29 Reasons Migrating Code (1) So far, we have been passing data in distributed system Passing programs, some even while in execution, simplifies the design of distributed systems Dynamic downloading of client-server software, the software does not have to be preinstalled. i.e. Install on demand Harder in heterogeneous systems

30. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 30 Reasons for Migrating Code (2) Figure 3-17. The principle of dynamically configuring a client to communicate to a server. The client first fetches the necessary software, and then invokes the server.

31. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 31 Migrating Code Examples (3) Example 1: (Send Client code to Server) –Consider a client-Server system where server holds a huge database. If a client application needs to perform many database operations, it may be better to ship part of the client application to the server and server sends only the results across the network. Example 2: (Send Server code to Client) –Data validation at the Database level: In many interactive DB applications, clients need to fill in forms that are subsequently translated into a series of DB operation where validation at server side is required.

32. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 32 Migrating Code Examples – Cont’d (4) Example 3: –System administrator may be forced to shut down a server but does not want to stop the running processes (e.g. to change a part or even permanent shut down) Example 4: –Temporarily freeze an environment, move to another machine and unfreeze (e.g. for debugging sever production issues)

33. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 33 Migrating Code – Benefits (5) Flexibility: Avoid keeping unexecuted code on clients machine, move code to client when service is actually requested. Better load balancing Minimizing network communication Parallelism: –Example: Searching for info on the web. Create mobile search query, called Mobil Agent, and send various copies to different servers to allow parallel search

34. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 34 Migrating Code – Types (6) A Process can be divided in 3 segments: Code Segment Resource Segment Execution Segment Weak Mobility: Migrate only the code segment Strong Mobility: Migrate all three segments Receiver-Initiated: Receiver requests code –Usually simple since receivers asks for info Sender-initiated: Sender pushes code –Must make sure the Sender is genuine (Authenticate)

35. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 35 Models for Code Migration (7) Figure 3-18. Alternatives for code migration.

36. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 36 Migration and Local Resources (1) Figure 3-19. Actions to be taken with respect to the references to local resources when migrating code to another machine.

37. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 37 Migration and Local Resources (2) Recourse Migration Examples: –What happens to a TCP port opened by a migrating process –URL reference to a File when the file is moved Recourse Types: –Fixed Resources: bound to a specific machine or environment and can not be moved (e.g. Local disk drives, communication ports) –Unattached resources: can easily be moved (e.g. Data files) –Fastened resources: may be possible but very costly (e.g. local databases or complete web sites) Binding strength: –(Strongest) By identifier: e.g. when a process uses a URL to refer to a web site by its IP address –(weaker) By Value: e.g. program relies on standard libraries such as “C” or “JAVA”. No need to migrate if the lib is a standard library –(Weakest) By type: e.g. references to local device such as printers,…

38. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 38 Migration in Heterogeneous Systems Three ways to handle migration (which can be combined) Pushing memory pages to the new machine and resending the ones that are later modified during the migration process. Stopping the current virtual machine; migrate memory, and start the new virtual machine. Letting the new virtual machine pull in new pages as needed, that is, let processes start on the new virtual machine immediately and copy memory pages on demand.