CA Network and Systems Management (NSM) |
Last Updated: February 22, 2013 |
This section provides best practices and guidelines for making the most of your CA Network and Systems Management (NSM) implementation. Many of the links in the left hand pane point to product-specific sections elsewhere in the Implementation Best Practices pages.The topics provided on this main page provide additional product-specific deployment considerations and other hot topics and best practices. For example, the Event Management topic provides tips on using the Advanced Event Correlation (AEC) function.
CA NSM Technical Support provides a regularly updated list of Tips/Tricks/Knowledge Sharing WebCasts through the following link:
https://support.ca.com/irj/portal/anonymous/phpdocs?filePath=0/2869/unicentertechsupp-webcast.html
This page will host new announcements in the CA NSM space as well as overviews, troubleshooting tips/tricks and general knowledge sharing on topics related to CA NSM and its functional components and options.
For additional tips, consult the Technical Document Index for your particular solution on the CA Technical Support website (http:\\support.ca.com).
This section contains information that applies to two or more solutions deployed in the same environment.
When two or more CA products are deployed into the same environment, one of the most commonly asked questions is "Does it matter which product I install first?" According the the MDB Install Order document, the answer will depend on which MDB release is involved. Prior to MDB r1.5, MDB installations created all of the database objects for all CA products. This caused the MDB to be larger than needed for the installed CA products. The latest version of the MDB (version 1.5) now installs only the database objects needed for the product being installed. Two of the solutions that currently use MDB r1.5 are CA NSM 11.2 and CA Automation Point r11.1. Although a new MDB will contain only those product schemas required by the product that installed it, older products using the older MDB version will be expecting all of the tables to be present. Therefore, before installing a CA product that ships with a prior version of the MDB you must first run the MDB Upgrade Script to restore all of the old MDB tables.
For information on how to determine which version of the MDB your installed product is running, and what steps may be required to make that MDB compatible with subsequent product installs, consult the following link:
ftp://ftp.ca.com/pub/ips/MDB/1.04/MAKE_COMPATIBLE/CA_MDB_Install_MDB104_into_partial_MDB15.html
Placement of a shared MDB, in relation to multiple products, is another concern. Should (or must) it be shared and, if so, which products should access it locally - and which can access it remotely? Answers to this question can be found in the Federation Guidelines page, which also includes the following links:
Multi-product deployments also impact sizing requirements. For example, if both CA NSM and CA Desktop and Server Management will be sharing a single MDB, what sizing adjustments might I need to make to accommodate all of the MDB tables for both products?
When installing multiple CA products you should use shorter path lengths than the default if more than one product will be installed on the box or if other installs have added to the current system path length. This is due to the 1023 character path length limitation imposed by the Windows Server 2003 operating system.
You can check the length of the System Variable path under System Properties. Check the length of the "expanded" path variable from the command line. For example, execute the following and count the characters:
path > p.txt
If the path statement is too long change the path variable to include more short names and reboot.
Click here for additional options and to access a tool that can be used to identify system path lengths.
In any event, maintenance and tuning considerations become even more critical when multiple products are sharing the same MDB. Guidelines for managing SQL, Oracle and Ingres based MDBs can be found in the Working with the MDB section..
This section contains tips and best practices for making the most of your CA Network and Systems Management (NSM) implementation.
If you are migrating from CA NSM r3.1 to CA NSM r11.2, a field developed migration utility (NSM 3.1 Migrate) is available to help you with the process. This utility provides an easy-to-follow wizard that enables you to select which components to migrate. Keep in mind that you will still need to test the migration and modify configuration settings once it is complete. As with all product updates you should also be sure to create a backup of existing configuration settings and database contents, including customized policies.
In general, the CA NSM Tips and Tricks presentation includes a number of useful tips ranging from sizing guidelines to tuning recommendations to troubleshooting considerations. The Unicenter Service Dependencies and Commonly used commands (reference sheet) documents both provide at a glance reference sheets.
The visualization components provide user access to the various GUIs and "management points." For CA NSM this includes:
The following links provide helpful tips specific to the NSM UIs:
The most commonly implemented Enterprise Management function is Event. Event allows for the processing of messages, and their related actions. With the ability to put together strings of actions, with condition code checking, the possibilities are endless. Also, the definition of Event Management policy is extremely quick and easy. In a distributed environment, many levels of Event Management can be linked together and processed cooperatively. In a small-scale implementation we may have just one Event Manager; in large rollouts we may have many more in a layered approach.
The Alert Management System (AMS) organizes and tracks the most important events in an enterprise or a logical segment of an enterprise so that you can focus on and manage the highest severity IT events. AMS provides tools for defining alert policies and multiple panes in the CA NSM MCC for viewing alerts. AMS lets you link to CA Service Desk, the customer support application that manages calls and IT assets, resolves problems, and shares corporate knowledge. You can also view the Alert Management console through MP.
For a discussion of the Alert Management System (AMS), click here.
Advanced Event Correlation (AEC) integrates seamlessly with Event Management to provide a powerful event correlation, root cause, and impact analysis capability. When used with existing CA NSM features, AEC can increase the quality and reduce the quantity of the information reported on the Event Console, which is used to automate certain operational tasks. Event correlation is a way to group associated events together for further processing. Grouping events lets you do simple but powerful forms of processing, such as event suppression, reformatting, aggregation or consolidation.
Information on using AEC can be found in the Administrator Guide as well as the Inside Event Management and Alert Management Guide.
Click here to review a document which provides a tutorial on how to create AEC policy to suppress events based on hostname. The technique described is one of a few AEC methods that may be deployed in response to the need to suppress events during maintenance windows.
Additional sample AEC policies for both CA NSM r11.x and for earlier releases can be found in the Sample Policies section.
Another commonly implemented Enterprise Management function is Job Management - formerly known as "Workload Management.". The CA NSM Job Management Option is configured with one or more Job Management Option Servers, which direct job scheduling, and CA Universal Job Management Agents, which actually execute the jobs.
For additional information on JMO architecture and planning, click here.
Unicenter employs many different types of Agents (including the Job Management and Event Agents discussed in the previous sections) but for the purposes of this discussion, we will be focusing on the SNMP Agents which are included under the umbrella of Agent Technology. Agent Technology requires the cooperation of multiple components. Roughly speaking:
Unicenter supports Agents on a wide range of platforms. However, there are platforms where Agents do not exist. These platforms may be critical to the enterprise. In this case one of the monitoring options is to use a proxy. Proxies bring the information from the platform into the Unicenter "domain". For example, Console logs from an HP 3000 machine piped to a managed SOLARIS, or a serial port feed into a Windows machine. Just because we don't have a specific agent doesn't mean we can't manage that object for the client. It has been done many times, and is a fairly easy thing to accomplish.
Another option is to use Resource Monitoring (RM) which utilizes an Admin Interface, a Remote Monitoring Agent and a Data Store. The Admin Interface is used to configure the monitored resource, to view its state and to present a centralized view of the enterprise through WorldView. The RM Agents, which are deployed throughout the enterprise and run as a Windows Service, process the data and copy it to the Data Store. More information on Remote Monitoring is provided in the Implementation Guide.
Policy is a general term meaning "the rules under which CA NSM operates." Event message actions, and Job Management jobs and jobsets are examples of Enterprise management policies. ForwardFSMEvent and Agent configsets are examples of Manager and Agent policies. If you realize that the long-term maintenance of these policies is something that should be of concern, you will look for ways to make this procedure more efficient and easy.
In Unicenter, "policy" refers to the overall strategy regarding how a resource is monitored in context. It entails
Policy can occur at many levels throughout the organization but it is best to :
DSM Policy is an extremely powerful tool. It enables a DSM to function completely autonomously even if the connection to the Enterprise Level is lost. Care must be taken when creating or modifying DSM Policy, and should be tested thoroughly in a lab environment. Also, if additional scripts/programs are invoked by the DSM, the power requirements for the DSM may increase. The ability to invoke external scripts/applications means that the DSM function can become the centerpiece for Regional management.
Distributed Intelligence Architecture (DIA) enables a central location to manage all components and aspects of a network. DIA makes data requests and retrievals standard across different CA NSM components by providing a generic mechanism that permits the dynamic deployment of necessary files to facilitate the correct monitoring of any given system. Deployment is generic and open to growth. DIA allows for high speed, secure communications to transport data while providing remote node management and inherent failover capabilities.
DIA consists of Knowledge Bases that are installed with management components such as WorldView and the DSM. The Knowledge Bases are formed into a virtual grid and can be further sub divided by configuring DIA zones. The DNA components are installed with agent installations and are registered to the DIA grid.
Tips on designing and troubleshooting your DIA architecture can be found in the DIA Supplemental Implementation Topics Guide that is available for download from the CA Network and Systems Management home page on Support Online.
WorldView Database Tunnel (wvdbt)
The WorldView Database Tunnel (wvdbt) is an Agent Technology service that provides access to MDB (CORe) for remote Distributed State Machines (DSMs). There are many reasons to deploy wvdbt, including:
Click here for a discussion of best practices using wvdbt in CA NSM r11.x.
In the event of change in hostname (i.e., through upgrade or resource consolidation) for a machine on which a CA NSM component has been installed, consult the following documents for information on software updates needed to reflect that change: