Abbilden der Anforderungen in einem Entwurf für Operations Manager 2007

  • Artikel

Letzte Aktualisierung: August 2010

Betrifft: Operations Manager 2007 R2, Operations Manager 2007 SP1

Abbilden von Anforderungen in einem Entwurf

Im vorausgehenden Abschnitt haben Sie die folgenden drei Aufgaben abgeschlossen:

  • Sie haben die betrieblichen Anforderungen zusammengestellt, mit deren Hilfe Sie planen, welche Operations Manager-Features zu implementieren sind.

  • Sie haben die IT-Anforderungen zusammengestellt, die Ihnen bei der Entscheidung für die Verwaltungsgruppentopologie helfen.

  • Sie haben ermittelt, wie in Ihrem Unternehmen derzeit Überwachungsaktivitäten abgewickelt werden, um planen zu können, wie Operations Manager zu konfigurieren ist.

In diesem Abschnitt werden die Entwurfsentscheidungen erläutert, mit deren Hilfe Sie all diese gesammelten Informationen und Erkenntnisse in einem konkreten Entwurf abbilden. Hierbei werden bewährte Methoden angewendet, um die Ausstattung und Kapazität im Hinblick auf Serverrollen und Komponenten zu planen. Dazu gehören Überwachungssammeldienste (ACS), Stammverwaltungsserver, Ausnahmeüberwachung ohne Agents (AEM), Gatewayserver, Sammelüberwachung von Clients.

Verwaltungsgruppenentwurf

Alle Implementierungen von Operations Manager 2007 bestehen aus mindestens einer Verwaltungsgruppe. Angesichts der Skalierbarkeit von Operations Manager 2007 ist eine einzige Verwaltungsgruppe für manche Implementierungen vollkommen ausreichend. Je nach den Anforderungen des Unternehmens werden eventuell gleich zu Beginn weitere Verwaltungsgruppen benötigt oder können im Laufe der Zeit hinzugefügt werden. Den Prozess der Aufteilung von Operations Manager-Diensten auf mehrere Verwaltungsgruppen nennt man Partitionierung.

In diesem Abschnitt werden die allgemeinen Kriterien vorgestellt, die für mehrere Verwaltungsgruppen sprechen. Die Planung der Zusammensetzung einzelner Verwaltungsgruppen, z. B. Festlegen der Serverausstattung und Verteilung der Operations Manager-Rollen unter den Servern einer Verwaltungsgruppe, wird im Abschnitt "Zusammensetzung von Verwaltungsgruppen" behandelt.

Eine Verwaltungsgruppe

Gehen Sie die Planung für die Operations Manager-Verwaltungsarbeit mit der gleichen Haltung an, wie die Planung Ihrer Active Directory-Domäne: Beginnen Sie mit einer Verwaltungsgruppe, und fügen Sie weitere Gruppen nach Bedarf hinzu. Für die Auslegung einzelner Operations Manager 2007 R2-Verwaltungsgruppen gelten folgende empfohlene Grenzwerte:

  • 3.000 Agents können an einen Verwaltungsserver Bericht erstatten.

  • Die meisten Anforderungen im Hinblick auf Skalierbarkeit, Redundanz und Notfallwiederherstellung können mit drei bis fünf Verwaltungsservern in einer Gruppe erfüllt werden

  • 50 gleichzeitig geöffnete Betriebskonsolen

  • 1.500 Agents können an einen Gatewayserver Bericht erstatten.

  • 25.000 Computer können zur Anwendungsfehlerüberwachung (AEM) an einen dedizierten Verwaltungsserver Bericht erstatten.

  • 100.000 AEM-Computer können an eine dedizierte Verwaltungsgruppe Bericht erstatten.

  • 2.500 Sammelüberwachungs-Agents können an einen Verwaltungsserver Bericht erstatten.

  • 10.000 Sammelüberwachungs-Agents können an eine Verwaltungsgruppe Bericht erstatten.

  • Insgesamt 6.000 Agents und UNIX- oder Linux-Computer pro Verwaltungsgruppe mit 50 offenen Konsolen

  • Insgesamt 10.000 Agents und UNIX- oder Linux-Computer pro Verwaltungsgruppe mit 25 offenen Konsolen

  • Pro dediziertem Verwaltungsserver können 500 UNIX- oder Linux-Computer überwacht werden.

  • Pro dediziertem Gateway können 100 UNIX- oder Linux-Computer überwacht werden.

  • Pro dediziertem Verwaltungsserver können 3.000 URLs überwacht werden

  • Pro dedizierter Verwaltungsgruppe können 12.000 URLs überwacht werden.

  • Pro Agent können 50 URLs überwacht werden.

Klicken Sie auf diesen Link, um die empfohlenen Grenzwerte für Operations Manager 2007 SP1 anzuzeigen.

Angesichts dieser Grenzwerte in Verbindung mit den Sicherheitsbereichen, die durch die Verwendung von Operations Manager-Rollen für die Kontrolle des Datenzugriffs geboten werden, bietet eine einzelne Verwaltungsgruppe eine hohe Skalierbarkeit, die für viele Situationen ausreicht.

Partitionierung und mehrere Verwaltungsgruppen

Unabhängig von der Skalierbarkeit einer Verwaltungsgruppe benötigen Sie mehrere Verwaltungsgruppen, wenn eines der folgenden Szenarien zu Ihren Anforderungen gehört:

  • Produktions- und Vorbereitungsfunktionalität: In Operations Manager empfiehlt es sich, eine Produktions- und eine separate Vorbereitungsimplementierung zu haben. Erstere wird zur Überwachung der Produktionsanwendungen eingesetzt wird, letztere weist nur minimale Interaktion mit der Produktionsumgebung auf. Die Verwaltungsgruppe der Vorbereitungsumgebung wird für das Testen und Optimieren der Management Pack-Funktionalität vor dessen Übernahme in die Produktionsumgebung verwendet. Darüber hinaus verwenden manchen Unternehmen eine Bereitstellungsumgebung für Server, in der neue Server für eine Anlaufperiode eingesetzt werden, bevor sie in der Produktion zum Einsatz kommen. Die Vorbereitungs-Verwaltungsgruppe kann zur Überwachung der Anlaufumgebung verwendet werden, um die Integrität der Server vor dem Produktionseinsatz zu gewährleisten.

  • Dedizierte ACS-Funktionalität: Wenn gemäß Ihrer Anforderungen die Protokollereignisse der Windows-Sicherheitsüberwachung gesammelt werden müssen, implementieren Sie den Überwachungssammeldienst (ACS, Audit Collection Service). Es kann nützlich sein, eine Verwaltungsgruppe zu implementieren, die ausschließlich die ACS-Funktion unterstützt, wenn die Sicherheitsanforderungen Ihres Unternehmens vorschreiben, dass die ACS-Funktion von einer eigenen Verwaltungsgruppe kontrolliert und verwaltet werden, die nicht mit der Verwaltung der restlichen Produktionsumgebung befasst ist.

  • Notfallwiederherstellungsfunktionalität: In Operations Manager 2007 werden alle Interaktionen mit den OperationsManager-Datenbanken in Transaktionsprotokollen erfasst, bevor Änderungen in die Datenbank übernommen werden. Diese Transaktionsprotokolle können an einen anderen Server unter Microsoft SQL Server 2005 SP1 oder neuer bzw. Microsoft SQL Server 2008 SP1 übermittelt und dort in eine Kopie der OperationsManager-Datenbank übernommen werden. Diese Technik nennt man Protokollversand. Die Ziel- oder Failover-Verwaltungsgruppe muss keine voll aufgefüllte und aktive Verwaltungsgruppe sein. Sie kann lediglich aus einem Stammverwaltungsserver (RMS) und einem Server unter SQL Server 2005 SP1 oder neuer bzw. SQL Server 2008 SP1 bestehen. Wenn ein Failover ausgeführt werden muss, ist für die verbleibenden Verwaltungsserver der Ausgangsverwaltungsgruppe eine Registrierungsänderung sowie ein Neustart erforderlich, damit sie als Mitglieder der Failover-Verwaltungsgruppe aktiv werden.

  • Kapazitätssteigerung: Operations Manager 2007 verfügt über keine integrierten Grenzwerte in Bezug auf die Anzahl der Agents, die eine einzelne Verwaltungsgruppe unterstützen kann. Je nach verwendeter Hardware und Überwachungsvolumen (je mehr Management Packs bereitgestellt werden, um so höher das Überwachungsvolumen) in der Verwaltungsgruppe werden eventuell mehrere Verwaltungsgruppen benötigt, um eine annehmbare Leistung zu gewährleisten.

  • Konsolidierte Ansichten: Wenn mehrere Verwaltungsgruppen zur Überwachung einer Umgebung verwendet werden, wird ein Mechanismus benötigt, um konsolidierte Ansichten der Überwachungs- und Warnungsdaten aller Gruppen zu liefern. Dies kann durch die Bereitstellung einer weiteren Verwaltungsgruppe erzielt werden (der ggf. eigene Überwachungsaufgaben zugewiesen werden können), die auf alle Daten in allen anderen Verwaltungsgruppen Zugriff hat. Diese Verwaltungsgruppen werden dann als verbunden bezeichnet. Die Verwaltungsgruppe, die eine konsolidierte Ansicht der Daten liefert, nennt man die lokale Verwaltungsgruppe, die anderen, die die Daten liefern, sind die verbundenen Verwaltungsgruppen.

  • Installierte Sprachen: Für alle Server, auf denen eine Operations Manager-Serverrolle installiert ist, muss die gleiche Sprache verwendet werden. Das heißt, dass Sie nicht auf dem Stammverwaltungsserver die englische Version von Operations Manager 2007 und auf der Betriebskonsole die japanische Version verwenden können. Wenn sich die Überwachungsanforderungen auf mehrere Sprachen erstrecken, muss für jede erforderliche Sprache eine zusätzliche Verwaltungsgruppe eingerichtet werden.

  • Sicherheit und Administration: Die Partitionierung von Verwaltungsgruppen aus Gründen der Sicherheit und der Administration entspricht dem Konzept nach stark der Delegierung administrativer Befugnisse über Active Directory-Organisationseinheiten oder Domänen an unterschiedliche administrative Gruppen. Möglicherweise gibt es in Ihrem Unternehmen mehrere IT-Gruppen, die jeweils einen eigenen Verantwortlichkeitsbereich haben. Dieser richtet sich eventuell nach der geografischen Lage oder nach Geschäftsbereichen. Beispielsweise kann dies bei einer Holding eine der Konzerngesellschaften sein. Wenn diese Art der kompletten Delegierung administrativer Befugnisse von der zentralen IT-Gruppe vorliegt, empfiehlt es sich möglicherweise, in jedem Bereich eigene Verwaltungsgruppenstrukturen einzurichten. Diese können dann als verbundene Verwaltungsgruppe mit einer lokalen Verwaltungsgruppe konfiguriert werden, deren Sitz sich im Rechenzentrum der zentralen IT-Organisation befindet.

