Client Management Suite

 View Only

Accelerated Plugin Deployement with Task Server 

Dec 21, 2009 03:06 PM

Balancing Server Load with Deployment Speed

If you've ever managed a large (>5,000 node) notification server, one of the things you tend to learn quickly is that performance of the server is very much impacted by a few important settings.

In fact, Symantec, in the "Planning and Implementation Guide" for version 7, it is recommended that: "Increase the Agent communication parameters as node count increases. A general rule of thumb may be one hour for every 2,500 nodes." In addition, the second setting that needs tuning is the "Resource Update Schedule" that updates the membership in filters/collections depending on the version you are discussing.

These settings are great in most situations, however in one particular instance, they cause a significant issue. That situation is when a new node is added to your environment, or a number of client agents/plugins need to be upgraded, such as during a server upgrade or service-pack.

One KB article (28984) attempts to address one of these causes, namely the new agent. However, as it focuses on the "create date" of a new agent, it does not deal with situations where resources are created by data imports (like Active Directory or Asset Management imports) in that the resource could be created in the NS environment a considerable amount of time before the resource actually obtains a Symantec Management Agent and begins downloading plugins.

As we looked at Version 7 (and much of the advice will work in V6 too... it was simply developed in a V7 environment), we saw two "Tasks" that would allow us to set the appropriate parameters to high values while at the same time allowing us to upgrade multiple agents in a quick and streamlined way.

First, we needed to determine how to trigger an accelerated checkin process for machines. What we finally came up with was to look at when the "Basic Inventory" for Client Agent has been last updated. This information can be retrieved from the "ResourceUpdateSummary" table in the NS. So, I created a Filter that would show the resources that have had their client agent information updated within the previous hour:

SELECT
Guid=rus.ResourceGuid
FROM
dbo.ResourceUpdateSummary rus
LEFT JOIN vitem i2
ON i2.guid = rus.InventoryClassGuid
WHERE
2.name IN ( 'AeX AC Client Agent' )
AND   DATEDIFF(mi,rus.ModifiedDate,GETDATE()) < 60

This filter will show all computers that have updated the Inv_AeX_AC_Client_Agent table within the last 60 minutes. You can tune this timeframe to suit your needs if you wish in the last line.

This led to an issue with the Resource Update Interval (RUI) setting. If we set the RUI setting to a high value to reduce load, then this filter would not update and would not actually catch machines that needed to be added to the accelerated checkin, and also, machines that did happen to catch the setting would remain in the accelerated checkin far longer than we wanted them to do so.

This led us to create a "Critical Filter Update" task. This task type uses the "Update Filter Membership" task type to update the above filter, along with the "Install" and "Upgrade" filters for all of our agents. This way, we could set our Delta RUI to a high value (like 8 hours) reducing load on the server, while being able to update these critical filters on a far more rapid timeframe. In our initial phase, this is run on a schedule every 5 minutes, and involves 19 filters.

The final piece of the puzzle is a client task to update client configuration. This task goes out and emulates the user pushing the "Update Configuration" button. In this case, we're running it again every 5 minutes, and strategically, it runs one minute following the Critical Filter Update task (because one of these tasks runs on the server and the other on the client, we could not sequence them as a job). This permits us to run our Agent Checkin interval up to a high value to reduce server load (8 hours as well), while at the same time taking machines that are in the process of updating things like their Agent versions and having them check in much more frequently.

Without these two processes, it would take from 24 to 48 hours for a new agent to get all of it's plugins installed thereon. Of course, by reducing the Delta RUI and checkin interval, these numbers would go down considerably, but by taking this approach, we can substantially reduce the load on the server from routine filter updates and general workstation checkins. Our general Basic Inventory interval is set to 7 days, along with the fact that Basic Inventory automatically sends when important stuff (like IP Address or Client Agents) changes, again reducing our load.

With these processes in place, we have observed new machines going from first load of the agent to fully function with all plugins in approximately one hour. We're actively tracing out the process to get this cut down to less than 30 minutes, with an eye to being able to get full patch inventory and deployment in a rapid manner.

Statistics
0 Favorited
0 Views
0 Files
0 Shares
0 Downloads

Tags and Keywords

Related Entries and Links

No Related Resource entered.