Planning and Installation Guide


Setting Up IBM Cluster Systems Management for Linux

The planning and installation process described in this guide helps a system administrator to get IBM Cluster Systems Management for Linux (CSM), hereafter known as Cluster Systems Management, up and running easily by setting up a management server and managed nodes either on existing Linux systems or by doing a full installation of the Linux operating system and CSM on the nodes of the cluster (not the management server, which must be set up first).

The application is available as an installation image in a directory or on the CSM CD-ROM. This document describes the minimum hardware and software requirements needed to use this product. See the Specified Operating Environment.

Information is also provided about planning and pre-installation tasks that you need to perform so that the installation will go smoothly and easily. Next, there is a step-by-step procedure for installing and setting up the cluster either on an existing group of nodes (CSM-only installation) or for a full installation of both the operating system and CSM (Kickstart installation). Finally, a troubleshooting section is provided in the form of frequently asked questions. You should read this document carefully and be familiar with it throughout before beginning the installation and set-up tasks.


Specified Operating Environment

This section describes the minimum hardware and software that are required for the Cluster Systems Management specified operating environment. For more detailed information, see the announcement.

Hardware Requirements

This product is supported on the IBM e(logo)server Cluster 1300 Model 7080 Primary Rack, 7080 Expansion Rack, 7081, and 7082.

Memory and Disk Space

For the management server, a minimum of 128MB of memory and 120MB of disk space is required for installing CSM, and an additional 1.5GB is required for a full installation.

For the managed node, a minimum of 128MB of memory and 20MB of disk space is required for CSM and the appropriate amount of additional disk space for the operating system and RPMS that you choose to install.

Network Requirements

TCP/IP and an Ethernet adapter

Network Considerations

In configuring a Cluster Systems Management cluster, give particular attention to the following:

Remote Control Hardware Requirements

To support remote control, the following hardware is required:

Note:
The total number of nodes should be less than or equal to the number of ports associated with all of the Equinox Serial Providers that are installed.
For more details, see IBM Cluster Systems Management for Linux Remote Control Guide and Reference.

Limitations

A cluster of up to 128 nodes is supported.

Software Requirements

IBM Cluster Systems Management for Linux has requirements for non-IBM software as well as IBM-developed software. As a convenience, the required non-IBM software that is not part of the Red Hat distribution is included on the CSM CD-ROM. Unless otherwise specified, the software is required on the management server and on the managed nodes.

CSM File Sets

The following file sets comprise the IBM Cluster Systems Management for Linux product:

  1. csm.client (This is required on the managed nodes only.)
  2. csm.core
  3. csm.server (This is required on the management server only.)
  4. csm.dsh
  5. rsct.core
  6. rsct.core.utils
  7. src

Required non-IBM Software

The Red Hat Linux 7.1 distribution is required. The Red Hat 7.1 distribution includes the following required non-IBM software:

  1. Expect 5.31-53 (on management server only)
  2. dhcp 2.0 (on management server only)
  3. glibc 2.2
  4. libstdc++ 2.9
  5. pdksh 5.0
  6. Pidentd 3.0
  7. perl 5.00503
  8. make 3.7
  9. nfs-utils 0.1 (on management server only)

In addition, IBM provides the following required non-IBM software:

  1. atftp 0.3
  2. cfengine 1.6.2
  3. DBD-CSV 0.1024
  4. DBI 1.14
  5. fping 2.2.b.1
  6. SQL-Statement 0.1016
  7. SYSlinux 1.53
  8. Text-CSV_XS 0.21
Note:
The minimum configuration and sizing of each node is highly dependent on the user's application and performance requirements.

Compatibility with General Parallel File System

It is mandatory that the CSM client RPM be installed either on all of the General Parallel File System for Linux (GPFS) nodes or on none of them. The Resource Monitoring and Control (RMC) subsystem requires that the definitions of its resource classes be the same on all nodes within the GPFS cluster. If the CSM client RPM is installed on only some of the GPFS nodes, some of the RMC daemons will not be able to join their peer group successfully, an undesirable situation. The CSM management server node should not be part of the GPFS cluster because it adds other resource classes to RMC, and it is not practical or desirable to install the CSM server RPM on all of the GPFS nodes.

