03-04-2017 – OMS: SCOM aus der Cloud?

1-OMS-7-22-16-1

03-04-2017 – OMS: SCOM aus der Cloud?

3 April 2017 - 10:41
OMS

Ich erinnere mich an Schlüsselerlebnisse an diversen Konferenzen, Gesprächen mit Kunden und auch Austausch mit Kollegen, dass ein Missverständnis stets im Raume kursierte und viel Verwirrung stiftete. Die Kernaussage war «Operations Management Suite ist SCOM aus der Cloud». Stimmt das? Um dieses (Miss)Verständnis aufzuklären und die Frage zu beantworten, muss etwas Vergangenheitsbewältigung betrieben werden, analog dem Zitat «Wer in der Zukunft lesen will, muss in der Vergangenheit blättern.» [André Malraux].

System Center Operations Manager (SCOM) war und ist DIE Monitoring Lösung für homo- und heterogene IT-Umgebungen aus dem Hause Microsoft. SCOM wurde ursprünglich von NetIQ entwickelt und im Jahre 2000 von Microsoft gekauft und hat eine 17-jährige Evolution hinter sich welche zuerst Microsoft Operations Manager (MOM) getauft wurde. 2007 wurde «MOM» komplett umgeschrieben auf ein flexibles und erweiterbares Framework. System Center Operations Manager war geboren und seither stetig weiterentwickelt und liegt nun in der aktuellsten Version SCOM 2016 vor.

Vor ca. 6 Jahren begann Microsoft mit System Center Advisor, einer auf Agenten basierenden Assessment und Best Practice Analyzer Lösung aus der Cloud zu experimentieren. Es war möglich verschiedene Workloads wie Windows Betriebssystem, SQL Server, Active Directory und Hyper-V Komponenten zu analysieren, Veränderungen der IT-Infrastruktur zu erkennen und Best Practices von Microsoft vorzuschlagen in Form von Alarmierungen. Zwischen 2012 und 2013 wurde die Palette der unterstützten Technologien erweitert auf Exchange, SharePoint und Lync. Anfangs war es noch eine isolierte Lösung, diese wurde aber schnell durch einen SCOM Connector in SCOM 2012 SP1 integriert, so dass Informationen zwischen der on-premise Lösung SCOM und der Cloud «Extension» System Center Advisor möglich war. In der nächsten SCOM Version 2012 R2 war der Connector bereits integriert. 2014 wurde System Center Advisor transformiert, weg von einer Silverlight basierten Weblösung hin zur einer HTML 5 Webapplikation mit erweitertem Angebot. Das heisst, der Best Practice Analyzer System Center Advisor wurde in das neue Produkt Azure Operational Insights integriert und Palette der Möglichkeiten erweitert durch sogenannte Intelligence Packs (IP). Zur Verfügung standen folgende Packs:

·         Configuration Assessment

·         Malware Assessment

·         Capacity Planning

·         Change Tracking

·         Log Management

·         SQL Assessment

·         System Update Assessment

Eine Schlüsselfunktionalität war ein cloudbasierter «Datentopf» der mittels Agent befüllt und mit einem PowerShell ähnlichen Syntax im Azure Operationals Insights Search Data Explorer durchsucht und analysiert werden konnte. Eine Verbindung an das Urgestein SCOM wurde auch durch einen Connector sichergestellt. Ein weiteres umbenennen des Operational Insights Produktes legte den Grundstein für heute all gegenwärtige Operations Management Suite (OMS), welche nun nicht mehr auf Intelligence Packs basiert, sondern auf sogenannten Solutions und Azure Operational Insights Search Data Explorer wird nun Azure Log Analytics genannt.

Da wir nun den Hintergrund beider Produkte etwas kennen, möchte ich gerne deren Fakten gegenüberstellen, um nun die die eingehende Frage objektiv beantworten zu können.

Konzept

