Verteilte Systeme (Distributed Systems)

Transcription

1 Verteilte Systeme (Distributed Systems) Karl M. Göschka VerteilteSysteme/

2 Lecture 4: Operating System Support Processes and Threads Client/Server Support and Concurrency Object Server Issues Code Migration Virtualization

3 Processes and threads (1) Unit of resource ownership and protection: It provides an address space to the program and protects it from other (concurrent) processes Unit of dispatching: A process encapsulates a program in execution - it contains the execution state of the program and is the entity that is scheduled and dispatched by the OS Enforced with hardware support (kernel mode) High cost for allocation and switching (possibly including swapping) granularity not sufficient 3

4 Process Switching (non-distributed) process B Context switching as the result of IPC 5

5 Processes and threads (2) Process remains the unit of resource management and protection, while thread becomes the unit of dispatching (execution state) Within a process, threads provide concurrent executions that share state (and the address space) minimal thread context (CPU, scheduling information, synchronization) Protection, however, is left to the application developer Trade-off: Robustness vs. efficiency 6

6 Multi-threading (1) A thread is an independent stream of execution Different threads in the same process share a global environment (e.g. same object instance) The accesses of threads to shared resources must be coordinated (synchronized) Different threads may run on different processors if available or share a single processor Threads are provided by operating systems, middleware, or even programming languages Java provides support for threads 7

7 Multi-threading (2) Threads are used to increase performance: Parallelism on multiprocessor machines (more finegrained than processes) Multi-threading is often used to reduce the impact of blocking operations (e.g. IO, networking) so that communication and local processing can overlap Local communication cheaper (vs. IPC context switching) 8

8 Multi-threading (3) Threads are used to improve the structure of a process respectively a large program Application-level parallelism Reactive (server) programming application responds to incoming (client) events Interactive (client) programming one thread to respond to user interaction, another to do the background work avoid blocking and increase perceived speed Asynchronous (batch) processing (e.g., autobackup) 9

9 Multi-threading issues Safety how to synchronize threads so that they do not interfere with one another Liveness how to avoid deadlock situations to ensure that all threads make progress (fairness?) Performance Overhead (performance penalty) from context-switching and synchronization 10

10 User level threads Thread library: routines for thread management, e.g. scheduling; saving and restoring thread context The kernel is not aware of the existence of threads All thread management done by the application: Cheap to create and destroy threads and only few instructions for switching, usually for synchronization purpose Scheduling can be application specific Can run on any OS BUT: Kernel schedules process as a unit Blocking system call will block entire process (including all other threads) BUT: Can not take advantage of multiprocessing 11

11 Kernel level threads (e.g., Windows) Kernel maintains context information for the process and the threads: Thread management is done by the kernel, only API to the kernel thread facility Scheduling is done on a thread basis by the kernel Multiprocessor support Non-blocking Kernel itself can be multithreaded BUT: Allocation and switching need expensive system calls: mode switch to the kernel 12

12 User-Level vs. kernel-level Threads 13

13 Combined Approaches Scheduler hints (Mach kernel) Scheduler Activation: Kernel upcall to thread package (kernel calls the user-level scheduler), but violates layered structure Hybrid: lightweight processes (LWP; Solaris) Process includes the user s address space, stack, and process control block User level thread package: Thread creation done in the user space, also the bulk of scheduling and synchronization of threads within application User level threads are mapped onto kernel level threads: Lightweight processes (LWP) Kernel threads (and LWPs) are scheduled by kernel: There is exactly one kernel thread for each LWP 14

14 Lightweight Process (1) 15

15 Lightweight Process (2) LWP exists within the process address space while at the same time it is bound to a single dispatchable kernel thread LWPs of one process share the user level thread table within that process Exploit concurrency application specific: Single threaded (no concurrency required) Logical parallelism (structuring): Multithreaded without need for hardware parallelism Kernel parallelism for multiprocessing or non-blocking Mixture: Background tasks may share LWP, while resource access via single LWP. 16

16 Lightweight Process (3) 17

17 Lecture 4: Operating System Support Processes and Threads Client/Server Support and Concurrency Object Server Issues Code Migration Virtualization

18 Invocations between address spaces (a) System call Thread Control transfer via trap instruction User Kernel Control transfer via privileged instructions (b) RPC/RMI (within one computer) Protection domain boundary Thread 1 Thread 2 (c) RPC/RMI (between computers) User 1 Kernel User 2 Thread 1 Network Thread 2 User 1 User 2 Kernel 1 Kernel 2 20

