Posts tagged: RES

Understanding Automation Manager traffic

By Max Ranzau

 

BandwidthexampleFrom the Nuts, Bolts and Bandwidth Dept. As some of you noticed, a while back RES released the Reference Architecture document for Automation Manager, so now we have one for both the core products, great. If you have no idea what I’m talking about, go read the document here. The reference doc leads in with the basic deployment scenarios and similar things, but the nittygritty stuff is on page 22+23, where we get down to the actual traffic load numbers. Some of these numbers are obviously based on estimates: For example the resulting network traffic of any job, invariably would be linked to what’s in the job in terms of modules, tasks and resources. Note: The ref.architecture doc specifies packet numbers, but since we are interested in the overall bandwidth consumption I’m leaving those number out as they’d only muddle the picture.

One more thing before we get started. The numbers listed below are obviously without Automation Manager bandwidth management involved. I may do another piece on that particular topic in the future so you get a better idea of what it actually does…

AM Agent-to-Dispatcher idle-traffic.

To begin with, lets talk about idle traffic. It’s a fact of life that all components in a network chat. The question is how much, how often and what the impact would be on the fringes on your infrastructure. Given the numbers below, chances are that you can work out the impact by yourself. While RES is keeping the formula on how to calculate the precise idle traffic under NDA, it’s pretty easy to make a couple of observations off the provided numbers. According to the examples in the document:

When idle, one AM agent spews about 47.5kByte worth of traffic per 5 min/300 sec. That’s not a whole lot as it boils down to just below 160 bytes/sec per agent.

Let’s expand on that: Even if you had 3000 agents on the same site, your total background noise from the AM agents, across all switches would be around 475k/sec. This is next to nothing on a regular LAN. Remember this is the agent-to-dispatcher poll traffic, so it would never have to cross a WAN link when you place your dispatchers strategically on your external sub-nets.

AM Dispatcher-to-Datastore idle traffic.

As most of you know, an AM Agent is wired never to talk to a datastore directly, but always go by way of at least one dispatcher.  How many dispatchers you will need depends entirely on the shape of the infrastructure you want to deploy AM in. Since each Dispatcher+ can handle 1500 concurrent agent connections, you are obviously going to have a lot less dispatchers than agents, however the kicker is that the dispatchers will usually be crossing WAN links if you have them. If you go about your dispatcher layout smartly, you should not need more than one dispatcher per wan, link which makes the following math rather easy. When the dispatchers aren’t doing anything job related, the idle traffic depends on:

A) Are there agents connected?

  • If no, the base impact is about 616k over 300 sec †1), being around 2kB/sec per dispatcher, which is negligible on most WAN links.
  • If yes, it seems there is a slight overhead when an agent is connected (22kB over 5 min = 73 bytes/sec). Presuming that number scales linear, then even with a fully loaded dispatcher with 1500 attached agents, you would be looking at around 110kb/sec dispatcher-to-datastore traffic †2)

†1)Disclaimer: As RES is keeping the formula for calculating this under wraps with the NDA stuff, I’m going to have to make a couple of leaps of faith here. Unless somebody with WireShark and the necessary time on their hands is prepared to run the numbers and verify (or spill the beans in the comments section ;)  – we can only go by what is stated in the doc. The reference document said the Agent idle traffic was measured over a 5 minute interval, but it doesn’t say so for the corresponding dispatcher traffic, thus we are going to presume they used the same measurement interval for that test. †2)The other presumption I had to make, is that each additional agent connected to a dispatcher adds on average the 73 bytes/sec onto the idle dispatcher-to-datastore traffic.

B) The other item to briefly consider: Is the dispatcher a garbage collector? This role has a very low impact and not much is posted about it anywhere at present, other than it’s selected dynamically amongst the dispatchers – supposedly similar to Citrix Zone Data Collectors as they all know about each other through their datastore. What the purpose of the RES AM data collection precisely is, when it happens, what the election criteria is, are still unanswered questions, but hopefully someone will provide that information in the near future. Anyway, based on the released numbers, we may presume the garbage collection role adds approximately 215k/5min to an idle agent, equivalent to just under 780 bytes/sec for the garbage collecting dispatcher. So unless part of your infrastructure is running over a 2G cell data connection you can probably ignore this completely.

AM Dispatcher-to-Datastore traffic, running a job

Since you hopefully won’t have your new Automation Manager installation sitting idly too much, it’s also worthwhile knowing what kind of traffic patterns you are looking at when a job is actually processing. Again we have to do a bit of guestimating based on the provided numbers in the RES reference architecture guide. The numbers are based on a job that downloads a 5.5MB AM resource. The only thing they really tell us is, that regardless if you are master caching or connecting a dispatcher directly to the datastore, the amount of data going across the wire seems roughly equivalent to the size of the resource payload + 500kB. If a dispatcher is set up as a master caching dispatcher, the transfer overhead looks to be about 200kB less than for a regular dispatcher connected to the datastore.

In conclusion, while the overhead isn’t very large, it is not easy to create usable rules of thumb out of this, as the reference document only provides one datapoint (5,5MB and resulting traffic), so in order to make an accurate estimate on traffic size, one would have to know how/if the 500kb overhead grows with the size of the resource/modules. I would suggest this would be an excellent addition to a revision of this document.

