Installazione della replica continua cluster in Windows Server 2008

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

Ultima modifica dell'argomento: 2008-12-19

Sebbene la distribuzione di una soluzione di replica continua cluster (CCR, Cluster Continuous Replication) in Windows Server 2008 sia simile alla distribuzione di una soluzione di replica continua cluster in Windows Server 2003, esistono alcune differenze significative. Prima dell'utilizzo della replica continua cluster, si raccomanda di rivedere per esteso la sezione Replica continua cluster. Inoltre, assicurarsi di soddisfare tutti i requisiti specificati in Pianificazione di una replica continua cluster.

L'installazione di un ambiente CCR in Windows Server 2008 viene eseguita in diverse fasi:

1. Configurazione dell'impostazione dell'hardware, iniziando dalla creazione e configurazione della rete cluster.

2. Creazione del cluster, iniziando dal primo nodo e successivamente passando al secondo.

3. Configurazione delle reti cluster e della tolleranza per gli heartbeat cluster mancanti.

4. Configurazione e protezione del witness di condivisione file.

5. Installazione dei ruoli del server Cassette postali attivi e passivi nel cluster. Il server di cassette postali in cluster (CMS, Clustered Mailbox Server) viene creato durante l'installazione del ruolo del server Cassette postali attivo.

   Nota

   Si raccomanda di completare ogni fase prima di avviare la fase successiva. Dopo aver completato tutte le fasi, si raccomanda di verificare la soluzione di replica continua cluster prima di inserirla nel contesto di produzione.

Inoltre, esistono alcune attività che devono essere eseguite dopo il completamento dell'installazione:

• Ottimizzazione delle impostazioni di controllo del failover.

• Regolazione della configurazione predefinita del dumpster del trasporto.

• Verifica della possibilità di spostare un server di cassette postali in cluster da un nodo all'altro del cluster.

• Abilitazione di più reti per l'attività di replica continua.

Prima di completare le procedure di riferimento seguenti, è necessario assicurarsi che i computer desiderati dispongano dei componenti del sistema operativo richiesti per l'installazione di Windows Server 2008. Per la procedura dettagliata di installazione dei prerequisiti di Microsoft Exchange in Windows Server 2008, vedere Come installare i prerequisiti di Exchange 2007 SP1 e SP2 in Windows Server 2008 o in Windows Vista.

La sezione seguente descrive più dettagliatamente ognuna delle fasi di installazione.

Creazione e configurazione della rete

È necessario disporre di un numero sufficiente di indirizzi IP quando si creano server di cassette postali in cluster in un ambiente CCR a due nodi in Windows Server 2008. Il clustering di failover di Windows Server 2008 introduce nuove funzionalità di rete che rappresentano un'importante differenza rispetto ai cluster legacy. Ad esempio, i cluster di failover di Windows Server 2008 introducono il supporto di più subnet, il supporto per i protocolli HDCP (Dynamic Host Configuration Protocol), IPv4 (Internet Protocol version 4 ) e IPv6. Quando viene eseguito in un cluster di failover di Windows Server 2008, Exchange Server 2007 SP1 include il supporto per cluster geograficamente lontani per failover in due subnet. Questo supporto include i cluster a copia singola (SCC, Single Copy Cluster) e i server Cassette postali in un ambiente CCR.

Iniziando dal clustering di failover di Windows Server 2008, ora i singoli nodi cluster possono trovarsi in reti instradate separate. È pertanto necessario che le risorse dipendenti da risorse indirizzo IP (ad esempio le risorse Nome di rete) implementino una logica OR in quanto è improbabile che ciascun nodo del cluster disponga di una connessione locale diretta a ciascuna rete conosciuta dal cluster. Questo facilita la messa in linea delle risorse indirizzo IP e nome di rete quando i servizi o le applicazioni eseguono il failover su nodi remoti.

Tutti gli indirizzi IP in linea associati a una risorsa del nome di rete sono registrati dinamicamente in DNS (Domain Name System), se configurati per gli aggiornamenti dinamici, con l'elenco ordinato in modo che le risorse indirizzo IP in linea siano restituite per prime ai client. Poiché i nodi cluster possono essere posizionati su diverse reti instradate e i meccanismi di comunicazione sono stati modificati in modo che utilizzino protocolli di sessione affidabili implementati tramite UDP (User Datagram Protocol) (unicast), i requisiti di rete per cluster geograficamente lontani non sono più applicabili. Di conseguenza, le organizzazioni possono distribuire un cluster di failover in due centri dati fisici senza dover utilizzare la tecnologia VLAN per occupare le subnet cluster in due percorsi.

Gli indirizzi IP sono obbligatori sia per le reti pubbliche che per quelle private. Di seguito vengono riportati i requisiti relativi agli indirizzi privati e pubblici:

• Indirizzi privati   Ogni nodo richiede un indirizzo IP per ogni scheda di rete utilizzata per la rete privata cluster. Si può utilizzare un indirizzo IPv4 statico oppure un indirizzo IPv6 assegnato dinamicamente. È necessario utilizzare indirizzi IP 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 nodi.

• Indirizzi pubblici   Ogni nodo richiede un indirizzo IP per ogni scheda di rete utilizzata per la rete pubblica cluster, denominata anche rete mista. Gli indirizzi IP, inoltre, sono necessari per rendere il cluster di failover e il server di cassette postali in cluster accessibili a client e amministratori. È necessario utilizzare indirizzi IP che non si trovino sulla stessa subnet o rete di una delle reti private. È possibile utilizzare indirizzi IPv4 statici, indirizzi IPv4 DHCP o indirizzi IPv6 statici.

  Importante

  Tutte le schede di rete per una rete cluster devono utilizzare la stessa versione di TCP/IP, ovvero devono utilizzare tutte IPv4, IPv6 o sia IPv4 che IPv6.

Procedure di rete consigliate per i server di cassette postali in cluster

Raccomandiamo anche di attenersi alle seguenti procedure consigliate per la rete cluster:

• Utilizzare nomi significativi   La compilazione di un cluster offre molte opportunità di utilizzare nomi significativi per cluster, nodi cluster, interfacce di rete cluster e server di cassette postali in cluster. La rete utilizzata per comunicare con altri server e client di Exchange può, ad esempio, essere chiamata Pubblica. La rete utilizzata per la comunicazione tra i nodi cluster può invece essere definita Privata. Utilizzare nomi che possono essere messi in relazione l'uno con l'altro senza dover consultare una pianta della topologia di rete. Un'altra convenzione utile consiste nel mettere in relazione i nodi di un cluster con il nome del server di cassette postali in cluster. Ad esempio, utilizzare mbx01, mbx01-nodo1 e mbx01-nodo2 rispettivamente per il server di cassette postali in cluster e per i due nodi.

• Utilizzare indirizzi IP privati per le interfacce di rete privata   Vedere la tabella riportata di seguito in cui sono elencati gli intervalli di indirizzi IP e le subnet mask utilizzabili per le interfacce di rete privata in ciascun nodo.

  Intervalli di indirizzi e subnet mask per le interfacce di rete privata

  Rete / Nodo	Intervallo indirizzi IP	Subnet mask
  Privata / NODE1	10.10.10.10-255	255.255.255.0
  Privata / NODE2	10.10.10.11-255	255.255.255.0

Notare quanto segue:

• Se la rete pubblica utilizza la rete 10.x.x.x e la subnet mask 255.255.255.0, è consigliabile utilizzare indirizzi IP di rete privata e subnet mask alternativi.

• Non si consiglia di utilizzare per la rete privata tipi di scheda con tolleranza di errore o "teaming". Se è necessaria la ridondanza per la rete privata, utilizzare più schede di rete configurate solo per l'utilizzo in cluster. Se si utilizza questa tecnologia, è importante verificare che firmware e driver siano della versione più recente. Per informazioni sulla compatibilità di un cluster di server, contattare il fabbricante della scheda di rete. Per ulteriori informazioni sul teaming della scheda di rete nella distribuzione di cluster di failover vedere l'articolo 254101 della Microsoft Knowledge Base, Teaming della scheda di rete e cluster di server.

