In this article, we look at Clustering in SQL Server in context of AlwaysOn Availability Groups and how both of them play together.
Clustering in SQL Server refers to installing multiple instances of SQL Server in Windows Server Failover Cluster. Windows Server Failover Cluster often makes use of shared storage mainly in the form of SAN. If the cluster contains a SQL Server instance, then the user databases and the systems will also have to be on the shared storage. This will enable the cluster to use any given server within the cluster to freely move the SQL Server instance anywhere, thus making the instance available across all servers in the cluster. This is the main purpose behind a failover cluster, to give you access to all the data from a particular SQL Server instance, available at a single spot, which is accessible from different servers.
The Availability Groups feature in SQL Server is a feature that requires Failover Clustering and provides scale-out read functionality. This feature of Availability Groups was first introduced in the 2012 edition of SQL Server, and to make use of this feature, you will first have to activate Failover Clustering in Windows. For those who are still using the 2008 or earlier edition of Windows Server, will find the feature in Datacenter or Enterprise Edition of the same. Hence they will have to pay to make use of this feature. Thankfully, for those with the 2012 or later edition of Windows Server, will find it pre-installed.
Failover Cluster in Availability Group
It is important to note that, even if you do enable the Failover Clustering feature for SQL Server instance, you do not necessarily require shared storage for using Availability Groups. You can make use of ‘Failover Cluster in Availability Group’ option, or use independent sub storage systems for running your Availability Groups. This feature is essential because, Availability Groups always make use of parts of Failover Clustering feature for managing a virtual network name and associated IP Address.
Availability Groups do not necessarily depend on Failover Clustering instances; you can make use of the failover clustering for hosting an availability replica for the associated availability group. However, Availability Groups depend on failover clusters for managing the roles of all availability replicas, belonging to different Availability Groups, and determining how are these replicas affected by a failover. There exists a Windows Failover Cluster resource group for all Availability Groups created by you. This resource group is monitored by the Windows Server Failover Cluster for determining the health of the primary replica.
Availability Groups were primarily introduced for increasing database availability and as a disaster recovery option. Combining AlwaysOn Availability Group with Clustering in SQL Server makes the feature even better and more useful. With the help of this combination we can access our databases and all the related information from any server, in any other server. If necessary, you can make use of failover clustering instance for the purpose of storing an availability replica from either of the Availability groups.
Hardware Failure or an Operating System Failure on a Node of Failover Cluster can Cause a Potential Data Loss Scenario
Incidents of hardware failure or OS failure can occur out of the blue. In some cases there may be a Quorum failure which has the potential of causing data loss. In such cases you should immediately call in a mdf recovery tool like DataNumen SQL Recovery to extract the records from the crashed file. This powerful tool can extract every possible data type, with exception to XML, stored in the SQL file within a short span of time while maintaining complete data integrity.
Alan Chen is President & Chairman of DataNumen, Inc., which is the world leader in data recovery technologies, including access recovery and sql recovery software products. For more information visit www.datanumen.com