Indicazioni di distribuzione per la replica dei dati su più siti di Exchange Server

Ultima modifica dell'argomento: 2006-09-01

La tecnologia di replica può fornire disponibilità elevata per i dati di Microsoft ® Exchange Server. Questo argomento è utile per comprendere meglio la tecnologia di archiviazione di replica e la relativa modalità di utilizzo in un ambiente Exchange Server.

La replica supporta la disponibilità elevata grazie ai dati ridondanti in più siti ma non impedisce il verificarsi di danneggiamento dei dati. Se dei dati non validi vengono scritti nella periferica di archiviazione primaria che causa il danneggiamento del database, gli stessi dati non validi si replicheranno ai siti remoti e ne danneggeranno i rispettivi database. Di conseguenza, la replica di dati non sostituisce i processi di manutenzione del database quali il backup del database, che ne convalida periodicamente l'integrità.

In questo argomento, il tipo di dati descritti sono i dati cui si accede mediante l'esecuzione dei servizi di Exchange, ad esempio una richiesta di I/O di scrittura inviata da un processo di Exchange. La replica di dati di sistema/sistema operativo non è descritta.

Microsoft dispone di criteri di supporto per i vari tipi di soluzioni di replica. Per informazioni sui criteri di supporto, vedere l'articolo 895847 della Microsoft Knowledge Base "Supporto della replica di dati su più siti per Exchange 2003 ed Exchange 2000" (informazioni in lingua inglese).

Meccanismi di replica

Lo scopo di utilizzare la replica di dati è di mantenere repliche correnti dei dati sui siti remoti. I server Exchange possono utilizzare le repliche sul sito remoto per fornire la continuità di servizio di posta elettronica nel caso di un'interruzione dell'archiviazione o del sito nella posizione primaria. La replica di dati può venire propagata in modo sincrono o asincrono. Per definizione, quando i dati sono replicati in modalità sincrona, gli host otterranno una risposta completa di scrittura dall'archivio solo quando le scritture di I/O sono salvate nelle posizioni locali e remote. In altre parole, sia l'archivio locale che l'archivio remoto devono implementare la modifica prima che la scrittura venga riconosciuta all'host come riuscita. Nella modalità asincrona, l'host otterrà una scrittura completa dall'archivio quando la scrittura sarà stata salvata nell'archivio locale, senza dover attendere dall'archivio remoto il riconoscimento che anch'esso ha aggiornato la replica.

Replica asincrona

In generale, quando l'applicazione host usa la replica asincrona non è sensibile alla distanza di replica in termini di maggior latenza della scrittura quanto lo sarebbe in modalità di replica sincrona. Tuttavia, si tengano presente i seguenti problemi quando si distribuisce la replica asincrona:

• Perdita di dati In base alla frequenza della replica dei dati, le modifiche dei dati apportate nel sito remoto possono far ritardare le modifiche apportate nel sito primario. Nel caso di un'interruzione del sito primario, la replica di sito remoto non sarà aggiornata completamente. Anche se questo ritardo è configurabile nella maggior parte delle soluzioni di archiviazione, si tenga presente la possibilità di perdita di dati a causa di questo comportamento.
• **Integrità dei dati (conservazione dell'ordine di scrittura)**Exchange presenta dipendenze di ordine di scrittura tra il database e i registri delle transazioni associate. Exchange scrive sempre le modifiche nei file di registro prima di salvare tali modifiche nei file del database. Nella modalità di replica sincrona, l'applicazione controlla l'ordine della scrittura. Nella modalità asincrona, tuttavia, la soluzione di replica controlla quando replicare i dati. Se la soluzione non conserva l'ordine di scrittura durante la replica, potrebbe danneggiare potenzialmente i file di database e impedire l'installazione dei database in caso di emergenza nel sito primario.
• Impatto sulle prestazioniMolti fornitori dichiarano che le loro soluzioni asincrone non influiscono sulle prestazioni di archiviazione, ma di fatto si avrà un degrado delle prestazioni quando si esegue la replica asincrona. A seconda dell'implementazione della soluzione, non è possibile definire con esattezza le aspettative di prestazione. Di conseguenza, i clienti dovrebbero provare approfonditamente la soluzione prima della distribuzione, allo scopo di verificare se la soluzione può fornire prestazioni di archiviazione adeguate per gli utenti di Exchange.

Alcuni fornitori di soluzioni utilizzano diverse tecnologie per risolvere il problema di conservazione dell'ordine di scrittura. Per distribuire correttamente una soluzione replicata in modo asincrono, è necessario collaborare con il fornitore per assicurare che la tecnologia asincrona soddisfi i seguenti requisiti:

• Mantenimento della coerenza dell'ordine di scrittura di tutte le periferiche in un gruppo di archiviazione, compresa la coerenza continua reciproca
• Dimostrazione della capacità di recupero, preferibilmente sia in laboratorio che in un ambiente di produzione
• Il fornitore dispone di un piano di supporto per i dati replicati.

Replica sincrona

Il problema principale per la replica sincrona nella distribuzione di Exchange è legato alle prestazioni. I test hanno mostrato che l'esperienza client è legata strettamente alla latenza della scrittura. Con una soluzione di replica sincrona, il numero di cassette postali che si possono ospitare per server di Exchange viene ridotto. L'impatto sulle prestazioni dipende ampiamente dalla distanza di replica, dalla larghezza di banda del collegamento di replica e dall'utilizzo. La replica sincrona può causare fino a una riduzione del 75% della scalabilità di cassette postali e server. Si consiglia di valutare questo fattore di riduzione di scalabilità quando si lavora sulla metodologia di pianificazione della capacità di Exchange. Per ulteriori informazioni, vedere "Pianificazione della distribuzione per la replica sincrona" più avanti in questo argomento.

Si è considerato comunemente la replica sincrona una soluzione che garantisce l'assenza di perdita di dati perché le repliche sono completamente sincronizzate con i file di dati di archiviazione primaria. Tuttavia, contrariamente a quanto si pensa, esistono scenari in cui le soluzioni di replica sincrona possono causare perdita di dati. Il seguente esempio illustra uno scenario di questo tipo.

In genere, le soluzioni di replica di dati di archiviazione gestiscono un errore di collegamento di replica in uno dei modi seguenti:

• Continuare a salvare le operazioni di I/O di scrittura solo sulla periferica di archiviazione primaria, registrare tutte le modifiche apportate a tutte le periferiche che utilizzano il collegamento di replica in un file di registro e archiviare il registro nell'archivio primario.
• Interrompere l'operazione di scrittura cosicché l'applicazione gestisca l'errore come se si fosse verificato un errore del disco.

Se la soluzione di replica utilizza il primo metodo di gestione, la perdita di dati è possibile. Durante una condizione di errore del collegamento, seguito a breve da un errore del sito primario, i dati salvati dopo l'errore di collegamento non saranno replicati e saranno pertanto persi insieme all'errore dell'archiviazione primaria. Quando si progetta la soluzione di replica di archiviazione, tenere presente questi tipi di condizioni di errore cosicché sia possibile creare un sistema per ridurre questo tipo di eventualità. In questo esempio, il cliente potrebbe valutare la distribuzione di collegamenti di replica ridondanti per ridurre la possibilità di perdita di dati.

Soluzioni di replica sincrona

Le soluzioni di replica sincrona sono classificate in base al punto in cui avviene la replica, replica basata sull'host o replica basata sull'archiviazione. La replica basata sull'host utilizza in genere il software (driver di filtro) basato sull'host per interrompere il flusso di I/O per gestire la replica. La replica basata sull'archiviazione avviene al di fuori dell'host a livello di periferica di archiviazione. Entrambe le soluzioni di replica possono essere distribuite nell'ambito di uno dei seguenti modi:

• **Clustering dislocato geograficamente (Geocluster)**In questa categoria, i nodi che appartengono allo stesso cluster si collocano in diversi siti. In genere, i server di Exchange sono ospitati attivamente dai nodi nel sito primario. Le soluzioni forniscono la replica sincrona dei dati di Exchange al sito o ai siti remoti. In caso di emergenza del sito primario, i server virtuali di Exchange eseguono il failover ai nodi passivi sul sito remoto e tornano in linea utilizzando i dati replicati di Exchange.
  In Microsoft Windows® Server Catalog è presente una categoria per le soluzioni cluster dislocati geograficamente. È possibile cercare le soluzioni di cluster dislocati geograficamente nei laboratori Microsoft per il controllo della qualità dell'hardware per Windows (WHWL, Windows Hardware Quality Labs) all'indirizzo https://go.microsoft.com/fwlink/?LinkId=28572.
• AltriQuesta categoria include tutti gli altri tipi di distribuzione di replica sincrona che non utilizzano i cluster dislocati geograficamente. Queste soluzioni si basano su altri mezzi per utilizzare i dati Exchange replicati sul sito o sui siti remoti in caso di un errore del sito primario (ad esempio, una soluzione di standby; la replica in congiunzione con i processi di ripristino di emergenza).

Microsoft consiglia vivamente di richiedere ai fornitori di soluzioni di replica delle garanzie relativamente ai seguenti problemi:

• La soluzione rientra nella categoria di soluzione di clustering dislocato geograficamente? In caso affermativo, ha la certificazione WHQL? In caso negativo, la periferica di archiviazione è elencata in una delle soluzioni descritte nella sezione "Cluster Solutions, Geographically Dispersed Clustering Solution" del Windows Server Catalog?
• La soluzione di replica impedisce totalmente la possibilità di perdita di dati a parte che nel caso di interruzione simultanea in tutti i siti?
• Quali sono le procedure di esecuzione di un failover e un failback?
• La soluzione di replica e la latenza prevista sono in grado di gestire il carico di utenti Exchange pianificato e offrire un servizio client di qualità?

Dati Exchange da replicare

Exchange è un'applicazione server incentrata sui dati. La replica di dati di Exchange a un sito secondario consente la ridondanza in caso di errori legati all'archiviazione. La determinazione del tipo esatto di dati da replicare è una decisione aziendale. Valutare il grado di tolleranza aziendale relativamente alla perdita dei vari tipi di dati qui descritti.

Dati obbligatori da replicare

I seguenti dati devono essere replicati:

• I file di database delle cassette postali di Exchange memorizzano i dati di messaggio. Ogni database è costituito di due file:
  • Il file di database (edb) che contiene i messaggi e il contenuto MAPI.
  • Il file di flusso (stm), che contiene contenuto nativo, non-MAPI.
• I file di registro delle transazioni (log) che registrano ogni transazione di salvataggio sul database.
• I file di punto di arresto (chk) che contengono le informazioni sulle voci dei file di registro che sono state scritte sul disco.

Tutti questi file sono essenziali per fornire l'accesso dei client al loro server di cassette postali e per il recupero dei dati di modifica del database che vengono tenuti in memoria e che vanno persi se gli archivi di un server di Exchange non vengono chiusi in maniera regolare, ad esempio nel caso di un'interruzione di alimentazione. Trattandosi di file di fondamentale importanza, questo set di dati deve essere replicato. I percorsi dei file di database si specificano nella pagina delle proprietà del database e ogni database ha il proprio percorso. Il percorso del file di registro delle transazioni e il percorso del file del punto di arresto si specificano nella pagina delle proprietà del gruppo di archiviazione e da essi dipendono tutti i database in quel gruppo di archiviazione.

La decisione di replicare i database di cartelle pubbliche è una decisione più complessa. Essa dipende in parte dalla progettazione della topologia di Exchange della distribuzione. A differenza dei dati della cassetta postale, i dati delle cartelle pubbliche possono venire replicati direttamente da Exchange Server. Si possono avere repliche multiple di archivi di cartelle pubbliche che replicano le modifiche (contenuto). Questa replica di dati non viene eseguita in modo sincrono.

Le soluzioni Geocluster richiedono la replica sincrona delle cartelle pubbliche all'interno del cluster. È necessario che questo requisito sia soddisfatto perché il cluster sia completamente funzionale nel sito secondario. I database delle cassette di posta all'interno del cluster devono puntare all'archivio di cartelle pubbliche (Archivio pubblico predefinito) che è presente anche all'interno del cluster cosicché i client possano accedere immediatamente non appena il cluster è disponibile nel sito secondario. Le cartelle pubbliche dentro il geocluster devono ospitare solo la gerarchia e non necessariamente tutto il contenuto per facilitare l'accesso alla cassetta postale durante una condizione di errore. L'opzione di ospitare l'intero contenuto delle cartelle pubbliche e replicarlo in modalità sincrona nelle cartelle pubbliche ospitate nel geocluster è una decisione aziendale. Se i dati delle cartelle pubbliche sono essenziali per l'azienda, ovvero se è tollerabile solo una minima quantità di perdita di tali dati, allora si prenda in considerazione l'utilizzo di una soluzione geocluster invece del meccanismo di replica della cartella pubblica di Exchange. Se questo livello di disponibilità dei dati di cartella pubblica non è necessario, è possibile utilizzare una soluzione di replica sincrona non-geocluster per i dati di cassetta combinata con il meccanismo di replica che si trova nelle cartelle pubbliche di Exchange.

Dati da replicare consigliati

I dati della coda locale del Simple Mail Transfer Protocol (SMTP), directory Mailroot, sono temporaneamente contenuti nella periferica di archiviazione mentre vengono elaborati da Exchange Server. Questa progettazione impedisce la perdita dei dati in caso di un errore del server. Ad esempio, quando un server di destinazione non è raggiungibile, i messaggi che si dovrebbero instradare a quel server saranno archiviati nella directory di coda del server locale fino a quando possono essere recapitati. In caso di errore del disco che memorizza i dati della coda, tutti i messaggi nella coda andranno perduti. A causa della natura transitoria dei dati della coda, non c'è nessun processo definito per il backup delle code di posta come esiste per il backup dei database di Exchange Server. Fornire la tolleranza d'errore e/o le soluzioni di disponibilità elevata per l'archiviazione che contiene queste informazioni di coda può proteggere dalla potenziale perdita di dati. Si consiglia inoltre di replicare i dati della coda MTA (directory MTADATA) in quegli ambienti in cui la perdita dei messaggi transitori a causa di errori del sito non è accettabile.

Il percorso della Mailroot dell'SMTP (che include le directory Queue e Badmail per l'istanza di server virtuale) è specificato nella scheda Messaggi della pagina delle proprietà del server virtuale SMTP nel Gestore di sistema di Exchange (ESM, Exchange System Manager) e nella pagina delle proprietà X.400 per il percorso di coda MTA. Considerare il proprio profilo per decidere se è necessario replicare i dati della coda di Exchange. Se si dispone di una topologia esistente di Exchange, è possibile decidere di potere tollerare la perdita di dati nella coda locale. È possibile misurare la quantità prevista di dati nella coda locale utilizzando la lunghezza di coda locale in Performance Monitor (Perfmon.msc) o il Visualizzatore code del Gestore di sistema Exchange, durante i periodi di picco del carico. Se per i dati della coda è necessaria la replica, è importante verificare le prestazioni di elaborazione dei messaggi nell'ambiente di replica, in modo che la latenza di replica introdotta non crei un collo di bottiglia per il trasporto. È possibile utilizzare lo strumento Stress Exchange Server e Performance 2003 per verificare la portata del trasporto in un ambiente di replica sincrono in cui vengono replicati i dati della coda. È possibile scaricare lo strumento dal sito Web Exchange Server Stress and Performance 2003.

Dati opzionali da replicare

I registri di verifica dei messaggi contengono le informazioni su tutti i messaggi trasferiti verso, da e all'interno di un server di Exchange. Questi dati possono essere importanti per scopi diagnostici. Per impostazione predefinita, la verifica dei messaggi non è attivata. Tuttavia, se questo dato è importante per l'azienda, è possibile replicarlo per evitare la perdita in caso di un'emergenza. Il percorso per il registro della verifica dei messaggi si specifica nella pagina delle proprietà di Exchange Server nel Gestore di sistema di Exchange.

Procedure consigliate per la configurazione dei meccanismi di replica

Ogni fornitore dispone di varie implementazioni proprietarie per i meccanismi di replica che forniscono diverse opzioni di replica. Consultare il fornitore specifico per discutere la soluzione e determinare se quella proposta è la più adatta a soddisfare i requisiti dell'azienda e il Contratto di livello di servizio (SLA, Service Level Agreement) per il ripristino di emergenza. Le seguenti raccomandazioni si possono applicare solo a determinate soluzioni di replica:

• Configurare la replica al livello del volume nel punto di montaggio/logico.
  Sebbene i dati da replicare siano contenuti nei file descritti nella sezione "Dati Exchange da replicare" di questo argomento, è necessario assicurarsi che, a livello di host, la replica sia configurata per l'unità di un volume del punto di montaggio/logico. Ad esempio, se il percorso dei dati della cassetta postale è G:\MDB1\MDB1.EDB, l'unità G dovrebbe essere quindi l'unità di base che esegue la replica. Tutti i dati sull'unità G saranno replicati di conseguenza. L'impostazione della replica al livello di file o di sottodirectory è soggetta all'errore umano e non è supportata da Microsoft.
• Creare più punti di replica.
  Per ridurre l'accodamento di più I/O destinati allo stesso punto di replica, configurare l'archiviazione in modo da creare più punti di replica possibile. Bilanciare il carico degli I/O su più punti di replica. In base alla soluzione di archiviazione/ replica, questo approccio può ridurre la latenza complessiva di lettura/scrittura di I/O grazie alla riduzione dell'accodamento I/O.
• Tenere i registi delle transazioni su volumi logici diversi.
  Quando i dati sono replicati, ogni richiesta di I/O di scrittura si accoda al livello del punto di replica. Exchange scrive i registri secondo un modello sequenziale e, nel caso in cui tali I/O sono destinati allo stesso punto di replica, vi sono buone possibilità che ogni I/O venga accodato per la scrittura. Questa situazione contribuisce ad allungare i tempi di risposta di scrittura sul registro, dando luogo a un fattore negativo importante per le prestazioni e la scalabilità di Exchange. Per questo motivo, Microsoft consiglia di segmentare i registri delle transazioni di gruppi di archiviazione diversi su volumi logici diversi con punti di replica diversi.
• Utilizzare più collegamenti di replica.
  Spesso è possibile migliorare le prestazioni e la scalabilità della soluzione di replica configurando più collegamenti di replica tra i siti primari e secondari . L'implementazione di questo approccio può essere costosa e non è necessaria per la replica di dati di Exchange. Tuttavia, vi sono distribuzioni che devono implementare più collegamenti di replica per ottenere le prestazioni/scalabilità desiderati per una determinata soluzione di replica di dati Exchange. Potrebbe inoltre essere necessario bilanciare il carico dei punti di replica sui collegamenti di replica disponibili per raggiungere una velocità ottimale.
  In Exchange vi è dipendenza dell'ordine di scrittura tra i database e i registri delle transazioni associati, per questo motivo è importante configurare un gruppo di punti di replica che supportino i volumi logici del gruppo di archiviazione (che includono il numero di database di unità logica (LUN) e il registro LUN) in modo che utilizzi lo stesso collegamento di replica. Questa configurazione è necessaria per mantenere l'ordine di scrittura a livello di gruppo di archiviazione, condizione essenziale per mantenere l'integrità dei dati sul sito remoto in caso di scenari di errore quali un errore di collegamento.
  L'utilizzo di più collegamenti di replica con più punti di replica può essere un approccio efficace per la scalabilità di una soluzione di replica di dati Exchange. Questo approccio potrebbe inoltre ridurre la possibilità di perdita di dati, descritta nell'esempio della sezione precedente "Replica Sincrona".

Procedure consigliate per configurare Exchange per la replica sincrona

Quando Exchange viene distribuito in un ambiente per la replica sincrona, alcune modifiche di configurazione consentono di migliorare le prestazioni/scalabilità del server. È importante comprendere queste modifiche in fase di pianificazione, in modo da poterle implementare durante la progettazione dell'archiviazione e della replica. Di seguito sono riportate le procedure consigliate per la configurazione:

• Creare il numero massimo dei gruppi di archiviazione per server Exchange.
  L'aumento del numero dei gruppi di archiviazione in una soluzione Exchange di replica sincrona può migliorare le prestazioni/scalabilità della distribuzione in quanto bilancia il carico delle transazioni di scrittura sul registro su più volumi logici e, di conseguenza, su più punti di replica. In generale, vi saranno più processi paralleli di scrittura sul registro, con la conseguente riduzione della latenza complessiva di scrittura sul registro transazioni, ovvero la riduzione dell'accodamento I/O, nell'ambiente di replica sincrona. Exchange Server 2003 Enterprise Edition consente quattro gruppi di archiviazione per ciascun server Exchange.
• Aumentare la dimensione del buffer del registro delle transazioni.
  La latenza delle operazioni di I/O di scrittura sul registro Exchange rappresenta un importante fattore di scalabilità nelle soluzioni di replica sincrona Exchange. Le operazioni di I/O di scrittura sul registro sono sequenziali e a coda singola, di conseguenza le probabilità che si crei un collo di bottiglia nel sistema sono alte. Le operazioni I/O di registro vengono scritte dapprima sui buffer di registro, quindi il buffer viene vuotato mediante un salvataggio non-lazy commit o un commit di capacità. Il non-lazy commit indica che il buffer di registro viene scritto immediatamente sul disco. Un commit di capacità indica che il buffer di registro viene scritto sul disco quando il buffer è pieno.
  L'aumento della dimensione del buffer di registro consente di ridurre la frequenza di salvataggi di capacità, aumenta la dimensione di scrittura di registro e di conseguenza riduce la latenza complessiva di scrittura sul registro. La riduzione della latenza di scrittura delle operazioni I/O sul registro rappresenta un metodo importante per migliorare le prestazioni/scalabilità dell'installazione di Exchange.
  La raccomandazione generale è di aumentare la dimensione di buffer fino a un massimo di 9.000 se la replica avviene su Fibre Channel. Per i collegamenti a larghezza di banda ridotta, quali i collegamenti TCP/IP, non è semplice determinare un valore ottimale per questo parametro. Se il collegamento appare saturo per l'aumento delle scritture su registro, con conseguente rallentamento della replica, eseguire delle prove per determinare la dimensione ottimale del buffer di registro in modo da ridurre al minimo la latenza della scrittura sul registro. Per informazioni sulla modifica del parametro, vedere l'articolo 328466 della Knowledge Base "L'impostazione dei buffer di registro ESE su un valore troppo basso può causare l'interruzione di risposta da parte dell'archivio". Consultare inoltre il fornitore della soluzione relativamente a questa impostazione.

Pianificazione della distribuzione per la replica sincrona

Sebbene siano state seguite tutte le raccomandazioni descritte in precedenza, la soluzione di archiviazione di replica sincrona può presentare problemi di prestazioni per i client di Exchange se non è stata verificata accuratamente prima della distribuzione. Non esistono regole fisse per gli effetti negativi sulle prestazioni/scalabilità legati all'implementazione della replica sincrona con Exchange. Ogni soluzione di replica Exchange presenta fattori di prestazioni diversi che possono includere, ma non sono soltanto, quelli indicati di seguito: distanza tra i siti, meccanismo di trasporto di replica, numero di collegamenti di replica, numero di punti di replica, numero di gruppi di archiviazione di Exchange, impostazioni di configurazione del database/registro Exchange, architetture di archiviazione e replica, profilo dei client Exchange. Ogni soluzione è univoca e richiede una pianificazione attenta e verifiche accurate per una buona distribuzione.

La latenza di scrittura di I/O nelle soluzioni di replica sincrona è il fattore chiave per limitare la scalabilità di Exchange. L'aumento della latenza di I/O crea un carico sul server che può avere forti ripercussioni sulle prestazioni del client Exchange. In particolare, l'alta latenza di scrittura provoca un aumento della latenza RPC che rallenta le operazioni del client. La replica sincrona consente la disponibilità elevata dei dati di Exchange, ma allo stesso tempo comporta una perdita significativa delle prestazioni di I/O. Il decadimento delle prestazioni di scrittura, e a volte di lettura, dell'I/O è un fattore critico per determinare il numero massimo di utenti che una data piattaforma può supportare.

Nella fase di pianificazione, eseguire le seguenti operazioni per convalidare la progettazione:

