Erstellen von Baselines für die Neuerstellung von Exchange-Inhaltsindizes – Teil 2

Veröffentlichung des Originalartikels: 27.06.2012

In Teil 1 dieser Reihe habe ich das Skript E2K7_IndexRebuildAnalyzer.ps1 erläutert. In diesem Artikel wird das von Anatoly Girko und mir entwickelte Search Rebuild Framework behandelt. Dieses Framework hatten wir ursprünglich entwickelt, um unseren internen Spezialisten im operativen Bereich ein umfassendes Paket an Validierungsschritten und Fortschrittsindikatoren an die Hand zu geben, das sie bei Neuerstellungen von Inhaltsindizes nutzen konnten..

Stufe 1: Zusammenstellen von Statistiken vor der Neuerstellung

In unserer Umgebung läuft es so: Wenn entschieden wird, dass die Inhaltsindexdateien einer Exchange-Postfachdatenbank neu erstellt werden sollen, berechnet der Operator zuerst Statistiken vor der Neuerstellung für den betroffenen Speicher. Diese Statistiken werden zu Dokumentationszwecken immer in eine CSV-Datei geschrieben und schließlich in unsere Sammlung von historischen Daten eingefügt. Allerdings ist die Verwendung des -CSVFile-Parameters optional, wie schon erwähnt. In Situationen, in denen der -CSVFile-Parameter nicht übergeben wird, wird die entsprechende Ausgabe in das Shell-Konsolenfenster geschrieben. Der Übersichtlichkeit halber sollten Sie sowohl die Bildschirmpuffergröße als auch die Fenstergröße der Konsolenbreite anpassen, damit all die verschiedenen ausgegebenen Header und Metriken ordentlich untergebracht sind. Dadurch sind die Werte in der Konsolensitzung besser lesbar. Von dort aus leite ich die Ausgabe in der Regel mit dem -AutoSize-Parameter (-a) an Format-Table (ft) weiter.

Beispiele

Beispiel für die Ausgabe in einer Konsole:

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

Ausgabe :

Beispiel für die Ausgabe in einer CSV-Datei:

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

Ausgabe :

Die Metriken vor der Neuerstellung werden dann mit der Sammlung der historischen Daten verglichen, und eine durchschnittliche Neuerstellungsdauer wird abgeleitet. Dabei berücksichtigen wir den geografischen Standort der Postfachdatenbank und der zugehörigen Endbenutzer-Postfächer. Basierend auf dem geografischen Standort des Speichers und der geschätzten Ausführungsdauer terminieren wir den Neuerstellungsvorgang auf einen Zeitpunkt, zu dem ein geringes Aufkommen an Benutzeraktivitäten in diesem Speicher besteht.

Stufe 2: Zurücksetzen des Inhaltsindex für die betroffene(n) Postfachdatenbank(en)

Im nächsten Schritt setzen die Operatoren in unserer Umgebung dann den Inhaltsindex für die Postfachdatenbank zurück, und zwar mit einer der unter Erneutes Erstellen des Volltextindexkatalogs dokumentierten Vorgehensweisen.

In den folgenden Beispielen setze ich die Inhaltsindexdateien für zwei Postfachdatenbanken in meiner Umgebung zurück. Zufällig haben diese beiden Speicher auch die meisten Postfächer, die größten EDB-Dateien und insgesamt die meisten Datenbankelemente auf dem Postfachclusterserver NA1-ERICNOR-1:

Zurücksetzen der Inhaltsindexdateien:

Stufe 3: Überprüfen, ob die Suchindizierung erkannt hat, dass eine vollständige Durchforstung erforderlich ist

Nachdem die vorhandenen Inhaltsindexdateien aus dem Dateisystem entfernt worden sind und anschließend der Dienst Microsoft Exchange-Suchindizierung neu gestartet worden ist, muss der MonitorAndUpdateMDBList-Thread den aktuellen Status der Inhaltsindizes für alle Postfachdatenbanken auf dem Postfachserver ermitteln, für die die Inhaltsindizierung aktiviert ist. Sobald der MonitorAndUpdateMDBList-Thread den Integritätsstatus des Inhaltsindex für jede Postfachdatenbank ermittelt hat, platziert er den entsprechenden Integritätsstatus jeder Postfachdatenbank in den Arbeitsspeicher. Ist der Wert des Integritätsstatus des Inhaltsindex Neu, dann hat der Dienst Microsoft Exchange-Suchindizierung festgestellt, dass eine vollständige Durchforstung erforderlich ist, um die Inhaltsindexdateien in den Status "Fehlerfrei" zu bringen. (Dabei ist "Fehlerfrei" der Zustand, in dem der Index über Speicherbenachrichtigung auf dem neuesten Stand gehalten wird). An diesem Punkt initiiert der Dienst Exchange-Suchindizierung eine vollständige Durchforstung der betroffenen Postfachdatenbank.

