Lync + SQL: should I mirror or should I cluster

With Microsoft’s recent change to allow clustering support with Lync Server 2013 the question that everyone will be asking: should I deploy a SQL Mirror or a SQL Cluster.  Although I say the answer to this question is “it depends”, I’ll try to explain why I think SQL Mirror should be and is the better SQL option for Lync.

First, SQL Mirroring is baked into the product.  The configuration and setup of a SQL mirror using topology builder (or the PowerShell commands) is so straight forward I think just about anyone can do it.  No matter how many different “wizards” Microsoft throws at the clustering setup and deployment (both Windows and SQL) it’s never been “easy” to do.  I’ll grant, setting up a SQL Cluster is easier today than it was in 2003, I still don’t think it “dummy proof”.  And the fact you still rely on Windows Clustering to configure and setup adds another layer to it all.  Once you add the Windows cluster to the mix, now you suddenly have to have six different arguments with the storage team about how the disks should really be setup on the server.  And the fact that you don’t have to use their “disk is cheap” SAN solution is usually a plus for you as well.

Second, the “baking” of SQL in Lync goes well beyond just the setup.  You have complete control over the SQL Mirror, who currently owns what, movement of the primary/mirror via Lync PowerShell.  Sure, you can do much of the cluster control via PowerShell with SQL 2012 but it’s simply not the same thing.  As part of the installation of the SQL mirror all of the RTC groups are assigned the necessary permissions to accomplish all of the tasks a Lync administrator would need.  You don’t have to go fight the SQL team for permission to move the database from node one to two or figure out just the right amount of permissions so you can control the cluster.

Third, speaking of the SQL team, they hate SQL mirrors.  I mean, really hate them.  You might ask yourself, is this a good thing?  And I would say yes!  On more than one occasion I have found the SQL administrator reaction to the SQL mirror requirement as “I hate mirrors, I won’t support a mirrored database and if you insist on having a mirrored database than you are responsible for it”.  And my answer to them is “fantastic” 100% of the time.  The SQL Administrator is rarely a help in the deployment and maintenance of Lync.  Instead, they are the ones who typically deploy some bizarre self-made application that breaks everything in Lync, make changes so you can’t update the database when you try to patch your server or remove every permission from the server so the next time you happen to reboot a front-end server no services start.  I welcome the administration of SQL servers and a mirror typically gives you that.

Lastly, there is simply no compelling reason not deploy the mirror.  I know this is reverse logic but really, what is the overwhelming and advantageous reason an organization small or large should deploy it to a cluster.  The fact that both clustering and mirrors are on the way out the door with SQL and being replaced with SQL Always-On (which by the way is a fancy mirror database) tells you even Microsoft acknowledges the flaws of the SQL Cluster.

So those are my four reasons why I believe the SQL Mirror is the better option and will continue to be my first recommendation to clients when deploying Lync Server 2013.

In the end, I really wish Microsoft would have done a “we recommend SQL Mirror but support SQL Clustering” statement instead of just saying they support them both.  Although some would have found it confusing I think it would have been a better solution.

If you have any other reasons feel free to comment or maybe you love SQL clusters that is fine as well … although I just don’t know why you would.

4 thoughts on “Lync + SQL: should I mirror or should I cluster

  • November 20, 2013 at 8:38 pm
    Permalink

    I really wish Microsoft would have done a “we recommend alwaysOn,but mirroring and clustering are supported.

    Reply
    • November 21, 2013 at 12:10 am
      Permalink

      Agreed, if they supported it at all. Next version.

      Reply
  • October 9, 2015 at 8:55 pm
    Permalink

    This entire article starts from a point of not having a cluster, having a bad cluster, and having a bad DBA. Maybe I’m spoiled but none of these are true. So mirror means two database, cluster means one. There seems to be absolutely no technical reason to pick Mirroring when you have a decent cluster in place. Leaving clustering as a way better option as it requires half as many databases.

    Reply
    • October 27, 2015 at 12:25 am
      Permalink

      The technical reason to pick a mirror over a cluster is the fact that you have two databases and not at the mercy of the SAN/Shared Storage. So if you are looking for high availability at the storage layer you would pick a mirror (or if in Skype for Business an Always On Availability Group). Of course, we could argue how likely a SAN/Shared Storage failure will occur. But I agree, my view is a bit jaded by having to working with super huge enterprises (100,000+ employees) and getting the SQL team to build a server and give you permissions is about as likely as congress agreeing on a budget deal. 🙂

      Reply

Leave a Reply to Richard Brynteson Cancel reply

Your email address will not be published. Required fields are marked *