Tech News Today, Marshmallow Custom Rom, Huawei, Run Programs, Network, Chromebook, Bank Account

Selasa, 07 Februari 2012

Hardware Load Balancers in Lync

Hardware Load Balancers in Lync - To all visitors of this blog, I say welcome and thank you for visiting the blog Tech News Today Look for all the things you need that are available on this blog. If not available, please leave suggestions and comments for the development of this blog. now we will discuss first about Hardware Load Balancers in Lync we have collected a lot of information from sources to create this article, so please see.

Articles : Hardware Load Balancers in Lync
full Link : Hardware Load Balancers in Lync

You can also see our article on:


Hardware Load Balancers in Lync

Over the past while, I've come across several Enterprise Edition Lync deployments done by other companies that utilized hardware load balancers for all Lync services.  In every case, the reason given for using the hardware load balancers was "so we could have high-availability".  They were shocked to find out that hardware load balancing all Lync services is actually not recommended in a wide variety of scenarios and they could have saved themselves a lot of time and money.

When I design a highly-available Lync deployment, I ask four questions whose answers determine where hardware load balancers are required:

  1. Will the majority of internal clients be running Lync?
  2. Will the majority of external clients be running Lync?
  3. Do you require high-availability when federating with companies running OCS 2007 R2 or older, or MSN/Yahoo!/AOL/GoogleTalk/Jabber?
  4. Do your external users need to play messages on their phone during a failover?
If the answer to #1 is "No", then I recommend against using hardware load balancing (HLB) for all internal Lync front-end pools.  If the answer to #2, #3 and #4 are also "No", then I recommend against using HLB for edge servers as well.

Before I go on, I should stress that HLBs are still required for load balancing HTTP/HTTPS traffic to the front-end servers.  Since web connections are session based, they are not suitable for DNS load balancing.  So, for your web services (which includes address book downloads, meeting content and meet/dialin URLs), you will still need a simple HLB solution, which can be provided by either hardware or even a dedicated software-based load balancer (but don't use Windows NLB, its not supported)

Using hardware load balancers in Lync can be a costly endeavour for many reasons:

  • For a full HLB solution for a single Lync site with edge services, you would need an HLB for the front-end pool, an HLB for the internal interfaces on your edge pools and an HLB for the external interfaces on your edge pool.  That's 3 HLBs.
  • Many HLBs are not well suited to real-time communication.  HLBs that support real-time media are much more expensive than one used only for web traffic balancing.  
  • Configuring the load balancers to work with Lync is much more complicated and extends the implementation time. It can also complicate troubleshooting connectivity issues. 
  • Putting additional hardware between your users and the servers also introduces additional network latency, which is something you want to minimize where possible.  
  • Finally, the HLBs themselves can be a single point of failure, unless you deploy multiple nodes.
Lync can use DNS load balancing to provide high availability.  That term is misleading, because it implies that  DNS is responsible for load balancing, which is not true (or possible, since you can only do DNS round-robin in most cases).  DNS is only used to present the initial list of available front-end or edge servers (depending on if the user is internal or external).  Once the Lync client successfully connects to Lync, it caches the IP address of each server in the pool.  The user will preferably connect to the same server at each login (calculated using an algorithm described here), but if that server is unavailable, the client will automatically and seamlessly connect to another server in the pool.  The same is also true for federated connections from other companies, as long as they are using Lync for their edge servers.   

For legacy connections or 3rd party IM provider connections to a DNS load balanced Lync pool, the clients/edge server will only connect to the first IP address that is returned from a DNS lookup.  Should that server go down, they will not failover to an alternate server.  The same is true for external users who try to listen to Exchange-based voicemail messages during a failover.  If legacy/3rd party connections or external access to voicemail (and remember that voicemail messages are always accessible via Outlook) are important, then this is the ONLY reason I would deploy HLB on your edge servers.  In most cases, the company accepts the reduced potential for legacy high-availability in return for a simpler, cheaper and more reliable solution.

So before you go and drop a ton of money on hardware load balancers, make sure you understand the built-in high-availability capabilities in Lync first, so you can make an informed decision.

For more information on DNS load balancing in Lync, check out these links:
Lync DNS Load Balancing on Technet
Lync DNS Load Balancing on NextHop



information Hardware Load Balancers in Lync has been completed in the discussion.

hopefully the article we give the title Hardware Load Balancers in Lync can provide knowledge for you in living everyday life in determining the gadget that suits your needs.

you just read the article about Hardware Load Balancers in Lync if this article is useful for you and want to bookmark it or share it please use the link https://sihanandi.blogspot.com/2012/02/hardware-load-balancers-in-lync.html thank you and do not forget to comment if anyone.

Tag :
Share on Facebook
Share on Twitter
Share on Google+
Tags :

Related : Hardware Load Balancers in Lync

0 komentar:

Posting Komentar