Einführung in das Operations Manager 2007 R2
Werbung
Operations Manager 2007 R2Entwurfshandbuch Microsoft Corporation Datum der Veröffentlichung: Mai 2009 Autor Christopher Fox Die in diesem Dokument enthaltenen Informationen stellen die behandelten Themen aus der Sicht der Microsoft Corporation zum Zeitpunkt der Veröffentlichung dar. Da Microsoft auf sich ändernde Marktanforderungen reagieren muss, stellt dies keine Verpflichtung seitens Microsoft dar, und Microsoft kann die Richtigkeit der hier dargelegten Informationen nach dem Zeitpunkt der Veröffentlichung nicht garantieren. Dieses Dokument dient nur zu Informationszwecken. MICROSOFT SCHLIESST FÜR DIESES DOKUMENT JEDE GEWÄHRLEISTUNG AUS, SEI SIE AUSDRÜCKLICH, KONKLUDENT ODER GESETZLICH GEREGELT, ABER ABDINGBAR. Die Benutzer sind verantwortlich für das Einhalten aller anwendbaren Urheberrechtsgesetze. Ungeachtet der Anwendbarkeit der entsprechenden Urheberrechtsgesetze darf ohne ausdrückliche schriftliche Erlaubnis der Microsoft Corporation kein Teil dieses Dokuments für irgendwelche Zwecke vervielfältigt oder in einem Datenempfangssystem gespeichert oder darin eingelesen werden, unabhängig davon, auf welche Art und Weise oder mit welchen Mitteln (elektronisch, mechanisch, durch Fotokopieren, Aufzeichnen, usw.) dies geschieht. Es ist möglich, dass Microsoft Rechte an Patenten bzw. angemeldeten Patenten, an Marken, Urheberrechten oder sonstigem geistigen Eigentum besitzt, die sich auf den fachlichen Inhalt dieses Dokuments beziehen. Das Bereitstellen dieses Dokuments gibt Ihnen jedoch keinen Anspruch auf diese Patente, Marken, Urheberrechte oder auf sonstiges geistiges Eigentum, es sei denn, dies wird ausdrücklich in den schriftlichen Lizenzverträgen von Microsoft eingeräumt. Die in den Beispielen verwendeten Firmen, Organisationen, Produkte, Domänennamen, E-MailAdressen, Logos, Personen, Orte und Ereignisse sind frei erfunden, soweit nichts anderes angegeben ist. Jede Ähnlichkeit mit bestehenden Firmen, Organisationen, Produkten, Domänen, Personen, Orten, Ereignissen, E-Mail-Adressen und Logos ist rein zufällig und nicht beabsichtigt. © 2009 Microsoft Corporation. Alle Rechte vorbehalten. Microsoft, Active Directory, ActiveSync, Internet Explorer, JScript, SharePoint, SQL Server, Visio, Visual Basic, Visual Studio, Win32, Windows, Windows PowerShell, Windows Server und Windows Vista sind Marken der Microsoft-Gruppe. Alle anderen Marken sind Eigentum ihrer jeweiligen Inhaber. Revisionsverlauf Veröffentlichungsdatum Änderungen Mai 2009 Die Operations Manager 2007 R2-Version dieses Handbuchs enthält die folgenden Aktualisierungen und Ergänzungen: Die Dokumentenroadmap wurde entfernt. Sicherheitsinformationen zur UNIX- oder Linux-Überwachung sowie Leistungs- und Veröffentlichungsdatum Änderungen Bereichsangaben wurden hinzugefügt. Bereichsangaben wurden aktualisiert. Inhalt Einführung in das Operations Manager 2007 R2-Entwurfshandbuch ............................................. 7 Übersicht über Operations Manager 2007 ................................................................................... 8 Ermitteln der Systemanforderungen für Operations Manager 2007 .......................................... 19 Abbilden der Anforderungen in einem Entwurf für Operations Manager 2007 .......................... 24 Entwickeln eines Implementierungsplans für Operations Manager 2007 .................................. 46 Einführung in das Operations Manager 2007 R2-Entwurfshandbuch Jede IT-Umgebung ist spezifisch, und daher muss die für ihre Überwachung verwendete Infrastruktur dieser Spezifik Rechnung tragen, um effizient zu sein. Es gibt keine "allgemeingültige" Lösung für die Überwachung, die ein zufrieden stellendes Ergebnis liefert. Andererseits können Unternehmen es sich nicht leisten, unternehmensspezifische Überwachungslösungen von Grund auf neu zu entwickeln. Der hierfür erforderliche Kapital- und Arbeitsaufwand verbietet dies. Microsoft System Center Operations Manager 2007 bietet einen Mittelweg zwischen diesen zwei Möglichkeiten, indem die Bausteine bereitgestellt werden, die für eine Ihren betrieblichen Erfordernissen entsprechende Lösung benötigt werden. Wie Sie die Bausteine anordnen und welche Beziehungen Sie zwischen ihnen herstellen, bleibt Ihrer Entscheidung überlassen und wird Topologieplanung genannt. Ihre Topologie muss sich an den betrieblichen, technologischen, die Sicherheit betreffenden und rechtlichen Erfordernissen Ihres Unternehmens orientieren, und der Entwurfsvorgang ist die Phase, in der die Spezifik Ihrer konkreten Umgebung in Ihre Operations Manager-Topologie integriert wird. Bevor Sie mit dem Entwurf beginnen, müssen Sie die Sicherheitsaspekte von Operations Manager 2007 vollständig verstanden haben, einschließlich der erforderlichen Konten und Gruppen und der für sie benötigten Berechtigungen. Für Ihren Entwurfsvorgang ist es äußerst wichtig, dass Sie die Rollen und die rollenbasierte Sicherheit, die in Operations Manager 2007 implementiert sind, sowie die Implikationen der obligatorischen gegenseitigen Authentifizierung verstehen Eine vollständige Einführung zur Operations Manager 2007-Sicherheit finden Sie im Operations Manager 2007-Sicherheitshandbuch unter http://go.microsoft.com/fwlink/?LinkId=64017. Operations Manager 2007 bietet einen modellbasierten Überwachungsansatz. Bei einer modellbasierten Verwaltung werden alle Elemente, die an der Bereitstellung einer Funktion oder eines Dienstes in Ihrem Unternehmen beteiligt sind, als Modelle dargestellt. Weitere Informationen zur modellbasierten Verwaltung finden Sie im Operations Manager 2007Schlüsselkonzeptehandbuch unter http://go.microsoft.com/fwlink/?LinkId=124799. Über dieses Handbuch Dieses Handbuch besteht aus Abschnitten, die Sie durch den Entwurfs- und Testvorgang zur Implementierung von Operations Manager 2007 führen. Dieses Handbuch soll Ihnen dabei helfen, die Komponenten der Bausteinebene in Operations Manager 2007 zu verstehen, indem Zusammenfassungen zu diesen Rollen gegeben werden. Es hilft Ihnen, die richtigen Fragen zu formulieren, um sicherzustellen, dass Ihr Entwurf den Anforderungen Ihres Unternehmens genügt. Es sorgt dafür, dass Sie die grundlegendsten Fragen des Entwurfs beantwortet haben, um sicherzustellen, dass Ihr Entwurf flexibel und skalierbar ist. Es hilft Ihnen, mithilfe von Daten 7 aus dem Leistungs- und Größen-Handbuch die Operations Manager 2007-Topologie zu planen und ihre Größe anzupassen. Es enthält eine Anleitung, wie Sie Ihren Entwurf in einer Testumgebung überprüfen können. Nachdem Sie dieses Handbuch durchgearbeitet haben, verfügen Sie über ein detailliertes Infrastrukturdiagramm und eine geplante Konfiguration der Operations Manager 2007Komponenten. Sie haben dann diese Blaupausen in einer Testumgebung überprüft und sind bereit, mit der Pilotbereitstellung in der Produktion zu beginnen. Hinweise für Ihr weiteres Vorgehen finden Sie dann im Operations Manager 2007-Bereitstellungshandbuch. Bitte beachten Sie, dass dieses Handbuch dazu bestimmt ist, Ihnen eine Anleitung zu geben. Die Entscheidungen, die Sie treffen, und der Entwurf, zu dem Sie schließlich gelangen, müssen letzten Endes Ihren Bedürfnissen entsprechen. Das Handbuch hilft sicherzustellen, dass Sie über alle Informationen verfügen, die Sie benötigen, um für Ihre spezielle Situation die besten Entscheidungen zu treffen. Grundlegendes zum Operations Manager 2007Entwurfsvorgang Das Entwerfen einer Operations Manager-Implementierung ist nichts anderes als ein Prozess, bei dem Folgendes erreicht werden soll: Verstehen der Features und Funktionen, die von Operations Manager 2007 bereitgestellt werden. Verstehen der betrieblichen und technischen Anforderungen Ihres Unternehmens, der aktuellen Infrastruktur und Ihrer aktuellen Überwachungsverfahren. Abbilden dieser Anforderungen auf eine Operations Manager 2007-Infrastruktur, die ihnen entspricht. Überprüfen des Entwurfs der Operations Manager 2007-Infrastruktur in einer Testumgebung. Während dieses Vorgangs müssen Sie eine Größen- und Kapazitätsplanung für Ihre Verwaltungsgruppen durchführen; die dafür benötigten Daten sind in diesem Handbuch enthalten. Übersicht über Operations Manager 2007 Die Infrastruktur von Operations Manager 2007 setzt sich aus bestimmten Kernkomponenten zusammen, die implementiert werden müssen, sowie aus einer Reihe optionaler Komponenten und Funktionen, die Sie nach Bedarf implementieren können. In diesem Abschnitt werden diese Komponenten und Funktionen entsprechend ihrer erforderlichen oder optionalen Klassifizierung beschrieben. Im Allgemeinen wird eine Komponente von Ihrem Quellmedium installiert, während eine Funktion konfiguriert werden muss, da zunächst die erforderlichen Komponenten für diese Funktion installiert werden müssen. 8 Erforderliche Serverrollen und Komponenten Die grundlegende Funktionseinheit für alle Operations Manager 2007-Implementierungen ist die Verwaltungsgruppe. Voraussetzung ist die Installation von Microsoft SQL Server 2005 SP1 oder höher oder Microsoft SQL Server 2008, die als Host für die OperationsManager-Datenbank dient. Die Basiskomponenten einer Verwaltungsgruppe sind die Betriebskonsole und mindestens ein Agent, der für überwachte Computer oder Geräte bereitgestellt wird. OperationsManager-Datenbank Die erste Komponente, die in allen Verwaltungsgruppen installiert werden muss, ist die OperationsManager-Datenbank. Diese erfordert eine Installation von Microsoft SQL Server 2005 SP1 oder höher oder Microsoft SQL Server 2008 SP1. In dieser Datenbank sind alle Konfigurationsdaten für Verwaltungsgruppe abgelegt. Zudem werden dort alle Überwachungsdaten gespeichert, die durch die Agents gesammelt und verarbeitet werden. Für eine optimierte Leistung von Operations Manager muss die Größe der OperationsManagerDatenbank kontrolliert verwaltet werden. Tests haben eine Größe von unter 50 GB als geeigneten Wert ergeben. Damit diese Grenze nicht überschritten wird, bietet Operations Manager 2007 einstellbare Parameter, die für eine automatische Löschung älterer, nicht mehr gebrauchter Daten sorgen. Da in einer Verwaltungsgruppe nur eine Operationsmanager-Datenbank vorhanden sein kann, muss sie funktional für die gesamte Verwaltungsgruppe sein. Da eine einzige Operationsmanager-Datenbankinstanz eine zentrale Fehlerstelle darstellen kann, besteht die Möglichkeit, die Operationsmanager-Datenbank in einen Failovercluster eines Clusterdienstes (früher unter der Bezeichnung MSCS geläufig) zu setzen. Darüber hinaus kann der Protokollversand konfiguriert werden, so dass aktuelle Betriebsdaten und Konfigurationsinformationen an einen anderen Microsoft SQL Server der gleichen Version, der ein Duplikat der primären OperationsManager-Datenbank enthält, gesendet werden können. Kommt es zu einem Fehler in der primären Datenbank, kann das Duplikat nach einer Aktualisierung die Funktion übernehmen. Stammverwaltungsserver Der Stammverwaltungsserver (RMS) ist ein spezialisierter Verwaltungsservertyp in einer Verwaltungsgruppe und gleichzeitig der erste Verwaltungsserver, der in einer Verwaltungsgruppe installiert wird. Pro Verwaltungsgruppe kann immer nur ein Stammverwaltungsserver aktiv sein. Kurz ausgedrückt ist der Stammverwaltungsserver der Fokuspunkt für die Administration, Verwaltung und Konfiguration der Verwaltungsgruppe sowie für die Kommunikation mit den Agents, der OperationsManager-Datenbank und anderen Datenbanken in der Verwaltungsgruppe. Zudem dient der Stammverwaltungsserver als Ziel für die Betriebskonsole und als bevorzugtes Ziel für die Webkonsolen. Der Stammverwaltungsserver fungiert als Host für die System Center-Datenzugriffs- und System Center-Verwaltungskonfigurationsdienste. Diese Dienste werden nur auf dem 9 Stammverwaltungsserver ausgeführt. Der System Center-Datenzugriffsdienst bietet für alle Clients einen sicheren Zugriff auf die OperationsManager-Datenbank, einschließlich Betriebskonsole, Betriebsshell und Webkonsole. Der System CenterVerwaltungskonfigurationsdienst dient zur Berechnung und Verteilung der Konfigurationsdaten aller Verwaltungsserver und Agents. Über diesen Dienst wird die Zuordnung der Management Packs an die Komponenten bestimmt. Gleichermaßen wie die OperationsManager-Datenbank kann die RMS-Rolle in einem MSCSFailovercluster installiert werden, um eine Hochverfügbarkeit zu erreichen. Darüber hinaus kann anderen Verwaltungsservern in der Verwaltungsgruppe (falls vorhanden) manuell die RMS-Rolle übertragen werden. Agent Bei einem Operations Manager 2007-Agent handelt es sich um einen Dienst, der für einen zu überwachenden Computer bereitgestellt werden kann. Auf dem überwachten Gerät wird ein Agent als System Center-Verwaltungsdienst aufgelistet. Jeder Agent sendet Informationen an einen Verwaltungsserver innerhalb der Verwaltungsgruppe. Dieser Verwaltungsserver wird als primärer Verwaltungsserver des Agents bezeichnet. Agents überwachen Datenressourcen auf dem überwachten Gerät und sammeln entsprechend der Konfiguration, die sie von ihren Verwaltungsservern erhalten, Informationen. Agents berechnen zudem den Integritätsstatus des überwachten Geräts und senden diese Informationen zurück an den Verwaltungsserver. Wenn sich der Integritätsstatus eines überwachten Geräts ändert oder andere Krtiterien erfüllt werden, kann über den Agent eine Warnung generiert werden. Auf diese Weise werden Benutzer über aufgetretene Probleme, die behandelt werden müssen, informiert. Auf Agents stehen zudem verschiedene Aktionstypen zur Verfügung, die Sie bei der Diagnose oder Korrektur von Problemen unterstützen können. Durch die Übermittlung von Integritätsdaten an den Verwaltungsserver liefert ein Agent ein aktuelles Bild über den Integritätsszustand des überwachten Geräts und der darauf befindlichen Anwendungen. Geräte können auch ohne Agent überwacht werden. In diesem Fall führt der Verwaltungsserver eine Fernüberwachung durch. Betriebskonsole Die Betriebskonsole ist eine zentrale, einheitliche Benutzeroberfläche für die Interaktion mit dem Operations Manager 2007-System. Sie bietet Zugriff auf Überwachungsdaten, grundlegende Konfigurationstools für Management Packs, Operations Manager 2007-Berichte sowie auf alle Steuerelemente und Werkzeuge, die für die Verwaltung von Operations Manager 2007 erforderlich sind. Der Arbeitsbereich auf der Betriebskonsole kann angepasst werden. Für den Zugriff auf die Betriebskonsole muss das Active Directory-Benutzerkonto des Benutzers einer Operations Manager 2007-Benutzerrolle zugewiesen sein. Eine Benutzerrolle enthält einen Gerätebereich, für den ein Zugriff gestattet ist, sowie ein Benutzerprofil, in dem die zulässigen Aktiväten der Rolle innerhalb des definierten Bereichs festgelegt sind. Für die Betriebskonsole gilt eine rollenbasierte Sicherheit, mit der ein Operations Manager-Administrator definieren kann, 10 welche Komponenten ein bestimmter Benutzer auf der Konsole anzeigen und welche Aktionen der Benutzer in Bezug auf diese Komponenten ausführen kann. Weitere Informationen finden Sie in diesem Dokument im Abschnitt "Rollenbasierte Sicherheit". Management Packs Management Packs enthalten eine Definition zur Integrität einer Anwendung, wie durch die Anwendungsentwickler festgelegt. Nach dem Import eines Management Packs in das Operations Manager-System können die entsprechenden Agents die Integrität einer Anwendung überwachen, Warnungen generieren, wenn relevante Probleme in der Anwendung auftreten, und Aktionen in der Anwendung und der unterstützenden Infrastruktur zur weiteren Diagnose oder zur Wiederherstellung des Integritätszustands der Anwendung durchführen. Ohne ein anwendungs-, betriebssystem- oder gerätespezifisches Management Pack ist das Operations Manager 2007System nicht in der Lage, eine Überwachung durchzuführen, da entsprechenden Entitäten nicht erkannt werden. Optionale Serverrollen und Komponenten Diese zusätzlichen Serverrollen erweitern die Funktionalität einer Verwaltungsgruppe. Die meisten dieser Komponenten werden getrennt von den erforderlichen Kernkomponenten installiert. Manche können jedoch auch gleichzeitig installiert werden. Umfassende Angaben zur Installation von Operations Manager 2007-Komponenten können Sie dem Operations Manager 2007-Bereitstellungshandbuch entnehmen. Verwaltungsserver Die primären Aufgaben eines Verwaltungsservers liegen im Empfang von Konfigurationsdaten und Management Packs über den Stammverwaltungsserver und in der Verteilung dieser Informationen an die Agents, die wiederum Informationen an den Verwaltungsserver übermitteln. Verwaltungsserver führen keine der speziellen Funktionen eines Stammverwaltungsservers (RMS) aus. Einem Verwaltungsserver kann die RMS-Rolle übertragen werden, wenn der ursprüngliche Stammverwaltungsserver ausfällt. Voraussetzung ist jedoch, dass der Verwaltungsserver bereits vor dem RMS-Ausfall in der Verwaltungsgruppe vorhanden war. Die Installation mehrerer Verwaltungsserver in einer Verwaltungsgruppe bietet zusätzliche Kapazität für die Agentverwaltung. Neben der Skalierbarkeit kann mit dem Einsatz zusätzlicher Verwaltungsserver in einer Verwaltungsgruppe eine Ausfallsicherheit konfiguriert werden. Wenn ein Agent die Verbindung zu seinem primären Verwaltungsserver verliert, greift dann ein Failovermechnismus, der es möglich macht, dass die Agentdaten an einen anderen Verwaltungsserver übertragen werden können. Der Verwaltungsserver kann auch zu Fernüberwachungszwecken genutzt werden (URLÜberwachung und plattformübergreifende Überwachung). In einer zusätzlichen Rolle kann ein Verwaltungsserver als Host für den Überwachungssammlungsserver (ACS, Audit Collection Service) fungieren. Der ACS-Sammlungsserver kann nur auf einem Verwaltungsserver oder einem Gatewayserver installiert werden. Weitere Informationen finden Sie im Abschnitt 11 "Überwachungssammeldienst (ACS)" in diesem Dokument. Eine weitere Rolle ist der Verwaltungsserver für die AEM-Freigabe. Entsprechende Ausführungen folgen. Gatewayserver Bevor ein Datenaustausch erfolgen kann, erfordert das Operation Manager 2007-System eine gegenseitige Authentifizierung von Verwaltungsservern und Agents sowie die Einrichtung eines verschlüsselten Kommunikationskanals. Das Standard-Authentifizierungsprotokoll ist Kerberos. Wenn sich Agent und Verwaltungsserver in der gleichen Active Directory-Gesamtstruktur oder in Gesamtstrukturen mit Gesamtstruktur-Vertrauensstellung befinden, erfolgt die gegenseitige Authentifizierung automatisch. Dies leitet sich aus der Tatsache ab, dass Keberos das StandardAuthentifizierungsprotokoll in Active Directory ist. Befinden sich Agents und Verwaltungsserver nicht innerhalb der gleichen KerberosVetrauensgrenze (d. h., nicht in der gleichen Active Directory-Gesamtstruktur oder nicht in Gesamtstrukturen mit Gesamtstruktur-Vertauensstellung) müssen zertifikatbasierte Authentifizierungsmechanismen verwendet werden. In dieser Situation muss für jene Agents und für die Verwaltungsserver, an die sie Daten übermitteln, ein Zertifikat ausgegeben und verwaltet werden. Wenn darüber hinaus zwischen Agents und Verwaltungsserver eine Firewall geschaltet ist, stehen zwei Möglichkeiten zur Verfügung: entweder werden die Firewallregeln angepasst, damit alle als Host für einen Agent dienenden Computer direkt über die Firewall kommunizieren können, oder der eingehende Operations Manager-Kommunikationsport wird geöffnet. Mit dem Einsatz von Operation Manager 2007-Gatewayservern kann der erforderliche Verwaltungsaufwand für die Aufrechterhaltung der Kommunikation zwischen durch eine Vertrauensgrenze getrennten Agents und Verwaltungsservern erheblich reduziert werden. Der Gatewayserver agiert als Proxy für die Agentkommunikation. Der Gatewayserver wird innerhalb der Vertrauensgrenze (diese kann einer Domäne entsprechen), in der sich die Agents befinden, implementiert, so dass für alle Agents eine Kommunikation möglich ist. Unter Nutzung des Computerzertifikats erfolgt die gegenseitige Authentifizierung mit dem Verwaltungsserver und die anschließende Weiterleitung der Agent-zu-Verwaltungsserver- und der Verwaltungsserver-zuAgent-Kommunikation. Die erfordert nur ein Zertifikat für den Verwaltungsserver und ein Zertifikat für das Gateway. Im Firewallszenario müssen für die Kommunikation miteinander nur der Gatewayserver und der Verwaltungsserver autorisiert werden. In einer Verwaltungsgruppe können im Sinne der Skalierbarkeit und zur Bereitstellung von Failovermechanismen mehrere Gatewayserver installiert werden. Sollte ein Agent die Verbindung zu seinem Gatewayserver verlieren, greifen dann die Failovermechanismen, und der Agent kann einen anderen Gatewayserver innerhalb seiner Verwaltungsgruppe und innerhalb seiner Vertrauensgrenze nutzen. Gleichermaßen können Gatewayserver für ein Failover zwischen Verwaltungsservern in einer Verwaltungsgruppe konfiguriert werden. Diese Konfiguration bietet auf diese Weise vollständig redundante Kommunikationskanäle für Agents, die außerhalb der Vertrauensgrenze eines Verwaltungsservers liegen. 12 Webkonsolenserver Der Webkonsolenserver bietet eine Schnittstelle zur Verwaltungsgruppe, auf die über einen Webbrowser zugegriffen werden kann. Die Webkonsole bietet jedoch nicht den vollen Funktionsumfang der Betriebskonsole. Es können lediglich die Ansichten Überwachung, Berichterstattung und Mein Arbeitsbereich aufgerufen werden. Die Webkonsole bietet Zugriff auf alle Überwachungsdaten und Tasks, die als Aktionen in Bezug auf überwachte Computer über die Betriebskonsole ausgeführt werden können. Der Zugriff auf Daten über die Webkonsole unterliegt den gleichen Beschränkungen wie der Zugriff auf Inhalte über die Betriebskonsole. Management Pack-Konfigurationskonsole Bei der Operations Manager 2007 Konfigurationskonsole handelt es sich um eine eigenständige Anwendung, die umfangreichere Konfigurationsoptionen für Management Packs bietet als im Konfigurationsbereich der Betriebskonsole zur Verfügung stehen. Mithilfe der Konfigurationskonsole können Sie neue Management Packs erstellen, vorhandene Management Packs anzeigen und modifizieren, die Integrität von Management Packs verifizieren sowie Importe und Exporte von Management Packs an bzw. von Verwaltungsgruppen durchführen. Die Operations Manager 2007 Konfigurationskonsole können Sie unter folgender Adresse herunterladen: http://go.microsoft.com/fwlink/?LinkId=136356. Berichterstattungs-Data Warehouse Im Berichterstattungs-Data Warehouse werden Überwachungs- und Warnungdaten für Verlaufsanalysezwecke gespeichert. Die Daten der Verwaltungsserver werden gleichzeitig in die Data Warehouse- und die OperationsManager-Datenbank geschrieben, so dass die generierten Berichte stets aktuelle Daten enthalten. Im Data Warehouse werden Leistungsdaten auf stündlicher oder täglicher Basis zusammengefasst. Auf diese Weise können Langzeitrendberichte schneller ausgeführt werden. Außerdem müssen zur Unterstützung der Langzeittrendberichterstattung weit weniger Daten aufbewahrt werden. Im Berichterstattungs-Data Warehouse können Daten von mehreren Verwaltungsgruppen empfangen werden. Zusammengefasste Ansichten der Daten sind in Berichten möglich. Berichtsserver Die Komponente Operations Manager-Berichtsserver wird auf einer Instanz von Microsoft SQL 2005 Reporting Services SP1 oder später oder Microsoft SQL Server 2008 SP1 Reporting Services installiert. Sie dient zur Erstellung und Präsentation der Berichte aus den Daten, die aus dem Berichterstattungs-Data Warehouse abgerufen werden. Der Zugriff auf alle Berichte erfolgt über die Betriebskonsole, d. h., der Zugriff wird über die rollenbasierte Sicherheit kontrolliert. Überwachungssammeldienste (ACS) Bei den Überwachungssammeldiensten (ACS) handelt es sich um eine hochperformante, sichere Lösung für die Sammlung und Archivierung von Ereignissen aus dem Sicherheitsereignisprotokoll überwachter Computer. Ereignisse werden in Microsoft SQL Server 2005 SP1 oder später oder 13 Microsoft SQL Server 2008 SP1 in einer separaten Datenbank, der ACS-Datenbank (weitere Ausführungen folgen), gespeichert. ACS sammelt alle Ereignisse, die in das Sicherheitsereignisprotokoll von Computern geschrieben wurden. Voraussetzung ist, dass auf diesen die ACS-Weiterleitung aktiviert wurde. Die Ereignisse werden von den überwachten Computern an den ACS-Sammlungsserver weitergeleitet, der auf einem Verwaltungsserver ausgeführt wird, die erhaltenen Daten verarbeitet und diese in die ACS-Datenbank schreibt. Die Ereignisse werden nahezu in Echtzeit und verschlüsselt von den Weiterleitungsdiensten an den Sammlungsserver übertragen. Mithilfe der ACS-Berichterstattung, einer separaten Komponente, werden dann aus den gespeicherten Daten Berichte generiert. Der Schlüssel zu einer effektiven Nutzung der ACS-Funktion liegt in der Entwicklung einer soliden Windows-Überwachungsgruppenrichtlinie, die als Domänengruppenrichtlinie implementiert wird. Weitere Informationen zu den zu Windows-Überwachungsgruppenrichtlinien und zur ACS-Implementierung finden Sie unter http://go.microsoft.com/fwlink/?LinkId=144734. ACS-Weiterleitung Die ACS-Weiterleitung ist integrierter Bestandteil des Operations Manager 2007-Agents, so dass keine separate Bereitstellung oder Konfiguration erforderlich ist. Die ACS-Weiterleitung wird als ACS-Weiterleitungsdienst angezeigt und ist standardmäßig deaktiviert. Auf einem individuellen Computer oder auf einer Gruppe von Computern wird die ACS-Weiterleitung über einen Task in der Betriebskonsole aktiviert. ACS-Sammlungsserver Die Hauptaufgabe des ACS-Sammlungsservers liegt in der Sammlung, Filterung und Vorverarbeitung aller im Windows-Sicherheitsereignisprotokoll aufgezeichneter Daten, die anschließend in die Datenbank eingefügt werden. Da der ACS-Server alle Sicherheitsereignisse fast in Echtzeit sammelt, empfängt das System große Datenmengen über die Weiterleitungen. Nicht alle diese Informationen sind von Interesse für Ihr Unternehmen, wie in der WindowsÜberwachungsgruppenrichtlinie für Ihr Unternehmen definiert. Der Filterungsmechanismus der Sammlung ermöglicht Ihnen, anzugeben, welche Ereignisse zur Langzeitspeicherung in die ACSDatenbank geschrieben werden sollen. Für den ACS-Sammlungsserver steht ein separates Installationsprogramm zur Verfügung, das unabhängig von anderen Operations Manager-Komponenten ist. Ein ACS-Sammlungsserver kann nur auf einem vorhandenen Verwaltungsserver oder einem Stammverwaltungsserver, wenn Sie keine weiteren Verwaltungsserver installiert haben, installiert werden. Ein ACSSammlungsserver kann, je nach Serverrolle und Windows-Überwachungsgruppenrichtlinie, Hunderte bis Tausende von Servern und Zehntausende von Arbeitsstationen unterstützen. Es besteht jedoch eine Eins-zu-Eins-Beziehung zwischen ACS-Sammlungsserver und ACSDatenbank (weitere Ausführungen folgen im nächsten Abschnitt). Wenn Ihr Unternehmen im Sinne der Skalierbarkeit oder aus Kontrollgründen zusätzliche ACS-Sammlungen erfordert, muss pro ACS-Sammlung eine ACS-Datenbank vorhanden sein. 14 ACS-Datenbank Nach der Vorverarbeitung der Daten durch den ACS-Sammlungsserver werden diese in die zugehörige ACS-Datenbank geschrieben. Dabei handelt es sich einfach um eine Datenbank, die auf einer Microsoft SQL Server 2005 SP1-oder SP2-Instanz angelegt wurde. Da es sich um eine SQL-Standarddatenbank handelt, kann Sie im Sinne einer Hochverfügbarkeit geclustert werden. Um der Eins-zu-Eins-Beziehung zwischen Sammlungsservern und Datenbanken Rechnung zu tragen, können Sie über benannte Instanzen mehrere ACS-Datenbanken auf einem zentralen SQL Server 2005 anlegen, solange dieser der zusätzlichen Last gewachsen ist. Weitere Informationen zur Dimensionierung und Kapazitätenplanung für ASC finden Sie in einem entsprechenden Absatz im weiteren Verlauf dieses Handbuchs. ACS-Berichterstattung Auch bei der ACS-Berichterstattung handelt es sich um eine separat zu installierende Komponente. Es steht eine Reihe vorkonfigurierter Berichte zur Verfügung. Voraussetzung für die Installation der ACS-Berichterstattung ist eine vorhandene Instanz von SQL Server 2005 SP1 (oder später) Reporting Services oder Microsoft SQL Server 2008 Reporting Services. Dabei kann es sich um eine eigenständige Instanz handeln, oder Sie installieren die ACSBerichterstattung zusammen mit Operations Manager 2007 und gehen einen Kompromiss ein. Wenn Sie die ACS-Berichterstattung auf die gleiche Reporting Services-Instanz setzen wie die Operations Manager 2007-Berichterstattung, wird die ACS-Berichterstattung vollkommen in die Operations Manager-Berichterstattung integriert. Dies hat einen geringeren Verwaltungsaufwand zur Folge, da jeder Benutzer mit Zugriffsrechten auf die Operations Manager-Berichte automatisch Zugriffsrechte auf die ACS-Berichte hat. Manche Unternehmen empfinden diese Konfiguration möglicherweise als nicht wünschenswert und entscheiden sich für eine Installation der ACS-Berichterstattung auf einer separaten SQL Server Reporting-Instanz. In diesem Fall müssen Sie eigene Sicherheitsgruppen und -rollen definieren. Dies bedingt zwar einerseits einen höheren Verwaltungsaufwand, andererseits erreichen Sie eine extrem strikte Kontrolle über den Zugriff auf ACS-Daten. Proxyagent Operations Manager 2007 bietet die Möglichkeit, Netzwerkgeräte über SNMP v2, Computer, die mit anderen Betriebssystemem als Windows aufgeführt werden, und Computer ohne Agents zu überwachen. In diesen Fällen führt ein anderer Computer, auf dem ein Agent installiert ist, eine Fernüberwachung durch. Der Computer, der die Fernüberwachung durchführt, wird als Proxagent bezeichnet. Bei dem Agent, der als Proxy für die Überwachung anderer Geräte agiert, handelt es sich um einen Operations Manager-Standardagent. Die Konfiguration unterscheidet sich nur wenig: Wählen Sie in den Eigenschaften des Agents die Option Dieser Agent soll als Proxyagent fungieren und verwaltete Objekte auf anderen Computern ermitteln. Anschließend konfigurieren Sie das ohne Agent verwaltete Gerät, um den zu nutzenden Proxyagent zuzuweisen. Weitere Informationen zur Agentbereitstellung und zur Geräteverwaltung finden Sie im Operations Manager 2007-Betriebshandbuch. 15 Operations Manager 2007-Befehlsshell Im Jahr 2006 führte Microsoft die Windows PowerShell Befehlszeilenschnittstelle für die Nutzung auf den Betriebssystemen Windows Server 2003, Windows Server 2008, Windows XP und Vista ein. Diese Schnittstelle wurde für die Automatisierung von Aufgaben durch Systemadministaroren entwickelt. Die zugehörige Benutzeroberfläche bietet eine interaktive Eingabaufforderung sowie eine Skriptumgebung, die kombiniert oder unabhängig voneinander genutzt werden können. Die Objekte, mit denen Sie in der PowerShell interagieren, werden als "Commandlets" bezeichnet. Diese Commandlets bestehen aus binären systemeigenen Befehlen im Windows PowerShellCode. Windows PowerShell-Befehle sind für den Umgang mit Objekten bestimmt. Dies sind strukturierte Informationen, bei denen es sich um mehr handelt als um bloße Zeichenketten auf dem Bildschirm. Die Ausgaben der Befehle liefern stets Zusatzinformationen, die Sie bei Bedarf nutzen können. Bei der Operations Manager 2007-Befehlsshell handelt es sich um eine Gruppe von 203 Commandlets, die speziell für die Automatisierung administrativer Aufgaben in Operations Manager 2007 entwickelt wurde. Die Befehlsshell kann auf jedem Computer installiert werden, auf dem die Betriebskonsole implementiert wird. Funktionen Funktionen sind standardmäßig vorhanden und müssen bei Bedarf für die Nutzung nur konfiguriert werden. Die Möglichkeit, in Operations Manager Funktionen nach eigenem Bedarf zu konfigurieren, unterstreicht die Flexibilität des Systems. Plattformübergreifende Überwachung (UNIX- oder Linux-basierte Computer) Mit Operations Manager 2007 R2-Verwaltungsservern und -Gatewayservern können UNIX- und Linux-Computer überwacht werden. Eine umfassende Liste der UNIX- und Linux-basierten Betriebssysteme, die überwacht werden können, finden Sie unter "Operations Manager 2007 R2 Supported Configurations" (Unterstützte Konfigurationen in Operations Manager 2007 R2) unter http://go.microsoft.com/fwlink/?LinkID=144400. Bei der plattformübergreifenden Überwachung stellt der auf dem Verwaltungsserver oder Gatewayserver ausgeführte System Center-Verwaltungsdienst die gesamte Überwachungsintelligenz zur Verfügung. Die Kommunikation zwischen dem überwachenden System Center-Verwaltungsdienst und dem überwachten Computer erfolgt über eine WSMANKommunikationsschicht, die sich auf beiden Komponenten befindet. Es ist eine zwingende Voraussetzung, dass die WSMAN-Schicht auf dem überwachten Computer installiert ist. Die Kommunikation zwischen den WSMAN-Schichten erfolgt über TCP-Port 1270 und geht immer vom Verwaltungsserver oder vom Gatewayserver aus. In einigen Fällen, wenn z. B. keine WSMAN-Schicht auf dem überwachten Gerät vorhanden ist oder ein Fehler auftritt, kann die Kommunikation über SSH TCP 22 erfolgen. SSH kann für die Installation der WSMAN-Schicht oder zu Diagnosezwecken genutzt werden. 16 Ausnahmeüberwachung ohne Agent Wenn auf einem Computer mit einem Windows-Betriebssystem ein Anwendungsfehler auftritt, kann der Watson-Dienst den Fehler aufzeichnen und die Fehlerinformationen an Microsoft senden, um die Ursache des Problems aufzudecken. In der Regel erfolgt diese auf jedem Computer auf individueller Basis. Da die Fehlerüberwachung und -meldung auf individueller Basis stattfindet, haben IT-Administratoren keine Einsicht in diese Ausnahmen, die in Ihrem Unternehmen auftreten. Wenn die Funktion Ausnahmeüberwachung ohne Agent aktiviert ist, können alle Ausnahmen an einen Verwaltungsserver in Ihrer Verwaltungsgruppe gesendet und dort zusammengefasst werden. Da sie dann konzentriert an einem zentralen Ort archiviert werden, kann Ihr Unternehmen diese Daten für die Analyse und Diagnose von Desktop- und Serveranwendungsfehlern, wie sie in ihrem gesamten Unternehmen auftreten, nutzen. Bei Bedarf können Sie den Verwaltungsserver auch für die Weiterleitung der Ausnahmenüberwachungsdaten zu Analysezwecken an Microsoft konfigurieren. Weitere Informationen zu diesem Thema finden Sie unter http://go.microsoft.com/fwlink/?LinkID=11699. 17 Connector Framework Beim Connector Framework handelt es sich um eine Anwendungsprogrammierungsschnittstelle (Application Programming Interface, API), mit der die Operations Manager-Funktionalität offen gelegt wird, um eine Integration mit anderen Verwaltungsprodukten oder anderen Technologien, wie z. B. Fehlerticketsysteme, zu ermöglichen. So wird die Entwicklung von Connectoren ermöglicht, die bidirektional Informationen mit Verwaltungsservern austauschen können. Primär interagiert das Connector Framework mit dem System Center-Datenzugriffsdienst auf dem Stammverwaltungsserver. Weitere Informationen zur Entwicklung von Anwendungen, die das Operations Manager 2007-Connector Framework nutzen, finden Sie unter Operations Manager 2007 SDK. Konzepte Bei der Planung Ihrer Topologie ist ein Verständnis des Konzepts der rollenbasierten Sicherheit, wie sie in Operations Manager implementiert ist, unumgänglich. Rollenbasierte Sicherheit Über die rollenbasierte Sicherheit wird gesteuert, welche Objekte ein Benutzer sehen kann und welche Aktionen er in Bezug auf diese Objekte ausführen darf. Eine Rolle besteht aus zwei Teilen. Der erst Teil ist ein Bereich, der die sichtbaren oder zugreifbaren Objekte enthält. So könnte beispielsweise ein Bereich definiert werden, der nur Domänencontroller oder SQL Server enthält. Der zweite Teil ist ein Profil. In jedem Profil werden Aktionen definiert, die in Bezug auf die sichtbaren Objekte ausgeführt werden können. Standardmäßig bietet Operations Manager 2007 folgende fünf Profile: Administrator — Dieses Profil enthält alle in Operations Manager verfügbaren Rechte. Erweiterter Operator — Dieses Profil verfügt über eingeschränkte Rechte zur Anpassung der Überwachungskonfiguration durch Konfigurieren von Außerkraftsetzungen in Regeln oder Monitoren. Autor — Dieses Profil besitzt die Berechtigung, die Überwachungskonfigurationselemente, wie Regeln, Tasks, Monitore und Ansichten, zu konfigurieren. Operator — Dieses Profil bietet Zugriffsberechtigungen auf Warnungen, Ansichten und Tasks. Schreibgeschützter Operator — Dieses Profil bietet einen schreibgeschützten Zugriff auf Warnungen und Ansichten. Berichtsoperator — Dieses Profil enthält eine Lesezugriffsberechtigung für Operations Manager-Berichte. Operations Manager bietet zudem fünf vordefinierte Rollen, die jeweils einen globalen Geltungsbereich besitzen. Die Operations Manager-Administratorenrolle nutzt beispielsweise das Administratorprofil und verfügt über einen globalen Geltungsbereich, d. h. Inhaber dieser Rolle können alle Objekte in Operations Manager sehen und manipulieren. Für jedes der zuvor beschriebenen Profile gibt es entsprechende vordefinierte Rollen. 18 Zusätzlich zu den vordefinierten Rollen können Sie neue Rollen definieren, die auf den Profilen Erweiterter Operator, Autor, Operator und Schreibgeschützter Operator basieren. Bei der Erstellung einer neuen Rolle wählen Sie zunächst das entsprechende Profil. Anschließend legen Sie den Bereich der Objekte fest, auf den die Rolle Zugriff erhalten soll. Mit dieser Methode können Sie beispielsweise für Ihre Exchange-Administratoren eine Rolle erstellen, die auf dem Profil Operator basiert, deren Bereich jedoch auf Microsoft Exchange Server beschränkt ist. Wenn Sie die Exchange-Administratoren anschließend dieser Rolle zuweisen (entweder durch Mitgliedschaft in einer Active Directory-Gruppe oder durch ein individuelles Konto), können die Rollenbesitzer die Betriebskonsole öffnen, doch sie sehen nur die Excahnage Server und dürfen lediglich Aktionen auf Warnungen, Ansichten und Tasks ausführen, die in Zusammenhang mit Exchange stehen. Die rollenbasierte Sicherheit wird unabhängig von der Art, wie auf die Operations ManagerFunktionalität zugegriffen wird, ob über die Webkonsole oder die Befehlsshell, angewendet. Weitere Informationen zu Rollen und rollenbasierter Sicherheit finden Sie im Operations Manager 2007-Sicherheitshandbuch. Ermitteln der Systemanforderungen für Operations Manager 2007 Die Ermittlung der Anforderungen Ihres Unternehmens sind der nächste Schritt im Operations Manager-Entwurfsprozess. Die Anforderungen untergliedern sich in drei Kategorien: betriebliche Anforderungen, IT-Anforderungen und Optimierungsanforderungen oder Ziele. Das Zusammentragen der Anforderungen ist der wichtigste Einzelschritt bei der Erarbeitung des Operations Manager 2007-Entwurfs. Wenn Sie sich ein fundiertes Verständnis der bestehenden Anforderungen angeeignet haben, können Sie eine Lösung erarbeiten, mit der Sie die daran geknüpften Erwartungen erfüllen. Werden die Erwartungen mit dem Projektergebnis verfehlt, ist der Projekterfolg fraglich. Um sicherzustellen, dass Sie die Anforderungen genau durchschauen, müssen Sie unterschiedliche Personengruppe zu Rate ziehen. Zu Beginn müssen Sie sich mit den Erwartungen der wichtigsten Akteure und Kostenträger auseinandersetzen. Wenn diese unerfüllbare Erwartungen an Operations Manager stellen, haben Sie zu diesem Zeitpunkt die Möglichkeit, aufzuklären und realistische Erwartungen zu vermitteln. Des weiteren müssen Sie mit der Gruppe der Personen zusammenarbeiten, die mit den aus Operations Manager gewonnen Daten umgehen oder diese nutzen. Das betrifft nicht nur die Helpdesk- und Anwendungsverwaltungsteams, sondern auch deren Vorgesetzte, die vermutlich die Operations Manager-Berichte lesen werden und in der Lage sein möchten, den Status ihrer Anwendung auf einen Blick zu erkennen. Wenn Sie mit dem Sammeln der Anforderungen fertig sind, erstellen Sie eine Übersicht der Daten, und veröffentlichen Sie diese an allgemein zugänglicher Stelle, damit alle interessierten Parteien entsprechend informiert werden. Damit bietet sich eine neuerliche Gelegenheit zur Klärung der Möglichkeiten. Wenn Sie sich noch stärker um Übereinstimmung in Bezug auf die 19 Anforderungen bemühen möchten, können Sie auch die Hauptakteure und Kostenträger bitten, Ihre Aufstellung abzuzeichnen. Betriebliche Anforderungen Die Verantwortlichen auf betrieblicher Seite, mit denen Sie zusammenarbeiten müssen, sind nicht nur die Führungskräfte der obersten Ebene, die als Kostenträger Ihres Operations ManagerProjekts auftreten, sondern auch die Manager und Vorstände, die für die Geschäftsprozesse verantwortlich sind, mit denen Ihr Unternehmen Einkommen erwirtschaftet. Auch wenn die betreffenden Personen kein großes Interesse an Operations Manager an sich haben, sind sie doch sehr stark an den von der IT-Abteilung erbrachten Leistungen interessiert, die der Unterstützung ihrer geschäftskritischen Anwendungen dienen. Bei Ihren Diskussionen mit dem betreffenden Personenkreis stehen wahrscheinlich die folgenden vier Bereiche im Zentrum des Interesses: Laufender Service des IT-Bereichs Leistungsdaten in Bezug auf die eigene Anwendung Einhaltung der Vorschriften Rendite der IT-Aufwendungen Laufender Service des IT-Bereichs In der Hauptsache erwarten sich die Verantwortlichen auf geschäftlicher Seite vom IT-Bereich, dass er für die Verfügbarkeit und reibungslose Ausführung ihrer Anwendungen sorgt. Ist dies nicht der Fall, muss dies umgehend gemeldet werden. Sie wollen über die Auswirkungen von Ausfällen auf den Geschäftsprozess sowie deren voraussichtliche Dauer aufgeklärt werden. Die Kenntnis des betreffenden Geschäftsprozesses ist die Grundvoraussetzung, um diese Anforderungen erfüllen zu können. Achten Sie bei Ihren Gesprächen darauf, dass Sie mit den folgenden Punkte vertraut sind: Welche Anwendungen kommen beim den Abläufen in Verbindung mit dem Kerngeschäft zum Einsatz? Anhand dieser Kenntnis können Sie ermitteln, für welche Anwendungen Sie eine End-to-End-Dienstüberwachung bereitstellen müssen. Welche Komponenten sind Bestandteil dieser Anwendungen? Diese Kenntnis hilft Ihnen beim Erarbeiten eines verteilten Anwendungsmodells, das Gegenstand der Überwachung sein wird. Verfügt die benötigte Anwendung über eine kritische Komponente, die auf Arbeitsstationen oder anderen Clients ausgeführt wird? Dieses Wissen ist wichtig für die Planung der Clientüberwachungsstrategie. Lassen Sie sich eine komplette Transaktion in der jeweiligen Anwendung erläutern. In Operations Manager 2007 können synthetische Transaktionen für regelmäßige Anwendungstests verwendet werden. Zudem können dadurch Überwachungsdaten erworben werden, aus denen hervorgeht, wie sich die Benutzererfahrung mit der Anwendung gestaltet. 20 Leistungsdaten Wenn Sie mit den Verantwortlichen auf geschäftlicher Seite erörtern, welche anwendungsbezogenen Leistungsdaten benötigt werden, müssen Sie klar unterscheiden zwischen der betrieblichen Leistung und der Anwendungsleistung. Daten (oder Messwerte) zu Geschäftsprozessen werden von Unternehmensinformationsdiensten in der Regel in Form von Berichten und ausgewogenen Kennzahlentafeln geliefert und gehören nicht hierher. Die Erwartungen, mit denen Sie sich auseinandersetzen müssen, beziehen sich auf die Anwendungsleistung. In diesem Zusammenhang müssen Sie mit den folgenden Punkte vertraut sein und diese erörtern: Wie sehen die Anwendungsleistungsdaten aus, die derzeit zur Verfügung stehen? Welche Daten werden gewünscht? Dieses Wissen hilft Ihnen bei der Rollenplanung (Profile und Bereiche). Auf welchem Wege werden die Anwendungsleistungsdaten derzeit geliefert? Welche Art der Datenbereitstellung wird gewünscht? Aufgrund dieser Information können Sie entscheiden, wie der Zugriff auf die Leistungsdaten zu gestalten ist. Wird beispielsweise eine Betriebskonsole mit der Benutzerrolle "Schreibgeschützter Operator" und Zugriff auf Berichte benötigt, die auf die jeweilige Anwendung eingeschränkt ist, oder reicht eine Webkonsole aus? Einhaltung der Vorschriften Die Einhaltung von Vorschriften ist eine kritische Frage für Geschäftsprozessbesitzer, jetzt und in Zukunft. In diesem Zusammenhang bauen viele der Prozessbesitzer auf IT-Unterstützung bei der Umsetzung und fortgesetzten Einhaltung der Vorschriften. Sie müssen folgende Punkte klären: Unterliegt der Geschäftsprozess bestimmten Vorschriften? Wie sehen diese aus? Dieses Wissen ist Ihnen beim Planen des Überwachungssammeldiensts (ACS) und bei der Rollenplanung nützlich. Welche Art von Daten soll mithilfe der IT-Lösung geliefert werden und welche Zeiträume gelten dafür? Auf der Basis dieses Wissens kann die Berichterstellung und die Datenaufbewahrungsdauer geplant werden. Rendite der IT-Aufwendungen Die betrieblichen Führungskräfte bezahlen für IT-Dienste entweder über direkte Rückbelastungen oder über einen indirekten Zuschlag, und wie alle guten Geschäftsleute wollen sie wissen, was sie für ihr Geld bekommen. Zur Beantwortung dieser Frage können Sie die Operations ManagerBerichterstattung verwenden, doch müssen Sie wissen, welche Dienste für die Geschäftsprozessbesitzer einen Wert darstellen. Sie müssen folgende Punkte klären: Welcher Dienst gilt als wichtigste Serviceleistung der IT-Abteilung? Mit diesem Wissen können Sie die Berichterstattung planen. Ist den Verantwortlichen bewusst, welche Leistungen sie derzeit für ihren IT-Zuschlag erhalten? Auf der Basis dieser Kenntnis können Sie gegebenenfalls unterschiedliche Berichte 21 zusammenstellen, um die Serviceleistungen zu belegen, die außerhalb der jeweiligen Geschäftsanwendung liegen. IT-Anforderungen Die IT-Anforderungen sind die treibende Kraft für die Operations Manager-Topologie und die dazugehörige Infrastruktur. Die zwei Faktoren, von denen Ihre IT-Anforderungen entscheidend abhängen, sind die angestrebten Optimierungsziele und die IT-Umgebung, in der Operations Manager zum Einsatz kommt. Sie müssen diese Anforderungen mithilfe IT-Kostenträgern, Hauptakteuren und Nutzern der Operations Manager-Daten erarbeiten. Verwenden Sie in den betreffenden Gesprächen breit angelegte, offene Fragen. Fragen Sie zu Beginn, wie Operations Manager in der Umgebung eingesetzt werden und worauf die Optimierung der Implementierung ausgerichtet sein soll. Die folgenden Punkte sind zu klären: Optimierungsziele Optimierungsziele sind die Aspekte der Operations Manager-Implementierung, denen der Entwurf entsprechen muss. Sie lassen sich in Aussagen ausdrücken wie: Verfügbarkeit/Wiederherstellbarkeit: Operations Manager muss verfügbar sein; Ausfälle müssen sich auf ein absolutes Minimum beschränken. Auf dieser Grundlage können Sie Ihre Planung auf hohe Verfügbarkeit und Sicherung/Wiederherstellung ausrichten. Kosten: Operations Manager muss so kostengünstig wie möglich implementiert werden. Kenntnis und Einhaltung des finanziellen Rahmens ist für den Projekterfolg ausschlaggebend. Leistung: Operations Manager muss beispielsweise Daten aus der Umgebung in weniger als 1 Minute melden, und der Konsolenzugriff darf nicht länger als 10 Sekunden ab Konsolenstart dauern. Mit diesem Wissen können Sie die Planung für die Hardware vornehmen. Bereich: Operations Manager muss eine Ansicht der gesamten Umgebung liefern. Auf dieser Basis können Sie die Anzahl der benötigten Verwaltungsgruppen sowie die Beziehungen derselben untereinander planen. Verwaltung: Die Operations Manager-Verwaltung muss auf bestimmte Gruppen eingeschränkt werden (oder entsprechend verfügbar sein). Auf dieser Basis können Sie Sicherheitsgruppen, Rollen, Zugriff und möglicherweise die Anzahl der Verwaltungsgruppen planen, die zu implementieren sind. Standort der Zugriffspunkte: Operations Manager-Daten dürfen nur über das UnternehmensIntranet zugänglich sein, oder sie müssen intern und extern zur Verfügung stehen. Auf dieser Basis können Sie planen, wo Betriebs- und Webkonsolen eingerichtet werden. Integration: Operations Manager muss in das bestehende Fehlerticketsystem oder andere Unternehmensüberwachungsprodukte eingebunden werden. Auf dieser Basis können Sie planen, an welcher Stelle sich Operations Manager und die dazugehörigen Features in Ihre Umgebung einfügen lassen und welche Rolle dies spielt. Außerdem hilft Ihnen dies bei der 22 Entscheidung, ob Connectors von Drittanbietern oder intern entwickelte Connectors erforderlich sind. Inventar der aktuellen Umgebung Eine exakte Bestandsaufnahme der aktuellen Umgebung ist in zweierlei Hinsicht nützlich. Zum einen lässt sich daraus ersehen, welche Komponenten von Operations Manager überwacht werden, zum zweiten lassen sich daraus die Beschränkungen und Grenzen erkennen, im Rahmen derer das System funktionieren muss. Sie müssen die folgenden Punkte klären: Bereich: Ungefähre Anzahl der Computer, die überwacht werden sollen. Erforderliche Management Packs: Anwendungen, die überwacht werden sollen. Art der Computer, die die Anwendungen unterstützen: Diese Liste enthält Windows-, Netzwerk- und UNIX- oder Linux-basierte Computer. Topologie: Physischer und Netzwerkstandort von Computern, die überwacht werden sollen. Topologie- und Konsolenverteilung: Physischer und Netzwerkstandort der Personen, die Operations Manager-Daten nutzen. Erforderliche Zertifikate und Gatewayserver: Active Directory-Vertrauensgrenzen Ihrer Umgebung. Aktuelle Verwaltungs- und Helpdesk-Produkte: Alle anderen Produkte, die derzeit für Überwachung, Warnung und Berichterstattung verwendet werden. Topologie- und Gatewayplanung: Firewalls und WAN-Links (Wide Area Network), die die Netzwerkgrenzen definieren. Topologie- und Rollenplanung: IT-Verwaltungsgrenzen für überwachte Computer und Anwendungen. Topologie und Lokalisierung: Sprache und geopolitische Grenzen, über die sich Ihre Umgebung erstreckt. Inventar der aktuellen Vorgehensweisen Alle Umgebungen werden auf irgendeine Weise überwacht und verwaltet. Die verwendeten Techniken und Technologien unterscheiden sich in Entwicklungsniveau und Ausgereiftheit. Im Rahmen des Infrastrukturoptimierungsmodells können alle Umgebungen mithilfe von vier Kategorien beschrieben werden: Basis, Standardisiert, Rationalisiert und Dynamisch. Unter http://go.microsoft.com/fwlink/?LinkId=92863 und Infrastrukturoptimierungstest finden Sie weitere Informationen über diese vier Kategorien sowie ein Tool, mit dessen Hilfe Sie selbst feststellen können, auf welchem Stand sich Ihr Prozess und Ihre Umgebung befindet. Um den Einsatz der Möglichkeiten von Operations Manager 2007 zu planen, müssen Sie die Vorgehensweisen kennen, die zum Überwachen und Verwalten Ihrer Umgebung derzeit verwendet werden. Dadurch können Sie berücksichtigen, wie auf Warninformationen reagiert wird und wer dafür zuständig ist. Sie können planen, wie und an wen Benachrichtigungen versendet werden. Sie können die administrative Kontrolle über Verwaltungsgruppen und Datensicherheit ausarbeiten. 23 Hier die wichtigsten Fragen, die in dieser Phase zu stellen sind: Wie wird die Überwachung in unserem Unternehmen derzeit gehandhabt? Wie werden in unserem Unternehmen die durch das Überwachungsverfahren/-system ermittelten Informationen verwertet? Zudem müssen Sie folgende Punkte klären: Wer bearbeitet in der Regel Probleme oder Warnungen, die durch automatische Systeme oder den Helpdesk gemeldet werden? Auf dieser Basis können Sie entscheiden, wer direkten Zugriff auf die Betriebskonsole benötigt und welche Daten die Konsole liefern muss. Werden Serverprobleme normalerweise vom Helpdesk behoben oder an Serversupportteams weitergeleitet? Verfügt das Unternehmen über eine personell besetzte Netzwerkbetriebszentrale oder ein anderes personell besetztes Überwachungssystem? Falls ja, wie viele Personen und wie viele Konsolen sind im ständigen Einsatz? Auf dieser Basis können Sie ermitteln, wo Verwaltungsgruppen einzurichten sind, damit die Unterstützungsanforderungen erfüllt werden. An wie vielen Standorte außer den Rechenzentren werden Agents bereitgestellt und wo befinden sich diese im Netzwerk? Wie sieht die verfügbare Bandbreite der Verbindungen zwischen den Standorten aus, an denen verwaltete Computer vorliegen? Wie wird derzeit das Sicherheitsprotokoll geführt? Wie werden derzeit Desktop- oder Clientanwendungen überwacht? Wie erfolgt die Überwachung für UNIX- oder Linux-basierte Computer und Netzwerkgeräte? Abbilden der Anforderungen in einem Entwurf für Operations Manager 2007 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 24 werden bewährte Methoden angewendet, um die Ausstattung und Kapazität im Hinblick auf Serverrollen und Komponenten zu planen. 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. 25 Pro dediziertem Verwaltungsserver können 3.000 URLs überwacht werden Pro dedizierter Verwaltungsgruppe können 12.000 URLs überwacht werden. Klicken Sie auf diesen Link für Informationen zu den empfohlenen Grenzwerten für Operations Manager 2007 SP1. 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 PackFunktionalitä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 ACSFunktion 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 OperationsManagerDatenbank ü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. 26 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 27 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 Anforderungen Kann in ein mit anderen Quorum- Rollen Failovercluster eingefügt werden Betriebsdatenbank Ja SQL Ja ÜberwachungssammeldiensteDatenbank (ACS) Ja SQL Ja Datenbank des Berichterstattungs-Data Warehouses Ja SQL Ja Reporting-Datenbank Ja Dedizierte SQL Server Reporting ServicesInstanz; nicht auf Domänencontroller Ja 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 Nein 28 Serverrolle Kompatibel Anforderungen Kann in ein mit anderen Quorum- Rollen Failovercluster eingefügt werden Überwachungsdatenbank kombiniert werden Gatewayserver Ja Webkonsolenserver Ja Agent Ja Kann nur mit ACSSammlungskomponente kombiniert werden; muss Domänenmitglied sein Nein Nicht zutreffend 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ärund 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 CABDateien 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. 29 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 CenterVerwaltungskonfigurationsdienst 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 2007Bereitstellungshandbuch. 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. 30 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 für Empfehlungen zur Komponentenverteilung und Plattformausstattung für Operations Manager 2007 SP1. 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 UNIXoder Linux-Computer DB, DW, RS, RMS; RAID 0+1 mit 4 Datenträgern, 8 GB RAM, Quadprozessor Mehrere Server, kleines Szenario Anzahl überwachter Serverrollen/Konfiguration Serverrollen/Konfiguration DB, DW, RS; RMS; RAID 0+1 mit 4 Datenträgern, 4 GB RAM, Dualprozessor RAID 1 mit 2 Datenträgern, 4 GB RAM, Dualprozessor Geräte 250 bis 500 WindowsComputer, 500 UNIXoder Linux-Computer 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 31 Cluster bereitstellen, wobei jeder Knoten die beschriebene Mindestkonfiguration sowie Verbindungen zu einem extern freigegebenen Datenträger für Clusterressourcen aufweist. Anzahl Serverrolle/Konfigur Serverrolle/Konfigur Serverrolle/Konfigur Serverrolle/Konfigur überwach ation ation ation ation DB; MS; DW, RS; RMS; RAID 0+1 mit 4 Datenträgern, 4 GB RAM, Dualprozessor RAID 1 mit 2 Datenträgern, 4 GB RAM, Dualprozessor RAID 0+1 mit 4 Datenträgern (Daten), RAID 1 mit 2 Datenträgern (Protokolle), 4 GB RAM, Dualprozessor RAID 1 mit 2 Datenträgern, 8 GB RAM, Dualprozessor ter Geräte 500 bis 750 Windows Compute r, 500 UNIXoder LinuxCompute r 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 Serverrolle/Konf Serverrolle/Konf Serverrolle/Konf Serverrolle/Konf Serverrolle/Konf überwa iguration iguration iguration iguration iguration DB; DW; RS; RMS; MS; RAID 0+1 mit 4 Datenträgern (Daten), RAID 1 mit 2 Datenträgern (Protokolle), 8 GB RAM, Dualprozessor RAID 0+1 mit 4 Datenträgern (Daten), RAID 1 mit 2 Datenträgern (Protokolle), 8 GB RAM, Dualprozessor. Hinweis: Eine RAID 5Konfiguration RAID 1 mit 2 Datenträgern, 4 GB RAM, Dualprozessor RAID 1 mit 2 Datenträgern, 8 GB RAM, Dualprozessor RAID 1 mit 2 Datenträgern, 4 GB RAM, Quadprozessor chter Geräte 750 bis 1000 Windo wsCompu ter, Unixoder LinuxCompu ter 32 Anzahl Serverrolle/Konf Serverrolle/Konf Serverrolle/Konf Serverrolle/Konf Serverrolle/Konf überwa iguration iguration iguration iguration iguration chter Geräte mit ähnlicher Leistung kann verwendet werden, um die DWSpeicheranford erungen zu erfüllen. 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 Serverrolle/Konf Serverrolle/Konf Serverrolle/Konf Serverrolle/Konf Serverrolle/Konf überwa iguration iguration iguration iguration iguration 1.000 bis 3.000 Windo wsCompu ter, 500 UNIXoder LinuxCompu ter DB; DW; RS; RMS; MS; RAID 0+1 mit 8 Datenträgern (Daten), RAID 1 mit 2 Datenträgern (Protokolle), 8 GB RAM, Quadprozessor RAID 0+1 mit 8 Datenträgern (Daten), RAID 1 mit 2 Datenträgern (Protokolle), 8 GB RAM, Quadprozessor RAID 1 mit 2 Datenträgern, 4 GB RAM RAID 0+1 mit 4 Datenträgern, 12 GB RAM, 64-BitQuadprozessor RAID 0+1 mit 4 Datenträgern, 8 GB RAM, Quadprozessor 3.000 bis 6.000 Windo ws- DB; DW; RS; RMS; MS; RAID 0+1 mit 14 Datenträgern RAID 0+1 mit 14 Datenträgern RAID 1 mit 2 Datenträgern, 4 GB RAM, RAID 0+1 mit 4 Datenträgern, 16 GB RAM, RAID 0+1 mit 2 Datenträgern, 8 GB RAM, chter Geräte Quadprozessor 33 Anzahl Serverrolle/Konf Serverrolle/Konf Serverrolle/Konf Serverrolle/Konf Serverrolle/Konf überwa iguration iguration iguration iguration iguration (Daten), RAID 1 mit 2 Datenträgern (Protokolle), 16 GB RAM, Quadprozessor (Daten), Quadprozessor RAID 1 mit 2 Datenträgern (Protokolle), 16 GB RAM, Quad/Dualprozessor. Hinweis: Eine RAID 5Konfiguration mit ähnlicher Leistung kann verwendet werden, um die DWSpeicheranford erungen zu erfüllen. Quadprozessor Quadprozessor chter Geräte Compu ter, Unixoder LinuxCompu ter 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. 34 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 Speicherund 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-BitHardware 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 SQLVerbindungen 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 OperationsManagerDatenbank 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 SQLVerbindungen mehr Bandbreite benötigt, und sie sind anfälliger für Netzwerklatenz als 35 Verbindungen zwischen Agents und dem Stammverwaltungsserver. Daher sollten Sie generell dafür sorgen, dass sich der Stammverwaltungsserver, die OperationsManagerDatenbank 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. Darüber hinaus richtet der Stammverwaltungsserver bei Instanzbereichsänderungen zusätzliche Abfragen an die Operations Manager-Datenbank, um die 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 OperationsManagerDatenbankservers: 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 136 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 OperationsManagerDatenbank von Vorteil sind. Daher wird empfohlen, dass Sie beim Konfigurieren von Schreibund 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 Systemoder 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 OperationsManagerDatenbank. 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: 37 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-BitHardware 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 38 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: 39 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. 40 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 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. In der folgenden Tabelle steht die Abkürzung DW für Data Warehouse, ODB steht für OperationsManager-Datenbank, RMS bezeichnet den Stammverwaltungsserver und MSFS2 bezieht sich auf einen zweiten Dateifreigabecomputer auf Verwaltungssserverbasis. Empfehlungen für eine kleine Konfiguration: Anzahl überwachter Geräte Serverrolle/Konfiguration 0 bis 2500 DW, ODB, MSFS2, RMS; 30 GB Speicherplatz als RAID 1 mit 2 Laufwerken, 4 GB RAM 41 Empfehlungen für eine mittlere Konfiguration: Anzahl überwachter Serverrolle/Konfiguration Serverrolle/Konfiguration DW, ODB; MSFS2, RMS; 50 GB Speicherplatz als RAID 1 mit 2 Laufwerken, 4 GB RAM RAID 1 mit 2 Laufwerken, 4 GB RAM Geräte 2500 bis 5000 Empfehlungen für eine umfangreiche Konfiguration: Anzahl Serverrolle/Konfiguration Serverrolle/Konfiguration Serverrolle/Konfiguration DW, ODB; MSFS2; RMS; überwachter Geräte 5.000 bis 7.500 100 GB Speicherplatz als RAID 1 mit 2 Laufwerken, RAID 1 mit 2 Laufwerken, RAID 1 mit 2 Laufwerken, 4 GB RAM 4 GB RAM 4 GB RAM Empfehlungen für eine Unternehmenskonfiguration: Anzahl Serverrolle/Konfigur Serverrolle/Konfigur Serverrolle/Konfigur Serverrolle/Konfigur überwach ation ation ation ation DW; ODB; MSFS2; RMS; 300 GB Speicherplatz als RAID 1 mit 2 Laufwerken, 4 GB RAM 300 GB Speicherplatz als RAID 1 mit 2 Laufwerken, 4 GB RAM RAID 1 mit 2 Laufwerken, RAID 1 mit 2 Laufwerken, 4 GB RAM 4 GB RAM ter Geräte 7.500 bis 10.000 Entwerfen von Überwachungssammeldiensten (ACS) Dieser Abschnitt enthält allgemeine Ratschläge, mit deren Hilfe Sie die Planung Ihrer ACSImplementierung 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 ManagerAgent 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 42 SQL Server 2005-Server oder der gleichen Instanz installiert werden wie die anderen Operations Manager-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 ACSSammlungsserver 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 ACSDatenbanken 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 ACSSammlungs- 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 2007Berichterstattungskomponente bereitgestellt werden soll. Hier die Merkmale dieser beiden Szenarien. Integration von ACS-Berichterstattung und Operations Manager-Berichterstattung: 43 Einzelkonsole für alle Berichte: Wenn die ACS-Berichterstattung gemeinsam mit der Operations Manager-Berichterstattung installiert ist, erfolgt der Zugriff auf die ACSBerichte ü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 ReportDesigners. 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-/DatenbankPaarungen, 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 ACSSammlung 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. 44 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-EndPaarung von ACS-Sammlung/Datenbank bis zu 150 Domänencontroller, 3.000 Mitgliedsserver oder 20.000 Arbeitsstationen (bei angewendetem passendem ACSSammlungsfilter) 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. 45 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. Entwickeln eines Implementierungsplans für Operations Manager 2007 Entwickeln eines Implementierungsplans Zu diesem Zeitpunkt des Entwurfsvorgangs sollten Sie über verschiedene Dokumente verfügen: Eine Liste der Ziele Ihres Operations Manager 2007-Implementierungsprojekts Eine Zusammenfassung der betrieblichen, rechtlichen und IT-Anforderungen Ein zuverlässiges Bestandsverzeichnis Ihrer aktuellen Produktionsumgebung Eine zuverlässige Beschreibung der gegenwärtig angewendeten Verfahren zur Durchführung der Überwachung Eine Auflistung der Operations Manager 2007-Dienste, die implementiert werden sollen, und der Komponenten, die zur Unterstützung dieser Dienste notwendig sind Ein detailliertes Diagramm Ihrer geplanten Verwaltungsgruppen mit Angaben, wie diese in Ihrer Umgebung angeordnet werden sollen Einen detaillierten Plan, wie Operations Manager mit Ihren aktuellen Überwachungsprozessen integriert werden soll 46 Hardwarespezifikationen für die Server in den geplanten Verwaltungsgruppen Das letzte Element, bei dessen Entwicklung dieses Handbuch Sie unterstützen soll, ist ein Implementierungsplan. Prüfen in einer Testumgebung Ein Implementierungsplan ist einfach eine nicht übermäßig detaillierte Auflistung der Schritte, die notwendig sind, um die Überwachungsumgebung aus ihrem gegenwärtigen, "Startzustand" genannten Zustand in den "gewünschten Endzustand" zu überführen. Der einzige Weg, um einen Implementierungsplan ordnungsgemäß zu entwickeln, führt über das Prüfen in einer Testumgebung. Das Ziel des Prüfens in einer Testumgebung, als Teil der Entwicklung eines Implementierungsplans, besteht darin, Konfiguration und Verfahren zu überprüfen, nicht jedoch darin, die Skalierbarkeit nachzuweisen, da es sich aus Kostengründen gewöhnlich verbietet, die Produktionsumgebung mit ihrer ganzen Komplexität vollständig zu modellieren und in eine Testumgebung zu laden. Beginnen Sie mit dem Entwurf der Testumgebung, indem Sie die kritischen Komponenten in Ihrer Produktionsumgebung identifizieren, welche die Überwachungsumgebung unterstützen, zum Beispiel das Active Directory und DNS. Identifizieren Sie außerdem Komponenten, mit denen Operations Manager interagieren wird, zum Beispiel Anwendungen, Server und Arbeitsstationen. Sichern Sie die Hardware, welche die Testumgebung des Startzustands hosten soll. Da Sie keine Prüfung auf Skalierbarkeit durchführen, sollten Sie die Verwendung von Microsoft Virtual Server in Erwägung ziehen, um diese Komponenten als virtuelle Maschinen zu hosten. Die Verwendung von Virtual Server hat außerdem den Vorteil, dass sie die Möglichkeit bietet, die Testumgebung nach einem Testlauf schnell auf einen leeren Startzustand zurückzusetzen. Bauen Sie die Infrastruktur der kritischen Komponenten und andere Komponenten des Startzustands in dieser Umgebung auf. Gehen Sie dabei mit der gebotenen Sorgfalt vor, um sicherzustellen, dass die Testumgebung der Produktionsumgebung möglichst ähnlich ist. Je größer die Ähnlichkeit im Hinblick auf Konfiguration, Dienste und Daten ist, desto aussagekräftiger ist die nachfolgende Prüfung. Stellen Sie dann die Hardware bereit, die verwendet werden soll, um die Produktionsimplementierung Ihrer Verwaltungsgruppen zu unterstützen, und bringen Sie diese in der Testumgebung zum Laufen. Dies gibt Ihnen Gelegenheit zu überprüfen, ob die gesamte Hardware vorhanden ist und einwandfrei arbeitet. Stellen Sie danach eine grobe Liste der Schritte zusammen, mit denen die Bereitstellung von Operations Manager erfolgen soll. Damit sind die vorbereitenden Schritte abgeschlossen. Nun sollten Sie schrittweise die Implementierung in der Testumgebung durchführen und dabei die Verfahren jeweils entsprechend aktualisieren. Es ist zu erwarten, dass während dieses Vorgangs Probleme auftreten. Das Ziel besteht hierbei darin, möglichst viele Probleme, welche die Implementierung behindern, zu identifizieren und Lösungen oder Verfahren zur Überwindung dieser Probleme zu entwickeln. Sie müssen damit rechnen, dass dieser Prozess viele Male wiederholt werden muss, wobei Sie jedes Mal etwas weiter kommen und nach Bedarf die Testumgebung auf den Startzustand zurücksetzen. 47 Sobald Sie in der Lage sind, die Implementierung vom Startzustand bis zum gewünschten Endzustand erfolgreich zu durchlaufen, können Sie sicher sein, dass Sie über einen zuverlässigen und wirklich nützlichen Implementierungsplan verfügen. 48
