CloudStack VS OpenStack

During the past few years our company has been working with cloud platforms like Apache CloudStack and OpenStack to build private clouds for our clients as well as for our internal use. Now we ready to share our opinion and observations about these two platforms talking about relatively small private deployments.

Private cloud is a platform which provides an easy way to manage cloud infrastructures like virtual machines, networks and storage along with flexible accounts management for ordinary end-users (not only for experienced administrators).

The main purpose of the private cloud is to reduce amount of cost required to host already existing environment or to build a new one – highly available and reliable, scalable and cost effective. This solution is rather effective when environment contains some finite number of constantly running virtual machines (VMs), and when your budget for purchasing or renting hardware to host these VMs substantially lower than prices for the same resources offered by popular cloud providers (like Amazon, Google, RackSpace, etc.).

Below we will try to compare some key aspects of CloudStack and OpenStack and describe which of the mentioned platforms looks more preferable from both our professional and personal points of view.

Hope this article will help you make the right decision when you decide to run your own private cloud.

Speaking about private cloud, we principally mean a core functionality described below. If you need, for example, Object Storage or Orchestration Service integrated as a part of a cloud platform – sure, OpenStack as platform looks much preferable because aggregates all of them. However, before you decide in favour of OpenStack please familiarize yourself with key aspects of both platforms’ functionality and implementation.

Possibly you do not need so many additional services integrated into a cloud platform, if its core functionality does not completely satisfy your requirements for:

Cloud platform should provide the next minimal set of features:

If we speak about CloudStack this platform provides all mentioned features as part of the monolithic management service and they are available all the time during the management service operation.

OpenStack splits this functionality between such core components as Nova, Neutron, Glance, Cinder and Keystone. Each component also divided into a few or more services which communicate with each other using message broker, configured using multiple .INI files and depend on SQL database. Thus, if one of the services fails the rest services may work incorrectly or may stop working at all.

On the project navigator page you can also check the full list of OpenStack components and their status like adoption and maturity, compare them with projects age and decide if they are really ready for production assuming that you want to use the cloud solution instead of developing it yourself to make it working.

Independently from the chosen platform, it’s obvious that backup is one of the most important things. And most important is the ability to do the backups regularly based on preferable schedule.

Both platforms have the functionality to backup machines using volume snapshots.

In CloudStack you can manage backup policies and automate snapshots creation by schedule using built-in product feature.

In OpenStack you will need to handle snapshots creation with additional scripts, create them manually or extend the deployment with some 3-rd party plugins or services. So, if you’re not a developer or an experienced system administrator most likely it will be a problem for you to do it by yourself and you will need to invest some additional costs into implementation of this feature in OpenStack.

One of the mandatory requirements for a private cloud is that deployment must be highly available and fault-tolerant. First, it’s important to differentiate high availability of a cloud platform itself and high availability for virtual machines (and thus – services inside these virtual machines) and networks.

Is both high availability features included by default into each of the cloud platform we’re talking about? Unfortunately, it is not so.

High availability and fault tolerance of a cloud platform itself is a configurable feature. This must be handled by the experienced deployment engineers who develop the cloud architecture based on technical requirements and available resources.

High availability and fault tolerance for end-users’ virtual machines and services deployed inside this cloud platform – is a platform specific feature, which can be either already included into the platform or not.

Starting a new virtual machine its owner hopes that the system will be available full time of its life circle (except for some downtimes for planned maintenance, of course), but in the real world it’s not always possible due to many reasons.

We know that in CloudStack the user can specify a virtual machine as HA-enabled. By default, all system VMs (virtual routers, VNC console and storage) are automatically configured as HA-enabled. When an HA-enabled machine fails, CloudStack detects this and restarts the virtual machine automatically within the same Availability Zone.

When we have just started working with OpenStack our main concern was availability of HA for VMs feature on this platform. What was a surprise when we found out that OpenStack doesn’t really have this feature built-in and it can be handled on hypervisor level only. Actual status of this feature in OpenStack can be checked here. One more illustrative example of this feature status is OpenStack user story. As you can see, it was proposed but has not been implemented for the past years.

