fos for multicore and clouds

8/13/2019 FOS for Multicore and Clouds

1/68

An Operating System for Multicoand Clouds:

Mechanisms and ImplementatiPresenters:HIBA AL-MASRI, BUSHRA AL- ZA'AREER

Supervisor: DR. AMJADNUSEIR

Faculty of computer & InformationTechnology

computer science Department/JUST


2/68

Outline

Introduction

Factored operating system (fos) Benefits of a single System Image

Multicor and Cloud OS challenges

Architecture

Case Studies Results and Implementation Conclusion


3/68

Introduction

The average computer user has an ever-increasing amof computational power at their fingertips.

Users have progressed from using


4/68

Introduction

The next decade will also bring single chip microprocecontaining hundreds or even thousands of computing

Contemporary OSes designed to run on a small numbreliable cores are not equipped to scale up to thousancores


5/68

Introduction

Cloud computing and Infrastructure as a Service (IaaS

promises a vision of boundless computation It can be tailored to exactly meet a users need

this need grows or shrinks rapidly

Unfortunately IaaS requires users to explicitly manageresources and machine boundaries

the ease of using a cloud computer must match that ocurrent-day multiprocessor system.


6/68

Current IaaS systems present a fractured and non-unview of resources to the programmer

They uses virtual machine as a provisioning unit but wa suitable abstraction layer

which introduce complexity to the system user

Introduction


7/68

The user is responsible for

fractured communication paradigms of intra-machine

(shared memory and pipes) and inter-machine (socket

communication

Scheduling and load balancing

System administration

I/O devices

Fault tolerance

Introduction


8/68

The solution could be to have a single image OS that IaaS systems as easy to use as multiprocessor system

factored operating system (fos) designed to meetthese needs

Fos is a single system image OS on multicore proceswell as cloud computers

it tackles OS scalability and adabtibility challenges

Factoring the OS into its component system services

Each system service is further factored into a collection of Intinspired servers which communicate via messaging

Introduction


9/68

Outline

Introduction



Architecture

Case Studies

Results and Implementation Conclusion


10/68

Factored operating system (fos)


11/68

Outline

Introduction



Architecture

Case Studies



12/68

Benefits of a single System Image

Ease of administration Transparent sharing

Informed optimizations

Consistency

Fault tolerance


13/68

Outline

Introduction




Architecture

Case Studies



14/68


Scalability

The current multicore revolution promises drastic changein fundamental system architecture

the number of general-purpose schedulable processingelements is drastically increasing.

Cloud resources are virtually unlimited for a given user

only restricted by monetary constraints

scalability is a first order design constraint for future OSein both single machine and cloud systems.


15/68

Variability of demand

multicore OSes need to manage the number of live core

in contrast , single core Oses only have to manage wheta single core is active or idle.

cloud computing makes more resources available on-demand than was ever conceivable in the past.

In both cases the demand is not static and resources arevariable

fosseeks to reduce the heat production and powerconsumption while maintaining the throughputrequirements imposed by the user.



16/68

Faults

In multicore systems as the hardware industry is con

decreasing the size of transistors and increasing theirsingle chip, the chance of faults is rising.

system software components must gracefully supportcores and bit flips

In clouds systems performance interference from othusers and applications can potentially impact the quaservice provided to the application

Programming for massive systems is likely to introdufaults

the lack of tools to debug and analyze large software makes software faults hard to understand and challen



17/68

Programming chalenges

Developing cloud applications composed of severalcomponents deployed across many machines is a difficutask

there is not a uniform programming model forcommunicating within a single multicore machine and

between machines managing and load-balancing these systems is proving

be a daunting task as well



18/68

Outline

Introduction




Architecture



19/68

Architecture

fos uses the following design principles:

Space multiplexing replaces time multiplexing

OS is factored into function-specific services, where e

is implemented as a parallel, distributed service

OS adapts resource utilization to changing system ne

Faults are detected and handled by OS


20/68

Fos Architecture


21/68

Fos Architecture

Microkernel

fos microkernel executes on every core in the system

fos uses a minimal microkernel OS design which prov

protected messaging layer

a name cache to accelerate message delivery

Basic time multiplexing of cores

Application Programming Interface(API)

All other OS functionality and applications execute in space.


22/68

Microkernel

API is designed to allow a process on one core to modifymemory and address space on another core if appropriacapabilities are held.

which allows fos to move significant memory managemand scheduling logic into userland space.

Architecture


23/68

Messaging

fos Providing a simple process-to-process messaging API need of OS Inter-Process communication and synchronizat

Advantages

messaging can be implemented on top of shared memorprovided by hardware, thus allowing this mechanism to

a variety of architectures sharing of data becomes much more explicit in the progr

model

Architecture


24/68

Messaging

fos allows conventional multithreaded applications withshared memory

Operating system services are implemented strictly usingmessages

fos messaging works intra-machine and across the cloudusing differing transport mechanisms to provide the sameinterface

Architecture


25/68

Sendingnode

Proxyserver

Sharedmemory

Proxyserver

Sharedmemory

Intendnod

Intendednode

Fist station Second stationNetwork

Architecture

Messaging


26/68

Messaging

Each process has a number of mailboxesthat other processes may delivermessages to provided they have thecredentials

Fos presents an API that allows theapplication to manipulate these

mailboxes and their properties.

Processes within fos are also able toregister a mailbox under a given name.

Architecture


27/68

Naming

Each service is divided into process or servers Each process is

Independent

Run on a different core

capable of handling the given request

All of them have the same name

Architecture


28/68

Naming

The criteria to choose the best member for a specifitask

1. The load of all servers and the latency

2. Fixed policy such as round robin and closest server

3. Custom policies such as callback mechanism and complix lobalancer

4. Metadata such as message queue length

Architecture


29/68

Naming

The criteria to build the nameserver1. Low latency for the service

2. Maintaining a consistent and global view of the namespa

3. Able to make continual update to the name-lookup

The importance of naming

Make abstraction that provide flexibility in load balancing alocality to the OS

much of the complexity in communication is abstracted bethe naming and messaging API

Architecture


30/68

OS services

Each service is composed of several servers

Servers in aggregate can accomplish a given task

Servers can be on the same station or on deferentstations(scalable)

Fleets communicate internally via massaging

Fleet is elastic(watchdog service and handshaking process)

Architecture


31/68

OS services

Difficulties with fleet1. Its complicated to program

2. Each service may have different parallelization strategies

3. Each service may have different constraints

Fos solution

1. Providing cooperative multithreading programming model2. easy-to-use remote procedure call (RPC) and serialization

facilities

3. data structures for common patterns of data sharing.

Architecture


32/68

Fos server model

The model is implemented as a user-space threading librar

The goals

to abstract calls to independent, parallel servers to make them appelibraries

to mitigate the complexities of parallel programming

Servers are event-driven programs, events are messages.

Messages arrive on one of three inbound mailboxes

external (public) mailbox

the internal (fleet) mailbox

the response mailbox

Architecture


33/68

Fos server model

The interface to the server is a simple function call

Threading library abstract away massaging

this model doesnt eliminate all the complexities of paralprogramming Because other code will execute on the serduring an RPC

The cooperative scheduler runs if There are threads ready to run

If no thread is ready, then a new thread is spawned that waits onmessages

If threads are sleeping for too long, then they are resumed with atime out error status.

Architecture


34/68

The idea is to provide a common container interface, w

abstracts several implementations that provide differenproperties of

Consistency

replication

performance

In the back end each server store some of the data ancommunicate with others for other data

This will alleviating the application developer fromconcerning themselves with the implementation ofdistributed data structures

Architecture

Parallel data structures


35/68

Outlines

Introduction




Architecture



36/68


37/68

Case StudiesFile System

fos file server is an example of interaction between

different servers in fos

To diminish cache and performance interferances:

Application client

fos file system server

block device server

all executing on distinct cores, communication is via messa

infrastructure(see figure 3: Anatomy of a file system)


38/68

Case Studies: File System


39/68

Case Studies

File System

steps(on application client):1. fos intercepts application client

2. bundles it in a message to be sent via the massaging layer

3. fos queries the name cache and sends the message to destinationcore


40/68


steps(on file system server):4. If the data requested by the application :

is cached, the server bundles it into a message and sends it back to the requeapplication

Otherwise, it fetches the needed sectors from disk through the block device d

server(as in this example, see figure)5.represents the bundling of the sectors request into block messages6.look-up of the block device driver in the name cache, then the fos

microkernel places the message in the incoming mailbox queue of t

block device driver server


41/68


steps (on block device driver server):7. 8. 9. In response to the incoming message, the block device drive

processes the request enclosed in the incoming message, fetches sectors from disk as portrayed

10. encapsulates the fetched sectors in a message

11. look-up of the file system server in the name cache

12. thenthe fos microkernel places the messageback to the incomingqueue of thefile systemserver


42/68


steps: in the file system server:

13. file server processes the acquired sectors from the incominmailbox queue, encapsulates the required data into messages

14. sends them back to the client application In the client application:15. libfos receives the data at its incoming mailbox queue and

processes it in order to provide the file system access requestthe client application


43/68


Case2: the file system server is not running on the machine(i.e. the name cache could not locate it):1.message is forwarded to the proxy server has the name cache

location of all the remote servers .then ,it determines the appropdestination machine for the message

2.bundles it into a network message

3.sends it via the network stack to the designated machine Although this adds an extra hop through the proxy server,it pro

the system with transparency when accessing local or remote ser


44/68


Instead of the fragmented view of the cloud resourcescloud environment, in case 2 :

A single image system was provided by unmessaging and naming allows servers to be assignany machine in the system, this gives a unapplication programming model to use inter-machineintra-machine resources in the cloud


45/68

Case StudiesSpawning Server

SpawnProcess(): bundles the spawn arguments intoa message

sends that message to the spawn serversincomingrequest mai

Where to deploy?

The spawn server interacts with the scheduler to deter

the best machine and core for the new process to start o


46/68

Case Studies

Spawning Server

Ifthe best is the local machine:

the spawn server sets up the address space for the new process

starts it The spawn server then returns the PID to the process

If on a remote machine is best:

the spawn server forwards the spawn request to the spawn server on

remote machine, which then spawns the process


47/68

Case Studies:Spawning Server


48/68

Case StudiesElastic Fleet

Watchdog process

Watch the load :

1. spawning a new member of the fleet

2. initiating the handshaking process that allows the new s

join the fleet

3. During the handshaking process, existing members of the

notifiedof the new member, and state is shared with the n

member


49/68


example (many servers on a single machine that are requesting service look-ups from the nameserver): the watchdog process watch that queues are becoming full

of the nameservers decide to spawn a new nameserver

allow the scheduler to determine which core to put this namon

notice fos provide programming model which takbenefit of being dynamically scalable to matchdeman


50/68


whatchdog process also, choose decision and poli

Resources available in a global scale

Load and location of existing servers

Monetary concerns

So, fos can make a much more informed decision than sothat simply look at the cloud application at the granularity


51/68

Outlines

Introduction




Architecture

Case Studies Result and Implementation

Conclusion


52/68

Result and Implementation our experiment:

16 machines, two xen x5460 processors(8 cores) runnning at3.16GHz and 8GB of main memory

interconnected via two 1Gbps Ethernet port


53/68

Result and Implementation competitive with Linux inthese basic metrics as well

the cloud1. System Calls2.Ping Response3.process creation4.File System5.Web Server6.Single System Image Growth


54/68

Result and Implementation Localsystem call


55/68

Result and ImplementationSystem Calls Timing was gathered using the hardware time stamp

counter from table1:

fos's currently is slower than linux's to improve messaging and system call performance u

URPC(User-level Remote procedure Call), where theinitial result promise to reduce the messaging time ansystem call


56/68

Result and Implementation Remote System Calls


57/68

Ping Response

Result and Implementation


58/68

Process Creation



59/68


File System


60/68


Web server


61/68


Single System Image Growth

Test

Eucalyptus as the cloud manager

fos cloud interface server used the EC2 REST API

Test Implementation

fos VM was manually started

started a second fos VM instance via Eucalyptus The proxy servers on the two VMs then connected and shared

providing a single system image by allowing fos nativemessages to occur over the network


62/68


Single System Image Growth

Test Result The amount of time it took for the first VM to spawn

integrate the second VM was 72.45 seconds

time in the result outside of fos

response time of the Eucalyptus cloud controller

time to setup the VM on a different machine with a 2GB dis

time for the second fos VM to receive an IP address via DHC

round trip time of the TCP messages sent by the proxy servwhen sharing state


63/68

Outlines

Introduction




Architecture


C l i


64/68

Conclusion

Cloud computing and multicores have created new

ofplatforms for application development

fos a single system interface providing a progra

model that allowsOS system services to scale with de

fosis scalable and adaptiveBy placing key mechani

multicore and cloud management in a unified opesystem


65/68

Any Question


66/68

Thank You ...


67/68

Reference

Wentzlaff, David, Charles Gruenwald III, Nathan Beckmann, Kevin Modzelewski,Belay, Lamia Youseff, Jason Miller, and Anant Agarwal. "An operating system forand clouds: mechanisms and implementation." In Proceedings of the 1st ACM syon Cloud computing, pp. 3-14. ACM, 2010.


68/68

fos for multicore and clouds

Documents