24 Oracle Enterprise Manager 10g Grid Control Implementation Guide
and many other types of targets as well. It is best practice to run either Grid Control or Database
Control, but not both, although you can run both concurrently.
Grid Control vs. AS Control
How is Grid Control different from Application Server (AS) Control? In short, as just one of many
target types it monitors, Grid Control monitors the Oracle Application Server, whereas AS Control
administers the Oracle Application Server.
Grid Control Monitors Oracle Application Server
While Grid Control administers all Oracle products in your enterprise, it only monitors the Oracle
Application Server—both the AS bundled with Grid Control and any separate AS targets that Grid
Control monitors. Monitoring AS instances in the Grid Control Console encompasses real-time
monitoring, alerting, and historical data collection, just as with any other Grid Control target. For
example, the Application Servers tab within the GC Console reveals the status, alerts, policy
violations (noncompliance with a desired state for security, configuration, or storage), and resource
usage of all Application Servers and their subcomponents, as shown here.
Chapter 1: Overview of the Grid Control Architecture 25
AS Control Administers Oracle Application Server
By contrast, use the standalone AS Control Console to administer AS subcomponents. To get a
better understanding of what it means to administer the Application Server, take a look at the AS
Control Console home page, accessible directly at http://:1156 on UNIX or http://
:18100 on Windows, or through the Grid Control Console on the Application Server
home page using the Administer link.
From the AS Console home page, you can control OMS and non-OMS Application Server
subcomponents—the Oracle HTTP Server, OC4J instances, and Web Cache. This control is from
A to Z; you can stop, start, restart, enable, or disable subcomponents. You can also gather
information about the management software itself by clicking the Management link at the bottom
of the System Components section on the Application Server home page. The AS Console has
four other tabs: J2EE Applications (which allow you to view response times for OC4J instances),
Ports (which you can change through the UI), Infrastructure (including Identity Management and
OracleAS Farm Repository Management), and Backup/Recovery (of AS data and configuration
files). Without going into more detail, as Application Server Control is beyond the scope of this
book, I hope I’ve given you just enough information to make the distinction clear between Grid
Control and Application Server Control.
26 Oracle Enterprise Manager 10g Grid Control Implementation Guide
Agents for Grid Control, Database
Control, and AS Control
Now that we are clear that Grid Control, Database Control, and Application Server Control
are all distinct, you’re probably not surprised to hear that separate Agents exist for each. The
Grid Control central Agent on each managed host (including OMS and OMR hosts) monitors
all targets on that host and uploads target information to the SYSMAN schema in the
Management Repository.
NOTE
In this book, Management Agent or Agent refers to the central
Grid Control Agent.
The Database Control Agent, on the database host, similarly stores data in a SYSMAN
schema, but this schema is local to its associated Oracle database. In contrast to both Grid
Control and Database Control Agents, the Application Server Control Agent, bundled with the
Oracle Application Server, only communicates real-time data internally to the Application Server
Control, as there is no Repository for historical data. All three Management Agents are distinct.
They run from their respective home directories—the Grid Control Agent from its own Agent
home, the Database Control Agent from the database home, and the Application Server Control
Agent from the Application Server home including that for the OMS.
Grid Control, Database Control, and
AS Control: All Together Now
Let’s build on the topology of Grid Control core components shown earlier in Figure 1-2 by
adding Database Control and Application Server Control to the mix, as represented in Figure 1-4
(I’ve omitted protocols for clarity).
I have also included four typical managed targets: a 10g Database Server, a 10g Application
Server, an 8i/9i Database Server, and a third-party application. For good measure, the figure
illustrates two OMS hosts, with two of the central Agents uploading management data to one of
the OMS hosts, and the remaining two Agents uploading to the other OMS host.14 In addition, a
Grid Control Console communicates with an OMS, which also receives Agent uploads of target
metric data. Although each OMS only receives data from the particular Agents that report to it,
each OMS uploads this data to a central Management Repository, which in turn makes
information from all Agents available to each OMS. This allows any GC Console to administer or
monitor all Grid Control targets. On the other hand, a particular Database Control Console is in
contact with just one database, and likewise, a particular AS Control Console connects with just
one Oracle Application Server. The Database and AS Consoles are privy only to local database
and Application Server data, respectively. All three Consoles can operate concurrently, but (as
already stated) it is best to shut down Database Control when using Grid Control, as Grid Control
can administer each of the databases to which a particular Database Console has access.
14
In a high availability configuration, as discussed in Chapter 15, rather than assigning Management Agents to
particular Management Services, you would use a hardware server load balancer to virtualize the Management
Services and shared storage to allow for failover between them.
Chapter 1: Overview of the Grid Control Architecture 27
Oracle
Management
Repository
Firewall
Oracle
Oracle Management
Management Service
Service
Adminis- Adminis- Adminis-
tration tration tration Monitoring Firewall
Central Central Central Central
Agent Agent Agent Agent
Grid Control Grid Control
Console Console
Oracle 10g Oracle 8i/9i 3rd-Party Oracle 10g
Database Database Application Application Adminis-
Server Server Server tration
Database AS Control
Monitoring Control Agent Agent 10g Application
10g Database Server Control
Control Console Managed Targets
Console
FIGURE 1-4. Grid Control, Database Control, and AS Control
Each Application Server Control Console should remain available, however, to administer a
particular Application Server, because Grid Control can only monitor an Application Server.
I hope all this makes the distinction clear between Grid, Database, and AS Control.
Summary
Here is a synopsis of what was covered in this introductory chapter:
■ We would be remiss if we made no mention of grid computing technology, which Grid
Control was designed to administer. I began this chapter by presenting a brief overview
of grid computing.
■ Next, I provided a brief history of Grid Control and highlighted several product features.
■ From there, I introduced you to the four main Grid Control components: the Console,
Agent, OMS, and Repository.
28 Oracle Enterprise Manager 10g Grid Control Implementation Guide
■ I then broke down the main GC middle-tier components into subcomponents, and
examined the interaction between all GC components. You saw how components work
together to satisfy Console requests and upload metric data from the Agent on a target
host through the OMS to the Repository, and how the OMS in turn delivers data back to
the Agent.
■ I ended this chapter with an ancillary but critical explanation of how Grid Control differs
from Application Server Control and Database Control. This delineation helps further
refine the scope of the book to just Grid Control and Application Server Control as it
relates to Grid Control.
Now that you understand the basic architecture and concepts of Grid Control, we can
proceed to Chapter 2, where we’ll meet in the garage for preinstallation. Then, in Chapter 3,
we’ll install Grid Control and get this thing on the road.
Chapter
2
Grid Control
Preinstallation
29
30 Oracle Enterprise Manager 10g Grid Control Implementation Guide
I
n Chapter 1, you got a feel of the workings of the Grid Control “engine” by
becoming familiarized with its components (and subcomponent) and examining
how they work together to process Agent management data and Console requests.
In this chapter, we prep the engine, and in Chapter 3, we begin building it. The
preinstallation steps discussed here are necessary to install a basic GC environment,
which consists of an Oracle Management Repository (OMR) database (single-instance or RAC)
servicing one or more Oracle Management Service (OMS) hosts that in turn talk to Oracle
Management Agents (OMAs) on each target host. You will prepare to install the OMR database
and one OMS either on the same host or on separate hosts, in close proximity to one another (i.e.,
in the same data center and preferably on the same subnet). I also provide sizing guidance and
instructions for deploying additional Active OMSs on separate hosts.
NOTe
This chapter is for setting up Active/Active OMS and Repository (i.e.,
RAC) installations. See Chapter 15 now if interested in implementing
an OMS or OMR Active/Passive configuration using Cold Failover
Cluster (CFC) as each requires a special Grid Control installation
procedure.
Let’s take a look at how the preinstallation tasks are organized in this chapter. They fall into
the following four major categories:
■ Architectural design The first preinstallation step is to make the minimum number
of design decisions required to install a basic GC environment, which can serve as a
common denominator for any high availability and disaster recovery topology to be
implemented when we get to Chapter 15 (except CFC configurations, which you must
implement when installing GC).
■ Network configuration After fleshing out the basic architecture, confirm the network
configuration, including host naming rules and constraints and connectivity checks
between GC component nodes.
■ Hardware requirements Provide the hardware resources (disk space, RAM, swap, and
CPU speed) for OMR and OMS hosts to meet Grid Control installation and operating
requirements.
■ Software requirements Confirm that GC meets all certification standards, create the
necessary OS groups, users, and directories, stop listeners on port 1521, synchronize OS
timestamps/time zones, and satisfy all platform-specific software requirements.
The preinstallation tasks in this chapter apply to the hosts where the OMR, OMS, and chain-
installed Agents will be installed, as well as to hosts where standalone Agents will be installed.
Chapter 2: Grid Control Preinstallation 31
Stage the Grid Control Software
OMR, OMS, OMA
In the inimitable IT multitasking fashion, I advise that you begin downloading and staging
the GC software while carrying on with the remaining preinstallation steps. You’ll need to
stage the distribution soon enough anyway to run the prerequisite checker, as described
shortly. To stage the GC software, you must obtain it, then set up access to run the installer
on the chosen host. The method of access varies depending upon whether the target system
is local or remote. There are two ways to obtain the Oracle Enterprise Manager 10g Grid
Control distribution software for a particular platform: download it from OTN or order the
Grid Control Media Pack from the Oracle Store. (Even if you order the Media Pack, you still
need to download the latest Patch Installer, which is not included.)
■ Download from OTN Download the latest full GC software release for your
platform from the Oracle Technology Network (OTN) Web site at http://www
.oracle.com/technology/software/products/oem/index.html. Make sure to select
the link under the Full Installers section for the latest full installation available for
your platform.1 The Full Installers contain the OMR, OMS, OMA, and Management
Packs, whereas the Patch Installers only contain the OMS, OMA, and Management
Packs. No platforms currently offer Full Installers for the latest GC release. Therefore,
you need to download the Full Installer archive for an earlier release, and the
Patch Installer archive for the latest release (applied in Chapter 4). The Full Installer
archives consist of one or more zip files, depending upon the platform, ranging from
1.3G on Windows to 4.3G on HP-UX Itanium. Download all zip files and unzip
them into the same staging directory (it creates its own directory structure).
■ Order the Media Pack Alternatively, order the latest Enterprise Manager 10g Grid
Control Media Pack for a particular platform from the Oracle Store for a nominal
fee. To order the Media Pack, go to http://oraclestore.oracle.com, choose your
country, click the Media Packs link on the left navigation pane, select the platform,
select the Enterprise Manager Media Pack, click Add to Cart, Checkout, and
follow the checkout procedures. The Media Pack for each OS contains the base
EM distribution and the Monitoring plug-ins (discussed in Chapter 11). When you
receive the Media Pack, you can either run the DVD-ROMs directly or stage them
on disk.
Whether you download the distribution software or order the Media Pack, you also
need to download the Agent software for managed host platforms other than your OMS
platform. Download this Agent software under the Mass Agent Deployment section of the
OTN site indicated above for Enterprise Manager.
Once you obtain the GC software from either one of these sources, you can access the
software via several methods, depending on whether the target system is local or remote.
(Continued )
1
1
I assume here that you are doing a fresh GC installation. If you need to upgrade a GC 10.2.0.X or 10.1.0.X
installation, see the latest Patch Installer README or release notes for your platform.
32 Oracle Enterprise Manager 10g Grid Control Implementation Guide
If the target system is local, access the GC software directly on that system. On
Windows platforms, no further action is required to run the installer locally. On UNIX
platforms, run the installer either from an Xwindows session or from a UNIX workstation.
If the target system is remote, access the GC software from a remote DVD drive or use
remote access software, as follows:
■ Access the GC software from a remote DVD drive (UNIX only). If the system where
EM is to be installed does not have a DVD drive, you can share a remote DVD
drive.
■ Access the GC software using remote access software. If you don’t have physical
access to a remote system where installing GC, but this system has a local hard
drive, you can install GC using remote access software such as Microsoft built
Remote Desktop Connection, VNC from RealVNC Ltd., or Hummingbird Exceed.
Start the remote access software on both your local computer and the remote
system and install GC in one of the following ways:
■ Copy the GC software to a hard drive and install from that hard drive. To do
this, share the hard drive, then using the remote access software, map a drive
letter on the remote system to the shared hard drive.
■ Access GC software from a DVD drive in your local computer. Insert the DVD
into a drive on your local computer and share the DVD drive. Use the remote
access software to map a drive letter on the remote system to the shared DVD
drive. You are now set up to run the Oracle Universal Installer (OUI), as
described in Chapter 3, from the shared hard drive on the remote host using the
remote access software.
On most UNIX systems, a DVD disk mounts automatically when inserted into the disk
drive. In case the DVD is not automatically mounted, the following lists the command to
set the mount point for each UNIX platform (execute as root):
AIX HP-UX Red Hat Linux SUSe Linux Solaris
/usr/sbin/mount /usr/sbin/mount mount -t nfs mount -t nfs /usr/sbin/mount
-rv cdrfs
See the platform-specific GC documentation for more detailed instructions on mounting
the product disks.
Chapter 2: Grid Control Preinstallation 33
How do chain-installed Agents (as referred to in the Oracle EM documentation) differ from
standalone Agents?
■ Chain-installed Agents You do not explicitly install these Agents; their installation is
bundled with that of an OMS . The Agent accompanies the OMS, “tags along for the
ride,” so to speak, to monitor the OMS as well as the Repository (if installed on the
same host) and any other host targets. Chain-installed Agents don’t have any distinct
prerequisites beyond those for the OMS they accompany.
■ Standalone Agents You explicitly install these Agents on each target host (except
on OMS hosts where Agents are chain-installed) using one of six methods covered
in Chapters 5, 6, and 7. Some of the preinstallation steps for the OMS also apply to
standalone Agents, as indicated in this chapter.
Standalone Agent and chain-installed Agent installations, once completed, are identical. Each
plays the role of a central Agent that GC needs to manage a particular target host.
In this chapter, I annotate all preinstallation tasks with OMR, OMS, and/or OMA (for any
Agent installation method) to indicate on which host(s) to execute the task. Complete all OMR
and OMS requirements now on the OMR node(s) and OMS hosts, respectively. (You can repeat
the OMS tasks covered in Chapter 15 for any additional OMS hosts you may install then for high
availability reasons.) You can either complete the standalone OMA requirements on all target
hosts concurrently, or wait and circle back to them when you get to Chapter 5, which lists
additional prerequisites for standalone Agents. Most administrators are anxious to install the OMR
and OMS and don’t want to concurrently perform certain preinstallation steps for standalone
Agents on all target hosts. If you feel this way, then, as the wizard says in The Wizard of Oz, “Pay
no attention to that man behind the curtain,” i.e., “Pay no attention to those standalone Agent
requirements in Chapter 2.” (My quote doesn’t have the same ring to it, but you get the idea.) You
can certainly wait to take care of these Agent requirements all at once when you get to Chapter 5.
Don’t worry; I will remind you.
NOTe
Again, the OMA annotations below indicate standalone (i.e., central)
Agent preinstallation steps for any Agent method. You can elect to
postpone these steps until Chapter 5, as they are not required for the
Agent chain-installed with the OMS in this chapter.
While many of the preinstallation steps apply generically to all operating systems, the commands
to verify or fulfill some of these steps differ by platform. Where the syntax varies, I provide the
variations for Windows and all flavors of UNIX.
Key Architectural Design Decisions
Grid Control preinstallation starts with design. This book splits that design into two stages: build a
stock GC engine (described in this chapter), then “sup’ up” this engine to meet high availability
(HA) and disaster recovery (DR) requirements (covered in Chapter 15).