One of the great advantages of a centralized and unified infrastructure platform like the Scale HC3 is the ability to use the platform to provide centralized desktop and end user services along side traditional server services.  The high speed back plane allows server and desktop resources to communicate at high speeds and the centralized management lowers the total cost of ownership often associated with these types of services.  Applications like file serving and latency sensitive communications particularly benefit from the architecture.

For the majority of businesses, the approach that will make the most sense to add remote end user computing services to their environment will be through the use of Microsoft’s own Remote Desktop Servers or RDS, as most environments seek to provide an experience similar to  a traditional Windows desktop.  Microsoft’s RDS is a powerful toolset and relatively easy to implement.  It is a great starting point for offering a range of services.

Because of the high availability nature of the Scale HC3 platform we have good choices as to how to approach planning and provisioning an RDS deployment.  We can choose to keep our deployment small and simple and utilize the Scale HC3 cluster’s built in high availability features to maintain our environment through hardware failure or we can leverage high availability from the RDS environment for this.

In a small deployment, it would be most common to leverage the Scale HC3’s high availability features to maintain the availability of our RDS services.  Doing this allows us to run a single RDS instance with a minimum of licensing, resource and maintenance overhead.  This is the simplest approach and is very effective.  This is an excellent way for the majority of customers to make the best use of the Scale HC3 platform.  Scale can do the heavy lifting in this case and we are able to focus our efforts in places where they are more effective.

In large deployments having a single RDS instance may not be adequate.  At this point it would generally become reasonable to move to a multi-server RDS deployment with workloads load balanced across the instances.  Typically we would want to see no more than a single RDS server deployed per Scale HC3 node to best leverage the available resources.  In this way as many RDS server instances could be deployed as needed to handle the environmental capacity.

In most cases, even with the larger deployment across many nodes, we would use load balancing in front of the RDS farm, but we would still use the Scale HC3 cluster’s built in high availability features to handle hardware failures by moving running workloads from a failed node to an available node.  The load balancer would see the same instance with the same IP address allowing for a nearly transparent recovery that is fully automated and requiring a minimal of effort.

In more extreme cases where the full capacity of the cluster is required it is possible to configure one RDS instance per physical cluster node and to disable high availability features and instead utilize the load balancing functions to shift load to remaining nodes.  This would result in a graceful loss of performance rather than an outage.  Unless resources were extremely constrained already, user allocated CPU and memory would decline but system functionality would remain.  This is not as ideal a full high availability solution but can be a very functional alternative to the cost of hardware for that level of protection.

Microsoft Windows RDS and Scale make an obvious partnership.  Scale focuses on making the platform as easy and robust as possible while Microsoft’s Windows and RDS product provide us the simplest entry point into the shared computing space.  For small and medium businesses and especially for on premises deployments RDS is often the perfect choice for moving to centralized, thin client-based computing and can be a key enabler for workforce mobility, security and even bring your own device options.

[This piece was commissioned for the Scale Blog.]