Teilen über


Planen eines Entwurfs für Verwaltungsgruppen

Übersicht

Eine Verwaltungsgruppe wird durch eine einzelne Betriebsdatenbank, einen oder mehrere Verwaltungsserver und einen oder mehrere überwachte Agents und Geräte identifiziert. Durch das Verbinden von Verwaltungsgruppen können Warnungen und andere Überwachungsdaten über eine einzelne Konsole angezeigt und bearbeitet werden. Aufgaben können auch von einer lokalen Verwaltungsgruppe initiiert werden, um auf den verwalteten Objekten einer verbundenen Verwaltungsgruppe ausgeführt zu werden.

Die einfachste Operations Manager-Implementierung ist eine einzelne Verwaltungsgruppe. Jede zusätzliche Gruppe erfordert mindestens einen eigenen Betriebsdatenbank‑ und Verwaltungsserver. Jede Gruppe muss zudem separat mit eigenen Konfigurationseinstellungen, Management Packs und Integration in andere Überwachungs‑ und ITSM-Lösungen verwaltet werden.

Diagramm eines Beispiel-MG-Einzelservers.

Die Implementierung der verteilten Verwaltungsgruppe bildet die Grundlage von 99 Prozent der Operations Manager-Bereitstellungen. Sie ermöglicht die Verteilung von Features und Diensten auf mehreren Servern, um Skalierbarkeit und Redundanz für einige dieser Features zu ermöglichen. Sie kann alle Operations Manager-Serverrollen enthalten und die Überwachung von Geräten über vertrauenswürdige Grenzen hinweg unter Verwendung des Gatewayservers unterstützen.

Das folgende Diagramm zeigt eine mögliche Option für die Topologie der verteilten Verwaltungsgruppe.

Diagramm eines Beispiel-OM, verteilter MG.

Hinweis

Es gibt keine direkte Kommunikation zwischen der Operations-Konsole und den Datenbanken. Die gesamte Kommunikation wird über Port TCP 5724 an einen bestimmten Verwaltungsserver und dann über OLE DB an Port TCP 1433 oder einen benutzerdefinierten Port, der von der SQL-Administration während der Einrichtung der SQL Server-Datenbank-Engine-Instanz angegeben wurde, an die Datenbankserver weitergeleitet. Es gibt jedoch eine direkte Kommunikation zwischen einer Anwendungsdiagnosekonsole (verbunden mit der Webkonsole) und dem SQL Server, der die Betriebs‑ und Data Warehouse-Datenbanken hostet.

Eine Verwaltungsgruppe, die Sie in Ihrer Umgebung bereitgestellt haben, kann in Microsoft Operations Management Suite (OMS) integriert werden, und durch die Verwendung von Log Analytics können Sie die Leistung, Ereignisse und Warnungen weiter korrelieren und visualisieren sowie entsprechend reagieren. So erhalten Sie eine erhöhte Sichtbarkeit, indem Sie angepasste Suchvorgänge über das gesamte Dataset hinweg durchführen können, um Daten zwischen Systemen und Anwendungen, lokal oder in der Cloud zu korrelieren.

Abbildung einer OM-Integration mit Microsoft OMS.

Die Integration mit Operations Manager erstreckt sich auf andere Produkte wie BMC Remedy, IBM, Netcool oder andere Unternehmensverwaltungslösungen, die von Ihrer Organisation verwendet werden. Weitere Informationen zur Planung der Interoperabilität mit diesen Lösungen finden Sie unter Integration in andere Verwaltungslösungen.

Verwaltungsgruppenkomponenten

Verwaltungsserver

