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

Articolo originale pubblicato mercoledì 27 giugno 2012

Nella Parte 1 di questa serie ho descritto lo script E2K7_IndexRebuildAnalyzer.ps1.  In questo articolo illustrerò invece il Search Rebuild Framework che ho sviluppato insieme ad 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.

Fase 1: raccolta delle statistiche di pre-ricostruzione

Nel nostro ambiente ogni volta che si decide di ricostruire i file di indice di contenuto di un database delle cassette postali di Exchange, l'operatore inizia calcolando innanzitutto le statistiche di pre-ricostruzione per l'archivio interessato. Queste statistiche vengono sempre scritte in formato CSV a scopo di documentazione e vengono inserite infine nel set di raccolte dati di cronologia. Come già affermato in precedenza, l'utilizzo del parametro -CSVFile tuttavia è facoltativo. In situazioni in cui non viene passato il parametro -CSVFile, l'output corrispondente verrà scritto nella finestra della console della shell. Per migliorare la leggibilità, è consigliabile modificare i valori di Screen Buffer Size Width e Window Size Width della console in modo da visualizzare correttamente tutte le intestazioni e la metrica che verranno generate. In questo modo sarà possibile leggere più facilmente i valori nella sessione della console. Dalla console in genere invio tramite "pipe" l'output su Format-Table (ft) con il parametro -AutoSize (-a) .

Esempi

Esempio nella console:

.\E2K7_IndexRebuildAnalyzer.ps1 -CMS NA1-ERICNOR-1 | ft -a

Output :

Esempio in formato CSV:

.\E2K7_IndexRebuildAnalyzer.ps1 -CMS NA1-ERICNOR-1 -CSVFile c:\ericnor\NA-1ERICNOR-1_PreRebuild.csv

Output :

La metrica di pre-ricostruzione viene quindi confrontata con la raccolta dati di cronologia per stimare il tempo medio necessario per la ricostruzione. Per il calcolo teniamo conto della posizione geografica del database delle cassette postali e delle corrispondenti cassette postali degli utenti finali. In base alla distribuzione geografica dell'archivio e al tempo stimato per il completamento dell'operazione, pianifichiamo il processo di ricostruzione per una data/ora in cui le attività degli utenti nell'archivio sono ridotte al minimo.

Fase 2: reimpostazione dell'indice di contenuto per i database delle cassette postali interessati

Gli operatori procedono quindi nell'ambiente a reimpostare l'indice di contenuto per il database delle cassette postali utilizzando una delle tecniche illustrate in Come ricreare il catalogo dell'indice di testo completo.

Nell'esempio riportato di seguito reimposterò i file di indice di contenuto di due database delle cassette postali presenti nell'ambiente. Questi due archivi presentano inoltre i valori più elevati di numeri di cassette postali (Mailbox Count), dimensioni dei file EDB (EDB Size) e numeri collettivi di elementi di database (Database: Total Items) nel server di cassette postali in cluster NA1-ERICNOR-1:

Reimpostazione dei file di indice di contenuto:

Fase 3: verifica che il servizio Indicizzatore ricerca abbia rilevato la necessità di eseguire la ricerca per indicizzazione completa

Dopo la rimozione dei file di indicizzazione di contenuto dal file system e il successivo riavvio del servizio Indicizzatore ricerca di Microsoft Exchange, è compito del thread MonitorAndUpdateMDBList determinare lo stato corrente degli indici di contenuto di tutti i database delle cassette postali del server di cassette postali abilitati per l'indicizzazione di contenuto. Dopo aver determinato lo stato di integrità degli indici di contenuto di ogni database delle cassette postali, il thread MonitorAndUpdateMDBList inserisce il valore di stato di integrità di ogni database delle cassette postali in memoria. Se i valore dello stato di integrità degli indici di contenuto è uguale a "New", il servizio Indicizzatore ricerca di Microsoft Exchange ha determinato che è necessaria una ricerca per indicizzazione completa per ripristinare nei file di indice di contenuto uno stato di integrità (per "integrità" si intende il punto in cui l'indice viene mantenuto aggiornato tramite notifica di archiviazione). È a questo punto che il servizio Indicizzatore ricerca di Microsoft Exchange avvia un'operazione di ricerca per indicizzazione completa nel database delle cassette postali interessato.

