Grundlegende Konzepte

Transkript

1 Überblick - Deutsch FUJITSU Software ServerView Suite Grundlegende Konzepte Ausgabe April 2015

2 Kritik Anregungen Korrekturen Die Redaktion ist interessiert an Ihren Kommentaren zu diesem Handbuch. Ihre Rückmeldungen helfen uns, die Dokumentation zu optimieren und auf Ihre Wünsche und Bedürfnisse abzustimmen. Sie können uns Ihre Kommentare per an senden. Zertifizierte Dokumentation nach DIN EN ISO 9001:2008 Um eine gleichbleibend hohe Qualität und Anwenderfreundlichkeit zu gewährleisten, wurde diese Dokumentation nach den Vorgaben eines Qualitätsmanagementsystems erstellt, welches die Forderungen der DIN EN ISO 9001:2008 erfüllt. cognitas. Gesellschaft für Technik-Dokumentation mbh Copyright und Handelsmarken Copyright 2015 Fujitsu Technology Solutions GmbH. Alle Rechte vorbehalten. Liefermöglichkeiten und technische Änderungen vorbehalten. Alle verwendeten Hard- und Softwarenamen sind Handelsnamen und/oder Warenzeichen der jeweiligen Hersteller.

3 Inhalt 1 Einleitung Grundkonzepte Server--Komponenten Verwaltete Server mit Agenten Applikationen Konsolen Helpers Prinzip: Agent - -Station Zyklus Schnittstelle zwischen Überwachung und Analyse Schnittstelle zwischen Anpassung und Ausführung Autonomes auf dem Server Hierarchische Konfigurationen Lokales Point-to-point Zentrales Kaskadiertes Integration in andere -Systeme Protokolle SNMP - Simple Network Protocol CIM (Common Information Model) IPMI - Intelligent Platform Interface PXE - Preboot Execution Environment Telnet HTTP - Hypertext Transfer Protocol SOAP - Simple Object Access Protocol ITIL - IT Infrastructure Library Helpers DHCP-Server PXE-Boot-Server TFTP-Server Mail-Server (MAPI oder SMTP)

4 Inhalt Web-Server MS Excel, Access- oder SQL-Datenbanken Mode Mode In-Band Mode Out-of-Band Zusammenfassung Positionierung von ServerView ServerView Suite Integration in andere -Systeme Integration von anderen Komponenten

5 1 Einleitung Mit der ServerView Suite stehen Produkte für die zentrale Verwaltung von Servern in einem Netzwerk zur Verfügung. Dieses Handbuch bietet Ihnen allgemeine Informationen zu den Grundlagen der Server Architektur. Die Thematik wird mit Blick auf die ServerView Suite behandelt und soll eine Einstiegshilfe für Sie sein. Im Kapitel "Grundkonzepte"werden zunächst die Server Komponenten kategorisiert und die damit realisierbaren Konzepte vorgestellt. Die standardisierten Protokolle und Programme, die Voraussetzung für die Kommunikation eines -Systems sind, werden beschrieben. Außerdem erhalten Sie einen Überblick, wie diese in der ServerView Suite verwendet werden. Ein Abschnitt behandelt die für den Remote-Zugriff verwendeten Modes. Das Kapitel "Positionierung von ServerView" bietet einen Überblick, wie die Verbindung mit anderen Enterprise Systemen erfolgt. Das Handbuch soll sowohl einen schnellen Überblick als auch einen tieferen Einstieg in die Thematik ermöglichen. Einige Textpassagen sind deshalb Grau hinterlegte. Sie dienen der Vertiefung von Themen und sind für Experten oder Leser, die weitergehende Information zu dem jeweiligen Thema lesen möchten. Für den normalen Einsatz der ServerView Suite können diese Absätze übersprungen werden. 5

6

7 2 Grundkonzepte Dieses Kapitel vermittelt einen Überblick über allgemeine Grundlagen und Konzepte für das Server-. Es werden hauptsächlich die Themen behandelt, deren Verständnis Voraussetzung ist für die optimale Planung, Konfiguration und den Betrieb von PRIMERGY Systemen sind. 2.1 Server--Komponenten Server--Komponenten lassen sich in vier Kategorien einteilen: verwaltete Server -Applikationen -Konsolen Helpers Das folgende Bild 1 zeigt schematisch das Zusammenspiel der Server- -Komponenten. 7

