Managing JBossAS Clusters via DynaGroups
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
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.