La data e l'ora di inizio effettivo dell'operazione di ricerca per indicizzazione completa sono indicate nel registro eventi applicazioni dall'ID evento 109.

Per accertarsi che in un sistema siano iniziate tutte le operazioni di ricerca per indicizzazione completa, l'operatore che esegue l'attività verificherà l'esistenza dell'ID evento 109 per ogni database delle cassette postali il cui indice di contenuto è stato precedentemente reimpostato al passaggio 2.

Esempio

Come illustrato nell'esempio precedente, i file di indice di contenuto per NA1-ERICNOR-1-DB1 e NA1-ERICNOR-1-DB18 sono stati reimpostati utilizzando lo script ResetSearchIndex. Per accertarsi che il servizio Indicizzatore ricerca di Microsoft Exchange abbia iniziato le operazioni di ricerca per indicizzazione completa, verificare che sia presente un ID evento 109 univoco per ogni database delle cassette postali nel server di cassette postali, come è possibile osservare negli esempi seguenti:

Tipo evento: Informazioni
Origine evento: Indicizzatore di ricerca di MSExchange
Categoria evento: Generale
ID evento: 109
Data: 10/05/2012
Ora: 14:22:19
Computer: NA1-ERICNOR-1-A
Descrizione: L'Indicizzatore di ricerca di Exchange ha creato un nuovo indice di ricerca ed eseguirà una ricerca per indicizzazione completa del database delle cassette postali NA1-ERICNOR-1\NA1-ERICNOR-1-SG1\NA1-ERICNOR-1-DB1 (GUID = 5a1122be-b9bb-4d5b-853a-e689b1ea1129).

Tipo evento: Informazioni
Origine evento: Indicizzatore di ricerca di MSExchange
Categoria evento: Generale
ID evento: 109
Data: 10/05/2012
Ora: 14:22:20
Computer: NA1-ERICNOR-1-A
Descrizione: L'Indicizzatore di ricerca di Exchange ha creato un nuovo indice di ricerca ed eseguirà una ricerca per indicizzazione completa del database delle cassette postali NA1-ERICNOR-1\NA1-ERICNOR-1-SG18\NA1-ERICNOR-1-DB18 (GUID = 2faba54d-1699-441e-8ac8-1a136d0b7b16).

Nota: in contrapposizione all'esame visivo del registro eventi, un'altra tecnica applicabile consiste nell'utilizzare semplicemente il cmdlet Get-EventLog e scrivere gli eventi di avvio in formato CSV. Esempio:

Get-EventLog "Applicazione" | Where-Object {$_.EventID -eq 109} | Select-Object EventID,TimeGenerated,Message | Export-CSV -NoTypeInformation -Path c:\Search_StartEvents.csv

Passaggio 4: verifica dell'avanzamento e del completamento dell'attività del servizio Indicizzatore ricerca