8 Server--Komponenten MANAGEMENT CONSOLES HELPERS Console Console MANAGEMENT APPLICATIONS Application Helper Application Application Helper MANAGED SERVERS WITH AGENTS Agent Agent Agent Bild 1: Server--Komponenten Die Komponenten kommunizieren miteinander über Protokolle. Sie können auf unterschiedlichen Rechnern installiert sein. Es ist jedoch auch möglich, mehrere Komponenten unterschiedlicher Kategorien auf einem Rechner zu installieren. Im Folgenden werden die vier Kategorien kurz beschrieben. Später erfahren Sie, wie Sie unterschiedliche Netzwerk-Topologien damit aufbauen können, sowie deren Vor- und Nachteile. 8

9 Server--Komponenten Verwaltete Server mit Agenten Um einen Server zu verwalten, muss in der Regel mindestens ein Agent auf ihm installiert sein. Agenten, die auf Servern installiert sind, ermöglichen es, diese entfernt (remote) zu überwachen und zu verwalten. Der Agent bietet dazu eine Schnittstelle an, über die er Anforderungen empfängt, um Informationen zu liefern, angeforderte Informationen liefert, Anforderungen empfängt, um Aktionen auszuführen, unaufgefordert Meldungen (Traps) sendet, sobald er eine besondere Situation auf dem verwalteten Server erkannt hat. Agenten kommunizieren mit -Applikationen. Agenten empfangen von -Applikationen Aufträge, Informationen zu liefern oder Aktionen auszuführen. Wenn sie besondere Situationen erkennen, schicken sie unaufgefordert Meldungen (z.b. Traps). Agenten führen also Aufträge von -Applikationen aus oder liefern diesen Informationen, d.h. sie sind der verlängerte Arm der -Applikationen auf den zu überwachenden Servern. Verwaltete Server kommunizieren mit den -Applikationen über Protokolle wie SNMP, CIM-basierte Protokolle, IPMI (siehe auch Abschnitt "Protokolle" auf Seite 28) Applikationen Aufgaben von -Applikationen sind z.b. Durchführen von komplexen Konfigurationen, Sammeln von Daten mehrerer Systeme, Konsistenzprüfungen, graphische Darstellung von Informationen, Reaktionen auf Trap-Situationen, Installation von Servern, Update von Servern, Erzeugen von Archiven oder Berichten usw. 9

10 Server--Komponenten -Applikationen kommunizieren mit: -Konsolen Konsolen sind die Schnittstelle zu Administratoren. Über Konsolen stehen sämtliche Funktionen der -Applikationen zur Verfügung. Eine häufig verwendete Konsole ist der Web-Browser. In diesem Fall kommuniziert die -Applikation mit der Konsole über HTTP/HTML oder HTTPS/HTML (siehe auch Abschnitt "Protokolle" auf Seite 28). Agenten auf verwalteten Servern -Applikationen kommunizieren mit Agenten, um von verwalteten Servern Informationen zu bekommen, Log-Dateien zu lesen, Aktionen auszuführen, Einstellungen vorzunehmen, über besondere Zustände informiert zu werden usw. anderen -Applikationen Komplexere Aufgaben erledigen die Komponenten der ServerView Suite durch die Kooperation von -Applikationen. - Applikationen nehmen dabei Dienstleistungen von anderen - Applikationen in Anspruch. Als Protokolle werden SOAP (siehe auch Abschnitt "Protokolle" auf Seite 28) oder proprietäre Protokolle verwendet. Helpers (siehe auch Abschnitt "Helpers" auf Seite 41) -Applikationen können auch Dienstleistungen von Helpers, wie zum Beispiel Services, die Betriebssysteme zur Verfügung stellen, in Anspruch nehmen. Dazu kommunizieren sie über die Schnittstellen, die diese Helpers anbieten. Repositories können Bestandteil von - Applikationen sein oder aber auch als Helper realisiert sein. Beispiele für PRIMERGY ServerView -Applikationen sind:serverview Operations Manager, ServerView Download Manager, ServerView Event Manager, ServerView Deployment Manager und ServerView Archive Manager. 10

