Planen eines Entwurfs von Verwaltungsgruppen

Wichtig

Diese Version von Operations Manager hat das Ende des Supports erreicht. Es wird empfohlen, ein Upgrade auf Operations Manager 2022 durchzuführen.

Übersicht

Eine Verwaltungsgruppe besteht aus einer einzelnen Betriebsdatenbank, mindestens einem Verwaltungsserver und je mindestens einem überwachten Agent und Gerät. Durch Verbinden von Verwaltungsgruppen lassen sich Warnungen und andere Überwachungsdaten über eine einzige Konsole anzeigen und bearbeiten. Die lokale Verwaltungsgruppe kann auch die Ausführung von Tasks für verwaltete Objekten einer verbundenen Verwaltungsgruppe initiieren.

Die einfachste Operations Manager-Implementierung ist eine einzelne Verwaltungsgruppe. Jede weitere Gruppe benötigt mindestens eine eigene Betriebsdatenbank und einen Verwaltungsserver. Jede Gruppe muss separat verwaltet werden, mit eigenen Konfigurationseinstellungen, Management Packs und eigener Integration in andere Überwachungs- und ITSM-Lösungen.

Diagramm eines Beispiels für einen MG-Einzelserver.

Die Implementierung einer verteilten Verwaltungsgruppe bildet die Grundlage für 99 Prozent aller Operations Manager-Bereitstellungen. Eine solche Bereitstellung ermöglicht die Verteilung von Funktionen und Diensten auf mehrere Server und eine entsprechende Skalierbarkeit und Redundanz einiger dieser Funktionen. Sie kann alle Operations Manager-Serverrollen enthalten und unterstützt die Überwachung von Geräten über Vertrauensgrenzen hinweg mithilfe des Gatewayservers.

Im folgenden Diagramm finden Sie ein Beispiel für die Topologie einer verteilten Verwaltungsgruppe.

Diagramm eines beispielweises OM Distributed MG.

Hinweis

Es gibt keine direkte Kommunikation zwischen der Betriebskonsole und den Datenbanken. Die gesamte Kommunikation wird über TCP-Port 5724 an einen bestimmten Verwaltungsserver und dann über OLE DB auf TCP-Port 1433 (oder einem vom SQL-Administrator während der Einrichtung der SQL Server-Datenbank-Engine-Instanz angegebenen benutzerdefinierten Port) an die Datenbankserver geleitet. Es besteht jedoch eine direkte Kommunikation zwischen einer Anwendungsdiagnosekonsole (die mit der Webkonsole verknüpft ist) und dem SQL Server, die die Betriebs- und Data Warehouse-Datenbanken hosten.

Eine Verwaltungsgruppe, die Sie in Ihrer Umgebung bereitgestellt haben, kann in Microsoft Operations Management Suite (OMS) integriert werden. Mithilfe von Log Analytics können Sie Leistung, Ereignisse und Warnungen weiter korrelieren, visualisieren und darauf reagieren. Dadurch erhalten Sie mehr Transparenz, da Sie benutzerdefinierte Suchvorgänge im gesamten Dataset durchführen können, um Daten zwischen Systemen und Anwendungen zu korrelieren, die lokal oder in der Cloud gehostet werden.

Abbildung der OM-Integration mit Microsoft OMS.

Operations Manager lässt sich auch in andere Produkte integrieren, z. B. BMC Remedy und IBM Netcool sowie weitere Enterprise Management-Lösungen, die in Ihrer Organisation verwendet werden. Weitere Informationen zur Planung der Interoperabilität mit diesen Lösungen finden Sie unter Integration in andere Verwaltungslösungen.

Komponenten einer Verwaltungsgruppe

Verwaltungsserver

In Operations Manager 2007 war der Stammverwaltungsserver (Root Management Server, RMS) ein spezieller Typ von Verwaltungsserver in einer Verwaltungsgruppe. Dieser Server wurde als erster Verwaltungsserver in einer Verwaltungsgruppe installiert. Der RMS war der Dreh- und Angelpunkt für die Administration der Verwaltungsgruppenkonfiguration, die Verwaltung von die und Kommunikation mit Agents sowie die Kommunikation mit der Betriebsdatenbank und anderen Datenbanken in der Verwaltungsgruppe. Der RMS diente auch als Ziel für die Betriebskonsole als bevorzugtes Ziel für die Webkonsolen. In System Center 2012 R2 – Operations Manager wurde die Rolle des Stammverwaltungsservers entfernt und alle Verwaltungsserver sind jetzt als Peers implementiert. Diese Konfiguration wird in System Center 2016 – Operations Manager und höher weiterhin verwendet.

