Bei einer Exchange 2016 zu Exchange 2019 Migration konnten keine Postfächer in die neuen Exchange 2019 Datenbanken verschoben werden. Die MoveRequests blieben bei 0% hängen und zeigten den Fehler StalledDueToSource_DiskLatency:
Egal wie groß oder klein das Postfach war: Kein Postfach konnte verschoben werden. Direkt nach dem Erstellen des MoveRequests, wurde der Fehler StalledDueToSource_DiskLatency angezeigt. Auch nach längerer Wartezeit ändere sich der Status nicht. Der folgende Befehl lieferte einen Hinweis, was die Ursache des Problems sein könnte:
Get-MoveRequest | Get-MoveRequestStatistics -IncludeReport -Diagnostic | fl
Der Fehlerbericht deutet auf ein Problem mit dem Storage hin und zeigt liefert auch direkt das entsprechende Volume, welches eine zu hohe Latenz aufweist:
Bei dem Volume aus dem Fehlerbericht handelt es sich um das Volume welches die Datenbank speichert:
Ich habe daraufhin die Leistungswerte des Volumes (Windows Performance Counter, vmware Performance Counter, Storage Werte) untersucht, konnte aber kein Problem feststellen. Bei diesem Exchange Server handelte es sich um eine vmware VM mit ausreichend welche auf einen dedizierten Datastore gespeichert wird. Der vmware Datastore liegt auf einem leistungsstarken Pure All-Flash Array. Alle Latenzen die ich finden konnte, vom Storage bis zur VM, waren unauffällig und lieferten Werte von unter 1ms.
Die Fehlersuche war hier ziemlich frustrierend, alle Performance Counter lieferten optimale Werte, es gab keinerlei Hinweise auf ein Leistungsproblem. Auch das Verschieben der VM auf andere Datastores von einem anderen Storage Array brachte nichts.
Aufgrund einer älteren Storage Migration des Exchange Servers gab es allerdings eine Unschönheit: Die Volumes für die Datenbanken waren über mehrere Disks verteilt (Spanned Volumes). In diesem Screenshot ist dies schön zu sehen, ein Volume erstreckt sich über mehrere Disks:
Wie bereits erwähnt, waren auch die Performance Counter jeder einzelnen Disk unauffällig, jedoch war dies der letzte Strohhalm. Ich habe also die Spanned Disks aufgelöst und ein großes Simple Volume für die Datenbank konfiguriert. Glücklicherweise war auf dem Storage genug Speicher frei und Dank Virtualisierung war der Umzug der Datenbank schnell erledigt. Eigentlich sind Spanned Volumes und Exchange Server auch nicht weiter ungewöhnlich. Bei einem physikalischem Server mit einem JBOD würde man hier ähnlich vorgehen.
Nachdem das Volume der Datenbank wieder auf einer großes Disk mit einem Volume gespeichert wurde, war der Fehler StalledDueToSource_DiskLatency verschwunden. Alle Postfächer ließen sich ohne Probleme migrieren. Auch für weitere Datenbanken welche auf Spanned Volumes gespeichert wurden, klappte nach der Umstellung zu einer großes Disk das Verschieben der Postfächer. Der Fehler StalledDueToSource_DiskLatency ist danach nicht wieder aufgetreten.
Die große einzelne Disk für die Datenbank habe ich übrigens auf dem gleichen Storage und dem gleichen vmware Datastore erstellt. Letztlich konnte ich den Grund für den Fehler StalledDueToSource_DiskLatency nicht feststellen, scheinbar hängt es aber mit den Spanned Volumes zusammen.
Vielleicht hilft dies ja auch anderen weiter, falls ihr den Fehler auch schon mal hattet, schreibt es gern in die Kommentare.
Wir hatten gerade ein ähnliches Phänomen in einer kleineren Umgebung.
ca. 20 Postfächer werden in PST exportiert, 19 laufen, 1 bringt die Meldung „StalledDueToSource_DiskLatency“. Während der Recherche (bin auch hier gelandet) hat sich das Problem aber selbständig bereinigt und er ist ohne weiteres Zutun auf „CopyingMessages“ gesprungen.
Bei uns hat also das reine Abwarten geholfen!
Interessant zu lesen und schön, dass du es gelöst hast! Aber ich denke, das ist schon eine ziemliche Seltenheit.
Der im Screenshot zu sehende Wust aus Disks und Volumes halte ich schon für sehr ungewöhnlich. Bei meinen selbst aufgebauten und betreuten Umgebungen nutze ich keine Spanned Volumes und bei neu hinzugekommenen, teils auch sehr wilden Installationen, ist mir so ein Fall auch noch nicht untergekommen.
Bei mir habe ich einen neuen Exchange2019 aufgesetzt, die ersten 50 Postfächer liessen sich migrieren, danach nichts mehr. Alle Werte unauffällig, das Volume für die DB ist 2TB groß und in einer HP MSA befindlich. Also 1 Volume, und StalledDueToTarget_DiskLatency, ganz gleich wie groß die Postfächer sind…..