Mithilfe der vorgestellten Szenarien sollte Sie sich ein klares Bild von der Anzahl der benötigten Verwaltungsgruppen in Ihrer Operations Manager-Infrastruktur machen können. Im nächsten Abschnitt werden die Verteilung der Serverrollen in einer Verwaltungsgruppe und die Ausstattungsanforderungen der betreffenden Systeme erläutert.

Zusammensetzung von Verwaltungsgruppen

Für die Anordnung der Operations Manager-Serverkomponenten in einer Verwaltungsgruppe gibt es wenige Einschränkungen. Sie können alle auf demselben Server installiert werden (mit Ausnahme der Gatewayserverrolle), oder sie können in unterschiedlichen Kombinationen über mehrere Server verteilt werden. Manche Rollen können in einen Clusterdienst-Failovercluster (früher auch MSCS-Failovercluster) installiert werden, um hohe Verfügbarkeit zu gewährleisten, und es können mehrere Verwaltungsserver installiert werden, um Agents ein Failover untereinander zu ermöglichen. Sie müssen anhand Ihrer IT-Anforderungen und der angestrebten Optimierungsziele entscheiden, wie die Operations Manager-Serverkomponenten aufgeteilt und welche Serverarten verwendet werden.

Serverrollenkompatibilität

Eine Operations Manager 2007-Verwaltungsgruppe kann vielfältige Dienste bereitstellen. Diese Dienste können auf bestimmte Server verteilt werden, wodurch die Server für spezielle Rollen klassifziert werden. Nicht alle Serverrollen und Dienste können nebeneinander bestehen. In der folgenden Tabelle werden die Kompatibilitäten und Abhängigkeiten aufgeführt. Daneben wird angegeben, ob die Rolle auf einem Failovercluster installiert werden kann:

Serverrolle Kompatibel mit anderen Rollen Anforderungen Kann in ein Quorum-Failovercluster eingefügt werden

Betriebsdatenbank

Ja

SQL

Ja

Überwachungssammeldienste-Datenbank (ACS)

Ja

SQL

Ja

Datenbank des Berichterstattungs-Data Warehouses

Ja

SQL

Ja

Berichterstattung

Ja

Dedizierte SQL Server Reporting Services-Instanz; nicht auf Domänencontroller

Nein

Stammverwaltungsserver

Ja

Nicht kompatibel mit Verwaltungsserver- oder Gatewayserverrolle

Ja

Verwaltungsserver

Ja

Nicht kompatibel mit Stammverwaltungsserver

Nein

Verwaltungskonsole

Ja

Windows XP, Windows Vista, Windows Server 2003 und Windows Server 2008

Nicht zutreffend

ACS-Sammlung

Ja

Kann mit Gatewayserver und Überwachungsdatenbank kombiniert werden

Nein

Gatewayserver

Ja

Kann nur mit ACS-Sammlungskomponente kombiniert werden; muss Domänenmitglied sein

Nein

Webkonsolenserver

Ja

 

Nicht zutreffend

Agent

Ja

Wird automatisch auf dem Stammverwaltungsserver und dem Verwaltungsserver in einer Verwaltungsgruppe bereitgestellt

Nicht zutreffend

Alle hier abgegebenen Empfehlungen basieren auf den folgenden Annahmen:

  • Die Zahlen zum Datenträgersubsystem basieren auf Laufwerken, die durchgängig 125 wahlfreie E/A-Vorgänge pro Sekunde pro Laufwerk vollziehen können. Viele Laufwerke können höhere E/A-Raten durchhalten, sodass insgesamt weniger Laufwerke in der Konfiguration erforderlich sind.

  • In Verwaltungsgruppen, in denen neben dem Stammverwaltungsserver noch Verwaltungsserver bereitgestellt sind, müssen alle Agents die Verwaltungsserver als Primär- und Sekundärverwaltungsserver verwenden und kein Agent darf den Stammverwaltungsserver als Primär- oder Sekundärverwaltungsserver verwenden.

  • Bei den Richtlinien für die Überwachung ohne Agent wird von ungefähr einem bis zwei Ausfällen pro Computer pro Woche ausgegangen, bei einer Durchschnittsgröße der CAB-Dateien von 500 KB.

  • Die Clientsammelüberwachung enthält nur standardmäßige clientspezifische Management Packs, einschließlich Windows Vista-, Windows XP- und Information Worker-Management Packs.

  • Die Netzwerkverbindungen zwischen Agents und Servern verfügen über eine Kapazität von 100 MBit/s oder mehr.

Verfügbarkeit

Der Bedarf für hohe Verfügbarkeit der Datenbanken, des Stammverwaltungsservers, der Verwaltungs- und Gatewayserver kann durch einen redundanten Aufbau der Verwaltungsgruppe befriedigt werden.

  • Datenbank: Alle in Operations Manager 2007 verwendeten Datenbanken benötigen Microsoft SQL Server 2005 SP1 oder neuer bzw. Microsoft SQL Server 2008 SP1 oder neuer. Diese Datenplattformen können in einer MSCS-Quorumknoten-Failoverkonfiguration installiert werden.

    Hinweis

    Weitere Informationen zu Clusterdiensten finden Sie in der Online-Hilfe zu Windows Server 2003 und Windows Server 2008.

  • Stammverwaltungsserver: Der System Center-Datenzugriffsdienst und der System Center-Verwaltungskonfigurationsdienst können nur auf dem Stammverwaltungsserver ausgeführt werden und stellen somit eine zentrale Fehlerquelle in der Verwaltungsgruppe dar. Aufgrund der kritischen Rolle, die der Stammverwaltungsserver spielt, empfiehlt es sich, den Stammverwaltungsserver in seinem eigenen Failovercluster mit zwei Knoten zu installieren, falls hohe Verfügbarkeit zu Ihren Anforderungen gehört. Vollständige Details zur Clusterinstallation des Stammverwaltungsservers finden Sie im Operations Manager 2007-Bereitstellungshandbuch.

  • Verwaltungsserver: In Operations Manager können Agents einer Verwaltungsgruppe Berichte an jeden Verwaltungsserver liefern, der der gleichen Gruppe angehört. Daher wird durch mehrere verfügbare Verwaltungsserver für redundante Pfade für die Agent-/Serverkommunikation gesorgt. Es empfiehlt sich in diesem Fall, neben dem Stammverwaltungsserver einen oder zwei Verwaltungsserver bereitzustellen und den Agentzuordnungs- und Failover-Assistenten zu verwenden, um die Agents den Verwaltungsservern zuzuordnen und den Stammverwaltungsserver von der Handhabung von Agents auszuschließen.

  • Gatewayserver: Gatewayserver dienen der Kommunikationsvermittlung zwischen Verwaltungsservern und Agents, die außerhalb der Kerberos-Vertrauensgrenzen der Verwaltungsserver liegen. Ein Failover von Agents zwischen Gatewayservern ist ebenso möglich wie zwischen Verwaltungsservern, wenn jeweils die Kommunikation mit dem Primärserver unterbrochen wird. Gleichermaßen können Gatewayserver für ein Failover zwischen Verwaltungsservern konfiguriert werden, sodass für alle Pfade zwischen Agents und Verwaltungsservern Redundanz besteht. Vorgehensweisen zur Bereitstellung einer solchen Konfiguration finden Sie im Operations Manager 2007-Bereitstellungshandbuch.

Kosten

Je stärker die Verwaltungsgruppenserverrollen verteilt sind, um so mehr Ressourcen werden zur Unterstützung der betreffenden Konfiguration benötigt. Hierzu gehören Verwaltungskosten für Hardware, Infrastruktur, Lizenzierung, Betrieb und Wartung. Wenn die Kostenkontrolle als Optimierungsziel für die Systemgestaltung verwendet wird, läuft das auf eine Einzelserverimplementierung oder eine minimale Rollenverteilung hinaus, was sich wiederum auf die Redundanz und somit potenziell auf die Leistung auswirkt.

