Progettazione dell'archiviazione del server Cassette postali

 

Si applica a: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007

Ultima modifica dell'argomento: 2009-04-03

Disporre di una capacità sufficiente è di importanza fondamentale. Quando si esaurisce lo spazio su un disco in cui è installato un database, il database passa allo stato non in linea. Quando si esaurisce lo spazio su un disco in cui è presente un registro delle transazioni, tutti i database presenti nel gruppo di archiviazione passano allo stato non in linea. Spesso risulta difficile aggiungere spazio entro tempi brevi e l'esecuzione della compattazione non in linea per liberare spazio può richiedere tempi piuttosto lunghi. Nella maggior parte dei casi l'esaurimento dello spazio su disco provoca un'interruzione della disponibilità di uno o più database per un periodo di tempo che in genere supera gli obiettivi temporali di recupero (recovery time objectives).

In questo argomento vengono fornite informazioni su:

• Strumento di calcolo dei requisiti di archiviazione delle cassette postali per Exchange 2007

• Capacità dei numeri di unità logica (LUN) del database

• Capacità dei numeri di unità logica (LUN) dei registri

• I/O transazionale

• Previsione di IOPS di riferimento in Exchange 2007

• I/O non transazionale

• Numeri di unità logica (LUN) e dischi fisici

• Impatto della replica continua sulla progettazione dell'archiviazione

Strumento di calcolo dei requisiti di archiviazione delle cassette postali per Exchange 2007

Lo strumento di calcolo dei requisiti di archiviazione del ruolo del server Cassette postali di Exchange Server 2007 consente di determinare i requisiti di archiviazione (prestazioni e capacità I/O) e il layout dei numeri di unità logica (LUN) ottimale in base ai fattori forniti in input. Per progettare una soluzione di archiviazione ottimale per un server Cassette postali di Exchange 2007, è necessario considerare numerosi fattori di input, descritti in questo argomento.

Lo strumento di calcolo dei requisiti di archiviazione, a fronte di input specifici per l'organizzazione, fornisce le indicazioni consigliate per i requisiti di I/O e di capacità, nonché il layout ottimale dei numeri di unità logica (LUN).

Per ulteriori informazioni sullo strumento di calcolo dei requisiti di archiviazione e sul suo utilizzo, vedere Strumento di calcolo dei requisiti per il ruolo del server Cassette postali di Exchange 2007 (informazioni in lingua inglese) nel blog del team di Exchange. Da questa pagina Web è inoltre possibile eseguire il download dello strumento.

Nota

UNRESOLVED_TOKEN_VAL(exBlog)

Capacità dei LUN del database

Esistono molti punti relativi ai dati che possono essere utilizzati per determinare la dimensione di un numeri di unità logica (LUN) del database. Vi sono anche altri fattori da tenere in considerazione. Una volta considerati e calcolati tutti i fattori, si consiglia di includere un fattore di sovraccarico aggiuntivo per il LUN del database del 20%. Tale valore consente di tenere conto degli altri dati che si trovano nel database e che non vengono necessariamente visualizzati durante il calcolo delle dimensioni delle cassette postali e degli spazi vuoti. La struttura dei dati (tabelle, visualizzazioni, indici interni) all'interno del database, ad esempio, contribuisce ad aumentare la dimensione complessiva del database stesso Pertanto, se dopo aver letto le seguenti sottosezioni si determina un requisito di spazio pari a 120 GB, è consigliabile preventivare 144 GB, pari al 20% di sovraccarico di sicurezza per i numeri di unità logica (LUN) del database del gruppo di archiviazione.

Quota della cassetta postale

La prima metrica da capire è la dimensione della cassetta postale. Se si è a conoscenza della quantità di dati che un utente finale può archiviare nella propria cassetta postale, è possibile determinare il numero di utenti che possono essere ospitati nel server. Le dimensioni e le quote finali delle cassette postali possono cambiare, tuttavia definire un obiettivo rappresenta il primo passo nella determinazione della capacità richiesta. Ad esempio, se in un server sono presenti 5.000 utenti con una quota della cassetta postale pari a 250 MB, saranno necessari almeno 1,25 TB (terabyte) di spazio su disco. Se per le quote delle cassette postali non viene impostato un limite esatto, sarà difficile stimare la quantità di capacità necessaria.

Spazio vuoto del database

Per il calcolo della dimensione del database sul disco fisico non è sufficiente moltiplicare il numero di utenti per le quote degli utenti. Quando la maggioranza degli utenti non è prossima alla quota della propria cassetta postale, i database utilizzano una quantità minore di spazio e in questi casi lo spazio vuoto non presenta problemi per quanto riguarda la capacità. Il database stesso contiene sempre pagine vuote, ovvero dello spazio vuoto distribuito nel suo interno. Durante la manutenzione in linea, gli elementi contrassegnati per la rimozione dal database vengono rimossi, liberando in tal modo queste pagine. La percentuale di spazio vuoto cambia costantemente: immediatamente dopo la manutenzione in linea si ha la percentuale di spazio vuoto più elevata, mentre appena prima della manutenzione in linea si ha la percentuale più bassa.

La dimensione dello spazio vuoto nel database può essere stimata calcolando la quantità di posta inviata e ricevuta dagli utenti con cassette postali nel database. Ad esempio, se si dispone di cento cassette postali da 2 GB (totale di 200 GB) in un database in cui gli utenti inviano e ricevono una media di 10 MB di posta al giorno, lo spazio vuoto è pari a circa 1 GB (100 cassette postali × 10 MB per cassetta).

Se la manutenzione in linea non viene completata correttamente, la quantità di spazio vuoto può aumentare a dismisura e sarà impossibile effettuare una stima anche approssimativa. È importante che le attività operative includano una quantità di tempo sufficiente per l'esecuzione della manutenzione in linea ogni notte, in modo da assicurare il corretto completamento dell'operazione di manutenzione entro un intervallo di tempo di una settimana o anche inferiore.

Dumpster di database

Ciascun database dispone di un cosiddetto "dumpster" in cui vengono archiviati gli elementi eliminati in maniera non definitiva. Per impostazione predefinita, in Exchange Server 2007 gli elementi eliminati vengono archiviati per 14 giorni, inclusi quelli eliminati dalla cartella Posta eliminata. Per impostazione predefinita, rispetto a Exchange Server 2003, in Exchange 2007 il sovraccarico utilizzato dal dumpster di database viene aumentato in quanto gli elementi eliminati vengono archiviati per un periodo di tempo doppio. La quantità effettiva di spazio utilizzato per il dumpster dipende dalla dimensione di ciascun elemento e dalle impostazioni di mantenimento specifiche dell'organizzazione.

Al termine del periodo di mantenimento, tali elementi verranno rimossi dal database durante un ciclo di manutenzione in linea. Alla fine, si raggiungerà uno stato di stabilità in cui la dimensione del dumpster sarà l'equivalente di due settimane di posta in arrivo/in uscita come percentuale della dimensione del database. La percentuale esatta dipende dalla quantità di posta eliminata e dalle dimensioni delle singole cassette postali.

Il dumpster aggiunge una percentuale di sovraccarico al database in base alla dimensione della cassetta postale e alla velocità di recapito dei messaggi della cassetta postale. Ad esempio, con una velocità di recapito dei messaggi costante pari a 52 MB alla settimana, una cassetta postale da 250 MB con profilo molto alto archivierebbe nel dumpster circa 104 MB aggiungendo un sovraccarico del 41%. Per una cassetta postale da 1 GB per la quale nel dumpster vengono archiviati gli stessi 104 MB, l'aumento del sovraccarico è pari al 10%.

Dimensione effettiva della cassetta postale

Con il tempo, le cassette postali degli utenti raggiungeranno la quota assegnata. Per evitare che vengano superati i limiti della quota assegnata alla cassetta postale sarà necessario eliminare una quantità di posta equivalente alla quantità di posta in arrivo. Ciò significa che la dimensione del dumpster aumenterà fino a raggiungere un valore pari a due settimane di posta in arrivo/in uscita. Se la maggior parte degli utenti non ha raggiunto la quota della cassetta postale, verranno eliminati solo alcuni messaggi della posta in arrivo/in uscita, in modo da suddividere la crescita tra il dumpster e l'aumento della dimensione della cassetta postale. Ad esempio, una cassetta postale da 250 MB con il profilo messaggi molto alto che riceve 52 MB di posta alla settimana, con una dimensione media dei messaggi pari a 50 KB, utilizzerà 104 MB di spazio nel dumpster (41%) e 7.3 MB di spazio vuoto per una dimensione totale della cassetta postale pari a 360 MB. Un altro esempio è rappresentato da una cassetta postale da 2 GB con il profilo messaggi molto alto che riceve 52 MB di posta alla settimana e che utilizzerà 104 MB di spazio nel dumpster (5%) e 7.3 MB di spazio vuoto, per una dimensione totale della cassetta postale pari a 2,11 GB. Cinquanta cassette postali da 2 GB in un gruppo di archiviazione equivalgono a 105,6 GB di spazio.

