Ermitteln von DNS-Anforderungen für Lync Server 2013
Letzte Änderung: 22.02.2013
Verwenden Sie das folgende Flussdiagramm, um DNS-Anforderungen (Domain Name System) zu ermitteln. Änderungen für die kumulativen Aktualisierungen für Lync Server 2013: Februar 2013 werden dort vermerkt, wo sie gelten.
Wichtig
Microsoft Lync Server 2013 unterstützt die Verwendung von IPv6-Adressen. 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 Host-AAAA für IPv6 zu konfigurieren und zu verwalten. Auch wenn Ihre Bereitstellung vollständig auf IPv6 umgestellt wurde, sind IPv4-DNS-Hosteinträge möglicherweise weiterhin erforderlich, wenn externe Benutzer weiterhin IPv4 verwenden.
Bestimmen des Flussdiagramms für DNS-Anforderungen
.jpg "175782ac-363e-408a-912f-8991bf152970")
Wichtig
Standardmäßig ist der Computername eines Computers, der keiner Domäne beigetreten ist, ein Hostname und kein vollqualifizierter Domänenname (Fully Qualified Domain Name, 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
So finden Lync-Clients Dienste
Microsoft Lync 2010, Lync 2013 und Lync Mobile ähneln sich dabei, wie der Client Dienste in Lync Server 2013 findet und darauf zugreift. Die wichtige Ausnahme ist die Lync Windows Store-App, die einen anderen Dienstspeicherortprozess verwendet. In diesem Abschnitt werden zwei Szenarien beschrieben, in dem die Clients Dienste suchen, zum einen die herkömmliche Methode mit einer Reihe von SRV- und A-Hostdatensätzen, zum anderen nur die AutoErmittlungsdiensteinträge. 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 endgültige 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:
lyncdiscoverinternal.< Domänen-A-Eintrag> (Host) für den AutoErmittlungsdienst in den internen Webdiensten
lyncdiscover.< Domänen-A-Eintrag> (Host) für den AutoErmittlungsdienst in den externen Webdiensten
_sipinternaltls._tcp.< Domänen-SRV-Eintrag> (Service Locator) für interne TLS-Verbindungen
_sipinternal._tcp.< Domänen-SRV-Eintrag> (Dienstlocator) für interne TCP-Verbindungen (nur ausgeführt, wenn TCP zulässig ist)
_sip._tls.< Domänen-SRV-Eintrag> (Service Locator) für externe TLS-Verbindungen
sipinternal.< Domänen-A-Eintrag> (Host) für den Front-End-Pool oder Director, der nur im internen Netzwerk aufgelöst werden kann
Sip.< 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
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 zwei Datensätze verwendet werden:
lyncdiscoverinternal.< Domänen-A-Eintrag> (Host) für den AutoErmittlungsdienst in den internen Webdiensten
lyncdiscover.< Domänen-A-Eintrag> (Host) für den AutoErmittlungsdienst in den externen Webdiensten
Es gibt keinen Fallback zu den 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 ist, gibt der AutoErmittlungsdienst alle Webdienst-URLs für den Startpool des Benutzers zurück, einschließlich des Mobilitätsdiensts (bekannt als Mcx durch das virtuelle Verzeichnis, das für den Dienst in IIS erstellt wurde), Microsoft Lync Web App- und Webplaner-URLs. Die interne Mobilitätsdienst-URL und die externe Mobilitätsdienst-URL sind jedoch dem externen Webdienste-FQDN zugeordnet. Daher stellt das Gerät unabhängig davon, ob es sich um ein internes oder ein externes Gerät im Netzwerk handelt, immer über den Reverseproxy eine externe Verbindung mit dem Mobilitätsdienst her.
Wenn die kumulative Aktualisierungen 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 Unified Communications Web API (UCWA)-Webkomponente. 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
Beim Erstellen von SRV-Einträgen ist es wichtig zu beachten, dass sie auf einen DNS A- und AAAA-Eintrag (wenn Sie IPv6-Adressierung verwenden) 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, können sich der A- und AAAA-Eintrag (wenn Sie IPv6-Adressierung verwenden) nicht in fabrikam.com befinden.
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 für Ihre Anforderungen besser geeignet ist. 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 herstellen können, z. B. adressbuchdienst, gehen interne Webanforderungen für mobile Anwendungen nur für den Mobilitätsdienst an den externen Web-FQDN. Für andere Dienstanforderungen, z. B. Adressbuchanforderungen, ist diese Konfiguration nicht erforderlich.
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 URIs des AutoErmittlungsdiensts 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 Erkennung anstelle der manuellen Ermittlung zu verwenden. Manuelle Einstellungen können jedoch hilfreich sein, um Probleme mit der Konnektivität mobiler Geräte zu beheben.
Konfigurieren 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 es zwei DNS-Zonen mit demselben Namespace gibt – aber eine nur interne DNS-Zonendienste-Anforderungen und die anderen nur externen DNS-Zonendienste-Anforderungen. Viele der DNS SRV- und A-Einträge, die im internen DNS enthalten sind, sind jedoch nicht im externen DNS enthalten, und umgekehrt. 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 für die Mobilität oder genauer gesagt für die DNS-Einträge LyncDiscover und LyncDiscoverInternal nicht unterstützt. 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. Ausführliche 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:
DNS A- und AAAA-Einträge (wenn Sie IPv6-Adressierung verwenden) und SRV-Einträge für interne Lync Server 2013-Client-Autokonfiguration (optional)
DNS A- und AAAA-Einträge (wenn Sie IPv6-Adressierung verwenden) oder CNAME-Einträge für die automatische Ermittlung von Lync Server 2013-Webdiensten (optional)
DNS A- und AAAA-Einträge (wenn Sie IPv6-Adressierung verwenden) für den Front-End-Poolnamen, den Director- oder Directorpoolnamen und alle internen Server, auf denen Lync Server 2013 im Unternehmensnetzwerk ausgeführt wird
DNS A- und AAAA-Einträge (wenn Sie IPv6-Adressierung verwenden) für die interne Edgeschnittstelle jedes Lync Server 2013- und Edgeservers im Umkreisnetzwerk
DNS A- und AAAA-Einträge (wenn Sie IPv6-Adressierung verwenden) 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 an contoso.com
Alle Server, auf denen Lync Server 2013 ausgeführt wird, und Clients, auf denen Lync 2013 im Unternehmensnetzwerk ausgeführt wird, verweisen auf die internen DNS-Server zum Auflösen von Abfragen an contoso.com oder die Verwendung der HOSTS-Datei auf jedem Edgeserver und listen A- und AAAA-Einträge (wenn Sie IPv6-Adressierung verwenden) für den nächsten Hopserver auf, insbesondere den 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:
DNS A- und AAAA-Einträge (wenn Sie IPv6-Adressierung verwenden) und SRV-Einträge für die automatische Konfiguration des Lync Server 2013-Clients (optional)
DNS A- und AAAA-Einträge (wenn Sie IPv6-Adressierung verwenden) 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 (wenn Sie IPv6-Adressierung verwenden) und SRV-Einträge für die externe Edgeschnittstelle jeder Lync Server 2013-, Edgeserver- oder Hardwarelastenausgleichs-VIRTUELLE IP (VIP) im Umkreisnetzwerk
DNS A- und AAAA-Einträge (wenn Sie IPv6-Adressierung verwenden) 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 vorgesehen ist. Dies war auch bei früheren Versionen von Communicator der Fall.
Wenn beispielsweise zwei SIP-Domänen verwendet werden, wären die folgenden DNS-Diensteinträge (SRV) erforderlich:
Wenn sich ein Benutzer als bob@contoso.com folgenden SRV-Eintrag anmeldet, funktioniert dies für 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 folgenden DNS SRV-Eintrag anmeldet, funktioniert dies für die automatische Konfiguration der zweiten SIP-Domäne.
_sipinternaltls._tcp.fabrikam.com. 86400 IN SRV 0 0 5061 pool01.fabrikam.com
Zum Vergleich: Wenn sich ein Benutzer als tim@litwareinc.com folgenden 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 mit Lync 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 nicht die automatische Konfiguration, automatisiert aber 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 IPv6-Adressierung verwenden), die dem Lync Server 2013-Pool entsprechen, der für die automatische Konfiguration verwendet wird. Wenn ein Benutzer beispielsweise auf pool01.contoso.net verwaltet wird, sich aber als bob@contoso.comLync anmeldet, erstellen Sie eine interne DNS-Zone mit dem Namen contoso.com und erstellen sie darin einen DNS A- und AAAA-Eintrag (wenn 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 mithilfe von 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 enthält (z. B. fabrikam.com), 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 verschiedenen IP-Adressen. Dies liegt daran, dass der DNS-Lastenausgleich verwendet wird, bei Verwendung des Hardwarelastenausgleichs jedoch nur ein einzelner Front-End-Pooleintrag vorhanden wäre. Außerdem ändern sich die FQDN-Werte des Front-End-Pools zwischen dem contoso.com Beispiel und dem fabrikam.com Beispiel, die IP-Adressen bleiben jedoch unverändert. Dies liegt daran, dass Benutzer, die sich von einer der SIP-Domänen aus 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" 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 Domänennamensystems (DNS) für die Notfallwiederherstellung
Um DNS so zu konfigurieren, dass Lync Server 2013-Webdatenverkehr an Ihre Notfallwiederherstellungs- und Failoverstandorte umgeleitet wird, müssen Sie einen DNS-Anbieter verwenden, der GeoDNS unterstützt. Sie können Ihre DNS-Einträge für das 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 Notfallwiederherstellungsfeature unterstützt die einfachen URLs "AutoErmittlung" (Lyncdiscover-URL), "Besprechung" und "Einwahl".
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. In den folgenden Details wird davon ausgegangen, dass gekoppelte Pools, geografisch verteilt und GeoDNS, die von Ihrem Anbieter entweder mit Round-Robin-DNS unterstützt werden oder für die Verwendung von Pool1 als primär konfiguriert sind, und bei Kommunikationsverlust oder Hardwarefehlern zu Pool2 übergehen.
| GeoDNS-Eintrag (Beispiel) | Pooleinträge (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 Verwenden der primären, Herstellen einer Verbindung mit sekundären, wenn 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 Verwenden der primären, Herstellen einer Verbindung mit sekundären, wenn 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 Verwenden der primären, Herstellen einer Verbindung mit sekundären, wenn 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 Verwenden der primären, Herstellen einer Verbindung mit sekundären, wenn 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 Verwenden der primären, Herstellen einer Verbindung mit sekundären, wenn 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 Verwenden der primären, Herstellen einer Verbindung mit sekundären, wenn 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 Verwenden der primären, Herstellen einer Verbindung mit sekundären, wenn 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 Verwenden der primären, Herstellen einer Verbindung mit sekundären, wenn Fehler |
DNS Load Balancing
Der DNS-Lastenausgleich wird in der Regel auf Anwendungsebene implementiert. Die Anwendung (z. B. ein Client mit Lync) versucht, eine Verbindung mit einem Server in einem Pool herzustellen, indem eine Verbindung mit einer der IP-Adressen hergestellt wird, die von der DNS-A- und AAAA-Eintragsabfrage (wenn IPv6-Adressierung verwendet wird) für den vollqualifizierten Domänennamen (FQDN) des Pools zurückgegeben wird.
Wenn beispielsweise drei Front-End-Server in einem Pool mit dem Namen pool01.contoso.com vorhanden sind, geschieht Folgendes:
Clients, auf denen Lync-Abfrage-DNS für pool01.contoso.com ausgeführt wird. 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 vom DNS-Roundrobin (DNS RR), der sich in der Regel auf den Lastenausgleich bezieht, indem er sich auf DNS stützt, um eine andere Reihenfolge von IP-Adressen bereitzustellen, die den Servern in einem Pool entsprechen. Normalerweise aktiviert DNS RR nur die Lastverteilung, aber kein Failover. Wenn beispielsweise die Verbindung mit der von der DNS-A- und AAAA-Abfrage zurückgegebenen IP-Adresse (wenn Sie IPv6-Adressierung verwenden) fehlschlägt, schlägt die Verbindung fehl. Daher ist DAS DNS-Roundrobin allein 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 für SERVER-zu-Server-SIP zu den Edgeservern
Lastenausgleich für Unified Communications Application Services (UCAS)-Anwendungen wie die automatische Konferenzzentrale, Reaktionsgruppe und Parken von Anrufen
Verhindern neuer Verbindungen mit UCAS-Anwendungen (auch als "Draining" 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 Dokument der Internet Engineering Task Force "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ät verwendet und dann gewichtiert wird. Beispiel: DNS SRV-Eintrag A hat eine Gewichtung von 20 und eine Priorität von 40 und DNS SRV-Eintrag B eine Gewichtung von 10 und Priorität von 50. DER DNS SRV-Eintrag A mit der Priorität 40 wird ausgewählt. Die folgenden Regeln gelten für die Auswahl von DNS SRV-Einträgen:
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 derselben Priorität SOLLTEN in einer durch das Gewichtungsfeld definierten Reihenfolge ausprobiert werden.
Das Gewichtungsfeld gibt eine relative Gewichtung für Einträge mit derselben Priorität an. Größere Gewichte SOLLTEN mit einer proportional höheren 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 der Gewichtung 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.