Leistung

Wenn die Leistung als Optimierungsziel verwendet wird, ist mit einem besseren Ergebnis zu rechnen, das auf einer stärker verteilten Konfiguration und Higher-End-Hardware aufbaut. Entsprechend steigen die Kosten.

Konsolenverteilung und Standort der Zugriffspunkte

Die Betriebskonsole kommuniziert direkt mit dem Stammverwaltungsserver und dem Berichtsserver, sofern die Berichtskomponente installiert ist. Daher ist die Entscheidung über den Standort von Stammverwaltungsserver und Datenbankservern in Bezug auf die Betriebskonsole kritisch für die Leistung. Stellen Sie sicher, dass diese Komponenten im Netzwerk nah beieinander liegen.

Empfohlene Komponentenverteilung und Plattformausstattung

In den Tabellen unten werden Empfehlungen in Bezug auf die Komponentenverteilung und die Plattformausstattung für Operations Manager 2007 R2 aufgeführt. Klicken Sie auf diesen Link, um Empfehlungen zur Komponentenverteilung und Plattformausstattung für Operations Manager 2007 SP1 anzuzeigen. Hierbei gilt: DB ist ein SQL-Datenbankserver, DW ist ein SQL-Datenbankserver, RS ist der Reporting Server, RMS ist der Stammverwaltungsserver und MS ist ein Verwaltungsserver. Informationen zum grundlegenden ACS-Entwurf und zur Planung finden Sie weiter unten in dieser Veröffentlichung.

Einzelserver, Universalszenario

Anzahl überwachter Geräte Serverrollen/Konfiguration

15 bis 250 Windows-Computer, 200 UNIX- oder Linux-Computer

DB, DW, RS, RMS;

RAID 0+1 mit 4 Datenträgern, 8 GB RAM, Quadprozessor

Mehrere Server, kleines Szenario

Anzahl überwachter Geräte Serverrollen/Konfiguration Serverrollen/Konfiguration

250 bis 500 Windows-Computer, 500 UNIX- oder Linux-Computer

DB, DW, RS;

RAID 0+1 mit 4 Datenträgern, 4 GB RAM, Dualprozessor

RMS;

RAID 1 mit 2 Datenträgern, 4 GB RAM, Dualprozessor

Mehrere Server, mittleres Szenario

Um für Redundanz zu sorgen, können Sie mehrere Verwaltungsserver bereitstellen, die jeweils die beschriebene Mindestkonfiguration aufweisen. Wenn Sie bei Datenbank- und Stammverwaltungsserver für hohe Verfügbarkeit sorgen möchten, können Sie diese in einem Cluster bereitstellen, wobei jeder Knoten die beschriebene Mindestkonfiguration sowie Verbindungen zu einem extern freigegebenen Datenträger für Clusterressourcen aufweist.

Anzahl überwachter Geräte Serverrolle/Konfiguration Serverrolle/Konfiguration Serverrolle/Konfiguration Serverrolle/Konfiguration

500 bis 750 Windows-Computer, 500 UNIX- oder Linux-Computer

DB;

RAID 0+1 mit 4 Datenträgern, 4 GB RAM, Dualprozessor

MS;

RAID 1 mit 2 Datenträgern, 4 GB RAM, Dualprozessor

DW, RS;

RAID 0+1 mit 4 Datenträgern (Daten), RAID 1 mit 2 Datenträgern (Protokolle), 4 GB RAM, Dualprozessor

RMS;

RAID 1 mit 2 Datenträgern, 8 GB RAM, Dualprozessor

Mehrere Server, großes Szenario

Um für Redundanz zu sorgen, können Sie mehrere Verwaltungsserver bereitstellen, die jeweils die beschriebene Mindestkonfiguration aufweisen. Wenn Sie bei Datenbank- und Stammverwaltungsserver für hohe Verfügbarkeit sorgen möchten, können Sie diese in einem Cluster bereitstellen, wobei jeder Knoten die beschriebene Mindestkonfiguration sowie Verbindungen zu einem extern freigegebenen Datenträger für Clusterressourcen aufweist.

Anzahl überwachter Geräte Serverrolle/Konfiguration Serverrolle/Konfiguration Serverrolle/Konfiguration Serverrolle/Konfiguration Serverrolle/Konfiguration

750 bis 1000 Windows-Computer, Unix- oder Linux-Computer

DB;

RAID 0+1 mit 4 Datenträgern (Daten), RAID 1 mit 2 Datenträgern (Protokolle), 8 GB RAM, Dualprozessor

DW;

RAID 0+1 mit 4 Datenträgern (Daten), RAID 1 mit 2 Datenträgern (Protokolle), 8 GB RAM, Dualprozessor. Hinweis: Eine RAID 5-Konfiguration mit ähnlicher Leistung kann verwendet werden, um die DW-Speicheranforderungen zu erfüllen.

RS;

RAID 1 mit 2 Datenträgern, 4 GB RAM, Dualprozessor

RMS;

RAID 1 mit 2 Datenträgern, 8 GB RAM, Dualprozessor

MS;

RAID 1 mit 2 Datenträgern, 4 GB RAM, Quadprozessor

Mehrere Server, Unternehmen

Um für Redundanz zu sorgen, können Sie mehrere Verwaltungsserver bereitstellen, die jeweils die beschriebene Mindestkonfiguration aufweisen. Wenn Sie bei Datenbank- und Stammverwaltungsserver für hohe Verfügbarkeit sorgen möchten, können Sie diese in einem Cluster bereitstellen, wobei jeder Knoten die beschriebene Mindestkonfiguration sowie Verbindungen zu einem extern freigegebenen Datenträger für Clusterressourcen aufweist.

Anzahl überwachter Geräte Serverrolle/Konfiguration Serverrolle/Konfiguration Serverrolle/Konfiguration Serverrolle/Konfiguration Serverrolle/Konfiguration

1.000 bis 3.000 Windows-Computer, 500 UNIX- oder Linux-Computer

DB;

RAID 0+1 mit 8 Datenträgern (Daten), RAID 1 mit 2 Datenträgern (Protokolle), 8 GB RAM, Quadprozessor

DW;

RAID 0+1 mit 8 Datenträgern (Daten), RAID 1 mit 2 Datenträgern (Protokolle), 8 GB RAM, Quadprozessor

RS;

RAID 1 mit 2 Datenträgern, 4 GB RAM

Quadprozessor

RMS;

RAID 0+1 mit 4 Datenträgern, 12 GB RAM, 64-Bit-Quadprozessor

MS;

RAID 0+1 mit 4 Datenträgern, 8 GB RAM, Quadprozessor

3.000 bis 6.000 Windows-Computer, Unix- oder Linux-Computer

DB;

RAID 0+1 mit 14 Datenträgern (Daten), RAID 1 mit 2 Datenträgern (Protokolle), 16 GB RAM, Quadprozessor

DW;

RAID 0+1 mit 14 Datenträgern (Daten), RAID 1 mit 2 Datenträgern (Protokolle), 16 GB RAM, Quad-/Dualprozessor. Hinweis: Eine RAID 5-Konfiguration mit ähnlicher Leistung kann verwendet werden, um die DW-Speicheranforderungen zu erfüllen.

RS;

RAID 1 mit 2 Datenträgern, 4 GB RAM, Quadprozessor

RMS;

RAID 0+1 mit 4 Datenträgern, 16 GB RAM, Quadprozessor

MS;

RAID 0+1 mit 2 Datenträgern, 8 GB RAM, Quadprozessor

Komponentenrichtlinien und bewährte Methoden

Neben den eben erläuterten Ausstattungsrichtlinien gelten für die Planung der einzelnen Operations Manager-Serverkomponenten weitere Erwägungen und bewährte Methoden.

Richtlinien und bewährte Methoden in Bezug auf den Stammverwaltungsserver

Auf dem Stammverwaltungsserver sind die kritischen Ressourcen der Arbeitsspeicher und die Zentraleinheit, da viele der vom Stammverwaltungsserver durchgeführten Vorgänge viel Speicher beanspruchen und daher unter übermäßigem Auslagern leiden. Neben anderen wirken sich die folgenden Faktoren auf die Last des Stammverwaltungsservers aus:

  • Anzahl der Agents in der Verwaltungsgruppe: Da der Stammverwaltungsserver die Konfiguration für alle Agents in der Verwaltungsgruppe berechnen muss, steigt bei zunehmender Agentzahl der erforderliche Speicherplatz, unabhängig vom Volumen der von den Agents übermittelten Vorgangsdaten.

  • Rate der Instanzbereichsänderungen: Unter dem Instanzbereich versteht man die Daten, die von Operations Manager erfasst werden, um alle überwachten Computer, Dienste und Anwendungen in der Verwaltungsgruppe zu beschreiben. Wenn diese Daten häufigen Änderungen unterliegen, sind zusätzliche Ressourcen auf dem Stammverwaltungsserver erforderlich, um die Konfigurationsaktualisierungen für die betroffenen Agents zu berechnen. Die Rate der Instanzbereichsänderungen steigt mit jedem zusätzlich in die Verwaltungsgruppe importierten Management Pack an. Durch Hinzufügen neuer Agents in die Verwaltungsgruppe steigt die Rate der Instanzbereichsänderungen ebenfalls vorübergehend an.

  • Anzahl gleichzeitig ausgeführter Betriebskonsolen und andere SDK-Clients: Beispiele für andere SDK-Clients sind die Webkonsole sowie zahlreiche Tools von Drittanbietern, die eine Verbindung mit Operations Manager unterhalten. Da der SDK-Dienst auf dem Stammverwaltungsserver gehostet wird, beansprucht jede zusätzliche Verbindung Speicher- und Prozessorkapazität.