Formazione del cluster di failover

Un cluster di failover viene formato quando viene aggiunto il primo nodo al cluster. Questa processo consente di dare al cluster un nome di rete e un indirizzo IP univoci. Il nome di rete e l'indirizzo IP, che formano l'identità di rete del cluster, si spostano tra i nodi nel cluster quando questi passano alla modalità in linea e non in linea. L'identità di rete del cluster viene raramente utilizzata nell'amministrazione di un server di cassette postali in cluster.

Se si ha familiarità con la distribuzione di cluster di failover o cluster di Exchange dalle precedenti versioni, si noterà che la distribuzione di un cluster per la replica continua cluster è abbastanza diversa. Se invece è la prima volta che si sperimenta una soluzione cluster, si scoprirà che la distribuzione è molto meno complessa delle configurazioni cluster tipiche.

È possibile compilare un nuovo cluster utilizzando le istruzioni contenute in Come creare un cluster di failover di Windows Server 2008 per la replica continua cluster.

Aggiunta di nodi supplementari

Dopo avere installato il Servizio cluster nel primo nodo, si noterà che sarà necessario meno tempo per installarlo nel secondo nodo, dal momento che il programma di installazione utilizza le impostazioni di rete configurate nel primo nodo come base per la configurazione delle impostazioni di rete nei nodi successivi. Prima di poter aggiungere e configurare il secondo nodo, è necessario convalidare la configurazione del cluster. È possibile verificare che il Servizio cluster sia in funzione e che il cluster sia operativo eseguendo Cluster.exe dal prompt dei comandi. Il risultato deve essere simile al codice riportato di seguito:

C:\>cluster group
Listing status for all available resource groups:
Group                   Node            Status
------------------ ---------------      ------
Cluster Group         <NODEName>        Online

Si consiglia inoltre di esaminare i registri degli eventi per verificare la presenza di eventuali errori o avvisi che potrebbero richiedere particolare attenzione prima di continuare. Per la procedura dettagliata per aggiungere il secondo nodo al cluster, vedere Come creare un cluster di failover di Windows Server 2008 per la replica continua cluster.

Configurazione di reti cluster

Dopo avere aggiunto entrambi i nodi al cluster, occorre configurare i componenti di rete del cluster. In particolare è necessario configurare reti per accesso client e cluster, nonché impostazioni di tolleranza per heartbeat cluster mancanti. Si consiglia inoltre di rinominare le reti cluster con nomi più significativi.

Nella tabella seguente sono riportate in dettaglio le opzioni disponibili per la configurazione di reti cluster per l'heartbeat cluster.

Opzioni per configurare le reti cluster

Per essere supportati, i server di cassette postali in cluster distribuiti in un ambiente di replica continua cluster richiedono almeno due schede di rete in entrambi i nodi. In Exchange 2007 SP1 qualunque rete gestita dal Servizio cluster e abilitata sia per l'utilizzo in cluster sia per le connessioni client (ad esempio configurata come rete mista) può essere utilizzata per le funzionalità di replica continua, inclusi il seeding, il log shipping e il reseeding. Ciò si ottiene utilizzando un nuovo cmdlet in Exchange 2007 SP1 denominato Enable-ContinuousReplicationHostName.

Configurazione delle impostazioni di tolleranza per heartbeat cluster mancanti

Una volta configurate le comunicazioni cluster e la priorità della rete, si consiglia di configurare impostazioni di tolleranza specifiche per heartbeat cluster mancanti. In questo modo si configura il monitoraggio del Servizio cluster della connettività di rete tra nodi cluster in modo che tolleri le piccole interruzioni. In caso di brevi interruzioni di rete, quindi, non si verifica il failover. Si consiglia di configurare reti cluster private e miste su tutti i nodi fino a dieci heartbeat mancanti. Questo livello di impostazione corrisponde a circa 12 secondi.

