Condividi tramite

Gestire i gruppi di disponibilità del database in Exchange Server

  • Articolo

Un gruppo di disponibilità del database (DAG) è un set di fino a 16 server Cassette postali di Exchange che consentono il ripristino automatico a livello di database da un errore di database/server/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 gruppo di disponibilità del database, tale server funziona con gli altri server del gruppo di disponibilità del database per fornire il ripristino automatico a livello di database dagli errori del database.

Al momento della creazione, un DAG è vuoto. 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 del cluster di failover e il database del cluster vengono quindi usati per tenere traccia e gestire le informazioni sul gruppo di disponibilità del database che possono cambiare rapidamente, ad esempio lo stato di montaggio del database, lo stato della replica e la posizione dell'ultimo montaggio.

Creazione di DAG

È possibile creare un gruppo di disponibilità del database usando la procedura guidata Nuovo gruppo di disponibilità database nell'interfaccia di amministrazione di Exchange o eseguendo il cmdlet New-DatabaseAvailabilityGroup in Exchange Management Shell. Quando si crea un gruppo di disponibilità del database, si specifica un nome per il gruppo di disponibilità del database e le impostazioni facoltative del server di controllo e della directory di controllo. Inoltre, è possibile assegnare uno o più indirizzi IP 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 usando il parametro DatabaseAvailabilityGroupIpAddresses . Se si omette questo parametro, il DAG tenta di ottenere un indirizzo IP utilizzando un server DHCP della rete.

Se si sta creando un gruppo di disponibilità del database che conterrà i server Cassette postali che eseguono Windows Server 2012 R2, è anche possibile creare un gruppo di disponibilità del database senza un punto di accesso amministrativo del cluster. In questo caso, il cluster non avrà un oggetto nome cluster (CNO) in Active Directory e il gruppo di risorse di base del cluster non conterrà una risorsa nome di rete o una risorsa indirizzo IP.

Per i passaggi dettagliati su come creare un gruppo di disponibilità del database, vedere Creare un gruppo di disponibilità del database.

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

I dag usano un subset di tecnologie di clustering di failover di Windows in Windows Server 2008 R2 o versioni successive, ad esempio l'heartbeat del cluster, le reti cluster e il database del cluster (per archiviare dati che cambiano o possono cambiare rapidamente, ad esempio le modifiche dello stato del database da attivo a passivo o inverso o da montato a smontato o inverso). Pertanto, è possibile creare dag solo nei server Cassette postali di Exchange installati nelle versioni supportate di Windows che includono il clustering di failover di Windows.

Nota

Il cluster di failover creato e utilizzato dal DAG deve essere dedicato al DAG. Il cluster non può essere utilizzato per altre soluzioni a elevata disponibilità o per altri scopi. Ad esempio, il cluster di failover non può essere utilizzato per il cluster di altre applicazioni o servizi. L'uso di un cluster di failover del DAG specifico per scopi diversi dal DAG non è supportato.

Server di controllo DAG e Directory di controllo

Quando si crea un dag, è necessario specificare un nome per il dag non più di 15 caratteri univoci all'interno della foresta di Active Directory. Inoltre, ciascun DAG viene configurato con un server e una directory di controllo. Il server di controllo del mirroring e la relativa directory vengono usati solo quando è presente un numero pari di membri nel gruppo di disponibilità del database e solo a scopo quorum. Non è necessario creare la directory di controllo in anticipo. Exchange crea e protegge automaticamente la directory sul server di controllo. La directory di controllo del mirroring non deve essere usata per scopi diversi dal server di controllo del dag.

Nota

Nella topologia di mirroring del database è possibile avere un terzo server denominato "server di controllo del mirroring". Il server di controllo del mirroring abilita il failover automatico dall'entità al server mirror o viceversa. A differenza dei server principal e mirror, il server di controllo di controllo non serve il database. Il ruolo del server di controllo del mirroring consiste nel verificare se un determinato server partner è attivo e funzionante. Il supporto del failover automatico è l'unica funzione per il server di controllo del mirroring e identifica quale server contiene la copia principale e quale server contiene la copia mirror del database.

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 del mirroring deve eseguire Windows Server 2008 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.

