Store-Prozess von Exchange 2013 braucht einen Neustart

Wer das kumulative Update 1 von Exchange Server 2013 im Einsatz hat, der wird feststellen, dass das System einen dazu auffordert, den Informationsspeicher-Dienst (Information Store Service) neu zu starten. Das ist immer dann der Fall, wenn der Administrator im Informationsspeicher eine neue Datenbank hinzufügt. Tony Redmond erklärt warum das nötig ist.

Wer das kumulative Update 1 (CU 1, wurde im April 2013 freigegeben) von Exchange Server 2013 im Einsatz hat, der wird feststellen, dass das System einen dazu auffordert, den Informationsspeicher-Dienst (Information Store Service) neu zu starten – und zwar immer dann, wenn man eine neue Datenbank im Informationsspeicher hinzufügt. Dieses Hinzufügen kann der Administrator entweder mit dem EAC (Exchange Administration Center;es ist über einen Web-Browser zugängig), oder über die Exchange Management Shell (EMS) ausgelöst haben.

Bereits in der RTM-Version (Ready to Manufactoring, also die „Erstausgabe von Exchange Server2013“) bestand diese Anforderung. Doch die zugehörigen Verwaltungs-Tools haben nicht den Hinweis ausgegeben, dass man in diesem beschriebenen Fall einen Neustart des Informationsspeicher Dienstes ausführen muss. Allerdings stellt sich die Frage, warum dieser Klimmzug nötig geworden ist.

Monolithischer Store-Prozess wurde aufgebrochen

Bei Exchange Server 2013 wurde der alte, monolithische „Store“-Prozess neu programmiert, so dass nun ein als „Managed Store“ bezeichneter Ansatz zum Einsatz kommt. Dabei wird im Vergleich zu Exchange 2007 oder 2010 ein komplett anderes Modell der Speicherverwaltung verfolgt: Auf einem Exchange 2013-Postfachserver gibt es nun einen „Control Process“ für den Informationsspeicher und einen „Store Worker Process“ für jede Datenbank im Informationsspeicher – egal ob es sich um eine aktive oder eine passive Datenbank im Information Store handelt, die auf diesem Server gemountet ist.

Beim Erzwingen des Neustarts eines kritischen Dienstes handelt es sich um einen Seiteneffekt, der im neuen Speicherverwaltungsmodell begründet ist. Auf den ersten Blick erscheint das sehr merkwürdig. Doch dazu muss man sich vor Augen führen, dass der Store-Prozess nur die Menge des Speichers beim Anlaufen bestimmt, den er verwendet, um alle Datenbanken auf einem Server (die maximale Größe des ESE Cachespeichers) zu verwalten. Das passiert immer nur dann, wenn der Server generell hochfährt, oder wenn man einen Neustart des Informationsspeicher-Dienstes erzwingt.

Beim alten Schema handelt es sich um die DBA (Dynamic Buffer Allocation). Dieser Ansatz schnappt sich so viel Speicher wie auf dem Server verfügbar ist und verwendet diesen Speicherbereich, um die Store-Daten zwischenzuspeichern (also zu cachen). Die Bezeichnung „Dynamic“ verdient sich dieser Ansatz, da der Store-Prozess Speicher an andere Prozesse zurückgibt, wenn die mehr Speicher benötigen. Doch dadurch entsteht auch der Eindruck, dass Exchange sehr viel Arbeitsspeicher an sich reißt – vor allem der Store-Prozess. Doch das DBA-Konzept arbeitet recht gut seit seiner Einführung bei Exchange 2003.

Mit der Aufteilung des monolithischen Store-Ansatzes in einen Control- und einen Worker-Prozess (pro Datenbank im Informationsspeicher) bei Exchange Server 2013 musste der alte Ansatz geändert werden. Exchange 2013 bestimmt dabei erstmal, wie viel Speicher es für den ESE-Cache verwenden soll (die Regel lautet 25 Prozent des gesamten verfügbaren RAM-Bereichs) und teilt dann diesen Speicherbreich unter den Worker-Prozessen auf. Dabei bekommen die aktiven Datenbanken logischerweise mehr Speicher zugewiesen als die passiven – sie haben ja auch mehr Arbeit zu verrichten.

Natürlich hängt das neue Schema zur Arbeitsspeicherverteilung davon ab, dass das System genau weiß, wie viele Worker-Prozesse aktiv sind. Beim Ändern dieses Parameters – also beim Erstellen einer neuen Datenbank – versucht der Store-Prozess nicht, seinen ESE-Cache neu zu berechnen oder Arbeitsspeicher seinen Datenbanken neu zuzuordnen. Das bedeutet allerdings, dass das Caching nicht so optimal läuft, wie es möglich wäre – solange man nicht den Store-prozess neu startet und dann der Arbeitsspeicher wieder bestmöglich verteilt wird.

Sicher wäre es besser gelöst, wenn die Speicherzuteilung dynamisch verwaltet würde. Doch zum einen ist das Hinzufügen oder das Entfernen einer Datenbank kein Vorgang, der allzu häufig in der Lebensdauer eines Servers stattfindet. Und zum anderen ist das Speicherverwaltungsschema bei Exchange Server 2013 recht neu. Daher erscheint es durchaus wahrscheinlich, dass in einer künftigen Version diese Aktion automatisiert verläuft.

Entfernen der Datenbank ohne Konsequenzen für Store-Prozess

Interessanterweise kommt der Dialog zum Neustart des Informationsspeicher-Dienstes nicht zum Vorschein, wenn eine Datenbank aus dem Informationsspeicher entfernt wird. Das könnte sein, weil die auf dem Server verbleibenden Datenbanken bereits über einen passenden Cache und Speicherausbau verfügen. Und die frei gewordenen Speicherressourcen von Windows auf andere Prozesse verteilt werden.

Ein weiterer Blickwinkel auf diese Situation kommt ins Spiel, wenn man sich überlegt, was nach dem Hinzufügen einer Datenbank im Informationsspeicher passiert: Üblicherweise wird man die Arbeitslast verteilen und dazu einige Postfächer in die neu angelegte Datenbank verschieben. In diesem Fall ist das Zuweisen von genügend Cache an die neue Datenbank sehr wichtig.

Alles eine Frage der Gewöhnung

Daher sollte man den Administrator in dieser Situation unbedingt davon in Kenntnis setzen, dass er den Informationsspeicher-Prozess neu starten soll.
Im Vergleich dazu ist das Neuberechnen der Cache-Zuteilung nach dem Entfernen einer Datenbank nicht so wichtig. Denn alle Postfächer wurden ja bereits aus der Datenbank entfernt – sonst kann sie gar nicht gelöscht werden. In beiden Fällen – dem Hinzufügen oder dem Entfernen einer Datenbank – handelt es sich nicht um eine recht häufige Aktion, wenn ein Server erst einmal effektiv im Einsatz ist. Daher muss man sich auch nicht sonderlich um den Neustart des Speicherinformations-Dienstes sorgen.

Die Gewöhnung an das Verhalten von neuer Software und wie man die einzelnen Applikationen am besten nutzen kann, ist oftmals ein langwieriger Prozess. Für einige Aufgaben bedeutet das einen Bruch mit den bisherigen Traditionen oder Vorgehensweisen – doch meist ergibt sich daraus für den Betrieb der Anwendung doch ein deutlicher Vorteil, so dass ein Umdenken sich letztendlich auch auszahlt.

Tony Redmond