GPFS and CSM should be using the same level of RSCT code. The current release of RSCT is Version 2.2.


Planning for Cluster Systems Management

This section describes the tasks that you need to perform before installing this product. Before you do anything else, ensure that the required IBM software is installed.

Read IBM Cluster Systems Management for Linux Remote Control Guide and Reference before beginning the installation process. IBM Cluster Systems Management for Linux Remote Control Guide and Reference contains illustrated information on hardware and networking set up and configuration, including the default installation values; for example, eth0, which is the value for the first Ethernet adapter that is connected to the cluster VLAN. It also provides a sample completed node-attribute table that you can use for guidance in completing your own blank template. A blank template is provided in Appendix A, Node Attributes Template for your convenience.

Pre-installation tasks

There are several tasks that the administrator must do to prepare for installation of Cluster Systems Management:

  1. For authentication and authorization of RMC requests, CSM software components require that any reference to an IP address or short hostname of any CSM management server or managed node be consistently resolvable by DNS or /etc/hosts to its canonical fully-qualified domain name (FQDN), which is normally the long version of the hostname. Two specific cases are considered:
  2. Some system administrators may choose to make /usr/local available to CSM cluster nodes as a read-only NFS mounted file system. When CSM is installed on the management server and the nodes, cfengine gets installed in /usr/local. If /usr/local is NFS mounted read-only, the installation of cfengine will be unsuccessful. If this is the case, choose one of the following two methods to avoid this problem:
  3. Information needs to be gathered to complete the template in Appendix A, Node Attributes Template. See the section "Hardware Configuration " in IBM Cluster Systems Management for Linux Remote Control Guide and Reference for a detailed discussion of hardware configuration and set-up considerations and for an example of a completed node-attribute table.
  4. The host names of the nodes that are being defined to the cluster need to be registered with the nameserver or added to the /etc/hosts file on the management server.
  5. IBM suggests that you create a separate partition called /tftpboot on the management server to contain a copy of the packages on the installation media before you install CSM. See Creating the /tftpboot partition for the procedure that shows how to do this.
  6. IBM suggests that you add /opt/bin to your $PATH variable and /opt/man to your $MANPATH variable on the management server and on the managed nodes.
  7. Prepare for the use of the dsh command. See Preparing for dsh and configuring the remote shell.
  8. For a full installation, set the boot order of the nodes to boot over the network. The recommended boot order is:
    1. Diskette
    2. CD-ROM
    3. Network
    4. Hard disk

    During the full installation process, Kickstart installs the operating system on each node. The Kickstart post-installation script does any additional set-up. As the node boots for the first time, the makenode command is run, which converts the node from the PreManagedNode class to the ManagedNode class.

Creating the /tftpboot partition

Before installing CSM, create a partition called /tftpboot that consists of 1GB of space for a full installation, which includes the operating system, or 100MB for a CSM-only installation. This will hold the required RPM and tarball packages for installation.

To create /tftpboot by using cfdisk, do the following:

  1. Log in as root.
  2. Run cfdisk.
  3. Move the cursor down to the Free Space entry.
  4. Press n to create a new partition
  5. Enter 100 for the Size (in MB) for a CSM-only installation. Enter 1500MB for a full installation.
  6. Select Beginning to specify where to position the partition.
  7. With the new partition selected, press t to select the partition type.
  8. Enter "83" (Linux) as the partition type.
  9. Select Write to write the new partition information to disk.

    Make a note of the device name and number of the new partition because you will need it for the next steps. Examples of the new partition name might be similar to /dev/hda7 or /dev/sda8.

  10. Reboot the system after the partition has been created. Then do the following:
    1. Run the following command:
      mkfs /dev/device  
      

      (where device is the name of the new partition; for example, hda7 or sda8.)

    2. Then run:
       mkdir  /tftpboot
      
    3. Then mount the partition:
      mount /dev/device  /tftpboot 
      
    4. Add the following line to /etc/fstab:
      /dev/device  /tftpboot  ext2 defaults 1 2
      

Preparing for dsh and configuring the remote shell

A distributed shell program (dsh) is used to run commands on the nodes. It is contained in the csm.dsh RPM and installed by the installms command. The dsh program uses a remote shell of your choice to issue remote commands to the managed nodes from the management server. The following preparation to enable the remote shell is required on each node before dsh is installed:

  1. Decide on the remote shell that you will be using. The default remote shell is rsh. If rsh is used, it is automatically configured on the nodes during a full installation. (Note that ssh and Kerberos are not automatically configured on the nodes.)
  2. The following steps are necessary for a CSM-only installation only.
    1. If you are using rsh, make sure the rsh-server RPM is installed and running. If you are using another remote shell, make sure its daemon is installed and running.
    2. Use the fully qualified host name when you define a node for the remote shell. If the remote shell requires a list of nodes in its configuration, then the nodes must be defined by their fully qualified host names. This allows the dsh command to recognize the node. You can also use an alias to define a node. Aliases are permitted provided the fully qualified host name is also given.
    3. Security must be set up on each node in such a way that dsh is allowed to run commands on that node. If you are using rsh, add the management server host name to the /root/.rhosts file on the nodes that will be managed nodes. If you are using another shell, you must fulfill the requirements for installing and using that shell.

      The DSH_REMOTE_CMD environment variable is used to specify a remote shell other than the default. This environment variable should always be set when CSM commands are issued because some CSM commands use dsh internally and will use rsh as the default if DSH_REMOTE_CMD is not set. The full install process configures rsh on the nodes if DSH_REMOTE_CMD is set to rsh (or if DSH_REMOTE_CMD is not set). This configuration adds the management server to /root/.rhosts, starting the rsh daemon on the nodes.

    4. To ensure that dsh is working on each of the nodes, use the remote shell to run a remote command from the node that will be the management server to each node that will be in the cluster.
    Note:
    Be aware that the dsh command does not provide the set-up for a specific security configuration. The user is responsible for fulfilling the particular security obligations of a specified security environment. At a minimum, you can configure rsh with the /root/.rhosts file on nodes. A more secure environment might have Kerberos configured or might be using some type of shell that conforms to the IETF (Internet Engineering Task Force) Secure Shell protocol.

For more information on dsh, see the man page or the IBM Cluster Systems Management for Linux Technical Reference.

Note:
The Distributed Command Execution Environment (DCEM) graphical user interface is provided to make it easy to use the dsh command functions. See the dcem man page and IBM Cluster Systems Management for Linux Administration Guide for information on how to start and how to use DCEM.


Overview of Cluster Systems Management installation

Two installation processes are offered to install the nodes. If the Linux operating system is not installed, you can install both the Linux operating system and Cluster Systems Management on the nodes. This is referred to as a full installation. If a Linux operating system already exists, you can install just Cluster Systems Management. This is referred to as a CSM-only installation.

For both a full installation and a CSM-only installation, you can take one of two approaches. For a simple installation without interim verification, you can run the following commands in sequence:

  1. Run installms to install the management server.
  2. Run addnode to install the nodes.

    The addnode command runs definenode, setupks (if this is a full installation), and then installnode automatically.

  3. Run monitorinstall to view the results and status of the installation.

If you need more control and would like the ability to double-check and make interim changes during installation, run the underlying commands individually as follows:

For a CSM-only installation, do the following:

  1. Run the installms command.
  2. Run the definenode command.
    1. Use lsnode -P to view node definitions.
    2. Use chnode -P to make changes to the attributes of a node.
  3. Run the installnode command.
  4. Run monitorinstall to view the results and status of the installation.

For a full installation, do the following:

  1. Run the installms command.
  2. Run the definenode command.
    1. Use lsnode -P to view node definitions.
    2. Use chnode -P to make changes to the attributes of a node.
  3. Run the setupks command. You can use the setupks command to tailor your configuration. See the setupks man page and the annotated kscfg.tmpl file in the Appendix for more information.
  4. Run the installnode command.
  5. Run the monitorinstall command to view the results and status of the installation.

