Gestione dei gruppi di disponibilità del database

 

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

Ultima modifica dell'argomento: 2016-11-28

Un gruppo di disponibilità del database (DAG) è un insieme di 16 server Cassette postali Microsoft Exchange Server 2010 che fornisce il ripristino automatico a livello di database da un errore del database, del server o della rete. I DAG utilizzano la replica continua ed un sottogruppo di tecnologie clustering di failover di Windows per fornire un'elevata disponibilità e resilienza del sito. I server Cassette postali in un gruppo di disponibilità del database si controllano reciprocamente alla ricerca di errori. Quando un server Cassette postali viene aggiunto a un DAG, funziona con gli altri server del DAG per fornire il ripristino automatico da errori a livello di database.

Quando si crea un DAG, questo risulta inizialmente vuoto e viene creato un oggetto di directory in Active Directory che rappresenta il DAG. L'oggetto di directory viene utilizzato per archiviare informazioni importanti relative al DAG, ad esempio le informazioni di appartenenza del server. Quando si aggiunge il primo server a un DAG, per quel DAG viene creato automaticamente un cluster di failover. Inoltre, viene attivata l'infrastruttura che controlla i server per rilevare eventuali problemi della rete o dei server stessi. Il meccanismo heartbeat di cluster di failover e il database cluster sono poi utilizzati per tracciare e gestire le informazioni sul DAG che possono cambiare rapidamente, come lo stato di installazione del database, lo stato di replica e l'ultimo percorso d'installazione.

Sommario

Creazione di DAG

Appartenenza al DAG

Configurazione delle proprietà del DAG

Reti del DAG

Configurazione di membri DAG

Esecuzione della manutenzione sui membri DAG

Chiusura dei membri DAG

Installazione di aggiornamenti cumulativi sui membri DAG

Creazione di DAG

Un DAG può essere creato utilizzando la procedura guidata relativa alla creazione di un nuovo gruppo di disponibilità del database in Exchange Management Console (EMC) o eseguendo il cmdlet New-DatabaseAvailabilityGroup in Exchange Management Shell. Quando viene creato un DAG, è necessario specificare un nome per il DAG e una directory e un server di controllo facoltativi. Inoltre, uno o più indirizzi IP vengono assegnati al DAG, utilizzando indirizzi IP statici o consentendo l'assegnazione automatica al DAG degli indirizzi IP necessari utilizzando il protocollo DHCP (Dynamic Host Configuration Protocol). È possibile assegnare manualmente indirizzi IP al DAG utilizzando il parametro DatabaseAvailabilityGroupIpAddresses. Se si omette questo parametro, il DAG tenta di ottenere un indirizzo IP utilizzando un server DHCP della rete.

Per la procedura dettagliata relativa alla creazione di un DAG, vedere Creazione di un gruppo di disponibilità del database.

Quando si crea un DAG, un oggetto vuoto che rappresenta il DAG con il nome specificato e la classe oggetto msExchMDBAvailabilityGroup viene creato in Active Directory.

