Gruppi di disponibilità del database

  • Articolo

Un gruppo di disponibilità del database è il componente di base del framework di disponibilità elevata e resilienza del sito del server Cassette postali integrato in Microsoft Exchange Server. Un gruppo di disponibilità del database è un gruppo costituito da un massimo di 16 server Cassette postali che ospita un insieme di database e fornisce il ripristino automatico a livello del database da errori che hanno un impatto su singoli server o database.

Importante

Tutti i server all'interno di un dag devono eseguire la stessa versione di Exchange. Ad esempio, non è possibile combinare server Exchange 2013 e server Exchange 2016 nello stesso dag.

Un gruppo di disponibilità del database è un confine per la replica del database delle cassette postali, i failover e gli switchover di database e server e un componente interno denominato Active Manager. Active Manager, che viene eseguito su tutti i server Cassette postali, gestisce switchover e failover all'interno dei gruppi di disponibilità del database. Per ulteriori informazioni su Active Manager, vedere Active Manager.

Qualsiasi server in un gruppo di disponibilità del database è in grado di ospitare una copia del database delle cassette postali da qualsiasi altro server nel gruppo di disponibilità del database. Quando un server viene aggiunto al gruppo di disponibilità del database, funziona con altri server nel gruppo di disponibilità del database per fornire il ripristino automatico da errori che hanno un impatto sui database delle cassette postali, ad esempio un errore di rete, del server o del disco.

Nota

Per ulteriori informazioni sulla creazione di gruppi di disponibilità del database, sulla gestione della loro appartenenza, sulla configurazione delle loro proprietà, su creazione e monitoraggio di copie del database delle cassette postali e sull'esecuzione di switchover, vedere Gestione di elevata disponibilità e resilienza del sito.

Database availability group lifecycle

I dag sfruttano il concetto di distribuzione incrementale, ovvero la possibilità di distribuire la disponibilità dei dati e del servizio per tutti i server Cassette postali e i database dopo l'installazione di Exchange. Dopo aver distribuito Exchange Server server Cassette postali, è possibile creare un dag, aggiungere server Cassette postali al dag e quindi replicare i database delle cassette postali tra i membri del dag.

Nota

È supportato creare un gruppo di disponibilità del database che contiene una combinazione di server cassette postali fisici e server cassette postali virtualizzati, a condizione che i server e la soluzione siano conformi ai requisiti di sistema Exchange Server e ai requisiti definiti in Exchange Server virtualizzazione. Come per tutte le configurazioni di Exchange ad alta disponibilità, è necessario verificare che tutti i server Cassette postali nel gruppo di disponibilità del database abbiano dimensioni appropriate per gestire il carico di lavoro necessario durante le interruzioni del servizio pianificate e non pianificate.

Un gruppo di disponibilità del database viene creato utilizzando il cmdlet New-DatabaseAvailabilityGroup. Un gruppo di disponibilità del database viene inizialmente creato come oggetto vuoto in Active Directory. Questo oggetto directory è utilizzato per archiviare informazioni relative al gruppo di disponibilità del database, come ad esempio le informazioni di appartenenza del server e alcune impostazioni di configurazione del gruppo. Quando si aggiunge il primo server a un DAG, per quel DAG viene creato automaticamente un cluster di failover. Il cluster di failover viene utilizzato esclusivamente dal gruppo di disponibilità del database e il cluster deve essere dedicato al DAG. L'utilizzo del cluster per altri scopi non è supportato.

Oltre alla creazione del cluster di failover, viene anche attivata l'infrastruttura che controlla i server per rilevare eventuali problemi della rete o dei server stessi. Il meccanismo heartbeat di cluster di failover e il database cluster sono poi utilizzati per tracciare e gestire le informazioni sul gruppo di disponibilità del database che possono cambiare rapidamente, come lo stato di installazione del database, lo stato di replica e l'ultimo percorso d'installazione.

