Gestire i gruppi di disponibilità del database in Exchange Server

SI APPLICA A:2016 2019 Edizione in abbonamento

Un gruppo di disponibilità del database (DAG) è un insieme di 16 server Cassette postali di Exchange che forniscono 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 interagisce con gli altri server del gruppo di disponibilità del database per fornire il ripristino automatico a livello di database in caso di 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 di replica e l'ultima posizione montata.

Creazione di DAG

È possibile creare un gruppo di disponibilità del database utilizzando la procedura guidata Nuovo gruppo di disponibilità database nell'interfaccia di amministrazione di Exchange (EAC) oppure 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 gli indirizzi IP al gruppo di disponibilità del database utilizzando il parametro DatabaseAvailabilityGroupIpAddresses . Se si omette questo parametro, il DAG tenta di ottenere un indirizzo IP utilizzando un server DHCP della rete.

Se si crea 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 tal caso, il cluster non avrà un oggetto nome cluster (CNO) in Active Directory e il gruppo di risorse core del cluster non conterrà una risorsa nome di rete o una risorsa indirizzo IP.

Per la procedura dettagliata sulla creazione di un gruppo di disponibilità del database, vedere Creare un gruppo di disponibilità del database.

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

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

Server di controllo DAG e Directory di controllo

Quando si crea un gruppo di disponibilità del database, è necessario specificare un nome per il gruppo di disponibilità del database non più lungo di 15 caratteri che sia univoco all'interno della foresta Active Directory. Inoltre, ciascun DAG viene configurato con un server e una directory di controllo. Il server di controllo e la relativa directory vengono usati solo quando è presente un numero pari di membri nel gruppo di disponibilità del database e solo ai fini del 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 non deve essere usata per scopi diversi da quello per il server di controllo del gruppo di disponibilità 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 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 utilizzato come server di controllo, se Windows Firewall è abilitato nel server di controllo previsto, è necessario abilitare l'eccezione di Windows Firewall per Condivisione file e stampanti. Il server di controllo usa la porta SMB 445.

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

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 ora include 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.

Quando un gruppo di disponibilità del database è stato distribuito in due data center, è ora possibile utilizzare una terza posizione per ospitare il server di controllo. Se l'organizzazione dispone di una terza posizione con un'infrastruttura di rete isolata dagli errori di rete che interessano i due data center in cui è distribuito il DAG, è possibile distribuire il server di controllo del database in tale terza posizione, configurando così 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 datacenter. Se l'organizzazione dispone solo di due sedi fisiche, è possibile utilizzare una rete virtuale di Microsoft Azure come terza posizione per posizionare il server di controllo.

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 gruppo di disponibilità del database. 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 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>>) su tale server e utilizza tale server Accesso client come server di controllo. Ad esempio, si consideri il server di controllo CAS3 su cui è stato installato il sistema operativo sull'unità C. Un gruppo di disponibilità del database 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.

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 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 specificano 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 e non sono presenti eccezioni del firewall configurate 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 utilizzando la procedura guidata Gestisci gruppo di disponibilità database nell'interfaccia di amministrazione di Exchange o i cmdlet Add-DatabaseAvailabilityGroupServer o Remove-DatabaseAvailabilityGroupServer in Exchange Management Shell. Per la procedura dettagliata su come gestire l'appartenenza al gruppo di disponibilità del database, vedere Gestire 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 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 grandi dimensioni o con più siti, in particolare quelli in cui il gruppo di disponibilità del database viene esteso a più siti di Active Directory, è necessario attendere il completamento della replica di Active Directory dell'oggetto del gruppo di disponibilità del database 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 di un nuovo CNO) per il gruppo di disponibilità del database. Questa creazione è dovuta al fatto che l'oggetto del gruppo di disponibilità del database risulta vuoto dal punto di vista dell'aggiunta del secondo membro, facendo sì che il cmdlet Add-DatabaseAvailabilityGroupServer crei un cluster e un CNO per il gruppo di disponibilità del database, anche se questi oggetti esistono già. 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 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.

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.

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. È possibile creare e disabilitare un account computer per il CNO, 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 utilizzando la procedura guidata Gestione gruppo di disponibilità 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 gruppo di disponibilità del database viene perso o si guasta ed è irreversibile e deve essere sostituito, è possibile eseguire un'operazione di ripristino del server utilizzando l'opzione Setup /m:RecoverServer . Tuttavia, prima di poter eseguire l'operazione di ripristino, è necessario rimuovere il server dal gruppo di disponibilità del database utilizzando il cmdlet Remove-DatabaseAvailabilityGroupServer con il parametro ConfigurationOnly .

