By Rodney Lindner-Oracle on Jan 12, 2015
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.
[ 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
- 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 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 192.168.20.0/24
- 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 10.187.56.0/24 network.
Create a new name and description.
Configure our rule, but this time look for Non Global Zones on the 10.187.56.0 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 10.187.56.0 subnet and one more zone on the 192.168.20.0 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.
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):
|PRODUCTION_STATUS||DEV/UAT/PROD||The value describes the production status DEV/UAT/PROD
||email@example.com||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.
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.