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

Articolo originale pubblicato martedì 26 giugno 2012

Una delle prime operazioni che in genere vengono eseguite dalla maggior parte degli amministratori di Exchange per la risoluzione di possibili problemi con Indicizzazione contenuto di Exchange consiste nel ricostruire i file di indice di contenuto del database delle cassette postali interessato (manualmente oppure tramite lo script ResetSearchIndex.ps1 disponibile nella directory \Exchange Server\Scripts). Negli anni ho collaborato anche con molti amministratori di Exchange che scelgono di ricostruire a scopo preventivo gli indici di ricerca in vari momenti durante l'anno di calendario o in corrispondenza del completamento di diverse attività cardine nell'ambito di un progetto, ad esempio in un progetto di migrazione.

Indipendentemente dalle ragioni per cui vengono reimpostati gli indici, la maggior parte degli amministratori, se interrogata, non sarà in grado di fornire stime realistiche del tempo richiesto per l'esecuzione del processo dall'inizio alla fine. Le conseguenze indesiderate dovute alla mancanza di dati accurati sui tempi richiesti dal processo varieranno in base all'organizzazione. È possibile che alcuni reparti IT sconsiglino di lasciare sprovvisti gli utenti di indici sul lato server durante la giornata lavorativa citando il rischio di un calo della produttività degli utenti finali e di un aumento dei problemi segnalati all'helpdesk. Dal punto di vista operativo, non conoscere i tempi previsti per la ricostruzione può anche impedire agli amministratori di Exchange di ricevere segnalazioni di potenziali problemi del processo di ricreazione stesso. Indipendentemente dalle ragioni, disporre di una solida conoscenza della durata del processo è comunque utile.

Effettivamente al momento sono disponibili poche informazioni sul tempo richiesto (o meglio ancora che dovrebbe essere richiesto) per ricostruire un indice di contenuto di Exchange. Apparentemente, questo è dovuto al fatto che i tempi di ricostruzione effettivi sono sempre variabili. Sono numerosi i fattori che determinano la velocità di ricostruzione e i tempi di completamento, in particolare:

• Variabilità del numero totale di cassette postali degli utenti finali "situate" in un database delle cassette postali di Exchange
• Variabilità delle dimensioni delle cassette postali contenute in un database delle cassette postali di Exchange
• Variabilità del numero di elementi delle cassette postali degli utenti situate in un database delle cassette postali di Exchange
• Variabilità del numero di elementi dei database delle cassette postali di Exchange (quando vengono eseguiti processi di ricostruzione simultanei)
• Variabilità delle dimensioni degli elementi contenuti in un database delle cassette postali di Exchange
• Variabilità del numero e delle dimensioni degli allegati di posta contenuti in un database delle cassette postali di Exchange
• Tipi e numero di filtri IFilter abilitati in un server di cassette postali di Exchange (per l'indicizzazione di diversi formati di file)
• Utilizzo delle risorse di sistema globali di un server di cassette postali che esegue la ricerca per indicizzazione (limitazione)
• Molto altro…

In Microsoft utilizziamo sia nelle implementazioni aziendali che in diverse offerte di Office 365 un framework di ricostruzione della ricerca (Search Rebuild Framework) che ho sviluppato insieme al mio collega, Anatoly Girko. Questo framework è stato progettato in origine per offrire al personale preposto alle operazioni interne una serie di passaggi di convalida e di indicatori di stato dettagliati da utilizzare per l'esecuzione di operazioni di ricostruzione di indici di contenuto. Queste tecniche vengono utilizzate in corrispondenza di diverse attività cardine nell'ambito del processo di ricostruzione globale per garantirne l'esito positivo.

Con l'evoluzione del framework, abbiamo deciso di aggiungere ulteriori funzionalità per monitorare e archiviare la metrica della velocità effettiva nel tempo per una o tutte le operazioni di ricostruzione. Man mano che abbiamo raccolto dati e che si sono manifestati dati di tendenza, ci siamo accorti di poter effettuare stime molto più documentate e accurate sui tempi previsti per una determinata operazione di ricostruzione. Questo ci ha consentito in qualità di team operativo di scegliere in modo più accurato quando pianificare i processi di ricostruzione in modo da ridurre al minimo i disagi per gli utenti finali. Da quando è iniziata l'implementazione, questo framework è stato utilizzato per sovrintendere le operazioni per diverse migliaia di indici di contenuto nei vari ambienti supportati.

In una serie di articoli illustreremo questo "Search Rebuild Framework" in modo che le parti interessate possano applicare ai propri ambienti una metodologia simile in caso di necessità. Verrà illustrata nei dettagli ogni fase del framework e verranno descritti inoltre i diversi set di strumenti che abbiamo creato come supporto per il processo. Questa serie di articoli si concluderà con un gruppo di grafici e tabelle in cui verranno dettagliate le statistiche osservate nei processi di ricreazione dell'indicizzazione di contenuto e le conclusioni tratte finora. Per i clienti che non hanno tenuto traccia precedentemente delle statistiche relative a quest'area, ci auguriamo che questi dati rappresentino un utile punto di riferimento. Queste informazioni dovrebbero consentire di effettuare stime documentate dei tempi di ricostruzione degli indici di contenuto di Exchange nei relativi ambienti. Dopo questa premessa, è opportuno segnalare che poiché tutti gli ambienti Exchange sono unici, la metrica ottenuta per il processo di ricostruzione potrebbe differire in modo significativo dai tempi da noi osservati e presentati in questi articoli.

Prima di iniziare, è opportuno chiarire che questa serie di articoli non deve essere interpretata come una guida per la risoluzione dei problemi. Ci aspettiamo piuttosto che le operazioni di ricreazione siano state eseguite proprio in risposta a un problema o come misura preventiva. Tutti gli esempi presentati in questa serie si basano su Exchange 2007. Ho deciso di concentrarmi sulla versione 2007 per questo post perché esistono maggiori probabilità di dover ricreare indici di Exchange 2007 anziché indici della versione 2010. Diversamente da Exchange 2007, la versione 2010 offre la possibilità di eseguire il reseeding degli indici di contenuto da origini ridondanti integre, riducendo la necessità di eseguire ricostruzioni complete degli indici in architetture con più copie. Nelle prossime settimane rilascerò con Anatoly un post integrativo con il riferimento tecnico per lo script relativo alla versione dello script IndexRebuildAnalyzer per Exchange 2010 man mano che raccoglieremo dati di esempio per il relativo utilizzo.

Script IndexRebuildAnalyzer

In Microsoft il set di strumenti principale utilizzato internamente per la ricostruzione degli indici di contenuto è lo script IndexRebuildAnalyzer. Questo script è stato creato da me e Anatoly in modo particolare per determinare le linee di base per la ricostruzione degli indici di contenuto. Come affermato precedentemente, esistono due versioni di questo script; una per Exchange 2007 e una per Exchange 2010. Per calcolare correttamente le statistiche, utilizzare sempre lo script che corrisponde alla versione del database delle cassette postali di Exchange di cui deve essere ricostruito l'indice. Lo script IndexRebuildAnalyzer genera due tipi di metrica in base alla modalità di funzionamento passata dall'operatore. Internamente queste due modalità sono denominate "metrica di pre-ricostruzione" e "metrica di post-ricostruzione". Tutte le proprietà sono documentate nella sezione di riferimento tecnico per lo script riportata di seguito.

Benché questo script venga utilizzato principalmente per tenere traccia delle operazioni di ricostruzione degli indici di contenuto, gli Amministratori di Exchange possono sicuramente utilizzarlo in "modalità di pre-ricostruzione" per ottenere statistiche temporizzate Point-In-Time (PIT) relative alle cassette postali, ad esempio il numero di cassette postali ("Number of Mailboxes"), il numero di elementi contenuti in un database ("Number of Items in a Database"), la dimensione media dei messaggi ("Average Message Size") per l'intera organizzazione e così via. In questo modo è possibile usufruire di un ulteriore punto di vista e di funzionalità aggiuntive per il calcolo delle tendenze degli utenti qualora lo strumento venga utilizzato regolarmente in base alle esigenze o ai requisiti aziendali.

I parametri dello script E2K7_IndexRebuildAnalyzer.ps1 e gli esempi di utilizzo possono essere ottenuti passando il parametro -Help nella sessione di PowerShell prima dell'esecuzione dello script.

Nella tabella seguente viene descritto ogni parametro:

Intestazioni della metrica dei database

Pre-ricostruzione

Come già affermato precedentemente, la "modalità di funzionamento" dello script è determinata dalla presenza o dall'assenza dell'opzione -PostRebuild. Per ottenere la metrica di pre-ricostruzione, non deve essere utilizzata l'opzione -PostRebuild. Quando viene creata un'istanza dello script in modalità di pre-ricostruzione, verranno visualizzate le intestazioni seguenti con la metrica corrispondente:

Post-ricostruzione (utilizzo del parametro -PostRebuild)

Quando viene utilizzata l'opzione -PostRebuild, IndexRebuildAnalyzer tenta di calcolare la metrica della velocità effettiva per le operazioni di ricostruzione degli indici di contenuto. Questa operazione viene eseguita analizzando il registro eventi applicazioni per ottenere la data e l'ora di inizio (indicata dall'ID evento 109) e la data e l'ora di fine della ricostruzione (indicata dall'ID evento 110) per ogni database delle cassette postali nel server di cassette postali. Per calcolare correttamente la metrica di post-ricostruzione deve essere presente la coppia completa di ID evento nel Visualizzatore eventi per ogni database delle cassette postali di cui è stato reimpostato l'indice di contenuto corrispondente. Se la coppia di ID evento non è disponibile, lo script non sarà in grado di calcolare le statistiche. In questi casi verrà restituita la stringa "NoEventFound". Le cause più comuni per cui viene restituita questa stringa sono le seguenti:

• L'operazione di ricostruzione degli indici di contenuto per uno o più database non è stata completata.
• Il registro eventi applicazioni è stato troncato o cancellato. La procedura consigliata è impostare la dimensione massima del registro sul valore massimo supportato.
• Nei database delle cassette postali per cui è stato segnalato "NoEventFound" non sono stati recentemente reimpostati gli indici di contenuto e per questo motivo è assente la coppia ID evento nel registro eventi. Utilizzando l'opzione -CSVFile ed Excel è possibile escludere facilmente tramite filtro queste stringhe dal set di risultati. Fornirò esempi per questa operazione nel passaggio 5 del framework.

Tutte le intestazioni e la metrica di "pre-ricostruzione" vengono calcolate anche ogni volta che viene passata l'opzione -PostRebuild per l'esecuzione dello script. Utilizzando l'opzione -PostRebuild verranno incluse inoltre le intestazioni e la metrica seguenti:

Conclusione

È possibile scaricare lo script Exchange 2007 Index Rebuild Analyzer qui.

Nella seconda parte di questa serie di articoli descriverò il framework di ricostruzione della ricerca e nella terza parte illustrerò i risultati ottenuti finora in Microsoft.

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 1.