Di seguito è riportata una formula per il dimensionamento del database che utilizza la cassetta postale da 2 GB:

Dimensione della cassetta postale = Quota della cassetta postale + Spazio vuoto + (Posta in arrivo settimanale × 2)

Dimensione della cassetta postale = 2,048 MB + (7.3 MB) + (52 MB × 2)

2,159 MB = 2,048 MB + 7.3 MB + 104 MB (5% in più rispetto alla quota)

Una volta progettata la dimensione effettiva della cassetta postale, è possibile utilizzare tale valore per determinare il numero massimo di utenti per database. Dividere la dimensione progettata della cassetta postale per la dimensione massima consigliata del database. Ciò consentirà anche di determinare il numero di database necessari per gestire il conteggio pianificato degli utenti, considerando database completamente compilati. Tenere presente che a causa di I/O non transazionale o di limitazioni dell'hardware, potrebbe essere necessario modificare il numero di utenti presenti in un singolo server. Alcuni amministratori preferiscono utilizzare più database per ridurre ulteriormente la dimensione del database. Tale approccio può risultare utile nelle finestre di backup e ripristino, provocando allo stesso tempo una maggiore complessità nella gestione di più database per server.

Indicizzazione del contenuto

L'indicizzazione del contenuto consente di creare un indice o un catalogo così che gli utenti finali possano eseguire le ricerche nella propria posta in modo semplice e rapido anziché scorrere manualmente il contenuto della cassetta postale. In Exchange 2007 viene creato un indice che occupa circa il 5% della dimensione totale del database e che viene posizionato nello stesso numero di unità logica (LUN) del database. Per l'indicizzazione del contenuto è necessario considerare come fattore una capacità ulteriore del 5% nella dimensione del LUN del database.

Manutenzione

Per un database che necessita di essere corretto o compattato non in linea è richiesta una capacità equivalente alla dimensione del database di destinazione più il 10%. Se si alloca una quantità di spazio sufficiente per un singolo database, un gruppo di archiviazione o un set di backup, sarà necessario disporre di ulteriore spazio per l'esecuzione di tali operazioni.

Gruppo di archiviazione di ripristino

Se si intende utilizzare un gruppo di archiviazione nell'ambito della propria strategia di ripristino di emergenza, sarà necessario disporre di una capacità sufficiente per gestire tutti i database che si desidera ripristinare contemporaneamente sul server.

Backup su disco

Molti amministratori eseguono backup di flusso in linea in una destinazione disco. Se la strategia di backup e ripristino comprende il backup su disco, è necessario disporre di una capacità sufficiente sul server per ospitare il backup. In base al tipo di backup utilizzato, tale capacità può essere pari alle dimensioni del database e dei registri, o grande quanto le dimensioni del database e di tutti i registri creati dall'esecuzione dell'ultimo backup completo.

Capacità LUN dei registri

I file di registro delle transazioni sono un record di tutte le transazioni eseguite dal modulo del database. Tutte le transazioni vengono prima scritte nel registro e, in seguito, vengono progressivamente scritte nel database. A differenza delle versioni precedenti di Exchange, le dimensioni dei file dei registri delle transazioni in Exchange 2007 sono state ridotte da 5 MB a 1 MB. Tale modifica è stata apportata per supportare le funzionalità di replica continua e per ridurre al minimo la quantità di dati perduti in caso di errore del sistema di archiviazione primario.

La tabella seguente consente di stimare il numero di registri delle transazioni generati in un server Cassette postali di Exchange 2007 se la dimensione media dei messaggi è pari a 50 KB.

Numero di registri delle transazioni generati per ciascun profilo di cassetta postale

Profilo cassetta postale	Profilo messaggi	Registri generati / cassetta postale
Basso	5 invii/20 ricezioni	6
Medio	10 invii/40 ricezioni	12
Alto	20 invii/80 ricezioni	24
Molto alto	30 invii/120 ricezioni	36
Altissimo	40 invii/160 ricezioni	48

Le linee guida seguenti definiscono le modalità in base alle quali la dimensione dei messaggi influisce sulla velocità di generazione dei registri:

• Se la dimensione media dei messaggi viene raddoppiata a 100 KB, il numero dei registri generati per la cassetta postale viene aumentato del fattore 1,9. Questo numero rappresenta la percentuale del database che contiene le tabelle degli allegati e dei messaggi, ossia il corpo e gli allegati dei messaggi.

• Se la dimensione dei messaggi aumenta oltre 100 KB, viene raddoppiata anche la velocità di generazione dei registri per la cassetta postale.

Ad esempio:

• Se il profilo della cassetta postale è Alto e la dimensione media dei messaggi è 100 KB, i registri generati per la cassetta postale sono 24 × 1,9 = 46.

• Se il profilo della cassetta postale è Alto e la dimensione media dei messaggi è 200 KB, i registri generati per la cassetta postale sono 24 × 3,8 = 91.

Fattori del backup e del ripristino

La maggior parte delle aziende che eseguono un backup notturno completo allocheranno una capacità equivalente a circa 3 giorni dei file di registro in un gruppo di archiviazione nel numero di unità logica (LUN) del registro delle transazioni in modo da evitare che errori nel backup provochino l'esaurimento dello spazio sull'unità che ospita i registri, un evento che provocherebbe lo smontaggio del gruppo di archiviazione.

La definizione della dimensione dei LUN di registro dipende in qualche maniera dal piano di backup e ripristino. Ad esempio, se il proprio piano consente di tornare indietro di due settimane e di riprodurre tutti i registri generati da allora, sarà necessario uno spazio pari a quello occupato dai file di registro in due settimane. Se il piano di backup comprende backup differenziali giornalieri e backup completi settimanali, i numeri di unità logica (LUN) dei registri dovrà essere maggiore dello spazio equivalente a un'intera settimana di registri in modo da consentire sia il backup che la riproduzione durante il ripristino.

Operazioni di spostamento delle cassette postali

Lo spostamento delle cassette postali è un fattore primario di capacità per le distribuzioni di cassette postali di grandi dimensioni. In molte società di grandi dimensioni, ogni notte o ogni settimana viene spostata una determinata percentuale di utenti in database, server o siti diversi. Se questo è il caso della propria organizzazione, potrebbe essere consigliabile fornire ulteriore capacità ai numeri di unità logica (LUN) dei registri per garantire che la migrazione degli utenti venga eseguita senza problemi. Mentre nel server di origine vengono registrate le eliminazioni di record, le cui dimensioni sono ridotte, sul server di destinazione tutti i dati trasferiti devono innanzitutto essere scritti nei registri delle transazioni. Se si generano 10 GB di file di registro in un giorno e si mantiene un buffer di tre giorni pari a 30 GB, lo spostamento di 50 cassette postali da 2 GB (100 GB) riempirà i numeri di unità logica (LUN) dei registri di destinazione dando luogo a un intervallo di tempo di inattività. In questi casi è necessario allocare una capacità maggiore per i LUN dei registri in modo da agevolare le operazioni di spostamento delle cassette postali.

Fattore di crescita dei registri

Nella maggior parte delle distribuzioni, in fase di creazione de numero di unità logica (LUN) dei registri è consigliabile aggiungere un fattore di sovraccarico pari al 20% della dimensione dei registri dopo aver valutato tutti gli altri fattori in modo da garantire

Esempio di pianificazione della capacità delle cassette postali

Nel seguente esempio viene illustrato il dimensionamento appropriato per un ambiente che dispone di 4.000 cassette postali da 1 GB con profilo messaggi molto alto nel caso di un singolo server di cassette postali in cluster in un ambiente di replica continua cluster. Tali cassette postali ricevono una media di 52 MB di posta alla settimana, con una dimensione media dei messaggi pari a 50 KB. Nella tabella seguente vengono forniti valori di esempio che determinano la dimensione effettiva della cassetta postale.