Hier einige bewährte Methoden in Bezug auf die Ausstattung des Stammverwaltungsservers:

  • 64-Bit-Hardware und Betriebssystem verwenden: Durch die Verwendung von 64-Bit-Hardware kann der Speicher leicht auf über 4 GB gesteigert werden. Auch wenn für die aktuelle Bereitstellung nicht mehr als 4 GB Arbeitsspeicher erforderlich sind, verschafft Ihnen 64-Bit-Hardware Spielraum für Systemerweiterungen später, um mit geänderten Anforderungen Schritt halten zu können.

  • Anzahl der Agents beschränken oder auf Agents verzichten, die an den Stammverwaltungsserver Bericht erstatten: In Verwaltungsgruppen mit weniger Agents ist es in der Regel kein Problem, wenn die Agents direkt an den Stammverwaltungsserver Bericht erstatten. Dadurch werden die Gesamtkosten für die erforderliche Hardware gesenkt. Bei steigender Agentzahl empfiehlt es sich jedoch, die direkte Berichterstattung an den Stammverwaltungsserver einzuschränken. Durch das Verlagern der von Agents verursachten Arbeitslast auf andere Verwaltungsserver sinken die Hardwareanforderungen an den Stammverwaltungsserver, wodurch in der Regel die Gesamtleistung und Zuverlässigkeit der Verwaltungsgruppe verbessert wird.

  • Für hohe Bandbreite bei der Netzwerkverbindung mit der OperationsManager-Datenbank und dem Data Warehouse sorgen: Der Stammverwaltungsserver kommuniziert häufig mit der Operations-Datenbank und dem Data Warehouse. In der Regel wird für diese SQL-Verbindungen mehr Bandbreite benötigt, und sie sind anfälliger für Netzwerklatenz als Verbindungen zwischen Agents und dem Stammverwaltungsserver. Daher sollten Sie generell dafür sorgen, dass sich der Stammverwaltungsserver, die OperationsManager-Datenbank und die Data Warehouse-Datenbank im gleichen LAN befinden.

Richtlinien und bewährte Methoden für die Operations-Datenbank

Wie bei allen Datenbankanwendungen hängt die Leistung der Operations-Datenbank am stärksten von der Leistung des Datenträgersubsystems ab. Da alle Operations Manager-Daten die OperationsManager-Datenbank durchlaufen, steigt die Leistung mit einem schnelleren Datenträger entsprechend an. Auch die Zentraleinheit und der Arbeitsspeicher beeinflussen die Leistung. Neben anderen wirken sich die folgenden Faktoren auf die Last der OperationsManager-Datenbank aus:

  • Rate der Datensammlung: Der Stammverwaltungsserver kommuniziert häufig mit der Operations-Datenbank und dem Data Warehouse. In der Regel wird für diese SQL-Verbindungen mehr Bandbreite benötigt, und sie sind anfälliger für Netzwerklatenz als Verbindungen zwischen Agents und dem Stammverwaltungsserver. Daher sollten Sie generell dafür sorgen, dass sich der Stammverwaltungsserver, die OperationsManager-Datenbank und die Data Warehouse-Datenbank im gleichen LAN befinden.

  • Rate der Instanzbereichsänderungen: Unter dem Instanzbereich versteht man die Daten, die von Operations Manager erfasst werden, um alle überwachten Computer, Dienste und Anwendungen in der Verwaltungsgruppe zu beschreiben. Die Aktualisierung dieser Daten in der OperationsManager-Datenbank ist relativ kostspielig verglichen mit dem Speichern neuer operativer Daten in der Datenbank. Wenn sich Instanzbereichsdaten ändern, werden zudem zusätzliche Abfragen vom Stammverwaltungsserver an die OperationsManager-Datenbank übermittelt, um Konfigurations- und Gruppenänderungen zu berechnen. Die Rate der Instanzbereichsänderungen steigt mit jedem zusätzlich in die Verwaltungsgruppe importierten Management Pack an. Durch Hinzufügen neuer Agents in die Verwaltungsgruppe steigt die Rate der Instanzbereichsänderungen ebenfalls vorübergehend an.

  • Gleichzeitig ausgeführte Betriebskonsolen und andere SDK-Clients: Jede offene Instanz der Betriebskonsole ruft Daten aus der OperationsManager-Datenbank ab. Die Abfrage dieser Daten führt möglicherweise zu umfangreichen Datenträgeraktivitäten und beansprucht die Zentraleinheit und den Arbeitsspeicher. Konsolen, auf denen große Mengen operativer Daten in der Ereignisansicht, Statusansicht, Warnungsansicht und Leistungsansicht angezeigt werden, verursachen oft die stärkste Belastung der Datenbank. Um maximale Skalierbarkeit zu erzielen, sollten Sie die Bereichsdefinition von Ansichten in Betracht ziehen, sodass nur benötigte Daten angezeigt werden.

Hier einige bewährte Methoden in Bezug auf die Ausstattung des OperationsManager-Datenbankservers:

  • Geeignetes Datenträgersubsystem auswählen: Das Datenträgersubsystem der OperationsManager-Datenbank ist die wichtigste Komponente für die allgemeine Skalierbarkeit und Leistung der Verwaltungsgruppe. Als Datenträgervolume für die Datenbank sollte in der Regel RAID 0+1 mit einer geeigneten Anzahl an Spindeln zum Einsatz kommen. RAID 5 ist normalerweise ungeeignet für diese Komponente, da hierbei der Speicherplatz auf Kosten der Leistung optimiert wird. Da der Primärfaktor bei der Auswahl eines Datenträgersubsystems für die OperationsManager-Datenbank die Leistung, nicht der Gesamtspeicherplatz ist, eignet sich RAID 0+1 besser. Wenn Ihre Ansprüche im Hinblick auf die Skalierbarkeit die Durchsatzkapazität eines Einzellaufwerks nicht überschreiten, ist RAID 1 oft eine passende Wahl, da hierbei Fehlertoleranz ohne Leistungseinbußen geboten wird.

  • Datendateien und Transaktionsprotokolle: Bei Bereitstellungen von geringem Umfang ist es oft am kostenwirksamsten, die SQL-Datendatei und die Transaktionsprotokolle auf einem physischen Volume zu kombinieren, da das Transaktionsprotokoll nur geringe Aktivität verursacht. Bei zunehmender Agentzahl empfiehlt es sich jedoch, separate Volumes für die SQL-Datendatei und das Transaktionsprotokoll zu verwenden. Dadurch können auf dem Volume des Transaktionsprotokolls Lese- und Schreibzugriffe effizienter abgewickelt werden, da die Arbeitslast überwiegend aus sequenziellen Schreibzugriffen besteht. Ein RAID 1-Volume mit einer Spindel kann sehr hohe Mengen sequenzieller Schreibzugriffe abwickeln und sollte für nahezu alle Bereitstellungen ausreichen, sogar bei extrem großen Ausmaßen.

  • 64-Bit-Hardware und Betriebssystem verwenden: Die OperationsManager-Datenbank profitiert häufig von einem großen Arbeitsspeicher, und dies kann eine kostenwirksame Methode zur Senkung der Datenträgeraktivität auf dem Server sein. Durch die Verwendung von 64-Bit-Hardware kann der Speicher leicht auf über 4 GB gesteigert werden. Auch wenn für die aktuelle Bereitstellung nicht mehr als 4 GB Arbeitsspeicher erforderlich sind, verschafft Ihnen 64-Bit-Hardware Spielraum für Systemerweiterungen später, um mit geänderten Anforderungen Schritt halten zu können.

  • Batterieunterstützten Datenträgercontroller mit Schreibcache verwenden: Tests haben gezeigt, dass Datenträger mit Schreibcache für die Arbeitslast der OperationsManager-Datenbank von Vorteil sind. Daher wird empfohlen, dass Sie beim Konfigurieren von Schreib- und Lesecache auf dem Datenträgercontroller die Cachekapazität zu 100 Prozent dem Schreibcache zuweisen. Generell ist bei der Verwendung von Datenträgercontrollern mit Schreibcache in Verbindung mit Datenbanksystemen darauf zu achten, dass ein geeignetes batteriegestütztes Sicherungssystem vorhanden ist, um Datenverlust im Fall eines System- oder Stromausfalls zu vermeiden.

Richtlinien und bewährte Methoden für das Data Warehouse

In Operations Manager 2007 werden Daten nahezu in Echtzeit im Data Warehouse gespeichert. Dadurch weist dieses eine ähnliche Last wie der Computer der OperationsManager-Datenbank auf. Da es sich hierbei um einen SQL-Server handelt, ist das Datenträgersubsystem die wichtigste Komponente für die Gesamtleistung, gefolgt von Arbeitsspeicher und Zentraleinheit. Die Operations Manager Reporting Services belasten den Data Warehouse-Server auch auf leicht unterschiedliche Weise. Neben anderen wirken sich die folgenden Faktoren auf die Last des Data Warehouses aus:

  • Rate der Dateneinfügung: Um eine effizientere Berichterstattung zu ermöglichen, werden im Data Warehouse neben einer begrenzten Menge an Rohdaten aggregierte Daten berechnet und gespeichert. Dieser zusätzliche Arbeitsaufwand bedeutet, dass die Sammlung der operativen Daten im Data Warehouse geringfügig teurer ist als in der OperationsManager-Datenbank. Diese zusätzlichen Kosten werden in der Regel durch die geringeren Verarbeitungskosten für Ermittlungsdaten aus dem Data Warehouse im Vergleich zur Verarbeitung der Daten aus der OperationsManager-Datenbank ausgeglichen.

  • Anzahl der Benutzer, die gleichzeitig Bericht erstatten: Da in Berichten häufig umfangreiche Mengen an Daten zusammengefasst werden, kann jeder berichterstattende Benutzer eine beträchtliche Last für das System darstellen. Sowohl die Anzahl der gleichzeitig erstellten Berichte als auch die Art der Berichte, die jeweils ausgeführt werden, haben Auswirkungen auf die Kapazitätsanforderungen. Im Allgemeinen beanspruchen Berichte, die umfangreiche Datenbereiche oder eine große Anzahl an Objekten abfragen, am meisten Systemressourcen.

Hier einige bewährte Methoden zur Ausstattung des Data Warehouse-Servers:

  • Geeignetes Datenträgersubsystem auswählen: Da das Data Warehouse inzwischen ein integraler Bestandteil des Gesamtdatenflusses innerhalb der Verwaltungsgruppe ist, ist die Entscheidung für ein geeignetes Datenträgersubsystem für das Data Warehouse äußerst wichtig. Wie bei der OperationsManager-Datenbank stellt oft RAID 0+1 die beste Option dar. Im Allgemeinen sollte das Datenträgersubsystem für das Data Warehouse dem der OperationsManager-Datenbank ähnlich sein.

  • Datendateien und Transaktionsprotokolle: Wie bei der OperationsManager-Datenbank empfiehlt es sich in der Regel mit zunehmender Anzahl an Agents, die SQL-Daten und die Transaktionsprotokolle zu trennen. Wenn sowohl die OperationsManager-Datenbank als auch das Data Warehouse auf dem gleichen Computer beheimatet sind, müssen die Transaktionsprotokolle für die OperationsManager-Datenbank in einem eigenen Volume getrennt vom Data Warehouse geführt werden, um Vorteile erkennen zu können. Die Datendateien für die OperationsManager-Datenbank und das Data Warehouse können auf dem gleichen Volume vorliegen, vorausgesetzt, die Kapazität ist ausreichend.

  • 64-Bit-Hardware und Betriebssystem verwenden: Das Data Warehouse profitiert in der Regel von einem großen Arbeitsspeicher, und dies kann eine kostenwirksame Methode zur Senkung der Datenträgeraktivität auf dem Server sein. Durch die Verwendung von 64-Bit-Hardware kann der Speicher leicht auf über 4 GB gesteigert werden. Auch wenn für die aktuelle Bereitstellung nicht mehr als 4 GB Arbeitsspeicher erforderlich sind, verschafft Ihnen 64-Bit-Hardware Spielraum für Systemerweiterungen später, um mit geänderten Anforderungen Schritt halten zu können.

  • Dedizierte Serverhardware für das Data Warehouse verwenden: Obwohl bei Bereitstellungen von geringem Umfang zumeist die OperationsManager-Datenbank und das Data Warehouse auf dem gleichen Computer konsolidiert werden können, ist es bei zunehmender Anzahl an Agents und damit verbunden steigendem Volumen eingehender operativer Daten vorteilhaft, diese zu trennen. Eine Trennung von Data Warehouse- und Berichterstattungsserver führt zudem zu einer besseren Leistung bei der Berichterstattung.

  • Batterieunterstützten Datenträgercontroller mit Schreibcache verwenden: Tests haben gezeigt, dass Datenträger mit Schreibcache für die Data Warehouse-Arbeitslast von Vorteil sind. Daher wird empfohlen, dass Sie beim Konfigurieren von Schreib- und Lesecache auf dem Datenträgercontroller die Cachekapazität zu 100 Prozent dem Schreibcache zuweisen. Generell ist bei der Verwendung von Datenträgercontrollern mit Schreibcache in Verbindung mit Datenbanksystemen darauf zu achten, dass ein geeignetes batteriegestütztes Sicherungssystem vorhanden ist, um Datenverlust im Fall eines System- oder Stromausfalls zu vermeiden.

Richtlinien und bewährte Methoden in Bezug auf Verwaltungsserver

Der größte Anteil der Last eines Verwaltungsservers wird durch die Sammlung operativer Daten und die Einfügung von Daten in die OperationsManager- und Data Warehouse-Datenbanken verursacht. Es ist wichtig, hervorzuheben, dass Verwaltungsserver diese Vorgänge direkt ausführen, ohne vom Stammverwaltungsserver abhängig zu sein. Für die Datenspeicherung in der Warteschlange verwenden Verwaltungsserver dabei zumeist den Arbeitsspeicher, um nicht auf einen langsameren Datenträger angewiesen zu sein, wodurch die Leistung steigt. Die wichtigste Ressource für Verwaltungsserver ist die Zentraleinheit, doch haben Tests ergeben, dass hierfür in der Regel keine High-End-Hardware erforderlich ist. Neben anderen wirken sich die folgenden Faktoren auf die Last eines Verwaltungsservers aus:

  • Rate der Sammlung operativer Daten: Da die Sammlung operativer Daten die Primäraktivität eines Verwaltungsservers ist, wirkt sich diese Rate am stärksten auf die Gesamtauslastung des Servers aus. Allerdings haben Tests gezeigt, dass Verwaltungsserver in der Regel hohe Verarbeitungsraten für operative Daten bei niedriger bis mäßiger Auslastung realisieren können. Primär hängt die Rate der Sammlung operativer Daten von der Art der bereitgestellten Management Packs in der Verwaltungsgruppe ab.

Hier einige bewährte Methoden zur Ausstattung eines Verwaltungsservers:

  • Hardware für Verwaltungsserver nicht überdimensionieren: In den meisten Szenarien ist der Einsatz eines gängigen Dienstprogrammservers ausreichend für die von einem Verwaltungsserver erledigte Arbeit. Die Einhaltung der Hardwarerichtlinien in diesem Dokument sollte für die meisten Arbeitslasten ausreichen.

  • Das maximale Verhältnis zwischen Agent und Verwaltungsservern von 3.000 zu 1 dar nicht überschritten werden. Die tatsächliche Serverleistung variiert je nach Volumen der gesammelten operativen Daten, doch haben Tests gezeigt, dass Verwaltungsserver in der Regel problemlos bis zu 2.000 Agents mit relativ hohem Volumen an eingehenden operativen Daten unterstützen können. Der Höchstwert von 2.000 Agents pro Verwaltungsserver ist ein Richtwert, der aus Erfahrungstests gewonnen wurde, und stellt kein striktes Limit dar. Sie müssen selbst feststellen, ob in Ihrer Umgebung die Anzahl der unterstützten Agents eventuell höher oder niedriger liegt; beides ist durchaus möglich.

  • Um ein optimales Verhältnis zwischen UNIX- oder Linux-Computern und Verwaltungsservern (500:1) zu erreichen, empfiehlt es sich, dass Sie dedizierte Verwaltungsserver für die plattformübergreifende Überwachung verwenden.

  • Die Redundanzanforderungen mit der geringstmöglichen Anzahl an Verwaltungsservern pro Verwaltungsgruppe erfüllen: Der Hauptgrund für die Bereitstellung mehrerer Verwaltungsserver hat nichts mit Skalierbarkeit zu tun, sondern besteht darin, für Redundanz und Notfallwiederherstellung vorzusorgen. Anhand von Tests hat sich gezeigt, dass die meisten Bereitstellungen mit drei bis fünf Verwaltungsservern auskommen, um diese Anforderungen vollständig zu erfüllen.

Richtlinien und bewährte Methoden in Bezug auf Gatewayserver

Gatewayserver fungieren als Relaisstation für die Kommunikation zwischen Verwaltungsservern und Agents, die auf entgegengesetzten Seiten von Kerberos-Vertrauensgrenzen liegen. Der Gatewayserver verwendet eine zertifikatbasierte Authentifizierung für die wechselseitige Authentifizierung mit dem Verwaltungsserver, wobei er nur eine Verbindung benötigt anstelle der mehrfachen Verbindungen, die zwischen Agents und Verwaltungsserver erforderlich wären. Dadurch wird die Verwaltung der zertifikatbasierten Authentifizierung von nicht vertrauenswürdigen Domänen einfacher und praktikabler. Neben anderen wirken sich die folgenden Faktoren auf die Last eines Gatewayservers aus:

  • Rate der Sammlung operativer Daten: Primär hängt die Last des Gateways von der Rate ab, mit der operative Daten gesammelt werden. Diese Rate ergibt sich aus der Anzahl der Agents, die an das Gateway Bericht erstatten, und den in der Verwaltungsgruppe bereitgestellten Management Packs.

