Introducing
Microsoft SQL Server 2016
Preview Edition
Higher availability
Stacia Varga, Denny Cherry, Joseph D’Antoni
This is a pre-release chapter of a forthcoming ebook entitled Microsoft
SQL Server 2016: Mission-Critical Applications, Deeper Insights,
Hyperscale Cloud. Please enjoy this chapter and watch for the release of
the full ebook at a later time.
PUBLISHED BY
Microsoft Press
A division of Microsoft Corporation
One Microsoft Way
Redmond, Washington 98052-6399
Copyright © 2016 by Microsoft Corporation
All rights reserved. No part of the contents of this book may be reproduced or transmitted in any
form or by any means without the written permission of the publisher.
ISBN: 978-1-5093-0193-5
Printed and bound in the United States of America.
First Printing
Microsoft Press books are available through booksellers and distributors worldwide. If you need
support related to this book, email Microsoft Press Support at mspinput@microsoft.com. Please tell us
what you think of this book at http://aka.ms/tellpress.
This book is provided “as-is” and expresses the author’s views and opinions. The views, opinions and
information expressed in this book, including URL and other Internet website references, may change
without notice.
Some examples depicted herein are provided for illustration only and are fictitious. No real association
or connection is intended or should be inferred.
Microsoft and the trademarks listed at http://www.microsoft.com on the “Trademarks” webpage are
trademarks of the Microsoft group of companies. All other marks are property of their respective
owners.
Acquisitions and Developmental Editor: Devon Musgrave
Project Editor: John Pierce
Editorial Production: Flyingspress
Cover: Twist Creative • Seattle
Contents
Higher availability ........................................................................................................................................................................ 1
AlwaysOn Availability Groups............................................................................................................................................. 1
Supporting disaster recovery with basic availability groups ............................................................................. 2
Using group Managed Service Accounts .................................................................................................................. 4
Triggering failover at the database level ................................................................................................................... 4
Supporting distributed transactions ........................................................................................................................... 5
Scaling out read workloads ............................................................................................................................................ 6
Defining automatic failover targets ............................................................................................................................. 7
Reviewing the improved log transport performance ........................................................................................... 8
Windows Server 2016 Technical Preview high-availability enhancements ...................................................... 9
Creating workgroup clusters ....................................................................................................................................... 10
Configuring a cloud witness ........................................................................................................................................ 11
Using Storage Spaces Direct ....................................................................................................................................... 13
Introducing site-aware failover clusters.................................................................................................................. 14
Windows Server Failover Cluster logging .............................................................................................................. 14
Performing rolling cluster operating system upgrades .................................................................................... 14
About the authors ................................................................................................................................ 16
In a world that is always online, maintaining uptime and streamlining
maintenance operations for your mission-critical applications are more
important than ever. In SQL Server 2016, the capabilities of the AlwaysOn
Availability Group feature continue to evolve from previous versions,
enabling you to protect data more easily and flexibly and with greater
throughput to support modern storage systems and CPUs. Furthermore,
AlwaysOn Availability Groups and AlwaysOn Failover Cluster Instances now
have higher security, reliability, and scalability. By running SQL Server 2016
on Windows Server 2016, you have more options for better managing
clusters and storage. In this chapter, we introduce the new features that
you can use to deploy more robust high-availability solutions.
AlwaysOn Availability Groups
First introduced in SQL Server 2012 Enterprise Edition, the AlwaysOn Availability Groups feature
provides data protection by sending transactions from the transaction log on the primary replica to
one or more secondary replicas, a process that is conceptually similar to database mirroring. In SQL
Server 2014, the significant enhancement to availability groups was the increase in the number of
supported secondary replicas from three to eight. SQL Server 2016 includes a number of new
enhancements that we explain in this section:

AlwaysOn Basic Availability Groups

Support for group Managed Service Accounts (gMSAs)

Database-level failover

Distributed Transaction Coordinator (DTC) support

Load balancing for readable secondary replicas

Up to three automatic failover targets

