Determinazione delle linee di base per la ricostruzione degli indici di contenuto di Exchange - Parte 3

Articolo originale pubblicato lunedì 2 luglio 2012

Nella Parte 1 di questa serie ho illustrato lo script E2K7_IndexRebuildAnalyzer.ps1 e nella Parte 2 ho discusso il framework di ricostruzione della ricerca (Search Rebuild Framework) che ho sviluppato insieme al mio collega, Anatoly Girko. Prima di concludere questa serie, desidero fornire un insieme di grafici nonché una tabella delle “medie osservate” in cui sono illustrate le caratteristiche di ricostruzione osservate dall'introduzione del framework. Spero che ciò consenta una migliore concettualizzazione, offrendo inoltre la possibilità di elaborare stime più accurate al momento del calcolo della propria velocità di ricostruzione.

Medie osservate fino a oggi in Microsoft

Anatoly e io abbiamo pensato più volte a come presentare questi concetti nel modo migliore. Come potete ben immaginare, le possibilità di presentazione sono infinite. Abbiamo alla fine deciso di impostare come ambito dei grafici e della tabella la dimensione dei messaggi utilizzata per la progettazione dalla maggior parte degli architetti dell'archiviazione di Exchange, ovvero 150 KB per elemento di posta. Abbiamo quindi eseguito un filtro secondario sul numero delle cassette postali e preso in considerazione nelle nostre raccolte dati solo i database delle cassette postali che disponevano di almeno 100 cassette postali attive per produrre le medie riportate di seguito. Dalla nostra raccolta abbiamo poi rimosso il 10% delle operazioni di ricostruzione con le migliori prestazioni e il 10% di quelle con le peggiori prestazioni per ottenere le medie utilizzate per creare i grafici e le tabelle.

Nota: nei diversi grafici e nella tabella seguenti le dimensioni medie delle cassette postali (Average Mailbox Size) in diversi incrementi di intervalli mancano palesemente. Tali dati non sono stati trascurati o omessi appositamente. L'assenza di dati statistici per questi intervalli è dovuta alla mancanza di dati validi nelle raccolte che abbiamo fatto nel tempo. In altri termini, non abbiamo mai eseguito operazioni di ricostruzione degli indici di contenuto e/o raccolto la metrica post-ricostruzione per database in cui le dimensioni medie delle cassette postali degli utenti finali rientrassero negli intervalli seguenti:

• 1700-1799 MB
• 1800-1899 MB
• 2000-2099 MB
• 2100-2199 MB

Grafici

Presenteremo quattro grafici pivot di Excel che riflettono le caratteristiche di velocità effettiva che abbiamo osservato finora sulla base della raccolta filtrata come spiegato in precedenza. Tali grafici pivot hanno lo scopo di illustrare la relazione esistente tra le diverse proprietà rilevate all'interno e in prossimità dell'archivio cassette postali, ovvero il numero delle cassette postali, il numero degli elementi e le dimensioni dei file EDB, e di metterle a confronto con i tempi necessari in precedenza per completare una ricerca per indicizzazione completa su archivi cassette postali aventi caratteristiche simili.

Grafico 1

Nella visualizzazione del Grafico 1 vengono illustrati specificamente la relazione tra il numero delle cassette postali per database, la dimensione relativa dei database delle cassette postali in gigabyte e il relativo impatto sul tempo totale di completamento della ricostruzione dell'indice di contenuto degli archivi cassette postali in minuti.

In tale grafico viene dimostrato in modo evidente come all'aumento del numero totale di cassette postali attive in un database delle cassette postali di Exchange corrisponda inoltre, in una relazione parallela, la tendenza a un aumento della dimensione dei file EDB nel sottosistema di archiviazione. Questa relazione di conseguenza incide sul tempo generale necessario per completare una ricerca per indicizzazione completa di un indice di contenuto. Questo è solo un modo più originale per esprimere il concetto seguente: con un numero maggiore di cassette postali attive, di solito vi sono più elementi di posta, che determinano una dimensione dei file EDB maggiore su disco e quindi "in genere" una maggiore durata della ricostruzione di un indice di contenuto. L'unica circostanza in cui questa ipotesi non si rivelerà mai esatta è quella di un database delle cassette postali con una grande quantità di spazio vuoto nel file. In tal caso la ricostruzione di un indice di contenuto verrà eseguita molto più velocemente del previsto. Questa situazione anomala è stata riscontrata negli ambienti che supportiamo, ma le relative statistiche sono state rimosse dalla nostra raccolta dati mediante la tecnica di filtro sopra descritta.