All of these commands are run on the management server. Details on these commands can be found in their man pages or in IBM Cluster Systems Management for Linux Technical Reference.
Attention:

For a CSM-only installation, after each node is installed by running installnode, you need to reboot the node to enable remote console support. The node does not have to be rebooted if remote console support is not being used.

The full installation process does a reboot automatically.


Running installms

The installms command performs the tasks that are necessary to make this system a management server. It installs the Open Source and IBM CSM software listed in Specified Operating Environment on the management server automatically if it is not already installed or if it is installed at a previous level.

IBM suggests that you set up the /tftpboot partition before you run installms. You also need to provide and mount the CSM distribution CD-ROM. The default mount point is /mnt/cdrom.

  1. Log in as root to the machine that is to become the management server.
  2. Copy the installms program from the CD-ROM to a temporary directory. The /tmp directory is fine.

    The program first copies installation packages from a download directory or from the CD-ROM that contains the CSM application to /tftpboot/rpm and /tftpboot/tarball.

  3. Next, the program asks you to insert the Linux distribution CD-ROMs in the drive. The program automatically mounts and unmounts the CD-ROMs as needed.
  4. The CSM, RPM, and tarball packages are used to install the code and initialize the server. The installms command determines whether the code needs to be installed (if it is missing or back level) and then installs or replaces the required packages, as necessary.

After installms has been run successfully, the management server is installed. You are ready to run the definenode or addnode command next.

For more information on installms, see the man page or the IBM Cluster Systems Management for Linux Technical Reference.


Running definenode or addnode

After the management server is installed by running installms, run definenode to define all of the nodes in the cluster or addnode to define and install the nodes in the cluster. These commands have certain prerequisites, which you need to be aware of.

Before you run definenode, you must prepare certain information and do some manual set up.

A node that has already been defined cannot be redefined with the definenode command. Including such a node in the command-line input causes the command to fail without defining any nodes. Including such a node in the node definition (nodedef) file, causes the definition of that node to fail, but the other nodes specified in the file are defined successfully. An error message is issued for the undefined node or nodes.

Prerequisites for running definenode or addnode

Before you run definenode or addnode, information needs to be gathered and recorded on a template similar to that in Appendix A, Node Attributes Template. A completed example of this table can be found in IBM Cluster Systems Management for Linux Remote Control Guide and Reference. This information can be entered into a node definition (nodedef) file, or it can be entered at the command line.

A nodedef file allows you enter the host names of the nodes that you wish to define in a file and thus avoid the error-prone task of having to type all of the host names on the command line in order to define nodes. If you intend to use a nodedef file, start with the sample file in /opt/csm/install/nodedef.sample and complete the information from the node-attribute planning template that you completed earlier.

See the nodedef man page or IBM Cluster Systems Management for Linux Technical Reference for more details about the node definition file.
Attention:

IBM suggests using the nodedef file and not the command line to define the nodes in the cluster.

Run definenode or addnode

The definenode command defines all the nodes in the cluster. It does not actually install the nodes. Node installation is done by installnode. If you run addnode, you do not need to run installnode because addnode runs installnode for you.

Note:
Wherever the definenode command is used in the following discussion, the addnode command could be substituted. Unless otherwise noted, the definenode and addnode arguments and usage are similar.

If some arguments are not provided, the command prompts you for each piece of information that it needs. If you should inadvertently miss a required option, the command prompts you for the missing information.

You can either use a node-definition file to define the nodes, console servers, and service processors to the cluster, or you can enter the information from the command line. To use a node definition file in order to define the nodes, console server information and service processors, type:

definenode -f nodedef 

To see the arguments that you need to enter from the command line, type:

definenode -h

To define the node with the host name clsn02.ppd.pok.ibm.com to the cluster, type:

definenode -n clsn02.ppd.pok.ibm.com 

The command prompts for missing information when some or all of the arguments are not provided.

