Condividi tramite

Informazioni sui fattori capacità registro e database delle cassette postali

  • Articolo

Ultima modifica dell'argomento: 2010-02-03

In questo argomento vengono presentati i fattori da tenere in considerazione durante la pianificazione della capacità dei registri e dei database delle cassette postali durante la progettazione dell'archiviazione sul server di cassette postali in Microsoft Exchange Server 2010.

Capacità dei database delle cassette postali

Molti fattori influenzano il piano relativo alla capacità dei database delle cassette postali di Exchange Server 2010. In questa sezione sono disponibili informazioni relative ai seguenti argomenti:

  • Quote di archiviazione delle cassette postali
  • Spazio vuoto del database
  • Elementi recuperabili dei database delle cassette postali
  • Dimensione effettiva della cassetta postale
  • Indicizzazione del contenuto
  • Manutenzione del database offline
  • Database di ripristino
  • Dimensione del database
  • Sovraccarico di crescita del database

Quote di archiviazione delle cassette postali

La prima metrica da comprendere è il limite delle dimensioni di archiviazione, definito quota di archiviazione delle cassette postali, attivo nell'organizzazione. Se si è a conoscenza della quantità di dati che un utente finale può archiviare nella propria cassetta postale, è possibile determinare il numero di cassette postali degli utenti che possono essere ospitate sul server. Anche se le quote di archiviazione delle cassette postali possono cambiare a seguito di modifiche nei requisiti dell'organizzazione, la definizione di un obiettivo per la quota di archiviazione delle cassette postali è il primo passo nella determinazione della capacità necessaria per i database delle cassette postali.

Ad esempio, se in un server sono presenti 5.000 cassette postali degli utenti da 250 MB, sono necessari almeno 1,25 TB di spazio su disco, senza tenere conto dei requisiti di spazio per gli elementi recuperabili. Se non viene impostato un limite per le quote di archiviazione delle cassette postali, potrebbe essere difficile stimare la capacità dei database. Le quote di archiviazione delle cassette postali per Exchange 2010 devono tenere conto dello spazio necessario sia per la cassetta postale principale sia per la cassetta postale di archiviazione personale (se in uso). Per ulteriori informazioni, vedere Gestione dei server Cassette postali e Gestione dell'archivio personale.

Spazio vuoto del database

Per il calcolo della dimensione del database sul disco fisico non è sufficiente moltiplicare il numero di utenti per la quota di archiviazione della cassetta postale. Quando la maggioranza degli utenti non è prossima alla quota di archiviazione 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 al suo interno. Durante la manutenzione in background del database, gli elementi contrassegnati per la rimozione dal database vengono rimossi, liberando in tal modo queste pagine. La percentuale di spazio vuoto cambia costantemente a seguito del processo di deframmentazione online attivo 24 ore su 24 per 7 giorni la settimana.

È possibile stimare la quantità di spazio vuoto nel database calcolando la quantità di posta inviata e ricevuta dagli utenti con cassette postali nel database. Ad esempio, se si dispone di 100 cassette postali da 2 GB (per un 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 a cassetta postale). La quantità di spazio vuoto può superare questa stima se la manutenzione del database in background non è in grado di completare un passaggio completo.

Inizio pagina

Elementi recuperabili dei database delle cassette postali

Ciascun database dispone di un cosiddetto "dumpster" in cui vengono archiviati gli elementi eliminati in maniera non definitiva. Per impostazione predefinita, in Exchange 2010 gli elementi eliminati temporaneamente vengono archiviati per 14 giorni, mentre gli elementi di calendario vengono archiviati per 120 giorni.

Inoltre, Exchange 2010 consente di impedire lo svuotamento dei dati prima della fine del periodo di conservazione di un elemento eliminato. Questa funzionalità è nota come ripristino di un singolo elemento. Se è abilitato il ripristino di un singolo elemento (funzione disabilitata per impostazione predefinita), si verifica un ulteriore aumento dell'1,2% delle dimensioni della cassetta postale per un periodo di conservazione degli elementi eliminati di 14 giorni. Per i dati di registrazione della versione calendario (funzione abilitata per impostazione predefinita), l'ulteriore aumento delle dimensioni della cassetta postale è pari al 5,8%.

