We help IT Professionals succeed at work.

SQL 2014 AlwaysOn Failover Clusters

George Perolli
We are looking at implementing a SQL cluster and we want to limit data loss if there is a failure.  I realize that using AlwaysOn Availability Groups is a better option, but it is a much more expensive option.  I know that Failover Cluster (FC) uses shared storage and so I will have a single point of failure on the storage.

My big question is if one of my servers fails will I have any data loss?  Another thing that I would like to know is in a FC can I have Server 1 the master of DB1 and Server 2 master of DB2?
Watch Question

Vitor MontalvãoIT Engineer
Distinguished Expert 2017

The AlwaysOn feature doesn't need a SQL Server cluster but a Windows Cluster so the only shared resource will be the Quorum disk.
Ryan McCauleySenior Data Architect

Just to clear up some terminology, Microsoft is now usin the term "AlwaysOn" to describe all of their high-availability clustering options. "Availability Groups" are the feature you're referring to (which is the next generation of Mirroring), and "Failover Cluster Instances" are the new name for what was previously commonly called a sql cluster. Both fall under the "AlwaysOn" umbrella, though.

Availability Groups can be a pretty expensive option - you need Enterprise Edition to use them, where you can do a two-node failover cluster with just standard edition (and add more nodes with enterprise). They do allow some great features, like balancing reads across multiple nodes and a quicker failover than traditional FCI (can be seconds instead of 30 seconds or so for an FCI), but they cost about 4x as much. Also, it's further complicated by the requirement for licensing of both sides of the cluster if you're going to have clients reading from each.

The data loss risk from a failure is the same with both solutions - if the active SQL instance in your failover cluster configuration (or the writable instance in your Availability Group) goes offline, all the transactions currently in process are rolled back and the clients have to reconnect. There's minimal risk of data corruption, as SQL Server is really good to keeping the files safe and recoverable, but you still lose the things that aren't yet committed. If you're concerned about the SAN as a single point of failure in your FCI, there are ways around that - log shipping, transactional replication, and other options that get your data to second physical location. Also, if you're setting up AG and then putting storage for both servers on the same SAN, you're going to have many of the same risks of a SAN failure. There is an upside to AG here, though - with FCI, you have only a single copy of your data and physical corruption can cause problems, where with AG each server has its own copy of the data and physical corruption of one copy of the data still leaves the other copy intact.

Not sure if this clarifies or muddies the waters, but I'm hoping it's helpful. If you've got a specific question given this additional detail, please share it and I'll contribute what I can.
George PerolliSenior Systems Administrator



I have one big question after reading you answer.  If I use FCI do I only have to license one server?  Meaning if I have 2 x 8 core servers I only have to buy licenses for 8 cores?  If I use log shipping or transactional replication I am going to need licensing for the additional server, but I could license for fewer core right?  Then if one of the primary servers dies I can move the licensing.

I am trying to get as much protection as I can for the least amount of money.  Don't get me wrong, if we have to go Enterprise to get the protection and performance that the owner deems necessary then we will get it.  However if I do not have to spend the money, I won't.
Ryan McCauleySenior Data Architect

Agreed - getting what you need for the lower number of dollars is always preferable :)

I assume you've seen the feature list by edition, but here it is just in case:


Also, here's the SQL 2014 licensing guide:


I'm not a licensing expert, but here's my interpretation of the scenarios you're asking about - if you want to read them yourself, you're looking for page 14 and page 20.

Failover cluster instances - Nodes are passive only if you aren't querying them and they're not being used to support anything. You must license both nodes, even if the second node is passive. However, if you have active software assurance (about a 50% cost premium) on the licenses covering your active node, you can cover the standby node for free with no additional licensing

Replication - You can replicate your data to a second location for failover purposes and you're not required to license the standby location. However, you're only allowed to move a core license once every 90 days, so you can't fail over to your standby dataset more than once every 3 months. Again, this is relaxed if you have software assurance on these licenses, and they can be moved between servers at will, with no restrictions.

In either case, you can fully license the standby nodes and it removes all restrictions around what you're allowed to do (failing back and forth, reporting from the secondary, secondary backups, etc).

Again, that's my understanding - please read the guide if you want to get Microsoft's official language.
George PerolliSenior Systems Administrator


I understood that in a FCI configuration you could not access the second node.  Is it possible to configure FCI so that 1 DB can be accessed from one node and another DB can be accessed from the second node?
Senior Data Architect
You can install multiple instances of SQL Server in a failover cluster and place them each on different nodes - that would satisfy what you're looking to do. However, you can't place databases on other nodes by themselves, but instead the databases move between nodes according to the instance to which they're attached.

It might be worth reading through this post, which attempts to clear up what "Active/Active" means and might answer some of your questions: