Pianificazione di una replica continua di standby

  • Articolo

 

Si applica a: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1

Ultima modifica dell'argomento: 2008-09-11

Sebbene la distribuzione di una replica continua di standby (SCR, Standby Continuous Replication) sia simile alla distribuzione di una replica continua locale (LCR, Local Continuous Replication), esistono differenze importanti da non trascurare. È necessario soddisfare requisiti generali per la replica continua di standby.

Requisiti generali per la replica continua di standby

Prima di abilitare gruppi di archiviazione per la replica continua di standby, è consigliabile acquisire familiarità con i seguenti requisiti per le origini e le destinazioni SCR:

  • Per ogni origine possono esistere più destinazioni. Per un'origine, ad esempio, può esistere una destinazione nello stesso centro dati e un'altra in un centro dati diverso. Non esiste alcun limite al numero delle destinazioni possibili per ogni origine. È consigliabile, tuttavia, non utilizzare più di quattro destinazioni per ogni origine. Qualora vengano configurate più di quattro destinazioni, è necessario verificare e pianificare l'impatto aggiuntivo sul server di origine.

  • Per ogni destinazione possono esistere più server di origine. È necessario che, sia nel sistema di origine sia in quello di destinazione, venga eseguito Exchange 2007 SP1. Il sistema operativo può essere qualsiasi sistema operativo supportato da Exchange 2007 SP1 (ad esempio Windows Server 2008 o Windows Server 2003). Tuttavia, tutti i computer di destinazione SCR devono eseguire lo stesso sistema operativo del computer SCR di origine. Non è supportato l'utilizzo di sistemi operativi diversi per un'origine SCR e per le relative destinazioni (ad esempio, se l'origine SCR è Windows Server 2003 e la destinazione SCR è Windows Server 2008 o viceversa).

  • È necessario che nel computer di destinazione SCR sia installato il ruolo del server Cassette postali di Exchange 2007 SP1. Se il computer di destinazione SCR è un nodo del cluster, tale nodo deve essere passivo (ovvero, nel nodo è installato il ruolo cassette postali in cluster passivo) e il cluster non può includere server di cassette postali in cluster.

  • Se si intende utilizzare un cluster di standby e la funzionalità di ripristino del server Cassette postali (Setup /RecoverCMS) come parte del processo di attivazione della destinazione SCR, è necessario pianificare attentamente i percorsi di installazione dei server Exchange. Per utilizzare il processo di ripristino del server, è necessario che il percorso di installazione del server Exchange sia uguale a quello dei computer di origine e di destinazione della replica continua di standby. Se il server Exchange viene installato in %ProgramFiles%\Microsoft\Exchange Server nel computer di origine della replica continua di standby (SCR), è necessario che venga installato in %ProgramFiles%\Microsoft\Exchange Server anche per tutti i computer di destinazione SCR relativi al server di origine SCR. Se i percorsi di installazione non corrispondono, l'esecuzione di Setup /RecoverCMS ha esito negativo perché il percorso di installazione del Registro di sistema non corrisponde al valore dell'attributo msExchInstallPath dell'oggetto server Cassette postali nel servizio directory di Active Directory.

  • Se il processo di attivazione include il ripristino di un server di cassette postali in cluster, è necessario disattivare la replica continua di standby per tutti i gruppi di archiviazione nel server di cassette postali in cluster prima di utilizzare Setup /RecoverCMS come parte del processo di attivazione. Se la replica continua di standby non viene disattivata per tutti i gruppi di archiviazione, il processo di Setup /RecoverCMS non viene eseguito.

  • I percorsi del gruppo di archiviazione e dei database nell'origine e in tutte le destinazioni SCR non devono essere in conflitto con altri percorsi di gruppi di archiviazione o di database. Se si utilizza la replica continua di standby, è necessario pianificare i percorsi del gruppo di archiviazione e dei database con maggiore attenzione, in quanto il percorso del gruppo di archiviazione e dei database utilizzati da un'origine SCR verranno utilizzati per la copia del gruppo di archiviazione e dei database in tutte le destinazioni SCR dell'origine.

  • È necessario che i computer di origine e di destinazione SCR si trovino nello stesso dominio di Active Directory, anche se possono risiedere nello stesso sito Active Directory o in siti diversi.

  • In Exchange 2007 Enterprise Edition ogni computer di destinazione supporta un massimo di 50 destinazioni SCR, ossia 50 gruppi di archiviazione replicati, mentre in Exchange 2007 Standard Edition viene supportato un massimo di 5 destinazioni SCR.

Restrizioni per i computer di destinazione SCR

Quando un nodo passivo o un server Cassette postali autonomo viene configurato come destinazione SCR, vengono bloccate le seguenti funzionalità:

  • In un server Cassette postali autonomo, designato come destinazione SCR, non è possibile abilitare la replica LCR per alcun gruppo di archiviazione. Il servizio di replica di Microsoft Exchange non è stato progettato o modificato per gestire sia la replica LCR che la replica proveniente da un'altra origine.

  • È necessario che il nodo passivo designato come destinazione SCR appartenga a un cluster di failover privo di server di cassette postali in cluster. Tale cluster è definito cluster di standby. Per ulteriori informazioni sui cluster di standby, vedere Disponibilità elevata.

Replica continua di standby e database delle cartelle pubbliche

La replica continua di standby e la replica delle cartelle pubbliche sono due forme di replica ben distinte incorporate in Exchange. Per via delle limitazioni di interoperabilità tra la replica continua e la replica delle cartelle pubbliche, se nell'organizzazione di Exchange vi sono più server Cassette postali contenenti un database di cartelle pubbliche, la replica delle cartelle pubbliche è abilitata e i database delle cartelle pubbliche non devono essere ospitati in un ambiente SCR.

Nota

Poiché la portabilità dei database può essere utilizzata solo con i database delle cassette postali, l'attivazione per una copia di destinazione della replica continua di standby di un database delle cartelle pubbliche può essere eseguita soltanto come parte di un'operazione di ripristino di un server o di un server di cassette postali in cluster (ad esempio, Setup /m:recoverServer, or Setup /recoverCMS).

Di seguito sono elencate alcune configurazioni consigliate per l'utilizzo di database delle cartelle pubbliche e della replica continua di standby nell'organizzazione di Exchange:

  • Se nell'organizzazione di Exchange si dispone di un singolo server Cassette postali e quest'ultimo è un server Cassette postali autonomo o un server di cassette postali in cluster in un ambiente SCC, il server Cassette postali può ospitare un database delle cartelle pubbliche e il gruppo di archiviazione contenente il database delle cartelle pubbliche può essere abilitato alla replica continua di standby, a condizione che il gruppo di archiviazione non sia abilitato per la replica continua locale. In questa configurazione, nell'organizzazione di Exchange è presente un singolo database delle cartelle pubbliche, pertanto la replica delle cartelle pubbliche è disabilitata. In questo scenario la ridondanza dei database delle cartelle pubbliche si ottiene utilizzando la replica continua di standby, che consente di conservare due copie del database delle cartelle pubbliche.

  • Se si dispone di più server Cassette postali, soltanto uno di questi contiene un database delle cartelle pubbliche e tale server è un server Cassette postali autonomo o un server di cassette postali in cluster in un ambiente SCC, il server Cassette postali può ospitare un database delle cartelle pubbliche e il gruppo di archiviazione contenente il database delle cartelle pubbliche può essere abilitato alla replica continua di standby, a condizione che il gruppo di archiviazione non sia abilitato per la replica continua locale. In questa configurazione, nell'organizzazione di Exchange è presente un singolo database delle cartelle pubbliche, pertanto la replica delle cartelle pubbliche è disabilitata. Anche in questo scenario la ridondanza dei database delle cartelle pubbliche si ottiene utilizzando la replica continua di standby.

  • Se si sta eseguendo la migrazione dei dati delle cartelle pubbliche verso un gruppo di archiviazione abilitato alla replica continua di standby, è possibile utilizzare la replica delle cartelle pubbliche per spostare il contenuto di un database delle cartelle pubbliche da un server Cassette postali autonomo o un server di cassette postali in cluster presente in un ambiente SCC verso un gruppo di archiviazione abilitato alla replica continua di standby. Una volta completata la replica, tutti i database delle cartelle pubbliche all'esterno dei gruppi di archiviazione abilitati alla replica continua di standby devono essere rimossi e nell'organizzazione di Exchange non devono essere ospitati altri database delle cartelle pubbliche.

  • Se si sta eseguendo la migrazione dei dati delle cartelle pubbliche da un gruppo di archiviazione abilitato alla replica continua di standby, è possibile utilizzare la replica delle cartelle pubbliche per spostare il contenuto di un database delle cartelle pubbliche da un gruppo di archiviazione a un server Cassette postali o un server di cassette postali in cluster presente in un ambiente SCC. Una volta completata la replica, tutti i database delle cartelle pubbliche all'interno del gruppo di archiviazione abilitato alla replica continua di standby devono essere rimossi e tutti i database delle cartelle pubbliche creati successivamente non devono essere ospitati in gruppi di archiviazione abilitati alla replica continua di standby.

Durante un intervallo di tempo in cui nell'organizzazione di Exchange esistono più database delle cartelle pubbliche e uno o più database sono ospitati in un gruppo di archiviazione abilitato alla replica continua di standby, se si verifica un errore nel gruppo di archiviazione SCR attivo ed è necessario attivare un database delle cartelle pubbliche di destinazione SCR, quest'ultimo può essere montato soltanto se sono disponibili tutti i registri per il gruppo di archiviazione che ospita il database delle cartelle pubbliche. Se alcuni registri risultano mancanti o non disponibili come risultato di un errore dell'origine SCR, non sarà possibile attivare la copia di destinazione SCR del database delle cartelle pubbliche. In questo caso, l'origine SCR deve essere portata in linea al fine di evitare una perdita di dati, oppure il database delle cartelle pubbliche deve essere ricreato nell'origine SCR e il relativo contenuto deve essere recuperato utilizzando la replica delle cartelle pubbliche da un database delle cartelle pubbliche diverso da quello della copia di destinazione SCR.

Replica continua di standby e backup

Non è possibile eseguire il backup di una copia di destinazione SCR. La replica continua locale e la replica continua di standby supportano la funzionalità di backup sia della copia attiva, sia della copia passiva. La replica continua di standby supporta solo il backup dell'origine SCR. Quando per il gruppo di archiviazione dell'origine SCR viene eseguito un backup supportato, le intestazioni del database di destinazione SCR vengono aggiornate e i file di registro vengono troncati. Se si abilita il gruppo di archiviazione dell'origine SCR per la replica continua cluster o la replica continua locale, quando si eseguono backup delle copie attive o passive del gruppo di archiviazione dell'origine SCR le intestazioni del database della destinazione SCR vengono aggiornate e i file di registro vengono troncati.

Replica continua di standby e ripristini

Quando un database di origine SCR viene sostituito con una versione precedente del database, è necessario sospendere e successivamente riprendere la replica continua per il gruppo di archiviazione, utilizzando Suspend-StorageGroupCopy e Resume-StorageGroupCopy, rispettivamente. Questo processo è necessario per aggiornare il servizio di replica di Microsoft Exchange con le informazioni di generazione del registro corrette. Se la replica continua non viene sospesa e ripresa, il servizio di replica disporrà di informazioni di generazione del registro obsolete e interromperà la replica dei file di registro.

Replica continua di standby e troncamento dei file di registro

In Exchange 2007 RTM le regole vengono applicate in modo che in un ambiente di replica continua un file di registro non viene eliminato fino a quando non ne viene eseguito il backup e la riesecuzione nella copia del database. Quando si utilizza la replica continua di standby, questa regola viene modificata. Nella replica continua di standby, che introduce il concetto di copie multiple del database, i file di registro nell'origine SCR possono essere troncati non appena siano stati ispezionati da tutti i computer di destinazione SCR. Il troncamento dei file di registro dell'origine SCR non attende la riesecuzione di tutti i file di registro in tutte le destinazioni SCR perché è possibile configurare le relative copie definendo un significativo ritardo di riesecuzione dei file di registro. Tuttavia il troncamento dei file di registro in un'origine SCR non si verificherà se una o più destinazioni SCR per un gruppo di archiviazione sono inattive. Perché i file di registro vengano troncati in un'origine SCR, è necessario che i computer SCR di destinazione siano in linea e accessibile dall'origine.

In una destinazione SCR, ogni tre minuti viene eseguito un thread in background per determinare l'eventuale necessità di troncamento dei file di registro. Un file di registro in una destinazione SCR viene troncato se vengono soddisfatti i tre criteri seguenti:

  • Il file di registro è stato troncato nell'origine SCR.

  • La sequenza di generazione dei file di registro è al di sotto del punto di arresto dei file di registro del gruppo di archiviazione.

  • Il file di registro è precedente a ReplayLagTime + TruncationLagTime. Per una descrizione di questi parametri, vedere "Aggiornamenti dei cmdlet per la replica continua di standby" nell'argomento Replica continua di standby.

In un ambiente LCR o CCR esteso con replica continua di standby, un file di registro viene troncato nella copia attiva e nella copia passiva se vengono soddisfatti i tre criteri seguenti:

  • È stato eseguito il backup del file di registro.

  • La sequenza di generazione dei file di registro è al di sotto del punto di arresto dei file di registro del gruppo di archiviazione.

  • Il file di registro è stato ispezionato da tutte le destinazioni SCR.

Ottimizzazione della connessione di rete di Windows 2003 per la replica continua di standby

Sebbene non siano richieste ottimizzazioni di rete quando si utilizza la replica continua di standby in Windows Server 2008, quando si utilizza la replica continua di standby in Windows Server 2003 si consiglia di ottimizzare le impostazioni Windows Server TCP/IP per la velocità e la latenza specifiche della connessione di rete. In particolare, può essere necessario regolare la dimensione della finestra di ricezione del protocollo TCP (Transmission Control Protocol) e le opzioni di scalabilità della finestra di Request for Comments (RFC) 1323 in un computer di origine SCR e nei relativi computer di destinazione SCR. Inoltre, potrebbe essere utile configurare le impostazioni di scadenza della cache del protocollo di risoluzione degli indirizzi (ARP, Address Resolution Protocol) e disattivare le opzioni TCP/IP avanzate per Windows Server 2003 Scalable Networking Pack (SNP) nel Registro di sistema di Windows.

Oltre a questi consigli, se il proprio ambiente include l'utilizzo del protocollo IPsec (IP Security), è consigliabile configurare IPsec in modo coerente in tutto l'ambiente di replica continua di standby. L'origine SCR e tutte le relative destinazioni dovranno usare IPsec oppure né l'origine SCR né le relative destinazioni dovranno utilizzare il protocollo. Se solo un nodo è configurato per utilizzare IPsec, il processo dell'associazione di protezione IPsec può causare un ritardo o la perdita del pacchetto.

Finestre di ricezione TCP e opzioni di scalabilità di RFC 1323

La dimensione della finestra di ricezione TCP è la quantità massima di dati (in byte) che possono essere ricevuti simultaneamente su una connessione. Il computer di invio è in grado di inviare solo quella quantità massima di dati prima di attendere un acknowledgment e un aggiornamento della finestra TCP dal computer di ricezione. Potrebbe essere utile regolare questa impostazione per aumentare la velocità di trasmissione durante il log shipping.

Per ottimizzare la velocità di trasmissione TCP, il computer di invio dovrebbe trasmettere un numero sufficiente di pacchetti per riempire la pipe tra il mittente e il destinatario. La capacità della pipe di rete è basata sulla larghezza di banda della pipe e la sua latenza (tempo di andata e ritorno). Maggiore la latenza, maggiore la capacità disponibile, perché è maggiore il tempo per inviare dati tra acknowledgment. Se si aumenta la dimensione della finestra TCP, il sistema può sfruttare il tempo tra acknowledgment inviando altri dati.

Lo standard TCP/IP consente una dimensione della finestra di ricezione fino a 65.535 ottetti, che è il valore massimo che è possibile specificare nel campo della dimensione della finestra TCP a 16 bit. Per migliorare le prestazioni in reti con larghezza di banda e ritardo elevati, il protocollo TCP/IP di Windows Server supporta la capacità di indicare finestre di ricezione di dimensioni maggiori di 65.535 ottetti, grazie all'utilizzo di finestre scalabili come descritto in RFC 1323, TCP Extensions for High Performance. Quando si utilizza la scalabilità della finestra, gli host in una conversazione sono in grado di negoziare una dimensione di finestra che consenta a più pacchetti di grandi dimensioni, come quelli spesso utilizzati nei protocolli di trasferimento dei file, di restare in attesa nei buffer del destinatario. In RFC 1323 viene descritto in dettaglio un metodo per supportare dimensioni di finestra di ricezione maggiori consentendo a TCP di negoziare un fattore di scalabilità per la dimensione di finestra al momento in cui viene stabilita la connessione.

È possibile modificare due voci del Registro di sistema, per ottimizzare la dimensione della finestra di ricezione TCP e le opzioni di scalatura della finestra di RFC 1323 in un computer su cui è in esecuzione Windows Server 2003: TCPWindowSize e TCP1323Opts. Per ulteriori informazioni su queste funzionalità, vedere l'articolo 224829 della Microsoft Knowledge Base, Descrizione di funzionalità TCP di Windows 2000 e Windows Server 2003.

È consigliabile utilizzare la versione 13 o successiva dello strumento di calcolo dei requisiti di archiviazione del ruolo del server Cassette postali di Exchange 2007 per determinare le impostazioni ottimali per queste voci del Registro di sistema in base al proprio collegamento di rete e alla propria latenza di rete. Per scaricare lo strumento di calcolo, vedere Strumento di calcolo dei requisiti per il ruolo del server Cassette postali di Exchange 2007 (informazioni in lingua inglese) nel blog del team di Exchange. Lo strumento di calcolo dei requisiti di archiviazione include anche istruzioni dettagliate per l'inserimento di valori del Registro di sistema nei propri server.

Nota

UNRESOLVED_TOKEN_VAL(exBlog)

Scadenza della cache ARP

La cache ARP è una tabella incorporata in memoria che esegue il mapping degli indirizzi IP agli indirizzi MAC (Media Access Control). Alle voci nella cache ARP viene fatto riferimento ogni volta che un pacchetto in uscita viene inviato all'indirizzo IP nella voce. Per impostazione predefinita, Windows Server 2003 regola la dimensione della cache ARP automaticamente per soddisfare le esigenze del sistema. Se una voce non è utilizzata da un diagramma in uscita per due minuti, viene rimossa dalla cache ARP. Le voci a cui viene fatto riferimento vengono rimosse dalla cache ARP dopo dieci minuti. Le voci aggiunte manualmente non vengono rimosse automaticamente dalla cache.

I risultati di verifiche interne svolte dal reparto IT interno di Microsoft hanno mostrato che le impostazioni predefinite di scadenza della cache ARP causavano perdite di pacchetti in ambienti CCR e SCR. Quando si verifica una perdita di pacchetti, il server mittente deve trasmettere nuovamente i dati persi. In un ambiente di replica continua è importante che i file di registro vengano copiati nel nodo passivo il più velocemente possibile e una nuova trasmissione dei dati a causa di pacchetti persi può influenzare negativamente la velocità di trasmissione del log shipping.

È possibile modificare il parametro TCP/IP ArpCacheMinReferencedLife nel Registro di sistema di Windows per controllare la scadenza della cache ARP. Questo parametro determina il tempo durante il quale le voci a cui viene fatto riferimento devono restare nella tabella della cache ARP prima che vengano eliminate. Le verifiche interne di Microsoft hanno rivelato che l'impostazione ottimale per il valore ArpCacheMinReferencedLife del Registro di sistema prevede l'utilizzo dello stesso valore per la scadenza della cache ARP nei router in rete, ovvero 4 ore.

Prima di modificre il valore di ArpCacheMinReferencedLife nel proprio ambiente, è consigliabile utilizzare Microsoft Network Monitor o uno strumento di acquisizione simile per raccogliere e analizzare il traffico di rete nell'interfaccia di rete utilizzata per copiare i registri dal nodo attivo a quello passivo. Per la procedura dettagliata di modifica del valore ArpCacheMinReferencedLife del Registro di sistema, vedere Appendice A: TCP/IP Configuration Parameters (informazioni in lingua inglese).

Funzionalità TCP/IP avanzate di Scalable Networking Pack

Windows Server 2003 Scalable Networking Pack (SNP) è un aggiornamento separato per Windows Server 2003 che contiene offload con e senza stato per accelerare lo stack di rete di Windows. L'aggiornamento include TCP Chimney Offload, Receive Side Scaling (RSS) e Network Direct Memory Access (NetDMA).

TCP Chimney è un offload con stato. TCP Chimney Offload consente la ripartizione dell'elaborazione TCP/IP in schede di rete in grado di gestire l'elaborazione TCP/IP nei componenti hardware.

RSS e NetDMA sono offload senza stato. Quando in un unico computer risiedono più CPU, lo stack di rete di Windows limita l'elaborazione del protocollo di ricezione a un'unica CPU. RSS risolve questo problema, poiché consente il bilanciamento ripartito su più CPU dei pacchetti che vengono ricevuti da una scheda di rete. NetDMA consente la presenza di un motore Direct Memory Access (DMA) sul bus Peripheral Component Interconnect (PCI). Lo stack TCP/IP è in grado di utilizzare il motore DMA per copiare dati invece di interrompere la CPU per gestire l'operazione di copia. Un componente correlato, TCPA, è un'altra funzione di offload che consente di utilizzare un motore DMA hardware sul bus PCI per fornire assistenza all'elaborazione di ricezione.

Queste funzionalità sono in grado di fornire vantaggi in termini di prestazioni di rete per alcuni ambienti. Tuttavia, non è possibile utilizzarle in alcuni scenari a causa dell'impiego di altre tecnologie. Ad esempio, non è possibile utilizzare TCP Chimney Offload e NetDMA se viene utilizzata una delle seguenti tecnologie:

  • Windows Firewall

  • Internet Protocol Security (IPsec).

  • Internet Protocol Network Address Translation (IPNAT)

  • Firewall di terze parti

  • Driver intermedi NDIS 5.1

Inoltre, in alcuni ambienti sono rilevabili problemi noti, inclusi gli ambienti con Microsoft Exchange, dove le prestazioni di rete possono diminuire quando si utilizzano queste funzionalità. Per i dettagli su alcuni di questi problemi, vedere l'articolo nel blog del team di Exchange, Windows 2003 Scalable Networking Pack e i relativi possibili effetti su Exchange (informazioni in lingua inglese).

Nota

UNRESOLVED_TOKEN_VAL(exBlog)

È consigliabile disattivare tutte le funzionalità negli ambienti di replica continua di standby in esecuzione nel sistema operativo Windows Server 2003 per il sistema operativo e per ogni scheda di interfaccia di rete (NIC, Network Interface Card) nel sistema. È possibile disattivare queste funzionalità come descritto di seguito:

Per ulteriori informazioni su SNP, vedere l'articolo 912222 della Knowledge Base, La versione di Microsoft Windows Server 2003 Scalable Networking Pack e il sito Web Connessione in rete scalabile (informazioni in lingua inglese).