Der Stammverwaltungsserver stellt keine einzelne Fehlerquelle mehr dar, weil die Dienste, die zuvor nur auf dem Stammverwaltungsserver gehostet wurden, nun auf allen Verwaltungsservern gehostet werden. Die Rollen werden an alle Verwaltungsserver verteilt. Wenn ein Verwaltungsserver nicht verfügbar ist, werden die entsprechenden Aufgaben automatisch neu verteilt. Durch die Rolle des Stammverwaltungsserver-Emulators wird Abwärtskompatibilität für Management Packs ermöglicht, die auf den Stammverwaltungsserver gerichtet sind. Wenn Sie über keine Management Packs verfügen, die zuvor auf den RMS ausgerichtet sind, müssen Sie den RMS-Emulator nicht verwenden.

Mithilfe von mehreren Verwaltungsservern lassen sich bei einer Verwaltungsgruppe zusätzliche Kapazität und durchgehende Verfügbarkeit erzielen. Wenn einer Verwaltungsgruppe mindestens zwei Verwaltungsserver hinzugefügt werden, werden die Verwaltungsserver automatisch Teil der drei Standardressourcenpools, und die Arbeitsauslastung wird auf die Mitglieder des Pools verteilt. Bei benutzerdefinierten Ressourcenpools werden die Mitglieder manuell hinzugefügt. Wenn ein Mitglied des Ressourcenpools ausfällt, wird die betreffende Arbeitslast von den anderen Mitgliedern übernommen. Wenn ein neuer Verwaltungsserver hinzugefügt wird, übernimmt der neue Verwaltungsserver automatisch einen Teil der Arbeit von den vorhandenen Mitgliedern im Ressourcenpool. Weitere Informationen zu deren Funktionsweise und den Empfehlungen, die Ihren Entwurfsplan beeinflussen, finden Sie unter Überlegungen zum Entwurf von Ressourcenpools .

Wenn ein Verwaltungsserver aus irgendeinem Grund nicht verfügbar ist, wird für Agents, die diesem Server zugeordnet sind, standardmäßig automatisch ein Failover auf einen anderen Verwaltungsserver ausgeführt. Bei der Auswahl der Anzahl und Platzierung von Verwaltungsservern sollte diese Failoverfähigkeit berücksichtigt werden, wenn Hochverfügbarkeit erforderlich ist.

Agents stellen eine Verbindung mit einem Verwaltungsserver her, um mit allen anderen Operations Manager-Komponenten zu kommunizieren. Eine der Aufgaben, die ein Verwaltungsserver erfüllt, besteht darin, die von Agents gesendeten Betriebsdaten zu empfangen und in die Betriebsdatenbank und das Data Warehouse einzufügen.

Ein Verwaltungsserver verarbeitet in der Regel ca. 3.000 Agents. Die tatsächliche Serverleistung variiert je nach Umfang der gesammelten Betriebsdaten. Üblicherweise kann jeder Verwaltungsserver jedoch 3.000 Agents unterstützen, auch bei einer relativ großen Menge an Betriebsdaten.

Es gibt keine Begrenzung für die maximale Anzahl von Verwaltungsservern pro Verwaltungsgruppe. Es empfiehlt sich jedoch, so wenige Verwaltungsserver wie möglich zu verwenden, nachdem Skalierbarkeits-, Hochverfügbarkeits- und Notfallwiederherstellungseinschränkungen behoben wurden.

Verwaltungsserver sollten über eine gute Netzwerkverbindung zur Operations Manager-Datenbank und zum Operations Manager-Data Warehouse verfügen, da sie häufig große Datenmengen an diese Speicher senden. Diese SQL Server-Verbindungen verbrauchen meist mehr Bandbreite und sind empfindlicher gegenüber Netzwerklatenz. Daher sollten sich alle Verwaltungsserver im gleichen lokalen Netzwerk befinden wie die Betriebsdatenbank und die Data Warehouse-Datenbank. Sie sollten nicht in einem Fernnetz (WAN) bereitgestellt werden. Die Latenz zwischen einem Verwaltungsserver und der SQL Server-Instanz, die die Operations Manager-Datenbanken hostet, muss weniger als 10 Millisekunden betragen.

