Release 8.1.5
A67822-01
 Library |
 Product |
 Contents |
 Index |
| Oracle SNMP Support Reference Guide Release 8.1.5 A67822-01 |
|
This chapter provides a brief overview of Oracle SNMP Support, including:
The Simple Network Management Protocol (SNMP) is acknowledged as the published, open standard for heterogeneous network management applications.
Designed primarily for database, network, and system administrators, Oracle SNMP Support integrates the management of Oracle products into a number of existing, widely-used management systems. This feature enables key Oracle products running anywhere on an enterprise's network to be located, identified, and monitored by a management station running at a centrally located node, in much the same way and using much the same tools as traditionally have been used to monitor the activity of the network itself. It thereby integrates the tasks of database and of network administrators, enabling both to use some of the same tools and to better integrate their tasks. Tools using SNMP traditionally provide powerful features for monitoring network components. Oracle extends this power to enable SNMP monitoring of some of its own products.
The primary benefits of Oracle SNMP Support include the following:
Strictly speaking, Oracle SNMP Support is intended more for monitoring Oracle products than for managing them. Oracle SNMP Support is invaluable for tracking the status of an entire network of Oracle applications -- first, to verify normal operations, and second, to spot and react to potential problems as soon as they are detected. However, for purposes of investigating and ameliorating some problems, other Oracle tools such as Oracle Server Manager may be more appropriate. This is because Oracle SNMP Support is designed to query status, but not to change system parameters, whereas other tools are designed to set or tune system parameters. Oracle does not support using SNMP to change, as opposed to query, system parameters primarily because the security that SNMP currently can provide is not considered adequate.
SNMP (Simple Network Management Protocol) is a standard internet protocol enabling certain nodes in a network, the management stations or managing nodes, to query other network components or applications for information concerning their status and activities. Such a query is known as an SNMP poll. The items that can be so polled are called managed elements. Traditionally, managed elements were limited to network components such as bridges and routers, but recently the definition has been extended to include mission-critical applications such as databases.
The software used by a management station is called a management framework or management platform. The management framework uses the SNMP protocol to request information from agents on the nodes being managed, and those agents send back the appropriate responses. The agents can also, independently of the framework, transmit messages called traps to well-known addresses in response to specific events. This is done to enable quick and possibly automatic reactions to the specific conditions that the traps indicate.
All requests sent to a given network node are handled by the same master agent. This agent redirects the requests to the appropriate managed elements on the node, in some cases using subagents. The protocol used for this is not yet standardized and is not SNMP. The information that SNMP can obtain is described in a structure called a Management Information Base (MIB), which is located on the node of the managed element.
Figure 1-1 shows the components of a management station and of a sample managed node.
The components shown in Figure 1-1 are explained in the sections that follow.
The management station refers to a node from which managed elements are monitored using the SNMP protocol. Typically, it is a stand-alone workstation that is on the same network or internetwork as the managed elements. While this book will consistently use the term management station, other terms used for it include management console, management system, or managing node.
At the management station, the management framework uses SNMP to request management information from other nodes. The framework collects, graphs, and possibly acts on that SNMP data, and saves some or all of it in a repository for historical analysis and reporting. Management frameworks include many tools and options. In addition to directly requesting information from managed nodes, frameworks typically use daemons to alert them when a managed node has sent a trap in response to a specific set of conditions. The traps also can be used to trigger management applications.
Because most frameworks use SNMP as a basis for communication, Oracle products that support SNMP can be integrated into virtually every management framework. Examples of such frameworks include:
Most of today's management frameworks also provide a selection of graphical objects that management applications may use to build a graphical user interface that serves their particular needs, such as:
The management applications are the tools integrated with the management framework to accomplish more specialized network or database tasks. These applications contain virtually all of the sophisticated logic associated with network management.
A customized management application can work with one or more frameworks (on different management stations) or run independently. Because Oracle SNMP Support is equally accessible to any type of provider, there are many different ways that applications can utilize it.
A fundamental management application, often shipped by default along with the management framework, is one that is capable of discovering the network topology and collecting some basic identification information about each discovered network entity or service. Such an application, for instance, may discover all hosts in a subnet along with their vendor, location, and status. Using this information, the management application can subsequently build up logical maps of the environment.
The managed node is a platform, such as a UNIX server, on which elements to be monitored reside. In Figure 1-1, two managed elements -- an Oracle7 or Oracle8 server and Oracle Names -- are located on the managed node.
The master agent is the process on a managed node that accepts queries, also called "polls", from the management framework and communicates with the elements to be managed in order to answer the query. It also can send SNMP traps independently in response to specific conditions. Only one master agent can exist on each managed node. Any node that does not have an agent will not be able to respond to SNMP requests, but this does not prevent other nodes on the network from doing so. In other words, it is not necessary that every node in a network be able to respond to SNMP, although this is normally desirable.
The master agent may be either monolithic or extensible. If it is monolithic, it communicates directly with the elements to be managed. Although such an agent can manage multiple elements on the same node, the set of elements that it can manage is fixed when the agent is created, because the monolithic agent itself is responsible for interfacing to the managed elements.
If, on the other hand, the master agent is extensible, it will use a specific subagent for each element it has to manage. That subagent is then responsible for interfacing to the element. In this scenario, new subagents can register with the master agent at any time, so new managed elements can be added dynamically.
Some operating systems supply only monolithic agents. In this case, Oracle provides a master agent that can effectively treat that monolithic agent as a subagent, enabling new managed elements to be added to the node dynamically.
The subagent is a process that receives queries for a particular managed element from the master agent and sends back the appropriate answers to the master agent. One subagent exists for each managed element residing on the managed node (with the exception that a single subagent can handle multiple Oracle database instances on the same node). In Figure 1-1, one subagent is dedicated to the Oracle7 or Oracle8 server application and another subagent is dedicated to the Names application. The subagent(s) and master agent communicate using a multiplexing protocol dictated by the master agent. There is no standard protocol for this connection, and, while a few protocols are widely used, none is a designated standard.
Notice that the subagent for the Oracle7 and Oracle8 servers is a separate process that communicates with the server through SQL*Net (using the IPC protocol). The Oracle Names subagent, on the other hand, is embedded in the application software itself. Both of these approaches are acceptable, as the specific means the subagents use to extract SNMP values are opaque to the master agent and to the framework.
Oracle Enterprise Manager is a system management tool which provides an integrated solution for managing a heterogeneous environment. It combines a graphical console, agents, common services, and tools to provide an integrated, comprehensive systems management platform for managing Oracle products.
Oracle Enterprise Manager does not use SNMP directly. Instead, it communicates with the agent over SQL*Net using Transparent Network Substrate (TNS) connections. The agent listens to SNMP requests and passes them on to Oracle Enterprise Manager.
The agents are intelligent processes running on remote nodes in the network. An agent resides on the same node as the service it supports. However, the agent can support more than one service on a particular node. For example, if two databases are installed on one machine, a single agent can support both databases. The agents perform such tasks as running jobs and monitoring events. They are also responsible for handling SNMP requests, if SNMP is supported on the agent's platform.
The agents support SNMP so applications can communicate directly with the agent using SNMP protocol on supported platforms. The agents provide access to Oracle's database Management Information Base (MIB) variables. Although the agent supports SNMP, the Oracle Enterprise Manager Communication Daemon uses TNS to communicate with the agent. Therefore, with Oracle Enterprise Manager, you can submit jobs or events that access Oracle MIB variables through the Daemon even when the database resides on a platform that does not support SNMP.
A management information base (MIB) is a text file, written in ASN.1 notation, which describes the variables containing the information that SNMP can access. The variables described in a MIB, which are also called MIB objects, are the items that can be monitored using SNMP. There is one MIB for each element being monitored. Each monolithic or subagent consults its respective MIB in order to learn the variables it can retrieve and their characteristics. The encapsulation of this information in the MIB is what enables master agents to register new subagents dynamically -- everything the master agent needs to know about the subagent is contained in its MIB. The management framework and management applications also consult these MIBs for the same purpose. In Figure 1-1, two MIBs exist, one for the Oracle Server and one for Oracle Names. MIBs can be either standard (also called public) or proprietary (also called private or vendor).
The actual values of the variables are not part of the MIB, but are retrieved through a platform-dependent process called "instrumentation". The concept of the MIB is very important because all SNMP communications refer to one or more MIB objects. What is transmitted to the framework is, essentially, MIB variables and their current values.
All MIBs are, in fact, part of one large hierarchical structure, with leaf nodes containing unique identifiers, data types, and access rights for each variable and the paths providing classifications. There is a standard path structure that includes branches for private subtrees. A portion of this structure is shown in Figure 1-2.
Each leaf of this tree provides the following information about one MIB variable:
The variable's name is intended to be descriptive, whereas the OID is a number that describes the path taken through the tree to reach that variable. For example, the variable named sysContact, identified by the OID 1.3.6.1.2.1.1.4 (meaning iso.org.dod and so on), is a read-write string variable that contains contact information about the administrator of the underlying system.
All objects contained under the mgmt branch of Figure 1-2 (in other words, all objects with OID's beginning 1.3.6.1.2) are considered standard and are tightly regulated by the Internet Engineering Task Force (IETF). For example, the standard RDBMS MIB lives under the mgmt branch and is supported by all relational database servers that claim to be SNMP-enabled. Oracle further adds its own MIB objects under the private branch to increase the manageability of its products. The following MIBs are specific to Oracle Services and are found under the {private.enterprise.oracle} branch:
SNMP is based on connectionless communication between the framework and the managed nodes. Because most management information does not demand reliable delivery, SNMP packets are transmitted from one node to a well-known address of another node, but no verification of successful delivery is made. The penalty for the light-weight, connectionless SNMP communication is paid by the management applications, which need to verify that SNMP transactions get completed successfully within a reasonable amount of time. If SNMP packets get lost in the network, the application cancels the associated transaction and possibly re-initiates it.
The most popular SNMP implementation uses the User Datagram Protocol (UDP) over the Internet Protocol (IP), although implementations also exist over other protocols, such as Novell's Internetwork Packet Exchange (IPX) and Apple's AppleTalk.
At the time of this writing, Oracle SNMP Support is provided for the following products:
On many platforms, an SNMP master agent is provided directly along with the operating system. This agent may or may not be compatible with the subagents Oracle provides (see "Master Agent").
This section discusses the general procedures for configuring SNMP for Oracle databases and Oracle Enterprise Manager. For more comprehensive configuration information, see the installation or configuration guide specific to your platform.
To configure the Oracle SNMP support on a managed node, follow the procedure outlined below:
The port is specified in the TRANSPORT section of the MASTER.CFG file located in the ORACLE_HOME\PEER\ADMIN directory.
For example, add the following section to the file:
TRANSPORT ordinary SNMP OVER UDP SOCKET AT PORT 161"
..
COMMUNITY section of the MASTER.CFG file.
COMMUNITY public ALLOW ALL OPERATIONS USE NO ENCRYPTION
Continue to Step 3 if the Encapsulator is to be used.
The port is specified in the SERVICES file located in the NT_HOME\SYSTEM32\DRIVERS\ETC directory.
For example, make sure that you have the following line in the file:
snmap 1161/udp snmp
ENCAPS.CFG, located in the ORACLE_HOME\PEER\ADMIN directory to specify which non-PEER master agents are to be encapsulated.
You must add at least an AGENT entry, including MIB-subtrees manageable by NMS, for the encapsulated master agent.
For example, you should have a section in the file. See the example below:
AGENT AT PORT 1161 WITH COMMUNITY public SUBTREES 1.3.6.1.2.1.1, 1.3.6.1.2.1.2, 1.3.6.1.2.1.3, 1.3.6.1.2.1.4, 1.3.6.1.2.1.5, 1.3.6.1.2.1.6, 1.3.6.1.2.1.7, 1.3.6.1.2.1.8, 1.3.6.1.4.1.77 FORWARD ALL TRAPS;
..
Monitoring consoles use an SNMP Master Agent to communicate with the Oracle Intelligent Agent. The SNMP Master Agent and the Oracle Intelligent Agent must be configured correctly before the Oracle Intelligent Agent can communicate over SNMP to the Master Agent.
The necessary SNMP files are installed along when you install the Oracle Intelligent Agent. After installing the Oracle Intelligent Agent, edit the following files as described below:
To edit the CONFIG.master file, find the line beginning with MANAGER and change the IPaddress coded in this line to match the IPaddress of the machine where the SNMP traps will be sent.
To edit the CONFIG.encap file, find the line AGENT AT PORT. It normally reads AGENT AT PORT 1161 WITH COMMUNITY public. If you modify the port number from 1161, you must also modify the start_peer script.
To edit the start_peer script, find the line NEW_SNMPD_PORT= and verify that it is using the same port number listed above in the CONFIG.encap file. Find the line NEW_TRAPD_PORT= and verify the port number is different than NEW_SNMPD_PORT=.
Add the following line to the file:
trap <hostname or ipaddress>
Replace the information in brackets with the actual hostname or IPaddress of the local host where the file is located.
ps command to find them, and the kill command to terminate the processes.
For example:
ps -ef | grep snmp
Checks to see if the SNMP Master Agent is running.
cd $ORACLE_HOME/network/snmp/peer su root ./start_peer -a
This command starts all three processes. Then use the ps command to determine if all three processes were started:
ps -aux |grep peer ps -aux |grep snmpd ps -ef | grep snmp
Load the Oracle MIBs according to the instructions provided in your SNMP Console configuration guide.
The necessary SNMP files are installed along when you install the Oracle Intelligent Agent. For information on configuring the Intelligent Agent, see the Oracle Enterprise Manager Configuration Guide.
To configure the SNMP Master Agent, follow the steps listed in "Using only an SNMP Console." Then do the following:
If the proper MIBs were loaded into the SNMP console, a trap will be sent to the SNMP Console whenever the event triggers.