See the man page or IBM Cluster Systems Management for Linux Technical Reference for details on definenode or addnode command-line syntax and more examples of the usage of the command.

See Example of definenode command run interactively for an example that demonstrates the interactive approach.

After definenode has been run successfully, verify the node definitions, and then run installnode. See Verifying node definitions for details.

Some error messages may be returned if definenode is not completely successful. See FAQs, hints, tips, and troubleshooting for troubleshooting information.

Example of definenode command run interactively

If you run the definenode command without any options, the program prompts you for the required information. Also, if you miss a piece of required information, the program prompts you for that information.

The following example shows sample input for nodes, console servers, and service processors with an interactive program. The example uses the definenode command, but the addnode command can be used instead with the same usage and arguments. Instead of requiring you to enter everything at once on the command line, the interactive program allows you to enter a little bit at a time. User input is shown in bold type.

Enter starting node name (hostname or IP address):  clsn01
Enter number of nodes to define (default = 1):  12
Enter list of Hardware Control Points (press ENTER for none):
        Format:  hwctrlpt[:method:spname][,...]
                 hwctrlpt = Hardware Control Point hostname
                            or IP address.
                 method   = Power method (default=netfinity)
                 spname   = Starting service processor name
                            or 'hostname' (default=node01)
        Example: hwctrlpt1::node06,hwctrlpt2,hwctrlpt3
        Example: hwctrlpt1::hostname,hwctrlpt2::hostname
mgtn03,mgtn04::hostname
Enter list of Console Servers (press ENTER for none):
        Format: csname[:method:csnum:port][, ...]
                csname = Console server name (hostname or IP address)
                method = Console method (default=esp)
                csnum  = Console server number (default=1)
                port   = Starting console port number (default=1)
        Example: cs1:::4,cs2:conserver,cs3
mgtn02
Enter Hardware Type (default = netfinity):  netfinity
Enter Install Method (csmonly or kickstart, default=csmonly):  kickstart
definenode: Adding CSM Nodes:
definenode: Adding Node clsn01.ppd.pok.ibm.com(9.114.133.193)
definenode: Adding Node clsn02.ppd.pok.ibm.com(9.114.133.194)
definenode: Adding Node clsn03.ppd.pok.ibm.com(9.114.133.195)
definenode: Adding Node clsn04.ppd.pok.ibm.com(9.114.133.196)
definenode: Adding Node clsn05.ppd.pok.ibm.com(9.114.133.197)
definenode: Adding Node clsn06.ppd.pok.ibm.com(9.114.133.198)
definenode: Adding Node clsn07.ppd.pok.ibm.com(9.114.133.199)
definenode: Adding Node clsn08.ppd.pok.ibm.com(9.114.133.200)
definenode: Adding Node clsn09.ppd.pok.ibm.com(9.114.133.201)
definenode: Adding Node clsn10.ppd.pok.ibm.com(9.114.133.202)
definenode: Adding Node clsn11.ppd.pok.ibm.com(9.114.133.203)
definenode: Adding Node clsn12.ppd.pok.ibm.com(9.114.133.204)
 

Verifying node definitions

After definenode has run, the management server has been set up with all the node information for CSM.

For a CSM-only installation, the cluster nodes are now ready to be installed.

For a full installation, setupks must still be run before verification can take place. Perform the activities in Running setupks before attempting to install the cluster nodes for a full installation.

When you are ready, this section describes how to verify and customize the cluster node definitions before the actual installing of the nodes takes place. Since the actual node installation has not happened yet, you can make changes to any node definitions here.

Verify the csm node information as follows:

  1. Run lsnode -P to display whether the node is on the PreManagedNodes object list. If the node is not on the list, it will not be installed.
  2. Run lsnode -Al -P to display all the information about each node.
  3. Run chnode -P to change the attributes of a node if that is needed.
  4. Run rmnode -P to remove a node before redefining it if that is needed.

