Ermitteln von DNS-Anforderungen für Lync Server 2013

 

Letztes Änderungsdatum des Themas: 2013-02-22

Verwenden Sie das folgende Flussdiagramm, um die DNS-Anforderungen (Domain Name System) zu bestimmen. Änderungen an der kumulativen Updates für Lync Server 2013: Februar 2013 werden dort notiert, wo sie zutreffen.

Wichtig

Microsoft Lync Server 2013 unterstützt die Verwendung der IPv6-Adressierung. Um IPv6-Adressen verwenden zu können, müssen Sie auch Unterstützung für IPv6-DNS bereitstellen und DNS-Host-AAAA-Einträge (als "Quad-A" bezeichnet) konfigurieren. In Bereitstellungen, in denen sowohl IPv4 als auch IPv6 verwendet werden, empfiehlt es sich, sowohl Host A-Einträge für IPv4 als auch AAAA für IPv6 zu konfigurieren und zu verwalten. Auch wenn Ihre Bereitstellung vollständig auf IPv6 umgestellt wurde, sind möglicherweise weiterhin IPv4-DNS-Hosteinträge erforderlich, wenn externe Benutzer noch IPv4 verwenden.

Flussdiagramm zur Ermittlung der DNS-Anforderungen

Wichtig

Standardmäßig ist der Computername eines Computers, der nicht mit einer Domäne verknüpft ist, ein Hostname, kein vollqualifizierter Domänenname (FQDN). Der Topologie-Generator verwendet FQDNs, keine Hostnamen. Daher müssen Sie ein DNS-Suffix für den Namen des Computers konfigurieren, der als Edgeserver bereitgestellt werden soll und nicht Mitglied einer Domäne ist. Verwenden Sie nur Standardzeichen (also A – Z, a – z, 0 – 9 und Bindestriche) beim Zuweisen von FQDNs der Server mit Lync Server, Edgeserver und Pools. Verwenden Sie keine Unicode-Zeichen oder Unterstriche. Andere als die genannten Zeichen in einem FQDN werden von externen DNS und öffentlichen Zertifizierungsstellen (wenn der FQDN dem SN im Zertifikat zugewiesen werden muss) häufig nicht unterstützt. Weitere Informationen finden Sie unter Konfigurieren von DNS-Hosteinträgen für Lync Server 2013.

Suchen von Diensten durch Lync-Clients

Microsoft Lync 2010, Lync 2013 und Lync Mobile ähneln sich darin, wie der Client Dienste in Lync Server 2013 findet und auf diese zugreift. Die wichtige Ausnahme ist die Lync Windows Store-App, die einen anderen Dienststandortprozess verwendet. In diesem Abschnitt werden zwei Szenarien beschrieben, in denen die Clients Dienste suchen: zunächst die herkömmliche Methode mit einer Reihe von SRV- und A-Hostdatensätzen, zum anderen die Verwendung der AutoErmittlungsdienstdatensätze. Kumulative Updates für die Desktopclients ändern den DNS-Standortprozess von Lync Server 2010 Für alle Clients wird der DNS-Abfrageprozess fortgesetzt, bis eine erfolgreiche Abfrage zurückgegeben wird oder die Liste der möglichen DNS-Einträge erschöpft ist und der letzte Fehler an den Client zurückgegeben wird.

Für alle Clients mit Ausnahme der Lync Windows Store-App Während der DNS-Suche werden SRV-Einträge abgefragt und in der folgenden Reihenfolge an den Client zurückgegeben:

1. lyncdiscoverinternal.<Domänen-A-Eintrag> (Host) für den AutoErmittlungsdienst in den internen Webdiensten

2. lyncDiscover.<Domänen-A-Eintrag> (Host) für den AutoErmittlungsdienst in den externen Webdiensten

3. _sipinternaltls._tcp.<Domänen-SRV-Eintrag> (Dienstlocator) für interne TLS-Verbindungen

4. _sipinternal._tcp.<Domänen-SRV-Eintrag> (Dienstlocator) für interne TCP-Verbindungen (wird nur ausgeführt, wenn TCP zulässig ist)

5. _sip._tls.<Domänen-SRV-Eintrag> (Dienstlocator) für externe TLS-Verbindungen

6. sipinternal.<Domänendatensatz> (Host) für den Front-End-Pool oder Director, der nur im internen Netzwerk aufgelöst werden kann

