Integrating Exalogic control with EM Cloud Control - Part 1
Back to overview

Integrating Exalogic control with EM Cloud Control - Part 1

Published on: Category: Oracle

A tale of two Enterprise Managers

This post is about Exalogic Control and Enterprise Manager Cloud Control, and how they can integrate and interact.

Enterprise Manager Ops Center (‘Exalogic Control’)

As the built-in ‘Infrastructure-as-a-Service (IaaS) dashboard’ for Exalogic, Exalogic Control provisions, manages, meters and monitors the complete virtual DC infrastructure for hosting your business software environments from the hardware up to the operating system level. Being an engineered system, an Exalogic has all required computing resources built-in : ZFS storage, Infiniband networking and 4-30 compute nodes bringing in lots of CPU and memory, ready to roll. Exalogic Control is based on Enterprise Manager Ops Center 12c, but it is much more than that. It is also tightly integrated with the Oracle Virtualization stack on the Exalogic.

Enterprise Manager Cloud Control

The other Enterprise Manager, probably more familiar to most readers, is EM Cloud Control 12c. This is Oracle’s centralized solution for complete lifecycle management of your Oracle and third party business software solutions. It provides centralized monitoring, management, metering and provisioning (and many many more functions) of all software components from the operating system and upwards, i.e. databases, middleware, applications etc.

At the operating system, these two solutions meet up, as illustrated below :

EM integration question

So, roughly speaking, Exalogic Control (EM Ops Center) is for datacenter operations and Cloud Control is for Business Application operations. A question I get frequently is how these two Enterprise Manager dashboards can interact and if they can be integrated. These dashboards serve two rather different work areas and therefore appeal to different ‘admin audiences’. Hence I have some reservations on the overall importance of such integrations, but they seem to raise considerable interest among coorporate customers.

Which integrations ?

Which integrations are possible? Digging through Oracle technical documentation I have come up with 4 integrations so far :

  1. Connect Ops Center to Cloud Control so ‘upper stack’ targets become visible in Ops Center
  2. Connect Cloud Control to Ops Center so ‘lower stack’ targets become visible in Cloud Control
  3. Integration of Exalogic ZFS storage management into Cloud Control
  4. Integration of Exacheck reports

The first integration has been adequately described by Gokhan Atil in this post, and is of somewhat less importance as most customers focus on centralizing and consolidating their IT management into Cloud Control. So, in this post I will focus on the second integration, which will make our Exalogic virtual datacenter visible in Enterprise Manager Cloud Control.

Connecting Cloud Control to Ops Center

Some prerequisites

I have found that for Exalogic the following conditions apply :

  • You must be on Exalogic version 2.0.4.0.0 or higher (a.k.a. Navstar release)
  • You must be on Cloud Control 12cR2 (v12.1.0.3)
  • Virtualization plugin version 12.1.0.3 *

And of course we must make sure that all entities involved must be able to find each other on the network using their correct hostnames. This may seem obvious but it can really get you into trouble if you don’t check this every step of the way.

* version 12.1.0.4 of the plugin is also available now, but it appears to have some issues so it’s best not to upgrade it for now!

Steps to setup integration of the Exalogic vDC with Cloud Control

There are seven steps to make this integration operational :

  1. Install EM agent on the Enterprise Controller (EC1) vServer
  2. Install EM agent on the Oracle VM Manager (OVMM) vServer
  3. Deploy the Virtualization plugin on the OVMM agent
  4. Import Ops Center certificate into the Management Agent keystore
  5. Configure OVMM for read only access by Cloud Control
  6. Register the Oracle VM Manager with Enterprise Manager Cloud Control
  7. Discover the Exalogic system using Exalogic Elastic Cloud Discovery Wizard

Steps 1 and 2 : deploying the agents

As always, for Cloud Control to be able to operate something, it needs to have an agent in place. The deployment of the Cloud Control agents can be done in the classic way by pushing the agent to the target (see this previous post), or we can use the newly introduced oracle-agt package. This package is now present by default in the Exalogic virtual server base image (EGBT) starting from the Navstar release.

As we want to do this ‘the Exalogic way’, let’s take the oracle-agt option and deploy it on the OVMM virtual host as an example. Deployment on EC1 is analogous.

  1. [root@xxxx-ovmm ~]#<strong> cd /usr/lib/init-exalogic-node ; </strong> <strong>cat .template_version
  2. </strong>exalogic_version='2.0.4.0.0'
  3. exalogic_template_build_version='221802'
  4. [root@xxxx-ovmm ~]# <strong>rpm -qa| grep oracle-agt
  5. </strong>oracle-agt-12.1.0.2.0-1.0

