Advanced cluster management made easy

Node Provisioning

The provisioning of software images to slave nodes is a key task of any cluster management software stack. Powerful and flexible node provisioning and software image management are essential to cluster installation and management, especially for larger and more complex clusters.

Capabilities

The sophisticated node provisioning and image management system in Bright Cluster Manager™ allows you to do the following:

• Install individual nodes or complete clusters from bare metal within minutes.
• Create, manage and use as many slave node images as required.
• Create, manage and use images that are very different (for example, based on different Linux kernels or distributions).
• Create or change images substantially without breaking compatibility with application software.
• Assign images to individual slave nodes or groups of slave nodes with a single command or mouse click.
• Make changes to slave node images on the head node, without having to login to slave nodes.
• Synchronize a slave node image on the head node from a hard disk on a slave node.
• Apply RPM package commands to slave images, manually or automatically (for example, using YumThe Yellowdog Updater, Modified (YUM) is an open-source command-line package-management utility for RPM-compatible Linux operating systems and has been released under the GNU General Public License).
• Update images incrementally, only transferring changes to the slave nodes.
• Update images live, without having to reboot slave nodes.
• Configure how disks should be partitioned (optionally using software RAIDRedundant Array of Independent Disks (RAID) is a way of arranging multiple hard disk drives into arrays for redundancy. and/or LVMLVM is a Logical Volume Manager for the Linux kernel; it manages disk drives and similar mass-storage devices, in particular large ones. The term "volume" refers to a disk drive or partition thereof. ).
• Protect disks or disk partitions from being overwritten.
• Provision images to memory and run slave nodes diskless.
• Keep track of changes to slave node images.
• Return to a previously stored slave node image if and when required.
• Backup all slave node images by backing up only the head node.
• Automatically update BIOS images or change BIOS configurations without keyboard or console access to the slave nodes.

Bright Cluster Manager Advanced Edition supports multiple, load-balancing provisioning nodes that can share load and take over from each other in case of hardware failure. This screenshot shows the status of four provisioning nodes and the nodes they are currently provisioning.

Bright Cluster Manager Advanced Edition supports multiple, load-balancing provisioning nodes that can share load and take over from each other in case of hardware failure.

Bright Cluster Manager Advanced Edition allows you to also do all the above on very large clusters, by using multiple, load-balanced provisioning nodes that can share load and take over from each other in case of hardware failure.

The Role of the Cluster Management Daemon, GUI and Shell

The cluster management daemon (CMDaemon) plays a central role in the coordination of the node provisioning process. It ensures that all required information is available to the master, provisioning and other slave nodes, and that all required steps are taken in the correct order. It also takes corrective action if something goes wrong in the provisioning process.

All commands for initiating related actions or modifying configuration information can be issued through the cluster management GUI or the cluster management shell.

Boot Phases

Four phases can be distinguished during the boot process of a slave node:

1. First Phase — Upon booting, a node retrieves its IP address and the preboot execution environment from the head node, using PXEPreboot Execution Environment. A slave node can be configured to skip this part, for example if it should boot independently from the head node.
2. Second Phase — The preboot execution environment checks with the head node which image needs to be provisioned to the slave node. The appropriate kernel and ramdisk are loaded from the head node and executed on the slave node.
3. Third Phase — The node starts up the node installation environment which is responsible for partitioning the local hard drive (if present), creating the file systems and transferring the software image onto these file systems. If the correct file systems are already present, only the differences between the software image and the contents of the local file systems will be transferred. The node installation environment is also responsible for bringing up network interfaces and configuring BMCs.
4. Fourth Phase — The node continues the booting procedure by switching to the local hard drive using the 'pivot-root' mechanism. By doing a 'pivot-root' the root file system is switched from the installer to the local disk without having to reboot the node.
5. Fifth Phase — The 'init' process is invoked, which is responsible for starting system services through the corresponding init scripts.