Installazione della replica continua cluster
Si applica a: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007
Ultima modifica dell'argomento: 2007-10-30
Prima dell'utilizzo della replica continua cluster (CCR), si consiglia di rivedere per esteso la sezione Replica continua cluster. Assicurarsi inoltre di soddisfare tutti i requisiti specificati in Pianificazione di una replica continua cluster. L'installazione di un ambiente di replica continua cluster (CCR) in Windows Server 2003 viene eseguita in diverse fasi:
Configurazione dell'impostazione dell'hardware, iniziando dalla creazione e configurazione della rete cluster.
Creazione del cluster, iniziando dal primo nodo e successivamente passando al secondo.
Configurazione e protezione del witness di condivisione file e configurazione delle reti di cluster e della tolleranza per heartbeat cluster mancanti.
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.
È anche necessario eseguire alcune attività post-installazione per il server di cassette postali in cluster:
Ottimizzazione delle impostazioni di controllo del failover.
Regolazione della configurazione predefinita del dumpster di trasporto.
Verifica della possibilità di spostare un server di cassette postali in cluster da un nodo all'altro del cluster.
Attivazione di una o più reti miste per il log shipping e il seeding.
La sezione seguente descrive più dettagliatamente ognuna delle fasi di installazione.
Creazione e configurazione della rete
Quando si creano server di cassette postali in cluster in un ambiente CCR a due nodi, è necessario disporre di un numero sufficiente di indirizzi IP statici. Gli indirizzi IP sono necessari sia per le reti pubbliche che per quelle private, e tutti gli indirizzi IP per ogni rete cluster si devono trovare nella stessa subnet. Di seguito vengono riportati i requisiti relativi agli indirizzi privati e pubblici:
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 nodi.
Indirizzi pubblici Ogni nodo richiede un indirizzo IP statico per ogni scheda di rete utilizzata per la rete pubblica cluster. Gli indirizzi IP statici, 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 statici che non si trovino sulla stessa subnet o rete di una delle reti private.
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 creazione 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.
Intervalli di indirizzi e subnet mask per le interfacce di rete privata
Rete Intervallo indirizzi IP Subnet mask Privata 1
10.10.10.10-255
255.255.255.0
Privata 2
10.10.10.11-255
255.255.255.0
Notare quanto segue:
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.
Non si consiglia di utilizzare per la rete privata tipi di scheda con tolleranza di errore o "teaming". Se è necessaria ridondanza per la rete privata, utilizzare più schede di rete impostate solo sulla comunicazione interna e definirne la priorità di rete nella configurazione cluster. Se si utilizza questa tecnologia, è importante verificare che firmware e driver siano della versione più recente. Per informazioni sulla compatibilità di un server cluster, contattare il fabbricante della scheda di rete. Per ulteriori informazioni sul teaming della scheda di rete nella distribuzione cluster dei server vedere l'articolo 254101 della Microsoft Knowledge Base, Teaming della scheda di rete e distribuzione cluster dei server (informazioni in lingua inglese).
Per configurare le reti nel cluster per l'utilizzo con una soluzione CCR di Microsoft Exchange Server 2007, configurare le reti pubbliche e private seguendo le procedure descritte nei seguenti argomenti: Come configurare le connessioni di rete per la replica continua cluster.
Formazione del cluster di failover
Un cluster di failover viene formato quando viene aggiunto il primo nodo al cluster. Questo processo consente di dare al cluster un nome di rete e un indirizzo IP univoci. Il nome di rete e l'indirizzo IP, che costituiscono 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 creare un nuovo cluster utilizzando le istruzioni della sezione Come creare un cluster di failover di Windows Server 2003 per la replica continua cluster. Questa procedura include istruzioni di interfaccia utente grafica e di interfaccia della riga di comando per la creazione del cluster di failover, aggiungendo il secondo nodo al cluster di failover e configurando il cluster in modo che venga utilizzato un quorum maggioranza dei nodi (MNS, Majority Node Set).
Nota
CCR in Windows Server 2003 richiede un modello di quorum denominato quorum MNS con witness di condivisione file. Questo modello di quorum è disponibile in Windows Server 2003 Service Pack 2 (SP2), richiesto per Exchange 2007 Service Pack 1 (SP1). Per utilizzare il quorum MNS con witness di condivisione file con la versione di produzione (RTM) di Exchange 2007 e Windows Server 2003 SP1, è necessario installare un aggiornamento rapido in ogni nodo prima di distribuire la replica continua cluster. 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 Microsoft Windows Server 2003 Service Pack 1 (informazioni in lingua inglese). Per la procedura dettagliata relativa all'installazione degli aggiornamenti rapidi necessari, vedere Come installare la funzione di witness di condivisione file della maggioranza dei nodi.
Configurazione post-installazione del cluster di failover
Dopo che il cluster di failover è stato creato con entrambi i nodi e configurato con un quorum MNS, è necessario eseguire alcune attività post-installazione prima dell'installazione di Exchange in uno dei nodi. È necessario configurare le reti di cluster, la tolleranza per heartbeat cluster mancanti e il componente witness di condivisione file del quorum MNS.
Configurazione di reti in cluster
Dopo avere aggiunto entrambi i nodi al cluster, occorre configurare i componenti di rete del cluster. In particolare, è necessario configurare le reti di cluster, la priorità della rete cluster e le impostazioni di tolleranza per heartbeat cluster mancanti. Nella seguente tabella vengono riportate le opzioni disponibili per la configurazione delle reti di cluster.
Opzioni per la configurazioni delle reti di cluster
| Opzione | Descrizione |
|---|---|
Solo accesso client (rete pubblica) |
Selezionare questa opzione se si desidera che il Servizio cluster utilizzi questa scheda di rete solo per la comunicazione esterna con altri client. In questa scheda di rete non si verificherà alcun traffico per le comunicazioni tra nodi o per l'aggiornamento del database cluster. |
Solo comunicazioni cluster interne (rete privata) |
Selezionare questa opzione se si desidera che il servizio cluster utilizzi questa rete solo per il traffico relativo alle comunicazioni tra nodi e all'aggiornamento del database cluster. |
Tutte le comunicazioni (rete mista) |
Selezionare questa opzione se si desidera che il servizio cluster utilizzi la scheda di rete per il traffico relativo alle comunicazioni tra nodi e all'aggiornamento del database cluster, nonché per le comunicazioni con client esterni. Tale opzione è selezionata per impostazione predefinita per tutte le reti. |
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 un ambiente di replica continua cluster (CCR) si consiglia di configurare una rete come rete privata e l'altra rete come rete mista. Se una rete è configurata come rete privata e l'altra come rete pubblica, la rete privata rappresenta un singolo punto di errore per il server di cassette postali in cluster.
Per la procedura dettagliata della configurazione dei componenti di rete del cluster, vedere Come configurare i componenti e della priorità di una rete cluster.
Configurazione delle impostazioni di tolleranza per heartbeat cluster mancanti
Una volta configurate le comunicazioni cluster e la priorità di rete, si consiglia di configurare le impostazioni di tolleranza specifiche per gli heartbeat cluster mancanti. In questo modo, il monitoraggio del servizio cluster della connettività di rete tra i nodi cluster viene configurato in modo da consentire la tolleranza alle interruzioni di breve durata. Viene quindi evitato il failover nei casi in cui l'interruzione di rete è di breve durata. Si consiglia di configurare reti di cluster private e miste su entrambi i nodi fino a dieci heartbeat mancanti. Il livello di impostazione corrisponde a 12 secondi circa.
Per la procedura dettagliata relativa alla configurazione della tolleranza del servizio cluster per heartbeat mancanti, vedere How to Configure Tolerance Settings for Missed Cluster Heartbeats.
Configurazione della funzione server di controllo del mirroring della condivisione di file
Dopo la formazione e la configurazione del cluster, è necessario configurare la funzione server di controllo del mirroring della condivisione di file. La replica continua cluster utilizza la funzione server di controllo del mirroring della condivisione di file su un terzo computer per evitare che si verifichi una partizione di rete all'interno del cluster, nota anche come split brain syndrome. La sindrome da cervello diviso in un ambiente di replica continua cluster si verifica quando:
Tutte le reti designate per le comunicazioni cluster interne si arrestano.
Entrambi i nodi non possono scambiarsi i segnali heartbeat.
Entrambi i nodi diventano attivi portando o tentando di portare in linea il server di cassette postali in cluster.
La condivisione di file per la funzione server di controllo del mirroring della condivisione di file può essere ospitata su qualsiasi server su cui è in esecuzione il sistema operativo Microsoft Windows. Tuttavia, per ospitarla, si consiglia di utilizzare un server Trasporto Hub nel sito del servizio directory di Active Directory contenente i nodi del cluster. Per verificare che un amministratore di Exchange disponga delle autorizzazioni e del controllo completi sulla condivisione, è consigliabile un server Trasporto Hub. Per la procedura dettagliata della configurazione della condivisione di file per l'utilizzo per la funzione server di controllo del mirroring della condivisione di file, vedere Come configurare il witness di condivisione file.
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 MNS con la funzione di witness di condivisione file, è necessario installare prima il ruolo del server Cassette postali nel nodo attivo. L'installazione del nodo attivo è un processo che consente di installare il ruolo del server Cassette postali nel nodo e, successivamente, creare un server di cassette postali in cluster nel nodo.
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 2003.
Nota
Se si installa il nodo attivo in un computer su cui è in esecuzione Windows Server 2003 che non si trova nello stesso sito di Active Directory in cui si trova il controller di dominio assegnato al ruolo di controller di dominio primario (PDC, Primary Domain Controller), è prima necessario creare un account computer con il nome che si intende assegnare al server di cassette postali in cluster. È necessario che l'account computer sia attivato e che l'oggetto computer sia disponibile nel sito di Active Directory locale. Se non esiste un account computer per il server di cassette postali in cluster e il PDC non si trova nel sito di Active Directory locale, il programma di installazione verrà interrotto.
Dopo l'installazione del ruolo del server Cassette postali sul nodo attivo, si consiglia di verificare che la configurazione del database del primo gruppo di archiviazione e i registri delle transazioni siano conformi a quanto previsto. Prima di procedere con il secondo nodo, potrebbe essere necessario spostarli. Per impostazione predefinita, il primo gruppo di archiviazione e il primo database si trovano nel percorso %ProgramFiles%\Microsoft\Exchange Server\Mailbox\First Storage Group.
Per la procedura dettagliata relativa alla configurazione del primo gruppo di archiviazione per un cluster, vedere Come spostare un gruppo di archiviazione e il relativo database.
Dopo l'installazione del ruolo del server Cassette postali e del server di cassette postali in cluster sul nodo attivo e dopo la verifica della configurazione del primo gruppo di archiviazione, è necessario installare il ruolo del server Cassette postali sul nodo passivo. L'installazione del nodo passivo è un processo che consente di installare il ruolo del server Cassette postali nel nodo. 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 2003.
Attività successive all'installazione
Una volta installato il ruolo del server Cassette postali su entrambi i nodi e creato il server di cassette postali in cluster, è necessario eseguire alcune attività successive all'installazione. Ad esempio:
Ottimizzazione delle impostazioni di controllo del failover.
Regolazione della configurazione predefinita del dumpster di 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.
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 montato 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. Quando si configura il sistema su Buona disponibilità o su Disponibilità ottimale, non utilizzare spazi. Ad esempio, utilizzare GoodAvailability e BestAvailability.
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.
Per ulteriori informazioni sull'ottimizzazione del failover, vedere Come regolare il failover e le impostazioni di installazione per la replica continua cluster.
Regolazione del dumpster di trasporto
Il dumpster di trasporto è una funzionalità del ruolo del server Trasporto Hub che consente di inviare la posta inoltrata di recente dopo un'interruzione non pianificata. Quando si utilizza la replica continua cluster o la relica continua locale (LCR) è necessario sempre abilitare il dumpster di trasporto. Il dumpster di 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 di 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 di trasporto. L'archivio delle informazioni elimina automaticamente i duplicati e inoltra nuovamente la posta andata perduta. È possibile utilizzare Exchange Management Console o il cmdlet Set-TransportConfig in Exchange Management Shell per modificare le impostazioni di configurazione predefinite del dumpster di trasporto che vengono applicate a livello del gruppo di archiviazione.
Si consiglia di configurare il parametro MaxDumpsterSizePerStorageGroup, che specifica la dimensione massima della coda del dumpster di trasporto per ogni gruppo di archiviazione, su un valore 1,5 volte maggiore rispetto alla dimensione massima dei messaggi inviabili. 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. Si consiglia inoltre di configurare il parametro MaxDumpsterTime, che specifica per quanto tempo un messaggio di posta elettronica deve rimanere nella coda del dumpster di trasporto, impostandolo sul valore 7.00:00:00, che equivale a 7 giorni. Si tratta di un periodo di tempo sufficiente a garantire il verificarsi di una prolungata interruzione senza perdita di messaggi di posta elettronica. Quando si utilizza la funzione di dumpster di trasporto, è necessario uno spazio supplementare sul server Trasporto Hub per ospitare le code del dumpster di 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 di cassette postali in cluster in un ambiente di replica continua cluster e per tutti i gruppi di archiviazione abilitati per la replica continua locale nel sito di Active Directory che contiene il server Trasporto Hub.
Per istruzioni dettagliate su come abilitare e configurare il dumpster di 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 Get-StorageGroupCopyStatus e Get-ClusteredMailboxServerStatus:
Il cmdlet Get-StorageGroupCopyStatus fornisce informazioni sullo stato della replica corrente per ciascun gruppo di archiviazione. Per la procedura dettagliata relativa alla 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.
Abilitazione di più reti per l'attività di replica continua
Nella versione di produzione (RTM) di Exchange 2007 tutte le operazioni di seeding e di copia dei file di registro vengono eseguite sulla rete pubblica. In Exchange 2007 SP1 è possibile abilitare per l'attività di replica continua cluster eventuali reti di cluster ridondanti configurate come reti miste. L'attività comprende il seeding, il reseeding e il log shipping del gruppo di archiviazione.
In Exchange 2007 SP1 solo le reti di cluster designate come miste possono essere abilitate per la replica continua. Una rete cluster mista è una rete cluster configurata sia per il traffico cluster (comunicazioni tra nodi) che per il traffico di accesso client. Le reti di cluster configurate per l'accesso cluster ma non per l'accesso client (talvolta definite reti private) non possono essere abilitate per la replica continua.
Il supporto per il log shipping in una rete mista viene configurato utilizzando il cmdlet Enable-ContinuousReplicationHostName. Allo stesso modo, la disattivazione di questa funzionalità viene eseguita 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 relativa all'abilitazione delle reti di cluster per l'attività di replica continua, vedere Come abilitare le reti cluster ridondanti per il log shipping e il seeding in Windows Server 2003.
Nota
Oltre al nome host, all'indirizzo IP e al gruppo cluster che viene creato nel cluster di failover, ogni volta che si esegue il cmdlet Enable-ContinuousReplicationHostName si crea anche un account nel dominio di Active Directory che contiene il server di cassette postali in cluster. Per impostazione predefinita, in Windows Server 2003 un utente che non dispone della delega dei privilegi di amministratore di dominio e al quale non sono state concesse le voci di controllo di accesso (ACE, Access Control Entry) per creare oggetti computer ed eliminare oggetti computer può aggiungere fino a 10 account computer. Per un amministratore di Exchange che esegue spesso i cmdlet Enable-ContinuousReplicationHostName e Disable-ContinuousReplicationHostName e che non dispone dei privilegi di amministratore di dominio o delle suddette voci di controllo di accesso, il limite di 10 account viene raggiunto rapidamente. Per questo problema sono disponibili due soluzioni descritte nell'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.
Il seeding e il reseeding in un ambiente di replica continua cluster viene eseguito utilizzando il cmdlet Update-StorageGroupCopy. In Exchange 2007 SP1 il cmdlet è stato esteso fino a includere un nuovo parametro denominato DataHostNames. Questo parametro viene utilizzato per specificare la rete da utilizzare per il seeding o il reseeding. Il valore è un elenco di due nomi con più valori: un nome di dominio completo (FQDN) o un nome host. Uno di tali nomi deve identificare il nodo passivo.