Update the agent.properties file:

  1. [root@xxxx-ovmm ~]#<strong> vi /usr/lib/oracle/agent.properties</strong>
  1. #-------------------------------------------------------------------------------
  2. #OMS_HOST:&lt;String&gt; OMS host info required to connect to OMS
  3. #OMS_PORT:&lt;String&gt; OMS port info required to connect to OMS
  4. #AGENT_REGISTRATION_PASSWORD:&lt;String&gt; Agent Registration Password needed to
  5. #     establish a secure connection to the OMS.
  6. #-------------------------------------------------------------------------------
  7. #OMS_HOST=#OMS_HOST#
  8. #OMS_PORT=#OMS_PORT#
  9. #AGENT_REGISTRATION_PASSWORD=#AGENT_REGISTRATION_PASSWORD#
  10. #-------------------------------------------------------------------------------
  11. #AGENT_USERNAME:&lt;String&gt; User name with which the agent should be installed.
  12. #AGENT_GROUP:&lt;String&gt; Group to which the agent user belogs.
  13. #AGENT_PORT:&lt;String&gt; Port in which the agent process will come up.
  14. #-------------------------------------------------------------------------------
  15. #AGENT_USERNAME=#AGENT_USERNAME#
  16. #AGENT_GROUP=#AGENT_GROUP#
  17. #AGENT_PORT=#AGENT_PORT#
  18. #-------------------------------------------------------------------------------
  19. #ORACLE_HOSTNAME:&lt;String&gt; Virtual hostname where the agent is deployed.
  20. #Example: ORACLE_HOSTNAME=hostname.domain
  21. #-------------------------------------------------------------------------------
  22. #ORACLE_HOSTNAME=#ORACLE_HOSTNAME#

Here we tell the agent where our Cloud Control instance is:

  1. OMS_HOST=xxxx-CC12c.qualogy.com
  2. OMS_PORT=4900
  3. AGENT_REGISTRATION_PASSWORD=&lt;very secret password&gt;
  4. AGENT_USERNAME=oracle
  5. AGENT_GROUP=oracle
  6. AGENT_PORT=3872
  7. ORACLE_HOSTNAME=xxxx-ovmm.qualogy.com

Then we let the oracle-agt package do the rest of the work:

  1. [root@xxxx-ovmm ~]# <strong>/etc/init.d/oracle-agt RESPONSE_FILE=/usr/lib/oracle/agent/
  2. agent.properties
  3. </strong>Response File:/usr/lib/oracle/agent/agent.properties
  4. Starting Oracle Universal Installer...
  5. Checking swap space: must be greater than 500 MB.  Actual 16378 MB  Passed
  6. ....
  7. &lt;lots of output&gt;
  8. ....
  9. ** Agent Port Check completed successfully.**
  10. perform - mode finished for action: configure
  11. You can see the log file: /usr/lib/oracle/agent/core/12.1.0.2.0/cfgtoollogs
  12. /oui/configActions2013-02-07_03-20-30-PM.log
  13. Agent Configuration completed successfully

Use the same procedure for setting up the agent on the Enterprise Controller vServer EC1. After this our EC1 and OVMM servers have been added to Cloud Control:

Step 3: Deploy the Virtualization plugin on the OVMM agent

Navigate to Setup > Extensibility > Plugins and deploy the virtualization plugin on the OVMM agent. If you need more guidance or background, check this link.

Here’s the result:

Now that our agents and the plugin are in place, we can get to the actual integration work.

Step 4: Import Ops Center certificate into the Management Agent keystore

We now need to get some authentication in place between Cloud Control and Ops Center. First we retrieve the Ops Center certificate, then we import it into the EC1 agent’s keystore.

Make sure you use the correct keytool version for this, or you will get arcane messages about ‘incorrect magic’, making you think you’ve logged onto some system at Hogwarts!

  1. [root@ec1-vm jsse]# <strong>/usr/java/jdk1.6.0_31/jre/bin/keytool -export -alias
  2. cacao_agent -file oc.crt -keystore truststore -storepass trustpass
  3. </strong>Certificate stored in file &lt;oc.crt&gt;

