Tags: System-Management, Windows Server, RSAT
Beim WSRM handelt es sich um ein Feature, mit dem Administratoren die CPU- und Speicherauslastung verwalten können. Die Zuordnung erfolgt an Anwendungen (Dienste), Benutzer, RDP-Sitzungen und Internet Information Services (IIS) Anwendungspools. Der Sinn hinter WSRM ist es, Server mit multiplen Rollen und Features so zu betreiben, dass deren gleichzeitige Verfügbarkeit gewährleistet ist, die Belegung der gesamten Ressourcen durch eine einzelne Rolle, RDP-Sitzung oder Dienst also verhindert wird.
Damit beschränkt sich der Einsatz von WSRM von vornherein auf das Szenario, dass ein Server mehrere Rollen zu erfüllen hat. Ressourcen zwischen mehreren Servern verteilen kann es nicht, und für Server, die eine einzige Rolle ausführen, braucht man es nicht.
WSRM installieren
WSRM wird als Feature installiert. Er benötigt eine Datenbank; befindet sich auf dem Server keine SQL-Installation, greift er auf die Windows-interne Datenbank zurück, die bei Bedarf als Abhängigkeit mit installiert wird. Zu WSRM gehört ein gleichnamiger Dienst, der automatisch gestartet wird. Von einer gelungenen Installation kann man sich überzeugen, indem man prüft, dass der Dienst „Windows-Systemressourcen-Manager“ gestartet wurde. Zur Installation gehört ein entsprechendes MMS-Snap-In. Auch von einer Workstation in der Domäne aus lässt sich WSRM per RSAT verwalten.
Vordefinierte WSRM-Richtlinien
WSRM tritt mit seinen vordefinierten Richtlinien erst in Aktion, wenn es notwendig ist, also Ressourcen knapp werden: Liegt die Gesamt-CPU-Auslastung unter 70%, greift die Ressourcenverwaltung nicht ein. Prozesse, Benutzer und Sitzungen können in einer solchen Situation reichhaltig vorhandener Reserven mit diesen umgehen, als ob der Manager nicht installiert wäre.
Die Verwaltung der Ressourcen erfolgt über Richtlinien – bequemerweise über 5 vordefinierte oder aufwendiger per Eigendefinition. Die vordefinierten Richtlinien sind für typische Rollenzusammenstellungen ausgelegt. Dabei handelt es sich um
| Policy | Beschreibung |
|---|---|
| Gleich pro Prozess (Equal Per Process) | Jeder Prozess wird gleichbehandelt. Liegt die Gesamt-CPU-Last über 70%, erhält jeder Prozess nur noch höchstens 10%. CPU-Zeit, die von geringlastigen Prozessen darüber hinaus übrigbleibt, wird anderen Prozessen zugeteilt. |
| Gleich pro Benutzer (Equal Per User) | Prozesse werden nach Benutzerkonto gruppiert und diese Gruppen dann gleichbehandelt, egal wie viele Prozesse darin jeweils aktiv sind – etwa jeweils 25% der Gesamt-CPU-Zeit bei 4 Benutzern. |
| Für Sitzung identisch (Equal Per Session) | Ressourcen werden gleichmäßig zwischen allen mit dem System verbundenen RDP-Sitzungen aufgeteilt. |
| Für IIS-Anwendungspool identisch (Equal per IISAppPool) | Ressourcen werden gleichmäßig zwischen allen IIS-Anwendungspools aufgeteilt. Wichtig: Anwendungen außerhalb eines IIS-Anwendungspools erhalten nur Ressourcen, die nicht von IIS-Anwendungspools belegt sind. |
| Gewichtete Remotesitzungen | Erlaubt es, Remote-Benutzern verschiedene CPU-Prioritäten zuzuteilen und Ressourcen entsprechend deren Einstufung zuzuweisen. Wichtig: Für das Festlegen oder Entfernen dieser Richtlinie muss der Server jeweils neu gestartet werden. |
Die Richtlinien setzt man im WSRM-Manager jeweils per Kontextmenüpunkt „Als Verwaltungsrichtlinie setzen“ in Kraft. Schaut man näher in das Innenleben einer Richtlinie, fällt auf, dass gewissen Prozesse von der Verwaltung ausgeschlossen sind, wie etwa services.exe oder winlogon.exe. Windows’ essentielle Systemprozesse kann man also mittels der Voreinstellungen nicht beschneiden und damit das die Stabilität des Systems gefährden.
Eigene WSRM-Richtlinien definieren
Eigene WSRM-Richtlinien definiert man im WSRM-Manager im Kontextmenü der bereits vordefinierten Richtlinien vor. Eigene Richtlinien erlauben eine sehr viel feinere Granulierung, etwa was auszuschließende Prozesse, die Schwellen für die Rest-CPU-Last und die Aufteilung zwischen verschiedenen Prozessoren betrifft. Auch eine Steuerung nach Zeit mit Hilfe des integrierten Kalenders sowie bedingte Richtlinien sind möglich – letztere treten erst als Reaktion auf definierbare Systemereignisse in Kraft.
Es ist jeweils möglich, bereits definierte Richtlinien und Auswahlkriterien als Grundlange für weitergehende Definitionen zu verwenden. Vorsicht – im benutzerdefinierten Modus mit eigenen WSRM-Richtlinien sind Netz und doppelter Boden weg: Die Ausschlussliste für systemrelevante Prozesse erstellt der Administrator hier selbst und startet mit einer leeren Liste. Die WSRM-GUI in der MMC deckt auch nicht alles ab, was man für deren Definition benötigt: Um Prozessnamen inklusive Parameter in die Liste aufnehmen zu können, muss man auf das Kommandozeilentool wsrmc.exe zurückgreifen. Das wird insbesondere dann notwendig, wenn es darum geht, Dienste zu adressieren, die per svchost.exe veraltet werden. Eine Beispielzeile, um etwa den Dienst für die Bilderübertragung von Scannern und Kameras in die Ausschlussliste aufzunehmen, wäre etwa
Wsrmc.exe /Set:UserExclusionList /INS → → /ProcList:"%WINDIR%\System32\Svchost.exe -k imagesvr"Microsoft-Dokumentation zu WSRM im TechNet
Ausführlich findet man alle Einzelheiten zu WSRM im TechNet in deutscher und englischer Sprache.
Täglich Know-how für IT-Pros mit unserem Newsletter
Andreas Kroschel ist Buchautor und Verfasser von Fachartikeln zu Hardware, Windows und Linux sowie IT-Sicherheit. Er arbeitete als Redakteur unter anderem für BYTE Deutschland und die PC-Welt.
Ähnliche Beiträge
Weitere Links