Indipendentemente dal server usato come server di controllo del mirroring, se Windows Firewall è abilitato nel server di controllo del mirroring previsto, è necessario abilitare l'eccezione di Windows Firewall per Condivisione file e stampanti. Il server di controllo del mirroring usa la porta SMB 445.

Importante

Se il server di controllo di controllo specificato non è un server Exchange 2010 o versione successiva, è necessario aggiungere il gruppo di sicurezza universale del sottosistema attendibile di Exchange al gruppo Administrators locale nel server di controllo prima di creare il gruppo di disponibilità dati. Queste autorizzazioni di sicurezza sono necessarie per garantire che Exchange possa creare una directory e condividerla sul server di controllo in base alle necessità.

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

Nota

È inoltre possibile utilizzare il cmdlet Set-DatabaseAvailabilityGroup per configurare il server e la directory di controllo nel percorso originario se il server di controllo ha perso i dati in archivio o se qualcuno ha modificato le autorizzazioni di condivisione o la directory di controllo.

Considerazioni sulla collocazione dei server di controllo

La collocazione del server di controllo di un DAG dipende dai requisiti aziendali e dalle opzioni disponibili nell'organizzazione. Exchange include ora il supporto per le nuove opzioni di configurazione del gruppo di disponibilità del database che non sono consigliate o non sono possibili in Exchange 2010. Queste opzioni includono l'uso di una terza posizione, ad esempio un terzo data center, una succursale o una rete virtuale di Microsoft Azure.

Nella tabella seguente sono elencate raccomandazioni generali sulla collocazione del server di controllo per diversi scenari di distribuzione.

Scenario di distribuzione Suggerimenti
Singolo DAG distribuito in un singolo datacenter Collocare il server di controllo nello stesso datacenter dei membri del DAG
Singolo DAG distribuito tra due datacenter, senza ulteriori posizioni disponibili Individuare il server di controllo in una rete virtuale di Microsoft Azure per abilitare il failover automatico del data center oppure

Collocare il server di controllo nel datacenter principale
Più DAG distribuiti in un singolo datacenter Collocare il server di controllo nello stesso datacenter dei membri del DAG. Altre opzioni sono:
  • Utilizzo dello stesso server di controllo per più DAG
  • Utilizzo di un membro del DAG come server di controllo di un altro DAG
Più DAG distribuiti tra due datacenter Individuare il server di controllo in una rete virtuale di Microsoft Azure per abilitare il failover automatico del data center oppure

Collocare il server di controllo nel datacenter considerato principale per ciascun DAG. Altre opzioni sono:

  • Utilizzo dello stesso server di controllo per più DAG
  • Utilizzo di un membro del DAG come server di controllo di un altro DAG
Singolo DAG o più DAG distribuiti tra più di due datacenter In questa configurazione, il server di controllo deve essere collocato nel datacenter in cui deve risiedere la maggior parte dei voti del quorum.

Quando un gruppo di disponibilità dati è stato distribuito in due data center, è ora possibile usare una terza posizione per ospitare il server di controllo del mirroring. Se l'organizzazione ha una terza posizione con un'infrastruttura di rete isolata dagli errori di rete che interessano i due data center in cui viene distribuito il dag, è possibile distribuire il server di controllo del dag in tale terza posizione, configurando in tal modo il dag con la possibilità di eseguire automaticamente il failover dei database nell'altro data center in risposta a un evento di errore a livello di data center. Se l'organizzazione ha solo due posizioni fisiche, è possibile usare una rete virtuale di Microsoft Azure come terza posizione per posizionare il server di controllo del mirroring.

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

Quando si crea un gruppo di disponibilità del database, è necessario specificare un nome per il dag. Opzionalmente, è anche possibile specificare un server e una directory di controllo.

Quando si crea un gruppo di disponibilità del database, sono disponibili le combinazioni di opzioni e comportamenti seguenti:

  • È 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 cerca nel sito di Active Directory locale un server Accesso client in cui non è installato il server Cassette postali e crea automaticamente la directory predefinita (%SystemDrive%:\DAGFileShareWitnesses\<DAGFQDN) e la condivisione predefinita (<DAGFQDN>>) in tale server e usa tale server accesso client come server di controllo. Si consideri, ad esempio, il server di controllo del mirroring CAS3 in cui il sistema operativo è stato installato nell'unità C. Un dag denominato DAG1 nel dominio contoso.com userebbe una directory di controllo predefinita di C:\DAGFileShareWitnesses\DAG1.contoso.com, che verrebbe condivisa come \CAS3\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 Accesso client 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 Accesso client 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 cluster 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 (CNO) del DAG.