Per la procedura dettagliata della configurazione dei componenti di rete del cluster, vedere Come configurare reti cluster per un cluster di failover.

Configurazione delle impostazioni TTL per la risorsa del nome di rete del server di cassette postali in cluster

Sono disponibili due scenari di distribuzione in cui l'adozione di opzioni di interruzione o di recupero prevede una modifica dell'indirizzo IP assegnato al server di cassette postali in cluster:

• Un server di cassette postali in cluster viene distribuito in un ambiente con più subnet.

• Un cluster di standby viene utilizzato per il recupero di un cluster danneggiato.

In entrambi gli scenari, il nome del server di cassette postali in cluster non cambia, ma cambia l'indirizzo IP assegnatogli. I client e gli altri server che comunicano con un server di cassette postali in cluster con indirizzi IP modificati non saranno 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 TTL del DNS su cinque minuti per la risorsa del nome di rete del server di cassette postali in cluster.

Per impostazione predefinita, nel Servizio cluster il valore TTL del DNS delle risorse Nome rete è impostato su 20 minuti. Sebbene sia possibile utilizzare gli strumenti di gestione del DNS per regolare manualmente il valore TTL del nome host direttamente nel database di DNS, il valore nel database di DNS verrà sovrascritto e impostato sul valore predefinito del Servizio cluster di 20 minuti ogni volta che viene aggiornata la registrazione del nome di rete nel DNS. Un aggiornamento della registrazione del nome di rete nel DNS si verifica ogni volta che il server di cassette postali in cluster viene avviato, spostato o riportato in linea dopo un errore o un failover.

In Windows Server 2008 è stata aggiunta una nuova proprietà privata alle risorse del nome di rete nei cluster di failover. La nuova proprietà è denominata HostRecordTTL ed è possibile configurarla utilizzando Cluster.exe.

Per la procedura dettagliata di configurazione dei valori TTL del DNS per la risorsa del nome di rete del CMS 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.

Configurazione del quorum del cluster

Una volta configurate le reti cluster, configurare il cluster di failover per l'utilizzo di una risorsa quorum di maggioranza dei nodi e di condivisione file. Per la procedura dettagliata di configurazione di un cluster di failover per l'utilizzo del modello del quorum di maggioranza dei nodi e di condivisione file, vedere Configurazione del quorum maggioranza dei nodi e delle condivisioni di file.

Convalida del cluster di failover

Windows Server 2008 include una nuova procedura guidata, denominata Convalida guidata di una configurazione, utilizzabile per verificare l'integrità e la configurazione di un cluster di failover. Si consiglia di eseguire questa procedura guidata prima di installare Exchange 2007 nel cluster. Eseguendo questa procedura guidata prima di installare Exchange 2007, è possibile identificare e risolvere problemi di configurazione dell'indirizzo nel cluster che potrebbero impedire l'installazione di Exchange.

La Convalida guidata di una configurazione include quattro gruppi di test progettati per verificare che il cluster soddisfi i requisiti necessari per essere supportato da Microsoft. Oltre a questi requisiti, la soluzione cluster deve disporre del logo di compatibilità Designed for Windows Server 2008.

I quattro gruppi di test sono: inventario, rete, archiviazione e configurazione di sistema. Poiché la replica continua cluster non utilizza l'archiviazione condivisa, non è necessario eseguire il gruppo di test di archiviazione. Se si esegue il gruppo di test di archiviazione per un cluster di failover che non dispone di risorse di archiviazione del cluster, quali un cluster di failover progettato per la replica continua cluster, il gruppo di test di archiviazione non verrà eseguito correttamente. Tutti gli errori del gruppo di test di archiviazione potranno essere ignorati senza problemi, perché la mancanza di archiviazione condivisa è prevista per un cluster di failover progettato per la replica continua cluster.

Per la procedura dettagliata relativa alla convalida del cluster di failover, vedere Come convalidare una configurazione cluster di failover.

Installazione e configurazione di server di cassette postali in cluster

È possibile installare il ruolo del server Cassette postali in un cluster eseguendo alcuni passaggi in ciascun nodo. Dopo la formazione e la convalida del cluster, e dopo la configurazione del cluster per l'utilizzo del quorum di Maggioranza dei nodi con la funzione server di controllo del mirroring della condivisione di file, è necessario installare prima il ruolo del server Cassette postali sul nodo attivo. Per la procedura dettagliata relativa all'installazione del ruolo del server Cassette postali nel nodo attivo, vedere Come installare il ruolo Cassette postali in cluster attivo in un ambiente di replica continua cluster in Windows Server 2008.

Dopo l'installazione del ruolo del server Cassette postali e del server di cassette postali in cluster nel nodo attivo e dopo la verifica della configurazione del primo gruppo di archiviazione, è necessario installare il ruolo del server Cassette postali nel nodo passivo. Per la procedura dettagliata relativa all'installazione del ruolo del server Cassette postali nel nodo passivo, vedere Come installare il ruolo Cassette postali in cluster passivo in un ambiente di replica continua cluster in Windows Server 2008.

Dopo l'installazione del ruolo del server Cassette postali, è possibile ottimizzare le impostazioni del failover. Per ulteriori informazioni sull'ottimizzazione del failover, vedere Come regolare le impostazioni di montaggio e di failover per la replica continua cluster.

Attività successive all'installazione

Una volta installato il ruolo del server Cassette postali in entrambi i nodi e creato il server di cassette postali in cluster, è necessario eseguire alcune attività successive all'installazione. Ad esempio:

• Abilitazione di più reti per l'attività di replica continua.

• Ottimizzazione delle impostazioni di controllo del failover.

• Regolazione della configurazione predefinita del dumpster del trasporto.

• Verifica della possibilità di spostare un server di cassette postali in cluster da un nodo all'altro del cluster.

Abilitazione di più reti per l'attività di replica continua

Nella versione di produzione (RTM) di Microsoft Exchange Server 2007 la copia e il seeding dei file di registro si verificano nella rete pubblica. In Exchange 2007 SP1 è possibile abilitare per l'attività di replica continua cluster eventuali reti cluster configurate come reti miste. L'attività comprende il seeding, il reseeding e il log shipping del gruppo di archiviazione.

In Exchange 2007 SP1 è possibile abilitare per la replica continua solo reti cluster progettate come miste. Per rete mista si intende qualunque rete cluster configurata per il traffico cluster (comunicazione tra nodi) e di accesso client. Non è possibile abilitare per la replica continua le reti cluster configurate per l'accesso cluster ma non per l'accesso client (definite anche reti private).

Il supporto per il log shipping in un rete mista viene configurato mediante un nuovo cmdlet denominato Enable-ContinuousReplicationHostName. In modo simile, la disattivazione della funzionalità si ottiene utilizzando il cmdlet Disable-ContinuousReplicationHostName. Se un server di cassette postali in cluster è presente in un ambiente di replica continua cluster, l'amministratore può eseguire Enable-ContinuousReplicationHostName su entrambi i nodi del cluster e specificare due indirizzi IP e nomi host. Quindi il sistema seleziona in modo casuale una rete mista per la copia dei registri dopo che la configurazione è stata eseguita correttamente e dopo la conferma che la rete mista è operativa.

Per la procedura dettagliata di abilitazione delle reti cluster per l'attività di replica continua, vedere Come abilitare le reti di cluster ridondanti per il log shipping e il seeding in Windows Server 2008.

