Container wars: Rocket vs. Odin vs. Docker

Containers have taken the networking world by storm, offering a lightweight, more flexible alternative to the traditional virtual machine. The major difference between a container and a VM is that a container may share common files, while VM processes are discrete and atomic, even if storage and networking is virtualized and shared. VMs are more like islands; containers can be islands or communes.

One day, we predict, most instances of operating systems atop hypervisors will be containers. In fact, OS makers are already tripping over each other to make ultra-slim, container-friendly versions of their products.

+ ALSO ON NETWORK WORLD: Best open source monitoring tools +

So, are containers ready for prime time in your network? What are the pros and cons? To investigate those questions, we tested three container methods, Docker, Rocket/rkt and openVZ/Odin (formerly Parallels).

Docker leads the way in terms of momentum, but there are also potential problems that need to be surmounted. Rocket/rkt addresses some of these problems, but isn’t yet production ready.

OpenVZ/Odin provides both a container methodology and a “virtual environment” reminiscent of popular hypervisor platforms, but with a few limitations.

All three are potentially very useful and also potentially very dangerous compared to traditional hypervisor and VM combinations. However, with applied care and methodical consideration, all three have great potential.

We tested these products in the context of enterprise systems infrastructure, rather than DevOps and Continuous Development. The energy behind containers, however, means that it’s very difficult to extricate systems infrastructure and its control planes versus the needs/benefits of rapid deployments, scale, and the philosophies behind continuous development practices.

Each of the products tested is in rapid transition, with the elder statesman OpenVZ/Virtuozzo playing a slightly different role, as more of a control plane product for service providers.

The problems containers solve

The evolution of containers is driven by a need for process orchestration that is lighter than VM deployment, but with some of the same systems approach to clustering, and rapid setup and teardown. All this must be done with reliability and security, which is where the heaviest criticism of each platform comes in, and it’s one of the byproducts of the evolution of cloud computing concepts.

+ ALSO: Standards are coming for containers +

In the openVZ/Virtuozzo scheme, container process and rapid roll-out are poised more towards service providers, who are offering appliance-driven infrastructure on the hoof to customers. Examples include canned website/email hosting, website merchandizing, highly language-localized appliance-like offerings, and associated services. In this scenario, instrumentation and billing for multiple baked instances of operating systems are key to a prospective client.

Odin, the renamed branch of Parallels that sponsors openVZ and offers Virtuozzo, has been doing this for a long time. It’s more predictable, more baked, and flexible enough to also be used as a hosting methodology for Docker.

Docker supplies a lightweight OS environment that’s subjugated and disciplined by controls from applied instrumentation. This instrumentation can be rudimentary or involve sophisticated management control planes.

Rocket/rkt is similar to Docker, but more primitive in some ways (and not ready for production). However, as Rocket seems to have been spawned as a response to the perceived sprawl and insecurities in Docker, we found that rkt satisfied some of our engineering instincts that we found wanting in Docker development.

Odin and its foundation of openVZ bills itself as a virtual environment, a hybrid model where a modified kernel is used to do both jobs of a traditional hypervisor, and alternately, the job of a container hosting environment. For example, you could run Docker or Rocket on openVZ.

We found that these three use very similar methodologies. Indeed cross-fertilization among these three parties, and a long list of other visible contributors, is huge. Each seems to sponsor the other in varying ways, and they’re representative of an emerging solution to lightweight instance management without the “heaviness” of traditional hypervisors.

So, do container hosting methods replace traditional Type 1 Hypervisors? Our answer today: not quite—these are different species. But we’re also noting that lightweight OS instances, such as CoreOS, skinny instances of Ubuntu Server, and even Red Hat’s upcoming Atomic distribution, are all designed to serve as the framework inside container hosting method. And we wouldn’t be surprised to see Windows 10 containers on the horizon, although MacOS containers are a stretch of the imagination.

Here are the individual reviews:

OpenVZ/Odin Virtuozzo 6.0

OpenVZ is a Linux distribution that houses hosted guest instances of VMs and/or containers. OpenVZ resources are in modern 3.X+ Linux kernels, and an OpenVZ kernel exists for downloading. Only the OpenVZ kernel is guaranteed to support all features—although a long list of partial OpenVZ services can be installed on Linux 3.X+.

+ ALSO: 12 hot application container startups +

OpenVZ guest instances can be either VMs or containers. When you add instrumentation, billing, and a management plane, you get the commercial product Odin Virtuozzo. Odin is a re-branding of this product by Parallels, a Swiss corporation.

We reviewed Virtuozzo in its Windows incarnation in 2008. Memory limitations of 32-bit servers at that time reduced the usefulness of Virtuozzo. The Windows product remains, but Virtuozzo now has the ability to use a shared kernel to do containers in the Linux realm.

We downloaded openVZ and installed it on a Lenovo ThinkServer RD640. As this scheme surrounds a Linux kernel of comparatively ancient origins, hardened as it may be, hardware compatibility needs to be ensured. We had plenty of server features, and we were told—but did not thoroughly test—that server hardware compatibility associated with Red Hat 6 will work with openVZ or Odin.

You’re tied to whichever HBA and JBOD disk combo you can muster although we verified that openVZ and Odin will work with RAID combos. IPv6 is not fully supported, although “hard” IPv6 VM/container addresses are supported and were tested.

Virtuozzo is a virtual environment, and in our testing, hosted VMs are typically Windows Servers. Linux and FreeBSD are best done as containers. Virtuozzo is controlled via a web app, and has necessary command line components that aren’t in the UI. It can be almost entirely controlled by CLI, if you desire.

Containers can be made from Docker, Rocket or LinuXContainers/LXC. There’s also a repository of OpenVZ/Virtuozzo containers available via download from Odin.