Gatewayserver

Operations Manager erfordert eine gegenseitige Authentifizierung zwischen Agents und Verwaltungsservern, bevor ein Informationsaustausch zwischen diesen Komponenten möglich ist. Damit das Authentifizierungsverfahren zwischen den beiden Komponenten sicher ausgeführt werden kann, erfolgt es verschlüsselt. Wenn sich Agent und Verwaltungsserver in der gleichen Active Directory-Domäne oder in Active Directory-Domänen befinden, zwischen denen Vertrauensbeziehungen eingerichtet wurden, können die durch Active Directory verfügbaren Kerberos V5-Authentifizierungsmechnismen verwendet werden. Wenn die Agents und Verwaltungsserver nicht innerhalb derselben Vertrauensgrenze liegen, müssen andere Mechanismen verwendet werden, um die Anforderung der sicheren gegenseitigen Authentifizierung zu erfüllen.

Gatewayserver werden verwendet, wenn eine Firewall die Agents von den Verwaltungsservern trennt oder wenn sich die Agents in einer separaten nicht vertrauenswürdigen Domäne befinden. Ein Gatewayserver fungiert als Proxy zwischen den Agents und dem Verwaltungsserver. Ohne Gatewayserver können die Agents weiterhin eine zertifikatbasierte Authentifizierung bei einem Verwaltungsserver durchführen. Hierfür muss aber ein X.509-Zertifikat ausgestellt und mit dem Tool „MOMCertImport.exe“ auf jedem Agent installiert werden. Darüber hinaus muss jeder Agent über die Firewall auf den Verwaltungsserver zugreifen können. Wenn sich die Agents in der gleichen Domäne wie der Gatewayserver oder in einer vertrauenswürdigen Domäne befinden, können sie die Kerberos-Authentifizierung verwenden. In diesem Fall sind Zertifikate nur für den Gatewayserver und die verbundenen Verwaltungsserver erforderlich. Dies umfasst die Überwachung von virtuellen Computern, die in Microsoft Azure Infrastructure-as-a-Service (IaaS) ausgeführt werden, mit Operations Manager (d. a. Hybrid Cloud Monitoring), das nicht demselben vertrauenswürdigen Bereich wie die Rollen, die die Operations Manager-Verwaltungsgruppe unterstützen, hinzugefügt wird, oder Sie haben Operations Manager in Azure IaaS bereitgestellt (ein virtueller Computer mit SQL Server hosten die operativen Datenbanken und mindestens einen virtuellen Computer, der die Verwaltungsserverrolle hostet) und überwachen nicht vertrauenswürdige lokale Workloads.

Im Folgenden finden Sie ein Beispiel für eine Operations Manager-Bereitstellung, in der Azure-IaaS-Ressourcen überwacht werden.
Abbildung von OpsMgr Monitoring Azure-Ressourcen.

Im Folgenden finden Sie ein Beispiel für eine in Azure-IaaS gehostete Operations Manager-Bereitstellung.
Abbildung von OpsMgr Hosted in Azure Iaas.