Hier einige bewährte Methoden zur Ausstattung eines Gatewayservers:

  • Gatewayserver können nützlich für die Verwaltung der Bandbreitennutzung sein: Aus Sicht der Leistung können Gateways als Hilfsmittel empfohlen werden, um die Bandbreitennutzung in Umgebungen mit niedriger Bandbreite zu optimieren, da sie die gesamte Kommunikation mit dem Verwaltungsserver in gewissem Umfang komprimieren.

  • Das maximale Verhältnis zwischen Agent und Verwaltungsservern von 1.500 zu 1 darf nicht überschritten werden. Anhand von Tests hat sich gezeigt, dass bei mehr als 1.000 Agents pro Gateway mit einer Beeinträchtigung im Hinblick auf die Wiederherstellungsmöglichkeiten zu rechnen ist, falls das Gateway bei einem längeren Ausfall (mehrere Stunden) nicht mit dem Verwaltungsserver kommunizieren kann. Wenn in Ihrer Umgebung mehr als 1.000 Agents an das Gateway Bericht erstatten müssen, sollten Sie den Einsatz mehrerer Gatewayserver in Betracht ziehen. Wenn Sie die Zahl von 1.500 Agents pro Gateway überschreiten wollen und die Wiederherstellungszeit des Gateways in Ihrer Umgebung von Bedeutung ist, ist es unbedingt zu empfehlen, dass Sie Ihr System testen, um sicherzustellen, dass das Gateway die Warteschlange nach einem längeren Ausfall zwischen Gateway und Verwaltungsserver rasch leeren kann.

  • Für eine große Anzahl an Gateways und über Gateway verbundenen Agents einen dedizierten Verwaltungsserver verwenden: Wenn Sie einen Verwaltungsserver ausschließlich für die Verbindung mit allen Gateways und ohne jede Agentverbindung bereitstellen, können Sie dadurch die Wiederherstellungszeit bei einem längeren Ausfall verkürzen.

Richtlinien und bewährte Methoden im Hinblick auf die Anwendungsfehlerüberwachung

Auf dem Verwaltungsserver, der für die Anwendungsfehlerüberwachung (AEM, Application Error Monitoring) verwendet wird, gehen die Daten vom Client für die Fehlerberichterstattung ein und werden dort in einer Dateifreigabe gespeichert. Wenn diese Dateifreigabe lokal vorliegt, wirkt sich dies auf den Verwaltungsserver aus.

Im folgenden einige bewährte Methoden für die Planung der Anwendungsfehlerüberwachung:

  • Der Speicherplatz für die Dateifreigabe kann lokal oder auf einem angeschlossenen NAS- (Network Attached Storage) oder SAN-Gerät (Storage Area Network) bereitgestellt werden.

  • Es empfiehlt sich, für die Anwendungsfehlerüberwachung einen eigenen Datenträger zu verwenden, der unabhängig ist vom Datenträger, der für die Data Warehouse- oder OperationsManager-Datenbanken verwendet wird.

  • Wenn der Speicherplatz in einem verteilten Dateisystem (DFS) eingerichtet wurde, muss die DFS-Replikation deaktiviert werden.

  • Gatewayserver dürfen nicht als AEM-Sammlung verwendet werden.

Anzahl überwachter Geräte Verwaltungsserver für AEM-Dateifreigabe

0 bis 10.000

200 GB Speicherplatz als RAID 1 mit 2 Laufwerken, 4 GB RAM, Dualprozessor

10.000 bis 25.000

500 GB Speicherplatz als RAID 1 mit 2 Laufwerken, 8 GB RAM, Dualprozessor

Richtlinien und Best Practices zur URL-Überwachung

Für die URL-Überwachung kann der Integritätsdienst eines Agents oder ein Verwaltungsserver genutzt werden. Wenn Sie mehr als 1000 URLs von einem Verwaltungsserver aus überwachen, müssen Sie die Versionsspeicher-Seitengröße für den Integritätsdienst von der Standardzahl 5120 Seiten auf 10240 Seiten heraufsetzen. Diese Änderung wird in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HealthService\Parameters\Persistence Version\Store Maximum vorgenommen. Da auf einem zur URL-Überwachung genutzten Verwaltungsserver CPU- und Datenträgerressourcen stark belastet werden, wird der Einsatz eines batteriegestützten Cachecontrollers empfohlen.

Richtlinien und bewährte Methoden im Hinblick auf die Clientsammelüberwachung

Im Rahmen der kollektiven Integritätsüberwachung werden Ereignis- und Leistungsdaten zahlreicher Computer gesammelt und die Daten zum Zweck der Berichterstattung und Auswertung nach Systemgruppen zusammengestellt. Beispielsweise werden Daten zur Speicherleistung von Windows XP- und Windows Vista-Clients auf unterschiedlicher Hardware gesammelt. Anschließend werden die Daten zusammengefasst und ausgewertet, um Berichte über die Speicherleistung bestimmter Systemgruppen, etwa nach Betriebssystem oder Hardwarehersteller, zu liefern. Dadurch wird die Analyse der Gesamtleistung im Vergleich zur Alternativmethode erleichtert, bei der lange Listen einzelner Systemleistungsberichte durchsucht werden müssen. Der Sammelüberwachungsmodus ermöglicht somit die Warnung und Überwachung auf kollektiver statt individueller Ebene.

Zu den Management Packs der Clientsammelüberwachung gehören: Information Worker, Windows Client, Windows XP, Windows Vista, Network Address Protocol und andere clientorientierte Management Packs.

Jeder Client, der von einem Agent überwacht wird, erzeugt normalerweise in regelmäßigen Abständen zusammenfassende Ereignisse, die ihrerseits verwendet werden, um die kollektive Integrität des Clientbestands zu berechnen. Die Warnungsausgabe einzelner Agents ist deaktiviert, daher werden von den auf den Clients ausgeführten Agents keine Warnungsdaten erzeugt.

Je nach Anzahl der bereitgestellten Management Packs und Volumen des Agentverkehrs können einzelne Verwaltungsserver an die 3.000 bis 4.000 mit Agents verwaltete Clients verwalten.

Beim Planen des Rollouts kollektiver Überwachungsclients empfiehlt es sich, die Agents in Sätzen von maximal 1.000 zu genehmigen, damit ausreichend Zeit für ihre Synchronisierung mit der aktuellen Konfiguration zur Verfügung steht.

Entwerfen von Überwachungssammeldiensten (ACS)

Dieser Abschnitt enthält allgemeine Ratschläge, mit deren Hilfe Sie die Planung Ihrer ACS-Implementierung in Angriff nehmen können.

ACS ist keine eigenständige Lösung. Diese Dienste können nur in einer bestehenden Verwaltungsgruppe gehostet werden, da der betreffende Agent in den Operations Manager-Agent integriert ist und mit diesem zusammen installiert wird. Ferner kann die ACS-Sammlung nur auf einem Verwaltungs- oder Gatewayserver installiert werden. Die verbleibenden Komponenten, die ACS-Datenbank und die ACS-Berichterstattung, können auf dem gleichen SQL Server 2005-Server oder der gleichen Instanz installiert werden wie die anderen OperationsManager-Datenbank- und Berichterstattungskomponenten. Allerdings sprechen Gründe wie Leistung, Kapazität und Sicherheit für eine Installation auf dedizierter Hardware.

Entwurfsentscheidungen

Bei der Planung der ACS-Implementierung müssen Sie vier grundlegende Entwurfsentscheidungen treffen. Hierbei dürfen Sie nicht vergessen, dass zwischen dem ACS-Sammlungsserver und der dazugehörigen ACS-Datenbank eine Eins-zu-Eins-Beziehung besteht. Eine ACS-Datenbank kann jeweils nur eine einzige ACS-Sammlung haben, von der ihr Daten zugeführt werden, und jede ACS-Sammlung muss über ihre eigene ACS-Datenbank verfügen. Es ist möglich, in einer Verwaltungsgruppe mehrere ACS-Sammlungs-/Datenbank-Paarungen zu haben, allerdings stehen keine vorgefertigten Lösungen bereit, um die Daten mehrerer ACS-Datenbanken in einer einzigen Datenbank zu konsolidieren.

Als erstes müssen Sie entscheiden, ob Sie eine Verwaltungsgruppe bereitstellen wollen, die ausschließlich für die Unterstützung von ACS dient, oder ob ACS in einer Verwaltungsgruppe bereitgestellt werden soll, die auch Integrationsüberwachungs- und Warnungsdienste leistet. Hier die Merkmale dieser beiden ACS-Bereitstellungsszenarien.

  • Szenario 1 - ACS gehostet in Produktionsverwaltungsgruppe:

    • Skalierte ACS-Nutzung: Da ACS alle Sicherheitsereignisse der Systeme sammelt, auf denen ACS-Weiterleitungen aktiviert sind, kann durch die Nutzung von ACS ein riesiges Datenvolumen erzeugt werden. Wenn Sie keine dedizierte Hardware für die ACS-Sammlungs- und Datenbankrollen verwenden, kann sich die Verarbeitung dieser Daten negativ auf die Leistung der Hostverwaltungsgruppe auswirken, insbesondere auf Datenbankebene.

    • Trennung von Verwaltung und Sicherheit ist nicht erforderlich: Da ACS in einer Verwaltungsgruppe gehostet wird, verfügen Personen mit administrativer Kontrolle über die Verwaltungsgruppe über Verwaltungsrechte für ACS. Wenn aufgrund von betrieblichen, Ordnungs-/Überprüfungs- und IT-Anforderungen eine Verpflichtung besteht, die informationstechnische Kontrolle über ACS außerhalb der Produktionsumgebung anzusiedeln, steht die Option der Bereitstellung von ACS in einer Produktionsverwaltungsgruppe nicht zur Verfügung.

  • Szenario 2 - ACS gehostet in dedizierter Verwaltungsgruppe:

    • Trennung von Verwaltung und Sicherheit ist erforderlich: Wenn eine eigene administrative Gruppe besteht, die im Unternehmen für Überprüfungs- und Sicherheitskontrolle zuständig ist, empfiehlt es sich, ACS in einer dedizierten Verwaltungsgruppe zu hosten, die von der Überprüfungs-/Sicherheitsgruppe verwaltet wird.