Dopo aver verificato che le operazioni di ricerca per indicizzazione completa siano iniziate (presenza dell' ID evento 109), l'operatore monitorizza l'avanzamento globale del processo di ricostruzione utilizzando System Monitor. In particolare devono essere monitorati gli oggetti e i contatori seguenti:

• Indicizzatore di ricerca di MSExchange\Numero di database di cui è in corso la ricerca per indicizzazione
• Indicizzatore di ricerca di MSExchange\Numero di database indicizzati mantenuti aggiornati tramite notifiche
• Indici di ricerca di MSExchange\<Istanza di database sottoposta a ricerca per indicizzazione>\Stato modalità ricerca per indicizzazione completa
• Indici di ricerca di MSExchange\<Istanza di database sottoposta a ricerca per indicizzazione>\Frequenza indicizzazione documenti
• Indici di ricerca di MSExchange\<Istanza di database sottoposta a ricerca per indicizzazione>\Numero di cassette postali rimaste da ricercare per l'indicizzazione
• Indici di ricerca di MSExchange\<Istanza di database sottoposta a ricerca per indicizzazione>\Numero di cassette postali spostate di recente con ricerca per indicizzazione in corso
• Indici di ricerca di MSExchange\<Istanza di database sottoposta a ricerca per indicizzazione>\Numero di batch in attesa
• Indici di ricerca di MSExchange\<Istanza di database sottoposta a ricerca per indicizzazione>\Limitazione del valore di ritardo in corso

Esaminando l'oggetto Indicizzatore di ricerca di MSExchange, un operatore può facilmente verificare quanti indici di contenuto nel server siano aggiornati e quanti siano attivamente sottoposti a ricerca per indicizzazione. Quando un server di cassette postali è completamente aggiornato, il valore del contatore "Numero di database di cui è in corso la ricerca per indicizzazione" è sempre pari a 0 e il valore del contatore "Numero di database indicizzati mantenuti aggiornati tramite notifiche" è uguale al numero di database delle cassette postali abilitati per l'indicizzazione di contenuto nel server.

Nell'esempio sono presenti 18 database delle cassette postali in totale nel server della posta e due di questi database sono attualmente sottoposti a ricerca per indicizzazione completa. Il valore del contatore "Numero di database di cui è in corso la ricerca per indicizzazione" (Number of Databases Being Crawled) pertanto dovrebbe essere pari a 2 e il valore del contatore "Numero di database indicizzati mantenuti aggiornati tramite notifiche" (Number of Indexed Databases Being Kept Up-to-Date by Notifications) dovrebbe essere pari a 16, come effettivamente è possibile osservare:

Man mano che nei singoli database delle cassette postali viene completata la ricerca per indicizzazione completa, è possibile osservare cambiamenti specifici nei contatori degli oggetti in System Monitor.

A livello di Indicizzatore di ricerca di MSExchange:

• Il valore del contatore "Numero di database di cui è in corso la ricerca per indicizzazione" diminuisce di un'unità
• Il valore del contatore "Numero di database indicizzati mantenuti aggiornati tramite notifiche" aumenta di un'unità

A livello di indice/indici di database delle cassette postali:

• Il valore di "Stato modalità ricerca per indicizzazione completa" nel database specifico è diminuito a 0 (in conformità con il nuovo valore dello stato Content Index Health determinato dal thread di monitoraggio MonitorAndUpdateMDBList).
• Il valore di "Numero di cassette postali rimaste da ricercare per l'indicizzazione" deve essere pari a 0.
• Pur non essendo specificatamente correlato in modo intrinseco all'operazione di ricostruzione della ricerca per indicizzazione completa, anche il valore del contatore "Numero di cassette postali spostate di recente con ricerca per indicizzazione in corso" deve essere pari a 0 per ogni indice. Quando le cassette postali di Exchange vengono spostate tra database delle cassette postali di Exchange (purché la destinazione sia abilitata per l'indicizzazione del contenuto), le notifiche di ricerca nel database di destinazione vengono temporaneamente sospese. Il servizio Indicizzatore ricerca di Microsoft Exchange procede in questo modo per poter eseguire ricerche per indicizzazione singole delle cassette postali recentemente spostate e aggiornare completamente l'indice master. Al termine delle ricerche per indicizzazione singole vengono riprese le notifiche di archiviazione. Considerare però che anche se la ricerca per indicizzazione completa è tecnicamente terminata, è comunque possibile che siano in corso ricerche per indicizzazione singole se gli spostamenti di cassette postali sono stati eseguiti contemporaneamente alla ricostruzione degli indici di contenuto. Se il valore di questo contatore è pari a 0, tutte le attività di ricerca per indicizzazione eseguite nel database delle cassette postali sono state sicuramente completate e pertanto devono essere convalidate come tali.

In un'istanza di Exchange Server in cui tutti gli indici di contenuto sono completamente aggiornati, i valori dei contatori dovrebbero essere i seguenti:

• "Indicizzatore di ricerca di MSExchange\Numero di database di cui è in corso la ricerca per indicizzazione" uguale a 0.
• "Indicizzatore di ricerca di MSExchange\Numero di database indicizzati mantenuti aggiornati tramite notifiche" uguale al numero di database delle cassette postali abilitati per l'indicizzazione nel server di cassette postali.
• "Stato modalità ricerca per indicizzazione completa" per ogni istanza di database delle cassette postali di Exchange nel server di cassette postali uguale a 0.
• "Numero di cassette postali rimaste da ricercare per l'indicizzazione" per ogni istanza di database delle cassette postali di Exchange nel server di cassette postali uguale a 0.
• "Numero di cassette postali spostate di recente con ricerca per indicizzazione in corso" per ogni istanza di database delle cassette postali di Exchange nel server di cassette postali uguale a 0.

