0

Based on the discussions that we had internally we initially decided to move with a SQL FCI for our non critical databases so that we would have hardware level redundancy. However, now the issue arises where in the project manager says that one of their azure VM's are in main campus and the other VM is in the DR site...so shared storage is not possible. Basically, as per him it would defeat the purpose of having them in separate locations on separate hardware..so he is overruling SQL FCI as an option. Now, the requirement is to have 2 SQL Servers with their own storage that we can fail over in an emergency or for maintenance.

My question at this point is why we can't have a shared storage between 2 different sites? Also is it feasible and recommended to have more than 30+ databases into AlwaysOn in case if we want to explore that route. Is there any other option if not that.

3
  • Azure VM or on-prem vm, I'm unsure as you said "azure main campus" but azure doesn't have a "main campus"? If it's on prem, you absolutely can have shared storage between the sites... whether or not your hardware and licensing for your storage vendor supports it or not is another story. Commented Oct 31, 2017 at 23:31
  • I meant like both the systems are in Azure if I understand this correctly but are in different sites...so is shared storage a feasibility or we need to move forward with AlwaysOn
    – Feivel
    Commented Nov 1, 2017 at 15:47
  • Yes, again, you can have shared storage in Azure - just not how you're thinking about it... this is also why I commented on Tony's answer. Rob Hindman shows this and more: blogs.msdn.microsoft.com/clustering/2017/02/14/… Commented Nov 2, 2017 at 5:26

1 Answer 1

1

The problem with having shared storage across sites is that the storage can't be in the same site as both systems, so you end up with unacceptable storage communication latency for one or both systems.

Availability Groups will not only give you the redundant computer hardware, but also redundant storage, so that is a benefit. The only problem you might face (as far as I can see), is that you won't want to configure the availability group with synchronous replication, as, once again, the latency between the sites would cause synchronous replication to slow down the active system. So you'll need to go with asynchronous replication / manual failover.

I don't see any problem with have numerous databases in an availability group. It is simply a matter of system and network resources to get the job done. See Prereqs, Restrictions, Recommendations - Always On Availability Groups. It states that Microsoft routinely tests with 10 AGs and 100 databases.

The typical HA + DR solution these days is to have an AG with two servers at the main site configured for synchronous replication / automatic failover, and one server at the DR site configured for asynchronous replication / manual failover.

9
  • You can have the storage be in the same site as both systems and across sites simultaneously - synchronous storage level replication. Commented Nov 1, 2017 at 4:27
  • Wouldn't the latency be an issue even with hardware replication? If it's a couple of blocks down the street, I can see that would be fine, but if it's 1000 miles... Commented Nov 1, 2017 at 11:44
  • Entirely depends. If it's 1000 miles then obviously it would need to meet their SLA (if they had one) but if it did - then doable. Commented Nov 1, 2017 at 13:49
  • @Sean Gallardy - Microsoft - Could you please point me to a blog post or documentation that actually would provide a reference for synchronous storage level replication indicating that you can have the storage across sites simultaneously.
    – Feivel
    Commented Nov 1, 2017 at 15:42
  • @F.Farouqi Microsoft doesn't make storage devices so this won't be pertinent to your storage vendor, but we do support storage replicas... so here you go: learn.microsoft.com/en-us/windows-server/storage/… software level storage replication. Again, not the same thing as what your storage vendor may support/give/use. Commented Nov 1, 2017 at 21:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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