Condividi tramite

Replica continua di standby: resilienza di sito con cluster in standby

  • Articolo

 

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

Ultima modifica dell'argomento: 2008-11-18

In questo argomento viene descritto il modo in cui l'organizzazione Contoso, Ltd. utilizza la replica continua di standby (SCR) in uno scenario di resilienza del sito. In questo scenario, si verifica un errore nel centro dati primario e Contoso, Ltd. decide di attivare il centro dati secondario. Dopo l'attivazione del centro dati secondario, il centro dati principale viene riconfigurato e ripristinato come principale con un passaggio controllato. Contoso, Ltd. dispone di due centri dati: un centro dati principale noto come SITOA Active Directory e un altro centro dati di backup noto come SITOB Active Directory. SITOA ha sede a Portland, in Oregon e SITOB a San Jose, in California.

Il SITOA comprende i seguenti componenti dell'infrastruttura:

  • Server di directory DC1 che offre inoltre servizi DNS (Domain Name System) protetti, integrati con Active Directory

  • Server Accesso client CAS1

  • Server Trasporto Hub HUB1

  • Server cassette postali di cluster, EXCMS1, eseguito in un cluster a copia singola con due nodi (SCC), EXCLUS1, contenente il NODOA e il NODOB. Note

    • I nodi del cluster di failover vengono eseguiti nel sistema operativo Windows Server 2008 e il cluster di failover è configurato con un quorum maggioranza dei nodi e dei dischi.

    • Il valore TTL (Time to Live) DNS della risorsa Nome rete del server di cassette postali in cluster è impostato su cinque minuti. Tale valore è stato configurato eseguendo il comando riportato di seguito, quindi arrestando e riavviando il server di cassette postali in cluster.

      Cluster.exe res "Network Name (EXCMS1)" /priv HostRecordTTL=300

      Nota

      La proprietà HostRecordTTL è disponibile solo per i cluster di failover con il sistema operativo Windows Server 2008. Non è possibile utilizzare questo comando nei cluster di failover con il sistema operativo Windows Server 2003.

Il SITOB comprende i seguenti componenti dell'infrastruttura:

  • Server di directory DC2 che offre inoltre servizi DNS protetti, integrati con Active Directory

  • Server Accesso client CAS2

  • Server Trasporto Hub HUB2

  • Cluster a nodo singolo, DRCLUS1, che verrà utilizzato come cluster di failover di standby. Note

    • Il nodo di questo cluster, NODOC, è l'unico nodo del cluster di failover di standby e utilizza il sistema operativo Windows Server 2008. Il cluster di failover di standby è configurato con un quorum maggioranza dei nodi.

      Nota

      Nei cluster di failover nei quali viene eseguito Windows Server 2003, il cluster di failover di standby a nodo singolo viene configurato con un normale quorum locale.

    • Il ruolo del server Cassette postali passivo viene installato nel NODOC utilizzando lo stesso percorso di installazione di EXCLUS1. Questa operazione è necessaria per poter eseguire un ripristino del server utilizzando Setup /RecoverCMS come parte del processo di attivazione di destinazione della replica continua di standby. Per utilizzare il processo di ripristino del server, è necessario che il percorso di installazione del server Exchange sia uguale a quello dei computer di origine e di destinazione della replica continua di standby. Se il server Exchange viene installato in %ProgramFiles%\Microsoft\Exchange Server nel computer di origine della replica continua di standby (SCR), è necessario che venga installato in %ProgramFiles%\Microsoft\Exchange Server anche per tutti i computer di destinazione SCR relativi al server di origine SCR. Se i percorsi di installazione non corrispondono, il processo di ripristino del server non riesce perché il percorso di installazione del Registro di sistema non corrisponde al valore dell'attributo msExchInstallPath dell'oggetto server Cassette postali di Active Directory.

    • Se si utilizza lo snap-in Utenti e computer di Active Directory, l'account del computer per DRCLUS1 viene configurato con tutte le autorizzazioni dell'oggetto computer EXCMS1. In questo modo, l'account del computer per EXCMS1 può essere reimpostato da DRCLUS1 qualora venga attivato il SITOB a causa di problemi nel SITOA.

      Nota

      Questo passaggio viene utilizzato solo per i cluster di failover con il sistema operativo Windows Server 2008. Il motivo risiede nel fatto che il Servizio cluster viene eseguito nel contesto di protezione del sistema locale. Questo passaggio non è necessario per i cluster di failover con il sistema operativo Windows Server 2003 se per entrambi i cluster di failover viene utilizzato lo stesso account del Servizio cluster.

