The first and easiest way to scale an OpenStack cluster is to add compute power. One control node can support more than one compute node. Remember installing RDO in Chapter 1, RDO Installation? We have come a long way since then! In that example, only one compute node was installed. One control node can support a large collection of compute nodes. The exact number that can be handled depends on the demand put on the cluster by its end users. It is probably safe to say that the capacity provided by one compute node is probably not going to meet most use cases, so let's take a look at how to add additional compute nodes to our OpenStack installation.

There are only two OpenStack services, NTP, and the supporting networking infrastructure that a new compute node needs to be running for it to be joined into an OpenStack cluster and start sharing the computing workload. These two services are the Nova compute service and the Neutron Open vSwitch agent. In our example installation, the supporting networking infrastructure is Open vSwitch, so Open vSwitch is required in this example. The Ceilometer compute agent can also optionally be installed if the telemetry data is expected to be collected. As soon as the Nova and Neutron agents communicate with the control tier, the node will be available for new instances to be scheduled as long as everything is properly configured.

Enter the great configuration complexity of OpenStack. A configuration management engine will make this process much simpler. There are a handful of configuration management engines out there that have a vibrant community and an active investment in a set of maintained modules that can be used to install and configure OpenStack. In Chapter 1, RDO Installation, Triple-O was used to install the OpenStack overcloud. Under the hood, Triple-O uses the configuration management engine puppet to do the heavy lifting of installation and configuration. Triple-O offers the facility to make additions and modifications to the original deployment by reusing the original deployment command. Before we use Triple-O to add another node, let's see the compute node already associated with our OpenStack cluster and what its status is using OpenStack's hypervisor commands:

undercloud# source overcloudrc
undercloud# openstack hypervisor list
undercloud# openstack hypervisor show 1

This command will output a list of the hypervisors registered with OpenStack. Pass the hypervisor's ID to the show command and look for the state and uptime fields. These will indicate if the node is healthy or not. Next, let's go ahead and add a new compute node to the cluster.

If you remember the installation from Chapter 1, RDO Installation, a configuration file was passed to the Triple-O quickstart. This configuration file was populated with a list of nodes that could be used with a quickstart deployment. To add a second compute node, it is as simple as rerunning the overcloud deploy command and indicating to use the second compute node:

undercloud# source stackrc
undercloud# openstack overcloud deploy --control-scale 1 --compute-scale 2 --templates --libvirt-type qemu --ceph-storage-scale 1 -e /usr/share/openstack-tripleo-heat-templates/environments/storage-environment.yaml

Notice that compute-scale has been increased from 1 to 2. Triple-O will try to run puppet on both defined compute nodes. The puppet run on the existing compute node will net no new changes. The second compute node will be booted, configured, and joined to the overcloud. It is important to understand that when the quickstart.sh file created these virtual machines to represent the bare-metal nodes, it also created a definition file that was imported into the undercloud. This is the instackenv.json file that is in the stack user's home directory on the undercloud. Open this file and inspect it to see the same list of nodes that were originally added to the openstac_essentials.yml file, except with information that defines how to manage their power state. If you need to add additional nodes, for instance, if you are managing baremetal compute nodes, the process of running overcloud deployment is the same. Just increase the compute-scale, control-scale or ceph-scale parameter accordingly. The difference is that the new nodes need to be defined and imported into the undercloud the same way that the original instackenv.json file was imported in Chapter 1, RDO Installation. The new node definitions can be added directly to the original instackenv.json file and re-imported with the same command used in Chapter 1, RDO Installation. To see the list of available nodes for Triple-O to use, run OpenStack's baremetal command:

undercloud# openstack baremetal list

Nodes in this list will be in a provisioning state available and have no instance ID associated with them when they can be used to deploy new overcloud nodes to them. If there is an instance ID, the nodes are already allocated and cannot be used to add new nodes to the overcloud.

When the overcloud deploy running to add the second compute node finishes, look at the list of hypervisors again and you will see the second hypervisor joined into the overcloud:

undercloud# source overcloudrc
undercloud# openstack hypervisor list

This process can be repeated for more compute nodes as long as there are baremetal nodes available in the baremetal node list. As more nodes are added as compute nodes, the Nova scheduler will spawn instances across all the nodes according to its scheduling algorithm.