Durante il processo di creazione, al gruppo di disponibilità del database viene assegnato un nome univoco e uno o più indirizzi IP statici oppure viene configurato per utilizzare il protocollo DHCP (Dynamic Host Configuration Protocol) o creato senza un punto di accesso amministrativo cluster. I dag senza un punto di accesso amministrativo possono essere creati solo nei server che eseguono Exchange 2019, Exchange 2016 o Exchange 2013 Service Pack 1 o versione successiva, con Windows Server 2012 R2 Standard o Datacenter Edition. I DAG senza punto di accesso amministrativo cluster hanno le seguenti caratteristiche:

  • Non è presente un indirizzo IP assegnato al cluster/DAG e, quindi, nessuna risorsa indirizzo IP nel gruppo risorsa principale del cluster.

  • Non è presente un nome di rete assegnata al cluster e, quindi, nessuna risorsa nome di rete nel gruppo risorsa principale del cluster

  • Il nome del cluster/DAG non è registrato nel DNS e non è risolvibile nella rete.

  • Non viene creato un oggetto di nome cluster (CNO) in Active Directory.

  • Il cluster non può essere gestito utilizzando lo strumento di gestione Cluster di Failover. Deve essere gestito utilizzando Windows PowerShell e i cmdlet PowerShell devono essere eseguiti sui membri del cluster individuale.

Questo esempio illustra come usare Exchange Management Shell per creare un gruppo di disponibilità del database con un punto di accesso amministrativo del cluster che avrà tre server. Due server (EX1 e EX2) si trovano nella stessa subnet (10.0.0.0) e il terzo server (EX3) si trova in una subnet diversa (192.168.0.0).

New-DatabaseAvailabilityGroup -Name DAG1 -WitnessServer EX4 -DatabaseAvailabilityGroupIPAddresses 10.0.0.5,192.168.0.5
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer EX1
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer EX2
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer EX3

I comandi per la creazione di un DAG senza un punto di accesso di amministrazione cluster sono molto simili:

New-DatabaseAvailabilityGroup -Name DAG1 -WitnessServer EX4 -DatabaseAvailabilityGroupIPAddresses ([System.Net.IPAddress])::None
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer EX1
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer EX2
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer EX3

Il cluster per DAG1 viene creato quando EX1 viene aggiunto al gruppo di disponibilità del database. Durante la creazione del cluster, il cmdlet Add-DatabaseAvailabilityGroupServer recupera gli indirizzi IP configurati per il gruppo di disponibilità del database e ignora quelli che non corrispondono ad alcuna delle subnet individuate in EX1. Nel precedente esempio, il cluster per DAG1 viene creato con l'indirizzo IP 10.0.0.5 e 192.168.0.5 viene ignorato. Nel secondo esempio precedente, il valore del parametro DatabaseAvailabilityGroupIPAddresses indica all'attività di creare un cluster di failover per il dag che non dispone di un punto di accesso amministrativo. Per questo il cluster viene creato con un indirizzo IP o risorsa nome di rete nel gruppo di ricerca cluster principale.

Viene quindi aggiunto EX2 e il cmdlet Add-DatabaseAvailabilityGroupServer recupera nuovamente gli indirizzi IP configurati per il gruppo di disponibilità del database. Non viene apportata alcuna modifica agli indirizzi del cluster poiché EX2 si trova nella stessa subnet di EX1.

Viene quindi aggiunto EX3 e il cmdlet Add-DatabaseAvailabilityGroupServer recupera nuovamente gli indirizzi IP configurati per il gruppo di disponibilità del database. Poiché è presente una subnet corrispondente a 192.168.0.5 in EX3, l'indirizzo 192.168.0.5 viene aggiunto come risorsa indirizzo IP nel gruppo cluster. Inoltre, viene automaticamente configurata una dipendenza OR per la risorsa nome rete per ogni risorsa indirizzo IP. L'indirizzo 192.168.0.5 verrà utilizzato dal cluster quando il gruppo di risorsa cluster principale si sposta in EX3.

Per i DAG con punti di accesso amministrativo cluster, La funzionalità clustering di failover di Windows registra gli indirizzi IP per il cluster in Domain Name System (DNS) quando la risorsa nome rete viene portata online. Inoltre, quando EX1 viene aggiunto al cluster, viene creato un CNO (cluster name object) in Active Directory. Il nome di rete, gli indirizzi IP e il CNO per il cluster non vengono creati per le funzioni DAG. Amministratori e utenti finali non hanno necessità di interfacciarsi o connettersi al nome del gruppo di disponibilità del database/cluster o all'indirizzo IP per alcun motivo. Alcune applicazioni di terze parti si connettono al punto di accesso amministrativo del cluster per eseguire attività di gestione, ad esempio il backup o il monitoraggio. Se non si usano applicazioni di terze parti che richiedono un punto di accesso amministrativo del cluster e il dag esegue Exchange 2016 o Exchange 2019 in Windows Server 2012 R2, è consigliabile creare un gruppo di disponibilità del database senza un punto di accesso amministrativo. Si semplifica così la configurazione DAG, si elimina la necessità per uno o più indirizzi IP e si riduce la superficie di attacco di un DAG.

