Condividi tramite

Pianificazione di una replica continua cluster

  • Articolo

 

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

Ultima modifica dell'argomento: 2008-07-23

Benché la distribuzione della replica continua cluster (CCR, Cluster Continuous Replication) sia simile alla distribuzione della replica continua locale (LCR, Local Continuous Replication) e cluster a copia singola (SCC, Single Copy Cluster), esistono alcune differenze importanti di cui è necessario tenere conto. Per la replica continua cluster devono essere soddisfatti sia requisiti generali sia requisiti specifici relativi all'hardware, al software, alle reti e ai cluster stessi.

Requisiti generali di una replica continua cluster

Prima di iniziare la distribuzione di una replica continua cluster, assicurarsi che siano soddisfatti i seguenti requisiti a livello di sistema:

  • È necessario utilizzare un singolo database per gruppo di archiviazione. Una volta creato un gruppo di archiviazione in un ambiente di replica continua cluster, esso può contenere solo un unico database. Questa procedura crea una topologia di archiviazione Microsoft Exchange più gestibile che aumenta la recuperabilità.

  • Domain Name System (DNS) deve essere in esecuzione. Il server DNS dovrebbe accettare gli aggiornamenti dinamici. In caso contrario, è necessario creare un record DNS Host (A) per ciascun server di cassette postali in cluster e uno per il cluster stesso, altrimenti Exchange non funziona correttamente. Per ulteriori informazioni su come configurare il DNS per Exchange, vedere l'articolo 322856 della Microsoft Knowledge Base, How to configure DNS to use with Exchange Server.

  • Se i nodi del cluster appartengono a una zona del servizio di denominazione directory con un nome diverso dal nome di dominio del servizio directory di Active Directory a cui è stato unito il computer, per impostazione predefinita il nome del sottodominio non verrà incluso nella proprietà DNSHostName. In questo caso, può essere necessario modificare la proprietà DNSHostName per assicurarsi che alcuni servizi, ad esempio il servizio Replica file (FRS, File Replication Service), funzionino correttamente. Per ulteriori informazioni, vedere l’articolo 240942 della Knowledge Base, Active Directory DNSHostName property does not include subdomain (informazioni in lingua inglese).

  • Tutti i nodi del cluster devono essere server membri dello stesso dominio. Microsoft Exchange Server 2007 non è supportato nei nodi che sono anche server di Active Directory o nei nodi membri di domini di Active Directory diversi.

  • Il cluster deve essere stato creato e deve essere accessibile prima di installare Exchange 2007. Per informazioni sulla creazione di un cluster di failover in Windows Server 2008, vedere Installazione della replica continua cluster in Windows Server 2008. Per informazioni sulla creazione di un cluster di failover in Windows Server 2003, vedere Installazione di un cluster a copia singola.

  • I nomi dei server di cassette postali in cluster (CMS, Clustered Mailbox Server) possono contenere fino a 15 caratteri.

  • Il cluster in cui è installato Exchange 2007 non può contenere Exchange Server 2003, Exchange 2000 Server o qualsiasi versione abilitata per i cluster di Microsoft SQL Server. L'esecuzione di Exchange 2007 su un cluster con una qualsiasi delle applicazioni sopra citate non è supportata. È possibile eseguire Exchange 2007 in un cluster con SQL Server 2005 Express Edition o con un'altra applicazione di database (quale Microsoft Office Access) solo se l'applicazione database non è in cluster.

  • Prima di installare Exchange 2007, assicurarsi che la cartella in cui si installano i dati di Exchange sia vuota.

  • È necessario installare la stessa versione di Exchange 2007 in tutti i nodi del cluster configurati come host di un server di cassette postali in cluster. Inoltre, il sistema operativo e i file di Exchange devono essere installati negli stessi percorsi e unità di tutti i nodi del cluster. A tale scopo, è necessario che tutti i computer abbiano una configurazione del disco simile, se non identica.

  • L'account del Servizio cluster deve essere membro del gruppo Administrators locale in ciascun nodo in grado di ospitare un server di cassette postali in cluster.

  • Non installare, creare o spostare le risorse dal gruppo di cluster predefinito nel gruppo di risorse che contiene il server di cassette postali in cluster. Inoltre, non installare, creare o spostare le risorse dal gruppo che contiene il server di cassette postali in cluster nel gruppo di cluster predefinito. Il gruppo cluster predefinito deve includere solo l'indirizzo IP del cluster, il nome rete e le risorse del quorum. Lo spostamento delle risorse in un gruppo di cluster predefinito oppure la combinazione delle risorse con un gruppo di cluster predefinito non è supportato.

    Importante

    I cluster che eseguono versioni precedenti di Exchange richiedono un'istanza cluster di Microsoft Distributed Transaction Coordinator (MSDTC). In Exchange 2007 il componente MSDTC non è più un requisito. I server di cassette postali in cluster in un ambiente di replica continua cluster non utilizzano e non necessitano della risorsa MSDTC installata nel cluster di failover. Le applicazioni di terze parti potrebbero richiedere una risorsa MSDTC per via delle dipendenze COM+. In Windows Server 2003 la risorsa cluster MSDTC richiede l'utilizzo di un'archiviazione condivisa nel cluster. L'aggiunta di un'archiviazione condivisa in un ambiente di replica continua cluster non è consigliata. Windows Server 2008 fornisce un'istanza MSDTC locale non cluster che rende superflua l'archiviazione condivisa in un cluster di failover di Windows Server 2008. Per ulteriori informazioni sulle modifiche MSDTC in Windows Server 2008, vedere la Guida di Windows Server 2008.

Requisiti hardware della replica continua cluster

