This post describes the implementation of the Administration Groups and Template Collections with Oracle Enterprise Manager Cloud Control 12c. Administration Groups (improvement of Grid 10g Target Groups) and Template Collections improve the management of targets and ease the implementation of the monitoring strategy.
Administration Groups allow to organize targets according to several criteria. For instance the Lifecycle status of the target (prod, dev, integration), the location of the target (its city or country), aso … The main goal is to apply common settings (i.e monitoring settings) to targets having the same purpose.
The first point about administration groups is to define a clear concept and the hierarchy between these several criteria. The administration groups must be organized in a convenient way according to the company organization. In the next chapter we will present how to handle the default hierarchy existing in Cloud Control 12c in order to change it in an administration group organization fitting to the company structure.
The target property is used to implement automatically the target in the appropriate administration group.
An example
In the following example, based on the existing administration groups we will create the following hierarchy which matches to the company organization:
Basically the company has two groups of systems, one for managing the sales and one for managing the costs. The “systems” can be any kind of targets: databases, Weblogic servers, hosts, etc. Each of these systems exist in PRODUCTION and DEVELOPMENT lifecycle status. It has been decided to group all production targets together and then separate the targets in underlying groups according to their “role”, COST or SALES, of course the same strategy has been followed for DEV.
Let’s see how we can realize this.
To create an Administration Group, you have to choose Setup → Add target → Add Administration Groups.
First of all, we have to select the “primary” criteria to sort the targets in the administration group hierarchy. In our case we use the “Lifecycle status” hierarchy level as root :
By default, the following hierarchy is created:
The different hierarchy levels are:
We can merge “Mission Critical” and “Production”, and on an other side we can merge “Test Staging” and “Development” we keep the control keypad and we select Development, Staging and Test , then we select Merge:
We have to perform the same operations for “Production” and “Mission Critical”. At the end, we have the following hierarchy:
We can modify the name of the Deve-Grp to DEV and make the same for the MC_GRP to PROD:
And finally we obtain:
Then, we can add a new hierarchy level by choosing Line of business, for example:
We now have the following organization for example with Costs and Sales:
Like in the previous stage we can change the name of the sub-groups:
Do not forget to click on the create button and the administration Group is created:
The next step is about Template Collections. Template collections is an extension of the existing monitoring templates (available since Grid Control 10g). Template collections allow to group several templates for several kinds of targets in one entity which can be “applied” to an Administration Group. To create a template collection we choose the Setup Menu → Administration Group and we select “Template Collections”:
The classical database, listener and host templates have already been created, we choose “Add” to create a Collection Template which consists of a set of these templates:
We have to associate the monitoring templates to the Admin Groups. We select “Association” and we select the DEV_GROUP , we choose Associate Template Collection and we associate the DEV_GRP to the DEV monitoring template:
We associate the PROD monitoring templates to the PROD_GRP. By doing this the sub group get the properties of their parent group. We can check for example the monitoring setting of the DEV_SALES_GROUP. We select this sub-group and we select “View Aggregate Settings”:
Now, we have to associate the different targets to the groups. Let’s check how to realize this operation. For a database we select a Database and choose Oracle Database → Target Setup → Properties:
We edit the life cycle status to Production:
Another solution is to use emcli on the OMS server to modify the target properties in case of huge number of targets. At first, we setup emcli on the OMS server:
racle@eurorclg02:/u01/app/oracle/Middleware/oms/bin/ [oms12c] ./emcli setup -url=https://vmtestoraem12c.it.dbi-services.com:4900/em/ -username=sysman Oracle Enterprise Manager Cloud Control 12c Release 12.1.0.1.0. Copyright (c) 1996, 2011 Oracle Corporation and/or its affiliates. A ll rights reserved. Enter password Do you trust the certificate chain? [yes/no] yes Emcli setup successful
We have to use the set_target_property_value to update the property for a target Watch out most of those arguments are case sensitive ! The official syntax is:
emcli set_target_property_value -property_records="target_name:target_type:property_name:property_value"
If we need to update the property LifeCycle Status to Production for the DB112 database, we have to run:
oracle@eurorclg02:/u01/app/oracle/Middleware/oms/bin/ [oms12c] emcli set_target_property_value -property_records="DB112:oracle_database:LifeCycle Status:Production" Properties updated successfully
If we now select the PROD_SALES_GROUP, let’s see if we have targets defined on it. We select the PROD_SALES_GROUP and we select Go To Group Home Page:
We can see the DB112 target database, however, this database is not synchronized. We have to select “Start Synchronization” to apply the templates right now, it takes a little time but finally the target gets synchronized:
We make the same operations for the other groups and finally, our Administration Group Infrastructure is ready !
Limitations
Hierarchy levels organization:
The hierarchy levels are “redundant”, which means that each level contains the same sub-levels.
In the following example : http://docs.oracle.com/cd/E24628_01/doc.121/e24473/administration_group.htm#autoId5 “Prod” and “Staging” have the same locations and each location has the same “line of businesses”. We might imagine systems with different “life cycle status” (i.e PROD/TEST) located at different place (i.e PROD at ZH/BSL for PROD and test at GVA/LS for TEST). However this does not seem to be possible with the current implementation.
Hierarchy maintenance:
To modify the hierarchy , the whole hierarchy is dropped and removed. This might also be a source of loosing some settings, therefore the concept must be correctly defined from scratch.
Definition of some monitoring settings (i.e monitoring configuration) :
It is not possible to setup the monitoring configuration (i.e dbsnmp username and password) for an administration group. Furthermore it is not possible to set a “generic” connect string like a SCAN IP in a cluster for instance. This feature would prevent to configure individually each target.
Conclusion
The use of Administration Groups and Template collections eases the automation of monitoring different kind of targets. The main advantage is the automatic registration of the target to a specific administration group as soon as a property is assigned to a target. This is quite interesting for DBAs, because they will not forget to administer targets in huge data centers, for example.
Cet article Oracle Enterprise Manager 12c: Administration Groups & Template Collections est apparu en premier sur Blog dbi services.