Valori di esempio per la determinazione della dimensione effettiva della cassetta postale su disco

Dimensione della cassetta postale	Dimensione dumpster (2 settimane)	Spazio vuoto	Dimensione totale su disco
1 GB	104 MB ( 2 x 52 MB)	7.3 MB	1,11 GB (+ 11%)

In questo ambiente, ciascun utente utilizza 1,11 GB di spazio su disco. La dimensione massima consigliata di un database in un ambiente di replica continua cluster è di 200 GB, quindi il server deve ospitare non più di 180 cassette postali per database. Per supportare 4.000 cassette postali, è necessario disporre di 23 database e, in questo ambiente, anche di 23 gruppi di archiviazione. Un ambiente di replica continua cluster richiede un database per gruppo di archiviazione, quindi ciascun database si trova nel proprio gruppo di archiviazione. Ciò determina un conteggio finale di 174 cassette postali per gruppo di archiviazione. In base al numero di cassette postali e alla loro dimensione effettiva la dimensione del database è pari a 193 GB, come illustrato nella tabella seguente.

Requisiti di capacità dei database

Cassette postali per database	Numero totale di database	Requisiti di dimensione dei database
174	23	193 GB

Al fine di garantire che il server Cassette postali non incorra in interruzioni dovute a problemi di allocazione dello spazio, è necessario dimensionare adeguatamente anche i registri delle transazioni in modo da soddisfare le esigenze di spazio determinate dai registri generati durante la creazione del set di backup. Molte organizzazioni che utilizzano una strategia di backup completo giornaliero pianificano in tre volte la frequenza di generazione del registro giornaliero nel caso in cui si verifichi un errore nel backup. Quando viene effettuato un backup settimanale dapprima completo, quindi differenziale o incrementale, per gestire un ripristino è necessaria una capacità di registro pari ad almeno una settimana. Se si suppone che una cassetta postale con un profilo messaggi molto alto generi in media 42 registri delle transazioni al giorno, un server con 4.000 cassette postali genererà quotidianamente 168.000 registri delle transazioni. Ciò implica che ogni gruppo di archiviazione genererà 7.304 registri. Viene spostato il 10% delle cassette postali alla settimana in un giorno (sabato) e il regime di backup include backup completi settimanali e backup incrementali giornalieri. Il server, inoltre, è in grado di attendere 3 giorni prima di eseguire il troncamento dei registri. Come illustrato nella tabella seguente, nel server sono necessari 38,8 GB di spazio per ciascun gruppo di archiviazione.

Requisiti di capacità dei registri

Registri per gruppo di archiviazione	Dimensione del file di registro	Dimensione del registro giornaliero	Dimensione della cassetta postale di spostamento	Dimensione del ripristino incrementale	Requisiti di dimensione dei registri
7,304	1 MB	7,13 GB	17 GB (17 × 1 GB)	21,4 GB (3 × 7,13 GB)	38,8 GB (17.4 + 21.4)

Il numero di unità logica (LUN)dei registri delle transazioni deve essere sufficientemente grande da gestire entrambi i registri generati dall'operazione di spostamento delle cassette postali e da disporre di spazio sufficiente per ripristinare i registri di una settimana.

I/O transazionale

L'I/O transazionale è l'I/O del disco causato dagli utenti che utilizzano il server. Ad esempio, la ricezione, l'invio e l'eliminazione di elementi danno luogo a operazioni di I/O del disco. Gli utenti di Microsoft Outlook che non utilizzano la modalità cache sono direttamente interessati quando la latenza del disco risulta scarsa. Quest'ultimo è uno dei problemi fondamentali da affrontare nella fase di progettazione dell'archiviazione. Per l'archiviazione sono stati ridotti i requisiti dell'I/O transazionale e, con la replica continua, l'elevata disponibilità non dipende più dall'utilizzo della costosa tecnologia di archiviazione Fibre Channel, sebbene quest'ultima rimanga ancora una buona soluzione.

Concetti relativi a IOPS (I/O al secondo)

Nelle versioni precedenti di Exchange Server una metrica fondamentale per il dimensionamento dell'archiviazione era la quantità di operazioni di I/O al secondo (IOPS, I/O per second) del database utilizzate da ciascun utente. Per misurare le operazioni di IOPS degli utenti, considerare il numero di operazioni di I/O (sia di lettura che di scrittura) nel LUN del database per un gruppo di archiviazione e dividerlo per il numero di utenti presenti nel gruppo di archiviazione. Ad esempio, 1.000 utenti che utilizzano 1.000 operazioni di I/O nel LUN del database indicano che si dispone di 1,0 operazioni di IOPS per utente.

Misurazione di IOPS di riferimento

Se si utilizza una versione precedente di Exchange Server e sono state calcolate le operazioni IOPS di riferimento, tenere presente che il valore di riferimento sarà influenzato da Exchange 2007 per i motivi seguenti.

• Il numero di utenti sul server influisce sulla cache del database per utente complessiva.

• La quantità di RAM influisce sull'aumento della dimensione della cache del database. Più grande è la cache di database, maggiore sarà il numero di riscontri di lettura nella cache e minore sarà il numero di operazioni I/O di lettura del database.

L'aspetto fondamentale è che la conoscenza del numero di operazioni di IOPS in un determinato server non è sufficiente a pianificare un'intera azienda, in quanto la quantità di RAM, il numero di utenti e il numero dei gruppi di archiviazione differiranno da server a server. Una volta che si è a conoscenza del numero effettivo di operazioni di IOPS, è consigliabile applicare ai calcoli un fattore di sovraccarico di I/O pari al 20% a titolo di margine di sicurezza. Non è consigliabile compromettere le prestazioni nel momento in cui, ad esempio, le attività richiedono maggiori risorse rispetto al normale.

Cache del database

Una versione a 64 bit di Windows Server su cui è in esecuzione la versione a 64 bit di Exchange 2007 aumenta sostanzialmente lo spazio indirizzo virtuale e consente a Exchange di aumentare la dimensione della cache del database, di ridurre le operazioni di I/O di lettura del database e di abilitare fino a 50 database per server.

La riduzione del numero di operazioni di lettura del database varia in base alla dimensione della cache del database disponibile sul server e al profilo dei messaggi degli utenti. Per indicazioni sulla memoria e sui gruppi di archiviazione, vedere Pianificazione delle configurazioni dei processori. Secondo tali indicazioni, in Exchange 2003 l'I/O transazionale può essere ridotto fino al 70%. La dimensione della cache del database per utente è un fattore fondamentale nella riduzione effettiva delle operazioni di I/O.

Nella tabella seguente viene illustrato l'aumento della dimensione della cache del database per utente confrontando i 900 MB predefiniti in Exchange 2003 con i 5 MB di cache del database per utente in Exchange 2007. È questa cache aggiuntiva del database a consentire un maggior numero di riscontri di lettura nella cache, riducendo le operazioni di lettura del database a livello di disco.

Dimensioni della cache del database in base al conteggio delle cassette postali

Conteggio cassette postali	Cassetta postale (MB)/Cache del database di Exchange 2003	Cassetta postale (MB)/Cache del database di Exchange 2007	Aumento della cache del database in Exchange 2003
4,000	0.225	5	23 volte
2,000	0.45	5	11 volte
1,000	0.9	5	6 volte
500	1.8	5	3 volte

Previsione di IOPS di riferimento in Exchange 2007

I due fattori più importanti che possono essere utilizzati per prevedere l'IOPS del database di Exchange 2007 sono la quantità di cache del database per utente e il numero di messaggi che ciascun utente invia e riceve al giorno. La seguente formula è basata su un utente standard che utilizza Office Outlook 2007 nella modalità cache di Exchange ed è stato verificata come attendibile con un margine del 20% circa. Altri tipi di client e scenari di utilizzo potrebbero produrre risultati non attendibili. Le previsioni sono valide solo per le dimensioni della cache del database dell'utente comprese tra 2 e 5 MB. La formula non è stata convalidata con utenti che inviano e ricevono più di 150 messaggi al giorno. La dimensione media del messaggio per la convalida della formula è di 50 KB, ma la dimensione del messaggio non è un fattore primario per le operazioni di IOPS.

Nella tabella seguente vengono forniti i valori stimati relativi alle operazioni di IOPS per utente che possono essere utilizzati al fine di prevedere i requisiti delle operazioni IOPS di riferimento di Exchange 2007.

