RES Workspace Manager High Availability for SQL Server

RES Workspace Manager - High Availability for SQL Server

Disclaimer Whilst every care has been taken by RES Software to ensure that the information contained in this publication is correct and complete, it is possible that this is not the case. RES Software provides the publication "as is", without any warranty for its soundness, suitability for a different purpose or otherwise. RES Software is not liable for any damage which has occurred or may occur as a result of or in any respect related to the use of this publication. RES Software may change or terminate this publication at any time without further notice and shall not be responsible for any consequence(s) arising there from. Subject to this disclaimer, RES Software is not responsible for any contributions by third parties to this publication. Copyright Notice Copyright on software and all Materials 1998-2011 Real Enterprise Solutions Development BV, P.O. Box 33, 5201 AA `s-Hertogenbosch, The Netherlands. RES and the RES Software Logo are either registered trademarks or service marks of Real Enterprise Solutions Nederland B.V. in Europe, the United States and other countries. RES Automation Manager, RES Workspace Manager, Dynamic Desktop Studio, Virtual Desktop Extender and RES VDX are trade names of Real Enterprise Solutions Nederland B.V. in Europe, the United States and other countries. All other product and company names mentioned may be trademarks and/or service marks of their respective owners. Real Enterprise Solutions Development BV, The Netherlands has the following patents: U.S. Pat. "US 7,433,962", "US 7,565,652", "US 7,725,527", other patents pending or granted.

2|Page

RES Workspace Manager - High Availability for SQL Server

Introduction ........................................................................................................... 4 RES Workspace Manager Datastore ............................................................................... 5 High Availability Techniques .................................................................................. 6 References 7 High Availability Scenarios Single Datastore (HA) Multiple Datastores (Multisite configuration) Further considerations regarding High Availability 7 7 14 16

3|Page

RES Workspace Manager - High Availability for SQL Server

Introduction

In RES Workspace Manager, the Datastore contains all information required to build the users dynamic desktop. One of the first steps in setting up an RES Workspace Manager environment therefore is to connect to a database server and create an RES Workspace Manager Datastore on it. Because of this, the high availability of an RES Workspace Manager Datastore is directly related to the type of database server on which it is located. RES Workspace Manager supports the following database server types:
Microsoft SQL Server (2000 and later, including Express editions) Microsoft SQL Azure Oracle (9i and later) IBM DB2 (8.1 and later) MySQL (5.0 and later)

This whitepaper covers the different levels of high availability scenarios using RES Workspace Manager 2011 with Microsoft SQL Server 2008 R2.

4|Page

RES Workspace Manager - High Availability for SQL Server

RES Workspace Manager Datastore

First, lets talk about the communication model used by RES Workspace Manager. RES Workspace Manager stores all configuration data and resources in an SQL-based database: the RES Workspace Manager Datastore. You can set all your Terminal Servers, Desktops and laptops to use a single database or you can use replication to set up multiple databases.

The RES Workspace Manager Console communicates directly with the RES Workspace Manager Datastore. All RES Workspace Manager Agents receive a local cache of the RES Workspace Manager Datastore and communicate with their cache rather than directly with the RES Workspace Manager Datastore. The local cache stores configuration data that is received from the Datastore. Each RES Workspace Manager Agent uses its cached data instead of connecting to the SQL database directly.

5|Page

RES Workspace Manager - High Availability for SQL Server

The local cache also stores user information (log files and monitoring data) that is collected by each RES Workspace Manager Agent. The RES Workspace Manager Agent Service, which runs on each RES Workspace Manager Agent, sends this data from the local cache to the Datastore. Local caches are updated through selective synchronization: the RES Workspace Manager Agent Service retrieves only changed information from the Datastore and places it in the local data cache. This reduces the load on the central Datastore significantly. This downstream communication is asynchronous: if the Datastore is busy or unavailable, the request is deferred until the Datastore is able to process it. The RES Workspace Manager Datastore also stores the user information (log files and monitoring data) that is collected by all RES Workspace Manager Agents. The RES Workspace Manager Agent Service pushes each Agent's log files and monitoring information from the local cache to the Datastore. This upstream communication is also asynchronous: if the database is busy or unavailable, the information remains in cache until the Datastore is able to receive it. The above mechanism plays a crucial role in allowing administrators to recover the main SQL server while end users are still working seamlessly. Any changes made via the console are obviously not accepted.
High Availability Techniques

The tools used to create resiliency and build a high availability protection around a Datastore hosted into a Microsoft SQL Server are:
Replication Backup and Restore Virtualization

6|Page

RES Workspace Manager - High Availability for SQL Server

References

Introduction to Backup and Restore Strategies in SQL Server Planning for Disaster Recovery SQL Server Best Practices
Hardware and Software Clustering solutions:

Getting Started with SQL Server 2008 R2 Failover Clustering Installing a SQL Server 2008 R2 Failover Cluster SQL Server 2008 Failover Clustering
SQL Virtualization:

SQL Server on VMware vSphere Best Practice Running SQL Server 2008 in a Hyper-V Environment - Best Practices and Performance Recommendations Virtualizing Microsoft SQL Server 2008 with Citrix XenServer

High Availability Scenarios

Depending on the environment the disaster recovery process can be different, but in the end the aim to is to get the service back online as soon as possible or at least within a predefined SLA.
Single Datastore (HA)

The most common scenario of an RES Workspace Manager setup is when only one Datastore is present within the infrastructure. The disaster recovery method used is to have a hot standby server (SQL2), which is already installed, stable and, most importantly, is an exact copy of the production server's configuration. The standby server should already have the most recent operational databases fully-restored in no-recovery mode.

7|Page

RES Workspace Manager - High Availability for SQL Server

SQL1 (production instance)

1.1 1.2 1.3 1.4 1.5 Drives Server Type System Model RAM Memory No. of CPUs CPU & Speed Hard Disk Space Windows 2008 R2 [Server Model Number, Product Type] 8 Gig 2 AMD (x64) C(#G);D(#G)

SQL2 (storage replication partner / hot standby restore-subscriber)

1.1 Server Type Windows 2008 R2 [Server Model Number, Product Type] Same as SQL1 9 Gig 2 AMD (x64) C(#G);D(#G) This server should have terabytes and terabytes of space, depending on your archiving needs.

1.2 1.3 1.4 1.5

System Model RAM Memory No. of CPUs CPU & Speed

Drives

Hard Disk Space

8|Page

RES Workspace Manager - High Availability for SQL Server

Above is a typical scenario in which the RES Workspace Manager Console connects to the first SQL server presents in the environment. As soon as the connection is established, the Datastore is populated with the tables needed to perfom day to day tasks.

9|Page

RES Workspace Manager - High Availability for SQL Server

As tested in our labs, we used the built in SQL tools to recreate the above tables (now empty) of the RES Workspace Manager Datastore in a new Datastore present on the second SQL server. The steps below outline the procedure used to script the original database, allowing the administrator to quickly and easlily scale this solution across the environment.

10 | P a g e

RES Workspace Manager - High Availability for SQL Server

The script can be saved to clipboard or to a file, easing administration and scalability.The script should then be run as a new query on the second SQL server, making sure that a Datastore with the exact name as on the production server exists already.The new Datastore will have the same structure of the original, but its tables will be empty. During replication, the appropiate information will then be added.

It is also imperative to create an SQL user on each database servers, who is owner of the RES Workspace Manager Datastore. This user should always be used to connect the Agents to the Datastore.

11 | P a g e

RES Workspace Manager - High Availability for SQL Server

The scenario below shows the complete setup, with the Agents connecting to a DNS alias, pointing to the production Datastore. In the event of failure of the primary Datastore, the administrator can easily point the alias in the DNS console to the DR Datastore, minimizing downtime for the end user while recovering the primary Datastore from backup tapes. Please make sure that DNS entries for each Agent are updated using the appropriate command.

Production Mode

DR Mode

It is critical during downtime of the production Datastore to prevent making any changes via the RES Workspace Manager Console while the Agents are connected to the DR Datastore. The Publisher/Subscriber model described in the attached document does not support a direct change to rows: when the production Datastore comes back online, the normal stream resumes re-establishing the correct update/change model as described by Microsoft. DNS alias should then be changed back to the production database and DNS entries for each Agent flushed, using the appropriate commands.

12 | P a g e

RES Workspace Manager - High Availability for SQL Server

It is also critical to have a resilient, tested and proven DNS infrastructure, ensuring that communication amongst the SQL servers and the Agent works flawlessly. As best practice SQL communication should be as described in the figure below:

DHCP can also be used for an automatic discovery of the online SQL server. The Workspace Manager Admin Guide gives you a step by step instructions on how to set this up. You can find this information at: (http://support.ressoftware.com/workspacemanageradminguide/14277.htm http://support.ressoftware.com/workspacemanageradminguide/14783.htm http://support.ressoftware.com/Modules/Downloads/Eval.aspx?DownloadGuid=5a0 8a3de-443b-e011-85a9-005056bb474c (pag.21)

13 | P a g e

RES Workspace Manager - High Availability for SQL Server

Multiple Datastores (Multisite configuration)

Another more complex scenario is when RES Workspace Manager is configured to work in a multi-site/branch office environment across the WAN. In this scenario, a master Datastore and site/branch Datastore are deployed to increase security, guarantee performance and load balance the master Datastore processing.

14 | P a g e

RES Workspace Manager - High Availability for SQL Server

In this scenario, the central Datastore is not contacted directly by all Agents. Instead it functions as a master repository to feed the branch offices Datastore. Agents at each branch will connect to their site Datastore. The local cache concept introduced at the beginning of the document still applies. An HA design around, not only the central but also for each branch Datastore, is essential to make the RES Workspace Manager service resilient. The central Datastore can be made redundant by following the same technique used in the single Datastore (HA) explained previously. To make the branch/site Datastore resilient, a similar technique to the single Datastore (HA) can be used. This method requires a more complex design in terms of replication, to work in a HA situation. Moreover, the considerations made previously regarding a stable and proven DNS infrastructure are even more important in this scenario. We stress the importance of having DNS integrated into Active Directory to make sure records are dynamically updated. A manual intervention by the administrator is however needed to replace the FQDN name in the DNS Alias. It is also necessary to have a backup strategy in place for the main site as well as the remote sites to ensure proper redundancy of data. As general guideline, a full back up should be schedule at least once a week (off peak hours to minimize performance degradation), and a differential back up once a day (also scheduled to run off peak hours, typically late in the evening). A monthly back up is also recommended. Tailoring this strategy to your environment is key to a successful redundancy solution, enabling key enterprise clients to run successful businesses.

15 | P a g e

RES Workspace Manager - High Availability for SQL Server

Further considerations regarding High Availability

The table below shows guidelines for high availability options beyond the scope of this document. Nonetheless RES Support is committed to share knowledge and advice regarding critical areas of the infrastructure such as SQL.

16 | P a g e