January 1, 2014 | Written by: Marco Celon
Share this post:
Note: We are currently posting the top 10 posts of 2013 today through Jan. 3. This post is #3 on the list and was originally published April 2, 2013.
Recently there has been a lot of discussion about the maturity of some areas of the Openstack project (Gartner, Forrester). In the technical community one thread of this discussion was focusing on the fact that in the current “Folsom” release there are still some concerns in terms of high availability (HA).
It is clear that HA is a key area of interest for organizations embracing cloud computing. High availability also has a number of areas that need to be addressed (Infrastructure, Applications). The requirement to protect a production-grade IT system or application against a failure of any node is not new by any standard, and has been addressed in many software products. Yet these software products are, by and large, not compatible with many cloud offerings, and most public cloud providers do not always provide the required functionality. As a result, users need to complement the cloud deployments with HA constructs that exist outside the cloud.
IBM has already articulated several studies and technical proposals for this topic and I encourage you to read this white paper as well as to connect to this developerWorks® article.
To expediently address the concerns of HA in Openstack a solution that covers the Platform Services (Relational DB and Message Broker) has been presented and documented in the San Diego Openstack Summit and starting from the Folsom release, it focus on using a Pacemaker / DRDB combination to achieve HA for both MySQL and RabbitMQ, to notice that many Pacemaker Resource Agents for specific Openstack components are available for download from gitHub.
Although Pacemaker is a well proven tool in the Linux space it seems that work and evolution is still needed on Openstack to both recover some HA gaps from other cloud platforms like Amazon and Eucalyptus and to define an overall clear strategy for HA in terms of:
- Agree on specific HA patterns, eventually base on different deployment topologies, as several and different approaches are actually used and explored (MySQL/Galera, XtraDB Cluster, MultiMaster Replication Manager.)
- Define a structured documentation for HA in Openstack as bits of information can now be retrieved as part of specific components (Nova) in the Wiki (NovaDb, RabbitMQ) and in the new section we already exposed.
- Collect and correlate all the HA functions already present in other areas of the project like in the Storage (Ceph) and Objects replication (Swift).
The request for HA functionalities is coming directly from the Enterprise adopters of Openstack and as the community as already started to give answers I am sure that in the next Grizzly release it will be possible to see and leverage the effort that is undergoing so that the Openstack ability to be a reference choice for Enterprise cloud deployments will be demonstrated.