OEM Grid Control 11gR1 architecture

As seen in Chapter 1 and in the earlier sections of this chapter, there are great demands on the functionality of an enterprise-wide infrastructure management solution. Not only should the centralized solution be capable of managing tens of thousands of physical entities spread across the landscape that forms the infrastructure, but it also must have the capability to model, monitor, administer, and configure higher-level logical entities that map to business functions. Apart from these, it must also be able to perform complex computations that assess the impact of the various targets on the business functions. Another often ignored demand on the management solution is to take into consideration the geographical spread of the infrastructure landscape. This spread means that data needs to be collected across geographies with differing time zones. Business service models that take into account targets spread across geographies must consider data normalization into a common time zone prior to any computation and impact assessment. The demands of these already complex computations are magnified when we take into consideration the scale of operations across the enterprise.

The key requirement of any management solution including OEM is to be able to provide and perform the above functionalities in a seamless manner. The above demands imply that the architecture must be capable of scaling and performing complex computations, but at the same time it must be simple enough for the administrators and must not overwhelm the enterprise. The success of any management solution will depend on its footprint within the enterprise. A successful management solution must be able to perform complex computations and scale very easily with a simple architecture and a small footprint.

The following image illustrates and introduces the high-level architecture of OEM 11gR1:

The key pieces of the architecture are as follows:

  • Oracle Management Agent (Agent): As implied by the name, this is a piece of software installed on a host. This software runs on the host and collects information about the targets on the host. The agent can also be configured to monitor targets on remote hosts. The collected data is then passed onto the management service.
  • Oracle Management Service (OMS): This is the brain of the OEM. This is a J2EE web application that provides the management functionality. It acts as the centralized management solution and also acts as the server to which all the management agents upload the collected data.
  • OEM Console: This is the user interface that exposes all the management functionalities to the end user of OEM. It's the interface through which the OEM and the end user communicate with each other.
  • Oracle Management Repository: This is the central repository that is used by the OMS to store all data. It hosts the complex schema that is used by the OMS to provide the management functionality.

The key parts of the management solution are the management agent, the OMS, and the management repository. The management repository provides the data storage to the OMS. The OMS provides current and future insights into business functions and services by looking at the historical data that is stored in this management repository. The OEM console application bridges the gap between the end administrative user and the OMS. It provides views into each of the targets and also allows the user to initiate actions and configuration changes on these targets.

As seen in the preceding screenshot, the Grid Control architecture is distributed in nature and relies on the agents to collect data on the individual hosts. This data is then transferred by the agent to the OMS and aggregated by the OMS at the enterprise level. The OMS has built-in logic that operates on the data to determine target states and performance. By distributing the data collection to individual agents the OMS is freed up to perform more important tasks. Let's now look at each of these architecture pieces in detail.

Oracle management agent

As seen in the pervious screenshot, the Oracle Management Agent is a local piece of software running on the host that needs to be managed. The agent is native to the host and it implies that the right agent needs to be downloaded and installed, based on the operating system (OS) installed on the host. The agent can either be installed manually on the host or using the OMS to push the agent onto it. In case the OMS push method is used then the host login credentials must be provided so as to enable a SSH access to the host.

Tip

In case of the OMS push method, to install the agent, the host login credentials must have sudo or administrative privileges so as to automatically run the root.sh file after the installation.

Once installed, the agent automatically discovers the host and itself as the two targets running on the host. In case other Oracle products are installed and registered in the local Oracle Inventory on the host, then these targets are also automatically discovered.

Local monitoring

In local monitoring, the agent is deployed on the host that it is collecting information about. Once installed, it can automatically discover the Oracle products that are installed. Any Oracle product when installed or patched will update this information into the Oracle Inventory. The agent upon its installation will parse this inventory to determine the installed set of products. Based on the product suite and its installed location, it automatically runs the relevant scripts to discover these as OEM targets and uploads this information to the OMS. Upon upload of this information it automatically starts monitoring these installed products.

Tip

In case of an automatic discovery of targets upon agent install, the OS user used to install the agent must have the necessary privileges to read the Oracle Inventory location. The discovery will fail and not proceed in case the required permissions are not present.

Remote monitoring

In the case of local monitoring, an agent is required on every host in the enterprise. This can be a burden on the administrator to not only install an agent on every host, but the agent process itself can consume precious memory and CPU cycles, thus impacting performance. Certain Oracle products, especially in the middleware arena, are built taking into consideration the enterprise management requirements. These products expose the necessary discovery, monitoring, and management capabilities remotely. The Fusion Middleware suite is an example of these kinds of products. In cases where only these products are installed on the host, an existing agent on a different host can be used to discover, monitor, and manage the installation.

In case of remote monitoring, there is no automatic discovery support and the administrator must use the console UI pages to initiate the remote discovery. However, once the discovery is performed, the agent automatically begins monitoring them.

Tip

Prior to remote discovery of middleware targets, the middleware servers must be enabled to accept remote management connections. Example: for remote discovery of WebLogic servers, the remote JMX connectors must be enabled.

Oracle Management Service (OMS) and console

The OMS is the brain of the entire Grid Control product. It provides all the functionality spoken in the context of Grid Control thus far. It is also responsible for managing all the communications with the Grid Control Agents. As an example, if an agent is uploading a large amount of data or is very slow to respond, it can disable the agent and indicate the same to the configured set of IT staff. The OMS is developed as a J2EE application and is deployed on the WebLogic server. The installation creates a WebLogic domain with an admin server and a managed server. The OMS application is deployed on the dedicated managed server.

The console application provides the necessary UI pages for the IT staff to interact with the Grid Control product.