User login
Learn how to use Qlustar!

QluMan Guide

Introduction

A Qlustar HPC cluster is designed to boot and manage compute or storage nodes (hosts) over the network and make them run a minimal OS (Operating System) image in RAM. Local disks (if present) are only used to preserve log files across boots and for temporary storage (e.g. for compute jobs). One or more head-nodes deliver the boot images to the nodes. Additionally, a small NFS share containing part of the configuration space for the nodes is exported from one of the head-nodes. Optionally, the RAM-based root FS (file-system) can be supplemented by a global NFS-exported chroot to support software not already contained in the boot images themselves. The head-node(s) of the cluster typically provides TFTP/PXE boot services, DHCP service, NIS service, torque or slurm resource management etc. to the cluster. The management of these and all cluster-related components of a Qlustar installation in general can easily be accomplished through a single administration interface: QluMan, the Qlustar Management interface.

The QluMan GUI is multi-user as well as multi-cluster capable: Different users are allowed to work simultaneously with the GUI. Changes made by one user are updated and visible in real-time in the windows opened by all the other users. On the other hand, it is possible to manage a virtually unlimited number of clusters within a single instance of the QluMan GUI at the same time. Each cluster is shown in a tab or in a separate main window.

Functionality Overview

A central part of Qlustar are its pre-configured modular OS images. Different nodes may have different hardware or need to provide specific and varying functionality/services. Therefore, to optimize the use of hardware resources and increase stability/security, Qlustar does not come with just one boot image that covers every use-case. Instead, a number of image modules with different software components are provided from which individual custom OS images can be created as needed. A Qlustar OS image just contains what is actually required to accomplish the tasks of a node, nothing more. See below for more details about configuring Qlustar OS images.

But providing different OS images is still not enough for a flexible yet easily manageable cluster: A node booting a generated image also receives extra configuration options via DHCP and via NFS at boot time, thus allowing to fine-tune the OS configuration at run-time. E.g. it is possible to determine how the local disks are to be used (if any are present), whether additional services like OpenSM or samba should be enabled/disabled and a lot more. Four different configuration/property categories exist in QluMan:

  • Generic Properties are simple on/off options or key+value pairs applicable to groups of nodes, e.g. to flag the reformatting of the local disks at the next boot, add torque node properties, etc.
  • Config Classes handle more complex configurations like boot/disk configs, DHCP, etc.
  • Hardware Properties are not used to configure the nodes themselves but describe their hardware configuration and are of importance e.g. for the slurm or torque resource managers and/or inventory management.
  • Finally, Specific Properties are properties that are unique to a particular node, like its serial number. Therefore, these properties can only be assigned to individual nodes.

Of course, one can configure every host in a cluster individually. But in most clusters, there are large groups of hosts that should be configured identically. However, even if there are several groups, they might share some properties/configurations but not all of them. To provide a simple handling of such scenarios, QluMan allows to combine generic properties, hardware properties and config classes each into sets. Moreover, it is possible to combine exactly one generic property, one hardware property and one config set into a Host Template. Assigning a Host Template to a group of hosts makes it possible to specify their complete properties and configuration settings with a single click. Nonetheless, for maximum flexibility, it is also allowed to override or extend the settings from the template of a host by assigning either one of the sets and/or individual properties/config classes to it. In case of conflicts, values from individual properties/config classes have highest priority followed by set values and finally the Host Template values. For more details on this see below.

Logging in

When starting qluman-qt, a login dialog appears, showing either the last used login information or (on the first start) the default parameters. Access to a cluster is specified by its hostname, a network port address (default 6001), a public key and a username (default admin) with its password (default admin).

The public key has been added in QluMan version 1.1.1. It is used for the encryption of the network traffic between the GUI and the server which employs high-speed/high-security elliptic-curve cryptography to protect every packet against espionage, corruption, and sabotage. You can find the correct key in the file /etc/qlustar/qluman/server-key.pub on the head-node. Be sure not to add spaces or other characters when copying and pasting the key, otherwise the connection will fail.

The default admin password should be changed immediately. To simplify managing multiple clusters, the current login data can be saved by providing a specifier and clicking the Save button. This will open a dialog asking for a name, the entry will be saved as. Note, that passwords will not be saved. Entering a previously used name will overwrite the corresponding entry, otherwise a new one will be created. If saved login data exists, it can be selected by its name via the dropdown menu. Entries can be removed by pressing the Delete button.

License Installation

To be able to configure your cluster with QluMan, a license key needs to be installed. Without a valid key, an error will be displayed upon start-up and the QluMan daemon will only allow read-only operations. In read-only mode, you can have a look at all the settings, but you can't change anything.

After closing the error dialog the License Key window can be opened by selecting File->License Key in the main Menu. If you never installed a license key before, the window will come up mostly empty.

To request a license key, click the Request Key button and a Key Info Dialog will open asking you for your name and address info. If you intend to use Qlustar Basic Edition, checkmark Free / non-profit license at the bottom of the dialog. Select OK to continue saving the key request in a file. Enter a file-name and save. You will now have to send an e-mail specifying the required number of nodes and features (see our order page) with this key file attached to order@q-leap.com.

After a while, you will receive a license key by mail that you can import using the Import Key button. If the import was successful, the license information will be displayed and you're ready to start working with QluMan.

After a successful license installation, you can move on to the interesting stuff. Upon start-up, the QluMan client automatically connects to the local QluMan daemon and opens the Enclosure View window.

Configuring Network Parameters

During the installation of Qlustar, the configuration parameters for the cluster network had to be entered and normally you won't need to change them. For the rare circumstances, where they do need to be changed, or in case you just want to verify the settings, you can select Manage Cluster->Network Config from the main windows menu. Note, that changing anything in this dialog involves a fundamental reconfiguration of the cluster setup, including rebooting the whole cluster. For this reason, changes in the Global Cluster Network Config do not take effect immediately after being changed in the dialog. They require a further confirmation by clicking the Save button, that will then actually commit the changes.

Configuring Ethernet

Changing the Ethernet network configuration is the most involved and requires several steps. In the Global Cluster Network Config there are 3 settings relevant for Ethernet: The Cluster Network IP address, the netmask and the cluster internal Head IP address. When changing the Cluster Network IP address or netmask, the IP addresses of all hosts configured in QluMan will be remapped to reflect their new values. This requires that the new netmask is large enough, so that the resulting network range can include all existing hosts in the cluster. Therefore, the GUI won't let you pick anything too small. If there are unused address ranges in your existing network and you need a smaller netmask than currently selectable, you will first have to change some host addresses so that all of them combined occupy a small enough subset of the current network.

Changing the network address IP will automatically remap the cluster internal Head IP address as well, while changing the netmask will not. Note, that the Qlustar convention, to use the second last IP of the cluster network as the Head IP, is obviously not a requirement. Hence, this is not done automatically when changing the netmask. Furthermore, changing the Head IP involves some additional steps without which the nodes in the cluster won't function or even boot. The point is that the Head IP also appears in the Global DHCP Template, NIS Host header and SSH Hosts / Known Hosts. These templates are simple, freely editable text blobs. A change of the Head IP in the Global Cluster Network Config will not change them, so you need to check and adjust each of them manually.

If the head-node does not have direct access to the Internet, a http proxy must be configured. Qluman uses this proxy to download packages from the Qlustar repository, when creating a new chroot. Click the checkmark before Http Proxy to enable proxy support and enter the hostname together with the port of the proxy. If the proxy requires authentication, click the checkmark before Authenticate and enter a username and password. Like usual, the new settings will only take affect, when you click the Save button.

Enclosure View

The Enclosure View shows an overview of the cluster in a tree structure. The tree structure is designed to reflect the physical structure of the cluster. At the lowest level are the hosts. A host can be a head, storage or compute node but also a switch e.g. In general, anything in the cluster that has a name, IP and MAC address is a host. A host is represented by its 'bare board' and should be placed into a host enclosure. 1U, 2U, 3U or 4U enclosures contain exactly one board, while others like a Twin or Blade chassis can have multiple boards. Once defined, host enclosures can be placed into racks, racks grouped into rows, rows into rooms and so on. The tree has a simple drag&drop interface. E.g. you can select a number of nodes (by holding the CTRL key and clicking or holding the shift key and dragging the mouse) and drag&drop them into a Blade enclosure.

Selecting a node in the tree displays its configuration info on the right hand side: The hostname, IP and MAC can be edited and saved by pressing <return>. The check-mark to the right of the field shows the state of the change. If the entered value is not valid, the check-box is cleared Unchecked checkbox. The check-boxes tool-tip (you'll see it when the mouse moves on top of it) gives the reason why the entered value is invalid. If the entered value is valid but has not yet been saved, the check-box is checked but ghosted Ghost-checked checkbox. Finally, after the value has been saved in the database, the check-box shows a solid check Checked checkbox.

For nodes that are not part of a multi-host enclosure (like a Blade or Twin chassis) the enclosure type can be changed to one of the single-slot host enclosures (1U, 2U, etc.). A new enclosure of the chosen type will then be created if the node is not already part of one. If a node is included in a multi-host enclosure, this field will be ghosted.

The template field allows to select a so-called Host Template for the node. Host Templates are a collection of exactly one "Generic Property Set", "Hardware Property Set" and "Config Set". Usually large groups of nodes have identical hardware and software configuration and will use the same template. Deviations from the template can be set for individual hosts by direct assignment of either a property set or individual property directly to the host. In case of unique properties direct assignment override settings from the template (or property set), for non-unique properties this is additive.

Note: Any changes made in the configuration only affects the active node (as indicated by the hostname in the info part of the enclosure view), and not all selected nodes. Configurations for all selected nodes can be made by using the context menu (right click) in the tree view.

Enclosures

Similar to host nodes, selecting an enclosure entry displays the physical layout of the corresponding enclosure on the right. Controls to select the visibility level and special slots are available at the top of the display. See below for more details about these. The name of the enclosure and its type (in brackets) is shown in the title. In the above case, both name and type are "Twin2". Below the title you have a representation of the physical layout of the enclosure. For this example, you see the 2x2 slots that are characteristic of a Twin2 enclosure. Two slots are filled with "beo-01" and "beo-02" and two slots remain empty, showing only the number of each slot in brackets.

Selecting a rack shows a more complex picture. The current example rack holds ten enclosures in its central 19 inch slots: A FatTwin, a Twin, a Twin2, a Blade 1, 3 Blade 2, another Twin2 and two 1U enclosures containing "beo-11" and "beo-12". The special top, left, right and bottom (not visible) slots are empty. In future versions a network switch or power controller, that is mounted at some special position of the rack, can be placed into these special slots.

Now let's explain the effect of the two controls at the top in more detail: The "Show special slots" check-box controls the visibility of the top, left, right and bottom special slots. Especially if these slots are empty, this will provide a more compact view of the interesting central slots. The other control, the visibility level, controls how many levels of the enclosure hierarchy are shown: Selecting a depth of 2 shows not only the selected rack with its slots but also the contents of the enclosures in each slot. Since the current version of QluMan only supports host enclosures (Twin, Blade, ...) and racks, a depth larger than 2 has no effect yet. In future versions, it will be possible to group racks into rows, rows into rooms, rooms into buildings and so on. This will allow you to reflect the physical layout of your cluster in as much detail as you like.

Populating Enclosures

New enclosures can be added through the context menu. The new enclosure must be given a name and its type can be selected. Currently, enclosure types cannot be manipulated yet. This will change in a future version.

Suitable for ordinary servers, a host being selected in the enclosure view can be placed into a single slot host enclosure directly by selecting the correct type in the host info part of the window (see above). For host enclosures that can hold more than one server/node (twin servers, blades etc.), drag&drop may be used to move hosts into them. Moreover, it's also possible to create larger (non-host) enclosures (like racks) and move host enclosures into them also by using using drag&drop. Note that a bare host cannot be placed directly into a non-host enclosure, only if it is already inside a host enclosure.

Another option to place hosts into enclosures is by selecting a number of them and then choosing a host enclosure from the context menu. This way, a new enclosure of the selected type is automatically created and all selected hosts are moved into it. If more hosts than can fit into a single enclosure of the chosen type are selected, additional enclosures of the same type will be created such that all hosts can be placed into one of them. This makes it easy to position large numbers of identical hosts into their enclosures. If the selected hosts were in an enclosure before and that enclosure becomes empty and is not itself part of a larger enclosure then the empty enclosure is automatically removed.

Relocating hosts by selecting a different host enclosure is supported not only on directly selected hosts but also on hosts inside selected enclosures. This allows changing the type of enclosure a group of hosts is in by selecting the old enclosure(s) and choosing a new one from the context menu. Note that this procedure does not change the type of the old enclosure but rather creates a new one, moves all the hosts to it and then deletes the now empty old enclosure(s). Try it out: Place a number of hosts into a large enclosure (like a blade), then select the enclosure and choose a small enclosure (like 1U) to relocate them. In general, such an operation will create one enclosure of the new type and fill all its slots before creating a second one. Hosts that where in different enclosures before can end up in the same enclosure after and hosts that were in the same enclosure before can end up in different enclosures after the operation.

When using drag&drop for the relocation, the host or enclosure is always placed into the lowest suitable slot of the target enclosure. This reflects our experience, that usually enclosures are simply filled from left to right and bottom to top. But sometimes this is not the case and a host or enclosure should be in a different slot as compared to the automatic placement. In this case, the host or enclosure can be moved through the context menu. The latter shows all the free slots the host or enclosure can be relocated to and a checked mark indicates the current location. Of course the relocation is only allowed into free slots. Hence, it may require removing (drag&drop out of the enclosure) a host or enclosure temporarily to free space for moving things around.

Selection

There are situations where one wants to change a property or config of a set of hosts. For example, you may want to change all nodes located in a particular blade to no longer format their disk on boot. This can be achieved by selecting a set of host in the enclosure view with the mouse. A range of hosts can be selected by clicking on the first host and then clicking on the last host while pressing the shift key. Hosts can also be added or removed from the selection by clicking on a host while pressing the ctrl key. Once a set of hosts is selected, changes can be made to all selected hosts through the context menu. For instance, this allows changing the Host Template or add/alter a generic property of a set of hosts.

An alternative and more powerful way to select a set of hosts is available via the Selection button at the bottom of the Enclosure View. At the top of the selection menu this brings up you'll find 3 items to select all hosts, clear the selection or to invert the selection. Below these items is a list of filters by which subsets of hosts were defined according to specific criteria. For more details on how to construct such host filters see below. When pressing Select, the selection is set to the hosts defined by the corresponding filter, dropping any previously selected hosts. Add to adds, while Remove from removes the hosts defined by the filter from the current selection. Intersection sets the selection to only those hosts in the current selection, that are also part of the set defined by the filter.

New Hosts

To add new hosts to the cluster you can either select "New Hosts" from the context menu in the Enclosure View tree or from the "Manage Hosts" menu. This opens the "Hosts Window".

Adding a new host requires the specification of an IP address, hostname and MAC in the corresponding three text fields of the dialog. The entered values are checked for their validity. If one of them is not valid, the check-box to its right remains cleared Unchecked checkbox. The tool-tip of the check-box will then show, why it is invalid. If all the values are valid, all check-boxes will show a solid check Checked checkbox and the "Add Host" button will become selectable. For convenience and if it makes sense, the IP address and the numeric part of the hostname (if there is one) will automatically be incremented by one, after a host was added. So in most cases, these fields will not have to be changed manually to add the next host. Only the new MAC will need to be entered.

To help adding new hosts, qlumand scans the DHCP log file for unknown hosts that have requested an IP address. For each unknown host found in the logs, the table at the top of the window shows the time of the first and last appearance in the log, its MAC address as well as the hardware vendor this MAC is assigned too (if known). Selecting a MAC in the table copies it into the MAC text field at the bottom and a double-click adds the host with the selected MAC. One can also select multiple lines (by holding the CTRL key and clicking or holding the shift key and dragging the mouse) and then click the "Add Selected" button at the bottom to add them all using the auto-increment feature for the IP address and hostname. If unsure, try adding a single host first and check the auto-increment does the right thing before adding a group of hosts. One easy way to add groups of hosts is to power them on one at a time with a short delay (say 30 seconds). The hosts will then appear in the Unknown MACs table in the order they were powered on and can be added as a group with the click of a single button.

At the bottom of the window a Host Template can be selected that will be used as the default for new hosts. Most of the time, no additional configuration is needed for a new host.

Configuring a Host

The configuration of a host consists of the definition and assignment of different types of properties and config classes. Properties are always a key + value pair and are further split into generic, hardware and specific properties.

Hardware Properties

Hardware properties are used to describe the hardware of a host. Amongst others, hardware properties like the amount of RAM or number of CPU cores are used to configure resource management systems like slurm or torque, so jobs can be assigned to the desired hosts. Others, like e.g. the server model or BIOS version, are purely informational and might be used for inventory management.

Generic Properties

A property that is not hardware related and not specific to a host is called generic. Generic properties can be configuration options, like 'OpenSM Host', or purely informational, like 'Paid by'. While hardware properties are meant to be more rigid typically with a configurable set of fixed values, generic properties are more flexible and can be defined at will. This will become more apparent in future versions of QluMan. Generic properties are also not necessarily unique, making it possible to assign multiple values for a single generic property. This is useful e.g. to add multiple torque host tags or to put hosts in multiple groups for dsh/pdsh (via the 'Host tag').

Specific Properties

As the name suggests, specific properties are specific to a single host. The best example for such a property is the serial number of the host.

Property/Config Sets

Individual generic properties, hardware properties and config classes can be used to define generic property sets, hardware property sets and config sets. This is simply a means of grouping them together so they can be used as a single entity. A Host Template can then be created by choosing one generic property set, one hardware property set and one config set.

Host Templates

When a correct Host Template exists, a host can be configured by selecting the desired template in the Enclosure View window. For a single host, this can be done by selecting it in the tree view. This brings up the host information on the left and the template can be selected from the drop-down menu. To configure multiple hosts, you would select them in the tree view and choose a Host Template from the context menu. The check-marks in the sub-menu indicate which Host Templates are currently assigned (if any) for the selected nodes. This action will override the previous assignment.

Generic properties can also be assigned to a host individually. Such assigned properties take precedence over ones of the same type selected through the Host Template. This is useful when a property should be changed temporarily for some hosts or when a property should not be changeable globally through the Host Template. Note that by default, every new host has the generic property "Schedule Format: always", which is required to format the disk on the first boot. This should be removed after the first successful boot of the host so that log files will be preserved across boots in the future.

Config Classes

Config Classes manage configurations that are too complex to fit into the key + value scheme used by properties. Therefore, there is no common interface to configure all classes. Instead each class has its own configuration dialog presenting the specific options it provides. Furthermore, some classes depend on sub-classes (e.g. "Boot Configs" depend on "Qlustar Images"). Only the top-level config classes can be assigned to a host template. Sub-classes are assigned indirectly via their parent class. Most of the functional subsystems of Qlustar have a dedicated config class. Currently there are four of them: "Boot Configs", "DHCP Configs", "Disk Configs" and "Slurm Configs" with sub-classes "Qlustar Images" and "UnionFS Groups".

Writing Config Files

The configurations managed via config classes and sub-classes in the QluMan GUI are translated into automatically generated configuration files on the head-node(s). While QluMan configuration options are usually saved in the QluMan database immediately after they have been entered in the GUI, the write process of the real configuration files on disk is a separate step that needs to be specifically initiated and confirmed.

Each configuration dialog of a config class has a "Preview" and "Write" button for its own config files. Additionally, there is also a dedicated dialog for writing and previewing all configuration files. You can access it from Manage Cluster->Write Files or the Write Files button at the bottom of the main window. If a config class has no pending changes, the Preview button becomes a View button and the Write button becomes ghosted. The Preview window shows both, the new version of the config file that will be written, as well as a context diff of the changes compared to the current file on disk (if there are any differences). If a config class changes only one file, the file will be shown directly. If multiple files are involved, there will be one tab for each file.

Checking the optional Force button will initiate a rewrite of all config files, even if they haven't changed. Note also, that the actual write command is performed via the Remote Execution Engine. This allows for consistent management of multiple head-nodes e.g. in a high-availability configuration.

Since the QluMan GUI is multi-user capable, it can happen that another user changes something, while you have the Preview Dialog open. In this case, the Refresh button at the bottom of the dialog becomes unghosted and the Write button becomes ghosted. This prevents the accidental writing of changes that haven't been audited yet.

Boot Configs

The "Boot Config" dialog allows to define settings for the PXE/tftp boot server. A boot configuration determines which Qlustar OS image is delivered to a node and optionally permits the specification of PXELinux commands and/or Linux kernel parameters. When opened, the "Boot Config" window shows a list of all boot configs currently defined sorted by their names. Note that the default config is special in the sense that it applies to any node that has no specific boot config assigned (either through a template or directly) to itself. This means that in the simplest configuration (all nodes should boot identically), it is sufficient to just have the "default" boot config without any specific assignment. By expanding a boot config item, the configured Qlustar image, PXELinux command and kernel parameters become visible. You can change any of the values by simply selecting a different option from the drop-down menus. In case of kernel parameters, you can also directly edit the entry and save the result by pressing <return>. Furthermore, it is possible to add more kernel parameters or remove them through the context menu.

The context menu also lets you create new boot configs as well as edit or delete an existing one. Alternatively a new boot config can be created by clicking the "New" button at the bottom of the dialog. Both the context menu and the button bring up the "New Boot Config" dialog. Simply enter the name for the new config, select a Qlustar image and (optionally) a PXELinux command, enter a description and press "OK" to create it. The new config then appears in the Boot Config window and is ready for use. Note that additional kernel parameters can not be added in the "New Boot Config" dialog or when editing an entry. This is only allowed via the context menu, once the mouse is over the boot config to be changed.

DHCP Config

The DHCP config dialog allows the configuration of the DHCP server and is provide by the main menu Manage Configs->DHCP Configs. The final DHCP server configuration file on disk is assembled from the header which defines global settings and the host part which contains the MAC/IP address and hostname of all the hosts registered with QluMan. The header can freely be edited in the "Global DHCP Template" part of the dialog. An initial version of it is created during installation and in most cases doesn't need to be changed. It contains many important parameters required for the cluster to function properly. Please consult the documentation of the DHCP server and the dhcpd.conf man page for the syntax of this file.

To prevent multiple persons from editing at the same time and overwriting each others changes accidentally you must acquire a lock for the template by clicking the Edit button. If another user is already editing the file the button will be ghosted and the tool tip will show which user is holding a lock for the template.

After having finished editing a template don't forget to save your changes by clicking the "Save" button. It will be ghosted, if there is nothing to save. You can undo all your changes up to the last time the template was saved by clicking the "Undo" button. In case another admin has made changes to a template while you are viewing or editing it, the "Refresh" button will become enabled. By clicking it, the updated template is shown and you loose any unsaved changes you have already made in your own edit field. To delete a template click the "Delete" button, but note that the "Global Template" can not be deleted, since it is needed for the DHCP server to function correctly.

The template lock expires automatically after some time without activity so that the template is not deadlocked if someone forgets to release the lock. In such a case the above dialog will be shown notifying you about it. By selecting OK a new lock will be requested. If another user is editing the template at that time though the request will fail and an error dialog will inform you of the failure.

DHCP options can also be set in separate group templates and targeted to specific hosts. For simple clusters, this is hardly ever needed, but for large clusters e.g. you might want to have more than one boot server to speed up cluster boot time. In this case you could assign different groups of hosts to different boot servers using this method. The defined group templates are available as configs to be added to config sets or hosts directly. You can select a group template from the drop-down menu at the bottom to view or edit it. As an example 2 templates specifying different boot-servers are included.

The drop-down menu also lets you create new templates by selecting the <new DHCP group> entry. Enter the name of the template in the text field and fill in the contents and description of the template. Pressing return after entering the name will automatically acquire a lock for the new template and go into edit mode. You can then enter the contents of the new template. Don't forget to click the Save button at the end.

When you are satisfied with your changes, you can preview the resulting dhcpd.conf file together with a diff to the old version on disk by clicking the Preview button. The changes will only take full effect when you click the Write button. This will also tell the DHCP server to reload its configuration. The same can also be done through the main menus Manage Cluster->Write Files entry or the Write Files button at the bottom of the cluster window and then selecting Preview or Write button in the DHCP Configs row.

Disk Configs

Qlustar has a powerful mechanism to manage the configuration of disks on a node. This mechanism is partly based on the setup_storage module of FAI. It basically allows for any automatic setup of your hard drives including kernel software RAID (md) and LVM setups. A detailed description of the syntax for disk configurations is available. Since the OS of a Qlustar node is always running from RAM, a disk-less configuration is obviously also possible. Note, that for flawless operation this requires some extra configuration (handling of log messages and in/output of batch jobs) that will be explained in the Qlustar admin guide. Valid configurations require definitions for two filesystems /var and /scratch as well as swap space (see examples). To permit the initial formatting of a new disk configuration on a node, it must have assigned the "Schedule Format: always" generic property during the initial boot (see the discussion above).

Disk configurations can be managed using the "Disk Configs" dialog accessible from the main menu Manage Configs->Disk Configs. You can select the config to be viewed/edited from the drop-down menu at the bottom left. A couple of example configurations are created during the installation. Note that there are two special configs: (a) "disk-less" (not editable or deletable) and (b) "default" (editable but not deletable). The default config is used for any node that doesn't have a specific assignment to a disk config (via a Host Template, config set). The configuration itself can be edited in the text field at the top of the dialog and should conform to setup_storage syntax (see above). New configs can be created by choosing <new disk config> from the drop-down menu. As usual, enter the name of the new config in the text field and fill in the contents and description.

Slurm Config

The slurm configuration module comes in three parts:

  • The overall slurm configuration being controlled through two templates in the Config Header tab.
  • The configuration of slurm nodes done via the Node Groups tab.
  • The configuration of partitions achieved using the Partitions tab.

Assignment of hosts to node groups and/or partitions is possible by adding the latter to the relevant Config Sets and Host Templates or by direct assignment through the generic property context menu.

Slurm Config Header

The overall slurm configuration is split into two templates, the slurm config and cgroups.conf. On write, QluMan adds the NodeName and PartitionName lines at the end of the slurm config template to generate the slurm.conf file, while the cgroup.conf file gets written as is. For the syntax of both templates, please refer to the slurm documentation (e.g. man slurm.conf). To edit one of the templates, select it, click the Edit button and start making changes. Click Save to save the changes or Undo to discard them. Use the Preview button to check changes before writing them.

Slurm Node Groups

Slurm node properties are configured from two sources:

  • The Hardware Properties assigned to a host. The number of CPUs, sockets, cores and the size of its main memory is taken from there.
  • The second source are the slurm node groups. Every host can belong to at most one such group. The membership is defined (see below) by adding the desired group to the Config Set that is assigned to the node via its Host Template. Each Node Group is a collection of slurm node properties, that will be set for the members of the group. Per default, only the MemSpecLimit property is defined, but other properties like Feature or Gres can be added by using the node property editor.

A new node group can be created by clicking the New Node Group button or selecting New Node Group from the context menu. This opens a dialog asking for the name of the new group. An existing node group can be renamed or deleted from the context menu.

The context menu also allows to add properties to a group. Note, that some properties are unique, i.e. only one value can be selected for the property. Adding a second value of the same property will automatically replace the old value in that case. Other properties are not unique. Adding multiple values to such properties results in a comma separated list of values in the slurm.conf file. An example for this is the Feature property. Properties can also be changed directly using the pull-down menu. If a change will cause a duplicate value, the previous (duplicate) value is automatically removed.

Slurm Partitions

The creation of Slurm partitions works exactly the same way as with slurm node groups. Please see above for how to create, rename and change partitions.

Slurm Property Editor

The Slurm property editor for node or partition properties can be opened by clicking the Properties button at the bottom of the Slurm main dialog. If the Node Groups tab is selected, the editor for node properties will be opened. If the Partitions tab is selected, the editor for partition properties will be opened.

To add a new property, enter the name of the property in the name field. If the name does not already exist, the New Property button will be enabled. Click on it to create the property. QluMan has a white-list of known valid properties, e.g. Gres and allows adding such a property without further questions. In this case, QluMan will also set the unique flag and add all known property values automatically.

When a property is created that is not on the white-list (Gris in the screenshot) a dialog opens up, asking for confirmation. Note that adding an unknown property can lead to a failure when trying to restart slurm. Therefore make sure to only add properties you are certain slurm will know about. A property without values can be deleted by clicking the Delete button.

To add values to a property, first select the desired property using the pull-down menu from the name. Then enter the new property using Add Value at the bottom and press return to add it. To delete a value, select Delete value from the context menu.

Assigning Hosts to Slurm Node Groups and Partitions

Host are assigned to Slurm Node Groups and Partitions by use of a Host Template and its corresponding Config Set. A Config Set may contain at most one Node Group but any number of Partitions, since a host can be member of an arbitrary number of slurm partitions. Both can be added by selecting them via Add Config in the context menu of the Config Set.

Other Configs

Qlustar OS Images

Qlustar OS images can be defined and configured in the "Qlustar Images" dialog accessible via Manage Configs->Qlustar Images. Each image has a unique name, a flavor (currently only "precise"), a version, a UnionFS chroot and one or more image modules.

Image Versioning

Currently available image versions are 9, 9.0 (both meta-versions) and 9.0.0. Note, that selecting meta-versions has implications on the update process. They allow tracking the newest x.y (x.y.z) releases automatically. Example: If you have installed version 9 of the modules, you will currently get the 9.0 (most recent 9.y) versions, but when 9.1 will be available, apt-get dist-upgrade will update to 9.1 versions automatically. So with this choice, updates will usually include larger changes, since new feature releases (like 9.1) will automatically be installed. Similar, if you have selected the 9.0 version (currently default after a fresh installation) you will currently get 9.0.0 (most recent 9.0.z version) and apt-get dist-upgrade will update the modules/images to 9.0.1 automatically once available. So this choice will update to new maintenance releases automatically. The most conservative choice would be to explicitly select a x.y.z version (currently 9.0.0), since then images will only receive bug fix updates without explicitly changing the version in Qlustar. See also the discussion in the general Qlustar Update Guide.

Image Properties

A couple of images are pre-defined during the installation process. The dialog shows the images sorted by their names. Expanding an entry shows its configuration and allows to select a UnionFS chroot via the drop-down menu. Each image must contain at least the core module. Additional modules can be added or removed using the context menu when hovering over an entry. Only modules that are not already chosen are available for selection.

New images can be added through the context menu or by pressing the "New" button at the bottom of the dialog. Like before, you should then enter the name for the new config, choose a UnionFS group and optionally provide a description for the new image. Existing images can be removed via the context menu.

NIS hosts

NIS (network information system) is used to manage hostname resolution within the cluster. For all hosts that are managed within QluMan itself, a corresponding NIS entry is created automatically. However, administrators might want to add other hosts external to the cluster to the NIS database as well. To achieve this, the creation of the NIS hosts database is split into a header part that can be freely edited by the admin, and a part that is auto-created with the hosts managed by QluMan. To edit the header part, choose Manage Configs->NIS Host Header from the main menu. The top part of the window popping up can then freely be edited. Note that entries for the head-node are automatically created upon installation and should remain unchanged unless one of the head-nodes IP changes. The resulting NIS hosts file can then be previewed and written to disk by pressing the corresponding dialogs at the bottom of the dialog. Upon writing the file, the NIS database is automatically rebuilt on the NIS master server.

SSH host files

To simplify ssh remote logins to cluster nodes, three ssh configuration files are provided and managed by QluMan: (a) ssh_known_hosts (holds ssh host keys of cluster nodes), (b) shosts.equiv (enables login without password between machines within the cluster) and (c) authorized_keys, which is used to allow password-less root login to nodes with the specified ssh public keys. The first two config files consist of a configurable header part, where additional hosts can freely be entered and an auto-generated part for the hosts managed by QluMan. The last one just has the configurable part. Ssh host info for the head-node and a possibly configured frontend-node are automatically inserted during the installation process.

Management of the three configs is similar to the NIS hosts dialog: To edit the header part of either config, select Manage Configs->SSH Configs from the main menu. Then choose the config to work on by using the drop-down menu at the bottom left. The top part of the window popping up can then freely be edited. Finally, the resulting ssh host files can be previewed and written to disk by pressing the corresponding dialogs at the bottom of the dialog. Note: There is no preview of the authorized_keys file, as this is automatically written during the boot phase on hosts, that are not head-nodes.

UnionFS Chroots

In most practical cases, a Qlustar image should be configured with an associated UnionFS chroot. Exceptions are single purpose images e.g. for Lustre servers. By design, images are stripped down to the functionality (programs) that is most often needed on a compute/storage node. This keeps them small while still providing fast, network-independent access to programs/files typically used.

To complement the image and provide the full richness of the packages/programs available in the chosen Linux distribution, the UnionFS chroot (holding a full installation of e.g. Ubuntu) is exported via NFS by one of the head-nodes and technically merged below the content of the Qlustar OS image. In practice, this means that all files belonging to the chroot will be available on the nodes configured to use it, but if a file/program is also in the node's image, that one will be used. Hence, this method combines the compactness and speed of the imaging approach with the completeness of a full OS installation to give you the best of all worlds.

The chroot associated with a Qlustar image is easily selectable as explained above. Management of the chroots themselves is possible via the Manage Chroots dialog which is accessible via the main menu Manage Cluster>Manage Chroots. It provides a number of actions related to chroots. Manipulation of the contents of chroots is explained elsewhere.

To specify a chroot to operate on, select it via the corresponding pull-down menu. This will show its description, as well as its properties like the NFS server that hosts it, the filesystem path on the server, the flavor (edge platform, precise/wheezy/...) and the version of the Qlustar feature release (always being of the form x.y, e.g 8.1).

When generating a new chroot, a name for the chroot must be specified and optionally a description of its purpose. Furthermore, you can select an NFS server where the chroot will be located (currently only one option), a flavor (aka edge platform) and Qlustar version. Finally you have the possibility to select Qlustar tasks. These are topic package bundles, each consisting of a collection of packages relevant to a certain field of HPC applications. Pressing the OK button then starts the generation of the chroot. You can follow the rather lengthy process (count a couple of minutes) in its own window.

Cloning an existing chroot is mostly useful when you want to test an upgrade to a new release or for other tests. Pressing the Clone button opens a sub-window in which you can specify the name of the new cloned chroot and optionally a description of its purpose. Pressing the OK button then starts the cloning process. You can again watch it in its own window. Editing a chroot let's you edit it's description.

Removal of a chroot by pressing the Remove button first asks you for a final confirmation. If you then press the Delete button, the chroot will be removed provided it is not still in use by a Qlustar image. If it is still in use, a list of images that are associated with the chroot is given. You would then first have to reconfigure these images to use another chroot before trying to remove again. Renaming of a chroot is not supported directly. To rename you'd have to clone the original chroot giving the clone the new desired name and afterwards remove the old chroot.

Infiniband network

For most practical purposes, Infiniband (IB) adapters need to be configured with an IP address (IPoIB) just like Ethernet adapters. If you have chosen to configure an IB network during installation, this section is mostly about how to review or change the initial settings. If not, IB first has to be activated in the Global Cluster Network Config dialog. An IB Network address IP and netmask can then be chosen. The Infiniband network must not collide with the Cluster (Ethernet) or IPMI network. This is prevented automatically in the settings dialog. The Infiniband IP of each host is computed by mapping the host part of its Cluster Network IP to the IB Network. Example: IP Cluster Network 192.168.52.100 - IP IB network 192.168.53.100. Note, that this mechanism requires the IB netmask to be at least as large as the Cluster Network netmask. Hence, smaller values won't be selectable.

To actually have a node's IB adapter be configured during the boot process, additional steps are necessary. It is not uncommon, that a cluster consists of hosts with IB and hosts without. Therefore, the pre-defined hardware property IB Adapter with a value of true must be assigned to a host, to explicitly enable IB for it. This is done most conveniently, by adding this property to the Hardware Property Set(s) used in the Host Template(s) for nodes with IB. If this assignment exists, Infiniband modules will be loaded and IP-over-IB will be configured during the boot process of the corresponding nodes with the IP mapping described above.

Activating/configuring OpenSM

In an IB fabric, at least one node (or switch) has to run a subnet manager to manage the routing tables. Qlustar provides OpenSM for this task. If the head-node is also part of the IB network, it's usually best to configure it to run OpenSM. This might have been chosen during installation, in which case there is nothing more to be done. If not, you have the option to run OpenSM on ordinary nodes too. In this case, it is advisable to run OpenSM on two or three nodes (not more) for redundancy reasons. It is therefore best, to configure this directly for the chosen hosts, rather than using a Host Template or generic property set. After selecting the host or hosts where OpenSM should run in the Enclosure View, open the context menu and select Set Generic Property->OpenSM Ports->ALL. The next time the hosts boots, the OpenSM daemon will be started on all its Infiniband ports.

If a host has more than one IB port, OpenSM can also be configured to run only on a specific port instead of all of them. The port can be specified by its number or by its unique ID. As this is an uncommon configuration and the unique ID is unknown beforehand, there is no preset value for this. To create a new value, first select an existing value, e.g. ALL, for the generic property OpenSM Ports. You can then edit the value in the Generic Properties box of a host. Editing the line and pressing return will create the new value. Beware that this will only affect one shown host. To assign the new value to other hosts, select them and then change the OpenSM Ports property through the context menu.

In some circumstances it might be necessary to run OpenSM with extra options. This can also be configured via generic properties. The only preset value is the empty string, so you need to create a new value for the options you require. First add the empty value of the generic property OpenSM Options to one host. Edit the value to your requirements and press return to create it. Finally add/change the OpenSM Options generic property to all relevant hosts.

IPMI settings

Configuring IPMI is similar to Infiniband and also involves multiple steps, because there are a number of options to set. If you have chosen to configure an IPMI network during installation, a larger part of this section is about how to review or change the initial settings. If not, IPMI first has to be activated in the Global Cluster Network Config dialog. There you can set the IPMI Network address IP and netmask. The IPMI address of a host is then determined with the same mapping as with IB and the same restrictions for the choice of netmask apply.

Often not all nodes in a cluster have IPMI. Therefore, in QluMan per default no host is configured to setup IPMI, unless it is assigned the hardware property IPMI Adapter with a value of true. The easiest way to achieve this, is to add the IPMI Adapter property to the Hardware Property Set(s) used in the Host Template(s) for the nodes with IPMI. With this assignment, a node is ready for monitoring its temperature and fan speeds.

Enabling IPMI nodes for remote control involves two more settings. The first one is the generic property Initialize IPMI. Per default the settings of the IPMI cards are not touched by Qlustar. However, while the Initialize IPMI generic property is assigned and set to true, the IPMI card settings of the corresponding host will be reset every time it boots. Changing the value of this property to true and after booting back to false allows a one-time setup of the cards properties.

The second generic property is the IPMI Channel to use. Per default channel 1 is used and this is the only preset value for the property. If you need to use a different channel, first add the generic property IPMI Channel to the Generic Property Set (or to a host directly) and then edit the value.

RXEngine / Remote Execution Engine

Overview

QluMan provides a powerful remote command execution engine, that allows to run shell commands on any number of hosts in parallel and analyze their output/status in real-time. Commands fall into two categories: Pre-defined commands and custom commands.

  • The command can be a single command or a series of commands in shell syntax.
  • The hosts are specified in Hostlist format or through a filter, so that even large groups can be represented by a short string.
  • The commands run in parallel on all hosts.
  • The network connection used for remote execution is both encrypted and authenticated. It employs the same high-speed/high-security elliptic-curve cryptography that is used for the connection between the QluMan server and the QluMan GUI.
  • The output is analyzed and updated in short intervals during the execution phase.
  • Hosts with equal output are grouped together to reduce the noise.
  • The output can further be filtered by the return code of the command and by (de)selecting stdout and/or stderr.

Executing a pre-defined command

Pre-Defined commands can be created using the Command Editor (see below for details). To execute a pre-defined command, open the pull-down menu of the Execute button at the bottom of the Enclosure View and select an entry. This opens a new Command Execution window for pre-defined commands. At the very top of it, the selected pre-defined command is shown. It can be changed if required. Below that is a list of arguments, the selected command accepts. "Execute on" is always present showing where the command will be executed. If defined, additional arguments of the command are displayed underneath. Further below, the final command is shown, with its arguments inserted at the right places. The command will be executed upon clicking the Execute button.

Arguments to a pre-defined command can be set fixed to a Host filter, in which case the filter and its resulting hostlist are shown as plain text and can not be edited. Optionally, specification of arguments in Hostlist format may also be left up to the user. In that case, a combo-box is shown, followed by the evaluation of the specified input shown as plain text. When hosts were selected in the Enclosure View, the combo-box will contain the hostlist corresponding to the selection as default. The text can be edited directly or a filter can be chosen from the dropdown menu. Any argument starting with "%" is assumed to be a filter. If this is not intended, the "%" must be escaped by another "%", but only at the start of an argument. For more details about specifying arguments in pre-defined commands see below.

Executing a custom command

To execute a custom command, open the pull-down menu of the Execute button at the bottom of the Enclosure View and select custom command from the menu. This opens a new blank Command Execution window. Note: The initial hostlist is empty in the screenshot examples, since no hosts where selected in the Enclosure View.

In case hosts were selected in the Enclosure View before clicking the Execute button, a hostlist representing these hosts will be present in the Command Execution window. This allows easy selection of hosts to run a command on via the Enclosure View or through the selection mechanism. The hostlist can also be updated at a later time from the currently selected hosts in the Enclosure View by clicking the Update button. This makes it simple, to run the same command on different sets of hosts. When a command is executed, it is added to the history and can be accessed again later through the pull-down menu. This allows rerunning recently used commands without having to retype them every time. Note, that the history is stored in the users home directory, hence every user has his own. The preferred way to manage frequently used commands is by pre-defining them (explained below).

Running Commands / Interpreting their Output

Once the hostlist is added, a command can simply be run by entering it in the command box and hitting the Execute button. It will then start to run in parallel on all listed hosts and the command output will be collected. Periodically, in short but increasing intervals, the output will be sorted and displayed. Hence, for short running programs you will see it immediately. Due to the increasing display intervals, long running and noisy commands won't cause constant flickering of the output, allowing you to more easily follow it.

Command State

After the Execute button has been pressed, all hosts will start in the Pending state. Once a host confirms that it has started its command, it will change to the Running state. When the command concludes, the state becomes one of Failed, Errors or Success. If the command exited with a return code other than 0, the host will enter the Failed state. If the command exited with a return code of 0, but produced output on stderr, it will enter the Errors state. Otherwise, it enters the Success state.

In the screenshot example, the hosts sn-1 and sn-2 were down, so they remained in the Pending state. By clicking the Pending button, a hostlist of the pending hosts is displayed. The QluMan server will start the command on those hosts, when they become online again. If you do not want that to happen, or if the command does not terminate on its own, then the Kill button allows you to stop the command. A killed command counts as failed, so sn-1 and sn-2 now enter that state. The command output also reflects that the command was killed.

Hosts and Groups

Hosts executing a command are not only grouped by their execution state, the command output produced by the different hosts is also analyzed and compared to each other. Hosts with identical output are put into a group. Their output is only displayed once, prefixed with the hostlist representing the hosts in each group. For a quick overview, the number of hosts and groups is also displayed below each state button. In the screenshot example, two hosts (sn-1 and sn-2) have failed, because they where offline and the command was killed before starting. The output of both was identical, so they form one group. Similar, one host (ql-head-pr-t) completed the command successfully and builds its own group.

The S buttons next to the numbers add or remove the hosts in each state to form a new hostlist. Press the button to include the corresponding hosts and press it once more to exclude them again. This is convenient, e.g. to quickly select only the hosts for which a command failed: Analyze the errors and later relaunch with an adjusted command. Another example: Select only the successful hosts to run a follow-up command etc.

Filtering by stdout and stderr

Commands usually output regular text to stdout and warnings as well as errors to stderr. In the latter case, the command ends up in the Errors state, because this is usually something that needs further inspection. The screenshot example prints two lines, one to stderr and one to stdout. Unfortunately Unix does not enforce any order between output to stdout and stderr. Therefore, as in this example, it can happen, that a small delay between the command output and reading from the file descriptors causes the order to slightly change.

Some commands produce a lot of output. Error messages are then easily overseen in between the lines. Similarly a command might report a lot of harmless errors, that hide the interesting output going to stdout. To simplify an analysis of the command output for such cases, the two buttons stdout and stderr at the bottom of the window allow toggling the visibility of stdout and stderr output selectively on and off.

Passing input to a command

Sometimes it is necessary to pass some input to a command. This can be done by clicking the Input button near the top. Another text box will then be added to the window and will allow to specify, what should be passed to stdin of the command on each host.

Command Syntax

Commands will be interpreted/executed by the BASH shell on every host matching the hostlist. The full BASH syntax is supported. Redirection of output to files, as in the last example, and working with variables works as expected. Please refer to the BASH documentation (e.g. man bash) for more details.

Command Editor

The command editor shows all the pre-defined commands in a tree view on the left. A number of useful commands are already defined by default. Selecting a command shows its definition on the right-hand side, where it can also be edited. Every command has a unique name/alias under which it appears in the tree view on the left, the execute menu in the Enclosure View and in the drop down menu of the pre-defined commands execution window. In the future, it will also be possible to limit commands to specific user roles, but for now all commands are unrestricted. A user either has rights to execute any pre-defined commands or none. Below the role selector, the command itself is defined.

Sorting commands

Commands are kept in a tree structure, grouping similar commands together. They can be sorted freely using the context menu to make frequently used commands easier to select. The Move Up and Move Down menu items move a command or group up or down within the group respectively. The Move to group sub-menu allows moving a command up or down in the tree hierarchy. Groups can be created, renamed and deleted to give any desired hierarchy of commands.

Defining or editing a command

To define a new command, select New Command from the context menu. The new command will be created in the group, where the context menu was opened or in the root, if the mouse is outside of any group. Initially, the command will have no definitions.

To edit a command, it needs to be selected first. Then its definitions will be shown on the right-hand side. The name/alias of a command can be edited by clicking in the text box at the top and entering the new name. The check-box to the right of the name indicates, whether your name is valid. Press enter, to save the new name and the check-box will become fully checked again. To undo editing, simply reselect the command in the tree view.

A command can be executed on any host or set of hosts in the cluster. The Execute on field governs how that host or set of hosts is constructed. The default is <User input>. This means, the user will have to choose the hostlist, where the command will run, at the time, when it will be executed. Alternatively, the hostlist of the command can be preset by selecting one of the filters from the dropdown menu. If a filter is selected, the hostlist, it currently evaluates to, is displayed below it.

Editing the command itself may take a while. To avoid conflicts from concurrent editing attempts by different QluMan users, only one person can edit a command at a time. To start the editing process, click the Edit button at the bottom. After that, changes to the command can be entered. Commands will be interpreted/executed by the BASH shell on every host matching the hostlist. The full BASH syntax is supported. Redirection of output to files and working with variables works as expected. Please refer to the BASH documentation (e.g. man bash) for more details. There is one exception to this: A "%" character followed by a number specifies additional arguments for the command, as explained in more detail below.

Sometimes it is necessary, to pass some input to a pre-defined command. This can be done by clicking the Input check-box. It will bring up an input text-box, where the desired input text can be entered.

To finish editing the command, click the Save button at the bottom. This actually saves the command text and input, if any, in the database and releases the lock on the command. This also scans the command text for argument placeholders and updates the entries in the Arguments box.

The definition of command arguments use the same mechanism as detailed for the Execute on definition. They can either be left up to the user to fill in, when the command is executed or be specified by a filter selectable from the dropdown menu. When executed, the %<num> placeholders in the command text are replaced by the user specified arguments or the resulting hostlist of the filter. There are always as many arguments as there are placeholders in the command. To add an argument, edit the command text and add a placeholder there. To remove an argument, edit the command text and remove the placeholder.

In the screenshot example, the test command is defined to execute on all head-nodes ("qlu-dev" is the only head node in the cluster). It has some input and two extra arguments. The first one is fixed to a Hostname filter, that evaluates to any host starting with "beo". The second one is left for the user to be specified, hence, when executing the command, only the second argument is editable. In the screenshot, the ONLINE filter was chosen for this argument, but any other text would have been possible too. For easy verification, the command text, with all the arguments substituted, is shown together with the command input (if defined). Note that in the example, the specified input is simply output by the cat command, so in the output shown, it appears between the two echo commands.

Host Filter Editor

Host filters define a set of hosts by specifying any number of criteria. The set of hosts defined by a filter is dynamic: Changes made to the properties of hosts are automatically reflected in the hostlist a filter evaluates to. Every time a filter is used, the criteria defining it are evaluated from scratch. Hence, host filters provide a powerful tool to classify hosts into groups, in a way that will dynamically take into account changes made to the cluster. They can be used in various ways within QluMan:

  • In pre-defined commands, to either specify, the set of hosts, where a command should be executed or to supply the resulting hostlist as an argument to the command.
  • As user input for pre-defined or custom commands.
  • In the Enclosure View to modify the selection.

The filter editor window is split into two areas. At the top the definition of the currently selected filter is shown. You can select the filter to be displayed from the dropdown menu. At the bottom the hosts that pass all the filters are displayed in the compact HostList format. This format is used by a number of other programs including pdsh and SLURM (the pdsh Wiki has a detailed discussion on the syntax).

Creating a new Filter

Select <new filter> from the dropdown menu to start defining a new filter. Then add filters from the context menu, until the desired subset of hosts is displayed in the bottom half of the window. Using their context menu, filters can be edited or removed and sub-filters be added. The Reset filter menu item clears the filter, so one can start from scratch. To finally create (save) the new filter click Save as and enter a name for it.

Editing a Filter

Editing a filter is similar to creating a new one. First select the filter from the dropdown menu to display it's current definition. Then add, edit or remove individual filters as desired. Finally click Save as to save the altered filter, Using an existing name will replace the old filter. Using a different name will create a new filter.

Types of Filters

A filter can be added from the context menu (right mouse click) in the top area. For a host to show up in the filtered list (bottom part), it must pass all the filters added. Each filter narrows down the list. Any number of filters can be added and they do not have to be unique. For example you can add a Hostname filter that selects all hosts that begin with "beo" and a Host Template filter that selects all "Demo VM" nodes. A host has to pass all top-level filters to show up. Currently, QluMan provides six top-level filters: Hostname, HostTemplate, Enclosure, HEADNODE, HEADNODES and ONLINE. Additional ones will be added in future versions.

Hostname Filter

Adding a Hostname filter opens up a pop-up dialog asking for the hostname or a regular expression to filter for. The input must be a regular expression in python syntax and is matched against the beginning of the hostname. If a match against the full hostname is desired then "$" should be added at the end. A ".*" can be added to the front, to match anywhere in the hostname instead of matching against the beginning.

Multiple hostname patterns can be added to a Hostname filter through the context menu. Note that this is additive: If a host matches at least one pattern, it will be included in the resulting list.

Host Template Filter

Adding a Host Template filter does not pop up a dialog. Instead it adds an empty Host Template filter. This simply selects all hosts with an assigned Host Template. Hosts that do not have a Host Template will not pass this filter. The filter can be made more specific by adding Host Template patterns to it through the context menu. This opens up a pop-up dialog, from where an existing Host Template name can be selected.

The result is a list of hosts, for which the associated Host Template matches the given pattern. Adding multiple Host Template names is again additive, just like with Hostname patterns.

Enclosure Filter

Adding an Enclosure filter also does not bring up a dialog. Like a Host Template filter, it selects all hosts that are part of an enclosure. Unlike the Hostname and Host Template filters though, an Enclosure filter allows for two different specifications: The name and the type of an enclosure can be matched. Just like Hostname and Host Template filters the Enclosure filter is additive. Adding sub-filters for both the Enclosure name and the Enclosure type will filter hosts that match at least one of those criteria. To filter for hosts that match both, an Enclosure name and an Enclosure type two separate Enclosure filters have to be used, to get the intersection of both filters. The first one to filter the name and the second to filter the type.

Inverting a Filter

Every filter, sub-filter and pattern can be inverted through the context menu. The context menu for a pattern contains menu entries for both the pattern and the enclosing filter separated by a line. The first "Invert" entry will invert the specific pattern that was selected, while the second "Invert" will invert the whole filter.

Besides the obvious, this can also be useful in finding hosts that are not configured correctly. For example, adding an empty Host Template filter and inverting it, will show all hosts without a Host Template. Adding a second filter, that selects all switches, power controllers and other special devices (they usually don't need a Host Template) and also inverting that, results in a list of all hosts, that are neither properly configured nodes (missing Host Template) nor special devices.

Additive versus subtractive

When constructing a filter, it is important to remember, that all top-level filters are subtractive. A host must pass all top-level filters to show up in the result. On the other hand, all patterns and sub-filters are additive. Matching any one of them within a top-level filter adds the host to the result of that filter. Hence, when subtractive behavior is desired for patterns or sub-filters, each pattern or sub-filter must be added to its own top-level filter. For example, to select all hosts that start with "beo" as well as end on "1" two Hostname filters have to be added.

QluMan User and Rights Management

QluMan is multi-user capable and provides an interface to configure and control users as well as their permissions when they work with QluMan. The QluMan users are not connected to system users in any way. To simplify permission management, the concept of user roles can be used. User roles allow to predefine a collection of permissions for QluMan operations. Once defined, they can be assigned to a user.

Managing QluMan Users

The admin user is pre-defined and has the admin role, meaning all possible rights. Roles for the admin user can not be changed, just like the root user in a Linux system always has all rights. When running QluMan for the first time, you should set the right email address for the admin user and then change its password. There are two ways to change the password.

The first one, using the Change password button, brings up the Change Password dialog asking for the old password and then twice the new password. When the new password matches the confirmation and is not too trivial, the OK button becomes unghosted and the password can be changed. The second one, using the Reset password button, first asks you whether you really want to reset the password. If you confirm, qlumand is notified to change the password to a random string and mail it to the users email address. Use this method, if the old password is not known or when resetting the password for another user.

To create a new user, select <new user> from the drop-down menu for users. Then edit the user name, fill out the remaining fields and click Save to create the user. The new user is created without a password (not an empty one), so initially, he can't log in and also has no assigned roles. Hence, the next step is to change or reset its password. With the new password, the user can then log in and look at the cluster properties/configs. However, without assigned roles, he will have no rights to change anything. You may assign the admin role to the user, giving him the same access rights as the admin user. Or you could define more restrictive roles and assign some of them to him. The next chapter explains how to create new roles. Don't forget to click the Save button after changing the roles assignment to actually activate them.

Managing User Roles/Permissions

The QluMan server performs many individual rights checks, before it allows/performs an operation. Many of those correspond directly to a specific window in the GUI, giving the user the right to alter settings in that window. For example, the right to configure UnionFS groups corresponds directly to operations available from the UnionFS Groups window under Manage Configs->UnionFS Groups. Others govern the right to specific actions or to alter specific properties. For example, the right to configure OpenSM on hosts enables the user to add, alter or delete the OpenSM Ports and OpenSM Options property of hosts in the Enclosure View.

The rights are grouped into 4 categories: Admin rights covers rights with global impact and root access to nodes, Booting covers all settings that affect how nodes will boot, Services covers the configuration of daemons and Host Config covers the general configuration of hosts.

Creating and editing roles is simple. Click New to create a new role, fill in a name and description for it and click OK. To change the rights associated with a role, first select it using the dropdown menu at the top. Next click the checkmark boxes to the left of the rights you want to change, grant or remove from the role. Click Save to save the changes or Undo to reset the rights to the last saved settings.

Customizing the Look&Feel

There are three aspects of QluMan's appearance that can be customized: Fonts, colors and widget style. Since QluMan is a QT application, it's Look&Feel can be controlled with KDE tools. Select the Manage Cluster->Preferences menu entry to bring up the KDE "System Settings" dialog. Now click on the "Application Appearance" icon and you'll have the options to modify fonts, colors and style.

Fonts

When you click on the "Fonts" icon, you'll see a list of different font identifiers for which you can change the font settings. The relevant identifiers to be adjusted for QluMan are "General", "Menu" and "Window Title". Changing one of the values and clicking the "Apply" button changes the corresponding font on the fly.

Colors

Click on the "Colors" icon and choose the "Colors" tab. There you can adjust the color of the different elements of the QluMan GUI. You can narrow down the color identifiers to the ones affecting particular GUI elements by choosing a specific color set with the corresponding pull-down menu. Changing one of the values and clicking the "Apply" button changes the corresponding color on the fly.

Manual

If you're using KDE4 on you're desktop, instead of configuring using the "System Settings" dialog, you can also move /root/.kde/share/config to /root/.kde/share/config.bak and copy your personal configured .kde/share/config directory to /root/.kde/share. As long as you're not using any non-standard KDE themes, this should just apply the favorite desktop settings you're familiar with to QluMan (restart of QluMan GUI required).

Widget Style

Changing the widget style can be a little more involved. First you need to start the QT configurator and choose a GUI style (default is QtCurve).

ssh -X root@servername qtconfig

When you're done, select File->Save and you'll already see the changes. After this you can exit qtconfig. If you want further customization of the widget style (note that only some styles are configurable, among them QtCurve), you can now go back to the "Application Appearance" Dialog (see above), click on the "Style" icon, choose the style you've selected in qtconfig as "Widget style" and press the "Configure..." button. You'll see a large number of options for customization. When you're satisfied with your modifications, press the "OK" button and finally the "Apply" button of the "Style - System Settings" window. Note, that you will see the resulting changes only after performing some actions (pressing a button, etc.) in the QluMan GUI.

To have more options for changing the widget style from the default of QtCurve, you can install additional kde-style packages (.e.g kde-style-oxygen) on the head-node.

glqxz9283 sfy39587stf02 mnesdcuix8
sfy39587stf03
sfy39587p08