0
4. Juli 2017

OMS – Anbindung einer OnPremise Infrastruktur: Direct attached Agent versus SCOM attached Agent

Sie betreiben eine SCOM Managementgroup zum Monitoring Ihrer Serverinfrastruktur? Sie überlegen an einer Hybrid Bereitstellung mit Microsoft Operations Management Suite (OMS)? Sie sind verwirrt bezüglich der Möglichkeiten die Systeme an OMS anzubinden? Direct attached Agent oder SCOM attached Agent? OMS Onboarding ist einfach? Ja, aber lesen Sie zunächst meinen Blogpost, damit Sie von Anfang an die richtigen Entscheidungen treffen.


In diesem Blogpost möchte ich die Unterschiede von Direct attached Agents und SCOM attached Agents darstellen und bei der Entscheidung für die eine oder die andere Variante helfen. Außen vor bleiben Systeme in Azure, ich beschränke mich hier auf die Unterschiede bei der Anbindung einer OnPremise Infrastruktur an OMS.

Unterschied Direct attached Agent und SCOM attached Agent

Die Agent-Software auf den Systemen ist grundsätzlich die gleiche. Der Unterschied ist, ob der Agent über eine SCOM Managementgroup (SCOM MG) und/oder direkt mit einem OMS Workspace verbunden ist.
Hier die unterschiedlichen, möglichen Fälle:

  • Ist der Agent nur mit einer SCOM MG, diese aber nicht mit einem OMS Workspace verbunden, fließen natürlich auch keine Daten zu OMS.
  • Ist der Agent mit einer SCOM MG verbunden und diese mit einem OMS Workspace, dann fließen Daten sowohl direkt vom Agent (mehr Details weiter unten) als auch über die SCOM MG (also den SCOM Managementserver) zu OMS. Obwohl Daten direkt vom Agent zu OMS gesendet werden, ist es noch kein Direct attached Agent.
  • Ist der Agent direkt mit einem OMS Workspace verbunden, dann fließen alle Daten direkt zu OMS. Dabei kann der Agent zusätzlich auch noch mit einer SCOM MG verbunden sein, solange diese nicht mit einem OMS Workspace verbunden ist, fließen darüber auch keine Daten zu OMS. Folgender Screenshots zeigt die direkte Verbindung des Agents zu OMS.
Direct attached Agent
Direct attached Agent
  • Wird der Agent nun über beide Wege zum selben OMS Workspace verbunden, sendet der Agent die Daten zweimal. Einmal über die direkte Anbindung und einmal über die SCOM MG. Das führt zu doppelten Daten in OMS und sollte vermieden werden.

Solutions, die eine SCOM MG Connection voraussetzen

Die Tabelle hier gibt an, welche Solutions eine SCOM MG Connection benötigen. Dies sind lediglich folgende:

Alert Management (Operations Manager)
Diese Solution benötigt zwingend eine SCOM Management Group Connection, da Alert-Daten aus SCOM verarbeitet werden sollen.

Capacity management, jetzt Capacity and performance (Public Preview)
Die neue Solution Capacity and performance benötigt keine SCOM Management Group Connection mehr. Die vorherige Solution Capacity Management setzte noch eine solche Connection voraus und hatte auch noch die Abhängigkeit zu Virtual Machine Manager – SCOM und VMM mussten miteinander verbunden sein. Mit der neuen Solution sind diese Abhängigkeiten obsolet.

Es gibt derzeit keine weitere Solution, die eine SCOM Management Group Connection voraussetzt.

Vorteile einer SCOM MG Connection

Warum also überhaupt SCOM an OMS anbinden und nicht jeden Agent direkt?

Einfachheit
Es muss nur die Connection der SCOM MG zu OMS hergestellt werden. Die Systeme, deren Daten nach OMS gesendet werden sollen können über SCOM-Gruppen zentral verwaltet werden. Die bestehenden Agents auf allen Servern müssen nicht angefasst werden.

Zentralisierung
Die Verbindung zu OMS geht nur vom SCOM Management Server zu OMS – das stimmt aber so nicht ganz. Dazu unten mehr.