Improved log transport performance
1
Higher availability | Return to Contents
New to availability groups?
If you are still using database mirroring, there are several reasons to transition your high-availability
strategy to availability groups. Database mirroring is deprecated as of SQL Server 2012, for
example, and basic availability groups are now included in SQL Server 2016 Standard Edition as a
replacement. Also, if you are exploring options for high-availability/disaster-recovery (HA/DR)
solutions but have never implemented availability groups, SQL Server 2016 provides several
benefits to consider.
Whereas database mirroring occurs at the database level, using a single thread to perform the data
replication, data is moved within availability groups by using a worker pool, which provides better
throughput and reduces CPU overhead. When your application requires multiple databases, you
can assign the databases to a single availability group to ensure that they all fail over at the same
time. By contrast, the unit of failover with database mirroring is a single database. With database
mirroring, you use a SQL Server witness instance to manage automatic failover, but with availability
groups you rely on Windows Server Failover Clustering (WSFC) to arbitrate uptime and connections.
Furthermore, clustering is a more robust solution than database mirroring because it provides
additional levels of protection.
A key benefit of availability groups is the ability to scale out replicas that you can configure to
support both high-availability and disaster-recovery requirements. For high-availability scenarios,
you should locate two or three servers in the same geographic location, configured to use
synchronous-commit mode and automatic failover. That said, automatic failover should be used
only in low-latency scenarios because writes to the primary replica are not considered complete
until they reach the transaction log on the secondary replica. For disaster-recovery scenarios in
which the servers are more than 100 kilometers apart, asynchronous-commit mode is a better
choice to minimize the performance impact on the primary replica.
Another benefit of availability groups is the ability for databases on a secondary replica to support
online reads as well as database backups. This capability allows you to implement a scale-out
architecture for reporting solutions by having multiple copies of secondary replicas in multiple
geographies. You provide connectivity to the availability group by using a virtual IP address called
the listener, which you configure to connect transparently to the primary replica or to a secondary
replica for reading. Figure 3-1 is a diagram of an availability group with replicas in New York, Los
Angeles, and Seattle and a listener to which clients connect.
Figure 3-1: An AlwaysOn Availability Group with a primary replica and two secondary replicas.
Supporting disaster recovery with basic availability groups
You can now use basic availability groups in the Standard Edition to automatically fail over a single
database. The use of basic availability groups is subject to the following limitations:

2
Two replicas (one primary and one secondary)
Higher availability | Return to Contents

One availability database

No read access on secondary replica

No backups on secondary replica

No availability group listener

No support in an existing availability group to add or remove a replica

No support for upgrading a basic availability group to an advanced availability group
Despite these limitations, with a basic availability group you get benefits similar to database mirroring
in addition to other features. For each replica, you can choose either synchronous-commit or
asynchronous-commit mode, which determines whether the primary replica waits for the secondary
replica to confirm that it has hardened the log. Moreover, performance is better because basic
availability groups use the same improved log transport operations that we describe later in this
chapter.
The steps to configure basic availability groups are similar to those for regular availability groups, with
some exceptions. You start by using the New Availability Group Wizard, which you launch in SQL
Server Management Studio (SSMS) by right-clicking the AlwaysOn High Availability folder in Object
Explorer. When you reach the Specify Replicas page, you click the Add Replica button to add the
primary and secondary replicas, but then the button becomes unavailable, as shown in Figure 3-2. In
addition, you cannot change the value for the Readable Secondary drop-down list, nor can you access
the Backup Preferences or Listener tabs.
Figure 3-2: Configuring replicas for a basic availability group.
3
Higher availability | Return to Contents
Note Although including an Azure replica in your disaster-recovery architecture is fully supported
for basic availability groups, the New Availability Group Wizard does not allow you the option to
add it. However, you can perform this step separately by using the Add Azure Replica Wizard, which
is described at https://msdn.microsoft.com/en-us/library/dn463980.aspx.
Using group Managed Service Accounts
To comply with regulatory auditing requirements, DBAs or system administrators in a large enterprise
must frequently reset service account passwords across SQL Server instances. However, managing
individual service account passwords involves a high degree of risk because downtime is likely to
occur if anything goes wrong. To address this problem, Microsoft enhanced Windows Server 2012 so
that you can more easily manage passwords for a service account in Active Directory by creating a
single service account for your SQL Server instances and then delegating permissions to each of those
servers. By default, Active Directory changes the password for a group Managed Service Account
(gMSA) every thirty days, although you can adjust the password-change interval to satisfy your audit
requirements.
In SQL Server 2012 and SQL Server 2014, you can implement this feature only in standalone
configurations. In SQL Server 2016, you can now use gMSAs with both availability groups and failover
clusters. If you are using Windows Server 2012 R2 as your operating system, you must install
KB298082 to ensure that services can seamlessly log on after a password change. However, no
patches are required if you install SQL Server 2016 on Windows Server 2016.
Triggering failover at the database level
Beginning in SQL Server 2012, AlwaysOn Availability Groups and AlwaysOn Failover Cluster Instances
(FCIs) use the sp_server_diagnostics stored procedure to periodically monitor the health of a server.
The default behavior is to fail over an availability group or an FCI when the health monitoring reveals
any of the following conditions:

The stored procedure returns an error condition.

The SQL Service service is not running.

The SQL Server instance is not responding.
However, in versions earlier than SQL Server 2016, this check does not account for database-level
failures. Beginning in SQL Server 2016, you can enable Database Level Health Detection when you
create an availability group, as shown in Figure 3-3. This way, any error that causes a database to be
suspect or go offline also triggers a failover of the availability group.
Note The FailureConditionLevel property determines the conditions that trigger a failover. For
normal operations, the default value is suitable. However, you can reduce or increase this property’s
value if necessary. To learn more, see “Configure FailureConditionLevel Property Settings” at
https://msdn.microsoft.com/en-us/library/ff878667.aspx.
4
Higher availability | Return to Contents
Figure 3-3: Creating a new availability group with database-level health detection.
Note Enabling Database Level Health Detection needs to be weighed carefully with the needs of
your application and its intended behavior in response to a failover. If your application can support
a database failover, Database Level Health Detection can enhance your total availability and uptime.
Automatic page repair
An important capability of availability groups is automatic page repair. If the primary replica cannot
read a page, it requests a fresh copy of the page from a secondary. However, in the event that the
primary replica cannot be repaired, such as when storage fails completely, you might be able to
bring your secondary replica online as a primary replica.
Supporting distributed transactions
One of the features long supported in FCIs, but not in availability groups, is the use of the Distributed
Transaction Coordinator (DTC). This feature is required if your application performs transactions that
must be consistent across multiple instances. When running SQL Server 2016 on Windows Server
2016, you can now implement support for distributed transactions when you create a new availability
group. To do this, you select the Per Database DTC check box (shown earlier in Figure 3-3) or by using
the T-SQL command shown in Example 3-1. Note that you cannot add DTC support to an existing
5
Higher availability | Return to Contents
availability group. By enabling DTC support, your application can distribute transactions between
separate SQL Server instances or between SQL Server and another DTC-compliant server, such as
Oracle or WebSphere.
Example 3-1: Creating an availability group with DTC support
CREATE AVAILABLITY GROUP [2016DEMO] WITH DTC_SUPPORT=PER_DB
Note Because each database in an availability group is synchronized independently while the
cross-database transaction manager operates at the SQL Server instance level, an active crossdatabase transaction might be lost during an availability group failover. Consequently, crossdatabase transactions are not supported for databases hosted by one SQL Server or within the
same availability group.
Scaling out read workloads
You can use availability groups for scale-out reads across multiple secondary copies of the availability
group. In SQL Server 2016, as in the previous version, you can scale up to as many as eight secondary
replicas, but the scale-out reads feature is not enabled by default. To support scale-out reads, you
must configure read-only routing by using the T-SQL commands shown in Example 3-2. You must
also create an availability group listener and direct connections to this listener. In addition, the
connection string must include the ApplicationIntent=ReadOnly keyword.
Example 3-2: Configuring read-only routing
ALTER AVAILABILITY GROUP [AG1]
MODIFY REPLICA ON
N'COMPUTER01' WITH
(SECONDARY_ROLE (ALLOW_CONNECTIONS = READ_ONLY));
ALTER AVAILABILITY GROUP [AG1]
MODIFY REPLICA ON
N'COMPUTER01' WITH
(SECONDARY_ROLE (READ_ONLY_ROUTING_URL = N'TCP://COMPUTER01.contoso.com:1433'));
ALTER AVAILABILITY GROUP [AG1]
MODIFY REPLICA ON
N'COMPUTER02' WITH
(SECONDARY_ROLE (ALLOW_CONNECTIONS = READ_ONLY));
ALTER AVAILABILITY GROUP [AG1]
MODIFY REPLICA ON
N'COMPUTER02' WITH
(SECONDARY_ROLE (READ_ONLY_ROUTING_URL = N'TCP://COMPUTER02.contoso.com:1433'));
ALTER AVAILABILITY GROUP [AG1]
MODIFY REPLICA ON
N'COMPUTER01' WITH
(PRIMARY_ROLE (READ_ONLY_ROUTING_LIST=('COMPUTER02','COMPUTER01')));
ALTER AVAILABILITY GROUP [AG1]
MODIFY REPLICA ON
N'COMPUTER02' WITH
(PRIMARY_ROLE (READ_ONLY_ROUTING_LIST=('COMPUTER01','COMPUTER02')));
GO
6
Higher availability | Return to Contents
Note You can also use Windows PowerShell to configure a read-only routing list as described at
https://msdn.microsoft.com/en-us/library/hh710054.aspx.
In SQL Server 2012 and SQL Server 2014, the read traffic is directed to the first available replica,
without consideration for load balancing. An alternative solution requires the use of third-party
hardware or software load balancers to route traffic equally across the secondary copies of the
databases. In SQL Server 2016, you can now balance loads across replicas by using nested
parentheses in the read-only routing list, as shown in Example 3-3. In this example, connection
requests first try the load-balanced set containing Server1 and Server2. If neither replica in that set is
available, the request continues by sequentially trying other replicas defined in the list, Server3 and
Server4 in this example. Only one level of nested parentheses is supported at this time.
Example 3-3: Defining a load-balanced replica list
READ_ONLY_ROUTING_LIST = (('Server1','Server2'), 'Server3', 'Server4')
Defining automatic failover targets
In SQL Server 2012 and SQL Server 2014, you can define a maximum of two replicas running in an
automatic failover set, but now SQL Server 2016 allows for a third replica to support a topology such
as is shown in Figure 3-4. In this example, the replicas on Node01, Node02, and Node03 are
configured as an automatic failover set. As long as data is synchronized between the primary replica
and one of the secondary replicas, failover can take place in an automatic fashion with no data loss.
Figure 3-4: Availability Group topology with three automatic failover targets.
When configuring availability group failover, you can choose from among the following failover
modes:

Automatic Failover A failover that occurs automatically on the failure of the primary replica,
which is supported only when both the primary replica and at least one secondary replica are
configured with AUTOMATIC failover mode and the secondary replica is currently synchronized.

Planned Manual Failover (without data loss) A failover that is typically initiated by an
administrator for maintenance purposes. This requires synchronous-commit mode, and the
databases must currently be synchronized.
7
Higher availability | Return to Contents

Forced Failover (with possible data loss) A failover that occurs when the availability group is
configured with asynchronous-commit mode, or the databases in the availability group are not
currently synchronized.
For automatic failover to work, you must configure all members of the availability group for
synchronous-commit mode and for automatic failover. You typically configure automatic failover for
high-availability scenarios, such as rolling updates to SQL Server. In this configuration, any
uncommitted transactions that have not reached the secondary replica are rolled back in the event of
failover, thereby providing near zero data loss.
Reviewing the improved log transport performance
When AlwaysOn Availability Groups were first introduced in SQL Server 2012, solid-state storage
devices (SSDs) were far less prevalent in enterprise IT architectures than they are now. SSDs enable
more throughput, which can be problematic on a standalone system and can overwhelm the ability to
write to the secondary database. In prior versions of SQL Server, the underlying processes responsible
for synchronizing data between replicas are shared among availability groups, database mirroring,
Service Broker, and replication. In SQL Server 2016, these processes are completely rewritten, resulting
in a streamlined protocol with better throughput and lower CPU utilization.
Although the process has been refactored, the sequence of internal operations for the log transport,
shown in Figure 3-5, continues to include the following steps:
1.
Log flush Log data is generated and flushed to disk on the primary replica in preparation
for replication to the secondary replica. It then enters the send queue.
2.
Log capture Logs for each database are captured on the primary replica, compressed, and sent
to the corresponding queue on the secondary replica. This process runs continuously as long as
database replicas are connecting. If this process is not able to scan and enqueue the messages
quickly enough, the log send queue continues to grow.
3.
Send The messages are removed from the queue and sent to each secondary replica across the
network.
4. Log receive/Log cache Each secondary replica gets messages from the primary replica and
then caches the messages.
5.
Log hardened The log is flushed on the secondary replica, and then a notification is sent to the
primary replica to acknowledge completion of the transaction.
6.
Redo pages
replica.
8
The flushed pages are retrieved from the redo queue and applied to the secondary
Higher availability | Return to Contents
Figure 3-5: Log transport operations for AlwaysOn Availability Groups.
Bottlenecks can occur in this process during the log-capture step on the primary replica and the redo
step on the secondary replica. In previous versions of SQL Server, both steps were single-threaded.
Consequently, bottlenecks might occur during large index rebuilds on availability groups with highspeed storage and on local networks, because these single-threaded steps had trouble keeping up
with the stream of log records. However, in SQL Server 2016 these steps can use multiple threads that
run in parallel, resulting in significant performance improvements. Furthermore, the compression
functions in the log-capture step have been replaced by a newer Windows compression function that
delivers up to five times better performance. During testing with high-throughput storage devices,
speeds up to 500 MB/s have been observed. Considering that this throughput is a compressed
stream, the redo step is receiving 1 GB/s, which should support the busiest applications on the fastest
storage.
Microsoft Azure high-availability/disaster-recovery licensing changes
Hybrid disaster-recovery scenarios are becoming increasingly popular. If you choose to implement
hybrid disaster recovery, be sure to maintain symmetry between on-premises and cloud solutions.
The license mobility benefit included with software assurance (SA) allows you to use a secondary
copy of SQL Server in any high-availability or disaster-recovery scenario without purchasing another
license for it. In the past, you could not use this benefit with the SQL Server images on Azure Virtual
Machines. Now you can deploy a new SQL Server image on an Azure Virtual Machine without
incurring charges as long as the secondary replica is not active. This means you can automate the
scale-out of your high-availability/disaster-recovery solutions with a minimum of effort and cost.
Windows Server 2016 Technical Preview highavailability enhancements
Nearly every version of Windows Server since Windows Server 2008 R2 has had major enhancements
to the operating system’s failover clustering stack as a result of development investments in related
technologies. First, Hyper-V, the virtualization platform in the operating system, uses the clustering
stack for its high-availability and disaster-recovery scenarios. Microsoft Azure also uses this same
functionality. Because SQL Server has failover clustering at the center of its high-availability/disasterrecovery technologies, it also takes advantage of the clustering features in the operating system.
Sometimes these features are visible from the database tier, allowing you to make configuration
9
Higher availability | Return to Contents
changes, but other features from the operating system, such as dynamic quorum, enhance SQL
Server’s uptime without requiring configuration. Windows Server 2016 Server Technical Preview
includes the following features that enhance SQL Server’s uptime:

Workgroup clusters

Cloud witness

Storage Spaces Direct

Site-awareness

Troubleshooting enhancements to Windows Server Failover Clusters (WSFC)

Cluster operating system rolling upgrade
Creating workgroup clusters
Earlier in this chapter, we explained how basic availability groups replace nearly all the functionality in
database mirroring. The one advantage that database mirroring has over availability groups in prior
versions of SQL Server is the ability to provide data protection across Active Directory (AD) domains or
without an AD domain. Starting with Windows Server 2016 Technical Preview and SQL Server 2016,
you can now create a workgroup cluster with nondomain servers as well as servers attached to
different AD domains. However, there is no mechanism for using a file share witness. Instead, you
must create a cloud witness, as we describe in the next section, or a shared disk.
Each server that you want to add to a workgroup cluster requires a primary DNS suffix in the full
computer name, as shown in Figure 3-6. You can add this suffix by clicking the More button in the
Computer Name/Domain Changes dialog box, which you access from System Properties for the
server.
10
Higher availability | Return to Contents
Figure 3-6: A server with a DNS suffix assigned to a workgroup.
Note In the current release of Windows Server 2016 Technical Preview, this feature is enabled by
default. However, you must use PowerShell to create a workgroup cluster because the Failover
Cluster Manager snap-in does not support this functionality. Furthermore, configuring a crossdomain cluster is more complex than configuring a workgroup cluster because Kerberos is required
to make cross-domain authentication work correctly. You can learn more about configuration
requirements for both scenarios by referring to “Workgroup and Multi-domain clusters in Windows
Server 2016” at http://blogs.msdn.com/b/clustering/archive/2015/08/17/10635825.aspx.
Configuring a cloud witness
Maintaining quorum is the most important function of any clustering software. In SQL Server, the
most frequently deployed model is Node And File Share Majority. One of the challenges when you are
designing a disaster-recovery architecture is to decide where to place the file share witness.
Microsoft’s official recommendation is to place it in a third data center, assuming you have a
primary/secondary availability group configuration. Many organizations already have two data
centers, but fewer have a third data center. Windows Server 2016 Technical Preview introduces a new
feature, the cloud witness, that address this problem.
You create a cloud witness by using the Cluster Quorum Wizard. Before you launch this wizard, you
must have an active Azure subscription and a storage account. To launch the wizard, right-click the
server in the Failover Cluster Manager, point to More Actions, select Configure Cluster Quorum
Settings, select the Select The Quorum Witness option, and then select the Configure A Cloud Witness
option, as shown in Figure 3-7.
Figure 3-7: Creating a cloud witness for a cluster quorum.
11
Higher availability | Return to Contents
On the next page of the wizard, provide the name of your Azure storage account, copy the storage
account key from the Azure portal to the clipboard, and type the Azure service endpoint, as shown in
Figure 3-8.
Figure 3-8: Addition of Azure credentials to cloud witness configuration.
When you successfully complete the wizard, the cloud witness is displayed in the Cluster Core
Resources pane in the Failover Configuration Manager snap-in, as shown in Figure 3-9.
Figure 3-9: Successful addition of a cloud witness to cluster core resources.
Because you select the Azure region when you create a storage account, you have control over the
placement of your cloud witness. All communications to and from Azure storage are encrypted by
default. This new feature is suitable for most disaster-recovery architectures and is easy to configure
at minimal costs.
12
Higher availability | Return to Contents
Note More information on this topic is available in “Understanding Quorum Configurations in a
Failover Cluster” at https://technet.microsoft.com/en-us/library/cc731739.aspx.
Using Storage Spaces Direct
Windows Server 2016 Technical Preview introduces the Storage Spaces Direct feature, which
seamlessly integrates several existing Windows Server features to build a software-defined storage
stack, as shown in Figure 3-10. These features include Scale-Out File Server, Clustered Shared Volume
File Systems (CSVFS), and Failover Clustering.
Figure 3-10: Storage options in Storage Spaces Direct.
The main use case for this feature is high-performance primary storage for Hyper-V virtual files.
Additionally, storage tiers are built into the solution. If you require a higher tier of performance for
TempDB volumes, you can configure Storage Spaces Direct accordingly. SQL Server can take full
advantage of this feature set because the infrastructure supports AlwaysOn Availability Groups and
AlwaysOn Failover Cluster Instances, thereby providing a much lower total cost of ownership
compared with traditional enterprise storage solutions.
Note See “Storage Spaces Direct in Windows Server 2016 Technical Preview” at
https://technet.microsoft.com/en-us/library/mt126109.aspx to learn more.
13
Higher availability | Return to Contents
Introducing site-aware failover clusters
Windows Server 2016 Technical Preview also introduces site-aware clusters. As a consequence, you
can now group nodes in stretched clusters based on their physical location. This capability enhances
key clustering operations such as failover behavior, placement policies, heartbeat between nodes, and
quorum behavior.
One of the key features of interest to SQL Server professionals is failover affinity, which allows
availability groups to fail over within the same site before failing to a node in a different site.
Additionally, you can now configure the threshold and site delay for heartbeating, which is the
network ping that ensures the cluster can talk to all its nodes.
You can not only specify a site for a cluster node, you can also define a primary location, known as a
preferred site, for your cluster. Dynamic quorum ensures that the preferred site stays online in the
event of a failure by lowering the weights of the disaster-recovery site.
Note Currently (in Windows Server 2016 TP4), the site-awareness functionality is only enabled
through PowerShell and not through Failover Cluster Manager. More information is available at
“Site-aware Failover Clusters in Windows Server 2016” at http://blogs.msdn.com/b/clustering
/archive/2015/08/19/10636304.aspx.
Windows Server Failover Cluster logging
Troubleshooting complex cluster problems has always been challenging. One of the goals of WSFC
logging in Windows Server 2016 is to simplify some of these challenges. First, the top of the cluster
log now shows the UTC offset of the server and notes whether the cluster is using UTC or local time.
The cluster log also dumps all cluster objects, such as networks, storage, or roles, into a commaseparated list with headers for easy review in tools such as Excel. In addition, there is a new logging
model call DiagnosticVerbose that offers the ability to keep recent logs in verbose logging while
maintaining a history in normal diagnostic mode. This compromise saves space but also provides
verbose logging as needed.
Note Additional information is available at “Windows Server 2016 Failover Cluster Troubleshooting
Enhancements – Cluster Log” at http://blogs.msdn.com/b/clustering/archive/2015/05/15/
10614930.aspx.
Performing rolling cluster operating system upgrades
In prior versions of SQL Server, if your SQL Server instance was running in any type of clustered
environment and an operating system upgrade was required, you built a new cluster on the new
operating system and then migrated the storage to the new cluster. Some DBAs use log shipping to
bring the downtime to an absolute minimum, but this approach is complex and, more importantly,
requires a second set of hardware. With rolling cluster operating system upgrades in Windows Server
2016, the process is more straightforward.
Specifically, SQL Server requires approximately five minutes of downtime in the rolling upgrade
scenario illustrated in Figure 3-11. In general, the process drains one node at a time from the cluster,
performs a clean install of Windows Server 2016, and then adds the node back into the cluster. Until
the cluster functional level is raised in the final step of the upgrade process, you can continue to add
new cluster nodes with Windows Server 2012 R2 and roll back the entire cluster to Windows Server
2012 R2.
14
Higher availability | Return to Contents
Figure 3-11: State transitions during a rolling operating system upgrade.
Note You use Failover Cluster Manager and PowerShell to manage the cluster upgrade. See
“Cluster Operating System Rolling Upgrade” at https://technet.microsoft.com/en-us/library
/dn850430.aspx to learn more.
15
Higher availability | Return to Contents
Stacia Varga is a consultant, educator, mentor, and writer who has specialized in businessintelligence solutions since 1999. During that time she authored or coauthored several books about BI
as Stacia Misner. Her last book was Introducing Microsoft SQL Server 2014 (Microsoft Press, 2014). She
has also written articles for SQL Server Magazine and Technet and has produced multiple BI video
courses available through Pluralsight. In addition, she has been recognized for her contributions to
the technical community as a Microsoft Data Platform MVP since 2011. Stacia provides consulting and
custom education services through her company, Data Inspirations; speaks frequently at conferences
serving the SQL Server community worldwide; and serves as the chapter leader of her local PASS user
group, SQL Server Society of Las Vegas. She holds a BA in social sciences from Washington State
University. Stacia writes about her experiences with BI at blog.datainspirations.com and tweets as
@_StaciaV_.
Joseph D'Antoni is a principal consultant for Denny Cherry and Associates Consulting. He is well
versed in SQL Server performance tuning and database infrastructure design, with more than a
decade of experience working in both Fortune 500 and smaller firms. Joseph is a frequent speaker at
major technical events worldwide. In addition, he blogs about a variety of technology topics at
joeydantoni.com and tweets as @jdanton. Joseph holds a BS in computer information systems from
Louisiana Tech and an MBA from North Carolina State University.
Denny Cherry is the owner, founder, and principal consultant for Denny Cherry and Associates
Consulting. His primary areas of focus are system architecture, performance tuning, and data
replication. Denny has been recognized in the technical community as a Microsoft Data Platform MVP,
VMware vExpert, and EMC Elect. He holds certifications for SQL Server from the MCDBA for SQL
Server 2000 up through Microsoft Certified Master for SQL Server 2008. He is also a Microsoft
Certified Trainer. Denny has written dozens of articles for SQL Server Magazine, Technet, and
SearchSQLServer.com, among others. In addition, he has authored and coauthored multiple books,
including The Basics of Digital Privacy: Simple Tools to Protect Your Personal Information and Your
Identity Online (Syngress, 2013) and Securing SQL Server: Protecting Your Database from Attackers, 2nd
Edition (Syngress, 2012). Denny speaks at events worldwide, blogs at www.dcac.co/blogs, and tweets
as @mrdenny.