Ruolo Gruppi di disponibilità del database (DAG)

Si applica a: Exchange Server 2013

Informazioni su Exchange DAG in Exchange Server 2013. In questo articolo viene descritto il ciclo di vita relativo al gruppo di disponibilità dei database (DAG) e l'utilizzo di un DAG per offrire disponibilità elevata e resilienza del sito.

Un gruppo di disponibilità del database (DAG, Database Availability Group) è il componente di base del server Cassette postali a disponibilità elevata e resilienza del sito integrata in Microsoft Exchange Server 2013. 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.

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.

Ciclo di vita del gruppo di disponibilità del database (DAG)

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 i server Cassette postali di Exchange 2013, è possibile creare un gruppo di disponibilità del database, aggiungere server Cassette postali al gruppo di disponibilità del database e quindi replicare i database delle cassette postali tra i membri del gruppo di disponibilità del database.

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 su server che eseguono Exchange 2013 Service Pack 1 o versione successiva su Windows Server 2012 R2 edizione Standard o Datacenter. 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.

In questo esempio viene mostrato come utilizzare Shell per creare un gruppo di disponibilità del database con punto di accesso amministrativo cluster con 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 2013 SP1 o versioni successive 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 2013, è necessario creare il dag 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.

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.

Modelli di quorum del gruppo di disponibilità del database (DAG)

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

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.

Utilizzo di un gruppo di disponibilità del database (DAG) per offrire disponibilità elevata

Per illustrare come un gruppo di disponibilità del database può fornire disponibilità elevata per i database delle cassette postali, considerare l'esempio seguente, in cui viene utilizzato un gruppo di disponibilità del database con cinque membri. Questo gruppo di disponibilità del database è illustrato nella figura seguente.

Nella figura precedente, i database verdi sono copie del database delle cassette postali attive e i database blu sono copie del database delle cassette postali passive. In questo esempio, non viene eseguito il mirroring delle copie tra ogni server, le copie vengono viceversa ripartite tra più server. In questo modo si assicura che non vi siano due server nel gruppo di disponibilità del database con lo stesso insieme di copie del database e ciò fornisce al gruppo di disponibilità del database maggiore resilienza agli errori, inclusi gli errori che si verificano mentre altri componenti non sono disponibili a causa della normale manutenzione.

Considerare lo scenario seguente, utilizzando il gruppo di disponibilità del database dell'esempio precedente che illustra la resilienza a più errori di database e server.

Inizialmente, tutti i database e i server sono integri. È necessario installare alcuni aggiornamenti del sistema operativo su EX2, quindi il server deve essere portato nella modalità manutenzione. Questo provoca uno switchover del server mediante il quale viene attivata la copia di DB4 su un altro server Cassette postali. Lo switchover del server consente di spostare tutte le copie attive del database delle cassette postali dal server corrente in uso a uno più server Cassette postali nel gruppo di disponibilità del database, in previsione di un'interruzione pianificata del server corrente. In questo esempio, è presente un solo database delle cassette postali attivo in EX2 (DB4), pertanto viene spostata una sola copia del database delle cassette postali attiva.

Mentre viene eseguita la manutenzione su EX2, si verifica un errore hardware irreversibile in EX3 che si disconnette. Prima di disconnettersi, EX3 ospitava la copia attiva di DB2. Per ripristinare il sistema dall'errore, viene automaticamente attivata la copia di DB2 ospitata in EX1 entro 30 secondi. come illustrato nella figura seguente.

Dopo aver completato la manutenzione pianificata per EX2, il server viene riportato online ed esce dalla modalità manutenzione. Non appena EX2 è disponibile, gli altri membri del gruppo di disponibilità del database ne ricevono notifica e le copie di DB1, DB4 e DB5 ospitate su EX2 vengono automaticamente sincronizzate con la copia attiva di ogni database. come illustrato nella figura seguente.

Dopo che il componente hardware che ha causato l'errore in EX3 è stato sostituito, EX3 viene riportato online. Quando EX3 è di nuovo disponibile, gli altri membri del gruppo di disponibilità del database ne ricevono notifica e le copie di DB2, DB3 e DB4 ospitate su EX3 vengono automaticamente sincronizzate con la copia attiva di ogni database. come illustrato nella figura seguente.

Utilizzo di un gruppo di disponibilità del database (DAG) per offrire resilienza del sito

Oltre a fornire disponibilità elevata in un datacenter, un gruppo di disponibilità del database può essere esteso a uno o più altri datacenter in una configurazione che fornisce resilienza del sito per uno o più datacenter. Nelle figure dell'esempio precedente, il gruppo di disponibilità del database si trova in un unico datacenter e in un unico sito Active Directory. È possibile utilizzare la distribuzione incrementale per estendere questo gruppo di disponibilità del database a un secondo data center (e a un secondo sito di Active Directory) distribuendo un server Cassette postali e le risorse di supporto necessarie (uno o più server di Active Directory e i servizi DNS). Il server Cassette postali viene quindi aggiunto al gruppo di disponibilità del database, come illustrato nella figura seguente.

In questo esempio, una copia passiva di ogni database attivo nel datacenter di Redmond è configurata in EX6 nel datacenter di Dublino. Esistono tuttavia molti altri esempi di configurazioni del gruppo di disponibilità del database che forniscono resilenza del sito. Ad esempio:

• Anziché ospitare solo le copie passive del database, EX6 potrebbe ospitare tutte le copie attive o un insieme di copie attive e passive.

• Oltre a EX6, nel datacenter di Dublino potrebbero essere distribuiti più gruppi di disponibilità del database, offrendo protezione da ulteriori errori. Questo tipo di configurazione è anche in grado di fornire ulteriori capacità, in modo tale che, se si verifica un errore nel datacenter di Redmond, il datacenter di Dublino è in grado di supportare un numero di utenti molto più grande.

Utilizzo di più gruppi di disponibilità del database (DAG) per offrire resilienza del sito

Nell'esempio precedente, un singolo gruppo di disponibilità del database si estende su più datacenter, fornendo resilienza del sito per uno o entrambi i datacenter. Quando si utilizza un singolo gruppo di disponibilità del database per fornire resilienza del sito in un ambiente in cui ogni datacenter a cui viene esteso il gruppo di disponibliità del database ha un gran numero di utenti attivi, esiste un singolo punto di errore nella connessione WAN (Wide Area Network). Ciò avviene perché il quorum richiede che la maggioranza dei voter sia attiva e in grado di comunicare reciprocamente.

Nell'esempio precedente, la maggioranza dei voter si trova nel datacenter di Redmond. Se il datacenter di Dublino ospita database attivi delle cassette postali e dispone di un gruppo di utenti locale, un'interruzione della connessione WAN determinerebbe un'interruzione del servizio di messaggistica per gli utenti di Dublino. Quando si verifica un'interruzione della connettività WAN, solo i membri del gruppo di disponibilità del database del datacenter di Redmond mantengono il quorum e continuano a fornire il servizio di messaggistica.

Per eliminare la rete WAN come singolo punto di errore quando è necessario fornire resilienza del sito per più datacenter che dispongono ciascuno di un gruppo di utenti attivo, è consigliabile distribuire più gruppi di disponibilità del database, in cui ogni DAG dispone della maggioranza dei voter in un datacenter separato. Quando si verifica un'interuzione della connettività WAN, la replica verrà bloccata fino al ripristino della connettività. Gli utenti potranno utilizzare il servizio di messaggistica, dal momento che ogni gruppo di disponibilità del database continua a servire il proprio gruppo di utenti locale.