In der Regel werden Gatewayserver nicht zum Verwalten der Bandbreitennutzung verwendet, da das Gesamtvolumen der daten, die von Agents an einen Verwaltungsserver gesendet werden, ähnlich ist, unabhängig davon, ob ein Gatewayserver verwendet wird oder nicht. Der Zweck eines Gatewayservers besteht darin, den Aufwand für die Verwaltung von Zertifikaten für Agents in nicht vertrauenswürdigen Domänen zu verringern und die Anzahl der Kommunikationspfade zu reduzieren, die über Firewalls zugelassen werden müssen.

  • Die Verwendung von mehr als 2.000 Agents pro Gatewayserver kann sich negativ auf die Wiederherstellungsfähigkeit im Falle eines anhaltenden Ausfalls auswirken, der die Kommunikation des Gatewayservers mit dem Verwaltungsserver verhindert. Wenn mehr als 2.000 Agents erforderlich sind, empfiehlt sich die Verwendung mehrerer Gatewayserver. Wenn die Wiederherstellungszeit des Gatewayservers ein Problem darstellt, besteht die Alternative darin, das System zu testen, um sicherzustellen, dass der Gatewayserver seine Warteschlange nach einem anhaltenden Ausfall zwischen dem Gatewayserver und dem Verwaltungsserver schnell leeren kann. Bedenken Sie darüber hinaus Folgendes: Wenn die eingehende Warteschlange auf dem Gatewayserver voll ist, werden Daten in der Warteschlange gemäß ihrer Priorität verworfen. Daher kann ein längerer Ausfall des Gatewayservers in diesem Szenario zu Datenverlusten führen.
  • Wenn sehr Agents über Gatewayserver verbunden sind, sollten Sie die Verwendung eines dedizierten Verwaltungsservers für alle Gatewayserver in Erwägung ziehen. Wenn alle Gatewayserver eine Verbindung mit einem einzelnen Verwaltungsserver herstellen, mit dem keine anderen Agents verbunden sind, kann die Wiederherstellungszeit im Falle eines anhaltenden Ausfalls beschleunigt werden. Die effektive Last auf dem Verwaltungsserver ist die Gesamtzahl von Agents, die entweder direkt oder über Gatewayserver mit dem Verwaltungsserver kommunizieren.
  • Um zu verhindern, dass der Gatewayserver die Kommunikation mit einem Verwaltungsserver initiiert, auch wenn er für das Failover zwischen mehreren Verwaltungsservern für Hochverfügbarkeit konfiguriert ist, enthält das Gatewaygenehmigungstool das Befehlszeilenargument /ManagementServerInitiatesConnection. Dadurch kann Operations Manager die Sicherheitsrichtlinien von Kunden erfüllen, wenn Systeme in einer DMZ oder einer anderen Netzwerkumgebung bereitgestellt sind und die Kommunikation nur aus dem Intranet initiiert werden darf.

Webkonsolenserver

Die Webkonsole bietet eine Schnittstelle zur Verwaltungsgruppe, auf die über einen Webbrowser zugegriffen werden kann. Es verfügt nicht über die volle Funktionalität der Betriebskonsole und bietet nur Zugriff auf die Ansichten Überwachung und Mein Arbeitsbereich. Die Webkonsole bietet Zugriff auf alle Überwachungsdaten und -tasks, die Aktionen darstellen, die für überwachte Computer über die Betriebskonsole ausgeführt werden können. Der Zugriff auf Daten über die Webkonsole unterliegt den gleichen Einschränkungen wie der Zugriff auf Inhalte über die Betriebskonsole.

Berichtsserver

Die Berichterstellung für System Center – Operations Manager wird auf SQL Server Reporting Services installiert (die von der von Ihnen verwendeten Version von Operations Manager unterstützt wird), und die einzige gültige Konfiguration von Reporting Services, die von Operations Manager-Berichterstellung unterstützt wird, ist der systemeigene Modus.

Hinweis

Durch die Installation von System Center – Operations Manager Reporting Services werden die Sicherheit der SQL Reporting Services-Instanz und die rollenbasierte Sicherheit von Operations Manager integriert. Installieren Sie keine anderen Reporting Services Anwendungen in diesem instance des SQL Server.

Die Operations Manager-Berichtsserverkomponenten können auf dem gleichen Server installiert werden, auf dem SQL Server Reporting Services 2014 oder 2016 ausgeführt wird. Die Komponenten können auch auf einem anderen Computer installiert werden. Um eine optimale Leistung zu erzielen, insbesondere in einer Unternehmensumgebung mit hohem Volumen und paralleler Berichtsgenerierung durch Benutzer, während interaktive oder geplante Berichte gleichzeitig verarbeitet werden, müssen Sie hochskaliert werden, um mehr gleichzeitige Benutzer und größere Berichtsausführungslasten zu bewältigen. Es wird empfohlen, dass sich der Operations Manager-Berichterstellungsdienst nicht auf demselben SQL Server befindet, der die Data Warehouse-Datenbank hostt und auf einem dedizierten System installiert ist.

Betriebsdatenbank

Die Betriebsdatenbank ist eine SQL Server-Datenbank, die alle Betriebsdaten, Konfigurationsinformationen und Überwachungsregeln für eine Verwaltungsgruppe enthält. Die Operations Manager-Datenbank ist ein Single Point of Failure (SPOF) für die Verwaltungsgruppe und kann daher mithilfe unterstützter Clusterkonfigurationen hoch verfügbar gemacht werden.