7. nippen.<Domänen-A-Eintrag> (Host) für den Front-End-Pool oder Director im internen Netzwerk oder den Access Edge-Dienst, wenn der Client extern ist

8. sipexternal.<Domänen-A-Eintrag> (Host) für den Access Edge-Dienst, wenn der Client extern ist

Die Lync Windows Store-App ändert den Prozess vollständig, da sie zwei Datensätze verwendet:

1. lyncdiscoverinternal.<Domänen-A-Eintrag> (Host) für den AutoErmittlungsdienst in den internen Webdiensten

2. lyncDiscover.<Domänen-A-Eintrag> (Host) für den AutoErmittlungsdienst in den externen Webdiensten

Es gibt kein Fallback auf die anderen Datensatztypen.

Der Unterschied zwischen den Methoden, die für neuere Clients im Vergleich zu älteren Clients verwendet werden, besteht darin, dass der AutoErmittlungsdienst zur bevorzugten Methode wird, um alle Dienste zu finden.

Wenn eine Verbindung erfolgreich hergestellt wird, gibt der AutoErmittlungsdienst alle Webdienst-URLs für den Basispool des Benutzers zurück, einschließlich des Mobility Service (bekannt als Mcx durch das virtuelle Verzeichnis, das für den Dienst in IIS erstellt wurde), Microsoft Lync Web App und Webplaner-URLs. Sowohl die interne Mobility Service-URL als auch die externe Mobility Service-URL sind jedoch dem externen Webdienst-FQDN zugeordnet. Daher stellt das Gerät unabhängig davon, ob ein mobiles Gerät intern oder außerhalb des Netzwerks ist, immer eine externe Verbindung mit dem Mobilitätsdienst über den Reverseproxy her.

Wenn die kumulative Updates für Lync Server 2013: Februar 2013 installiert wurde, gibt der AutoErmittlungsdienst auch Verweise auf Internal/UCWA, External/UCWA und UCWA zurück. Diese Einträge beziehen sich auf die UCWA-Webkomponente (Unified Communications Web API). Derzeit wird nur der Eintrag UCWA verwendet und stellt einen Verweis auf eine URL für die Webkomponente bereit. UCWA wird von Lync 2013 Mobile-Clients anstelle des Mcx Mobility Service verwendet, der von den Lync 2010 Mobile-Clients verwendet wird.

Hinweis

Beachten Sie beim Erstellen von SRV-Einträgen, dass sie auf einen DNS-A- und AAAA-Eintrag (bei Verwendung der IPv6-Adressierung) in derselben Domäne verweisen müssen, in der der DNS-SRV-Eintrag erstellt wird. Wenn sich der SRV-Eintrag beispielsweise in contoso.com befindet, weist der A- und AAAA-Datensatz (bei Verwendung der IPv6-Adressierung) darauf hin, dass er sich nicht in fabrikam.com befinden kann.

Tipp

Die Standardkonfiguration besteht darin, den gesamten mobilen Clientdatenverkehr über den externen Standort zu leiten. Sie können Einstellungen so ändern, dass nur die interne URL zurückgegeben wird, wenn dies Ihren Anforderungen besser entspricht. Mit dieser Konfiguration können Benutzer mobile Lync-Anwendungen nur dann auf ihren mobilen Geräten verwenden, wenn sie sich innerhalb des Unternehmensnetzwerks befinden. Um diese Konfiguration zu definieren, verwenden Sie das Cmdlet Set-CsMcxConfiguration .

Hinweis

Obwohl mobile Anwendungen auch eine Verbindung mit anderen Lync Server 2013-Diensten wie dem Adressbuchdienst herstellen können, werden interne Webanforderungen für mobile Anwendungen nur für den Mobility Service an den externen Web-FQDN gesendet. Andere Dienstanforderungen, z. B. Adressbuchanforderungen, erfordern diese Konfiguration nicht.

Mobile Geräte unterstützen die manuelle Ermittlung von Diensten. In diesem Fall muss jeder Benutzer die Einstellungen für mobile Geräte wie folgt mit den vollständigen internen und externen AutoErmittlungsdienst-URIs konfigurieren, einschließlich protokoll und Pfad:

• <https:// ExtPoolFQDN>/Autodiscover/autodiscoverservice.svc/Root für externen Zugriff

• <https:// IntPoolFQDN>/AutoDiscover/AutoDiscover.svc/Root für internen Zugriff

Es wird empfohlen, die automatische Ermittlung anstelle der manuellen Ermittlung zu verwenden. Manuelle Einstellungen können jedoch nützlich sein, um Konnektivitätsprobleme mit mobilen Geräten zu beheben.