Nota

L'utilizzo di una condivisione file che è parte di uno spazio dei nomi DFS (Distributed File System) non è supportato.

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 del mirroring, ma non una directory di controllo, viene visualizzato il messaggio di errore seguente:

The task was unable to create the default witness directory on server <Server Name>. Please manually specify a witness directory.

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

Unable to access file shares on witness server '<ServerName>'. Until this problem is corrected, the database availability group may be more vulnerable to failures. You can use the Set-DatabaseAvailabilityGroup cmdlet to try the operation again. Error: The network path was not found.

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 nel server di controllo del mirroring e non sono configurate eccezioni del firewall per WMI, il cmdlet Add-DatabaseAvailabilityGroupServer visualizza il messaggio di avviso seguente:

Failed to create file share witness directory 'C:\DAGFileShareWitnesses\DAG_FQDN' on witness server '<ServerName>'. Until this problem is corrected, the database availability group may be more vulnerable to failures. You can use the Set-DatabaseAvailabilityGroup cmdlet to try the operation again. Error: WMI exception occurred on server '<ServerName>': The RPC server is unavailable. (Exception from HRESULT: 0x800706BA)

Per risolvere gli errori e gli avvisi precedenti, eseguire una delle operazioni seguenti:

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

Appartenenza al DAG

Dopo aver creato un gruppo di disponibilità del database, è possibile aggiungere o rimuovere server dal gruppo di disponibilità del database usando la procedura guidata Gestisci gruppo di disponibilità del database nell'interfaccia di amministrazione di Exchange oppure i cmdlet Add-DatabaseAvailabilityGroupServer o Remove-DatabaseAvailabilityGroupServer in Exchange Management Shell. Per i passaggi dettagliati su come gestire l'appartenenza al gruppo di disponibilità del database, vedere Gestire l'appartenenza ai gruppi di disponibilità del database.

Nota

Ogni server Cassette postali che è membro di un DAG è anche un nodo del cluster sottostante utilizzato dal DAG. Di conseguenza, in qualsiasi momento, un server Cassette postali può essere un membro di un solo dag.

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 gruppo di disponibilità del database, si verificano gli eventi seguenti:

  • 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 un ambiente di siti di grandi dimensioni o multipli, in particolare in quelli in cui il dag viene esteso a più siti di Active Directory, è necessario attendere il completamento della replica di Active Directory dell'oggetto dag contenente il primo membro del gruppo di disponibilità del database. Se questo oggetto Active Directory non viene replicato in tutto l'ambiente, l'aggiunta del secondo server potrebbe causare la creazione di un nuovo cluster (e un nuovo CNO) per il gruppo di disponibilità del database. Questa creazione è dovuta al fatto che l'oggetto DAG appare vuoto dal punto di vista del secondo membro aggiunto, causando la creazione di un cluster e di un oggetto CNO per il dag da parte del cmdlet Add-DatabaseAvailabilityGroupServer , anche se questi oggetti esistono già. Per verificare che l'oggetto dag contenente il primo server dag sia stato replicato, usare il cmdlet Get-DatabaseAvailabilityGroup nel secondo server aggiunto per verificare che il primo server aggiunto sia elencato come membro del gruppo di disponibilità del database.

Quando il secondo server e i server successivi vengono aggiunti al gruppo di disponibilità del database, si verificano gli eventi seguenti:

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

Nota

La modifica del modello di quorum deve avvenire automaticamente. Tuttavia, se il modello quorum non passa automaticamente al modello corretto, è possibile eseguire il cmdlet Set-DatabaseAvailabilityGroup con solo il parametro Identity per correggere le impostazioni del quorum per il gruppo di disponibilità del database.

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. 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, Remote Powershell contatta il servizio di replica di Microsoft Exchange sul server Cassette postali che viene 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.

Attenzione