If something needs to be corrected, either you can use rmnode -P to remove the node that was not successfully defined and then rerun definenode with the correct arguments, or you can use chnode -P to make changes to any attributes of a node. Note that all of the attributes for a node might not be completed at this point. See the chnode, definenode, lsnode, and rmnode man pages or the IBM Cluster Systems Management for Linux Technical Reference for more information.

ISP password file generated when definenode is run

The definenode command is run to set up the hardware-control-point and console-server attributes that are needed by the rpower and rconsole commands. Before running setupks to perform a full installation, you need to make sure the internal service processor (ISP) passwords are correct.

The ISP password file is created from /etc/opt/csm/netfinity_power.config.templ when definenode is run. Afterwards you can modify the netfinity_power.config file to specify individual passwords and user IDs for each node, if needed. Or, you can leave the default passwords if that is suitable.For more information on netfinity_power.config, see the man page or the IBM Cluster Systems Management for Linux Technical Reference.

More information and additional steps on changing the user IDs and passwords are supplied in IBM Cluster Systems Management for Linux Remote Control Guide and Reference.


Running setupks

The setupks command collects configuration information and uses a template create the Kickstart configuration file for each node containing the information that it has collected. The command also:

A sample annotated template is located in the Appendix. The current template is located on your system at /opt/csm/install/kscfg.tmpl.

You can use the template as-is or modify it. See the annotated kscfg.tmpl file in the Appendix for instructions on how to modify this file. Modifications made to the template file affect the entire cluster and should be made before running setupks.

You can also modify the generated Kickstart configuration file for each node. The resulting Kickstart configuration file that is generated for each node by setupks is called /tftpboot/ks71/node-ip-address-kickstart Modifying this file affects only the settings on this node and should be done after running setupks.

In particular, there are variables in the Kickstart configuration template and the generated file in the format #VARIABLE# that must not be deleted. Many of these are automatically customized with the appropriate values during the process of generating the Kickstart configuration file. For example, the following are some of the variables that are automatically customized (see Appendix B, Appendix B, Sample kscfg.tmpl File for all of the variables):

#MGMTSVR_HOSTNAME#
Replaced with the host name of the management server.

#NFS_HOSTNAME#
Replaced with the host name of the management server.

#NFS_DIR#
Replaced with the directory on the management server that contains the Red Hat installation images; for example, /tftpboot/rh71.

The following information is in the kscfg.tmpl file and in the generated Kickstart configuration file for each node, and can be modified if needed:

Note:
See the annotated kscfg.tmpl sample file in the Appendix, and the setupks and kscfg.tmpl man pages or the IBM Cluster Systems Management for Linux Technical Reference for further details.

Data is collected for each node for the /etc/dhcp.conf file and Kickstart configuration file.

The following information is collected for the /etc/dhcp.conf file. Any existing /etc/dhcp.conf file is saved to /etc/dhcp.conf.orig and a new file is created. After running setupks, any entries that were previously in /etc/dhcp.conf should be replaced manually.

A firstboot file is also generated for each node. The template file is in /opt/csm/install/firstboot.tmpl and the generated files for each node are in /tftpboot/bin/<node-hostname>.firstboot. The firstboot script is run the first time a node boots from its hard drive after it is installed. The purpose of the firstboot script is to run the makenode command. Code may be added to the template or script to run additional functions during firstboot.


Running installnode

This command is used to install the nodes in the cluster by running makenode remotely on each node for a CSM-only installation or by using Kickstart to run makenode for a full installation. The appropriate software listed in Specified Operating Environment is installed automatically by the installnode command on the nodes if it is not already installed or if it is installed at a previous level.

The monitorinstall command displays the installation status for each node. In addition, the makenode.log file is maintained on each node in /var/log/csm/makenode.log that contains information on what happened during installation on each node and a similar installnode.log file is maintained on the management server with information on the whole installation process. For a full installation, a /var/log/csm/kickstart.log file and /var/log/csm/firstboot.log file on each node contain information about Kickstart and firstboot post-installation.

For more information on installnode and makenode, see the man pages or the IBM Cluster Systems Management for Linux Technical Reference.

Prerequisites for running installnode