19 Client and server with threads Thread 1 generates results T1 Thread 2 makes requests to server Receipt & queuing Input-output Requests N threads Client Server Common threads in a client: UI, processing, network connection Common threads in a server: multiple clients; multiple I/O 21

20 Multithreaded Client Interact with human user and remote server in parallel (non blocking towards user) Hide communication latencies: Do something else in parallel (e.g. Web browser) Load balancing (only useful if supported on server side): connections to different replicas, data transfer in parallel Local data processing Compound documents: Drag-and-drop; inplace editing (notifications) Components for distribution transparency 22

21 Client-Side Support for Transparency Access: stub Location: naming and (re-)binding Replication: proxy Failure: retry, redirect, cache Concurrency: transaction monitor A possible approach to transparent replication of a remote object using a client-side solution. 23

22 N-Tier Java Applet Web Browser HTML Client HTTP Devices Presentation Tier Specific servers Windows Application Distribution Protocol: IIOP, RMI, or proprietary (e.g. DCE) Java Application Web Server Glue Logic HTTP Daemon Servlet static content and templates: HTML XHTML XML JSP Business Tier Session Session Session Session Business Logic Distributed Component Based Infrastructure Transaction Manager Content Mgmt Persistence Manager Libraries Wrapper/Connector Resource Tier Database Access Protocol: JDBC, SQLJ, or proprietary (e.g. SQL*Net) Legacy System proprietary legacy protocol Database Server proprietary legacy protocol 27

23 Architecture Results from case studies Often implicitly used by developers 29

24 Modeling MOF Meta-Meta-Model UML Class Diagram ConcurTask Trees Presentation Modeling Modeling Languages Domain Model relate Task Model relate Presentation Models relate Models communicate communicate Model Controller Views communicate Architecture 30

25 Server Design Issues Iterative or concurrent (e.g., multithreaded) Server interrupt / out-of-band control Stateless, stateful, soft state, session state Where/how to find/bind the server Name or directory servers Well known port addresses (0 1023) (see list at Multithreaded server: Simplifies server code Exploit parallelism for high performance (multiprocessor workstation) 31

26 Client/server binding 3.7 a) Client-to-server binding using a daemon as in DCE b) Client-to-server binding using a superserver as in UNIX (inetd, forks process) 32

27 Multithreaded Servers Example: A multithreaded server organized in a dispatcher/worker model. (dispatcher also called coordinator; worker also called servant or object) 34

28 Structure of a server Different architectures are possible Who creates the thread? When is the thread created? Fixed number of threads? Several design patterns 35

29 Pool vs. dynamic thread creation Thread creation is expensive (100s of instructions) The cost of thread creation can be amortized over many requests by keeping a thread around for several requests A fixed number of threads could be created at start-up time and assigned to requests as they come in 36

30 Server threading architectures workers per-connection threads per-object threads I/O remote objects remote objects I/O remote objects a. Thread-per-request b. Thread-per-connection c. Thread-per-object 37

31 The thread-per-request architecture A coordinator thread reads incoming requests As soon as a request is read, it spawns (creates) a thread to handle the request The new thread decodes the request; calls the servant to perform the request exits 38

32 Thread-per-connection architecture The coordinator thread detects a new client It connects the incoming client to a new thread The new thread decodes the request; calls the servant to perform the request returns to read next request from same client 39

33 The thread-per-servant architecture Each servant has its own thread and queue The coordinator reads an incoming request and inserts it in the queue of appropriate servant Each servant thread repeatedly takes a request from its queue and executes it (simple way of making servants thread-safe through strict serialization) 40

34 Server Clusters The general organization of a three-tiered server cluster 41

35 Lecture 4: Operating System Support Processes and Threads Client/Server Support and Concurrency Object Server Issues Code Migration Virtualization

36 Object server Provides means to access objects remotely according to different activation policies Object creation on invocation vs. during server initialization Separate memory segments vs. sharing code (class definition) Thread policies (single, one per object, one per request,...) and pool vs. on demand object adapter implements policies 43

37 Object Adapter (1) An object adapter (OA) implements a particular activation/invocation policy (OA groups objects per policy) Different OAs may coexist in the same server dispatcher OA is unaware of the specific object interface OA extracts reference and invokes skeleton according to policy 44

38 Example: The Ice Runtime System Example of creating an object server in Ice. 45

39 The main components of CORBA client implementation repository interface repository server object skeleton adapter client program proxy for A ORB core Request Reply ORB core Servant A or dynamic invocation or dynamic skeleton Servants (= programmer supplied object implementation) are a) inherited from generated skeleton or b) they are bound (registered) to particular skeletons 49

