Skype for Business High Availability - Pool Pairing

====
High availability and Disaster Recovery in Skype for Business/Lync 2013 is a beautiful thing. Providing always on services, as well as great recovery provisions for DR is core to the product. Looking at it though, you could perceive it requiring a whole heap of hardware and licensing - not the case really. A common misconception is around the pool pairing types. Let's have a look at that.

Before we do however, let's just qualify some terms for the purposes of this blog:

High Availability
For a service to be HA, it automatically survives a failure in the topology, and recovers, without administrative input.

Disaster Recovery
For DR, Administrative input is required to 'push' services/users to a DR site.

Other's have different definitions of the above, but this will do for the purposes of this blog.

Firstly, for both HA and DR, don't be quick to dismiss the Standard Edition of the product. It provides great high availability for voice, and easy to implement/low cost DR. Have a read of this to explain why:

In praise of Lync Standard Edition

Things seem to get expensive when you want to pair an Enterprise Pool for high availability. Consider the pool pairing requirements from this article:

Front End pool disaster recovery in Skype for Business Server 2015

In particular, note the requirements on the pool pairing:



As a quick side note, have a look at the RTO & RPO for the failover:



Great RTO and RPO, right? But wait - this is measured on 40 *thousand* active users, with 200 *thousand* enabled users. So, there's that….

Anyway, back to HA/DR. So let's say for example you implement an Enterprise Edition pool as you want High Availability in your primary pool, and you also want to provision Disaster Recovery for the same pool. The configuration I often see proposed is similar to this (click on the image for a larger view):



So we put three front end servers in the primary pool, and have an SQL server for the databases. We also have the DR pool of three front end servers, and the associated SQL services at that site. Let's say you have 3.5k users for example, that's a lot of server instances and Skype for Business Server 2015 licenses isn't it? With that model, let's assume:

Primary DC (Active)

• 2 x SQL Servers
• 2 x OS, 2 x SQL
• 3 x Front End Servers
• 3 x Skype for Business Server 2015 licenses
• Hardware Load Balancer for Web Services

Secondary DC (Passive)

• 1 SQL Server
• 1 x OS, 1 x SQL
• 3 x Front End Servers
• 3 x Skype for Business Server 2015 licenses
• Hardware Load Balancer for Web Services

With three servers in the pool you'll need to load balance the web services between the pool servers as well, usually using a Hardware Load Balancer of some sort.

In this setup you have done the correct thing according to the supportability rules. Enterprise Pool with Enterprise Pool, virtual to virtual or physical to physical (no virtual to physical pairing), and you've used the same OS across the platforms.

Here's the thing though - why do you need three Front End Servers in the secondary/passive data centre? Look at the rules - where does it state you need the same number of Front End servers? The answer is - it doesn't. You can have a differing amount of Front End servers in the paired pools.

All of a sudden, that architecture is looking smaller. Consider this:




In this model, you'd need:

Primary DC (Active)

• 2 x SQL Servers
• 2 x OS, 2 x SQL
• 3 x Front End Servers
• 3 x Skype for Business Server 2015 licenses
• Hardware Load Balancer for Web Services

Secondary DC (Passive)

• 1 SQL Server
• 1 x OS, 1 x SQL
• 1 x Front End Servers
• 1 x Skype for Business Server 2015 licenses

You've immediately cut out an extra two servers, and the associated licensing, as well as the requirement for hardware load balancing in the secondary site. This works, and is supported. It's a good model for when you want to provide HA & DR for users, without having to put a lot of infrastructure in the secondary DC.

Of course this model only really suits an Active/Passive setup where you have users being provisioned from the primary DC, and the secondary DC is only used in a fail over scenario. If you wanted Active/Active (which is a very credible option), then you'd really need to provide HA in both DCs and provision enough resources for each DC to carry 100% of the load.

I haven't included Office Web Apps in the above, however that's another consideration. You may put a couple of them in the Active DC load balanced - but why would you want multiple in DR? In fact, there's a question of whether you need them in DR anyway unless you consider it a critical function.

Anyway, the point of this blog is really just to show that there's a lot of flexibility in Lync/Skype for Business in terms of HA/DR - put some thought in to it, you'll find it's not as difficult/expensive as you'd imagine.

blog comments powered by Disqus