Client-Server-Loesungen setzen sich am Markt immer staerker durch, doch im Bereich des System- und Netzwerk-Managements von Grossrechnern ist ueber konkrete, implementierte Loesungen wenig bekannt. Gerade hier liegt aber ein grosses Potential an Ressourcen- und damit Kosteneinsparung durch Automation und Integration. Wolfgang Lotz* untersucht die Problematik am Beispiel des User-Helpdesks einer Grossbank.

Es ist schwer verstaendlich, dass die Belange und die Bedeutung des User-Helpdesks in der Praxis oft vernachlaessigt werden, da er doch die erste Anlaufstelle ist, an die sich Endbenutzer bei Problemen aller Art wenden. Deshalb sollten die dort Beschaeftigten mit effizienten Werkzeugen ausgeruestet werden, die ein schnelles Reagieren erlauben und von ihren Benutzern moeglichst wenig spezielle Systemkenntnisse verlangen: Sind doch in der Regel User- Helpdesk-Mitarbeiter Universalisten, die eine breite Palette der Problemanalyse und -behebung beherrschen muessen. Nicht loesbare Endbenutzerprobleme koennen ja an Spezialisten weitergeleitet werden.

Die Konzeption und der aktuelle Stand der Realisierung eines Toolsets fuer den User-Helpdesk sollen am Beispiel des heterogen Netzes einer Grossbank auf Basis des IBM-Produktes "Netview/390" eingehender betrachtet werden. Statt Netview ist prinzipiell auch der Einsatz anderer Produkte vorstellbar.

Komponenten sollten passiv ueberwacht werden

Netz- und System-Management untergliedern sich in unterschiedliche Disziplinen, die unabhaengig von der gewaehlten Plattform mehr oder weniger vollstaendig abgedeckt sein muessen. Aus operativer Sicht sind das Fehler- und Leistungs-Management besonders hervorzuheben. Setzt man voraus, dass in einem Netz beliebiger Architektur stets besonders neuralgische Komponenten existieren, so muss das Fehler- (Fault-)Management die dadurch verursachten Probleme zeitnah erfassen und verarbeiten. Es ist ein Mechanismus gefordert, der passiv den Status dieser Komponenten ueberwacht.

Der User-Helpdesk sollte dagegen nur Endbenutzerprobleme behandeln, fuer die die Methoden des passiven Monitorings allerdings ungeeignet sind. Schwierigkeiten treten hier naturgemaess am "Netzrand" auf und werden im allgemeinen von der Systemsteuerung bei grossen heterogenen Netzen nicht bemerkt, wenn innerhalb der Leitungsfuehrung keine wichtigen Knoten betroffen sind.

Ausserdem ist die Problemstellung nicht auf die Ermittlung eines Ressourcenstatus beschraenkt. Vielmehr ist der User-Helpdesk mit kombinierten Problemen konfrontiert, auf die er ueblicherweise erst nach einem Anruf durch den betroffenen Endanwender reagieren kann. Die eingesetzte Methode ist somit das aktive Monitoring von Endbenutzerressourcen.

Ein typisches User-Helpdesk-Problem ist eine Terminal-Host- Session, die im Bereich der Systems Network Architecture (SNA) fehlerhaft ist. Die physische Leitungsfuehrung ist komplex. Logisch liegen das Endgeraet und die Applikation in unterschiedlichen SNA- Netzen. Die Wegfuehrung erstreckt sich physisch ueber verschiedene X.25-Strecken (Trunks und andere). In Netzteilbereichen sind Multiplexer-Strecken vorhanden.

Deshalb sind auf der SNA-Ebene die Moeglichkeiten der Problemanalyse gering. Zwar lassen sich die betroffenen Netz- und Systemkomponenten in unterschiedlichen Netzarchitekturen von einem User-Helpdesk-Arbeitsplatz aus fuer alle Architekturen analysieren. Doch diese Integration setzt die Verwendung von Gateways auf Basis von Netview/PC in einem sogenannten Service-Point voraus, um Nicht-SNA-Ressourcen direkt einbeziehen zu koennen.

SNA-Analyse ist in der Praxis sehr komplex

