Distribuzione della disponibilità elevata e della resilienza del sito

Si applica a: Exchange Server 2010 SP2, Exchange Server 2010 SP3

Ultima modifica dell'argomento: 2015-03-09

Per creare un server Cassette postali a elevata disponibilità nelle versioni precedenti di Exchange, occorre installare Exchange su un server configurato come membro del cluster di failover di Microsoft Windows. Se si desiderava un server Cassette postali a elevata disponibilità, era necessario creare e configurare il cluster prima di eseguire il programma di installazione di Exchange. Il programma di installazione di Exchange (e altri componenti di Exchange, ad esempio l'archivio di Exchange e il servizio Supervisore sistema di Microsoft Exchange) era compatibile con il cluster e perciò si comportava diversamente quando veniva eseguito su un server autonomo. Se Exchange era già installato su un server di Windows autonomo, non era possibile configurare il server per l'elevata disponibilità senza prima rimuovere Exchange, creare un cluster e reinstallare Exchange utilizzando una versione del programma di installazione compatibile con il cluster.

Microsoft Exchange Server 2010 utilizza il concetto conosciuto come distribuzione incrementale sia per l'elevata disponibilità che per la resilienza del sito. A differenza delle versioni precedenti, Exchange 2010 non utilizza più il modello di risorse cluster per una disponibilità elevata. Come risultato di questa modifica all'architettura, non esiste più una versione del programma di installazione compatibile con il cluster e non sarà più necessario configurare l'elevata disponibilità durante l'installazione. Contrariamente, è sufficiente installare tutti i server di Exchange 2010 come server autonomi e, quindi, configurare in modo incrementale i server e i database delle cassette postali per un'elevata disponibilità e resilienza del sito, in base alle necessità.

Panoramica del processo di distribuzione

Mentre i passi attuali utilizzati da ogni organizzazione possono variare leggermente, l'intero processo di distribuzione di Exchange 2010 durante la configurazione con resilienza del sito o a elevata disponibilità è generalmente lo stesso. Dopo l'esecuzione delle attività di pianificazione e progettazione necessarie per la creazione e distribuzione di un gruppo di disponibilità del database (DAG) e la creazione delle copie del database delle cassette postali, fare quanto segue:

1. Creare un DAG. Per la procedura dettagliata, vedere Creazione di un gruppo di disponibilità del database.

2. Se necessario, preinstallare l'oggetto del nome cluster (CNO). Quando si effettua la distribuzione di un gruppo di disponibilità del database con i server Cassette postali che eseguono Windows Server 2012, è necessaria la pregestione del CNO. La pregestione è necessaria anche negli ambienti in cui la creazione di account del computer è limitata o in cui gli account del computer vengono creati in un contenitore diverso dal contenitore di computer predefinito. Per la procedura dettagliata, vedere Pregestione dell'oggetto nome cluster per un gruppo di disponibilità del database.

3. Aggiungere due o più server Cassette postali al DAG. Per la procedura dettagliata, vedere Gestisci l'appartenenza al gruppo di disponibilità del database.

4. Configurare le proprietà del DAG in base alle esigenze:

   1. Eventualmente, configurare la compressione e la crittografia DAG, la porta per la replica, gli indirizzi IP del DAG e altre proprietà del DAG. Per la procedura dettagliata, vedere Configurazione delle proprietà del gruppo di disponibilità del database.

   2. Se il DAG contiene tre o più server Cassette postali distribuiti in più siti di Active Directory, deve essere abilitata la modalità di coordinamento dell'attivazione del datacenter (DAC). Per ulteriori informazioni, vedere Informazioni sulla modalità di coordinamento dell'attivazione del centro dati.

   3. Per la procedura dettagliata sulla creazione di una rete DAG, vedere Creazione di una rete del gruppo di disponibilità del database. Per gestire una rete DAG, vedere Configurazione delle proprietà di rete del gruppo di disponibilità del database.

5. Aggiungere copie del database delle cassette postali tra i server Cassette postali nel DAG. Per la procedura dettagliata, vedere Aggiunta di una copia del database delle cassette postali.

Distribuzione di esempio: DAG con quattro membri in due datacenter

In questo esempio viene descritto come l'organizzazione Contoso, Ltd. configura e distribuisce un DAG con quattro membri che verrà esteso in due posizioni fisiche: un datacenter primario noto come SITO_A di Active Directory e un datacenter secondario noto come SITO_B di Active Directory. SITO_A si trova a Redmond, Washington e SITO_B a Dublino, Irlanda.

Infrastruttura di base

Ogni percorso contiene gli elementi dell'infrastruttura necessari per far funzionare un'infrastruttura di messaggistica basata su Exchange 2010, cioè:

• I servizi directory (Active Directory o Servizi di dominio di Active Directory)

• La risoluzione del nome DNS (Domain Name System)

• Uno o più server Accesso client di Exchange 2010

• Uno o più server Trasporto Hub di Exchange 2010

• Uno o più server Cassette postali di Exchange 2010

Nella figura seguente è illustrata la configurazione Contoso.

Gruppo di disponibilità del database esteso tra due siti

Ad eccezione dei server Cassette postali, tutti i server nell'ambiente Contoso eseguono il sistema operativo Windows Server 2008 R2 Standard. I server Cassette postali, progettati tenendo conto dei DAG eseguono Windows Server 2008 R2 Enterprise.

Oltre ai componenti dell'infrastruttura precedente, ogni posizione contiene altri elementi di messaggistica, ad esempio i server Trasporto Edge e i server Messaggistica unificata.

Configurazione di rete

Come illustrato nella figura precedente, la soluzione include l'utilizzo di più subnet e più reti. Ogni server Cassette postali nel DAG ha due schede di rete su subnet separate. In ogni server Cassette postali, una scheda di rete verrà utilizzata per la rete MAPI (192.168.x.x) e una scheda di rete verrò utilizzata per la rete di replica (10.0.x.x). Solo la rete MAPI fornisce la connettività a Active Directory, ai servizi DNS e ad altri server e client Exchange. La scheda utilizzata per la rete di replica in ogni membro fornisce la connettività solo alle schede di rete di replica negli altri membri del DAG.

Le impostazioni per ogni scheda di rete in ogni nodo sono descritte in dettaglio nella tabella seguente.

Come illustrato nella tabella precedente, le schede utilizzate per le reti di replica non utilizzano gateway predefiniti. Per fornire la connettività di rete tra tutte le schede di rete di replica, Contoso utilizza route statiche permanenti che eseguono la configurazione mediante lo strumento Netsh.exe. Netsh.exe è uno strumento che può essere utilizzato per configurare e monitorare computer basati su Windows su un prompt di comandi. Lo strumento Netsh.exe consente di direzionare i comandi di contesto immessi in un helper appropriato che, a sua volta, esegue il comando. Un helper è un file di libreria di collegamento dinamico (.dll) che estende la funzionalità dello strumento Netsh.exe fornendo la configurazione, il monitoraggio e il supporto per uno o più servizi, utilità o protocolli.

Per configurare il routing per le schede di rete di replica su MBX1A e MBX2A, veniva eseguito questo comando su ogni server.

netsh interface ipv4 add route 10.0.2.0/24 <NetworkName> 10.0.1.254

Per configurare il routing per le schede di rete di replica su MBX1B e MBX2B, veniva eseguito questo comando su ogni server.

netsh interface ipv4 add route 10.0.1.0/24 <NetworkName> 10.0.2.254

Sono state configurate anche le seguenti impostazioni di rete aggiuntive:

• La casella di controllo Registra tale indirizzo di connessione nel DNS è selezionata per ogni scheda di rete MAPI del membro DAG e deselezionata per ogni scheda di rete di replica.

• Viene configurato almeno un indirizzo del server DNS configurato per ogni scheda di rete MAPI del membro DAG, mentre non ne viene configurato alcuno per le schede di rete di replica. Per la ridondanza, Contoso utilizza più indirizzi del server DNS per le schede di rete MAPI.

• Contoso non utilizza IPv6 e il protocollo viene disabilitato sui server.

• Contoso non utilizza Windows Firewall che è disattivato sui server.

Dopo che le schede di rete sono state configurate, Contoso è pronto a creare un DAG e ad aggiungere i server Cassette postali al DAG.

Creazione e configurazione del gruppo di disponibilità del database

L'amministratore ha deciso di creare uno script dell'interfaccia della riga dei comandi di Windows PowerShell che esegue diverse attività:

• Viene utilizzato il cmdlet New-DatabaseAvailabilityGroup per creare il DAG. Dal momento che SITO_A viene considerato il datacenter primario, Contoso ha scelto di utilizzare un server di controllo nello stesso datacenter, cioè, HUB-A.

• Viene utilizzato il cmdlet Set-DatabaseAvailabilityGroup per preconfigurare un server di controllo alternativo e una directory di controllo alternativa nel caso sia necessaria un'operazione di switchover del sito.

• Viene utilizzato il cmdlet Add-DatabaseAvailabilityGroupServer per aggiungere ciascuno dei quattro server Cassette postali al DAG.

• Viene utilizzato il cmdlet Set-DatabaseAvailabilityGroup per configurare il DAG per la modalità DAC. Per ulteriori informazioni relative alla modalità DAC, vedere Informazioni sulla modalità di coordinamento dell'attivazione del centro dati.

Di seguito sono riportati i comandi utilizzati nello script:

New-DatabaseAvailabilityGroup -Name DAG1 -WitnessServer HUB-A -WitnessDirectory C:\DAGWitness\DAG1.contoso.com -DatabaseAvailabilityGroupIPAddresses 192.168.1.8,192.168.2.8

Il comando precedente crea un DAG denominato DAG1, configura Hub-A in modo che funzioni come server di controllo, configura una directory di controllo specifica (C:\DAGWitness\DAG1.contoso.com) e configura due indirizzi IP per il DAG (uno per ogni subnet sulla rete MAPI).

Set-DatabaseAvailabilityGroup -Identity DAG1 -AlternateWitnessDirectory C:\DAGWitness\DAG1.contoso.com -AlternateWitnessServer HUB-B

Il comando precedente configura DAG1 per utilizzare un server di controllo alternativo di Hub-B e una directory di controllo alternativa su Hub-B che utilizza lo stesso percorso configurato su Hub-A.

Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer MBX1A
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer MBX1B
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer MBX2A
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer MBX2B

I comandi precedenti aggiungono un server Cassette postali alla volta al DAG. I comandi installano anche il componente clustering di failover di Windows su ogni server Cassette postali (se non è già installato), creano un cluster di failover e aggiungono ogni server Cassette postali al cluster appena creato.

Set-DatabaseAvailabilityGroup -Identity DAG1 -DatacenterActivationMode DagOnly

Il comando precedente abilità la modalità DAC per il DAG.

Database delle cassette postali e copie del database delle cassette postali

Dopo aver creato il DAG e aggiunto i server Cassette postali al DAG, Contoso si prepara alla creazione di database delle cassette postali e di copie del database delle cassette postali. Per creare un sistema a prova di errori, Contoso intende configurare ogni database delle cassette postali con tre copie del database non ritardate e una copia del database ritardata. La copia ritardata avrà un ritardo di riesecuzione dei file di registro configurato di tre giorni.

Questa configurazione fornisce un totale di quattro copie per ogni database (una attiva, due passive non ritardate e una passiva ritardata). Contoso intende disporre di quattro database attivi per ciascun server. Con quattro database attivi per ciascun server e tre copie passive di ogni database, la soluzione Contoso contiene in totale 16 copie del database.

Come illustrato nella figura seguente, Contoso desidera ottenere un layout bilanciato dei database.

Layout della copia del database per Contoso, Ltd

Ogni server Cassette postali ospita una copia del database delle cassette postali attiva, due copie del database passive non ritardate e una copia del database passiva ritardata. La copia ritardata di ciascun database delle cassette postali attivo è ospitata su un server Cassette postali nell'altro sito.

Per creare questa configurazione, l'amministratore esegue diversi comandi.

In MBX1A, eseguire i comandi riportati di seguito.

Add-MailboxDatabaseCopy -Identity DB1 -MailboxServer MBX2A
Add-MailboxDatabaseCopy -Identity DB1 -MailboxServer MBX2B
Add-MailboxDatabaseCopy -Identity DB1 -MailboxServer MBX1B -ReplayLagTime 3.00:00:00 -SeedingPostponed
Suspend-MailboxDatabaseCopy -Identity DB1\MBX1B -SuspendComment "Seed from MBX2B" -Confirm:$False
Update-MailboxDatabaseCopy -Identity DB1\MBX1B -SourceServer MBX2B
Suspend-MailboxDatabaseCopy -Identity DB1\MBX1B -ActivationOnly

In MBX2A, eseguire i comandi riportati di seguito.

Add-MailboxDatabaseCopy -Identity DB2 -MailboxServer MBX1A
Add-MailboxDatabaseCopy -Identity DB2 -MailboxServer MBX1B
Add-MailboxDatabaseCopy -Identity DB2 -MailboxServer MBX2B -ReplayLagTime 3.00:00:00 -SeedingPostponed
Suspend-MailboxDatabaseCopy -Identity DB2\MBX2B -SuspendComment "Seed from MBX1B" -Confirm:$False
Update-MailboxDatabaseCopy -Identity DB2\MBX2B -SourceServer MBX1B
Suspend-MailboxDatabaseCopy -Identity DB2\MBX2B -ActivationOnly

In MBX1B, eseguire i comandi riportati di seguito.

Add-MailboxDatabaseCopy -Identity DB3 -MailboxServer MBX2B
Add-MailboxDatabaseCopy -Identity DB3 -MailboxServer MBX2A
Add-MailboxDatabaseCopy -Identity DB3 -MailboxServer MBX1A -ReplayLagTime 3.00:00:00 -SeedingPostponed
Suspend-MailboxDatabaseCopy -Identity DB3\MBX1A -SuspendComment "Seed from MBX2A" -Confirm:$False
Update-MailboxDatabaseCopy -Identity DB3\MBX1A -SourceServer MBX2A
Suspend-MailboxDatabaseCopy -Identity DB3\MBX1A -ActivationOnly

In MBX2B, eseguire i comandi riportati di seguito.

Add-MailboxDatabaseCopy -Identity DB4 -MailboxServer MBX1B
Add-MailboxDatabaseCopy -Identity DB4 -MailboxServer MBX1A
Add-MailboxDatabaseCopy -Identity DB4 -MailboxServer MBX2A -ReplayLagTime 3.00:00:00 -SeedingPostponed
Suspend-MailboxDatabaseCopy -Identity DB4\MBX2A -SuspendComment "Seed from MBX1A" -Confirm:$False
Update-MailboxDatabaseCopy -Identity DB4\MBX2A -SourceServer MBX1A
Suspend-MailboxDatabaseCopy -Identity DB4\MBX2A -ActivationOnly

Negli esempi precedenti per il cmdlet Add-MailboxDatabaseCopy, il parametro ActivationPreference non è stato specificato. L'attività aumenta automaticamente il numero della preferenza di attivazione con ogni copia aggiunta. Il numero della preferenza del database originale è sempre 1. Alla prima copia aggiunta con il cmdlet Add-MailboxDatabaseCopy viene assegnato automaticamente il numero della preferenza 2. Partendo dal presupposto che nessuna copia viene rimossa, alla successiva copia aggiunta viene assegnato il numero della preferenza 3 e così via. In questo modo, negli esempi precedenti, il numero della preferenza di attivazione della copia passiva nello stesso datacenter della copia attiva è 2; quello della copia passiva non ritardata nel datacenter remoto è 3 e quello della copia passiva ritardata nel datacenter remoto è 4.

Anche se esistono due copie di ogni database attivo nella rete WAN in un altro percorso, il seeding nella rete WAN è stato eseguito solo una volta. Ciò perché Contoso sta sfruttando la capacità di Exchange 2010 di utilizzare una copia passiva di un database come origine del seeding. L'utilizzo del cmdlet Add-MailboxDatabaseCopy con il parametro SeedingPostponed impedisce all'attività di eseguire automaticamente il seeding della copia del database appena creata. Quindi, l'amministratore può sospendere la copia priva di seeding e utilizzando il cmdlet Update-MailboxDatabaseCopy con il parametro SourceServer, può specificare la copia locale del database come origine dell'operazione di seeding. Di conseguenza, il seeding della seconda copia del database aggiunta a ogni percorso si verifica localmente e non nella rete WAN.

Contoso ha configurato una copia passiva di ciascun database delle cassette postali come copia del database ritardata per garantire la protezione nel caso si verifichi il danneggiamento logico del database. Di conseguenza, l'amministratore configura le copie ritardate come bloccate per l'attivazione utilizzando il cmdlet Suspend-MailboxDatabaseCopy con il parametro ActivationOnly. In questo modo le copie del database ritardate non verranno attivate se si verifica il failover del server o del database.

Convalida della soluzione

Dopo aver distribuito e configurato la soluzione, l'amministratore esegue diverse attività che convalidano la conformità della soluzione prima di spostare le cassette postali di produzione nei database del DAG. È necessario verificare la soluzione utilizzando diversi metodi, comprese le simulazioni di errore. Per convalidare la soluzione, l'amministratore esegue diverse attività.

Per verificare lo stato generale del DAG, l'amministratore esegue il cmdlet Test-ReplicationHealth. Questo cmdlet controlla diversi aspetti dello stato di riesecuzione e di replica per fornire le informazioni relative a ogni server Cassette postali e alla copia del database nel DAG.

Per verificare le operazioni di riesecuzione e di replica, l'amministratore esegue il cmdlet Get-MailboxDatabaseCopyStatus. Questo cmdlet è in grado di fornire informazioni sullo stato in tempo reale relative a una copia specifica del database delle cassette postali o per tutte le copie del database delle cassette postali su un server specifico. Per ulteriori informazioni relative al monitoraggio dell'integrità e dello stato dei database replicati in un DAG, vedere Monitoraggio della disponibilità elevata e della resilienza del sito.

Per verificare che le operazioni di switchover funzionino nel modo previsto, l'amministratore utilizza il cmdlet Move-ActiveMailboxDatabase per eseguire una serie di switchover del server e del database. Al termine di queste attività, l'amministratore utilizza lo stesso cmdlet per spostare le copie del database attive nei percorsi originali.

Per verificare i comportamenti previsti in diversi scenari di errore, l'amministratore esegue diverse attività che simulano o causano effettivamente degli errori. Ad esempio, l'amministratore può fare quanto segue:

• Scollegare il cavo di alimentazione su MBX1A, attivando un failover del server. L'amministratore verifica che DB1 diventi attivo su un altro server (preferibilmente MBX2A, in base ai valori della preferenza di attivazione).

• Scollegare il cavo di rete per la scheda di rete MAPI su MBX2A, attivando un failover del server. L'amministratore verifica che DB2 diventi attivo su un altro server (preferibilmente MBX1A, in base ai valori della preferenza di attivazione).

• Prendere in modalità offline il disco utilizzato dalla copia attiva di DB3, attivando un failover del database. L'amministratore verifica che DB3 diventi attivo su un altro server (preferibilmente MBX2B, in base ai valori della preferenza di attivazione).

Potrebbero esistere altri scenari di errore verificati dall'organizzazione, in base alle esigenze. Dopo aver simulato un errore (ad esempio, tirando il cavo di alimentazione) e verificando il comportamento della soluzione, l'amministratore può ripristinare la configurazione originale della soluzione. In alcuni casi, la soluzione potrebbe essere testata per più errori simultanei. Il piano di verifica della soluzione stabilirà se ripristinare la configurazione originale della soluzione al termine di ogni simulazione di errore.

Inoltre, un amministratore può decidere di interrompere la connessione di rete tra due datacenter, simulando un errore nel sito. L'esecuzione di uno switchover del datacenter è un processo molto più complesso e coordinato; tuttavia è un processo consigliato se la soluzione distribuita è stata progettata per fornire la resilienza del sito per i dati e i servizi di messaggistica. Per informazioni dettagliate sugli switchover del datacenter, vedere Passaggi centro dati.

Passaggio alla fase operativa

Dopo aver distribuito la soluzione, può essere estesa ulteriormente utilizzando la distribuzione incrementale. A questo punto, la gestione della soluzione passerà alla fase operativa e verranno eseguite queste attività:

• Monitorare l'integrità e lo stato dei DAG e copie del database delle cassette postali. Per ulteriori informazioni, vedere Monitoraggio della disponibilità elevata e della resilienza del sito.

• Eseguire switchover del database e del server, in base alle esigenze. Per la procedura dettagliata relativa all'esecuzione di un passaggio di database, vedere Attivazione di una copia database delle cassette postali. Per la procedura dettagliata relativa all'esecuzione di un passaggio di server, vedere Esecuzione del passaggio di un server. Se necessario, avviare lo switchover del datacenter. Per ulteriori informazioni sul passaggio tra centri dati, vedere Passaggi centro dati.

Per ulteriori informazioni sulla gestione della soluzione, vedere Gestione della disponibilità elevata e della resilienza del sito.

 ©2010 Microsoft Corporation. Tutti i diritti riservati.