Nell'esempio tutti questi valori restituiscono True e pertanto posso ragionevolmente presumere che gli indici siano stati ricostruiti correttamente e che dal punto di vista dell'indice di contenuto il server sia completamente integro:

Dopo che tutti gli indici di contenuto risultano aggiornati in System Monitor, l'operatore che esegue l'attività esaminerà il registro eventi applicazioni e verificherà l'esistenza dell'ID evento 110, ovvero l'evento di completamento della ricerca per indicizzazione completa del servizio Indicizzatore ricerca di Microsoft Exchange. Analogamente all'ID evento 109, sarà presente un ID evento 110 univoco per ogni database delle cassette postali per cui è stata eseguita la ricerca per indicizzazione completa:

Tipo evento: Informazioni
Origine evento: Indicizzatore di ricerca di MSExchange
Categoria evento: Generale
ID evento: 110
Data: 10/05/2012
Ora: 17:39:47
Computer: NA1-ERICNOR-1-A
Descrizione: L'Indicizzatore di ricerca di Exchange ha terminato una ricerca per indicizzazione completa del database delle cassette postali NA1-ERICNOR-1\NA1-ERICNOR-1-SG1\NA1-ERICNOR-1-DB1 (GUID = 5a1122be-b9bb-4d5b-853a-e689b1ea1129).

Tipo evento: Informazioni
Origine evento: Indicizzatore di ricerca di MSExchange
Categoria evento: Generale
ID evento: 110
Data: 10/05/2012
Ora: 17:11:47
Computer: NA1-ERICNOR-1-A
Descrizione: L'Indicizzatore di ricerca di Exchange ha terminato una ricerca per indicizzazione completa del database delle cassette postali NA1-ERICNOR-1\NA1-ERICNOR-1-SG18\NA1-ERICNOR-1-DB18 (GUID = 2faba54d-1699-441e-8ac8-1a136d0b7b16).

Nota: in contrapposizione all'esame visivo del registro eventi, un'altra tecnica applicabile consiste nell'utilizzare semplicemente il cmdlet Get-EventLog e scrivere gli eventi di completamento in formato CSV. Esempio:

Get-EventLog "Applicazione" | Where-Object {$_.EventID -eq 110} | Select-Object EventID,TimeGenerated,Message | Export-CSV -NoTypeInformation -Path c:\Search_CompletionEvents.csv

Fase 5: raccolta della metrica di post-ricostruzione

Nel passaggio 5 si presuppone che l'operatore abbia verificato che sia stata eseguita la ricerca per indicizzazione completa di ogni database delle cassette postali. È a questo punto che l'operatore raccoglierà la metrica di post-ricostruzione per determinare le caratteristiche di velocità effettiva per ogni database delle cassette postali sottoposto a ricerca per indicizzazione.

Per raccogliere questi dati, viene eseguito lo script E2K7_IndexRebuildAnalyzer con l'opzione -PostRebuild.

Come indicato precedentemente, con l'opzione -PostRebuild viene ricercata nei registri eventi applicazioni la presenza sia dell'ID evento 109 che dell'ID evento 110. In caso di replica di cluster continua, verrà valutato il registro eventi applicazioni di ogni nodo di replica continua cluster (CCR). Se lo script individua questi ID evento, calcolerà il tempo totale (in diversi incrementi di tempo) necessario per eseguire la ricerca per indicizzazione completa in ogni database delle cassette postali. Restituirà quindi all'operatore le caratteristiche di velocità effettiva di ogni singola operazione di ricostruzione.

È opportuno ribadire che verranno valutati tutti i database delle cassette postali del server di cassette postali, indipendentemente dal fatto che i relativi indici di ricerca siano stati ricostruiti. Se inoltre viene creata un'istanza senza l'opzione -CSVFile, il set di risultati verrà generato nella finestra della console. Quando si calcolano le statistiche di post-ricostruzione, consiglio di utilizzare -CSVFile, poiché consente di creare report, di eseguire il calcolo pivot e di ordinare e filtrare i dati facilmente in Excel.

Esempio