In Operations Manager 2007 war der Stammverwaltungsserver (RMS) ein spezieller Verwaltungsserver in einer Verwaltungsgruppe und der erste Verwaltungsserver, der in einer Verwaltungsgruppe installiert wurde. Der RMS war der Fokuspunkt bei der Verwaltung der Verwaltungsgruppenkonfiguration, der Verwaltung und Kommunikation mit Agents sowie der Kommunikation mit der operativen Datenbank und anderen Datenbanken in der Verwaltungsgruppe. Der RMS diente auch als Ziel für die Betriebskonsole und das bevorzugte Ziel für die Webkonsolen. In System Center 2012 R2 – Operations Manager wurde die Rolle des Stammverwaltungsservers entfernt, und alle Verwaltungsserver sind jetzt Peers. Diese Konfiguration ist weiterhin in System Center 2016 – Operations Manager und höher vorhanden.

Der RMS ist kein Single Point of Failure mehr, da alle Verwaltungsserver die Dienste hosten, die zuvor nur vom RMS gehostet wurden. Rollen werden an alle Verwaltungsserver verteilt. Wenn ein Verwaltungsserver nicht verfügbar ist, werden seine Zuständigkeiten automatisch weiterverteilt. Eine RMS-Emulatorrolle bietet Abwärtskompatibilität für Management Packs, die für den RMS ausgerichtet sind. Wenn Sie keine Management Packs haben, die zuvor auf den RMS ausgerichtet waren, müssen Sie den RMS-Emulator nicht verwenden.

Die Verwaltungsgruppe kann mehrere Verwaltungsserver umfassen, um zusätzliche Kapazität und kontinuierliche Verfügbarkeit bereitzustellen. Werden einer Verwaltungsgruppe mindestens zwei Verwaltungsserver hinzugefügt, werden die Verwaltungsserver automatisch Teil der drei Standardressourcenpools, und die Arbeit wird über die Mitglieder des Pools verteilt. Für individuell definierte Ressourcenpools werden Mitglieder manuell hinzugefügt. Wenn ein Mitglied des Ressourcenpools ausfällt, wird die betreffende Workload von den anderen Mitgliedern übernommen. Wenn ein neuer Verwaltungsserver hinzugefügt wird, nimmt der neue Verwaltungsserver den vorhandenen Mitgliedern im Ressourcenpool automatisch einige der Arbeiten ab. Unter Überlegungen zum Entwurf von Ressourcenpools finden Sie weitere Informationen dazu, wie dies funktioniert, und die Empfehlungen, die Ihren Entwurfsplan beeinflussen.

Wenn ein Verwaltungsserver aus irgendeinem Grund nicht verfügbar ist, werden Agents, die auf ihn angewiesen sind, standardmäßig automatisch als Failover auf einen anderen Verwaltungsserver übertragen. Bei der Auswahl der Anzahl und Platzierung von Verwaltungsservern sollte diese Failover-Fähigkeit berücksichtigt werden, wenn Hochverfügbarkeit eine Anforderung ist.

Agents stellen eine Verbindung mit einem Verwaltungsserver her, um mit allen anderen Operations Manager-Komponenten zu kommunizieren. Einige der von einem Verwaltungsserver durchgeführten Arbeiten umfassen den Vorgang, die von Agents gesendeten Betriebsdaten zu übernehmen und in die betriebstechnische Datenbank und das Data Warehouse einzufügen.

Ein typischer Verwaltungsserver verarbeitet ca. 3.000 Agents. Die tatsächliche Serverleistung variiert je nach dem Umfang der gesammelten Betriebsdaten. Verwaltungsserver können jedoch in der Regel jeweils 3.000 Agents unterstützen, auch bei relativ umfassenden Betriebsdaten.

Es gibt keinen Grenzwert für die maximale Anzahl von Verwaltungsservern pro Verwaltungsgruppe. Es empfiehlt sich jedoch, möglichst wenige Verwaltungsserver zu verwenden, nachdem Skalierbarkeit, hohe Verfügbarkeit und Einschränkungen bei der Notfallwiederherstellung behoben wurden.

