|
|
You should read this chapter to understand how the Cisco Info Server is set up. Once you are familiar with this information, we recommend you use the Process Control system to manage the Cisco Info Server. See "Process Control," for detailed information.
Additional information about the Cisco Info Server is included in "Cisco Info Server Reference."
This chapter includes the following sections:
The Cisco Info Server is the core of Cisco Info Center and is where all event and status data is stored and managed.
The Cisco Info Server is an active, main-memory database. Event information is passed to the Cisco Info Server from external programs, such as Mediators or Gateways, and this information is stored in a series of database tables. The Cisco Info Server uses the event information to update the alerts.status table. When an event is stored in this table, it is known as an alert. For more information about the database tables, see the "Cisco Info Server Table Formats" section.
The Cisco Info Server updates the stored information using a method called "deduplication." The deduplication process analyzes incoming events and determines whether they represent an additional instance of an event that has already arrived or indicate a fault condition that is related to an existing event. If the event duplicates an existing event, the original event is updated and the new event is not displayed on the monitoring interface. This reduces the amount of data in the Cisco Info Server. For more detailed information on the deduplication process, see the, "Deduplication" section.
The Cisco Info Server also stores details about users and their privileges, information about how to display events in the Event List, class information for generic type events, menus for Cisco Info Admin Desktop tools, and other information used in the management of the system.
Cisco Info Center Admin Desktops can attach to the Cisco Info Server and use the event information. For example, an Admin Desktop can attach to the Cisco Info Server, validate the user's identity, and allow users to view and manipulate these alerts, depending upon their security. The Objective View also attaches to the Cisco Info Server and allows users to view the information in a graphical display.
Information can be exported from the Cisco Info Server to other applications by attaching a Cisco Info Gateway. The Cisco Info Gateway monitors the alerts.status table for changes. The operation and configuration of a Cisco Info Gateway is described in the Cisco Info Center Mediator and Gateway Reference.
The Cisco Info Server is also capable of responding automatically to particular events or the state of an event. This is known as Automation. For details, see "Automation."
A Cisco Info Server uses Cisco Info Server SQL as its command language. For details on the syntax of Cisco Info Server SQL, see "Cisco Info Server Reference."
The following sections describe how the Cisco Info Server reduces the event information using the deduplication process.
Event information is forwarded to the Cisco Info Server from Info Mediators or Gateways with an identifier field. This field is used as a key and the alerts.status table is searched for an identical key.
If an identical key is not found in the status table, an alert entry is inserted into the alerts.status table. All the field information transmitted by the Info Mediator is placed in this new entry, including the FirstOccurrence time.
If an identical key is found, that entry is updated with the latest status information. The update process updates the LastOccurrence field with the time from the incoming event and increments the Count field. No other fields are updated unless the ReawakenClosed property in the Cisco Info Server is set to true. In this case, the Severity field is updated if the severity in the Cisco Info Server's alert is 0 (Closed). If DeackOnReawaken is set, the Acknowledged field is cleared. This key matching process is referred to as deduplication.
The Identifier field plays a critical role in how an event is deduplicated and what makes a unique event. Identifier fields are generated by the Mediators sending the event. The generation of the identifier is controlled by the Cisco Info Mediator rules file, which is Cisco Info Mediator specific.
For more information on the generation of identifier fields, see the Cisco Info Center Mediator and Gateway Reference manual.
The Cisco Info Server uses a narrow casting mechanism called IDUC (Insert, Delete, Update, or Control) to notify client tools of changes in event information. To avoid network and system saturation, IDUC messages are bundled up on a discrete interval. When this interval expires, an IDUC packet is sent to each client tool with the details of all changes in the alerts. This interval is called the Cisco Info Server granularity and is controlled by a property called granularity. Granularity is, by default, set to
60 seconds. Reducing the granularity increases the real-time response of the client tools but greatly increases the network traffic and Cisco Info Server load. The sixty second value is optimal for most systems and it is recommended the value not be changed unless under the guidance of technical support.
This section describes how to start a Cisco Info Server manually. You must have a Cisco Info Server running before you can use any of the components of Cisco Info Center.
To start the Cisco Info Server, issue the following command:
host% $OMNIHOME/bin/nco_objserv -name <servername>where servername is the name of the Info Server that you want to start.
 |
