Introducing Relay Server
To start the article it’s good to explain what the RES Relay Server actually is. The RES Relay Server is introduced in RES Workspace Manager 2012. Before the Relay Server all Workspace Manager clients (called Agents) are directly connecting to the SQL database where the configuration and logging of RES Workspace Management is stored. In case of real large environments this could be resource intensive on the SQL database. Also in the case of several offices/more sites the traffic between the agent and the database will be transferred over (slower) WAN links. In the last scenario RES Workspace Manager (RES WM) could be used with a second mirrored database, but this involves more hardware and software costs. The relay server component can be used for such scenarios. The relay server is separate component, which can be installed on a Windows machine. The agent server will communicate with the database and caches all the information. The agent will be connected to the relay server and retrieve the settings from the relay server.
The Proof of Concept Customer Case
In my proof of concept case the customer has plans to set-up an active-active data center setup. In both data centers Citrix XenApp servers will be available with the RES WM Agent. Although there is a large bandwidth connection with low latency one of the requirements is that as less as possible traffic need to transferred between the data centers (I will write another real life experience article on this subject for all components in the near feature). To accomplish this for RES WM we decided to use the Relay Server option. In this article I will describe my experiences and the way we are going to implement it.
Before you read this article further I would like to mention that I think Relay Server is great and is working fine, although I have some remarks and options I’m missing in the current implementation.
Installation and Configuration Relay Server
As already mentioned the relay server is a separate component, which needs to be installed separately. The component can be installed on the same machine as the RES WM Agent is installed, although it’s not recommended. Both products are using the same port by default and updating or removing one of the components can conflict with the other one. The installation is pretty straight forwarded; just specify the destination location and accepting the license agreement. After the installation the Relay Server Configuration will be started, allowing to set-up the relay server to connect to another relay server or directly to the database.
Depending which option you have chosen you need to specify the relay server you would like to use or filling in the database information. As an additional security you need to specify the environment name and corresponding password (configured with the RES Workspace Manager Console). Also the port number for communication can be change in this utility. When the Relay Server is connected to the RES WM environment, it will be shown up in the RES Workspace Manager Console. Within the RES WM Console you can configure the synchronization policy.
In this Proof of Concept we decided to use one relay server per data center, which will connect directly to the database. The load is not an issue because the amount of agents is limited (only XenApp servers) and the relay server is only used to arrange less network traffic between the data centers.
Because the environment will be build up via automated ways we also tested that part. The first relay server cannot be done fully automated, the software can be installed silent using MSI parameters however the configuration to connect to the RES WM cannot be done. There are no parameters available for that part. When the first server is configured you can export the configuration settings to an XML file. This XML can be specified as a parameter to the next Relay Server that will be rolled out.
Connecting the agents to the RES Relay Server
Now the RES relay servers are up and running you need to configure the agents to use the relay server. This can be done for every agent separately or create a Workspace Container, where those settings will be applied (assuming that you would like to use more than one relay server) . Logically you don’t want to adjust every client (by default an agent connects directly to the database), so using a workspace container is the most logical choice and by preference automatically during the installation. This can be done via the standard unattended installation option of the RES WM agent using the parameters ADDTOWORKSPACE=<<Name of the Workspace>> and INHERITESETTINGS=YES. The last is important otherwise the relay server configuration made in the workspace will not be used.
Independent which option you choose to configure the relay server settings for the agent, there are three methods to let the agent use a relay server.
- Multicast
The agent will try to automatically discover any available relay server. Personally I don’t prefer that agents are “shouting” for a service. Did not test did one in detail, but I expect that this is within a VLAN only (in my case the relay server in the datacenter was not found).
- Preconfigured (using list)
You can configure a list of relay servers the agent can used. Unfortunate there is option to configure a priority and it is not fully clear how the order of the relay server is constructed (it looks it’s based on the name of the Relay Server). Personally I would like to see such a priority option build-in.
- Resolve (using DNS)
With this option you specify a DNS name of the relay server. This gives some flexibility by assigning the Relay Server using a CNAME or Agents that are connected outside the network.
You can combine the methods, so you can configure more options together. When using more methods they are tried in the order multicast, preconfigured and at last resolve. When in one of the methods a relay server is found that one will be used and the other methods will not be used.
During my testing I noticed some behavior I did not completely expected. During testing I changed the way the relay server could be found. I made a mistake in the configuration and the configuration was automatically switched back to the old configuration. So there is check build in to see if the relay server is available. However when the configuration has succeeded once, the agent will always use that configuration.
In our Proof of Concept as mentioned before we would like to have one Relay Server on each site. The idea was to use the Configured List for the agent connections. However because you can specify the priority, the configuration could not satisfy our requirements. The Relay Server in Site A was always specified on top, which logically was not our goal for Site B.
Therefore we needed to use another solution. We found out that if an agent is configured to one relay server and don’t have a connection with the RES VM environment anymore because the relay server is gone (forever) the agent becomes an Orphan. Change the connection to the RES WM (via database or Relay Agent) is done in the database, where the agent does not have a connection with it, because his contact point (relay server) is not available. At first it looked like you cannot change the configuration locally on the agent to connect to another relay server or set-up a direct database connection in case of disaster (with the Relay Server). After discussing this behavior with RES product management it is possible. You should first change the configuration via the RES WM console to the new config, after that you can re-configure the agent locally using the res.exe /config command. It’s good to see that you can change it, but you should know the procedure (currently this is not described officially).
However configuring one relay server in the Configured List is logically not a real option in production environments. The way to accomplish the target was using DSN resolving. We created two CNAMES, one for each Relay Server. We configured the CNAME as the destination for Resolve DNS for the corresponding Workspace Container. In case one relay server totally fails, the CNAME should be changed to the other relay server and after a refresh of the DNS cache the agent is connected again to the RES WM environment. However this is a manual action, we asked RES to build-in a priority list in the Configured List. That’s the actual way in my opinion you would like to use the Relay Server.
Conclusion
The RES Relay Server is powerful and useful option to the minimize traffic over WAN links, not to stress the database that much and/or not to set-up a SQL High Available solution (which are often complex). The installation and configuration is easy and mostly logical. Only on the agent setup using a relay server it would be nice if the suggested features will be implemented to make the component more robust and more reliable (for some use case scenarios).
With using the DSN resolving with the CNAMES we accomplished the target to keep the traffic within each data center, while there is a fallback when the component fails (for good or a long time).