1 / 31

Computer Engineering Department Distributed Systems Course Asst. Prof. Dr. Ahmet Sayar

Distributed (Operating) Systems - Virtualization - -Server Design Issues- - Process and Code Migration -. Computer Engineering Department Distributed Systems Course Asst. Prof. Dr. Ahmet Sayar Kocaeli University - Fall 201 3. - Virtualization -. Resource Virtualization.

noel
Télécharger la présentation

Computer Engineering Department Distributed Systems Course Asst. Prof. Dr. Ahmet Sayar

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- Computer Engineering Department Distributed Systems Course Asst. Prof. Dr. AhmetSayar • Kocaeli University - Fall 2013

  2. -Virtualization-

  3. Resource Virtualization • On a single-processor computer, this simultaneous execution is, of course, an illusion. • As there is only a single CPU, only an instruction from a single thread or process will be executed at a time. • By rapidly switching between threads and processes, the illusion of parallelism is created • The separation between having a single CPU and being able to pretend there are more can be extended to other resources as well, leading to what is known as resource virtualization.

  4. 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

  5. Types of Interfaces • Different types of interfaces • Between hardware and software: Assembly instructions that can be invoked by any program. • 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

  6. 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

  7. 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.

  8. Types of Virtualization • Emulation • VM emulates/simulates complete hardware • Unmodified guest OS for a different PC can be run • Bochs, VirtualPC for Mac, QEMU • Full/native Virtualization • VM simulates “enough” hardware to allow an unmodifiedguest OS to be run in isolation • Same hardware CPU • IBM VM family, VMWare Workstation, Parallels,…

  9. -Server Design Issues-

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

  11. 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

  12. 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 • Compare stateful vs. stateless

  13. 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

  14. 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.

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

  16. -Process and Code Migration-

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

  18. 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

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

  20. 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 (machine having the code) • Migration initiated by machine where code resides • Client sending a query code to a database server • Client should be pre-registered • Receiver-initiated (machine receiving the code) • Migration initiated by machine that receives code • Java applets • Receiver can be anonymous

  21. 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

  22. Models for Code Migration

  23. 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 (strongest): 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) • Local database, web sites • Fixed resources • Can not bemoved: Local devices, communication end points

  24. 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

  25. 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]

  26. Case Studies Back up slides

  27. 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

  28. 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

  29. 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

  30. 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

  31. 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