Updatemanagement
Die SCOM Agents können über die bekannten Mechanismen eines SCOMs up to date gehalten werden.

Vorteile einer Direct Connection

Nun muss man aber folgende „Nachteile“ kennen, um die Entscheidung für oder gegen eine SCOM MG Connection treffen zu können:

OMS Multihoming
Über eine SCOM MG Connection ist kein Multihoming der Agents möglich. Das bedeutet, dass eine SCOM MG nur an einen OMS Workspace angebunden werden kann. Ein Direct attached Agent kann ab Version 8.0.10879.0 an mehrere OMS Workspaces angebunden sein.

Solution Targeting (Public Preview)
Damit lassen sich Solutions auf Gruppen begrenzen und somit nur für einzelne Agents aktivieren. Dies bietet Flexibilität und Kostenersparnis. So kann man z.B. die Security Solution nur auf bestimmte Systeme beschränken und somit die Kosten reduzieren. Vorher wurde eine Solution, sobald Sie im OMS Workspace hinzugefügt wurde auf alle mit dem Workspace verbundenen Agents deployed und alle Agents sendeten die Daten zur Solution. Bei einer SCOM MG Connection greift dieses neue Feature nicht.

Zentralisierung
Auch wenn die Agents nur über eine SCOM MG Connection mit einem OMS Workspace verbunden sind, senden die Agents bestimmte Daten trotzdem direkt nach OMS. So werden z.B. Performance Counter und Security Eventlogs immer über den Agent direkt nach OMS und nie über die SCOM MG gesendet. Auch werden Heartbeats der über eine SCOM MG verbundenen Agents über die SCOM MG Connection und die Direct Connection gesendet.

Entscheidung für eine Variante ist wichtig

Nochmal der Hinweis:
Beides zusammen, also SCOM attached und Direct attached sollte man vermeiden. Dadurch kann es zu redundanten Daten in OMS kommen, die wohl nicht auf die Kosten schlagen (aber wer kann das in allen Fällen und zukünftig genau sagen?), die aber für Verwirrung sorgen, wenn man Agents doppelt im Workspace findet. Hierzu gibt dieser Artikel im Azure Feedback Forum Auskunft.
Auch in der Doku zur Service Map Solution wird vor doppelten Daten durch eine solche Konfiguration gewarnt.

Zusammenfassung

Es gilt also festzuhalten: Man sollte sich vor der Einführung von OMS Gedanken machen, wie man die Agents verbindet, Direct attached oder SCOM attached. Damit vermeidet man doppelte Daten in OMS und verwirrende Ergebnisse bei der Suche in OMS.

Mit Kenntnis dieser Hintergründe ist auch klar, dass jeder Agent mit OMS sprechen können muss, also eine Internetverbindung oder ein OMS Gateway braucht, sonst fehlen in OMS Daten, die man dort auf jeden Fall haben möchte (Performance Counter, Security Event Logs, …). Wer also den Punkt Zentralisierung über eine SCOM MG als den Grund angesehen hat, der wird enttäuscht, da die Konfiguration von Firewalls, Proxies und OMS Gateway obligatorisch ist.

Warum also nicht gleich alle Agents direkt anbinden und die SCOM MG Connection weg lassen? Ich bin mittlerweile der Meinung, das dies der bessere Weg ist. Schon heute ist man mit Direct attached Agents flexibler (Solution Targeting geht nur so) und dies wird zukünftig nicht weniger werden. Neue Solutions werden wahrscheinlich zuerst bzw. ausschließlich mit Direct attached Agents funktionieren. Sicher, der Aufwand zum Onboarding ist zunächst höher, ich muss alle Agents für die Direct Connection konfigurieren und das Updatemanagement der Agents neu überdenken. Aber der Aufwand lohnt sich aus meiner Sicht.

Empfehlung: Direct attached Agent

Mein empfohlenes Zielszenario sieht also so aus:

Zielarchitektur
Zielarchitektur

Gerne erwarte ich Ihre Kommentare, Gedanken und Anregungen zu dem Thema.

Schreiben Sie einen Kommentar

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.