Verwalteter Speicher

Gilt für: Exchange Server 2013

Alle vorherigen Exchange Server-Versionen, von Exchange Server 4.0 bis Exchange Server 2010, haben die Ausführung einer einzelnen Instanz des Prozesses des Microsoft Exchange-Informationsspeichers (Store.exe) in der Serverrolle "Mailbox" unterstützt. Diese einzelne Speicherinstanz hostet alle Datenbanken auf diesem Server: aktive, passive, verzögerte und wiederhergestellte. In den vorherigen Exchange-Architekturen gibt es nur wenig Isolation zwischen den verschiedenen Datenbanken, die auf einem Postfachserver gehostet werden. Ein Problem mit einer einzelnen Postfachdatenbank hat das Potenzial, sich auf alle anderen Datenbanken auszuwirken, und Ausfälle aufgrund der Beschädigung einer Datenbank können den Dienst für alle Benutzer, deren Datenbanken auf diesem Server gehostet werden, beeinträchtigen.

Eine weitere Herausforderung bei einem einzelnen Store instance in früheren Versionen von Exchange besteht darin, dass die Extensible Storage Engine (ESE) gut auf 8 bis 12 Prozessorkerne skaliert wird, aber über diesen Schwellenwert hinaus probleme bei der prozessorübergreifenden Kommunikation und Cachesynchronisierung zu einer negativen Skalierung führen. Angesichts der heutigen größeren Server mit mehr als 16 Kernsystemen würde dies bedeuten, dass die administrative Herausforderung besteht, die Affinität von 8 bis 12 Kernen für ESE zu verwalten und die anderen Kerne für Prozesse ohne Store zu verwenden (z. B. Assistenten, Search Foundation, verwaltete Verfügbarkeit usw.). Außerdem waren die Aufwärtsskalierungsoptionen für den Informationsspeicherprozess in der bisherigen Architektur beschränkt.

Der Prozess Store.exe hat im Laufe der Jahre, in denen sich Exchange Server selbst entwickelt hat, auch eine bemerkenswerte Entwicklung durchgemacht, aber als einzelner Prozess ist seine Skalierbarkeit begrenzt, und er stellt auch eine einzelne Fehlerquelle dar. Aufgrund dieser Begrenzungen ist Store.exe in Exchange 2013 nicht mehr vorhanden und wird durch den verwalteten Speicher ersetzt.

Verwalteter Speicher

Der verwaltete Speicher ist der Name für die Prozesse des Informationsspeichers (auch als "Store" bezeichnet) in Exchange Server 2013. Der verwaltete Speicher verwendet ein Controller-/Workerprozessmodell, das Speicherprozessisolation und schnelleres Datenbankfailover ermöglicht. Der verwaltete Speicher enthält auch einen neuen Zwischenspeichermechanismus für statische Datenbanken, der den dynamischen Pufferalgorithmus in früheren Versionen von Exchange Server ersetzt. Im multiprozessbasierten Modell, das vom verwalteten Speicher verwendet wird, gibt es einen einzelnen Speicherdienstcontrollerprozess (in diesem Fall Microsoft.Exchange.Store.Service.exe auch als MSExchangeIS bezeichnet) und einen Workerprozess (in diesem Fall Microsoft.Exchange.Store.Worker.exe) für jede eingebundene Datenbank. Wenn eine Datenbank eingebunden wird, wird ein neuer Arbeitsprozess instanziiert, der nur diese Datenbank verarbeitet. Wenn die Bereitstellung einer Datenbank aufgehoben wird, wird der Arbeitsprozess für diese Datenbank beendet.

Wenn Sie z. B. 40 Datenbanken auf einem Server bereitgestellt haben, laufen 41 Prozesse für den verwalteten Speicher, einer für jede Datenbank und einer für den Speicherdienst-Steuerungsprozess.