La formula per determinare i requisiti di spazio del dumpster per una conservazione degli elementi eliminati della durata di 14 giorni quando sono abilitati il ripristino di un singolo elemento e la registrazione della versione del calendario è la seguente:

Dimensione del dumpster = (Posta in arrivo/inviata ogni giorno × Dimensione media del messaggio × Periodo di conservazione degli elementi eliminati) + (Dimensioni della quota della cassetta postale × 0,012) + (Dimensioni della quota della cassetta postale × 0,058)

Ad esempio, se la dimensione della cassetta postale è pari a 2 GB, l'abilitazione del ripristino di un singolo elemento per un periodo di conservazione degli elementi eliminati di 14 giorni richiede altri 25 MB di spazio, mentre la funzionalità di registrazione del calendario richiede altri 119 MB.

Per ulteriori informazioni, vedere gli argomenti seguenti:

Dimensione effettiva della cassetta postale

Con il tempo, le cassette postali degli utenti raggiungeranno la quota di archiviazione della cassetta postale. Per evitare che vengano superati i limiti della quota di archiviazione assegnata alla cassetta postale sarà necessario eliminare una quantità di posta equivalente alla quantità di posta in arrivo. Questo requisito implica un aumento del dumpster a una dimensione massima equivalente alla quantità di posta elettronica inviata e ricevuta ogni giorno moltiplicata per il numero di giorni nel periodo di conservazione degli elementi eliminati. Se la maggior parte degli utenti non ha raggiunto la quota di archiviazione, viene eliminata solo una parte della posta in arrivo o inviata. La crescita viene quindi divisa tra il dumpster e l'aumento nelle dimensioni della cassetta postale.

Di seguito è riportata una formula per il dimensionamento del database che utilizza una cassetta postale da 2 GB senza la funzionalità di archiviazione personale:

Dimensione del database = Quota della cassetta postale + Spazio vuoto + Dimensione del dumpster

Ad esempio, una cassetta postale da 250 MB con 100 messaggi al giorno che riceve 37 MB di posta in una settimana lavorativa di 5 giorni (con una dimensione media dei messaggi pari a 75 KB) utilizzerà 120 MB di spazio nel dumpster con il ripristino di un singolo elemento abilitato per 14 giorni e 7,3 MB di spazio vuoto, per una dimensione totale della cassetta postale pari a 378 MB. Un altro esempio è rappresentato da una cassetta postale da 2 GB con 100 messaggi al mese che riceve 37 MB di posta alla settimana, la quale utilizzerà 246 MB di spazio nel dumpster e 7,3 MB di spazio vuoto, per una dimensione totale della cassetta postale pari a 2,25 GB.

Una volta determinata la dimensione effettiva della cassetta postale, è possibile utilizzare tale valore per determinare il numero massimo di utenti per database. Dividere la dimensione della cassetta postale prevista per la dimensione consigliata del database. Questo valore consentirà anche di determinare il numero di database necessari per gestire il conteggio pianificato degli utenti, considerando database completamente popolati. Tenere presente che a causa di I/O non transazionali 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 metodologia 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 2010 viene creato un indice che occupa circa il 10% 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 10% nella dimensione del LUN del database.

Inizio pagina

Manutenzione del database offline

Per un database che necessita di essere corretto o compattato offline è 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 o un set di backup, sarà necessario disporre di ulteriore spazio per l'esecuzione di tali operazioni.

Importante

Le procedure di manutenzione offline devono essere implementate solo su richiesta del Servizio Supporto Tecnico Clienti Microsoft, in quanto tali procedure invalidano tutte le copie del database e richiedono un reseeding completo del database.

Database di ripristino

Se si intende utilizzare un database di ripristino nell'ambito della propria strategia di ripristino di emergenza, deve essere disponibile una capacità sufficiente per gestire tutti i database che si desidera ripristinare contemporaneamente sul server. Per ulteriori informazioni, vedere Database di ripristino.

Dimensione del database

