Oracle Enterprise Manager 10g Grid Control Implementation Guide P2

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

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://<AShost>:1156 on UNIX or http://

<AShost>: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 Chapter 1: Overview of the Grid Control Architecture 27

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

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

FIGURE 1-4 Grid Control, Database Control, and AS Control

Grid Control Console

Oracle Management Repository

Oracle Management Service

10g Database

Control Console

10g Application Server Control Console

Oracle 10g Database Server

3rd-Party Application ApplicationOracle 10g

Server Managed Targets

Firewall

Firewall

Oracle 8i/9i Database Server

Oracle Management Service

Central Agent

Central Agent

Central Agent

Central Agent

Grid Control

Console

Adminis-tration

Monitoring

Adminis-tration

Database Control Agent AS ControlAgent Monitoring

Adminis-tration Adminis-tration

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

2

Grid Control Preinstallation

29

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 chain-installed, as well as to hosts where standalone Agents will be chain-installed

I

Chapter 2: Grid Control Preinstallation 31

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.

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 )

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

-rv cdrfs <DVD

device name>

<disk mount

point directory>

/usr/sbin/mount -F cdfs -o rr

<DVD device name> <disk mount point directory>

mount -t nfs

<hostname>:/

mnt/<DVD_

path>

mount -t nfs

<hostname>:/

media/<DVD_

path>

/usr/sbin/mount

-r -F hsfs <DVD

device name>

<disk mount point directory>

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)