Download AlwaysON (HADR): Step-by-Setup setup guide

Implementing MSSQL AlwaysOn
Availability Groups with Wyse™
vWorkspace™ 8.5
Deployment and Configuration Guide
©
2016 Dell Inc.
ALL RIGHTS RESERVED.
This guide contains proprietary information protected by copyright. The software described in this guide is furnished under a
software license or nondisclosure agreement. This software may be used or copied only in accordance with the terms of the
applicable agreement. No part of this guide may be reproduced or transmitted in any form or by any means, electronic or
mechanical, including photocopying and recording for any purpose other than the purchaser’s personal use without the written
permission of Dell Inc.
The information in this document is provided in connection with Dell products. No license, express or implied, by estoppel or
otherwise, to any intellectual property right is granted by this document or in connection with the sale of Dell products. EXCEPT
AS SET FORTH IN THE TERMS AND CONDITIONS AS SPECIFIED IN THE LICENSE AGREEMENT FOR THIS PRODUCT, DELL ASSUMES NO
LIABILITY WHATSOEVER AND DISCLAIMS ANY EXPRESS, IMPLIED OR STATUTORY WARRANTY RELATING TO ITS PRODUCTS
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR
NON-INFRINGEMENT. IN NO EVENT SHALL DELL BE LIABLE FOR ANY DIRECT, INDIRECT, CONSEQUENTIAL, PUNITIVE, SPECIAL OR
INCIDENTAL DAMAGES (INCLUDING, WITHOUT LIMITATION, DAMAGES FOR LOSS OF PROFITS, BUSINESS INTERRUPTION OR LOSS
OF INFORMATION) ARISING OUT OF THE USE OR INABILITY TO USE THIS DOCUMENT, EVEN IF DELL HAS BEEN ADVISED OF THE
POSSIBILITY OF SUCH DAMAGES. Dell makes no representations or warranties with respect to the accuracy or completeness of
the contents of this document and reserves the right to make changes to specifications and product descriptions at any time
without notice. Dell does not make any commitment to update the information contained in this document.
If you have any questions regarding your potential use of this material, contact:
Dell Inc.
Attn: LEGAL Dept
5 Polaris Way
Aliso Viejo, CA 92656
Refer to our web site (software.dell.com) for regional and international office information.
Patents
This product includes patent pending technology. For more information, go to http://software.dell.com/legal/patents.aspx.
Trademarks
Dell, the Dell logo, and vWorkspace are trademarks of Dell Inc. Other trademarks and trade names may be used in this
document to refer to either the entities claiming the marks and names or their products. Dell disclaims any proprietary interest
in the marks and names of others.
Legend
CAUTION: A CAUTION icon indicates potential damage to hardware or loss of data if instructions are not followed.
WARNING: A WARNING icon indicates a potential for property damage, personal injury, or death.
IMPORTANT NOTE, NOTE, TIP, MOBILE, or VIDEO: An information icon indicates supporting information.
Implementing MSSQL AlwaysOn Availability Groups with Wyse™ vWorkspace™ Deployment and Configuration Guide
Updated - February 2016
Software Version - 8.5
1
1
Executive Summary
With the release of Microsoft SQL Server 2005, Microsoft introduced SQL Database Mirroring as a primary means
for increasing database availability. Mirroring works very well in the virtual environment by providing redundant
copies of the SQL data in an active - passive configuration. Dell Wyse vWorkspace can take advantage of the
increased data protection and availability offered by database mirroring. SQL Database Mirroring is described
here and continues to be supported in subsequent versions of Microsoft SQL Server. However, SQL mirroring
requires two database replicas and a third witness server to effect automated failover.
With the release of SQL Server 2012 (Denali), Microsoft consolidated SQL fault tolerance under their Failover
Clustering model with the introduction of AlwaysOn technologies. AlwaysOn encapsulates a broad range of
comprehensive high availability and disaster recovery options including Failover Cluster Instances (FCI) and
AlwaysOn Availability Groups (AG). The following link provides architectural guidance for AlwaysOn
technologies: http://msdn.microsoft.com/en-us/library/jj215886. Failover Cluster Instances (FCI) can be
thought of as the more traditional, shared storage, two or four node cluster, more appropriate for physical
server failure scenarios. The two technologies are vastly different; serving different failure scenarios, but could
be implemented together if the need arises.
AlwaysOn Availability Groups provide advanced technologies similar to SQL mirroring and is based purely on
non-shared storage. Like mirroring, each instance of SQL Server in the topology has its own copy of data, and
does not need to share storage. This form of high availability and disaster recovery is a superior choice for
protecting the virtualized vWorkspace database instance by providing two or more synchronized copies of the
database across the implementation environment. Instead of cluster shared storage, AlwaysOn Availability
Groups can use a simple file share witness for quorum purposes. With AlwaysOn, the failover cluster provides a
SQL Listener cluster object that is monitored and managed. The owner of the cluster Listener is the current
active, primary node. The following link provides architectural guidance for AlwaysOn Availability Groups:
http://msdn.microsoft.com/en-us/library/jj191711.aspx. AlwaysOn Availability Groups provide levels of fault
tolerance and redundancy sometimes required of advanced remote application and desktop delivery use cases
not met with SQL Express or stand-alone instances of MSSQL. However, this SQL feature requires SQL Server
Enterprise edition (http://msdn.microsoft.com/en-US/library/cc645993(v=sql.110).aspx#High_availability).
By using AlwaysOn Availability Groups to host the Wyse vWorkspace configuration and reporting databases, an
availability groups solution with multiple secondary nodes can replace the legacy mirroring solution that uses
database mirroring and log shipping, to provide greater levels of fault tolerance and redundancy. It can span to
multi-site DR scenarios and can be expanded to a public/private cloud, hybrid environment with Microsoft
Azure.
Implementing MSSQL AlwaysOn Availability Groups with vWorkspace 8.5
Deployment and Configuration Guide
3
2
2
Introduction
vWorkspace is simple to install and use. It is designed for customers of all sizes, ranging from the very small
business to the very large enterprise. We know today's users expect to be able to access their applications and
data anytime, from anywhere. As vWorkspace simplicity scales to provide high performance to greater numbers
of users, fault tolerance and redundancy becomes important considerations for all vWorkspace infrastructure
components. But no component is more important than the central vWorkspace SQL database. In previous
versions of vWorkspace, SQL Mirroring was often architected as a simple, yet effective means to provide the
needed database single point of failure protection. Today, Microsoft SQL Server is moving past SQL Mirroring and
has introduced AwaysOn Availability Groups as a more feature rich technology that can be utilized by
vWorkspace to provide high availability and disaster recovery. In this guide, we will be setting up two nodes of
an Availability Group on two Windows Server 2012R2 servers with SQL Server 2014 Enterprise. AlwaysOn
Availability Groups support up to eight nodes and the secondary nodes are all readable replicas. Availability
Groups can be implemented on SQL 2012, SQL 2014, or SQL 2016 Enterprise.
Implementing MSSQL AlwaysOn Availability Groups with vWorkspace 8.5
Deployment and Configuration Guide
4
3
3
Deployment and Configuration Guide
external assistance
A wealth of information exists online providing step-by-step instructions for deploying Microsoft SQL and
implementing AlwaysOn technologies. See the following for Microsoft Step-By-Step Guides from MSDN and
TechNet:
•
AlwaysON (HADR): Step-by-Setup setup guide
•
Step-By-Step: Creating a SQL Server 2012 AlwaysOn Availability Group
The remainder of these links provide background information and additional insight into SQL AlwaysOn
Availability Groups. These links are provided for information and insights only and are not endorsements of the
sites nor confirmation as to the accuracy of the information conveyed.
Configuration Prerequisites
This guide assumes that two identical Windows Server 2012R2 have been built with identical disk layouts. You
can use the Microsoft Failover Clustering feature on the Standard and Datacenter editions of Windows Server
2012 R2 and Windows Server 2012. This includes Server Core installations. Each SQL Server instance must be
running the Enterprise Edition of SQL Server. SQL AlwaysOn Availability Groups use Microsoft Failover Clustering
to monitor and failover connectivity to separate instances of the vWorkspace SQL database. The Microsoft
Clustering components are used to create a clustered SQL Listener that is owned by the active node of the
availability group. On failover, this listener ownership is transferred to one of the passive nodes making it the
active node. No shared storage or clustered storage is used with Availability Groups. Therefore, the SQL Server
installation uses a standalone installation, rather than a SQL Cluster installation.
The Cluster will need a HOSTNAME and management interface IP ADDRESS. The Availability Group Listener will
need a HOSTNAME and a listener IP ADDRESS -- two different hostnames and two IP addresses are required.
MSDN (HTTP://MSDN.MICROSOFT.COM)
This section provides the detailed prerequisites for SQL AlwaysOn.
Prerequisites, Restrictions, and Recommendations for
AlwaysOn Availability Groups
http://msdn.microsoft.com/en-us/library/ff878487.aspx
Benefits, Terms & Definitions
http://msdn.microsoft.com/en-us/library/hh510230.aspx
Implementing MSSQL AlwaysOn Availability Groups with vWorkspace 8.5
Deployment and Configuration Guide
5
Availability Group Listeners, Client Connectivity, and
Application Failover
http://msdn.microsoft.com/en-us/library/hh213417.aspx
Create or Configure an Availability Group Listener
http://msdn.microsoft.com/en-us/library/hh213080.aspx
AlwaysON (HADR): Step-by-Setup setup guide
http://blogs.msdn.com/b/sqlserverfaq/archive/2010/12/17/sql-server-denali-alwayson-hadr-step-by-setupsetup-guide.aspx
SQL AlwaysOn Team Blog
http://blogs.msdn.com/b/sqlalwayson/
Maintenance Plan Does not Backup Database or Log of
Database Defined in Availability Group
http://blogs.msdn.com/b/alwaysonpro/archive/2014/01/02/maintenance-plan-does-not-backup-database-orlog-of-database-that-belongs-to-availability-group.aspx
TECHNET - (HTTP://TECHNET.MICROSOFT.COM)
Configure and manage SQL Server availability groups for
SharePoint 2010
http://technet.microsoft.com/en-us/library/hh913923(v=office.14).aspx#PrereqANDrequire
Configure SQL Server 2012 AlwaysOn Availability Groups for
SharePoint 2013
http://technet.microsoft.com/en-us/library/jj715261(v=office.15).aspx#overview
Step-By-Step: Creating a SQL Server 2012 AlwaysOn
Availability Group
http://blogs.technet.com/b/canitpro/archive/2013/08/20/step-by-step-creating-a-sql-server-2012-alwaysonavailability-group.aspx
Create or Configure an Availability Group Listener
https://technet.microsoft.com/en-us/library/hh213080(v=sql.110).aspx#Restrictions
Implementing MSSQL AlwaysOn Availability Groups with vWorkspace 8.5
Deployment and Configuration Guide
6
SQLSERVER PERFORMANCE BLOG (HTTP://WWW.SQLSERVER-PERFORMANCE.COM)
Using the AlwaysOn Feature of SQL Server 2012
http://www.sql-server-performance.com/2013/alwayson-clustering-failover/
SQL Server 2012 AlwaysOn Availability Group Environmental
Setup
http://www.sql-server-performance.com/2013/sql-server-alwayson-availability-group-environmental-setup/
Configuring and Creating an AlwaysOn Availability Group
http://www.sql-server-performance.com/2013/configuring-creating-alwayson-availability-group-sql-server2012/
Managing and Connecting to AlwaysOn Availability Groups
http://www.sql-server-performance.com/2013/managing-and-connecting-to-alwayson-availability-groups/
SQLpassion (HTTP://WWW.SQLPASSION.AT)
SQL Server 2012 AlwaysOn Availability Groups- Part 1
http://www.sqlpassion.at/archive/2012/03/21/sql-server-2012-alwayson-availability-groups-part-1/
SQL Server 2012 AlwaysOn Availability Groups - Part 2
http://www.sqlpassion.at/archive/2012/07/19/sql-server-2012-alwayson-availability-groups-part-2/
Setting up AlwaysOn through T-SQL
http://www.sqlpassion.at/archive/2012/07/23/sql-server-2012-alwayson-availability-groups-part-3-setting-upalwayson-through-t-sql/
Adding new Replicas
http://www.sqlpassion.at/archive/2012/07/26/sql-server-2012-alwayson-availability-groups-part-4-addingnew-replicas/
Cloud Configurations
Both Microsoft Azure and Amazon AWS configurations are available with SQL AlwaysOn. This guide will not cover
these more complex Public Cloud or Hybrid Cloud configurations. As Azure has matured, Microsoft has provided
additional support for hybrid Availability Group where nodes are supported both locally and in the cloud. Azure
Implementing MSSQL AlwaysOn Availability Groups with vWorkspace 8.5
Deployment and Configuration Guide
7
includes a Relational Database Service called Azure SQL. This cloud offering currently does not include all of the
SQL functionality needed by vWorkspace. However, Azure offers Azure Gallery SQL Enterprise Virtual Server
offerings that allow building a functional SQL AlwaysOn Availability Group.
SQL Improvements for Azure
http://weblogs.asp.net/scottgu/windows-azure-general-availability-of-sql-server-always-on-support-andnotification-hubs-autoscale-improvements-more
http://blogs.technet.com/b/dataplatforminsider/archive/2014/06/19/sql-server-alwayson-availability-groupssupported-between-microsoft-azure-regions.aspx
http://msdn.microsoft.com/library/azure/dn753804.aspx
http://blogs.technet.com/b/dataplatforminsider/archive/2014/11/13/alwayson-availability-groups-nowsupport-internal-listeners-on-azure-virtual-machines.aspx
AlwaysOn Availability Groups with AWS
http://aws.amazon.com/about-aws/whats-new/2014/07/15/microsoft-wsfc-and-sql-server-alwayson-quickstart-reference-deployment/
Implementing MSSQL AlwaysOn Availability Groups with vWorkspace 8.5
Deployment and Configuration Guide
8
4
4
SQL AlwaysOn availability group
implementation
vWorkspace Deployment Scenarios
SQL AlwaysOn Availability Groups could be implemented as part of an initial vWorkspace environment
implementation or could be implemented as part of an upgrade or migration. In both scenarios, you can use the
same general procedures. Begin with the FIRST Enterprise SQL Server as the vWorkspace_Database server along
with vWorkspace_Database_Reporting database (if desired as part of the availability group). Implement this
single server by creating the vWorkspace_Database during the initial installation or migrate the databases to
this server from SQL Express or an existing standalone SQL Standard Server. Migrating SQL Express requires a
Backup and Restore methodology. However migrating from SQL 2008 and later, you can use the Copy Database
Wizard described here:
•
https://technet.microsoft.com/en-us/library/ms188664(v=sql.110).aspx
After the vWorkspace environment is configured and using the FIRST Enterprise SQL Server, create your
Availability Group and extend the group to the SECOND node in the Availability Group. From this point the
Availability Group can be extended to up to EIGHT nodes.
Review Prerequisites, Restrictions, and
Recommendations for AlwaysOn Availability
Groups
Review Configuration Prerequisites on page 5 and consider using the MSDN checklist at Prerequisites,
Restrictions, and Recommendations for AlwaysOn Availability Groups appropriate for the version of SQL you are
deploying. Consider using a SQL Database Engine service account that has been assigned appropriate permission
for SQL, AD, and Clustering described in the references above.
Build two or more identical SQL Enterprise
SQL Servers
SQL AlwaysOn Availability Groups support up to eight nodes within an Availability Group. In the virtualization
environment, this allow multiple copies of the database to exist and maintain synchronization, while the
Failover Cluster manages the active node via cluster ownership of the SQL Listener IP address. With failover, the
Cluster Manager passes ownership of the listener to one of the other nodes which then becomes the active
node. With this methodology, the SQL installation needs to be similar on each of the nodes so that failover
transfer of SQL Server is seamless. All SQL Servers need to be Enterprise version with similar installation
configurations. All installation paths need to be identical for SQL Server. At a minimum, two nodes are required.
Numerous articles provide background on how to virtualize an SQL Server. These include:
•
http://download.microsoft.com/download/6/1/D/61DDE9B6-AB46-48CA-8380D7714C9CB1AB/Best_Practices_for_Virtualizing_and_Managing_SQL_Server_2012.pdf
Implementing MSSQL AlwaysOn Availability Groups with vWorkspace 8.5
Deployment and Configuration Guide
9
•
http://sqlmag.com/sql-server/sql-server-virtualization-tips
•
http://www.vmware.com/files/pdf/sql_server_best_practices_guide.pdf
•
http://channel9.msdn.com/Events/TechEd/NorthAmerica/2013/MDC-B328
Install Enterprise SQL Server
Install SQL Enterprise on the two Windows 2012R2 servers. The installations should be identical with database
and log file directory location the same. Perform a standalone installation for SQL Availability Groups. Of course
Microsoft SQL Server certainly supports Failover Cluster Instances (FCI) should you need that level of fault
tolerance and redundancy. However, in the virtualization arena, multiple copies of the database distributes
across multiple hardware platforms using SQL Availability Groups provides superior redundancy should a
hardware or software failure occur.
Figure 1. SQL installation dialog
TechNet Step-by-step Installation
http://social.technet.microsoft.com/wiki/contents/articles/23878.installing-sql-server-2014-step-by-steptutorial.aspx
SQLServer Central Step-By-Step Installation
http://www.sqlservercentral.com/blogs/sqlsailorcom/2014/04/01/sql-server-2014-install-step-by-step/
AlwaysOn Availability Groups are a function of the SQL Database Engine. So when installing, the only feature
that is absolutely REQUIRED is the Database Engine. You should choose other components such as the Basic and
Advanced Management Tools as the SQL Management Console has an Availability Group Dashboard that is used
for health status and failover wizard functions. You may want Integration Services if you are migrating from a
SQL Express or single SQL Server environment and want to use IS to transfer data or logins across platforms.
Replication Services may be desired for other enterprise databases. See the following blog for more information
if your environment needs SQL replication:
http://blogs.msdn.com/b/alwaysonpro/archive/2014/01/30/setting-up-replication-on-a-database-that-is-partof-an-alwayson-availability-group.aspx. SQL AlwaysOn will need the SQL Native Client (sqlcli.msi) for the
brokers, profile server, etc. so you may want the Client Connectivity Tools installed although the Native client
can be retrieved directly from the installation media also.
So at a minimum, install the Database Engine (SQLENGINE), Management Tools - Basic (SSMS), and Management
Tools - Complete (ADV_SSMS). Other features are optional for you.
Implementing MSSQL AlwaysOn Availability Groups with vWorkspace 8.5
Deployment and Configuration Guide
10
Figure 2. SQL feature selection
In the example within this document, SQL is installed on the system C: drive. Additional disk drives are added
for data and log storage. Database files are located on a D: drive data disk and the transaction log files are
stored on an E: Drive log disk. It is important that all member nodes of an availability group have the same disk
layout relative to the SQL installation. Data directories, log directories, backup directories, SQL system
database locations, etc. should all be the same across the Availability Group to facilitate failover scenarios.
SQL implementation scenarios
If you are building a new vWorkspace implementation, then install the vWorkspace_Database onto one of the
Enterprise SQL Servers, configure the environment, and test with the single SQL Server configuration. If
migrating, then migrate the databases to one of the new Enterprise SQL nodes. Later, implement SQL AlwaysOn
Availability Groups by:
1
Enable the failover clustering feature on all SQL servers that will be a part of the Availability group.
2
Ensure vWorkspace_Database and vWorkspace_Database_Reporting are in FULL recovery mode.
3
Back up the vWorkspace_Database and vWorkspace_Database_Reporting Databases.
4
Create and Configure a Network Quorum Witness Share that all AG nodes can read and write.
5
Create a Network Synchronization Share that all AG nodes can read and write.
6
Synchronize vWorkspace SQL Login Account SIDs and passwords across all AlwaysOn AG Nodes. Not only
should the passwords be synchronized, the SQL SID must also be duplicated so that they are identical on
all Availability Group SQL servers for each user.
7
Create a Failover Cluster with all SQL Servers as nodes in the Cluster.
8
Configure Cluster Quorum with Witness File Share location.n.
9
Enable Availability Groups in all SQL Servers using the SQL Configuration Manager.
10 Create a New Availability Group in SQL Management Console.
11 Configuring the Availability Group Listener.
12 Setting the SQL AG listener DNS Time to Live (TTL) and other follow-up tasks.
13 Install SQL Native Client on all brokers and components running Database Manager and/or has a SYSTEM
DSN configured.
The ordering of these tasks are generalized based on their dependencies. They may be accomplished in any
order as long as these dependencies are accomplished. For example, to complete step seven, you must have
Implementing MSSQL AlwaysOn Availability Groups with vWorkspace 8.5
Deployment and Configuration Guide
11
accomplished Step 1. Step 4, and Step 5 may be accomplished in any order before you start the next section.
Enable the Failover Clustering feature on all SQL Servers that will be part of the Availability Group.
Enable the failover clustering feature on all SQL servers that
will be a part of the Availability group
AlwaysOn Availability Groups requires the Windows Server Failover Clustering (WSFC) feature. For Availability
Groups to be enabled, SQL must reside on a WSFC node. Availability Groups rely on the Failover Cluster to
monitor and manage the current roles of the SQL replicas and to determine how a failover event affects the
availability of each replicas. With SQL AlwaysOn, Failover Clustering serves a role similar to the Witness in SQL
Mirroring and needs to be enabled or turned on as a Feature.
Figure 3. Add Roles and Features wizard
Open Server Manager on each of your SQL Serer Availability Group nodes and navigate to Add Roles and
Features. Continue to the FEATURES selection dialog and enable the Failover Clustering feature. SQL 2014 still
requires .NET 3.5. Therefore, while you are enabling features, ensure that .NET 3.5 is also enabled prior to
installation of SQL Server.
Ensure vWorkspace_Database and
vWorkspace_Database_Reporting are in FULL recovery
mode
As a relational database, SQL uses transaction logs to assist in achieving the Atomicity, Consistency, Isolation,
and Durability (ACID) properties of the data in the database. SQL Server allows the transaction logs to be
configured in one of three database recovery models (see https://msdn.microsoft.com/enus/library/ms189275(v=sql.120).aspx for additional background):
•
Simple. Circular logging; can recover to the end of the last full backup; keeps space requirements small;
no need to manage the transaction log space; database actions that REQUIRE transaction log backups are
NOT supported.
NOTE: Default SQL Express configuration.
Implementing MSSQL AlwaysOn Availability Groups with vWorkspace 8.5
Deployment and Configuration Guide
12
•
Full. Full transaction logging; can recover to a point in time; MUST back up transaction logs and actively
manage transaction log space; supports AlwaysOn Availability Groups.
NOTE: Default SQL Standard & Enterprise configuration.
•
Bulk logged. An adjunct of the full recovery model that permits high-performance bulk copy operations;
can recover to the end of any backup; does not support AlwaysOn configurations.
Figure 4. Database properties, Recovery mode
Additional database requirements are included in Prerequisites, Restrictions, and Recommendations for
AlwaysOn Availability Groups on page 5. These include:
•
Only user databases can belong to Availability Groups (No system databases)
•
Be resident on one instance of SQL Server where the Availability Group will be created
•
Be a read-write database
•
Be a multi-user database
•
Not use AUTO-CLOSE
•
Have at least ONE FULL database backup
•
Can’t belong to any other AGs
•
Can not be configured for DB Mirroring
Back up the vWorkspace_Database and
vWorkspace_Database_Reporting Databases
The Availability Group configuration requires that the databases be backed up prior to configuring the
Availability Group. Therefore, perform a full database backup of all databases that will be included within the
Availability Group.
Implementing MSSQL AlwaysOn Availability Groups with vWorkspace 8.5
Deployment and Configuration Guide
13
Figure 5. Database tasks - Backup - FULL
To back up the databases
1
Open the SQL Management Studio and right click on the vWorkspace_Database.
2
Select Tasks and then select Backup.
3
Accept the defaults for a FULL backup by clicking OK.
4
Perform similar default FULL backups on any other databases that will be part of the availability such as
the vWorkspace_Database_Reporting database.
Create and Configure a Network Quorum Witness Share that
all AG nodes can read and write
Introduced with Server 2008 and later, a File Share Witness (FSW) is a network file share the we create to act as
a tie-breaker when a cluster quorum needs to be established. The FSW is created completely separate from the
cluster nodes and can be created on a file server, a domain controller, a broker, or any available machine in the
environment. See Node and File Share Majority in the following MSDN article for background and review the FWS
recommendations:
•
https://technet.microsoft.com/en-us/library/cc770620(v=WS.10).aspx .
Figure 6. File share witness quorum
The following additional blog articles provide background and step-by-step procedures:
Implementing MSSQL AlwaysOn Availability Groups with vWorkspace 8.5
Deployment and Configuration Guide
14
•
http://blogs.technet.com/b/askpfeplat/archive/2012/06/27/clustering-what-exactly-is-a-file-sharewitness-and-when-should-i-use-one.aspx
•
http://www.howtonetworking.com/server/cluster12.htm
Unlike a disk quorum, the FSW does not hold or maintain configuration data. Thus, you can create this share on
any of your management infrastructure servers with a minimum of 5 MB of free space, with appropriate
architectural and workload considerations.
On the designated FSW server, create a folder with at least 5MB of available disk space and share that folder.
Both NTFS and File Share full permissions will need to be assigned to the Cluster Name Object (CNO) Account
that will be created in Active Directory when we create the AG cluster. The CNO account will be the same name
as the cluster and by default gets created in the Computers container in your Domain. The cluster is created in
Create a Failover Cluster with all SQL Servers as nodes in the Cluster on page 18 and permission within the share
will be assigned within that section.
Create a Network Synchronization Share that all AG nodes
can read and write
When the Availability Group is first created the databases must be synchronized to the other nodes within the
Availability Group. During the New AG creation wizard, the Add AG Replica Wizard, or the Add database to AG
wizard, you are prompted to select a synchronization choice of Full, Join only, or Skip initial data
synchronization. These choices and recommendation are described here:
•
https://msdn.microsoft.com/en-us/library/hh231021(v=sql.120).aspx
For Full synchronization, the account used to start the Database Engine on the primary replica must have read
and write file-system permissions on a network share. For secondary replicas, the account must have read
permission on the network share. Ample free disk space must be planned for storage of a full backup of all
databases within the Availability Group.
Figure 7. SQL Server Configuration Manager – SQL Server Service Account
On the designated Synchronization Share server, create the Network SMB Share using any desired share name.
Ensure there is enough available free space for the database backup files and assign Share permissions to grant
the SQL Service Account Full Share permissions. Also grant Full Control NTFS permissions. Also grant the SYSTEM
account as well and the local Administrators group Full Control permissions.
Implementing MSSQL AlwaysOn Availability Groups with vWorkspace 8.5
Deployment and Configuration Guide
15
Figure 8. Replica Synchronization File Share and NTFS Permissions
Synchronize vWorkspace SQL Login Account SIDs and
passwords across all AlwaysOn AG Nodes
As vWorkspace scales, the database can be migrated from SQL Express or SQL Standard using backup and
restore. Manually create the SQL Logins for pnadmin, ReportViewer, and any other administrator accounts.
Duplicate the existing passwords as the accounts are created. Restore the databases and then re-sync the
account passwords using sp_change_users_login:
Figure 9. SP_CHANGE_USERS_LOGIN
vWorkspace 8.0.1 (MR1) included a Best Practice Guide that details these procedures. It can be found at:
•
http://documents.software.dell.com/vworkspace/8.0.1/vworkspace-8.0-mr1-best-practices/bestpractices-for-database-migration.
With SQL mirroring as well as SQL migrations we used a stored procedure called sp_change_users_login to sync
the vWorkspace database login accounts. SQL Login accounts are stored in the master database in a table called
syslogins. With Windows authentication, SQL stores the user SID in syslogins. Regular SQL logins have a unique
hexadecimal SID generated by the SQL server. If the same SQL Login account is created on two different SQL
servers, they will have the same name but will actually have completely different SIDs. The stored procedure
sp_change_users_login maps the restored database user to the new SID for the user on the new SQL server.
For failovers to work correctly with AlwaysOn, we must take an extra step with our SQL Servers. Not only must
the passwords be in sync, but the SQL account SIDs must also be the same on all SQL servers in an AlwaysOn
Availability Group. The following Microsoft Support article describes a procedure to transfer logins:
•
http://support.microsoft.com/kb/918992.
In the REMARKS of this article, Microsoft notes that SQL 2012 and later change the password hash and cause an
error. Thus, the transfer steps in the article have been simplified and modified below for vWorkspace with SQL
2012. You can simply copy the vWorkspace account SID from the query result from Figure 9 run on the primary
replica, and paste it into the Create LOGIN script at Figure 10 to run on the other SQL Servers:
Use one SQL Server to host the vWorkspace_Database as the primary replica. On this SQL server open a new
query window and execute the following query:
Implementing MSSQL AlwaysOn Availability Groups with vWorkspace 8.5
Deployment and Configuration Guide
16
Figure 10. SQL Query to Retrieve SQL Login SIDs and LoginNames
Figure 11. Executing SQL Query to Retrieve SQL SIDs and LoginNames
Next, substitute the SIDs retrieved in the previous query in the following query (replace the RED and GREEN SIDs
below) and run the Create Login script on each of the OTHER SQL servers that will be part of the Availability
Group:
Figure 12. SQL Query to Create Duplicate SQL Logins
SQL Account transfer and synchronization Step:
1
Retrieve SID for vWorkspace LoginNames from Primary Replica SQL Server.
2
Duplicate Accounts and Passwords on all OTHER replicas in the Availability Group.
Implementing MSSQL AlwaysOn Availability Groups with vWorkspace 8.5
Deployment and Configuration Guide
17
Figure 13. Executing Create Login Query
Create a Failover Cluster with all SQL Servers as nodes in
the Cluster
Review the Step-by-Step Guide: Configuring Accounts in Active Directory at the following location for failover
clusters:
•
https://technet.microsoft.com/en-us/library/cc731002(v=ws.10).aspx
Double-check the IP Address availability and Hostname availability within both Active Directory and DNS. The
Availability Group will need a name. The Failover cluster will need two host names and two IP addresses:
•
Cluster HOSTNAME: ___________SQLHADR_________________________________
•
Cluster IP Address:
•
Availability Group Name: ________vWAlwaysOn______________________________
•
Availability Group Listener HOSTNAME: _________vAG-LISTENER________________
•
Availability Group Listener IP ADDRESS: _________192.168.1.29__________________
___________192.168.1.42_______________________________
Launch the Failover Cluster Manager from Administrative Tools:
Implementing MSSQL AlwaysOn Availability Groups with vWorkspace 8.5
Deployment and Configuration Guide
18
Figure 14. Launch Failover Cluster Manager
The Cluster Manager includes an Overview node, a Clusters node, a Management node and a More Information
node. In the Management Wizards at the bottom of the Cluster Manager start with Validate Configuration. Click
this link to initiate the Validate Configuration Wizard. This wizard will Validate your configuration, will guide
you through Create Cluster and will finally Connect to the Cluster. Have your two available host names and two
IP Address ready.
Figure 15. Select Validate Configuration
To begin, Click the Validate Configuration link. For the Availability Group cluster, we will not have any shared
storage. Click Next to acknowledge the Before you Begin information.
Implementing MSSQL AlwaysOn Availability Groups with vWorkspace 8.5
Deployment and Configuration Guide
19
Figure 16. Before you begin the Create Cluster Wizard
Next, add at least two SQL servers as cluster nodes. In this example, we have two nodes – CWWSQL1 &
CWWSQL2:
Figure 17. Select servers or a cluster
While we could “Run all tests”, our Availability Group has no shared storage, so many of these storage tests will
fail. Therefore, select “Run only tests I select”, so that we can bypass the storage checks.
Figure 18. Validation testing options
In the Test Selection dialog, unselect the Storage tests as our Availability Group will not use shared storage.
Implementing MSSQL AlwaysOn Availability Groups with vWorkspace 8.5
Deployment and Configuration Guide
20
Figure 19. Validation test selection
Also expand the Inventory node and deselect any Storage Adapters you choose to bypass within the storage
inventory.
Selecting to bypass the Storage tests is completely optional. Regardless of whether you run all tests or choose to
select the test that run, you will still need to review the validation results and evaluate the validation items to
correct any failures and review any warnings.
Click “Next” and the Wizard will ensure it can communicate with all nodes. A Validation Summary will be
displayed showing all nodes to be tested and the selected tests that will be run.
Figure 20. Validation configuration summary
Continue, past the Confirmation page and click “Next” to begin the Validation tests.
Implementing MSSQL AlwaysOn Availability Groups with vWorkspace 8.5
Deployment and Configuration Guide
21
Figure 21. Validating configuration
The Validation Wizard will run the tests and display a Summary.
You can expect validation warnings from the network configuration and perhaps other areas if you selected to
run all tests. Verify that all nodes were validated. Scroll through the Summary and see which tests produced
Warnings or Failures.
Click “View Report” and look for any Warnings in Yellow or Failures in Red. Evaluate each finding relative to the
success of the cluster.
Implementing MSSQL AlwaysOn Availability Groups with vWorkspace 8.5
Deployment and Configuration Guide
22
Figure 22. Validation warnings
Figure 23. Validating Configuration
When you are completed reviewing the Validation Summary and are satisfied with the results, you may advance
to the Create Cluster Wizard by Clicking the “Create the cluster now using the validated nodes” Checkbox and
then click “Finish” to advance directly to the Create Cluster Wizard. Otherwise, you’ll return to the Failover
Cluster Manager when any failures are corrected and you can click on the “Create Cluster” Wizard in the
Management Node.
The Create Cluster Wizard begins with an overview dialog. We will need Cluster Host Name and IP Address. Click
“Next” if you have these available:
Implementing MSSQL AlwaysOn Availability Groups with vWorkspace 8.5
Deployment and Configuration Guide
23
Figure 24. Validating configuration
The Create Cluster Wizard begins with an overview dialog. We will need Cluster Host Name and IP Address. Click
“Next” if you have these available:
Implementing MSSQL AlwaysOn Availability Groups with vWorkspace 8.5
Deployment and Configuration Guide
24
Figure 25. Create Cluster Before You Begin
Figure 26. Access Point for Administering the Cluster
In this example, our network group has assigned the Availability Group Failover Cluster the Hostname of
SQLHADR with an IP address of 192.168.1.42. Thus, in the Access Point Dialog, we type SQLHADR as the Cluster
Name and configure the Cluster Management IP Address:
Implementing MSSQL AlwaysOn Availability Groups with vWorkspace 8.5
Deployment and Configuration Guide
25
Figure 27. Cluster name and IP address
Click “Next” and the Create Cluster Confirmation Dialog appears.
IMPORTANT: With Availability Group Clusters, we do not use shared storage. Therefore, deselect the “Add
all eligible storage to the cluster” checkbox. Otherwise, local storage will be grabbed and controlled by
the cluster!
Figure 28. Uncheck the Add Storage checkbox
Outcomes of Accidentally Adding Local Storage to Availability Group Cluster.
To illustrate the effects of leaving this checkbox checked, this SQL Server has three local disk drives – C:
(SYSTEM); D: (DATA); & E: (LOGS):
Implementing MSSQL AlwaysOn Availability Groups with vWorkspace 8.5
Deployment and Configuration Guide
26
Figure 29. Example of local storage configuration
If the checkbox were left checked, then the cluster grabs the non-system disks from all cluster nodes, creating
cluster objects and attempts to take the storage off line. They become unavailable to the local system.
Figure 30. Cluster grabbing non-system disks from SQL Servers
In order to recover the storage and make it available again to the operating systems, you would need to delete
each disk from the Disks Node under the Storage Node in the Cluster Manager.
Select each local disk and select the “Remove” action:
Figure 31. Remove the local disks from the cluster
Availability Group Clusters use local storage, so the cluster Disk Node should be empty:
Implementing MSSQL AlwaysOn Availability Groups with vWorkspace 8.5
Deployment and Configuration Guide
27
Figure 32. Availability group cluster with no storage
Once the Cluster gives the disk back to the operating system, you will need to bring the disks back ONLINE:
Figure 33. Bring Local Disks Back Online if the Cluster Added the Storage
Thus, to preclude this extra work, make sure you do not select the checkbox to add local storage to the cluster
when building an Availability Group environment.
With the Cluster Confirmation properly configured to NOT add local storage, clicking “Next” will attempt to
create the new Availability Group Cluster.
Implementing MSSQL AlwaysOn Availability Groups with vWorkspace 8.5
Deployment and Configuration Guide
28
Figure 34. Uncheck the Add Storage Checkbox and Click “Next”
The Create Cluster Wizard will configure all nodes and start the appropriate Cluster Services:
Figure 35. Create cluster progress
A Summary of the Cluster Creation process shows success, warnings, or failures. In this example, the expected
warning shows that we still need to configure the File Share Witness.
Implementing MSSQL AlwaysOn Availability Groups with vWorkspace 8.5
Deployment and Configuration Guide
29
Figure 36. Create cluster summary
Configure Cluster Quorum with Witness File Share location.
The Cluster Manager Console (Red Arrow) confirms that there is NO File Share Witness configured. Many
configurations actions must be accomplished on the node that is the Current Host Server (Green Arrow).
Figure 37. Cluster Manager shows No Cluster Witness
To configure the File Share Witness that was created in Create and Configure a Network Quorum Witness Share
that all AG nodes can read and write on page 14, connect to the Current Host Server (Green Arrow) and right
click on the cluster name and select “More Actions” (Red Arrows). This same Actions menu is available on the
far right of the console.
Implementing MSSQL AlwaysOn Availability Groups with vWorkspace 8.5
Deployment and Configuration Guide
30
Figure 38. Select Actions – Configure Cluster Quorum Settings
We want to configure a vote for each node plus another vote for the witness. This is called Node and File Share
Majority. Review Create and Configure a Network Quorum Witness Share that all AG nodes can read and write on
page 14 for additional information. Windows Server 2012R2 adds additional capabilities to Failover Clustering
including Dynamic Witness, which dynamically adjusts the witness vote.
The link in the “Before You Begin” dialog will take you to a Technet article which explains the cluster
improvements:
•
https://technet.microsoft.com/library/dn265972.aspx.
Figure 39. Before You Begin - Configure Cluster Quorum Wizard
The top option is default, but we have not identified or configured the witness. Thus, we select the middle,
second option to “Select the quorum witness”. This will also invoke dynamic quorum configuration for us.
Implementing MSSQL AlwaysOn Availability Groups with vWorkspace 8.5
Deployment and Configuration Guide
31
Figure 40. Select Quorum Configuration Option
Select the middle, second option, “Configure a file share witness” to configure a File Share Witness.
Figure 41. Select Configure a file share witness
Next, we’ll configure the File Share UNC. But first, we need to grant SQLHADR$ permissions to the share as we
discussed in Create and Configure a Network Quorum Witness Share that all AG nodes can read and write on
page 14. Thus, navigate to the designated server where the File Share Witness was created earlier. We created
a “Quorum” File Share. In this example, \\CWUPM01 has both the Quorum and the Database Sync UNC Shares.
The Quorum share was created earlier:
Implementing MSSQL AlwaysOn Availability Groups with vWorkspace 8.5
Deployment and Configuration Guide
32
Figure 42. Quorum File Share Witness on \\CWWUPM01
Both NTFS permissions and File Share permissions need to be assigned to the Cluster Host Name Object Account
which we called SQLHADR in this example. For permissions, the Cluster Host Name Object is an Active Directory
Computer account, SQLHADR$. Assign both NTFS and File Share identical permissions.
Click on the share permissions and clear out the previous inherited entries and add the following permissions:
•
Cluster Name Object (CNO) Account (SQLHADR$) – Full Control
•
SYSTEM – Full Control
•
SQL Database Engine Service Account (SQLAdmin) – Full Control
•
Local Server Administrators Group – Full Control
Figure 43. Assign UNC and NTFS permissions to the Cluster Hostname
Once permissions are assigned, the UNC share path can be configured:
Implementing MSSQL AlwaysOn Availability Groups with vWorkspace 8.5
Deployment and Configuration Guide
33
Figure 44. Configure the File Share Witness
Browse for the Shared Folder and enter the designated File Share Server. Click “Show Shared Folders” and select
the Files Share Witness folder. Click “OK” and then click “Next”. The Configuration Wizard will then setup and
configure the Witness.
Figure 45. Confirmation of the File Share Witness
When you click “Next”, the Wizard creates a GUID folder representing the Cluster within the File Share Witness
and verifies permissions by writing a zero-byte “VerifyShareWriteAccess” file. It then writes a 1KB Witness
configuration file.
Implementing MSSQL AlwaysOn Availability Groups with vWorkspace 8.5
Deployment and Configuration Guide
34
Figure 46. File Share Witness GUID Directory
The Wizard completes with a Summary confirmation. Click “Finish” to complete the Wizard.
Figure 47. File Share Witness Wizard Summary
Enable Availability Groups in all SQL Servers using the SQL
Configuration Manager
Because of the prerequisites require for AlwaysOn Availability Groups in SQL, the feature is turned off initially
and must be enabled within the SQL Server 201X Configuration Manager. This is the utility that configures the
SQL services; allows you to change the service authentication context; and manage the SQL Server Clients. The
launch icon and Management console look like this:
Figure 48. SQL Server 201X Configuration Manager
On each of the SQL nodes in the Availability Group, open the SQL Server 201X Configuration Manager console
and select the SQL Server database engine in the console.
Right click and select SQL Server (MSSQLSERVER) “Properties” to open the Properties dialog box.
Implementing MSSQL AlwaysOn Availability Groups with vWorkspace 8.5
Deployment and Configuration Guide
35
Figure 49. SQL Server Properties
The properties dialog will open. Above the “Log On” tab you will see “AlwaysOn High Availability”. Select this
tab and CHECK the “Enable AlwaysOn Availability Groups”.
Figure 50. Enable AlwaysOn Availability Groups (HADR)
The console will alert you that this configuration is only read upon service startup. Thus you will need to restart
the SQL database engine.
Figure 51. Restart SQL Warning for Configuration to Take Effect
IMPORTANT: Remember that this configuration to Enable AlwaysOn Availability Groups needs to be
accomplished on all SQL replica nodes.
You can’t enable AlwaysOn within the SQL Management Studio itself. But you can check to see if it has been
enabled. Select the Server Properties within the Studio and look down the General Properties for “Is HADR
Enabled”.
Implementing MSSQL AlwaysOn Availability Groups with vWorkspace 8.5
Deployment and Configuration Guide
36
Figure 52. Verify HADR is Enabled for AlwaysOn Availability Groups
Create a New Availability Group in SQL Management Console
We’re now ready to create the AlwayOn Availability Group for vWorkspace. With Availability Groups, everything
is done in the SQL Management Studio. They’re created, operated, and maintained from within the SQL
Management Studio. You do not use the Failover Cluster Manager to failover Availability Groups. You use the SQL
Management Studio. Our vWorkspace databases are running from our first SQL server called CWWSQL01 so this
will be our primary replica and where we create the Availability Group. You could just as easily create a new
empty vWorkspace database for a new farm installation.
Once we’ve enabled HADR, you can right click on the “Availability Groups” node and the menu provides three
ways to create a new Availability Group. You can “Start PowerShell” and create and configure everything via
scripting; you can click “New Availability Group” and create and configure things manually; or you can use the
EASY BUTTON and select the “New Availability Group Wizard.”
For this example, we’ll use the New Availability Group Wizard.
Implementing MSSQL AlwaysOn Availability Groups with vWorkspace 8.5
Deployment and Configuration Guide
37
Figure 53. Availability Group Options
The New Availability Group Wizard walks us through seven major steps. We’ll need an Availability Group Name;
identify the databases to include in the AG; specify the nodes and replicas; select synchronization; validate the
configuration; summarize tasks; and display results:
Figure 54. New Availability Group Wizard Introduction
For our example, we’ll call our Availability Group “vWAlwaysOn”. So click “Next” on the Wizard “Introduction”
and then enter your Availability Group Name in the group name dialog:
Implementing MSSQL AlwaysOn Availability Groups with vWorkspace 8.5
Deployment and Configuration Guide
38
Figure 55. New availability group name
Next, the Wizard wants us to select our databases. Since the vWorkspace databases are running on this SQL
Server (CWWSQL1), we see them and the Wizard determines that they meet the database prerequisites.
Figure 56. New Availability Group Select Databases Prerequisites Met
If the Wizard finds that the databases haven’t been backed up or don’t meet the requirements mentioned in
Ensure vWorkspace_Database and vWorkspace_Database_Reporting are in FULL recovery mode on page 12 such
as Auto-close being enabled then you will need to correct them prior to continuing.
Figure 57. New Availability Group Database Prerequisites Not Met
The Wizard status tells you what the issue is with the database. In the above example, Auto-Close is enabled.
Thus, the database properties is opened and Auto-Closed is changed from True to False and the Wizard run again
after the database configuration is updated. Clicking “Refresh” rechecks the database.
Implementing MSSQL AlwaysOn Availability Groups with vWorkspace 8.5
Deployment and Configuration Guide
39
Figure 58. Database Configuration with Auto-Close Enabled.
Once the databases are selected and they meet the prerequisites are met, click “Next” to Specify the Replicas.
AG can support up to eight replica nodes. We will be adding only two replicas – CWWSQL1 and CWWSQL2. The
Replicas Wizard has four tabs to configure Replica Server Instances; Replica Server Endpoints; Backup
Preferences; and Listener.
Because the Listener engages the Failover Cluster to create a Cluster Object for the Listener, the default Wizard
configuration is to create the Listener “later” after completion of Availability Group in SQL. The Listener needs
a Listener Name and IP Address and we will want to verify Listener Name uniqueness in Active Directory, DNS,
Netbios; and ensure the static IP Address is available.
Our first replica will have already been added to the Wizard. We want “Automatic Failover and Synchronous
Commit”, as well as the ability to read any of our secondary replicas.
Thus, we configure CWWSQL1 as show below:
Figure 59. Specify Primary Replica
Next, we add the other replica server instances. We’ll add CWWSQL2 and configure it the same as the Primary.
The Wizard must connect to each replica node as we add it to the Wizard. After you authenticate, the
secondary replica is added. Configure it the same as the primary:
Implementing MSSQL AlwaysOn Availability Groups with vWorkspace 8.5
Deployment and Configuration Guide
40
Figure 60. Specify Secondary Replica
To participate in AlwaysOn Availability Groups or database mirroring, a SQL server instance requires a dedicated
database mirroring endpoint. See the following article:
•
https://technet.microsoft.com/en-us/library/ms179511(v=sql.120).aspx.
We will accept the default configuration entries in the Wizard.
Figure 61. Specify Endpoint Configurations
You may configure your backup preferences as required by your implementation. Because we set our secondary
replicas as readable, we can use any of them for backup tasks. We will accept the defaults.
Figure 62. Specify Backup Preferences
Because creating the AG Listener will require a unique Listener Hostname and static IP address and will invoke
creation of a Cluster Object and Active Directory entries, the default Wizard configuration is to create the AG
Listener separately after the AG Wizard has been completed. We will accept the default Wizard configuration.
Implementing MSSQL AlwaysOn Availability Groups with vWorkspace 8.5
Deployment and Configuration Guide
41
However, you may create the AG Listener within the Wizard if you have verified your Listener Hostname and IP
Address.
Figure 63. Do not create an Availability Group Listener Now
We will create the AG Listener in Configuring the Availability Group Listener on page 48, after the AG Wizard
has completed. To create and configure the Listener within the Wizard, enter your Listener Hostname/DNS
Name, TCP port, and click “Add” to configure the Listener static IP address.
Figure 64. Create an Availability Group Listener in Wizard
Availability Groups support multiple subnet clusters so enter your replica subnet and the subnet IP Address for
the AG Listener. Production AG Listeners should always use static IP Addresses.
Figure 65. Add Availability Group Listener IP Address in Wizard
You may add additional subnet Listeners if your environment requires them. Multiple Listener pros and cons are
discussed in this article:
Implementing MSSQL AlwaysOn Availability Groups with vWorkspace 8.5
Deployment and Configuration Guide
42
•
http://blogs.msdn.com/b/sqlalwayson/archive/2012/02/03/how-to-create-multiple-listeners-for-sameavailability-group-goden-yao.aspx.
After the Listener is configured, click “Next” to continue.
Figure 66. Add Availability Group Listener IP Address in Wizard
The AG Wizard needs to setup Initial Data Synchronization preferences. We covered this option in Create a
Network Synchronization Share that all AG nodes can read and write on page 15. For our example, CWWSQL1
holds the primary replica and database. We will need the Wizard to create secondary replica databases and
provide Full Synchronization of the data to these replicas. Therefore, we’ll select Full Synchronization and use
the Sync Share we created and configured. Once configured, click “Next” to continue to Validation.
Figure 67. Specify Data Synchronization Preferences
If we accepted the default settings to create the AG Listener after the Wizard completion, then the Validation
should proceed with one expected Warning about the AG Listener.
Implementing MSSQL AlwaysOn Availability Groups with vWorkspace 8.5
Deployment and Configuration Guide
43
Figure 68. Validation when no listener is added with the Wizard
If we configured the AG Listener, then the Validation should proceed without any Warnings. You will need to
evaluate and correct any Validation failures to proceed. Click “Next” to continue.
Figure 69. Validation when a listener is added with the Wizard
The Wizard summarizes the automation tasks that need to be accomplished. It is advisable to export the SQL
script for documentation and review. This can be accomplished using the “Script” button.
Implementing MSSQL AlwaysOn Availability Groups with vWorkspace 8.5
Deployment and Configuration Guide
44
Figure 70. New Availability Group Wizard summary
When you click “Finish”, the Wizard will begin execution of the AG Wizard configuration script and display a
progress bar.
Figure 71. New Availability Group Wizard progress
Click “More Details” to see each task and its status:
Implementing MSSQL AlwaysOn Availability Groups with vWorkspace 8.5
Deployment and Configuration Guide
45
Figure 72. New Availability Group Wizard Progress with details
At the completion of the automation, review the Results.
Figure 73. New Availability Group Wizard results
Availability Groups are created, operated, managed, and maintained within the SQL Management Studio. Even
failover and recovery uses the SQL Management Studio. Because the Failover Cluster only manages ownership of
the AG Listener, it can failover the AG Listener, but the Cluster Manager does not know how to transfer the
database mirroring and log synchronization responsibilities. Thus, you should not use the Failover Cluster
Manager to effect Availability Group failovers or recovery. Use the Dashboard View within the SQL Management
Studio.
Figure Figure 74 shows the primary and secondary replicas with the Availability Group Dashboard open on each
server.
As an alternative to managing the Availability Group using the SQL Management Studio, SQL PowerShell could
also be used to automate these tasks.
Implementing MSSQL AlwaysOn Availability Groups with vWorkspace 8.5
Deployment and Configuration Guide
46
Figure 74. Availability Group Replicas with Dashboard Showing
To assist with managing the Availability Group, you can add all AG nodes within the SQL Management Studio.
This multi-node configuration can be duplicated across all nodes of the AG so that regardless of the server, you
can manage the environment easily.
Implementing MSSQL AlwaysOn Availability Groups with vWorkspace 8.5
Deployment and Configuration Guide
47
Figure 75. SQL Management Studio with all Replicas Connected
Configuring the Availability Group Listener
Accepting the Availability Group Creation Wizard default configurations requires that we create the Availability
Group Listener manually after the Availability Group has been setup and configured. Within the SQL
Management Studio, our Availability Group (vWAlwaysOn) has three subnodes. They are “Availability Replicas”
that shows and allows management of our SQL Server Instances; “Availability Databases” that shows and allows
management of our highly available databases; and “Availability Group Listeners” that shows and manages our
subnet AG Listeners.
Within the Management Studio, the AG Listener will require a unique Listener Hostname; a subnet
identification; a static IP address; and a TCP port for the Listener to listen on. There are several ways to
configure the TCP Listener port:
•
Specify different port numbers for each SQL instance and a different port number for the AG Listener.
•
Specify the same port number for all the SQL instances (as a standard), and a different port number for
the AG Listener.
•
Specify the same port number for all the SQL instances as well as the AG Listener. This is possible
because the IP address of each SQL Server instance is different from the IP address of the AG Listener.
For vWorkspace, using the default SQL port of TCP 1433 for the AG Listener is optimum. We can choose to use
TCP port 1433 for the all of the SQL instances or use dynamic port assignment and allow the SQL Browser to
advertise them. The following blog explains all of these options:
•
http://blogs.msdn.com/b/sqlcat/archive/2014/02/03/alwayson-availability-groups-listener-namedinstances-port-numbers-etc.aspx.
Implementing MSSQL AlwaysOn Availability Groups with vWorkspace 8.5
Deployment and Configuration Guide
48
Figure 76. Creating and configuring an AG listener manually
AG Listener creation should be performed on the Primary Node. We begin the AG Listener setup and
configuration by right clicking in the SQL Management Studio on the AG Listener node and selecting “Add
Listener” We will call our AG Listener vWAG-LISTENER and assign it a static IP Address of 192.168.1.29. The
initial setup requires a Listener Name, TCP port, but configures for DHCP. DHCP should not be used in a
production HADR scenario.
Figure 77. Configuring an AG listener name and port
Change the DHCP configuration to Static IP and then click the “Add” button.
Implementing MSSQL AlwaysOn Availability Groups with vWorkspace 8.5
Deployment and Configuration Guide
49
Figure 78. Configuring an AG listener static IP address
Click “OK” to add the subnet static IP. In some scenarios, you might create multiple subnet listeners. For our
example, the single IP Address is sufficient. As with the Availability Group automation, you may want to save
the Listener creation automation script by clicking on the “Script” button and saving the scripting for
documentation. Click “OK” to continue. The lower Progress window will change from “Ready” to “Executing” as
the creation script executes.
Figure 79. Creating the AG listener manually using a script
The new AG listener will now display in the SQL Management Studio.
Implementing MSSQL AlwaysOn Availability Groups with vWorkspace 8.5
Deployment and Configuration Guide
50
Figure 80. Creating the AG listener manually using a script
Now the Cluster is complete. If we look in the Failover Cluster Manager, you’ll see the vWAlwaysOn Availability
Group Object with the vWAG-LISTENER Resource. Remember that management and maintenance of THIS cluster
is accomplished in the SQL Management Studio!
Figure 81. Failover cluster manager with summary and resources
Setting the SQL AG listener DNS Time to Live (TTL) and
other follow-up tasks
When the Failover Cluster registers the Availability Group Listener in DNS, it sets the Default Time To Live (TTL)
in seconds to 1200 or 20 minutes. This setting is a default parameter setting on the listener network name
resource within the cluster.
For most cluster implementations, a 20 minute TTL is an adequate setting. But in our database failover
scenario, this setting is much too long. We want our SQL clients to update their DNS cache more often. In the
prerequisites document linked at paragraph Prerequisites, Restrictions, and Recommendations for AlwaysOn
Availability Groups on page 5, it suggests changing this configuration. The following blog provides this and other
Implementing MSSQL AlwaysOn Availability Groups with vWorkspace 8.5
Deployment and Configuration Guide
51
settings relative to Availability Groups:
•
https://msdn.microsoft.com/en-us/library/hh213080.aspx#HostRecordTTL.
Additional Availability Group Follow-up Tasks include:
•
MultiSubnetFailover Keyword and Associated Features
•
RegisterAllProvidersIP Setting
•
Disable RegisterAllProvidersIP
If we set debug on within nslookup and query for our listener name, we can verify this TTL:
Figure 82. NSLOOKUP query for TTL
On the primary SQL node of the Availability Group, open PowerShell as Administrator so that we can view the
Cluster Configuration and modify the DNS TTL. We’ll follow the MSDN recommendation and set the DNS TTL to 5
minutes or 300 seconds. Our SQL Server Native Client or ODBC Driver 11 will begin retries immediately on
failover. However, complete environmental recovery could take up to the DNS TTL for AG Listener DNS update
at the client. Lowering the TTL will increase network traffic slightly. The DNS TTL value should be evaluated
and set as required for your environment and recovery.
Type Import-Module FailoverClusters to load the Cluster PowerShell Module.
Figure 83. PowerShell import module
Verify the cluster settings by typing Get-Cluster.
Implementing MSSQL AlwaysOn Availability Groups with vWorkspace 8.5
Deployment and Configuration Guide
52
Figure 84. PowerShell Get-Cluster Command
Verify the cluster resources by typing Get-ClusterResource. We’re looking for the NetworkName of our AlwaysOn
Listener. In this example it’s vWAlwaysOn_vWAG-LISTENER.
Figure 85. PowerShell Get-ClusterResource Command
We see it’s set for 1200. Now we need to change it to 300 seconds or 5 minutes. In the MSDN article they provide
the following recommendation for setting the HostRecordTTL.
Figure 86. PowerShell Set-ClusterParameter Syntax
Since we’re already loaded the module and found our Cluster Resource, we can just modify the previous GetClusterParameter to a Set-ClusterParameter. In the previous command we typed Get-ClusterResource
vWAlwaysOn_vWAG-Listener | Get-ClusterParameter.
Change Get-ClusterParameter to Set-ClusterParameter.
The Set-ClusterParameter needs two inputs – the parameter name (HostRecordTTL) and its new value (300). So
press the up arrow and modify or type ClusterResource vWAlwaysOn_vWAG-Listener | Set-ClusterParameter
HostRecordTTL 300.
Implementing MSSQL AlwaysOn Availability Groups with vWorkspace 8.5
Deployment and Configuration Guide
53
Figure 87. PowerShell Set-ClusterParameter Command
Our window shows success but notes that we must cycle the listener off line and then back Online. To verify the
change you can retype the previous Get-ClusterParameter command to verify:
Figure 88. PowerShell Get-ClusterParameter Summary
The SQL Server Native Client and ODBC Driver 11 include a new connection string keyword called
MultiSubnetFailover used to enable:
•
Faster multi-subnet failover to a multi-subnet listener for an AlwaysOn Availability Group or Failover
Cluster Instances.
•
Faster single subnet failover to a single subnet listener for an AlwaysOn Availability Group or Failover
Cluster Instances. This feature is used when connecting to a listener that has a single IP in a single
subnet. This performs more aggressive TCP connection retries to speed up single subnet failovers.
The follow-up MSDN article referenced earlier in this section describes setting the Cluster Parameter
“RegisterAllProvidersIP” to “0” if you are using legacy .NET Framework 3.5 or OLEDB which do not support the
MultiSubnetFailover keyword. vWorkspace 8.5 and later should not need this setting which is set to “1” as shown
Implementing MSSQL AlwaysOn Availability Groups with vWorkspace 8.5
Deployment and Configuration Guide
54
in Figure 88.
Install SQL Native Client on all brokers and components
running Database Manager and/or has a SYSTEM DSN
configured
Beginning with SQL Server 2012, Microsoft is aligning with ODBC for all Native Relational Data Access. SQL
Server 2014 includes and installs the SQL Server 2012 Native Client. There is no SQL Server 2014 Native Client
and there will be no more updates to the ODBC driver in SQL Server Native Client.
The successor to the ODBC driver in SQL Server Native Client, which is called the Microsoft ODBC Driver 11 for
SQL Server on Windows, is installed with SQL Server 2014. For more information about the Microsoft ODBC
Driver 11 for SQL Server on Windows, see Microsoft ODBC Driver 11 for SQL Server - Windows. The OLE DB
Provider in SQL Server Native Client was last updated in SQL Server 2012 Native Client.
Both of these SQL clients are included on the SQL2014 DVD and the following article outlines installing the
native Client:
•
https://technet.microsoft.com/en-US/library/ms131321(v=sql.120).aspx.
Installing the ODBC client is similar. If you browse the DVD, the SQL clients are located in the 1033_ENU_LP
folder, within the Setup folder, and within the x64 folder. The files are sqlncli.msi and msodbcsql.msi. Their
installation, setup, and configuration is similar. But you only need to install one or the other to provide
AlwaysOn Availability Group connectivity.
Figure 89. SQL client file locations
To distribute the client(s) to all vWorkspace components that communicate with the database (PNDMSVC), you
may want to create a network share to ease deployment.
Implementing MSSQL AlwaysOn Availability Groups with vWorkspace 8.5
Deployment and Configuration Guide
55
Figure 90. SQL native & SQL ODBC clients
By default, vWorkspace creates a 32-bit SQL Server DSN using the SQL Server Driver SQLSRV32.DLL. However,
this older driver does not support SQL AlwayOn Failover. In the same way we had to install and configure the
newer SQL Native Client with Mirroring, we will also need to install the newer SQL native or SQL ODBC Drivers
and create a new 32-bit DSN.
Figure 91. SQL server, SQL native & SQL ODBC client DSNs
We’ll contrast installing and configuring both the SQL Native and the SQL ODBC client drivers. Both consist of
five steps and can be automated per https://technet.microsoft.com/en-US/library/ms131321(v=sql.120).aspx.
msiexec /i sqlncli.msi /qr IACCEPTSQLNCLILICENSETERMS=YES
msiexec /I msodbcsql.msi /qr IACCEPTMSODBCSQLLICENSETERMS=YES
In the screen shots below, the Native Client is on the left and the ODBC Driver is on the right: Later, we will use
and compare configurations and failover performance using both clients. In the production environment, you do
not need to install both of these newer clients. Only one new client and one new 32-bit DSN are required.
Implementing MSSQL AlwaysOn Availability Groups with vWorkspace 8.5
Deployment and Configuration Guide
56
Figure 92. SQL native & SQL ODBC client welcome
Figure 93. SQL native & SQL ODBC client license agreement
Figure 94. SQL native & SQL ODBC client component selection
Implementing MSSQL AlwaysOn Availability Groups with vWorkspace 8.5
Deployment and Configuration Guide
57
Figure 95. SQL native & SQL ODBC client ready to install
Figure 96. SQL native & SQL ODBC client installation finished
After installing the newer SQL Client, you will need to configure the 32-bit DSN. Open Administrative Tools and
launch the 32-bit ODBC Data Source Administrator:
Figure 97. 32-bit ODBC Data Source Administrator
Configure SQL native client DSN
We will configure the SQL Native Client DSN first. Click “Add” to launch the creation of a new DSN. Scroll down
and select “SQL Server Native Client” and click “Finish”.
Implementing MSSQL AlwaysOn Availability Groups with vWorkspace 8.5
Deployment and Configuration Guide
58
Figure 98. SQL native client drive snlection
In the “Create a New DSN” dialog, enter a DSN name that will be used for all vWorkspace Native Client
configurations. The description is optional. In the Server list box, enter our Availability Group Listener Name.
Figure 99. SQL native client new DSN
Next, configure the SQL Authentication. vWorkspace uses SQL Server authentication using a login ID. In
Synchronize vWorkspace SQL Login Account SIDs and passwords across all AlwaysOn AG Nodes on page 16 we
synchronized both the Login ID SID and password across ALL replica nodes.
Implementing MSSQL AlwaysOn Availability Groups with vWorkspace 8.5
Deployment and Configuration Guide
59
Figure 100. SQL native client authentication
Click “Next” and check the “Change the default database to:” checkbox. Select the vWorkspace database and
check the “Multi-subnet failover” checkbox.
Figure 101. SQL native client database selection
The MultiSubnetFailover checkbox configures SQL Server Native Client to provide faster detection of and
connection to the (currently) active primary replica server. The following articles provide additional background
on HADR configurations:
•
https://technet.microsoft.com/en-us/library/ms130822.aspx
Additionally, we can specify MultiSubnetFailover=Yes when connecting to a SQL Server 2012 availability group
listener or SQL Server 2012 Failover Cluster Instance within our vWorkspace database configuration.
Click “Next” and accept the default settings in the next DSN dialog and then click “Finish”:
Implementing MSSQL AlwaysOn Availability Groups with vWorkspace 8.5
Deployment and Configuration Guide
60
Figure 102. SQL native client database DSN properties
To conclude creating the SQL Native Client DSN, you get a summary and can test the connection. Click “Test
Data Source” and verify that it completes successfully:
Figure 103. SQL native client database DSN summary and test
Configure ODBC driver 11 for SQL server DSN
The ODBC Driver 11 for SQL Server provides additional retry settings and may provide more robust failover
reconnections in multi-site environments. Thus, as an alternative to the Native Client, we will also configure a
DSN for the ODBC Driver 11 for SQL Server. Both of these newer drivers support AlwaysOn Availability Groups,
but you only need to install ONE driver.
Implementing MSSQL AlwaysOn Availability Groups with vWorkspace 8.5
Deployment and Configuration Guide
61
Figure 104. Create ODBC driver 11 for SQL server DSN
Click “Add” to launch the creation of a new DSN. Scroll down and select “ODBC Driver 11 for SQL Server” and
click “Finish”.
Figure 105. Select ODBC driver 11 for SQL server
In the “Create a New DSN” dialog, enter a DSN name that will be used for all vWorkspace Native Client
configurations. The description is optional. In the Server list box, enter our Availability Group Listener Name.
The configuration of this DSN is almost identical to the DSN we configured for the Native Client.
Implementing MSSQL AlwaysOn Availability Groups with vWorkspace 8.5
Deployment and Configuration Guide
62
Figure 106. Create a new SQL server DSN
Next, configure the SQL Authentication. vWorkspace uses SQL Server authentication using a login ID. In
Synchronize vWorkspace SQL Login Account SIDs and passwords across all AlwaysOn AG Nodes on page 16 we
synchronized both the Login ID SID and password across ALL replica nodes.
Figure 107. Configure authentication
Similar to the Native Client, click “Next” and check the “Change the default database to:” checkbox. Select the
vWorkspace database and check the “Multi-subnet failover” checkbox.
Implementing MSSQL AlwaysOn Availability Groups with vWorkspace 8.5
Deployment and Configuration Guide
63
Figure 108. Select vWorkspace database and MultiSubnetFailover
In the following dialog, the ODBC Driver 11 for SQL Server provides two configurations not available in the
Native Client. They are “Connect Retry Count” and “Connect Retry Interval (seconds)”. These provide a little
greater control for the failover and retry process.
Figure 109. Accept defaults and configure Retry if desired
To conclude creating the ODBC Driver 11 for SQL Server DSN, you get a summary and can test the connection.
Click “Test Data Source” and verify that it completes successfully:
Implementing MSSQL AlwaysOn Availability Groups with vWorkspace 8.5
Deployment and Configuration Guide
64
Figure 110. DSBC DSN summary and test
For testing, we now have the original SQL Server DSN and the two newer native and ODBC Driver 11 DSNs that
support AlwaysOn availability groups.
Figure 111. ODBC DSN administrator with three configured DSNs
Changing the DSN configuration in the vWorkspace Management Console
vWorkspace components that communicate with the database include the vWorkspace Database Management
Service (PNDMSVC) and the vWorkspace Management Console (PNCONSOLE). These components use a SQL
connection string that combines the DSN configuration with Login ID credentials and password to effect a SQL
connection to the database server. To change that SQL connection string we need a configured DSN and can then
change the SQL connection in the vWorkspace Management Console.
However, to accomplish any database configuration changes, we must launch the vWorkspace Management
Console with a right click and selecting “Run as Administrator”. Thus, right click on the console and select “Run
as administrator”.
Implementing MSSQL AlwaysOn Availability Groups with vWorkspace 8.5
Deployment and Configuration Guide
65
Figure 112. Run the Management Console as Administrator
Select the “File” menu and then select “Database Configuration”:
Figure 113. Select the File menu and Database Configuration
In the Configure vWorkspace Database dialog, drop the list box down and select the SQL Native DSN. Since
we’ve synchronized the Login IDs and passwords, simply click “OK” and the SQL connection string is written to
the local registry. The console uses this string to connect to the database. So the console reinitializes the
connection and refreshes the vWorkspace Management Console.
Figure 114. Select File Database DSN from drop down
For testing, we could also select the ODBC Driver DSN and click “OK”
Implementing MSSQL AlwaysOn Availability Groups with vWorkspace 8.5
Deployment and Configuration Guide
66
Figure 115. DSN selected, Login ID and Password remain the same
You can also add any ODBC keywords such as “MultiSubnetFailover=Yes” in the additional ODBC parameters.
While the DSN should provide this setting, we will include it in our failover testing:
Figure 116. Add ODBC keyword parameter
SQL AlwaysOn maintenance tasks
One of the database requirements for SQL AlwaysOn Availability Groups is FULL recovery mode. This
configuration requires that we backup the AG databases regularly so that the transaction logs are truncated and
log disk space kept to a minimum. A benefit of Availability Group replicas is that we can backup any of the
Read-only secondary replicas and allow the primary to continue to service the vWorkspace farm. In Specify
Backup Preferences on page 41, we set the backup preference for the secondary replicas. The following articles
provide SQL AlwaysOn AG maintenance background:
•
https://msdn.microsoft.com/en-us/library/hh245119(v=sql.120).aspx
•
http://blogs.msdn.com/b/sqlgardner/archive/2012/07/18/sql-2012-alwayson-and-backups-part-1offloading-the-work-to-a-replica.aspx
•
http://blogs.msdn.com/b/sqlgardner/archive/2012/07/21/sql-2012-alwayson-and-backups-part-2configuring-backup-preferences-and-automating-backups.aspx
•
http://blogs.msdn.com/b/sqlgardner/archive/2012/08/28/sql-2012-alwayson-and-backups-part-3restore.aspx
Since backups could happen on any secondary replica if one is available, then it might be preferred to write
backups from all nodes to the same file share and to put the server name, database name, and date-time stamp
into the file name. That way you know where the backups originated from and can easily formulate a restore
chain if needed. We will create an identical Maintenance Plan on all AG nodes. If three or more nodes exist,
then nodes priorities should be differentiated with their backup priority.
Implementing MSSQL AlwaysOn Availability Groups with vWorkspace 8.5
Deployment and Configuration Guide
67
Figure 117. Replica backup priorities
Open the SQL Management Studio on a secondary replica and expand the Management node. Right click on
Maintenance Plan and select “Maintenance Plan Wizard”. You could manually create the plan using the “New
Maintenance Plan” selection, but the Wizard nicely walks you through all of the Plan steps and guides your task
selection. We must select only those tasks that can execute on a secondary replica. These include:
•
Check Database Integrity. Ensure successful backup
•
Back Up Database (Full). Must be configured as “Copy Only Backup”
•
Back Up Database (Transaction Log). Truncate logs
•
Clean Up History. Clean up and maintain a limited set of backups
Figure 118. Maintenance Plan wizard to create a backup job
Provide a Name for the plan and configure its schedule. Click “Change” to configure the plan schedule:
Implementing MSSQL AlwaysOn Availability Groups with vWorkspace 8.5
Deployment and Configuration Guide
68
Figure 119. Select Plan Properties
Figure 120. New Job Schedule
Configure the schedule as required by the implementation. In this example, the plan will maintain two weeks of
backups performed every three days. This is merely an example as implementation requirements will need to
be discussed and frequency of backups configured as required. Click “OK” to return to the Plan Properties
dialog and there, click “Next” to continue. Next, we’ll select the job tasks to be preformed.
Implementing MSSQL AlwaysOn Availability Groups with vWorkspace 8.5
Deployment and Configuration Guide
69
Figure 121. Select Maintenance Tasks
Arrange the tasks in the order you want them executed. Here, we’re cleaning up History last:
Figure 122. Select Maintenance Task Order
The Wizard will now guide us through configuring each task. For the Check Integrity task, accept the defaults
and select our vWorkspace databases.
Figure 123. Check Database Integrity configuration
The next task to configure is the Full Backup Task. The dialog has three tabs. On the first tab, we select our
vWorkspace databases; the second tab configures the backup destination, while the third tab configures backup
options. Use the drop-down and select the vWorkspace Databases. Then click on the second tab for destination.
Implementing MSSQL AlwaysOn Availability Groups with vWorkspace 8.5
Deployment and Configuration Guide
70
Figure 124. Define databases to back up
Figure 125. Select databases
On the destination tab, selecting “Create a sub-directory for each database” will help organize the backups.
Verify the destination location and change it if necessary or desired.
Implementing MSSQL AlwaysOn Availability Groups with vWorkspace 8.5
Deployment and Configuration Guide
71
Figure 126. Backup destination
For the task to be executed on a secondary replica, you MUST select “Copy-Only Backup”! You can also set the
backup expiration.
Figure 127. Backup options
Next, the transaction log backup configuration is similar to the Full Database Backup. Except you don’t need to
configure “Copy-Only Backup”. That’s only require for the full database.
Figure 128. Transaction log backup selection
Implementing MSSQL AlwaysOn Availability Groups with vWorkspace 8.5
Deployment and Configuration Guide
72
Figure 129. Select vWorkspace Database Logs
Select the vWorkspace Database again and then configure the destination to ”Create a sub-directory for each
database”:
Figure 130. Log backup destination
Next configure the options tab to expire the transaction log backup as required. Leave the remainder of the
options at their default.
Implementing MSSQL AlwaysOn Availability Groups with vWorkspace 8.5
Deployment and Configuration Guide
73
Figure 131. Log backup options
Next, configure the cleanup task to remove history as desired. In this example, two weeks is used:
Figure 132. Cleanup history options
Choose if you want a text file report or email notification. In this example, both are turned off:
Figure 133. Report options
The Wizard will show a summary of tasks to be performed to create the maintenance plan.
Implementing MSSQL AlwaysOn Availability Groups with vWorkspace 8.5
Deployment and Configuration Guide
74
Figure 134. Wizard summary
The Wizard will begin creating the Maintenance Plan and display the progress. When completed, the results will
be displayed:
Figure 135. Plan creation process
Figure 136. Plan creation results
Implementing MSSQL AlwaysOn Availability Groups with vWorkspace 8.5
Deployment and Configuration Guide
75
5
5
High Availability testing with Wyse
vWorkspace and Microsoft SQL
AlwaysOn availability groups
About this section
This section is intended to serve as guidance to those wishing to utilize Microsoft SQL Server to achieve greater
vWorkspace database high availability (HA) using SQL AlwaysOn Availability Groups (AG).
Background
In an effort to further support SQL database HA requirements, Dell has conducted testing of the vWorkspace
version 8.5 product as it relates to Microsoft SQL Server AlwaysOn Availability Groups. Every reasonable effort
was made to ensure any issues that may occur during a DB failover have been identified with this testing.
vWorkspace software architects, developers and engineers were involved in the design, setup, testing, analysis
and review.
Testing scenario
The primary vWorkspace database (vWorkspace_Database) is the prime concern for high availability. If the
Reporting Database has been configured, then it should also be included in the Availability Group. For this
testing the Monitoring and Diagnostics database is assumed to be using a local MySQL database and was not
evaluated for high availability since Monitoring and Diagnostics HA is not planned for support until vWorkspace
version 8.6. The virtualization platform should be incidental with respect to SQL AlwaysOn AG. This testing was
conducted on two Microsoft Hyper-V 2012R2 Hyper-V servers. The following vWorkspace components were used
in testing:
Table 1. vWorkspace SQL AlwaysOn lab components
Quantity Machine type
Machine name
Notes
2
Microsoft Enterprise SQL
Server 2014
CWWSQL1
SQL AlwaysOn supports up to eight
nodes. All servers were Windows
Server 2012R2
2
vWorkspace Brokers
CWBRK01 CWBRK02
vWorkspace 8.5 on Microsoft Windows
Server 2012R2
1
vWorkspace Universal Print
Server
CWPRT01
vWorkspace 8.5 on Microsoft Windows
Server 2012R2
1
vWorkspace User Profile
Management Storage Server
CWUPM01
vWorkspace 8.5 on Microsoft Windows
Server 2012R2
2
vWorkspace Web Access
Servers
CWWEB01 CWWEB02
vWorkspace 8.5 on Microsoft Windows
Server 2012R2
CWWSQL2
Implementing MSSQL AlwaysOn Availability Groups with vWorkspace 8.5
Deployment and Configuration Guide
76
Table 1. vWorkspace SQL AlwaysOn lab components
Quantity Machine type
Machine name
Notes
1
vWorkspace Secure Access
Server
CWSSL01 (DMZ – not
domain joined)
vWorkspace 8.5 on Microsoft Windows
Server 2012R2
2
vWorkspace Rapid Provisioned RRDS001 RRDS002
RDSH Server
vWorkspace 8.5 RDSH Rapid
Provisioned from Microsoft Windows
Server 2012R2 Template
Figure 1. Test lab environment
We have not included vWorkspace Monitoring and Diagnostics version 5.7 in this evaluation as it can use its own
internal MySQL database and currently does not support HA. There is no technical reason that if the Monitoring
and Diagnostics database were hosted on the SQL Servers that it too could be easily included in the Availability
Group databases. This will become more important as high availability options for Monitoring and Diagnostics
becomes available in vWorkspace version 8.6 and later.
As vWorkspace Virtual Desktop machines (VDI) heartbeat to the brokers and do not communicate directly with
the SQL Server(s), they were also not included in the HA testing.
To validate Instant Provisioning RDSH servers and their integration with the HA environment, two additional
Instant Provisioned RDSH server were deployed from a Windows Server 2012R2 RDSH Instant Provisioning
Template. The template included the SQL Server Native Client, as well as the SQL Server ODBC Client. The
Broker deploys its own DSN Name, Login ID, and Password to these newly provisioned servers. However, the
resulting RDSH DSN is mis-configured to use the SQL Server Driver instead of the SQL Native Client or the ODBC
Driver 11.
Implementing MSSQL AlwaysOn Availability Groups with vWorkspace 8.5
Deployment and Configuration Guide
77
Figure 2. Test lab RDSH
Therefore, we need to adjust the RDSH servers DSN to use one of the fault-tolerant SQL drivers. The
workaround is to use the ODBC DSN Administrator to review and then delete the existing DSN and create a new
DSN. This workaround requires that you open the vWorkspace console as administrator and update the database
configuration to write the updated SQL Connection String to the registry.
Figure 3. Mis-configured RDSH DSN
Workaround:
On the RDSH server, open Administrative Tools and launch the 32-bit ODBC Data Sources Manager.
Select the System DSN tab and select the vWorkspace DSN. If there is no DSN, then ensure the RDSH server has
initialized within the vWorkspace Farm, as initialization writes these values for the RDSH server. Click
“Configure” to review and document five items before deleting the DSN:
Implementing MSSQL AlwaysOn Availability Groups with vWorkspace 8.5
Deployment and Configuration Guide
78
Figure 4. Review and record DSN data elements
After you document the Instant Provisioned DSN, select it and click “Remove” to delete it.
Next, click “Add” to create a HADR DSN with the same name and data elements but using the SQL Server Native
Client instead of the SQL Server driver. Select the SQL Server Native Client and click “Finish”:
Figure 5. Create new DSN and select SQL native driver
Fill in the DSN Name and Server from the previous DSN. The description is optional. Click “Next”:
Implementing MSSQL AlwaysOn Availability Groups with vWorkspace 8.5
Deployment and Configuration Guide
79
Figure 6. Enter the recorded DSN data elements
Enter the PNAdmin Login ID and Password:
Figure 7. Enter the Login ID and Password
Select the vWorkspace Database and click Multi-subnet failover:
Figure 8. Select the vWorkspace database and select MultiSubnetFailover
Accept the defaults and click “Finish”:
Implementing MSSQL AlwaysOn Availability Groups with vWorkspace 8.5
Deployment and Configuration Guide
80
Figure 9. Accept defaults and click Finish
Test the DSN and check for a a successful connection:
Figure 10. Test connection to ensure successful connectivity
We’ve now updated this DSN with a HADR driver to support availability groups. Click “OK.”
Figure 11. DSN updated to HADR driver
Update the SQL Connection String in the vWorkspace Management Console. Open the Management Console as
“Administrator”. Click File/Database Configuration. Select the DSN in the drop down and add
MultisubnetFailover=Yes in the ODBC Parameters. Click “OK” to write the updated SQL connection string into
the registry.
Implementing MSSQL AlwaysOn Availability Groups with vWorkspace 8.5
Deployment and Configuration Guide
81
Figure 12. Update the SQL connection string in the vWorkspace Management Console
AlwaysOn AG implementation and testing
requirements
SQL AlwaysOn availability group implementation on page 9 provides detailed implementation procedures and
requirements for SQL AlwaysOn Availability Groups. SQL implementation scenarios on page 11 outlines the
general steps to create the foundation for the vWorkspace HA environment.
Planned or manual AG failover
Unlike normal cluster operations, SQL Availability Groups leverage the AG Listener cluster object ownership to
control and manage the primary database replica. During failure of the primary replica node, the Failover
Cluster swaps ownership of the AG Listener to a secondary node and notifies that node of its new role.
Additional SQL configurations and tasks must also be accomplished to actually effect the new primary replica
assuming its new role. This happens automatically in the case of node failure.
But when we want to manually failover the primary role, we should use the dashboard within the SQL
Management Studio to effect the transfer rather than using the Failover Cluster Manager. Any AG replica node
can initiate the SQL AG Failover Wizard.
Figure 13. AlwaysOn Dashboard Start Failover wizard
SQL AG Failover Wizard
Launch the SQL Failover Wizard by clicking the “Start Failover Wizard” link on the AlwaysOn SQL Studio
dashboard.
Implementing MSSQL AlwaysOn Availability Groups with vWorkspace 8.5
Deployment and Configuration Guide
82
The Wizard displays an Introduction dialog:
Figure 14. AG Start Failover wizard introduction
The Wizard displays all secondary replicas where you select the new primary replica:
Figure 15. AG Start Failover wizard Select New Primary
Next, the Wizard needs to connect to the replica node to configure it:
Figure 16. AG Start Failover wizard Connect to Replica Authentication
Authenticate and connect to the replica and click “Next”:
Implementing MSSQL AlwaysOn Availability Groups with vWorkspace 8.5
Deployment and Configuration Guide
83
Figure 17. AG Start Failover wizard, Connect to Replica
The Wizard next displays a summary of the tasks that need to be accomplished on the new primary replica:
Figure 18. AG Start Failover wizard script summary
Click “Finish” and the script executes promoting the new primary replica:
Figure 19. AG Start Failover wizard progress
The results of the failover task is displayed:
Implementing MSSQL AlwaysOn Availability Groups with vWorkspace 8.5
Deployment and Configuration Guide
84
Figure 20. AG Start Failover wizard results
Testing methodology
The general testing methodology to evaluate vWorkspace recovery with SQL Server AlwaysOn Availability Groups
includes:
1
2
3
4
5
Evaluate CWWSQL1 and CWWSQL2 AG node replicas in manual failover test
•
Use SQL Studio AG Dashboard to effect manual failover from Primary to Secondary node
•
Use Sysinternals Process Explorer to view services and their connections
•
Use TCPVIEW to view current connections on each SQL Server node in the AG
•
Time SQL Failover recovery within SQL Studio an Failover Cluster
Evaluate CWWSQL1 and CWWSQL2 AG node replicas in simulated node failure
•
Shutdown Primary node to simulate node failure
•
Use Sysinternals Process Explorer to view services and their connections
•
Use TCPVIEW to view current connections on secondary SQL Server node in the AG
•
Time SQL Failover recovery within SQL Studio an Failover Cluster
•
Time SQ Failover recovery within TCPVIEW
Evaluate CWBRK01 vWorkspace Broker recovery
•
Use SQL Studio AG Dashboard to effect manual failover from Primary to Secondary node
•
Use Sysinternals Process Explorer to view services and their connections
•
Review local TCPVIEW
•
Review SQL TCPVIEW
•
Open console on CWBRK01
Evaluate CWBRK02 vWorkspace Broker recovery
•
Use SQL Studio AG Dashboard to effect manual failover from Primary to Secondary node
•
Use Sysinternals Process Explorer to view services and their connections
•
Review local TCPVIEW
•
Review SQL TCPVIEW
•
Open console on CWBRK02
Evaluate RRDS001 vWorkspace Session Host recovery
Implementing MSSQL AlwaysOn Availability Groups with vWorkspace 8.5
Deployment and Configuration Guide
85
6
7
8
9
•
Use SQL Studio AG Dashboard to effect manual failover from Primary to Secondary node
•
Use Sysinternals Process Explorer to view services and their connections
•
Review local TCPVIEW
•
Review SQL TCPVIEW
•
Open console on RRDS001
Evaluate RRDS002 vWorkspace Session Host recovery
•
Use SQL Studio AG Dashboard to effect manual failover from Primary to Secondary node
•
Use Sysinternals Process Explorer to view services and their connections
•
Review local TCPVIEW
•
Review SQL TCPVIEW
•
Open console on RRDS002
Evaluate CWUPM01 vWorkspace User Profile Storage Server recovery
•
Use SQL Studio AG Dashboard to effect manual failover from Primary to Secondary node
•
Use Sysinternals Process Explorer to view services and their connections
•
Review local TCPVIEW
•
Review SQL TCPVIEW
•
Open console on CWUPM01
Evaluate CWPRT01 vWorkspace Network Universal Print Server recovery
•
Use SQL Studio AG Dashboard to effect manual failover from Primary to Secondary node
•
Use Sysinternals Process Explorer to view services and their connections
•
Review local TCPVIEW
•
Review SQL TCPVIEW
•
Open console on CWPRT01
Evaluate CWWEB01 vWorkspace LAN Web Access Server recovery
•
Use SQL Studio AG Dashboard to effect manual failover from Primary to Secondary node
•
Use Sysinternals Process Explorer to view services and their connections
•
Review local TCPVIEW
•
Review SQL TCPVIEW
•
Connect Client Browser; authenticate; query available application resources
10 Evaluate CWWEB02 vWorkspace LAN WEB Access Server recovery
•
Use SQL Studio AG Dashboard to effect manual failover from Primary to Secondary node
•
Use Sysinternals Process Explorer to view services and their connections
•
Review local TCPVIEW
•
Review SQL TCPVIEW
•
Open console on CWBRK02
11 Evaluate CWSSL01 vWorkspace WAN Secure Access & Web Access Server recovery
•
Use SQL Studio AG Dashboard to effect manual failover from Primary to Secondary node
•
Use Sysinternals Process Explorer to view services and their connections
•
Review local TCPVIEW
•
Review SQL TCPVIEW
Implementing MSSQL AlwaysOn Availability Groups with vWorkspace 8.5
Deployment and Configuration Guide
86
•
Open console on CWBRK02
Evaluate CWWSQL1 and CWWSQL2 AG node replicas in
manual failover test
In this evaluation, we’ll test the manual failover of the Availability Group using the SQL Management Studio
dashboard. All core vWorkspace components will be connected to the SQL AG. The Web Access and Secure
Access will be evaluated later. We’ll check to see how long it takes for the Failover Cluster to transfer
ownership of the AG Listener. CWWSQL2 is our primary replica and we see the vWorkspace components
connected to the vWAG-Listener:
Figure 21. AG primary and secondary replicas
Using the SQL Management Studio, the Availability Group Dashboard was used to Failover the Group.
The Cluster transfers vWAG-Listener ownership between 12 and 13 seconds. The Brokers are first to reconnect
to the new Primary Replica, followed by the RDSH servers. These take between 15 and 45 seconds to reconnect.
The User Profile Management and Universal Print Server are last to connect.
Figure 22. AG secondary and primary replica transfer
The overall environment stabilized within 60 to 90 seconds.
Evaluate CWWSQL1 and CWWSQL2 AG node replicas in
simulated node failure
In this evaluation, we’ll simulate a node failure by shutting down the Primary Replica see the effects on the
Availability Group. The same vWorkspace components will be connected to the SQL AG. The Web Access and
Secure Access will be evaluated later. We’ll check to see how long it takes for the Failover Cluster to transfer
ownership of the AG Listener. CWWSQL1 is our primary replica and we see the vWorkspace components
connected to the vWAG-Listener:
Implementing MSSQL AlwaysOn Availability Groups with vWorkspace 8.5
Deployment and Configuration Guide
87
Figure 23. Simulated failure AG primary and secondary replicas
In this simulated failure mode, the Cluster recognizes the failure and transfer the vWAG-Listener between 20
and 25 seconds. The Brokers are again the first to reconnect but take between 30 and 35 seconds to begin
reconnecting. The User Profile Storage Server and Universal Print Server were next to reconnect between 60
and 70 seconds. The RDSH servers were the last to reconnect between 80 and 90 seconds. The environment has
stabilized within a minute and 45 seconds.
Figure 24. AG primary replica transfer
On recovery of the failed SQL Server (CWWSQL1), it assumes the secondary replica role and initiates a log
synchronization across port 5022, the mirror endpoint. The amount of data transfer is proportional to the length
of time the server is out of service.
Evaluate CWBRK01 and CWBRK02 vWorkspace Broker
recovery
In this evaluation, we’ll test the failover of the Availability Group. We’ll check to see how long it takes for the
Failover Cluster to transfer ownership of the AG Listener and how long it takes CWBRK01 to reconnect to the
vWAG-LISTENER. We see CWBRK01 initially connected to the primary replica on local ports 49653 and 49714.
After failover, CWBRK01 is reconnecting to the vWAG-LISTENER on ports 49775 and 49777:
Implementing MSSQL AlwaysOn Availability Groups with vWorkspace 8.5
Deployment and Configuration Guide
88
Figure 25. AG Primary Replica Transfer for CWBRK01
In a manual transfer, CWBRK01 takes between 15 and 30 seconds to reconnect. In a failure simulation, CWBRK01
takes between 30 and 35 seconds to initiate reconnection.
Two brokers were setup to ensure multiple broker evaluation. CWBRK02 performed similarly to CWBRK01. In
multiple failover tests, sometimes CWBRK02 reconnected first and other times CWBRK01 reconnected first. The
evaluation results were very similar between the two brokers.
Evaluate RRDS001 and RRDS002vWorkspace Session Host
recovery
In this evaluation, we’ll test the failover of the Availability Group. We’ll check to see how long it takes for the
Failover Cluster to transfer ownership of the AG Listener and how long it takes RRDS001 and RRDS002 to
reconnect to the vWAG-LISTENER. We see RRDS001 initially connected to the primary replica on local port 50507
and RRDS002 connected to the primary replica on local port 50493:
Figure 26. AG Primary Replica Transfer for RDSH
After failover, RRDS001 is reconnecting to the vWAG-LISTENER on port 50633 and RRDS002 is reconnecting to the
vWAG-LISTENER on port 50628:
Implementing MSSQL AlwaysOn Availability Groups with vWorkspace 8.5
Deployment and Configuration Guide
89
Figure 27. AG Primary Replica Transfer after failover
In a manual transfer, the RDSH servers take between 30 and 45 seconds to reconnect. In a failure simulation, the
RDSH servers take between 80 and 90 seconds to initiate reconnection.
Evaluate CWUPM01 vWorkspace User Profile Storage Server
and CWPRT01 vWorkspace Network Universal Print Server
recovery
In this evaluation, we’ll test the failover of the Availability Group. We’ll check to see how long it takes for the
Failover Cluster to transfer ownership of the AG Listener and how long it takes CWUPM01 and CWPRT01 to
reconnect to the vWAG-LISTENER. We see CWUPM01 initially connected to the primary replica on local port
49323 and RRDS002 connected to the primary replica on local port 49369:
Figure 28. AG Primary Replica Transfer for CWUPM01 and CWPRT01
After failover, CWUPM01 is reconnecting to the vWAG-LISTENER on port 49327 and RRDS002 is reconnecting to
the vWAG-LISTENER on port 49371:
Figure 29. AG Primary Replica Transfer for CWUPM01 and CWPRT01 after Failover
Recovery of these two components are very similar. In a manual transfer, the CWUPM01 and CWPRT01 servers
take between 45 and 60 seconds to reconnect. In a failure simulation, the CWUPM01 and CWPRT01 servers take
between 60 and 70 seconds to initiate re-connections.
Implementing MSSQL AlwaysOn Availability Groups with vWorkspace 8.5
Deployment and Configuration Guide
90
Evaluate CWWEB01 and CWWEB02 vWorkspace LAN Web
Access Server recovery
In this evaluation, we’ll test the failover of the Availability Group. We’ll check to see how long it takes for the
Failover Cluster to transfer ownership of the AG Listener and how CWWEB01 and CWWEB02 are affected by the
failover. We connected a client browser to CWWEB01 and CWWEB02. Their behavior was similar. If you
attempted authentication during the failover, the client received a Broker Communication Error Message. As
soon as the Broker failover, the client browser authenticated and received their published applications.
CWWEB02 had similar behavior.
Figure 30. CWWEB01 failover evaluation
The webconfig.xml was pushed from CWBRK01 immediately after failover from a relaunched vWorkspace
Management console and it worked successfully. You can see the connection on local TCP port 50171 above.
Once authenticated, the Web Client launched the published application successfully.
The Web Portal outage was consistent with the failover of the broker. These take between 15 and 45 seconds to
be able to connect to a recovers Broker in manual failover; and between 30 and 35 seconds in a simulated
failure recovery.
Figure 31. CWWEB01 failover evaluation
Evaluate CWSSL01 vWorkspace WAN Secure Access & Web
Access Server recovery
In this evaluation, we’ll test the failover of the Availability Group. We’ll check to see how long it takes for the
Failover Cluster to transfer ownership of the AG Listener and how CWSSL01 are affected by the failover. We
Implementing MSSQL AlwaysOn Availability Groups with vWorkspace 8.5
Deployment and Configuration Guide
91
connected a client browser to CWSSL01, which has a Federated Site configured with both a Native Connector
Site and a HTML5 Site configured. CWSSL01’s behavior was similar to the LAN Portals. If you attempted
authentication during the failover, the client hourglasses trying to connect to the recovering Brokers. Once
recovered, the browser authentication page displayed. The client browser authenticated and received their
published applications.
Figure 32. CWSSL01 failover evaluation
Figure 33. CWSSL01 failover evaluation
Figure 34. CWSSL01 failover evaluation
Implementing MSSQL AlwaysOn Availability Groups with vWorkspace 8.5
Deployment and Configuration Guide
92
6
6
Summary
By using AlwaysOn Availability Groups to host the Wyse vWorkspace configuration and reporting databases, an
availability groups solution with multiple secondary nodes can replace the legacy mirroring solution that uses
database mirroring and log shipping, to provide greater levels of fault tolerance and redundancy.
High Availability testing with Wyse vWorkspace and Microsoft SQL AlwaysOn availability groups on page 76
evaluated the major components of vWorkspace and found excellent recoverability of all components.
Implementing MSSQL AlwaysOn Availability Groups with vWorkspace 8.5
Deployment and Configuration Guide
93
Dell listens to customers and delivers worldwide innovative technology, business solutions
and services they trust and value. For more information, visit www.software.dell.com.
Contacting Dell
Technical support:
Online support
Product questions and sales:
(800) 306-9329
Email:
[email protected]
Technical support resources
Technical support is available to customers who have purchased Dell software with a
valid maintenance contract and to customers who have trial versions. To access the
Support Portal, go to http://software.dell.com/support/.
The Support Portal provides self-help tools you can use to solve problems quickly and
independently, 24 hours a day, 365 days a year. In addition, the portal provides direct
access to product support engineers through an online Service Request system.
The site enables you to:
•
Create, update, and manage Service Requests (cases)
•
View Knowledge Base articles
•
Obtain product notifications
•
Download software. For trial software, go to Trial Downloads.
•
View how-to videos
•
Engage in community discussions
•
Chat with a support engineer