This is part 2 of a twelve post series. To see an index of all twelve posts click here.
On the second day of Lync’mas my UC Team gave to me: two paired pools!
Introduction
Lync 2010 was a breakout version for Microsoft’s UC platform. The major improvements in voice, video and conferencing shot Microsoft to the upper right sector in Gartner’s “UC Magic Quadrant” reports. For those of us that had been working with OCS and LCS, Lync 2010 was the everything we had been hoping for: unified client, unified application, unified user experience. Perfect, right? Well there was only one hitch: enterprises were seeing all this “unified” business as fancy-speak for “all your eggs in one basket” and they didn’t see much redundancy in the basket.
Client after client that I talked to was VERY excited about Lync and the unified features it brought to enterprise communications. But the common refrain was that they were too afraid to move all voice, video, and conferencing to a platform that didn’t have a great DR story. For those of you too young to remember, Lync 2010 had 3 main options for “DR”:
1) “Metro” DR – involving a stretched SQL cluster (ick) across a metro-area network, requiring extremely low-latency links, high bandwidth, snapshot replication of SQL data, and a network team that was willing to do all this. Unsurprisingly, we never had a single customer take us up on this design.
2) Backup Registrar – involving a separate Lync Standard Edition server or separate Lync Enterprise Edition pool to act as a “backup”. In the case of a failure of a user’s primary Lync server, the client could be redirected to the backup registrar. This allowed phone calls to continue as well as IM. But no presence, no conferencing, no contact lists, no address book lookup. Etc. etc. Truly, this was better than nothing, but a full DR story it was not.
3) Backup and Restore – not awesome for obvious reasons.
Frankly none of these options set anyone’s mind at ease. As a result, many large enterprises were reticent to make Lync a “Tier 1” application – mission critical with a real DR strategy. So Lync was relegated to Tier 2 status, befitting only things like IM/Presence, desktop sharing etc. And this was a real shame. For as great of a Unified Communications solution as Lync 2010 is, lack of DR seemed to force many people to not deploy voice or audio conferencing, depriving Lync of a lot of its “unified” power.
So what’s the deal!?! Why were the Lync DR options so unappealing in 2010? The answer, as it turns out, was not with Lync itself, but rather in the way that Lync was using SQL.
Lync 2010 Limitations
I won’t spend lot of time dwelling on the past, but the Lync 2010 architecture was based on OCS, which was based on LCS which was IM-only, which was never designed to be mission-critical. That architecture had all of the important “stuff” happening in the separate SQL back end server: presence, contact lists, conferencing configuration. So if SQL went down, all the real guts of the system were gone with it. And when you are storing real-time presence info in SQL, replicating that info (available, busy, away, in a call, and so on) is a noisy, intensive business. It’s true that SQL itself could always do replication – but Lync’s problem would then be determining which SQL server was “active” and how to get Front End servers registered with the right Back Ends under which conditions, and on and on. In short: as long as Lync was using the old architecture which placed all the configuration and high-volume transactions on a single backend SQL server (even if it were clustered), DR was going to be very limited.
Lync 2013 needed to radically depart from the old architecture in order to provide better DR, which would in turn get more organizations to put all their communication eggs in one unified (but redundant) basket.
Lync 2013 Paired Pools to the Rescue
If SQL was the cause of so many of Lync’s DR sorrows, then the first order of business was to rethink SQL for Lync 2013. 2010 relied on the Front Ends being very tightly integrated with the SQL back end. 2013 blows this model apart by moving a lot of the former “back-end” functionality right into the Front Ends themselves. With the Front Ends no longer so reliant on a Back End SQL server, Lync 2013 can now just take advantage of Front End replication (handled by the newly-introduced “Lync Backup Service) whereby a copy of all the important user data will be replicated to a Front End server in another Lync pool. This is called “paired pools”.
Lync 2013 paired pools build on the above-mentioned “Backup Registrar” concept introduced with Lync 2010: if your primary pool failed, users could register to another pool located elsewhere. But now with 2013 you’re not also stuck with the above-mentioned crummy limitations of 2010 failover. Yes! In 2013 you get voice, you get video, you get presence, you get conferencing, and you get contact lists! All critical functionality will remain intact during a DR failover with paired pools.
What I like the most about paired pools is that a Lync pool that is serving, say 3,000 users in California can be paired with a Lync pool that is serving 3,000 users in New York. Each pool’s “day job” is to serve its local users. But secretly, in the background, the two pools are replicating all their info to each other in real time. So if a hurricane strikes New York rendering the data center inoperable, all users can be directed over to California & the California pool will do double-duty for a while until service is restored in New York. The reason I like this so much is that you don’t have to have a set of idle Lync servers waiting in a lonely DR site somewhere for this to work. You can use actual in-production pools so you don’t need to waste extra resources on servers / software that will (hopefully) never be used.
Now it’s true that a couple services won’t fail over in paired-pools (Response Groups & CAC). But one can still argue that all critical functionality does remain intact during a disaster, which is the requirement of most organizations’ DR plans for Tier 1 apps.
Conclusion
With the introduction of paired pools, organizations can now feel good about fully adopting Lync and all its workloads. Voice and conferencing are absolutely Tier 1 applications and the architecture changes in Lync 2013 will meet enterprises’ requirements for Tier 1 Disaster Recovery.
This is really important to understand because it’s different than what other traditional IP-PBX vendors have been offering. Paired pools doesn’t just give you PBX redundancy, which Cisco and Avaya have been doing for years. Lync 2013 actually offers you UC redundancy. Not just voice, but also IM, Presence, Video, Audio Conferencing & Web Conferencing services all replicated with the same mechanism of the Lync Backup Service.
Combining the very best UC user experience with the very best UC redundancy – that should make for a very merry Lync’mas indeed.