11 -Prinzip: Agent - -Station Konsolen Konsolen können abgesetzt von -Applikationen sein und erlauben es dem Administrator dadurch, von jedem beliebigen Ort und zu beliebiger Zeit auf die Dienstleistungen von ServerView -Applikationen zuzugreifen. Beispiele für -Konsolen, die mit der ServerView Suite verwendet werden, sind Web-Browser und Telnet-Konsole Helpers Als Helpers werden Services oder Programme bezeichnet, die nicht Bestandteil der ServerView Suite sind, die aber beim Betrieb der ServerView Suite verwendet werden oder verwendet werden können. Beispiele für Helpers, die in der ServerView Suite verwendet werden, sind der DHCP Service (siehe Abschnitt "DHCP-Server" auf Seite 41) und der TFTP Service (siehe Abschnitt "TFTP-Server" auf Seite 43), die unter anderem von ServerView Deployment Manager verwendet werden Prinzip: Agent - -Station Will man das -Prinzip erklären, dann ist es sinnvoll, die oben vorgestellten Kategorien noch etwas mehr zu abstrahieren. Die Abstraktion in diesem Kapitel lehnt sich an die Beschreibung der Architektur in den SNMP Standards an. Hier gibt es Agenten auf verwalteten Elementen (Server, Netzwerk-Komponenten, usw.) und -Stationen: Agenten Agenten sind die ausführenden Auftragnehmer der - Applikationen auf den verwalteten Servern. -Station -Applikationen, -Konsolen und Helpers, die zusammen kooperieren, werden zu einer Einheit zusammengefasst und als -Station bezeichnet. Die -Station wird verstanden 11

12 -Prinzip: Agent - -Station als der Gegenpart zu den Agenten, wobei die -Station ein logisches Gebilde ist, das physisch sowohl auf einem Rechner als auch verteilt auf mehrere Rechner ablaufen kann. Auf der Basis dieses Prinzips Agent - -Station wird nachfolgend der Ablauf von -Operationen am Beispiel einiger typischer Aktionen erklärt Zyklus Server- ist ein fortwährender Prozess, der durch den in Bild 2 dargestellten Zyklus schematisch dargestellt werden kann. Analysis Adaptation Knowledge & Rules Monitoring Execution Bild 2: -Zyklus Die vier Phasen des Zyklus sind die Überwachung, die Analyse, die Anpassung und die Ausführung: Überwachung liefert die aktuelle -Information vom verwalteten Server und seinen Komponenten. Analyse ist die Ableitung von Erkenntnissen aus dieser Information. Beispiele sind das Überschreiten von Schwellwerten, die Vorhersage von Ressourcen-Engpässen oder das Herausfinden der Ursache für eine Folge von Traps. Anpassung umfasst die Planung, mit welchen Aktionen auf eine in der Analyse-Phase erkannte Situation zu reagieren ist. Beispiele für eine Anpassung sind: Umkonfiguration, Neustart von Services, Stopp von Servern, Neuinstallation von Servern, Update-Installationen, Veränderung der Zuordnung von Ressourcen usw. Ausführung bedeutet die tatsächliche Umsetzung der in der Anpassungsphase entstandenen Planung auf dem verwalteten Server. 12

13 -Prinzip: Agent - -Station Insbesondere für die Phasen Analyse und Anpassung sind Wissen und Regeln nötig: Wissen umfasst des Verstehen der Zusammenhänge zwischen Komponenten, Kenntnisse über das Verhalten der Komponenten oder die Bedeutung und Wirkung von Konfigurationen. Bestandteil des Wissens ist auch die Kenntnis, was Maßnahmen bewirken können und eventuell welche Seiteneffekte sie haben können. Regeln umfassen Anweisungen, die entweder direkt in Form von Vorschriften vorgegeben sind oder von Service Level Agreements - mithilfe von Wissen - abgeleitet werden. Zwischen Agent und -Station gibt es im -Zyklus also zwei Kommunikationsstellen, auf der linken Seite der Darstellung im Bild 2 zwischen Überwachung und Analyse und auf der rechten Seite zwischen Planung und Ausführung. Diese beiden Schnittstellen werden in den nachfolgenden Abschnitten näher betrachtet. 13

