In diesem Beitrag möchte ich ein paar Infos zum Thema Resource Pools im Bezug auf das Netzwerkmonitoring mit SCOM 2012 geben.

Es gibt eine klare Empfehlung seitens Microsoft, daß für das Netzwerkmonitoring ein eigener Resource Pool angelegt werden soll. In diesem Pool sollten nur Management Server bzw. Gateway Server enthalten sein, die keinem anderen Pool zugeordnet sind.

Das Erstellen eines neuen Pools ist sehr einfach:

Die Server des neuen Pools sollten nun noch aus den anderen Resource Pools entfernt werden. Damit dies möglich ist, muss der entsprechende Pool auf "Manual Membership" umgestellt werden.
Dies geht für fast alle System Pools direkt in der Console:

Lediglich für den "All Management Servers Resource Pool" ist das nicht möglich. Für diesen Pool kann man die Umstellung via Powershell Kommando durchführen:

Get-SCOMResourcePool –Name “All Management Servers Resource Pool” | Set-SCOMResourcePool –EnableAutomaticMembership $FALSE 

WICHTIG: Nach der Umstellung der Pools werden neu installierte Management Server nicht mehr automatisch den System Pools zugeordnet. Dies muss manual durch einen Administrator erfolgen.

Nachdem der Resource Pool erstellt wurde, wird eine entsprechende Discovery Rule erstellt. Dabei gilt:

• Jedem Management oder Gateway Server kann genau eine Discovery Rule zugeordnet werden
• Die Überwachung der Devices, die durch eine Rule gefunden werden, erfolgt durch den zur Rule angegebenen Resource Pool
• Sollten mehr als eine Discovery Rule nötig sein, so sollte jeweils ein eigener Pool erstellt werden
• Jedes Netzwerkdevice sollte nur von einem Pool überwacht werden. Ist dies nicht der Fall, kann das Gerät nicht aus dem Operations Manager entfernt werden

Weitere Infos über das Thema Resource Pools folgen ...

Allgemein bekannt ist die Tatsache, das mit dem System Center Operations Manager 2012 der Root Management Server der Vergangenheit angehört. Für alle Monitore und Rules, die als Target den RMS hatten, gibt es nun die RMS Emulator Rolle.

Neu sind nun die Management Server Resource Pools, in denen verschiedene Management Server gleichberechtigt in einer Gruppe ihren Dienst erledigen. Ich möchte an dieser Stelle meine ersten Erfahrungen und Erkenntnissen mit den neuen Pools und deren Besonderheiten ansprechen.

Fakt 1: Obwohl nun auf allen Management Servern die vom RMS bekannten 3 Dienste laufen (Data Access, Management Configuration und System Center Management), bezieht sich aktuell die Pool-Funktionalität lediglich auf den Health Service.

Auswirkung 1: Eine Console verbindet sich nicht mit einem Pool, sondern per Zufall mit einem der SDK Dienste eines Management Servers. Will man hier einen Failover oder eine Lastverteilung einrichten, so ist das NLB (Network Load Balancer) Feature die Lösung. Damit kann man einen virtuellen Namen für die Consolen Anmeldung vergeben und dahinter verbergen sich die im Cluster eingetragenen Management Server.

Auswirkung 2: Auch die Agenten kann man nicht mit einem Pool verbinden. Diese werden wie unter SCOM 2007 R2 konfiguriert. Entweder über die Active Directory Integration oder mit einem primären MS und ein oder mehreren Failover Servern.

Auswirkung 3: Durch die verstärkte Kommunikation zwischen den Management Servern gibt es seitens der SCOM 2012 Produktgruppe die Vorgabe, dass die Latenz Zeit zwischen den MS Rechner maximal 5 ms betragen darf. Hat man im Moment in dezentralen Standorten einen MS stehen, so sollte dieser in das zentrale RZ umgezogen und durch ein Gateway ersetzt werden.

Weitere Infos über das Thema Resource Pools folgen ...

Mit der Installation eines SCOM 2012 Agenten wird auf einem System nun ebenfalls ein kleines grafisches Konfigurationstool installiert. Mit diesem Tool hat man die folgenden Möglichkeiten:

• den Agenten zu einer weiteren Management Gruppe hinzufügen
• den Agenten aus einer Management Gruppe entfernen
• die Active Directory Integration ein- bzw. auszuschalten
• den "Local Action Account" für den Agenten ändern

Zu finden ist das Tool nach einer Agenteninstallation unter "Systemsteuerung/System und Sicherheit" (bzw. "Control Panel/System and Security"):

Nach dem Start des erhält man eine Liste der Management Gruppen, mit denen der Agent verbunden ist:

Über Add / Remove kann eine weitere Management Gruppe hinzugefügt werden bzw. ein vorhandene gelöscht werden.

Wird eine Gruppe in der Liste markiert, so erhält man mit der Edit-Funktion einen Dialog, in dem der lokale Action Account eingestellt werden kann. Damit gibt es nun ein sehr schöne Möglichkeit für einen Systemadministrator, spezielle Benutzerdaten für den Agenten zu setzen, ohne auf die Hilfe der SCOM Administratoren angewiesen zu sein:

Zusammenfassend bleibt zu sagen, dass dieses kleine Tool ein weiterer postiver Schritt in Punkto Benutzerfreundlichkeit darstellt.