IBM CSM to IBM Systems Director Transformation Guide

Chapter 4. Functional comparison 85

You can also use the mkevtautopln command to create an EAP, or chevtautopln to make

changes to an existing EAP.

4.2.4 Monitor migration considerations

Since CSM uses RSCT RMC and IBM Systems Director, it is agent protocol-based. We did

not find any easy way to transform existing CSM monitor or condition data into an XML format

usable by IBM Systems Director, because data is kept in two very different formats.

One could consider whether making such a transformation tool would really be worth it

because this is often costly. Our conclusion is that it depends on the environment and would

most likely require a cost benefit analysis (CBA), the result of which is a total picture of costs,

benefits and risks involved, making it much easier for management to make the final call.

We found it much easier to document the existing CSM monitors by using commands such as

lscondition and lscondresp and then using this information to define new monitors on IBM

Systems Director, but because each environment is different, other solutions might be more

appropriate.

4.3 Hardware and software management

This section contains information about hardware and software management in the cluster.

4.3.1 Remote commands

Remote management facilities in IBM Systems Director are more comprehensive and include

more remote functionalities than CSM. In CSM we got used to performing remote

management for more than one platform with the help of distributed shell commands (dsh)

and distributed copy commands (dcp) for remote file transfer. In Systems Director we can still

find these functionalities, although the implementation is a bit different and plus we can find

many others such as: remote command line, hardware command line, web-based

administration, remote control, and remote serial consoles.

Throughout this chapter we compare the implementation of the functionalities available in

both products and also describe the new funtionalities available only in IBM Systems Director.

Distributed Command Execution

The purpose of dsh is to run remote shell commands and their flags on multiple systems at a

time.

Cluster Systems Management

The dsh used in CSM was based on PSSP's distributed shell commands dsh and dshbak.

When you need to execute a remote command on multiple nodes, dsh runs that command for

you in parallel on all the nodes you specified, and afterwords dshbak formats the output. The

two commands were part of the csm.dsh fileset.

Because dsh could run commands on multiple nodes or groups at a time it was able to

populate its targets from three different sources (contexts): CSM database, NIM resource

database, or dsh-specific methods (node list). Another option was to dynamically construct a

list of nodes by specifying them as parameters using the -n or -N flags.

86 IBM CSM to IBM Systems Director Transformation Guide

There were three available methods to use dsh for remote shell commands:

򐂰 Command Line Interface

With this method you had to build the command every time you ran it and you had to know

all the flags. The nodes against which you wanted to run the command you had to either

enter manually or by setting the DSH_NODE_LIST or WCOLL variable.

򐂰 Smitty csm_dsh

This method enabled you to dynamically construct the commands. Smitty menus were

able to search for nodes and groups defined in the CSM database and set them as targets

for the command you were about to run.

򐂰 Distributed Command Execution Manager

DCEM was included as a plug-in application in the IBM web-based System Manager. This

method was the most comprehensive because you had many options available. You could

choose the nodes or devices to run this command against based on DHS, NIM, or CSM’s

database, and had the option to save and edit the commands you built for later use. DCEM

command output and activity were saved in log files so you were able to search through

previous runs of the commands. For more details see IBM Cluster Systems Management

for AIX and Linux Planning and Installation Guide Version 1, Release 7.1, SA23-1344-05.

With CSM it was the system administrator's responsibility to configure and enable remote

shell access to the systems, or configure Kerberos. So we can say that CSM was not in

charge of security. The distributed shell command dsh used the underlying remote shell

security protocols, which by default was rsh, but you had the option to change it to an even

more secure remote command protocol, ssh.

Figure 4-8 on page 87 shows the panel of CSM - DCEM.