I gruppi di disponibilità del database utilizzano la tecnologia di clustering di failover di Windows, ossia heartbeat cluster, reti cluster e database cluster (per l'archiviazione di dati che possono venire modificati rapidamente, ad esempio le modifiche di stato del database da attivo a passivo o viceversa, oppure da montato a smontato e viceversa). Poiché i DAG si basano sul clustering di failover di Windows, possono essere creati solo nei server Cassette postali di Exchange 2010 che eseguono il sistema operativo Windows Server 2008 Enterprise o Windows Server 2008 R2 Enterprise.

Server di controllo DAG e Directory di controllo

Quando si crea un DAG, è necessario specificare un nome per il DAG non più lungo di 15 caratteri e univoco all'interno della foresta di Active Directory. Inoltre, ciascun DAG viene configurato con un server e una directory di controllo. Il server di controllo e la directory relativa vengono utilizzati solo ai fini del quorum, quando il gruppo di disponibilità del database contiene un numero pari di membri. Non è necessario creare la directory di controllo in anticipo. Exchange crea e protegge automaticamente la directory sul server di controllo. Questa directory deve essere utilizzata esclusivamente per il server di controllo del DAG.

I requisiti per il server di controllo sono i seguenti:

• Il server di controllo non può essere un membro del DAG.

• Il server di controllo deve essere nella stessa foresta di Active Directory del DAG.

• Il server di controllo deve eseguire Windows Server 2003 o versione successiva.

• Un singolo server può essere utilizzato come server di controllo per più DAG. Tuttavia, ciascun DAG richiede la propria directory di controllo.

Si consiglia di utilizzare un server Trasporto Hub di Exchange 2010 nel sito di Active Directory contenente il DAG. In questo modo il server e la directory di controllo possono rimanere sotto il controllo di un amministratore di Exchange. Indipendentemente dal server utilizzato come server di controllo, se è abilitato Windows Firewall sul server di controllo previsto, è necessario abilitare l'eccezione di Windows Firewall per Condivisione file e stampanti.

Non è necessario che il server e la directory di controllo siano a prova di errore o che utilizzino altre forme di ridondanza o elevata disponibilità. Non è necessario utilizzare un file server in cluster per il server di controllo o impiegare qualunque altra forma di resilienza per il server di controllo. Ciò è dovuto a diversi motivi. Con DAG di dimensioni maggiori (ad esempio, con sei o più membri) devono verificarsi numerosi errori prima che sia necessario il server di controllo. Poiché un DAG con sei membri può tollerare fino a due errori del voter senza perdere il quorum, devono verificarsi almeno tre errori dei voter prima che sia necessario l'utilizzo del server di controllo per mantenere il quorum. Inoltre, se si verifica un errore che influisce sul server di controllo attuale (ad esempio, si perde il server di controllo a causa di un guasto hardware), è possibile utilizzare il cmdlet Set-DatabaseAvailabilityGroup per configurare un nuovo server e una nuova directory di controllo (purché si disponga di un quorum).

In un ambiente in cui un DAG si estende su più datacenter (e siti Active Directory) ed è configurato per la resilienza del sito, si consiglia di utilizzare un server di controllo in un datacenter principale (il datacenter che contiene la maggior parte degli utenti). Se ogni datacenter ha un numero simile di utenti, quello scelto per ospitare il server di controllo verrà considerato il datacenter principale dal punto di vista della soluzione. Se il server di controllo è nel datacenter che contiene la maggioranza dei client, la maggior parte dei client mantiene l'accesso dopo un errore.

Se il datacenter è remoto per numerosi utenti, ciò potrebbe influire sulla scelta. Sarebbe quindi necessario determinare se uno dei requisiti del datacenter principale è quello di rimanere integro e attivo in caso di perdita della connessione alla rete WAN con conseguente perdita di contatto con gli altri due datacenter. In questo caso, il server di controllo deve trovarsi anche nel datacenter principale.

Anche se è possibile utilizzare un server di controllo in un terzo datacenter, si sconsiglia questo scenario. Dal punto di vista di Exchange, questa configurazione non fornisce maggiore disponibilità. È molto importante prendere in esame tutte le criticità dei percorsi, quando si utilizza un server di controllo in un terzo datacenter. Ad esempio, se si perde la connessione WAN tra il datacenter principale e il secondo e il terzo datacenter, la soluzione che si trova nel datacenter principale non sarà più disponibile.

Indicazione di un server e di una directory di controllo durante la creazione di un DAG

Quando si crea un DAG, è necessario specificare un nome per il DAG. Opzionalmente, è anche possibile specificare un server e una directory di controllo. Se si specifica un server di controllo, si consiglia di utilizzare un server Trasporto Hub, in quanto questo consente a un amministratore di Exchange di conoscere la disponibilità del server di controllo.

Quando si crea un DAG, sono disponibili le seguenti combinazioni di opzioni e comportamenti:

• È possibile specificare solo un nome per il DAG e lasciare i campi Server di controllo e Directory di controllo vuoti. In questo scenario, la procedura guidata cercherà un server Trasporto Hub in cui non è installato il ruolo del server Cassette postali, creerà automaticamente la directory predefinita (%SystemDrive%:\DAGFileShareWitnesses\<DAGFQDN>) e la condivisione predefinita (<DAGFQDN>) su quel server Trasporto Hub che verrà utilizzato come server di controllo. Ad esempio, considerare un server di controllo denominato EXMBX3 su cui si è installato il sistema operativo sull'unità C. Un DAG denominato DAG1 in un dominio denominato contoso.com utilizzerebbe una directory di controllo predefinita C:\DAGFileShareWitnesses\DAG1.contoso.com, che verrebbe condivisa come \\EXMBX3\DAG1.contoso.com.

• È possibile specificare un nome per il DAG, il server di controllo che si desidera utilizzare e la directory che si desidera creare e condividere sul server di controllo.

• È possibile specificare un nome per il DAG, il server di controllo che si desidera utilizzare e lasciare il campo Directory di controllo vuoto. In questo scenario, la procedura guidata crea la directory predefinita sul server di controllo specificato.

• È possibile specificare un nome per il DAG, lasciare il campo Server di controllo vuoto e specificare la directory che si desidera creare e condividere sul server di controllo. In questo scenario, la procedura guidata ricerca un server Trasporto Hub su cui non è installato il ruolo del server Cassette postali e crea automaticamente il DAG specificato su quel server, condivide la directory e utilizza il server Trasporto Hub come server di controllo.

Quando viene costituito un DAG, questo utilizza inizialmente il modello di quorum Maggioranza dei nodi. Quando il secondo server Cassette postali viene aggiunto al DAG, il modello di quorum viene automaticamente modificato in Maggioranza dei nodi e delle condivisioni file. Con questa modifica, il DAG inizia a utilizzare il server di controllo per il mantenimento di un quorum. Se la directory di controllo non esiste, Exchange la crea automaticamente, la condivide e fornisce le autorizzazioni di controllo completo per l'account sul computer dell'oggetto nome cluster del DAG.

Se Windows Firewall risulta abilitato sul server di controllo prima che venga creato il DAG, ciò potrebbe bloccare la creazione del DAG. Exchange utilizza Strumentazione gestione Windows (WMI) per creare la condivisione file e la directory sul server di controllo. Se Windows Firewall è abilitato sul server di controllo e non esistono eccezioni firewall configurate per WMI, il cmdlet New-DatabaseAvailabilityGroup restituirà un errore. Se si specifica un server di controllo ma non una directory di controllo, viene visualizzato il seguente messaggio di errore.

Non è stato possibile creare la directory di controllo predefinita sul server <Nome Server>. Specificare manualmente una directory di controllo.

Se si specifica un server di controllo e una directory di controllo, viene visualizzato il seguente messaggio di avviso.

Impossibile accedere alle condivisioni file sul server di controllo 'NomeServer'. Finché il problema non viene risolto, il gruppo di disponibilità del database potrebbe essere più vulnerabile agli errori. È possibile utilizzare il cmdlet Set-DatabaseAvailabilityGroup per ripetere l'operazione. Errore: Impossibile trovare il percorso di rete.

Se Windows Firewall viene abilitato sul server di controllo dopo la creazione del DAG ma prima dell'aggiunta dei server, ciò potrebbe bloccare l'aggiunta o la rimozione dei membri del DAG. Se Windows Firewall è abilitato sul server di controllo e non esistono eccezioni firewall configurate per WMI, il cmdlet Add-DatabaseAvailabilityGroupServer visualizza il seguente messaggio di errore.

Impossibile creare la directory di controllo di condivisione dei file 'C:\DAGFileShareWitnesses\DAG_FQDN' sul server di controllo 'NomeServer'. Finché il problema non viene risolto, il gruppo di disponibilità del database potrebbe essere più vulnerabile agli errori. È possibile utilizzare il cmdlet Set-DatabaseAvailabilityGroup per ripetere l'operazione. Errore: Eccezione WMI nel server 'NomeServer': Il server RPC non è disponibile. (Eccezione da HRESULT: 0x800706BA)

Per correggere l'errore precedente e i problemi riscontrati dagli avvisi, fare quanto segue:

• Creare manualmente la directory di controllo, condividerla sul server di controllo e assegnare l'oggetto nome cluster per il controllo totale del DAG relativamente alla directory e alla condivisione.

• Abilitare l'eccezione WMI in Windows Firewall.

• Disabilitare Windows Firewall.

Inizio pagina

Appartenenza al DAG

Una volta creato un DAG, è possibile aggiungere o rimuovere i server dal DAG utilizzando la procedura guidata relativa alla gestione del gruppo di disponibilità del database in EMC o utilizzando il cmdlet Add-DatabaseAvailabilityGroupServer o Remove-DatabaseAvailabilityGroupServer in Shell. Per la procedura dettagliata sulla gestione dell'appartenenza al DAG, vedere Gestisci l'appartenenza al gruppo di disponibilità del database.

Se sul server Cassette postali aggiunto a un DAG non è installato il componente di clustering di failover, il metodo utilizzato per aggiungere il server (ad esempio, il cmdlet Add-DatabaseAvailabilityGroupServer o la procedura guidata relativa alla gestione del gruppo di disponibilità del database) installerà la funzionalità di clustering di failover.

Quando il primo server Cassette postali viene aggiunto a un DAG, si verifica quanto segue:

• Se non è già installato, viene installato il componente clustering di failover di Windows.

• Viene creato un cluster di failover utilizzando il nome del DAG. Il cluster di failover viene utilizzato esclusivamente dal DAG e il cluster deve essere dedicato al DAG. L'utilizzo del cluster non è supportato per tutti gli scopi.

• Un oggetto nome cluster viene creato nel contenitore di computer predefinito.

• Il nome e l'indirizzo IP del DAG vengono registrati come record Host (A) nel DNS (Domain Name System).

• Il server viene aggiunto all'oggetto DAG in Active Directory.

• Il database del cluster viene aggiornato con le informazioni sui database installati sul server aggiunto.

In ambienti di dimensioni notevoli o con più siti, specialmente in quelli in cui il DAG viene esteso su più siti di Active Directory, è necessario attendere che venga completata la replica Active Directory dell'oggetto DAG contenente il primo membro del DAG. Se questo oggetto Active Directory non viene replicato nell'ambiente, aggiungendo il secondo server è possibile che venga creato un nuovo cluster e un nuovo oggetto di rete cluster per il DAG. Ciò avviene in quanto l'oggetto DAG appare vuoto dal punto di vista del secondo membro aggiunto. Di conseguenza, il cmdlet Add-DatabaseAvailabilityGroupServer creerà un cluster e un oggetto nome cluster per il DAG, anche se questi oggetti già esistono. Per verificare che l'oggetto DAG contenente il primo server DAG sia stato replicato, utilizzare il cmdlet Get-DatabaseAvailabilityGroup sul secondo server aggiunto per verificare che il primo server aggiunto sia elencato come membro del DAG.

Quando il secondo e i successivi server vengono aggiunti al DAG, si verifica quanto segue:

• Il server viene aggiunto al cluster di failover di Windows per il DAG.

• Il modello di quorum viene adattato automaticamente:

  • Il modello di quorum Maggioranza dei nodi viene utilizzato per i DAG contenenti un numero dispari di membri.

  • Il modello di quorum Maggioranza dei nodi e delle condivisioni di file viene utilizzato per i DAG contenenti un numero pari di membri.

• La directory di controllo e la condivisione vengono create automaticamente da Exchange quando necessario.

• Il server viene aggiunto all'oggetto DAG in Active Directory.

• Il database del cluster viene aggiornato con le informazioni sui database installati.

Pregestione dell'oggetto nome cluster per un DAG

Il CNO è un account del computer creato in Active Directory e associato alla risorsa Nome del cluster. La risorsa del nome cluster è collegata all'oggetto di rete cluster, un oggetto abilitato per Kerberos che funge da identità del cluster e fornisce il contesto di sicurezza del cluster. In Exchange 2007, questo account del computer abilitato per Kerberos è stato creato nel dominio utilizzando il contesto di sicurezza dell'utente che esegue le attività. È necessario che l'account utente abbia le autorizzazioni per creare e abilitare gli account del computer nel dominio o che l'account del computer venga correttamente pregestito e che venga eseguito il provisioning.

La creazione del cluster sottostante al DAG e del CNO per quel cluster viene eseguita quando il primo membro viene aggiunto al DAG. Quando il primo server viene aggiunto al DAG, Powershell contatta il servizio di replica di Microsoft Exchange sul server Cassette postali aggiunto. Il servizio di replica di Microsoft Exchange installa la funzionalità di clustering di failover (se non è già installata) e avvia il processo di creazione del cluster. Il servizio di replica di Microsoft Exchange viene eseguito nel contesto di sicurezza LOCAL SYSTEM ed è in questo contesto che viene eseguita la creazione del cluster.

In ambienti in cui la creazione degli account computer è limitata o in cui gli account computer vengono creati in un contenitore diverso da quello predefinito dei computer, è possibile pregestire ed eseguire il provisioning dell'oggetto di rete cluster. Creare e disabilitare un account computer per il CNO, quindi:

• Assegnare il controllo completo dell'account computer all'account computer del primo server Cassette postali aggiunto al DAG.

• Assegnare il controllo completo dell'account computer al gruppo di protezione universale Exchange Trusted Subsystem.

L'assegnazione del controllo completo dell'account computer all'account computer del primo server Cassette postali aggiunto al DAG fa sì che il contesto di sicurezza LOCAL SYSTEM sia in grado di gestire l'account computer pregestito. Invece, è possibile utilizzare l'assegnazione del controllo completo dell'account computer al gruppo di protezione universale Exchange Trusted Subsystem in quanto tale gruppo Exchange Trusted Subsystem contiene gli account computer di tutti i server Exchange nel dominio.

Per la procedura dettagliata relativa alla pregestione e al provisioning dell'oggetto di rete cluster per un DAG, vedere Pregestione dell'oggetto nome cluster per un gruppo di disponibilità del database.

Rimozioni di server da un DAG

I server Cassette postali possono essere rimossi da un DAG utilizzando la procedura guidata relativa alla gestione del gruppo di disponibilità del database in EMC o il cmdlet Remove-DatabaseAvailabilityGroupServer in Shell. Prima di rimuovere un server Cassette postali da un DAG, tutti i database delle cassette postali replicati devono prima essere rimossi dal server. Se si tenta di rimuovere un server Cassette postali con i database delle cassette postali replicati da un DAG, l'operazione non viene completata.

Ci sono alcuni scenari in cui è necessario rimuovere un server Cassette postali da un DAG prima di eseguire determinate operazioni. Tra questi scenari sono compresi:

• Esecuzione di un'operazione di ripristino del server   Se un server Cassette postali che è un membro di un DAG viene perso o non può essere in altro modo ripristinato a seguito di errore e deve quindi essere sostituito, è possibile eseguire un'operazione di ripristino del server utilizzando l'opzione Setup /m:RecoverServer. Tuttavia, prima di eseguire l'operazione di ripristino, è necessario rimuovere il server dal DAG utilizzando il cmdlet Remove-DatabaseAvailabilityGroupServer con il parametro ConfigurationOnly.

• Rimozione di un gruppo di disponibilità del database   Ci possono essere situazioni in cui è necessario rimuovere un DAG (ad esempio, quando si disabilita la modalità di replica di terze parti). Per rimuovere un DAG, occorre prima rimuovere tutti i server dal DAG. Se si tenta di rimuovere un DAG contenente uno o più membri, l'operazione non viene completata.

Inizio pagina

Configurazione delle proprietà del DAG

Dopo aver aggiunto i server al DAG, è possibile utilizzare EMC o Shell per configurare le proprietà di un DAG, compresi il server e la directory di controllo utilizzati dal DAG e gli indirizzi IP ad esso assegnati.

Le proprietà configurabili comprendono:

• Server di controllo   Il nome del server che si desidera ospiti la condivisione dei file per il server di controllo della condivisione file. Si consiglia di utilizzare un server Trasporto Hub esterno al DAG come server di controllo. Questo permette al sistema di configurare, proteggere e utilizzare automaticamente la condivisione, in base alle esigenze.

• Directory di controllo   Il nome di una directory da utilizzare per archiviare i dati di controllo della condivisione file. La directory verrà automaticamente creata dal sistema sul server di controllo specificato.

• Indirizzi IP del gruppo di disponibilità del database   Uno o più indirizzi IP assegnati al DAG. Questi indirizzi possono essere configurati utilizzando manualmente gli indirizzi IP statici assegnati o possono essere assegnati automaticamente al DAG utilizzando un server DHCP nell'organizzazione.

Shell consente di configurare le proprietà del DAG non disponibili in EMC, quali gli indirizzi IP, le impostazioni di crittografia e compressione di rete, l'individuazione della rete, la porta TCP utilizzata per la replica e le impostazioni per un server di controllo e una directory di controllo alternativi e di abilitare la modalità di coordinamento dell'attivazione del datacenter.

Per la procedura dettagliata sulla configurazione delle proprietà del DAG, vedere Configurazione delle proprietà del gruppo di disponibilità del database.

Crittografia di rete del DAG

I DAG supportano l'uso della crittografia sfruttando le funzionalità di crittografia del sistema operativo Windows Server. I DAG utilizzano l'autenticazione Kerberos tra server Exchange. I servizi Microsoft Kerberos SSP (Security Support Provider) e i servizi API EncryptMessage e DecryptMessage gestiscono la crittografia del traffico della rete DAG. Microsoft Kerberos SSP supporta più algoritmi di crittografia. Per un elenco completo, vedere la sezione 3.1.5.2, "Tipi di crittografia" dell'articolo sulle estensioni del protocollo Kerberos. L'handshake di autenticazione Kerberos seleziona il protocollo di crittografia più forte supportato nell'elenco: generalmente Advanced Encryption Standard (AES) a 256 bit, eventualmente con un codice HMAC (SHA Hash-based Message Authentication Code) per mantenere l'integrità dei dati archiviati. Per informazioni dettagliate, vedere HMAC.

La crittografia di rete è una proprietà del DAG e non di una rete del DAG. È possibile configurare la crittografia di rete del DAG utilizzando il cmdlet Set-DatabaseAvailabilityGroup in Shell. Le possibili impostazioni di crittografia per le comunicazioni di rete del DAG sono elencate nella seguente tabella.

Impostazioni di crittografia per le comunicazioni di rete del DAG

Impostazione	Descrizione
Disabilitata	Non viene utilizzata la crittografia di rete.
Abilitata	La crittografia di rete viene utilizzata per la replica e il seeding su tutte le reti del DAG.
InterSubnetOnly	Viene utilizzata la crittografia di rete sulle reti del DAG durante la replica su differenti subnet. Questa impostazione è quella predefinita.
SeedOnly	Viene utilizzata la crittografia di rete su tutte le reti DAG solo per il seeding.

Compressione di rete del DAG

I DAG supportano la compressione incorporata. Quando la compressione viene abilitata, la comunicazione di rete del DAG utilizza XPRESS, che è l'implementazione Microsoft dell'algoritmo LZ77. Per ulteriori informazioni, vedere la spiegazione dell'algoritmo Deflate e la sezione 3.1.7.2, "Algoritmo di compressione", dell'articolo sulle specifiche del protocollo di formato wire. Questo è lo stesso tipo di compressione utilizzato in molti protocolli Microsoft, in particolare, compressione RPC MAPI tra Microsoft Outlook e Exchange.

Come nel caso della crittografia di rete, la compressione della rete è anche una proprietà del DAG e non di una rete del DAG. È possibile configurare la compressione di rete del DAG utilizzando il cmdlet Set-DatabaseAvailabilityGroup in Shell. Le possibili impostazioni di compressione per le comunicazioni di rete del DAG sono elencate nella seguente tabella.

Impostazioni di compressione per le comunicazioni di rete del DAG

Impostazione	Descrizione
Disabilitato	Non viene utilizzata la compressione di rete.
Enabled	La compressione di rete viene utilizzata per la replica e il seeding su tutte le reti del DAG.
InterSubnetOnly	Viene utilizzata la compressione di rete sulle reti del DAG durante la replica su differenti subnet. Questa impostazione è quella predefinita.
SeedOnly	Viene utilizzata la compressione di rete su tutte le reti del DAG solo per il seeding.

Inizio pagina

Reti del DAG

Una rete del DAG è un insieme di una o più subnet utilizzato sia per il traffico di replica che per il traffico MAPI. Ciascun DAG contiene al massimo una rete MAPI e zero o più reti di replica. Nella configurazione di una singola scheda di rete, la rete viene utilizzata per il traffico di replica e MAPI. Sebbene siano supportati una sola scheda e un solo percorso di rete, si consiglia di fare in modo che ciascun DAG abbia almeno due reti. In una configurazione a due reti, una rete è in genere dedicata al traffico di replica e l'altra rete è utilizzata principalmente per il traffico MAPI. È anche possibile aggiungere schede di rete a ciascun membro del DAG e configurare reti del DAG aggiuntive come reti di replica.

È possibile utilizzare la procedura guidata relativa alla creazione di una nuova rete del gruppo di disponibilità del database in EMC o il cmdlet New-DatabaseAvailabilityGroupNetwork in Shell per creare una rete del DAG. Per la procedura dettagliata sulla creazione di una rete DAG, vedere Creazione di una rete del gruppo di disponibilità del database.

È possibile utilizzare la finestra di dialogo Proprietà della rete del DAG in EMC o il cmdlet Set-DatabaseAvailabilityGroupNetwork in Shell per configurare le proprietà della rete del DAG. Per la procedura dettagliata sulla configurazione delle proprietà della rete DAG, vedere Configurazione delle proprietà di rete del gruppo di disponibilità del database. Ciascuna rete del DAG prevede dei parametri obbligatori e facoltativi per configurare quanto segue:

• Nome rete   Un nome univoco per la rete del DAG con un massimo di 128 caratteri.

• Descrizione rete   Una descrizione facoltativa per la rete del DAG con un massimo di 256 caratteri.

• Subnet di rete   Una o più subnet specificate utilizzando il formato IndirizzoIP/Maschera di bit (ad esempio, 192.168.1.0/24 per le subnet IPv4; 2001:DB8:0:C000::/64 per le subnet IPv6).

• Abilita replica   In EMC, selezionare la casella di controllo per dedicare la rete del DAG al traffico di replica e bloccare il traffico MAPI. Deselezionare la casella di controllo per impedire alla replica di utilizzare la rete del DAG e abilitare il traffico MAPI. In Shell, utilizzare il parametro ReplicationEnabled nel cmdlet Set-DatabaseAvailabilityGroupNetwork per abilitare o disabilitare la replica.

Le reti DAG iniziali (ad esempio, DAGNetwork01 e DAGNetwork02) create dal sistema si basano sulle subnet enumerate dal servizio Cluster. Ciascun membro DAG deve avere lo stesso numero di schede di rete e ciascuna scheda di rete deve disporre di un indirizzo IPv4 (e, opzionalmente, anche di un indirizzo IPv6) su una subnet univoca. Più membri DAG possono disporre di indirizzi IPv4 sulla stessa subnet, ma ciascuna scheda di rete e una coppia di indirizzi IP in un determinato membro DAG devono trovarsi su una subnet univoca. Inoltre, solo la scheda utilizzate per la rete MAPI deve essere configurata con un gateway predefinito. Le reti di replica non devono essere configurate con un gateway predefinito.

Ad esempio, considerare DAG1, un DAG con due membri in cui ciascun membro dispone di due schede di rete (una dedicata alla rete MAPI e l'altra alla rete di replica). Nella tabella seguente, sono riportati esempi di impostazioni di configurazioni di indirizzi IP.

Esempi di impostazioni delle schede di rete

Server-scheda di rete	Indirizzo IP/subnet mask	Gateway predefinito
EX1-MAPI	192.168.1.15/24	192.168.1.1
EX1-Replica	10.0.0.15/24	Non applicabile
EX2-MAPI	192.168.1.16	192.168.1.1
EX2-Replica	10.0.0.16	Non applicabile

Nella seguente configurazione, sono disponibili due subnet configurate nel DAG: 192.168.1.0 e 10.0.0.0. Quando EX1 ed EX2 vengono aggiunte al DAG, verranno enumerate due subnet e verranno create due reti DAG: DAGNetwork01 (192.168.1.0) e DAGNetwork02 (10.0.0.0). Tali reti verranno configurate come indicata nella tabella seguente.

Impostazioni reti DAG enumerate per un DAG con una singola subnet

Nome	Subnet	Interfacce	Accesso MAPI abilitato	Replica abilitata
DAGNetwork01	192.168.1.0/24	EX1 (192.168.1.15) EX2 (192.168.1.16)	True	True
DAGNetwork02	10.0.0.0/24	EX1 (10.0.0.15) EX2 (10.0.0.16)	False	True

Per completare la configurazione di DAGNetwork02 come rete di replica dedicata, disabilitare la replica per DAGNetwork01 utilizzando il seguente comando.

Set-DatabaseAvailabilityGroupNetwork -Identity DAG1\DAGNetwork01 -ReplicationEnabled:$false

Una volta disabilitata la replica per DAGNetwork01, il servizio di replica di Microsoft Exchange utilizza DAGNetwork02 per la replica continua. Se DAGNetwork02 rileva un errore, il servizio di replica di Microsoft Exchange reimposta l'utilizzo di DAGNetwork01 per la replica continua. Tale operazione viene eseguita intenzionalmente dal sistema al fine di mantenere una disponibilità elevata.

Reti DAG e distribuzioni di più subnet

Nell'esempio precedente, anche se il DAG utilizza due subnet differenti DAG (192.168.1.0 e 10.0.0.0), il DAG viene considerato un DAG con una singola subnet, in quanto ciascun membro utilizza la stessa subnet per creare la rete MAPI. Quando i membri del DAG utilizzano subnet differenti per la rete MAPI, il DAG viene considerato come un DAG a più subnet. In un DAG a più subnet, è necessario eseguire una configurazione aggiuntiva delle reti DAG per associare le subnet appropriate a ciascuna rete DAG.

Ad esempio, considerare DAG2, un DAG con due membri in cui ciascun membro dispone di due schede di rete (una dedicata alla rete MAPI e l'altra alla rete di replica) e ciascun membro del DAG si trova in un sito Active Directory distinto, con la relativa rete MAPI su una subnet differente. Nella tabella seguente, sono riportati esempi di impostazioni di configurazioni di indirizzi IP.

Esempio di impostazioni di schede di rete per un DAG a più subnet

Server-scheda di rete	Indirizzo IP/subnet mask	Gateway predefinito
EX1-MAPI	192.168.0.15/24	192.168.0.1
EX1-Replica	10.0.0.15/24	Non applicabile
EX2-MAPI	192.168.1.15	192.168.1.1
EX2-Replica	10.0.1.15	Non applicabile

Nella seguente configurazione, sono disponibili quattro subnet configurate nel DAG: 192.168.0.0, 192.168.1.0, 10.0.0.0 e 10.0.1.0. Quando EX1 ed EX2 vengono aggiunte al DAG, verranno enumerate quattro subnet e verranno create due reti DAG: DAGNetwork01 (192.168.0.0), DAGNetwork02 (10.0.0.0), DAGNetwork03 (192.168.1.0) e DAGNetwork04 (10.0.1.0). Tali reti verranno configurate come indicata nella tabella seguente.

Impostazioni reti DAG enumerate per un DAG a più subnet

Name	Subnet	Interfacce	Accesso MAPI abilitato	Replica abilitata
DAGNetwork01	192.168.0.0/24	EX1 (192.168.0.15)	True	True
DAGNetwork02	10.0.0.0/24	EX1 (10.0.0.15)	False	True
DAGNetwork03	192.168.1.0/24	EX2 (192.168.1.15)	True	True
DAGNetwork04	10.0.1.0/24	EX2 (10.0.1.15)	False	True

Per completare la configurazione necessaria, DAGNetwork03 e DAGNetwork04 devono essere rispettivamente compresse in DAGNetwork01 e DAGNetwork02. Ciò implica l'aggiunta della subnet attualmente associata a DAGNetwork03 in DAGNetwork01 e l'aggiunta della subnet attualmente associata a DAGNetwork04 in DAGNetwork02. In questo modo, verranno rimosse le associazioni di subnet da DAGNetwork03 e DAGNetwork04 che verranno lasciate come reti DAG vuote che possono essere, quindi, rimosse. Per comprimere le subnet in due reti DAG e disabilitare la replica sulla rete MAPI, utilizzare i seguenti comandi.

Set-DatabaseAvailabilityGroupNetwork -Identity DAG2\DAGNetwork01 -Subnets 192.168.0.0,192.168.1.0 -ReplicationEnabled:$false
Set-DatabaseAvailabilityGroupNetwork -Identity DAG2\DAGNetwork02 -Subnets 10.0.0.0,10.0.1.0
Remove-DatabaseAvailabilityGroupNetwork -Identity DAG2\DAGNetwork03
Remove-DatabaseAvailabilityGroupNetwork -Identity DAG2\DAGNetwork04

Reti del DAG e reti iSCSI

Per impostazione predefinita, i DAG eseguono l'individuazione di tutte le reti rilevate e configurate per l'utilizzo da parte del cluster sottostante. Ciò include qualsiasi rete Internet SCSI (iSCSI) in uso a seguito dell'utilizzo dell'archiviazione iSCSI per uno o più membri del DAG. Secondo la procedura consigliata, l'archiviazione iSCSI deve utilizzare reti e schede di rete dedicate. Queste reti non devono essere gestite dal DAG o dal suo cluster oppure utilizzate come reti del DAG (MAPI o di replica). Al contrario, il loro utilizzo da parte del DAG deve essere disabilitato manualmente, in modo che possano essere dedicate al traffico dell'archiviazione iSCSI. Per disabilitare il rilevamento e l'utilizzo di reti iSCSI come reti DAG, configurare il gruppo di disponibilità per ignorare qualsiasi rete iSCSI attualmente rilevata utilizzando il cmdlet Set-DatabaseAvailabilityGroupNetwork, come mostrato in questo esempio:

Set-DatabaseAvailabilityGroupNetwork -Identity DAG2\DAGNetwork02 -ReplicationEnabled:$false -IgnoreNetwork:$true

Questo comando disabiliterà la rete anche per l'utilizzo da parte del cluster. Sebbene le reti iSCSI continueranno ad apparire come reti DAG, non verranno utilizzate per MAPI o traffico di replica dopo l'esecuzione del comando precedente.

Inizio pagina

Configurazione di membri DAG

I server Cassette postali che sono membri di un DAG dispongono di proprietà specifiche per una disponibilità elevata che dovrebbero essere configurate come descritto nelle seguenti sezioni:

• Dial di montaggio automatico del database

• Criterio di attivazione automatica della copia del database

• Numero massimo di database attivi

Dial di montaggio automatico del database

Il parametro AutoDatabaseMountDial indica il comportamento per l'installazione automatica del database dopo un failover del database. È possibile utilizzare il cmdlet Set-MailboxServer per configurare il parametro AutoDatabaseMountDial con uno qualsiasi dei seguenti valori:

• BestAvailability   Se si specifica questo valore, il database viene installato automaticamente subito dopo il failover, se la lunghezza della coda delle copie è minore o uguale a 12. La lunghezza della coda delle copie indica il numero di registri riconosciuti dalla copia passiva che è necessario replicare. Se la lunghezza della coda delle copie è maggiore di 12, il database non viene installato automaticamente. Quando la lunghezza della coda delle copie è minore o uguale a 12, Exchange tenta di replicare i registri rimanenti sulla copia passiva e installa il database.

• GoodAvailability   Se si specifica questo valore, il database viene installato automaticamente dopo il failover, se la lunghezza della coda delle copie è minore o uguale a sei. La lunghezza della coda delle copie indica il numero di registri riconosciuti dalla copia passiva che è necessario replicare. Se la lunghezza della coda delle copie è maggiore di sei, il database non viene installato automaticamente. Quando la lunghezza della coda delle copie è minore o uguale a sei, Exchange tenta di replicare i registri rimanenti sulla copia passiva e installa il database.

• Lossless   Se si specifica questo valore, il database non viene installato automaticamente fino a quando tutti i registri generati sulla copia attiva non sono stati copiati sulla copia passiva. Inoltre, tale impostazione fa sì che l'algoritmo di selezione delle copie migliori ordini potenziali candidati per l'attivazione in base al valore di preferenza dell'attivazione della copia del database e non alla lunghezza della relativa coda delle copie.

Il valore predefinito è GoodAvailability. Se si specifica BestAvailability o GoodAvailability e non sono stati replicati sulla copia passiva tutti i registri della copia attiva, si rischia di perdere dei dati delle cassette postali. Tuttavia, la funzionalità del dumpster del trasporto (abilitata per impostazione predefinita) è un valido aiuto contro la perdite dei dati perché reinvia i messaggi che si trovano nella coda del dumpster del trasporto.

Oltre ai valori precedenti, è anche possibile configurare il parametro AutoDatabaseMountDial con un valore personalizzato utilizzando ADSI Edit o Ldp.exe per modificare l'attributo direttamente in Active Directory. Il parametro AutoDatabaseMountDial è rappresentato dall'attributo msExchDataLossForAutoDatabaseMount dell'oggetto server Cassette postali. Il valore numerico intero per questo attributo rappresenta il numero massimo di file di registro delle transazioni che si è disposti a perdere nell'installazione di un database senza intervento umano. Se si configura il parametro AutoDatabaseMountDial con un valore personalizzato maggiore di 12, si consiglia anche di aumentare le dimensioni del dumpster di trasporto per abilitare una protezione maggiore per evitare una quantità maggiore di perdite dei registri.

Esempio: Configurazione del dial di montaggio automatico del database

Il seguente esempio configura un server Cassette postali con un'impostazione AutoDatabaseMountDial di GoodAvailability.

Set-MailboxServer -Identity EX1 -AutoDatabaseMountDial GoodAvailability

Criterio di attivazione automatica della copia del database

Il parametro DatabaseCopyAutoActivationPolicy consente di specificare il tipo di attivazione automatica disponibile per le copie del database delle cassette postali sui server Cassette postali selezionati. È possibile utilizzare il cmdlet Set-MailboxServer per configurare il parametro DatabaseCopyAutoActivationPolicy con uno qualsiasi dei seguenti valori:

• Blocked   Se si specifica questo valore, non è possibile attivare automaticamente i database sui server Cassette postali selezionati.

• IntrasiteOnly   Se si specifica questo valore, è possibile attivare la copia del database sui server dello stesso sito Active Directory. In questo modo si evita l'attivazione o il failover tra siti. Questa proprietà vale per le copie del database delle cassette postali in arrivo (ad esempio, una copia passiva che viene resa attiva). I database non possono essere attivati su questo server Cassette postali per le copie del database che sono attive in un altro sito Active Directory.

• Unrestricted   Se si specifica questo valore, non sono presenti limitazioni particolari per quanto riguarda l'attivazione delle copie del database delle cassette postali sui server Cassette postali selezionati.

Esempio: Configurazione del criterio di attivazione automatica della copia del database

Nel seguente esempio, viene configurato un server Cassette postali con un'impostazione DatabaseCopyAutoActivationPolicy di Blocked.

Set-MailboxServer -Identity EX1 -DatabaseCopyAutoActivationPolicy Blocked

Numero massimo di database attivi

Il parametro MaximumActiveDatabases (utilizzato anche con il cmdlet Set-MailboxServer) indica il numero di database che possono essere installati su un server Cassette postali. È possibile configurare i server Cassette postali per soddisfare i requisiti di distribuzione accertandosi di non sovraccaricare il server Cassette postali.

Il parametro MaximumActiveDatabasesviene configurato con un valore numerico intero. Una volta raggiunto il valore massimo, le copie del database sul server non vengono attivate se si verifica un failover o un passaggio. Se le copie sono già attivate sul server, questo non consente l'installazione dei database.

Esempio: Configurazione del numero massimo di database attivi

Nell'esempio seguente viene configurato un server Cassette postali per supportare un massimo di 20 database attivi.

Set-MailboxServer -Identity EX1 -MaximumActiveDatabases 20

Inizio pagina

Esecuzione della manutenzione sui membri DAG

Prima di eseguire qualsiasi tipo di manutenzione software o hardware su un membro DAG, è necessario rimuovere prima il membro DAG dal servizio utilizzando lo script StartDagServerMaintenance.ps1. Questo script sposta tutti i database attivi all'esterno del server e fa sì che i database attivi non vengano spostati in quel server. Lo script garantisce anche che tutte le funzionalità di supporto del DAG principali che potrebbero trovarsi sul server (ad esempio, il ruolo Active Manager primario (PAM)) vengano spostate su un altro server e non vengano nuovamente spostate nel server. In modo specifico, lo script StartDagServerMaintenance.ps1 esegue le seguenti attività:

• Esecuzione di Suspend-MailboxDatabaseCopy con il parametro ActivationOnly per sospendere ogni copia del database ospitata in un membro del gruppo di disponibilità per l'attivazione.

• Sospende il nodo nel cluster, evitando che si trasformi nel PAM.

• Imposta il valore del parametro DatabaseCopyAutoActivationPolicy nel membro DAG su Blocked.

• Sposta tutti i database attivi attualmente ospitati nel membro DAG in altri membri DAG.

• Se il membro DAG possiede attualmente il gruppo cluster predefinito, lo script sposta il gruppo cluster predefinito (e, quindi, il ruolo PAM) in un altro membro DAG.

In caso di errore di una qualsiasi delle attività precedenti, tutte le operazioni, ad eccezione degli spostamenti del database portati a termine, risultano non eseguite.

Una volta che la manutenzione è stata completata e il membro DAG è pronto per il ripristino del servizio, è possibile utilizzare lo script StopDagServerMaintenance.ps1 per disattivare la modalità di manutenzione per il membro DAG e rimetterlo in produzione. In modo specifico, lo script StopDagServerMaintenance.ps1 esegue le seguenti attività:

• Esegue il cmdlet Resume-MailboxDatabaseCopy per ciascuna copia del database ospitata nel membro del DAG.

• Ripristina il nodo nel cluster abilitando la funzionalità dei cluster completa per il membro del DAG.

• Imposta il valore del parametro DatabaseCopyAutoActivationPolicy nel membro DAG su Unrestricted.

Entrambi gli script accettano il parametro -ServerName (che può essere il nome host o il nome di dominio completo (FQDN) del membro DAG) e il parametro -WhatIf. Entrambi gli script possono essere eseguiti localmente o in remoto. È necessario che sul server su cui vengono eseguiti gli script siano installati gli strumenti Gestione cluster di failover (RSAT-Clustering) di Windows.

Inizio pagina

Chiusura dei membri DAG

La soluzione ad elevata disponibilità Exchange 2010 è integrata con la procedura di chiusura di Windows. Se un amministratore o un'applicazione avvia la chiusura di un server Windows in un DAG che dispone di un database replicato in uno o più membri DAG, il sistema cerca di attivare un'altra copia del database installato prima di permettere il completamento della procedura di chiusura.

Tuttavia, questo nuovo comportamento non garantisce un'attivazione lossless per tutti i database sul server in chiusura. Di conseguenza, la procedura consigliata prevede di eseguire uno switchover del server prima di arrestare un server membro di un gruppo di disponibilità del database. Per ulteriori informazioni sull'esecuzione di uno switchover del server, vedere Esecuzione del passaggio di un server.

Inizio pagina

Installazione di aggiornamenti cumulativi sui membri DAG

L'installazione degli aggiornamenti cumulativi di Microsoft Exchange Server 2010 su un server che è membro di un DAG è un'operazione relativamente semplice. Quando si installa un aggiornamento cumulativo su un server che è membro di un DAG, numerosi servizi verranno arrestati durante l'installazione, compresi tutti i servizi di Exchange e il servizio cluster. La procedura generica per l'applicazione degli aggiornamenti cumulativi a un membro del DAG è la seguente:

1. Utilizzare lo script StartDagServerMaintenance.ps1 per attivare la modalità di manutenzione per un membro DAG.

2. Installare l'aggiornamento cumulativo.

3. Utilizzare lo script StopDagServerMaintenance.ps1 per disattivare la modalità di manutenzione per il membro DAG e rimetterlo in produzione.

4. Utilizzare lo script RedistributeActiveDatabases.ps1 per ridistribuire le copie del database attive lungo il DAG.

È possibile scaricare l'aggiornamento cumulativo più recente per Exchange 2010 da Area download Microsoft. Per la procedura dettagliata sull'installazione di un aggiornamento cumulativo su un membro DAG, vedere Installazione degli aggiornamenti cumulativi sui membri del gruppo di disponibilità del database (DAG).

Inizio pagina

 ©2010 Microsoft Corporation. Tutti i diritti riservati.