Grafico 2

Nel Grafico 2 vengono illustrati la relazione esistente tra la dimensione media delle cassette postali (Average Mailbox Size), presenti nei database inclusi nello stesso set di esempio filtrato, e il relativo impatto sulla velocità effettiva della ricostruzione di un indice di contenuto a livello di database delle cassette postali in secondi per cassetta postale (Seconds per/mailbox).

In questo grafico fondamentalmente viene ribadito il concetto presentato nel Grafico 1, anche se a livello di cassette postali attive. Nello specifico, man mano che aumenta la media della dimensione delle cassette postali attive, aumenta anche il numero medio di elementi di posta contenuti in tali cassette. In media, maggiore è il numero degli elementi di posta in una cassetta postale, più tempo sarà necessario all'indicizzatore di ricerca per completare la ricerca per indicizzazione su una determinata cassetta postale, con un conseguente impatto sul tempo necessario per completare una ricerca per indicizzazione completa per tutte le cassette postali nel database.

Grafico 3

Nel Grafico 3 vengono illustrati la relazione esistente tra la dimensione media delle cassette postali (Average Mailbox Size), presenti nei database inclusi nello stesso set di esempio filtrato, e il relativo impatto sulla velocità effettiva della ricostruzione di un indice di contenuto in megabyte al secondo (MB/second).

Il Grafico 3 è basato sull'ipotesi iniziale accennata nel Grafico 2. Più specificamente, viene illustrato che con l'aumentare della dimensione media delle cassette postali (Average Mailbox Size) e del numero medio di elementi di posta (Average Item Count) in un database delle cassette postali, vi è una relazione negativa con la velocità effettiva dell'indicizzatore di ricerca. Nel Grafico 3 tale relazione viene mostrata in megabyte al secondo.

Grafico 4

Nel Grafico 4 vengono illustrati la relazione esistente tra la dimensione media delle cassette postali (Average Mailbox Size), presenti nei database inclusi nello stesso set di esempio filtrato, e il relativo impatto sulla velocità effettiva della ricostruzione di un indice di contenuto in elementi al secondo (Items per second) in base a una dimensione media dei messaggi di 150 KB :

Come nel caso del Grafico 3, nel Grafico 4 viene illustrato l'impatto negativo sulle prestazioni in termini di velocità effettiva come elementi al secondo (Items per second).

Tabella delle medie osservate

Per presentare la tabella, abbiamo utilizzato lo stesso set filtrato (descritto in precedenza e riportato nei grafici), ma abbiamo scelto di creare medie mirate basate sulla dimensione media delle cassette postali (Average Mailbox Size). Tali righe sono quindi delineate come righe indipendenti in incrementi di 99 MB. La caratteristica di velocità effettiva per ogni riga rappresenta le medie aggregate per tutti i database di dimensioni analoghe che hanno completato operazioni di ricostruzione nella nostra raccolta, nello specifico dove la dimensione media dei messaggi (Average Message Size) era pari a 150 KB e la dimensione media delle cassette postali (Average Mailbox Size) per tutte le cassette postali attive in tali database era compresa negli intervalli definiti nella colonna A.

Le medie dei dati raccolti nel tempo presentate in questa tabella, almeno per me, portano a tre possibili modi di stimare i tempi di ricostruzione dell'indice di contenuto:

• Potrebbe essere implementata una "media dei dati raccolti nel tempo" basata sulla dimensione media delle cassette postali (Average Mailbox Size), in cui la dimensione media dei messaggi (Average Message Size) per gli elementi che risiedono in tali cassette è pari a 150 KB.Poiché nella nostra raccolta disponiamo di grandi quantità di dati di cronologia sulla ricostruzione, scegliamo di avvalerci di tale media. Otteniamo la nostra stima determinando il valore Average Mailbox Size mediante la metrica "pre-ricostruzione" ed effettuando un confronto con la media dei dati raccolti nel tempo. Prendiamo quindi la media composta per la ricostruzione in termini di secondi per cassetta postale (Rebuild: Seconds per/Mailbox) e quindi moltiplichiamo tale valore per il numero di cassette postali nel database che richiedono una ricerca per indicizzazione per determinare il tempo totale necessario per il completamento.
• Potrebbe essere stabilita anche una "media dell'organizzazione" basata sulla dimensione media dei messaggi (Average Message Size), quali che siano il numero degli elementi e la dimensione media delle cassette postali all'interno dell'organizzazione. Tale media dell'organizzazione viene fornita nella riga delle medie sopra riportata.
• Potrebbe essere stabilita una media composta tra la media dei dati raccolti nel tempo e quella dell'organizzazione.

Se ad esempio si dispone di un indice di contenuto che deve essere ricostruito per un database i cui utenti hanno una dimensione media delle cassette postali (Average Mailbox Size) compresa nell'intervallo 500-599 MB, presupponendo che la dimensione media dei messaggi (Average Message Size) sia pari a 150 KB e che il database abbia 200 utenti, è possibile ottenere la stima in uno dei tre modi applicabili:

Tabella delle medie dei dati raccolti nel tempo:

200 cassette postali * 63 secondi = 12600 secondi in totale. Questo significa che per eseguire una ricerca per indicizzazione completa sono necessari 210 minuti, ovvero circa 3,5 ore.

"Media dell'organizzazione":

200 cassette postali * 108 secondi = 21600 secondi in totale. Questo significa che per eseguire una ricerca per indicizzazione completa sono necessari 360 minuti, ovvero circa 6,0 ore.

Media composta (media "dei dati raccolti nel tempo" + media "dell'organizzazione") :

3,5 + 6,0 = 9,5 ore

9,5 / 2 = 4,75 ore

Conclusione

Il tempo totale necessario per ricostruire un indice di contenuto varierà sempre perché gli utenti che hanno a che fare con la posta elettronica e gli elementi di posta stessi sono sempre fattori variabili. Quando si ricostruiscono gli indici di contenuto, le stime più accurate e attendibili saranno sempre quelle basate sulle medie dei dati raccolti nel tempo. Vorrei anche spiegare che, quando decidiamo di ricostruire un indice di contenuto internamente in MSFT, facciamo del nostro meglio per pianificare il processo per i periodi in cui "l'impatto per gli utenti può essere minimo". Le nostre implementazioni tuttavia sono a livello globale, quindi è praticamente impossibile eliminare del tutto gli effetti negativi sugli utenti. L'importante è ridurre al minimo l'impatto sull'area di esposizione. Inoltre, nelle nostre raccolte dati non consideriamo i ritardi per limitazioni dell'indicizzatore di ricerca. Tutti i ritardi di questo tipo vengono gestiti e compresi al momento e sono rappresentativi nei singoli ticket quando vengono presentati per le operazioni. Avvalendovi delle tecniche di filtro descritte in questo post, potrete isolare i numeri da tali medie negative (lo stesso vale per le operazioni di ricostruzione con una "velocità effettiva eccessivamente elevata") e avere delle stime generali notevolmente più accurate.

Se amate giocare con i numeri e le medie, io sono pronto a rischiare con voi. Se però sono necessari calcoli più precisi, vi suggerisco di implementare un framework come quello illustrato in questa serie di post.

Speriamo che questa serie di post vi sia stata utile e, soprattutto, che con l'occasione abbiate imparato qualcosa di nuovo!

Buona fortuna!

Eric Norberg
Service Engineer
Dedicato a Office 365

Questo è un post di blog localizzato. L'articolo originale è disponibile in Establishing Exchange Content Index Rebuild Baselines – Part 3