6
Management Server and Intelligent Agent

Enterprise Manager, Release 2.1 deploys a Management Server and an Oracle Intelligent Agent to allow clients to manage objects, such as databases, listeners, nodes, and additional discovered services.

• Oracle Intelligent Agent

• Management Server

Oracle Intelligent Agent

The Oracle Intelligent Agent is a daemon-like process running on a remote node 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 are responsible for:

• Providing local services or calling operating system dependent services to interact locally with the managed targets.

• Running jobs, collecting their results and output, and queueing them for the Management Server.

• Checking for events, and queueing the resulting event reports for the Management Server.

• Returning job and event reports to the appropriate Management Server.

• Canceling jobs or events as directed by the Console or other applications.

• Handling Simple Network Management Protocol (SNMP) requests, if SNMP is supported on the agent's platform.

For information on configuring the agent, see the Oracle Enterprise Manager Configuration Guide and the Oracle server platform-specific installation documentation for your system. For information on general Intelligent Agent operation, troubleshooting and Tcl scripting, see the Oracle Intelligent Agent User's Guide.

Characteristics

Intelligent Agents are autonomous because they function without requiring that the Console or Management Server be running. An agent that services a database can run when the database is down, allowing the agent to start up or shut down the database. The Intelligent Agents can independently perform administrative job tasks at any time, without active participation by the administrator. Similarly, the agents can autonomously detect and react to events, allowing them to monitor the system and execute a fixit job to correct problems without the intervention of the administrator.

The agents operate independently and are able to execute jobs and monitor events when the administrator has logged out of the Console and/or the Management Server has been shut down. The agents queue any job or event messages destined for that administrator, and deliver them when the administrator logs in to a Console again. Information about jobs and events are stored in files on the agent's node.

Note:

The agent queues a maximum of 500 messages. After the limit is reached, the oldest messages are dropped.

Event and Job Support

The agents are responsible for executing jobs and monitoring for events. Jobs and events are implemented as Tcl scripts. When the agent executes a job or tests for an event, it runs the appropriate Tcl script. Because jobs can be long-running or complicated tasks, such as a database backup job, the agent does not execute the job in its process space. Jobs are run in a separate process. When the job is completed, the agent sends the results to the Management Server. In contrast, event scripts are typically run directly by the agent. Event scripts are used for detecting exceptions and are expected to have short execution times.

Network Encryption

Network encryption for communication between the Management Server and Agent can be accomplished with the Advanced Networking Option (ANO) option of Net8. ANO uses a sophisticated algorithm to provide encryption on the Transparent Network Substrate (TNS) connections. For information on ANO, see the Net8 Administrator's Guide. For SQL*Net installations, network encryption can be accomplished with the Oracle Secure Network Services (SNS) option.

SNMP Support

The agents support SNMP, so applications can communicate directly with the agent using SNMP protocol. The agents provide access to Oracle's database Management Information Base (MIB) variables. Although the agent supports SNMP, the Management Server does not use that protocol to communicate with the agent. You can submit jobs or events that access Oracle MIB variables even when the database resides on a platform that does not support SNMP. For more information on SNMP, see the Oracle SNMP Support Reference Guide.

Management Server

The Management Server communicates with first tier clients, then processes all system management tasks, administrates the distribution of these tasks across the entire network system to the Agents, and provides scalability across the system. The Management Server uses a repository as persistent storage to maintain system data, application data, and state for many entities distributed throughout the architecture. The Management Server is responsible for such activities as:

• Communicating with agents on nodes to schedule and manage jobs.

• Communicating with agents on nodes to submit and monitor events.

• Queueing operations that fail and retrying them periodically.

• Discovering the network services in the system.

The Management Server is implemented as a multi-threaded process. For example, separate threads in the Management Server perform activities such as submitting jobs and events to agents, discovering new services in the network, or receiving messages from agents. Because the Management Server's threads operate independently, the Management Server can perform various operations simultaneously and perform efficiently in large busy distributed environments.

Communication between the Management Server and the agents is vital to the Job and Event systems. The Management Server must be able to send messages to the agents in order to submit jobs and events. The agents must be able to send messages to the Management Server to report results and status messages for the jobs and events.

The Management Server uses CORBA to communicate with components of the Oracle Enterprise Manager system. When the Management Server communicates with V1.x Oracle Intelligent Agents, an Agent Gateway is used. The Agent Gateway and V1.x agents communicate using Oracle Remote Operations, which is a remote procedure call mechanism based on the Transparent Network Substrate (TNS). The Management Server and agents can also use Oracle Secure Network Services (SNS) to maintain the security of their network transmissions.

Message Queues

The Management Server and agents use message queues for the messages they send. Using queues ensures that no messages are lost even when the Management Server or agent is down. The Management Server maintains several queues for messages. The operations queue contains job and event requests sent by the Console. For example, when you submit a new job to the Job system, the Console queues the new job request on the Management Server's operations queue.

Failed Queue

When the Management Server retrieves a job or event request from its operation queue, it tries to contact the agent that should receive the request. If it cannot contact the agent, the Management Server places the request in its failed queue. Periodically the Management Server tries to contact the agent which is responsible for the operation request in the failed queue. If the Management Server successfully contacts the agent, the operation request is removed from the failed queue and sent to the responsible agent.

Notification Queue

The Management Server maintains a notification queue for job and event notification. The notification queue contains messages about the status of jobs and events. When the Management Server receives a message from an agent regarding a job or event, it places the message in the notification queue. When the Management Server changes the status of a job or event it also places a message in the queue.

For example, when the Management Server has successfully submitted a new job to an agent, it places a message in the notification queue updating the job's status to submitted. Messages in the notification queue are used to update the job and event information stored in the repository.

Connection Cache

In order for an Management Server and an agent to pass messages, they must establish a connection. Rather than requiring that the Management Server or agent create a new connection each time it wants to send a message, the Management Server maintains a cache of connections. If a connection is needed and it already exists in the cache, it can be reused. This reduces the overhead involved in creating new connections. Connections in the cache are aged out using a least recently used algorithm.