Per informazioni sulla pianificazione generale dell'hardware, vedere Pianificazione delle configurazioni dei processori e Pianificazione dell'archiviazione su disco. Di seguito sono riportati i requisiti hardware per gli ambienti di replica continua cluster.

  • Quando si utilizza un quorum maggioranza dei nodi (MNS) con witness di condivisione file in Windows Server 2003, possono essere presenti solo due nodi nel cluster. Se nel cluster è presente un nodo o sono presenti più di due nodi, la funzionalità del witness di condivisione file del quorum MNS non può essere utilizzata. In questo caso è necessario usare un quorum MNS tradizionale che richiede tre o più nodi in un cluster.

  • Quando si utilizza un quorum maggioranza dei nodi e delle condivisioni di file in Windows Server 2008, possono essere presenti solo due nodi nel cluster. Se nel cluster è presente un nodo o sono presenti più di due nodi, il quorum maggioranza dei nodi e delle condivisioni di file non può essere utilizzato. In questo caso è necessario usare un quorum maggioranza dei nodi che richiede tre o più nodi in un cluster.

    Nota

    È consigliabile utilizzare un cluster di failover a due nodi che utilizzi il quorum MNS con witness di condivisione file o il quorum maggioranza dei nodi e delle condivisioni di file. In tal modo è possibile evitare la necessità di un terzo nodo voter nel cluster.

  • I server utilizzati devono essere inclusi nel Microsoft Windows Server Catalog of Tested Products in relazione al sistema operativo nel quale verranno installati. Tuttavia, se nel cluster non viene utilizzata l'archiviazione condivisa, non è necessario che i server siano elencati nella categoria Cluster.

  • I due server che ospitano i ruoli del server Cassette postali devono avere caratteristiche simili ma non identiche nei seguenti elementi:

    • CPU

    • Memoria

    • Capacità I/O (Input/Output)

    • Rete

    • Fornitore

    • Disponibilità di archiviazione sul disco, incluso lo spazio e le capacità di operazioni I/O

Requisiti dei quorum per la replica continua cluster

In genere, per le applicazioni in cluster non è importante conoscere il tipo di quorum utilizzato nel cluster in cui sono installate. Quando si progetta il componente quorum per l'ambiente di replica continua cluster, tenere presente le considerazioni e i requisiti seguenti:

  • In Windows Server 2008, il tipo di quorum più indicato per la replica continua cluster è il quorum maggioranza dei nodi e delle condivisioni di file.

  • In Windows Server 2003, il tipo di quorum più indicato per un ambiente di replica continua cluster è il quorum maggioranza dei nodi con witness di condivisione di file.

Se per la replica continua cluster viene utilizzato uno dei quorum indicati in precedenza, non è necessario che i server dei nodi siano inclusi nell'elenco Microsoft Windows Server Catalog of Tested Products.

Se per la replica continua cluster viene utilizzato un quorum di archiviazione condivisa, è necessario che l'intero sistema sia incluso nell'elenco Microsoft Windows Server Catalog of Tested Products.

In Exchange Server 2007 Service Pack 1 (SP1), se non viene configurato un witness di condivisione file o una maggioranza delle condivisioni di file, il programma di installazione blocca le configurazioni cluster a due nodi. Una configurazione di questo tipo, infatti, non è in grado di gestire la perdita di un nodo del cluster perché sarebbe impossibile mantenere la maggioranza e, di conseguenza, il cluster verrebbe disconnesso.

Requisiti software di una replica continua cluster

Di seguito sono riportati i requisiti software per ambienti di replica continua cluster.

  • In entrambi i nodi del cluster deve essere installato il sistema operativo Windows Server 2008 Enterprise o Windows Server 2003 Enterprise Edition, con le stesse lettere di unità di avvio e di sistema. Non è possibile creare un cluster utilizzando un nodo con Windows Server 2008 e un altro nodo con Windows Server 2003. In un cluster di failover non sono supportate versioni diverse dei sistemi operativi.

  • Se si sta creando un ambiente di replica continua cluster utilizzando la versione di produzione (RTM) di Exchange 2007 in Windows Server 2003, è necessario che in entrambi i nodi del cluster sia installato Windows Server 2003 Service Pack 2 (SP2) oppure Windows Server 2003SP1 con l'aggiornamento rapido descritto nell'articolo 921181 della Knowledge Base, È disponibile un aggiornamento che aggiunge una funzionalità di witness di condivisione file e una funzionalità di heartbeat cluster configurabile ai cluster di server basati su Windows Server 2003 Service Pack 1. L'aggiornamento rapido è incluso in Windows Server 2003 SP2. Se si sta creando un ambiente di replica continua cluster utilizzando Exchange 2007 SP1 in Windows Server 2003, è necessario che in entrambi i nodi del cluster di failover sia installato Windows Server 2003 SP2.

  • Il cluster deve essere a tre nodi con un quorum maggioranza dei nodi (MNS) tradizionale, oppure a due nodi con un quorum maggioranza dei nodi (MNS) con witness di condivisione file. In genere, si presume che in Windows Server 2003 venga utilizzato un cluster a due nodi che utilizza un quorum MNS con witness di condivisione file e che in Windows Server 2008 venga utilizzato un cluster a due nodi con un quorum maggioranza dei nodi e delle condivisioni di file.

  • Non è necessario che il witness di condivisione file per il quorum MNS o il quorum maggioranza delle condivisioni di file si trovi in un computer dedicato. Può trovarsi su un qualsiasi computer in cui sia in esecuzione Windows Server. Tuttavia, si consiglia di ospitare il witness di condivisione file in un server Trasporto Hub (o in un altro server di Exchange) in modo che sia sotto il controllo dell'amministratore di Exchange.

  • In un cluster è possibile installare solo il ruolo del server Cassette postali. In un computer appartenente a un cluster di failover non può essere installato nessun altro ruolo del server.

Requisiti di rete di una replica continua cluster

È importante che le reti utilizzate per le comunicazioni tra client e cluster siano configurate correttamente. In questa sezione sono riportati collegamenti alle procedure necessarie per verificare che le impostazioni della rete pubblica e della rete privata siano corrette. Inoltre, è necessario assicurarsi che l'ordine della connessione di rete sia configurato correttamente per il cluster. Quando si progetta l'infrastruttura di rete per l'ambiente di replica continua cluster, considerare quanto segue:

  • Ciascun nodo deve disporre di almeno due schede di rete disponibili per il cluster di Windows. I client e gli altri server devono poter accedere ai nodi soltanto da una delle due schede di rete. Le altre schede di rete vengono utilizzate per le comunicazioni tra cluster. La configurazione consigliata prevede una rete privata dedicata alle comunicazioni cluster interne e una rete pubblica designata come "mista".

  • La rete pubblica cluster deve fornire la connessione ad altri server di Exchange e ad altri servizi, come Active Directory e DNS. Non è possibile evitare che questo diventi un singolo punto di errore utilizzando le schede di rete o una tecnologia simile.

  • È necessario che sia fornita una rete privata cluster separata. La rete privata deve essere utilizzata per l'heartbeat cluster. La rete privata non richiede il DNS.

  • I requisiti di heartbeat potrebbero non essere i requisiti di latenza e di larghezza di banda di rete pubblica più rigidi per una configurazione a due centri dati. Per determinare i requisiti di rete richiesti dall'ambiente è necessario valutare il carico complessivo della rete che include l'accesso dei client, Active Directory, i servizi di trasporto e di replica continua, nonché il traffico dovuto alle applicazioni.

  • Al fine di massimizzare il tempo di reseeding, per gli ambienti di replica continua cluster è consigliabile utilizzare una rete Gigabit Ethernet. Per ulteriori informazioni sul perché sia consigliabile l'utilizzo di una rete Gigabit Ethernet, vedere "Dimensione dei database e replica continua cluster" più avanti in questo argomento.

  • In Exchange 2007 RTM, un gruppo di risorse contenente un server di cassette postali in cluster può disporre di un'unica risorsa del nome di rete. In Exchange 2007 RTM non è possibile inserire più di una risorsa del nome di rete in un gruppo di risorse che contiene un server di cassette postali in cluster. Questa limitazione non è presente in Exchange 2007 SP1. Dopo aver aggiornato il server di cassette postali in cluster alla versione Exchange 2007 SP1, il gruppo di risorse che contiene il server di cassette postali in cluster può includere più di una risorsa del nome di rete.

Requisiti di rete per l'installazione di un ambiente di replica continua cluster in Windows Server 2008

I requisiti di rete per l'installazione di un ambiente di replica continua cluster in Windows Server 2008 sono leggermente diversi da quelli per l'installazione di un ambiente di replica continua cluster in Windows Server 2003. Come in Windows Server 2003, se si installa un ambiente di replica continua cluster in Windows Server 2008, è necessario disporre di un numero di indirizzi IP sufficiente per entrambi i nodi e per il server di cassette postali in cluster (CMS). Tuttavia Windows Server 2008 offre alcune opzioni aggiuntive che non sono disponibili in Windows Server 2003:

  • I nodi del cluster possono risiedere su subnet differenti. In Windows Server 2003, l'interfaccia di rete per ciascuna rete in ciascun nodo deve trovarsi sulla stessa subnet della rete corrispondente nell'altro nodo. Questo requisito non viene posto in Windows Server 2008. Come risultato, i nodi all'interno di un cluster di failover sono in grado di comunicare attraverso i router della rete. Pertanto, per connettere i nodi non è necessario ricorrere alla tecnologia virtual LAN (VLAN).

  • Quando si utilizzano più subnet in un ambiente di replica continua cluster, la replica DNS può influire sulla capacità del client di riconnettersi a un CMS dopo che si è verificato un failover o un handoff del CMS tra i nodi. I client e gli altri server che comunicano con un server di cassette postali in cluster con indirizzi IP modificati non sarà in grado di ristabilire le comunicazioni con il server di cassette postali in cluster fino a quando il DNS non è stato aggiornato con il nuovo indirizzo IP e non sono state aggiornate eventuali cache DNS locali. Per ridurre al minimo il tempo necessario per informare i client e gli altri server delle modifiche del DNS, è consigliabile impostare un valore Time to Live (TTL) del DNS su cinque minuti per la risorsa del nome di rete del server di cassette postali in cluster. Nella maggior parte degli ambienti si consiglia di impostare il valore DNS TTL solo per la risorsa del nome di rete del CMS. Tuttavia, in ambienti dotati di strumenti di gestione non Exchange che eseguono la connessione al cluster per nome, a scopi di gestione, si consiglia di impostare un valore TTL più basso per la risorsa del nome di rete del cluster. Per la procedura dettagliata di configurazione dei valori TTL del DNS per le risorse Nome rete da utilizzare in un CMS in cluster con più subnet o in una distribuzione di cluster di standby, vedere Come configurare i valori DNS TTL per le risorse del nome di rete.

  • Nel clustering di failover di Windows Server 2008 questa funzionalità viene fornita in un contesto in cui le risorse indirizzo IP sono in grado di ottenere il relativo indirizzamento dai server Dynamic Host Configuration Protocol (DHCP) oltre che tramite voci statiche. Se gli stessi nodi cluster vengono configurati per il recupero dei relativi indirizzi IP da un server DHCP, il comportamento predefinito prevede il recupero automatico di un indirizzo IP per tutte le risorse indirizzo IP del cluster. Se il nodo cluster include indirizzi IP assegnati in modo statico, anche le risorse indirizzo IP del cluster dovranno essere configurate con indirizzi IP statici. Pertanto, l'assegnazione degli indirizzi IP alle risorse indirizzo IP del cluster si basa sulla configurazione del nodo fisico e di ciascuna interfaccia specifica del nodo. Non è consigliato l'utilizzo di DHCP per i server di cassette postali in cluster. Prima di utilizzare DHCP per un CMS, è opportuno considerare quanto segue:

    • Il Servizio cluster non porterà in linea una risorsa indirizzo IP abilitata a DHCP se l'indirizzo IP cambia.

    • I server DHCP devono essere configurati per concedere un lease illimitato per tutti gli indirizzi assegnati tramite DHCP utilizzati dai server di cassette postali in cluster.

  • Windows Server 2008 e il relativo Servizio cluster supportano anche Internet Protocol versione 6 (IPv6). Questa capacità prevede a sua volta il supporto delle risorse indirizzo IP di tipo IPv6 e IPv4, sia da sole che in combinazione in un cluster. Inoltre, i cluster di failover supportano il protocollo ISATAP (Intra-site Automatic Tunneling Addressing Protocol) e solo gli indirizzi IPv6 che consentono la registrazione dinamica in DNS (record host AAAA e zona di ricerca inversa IP6.ARPA). L'utilizzo di indirizzi e di intervalli indirizzi IP in formato IPv6 è supportato solo se Exchange 2007 SP1 viene distribuito in un computer che esegue Windows Server 2008, se su tale computer è abilitato sia IPv6 che IPv4 (Internet Protocol Version 4) e se la rete supporta entrambe le versioni degli indirizzi IP. Se Exchange 2007 SP1 viene distribuito in questa configurazione, tutti i ruoli dei server potranno inviare e ricevere dati da dispositivi, server e client che utilizzano indirizzi in formato IPv6. Nell'installazione predefinita di Windows Server 2008 il supporto per i formati IPv4 e IPv6 è abilitato. Se Exchange 2007 SP1 è installato in Windows Server 2003, gli indirizzi in formato IPv6 non sono supportati. Per ulteriori informazioni sul supporto di Exchange 2007 SP1 per gli indirizzi in formato IPv6, vedere Supporto IPv6 in Exchange 2007 SP1 e SP2.

Requisiti di rete per l'installazione di un ambiente di replica continua cluster in Windows Server 2003

Se si sta installando un ambiente di replica continua cluster in Windows Server 2003, è necessario disporre di un numero sufficiente di indirizzi IP statici quando si creando server di cassette postali in cluster in un ambiente di replica continua cluster a due nodi. È necessario un indirizzo IP per il cluster e per il server di cassette postali in cluster. Inoltre, sono necessari indirizzi IP sia per le reti pubbliche che per quelle private:

  • Indirizzi privati   Ogni nodo richiede un indirizzo IP statico per ogni scheda di rete utilizzata per la rete privata cluster. È necessario utilizzare indirizzi IP statici che non si trovino sulla stessa subnet o rete di una delle reti pubbliche. È consigliabile utilizzare 10.10.10.10 e 10.10.10.11 con una subnet mask di 255.255.255.0 come indirizzi IP privati dei due nodi. Se la rete pubblica utilizza una rete 10.x.x.x e la subnet mask 255.255.255.0, è consigliabile utilizzare indirizzi IP di rete privata e subnet mask alternativi. Se vengono configurate più reti private, sono necessari subnet e indirizzi univoci per ciascuna scheda di rete e ogni rete privata.

  • Indirizzi pubblici   Ogni nodo richiede un indirizzo IP statico per ogni scheda di rete utilizzata per la rete pubblica cluster. Inoltre, gli indirizzi IP statici sono necessari per rendere il cluster di server e il server di cassette postali in cluster accessibili a client e amministratori. È necessario utilizzare indirizzi IP statici che non si trovino sulla stessa subnet o rete di una delle reti private.

La rete privata per tutti i nodi in un cluster deve trovarsi nella stessa subnet, ma è possibile utilizzare switch VLAN (LAN virtuale) sulle interconnessioni tra i due nodi. Se si utilizza una rete VLAN, la latenza di andata e ritorno da punto a punto deve essere inferiore a 0,5 secondi. Inoltre, il collegamento tra i due nodi deve essere riportato come una singola connessione da punto a punto dalla prospettiva del sistema operativo Windows Server 2003 in esecuzione sui nodi. Per evitare singoli punti di errore, utilizzare hardware VLAN indipendente per i vari percorsi tra i nodi. La stessa restrizione che riguarda la subnet non si applica ai cluster di failover in esecuzione su Windows Server 2008.

Le reti pubbliche per tutti i nodi in un cluster devono trovarsi nella stessa subnet e utilizzare una subnet che sia diversa da quella in uso per le reti private. La stessa restrizione che riguarda la subnet non si applica ai cluster di failover in esecuzione su Windows Server 2008.

L'ordine di connessione di rete in Windows deve essere configurato assegnando la priorità più alta alle reti pubbliche, mentre la priorità di rete nel cluster deve essere configurata con le reti private al vertice dell'ordine di priorità.

Se si installa un ambiente di replica continua cluster in Windows Server 2003 in una configurazione di più centri dati:

  • Tutte le reti utilizzate per l'accesso client devono fornire una larghezza di banda adeguata e una latenza sufficientemente bassa per consentire ai client di accedere al server di cassette postali in cluster da ciascun centro dati.

  • Tutte le reti utilizzate per replicare i registri delle transazioni devono fornire una larghezza di banda adeguata e una latenza sufficientemente bassa per copiare tempestivamente i file di registro ed evitare, quando possibile, la creazione di backlog dei file di registro.

  • Le reti utilizzate per l'heartbeat cluster devono essere in grado di inviare e ricevere un pacchetto heartbeat entro il numero richiesto di tentativi configurati. Se si installa l'ambiente di replica continua cluster in Windows Server 2003 SP2 oppure in Windows Server 2003 SP1 con l'aggiornamento descritto nell'articolo 921181 della Knowledge Base, È disponibile un aggiornamento che aggiunge una funzionalità di witness di condivisione file e una funzionalità di heartbeat cluster configurabile ai cluster di server basati su Windows Server 2003 Service Pack 1 (informazioni in lingua inglese), il numero dei tentativi di heartbeat non riusciti per l'interfaccia e per il nodo vengono esposti come proprietà della configurazione cluster. Se si installa la replica continua cluster in Windows Server 2008, questo aggiornamento non è necessario. In entrambi i casi, gli heartbeat vengono ancora inviati ogni 1,2 secondi, ma il cluster può essere configurato in modo che debbano verificarsi più tentativi non riusciti (siano essi dovuti a pacchetti ignorati, a eccessiva latenza, a problemi dell'interfaccia o del nodo) prima che sia intrapresa un'azione di ripristino. I valori di proprietà sono espressi in unità di heartbeat persi e non in tempo trascorso. Per cui, il cluster non può essere configurato in modo che si sospetti un problema dell'interfaccia dopo cinque secondi. Può essere configurato in modo che sospetti un problema dell'interfaccia dopo cinque tentativi vani e, a seconda di quando nel periodo dell'heartbeat il problema si è effettivamente verificato, cinque tentativi vani equivarranno a circa cinque o sei secondi. Entrambe queste impostazioni hanno un tempo minimo consentito di 2 secondi ed un tempo massimo consentito di 20 secondi.

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

