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

Veröffentlichung des Originalartikels: 26.06.2012

Eine der ersten Maßnahmen, die die meisten Exchange-Administratoren in der Regel bei der Behandlung von vermuteten Problemen mit der Exchange-Inhaltsindizierung ergreifen, ist die Neuerstellung der betroffenen Inhaltsindexdateien der Postfachdatenbank (entweder manuell oder mithilfe des Skripts ResetSearchIndex.ps1 aus dem Verzeichnis \Exchange Server\Scripts). Im Laufe der Jahre habe ich auch mit vielen Exchange-Administratoren zusammengearbeitet, die Suchindizes zu mehreren Zeitpunkten während des Kalenderjahrs proaktiv oder bei Erreichung verschiedener Meilensteine innerhalb eines Projekts (z. B. eines Migrationsprojekts) neu erstellt haben.

Unabhängig von der jeweiligen Begründung für die Neuerstellung der Indizes können die meisten Administratoren auf Anfrage keine realistische Schätzung darüber abgeben, wie lang dieser Prozess von Anfang bis Ende dauert. Welche unangenehmen Begleiterscheinungen die Unmöglichkeit einer genauen Einschätzung der Dauer hat, ist von Organisation zu Organisation verschieden. Manche IT-Abteilungen raten davon ab, während des Geschäftstags keine serverseitigen Indizes für Benutzer zur Verfügung zu haben und nennen Produktivitätseinbußen bei den Endbenutzern sowie eine erhöhte Zahl von eskalierten Problemen, die beim Helpdesk eingehen, als Gründe. Aus der Sicht des IT-Betriebs kann die Unkenntnis über die zu erwartende Dauer von Neuerstellungen auch dazu führen, dass Exchange-Administratoren nicht auf potenzielle Probleme innerhalb des Neuerstellungsvorgangs selbst aufmerksam gemacht werden. Wie auch immer man die Sache anpackt, eine realistische Einschätzung der voraussichtlichen Dauer des Prozesses ist sehr wertvoll.

Leider sind heutzutage kaum Informationen darüber verfügbar, wie lange es dauert (oder besser gesagt dauern sollte), einen Exchange-Inhaltsindex neu zu erstellen. Der Grund hierfür ist anscheinend, dass die tatsächliche Neuerstellungsdauer immer unterschiedlich ist. Sie wird nämlich von zahlreichen Faktoren beeinflusst, insbesondere von folgenden:

• Unterschiedliche Gesamtzahl der Endbenutzer-Postfächer, die in einer Exchange-Postfachdatenbank verwaltet werden
• Unterschiedliche Größe der Postfächer, die in einer Exchange-Postfachdatenbank enthalten sind
• Unterschiedliche Anzahl der Elemente in den verschiedenen Endbenutzer-Postfächern, die in einer Exchange-Postfachdatenbank verwaltet werden
• Unterschiedliche Anzahl der Elemente in den verschiedenen Exchange-Postfachdatenbanken (bei Ausführung von gleichzeitigen Neuerstellungen)
• Unterschiedliche Größe der Elemente, die sich in einer Exchange-Postfachdatenbank befinden
• Unterschiedliche Anzahl und Größe der E-Mail-Anhänge, die sich in einer Exchange-Postfachdatenbank befinden
• Typen und Anzahl der aktivierten IFilter auf einem Exchange-Postfachserver (zur Indizierung unterschiedlicher Dateiformate)
• Allgemeine Auslastung der Systemressourcen durch die Ausführung einer Durchforstung auf einem Postfachserver (z. B. Drosselung)
• Und vieles mehr ...

Bei Microsoft verwenden wir (sowohl in der unternehmensinternen Implementierung als auch in verschiedenen Office 365-Angeboten) ein Search Rebuild Framework, das von meinem Kollegen Anatoly Girko und mir entwickelt wurde. 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. Diese Verfahren werden an verschiedenen wichtigen Meilensteinen während des gesamten Neuerstellungsprozesses angewendet, um eine erfolgreiche Durchführung sicherzustellen.

