The purpose of this article, is to shed some light on the Workspace Manager Relay Server, available soon in Workspace Manager 2012. Before we begin, let me give you some background, so we better understand the need and use cases for this thing. First of all, the RES Workspace Manager has supported a SQL based backend since the PowerFuse 2008 release. As far as scalability goes, this was a giant step beyond the filebased datastore of the 90's (and for the AS fanboys reading along; don't get your user config mixed up with your console config). However the question always remained: Okay cool, so how well does scale. The answer was always quite simple: Workspace Manager scales as well as your datastore. In other words if you were running your datastore on your mom's old overclocked 286, don't expect the world. However if you like most normal enterprises have an existing SQL infrastructure running already for one purpose or another, it's very likely that you are able to support a Workspace Manager architecture as well.
While recognizing your milage may vary according to DBMS vendor, a regular MS SQL Server Standard server supports 32.762 user connections. As the RES workspace manager 2011 can utilize two datastores for respectively logging and configuration datastores, we count 2 connections per RES WM Agent. So does this mean that you can only run 16.381 WM agents on one database. No, that number is per instance, and add clustering capabilty to the equation and you can support as many WM agents as you need, ie Workspace Manager scales as well as your datatstore, QED.
An often asked question which I've been asked again and again during training, is "I have multiple [overseas] locations – should I set up database replication. While this was an option in the past where a simpler datastructure was being used, it's not something I would recommend anymore. This is specifically due to that we have several tables in the RES WM Datastore that either needs to be replicated upstream, downstream or both ways. In short, you would need to be very carefull in setting the replication scheme up just right, or you could end up with a whole lot of iffyness on your hands.
Okay, so that was the situation until now (or rather soon). With the upcoming release of Workspace Manager 2012 you can however throw another design component into the mix, rather than just designing the Datastore From Hell. With the Workspace Manager relay server you get the following advantages:
- Better scalability,
- Reduced network traffic,
- Reduced datastore load (which is great if your datastore is huffing and puffing already)
- You are able to negate any need for native DB drivers on the RES WM agents, as the relay server will sit between the agents and the datastore.
- Finally, I see this as a great way of segmenting traffic if you have Workspace Manager agents on computers outside your firewall. Stick a relay server in your DMZ and you're golden.
Those of you familiar with the RES Automation Manager product line (formerly known as Wisdom), this particular architecture should be very familiar, as the Relay Server is basically the equivalent of a Workspace Manager Dispatcher. It is my understanding that we've used some of the code from the current AM dispatcher+ to build the Relay Server. There is however one very important difference between the Relay Server and the AM Dispatcher: The relay server is optional. It is still possible to connect WM agents directly to the datastore, business as usual, alongside deploying one or more relay servers, pointing to the same datastore.
The WM Relay server like it's AM Dispatcher cousin, has the ability to be chained, meaning you for example can have a Master Relay server for a given geographical area, with sub-relay servers pointing to it. See the graphics on the right. Relay servers are communicating natively with each other, so there's no need for specific database drivers, except when any component (master relay server or a WM agent) is talking directly to the datastore.
A few things you may want to know when deploying the Relay server:
- You need .Net Framework 4 installed (the full package). You don't need anything else, like IIS as the Relay Server is completely self contained.
- The Relay server can run on any Windows OS from Windows XP x86 and up. In other words, you don't necessarily need a Windows server OS to run it.
- Do not deploy the relay server on a box where there's already a Workspace Manager installed. Doing so may cause a rip in the fabric of space-time and we will all die miserably. More likely it's because the Relay Server listens on port tcp/1942 per default, which the WM Agent already listens on for force-cache requests. See this article for more info on the IP ports of RES products.
- The relay server is packaged as both a native x64 and x86 MSI. The MSI file itself doesn't have much in the shape of configuration options, as all this is stored in an XML file. This config file can be specified as a public MSI attribute during installation as CONFIGFILE=x:\yourconfigfile.xml.
- If you install the relay server just by running the MSI manually, you'll get prompted for the info necessary to generate the config file.
- The relay server runs as a service (RESRLS / "RES Workspace Manager Relay Server") with LocalSystem credentials.
Relay Server setup
The setup of the relay server itself is straight forward. Hit the Add button and you'll get stepped through a wizard where you either specify a connection to a datastore, or to another existing relay server. You also get the opportunity to change the location of the relay server's cache. Once this is done you can write the configuration to the forementioned XML file for further unattended installs.
Once the relay server has been configured, it will be visible in the WM2012 console under the new Setup|Relay servers. Oh yeah, that's one thing that will mess with you initially if you don't notice it. The Setup section in WM2012 is no longer a main node in the lower left corner. You will find Setup in the menubar of the console now. It kinda makes sense as it's all the set-n-forget items, which you don't want to have cluttering up your console on an everyday basis anyway.
Agent to Relay hookup
Another thing we need to cover, is how you hook up agents to a relay server. This topic is twofold as it also includes how the agent decides what to connect to when. While you might initially think it would be under connections, it's actually to be found as a property of the Agent. Here's btw another change in the WM console, which you need to be familiar with: Where the Setup main node was before, you now have a new one called Administration. You will find the Agents section there. Rembember: Existing WM2011 Agents or older have no clue what a relay server is, so all agents you want to have talking through a relay server, must be upgraded to WM2012.
You basically have 3 options available for how the WM Agent should find a relay server: You can choose
- Multicast discovery,
- A list of relay servers (like the server location table in a Citrix client),
- A fallback server specified via DNS.
It is possible to combine more than one of these options according to your needs. The WM Agent will look for a relay server using the 3 methods above, one by one, in the order they are shown. the WM Agent will stop looking when it finds a Relay Server. If none of the selected methods yield a Relay Server, the WM Agent will use the cached configuration settings in the DBcache, business as usual. It is important to note that if a WM Agent has been configured for Relay Server connection, it will never attempt a direct database connection.
It is also possible to set global and individual settings for both the Relay Servers and the individual Agents: The Relay Server's global default settings are defined under Setup | Relay Servers | Settings. The individual Relay Servers can be configured to deviate from the default settings by doubleclicking a Relay Server under Setup | Relay Servers | Properties. While individual overrides are possible, it doesn't look like it's possible at this time to group Relay Servers and manage them like you do with Teams in Automation Manager, but before you panic, think about how many variations of relay server configurations you would need. Let's cross that bridge, if you get to it.
Anyway, the WM Agent is where you really need the flexibility as you may have many different sites and thereby connections pathways. Per default every agent inherrits the settings defined in Administration | Agents | Settings. The neat thing here is that you can use the existing PlusMenu feature to manage Workspace Models. This will allow you create exceptions for individual Workspace Containers. See article RG027 for more info on the models. This is the recommended approach when you want to manage multiple sets of agents which will have different ways of discovering a relay server. On the right I've created an example where you have a [Laptops] workspace container, which is just a list of agents in the Computer Control tab of a Workspace Container. Adding this as a workspace model, I have now specified that my laptops will always resolve their relay server via a list.
Unattended Agent installation
The installation MSI for the RES Workspace Manager 2012 itself has been augmented with some extra public MSI attributes, which will help you configure the Relay Server options out of the box. These parameters can be found in the updated Technote RG004. Click here to read it.
To be continued…
As the relay server at this time of writing is still part of the Interim Release of Workspace Manager, things are still subject to change before the release and I probably will need to update this article later. If you are not on the EA Program, you will have to wait for the Workspace Manager 2012 release. This will be announced via the RES Software website, newsletters etc. I still have a couple of unresolved questions myself, which I will share the answers to, as soon as I get them. Right now on the todo list is:
- How many agents does a relay server support: Update/Answer Apr 18th: I am told we have tested the Relay Server with 1000 connections, with the 5 second default update interval without incident. The logical conclusion is that if you tweak the update interval a bit, the relay server can support many more, as it really just depends on the hardware performance.
- How is a relay server list processed? Update/Answer Apr 18th: The list is processed much the same way an AM Dispatcher list is processed. Uppon reading a list of servers, the WM Agent randomly target relay servers from the list until all options have been exhausted. What happens then is either fallback to the DNS configured server, or use cached settings.
- I've run into an interesting item, which I better share. As you may know there's a limitation of about 257 chars on the path+filename length that Windows support. If you like me have a boatload of existing Custom Resources stored in your DB, these will be replicated to the Relay Servers. I have mandatory profile templates stored in my custom resources so the directory structure tends to run a bit deeper than average, which could cause the replication to fail. Update/Answer Apr 18th; This is being fixed as we speak, but in the meantime it can be migitated by placing the Relay Server cache in a shorter path off the root of an available local drive, like C:\r\ or similar.
When you get access to the new release, be sure to study the release notes as always. This is where all the juicy bits are to be found! If you have any additional questions about the RES Relay Server, feel free to post them here and I'll try to get us some answers. As I'm sure you will agree the Relay Server is an important upcoming infrastructure component of RES Workspace Manager and the more we all know about it today, the better we all are set for designing tomorows Workspace!