Note The default server name given to Info Servers when you run the nco_config configuration program is INFOSERVER. |
By default, each Info Server selects a random unused port for the IDUC connection when started.
To specify an IDUC port, you can either use the -port option on the command line or specify the IDUC port in the host services file (/etc/services).
To specify an IDUC port, enter the following command:
$OMNIHOME/bin/nco_objserv -name servername -port nnnnwhere servername is the name of the Info Server that you want to start and nnnn is the port number that you want to use.
For more information on the command line options for nco_objserv see the, "Command Line Options" section.
Info Servers should only be stopped in one of the following ways:
It is recommended that the Info Server runs under process control to ensure that the Info Server starts when the machine starts up and to provide an automatic restart if the Info Server fails. Process control is described in "Process Control."
Process control is provided by the Cisco Info Center process agent. The process agent ensures that the Info Server automatically restarts if it fails. By starting the process agent at system startup, you can make the Info Server start when the machine powers up.
To stop an Info Server that has been started manually, use the SQL interactive interface. For more information on the SQL interactive interface, see the "SQL Interactive Interface" section.
Enter the following command to start the SQL interface:
$OMNIHOME/bin/nco_sql -server servername -user rootwhere servername is the name of the Info Server that you want to stop.
Provide the requested password when the SQL prompt appears, then enter the following:
1> shutdown;You can add the dump option to the shutdown SQL command when converting to default storage. For details on the shutdown command see the "shutdown" section.
If the Info Server was started under process control, the process agent restarts it automatically after a manual shutdown. In this case, you must shut the Info Server down by logging into the process agent.
The Info Server normally runs under process control. If you try to shut it down using the nco_sql command, the process agent restarts it automatically.
If the Info Server has been started by a process agent and the remote machine also has a process agent running, you can use the standard process control commands to start and stop the Info Server. For more information see the "Starting a Service or Process" section and the "Stopping a Service or Process" section. The name specified by the -server option is compared to the process agent names configured on the host. The host machine and port are identified and the command is sent to the correct process agent.
Upon start-up, nco_objserv attempts to open the $OMNIHOME/etc/<servername>.props file and the $OMNIHOME/etc/<servername>.sql file, where <servername> is the name of the server. These files define the run-time properties and the database configuration of the Cisco Info Server.
If the <servername>.props file is not found, the following message appears:
Warning: couldn't open /opt/Omnibus/etc/<servername>.props
If the <servername>.sql file is not found, the following message appears:
Operating system error: No such file or directory
Once this file has been read, by default, the Cisco Info Server scans the directory defined in the environment variable $OMNIDB. If this variable is not set, $OMNIHOME/db is used instead. This directory contains all the state information from the previous run of nco_objserv, as well as user names, automation triggers and actions, and other configuration information. Files are stored with the following naming convention:
<servername>.<databasename>.<tablename>.dat
Where <servername> is the name of the server, <databasename> is the name of the database, and <tablename> is the name of the table within that database. For each database and table within it, nco_objserv looks up these files and loads their contents into that table.
In addition to the .dat files, some tables in the database create files with the .trans extension. These files are transaction logs of changes in the table as the .dat file was last written to. The .dat files are updated every five minutes, at which point, the .trans files are consolidated and cleared.
As an example, for the Cisco Info Server named INFOSERVER, some of the files looked for are:
When the Cisco Info Server is running, these files are kept up to date with the current state of the Cisco Info Server, unless transient mode is enabled (not recommended).
The connection details for each Info Server must be stored in the interfaces.solaris2 file. To modify the entries in this file, run the nco_xigen utility. For information on running nco_xigen, see chapter 3 of the Cisco Info Center Installation and Configuration manual.
When an Info Server, Info Mediator, Info Gateway, or Admin Desktop starts up, it reads the $OMNIHOME/etc/interfaces.solaris2 file to find connection information. If the Info Server is not available, it uses the connection details for a backup Info Server.
An Info Server that is to be used as a backup server requires a second entry in the interfaces.solaris2 file. The backup server entry must have the same name as the primary Info Server. Normally the host machine and port number are different.
Note that the names must be in upper case. Also, do not use a name that ends with the letters _PA or _GATE as these letters are reserved to identify a Process Control agent or Cisco Info Gateway, respectively.
For each Cisco Info Server name, an entry must exist in the interfaces file, and a port must be allocated in the /etc/services file (see Section, "Service File Entries for Multiple Cisco Info Servers").
You can create any number of Info Servers on a single machine. To create a new Cisco Info Server, enter the following command:
host% $OMNIHOME/install/nco_new_server <servername>where servername is the name of the new Info Server.
This creates the default database initialization files for the new Cisco Info Server. These are described in the "Database Initialization" section.
|
Note After you create a new Cisco Info Server, you should run the nco_xigen utility to add the new server name to the to add this name to the interfaces.solaris2 file. For more information, see the Cisco Info Center Installation and Configuration manual. |
When you are running more than one Cisco Info Server, each Cisco Info Server in the system should contain an entry in the /etc/services file on all machines. The entry uses the following form:
nco_<servername> <nnnn>/tcp Where <servername> is the name of the Cisco Info Server and <nnnn> is a four digit port number. For example, the entry for two Info Servers, named INFOSERVER and ISERVER2 could read:
nco_INFOSERVER 4100/tcp
nco_ISERVER2 4101/tcp
The port can be set to any number, however, do not use the numbers 1 to 1024 as these are generally assigned as system numbers.
The /etc/services file may be managed by Network Information Service (NIS). In this case, you should make the entry in the NIS services file, then push the updated configuration to all machines.
Without the entries in the /etc/services file on a machine where multiple Cisco Info Servers exist, the second and later Cisco Info Servers are unable to start as they all attempt to use the same socket. Without the entries in the /etc/services file on a machine which is a client of a machine with multiple Cisco Info Servers, the Cisco Info Admin Desktop tools find themselves connecting to one server but receiving update information from one of the other servers. For this reason, it is important the required entries are present in the /etc/services file.
The following sections describe the command line options for the Cisco Info Server. The options use the following format:
nco_objserv -option <parameter> Each Cisco Info Server requires a unique name. This is the name referred to in the interfaces file. The default name for the Cisco Info Server is INFOSERVER.
You can override the default name with the -name command line option followed by a string, which should be the name of the Cisco Info Server. This is appropriate where more than one Cisco Info Server is in use or where the system is to be configured with an alternative name (rather than INFOSERVER) for the first Cisco Info Server.
In systems where a Domain Name System (DNS) is widely used, the name returned by a host machine internally may not be the name by which it is referred to on the network. For example, a machine named sfo may actually be referred to on the network as sfo.bigcorp.org. An Info Server running on sfo should have -DNS sfo.bigcorp.org set on the command line.
Before you run Cisco Info Center, the port for each Cisco Info Server is specified in the /etc/services file. See Section, "Service File Entries for Multiple Cisco Info Servers". To specify another port number when you start the Cisco Info Server, use the -port option. For example, to test the port number 4300, specify -port 4300 on the command line.
The property file is read at start-up to configure the Cisco Info Server. Use the Configuration tool to manipulate the properties. See"The Properties Tab" section for more information. When a Cisco Info Server is not running, you can manipulate the properties using the Properties Editor (nco_xprops). See the "Editing the Cisco Info Server Properties" section for more information.
The default properties file is named $OMNIHOME/etc/<servername>.props, where <servername> is the name of the Cisco Info Server. For example, if the server name is INFOSERVER, the properties file is, by default, $OMNIHOME/etc/INFOSERVER.props.
The Cisco Info Server has a command line option, -propsfile <filename>. This allows you to specify an alternative properties file.
The SQL file is read at start-up to define the Info Server. If you do not specify an SQL file when starting an Info Server the default file is used.The default file location is:
$OMNIHOME/etc/servername.sql
where servername is the name of the Info Server.
To specify an alternative SQL file, use the following option:
-sqlfile stringIn this command, string is the full path and file name of the alternative SQL file.
You can copy and edit the default Info Server template to create an alternative SQL file. See the "Adding Database Tables to the Cisco Info Server" section for more information.
To set the maximum log file size, use the -logsize numeric option where numeric is the size of the log in Kbytes. The default value is 1024.
By default, the log file is written in the $OMNIHOME/log directory with the log file name being the name of the Cisco Info Server. To override the default and specify a different name, use the -logfile option followed by a full pathname to a file. The -uniquelog option is overridden by -logfile.
The log file process can be stopped from writing to a file and send its output to the UNIX standard output, that is, the console where the command is run.
To do this, use the -stderr command line option. No log files are written to disk when using -stderr.
Some administrators require a separate log file that records all delete commands issued on the Info Server. This is called a delete log.
To create a delete log, use the -DELETES option followed by the name of the file to which you want the delete log to be written.
To set the level of detail sent to the log file after an alert is deleted, use the following option:
-DELETES_LEVEL numericwhere numeric is the log level.
Table 1-1 describes the details sent for each log level
.
| Level | Details logged |
|---|---|
< 0 | No log output. |
0 | appid, sql |
1 | time, uid, appid, sql. |
2+ | time, uid, appid, sql + the contents of each alert deleted. |
To set the size of the delete log, use the option -DELETES_SIZE numeric. Once the size of the file reaches the number of bytes specified in numeric, the Info Server starts a new log file on the next command. Logging from a single statement is never split between files.
The Cisco Info Server can be run in secure mode. The -secure option controls the authentication of any Cisco Info Mediator or Cisco Info Gateway connection requests with a user name and an encrypted password. The default is unsecure mode.
When a connection request is sent, the Cisco Info Server issues an authentication message. The Cisco Info Mediator or Cisco Info Gateway must respond with the correct user name and password.
Each Info Mediator, monitor or Info Gateway must have a unique AuthUserName property and AuthPassword property in its rules file. If the user name and password are incorrect, the Info Server issues an error message.
You can choose any name for the property AuthUserName. To generate the associated property AuthPassword enter the following command:
The command takes the unencrypted password and displays the encrypted password.
See the "Secure Mode" section in Chapter 1 of the Cisco Info Center Mediator and Gateway Reference for more information on setting passwords.
The Cisco Info Server can collect statistics (for example, the number of events or Mediators.) By default, the statistics gathering facility is disabled and the stats table in the INFOSERVER.sql file is commented out.
create table stats(StatTime time,NumClients int,NumRealtime int,NumProbes int,NumGateways int,NumMonitors int,NumProxys int,EventCount int,JournalCount int,DetailCount int,primary key(StatTime),permanent);
|
Note You can also comment out individual fields to stop that statistic being recorded. |
The Cisco Info Server uses a per-client broadcast mechanism called IDUC to inform clients of changes in the tables. By default, this is set to 60 seconds. The -granularity option controls the batching of IDUC broadcasts, taking a time in seconds as its parameter; reducing this value increases the update rate to the clients.
While the Info Server is running, it maintains copies of files on disk for all of the tables in memory. The processes used are called checkpointing and logging.
Two methods are available for the storage of the database tables in memory: default storage and region storage. Each storage method uses a different type of checkpointing and logging.
Checkpointing can be controlled by setting the -interval option followed by an integer value representing a time in seconds. The default interval is 300 seconds.
The choice of storage method also defines which database tables can be controlled using the -interval option.
See the "Maintaining Database Table Files on Disk" section for details on default storage and region storage.
An internal clock is used to control the sampling of automation triggers. By default, this is set to 1 second, but it can be overridden by setting the -autotick option with a parameter which is the number of seconds to sample with.
|
Note This is not recommended for production use. |
The Cisco Info Server uses an internal timer by default on Solaris systems. This timer is used to give a timing mechanism to the automation system. To override this default setting, use the -timer command line option followed by the parameters:
The Cisco Info Server can, by default, support 64 connections from Cisco Info Admin Desktop clients, Cisco Info Gateways and Mediators. This maximum number of connections can be increased by specifying the option -connections followed by a value for the new maximum number of connections.
|
Note The -stacksize option should only be used after consulting technical support. |
Debug messages can be added to the log file using the -debug option followed by an integer which represents the level of debug. For example, -debug 0 is the default, which generates no debug messages. Set 1, 2, and 3 to generate more debug messages.
The Cisco Info Server displays its version details. All other options are ignored.
For example, specify the following command:
host% nco_objserv -helpThe Cisco Info Server displays a usage message which details all the available options and briefly describes their purpose.
When nco_objserv is started with the -norecover command line option, the Cisco Info Server makes no attempt to recover the files in $OMNIDB (or $OMNIHOME/db when $OMNIDB is not set), and starts with completely empty tables. This includes the master database names table, so no tools can connect. The only access is through the nco_sql command. This mode is for maintenance only.
|
Note This option is not recommended for production use of the Cisco Info Server. |
When nco_objserv is started with the -transient command line option, the Cisco Info Server makes no attempt to write to the files in $OMNIDB (or $OMNIHOME/db when $OMNIDB is not set), however, it does load the contents of those files at start up.
|
Note This option is not recommended for production use of the Cisco Info Server. |
The Cisco Info Server is made up of the following databases:
The database name appears at the start of a tablename in the following format:
<databasename>.<tablename>
It is recommended this fully qualified name is used when referring to any table.
Alert related tables are described in more detail in the following sections in Appendix A
Authentication tables are described in more details in the following sections in Appendix A:
Automation tables are described in more details in the following sections in Appendix A:
Desktop tool tables are described in more detail in the following sections:
The Java Event List table is described in more detail in the following section in Appendix A:
The Internet Service Monitors table is described in more detail in the following section:
The data types used in the Info Server tables are described in more detail in the following section:
This section describes the Cisco Info Server support utilities and processes which allow you to customize the Cisco Info Server.
More information about the support commands is available in the "Cisco Info Server Interactive Commands" section in Appendix A.
You can login to the Cisco Info Server using the nco_sql utility, which requires a username and password.
To start the nco_sql utility, specify the following command:
host% nco_sql -user root -server <servername>Where <servername> is the name of the Cisco Info Server (when this option is omitted, the default server INFOSERVER is used). You are then prompted for your Cisco Info Center password. Once you have logged in, the following prompt appears:
1>
Step 2 Enter a valid SQL statement.
Step 3 Enter go and then press Return to send the command to the Cisco Info Server.
The results of the command are displayed on the screen.
To exit nco_sql, press <Ctrl D> or enter quit.
For information on stopping the Cisco Info Server, see the "Stopping the Info Server" section.
It is possible to add extra databases and tables to the Info Server to complement the standard tables.
For example, you might require a table that contains all the alerts from one host machine. To do this you would write an automation to populate the new table with data from a standard table.
To add a database table to the Info Server, complete these steps:
For instruction on stopping the Info Server, see the "Stopping the Info Server" section
You cannot modify the database tables while the Info Server is running. You can create tables and databases, but their configuration is lost when the Info Server restarts. To make a permanent change, you must modify the Info Server's initialization file. Before you do this, it is recommended that you shut down the Info Server.
Step 2 Locate the Info Server's initialization SQL file.
This file is located in the following location
$OMNIHOME/etc/servername.sql
where servername is the name of the Info Server
Step 3 Make a copy of the initialization SQL file.
This allows you to roll back any changes if necessary.
Step 4 Edit the initialization SQL file:
a. Do not modify the set of CREATE DATABASE and CREATE TABLE commands.
custom database is created for customer use. You can add any number of new tables to this database as required. b. Go to the end of the file to add your new entries.
c. Add the CREATE DATABASE/TABLE section.
d. At the end of the file, add the CREATE DATABASE and CREATE TABLE sections.
Step 5 Save the initialization SQL file.
Step 6 Restart the system.
Step 7 Make sure that you check for any error messages from the Info Server when it starts up. These messages can indicate errors in your new SQL code.
The following example shows how to create a new database called netusers, with a table called userlist that contains user IDs and the users' full names.
At the end of the servername.sql file, enter the following line to create a new database called netusers:
CREATE DATABASE netusers;
On the next line, enter the following USE DATABASE command so that the Info Server creates the table within the correct database:
USE DATABASE netusers;
To make the file easier to read, you can add empty lines between entries as required.
Enter the following line, including the open brace, to create the new table userlist:
CREATE TABLE userlist {
The following lines add two variable character fields. The field userid can contain a maximum of 20 characters and the field username can contain a maximum of 128 characters.
userid varchar(20), username varchar(128),
A primary key entry must be included in any tables you create. The primary key is used for row retrieval and in deduplication. To make the userid field the table's primary key, enter the following line:
primary key(userid),
If more than one primary key entry is specified for a table, only the last entry is used. The Netcool/OMNIbus Info Server does not support multiple primary keys.
The permanent command makes the Info Server save the contents of the table to disk automatically, in the same way that the other Info Server tables are saved. When the Info Server is restarted after being shutdown, the contents of the table are restored automatically. To restore the contents of the table, enter the following line:
permanent
The closing brace completes the entry.
}
The following listing shows the complete SQL code for creating the database and table:
CREATE DATABASE netusers;
USE DATABASE netusers;
CREATE TABLE userlist {
userid char(20),
username char(128),
primary key(userid),
permanent
}
In Table A-2 ("alerts.status Table") in Appendix A, particular fields are marked as mandatory. Do not modify or remove these fields from the alerts.status table.
In the following sequence of operations, it is assumed the changes are being made on a Cisco Info Server named INFOSERVER. Substitute this name with the name of the Cisco Info Server you are changing.
See the "Stopping the Info Server" section for a listing of the commands used to stop the Info Center.
You cannot modify the tables when the Cisco Info Server is running. It is possible to create tables and databases, however, the configuration of these is lost when the Cisco Info Server restarts. To make a permanent change, you must modify the Cisco Info Server's initialization file and it is recommended that you shut down the Cisco Info Server.
Step 2 Make a backup of your data. Make a copy of all data in the $OMNIHOME/db directory to a chosen directory.
Step 3 Copy your initialization SQL file. Copy the $OMNIHOME/etc/servername.sql file to $OMNIHOME/etc/servername.orig. This allows the nco_migrate utility to operate.
Step 4 Edit the initialization SQL file. Edit the servername.sql file with your preferred editor. To modify the alerts.status table, locate the CREATE TABLE status line and change the definition within the braces {}.
Step 5 Save the servername.sql initialization file when you have completed your editing.
Step 6 Migrate your existing data to the new database.
The nco_migrate utility takes the previous (servername.sql) configuration and the new (servername.sql) configuration and works out how to move the data into the new configuration. To run nco_migrate, enter the following:
host% $OMNIHOME/bin/nco_migrate -server servernamewhere servername is the name of the Info Server that you want to migrate.
The process is automatic.
Step 7 Restart the Cisco Info Server.
With new fields installed, it is possible to populate them in two ways:
The database used by the Info Server is main-memory resident. Main memory is volatile and its contents are lost if a controlled shutdown or a power failure occurs. To ensure data is not lost in these circumstances, it is copied to disk.
Two types of file are maintained on disk.
At each checkpoint the table is copied to a checkpoint file and its associated log file is deleted. The type of checkpoint used depends upon the storage method chosen.
When an Info Server is started, the main memory database is restored by loading the most recent files on disk. When recovering from an unexpected shutdown the Info Server loads both the checkpoint files and the log files.
There are two methods available for storing table data in memory. Each storage method uses a different checkpointing and logging procedure. The options are:
It is not necessary to understand how the two storage methods work. The decision to use default or region storage should be made after considering the advantages and disadvantages of each method. These are described in "Advantages and Disadvantages".
Each row in a database table is written to the checkpoint file in an SQL insert format. When the Info Server starts this file is loaded and the database is recreated by running these SQL commands. If a log file exists for a table, the SQL commands in this file are replayed to complete the process.
For each table a checkpoint file is generated from the database table in memory. The checkpoint file name is in the format:
servername.databasename.tablename.dat
Before copying data to the checkpoint file, the previous version is renamed as follows:
servername.databasename.tablename.bak
Tables which are rarely updated are copied to a file each time there is a change. Tables which are frequently updated are checkpointed. Checkpointing takes place at specified time intervals. The time interval between each checkpoint is set in the Info Server properties file. The default time is 300 seconds.
The changes made to a table between each checkpoint are added to a log file. The log file name is in the format:
servername.databasename.tablename.trans
Where servername is the name of the Info Server, databasename is the name of the database and tablename is the name of the table. For example INFOSERVER.alerts.status.
The .bak file is only used if the .dat file has been corrupted during an unexpected shutdown. Changes since the .bak file was created are still contained in the .trans file.
For example the default Info Server named INFOSERVER would contain the following files:
INFOSERVER.alerts.col_visuals.dat INFOSERVER.alerts.colors.dat INFOSERVER.alerts.conversions.dat INFOSERVER.alerts.details.dat INFOSERVER.alerts.journal.dat INFOSERVER.alerts.journal.bak INFOSERVER.alerts.journal.trans INFOSERVER.alerts.objclass.dat INFOSERVER.alerts.objmenuitems.dat INFOSERVER.alerts.objmenus.dat INFOSERVER.alerts.resolutions.dat INFOSERVER.alerts.status.dat INFOSERVER.alerts.status.bak INFOSERVER.alerts.status.trans INFOSERVER.auto.actions.dat INFOSERVER.auto.triggers.dat INFOSERVER.jel.jel_props.dat INFOSERVER.master.groups.dat INFOSERVER.master.members.dat INFOSERVER.master.names.dat INFOSERVER.master.profiles.dat INFOSERVER.master.stats.dat INFOSERVER.service.status.dat INFOSERVER.tools.action_access.dat INFOSERVER.tools.actions.dat INFOSERVER.tools.menu_items.dat INFOSERVER.tools.menus.dat INFOSERVER.tools.menu_defs.dat INFOSERVER.tools.prompt_defs.dat
Region storage is a method of storing data within the Info Server. The method has a number of performance advantages over the default storage method when the Info Server contains large database tables.
For each table two checkpoint files are generated from the database table in memory. The checkpoint file names are in the following format:
servername.databasename.tablename.chk0 servername.databasename.tablename.chk1
For each table two log files are generated. Their names are in the following format:
servername.databasename.tablename.log0 servername.databasename.tablename.log1
servername.databasename.tablename.tab.
Where servername is the name of the Info Server, databasename is the name of the database and tablename is the name of the table. For example INFOSERVER.alerts.status.
The checkpoint process writes alternately to the .chk0 and .chk1 files. If one file has become corrupted during an unexpected shutdown the data in the other file and the log files are used to rebuild the database tables in memory.
As each checkpoint starts, the logging process switches to the alternate log file. The older log file is deleted before the start of the next checkpoint.
The .tab file is unique to the machine and can not normally be transported to another machine.
When using region storage the Info Server rebuilds the database tables in memory by loading the table file. If the shutdown was unexpected, the database tables in memory are rebuilt using the checkpoint files and log file for each database table.
The following points should be considered when deciding whether to use default storage or region storage:
When default storage is used, the tables in memory are locked during checkpointing. Any Info Server connection which tries to change a table is put on hold until the checkpoint is complete and the lock is removed. When the connection is on hold a desktop could freeze and a probe may temporarily stall. The data from the probe is sent once the communication link is active.
When region storage is used, it is not necessary for the Info Server to lock the tables during checkpointing. No connections are placed on hold.
The database table lock only becomes noticeable when database tables are very large. In a typical installation deduplication prevents tables becoming large enough for the memory lock to become an issue.
When default storage is used, only frequently updated tables are logged. These log files contain the SQL statements that are applied to a table. SQL statements include bulk commands such as update and delete. These take up very little space when logged.
When region storage is used, every table uses logging. These log files contain the data from every modified row.
The region storage log files can become much larger than the default storage log files.
Region storage is enabled by setting the property RegionStorage to be True in the Info Server .props file. The Info Server must be shut down before this property can be changed. To return to default storage set the option to False.
When changing the storage method, the checkpoint files and logging files must be converted before the Info Server can start correctly.
Enter the command nco_objserv -dattofuzzy while the Info Server is not running to convert the .dat files to .tab files.
There are two ways to change from region storage to default storage:
Log in to the Info Server using the SQL interactive interface. For details see "Cisco Info Server SQL" section.
Shut down the Info Server using the following commands:
1> shutdown dump;The Info Server is shut down. The default checkpoint file .dat is generated instead of the .tab file.
The migration utility nco_migrate operates by default on .dat files used in default storage. The -fuzzy option allows the migration utility to operate on region storage.
Enter the following command:
nco_migrate -fuzzyThe .tab file is converted to a .dat file, then the migrate command is applied and the .dat file is converted back to a .tab file.
If the -fuzzy option is used on an Info Server which is running default storage, the nco_migrate command is ignored.
For details on the nco_migrate command see the "Database Migration" section.
In very rare cases, the use of region storage can result in tables becoming fragmented in memory. To reclaim the unused space in a table, run the following SQL command:
vacuum databasename.tablename;In this command, databasename is the name of the database and tablename is the name of the table.
If the command is issued when region storage is not enabled, it has no effect.
|
Note This command should only be used under the advice of technical support. |
If a large number of external programs are forwarding event information directly to the Cisco Info Server, this can have a negative impact on performance.
Figure 1-1 shows a Proxy Server configuration.
Proxy Servers can be started quickly on the command line. However, once you have become familiar with the command line options, you should start the Proxy Server using the Process Control system. See "Process Control," for more information.
nco_proxyserv -name proxy_name server servernamewhere proxy_name is the name of the Proxy Server and servername is the name of the Info Server to which the Proxy Server will forward events.
Each Proxy Server requires a unique name. This is the name referred to in the interfaces file. The default name for the Proxy Server is NCO_PROXY.
You can override the default name with the -name command line option, followed by the name of the Proxy Server. This option is appropriate when using more than one Proxy Server or using an alternative name, rather than NCO_PROXY.
This is the name of the Cisco Info Server to which the Proxy Server is to connect. The default is INFOSERVER.
The Proxy Server allows you to use an alternative properties file with the command line option, -propsfile <filename>. The default property file is named $OMNIHOME/etc/<servername>.props, where <servername> is the name of the Proxy Server.
For example, when the Proxy Server is NCO_PROXY, the properties file is by default, $OMNIHOME/etc/NCO_PROXY.props.
The Proxy Server can, by default, support a maximum of thirty connections from Mediators and Gateways. This maximum number of connections can be increased by specifying the -max option followed by the new maximum number of connections.
This option sets the ratio for connections to the Proxy Server. The ratio is for incoming connections, for example from Mediators, to outgoing connections to a Cisco Info Server. The default is 10:1.
To find out the Proxy Server version, use the -version command line option. For example, specify the following command:
host% nco_proxyserv -versionThe Proxy Server displays the version details. All other options are ignored.
The Proxy Server displays a usage message which details all the available options and briefly describes their purpose.
The system administration interface for Cisco Info Center includes a utility called the Properties Editor. A properties file is any file with a .props extension. You can use this window to edit properties files for Info Servers, Proxy Servers, Process Agents, Info Mediators, Monitors, and Info Gateways.
If the Info Server is running, you can start the Properties Editor from the Properties tab of the Configuration Manager portion of the Conductor utility. If the Info Server is not running, you can start the Properties editor from the UNIX command line. You can also start the Properties Editor from the Conductor utility.
To start editing the Cisco Info Server properties, enter the following:
host% $OMNIHOME/bin/nco_xpropsFigure 1-2 shows the Properties Editor window.
To edit the Cisco Info Server properties, complete these steps:
Step 2 Select a properties file from the File options list.
Step 3 Click on the Open button.
The Properties Editor searches the /Omnibus/etc directory for files with a .props extension and then lists the properties.
Step 4 To change property values, complete these steps:
a. Click on a property to select it.
b. Edit the value in the Value field.
c. Click on the Update button.
If you click on the Name field, the button label changes to Add. Click on the Add button to specify this as a new property to the list and then complete steps 4b and 4c to edit it.
Step 5 When you are done updating the properties, click the Save button to accept your changes.
Step 6 Click the Close button to exit the Properties Editor.
|
Note The settings in a read only property file are displayed in grey. You cannot modify them. |
To add a new property, complete these steps:
Step 2 Enter a value in the Value frame.
Step 3 Click the Add button to add the new property.
 |
Caution Click the Save button to save your changes. |
To delete a property from the list, complete these steps:
Step 2 Click on the Remove button.
Step 3 Click on the Save button to save your changes.
To save the changed properties, click on the Save button.
Posted: Tue Jun 13 15:29:05 PDT 2000
Copyright 1989 - 2000©Cisco Systems Inc.