Tutti i server di entrambi i siti Active Directory vengono configurati in modo da utilizzare i server DNS integrati in Active Directory. L'intervallo di replica di Active Directory in entrambi i siti Active Directory è impostato su 15 minuti.

La replica continua di standby (SCR) è configurata in modo che i file di registro delle transazioni vengano replicati da tre gruppi di archiviazione su EXCMS1 alle destinazioni SCR su NODOC. Per questa configurazione sono stati utilizzati i seguenti comandi:

Enable-StorageGroupCopy EXCMS1\SG1 -StandbyMachine NODEC
Enable-StorageGroupCopy EXCMS1\SG2 -StandbyMachine NODEC
Enable-StorageGroupCopy EXCMS1\SG3 -StandbyMachine NODEC

Nota

Per consentire l'abilitazione contemporanea di tutti i gruppi di archiviazione in EXCMS1 per la replica SCR, eseguire il comando riportato di seguito: Get-StorageGroup -Server EXCMS1 | Enable-StorageGroupCopy -StandbyMachine NODEC

L'integrità e lo stato della replica SCR per ogni gruppo di archiviazione sono stati verificati utilizzando i cmdlet Test-ReplicationHealth e Get-StorageGroupCopyStatus di Exchange Management Shell. Ad esempio:

Get-StorageGroupCopyStatus EXCMS1\SG1 -StandbyMachine NODEC

Lo spostamento del server di cassette postali in cluster è stato verificato e opera secondo le modalità previste, così come le copie di backup e il troncamento dei file registro.

Guasto del sito principale e attivazione del sito di backup

Improvvisamente e senza alcun preavviso, a Portland si è verificato un terremoto di grave entità. Sebbene nessuno abbia riportato lesioni gravi, i danni al SITOA sono stati tali da determinare l'interruzione dell'erogazione dei servizi essenziali, quali energia elettrica, acqua e gas. Poiché avrebbero potuto trascorrere mesi prima che Contoso, Ltd. potesse utilizzare nuovamente il SITOA, si è deciso di procedere all'attivazione manuale del SITOB per tutti i dati di messaggistica e i servizi.

L'attivazione del SITOB ha avuto inizio con la verifica dei servizi di directory e la risoluzione DNS. Poiché nel SITOB è già presente un server di directory nel quale risiede il servizio DNS integrato con Active Directory, i servizi sono risultati integri, aggiornati e perlopiù non interessati dal mancato funzionamento del SITOA. Dopo la verifica dei servizi di directory e DNS, il passaggio successivo ha comportato l'attivazione delle destinazioni della replica SCR e il ripristino del server di cassette postali in cluster. Sono stati quindi eseguiti, nell'ordine, i passaggi riportati di seguito:

  1. Nel NODOC è stato aperto Exchange Management Shell e per preparare il montaggio delle destinazioni SCR sono stati eseguiti i comandi riportati di seguito.

    Restore-StorageGroupCopy -Identity EXCMS1\SG1 -StandbyMachine NODEC -Force
