The Enterprise Manager product is built using Java technology and an Oracle database. The Enterprise Manager product runs on top of Oracle Application Server and uses an Oracle Database as its persistence store. Enterprise Manager has three main components:
For user interactions there is a centralized console that operates upon the Management Repository and uses services provided by the Management Server. This is a browser-based console.
In a typical setup, one management agent needs to be installed (on each host to be managed) that uploads data to the Management Server and that, in turn, persists the data in the repository. A system administrator can access this data or initiate or schedule an operation though the console. The next diagram shows a sample setup of the Enterprise Manager:
Before we get into the details of each component, one Enterprise Manager term, target, should be introduced. Target is very central for the EM system and everything moves around various target models.
Target is a generic term that refers to any managed entity that is managed by Enterprise Manager. For each target there is a model of the target stored in the Enterprise Manager repository. There are various target types available out-of-the-box like target types for a WebLogic server, or target types for BPEL Process Manager. The target model contains all the properties needed for managing the target. For example, a model for the WebLogic server contains JMX URL and credentials to connect to JMX server. The target model also defines what metrics should be collected for a target, the associated thresholds for those metrics and the collection frequency for those metrics.
At a broad level, targets are of two types — the agent target, and the repository only target. Agent targets are the target models that get created as the end result of the discovery process. The agent and the repository maintain the definition and model of such targets. Metrics for such targets are collected by the agent and uploaded to the repository. The repository only targets are targets that get created only in the repository — they may get created as part of the discovery process or they may be created manually. All of the metric calculations of such targets are done in the repository. For example, WebLogic Managed Server is modeled as an agent target and WebLogic Domain and WebLogic Cluster are modeled as repository only targets.
OMS is a central process for Enterprise Manager. It provides a set of common services that help in the monitoring and management of a target. Some of those services are job scheduling, notification, and so on. OMS collects data from all of the agents and, after processing, persists it into the repository. For other system management operations like backup recovery, OMS orchestrates the sequence of events that need to be triggered on the agent for a given target.
OMS also communicates with the agent over HTTP/HTTPS protocol and uses JDBC to persist data in the repository.
The Oracle Management Agent process is a proxy process for Enterprise Manager that collects data from targets and sends it to the Management repository. Generally it is co-located on the same host where a target is running. In this book we will use the terms OMA and agent interchangeably.
The agent keeps the target model synchronized with the actual target. It also collects monitoring and configuration information as per the target model, and uploads it into the Management repository via services exposed by the Management service. This collection of information is done as per the collection frequency defined by the target model. During collection, metrics are evaluated against the thresholds defined in the target model. In case metric values violate the thresholds, the agent generates an alert and sends it to the Management Server.
The agent executes all of the operations that are triggered from OMS, at the end of the operation the agent returns the status and output of such operations, for example, a "start WebLogic server command" triggered from OMS is delegated to the agent, after completion the agent sends the status and output of such commands back to OMS.
Besides monitoring, the agent executes all of the operations that are scheduled from OMS, and returns the status and output of such operations, for example, the agent executes a start-stop operation scheduled from OMS and returns the status and output of that operation.
Agents use a heartbeat mechanism to keep the Management Server informed about the health of agent. The agent communicates with the Management Server over HTTP/HTTPS protocol. In more secure setups, agents need one password to communicate with the management service.
OMR is the persistence store for all EM data. All data related to target models, performance metrics and configuration metrics are persisted in the OMR. OMR also keeps historical data that can be used for analyzing the performance of the system over a period of time. Historical data related to configuration can be used to track configuration changes. OMR is built using an Oracle Database.
Some data from the Oracle Management Repository is exposed via public views and can be used for integration with external systems. The repository can be installed in a pre-existing database or a new database.
In this book, we will use the terms Oracle Management Repository and repository interchangeably.
The Enterprise Manager Console is a browser-based interface where the user can view all the data from the management repository in useful formats like performance analysis charts, availability reports, and so on. Using the same console, administrators can schedule and monitor various operations like backup recovery, patching, and so on.
As Enterprise Manager becomes a central point for managing and monitoring a complete IT infrastructure, the availability of Enterprise Manager itself is extremely critical. To support the high availability of OMS, Enterprise Manager supports a configuration where two or more OMSs are configured in active mode. To support high availability of the persistence store Management Repository can be setup to work with Oracle Real Application Cluster (RAC) database.