Als zweites müssen Sie entscheiden, ob die ACS-Berichterstattung in derselben SQL Server 2005 Reporting Services-Instanz wie die Operations Manager 2007-Berichterstattungskomponente bereitgestellt werden soll. Hier die Merkmale dieser beiden Szenarien.

  • Integration von ACS-Berichterstattung und Operations Manager-Berichterstattung:

    • Einzelkonsole für alle Berichte: Wenn die ACS-Berichterstattung gemeinsam mit der Operations Manager-Berichterstattung installiert ist, erfolgt der Zugriff auf die ACS-Berichte über die Operations Manager-Betriebskonsole.

    • Gemeinsames Sicherheitsmodell: Wenn die Operations Manager 2007-Berichterstattung im Rahmen der SQL Server 2005 Reporting Services installiert ist, wird das Standardsicherheitsmodell überschrieben und durch das rollenbasierte Sicherheitsmodell von Operations Manager ersetzt. Die ACS-Berichterstattung ist mit diesem Modell kompatibel. Alle Benutzer, die der Rolle "Report-Operator" zugewiesen wurden, können auf die ACS-Berichte zugreifen, vorausgesetzt, sie verfügen auch über die erforderliche Berechtigung für die ACS-Datenbank.

    Hinweis

    Falls die Operations Manager-Berichterstattung später deinstalliert wird, muss das ursprüngliche SRS-Sicherheitsmodell unter Verwendung des Dienstprogramms ResetSRS.exe, das auf dem Installationsmedium im Verzeichnis SupportTools zu finden ist, manuell wiederhergestellt werden.

  • Bei Installation der ACS-Berichterstattung auf einer dedizierten Instanz von SQL Server Reporting Services:

    • Eigene Konsole für ACS- und Operations Manager-Berichte: Bei der Installation in einer dedizierten SRS-Instanz erfolgt der Zugriff auf die ACS-Berichte über die SRS-Website, die bei der Installation hierfür erstellt wird. Dadurch besteht mehr Flexibilität im Hinblick auf die Konfiguration der Ordnerstruktur und die Verwendung des SRS Report-Designers.

    • Eigenes Sicherheitsmodell: Wenn Sie eine dedizierte SRS-Instanz verwenden, können Sie Sicherheitsrollen nach Bedarf erstellen, um die betrieblichen und IT-Anforderungen zu erfüllen, die sich in Verbindung mit der Kontrolle des Zugriffs auf die ACS-Berichte ergeben. Beachten Sie, dass für die ACS-Datenbank weiterhin die erforderliche Berechtigung erteilt werden muss.

Die dritte Entscheidung, die Sie treffen müssen, gilt der Anzahl der ACS-Sammlungs-/Datenbank-Paarungen, die zur Unterstützung Ihrer Umgebung bereitgestellt werden soll. Die Unterstützung, die eine einzelne ACS-Sammlungs-/Datenbank-Paarung für die laufende Sammlung und Einfügung von Ereignissen leisten kann, lässt sich nicht auf eine absoluten Zahl festlegen. Sie hängt ab von der Leistung des Speichersubsystems, mit dem der Datenbankserver verbunden ist. Beispielsweise kann eine einfache SAN-Lösung in der Regel 2.500 bis 3.000 Sicherheitsereignisse pro Sekunde unterstützen. Unabhängig hiervon wurde bei der ACS-Sammlung die Bewältigung kurzfristiger Spitzen von 20.000 Sicherheitsereignissen pro Sekunde beobachtet. Die folgenden Faktoren wirken sich auf die Anzahl der pro Sekunde erzeugten Sicherheitsereignisse aus:

  • Die Überwachungsrichtlinienkonfiguration: Mit zunehmender Aggressivität der Überwachungsrichtlinie steigt auch die Anzahl der Sicherheitsereignisse, die von den überwachten Computern erzeugt werden.

  • Die Rolle des Computers, auf dem die ACS-Weiterleitung aktiviert ist, je nach Standardüberwachungsrichtlinie; der Domänencontroller erzeugt die meisten Sicherheitsereignisse. Mitgliedsserver erzeugen die nächsthöchste und Arbeitsstationen die geringste Menge.

Computerrolle Ungefähre Anzahl ungefilterter Sicherheitsereignisse pro Sekunde, die bei hoher Last erzeugt werden

Windows Server 2003-Domänencontroller

40 Ereignisse pro Sekunde

Windows Server 2003-Mitgliedsserver

2 Ereignisse pro Sekunde

Arbeitsstation

0,2 Ereignisse pro Sekunde

  • Auf der Basis der Zahlen in der vorausgehenden Tabelle kann eine einzige High-End-Paarung von ACS-Sammlung/Datenbank bis zu 150 Domänencontroller, 3.000 Mitgliedsserver oder 20.000 Arbeitsstationen (bei angewendetem passendem ACS-Sammlungsfilter) unterstützen.

  • Menge der Benutzeraktivität im Netzwerk: Wenn Ihr Netzwerk von High-End-Benutzern verwendet wird, die umfangreiche Transaktionen durchführen, wie dies beispielsweise bei Microsoft der Fall ist, werden mehr Ereignisse erzeugt. Wenn Ihre Netzwerkbenutzer relativ wenige Transaktionen durchführen, wie das bei einem Verkaufskiosk oder in einem Warenlager der Fall ist, sind weniger Sicherheitsereignisse zu erwarten.

  • Konfiguration von ACS-Sammlungsfiltern: ACS sammelt alle Sicherheitsereignisse aus dem Sicherheitsereignisprotokoll eines überwachten Computers. Unter all diesen gesammelten Ereignissen sind wahrscheinlich nur einige wenige für Sie von Interesse. ACS bietet die Möglichkeit, die unerwünschten Ereignisse herauszufiltern, sodass von der Sammlung nur die erwünschten verarbeitet und in die ACS-Datenbank eingefügt werden. Mit zunehmender Filterung werden weniger Ereignisse verarbeitet und in die ACS-Datenbank eingefügt.

Die letzte Entwurfsentscheidung, die Sie fällen müssen, betrifft die SQL Server-Version (2005 oder 2008), die Sie für die ACS-Datenbank verwenden wollen. ACS unterstützt den Einsatz von SQL Server 2005 Standard Edition und SQL Server 2005 Enterprise Edition bzw. SQL Server 2008 Standard oder Enterprise Edition. Die verwendete Version wirkt sich auf das Verhalten des Systems während des täglichen Datenbankwartungsfensters aus. Bei der Wartung werden Datenbankpartitionen, deren Zeitstempel außerhalb des Datenbeibehaltungsplans liegt (in der Regel ist die Datenbeibehaltung auf 14 Tage eingestellt), aus der Datenbank gelöscht. Bei Verwendung von SQL Server Standard Edition wird die Einfügung von Sicherheitsereignissen angehalten, und Ereignisse verbleiben in der ACS-Sammlungswarteschlange, bis die Wartung abgeschlossen ist. Bei Verwendung von SQL Server Enterprise Edition wird die Einfügung verarbeiteter Sicherheitsereignisse fortgesetzt, wobei die Rate auf 30 bis 40 Prozent des üblichen Werts reduziert ist. Dies ist ein Grund, weshalb Sie den Zeitraum für die tägliche Datenbankwartung mit Sorgfalt auswählen und sich für eine Zeit entscheiden sollten, zu der möglichst wenig Benutzer- und Anwendungsaktivität im Netzwerk stattfindet.

Anpassen der Größe von ACS

In diesem Abschnitt wird erläutert, wie Sie die Größe von ACS-Hardwarekomponenten vor deren Bereitstellung anpassen können, indem Sie ermitteln, wie viele Datenträger, ACS-Sammlungen und -Datenbanken benötigt werden.

Wichtig

Zur Festlegung der adäquaten Größe von ACS müssen Sie die erforderliche Anzahl von Datenträgern für die ACS-Festplatten-E/A sowie die Größe der ACS-Datenbank bestimmen. Die Prozesse zur Berechnung dieser Werte werden im Abschnitt "ACS-Größenanpassung" beschrieben. Jede ACS-Sammlung muss über eine eigene ACS-Datenbank verfügen. Die Geschwindigkeit beim Einfügen von Daten in die Datenbank, die durch die Leistung des Speichersubsystems diktiert wird, bestimmt die Kapazität der jeweiligen ACS-Sammlung. Je mehr Datenträger von einem einzelnen Datenträgerarray unterstützt werden, desto besser die Leistung.

Tipp

Die Überwachungssammeldienste unterstützen den Einsatz von SQL Server 2005 Standard Edition und SQL Server 2005 Enterprise Edition; die verwendete Version wirkt sich jedoch auf das Verhalten des Systems während des täglichen Datenbankwartungsfensters aus. Bei der Wartung werden Datenbankpartitionen, deren Zeitstempel außerhalb des Datenbeibehaltungsplans liegt (in der Regel ist die Datenbeibehaltung auf 14 Tage eingestellt), aus der Datenbank gelöscht. Bei Verwendung von SQL Server 2005 Standard Edition wird die Einfügung von Sicherheitsereignissen angehalten, und Ereignisse verbleiben in der ACS-Sammlungswarteschlange, bis die Wartung abgeschlossen ist. Bei Verwendung von SQL Server 2005 Enterprise Edition wird die Einfügung von Sicherheitsereignissen fortgesetzt, wobei die Rate auf 30 bis 40 Prozent des üblichen Werts reduziert ist. Aus diesem Grund sollten Sie den Zeitraum für die tägliche Datenbankwartung mit Sorgfalt auswählen und sich für eine Zeit entscheiden, zu der möglichst wenig Benutzer- und Anwendungsaktivität im Netzwerk stattfindet.