La dimensione del database determina quante cassette postali distribuire all'interno di ogni database e quanti database distribuire. Le dimensioni dei database distribuiti dipendono da diversi fattori:

  • Contratti di servizio per backup/ripristino   Le dimensioni del database stabiliscono anche la possibilità di eseguire il backup e il ripristino dei dati entro un tempo ragionevole.
  • Architettura a disponibilità elevata   Se si prevede di utilizzare più copie del database, è possibile progettare i database con una dimensione di 2 TB, dal momento che le copie diverranno la prima linea di difesa per quanto riguarda le operazioni di ripristino.
  • Architettura di archiviazione   Se si prevede di distribuire una risorsa di archiviazione JBOD (in cui un disco ospita sia il database sia i registri delle transazioni corrispondenti), sono le dimensioni del disco in uso a determinare la dimensione massima del database. Ad esempio, su un disco da 1 TB (con capacità formattata di circa 917 GB) è necessario considerare anche lo spazio per i registri delle transazioni e l'indice del contenuto, assicurandosi nel contempo di non esaurire lo spazio disponibile.

Sovraccarico di crescita del database

Una volta considerati e calcolati tutti i fattori, si consiglia di includere un fattore di sovraccarico aggiuntivo per il numero di unità logica del database pari al 20%. Questo 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 dello spazio vuoto.

Inizio pagina

Capacità del registro

I file di registro delle transazioni sono una registrazione di tutte le transazioni eseguite dal motore di database. Tutte le transazioni vengono prima scritte nel registro e, in seguito, vengono progressivamente scritte nel database. A differenza di Exchange Server 2003, le dimensioni dei file dei registri delle transazioni in Exchange 2010 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 della risorsa di archiviazione primaria.

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

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

Profilo dei messaggi (dimensioni medie del messaggio pari a 75 KB) Numero di registri delle transazioni generati ogni giorno

50

10

100

20

150

30

200

40

250

50

300

60

350

70

400

80

450

90

500

100

È possibile utilizzare le seguenti linee guida per comprendere l'effetto della dimensione dei messaggi sulla velocità di generazione dei registri delle transazioni:

  • Se la dimensione media dei messaggi viene raddoppiata a 150 KB, il numero dei registri generati per cassetta postale viene aumentato di un fattore di 1,9. Questo numero rappresenta la percentuale del database che contiene le tabelle degli allegati e dei messaggi (corpo e allegati dei messaggi).
  • Se la dimensione dei messaggi aumenta oltre 150 KB, viene raddoppiata anche la velocità di generazione dei registri per la cassetta postale, da 1,9 a 3,8.

Ad esempio, se si dispone di 100 messaggi al giorno:

  • Con una dimensione media dei messaggi di 150 KB, il numero dei registri generati per cassetta postale corrisponde a 20 × 1,9 = 38.
  • Con una dimensione media dei messaggi di 300 KB, il numero dei registri generati per cassetta postale corrisponde a 20 × 3,8 = 76.

Nelle sezioni seguenti vengono illustrati i fattori che influiscono sulla capacità di dimensionamento dei registri:

  • Fattori di backup e ripristino
  • Operazioni di spostamento delle cassette postali
  • Fattore di sovraccarico della crescita dei registri
  • Fattori di disponibilità elevata
  • Pianificazione della capacità dei numeri di unità logica

Fattori di backup e ripristino

La definizione della dimensione dei numeri di unità logica dei registri dipende in parte dal piano di backup e ripristino. Ad esempio, se il proprio piano consente di tornare indietro di due settimane e di rieseguire 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 dei registri dovranno essere maggiori dello spazio equivalente a un'intera settimana di file di registro, in modo da consentire sia il backup che la riesecuzione durante il ripristino. La maggior parte delle organizzazioni che eseguono backup notturni completi assegnano una capacità pari a due o tre volte la capacità richiesta per la generazione dei registri giornalieri. In questo modo è possibile evitare che errori nel backup provochino l'esaurimento dello spazio sull'unità che ospita i registri, un evento che provocherebbe lo smontaggio del database.

