Chapter 5. Administration

This chapter discusses the following:

Monitoring Status

To monitor status, use the following:

  • The sgicm-config-cluster GUI to monitor the status of the cluster and the services

  • clustat to monitor the cluster status

Figure 5-1 shows an example of the GUI.

Figure 5-1. Status

Status

Displaying Service Information

To display information about a service using the GUI, click on the service name in the Cluster Status window.

In the CLI:

sgicm-config-cluster-cmd --service=servicename

For example:

# sgicm-config-cluster-cmd --service=nfs

Figure 5-2 shows an example of the status window.

Figure 5-2. Service Information

Service Information

Starting Cluster Processes

Use the following GUI selection in the Cluster Status window to start cluster daemons on the local member:

Cluster -> Start Local Cluster Daemons

In the CLI:

/etc/init.d/clumanager start

To start the daemons on other members, you must run the GUI or CLI on those other machines.

Stopping Cluster Processes

Use the following GUI selection in the Cluster Status window to stop cluster daemons on the local member:

Cluster -> Stop Local Cluster Daemons

In the CLI:

/etc/init.d/clumanager stop

To stop the daemons on other members, you must run the GUI or CLI on those other machines.

Service Administration

In the GUI, use the Cluster Status window to enable, disable, detach, restart, or stop services or to view service properties. You can also restart and relocate a service by using drag and drop on the service icon to the target node icon.

When you enable a service, you start it for the first time. The service will start on any member in the cluster based on the failover domain. When you restart the service, it restarts the service that was already running on the local node.

In a successful detach operation, the service is no longer monitored and is not part of the cluster, but continues to run on the member. (The difference between detach and disable is that the services are not stopped with a detach.)

You can also use the clusvcadm command as follows:

  • Enable the service on the local member:

    clusvcadm -e service

  • Enable the service on the specified member:

    clusvcadm -e service -m member

  • Disable the service:

    clusvcadm -d service

  • Detach the service:

    clusvcadm -t service

  • Restart the service on the local member:

    clusvcadm -R service

  • Relocate the service:

    clusvcadm -r service -m member

  • Stop the service:

    clusvcadm -s service

To avoid seeing output, use the -q option.

Cluster Service States

A service can have one of the following states:

State

Description

Uninitialized

Transitioning when clusvcmgrd daemon starts

Pending

Transitioning to running or disabled

Running

Online and is being actively monitored

Disabled

Not online and service was stopped

Stopped

Disabled but will start when cluster processes are started again

Failed

Needs operator attention

Detached

Not online but the service was not stopped in the cluster

A detached service has no owner and last owner is the member where the service application is still running. The GUI and the clustat command display the last owner for services in the detached state, as shown in the Figure 5-3.

Figure 5-3. Detached State

Detached State

To recover from detached state, you must disable the service and then enable it. When a disable action is performed on the service, the service's stop scripts are executed on the last owner. If you try to perform an enable or restart action on a service in the detached state, it will fail with the following error message:

Service servicename is in detached state. Disable 
and then enable service.

If the last owner of a service in detached state leaves cluster membership, or if the cluster daemons are stopped on the last owner of the service, the service will move to disabled state.


Caution: Although the service is in disabled state, the service application is still running on the last owner and is not stopped by SGI Cluster Manager. If you attempt to enable the service at this point, it will cause data integrity problems.


Message Logging

SGI Cluster Manager logs messages to /var/log/messages using the syslog facility local4. You can use syslog.conf to redirect messages to another location. To rotate logs, use logrotate(8).

SGI Cluster Manager uses the following message levels:

Level

Description

0

EMERG (emergency)

1

ALERT

2

CRIT (critical problem)

3

ERROR

4

WARNING (default)

5

NOTICE

6

INFO (informational)

7

DEBUG