Se i membri del DAG eseguono Windows Server 2012, è necessario pregestire l'oggetto di rete cluster (CNO) prima di aggiungere il primo server al DAG. Se i membri del gruppo di disponibilità del database eseguono Windows Server 2012 R2 e si crea un gruppo di disponibilità del database senza un punto di accesso amministrativo del cluster, non verrà creato un CNO e non sarà necessario creare un'istanza di CNO per il gruppo di disponibilità del database.

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'account CNO e quindi eseguire una delle operazioni seguenti:

  • 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 gruppo di disponibilità del database tramite la procedura guidata Gestisci gruppo di disponibilità del database nell'interfaccia di amministrazione di Exchange o il cmdlet Remove-DatabaseAvailabilityGroupServer in Exchange Management 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 membro di un dag viene perso o in caso contrario non riesce ed è irreversibile e richiede la sostituzione, è possibile eseguire un'operazione di ripristino del server usando l'opzione Setup /m:RecoverServer . Tuttavia, prima di poter eseguire l'operazione di ripristino, è necessario rimuovere il server dal dag usando il cmdlet Remove-DatabaseAvailabilityGroupServer con il parametro ConfigurationOnly .

  • Rimozione del gruppo di disponibilità del database: potrebbero essere presenti situazioni in cui è necessario rimuovere un gruppo di disponibilità del database, 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.

Configurazione delle proprietà del DAG

Dopo aver aggiunto i server al gruppo di disponibilità del database, è possibile usare L'interfaccia di amministrazione di Exchange o Exchange Management Shell per configurare le proprietà di un gruppo di disponibilità del database, inclusi il server di controllo e la directory di controllo usati dal gruppo di disponibilità del database e gli indirizzi IP assegnati al dag.

Le proprietà configurabili comprendono:

  • Server di controllo: nome del server che si vuole ospitare la condivisione file per il server di controllo della condivisione file. Si raccomanda di specificare un server Accesso client come server di controllo. Questa denominazione consente al sistema di configurare, proteggere e usare automaticamente la condivisione, in base alle esigenze, e consente all'amministratore della messaggistica di essere a conoscenza della disponibilità del server di controllo del mirroring.

  • Directory di controllo del mirroring: nome di una directory che verrà usata 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 devono essere assegnati al gruppo di disponibilità del database, a meno che i membri del gruppo di disponibilità del database non eseguano Windows Server 2012 R2 e si stia creando un dag senza un indirizzo IP. In alternativa, gli indirizzi IP del DAG possono essere configurati utilizzando gli indirizzi IP statici assegnati manualmente o possono essere assegnati automaticamente al DAG utilizzando un server DHCP nell'organizzazione.

Exchange Management Shell consente di configurare le proprietà del gruppo di disponibilità dati non disponibili nell'interfaccia di amministrazione di Exchange, ad esempio gli indirizzi IP del gruppo di disponibilità del database; impostazioni di crittografia e compressione della rete; individuazione di rete; la porta TCP usata per la replica; e impostazioni alternative del server di controllo e della directory di controllo; e per abilitare la modalità di coordinamento attivazione del data center.

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 l'elenco completo, vedere la sezione 3.1.5.2 "Tipi di crittografia" delle estensioni del protocollo Kerberos. L'handshake di autenticazione Kerberos seleziona il protocollo di crittografia più sicuro supportato nell'elenco: in genere Advanced Encryption Standard (AES) a 256 bit, potenzialmente con un codice HMAC (Sha Hash-Based Message Authentication Code) per mantenere l'integrità dei dati. Per altre informazioni, vedere HMAC.

La crittografia di rete è una proprietà del dag e non della rete dag. È possibile configurare la crittografia di rete del gruppo di disponibilità del database usando il cmdlet Set-DatabaseAvailabilityGroup in Exchange Management Shell. Le possibili impostazioni di crittografia per le comunicazioni di rete DAG sono illustrate nella tabella seguente:

Impostazione Descrizione
Disabilitato Non viene utilizzata la crittografia di rete.
Abilitato 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 è l'impostazione 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. Questa compressione è lo stesso tipo di compressione usata in molti protocolli Microsoft, in particolare la compressione RPC MAPI tra Microsoft Outlook ed Exchange.

Come con la crittografia di rete, la compressione di rete è anche una proprietà del dag e non della rete dag. È possibile configurare la compressione di rete del gruppo di disponibilità del database usando il cmdlet Set-DatabaseAvailabilityGroup in Exchange Management Shell. Le possibili impostazioni di compressione per le comunicazioni di rete DAG sono illustrate nella tabella seguente:

Impostazione Descrizione
Disabilitato Non viene utilizzata la compressione di rete.
Abilitato 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 è l'impostazione predefinita.
SeedOnly Viene utilizzata la compressione di rete su tutte le reti del DAG solo per il seeding.

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.

Nota

Quando si utilizzano più reti di replica, non è possibile specificare un ordine di precedenza per l'utilizzo della rete. Exchange seleziona a caso una rete di replica dal gruppo delle reti di replica da utilizzare per l'invio dei registri.

In Exchange 2010, la configurazione manuale della rete DAG era necessaria in molti scenari. Per impostazione predefinita, nelle versioni successive di Exchange le reti dag vengono configurate automaticamente dal sistema. Prima di poter creare o modificare reti DAG, è necessario abilitare il controllo manuale della rete DAG utilizzando i seguenti comandi:

Set-DatabaseAvailabilityGroup <DAGName> -ManualDagNetworkConfiguration $true

Dopo aver abilitato la configurazione manuale della rete dag, è possibile usare il cmdlet New-DatabaseAvailabilityGroupNetwork in Exchange Management Shell per creare una rete dag. Per la procedura dettagliata sulla creazione di una rete DAG, vedere Creare una rete di gruppo di disponibilità del database.

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

  • Nome di rete: nome univoco per la rete dag di un massimo di 128 caratteri.

  • Descrizione della rete: descrizione facoltativa per la rete dag di un massimo di 256 caratteri.

  • Subnet di rete: una o più subnet immesse usando un formato IPAddress/Bitmask (ad esempio, 192.168.1.0/24 per le subnet IPv4( Internet Protocol versione 4), 2001:DB8:0:C000::/64 per le subnet IPv6 (Internet Protocol versione 6).

  • Abilita replica: nell'interfaccia di amministrazione di Exchange selezionare la casella di controllo per dedicare la rete dag al traffico di replica e bloccare il traffico MAPI. Deselezionare la casella di controllo per impedire alla replica di usare la rete dag e abilitare il traffico MAPI. In Exchange Management Shell usare il parametro ReplicationEnabled nel cmdlet Set-DatabaseAvailabilityGroupNetwork per abilitare e disabilitare la replica.

Nota

La disattivazione della replica per la rete MAPI non garantisce in assoluto che il sistema non utilizzerà la rete MAPI per la replica. Quando tutte le reti di replica configurate risultano offline, non riuscite o non disponibili e rimane solo la rete MAPI (configurata come disabilitata per la replica), il sistema utilizza la rete MAPI per la replica.

Le reti DAG iniziali (ad esempio, MapiDagNetwork e ReplicationDagNetwork01) create dal sistema sono basate su sottoreti 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). Le impostazioni di configurazione degli indirizzi IP di esempio sono illustrate nella tabella seguente:

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-Replication 10.0.0.15/24 Non applicabile
EX2-MAPI 192.168.1.16 192.168.1.1
EX2-Replication 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: MapiDagNetwork (192.168.1.0) e ReplicationDagNetwork01 (10.0.0.0). Queste reti verranno configurate, come illustrato nella tabella seguente:

Impostazioni reti DAG enumerate per un DAG con una singola subnet

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

Per completare la configurazione di ReplicationDagNetwork01 come rete di replica dedicata, disabilitare la replica per MapiDagNetwork eseguendo il comando seguente:

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

Dopo aver disabilitato la replica per MapiDagNetwork, il servizio replica Microsoft Exchange utilizza ReplicationDagNetwork01 per la replica continua. Se si verifica un errore in ReplicationDagNetwork01, il servizio Replica di Microsoft Exchange torna ad utilizzare MapiDagNetwork per la replica continua. La restituzione a MapiDagNetwork viene eseguita intenzionalmente dal sistema per mantenere la 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 gruppo di disponibilità con più subnet, le appropriate subnet vengono associate automaticamente con 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. Le impostazioni di configurazione degli indirizzi IP di esempio sono illustrate nella tabella seguente:

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-Replication 10.0.0.15/24 Non applicabile
EX2-MAPI 192.168.1.15 192.168.1.1
EX2-Replication 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 gruppo di disponibilità, verranno enumerate quattro subnet e verranno create due reti DAG: MapiDagNetwork (192.168.0.0, 192.168.1.0) e ReplicationDagNetwork01 (10.0.0.0, 10.0.1.0). Queste reti verranno configurate come illustrato nella tabella seguente:

Impostazioni reti DAG enumerate per un DAG a più subnet

Nome Subnet Interfacce Accesso MAPI abilitato Replica abilitata
MapiDagNetwork 192.168.0.0/24
192.168.1.0/24		 EX1 (192.168.0.15)
EX2 (192.168.1.15)		 True True
ReplicationDagNetwork01 10.0.0.0/24
10.0.1.0/24		 EX1 (10.0.0.15)
EX2 (10.0.1.15)		 False True

Reti 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. Questa individuazione include quella di qualsiasi rete SCSI Internet (iSCSI) in uso in seguito all'uso dell'archiviazione iSCSI per uno o più membri del gruppo di disponibilità del database. 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 cluster, né essere usate come reti DAG (MAPI o replica). Queste reti devono invece essere disabilitate manualmente dall'uso da parte del dag in modo che possano essere dedicate al traffico di 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.

Configurazione di membri del 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

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

  • BestAvailability: se si specifica questo valore, il database viene montato automaticamente immediatamente dopo un failover se la lunghezza della coda di copia è 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 di copia è minore o uguale a 12, Exchange tenta di replicare i log rimanenti nella copia passiva e monta il database.

  • GoodAvailability: se si specifica questo valore, il database viene montato automaticamente immediatamente dopo un failover se la lunghezza della coda di copia è 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 montato automaticamente fino a quando tutti i log generati nella copia attiva non vengono copiati nella 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 GoodAvailabilitye tutti i log della copia attiva non possono essere copiati nella copia passiva attivata, è possibile che si perdano alcuni dati della cassetta postale. Tuttavia, la funzionalità Rete sicura (abilitata per impostazione predefinita) è un valido aiuto contro la perdita dei dati perché reinvia i messaggi che si trovano nella coda di Rete sicura.

Esempio: configurazione del dial di montaggio automatico del database

Nell'esempio seguente viene configurato 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 usare il cmdlet Set-MailboxServer per configurare il parametro DatabaseCopyAutoActivationPolicy con uno dei valori seguenti:

  • Blocked: se si specifica questo valore, i database non possono essere attivati automaticamente nei server Cassette postali selezionati.

  • IntrasiteOnly: se si specifica questo valore, la copia del database può essere attivata nei server nello stesso sito di Active Directory. Questa attivazione impedisce il failover o l'attivazione 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 esistono restrizioni speciali sull'attivazione delle copie del database delle cassette postali nei server Cassette postali selezionati.

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

Nell'esempio seguente 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 MaximumActiveDatabases è configurato con un valore numerico numero intero. When the maximum number is reached, the database copies on the server won't be activated if a failover or switchover occurs. 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

Esecuzione della manutenzione sui membri del DAG

Prima di eseguire qualsiasi tipo di manutenzione software o hardware in un membro del gruppo di disponibilità del database, è necessario innanzitutto mettere il membro del gruppo di disponibilità del database in modalità di manutenzione. Gli script seguenti vengono forniti con Exchange Server per facilitare le procedure di manutenzione del gruppo di disponibilità del database:

  • StartDagServerMaintenance.ps1: consente di spostare tutti i database attivi dal server. Sposta anche tutte le funzionalità di supporto del dag critico, ad esempio il ruolo Primary Active Manager (PAM) e impedisce loro di tornare al server prima del completamento della manutenzione.

  • StopDagServerMaintenance.ps1: consente di escludere il membro del gruppo di disponibilità dal database dalla modalità di manutenzione e di renderlo una destinazione attiva per tutti i database e tutte le funzionalità di supporto del dag critico.

Entrambi gli script precedenti accettano il parametro ServerName (che può essere il nome host o il nome di dominio completo (FQDN) del membro del gruppo di disponibilità dati) e i parametri WhatIf . Entrambi gli script possono essere eseguiti in locale o in remoto. Nel server in cui vengono eseguiti gli script devono essere installati gli strumenti di gestione del cluster di failover di Windows (RSAT-Clustering).

Nota

