Vom Mainframe zum Client-Server und zurück

Achim Scharf

Die in den achtziger Jahren und zuvor installierten EDV-Systeme waren auf den zentralen Groß-(Host)Rechner ausgerichtet, Anwendungen und Daten wurden relativ sicher im Rechenzentrum gespeichert. Es gab noch keine grafische Bedienoberfläche, Ein- und Ausgaben erfolgten rein alphanumerisch über Terminals ohne eigene Verarbeitungsleistung. Die Vorteile einer Host-orientierten Lösung lagen in der effizienten Verwaltung von Informationen als auch von Ressourcen des EDV-Bereiches mit niedrigsten Kosten pro Endbenutzer sowie in der weitgehenden Vorhersagbarkeit von Kosten, Verfügbarkeit und des Serviceniveaus. Der wesentliche Nachteil lag in einer relativ starken Unflexibilität bezogen auf neue und andere Anforderungen.

Als zu Beginn der achtziger Jahre der Personal Computer (PC) auf den Markt kam, konnte er nur als Einzelarbeitsplatz eingesetzt werden. Dann wurde der PC an Mainframes angeschlossen und emulierte "dumme Terminals". Diese Kombination eröffnete die Möglichkeit, Daten aus den laufenden Anwendungssystemen zu übernehmen und mit PC-Standardsoftware weiter zu verarbeiten.

Die Client-Server-Architektur führte zu einem "Downsizing" der Systeme, und damit argumentierte der damalige "David" Sun gegen den "Goliath" IBM. "Während mit jedem Terminal im klassischen Großrechnerbetrieb die Gesamtleistung abnimmt, steigt mit jedem Client und mit jedem Server die Gesamtleistung des verteilten Client-Server Verbundes. Statt alle Verarbeitungsfunktionen auf einen Großrechner zu konzentrieren, finden wir in Client-Server-Architekturen eine Verteilung der Leistungsanforderungen auf eine Vielfalt von Geräten", so Sun-Chef Scott McNealy damals. Im November 1992 stellte er das SPARC Center 2000 vor, einen Unix-Server für bis zu 20 Prozessoren, mit denen Sun in das Rechenzentrum vordringen wollte. Viele Banken ließen sich auch von den Vorteilen der Enterprise Server überzeugen.

Siemens-Nixdorf (heute Fujitsu-Siemens Computer) setzte in seiner MX-Serverfamilie im Jahr 1986 auf die NS-3200-Prozessoren von National Semiconductor und Unix. Mit dem 8-Prozessor-System MX-500 kam auch der Übergang vom Unix III auf System V unter der Bezeichnung Sinix. Zielrichtung war die IBM-SNA-Systemwelt. Die nachfolgende RM-Serverfamilie basierte auf MIPS-Prozessoren. Im November 1994 führte SNI in der Towerklasse die ersten kommerziellen Risc-Systeme (RM400) mit 200-MHz-Prozessor ein. Mit drei RM600-Multiprozessor-Servern wurden im März 1995 auch Midrange- und Highend-Systeme zu Einstiegspreisen zwischen 60.000 und 170.000 Euro angeboten.

Mit dem Reliant RM1000 Parallel-Server stellte SNI zur CeBIT 1995 eine massiv-parallele Server-Architektur vor. Sie erlaubte eine Skalierbarkeit mit Hunderten von Verarbeitungsrechnern (Knoten) und mehr als zehn Terabyte Speicher. Als Knoten galten Einzelprozessoren, aber auch SMP-Systeme der RM-Server-Linie von SNI oder der Nile-Serie von Pyramid. Der Preis für eine lauffähige Einstiegskonfiguration mit vier Prozessoren und 16 Gigabyte Festplatten lag bei 150.000 Euro. "Mit diesem Portfolio sind wir der einzige Anbieter einer kompletten Linie für durchgängige unternehmensweite Anwendungen, angefangen bei Ein- und Multiprozessor-Rechnern über gekoppelte symmetrische Multiprozessoren bis hin zu Mainframes und massiv-parallelen Systemen einschließlich der Kopplung zu Prozessorkomplexen", stellte denn auch Klaus Gewald, Bereichsleiter Midrange Systems, fest. Die erhoffte Akzeptanz im Markt ließ allerdings auf sich warten, so dass der RM 1000 als Flop zu verbuchen war.

