If there’s one thing that I got asked a lot is a summary of my viewpoint on “why you choose opennebula”, after my presentation at the last OpenNebulaConf. Basically the answer is always “it depends on what you’re looking for” but it rarely suffices, so I take advantage of the invitation by Ignacio Llorente to write a few words on that. Let’s start with an image that explains how people usually views the debate:
And – let’s be clear – it does not really convey the fact that OpenNebula and OpenStack are both terrific project with slightly different needs and use cases, and so this comparison is probably useless. After all, do we really say that we can’t have both Apache and Nginx as web servers? Who said that we can’t have both, in their respective market niches?
In my view, OpenStack is a toolkit for creating sophisticated Infrastructure-as-a-Service platforms, and is composed of several top level projects and many more ancillary pieces, a view that is shared by many others (for example Monty Taylor, or Jay Pipes) that can be summarily shown as:
Talking about “an OpenStack cloud” is thus quite indefinite, as it may be composed of just three pieces or thirty. Another defining aspect is the overall scalability, that implies that (just because there are lots of different pieces, connected in many different ways) there are lots of knobs. Lots.
Well, OpenStack probably needs them all.
And – just to be clear – a very large OpenStack installation probably needs most of them, since they need to provide components that must be usable and deployable in innumerable different conditions and combinations.
OpenNebula is structurally different: it is much more a finished product, with a modular structure that covers a subset of the OpenStack projects, with a much smaller set of variables and knobs:
| OpenStack component | OpenNebula equivalent |
| Compute (Nova) | builtin |
| Object Storage (Swift) | no equivalent |
| Image Service (Glance) | builtin |
| Identity (Keystone) | builtin |
| Dashboard (Horizon) | SunStone |
| Networking (Neutron) | builtin |
| Block Storage (Cinder) | builtin+plugins |
| Telemetry (Ceilometer) | builtin |
| Orchestration (Heat) | flow |
| Database Service (Trove) | no equivalent |
| Data processing (Sahara) | no equivalent |
| Bare metal (Ironic) | no equivalent |
| Queue service (Zaqar) | no equivalent |
| Key management (Barbican) | no equivalent |
| DNS Services (Designate) | no equivalent |
Most of the higher level services do have no equivalent in OpenNebula, and it’s mostly by design – if you need a service you add it through an external VM that provides what you need. For example, if you need an object storage service you can use Riak, Ceph, Walrus, Gluster, Skylable are among the first that come to mind, all with different advantages and disadvantages (and you can even use swift inside of an OpenNebula VM, by the way :-))
The “all in one” approach of OpenNebula also simplifies common management operations, like recovery from failover. OpenStack needs external automation or a manual intervention; as an example, to recover from a total fault on a compute node:
“If a compute node fails and won’t be fixed for a few hours (or at all), you can relaunch all instances that are hosted on the failed node if you use shared storage for /var/lib/nova/instances. To do this, generate a list of instance UUIDs that are hosted on the failed node by running the following query on the nova database: mysql> select uuid from instances where host = ‘c01.example.com’ and deleted = 0; Next, update the nova database to indicate that all instances that used to be hosted on c01.example.com are now hosted on c02.example.com: mysql> update instances set host = ‘c02.example.com’ where host = ‘c01.example.com’ and deleted = 0; After that, use the nova command to reboot all instances that were on c01.example.com while regenerating their XML files at the same time: # nova reboot –hard <uuid> Finally, reattach volumes using the same method described in the section Volumes.”(from OpenStack Operations Guide, sep. 2014, page 140)
Even after a compute node reboot, you may have to handle things properly:
“After the compute node is successfully running, you must deal with the instances that are hosted on that compute node because none of them are running. Depending on your SLA with your users or customers, you might have to start each instance and ensure that they start correctly. … You can create a list of instances that are hosted on the compute node by performing the following command: # nova list –host c01.example.com –all-tenants After you have the list, you can use the nova command to start each instance: # nova reboot <uuid>”OpenNebula on the other hand manages the same thing with the fault hooks, mostly managing things in an automated way. Other aspect are extremely simplified in OpenNebula, like action/condition triggers, where OpenStack Heat is certainly more complete and sophisticated than the probes available within OpenNebula.
Another aspect is size: OpenNebula is one tenth of OpenStack in terms of lines of code – 1841Klines for OpenStack vs. 193Klines for OpenNebula (data from J.G.Barahona, “the quantitative state of the open cloud”, OSCON 2014) which means that changing, adapting and simply looking at the code to understand it is ten times easier and cheaper as well.
If we look at the features that are expected both from devops and enterprise users (as defined by the fine folks at the 451 group) we can see that what is looked for is a set of features like these:
| Feature | Audience |
| Supports hybrid cloud networking (multi-vendor, public, hosted) | DevOps and enterprise business users |
| Supports private cloud offerings | Both |
| Supports vendor and user service blueprints | Enterprise business |
| Supports VM provisioning, HA, scaling, recovery | DevOps |
| Integrates with developer tools (such as Chef or New Relic) | DevOps |
| Offers a self-service portal, service catalog | DevOps |
| Integration/migration (transformation engine) | DevOps |
| Provides workload placement recommendations | Enterprise business |
| Offers consumption management/optimization recommendations | Enterprise business |
| Supports role-based access control/security | Both |
| SaaS and on-premises license models | Enterprise business |
| Offers app monitoring and system tool extensions (patching, backup, OS monitoring, etc.) | Both |
source: 451 group “Cloud Management Platforms: a comparison of product categories”
And it’s easy to see that apart for the last line (where probably the only open source platform with said features is ManageIQ) everything else is more or less covered by both.
The end result is that OpenStack and OpenNebula should be seen as complementary offerings – if you need a toolbox, or the features of some or all the many components offered by the OpenStack ecosystem just go there. Lots of people will help you in building your cloud, the amount of activity and enthusiasm is amazing and beautiful. If you need something that can be deployed, understood and used in a few hours (without sacrificing scalability or core features) look at OpenNebula.
The open cloud does have space enough for both.
Hi Carlo,
Interesting read. I agree with you that the open cloud space has more than enough room for both camps. Just wanted to clarify something… neither Monty nor I subscribe to the OpenStack Layers view of the OpenStack world. Monty sees a smallish “Layer #1” with a couple components in it that would be necessary to launch an app like WordPress easily in a cloud. And I take the view that there is no core in OpenStack at all; or at least, no core worth spending time trying to figure out. 🙂
All the best,
-jay
Thanks- and sorry if I seemed to imply you endorse one view or the other. I followed with interest the current debate on what “core” is, and I see lots of different views; I tried to summarize it for people that may be unaware of the long and complex discussion (and the more recent view of “umbrellas”, API-friendly, and whatnot :-)) My desire for a simplified view comes from the many questions I got on “equivalence”, as lots of competing vendor use a somehow stratified/layered approach in their documentation.
There is anyway no big difference even if we reject the idea of a core (apart from nova, neutron, glance and keystone): most components do map to equivalent OpenNebula builtin at the lower level, while there is no direct ON equivalent for the higher-level services for DBaaS, Queues and others, so there is a fundamental philosophical/structural difference that is however not that easy to perceive from a cursory glance of the respective website.
As I said, I believe strongly there is space for both, and in some cases even for some form of “cross-pollination” between them, and I strongly resent the somehow dramatic approach of “there will be only one” that implies that only one cloud toolkit can survive; OSS has demonstrated over and over that in many instances there is space for alternatives with different strengths and weaknesses.
And many thanks for reading and commenting!