The document discusses different deployment topologies for OpenStack high availability configurations. It describes the types of nodes in an OpenStack deployment including endpoint, controller, compute, and cinder volume nodes. It then examines several specific topology examples: one using a hardware load balancer with API services on compute nodes, another with a dedicated endpoint node and API services on controller nodes, and a third with simple controller redundancy and API services on controller nodes. Across all the examples, the key is distributing OpenStack services across nodes in a redundant and highly available manner.

1. Deployment topologies for High Availability
(HA) with OpenStack

2. Types of nodes
• OpenStack deployment needs to contain at
least three types of nodes
– Endpoint node
– Controller node
– Compute node
– Cinder-volume

3. • Endpoint node: This node runs load balancing and high availability
services that may include load-balancing software and clustering
applications. A dedicated load-balancing network appliance can
serve as an endpoint node. A cluster should have at least two
endpoint nodes configured for redundancy.
• Controller node: This node hosts communication services that
support operation of the whole cloud, including the queue server,
state database, Horizon dashboard, and possibly a monitoring
system. This node can optionally host the nova-scheduler service
and API servers load balanced by the endpoint node. At least two
controller nodes must exist in a cluster to provide redundancy. The
controller node and endpoint node can be combined in a single
physical server, but it will require changes in configuration of the
nova services to move them from ports utilized by the load
balancer.

4. • Compute node: This node hosts a hypervisor and
virtual instances, and provides compute resources to
them. The compute node can also serve as the network
controller for instances it hosts, if a multihost network
scheme is in use. It can also host non-demanding
internal OpenStack services, like scheduler, glance-api,
etc.
• Cinder Volume node: This is used if you want to use
the Cinder-volume service. This node hosts the cinder-
volume service and also serves as an iSCSI target.

5. • typically hosts the load-balancing software or
appliance providing even traffic distribution to
OpenStack components and high availability—the
controller and compute nodes can be set up in
many different ways, ranging from “fat”
controller nodes which host all the OpenStack
internal daemons
• compute nodes can take some of OpenStack’s
internal processing, by hosting API services and
scheduler instances.

6. Topology with a hardware load
balancer
• In this deployment variation, the hardware
load balancer appliance is used to provide a
connection endpoint to OpenStack services
• API servers, schedulers, and instances of nova-
scheduler are deployed on compute nodes
• glance-registry instances and Horizon are
deployed on controller nodes.

7. • All the native Nova components are stateless
web services; this allows you to scale them by
adding more instances to the pool
• we can safely distribute them across a farm of
compute nodes. The database and message
queue server can be deployed on both
controller nodes in a clustered fashion

9. Topology with a dedicated endpoint node
• In this deployment configuration, we replace a
hardware load balancer with an endpoint host
that provides traffic distribution to a farm of
services.
• Another major difference compared to the
previous architecture is the placement of API
services on controller nodes instead of compute
nodes.
• Essentially, controller nodes have become
“fatter” while compute nodes are “thinner.”

10. • Also, both controllers operate in
active/standby fashion.
• Controller node failure conditions can be
identified with tools such Pacemaker and
Corosync/Heartbeat

12. Topology with simple controller
redundancy
• In this deployment, endpoint nodes are
combined with controller nodes. API services and
nova-schedulers are also deployed on controller
nodes
• the controller can be scaled by adding nodes and
reconfiguring HAProxy.
• Two instances of HAProxy are deployed to assure
high availability, and detection of failures and
promotion of a given HAProxy from standby to
active can be done with tools such as Pacemaker
and Corosync/Heartbeat.

14. Many ways to distribute services