Monday Jan 12, 2015

Enterprise Manager Ops Center - The Power of Groups

To Group or not to Group

Any customer with more than a handful of servers will struggle to take advantage of Ops Center's full features, unless they embrace the use of groups. The ability to group a number of like servers into a logical target, that can then be operated on, means you can do a single action instead of running the same action hundreds of times, once for each server in the group. Grouping also allows you to view and manage your environment in line with your current organizational units and business practices.

What can be done with Groups

Groups avoid the need to select individual servers and can be used as a target for:

  • Update profiles (Patching) - Update patches/packages and files and apply pre/post actions
  • Operational plans - Run a script, update config files etc
  • Perform actions - Reboot/halt/refresh/power-off/power-on actions to all assets in the group
  • Monitoring profiles - Apply customized monitoring profiles
  • Reporting -  Run a single report that includes multiple servers

Groups can also:

  • Display membership - The Membership Graph or the asset tree view both show the servers that make up a group
  • Display incidents/alerts - Groups work as a roll-up point for incidents on any server in the group
  • Display Top CPU/Memory/Network consumers - The "Asset summary" of a group shows top consumers of CPU/Memory/Network resources
  • Restrict the assets that a given user has access to in Ops Center

Types of Groups

Groups are totally logical constructs. An asset (Server, OS, Zone, LDOM) can be a member of as many groups as you like. Deleting a group, does not delete the assets it contains. While most often groups will contain assets of all the same type (eg: System LOMs), as this will give you a group where an action like "power off" makes sense to all the members of the group, it is also possible to create a group that is made up of differing asset types eg: all the assets (OS/LOM/Zones) that are part of a physical server. This type of group would normally be used to restrict the permissions of users so that they could only view/manage the servers for which they are responsible.  A key fact to remember when thinking about groups is that an asset that is a member of one group is not precluded from being a member of other groups.

Ops Center Predefined Groups

As a starting point, Ops Center provides a number of predefined groups found under the [ Navigation ==> Assets ] menu.

While most of the groupings are what you would expect, there are a few that require a little more explanation.

Standard Views 

[ All Assets ] - Not really a group as everything turns up here

[ Engineered Systems ] - A grouping of all discovered Engineered Systems (SPARC SuperCluster). Note that each Engineered System is also its own sub-group

[ Operating Systems ] -  Grouping based on OS type, release and version

[ Servers ] - Grouping based on physical servers

    • M-Series -  M[3/4/5/8/0]000, M6 and M10 servers
    • Other SPARC - servers that are not sun4u or sun4v architecture or non Oracle/Sun servers
    • U-Class - servers that have sun4u architecture CPU's (V240/V490/SF6800 etc.)
    • V-Class - servers that have sun4v architecture CPU's (T1000/T2000/T5XX0/T3/T4/T5 etc.) - not V-series servers as you might first think
  • x86
    • Other x86 - Non Oracle/Sun servers 
    • x64 - 64 bit servers
    • x86 32-bit - 32 bit servers

[ Chassis ] - 6000/8000 blade based chassis and their server blades 

[ Network Switches ] - Managed InfiniBand and network switches. Ops Center only manages a limited number of switch models and these will normally be found as part of an Engineered System (Exadata/Exalogic/SPARC Super Cluster).

[ Racks ]  - Both Engineered System racks and manually declared racks. It is not commonly known that you can declare all the racks in your data center in Ops Center and place all your servers in their respective racks, giving you a useful data center view.

All the predefined groups are useful but as you can see, they are based on broad brush physical characteristics of a server and its OS. There is no allowance for how you actually use your servers. For that you will need to build your own "User Defined Groups".

User Defined Groups

User Defined Groups are an extremely powerful addition to Ops Center and allow you to model your application, organizational units and business constraints into Ops Center's management interface. Basically, it makes Ops Center capable of working much more in alignment with the way your business operates. Before we go onto how to create "User Defined Groups", let's go over, in a little more detail, what you could use them for:

  • Applications - create a group of all your web servers to report on patch levels, apply patches, update application configurations, restart applications, list top resource consumers.
  • Prod/Dev/Test - create a group based on production status, so you can  apply differing monitoring/alerting profiles, produce management reports and restrict admin access.
  • Admin By - create a group of all the servers that an admin(s) is responsible for, so they can quickly respond to alerts or you can limit the functions they are authorized to perform.
  • Patching - create a group based on the servers that are in the 1st round of patching, so you can easily and consistently patch, do before and after patching reports and maintain consistent patch levels across key applications.

These are just a few of the many things for which groups can be used. Setting up groups will greatly decrease your day to day workload and increase the manageability of your environment. Without the use of grouping, it is unlikely that you will be able to scale your Ops Center environment efficiently beyond about 30 servers.

Creating a User Defined Group 

First select the "Create Group" action [ Navigation ==> All Assets ==> Create Group ]

Static Groups 

Static groups are just as the name suggests, you define a group and place static members in it.

The default action of the "Configure Group" wizard is to create a Static Group. As long  as the "Configure group rules" checkbox is unchecked this will be a static group.

Give the group a name (mandatory), a description (Optional), and one or more group tags (Optional) and click "Next" and "Finish" to complete the wizard and launch the job that creates the group.

Tagging is another powerful feature that will be the topic of another blog, but in summary, it is a way of storing an arbitrary tag (value pair) with an asset or group, which means you can store any important information with the asset, such as Asset Number, Production status, etc.

Now, one by one, navigate to your servers and manually add the server to the group you have created.

Select your individual servers page and select the "Add Asset to Group" action.

Select the Group you want to add to (our example group is "Static Group") and the click then [Add Assets to Group] button.

Dynamic (Smart) Groups 

Dynamic (smart) groups are once again much as the label says. An asset(server/OS etc) will become part of the group based on it matching one or many criteria. The criteria is evaluated every time the group is accessed. So if you deploy a new server, create a zone or update any other matched attribute, it will change the group membership. The next time you access the group its membership will be automatically updated to include the current view of the environment. There is a large number of attributes that can be used to make criteria and the criteria can be combined to make complex grouping rules. There is more than enough to discuss on building these rules for another blog, but today, let's just go with a single example to give you the feel for the capabilities of dynamic grouping.

We will launch the "Create Group" wizard, as we did for the static group, but this time we will give it a more descriptive name and description. Last but not least, we will check the "Configure group rules" check-box, which will make the group we create a dynamic group.

Rules can be as simple as "hostname" starts with "prod" or as complex as having multiple rules each with multiple criteria matches. This is why I will be going into more details on building these rule sets in another blog in the next few weeks.

For this example, I have chosen a moderate level of complexity. We have a single rule, but we will only match on any asset that has all 4 of the attributes set.

  • OS Version contains 11 ( I also could have used Version equals 5.11)
  • Has an IP address is on subnet
  • Is a Non Global Zone
  • Is managed by Ops Center (It would be unusual to not be in a managed state, but a Proxy Controller in a NGZ is an example of a non managed asset. )

Click [Next] to see the preview screen and to check that we matched the assets we want.

You can see that we have matched on 4 Solaris 11 zones. Now let's see how that looks in the BUI [Navigation==>Assets ==>All User Defined Groups (pull-down)].

You see we have our static group and our dynamic group we have just created.

OK, let's create a second group, but this time for managed Non Global zones of the network.

Create a new name and description.

Configure our rule, but this time look for Non Global Zones on the network.

Preview shows no matching hosts, which in this case is correct, as I have not deployed a zone on that network yet. Finish the wizard and now let's look in the BUI to see what we have.

Checking the [All User Defined Groups] pull-down, we now see our static group and 2 different S11 NGZ groups, one with 4 members and one with no members.  (I was not quite consistent with the group naming, but I could fix that using the [Modify Group action].)

Now if I go off and deploy a few new zones, we can then see what our smart groups look like. I have deployed 2 zones on the subnet and one more zone on the subnet.

As you can see, the new zones automatically appear in the correct groups.

Dynamic (Smart) Groups - Criteria

There are far too many attributes to go through here ( a few are listed below) and I will be writing a further blog to show you how to use some of the more useful ones.

Semantic Tags

But I will call out one special criteria (attribute) that is probably the most useful one of all - the Semantic tag. A Semantic tag is an arbitrary tag or a tag/value pair that can be added to any asset to basically store descriptive information about that asset. You can add a tag to an asset by simply clicking the [Edit Tag] action.

Examples of Semantic Tags (Key):

 Tag Name
 PRODUCTION  Describes the production status
 SALES  Describes the business unit that owns the server

Examples of Semantic Tags/Value pairs (Key and Value):

Tag Name  Value Description
 PRODUCTION_STATUS  DEV/UAT/PROD The value describes the production status DEV/UAT/PROD
 Admin_By The value describes the name/group of the administrator of the system (could even be their email)
 Business_Unit  SALES/ENGINEERING/ACCOUNTS The value describes the business unit that owns the server
 Application  DataBase/Web/ApplicationServer The value describes the application running on the asset

As you can see, you can create a Semantic Tag to store any information about your server that you require. These tags and tag/value pair scan be used as attributes to create Dynamic groups.

Configure a group using a "Semantic Tag Key & Value".

And the group based on the tag/value pair is ready to use.

Nesting Groups

One final feature of groups is that you can nest them (have a group that contains 1 or more other groups).

Create a group as before. This time click the check-box for "Configure subgroups".

Then you must drag the subgroups you want to include to the "Selected Group" icon.

Repeat this procedure until you have all your required groups selected.

Now click [Next], [Next] and [Finish], then check what our new group looks like.

You can see the S11-Zones group contains both S11 NGZ groups.

And by highlighting the S11-Zones group, we can see its membership and incident information for all included assets.


I hope this has given you a good understanding of groups and how they can make your use of Ops Center more productive.



Monday Jan 05, 2015

Enterprise Manager Ops Center - OS provisioning across secondary network interfaces


One of Enterprise Manager Ops Center's core functionalities is to be able to provision the OS to bare metal servers. If the network you are provisioning across is connected to one of the onboard ports (on the first onboard network chip), all is well and provisioning will work as expected. This would be the case for 95% plus of all customers, but if you are trying to provision across a network that is connected to a port on a card in an expansion slot (or a second onboard network chip), your provisioning job will fail due to the incorrect MAC address being set in the JET/AI/Kickstart server. If you are one of the people who has hit this issue, please read on. If you are provisioning over an onboard NIC port, stop reading now and happy OS provisioning.

The Cause

When Ops Center discovers the ILOM (ALOM/XSCF and all the other various LOMs) of a server, there are only certain pieces of information that can be collected from the LOM while the OS is running. We maintain a policy of creating as little impact as possible during discovery, so we do not force you to shutdown the OS during discovery. 

Information we can collect:

  • the number of network interfaces
  • the MAC address of the first network interface (port)

Information we can NOT collect:

  • the MAC address of all the other network interfaces (ports)

Since the LOM only provides the first MAC address, Ops Center must calculate the MAC addresses of the remaining network interfaces. Ops Center will get the MAC addresses for the onboard NICs correct but its calculated MAC addresses will be wrong for any NICs not on the first onboard network chip.

If we have an example system that has 4 onboard network ports (on the motherboard) and an expansion network card in the PCI-E/X slot with an additional 4 network ports, Ops Center's view of that server, based on the information from the LOM, would not match the physical server.

Interfaces Name Ops Center's Mac Address - Calculated ( from LOM) Actual Mac Adress Correct
Number of Network interfaces 8 8 YES
Mac Address for interface 0 (onboard) net0 00:21:28:17:72:b2 00:21:28:17:72:b2 YES
Mac Address for interface 1 (onboard) net1 00:21:28:17:72:b3 00:21:28:17:72:b3 YES
Mac Address for interface 2 (onboard net2 00:21:28:17:72:b4 00:21:28:17:72:b4 YES
Mac Address for interface 3 (onboard net3 00:21:28:17:72:b5 00:21:28:17:72:b5 YES
Mac Address for interface 4 (PCI-E/X card) net4 00:21:28:17:72:b6 00:14:4f:6b:fd:28 NO
Mac Address for interface 5 (PCI-E/X card) net5 00:21:28:17:72:b7 00:14:4f:6b:fd:29 NO
Mac Address for interface 6 (PCI-E/X card) net6 00:21:28:17:72:b8 00:14:4f:6b:fd:30 NO
Mac Address for interface 7 (PCI-E/X card) net7 00:21:28:17:72:b9 00:14:4f:6b:fd:31 NO

 You can confirm that the Mac addresses for an expansion network card has been calculated, by looking at the Network tab in the BUI for the LOM object.

You can see the displayed MAC addresses for GB_4 and GB_5 are just a simple increment of 1 from that of GB_3 which should not be the case as GB_4 and GB_5 are on a PCI-E/X expansion card. While most Oracle(Sun) servers have 4 on-board network interfaces of the same type, some servers may have 2 x 1GBit interfaces and 2 x 10Gbit interfaces. In this case, only the first on-board network interfaces will display the correct MAC addresses.

It should be noted that if you have discovered the LOM and discovered the running operation system, Ops Center will have been able to identify the correct MAC addresses for all the network interfaces as it combines the information gathered from the LOM and the Operating System to display the full picture (correct values). Unfortunately, you can not rely on these when re-provisioning, as part of the OSP job will delete the OS object (we are re-provisioning it after all) and the cached values for the MAC address may expire before the JET/AI/Kickstart server is configured.

The Impact

If you were to provision across net0, net1, net2, or net3 all would work well, but if you selected net4 or above for provisioning, the job would fail due to a timeout in the "Monitor OS Installation" task as the Jet/AI/Kickstart server would have been configured with the wrong MAC address and so it would have not responded to the OSP request. Please note that a misidentified MAC address is not the only possible cause of a timeout in the "Monitor OS Installation" task. This error only indicates that some step of the OS provisioning has failed and can be caused by a number of different issues.

The Solution

There are 2 ways of provisioning to secondary network interfaces

1) Use the MAC address method (simplest method - only available in 12.2.0+)

In Ops Center 12.2.0, we introduced an option to specify the MAC address to provision across directly in the BUI. When running the "Install Server" Action/Wizard, the "Boot Interface Resource Assignments" page has a check-box [Identify Network Interface by MAC Address]. Selecting this check-box will change the wizard from using netX interface names that rely on the discovered MAC address, to letting you manually enter the MAC address. This entered MAC address is used to setup the JET/AI/Kickstart server and is used to interrogate the OBP of the server to workout the netX interface that is required for wanboot.

It is as easy as that and your provisioning job will progress as normal.

2) Overload the MAC address before provisioning (the way we did it before we had method #1)

Assuming you have already discovered and managed the systems LOM, you can overload (update) the discovered/calulated network interface MAC addresses.

In the BUI, select "Assets" ==> "All Assets" ==> "Add Assets"

then choose "Manually declared server to be a target of OS provisioning"

While this could declare multiple servers using an XML file, in this example, we will just be doing a single server. This wizard normally lets us declare a server network interfaces but as some of the MAC addresses we will be declaring are already part of an existing discovered server LOM, Ops Center will identify the overlaping MAC address and merge this data with the existing server. The matching interfaces will stay the same but the new MAC addresses will overload (replace) the incorrect addresses.

Select Declare a single server, then click the [Green Plus] icon

Enter the port name [GB_X] and the actual MAC address.

Repeat this for all the interfaces, up to and including the one you want to provision across. 

Do not skip any interfaces as the interface numbering is based on the order the entries are stored in the database.

When you have entered all required interfaces, you then have to fill in the server details.

Once completed, click the [Declare Asset] button and wait for the job to complete. Normally, this will just take a few seconds. 

You can check in the BUI that the updated MAC addresses have been applied.

Now, just run your provisioning job as per normal and the correct MAC address will be configured in the JET/AI/Kickstart server.

As you can see, if you have updated your Enterprise Controller to Ops Center 12.2.0 or higher, option #1 is the simpler method.

All the best with your OS provisioning,


Wednesday Sep 10, 2014

Enterprise Manager Ops Center - Changing alert severity in default monitoring policies

Modifying Monitoring Policies

Ops Center delivers default monitoring policies for the various types of assets managed and monitored by Ops Center. These policies are specific to each asset type. In the real world, these policies act only as a starting point and you will need to customize them to suit your own environment. Most of the customizations can be done in the BUI (Browser User Interface),  which is covered in the manuals and other blogs on this site, but occasionally, you will need to manually edit the underlying XML of the default policies to get the customization you require. The method of doing that is covered in this blog entry.

List of monitoring ptofiles

In the BUI, you can easily copy these default policies and then modify them to suit your own environment.

You can do the following modifications in the BUI:

  • enable/disable monitoring rules
  • add a new monitoring rule
  • delete an existing monitoring rule
  • Modify the thresholds/severities/triggers for most alert rules

Modifications are normally done by highlighting the rule, clicking the edit [] icon, making your changes and then clicking the apply button. Remember that once you have made all the rule changes, the policy should be applied/reapplied to your target assets. Most rules are editable in this way.

Edit SMF rule

However, not all rules can be edited in the BUI. A rule like "Operating System Reachability" can not be edited from the BUI and must be done manually by editing the underlying XML. These rules can be identified by the fact that there is no edit [] icon available when the "Operating System Reachability" alert rule is selected.

Only Ops Center factory default policies (product standard default policies) can be edited by modifying the XML on the filesystem. When a policy is modified, it copies the default policy to a custom policy which can be modified in the BUI. These modified policies are stored in the database, not as XML on the filesystem. This means that if you want to change one of these non editable rules, you must manually edit the factory default policy.  Then, make a copy of the policy to create a custom policy and, if required, re-apply any additional customizations in the BUI, so that your new policy adsorbs the manual modifications.

While the default values are normally sufficient for most customers, I had a request from a customer who wanted to change the "Operating System Reachability" severity from Warning (the default) to Critical. He considered this to be an important event that needed to be alerted at a higher level so that it would grab the attention of his administration staff. Below is the procedure for how to achieve such a modification.

Manually Modifying the Default Alert Severity

As part of a standard install, Ops Center will create an alert of severity Warning if it loses connectivity with an Operating System (S8/9 OS or S10/11 GZ).

This will create an alert with the description "The asset can no longer be reached"

Warning Level alert

So here is the procedure for how to change the default alert severity for the "Operating System Reachability" alert from Warning to Critical. Be aware that there is a different alert for "Non-global zone Reachability", which will not be covered here, but modifying it, or other alerts, would follow a similar procedure.

We will be modifying the XML files for the default monitoring policies. These can be found at /var/opt/sun/xvm/monitoringprofiles on your EC.

root@ec:/var/opt/sun/xvm/monitoringprofiles# ls
Chassis.xml                       MSeriesDomain.xml                 ScCluster.xml
CiscoSwitch.xml                   NasLibrary.xml                    ScNode.xml
Cloud.xml                         NonGlobalZone.xml                 ScZoneClusterGroup.xml
ExadataCell.xml                   OperatingSystem.xml               ScZoneClusterNode.xml
FileServer.xml                    OvmGuest.xml                      Server.xml
GlobalZone.xml                    OvmHost.xml                       Storage.xml
IscsiStorageArray.xml             OvmManager.xml                    Switch.xml
LDomGuest.xml                     PDU.xml                           Tenancy.xml
LDomHost.xml                      RemoteOracleEngineeredSystem.xml  VirtualPool.xml
LocalLibrary.xml                  SanLibrary.xml
MSeriesChassis.xml                SanStorageArray.xml

Follow the steps below to modify the monitoring policy:

  1. In the BUI, identify which policies you want to modify. Look at an asset in the BUI and select the "Monitoring" tab. At the top of the screen, you will see what monitoring policy (Alert Monitoring Rules) it is running. In this case, the policy is called "OC- Global Zone", which will be the "GlobalZone.xml" file.

    Identify Profile type

    Or alternatively, log on to the EC and grep for the alert rule name.

    # grep "Operating System Reachability" *
    GlobalZone.xml:                <name>Operating System Reachability</name>
    OperatingSystem.xml:                <name>Operating System Reachability</name>

    In this case, we will want to change "OC - Operating System" and "OC - Global Zone" policies, as they both have the "Operating System Reachability" rule, so we will be editing both the "GlobalZone.xml" and "OperatingSystem.xml" files.

  2. Make a backup copy of any XML file you modify (in case you mess something up).

    # pwd
    # cp OperatingSystem.xml OperatingSystem.xml.orig
    # cp GlobalZone.xml GlobalZone.xml.orig
  3. Edit each file and look for the rule name

         <name>Operating System Reachability</name>

    and change "unreachable.duration.minutes.WARNING" to "unreachable.duration.minutes.CRITICAL".

         <name>Operating System Reachability</name>

    Repeat for the other file(s).

  4. Make a backup copy of  your modified XML files as these files may be overwritten during an upgrade process.

  5. Now restart the EC so that the new monitoring policies are re-read.

  6. You should now apply the new policy to the hosts you want to have the updated rule.

  7. Check the Message Center in the Navigation panel and you will see that your alert has now changed from "Warning" to "Critical".

Critical Alert level

A Best Practice option would now use the BUI to copy the new  (OC - Global Zone and OC - Operating System) policies to your own custom policies, adding any additional rule modifications. Copying the new OC policy  to a custom policy saves it into the database so it will not get overridden by any subsequent Ops Center upgrade. Remember to apply the custom policy to your asset(s) or asset groups.

It is good practice to keep the name of the source policy in the name of your custom policy. It will make your life easier if you ever get confused about which policy applies to which type of asset or if you want to go back to the original source policy.

If you want your new custom policy to be automatically applied when you discover/provision a new asset, you will need to select the policy and click the "Set as Default Policy" action for that asset class.

Setting default policy

The green tick on the icon indicates that a policy is the default for that asset class.

You have now successfully modified the default alert severity, for an alert that could not be modified in the BUI.


Rodney Lindner
Senior IT/Product Architect
Systems Management - Ops Center Engineering

Wednesday Jul 23, 2014

Enterprise Manager Ops Center 12c R2 U1 Released

We are happy and excited to announce that on July 20, 2014, Oracle Enterprise Manager Ops Center 12c Release 2 Update 1 was released for all platforms including Oracle Solaris SPARC/x86 and Linux.

Ops Center 12cR2 PSU1 is an update release containing improvements and enhancements in the following areas: performance, new hardware support and general quality improvements.

In the performance area we have made improvements in core Ops Center components such as the Enterprise Controller, Proxy Controller and Virtualization Agent. We have reduced the Enterprise Controller memory footprint and enhanced start up times for the Enterprise Controller and agents. We have looked at areas such as deployment wizards and the management of LUN's and made improvements in the performance of these areas.

For new hardware we support the discovery, monitoring and provisioning of both OS and Firmware for: X4-4, X4-8, M4000 and M10. We also made improvements for firmware management of the X4-2 and introduced enhanced support for add / modify hardware configurations for Oracle SuperCluster. 

In the general quality area we improved security, refined logging, made improvements to OS provisioning and enhanced areas such as LDAP and the UI.

For customers with a support contract historically any new updates to the Ops Center components would automatically appear in the Download window of the UI. However, we have noticed a bug which prevents this new version appearing. A fix / IDR is in place and is described in the release notes for this version available here. There is also a MOS note 1908726.1 which describes the IDR and procedure to enable the download.

Software downloads outside of this automatic process will be available on the OTN and edelivery in the coming days.

Before upgrading your Enterprise Controller please check the upgrade guide available here.

There is also an excellent blog which gives advice on pre upgrade tasks to ensure a smooth and successful upgrade experience here.

Thursday May 02, 2013

How to Monitor Systems in Enterprise Manager using Ops Center

In this post, we'll use Ops Center to add hardware monitoring to Enterprise Manager. We'll discuss the existing capabilities of Host targets, show how to create an Infrastructure Stack and demonstrate some of the features it provides to Enterprise Manager.

A recording of this community call is now available here:

WebEx Recording: Ops Center integration with Cloud Control


This blog post uses both the Enterprise Manager 12c Cloud Control and Ops Center products. The following list describes the initial setup state and provides links to Oracle documents you can use to install and configure both products:

  • Enterprise Manager 12c
    • Install and configure an Oracle Management Server and Repository (OMS and OMR)
    • Install the Oracle Management Agent (OMA) on a target OS instance
  • Ops Center 12c
    • Install and Configure the Enterprise and Proxy Controller (EC and PC)
    • Discover and manage the system and its associated OS (installing the Ops Center agent on the OS instance)

I've configured the environment for this post in the following way:

  • Enterprise Manager 12c: OMS and OMR running separately
  • Ops Center 12c: EC and PC running co-located
  • Two sample systems, both running Solaris 11
    • An Oracle SPARC T4-2 server
    • An Oracle SunFire X4200 M2 server

Host Capabilities in Enterprise Manager

By default, installing an Enterprise Manager agent on an OS instance creates an associated Host target. A Host provides a lot of useful data about the platform that hosts the OMA, such as

  • CPU and memory utilization
  • File system size and utilization
  • Network interfaces and activity
  • Program and process resources
  • User activity

The Host does not provide sensor data associated with the server and cannot report issues with the underlying hardware. Fortunately Ops Center can do both of these things, and you can incorporate server data, monitoring thresholds and alerts into your Enterprise Manager environment.

Setting Up an Infrastructure Stack

Ops Center: Configure the connection to Enterprise Manager

To connect Ops Center with Enterprise Manager, select the left-hand Navigation link Administration > Enterprise Manager Cloud Control. Click on the right-hand Action link Configure/Connect and open a pop-up dialog box. The dialog lets you configure the OMS and OMR settings. The screen shot below shows both steps from the wizard.

Enterprise Manager: Download and deploy the Ops Center Plug-In

Enterprise Manager 12c provides a deployable plug-in to manage an Infrastructure Stack. For Enterprise Manager installations running in online mode, you can download it from the Extensibility > Plug-Ins menu from the Servers, Storage and Network category.

Download and deploy the plug-in to the OMS. You can immediately deploy it to the OMA instances you want to integrate with Ops Center, or wait until you create an infrastructure stack. (Enterprise Manager will automatically install the plug-in to the OMA if it is not already present)

Enterprise Manager: Create an Infrastructure Stack Target

An Infrastructure Stack associates data from a system in Ops Center with targets in Enterprise Manager. To create one, select the menu option Setup > Add Targets > Add Targets Manually. From the wizard, select Infrastructure Stack from the pull-down menu and identify the Monitoring Agent that will be used.

The subsequent configuration screen allows you to define the name for the target, to identify the Enterprise Controller that will provide the data for the server, and to specify the Ops Center login credentials. Any user account defined in Ops Center is suitable for the target.

Infrastructure Stack Capabilities

What benefits does an Infrastructure Stack provide? As the consolidation point for server-related information, it enables you to perform three principal tasks:

  • Monitoring, with metrics and thresholds for the server
  • Reporting, using a set of standard Information Publisher reports
  • Incident Management, with Ops Center hardware alerts

Let's look at some examples for each.


An Infrastructure Stack provides a wealth of information about a server, including identification information, state, capabilities and sensor data. The home page provides a summary of current values for power consumption, temperature, fan speed, and reported incidents.

The metrics section provides more detailed data such as sensor values, thresholds, installed firmware and server capabilities.

Note that the reported values ultimately depend on what data is available for a specific type of server. Some earlier models don't report temperature data, for instance.


Enterprise Manager provides three standard Information Publisher reports:

  • Infrastructure Stack Topology, showing the server and OS associated with the stack
  • Infrastructure Stack Configuration, providing a tabular summary of key data
  • Hardware Sensors, showing current values and thresholds for monitored server data

The following screen shots provide sample report output for the infrastructure stack configuration and hardware sensor data.

Incident Management

Incident reporting is an optional capability for an Infrastructure Stack. Enabling the feature causes Ops Center to forward hardware alarms, allowing you to consolidate problem management in Enterprise Manager.

To enable incident reporting, navigate to the Infrastructure Stack and select the menu option Monitoring > Metric and Collection Settings. Select the link Collection Schedule for Infrastructure Stack Alarms to edit the settings:

If you toggle the collection schedule to Enabled, Enterprise Manager will activate incident reporting based on hardware alarms. By default, the data refresh frequency is once every five minutes, with warning or critical alarms being reported.

In this example, we simulated an hardware alarm using the IPMItool utility from the Hardware Management Pack. Ops Center forwarded the event and all associated data, which generated an actionable incident in Enterprise Manager,


In this post, we have demonstrated how to integrate Ops Center data into Enterprise Manager, and described the features available for an Infrastructure Stack. If you would like to learn more, please join us for the WebEx demo on May 9th.

Thursday Nov 15, 2012

Ops Center Solaris 11 IPS Repository Management: Using ISO Images

A recording of this community call is now available here:

With Enterprise Manager Ops Center 12c, you can provision, patch, monitor and manage Oracle Solaris 11 instances. To do this, Ops Center creates and maintains a Solaris 11 Image Packaging System (IPS) repository on the Enterprise Controller. During the Enterprise Controller configuration, you can load repository content directly from Oracle's Support Web site and subsequently synchronize the repository as new content becomes available.

Of course, you can also use Solaris 11 ISO images to create and update your Ops Center repository. There are a few excellent reasons for doing this:

  1. You're running Ops Center in disconnected mode, and don't have Internet access on your Enterprise Controller
  2. You'd rather avoid the bandwidth associated with live synchronization of a Solaris 11 package repository

This demo will show you how to use Solaris 11 ISO images to set up and update your Ops Center repository.


This tip assumes that you've already installed the Enterprise Controller on a Solaris 11 OS instance and that you're ready for post-install configuration.

In addition, there are specific Ops Center and OS version requirements depending on which version of Solaris 11 you plan to install.You can get full details about the requirements in the Release Notes for Ops Center 12c update 2.

Additional information is available in the Ops Center update 2 Readme document.

Part 1: Using a Solaris 11 ISO Image to Create an Ops Center Repository

Step 1 – Download the Solaris 11 Repository Image

The Oracle Web site provides a number of download links for official Solaris 11 images. Among those links is a two-part downloadable repository image, which provides repository content for Solaris 11 SPARC and X86 architectures. In this case, I used the Solaris 11 11/11 image.

First, navigate to the Oracle Web site and accept the OTN License agreement:

Next, download both parts of the Solaris 11 repository image. I used the Solaris 11 11/11 image, and have provided the URLs here:

Finally, use the cat command to generate an ISO image you can use to create your repository:
# cat sol-11-1111-repo-full.iso-a sol-11-1111-repo-full.iso-b > sol-11-1111-repo-full.iso

The process is very similar if you plan to set up a Solaris 11.1 release in Ops Center. In that case, navigate to the Solaris 11 download page, accept the license agreement and download both parts of the Solaris 11.1 repository image. Use the cat command to create a single ISO image for Solaris 11.1

Step 2 – Mount the Solaris 11 ISO Image in your Local Filesystem

Once you have created the Solaris 11 ISO file, use the mount command to attach it to your local filesystem. After the image has been mounted, you can browse the repository from the ./repo subdirectory, and use the pkgrepo command to verify that Solaris 11 recognizes the content:

Step 3 – Use the Image to Create your Ops Center Repository

When you have confirmed the repository is available, you can use the image to create the Enterprise Controller repository. The operation will be slightly different depending on whether you configure Ops Center for Connected or Disconnected Mode operation.

For connected mode operation, specify the mounted ./repo directory in step 4.1 of the configuration wizard, replacing the default Web-based URL. Since you're synchronizing from an OS repository image, you don't need to specify a key or certificate for the operation.

For disconnected mode configuration, specify the Solaris 11 directory along with the path to the disconnected mode bundle downloaded by running the Ops Center harvester script:

Ops Center will run a job to import package content from the mounted ISO image. A synchronization job can take several hours to run – in my case, the job ran for 3 hours, 22 minutes on a SunFire X4200 M2 server.

During the job, Ops Center performs three important tasks:

  1. Synchronizes all content from the image and refreshes the repository
  2. Updates the IPS publisher information
  3. Creates OS Provisioning profiles and policies based on the content

When the job is complete, you can unmount the ISO image from your Enterprise Controller. At that time, you can view the repository contents in your Ops Center Solaris 11 library. For the Solaris 11 11/11 release, you should see 8,668 packages and patches in the contents.

You should also see default deployment plans for Solaris 11 provisioning. As part of the repository import, Ops Center generates plans and profiles for desktop, small and large servers for the SPARC and X86 architecture.

Part 2: Using a Solaris 11 SRU to update an Ops Center Repository

It's possible to use the same approach to upgrade your Ops Center repository to a Solaris 11 Support Repository Update, or SRU. Each SRU provides packages and updates to Solaris 11 - for example, SRU 8.5 provided the packaged for Oracle VM Server for SPARC 2.2

SRUs are available for download as ISO images from My Oracle Support, under document ID 1372094.1. The document provides download links for all SRUs which have been released by Oracle for Solaris 11. SRUs are cumulative, so later versions include the packages from earlier SRUs.

After downloading an ISO image for an SRU, you can mount it to your local filesystem using a mount command similar to the one shown for Solaris 11 11/11.

When the ISO image is mounted to the file system, you can perform the Add Content action from the Solaris 11 Library to synchronize packages and patches from the mounted image. I used the same mount point, so the repository URL was file://mnt/repo once again:

After the synchronization of an SRU is complete, you can verify its content in the Solaris 11 library using the search function. The version pattern is 0.175.0.#, where the # is the same value as the SRU.

In this example, I upgraded to SRU 1. The update job ran in just under 8 minutes, and a quick search shows that 22 software components were added to the repository:

It's also possible to search for "Support Repository Update" to confirm the SRU was successfully added to the repository. Details on any of the update content are available by clicking the "View Details" button under the Packages/Patches entry.

Wednesday Nov 07, 2012

Keeping track of File System Utilization in Ops Center 12c

Enterprise Manager Ops Center 12c provides significant monitoring capabilities, combined with very flexible incident management. These capabilities even extend to monitoring the file systems associated with Solaris or Linux assets. Depending on your needs you can monitor and manage incidents, or you can fine tune alert monitoring rules to specific file systems.

This article will show you how to use Ops Center 12c to

  • Track file system utilization
  • Adjust file system monitoring rules
  • Disable file system rules
  • Create custom monitoring rules

A recording of this community call is now available here:

Monitoring File Systems for OS Assets

The Libraries tab provides basic, device-level information about the storage associated with an OS instance. This tab shows you the local file system associated with the instance and any shared storage libraries mounted by Ops Center.

More detailed information about file system storage is available under the Analytics tab under the sub-tab named Charts. Here, you can select and display the individual mount points of an OS, and export the utilization data if desired:

In this example, the OS instance has a basic root file partition and several NFS directories. Each file system mount point can be independently chosen for display in the Ops Center chart.

File Systems and Incident  Reporting

Every asset managed by Ops Center has a "monitoring policy", which determines what represents a reportable issue with the asset. The policy is made up of a bunch of monitoring rules, where each rule describes

  • An attribute to monitor
  • The conditions which represent an issue
  • The level or levels of severity for the issue

When the conditions are met, Ops Center sends a notification and creates an incident.

By default, OS instances have three monitoring rules associated with file systems:

  • File System Reachability: Triggers an incident if a file system is not reachable
  • NAS Library Status: Triggers an incident for a value of "WARNING" or "DEGRADED" for a NAS-based file system
  • File System Used Space Percentage: Triggers an incident when file system utilization grows beyond defined thresholds

You can view these rules in the Monitoring tab for an OS:

Of course, the default monitoring rules is that they apply to every file system associated with an OS instance. As a result, any issue with NAS accessibility or disk utilization will trigger an incident. This can cause incidents for file systems to be reported multiple times if the same shared storage is used by many assets, as shown in this screen shot:

Depending on the level of control you'd like, there are a number of ways to fine tune incident reporting.

Note that any changes to an asset's monitoring policy will detach it from the default, creating a new monitoring policy for the asset. If you'd like, you can extract a monitoring policy from an asset, which allows you to save it and apply the customized monitoring profile to other OS assets.

Solution #1: Modify the Reporting Thresholds

In some cases, you may want to modify the basic conditions for incident reporting in your file system. The changes you make to a default monitoring rule will apply to all of the file systems associated with your operating system. Selecting the File Systems Used Space Percentage entry and clicking the "Edit Alert Monitoring Rule Parameters" button opens a pop-up dialog which allows you to modify the rule.

The first screen lets you decide when you will check for file system usage, and how long you will wait before opening an incident in Ops Center. By default, Ops Center monitors continuously and reports disk utilization issues which exist for more than 15 minutes.

The second screen lets you define actual threshold values. By default, Ops Center opens a Warning level incident is utilization rises above 80%, and a Critical level incident for utilization above 95%

Solution #2: Disable Incident Reporting for File System

If you'd rather not report file system incidents, you can disable the monitoring rules altogether. In this case, you can select the monitoring rules and click the "Disable Alert Monitoring Rule(s)" button to open the pop-up confirmation dialog.

Like the first solution, this option affects all file system monitoring. It allows you to completely disable incident reporting for NAS library status or file system space consumption.

Solution #3: Create New Monitoring Rules for Specific File Systems

If you'd like to have the greatest flexibility when monitoring file systems, you can create entirely new rules. Clicking the "Add Alert Monitoring Rule" (the icon with the green plus sign) opens a wizard which allows you to define a new rule.

 This rule will be based on a threshold, and will be used to monitor operating system assets. We'd like to add a rule to track disk utilization for a specific file system - the /nfs-guest directory. To do this, we specify the following attribute

The value of name in the attribute allows us to define a specific NFS shared directory or file system... in the case of this OS, we could have chosen any of the values shown in the File Systems Utilization chart at the beginning of this article.

usedSpacePercentage lets us define a threshold based on the percentage of total disk space used. There are a number of other values that we could use for threshold-based monitoring of FileSystemUsages, including

  • freeSpace
  • freeSpacePercentage
  • totalSpace
  • usedSpace
  • usedSpacePercentage

The final sections of the screen allow us to determine when to monitor for disk usage, and how long to wait after utilization reaches a threshold before creating an incident. The next screen lets us define the threshold values and severity levels for the monitoring rule:

If historical data is available, Ops Center will display it in the screen. Clicking the Apply button will create the new monitoring rule and active it in your monitoring policy.

If you combine this with one of the previous solutions, you can precisely define which file systems will generate incidents and notifications. For example, this monitoring policy has the default "File System Used Space Percentage" rule disabled, but the new rule reports ONLY on utilization for the /nfs-guest directory.

Stay Connected:

Twitter |  Facebook |  YouTube |  Linkedin |  Newsletter

Thursday Sep 13, 2012

Upgrading Agent Controllers in Oracle Enterprise Manager Ops Center 12c

Oracle Enterprise Manager Ops Center 12c recently released an upgrade for Solaris Agent Controllers. In this week's blog post, we'll show you how to upgrade agent controllers.

Detailed instructions about upgrading Agent Controllers are available in the product documentation here. This blog post uses an Enterprise Controller which is configured for connected mode operation. If you'd like to apply the agent update in a disconnected installation, additional instructions are available here.

Step 1: Download Agent Controller Updates

With a connected mode Ops Center installation, you can check for product updates at any time by selecting the Enterprise Controller from the left-hand Administration navigation tab.

Select the right-hand Action link “Ops Center Downloads” to open a pop-up dialog displaying any new product updates. In this example, the Enterprise Controller has already been upgraded to the latest version (Update 1, also shown as build version 2076) so only the Agent Controller updates will appear.

There are three updates available: one for Solaris 10 X86, one for Solaris 8-10 SPARC, and one for all versions of Solaris 11. Note that the last update in the screen shot is the Solaris 11 update; for details on any of the downloads, place your mouse over the information icon under the details column for a pop-up text region.

Select the software to download and click the Next button to display the Ops Center license agreement.

Review and click the check box to accept the license agreement, then click the Next button to begin downloading the software.

The status screen shows the current download status. If desired, you can perform the downloads as a background job. Simply click the check box, then click the next button to proceed to the summary screen.

The summary screen shows the updates to be downloaded as well as the current status. Clicking the Finish button will close the dialog and return to the Browser UI. The download job will continue to run in Ops Center and progress can still be viewed from the jobs menu at the bottom of the browser window.

Step 2: Check the Version of Existing Agent Controllers

After the download job completes, you can check the availability of agent updates as well as the current versions of your Agent Controllers from the left-hand Assets navigation tab.

Select “Operating Systems” from the pull-down tab lets to display only OS assets. Next, select “Solaris” in the left-hand tab to display the Solaris assets. Finally, select the Summary tab in the center display panel to show which versions of agent controllers are installed in your data center.

Notice that a few of the OS assets are not displayed in the Agent Controllers tab. Ops Center will not display OS instances which do not have an Agent Controller installation. This includes Enterprise Controllers and Proxy Controllers (unless the agent has been activated on the OS instance) and and OS instances using agentless management.

For Agent Controllers which support an update, the version of agent software (in this example, 2083) appears to the right of the currently installed version.

Step 3: Upgrade Your Agent Controllers

If desired, you can upgrade agent controllers from the previous screen by selecting the desired systems and clicking the upgrade button. Alternatively, you can click the link “Upgrade All Agent Controllers” in the right-hand Actions menu:

In either case, a pop-up dialog lets you start the upgrade process. The first screen in the dialog lets you choose the upgrade method:

Ops Center provides three ways to upgrade agent controllers:

  • Automatic Upgrade: If Agent Controllers are running on all assets, Ops Center can automatically upgrade the software to the latest version without requiring any login credentials to the system
  • SSH using a single set of credentials: If all assets use the same login credentials, you can apply a single set to all assets for the upgrade process. The log-in credentials are the same ones used for asset discovery and management, which are stored in the Plan Management navigation tab under Credentials.
  • SSH using individual credentials: If assets use different login credentials, you can select a different set for each asset.

After selecting the upgrade method, click the Next button to proceed to the summary screen. Click the Finish button to close the pop-up dialog and start the upgrade job for the agent controllers.

The upgrade job runs a series of tasks in parallel, and will upgrade all agents which have been selected. Once the job completes, the OS instances in your data center will be upgraded and running the latest version of Agent Controller software.

Monday Jul 23, 2012

Oracle Enterprise Manager Ops Center 12c Update 1 - Additional Information and Best Practices

Oracle Enterprise Manager Ops Center 12c Update 1 was released earlier this month. Eran Steiner , Technical Architect, Oracle Enterprise Manager, adds some additional information and best practices about upgrading to Ops Center 12c Update 1 in this blog.

Eran hosted a call to provide an overview of Oracle Enterprise Manager Ops Center 12c Update 1 and answer any questions.The recording of this call is available here and the presentation can be downloaded here.

[Read More]

Monday May 21, 2012

Benefits of using Ops Center to deploy and manage Solaris 11

One of the more significant new features in Oracle Enterprise Manager Ops Center 12c is the ability to install Ops Center on Oracle Solaris 11, and to deploy and manage systems running Solaris 11.  The Solaris 11 capabilities are in addition to the analogous features for Solaris 10 and Linux, which can all be handled from the same Ops Center infrastructure.

When the Ops Center Enterprise Controller (EC) is installed on a system running Solaris 11, the EC can create a Solaris 11 Software Update Library containing Oracle Solaris Image Packaging System (IPS) content that is synchronized with the main Oracle repository at The Ops Center managed Solaris 11 repository becomes the package (pkg) publisher for downstream Solaris 11 deployments and updates on all Solaris 11 systems being managed by Ops Center.

Ops Center provides the ability to define Solaris 11 OS and Software Profiles comprised of Oracle Solaris 11 packages, user-supplied custom packages, scripts, and other files.  Such Software Profiles profiles can then be used to install and update software on systems already running Solaris 11 in a structured and consistent way.  Ops Center not only caches the main Oracle Solaris IPS repository, but more importantly it gives admins the ability to define their own preferred collection of packages so that systems can easily be kept in sync with each other, running a well-defined, life-cycle-managed Standard Operating Environment (SOE), instead of just whatever the latest content is at

Ops Center 12c also adds Solaris 11 features for bare-metal OS Provisioning, based on the Solaris 11 Auto Install (AI) facility.  Ops Center configures the Solaris 11 AI in a way that shields admins from needing to write custom AI manifests or custom "first boot" packages.  Solaris 11 deployments using Ops Center follow similar profile-based patterns as for Solaris 10 or Linux, all of which can all be deployed from the same Ops Center infrastructure running on Solaris 11.  The gory details of all these different times of bare-metal OS Provisioning are handled automatically for the user so that he or she does not need to put time and resources into manually creating and maintaining infrastructure for deploying different OS's natively -- Solaris 11 with AI, Solaris 10 JumpStart with JET, or Linux with Kickstart or AutoYast.  All of those OS's are handled by Ops Center under the covers, based on whatever network boot capability the OS requires (PXE/DHCP, WANBOOT, or AI), and all from the same Ops Center infrastructure running on Solaris 11.

Specific to Solaris 11 OS Provisioning (via AI), Ops Center provides its own "first-boot" package+scripts to customize the Solaris 11 deployment, and in particular this approach automatically installs the Ops Center agent.  With the Ops Center Agent in place right from the start, it is easy to handle post-install steps using the Ops Center features for handling Solaris 11 OS and Software Profiles containing additional packages, scripts, and content from the Solaris 11 Software Library, described above.

Tying bare-metal Solaris 11 deployment and post-install customization together is a key way that Ops Center simplifies the overall life-cycle management for Solaris 11 (in addition to Solaris 10 and Linux).   For example, a top-level plan based on "Configure and Install Logical Domains" can create numerous Logical Domains into an Oracle VM Server for SPARC "Server Pool" and provision Solaris 11 into each LDom Guest based on a powerful multi-step "Install Server" plan.  Such a plan can cover the end-to-end steps for installing and updating the OS, running scripts and adjusting monitoring parameters, etc.

Here is an example of the kinds of activities that can be performed in conjunction an OS Deployment, or separately, depending on the need:

Oracle Enterprise Manager Ops Center 12c Deployment Plan

NOTE: In the above example, the last step "Create Guests" can be used to create one or more Solaris Containers within the LDom Guest, rounding out the end-to-end deployment all the way from LDom Guest to Solaris 11 Global Zone to multiple Solaris Containers, if so desired.

One of the nicest aspect of deploying and managing Solaris 11 using Ops Center Plans and Profiles is that the same content can be applied as updates to existing Solaris 11 systems, aligned to the same content as chained off a bare-metal OS Provisioning.  It is up to the user which steps they want to include in a deployment plan -- whether they are updating Software Profiles on systems deployed 6 months ago to match the latest standard, or they are deploying new systems based on that same standard, Ops Center provides the means to insure that the outcome is consistent.

Here is an example of the kinds of activities that can be performed on an existing Solaris 11 OS -- either ad hoc, or immediately after a Solaris 11 OS Provisioning step, so that whether the life-cycle started with a new system, or the intent is to update a system deployed six months ago, the outcome can be the same:

S11 Update Multi-Step Plan

In short, Ops Center running on Solaris 11 can manage Solaris 10 and Linux systems, all from a common infrastructure, and all based on a simplified, consistent, profile- and plan-based way to do the OS and Software deployments and updates.  The net effect is an easy to use way to managing the life-cycle of heterogeneous systems, in a very consistent way through automation and re-use.

Please let us know what you think?  Until next time...

Leon Shaner | Senior IT/Product Architect
Systems Management | Ops Center Engineering @ Oracle

The views expressed on this [blog; Web site] are my own and do not necessarily reflect the views of Oracle.

For more information, please go to Oracle Enterprise Manager  web page or  follow us at : 

Twitter | Facebook | YouTube | Linkedin | Newsletter

Tuesday Apr 24, 2012

Demo Series : Gain Total Cloud Control of Systems with Enterprise Manager Ops Center 12c

Earlier this month, at Oracle Enterprise Manager Ops Center 12c launch, we published a series of demos of Oracle Enterprise Manager Ops Center 12c  managing various Oracle solutions from applications to hardware . You could see all of those demos by clicking the graphic below.  Following the graphics below, I have a brief overview of an enterprise customer scenario and various demos highlighting the management of various systems .

Demo Series - Explore Oracle Enterprise Manager Ops Center 12c

A Step-by-Step Journey to Enterprise Clouds

A large global financial company serving millions of customers worldwide has decided to investigate a private cloud infrastructure. They have multiple business units and are located in multiple regions worldwide.

Their enterprise applications include Oracle Siebel CRM, Oracle E-Business Suite Financials, and PeopleSoft HCM. They have recently added several Oracle Fusion Applications modules to enhance their CRM and HCM capabilities. Over time, they have also deployed a number of Java and web-based applications. They use Oracle Solaris/SPARC environments for their E-Business Suite applications. Their web servers, some of their application servers, and a number of the home grown applications run on Oracle Enterprise Linux and Oracle x86 servers. They have deployed Oracle virtualization solutions for x86 servers and SPARC.

This company is transitioning their IT to a private cloud environment to support the CEO’s new corporate strategy to increase operational efficiency by 10% while growing the top line by 30% in two years. The IT organization, led by their CIO, considered various options and concluded that achieving the CEO’s objectives would require them to transition their enterprise applications to the cloud, thereby creating real differentiation in how they service their customers. They reviewed several vendors and concluded that their private cloud solutions were adequate for small applications but too risky for enterprise applications. They decided to go with the an Oracle solution because only Oracle was able to demonstrate a proven solution to power enterprise applications while also leveraging SPARC and x86 virtualization for a complete cloud management solution.

They have already started to deploy Database-as-a-Service and Fusion Middleware-as-a-Service clouds using Oracle Enterprise Manger Self Service Application Portal. They plan to deploy Infrastructure-as-Service cloud based on both SPARC and x86 servers with Oracle virtualization solutions and manage them through Oracle Enterprise Manager Ops Center. They have recently deployed many ExaData systems. They are starting to deploy ExaLogic and Super Clusters Engineered systems as well to accelerate performance and time to market.

Integrated Linux Management in the Cloud

Linux Management functionality is available as part of Oracle Enterprise Manager 12c and is available to Oracle Linux Basic and Premier Support customers at no cost. The solution provides an integrated and cost-effective solution for complete Linux server lifecycle management and delivers comprehensive provisioning, patching, monitoring, and administration capabilities via a single, web-based user interface thus significantly reducing the complexity and cost associated with managing Linux operating system environments.

Using these rich Linux management features along with the complete Oracle Enterprise Manager product solution, the global financial company takes advantage of enterprise-scale service level management, automated change and configuration management, and comprehensive system and application performance management.

Integrated Lifecycle Management for Physical and Virtual Servers in the Cloud

Oracle VM offers server virtualization for both x86 and SPARC architectures that enable the deployment of agile cloud infrastructures. Virtualized server environments integrated with Oracle Enterprise Manager Ops Center allow you to easily create, deploy, clone virtual servers, and live migrate workloads while dynamically controlingcompute resources. Integrated lifecycle management of both physical & virtual servers with Ops Center simplifies the daily workflowneeded to control cloud infrastructures. This is one of the key reasons why this company decided power their private cloud with Oracle virtualization technologies.

Oracle Solaris 11 – The First Cloud OS

With its new and improved features, Oracle Solaris brings mission-critical enterprise class computing to cloud scale environments. These features include extremely agile, no overhead virtualization, simplified software lifecycle management, and built-in security across all layers. Oracle Enterprise Manager Ops Center understands all these new technologies, and therefore is the perfect tool to manage Oracle Solaris deployments at data center and cloud scales.

Manage Mission Critical Applications in the Cloud

Deploying and managing mission critical applications in cloud are one of the key strategic interests of the enterprises. Oracle SPARC based Infrastructure-as-a-Service ( IaaS ) offers the scale, reliability, and performance needed for those mission critical applications. In this demo, you will learn about how to manage SPARC server platforms, which is the foundation of the enterprise cloud this global financial company wants to deploy The Oracle SPARC technologies offers an extreme thread count and memory density in a small and eco-friendly form factor. This company wanted to insure they could leverage their existing SPARC population with not excluding new growth into the T4 chassis models. They found Ops Center offered them complete coverage of where they were the most invested.

Private PaaS and IaaS Cloud with Oracle Enterprise Manager

Oracle Enterprise Manager provides complete lifecycle management for cloud - from automated cloud setup, to delivery, to cloud operations. Learn how Oracle Enterprise Manager Cloud Control 12c and Oracle Enterprise Manager Ops Center 12c work together to provide an end-to-end solution to take you from zero to cloud in a day, whether the goal of your private cloud is Infrastructure as a Service (IaaS) or Platform as a Service (PaaS).

Managing DBaaS and MWaaS Cloud Services Delivery with Oracle Enterprise Manager

This demo showcases Engineered Systems Management capabilities of Oracle Enterprise Manager Cloud Control and Ops Center 12c. You can now manage all components of Oracle Exadata Database Machine, from databases to cell storage to network swicthes, from a single console. Similarly, you can now manage all aspects of Oracle Exalogic, including software and hardware, from a single console. Learn how Oracle Enterprise Manager is engineered systems-aware and provides insight into the performance, configuration and physical health of these highly performance machines.

Simplify Your Data Center with Exalogic Elastic Cloud

Oracle Exalogic Elastic Cloud is the industry’s Best Foundation for Cloud. It is hardware and software engineered together to provide extreme performance for Java applications, Oracle Applications, and other enterprise applications. Exalogic offers fully integrated compute nodes, storage and networking, fully integrated ZFS network attached storage appliance with 40TB of SAS disk storage, QDR InfiniBand IO Fabric, with 40 Gb/second throughput and microsecond latencies, Data center service network integration with 10 GbE, Scalable, open standard grid architecture. That means less effort spent by you on putting the pieces together and more time spend on extending the business value of your applications.

Check out this demonstration to learn more about Exalogic and the right configuration that meets your needs.

Oracle Software Runs Best on Oracle Hardware

Oracle Enterprise Manager offers the right amount of information across the stack, breaking down isolated IT organizations and helps make a stronger connection between the business services and the server assets they utilize.

To learn more, please go to Oracle Enterprise Manager  web page and stay connected with us at  :

Twitter | Facebook | YouTube | Linkedin | Newsletter

Tuesday Apr 10, 2012

A new version of Oracle Enterprise Manager Ops Center Doctor (OCDoctor ) Utility released

In February,  we posted a blog of Oracle Enterprise Manager Ops Center Doctor aka OCDoctor Utility. This utility assists in various stages of the Ops Center deployment and can be a real life saver. It is updated on a regular basis with additional knowledge (similar to an antivirus subscription) to help you identify and resolve known issues or suggest ways to improve performance.

A new version ( Version 4.03 ) of the OCDoctor is now available . This new version adds full support for recently announced Oracle Enterprise Manager Ops Center 12c including prerequisites checks, troubleshoot tests, log collection, tuning and product metadata updates. In addition, it adds several bug fixes and enhancements to OCDoctor Utility.

To download OCDoctor for new installations:

For existing installations, simply run:
# /var/opt/sun/xvm/OCDoctor/ --update

Tip : If you have Oracle Enterprise Manager Ops Center12c EC installed, your OCDoctor will automatically update overnight.

Stay connected with  Oracle Enterprise Manager   : 

Twitter | Facebook | YouTube | Linkedin | Newsletter

Tuesday Mar 06, 2012

How to use Oracle Enterprise Manager Ops Center to patch your Solaris Systems ?

Oracle Enterprise Manager Ops Center allows you to update your Solaris systems with patches available from My Oracle Support (MOS).

Like always in life, there are multiple ways to perform a given task and the same is true for Ops Center.

Juergen Fleischer, Senior IT/Product Architect , Oracle Enterprise manager Ops center provided the content for this blog to guide you through different ways to perform Oracle Solaris patching depending on deployment scenarios.

Scenario 1 - Applying a single Patch to an Asset

Let's start with installing just a single patch to a system. To perform this task you would select the OS Asset and pick the action 'View/Modify Catalog' from the right hand side Actions panel.

From the pop-up screen, you can search for the patchid, see which revision is already installed and select a newer one if required.

Here is a MOS how-to document describing this in all detail:

Scenario 2 - Applying multiple patches to several systems

If you have to apply a list of patches to multiple systems every now and then, creating an Update Profile would be the best method, as once you have created the Profile it can be used many times ensuring the exact same patches in the list are applied each and every time.

Update Profiles are located in the 'Plan Management' section. Update Profiles can be used in two ways: either you select a single or a group of OS assets and pick the action 'New Update OS Job'. Or, you pick the Update Profile in the Plan Management section and select 'New Update OS Job'. The wizard will allow you to select one or more target assets or groups.

Here is a MOS how-to with all the details:

Scenario 3 - Regular Baseline Patching

For regular Baseline Patching 'Update Profiles' can be based on given patchsets which are made available by the Ops Center Knowledge Base (KB).

The KB offers two different patchsets, the monthly released Solaris Baselines (based on Oracle's internal EIS-DVD) and the current or archived versions of the "Recommended Patchset for Solaris". These are updated whenever a new critical patch gets released. Every quarter, one of these Recommended Patchsets for Solaris will be renamed as the 'Critical Patch Update' in line with standard Oracle practice. It's up to the Customer's patching policy and strategy to determine which patchsets should be used and how often they should be applied.

Scenario 4 - Latest & Greatest patchset

Finally, if required, Customers can select what is called "Latest & Greatest" patchset. These are all the latest available patches for all installed packages. To perform this task, use the 'Host Compliance Report' and tick the Security & Bug Fixes check box.

More details can be found in this blog entry

or in this MOS how-to document:

So far, we have talked about various scenarios around applying a single patch or multiple patches.  These patches can be applied on a running system or by using LiveUpgrade (LU).  LU allows creating Alternate Boot Environment (ABE), Synchronizing boot environments, Patching the ABE and then Activating the ABE.
For detailed examples and howto examples:

Before using LiveUpgrade, please verify that the latest LU-Patch (sparc: 121430, x86: 121431) is  installed on the running system.

Furthermore, when payching zones always make use of the parallel zone patching feature, independent if using LU or not. Following blog entry describes this very well :

Stay Connected:
Twitter | Facebook | YouTube | Linkedin | Newsletter

Wednesday Oct 27, 2010

New IDC Podcast on Systems Management

[Read More]

Latest information and perspectives on Oracle Enterprise Manager.

Related Blogs


« October 2015