High Availability in the OpenStack Cloud

Openstack is based on a modular architectural design where services can be co-resident on a single host or, more commonly, on multiple hosts.

Before Discussing HA lets know in brief about the Openstack Architecture.

Openstack conceptual architecture:

openstack_havana_conceptual_arch

Q : With High Availability(HA) what we try to do ?

Ans : We try to minimize two things.

1. System downtime

This occurs when a user-facing service is unavailable beyond a specified maximum amount of time.

2. Data loss —

When the machine goes down abruptly there can be a loss of data ,Accidental deletion or Destruction of data.

Most high availability systems guarantee protection against system downtime and data loss only in the event of a single failure. However, they are also expected to protect against cascading failures, where a single failure deteriorates into a series of consequential failures.

The main aspect of high availability is the elimination of single points of failure (SPOFs). A SPOF is an individual piece of equipment or software which will cause system downtime or data loss if it fails. In order to eliminate SPOFs, check that mechanisms exist for redundancy of.

  1. Network components, such as switches and routers

  2. Applications and automatic service migration

  3. Storage components

  4. Facility services such as power, air conditioning, and fire protection

OpenStack currently satisfy HA requirements for its own infrastructure services. Means it does not guaranty the HA of the Guest VMs but its own Services.

Now Lets try to understand what are the Openstack Services are that needs to be Highly available.

1. Identity Service, i.e Keystone-API.

2. Messaging Service, RabbitMQ

3. Database Service, i.e MySql Serivce.

4. Image Service.i.e Glance-API.

5. Network Service,Newtron-API.

6. Compute Services ,Nova-API.

  1. Nova-API

  2. Nova-Conductor

  3. Nova-Scheduler

There two type of services here stateless and stateful.

A stateless service is one that provides a response after your request, and then requires no further attention. And the services are follows.

Keystone-api :

Keystone is an OpenStack project that provides Identity, Token, Catalog and Policy services for use specifically by projects in the OpenStack family. It implements OpenStack’s Identity API.

keystone

Glance-api :

Project Glance in OpenStack is the  Image Service which offers retrieval, storage, and metadata assignment for your images that you want to run in your OpenStack cloud. 

glance

Neutron-api :

Neutron is an OpenStack project to provide “networking as a service” between interface devices (e.g., vNICs) managed by other Openstack services

Nova-api :

vmwareapi_blockdiagram

Nova-Conductor : Nova-conductor is a RPC server. It is stateless, and is horizontally scalable, meaning that you can start as many instances on many servers as you want. Note that most of what nova-conductor does is doing database operations on behalf of compute nodes. The majority of the APIs are database proxy calls. Some are proxy calls to other RPC servers such as nova-api and nova-network.

The client side of the RPC call is inside nova-compute. For example, if there is a need to update certain state of a VM instance in nova-compute, instead of connecting to the database directly, make a RPC call to nova-conductor, which connects to the database and makes the actual db update.

Nova-Scheduler: Compute resource scheduling, it is the DRS for Openstack environment, people know DRS (Distributed Resource Scheduler)  in a VMware environment can understand its functionality if they understand what VMware DRS is.

nova-compute

Openstack stateful Services.

A stateful service is one where subsequent requests to the service depend on the results of the first request. Stateful services are more difficult to manage because a single action typically involves more than one request, so simply providing additional instances and load balancing will not solve the problem.

  • OpenStack Database 
  • Message Queue

The important thing to achieve HA is to make sure these services are redundant, and available,apart from these services some of networking services also needs to be highly available and for all these services how you achieve that is up to you.

In my next blog I ll write some of the common ways to achieve high availability on these openstack services.

3 thoughts on “High Availability in the OpenStack Cloud

    • panchaleswar says:

      VMware DRS :

      VMware vSphere Distributed Resource Scheduler (DRS) is a feature included in the vSphere.
      Using DRS, you can:

      1.Improve service levels by guaranteeing appropriate resources to virtual machines.
      2.Automatically migrate virtual machines during maintenance without service disruption.
      It does this by two ways
      1.Initally placing the VM ,when it starts,in the right ESXi Host based on the the capacity of the ESXi and the resource required for the VM.
      2.Can Migrate the VM by performing a vMotion to another ESXi Host while the VM is in running state so that the VM and the Cluster is balanced can run without resource constraint.

      Nova Scheduler :

      Where as the Nova Schedulers can do some functionality of the VMware DRS.
      Compute uses the nova-scheduler service to determine which host a VM should launch on.
      The term “host” in the context means a physical node that has a nova-compute service running on it.
      Still it does not have the capability to balance the resources by doing a live migration of a running VM to another Host.

      Hope this gives you more clarity.

      Like

Leave a reply to Ftancis M Cancel reply