Archive for the ‘SML’ Category

h1

SCOM 2007 (OpsMgr) – meine ersten Eindrücke

11. Juli 2007

Microsoft Operationsmanager MOM hat einen Nachfolger bekommen, den System Center Operations Manager 2007 (kurz SCOM2007 oder OpsMgr)

Die Oberfläche

Der System Center Operations Manager (OpsMgr) präsentiert sich mit einer Konsole, von der aus alles erledigt werden kann: Einrichten, Überwachen, Tunen. Er stellt definierte Rollen für Zugriff und Berechtigungen zur Verfügung und bindet sehr intensiv das Active Directory ein. AD wird konsultiert für Discovery, Benutzerkonten, Agent Configuration, die auf OU-Ebene durchgeführt werden kann.

OpsMgr RAM Usage

„Self Tuning Thresholds“ erleichtern die Arbeit des Nachjustierens der Schwellwerte. Erstaunlich ist der Ressourcenverbrauch: 2 GB RAM sind weg wie nix. Wenn ich da an meinen Nagios auf der Soekrisbox denke …

Überwachen

Model-Based Architecture

Mit der Service Modeling Language (SML) würde ein echter W3C Standard mit tatsächlich breiter Unterstützung und offener Spezifikation zur Verfügung stehen.

System Modeling Language

Leider basiert die derzeitige Version des OpsMgr aber auf einer Vorversion dieses Standards. Mit SML könnten Services und Health-Models herstellerübergreifend konstruiert werden. Der Lieferant einer UPS könnte dann für alle SML-basierenden Operations Manager eine Monitoring-Schnittstelle liefern.

xml.png

Zum Teil (sehr zögerlich) machen das auch manche Hersteller, indem sie sogenannte Management Packs zur Verfügung stellen. Diese kommen als sealed packages, also verschlüsselt in den OpsMgr. Die Verschlüsselung hat lt. MS den Hintergrund, dass es sonst laufend zu Fehlern käme, wenn die Admins in dem Management Packs herumbasteln würden. „Soso“, sag ich da nur und frage mich, inwieweit denn diese Managementpacks dann auch für andere Monitoringprodukte verwendbar sind – das ist bis jetzt jedenfalls im Dunkeln.

Enduserperspektive

Eine schöne Sache: Webseiten zum Beispiel können regelmäßig auf deren Verfügbarkeit hin geprüft werden. Sogar nach Schlüsselwörtern in dem empfangenen HTML-Code kann gesucht werden. Das erlaubt ungeahnte Einsatzzwecke: Abfrage bei http://wetter.orf.at und Alarm immer wenn „Regen“ (w/o the quotes, wie es in der MS-Knowledbase heißen würde) gefunden wurde ergibt einen elektronischen Wetterfrosch mit 2 GB Hauptspeicherbedarf.

Im Ernst: Diese als Syntetic Transactions bezeichneten „gescripteten Enduser“ können von verschiedenen „watcher-nodes“ aus ihr Checks durchführen. Das ist ein feine Sache zumal auch komplexere Checks mit „http post“ (Passworteingabe) möglich sind.

Maintanance Mode

Objekte können in Maintanance Mode gesetzt werden. Ab dann werden alle Alerts werden unterdrückt und die Downtime fließt dann nicht in die Verfügbarkeitsstatistik ein.

Interoperabilität

Wie schaut es, abgesehen von dem bisher nicht eingelösten Versprechen sich an einen W3C-Standard zu halten, sonst mit der Interoperabilität aus?

SNMPv2 wird unterstützt, die Version v1 nur mit einem nachzuinstallierenden Patch und v3 wurde angekündigt ohne konkreten Termin. Und tatsächlich, man kann Abfragen (snmp get) starten. Inwieweit diese auch nutzbar sind, wird man sich noch ansehen müssen. Auch SNMP Traps können empfangen und verarbeitet werden.

Bereits der MOM konnte Logfiles von syslog-Clients auswerten. Das kann der OpsMgr auch – nur wie das gehen soll, ist leider nicht so einfach in Erfahrung zu bringen. Wir warten also auf die dazu nötige Doku.

Zusammenfassung

Der OpsMgr ist wohl einfacher als der MOM 2005 zu bedienen: Er hat nur noch eine Konsole und ist weitestgehend in das AD-integriert. Die Self-Tuning-Tresholds sind ein echter Timesaver – aber nur wenn man eine reinrassige MS-Umgebung hat und darauf verzichtet, die darunter liegenden Netzwerkkomponenten überwachen zu wollen.

Theoretisch wäre er offener als der MOM 2005; der W3C-Standard für die Management Packs und SNMP v2, sowie die Integration von Syslogs und Webservices machen Hoffnung. Sehr fraglich ist aber beim derzeitigen Stand der Dokumentation, inwieweit diese wirklich nutzbar sind. Hier tut sich unter Umständen ein interessanter Markt für Firmen auf, die über Knowhow mit alternativen Monitoren wie Nagios haben und für das Thema Interoperabilität aufgeschlossen sind.

Erschreckend finde ich den Ressourcenbedarf. Alleine was an Serverpower nötig ist, um den OpsMgr zu betreiben ist gewaltig. Prüfen würde ich auch, inwieweit die Kommunikation zwischen Agenten und Zentralserver nicht merkbar das Netz belastete; deren Kommunikation erfolgt auf TCP-Basis.

Das eigentliche Drama ist aber die fehlende Dokumentation, ohne die anspruchsvollere Anwendungen, die beispielsweise Netzwerkkomponenten wie Switches und Firewalls mit einschließen, schwer möglich sind.

Link

http://www.w3.org/Submission/2007/SUBM-sml-20070321/