Exchange, stubbing e recupero di spazio di database

Articolo originale pubblicato martedì 28 agosto 2012

Nell'aggiornamento cumulativo 1 (RU1) per Exchange 2010 SP2 è inclusa una correzione relativa a un problema riguardante il recupero di spazio del database. Sembra che vi sia un po' di confusione a proposito di questo problema, pertanto vorrei spiegarvi di quale problema e di quale correzione si tratta e discutere delle previsioni correlate all'utilizzo di prodotti di terze parti che eseguono lo stubbing degli elementi all'interno del database (lo stubbing è un processo mediante il quale un messaggio viene sostituito da un oggetto puntatore e la versione originale viene archiviata in un archivio esterno).

Bug e correzione

In Exchange 2010 abbiamo scoperto che lo spazio del database non veniva liberato in diversi scenari in cui gli elementi vengono eliminati in modo definitivo, ovvero vengono rimossi dall'archivio. Sono inclusi gli scenari di archiviazione in cui gli elementi vengono eliminati in blocco in base alla data, gli scenari di stubbing in cui gli allegati vengono eliminati e altri scenari come la replica di cartelle pubbliche e cassette del journaling. Questo problema ha interessato un gran numero di clienti e dipendeva dal funzionamento dell'eliminazione degli elementi.

Exchange 2010 in genere tenta di pulire la riga di un elemento eliminato nel giro di un paio di minuti dall'eliminazione definitiva. La pulizia però avrà esito negativo se vi sono ancora riferimenti aperti all'elemento. L'indicizzazione del contenuto che indicizza il messaggio e un client separato che legge il messaggio ad esempio sono alcuni dei possibili scenari in cui la pulizia non verrà eseguita. In presenza di riferimenti aperti, la pulizia non riesce. Prima che fosse disponibile la correzione, se la pulizia falliva in un determinato punto, tale spazio andata effettivamente perso e non poteva essere recuperato senza spostare la cassetta postale.

È risultato che i riferimenti in sospeso per i messaggi eliminati siano comuni soprattutto nelle cassette del journaling o in caso di utilizzo di software di archiviazione di terze parti, pertanto la grande maggioranza dei clienti che hanno riscontrato tale bug lo ha associato a uno di questi due scenari. Ma da un punto di vista tecnico, qualsiasi client potrebbe mantenere un riferimento aperto e impedire la pulizia di un elemento.

La correzione inclusa nell'aggiornamento cumulativo 1 per SP2 consente di risolvere il problema aggiungendo un meccanismo che ritenta l'esecuzione della pulizia. Se questa ha esito negativo perché vi è ancora un riferimento aperto, l'archivio ritenterà periodicamente finché l'esito non sarà positivo.

La correzione ha avuto effetti sullo stubbing?

Per stubbing si intende un processo mediante il quale un prodotto di archiviazione di terze parti acquisisce un messaggio di grandi dimensioni e lo trasforma in un elemento di dimensioni più piccole, il cosiddetto stub. A tale scopo, in genere gli allegati vengono eliminati e il corpo del messaggio viene modificato in modo che abbia dimensioni più ridotte.

Nella misura in cui lo stubbing elimina gli allegati, questo bug può incidere sul processo perché la pulizia di tali allegati eliminati potrebbe non venire eseguita a causa dell'esistenza di riferimenti aperti. Ma a parte questo, il bug non ha mai riguardato veramente lo stubbing.

E se lo stubbing non consente di ottenere la quantità di spazio prevista?

L'Archivio informazioni di Exchange è cambiato in modo significativo nel corso degli anni, ma anche in Exchange 2003 e 2007 lo stubbing può produrre database molto più grandi del previsto quando vengono aggiunte cassette postali. Questo dipende soprattutto da due tipi di sovraccarico.

Il primo tipo di sovraccarico è dovuto al fatto che alcune proprietà non vengono conteggiate nella dimensione del messaggio. Quando controlliamo la dimensione di un messaggio in Outlook, la dimensione visualizzata in realtà non corrisponde alla dimensione totale di tutti i dati archiviati da Exchange per il messaggio. Determinate proprietà che vengono archiviate non vengono calcolate per l'utente e non risultano perciò incluse nella dimensione del messaggio. Possono essere proprietà documentate pubblicamente, come PR_URL_NAME, o altre proprietà interne non accessibili ai client.

Il secondo tipo di sovraccarico dipende dalla frammentazione delle pagine. La dimensione delle pagine di database è cambiata negli anni da 4 KB in Exchange 2003 a 8 KB in Exchange 2007 e a 32 KB in Exchange 2010. Ogni record del database deve essere inserito in queste pagine e, a seconda dell'efficienza con cui è possibile eseguire l'operazione, resterà più o meno spazio nella pagina. Tale frammentazione genera spazio vuoto che non può essere recuperato con le attività di manutenzione del database. La maggiore dimensione delle pagine caratteristica delle versioni più recenti di Exchange consente di collocare più facilmente diversi piccoli elementi in una stessa pagina e quindi di avere una minore frammentazione, che comunque non sparirà mai del tutto.