SCOM besteht aus einem erweiterbaren, hierarchisch aufgebauten Objektmodell. Das heisst, Komponenten die in SCOM überwacht werden sollen, können mittels Management Packs (XML Dateien), entdeckt (Discovery) und mittels Beziehungen untereinander in eine Hierarchie setzen (Service Model). Durch Sensoren (Monitore) kann ein untergeordnetes Objekt, ein übergeordnetes Objekt in einen gesunden (Healthy) Zustand oder in einen fehlerhaften (Unhealthy) Zustand versetzen und diesen visuell darstellen. Dieses Modell wird als Health Modell beschrieben und hat durch seine Abhängigkeiten viele Vorteile aber auch gewisse Nachteile, die vor allem in der Administration zum Tragen kommen.

OMS arbeitet mit sogenannten flachen Daten, das heisst die Daten existieren als Datensätze in einen grossen Datentopf. Es bestehen keine Objekte noch Beziehungen unter den gesammelten Daten. Zum Beispiel werden mittels Solution 1 Diskinformationen von Computer X gesammelt und zugleich von einer anderen Solution 2 Information über die selbe Disk gesammelt, besteht keine Beziehung noch Kenntnisse des Status zwischen den Disk Daten aus Solution 1 und Solution 2. OMS hat (noch) kein Service Model und demnach auch kein Health Model.

Agenten

SCOM und OMS stehen Agenten zur Verfügung um Infrastrukturdaten zu sammeln, der Microsoft Monitoring Agent. Während SCOM angewiesen ist, dass er der Agent seine Daten an ein Management- oder Gateway Server benötigt, kann OMS seine Daten via SCOM Management Group oder als eigenständiger Agent die Daten in die Cloud senden. Mittlerweile setzt Microsoft für beide Produkte den selben Microsoft Monitoring Agenten (MMA) ein, das heisst ein Agent für beide Produkte.

Daten sammeln

Die Intelligenz zum Sammeln der Daten wird in Form von Management Packs für SCOM von Microsoft zur Verfügung gestellt oder können selber erstellt werden (Authoring). Management Packs beinhalten Klassen, Beziehungen, Discoveries, Regelwerke zum Alarmieren (Monitors/Rules), Schwellwerte, Ansichten für die Konsole, Reports etc. Durch diese offene Struktur können Management Packs für nicht unterstützte Applikationen selber erstellt werden. Dies erfordert jedoch ziemlich hohes Know-How an den MP Author.

In OMS wird die Logik zum Sammeln der Daten in Solutions verpackt. Wobei man hier abstrahieren muss zwischen der eigentlichen Logik zum Sammeln der Daten und der Visualisierung. Daten können via Management Pack ähnlichen Konstrukten via SCOM nach OMS gesendet werden oder via Log Analytics HTTP Data Collector API. Die REST API kann über PowerShell, C# oder jede andere Programmiersprache angesprochen werden und durch einen JSON formatierten Request befüllt werden. Die Visualisierung der Daten wird mittels View Designer in Azure Log Analytics erstellt, siehe hierzu den Punkt Visualisierung. Am Ende wird die Lösung in Azure Resource Manager (ARM) Templates verpackt und verteilt.

Ein wichtiger Unterschied besteht auch beim gezielten Steuern, auf welchen Systemen welche Daten gesammelt werden können. SCOM bietet ein sehr granulares, gezieltes Sammeln der Daten (Targeting). Das heisst, die Regelwerke können gezielt auf spezielle Objekte ausgeführt werden. OMS bietet zurzeit keine Möglichkeit die Solutions auf dedizierten Zielsystemen auszuführen.

Visualisierung

Die Möglichkeiten in SCOM, Daten ohne Drittanbieter Tool zu visualisieren sind sehr bescheiden und wahrscheinlich auch eine Schwäche des Produktes. Eine Übersicht der aktuellen Infrastruktur Informationen können über Ansichten in der Konsole dargestellt und durch Dashboards und Widgets etwas verfeinert werden. Die verfügbare Webkonsole bietet eine limitierte Darstellung für Endanwender und Applikationsverantwortliche. Langzeitdaten können mittels SQL Server Reporting Services (SSRS) Reports ausgewertet werden.

OMS basiert auf HTML 5 und nutzt somit eine aktuelle und weit verbreitete Technologie. Die Darstellung der Daten können mittels Log Search Abfragen vordefiniert werden. Anschliessend können die Suchabfragen direkt im Portal über den View Designer mit vordefinierten Ansichten (Views) in einer modernen Form dargestellt werden. Die Auswahl an Views ist derzeit noch etwas limitiert.

Schnittstellen

SCOM unterstützt keine aktuellen Schnittstellen um Daten von Fremdsystem zu empfangen. Es gibt die Möglichkeit von PowerShell, Management Pack Authoring, Software Development Kit (SDK) oder via Custom Connector, Informationen in SCOM zu bringen. Eine API sucht man vergebens.

OMS wurde entwickelt um moderne Standards zu unterstützen und bietet daher auch eine mächtige REST API, welche einfach über eine Script- oder Programmiersprache angesprochen werden kann. Einen etwas komplizierterer weg über Management Packs besteht auch.

Daten Analyse

Für Langzeit Datenanalyse bietet SCOM ein SQL Server basiertes Datawarehouse an. Das heisst eine Datenbank, die Monitoring Daten als Roh- und aggregierte Datenpunkte in der Datenbank gespeichert hat und mittels Reporting Tools ausgewertet werden können.

Einen neuen Ansatz geht OMS. Die gesammelten Daten werden in Azure Storage gespeichert und nicht aggregiert. Mittels proprietärer Suchsprache, können die Daten durchsucht und analysiert werden. Die Suchabfragen können gespeichert werden und für verschiedene Anwendungszwecke weiterverwendet werden so zum Beispiel für Visualisierungen und Alarmierung.

Alarmierung

Ein wichtiges Kriterium für ein Monitoring Tool ist das Alarmieren. Die bedeutet durch definieren von Schwellwerten (Thresholds), werden Grenzwerte gesetzt die bei Unter- oder Überschreiten eine Meldung (Alert) versenden. SCOM bietet Monitore und Regeln die diese Aufgabe sehr spezialisiert übernehmen und aus der Monitoring Perspektive entwickelt wurden.

OMS bietet einen anderen und weitaus reduzierteren Ansatz als SCOM. Die Basis in Azure Log Analytics ist immer eine Suchabfrage (Search Query). Basierend auf dieser Abfrage, können Metriken gesetzt werden, die bei Unter- oder Überschreitung, Aktionen getriggert werden, welche dann einen Alarm / Mail versenden oder auch einen Webhook oder Azure Automation Runbook triggern.

Interoperabilität

Die Unterstützung von heterogenen IT Infrastrukturen wird immer wichtiger. So gibt es kaum noch reine Microsoft Umgebungen, sondern UNIX/Linux Derivate haben schon lange ihren Platz in den Datacentern gesichert und für eine ausgewachsene Monitoring Lösung ist es nahezu ein Muss, Microsoft und UNIX/Linux Varianten zu unterstützen. Weiterer Support für Netzwerkkomponenten und Azure Workloads darf natürlich auch nicht fehlen. SCOM und OMS bieten beide Agenten und Support für Windows und UNIX/Linux an.

SCOM bietet in allen Bereichen eine ausgereifte Lösung die das Monitoring bei on-premise Komponenten sehr ausgereift ist und auch gewisse Unterstützung für Azure Workloads bietet, dies aber in einem begrenzten Rahmen.