Other than that, clarifying comments are welcome!

What’s up with that other WM service?

By Max Ranzau

 

From the Inquisitive Minds Want to Know dept. Since the release of Workspace Manager 2012 SR3, you may have noticed an extra service has been added, besides the well known RES service (aka “Workspace Manager Agent”), which takes care of synchronizing the local DBcache with the SQL datastore. The other service, is seen in the Services.msc as “RES Workspace Manager PE”, shortnamed RESPESVC:

respesvc

I asked one of our software folks what the purpose of this service is. I was told that RESPESVC plays a role in environment variable injection into intercepted processes & injection of DLL’s in Windows processes for logoff scenario’s. If you are wondering about what the PE part is short for, RESPESVC is RES Privileged Execution Service. In SR4 it will also do Dynamic Privileges, moving that over from the RES service, making the technical architecture of that feature a lot simpler.

I know a few of you likeminded professional tinkerers are wondering; can one do anything interesting with this service? Does it’s credentials need to be reconfigured like with the RES service if you are running SQL authentication? In both cases the honest answer is no. There’s nothing to see here, move along :) This service just needs to be left alone, running with it’s default LocalSystem credentials and the world will be a better place, architecture wise. If this changes, I’ll be sure to let you know.

 

New technote: Guide to Environment Variables

Animated, Gears, boxFrom the WhereDoesHeGetThoseWonderFulToys Dept. It took a while to get the whole thing stood up, but here it is, a complete and current (as of Workspace Manager 2012 SR2) overview of all RES Environment Variables. The guide also covers known system environment variables and references how these tie into a RES managed environment. Finally the guide also includes buildingblocks a couple of small diagnostic tools that will show the current values of the variables within a session, without using nor exposing the Command Prompt to the users. Enjoy!

doc-icon2 <<< Click here to open the Guide.

The new look of RES Software

Hot off the press: As previously announced, wonderful things are happening over at RES. Today 5pm CET, RES Software has changed the website, logo and messaging, but that’s not all. Product names and categorizations have changed too! More below. There are many other significant changes underway, which will be revealed over the course of this week. To help you make sense of it all, here is a quick breakdown on what’s going on so far:

  • New website. Have a look at the new RESsoftware.com, which is live now.
  • New logo. Gone is the old blue-white-black. You can view the new shaded logo in all it’s glory by clicking on the miniature in the upper left corner of this article.
  • New product suite: As of today, all the current products are considered part of ONE  suite, called the RES Dynamic Desktop Studio. See the illustration on the right.
  • The product now formerly known as RES PowerFuse will from today be known as the RES Workspace Manager, part of the Dynamic Desktop Stuido.
  • RES Wisdom will from today be known as the RES Automation Manager. also part of the suite
  • Orchestra aka Orchestraton Pack for Wisdom is now known as the Service Orchestration Module in the Automation Manager.
  • The Workspace Extender aka Subscriber will from today be known as the Virtual Desktop Extender, or VDX.
  • VDX will be available as a stand-alone product from January 2011.

All this information and more is available in the New RES FAQ, available here.

As mentioned there will be made more, important announcements during this week, so keep an eye out for them here at the ‘Guru. In the meantime, you can see what the  new names and logo’s for the components of the Dynamic Desktop Studio will look like. Click on the individual components to jump to the corresponding product page.

Now, if you will excuse me, I’ve got 50.000 entries in the RESpedia to edit.. :-)

RESguru’s got Forums!

breaking-news-sGreetings all Guru’s! Today RESguru.com proudly announces the launch of a new part of the site, the Forums. C’mon – every good blog has to have one, right? Anyway a few good men have been test driving the forums  for little while before the announcement today. Just like every vendor has it’s own official forum, RESguru is the first unofficial RES forum of it’s kind, hopefully to be joined by many more in the future. It’s all about building communities.

If you’ve got something on your mind; questions, ideas, rants, answers, grins or gripes  related to RES products  – anything RES at all, feel free to drop in and say hi. The current forum members include some of the most accomplished RES consultants, integrators, system administrators, techs, etc. However, since this is a forum based on voulentary participation, if you got a urgent problem with your RES production environment your best bet is still to talk with the friendly folks at RES Support.

The full link to the Forum is: www.resguru.com/forum, which you will find as a permanent link  in the Guru Links section on the right hand the blog.

/TRG

RES Revamped!

res-new-web

reslogoHere’s some catchup on what’s been going on for the last month. On March 31st  at 15:30, Hell froze over, the pigs made Mach 1, and RES got a slick new website! The portal is however still pretty much the same.

Mystified by the appearance of two rectangular objects resembling containers of sorts, RESguru.com sent out their trusty investigators, Mr. Pitt and Mr. Freeman to examine the website in more detail. We now go live to an in-depth interview:

whatsinthedamnbox

;-)

More Buildingblocks!

BricksLooks like there’s now a buildingblock section at the RES forum.  It’s even a publicly accessible place – Nice!However, these are not RES endorsed nor certified buildingblocks. Guess it’s the same groundrules which applies around here. Anyway go have a look here