È disponibile anche lo script RedistributeActiveDatabases.ps1 , che supporta il montaggio di database delle cassette postali in membri del dag specifici, come indicato dal numero di preferenza di attivazione in ogni database. Tuttavia, in Exchange 2016 CU2 o versioni successive, la nuova proprietà dag denominata PreferenceMoveFrequency bilancia automaticamente le copie del database in un dag. Sarà quindi necessario usare RedistributeActiveDatabases.ps1 script solo se questa funzionalità è stata disabilitata o se si desidera bilanciare manualmente le copie del database.

Lo script StartDagServerMaintenance.ps1 esegue le attività seguenti:

  • Imposta il valore del parametro DatabaseCopyAutoActivationPolicy nel membro del gruppo di Blockeddisponibilità del database su , impedendo l'attivazione di copie di database nel server.

  • Sospende il nodo nel cluster, impedendo al nodo di essere e diventare pam.

  • Sposta tutti i database attivi attualmente ospitati nel membro del gruppo di disponibilità del database in altri membri del gruppo di disponibilità del database.

  • Se il membro del gruppo di disponibilità del database è attualmente proprietario del gruppo di cluster predefinito, lo script sposta il gruppo di cluster predefinito (e quindi il ruolo PAM) in un altro membro del gruppo di disponibilità del database.

Se una delle attività precedenti ha esito negativo, tutte le operazioni, ad eccezione degli spostamenti riusciti del database, vengono annullate dallo script.

Per avviare le procedure di manutenzione in un membro del gruppo di disponibilità del database, incluso lo scaricamento delle code di trasporto e la sospensione della connettività client, eseguire le attività seguenti:

  1. Per svuotare le code di trasporto, eseguire il comando seguente:

    Set-ServerComponentState <ServerName> -Component HubTransport -State Draining -Requester Maintenance

  2. Per avviare lo svuotamento delle code di trasporto, eseguire il comando seguente:

    Restart-Service MSExchangeTransport

  3. Per avviare il processo di svuotamento di tutte le chiamate di messaggistica unificata (solo in Exchange 2016), eseguire il comando seguente:

    Set-ServerComponentState <ServerName> -Component UMCallRouter -State Draining -Requester Maintenance

  4. Per accedere agli script di manutenzione del dag, eseguire il comando seguente:

    CD $ExScripts

  5. Per eseguire lo script StartDagServerMaintenance.ps1 , eseguire il comando seguente:

    .\StartDagServerMaintenance.ps1 -ServerName <ServerName> -MoveComment Maintenance -PauseClusterNode

    Per il valore del parametro MoveComment , è possibile creare qualsiasi notazione desiderata. L'esempio precedente usa "Maintenance".

    Nota

    L'esecuzione di questo script può richiedere del tempo e durante questo periodo potrebbe non essere visualizzata alcuna attività sullo schermo.

  6. Per reindirizzare i messaggi in sospeso nelle code locali al server Exchange specificato dal parametro Target, eseguire il comando seguente:

    Redirect-Message -Server <ServerName> -Target <Server FQDN>

  7. Per impostare il server in modalità di manutenzione, eseguire il comando seguente:

    Set-ServerComponentState <ServerName> -Component ServerWideOffline -State Inactive -Requester Maintenance

Per verificare che un server sia pronto per la manutenzione, procedere come segue:

  1. Per verificare che il server sia stato inserito in modalità di manutenzione, verificare che solo Monitoring e RecoveryActionsEnabled siano in uno stato attivo quando si esegue il comando seguente:

    Get-ServerComponentState <ServerName> | Format-Table Component,State -Autosize

  2. Per verificare che il server non ospiti copie di database attive, eseguire il comando seguente:

    Get-MailboxServer <ServerName> | Format-List DatabaseCopyAutoActivationPolicy

  3. Per verificare che il nodo del cluster sia in pausa, eseguire il comando seguente:

    Get-ClusterNode <ServerName> | Format-List

  4. Per verificare che tutte le code di trasporto siano state svuotate, eseguire il comando seguente:

    Get-Queue

Al termine della manutenzione e dopo che il membro del gruppo di disponibilità del database è pronto per tornare al servizio, lo script StopDagServerMaintenance.ps1 consente di escludere il membro del dag dalla modalità di manutenzione e di reinserirlo nell'ambiente di produzione. Lo script StopDagServerMaintenance.ps1 esegue le attività seguenti:

  • Riprende il nodo nel cluster, che consente la funzionalità completa del cluster per il membro del gruppo di disponibilità del database.

  • Imposta il valore del parametro DatabaseCopyAutoActivationPolicy nel membro del gruppo di disponibilità del database su Unrestricted.

  • Esegue il cmdlet Resume-MailboxDatabaseCopy per ogni copia del database ospitata nel membro del gruppo di disponibilità del database.

