Gestione dei gruppi di disponibilità del database

Si applica a: Exchange Server 2010

Ultima modifica dell'argomento: 2010-01-25

Un gruppo di disponibilità del database (DAG) è un insieme di 16 server Cassette postali Microsoft Exchange Server 2010 che fornisce il ripristino automatico da un errore a livello di database, server o rete. I DAG utilizzano la replica continua ed un sottogruppo di tecnologie clustering di failover di Windows  per fornire la disponibilità continua delle cassette postali. I server Cassette postali di un DAG 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 viene creato un DAG, che inizialmente è vuoto, in Active Directory viene creato un oggetto di 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 dei gruppi di disponibilità del database (DAG)

Appartenenza al gruppo di disponibilità del database (DAG)

Configurazione delle proprietà del gruppo di disponibilità del database (DAG)

Reti del gruppo di disponibilità del database (DAG)

Chiusura dei membri del gruppo di disponibilità del database (DAG)

Installazione degli aggiornamenti cumulativi per i membri del gruppo di disponibilità del database

Creazione dei gruppi di disponibilità del database (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 DatabaseAvailablityGroupIpAddresses. Se si omette questo parametro, il DAG tenterà 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 DAG utilizzano un sottogruppo di tecnologie clustering di failover di Windows, ad esempio, heartbeat cluster, reti cluster e database cluster (per archiviare dati che cambiano o che possono cambiare rapidamente, ad esempio, lo stato del database che cambia da attivo a passivo o viceversa oppure da installato a non installato o viceversa). Poiché i DAG si basano sul clustering di failover di Windows, possono essere creati solo sui server Cassette postali di Exchange 2010 in cui è installato il sistema operativo Windows Server 2008 Enterprise o Windows Server 2008 R2 Enterprise.

Server e directory di controllo del gruppo di disponibilità del database (DAG)

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 DAG contiene un numero pari di membri. Non è necessario creare la directory di controllo in anticipo. Exchange creerà e proteggerà 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.
• Sul server di controllo deve essere in esecuzione Windows Server 2008 R2, Windows Server 2008, Windows Server 2003 R2 o Windows Server 2003.
• Un singolo server può svolgere la funzione di controllo per più DAG; tuttavia, ogni DAG richiede una propria directory di controllo.

Si consiglia di utilizzare un server Trasporto Hub di Exchange 2010 nel sito di Active Directory contenente il DAG. Ciò consente al server e alla directory di controllo di rimanere sotto il controllo di un amministratore di Exchange.

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 del cluster per il server di controllo o impiegare qualunque altra forma di resilienza per il server di controllo. Ciò è dovuto a diversi motivi. Con i DAG più grandi (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 server senza perdere il quorum, devono verificarsi almeno tre errori dei membri prima che insorga la necessità di un intervento del server di controllo. Inoltre, se si verifica un errore che riguarda il 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. Facoltativamente, è 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\<FQDNDAG>) e la condivisione predefinita (<FQDNDAG>) su quel server Trasporto Hub che verrà utilizzato come server di controllo. Ad esempio, prendere in considerazione un server di controllo chiamato EXMBX3 su cui il sistema operativo è stato installato sull'unità C. Un DAG denominato DAG1 nel dominio contoso.com utilizzerebbe la directory di controllo predefinita C:\DAGFileShareWitnesses\DAG1.contoso.com, che potrebbe essere condivisa con il nome \\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 creerà 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 cercherà un server Trasporto Hub su cui non è installato il ruolo del server Cassette postali e creerà automaticamente il DAG specificato su quel server, condividerà la directory e utilizzerà il server Trasporto Hub come server di controllo.

Quando viene costituito un DAG, inizialmente viene utilizzato 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 di rete cluster del DAG.

Se Windows Firewall è abilitato sul server di controllo prima che il DAG venga creato, 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, verrà restituito l'errore seguente:

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, verrà visualizzato l'avviso seguente:

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 è abilitato sul server di controllo dopo aver creato il DAG ma prima che i server vengano aggiunti, 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 visualizzerà l'avviso seguente:

Impossibile creare la directory di controllo di condivisione file 'C:\DAGFileShareWitnesses\FQDN_DAG' 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 in precedenza la directory di controllo e la condivisione sul server di controllo
• Abilitare l'eccezione WMI in Windows Firewall
• Disabilitare Windows Firewall

Inizio pagina

Appartenenza al gruppo di disponibilità del database (DAG)

Dopo aver 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 i cmdlet Add-DatabaseAvailbilityGroupServer o Remove-DatabaseAvailbilityGroupServer 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.
• Un oggetto di rete cluster viene creato nel contenitore di computer predefinito.
• Il nome e l'indirizzo IP del DAG vengono registrati come record Host (A) nel DNS.
• 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 grandi dimensioni 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ò perché l'oggetto DAG apparirà vuoto dal punto di vista del secondo membro aggiunto. Di conseguenza il cmdlet Add-DatabaseAvailabilityGroupServer creerà un nuovo cluster e oggetto di rete cluster per il DAG, anche se questi oggetti già esistono. Per verificare che l'oggetto DAG contenente il primo server DAG è 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 di rete cluster per un gruppo di disponibilità del database

L'oggetto di rete cluster è un account del computer creato in Active Directory e associato alla risorsa del nome 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.

Come specificato in precedenza, la creazione del cluster sottostante al DAG e dell'oggetto di rete 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à 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 l'oggetto di rete cluster, quindi:

• Assegnare il controllo completo dell'account computer all'account computer della prima cassetta postale che si aggiunge al gruppo di disponibilità del database.
• 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 della prima cassetta postale che si sta aggiungendo 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 del computer al gruppo di protezione universale Exchange Trusted Subsystem perché tale gruppo 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 Predisporre l'oggetto rete cluster per un gruppo di disponibilità del database.

Rimozione dei server da un gruppo di disponibilità del database (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-DatabaseAvailbilityGroupServer 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 verrà 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 un'operazione di ripristino, è necessario rimuovere prima 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 che contiene uno o più membri, l'operazione non verrà completata.

Inizio pagina

Configurazione delle proprietà del gruppo di disponibilità del database (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 relativa alla configurazione delle proprietà del gruppo di disponibilità del database, vedere Configurazione delle proprietà del gruppo di disponibilità del database.

Crittografia di rete del gruppo di disponibilità del database (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 i server Exchange. Le API EncryptMessage/DecryptMessage di Microsoft Kerberos SSP (Security Support Provider) gestiscono la crittografia del traffico di rete nel DAG. Microsoft Kerberos SSP supporta più algoritmi di crittografia. Per l'elenco completo, vedere la sezione di riferimento 3.1.5.2, "Tipi di crittografia" di Estensioni del protocollo Kerberos. L'autenticazione Kerberos tramite handshake 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.
SeedOnly	Viene utilizzata la crittografia di rete su tutte le reti DAG solo per il seeding.

Compressione di rete del gruppo di disponibilità del database (DAG)

I DAG supportano inoltre 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 Algoritmo LZ77 e la sezione 3.1.7.2, "Algoritmo di compressione" di 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 la 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
Disabilitata	Non viene utilizzata la compressione di rete.
Abilitata	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.
SeedOnly	Viene utilizzata la compressione di rete su tutte le reti del DAG solo per il seeding.

Inizio pagina

Reti del gruppo di disponibilità del database (DAG)

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. Una rete del DAG è un insieme di una o più subnet utilizzato sia per il traffico di replica che per il traffico MAPI. 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. È possibile creare reti aggiuntive in un DAG e configurarle come reti di replica per ridondanza.

È 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 informazioni dettagliate relative alla creazione di una rete del 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 relativa alla configurazione delle proprietà della rete del 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.

Reti del DAG e reti iSCSI

Per impostazione predefinita, i DAG eseguiranno 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 interfaccia 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 la rilevazione delle reti iSCSI e impedire il loro utilizzo come reti del DAG sono necessarie due operazioni:

1. Configurare il DAG in modo che ignori tutte le reti iSCSI attualmente rilevate utilizzando il cmdlet Set-DatabaseAvailabilityGroupNetwork, come mostrato in questo esempio.

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

2. Disabilitare la rete per impedirne l'utilizzo da parte del cluster utilizzando il seguente comando da un prompt dei comandi con privilegi avanzati o dalla finestra PowerShell. Eseguire Cluster network per visualizzare i nomi delle reti del cluster.

   Cluster network ClusterNetworkName /prop Role=0
   

Dopo aver disabilitato tutte le reti iSCSI per l'utilizzo da parte del DAG e del suo cluster, è possibile facoltativamente forzare l'individuazione della rete eseguendo il cmdlet Set-DatabaseAvailabilityGroup con il parametro DiscoverNetworks. Se una qualsiasi rete iSCSI rimane visualizzata come rete del DAG, rimuovere tutte le subnet dalla rete e quindi eliminare la rete del DAG.

Inizio pagina

Chiusura dei membri del gruppo di disponibilità del database (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 del 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 che tutti i database sul server in chiusura saranno perfettamente integri una volta riavviati. 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 la procedura dettagliata relativa all'esecuzione di uno switchover del server, vedere Esecuzione del passaggio di un server.

Inizio pagina

Installazione degli aggiornamenti cumulativi sui membri del gruppo di disponibilità del database (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 di Windows. La procedura generica per l'applicazione degli aggiornamenti cumulativi a un membro del DAG è la seguente:

• Eseguire lo switchover del server in modo che tutti i suoi database diventino copie passive.
• Sospendere l'attivazione dei database sul server da aggiornare.
• Installare l'aggiornamento cumulativo.
• Riprendere l'attivazione dei database sul server aggiornato.
• Eseguire gli switchover dei database in base alle esigenze.

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

Inizio pagina