SQL Database Mirroring with Lync Server 2010 Series – Prerequisites

I gave you guys a heads up on this a few weeks ago that I’d looked into this in some fairly significant detail and found some interesting behaviour when you attempt to failover after deploying Lync Server 2010 backend and Group Chat databases using SQL Server Database Mirroring. Now that I’ve completed this work, I can share the results with you in a multi-part blog series.

Questions have always been asked over the years as to why organisations can’t use SQL Database Mirroring as a lower cost alternative to SQL Failover Clustering and the only advice we’ve been able to give is what TechNet documentation provides:  “Lync Server 2010 does not support native database mirroring“.

Based on the work I’ve done, I can tell you what happens when you attempt to failover, what you have to do to actually get to a “recovered” situation and reasons why you won’t want to use SQL Database Mirroring with Lync.

The Supported Scenario Today

So today the official supported scenario is to deploy your Lync Server 2010 Enterprise Edition backend and Group Chat databases in one of two ways:
  • On a standalone SQL Server with no resilience.
  • On a highly available SQL Server two node Failover Cluster.
    • This is either for a local, in-site SQL cluster instance for server resiliency only.
    • Or a cross-site, metro data centre SQL clustered instance with one node in each site (and SAN replication, low latency etc) for site resiliency.
The latter solution giving you a resiliency solution with failover you know works for the entire instance.

Why SQL Database Mirroring?

Database mirroring was a new feature delivered as part of SQL Server 2005. The data replication occurs at an individual database level rather than at an instance level in clustering, providing greater flexibility at the expense of a higher management/configuration overhead. Unlike clustering, the system databases e.g. master db cannot be replicated using Database Mirroring. This means that you need to recreate logins, security etc manually on the mirrored node.

The mirroring process transports logs over its own TCP/IP session on port 5022 and uses compression by default. An important point to note is that SQL Server Standard Edition is a single threaded operation whereas SQL Server Enterprise Edition is a multi-threaded mirroring process.

One of the greatest benefits of database mirroring is its flexibility. An example of this is that an administrator can effortlessly switch principal and mirror roles back and forth, failing over between the two nodes. Plus there is no dependency on identical/near-identical hardware, disk, heartbeat networks etc that make traditionally make clustering a hinderance. Think of it like SCR was to Exchange Server 2007.

Compelling Reasons for Database Mirroring

I can definitely see why an organisation would want to utilise mirroring rather than clustering, especially when attempting to design site resiliency. The top reasons being that it is:

  • Cheaper.
  • Represents less infrastructure complexity.
  • Better for site resiliency as there are no tight network and storage requirements. <— No 1 reason.

Test Environment

As part of this investigation, I deployed the following machines to test this configuration:

  • One Lync Server 2010 Enterprise Edition pool consisting of two Front End servers (named FE01 and FE02).
  • Two Lync Server 2010 Group Chat servers (GC01 and GC02).
  • Two SQL Server 2008 R2 servers fulfilling the principal (named SQL01) and mirror (named SQL02) roles for Database Mirroring.

Lync and SQL Configuration

After deploying my servers, I got them ready to define the topology and install Lync. I’m not going to go into loads of detail on the configuration of SQL Database Mirroring here because it’s well covered on TechNet and it’s all GUI driven. I completed the database parts in the following way:

  1. Specified the location for the back end databases for the Front End pool as the principal SQL server (SQL01) in Topology Builder and published.
  2. Setup my Group Chat database and permissions on SQL01 and specified this server in the Group Chat Installation Wizard.
  3. Ensured the Lync backend databases were successfully deployed onto this server.
  4. Verified all sign-in functionality with both the Lync and Group Chat clients.
  5. Configured SQL Database Mirroring using the SQL Server 2008 R2 Management Studio GUI to mirror all databases to SQL02.
  6. Verified that all databases were in a Principal, Synchronized status on SQL01 and Mirrored, Synchronizing on SQL02.

The Next Chapter

Once we’re at this stage, we’re good to start failing the databases over to the mirror node to see how Lync behaves.

Be sure to subscribe and come back for the next part where it gets interesting. Services started failing over the shop, TCP connections were being automagically redirected to the SQL mirror node and there’s lots of the Lync client being in “limited functionality mode”. Stay tuned. 🙂

10 thoughts on “SQL Database Mirroring with Lync Server 2010 Series – Prerequisites

  1. Pingback: SQL Database Mirroring with Lync Server 2010 Series – Prerequisites | Justin Morris on UC « JC’s Blog-O-Gibberish

  2. Tung

    Hi Justin,

    I’m considering HA solution for Archiving/Monitoring Server based on Database Mirroring, did you thought that could be possible, fully function of Lync Archiving/Monitoring could be used after a failover?

    Best Regards,
    Tung.

    Reply
    1. Justin Morris

      Hi Tung,

      A more detailed explanation will be forthcoming in the next blog post in the series, but I’ll tell you right now that Archiving and Monitoring won’t function properly if you failover to a mirror node.

      Reply
    1. Justin Morris

      Hi Geo,

      In what way? This series focuses on SQL database mirroring only, so load balancing with an F5 HLB isn’t applicable in this scenario.

      Reply
  3. mossywell

    Maybe Geo means GTM, not LTM and abstracting the SQL service name in conjunction with short TTLs. (Or even not using GTM at all – just DNS – but that’s then manual process.)

    Reply
    1. Justin Morris

      Absolutely, that’s the most important thing imo. To help organisations make a more informed design choice, I decided it was worth publishing why this isn’t supported and doesn’t work. 🙂

      Reply
  4. Pingback: SQL Database Mirroring with Lync Server 2010 Series – Failover | Justin Morris on UC

  5. Pingback: SQL Database Mirroring with Lync Server 2010 Series - Group Chat | Justin Morris on UC

Leave a Reply to Justin Morris Cancel reply

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.