ACS-Größenanpassung

Die Zahl der ACS-Sammlungen und die Festlegung der Größe der ACS-Datenbank sowie des Datenträgersubsystems für die Datenbank wird komplett davon bestimmt, wie viele Sicherheitsheitsereignisse pro Sekunde an die Sammlung weitergeleitet werden. Mit den ACS-Größenberechnungen finden Sie Antworten auf drei Fragen:

  1. Wie viele ACS-Sammlungen benötige ich?

  2. Wie viel Speicherplatz muss ich der Datenbank zuweisen?

  3. Wie viele Datenträger benötige ich, um den erwarteten Durchsatz auf der Datenbank zu unterstützen?

Ideal wäre es, wenn Sie zur Ermittlung der Anzahl der Sicherheitsereignisse, die von Computern in Ihrem Unternehmen erzeugt werden, eine ACS-Pilotsammlung installieren könnten, die die Rate der ankommenden Ereignisse misst. Wenn Sie über eine ACS-Pilotsammlung verfügen, können Sie den Leistungsindikator "ACS-Sammlung\Ankommende Ereignisse/Sekunde" überwachen. Wenn Ihnen keine ACS-Pilotsammlung zur Verfügung steht, können Sie mit den nachfolgenden Richtlinien für die Größenfestlegung und mithilfe des Beispielskripts ähnliche Ergebnisse erzielen.

Führen Sie die nachstehend beschriebenen Schritte aus, um mithilfe des Skripts Generierte Ereignisse pro Sekunde die Zahl der Ereignisse pro Sekunde für alle Computer in Ihrem Unternehmen zu erfassen. Nachdem Sie die Zahl der Ereignisse ermittelt haben, berechnen Sie mithilfe dieser Zahl die für die E/A-Vorgänge erforderliche Anzahl Datenträger und die erforderliche Gesamtgröße der ACS-Datenbank. Dies wird in den nachfolgenden Abschnitten beschrieben.

So ermitteln Sie die ungefähre Anzahl von Ereignissen pro Sekunde für alle Computer

  1. Identifizieren Sie Computergruppen, auf denen ähnliche Funktionen ausgeführt werden, beispielsweise Domänencontroller, Mitgliedsserver und Desktopcomputer.

  2. Ermitteln Sie für alle Computer in Ihrem Unternehmen die Anzahl der Computer in der jeweiligen Gruppe.

  3. Führen Sie zum Aufzeichnen von Daten das im Abschnitt Generierte Ereignisse pro Sekunde enthaltene Beispielskript innerhalb von 48 Stunden auf mindestens einem Computer pro Gruppe aus. Der Computer, auf dem Sie das Skript ausführen, fungiert als Stellvertreter für alle Computer in seiner Gruppe.

  4. Geben Sie die Daten zur Konsolidierung und Analyse in eine Tabellenkalkulation ein.

  5. Identifizieren Sie anhand der gesammelten Daten die Spitzenauslastung.

  6. Ermitteln Sie für jeden Computer, auf dem Sie Daten erfassen, wie viele Ereignisse pro Sekunde während der Spitzenauslastung erzeugt werden, und multiplizieren Sie diesen Wert anschließend mit der Zahl der Computer in der repräsentierten Gruppe. Wiederholen Sie diesen Schritt für jede Gruppe.

  7. Addieren Sie die im vorherigen Schritt gewonnenen Werte, um die Anzahl der Ereignisse pro Sekunde für alle Computer in Ihrem Unternehmen zu ermitteln.

    Der Gesamtwert wird in den nachfolgenden Abschnitten zur Berechnung der erforderlichen Anzahl von Datenträgern für die E/A-Vorgänge und der erforderliche Gesamtgröße der ACS-Datenbank herangezogen.

Berechnen der zum Ausführen der E/A-Vorgänge benötigten Datenträgerzahl In einer von Microsoft durchgeführten Testreihe betrug die geschätzte durchschnittliche Anzahl logischer Festplatten-E/A-Vorgänge pro Ereignis für ACS-Datenbankprotokolle 1,384 und für die ACS-Datenbank 0,138. Diese Werte können jedoch je nach Umgebung geringfügig abweichen. Diese Berechnungen basieren auf der Annahme, dass die die Festplattendrehzahl pro Minute (1/min) in einem 1:1-Verhältnis zur logischen Festplatten-E/A steht und eine RAID 0+1-Konfiguration verwendet wird.

Mithilfe der nachfolgenden Formeln können Sie ermitteln, wie viele Datenträger zur Unterstützung der E/A-Vorgänge benötigt werden.

Für die Protokolllaufwerke:

[Durchschnittliche Anzahl Festplatten-E/A pro Ereignis für Transaktionsprotokoll] x [Ereignisse pro Sekunde für alle Computer] / [Festplattendrehzahl] x 60 Sek/Minute = [Anzahl der erforderlichen Laufwerke] x 2 (für RAID 1)

Werte für die vorhergehenden Variablen werden in der nachstehenden Tabelle beschrieben.

Variable Wert

Durchschnittliche Anzahl logische Festplatten-E/A pro Ereignis (für die Transaktionsprotokolldatei)

1.384

Geschätzte Anzahl Ereignisse pro Sekunde für alle Computer

Geschätzt mithilfe des Skripts und mithilfe des Verfahrens "So ermitteln Sie die ungefähre Anzahl von Ereignissen pro Sekunde für alle Computer"

Festplattendrehzahl

Variiert je nach Datenträger

Für die Datenbanklaufwerke:

[Durchschnittliche Anzahl Festplatten-E/A pro Ereignis für Datenbankdatei] x [Ereignisse pro Sekunde für alle Computer] / [Laufwerksdrehzahl] x 60 Sek/Minute = [Anzahl der erforderlichen Laufwerke] x [2 for RAID 1]

Werte für die vorhergehenden Variablen werden in der nachstehenden Tabelle beschrieben.

Variable Wert

Durchschnittliche Anzahl logische Festplatten-E/A pro Ereignis (für die Datenbankdatei)

0.138

Geschätzte Anzahl Ereignisse pro Sekunde für alle Computer

Geschätzt mithilfe des Skripts und mithilfe der Schrittanweisung "So ermitteln Sie die ungefähre Anzahl von Ereignissen pro Sekunde für alle Computer"

Festplattendrehzahl

Variiert je nach Datenträger

Wenn zur Unterstützung der E/A-Vorgänge für Ereignisse mehr Datenträger benötigt werden als in einem Datenträgerarray unterstützt werden, müssen die Ereignisse auf mehrere Sammlungen verteilt werden.

Berechnen der Gesamtgröße der ACS-Datenbank
Verwenden Sie zur Berechnung der Gesamtgröße der ACS-Datenbank folgende Formel:

[Ereignisse pro Sekunde für alle Computer] x [0,4 KB – dies entspricht der Größe des Ereignisses] x 60 Sek. x60 Min. x 24 Std /1024 MB /1024 GB /1024 TB x [Aufbewahrungsdauer – Zeitraum der Beibehaltung in der Datenbank] = Gesamtgröße der Datenbank

Richtlinien und bewährte Methoden im Hinblick auf den Überwachungssammeldienst

Für die Gesamtleistung des ACS-Systems ist die Leistung der ACS-Datenbank und des Datenträgersubsystems am stärksten ausschlaggebend. Angesichts einer kontinuierlichen Einfügerate von Tausenden von Ereignissen pro Sekunde mit potenziellen Spitzen in den Zehntausenden Ereignissen pro Sekunde, ist dies offensichtlich. Bei vielen überwachten Computern, einschließlich Domänencontrollern, sammelt sich nicht selten in einer 14-tägigen Zeitspanne ein Terabyte an Daten in der ACS-Datenbank an. Im Folgenden einige bewährte Methoden für ACS:

  • Verwenden Sie für Sammlung und SQL Server 64-Bit-Hardware und ein entsprechendes Betriebssystem sowie eine leistungsstarke SAN-Lösung.

  • Trennen Sie die Datenbankdateien von den Transaktionsprotokollen.

  • Verwenden Sie dedizierte Hardware als ACS-Host, falls gerechtfertigt.

  • Verwenden Sie straffe Filter, um die Anzahl der rauschbedingten Sicherheitsereignisse, die in die Datenbank eingefügt werden, zu senken.

  • Planen Sie Ihre Windows-Überwachungsrichtlinie sorgfältig, sodass auf den überwachten Systemen nur relevante Ereignisse protokolliert werden.

  • Aktivieren Sie die ACS-Weiterleitung nur auf notwendigen Systemen.

  • Konfigurieren Sie Sicherheitsereignisprotokolle mit ausreichend Speicherplatz, sodass bei einem Verlust der Kommunikation mit der ACS-Sammlung die Sicherheitsereignisprotokolldatei nicht am Ende umbricht und vorausgehende Ereignisse überschrieben werden mit dem Ergebnis, dass Ereignisdaten verloren gehen.