Verwaltungsserver sollten über eine gute Netzwerkkonnektivität mit der Operations Manager-Datenbank und dem Data Warehouse verfügen, da sie häufig große Datenmengen an diese Speicher senden. Im Allgemeinen verbrauchen diese SQL Server-Verbindungen mehr Bandbreite und sind anfälliger für die Netzwerklatenz. Daher sollten sich alle Verwaltungsserver im selben lokalen Netzwerk wie die Betriebsdatenbank und die Data Warehouse-Datenbank befinden und niemals über ein breites Netzwerk bereitgestellt werden. Es sollte weniger als 10 Millisekunden Latenz zwischen einem Verwaltungsserver und einer SQL Server-Instanz geben, die die Operations Manager-Datenbanken hosten.

Gatewayserver

Operations Manager erfordert eine gegenseitige Authentifizierung zwischen Agents und Verwaltungsservern, bevor zwischen diesen Informationen ausgetauscht werden. Der Prozess wird verschlüsselt, um den Authentifizierungsprozess zwischen den beiden zu sichern. Wenn sich der Agent und der Verwaltungsserver in derselben Active Directory-Domäne oder in Active Directory-Domänen befinden, die Vertrauensstellungen eingerichtet haben, verwenden sie Kerberos V5-Authentifizierungsmechanismen, bereitgestellt von Active Directory. Wenn die Agents und Verwaltungsserver nicht innerhalb der gleichen 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. Der Gatewayserver fungiert als Proxy zwischen den Agents und dem Verwaltungsserver. Ohne den Gatewayserver können die Agents weiterhin zertifikatbasierte Authentifizierung mit einem Verwaltungsserver durchführen, aber ein X.509-Zertifikat muss auf jedem Agent mit dem MOMCertImport.exe-Tool ausgestellt und installiert werden, und jeder benötigt Zugriff auf den Verwaltungsserver über die Firewall. Wenn sich die Agents in derselben Domäne wie der Gatewayserver oder in einer vertrauenswürdigen Domäne befinden, können sie die Kerberos-Authentifizierung verwenden. In diesem Fall benötigen nur der Gatewayserver und die verbundenen Verwaltungsserver Zertifikate. Dies umfasst die Überwachung von virtuellen Computern, die in der Microsoft Azure-Infrastructure-as-a-Service (IaaS) ausgeführt werden, mit Operations Manager (d. h. Hybrid-Cloud-Überwachung), die nicht demselben vertrauenswürdigen Bereich wie die Rollen, die die Operations Manager-Verwaltungsgruppe unterstützen, angehören, oder Sie haben Operations Manager in Azure IaaS (ein virtueller Computer mit SQL Server, der die Betriebsdatenbanken hostet, und einen oder mehrere virtuelle Computer, die die Verwaltungsserverrolle hosten) bereitgestellt und überwachen nicht vertrauenswürdige lokale Workloads.

Im Folgenden finden Sie ein Beispiel für die Operations Manager-Bereitstellungsüberwachung von Azure IaaS-Ressourcen.
Abbildung der OpsMgr-Überwachung von Azure-Ressourcen.

Nachfolgend sehen Sie ein Beispiel für die Operations Manager-Bereitstellung, die in Azure IaaS gehostet wird.
Abbildung von OpsMgr gehostet in Azure IaaS.

