Creating a Distributed Unidesk VDI environment for Remote Office/Branch Office (ROBO)

by Ron Oglesby on Tue, Feb 7, 2012 at 11:15 AM 0 comments, 324 views

On-Demand Webinar: Remote Office/Branch Office VDI: How One Local Government Agency Did It
Watch: Click here to watch on-demand webinar

In last week's blog I talked a little bit about the problems remote / branch offices can cause for VDI projects.  The technological problems with these remote offices tend to be based on the fact that the office is somewhat independent and has been designed to operate with lots of local compute power and local resources. Migrating the users at this site to a centralized VDI environment is not as simple as replacing their desktops with thin clients. The migration may require file services and even some application and print services moving centrally along with the potential for serious network upgrades to support the new network dependent model.

One possible solution to this problem is to adopt a distributed VDI model by locating a host server or multiple servers in the remote office to host the desktops while still managing those desktops centrally. Keeping the desktops remote also keeps the compute power remote and should not require migration of any servers or services to the central location. As a side benefit, this design may allow you to offer some local control of those desktops when required.
 
So how does Unidesk help in this ROBO VDI model?
 
In a Unidesk environment the remote site is nothing more than an extension of our CacheCloud technology. CacheCloud manages the replication and updating of layers across the Unidesk CachePoints and the VDI storage environment. 
 
 
In this scenario at least one (and often two) ESX/ESXi servers are deployed to the remote office to host desktops. Centralized storage (some type of low cost array) can be used, but often local storage within each host is deployed to keep the cost per desktop down. VMware management tools (vCenter) in the central location are used to manage the server infrastructure, but the compute and storage resources are completely located in the remote office. 
 
The ESX servers are managed by the same vCenter infrastructure as the central office which allows Unidesk to deploy distributed CachePoint virtual appliances to these servers just as you would in the central location.
 
OS and Application Layer Replication
 
The CacheCloud technology facilitates layer management and version control and handles the layer replication based on desktop configurations. This replication is intelligent and designed to reduce the amount of data traversing the network. 
 

New layers or updates to existing layers are automatically replicated upon layer assignment from the centralized Master CachePoint to the distributed desktop CachePoints. Staging of layers to be used by desktops can also be accomplished to control when large layers (such as complete OS images) are replicated. This is often accomplished by creating an “admin” or test desktop and assigning it the layer you wish to stage during the optimal time for minimal network disruption. 

Changes to layers or updates (such as patching the OS layer or an application layer) only move the change over the network. As an example, the administrator makes a 300MB change to a 10GB gold image that is used at the remote site. Once the new layer version is assigned to the desktops at the remote site, only the delta between the previous version and the new version (the 300MB change) is replicated. 
 
Centrally managed but distributed control (if needed)
 
Another interesting feature in this model is the ability to allow some local control of the desktops. The layering technology in Unidesk still allows users (with proper permissions) to install local applications into their new desktops. So that local control and flexibility they had with full PCs is not lost in this new model. 
 
Of course these desktops will be easier to repair and update due to Unidesk layering, but if any local IT staff does exist, they can be given access to the desktop tab in the Unidesk system so they can modify, update and repair desktops as needed. The political fight that often comes of centralizing these desktops is based on loss of control and flexibility (perceived or real). Allowing some local control while still benefiting from centralized image and application management is a key to end user buy in and the successful deployment in a distributed environment.
 
Series follow ups: 
 
The final blog in this series will provide an overview of an existing Unidesk customer environment and some details on their implementation and management processes for the remote and centralized VDI desktops.
 

Post new comment

The content of this field is kept private and will not be shown publicly.