Der Speicherdienst-Prozesscontroller ist schlank und zuverlässig, aber wenn er stirbt oder beendet wird, werden alle seine Arbeitsprozesse absterben (sie erkennen, dass der Dienstcontrollerprozess nicht mehr vorhanden ist und beendet wird). Der Steuerungsprozess für den Speicherdienst überwacht den korrekten Ablauf aller Speicherarbeitsprozesse auf dem Server. Eine erzwungene oder unerwartete Beendigung der Microsoft.Exchange.Store.Service.exe führt zu einem sofortigen Failover aller aktiven Datenbankkopien. Der verwaltete Speicher ist außerdem fest in den Microsoft Exchange-Replikationsdienst (MSExchangeRepl.exe) und in Active Manager integriert. Der Steuerungsprozess, die Arbeitsprozesse und der Replikationsdienst arbeiten zusammen, um Ihnen eine höhere Verfügbarkeit und Zuverlässigkeit zu bieten.

• Prozess des Microsoft Exchange-Standortreplikationsdiensts (MSExchangeRepl.exe)

  • Verantwortlich für die Ausgabe der Bereitstellungs- und Bereitstellungsaufhebungsvorgänge im Speicher

  • Initiiert Wiederherstellungsaktionen nach vom Informationsspeicher, von Extensible Storage Engine (ESE) oder vom Antwortdienst für verwaltete Verfügbarkeit gemeldeten Speicherungs oder Datenbankausfällen

  • Erkennt unerwartete Datenbankfehler

  • Stellt die administrative Schnittstelle für Management-Aufgaben bereit

• Informationsspeicher-Prozess/Dienstcontroller (Microsoft.Exchange.Store.Service.exe)

  • Verwaltet die Dauer jedes Arbeitsprozesses auf Grundlage der vom Replikationsdienst gemeldeten Bereitstellungs- und Bereitstellungsaufhebungsvorgänge

  • Verarbeitet eingehende Anforderungen vom Windows-Dienststeuerungs-Manager

  • Protokolliert Fehlerelemente, wenn Probleme in Speicherarbeitsprozessen erkannt wurden (z. B. Hängen oder unerwarteter Abbruch)

  • Beendet die Speicherarbeitsprozesse als Reaktion auf Failover-Ereignisse

• Speicherarbeitsprozess (Microsoft.Exchange.Store.Worker.exe)

  • Verantwortlich für die Ausführung von RPC-Vorgängen für Postfächer in einer Datenbank

  • RPC-Endpunkt-Instanz im Arbeitsprozess ist die Datenbank-GUID

  • Stellt den Datenbankcache für eine Datenbank bereit

Statischer Datenbankcaching-Algorithmus

Der in Exchange Server 5.5 eingeführte und vom Informationsspeicher in Exchange 2000 Server, Exchange Server 2003, Exchange Server 2007 und Exchange Server 2010 verwendete Datenbankzwischenspeicherungsalgorithmus ist ebenfalls nicht mehr in Exchange 2013 enthalten. Exchange 2013 verwendet einen einfachen und unkomplizierten Algorithmus zum Bestimmen des Datenbankcaches. Der verwaltete Speicher ordnet den Cache bei einem Failover nicht mehr dynamisch zwischen Datenbanken neu zu, was die interne Cacheverwaltung erheblich vereinfacht. Stattdessen basiert der für jeden Datenbankcache zugeordnete Arbeitsspeicher (z. B. jeder Speicherarbeitsprozess) auf der Anzahl der lokalen Datenbankkopien und dem Wert von MaximumActiveDatabases( sofern konfiguriert). Wenn der Wert von MaximumActiveDatabases größer als die Anzahl der aktuellen Datenbankkopien ist, basiert die Cacheberechnung auf der Anzahl der Datenbankkopien.

Der von Exchange 2013 verwendete statische Algorithmus weist Speicher für den ESE-Cache jedes Speicherarbeitsprozesses auf Grundlage des physischen RAM-Speichers zu. Dieser Arbeitsspeicher wird als max. Cacheziel einer Datenbank bezeichnet. 25% des gesamten Serverspeichers wird dem ESE-Cache zugewiesen. Dieser Anteil des Arbeitsspeichers wird als Servercachegrößenziel bezeichnet.

Eine statische Menge dieses Caches wird aktiven und passiven Kopien zugewiesen. Dem Speicherarbeitsprozess wird das maximale Cache-Ziel nur zugewiesen, wenn eine aktive Datenbankkopie verarbeitet wird. Passiven Datenbankkopien wird 20 Prozent des maximalen Cache-Ziels zugewiesen. Der Rest wird vom Informationsspeicher reserviert und dem Arbeitsprozess zugewiesen, wenn die Datenbank vom passiven in den aktiven Zustand wechselt.