Normalerweise werden Gatewayserver nicht für die Verwaltung der Bandbreitennutzung verwendet, da das Gesamtvolumen der von Agents an einen Verwaltungsserver gesendeten Daten ähnlich ist, unabhängig davon, ob ein Gatewayserver verwendet wird oder nicht. Der beabsichtigte Zweck eines Gatewayservers ist es, 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 verringern, die über Firewalls zulässig sein müssen.

  • Die Verwendung von mehr als 2.000 Agents pro Gatewayserver kann sich negativ auf die Möglichkeit auswirken, bei einem dauerhaften Ausfall, der verhindert, dass der Gatewayserver mit dem Verwaltungsserver kommuniziert, entsprechende Wiederherstellungen auszuführen. Wenn mehr als 2.000 Agents erforderlich sind, werden mehrere Gatewayserver empfohlen. Die Alternative, wenn die Wiederherstellungszeit des Gatewayservers ein Problem darstellt, besteht darin, das System zu testen, um sicherzustellen, dass der Gatewayserver seine Warteschlange nach einem dauerhaften Ausfall zwischen dem Gatewayserver und dem Verwaltungsserver schnell leeren kann. Darüber hinaus werden nach dem Ausfüllen der eingehenden Warteschlange auf dem Gatewayserver Daten in der Warteschlange nach ihrer Priorität verworfen, was bedeutet, dass ein anhaltender Gatewayserverausfall in diesem Szenario zu Datenverlust führen könnte.
  • Wenn eine große Anzahl von Agents über Gatewayserver verbunden ist, sollten Sie einen dedizierten Verwaltungsserver für alle Gatewayserver verwenden. Wenn alle Gatewayserver eine Verbindung mit einem einzelnen Verwaltungsserver herstellen, ohne dass andere Agents damit verbunden sind, kann die Wiederherstellungszeit bei einem dauerhaften Ausfall beschleunigt werden. Die effektive Auslastung für den Verwaltungsserver ist die Gesamtzahl der Agents, die direkt oder über Gatewayserver an ihn berichten.
  • Um zu verhindern, dass der Gatewayserver die Kommunikation mit einem Verwaltungsserver initiiert, einschließlich wenn ein 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 kann.

Webkonsolenserver

Die Webkonsole stellt eine Schnittstelle zu der Verwaltungsgruppe bereit, auf die über einen Webbrowser zugegriffen werden kann. Sie verfügt nicht über die vollständige Funktionalität der Betriebskonsole und bietet nur Zugriff auf die Ansichten „Überwachen“ und „Mein Arbeitsbereich“. Die Webkonsole bietet Zugriff auf alle Überwachungsdaten und ‑aufgaben, bei denen es sich um Aktionen handelt, die auf überwachten Computern über die Betriebskonsole ausgeführt werden können. Der Zugriff auf Daten in der Webkonsole hat dieselben Einschränkungen wie der Zugriff auf Inhalte in der Betriebskonsole.

Berichtsserver

Die Berichterstattung für System Center – Operations Manager wird unter SQL Server Reporting Services (unterstützt von der von Ihnen verwendeten Version von Operations Manager) installiert. Die einzig gültige Reporting Services-Konfiguration, die von Operations Manager Reporting unterstützt wird, ist der native 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 derselben Instanz von SQL Server.

Die Operations Manager-Berichtsserver-Komponenten können auf demselben Server installiert werden, auf dem SQL Server 2014 oder 2016 Reporting Services ausgeführt wird, oder auf einem anderen Computer. Für eine optimale Leistung, insbesondere in einer Unternehmensumgebung mit einer hohen Anzahl an gleichzeitigen Berichterstellungen durch Benutzende, während interaktive oder geplante Berichte gleichzeitig verarbeitet werden, müssen Sie die Kapazität erhöhen, um mehr Benutzende zur gleichen Zeit und größere Berichtsausführungslasten zu bewältigen. Es wird empfohlen, dass sich die Operations Manager-Berichterstellung nicht auf demselben SQL Server befindet, auf dem die Data Warehouse-Datenbank gehostet wird und der 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 eine einzige Fehlerquelle für die Verwaltungsgruppe, sodass sie mithilfe unterstützter Clusteringkonfigurationen hoch verfügbar gemacht werden kann.

Um diese Datenbank in einer konsistenten Größe zu behalten, geben die Optimierungseinstellungen in Operations Manager die Dauer der Speicherung von Daten darin an. Standardmäßig beträgt diese Dauer sieben (7) Tage.

Reporting-Data Warehouse-Datenbank

