Whether you need to have a good network connectivity, a tight integration with Active Directory or DNS, a stable Windows Server Failover Cluster, etc. the most common advice that technical experts will give you regarding SQL Server Always On Availability Groups falls into one category: technology. I’ve just listed a handful of them and there’s still a bunch more. I’ve been guilty of this myself whenever I get invited to join a technical call to assess a customer environment. I guess it’s but natural: “geeks talking geeks.” Have you ever been invited to a party where everyone is talking about something which you know nothing about? Duh!

When a customer or your manager approaches you and ask about this new SQL Server feature called AlwaysOn (I really don’t like calling it AlwaysOn but that’s how I can communicate with them) pay attention to your initial response. I bet you would start talking about the technical details of the feature – having multiple copies of the database, faster failover, automatic redirection, readable secondaries, etc. There’s nothing wrong with that. However, when you start off with the technology aspects of a feature, technology will end up dictating the direction of the conversation.

So, What Should Technical Experts Be Telling Me About SQL Server Always On Availability Groups?

I’m glad you asked. The answer to that is simply this:

It’s interesting how a simple phrase like this changes the tone of the conversation from technology-focused to requirements-focused. I confess that I still struggle with it on a regular basis. But I try my best to refocus the conversation from technology to that of requirements. Here are a couple of questions you might ask during a conversation:

• Instead of asking, “Do you prefer a failover clustered instance or an Always On Availability Group,” try asking, “how much downtime can you afford?“
• Instead of asking, “How many replicas do you need for your Always On Availability Group,” try asking, “how much data can you afford to lose?“
• Instead of asking, “Do you need 24 x 7 availability,” try asking, “what was the agreed upon service level?“

If you start asking non-technology-related questions, you start to uncover more important aspects of the business that may not have been discovered had we focus on technology. One example I can think of was when one of my previous customers asked about Always On Availability Groups in relation to their SharePoint 2013 environment. While the SharePoint farm is mission-critical, it is only accessed during normal business hours within the North American timezone, roughly between 7AM Eastern time to 7PM Pacific time Monday to Friday. This means that they have a 9-hour maintenance window during the weekdays and more than 48 hours during the weekends. While they started asking about implementing Always On Availability Groups for their SharePoint 2013 farm, I recommended that they simply implement a 2-node failover clustered instance since they already have shared storage anyway. For disaster recovery, they can just use log shipping. This design was enough to meet their business requirement. It even saved them big time on licensing cost because Always On Availability Group is only available in Enterprise Edition. They were able to implement a 2-node SQL Server failover clustered instance using Standard Edition.

But the point simply is, let the business requirements dictate the design and implementation of a technology solution and not the other way around. As a technical expert, resist the temptation to start and lead the conversation towards the technical aspect. Focus on the business requirement to define the appropriate technology solution.

To help you even further, I’ve recorded a video that highlights the different acronyms (I also call them the Alphabet Soup) that need to drive your high availability and disaster recovery solutions – be it implementing a SQL Server Always On Availability Group or any other technology.

Feeling helpless and confused when dealing with Windows Server Failover Clustering  (WSFC) for your SQL Server databases?

You’re not alone. I’ve heard the same thing from thousands of SQL Server administrators throughout my entire career. These are just a few of them.

“How do I properly size the server, storage, network and all the AD settings which we do not have any control over?”

“I don’t quite understand how the Windows portion of the cluster operates and interacts with what SQL controls.”

“I’m unfamiliar with multi-site clustering.”

“Our servers are setup and configured by our parent company, so we don’t really get much experience with setting up Failover Clusters.“

If you feel the same way, then, this course is for you. It’s a simple and easy-to-understand way for you to learn and master how Windows Server Failover Clusters can keep your SQL Server databases highly available. Be confident in designing, building and managing SQL Server databases running on Windows Server Failover Clusters.

But don’t take my word for it. Here’s what my students have to say about the course.

“The techniques presented were very valuable, and used them the following week when I was paged on an issue.”

“Thanks again for giving me confidence and teaching all this stuff about failover clusters.”

“I’m so gladdddddd that I took this course!!”

“Now I got better knowledge to setup the Windows FC ENVIRONMENT (DC) for SQL Server FCI and AlwaysON.”