Readme and Release notes for release 5.1.0.7 LoadLeveler 5.1.0.7 LL_scheduler-5.1.0.7-power-Linux-RHEL6 Readme

This installation procedure assumes that you are updating a machine running the full version of LoadLeveler.

License RPM

Do not proceed if the LoadL-full-license- < OS-ARCH > - < installed_license_version > license package is not installed. For example, if you are currently running LoadLeveler 4.1.x for Linux, you cannot install an update for LoadLeveler 5.1.x. You must first upgrade to LoadLeveler 5.1.0.3-0 before you can install an update package for a 5.1.0.X-0 release. Please contact your IBM marketing representative for information on how to obtain the appropriate LoadLeveler CD-ROM that has the license package.

When uninstalling the "LoadL- < fileset > -full" RPM currently installed on your machine, do not uninstall the "LoadL-full-license" RPM for your currently installed LoadLeveler release. The "LoadL- < fileset > -full" update RPM has a dependency on the currently installed license RPM. Also, the LoadLeveler daemons will not start unless the license package is installed and you have accepted the terms and conditions of the license agreement.

Submit-only machines

The update steps for a LoadLeveler submit-only machine are similar to those associated with a machine running the full product. Simply replace the relevant "full" file names by their "so" counterparts. Also, on a submit-only machine there is no need to execute the llctl drain, llctl stop, or llctl start commands because LoadLeveler daemons do not run on a submit-only machine.

File name conventions

Download packages and RPMs for LoadLeveler updates use consistent file naming conventions. By looking at the components of the file name, you can determine which update package you will need to download based on the machine's architecture, Linux operating system, and the installed version of LoadLeveler.

Example

Download package:

Package RPMs:

Currently installed LoadLeveler and License RPMs:

where

< fileset >

< OS-ARCH >

< update_version >

< arch >

< base_version >

< currently_installed_version >

< installed_license_version >

1. Change to the < UpdateDirectory > directory, that is, the directory where the *.tar.gz file for the LoadLeveler update resides and where you have write access:
   
   cd < UpdateDirectory >
2. Extract the RPM files from the tar file:
   
   tar -xzvf LL- < fileset > - < update_version > . < arch > . < OS-ARCH > .tar.gz
   
   At the end of this step the files extracted from the archive should match the files listed in the Readme ("View" link) for the LoadLeveler update you downloaded.
3. Verify that the LoadLeveler "license" RPM for the LoadLeveler version that you are updating is currently installed on this system:
   
   rpm -qa | grep LoadL
   
   The output of this command should be similar to the following:
   
   LoadL- < fileset > -full- < OS-ARCH > - < currently_installed_version >
   LoadL-full-license- < OS-ARCH > - < installed_license_version >
4. If LoadLeveler resource manager fileset is running on this machine, enter the following command to "drain" the LoadL_schedd and LoadL_startd daemons on this machine and all other machines in the LoadLeveler cluster:
   
   llctl -g drain
   
   Note: To avoid potential incompatibility problems, all machines in the cluster should be upgraded to the same LoadLeveler update release before restarting the LoadLeveler daemons.
5. Use the llstatus command to verify that the LoadL_schedd and LoadL_startd daemons are in "Drned" (drained) state, and then enter the following command to stop the LoadLeveler daemons:
   
   llctl -g stop
6. To apply the update, use one of the following options:
   
   OPTION 1
   
   Uninstall the currently installed "LoadL- < fileset > -full" RPM and then install the "LoadL- < fileset > -full" update package by running the following commands:
   
   rpm -e LoadL- < fileset > -full- < OS-ARCH > - < currently_installed_version >
   rpm -ivh LoadL- < fileset > -full- < OS-ARCH > - < update_version > . < arch > .rpm
   

   For Blue Gene/Q only:
   Run these additional commands:
   rpm -e LoadL-scheduler-bluegene- < OS-ARCH > - < currently_installed_version >
   rpm -ivh LoadL-scheduler-bluegene- < OS-ARCH > - < update_version > . < arch > .rpm
   
   
   
   
   OPTION 2
   
   Use the -U option of the rpm command to apply the update directly:
   
   rpm -Uvh LoadL- < fileset > -full- < OS-ARCH > - < update_version > . < arch > .rpm

   For Blue Gene/Q only:
   Run this additional command:
   rpm -Uvh LoadL-scheduler-bluegene- < OS-ARCH > - < update_version > . < arch > .rpm

7. Repeat step 6 for all the machines in the LoadLeveler cluster. On completion of this task, restart the LoadLeveler daemons with the following command:
   
   llctl -g start

For further information, consult the LoadLeveler Library for the appropriate version of the LoadLeveler Linux Installation Guide.

Control groups are used for preemption, process tracking, workload management (WLM), and checkpoint/restart. A control group file system must be configured and mounted in order to enable these functions. The /etc/cgconfig.conf file is used to define control groups, their attributes, and their mount points. On diskless systems the /etc/cgconfig.conf file should be part of the diskless image.

Complete the following steps to setup control groups on a diskless cluster.

1. Create the cgconfig.conf file in either an existing directory or a new directory in the /install/postscripts directory on the EMS management server.
   
   For example:
   mkdir -p /install/postscripts/admin_files
   vi /install/postscripts/admin_files/cgconfig.conf
   

   Note: Files and subdirectories under /install/postscripts on the EMS are copied to the /xcatpost directory on the compute nodes before the postscripts are run.

2. If you plan to use checkpoint/restart or LoadLeveler process tracking and preemption, the first entry in the cgconfig.conf file must be:
   
   mount {ns = /cgroup/freezer;freezer = /cgroup/freezer;}
   
   
3. If you plan to use WLM, include the following in the cgconfig.conf file:
   
   mount {
     cpu = /cgroup/cpu;
     cpuacct = /cgroup/cpuacct;
     memory = /cgroup/memory;
   }
   
   group LOADL {
     memory{
       memory.limit_in_bytes = ;
       memory.soft_limit_in_bytes = ;
       memory.memsw.limit_in_bytes = ;
    }
    cpu{}
    cpuacct{}
   }
   
   
4. In a script that is configured in the xCAT database as a postscript for the compute nodes, add the following:

   cp /xcatpost/admin_files/cgconfig.conf /etc/cgconfig.conf /sbin/cgconfigparser -l /etc/cgconfig.conf
   
   where "admin_files" is the directory name you used in step 1.
   
   If you plan to use scheduling affinity, add the following lines to this script after invoking /sbin/cgconfigparser
   
   mkdir /dev/cpuset
   mount -t cpuset none /dev/cpuset