Konfigurieren von Split-Brain DNS mit Lync Server

Split-Brain-DNS ist durch eine Reihe von Namen bekannt, z. B. Split-DNS oder Split-Horizon-DNS. Es beschreibt einfach eine DNS-Konfiguration, bei der zwei DNS-Zonen mit demselben Namespace vorhanden sind– aber eine DNS-Zone nur interne Anforderungen und die anderen DNS-Zonen nur externe Anforderungen verarbeiten. Viele der DNS-SRV- und A-Einträge, die im internen DNS enthalten sind, sind jedoch nicht im externen DNS enthalten, und das Gegenteil ist ebenfalls der Fall. In Fällen, in denen derselbe DNS-Eintrag sowohl im internen als auch im externen DNS vorhanden ist (z. B www.contoso.com. ), unterscheidet sich die zurückgegebene IP-Adresse je nachdem, wo (intern oder extern) die Abfrage initiiert wurde.

Wichtig

Derzeit wird Split-Brain DNS nicht für die Mobilität unterstützt, genauer gesagt für die DNS-Einträge LyncDiscover und LyncDiscoverInternal. LyncDiscover muss auf einem externen DNS-Server und LyncDiscoverInternal auf einem internen DNS-Server definiert werden.

Für die Zwecke dieser Themen wird der Begriff Split-Brain-DNS verwendet.

Wenn Sie Split-Brain-DNS konfigurieren, enthält die folgende interne und externe Zone eine Zusammenfassung der Typen von DNS-Einträgen, die in jeder Zone erforderlich sind. Weitere Informationen finden Sie unter Szenarien für den Zugriff externer Benutzer in Lync Server 2013.

Internes DNS:

• Enthält eine DNS-Zone namens contoso.com, für die sie autoritativ ist.

• Die interne contoso.com Zone enthält Folgendes:

  • DNS-A- und AAAA-Einträge (bei Verwendung der IPv6-Adressierung) und SRV-Einträge für die automatische Konfiguration des internen Lync Server 2013-Clients (optional)

  • DNS-A- und AAAA-Einträge (bei Verwendung der IPv6-Adressierung) oder CNAME-Einträge für die automatische Ermittlung von Lync Server 2013-Webdiensten (optional)

  • DNS-A- und AAAA-Einträge (wenn Sie die IPv6-Adressierung verwenden) für Den Namen des Front-End-Pools, den Namen des Director- oder Director-Pools und alle internen Server, auf denen Lync Server 2013 im Unternehmensnetzwerk ausgeführt wird

  • DNS-A- und AAAA-Einträge (bei Verwendung der IPv6-Adressierung) für die interne Edge-Schnittstelle jedes Lync Server 2013-Edgeservers im Umkreisnetzwerk

  • DNS-A- und AAAA-Einträge (bei Verwendung der IPv6-Adressierung) für die interne Schnittstelle jedes Reverseproxyservers im Umkreisnetzwerk (optional für die Verwaltung des Reverseproxys)

  • Alle internen Edgeschnittstellen des Lync Server 2013-Edgeservers im Umkreisnetzwerk verwenden die interne DNS-Zone zum Auflösen von Abfragen in contoso.com

  • Alle Server mit Lync Server 2013 und Clients, auf denen Lync 2013 im Unternehmensnetzwerk ausgeführt wird, verweisen auf die internen DNS-Server zum Auflösen von Abfragen in contoso.com oder zur Verwendung der HOSTS-Datei auf jedem Edgeserver und listen A- und AAAA-Einträge (wenn Sie die IPv6-Adressierung verwenden) für den Server des nächsten Hops auf, insbesondere die Director- oder Director-VIP. Front-End-Pool-VIP oder Standard Edition-Server

Externes DNS:

• Enthält eine DNS-Zone namens contoso.com, für die sie autoritativ ist.

• Die externe contoso.com Zone enthält Folgendes:

  • DNS-A- und AAAA-Einträge (bei Verwendung der IPv6-Adressierung) und SRV-Einträge für die automatische Konfiguration des Lync Server 2013-Clients (optional)

  • DNS-A- und AAAA-Einträge (bei Verwendung der IPv6-Adressierung) oder CNAME-Einträge für die automatische Ermittlung von Lync Server 2013-Webdiensten für die Verwendung mit Mobilität

  • DNS-A- und AAAA-Einträge (bei Verwendung der IPv6-Adressierung) und SRV-Einträge für die externe Edge-Schnittstelle jeder Lync Server 2013-, Edgeserver- oder Hardwarelastenausgleichs-IP (VIP) im Umkreisnetzwerk

  • DNS-A- und AAAA-Einträge (bei Verwendung der IPv6-Adressierung) für die externe Schnittstelle des Reverseproxyservers oder der VIP für einen Pool von Reverseproxyservern im Umkreisnetzwerk