Der Zeitpunkt, an dem der Vorgang der vollständigen Durchforstung tatsächlich beginnt, wird im Anwendungsereignisprotokoll anhand von Ereignis-ID 109 angegeben.

Um sicherzustellen, dass alle vollständigen Durchforstungen auf einem System begonnen haben, überprüft der Operator, ob Ereignis-ID 109 für jede Postfachdatenbank vorhanden ist, deren Inhaltsindex zuvor in Stufe 2 zurückgesetzt worden war.

Beispiel

Wie im vorherigen Beispiel veranschaulicht, wurden die Inhaltsindexdateien für NA1-ERICNOR-1-DB1 und NA1-ERICNOR-1-DB18 mithilfe des Skripts ResetSearchIndex zurückgesetzt. Um festzustellen, ob der Dienst Microsoft Exchange-Suchindizierung die vollständigen Durchforstungen gestartet hat, muss überprüft werden, ob für jede Postfachdatenbank auf dem Postfachserver eine eindeutige Ereignis-ID 109 vorhanden ist. Das ist offensichtlich der Fall:

Ereignistyp: Information
Ereignisquelle: MSExchange-Suchindizierung
Ereigniskategorie: Allgemein
Ereignis-ID: 109
Datum: 10.05.2012
Uhrzeit: 14:22:19
Computer: NA1-ERICNOR-1-A
Beschreibung: Die Exchange-Suchindizierung hat einen neuen Suchindex erstellt und führt eine vollständige Durchforstung für die Postfachdatenbank NA1-ERICNOR-1\NA1-ERICNOR-1-SG1\NA1-ERICNOR-1-DB1 (GUID = 5a1122be-b9bb-4d5b-853a-e689b1ea1129) aus.

Ereignistyp: Information
Ereignisquelle: MSExchange-Suchindizierung
Ereigniskategorie: Allgemein
Ereignis-ID: 109
Datum: 10.05.2012
Uhrzeit: 14:22:20
Computer: NA1-ERICNOR-1-A
Beschreibung: Die Exchange-Suchindizierung hat einen neuen Suchindex erstellt und führt eine vollständige Durchforstung für die Postfachdatenbank NA1-ERICNOR-1\NA1-ERICNOR-1-SG18\NA1-ERICNOR-1-DB18 (GUID = 2faba54d-1699-441e-8ac8-1a136d0b7b16) aus.

Hinweis: Eine brauchbare Alternative zur visuellen Überprüfung des Ereignisprotokolls wäre es, einfach das Get-EventLog-Cmdlet zu verwenden und die Start-Ereignisse in eine CSV zu schreiben. Beispiel:

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

Stufe 4: Überprüfen des Fortschritts und des Abschlusses der Suchindizierung

Nachdem der Operator sichergestellt hat, dass die vollständigen Durchforstungen gestartet wurden (über das Vorhandensein von Ereignis-ID 109), beobachtet er den allgemeinen Fortschritt der Neuerstellung mithilfe des Systemmonitors. Speziell die folgenden Objekte und Parameter werden überwacht:

• MSExchange-Suchindizierung\Anzahl von Datenbanken, die gecrawlt werden
• MSExchange-Suchindizierung\Anzahl indizierter Datenbanken, die durch Benachrichtigungen aktuell gehalten werden
• MSExchange-Suchindizes\<DB-Instanz, die gecrawlt wird>\Status des vollständigen Crawlmodus
• MSExchange-Suchindizes\<DB-Instanz, die gecrawlt wird>\Dokumentindizierungsrate
• MSExchange-Suchindizes\<DB-Instanz, die gecrawlt wird>\Anzahl der zum Crawlen verbliebenen Postfächer
• MSExchange-Suchindizes\<DB-Instanz, die gecrawlt wird>\Anzahl der zuletzt verschobenen Postfächer, die gecrawlt werden
• MSExchange-Suchindizes\<DB-Instanz, die gecrawlt wird>\Anzahl der ausstehenden Batches
• MSExchange-Suchindizes\<DB-Instanz, die gecrawlt wird>\Wert der Einschränkungsverzögerung

