Server nella topologia con resilienza di siti metropolitani

 

Ultima modifica dell'argomento: 2011-10-18

La topologia con resilienza di siti metropolitani può includere diversi tipi di ruoli del server, come descritto di seguito.

Pool Front End

Questo pool ospita tutti gli utenti di Lync Server. Ogni sito, Nord e Sud, contiene quattro Front End Server configurati in modo identico. Il database back-end è distribuito come due nodi di cluster geograficamente distanti di SQL Server 2008 attivo/passivo in esecuzione nel servizio Clustering di failover di Windows Server 2008 R2. È richiesta la replica dei dati sincrona tra i due server di database back-end.

Nella topologia di prova, il Mediation Server è collocato con il Front End Server. Sono supportate anche topologie con Mediation Server autonomo.

La topologia di prova utilizza il bilanciamento del carico DNS per bilanciare il traffico SIP nel pool con dispositivi di bilanciamento del carico hardware distribuiti per il traffico HTTP.

Per la resilienza dei siti sono inoltre supportate topologie che utilizzano solo dispositivi di bilanciamento del carico hardware per bilanciare tutti i tipi di traffico

Pool A/V Conferencing

È stato distribuito un singolo pool A/V Conferencing con quattro A/V Conferencing Server, due in ogni sito.

Pool di server Director

È stato distribuito un singolo pool di server Director con quattro server Director, due in ogni sito.

Pool di server perimetrali

I server perimetrali sono stati utilizzati per l'esecuzione di tutti i servizi (Access Edge, A/V Conferencing Edge e Web Conferencing Edge), ma tali server sono stati testati solo per scenari relativi agli utenti remoti. La federazione e la connettività per messaggistica istantanea pubblica esulano dagli argomenti trattati nel presente documento.

È consigliato il bilanciamento del carico DNS per il pool di server perimetrali, ma è supportato anche l'utilizzo di dispositivi di bilanciamento del carico hardware. Per l'interfaccia perimetrale interna e per quella esterna è necessario utilizzare lo stesso tipo di bilanciamento del carico. Non è possibile utilizzare il bilanciamento del carico DNS in un'interfaccia perimetrale e il bilanciamento del carico hardware nell'altra. Se si utilizzano dispositivi di bilanciamento del carico hardware per il pool di server perimetrale, il dispositivo in un sito funge da dispositivo di bilanciamento del carico primario e risponde alle richieste con l'indirizzo IP virtuale del servizio Edge appropriato. Se il dispositivo primario non è disponibile, il dispositivo di bilanciamento del carico hardware secondario nell'altro sito assume il controllo. A ogni sito corrisponde una subnet IP specifica. Le reti perimetrali non sono state estese attraverso i siti Nord e Sud.

Group Chat Server

Ogni sito ospita sia un servizio del canale che un servizio di ricerca, ma questi servizi possono essere attivi in solo uno dei siti alla volta. Il servizio del canale e il servizio di ricerca nell'altro sito devono essere arrestati o disabilitati. Nell'evento di un failover del sito, sono richiesti interventi manuali per avviare questi servizi nel sito di failover.

Ogni sito ospita anche un Compliance Server, ma solo uno di questi server può essere attivo contemporaneamente. In caso di failover e failback di un sito, è necessario intervenire manualmente per ripristinare il servizio. Per informazioni dettagliate, vedere Backup del server di conformità nella documentazione relativa alle operazioni.

Il database back-end di Group Chat è stato distribuito come due nodi di cluster geograficamente distanti di SQL Server 2008 attivo/passivo in esecuzione nel servizio Clustering di failover di Windows Server 2008 R2. La replica dei dati tra i due server back-end deve essere sincrona. Viene utilizzata una singola istanza di database sia per Group Chat che per i dati di conformità.

Monitoring Server e server di archiviazione

Per Monitoring Server e il server di archiviazione è consigliabile una distribuzione in modalità hot standby. Distribuire questi ruoli del server in entrambi i siti, in un singolo server in ogni sito. Solo uno di questi server è attivo e i pool nella distribuzione sono tutti associati a tale server attivo. L'altro server è distribuito e installato, ma non associato ad alcun pool.

Se il server principale diventa non disponibile, si utilizza Generatore di topologie per associare manualmente i pool al server in modalità standby, che diventa il server principale.

Cluster di file server

È stato distribuito un file server come risorsa del cluster geograficamente distante a due nodi, che utilizza il servizio Cluster di failover di Windows Server 2008 R2. È richiesta la replica dei dati sincrona. Qualsiasi funzione di Lync Server che richiede una condivisione file ed è divisa tra i due siti deve utilizzare questo cluster di condivisioni file, incluso quanto segue:

  • Percorso del contenuto delle riunioni

  • Percorso dei metadati delle riunioni

  • Percorso di archiviazione delle riunioni

  • Archivio file del server della Rubrica

  • Archivio dati dell'applicazione

  • Archivio dati di aggiornamento client

  • Archivio file di conformità Group Chat

  • Percorso dei file di caricamento di Group Chat

Proxy inverso

Viene distribuito un server proxy inverso in ogni sito. Nella topologia di prova, questi server eseguono Microsoft Forefront Threat Management Gateway. Ogni server che esegue Microsoft Forefront Threat Management Gateway viene eseguito in modo indipendente. In ogni sito è stato distribuito un dispositivo di bilanciamento del carico hardware.