Database Reference
In-Depth Information
Management Service
The management service, or OMS, provides a user interface via the Enterprise Manager console and processes data
from agents. A loss of the OMS will result in a complete Enterprise Manager outage: agent uploads, jobs, incidents,
and notifications will all stop to function. The Oracle WebLogic Node Manager and the Oracle Process Manager and
Notification Server (OPMN) will attempt to restart the management service automatically if it is down. Although this
provides some benefit, it will not protect the OMS if the host is down. At a minimum, the OMS and repository should
be installed on separate hosts if possible. Multiple OMSs can be deployed behind a server load balancer to provide
protection against a single host being down. Also, you can opt to install the OMS on a shared filesystem, which will
provide passive failover in case of the loss of a single host. You will look at each of these options for protecting the
OMS in further detail.
Level 1—Separate OMS and Repository Hosts/No Redundancy
A level 1 configuration is composed of a single OMS and repository, with each installed on its own host. This
configuration provides the least protection, as failure of any host will result in a complete outage of the Enterprise
Manager system. Consideration should be given to the proximity between the OMS and repository, as high network
latency between the two can diminish performance. This configuration is recommended for all but the smallest of
configurations.
Figure
13-4
is a diagram of a level 1 high-availability configuration. Agents upload directly to the management
service host, while users interact with the OMS via the Enterprise Manager console or the command-line EMCLI
directly to the physical OMS host. If either the management service or repository database hosts become unavailable,
a complete outage will occur, resulting in loss of monitoring for targets. Keeping each component on its own server
reduces the likelihood of their impacting each other due to resource overhead. For example, increasing the database
parameters
sga_max_size and sga_target
could lessen the performance of the OMS because doing so reduces
the amount of memory available to the operating system. In addition, it lays the basis for a scalable environment as
business requirements dictate.
Figure 13-4.
Level 1 high-availability configuration with OMS and repository on separate servers
