Condividi tramite

Pianificare la distribuzione di Advanced Edge Server per Skype for Business Server

  • Articolo

Riepilogo: Esaminare scenari per Skype for Business Server opzioni di distribuzione. Questo argomento è utile indipendentemente dal fatto che si desideri un singolo server o che si preferisca un pool di server con DNS o HLB.

Quando si tratta di pianificazione DNS (Domain Name System) per Skype for Business Server, nella decisione possono essere presenti molti fattori. Se la struttura del dominio dell'organizzazione è già in atto, potrebbe essere necessario rivedere la procedura da seguire. Inizieremo con gli argomenti che si trovano di seguito:

Procedura dettagliata di Skype for Business client di individuazione dei servizi

Skype for Business client sono simili alle versioni precedenti dei client Lync per la ricerca e l'accesso ai servizi in Skype for Business Server. Questa sezione descrive in dettaglio il processo di percorso del server.

  1. lyncdiscoverinternal.<Dominio>

    Si tratta di un record host per il servizio di individuazione automatica nei servizi Web interni.

  2. lyncdiscover.<Dominio>

    Si tratta di un record host per il servizio di individuazione automatica nei servizi Web esterni.

  3. _sipinternaltls._tcp.<Dominio>

    Si tratta di un record SRV per connessioni TLS interne.

  4. _sip._tls.<Dominio>

    Si tratta di un record SRV per le connessioni TLS esterne.

  5. sipinternal.<Dominio>

    Si tratta di un record host per il pool Front End o il director, risolvibile solo nella rete interna.

  6. Sip.<Dominio>

    Si tratta di un record host per il pool Front End o il director, risolvibile solo nella rete interna.

  7. sipexternal.<Dominio>

    Si tratta di un record host per il servizio Access Edge, quando il client è esterno.

Il servizio di individuazione automatica è sempre preferito perché è il metodo preferito per la posizione del servizio, mentre gli altri sono metodi di fallback.

Nota

Quando si creano record SRV, è importante ricordare che devono puntare a un DNS A (e AAAA se si usano gli indirizzi IPv6) nello stesso dominio in cui viene creato il record SRV DNS. Ad esempio, se il record SRV si trova in contoso.com, il record A (e AAAA) a cui punta non può trovarsi in fabrikam.com.

Se si è disposti a farlo, è possibile configurare il dispositivo mobile per l'individuazione manuale dei servizi. Se si sta cercando di farlo, ogni utente deve configurare le impostazioni del dispositivo mobile con gli URL completi dei servizi di individuazione automatica interni ed esterni, inclusi il protocollo e il percorso, come indicato di seguito:

  • Per l'accesso esterno: https://< ExtPoolFQDN>/Autodiscover/autodiscoverservice.svc/Root

  • Per l'accesso interno: https://< IntPoolFQDN>/AutoDiscover/AutoDiscover.svc/Root

È consigliabile usare l'individuazione automatica anziché l'individuazione manuale. Ma se stai eseguendo alcuni test o risoluzione dei problemi, le impostazioni manuali possono essere molto utili.

Split-brain DNS

Si tratta di una configurazione DNS in cui sono presenti due zone DNS con lo stesso spazio dei nomi. La prima zona DNS gestisce le richieste interne, mentre la seconda zona DNS gestisce le richieste esterne.

Perché una società dovrebbe farlo? Potrebbero avere l'esigenza di usare lo stesso spazio dei nomi internamente ed esternamente, ma naturalmente molti record DNS SRV e A saranno univoci in una o più aree e, in caso di duplicazione, gli indirizzi IP associati a questi record saranno univoci.

Questo presenta alcune sfide. Il più importante è che il DNS split-brain non è supportato per la mobilità. Ciò è dovuto ai record DNS LyncDiscover e LyncDiscoverInternal (LyncDiscover deve essere definito sul server DNS esterno, mentre LyncDiscoverInternal deve essere definito nel server DNS interno).

Qui verranno elencati i record DNS per le aree interne ed esterne, ma è possibile trovare esempi dettagliati nella sezione Requisiti ambientali di Edge Server.