Anhand des MSExchangeSearchIndexer-Objekts kann ein Operator mühelos feststellen, wie viele Inhaltsindizes auf dem Server auf dem neuesten Stand sind und wie viele gerade aktiv gecrawlt werden. Wenn ein Postfachserver vollständig auf dem aktuellen Stand ist, ist der Wert für den Parameter Anzahl von Datenbanken, die gecrawlt werden immer gleich 0 und der Wert des Parameters "Anzahl indizierter Datenbanken, die durch Benachrichtigungen aktuell gehalten werden" entspricht der Anzahl der Postfachdatenbanken, für die die Inhaltsindizierung auf dem Server aktiviert ist.

In meinem Beispiel habe ich insgesamt 18 Postfachdatenbanken auf meinem E-Mail-Server, und für zwei dieser Datenbanken wird derzeit eine vollständige Durchforstung ausgeführt. Daher sollte der Wert für Anzahl von Datenbanken, die gecrawlt werden gleich 2 sein und der Wert für Anzahl indizierter Datenbanken, die durch Benachrichtigungen aktuell gehalten werden sollte gleich 16 sein. Dies ist auch tatsächlich der Fall:

Bei jedem Abschluss einer vollständigen Durchforstung für eine einzelne Postfachdatenbank werden Sie bestimmte Veränderungen der verschiedenen Objektparametern im Systemmonitor feststellen.

Auf der Ebene der MSExchange-Suchindizierung:

• Der Parameter Anzahl von Datenbanken, die gecrawlt werdenwird jeweils um 1 verringert.
• Der Parameter Anzahl indizierter Datenbanken, die durch Benachrichtigungen aktuell gehalten werden wird jeweils um 1 verringert.

Auf der Ebene der Postfachdatenbank-Indizes:

• Der Wert für Status des vollständigen Crawlmodus für die betreffende Datenbank ist auf 0 herabgesetzt worden (dies spiegelt den neuen Wert für den Integritätsstatus des Inhaltsindex wider, der vom MonitorAndUpdateMDBList-Überwachungsthread ermittelt wurde).
• Der Parameter Anzahl der zum Crawlen verbliebenen Postfächer sollte den Wert 0haben.
• Obwohl der Parameter Anzahl der zuletzt verschobenen Postfächer, die gecrawlt werden nicht speziell mit dem Neuerstellungsvorgang bei vollständigen Durchforstungen an sich zusammenhängt, solle sein Wert ebenfalls für jeden Index 0 sein. Bei der erfolgreichen Verschiebung von Exchange-Postfächern zwischen Exchange-Postfachdatenbanken (wenn für die Zieldatenbank die Inhaltsindizierung aktiviert ist) werden die Suchbenachrichtigungen in der Zieldatenbank vorübergehend ausgesetzt. Dies hat den Zweck, dass der Dienst Exchange-Suchindizierung einmalige Durchforstungen der zuletzt verschobenen Postfächer ausführen kann, um den Hauptindex vollständig auf den neuesten Stand zu bringen. Sobald die einmalige Durchforstung abgeschlossen ist, werden die Speicherbenachrichtigungen wieder fortgesetzt. Das Problem dabei: obwohl die vollständige Durchforstung technisch abgeschlossen ist, besteht immer noch die Möglichkeit, dass eine einmalige Durchforstung erfolgt, wenn zum gleichen Zeitpunkt wie bei der Neuerstellung des Inhaltsindex Postfächer verschoben wurden. Sofern dieser Parameter den Wert 0 hat, sind alle Durchforstungsaktivitäten für die Postfachdatenbank definitiv abgeschlossen. Eine Validierung würde dies entsprechend bestätigen.

Auf einem Exchange-Server, auf dem alle Inhaltsindizes vollständig auf dem neuesten Stand sind, wären folgende Angaben zu erwarten:

• MSExchange-Suchindizierung\Anzahl von Datenbanken, die gecrawlt werden ist gleich 0.
• MSExchange-Suchindizierung\Anzahl indizierter Datenbanken, die durch Benachrichtigungen aktuell gehalten werdenentspricht der Anzahl der Postfachdatenbanken, für die auf dem Postfachserver die Indizierung aktiviert ist.
• Status des vollständigen Crawlmodus ist für jede Exchange-Postfachdatenbank-Instanz auf dem Postfachserver gleich 0.
• Anzahl der zum Crawlen verbliebenen Postfächer ist für jede Exchange-Postfachdatenbank-Instanz auf dem Postfachserver gleich 0.
• Anzahl der zuletzt verschobenen Postfächer, die gecrawlt werden ist für jede Exchange-Postfachdatenbank-Instanz auf dem Postfachserver gleich 0.