Das Framework entwickelte sich weiter, und so beschlossen wir, zusätzliche Funktionen einzubinden, mit denen wir historische Durchsatzmetriken für alle Neuerstellungsvorgänge verfolgen und speichern konnten. Mit zunehmender Größe dieser Datensammlungen und immer aufschlussreicheren resultierenden Trenddaten konnten wir deutlich fundiertere und genauere Schätzungen der Dauer von Neuerstellungsvorgängen abgeben. Dadurch konnten wir im operativen Einsatz wiederum den Zeitpunkt von Neuerstellungen sinnvoller planen, beispielsweise um die Unterbrechungen aufseiten der Endbenutzer so kurz wie möglich zu halten. Seit seinen Anfängen ist dieses Framework nun schon zur Überwachung von Neuerstellungen für Tausende von Inhaltsindizes in den unterschiedlichen von uns unterstützten Umgebungen eingesetzt worden.

In dieser Artikelreihe wollen wir unser "Rebuild Framework" erläutern, sodass Interessierte eine ähnliche Methodik in ihren eigenen Umgebungen anwenden können, falls dies erforderlich sein sollte. Jede Stufe des Frameworks wird ausführlich beschrieben. Ergänzt werden diese Informationen durch Erklärungen der verschiedenen Toolsets, die wir zur Unterstützung dieses Prozesses geschrieben haben. Abgeschlossen wird die Artikelreihe mit einer Zusammenstellung von Diagrammen und Tabellen, die unsere auf Beobachtung basierenden Statistiken und Schlussfolgerungen zu den Neuerstellungen von Inhaltsindizes bis dato aufzeigen. Wir hoffen, dass diese Angaben Kunden, die bisher in diesem Bereich noch keine Statistiken erstellt haben, als wertvolle Orientierungshilfe dienen. Wir nehmen an, dass Sie anhand dieser Daten die Dauer von Neuerstellungen von Exchange-Inhaltsindizes in ihren eigenen Umgebungen genauer schätzen können. Abgesehen davon weisen wir darauf hin, dass Ihre Neuerstellungsmetriken aufgrund der Einzigartigkeit jeder Exchange-Umgebung erheblich von den Werten abweichen können, die wir gemessen haben und hier wiedergeben.

Bevor wir uns kopfüber in die Materie stürzen, möchte ich noch darauf hinweisen, dass diese Artikelreihe nicht als Leitfaden für die Problembehandlung gedacht ist. Wir gehen davon aus, dass Sie als Ergebnis eigener Problembehandlungsschritte zu dem Entschluss gekommen sind, Neuerstellungen entweder als Reaktion auf ein Problem oder als proaktive Maßnahme auszuführen. Alle in dieser Reihe geschilderten Beispiele basieren schwerpunktmäßig auf Exchange 2007. Ich habe mich für diesen Beitrag für Exchange 2007 entschieden, weil die Wahrscheinlichkeit, dass Indizes in der 2007er Version neu erstellt werden, deutlich höher ist als bei Exchange 2010 (anders als die 2007er Version kann Exchange 2010 ein erneutes Seeding von Inhaltsindizes aus fehlerfreien redundanten Quellen ausführen, sodass es in Architekturen mit mehreren Kopien weitaus seltener notwendig ist, vollständige Indexneuerstellungen auszuführen). In den nächsten Wochen werden Anatoly und ich einen ergänzenden Beitrag veröffentlichen, der die Skriptreferenz für die Exchange 2010-Version des Skripts für die Analyse der Inhaltsindex-Neuerstellung enthält, sobald wir genügend einschlägige Anwendungsbeispiele gesammelt haben.

Skript für die Analyse der Indexneuerstellung

Das wichtigste Toolset, das wir intern bei Microsoft für die Neuerstellung von Inhaltsindizes verwenden, ist das Skript IndexRebuildAnalyzer. Dieses Skript haben Anatoly und ich speziell für die Erstellung von Baselines für die Neuerstellung von Inhaltsindizes geschrieben. Wie schon erwähnt, gibt es zwei Versionen von diesem Skript: eine Exchange 2007-Version und eine Exchange 2010-Version. Damit Ihre Statistiken stimmen, verwenden Sie immer das Skript, das der Version der Exchange-Postfachdatenbank entspricht, deren Index neu erstellt wird. Das Skript IndexRebuildAnalyzer generiert zwei Typen von Metriken, die von dem Ausführungsmodus abhängig sind, der vom Operator übergeben wird. Intern bezeichnen wir diese zwei Modi als "Metrik vor der Neuerstellung" und "Metrik nach der Neuerstellung" (alle Eigenschaften sind im Abschnitt "Skriptreferenz" weiter unten dokumentiert).