14 -Prinzip: Agent - -Station Im Prinzip wird dieser Zyklus permanent durchlaufen, wobei der Antrieb dazu an zwei Stellen erfolgen kann. Analyse (Antrieb von innen) Wird während des laufenden Betriebs eines Systems in der Analysephase eine Situation erkannt, die eine Anpassung nötig macht, so wird dadurch ein neuer Durchlauf des Zyklus erzeugt. Planung (Antrieb von außen) Entscheidet der Administrator zum Beispiel, einen weiteren Server zu installieren oder aufgrund einer Änderung eines Service Level Agreements die Zuweisung von Ressourcen zu verändern, dann wird ausgehend von der Planungsphase ein neuer Durchlauf des Zyklus angestoßen. Damit ist die Zuordnung dieser Phasen zu dem -Prinzip Agent - -Station einfach abzuleiten: Agent Der Agent wird hauptsächlich verwendet für die Phasen Überwachung und Ausführung. In einigen Fällen trägt er auch bei zur Phase Analyse, z.b. durch Schwellwertüberwachung, das Senden von Traps oder durch PDA- Funktionen (Prefailure Detection Analysis) von ServerView Agenten. Zur Ausführung von Planungsentscheidungen können aber auch andere Werkzeuge oder Aktionen eingesetzt werden, wie eine Neu-Konfiguration des Betriebssystems oder der manuelle Austausch von Hardware- Komponenten. Station In den Phasen Analyse und Anpassung ist der Administrator mit seinem Wissen entscheidend. Er verwendet die -Station, um die für die Analyse notwendige Information von den Agenten zu bekommen, und auch dazu, die in der Anpassungsphase erarbeitete Planung auf den Systemen über Agenten umzusetzen. In zunehmendem Maße werden -Routineaufgaben automatisiert. In solchen Fällen läuft die Analyse- und Anpassungsphase komplett in der -Station ohne Einwirkung des Administrators ab. Die ServerView Suite bietet hierfür die Möglichkeit, den ServerView Event Manager so zu konfigurieren, dass beim Empfang bestimmter Traps automatisch Skripte ausgeführt werden. 14

15 -Prinzip: Agent - -Station Schnittstelle zwischen Überwachung und Analyse An dieser Schnittstelle kooperieren Agenten mit der -Station, um Information aus der Überwachungsphase in die Analysephase zu transportieren. Wie sich nachfolgend zeigen wird, kann dies eine permanente Kommunikation sein, insbesondere im Fall von Polling. Polling -Protokolle, wie SNMP oder CIM, werden hauptsächlich im Polling-Modus verwendet. In diesem Modus geht die Initiative von der -Station aus, indem sie beim Agenten Information anfordert. Im Normalfall liefert der Agent die gewünschte Information dann an die -Station. In der Analysephase wird dann entschieden, ob eine Situation vorliegt, die eine Planungsphase erforderlich macht. Falls dies der Fall ist, wird dadurch der -Zyklus angetrieben, die Planungsphase beginnt. Unabhängig davon, wird dieser Vorgang aber immer wieder durchgeführt, indem die -Station in bestimmten Zeitintervallen regelmäßig vom Agenten aktuelle Information anfordert und analysiert. Wenn dieses Polling in zu kurzen Zeitintervallen durchgeführt wird, so kann das einerseits zu zusätzlicher Netzbelastung führen, und andererseits verbraucht der Agent dadurch Ressourcen auf dem Server, z.b. CPU-Leistung. Längere Polling- Intervalle bedeuten natürlich wiederum einen Verlust an Aktualität. Die geforderte Aktualität hängt von der jeweiligen -Information ab, zum einen, wie schnell sich die Information verändern kann, und zum anderen, wie schnell darauf reagiert werden soll. Zum Beispiel muss die PDA- Information, dass eine Platte in drei Tagen ausfallen könnte, nicht im Millisekundentakt abgefragt werden. Deshalb verwendet ServerView automatisch sinnvolle, unterschiedliche Polling-Intervalle. Außerdem werden andere intelligente Techniken (z.b. Caching) verwendet, um die durch das Polling erzeugte Last so gering wie möglich zu halten. Als weitere Alternative bietet ServerView auch Aktualisierungs-Schaltflächen an der Konsole an, mit denen explizit ein Polling-Vorgang angestoßen werden kann. 15