So, if you want to make your virtual machines highly available in OpenStack, be sure that they will be able to automatically migrate to another host in case of failure or, for example, recover with a minimal downtime after unexpected hardware failure (like power outages, hardware issues, etc.), software failure inside a virtual machine which caused system shutdown (kernel bug, OOM, etc.) or infrastructure failure (like shared storage failure) you must additionally use a hypervisor which will handle VMs high availability and hardware hosts failures.

Not a secret, that KVM is the most tested and used OpenStack hypervisor (new and already existing features tested exactly using KVM first). But, if you run OpenStack deployment using KVM (which does not provide HA for VMs from scratch) as hypervisor, you also will not be able to provide HA for VMs.

Sure, this does not mean that HA for VMs cannot be implemented with OpenStack and KVM. The most common way to do it is to use Heat in combination with Ceilometer and manage VMs inside Heat stacks. For example, Platform9 use exactly this way to provide this must-have feature and have a nice thirteen minute demonstration video which shows how to create highly available VMs using their OpenStack implementation.

More than likely that many engineers who worked with both platforms would opt for simpler option with enabling / disabling a checkbox for virtual machines HA in CloudStack, rather than using so many things like OpenStack Heat, Ceilometer and virtualization to create a highly available virtual machine in OpenStack.

High availability of networking is a critical question for each deployment and both platforms provide their specific implementation of L3 HA.

CloudStack provides the solution based on the above-mentioned native support of Virtual Machines HA: virtual routers presented as specific virtual machines and their availability is handled as entire VMs HA.

OpenStack is designed as a modular and distributed platform, so to handle high availability of the networking services it will be required to distribute virtual routers at least between two hardware machines.

Both, CloudStack and OpenStack, have a controller for management of the system, but the implementation of this controller is a bit different.

CloudStack controller is a single management server process which use database to store configuration and can run inside hardware or virtual machine. Management server connects to compute hosts directly via hypervisor or via agents depending on the hypervisor type. Both management services can be clustered using common practices like MySQL replication (to handle load on database) and TCP load balancing (to handle API and WEB requests).

In OpenStack, controller is a machine which has the same hardware resources as a compute node and runs multiple services like databases, message broker, WEB-server and set of OpenStack components. Most of these services can be clustered to provide HA for the management service itself and make it fault tolerant. However, this will require adding more server instances to the system, that will lead to complication of system support in the future and will require additional efforts and peoples’ resources for managing the deployment.

It’s obvious that each service could be a potential point of failure, and the more the number of services, the higher probability of failure. In CloudStack number of potential points of failure is lower comparing to OpenStack.

It’s evident that works on the private cloud do not end up with the setup and configuration. Developed environment, hypervisors, operating systems and hardware require regular maintenance and upgrades.

Depending on the platform, number and variety of customizations and dependencies maintenance task can be fast and easy or become a nightmare.

Both, CloudStack and OpenStack, are open source products. It means that any registered community member can contribute into these platforms. However, communities of CloudStack and OpenStack are a bit different.

CloudStack community is managed by Apache Software Foundation. It has the core team responsible for the new features implementation as well as for bug fixes. That means all information and data are available at one place and it is well structured.

OpenStack community is a huge network (primary between core contributors) that is completely decentralized. As a result, bug fixes and new features may be included into different distributions and with different frequency. So, before starting to work with OpenStack you should decide which distribution to use: RedHat, Ubuntu, Mirantis or any other software provided as self-hosted solution or as a service. One more aspect of OpenStack decentralization is that a lot of technical information can be found in the internal documentation of its core contributors only, which is not always open and regularly updated. Lack of actual and well-documented information sufficiently complicates the configuration process and further maintenance and usage of this platform, that obviously increases the costs of works.

Both platforms have their own issues to be addressed, pros and cons. We continue to believe that CloudStack is more stable, easier, and cost & time effective solution for relatively small private clouds, which typically do not have large number of hardware servers and huge amount of resources to host multiple clusters, as well as don’t require many technicians to monitor and maintain the deployment health.