I DAG vengono inoltre configurati per utilizzare un server e una directory di controllo. Il server e la directory di controllo sono configurati automaticamente dal sistema oppure possono essere configurati manualmente dall'amministratore. Nell'esempio precedente, EX4 (un server che non è e non sarà membro del DAG) viene configurato manualmente come server di controllo del DAG.

Per impostazione predefinita, il gruppo di disponibilità del database è progettato per utilizzare la funzionalità di replica continua incorporata per replicare i database delle cassette postali tra i server del gruppo di disponibilità del database. Se si usa la replica di dati di terze parti che supporta l'API di replica di terze parti in Exchange Server, è necessario creare il gruppo di disponibilità del database in modalità di replica di terze parti usando il cmdlet New-DatabaseAvailabilityGroup con il parametro ThirdPartyReplication. Non è possibile disabilitare questa modalità, una volta abilitata.

Una volta creato il gruppo di disponibilità del database, è possibile aggiungere server Cassette postali a tale gruppo di disponibilità del database. Quando si aggiunge il primo server al gruppo di disponibilità del database, viene formato un cluster per l'utilizzo da parte del gruppo di disponibilità del database. I gruppi di disponibilità del database utilizzano la tecnologia clustering di failover di Windows, ad esempio heartbeat cluster, reti cluster e database cluster (per l'archiviazione di dati che vengono modificati, quali le modifiche di stato del database da attivo a passivo o viceversa, oppure da montato a smontato e viceversa). Con l'aggiunta di ogni server successivo al gruppo di disponibilità del database, il server viene aggiunto anche al cluster sottostante, il modello di quorum del cluster viene automaticamente regolato da Exchange e il server viene aggiunto all'oggetto gruppo di disponibilità del database in Active Directory.

Dopo l'aggiunta dei server Cassette postali a un gruppo di disponibilità del database, è possibile configurare una vasta gamma di proprietà del gruppo di disponibilità del database, ad esempio è possibile utilizzare o meno la crittografia di rete o la compressione di rete per la replica del database all'interno del DAG. È anche possibile configurare reti di gruppi di disponibilità del database e crearne altre.

Dopo aver aggiunto i membri a un gruppo di disponibilità del database e configurato tale gruppo, è possibile replicare i database delle cassette postali attivi in ogni server negli altri membri del gruppo di disponibilità del database. Dopo aver creato le copie del database delle cassette postali, è possibile monitorare l'integrità e lo stato delle copie utilizzano una vasta gamma di strumenti di monitoraggio incorporati. Inoltre, è possibile eseguire switchover di server e database.

Modelli quorum del gruppo di disponibilità del database

Sotto ogni dag è presente un cluster di failover di Windows. I cluster di failover usano il concetto di quorum, che usa un consenso degli elettori per garantire che solo un subset dei membri del cluster (che potrebbe significare tutti i membri o la maggioranza dei membri) funzioni contemporaneamente. Quorum non è un nuovo concetto per Exchange Server. I server Cassette postali a disponibilità elevata nelle versioni precedenti di Exchange usano anche il clustering di failover e il relativo concetto di quorum. Quorum rappresenta una visualizzazione condivisa di membri e risorse e il termine quorum viene usato anche per descrivere i dati fisici che rappresentano la configurazione all'interno del cluster condivisa tra tutti i membri del cluster. Di conseguenza, tutti i dag richiedono il quorum del cluster di failover sottostante. Se il cluster perde il quorum, tutte le operazioni dag terminano e tutti i database montati ospitati nel dag smonta. In questo caso, l'intervento dell'amministratore è necessario per correggere il problema del quorum e ripristinare le operazioni del gruppo di disponibilità del database.