Automatische Konfiguration ohne Split-Brain DNS

Mithilfe von Split-Brain-DNS kann ein Lync Server 2013-Benutzer, der sich intern anmeldet, die automatische Konfiguration nutzen, wenn die interne DNS-Zone einen _sipinternaltls._tcp-SRV-Eintrag für jede verwendete SIP-Domäne enthält. Wenn Sie jedoch kein Split-Brain-DNS verwenden, funktioniert die interne automatische Konfiguration von Clients, auf denen Lync ausgeführt wird, nur, wenn eine der weiter unten in diesem Abschnitt beschriebenen Problemumgehungen implementiert ist. Dies liegt daran, dass Lync Server 2013 erfordert, dass der SIP-URI des Benutzers mit der Domäne des Front-End-Pools übereinstimmt, der für die automatische Konfiguration bestimmt ist. Dies war auch bei früheren Versionen von Communicator der Fall.

Wenn Sie beispielsweise zwei SIP-Domänen verwenden, sind die folgenden DNS-Diensteinträge (SRV) erforderlich:

• Wenn sich ein Benutzer als bob@contoso.com der folgende SRV-Eintrag anmeldet, funktioniert die automatische Konfiguration, da die SIP-Domäne (contoso.com) des Benutzers mit der Domäne des Front-End-Pools für die automatische Konfiguration übereinstimmt:

   _sipinternaltls._tcp.contoso.com. 86400 IN SRV 0 0 5061 pool01.contoso.com

• Wenn sich ein Benutzer als alice@fabrikam.com der folgende DNS-SRV-Eintrag anmeldet, funktioniert die automatische Konfiguration der zweiten SIP-Domäne.

   _sipinternaltls._tcp.fabrikam.com. 86400 IN SRV 0 0 5061 pool01.fabrikam.com

Wenn sich ein Benutzer als tim@litwareinc.com der folgende DNS-SRV-Eintrag anmeldet, funktioniert die automatische Konfiguration nicht, da die SIP-Domäne (litwareinc.com) des Clients nicht mit der Domäne übereinstimmt, in der sich der Pool befindet (fabrikam.com):

 _sipinternaltls._tcp.litwareinc.com. 86400 IN SRV 0 0 5061 pool01.fabrikam.com

Wenn für Clients, auf denen Lync ausgeführt wird, eine automatische Konfiguration erforderlich ist, wählen Sie eine der folgenden Optionen aus:

• Gruppenrichtlinie Objekte Verwenden Sie Gruppenrichtlinie-Objekte (GPOs), um die richtigen Serverwerte aufzufüllen.

  Hinweis

  Diese Option aktiviert keine automatische Konfiguration, aber sie automatisiert den Prozess der manuellen Konfiguration. Wenn dieser Ansatz verwendet wird, sind die SRV-Einträge, die der automatischen Konfiguration zugeordnet sind, nicht erforderlich.

• Übereinstimmende interne Zone Erstellen Sie eine Zone im internen DNS, die der externen DNS-Zone entspricht (z. B. contoso.com), und erstellen Sie DNS A- und AAAA-Einträge (wenn Sie die IPv6-Adressierung verwenden), die dem lync Server 2013-Pool entsprechen, der für die automatische Konfiguration verwendet wird. Wenn z. B. ein Benutzer auf pool01.contoso.net sich aber als bob@contoso.comanmeldet, erstellen Sie eine interne DNS-Zone namens contoso.com, und erstellen Sie darin einen DNS-A- und AAAA-Eintrag (wenn die IPv6-Adressierung verwendet wird) für pool01.contoso.com.

