Anforderungen an den Lastenausgleich für Skype for Business
Zusammenfassung: Überprüfen Sie die Überlegungen zum Lastenausgleich, bevor Sie Skype for Business Server implementieren.
Der Lastenausgleich verteilt den Datenverkehr auf die Server in einem Pool. Wenn Sie über Front-End-Pools, Vermittlungsserverpools oder Edgeserverpools verfügen, müssen Sie den Lastenausgleich für diese Pools bereitstellen.
Skype for Business Server unterstützt zwei Arten von Lastenausgleichslösungen für Client-zu-Server-Datenverkehr: DNS-Lastenausgleich (Domain Name System) und Hardwarelastenausgleich (häufig als HLB abgekürzt). Der DNS-Lastenausgleich bietet mehrere Vorteile, darunter eine einfachere Verwaltung, eine effizientere Problembehandlung und die Möglichkeit, einen Großteil ihres Skype for Business Server Datenverkehrs von potenziellen Hardwarelastenausgleichsproblemen zu isolieren.
Entscheiden Sie selbst, welche Lastenausgleichslösung für jeden Pool in Ihrer Bereitstellung geeignet ist, aber beachten Sie die folgenden Einschränkungen:
Für die interne Edgeschnittstelle und die externe Edgeschnittstelle muss derselbe Typ von Lastenausgleich verwendet werden. Es ist nicht möglich, für eine Edgeschnittstelle den DNS-Lastenausgleich und für die andere Edgeschnittstelle ein Hardwaregerät zum Lastenausgleich zu verwenden.
Für einige Arten von Datenverkehr ist ein Hardwaregerät zum Lastenausgleich erforderlich. HTTP-Datenverkehr erfordert beispielsweise ein Hardwaregerät zum Lastenausgleich anstatt eines DNS-Lastenausgleichs. Der DNS-Lastenausgleich funktioniert nicht beim Client-zu-Server-Datenverkehr.
Wenn Sie für einen Pool den DNS-Lastenausgleich verwenden möchten, aber dennoch Hardwaregeräte zum Lastenausgleich benötigen, beispielsweise für den HTTP-Datenverkehr, ist die Verwaltung der Hardwaregeräte zum Lastenausgleich jetzt erheblich einfacher. Ein Beispiel hierfür ist, dass ausschließlich der HTTP- und HTTPS-Datenverkehr verwaltet wird, während alle anderen Protokolle vom DNS-Lastenausgleich verwaltet werden. Ausführliche Informationen finden Sie unter DNS Load Balancing.
Für Server-zu-Server-Datenverkehr verwendet Skype for Business Server einen topologiefähigen Lastenausgleich. Server lesen die veröffentlichte Topologie im zentralen Verwaltungsspeicher, um die FQDNs der Server in der Topologie abzurufen und den Datenverkehr automatisch auf die Server zu verteilen. Administratoren müssen diese Art des Lastenausgleichs weder konfigurieren noch verwalten.
Wenn Sie den DNS-Lastenausgleich verwenden und den Datenverkehr an einen bestimmten Computer blockieren müssen, reicht es nicht aus, einfach nur die IP-Adresseinträge aus dem Pool-FQDN zu entfernen. Sie müssen auch den DNS-Eintrag für den Computer entfernen.
Anforderungen an das Hardwaregerät zum Lastenausgleich
Die Skype for Business Server skalierte konsolidierte Edgetopologie ist für den DNS-Lastenausgleich für neue Bereitstellungen optimiert, die hauptsächlich mit anderen Organisationen, die Skype for Business Server oder Lync Server verwenden, verbunden sind. Wenn Hochverfügbarkeit für eines der folgenden Szenarien erforderlich ist, muss ein Hardwarelastenausgleich 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 Nat für die direkte Serverrückgabe (Direct Server Return, DSR) wird mit Skype for Business Server nicht unterstützt.
Informationen dazu, ob Ihr Hardwarelastenausgleich die für Skype for Business Server erforderlichen Features unterstützt, finden Sie unter Infrastruktur für Skype for Business.
Anforderungen bei Verwendung eines Hardwaregeräts zum Lastenausgleich für Edgeserver, auf denen der A/V-Edgedienst ausgeführt wird
Im Folgenden finden Sie die Hardwarelastenausgleichsanforderungen 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 TCP-Nagling für den externen Portbereich 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 befinden als die externe Edgeserverschnittstelle, 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 eine der externen Edge-IP-Adressen verwenden.
Die Quelladresse des Clients darf durch den Lastenausgleich nicht geändert werden.
Weitere Hardware-Load Balancer-Anforderungen
Cookiebasierte Affinitätsanforderungen werden in Skype for Business Server für Webdienste erheblich reduziert. Wenn Sie Skype for Business Server 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 beibehalten möchten, verwenden Sie weiterhin die 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-Sitzungslebensdauer, was für Lync Server- und Lync 2013-Clients in Ordnung ist, da der Sitzungszustand 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).
Vorsicht
Wenn Sie mobile Geräte bereitstellen, muss Ihr Hardwarelastenausgleich in der Lage sein, einen individuellen Lastenausgleich für jede Anforderung innerhalb einer TCP-Verbindung auszuführen. Für die neuesten mobilen Apps für Apple iOS ist Transport Layer Security (TLS) Version 1.2 erforderlich.
Vorsicht
Ausführliche Informationen zu Hardware-Lastenausgleichsmodulen von Drittanbietern finden Sie unter Infrastruktur für Skype for Business.
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 Skype for Business Server bedeutet Source_addr Persistenz, dass mehrere Verbindungen, die von einer einzelnen IP-Adresse stammen, immer an einen Server gesendet werden, um den Sitzungszustand beizubehalten.
Legen Sie ein TCP-Leerlauftimeout von 1.800 Sekunden fest.
Erstellen Sie in der Firewall zwischen dem Reverseproxy und dem Hardwarelastenausgleich des Nächsten Hoppools eine Regel, um https: Datenverkehr an Port 4443 vom Reverseproxy zum Hardwarelastenausgleich zuzulassen. Das Hardwaregerät zum Lastenausgleich muss für die Überwachung der Ports 80, 443 und 4443 konfiguriert werden.
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 Der Front-End-Pool ausfällt, sollte die HLB-Überwachung auch den Empfang von Datenverkehr für die Webdienste beenden. Sie können die HLB-Portüberwachung implementieren, um Folgendes zu überwachen:
Front-End-Serverbenutzerpool – 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 |
DNS Load Balancing
Skype for Business Server ermöglicht den DNS-Lastenausgleich, eine Softwarelösung, die den Verwaltungsaufwand für den Lastenausgleich in Ihrem Netzwerk erheblich reduzieren kann. Der DNS-Lastenausgleich gleicht den Netzwerkdatenverkehr aus, der für Skype for Business Server eindeutig ist, z. B. SIP- und Mediendatenverkehr.
Wenn Sie den DNS-Lastenausgleich bereitstellen, wird der Verwaltungsaufwand Ihrer organization für Hardwarelastenausgleichsmodule minimiert. Darüber hinaus wird die komplexe Problembehandlung von Problemen im Zusammenhang mit der Fehlkonfiguration von Lastenausgleichsmodulen für SIP-Datenverkehr vermieden. Sie können auch Serververbindungen verhindern, sodass Sie Server offline schalten können. Der DNS-Lastenausgleich stellt außerdem sicher, dass Hardwarelastenausgleichsprobleme sich nicht auf Elemente des SIP-Datenverkehrs auswirken, z. B. das grundlegende Anrufrouting.
Das folgende Diagramm zeigt ein Beispiel, das sowohl den internen als auch den externen DNS-Lastenausgleich enthält:
Diagramm eines Edgenetzwerks, in dem öffentliche IPv4-Adressen verwendet werden
Wenn Sie den DNS-Lastenausgleich verwenden, können Sie möglicherweise auch kostengünstigere Hardwarelastenausgleichsmodule erwerben, als wenn Sie die Hardwarelastenausgleichsmodule für alle Arten von Datenverkehr verwendet haben. Sie sollten Lastenausgleichsmodule verwenden, die Interoperabilitätsqualifizierungstests mit Skype for Business Server bestanden haben. Ausführliche Informationen zu Load Balancer-Interoperabilitätstests finden Sie unter Lync Server 2010 Load Balancer Partners. Der inhalt gilt für Skype for Business Server.
Der DNS-Lastenausgleich wird für Front-End-Pools, Edgeserverpools, Director-Pools und eigenständige Vermittlungsserverpools unterstützt.
DER DNS-Lastenausgleich wird in der Regel auf Anwendungsebene implementiert. Die Anwendung (z. B. ein Client, der Skype for Business ausführt), versucht, eine Verbindung mit einem Server in einem Pool herzustellen, indem sie eine Verbindung mit einer der IP-Adressen herstellt, die von der DNS-A- und AAAA-Datensatzabfrage (bei Verwendung der IPv6-Adressierung) für den vollqualifizierten Domänennamen (FQDN) des Pools zurückgegeben werden.
Wenn sich beispielsweise drei Front-End-Server in einem Pool mit dem Namen pool01.contoso.com befinden, geschieht Folgendes:
Clients, die Skype for Business ausführen, fragen DNS nach pool01.contoso.com ab. Die Abfrage gibt drei IP-Adressen zurück und speichert sie wie folgt zwischen (nicht unbedingt in dieser Reihenfolge):
pool01.contoso.com 192.168.10.90
pool01.contoso.com 192.168.10.91
pool01.contoso.com 192.168.10.92
Der Client versucht, eine TCP-Verbindung (Transmission Control Protocol) mit einer der IP-Adressen herzustellen. Wenn dies fehlschlägt, versucht der Client die nächste IP-Adresse im Cache.
Bei erfolgreicher TCP-Verbindung handelt der Client die Verwendung von TLS zur Verbindungsherstellung mit der primären Registrierung in „pool01.contoso.com“ aus.
Wenn der Client alle zwischengespeicherten Einträge ohne erfolgreiche Verbindung versucht, wird der Benutzer benachrichtigt, dass derzeit keine Server mit Skype for Business Server verfügbar sind.
Hinweis
Der DNS-basierte Lastenausgleich unterscheidet sich von DNS-Roundrobin (DNS RR), der sich in der Regel auf den Lastenausgleich bezieht, indem dns verwendet wird, um eine andere Reihenfolge von IP-Adressen bereitzustellen, die den Servern in einem Pool entspricht. In der Regel ermöglicht DNS RR nur die Lastverteilung, aber kein Failover. Wenn beispielsweise die Verbindung mit der 1 IP-Adresse, die von der DNS-A- und AAAA-Abfrage zurückgegeben wird (bei Verwendung der IPv6-Adressierung) fehlschlägt, schlägt die Verbindung fehl. Daher ist DNS-Roundrobin an sich weniger zuverlässig als der DNS-basierte Lastenausgleich. Sie können DNS-Roundrobin in Verbindung mit dem DNS-Lastenausgleich verwenden.
Der DNS-Lastenausgleich wird für Folgendes verwendet:
Lastenausgleich von Server-zu-Server-SIP mit den Edgeservern
Lastenausgleich von UCAS-Anwendungen (Unified Communications Application Services), z. B. automatische Konferenzzentrale, Reaktionsgruppe und Parken von Anrufen
Verhindern neuer Verbindungen mit UCAS-Anwendungen (auch als "Ausgleichen" bezeichnet)
Lastenausgleich für den gesamten Client-zu-Server-Datenverkehr zwischen Clients und Edgeservern
Der DNS-Lastenausgleich kann nicht für Folgendes verwendet werden:
- Client-zu-Server-Webdatenverkehr zu Director- oder Front-End-Servern
DNS-Lastenausgleich und Verbunddatenverkehr:
Wenn mehrere DNS-Einträge von einer DNS SRV-Abfrage zurückgegeben werden, wählt der Access Edge-Dienst immer den DNS-SRV-Eintrag mit der niedrigsten numerischen Priorität und der höchsten numerischen Gewichtung aus. Das Internet Engineering Task Force-Dokument "A DNS RR for specifying the location of services (DNS SRV)" RFC 2782, DNS SRV RR gibt an, dass, wenn mehrere DNS SRV-Einträge definiert sind, zuerst die Priorität und dann die Gewichtung verwendet wird. Dns-SRV-Eintrag A hat beispielsweise eine Gewichtung von 20 und eine Priorität von 40, und DNS-SRV-Eintrag B hat eine Gewichtung von 10 und eine Priorität von 50. DNS SRV-Eintrag A mit Priorität 40 wird ausgewählt. Die folgenden Regeln gelten für die Dns-SRV-Eintragsauswahl:
Priorität wird zuerst berücksichtigt. Ein Client MUSS versuchen, den durch den DNS-SRV-Eintrag definierten Zielhost mit der niedrigsten nummerierten Priorität zu kontaktieren, die er erreichen kann. Ziele mit der gleichen Priorität SOLLTEN in einer durch das Gewichtungsfeld definierten Reihenfolge versucht werden.
Das Gewichtungsfeld gibt eine relative Gewichtung für Einträge mit der gleichen Priorität an. Größere Gewichtungen SOLLTEN mit proportional höherer Wahrscheinlichkeit ausgewählt werden. DNS-Administratoren sollten Gewichtung 0 verwenden, wenn keine Serverauswahl erforderlich ist. Bei Datensätzen, die Gewichtungen größer als 0 enthalten, sollten Datensätze mit dem Gewicht 0 eine sehr geringe Wahrscheinlichkeit haben, ausgewählt zu werden.
Wenn mehrere DNS SRV-Einträge mit gleicher Priorität und Gewichtung zurückgegeben werden, wählt der Access Edge-Dienst den SRV-Eintrag aus, der zuerst vom DNS-Server empfangen wurde.
DNS-Lastenausgleich für Front-End-Pools und Director-Pools
Sie können den DNS-Lastenausgleich für den SIP-Datenverkehr in Front-End-Pools und Director-Pools verwenden. Wenn der DNS-Lastenausgleich bereitgestellt wird, müssen Sie auch Hardwarelastenausgleichsmodule für diese Pools verwenden, jedoch nur für HTTPS-Datenverkehr zwischen Client und Server. Der Hardwarelastenausgleich wird für HTTPS-Datenverkehr von Clients über die Ports 443 und 80 verwendet.
Sie benötigen zwar weiterhin Hardwarelastenausgleichsmodule für diese Pools, deren Einrichtung und Verwaltung erfolgt jedoch in erster Linie für HTTPS-Datenverkehr, den die Administratoren von Hardwarelastenausgleichsmodulen gewohnt sind.
DNS-Lastenausgleich und Unterstützung älterer Clients und Server
Der DNS-Lastenausgleich unterstützt automatische Failover nur für Server mit Skype for Business Server oder Lync Server 2010 sowie für Lync 2013- und Skype for Business-Clients. Frühere Versionen von Clients und Office Communications Server können weiterhin eine Verbindung mit Pools herstellen, in denen der DNS-Lastenausgleich ausgeführt wird. Wenn sie jedoch keine Verbindung mit dem ersten Server herstellen können, auf den der DNS-Lastenausgleich verweist, können sie kein Failover auf einen anderen Server im Pool durchführen.
Wenn Sie Exchange UM verwenden, müssen Sie außerdem mindestens Exchange 2010 SP1 verwenden, um Unterstützung für Skype for Business Server DNS-Lastenausgleich zu erhalten. Wenn Sie eine frühere Version von Exchange verwenden, verfügen Ihre Benutzer nicht über Failoverfunktionen für diese Exchange UM-Szenarien:
Wiedergeben der Enterprise-Voicemail auf dem Handy
Übertragen von Anrufen von einer automatischen Exchange UM-Telefonzentrale
Alle anderen Exchange UM-Szenarien funktionieren ordnungsgemäß.
Bereitstellen des DNS-Lastenausgleichs für Front-End-Pools und Director-Pools
Für die Bereitstellung des DNS-Lastenausgleichs für Front-End-Pools und Director-Pools müssen Sie einige zusätzliche Schritte mit FQDNs und DNS-Einträgen ausführen.
Ein Pool, der den DNS-Lastenausgleich verwendet, muss über zwei FQDNs verfügen: den regulären Pool-FQDN, der vom DNS-Lastenausgleich (z. B. pool01.contoso.com) verwendet wird und in die physischen IP-Adressen der Server im Pool aufgelöst wird, und einen weiteren FQDN für die Webdienste des Pools (z. B. web01.contoso.com), der in die virtuelle IP-Adresse des Pools aufgelöst wird.
Wenn Sie im Topologie-Generator den DNS-Lastenausgleich für einen Pool bereitstellen möchten, müssen Sie zum Erstellen dieses zusätzlichen FQDNs für die Webdienste des Pools das Kontrollkästchen Internen Webdienstpool-FQDN außer Kraft setzen aktivieren und den FQDN auf der Seite Webdienst-URLs für diesen Pool angeben eingeben.
Um den vom DNS-Lastenausgleich verwendeten FQDN zu unterstützen, müssen Sie DNS bereitstellen, um den Pool-FQDN (z. B. pool01.contoso.com) in die IP-Adressen aller Server im Pool aufzulösen (z. B. 192.168.1.1, 192.168.1.2 usw.). Sie sollten nur die IP-Adressen von Servern angeben, die derzeit bereitgestellt werden.
Vorsicht
Wenn Sie über mehrere Front-End-Pools oder Front-End-Server verfügen, muss der FQDN für externe Webdienste eindeutig sein. Wenn Sie beispielsweise den FQDN für externe Webdienste eines Front-End-Servers als pool01.contoso.com definieren, können Sie pool01.contoso.com nicht für einen anderen Front-End-Pool oder Front-End-Server verwenden. Wenn Sie auch Directors bereitstellen, muss der für jeden Director- oder Director-Pool definierte FQDN für externe Webdienste von jedem anderen Director- oder Director-Pool sowie jedem Front-End-Pool oder Front-End-Server eindeutig sein. Wenn Sie entscheiden, die internen Webdienste mit einem selbstdefinierten FQDN zu überschreiben, muss jeder FQDN von jedem anderen Front-End-Pool, Director oder einem Director-Pool eindeutig sein.
DNS-Lastenausgleich für Edgeserverpools
Sie können den DNS-Lastenausgleich in Edgeserverpools bereitstellen. Wenn Sie dies tun, müssen Sie einige Überlegungen berücksichtigen.
Die Verwendung des DNS-Lastenausgleichs auf Ihren Edgeservern führt in den folgenden Szenarien zu einem Verlust der Failoverfähigkeit:
Verbund mit Organisationen, die Versionen von Skype for Business Server ausführen, die vor Lync Server 2010 veröffentlicht wurden.
Chatnachrichtenaustausch mit Benutzern der öffentlichen Instant Messaging-Dienste AOL und Yahoo!, zusätzlich zu XMPP-basierten Anbietern und Servern, wie Google Talk, derzeit der einzige unterstützte XMPP-Partner.
Diese Szenarien funktionieren, solange alle Edgeserver im Pool ausgeführt werden, aber wenn ein Edgeserver nicht verfügbar ist, schlagen alle Anforderungen für diese Szenarien, die an ihn gesendet werden, fehl, anstatt an einen anderen Edgeserver zu routingen.
Wenn Sie Exchange UM verwenden, müssen Sie mindestens Exchange 2013 verwenden, um Unterstützung für Skype for Business Server DNS-Lastenausgleich auf Edge zu erhalten. Wenn Sie eine frühere Version von Exchange verwenden, verfügen Ihre Remotebenutzer nicht über Failoverfunktionen für diese Exchange UM-Szenarien:
Wiedergeben der Enterprise-Voicemail auf dem Handy
Übertragen von Anrufen von einer automatischen Exchange UM-Telefonzentrale
Alle anderen Exchange UM-Szenarien funktionieren ordnungsgemäß.
Für die interne Edgeschnittstelle und die externe Edgeschnittstelle muss derselbe Typ von Lastenausgleich verwendet werden. Es ist nicht möglich, für eine Edgeschnittstelle den DNS-Lastenausgleich und für die andere Edgeschnittstelle ein Hardwaregerät zum Lastenausgleich zu verwenden.
Bereitstellen des DNS-Lastenausgleichs in Edgeserverpools
Zum Bereitstellen des DNS-Lastenausgleichs auf der externen Schnittstelle Ihres Edgeserverpools benötigen Sie die folgenden DNS-Einträge:
Für den Access Edge-Dienst benötigen Sie einen Eintrag für jeden Server im Pool. Jeder Eintrag muss den FQDN des Zugriffs-Edgediensts (z. B. sip.contoso.com) in die IP-Adresse des Zugriffs-Edgediensts auf einem der Edgeserver im Pool auflösen.
Für den Webkonferenz-Edgedienst benötigen Sie einen Eintrag für jeden Server im Pool. Jeder Eintrag muss den FQDN des Webkonferenz-Edgediensts (z. B. webconf.contoso.com) in die IP-Adresse des Webkonferenz-Edgediensts auf einem der Edgeserver im Pool auflösen.
Für den Audio/Video Edge-Dienst benötigen Sie einen Eintrag für jeden Server im Pool. Jeder Eintrag muss den FQDN des Audio/Video-Edgediensts (z. B. av.contoso.com) in die IP-Adresse des A/V-Edgediensts auf einem der Edgeserver im Pool auflösen.
Zum Bereitstellen des DNS-Lastenausgleichs auf der internen Schnittstelle Ihres Edgeserverpools müssen Sie einen DNS A-Eintrag hinzufügen, der den internen FQDN des Edgeserverpools in die IP-Adresse jedes Servers im Pool auflöst.
Verwenden des DNS-Lastenausgleichs in Vermittlungsserverpools
Sie können den DNS-Lastenausgleich für eigenständige Vermittlungsserverpools verwenden. Der gesamte SIP- und Mediendatenverkehr wird durch den DNS-Lastenausgleich ausgeglichen.
Zum Bereitstellen des DNS-Lastenausgleichs in einem Vermittlungsserverpool müssen Sie DNS bereitstellen, um den FQDN des Pools (z. B. mediationpool1.contoso.com) in die IP-Adressen aller Server im Pool aufzulösen (z. B. 192.168.1.1, 192.168.1.2 usw.).
Blockieren von Datenverkehr zu einem Server mit DNS-Lastenausgleich
Wenn Sie den DNS-Lastenausgleich verwenden und den Datenverkehr an einen bestimmten Computer blockieren müssen, reicht es nicht aus, einfach nur die IP-Adresseinträge aus dem Pool-FQDN zu entfernen. Sie müssen auch den DNS-Eintrag für den Computer entfernen.
Beachten Sie, dass für Server-zu-Server-Datenverkehr Skype for Business Server einen topologiefähigen Lastenausgleich verwendet. Server lesen die veröffentlichte Topologie im zentralen Verwaltungsspeicher, um die FQDNs der Server in der Topologie abzurufen und den Datenverkehr automatisch auf die Server zu verteilen. Um zu verhindern, dass ein Server Server-zu-Server-Datenverkehr empfängt, müssen Sie den Server aus der Topologie entfernen.