Il seeding e il reseeding in un ambiente di replica continua cluster vengono eseguiti utilizzando il cmdlet Update-StorageGroupCopy. In Exchange 2007 SP1 questo cmdlet è stato esteso per includere un nuovo parametro denominato DataHostNames. Tale parametro consente di specificare la rete da utilizzare per il seeding o il reseeding. Il valore è un elenco di due nomi a più valori: un nome di dominio completo (FQDN, Fully Qualified Domain Name) o un nome host. Uno di questi nomi deve indicare il nodo passivo.

Ottimizzazione delle impostazioni di controllo del failover

La funzione di replica continua cluster include attributi che consentono di controllare il comportamento del failover di un server di cassette postali in cluster. È possibile configurare questi attributi utilizzando il cmdlet Set-MailboxServer. Questi attributi consentono di controllare i due algoritmi decisionali riportati di seguito:

• Algoritmo 1   L'algoritmo 1 consente di controllare se un database viene installato entro il tempo di failover. Al momento del failover, se il database ha perso un numero di registri inferiore a quello configurato, verrà montato automaticamente. È possibile configurare il numero di registri persi utilizzando un valore denominato AutoDatabaseMountDial. Questo parametro, rappresentato in Active Directory da un attributo di Exchange Server denominato msExchDataLossForAutoDatabaseMount, può avere tre valori: Senza perdita di dati, Buona disponibilità e Disponibilità ottimale. Senza perdita di dati indica 0 registri persi, Buona disponibilità indica 3 registri persi e Disponibilità ottimale, ovvero l'impostazione predefinita, indica 6 registri persi. Per informazioni dettagliate su come configurare tali valori, vedere Come regolare le impostazioni di montaggio e di failover per la replica continua cluster.

• Algoritmo 2   L'algoritmo 2 consente di determinare se è più importante essere in linea con dati non aggiornati oppure essere non in linea. Se il database non viene montato sulla base dell'algoritmo 1, è possibile definire il momento in cui eseguire una seconda verifica. Il tempo di attesa è configurato dall'attributo ForcedDatabaseMountAfter. Il valore può essere espresso in unità di ore, l'impostazione predefinita è illimitato.

  Importante

  Quando viene raggiunto il valore di ForcedDatabaseMountAfter, il database verrà montato, indipendentemente dal fatto che la copia del gruppo di archiviazione sia indietro di 1 registro, di 10 registri o di 1.000 registri, nel qual caso ne risulterebbe una perdita di dati significativa. Per tale motivo non è consigliabile utilizzare questo parametro se i contratti di servizio (SLA, Service Level Agreement) garantiscono un valore massimo per la quantità di dati che è possibile perdere.

Regolazione del dumpster del trasporto

Il dumpster del trasporto è una funzionalità del ruolo del server Trasporto Hub che deve essere configurata quando si utilizza la replica continua locale (LCR) o la replica continua cluster (CCR) e solo negli ambienti LCR e CCR. Il dumpster del trasporto invia la posta inoltrata di recente dopo un'interruzione non pianificata. Quando si utilizza la replica continua locale o la replica continua cluster è sempre necessario abilitare il dumpster del trasporto. Il dumpster del trasporto viene abilitato in tutta l'organizzazione impostando la quantità di spazio di archiviazione disponibile per gruppo di archiviazione e impostando il tempo di conservazione della posta nel dumpster del trasporto.

Il server Trasporto Hub mantiene una coda di posta recapitata di recente a un server di cassette postali in cluster. Nel caso di un failover con perdita di dati, la replica continua cluster richiede automaticamente a ogni server Trasporto Hub presente nel sito di inviare nuovamente la posta a partire dalla coda del dumpster del trasporto. Negli ambienti di replica continua locale la richiesta per il nuovo invio viene eseguita come parte dell'attività di Restore-StorageGroupCopy. Quando si verifica il reinvio, l'archivio delle informazioni elimina automaticamente i duplicati e recapita nuovamente la posta andata perduta. Per modificare le impostazioni di configurazione predefinite del dumpster del trasporto, applicate a livello del gruppo di archiviazione, è possibile utilizzare il cmdlet Set-TransportConfig. In alternativa, in Exchange 2007 SP1 è anche possibile utilizzare Exchange Management Console per configurare i valori del dumpster del trasporto.

