Chapter 1 - |
Product Description |
This chapter provides an overview of the Configuration and Service Tracker (CST) software for version CST 3.0. It includes the following sections:
CST plays an important role in the overall strategy of proactive system management at a customer site. The software executing on each monitored host provides a macroscopic view of system configuration changes that are caused by failures or upgrades and service patterns over an extended period.
CST 3.0 includes a configuration for automatic emails to be sent to Sun Microsystems. The emails contain captured tracking data, which is used by Sun to track system availability and performance and to continually improve Sun products and services. Availability Management System (AMS) is a secure database where the captured availability data is stored in Sun Microsystems.
CST 3.0 can be deployed either within Sun Management Center envinroment or in an independant framework
The CST application tracks and record event and configuration data to be viewed and reported upon through the CST user interface.
CST automatically detects the following events for the system on which it runs:
On Sun multi-domain systems, CST also detects the following events:
When an event is detected, CST captures a snapshot of the current system configuration information and categorizes it into the following categories:
CST determines and records the changes in the configuration of the system by comparing the new snapshot with the previous snapshot.
In UltraSPARC® III platforms, CST collects more detailed hardware information about the Field Replaceable Units (FRUs) in the system. This hardware information is in addition to the data collected by the hardware probe common to all Sun systems. The additional FRU data is viewable as a sub-category in the Installed Hardware section of the Configurations folder. This is considered part of Hardware Information and changes in FRU do not generate separate events.
For the Sun Fire 3800, 4800, 4810, and 6800 systems, CST collects FRU information remotely from the CST middleware server host.
The CST user interface is also used interactively to enter service comments and cause codes for each event.
CST provides a number of benefits for system administration, including:
CST 3.0 has the following components:
The CST server is a multi-threaded daemon running on the designated server system. It manages agent data reported by the various 'attached' CST agents and communicates with the UI to display the collected data.
The server maintains all the agent data in a system. Data from the agents is maintained in unique folders within the file system for easy lookup and maintenance.
In the Sun Management Center environment, the CST server communicates to the CST console via the CST service agent.
In addition, the CST server has the agent functionality built-in, and it collects and tracks the configuration changes occuring on the system. Hence it is not required to install the CST agent on the CST server system
When registered, the CST server also sends the complete agent information back to Sun either via the Net Connect 3.0 secure pipe or via secure email if Net Connect 3.0 is unavailable.
CST Agent is a daemon that runs on each of the systems being tracked. The daemon detects whenever a change occurs and creates an event according to the change.
CST Agent can be attached or unattached. An unattached agent is a self-monitoring unit that collects data but does not report the data to any CST server. The user interface is not available for unattached agents.
Once a CST utility, either cstattach or cstattagt, is used to make the connection, the CST agent starts reporting to a middleware, and the GUI is updated with the agent information. From that point forward, the agent data can be viewed using the GUI. See Chapter 6, Utilities , cstattach, and cstattagt, for details on the utilities.
When the CST agent is not attached, the following are available:
All information collected by the daemon is also sent to the CST server on the middleware system for automatic backup. If the server system or its software cannot be reached, the data is backed up and transmitted again when the connection is reestablished.
The CST "heartbeat" process ensures that a CST daemon is running and ready to collect data at all times.
The repository resides in the server system. It holds the data that CST collects from the tracked systems. The CST data is kept in a hierarchical directory structure, where each directory represents a specific system. The key data files in each directory are outlined in TABLE 1-1.
Caution - Do not edit these files manually. They are maintained by the CST software. Any edits will corrupt the file and disable software functionality. |
The directories in the repository are created automatically by the server, based on the hierarchy information provided during the install of the CST agent, or at the time of "attach."
The CST user interface is an applet when the CST installation is stand-alone based. In an environment where SunMC is installed, you can invoke the CST console via the SunMC soncole, Tool menu.
This is an applet that can be viewed using a browser, such as Netscape. It can be invoked from the URL:
The hierarchy information is available in Enterprise View within the CST applet.
Both user interfaces provide the user with the collected information, history log, and configuration. Each includes printing reports, managing events, and retrieving statistics.
The CST service agent is a customized agent on the Sun Management Center server that provides two-way data transfer between the CST console and the CST server.
The CST service agent is bundled with the Sun Management Center server software, and activates automatically when a CST server (SUNWcstu) is also installed on that system.
Note - When you are running CST 3.0 with Sun Management Center, you open CST through the Tool menu. The Sun Management Center console is the user interface. |
This is an application that runs from within the Sun Management Center console. The CST UI can be invoked from the tools menu in the Sun Management Center console. The CST console is a pop-up frame from the Sun Management Center console, and the hierarchy information is available on the Sun Management Center window.
CST 3.0 supports all current Sun 4d- and 4u-based server platforms, Sun4u desktops, including the Sun Enterprise 10000, and Sun Fire platforms, both mid-range and high-end models. CST 3.0 software supports Sun Cluster 3.0 and 3.1 environments.
CST 3.0 runs in Solaris 2.6, 7, and 8 and 9 operating environments.
CST 3.0 does not support Solaris versions 2.4 and 2.5.1. CST versions 1.5.1 and 2.1U1 - both AMS and non-AMS releases, run on Solaris 2.5.1 and can report into a CST 3.0 server.
To view CST data through an applet requires a browser, such as Netscape, that supports JDK 1.2 or later.
CST 3.0 can be installed on and can track events on all Solaris/Sparc platforms, including Sparc III versions. The following sections describe CST support for the multi-domain Sun platforms.
Since Sun Enterprise 10000 servers can have multiple domains and a System Service Processor (SSP) to manage the platform, multiple copies of CST must be run on this platform. One instance is installed and run on each of the domains. Also, a separate CST agent must be installed on the SSP.
Note - It is important that the CST agent is installed on the SSP. It should be installed on the SSP before installing on the domains. |
CST on the SSP tracks the following events:
CST on the domain tracks the following events on that domain:
CST 3.0 is designed to support all Sun Fire platforms:
CST can track platform information from the system controllers on a Sun Enterprise 15K system, also known as a Sun Fire 15K and 12K.
The CST agent must be installed on the system controllers, and it must run on each of the domains. If the system has a spare system controller, the CST agent must also be installed on the spare system controller.
CST 3.0 supports creation of service events and annotation of event comments for system controllers and domains, but it does not support creation of service events or updates at the platform level.
The CST 3.0 application on the system controllers tracks the following events:
CST can track platform information for all Sun Fire systems.
To facilitate manual configuration described in the above note, use the CST utility, addsunfire. This utility helps configure the remote monitoring agent. For details on this utility, see Chapter 6, Utilities, , addsunfire.
The CST agent is run on the Sun Fire midrange domains just as it is on other server systems.
When installed on Sun Cluster 3.0 or Sun Cluster 3.1 Cluster nodes, CST 3.0 tracks and provides a continuos record of the cluster membership and configuration changes. The data is stored in the repository as a formatted file and is available for viewing from the CST console. The information is viewable through a tabbed panel in the Configurations section of the CST user interface.
The information is further sub-categorized into the following:
CST also detects various cluster failover events and records them in the CST history file. The events are annotated with additional relevant details such as cluster ID, affected resource group/node, failover status etc. These are available for viewing through the events table and the events comments section in the CST history folder.
The following cluster events are tracked.
The "CLUSTER_PLATFORM" hierarchy is created on the server, and it is viewable from the CST user interface. With this feature, users can do the following:
Note - Events in the global CST history under "CST Cluster ID" hierarchy are logged and sorted based on the time when the CST server receives each event and not necessarily on the event timestamp. |
Note - The "Summary" section of Cluster configuration for "CST Cluster ID" hierarchy reports the name of the last node with a configuration change. |
Volume Manager is viewable on a tabbed pane in the Configurations section of CST.
The information is further sub-categorized into the following:
Note - Volume Manager events and differences are included on the History folder. |
CST tracks the standard events as listed in Tracking and Recording Events.
If there are applications on the system that are started or stopped through UNIX shell, awk, or perl scripts, the configuration changes, and start and stop activity on those applications can be monitored through CST. To manually register a custom event related to those applications, include the following line at the end of the application Start/Stop script:
The app_event only relays the event. It does not validate if the application successfully started or stopped.
For example, the following line adds the machine password change as a CST event to the CST History log:
Each time this line of code is included, CST registers the event in the CST History section of the CST Graphical User Interface (GUI) (See Chapter 4, Features and Functions,, FIGURE 4-10).
To track such password changes automatically, add the following script to your crontab file, and run it at your convenient time and frequency, for example, every hour or every day.
#!/bin/sh
# This script is used for creating a cst application event of
# event type string "Password Change" by calling cst command
# app_event. You need to add this script to your crontab file.
# Get the time info of the file: /etc/passwd
if test -f /tmp/cst_app_passwd
then
ls -l /etc/passwd|awk '{print $6, $7, $8}' > /tmp/cst_app_passwd_new
# Compare the time stamp of the passwd file, to see if there
# any difference.
diff /tmp/cst_app_passwd /tmp/cst_app_passwd_new >/tmp/cst_result
result=`ls -l /tmp/cst_result|awk '{print $5}'`
if test $result = 0
then
echo "The password is not changed" >/tmp/cstpasswd
rm /tmp/cst_app_passwd_new
rm /tmp/cst_result
else
cp /tmp/cst_app_passwd_new /tmp/cst_app_passwd
rm /tmp/cst_app_passwd_new
# Call cst_app_event to register event
/opt/SUNWcst/bin/app_event "Password Changed" "Changed by owner"
fi
fi
When the data feed to Sun is enabled, CST sends all tracked data to Sun in XML format through the secure Net Connect, Proxy if it is installed on the server where CST server exists. If the Proxy is absent, the data is sent as a secure email.
To send the data by Net Connect Proxy, Net Connect 3.0 must be installed on the CST server. If this is installed when the CST server is already running, the CST server must be stopped. Using the following command. Type:
To send the data by secure email, the CST server must have "sendmail" installed.
The data is sent asynchronously, i.e. sent when a monitored host reports one or more of the following events:
The data content is usually less than 1KB in size except when large configuration changes are involved.
Periodically CST sends summary information about the installed site to Sun. The summary data is used to checkpoint system status to provide accurate availability reporting.
If the continous data feed to Sun is not enabled, a skeleton summary of the install base is still sent to a secure site within Sun, once a week. This summary information is used to help generate statistics on CST deployment. For more details or to turn this ability onor off, contact your Sun representative.
Copyright © 2003, Sun Microsystems, Inc. All rights reserved.