• Interne Pin-Point-Zone Wenn Sie eine gesamte Zone im internen DNS erstellen, ist keine Option, können Sie Pin-Point-Zonen (d. h. dedizierte Zonen) erstellen, die den SRV-Einträgen entsprechen, die für die automatische Konfiguration erforderlich sind, und diese Zonen mit dnscmd.exe auffüllen. Dnscmd.exe ist erforderlich, da die DNS-Benutzeroberfläche die Erstellung von Pin-Point-Zonen nicht unterstützt. Wenn die SIP-Domäne beispielsweise contoso.com ist und Sie über einen Front-End-Pool namens pool01 verfügen, der zwei Front-End-Server enthält, benötigen Sie die folgenden Pin-Point-Zonen und A-Einträge in Ihrem internen DNS:

  dnscmd . /zoneadd _sipinternaltls._tcp.contoso.com. /dsprimary
  dnscmd . /recordadd _sipinternaltls._tcp.contoso.com. @ SRV 0 0 5061 pool01.contoso.com.
  dnscmd . /zoneadd pool01.contoso.com. /dsprimary
  dnscmd . /recordadd pool01.contoso.com. @ A 192.168.10.90
  dnscmd . /recordadd pool01.contoso.com. @ AAAA <IPv6 address>
  dnscmd . /recordadd pool01.contoso.com. @ A 192.168.10.91 
  dnscmd . /recordadd pool01.contoso.com. @ AAAA <IPv6 address>
  

  Wenn Ihre Umgebung eine zweite SIP-Domäne (z. B. fabrikam.com) enthält, benötigen Sie die folgenden Pin-Point-Zonen und A-Einträge in Ihrem internen DNS:

  dnscmd . /zoneadd _sipinternaltls._tcp.fabrikam.com. /dsprimary
  dnscmd . /recordadd _sipinternaltls._tcp.fabrikam.com. @ SRV 0 0 5061 pool01.fabrikam.com.
  dnscmd . /zoneadd pool01.fabrikam.com. /dsprimary
  dnscmd . /recordadd pool01.fabrikam.com. @ A 192.168.10.90
  dnscmd . /recordadd pool01.contoso.com. @ AAAA <IPv6 address>
  dnscmd . /recordadd pool01.fabrikam.com. @ A 192.168.10.91
  dnscmd . /recordadd pool01.contoso.com. @ AAAA <IPv6 address>
  

Hinweis

Der FQDN des Front-End-Pools wird zweimal angezeigt, jedoch mit zwei unterschiedlichen IP-Adressen. Dies liegt daran, dass DNS-Lastenausgleich verwendet wird, aber wenn Hardwarelastenausgleich verwendet wird, gibt es nur einen einzelnen Front-End-Pooleintrag. Außerdem ändern sich die FQDN-Werte des Front-End-Pools zwischen dem contoso.com Beispiel und dem fabrikam.com Beispiel, aber die IP-Adressen bleiben unverändert. Dies liegt daran, dass Benutzer, die sich von einer sip-Domäne anmelden, denselben Front-End-Pool für die automatische Konfiguration verwenden.

Ausführliche Informationen finden Sie im DMTF-Blogartikel "Communicator Automatic Configuration and Split-Brain DNS" (Communicator Automatic Configuration and Split-Brain DNS) unter https://go.microsoft.com/fwlink/p/?linkId=200707.

Hinweis

Die Inhalte der Blogs und die zugehörige URL können ohne vorherige Ankündigung geändert werden.

Konfigurieren des Domain Name System (DNS) für die Notfallwiederherstellung

Um DNS für die Umleitung von Lync Server 2013-Webdatenverkehr an Ihre Notfallwiederherstellungs- und Failoverstandorte zu konfigurieren, müssen Sie einen DNS-Anbieter verwenden, der GeoDNS unterstützt. Sie können Ihre DNS-Einträge für Web einrichten, um die Notfallwiederherstellung zu unterstützen, sodass Features, die Webdienste verwenden, auch dann fortgesetzt werden, wenn ein vollständiger Front-End-Pool ausfällt. Dieses Feature für die Notfallwiederherstellung unterstützt die AutoErmittlung (LyncDiscover-URL), einfache URLs für Besprechungen und Einwahlen.

Sie definieren und konfigurieren zusätzliche DNS-Hosteinträge (A und AAAA bei Verwendung von IPv6) für die interne und externe Auflösung von Webdiensten bei Ihrem GeoDNS-Anbieter. Bei den folgenden Details wird davon ausgegangen, dass poolpaare, geografisch verteilte Pools und GeoDNS von Ihrem Anbieter entweder mit Roundrobin-DNS unterstützt werden oder für die Verwendung von Pool1 als primär konfiguriert sind, und im Falle eines Kommunikationsausfalls oder eines Hardwarefehlers ein Failover auf Pool2 ausgeführt wird.

