Condividi tramite

Distribuzione della disponibilità elevata e della resilienza del sito

  • Articolo

Si applica a: Exchange Server 2010

Ultima modifica dell'argomento: 2009-12-04

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 risorsa cluster per l'elevata disponibilità e non è un'applicazione compatibile con il cluster (o in cluster). 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. Al contrario, basterà semplicemente installare tutti i server Exchange 2010 come server autonomi, quindi distribuire l'elevata disponibilità e la resilienza del sito in base alle esigenze.

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. Aggiungere due o più server Cassette postali al DAG. Per la procedura dettagliata, vedere Gestisci l'appartenenza al gruppo di disponibilità del database.
  3. 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 relativa alla 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.
  4. 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

Nota

I ruoli del server Accesso client, Trasporto Hub e Cassette postali possono trovarsi su un unico computer. In questa distribuzione di esempio, i ruoli del server sono installati su computer separati.

Nella figura seguente è illustrata la configurazione Contoso.

Gruppo di disponibilità del database esteso tra due siti
Gruppo di disponibilità del database 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.

Nome Indirizzo IPv4 Subnet mask Gateway predefinito

MBX1A (MAPI)

192.168.1.4

255.255.255.0

192.168.1.1

MBX2A (MAPI)

192.168.1.5

255.255.255.0

192.168.1.1

MBX1B (MAPI)

192.168.2.4

255.255.255.0

192.168.2.1

MBX2B (MAPI)

192.168.2.5

255.255.255.0

192.168.2.1

MBX1A (replica)

10.0.1.4

255.255.0.0

Nessuna

MBX2A (replica)

10.0.1.5

255.255.0.0

Nessuna

MBX1B (replica)

10.0.2.4

255.255.0.0

Nessuna

MBX2B (replica)

10.0.2.5

255.255.0.0

Nessuna

Come illustrato nella tabella precedente, le schede utilizzate per le reti di replica non utilizzano gateway predefiniti. Per fornire la connettività di rete tra ciascuna scheda di rete di replica, Contoso utilizza route statiche permanenti.

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

Route add 10.0.2.0 mask 255.255.0.0 10.0.1.254 -p

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

Route add 10.0.1.0 mask 255.255.0.0 10.0.2.254 -p

Nota

L'opzione –p viene utilizzata per rendere le route permanenti (ad esempio, per mantenerle dopo il riavvio). Se non si utilizza l'opzione –p, le route scompariranno dopo il riavvio e si perderà la connettività.

Sono state configurate anche le seguenti impostazioni di rete aggiuntive:

  • La casella di controllo Registra gli indirizzi della connessione in DNS è selezionata per ogni scheda di rete MAPI e deselezionata per ogni scheda di rete di replica.
  • Per ogni scheda di rete MAPI viene configurato almeno un indirizzo del server DNS mentre per le schede di rete di replica non viene configurato alcun indirizzo. 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à:

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.

Nota

L'utilizzo dello stesso percorso non è necessario. Contoso ha deciso di standardizzare la configurazione.

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
Layout 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.

Nota

Nell'esempio precedente, viene eseguito il seeding della copia del database non ritardata nella rete WAN e tale copia viene utilizzata per eseguire il seeding della copia ritardata del database che si trova nello stesso datacenter della copia non ritardata.

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à:

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