Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

We're investigating implementation options for SQL Server AlwaysOn.

AlwaysOn is dependant on Windows Clustering, and I have read several articles that state shared storage is no longer a requirement for clustering. I have also read several articles that state the opposite, or state that it only isn't a requirement for multisite clusters.

We do not plan on using multisite clustering. We would have two servers in the same room - one being a master server that takes all writes, and another backup server that we can use as a reporting server if available. On a failover, the secondary becomes the master until the next failover happens. We will also replicate some of our data off-site to two servers in a web farm. This is pretty standard from what I understand.

I'm on the software/database side of this project, so bear with me on these questions - I might need a lot of clarification:

  • Is shared storage still a requirement for our proposed implementation of Windows Clustering?
  • Why is shared storage a requirement, when I'm going to be replicating our SQL data to the other server anyway?
  • Is shared storage only a requirement for system files? Can we have our MDFs/LDFs on directly attached storage? (we probably will use a SAN, but just curious)
  • Is it possible to make replication highly available, possibly by failing over the publishing responsibilities along with everything else? I have a solution in mind if we can't, but that would be really nice.
share|improve this question
Forgot that publisher responsibility failover is provided in AlwaysOn. – Stuart Branham Jan 30 '12 at 15:25
up vote 2 down vote accepted

AlwaysOn Availability Groups do not require shared storage provided by Windows Clustering. This is only required if you are using Failover Cluster Instances.

To answer your other question, you can certainly store your database files on directly attached storage. One thing to watch out for though, is that you need to make sure that the paths on all Availability Replica's are the same. While you technically can do this, it can lead to further issues down the road if you perform add file operations on the primary.

Shared Storage source

Path limitation source (see Restrictions):

share|improve this answer
Thanks for the answer! Now that we've been able to play with it, we understand how it works a bit better. – Stuart Branham May 17 '12 at 21:52

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.