Oracle SNMP Agent Architectural Models

The following sections describe the agent/subagent architectural models supported by Oracle SNMP Agent:

•	Architectural Models Identified

•	Simple SNMP Agent Model

•	SNMP Master Agent/ Subagent Model

•	SMUX Master Agent/ Subagent Model

Architectural Models Identified

Oracle SNMP Agent supports three architectural models: the simple SNMP agent model, the SNMP master agent/ subagent model, and the SMUX master agent/ subagent model. The latter two models, as well as the combination of the latter two models, are made possible by the SNMP master agent and SMUX master agent capabilities provided by the Oracle SNMP Agent Integrator (snmp_integrator). The SNMP multiplexing (SMUX) protocol is defined in RFC 1227.

By providing the Oracle SNMP Agent Integrator and supporting the SMUX protocol, Oracle SNMP Agent is able to support multiple SNMP agents and subagents from any vendor to operate on the same machine and appear as a single SNMP agent to the SNMP management console.

Simple SNMP Agent Model

The simple SNMP agent model, shown in Figure 2‑1, applies when managing a single Tuxedo application (domain) running on the managed node.

Figure 2‑1 Single SNMP Agent Running on a Managed Node—Example

With this model, the tux_snmpd process is started with the -s option in the startup command (tux_snmpd -s) to configure the process as an SNMP agent—as opposed to a SMUX subagent.

Including the -c option in the tux_snmpd startup command (tux_snmpd -s -c) enables users to run only one Tuxedo SNMP agent on the master node of a Tuxedo domain, to simplify management of multiple-node domains and to enable data collection from hardware platforms not directly supported by the Oracle SNMP Agent software. When the -c option is specified, the agent becomes central for the entire Tuxedo domain and is enabled to gather information from all nodes involved in the domain.

SNMP Master Agent/ Subagent Model

The SNMP master agent/ subagent model, shown in Figure 2‑2, applies when managing different types of system or network resources on the managed node. This model does not apply to managing multiple instances of the same type of resource; for example, you cannot use this model to manage multiple Tuxedo domains running on the same managed node.

Figure 2‑2 Multiple SNMP Agents Running on a Managed Node—Example

Note:

The SNMP agents must be started before starting the Oracle SNMP Agent Integrator.

With this model, communication between the SNMP manager and the SNMP agents is handled by the Oracle SNMP Agent Integrator SNMP master agent capability. The Oracle SNMP Agent Integrator distributes the requests from the SNMP manager to specific SNMP agents, receives the responses from the individual agents, and forwards those responses back to the SNMP manager.

Starting tux_snmpd Processes as SNMP Agents

Each tux_snmpd process is started with the -s option to configure each tux_snmpd process as an SNMP agent—as opposed to a SMUX subagent. SNMP agents running under the Oracle SNMP Agent Integrator are also known as non-SMUX peer agents.

Managing a Tuxedo Domain

With the SNMP master agent/ subagent model, one and only one of the managed resources on the managed node may be a Tuxedo domain. The tux_snmpd process targeted to manage that domain may be started with the -l logical_agent_name option to assign the process a name other than the default name “tux_snmpd.” The -l logical_agent_name option or the default name “tux_snmpd” allows an administrator to associate the tux_snmpd process with the Tuxedo domain that the process is to manage.

Also, as described in “Simple SNMP Agent Model” on page 2‑2, if the managed node is the master machine for the Tuxedo domain, including the -c option in the startup of the associated tux_snmpd process enables that process to manage the entire domain.

SMUX Master Agent/ Subagent Model

The SMUX master agent/ subagent model, shown in Figure 2‑3, applies when managing different types of system or network resources on the managed node. This model also applies to managing multiple instances of the same type of resource; for example, you can use this model to manage multiple Tuxedo domains running on the same managed node.

Figure 2‑3 Multiple SMUX Subagents Running on a Managed Node—Example

Note:

The Oracle SNMP Agent Integrator must be started before starting the SMUX subagents.

With this model, communication between the SNMP manager and the SMUX subagents is handled by the Oracle SNMP Agent Integrator SMUX master agent capability. The Oracle SNMP Agent Integrator distributes the requests from the SNMP manager to specific SMUX subagents, receives the responses from the individual subagents, and forwards those responses back to the SNMP manager.

Starting tux_snmpd Processes as SMUX Subagents

Each tux_snmpd process is started without the -s option to configure each tux_snmpd process as a SMUX subagent—as opposed to an SNMP agent. SMUX subagents use the SNMP multiplexing (SMUX) protocol defined in RFC 1227 to communicate with the Oracle SNMP Agent Integrator.

Managing Multiple Tuxedo Domains Concurrently

With the SMUX master agent/ subagent model, multiple Tuxedo domains running on the managed node may be managed concurrently. To do so, an administrator starts a SMUX subagent for each domain. And for each SMUX subagent, the administrator specifies the -l logical_agent_name option at startup to associate the tux_snmpd process with the Tuxedo domain that the process is to manage.

The SNMP manager running on the management station uses an address of the following form to send requests to a particular SMUX subagent:

community_name@logical_agent_name

Where community_name is the read-only community name for Get requests, and the read-write community name for Set requests; and logical_agent_name is the name of the agent to which the SNMP request is intended. For example:

public@simpapp_agent

Also, as mentioned in “Simple SNMP Agent Model” on page 2‑2, if the managed node is the master machine for a Tuxedo domain, including the -c option in the startup of the associated tux_snmpd process enables that process to manage the entire domain.