SQL Mirroring for Databases

The one weak spot in any Office Communications Server 2007 R2 or Lync Server 2010 deployment was the backend SQL database for each Front End pool. This was traditionally a SQL server cluster hosted by multiple nodes, but the storage for the database had to be a single SAN. Administrators were anxious to remove this single point of failure by leveraging a feature in SQL called database mirroring, in which the databases are kept in sync between two separate nodes each with their own storage. It was technically possible to configure SQL mirroring for the database, but there was no automated or easy way to fail over between the mirrored nodes. More importantly, it wasn’t ever a scenario supported by Microsoft.

Lync Server 2013 has finally introduced support for SQL server mirroring of the backend database, which allows administrators to remove the dependency on a SAN. This helps reduce the complexity and overall cost of any highly available deployment since Windows and SQL server clustering is no longer required. The resiliency of the solution is also improved since there are now two unique copies of the user data within the backend database.

Automatic failover between the mirrored SQL server nodes can be enabled when a SQL server mirroring witness server is deployed. The witness server acts as the third vote for which node should actively serve the databases, similar to a quorum disk in a cluster or a file-share witness in an Exchange Database Availability Group (DAG). The Express Edition of SQL Server can be used for the witness server to save on licensing costs, but regardless of whether the full or the Express Edition is used, it must match the major product version used for the backend nodes.