In meinem Beispiel haben alle diese Parameter den Wert True. Damit kann ich nach Menschenermessen davon ausgehen, dass die Indizes erfolgreich neu erstellt worden sind und dass der Server im Hinblick auf den Inhaltsindex vollständig fehlerfrei ist:

Sobald nach Angaben im Systemmonitor alle Inhaltsindizes auf dem aktuellen Stand sind, kann der zuständige Operator das Anwendungsereignisprotokoll durchsehen und überprüfen, ob Ereignis-ID 110 vorhanden ist. Dies ist in der Microsoft Exchange-Suchindizierung das Ereignis für die Fertigstellung der vollständigen Durchforstung. Ähnlich wie bei Ereignis-ID 109 wird ein eindeutiger Eintrag für Ereignis 110 für jede Postfachdatenbank vorhanden sein, für die die vollständige Durchforstung abgeschlossen ist:

Ereignistyp: Information
Ereignisquelle: MSExchange-Suchindizierung
Ereigniskategorie: Allgemein
Ereignis-ID: 110
Datum: 10.05.2012
Uhrzeit: 17:39:47
Computer: NA1-ERICNOR-1-A
Beschreibung: Die Exchange-Suchindizierung hat einen vollständigen Crawlvorgang (Indizierung) von Postfachdatenbank NA1-ERICNOR-1\NA1-ERICNOR-1-SG1\NA1-ERICNOR-1-DB1 (GUID = 5a1122be-b9bb-4d5b-853a-e689b1ea1129) ausgeführt.

Ereignistyp: Information
Ereignisquelle: MSExchange-Suchindizierung
Ereigniskategorie: Allgemein
Ereignis-ID: 110
Datum: 05.10.2012
Uhrzeit: 17:11:47
Computer: NA1-ERICNOR-1-A
Beschreibung: Die Exchange-Suchindizierung hat einen vollständigen Crawlvorgang (Indizierung) von Postfachdatenbank NA1-ERICNOR-1\NA1-ERICNOR-1-SG18\NA1-ERICNOR-1-DB18 (GUID = 2faba54d-1699-441e-8ac8-1a136d0b7b16) ausgeführt.

Hinweis: Eine brauchbare Alternative zur visuellen Überprüfung des Ereignisprotokolls wäre es, einfach das Get-EventLog-Cmdlet zu verwenden und die Fertigstellungsereignisse in eine CSV zu schreiben. Beispiel:

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

Stufe 5: Erfassen von Metriken nach der Neuerstellung

In Stufe 5 wird davon ausgegangen, dass der Operator den Abschluss der vollständigen Durchforstung für jede Postfachdatenbank verifiziert hat. An diesem Punkt würde der Operator Metriken nach der Neuerstellung erfassen, um die Durchsatzwerte für jede durchforstete Postfachdatenbank zu ermitteln.

Zum Erfassen dieser Metriken wird das Skript E2K7_IndexRebuildAnalyzer mit dem Schalter -PostRebuild verwendet.

Wie bereits erwähnt, werden mit -PostRebuild die Anwendungsereignisprotokolle auf das Vorhandensein von Ereignis-ID 109 und Ereignis-ID 110 untersucht. Im Falle der fortlaufenden Clusterreplikation wird das Anwendungsereignisprotokoll für jeden Knoten im CCR-Cluster ausgewertet. Findet das Skript diese Ereignis-IDs, berechnet es die Gesamtzeit (in verschiedenen Zeiteinheiten), die für die Ausführung der vollständigen Durchforstung für jede Postfachdatenbank benötigt wurde. Anschließend gibt es die Durchsatzwerte für jeden einzelnen Neuerstellungsvorgang zurück.

Zu beachten ist wieder, dass alle Postfachdatenbanken auf dem Postfachserver ausgewertet werden, ungeachtet dessen, ob für alle Postfachdatenbanken die Suchindizes neu erstellt wurden oder nicht. Außerdem wird bei Instanziierung ohne die Option -CSVFile der Ergebnissatz in das Konsolenfenster ausgegeben. Ich empfehle unbedingt, beim Erfassen der Metriken nach der Neuerstellung die Option -CSVFile zu verwenden, da dies die Berichterstellung, Sortierung, Filterung und Pivotierung beim Verwenden von Excel sehr einfach macht.