• Rimozione del gruppo di disponibilità del database: In alcune situazioni potrebbe essere 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 utilizzare 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 utilizzati dal gruppo di disponibilità del database, nonché gli indirizzi IP assegnati al gruppo di disponibilità del database.

Le proprietà configurabili comprendono:

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

• Directory di controllo: il nome di una directory che verrà utilizzata per archiviare i dati di controllo della condivisione di 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 stiano eseguendo Windows Server 2012 R2 e tu stia creando un gruppo di disponibilità del database 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à del database che non sono disponibili nell'interfaccia di amministrazione di Exchange, ad esempio gli indirizzi IP del gruppo di disponibilità del database; impostazioni di crittografia e compressione di rete; individuazione della rete; la porta TCP utilizzata per la replica; e impostazioni alternative del server di controllo e della directory di controllo; e per 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 l'elenco completo, vedere sezione 3.1.5.2, «Tipi di crittografia» delle estensioni del protocollo Kerberos.) L'handshake di autenticazione Kerberos seleziona il protocollo di crittografia più forte supportato nell'elenco: in genere Advanced Encryption Standard (AES) a 256 bit, potenzialmente con un codice di autenticazione messaggi basato su hash SHA (HMAC) per mantenere l'integrità dei dati. Per ulteriori informazioni, vedere HMAC.

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

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 utilizzato in molti protocolli Microsoft, in particolare nella compressione MAPI RPC tra Microsoft Outlook ed Exchange.

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

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.

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 del gruppo di disponibilità del database, è possibile utilizzare il cmdlet New-DatabaseAvailabilityGroupNetwork in Exchange Management Shell per creare una rete del gruppo di disponibilità del database. Per la procedura dettagliata sulla creazione di una rete DAG, vedere Creare una rete di gruppo di disponibilità del database.

È possibile utilizzare 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 del gruppo di disponibilità del database di un massimo di 128 caratteri.

• Descrizione di rete: descrizione facoltativa per la rete del gruppo di disponibilità del database di un massimo di 256 caratteri.

• Subnet di rete: una o più subnet immesse utilizzando un formato di indirizzo IP/maschera di bit , 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).

• Abilitare la replica: nell'interfaccia di amministrazione di Exchange selezionare la casella di controllo per dedicare la rete del gruppo di disponibilità del database al traffico di replica e bloccare il traffico MAPI. Deselezionare la casella di controllo per impedire alla replica di utilizzare la rete del gruppo di disponibilità del database e per abilitare il traffico MAPI. In Exchange Management Shell, utilizzare il parametro ReplicationEnabled nel cmdlet Set-DatabaseAvailabilityGroupNetwork per abilitare e disabilitare 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 dell'indirizzo IP di esempio sono mostrate nella tabella seguente:

Esempi di impostazioni delle schede di rete

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 mostrato nella tabella seguente:

Impostazioni reti DAG enumerate per un DAG con una singola subnet

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. Il ritorno a MapiDagNetwork viene eseguito intenzionalmente dal sistema per mantenere l'alta disponibilità.

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 dell'indirizzo IP di esempio sono mostrate nella tabella seguente:

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

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 mostrato nella tabella seguente:

Impostazioni reti DAG enumerate per un DAG a più subnet

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 tutte le reti Internet SCSI (iSCSI) in uso a seguito dell'utilizzo 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 gruppo di disponibilità del database o dal relativo cluster o essere usate come reti del gruppo di disponibilità del database (MAPI o replica). Al contrario, queste reti devono essere disabilitate manualmente dall'uso da parte del gruppo di disponibilità del database 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

• Criterio di attivazione automatica della copia del database

• Maximum active databases

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 dei seguenti valori:

• 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 è inferiore o uguale a 12, Exchange tenta di replicare i registri 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 sono stati 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 o BestAvailability o GoodAvailabilitytutti i log della copia attiva non possono essere copiati nella copia passiva attivata, è possibile che alcuni dati della cassetta postale vadano persi. 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 pari a 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 dei seguenti valori:

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

• IntrasiteOnly: se si specifica questo valore, è possibile attivare la copia del database 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 particolari restrizioni per l'attivazione delle copie del database delle cassette postali sui server delle 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 pari a 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 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 hardware o software su un membro del gruppo di disponibilità del database, è necessario prima attivare la modalità di manutenzione per il membro del gruppo di disponibilità del database. I seguenti script vengono forniti con Exchange Server per facilitare le procedure di manutenzione del gruppo di disponibilità del database:

• StartDagServerMaintenance.ps1: Assiste nello spostamento di tutti i database attivi dal server. Sposta inoltre tutte le funzionalità di supporto del gruppo di disponibilità del database critiche, come il ruolo di Primary Active Manager (PAM), e impedisce loro di tornare sul server prima del completamento della manutenzione.

• StopDagServerMaintenance.ps1: consente di disattivare la modalità di manutenzione del membro del gruppo di disponibilità del database e di renderlo un obiettivo attivo per tutti i database e tutte le funzionalità critiche di supporto del gruppo di disponibilità del database.

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à del database, 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 (clustering RSAT).

Lo scriptStartDagServerMaintenance.ps1 esegue le attività seguenti:

• Imposta il valore del parametro DatabaseCopyAutoActivationPolicy nel membro del gruppo di disponibilità del database su , impedendo Blockedl'attivazione di qualsiasi copia del 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 possiede attualmente il gruppo di cluster predefinito, lo script sposta il gruppo di cluster predefinito (e pertanto 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 di database riusciti, vengono annullate dallo script.

Per avviare le procedure di manutenzione su un membro del gruppo di disponibilità del database, tra cui lo svuotamento 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 prosciugamento 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 gruppo di disponibilità del database, eseguire il comando seguente:

   CD $ExScripts
   

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

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

   Per il valore del parametro MoveComment è possibile inserire le notazioni desiderate. L'esempio precedente usa "Manutenzione".

   Nota

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

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

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

7. Per attivare la modalità di manutenzione per il server, 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 messo in modalità di manutenzione, verificare che siano 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 attive del database, usare il comando seguente:

   Get-MailboxServer <ServerName> | Format-List DatabaseCopyAutoActivationPolicy
   

3. Per verificare che il nodo del cluster sia sospeso, usare 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 in servizio, lo script di StopDagServerMaintenance.ps1 consente di far uscire il membro del gruppo di disponibilità dal database dalla modalità di manutenzione e rimetterlo in produzione. Lo scriptStopDagServerMaintenance.ps1 esegue le attività seguenti:

• Riprende il nodo del cluster, abilitando tutte le funzionalità 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 il membro del gruppo di disponibilità del database allo stato di produzione completo, 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à fuori manutenzione e pronto ad accettare connessioni client, eseguire il comando seguente:

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

   Nota

   • Se l'ambiente utilizza Microsoft Exchange IMAP4 & i servizi POP3 di Microsoft Exchange, per impostazione predefinita, i servizi verranno arrestati e rimarranno in modalità di arresto se i componenti correlati ImapProxy e PopProxy sono nello stato Inattivo.
   • Per avviare i servizi, modificare lo stato dei componenti e PopProxy dei correlati ImapProxy in Attivo e avviare manualmente i servizi.

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 gruppo di disponibilità del database, eseguire il comando seguente:

   CD $ExScripts
   

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

   .\StopDagServerMaintenance.ps1 -serverName <ServerName>
   

5. Per abilitare le code di trasporto a 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, alcuni componenti del server possono trovarsi in uno stato inattivo, che verrà visualizzato nell'output del cmdlet precedente Get-ServerComponentState . Per risolvere il problema, eseguire i comandi seguenti:

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

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

   • 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 che viene arrestato 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 gruppo di disponibilità del database è 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 ulteriori informazioni sugli aggiornamenti più recenti di Exchange, vedere Numeri di build e date di rilascio di Exchange Server.