WLM -Workload Management

Workload Management ist eine Funktion ab Exchange 2013, um für die verschiedenen Dienste die aktuelle Belastung zu ermitteln und Zugriffe der Anwender auf weniger belastete Systeme zu verlagern. Das Ziel ist eine bessere Leistung für den Anwender aber auch eine gleichmäßigere Verteilung der Zugriffe auf die verschiedenen Servern. Exchange 2010 kannte nur ein "Throttling", um z.B. den SMTP-Empfang temporär zu unterbrechen um den Absender zum Switch auf einen anderen Hub-Server zu bringen. Wenn aber Exchange schon selbst sich überwacht und Grenzwerte eingebaut hat, dann wäre es doch interessant die Ergebnisse dieser Überwachung für ein Monitoring anzuzapfen.

Laut Doku ist diese Funktion nur mit Exchange 2013 beschrieben. Auf Exchange 2016 funktioniert es aber auch.

Was ist WLM?

WLM gibt es schon lange aber vermutlich bleibt es den meisten Administratoren auch lange verborgen und sie werden eher mit dem E2013:Heathcheck oder E2013:Troubleshooting Bekanntschaft gemacht haben. Dass es WLM gibt, habe ich erst mit Exchange 2016 quasi "wiederentdeckt", als ich den Vortrag "BRK3206-Exchange Storage for Insiders Its ESE" der Ignite 2015 betrachtet habe. Hier sind zwei Folien zu sehen:


Quelle: BRK3206-Exchange Storage for Insiders Its ESE.mp4 http://video.ch9.ms/sessions/ignite/2015/BRK3206-mobile.mp4


Quelle: BRK3206-Exchange Storage for Insiders Its ESE.mp4 http://video.ch9.ms/sessions/ignite/2015/BRK3206-mobile.mp4

Die Sprecher gehen nur kurz auf WLM im Rahmen der ESE-Thematik ein, aber mir hat es gereicht hier etwas genauer nachzuschauen.

Was misst und bewertet Exchange?

Irgendwo in den Tiefen der Exchange Konfiguration steckt das wissen, was Exchange überwacht. Das passende Commandlet hierzu ist "Get-ExchangeDiagnosticInfo". Exchange organisiert intern die Einstellungen pro Server und Prozess. Ein einfacher Aufruf ohne Parameter liefert als "Result" eine XML-Struktur mit allen Prozessen, die überwacht werden. Hier der Anfang.

[PS] C:\>Get-ExchangeDiagnosticInfo 

RunspaceId  : 4dfecacb-4464-41e9-89e0-b0bb97ab6a5c
Result      : <Diagnostics>
                <ProcessLocator>
                  <count>40</count>
                  <Process>
                    <guid>5b078d0c-1639-44f6-98ce-cac2c9a90a9e</guid>
                    <id>1756</id>
                    <name>Microsoft.Exchange.Directory.TopologyService</name>
                  </Process>
                  <Process>
                    <guid>b0c11255-d44f-4235-8740-70daa39d24dc</guid>
                    <id>3848</id>
                    <name>noderunner</name>
                  </Process>
                  <Process>
                    <guid>5b66d007-510f-4186-b591-6681a9b547a1</guid>
                    <id>13820</id>
                    <name>MSExchangeOWACalendarAppPool</name>
                  </Process>
                  <Process>
                    <guid>650156b7-380c-4e72-bcb4-3ec95b00cf99</guid>

Eine Liste der Prozesse bekommen Sie mit:

[PS] C:\>( [xml](Get-ExchangeDiagnosticInfo).result).diagnostics.processlocator.process | select name

name
----
Microsoft.Exchange.Directory.TopologyService
noderunner
MSExchangeOWACalendarAppPool
MSExchangeMapiAddressBookAppPool
MSExchangeMapiMailboxAppPool
MSExchangeRpcProxyAppPool
MSExchangePowerShellAppPool
MSExchangeAutodiscoverAppPool
noderunner
Microsoft.Exchange.UM.CallRouter
umservice
EdgeTransport
Microsoft.Exchange.Store.Worker
MSExchangeTransport
MSExchangeThrottling
MSExchangeSubmission
Microsoft.Exchange.ServiceHost
Microsoft.Exchange.RpcClientAccess.Service
Microsoft.Exchange.Imap4Service
Microsoft.Exchange.Imap4Service
MSExchangeHMWorker
msexchangerepl
MSExchangeMailboxReplication
Microsoft.Exchange.Imap4
Microsoft.Exchange.Store.Service
Microsoft.Exchange.Imap4
MSExchangeMailboxAssistants
MSExchangeHMHost
MSExchangeFrontendTransport
Microsoft.Exchange.Search.Service
MSExchangeDelivery
MSExchangeCompliance
MSExchangeOWAAppPool
MSExchangeServicesAppPool
MSExchangeECPAppPool
MSExchangeSyncAppPool
MSExchangeRpcProxyFrontEndAppPool
MSExchangeMapiFrontEndAppPool
MSExchangePowerShellFrontEndAppPool

Basierend auf dieser Datei kann ich dann die Details zu einem Prozess erfragen. Diesmal ist die XML-Struktur noch deutlich umfangreicher allein für einen Prozess.

