Verwalteter Speicher in Exchange Server
Der verwaltete Speicher ist der Name für die Informationsspeicherprozesse (auch als Store bezeichnet) in Exchange Server 2016 und Exchange Server 2019. Der verwaltete Speicher wurde in Exchange Server 2013 eingeführt und verwendet ein Controller-/Workerprozessmodell, das Speicherprozessisolation und ein schnelleres Datenbankfailover ermöglicht. Der verwaltete Speicher verwendet auch einen Zwischenspeichermechanismus für statische Datenbanken, der den dynamischen Pufferalgorithmus in früheren Versionen von Exchange ersetzt.
Das multiprozessbasierte Modell, das vom verwalteten Speicher verwendet wird, besteht aus den folgenden Prozessen auf dem Postfachserver:
Ein einzelner Speicherdienstcontrollerprozess für den gesamten Exchange-Server (Microsoft.Exchange.Store.Service.exe, auch als MSExchangeIS bezeichnet).
Ein Arbeitsprozess für jede eingebundene Datenbank (Microsoft.Exchange.Store.Worker.exe). 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 beispielsweise 40 Postfachdatenbanken auf einem Postfachserver eingebunden haben, werden 41 Prozesse für den verwalteten Speicher ausgeführt: einen für jede Datenbank und einen für den Speicherdienstprozesscontroller. 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 auf dem Server.
Der verwaltete Speicher ist außerdem fest in den Microsoft Exchange-Replikationsdienst (MSExchangeRepl.exe) und in Active Manager integriert. Controllerprozess, Workerprozesse und Replikationsdienst arbeiten zusammen, um eine höhere Verfügbarkeit und Zuverlässigkeit zu gewährleisten, wie in der folgenden Liste beschrieben:
Microsoft Exchange-Replikationsdienstprozess (MSExchangeRepl.exe):
Verantwortlich für die Ausgabe von Einbindungs- und Aufhebungsvorgängen im Store.
Initiiert eine Wiederherstellungsaktion für Speicher- oder Datenbankfehler, die vom Store, der Extensible Storage Engine (ESE) und den Antworten auf die verwaltete Verfügbarkeit gemeldet werden.
Erkennt unerwartete Datenbankfehler.
Stellt die Verwaltungsschnittstelle für Verwaltungsaufgaben bereit.
Speicherdienstprozess/-controller (Microsoft.Exchange.Store.Service.exe):
Verwaltet die Lebensdauer der einzelnen Arbeitsprozess basierend auf den Bereitstellungs- und Aufhebungsvorgängen, die vom Replikationsdienst empfangen wurden.
Verarbeitet eingehende Anforderungen vom Windows-Dienststeuerungs-Manager.
Protokolliert Fehlerelemente, wenn Probleme beim Speichern des Arbeitsprozesses erkannt wurden (z. B. Hängen oder unerwartetes Beenden).
Beendet Speicher-Workerprozesse im Antwortfailoverereignis.
Speicherarbeitsprozess (Microsoft.Exchange.Store.Worker.exe)
Verantwortlich für die Ausführung von RPC-Vorgängen für Postfächer in einer Datenbank.
DER RPC-Endpunkt instance innerhalb des Arbeitsprozesses ist die Datenbank-GUID.
Stellt den Datenbankcache für eine Datenbank bereit.
Zwischenspeicherungsalgorithmus für statische Datenbanken
Der verwaltete Speicher verwendet einen einfachen und einfachen Algorithmus zum Bestimmen des Datenbankcaches im Vergleich zur dynamischen Pufferzuordnung , die in den vorherigen Versionen von Exchange verwendet wurde. Der für jeden Datenbankcache (d. h. jeden Speicherarbeitsprozess) zugeordnete Arbeitsspeicher basiert auf der Anzahl lokaler Datenbankkopien und dem konfigurierten Wert des Parameters MaximumActiveDatabases im Cmdlet Set-MailboxServer (der Standardwert ist $null oder leer). Wenn der Wert von MaximumActiveDatabases größer als die Anzahl der aktuellen Datenbankkopien ist, basiert die Cacheberechnung auf der Anzahl der Datenbankkopien.
Der statische Algorithmus ordnet Arbeitsspeicher für den ESE-Cache jedes Speicherarbeitsprozesses basierend auf der Menge des physischen RAM zu, der auf dem Server installiert ist. Dies wird auf das maximale Cacheziel der Datenbank verwiesen. 25 % des gesamten Serverarbeitsspeichers werden dem ESE-Cache zugeordnet und als Servercachegrößenziel bezeichnet.
Hinweis
Sie können das Servercachegrößenziel und damit die Dem Speicher für ESE-Cache zugeordnete Arbeitsspeichermenge überschreiben msExchESEParamCacheSizeMax , indem Sie das -Attribut des InformationStore-Objekts in Active Directory verwenden (der konfigurierte Wert ist die Anzahl von 32-KB-Seiten, die allen Speicherprozessen zugeordnet werden sollen).
Eine statische Menge dieses Caches wird aktiven und passiven Kopien zugewiesen. Dem Speicherarbeitsprozess wird das maximale Cacheziel nur bei der Wartung einer aktiven Datenbankkopie zugeordnet. 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 neue Datenbanken ein kleineres Cachegrößeziel als Datenbanken, die vor dem letzten Dienststart vorhanden waren. In diesem Szenario wird die Summe der Datenbankcachegrößenziele wahrscheinlich das Servercachegrößenziel überschreiten, bis MSExchangeIS neu gestartet wird.
Beispiel für Datenbankcacheberechnungen
Hier finden Sie Beispielberechnungen für die Datenbankzwischenspeicherung, die auf dem Arbeitsspeicher und der Datenbankkonfiguration eines Postfachservers basieren.
Beispiel 1
Postfachserverkonfiguration:
48 GB Arbeitsspeicher
Zwei aktive Datenbanken und zwei passive Datenbanken
Parameter "MaximumActiveDatabases ": nicht konfiguriert
Die Größe des Datenbankcaches beträgt 3 GB für jeden aktiven Datenbankkopierarbeitsprozess und 0,6 GB für jeden passiven Datenbankkopierarbeitsprozess. So werden diese Werte berechnet:
Servercachegrößenziel: 25 % der Arbeitsspeichermenge: 48 GB * 0,25 = 12 GB.
Maximales Datenbankcacheziel: Dividieren Sie das Servercachegrößenziel durch die Gesamtzahl der aktiven und passiven Datenbanken: 12 GB/4 Datenbanken = 3 GB.
Für passive Datenbankkopien verwendeter Arbeitsspeicher: 20 % des maximalen Datenbankcacheziels: 3 GB * 0,20 = 0,6 GB.
Von den 12 GB Arbeitsspeicher, die dem Servercachegrößenziel zugewiesen sind:
7,2 GB werden von Datenbank-Workerprozessen verwendet.
4,8 GB werden vom Informationsspeicher für die beiden passiven Datenbankkopien reserviert, falls sie zu aktiven Kopien werden. In diesem Fall verwenden sie ihr maximales Cacheziel von 3 GB.
Beispiel 2
Postfachserverkonfiguration:
48 GB Arbeitsspeicher
Zwei aktive Datenbanken und zwei passive Datenbanken
MaximumActiveDatabases-Parameter : 2
Die Größe des Datenbankcaches beträgt 5 GB für jeden aktiven Datenbankkopier-Workerprozess und 0,2 GB für jeden passiven Datenbankkopierarbeitsprozess. So werden diese Werte berechnet:
Servercachegrößenziel: 25 % der Arbeitsspeichermenge: 48 GB * 0,25 = 12 GB.
Maximales Datenbankcacheziel: Dividieren Sie das Servercachegrößenziel durch die Summe von:
Die Anzahl der aktiven Datenbanken
20 % der Anzahl passiver Datenbanken
12 GB / (2A + (2P * 0,20)) = 5 GB
Für passive Datenbankkopien verwendete Arbeitsspeicher: 20 % des maximalen Datenbankcacheziels: 5 GB * 0,20 = 1 GB.
Aus den 12 GB Arbeitsspeicher, die dem Servercachegrößenziel zugewiesen sind:
12 GB werden von Datenbank-Workerprozessen verwendet
Für die beiden passiven Datenbankkopien wird kein Arbeitsspeicher vom Informationsspeicher reserviert, da sie nicht zu aktiven Kopien werden können (MaximumActiveDatabases ist mit dem Wert 2 konfiguriert, und es sind bereits zwei aktive Datenbankkopien auf dem Server vorhanden).