Cache del database e stima delle operazioni IOPS per utente in base al profilo utente e all'attività dei messaggi

Tipo utente (profilo di utilizzo)	Invio/ricezione giornaliero di messaggi con una dimensione di circa 50 KB	Cache del database per utente	Operazioni di IOPS stimate per utente
Basso	5 invii/20 ricezioni	2 MB	0.11
Medio	10 invii/40 ricezioni	3,5 MB	0.18
Alto	20 invii/80 ricezioni	5 MB	0.32
Molto alto	30 invii/120 ricezioni	5 MB	0.48
Altissimo	40 invii/160 ricezioni	5 MB	0.64

Per stimare la dimensione della cache del database, sottrarre 2.048 MB (3.072 se si utilizza la replica continua locale) dalla quantità di memoria totale installata nel server Exchange e dividere tale quantità per il numero di utenti. Ad esempio, per un server con 3.000 utenti e 16 GB di RAM, sottrarre 2 GB per il sistema, lasciando 14 GB di RAM totali ossia 4,66 MB per utente (14 GB / 3.000 = 4,66 MB).

Se la dimensione media della cache del database per utente è pari a 4,66 MB e il numero medio di messaggi inviati e ricevuti al giorno è 60, è possibile stimare il numero di operazioni di lettura e scrittura sul database.

• Operazioni di lettura dal database   Moltiplicare i 60 messaggi al giorno per 0,0048 ottenendo come risultato 0,288. Quindi, elevare la quantità di memoria cache del database per cassetta postale (4,66 MB) alla -0,65 (5 ^ -0.65), che dà come risultato 0,3622. Infine, moltiplicare le due cifre ottenute, ottenendo il risultato di 0,104 di operazioni di lettura del database per utente (0,288 × 0,3622 = 0,104).

• Operazioni di scrittura sul database   Moltiplicare il numero di messaggi per utente (60) per 0,00152, ottenendo come risultato 0,0912 operazioni di scrittura sul database per utente.

La formula da utilizzare è:

((0.0048 × M) × (D^-0,65)) + (0,00152 * M) = totale operazioni IOPS sul database

dove M è il numero di messaggi e D è la cache del database per utente. Il totale di operazioni di IOPS sul database per utente è composto dall'addizione delle operazioni di lettura e scrittura. In questo esempio, il totale è 0,189:

((0.0048 × 60) × (4.66 ^ -0.65)) + (0.00152 × 60) = 0.189

Il grafico seguente dimostra la riduzione del numero di letture e scritture nel database ottenuto utilizzando Exchange 2007 con 4.000 cassette postali da 250 MB simulando Outlook 2007 in modalità cache di Exchange e con la memoria consigliata per il server.

Riduzione delle operazioni IOPS in Exchange Server 2007 in confronto a Exchange Server 2003

Impatto dei client in modalità in linea

A differenza dei client in modalità cache di Exchange, tutte le operazioni dei client in modalità in linea sono relative al database. Di conseguenza, le operazioni I/O di lettura dal database aumentano. Qualora la maggior parte dei client operi in modalità in linea, quindi, utilizzare le seguenti indicazioni:

• I client in modalità in linea da 250 MB aumentano il numero di operazioni di lettura dal database di un fattore 1,5 rispetto ai client in modalità cache di Exchange. Al di sotto di 250 MB, l'impatto è trascurabile.

• Con il raddoppiare della dimensione delle cassette postali, raddoppiano anche le operazioni IOPS di lettura dal database, supponendo che la distribuzione degli elementi tra le cartelle principali rimanga invariata.

Nel grafico seguente vengono illustrate le operazioni IOPS in base alla dimensione della cassetta postale.

Aumento delle operazioni IOPS di lettura dal database con l'aumentare della dimensione delle cassette postali

Durante le verifiche si è inoltre dimostrato che l'aumento della cache del database al di sopra del valore di 5 MB per cassetta postale non offre alcun vantaggio significativo ai fini della riduzione dei requisiti I/O di lettura dal database. Nel grafico seguente viene illustrato il caso di cassette postali da 2 GB con client in modalità in linea e gli effetti sulla riduzione dei requisiti I/O di lettura dal database dell'aumento della cache al di sopra di 5 MB.

Riduzione delle operazioni IOPS di lettura dal database con l'aumentare della dimensione della cache per cassetta postale

Alla luce di questi dati, è possibile trarre le considerazioni seguenti:

• Se appropriato, distribuire client in modalità cache. Per ulteriori informazioni, vedere la successiva sezione "Numero di elementi per cartella".

• Assicurarsi di tener conto dei requisiti I/O in fase di progettazione dell'archiviazione del database.

Per ulteriori fattori relativi alle operazioni IOPS, ad esempio i client di terze parti, vedere Ottimizzazione del sistema di archiviazione per Exchange Server 2003.

Rapporti operazioni di lettura/scrittura del database

In Exchange 2003 il rapporto tra operazioni di lettura e scrittura del database era generalmente 2:1, ossia il 66% delle operazioni di lettura. Con Exchange 2007 la cache del database, di dimensioni superiori, consente di ridurre il numero di operazioni di lettura del database sul disco dando luogo, a sua volta, a una riduzione delle operazioni di scrittura come percentuale dell'I/O complessivo. Se si seguono i consigli relativi alla memoria e si utilizza la modalità cache di Exchange, il rapporto tra lettura e scrittura dovrebbe avvicinarsi a 1:1 ovvero il numero delle operazioni di lettura dovrebbe essere pari al 50% delle operazioni complessive.

Quando si utilizza Outlook in modalità in linea o si utilizzano i motori di ricerca desktop, il rapporto tra operazioni di lettura e scrittura aumenterà leggermente a favore delle operazioni di lettura, in base alla dimensione della cassetta postale. Se il numero di operazioni di I/O di scrittura risulta percentualmente superiore, la scelta di un determinato tipo di RAID ne sarà influenzata in quanto RAID5 o RAID6 comportano dei costi significativi relativi alle operazioni di scrittura. Per ulteriori informazioni su come scegliere la soluzione appropriata di RAID per i server in uso, vedere Tecnologia di archiviazione.

Rapporto registro/database

In Exchange 2003 un registro delle transazioni per un gruppo di archiviazione richiede circa il 10% di operazioni di I/O rispetto a quelle dei database nel gruppo di archiviazione. Ad esempio, se il LUN del database utilizza 1.000 operazioni di I/O, il LUN dei registri ne utilizzerà approssimativamente 100. Grazie alla riduzione delle operazioni di lettura del database in Exchange 2007, alla dimensione minore dei file di registro e alla possibilità di disporre di più gruppi di archiviazione, il rapporto delle operazioni di scrittura registro/database è di circa 3:4. Ad esempio, se il numero di unità logica (LUN) del database utilizza 500 operazioni di scrittura di I/O, il LUN del registro ne utilizzerà approssimativamente 375.

Dopo aver misurato o previsto le operazioni dell'I/O transazionale del registro, applicare un fattore di sovraccarico di I/O del 20% per garantire un margine di sicurezza sufficiente nei periodi in cui sono richieste maggiori risorse. Inoltre, quando si utilizza la replica continua, i registri delle transazioni chiusi devono essere letti e inviati a una seconda posizione. Tale sovraccarico rappresenta un 10% aggiuntivo nelle letture dei registri. Se il registro delle transazioni per un gruppo di archiviazione utilizza 375 operazioni di I/O di scrittura, si possono prevedere 37,5 ulteriori operazioni di I/O di lettura quando si utilizza la replica continua.

Conteggio elementi per cartella

In Informazioni sull'impatto sulle prestazioni di un numero elevato di elementi e delle visualizzazioni con restrizioni viene descritto l'impatto sulle prestazioni dei dischi dovuto al numero di elementi nelle cartelle principali, nonché al tipo e alla modalità utilizzata dai client.

