By Dor Laor, Tzach Livyatan

In the following demo, Dor is running 4 different OSv base virtual appliances on his laptop:

• Redis
• Tomcat
• MySQL
• Cassandra

Each virtual appliance is a full–blown VM, each with a pre-integrated cloud application, and each launched without terminating the others.

As you can see, application startup time takes between sub-second (Redis) to a few seconds (Cassandra) depending on the application. The hypervisor plus OS part of the boot time is less than a second for all cases.

Want more info on Capstan and related topics? Join the osv-dev mailing list. You can get regular OSv updates by subscribing to this blog’s feed, or folllowing @CloudiusSystems on Twitter.

Pop quiz: what does this graph show?

If you’d like a hint, here’s some context. It’s from the upcoming talk on Cassandra on OSv at Cassandra Summit in San Francisco.

We’ve been picking up a bunch of Cassandra tips at the event so far. And we’re really looking forward to (a) tomorrow’s talks from the administrators of large-scale Cassandra sites and (b) showing off a new useful thing that should make life much easier for Cassandra admins who know curl. Which would be…everyone?

If you missed the chance to see Don Marti and Glauber Costa at Linuxcon/CloudOpen, please come see us, with bonus extra speaker Dor Laor. Otherwise, you can keep up with the latest OSv news from this blog’s feed, or folllowing @CloudiusSystems on Twitter.

(Next up: Xen Project User Summit in New York City…)

The previous blog article, on Jolokia mentions a configuration item for cloud-init. You may be asking, “Cloud init? How do I use that on OSv?” Well, good news. For details on configuring OSv using the cloud init mechanism, check out our recently updated wiki page: Cloud init.

Tomasz Grabiec has written an informative page on how to configure your OSv instance, from setting the port for the management HTTP server to filling in the content of config files. Check it out. (Naturally, it’s a wiki, so feel free to fill in additional details if you like.)

Want more info on cloud-init and related topics? Join the osv-dev mailing list. You can get regular OSv updates by subscribing to this blog’s feed, or folllowing @CloudiusSystems on Twitter.

By Calle Wilund

OSv is a great way to run Java applications in the cloud, and it recently became just a little bit better. As you are probably aware, OSv exposes quite a bit of information and manageability options through its RESTful API, accessible through the built-in HTTP server. More or less from its inception, this API has exposed various aspects of the JVM and the Java Management Beans provided.

Recently we improved on this a bit by including the Jolokia JMX-via-JSON-REST connector, providing full read/write access to the entire set of Java manageability attributes and operations. Now you no longer need to set up and secure separate JMX-over-RMI connectivity with your Java application to fully manage it.