Um Detailanalysen von SNA-Ressourcen zu erhalten, die selbst oder deren Session-Partner auf unterschiedlichen Host-Rechnern im Netz zugaenglich sind, muessen verteilte SNA-Abfragen auf den verschiedenen Rechnern durchgefuehrt werden. In der Praxis stellt sich die SNA-Analyse noch wesentlich komplexer dar, da ueblicherweise ein Session-Management-Produkt eingesetzt wird, das "Multisessions" eines Endusers zu vielen Applikationen auf unterschiedlichen Host-Rechnern aufbaut. Zudem sind Session- Manager aus SNA-Sicht reine Anwendungen, die nicht mit SNA- Mitteln, sondern nur ueber das Betriebssystem zu analysieren sind.

Daraus wird ersichtlich, dass die Analyseergebnisse, die von unterschiedlichen Rechnern gewonnen werden, zusammenzufuehren, logisch aufzubereiten und geeignet darzustellen sind. Hierzu lassen sich drei Integrationsstufen unterscheiden. Die Integration auf SNA-Basis inklusive Session-Management in einer Mehrrechnerumgebung bezeichnet man als zweite Integrationsstufe.

Wird das SNA-Netz als logisches Netz oberhalb eines Corporate Network (zum Beispiel auf Basis von X.25) "gelegt", sind zusaetzlich alle moeglicherweise betroffenen Nicht-SNA-Komponenten zu analysieren, die zwischen dem Arbeitsplatz des Endanwenders und den aufgerufenen Anwendungen liegen. Dazu sind automatisierte Abfragen fuer die entsprechende Netview/PC-Anwendung des X.25- oder Multiplexer-Netzes zu generieren. Die Integration der Nicht-SNA- Welten ist die dritte Integrationsstufe.

Alle drei Integrationsstufen sind unter Einsatz von Automationstechniken zu konzipieren. Die Host-Plattform, die die integrierte Netzwerk-Management-Station enthaelt, fungiert als primaeres Management-System (Client), alle anderen sind Sekundaersysteme (Server).

Die Arbeitsplattform und das primaere Netzwerk-Management-System als Traegersystem definieren einen "Umbrella", von dem aus der Zugriff auf die einzelnen Netze und innerhalb dieser auf die Teilnetze moeglich wird. Idealerweise sollte dieser Umbrella unabhaengig von einer Systemplattform sein. Er ist das Kernsystem, in das die anderen Management-Systeme als Sekundaersysteme integriert werden, und stellt die grafische Benutzer-Schnittstelle zur Verfuegung.

In einer heterogenen Umgebung besteht prinzipiell die Moeglichkeit, sich von einem Terminal aus an einem Session-Manager eines entfernten Hosts einzuloggen und von dort auf weitere Hosts zuzugreifen (sofern dies dem Endbenutzer erlaubt ist). Hieraus ergibt sich eine grosse Vielfalt von Problemen, denen die Mitarbeiter des User-Helpdesks im Praxisbetrieb potentiell ausgesetzt sind.

Als Netz- und System-Management-Plattform wird im Fall der Grossbank wie gesagt Netview eingesetzt. Daraus ergeben sich mehrere Moeglichkeiten, Automation zu betreiben, zum Beispiel durch Customization der System-Tasks oder Verwendung von API- Schnittstellen. Im konkreten Fall wurde eine moeglichst weitgehende Abdeckung der Anforderungen durch Nutzung der Standard-Produkt- Features angestrebt. Darauf aufbauend, implementierte man eine systemnahe Client-Server-Anwendung auf Basis der prozeduralen Sprache Rexx.

Der Client realisiert die Arbeitsplattform fuer den Helpdesk- Mitarbeiter. Systemtechnisch ist er als dem User zugeordnete Subtask innerhalb des Adressraumes Netview eingerichtet. Der Client selbst ist wiederum zweigeteilt in zwei Prozesse, einen View- Prozess, der den Datenaustausch mit der grafischen Oberflaeche verwaltet, und einen Kontrollprozess fuer jede Architektur, der die Verarbeitung innerhalb dieser Netz- oder Systemarchitektur steuert. Dabei stehen einem Client mehrere Server zur Verfuegung.

Die Relation Client zu Server ist anpassbar