Heute setzt Fujitsu-Siemens bei Servern verstärkt auf Intel-Prozessoren und Windows 2000/2003 als Server-Betriebssystem, führt aber auch noch modernisierte Mainframes mit dem Betriebssystem BS2000 weiter.

Logische Fortentwicklung

Die Client-Server-Architektur war eine Fortentwicklung der Software-Strukturierung. Unstrukturierte, monolithische Programme wurden schon in den sechziger Jahren durch modularisierte Programme abgelöst. Die Weiterentwicklung dieser Modularität führte zu einer dreiteiligen Struktur nach Benutzer-, Prozess- sowie Daten-Schicht.

Frühe Formen einer derart geschichteten Software wiesen recht diffuse Schnittstellen zwischen den aneinandergrenzenden Schichten auf. Um die Austauschbarkeit der Schichten zu ermöglichen, war eine Verbesserung der Schnittstellen erforderlich, die Aktivierung der Nachbarschicht erfolgte nur noch über logische Kommandos, deren Interpretation und Ausführung "generische Schnittstellen" übernahmen. Damit war die Austauschbarkeit der Schichten generell möglich.

Die Client-Server-Architektur war eine Fortentwicklung dieses Schichtenmodells. Die Funktionen der Datenschicht wurden in die Server-Komponente und die der Prozess-Schicht sowohl auf die Clients als auch auf die Server-Ebene implementiert.

Lokale Netzwerke (LAN) waren daher eine naheliegende Plattform für die Realisierung von Client-Server-Architekturen: die Client- und Server-Prozesse wurden jeweils eigenständigen Rechnereinheiten zugewiesen. Mainframes konnten als Server in Koexistenz mit Unix-Rechnern weiter verwendet werden, während PCs als Clients dienen. Die Client-Systeme (Frontends) wurden den Bedürfnissen des jeweiligen Anwenders entsprechend in Hard- und Software konfiguriert. Ähnliches galt für die Server, wobei sie sehr unterschiedliche Aufgaben wie Programm-, File-, Druck-, Kommunikations- oder Datenbank-Server wahrnahmen.

Die Verteilung der Server-Funktionen auf unterschiedliche Geräte führte zu einer Entbündelung der Leistungsansprüche an die Hardware. Das gleiche galt für die Clients: durch ihre Fähigkeit zur eigenständigen Programmabwicklung bewirkten sie eine massive Entlastung zentraler Hardware-Ressourcen.

Die wachsende Komplexität der technischen Systeme von mehreren vernetzten Systemen mag zwar ein Nachteil sein, dem jedoch massive Vorteile gegenüberstanden. Transaktionen zwischen dem Client und Server sind beispielsweise erheblich netzintensiver als bei Terminal-Host-Anwendungen. So erforderte eine typische Terminal-Host-Transaktion etwa 9 Kilobit per Sekunde, während die gleiche Client-Server-Anwendung mit mehreren Netzwerk-Transaktionen auf mehr als 100 Kilobit kommt. Im Gegensatz zu einer Terminal-Host-Transaktion werden solche Transaktionen von Client-Server-Systemen in kleinen Schritten abgearbeitet, die Veränderungen im Verkehrsverhalten von bis zum Faktor 10 zur Folge haben können. Downsizing der Anwendungen hieß daher Upsizing des Netzes.

Andererseits - die Kosten pro Transaktion bei Datenbankanwendungen ließen sich im Client-Server-Umfeld gegebenenfalls um den Faktor 40 gegenüber Großrechnerumgebungen senken, so die Argumentation von Sun, und das sei ein wesentlicher Grund zum Downsizing. Der Server, und die auf ihn ausgelagerte Anwendungssoftware, stand im Mittelpunkt des Downsizing.

Softwareseitig hatte die Aufteilung der Programme in einen Frontend- und einen Backend-Teil zudem einen großen praktischen Nutzen. Durch diese Aufteilung der Funktionen auf unterschiedliche technische Komponenten wurde eine strikte Schichtenbildung in der Software erzwungen, die einen wertvollen Beitrag zur Verbesserung der Transparenz und somit zur Verbesserung der Wartungsbedingungen lieferte. Die Wechselbarkeit der Schichten (Frontend und Backend) wurde durch diese Architektur ebenfalls begünstigt.

Die dritte Welle