Implementation in OpenVZ is similar to Docker and Rkt. Virtualized environments are installed easily and gave the same performance as the same hardware under VMware 5.5, similarly configured. We did not use extensive benchmarks to come to this conclusion, just the SciMark browser tests we use as a loose metric for performance with Firefox 35, given similar workloads and background usage profiles.

Viewed this way, OpenVZ is much like a hypervisor, although lighter in overall processing weight than VMware, and more like Windows Hyper-V. It also doesn’t have VMware ESXi 5.X’s extensive feature list—or cost.

Testing OpenVZ and Virtuozzo

We tried OpenVZ/OVZ first. There are two branches of installation, one for RedHat-ish releases, and the other for Debian releases. Beneath each of these is a branch for pre-sysctrl and inferences for post-sysctrl. Functionality was essentially the same for all branches, as installation foundation binaries are similar.

The docs are geared for Linux-savvy installers and aren’t complete enough for novices.

OpenVZ wants bare metal although it can be run as a VM. When using bare metal, performance can be staggeringly faster. We suggest strongly not to use OpenVZ or Virtuozzo as VMs as performance cuts, especially when overallocating resources, will cause the entire host to thrash.

OpenVZ containers, or “virtual environments,” are started as a cgroup-demoted service. If the OpenVZ kernel is used instead of a standard issue Linux kernel, then we could use a filesystem called ploop to decrease the number of Linux inodes used.

After deciding the filesystem type, we installed vzctl, the main container controller, then vzquota, which controls container resource volumes/quotas. The vzctl app can then be used to deploy varying container images from the openvz.org site. The containers are very small in initial displacement, and retrieved in the form of a tarball into a cache directory, and deployed from there.

We offer a warning that not all kernels (saving OpenVZ’s kernel) used in late era Linux 3.x kernels offer full support for memory and CPU controls. We didn’t run into a problem, but we can envision scenarios where a kernel doesn’t have all of the OpenVZ toggles compiled into it, resulting in VM or container domination of the host. Ostensibly, a kernel can be recompiled with all the features turned on if desired, but we didn’t test this.

The images are sent with a GPG key so as to authenticate the image. This is important. It’s quite possible to build your own images if desired, although there are plentiful OpenVZ-sourced Linux images. Images downloaded can be deployed directly from image cache. We started many images from scripts; images deploy rapidly, but not as rapidly as Docker atop CentOS in our test environment. The difference in times are negligible, perhaps a few seconds, perhaps because of the time needed by ploop to create its filesystem.

Odin Virtuozzo 6 SP1

The commercial, instrumented side of OpenVZ is Odin’s Virtuozzo, which in our testing, arrived looking very similar to Red Hat 6. Virtuozzo took a very long time to install, and eventually was able to understand our iSCSI storage although we found iSCSI slows Virtuozzo down. NFS is supported and was only slightly faster than iSCSI in testing.

Virtuozzo offers a web page for the minutae of IP configuration (IPv4), including virtual network cards, and VLANs. This is similar to how Xen/XenServer and VMware put networks together, and is poised at multi-tenant configurations.

There are two methods of creating Odin Virtual Environments, one poised towards native hypervisor use—meaning any rational processor/platform-supported operating system—and another designed for Linux container payloads.

+ ALSO: For containers, security is problem #1 +

Those payloads can be serviced by the ploop file systems, but also pfcached/ParallelsFileCacheDaemon with performs deduplication of commonly accessed files in its own ploop filesystem cache. The pfcached uses an algorithm to choose how and when to do deduplication, and we didn’t expect to see an initial performance increase largely because the algorithm takes time to work at achieving greatest effectiveness.

OpenVZ/Virtuozzo containers are instances controlled by vzctl or prctl. One contacts them in the usual ways, ssh, RDP, or the console. In turn, containers execute in their own, normal little worlds, doing work, digesting and storing data, or perhaps offering up a web page.

Containers or VMs are isolated through virtualized Ethernet and no special inter-container or VM communications links are enabled; this must be done on your own, perhaps Puppet, Chef, or another method would be used. Virtual USB, floppy drives, DVDs are available, but only primitive video. It’s possible to build multiple hardware servers that are connected together for high availability purposes, but this wasn’t tested.

We installed four test Windows and Linux ISO binaries (our own ISO sources) as guest VMs, successfully. We did not try advanced graphics, virtualized USB ports, or sound ports. We also tested several Odin images of the same Linux distro sources and found no difference in testing between the two (ex: Ubuntu 14.04 vs Odin-sourced Ubuntu 14.04).

As with OpenVZ, images can be downloaded, ready to deploy on the host substrate. Using pre-formatted templates, user-generated or OpenVZ/Parallels/Odin images get the benefits of optimized memory utilization, although ceilings during a periodic burst activity may slow some VMs or containers, just as it would given administratively-set ceilings in other hypervisors.

CPU MHz (clock cycles), burst limits, and number of CPUs can be allocated. There is no CPU affinity, likely because this is difficult to do with in Linux kernel CPU-task affinity in general.

Using ploop makes file system snapshotting simple, and it’s necessary to do the Virtuozzo live migration of VMs or containers possible. This is aided by the fact that VM or container filesystems are contained as a large object, rather than a discrete set of files, folders, inodes, governed by miscellaneous sysctls behaviors. We did not test live migration.

In use

We could cram a stunning number of containers and VMs into Virtuozzo. Access behaved normally, and the OS found all of the 24 CPU cores in the host, and allowed us to allocate them to VMs or containers. With only a few terabytes of storage and 128GB of memory, we wondered which one would run out first—chip or storage memory. We could overallocate either disk or memory, and so we pushed it, and made some VMs misbehave.