Supporto per più gateway
Ultima modifica dell'argomento: 2012-01-25
Una novità per il Mediation Server di Lync Server 2010 riguarda la possibilità per un singolo Mediation Server di controllare più gateway. Nelle versioni precedenti il rapporto tra Mediation Server e gateway è di 1:1. Un determinato gateway può essere assegnato a più route di chiamata e associato a un Mediation Server o a un pool di Mediation Server. È possibile associare più gateway a un singolo Mediation Server o a un pool di Mediation Server. In questa versione il numero di gateway che un determinato Mediation Server può gestire dipende dalla capacità di elaborazione del server nelle ore di punta. Se si distribuisce un Mediation Server in hardware che supera i requisiti minimi per Lync Server 2010, come decritto in "Hardware supportato" nella documentazione relativa alla supportabilità, la stima del numero di chiamate attive gestibili da un Mediation Server autonomo è pari circa a 1000. Se la distribuzione viene eseguita in hardware che soddisfa queste specifiche, il Mediation Server dovrebbe eseguire la transcodifica, ma continua a instradare le chiamate per più gateway, anche se i gateway non supportano la funzionalità di bypass multimediale.
Quando si definisce una route di chiamata, si specificano i gateway ma non i Mediation Server associati a tale route. Per associare i gateway, e pertanto le route, ai Mediation Server si utilizza invece Generatore di topologie. In altri termini, il routing determina quale gateway utilizzare per una chiamata e quale Mediation Server associato a tale gateway gestisce la chiamata.
Un'altra novità di Lync Server 2010 è la possibilità di distribuire un Mediation Server come pool, che può trovarsi nella stessa posizione di un pool Front End o essere distribuito come pool autonomo. Quando un Mediation Server si trova nella stessa posizione di un pool Front End, la dimensione del pool può essere al massimo pari a 10 (il limite della dimensione del pool di registrazione). Nell'insieme, queste nuove funzionalità aumentano l'affidabilità e la flessibilità di distribuzione per i Mediation Server, ma richiedono funzionalità associate nelle entità peer seguenti:
Gateway PSTN. Un gateway qualificato per Lync Server 2010 deve implementare il bilanciamento del carico DNS, tramite il quale può fungere da servizio di bilanciamento del carico per un pool di Mediation Server e pertanto bilanciare il carico delle chiamate nel pool.
Session Border Controller. Per un trunk SIP, l'entità peer è un Session Border Controller (SBC) presso un provider di servizi di telefonia Internet. Nella direzione dal pool di Mediation Server all'SBC, l'SBC può ricevere connessioni da qualsiasi Mediation Server del pool. Nella direzione dall'SBC al pool, il traffico può essere inviato a qualsiasi Mediation Server del pool. Per ottenere questo risultato, uno dei metodi disponibili è il bilanciamento del carico DNS, se supportato dal provider di servizi e dall'SBC. Un'alternativa consiste nel fornire al provider di servizi gli indirizzi IP di tutti i Mediation Server del pool. Il provider di servizi ne eseguirà quindi il provisioning nel relativo SBC come trunk SIP separato per ogni Mediation Server. Infine, il provider di servizi gestirà il bilanciamento del carico per i propri server. Non tutti i provider di servizi o SBC supportano queste funzionalità. Inoltre, il provider di servizi potrebbe addebitare altri costi. Solitamente, ogni trunk SIP per l'SBC prevede una tariffa mensile.
In alternativa, il provider di servizi può configurare un singolo trunk SIP per il sito e quindi distribuire un sistema hardware di bilanciamento del carico tra l'SBC e il pool di Mediation Server (o i Mediation Server nella stessa posizione del pool Front End). Con questa configurazione, se si aggiunge un nuovo Mediation Server, la configurazione del provider di servizi non deve essere modificata. È possibile ottenere ridondanza di SBC se l'IP dell'SBC è un IP virtuale (VIP) che può terminare in SBC fisici diversi. In questo caso, se un SBC diventa non disponibile, esiste un meccanismo di recupero.
IP-PBX. Nella direzione dal pool di Mediation Server alla terminazione SIP dell'IP-PBX, l'IP-PBX può ricevere connessioni da qualsiasi Mediation Server del pool. Nella direzione dall'IP-PBX al pool, il traffico può essere inviato a qualsiasi Mediation Server del pool. Poiché la maggior parte dei IP-PBX non supporta il bilanciamento del carico DNS, è consigliabile definire singole connessioni SIP dirette dall'IP-PBX a ogni Mediation Server del pool. L'IP-PBX gestirà quindi il bilanciamento del carico distribuendo il traffico sul gruppo di trunk. Il presupposto è che il gruppo di trunk disponga di un set coerente di regole di routing nell'IP-PBX. Prima di decidere se un cluster di Mediation Server può interagire correttamente con un IP-PBX, è necessario determinare se questo concetto di gruppo di trunk è supportato dall'IP-PBX e come si interseca con l'architettura di ridondanza/clustering dell'IP-PBX.
Un pool di Mediation Server deve avere una vista uniforme del gateway peer con cui interagisce. Questo significa che tutti i membri del pool accedono alla stessa definizione del gateway peer dall'archivio di configurazione e hanno le stesse probabilità di interagire con esso per le chiamate in uscita. Pertanto, non è possibile segmentare il pool in modo che alcuni Mediation Server comunichino solo con determinati peer gateway per le chiamate in uscita. Se tale segmentazione è necessaria, occorre utilizzare un pool distinto di Mediation Server, ad esempio nel caso in cui le funzionalità associate nei gateway PSTN, trunk SIP o IP-PBX per l'interazione con un pool, come decritto in precedenza, non siano presenti.
Per una distribuzione di Lync Server 2010 si presuppone che un determinato gateway PSTN, IP-PBX o trunk SIP peer dipenda da un singolo pool di Mediation Server. Le chiamate vengono instradate da questo pool mediante il pool Front End di Lync Server 2010, in modo che possano raggiungere il peer gateway.
Per trunk SIP, IP-PBX e gateway PSTN per cui è necessario utilizzare un pool distinto di Mediation Server, è possibile seguire lo schema seguente per ottenere ridondanza:
Per risolvere l'interazione di più Mediation Server con la stessa entità peer gateway, è necessario configurare più gateway virtuali. Ogni gateway dovrà essere associato a un nome FQDN diverso, che DNS risolverà nello stesso indirizzo IP.
È necessario utilizzare singoli Mediation Server autonomi, ad esempio un pool di un unico Mediation Server, e definire un trunk da un Mediation Server a un gateway virtuale. Ogni Mediation Server ridondante sarà responsabile di una connessione del trunk con un gateway virtuale diverso.
Affinché questo schema funzioni per i peer gateway che supportano TLS, il nome FQDN di ogni gateway virtuale deve trovarsi nella parte del nome del soggetto del nome alternativo del soggetto del certificato fornito dal peer gateway.
I criteri applicati per l'interazione con il peer gateway saranno quelli associati al primo oggetto gateway corrispondente nell'archivio di configurazione. Questo non dovrebbe essere un problema, perché è necessario associare gli stessi criteri a tutti i gateway virtuali, che corrispondono allo stesso hardware fisico.
Le route di Lync Server 2010 utilizzeranno gateway virtuali diversi. Ogni gateway virtuale dipenderà da un Mediation Server diverso.
Il numero di gateway controllabili da un determinato pool di Mediation Server dipende dal numero di chiamate che utilizzano il bypass multimediale. Se un numero elevato di chiamate utilizza questa funzionalità, un Mediation Server del pool può gestire molte più chiamate, perché è necessaria una sola elaborazione del livello di segnalazione.