DNS interno

  • Contiene una zona DNS chiamata, ad esempio, contoso.com, di cui è autorevole.

  • Questa contoso.com interna contiene:

    • DNS A e AAAA (se si usano indirizzi IPv6) record per il pool Front End, il nome del pool di director o del pool di director e tutti i server interni che eseguono Skype for Business Server nella rete dell'organizzazione.

    • Record DNS A e AAAA (se si usano indirizzi IPv6) per l'interfaccia interna di Edge per ogni Skype for Business Server server perimetrale nella rete perimetrale.

    • Record DNS A e AAAA (se si usano indirizzi IPv6) per l'interfaccia interna di ogni server proxy inverso nella rete perimetrale (facoltativo per la gestione di un proxy inverso).

    • DNS A e AAAA (se si usano gli indirizzi IPv6) e record SRV per la configurazione automatica del client Skype for Business Server interno (facoltativo).

    • DNS A e AAAA (se si usano gli indirizzi IPv6) o record CNAME per l'individuazione automatica di Skype for Business Server Servizi Web (facoltativo).

  • Tutte le interfacce perimetrali interne Skype for Business Server nella rete perimetrale usano questa zona DNS interna per la risoluzione delle query da contoso.com.

  • Tutti i server che eseguono Skype for Business Server e i client che eseguono Skype for Business Server nella rete aziendale puntano ai server DNS interni per la risoluzione delle query su contoso.com oppure usano il file Host in ogni server perimetrale ed elencano i record A e AAAA (se si usano gli indirizzi IPv6) per il server dell'hop successivo (in particolare per il pool director o director) VIP, pool Front End VIP o server Standard Edition).

DNS esterno

  • Contiene una zona DNS chiamata, ad esempio, contoso.com, di cui è autorevole.

  • Questa contoso.com esterna contiene:

    • DNS A e AAAA (se si usano gli indirizzi IPv6) o record CNAME per l'individuazione automatica di Skype for Business Server servizi Web. Questo è per l'uso con mobilità.

    • DNS A e AAAA (se si usano gli indirizzi IPv6) e record SRV per l'interfaccia esterna edge di ogni server perimetrale Skype for Business Server o vip con bilanciamento del carico hardware (HLB) nella rete perimetrale.

    • DNS A e AAAA (se si usano indirizzi IPv6) e record SRV per l'interfaccia esterna del server proxy inverso o (VIP per un pool di server proxy inverti), nella rete perimetrale.

    • DNS A e AAAA (se si usano gli indirizzi IPv6) e record SRV per Skype for Business Server configurazione automatica client (facoltativo).

Configurazione automatica senza DNS split-brain

Se non si usa il DNS split-brain, la configurazione automatica interna dei client che eseguono Skype for Business non funzionerà a meno che non si usi una delle soluzioni alternative disponibili qui. Perché no? Poiché Skype for Business Server richiede che l'URI SIP dell'utente corrisponda al dominio del pool Front End designato per la configurazione automatica. Questa operazione non è stata modificata rispetto alle versioni precedenti di Lync Server.

Quindi, se sono in uso due domini SIP, sono necessari questi record SRV DNS:

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

    Se un utente accede come bob@contoso.com, questo record funziona per la configurazione automatica, poiché il dominio SIP dell'utente corrisponde al dominio del pool Front End (contoso.com).

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

    Se un utente accede come alice@fabrikam.com, questo record funziona per la configurazione automatica del secondo dominio, anche perché il dominio SIP corrisponde al pool Front End del dominio.

Per approfondire l'esempio, non è possibile procedere come segue:

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

    Un utente che accede come tim@litwareinc.com non funziona per la configurazione automatica, perché il suo dominio SIP (litwareinc.com) non corrisponde al dominio nel pool (fabrikam.com).

Quindi, ora che sappiamo tutto questo, se è necessario il requisito automatico per i client di Skype for Business senza DNS split-brain, sono disponibili queste opzioni:

  • Oggetti Criteri di gruppo

    È possibile usare Criteri di gruppo Objects (GPO) per popolare i valori del server corretti.

    Nota

    Questa opzione non abilita la configurazione automatica, ma automatizza la configurazione manuale. Se si usa questo approccio, i record SRV associati alla configurazione automatica non sono necessari.

  • Zona interna corrispondente

    È necessario creare un'area nel DNS interno corrispondente all'area DNS esterna (ad esempio contoso.com) e quindi creare record DNS A (e AAAA se si usano indirizzi IPv6) che corrispondono al pool di Skype for Business Server usato per la configurazione automatica.

    Ad esempio, se un utente è ospitato in pool01.contoso.net, ma accede a Skype for Business come bob@contoso.com, creare una zona DNS interna denominata contoso.com e al suo interno è necessario creare un record DNS A (e AAAA se si usano indirizzi IPv6) per pool01.contoso.com.

  • Zona interna pin-point

    Se non è possibile creare un'intera zona nel DNS interno, è possibile creare zone pin-point (dedicate) che corrispondono ai record SRV necessari per la configurazione automatica e popolare tali aree con dnscmd.exe. Dnscmd.exe è necessario perché l'interfaccia utente DNS non supporta la creazione di zone pin-point.

    Ad esempio, se il dominio SIP è contoso.com e si dispone di un pool Front End denominato pool01 che contiene due Front End Server, saranno necessari le seguenti zone pin-point e record A nel DNS interno:

    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>

    Nell'ambiente potrebbe essere presente un secondo dominio SIP. In questo caso, sono necessari i seguenti punti di accesso e record A nel DNS interno:

    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>

