In praise of Lync Standard Edition
25/10/14 13:31 Filed in: Lync
Standard Edition is more capable than most give it credit for...let’s have a look.
====
One of the things I find interesting about Lync is how often the Standard Edition server is overlooked when evaluating the potential deployment options. Invariably it’s because people see the term ‘high availability’ and automatically go for the Enterprise Edition model.
Now, the problem with that is that an Enterprise Edition pool can all of a sudden look like a lot of servers, infrastructure, and licensing. By way of example, consider this (click on the image to see a larger version):
So we have three Front End Servers, two access Edge, two reverse Proxy, a hardware load balancer for web services. We also have dependencies on SQL and file storage - not to mention Office Web Application servers should you wish to deploy those as well.
That appears to be a lot doesn’t it? The thing is, that architecture can support thousands of users - a three server pool for example with the right resources will support in excess of 12k active users.
Let’s not forget as well that if you want a DR pool, you need another Enterprise Edition pool with the same architecture...all of a sudden, Lync can look quite expensive can’t it, especially if you have fewer users.
When looking at high availability/recoverability, the key points are Recovery Time Objective (RTO), and Recovery Point Objective (RPO). The higher requirement for both then typically the more infrastructure you’ll need - for example the Enterprise Pool setup when combined with a replicated DR pool offers a very small RTO threshold due to the all the redundancy.
Let’s say for example you had 500 people, and wanted high availability. Would you really want to invest in all that architecture? in reality, you may not want to - this is where the Standard Edition can shine. You can implement a far smaller infrastructure that chances are will provide a reasonable RTO through pairing. Consider this scenario (Again click on the image for a larger copy):
But wait - this doesn’t give us high availability does it! Well, it does really - the issue comes down to what you consider to be high availability. You can do fully automated availability/failover using the Enterprise Edition - that is if one of the servers/services fails, then the client is automatically redirected to one of the surviving servers. That though has the dependencies listed earlier on infrastructure and architecture.
What you can do with Standard Edition is pair them for Disaster Recovery. In the event of a failure of the primary server, an Administrator can invoke failover and users will be pushed to the opposing Standard Edition server.
Sure, it takes administrative input, but look at the cost advantages against the fully deployed Enterprise Edition pool. No SQL needed (unless you want archiving/media monitoring), no separate file storage requirements, no hardware load balancer etc. All of a sudden a RTO of 15 minutes or so becomes far more attractive.
But wait - again - I want telephony! I need high availability for telephony! Well, Standard Edition can do this too through the pairing of the pools. In the event of a failure of the primary server, Lync voice will automatically be re-routed to the secondary server so your telephony will survive. Note that the telephony will survive in a mode known as ‘Reduced Functionality Mode’ - users will be able to use telephony but some higher level functions will not be available....here’s a quick summary:
Available services:
- PSTN Inbound/outbound calls
- Internal Calling
- Hold/Transfer
- Two Party IM and Audio/Video
- Call Forwarding, Simultaneous Ringing, Delegation, Team-call
- Join conferences scheduled by users homed on a different non-failed pool
Unavailable services:
- Scheduling IM, A/V & Web Conferences (I.e. multi-party)
- Presence and Do Not Disturb (DND) based routing
- Updating Call Forwarding settings
- Response Group Service & Call Park
- Leaving Voicemails
- Voicemail Retrieve
Bear in mind that if you invoke DR and push users to the opposing Standard Edition server then all functionality comes back on line.
Very cool hey? All of a sudden you have a highly available architecture, that’s cheap to deploy and manage, without lots of infrastructure dependencies.
A single Standard Edition server (with adequate resources) can service approximately 5,000 users. Think about that - Five. Thousand. Users. Standard Edition paired deployments start to become very attractive don’t they.
Some other things to note:
- The other Standard Edition server can either be next to your live one, or in a remote data centre - brilliant dispersed recoverability there.
- You can house 50% of your users on each server - this means that in a failure only 50% of the users will be affected while you invoke DR for the broken server. Once you have invoked DR 100% of the user load will be on the surviving server, with all services restored.
- You can only pair the same pool types - I.e. Standard Edition to Standard Edition, Enterprise to Enterprise - you cannot pair Enterprise to Standard.
- You can only pair in a one to one model, not one to many. So you can pair one Standard Edition server to one other, you can’t pair a Standard Edition to multiple other Standard Edition pools.
Anyway, I hope you can see that a Standard Edition deployment has an awful lot going for it in terms of scale of deployment. Make sure you plan it properly and you’ll have a great, and highly available, platform.
Oh - edited to add - here’s a great article describing the availability model.
New Pool HA Features in Lync2013
blog comments powered by Disqus