Exchange 2013: EventID 15004 (Version Buckets), Mails werden nicht gesendet oder empfangen

Ich habe schon mehrere Anfragen erhalten, die sich um das Thema Back Pressure drehen. Wenn sich Exchange im Back Pressure Zustand befindet, werden Mails nur noch langsam oder gar nicht mehr empfangen oder gesendet.

Häufig wird dann ungefähr die folgende Situation geschildert:

Exchange sendet oder empfängt keine Mails mehr und das Ereignis 15004 wird protokolliert, welches den Hinweis enthält das der Wert für Version Buckets zu hoch ist. Das Problem tritt unter Umständen nur sporadisch auf. Nach einem Neustart der Exchange Dienste oder des Servers können Mails wieder gesendet und empfangen werden, bis irgendwann das Problem wieder auftritt.

Die Ressourcenauslastung ist von Normal auf Hoch gestiegen.

Die folgenden Ressourcen sind überlastet:
Version-Buckets = 8 [Hoch] [Normal=1 Mittel=2 Hoch=3]

Aufgrund von Rückstau wurden die folgenden Komponenten deaktiviert:
Eingehende Nachrichtenübermittlung von Hub-Transport-Servern
Eingehende Nachrichtenübermittlung aus dem Internet
E-Mail-Übermittlung von PICKUP-Verzeichnis
E-Mail-Übermittlung von Wiedergabeverzeichnis
E-Mail-Übermittlung von Postfachserver
E-Mail-Zustellung an Remotedomänen
Inhaltsaggregation
Erneute E-Mail-Übermittlung über die Komponente zur erneuten Nachrichtenübermittlung.
Erneute Nachrichtenübermittlung von der Komponente für Shadow-Redundanz

Kurze Erklärung:

Exchange verarbeitet Mails mittels Batches, Bach Points und Version Buckets. Eine Nachricht mit großem Anhang kann in mehrere Batches aufgeteilt werden, die dann abgearbeitet werden. Version Buckets sind eine Liste mit Transaktionen von Batches die noch nicht in die Transaktionsprotokolle der Warteschlangendatenbank übergeben wurden. Im Prinzip ist es also ein Transaktionsprotokoll im Arbeitsspeicher des Servers.

Das Back Pressure Feature überwacht die Anzahl der Version Buckets und Batches die zu diesem Zeitpunkt nur im Arbeitsspeicher des Servers existieren und greift in den Übermittlungsprozess ein, falls die Werte zu hoch werden.

Die häufigste Ursache:

Die Ursache für zu hohe Version Buckets oder Batch Point Werte sind zu große Mails die der Exchange Server nicht mehr handeln kann. Wird zum Beispiel eine Mail mit einem 50 MB großen Anhang empfangen, die an mehrere Empfänger zugestellt werden soll, können die Werte für Version Buckets und Batch Points in die Höhe schnellen. In diesem Fall greift Back Pressure ein und weist Mails ab um die Last zu senken. Exchange hat dann etwas Zeit um die Änderungen an die Warteschlangen Datenbank zu übergeben.

Problem beheben:

Die wohl einfachste Lösung für das Problem ist, die maximale Größe der Nachrichten zu verringern. Es gibt bessere Wege große Daten auszutauschen, als diese per Mail zu verschicken. Leider lässt sich das nicht immer durchsetzen. Wenn also große Mails empfangen werden müssen, muss sichergestellt sein, dass die Spitzenlast abgefangen werden kann die große Mails verursachen. Schnell wird dann der Storage zum Flaschenhals. Kleines Rechenbeispiel:

Ganz Mutige können auch die auch das Verhalten von Back Pressure anpassen, indem die sie Maximalwerte erhöhen werden (NICHT EMPFOHLEN). Dazu können die Werte für „VersionBucketsHighThreshold“, „VersionBucketsMediumThreshold“ und „VersionBucketsNormalThreshold“ in folgender Datei höher gesetzt werden:

C:\Program Files\Microsoft\Exchange Server\V15\Bin\EdgeTransport.exe.config

Besser ist es allerdings den Engpass zu finden, der die hohen Werte verantwortlich ist. Ich habe das Problem in meiner Testumgebung nach gestellt (Ich habe die Maximum Werte in der EdgeTransport.exe.config extrem niedrig gesetzt um das Verhalten zu reproduzieren). Ich erhalte also irgendwann das Event 15004 mit dem Hinweis auf zu hohe Version Bucket Werte:

Das Event ist um 20:42 Uhr aufgetreten, also können zunächst die TrackingLogs durchsucht werden, um herauszufinden, ob in dem Zeitraum tatsächlich große Mails gesendet wurden:

$start = "19.11.2014 20:40" | get-date
$end = "19.11.2014 20:45" | get-date
Get-MessageTrackingLog -Start $start -End $end -ResultSize unlimited | where {$_.sender -notmatch "health"} | select timestamp,sender,recipients,totalbytes,eventid

Hier sehen wir dann tatsächlich eine Mail die etwas größer war:

Im Hintergrund habe ich mal den Perfmon laufen lassen, dort sieht es so aus:

Der Leistungsindikator lässt sich auf per Powershell für alle Exchange Server abfragen, daraus könnte man auch ein kleines Monitoring Script bauen:

$exchangeserver = get-mailboxserver

$versionbuckets = @() 
foreach ($server in $exchangeserver)
	{
		$servername = $server.name
		$versionbucketscount = (get-counter "\\$servername\msexchange-datenbank(information store)\zugewiesene versionsbuckets").countersamples.CookedValue
		$versionbuckets += new-object PSObject -property @{Servername="$servername";Versionbuckets="$versionbucketscount"} 
	}
$versionbuckets

Leider gibt es keine Universal Lösung wie in etwa „Hey da ist die Platte zu langsam“ oder „Steck halt mehr RAM rein“, Aber wenn man schon einmal die Uhrzeit und den Auslöser kennt, kann man tiefer in die Analyse einsteigen. Wichtige Faktoren sind:

• CPU Auslastung
• RAM
• Storage Latenz
• Storage Auslastung (IOPS)

In virtuellen Umgebung, kommen noch ein paar weitere Faktoren hinzu (Ich kann jetzt nur von VMware sprechen)

• Ready Werte
• Storage Latenz
• HBA Queues (bei FC)
• ESX Host Auslastung

Mir ist als häufigste Ursache das Storage aufgefallen, mal waren es überlastete HBAs oder überlastete Netzwerkkarten für iSCSI. Mal konnte das Storage selbst einfach nicht genug IOPS für Lastspitzen liefern. Häufig sieht man auch stark überbuchte ESX Hosts.

Es ist also wichtig sich zu anzuschauen, was alles in der Infrastruktur passiert während das Event auftritt. Laufen Virenscans? Läuft ein Backup? usw usw.

Ein guter Ansatz ist folgender: Alle relevanten Konsolen, die Daten liefern können (Storage Monitoring, esxtop oder vSphere Client Leistungsdaten, Windows Perfmon, LAN Switch Konsolen, FC Switch Konsolen usw) und versucht das Problem außerhalb der Geschäftszeit nachzustellen. Einfach mal eine 50 MB Mail an 5 Empfänger schicken und schauen wo es zu Engpässen kommt. Diese kann man dann gezielt abstellen, oder eben die maximale Mailgröße senken…