1. Per informazioni sui metodi di progettazione e di implementazione dell'archiviazione per Exchange, vedere Optimizing Storage for Exchange 2003.
2. Utilizzare il test Jetstress per convalidare la velocità dell'archiviazione con configurazione di replica sincrona. Per scaricare lo strumento Jetstress, vedere il sito Web Microsoft Exchange Server Jetstress Tool.
3. Misurare l'effetto dell'aumento della latenza della scrittura sul client di posta elettronica eseguendo un test Exchange Server Load Simulator 2003 (LoadSim) adeguato per il proprio ambiente. Per scaricare LoadSim, vedere il sito Web Microsoft Exchange Server 2003 Load Simulator (LoadSim).
4. Misurare la produttività media del disco quando si esegue LoadSim. La produttività del disco deve essere uguale o maggiore alla produttività media di picco prevista per l'ambiente di produzione simulato (IOPS/Mailbox). Per informazioni dettagliate sulla misurazione della produttività media di picco del disco, vedere Optimizing Storage for Exchange 2003.
5. Osservare attentamente il contatore della latenza media della RPC sul tempo di risposta del server e del client dopo aver eseguito i test di LoadSim. Quando si analizzano i risultati dei test, si tenga presente che tutti e tre i contatori devono soddisfare i criteri elencati di seguito.
   Latenza media RPC
   Questo contatore visualizza il tempo medio necessario per elaborare una singola richiesta di chiamata a procedura remota (RPC). L'aumento del carico di utenti o della distanza di replica comporterà un aumento della latenza media della RPC. Il limite massimo di media è 50 ms e il valore massimo dovrebbe essere 100 ms. Se i risultati di test mostrano un media sopra i 50 ms, le prestazioni generali del client saranno lente. Se la media è inferiore a 50 ms, ma occasionalmente raggiunge punte di 100 ms, le prestazioni del client saranno lente in occasione di tali punte.
   Contatori di latenza sul disco
   Il team di produzione di Microsoft Exchange ha sottoposto a test di diverse soluzioni di hardware di replica sincrona. I risultati indicano le connessioni fra la latenza media RPC e le latenze sul disco. In generale, la soluzione riesce a gestire un determinato carico quando la media della latenza di lettura del database è inferiore ai 20 ms e la media delle latenze di scrittura e lettura sul registro sono inferiori ai 20 ms. I valori massimi di queste latenze si dovrebbero mantenere sotto i 40 ms. Sopra queste soglie, i client avranno probabilmente tempi di risposta più lenti.
   Tempo di risposta del client
   È possibile confermare le prestazioni generali del client eseguendo lslog.exe in tutti i computer client. Questa attività restituisce la media ponderata del 95° percentile, il valore deve essere inferiore a 1.000 ms. lslog.exe fa parte dello strumento LoadSim. La documentazione di LoadSim illustra come utilizzare Islog.exe e come interpretare i risultati che fornisce.
   Per ulteriori informazioni sulle prestazioni, vedere Troubleshooting Exchange Server 2003 Performance.
6. Verificare la soluzione per il profilo della cassetta postale a fronte della distanza di replica pianificata. La distanza di collegamento di replica presenta una limitazione fisica. All'aumento della distanza corrisponde un rallentamento del tempo di risposta client/server a causa delle maggiori latenze di scrittura che si verificano per la replica sincrona sulla distanza. In generale, si considera la soglia di 100 km per la replica sincrona dei dati di archiviazione di Exchange Server. Questo valore di soglia può variare a seconda dell'implementazione della soluzione.
7. Creare un piano di backup che convalidi l'integrità del database a un intervallo regolare. La replica non sostituisce il processo di backup.
8. Assicurarsi di disporre di un piano di ripristino di emergenza completo che sia stato testato con la stessa attenzione delle prestazioni di replica della soluzione. Esistono diversi metodi di recupero dei dati, dei server e dei siti di Exchange. Implementare un piano di ripristino di emergenza che soddisfi i requisiti aziendali e dei Contratti di servizio che guidino attraverso fasi di ripristino veloci ed efficienti in caso di emergenza. Verificare e convalidare il piano simulando più tipi di condizioni di errore in una distribuzione di Exchange che utilizza la replica sincrona in condizioni di carico intenso.