The Jolokia API is available via the OSv REST server at `http[s]://:/jolokia`</nobr>. You can explore this and other API:s via the [Swagger UI](https://github.com/cloudius-systems/osv/wiki/The-RESTful-API#using-the-swagger-ui). For a better understanding of the full [Jolokia syntax](http://www.jolokia.org/reference/html/protocol.html), I suggest reading through the [reference manual](http://www.jolokia.org/reference/html/index.html). In its simplest form, querying a Java Management Bean value from an OSv instance can be done like this:

> curl http://<ip>:<port>/jolokia/read/java.lang:type=Memory/HeapMemoryUsage

With the result of something like:

{	
	"timestamp"	:1409065190,
	"status"	:200,
	"request"	: {
			"mbean"		:"java.lang:type=Memory",
			"attribute"	:"HeapMemoryUsage",
			"type"		:"read"
			},
	"value"		: {
			"max"		:1839202304,
			"committed"	:1839202304,
			"init"		:1918894080,
			"used"		:192117128
			}
}

Jolokia provides a full syntax for packaging JMX bean information inside JSON objects, including the ability to batch requests. It also provides client connector libraries for Java, Perl and JavaScript to access them easily from (web) applications.

##Important note about REST requests and browser security Most browsers today enforce that resources such as REST queries may only be made to the same domain as the requesting web page. When you want to allow cross-domain requests you need to either turn off this security feature in your browser (for Google Chrome you can run it with --disable-web-security, however if you use Firefox I do not know of any way to do it), or enable CORS in OSv.

To do the latter, you need to provide a httpserver configuration section in your cloud init settings. To simply allow all domains to make requests to the OSv APIs, add this to your configuration:

httpserver:
    access-allow: '*'

And make this reachable through your cloud-init server. (Or use the EC2 simulator script provided with OSv).

A small demo

A small demo JavaScript application showing how to easily plot various JVM graphs from a running OSv instance can be found at https://github.com/elcallio/jolokia-demo (which is a modified fork of the Jolokia demo created by Tomasz Nurkiewicz.

To test the demo, simply clone the repository and edit the src/js/osvhost.js to match the IP address and port for your OSv instance. (Don’t forget to make sure that your OSv image includes the HTTP server).

Since I am runnning OSv compiled from source, I simply go to my OSv source tree and type:

> make image=httpserver,mgmt

…<chug, chug, chug> And when it is done:

> ./scripts/run.py --api

This will build and start an almost empty image, containing only the HTTP server, cloud init support and the Java-based shell (not a very interesting appliance, I admit, but you can pick any image you prefer). Running like this, the REST API is available from http://localhost:8000, so this is what I enter into src/js/osvhost.js.

Then load the jolokia-demo/src/index.html in your favourite browser, and you should be greeted by this:

As you can see, the demo provides the start of a small management console for Java with just a few lines of Javascript code, most of which actually deal with setting up the charts. Requesting and polling the actual data on the other hand is almost ridiculously easy.

Having Jolokia integrated in the OSv manageability layer means that not only can you access all the JMX attributes parallel with the rest of the exposed OSv aspects, not having to modify Java appliances, but also that you only need to deal with securing a single service point.

This is just one small aspect of all the new and exciting manageability features that are in or coming to OSv. Over the next few months we hope to bring you additional aspects that will further enhance your deployment experience. Stay tuned.

If you have any questions on OSv management, please join the osv-dev mailing list. You can get general updates by subscribing to this blog’s feed, or folllowing @CloudiusSystems on Twitter.

While we relax and don’t have to fix anything on our slides (really, they’re all done), other speakers at the Linux Foundation’s CloudOpen North America conference in beautiful Chicago have some observations to make about OSv.

The Linux Foundation always picks great conference locations.

Russell Pavlicek from the Xen project mentioned several library OSs that run on Xen in his talk on new Xen features. He called the concept “one of the biggest advances in the cloud.” Earlier library OSs have shown how much performance and simplicity gains are available, and OSv is extending the idea to ordinary POSIX and Java applications.

Mike Day from IBM said, “the engineers who write OSv are really good C++ coders,” and called the project “some of the finest C++ source code I’ve ever seen” in his talk on cloud operating systems for servers. He also had some praise for the spinlock-free way that OSv handles mutexes, which as regular readers of this blog will know is important to prevent the dreaded lock-holder preemption problem.

If you’re at LinuxCon, excuse me, #linuxcon, please come over and say “hi” to the OSv speakers: Don Marti and Glauber Costa. Hope to see you at the event, and please come to “Beating the Virtualization Tax for NoSQL Workloads With OSv” on Friday at 10:45 in the Colorado room. Otherwise, you can get general OSv updates by subscribing to this blog’s feed, or folllowing @CloudiusSystems on Twitter.

Chicago River photo: Urban for Wikimedia Commons

By Glauber Costa and Don Marti

We’re planning to attend the Linux Foundation’s CloudOpen North America conference. Hope to see you there, and please come to our talk, “Beating the Virtualization Tax for NoSQL Workloads With OSv.”

We’ll be using a popular NoSQL database for our demo: Redis. If you’d like to follow along, you’re welcome to clone and build Redis on OSv. We’re big Redis fans, because it’s a fast, easy-to-administer, in-memory database that works with many useful data structures.

Redis A to Z

Redis is a remarkably useful piece of software. People on the Internet talk about Redis a lot. Here’s what Google Suggest has to say about it: Atomic, benchmark, cluster, delete, expire, failover, gem, hash, incr, Java, key, list, master/slave, node.js, objects, Python, queue, Ruby, set, ttl, Ubuntu, “vs. mongodb”, Windows, XML, yum, zadd. (zadd is a really cool command by the way. A huge time-saver for maintaining “scoreboard” state for games and content-scoring applications. Did we mention that we’re Redis fans?)

Redis fills a valuable niche between memcached and a full-scale NoSQL database such as Cassandra. Although it’s fast and perfectly usable as a simple key-value store, you can also use Redis to manage more featureful data structures such as sets and queues.

It makes a great session cache, lightweight task queue, or a place to keep pre-rendered content or ephemeral data, and it’s a star at highscalability.com.

But you probably already know that.

Building Redis on OSv

Redis works normally on OSv except for one feature: the BGSAVE command. A Redis background save depends on the operating system’s copy-on-write functionity. When you issue the BGSAVE command, the parent Redis process calls fork, and the parent process keeps running while the child process saves the database state.

Copy-on-write ensures that the child process sees a consistent set of data, while the parent gets its own copy of any page that it modifies.

Because OSv has a single address space, that isn’t an option here. OSv support Redis SAVE but not BGSAVE. Other than that, running redis on OSv requires little effort. From the OSv source tree, all one should do is:

make image=redis-memonly

Now you have a usr.img file, which you can run locally with OSv’s run.py. Behind the scenes, all that this build step is doing is to issue the application’s make, with the right set of flags so redis is a shared library. For more info on how to do that, see our earlier example. of how to use the -fPIC and -shared options.

Is it fast?

We have been running redis on local machines to test many of its functionalities and help us mature OSv. As with any piece of software, the result of course depends on many factors. Because OSv is an operating system designed for the cloud, we wanted to showcase its performance running on Amazon EC2.

To do that, we have selected the c3.x8large machines. They feature 32 CPUs and 60Gb of memory each. We are fully aware this is an overkill in the case of Redis - a single threaded application. However, those are the only machines that Amazon advertises as featuring 10Gb networking, and we didn’t want the network to be a bottleneck for the sake of the benchmark. Also, smaller machines cannot be put in EC2 placement groups. It all boils down to the network!

So in this benchmark, no more than two cores should be active at any given time - one for redis, one for network interrupt processing. In a real scenario, one could easily deploy in a smaller machine.

Benchmark setup

We have benchmarked redis’ latest beta (beta-8) running both on OSv, and on an Ubuntu14 AMI. To do that, we have just launched a new AMI, selected Ubuntu14.04, and launched it. Once it launched, we have downloaded and compiled redis’ latest, and moved the redis.conf used by OSv to the machine. The only difference in that configuration file from what is shipped with redis by default, is that we disable disk activity. As already explained, OSv currently do not support that, and to be fair, the Linux guest we are comparing against should not hit the disk either at any point.

On ubuntu, redis was run with:

numactl --physcpubind=1 redis-server ~/redis.conf

Using numactl considerably reduces the standard deviation coming from the Linux scheduler moving the thread around.

The redis-benchmark command was issued in another machine of the same type, running in the same zone and placement group.

The two commands were:

numactl --physcpubind=1 redis-benchmark --csv -h <IP> -c 50 -n 100000 -P 1

and later on, to demonstrate how OSv can handle larger messages,

numactl --physcpubind=1 redis-benchmark --csv -h <IP> -c 50 -n 100000 -P 16

What this last command does, is to exercise redis’ pipeline feature, that can send multiple - in this case 16 - commands in the same packet. This will decrease the impact of the round trip time in the final figure.

The difference can be clearly seen in the graph…

Note that the LRANGE class of commands has a significantly different pattern than the other commands. In that command, the client sends a very short query, and receive a potentially very large reply, thereby exercising the transmission path, rather than the receive path of OSv. This table shows that our transmission path is lacking a bit of love, particularly when the response sizes grows (as the pipeline level increases)

Conclusions

OSv is a fast maturing, but not yet mature operating system, soon to be in beta phase. We have gaps to close, as can be seen in the case of LRANGE set of benchmarks. So far, we have focused our efforts in technologies around the receive path, and it has paid off: We can offer a level of performance far beyond what an out of the box distribution can. Some features that we architecturally lack, makes the use of Redis as a full-blown on-disk database challenging. But if you want to serve your load from memory, the OSv promise delivers: With OSv, you don’t have to pay the virtualization tax.

If you’ll be at CloudOpen, you can add our talk to your schedule now.

If you have any questions on running Redis or any other application, please join the osv-dev mailing list. You can get general updates by subscribing to this blog’s feed, or folllowing @CloudiusSystems on Twitter.

Clojure developers usually do not care too much about the underlying OS. The low-level differences between Linux, Mac OS, and even Microsoft Windows are abstracted away by the JVM.

When deploying Clojure code on the cloud, there used to be one default choice - Linux. But Linux is not an ideal OS for pure cloud services.

OSv is a new, open source OS, designed specifically for the cloud. Since OSv supports the standard JVM, it is ideal for running Clojure applications on the cloud. And the same configuration applies to building VMs for any cloud: public clouds such as Amazon’s and Google’s, private clouds based on VMware or KVM, or public and private OpenStack.

Porting a Clojure application to OSv was already pretty easy, but now it’s even easier. This blog post describes a new lein template for OSv.

Usage

Capstan works together with the Leinigen build tool.

First, create a new project skeleton.

lein new capstan new-app

Now, you can run Capstan to run your project on an a OSv VM.

cd new-app
capstan run

The template takes care of creating the project skeleton, including the Capstanfile. When this is done, you can use Capstan directly to build a new OSv VM, deploy it on the cloud, or upload it to the public repository.

</p>

For more info on Capstan and other OSv subjects, please join the osv-dev mailing list.
You can get updates on by subscribing to the OSv blog RSS feed or following @CloudiusSystems on Twitter.

By Tzach Livyatan This post is a response to the excellent presentation “Java Application Servers Are Dead!” by Eberhard Wolff. Go read his slides and come back here.

Back already? Assuming you agree with Eberhard’s claims, let me demonstrate how most of his points on Java Application Servers can be applied to a generic OS (one designed for hardware servers) in the cloud as well.

First let me scope the discussion. An operating system can run on your mobile, desktop, back office, or as a VM on the cloud. For this post, I’m referring specifically to the cloud use case, which can be public or private. Cloud deployments are the important case to concentrate on, as new Java application servers are mostly deployed on VMs these days.

Illustration: Omarcito for Wikimedia Commons (http://commons.wikimedia.org/wiki/File:Omarcito.gif)

Eberhard present different properties of the Java Application Server, and for each, demonstrates why it is no longer relevant. I will follow his footsteps, applying the same methodology to generic OS, for two of the properties: Container for multiple applications and Deployment.

Container for multiple applications

Both the Java application server and the OS are supposed to isolate applications from each other. Both do a good job at it, and OS isolation is definitely somewhat stronger. However, it is still not good enough for multitenancy, even with OS-level containers. This is why we have hypervisors, and this is why most deployment in the clouds include one application per VM.

Deployment

I agree with Eberhard’s claim that Java deployments (JAR, WAR, EAR) are problematic. Linux-style packaging, using RPM or deb packages, is not a full solution either.

In a cloud environment, there is no reason to start with a blank OS, and spend 15 minutes downloading and installing the application. It makes more sense to use a pre-installed server image (AMI, in AWS terms) with the application already installed. Indeed, using a ready-made AMI is a common practice.

Containers are another successful attempt to fix this problem, but running containers on a virtual machine brings an extra layer of complexity. More on that here. Obviously, there is still a requirement to install urgent patches on both AMI and containers.

To summarize, both the Java application server and the generic OS were created to provide a set of services which is no longer required.

With Java AS and generic OS dead, what’s next?

** Micro Services **

“an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API” Martin Fowler Illustration: Martin Fowler (http://martinfowler.com/articles/microservices.html)

Each micro service can can have its own end to end stack, from the OS up to the application. As explained above, an ideal scenario would be to deploy the micro service logic directly on a hypervisor, cutting two middle layers: the application server and the generic OS.

At this point you might doubt my sanity. Run my application on EC2 with no OS at all to support it? Not quite.

As you recall from the “AS are dead” presentation, the application server has become an application library, dedicated to supporting a single application. With the Library OS concept, the the same process can also be applied to the OS, making it a library of the application.

For every micro service, one can use a tool like Capstan to cook a new VM, pre integrating the application, JVM and the OS - to a ready to be deployed VM. Just take it and deploy it on your favorite cloud provider.

Take Capstan for a spin

For more info on Capstan and other OSv subjects, please join the osv-dev mailing list.
You can get updates on by subscribing to the OSv blog RSS feed or following @CloudiusSystems on Twitter.

By Don Marti

If you’re writing a program that keeps a cache in memory, you’re probably expecting users to have to set the cache size, which means a configuration setting or command-line argument. And every configuration setting or command-line argument is something that you have to document, or explain to users when they get it wrong.

Thankfully, there’s an easier way.

With OSv, you can ask the OS to let your program know when memory is tight, so that you can manage the cache size on the fly. Less time spent tweaking settings, more items kept in cache, what’s not to like? Just set up a shrinker callback and register it. (There is a mechanism for memory pressure notifications on Linux, but it’s somewhat complex. With OSv it’s just one function to write.)

Defining a shrinker function

OSv notifies your program of a low memory situation by calling a shrinker callback.

A shrinker function takes two arguments:

• target amount of memory to free (size_t)

• A boolean “hard” argument. This is false if the function is being called for preemptive freeing of memory, and true if the system is under severe pressure.

In most invocations, the argument hard will be set by OSv to false. This indicates that the system is acting preemptively, and memory pressure is starting to build up. The application is free to defer the freeing of objects to a later stage. Having your shrinker callback called with hard set to true, however, means that OSv is under severe memory pressure, and may be unable to serve allocations. If not enough memory is freed, the system may be forced to abort.

Registering

Now that the shrinker function is defined, you need to register it.

To register a shrinker function involves calling osv_register_shrinker:

void *osv_register_shrinker(const char *name,
                            size_t (*func)(size_t target, bool hard));

For example, an application in C can just do:

extern void *osv_register_shrinker(const char *name,
                            size_t (*func)(size_t target, bool hard));

int main () {
  ...
  osv_register_shrinker("Example Shrinker", shrinker_function);
  ...
  return 0;
}

An extremely basic example of a program that uses the OSv shrinker API is memory-hog. To try it, install Capstan, clone the Git repository, and build an OSv image to run it. Currently memory-hog requires at least 2GB of memory.

$ git clone git@github.com:dmarti/memory-hog.git
Cloning into 'memory-hog'...
remote: Reusing existing pack: 76, done.
remote: Total 76 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (76/76), 12.84 KiB | 0 bytes/s, done.
Resolving deltas: 100% (39/39), done.
Checking connectivity... done.
$ cd memory-hog
$ capstan run -m 2G
Building memory-hog...
Created instance: memory-hog
OSv v0.09
eth0: 192.168.122.15
I'm a memory hog!
program: 	Oink!
program: 	Oink!
program: 	Oink!

...many "Oink!"s later...

program: 	Oink!
shrinker:	Soft pressure, all done.
program: 	Oink!
shrinker:	Soft pressure, all done.
program: 	Oink!
shrinker:	Soft pressure, all done.
program: 	Oink!
shrinker:	Soft pressure, all done.
program: 	Oink!
shrinker:	Soft pressure, all done.
program: 	Oink!
shrinker:	Soft pressure, all done.
shrinker:	processing request to free 166062080 bytes.
shrinker:	starting with 64 things.
shrinker:	finishing with 58 things.
		192534576 bytes of memory were freed!
program: 	Oink!
shrinker:	Soft pressure, all done.

Concurrency

Shrinker callbacks conceptually work like asynchronous signal handlers, They handle specific events and may be called at any time, from your program’s point of view.

Each cache in your program that the shrinker can release data from, must have its own lock to prevent concurrency issues.

The memory-hog sample program uses a mutex to handle concurrency. To handle soft memory pressure, where your shrinker is called with hard set to false, you can keep a global free_memory_please global variable, and set it in the shrinker callback. Then check it in the main loop, and free memory if necessary. However, hard memory pressure must be handled immediately, or the system may hang.

Handling soft pressure

If possible, you should have your shrinker try to release some memory when called with hard set to false. This will reduce the number of times you have to handle shrinking, and improve performance by making more free memory available to OSv for system tasks. The memory-hog example currently ignores soft pressure.

For more info on memory management and other OSv subjects, please join the osv-dev mailing list. You can get updates on by subscribing to the OSv blog RSS feed or folllowing @CloudiusSystems on Twitter.

What happens in that critical fraction of a second between when a virtual x86_64 system “powers up” and when it begins running operating system code written in a high-level language?

For a helpful walk-through, there’s a new article on the OSv wiki, originally written by Elazar Leibovich.

The boot process for a modern VM traces its history back to the original IBM PC.

While some of the intricate startup steps are historic, the end result is an OSv boot time that’s less than a second—an order of magnitude faster than a conventional multi-user OS. To read (or contribute!) details, the “OSv early boot” article on the wiki.

(photo: Hans Haase for Wikimedia Commons. Available under the Creative Commons Attribution-Share Alike 3.0 Unported license.)

If you have any questions on OSv internals, or porting your application, please join the osv-dev mailing list. You can get general updates by subscribing to this blog’s feed, or folllowing @CloudiusSystems on Twitter.