Quando si è pronti per ripristinare lo stato di produzione completo del membro del gruppo di disponibilità del database, inclusa la ripresa delle code di trasporto e della connettività client, eseguire le attività seguenti:

  1. Per configurare il server in modo che sia in modalità non di manutenzione e pronto ad accettare connessioni client, eseguire il comando seguente:

    Set-ServerComponentState <ServerName> -Component ServerWideOffline -State Active -Requester Maintenance

  2. Per consentire al server di accettare chiamate di messaggistica unificata (solo in Exchange 2016), eseguire il comando seguente:

    Set-ServerComponentState <ServerName> -Component UMCallRouter -State Active -Requester Maintenance

  3. Per accedere agli script di manutenzione del dag, eseguire il comando seguente:

    CD $ExScripts

  4. Per eseguire lo script StopDagServerMaintenance.ps1 , eseguire il comando seguente:

    .\StopDagServerMaintenance.ps1 -serverName <ServerName>

  5. Per consentire alle code di trasporto di riprendere l'accettazione e l'elaborazione dei messaggi, eseguire il comando seguente:

    Set-ServerComponentState <ServerName> -Component HubTransport -State Active -Requester Maintenance

  6. Per riprendere l'attività di trasporto, eseguire il comando seguente:

    Restart-Service MSExchangeTransport

Per verificare se un server è pronto per essere utilizzato in ambienti di produzione, eseguire le operazioni riportate di seguito:

  1. Per verificare che il server non sia in modalità di manutenzione, eseguire il comando seguente:

    Get-ServerComponentState <ServerName> | Format-Table Component,State -Autosize

Se si installa un aggiornamento di Exchange e il processo di aggiornamento non riesce, può lasciare alcuni componenti del server in uno stato inattivo, che verrà visualizzato nell'output del cmdlet precedente Get-ServerComponentState . Per risolvere questo problema, eseguire i comandi seguenti:

  1. Set-ServerComponentState <ServerName> -Component ServerWideOffline -State Active -Requester Functional

  2. Set-ServerComponentState <ServerName> -Component Monitoring -State Active -Requester Functional

  3. Set-ServerComponentState <ServerName> -Component RecoveryActionsEnabled -State Active -Requester Functional

Chiusura dei membri del DAG

La soluzione a disponibilità elevata di Exchange è integrata con il processo di arresto 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 che tutti i database nel server in fase di arresto sperimenteranno un'attivazione lossless . Di conseguenza, la procedura consigliata prevede di eseguire un passaggio di server prima di arrestare un server membro di un gruppo di disponibilità del database.

Installazione di aggiornamenti sui membri del DAG

L'installazione degli aggiornamenti di Exchange in un server membro di un dag è un processo relativamente semplice. Quando si installa un aggiornamento su un server che è membro di un DAG, diversi servizi verranno arrestati durante l'installazione, compresi tutti i servizi di Exchange e il servizio Cluster. La procedura generale per l'applicazione degli aggiornamenti a un membro del DAG è la seguente:

  1. Seguire i passaggi descritti precedentemente per mettere il membro del DAG in modalità manutenzione.

  2. Installare l'aggiornamento.

  3. Utilizzare i passaggi descritti precedentemente per disattivare la modalità di manutenzione per il membro del DAG e rimetterlo in produzione.

  4. Facoltativamente, usare lo script RedistributeActiveDatabases.ps1 per ribilanciare le copie del database attive nel gruppo di disponibilità del database.

Per altre informazioni sugli aggiornamenti di Exchange più recenti, vedere Exchange Server numeri di build e date di rilascio.

Nota

È consigliabile eseguire sempre tutti i membri del gruppo di disponibilità del database nella stessa versione del server Exchange (inclusi gli aggiornamenti cumulativi e di sicurezza). Eseguire un "aggiornamento in sequenza" di tutti i membri del gruppo di disponibilità del database e non eseguire un gruppo di disponibilità del database con membri in una versione di Exchange diversa per un periodo di tempo prolungato.