Distributed (Operating) Systems - Virtualization - -Server Design Issues- - Process and Code Migration -

1. Distributed (Operating) Systems -Virtualization- -Server Design Issues- -Process and Code Migration- Fall 2011 Kocaeli University Computer Engineering Department

2. -Virtualization-

3. Virtualization • Virtualization: extend or replace an existing interface tomimic the behavior of another system. • Introduced in 1970s: run legacy software on newer mainframe hardware • Handle platform diversity by running apps in VMs • Portability and flexibility

4. Types of Interfaces • Different types of interfaces • Between hardware and software: Assembly instructions • Between OS and hardware: Assembly instructions by privileged programs • System calls: Offered by OS • Library functions: APIs • Depending on what is replaced /mimicked, we obtain different forms of virtualization

5. Types of Virtualization • Virtualization can take place in two different ways: • Process Virtual Machines • Runtime system that essentially provides an abstract instruction set that is to be used for executing applications. • Instructions can be interpreted but could also be emulated as is done for running Windows applications on Unix platforms. • In this case, emulator also mimic the system calls. • Ex. JVM • Virtual Machine Monitor • See the next slide

6. Virtual Machine Monitor VMM • Typical examples are VMware and Xen • Virtualization is implemented as a layer completely shielding hardware • Offering the complete instruction sets • Can be offered simultaneously to different programs at the same time • It is possible to have multiple, and different operating systems run independently and concurrently on the same platform.

7. -Server Design Issues-

8. Server Design Issues • Server Design • Iterative versus concurrent • How to locate an end-point (port #)? • Well known port # • Directory service (port mapper in Unix) • Super server (inetd in Unix)

9. Server Designs -more- • Iterative or sequential • Single process no threads in that process • Service one request at a time • No concurrency • Multithreaded • Every time new request comes in handed it to new thread • Full concurrency • Event-based • Sits in between 1 and 2 • Single process with single thread • The way you emulate concurrency is that all calls are not blocking (non-blocking IO) • Sequential calls and single process but you still get concurrency • Process-based • Each request is assigned to a different process

10. Stateful or Stateless? • Stateful server • Maintain state of connected clients • Sessions in web servers • Stateless server • No state for clients • Soft state • Maintain state for a limited time; discarding state does not impact correctness

11. Server Clusters • Collection of machines connected through a network, where each machine runs one or more servers • Mostly connected with LAN having high bandwidth and low latency • Logically organized into three tiers • Each tier may be optionally replicated; uses a dispatcher • Use TCP splicing or handoffs

12. TCP hand off • Standard way of accessing server cluster – TCP connection • Switches accept incoming TCP connection requests and hand off connections to one of the servers.

13. Scalability • Question : How can you scale the server capacity? • Buy bigger machine! • Replicate • Distribute data and/or algorithms • Ship code instead of data • Cache

14. -Process and Code Migration-

15. Code and Process Migration • Motivation • How does migration occur? • Resource migration • Agent-based system • Heterogeneous - Homogeneous systems

16. Motivation • Key reasons: performance and flexibility • Process migration (aka strong mobility) • Improved system-wide performance • Better utilization of system-wide resources • Examples: Condor, DQS • Code migration (aka weak mobility) • Shipment of server code to client – filling forms (reducecommunication, no need to pre-link stubs with client) • Ship parts of client application to server instead of data fromserver to client (e.g., databases) • Improve parallelism – agent-based web searches

17. Motivation • Flexibility • Dynamic configuration of distributed system • Clients don’t need preinstalled software – download on demand

18. Migration models • Process = code seg + resource seg + execution seg • Weak versus strong mobility • Weak => transferred program starts from initial state • Sender-initiated versus receiver-initiated • Sender-initiated • migration initiated by machine where code resides • Client sending a query to database server • Client should be pre-registered • Receiver-initiated • Migration initiated by machine that receives code • Java applets • Receiver can be anonymous

19. Who executes migrated entity? • Code migration (weak mobility) • Execute in a separate process • [Applets] Execute in target process • Execute in the same process that downloaded the code • Process needs to be protected against malicious codes • Process migration (strong mobility) • Remote cloning (remote fork) • Create a clone and migrate it • Migrate the process

20. Models for Code Migration

21. What about resource segmentDo Resources Migrate? • So far, migration of the code and execution segment are mentioned. What about resource segment? • Depends on resource to process binding • By identifier: specific web site, ftp server • By value: Java libraries • By type: printers, local devices • Depends on type of “attachments” • Unattached to any node: data files • Fastened resources (can be moved only at high cost) • Database, web sites • Fixed resources • Local devices, communication end points

22. Resource Migration Actions • Actions to be taken with respect to the references to local resourceswhen migrating code to another machine. • GR: establish global system-wide reference • MV: move the resources • CP: copy the resource • RB: rebind process to locally available resource

23. Migration in Heterogeneous Systems • Systems can be heterogeneous (different architecture, OS) • Support only weak mobility: recompile code, no run time information • Strong mobility: recompile code segment, transfer execution segment [migration stack] (figure) • Virtual machines - interpret source (scripts) or intermediate code [Java]

24. Case study: Agents • Software agents • Autonomous process capable of reacting to, and initiatingchanges in its environment, possibly in collaboration • More than a “process” – can act on its own • Mobile agent • Capability to move between machines • Needs support for strong mobility • Example: D’Agents (aka Agent TCL) • Support for heterogeneous systems, uses interpreted languages

25. Case Study: Viruses and Malware • Viruses and malware are examples of mobile code • Malicious code spreads from one machine to another • Sender-initiated: • proactive viruses that look for machines to infect • Autonomous code • Receiver-initiated • User (receiver) clicks on infected web URL or opens an infected email attachment

26. Case Study: PlanetLab • Distributed cluster across universities • Used for experimental research by students and faculty in networking and distributed systems • Uses a virtualized architecture • Linux Vservers • Node manager per machine • Obtain a “slice” for an experiment: slice creation service

27. Case Study: ISOS • Internet scale operating system • Harness compute cycles of thousands of PCs on the Internet • PCs owned by different individuals • Donate CPU cycles/storage when not in use (pool resources) • Contact coordinator for work • Coordinator: partition large parallel app into small tasks • Assign compute/storage tasks to PCs • Examples: Seti@home, P2P backups

28. Case study: Condor • Condor: use idle cycles on workstations in a LAN • Used to run large batch jobs, long simulations • Idle machines contact condor for work • Condor assigns a waiting job • User returns to workstation => suspend job, migrate • Flexible job scheduling policies