High availability in the cloud: An OpenStack approach

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:

  1. 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.)
  2. 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.
  3. 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.

Share
Comments: 49
Marco Celon

About Marco Celon

Marco is a solutions consultant at Cisco. He is a former IBM cloud delivery specialist and is based in Australia.
This entry was posted in OpenStack, Standards and tagged , , , , , , , , , , , , , . Bookmark the permalink.

49 Responses to High availability in the cloud: An OpenStack approach

  1. Hello Marco,

    I agree on the the Pacemaker/DRDB-combination: for my OpenStack implementation this seems a great alternative: http://www.cloudcomp.ch/2013/04/pacemaker-cluster
    What do you think about pros and cons of the different HA patterns used in MySQL/Galera, XtraDB etc.? Shouldn't the real discussion start at this point?

    • Marco Celon says:

      Hi Konstantin, sure it is and at the moment is the most reliable way to provide HA also cause quite a number of Pacemaker/DRDB implementations are active in the OpenStack space so that you are able to access best practices and to obtain support using forums and all the other community tools. About the options that you have out there you should consider that MMM is lacking the support of the Galera solution and in their Main Page themself are pointing to that tool. Galera and XtraDB are based on the same libraries of HA but in XtraDB everything is packaged together with the Percona Database server. All that said my personal choice is still Pacemaker/DRDB for the reasons I told you before and cause in the discussions that are ongoing in the community it seems that this is going to be the "official" solution. However and as I pointed out in the post we are still missing an overall strategy for the OpenStack, something that embrace the whole solution and not only some part of it, we need to make choices, document and propose best practices… Just stay tuned on the OpenStack community and already in the recent Grizzly release you can see some of the results of this effort coming out. Cheers, Marco.”

Comments are closed.