Restore-StorageGroupCopy -Identity EXCMS1\SG2 -StandbyMachine NODEC -Force
Restore-StorageGroupCopy -Identity EXCMS1\SG3 -StandbyMachine NODEC -Force

    Importante

    Quando l'origine SCR non è disponibile, è sempre necessario specificare il parametro Force.

    Nota

    In alternativa all'esecuzione di tre comandi Restore-StorageGroupCopy distinti, come illustrato nel passaggio 1, è possibile utilizzare un nuovo script incluso in Microsoft Exchange Server 2007 Service Pack 1 (SP1), denominato GetSCRSources.ps1, e creare una pipeline dell'output dello script in un'unica attività Restore-StorageGroupCopy, come indicato di seguito: GetSCRSources | Restore-StorageGroupCopy -StandbyMachine $env:ComputerName -Force

  2. Lo snap-in Gestione DNS consente di rimuovere dal servizio DNS i record esistenti per EXCMS1.

    Nota

    Questo passaggio viene utilizzato solo per i cluster di failover con il sistema operativo Windows Server 2008. Il motivo risiede nel fatto che il Servizio cluster viene eseguito nel contesto di protezione del sistema locale. Questo passaggio non è necessario per i cluster di failover con il sistema operativo Windows Server 2003 se per entrambi i cluster di failover viene utilizzato lo stesso account del Servizio cluster.

  3. La replica continua di standby è disattivata per tutti i gruppi di archiviazione in preparazione del processo di /RecoverCMS. Se la replica continua di standby non viene disattivata per tutti i gruppi di archiviazione, il processo di Setup /RecoverCMS non viene eseguito. È possibile disattivare la replica continua di standby utilizzando i seguenti comandi:

    Disable-StorageGroupCopy -Identity EXCMS1\SG1 -StandbyMachine NODEC -Confirm:$False
Disable-StorageGroupCopy -Identity EXCMS1\SG2 -StandbyMachine NODEC -Confirm:$False
Disable-StorageGroupCopy -Identity EXCMS1\SG3 -StandbyMachine NODEC -Confirm:$False

  4. Il server di cassette postali in cluster (EXCMS1) viene ripristinato mediante l'opzione /RecoverCMS dell'installazione. Il ripristino ha luogo in NODOC mediante il seguente comando:

    Setup.com /RecoverCMS /CMSName:EXCMS1 /CMSIPAddress:<IPAddress>

    Notare quanto segue:

    • Il valore di CMSIPAddress, nel comando precedente, dovrebbe rappresentare un indirizzo IP diverso da quello originale di EXCMS1. Questo è dovuto al fatto che il ripristino di EXCMS1 è esterno al sito. Vale a dire che, pur risiedendo in origine nel SITOA, il server viene ripristinato nel SITOB.

    • Setup /RecoverCMS viene completato correttamente dopo la replica DNS e lo svuotamento della cache DNS (NODOC) del server di ripristino. Se l'installazione non riesce, è necessario utilizzare NSLookup dal controller di dominio primario (PDC) e da NODOC per assicurarsi che l'indirizzo IP corretto venga risolto in NODOC e, dopo la verifica, eseguire nuovamente l'installazione.

    • Nei cluster di failover nei quali viene eseguito Windows Server 2003, l'oggetto computer di EXCMS1 viene reimpostato durante il processo Setup /RecoverCMS. Perché l'installazione si concluda correttamente è necessaria una replica di questa reimpostazione nel sito Active Directory locale. Se il controller di dominio primario (PDC) non si trova nel sito Active Directory locale, verificare il funzionamento dei collegamenti al sito Active Directory tra il PDC e il sito Active Directory locale.

    • Al termine del processo di ripristino dell'installazione, EXCMS1 è stato ripristinato nel SITOB e ora risiede in NODOC, in un cluster a copia singola (Single Copy Cluster, SCC) denominato DRCLUS1.

    • In conseguenza dell'operazione di ripristino del server di cassette postali in cluster, il TTL DNS di EXCMS1 è stato riportato al valore predefinito di 20 minuti. È necessario eseguire il comando riportato di seguito, quindi arrestare e riavviare il server di cassette postali in cluster per riportare il valore a cinque minuti.

      Cluster.exe res EXCMS1 /priv HostRecordTTL=300

  5. Successivamente, i database dei tre gruppi di archiviazione vengono montati utilizzando l'attività Mount-Database.

  6. In questo scenario non è necessario eseguire altre operazioni di ripristino dei ruoli del server, in particolare Accesso client e Trasporto Hub, perché nel SITOB già esistono CAS2 e HUB2.

    Nota

    Nell'ambito dell'operazione di ripristino del server Accesso client, è necessario riconfigurare gli URL esterni in modo che puntino ai server Accesso client di SITOB.

    Nota

    Questo scenario esemplificativo non include il ripristino dei server Trasporto Edge. Se nel SITOA esistevano server Trasporto Edge persi a causa dei problemi del sito, è necessario riportare in linea nel SITOB i server Trasporto Edge e i record Mail Exchanger (MX) DNS perché sarà necessario aggiornare i domini SMPT di Contoso in modo che puntino ai nuovi server Trasporto Edge.

  7. Se nell'organizzazione Contoso sono presenti altri siti Active Directory, i messaggi verranno accodati nel sito Active Directory principale. Successivamente alla replica delle informazioni sull'appartenenza al sito di EXCMS1 in tutti gli altri siti Active Directory, sarà possibile eseguire nuovi tentativi manuali relativi alle code SMTP contenenti i messaggi destinati al sito principale. In assenza di tentativi manuali, il modulo di trasporto tenterà automaticamente di elaborare la coda dopo 12 ore. In questo modo i messaggi verranno nuovamente categorizzati. Successivamente alla ricategorizzazione, i messaggi vengono recapitati a EXCMS1 in SITOB.