[PS] C:\>Get-ExchangeDiagnosticInfo -Process MSExchangeOWACalendarAppPool

RunspaceId  : 4dfecacb-4464-41e9-89e0-b0bb97ab6a5c
Result      : <Diagnostics>
                <ProcessInfo>
                  <id>13820</id>
                  <serverName>EX2016</serverName>
                  <startTime>2016-09-20T20:04:53.9575339Z</startTime>
                  <currentTime>2016-09-30T20:57:38.7178214Z</currentTime>
                  <lifetime>10.00:52:44.7602875</lifetime>
                  <threadCount>44</threadCount>
                  <handleCount>1614</handleCount>
                  <workingSet>121.6 MB (127,516,672 bytes)</workingSet>
                </ProcessInfo>
                <Components>
                  <ADDriver>
                    <Help>Supported arguments: connections=String, partnerdc=String</Help>
                  </ADDriver>
                  <ProcessModuleInfo>
                    <ProcessModuleInfoDiagnosticResult xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
                      <Modules>
                        <ModuleDiagnosticInfo>
                          <FullName>mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089</FullName>
                          <FileVersion>4.6.1085.0 built by: NETFXREL4STAGE</FileVersion>
                          <ProductVersion>4.6.1085.0</ProductVersion>
                          <OriginalFileName>mscorlib.dll</OriginalFileName>
                          <LastModificationTime>2016-09-20T19:51:51.6758144Z</LastModificationTime>
                          <Location>C:\Windows\Microsoft.NET\Framework64\v4.0.30319\mscorlib.dll</Location>
                        </ModuleDiagnosticInfo>
                        <ModuleDiagnosticInfo>
                          <FullName>System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a</FullName>
                          <FileVersion>4.6.1085.0 built by: NETFXREL4STAGE</FileVersion>
                          <ProductVersion>4.6.1085.0</ProductVersion>
                          <OriginalFileName>System.Web.dll</OriginalFileName>
                          <LastModificationTime>2016-09-20T19:51:49.1601545Z</LastModificationTime>
                          <Location>C:\Windows\Microsoft.Net\assembly\GAC_64\System.Web\v4.0_4.0.0.0__b03f5f7f11d50a3a\System.Web.dll</Location>
                        </ModuleDiagnosticInfo>
                        <ModuleDiagnosticInfo>
                          <FullName>System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089</FullName>

Sie erkennen aber schon die aktuellen Betriebsdaten wie die ProzessID aber auch z.B. die Anzahl der Handles etc. Zudem gibt es noch weitere "Components". Hier sieht man erst mal nur den ADDriver. Interessanter ist nun mal eine komplette Liste:

$processlist =( ( [xml](Get-ExchangeDiagnosticInfo).result).diagnostics.processlocator.process | select name -ExpandProperty name)
foreach ($process in $processlist){
   write-host "Loading Components for Process " $process
   get-exchangeDiagnosticInfo -process $process
}

Auch die WLM-Konfiguration kann über eine Richtlinie angepasst werden.

# Anzeigen der WLM Policy
Get-ExchangeDiagnosticInfo `
   -server <server> `
   -process MSExchangeMailboxAssistants `
   -Component SystemWorkloadManager `
   -Argument polic

Auch hier kommt eine XML-Ausgabe zurück, die Sie weiter parsen können

Wie kann ich den aktuellen Status lesen?

Der erste und einfache Einstiegspunkt ist der Blick auf einzelne Ressourcen. Sie holen sich dazu die Liste der Prozesse mit:

[xml]$processlist=Get-ExchangeDiagnosticInfo -Server EX16A

Und dann bleibt wieder nur einen Schleife durch alle Prozesse. Exemplarisch habe ich hier einen Prozess ausgegeben.

$diag = Get-ExchangeDiagnosticInfo `
   -Server EX16A`
   -Process EdgeTransport `
   -Component ResourceManager `
   -Argument verbose

[PS] C:\>([xml]$diag.Result).Diagnostics.ProcessInfo

id : 38488
serverName : EX16A
startTime : 2021-08-10T12:53:01.5812516Z
currentTime : 2021-08-31T21:40:36.4858636Z
lifetime : 21.08:47:34.9046120
threadCount : 258
handleCount : 5515
workingSet : 1.195 GB (1,283,330,048 bytes)
fastTrainExchangeVersion : 15.1.2308.14

Ab nun können Sie überlegen, welche Prozesse sie in welche Monitoring-Lösung einspeisen. Ich würde einfach ein PowerShell-Skript bauen, welches auf dem Exchange Server lokal oder einem ManagementSystem remote zyklisch die Daten ausliest, entsprechend formatiert und an ihre Monitoring-Lösung übermittelt. Für PRTG könnte das ein PRTG - HTTP Push-Sensor sein. Andere Monitoring-Lösungen wie Nagios/Cacti/CheckMK haben ähnliche Schnittstellen. Sie können auch die numerischen Werte z.B. in eine Grafana/Influx oder ELK-Lösung senden.

Vielleicht liefe ich später mal ein Skript nach, welches diese Daten in ein Monitoring exportiert. Wen Sie woanders schon ein passendes Skript finden, dann setze ich gerne einen Link

Weitere Links