Checking OpenStack’s Pulse With Pacemaker

melissa • November 27, 2014 • 1 Comment

High availability is an important aspect of any infrastructure deployment.  We’re all familiar with technologies such as VMware’s HA and Microsoft Cluster Server.  Pacemaker brings this same functionality to the Linux world.  Pacemaker can scale from a two node active/passive cluster to a 16 node active/active cluster.  Pacemaker also brings enables you to ensure application components stay separated, or stay on the same machine, similar to VMware’s anti-affinity and affinity rules.


Setting the Pace

Pacemaker is one piece of the puzzle.  Pacemaker is a cluster resource manager, and will take care of things like nodes joining and leaving the cluster and monitoring of resources.  To take care of the messaging and quorum aspect of the cluster, it relies on another component.  This component can be a couple of different things, but the more popular options are Heartbeat and Corosync.  While it may sound complex, Pacemaker and Corosync are not that difficult to set up.  GeekPeek.Net has a great three part series on getting them up and running on CentOS.

Protecting the Stack
Pacemaker can be used to protect key services in an OpenStack deployment.  In this case, Corosync is usually the messaging layer of choice.  Why is this important?  We’ve talked about the Keystone identity service and how central it is to OpenStack operation, but it isn’t the only one.  Glance, the Image service, Cinder, the block storage service, Neutron, the networking service, and Ceilometer, the telemetry service are all services that can wreak havoc on an environment if they aren’t functional.

pacemaker

(Pacemaker architecture with Corosync)

After Pacemaker and Corosync have been installed, each service can be added to Pacemaker.  This is the foundation for making each service into its own high availability service with some being able to be active/active, and some being active/passive.  The OpenStack High Availability Guide gives a great foundation for building out your service protection strategy.

NFV and Neutron
One of the biggest areas where High Availability is needed is the OpenStack networking and Network Function Virtualization.  We hear a lot about challenges with scalability and resiliency in Neutron, but the point where scale is a problem is usually larger than many companies will find themselves growing.  NFV is another set of features that enterprise vendors are pushing to build in HA at installation.  NFV as a part of the HA cloud is one of the key drivers to bring it to the mainstream.

Will OpenStack Become High Availability OOB?
This is a question that many are asking.  Is the out of the box OpenStack able to add high availability, or does it make more sense to rely on external services and third party features to get this done?  With enterprise customers eyeing OpenStack as a potential platform we may see a lot of work around this in the next few development cycles.

Most agree that OpenStack itself doesn’t need to be built as HA.  The ability to use great tools like Pacemaker and Corosync, and other tools to protect shared services for OpenStack, we have good potential to design a more resilient cloud platform.  Building your scalable cloud will need some forethought. This is a good time to evaluate how you can use Pacemaker to keep the pulse of your OpenStack cloud strong.

 

Song of the Day – Nico and Vinz – Am I Wrong?

Categories OpenStack

1 Comment