Import this key into the agent keystore:

  1. [root@ec1-vm ~]# <strong>export JAVA_HOME=/usr/java/jdk1.6.0_31
  2. </strong>[root@ec1-vm ~]# <strong>export JSSE=/etc/opt/sun/cacao2/instances/oem-ec/security/jsse
  3. </strong>[root@ec1-vm ~]# <strong>export AGTHOME=/usr/lib/oracle/agent
  4. </strong>[root@ec1-vm ~]# <strong>export MONTRUST=$AGTHOME/</strong><strong>core/12.1.0.2.0/stage/sysman/
  5. config/montrust
  6. </strong>[root@ec1-vm ~]# <strong>$JAVA_HOME/jre/bin/keytool -import -keystore $MONTRUST/
  7. AgentTrust.jks -alias wlscertgencab -file $JSSE/oc.crt
  8. </strong>Enter keystore password:  <em>&lt;password&gt;
  9. </em>Owner: CN=ec1-vm_oem-ec_agent
  10. Issuer: CN=ec1-vm_oem-ec_agent
  11. Serial number: 13e69950
  12. Valid from: Thu Jan 01 01:00:00 CET 1970 until: Sat May 01 16:02:53 CEST 2032
  13. Certificate fingerprints:
  14. MD5:  FC:DB:16:87:80:C2:A0:AE:6B:A6:A7:40:FE:06:13:72
  15. SHA1: 53:BA:17:C2:65:EE:84:85:C7:C9:20:28:5D:78:1B:F5:DD:FD:87:E7
  16. Signature algorithm name: MD5withRSA
  17. Version: 3
  18. Trust this certificate? [no]: <strong> yes
  19. </strong>Certificate was added to keystore

Check the agent’s keystore:

  1. [root@ec1-vm agent]# <strong>$JAVA_HOME/jre/bin/keytool -list -keystore $MONTRUST/AgentTrust.jks
  2. </strong>Enter keystore password:
  3.  
  4. Keystore type: JKS
  5. Keystore provider: SUN
  6.  
  7. Your keystore contains 10 entries
  8.  
  9. verisignclass1pca, Oct 21, 2009, trustedCertEntry,
  10. Certificate fingerprint (MD5): 51:86:E8:1F:BC:B1:C3:71:B5:18:10:DB:5F:DC:F6:20
  11. verisignclass3ca, Oct 21, 2009, trustedCertEntry,
  12. Certificate fingerprint (MD5): 10:FC:63:5D:F6:26:3E:0D:F3:25:BE:5F:79:CD:67:67
  13. gtecybertrustglobalca, Oct 21, 2009, trustedCertEntry,
  14. Certificate fingerprint (MD5): CA:3D:D3:68:F1:03:5C:D0:32:FA:B8:2B:59:E8:5A:DB
  15. entrustsslca, Oct 21, 2009, trustedCertEntry,
  16. Certificate fingerprint (MD5): DF:F2:80:73:CC:F1:E6:61:73:FC:F5:42:E9:C5:7C:EE
  17. entrust2048ca, Oct 21, 2009, trustedCertEntry,
  18. Certificate fingerprint (MD5): BA:21:EA:20:D6:DD:DB:8F:C1:57:8B:40:AD:A1:FC:FC
  19. <strong>wlscertgencab, Mar 5, 2013, trustedCertEntry,
  20. </strong><strong>Certificate fingerprint (MD5): FC:DB:16:87:80:C2:A0:AE:6B:A6:A7:40:FE:06:13:72
  21. </strong>verisignserverca, Oct 21, 2009, trustedCertEntry,
  22. Certificate fingerprint (MD5): 74:7B:82:03:43:F0:00:9E:6B:B3:EC:47:BF:85:A5:93
  23. gtecybertrustca, Oct 21, 2009, trustedCertEntry,
  24. Certificate fingerprint (MD5): C4:D7:F0:B2:A3:C5:7D:61:67:F0:04:CD:43:D3:BA:58
  25. entrustgsslca, Oct 21, 2009, trustedCertEntry,
  26. Certificate fingerprint (MD5): 9D:66:6A:CC:FF:D5:F5:43:B4:BF:8C:16:D1:2B:A8:99
  27. verisignclass2ca, Oct 21, 2009, trustedCertEntry,
  28. Certificate fingerprint (MD5): B3:9C:25:B1:C3:2E:32:53:80:15:30:9D:4D:02:77:3E