Obwohl dieses Skript primär zur Überwachung von Inhaltsindex-Neuerstellungen genutzt wird, könnten Exchange-Administratoren es sicher im Modus "vor der Neuerstellung" verwenden, um zeitpunktbezogene (Point-In-Time (PIT) ) Statistiken für verschiedene postfachbezogene Zwecke zu gewinnen (z. B. "Anzahl der Postfächer", "Anzahl der Elemente in einer Datenbank", "durchschnittliche Nachrichtengröße" für die gesamte Organisation usw.). Dadurch können Sie beispielsweise zusätzliche Grafiken und Funktionen für die Beobachtung von Trends bei Benutzern erhalten, wenn Sie das Tool je nach Ihren geschäftlichen Anforderungen regelmäßig verwenden.

Die Parameter für das Skript E2K7_IndexRebuildAnalyzer.ps1 sowie Anwendungsbeispiele können Sie abrufen, indem Sie den -Help-Parameter in der PowerShell-Sitzung übergeben, bevor Sie das Skript ausführen.

In der folgenden Tabelle werden die einzelnen Parameter kurz beschrieben:

Header für Datenbankmetriken

Vor der Neuerstellung

Wie oben bereits beschrieben, wird der "Ausführungsmodus" des Skripts durch das Vorhandensein oder Fehlen des Schalters -PostRebuild bestimmt. Sollen Metriken vor der Neuerstellung gewonnen werden, verwenden Sie den Schalter -PostRebuild nicht. Wird das Skript im Modus vor der Neuerstellung instanziiert, werden die folgenden Header mit den zugehörigen Metriken angezeigt:

Nach der Neuerstellung (Schalter -PostRebuild verwenden)

Wenn Sie den Schalter -PostRebuild verwenden, versucht IndexRebuildAnalyzer, Durchsatzmetriken für Neuerstellungsvorgänge für Inhaltsindizes zu berechnen. Dazu analysiert das Skript das Anwendungsereignisprotokoll, um sowohl den Startzeitpunkt (angegeben durch Ereignis-ID 109) und den Fertigstellungszeitpunkt der Neuerstellung (angegeben durch Ereignis-ID 110) für jede Postfachdatenbank auf dem Postfachserver zu beziehen. Damit Metriken nach der Neuerstellung fehlerfrei berechnet werden, muss das vollständige Ereignis-ID-Paar in der Ereignisanzeige für jede Postfachdatenbank vorhanden sein, deren zugehöriger Inhaltsindex zurückgesetzt wurde. Wenn das Ereignis-ID-Paar nicht vorhanden ist, kann das Skript die Statistik nicht berechnen. In solchen Fällen wird die Zeichenfolge "NoEventsFound" zurückgegeben. Wenn diese Zeichenfolge zurückgegeben wird, hat dies meist einen der folgenden Gründe:

• Der Inhaltsindex-Neuerstellungsvorgang für eine gegebene Gruppe von Datenbanken ist nicht abgeschlossen worden.
• Das Anwendungsereignisprotokollwurde umgebrochen oder geleert. (Die bewährte Methode hierfür besteht darin, den Wert für die maximale Protokollgröße auf den höchstmöglichen Wert zu setzen.)
• Für die Postfachdatenbanken, für die NoEventsFound gemeldet wird, wurden die Inhaltsindizes in letzter Zeit nicht zurückgesetzt (daher das Fehlen des Ereignis-ID-Paars im Ereignisprotokoll). Durch Verwenden der Option -CSVFile und Excel können diese Zeichenfolgen leicht aus dem Ergebnissatz herausgefiltert werden. In Schritt 5 des Frameworks erkläre ich die Filterung und gebe Beispiele dafür.

Alle Header und Metriken "vor der Neuerstellung" werden auch berechnet, wenn der Schalter -PostRebuild für die Skriptausführung übergeben wird. Bei Verwendung des Schalters -PostRebuild werden folgende Header und Metriken hinzugefügt:

Schlussbemerkung

Sie können das Exchange 2007-Skript für die Analyse der Inhaltsindex-Neuerstellung hier herunterladen.

In Teil 2 dieser Artikelreihe erkläre ich das Search Rebuild Framework. Teil 3 enthält eine Beschreibung der bisher bei Microsoft beobachteten Durchschnittswerte.

Eric Norberg
Service Engineer
Office 365

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