Poiché i server DNS utilizzati dai client e gli altri server hanno il corretto indirizzo IP per EXCMS1, tutti i client sono in grado di accedere alle proprie cassette postali utilizzando i metodi di accesso originali, ad esempio Microsoft Outlook Web Access, Exchange ActiveSync e Microsoft Office Outlook.

Riconfigurazione del sito principale

Poiché il sito secondario, ossia SITOB, ora svolge la funzione di centro dati principale, è necessario riconfigurare il centro dati principale originario, ossia SITOA, in modo che i servizi che ora risiedono nel SITOB non entrino in conflitto con quelli ripristinati dopo la riattivazione del SITOA. Il SITOA dovrebbe essere riportato in linea con modalità controllate dall'amministratore in base alla procedura seguente:

  1. Riportare innanzitutto in linea i servizi di directory e di risoluzione del nome DNS riportando in linea DC1.

  2. Quando DC1 è in linea, riportare in linea CAS1 e HUB1.

    Si noti che dopo aver riportato in linea HUB1, è necessario che un amministratore verifichi che i messaggi della relativa coda siano stati recapitati. Se i messaggi sono bloccati nelle code, possono essere reinoltrati mediante il seguente comando.

    Retry-queue [queue name] -Resubmit $True

  3. Riportare in linea i nodi nei quali risiede il cluster EXCLUS1. Per gli obiettivi di questo scenario, per prima cosa viene riportato in linea il NODOA e, quindi, il NODOB.

  4. Quando entrambi i nodi sono stati riportati in linea, il server di cassette postali in cluster rimane non in linea. Questo include tutte le risorse del server di cassette postali in cluster, con particolare riferimento alla risorsa Nome rete. Non è possibile riportare in linea questa risorsa perché EXCMS1 è già in linea e utilizza lo stesso nome di rete. Riportando in linea EXCMS1 nel NODOA o nel NODOB ne conseguirebbe un conflitto di nomi nella rete.

  5. Nel nodo che attualmente detiene il gruppo di risorse contenente il server di cassette postali in cluster, è necessario che un amministratore cancelli il server e le relative risorse dal cluster di failover. A tale scopo l'amministratore rimuove dapprima tutte le risorse non appartenenti a Exchange dal gruppo di cluster contenente il server di cassette postali in cluster. L'amministratore esegue quindi il comando riportato di seguito nel NODOA:

    Setup.com /ClearLocalCMS /CMSName:EXCMS1

    Note

    • Dopo aver deselezionato il server di cassette postali in cluster e le relative risorse in EXCLUS1, è consigliabile utilizzare lo snap-in Amministrazione cluster o Gestione cluster di failover per verificare l'avvenuta rimozione di tutte le risorse del server di cassette postali in cluster.

    • Ora EXCLUS1 è un cluster di failover con due nodi passivi, il NODOA e il NODOB, in ciascuno dei quali è installato un ruolo server Cassette postali passivo. A questo punto, in EXCLUS1 non esiste alcun server di cassette postali in cluster.

  6. Poiché nei nodi del cluster viene eseguito Windows Server 2008, dopo aver eseguito Setup /ClearLocalCMS l'oggetto computer virtuale (VCO, Virtual Computer Object) verrà disattivato. Per attivare nuovamente l'oggetto computer virtuale, fare clic su Start, scegliere Tutti i programmi, quindi Strumenti di amministrazione e infine Utenti e computer di Active Directory. Espandere il dominio, espandere Computer, fare clic con il pulsante destro del mouse su EXCMS1 VCO, quindi scegliere Abilita account.

  7. Per preparare il passaggio controllato dal SITOB al SITOA, il NODOA viene adibito a destinazione SCR dei gruppi di archiviazione residenti in EXCMS1 nel SITOB. A questo scopo, è necessario utilizzare i seguenti comandi in NODOC:

    Enable-StorageGroupCopy EXCMS1\SG1 -StandbyMachine NODEA
Enable-StorageGroupCopy EXCMS1\SG2 -StandbyMachine NODEA
Enable-StorageGroupCopy EXCMS1\SG3 -StandbyMachine NODEA

    Nota

    Se l'archiviazione utilizzata dal cluster di failover originale non è interessata dai problemi del SITOA e se nel NODOA esistono ancora i database originali e i relativi registri delle transazioni dei gruppi di archiviazione della struttura, è possibile utilizzarli per la replica continua senza dover eseguire nuovamente il seeding completo di ogni gruppo di archiviazione del NODOA. Se i file esistenti sono inutilizzabili oppure se nel server di cassette postali in cluster originale è stata configurata la registrazione circolare, è necessario eseguire nuovamente un seeding completo per ogni gruppo di archiviazione mediante il cmdlet Update-StorageGroupCopy.

In questo scenario, a scopo esemplificativo, viene utilizzato una replica continua di standby. Se invece nello scenario di ripristino viene utilizzato un server di cassette postali in cluster in ambiente di replica continua cluster (CCR), è consigliabile eseguire un passaggio aggiuntivo nel quale anche il nodo passivo viene preparato per il passaggio controllato mediante la gestione temporanea dei database e dei file di registro. Questo passaggio avviene solo a scopo di ottimizzazione, per eliminare l'esigenza di seeding dei gruppi di archiviazione passivi dopo aver riportato l'ambiente CCR nel SITOA. È possibile eseguire questa attività con uno dei metodi seguenti:

  • Sospendere la replica continua delle tre destinazioni SCR e copiare i file del gruppo di archiviazione e i database dal NODOA nei percorsi appropriati del NODOB.

  • Abilitare il NODOB come destinazione SCR di EXCMS1.

Passaggio controllato al sito principale originario

Dopo l'approvazione dell'utilizzo del SITOA, è possibile eseguire un passaggio manuale e controllato dei dati e dei servizi da SITOB a SITOA. I passaggi necessari sono effettivamente inversi a quelli compiuti per attivare SITOB:

  1. Il primo passaggio consiste nello smontare tutti i database di EXCMS1. Lo scopo è quello di interrompere la generazione dei file di registro delle transazioni e di predisporre l'attivazione delle destinazioni SCR in NODOA. È possibile smontare i database utilizzando Exchange Management Console oppure il cmdlet Dismount-Database di Exchange Management Shell.

  2. In NODOA, l'amministratore prepara tutti i gruppi di archiviazione per il montaggio. Per questa attività eseguire i comandi riportati di seguito:

    Restore-StorageGroupCopy -Identity EXCMS1\SG1 -StandbyMachine NODEA
Restore-StorageGroupCopy -Identity EXCMS1\SG2 -StandbyMachine NODEA
Restore-StorageGroupCopy -Identity EXCMS1\SG3 -StandbyMachine NODEA

    Note

    • Nei tre comandi precedenti, il parametro Force non viene utilizzato perché il server SCR di origine è disponibile. Non utilizzando il parametro Force, l'attività tenta automaticamente di copiare tutti i file di registro dall'origine SCR.

    • Al termine di ogni attività, è necessario che l'amministratore verifichi che tutti i file di registro di ogni gruppo di archiviazione siano stati copiati nel NODOA e che la replica SCR sia stata disabilitata.

    • Se anche il NODOB è stato configurato come destinazione SCR, prima di proseguire è necessario disabilitarlo e ripristinarlo. In questo scenario, è consigliabile eseguire Restore-StorageGroupCopy innanzitutto in NODOB, quindi in NODOA e, successivamente, eseguire Setup /RecoverCMS in NODOA.

  3. È necessario arrestare il server di cassette postali in cluster EXCMS1 in DRCLUS1. Questa attività viene eseguita dal NODOC mediante la procedura guidata Gestisci server di cassette postali in cluster in Exchange Management Console oppure mediante il cmdlet Stop-ClusteredMailboxServer di Exchange Management Shell.

  4. Rimuovere il record A per EXCMS1 da DNS utilizzando lo snap-in di gestione DNS.

    Nota

    È necessario rimuovere il record A per EXCMS1 solo se il cluster di failover viene eseguito in Windows Server 2008. Se il cluster di failover viene eseguito in Windows Server 2003, non è necessario eseguire questo passaggio.

  5. Il server di cassette postali in cluster (EXCMS1) viene ripristinato mediante l'opzione /RecoverCMS dell'installazione. Il ripristino ha luogo in NODOA mediante il seguente comando:

    Setup.com /RecoverCMS /CMSName:EXCMS1 /CMSIPAddress:<IPAddress>

    Note

    • Il valore di CMSIPAddress, nel comando precedente, dovrebbe rappresentare l'indirizzo IP originale di EXCMS1. Questo è dovuto al fatto che EXCLUS1 viene ripristinato nel percorso originale.

    • Al termine del processo di ripristino dell'installazione, EXCMS1 è stato ripristinato nel SITOA e ora risiede in NODOA in un cluster SCC a due nodi denominato EXCLUS1.

    Nota

    In questo scenario, a scopo esemplificativo, viene utilizzato ancora un cluster SCC. Se nello scenario di ripristino viene invece utilizzato un server Cassette postali cluster in ambiente CCR, può essere necessario eseguire ulteriori passaggi. L'operazione /RecoverCMS sospende la replica continua, in questo caso, dal NODOA al NODOB. È necessario che l'amministratore esegua Resume-StorageGroupCopy per i gruppi di archiviazione al fine di ristabilire le attività di replica e di riesecuzione. Successivamente, è necessario che l'amministratore verifichi la ripresa dell'attività di replica. Se la gestione temporanea del NODOB descritta in precedenza non riuscisse, sarà necessario rieseguire il seeding delle copie passive dei gruppi di archiviazione.

    • In conseguenza dell'operazione di ripristino del server di cassette postali in cluster, il TTL DNS di EXCMS1 è stato riportato al valore predefinito di 20 minuti. È necessario eseguire il comando riportato di seguito, quindi arrestare e riavviare il server di cassette postali in cluster per riportare il valore a cinque minuti.

      Cluster.exe res "Network Name (EXCMS1)" /priv HostRecordTTL=300

  6. I database dei tre gruppi di archiviazione vengono montati utilizzando il cmdlet Mount-Database.

  7. In questo scenario, non è necessario eseguire altre operazioni di ripristino dei ruoli server, in particolare Accesso client e Trasporto Hub, perché nel SITOA già esistono CAS1 e HUB1.

    Nota

    Nell'operazione di ripristino del server Accesso client, è necessario riconfigurare gli URL esterni in modo che puntino ai server Accesso client di SITOA.

    Nota

    Questo scenario esemplificativo non include il ripristino dei server Trasporto Edge. Se i server Trasporto Edge sono in uso, sarà necessario aggiornare i record DNS Mail Exchanger (MX) dei domini SMTP di Contoso in modo che puntino ai server Trasporto Edge corretti.

  8. Se nell'organizzazione Contoso sono presenti altri siti Active Directory, i messaggi verranno accodati nel sito Active Directory principale. Successivamente alla replica delle informazioni sull'appartenenza al sito di EXCMS1 in tutti gli altri siti Active Directory, sarà possibile eseguire nuovi tentativi manuali relativi alle code SMTP contenenti i messaggi destinati al sito principale. In assenza di tentativi manuali, il modulo di trasporto tenterà automaticamente di elaborare la coda dopo 12 ore. In questo modo i messaggi verranno nuovamente categorizzati. Successivamente alla ricategorizzazione, i messaggi vengono recapitati a EXCMS1 in SITOA.

  9. Poiché i server DNS utilizzati dai client e gli altri server hanno il corretto indirizzo IP per EXCMS1, tutti i client sono in grado di accedere alle proprie cassette postali utilizzando i metodi di accesso originali, ad esempio Outlook Web Access, Exchange ActiveSync e Outlook. Inoltre, al termine delle repliche delle modifiche DNS nel SITOB e al termine della replica dell'appartenenza al sito di EXCMS1, i server Trasporto Hub instraderanno i messaggi al sito Active Directory corretto. Gli amministratori possono anche imporre manualmente il reinoltro dei messaggi presenti in una delle code di HUB1 o di HUB2. Per questa attività eseguire il comando riportato di seguito:

    Retry-queue [queue name] -Resubmit $True

Riconfigurazione del sito di backup

Al termine del passaggio manuale controllato da SITOB a SITOA, è possibile riportare SITOB al suo stato operativo di centro dati di backup. Per questo è necessario disabilitare il server di cassette postali in cluster di standby dal cluster di failover di SITOB e abilitare nuovamente il NODOC come destinazione SCR per i tre gruppi di archiviazione di EXCMS1. Sono stati quindi eseguiti, nell'ordine, i passaggi riportati di seguito:

  1. Durante il passaggio controllato, il server Cassette postali cluster in esecuzione in DRCLUS1 di SITOB è stato arrestato in modo da poter essere riportato in EXCLUS1 di SITOA. Dopo aver riportato in funzione EXCMS1 in EXCLUS1, è necessario rimuoverne le informazioni di configurazione da DRCLUS1. È possibile disabilitare le informazioni di configurazione e rimuovere completamente EXCMS1 da DRCLUS1, rimuovendo tutte le risorse non appartenenti a Exchange dal gruppo di cluster contenente il server di cassette postali in cluster ed eseguendo quindi il comando riportato di seguito:

    Setup.com /ClearLocalCMS /CMSName:EXCMS1

  2. Poiché nel nodo del cluster viene eseguito Windows Server 2008, dopo aver eseguito Setup /ClearLocalCMS l'oggetto computer virtuale verrà disattivato. Per attivare nuovamente l'oggetto computer virtuale, fare clic su Start, scegliere Tutti i programmi, quindi Strumenti di amministrazione e infine Utenti e computer di Active Directory. Espandere il dominio, espandere Computer, fare clic con il pulsante destro del mouse su EXCMS1 VCO, quindi scegliere Abilita account.

  3. Dopo aver deselezionato il server di cassette postali in cluster e le relative risorse in DRCLUS1, l'amministratore può utilizzare lo snap-in Amministrazione cluster o Gestione cluster di failover per verificare l'avvenuta rimozione di tutte le risorse del server di cassette postali in cluster.

  4. La replica continua di standby (SCR) è configurata in modo che i file di registro delle transazioni vengano replicati da tre gruppi di archiviazione su EXCMS1 alle destinazioni SCR su NODOC. Per questa configurazione sono stati utilizzati i seguenti comandi:

    Enable-StorageGroupCopy EXCMS1\SG1 -StandbyMachine NODEC
Enable-StorageGroupCopy EXCMS1\SG2 -StandbyMachine NODEC
Enable-StorageGroupCopy EXCMS1\SG3 -StandbyMachine NODEC

    Nota

    Prima di attivare la replica continua di standby per replicare i gruppi di archiviazione da EXCMS1 a NODEC, è necessario assicurarsi che non siano presenti conflitti tra i gruppi di archiviazione o i percorsi di database. È inoltre necessario assicurarsi che eventuali gruppi di archiviazione e file di database obsoleti e non necessari siano stati rimossi dai percorsi originali.

  5. L'integrità e lo stato della replica SCR per ogni gruppo di archiviazione sono stati verificati utilizzando i cmdlet Test-ReplicationHealth e Get-StorageGroupCopyStatus. È necessario verificare inoltre l'esito dello spostamento del server di cassette postali in cluster tra nodi, così come delle copie di backup e delle operazioni di troncamento dei file registro. Al termine di tutte le verifiche, ai fini del sistema di messaggistica Exchange 2007 il centro dati principale e quello secondario sono tornati nella modalità operativa originale.