Beispiel

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

Nachdem die Ausführung von E2K7_IndexRebuildAnalyzer abgeschlossen ist, kann die CSV-Datei untersucht werden. Diese Untersuchung ergibt, dass alle Exchange-Postfachdatenbanken auf dem Postfachserver verarbeitet worden sind. Die Zeichenfolge NoEventsFound wird für viele der Exchange-Postfachdatenbanken zurückgegeben, da die Ereignis-ID-Paarkombination der Suchindizierung nicht gefunden werden kann. Im aktuellen Beispiel wird für 16 Postfachdatenbanken "NoEventsFound" gemeldet, und 2 Postfachdatenbanken haben gültige Metriken nach der Neuerstellung:

Dieses Ergebnis können Sie weiter präzisieren, indem Sie einen einfachen textbasierten Filter in Excel anwenden. Wenn Sie einen der Spaltenheader nach der Neuerstellung filtern und die Zeichenfolge NoEventFound deaktivieren, werden nur Datenbanken mit Metriken nach der Neuerstellung angezeigt:

Ergebnis: Durch das Anwenden dieses Filters auf den Beispielergebnissatz werden jetzt nur noch NA1-ERICNOR-1-DB1 und NA1-ERICNOR-1-DB18 angezeigt (d. h. die Postfachdatenbanken, deren Inhaltsindizes zurückgesetzt worden sind). Außerdem lässt sich feststellen, dass die Metriken nach der Neuerstellung erfolgreich bestätigt wurden, da gültige Werte für die verschiedenen Header nach der Neuerstellung vorhanden sind:

Filteranwendung nach der Neuerstellung:

Stufe 6: Validierung mit "Test-ExchangeSearch"

Stufe 6 im "Rebuild Framework" stellt sicher, dass jedes Postfach, das in Postfachdatenbanken verwaltet wird, deren Inhaltsindizes zurückgesetzt wurden, jetzt gültige Suchergebnisse zurückgeben kann. Dazu können Sie die Kernfunktionen des Test-ExchangeSearch-Cmdlets nutzen. Die endgültige Validierung ist erst dann abgeschlossen, wenn das Cmdlet für alle Postfächer die Antwort True zurückgibt.

Beispiel:

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

Die Ausführung dieses Prozesses nimmt sehr viel Zeit in Anspruch, je nachdem, wie viele Postfächer die Datenbank enthält. Beachten Sie auch, dass beim Durchführen von Massenvorgängen mit Test-ExchangeSearch die Eigenschaften ResultFound und SearchTime erst im Konsolenfenster angezeigt werden, nachdem alle Postfächer verarbeitet worden sind (unabhängig von True- oder False-Ergebnissen). In manchen Fällen kann es auch sinnvoll sein, alle Ergebnisse zu Dokumentationszwecken in einer CSV-Datei zu speichern.

Endbenutzer-Postfächer, für die der Test Test-ExchangeSearch den Wert False zurückgibt, werden als einmalige Probleme behandelt und entsprechend bearbeitet.

Stufe 7: Analyse der Metriken nach der Neuerstellung

Zur besseren Lesbarkeit stelle ich die verschiedenen Metriken im Tabellenformat dar und nicht in den ursprünglichen Excel-Spalten. Wie schon erwähnt, waren auf dem Postfachclusterserver NA1-ERICNOR-1 zwei Exchange-Postfachdatenbanken, deren Inhaltsindizes neu erstellt wurden: NA1-ERICNOR-1-DB1 und NA1-ERICNOR-1-DB18.

Postfachmetriken nach der Neuerstellung:

Metriken für die Neuerstellung von Postfachdatenbanken:

Die verschiedenen Metriken vor und nach der Neuerstellung werden dann der Sammlung von historischen Daten hinzugefügt und fließen somit in die historischen Durchschnittswerte für zukünftige Neuerstellungsvorgänge ein.

Schlussbemerkung

Im zweiten Beitrag zu dieser Artikelreihe habe ich die Stufen des "Search Rebuild Framework" beschrieben. Im dritten und letzten Beitrag erläutere ich die Durchschnittswerte, die wir in unseren Bereitstellungen bei Microsoft beobachtet haben.

Eric Norberg
Service Engineer
Office 365

Dies ist ein übersetzter Blogbeitrag. Den Originalartikel finden Sie unter Establishing Exchange Content Index Rebuild Baselines – Part 2