Поделиться через

Should I upgrade SQL? Move to SQL Mirroring? - Microsoft Lync 2013

  • Статья

Lync_2013_SQL

I have seen this topic brought up quite a bit in organizations looking to upgrade there current Lync 2010 Infrastructure or implementing Lync 2013 in a new environment where by they have not used Unified Communications Products from Microsoft previously.

Microsoft have made some big changes in the Back End Supported Topology's in Lync 2013 along with many changes in HR/DR (High Availability/Disaster Recovery) and so to benefit from all of the features provided in Lync 2013 it is important that you deploy the infrastructure in a supported scenario and likewise to ensure you are fully supported by Microsoft.

In this post I am going to briefly touch on the SQL Server requirements & HR/DR Features but I will be going into further depth with these at a later date.

These are two questions which have been asked by organizations recently which I have answered simply below:

Q. Can I use my existing Microsoft SQL Server version

A. If you currently use a x64 version of SQL Server then you can use it providing is one of the following versions:

  • SQL Server 2008 R2 Standard & Enterprise Edition
  • SQL Server 2012 Standard & Enterprise Edition

Please Note: x86 SQL Scenarios are NOT supported with Lync 2013 and it is recommended that you do not mix/match your SQL versions in the topology as you don't want DB Issues.. :o

Q. Can I use my existing SQL Clustering Topology?

A. You can use your existing SQL Server Cluster although this is not a supported scenario, and so you would be implementing an non-supported back-end topology and so therefore it is recommend you migrate to SQL Mirroring.

----

SQL Server Back End High Availability - SQL Mirroring / Requirements 

  • Primary Publisher (principal)
  • Secondary subscriber
  • Witness Server is optional but as it provides automatic fail-over it's worth considering.
  • High-Safety Mode (Synchronous)

It is important that:

  • Primary, Mirror and witness have the same version of SQL Server
  • Primary & Mirror must be running the same edition, so the witness can be different if you so wish.
  • It is not required for you to have the same instance name between the Primary & Mirror but it is recommended for ease of administration.

SQL Mirroring Planned Fail over: (or/ no witness)

First of all lets find out the current state of the mirror by running these two commands:

Get-CsDatabaseMirrorState -PoolFQDN <InsertPoolFQDNhere> -DatabaseType User
Get-CsDatabaseMirrorState -PoolFQDN <InsertPoolFQDNhere> -DatabaseType CMS

Then we need to invoke the fail-over by running the following two commands:

Invoke-CsDatabaseFailover -PoolFQDN <InsertPoolFQDNhere> -DatabaseType User -NewPrincipal mirror -Verbose
Invoke-CsDatabaseFailover -PoolFQDN <InsertPoolFQDNhere> -DatabaseType CMS -NewPrincipal mirror -Verbose

If you had a witness server then this would be done automatically, although it's good to keep it in mind as you might want to test fail-over.

The user experience during a Back End Failure is anticipated to be as follows:

  • If you use a SQL Witness Server then Little to No Interruption
  • If you do not use a SQL Witness Server then it resiliency mode is invoked and it will await IT Administrator completes manual fail-over.
  • If both the principal and mirror Back End Servers fail then again interruption will be experience until IT Administrator completes manual fail-over/recovery.

I hope this helps, if you have any further questions please feel free to ask.

Cheers,

James.