Release 8.0.5
A64404-01
Library |
Product |
Contents |
Index |
| Oracle
SNMP Support Reference Guide
Release 8.0.5 A64404-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:
The MIB HierarchySNMP 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 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
|
Note:: If an entry for SNMP already exists in the file, change the port from 161 (default number) to another available port (1161 in this example). |
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;
..
|
Note:: The port (1161 in this example) must match the one you specified in Step 3. |
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.
For example:
ps -ef | grep snmp
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.
