Bei einer Migration von Exchange Server 2016 zu Exchange Server 2019 kam es in einer größeren Exchange Server Umgebung zu einem spannenden Phänomen.
Die Nachrichtenzustellung für Empfänger einer bestimmten Datenbank war verzögert. Auf allen Mitgliedsservern der DAG wuchs die Warteschlange für die Postfachzustellung in Postächer dieser Datenbank an. Der protokollierte Fehler war:
432 4.3.2 STOREDRV.Deliver; dynamic mailbox database throttling limit exceeded
Diese Fehlermeldung deutet recht schwammig darauf hin, dass irgendein Problem mit der Datenbank selbst besteht und es zu einem Throttling kommt, welches die Zustellung von Nachrichten in die Postfächer unterbindet.
Aber welche Komponente war nun betroffen? Die Fehlermeldung erwähnt STOREDRV.Deliver. Aber was ist das und wo ist die Komponente platziert?
Das folgende Diagramm zeigt den internen Nachrichtenfluss eines Exchange Servers mit Protokollen der einzelnen Komponenten.
(Quelle: Microsoft)
Die Nachrichtenwarteschlange ist Teil des Transport Service. Die Zustellung an den Mailbox Transport Delivery Service schlägt fehl, weil dieser keine weiteren Nachrichten für die direkte Zustellung per RPC an die betroffene Datenbank annahm. Die Fehlermeldung, die wir in der Warteschlange gesehen haben, war also eine Antwort der SMTP Receive Komponente als Reaktion auf ein Problem der Mailbox Delivery Agents.
Auch die Transportdienste der anderen Exchange Server konnten keine Nachrichten an den Mailbox Transport Delivery Service für die betroffene Datenbank mehr zustellen. Die Gesamtzahl der Nachrichten in den Warteschlangen aller Server war zwischenzeitlich auf mehr als 1.000 Nachrichten angewachsen. Der Druck, das Problem zu lösen, wuchs.
Es war klar, dass es ein Problem zwischen dem Store Driver Deliver und der Datenbank gab. Aber welches?
Der erste und einfachste Ansatz zur Identifikation des Problems war ein schneller Blick in den Performance Monitor des Servers, auf dem die aktive Kopie der betroffenen Postfachdatenbank eingebunden war. Und dort zeigte sich ein erschreckendes Bild.
Die Disk I/O Zeiten für den Dateizugriff der Exchange-Datenlaufwerke lagen zwischen 1.500ms und 2.500ms. Der Höchstwert erreichte einen fünfstellingen Millisekundenwert.
Der folgendes Screenshot is exemplarisch für die Gesamtsituation auf dem Server.
Bei den Exchange Server Systemen handelte es sich um physische Server mit direkt angebundenen (DAS) JBOD-Datenlaufwerken.
Es war aber weiter unklar, was der Auslöser der Situation war. Wir mussten mit der Analyse fortfahren.
Die Datenbank enthielt ~2.500 Postfächer, die auch aktiv von Outlook Clients verwendet wurden, bei einer Datenbankgröße von ~2TB. Ein großer Teil dieser Postfächer war Teil eines Migrationsbatches zur Verschiebung von Postfächern zu Exchange Server 2019. Man kann einfach sagen, dass eine zu zu große Datenbank, mit zu vielen Postfächern, zu viel zu tun hatte.
Als erste Maßnahme wurden die laufenden Migrationsbatche angehalten. Es hat natürlich ein wenig gedauert, bis die Batche und die einzelnen Moves wirklich gestoppt waren. Aber es zeigte sich, dass langsam aber sicher Bewegung in die Warteschlagen kam.
Es blieb nur eins: Warten.
Eine Beruhigung der Situation trat nach etwas mehr als zwei Stunden ein. So lange mussten sich die Anwender mit einer Zustellung der Nachrichten in ihr Postfach gedulden. Um eine Wiederholung dieser Situation zu vermeiden, wurde anschließend damit begonnen, die Anzahl der Postfächer in der betroffenen Datenbank durch Verschieben in andere Datenbanken zu verringern.
Was man nicht machen sollte
Wenn man nach der o.g. Fehlermeldung im Internet nach einer Lösung sucht, findet man einige Artikel, die eine Anpassung der Konfigurationsdatei des Mailbox Transport Delivery Service vorschlagen. Zum einen wird eine Anpassung der Thread Anzahl als Lösung angepriesen, zum andere eine Deaktivierung des Throttling. Beides sind keine Lösung, sondern führen nur zu einer unkontrollierten Überlastung des Servers.
Was man machen sollte
Die Überwachung von Exchange Server Systemen hilft. Zumindest, wenn man sie richtig konfiguriert und ihr auch Aufmerksamkeit schenkt. Eine Exchange Server Organisation benötigt sowohl ein System-Monitoring, um die Betriebsparameter des Betriebssystems und der Applikation, wir z.B. Disk I/O oder Warteschlangengröße, zu permanent zu überwachen. Ebenso benötigt man ein Applikations-Monitoring, das in der Lage ist, Client-Aktivitäten auszuführen. Nur so kann man sicherstellen, dass man Client-Probleme feststellt, obwohl augenscheinlich alle Systemparameter normal sind. Die Unterschiede zwischen beiden Monitoring-Varianten haben ich in einem Blogartikel zusammengefasst.
Links
Viel Spaß mit Exchange Server.
