Risultati dei test

Latenza del collegamento del sito centrale

È stato utilizzato un simulatore di latenza di rete per introdurre la latenza nel collegamento WAN simulato tra i siti Nord e Sud. La topologia consigliata supporta una latenza massima di 20 ms tra i siti geografici. Miglioramenti apportati all'architettura di Lync Server 2010 consentono una latenza superiore a quella massima supportata di 15 nella topologia con resilienza di siti metropolitani di Microsoft Office Communications Server 2007 R2.

• 15 ms.   È stata introdotta inizialmente una latenza di round trip di 15 ms sia nel percorso di rete tra i due siti che nel percorso dati utilizzato per la replica dei dati tra i due siti. La topologia ha continuato a funzionare senza problemi in queste condizioni e sotto carico.

• 20 ms.   Successivamente si è iniziato ad aumentare la latenza. Con una latenza di round trip di 20 ms per il traffico di rete e di dati, la topologia ha continuato a funzionare senza problemi. 20 ms è la latenza di round trip massima supportata per questa topologia in Lync Server 2010.

  Importante:
  Microsoft non supporterà soluzioni con latenza di rete e di dati superiore a 20 ms.

• 30 ms.   Con una latenza di round trip di 30 ms si inizia a osservare un peggioramento delle prestazioni, in particolare un aumento delle dimensioni delle code dei messaggi per i database di archiviazione e di monitoraggio. Come conseguenza dell'aumento della latenza è peggiorata anche l'esperienza utente. Sono aumentati i tempi di accesso e di creazione di conferenze e si è verificato un peggioramento significativo delle funzionalità A/V. Per questi motivi Microsoft non supporta una soluzione con una latenza di round trip superiore a 20 ms.

Failover

Come affermato precedentemente, in tutti i cluster di Windows Server 2008 R2 della topologia è stato utilizzato un quorum di tipo Maggioranza dei nodi e delle condivisioni file. Per simulare il failover dei siti è stato necessario pertanto isolare tutti i server e i cluster perdendo connettività con il sito Sud e il sito di controllo. Tutti i server nel sito Nord inoltre sono stati chiusi in modo anomalo.

I risultati e le conclusioni dopo l'errore del sito Nord sono i seguenti:

• Il nodo del cluster di SQL Server passivo è diventato attivo in pochi minuti. Il tempo può variare a seconda dei dettagli dell'ambiente. Gli utenti interni connessi al sito Nord sono stati disconnessi e quindi riconnessi automaticamente. Durante il failover, le informazioni sulla presenza non sono state aggiornate e nuove azioni, ad esempio nuove sessioni di messaggistica istantanea o nuove conferenze, hanno avuto esito negativo con messaggi appropriati. Dopo il failover non si sono verificati altri errori.

• In presenza di un percorso di rete valido tra peer, le chiamate peer-to-peer in corso non sono state interrotte.

• Le chiamate UC-PSTN sono state disconnesse in caso di non disponibilità del gateway che supportava la chiamata. In tal caso, gli utenti hanno potuto ristabilire manualmente la chiamata.

• Gli utenti di Lync 2010 connessi al sito Nord sono stati disconnessi e automaticamente riconnessi al sito Sud in pochi minuti per continuare normalmente le operazioni.

• Per la riconnessione, gli utenti dei client Group Chat hanno dovuto disconnettersi e quindi rieseguire l'accesso. I servizi canali e di ricerca di Group Chat nel sito Sud, che in genere vengono arrestati o disabilitati nel sito, sono stati sottoposti ad avvio manuale.

• Si è verificato il failover automatico nel sito Sud per le conferenze ospitate nel sito Nord. Dopo il failover è stato richiesto a tutti gli utenti di riaccedere alla conferenza. I client hanno potuto riaccedere alla riunione. La registrazione della riunione non si è interrotta durante il failover. L'archiviazione invece si è interrotta finché non è stato riconnesso il server di archiviazione hot standby.

• La gestibilità ha continuato a funzionare durante l'inattività del sito Nord. È stato possibile ad esempio spostare gli utenti dal Survivable Branch Appliance al pool Front End.

• Dopo la disconnessione del sito Nord, i cluster di SQL Server e i cluster di condivisione file nel sito Sud sono stati connessi in pochi minuti.

• La durata del failover dei siti osservata nei test è stata di pochi minuti.

Failback

Ai fini dei test, è stato definito il failback come ripristino di tutte le funzionalità nel sito Nord in modo che gli utenti potessero riconnettersi ai server di tale sito. Dopo il ripristino del sito Nord, tutte le risorse dei cluster sono state spostate di nuovo nei relativi nodi nel sito Nord.

È consigliabile eseguire il failback in modo controllato, preferibilmente fuori orario, poiché durante le procedure di failback è possibile che gli utenti vengano disconnessi. I risultati e le conclusioni dopo il failback del sito Nord sono i seguenti:

• Prima di spostare di nuovo le risorse dei cluster nei rispettivi nodi nel sito Nord, è stata necessaria la risincronizzazione completa dello spazio di archiviazione, altrimenti non sarebbe stato possibile per i cluster riconnettersi. La risincronizzazione dello spazio di archiviazione è stata eseguita automaticamente.

• Per un impatto minimo sugli utenti, i cluster sono stati impostati in modo da non eseguire automaticamente il failback. È consigliabile rimandare il failback alla successiva finestra temporale per la manutenzione, dopo essersi accertati che lo spazio di archiviazione sia stato risincronizzato completamente.

• I Front End Server risultano disponibili online nel momento in cui sono in gradi di connettersi a Servizi di dominio Active Directory. Se il database back-end non è ancora disponibile nel momento in cui i Front End Server sono online, gli utenti potranno usufruire di funzionalità limitate.

  Dopo che i Front End Server del sito Nord sono online, vengono instradate nuove connessioni a tali server. Gli utenti online che in genere si connettono tramite i Front End Server nel sito Nord verranno disconnessi e quindi riconnessi nel consueto server del sito Nord.

  Se si desidera impedire ai Front End Server nel sito Nord di riconnettersi automaticamente, ad esempio per esercitare un maggiore controllo sull'intero processo o se non sono stati ripristinati livelli accettabili di latenza tra i due siti, è consigliabile arrestare i Front End Server.

• La durata del failback dei siti osservata nei test è stata inferiore a un minuto.