TripleO Architecture¶

TripleO¶

TripleO is the friendly name for “OpenStack on OpenStack”. It is an official OpenStack project with the goal of allowing you to deploy and manage a production cloud onto bare metal hardware using a subset of existing OpenStack components.

With TripleO, you start by creating an “undercloud” (a deployment cloud) that will contain the necessary OpenStack components to deploy and manage an “overcloud” (a workload cloud). The overcloud is the deployed solution and can represent a cloud for any purpose (e.g. production, staging, test, etc).

TripleO leverages several existing core components of OpenStack including Nova, Ironic, Neutron, Heat, Glance and Ceilometer to deploy OpenStack on baremetal hardware. Nova and Ironic are used in the undercloud to manage baremetal instances that comprise the infrastructure for the overcloud. Neutron is utilized to provide a networking environment in which to deploy the overcloud, machine images are stored in Glance, and Ceilometer collects metrics about your overcloud.

The following diagram illustrates a physical view of how the undercloud may be hosted on one physical server and the overcloud distributed across many physical servers.

SpinalStack’s Inspiration¶

Some key aspects of SpinalStack workflow have been incorporated into TripleO, providing options to perform introspection, benchmarking and role matching of your hardware prior to deploying OpenStack.

Hardware introspection features enable you to collect data about the properties of your hardware prior to deployment, such that specific classes of hardware may be matched to specific roles (e.g. a special hardware configuration for Compute or Storage roles). There is also the option to enable performance benchmarking during this phase, such that outliers which do not match the expected performance profile may be excluded from the deployment.

TripleO also configures servers in a similar way to SpinalStack, using stable community puppet implementations, applied in a series of steps, such that granular control and validation of the deployment is possible

Environment Preparation¶

In the first place, you need to check that your environment is ready. TripleO can deploy OpenStack into baremetal as well as virtual environments. You need to make sure that your environment satisfies minimum requirements for given environment type and that networking is correctly set up.

Next step is to install the undercloud. We install undercloud using Instack’s script and it calls puppet scripts in the background. Upstream TripleO developers also use the developer-based steps known as devtest.

Undercloud Data Preparation¶

Nodes¶

Deploying the overcloud requires suitable hardware. The first task is to register the available hardware with Ironic, OpenStack’s equivalent of a hypervisor for managing baremetal servers. Users can define the hardware attributes (such as number of CPUs, RAM, disk) manually or he can leave the fields out and run introspection of the nodes afterwards.

The sequence of events is pictured below:

• The user, via the command-line tools, or through direct API calls, registers the power management credentials for a node with Ironic.
• The user then instructs Ironic to reboot the node.
• Because the node is new, and not already fully registered, there are no specific PXE-boot instructions for it. In that case, the default action is to boot into an introspection ramdisk
• The introspection ramdisk probes the hardware on the node and gathers facts, including the number of CPU cores, the local disk size and the amount of RAM.
• The ramdisk posts the facts to the ironic-inspector API.
• All facts are passed and stored in the Ironic database.
• There can be performed advanced role matching via the ”ahc-match” tool, which simply adds an additional role categorization to Ironic based on introspected node facts and specified conditions.

Deployment Planning¶

Whole part of planning your deployment is based on concept of overcloud roles. A role brings together following things:

• An image; the software to be installed on a node
• A flavor; the size of node suited to the role
• A size; number of instances which should be deployed having given role
• A set of heat templates; instructions on how to configure the node for its task

In the case of the “Compute” role:

• the image must contain all the required software to boot an OS and then run the KVM hypervisor and the Nova compute service
• the flavor (at least for a deployment which isn’t a simple proof of concept), should specify that the machine has enough CPU capacity and RAM to host several VMs concurrently
• the Heat templates will take care of ensuring that the Nova service is correctly configured on each node when it first boots.

Currently, the roles in TripleO are very prescriptive, and in particular individual services cannot easily be scaled independently of the Controller role (other than storage nodes). More flexibility in this regard is planned in a future release.

Customizable things during deployment planning are:

• Number of nodes for each role
• Service parameters configuration
• Network configuration (NIC configuration options, isolated vs. single overlay)
• Ceph rbd backend options and defaults
• Ways to pass in extra configuration, e.g site-specific customizations

Deployment¶

Deployment to physical servers happens through a collaboration of Heat, Nova, Neutron, Glance and Ironic.

The Heat templates and environments are served to Heat which will orchestrate the whole deployment and it will create a stack. Stack is Heat’s own term for the applications that it creates. The overcloud, in Heat terms, is a particularly complex instance of a stack.

In order for the stack to be deployed, Heat makes successive calls to Nova, OpenStack’s compute service controller. Nova depends upon Ironic, which, as described above has acquired an inventory of introspected hardware by this stage in the process.

At this point, Nova flavors may act as a constraint, influencing the range of machines which may be picked for deployment by the Nova scheduler. For each request to deploy a new node with a specific role, Nova filters the list of available nodes, ensuring that the selected nodes meet the hardware requirements.

Once the target node has been selected, Ironic does the actual provisioning of the node, Ironic retrieves the OS image associated with the role from Glance, causes the node to boot a deployment ramdisk and then, in the typical case, exports the node’s local disk over iSCSI so that the disk can be partitioned and the have the OS image written onto it by the Ironic Conductor.

See Ironic’s Understanding Baremetal Deployment for further details.

Per-node Setup¶

TBD - Puppet

Monitoring the Overcloud¶

When the overcloud is deployed, Ceilometer can be configured to track a set of OS metrics for each node (system load, CPU utilization, swap usage etc.)

Additionally, Ironic exports IPMI metrics for nodes, which can also be stored in Ceilometer. This enables checks on hardware state such as fan operation/failure and internal chassis temperatures.

The metrics which Ceilometer gathers can be queried for Ceilometer’s REST API, or by using the command line client.

Scaling-out the Overcloud¶

The process of scaling out the overcloud by adding new nodes involves these stages:

• Making sure you have enough nodes to deploy on (or register new nodes as described in the “Undercloud Data Preparation” section above).
• Calling Heat to update the stack which will apply the set of changes to the overcloud.