Jeder Server besteht aus einem Exekutorprozess pro Architektur, ueber den die Kommandos an den entsprechenden Adressraum abgesetzt und die Antworten an den initiierenden Kontrollprozess zurueckgegeben werden. Um den angestrebten Automatisierungsgrad zu erreichen, wurde der Client nur einmal im Gesamtnetz implementiert. Die Relation Client zu Server ist aber innerhalb des Tools anpassbar.

Zwischen Kontroll- und Exekutorprozess besteht bei unterschiedlichen Netviews auf verschiedenen Hosts eine Advanced Program-to-Program Communication (APPC). Das heisst, der Helpdesk- Mitarbeiter benoetigt nur noch eine Session zu dem Client-Netview, alle anderen Sessions laufen im Hintergrund zu allen anderen Netviews (Server). Diese verwalten sowohl die Netz- als auch Systemabfragen und routen die Ergebnisse an den Client zurueck.

Um eine durchgaengige Automation einsetzen zu koennen, entschied man sich fuer die Separation der "heterogenen" Wegfuehrung in "homogene" Teilwege pro Architektur.

Dabei erfolgt die Analyse der ersten homogenen "Teilwelt" ueber Automaten rechneruebergreifend fuer das Netz (zum Beispiel SNA) und das System (zum Beispiel Session-Manager). An einem Problemanalyse-Bildschirm koennen die User-Helpdesk-Mitarbeiter die Ergebnisse beurteilen und gaengige Probleme durch voreingestellte Kommandos beheben. Damit entsteht ein integriertes Gesamtbild der Komponenten zwischen Enduser und Applikation.

Bevor ein solches Automationsprojekt in die Praxis umgesetzt wird, ist auch die Loesungsstrategie zu definieren. Die Handhabung ist denkbar einfach. Lediglich der Ressourcenname und die Zielarchitektur sind zu spezifizieren. Alles uebrige sollten die Automaten erledigen. Da die Sessions "im Hintergrund" bestehen bleiben, ist das System sehr performant.

Die Abbildung verdeutlicht die Zusammenhaenge zwischen den Endbenutzer-Sessions und den Moeglichkeiten des User-Helpdesks, komplexe Probleme zu analysieren und zu loesen. Das Client-Netview sowie ein Server-Netview liegen im SNA-Netz 2. Der Helpdesk- Mitarbeiter hat eine Session zum Client-Netview. Eine seiner Anwendungen ist der beschriebene aktive Monitor. Weitere VTAM- Anwendungen in dieser Domain sind der Session-Manager und eine beliebige Applikation (zum Beispiel CICS).

Vom Client-Netview gibt es APPC/LU6.2-Sessions zu einem Server- Netview im gleichen SNA-Netz und in einem anderen SNA-Netz (SNA- Netz 1). Zu dieser Netview-Domain gehoeren auch die Service-Points (mit Netview/PC und einer Service-Point-Applikation) fuer den Uebergang von der SNA- in die Non-SNA-Welt. Diese Applikation konvertiert SNA-Kommandos in die Kommandos der Zielarchitektur und umgekehrt Alarme in SNA-Alerts. Aus Host-Sicht steht damit eine bidirektionale Non-SNA-Schnittstelle innerhalb von Netview zur Verfuegung.

Die in der Abbildung eingezeichnete SNA-Ressource (Enduser mit Problem) ist ueber einen Session-Manager mit einer Applikation auf dem gleichen Host und einer Applikation auf einem anderen Host in einem anderen Netz verbunden. Fuer die Problemanalyse selbst koennen mehrere Automationsstufen online gewaehlt werden. Im allgemeinen Fall wird die Ressource gesucht, wenn sie der Helpdesk-Mitarbeiter nicht zuordnen kann, wird der sogenannte Navigator aktiviert. Nach dem Auffinden wird sie bezueglich ihres Status und des Status aller beteiligten Knoten automatisch analysiert. Aktionen, zum Beispiel eine Aktivierung, werden dann vom Helpdesk-Mitarbeiter innerhalb des aktiven Monitors im Client-Netview an das oder die Server- Netviews abgesetzt und das Ergebnis als Farbgrafik auf dem Bildschirm angezeigt.

