With SQL Server 2012 AlwaysOn your solution does not have to utilise shared storage, but can use SAN, DAS, NAS or Local Disk depending on your budget and requirements. This requirement leads to the storage being more expensive and a little bit more complicated to configure and administer. SQL Server versions prior to SQL Server 2012, being setup as clustered instance on a WSFC require the storage to be presented as shared storage. I’ll go into detail later on in this article. The first step we need to undertake in preparing our AlwaysOn nodes is to add the Failover Cluster Feature to each node. The nodes that you will use in your SQL Server 2012 AlwaysOn solution have to be part of a WSFC. You can get around this by using database snapshots to give you a ‘read only’ copy. Another downside is that the mirrored database is not accessible. In this case, your application may not operate correctly. If you have several databases residing in an instance of SQL Server and one of those databases is failed over to the secondary location via your database mirroring setup, this database may be dependent on one or more of the other databases in the instance as well. One of the problems with database mirroring is that it cannot automatically failover a group of databases that are inter-related. It can then switch roles with the mirrored database on failover. Database Mirroringĭatabase mirroring gives you the ability to fully-synchronise databases from one instance of SQL Server to another, whether the second instance is located on the same server, a different server in the same data centre or to a server in another data centre.
This has required a lot of work with your storage vendors to get your setup correct. It does this by monitoring the health of the active node and failing over to a backup node, with automatic transfer of resource ownership, when problems are detected.Īlthough the WSFC is able to span multiple subnets, a SQL Server which is cluster-aware has not, until now, been able to support a clustered instance of SQL Server across multiple subnets: It has therefore been quite expensive to set up clustering across multiple data centres due to the WSFC requiring shared storage in both data centres as well as the block level SAN replication. A WSFC cluster is a group of independent servers that work together to increase the availability of applications and services. The technology for WSFC is part of the backbone of AlwaysOn.
Sql server 2012 windows#
We’ll need to explain some of these components of AlwaysOn Windows Server Failover Clustering (WSFC)Ĭlustering technology has been around for quite some time, starting with Microsoft Clustering Services (MCS) back in NT 4.0 days. Employing Built-in Compression & Encryption.Performing DBCC statements against a secondary replica.Allowing backups to be undertaken on a secondary replica.Creating up to four readable secondary replicas.providing a logical grouping of similar databases via Availability Groups.providing a combination of Synchronous and Asynchronous mirroring.Utilizing database mirroring for the data transfer over TCP/IP.Using the WSFC APIs to perform failovers.This is where SQL Server 2012 AlwaysOn can help, because it provides the benefits of: Some of these can take time and resources to implement, and may therefore not be meeting your current requirements. Multi-Site Windows Server Failover Clustering.Single Site Windows Server Failover Clustering.Currently, depending on your environment, you could already be using one or more of the following HA components that existed in previous versions of SQL Server: It aims to provide more granular control to achieve High Availability.
AlwaysOn does not use entirely new technologies but makes more effective use of existing technologies that are tried and tested. This has been designed to meet the ever-increasing need for ‘High Availability’ (HA). One of the better-known features in the release of SQL Server 2012 Enterprise Edition is AlwaysOn.