| Configuration and Service Tracker, version 3.5 |    
|
| Configuration and Service Tracker, version 3.5 |
|
| Chapter 1- |
|
Product Description |
This chapter provides an overview of the Configuration and Service Tracker (CST) software for version CST 3.5. 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 caused by failures, upgrades, and/or service activities over an extended period.
CST 3.5 includes a configuration for sending data automatically back to Sun Microsystems. The data 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.
Some key capabilities are that CST:
CST 3.5 can be deployed either within Sun Management Center envinroment (versions 3.0 and 3.5) or in a SunSM Remote Services (SRS) Net Connect 3.0.x environment. CST 3.5 can also exist as an independant application.
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:
System software (formerly Sun Open Net Environment software)
When an event is detected, CST captures a snapshot of the current system configuration information and categorizes it into the following categories:
Operating System
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.5 has the following components:
CST server runs on the designated server system. The server receives data from all the reporting agents and stores it in the repository. The terms CST server and CST middleware mean the same thing, and they are used interchangeably in this document.
CST agent is the CST daemon running on the system tracked by the CST agent (aka host), and, when attached to a CST server, it reports all collected information to its CST server.
The information from the agents is stored in the CST repository. This is stored as a fixed format (ASCII) file in a file system on the CST server.
The CST console is a Java-based user interface that can run either as a Java applet in a browser or as a Java bean in the Sun Management Center console.
The functionality of both the user interfaces is similar. The user interface allows a user to view and manage the CST collected events.
The CST service agent daemon runs only if the environment is Sun Management Center based. The service agent transfers data between the CST server and the CST console in the Sun Management Center environment.
The application tracking modules are shared object callback routines invoked by the CST agent to track the UP/DOWN of applications. There is one tracking module for each application.
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 SRS Net Connect 3.0.x secure pipe or via secure email if SRS Net Connect 3.0.x 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 the Utilities chapter, cstattach, and cstattagt, for details on the utilities.
When the CST agent is not attached, the following are available:
/var/opt/SUNWcst/probe.current
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 concole, Tool menu.
This is an applet that can be viewed using a browser, such as Netscape. It can be invoked from the URL:
http://<middleware-name>/cst.html
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 (versions 3.0 and 3.5) 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.5 with Sun Management Center, version 3.0 or 3.5, 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 (version 3.0 or 3.5) 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.5 has built-in support to track the availability of all the Sun Java System software applications that are part of Sun Java System. The tracking is achieved through callback routines invoked by the CST agent at prespecified intervals.
The tracking modules are shipped bundled as part of the CST agent package and are automatically invoked when the CST agent is installed. They have the capability to detect the presence as well as the UP/DOWN status of the applications they are designed to track. The events are registered, through a CST interface called cstappev, for logging and forwarding.
CST 3.5 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.5 software supports Sun Cluster 3.0 and 3.1 environments.
CST 3.5 runs in Solaris 2.6, 7, and 8 and 9 operating environments.
CST 3.5 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.5 server.
To view CST data through an applet requires a browser, such as Netscape, that supports JDK 1.2 or later.
CST 3.5 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.5 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.5 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.5 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 addsunfire in the Utilities chapter .
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.5 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.
[ D ]
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:
Each cluster has a hierarchy inside "CLUSTER_PLATFORM." The CST cluster ID hierarchy is created for each cluster, and the hierarchy name is in the following format:
CLUSTER_NAME,CLUSTER_ID,CLUSTER_VERSION
A soft link for each node is created under the hierarchy for easy viewing of the cluster member. Clicking the nodename displays generic cluster-node information.
|
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.
[ D ]
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.
When installed on systems running one or more software applications of the Sun Java System, CST 3.5 has the built-in capability to track the availability and configuration changes of these applications. This tracking is achieved through custom tracking modules that are bundled with the CST 3.5 agent package.
The following applications are tracked:
*These applications were formerly known as Sun ONE applications.
There is a one-to-one mapping between the application and the tracking module. The tracking module has the capability to track multiple instances of the application running on the monitored host.
Each application and its specific instance are assigned a specific ID by the tracking module. The format for the ID is as follows:
<App Class>,<App Name>,<App Version>,<App Instance>
For example: Sun Java System,Application Server, 7, domain1_admin-server
The tracking modules are loaded when the CST application is invoked on a monitored system. Subsequently, the tracking modules detect the presence of the application to be tracked, and, if found, determine the configuration and the instances in effect. The application and its instances are registered as "<Application> Registered" events through the cstappev interface. The modules then track the application on a continual basis, and register Application UP/DOWN events as well as events to notify configuration and usage snapshots.
All tracked information is stored both locally on the agent and on the central server to which the agent is attached. The collected data is available for viewing throughthe CST applet under the APPLICATIONS tab. For more details,
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:
/opt/SUNWcst/bin/app_event "event type" "comment"
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:
/opt/SUNWcst/bin/app_event "password changed" "By machine owner"
Each time this line of code is included, CST registers the event in the CST History section of the CST Graphical User Interface (GUI). For an example, see FIGURE 4-12 in the CST Features and Functions chapter.
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 CST packet name
for i in SUNWcstu SUNWcst SUNWcstv SUNWcstve
do
pkginfo $i 2> /dev/null 1> /dev/null
if test $? = 0
then
packname=$i
break
fi
done
# Get the installation base
instbase=`pkginfo -r $packname`
# Set the full path to app_event
app_event=$instbase"/"$packname"/bin/app_event"
# 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 is
# 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
cp /tmp/cst_app_passwd_new /tmp/cst_app_passwd
# Call cst_app_event to register event
$app_event "Password Changed" "Changed by owner" 1> /dev/null
fi
else
ls -l /etc/passwd | awk '{print $6, $7, $8}' > /tmp/cst_app_passwd
fi
rm /tmp/cst_app_passwd_new
rm /tmp/cst_result
# End of the script
When the data feed to Sun is enabled, CST sends all tracked data to Sun in XML format through the secure SRS Net Connect proxy, when SRS Net Connect is installed on the server where CST server resides. If the SRS Net Connect proxy is absent, the data is sent as a secure email.
SRS Net Connect is a self-managed system monitoring, configuration, patch and trend reporting tool. It is designed to enable Sun customers to monitor their Sun systems, and identify events before they can escalate into downtime. This tool is activated and used via the Web where customers view system status and configurations, trend and patch information, and alarms. Alarms can also be sent to the customer by email and pager.
The goal of SRS Net Connect is to empower our customers to proactively and preemptively manage their Sun server and storage systems in order to maximize system availability.
To send the data by SRS Net Connect proxy, SRS Net Connect 3.0.x must be installed on the CST server. If SRS Net Connect is installed on the CST server when the CST server is already running, the CST server must be stopped with the following command. Type:
# /opt/SUNWcstu/sbin/cstadm stop
#/opt/SUNWcstu/sbin/cstadm start
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.
| Configuration and Service Tracker, version 3.5 | 817-0706-02 |
|
Copyright © 2003, Sun Microsystems, Inc. All rights reserved.