OMS bietet Support für Microsoft und UNIX/Linux Derivate und hat einen breiten Grad an Unterstützung. Im Bereich Netzwerk Monitoring, bestehen zum einen Solutions und für ein reines SNMP Monitoring muss die Datensammlung über eine UNIX/Linux Maschine konfiguriert werden. Eine noch etwas breite Unterstützung bietet OMS für verscheiden Azure Workloads. OMS wurde in Azure geboren und daher ist es nicht verwunderlich, dass die Unterstützung für Azure quasi in die Wiege gelegt wurde.

Administration und Sicherheit

Ein wichtiger Punkt ist die Administration und in diesem Zusammenhang auch der Sicherheitsaspekt. Überall wo Daten gesammelt werden, können die Daten eine gewisse Brisanz haben. Spätestens, wenn Daten aggregiert und kombiniert werden können, kann die Brisanz um Faktoren gesteigert werden. SCOM war / ist ein reines on-premise Monitoring Tool, das die Datenhaltung aufgeteilt in 2 Datenbanken kennt. Die Kontrolle aller Komponenten inkl. der Daten ist zu diesem Zeitpunkt bei der Firma, die das System betreibt. Richtig konfiguriert, haben nur SCOM Administratoren Zugriff auf die Informationen. Dies bringt jedoch auch mit sich, dass alle Komponenten administriert, gepflegt und unterhalten werden müssen. Dies darf man nicht vernachlässigen, auch wenn es «nur» ein Monitoring System ist.

OMS verfolgt einen ganz anderen Ansatz. OMS ist eine «Software as a Service» (SaaS) Applikation, die voll und ganz durch Microsoft verwaltet wird. Das heisst von der Bereitstellung von genügend Kapazitäten / Resource bis hin zum Unterhalt und Erweiterung der Lösung. Der springende Punkt ist, dass auch die gesammelten Informationen in der Cloud gespeichert werden und nicht mehr unter der gleichen Kontrolle stehen wie bei einer on-premise Lösung. Die bereitet vielen CIOs Bauch- und Kopfschmerzen, Microsoft versucht die Bedenken mittels Aufklärung und Zertifizierungen entgegenzuwirken.

 

Ist OMS nun SCOM aus der Cloud? Blicken wir zurück. SCOM wurde zu einer Zeit erschaffen wo Cloud noch kein Thema war und in der heutigen Form nicht existierte, mit dem Ziel, lokale IT Systeme spezialisiert zu überwachen. SCOM hat keine andere Aufgabe als Monitoring, welche durch die langjährige Weiterentwicklung perfektioniert wurde.
OMS wurde in der Cloud geboren und ist im Verhältnis ein junges Produkt. Geboren erst als Assessment Lösung, dann erweitert als Daten Analyse und Management Tool, welches die Fähigkeit hat zu alarmieren falls ein Zustand von einem Konfigurierten Wert abweicht. OMS hat einen völlig anderen Architektur Ansatz als SCOM und auch einen anderen Hintergrund, Ziel und Zweck. Durch das Potential der Cloud und die moderne Architektur hat OMS ein nahezu grenzenloses Potential. Dieses reicht vom Verwalten von Cloud Ressourcen, zur Daten Analyse, bis hin zu Visualisierung und Alarmierung. Jedoch sind die Monitoring Möglichkeiten wie wir sie aus SCOM kennen noch in weiter Ferne. SCOM im Gegenzug ist fokussiert auf Monitoring, zeigt aber durch historisch bedingte Altlasten einer on-premise Lösung, Defizite für die moderne Cloud Infrastrukturen der heutigen Zeit. Somit kann man klar sagen OMS ist NICHT SCOM aus der Cloud, könnte es aber einmal werden. Beide Tools haben ihre Stärken in Bereichen die das andere Tool nicht hat, deshalb ist zum heutigen Zeitpunkt die Kombination beider Tools mittels Konnektoren der Ansatz den IT Abteilungen verfolgen sollten.

Autor: Microsoft MVP Stefan Roth

Juni 2017
M D M D F S S
« Mai    
 1234
567891011
12131415161718
19202122232425
2627282930