Planen der Advanced Edge Server-Bereitstellung für Skype for Business Server
Zusammenfassung: Sehen Sie sich Szenarien für Skype for Business Server Bereitstellungsoptionen an. Dieses Thema wird Ihnen helfen, egal ob Sie einen einzelnen Server oder einen Server-Pool mit DNS oder HLB bevorzugen.
Wenn es um die Dns-Planung (Domain Name System) für Skype for Business Server geht, können viele Faktoren in Ihre Entscheidung hineinspielen. Falls die Domänenstruktur Ihrer Organisation bereits aufgebaut ist, könnte es nun darum gehen, wie Sie weiter vorgehen. Wir starten mit den folgenden Punkten:
Walkthrough of Skype for Business clients locating services
Skype for Business Clients ähneln früheren Versionen von Lync-Clients, wie sie Dienste in Skype for Business Server finden und darauf zugreifen. Der Inhalt dieses Abschnitts beschreibt das Ausfindigmachen des Servers.
lyncdiscoverinternal.<Domäne>
Dies ist ein Host-Eintrag für den AutoErmittlungsdienst in den internen Webdiensten.
lyncDiscover.<Domäne>
Dies ist ein Host-Eintrag für den AutoErmittlungsdienst in den externen Webdiensten.
_sipinternaltls._tcp.<Domäne>
Dies ist ein SRV-Eintrag für interne TLS-Verbindungen.
_sip._tls.<Domäne>
Dies ist ein SRV-Eintrag für externe TLS-Verbindungen.
sipinternal.<Domäne>
Dies ist ein A-Hostdatensatz für den Front-End-Pool oder Director, der nur im internen Netzwerk aufgelöst werden kann.
Sip.<Domäne>
Dies ist ein A-Hostdatensatz für den Front-End-Pool oder Director, der nur im internen Netzwerk aufgelöst werden kann.
sipexternal.<Domäne>
Dies ist ein A-Hostdatensatz für den Access Edge-Dienst, wenn der Client extern ist.
Der AutoErmittlungsdienst ist immer die bevorzugte Methode zur Dienstidentifizierung. Auf alle anderen Methoden wird nur zurückgegriffen, wenn es nicht anders geht.
Hinweis
Beim Erstellen von SRV-Einträgen muss berücksichtigt werden, dass die Einträge auf einen DNS-A-Eintrag (und DNS-AAAA-Eintrag, wenn Sie IPv6-Adressen nutzen) in derselben Domäne zeigen, in der der DNS-SRV-Eintrag erstellt wird. Wenn sich der SRV-Eintrag z. B. in der Domäne „contoso.com“ befindet, kann sich der A-Eintrag (und AAA-Eintrag) auf den er zeigt, nicht in der Domäne „fabrikam.com“ befinden.
Es steht Ihnen frei, Ihr Mobilgerät auf die manuelle Ermittlung von Diensten einzustellen. In diesem Fall muss jeder Benutzer in den Einstellungen des mobilen Geräts wie folgt die vollständigen internen und externen AutoErmittlungsdienst-URIs konfigurieren, einschließlich Protokoll und Pfad:
Für externen Zugriff: https://< ExtPoolFQDN>/Autodiscover/autodiscoverservice.svc/Root
Für internen Zugriff: https://< IntPoolFQDN>/AutoDiscover/AutoDiscover.svc/Root
Wir empfehlen das Verwenden einer automatischen Ermittlung anstelle einer manuellen Ermittlung. Falls Sie aber Fehlersuchen oder Tests durchführen, können die manuellen Einstellungen sehr hilfreich sein.
Split-Brain-DNS
Bei dieser DNS-Konfiguration haben Sie zwei DNS-Zonen mit denselben Namespaces. Die erste DNS-Zone ist für interne Anfragen zuständig, während sich die zweite DNS-Zone um externe Anfragen kümmert.
Warum sollte ein Unternehmen dies tun? Es kann erforderlich sein, denselben Namespace intern und extern zu verwenden, aber dies führt natürlich dazu, dass viele DNS-SRV- und A-Einträge für eine oder andere Zone eindeutig sind, und bei Duplizierung sind die ip-Adressen, die diesen Datensätzen zugeordnet sind, eindeutig.
Dies ist mit einigen Herausforderungen verbunden. Das wichtigste ist, dass Split-Brain-DNS für Mobility nicht unterstützt wird. Der Grund dafür sind die LyncDiscover- und LyncDiscoverInternal-DNS-Einträge („LyncDiscover“ muss auf einem externen DNS-Server und „LyncDiscoverInternal“ muss auf einem internen DNS-Server definiert werden).
Hier werden die DNS-Einträge für die internen und externen Zonen aufgelistet. Ausführliche Beispiele finden Sie jedoch im Abschnitt Edgeserver-Umgebungsanforderungen.
Interne DNS-Konfiguration
Enthält eine DNS-Zone namens (z. B.) „contoso.com“, für die es autoritativ ist.
Die interne „contoso.com“ enthält:
DNS-A- und AAAA-Einträge (wenn Sie die IPv6-Adressierung verwenden) für Ihren Front-End-Pool, Den Namen des Director-Pools oder Director-Pools sowie alle internen Server, die Skype for Business Server im Netzwerk Ihres organization ausgeführt werden.
DNS-A- und AAAA-Einträge (wenn Sie die IPv6-Adressierung verwenden) für Ihre interne Edge-Schnittstelle für jeden Skype for Business Server Edgeserver in Ihrem Umkreisnetzwerk.
DNS-A- und AAAA-Einträge (bei Verwendung der IPv6-Adressierung) für die interne Schnittstelle jedes Reverseproxyservers in Ihrem Umkreisnetzwerk ( optional für die Verwaltung eines Reverseproxys)
DNS-A- und AAAA-Einträge (wenn Sie die IPv6-Adressierung verwenden) und SRV-Einträge für interne Skype for Business Server automatische Clientkonfiguration (optional).
DNS-A- und AAAA-Einträge (wenn Sie die IPv6-Adressierung verwenden) oder CNAME-Einträge für die automatische Ermittlung von Skype for Business Server Webdiensten (optional).
Alle Ihre Skype for Business Server internen Edgeschnittstellen in Ihrem Umkreisnetzwerk verwenden diese interne DNS-Zone zum Auflösen von Abfragen in contoso.com.
Alle Server, auf denen Skype for Business Server ausgeführt werden, und Alle Clients, die Skype for Business Server im Unternehmensnetzwerk ausführen, verweisen auf interne DNS-Server zum Auflösen von Abfragen an contoso.com, oder sie verwenden die Hostdatei 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 (speziell für den Director- oder Director-Pool). VIP, Front-End-Pool-VIP oder Standard Edition-Server).
Externes DNS
Enthält eine DNS-Zone namens (z. B.) „contoso.com“, für die es autoritativ ist.
Die externe „contoso.com“ enthält:
DNS A und AAAA (bei Verwendung der IPv6-Adressierung) oder CNAME-Einträge zur automatischen Ermittlung von Skype for Business Server Webdiensten. Dies betrifft die Nutzung für Mobilität.
DNS-A- und AAAA-Einträge (wenn Sie die IPv6-Adressierung verwenden) und SRV-Einträge für die externe Edgeschnittstelle jedes Skype for Business Server Edgeservers oder einer HLB-VIP (Hardwarelastenausgleich) im Umkreisnetzwerk.
DNS-A- und AAAA-Einträge (wenn Sie die IPv6-Adressierung verwenden) und SRV-Einträge für die externe Schnittstelle des Reverseproxyservers oder (VIP für einen Pool von Reverseproxyservern) im Umkreisnetzwerk.
DNS-A- und AAAA-Einträge (bei Verwendung der IPv6-Adressierung) und SRV-Einträge für Skype for Business Server automatische Clientkonfiguration (optional).
Automatische Konfiguration ohne Split-Brain-DNS
Wenn Sie kein Split-Brain-DNS verwenden, funktioniert die interne automatische Konfiguration von Clients, auf denen Skype for Business ausgeführt wird, nur, wenn Sie eine der hier verfügbaren Problemumgehungen verwenden. Warum funktioniert sie nicht? Da Skype for Business Server 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 hat sich gegenüber früheren Versionen von Lync Server nicht geändert.
Wenn Sie z. B. zwei SIP-Domänen verwenden, sind die zwei folgenden DNS-SRV-Einträge erforderlich:
_sipinternaltls._tcp.contoso.com. 86400 IN SRV 0 0 5061 pool01.contoso.com
Wenn sich ein Benutzer als bob@contoso.comanmeldet, funktioniert dieser Datensatz für die automatische Konfiguration, da die SIP-Domäne des Benutzers mit der Domäne des Front-End-Pools (contoso.com) übereinstimmt.
_sipinternaltls._tcp.fabrikam.com. 86400 IN SRV 0 0 5061 pool01.fabrikam.com
Wenn sich ein Benutzer als alice@fabrikam.comanmeldet, würde dieser Datensatz für die automatische Konfiguration der zweiten Domäne funktionieren, da die SIP-Domäne mit dem Front-End-Pool für diese Domäne übereinstimmt.
Zur weiteren Veranschaulichung sei hier ein Beispiel aufgeführt, das nicht funktioniert:
_sipinternaltls._tcp.litwareinc.com. 86400 IN SRV 0 0 5061 pool01.fabrikam.com
Ein Benutzer, der sich als tim@litwareinc.com anmeldet, funktioniert nicht für die automatische Konfiguration, da seine SIP-Domäne (litwareinc.com) nicht mit der Domäne im Pool übereinstimmt (fabrikam.com).
Da wir nun alles wissen, haben Sie folgende Optionen, wenn Sie eine automatische Anforderung für Ihre Skype for Business-Clients ohne Split-Brain-DNS benötigen:
Gruppenrichtlinien
Sie können Gruppenrichtlinienobjekte zum Auffüllen der richtigen Serverwerte verwenden.
Hinweis
Mit dieser Option wird die automatische Konfiguration nicht aktiviert, der Prozess der manuellen Konfiguration wird jedoch automatisiert. Daher werden die SRV-Einträge für die automatische Konfiguration bei Verwendung dieses Ansatzes nicht benötigt.
Übereinstimmende interne Zone
Sie müssen eine Zone in Ihrem internen DNS erstellen, die Ihrer externen DNS-Zone entspricht (z. B. contoso.com), und dann DNS A-Einträge (und AAAA, wenn Sie die IPv6-Adressierung verwenden) erstellen, die dem für die automatische Konfiguration verwendeten Skype for Business Server Pool entsprechen.
Wenn Sie beispielsweise einen Benutzer haben, der sich auf pool01.contoso.net befindet, sich aber bei Skype for Business als bob@contoso.comanmeldet, erstellen Sie eine interne DNS-Zone namens contoso.com. In ihr müssen Sie einen DNS-A-Eintrag (und AAAA, wenn die IPv6-Adressierung verwendet wird) für pool01.contoso.com erstellen.
Interne dedizierte Zone
Wenn die Erstellung einer vollständigen internen DNS-Zone nicht möglich ist, können Sie dezidierte (zugeordnete) Zonen erstellen, die den für die automatische Konfiguration erforderlichen SRV-Einträgen entsprechen und diese Zonen mithilfe von „dnscmd.exe“ auffüllen. „Dnscmd.exe“ wird benötigt, da die Benutzeroberfläche für DNS das Erstellen von internen Zonen nicht unterstützt.
Wenn Ihre 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>Möglicherweise verfügen Sie über eine zweite SIP-Domäne in Ihrer Umgebung. In diesem Fall 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 DER DNS-Lastenausgleich verwendet wird. Wenn HLB verwendet wird, gibt es nur einen einzelnen Front-End-Pooleintrag.
Hinweis
Außerdem ändern sich die FQDN-Werte des Front-End-Pools zwischen den Beispielen contoso.com und fabrikam.com, aber die IP-Adressen bleiben unverändert. Das liegt daran, dass Benutzer, die sich von einer sip-Domäne aus anmelden, denselben Front-End-Pool für die automatische Konfiguration verwenden.
DNS-Notfallwiederherstellung
Um DNS so zu konfigurieren, dass Skype for Business Server 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 so einrichten, dass die Notfallwiederherstellung unterstützt wird, sodass Features, die Webdienste verwenden, auch dann fortgesetzt werden, wenn ein vollständiger Front-End-Pool ausfällt. Diese Notfallwiederherstellungsfunktion unterstützt AutoErmittlung, einfache URLs für Besprechungen und Einwahl.
Sie definieren und konfigurieren zusätzliche DNS-Host-A-Einträge (AAAA, wenn Sie IPv6 verwenden) für die interne und externe Auflösung von Webdiensten bei Ihrem GeoDNS-Anbieter. Bei den folgenden Details wird davon ausgegangen, dass die von Ihrem Anbieter unterstützte GeoDNS-Poolpaare entweder über Roundrobin-DNS verfügt oder für die Verwendung von Pool1 als primäre Instanz konfiguriert ist und ein Failover zu Pool2 ausgeführt wird, wenn kommunikations- oder stromausfall auftritt.
Alle DNS-Einträge in dieser Tabelle sind Beispiele.
| GeoDNS-Eintrag | Pool-Einträge | CNAME-Einträge | DNS-Einstellungen (wählen Sie eine Option aus) |
|---|---|---|---|
| Meet-int.geolb.contoso.com |
Pool1InternalWebFQDN.contoso.com Pool2InternalWebFQDN.contoso.com |
Meet.contoso.com zu Meet-int.geolb.contoso.com |
Roundrobin zwischen Pools ODER Primäre verwenden, bei Fehler mit der sekundären verbinden |
| Meet-ext.geolb.contoso.com |
Pool1ExternalWebFQDN.contoso.com Pool2ExternalWebFQDN.contoso.com |
Meet.contoso.com zu Meet-ext.geolb.contoso.com |
Roundrobin zwischen Pools ODER Primäre verwenden, bei Fehler mit der sekundären verbinden |
| Dialin-int.geolb.contoso.com |
Pool1InternalWebFQDN.contoso.com Pool2InternalWebFQDN.contoso.com |
Meet.contoso.com zu Meet-int.geolb.contoso.com |
Roundrobin zwischen Pools ODER Primäre verwenden, bei Fehler mit der sekundären verbinden |
| Dialin-ext.geolb.contoso.com |
Pool1ExternalWebFQDN.contoso.com Pool2ExternalWebFQDN.contoso.com |
Meet.contoso.com zu Meet-ext.geolb.contoso.com |
Roundrobin zwischen Pools ODER Primäre verwenden, bei Fehler mit der sekundären verbinden |
| Lyncdiscoverint-int.geolb.contoso.com |
Pool1InternalWebFQDN.contoso.com Pool2InternalWebFQDN.contoso.com |
Meet.contoso.com zu Meet-int.geolb.contoso.com |
Roundrobin zwischen Pools ODER Primäre verwenden, bei Fehler mit der sekundären verbinden |
| Lyncdiscover-ext.geolb.contoso.com |
Pool1ExternalWebFQDN.contoso.com Pool2ExternalWebFQDN.contoso.com |
Meet.contoso.com zu Meet-ext.geolb.contoso.com |
Roundrobin zwischen Pools ODER Primäre verwenden, bei Fehler mit der sekundären verbinden |
| Scheduler-int.geolb.contoso.com |
Pool1InternalWebFQDN.contoso.com Pool2InternalWebFQDN.contoso.com |
Meet.contoso.com zu Meet-int.geolb.contoso.com |
Roundrobin zwischen Pools ODER Primäre verwenden, bei Fehler mit der sekundären verbinden |
| Scheduler-ext.geolb.contoso.com |
Pool1ExternalWebFQDN.contoso.com Pool2ExternalWebFQDN.contoso.com |
Meet.contoso.com zu Meet-ext.geolb.contoso.com |
Roundrobin zwischen Pools ODER Primäre verwenden, bei Fehler mit der sekundären verbinden |
DNS-Lastenausgleich
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 Pool-FQDN zurückgegeben werden.
Wenn beispielsweise drei Front-End-Server in einem Pool mit dem Namen pool01.contoso.com vorhanden sind, geschieht Folgendes:
Clients, die Skype for Business ausführen, fragen DNS nach pool01.contoso.com ab. Die Anfrage gibt drei IP-Adressen zurück und speichert diese wie folgt im Zwischenspeicher (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 zu einer der IP-Adressen herzustellen. Wenn dies fehlschlägt, wird die nächste IP-Adresse versucht, die aus dieser Liste zwischengespeichert wird.
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, erhält der Benutzer eine Benachrichtigung, 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 der IP-Adressen für die Server in Ihrem Pool zu geben. In der Regel ermöglicht DNS RR die Lastverteilung, ermöglicht ihnen jedoch nicht, ein Failover zu aktivieren. Wenn beispielsweise bei der Verbindung mit der 1 IP-Adresse, die von Ihrer DNS A-Abfrage (oder AAAA in einem IPv6-Szenario) zurückgegeben wird, ein Fehler auftritt, tritt bei dieser Verbindung ein Fehler auf. Dadurch ist DIE DNS-RR weniger zuverlässig als der DNS-basierte Lastenausgleich. Sie können DNS RR weiterhin in Verbindung mit dem DNS-basierten Lastenausgleich verwenden, wenn Sie dies tun müssen.
Funktionen des DNS-Lastenausgleichs:
Lastenausgleich von Server-zu-Server-SIP auf die Edgeserver.
Lastenausgleich für Anwendungen der Unified Communications-Anwendungsdienste, z. B. automatische Konferenztelefonzentrale, Reaktionsgruppen und die Anwendung zum Parken von Anrufen.
Verhindern neuer Verbindungen mit Anwendungen der Unified Communications-Anwendungsdienste (auch als „Serverausgleich“ bekannt).
Lastenausgleich für den gesamten Client-zu-Server-Datenverkehr zwischen Clients und Edgeservern.
Keine Funktionen des DNS-Lastenausgleichs:
- Client-zu-Server-Webdatenverkehr zu Ihren Front-End-Servern oder einem Director.
Um etwas ausführlicher zu erfahren, wie ein DNS-SRV-Eintrag ausgewählt wird, wenn mehrere DNS-Einträge von einer Abfrage zurückgegeben werden, wählt der Access Edge-Dienst immer den Datensatz mit der niedrigsten numerischen Priorität und, wenn ein Tie-Breaker erforderlich ist, die höchste numerische Gewichtung aus. Dies entspricht der Dokumentation der Internet Engineering Task Force.
Wenn Ihr erster DNS-SRV-Eintrag beispielsweise eine Gewichtung von 20 und eine Priorität von 40 und Ihr zweiter DNS-SRV-Eintrag eine Gewichtung von 10 und eine Priorität von 50 hat, wird der erste Eintrag ausgewählt, da er die niedrigere Priorität von 40 hat. Priorität geht immer zuerst, und das ist der Host, auf den ein Client zuerst ausgerichtet wird. Was geschieht, wenn es zwei Ziele mit der gleichen Priorität gibt?
In diesem Fall kommt es dann auch die Gewichtung an. Größere Gewichtungen sollten mit proportional höherer Wahrscheinlichkeit gewählt werden. DNS-Administratoren sollten eine Gewichtung von 0 verwenden, wenn keine Serverauswahl getroffen werden muss. Bei Datensätzen, die Gewichtungen größer als 0 enthalten, haben Datensätze mit der Gewichtung 0 eine geringe Wahrscheinlichkeit, dass sie ausgewählt werden.
Was passiert also, wenn mehrere DNS-SRV-Einträge mit gleicher Priorität und Gewichtung zurückgegeben werden? In diesem Fall wählt der Access Edge-Dienst zuerst den SRV-Eintrag aus, den er vom DNS-Server erhalten hat.