GeoDNS-Datensatz (Beispiel)	Pooldatensätze (Beispiel)	CNAME-Einträge (Beispiel)	DNS-Einstellungen (wählen Sie eine Option aus)
Meet-int.geolb.contoso.com	Pool1InternalWebFQDN.contoso.com Pool2InternalWebFQDN.contoso.com	Meet.contoso.com-Alias für Pool1InternalWebFQDN.contoso.com Meet.contoso.com-Alias für Pool2InternalWebFQDN.contoso.com	Roundrobin zwischen Pools Primäres Verwenden, Herstellen einer Verbindung mit dem sekundären Replikat bei Einem Fehler
Meet-ext.geolb.contoso.com	Pool1ExternalWebFQDN.contoso.com Pool2ExternalWebFQDN.contoso.com	Meet.contoso.com-Alias für Pool1ExternalWebFQDN.contoso.com Meet.contoso.com-Alias für Pool2ExternalWebFQDN.contoso.com	Roundrobin zwischen Pools Primäres Verwenden, Herstellen einer Verbindung mit dem sekundären Replikat bei Einem Fehler
Dialin-int.geolb.contoso.com	Pool1InternalWebFQDN.contoso.com Pool2InternalWebFQDN.contoso.com	Dialin.contoso.com-Alias für Pool1InternalWebFQDN.contoso.com Dialin.contoso.com-Alias für Pool2InternalWebFQDN.contoso.com	Roundrobin zwischen Pools Primäres Verwenden, Herstellen einer Verbindung mit dem sekundären Replikat bei Einem Fehler
Dialin-ext.geolb.contoso.com	Pool1ExternalWebFQDN.contoso.com Pool2ExternalWebFQDN.contoso.com	Dialin.contoso.com-Alias für Pool1ExternalWebFQDN.contoso.com Dialin.contoso.com-Alias für Pool2ExternalWebFQDN.contoso.com	Roundrobin zwischen Pools Primäres Verwenden, Herstellen einer Verbindung mit dem sekundären Replikat bei Einem Fehler
Lyncdiscoverint-int.geolb.contoso.com	Pool1InternalWebFQDN.contoso.com Pool2InternalWebFQDN.contoso.com	Lyncdiscoverinternal.contoso.com-Alias für Pool1InternalWebFQDN.contoso.com Lyncdiscoverinternal.contoso.com-Alias für Pool2InternalWebFQDN.contoso.com	Roundrobin zwischen Pools Primäres Verwenden, Herstellen einer Verbindung mit dem sekundären Replikat bei Einem Fehler
Lyncdiscover-ext.geolb.contoso.com	Pool1ExternalWebFQDN.contoso.com Pool2ExternalWebFQDN.contoso.com	Lyncdiscover.contoso.com-Alias für Pool1ExternalWebFQDN.contoso.com Lyncdiscover.contoso.com-Alias für Pool2ExternalWebFQDN.contoso.com	Roundrobin zwischen Pools Primäres Verwenden, Herstellen einer Verbindung mit dem sekundären Replikat bei Einem Fehler
Scheduler-int.geolb.contoso.com	Pool1InternalWebFQDN.contoso.com Pool2InternalWebFQDN.contoso.com	Scheduler.contoso.com-Alias für Pool1InternalWebFQDN.contoso.com Scheduler.contoso.com-Alias für Pool2InternalWebFQDN.contoso.com	Roundrobin zwischen Pools Primäres Verwenden, Herstellen einer Verbindung mit dem sekundären Replikat bei Einem Fehler
Scheduler-ext.geolb.contoso.com	Pool1ExternalWebFQDN.contoso.com Pool2ExternalWebFQDN.contoso.com	Scheduler.contoso.com-Alias für Pool1ExternalWebFQDN.contoso.com Scheduler.contoso.com-Alias für Pool2ExternalWebFQDN.contoso.com	Roundrobin zwischen Pools Primäres Verwenden, Herstellen einer Verbindung mit dem sekundären Replikat bei Einem Fehler

DNS Load Balancing

DER DNS-Lastenausgleich wird in der Regel auf Anwendungsebene implementiert. Die Anwendung (z. B. ein Client, auf dem Lync ausgeführt wird) 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 Lync ausführen, fragen DNS für 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 Lync Server 2013 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)" http://www.ietf.org/rfc/rfc2782.txt gibt an, dass, wenn mehrere DNS SRV-Einträge definiert sind, zuerst prioritäts- und dann 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.