Thoughts on…

Java Middleware & Systems Management

Managing JBossAS Clusters via DynaGroups

leave a comment »

As your enterprise grows, it becomes increasingly difficult to individually manage the resources in your inventory. Compatible groups mitigate this issue by providing several features and functions that can be applied to all members of the group:

  • measurement data and graph averaging
  • group operation execution and scheduling
  • aggregate updates to plugin configurations (connection properties)

However, there still exists the problem of how to efficiently maintain your groups and their memberships. Let’s say you have a few dozen JBoss AS instances in inventory and you wanted to group them by the cluster each belongs to.

First of all, how do you even know how many clusters you have, and what each is identified by? This information is needed so you know how many compatible groups to create, and how to name each of them.

More generally, even if the cluster names were readily available, how do you find the information about which resources belong to which cluster? In well managed environments, the cluster information might be recorded in some kind of spreadsheet or well-formed xml file, or may be auto-generated into one of those formats by running some type of reporting tool against an internal database where this information is kept up-to-date.

In the best of circumstances, you still have a lot of manual, error prone work to do. You would need to take the information from your external system, manually create the groups, and manually update the membership of each.

OK, so maybe you take the blue pill and try to convince yourself this isn’t so bad; it might take a few hours to setup, but once it’s done it’s done…right? Well…no. What happens when your cluster changes? What if you have an environment that dynamically reprovisions generic machines as needed based on incoming load to each cluster? After a few provisioning iterations, the set of machines representing each cluster might be completely different from what they were a few days ago. So now you have the additional, still error prone, and even more difficult manual task of updating each of your groups to reflect this.

Granted, the above was a slightly contrived example to emphasize how daunting of a task this could be, but you’d be surprised at how often I see customers with pseudo-dynamic setups like this. Their provisioning might be fairly manual, and their changes might only occur once a week or so, but keeping this information up-to-date in multiple systems is a pain point for them nonetheless.

DynaGroups to the rescue. This construct, which has existed since the 0.1 version of the RHQ platform, tries to eliminate all of these pain points by making the process fully automated and self-updating.

Assuming you’re using the default mechanism within JBoss to setup your clusters – namely, JGroups – you can write an RHQ plugin to inject the name of the JGroups partition into the discovered resource. You might decide that it works best for you as a measurement trait, or maybe you want to put in inside the connection properties. It doesn’t really matter where it goes, DynaGroups can handle both scenarios equally well.

But let’s assume that you exposed it as a trait called ‘partitionName’, then you would create a group definition with the following expression set:

resource.type.name = JBossAS Server
groupBy resource.trait[partitionName]

That’s it. It’s that simple. There’s no trick. When you click the calculate button the DyanGroups engine will inspect the above set, find the groupBy expression, and automatically create one resource group for every unique value of partitionName that it can find across all resources that are currently in your inventory – this means one group for each of your clusters.

After that’s done, it will walk each group, and requery the inventory to find any JBossAS Server instances that match the partitionName that that group represents, and then add them to the group automatically. Oh, and get this, the name of each resource group will contain the cluster identifier / partition name that each resource member in it shares – neat, huh?

And this doesn’t just work when you’re calculating group memberships for the first time. If your inventory ever changes – new resources added, old resources deleted, resources reprovisioned and now belong to a different cluster – all you have to do is go back to the group definition and click the calculate button again. The DynaGroups engine will take care of everything necessary to create new resource groups for new clusters, delete groups for cluster names that are no longer in use, and update the memberships of each of the existing groups according to the new partition information it finds.

Amazingly, this is just one of many, many things DynaGroups can do. Stay tuned to future articles highlighting other nifty ways this construct can be used to help you more efficiently manage your inventory.

Advertisements

Written by josephmarques

May 8, 2008 at 10:34 am

Posted in rhq

Tagged with

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: