Switchover del datacenter

In una configurazione con resilienza del sito, può verificarsi all'interno di un DAG il ripristino automatico in risposta a un errore a livello di sito, consentendo al sistema di messaggistica di rimanere in uno stato funzionale. Questa configurazione richiede almeno tre posizioni, poiché richiede la distribuzione dei membri DAG in due posizioni e quella del server di controllo del DAG in una terza posizione.

Se non si dispone di tre posizioni o anche se si hanno tre posizioni, ma si vuole controllare le azioni di ripristino a livello di data center, è possibile configurare un dag per il ripristino manuale in caso di errore a livello di sito. In tal caso, la procedura da eseguire viene denominata switchover del datacenter. Come per molti scenari di ripristino di emergenza, la pianificazione e preparazione anticipata di uno switchover del datacenter può semplificare il processo e ridurre la durata dell'interruzione.

There are four basic steps that you complete to perform a datacenter switchover, after making the initial decision to activate the second datacenter:

1. Terminare un data center parzialmente in esecuzione: questo passaggio comporta la chiusura dei servizi exchange nel data center primario, se sono ancora in esecuzione servizi. This is particularly important for the Mailbox server role because it uses an active/passive high availability model. If services in a partially failed datacenter aren't stopped, it's possible for problems from the partially failed datacenter to negatively affect the services during a switchover back to the primary datacenter.

   Importante

   If network or Active Directory infrastructure reliability has been compromised as a result of the primary datacenter failure, we recommend that all messaging services be off until these dependencies are restored to healthy service.

2. Convalidare e confermare i prerequisiti per il secondo data center: questo passaggio può essere eseguito in parallelo con il passaggio 1 perché la convalida dell'integrità dell'infrastruttura nel secondo data center è in gran parte indipendente dal primo data center. Each organization typically requires its own method for performing this step. For example, you may decide to complete this step by reviewing health information collected and filtered by an infrastructure monitoring application, or by using a tool that's unique to your organization's infrastructure. Si tratta di un passaggio critico, perché non si vuole attivare il secondo data center quando l'infrastruttura non è integra e instabile.

3. Attivare i server Cassette postali: questo passaggio inizia il processo di attivazione del secondo data center. Questo passaggio può essere eseguito in parallelo con il passaggio 4 perché i servizi di Microsoft Exchange possono gestire le interruzioni e il ripristino del database. L'attivazione dei server Cassette postali comporta un processo di contrassegno dei server non riusciti dal data center primario come non disponibili, seguito dall'attivazione dei server nel secondo data center. Il processo di attivazione per i server Cassette postali dipende dal fatto che il dag sia in modalità di coordinamento dell'attivazione del database. Per altre informazioni, vedere Modalità di coordinamento attivazione del data center .

   If the DAG is in DAC mode, you can use the Exchange site resilience cmdlets to terminate a partially failed datacenter (if necessary) and activate the Mailbox servers. For example, in DAC mode, this step is performed by using the Stop-DatabaseAvailabilityGroup cmdlet. In some cases, the servers must be marked as unavailable twice (once in each datacenter). Next, the Restore-DatabaseAvailabilityGroup cmdlet is run to restore the remaining members of the database availability group (DAG) in the second datacenter by reducing the DAG members to those that are still operational, thereby reestablishing quorum. If the DAG isn't in DAC mode, you must use the Windows Failover Cluster tools to activate the Mailbox servers. After either process is complete, the database copies that were previously passive in the second datacenter can become active and be mounted. At this point, Mailbox server recovery is complete.

4. Attivare i servizi accesso client: ciò comporta l'uso delle informazioni di mapping degli URL e della metodologia di modifica DNS (Domain Name System) per eseguire tutti gli aggiornamenti DNS necessari. The mapping information describes what DNS changes to perform. The amount of time required to complete the update depends on the methodology used and the Time to Live (TTL) settings on the DNS record (and whether the deployment's infrastructure honors the TTL).

Users should start to have access to messaging services sometime after steps 3 and 4 are completed. Steps 3 and 4 are described in greater detail later in this topic.

Terminating a Partially Failed Datacenter

Quando il gruppo di disponibilità del database è in modalità di coordinazione dell'attivazione del database, per terminare i membri del gruppo di disponibilità del database ancora attivi nel centro dati principale, eseguire le operazioni specifiche riportate di seguito:

Quando il dag di Exchange è in modalità applicazione livello dati, è possibile disabilitare i server in un data center non riuscito con un singolo comando. In questo modo è possibile montare i database in un altro data center anche se il gruppo di disponibilità del database non dispone del quorum (più della metà dei membri del dag disponibile).

When the DAG is in DAC mode, the specific actions to terminate any surviving DAG members in the primary datacenter are as follows:

1. The DAG members in the primary datacenter must be marked as stopped in the primary datacenter. Arrestato è uno stato di Active Manager che impedisce il montaggio dei database e Active Manager in ogni server del data center non riuscito viene inserito in questo stato usando il cmdlet Stop-DatabaseAvailabilityGroup . Il parametro ActiveDirectorySite di questo cmdlet può essere usato per contrassegnare tutti i server nel data center primario come arrestati con un singolo comando. This step may not be possible depending on the failure. This step should be taken if the state of the datacenter permits it. The Stop-DatabaseAvailabilityGroup cmdlet should be run against all servers in the primary datacenter. Se il server Cassette postali non è disponibile ma Active Directory opera nel data center primario, il comando Stop-DatabaseAvailabilityGroup con il parametro ConfigurationOnly deve essere eseguito su tutti i server in questo stato nel data center primario oppure il server Cassette postali deve essere disattivato. Failure to either turn off the Mailbox servers in the failed datacenter or to successfully perform the Stop-DatabaseAvailabilityGroup command against the servers will create the potential for split-brain syndrome to occur across the two datacenters. You may need to individually turn off computers through power management devices to satisfy this requirement.

2. The second datacenter must now be updated to represent which primary datacenter servers are stopped. A tale scopo, eseguire lo stesso comando Stop-DatabaseAvailabilityGroup con il parametro ConfigurationOnly usando lo stesso parametro ActiveDirectorySite e specificare il nome del sito di Active Directory nel data center primario non riuscito. The purpose of this step is to inform the servers in the second datacenter about which mailbox servers are available to use when restoring service.

I membri del gruppo di disponibilità del database nel centro dati devono essere rimossi forzatamente dal cluster sottostante del gruppo di disponibilità del database eseguendo i comandi seguenti su ogni membro:

1. I membri del gruppo di disponibilità del database nel secondo centro dati devono essere riavviati e utilizzati per completare il processo di rimozione dal secondo centro dati. Arrestare il servizio Cluster su ogni membro del gruppo di disponibilità del database nel secondo centro dati eseguendo il comando seguente su ogni membro:

   net stop clussvc
   

   cluster <DAGName> node <DAGMemberName> /forcecleanup
   

2. I membri del gruppo di disponibilità del database nel secondo data center devono ora essere riavviati e quindi usati per completare il processo di rimozione dal secondo data center. Arrestare il servizio cluster in ogni membro del gruppo di disponibilità del database nel secondo data center eseguendo il comando seguente in ogni membro:

   net stop clussvc
   

3. On a DAG member in the second datacenter, force a quorum start of the Cluster service by running the following command:

   net start clussvc /forcequorum
   

4. Open the Failover Cluster Management tool and connect to the DAG's underlying cluster. Expand the cluster, and then expand Nodes. Right-click each node in the primary datacenter, select More Actions, and then select Evict. When you're done evicting the DAG members in the primary datacenter, close the Failover Cluster Management tool.

Se nel data center non riuscito sono in uso servizi di messaggistica unificata, questi devono essere disabilitati per impedire il routing delle chiamate al data center non riuscito. È possibile disabilitare i servizi di messaggistica unificata usando il cmdlet Disable-UMService , Disable-UMService EX1ad esempio . In alternativa, se si usa un gateway VoIP (Voice over IP), è anche possibile rimuovere le voci del server dal gateway VoIP o modificare i record DNS per i server non riusciti in modo che puntino all'indirizzo IP dei server nel secondo data center se il gateway VoIP è configurato per instradare le chiamate tramite DNS.

Attivazione dei server Cassette postali

I passaggi richiesti per attivare i server Cassette postali durante lo switchover di un centro dati dipende anche dal fatto che il gruppo di disponibilità del database sia in modalità di coordinazione dell'attivazione del database. Prima di attivare i membri del gruppo di disponibilità del database nel secondo centro dati, è opportuno assicurarsi che i servizi di infrastruttura nel secondo centro dati siano pronti per l'attivazione del servizio di messaggistica.

Di seguito, è riportata la procedura per il completamento dell'attivazione dei server Cassette postali nel secondo centro dati, quando il gruppo di disponibilità del database è in modalità di coordinazione dell'attivazione del database:

1. È necessario arrestare il servizio Cluster su ciascun membro del gruppo di disponibilità del database nel secondo centro dati. È possibile usare il cmdlet Stop-Service per arrestare il servizio , ad esempio , Stop-Service ClusSvcoppure usare net stop clussvc da un prompt dei comandi con privilegi elevati.

2. I server Cassette postali nel datacenter di standby vengono quindi attivati utilizzando il cmdlet Restore-DatabaseAvailabilityGroup. Il sito Active Directory del centro dati di standby viene trasmesso al cmdlet Restore-DatabaseAvailabilityGroup per l'identificazione dei server da utilizzare per il ripristino del servizio e per configurare il DAG per l'utilizzo di un server di controllo alternativo. Se il server di controllo alternativo non è stato configurato in precedenza, è possibile configurarlo usando i parametri AlternateWitnessServer e AlternateWitnessDirectory del cmdlet Restore-DatabaseAvailabilityGroup . Se si utilizza tale comando, i criteri del quorum vengono compressi nei server del centro dati di standby. Se il numero di server in quel centro dati è un numero pari, verrà attivato il gruppo di disponibilità del database mediante l'uso del server di controllo alternativo come identificato dall'impostazione dell'oggetto gruppo di disponibilità del database.

3. È ora possibile attivare il database. A seconda della configurazione specifica utilizzata dall'organizzazione, tale operazione potrebbe non avvenire automaticamente. Se i server nel centro dati di standby dispongono di un'impostazione di attivazione bloccata, il sistema non eseguirà un failover automatico dal centro dati principale a quello di standby di qualsiasi database. Se non vi sono restrizioni di failover per le copie del database nel centro dati di standby, il sistema attiverà le copie nel secondo centro dati presumendone l'integrità. Se i database sono configurati con un'impostazione di attivazione bloccata che richiede un'azione manuale esplicita, è possibile scegliere fra due opzioni:

4. Eliminare l'impostazione che blocca l'attivazione. In questo modo, verrà ripristinato il comportamento predefinito del sistema, ossia quello di attivare tutte le copie disponibili.

5. Lasciare invariata l'impostazione e utilizzare il cmdlet Move-ActiveMailboxDatabase per completare l'attivazione del database nel secondo centro dati. Per completare tale passo utilizzando il cmdlet Move-ActiveMailboxDatabase quando è impostato il blocco dell'attivazione, è necessario identificare in modo esplicito la destinazione dello spostamento.

6. L'ultimo passo è di esaminare tutti gli errori e i messaggi di avviso derivanti dalle attività. Tutti gli avvisi indicati devono essere esaminati e corretti. Il modello di progettazione dell'attività per questi comandi prevede una mancata riuscita solo se le attività non riescono a raggiungere lo scopo principale della propria progettazione. Ad esempio, il cmdlet Restore-DatabaseAvailabilityGroup avrà esito negativo se non può comprimere il quorum del gruppo di disponibilità del database per consentire il riavvio di un server nel secondo centro dati per l'elaborazione senza che venga interrotto il quorum. Tuttavia, l'output di ciascuna attività viene utilizzato anche per identificare i problemi che richiedono un completamento da parte dell'amministratore. Si consiglia di salvare l'output di tutte le attività e di riesaminarlo per le azioni successive.

Di seguito, è riportata la procedura per il completamento dell'attivazione dei server Cassette postali nel secondo centro dati, quando il gruppo di disponibilità del database non è in modalità di coordinazione dell'attivazione del database:

1. Il quorum deve essere modificato in base al numero di membri del gruppo di disponibilità del database presenti nel secondo centro dati.

2. Se è presente un numero dispari di membri del gruppo di disponibilità del database, modificare il modello di quorum del gruppo di disponibilità del database da maggioranza dei nodi e delle condivisioni file a maggioranza dei nodi eseguendo il comando seguente:

   cluster <DAGName> /quorum /nodemajority
   

3. Se è presente un numero pari di membri del gruppo di disponibilità del database, riconfigurare il server e la directory di controllo eseguendo il comando seguente in Exchange Management Shell:

   Set-DatabaseAvailabilityGroup <DAGName> -WitnessServer <ServerName>
   

4. Avviare il servizio Cluster su ogni membro del gruppo di disponibilità del database rimanente nel secondo centro dati eseguendo il comando seguente:

   net start clussvc
   

5. Eseguire switchover del server per attivare i database delle cassette postali nel gruppo di disponibilità del database eseguendo il comando seguente per ogni membro del gruppo di disponibilità del database:

   Move-ActiveMailboxDatabase -Server <DAGMemberinPrimarySite> -ActivateOnServer <DAGMemberinSecondSite>
   

6. Montare i database delle cassette postali in ogni membro del gruppo di disponibilità del database eseguendo il comando seguente:

   Get-MailboxDatabase <DAGMemberinSecondSite> | Mount-Database
   

Attivazione dei servizi accesso client

I client si connettono agli endpoint del servizio (ad esempio Outlook sul web, individuazione automatica, Exchange ActiveSync, Outlook Via Internet, POP3, IMAP4 e l'array di servizi accesso client RPC) per accedere ai servizi e ai dati di Exchange. L'attivazione dei servizi accesso client comporta pertanto la modifica del mapping dei record DNS per questi endpoint di servizio da indirizzi IP nel data center primario agli indirizzi IP del secondo data center configurati come nuovi endpoint di servizio. In base alla configurazione del DNS, i record DNS che è necessario modificare possono trovarsi o meno nella stessa zona DNS.

Attivazione dei servizi accesso client

I client si connetteranno automaticamente ai nuovi endpoint del servizio in uno dei due modi riportati di seguito:

• I client continueranno a tentare la connessione e dovrebbero connettersi automaticamente una volta scaduto il valore TTL per la voce DNS originale e una volta che la voce risulta scaduta dalla cache DNS del client. Gli utenti possono anche eseguire il ipconfig /flushdns comando da un prompt dei comandi per cancellare manualmente la cache DNS.

• I client che avviano o riavviano eseguono una ricerca DNS all'avvio e riceveranno il nuovo indirizzo IP per l'endpoint del servizio, che sarà un server Exchange che esegue i servizi accesso client o una matrice di servizi accesso client, nel secondo data center.

Supponendo che tutte le modifiche di configurazione appropriate siano state completate per definire e configurare i servizi nel secondo data center in modo che funzionino come nel data center primario e presupponendo che la configurazione DNS stabilita sia corretta, non devono essere necessarie altre modifiche per attivare i servizi accesso client.

Attivazione dei servizi di trasporto

Generalmente, i client e gli altri server che inoltrano messaggi identificano tali server mediante l'uso di DNS. L'attivazione dei servizi Trasporto nel secondo datacenter implica la modifica dei record DNS affinché puntino all'indirizzo IP dei server Cassette postali nel secondo datacenter. A questo punto, i client e i server mittente si connetteranno automaticamente ai server nel secondo datacenter in uno dei seguenti modi:

• I client continueranno a tentare la connessione e dovrebbero connettersi automaticamente una volta scaduto il valore TTL per la voce DNS originale e una volta che la voce risulta scaduta dalla cache DNS del client. Gli utenti possono anche eseguire il ipconfig /flushdns comando da un prompt dei comandi per cancellare manualmente la cache DNS.

• L'avvio o riavvio dei client comporterà una ricerca DNS all'avvio e consentirà di ottenere il nuovo indirizzo IP per l'endpoint SMTP che sarà un server Cassette postali nel secondo datacenter.

Presumendo che siano state completate tutte le modifiche appropriate apportate alla configurazione per definire e configurare i servizi del secondo centro dati affinché questi ultimi funzionino nello stesso modo che se si trovassero nel centro dati principale e presumendo che la configurazione DNS stabilita sia corretta, non dovrebbe essere necessario apportare ulteriori modifiche per attivare i server Trasporto.

Attivazione dei servizi di messaggistica unificata in Exchange 2016

I servizi di messaggistica unificata in Exchange 2016 si connettono al sistema PBX di un'organizzazione e alle linee telefoniche. La connessione logica tra il sistema PBX e il servizio Messaggistica unificata viene fornita da un gateway IP. I gateway IP includono una funzionalità ad elevata disponibilità e sono in grado di passare da un servizio Messaggistica unificata a un altro quando viene rilevato un errore.

Se nel secondo data center sono presenti servizi di messaggistica unificata che si trovano in uno stato disabilitato perché sono dedicati alla soluzione di resilienza del sito, possono essere abilitati usando il cmdlet Enable-UMService (ad esempio, Enable-UMService EX4).

Pertanto, presumendo che i gateway IP siano associati ai servizi Messaggistica unificata mediante l'uso dei server DNS, l'attivazione dei servizi Messaggistica unificata implica la modifica ai record DNS affinché questi puntino ai nuovi indirizzi IP che verranno configurati per il servizio Messaggistica unificata nel secondo centro dati. Presupponendo che siano state completate tutte le modifiche di configurazione appropriate necessarie per definire e configurare i servizi nel secondo datacenter, affinché funzionino come se si trovassero nel datacenter principale, e presupponendo che la configurazione DNS stabilita sia corretta, non dovrebbe essere necessario apportare ulteriori modifiche per attivare i servizi Messaggistica unificata.

Se il gateway IP utilizzato non supporta l'uso di nomi DNS per risolvere i servizi Messaggistica unificata, saranno necessari ulteriori passi di configurazione per direzionare manualmente il gateway IP verso gli indirizzi IP dei servizi Messaggistica unificata nel secondo datacenter.

Attivazione dei server Trasporto Edge

I passi per l'attivazione del ruolo del server Trasporto Edge varieranno a seconda della configurazione specificata. I server Trasporto Edge in due centro dati possono essere configurati in una configurazione attiva/passiva o attiva/attiva. In una configurazione attiva/passiva, il server Trasporto Edge nel secondo centro dati risulta inattivo fino a quando non viene attivato il secondo centro dati. In una configurazione attiva/attiva, i server Trasporto Edge in entrambi i centro dati recapitano posta ininterrottamente.

In una configurazione attiva/attiva, non è richiesto alcun passo per l'attivazione dei server Trasporto Edge nel secondo centro dati, in quanto già in esecuzione. In una configurazione attiva/passiva, è necessario aggiornare il record di risorse DNS MX per ciascun dominio SMTP come parte dello switchover dal centro dati principale a quello di standby. Sebbene la configurazione attiva/attiva fornisca una soluzione semplice per lo switchover del centro dati, ha lo svantaggio che necessita di un monitoraggio accurato del carico per accertarsi che una volta eseguito lo switchover del centro dati i server Trasporto Edge nel secondo centro dati siano in grado di fornire capacità sufficiente per supportare il carico incrementato che scorre in esso; di conseguenza, i server Trasporto Edge nel centro dati principale risultano non disponibili.

Anche con una configurazione attiva/attiva, potrebbe essere appropriato aggiornare i record di risorse MX per i server Trasporto Edge durante lo switchover di un centro dati. Se si consente al record di risorse MX relativo al centro dati danneggiato di continuare a puntare al centro dati danneggiato, nel momento in cui viene avviato il ripristino del centro dati questo potrebbe tentare di connettersi ai relativi server Trasporto Edge. Ciò potrebbe accadere mentre i servizi Trasporto Edge sono in uno stato di instabilità (ad esempio, in quanto si stanno ripristinando servizi dipendenti nel centro dati).

Presumendo che i record DNS siano sotto il controllo dell'organizzazione, l'attivazione dei server Trasporto Edge implica l'aggiornamento del record di risorse MX per ciascun dominio SMTP ospitato dal server.

Gli aggiornamenti del DNS abilitano il traffico in ingresso e il traffico in uscita viene gestito dall'attivazione dei database delle cassette postali in un sito che dispone di server Trasporto Edge funzionanti:

• Quando le connessioni SMTP in ingresso vengono avviate utilizzando le informazioni sulla risoluzione dei nomi aggiornate, i client SMTP si connetteranno ai server Trasporto Edge nel secondo centro dati. Il traffico verrà instradato in modo appropriato dal server Trasporto Edge e non è necessario apportare ulteriori modifiche.

• Quando vengono avviate le connessioni SMTP in uscita, queste proveranno a connettersi al server Trasporto Edge localmente disponibile e i messaggi verranno messi in coda o inviati immediatamente a seconda dello stato del server di ricezione.

Ripristino del servizio per il centro dati principale

In genere, gli errori del centro dati sono temporanei o permanenti. Nel caso di un errore permanente, quale un evento che ha provocato la distruzione permanente di un centro dati principale, non vi è alcuna prospettiva che il centro dati principale venga attivato. Tuttavia, nel caso di un errore temporaneo (ad esempio, un'interruzione di alimentazione estesa o di dimensioni notevoli, ma con un danno reversibile), esiste una possibilità che venga ripristinato il servizio completo del centro dati principale.

Il processo di ripristino del servizio in un data center non riuscito in precedenza viene definito switchback. I passaggi usati per eseguire il switchback di un data center sono simili ai passaggi usati per eseguire il switchover di un data center. Una differenza significativa è che i switchback dei data center sono pianificati e la durata dell'interruzione è spesso molto più breve.

È importante che lo switchback non venga eseguito finché le dipendenze dell'infrastruttura per Exchange non vengono riattivate, non risultano funzionanti e stabili e non sono state convalidate. Se tali dipendenze non sono disponibili o integre, il processo di switchback potrebbe determinare un'interruzione più lunga del necessario e potrebbe non essere completato correttamente.

Switchback del ruolo server Cassette postali

Il ruolo server Cassette postali dovrebbe essere il primo di cui eseguire lo switchback al datacenter principale. La procedura seguente illustra in dettaglio il processo di switchback del ruolo server Cassette postali:

1. Come parte del processo di switchover del centro dati, è stato attivato uno stato di arresto per i server Cassette postali nel centro dati principale. Quando l'ambiente (quali il centro dati principale, le dipendenze di Exchange e una connettività WAN) è pronto, il primo passaggio è di attivare lo stato avviato per i server Cassette postali del centro dati principale ripristinato e di incorporarli nel gruppo di disponibilità del database. La modalità con cui viene eseguita questa operazione dipende dal fatto che il gruppo di disponibilità del database sia o meno in modalità di coordinazione dell'attivazione del database.

   1. Se il gruppo di disponibilità del database è in modalità di coordinazione dell'attivazione del database, è possibile incorporare i membri del gruppo di disponibilità del database nel sito principale utilizzando il cmdlet Start-DatabaseAvailabilityGroup. A questo punto, per assicurarsi che il DAG stia utilizzando il modello di quorum appropriato, eseguire il cmdlet Set-DatabaseAvailabilityGroup sul DAG senza specificare alcun parametro.

   2. Se il gruppo di disponibilità del database non è in modalità di coordinazione dell'attivazione del database, è possibile incorporare i membri del gruppo di disponibilità del database utilizzando il cmdlet Add-DatabaseAvailabilityGroupServer.

2. Una volta incorporati i server Cassette postali del centro dati principale nel gruppo di disponibilità del database, sarà necessario sincronizzarne saltuariamente le relative copie del database. A seconda del tipo di errore, della durata dell'interruzione e delle azioni intraprese da un amministratore durante l'interruzione, ciò potrebbe richiedere il reseeding delle copie del database. Ad esempio, se durante l'interruzione, si rimuovono le copie del database dal centro dati principale danneggiato per consentire il troncamento dei file di registro per le restanti copie attive nel secondo centro dati, sarà necessario eseguire il reseeding. Da questo punto in avanti, ciascun database può procedere individualmente. Una volta verificata l'integrità dei una copia del database replicata nel centro dati principale, è possibile passare al passo successivo.

   Nota

   Tale processo non richiede uno spostamento contemporaneo di tutti i database. Si consiglia di spostare la maggior parte dei database dell'organizzazione contemporaneamente; tuttavia, alcuni database potrebbero rimanere nel secondo centro dati qualora si verificassero problemi associati alle copie del database nel centro dati principale.

3. Dopo aver verificato che la maggior parte dei database si trova in uno stato integro nel datacenter principale, è possibile programmare l'interruzione per lo switchback. Quando arriva il periodo pianificato, è necessario adottare la seguente procedura:

   1. Durante il processo di switchover del centro dati, il gruppo di disponibilità del database era configurato per utilizzare un server di controllo alternativo. È necessario riconfigurare il gruppo di disponibilità del database affinché utilizzi un server di controllo nel centro dati principale. Se si usa lo stesso server di controllo e la stessa directory di controllo usati prima dell'interruzione del data center primario, è possibile eseguire il Set-DatabaseAvailabilityGroup -Identity DAGName comando . Se si intende utilizzare un server o una directory di controllo diversi dal server e dalla directory di controllo originali, utilizzare il comando Set-DatabaseAvailabilityGroup per configurare i parametri del server e della directory di controllo con i valori appropriati.

   2. I database che si stanno riattivando nel centro dati principale devono essere smontati nel secondo centro dati. È possibile utilizzare il cmdlet Dismount-Database per smontare i database.

   3. Dopo aver smontato i database, gli URL dei server che eseguono i servizi Accesso client devono essere spostati dal secondo data center al data center primario. A tale scopo, modificare il record DNS per gli URL in modo che puntino al server o alla matrice dei servizi accesso client nel data center primario. Così facendo, il sistema agirà come se si verificasse un failover del database per ciascun database spostato.

   Importante

   Non procedere al passaggio successivo fino a quando gli URL per i server che eseguono i servizi Accesso client non sono stati spostati e le voci dns TTL e cache sono scadute. L'attivazione dei database nel data center primario prima di spostare gli URL nel data center primario comporterà una configurazione non valida, ad esempio un database montato che non dispone di servizi Accesso client in esecuzione nel sito Active Directory.

4. Poiché ciascun database nel centro dati principale è in uno stato di integrità, è possibile attivarlo nel centro dati principale eseguendo gli switchover del database. Tale operazione viene eseguita utilizzando il cmdlet Move-ActiveMailboxDatabase per ciascun database che verrà attivato.

5. Una volta spostati tutti i database nel centro dati principale, è possibile montarli utilizzando il cmdlet Mount-Database.

Dopo avere attivato e montato uno o più database nel datacenter principale, è possibile eseguire le procedure di switchback per gli altri ruoli server.

Switchback dei servizi accesso client

Nell'ambito del processo di switchover, i record DNS interni ed esterni usati da client, altri server e gateway IP per risolvere gli endpoint di servizio per i servizi accesso client, i servizi trasporto e messaggistica unificata e i server Trasporto Edge sono stati modificati in modo da puntare agli endpoint corrispondenti nel secondo data center. Il processo di switchback per gli altri ruoli server implica la modifica di tali record in modo che puntino agli endpoint del servizio ripristinati nel datacenter principale.

Come nel caso delle modifiche apportate al DNS effettuate durante lo switchover al secondo centro dati, i client, i server e i gateway IP proseguiranno con i tentativi di connessione e dovrebbero connettersi automaticamente alla scadenza del valore TTL per la voce del DNS originale e alla scadenza della voce dalla relativa cache DNS.

Ripristino della resilienza del sito

Terminato lo switchback al datacenter principale, è possibile ristabilire la resilienza del sito per il datacenter principale verificando l'integrità e lo stato di ogni copia del database delle cassette postali nel secondo datacenter. Inoltre, se ciascuna copia del database nel secondo centro dati risultava originariamente bloccata per l'attivazione, è possibile, a questo punto, riconfigurare tali impostazioni.