Si consiglia di configurare la dimensione massima per gruppo di archiviazione (il parametro MaxDumpsterSizePerStorageGroup) su una dimensione pari a 1,5 volte la dimensione massima del messaggio inviabile. Ad esempio, se la dimensione massima per i messaggi è pari a 10 megabyte (MB), il parametro MaxDumpsterSizePerStorageGroup deve essere configurato con un valore di 15 MB. Per le organizzazioni senza dimensione massima dei messaggi è consigliabile configurare la dimensione massima per gruppo di archiviazione con un valore pari a 1,5 volte la dimensione della dimensione media dei messaggi inviati nell'organizzazione.

È anche consigliabile configurare il tempo di conservazione massimo per gruppo di archiviazione (il parametro MaxDumpsterTime) su un valore pari a 07.00:00:00, ovvero 7 giorni. Quest'arco di tempo è sufficiente a garantire che non si verifichino perdite di posta elettronica in caso di interruzioni estese. Quando si utilizza la funzione del contenitore del trasporto, è necessario uno spazio supplementare su disco del server Trasporto Hub per ospitare le code del contenitore del trasporto. La quantità di spazio di archiviazione necessario è pari all'incirca al valore del parametro MaxDumpsterSizePerStorageGroup moltiplicato per il numero dei gruppi di archiviazione di tutti i server Cassette postali che utilizzano la replica continua nel sito di Active Directory contenente il server Trasporto Hub.

Per istruzioni dettagliate su come abilitare e configurare il dumpster del trasporto, vedere Configurazione del dumpster di trasporto.

Verifica della soluzione replica continua cluster

Una volta completata l'installazione di una soluzione di replica continua cluster oppure una volta apportate modifiche significative alla configurazione, si consiglia di verificare l'integrità e lo stato del server di cassette postali in cluster e che entrambi i nodi siano correttamente configurati per supportare tale server.

La soluzione consigliata per verificare l'integrità e lo stato del server di cassette postali in cluster è di eseguire i cmdlet Test-ReplicationHealth, Get-StorageGroupCopyStatus e Get-ClusteredMailboxServerStatus.

• Il cmdlet Test-ReplicationHealth è nuovo in Exchange 2007 SP1. Questo cmdlet è progettato per il monitoraggio proattivo della replica continua e della pipeline di replica continua. Il cmdlet Test-ReplicationHealth verifica tutti gli aspetti inerenti a replica, servizi cluster e stato di riproduzione e replica dei gruppi di archiviazione per fornire una panoramica completa del sistema di replica. Per ulteriori informazioni sul cmdlet Test-ReplicationHealth, vedere Test-ReplicationHealth.

• Il cmdlet Get-StorageGroupCopyStatus fornisce informazioni sullo stato della replica corrente per ciascun gruppo di archiviazione. Per la procedura dettagliata di visualizzazione dello stato dei gruppi di archiviazione in un ambiente di replica continua cluster, vedere Come visualizzare lo stato di una copia di replica continua cluster utilizzando Exchange Management Shell.

• Il cmdlet Get-ClusteredMailboxServerStatus fornisce informazioni sullo stato operativo di base del server di cassette postali in cluster. Per la procedura dettagliata per ottenere informazioni sullo stato operativo di base di un server di cassette postali in cluster, vedere Come visualizzare lo stato del server cassette postali cluster.

Il metodo più appropriato per verificare che entrambi i nodi siano in grado di portare in linea il server di cassette postali in cluster è l'utilizzo del cmdlet Move-ClusteredMailboxServer per spostare il server di cassette postali in cluster su ogni nodo. In Exchange 2007 SP1 è possibile utilizzare anche la Gestione guidata server di cassette postali in cluster in Exchange Management Console per spostare un server di cassette postali in cluster da un nodo all'altro, in modo da verificare che entrambi possano portare in linea il server.