Utility computing

OSv is a cloud computing focused computer operating system, described in this paper.

Currently, virtual machines in the cloud typically run existing general-purpose operating systems, such as Linux, on top of the cloud's hypervisor kernel. The cloud’s hypervisor already provides some features, such as isolation and hardware abstraction, which are duplicated by traditional operating systems (in this case Linux), and that this duplication comes at a cost. OSv aims to replace Linux by addressing the duplication issues by using a low-overhead library-OS-like design.



In the current model on the left, system calls need to go through the JVM, Linux kernel, and Hypervisor kernel. This is inefficient, and the OSv model on the right aims to make it simpler and faster.

Goals of OSv:

1. Run Linux apps (although not all)
2. Faster (app performance)
3. Faster boot time (instead of fork/exec, use VM)
4. Use C++11 (atomic synchronization)

The library OS seeks to achieve the following:

• Every app gets its own virtual machine
• Every app has its own copy of the library (often shared in practice, for performance reasons)
• Every app has its own address space

What we need to build OSv:

• Loader (loads OSv, JVM, etc.)
• Dynamic linker (builds apps not in C++)
• Memory management (new/malloc)
• Thread scheduler
• Synchronization
• Drivers (hook up app to the files hypervisor has control of)

For performance, OSv avoids spinlocks. Spinlocks cause a lock-holder preemption problem. Instead, OSv uses lock-free algorithms by utilizing the atomic operations C++11 provides for accessing shared memory.



In Linux, an application knows that a packet for it is received by using the Linux socket mechanism. This mechanism is considered inefficient for OSv. The application must copy data from system space to user space after it has been received through the network. OSv avoids that by using a dedicated thread for receiving and sending packets. The use of this new mechanism is not enforced, however, because OSv still wants Linux applications to be able to run.
The dedicated thread for receiving and sending packets can run lockless. However, it doesn't provide the LInux/POSIX API! Applications will need to be written differently to accomodate the new API provided by OSv.

OSv also runs tickless. Instead of interrupting each thread at set intervals, OSv uses hardware timers on a per thread basis to cut down on interrupts per second. However, the paper notes that OSv still has to interrupt threads sometimes to deal with specific types of hardware.

OSv only works with JVM-like apps. The idea behind OSv is to modify JVM to use these new socket APIs more effectively. It is designed to run existing Java apps on top of a modified JVM. However, doing so limits OSv to the Java world as only Java apps can run on OSv.

ClickOS is another OS that does not use system calls, developed by Kohler in 2008. This type of operating system has not succeeded yet, but if it does, it could change the way operating systems work with system calls.

• Modularity - appropraite modularity
• Abstraction
• Hiding complexity
• An interface specification
  • Contract between users + maintainers
  • Basis for interoperability
  • Who is in charge of these interface specs?
• Interface =/= Implementation
  • Any interface with just one implementation should be viewed with suspicion
  • Matter of control and technical resources
• Multiple ways to view an OS
• Services = Objects + Operations
  • Object oriented view
  • Works but is slow
  • API almost the same as protocol
• Objects implementation as data structures
  • May be distributed across network (on secondary storage, cache, etc.)
  • Efficiency + pragmatics are crucial

Mainframes were developed by IBM and used during the 1960s to 1980s. The main goal of these mainframes was throughput.



Clusters were developed during the 1990s, and is even used for some applications in the present. Each node has its own disk and network. These separate machines need to be managed for booting, upgrading kernel version, etc. Many different types of software managers were developed, and the most popular one was Beowulf.



Clusters tent to work best when the app is CPU constrained. For example, scientific computational centers use this type of framework.
One downside to this design is that clusters are hard to expand. One solution is to use a "cluster of clusters", but this approach has its limitations as well.

Other contributers to the cloud idea

• "Containerization" of nodes - nodes would be stored in individual containers that would make assembly and disassembly with other containers easy, to make expanding a computational system easy.
• Low power nodes - nodes that would go off when not in use, but come on quickly when needed. One solution to this is to use flash memory instead of disk.

Advantages of cloud computing

• Short-term commitment
• As-needed payment
• Grow as needed "instantly". Useful for:
  • Unknown demand (startups)
  • Varying demand (Superbowl website)

Some popular public cloud service providers are:

• Amazon Web Services (AWS)
• Microsoft Azure
• Google App Engine
• OpenStack

A recent (2013) survey of what type of cloud computing organizations use:

• 19% use public clouds
• 18% use hosted private clouds
• 8% use hybrid clouds - a combination of the other choices
• 55% use on-premise private clouds

Problems with clouds

• Software Licensing - how much does it cost to license a software for multiple users?
  • "Nothing new" - Ellison, Chairman of Oracle Corporation
  • "Licensing trap" - Cloud system designers
  • Acquiring licenses for software could exceed the hardware cost of a cloud system
• Data confidentiality
  • Do you trust public cloud services to keep your data private?
  • A problem for hospitals and other institutions that require confidentiality of client data
  • Solution: host your own on-premise private cloud
• Data transfer bottlenecks
  • The cloud can consist of thousands of processors scattered throughout the world
  • How to transfer data from, for example, LA to Boston?
  • CPUs are not a bottleneck in this case
  • Data transfer bottleneck can be attributed to two factors: throughput and latency
  • "Sneakernet" - transporting hard drives w/ data can be a solution
• Overload risks
  • What if your cloud supplier is busy? One solution is to use multipole suppliers
  • DDOS on a website that is hosted on a public cloud can cause an attack on other websites hosted on the same server - global meltdown is more likely
• Lock-in - Amazon uses EC2, and Microsoft uses Azure. It's expensive/not allowed to bring an application designed to run on Azure to Amazon, and to ask them to host it.
• Debugging
  • How to test and debug a large cloud app?
  • Gdb would not work in this situation because there is too much data across different nodes to handle
  • It is possible to start small, debug locally, and then scale
  • However, scaling presents emergent properties that one cannot predict
• CAP Theorem - Distributed applications often want:
  • Consistency
  • Availability
  • Partition Tolerance
  However, the theorem states that one may only choose two out of the three above.