RES Workspace Manager in a non-persistent environment

RES Workspace Manager is a user environment manager (UEM) that enables you to centrally manage the user workspace (RES term for the users desktop, start menu and all user related settings) for both virtual and physical machines. UEM products like RES Workspace Manager are common in virtual desktop environments like SBC or VDI (I don’t like the term VDI) because they simplify management and improve consistency between all the machines.

Virtual desktop machines are either persistent or non-persistent. When a machine is non-persistent the machine reverts to the state it was before (also called stateless) as it is stored in the “golden image”. This has a lot of benefits but comes with some challenges.

RES Workspace Manager stores all the configuration and state data in a database (the RES Workspace Manager Datastore ). Administrators connect the console directly to the database to see and edit the configuration. Each machine that runs RES Workspace Manager has an agent that connects to the Datastore to receive the configuration.

To continue running when the datastore is not available, for instance on a laptop that is not connected to the network, each Agent has a database cache stored locally on the machine. When the Datastore is unavailable due to a failure this does not impact the users workspace, all the latest (security or policy) changes are applied as configured. New changes cannot be configured of course.

 

RES Workspace Manager normal architecture

In an environment with a normal setup (where Agents connect directly to the Datastore ) the situation can be as followed. The image of the non-persistent machines is created on April 1^st , the database cache stores the configuration of this date. On April 21^st an Administrator changes a configuration, for the sake of the argument this is an important security policy, which is stored in the Datastore. When a machine starts up the RES Workspace Manager retrieves the latest version from the Datastore and stores this in the local database cache.

But what happens when the database server fails and the Datastore becomes unavailable? Because the machines are non-persistent they will revert to the initial state of April 1st. The machine starts the Workspace Manager Agent and, since there is Datastore to contact, it will present the users workspace with the configuration without the important security update.

 

RES Workspace Manager with Relay Server

In RES Workspace Manager 2012 a new component was introduced: the Relay Server. Basically the Relay Server acts as a proxy between the Datastore and the Agents. Each Relay Server caches the content of the Datastore with the configuration data and the usage tracking information of the Agents. Connection from the Relay Server to the Datastore can be immediately or with a predefined schedule, this is especially very useful if the Datastore is in another site with reduced bandwidth.

The Relay Server is very scalable, each Relay Server can serve numerous (thousands) of Agents, and Agents can discover them easily. Discovery of the Relay Servers can be done with a multicast (enabled by default) or with a predefined list. When an Agent can’t contact one Relay Server in the list it will contact another, providing high availability.

So how does the Relay Server fit in an environment with non-persistent machines? Consider the same situation as in the normal architecture. The golden images is created on April 1^st and an important security policy is applied on April 21^st, the latest configuration is stored in the Datastore and the Relay Server. When a machine starts up the RES Workspace Manager retrieves the latest version from the Relay Server and stores this in the local database cache. Same as with the Normal architecture.

So what happens when the database server fails and the Datastore becomes unavailable? Because the Relay Server has the content of the Datastore cached the machines retrieve the latest configuration data. The non-persistent machine starts the Workspace Manager Agent and will present the users workspace with the configuration the user workspace including the important security update.

 

 

Conclusion

If you’re using RES Workspace Manager as your UEM in an environment with non-persistent machines it is advisable to have the datastore high available. This can be done by making the datastore high available with (for instance) a cluster or by implementing RES Workspace Manager Relay Servers.

By implementing Relay Servers the need for a clustered database is reduced. Not only for the availability of the databases in case of a failure but also for the availability from different sites (with reduced bandwidth).

 

Persistent disk

Barry Schiffer just pointed out that if you have a persistent disk attached to your non-persistent machine (as done with non-persistent Citrix XenApp worker servers) the RES Workspace Manager local cache can be stored on the persistent disk. This way the local database cache is always up-to-date.