Requisiti per il bilanciamento del carico per Skype for Business
Riepilogo: Esaminare le considerazioni sul bilanciamento del carico prima di implementare Skype for Business Server.
Il bilanciamento del carico distribuisce il traffico tra i server in un pool. Se si dispone di pool Front End, pool Mediation Server o pool di server perimetrali, è necessario distribuire il bilanciamento del carico per questi pool.
Skype for Business Server supporta due tipi di soluzioni di bilanciamento del carico per il traffico da client a server: bilanciamento del carico DNS (Domain Name System) e bilanciamento del carico hardware (spesso abbreviato in HLB). Il bilanciamento del carico DNS offre diversi vantaggi, tra cui un'amministrazione più semplice, una risoluzione dei problemi più efficiente e la possibilità di isolare gran parte del traffico Skype for Business Server da eventuali problemi di bilanciamento del carico hardware.
Decidere autonomamente quale soluzione di bilanciamento del carico è appropriata per ogni pool nella distribuzione, ma tenere presente le restrizioni seguenti:
L'interfaccia perimetrale interna e l'interfaccia perimetrale esterna devono usare lo stesso tipo di bilanciamento del carico. Non è possibile usare il bilanciamento del carico DNS su un'interfaccia e il bilanciamento del carico hardware sull'altra.
Alcuni tipi di traffico richiedono un bilanciamento del carico hardware. Ad esempio, il traffico HTTP richiede un bilanciamento del carico hardware anziché il bilanciamento del carico DNS. Il bilanciamento del carico DNS non funziona con il traffico Web da client a server.
Se si sceglie di usare il bilanciamento del carico DNS per un pool, ma è comunque necessario implementare bilanciamenti del carico hardware per il traffico, ad esempio il traffico HTTP, l'amministrazione dei bilanciamenti del carico hardware è notevolmente semplificata. Ad esempio, la configurazione del bilanciamento del carico hardware sarà più semplice perché gestirà solo il traffico HTTP e HTTPS, mentre tutti gli altri protocolli verranno gestiti dal bilanciamento del carico DNS. Per informazioni dettagliate, vedere Bilanciamento del carico DNS.
Per il traffico da server a server, Skype for Business Server usa il bilanciamento del carico con riconoscimento della topologia. I server leggono la topologia pubblicata nell'archivio di gestione centrale per ottenere gli FQDN dei server nella topologia e distribuire automaticamente il traffico tra i server. Gli amministratori non devono configurare o gestire questo tipo di bilanciamento del carico.
Se si usa il bilanciamento del carico DNS ed è necessario bloccare il traffico verso un computer specifico, non è sufficiente rimuovere semplicemente le voci dell'indirizzo IP dal nome di dominio completo del pool. È necessario rimuovere la voce DNS anche per il computer.
Requisiti relativi al servizio di bilanciamento del carico hardware
La topologia Edge consolidata con scalabilità Skype for Business Server è ottimizzata per il bilanciamento del carico DNS per le nuove distribuzioni federate principalmente con altre organizzazioni che usano Skype for Business Server o Lync Server. Se è richiesta disponibilità elevata per uno degli scenari seguenti, è necessario utilizzare un servizio di bilanciamento del carico hardware nei pool di server perimetrali per quanto segue:
Federazione con organizzazioni che usano Office Communications Server 2007 R2 o Office Communications Server 2007
Messaggistica unificata di Exchange per utenti remoti che usano la messaggistica unificata di Exchange prima di Exchange 2010 con SP1
Connettività agli utenti di messaggistica istantanea pubblica
Importante
L'uso del bilanciamento del carico DNS su un'interfaccia e il bilanciamento del carico hardware sull'altra non è supportato. È necessario usare il bilanciamento del carico hardware per entrambe le interfacce o il bilanciamento del carico DNS per entrambe.
Nota
Se si utilizza un bilanciamento del carico hardware, il bilanciamento del carico distribuito per le connessioni con la rete interna deve essere configurato in modo da bilanciare il carico solo con il traffico verso i server che eseguono il servizio Access Edge e il servizio A/V Edge. Non riesce a bilanciare il carico tra il traffico al servizio Web Conferencing Edge interno o al servizio proxy XMPP interno.
Nota
Il NAT direct server return (DSR) non è supportato con Skype for Business Server.
Per determinare se il bilanciamento del carico hardware supporta le funzionalità necessarie richieste da Skype for Business Server, vedere Infrastruttura per Skype for Business.
Requisiti di Load Balancer hardware per i server perimetrali che eseguono il servizio A/V Edge
Ecco i requisiti di bilanciamento del carico hardware per i server perimetrali che eseguono il servizio A/V Edge:
Disattiva tcp nagling per entrambe le porte interne ed esterne 443. Nagling è il processo di combinazione di diversi piccoli pacchetti in un unico pacchetto più grande per una trasmissione più efficiente.
Disattivare il ronzio TCP per l'intervallo di porte esterne compreso tra 50.000 e 59.999.
Non usare NAT nel firewall interno o esterno.
L'interfaccia interna dell'edge deve trovarsi in una rete diversa da quella del server perimetrale e il routing tra di essi deve essere disabilitato.
L'interfaccia esterna del server perimetrale che esegue il servizio A/V Edge deve utilizzare indirizzi IP instradabili pubblicamente e nessuna conversione nat o porta su uno qualsiasi degli indirizzi IP esterni edge.
Il bilanciamento del carico non deve modificare l'indirizzo di origine del client.
Altri requisiti di Load Balancer hardware
I requisiti di affinità basati sui cookie sono notevolmente ridotti in Skype for Business Server per i servizi Web. Se si distribuisce Skype for Business Server e non si conservano i front end server di Lync Server 2010 o i pool Front End, non è necessaria la persistenza basata su cookie. Tuttavia, se si conserva temporaneamente o definitivamente qualsiasi pool Front End Server o Front End di Lync Server 2010, si continuerà a usare la persistenza basata sui cookie man mano che viene distribuita e configurata per Lync Server 2010.
Nota
Se si decide di usare l'affinità basata su cookie anche se la distribuzione non lo richiede, non vi è alcun impatto negativo a tale scopo.
Per le distribuzioni che non utilizzeranno l'affinità basata sui cookie:
- Nella regola di pubblicazione del proxy inverso per la porta 4443 impostare Forward host header su True. In questo modo l'URL originale verrà inoltrato.
Per le distribuzioni che useranno l'affinità basata sui cookie:
Nella regola di pubblicazione del proxy inverso per la porta 4443 impostare Forward host header su True. In questo modo l'URL originale verrà inoltrato.
Il cookie del bilanciamento del carico hardware NON DEVE essere contrassegnato come httpOnly
Il cookie del bilanciamento del carico hardware NON DEVE avere una scadenza
Cookie del servizio di bilanciamento del carico hardware DEVE essere denominato MS-WSMAN (valore previsto dai servizi Web e non modificabile)
Cookie del servizio di bilanciamento del carico hardware DEVE essere impostato in ogni risposta HTTP per cui la richiesta HTTP in arrivo non dispone di un cookie, indipendentemente dal fatto che una precedente risposta HTTP sulla stessa connessione TCP abbia già ottenuto un cookie. Se il bilanciamento del carico ottimizza l'inserimento dei cookie in modo che si verifichi una sola volta per ogni connessione TCP, tale ottimizzazione NON DEVE essere utilizzata
Nota
Le configurazioni tipiche del bilanciamento del carico hardware usano l'affinità indirizzo di origine e 20 minuti. Durata sessione TCP, che è bene per i client Lync Server e Lync 2013 perché lo stato della sessione viene mantenuto attraverso l'utilizzo client e/o e l'interazione dell'applicazione.
Se si distribuiscono dispositivi mobili, il bilanciamento del carico hardware deve essere in grado di bilanciare il carico di singole richieste all'interno di una sessione TCP (in effetti, è necessario essere in grado di bilanciare il carico di una singola richiesta in base all'indirizzo IP di destinazione).
Attenzione
Se si distribuiscono dispositivi mobili, il bilanciamento del carico hardware deve essere in grado di bilanciare ogni singola richiesta all'interno di una connessione TCP. Le app per dispositivi mobili Apple iOS più recenti richiedono Transport Layer Security (TLS) versione 1.2.
Attenzione
Per informazioni dettagliate sui bilanciamenti del carico hardware di terze parti, vedere Infrastruttura per Skype for Business.
Ecco i requisiti per il bilanciamento del carico hardware per i servizi Web del pool Director e Front End:
Per i provider di servizi Web interni, impostare la persistenza Source_addr (porta interna 80, 443) nel bilanciamento del carico hardware. Per Skype for Business Server, Source_addr persistenza significa che più connessioni provenienti da un singolo indirizzo IP vengono sempre inviate a un server per mantenere lo stato della sessione.
Usare il timeout di inattività TCP di 1800 secondi.
Nel firewall tra il proxy inverso e il bilanciamento del carico hardware del pool di hop successivo, creare una regola per consentire https: traffico sulla porta 4443, dal proxy inverso al bilanciamento del carico hardware. Il bilanciamento del carico hardware deve essere configurato per l'ascolto sulle porte 80, 443 e 4443.
Riepilogo dei requisiti di affinità Load Balancer hardware
| Posizione client/utente | Requisiti di affinità FQDN per i servizi Web esterni | Requisiti di affinità FQDN per i servizi Web interni |
|---|---|---|
| Lync Web App (utenti interni ed esterni) Dispositivo mobile (utenti interni ed esterni) |
Nessuna affinità |
Affinità indirizzo di origine |
| Lync Web App (solo utenti esterni) Dispositivo mobile (utenti interni ed esterni) |
Nessuna affinità |
Affinità indirizzo di origine |
| Lync Web App (solo utenti interni) Dispositivo mobile (non distribuito) |
Nessuna affinità |
Affinità indirizzo di origine |
Monitoraggio delle porte per i bilanciamenti del carico hardware
È possibile definire il monitoraggio delle porte sui bilanciamenti del carico hardware per determinare quando servizi specifici non sono più disponibili a causa di errori hardware o di comunicazione. Ad esempio, se il servizio Front End Server (RTCSRV) si arresta perché il Front End Server o il pool Front End non riesce, anche il monitoraggio HLB deve interrompere la ricezione del traffico sui servizi Web. È possibile implementare il monitoraggio delle porte su HLB per monitorare quanto segue:
Pool di utenti front-end server - Interfaccia interna HLB
| IP virtuale/porta | Porta nodo | Node Machine/Monitor | Profilo di persistenza | Note |
|---|---|---|---|---|
| <pool>web-int_mco_443_vs 443 |
443 |
Front End 5061 |
Fonte |
HTTPS |
| <pool>web-int_mco_80_vs 80 |
80 |
Front End 5061 |
Fonte |
HTTP |
Pool di utenti front-end server - Interfaccia esterna HLB
| IP virtuale/porta | Porta nodo | Node Machine/Monitor | Profilo di persistenza | Note |
|---|---|---|---|---|
| <web_mco_443_vs piscina> 443 |
4443 |
Front End 5061 |
Nessuno |
HTTPS |
| <web_mco_80_vs piscina> 80 |
8080 |
Front End 5061 |
Nessuno |
HTTP |
Bilanciamento del carico DNS
Skype for Business Server consente il bilanciamento del carico DNS, una soluzione software in grado di ridurre notevolmente l'overhead amministrativo per il bilanciamento del carico sulla rete. Il bilanciamento del carico DNS bilancia il traffico di rete univoco per Skype for Business Server, ad esempio il traffico SIP e il traffico multimediale.
Se si distribuisce il bilanciamento del carico DNS, l'overhead amministrativo dell'organizzazione per i bilanciamenti del carico hardware sarà ridotto a icona. Inoltre, la complessa risoluzione dei problemi relativi alla configurazione errata dei bilanciamenti del carico per il traffico SIP verrà eliminata. È anche possibile impedire le connessioni server in modo da portare i server offline. Il bilanciamento del carico DNS garantisce inoltre che i problemi di bilanciamento del carico hardware non influiscano sugli elementi del traffico SIP, ad esempio il routing delle chiamate di base.
Il diagramma seguente illustra un esempio che include il bilanciamento del carico DNS interno ed esterno:
Diagramma di rete Edge con indirizzi IPv4 pubblici
Se si usa il bilanciamento del carico DNS, è anche possibile acquistare bilanciamenti del carico hardware a costi inferiori rispetto a quando sono stati usati i bilanciamenti del carico hardware per tutti i tipi di traffico. È consigliabile usare bilanciamenti del carico che hanno superato i test di qualificazione per l'interoperabilità con Skype for Business Server. Per informazioni dettagliate sui test di interoperabilità del bilanciamento del carico, vedere Lync Server 2010 Load Balancer Partners. Il contenuto si applica a Skype for Business Server.
Il bilanciamento del carico DNS è supportato per pool Front End, pool di server perimetrali, pool di director e pool di Mediation Server autonomi.
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 il nome di dominio completo del pool (FQDN).
Ad esempio, se sono presenti tre server front-end in un pool denominato pool01.contoso.com, si verificherà 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 (non necessariamente in questo 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 (Transmission Control Protocol) a uno degli indirizzi IP. Se l'operazione non riesce, il client prova l'indirizzo IP successivo nella cache.
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, all'utente viene notificato 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 corrispondenti ai server in un pool. In genere DNS RR abilita solo la distribuzione del carico, ma non il failover. Ad esempio, se la connessione a un indirizzo IP restituito dalla query DNS A e AAAA (se si usano gli indirizzi IPv6) non riesce, la connessione non riesce. Pertanto, il round robin DNS da solo è meno affidabile del bilanciamento del carico basato su DNS. È possibile usare il round robin DNS in combinazione con il bilanciamento del carico DNS.
Il bilanciamento del carico DNS viene utilizzato per quanto segue:
Load balancing server-to-server SIP to the Edge Servers
Applicazioni UCAS (Unified Communications Application Services) di bilanciamento del carico, ad esempio Operatore automatico servizi di conferenza, Response Group e Parcheggio di chiamata
Prevenzione di 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 utilizzare il bilanciamento del carico DNS per quanto segue:
- Traffico Web da client a server verso server director o front end
Bilanciamento del carico DNS e traffico federato:
Se una query SRV DNS restituisce più record DNS, il servizio Access Edge seleziona sempre il record SRV DNS con la priorità numerica più bassa e il peso numerico massimo. Nel documento di Internet Engineering Task Force "A DNS RR for specifying the location of services (DNS SRV)" RFC 2782, DNS SRV RR specifica che se sono definiti più record SRV DNS, prima viene usata la priorità, quindi peso. Ad esempio, il record SRV DNS A ha un peso di 20 e una priorità 40 e il record SRV DNS B ha un peso di 10 e la priorità di 50. Verrà selezionato il record SRV DNS A con priorità 40. Le regole seguenti si applicano alla selezione di record SRV DNS:
La priorità viene considerata per prima. Un client DEVE tentare di contattare l'host di destinazione definito dal record SRV DNS con la priorità numerato più bassa che può raggiungere. Gli obiettivi con la stessa priorità DEVONO essere provati in un ordine definito dal campo peso.
Il campo peso specifica un peso relativo per le voci con la stessa priorità. Pesi maggiori DEVONO avere una probabilità proporzionalmente superiore di essere selezionati. Gli amministratori DNS DEVONO usare Peso 0 quando non è necessario selezionare alcun server. In presenza di record contenenti pesi maggiori di 0, i record con peso 0 dovrebbero avere una probabilità molto piccola di essere selezionati.
Se vengono restituiti più record SRV DNS con uguale priorità e peso, il servizio Access Edge selezionerà il record SRV ricevuto per primo dal server DNS.
Bilanciamento del carico DNS nei pool front-end e nei pool di director
È possibile usare il bilanciamento del carico DNS per il traffico SIP nei pool Front End e nei pool di director. Con il bilanciamento del carico DNS distribuito, è comunque necessario usare i bilanciamenti del carico hardware per questi pool, ma solo per il traffico HTTPS da client a server. Il bilanciamento del carico hardware viene utilizzato per il traffico HTTPS dai client sulle porte 443 e 80.
Anche se sono ancora necessari bilanciamenti del carico hardware per questi pool, la loro configurazione e amministrazione sarà principalmente per il traffico HTTPS, a cui sono abituati gli amministratori dei bilanciamenti del carico hardware.
Bilanciamento del carico DNS e supporto di client e server meno recenti
Il bilanciamento del carico DNS supporta il failover automatico solo per i server che eseguono Skype for Business Server o Lync Server 2010 e per Lync 2013 e client Skype for Business. Le versioni precedenti dei client e di Office Communications Server possono comunque connettersi a pool che eseguono il bilanciamento del carico DNS, ma se non riescono a stabilire una connessione al primo server a cui fa riferimento il bilanciamento del carico DNS, non riescono a eseguire il failover su un altro server del pool.
Inoltre, se si usa la messaggistica unificata di Exchange, è necessario usare almeno Exchange 2010 SP1 per ottenere supporto per Skype for Business Server bilanciamento del carico DNS. Se si usa una versione precedente di Exchange, gli utenti non disporrà di funzionalità di failover per questi scenari di messaggistica unificata di Exchange:
Riproduzione della segreteria telefonica Aziendale sul telefono
Trasferimento di chiamate da un operatore automatico di messaggistica unificata di Exchange
Tutti gli altri scenari di messaggistica unificata di Exchange funzioneranno correttamente.
Distribuzione del bilanciamento del carico DNS nei pool front-end e nei pool di director
La distribuzione del bilanciamento del carico DNS nei pool Front End e nei pool di director richiede l'esecuzione di un paio di passaggi aggiuntivi con FQDN e record DNS.
Un pool che usa il bilanciamento del carico DNS deve avere due FQDN: il normale FQDN del pool usato dal bilanciamento del carico DNS (ad esempio pool01.contoso.com) e risolve gli INDIRIZZI IP fisici dei server nel pool e un altro FQDN per i servizi Web del pool, ad esempio web01.contoso.com, che risolve l'indirizzo IP virtuale del pool.
In Generatore di topologie, se si vuole distribuire il bilanciamento del carico DNS per un pool, per creare questo FQDN aggiuntivo per i servizi Web del pool è necessario selezionare la casella di controllo Ignora FQDN pool di servizi Web interni e digitare l'FQDN nella pagina Specificare gli URL dei servizi Web per il pool .
Per supportare l'FQDN usato dal bilanciamento del carico DNS, è necessario eseguire il provisioning del DNS per risolvere l'FQDN del pool, ad esempio pool01.contoso.com, agli indirizzi IP di tutti i server del pool, ad esempio 192.168.1.1, 192.168.1.2 e così via. È necessario includere solo gli indirizzi IP dei server attualmente distribuiti.
Attenzione
Se si hanno più pool Front End o Front End Server, l'FQDN dei servizi Web esterni deve essere univoco. Ad esempio, se si definisce il nome di dominio completo dei servizi Web esterni di un Front End Server come pool01.contoso.com, non è possibile usare pool01.contoso.com per un altro pool Front End o Front End Server. Se si stanno distribuendo anche director, l'FQDN dei servizi Web esterni definito per qualsiasi pool di director o director deve essere univoco da qualsiasi altro pool di director o director, nonché da qualsiasi pool Front End o Front End Server. Se si decide di ignorare i servizi Web interni con un FQDN auto definito, ogni FQDN deve essere univoco da qualsiasi altro pool Front End, director o director.
Bilanciamento del carico DNS nei pool di server perimetrali
È possibile distribuire il bilanciamento del carico DNS nei pool di server perimetrali. In questo caso, è necessario tenere conto di alcune considerazioni.
L'uso del bilanciamento del carico DNS nei server perimetrali causa una perdita di capacità di failover negli scenari seguenti:
Federazione con organizzazioni che eseguono versioni di Skype for Business Server rilasciate prima di Lync Server 2010.
Scambio di messaggi istantanei con gli utenti dei servizi di messaggistica istantanea pubblica AOL e Yahoo!, oltre ai provider e ai server basati su XMPP, come Google Talk, attualmente l'unico partner XMPP supportato.
Questi scenari funzionano a condizione che tutti i server perimetrali nel pool siano attivi e in esecuzione, ma se un server perimetrale non è disponibile, le richieste per questi scenari inviate non riusciranno, invece del routing a un altro server perimetrale.
Se si usa la messaggistica unificata di Exchange, è necessario usare almeno Exchange 2013 per ottenere supporto per Skype for Business Server bilanciamento del carico DNS in Edge. Se si usa una versione precedente di Exchange, gli utenti remoti non disporrà di funzionalità di failover per questi scenari di messaggistica unificata di Exchange:
Riproduzione della segreteria telefonica Aziendale sul telefono
Trasferimento di chiamate da un operatore automatico di messaggistica unificata di Exchange
Tutti gli altri scenari di messaggistica unificata di Exchange funzioneranno correttamente.
L'interfaccia perimetrale interna e l'interfaccia perimetrale esterna devono usare lo stesso tipo di bilanciamento del carico. Non è possibile usare il bilanciamento del carico DNS in un'interfaccia perimetrale e il bilanciamento del carico hardware nell'altra.
Distribuzione del bilanciamento del carico DNS nei pool di server perimetrali
Per distribuire il bilanciamento del carico DNS nell'interfaccia esterna del pool di server perimetrali, sono necessarie le voci DNS seguenti:
Per il servizio Access Edge, è necessaria una voce per ogni server nel pool. Ogni voce deve risolvere l'FQDN del servizio Access Edge (ad esempio, sip.contoso.com) all'indirizzo IP del servizio Access Edge in uno dei server perimetrali nel pool.
Per il servizio Web Conferencing Edge, è necessaria una voce per ogni server nel pool. Ogni voce deve risolvere l'FQDN del servizio Web Conferencing Edge (ad esempio, webconf.contoso.com) all'indirizzo IP del servizio Web Conferencing Edge in uno dei server perimetrali nel pool.
Per il servizio Edge audio/video, è necessaria una voce per ogni server nel pool. Ogni voce deve risolvere il nome di dominio completo del servizio Edge audio/video (ad esempio, av.contoso.com) all'indirizzo IP del servizio A/V Edge in uno dei server perimetrali del pool.
Per distribuire il bilanciamento del carico DNS nell'interfaccia interna del pool di server perimetrali, è necessario aggiungere un record DNS A, che risolve l'FQDN interno del pool di server perimetrali all'indirizzo IP di ogni server nel pool.
Utilizzo del bilanciamento del carico DNS nei pool di Mediation Server
È possibile usare il bilanciamento del carico DNS nei pool di Mediation Server autonomi. Tutto il traffico SIP e multimediale è bilanciato dal bilanciamento del carico DNS.
Per distribuire il bilanciamento del carico DNS in un pool di Mediation Server, è necessario eseguire il provisioning del DNS per risolvere il nome di dominio completo del pool, ad esempio mediationpool1.contoso.com, agli indirizzi IP di tutti i server del pool, ad esempio 192.168.1.1, 192.168.1.2 e così via.
Blocco del traffico verso un server con bilanciamento del carico DNS
Se si usa il bilanciamento del carico DNS ed è necessario bloccare il traffico verso un computer specifico, non è sufficiente rimuovere semplicemente le voci dell'indirizzo IP dal nome di dominio completo del pool. È necessario rimuovere la voce DNS anche per il computer.
Si noti che per il traffico da server a server, Skype for Business Server usa il bilanciamento del carico con riconoscimento della topologia. I server leggono la topologia pubblicata nell'archivio di gestione centrale per ottenere gli FQDN dei server nella topologia e distribuire automaticamente il traffico tra i server. Per impedire a un server di ricevere traffico da server a server, è necessario rimuovere il server dalla topologia.