Un metodo per ridurre le operazioni di I/O del server consiste nell'utilizzo di Outlook 2007 nella modalità cache di Exchange. La sincronizzazione iniziale delle cassette postali è un'operazione dispendiosa. Tuttavia, man mano che le dimensioni delle cassette postali aumentano con il tempo, il carico del sottosistema del disco viene trasferito dal server Exchange al client Outlook. Ciò significa che la presenza di un numero elevato di elementi nella Posta in arrivo di un utente o la ricerca in una cassetta postale da parte di un utente influenzerà poco le prestazioni del server. Inoltre, gli utenti che utilizzano la modalità cache di Exchange e che dispongono di cassette postali di grandi dimensioni potrebbero necessitare di computer più veloci rispetto a coloro che dispongono di cassette postali di dimensioni ridotte (in base alla soglia specifica dell'utente di prestazioni accettabili). Quando si esegue la distribuzione dei computer client su cui viene eseguito Outlook 2007 nella modalità cache di Exchange, è necessario tenere presente quanto segue in merito alle dimensioni /.OST delle cassette postali:

• Fino a 5 GB: Questa dimensione consente di ottenere buone prestazioni sulla maggior parte dell'hardware.

• Tra 5 e 10 GB: Questa dimensione è tipicamente dipendente dall'hardware. Pertanto, se si dispone di un disco rigido rapido e di molta RAM, le prestazioni saranno migliori. Tuttavia, con i dischi rigidi più lenti, come le unità normalmente disponibili in computer portatili o le unità SSD (Solid State Drive) di prima generazione, è possibile che si verifichino interruzioni dell'applicazione durante la risposta delle unità.

• Oltre 10 GB: Con questa dimensione iniziano a verificarsi brevi interruzioni con la maggior parte degli hardware.

• Molto grande (da 25 GB): Questa dimensione aumenta la frequenza di interruzioni brevi, specialmente durante il download di nuovi messaggi di posta elettronica. In alternativa, è possibile utilizzare gruppi di invio/ricezione per sincronizzare manualmente la posta.

Nota

Queste indicazioni sono basate sull'installazione di un aggiornamento cumulativo per Outlook 2007 Service Pack 1 o successivi, come descritto nell'articolo 961752 della Microsoft Knowledge Base, Descrizione del pacchetto hotfix Outlook 2007 (Outlook.msp): 24 febbraio 2009.

Se si verificano problemi legati alle prestazioni di Outlook 2007 nella distribuzione in modalità cache di Exchange, vedere l'articolo 940226 della Microsoft Knowledge Base, Come risolvere problemi di prestazioni in Outlook 2007.

Sia Outlook Web Access che Outlook in modalità in linea archiviano gli indici ed eseguono ricerche dei dati in base alla copia del server. Per cassette postali di dimensioni relativamente grandi, questo genera all'incirca il doppio di operazioni di IOPS per cassetta postale di un client in modalità cache di Exchange di dimensioni adeguate. Il numero di operazioni di IOPS per cassetta postale relativo a cassette postali di grandi dimensioni è ancora più elevato. La prima volta che si ordina una visualizzazione in una modalità nuova, viene creato un indice generando numerose operazioni di I/O di lettura nel LUN del database. Gli ordinamenti successivi in un indice attivo non sono onerosi.

Un caso cui prestare attenzione è quello di un utente che supera il numero massimo di indici archiviabili in Exchange. Per Exchange 2007 questo numero è pari a 11. Quando l'utente sceglie di utilizzare un altro tipo di ordinamento, creando così il dodicesimo indice, si verificheranno operazioni di I/O del disco aggiuntive. Poiché questo indice non viene archiviato, le relative operazioni di I/O del disco verranno eseguite nuovamente ogni volta che l'utente eseguirà l'ordinamento. A causa delle elevate operazioni di I/O che possono essere generate in uno scenario simile, non è consigliabile archiviare più di 20.000 elementi nelle cartelle principali quali Posta in arrivo e Posta inviata. La creazione di più cartelle di livello superiore o di sottocartelle in Posta in arrivo e Posta inviata consentirà di ridurre notevolmente il dispendio di risorse associato alla creazione dell'indice a condizione che il numero di elementi in una cartella non superi 20.000. Per ulteriori informazioni su come i conteggi degli elementi influiscono sulle prestazioni dei server Cassette postali, vedere Recommended Mailbox Size Limits (informazioni in lingua inglese) e Informazioni sull'impatto sulle prestazioni di un numero elevato di elementi e delle visualizzazioni con restrizioni.

Nota

UNRESOLVED_TOKEN_VAL(exBlog)

Per ulteriori informazioni sui miglioramenti disponibili, vedere l'articolo 968009 della Microsoft Knowledge Base, L'aggiornamento cumulativo di febbraio 2009 miglioramenti in Outlook 2007.

I/O non transazionale

L'I/O transazionale si verifica in risposta all'azione diretta di un utente, ha in genere la priorità più elevata ed è al centro della progettazione dell'archiviazione. La riduzione dell'I/O transazionale rende l'I/O non transazionale più importante. In presenza di cassette postali di grandi dimensioni, in particolare nel caso di quelle da 2 GB, molte aziende non si limitano a raddoppiare la capacità a disposizione degli utenti, ma addirittura, in alcuni casi, la decuplicano. Un esempio di questo tipo è rappresentato dal passaggio da 200 MB a 2 GB. Quando si verifica un aumento così significativo della quantità di dati presenti su disco, nella pianificazione del sistema di archiviazione è necessario tenere in considerazione e calcolare le operazioni di I/O non transazionale.

Indicizzazione del contenuto

In Exchange 2007, i messaggi vengono indicizzati durante la ricezione, provocando un piccolo sovraccarico delle operazioni di I/O del disco. La ricerca in base all'indice in Exchange 2007 è circa 30 volte più veloce rispetto alla ricerca in Exchange 2003.

Gestione record di messaggistica

La Gestione record di messaggistica è una nuova funzionalità di Exchange 2007 che consente agli amministratori e agli utenti di gestire le cassette postali. È possibile impostare i criteri per spostare o eliminare la posta in base a soglie specifiche, ad esempio una data di scadenza. La Gestione record di messaggistica è una ricerca per indicizzazione pianificata, eseguita sul database con un'operazione di lettura sincrona simile al backup e alla manutenzione in linea. Lo spazio richiesto su disco della Gestione record di messaggistica dipende dal numero di elementi per i quali è necessaria un'azione (ad esempio, l'eliminazione o lo spostamento).

Si consiglia di non eseguire la Gestione record di messaggistica contemporaneamente al backup o alla manutenzione in linea. Se si utilizza la replica continua, è possibile distribuire i backup del servizio Copia Shadow del volume (VSS, Volume Shadow Copy Service) nella copia passiva, concedendo una quantità maggiore di tempo per la manutenzione in linea e la gestione dei record di messaggistica, in modo tale da evitare interferenze fra tali attività e con le attività degli utenti.

Manutenzione in linea

Durante l'esecuzione della manutenzione in linea del database, vengono eseguite numerose operazioni quali, ad esempio, la rimozione definitiva degli elementi eliminati e la deframmentazione in linea del database. La manutenzione genera operazioni di lettura, mentre la deframmentazione in linea genera operazioni sia di lettura che di scrittura. La quantità di tempo impiegata per il completamento della manutenzione è proporzionale alla dimensione del database e può costituire un fattore limitante per la crescita di quest'ultima. Per ulteriori informazioni sulla manutenzione in linea, vedere Store Background Processes Part I (informazioni in lingua inglese).

Nota

UNRESOLVED_TOKEN_VAL(exBlog) 

Backup e ripristino

L'amministratore ha a disposizione diversi metodi per l'esecuzione del backup e del ripristino. La metrica fondamentale con il backup e il ripristino è la velocità di trasmissione, ovvero il numero di megabyte al secondo che possono essere copiati nei e dai LUN di produzione. Una volta determinata la velocità di trasmissione, è necessario valutare se è sufficiente per soddisfare i criteri del contratto di servizio per il backup e ripristino. Ad esempio, se si ha necessità di completare un backup in 4 ore, potrebbe essere necessario aggiungere spazio su disco. In base alla configurazione dell'hardware, è possibile ottenere buoni risultati modificando la dimensione dell'unità di allocazione. Questa modifica può essere utile sia per i backup di flusso in linea sia per il controllo dell'integrità eseguito dall'Utilità di database del server di Exchange (Eseutil.exe) durante un backup del servizio Copia Shadow del volume.

In presenza di 2.000 utenti su un server, il passaggio da una cassetta postale da 200 MB a una da 2 GB decuplica la dimensione del database. Molti amministratori non sono abituati a dover gestire grandi quantità di dati su un unico server. Si prenda in considerazione un server con 2.000 cassette postali da 2 GB. In base al sovraccarico descritto in precedenza, la quantità di dati risultante è superiore a 4 TB. Se si è in grado di raggiungere una velocità di backup pari a 175 GB/ora (48 MB/min), saranno necessarie almeno 23 ore per eseguire il backup del server. Un'alternativa per i server che non utilizzano la replica continua locale (LCR) o la replica continua cluster (CCR) può essere l'esecuzione di un backup completo di 1/7 dei database ogni giorno e di un backup incrementale dei database rimanenti, come illustrato nella tabella seguente.

Esempio di routine di backup settimanale

Tipo di backup	Giorno 1	Giorno 2	Giorno 3	Giorno 4	Giorno 5	Giorno 6	Giorno 7
Completa	DB 1-2	DB 3-4	DB 5-6	DB 7-8	DB 9-10	DB 11-12	DB 13-14
Incrementale	DB 3-14	DB 1-2 DB 5-14	DB 1-4 DB 7-14	DB 1-6 DB 9-14	DB 1-8 DB 11-14	DB 1-10 DB 13-14	DB 1-12

Come illustrato nella tabella precedente, queste operazioni comporterebbero l'esecuzione del backup notturno di una quantità di dati pari a circa 650 GB, per un tempo totale di 3,7 ore alla velocità di 175 GB all'ora. Alcune soluzioni possono raggiungere velocità effettive superiori o inferiori. Tuttavia, nel caso di cassette postali di grandi dimensioni può essere necessario adottare approcci diversi.

Con la replica continua locale e la replica continua cluster, la copia passiva costituisce il primo livello di difesa. Il ripristino da backup sarà necessario solo in caso di errore sia nella copia attiva che in quella passiva o se entrambe non sono disponibili. L'operazione di recupero dei registri incrementali eseguita in più giorni può richiedere del tempo aggiuntivo. Per questo motivo, il backup incrementale viene utilizzato raramente in una soluzione di recupero rapido, come i cloni del servizio Copia Shadow del volume e la replica continua cluster. Con un clone del servizio Copia Shadow del volume, il recupero dei dati è rapido e l'aggiunta di una minima quantità di tempo per la riesecuzione dei registri può essere accettabile, così da contenere i tempi di backup entro quelli previsti dal contratto di servizio del backup.

Backup di flusso in linea

Con i backup di flusso è consigliabile separare l'I/O di flusso (origine e destinazione) in modo che più gruppi di archiviazione sottoposti a backup non richiedano contemporaneamente le stesse risorse disco. Indipendentemente dal fatto che la destinazione sia un disco o un nastro, esisterà un limite nella velocità di trasmissione sui dischi fisici e sui controller univoco per ciascuna soluzione hardware. È probabile che sia necessario isolare alcuni gruppi di archiviazione per massimizzare il numero di operazioni di backup simultanee e la velocità di trasmissione in modo da ridurre al minimo l'intervallo di esecuzione del backup. Nella tabella seguente viene descritto un esempio di due backup simultanei di 14 database.

Esempio di routine di backup simultanea

Numero backup	LUN 1	LUN 2	LUN 3	LUN 4	LUN 5	LUN 6	LUN 7
Primo backup	gruppo di archiviazione (SG) 1	SG 2	SG 3	SG 4	SG 5	SG 6	SG 7
Secondo backup	SG 8	SG 9	SG 10	SG 11	SG 12	SG 13	SG 14

Se si isolano i numeri di unità logica (LUN) dei gruppi di archiviazione l'uno dall'altro, come illustrato nella figura seguente, è possibile eseguire backup di flusso simultanei, uno per ogni LUN. È necessario che i processi di backup del primo gruppo di archiviazione di ogni numero di unità logica (LUN) vengano completati prima dell'inizio del backup del secondo gruppo di archiviazione, in modo da isolare i flussi di backup. Due processi di backup di flusso negli stessi dischi fisici non sono due volte più veloci, ma sono più veloci di un singolo processo di backup di flusso in termini di megabyte al secondo.

Backup servizio Copia Shadow del volume

In Exchange 2007 viene utilizzato il servizio Copia Shadow del volume incluso in Windows Server 2003 per creare le copie shadow del volume dei database e dei file di registro delle transazioni. Per ulteriori informazioni sulla Copia Shadow del volume, incluse le tecniche delle snapshot e dei cloni, vedere la sezione relativa all'utilizzo del servizio Copia Shadow con Exchange Server 2003 (informazioni in lingua inglese). Una novità in Exchange 2007 è rappresentata dalla capacità di effettuare backup del servizio Copia Shadow del volume della copia passiva dei gruppi di archiviazione in esecuzione in un ambiente di replica continua locale o di replica continua cluster. In tali ambienti, una snapshot del servizio Copia Shadow del volume della copia passiva consente di rimuovere il carico del disco sui LUN attivi sia durante la fase di integrità del checksum del backup, sia nella successiva copia su nastro o disco. Consente inoltre di liberare più tempo nei LUN attivi per eseguire la manutenzione in linea, la gestione record di messaggistica e altre attività.

Numeri di unità logica e dischi fisici

In molti casi, il disco fisico, o numero di unità logica (LUN) riconosciuto dal sistema operativo viene estratto dall'hardware utilizzato per impostare il disco nel sistema operativo. Per motivi legati alle prestazioni e al ripristino, è sempre stato fondamentale separare i file di registro delle transazioni dai file di database a livello di disco fisico e di LUN. La presenza di I/O del disco sequenziali e casuali nello stesso disco fisico riduce in modo sostanziale le prestazioni e, dal punto di vista del ripristino, la separazione dei file di registro e dei file di database di un gruppo di archiviazione assicura che un errore irreversibile di un insieme di dischi fisici non provochi la perdita dei file di registro e dei file di database.

In Exchange 2007 si consiglia di inserire tutti i database presenti in un gruppo di archiviazione nello stesso LUN fisico. Si consiglia, inoltre, di non inserire più di un database in ogni gruppo di archiviazione. L'I/O del database di Exchange è casuale e la maggior parte dei sottosistemi di archiviazione trae vantaggio dall'esecuzione dello stesso carico di lavoro dei dischi fisici. Molti array di archiviazione sono progettati in modo che diversi dischi fisici vengano raggruppati in un gruppo di dischi e che i LUN vengano creati nello spazio disponibile in quel gruppo di dischi e distribuiti equamente in ogni disco fisico. È accettabile che i dischi fisici che stanno eseguendo il backup del LUN del database di un gruppo di archiviazione eseguano anche il backup degli altri LUN contenenti i database di altri server e gruppi di archiviazione. Analogamente, non è fondamentale isolare ciascun LUN del registro delle transazioni di un gruppo di archiviazione in assi fisici separati, anche se la perdita di I/O sequenziali influenza leggermente le prestazioni.

Nel caso in cui sia configurato il numero massimo di 50 gruppi di archiviazione su un unico server, a ciascun gruppo di archiviazione viene assegnato un LUN del registro delle transazioni e un LUN del database. In questo modo si supera il numero di lettere di unità disponibile ed è necessario utilizzare i punti di montaggio del volume nel file system NTFS. I cinquanta gruppi di archiviazione configurati per la replica continua richiedono 200 numeri di unità logica (LUN), che potrebbero superare i limiti massimi di alcuni array di archiviazione, in modo particolare nel caso della replica continua locale (LCR) in cui tutti i 200 LUN dovrebbero essere presenti in un unico server. Con l'aumento del numero di LUN, il monitoraggio diventa sempre più importante perché l'esaurimento dello spazio su disco provoca la disinstallazione del gruppo di archiviazione.

Progettazione del LUN

In molti casi, il numero di unità logica (LUN) riconosciuto dal sistema operativo viene estratto dall'hardware fisico effettivamente presente dietro il disco. Per ragioni di prestazioni e recuperabilità, è assolutamente fondamentale separare i registri delle transazioni dal database a livello del LUN e del disco fisico. Su alcuni array di archiviazione, la presenza di operazioni di I/O sequenziali e casuali nello stesso disco fisico può ridurre le prestazioni e, dal punto di vista della recuperabilità, la separazione dei database e dei registri delle transazioni di un gruppo di archiviazione assicura che un errore irreversibile di un determinato insieme di dischi fisici non provochi la perdita sia dei database che dei registri delle transazioni.

L'I/O del database di Exchange è casuale, quindi, se i dischi fisici eseguono lo stesso carico di lavoro, per la maggior parte dei sottosistemi di archiviazione questo rappresenta un vantaggio. Molti array di archiviazione sono progettati in modo che diversi dischi fisici vengano innanzitutto raggruppati in un gruppo di dischi e che i numeri di unità logica (LUN) vengano creati nello spazio disponibile in quel gruppo di dischi e distribuiti equamente in ogni disco fisico. Quando non si utilizza la replica continua, è accettabile che i dischi fisici che stanno eseguendo il backup del numero di unità logica (LUN) del database di un gruppo di archiviazione eseguano anche il backup degli altri numeri di unità logica (LUN) contenenti i database di altri server e gruppi di archiviazione. Analogamente, non è fondamentale isolare ciascun numero di unità logica (LUN) del registro delle transazioni di un gruppo di archiviazione in assi fisici separati, anche se la perdita di I/O sequenziali influenza leggermente le prestazioni. È importante separare i LUN del registro e del database provenienti dallo stesso gruppo di archiviazione in dischi fisici diversi. Non è realistico dedicare due o quattro dischi fisici da 500 GB al numero di unità logica (LUN) del registro delle transazioni di un singolo gruppo di archiviazione quando sono necessarie 30 operazioni di IOPS (I/O al secondo) e il 5% della capacità.

Sebbene esistano numerosi metodi per progettare i numeri di unità logica (LUN) in Exchange 2007, per limitare la complessità è consigliabile adottare i due metodi riportati di seguito:

• 2 numeri di unità logica (LUN) per gruppo di archiviazione

• 2 numeri di unità logica (LUN) per set di backup

2 LUN per gruppo di archiviazione

La procedura consigliata per Exchange 2003 era di creare 2 LUN per un gruppo di archiviazione (uno per i registri e uno per i database). Con Exchange 2007 e nel caso del numero massimo di gruppi di archiviazione, ossia 50, il numero di LUN dipende dalla strategia di backup. Se l'obiettivo temporale di recupero (RTO, recovery time objective) è molto limitato o se si utilizzano i cloni del servizio Copia Shadow del volume per il recupero rapido, è consigliabile collocare ciascun gruppo di archiviazione in un proprio numero di unità logica (LUN) del database o del registro delle transazioni. Poiché in questo modo si supera il numero di lettere di unità disponibili, è necessario utilizzare i punti di montaggio del volume.

Alcuni vantaggi di questa strategia sono riportati di seguito:

• Possibilità di utilizzo del servizio Copia Shadow del volume basato su hardware al livello del gruppo di archiviazione, fornendo il backup e il ripristino dei singoli gruppi di archiviazione.

• Flessibilità per isolare le prestazioni tra gruppi di archiviazione.

• Aumento del livello di affidabilità. Un problema di capacità, un virus o un danneggiamento che si dovesse verificare su un singolo LUN avrebbe impatto su un solo gruppo di archiviazione.

Di seguito sono riportati alcuni svantaggi di questa strategia:

• Cinquanta gruppi di archiviazione che utilizzano la replica continua richiedono 200 numeri di unità logica (LUN), un valore che potrebbe superare i limiti massimi di alcuni array di archiviazione, in modo particolare nel caso della replica continua locale (LCR) in cui tutti i 200 numeri di unità logica (LUN) dovrebbero essere presenti in un unico server.

• Un LUN diverso per ogni gruppo di archiviazione comporta la presenza di più LUN per server, aumentando i costi amministrativi.

2 LUN per set di backup

Un set di backup è il numero dei database di cui viene eseguito il backup completo in una notte. Una soluzione che prevede l'esecuzione del backup completo di 1/7 dei database nell'arco di una notte può contribuire a ridurre la complessità collocando tutti i gruppi di archiviazione di cui eseguire il backup sullo stesso numero di unità logica (LUN) del database o del registro. Questo consente di ridurre il numero di LUN sul server.

Alcuni vantaggi di questa strategia sono riportati di seguito:

• Amministrazione dell'archiviazione semplificata in quanto sono presenti meno LUN da gestire.

• Potenziale riduzione del numero dei processi di backup.

Di seguito sono riportati alcuni svantaggi di questa strategia:

• Limiti nella capacità di eseguire ripristini e backup del servizio VSS basato su hardware.

• Limiti alla possibilità di estendere la capacità, a causa del limite di 2 TB (terabyte) per la partizione del record di avvio principale (MBR, Master Boot Record).

Punti di montaggio dei volumi

Esistono molti casi, ad esempio nei cluster a copia singola con più nodi, in cui sono necessari più numeri di unità logica (LUN) rispetto alle lettere di unità disponibili. In casi come questi, è necessario utilizzare i punti di montaggio dei volumi. Le lettere di unità sono una funzionalità legacy del sistema operativo MS-DOS per il riconoscimento delle partizioni o dei dischi. È consigliabile evitare l'utilizzo di un numero eccessivo di lettere di unità. È molto più semplice posizionare tutti i LUN del database e del registro delle transazioni in un punto di montaggio del volume per facilitare le operazioni di amministrazione. Se si dispone di 20 gruppi di archiviazione, ciascuno con un database, non sarà semplice ricordare quale lettera di unità è associata al database 17. Nella tabella seguente viene descritto un esempio di utilizzo dei punti di montaggio del volume.

Esempio di layout della cartella utilizzando i punti di montaggio del volume

Registri delle transazioni (L:)	Database (P:)
L:\SG1LOG	P:\SG1DB
L:\SG2LOG	P:\SG2DB
L:\SG3LOG	P:\SG3DB
L:\SG4LOG	P:\SG4DB

In questo esempio, L: e P: sono LUN di ancoraggio, che ospitano rispettivamente i LUN dei registri e dei database. Ciascuna cartella in queste unità è un punto di montaggio del volume di un LUN separato.

Servizio Copia Shadow del volume basato su hardware

Quando si utilizza il servizio Copia Shadow del volume basato su hardware, è necessario tenere presente alcuni consigli utili per il posizionamento dei dati di Exchange nei numeri di unità logica (LUN). Per una soluzione che prevede il servizio Copia Shadow del volume basato su hardware, in ciascun LUN del registro delle transazioni e del database devono essere collocati solo i file provenienti dal set di backup scelto. Se si desidera ripristinare un determinato gruppo di archiviazione senza incidere sugli altri gruppi di archiviazione, sono necessari LUN separati del registro delle transazioni e del database per ciascun gruppo di archiviazione. Per portare altri database e gruppi di archiviazione non in linea così da ripristinare un singolo database, è possibile posizionare più gruppi di archiviazione in un singolo LUN del registro delle transazioni e del database.

Servizio Copia Shadow del volume basato su software

Quando si utilizza il servizio Copia Shadow del volume basato su software, in particolare con cassette postali di grandi dimensioni e la replica continua, il backup è costituito da una strategia in due passaggi. Innanzitutto si esegue una snapshot del servizio Copia Shadow del volume, quindi si trasferiscono i file flat su disco o su nastro.

Affidabilità dei LUN

È di fondamentale importanza posizionare sempre i database e i registri delle transazioni di un gruppo di archiviazione in dischi fisici separati in modo da aumentare il livello di affidabilità. Con la replica continua è importante, inoltre, separare i LUN attivi da quelli passivi in un sistema di archiviazione distinto. Con le funzionalità di replica continua cluster e di replica continua locale, è necessario assicurarsi una certa resilienza dell'archiviazione nel caso in cui si verifichi un errore irreversibile dell'archiviazione primaria.

Esempio di LUN

Il seguente scenario si basa sul precedente esempio di capacità e applica tali informazioni alla creazione di un LUN. In questo esempio, il regime di backup è un backup completo giornaliero. Si desidera abilitare l'indicizzazione del contenuto e posizionarla nel numero di unità logica (LUN) del database. Il 5% di 193 GB è circa 10 GB. È necessario aggiungere questo valore alla dimensione finale del numero di unità logica (LUN). Il fattore di crescita di 193 GB deve essere pari al 20% della dimensione finale del database. Il 20% di 193 GB è 39 GB. I risultati vengono visualizzati nelle tabelle seguenti.

Esempio di valori per la determinazione della dimensione del numero di unità logica (LUN) dei database

Dimensione del database	Fattore di crescita	Indicizzazione del contenuto	Dimensione del LUN del database
193 GB	39 GB	10 GB	241 GB

Ciascun gruppo di archiviazione crea 7,13 GB di registri al giorno, e si desidera archiviare almeno una quantità di registri equivalente a 3 giorni.

Esempio di valori per la determinazione della dimensione del numero di unità logica (LUN) dei registri

Registri (1 giorno)	Registri (3 giorni)
7,13 GB	21,4 GB

Spostamento delle cassette postali

Nell'organizzazione presa come esempio, ogni settimana viene spostato il 10% delle cassette postali. Lo spostamento viene eseguito il sabato. Di conseguenza, il numero di unità logica (LUN) dei registri deve gestire l'intero carico in un giorno. Una strategia di spostamento delle cassette postali utilizzata in Microsoft prevede la distribuzione equa degli utenti in arrivo in ciascun gruppo di archiviazione. Ciò significa che il server di esempio con 4.000 utenti deve spostare circa 400 utenti ogni sabato. Con 23 gruppi di archiviazione, ciascun gruppo deve ricevere 17 cassette postali da 1 GB, come illustrato nella tabella seguente.

Esempio di valori per la determinazione della dimensione del numero di unità logica (LUN) dei registri per lo spostamento delle cassette postali

Registri (3 giorni)	Spostamenti delle cassette postali	Dimensione del LUN del registro
21,4 GB	17,64 GB (17 utenti da 1 GB)	46,6 GB (38,8 GB + 20%)

Con questo layout, non verranno spostati più di 17 utenti in un gruppo di archiviazione in un singolo giorno. Quindi, è più logico aumentare la dimensione del numero di unità logica (LUN) dei registri nel caso in cui sia necessario spostarne più del 5% in un giorno specifico.

Impatto della replica continua sulla progettazione dell'archiviazione

La replica continua è una funzionalità nuova di Exchange 2007 in cui i file di registro e il database di un gruppo di archiviazione vengono copiati in un percorso secondario. Quando vengono chiusi o riempiti, i nuovi registri delle transazioni vengono copiati in un percorso secondario, convalidati e rieseguiti nella copia passiva del database. Per ottenere l'adattabilità dell'archiviazione, si consiglia di collocare la copia passiva in un array di archiviazione completamente isolata dai LUN di produzione. A seconda della copia passiva che gestisce il carico della produzione in caso di errore, l'archiviazione deve soddisfare le prestazioni e la capacità della soluzione di archiviazione utilizzata dalla copia attiva del gruppo di archiviazione.

Ogni gruppo di archiviazione può contenere solo un database se si utilizza la replica continua, pertanto ciascuna copia del database richiede quattro numeri di unità logica (LUN). Ogni copia del database si troverà nel proprio gruppo di archiviazione, che avrà bisogno di un LUN di database e di un LUN di registro distinti per la copia attiva e per quella passiva.

Si consiglia di attenersi alle indicazioni seguenti:

• Suddividere l'archiviazione in LUN singoli a livello di hardware e non creare più partizioni logiche di un LUN all'interno del sistema operativo.

• Separare i registri delle transazioni e i database e collocarli in dischi fisici distinti per aumentare la tolleranza di errore.

• Suddividere i LUN attivi e passivi in array di archiviazione assolutamente distinte in modo che l'archiviazione non presenti un singolo punto di errore.

• Se i gruppi di archiviazione o i database di più server di cassette postali in cluster sono ospitati nello stesso array di archiviazione, è necessario assicurarsi che ogni numero di unità logica (LUN) sia creato con dischi fisici diversi.

La progettazione dell'archiviazione deve ottimizzare la tolleranza di errore suddividendo i controller di archiviazione in un bus PCI (Peripheral Component Interconnect) diverso. Inoltre, si consiglia di progettare l'archiviazione della copia passiva in modo che corrisponda all'archiviazione utilizzata per la copia attiva in termini di capacità e prestazioni. L'archiviazione della copia passiva è la prima misura di difesa contro gli errori irreversibili dell'archiviazione della copia attiva e, in caso di failover, la copia passiva diventa la copia attiva. La collocazione dei LUN della copia passiva in hardware di archiviazione completamente diversi impedisce che qualsiasi azione eseguita sulla copia passiva comprometta la copia attiva.

Con la replica continua, si verificano più I/O transazionali. È necessario considerare questo fattore durante il dimensionamento dei server. Il registro delle transazioni attive, che è un'operazione di scrittura sequenziale, deve inoltre leggere il registro dopo che è stato chiuso e copiarlo nella cartella di quarantena dei LUN dei registri delle transazioni di replica. Il registro deve essere controllato nel percorso di replica e spostato alla destinazione finale nel LUN di replica. Il registro infine viene letto ed eseguito nel database. I LUN di registro delle transazioni attive e di replica devono leggere e scrivere quasi il 100% dell'attività di scrittura sequenziale presente in un server Cassette postali autonomo. Questo modifica al comportamento potrebbe richiedere la valutazione delle impostazioni della cache nel controller di archiviazione. In un controller di archiviazione con batteria si consiglia di impostare la lettura al 25% e la scrittura al 75%.

Replica continua e dimensione dei database

Con l'utilizzo della replica continua è possibile aumentare la dimensione massima consentita del database. Per Exchange 2007 si consigliano le seguenti dimensioni massime di database:

• Database ospitati su un server Cassette postali senza replica continua: 100 GB

• Database ospitati su un server Cassette postali con replica continua e rete Gigabit Ethernet: 200 GB

  Nota

  I database di grandi dimensioni possono anche richiedere tecnologie di archiviazione più recenti per l'aumento della larghezza di banda necessaria nei casi di ripristino.

  Importante

  La dimensione massima effettiva per i propri database dovrebbe essere dettata dal contratto di servizio (SLA, service level agreement) in vigore presso la propria organizzazione. Determinando il database più grande di cui è possibile eseguire un backup e un ripristino nei tempi specificati dal contratto di servizio (SLA) dell'organizzazione, vengono determinate anche le dimensioni massime dei database.

Opzioni di archiviazione della replica continua locale

La replica continua locale consente il log shipping (la distribuzione dei log) in un unico server. In caso di errore irreversibile dell'archiviazione in cui si trova la copia attiva del database o dei file di registro, l'amministratore può attivare manualmente la copia passiva del database. L'archiviazione della copia passiva deve essere completamente separata dall'archiviazione della copia attiva. Inoltre:

• Le schede dei controller devono trovarsi su un bus PCI diverso.

• Ciascuna soluzione di archiviazione deve disporre del proprio gruppo di continuità.

• Ogni soluzione di archiviazione deve trovarsi in un circuito di potenza diverso.

Opzioni di archiviazione della replica continua cluster

La replica continua cluster consente il log shipping in un nodo passivo in un cluster di failover attivo/passivo. Distribuendo i log e memorizzando la copia passiva in un server completamente diverso, l'impatto operativo sul nodo attivo diminuisce e migliora la tolleranza di errore nel server.

Nella distribuzione della replica continua cluster dislocata geograficamente, la copia passiva può essere in un nodo che si trova in una ubicazione fisica diversa rispetto al nodo attivo, con la conseguente adattabilità del sito. Sebbene siano ancora applicabili le informazioni contenute nell'articolo Indicazioni di distribuzione per la replica dei dati su più siti di Exchange Server, la tecnologia di recupero alla base della replica continua cluster implica che con un'elevata latenza gli utenti non riscontrino differenze sostanziali. Tale aspetto è in netto contrasto con la soluzione di cluster dislocati geograficamente in cui la latenza di replica sincrona influenza negativamente il server attivo. Con la replica continua cluster, il processo di replica può essere eseguito in ritardo, aumentando il periodo di tempo di asincronia della copia attiva e della copia passiva. Se tuttavia un guasto compromette la copia attiva, sarà possibile recuperare tutti i messaggi non replicati nel nodo passivo grazie alla funzionalità del dumpster del trasporto del server Trasporto Hub.

Opzioni di archiviazione del cluster a copia singola

L'hardware utilizzato per un cluster a copia singola deve essere elencato nella categoria Cluster del Catalogo server di Windows. L'hardware utilizzato per i cluster a copia singola (SCC, single copy cluster) geograficamente distribuiti deve essere elencato nella relativa categoria nel catalogo Windows Server da supportare.

Per un server di cassette postali in cluster che utilizza l'archiviazione condivisa, fare riferimento alle stesse considerazioni fondamentali sull'archiviazione di un server autonomo. Utilizzando la replica sincrona, la latenza dei dischi può essere aumentata artificialmente mediante il processo di replica. È necessario prestare attenzione ad aumentare i punti di replica nell'array di archiviazione. Per ulteriori informazioni sulla replica di cluster a copia singola, vedere Indicazioni di distribuzione per la replica dei dati su più siti di Exchange Server.