Der Client/Server-Ansatz wurde zwar von den Protagonisten, allen voran Sun als Königsweg gepriesen, hat sich jedoch nicht als solcher erwiesen, aber auch nicht als Flop.

Multiprozessor-Server mit Terabyte-Speichern übernahmen die Rolle der Mainframes und durch die Interaktivität der "Productivity Tools" entstand ein hohes Datenaufkommen im Netzwerk, Ethernet mit 10 Megabit/Sekunde reichte oftmals nicht mehr aus, besonders bei grafikintensiven Anwendungen und Multimedia.

Netzwerk-orientierte Lösungen versprachen einen Ausweg aus diesen Problematiken. Die grundsätzliche Definition ging davon aus, dass jeder Nutzer einen Zugriff auf die notwendigen Anwendungen, Daten und Dienste hat, die irgendwo in einem Netzwerk residieren. "Die dritte Welle des Computing ist ausgebrochen, das Netz ist der Computer", so Louis Gerstner, General Manager von IBM im Frühjahr 1995. Netzwerk-Computing und der Netzwerk-Computer als Client wurden unter dem Aspekt der Unterhaltskosten nicht nur in puncto Aufrüstung und Softwareverteilung interessant, sondern auch in der Netzwerkwartung.

Das Paradigma Network Computing und Netzwerk-Computer setzte auf sogenannte "Thin Clients". Apple, IBM, Netscape, Oracle und Sun entwickelten dafür 1996 eine NC-Referenzplattform. Nicht zuletzt die Entwicklung der Internet-Browser und deren Einsatz auch in firmeneigenen Intranets ließ den NC als intelligentes Terminal am Arbeitsplatz interessant erscheinen. Das Konzept ist simpel, ein Web-Browser wurde als einzige Applikation lokal gespeichert. Dies ermöglichte die Herstellung von preiswerten Rechnern, die keine Festplatten, wenig Hauptspeicher und eine kleine Zentraleinheit benötigten. Dennoch, der NC oder Windows-Terminals konnten den PC nicht verdrängen, sondern letztlich nur ergänzen.

Der Mainframe kommt zurück

Mit Einführung von Client-Server-Architekturen und der teilweisen Ablösung von Großrechnern ging es den Managern in erster Linie um die in Aussicht gestellten Kostenreduktionen. Der steigende Einsatz von Clients hat die Server aber nicht in dem erwarteten Maße entlastet, wie Untersuchungen des deutschen IT-Beratungsunternehmens Compass aus dem Jahr 1998 zeigten. Im Gegenteil sei die Arbeitslast sogar meist angestiegen.

Der allgemeine Kostentrend für den Betrieb eines Rechenzentrums geht aber in die gegenläufige Richtung. Trotz gestiegener Arbeitsleistung gingen diese Kosten merklich zurück. Die Einheitenkosten für die stets wachsende Anzahl von Tischrechnern sank hingegen nur langsam. Die Gesamtkosten der Informationstechnik sind also nicht im erwarteten Maße gesunken, in einigen Fällen sind sie den Untersuchungen zufolge sogar gestiegen. Der Durchschnittspreis pro tausend CPU-Sekunden sei von 4 Euro (1994) auf 1 Euro (1997) gesunken, vermerkte die Studie. Die durchschnittliche Rechenzentrumsbelastung habe sich in der gleichen Zeit beinahe verdoppelt, von 8 Millionen CPU-Sekunden pro Monat (1994) auf über 15 Millionen in 1997. Die durchschnittlichen Jahreskosten sanken jedoch von 10 Millionen Euro auf knapp 5 Millionen.

Die gleichen Unternehmen verzeichneten jedoch einen deutlichen Anstieg ihrer Kosten im Client/Server-Bereich. Wurden 1994 noch etwa 3500 Euro Jahreskosten pro Client veranschlagt, so sanken diese zwar bis 1997 auf 2600 Euro. Da sich die durchschnittliche Anzahl eingesetzter Clients allerdings lawinenartig von durchschnittlich 2000 auf mehr als 4000 vermehrt hat, führte dies dennoch zu einer Kostenexplosion von 5 Millionen Euro pro Jahr (1994) auf 13 Millionen Euro/Jahr (1997). Die Gründe hierfür waren laut Compass vielfältig. Große Mengen einfacher Terminals wurden durch voll funktionsfähige PCs ersetzt und mit Applikationspaketen für Textverarbeitung, Tabellenkalkulation, elektronischen Kalendern usw. ausgestattet. Der vermehrte Einsatz von Geschäftsanwendungen (wie Finanzsoftware, Personalverwaltung, Fertigungssteuerung) stellte aber auch höhere Anforderungen an die Datenverarbeitung und Verteilungsroutinen, was wiederum zu einer erhöhten Arbeitsbelastung im Rechenzentrum führte. Trotz komplexerer Transaktionen wurde gleichzeitig Wert auf gesteigerte Benutzerfreundlichkeit gelegt, und damit wesentlich aufwendigere Rechenprozesse dem Rechenzentrum abverlangt.

