SfB Pool und Loadbalancer Port

Wer Skype for Business Enterprise-Pools einsetzt, muss auch einen Loadbalancer für die WebServices einplanen. DNS-RoundRobin geht zwar, aber ist nicht zuverlässig. Ein Load-Balancing von SIP ist seit Lync 2013 nicht mehr erforderlich und auch nicht mehr empfohlen.

Die Rolle des HLB

Ein Loadbalancer, der Zugriffe auf mehrere IIS-Instanzen auf den Pool-Mitgliedern verteilt, ist heute keine Besonderheit mehr. Es geht einfach darum http/HTTPS-Zugriffe ohne vorherige Authentifizierung auf die Pool-Mitglieder zu verteilen. Das kann heute jeder Layer-4 Loadbalancer. Mehr ist gar nicht gefordert. Allerdings muss der Loadbalancer natürlich prüfen, welcher Server funktionsfähig ist, damit die Zugriffe nicht auf ein totes Ende laufen.

Wenn Sie sich nicht auf einen PING auf den Server oder ein TCP-Connector auf 443 beschränken wollen, dann ist der Abruf einer Webseite per HTTPS natürlich ein sehr aussagekräftiger Test über die Funktionsfähigkeit des Webservers. Allerdings reicht dies nicht aus, da der WebServer auch reagiert, wenn die dahinter liegenden Dienste wie eben der RTCSRV-Dienst nicht aktiv sind. Der SIP-Server muss die Anfragen der Webapplikation bedienen.

Daher sollte ein Loadbalancer neben der Erreichbarkeit des Webserver per HTTPS auch die Funktionsfähigkeit des SIP-Servers prüfen.

Monitoring 5061

Da die meisten Loadbalancer natürlich kein SIP sprechen und Skype for Business auch eine Anmeldung anfordert, wird meist nur ein Test der Erreichbarkeit von Port 5061 auf dem Real-Server konfiguriert. Die ist im Prinzip funktionsfähig aber führt zu folgender Meldung im Eventlog des Real-Servers

Source: LS Protocol Stack
Event ID: 14502
Level: Error
A significant number of connection failures have occurred with remote server IP 10.1.1.12. 
There have been 120 failures in the last 180 minutes. There have been a total of 493 failures.
The specific failure types and their counts are identified below.
Instance count - Failure Type
493 0x80072746(WSAECONNRESET) 
This can be due to credential issues, DNS, firewalls or proxies. The specific failure types above should identify the problem.

Der Skype for Business Server beschwert sich also über einen Client, der sich sehr oft verbindet und dann die Verbindung wieder abbaut. Normal ist das eher nicht und kann als Angriff oder Fehlkonfiguration im Netzwerk falsch gedeutet werden. Nerviger ist eben die Einstufung als "Error", obwohl es doch nur ein einfacher "Erreichbarkeitstest" durch den Loadbalancer ist.

Konfiguration HLB-Port

Andere gründe als nur eine "Angriffserkennung" kann ich erst mal nicht erkennen, warum der Skype for Business Frontend Service hier so empfindlich ist und sich im Eventlog beschwert. Dennoch hat Microsoft extra für die Überprüfung der Erreichbarkeit durch Loadbalancer eine gesonderte Lösung bereitgestellt. Damit diese „Healtch-Checks“ nicht den normalen Diensteingang betreffen und Skype for Business weiter seine Überwachung aktiv lassen kann, können Sie für Skype for Business einen gesonderten Port für den Loadbalancer-Check konfigurieren. Die Einstellung ist im Pool eine einfache Checkbox mit der Angabe eines Ports:

Der Topology-Builder schlägt hier per Default Port 5060 vor, der von Skype for Business nicht genutzt wird. Port 5060/TCP wird normalerweise für „SIP over TCP“, d.h. SIP ohne Verschlüsselung verwendet. Sie können diese Port in Skype for Business natürlich auch aktivieren. Ich nutzt lieber einen anderen Port, der definitiv nicht genutzt wird und auch nicht von anderen Systemen vielleicht geprobt wird, z.B. 5058. Sie sind hier in der Wahl aber frei, solange Sie den gleichen Port im Loadbalancer als Prüfung eintragen können und keine Firewall o.ä. die Verbindung unterbindet.

Wenn Sie die so gemachte Änderung in die Topologie veröffentlicht haben, zeigt die "ToDo"-Liste an, dass Sie das lokale Setup noch einmal starten sollen. Ich habe allerdings gesehen, dass der Testport nach kurzer Zeit auch ohne das lokale Setup aktiv wurde.

Der Port erlaubt aber nur eine Überprüfung, ob der RTCSRV-Dienst gestartet ist. Soweit ich gesehen habe, gibt es keine interne Logic, bei der dieser Port aufgrund anderer Dienste geschlossen wird. Hier ist also Exchange schon etwas weiter, wo über http-Requests auch wirklich ein „Health-Status“ ermittelt werden kann.

Lieber wäre mir auch ein „healthcheck.htm“ in der Skype for Business Webseite gewesen, der die Ergebnisse von synthetischen Test liefert. Exchange macht dies ja sehr gut vor (Siehe ). Bis dahin sollten Sie in der Firewall eben zwei Checks hinterlegen, und nur wenn beide Prüfungen positiv sind, dürfen die eingehenden Anfragen auf diesen Server weiter gegeben werden.

Weitere Links