About the Oracle Cloud Control 12c Components

By Michael New, Edward Whalen, Matthew Burke on October 30, 2015


The basic Cloud Control topology consists of four core components, as depicted in Figure 1: the Cloud Control Console, the Oracle Management Agent, the Oracle Management Service, and the Oracle Management Repository. Each component can be separated by a firewall.

 

fig1-1
FIGURE 1.   Topology of Cloud Control core components
Following is a brief description of each core component.
  • Cloud Control Console   The Cloud Control Console is a browser-based application through which administrators can centrally manage their entire computing environment. If you had to choose one image to define the big picture for Cloud Control, it would have to be the Console home page:
p9-01

 

The home page displays an overall view of your managed IT infrastructure from which you can drill down to a specific managed target that Cloud Control administers. The CC Console is certified to run on all popular browsers, including Internet Explorer, Firefox, Safari, and Google Chrome, and to use the Adobe Flash Player plug-in for certain Console functionality. You don’t install the Console; the Management Service renders it. You just open a browser and connect to the Console via the Enterprise Manager login URL.

 

  •  Oracle Management Agent   The Management Agent, installed on each managed host, monitors the host and all targets on that host, and communicates information about these targets to the OMS. Targets can be Oracle and non-Oracle components installed on the host. Cloud Control monitors over 200 different target types; each instance of a particular target type counts as a monitored target. Examples of commonly used target types are Database Instance, Listener, Oracle Application Server, and Host.
Management plug-ins permit monitoring of specific Oracle and non-Oracle target types. In Grid Control 10g and 11g, certain target types bundled with the product are now packaged as plug-ins in CC 12c. This allows the Oracle EM development team to update plug-in software for target types independently of the CC release. Plug-ins are both Oracle-built and partner-built. Oracle-built plug-ins exist for Oracle products, of course, but also for many non-Oracle products, including Microsoft SQL Server, Microsoft Active Directory, NetApp Filer, and IBM WebSphere Application Server. Partner-built plug-ins are available for other non-Oracle components typically found in today’s data centers, including F5 BIG-IP LTM, Citrix Presentation Server, and Brocade ServerIron System.
Cloud Control monitors itself, so an Agent also runs on all nodes hosting the Oracle Management Service and Management Repository. Each managed host (or virtual host) runs one and only one Agent. (Agents in Cold Failover Cluster [CFC] environments run multiple Agents, one for each cluster node, and one for the virtual host itself.) You can have as many Agents as you can scale the Cloud Control infrastructure to support, which is practically capped only by network speeds as limited by geography. Oracle certifies the Agent for the latest current 12c release (12.1.0.2) on the most common 32-bit and 64-bit host platforms, including Linux x86-64 and x86 (RHEL, OEL, SLES, and Asianux), Oracle Solaris on SPARC (64-bit), Oracle Solaris on x86-64 (64-bit), IBM AIX on POWER Systems (64-bit), IBM Linux on System z Windows (x64 and x86), and HP-UX (Itanium, PA-RISC).
  • Oracle Management Service   The OMS is a Java 2 Platform Enterprise Edition (J2EE) middle-tier application that renders the user interface for the Console. Agents upload target-related data to the OMS, which then processes this data before uploading it to a data store, the Oracle Management Repository. The Cloud Control middle tier consists of an Oracle WebLogic Server 10.3.5 instance, which deploys the Management Service J2EE Web application.

You must install the OMS on at least one or more hosts as needed to support your environment for scalability or high availability. Each Management Service must reside on its own host. The OMS and Management Repository can reside on the same host, but for performance reasons, Oracle does not recommend this configuration for a production Cloud Control environment, unless it is small (fewer than 1,000 targets). All physical OMS hosts independently provide the generic Oracle Management Service, though multiple OMS hosts with a Shared Directory can coordinate to process Agent upload files to this directory.

At the time of this writing, the OMS was certified to run on Linux x86-64 and x86, Oracle Solaris on SPARC (x64), Oracle Solaris on x86-64 (64-bit), IBM AIX on POWER Systems, and Windows x86-64. Plans are to certify the OMS on Windows x86 and HP-UX (Itanium, PA-RISC), which are already certified for the Agent.

  •    Oracle Management Repository   The Repository (OMR) is the data store for Cloud Control, created either during the CC installation in a pre-installed Oracle database or by the EM template in DBCA when creating the database. The Repository is located in the SYSMAN schema, which contains information on all Cloud Control targets and administrators. The Repository organizes this data so that the OMS can retrieve and display it in the Console for any administrator with privileges to view it. A Cloud Control infrastructure uses just one central Repository database. It can be a single-instance or RAC Oracle database, releases 10gR2 (10.2.0.5), 11gR1 (11.1.0.7.0), or 11gR2 (11.2.0.1+), although Oracle Database 11.2 is recommended.
Console administrators and Agents communicate with the OMS, via ad hoc and batch connections (except alerts), using the following network protocols, respectively:
  • An administrator requests content in the Console over HTTP(S) in a browser session, which the OMS renders. The OMS then retrieves the data for the request from the Management Repository and displays it in the Console.
  • Agents upload information to the OMS over HTTP(S), and the OMS uploads this data via thin JDBC to the OMR. The OMR sends data back to the OMS over thin JDBC, which is relayed to the Agent via a built-in HTTP listener.

Related Posts

Leave a Reply