Wenn nun Client/Server-Systeme nicht im erwarteten Umfang zu Kostenreduktionen geführt haben, so sollte man doch wenigstens auf eine erhöhte Produktivität bauen können. Nur wenige Unternehmen verfügen jedoch über die Mittel, Produktivitätsveränderungen durch den Einsatz von Client/Server-Technologie im eigenen Hause nachzuweisen. Wertsteigerungen ergeben sich noch immer am offensichtlichsten durch den Einsatz von Business-Applikationen, die wiederum aus Sicherheitsgründen zentral und nicht verteilt eingesetzt werden. Auch der Silberstreifen der Netz-Computer hinsichtlich Kostensenkung war trügerisch. Sie eignen sich am besten zum Ersatz der Terminals oder bei Call-Centern, wo nur eine begrenzte Menge von Applikationen schnell zur Verfügung gestellt werden muss.

Unter diesen Aspekten sind viele Unternehmen in den zentralen Anwendungen den Großrechnern nicht nur treu geblieben, sondern führten leistungsfähigere Systeme ein, die zudem in der Hardware und den Software-Lizenzen deutlich kostengünstiger wurden. "Weil die Unternehmen jetzt dazu übergehen, sämtliche Geschäftsprozesse mit Hilfe der Informationstechnik zu realisieren, erleben wir die Renaissance der Großrechner, weil sie für die klassischen Attribute wie Verfügbarkeit, Sicherheit und Ausbaufähigkeit stehen", stellte Hermann-Josef Lamberti, Chef von IBM Deutschland, Anfang 1998 fest. "Wenn ein R/3-Server mit tausend lokalen Anwendern gegenüber dem Internet geöffnet wird, dann kommen ganz schnell viel höhere Nutzerzahlen zustande. Wenn Unternehmen damit beginnen, die Entscheidungsmechanismen ihrer Kunden in Data Warehouses abzuspeichern und zu analysieren, dann explodiert schnell der Speicherbedarf. Und wenn mehr und mehr Verschlüsselungsverfahren eingesetzt werden, um den elektronischen Handel sicherer zu machen, dann steigert das den erforderlichen Rechenaufwand enorm."

Heute heißt die IBM-Strategie "On Demand Services", Rechenleistung auf Abruf. Zahlreiche Anwender haben laut IBM in den letzten Jahren die Qualitäten des Großrechners im Umfeld neuer Anwendungen, insbesondere bei Linux und modernen Softwarelösungen, neu entdeckt. Nach Untersuchungen von IDC gewann der Mainframe im Jahr 2002 3% Marktanteile im Server-Segment mit 250.000 $ Anschaffungspreis. Die IBM ZSeries hat seit der Einführung des Z900 im Jahr 2000 sogar 8% Marktanteil dazu gewonnen. "Im vergangenen Jahr konnten wir mehr als hundert neue SAP-Anwender gewinnen, rund 17% vom Workload laufen unter Linux", unterstreicht Francis Kuhlen, Vice President der IBM Systems Group EMEA. Die neue Generation Z990 habe 4 Jahre Entwicklungszeit und 1 Mrd. $ Investitionen gekostet. Der z990 bietet eine Leistung von bis zu 9.000 MIPS (Million Instructions per Second) auf 32 Prozessoren - das sind doppelt so viele Prozessoren und fast dreimal so viel Systemkapazität wie beim Vorgängermodell Z900. Bis zu 30 logische Partitionen (LPARs) werden auf dem z990 unterstützt, doppelt so viele virtuelle Server im Vergleich zum Vorgängermodell. Zur Konsolidierung von Serverfarmen lassen sich mit dem Betriebssystem Z/VM 4.4 Hunderte von virtuellen Linux-Servern implementieren und administrieren.