Das maximale Cache-Ziel wird nur beim Start des Informationsspeichers berechnet. Deshalb müssen Sie, wenn Sie Datenbanken oder Datenbankkopien hinzufügen oder entfernen, den Speichersteuerungsdienst (MSExchangeIS) neu starten, damit der Cache entsprechend angepasst werden kann. Wenn der Dienst nicht neu gestartet wird, haben neu erstellte Datenbanken ein kleineres Cachegrößeziel als Datenbanken, die vor dem Start des Diensts erstellt wurden. in diesem Fall überschreitet die Summe der Datenbankcache-Größenziele wahrscheinlich das Servercache-Größenziel, bis MSExchangeIS neu gestartet wird.

Beispielberechnungen des Datenbankcaches

Unten finden Sie Beispiele für die Berechnung der Datenbankcachegröße, die auf der Speicher- und Datenbankkonfiguration des Postfachservers beruhen.

Beispiel 1

In diesem Beispiel verfügt der Postfachserver über einen Speicher von 48 GB und hostet zwei aktive und zwei passive Datenbanken. Darüber hinaus ist der Parameter MaximumActiveDatabases nicht konfiguriert. In dieser Konfiguration wird jedem Arbeitsprozess für eine aktive Datenbankkopie ein Datenbankcache von 3 GB zugewiesen, und jeder Arbeitsprozess für eine passive Datenbankkopie erhält 0,6 GB. Hier wird beschrieben, wie diese Werte berechnet wurden.

Multiplizieren Sie den Speicherbetrag mit 25 %, um das Servercache-Größenziel zu erhalten:

48 GB x 25 % = 12 GB

Teilen Sie dann, um das maximale Datenbankcache-Ziel zu erhalten, das Servercache-Größenziel durch die Gesamtzahl der aktiven und passiven Datenbanken:

12 GB / 4 Datenbanken = 3 GB

Um den Speicherbetrag zu bestimmen, der für die passiven Datenbankkopien verwendet wird, multiplizieren Sie das maximale Datenbankcache-Ziel mit 20 %:

3 GB x 20 % = 0,6 GB

Von den 12 GB Speicher, die dem Servercache-Größenziel zugewiesen wurden, werden 7,2 GB in Datenbankarbeitsprozessen belegt, und 4,8 GB werden vom Informationsspeicher für die zwei passiven Datenbankkopien für den Fall reserviert, dass aus diesen aktive Kopien werden. In diesem Fall verwenden sie ihr maximales Cacheziel von 3 GB.

Beispiel 2

In diesem Beispiel hat der Postfachserver ebenfalls 48 GB Speicher und hostet zwei aktive und zwei passive Datenbanken; der Parameter MaximumActiveDatabases ist jedoch mit dem Wert 2 konfiguriert. In dieser Konfiguration beträgt die Menge des Datenbankcaches für jeden Arbeitsprozess einer aktiven Datenbankkopie 5 GB und für jeden Arbeitsprozess einer passiven Datenbankkopie 0,2 GB. Hier wird beschrieben, wie diese Werte berechnet wurden.

Multiplizieren Sie den Speicherbetrag mit 25 %, um das Servercache-Größenziel zu erhalten:

48 GB x 25 % = 12 GB

Um das maximale Datenbankcacheziel zu erhalten, dividieren Sie das Servercachegrößenziel durch die Gesamtzahl der aktiven Datenbanken plus die Gesamtzahl der passiven Datenbanken multipliziert mit 20 %:

12 GB / (2A + (2P x 20 %)) = 5 GB

Um den Speicherbetrag zu bestimmen, der für die passiven Datenbankkopien verwendet wird, multiplizieren Sie das maximale Datenbankcache-Ziel mit 20 %:

5 GB x 20 % = 1 GB

Von den 12 GB Arbeitsspeicher, die dem Servercachegrößenziel zugewiesen sind, werden 12 GB von Datenbank-Workerprozessen verwendet, und der Informationsspeicher reserviert keinen Arbeitsspeicher für die beiden passiven Datenbankkopien, da sie in dieser Konfiguration nicht zu aktiven Kopien werden können (da MaximumActiveDatabases mit dem Wert 2 konfiguriert ist, und es sind bereits 2 aktive Datenbankkopien auf dem Server vorhanden.