16 -Prinzip: Agent - -Station Traps Bestimmte Ereignisse, die einfach zu erkennen sind, z.b. Überschreitung eines Temperaturwertes, werden bereits direkt vom Agenten erkannt. In diesen Fällen sendet der Agent eine unaufgeforderte Nachricht, die als Trap bezeichnet wird, an die -Station. Hier haben wir also keine permanente Kommunikation. In der Analysephase wird dann entschieden, ob das über den Trap gemeldete Ereignis eine Planungsphase erfordert Schnittstelle zwischen Anpassung und Ausführung Auch diese Schnittstelle ist genau betrachtet mehr als eine einfache Übergabe von Information. Nach dem Anstoßen einer Aktion muss der Status dieser Aktion beziehungsweise die erfolgreiche Beendigung oder eine Fehlersituation an die Planungsphase zurückgemeldet werden. Im Falle einer nicht erfolgreichen Durchführung der Aktion muss eventuell in einer erneuten Anpassungsphase der Plan modifiziert und dann erneut ausgeführt werden. 16

17 -Prinzip: Agent - -Station Die folgenden vier Beispiele sollen zeigen, wie an dieser Schnittstelle die Kooperation von -Station und Agenten abläuft. Beispiel 1 Ein Administrator erkennt Performance-Probleme bei der LAN-Anbindung eines Servers und analysiert, dass ein Konfigurationsparameter des TCP/IP- Stacks geändert werden muss. Diesen Plan kann er von seiner - Konsole umsetzen, indem er von dort über die -Applikation an den Agenten einen entsprechenden Auftrag schickt. Die erfolgreiche Durchführung dieser Aktion wird dann vom Agenten bestätigt. Beispiel 2 Ein Server hängt, das bedeutet, auch sein Agent, der auf dem Betriebssystem läuft, antwortet nicht mehr. Der Administrator entscheidet, dass er diesen Server neu starten möchte. Diesen Plan kann er von seiner ServerView-Konsole durchführen. Er stößt diese Aktion zum Beispiel über das RemoteView Service Board an, das die Rolle eines Agenten spielt, der unabhängig vom Zustand des Betriebssystems auf dem Server ist. Beispiel 3 Es wurde entschieden, einen neuen Blade Server in Betrieb zu nehmen. Dazu wird der Deployment Manager aus der PRIMERGY ServerView Suite verwendet, um die einzelnen Server Blades zu installieren bzw. zu klonen. In diesem Fall ist zunächst noch kein Agent auf den Server Blades vorhanden. Der Deployment Manager bringt automatisch über PXE (siehe auch Abschnitt "Protokolle" auf Seite 28) Agenten auf die Server Blades. Diese Agenten führen dann in Kooperation mit Deployment Manager-Komponenten und weiteren Helpers die Installation oder das Klonen aus Autonomes auf dem Server Bisher haben wir die Phasen des -Zyklus betrachtet. Ein weiterer wichtiger zu betrachtender Aspekt ist der Ablaufort dieser Phasen. Prinzipiell gilt, dass ein -Zyklus so lokal wie möglich realisiert sein soll. Betrachten wir das Beispiel, in dem ein Administrator in die Phasen Analyse und Anpassung involviert ist. Der Administrator wird versuchen ein aufgetretenes Problem alleine zu lösen. Er wird erst dann einen weiteren Administrator in die Entscheidung einbeziehen, wenn das Problem dies nötig macht. Mit anderen Worten, der Administrator versucht, den -Zyklus so lokal wie möglich zu halten. 17

