Netherlands: Software

Introductie van Micorosoft SQL Server 2016

Issue link:

Contents of this Issue


Page 57 of 212

46 C H A P T E R 3 | Higher availability 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 in "Site-aware Failover Clusters in Windows Server 2016" at 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 comma- separated 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 in "Windows Server 2016 Failover Cluster Troubleshooting Enhancements – Cluster Log" at 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.

Articles in this issue

Links on this page

Archives of this issue

view archives of Netherlands: Software - Introductie van Micorosoft SQL Server 2016