I/O-Probleme bei virtuellen Exchange-Installationen

Einleitung

Es ist mal wieder Exchange-Zeit! Zwar drängt sich der Eindruck auf, dass ich vor allem mit Microsofts Messaging-Lösung meine Zeit verbringe, aber das liegt nur daran, dass er so viel Angriffsfläche für Bugs und andere Katastrophen bietet.

Die Problemstellung

Ich betreue einige virtuelle Exchange-Installationen von Microsoft Exchange Server 2007 bis Exchange Server 2016, alle davon virtualisiert.

Eine der Exchange 2016-Installationen tanzt dabei aber aus der Reihe. Es ist damit faktisch unmöglich Mailboxen zu verschieben (sowohl zu einem probehalber installiertem 2. Server als auch nach Office 365). Die Fehlermeldungen reklamieren, dass die Festplatte zu beschäftigt sei, um Migrationen durchzuführen.

Das betreffende System hält ungefähr 25 Mailboxen, verfügt über 4 vCPU und 16 GB RAM und ist unter Hyper-V (Server 2016 Standard) virtualisiert. Perfmon auf dem Hypervisor zeigt eine Disk-Queue für die System- und Mailbox-VHDX von 90 respektive 80.
Das virtuelle System erreicht schreibend eine Schreibgeschwindigkeit von nur noch 4,6 MB/s, gemessen mit diskspd

Ein Screenshot, der die Datenträgerwarteschlange der die I/O-Probleme bei virtuellen Exchange-Installationen zeigt
Die Warteschlange der virtuellen Disks des Exchange-Systems. am unteren Rand ganz leicht in Blau zu sehen: Die Warteschlange einer anderen VM auf dem gleichen Hypervisor. 

Weitere Beobachtungen

Laut Microsoft Docs sind 8 GB Arbeitsspeicher die Minimalanforderung zum Betrieb einer Exchange 2016 -Installation in der Postfachrolle, der Server wurde mit 16 GB ausgestattet und es wurden lediglich 62% des Arbeitsspeichers vom System belegt (entsprechend 9,92 GB).

Woher kommen nun die I/O-Probleme bei virtuellen Exchange-Installationen? 

Die Analyse anderer virtueller Systeme auf dem gleichen Hypervisor zeigte, dass weder der Hypervisor selbst ein Problem mit der Datenträgerwarteschlange hat, noch andere virtuelle Maschinen.

Das Dateisystem war zwar zu 12% fragmentiert, und ehrlich gesagt erwartete ich keine Wunderheilung, aber ich wollte es einfach ausschließen:

Ausgabe der Kommandozeile nach defrag.exe
Ergebnis der Defragmentierung im Rahmen der Ursachenforschung

Das Problem musste auf dem Exchange Server zu finden sein.

Lösung: Ja – Ursache: unklar

Da mir in der Vergangenheit das Exchange Management Pack für SCOM 2012R2 durch hardgecodede Limits in Erinnerung geblieben ist, probierte ich einfach einmal, ob die I/O-Probleme bei virtuellen Exchange-Installationen mit (viel) mehr RAM zu lösen sind.

Ich wies der Maschine 48 GB RAM zu – obwohl ja nur 62% von 16 GB verwendet wurden und war erstaunt: Die Maschine belegte nun 19% Arbeitsspeicher (also 9,12 GB) und pendelte sich nach 24 Stunden bei 30% ein – und die Datenträgerwarteschlange ist wieder normal:

Screenshot des Taskmanagers im wiedererlangten Normalzustand
Ansicht des Taskmanagers nach der Lösung des I/O-Problems

Ich vermute tatsächlich ein irgendwo verstecktes, festes Limit – anders ist das Verhalten des Systems kaum zu erklären – wenn jemand etwas genaueres weiß, kann er gerne hier kommentieren.

Schreibe einen Kommentar