Um Größe dieser Datenbank konsistent zu halten, geben die Bereinigungseinstellungen in Operations Manager an, wie lange die Daten in der Datenbank beibehalten werden können. Standardmäßig beträgt dieser Zeitraum 7 (sieben) Tage.

Reporting-Data Warehouse-Datenbank

Das Reporting-Data Warehouse ist eine SQL Server-Datenbank, die Betriebsdaten für eine langfristige Berichterstellung sammelt und speichert. Diese Daten werden direkt von Datensynchronisierungsvorgängen in der Betriebsdatenbank sowie von Regeln geschrieben, die Daten für die Berichterstellung sammeln. Die Verwaltung des Data Warehouse, einschließlich Aggregation, Bereinigung und Optimierung, wird automatisch von Operations Manager durchgeführt.

Die folgende Tabelle zeigt die Standarddatentypen und die standardmäßige Beibehaltungsdauer nach der anfänglichen Einrichtung der Data Warehouse-Datenbank.

Dataset Aggregationstyp Beibehaltungsdauer (in Tagen)
Warnung Raw 400
Clientüberwachung Raw 30
Clientüberwachung Täglich 400
Ereignisse Raw 100
Leistung Raw 10
Leistung Stündlich 400
Leistung Täglich 400
State Raw 180
State Stündlich 400
State Täglich 400

Ein Data Warehouse kann die Anforderungen mehrerer Verwaltungsgruppen verarbeiten. Daher kann ein einzelner Bericht Daten von allen Computern der gesamten Organisation enthalten.

Genau wie die Operations Manager-Datenbank kann die Data Warehouse-Datenbank gruppiert werden, um Hochverfügbarkeit zu erzielen. Wenn es sich nicht um ein Cluster handelt, sollte es sorgfältig überwacht werden, damit probleme schnell behoben werden können.

ACS-Sammlung

Die ACS-Sammlung empfängt und verarbeitet Ereignisse von ACS-Weiterleitungen und sendet diese Daten dann an die ACS-Datenbank. Diese Verarbeitung umfasst das Disassemblieren der Daten, sodass sie auf mehrere Tabellen innerhalb der ACS-Datenbank verteilt werden können, die Datenredundanz minimiert und Filter angewendet werden, sodass der ACS-Datenbank keine unnötigen Ereignisse hinzugefügt werden.

ACS-Datenbank

Die ACS-Datenbank ist das zentrale Repository für Ereignisse, die durch eine Überwachungsrichtlinie innerhalb einer ACS-Bereitstellung generiert werden. Die ACS-Datenbank kann sich auf demselben Computer befinden wie die ACS-Sammlung, doch für optimale Leistung sollten beide auf einem dedizierten Server installiert werden. Die Daten werden standardmäßig 14 (vierzehn) Tage lang beibehalten.

ACS-Weiterleitung

Der unter ACS-Weiterleitungen ausgeführte Dienst ist im Operations Manager-Agent enthalten. Dieser Dienst wird standardmäßig im Rahmen der Installation von Operations Manager-Agent installiert, aber nicht aktiviert. Mit dem Task „Überwachungssammlung aktivieren“ oder über PowerShell können Sie diesen Dienst für mehrere Agent-Computer gleichzeitig aktivieren. Nachdem Sie diesen Dienst aktiviert haben, werden alle Sicherheitsereignisse an die ACS-Sammlung gesendet, zusätzlich zum lokalen Sicherheitsprotokoll.

Überlegungen zum Entwurf

