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
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
Stores and serves images with metadata on each, for launching in the cloud
Indicates which resources to use first; for example, spreading out where instances are launched based on an algorithm
Provides a web-based frontend for users to consume OpenStack cloud services
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