18 -Prinzip: Agent - -Station Läuft der -Zyklus komplett automatisch und ohne Mitwirkung eines Administrators ab, wird der Zyklus Autonomic Cycle genannt. Anmerkung: Der Begriff Autonomic Cycle ist abgeleitet vom englischen Begriff autonomic nervous system, dem vegetativen Nervensystem. Dieses passt den Organismus permanent an neue Situationen an, ohne dass dies dem Menschen bewusst wird. Zum Beispiel, wird die Pulsfrequenz oder Atemfrequenz automatisch erhöht bei körperlicher Aktivität. Auch der Autonomic Cycle soll so lokal wie möglich realisiert sein. Wenn zum Beispiel ein Autonomic Cycle komplett auf dem verwalteten Server läuft, dann hat dies unter anderem den Vorteil, dass der Autonomic Cycle nicht von anderen entfernten Komponenten und auch nicht von einem funktionierenden Netzwerk abhängig ist. Zwei Beispiele dafür sind nachfolgend beschrieben. Automatic Server Reconfiguration & Restart (ASR&R) Hier ist der komplette Autonomic Cycle bereits auf BIOS-Ebene von Servern implementiert. Wird ein Systemausfall durch defekte Bauteile, wie fehlerhafte Hauptspeichermodule oder - bei Mehrprozessorsystemen - fehlerhafte Prozessoren verursacht, werden diese Bauteile ausgeblendet. Es wird versucht, den Server erneut zu starten. Parameter, die diesen Autonomic Cycle steuern, wie zum Beispiel die Anzahl der Neustart- Versuche, ehe das System abgeschaltet wird, kann der Administrator von der ServerView-Konsole aus einstellen. Lokaler ServerView Event Manager Der ServerView Event Manager empfängt Traps und entscheidet dann, was zu tun ist. Mögliche Aktionen sind zum Beispiel, einen oder mehrere Administratoren über oder SMS über ein bestimmtes Ereignis zu informieren, einen Eintrag in eine Log-Datei zu erzeugen oder einen Trap an einen anderen, zum Beispiel übergeordneten ServerView Event Manager zu schicken. Es ist jedoch auch möglich, ein Script automatisch auszuführen, das Aktionen anstößt, die in dieser Situation erforderlich sind. Der ServerView Event Manager kann sowohl remote als auch lokal auf einem verwalteten Server installiert und betrieben werden. Insbesondere die Möglichkeit, das automatische Ausführen von Scripts mit dem Empfang von Traps zu verbinden, bietet die Möglichkeit Autonomic Cycles komplett auf verwalteten Servern einzurichten. 18

19 Hierarchische Konfigurationen 2.3 Hierarchische Konfigurationen Dieser Abschnitt beschreibt, welche Topologien mit den beschriebenen abstrakten Komponenten -Konsole, Applikation, Agent und Helper aufgebaut werden können. Es werden einige typische Beispiele, die mit der ServerView Suite realisierbar sind, vorgestellt. Deren Eigenschaften, sowie die Vor- und Nachteile werden diskutiert Lokales Sind alle Komponenten, d.h. Agent, -Applikation, eventuelle Helpers und -Konsole, auf einem Server installiert, dann ist das eine Konfiguration für lokales. Dies ist im Prinzip mit der ServerView Suite möglich, macht aber sicher nur in Ausnahmefällen Sinn. Zum Beispiel, wenn mit der ServerView Suite nur ein einzelner Server lokal überwacht und verwaltet werden soll Point-to-point- Bei Point-to-point- ist auf jedem verwalteten Server neben dem Agenten auch die -Applikation installiert. Die Konsole ist räumlich entfernt. Es ist auch möglich, mehrere Konsolen zu verwenden. Charakteristisch für das Point-to-point- ist, dass von der Konsole aus nur einzelne Server direkt verwaltet werden können; es gibt zum Beispiel nicht die Möglichkeit, sich eine Liste von Servern anzeigen zu lassen bzw. diese in Gruppen zusammenzufassen. 19