L'entità del sovraccarico solitamente non cambia molto da un messaggio all'altro. Un messaggio di piccole dimensioni comporterà lo stesso sovraccarico di un messaggio di grandi dimensioni. Ecco perché, riempiendo un database con piccoli elementi, il sovraccarico sarà molto più evidente.

Si consideri ad esempio uno scenario in cui un database sia stato riempito con elementi tutti di una dimensione pari a 1 MB e che tali elementi abbiano tutti un sovraccarico pari a 1 KB. Questo significa che il database presenta un sovraccarico approssimativamente dello 0,09%. Se si esegue lo stubbing di tutti gli elementi del database per ridurli a una dimensione di 4 KB, il sovraccarico di 1 KB improvvisamente diventerà più visibile, occupando il 25% del database. Io stesso una volta ho creato un database di Exchange 2003 che aveva un sovraccarico del 70% perché lo avevo riempito di piccoli elementi e avevo poi eseguito lo stubbing su tutto.

E cosa accade in Exchange 2010?

In Exchange 2010 è necessario considerare un ulteriore fattore che può incidere sul recupero dello spazio con lo stubbing, ovvero la diversa progettazione del database.

Per Exchange 2010 sono stati compiuti notevoli sforzi per ridurre il numero delle operazioni di input/output al secondo (IOPS). Gran parte di tali sforzi si è concentrata sull'eliminazione del vecchio processo di deframmentazione online che ogni notte scombussolava il database spostando tutto allo scopo di ottimizzare lo spazio. In Exchange 2010 siamo molto più focalizzati sull'archiviazione del contenuto delle cassette postali in pagine contigue per ridurre le operazioni di I/O, anche se questo può causare la presenza di spazio inutilizzato in alcuni punti. In altri termini, Exchange 2010 semplicemente non è stato concepito per un recupero aggressivo dello spazio quando la dimensione di un messaggio improvvisamente diminuisce. Si tratta di uno scenario che abbiamo ridotto al minimo nell'architettura al fine di migliorare l'I/O. Per ulteriori informazioni sulle modifiche relative alla manutenzione, vedere Manutenzione del database in Exchange 2010.

Questo significa forse che lo stubbing non consentirà di risparmiare spazio? Non necessariamente. I prodotti di stubbing in genere eliminano gli allegati, quindi è plausibile che lo spazio corrispondente venga liberato. E, benché Exchange 2010 non sia stato progettato a tale scopo, abbiamo osservato che libera spazio anche quando vengono sottoposti a stubbing elementi senza allegati.

Poiché però questo aspetto non è previsto specificamente nella progettazione di Exchange 2010, non possiamo prevedere quanto spazio verrà liberato con l'archiviazione di stub. Qualsiasi previsione al riguardo dovrebbe provenire dai nostri testing o dai dati resi disponibili dal fornitore del software di archiviazione in uso.

In altri termini, non possiamo fare affermazioni certe sul recupero di spazio in caso di modifica di un elemento per ridurne le proprietà. Se modificando un elemento per ridurne le dimensioni non viene rilasciato spazio, tale condizione si verifica da progettazione in Exchange 2010. Come sempre, se le verifiche svolte dal personale addetto al supporto per problemi di spazio del database in caso di utilizzo di prodotti di terze parti dovessero mostrare che Exchange funziona da progettazione, potrebbe essere necessario rivolgersi su nostra indicazione alla terza parte in questione per avere assistenza.

Conclusione

Nell'aggiornamento cumulativo 1 per Exchange 2010 SP2 è inclusa una correzione che agevolerà i clienti nell'esecuzione di qualsiasi tipo di archiviazione, che si tratti dello stubbing o di un altro metodo, perché effettua in modo affidabile la pulizia degli elementi eliminati in modo definitivo. Qualsiasi risparmio di spazio su disco previsto a seguito dello stubbing dovrà tuttavia essere verificato personalmente e dal fornitore del software di archiviazione. Durante il provisioning dell'archiviazione, è consigliabile seguire le istruzioni da noi pubblicate (che prevedono tra l'altro l'utilizzo di cassette postali di grandi dimensioni in modo che non sia necessario ricorrere a soluzioni di archiviazione di terze parti) e avvalersi dei nostri strumenti per essere certi di avere spazio adeguato per i dati di Exchange.

Bill Long

Questo è un post di blog localizzato. L'articolo originale è disponibile in Exchange, Stubbing, and Database Space Reclamation.