.\E2K7_IndexRebuildAnalyzer.ps1 -CMS NA1-ERICNOR-1 -PostRebuild -CSVFile c:\ericnor\NA1-ERICNOR-1_PostRebuild.csv

Al termine dell'esecuzione di E2K7_IndexRebuildAnalyzer, è possibile esaminare il file CSV. Dall'analisi del file CSV risulta che sono stati elaborati tutti i database delle cassette postali di Exchange nel server di cassette postali. Per molti database delle cassette postali di Exchange viene restituita la stringa "NoEventFound" perché è impossibile individuare la combinazione di coppie di ID evento del servizio Indicizzatore ricerca. Nel caso di questo esempio per 16 database delle cassette postali viene restituita la stringa "NoEventFound" e per due database delle cassette postali è presente una metrica di post-ricostruzione valida:

Questo set di risultati può essere ulteriormente perfezionato applicando un filtro basato su testo semplice in Excel. Applicando un filtro a una delle intestazioni di colonna di post-ricostruzione e deselezionando la stringa "NoEventFound", verranno visualizzati solo i database con metrica di post-ricostruzione valida:

Applicando questo filtro al set di risultati di esempio vengono visualizzati solo NA1-ERICNOR-1-DB1 e NA1-ERICNOR-1-DB18, ovvero i database delle cassette postali per cui sono stati reimpostati gli indici di contenuto. È evidente inoltre che la metrica di post-ricostruzione è stata verificata correttamente poiché vengono presentati valori validi per le diverse intestazioni di post-ricostruzione:

Applicazione del filtro stringa di post-ricostruzione:

Fase 6: convalida tramite Test-ExchangeSearch

Nella fase 6 del Search Rebuild Framework viene verificato che ogni cassetta postale situata nei database delle cassette postali per cui sono stati reimpostati gli indici di contenuto possa ora restituire risposte di ricerca valide. Questo obiettivo può essere raggiunto utilizzando le funzionalità di base del cmdlet Test-ExchangeSearch. La convalida finale è completa solo dopo che tutte le cassette postali hanno restituito True al cmdlet.

Esempio:

Get-Mailbox -Database NA1-ERICNOR-1\ NA1-ERICNOR-1-SG1\ NA1-ERICNOR-1-DB1 | Test-ExchangeSearch | ft -a

Get-Mailbox -Database NA1-ERICNOR-1\ NA1-ERICNOR-1-SG18\ NA1-ERICNOR-1-DB18 | Test-ExchangeSearch | ft -a

Per eseguire questo processo sarà necessario molto tempo, a seconda del numero di cassette postali contenute nel database. È opportuno inoltre segnalare che quando vengono eseguite operazioni globali con Test-ExchangeSearch, le proprietà ResultFound e SearchTime saranno visibili nella finestra della console solo dopo l'elaborazione di tutte le cassette postali (indipendentemente dal fatto che sia stato restituito True o False). In alcuni casi sarebbe anche consigliabile archiviare tutti i risultati in formato CSV a scopo di documentazione.

Le eventuali cassette postali di utenti finali che restituiscono False al test eseguito tramite Test-ExchangeSearch verranno trattate come problemi singoli e corrette di conseguenza.

Passaggio 7: analisi della metrica di post-ricostruzione

Per migliorare la leggibilità, fornirò i diversi valori di metrica in formato tabulare, diversamente dalla visualizzazione nativa in colonne di Excel. Come precedentemente indicato, la ricostruzione degli indici di contenuto è stata effettuata per due database delle cassette postali di Exchange nel server di cassette postali in cluster NA1-ERICNOR-1: NA1-ERICNOR-1-DB1 e NA1-ERICNOR-1-DB18

Metrica di post-ricostruzione delle cassette postali:

Metrica di ricostruzione dei database delle cassette postali:

I diversi valori di metrica di ricostruzione e di metrica di pre-ricostruzione vengono quindi aggiunti alla raccolta dati di cronologia in modo che possano essere utilizzati per il calcolo delle medie osservate nel tempo per esercizi di ricostruzione futuri.

Conclusione

Nel secondo post di questa serie ho descritto le fasi del Search Rebuild Framework. Nel terzo e ultimo post verranno illustrate le medie osservate nell'ambito delle nostre distribuzioni 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 2.