RES Workspace Manager

High Availability for SQL Server

2 | P a g e

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.

3 | P a g e

RES Workspace Manager - High Availability for SQL Server

Introduction ........................................................................................................... 4

RES Workspace Manager Datastore ............................................................................... 5

High Availability Techniques .................................................................................. 6 References 7

High Availability Scenarios 7

Single Datastore (HA) 7

Multiple Datastores (Multisite configuration) 14

Further considerations regarding High Availability 16

4 | P a g e

RES Workspace Manager - High Availability for SQL Server

Introduction

In RES Workspace Manager, the Datastore contains all information required to build

the user’s 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.

5 | P a g e

RES Workspace Manager - High Availability for SQL Server

RES Workspace Manager Datastore

First, let’s 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.

6 | P a g e

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

7 | P a g e

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.

8 | P a g e

RES Workspace Manager - High Availability for SQL Server

SQL1 (production instance)

1.1 Server Type Windows 2008 R2

1.2 System Model [Server Model Number, Product Type]

1.3 RAM Memory 8 Gig

1.4 No. of CPU’s 2

1.5 CPU & Speed AMD (x64)

Drives Hard Disk Space C(#G);D(#G)

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

1.1 Server Type Windows 2008 R2

1.2 System Model

[Server Model Number, Product Type] Same as

SQL1

1.3 RAM Memory 9 Gig

1.4 No. of CPU’s 2

1.5 CPU & Speed AMD (x64)

Drives Hard Disk Space

C(#G);D(#G)

This server should have terabytes and terabytes

of space, depending on your archiving needs.

9 | P a g e

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.

10 | P a g e

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.

11 | 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.

12 | 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.

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.

Production Mode DR Mode

13 | 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)

14 | 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.

15 | 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.

16 | 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.