OK, our certificate is in there (check the dates). To finish up, stop and restart the Cloud Control agent. Though the above import process seems to work OK, I found that the agent still complains about authentication when doing the Exalogic discovery in the last step. This issue can be solved by importing the key via the following alternative emctl command:

  1. [root@ec1-vm ~]# <strong>$AGTHOME/agent_inst/bin/emctl secure add_trust_cert_to_jks
  2. -trust_certs_loc $HOME/oc.crt -password welcome -alias wlscertgencab
  3. </strong>Oracle Enterprise Manager Cloud Control 12c Release 2
  4. Copyright (c) 1996, 2012 Oracle Corporation.  All rights reserved.
  5.  
  6. Message   :   Certificate was added to keystore
  7. ExitStatus: SUCCESS

Step 5: Configure OVMM for read only access by Cloud Control

Next we setup the Oracle VM Manager for read only access by Cloud Control. This means that for now, you can only check and monitor the status of virtual servers in Cloud Control, but you will not be able to stop and start them (and do other changes). To get this done, we need the ID of our Exalogic rack. We can retreive this from any compute (hypervisor) node, from the em-context.info file:

  1. [root@xxxxcn01 ~]# <strong>cat /var/exalogic/info/em-context.info
  2. </strong>ExalogicID=Oracle Exalogic X2-2 &lt;your rack ID&gt;
  1. [root@xxxx-ovmm ~]# <strong>cd /u01/app/oracle/ovm-manager-3/ovm_shell</strong>
  2. [root@xxxx-ovmm ovm_shell<strong>]# sh ovm_shell.sh --url=tcp://localhost:54321 -
  3. -username=admin --password=&lt;paaswoord&gt;
  4. </strong>OVM Shell: 3.0.3.326 Interactive Mode
  5. &gt;&gt;&gt; from com.oracle.ovm.mgr.api import *
  6. &gt;&gt;&gt; from com.oracle.ovm.mgr.api.event import *
  7. &gt;&gt;&gt; from com.oracle.ovm.mgr.api.virtual import *
  8. &gt;&gt;&gt; from com.oracle.ovm.mgr.api.physical import *
  9. &gt;&gt;&gt; from com.oracle.ovm.mgr.api.physical.network import *
  10. &gt;&gt;&gt; from com.oracle.ovm.mgr.api.physical.storage import *
  11. ---
  12. &gt;&gt;&gt; <strong>ovm = OvmClient.getOvmManager ()
  13. </strong>&gt;&gt;&gt; <strong>f = ovm.getFoundryContext ()
  14. </strong>&gt;&gt;&gt;<strong> j = ovm.createJob ( 'Setting EXALOGIC_ID' );
  15. </strong>&gt;&gt;&gt; <strong>j.begin ();
  16. </strong>&gt;&gt;&gt; <strong>f.setAsset ( "EXALOGIC_ID", "&lt;your rack ID&gt;");
  17. </strong>&gt;&gt;&gt; <strong>j.commit ();
  18. </strong>&gt;&gt;&gt;

Step 6 : Register the Oracle VM Manager with Enterprise Manager Cloud Control

Quoting the documentation:

The first step to register Oracle VM Manager is to authenticate to the Oracle Enterprise Manager 12c Cloud Control console. Once authenticated, click the Enterprise menu, then select Infrastructure Cloud,and click Home to access the Infrastructure Cloud page

This step is done from Cloud Control. Again, if you need more guidance or background, check this useful link.

After clicking on the Submit button on the top right, the registration job will be run.

And here we see the result of our efforts so far:

We can now see some parts of our Exalogic virtual datacenter. We can see the eight hypervisor nodes cn01-cn08 and expand them to see what runs on each. We also see the unallocated vServers that are not running presently.

In the next post I will finish up with step 7 (Discover the Exalogic system using Exalogic Elastic Cloud Discovery Wizard) and show you more examples of what you can now see and monitor on the Exalogic from Cloud Control.

Publicatiedatum: 3 april 2013

Jos Nijhoff
About the author Jos Nijhoff

Jos Nijhoff is an experienced Application Infrastructure consultant at Qualogy. Currently he plays a key role as technical presales and hands-on implementation lead for Qualogy's exclusive Exalogic partnership with Oracle for the Benelux area. Thus he keeps in close contact with Oracle presales and partner services on new developments, but maintains an independent view. He gives technical guidance and designs, reviews, manages and updates the application infrastructure before, during and after the rollout of new and existing Oracle (Fusion) Applications & Fusion Middleware implementations. Jos is also familiar with subjects like high availability, disaster recovery scenarios, virtualization, performance analysis, data security, and identity management integration with respect to Oracle applications.

More posts by Jos Nijhoff
Comments
Reply