Il quorum è importante per garantire la coerenza, per risolvere eventuali conflitti derivanti dal partizionamento e per garantire la velocità di risposta dei cluster:

  • Garantire la coerenza: un requisito principale per un cluster di failover di Windows è che ognuno dei membri abbia sempre una visualizzazione del cluster coerente con gli altri membri. L'hive del cluster viene utilizzato come l'archivio definitivo in cui sono memorizzate tutte le informazioni di configurazione relative al cluster. Se non è possibile caricare localmente l'hive del cluster in un membro del gruppo di disponibilità del database, il servizio Cluster non viene avviato perché non è in grado di garantire che il membro soddisfa il requisito di disporre di una vista del cluster coerente con gli altri membri.

  • Agire come tie-breaker: una risorsa quorum di controllo viene usata nei dag con un numero pari di membri per evitare scenari di sindrome del cervello diviso e per assicurarsi che una sola raccolta di membri nel dag sia considerata ufficiale. Quando il server di controllo è necessario per il quorum, i membri del gruppo di disponibilità del database in grado di comunicare con il server di controllo possono impostare un blocco SMB (Server Message Block) sul file di log del server di controllo. Il membro del gruppo di disponibilità del database che blocca il server di controllo (definito nodo di blocco) mantiene un voto aggiuntivo ai fini del quorum. I membri del gruppo di disponibilità del database in contatto con il nodo di blocco sono in maggioranza e mantengono il quorum. I membri del gruppo di disponibilità del database in contatto con il nodo di blocco sono in minoranza e perdono il quorum.

  • Garantire la velocità di risposta: per garantire la velocità di risposta, il modello quorum garantisce che, ogni volta che il cluster è in esecuzione, un numero sufficiente di membri del sistema distribuito siano operativi e comunicativi e che sia possibile garantire almeno una replica dello stato corrente del cluster. Non è richiesto tempo ulteriore per mettere i membri in comunicazione o per determinare se è garantita una replica specifica.

I gruppi di disponibilità del database con un numero pari di membri utilizzano la modalità quorum Maggioranza dei nodi e delle condivisioni file del cluster di failover, che impiega un server di controllo esterno che funge da tie-breaker. In questa modalità di quorum, ogni membro del gruppo di disponibilità del database ottiene un voto. Viene inoltre utilizzato il server di controllo per attribuire un voto pesato a un membro del gruppo di disponibilità del database (ad esempio, ottiene due voti anziché uno). Per impostazione predefinita, i dati relativi al quorum del cluster vengono archiviati nel disco di sistema di ogni membro del gruppo di disponibilità del database e ne viene garantita la coerenza tra tutti i dischi. Non viene tuttavia archiviata alcuna copia dei dati del quorum sul server di controllo. Nel server di controllo è presente un file che tiene traccia del membro con la copia più aggiornata dei dati, ma in tale server non è presente alcuna copia dei dati del quorum del cluster. In questo modo, la maggioranza dei voter (i membri del gruppo di disponibilità del database più il server di controllo) deve essere operativa e in grado di comunicare reciprocamente per mantenere il quorum. Se la maggior parte dei votanti non è in grado di comunicare con gli altri, il cluster sottostante del gruppo di disponibilità del database perde il quorum e sarà necessario un intervento amministrativo per ripristinare il funzionamento del gruppo di disponibilità del database. Per altre informazioni, vedere Switchovers di Datacenter e Restore-DatabaseAvailabilityGroup.

I gruppi di disponibilità del database con un numero dispari di membri utilizzano la modalità quorum Maggioranza dei nodi del cluster di failover. In questa modalità, ogni membro ottiene un voto e il disco di sistema locale di ciascun membro viene utilizzato per archiviare i dati del quorum del cluster. Se la configurazione del gruppo di disponibilità del database viene modificata, le modifiche si rifletteranno su tutti i diversi dischi. La modifica viene considerata vincolante e permanente solo se viene apportata ai dischi della metà dei membri (con arrotondamento per difetto) più uno. Ad esempio, in un gruppo di disponibilità del database con cinque membri, la modifica deve essere apportata a due membri più uno o a un totale di tre membri.

Il quorum richiede che la maggioranza dei voter sia in grado di comunicare reciprocamente. Si consideri un gruppo di disponibilità del database con quattro membri. Poiché il gruppo di disponibilità del database include un numero pari di membri, viene utilizzato un server di controllo esterno per fornire a uno dei membri del cluster un quinto voto che consenta di risolvere i conflitti. Per mantenere una maggioranza di voter (e quindi il quorum), almeno tre voter devono essere in grado di comunicare reciprocamente. In qualsiasi momento, un numero massimo di due voter può trovarsi offline senza interrompere il servizio e l'accesso ai dati. Se tre o più voter sono offline, il gruppo di disponibilità del database perde il quorum e il servizo e l'accesso ai dati verranno interrotti fino alla risoluzione del problema.