Nota

L'FQDN del pool Front End viene visualizzato due volte, ma con due indirizzi IP diversi. Il motivo è che viene usato il bilanciamento del carico DNS. Se viene utilizzato HLB, esisterebbe una sola voce del pool Front End.

Nota

Inoltre, i valori FQDN del pool Front End cambiano tra i contoso.com e fabrikam.com esempi, ma gli indirizzi IP rimangono invariati. Questo è dovuto al fatto che gli utenti che eseguire l'accesso da uno dei domini SIP usano lo stesso pool Front End per la configurazione automatica.

Ripristino di emergenza DNS

Per configurare il DNS per reindirizzare Skype for Business Server traffico Web ai siti di ripristino di emergenza e di failover, è necessario usare un provider DNS che supporta GeoDNS. È possibile configurare i record DNS per supportare il ripristino di emergenza, in modo che le caratteristiche che usano i servizi Web continuino anche se un intero pool Front End va giù. Questa funzionalità dr supporta l'individuazione automatica, riunione e accesso esterno semplici URL.

Definire e configurare record A (AAAA) aggiuntivi per l'host DNS (AAAA se si usa IPv6) per la risoluzione interna ed esterna dei servizi Web presso il provider GeoDNS. I dettagli seguenti presuppongono pool associati, distribuiti geograficamente, e che GeoDNS supportato dal provider abbia il DNS round robin o sia configurato per usare Pool1 come principale e non riesce a Pool2 in caso di perdita di comunicazioni o interruzioni di corrente.

Tutti i record DNS in questa tabella sono esempi.

Record GeoDNS Record del pool Record CNAME Impostazioni DNS (seleziona una opzione)
Meet-int.geolb.contoso.com
 Pool1InternalWebFQDN.contoso.com
Pool2InternalWebFQDN.contoso.com
 Meet.contoso.com a Meet-int.geolb.contoso.com

 Round Robin tra pool
O
Usa principale, connetti a secondario in caso di errore
Meet-ext.geolb.contoso.com
 Pool1ExternalWebFQDN.contoso.com
Pool2ExternalWebFQDN.contoso.com
 Meet.contoso.com a Meet-ext.geolb.contoso.com

 Round Robin tra pool
O
Usa principale, connetti a secondario in caso di errore
Dialin-int.geolb.contoso.com
 Pool1InternalWebFQDN.contoso.com
Pool2InternalWebFQDN.contoso.com
 Meet.contoso.com a Meet-int.geolb.contoso.com

 Round Robin tra pool
O
Usa principale, connetti a secondario in caso di errore
Dialin-ext.geolb.contoso.com
 Pool1ExternalWebFQDN.contoso.com
Pool2ExternalWebFQDN.contoso.com
 Meet.contoso.com a Meet-ext.geolb.contoso.com

 Round Robin tra pool
O
Usa principale, connetti a secondario in caso di errore
Lyncdiscoverint-int.geolb.contoso.com
 Pool1InternalWebFQDN.contoso.com
Pool2InternalWebFQDN.contoso.com
 Meet.contoso.com a Meet-int.geolb.contoso.com

 Round Robin tra pool
O
Usa principale, connetti a secondario in caso di errore
Lyncdiscover-ext.geolb.contoso.com
 Pool1ExternalWebFQDN.contoso.com
Pool2ExternalWebFQDN.contoso.com
 Meet.contoso.com a Meet-ext.geolb.contoso.com

 Round Robin tra pool
O
Usa principale, connetti a secondario in caso di errore
Scheduler-int.geolb.contoso.com
 Pool1InternalWebFQDN.contoso.com
