1 / 28

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

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

ayoka
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related