Thursday May 28, 2015

Uploading and Deploying Oracle Solaris 11 Files

I saw a question recently about uploading flat files, such as a config file, or tarballs to an Oracle Solaris 11 library and then deploy them to Oracle Solaris 11 servers. This is an easy task for Oracle Solaris 8, 9, or 10, but it's trickier to find with Oracle Solaris 11.

Here are the steps to upload and deploy such files with Oracle Solaris 11 in Ops Center, using our software library for the content.

  1. Create an Oracle Solaris 11 pkg which contains the config files. Here's an example for how to do so: http://docs.oracle.com/cd/E23824_01/html/E21798/glcej.html
  2. Add that pkg to the repository. (The above example also covers this step.)
  3. Sync Ops Center with the repository so that the new pkg is added to Ops Center's catalog of software.
  4. Create an Ops Center Oracle Solaris 11 Profile that installs the pkg created in Step 1.
  5. Apply the profile in an update plan to the target systems.

For more information about OS Profiles, see the OS Updates chapter.

Thursday May 21, 2015

Special Database Options

When you're installing Ops Center, you have two options for the product database: You can use an embedded database, that's automatically installed on the Enterprise Controller and managed by Ops Center, or you can use a remote database that you manage yourself.

With regards to the customer-managed database, I saw an important question recently: When you install this database, do you have to enable any of the advanced or special features? Some folks want to use the bare minimum installation for security reasons.

The answer here is that Ops Center only requires the base installation; no special features are used. As long as you're using one of the DB versions listed in the Certified Systems Matrix, you're golden.

Thursday May 07, 2015

Clustered Ops Center installation

Today's question from an Ops Center user:

"Can we cluster Ops Center deployments using, say, Solaris Cluster? How would we do it?"

Well, there are a couple of possible ways that you can install the Enterprise Controller so that it can fail over.

The first method is to use the documented HA installation, which uses Oracle Clusterware, two or more Enterprise Controller systems, and a remote customer-managed database. The procedures for this kind of installation are documented in the Oracle Solaris and Linux install guides.

The second is to install the Enterprise Controller in an LDom controlled by Oracle Solaris Cluster, and then have the Enterprise Controller fail over between hosts via Cluster. You can use an embedded database or a remote database with this solution.

Thursday Apr 30, 2015

Using Maintenance Mode

So, after last week's post about blacklisting assets for Ops Center, a couple of people pointed out that there's another - probably easier - way of temporarily stopping an asset from generating ASRs if you're doing maintenance on it: Putting the asset in maintenance mode.

Putting an asset in maintenance mode stops it from generating new incidents, so that when you power off or reconfigure it, Ops Center doesn't freak out. Ops Center doesn't stop managing the asset, and you can then disable maintenance mode when you're done.

Bear in mind that Ops Center will also treat the asset as though it's about to go down: If you put a Proxy Controller in maintenance mode it can't run jobs, and if you put an Oracle VM Server for SPARC in maintenance mode Ops Center will try to migrate its guests to another system in the server pool, or stop them if no other system is available.

Take a look at the Incidents chapter in the Feature Reference Guide for more information about maintenance mode.

Thursday Apr 23, 2015

Disabling ASR for a specific asset

Enabling ASR for your environment helps you get quick assistance when you have a hardware issue - Ops Center takes asset information when a hardware incident occurs, and generates a service request based on contact information and MOS credentials that you've provided.

The trick, though, is that you enable ASR for your entire environment. You can provide separate contact info for some groups, but when you enable it it's on for all assets that are associated with the credentials. So, what if you're performing some hardware maintenance, and you don't want to accidentally cause ASR to open a service request?

In cases like this, you can add an asset to a blacklist, to prevent ASRs from being generated for it. Select the Enterprise Controller from the admin section of the UI, then click configuration. In the list of subsystems, select Auto Service Request. You can then enter one or more serial numbers in a comma-separated list in the serial blacklist field to disable ASR creation for those assets. Monitoring of the assets still happens, and ASRs are created for other assets as normal.

The ASR chapter in the Admin guide goes into more detail about how to get ASR running.

Thursday Apr 16, 2015

LDom versions

I saw a recent question about LDOM versions that come along with Oracle Solaris versions:

"I'm looking at upgrading some of my Control Domains to Oracle Solaris 11.2 SRU 8, which comes with LDoms 3.2. If I upgrade, will the new version be supported for migration?"

LDoms 3.2 is not yet supported by Ops Center, so if you start using it, you'll find that Ops Center won't know how to find migration targets for it.

If you're interested in which versions are supported, keep an eye on the Certified Systems Matrix; we'll add new versions there once they're certified.

Thursday Apr 02, 2015

Ops Center's port usage

I saw a question about the ports used by Ops Center:

"There's a table in the Ports and Protocols guide showing what ports have to be opened for Ops Center, but I'm confused about directionality. Do these ports have to be open bi-directional?"

Nope. The ports only have to be open in the direction indicated by the first column - so, the ports listed for "Enterprise Controller to Proxy Controller" only need to be open in that direction.

Thursday Mar 26, 2015

Modifying Asset Groups

I got a question recently about the system-defined groups used in Ops Center:

"As I started discovering assets in Ops Center, I saw that they were being sorted into system-defined groups based on asset type. How can I modify these groups for my environment - for example, to put assets from two different labs into two groups?"

Well, you can't. The system-defined groups will forever be system-defined. However, if you're looking for a way to control the way that your assets are organized, you can create user-defined groups.

For example, if you have two labs, you can create a group for each lab, and then add each asset to the correct lab group.

Another possibility is to use group rules to add the assets automatically. For example, when you discover the assets in Lab A, you could add a "LabA" tag to them. Then, you could set up a group for Lab A, and create a rule that will automatically add assets to the group if they have the "LabA" tag.

You can learn more about discovery and user-defined groups in the Asset Management chapter.

Thursday Mar 19, 2015

Tuning Asset Monitoring

The ability to monitor a variety of asset characteristics, like reachability and CPU usage, is one of Ops Center's strengths. However, sometimes you'll want to fine-tune this monitoring capability. Maybe you have a group of important operating systems and you want their monitoring rules to be more stringent, for example.

In cases like that, you can use monitoring policies to fine-tune the way that your assets are monitored. A monitoring policy specifies what thresholds are critical, such as reachability being false (duh) or memory usage being higher than 90%. These thresholds determine when incidents are raised on the monitored assets.

By creating a monitoring policy and applying it to an asset or a group of assets, you can effectively tell Ops Center which information about your assets is important to you, so that you see more signal and less noise.

There's more information about asset monitoring in the Monitoring Rules and Policies chapter of the Feature Reference Guide.

Thursday Mar 12, 2015

Giving Feedback in the OC Docs

There are a couple of features of the docs that are sometimes overlooked, so I thought I'd mention them.

If you click on a book in the documentation library, over on the left there are a couple of buttons. The feedback button lets you send us a message about the doc that you're looking at, so if something is confusing or incorrect, you can let us know and we'll fix it. There's also a download button where you can get a PDF of the current doc.


Also, if you're on the main page for Oracle Docs, there's a flying question mark box that you can click to give feedback about the doc site in general:


Speaking for our team, we do actually read those feedback messages, so let us know what you think.

Thursday Mar 05, 2015

Using Variables in Operational Plans

I saw a question recently about variables in operational plans, which I thought I'd discuss. If you're unfamiliar with them, operational plans let you create or upload scripts, then run those scripts on targeted systems through Ops Center.

The question was about the variables you can use in these scripts. There are two kinds of variables you can use: user-defined ones, which you have to create, or system defined variables which are defined by Ops Center. The system defined variables are listed in the documentation, but the questioner wasn't sure what each variable actually was. So, here's a list of the useful system variables and what they do:

  • $OC_UFN - The target asset's user-friendly name - the same name that's used in the UI.

  • $OC_JOB_ID - The Job ID number for the job that's applying the operational plan. A lot of users use this variable to help track changes that are made by a script.

  • $OC_TARGET_NAME - This is Ops Center's internal name for the target asset.

  • $OC_TARGET_TYPE - This is the type of asset that the script is being applied to.

There's more information about creating and applying Operational Plans in the Feature Reference Guide.

Thursday Feb 26, 2015

Database License

I saw a question about Ops Center's database license recently:

"Ops Center comes with a license for an Oracle Database. What if I want to set up multiple databases in a RAC? Is that covered by this license?"

The answer here is that Ops Center only comes with a license for a single instance of an Oracle Database. This can be either the embedded database or a single customer-managed database. If you want to set up multiple databases in a RAC for use by Ops Center, you'll need separate licenses for all but one of them.

Thursday Feb 19, 2015

Creating Networks for Server Pools

I've seen a couple of questions recently about creating networks for Server Pools. There's an important guideline that you should bear in mind, particularly when you're planning your Server Pools out: The servers in a server pool should be homogenous in terms of their network tagging mode.

The reason for this is that, if you had a Server Pool with servers using tagged and untagged networks, a guest migrated from one server to another could lose its network configuration.

The same principle applies even to standalone Oracle VM Servers for SPARC - you can't connect the same network to a standalone one in both tagged and untagged modes.

Thursday Feb 12, 2015

Discovery Changes

There were a few changes to the discovery process in Ops Center 12.2.2. If you've already upgraded, you might have noticed some of them, but I thought I'd give you the rundown.

The first change is an enhancement for zones and LDoms discovery. In version 12.2.2, when you discover a control domain or global zone and manage it with an Agent, any non-global zones or logical domains on them are discovered automatically. There are also some performance enhancements in this area, so the discoveries ought to go quicker now than in past.

The other change is that the Find Assets wizard, which searches for assets using service tags, is now disabled by default. This is mostly because, since this method searches for service tag-equipped products on all networks associated with a Proxy Controller, it can end up being a big resource drain/timesink in a very large environment. If you want, you can still enable it.

Thursday Feb 05, 2015

Access Point counts in the OCDoctor

When you're trying to figure out questions of scaling in Ops Center, it's important to be able to tell exactly how much load the different parts of the infrastructure are handling. In Ops Center, the relevant number is the access point count. An access point is a connection between a Proxy Controller and a managed asset. We don't just count the number of assets directly because, if different parts of an asset are managed by different Proxy Controllers, that puts more load on the system.

There's a tool in the OCDoctor's toolbox directory that lets you count the access points in your environment. The AssetCount.sh script gives you the total number of access points managed by the Enterprise Controller, and gives additional information depending on which option you use:

  • The standard option shows the number of access points for each Proxy Controller - both the total and a detailed breakdown by asset category.
  • The machine option gives a list of the access points on each Proxy Controller in machine-readable format.
  • The agent option shows, for each Proxy Controller, how many assets are agent-managed, how many are agentless, and how many are SPs.

The Scaling and Performance Guide explains how to use the AssetCount.sh script. You can find it in the version 12.2.2 documentation library.

About

This blog discusses issues encountered in Ops Center and highlights the ways in which the documentation can help you

Search

Archives
« May 2015
SunMonTueWedThuFriSat
     
1
2
3
4
5
6
8
9
10
11
12
13
15
16
17
18
19
20
22
23
24
25
26
27
29
30
31
      
Today