Bei der Entscheidung, ob eine einzelne oder mehrere Verwaltungsgruppen implementieren werden sollen, müssen folgende Faktoren berücksichtigt werden:

  • Erhöhte Kapazität. Operations Manager weist keine integrierten Beschränkungen bezüglich der Anzahl von Agents auf, die von einer einzelnen Verwaltungsgruppe unterstützt werden können. Je nach verwendeter Hardware und der Überwachungslast (eine größere Anzahl von Management Packs bedeutet eine höhere Last) in der Verwaltungsgruppe benötigen Sie möglicherweise mehrere Verwaltungsgruppen, um eine akzeptable Leistung zu gewährleisten.
  • Konsolidierte Ansichten. Wenn zur Überwachung einer Umgebung mehrere Verwaltungsgruppen verwendet werden, ist ein Mechanismus erforderlich, der eine konsolidierte Ansicht der Überwachungs- und Warnungsdaten aus diesen Gruppen bereitstellt. Dies lässt erreichen, indem Sie eine zusätzliche Verwaltungsgruppe bereitstellen (die Überwachungsaufgaben ausführen kann, aber nicht muss), die auf alle Daten in allen anderen Verwaltungsgruppen zugreifen kann. Diese Verwaltungsgruppen gelten als verbunden. Die Verwaltungsgruppe, die zum Bereitstellen der konsolidierten Datenansicht verwendet wird, wird als lokale Verwaltungsgruppe bezeichnet. Alle anderen Verwaltungsgruppen, die Daten für diese Gruppe bereitstellen, werden als verbundene Verwaltungsgruppen bezeichnet.
  • Sicherheit und Verwaltung. Das Partitionieren von Verwaltungsgruppen aus Sicherheits- und verwaltungstechnischen Gründen ähnelt dem Delegierung von Verwaltungsautorität über Active Directory-Organisationseinheiten oder -Domänen an verschiedene administrative Gruppen. Ihr Unternehmen kann mehrere IT-Gruppen einrichten, die jeweils über einen eigenen Zuständigkeitsbereich verfügen. Die Zuständigkeit kann für geografische Regionen oder Geschäftsbereiche gelten. Bei einer Beteiligungsgesellschaft kann es sich beispielsweise um eines der Tochterunternehmen handeln. Wenn diese Art der vollständigen Delegierung von Verwaltungsrechten der zentralen IT-Gruppe vorhanden ist, kann es nützlich sein, in jedem der Bereiche eine Verwaltungsgruppenstruktur zu implementieren. Diese Verwaltungsgruppen können als verbundene Verwaltungsgruppen für eine lokale Verwaltungsgruppe konfiguriert werden, die sich im zentralen IT-Rechenzentrum befindet.
  • Installierte Sprachen. Alle Server, auf denen eine Operations Manager-Serverrolle installiert ist, müssen in der gleichen Sprache installiert sein. Das heißt, Sie können den Verwaltungsserver nicht mit der englischen Version von Operations Manager 2012 R2 installieren und dann die Betriebskonsole mit der japanischen Version bereitstellen. Wenn die Überwachung mehrere Sprachen umfassen muss, ist für jede Sprache der Operatoren eine zusätzliche Verwaltungsgruppe erforderlich.
  • Produktions- und Vorproduktionsfunktionen. In Operations Manager wird empfohlen, eine Produktionsimplementierung zur Überwachung Ihrer Produktionsanwendungen und eine Vorproduktionsimplementierung mit minimaler Interaktion mit der Produktionsumgebung zu verwenden. Die Vorproduktionsverwaltungsgruppe wird zum Testen und Optimieren der Management Pack-Funktionalität verwendet, bevor sie in die Produktionsumgebung migriert wird. Darüber hinaus haben einige Unternehmen eine Stagingumgebung für Server eingerichtet, in der neu erstellte Server vor der Platzierung in der Produktionsumgebung eine Anlaufphase durchlaufen. Die Vorproduktionsverwaltungsgruppe kann verwendet werden, um die Stagingumgebung zu überwachen, um die Integrität der Server vor dem Produktionsrollout sicherzustellen.
  • Dedizierte ACS-Funktion. Wenn Ihre Anforderungen die Erfassung von Windows-Überwachungssicherheitsprotokollereignissen oder UNIX/Linux-Sicherheitsereignissen umfassen, implementieren Sie den Audit Collection Service (ACS). Wenn die ACS-Funktion aufgrund der Sicherheitsanforderungen in Ihrem Unternehmen von einer Verwaltungsgruppe gesteuert und verwaltet werden muss, die nicht gleichzeitig auch für den Rest der Produktionsumgebung zuständig ist, kann es von Vorteil sein, eine Verwaltungsgruppe zu implementieren, die ausschließlich die ACS-Funktion unterstützt.
  • Funktionen für die Notfallwiederherstellung. In Operations Manager werden alle Interaktionen mit der Operations Manager-Datenbank in Transaktionsprotokollen aufgezeichnet, bevor sie per Commit an die Datenbank übertragen werden. Diese Transaktionsprotokolle können an einen anderen Server gesendet werden, auf dem Microsoft SQL Server ausgeführt wird, und auf eine Kopie der Operations Manager-Datenbank dort gebunden werden. Diese Funktion ist eine Möglichkeit, zwischen zwei SQL Server-Instanzen in der gleichen Verwaltungsgruppe für Redundanz der Operations Manager-Betriebsdatenbank zu sorgen. Wenn ein kontrolliertes Failover ausgeführt werden muss, muss für die Verwaltungsserver in der Verwaltungsgruppe die Registrierung geändert werden, damit die Server auf die sekundäre SQL Server-Instanz verweisen und mit dieser kommunizieren. Es kann eine Failoververwaltungsgruppe bereitgestellt werden, die der genauen Konfiguration der primären Verwaltungsgruppe (Management Packs, Außerkraftsetzungen, Benachrichtigungsabonnements, Sicherheit usw.) entspricht, und die Agents sind für Berichte an beide Verwaltungsgruppen konfiguriert. Wenn die primäre Verwaltungsgruppe in ihrer Gesamtheit aus irgendeinem Grund nicht verfügbar ist, gibt es keine Ausfallzeiten der Überwachungsumgebung. Diese Lösung stellt die Dienstkontinuität der Verwaltungsgruppe und eine unterbrechungsfreie Überwachung sicher.