40 Role of CORBA Object Adapters Portable and transparent activation of object implementations Creation/management of object references Calling implementation skeleton Control of multiple server threads Basic authentication Deactivation of object implementations Support for persistent identities 50

41 Portable Object Adaptor (1) OID: POA assigned or user assigned Activation explicit or on demand 1. Multiple OIDs single servant 2. One servant for all objects 3. Single servant, many objects and types (DSI) Mapping of CORBA object identifiers to servants. a) The POA supports multiple servants. b) The POA supports a single servant. 52

42 Portable Object Adaptor (2) My_servant *my_object; CORBA::Objectid_var oid; // Declare a reference to a C++ object // Declare a CORBA identifier my_object = new MyServant; // Create a new C++ object oid = poa ->activate_object (my_object); // Register C++ object as CORBA OBJECT Changing a C++ object into a CORBA object. 53

43 Lecture 4: Operating System Support Processes and Threads Client/Server Support and Concurrency Object Server Issues Code Migration Virtualization

44 Code migration (1) Parameters passed among client and server may refer not only to data but also to code perhaps even while being executed! Historical: Balancing of computational load Distributed Systems: Moving code to where the data is can lower communication overhead: move query processing to database machine moving code to client can also improve scalability (e.g. form processing) 55

45 Example of Migrating Code The principle of dynamically configuring a client to communicate to a server. The client first fetches the necessary software, and then invokes the server (e.g. Java applet). 56

46 Code migration (2) Exploit parallelism (linear speed-up of e.g. Web search) Flexibility: Moving code can be used to customize (i.e. configure) the client dynamically and provide service interfaces on demand: Improved versioning and evolution BUT Security? BUT Code migration in heterogeneous systems is costly and intricate! Mobile code offers a different paradigm for structuring of distributed applications 57

47 Models for Code Migration Alternatives for code migration: Consider code segment, execution segment, and resource segment 58

48 Migration and Local Resources (1) Resource segment can not always be moved along without being changed Three types of process-to-resource bindings Binding by identifier Binding by value Binding by type Three types of resource-to-machine bindings Unattached resources Fastened resources Fixed resources 59

49 Migration and Local Resources (2) Resource-to machine binding Unattached Fastened Fixed Process-toresource binding By identifier By value By type MV (or GR) CP ( or MV, GR) RB (or GR, CP) GR (or MV) GR (or CP) RB (or GR, CP) GR GR RB (or GR) Actions to be taken with respect to the references to local resources when migrating code to another machine: GR Establish a global systemwide reference MV Move the resource CP Copy the value of the resource RB Rebind process to locally available resource 60

50 Lecture 4: Operating System Support Processes and Threads Client/Server Support and Concurrency Object Server Issues Code Migration Virtualization

51 Virtualization (1) Threads provide illusion of several processors Virtualization extends this idea to the resources 70s: run legacy software, e.g., IBM s: Application software is outliving system (operating system and hardware) portability Administration of large and heterogeneous systems and applications flexibility+portability Isolation: Reliability and security 62

52 The Role of Virtualization in DS a) General organization between a program, interface, and system. b) General organization of virtualizing system A on top of system B. 63

53 Interfaces at different levels (2) Various interfaces offered by computer systems. 65

54 Architectures of Virtual Machines (1) A process virtual machine, with multiple instances of (application, runtime) combinations. E.g., JVM. 66

55 Architectures of Virtual Machines (2) A virtual machine monitor, with multiple instances of (applications, OS) combinations. E.g., VMware, Xen 67

56 Migration in Heterogeneous Systems (1) Can the code segment be executed at all? Is the execution segment properly represented? scripting languages and highly portable languages (Java) rely on a process virtual machine that interprets source code (scripting) or intermediate code (Java) 68

57 Migration in Heterogeneous Systems (2) recently: migrate the whole computing environment (virtual machine monitor): strong mobility resources are part of moved environment service continuation during maintenance resource bindings: network-to-mac binding (storage as separate tier) memory image % 69

58 Migration in Heterogeneous Systems (3) Ways to handle migration (can be combined) Pushing memory pages to the new machine and resending the ones that are later modified during the migration process. ( extra effort) Stopping the current virtual machine; migrate memory, and start the new virtual machine. ( long service interruption) 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. ( long migration period) pre-copy: method 1 + method 2 (~200ms interruption) 70

59 Summary Concurrency is naturally present in a distributed system and needs operating system support Concurrency may be exploited in several ways in distributed systems: To improve performance by hiding delays due to blocking To structure high-performance servers To structure clients that hide server replication Other paradigms with different operating system support code migration virualization 76