Struttura di layout della copia del database

 

Si applica a: Exchange Server 2010 SP2, Exchange Server 2010 SP3

Ultima modifica dell'argomento: 2010-11-11

Quando si progetta una soluzione a elevata disponibilità per i server Cassette postali, è necessario assicurare disponibilità elevata ai vari componenti dell'infrastruttura, tra cui:

• Servizi di infrastruttura, quali Active Directory e Domain Name System (DNS)

• Server membri del gruppo di disponibilità del database (DAG, Database Availability Group)

• Singoli componenti di archiviazione, quali dischi, controller di archiviazione e ripiani

• Singoli componenti di rete, quali router, commutatori e aggregatori

• Rack per server e archivio

• Bus Power

• Datacenter

Ciascuna di queste aree di componenti rappresenta dei potenziali punti di errore, che vengono talvolta definiti domini di errore. Di conseguenza, il livello di disponibilità del DAG dipende in ultima analisi dalle modalità di progettazione della soluzione al fine di isolare e ridurre al minimo gli eventuali effetti negativi dei malfunzionamenti in uno di tali domini nell'ambiente DAG. Per fare in modo che i domini di errore siano indipendenti, ogni dominio di errore deve disporre di una copia del database. Inoltre, poiché un malfunzionamento determinerebbe la mancata disponibilità di più copie, non è richiesta più di una copia per dominio di errore.

Si consideri, ad esempio, uno scenario in cui si dispone di due copie di un database. Ogni copia viene memorizzata in un insieme separato di dischi, ma entrambe si trovano nello stesso array di archiviazione. Se per un qualsiasi motivo nell'array di archiviazione si verifica un errore o l'array non è più disponibile, entrambe le copie non saranno più disponibili. In questo esempio, il dominio di errore è l'array di archiviazione. Solo una singola copia del database delle cassette postali deve trovarsi sull'array. In caso contrario, se si verifica un errore nell'array, più copie (probabilmente tutte) del database non saranno più disponibili.

Durante la pianificazione dell'architettura delle cassette postali, considerare i seguenti aspetti ulteriori della pianificazione:

• Verranno distribuite più copie del database?

• Quante copie del database verranno distribuite?

• Si punterà a un'architettura con resilienza del sito?

• Quale tipo di modello di resilienza del server Cassette postali verrà distribuito?

• Quanti server Cassette postali verranno distribuiti?

• Quale modello di backup verrà utilizzato?

• Quale architettura di archiviazione verrà utilizzata?

Per informazioni dettagliate sulla pianificazione di questi aspetti, vedere Informazioni sui fattori di disponibilità elevata.

Sommario

Layout delle copie del database non bilanciate

Progettazione di un layout della copia del database bilanciata

Distribuzione del database attivo in uno scenario di esempio durante errori del server

Scenari di progettazione

Per informazioni sulle attività di gestione relative alla resilienza del sito e all'elevata disponibilità, vedere Gestione della disponibilità elevata e della resilienza del sito.

Layout delle copie del database non bilanciate

Per comprendere quante copie del database devono essere distribuite in un DAG, si consideri una progettazione DAG in fase di pianificazione da parte di Contoso, Ltd per la soluzione del server Cassette postali a elevata disponibilità. Contoso sta creando un DAG costituito dai seguenti componenti:

• 4 server Cassette postali

• 20 database delle cassette postali

• 2 copie di ogni database delle cassette postali

Tutti i server vengono distribuiti in un unico datacenter, ogni server dispone della propria archiviazione dedicata e ogni server viene distribuito nel proprio rack.

