A large-scale Lync deployment typically consists of at least one central site that contains either a Standard or Enterprise Edition pool and one or more branch sites that don't warrant having a full-blown Lync deployment, but still need local voice connectivity in case of a WAN outage.
You have 4 options when considering what to deploy at a branch site:
- Survivable Branch Appliance (SBA) - an all-in-one solution that consists of a PSTN gateway with the appropriate interface required for connectivity to the PSTN and a "Lync-Lite" installation that has only the Lync registrar and mediation server roles.
- Survivable Branch Server (SBS) - A "Lync-lite" installation containing the Lync registrar and mediation server roles.
- A PSTN gateway and a standalone Lync mediation server
- A full-blown Lync deployment (typically Standard Edition)
What a lot of people don't realize is that there is more to consider than simple user counts. Let's start by looking at where an SBA is appropriate, and where it isn't.
Survivable Branch Appliance
As noted earlier, a Survivable Branch Appliance is an appliance that contains a PSTN gateway along with a small Windows Server 2008 R2 deployment with the Lync registrar and mediation server roles. SBAs are purchased from vendors such as NET, Audiocodes, Dialogic, or Ferrari, among others. An SBA is paired with a central site that has a full-blown Lync deployment and is designed to be dropped into an office that doesn't have much local IT support.Lync clients are homed on an SBA, and will register/login directly against it. PSTN calls are routed through the mediation server role and onto the PSTN gateway component of the SBA.
While clients register against the SBA, their contact list is still homed on the central Lync deployment. Also, all conferencing features and response group functionality is provided by the central Lync deployment. So, if the WAN link between the central site goes down, clients will lose their personal contact list, the ability to do multiparty web/video conferencing and any response groups whose phone numbers terminate on the SBA won't work. This is beautifully illustrated by VOIPNorm on his blog post on the topic. What DOES work is one-to-one IMs/telephone calls, PSTN calling, searching for contacts and any other features that don't require the full Lync deployment's involvement. Again, see the blog post by VOIPNorm for full details.
When to Use a SBA and When Not To
Use an SBA when you your site meets the following criteria:- Up to 1000 users (2000 if you use 2 SBAs)
- Have a T1/E1 or analog connection to the PSTN
- Won't miss conferencing or response group functionality during a WAN outage
- Have limited IT staff on site
- Does a lot of conferencing and has a slow/expensive WAN pipe to the central site. Conferencing services come from the central pool, so this can be a strain on WAN resources.
- Requires high availability for conferencing features and/or Response Group services
- Use a SIP trunk for PSTN connectivity, unless the SBA can be configured as a SIP gateway and doesn't have PSTN interfaces you don't need (they aren't cheap)
Survivable Branch Server
A Survivable Branch Server (SBS) has the same capabilities as an SBA, but without the PSTN gateway component. It isn't something that you purchase from a vendor. It's simply a "Lync-lite" server you define in the topology and install yourself on a regular Windows Server 2008 R2 (or Windows Server 2012 for Lync 2013) server. Like the SBA, it only has the Lync registrar and mediation server roles.Incidentally, you won't see an option to define an SBS in the Lync topoology. Your only option is an SBA. Since the functionality of the Lync portion of the SBA is identical for an SBS, it doesn't need to be defined separately. Lync doesn't care if the PSTN gateway is part of the same chassis as in an SBA or a separate component as with an SBS.
When to Use a SBS and When Not To
Use an SBS when your site meets the following criteria:- Have up to 2000 users
- Have the local infrastructure to support a full-blown Windows Server deployment (either VM or physical server)
- Have a SIP trunk connection to a Lync-certified SIP provider, or you already have a standalone PSTN gateway
- Won't miss conferencing or response group functionality during a WAN outage
- Have at least some local IT staff
- Does a lot of conferencing and has a slow/expensive WAN pipe to your central site. Conferencing services come from the central pool, so this can be a strain on WAN resources.
- Requires high availability for conferencing features and/or Response Group services
- Have either a T1/E1 or analog service for PSTN access. You would still need to purchase a PSTN gateway, and would probably be better served by using an SBA (unless either of the above 2 points apply)
PSTN Gateway and Mediation Server
This option is an interesting one in that I've not seen it "in the wild". A site with just a mediation server role is entirely dependent on the WAN link to the central site. If the WAN goes down, then so do your clients. You need the infrastructure to support a Windows installation, something many small branch sites don't have. If you have a SIP trunk connection, you may not need a PSTN gateway at all. Conversely, you may not require a mediation server if you use media bypass to send client audio traffic directly from the client to the PSTN gateway.When to Use this Option and When Not To
Use a PSTN Gateway/mediation server when your site meets the following criteria:- You have a 100% reliable WAN connection to your central site or your users will be OK with no functionality in the event of an outage
- Your WAN isn't reliable
Standard Edition Deployment
Sometimes, you will need a full-blown Lync deployment at your branch site. With even just a Standard Edition server, local clients will get all the functionality Lync has to offer, so WAN outages won't be a big issue.
When to Use this Option
Use a Standard Edition server when your site meets one or more of the following criteria:
- You have more than 2000 users in a site
- Your WAN link reliability is low
- Your users do a lot of conferencing with each other
- You need local Response Group functionality
Hopefully, this post will give you some better guidance as to what branch role to deploy at your sites. If you have any questions or comments, please let me know. By the way, the above is relevant for both Lync 2010 and Lync 2013.
0 komentar:
Posting Komentar