Upload
rene-van-der-linden
View
292
Download
11
Embed Size (px)
Citation preview
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.