Quando si utilizza la replica continua cluster in Windows Server 2003, è consigliabile ottimizzare le impostazioni TCP/IP di Windows Server per la velocità e la latenza specifiche del collegamento 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 nei nodi attivi e passivi. 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 cluster. Entrambi i nodi dovranno utilizzare IPsec oppure non lo dovrà utilizzerà nessuno dei nodi. 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à della pipe di rete, 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. È possibile scaricare lo strumento di calcolo dal blog del team di Exchange, facendo clic qui (informazioni in lingua inglese). 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 modificare 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: Parametri di configurazione TCP/IP (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 cluster 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 Microsoft Knowledge Base, La versione di Microsoft Windows Server 2003 Scalable Networking Pack e il sito Web Connessione in rete scalabile (informazioni in lingua inglese).

Comportamento di Outlook dopo il failover di un server di cassette postali in cluster in un cluster failover per più subnet

Se si verifica uno spostamento o viene eseguito un failover per un server di cassette postali in un cluster di failover dislocato geograficamente e composto da più subnet, il nome del server di cassette postali in cluster viene mantenuto. Tuttavia, l'indirizzo IP assegnato a tale nome non viene mantenuto. La disponibilità di questo server per client e altri server dipende dalla propagazione del nuovo indirizzo IP in tutto il DNS. La propagazione DNS potrebbe richiedere alcuni minuti. Per questo motivo è consigliabile configurare su 5 minuti (300 secondi) il valore TTL per il record host DNS per il server di cassette postali in cluster. Per la procedura dettagliata di configurazione del valore TTL del DNS per il server di cassette postali in cluster, vedere Come configurare i valori DNS TTL per le risorse del nome di rete. Dopo aver configurato il valore TTL del DNS per il server di cassette postali in cluster, è necessario interrompere e riavviare il server di cassette postali in cluster per rendere effettive le modifiche.

Sebbene nei client Microsoft Office Outlook interni non sia necessario che i profili nuovi o riconfigurati vengano riconnessi utilizzando il nuovo indirizzo IP, è necessario attendere che la cache DNS locale venga cancellata affinché la risoluzione del nome del server di cassette postali in cluster si sposti dall'indirizzo IP meno recente a quello nuovo. Dopo la propagazione dell'indirizzo IP ai server DNS appropriati, la cache DNS sui client Outlook può essere cancellata utilizzando il comando riportato di seguito quando viene visualizzato il prompt dei comandi nel client:

ipconfig /flushdns

Nelle seguenti sezioni viene illustrato il comportamento di Outlook in varie configurazioni.

Replica continua cluster estesa in Windows Server 2003 (una subnet)

In questa configurazione sono presenti una risorsa del nome di rete e una risorsa indirizzo IP dalla quale dipende la risorsa del nome di rete. In DNS, il nome della risorsa di rete è associata all'indirizzo IP. Tutte le risorse, inclusa la risorsa indirizzo IP, possono essere spostate tra i due nodi del cluster. Dalla prospettiva di Outlook, non si verifica alcuna modifica dell'indirizzo IP in quanto l'unica modifica di rete in caso di failover è l'associazione dell'indirizzo IP all'indirizzo MAC, che è trasparente per i client.

Replica continua cluster estesa in Windows Server 2008 (due subnet, presupponendo IPv4)

In questa configurazione sono presenti una risorsa del nome di rete e due risorse indirizzo IP dalle quali dipende la risorsa del nome di rete. In DNS, il nome della risorsa di rete è associata all'indirizzo IP corrente in linea. Durante il failover, quando la risorsa del nome di rete entra in linea, il servizio aggiorna la voce DNS per il nome della rete con il secondo indirizzo IP, che corrisponde all'altra subnet. L'aggiornamento del record deve essere propagato attraverso l'intero DNS. Dalla prospettiva di Outlook, Outlook non necessita di un profilo nuovo o riconfigurato, ma deve attendere che la rispettiva cache DNS locale venga svuotata per consentire la risoluzione del nome di rete in un indirizzo IP diverso. Questa operazione può essere eseguita manualmente sul client eseguendo:

IPConfig /flushdns

Replica continua cluster locale con replica continua di standby in un sito remoto (una o due subnet)

In questa configurazione è presente una risorsa del nome di rete e una risorsa indirizzo IP dalla quale dipende il nome di rete. Tutte le risorse, inclusa la risorsa indirizzo IP, possono essere spostate tra i due nodi del cluster. In un failover di siti in cui la destinazione della replica continua di standby viene attivata eseguendo Setup.com /recoverCMS, il server delle cassette postali in cluster viene spostato in un sito/cluster diverso. Quando si esegue questo comando, si fornisce l'indirizzo IP che deve essere associato al nome di rete nel sito remoto. All'installazione vengono creati un nome di rete e le risorse indirizzo IP, mentre il servizio cluster aggiorna il DNS con il nuovo indirizzo IP. L'aggiornamento DNS deve essere propagato attraverso l'intero DNS. Dalla prospettiva di Outlook, Outlook non necessita di un profilo nuovo o riconfigurato, ma deve attendere che la rispettiva cache DNS locale venga svuotata per consentire la risoluzione del nome di rete in un indirizzo IP diverso. Questa operazione può essere eseguita manualmente sul client eseguendo:

IPConfig /flushdns

Requisiti di archiviazione per una replica continua cluster

La replica continua cluster è stata progettata per eliminare la necessità di archiviazione condivisa in un cluster di Windows. L'archiviazione condivisa era un requisito per le precedenti versioni di Exchange. Gli unici requisiti di archiviazione per la replica continua cluster sono prestazioni e capacità sufficienti dell'archiviazione supportata da Windows.

La replica continua cluster non richiede ulteriori capacità di I/O all'archiviazione utilizzata dai gruppi di archiviazione e dai database. Quando si progetta una soluzione di archiviazione di replica continua cluster, è consigliabile seguire le procedure consigliate riportate di seguito:

  • La posizione dei gruppi di archiviazione e dei database deve essere identica in tutti i nodi cluster.

  • I file di database e i file del registro delle transazioni devono essere archiviati in numeri di unità logica (LUN, Logical Unit Number) diversi.

  • Per rendere i volumi visibili dal sistema operativo, utilizzare i punti di montaggio del volume del file system NTFS.

  • Utilizzare nomi riconoscibili che possono essere collegati direttamente e logicamente al gruppo di archiviazione o al database ospitato. Se vengono utilizzati volumi diversi per i registri e i database, i percorsi devono consentire di identificare il tipo di dati. Questo approccio può aiutare a evitare errori umani quando il numero di database e gruppi di archiviazione è elevato. Se viene eseguita l'installazione predefinita, il gruppo di archiviazione e i database vengono creati nel percorso di installazione di Exchange 2007.

    Nota

    Exchange 2007 non supporta la collocazione dei registri delle transazioni o dei file di database nella directory radice di un volume.

Un ambiente di replica continua cluster richiede un'archiviazione che offra prestazioni e capacità adeguate. Su entrambi i nodi devono essere configurate archiviazioni equivalenti in termini di prestazioni e capacità del sistema utilizzando la stessa posizione (lettera di unità e percorso) per ogni gruppo di archiviazione e database.

Dimensione dei database e replica continua cluster

La prima misura di difesa contro gli errori di archiviazione gravi o la corruzione dei database fisici con replica continua cluster è il ripristino della copia passiva dei dati e non il ripristino di backup. Questo rende molto meno importante avere obiettivi temporali di recupero (RTO, Recovery Time Objectives) brevi basati sul ripristino da archivio o nastro. Invece di eseguire il ripristino dal nastro, è possibile attivare la copia passiva di un database per rendere disponibili i dati ai client dopo alcuni minuti anziché dopo alcune ore. In questo senso, la replica continua cluster può essere considerata un meccanismo di recupero rapido, alla stessa stregua delle istantanee e dei cloni basati su hardware creati utilizzando il servizio Copia Shadow del volume (Volume Shadow Copy Service, VSS) in Exchange Server 2003.

Non è raro per gli amministratori dover effettuare operazioni di database fuori rete, ad esempio correzioni, per ovviare a problemi dovuti a backup inutilizzabili per nastri danneggiati o a tentativi di ripristino non riusciti. Con la replica continua cluster è possibile evitare queste eventualità e le probabilità di dover eseguire il ripristino di un database sono molto minori. Sebbene la percentuale dei casi in cui è necessario il ripristino di un database venga notevolmente ridotta, alcune situazioni richiedono comunque questo tipo di intervento. Quando si decidono le dimensioni dei database, è opportuno valutare attentamente il massimo tempo di inattività accettabile.

La replica continua cluster consente di avere periodi di esecuzione della manutenzione in linea più lunghi. Poiché la replica continua cluster consente di eseguire un backup dalla copia passiva di un gruppo di archiviazione, è possibile estendere il periodo di esecuzione della manutenzione in linea sul nodo cluster attivo. In molti casi, è possibile raddoppiare il periodo di esecuzione della manutenzione in linea, il che consente di avere cassette postali e database di dimensioni maggiori.

Un'altra funzione di Exchange 2007, denominata resilienza dei registri persi (Lost Log Resiliency, LLR), riduce drasticamente i casi di incoerenza del database dovuti alla perdita di registri. In termini generali, la ragione più comune per cui un amministratore corregge un database è per riportarlo in uno stato coerente quando i registri necessari sono stati persi o si sono corrotti, impedendo in questo modo il montaggio del database. La funzionalità LLR aumenta la resilienza in molti casi in cui i registri sono danneggiati o sono andati persi, consentendo il montaggio di un database senza doverne eseguire la correzione. Per ulteriori informazioni sulla funzionalità LLR, vedere Resilienza dei registri persi e attività del registro delle transazioni in Exchange 2007.

Pertanto, potrebbe sembrare che la replica continua consente di ingrandire i database quanto si desidera senza rischi. Ma non è così. La manutenzione in linea che deve essere eseguita in tempi ragionevoli per ogni database rappresenta ancora un fattore limitante per le dimensioni dei database. Con la replica continua cluster, la possibilità di dover eseguire di nuovo il seeding dei database è un altro fattore limitante. La replica continua cluster offre ridondanza dei database per cui, se la copia attiva di un database è andata persa o si è corrotta, il ripristino può essere eseguito rapidamente attivando la copia passiva del database. La replica continua cluster offre l'attivazione automatica tramite il processo noto come failover.

Una volta verificatosi un failover, rimane solo una copia del database, la nuova copia attiva. Poiché la copia passiva non esiste più, la ridondanza del database può risultare compromessa. Tuttavia, si dovrebbe comunque disporre del backup. Per abilitare nuovamente la resilienza, è necessario rimuovere i database con perdita o danneggiamento dei dati, nonché creare una nuova copia passiva del database a partire dalla copia attiva ed eseguirne il reseeding. A seconda delle dimensioni del database, ciò potrebbe richiedere molto tempo. La peggiore delle ipotesi è la perdita o il danneggiamento di tutte le copie attive, caso in cui deve essere eseguito di nuovo il seeding di tutte le copie passive. Questa ipotesi è una delle ragioni per cui è consigliabile utilizzare una rete Gigabit Ethernet per ambienti di replica continua cluster.

In un ambiente di replica continua cluster, purché non siano presenti colli di bottiglia relativi a dischi o a processori, è possibile prevedere le seguenti velocità di trasferimento mediante Gigabit Ethernet:

  • Nuova esecuzione di seeding di database singolo: circa 25 MB al secondo

  • Nuova esecuzione di seeding di più database (in parallelo): circa 100 MB al secondo (limitato dalla larghezza di banda della rete)

Con l'utilizzo della replica continua è possibile aumentare la dimensione massima consentita del database. Per Exchange 2007 si consigliano le seguenti dimensioni massime di database:

  • Database ospitati su un server Cassette postali senza replica continua: 100 GB

  • Database ospitati su un server Cassette postali con replica continua e rete Gigabit Ethernet: 200 GB

    Nota

    I database di grandi dimensioni possono anche richiedere tecnologie di archiviazione più recenti per l'aumento della larghezza di banda necessaria nei casi di ripristino.

    Importante

    La dimensione massima effettiva per i propri database dovrebbe essere dettata dal contratto di servizio (SLA, service level agreement) in vigore presso la propria organizzazione. Determinando il database più grande di cui è possibile eseguire un backup e un ripristino nei tempi specificati dal contratto di servizio (SLA) dell'organizzazione, vengono determinate anche le dimensioni massime dei database.

Requisiti di Active Directory di una replica continua cluster

La replica continua cluster ha gli stessi requisiti dell'infrastruttura di Active Directory di un server autonomo, più alcuni requisiti aggiuntivi. In una soluzione con più centri dati, i centri dati devono disporre di un supporto di infrastruttura di Active Directory adeguato, perché in qualsiasi momento uno dei centri dati potrebbe ospitare il server di cassette postali in cluster. È necessario che sia garantita questa capacità anche se gli altri centri dati non sono disponibili. Inoltre, tutti i nodi del cluster devono trovarsi nello stesso dominio e l'account del Servizio cluster deve disporre delle autorizzazioni appropriate.

Nota

I server Cassette postali in un cluster dislocato geograficamente richiedono che un singolo sito di Active Directory sia esteso tra i centri dati, perché tutti i nodi nel cluster devono essere membri dello stesso sito. Non è necessario tuttavia che gli altri server di entrambi i centri dati si trovino sulla stessa subnet o nello stesso sito di Active Directory.

Requisiti dell'account del servizio per la replica continua cluster

Se si installa la replica continua cluster in Windows Server 2008, l'account del Servizio cluster viene eseguito nell'account LocalSystem (SYSTEM).

Se si installa la replica continua cluster in Windows Server 2003, per l'account del Servizio cluster è necessario utilizzare un account di dominio. Tutti i nodi del cluster devono essere membri dello stesso dominio e devono utilizzare lo stesso account del Servizio cluster. L'account del Servizio cluster deve essere anche membro del gruppo Administrators locale in ciascun nodo in grado di ospitare un server di cassette postali in cluster.

L'account del Servizio cluster è responsabile per la creazione e la gestione dell'account computer identificato e associato alla risorsa del nome di rete del cluster di failover quando tale risorse viene portata in linea. Per assicurare che l'account del Servizio cluster disponga delle autorizzazioni appropriate, vedere l'articolo 307532 della Knowledge Base, Risoluzione dei problemi dell'account del Servizio cluster in relazione alla modifica di oggetti computer. Per ulteriori informazioni, vedere l'articolo 251335 della Knowledge Base Impossibile per gli utenti di dominio collegare una workstation o un server a un dominio.

Replica continua cluster e database delle cartelle pubbliche

La replica continua locale 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 di replica continua cluster.

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

  • Se nell'organizzazione di Exchange è presente un server Cassette postali singolo che svolge la funzione di server di cassette postali in cluster in un ambiente di replica continua cluster, il server Cassette postali è in grado di ospitare un database delle cartelle pubbliche. 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 cluster, che consente di conservare due copie del database delle cartelle pubbliche.

  • Se si dispone di più server Cassette postali, è possibile ospitare un database delle cartelle pubbliche in un ambiente di replica continua cluster, purché nell'intera organizzazione di Exchange sia presente un solo database delle cartelle pubbliche. Anche in questo scenario la ridondanza dei database delle cartelle pubbliche si ottiene utilizzando la replica continua cluster. In questa configurazione, nell'organizzazione di Exchange è presente un singolo database delle cartelle pubbliche, pertanto la replica delle cartelle pubbliche è disabilitata.

  • Se si sta eseguendo la migrazione dei dati delle cartelle pubbliche verso un ambiente di replica continua cluster, è possibile utilizzare la replica delle cartelle pubbliche per spostare il contenuto di un database delle cartelle pubbliche da un server Cassette postali autonomo o da un server di cassette postali in cluster presente in un ambiente SCC verso un server di cassette postali in cluster in un ambiente di replica continua cluster. Dopo aver creato il database delle cartelle pubbliche in un ambiente di replica continua cluster, i database delle cartelle pubbliche aggiuntivi dovrebbero essere presenti soltanto fino a quando i dati delle cartelle pubbliche sono stati completamente replicati nell'ambiente di replica continua cluster. Una volta completata la replica, tutti i database delle cartelle pubbliche all'esterno dell'ambiente di replica continua cluster 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 ambiente di replica continua cluster, è possibile utilizzare la replica delle cartelle pubbliche per spostare il contenuto di un database delle cartelle pubbliche da un server di cassette postali in cluster presente in un ambiente di replica continua cluster verso un server Cassette postali autonomo o un server di cassette postali in cluster in un ambiente di cluster a copia singola. Dopo aver creato il database delle cartelle pubbliche aggiuntivo all'esterno dell'ambiente di replica continua cluster, il database delle cartelle pubbliche nell'ambiente di replica continua cluster deve essere presente soltanto fino a quando non è stata completata la replica dei dati delle cartelle pubbliche nei database delle cartelle pubbliche aggiuntivi. Una volta completata la replica, tutti i database delle cartelle pubbliche all'interno di tutti gli ambienti di replica continua cluster devono essere rimossi e tutti i database delle cartelle pubbliche creati successivamente non devono essere ospitati in gruppi di archiviazione abilitati per la replica continua.

Durante un periodo in cui nell'organizzazione di Exchange esistono più database delle cartelle pubbliche e uno o più database delle cartelle pubbliche sono ospitati in un ambiente di replica continua cluster (come, ad esempio, negli scenari di migrazione descritti in precedenza), considerare le differenze nel comportamento per i tempi di attività pianificati (senza perdita di dati) e non pianificati (con perdita di dati):

  • Se si verifica un'interruzione pianificata (senza perdita di dati), il database delle cartelle pubbliche tornerà in linea e la replica delle cartelle pubbliche continuerà come previsto.

  • Se si verifica un'interruzione non pianificata, il database delle cartelle pubbliche non verrà portato in linea fino a quando non saranno disponibili il server originale e tutti i registri del gruppo di archiviazione che ospita il database delle cartelle pubbliche. In caso di un'eventuale perdita di dati dovuta all'interruzione, la replica continua cluster non consentirà di portare in linea il database delle cartelle pubbliche quando la replica delle cartelle pubbliche è abilitata. In questo caso, il nodo originale deve essere portato in linea al fine di evitare una perdita di dati, oppure il database delle cartelle pubbliche deve essere ricreato nel server di cassette postali in cluster nell'ambiente di replica continua cluster e il relativo contenuto deve essere recuperato, utilizzando la replica delle cartelle pubbliche, dai database delle cartelle pubbliche che si trovano all'esterno dell'ambiente di replica continua cluster.

Backup e ripristino e replica continua cluster

Utilizzando la tecnologia VSS, i backup basati su Exchange sono supportati per i gruppi di archiviazione e i database sia di produzione che di copia. I backup di flusso sono supportati solo dal nodo attivo.

Nota

Un'attività comune durante i backup basati su Exchange è il troncamento dei file di registro delle transazioni dopo il completamento corretto del backup. La funzionalità di replica nella replica continua cluster garantisce che i registri non replicati non verranno eliminati. Di conseguenza, l'esecuzione dei backup in una modalità che consente l'eliminazione dei registri non può effettivamente liberare spazio se, durante la replica, la copia dei registri non è in fase sufficientemente avanzata.

I ripristini della copia attiva basati su Exchange possono essere eseguiti utilizzando il flusso o le soluzioni di backup VSS (Volume Shadow Copy Service, Servizio Copia Shadow del volume). I ripristini basati su Exchange non sono supportati per la copia passiva.

Nota

Prima di eseguire il ripristino, è necessario eliminare tutti i file dei gruppi di archiviazione e dei database dalla copia passiva del gruppo di archiviazione.

Dopo il ripristino di un database da un backup in un gruppo di archiviazione in un ambiente di replica continua cluster, è necessario sospendere e riprendere la replica continua per il gruppo di archiviazione utilizzando rispettivamente Suspend-StorageGroupCopy e Resume-StorageGroupCopy. 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 di Microsoft Exchange disporrà di informazioni di generazione del registro obsolete e interromperà la replica dei file di registro.

Calcolo del checksum dei database di manutenzione in linea e azzeramento delle pagine dei database in Exchange 2007 SP1

Il calcolo del checksum consente di verificare l'integrità del database. Lo scrubbing delle pagine è l'azzeramento dei database al termine di un backup di flusso. Exchange 2007 RTM calcola il checksum di un intero database quando viene eseguito il backup di flusso in linea completo di un database. Come specificato in precedenza, negli ambienti di replica continua è possibile eseguire i backup di flusso solo sulla copia attiva di un database. Non è possibile eseguire il backup di flusso della copia passiva di un database. Per eseguire lo snapshot completo o il clone completo di una copia passiva è possibile utilizzare la tecnologia VSS. È inoltre possibile calcolare il checksum degli snapshot e dei cloni completi. In genere, tuttavia, negli ambienti a replica continua è possibile calcolare il checksum senza richiedere né interventi dell'amministratore né tempi di inattività solo su una copia del database, quella attiva o quella passiva. I motivi vengono elencati di seguito.

  • L'esecuzione del backup di flusso della copia attiva di un database e l'esecuzione di backup VSS della copia passiva dello stesso database sono attività onerose.

  • Sebbene sia possibile utilizzare VSS sia per la copia attiva sia per le copie passive del database, questa tecnica non è conforme all'indicazione di ripartire il carico di lavoro dei backup dalla copia attiva a quella passiva.

  • La resilienza può venire temporaneamente compromessa perché l'esecuzione di controlli di integrità manuali mediante le Utilità del database di Exchange (Eseutil) richiede la sospensione della replica continua.

Al fine di abilitare lo scrubbing delle pagine e il controllo del checksum dei database su tutte le copie del database evitando i problemi descritti in precedenza, in Exchange 2007 SP1 sono state introdotte due nuove funzionalità: Calcolo del checksum dei database di manutenzione in linea e azzeramento delle pagine dei database di manutenzione in linea. Queste funzionalità consentono agli amministratori di attivare l'esecuzione in background dell'azzeramento delle pagine e del calcolo del checksum di un database. È possibile abilitare ciascuna funzionalità separatamente o insieme, configurando manualmente appositi valori del registro di sistema nel server Cassette postali che contiene i database da analizzare e riavviando il servizio Archivio informazioni di Microsoft Exchange. I valori del Registro di sistema vengono configurati a livello di Archivio informazioni di Microsoft Exchange. Dopo averle abilitate, le attività in background configurate verranno quindi eseguite su tutti i database del server Cassette postali. Le voci del Registro di sistema sono descritte di seguito.

Avviso

UNRESOLVED_TOKEN_VAL(exRegistry)

Abilitazione del calcolo del checksum del database di manutenzione in linea

Posizione: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

Nome: Checksum manutenzione in linea

Tipo: REG_DWORD

Valore: 0x00000001

Abilitazione dell'azzeramento delle pagine del database di manutenzione in linea

Posizione: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

Nome: Azzeramento pagine database durante checksum

Tipo: REG_DWORD

Valore: 0x00000001

Limitazione delle richieste di calcolo del checksum del database di manutenzione in linea

Posizione: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

Nome: Limitazione delle richieste di calcolo del checksum

Tipo: REG_DWORD

Valore: 0x00000000 (millisecondi)