Das Reporting-Data Warehouse ist eine SQL Server-Datenbank, die Betriebsdaten für die langfristige Berichterstattung sammelt und speichert. Diese Daten werden direkt aus Regeln geschrieben, die Daten zum Melden und aus Datensynchronisierungsprozessen in der Betriebsdatenbank sammeln. Die Wartung des Data Warehouse, einschließlich Aggregation, Pflege und Optimierung, erfolgt automatisch von Operations Manager.

In der folgenden Tabelle werden die Standarddatentypen und der Aufbewahrungszeitraum nach der Ersteinrichtung der Data Warehouse-Datenbank hervorgehoben.

Dataset Aggregationstyp Aufbewahrungszeitraum (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
Staat Raw 180
Staat Stündlich 400
Staat Täglich 400

Ein Data Warehouse kann mehrere Verwaltungsgruppen versorgen. Auf diese Weise kann ein einzelner Bericht Daten von allen Computern in der Organisation integrieren.

Wie bei der Operations Manager-Datenbank kann die Data Warehouse-Datenbank für Hochverfügbarkeit gruppiert werden. Wenn sie nicht gruppiert ist, sollte sie sorgfältig überwacht werden, damit alle Probleme schnell behoben werden können.

ACS-Collector

Der ACS-Collector empfängt und verarbeitet Ereignisse von ACS-Weiterleitungen und sendet diese Daten dann an die ACS-Datenbank. Diese Verarbeitung umfasst die Demontage der Daten, sodass sie über mehrere Tabellen innerhalb der ACS-Datenbank verteilt werden kann, wodurch Datenredundanz minimiert und Filter angewendet werden, sodass unnötige Ereignisse nicht der ACS-Datenbank hinzugefügt werden.

ACS-Datenbank

Die ACS-Datenbank ist das zentrale Repository für Ereignisse, die von einer Überwachungsrichtlinie innerhalb einer ACS-Bereitstellung generiert werden. Die ACS-Datenbank kann sich auf demselben Computer wie der ACS-Collector befinden, aber für eine optimale Leistung sollten beide jeweils auf einem dedizierten Server installiert werden. Standardmäßig werden die Daten für vierzehn (14) Tage aufbewahrt.

ACS-Weiterleitung

Der Dienst, der auf ACS-Weiterleitungen ausgeführt wird, ist im Operations Manager-Agent enthalten. Standardmäßig ist dieser Dienst installiert, aber nicht aktiviert, wenn der Operations Manager-Agent installiert ist. Sie können die Aufgabe „Überwachungssammlung aktivieren“ oder PowerShell verwenden, um diesen Dienst für mehrere Agentcomputer gleichzeitig zu aktivieren. Nachdem Sie diesen Dienst aktiviert haben, werden alle Sicherheitsereignisse zum lokalen Sicherheitsprotokoll und zusätzlich an den ACS-Collector gesendet.

Überlegungen zum Entwurf

Bei der Entscheidung, eine einzelne oder mehrere Verwaltungsgruppen zu implementieren, sollten die folgenden Faktoren berücksichtigt werden:

  • Erhöhte Kapazität. Operations Manager verfügt über keine integrierten Grenzwerte für die Anzahl der Agents, die eine einzelne Verwaltungsgruppe unterstützen kann. Abhängig von der verwendeten Hardware und der Überwachungslast (mehr bereitgestellte Management Packs sorgen für eine höhere Überwachungslast) für die Verwaltungsgruppe benötigen Sie möglicherweise mehrere Verwaltungsgruppen, um eine akzeptable Leistung zu gewährleisten.
  • Konsolidierte Ansichten. Wenn mehrere Verwaltungsgruppen verwendet werden, um eine Umgebung zu überwachen, ist ein Mechanismus erforderlich, um eine konsolidierte Ansicht der Überwachungs‑ und Warnungsdaten von diesen bereitzustellen. Dies kann durch die Bereitstellung einer zusätzlichen Verwaltungsgruppe (die möglicherweise Überwachungsverantwortung hat oder die möglicherweise keine Überwachungsverantwortung hat), die Zugriff auf alle Daten in allen anderen Verwaltungsgruppen hat, erreicht werden. Diese Verwaltungsgruppen werden dann als verbunden bezeichnet. Die Verwaltungsgruppe, die verwendet wird, um eine konsolidierte Ansicht der Daten bereitzustellen, wird als lokale Verwaltungsgruppe bezeichnet, und die anderen, die Daten bereitstellen, werden als verbundene Verwaltungsgruppen bezeichnet.
  • Sicherheit und Verwaltung. Partitionierungs-Verwaltungsgruppen für Sicherheit und Verwaltung ähneln vom Konzept her der Delegierung von Verwaltungsautorität über Active Directory-Organisationseinheiten oder ‑Domänen zu verschiedenen administrativen Gruppen. Ihr Unternehmen kann mehrere IT-Gruppen umfassen, die jeweils einen eigenen Zuständigkeitsbereich haben. Der Bereich kann ein bestimmtes geografisches Gebiet oder ein bestimmter Geschäftsbereich sein. Beispielsweise kann es sich bei einer Beteiligungsgesellschaft um eine der Tochtergesellschaften handeln. Dort, wo diese Art der vollständigen Delegierung der administrativen Autorität von der zentralen IT-Gruppe besteht, kann es nützlich sein, eine Verwaltungsgruppenstruktur in jedem der Bereiche zu implementieren. Dann können sie 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 derselben 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 mithilfe der japanischen Version bereitstellen. Wenn die Überwachung mehrere Sprachen umfassen muss, wird für jede Sprache der Operatoren eine zusätzliche Verwaltungsgruppe benötigt.
  • Production‑ und PreProduction-Funktionalität. In Operations Manager empfiehlt es sich, über eine Produktionsimplementierung zu verfügen, die für die Überwachung Ihrer Produktionsanwendungen verwendet wird, und über eine Vorproduktionsimplementierung zu verfügen, die minimale Interaktionen mit der Produktionsumgebung hat. Die Vorproduktions-Verwaltungsgruppe wird zum Testen und Optimieren der Management Pack-Funktionalität verwendet, bevor sie in die Produktionsumgebung migriert wird. Darüber hinaus beschäftigen einige Unternehmen eine Stagingumgebung für Server, in denen neu gebaute Server für eine Einarbeitungszeit platziert werden, bevor sie in die Produktion aufgenommen werden. Die Vorproduktions-Verwaltungsgruppe kann verwendet werden, um die Stagingumgebung zu überwachen und so die Integrität von Servern vor dem Produktionsrollout sicherzustellen.
  • Dedizierte ACS-Funktionalität. Wenn zu Ihren Anforderungen die Notwendigkeit gehört, Windows Audit Security-Protokollereignisse oder UNIX/Linux-Sicherheitsereignisse zu erfassen, implementieren Sie den Audit Collection Service (ACS). Es kann von Vorteil sein, eine Verwaltungsgruppe zu implementieren, die die ACS-Funktion ausschließlich unterstützt, wenn die Sicherheitsanforderungen Ihres Unternehmens festlegen, dass die ACS-Funktion von einer anderen Verwaltungsgruppe kontrolliert und verwaltet wird als der, die die restliche Produktionsumgebung verwaltet.
  • Notfallwiederherstellungsfunktionalität. In Operations Manager werden alle Interaktionen mit der Operations Manager-Datenbank in Transaktionsprotokollen aufgezeichnet, bevor sie für die Datenbank übernommen werden. Diese Transaktionsprotokolle können an einen anderen Server, der Microsoft SQL Server ausführt, gesendet und für eine Kopie der Operations Manager-Datenbank dort übernommen werden. Dieses Feature ist eine Option, um Redundanz der Operations Manager-Betriebsdatenbank zwischen zwei SQL-Servern in der gleichen Verwaltungsgruppe bereitzustellen. Wenn ein kontrolliertes Failover ausgeführt werden muss, benötigen die Verwaltungsserver in der Verwaltungsgruppe eine Registrierungsänderung, um auf den sekundären SQL Server zu verweisen und mit diesem zu kommunizieren. Es kann eine Failover-Verwaltungsgruppe bereitgestellt werden, die exakt der Konfiguration der primären Verwaltungsgruppe entspricht (Management Packs, Außerkraftsetzungen, Benachrichtigungsabonnements, Sicherheit usw.), und die Agents sind so konfiguriert, dass sie an beide Verwaltungsgruppen berichten. Wenn die primäre Verwaltungsgruppe in ihrer Gesamtheit aus irgendeinem Grund nicht mehr verfügbar ist, gibt es keine Downtime der Überwachungsumgebung. Diese Lösung stellt die Dienstkontinuität der Verwaltungsgruppe und den Nullverlust der Betriebsüberwachung sicher.

Planen Sie vor der Bereitstellung von System Center Operations Manager in einer Produktionsumgebung den Entwurf Ihrer Verwaltungsgruppe. In der Planungsphase verstehen Sie die IT-Dienstkomponenten (d. h. Infrastruktur und Anwendungsebene) und die Anzahl der Systeme und Geräte, die sie unterstützen, wie sie Ihre Prozesse für die Vorfall‑ und Problemverwaltung integrieren und unterstützen sowie wie Sie die Daten für verschiedene Vorfallseskalations-Unterstützungsebenen, Engineering, Service-Konsumenten und Verwaltung visualisieren.

Verbundene Verwaltungsgruppen

Für viele Unternehmen mit Servern an mehreren geografischen Standorten ist eine zentrale Überwachung dieser Server erforderlich. Die Konfiguration der verbundenen Verwaltungsgruppe, die in der nachstehenden Abbildung dargestellt ist, besteht aus einer Reihe von Workflowprozessen, die für die Erstellung einer hierarchischen Systemverwaltungsinfrastruktur konzipiert sind.

Diagramm des Beispiels für eine verbundene Verwaltungsgruppe

Diese Konfiguration kann verwendet werden, um eine zentrale Überwachung zu erreichen. Sie 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 das Verbinden von Operations Manager-Verwaltungsgruppen können zentrale Überwachungsfunktionen verwaltet werden, während gleichzeitig Folgendes ermöglicht wird:

  • Überwachung einer größeren Anzahl von verwalteten Objekten als mit einer einzelnen Verwaltungsgruppe möglich ist.
  • Aufteilung der Überwachungsaktivitäten nach logischen Unternehmenseinheiten, wie etwa „Marketing“, oder nach physischen Standorten, wie etwa „Rom“.

Beim Verbinden von Verwaltungsgruppen stellen Sie keine neuen Server bereit. Vielmehr gewähren Sie der lokalen Verwaltungsgruppe Zugriff auf die Warnungen und Ermittlungsinformationen in einer verbundenen Verwaltungsgruppe. So können Sie alle Warnungen und alle anderen Überwachungsdaten aus mehreren Verwaltungsgruppen in einer einzigen Betriebskonsole anzeigen und damit interagieren. Darüber hinaus können Sie Aufgaben auf den überwachten Computern der verbundenen Verwaltungsgruppen ausführen. Informationen zum Verbinden von Verwaltungsgruppen finden Sie unter Verbinden von Verwaltungsgruppen in Operations Manager.

Installierte Sprachen

Operations Manager-Verwaltungsgruppen unterstützen nur eine installierte Sprache. Wenn die gesamte IT-Umgebung, die Sie überwachen müssen, über mehr als eine installierte Sprache verfügt, wird pro Sprache eine separate Verwaltungsgruppe benötigt.