Pool2InternalWebFQDN.contoso.com
 Meet.contoso.com a Meet-int.geolb.contoso.com

 Round Robin tra pool
O
Usa principale, connetti a secondario in caso di errore
Scheduler-ext.geolb.contoso.com
 Pool1ExternalWebFQDN.contoso.com
Pool2ExternalWebFQDN.contoso.com
 Meet.contoso.com a Meet-ext.geolb.contoso.com

 Round Robin tra pool
O
Usa principale, connetti a secondario in caso di errore

Bilanciamento del carico DNS

Il bilanciamento del carico DNS viene in genere implementato a livello di applicazione. L'applicazione, ad esempio un client che esegue Skype for Business, tenta di connettersi a un server in un pool connettendosi a uno degli indirizzi IP restituiti dalla query record DNS A e AAAA (se si usano indirizzi IPv6) per l'FQDN del pool.

Ad esempio, se sono presenti tre Front End Server in un pool denominato pool01.contoso.com, si verificherebbe quanto segue:

  • I client che eseguono Skype for Business query DNS per pool01.contoso.com. La query restituisce tre indirizzi IP e li memorizza nella cache come indicato di seguito (in un certo ordine):

       
    pool01.contoso.com
    		 192.168.10.90
    pool01.contoso.com
    		 192.168.10.91
    pool01.contoso.com
    		 192.168.10.92

  • Il client tenta di stabilire una connessione TCP a uno degli indirizzi IP. Se l'operazione non riesce, prova l'indirizzo IP successivo memorizzato nella cache dell'elenco.

  • Se la connessione TCP ha esito positivo, il client negozia TLS per connettersi al registrar principale in pool01.contoso.com.

  • Se il client tenta tutte le voci memorizzate nella cache senza una connessione riuscita, l'utente riceve una notifica che indica che al momento non sono disponibili server che eseguono Skype for Business Server.

Nota

Il bilanciamento del carico basato su DNS è diverso dal DNS Round Robin (DNS RR), che in genere fa riferimento al bilanciamento del carico facendo affidamento sul DNS per fornire un ordine diverso di indirizzi IP per i server del pool. In genere, DNS RR abilita la distribuzione del carico, ma non consente di abilitare il failover. Ad esempio, se la connessione a un indirizzo IP restituito dalla query DNS A (o AAAA in uno scenario IPv6) non riesce, la connessione avrà esito negativo. In questo modo la RR DNS risulta meno affidabile rispetto al bilanciamento del carico basato su DNS. Se necessario, è comunque possibile usare LAR.DNS in combinazione con il bilanciamento del carico basato su DNS.

Usare il bilanciamento del carico DNS per:

  • Bilanciamento del carico sip da server a server ai server perimetrali.

  • Servizio UCAS (Unified Communication Application Services) del bilanciamento del carico, ad esempio Operatore automatico servizi di conferenza, Response Group e Parcheggio di chiamata.

  • Impedire nuove connessioni alle applicazioni UCAS (note anche come svuotamento).

  • Bilanciamento del carico di tutto il traffico client-server tra client e server perimetrali.

Non è possibile usare il bilanciamento del carico DNS per:

  • Traffico Web da client a server verso i server Front End o verso un director.

Per approfondire la selezione di un record SRV DNS quando più record DNS vengono restituiti da una query, il servizio Access Edge seleziona sempre il record con la priorità numerica più bassa e, se è necessario un tie-breaker, il peso numerico più alto. Questo è coerente con la documentazione della Task Force ingegneria Internet.

Quindi, ad esempio, se il primo record SRV DNS ha un peso di 20 e una priorità di 40 e il secondo record SRV DNS ha un peso di 10 e una priorità di 50, verrà scelto il primo record perché ha la priorità più bassa di 40. Priorità va sempre prima, e questo è l'host di destinazione di un client. Cosa succede se ci sono due obiettivi con la stessa priorità?

In questo caso, viene preso in considerazione il peso. Ai pesi maggiori dovrebbe essere data un'alta probabilità, in questa circostanza, di essere selezionati. Gli amministratori DNS devono usare il peso 0 quando non è necessario selezionare alcun server. In presenza di record contenenti pesi maggiori di 0, i record con peso 0 hanno piccole possibilità di essere selezionati.

Quindi, cosa succede se più record SRV DNS con uguale priorità e peso vengono restituiti? In questo caso, il servizio Access Edge sceglierà prima il record SRV ottenuto dal server DNS.