This post has been republished via RSS; it originally appeared at: Skype for Business Blog articles.
First published on TECHNET on Nov 28, 2017Author: Steve Schiemann
Introduction and Background:
This writing is intended for customers currently implementing or planning for the Software Defined Networking Interface (SDN) implementation for Lync/Skype for Business on-premise servers. As noted in my previous blog post , the SDN Interface uses open protocols to apply software control to network hardware. There are three primary components to the SDN Interface:
· The Dialog Listener that captures signaling and quality observations about media traffic between Skype for Business endpoints. The Listener component (a.k.a. “LDL”, or Lync Dialog Listener) needs to be installed on each Front-End server.
· At least one SDN Manager that collects data from Dialog Listeners and distributes to third-party network management systems (“Subscribers”, or network controllers). If a single Manager or manager failover configuration is deployed, call quality data is stored in memory on each manager. This is transient data, meaning that as soon as it is sent to a controller, it goes away. In a manager pool configuration, a data store that maintains the shared state among all SDN Managers in a single pool is required. The data store could be a SQL database or Redis cache system.
· One or more Subscribers. These controllers support a RESTful (REpresentational State Transfer) web service to receive and analyze the call- and media-quality data posted from the SDN Managers. Based on the call quality data received, these third-party network management systems can make real-time adjustments to optimize network traffic.
This blog post applies primarily to the Manager component . This component can be deployed in different ways:
· In a manager pool
· In a failover configuration
· As a single manager
· Manager and Listener components collocated on the same server.
For more context, please refer to my previous blog post, online SDN Interface documentation , and/or the documents downloaded with each version of the SDN Interface.
Statement:
If deploying multiple SDN Interface managers, the Skype for Business product group is now strongly recommending installing SDN Manager pools, instead of deploying managers in a failover configuration.
Why?
Failures triggered by various connection issues reaching limits cause the DialogListener to fail over. The problem is that there is no coordination among them. Failover configuration is really targeted for a disaster mitigation solution. If failover is configured, the limits in the parameters (such as submitqueuelen and maxretrybeforefailover in our documentation ) should be set high enough to prevent a failover happening in unintended situations. Details regarding these parameters are beyond the scope of this post.
When a disconnected Dialog Listener attempts to deliver messages to the primary SDN Manager, a failover protection algorithm will switch to the alternative SDN Manager to ensure that the SDN Interface provides continuous service when server failures occur. In this case, the alternate SDN Manager becomes the new primary service provider. Call states are lost during the failover transition , because state is kept in memory on the primary SDN Manager. This may cause inconsistent or incomplete message reporting delivered to subscribers until the new active SDN Manager can establish a consistent view of the ongoing media streams.
In the event of fail over, the secondary computer is promoted to the new primary node. Restoring the second node will automatically make it the secondary node, and the new primary node will stay in place until it fails over. Listeners will not “fail back” automatically to their original manager.
Why is an SDN Manager Pool Better than a Failover configuration?
In a Skype for Business SDN Interface pool configuration, all Dialog Listeners are connected to a DNS load-balanced pool of SDN Manager servers.
In this configuration, the size of the pool scales with the message load produced by the Skype for Business Servers and Dialog Listeners. The pool automatically handles most server failures. Network controllers (subscribers) connected to this SDN Manager pool receive a consistent state about applicable media streams handled by the connected Skype for Business Server front end pools.
Disaster scenarios can be dealt with by defining the SDN Manager pool across different locations. The failover configuration is there for similar failover, but it needs careful configuration and therefore not really recommended at all. Setting up an SDN Manager pool across different locations is preferred.
The disadvantage is that you need a data store (Redis or SQL) for a manager pool, but the advantage is load-sharing within the pool, instead of having a passive backup.
Summary
Although the documentation that is downloaded with each version of the SDN Interface treats each possible manager deployment equally, the product group is considering deprecating the failover scenario. If deploying multiple SDN managers, strongly consider using one or more manager pools.