Bevor Sie System Center Operations Manager in einer Produktionsumgebung bereitstellen, sollten Sie den Entwurf Ihrer Verwaltungsgruppe planen. Verstehen Sie während der Planungsphase die IT-Dienstkomponenten (d. h. Infrastruktur und Anwendungsebene) und die Anzahl der Systeme und Geräte, die sie unterstützen, wie Sie Ihre Incident- und Problemverwaltungsprozesse integrieren und unterstützen und wie Sie die Daten für verschiedene Supportebenen für Die Eskalation von Vorfällen visualisieren, engineering, Service Consumer und Management.

Verbundene Verwaltungsgruppen

Viele Unternehmen mit Servern an mehreren geografischen Standorten benötigen eine zentrale Überwachung dieser Server. Die Konfiguration einer verbundenen Verwaltungsgruppe besteht – wie in der Abbildung unten zu sehen – aus einer Reihe von Workflowprozessen, die eine hierarchische Systemverwaltungsinfrastruktur aufbauen.

Diagramm des Beispiels für eine verbundene Verwaltungsgruppe.

Diese Konfiguration kann für eine zentrale Überwachung verwendet werden. Es wurde entwickelt, um die Anzeige von Warnungen und Überwachungsdaten zu unterstützen und Aufgaben für ein verwaltetes Objekt einer verbundenen Verwaltungsgruppe zu initiieren.

Durch die Verbindung von Operations Manager-Verwaltungsgruppen sorgen Sie für eine zentralisierte Überwachung und ermöglichen gleichzeitig Folgendes:

  • Überwachung einer größeren Anzahl verwalteter Objekte als mit einer einzigen Verwaltungsgruppe.
  • Aufteilung der Überwachungsaktivitäten nach logischen Geschäftseinheiten, z.B. „Marketing“, oder nach physischen Standorten, wie z.B. „Rom“.

Wenn Sie Verwaltungsgruppen verbinden, stellen Sie keine neuen Server bereit. Stattdessen gewähren Sie der lokalen Verwaltungsgruppe Zugriff auf die Warnungen und Ermittlungsinformationen, die sich in einer verbundenen Verwaltungsgruppe befinden. Auf diese Weise können Sie alle Warnungen und sonstigen Überwachungsdaten mehrerer Verwaltungsgruppen über eine Betriebskonsole einsehen und entsprechende Maßnahmen ergreifen. Überdies können Sie auf den überwachten Computern der verbundenen Verwaltungsgruppen Tasks ausführen. Um zu erfahren, wie Sie Verwaltungsgruppen verbinden, gehen Sie unter Connecting Management Groups in Operations Manager (Verbinden von Verwaltungsgruppen in Operations Manager).

Installierte Sprachen

Operations Manager-Verwaltungsgruppen unterstützen nur eine installierte Sprache. Wenn in der IT-Gesamtumgebung, die Sie überwachen müssen, mehrere Sprachen installiert sind, wird für jede Sprache ein eigener Verwaltungsserver benötigt.