Designing for Cloud Controllers and Cloud Management


OpenStack is designed to be massively horizontally scalable, which allows all services to be distributed widely. However, to simplify this guide, we have decided to discuss services of a more central nature, using the concept of a cloud controller. A cloud controller is just a conceptual simplification. In the real world, you design an architecture for your cloud controller that enables high availability so that if any node fails, another can take over the required tasks. In reality, cloud controller tasks are spread out across more than a single node.

The cloud controller provides the central management system for OpenStack deployments.Typically, the cloud controller manages authentication and sends messaging to all the systems through a message queue.

For many deployments, the cloud controller is a single node. However, to have high availability, you have to take a few considerations into account

The cloud controller manages the following services for the cloud:


 Tracks current information about users and instances, for example, in a database,typically one database instance managed per service

Message queue services

 All AMQP—Advanced Message Queue Protocol—messages for services are received and sent according to the queue broker

Conductor services

 Proxy requests to a database

Authentication and authorization for identity management

Indicates which users can do what actions on certain cloud resources; quota

management is spread out among services, however

Image-management services

Stores and serves images with metadata on each, for launching in the cloud

Scheduling services

Indicates which resources to use first; for example, spreading out where instances are launched based on an algorithm

User dashboard

Provides a web-based frontend for users to consume OpenStack cloud services

API endpoints

Offers each service’s REST API access, where the API endpoint catalog is managed by the Identity Service . For our example, the cloud controller has a collection of nova-* components that represent the global state of the cloud; talks to services such as authentication; maintains information about the cloud in a database; communicates to all compute nodes and storage workers through a queue; and provides API access. Each service running on a designated cloud controller may be broken out into separate nodes for scalability or availability.

As another example, you could use pairs of servers for a collective cloud controller—one active, one standby—for redundant nodes providing a given set of related services, such as:

Frontend web for API requests, the scheduler for choosing which compute node to boot an instance on, Identity services, and the dashboard

  • Database and message queue server (such as MySQL, RabbitMQ)
  • Image Service for the image management
Next articlePricing Patterns in Public Cloud