Anforderungen an das Hardwaregerät zum Lastenausgleich für Lync Server 2013
Thema Letzte Änderung: 11.05.2015
Die skalierte konsolidierte Edgetopologie von Lync Server 2013 ist für den DNS-Lastenausgleich für neue Bereitstellungen optimiert, die hauptsächlich mit anderen Organisationen verbunden sind, die Lync Server verwenden. Wenn für eines der folgenden Szenarien eine hohe Verfügbarkeit erforderlich ist, muss ein Hardwaregerät zum Lastenausgleich in Edgeserverpools für Folgendes verwendet werden:
Verbund mit Organisationen, die Office Communications Server 2007 R2 oder Office Communications Server 2007 verwenden
Exchange UM für Remotebenutzer, die Exchange UM vor Exchange 2010 mit SP1 verwenden
Verbindung mit Benutzern öffentlicher Chatdienste
Wichtig
Das Verfahren, für eine Schnittstelle den DNS-Lastenausgleich und für eine andere Schnittstelle ein Hardwaregerät zum Lastenausgleich zu verwenden, wird nicht unterstützt. Sie müssen entweder für beide Schnittstellen ein Hardwaregerät zum Lastenausgleich oder für beide Schnittstellen den DNS-Lastenausgleich verwenden.
Hinweis
Wenn Sie ein Hardwaregerät zum Lastenausgleich einsetzen, muss der Lastenausgleich für Verbindungen mit dem internen Netzwerk so konfiguriert werden, dass nur für den Datenverkehr zu Servern, auf denen der Zugriffs-Edgedienst und der A/V-Edgedienst ausgeführt werden, ein Lastenausgleich stattfindet. Es kann kein Lastenausgleich für den Datenverkehr zum internen Webkonferenz-Edgedienst oder zum internen XMPP-Proxydienst durchgeführt werden.
Hinweis
Die Direct Server Return (DSR)-NAT wird mit Lync Server 2013 nicht unterstützt.
Informationen dazu, ob ihr Hardwaregerät zum Lastenausgleich die erforderlichen Features von Lync Server 2013 unterstützt, finden Sie unter "Lync Server 2010 Load Balancer Partners" unter https://go.microsoft.com/fwlink/p/?linkId=202452.
Anforderungen bei Verwendung eines Hardwaregeräts zum Lastenausgleich für Edgeserver, auf denen der A/V-Edgedienst ausgeführt wird
Es folgen die Hardwareanforderungen für den Lastenausgleich für Edgeserver, auf denen der A/V-Edgedienst ausgeführt wird:
Deaktivieren Sie den Nagle-Algorithmus für TCP sowohl für den internen als auch für den externen Port 443. Mit diesem Algorithmus werden mehrere kleine Pakete für eine effizientere Übermittlung zu einem einzigen, größeren Paket zusammengefasst.
Deaktivieren Sie den Nagle-Algorithmus für TCP für den Bereich der externen Ports 50.000 bis 59.999.
Verwenden Sie keine Netzwerkadressenübersetzung für die interne oder externe Firewall.
Die interne Edgeschnittstelle muss sich in einem anderen Netzwerk als die externe Edgeserverschnittstelle befinden, und das Routing zwischen ihnen muss deaktiviert sein.
Die externe Schnittstelle des Edgeservers, auf dem der A/V-Edgedienst ausgeführt wird, muss öffentlich routingfähige IP-Adressen und keine NAT- oder Portübersetzung für externe EDGE-IP-Adressen verwenden.
Anforderungen an das Hardwaregerät zum Lastenausgleich
Die Anforderungen an cookiebasierte Affinität werden in Lync Server 2013 für Webdienste erheblich reduziert. Wenn Sie Lync Server 2013 bereitstellen und keine Lync Server 2010-Front-End-Server oder Front-End-Pools beibehalten, benötigen Sie keine cookiebasierte Persistenz. Wenn Sie jedoch Lync Server 2010-Front-End-Server oder Front-End-Pools vorübergehend oder dauerhaft aufbewahren, verwenden Sie weiterhin cookiebasierte Persistenz, während sie für Lync Server 2010 bereitgestellt und konfiguriert wird.
Hinweis
Wenn Sie sich entscheiden, die cookiebasierte Persistenz zu verwenden, obwohl dies für Ihre-Bereitstellung nicht erforderlich ist, hat dies keine negative Auswirkung.
Für Bereitstellungen, in denen die cookiebasierte Affinität nicht verwendet wird:
- Legen Sie für die Veröffentlichungsregel des Reverseproxys für Port 4443 Forward host header auf „True“ fest. Dadurch wird sichergestellt, dass die ursprüngliche URL weitergeleitet wird.
Für Bereitstellungen, in denen die cookiebasierte Affinität verwendet wird:
Legen Sie für die Veröffentlichungsregel des Reverseproxys für Port 4443 Forward host header auf „True“ fest. Dadurch wird sichergestellt, dass die ursprüngliche URL weitergeleitet wird.
Das Cookie für das Hardwaregerät zum Lastenausgleich DARF NICHT als „httpOnly“ gekennzeichnet sein.
Das Cookie für das Hardwaregerät zum Lastenausgleich DARF KEINE Ablaufzeit haben.
Das Cookie für das Hardwaregerät zum Lastenausgleich MUSS den Namen MS-WSMAN haben (dies ist der von den Webdiensten erwartete Wert, der nicht geändert werden kann).
Das Cookie für das Hardwaregerät zum Lastenausgleich MUSS in jeder HTTP-Antwort festgelegt sein, für die die eingehende HTTP-Anforderung kein Cookie enthielt, unabhängig davon, ob für eine vorherige HTTP-Antwort für dieselbe TCP-Verbindung bereits ein Cookie abgerufen wurde. Wenn der Lastenausgleich das Einfügen von Cookies so optimiert, dass sie nur einmal pro TCP-Verbindung erfolgt, darf diese Optimierung NICHT verwendet werden.
Hinweis
In typischen Konfigurationen für das Hardwaregerät zum Lastenausgleich werden die Quelladressenaffinität und eine TCP-Sitzungsdauer von 20 Minuten verwendet. Tcp-Sitzungsdauer, was für Lync Server- und Lync 2013-Clients in Ordnung ist, da der Sitzungsstatus durch Clientnutzung und/oder Anwendungsinteraktion beibehalten wird.
Wenn Sie mobile Geräte bereitstellen, muss das Hardwaregerät zum Lastenausgleich in der Lage sein, einen Lastenausgleich für eine einzelne Anforderung in einer TCP-Sitzung vorzunehmen (tatsächlich muss es möglich sein, einen Lastenausgleich für eine einzelne Anforderung basierend auf der Ziel-IP-Adresse vorzunehmen).
Warnung
F5-Hardwaregeräte zum Lastenausgleich sind mit einer Funktion namens OneConnect ausgestattet, mit der sichergestellt wird, dass für jede Anforderung in einer TCP-Verbindung ein individueller Lastenausgleich vorgenommen wird. Wenn Sie mobile Geräte bereitstellen, stellen Sie sicher, dass der Hersteller des Hardwaregeräts für den Lastenausgleich dieselbe Funktion unterstützt. Für die neuesten mobilen Apps für Apple iOS ist Transport Layer Security (TLS) Version 1.2 erforderlich. F5 stellt hierfür bestimmte Einstellungen bereit.
Ausführliche Informationen zu Hardwarelastenausgleichsmodulen von Drittanbietern finden Sie unter https://go.microsoft.com/fwlink/p/?linkId=230700
Im Folgenden sind die Anforderungen bei Verwendung eines Hardwaregeräts zum Lastenausgleich für Director- und Front-End-Pool-Webdienste aufgeführt:
Legen Sie für interne virtuelle IP-Adressen der Webdienste die Dauerhaftigkeit von Quelladressen (interner Port 80, 443) für das Hardwaregerät zum Lastenausgleich fest. Für Lync Server 2013 bedeutet Source_addr Persistenz, dass mehrere Verbindungen, die von einer einzelnen IP-Adresse stammen, immer an einen Server gesendet werden, um den Sitzungsstatus beizubehalten.
Legen Sie ein TCP-Leerlauftimeout von 1.800 Sekunden fest.
Erstellen Sie für die Firewall zwischen dem Reverseproxy und dem Hardwaregerät zum Lastenausgleich des nächsten Hoppools eine Regel zum Zulassen von https:-Datenverkehr an Port 4443 – vom Reverseproxy zum Hardwaregerät zum Lastenausgleich. Das Hardwaregerät zum Lastenausgleich muss für die Überwachung der Ports 80, 443 und 4443 konfiguriert werden.
Wichtig
Weitere Informationen zur Konfiguration des Hardwaregeräts zum Lastenausgleich finden Sie in der Portzusammenfassung – skalierter konsolidierter Edgeserver mit Hardwarelastenausgleich in Lync Server 2013.
Zusammenfassung der Affinitätsanforderungen an das Hardwaregerät zum Lastenausgleich
| Client-/Benutzerstandort | Affinitätsanforderungen an den externen Webdienste-FQDN | Affinitätsanforderungen an den internen Webdienste-FQDN |
|---|---|---|
Lync Web App (interne und externe Benutzer) Mobiles Gerät (interne und externe Benutzer) |
Keine Affinität |
Quelladressenaffinität |
Lync Web App (nur externe Benutzer) Mobiles Gerät (interne und externe Benutzer) |
Keine Affinität |
Quelladressenaffinität |
Lync Web App (nur interne Benutzer) Mobiles Gerät (nicht bereitgestellt) |
Keine Affinität |
Quelladressenaffinität |
Portüberwachung für Hardwaregeräte zum Lastenausgleich
Sie definieren die Portüberwachung für Hardwaregeräte zum Lastenausgleich (Hardware Load Balancers, HLB), um festzustellen, wann bestimmte Dienste aufgrund von Hardware- oder Kommunikationsfehlern nicht mehr verfügbar sind. Wenn beispielsweise der Front-End-Serverdienst (RTCSRV) beendet wird, weil der Front-End-Server oder Front-End-Pool ausfällt, sollte die HLB-Überwachung auch den Empfang von Datenverkehr über die Webdienste beenden. Sie können die HLB-Portüberwachung implementieren, um Folgendes zu überwachen:
Front-End-Server-Benutzerpool – INTERNE HLB-Schnittstelle
| Virtuelle IP/Port | Knoten Port | Knoten Computer/Monitor | Persistenzprofil | Hinweise |
|---|---|---|---|---|
<pool>web-int_mco_443_vs 443 |
443 |
Front-End 5061 |
Quelle |
HTTPS |
<pool>web-int_mco_80_vs 80 |
80 |
Front-End 5061 |
Quelle |
HTTP |
Front-End-Serverbenutzerpool – EXTERNE HLB-Schnittstelle
| Virtuelle IP/Port | Knoten Port | Knoten Computer/Monitor | Persistenzprofil | Hinweise |
|---|---|---|---|---|
<pool>web_mco_443_vs 443 |
4443 |
Front-End 5061 |
Keine |
HTTPS |
<pool>web_mco_80_vs 80 |
8080 |
Front-End 5061 |
Keine |
HTTP |