Contoso richiede che le due copie del database a elevata disponibilità (prive dell'intervallo, ad esempio) siano sempre disponibili e che la soluzione rimanga invariata anche nel caso di due interruzioni simultanee dei membri del DAG, senza ripercussioni negative sulla disponibilità dei database.

In base a tali requisiti, il layout della copia del database utilizzato viene mostrato nella figura seguente.

Layout della copia del database iniziale

Inizialmente, la progettazione sembra stabile poiché distribuisce le copie attive di ciascun database tra i quattro membri del DAG. Questa soluzione presenta tuttavia alcuni svantaggi. Il layout non è ottimale dal punto di vista delle risorse del server. Ad esempio, quando si verifica un errore in un singolo server, si avrà una distribuzione irregolare dei database, come illustrato nella figura seguente.

Layout della copia del database dopo un errore in un singolo server

L'errore del Server4 causa l'attivazione dei database da DB16 a DB20 sul Server1, anziché la distribuzione fra i tre server rimanenti. Il risultato è una distribuzione irregolare dei database delle cassette postali attivati e un utilizzo ineguale delle risorse del server. Rispetto agli altri due server rimanenti (Server2 e Server3), l'utilizzo del Server1 risulta raddoppiato.

Un altro problema è che il DAG non è in grado di contenere un numero di copie sufficienti per continuare a funzionare dopo due interruzioni del server in tutti i casi. Un altro errore del server potrebbe causare la mancata disponibilità del 50% dei database. Se si verifica un errore in Server1 e Server4 o se gli stessi non sono più disponibili reciprocamente, 10 database non saranno più disponibili, come illustrato nella figura seguente.

Layout della copia del database dopo un errore su due server

Questa soluzione non soddisfa il requisito fondamentale di persistenza e continuità operativa anche nel caso in cui si dovesse verificare un errore su due server. Per mantenere invariata l'operatività anche in caso di un errore su due server e mantenere attivi tutti i database, è necessario distribuire una terza copia e stabilire un nuovo layout.

Inizio pagina

Progettazione di un layout della copia del database bilanciata

La progettazione di un layout della copia del database bilanciata può richiedere il riesame di alcune scelte di progettazione, al fine di ottenere la soluzione ottimale. Durante la pianificazione del layout della copia del database, utilizzare i seguenti principi di progettazione:

• Ridurre al minimo gli errori nelle copie multiple del database delle cassette postali isolando reciprocamente ogni copia e posizionandole in domini di errore diversi. Ad esempio, non collocare più di una singola copia del database di uno specifico database delle cassette postali nello stesso rack del server o nello stesso array di archiviazione.

• Disporre le copie del database in modalità coerente e distribuita per assicurarsi che i database delle cassette postali attivi siano distribuiti uniformemente dopo un errore. La somma delle preferenze di attivazione di ogni copia del database su un server specifico deve essere identica o pressoché identica. Ciò determina una distribuzione all'incirca identica dopo un errore, presumendo che la replica sia integra e aggiornata.

Blocchi predefiniti

Per attenersi ai principi di progettazione indicati in precedenza, si consiglia di collocare le copie del database in una disposizione particolare che garantisca la distribuzione simmetrica di tutte le copie attive fra il maggior numero di server possibile. La disposizione delle copie del database si basa sul concetto di blocco predefinito.

Il primo blocco predefinito (noto come blocco predefinito di livello 1) si basa sul numero di server Cassette postali che ospiteranno le copie del database attive. Si supponga che il numero sia N. N definisce non solo il numero dei server Cassette postali, ma anche il numero dei database all'interno del blocco predefinito. Una copia attiva del database viene distribuita su ciascun server, formando uno schema diagonale. Come nell'esempio precedente, sono presenti 4 server Cassette postali e 20 database delle cassette postali. La dimensione del blocco predefinito di livello 1 è 4, come illustrato nella figura seguente.

Blocco predefinito di livello 1

Viene ripetuto lo stesso schema per ogni insieme rimanente di blocchi predefiniti di livello 1. Dal momento che esistono 20 database, sono presenti cinque insiemi di blocchi predefiniti di livello 1, come illustrato nella figura seguente.

Cinque blocchi predefiniti di livello 1 per 20 database

Quando si aggiunge una seconda copia del database, il posizionamento è diverso per ciascun insieme di blocchi predefiniti. Poiché un server ospita già la copia attiva, sono disponibili N – 1 server per ospitare la seconda copia del database. Quando si utilizza ciascuno di tali N – 1 server una volta, il risultato è una distribuzione simmetrica completa che forma il nuovo blocco predefinito più esteso. Di conseguenza, le dimensioni del nuovo blocco predefinito (noto come blocco predefinito di livello 2) diventano i database N × (N – 1). Ciò significa che la seconda copia del database per il primo database viene posizionata sul secondo server e ogni seconda copia successiva viene distribuita secondo uno schema diagonale all'interno del blocco predefinito. Una volta completato lo schema nell'insieme di blocchi predefiniti di livello 1, la posizione di inizio della seconda copia per il blocco successivo è offset per uno e quindi la seconda copia inizia sul terzo server.

Nell'esempio, le dimensioni del blocco predefinito ora diventano 4× (4 – 1) = 4× 3 = 12, indicando che 12 database costituiscono ciascun insieme di blocchi predefiniti di livello 2. Per l'insieme 1 di blocchi predefiniti di livello 1 (da DB1 a DB4), la seconda copia di DB1 viene posizionata su Server2, mentre per l'insieme 2 di blocchi predefiniti di livello 1 (da DB5 a DB8), la seconda copia di DB5 viene posizionata su Server3. Il posizionamento del server di inizio per ciascun insieme di blocchi predefiniti di livello 1 è offset dall'insieme di blocchi predefiniti di livello 1 precedente per un server. Il layout prosegue con il posizionamento della seconda copia di DB9 su Server4. In questo modo si ha la garanzia che, in caso di errore su Server1, vengono attivate le seconde copie in tutti e tre i server rimanenti anziché attivare più database sullo stesso server.

Blocco predefinito di livello 2 con tre blocchi predefiniti di livello 1

Questo schema viene ripetuto per ogni secondo insieme di blocchi predefiniti rimanente. Dal momento che sono presenti 20 database, in questo esempio vengono utilizzati due insiemi di blocchi predefiniti di livello 2. È opportuno notare che la seconda copia di DB13 si trova su Server2.

Blocco predefinito di livello 2 con due blocchi predefiniti di livello 1 rimanenti

Per comprendere meglio tale logica, è opportuno confrontare il posizionamento della copia del database per DB1, DB5 e DB9. Ogni singolo database dispone di una copia attiva ospitata su Server1. Se si verifica un errore in Server1, l'obiettivo è attivare le seconde copie del database sui server diversi rimanenti per ottenere una distribuzione del carico uniforme. A tale scopo, posizionare una seconda copia del database di DB1 su Server2, una seconda copia del database di DB5 su Server3 e una seconda copia del database di DB9 su Server4. È sufficiente ripetere lo schema iniziando da DB13. Le copie dei database rimanenti vengono aggiunte secondo uno schema diagonale, come illustrato nella figura seguente.

Posizionamento delle copie del database per una distribuzione uniforme

Il secondo blocco predefinito (da DB13 a DB20) contiene solo 8 database, non 12. Di conseguenza, questa struttura non sarà completamente simmetrica se si verifica un singolo errore. Per ottenere una distribuzione completamente simmetrica, pianificare l'architettura in modo che il numero dei database sia un multiplo della dimensione del blocco predefinito più grande. In questo esempio, i numeri ottimali sono 24, 36, 48 o 60 database e così via.

Quando si aggiunge una terza copia del database, è necessario posizionarla di nuovo in modo diverso per ogni gruppo di database N × (N – 1). Poiché sono disponibili solo N – 2 server da cui selezionare il posizionamento della terza copia del database, si verificheranno N – 2 variazioni. Il nuovo blocco predefinito (noto come blocco predefinito di livello 3) comprenderà i database N × (N – 1) × (N – 2). Pertanto, la terza copia del database per il primo database viene posizionata sul terzo server e ogni terza copia successiva viene distribuita secondo uno schema diagonale in base alla posizione di inizio nel nuovo blocco predefinito. Una volta completato lo schema nel primo insieme di blocchi predefiniti di livello 1, la posizione di inizio è offset per uno in modo che la terza copia sia posizionata nella quarta posizione.

In questo esempio, il blocco predefinito ora diventa 4 × (4 – 1) × (4 – 2) = 4 × 3 × 2 = 24, indicando che 24 database costituiscono ciascun insieme di blocchi predefiniti di livello 3. Per realizzare lo schema di posizionamento simmetrico dei database, collocare la terza copia di database di DB1 su Server3 (che rappresenta il primo server disponibile, dal momento che Server1 ospita la prima copia e Server2 ospita la seconda copia) e scostare ogni copia aggiuntiva di uno fino a raggiungere la fine dell'insieme di blocchi predefiniti 1 di livello 1. Per l'insieme successivo di blocchi predefiniti, posizionare nuovamente la terza copia di database sul server disponibile successivo (Server4) e continuare nello stesso modo fino a raggiungere DB12, che rappresenta la fine dell'insieme di blocchi predefiniti 1 di livello 2. Da DB13 a DB20, seguire lo stesso schema ma scostare il posizionamento della terza copia di database di uno in modo che non termini sugli stessi server da DB1 a DB12.

Layout bilanciato con tre copie del database e quattro server

Di nuovo, per comprendere meglio tale logica, è opportuno confrontare il posizionamento delle copie del database da DB1 a DB13. La copia attiva di tali database è ospitata su Server1 e la seconda copia del database è ospitata su Server2. Se si verifica un errore in tali server, l'obiettivo è attivare le terze copie di database sui server diversi rimanenti per ottenere una distribuzione del carico uniforme. Per ottenere ciò, posizionare la terza copia di database di DB1 su Server3 e la terza copia di database di DB13 su Server4. Coppie simili sono costituite da DB2 e DB14, DB3 e DB15 e così via. È sufficiente ripetere lo schema iniziando da DB25 (in questo esempio non viene utilizzato un numero elevato di database).

È opportuno notare che il terzo insieme di blocchi predefiniti (da DB1 a DB20) contiene solo 20 e non 24 database. Di conseguenza, questa struttura non sarà completamente simmetrica se si verifica un doppio errore. Di nuovo, per ottenere una distribuzione completamente simmetrica, pianificare l'architettura in modo che il numero dei database sia un multiplo della dimensione del blocco predefinito più grande. In questo esempio, i numeri ottimali sono 24, 48, o 72 database e così via.

Quando si aggiunge una quarta copia del database, è necessario posizionarla di nuovo in modo diverso per ogni gruppo di database N × (N – 1) × (N – 2). Il nuovo blocco predefinito comprende i database N × (N – 1) × (N – 2) × (N – 3). L'approccio logico è lo stesso e garantisce la distribuzione uniforme dei database all'interno del nuovo blocco predefinito nel caso in cui si verifichino errori in tre server.

Nell'esempio con quattro server, è presente solo una variazione legata al posizionamento della quarta copia del database (è disponibile un solo server rimanente). Di conseguenza, la dimensione del blocco predefinito rimane effettivamente con valore 24. Ciò è evidente anche quando si utilizza la seguente formula per la dimensione del blocco predefinito: 4 × 3 × 2 × (4 – 3) = 4 × 3 × 2 × 1 = 24.

Continuando ad aggiungere ulteriori copie di database, le dimensioni del blocco predefinito aumentano e la formula generale per la dimensione del blocco predefinito è Perm(N,M) = N × (N – 1) … (N – M + 1) = N!/(N – M)! = CNMM!, dove N = numero di server e M = numero di copie di database. La cosa diventa evidente quando si comprende che la distribuzione simmetrica completa delle copie del database viene ottenuta selezionando tutte le possibili permutazioni delle copie di database M nei server disponibili N.

Per l'utilizzo di questa metodologia, è opportuno tenere presente alcune avvertenze:

• La distribuzione di un numero di database non multiplo della dimensione del blocco predefinito più grande determina una distribuzione asimmetrica dei database attivi durante gli eventi di errore.

• La distribuzione delle architetture per contenere gli errori in più domini può determinare una distribuzione asimmetrica dei database attivi durante gli eventi di errore. Ciò accade perché le definizioni dei domini di errore impongono delle limitazioni al posizionamento delle copie di database, interrompendo la simmetria dello schema.

• La distribuzione delle soluzioni con resilienza del sito che comportano database esterni al sito *nel caso gli eventi lo richiedano può determinare una distribuzione asimmetrica dei database attivati nel datacenter secondario durante gli eventi di errore del server datacenter principale.

Inizio pagina

Distribuzione del database attivo in uno scenario di esempio durante errori del server

Utilizzando l'esempio precedente, nel caso si verifichi un errore in un server (ad esempio, un errore di Server4), i database delle cassette postali attivi sono distribuiti come illustrato nella figura seguente. Viene attivata la seconda copia per DB4, DB8, DB12, DB16 e DB20, indicata come Attiva in arancione.

Distribuzione della copia del database attiva dopo un singolo errore del server

Se si verifica un doppio errore del server (la terza copia viene attivata per alcuni database ed è indicata come Attiva in verde), i due server rimanenti, Server1 e Server3, disporranno di un numero uguale di database delle cassette postali attivati.

Distribuzione della copia del database attiva dopo un errore in due server

Tuttavia, poiché in questo esempio il numero dei database non è un multiplo della dimensione del blocco predefinito più grande (24 database), non tutti i gli eventi di errore in due server determineranno una distribuzione simmetrica.

Distribuzione della copia del database attiva dopo un diverso errore in due server

Inizio pagina

Scenari di progettazione

Per comprendere il principio di progettazione del layout della copia del database, inclusa la formula matematica associata, è necessario considerare altri due layout dal punto di vista dell'architettura.

Scenario di progettazione: Soluzione con resilienza del sito per la distribuzione attiva/passiva

In questo scenario, Contoso decide di distribuire la seguente architettura:

• Il DAG si estende su due datacenter, operando secondo un modello di distribuzione degli utenti attivo/passivo.

• Ogni server viene distribuito in un server rack separato.

• Ogni archiviazione del server è isolata dall'archiviazione degli altri server all'interno del datacenter.

• Sono presenti quattro server Cassette postali per datacenter.

• È presente un totale di 24 database delle cassette postali.

• L'ideale sarebbe disporre di quattro copie del database a elevata disponibilità e mantenere invariata l'operatività in caso di errore in due server o di un singolo errore nel datacenter.

In questo esempio, il blocco predefinito di livello 1 è 4, i database sono raggruppati in unità di quattro e le copie attive sono distribuite tra i quattro server nell'ambito del blocco predefinito.

Distribuzione omogenea della prima copia in un blocco predefinito

Per ogni server che ospita le copie attive, la seconda copia del database viene distribuita il più omogeneamente possibile fra tutti i server membri rimanenti, continuando con uno schema diagonale dal momento che ogni copia è isolata dall'altra. In questo esempio, il blocco predefinito di livello 2 diventa 12, divenendo l'insieme ricorrente ogni 12 database.

Distribuzione omogenea della seconda copia in un blocco predefinito

Poiché questa soluzione con resilienza del sito è per un modello di distribuzione degli utenti attivo/passivo con un numero pari di server e copie di database in entrambi i datacenter, la terza copia del database viene posizionata in uno schema diagonale tra Server5 e Server6, utilizzando il valore 4 del blocco predefinito di livello 1. In questo modo, si garantisce che Server5 e Server6 rispecchiano il posizionamento della prima copia del database da Server1 a Server4.

Distribuzione omogenea di una terza copia in un secondo blocco predefinito

Poiché questa soluzione con resilienza del sito è per un modello di distribuzione degli utenti attivo/passivo con un numero pari di server e copie di database in entrambi i datacenter, la quarta copia del database viene posizionata in uno schema diagonale tra Server5 e Server6, utilizzando il valore 12 del blocco predefinito di livello 2. In questo modo, si garantisce che Server5 e Server6 rispecchiano il posizionamento della seconda copia del database da Server1 a Server4.

Distribuzione omogenea di una quarta copia nel secondo blocco predefinito

Se si verifica un errore in un singolo server, i tre server rimanenti nel datacenter principale disporranno di un numero pari di database delle cassette postali attivati (8 per server).

Distribuzione delle copie dei database attive dopo un errore in un singolo server

Se si verificano due errori simultanei in un server, i due server rimanenti nel datacenter principale disporranno di un numero pari di database delle cassette postali attivati (10 per server), mentre 4 database verranno attivati nel datacenter secondario.

Distribuzione delle copie dei database attive dopo un errore in due server

Scenario di progettazione: domini di errore multipli

In questo esempio, Wingtip Toys decide di distribuire la seguente architettura:

• Tutti i server vengono distribuiti in un unico datacenter.

• I server vengono raggruppati in unità di tre.

• Ognuno dei tre server viene posizionato nello stesso rack con il relativo archivio.

• È disponibile un totale di 3 rack e 9 server.

• È presente un totale di 18 database delle cassette postali.

• L'ideale sarebbe disporre di tre copie del database a elevata disponibilità e mantenere invariata l'operatività in caso di errore in due server membri o di un singolo errore nel rack.

In questo esempio, il blocco predefinito di livello 1 è 6, quindi i database sono raggruppati in unità di 6 e le copie attive sono distribuite tra i sei server nell'ambito del blocco predefinito.

Layout della copia del database per il blocco predefinito di livello 1

Per ogni server che ospita le copie attive, la seconda copia del database viene ripartita il più omogeneamente possibile tra tutti i server membri rimanenti, garantendo allo stesso tempo che le due copie dello stesso database non vengano posizionate nello stesso rack del server. In questo esempio, anziché la formula del blocco predefinito di livello 2 di N × (N – 1), viene utilizzata la formula di N × (N – 2) per fare in modo che le due copie dello stesso database non vengano posizionate nello stesso rack. Ciò significa che il blocco predefinito di livello 2 è 6 × 4 = 24.

Layout della copia del database per la prima e la seconda copia

La terza copia del database è posizionata in uno schema diagonale tra i server, per fare nuovamente in modo che più copie dello stesso database non vengano posizionate nello stesso rack del server. In questo esempio, anziché la formula del blocco predefinito di livello 3 N × (N – 2), viene utilizzata la formula di N × (N – 2) × (N – 4) per fare in modo che due copie dello stesso database non vengano posizionate nello stesso rack. Ciò significa che il blocco predefinito di livello 6 × 4 × 2 = 48.

Layout della copia del database per la prima, la seconda e la terza copia

Se si verifica un errore in un singolo server, i cinque server rimanenti nel datacenter principale disporranno di un numero pressoché identico di database delle cassette postali attivati. Quattro server disporranno di 10 database attivati per server, mentre un server (il partner del rack) disporrà di 8 database attivati.

Conteggio e layout dei database attivi dopo un errore in un singolo server

Se si verificano due errori simultanei in un server (rack diversi), i quattro server rimanenti disporranno di un numero pressoché identico di database delle cassette postali attivati.

Conteggio e layout dei database attivi dopo un errore in due server (rack diversi)

Se si verificano due errori simultanei in un server (stesso rack), i quattro server rimanenti disporranno di un numero pressoché uguale di database delle cassette postali attivati.

Conteggio e layout dei database attivi dopo un errore in due server (stesso rack)

Inizio pagina

 ©2010 Microsoft Corporation. Tutti i diritti riservati.