Liegt der Netzwerk-Management-Umbrella in der SNA-Architektur, sind Service-Points als Netzuebergaenge in andere Netzarchitekturen einzusetzen. Soll ein X.25-Knoten analysiert werden, wird ein entsprechendes SNA-Kommando, das ein X.25-Kommando enthaelt, ueber die Service-Point-Applikation in das X.25-Netz geleitet. Das Ergebnis, das auf dem gleichen Weg zurueckkommt, wird ueber den oben beschriebenen Kontrollprozess an den View-Prozess via APPC gegeben.

Der Helpdesk-Mitarbeiter bekommt auf einem Bildschirm dann in unterschiedlichen Fenstern die homogenen Teilwelten dargestellt. Die Analyseergebnisse, die auf dem "integrierten Bildschirm" vorliegen, sind die Grundlage fuer die automatisierte Weiterleitung an das Problem-Management. Ausserdem koennen Filter implementiert werden, die Problemextrakte in Problemtickets abbilden und in eine Problem-Management-Database einspeisen. Andererseits koennen auch spezielle Ressourcendaten aus einer Netzdatenbank vorher abgefragt werden, so dass sich noch groessere Rationalisierung erzielen laesst.

Passiver Monitor sammelt die Ereignisse zentral

Die Automation erstreckt sich dann von den Feldern Fault- und Performance-Management bis hin zum Problem- sowie Konfigurations- Management. Die Aktivitaeten des User-Helpdesks lassen sich somit in einfacher Weise definiert abschliessen und an die naechste Gruppe im Rahmen der Problemeskalation weiterleiten.

Diese Schilderung vereinfacht das Verfahren allerdings stark. In einer realen Installation gehoeren zum beschriebenen aktiven Monitor weitere Automationsanwendungen. Der passive Monitor sammelt die Ereignisse im Sinne von Netzwerk-Events beziehungsweise Alerts an einer zentralen Stelle (Focal-Point) aus allen SNA-Netzen und innerhalb dieser aus allen VTAM-Domains. Dazu werden die Alerts von allen Netzwerk-Management-Systemen an das primaere System geroutet. Zusaetzlich werden die Alarme aus den Non- SNA-Netzen aufbereitet und an den Focal-Point weitergeleitet.

Dabei ueberwacht der Topologie-Manager die Kernressourcen. Dies sind die wichtigsten Nodes der oberen SNA-Ebene beziehungsweise wichtige Systeme und Gateways anderer Architekturen. Er fuehrt als Funktion im wesentlichen das sogenannte Auto-Discovery aus, das zyklisch die Topologie analysiert und diese Ergebnisse in den aktiven Monitor einbringt.

Bei der Realisierung einer solchen Loesung ist darauf zu achten, dass die Produkte der beteiligten Hersteller aktuell und strategisch aufeinander abgestimmt sind. Zudem sollte die Plattform mit Blick in die Zukunft den Migrationsweg zu anderen Loesungen nicht verbauen. Deshalb muessen Netz-Management- Anwendungen portabel sein, das heisst, der Umbrella, der alle vorhandenen Verwaltungssysteme in einem Unternehmen verbindet, muss auch auf einer offenen Plattform implementiert werden koennen.

Die Umbrella-Plattform fuer ein uebergreifendes System- und Netzwerk-Management sollte zwischen Mainframe, offenen Systemen und LAN-Loesungen frei waehlbar sein. Konkret heisst dies, dass beispielsweise in gemischten SNA-, TCP/IP- und sonstigen Netzen der Umbrella auch in einem SNMP-basierten Netz-Managementsystem implementiert werden kann, von dem aus eine Host-basierte Netzadministration abgefragt wird. Inwieweit dieses "in seiner Welt" seine Aufgaben behalten wird, ist unternehmensspezifisch festzulegen. Erste Produkte in dieser Richtung sind bereits am Markt oder angekuendigt. In Zukunft werden die Moeglichkeiten und damit auch Freiheiten bei der Implementierung von verteilten Loesungen stark zunehmen. Gleichermassen wird der konzeptionelle Aufwand steigen und Know-how gefragt sein, das die Kenntnis von Produkten der unterschiedlichsten Hersteller einschliesst.

* Wolfgang Lotz ist Senior Consultant bei der Ploenzke AG in Wiesbaden. Sein fachlicher Schwerpunkt liegt im Bereich heterogene Netze, Netzwerk- und System-Management sowie Automation.