20 Hierarchische Konfigurationen MANAGEMENT CONSOLES Console MANAGED SERVER Application Agent Application Agent Bild 3: Point-to-point Die Vorteile dieser Konfiguration sind erhöhte Sicherheit und höhere Verfügbarkeit. Erhöhte Sicherheit Das SNMP-Protokoll, das häufig zwischen Agenten und - Applikationen verwendet wird, bietet Sicherheitsmechanismen, die für einige Einsatzszenarios möglicherweise nicht ausreichen. Für Monitoring- Zwecke ist dies unproblematisch, aber wenn Aktionen über SNMP ausgelöst werden sollen, ist die Sicherheitsstufe oft nicht annehmbar. Da bei dieser Konfiguration keine SNMP-Nachrichten über das Netzwerk gesendet werden, führt die Verwendung von SNMP nicht zu einem Sicherheitsrisiko. Für die Kommunikation zwischen der Konsole und der - Applikation werden Protokolle verwendet, die über SSL/TLS abgesichert werden können. 20

21 Hierarchische Konfigurationen Höhere Verfügbarkeit Läuft der Manager im Gegensatz zum Point-to-point- auf einem zentralen Rechner, dann ist das Server- nur verfügbar, wenn dieser Rechner verfügbar ist. Gegebenenfalls muss er deshalb gedoppelt werden. Bei der Point-to-point Konfiguration läuft jedoch der Manager auf dem verwalteten Server, so dass diese Abhängigkeit nicht vorhanden ist. Typische Beispielkonfigurationen für Point-to-Point- mit ServerView Suite Komponenten sind: Agent und ServerView Operations Manager auf dem verwalteten Rechner. In diesem Fall kann der Rechner von jedem Web-Browser verwaltet werden. Die Kommunikation zwischen Konsole und Manager kann durch SSL/TLS (HTTPS) abgesichert werden. Auch auf den integrated Remote Controller (irmc) oder ein -Blade kann über HTTPS zugegriffen werden. Diese Komponenten stellen die Information bereit und stellen sie außerdem auch graphisch als Web-Seiten dar; sie spielen deshalb die Rolle von Agent und Manager gleichzeitig (siehe auch Abschnitt "-Mode Out-of- Band " auf Seite 45). Agent und ServerView Event Manager auf dem verwalteten Rechner. In diesem Fall gehen keine Traps über das Netz und können deshalb auch nicht verloren gehen. Der ServerView Event Manager kann zum Beispiel direkt vom verwalteten Server den Administrator über Probleme informieren oder automatisch Scripts ausführen. 21

22 Hierarchische Konfigurationen Zentrales Bei dieser Konfiguration läuft die -Applikation auf einem eigenen zentralen Rechner. Die für Point-to-point- beschriebenen Vorteile sind damit nicht mehr gegeben. Die Vorteile dieser Konfiguration sind konsolidierte Übersicht, Gruppenbildung und übergreifende Automatisierungslösungen. Konsolidierte Übersicht Da der Manager Zugriff auf die Information von mehreren Servern hat, kann er eine konsolidierte Übersicht, z.b. als Serverliste darstellen. Diese Darstellung beinhaltet auch den Gesamtstatus jedes Servers. Gruppenbildung In der konsolidierten Darstellung der Serverliste kann der Administrator auch mehrere Server zu einer Servergruppe zusammenfassen. Er kann dann einfach eine Operation auf eine Gruppe anwenden, anstatt die Operation n-mal auf jedem Server einzeln anzuwenden. Dies erleichtert die Arbeit erheblich. Übergreifende Automatisierungslösungen Übergreifende Automatisierungslösungen, die einen Überblick über mehrere Server benötigen, können nur bei zentralen - Applikationen angekoppelt werden. 22

23 Hierarchische Konfigurationen MANAGEMENT CONSOLES Console MANAGEMENT APPLICATIONS Application MANAGED SERVER Agent Agent Bild 4: Zentrales Für konsolidierte Sicht typische ServerView Konfigurationen realisiert man, indem ServerView Operations Manager und/oder der ServerView Event Manager auf einem zentralen Rechner installiert werden. 23

