Final Part 3: Openstack TripleO Architecture and Step By Step Guide for installation of undercloud and overcloud nodes (compute, controller, ceph-storage)

Bring up undercloud director

Prepare Undercloud for overcloud deployment

You can also configure a cluster for more than one ceph-nodes

.

Phases of overcloud node deployment

Registration:

• The "stack" user uploads information about the proposed overcloud nodes
• The information includes credentials for power management
• The information is saved in the ironic database and used during the introspection phase.

Introspection:

• Ironic connects to the registered nodes to gather more details about the hardware resources.
• The discovery kernel and ramdisk images are used during this process.

Deployment:

• The "stack" user deploys the overcloud nodes, allocating resources and nodes that were discovered during the introspection phase.
• Hardware profiles and Heat templates are used during the phase.

Registering an overcloud node

This consists of adding it to an ironic list for the possible nodes for the overcloud. The undercloud needs the following information to register a node.

• The type of power  management being used (such as IPMI or PXE over SHH). The various power management drivers supported by iroic can be listed using "ironic driver -list".
• The node's IP address on the power management network.
• The credentials to be used for the power management interface.
• The MAC address for the NIC on the PXE/provisioning network.
• The kernel and ramdisk that will be used for introspection.

All of this information can be passed using a JSON file or using a CSV file. The "openstack baremetal import" command imports this file into the ironic database.

Configure Virtual Bare Metal Controller (VBMC)

The director can use virtual machines as nodes on a KVM host. It controls their power management through emulated IPMI devices. SInce we have a lab setup using KVM as my setup we will use VBMC to help register the nodes.

Since we are using virtual machines for our setup which does not has any iLO or similar utlity for power management we will use VBMC.

Enable the below repo on your "KVM Host" to get the vbmc package.

Create a virtual bare metal controller (BMC) for each virtual machine using the vbmc command.

To list the available domains

Next start all the virtual BMCs:

Check the status again

Now all our domains are in running state.

To get the list of supported drivers for IMPI connection

To check the power status of all our virtual hosts to make sure they are reachable from our undercloud.

Configuration Files

Create a JSON file describing your Overcloud baremetal nodes, call it "instack-threenodes.json" and place in your home directory. The file should contain a JSON object with the only field nodes containing list of node descriptions.

Each node description should contains required fields:

• pm_type - driver for Ironic nodes, see Ironic Hardware Types for details
• pm_addr - node BMC IP address (hypervisor address in case of virtual environment)
• pm_user, pm_password - node BMC credentials

These credentials will be used to control the power of the overcloud hypervisors.

Below is my input json file which I will use to import the nodes into the ironic database

Register Nodes

Register and configure nodes for your deployment with Ironic:

Introspection of overcloud nodes

For the introspection/discovery of overcloud nodes. Ironic uses PXE provided by the undercloud. The "dnsmasq" is used to provide DHCP and PXE capabilities to the ironic service. The PXE directory images are delivered over HTTP. Prior to introspection, the registered nodes have a valid kernel and ramdisk assigned to them and every node for introspection should have:

• Power State should be power off
• Provision State should be available
• Maintenance should be False
• Instance UUID likely set to None.

Use below command to make sure our nodes meet the above requirement

The "openstack baremetal introspection" command is used to start the introspection and "bulk start" can be used to proceed with introspection of all nodes. The two nodes that will be checked are the controller and compute nodes

Change the provision state of the nodes to "manageable"

Check the provisioning state

Run the following command to inspect the hardware attributes of individual nodes:

You can check the progress of the introspection using below comman from a different terminal

OR
You can monitor the console of the VM to check the progress of the introspection

To check the exit status of introspection

To get the disk related inventory from the introspection data

HINT: This data can be used to assign root disks if required.

Once the introspection is completed you can check the resources calculated by the nova at the introspection stage for all the 3 hypervisors

Flavor Details

The undercloud will have a number of default flavors created at install time. In most cases these flavors do not need to be modified, but they can be if desired. By default, all overcloud instances will be booted with the baremetal flavor, so all baremetal nodes must have at least as much memory, disk, and cpu as that flavor.

In addition, there are profile-specific flavors created which can be used with the profile-matching feature

Check the property of the ironic nodes

Modify your flavors to add the capabilities similar to as the ironic nodes

Check the properties filed of the flavors again which we plan to use with our ironic nodes

Tagging node into profiles

After registering and inspecting the hardware of each node, you will tag them into specific profiles. These profile tags match your nodes to flavors, and in turn the flavors are assigned to a deployment role. Default profile flavors compute, control, swift-storage, ceph-storage, and block-storage are created during Undercloud installation and are usable without modification in most environments.

Currently there is no profile assigned to any of the nodes

Make sure you modify the "properties/capabilities" as per your node's properties and add the profile

Once all the above commands are executed sucessfully, re-check the profile assignment. Here we see respective profiles are assigned to the nodes

Heat Templates

The director uses Heat Orchestration Templates (HOT) as a template format for its Overcloud deployment plan. Templates in HOT format are mostly expressed in YAML format. The purpose of a template is to define and create a stack, which is a collection of resources that Heat creates and the configuration per resources. Resources are objects in OpenStack and can include compute resources, network configuration, security groups, scaling rules, and custom resources.

The structure of a Heat template has three main sections:
Parameters - These are settings passed to Heat, which provides a way to customize a stack, and any default values for parameters without passed values. These are defined in the parameters section of a template.

Resources - These are the specific objects to create and configure as part of a stack. OpenStack contains a set of core resources that span across all components. These are defined in the resources section of a template.

Output - These are values passed from Heat after the stack's creation. You can access these values either through the Heat API or client tools. These are defined in the output section of a template.

Copy the default templates

The default mapping uses the root disk for Ceph Storage. However, most production environments use multiple separate disks for storage and partitions for journaling. In this situation, you define a storage map as part of the storage-environment.yaml file copied previously.

Edit the storage-environment.yaml file and add an additional section that contains the following:

This adds extra Hiera data to the Overcloud, which Puppet uses as custom parameters during configuration. Use the ceph::profile::params::osds parameter to map the relevant disks and journal partitions. For example, a Ceph node with four disks might have the following assignments:

/dev/vda - The root disk containing the Overcloud image
/dev/vdb - The disk containing the journal partitions. This is usually a solid state disk (SSD) to aid with system performance.
/dev/vdc - The OSD disks

Overcloud Deployment

After introspection the undercloud knows which nodes are used for the deployment of the overcloud, but it may not know what overcloud node types are to be deployed.

HINT: The entire deployment may take ~45-60 minutes

Below list explains the terminology used in the above command.

To check the status of overcloud deployment

To check the status of individual resource

To delete the existing overcloud stack and re-deploy

Below file will be created once the overcloud deployment is complete

Now you can login to your nodes from the undercloud

I hope the article was useful.

Please let me know your views and feedback in the comment section below.