Before the installnode command can be run, the following must be done on the management server:

  1. NFS must be available to mount and unmount /tftpboot remotely. The nfs-utils RPM contains NFS.
  2. For a CSM-only installation, the dsh command must be available to perform remote commands on the nodes; that is, security must be set up on each node in such a way that dsh is allowed to run commands on that node. dsh is used to perform an NFS mount of /tftpboot to each node and to run makenode from the mounted /tftpboot on each node. It is also used to determine the output of makenode, which is then recorded in the installnode log (/var/log/csm/installnode.log). The log can be reviewed to make sure that the nodes were installed successfully.
  3. The installms and definenode commands must have been run successfully for a CSM-only installation, For a full installation, the setupks command also must have been run successfully.
  4. Verify that the node definitions are correct, or change the node definitions. See Verifying node definitions. When you are satisfied with the node definitions, run installnode.

Run installnode

  1. Run installnode. Note that the installnode command runs synchronously for a CSM-only installation; that is, when installnode completes, the installation of the cluster is complete. But for a full installation, installnode runs asynchronously; that is, immediately after the installation process is initiated (the node is rebooted), installnode exits even though the installation may not be complete.
  2. After you have a working cluster, see Getting started with the newly installed cluster to make sure that the cluster is functioning successfully. (If you are performing a CSM-only installation, you should have a working cluster after running installnode.) Run the monitorinstall command to see how the installation is progressing.
  3. See /var/log/csm/installnode.log on the management server or /var/log/csm/makenode.log on the managed node for information on what happened on each node during installation if there is a problem. To determine how to handle a problem, see FAQs, hints, tips, and troubleshooting .
  4. For a full installation, see /var/log/csm/kickstart.log and firstboot.log for information on the processing of the Kickstart post-installation script and the firstboot script.

After a full install, the boot order in the BIOS of the node can be left as is: floppy, CD-ROM, network, hard disk. In this case, every time the node boots it uses dhcp to contact the management server, which uses pxelinux to boot the node from its hard drive. Or after the full installation is complete, you can change the boot order in the BIOS back to: floppy, DC-ROM, hard disk, network.


Check installation status

The installation monitor tool is started by running the monitorinstall command. The tool displays the status of the installation on each of the nodes. It returns the following types of status: installed, installing, not installed, failed install.

You can also run the rconsole command to view installation progress on each node for a full installation. Type the following:

rconsole -Pa

Adding a node to an existing cluster

You can add another node to the cluster either by running definenode, setupks if this is a full installation, and then installnode again or by running addnode again. To add a new node to the cluster, do the following:

  1. You must assign the correct host name, service processor information, and console server information. For example, you need to assign a proper unused console port number. To find out what attributes are already in use you need to see the attributes not only for managed nodes but also for premanaged nodes because some nodes might not have been installed yet. Type the following to see the attributes of managed nodes:
    lsnode -Al
    

    And, type the following to see the attributes of premanaged nodes:

    lsnode -AlP
    
  2. To define the node, type:
    definenode
    

    You will be prompted for the required information.

  3. After definenode is completed successfully, run setupks if this is a full installation; then run installnode.
  4. Run monitorinstall to check on the status of the installation process.
  5. To verify that the node is installed, type:
    lsnode -Al nodename
    

Removing a node from an existing cluster

Removing a node from a cluster does not uninstall CSM and its prerequisites from the node. Rather, it disassociates the node from its management server. It removes the node from the database of the management server, and it informs the node that it is no longer attached to the management server. To remove a node from the cluster, type:

rmnode hostname

A removed node can be added back into the cluster by running definenode, setupks if this is a full installation, and installnode or addnode again.


Getting started with the newly installed cluster

This section tells you how you can determine whether the installation was successful. It also gives you some suggestions on how to get started using Cluster Systems Management. After installation is successfully completed, remote RMC and CSM commands are enabled. To verify that the installation was successful, enter the following commands. If everything is as it should be, you should see the following results:

To try out monitoring, use the following example.


[ Top of Page | Previous Page | Next Page | Table of Contents | Index ]