24 Hierarchische Konfigurationen Kaskadiertes -Applikationen, die sich gleichzeitig wie Agenten verhalten können, können kaskadiert werden. Damit ergibt sich eine Topologie, wie sie im Bild 5 dargestellt ist. Die Kaskadierung dient dazu, Informationen der unteren Ebenen auf höheren Ebenen zu verdichten. MANAGEMENT CONSOLES Console Application MANAGEMENT APPLICATIONS Application Application Agent Agent Agent MANAGED SERVER Bild 5: Kaskadiertes In der ServerView Suite ist es der ServerView Event Manager, der beide Rollen spielen kann, die der -Applikation und die des Agenten. In der Rolle der -Applikation empfängt er SNMP-Traps von allen Agenten, die so konfiguriert sind, dass sie Traps an den ServerView Event Manager schicken. Der ServerView Event Manager kann jedoch auch so konfiguriert werden, dass er in bestimmten Situationen selbst Traps schickt und sich somit wie ein Agent verhält. Zum Beispiel kann er empfangene Traps filtern und nur ganz bestimmte weiterschicken. 24

25 Hierarchische Konfigurationen Durch entsprechende Konfiguration mehrerer ServerView Event Manager von einer -Konsole aus kann festgelegt werden, welche Traps von welchem Event Manager an die nächst höherer Ebene geschickt werden sollen. Eine Kaskadierung von ServerView Event Managern ist dann sinnvoll, wenn eine größere Anzahl von Servern verwaltet werden soll. Falls es Sicherheitsaspekte erforderlich machen, können auch Hierarchien mit redundanten Pfaden aufgebaut werden Integration in andere -Systeme Die ServerView Suite kann auch in andere -Systeme, wie CA Unicenter, IBM Tivoli oder BMC Patrol, integriert werden. Dafür stehen spezielle ServerView-Produkte zur Verfügung. Das Bild 6 zeigt schematisch, wie Server--Komponenten in diesen übergeordneten Enterprise -Systemen integriert werden. 25

26 Hierarchische Konfigurationen ENTERPRISE MANAGEMENT SYSTEM Enterprise System MANAGEMENT APPLICATIONS Application Application MANAGED SERVER Agent Agent Agent Bild 6: Integration in andere -Systeme Solche Integrationslösungen umfassen die drei Integrationstypen Trap- Integration, Status-Integration und Call-Integration. Trap-Integration Für die Trap-Integration gibt es zwei Möglichkeiten: Agenten können so konfiguriert werden, dass sie ihre Traps direkt an das Enterprise System schicken. Die zweite Möglichkeit ist ähnlich wie die Kaskadierung von ServerView Event Managern. Agenten schicken ihre Traps an den PRIMERGY ServerView Event Manager, wobei dieser entsprechend seiner Konfiguration alle oder ausgefilterte Traps an das Enterprise System weiterleitet. Eine ähnliche Integration besteht darin, dass ein Enterprise System, z.b. MOM (Microsoft Operations Manager) Einträge in der vom Betriebssystem verwalteten-event-log-datei auswertet. Da der ServerView Event Manager SNMP-Traps als Events in diese Log-Datei einträgt, ist das gewissermaßen eine indirekte Trap-Integration. 26

27 Hierarchische Konfigurationen Status-Integration ServerView Agenten werden vom Enterprise System dazu verwendet, die Existenz von verwalteten Servern im Netz festzustellen (Discovery). Außerdem liefern sie auch den Gesamtstatus des Servers an das Enterprise System. Mit diesen Informationen können dann die verwalteten Server zum Beispiel in Topologie-Ansichten dargestellt werden, wobei in der Regel ein Icon den Typ des Servers darstellt und die Farbe dieses Icons den Gesamtzustand des Servers. Call-Integration Wie oben beschrieben stellen Enterprise Systeme verwaltete PRIMERGY Server durch entsprechende Icons dar. Bei einem Doppelklick auf ein solches Icon, wird automatisch eine -Konsole geöffnet, mit der der Verwalter über eine ServerView -Applikation Zugriff auf den verwalteten Server hat, der durch dieses Icon dargestellt wird. 27