Se nell'infrastruttura di backup in Exchange 2010 si prevede di utilizzare l'adattabilità delle cassette postali e il ripristino di un singolo elemento (abilitando in tal modo la registrazione circolare), è consigliabile allocare uno spazio pari a tre volte la capacità richiesta per la generazione dei registri giornalieri. In questo modo, se la replica viene sospesa o non funziona con i parametri normali, i database non vengono smontati a causa di errori di troncamento.

Operazioni di spostamento delle cassette postali

Lo spostamento delle cassette postali è un fattore di capacità primario per le distribuzioni di cassette postali di grandi dimensioni. In molte società di grandi dimensioni, ogni notte oppure ogni settimana viene spostata una determinata percentuale di cassette postali degli 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 dei registri per garantire che lo spostamento delle cassette postali venga eseguito 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 dei registri di destinazione dando luogo a un intervallo di tempo di inattività. In questi casi è necessario allocare una capacità maggiore per i numeri di unità logica dei registri in modo da agevolare le operazioni di spostamento delle cassette postali.

Fattore di sovraccarico della crescita dei registri

Nella maggior parte delle distribuzioni, in fase di creazione del numero di unità logica 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 la disponibilità della capacità necessaria nelle fasi di generazione imprevista dei registri.

Fattori di disponibilità elevata

La disponibilità elevata influenza i requisiti di capacità dei registri in tre modi significativi:

  • Conteggio delle copie dei database   La capacità di registrazione dell'intero sistema viene aumentata in base al numero di copie dei database scelto nella distribuzione a disponibilità elevata. Se si dispone di tre copie del database su tre server, è necessario effettuare il provisioning della capacità di registrazione per ciascuna copia su ogni server.
  • Meccanismo di troncamento dei registri   La disponibilità elevata in Exchange 2010, insieme alla possibilità di creare fino a 16 copie di ogni database delle cassette postali, consente di utilizzare la registrazione circolare a replica continua come meccanismo di troncamento/eliminazione dei registri, invece di utilizzare i backup completi/incrementali per troncare/eliminare i registri precedenti. Per ulteriori informazioni, vedere la sezione "Troncamento del registro senza i backup" in Informazioni su backup, ripristino e ripristino di emergenza e Disponibilità elevata e resilienza del sito.
  • Intervallo di riesecuzione delle copie del database   La disponibilità elevata in Exchange 2010 consente di ritardare la riesecuzione dei registri sulle copie passive del database (con una configurazione copia per copia). Questa funzionalità consente di ritardare l'esecuzione dei registri nelle copie del database che utilizzano tale intervallo. Questo ritardo può essere utile per proteggersi da eventi che causerebbero la replica di contenuto indesiderato in tutte le copie del database. L'esecuzione del contenuto nella copia del database che utilizza l'intervallo può essere interrotta mediante una sospensione della riesecuzione prima che i registri con contenuto indesiderato vengano eseguiti nel database.
    Se l'intervallo di riesecuzione per una copia del database è abilitato, i requisiti relativi alla capacità dei registri cambiano di conseguenza. Se è configurato un intervallo di 14 giorni, è necessario effettuare il provisioning per una quantità di registri pari a 17 giorni. La capacità aggiuntiva è richiesta solo per le copie del database per cui è configurato l'intervallo; le altre copie del database, prive dell'intervallo, impongono normali requisiti per la capacità di registrazione.

Per ulteriori informazioni, vedere Informazioni sui fattori di disponibilità elevata.

Pianificazione della capacità dei numeri di unità logica

I requisiti di capacità per il numero di unità logica si basano sulla dimensione del set di dati (database, registri delle transazioni, indice del contenuto e spazio di ripristino) e sulla disponibilità di spazio libero aggiuntivo. La maggior parte dei programmi di gestione delle operazioni utilizzano soglie di capacità che avvisano l'utente quando un numero di unità logica è utilizzato per più dell'80%.

È possibile utilizzare la seguente formula per determinare la dimensione appropriata del numero di unità logica:

Capacità del numero di unità logica = Dimensione dei dati / (1 - Percentuale di spazio libero richiesto)

Ad esempio, se il requisito per la dimensione dei dati è pari a 3.000 MB e il requisito per lo spazio libero è pari al 20%, il numero di unità logica che ospita questi dati deve avere una dimensione di 3.750 MB.