Oracle Enterprise Manager 10g Grid Control Implementation Guide P2

Chia sẻ: Vong Phat | Ngày: | Loại File: PDF | Số trang:10

Thêm vào BST

Báo xấu

129
lượt xem 11
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

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.

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: Oracle Enterprise Manager 10g Grid Control Implementation Guide P2

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).