CW-Gespräch mit Carlton G. Amdahl, dem Sohn des PCM-Pioniers Gene Amdahl, über Server-Konzepte und das Aussterben der Mainframes als Rückgrat der DV-Organisation
MÜNCHEN (jm) - Carlton G. Amdahl ist nicht nur durch seinen Vater Gene Amdahl vorbelastet, als Cheftechnologe der kalifornischen Superserver-Firma Netframe Systems Inc. besteht seine Aufgabe darin, Rechner zu entwickeln, die Vorteile der PC-Technogie mit denen der Großrechnerwelt verbinden. Gegenüber der COMPUTERWOCHE äußerte sich Amdahl zum Für und Wider der Migration von Mainframes auf PC- basierte Netzwerke.
CW: Seit September 1990 definiert die IBM ihre Mainframes als Server. Sind Großrechner - wie es immer wieder zu hören ist - Ihrer Meinung nach für Server Aufgaben besser geeignet als etwa Superserver ß la Netframe, die Anleihen sowohl bei der PC- als auch bei der Mainframe-Welt machen?
Amdahl: Also, bei der Terminologie gibt es einige Mißverständnisse. Man sollte zunächst einmal klären, was für eine Rolle dem Server-Konzept in heterogenen DV-Systemen zukommt. In bezug auf Ihre Frage kann man mit der IBM zwar durchaus d'accord sein, daß ein Mainframe sich als Server eignet und als solcher auch durchaus eine Rolle spielt. Es ist aber nicht so, daß einem Großrechner per se Server-Qualitäten zuzuschreiben wären.
CW: Auch wenn man das Mainframe-Konzept heutzutage überdenken muß, so kann man ihm doch gewisse positive Eigenschaften nicht absprechen.
Amdahl: Natürlich. Großrechnersysteme sind typischerweise für sehr große Datenbanken ausgelegt. Sie können ferner auch Hunderte von Telekommunikationsleitungen bedienen. Hingegen sind sie nicht unbedingt geeignet für Hochgeschwindigkeitsaktivitäten in Netzwerk-Server-Umgebungen, wie wir sie bauen.
CW: Trotzdem sind die Anwendungsgebiete noch unterschiedlich?
Amdahl: Sicherlich. Unsere Superserver-Produkte sind eher in LANs anzusiedeln und weniger in Time-sharing-Systemen wie MVS-basierten Großrechnern.
CW: Ist es dann realistisch, Mainframes durch Rechner wie etwa ihre Superserver ersetzen zu wollen?
Amdahl: Definitiv ja. Nehmen Sie unsere eigene Firma: Wir haben einige 3090-Großrechner ausgetauscht. Wissen Sie, die Beschränkungen, denen man auf dem Downsizing-Weg ausgesetzt ist, haben eigentlich nicht so sehr mit Hardwarelimitationen zu tun, sondern mehr mit der begrenzten Verfügbarkeit von vertikaler Anwendungssoftware. Aber hier tut sich einiges.
CW: Ein wichtige Rolle dürften in diesem Zusammenhang Datenbankhersteller spielen.
Amdahl: Eindeutig. Es gibt eine ganze Menge an vertikalen Applikationen, die durch DB-Technologien möglich werden. Über Datenbankanwendungen wird der entscheidende Kampf im Downsizing-Geschäft geführt.
CW: Mainframe-Protagonisten werden auch ein, daß es für die Host-Umgebungen Transaktionsmonitore gibt, die - zumindest in der gewohnten Leistungsdimension für Server- oder auch Unix-Umgebungen nicht existieren.
Amdahl: Das ist zum Teil richtig. Nur in bestimmten Kontexten, etwa bei einer Oracle-Datenbank-Umgebung, sieht man heute schon vergleichbare Ergebnisse, aber wir kennen einige Unternehmen, die sehr hochentwickelte Transaktionsmonitote für Netze entwickeln.
CW: Leistungsstarke Transaktionsmonitore werden aber in Zukunft auch unabhängig von bestimmten Umgebungen angeboten?
Amdahl: Ja. Damit hängt natürlich wieder sehr stark die Entwicklung von Softwarewerkzeugen zusammen - auch das wird kommen.
CW: Kurzfristig?
Amdahl: Nein, das wird noch eine ganze Zeit dauern. Und das bedeutet auch, daß Mainframes nicht in allernächster Zeit sterben werden. Was man allerdings absehen kann, ist, daß die Anwendungsentwicklung für Großrechner langsam nachläßt. Neue Anwendungen dürften vornehmlich für Server-basierte Topologien geschrieben werden.
CW: Ein anderes Vorurteil betrifft die Fähigkeit von Betriebssystemen wie MVS, die gegenüber Real-time-Systemen in Sachen Transaktionen im Vorteil seien.
Amdahl: Es ist aber auch wahr, daß Time-slice-Systeme wie MVS in der Regel gerade in puncto Hochgeschwindigkeits-Netzkommunikation recht schlechte Ergebnisse erzielen. Das Problem besteht darin, Fileserver und Applikations-Server, funktional zu trennen. Dabei handelt es sich nämlich um fundamental unterschiedliche Aufgabenstellungen.
CW: Hat das nicht auch Konsequenzen für die einzusetzende Software?
Amdahl: In der Tat wird für die unterschiedlichen Aufgaben der Server auch unterschiedliche Software benötigt. Für die eigentlichen Anwendungen ist es typisch, robuste Time-sharing-Systeme wie etwa Unix System V.4 zu nutzen. Immer dann, wenn Aufgaben nie beispielsweise das Bedienen von Routing-Protokollen anstehen, die von Fileservern erledigt, werden, sind Real-time-Plattformen wie Netware 386 gefragt.
CW: Das Problem besteht also darin, die einzelnen je nach Aufgabenstellung geeigneten Elemente zusammenzufügen ...
Amdahl: Richtig. Und wir glauben, daß diese Aufgabe in einem Netzwerk am besten erledigt werden kann. Nehmen Sie noch einmal Netframe: Normalerweise versucht man, Ethernet und Token Ring zu verbinden. Wir stecken beides in einen Rechner, wobei wir vor allem Bus- und Speichergeschwindigkeiten optimal zu nutzen suchen.
CW: Die Ausfallsicherheit und damit die Verfügbarkeit sind weitere Punkte, die Großrechner-Adepten ins Feld führen, wenn es gegen PC-basierte Netzwerke geht. Was ist denn an dieser vermeintlichen Stärke der Mainframes dran? Haben herkömmliche Hosts in diesem Punkt wirklich Vorteile?
Amdahl: Doch, das ist absolut richtig. Wir arbeiten aber an diesem Problem. Da ich aus der Mainframe-Entwicklung komme, weiß ich, daß man beim Design der Rechnerlogik ungefähr 30 Prozent allein für automatisch ablaufende Kontroll- und Fehlertoleranz-Charakteristika aufwendet. Das ist - im Vergleich zu PCs - ein Riesenprozentsatz. Und je größer die Rechnersysteme sind, desto wichtiger ist es, die Sicherheitsaspekte nie aus den Augen zu verlieren.
Je komplexen Systeme werden, je mehr störanfällige Einzelteile sie somit inkorporieren, desto wichtiger ist es, auf Ausfallsicherheits-Technologien zurückzugreifen.
CW: Was bedeutet dies für den Anwender?
Amdahl: Das heißt ganz einfach, es muß für den Anwender ein Wachstumsmodell geben, das ihn in die Lage versetzt, Stück für Stück seine Rechnerumgebung auszubauen, ohne daß er gleich seine gesamte DV über den Haufen werfen muß. Schauen Sie sich heute in vielen Server-Netzumgebungen um: Da müssen sie genau das tun, nämlich sämtliche Adapterkarten und alle benutzte Software austauschen, wenn sie wachsen wollen. Das ist in zeitkritischen Umgebungen unzumutbar vor allem deshalb, weil sie auf diese Weise nie die geforderte Stabilität des Gesamtsystems erhalten.
CW: Steht man da nicht vor einem Widerspruch: Einerseits will man die Mainframes loswerden, andererseits stehen alternative Architekturen nicht zur Verfügung?
Amdahl: Man kann dieses Problem lösen, indem man die Architektur des Rechners entsprechend auslegt. Einfach durch neue Add-on-Boards lösen Sie solche Schwierigkeiten sicherlich nicht.
CW: Wie sieht es denn mit Skalierbarkeit von Server-Systemen aus, wenn man sich einmal die Anzahl unterstützter Benutzer überlegt? Eingefleischte Mainframer können da über die Konkurrenz von unten nur müde lächeln.
Amdahl: Die Menge unterstützter Benutzer hängt stark von der Fähigkeit ab, die Anzahl der Peripherie-Subsysteme zu steigern, die ein Server bedienen kann. Rechner wie der Systempro von Compaq gehen nicht in puncto CPU-Leistung in die Knie, sondern wegen ihres I/O-Designs.
CW: Es ist zudem bekannt, daß die Prozessoren einen großen Teil ihrer Arbeit für die Verwaltung von Netzwerkkarten und Controllern aufwenden...
Amdahl: Exakt. Und um dieses Problem zu umgehen, setzen wir in unseren Netframe-Systemen dedizierte Prozessoren ein, die sich um solche I/O-gebundenen Aufgaben kümmern. Die System-CPU kann sich etwa bei unserem Design völlig auf die jeweiligen Applikationen konzentrieren. Auch durch diese Aufgabenteilung erreichen sie ein wesentlich höheres Niveau an Durchsatz.
CW: Ein anderer Punkt von Bedeutung ist das nicht optimale Bus-System in Server-Maschinen, die an PC-Technologie orientiert sind.
Amdahl: In der Tat. Nehmen Sie den EISA-Bus: Sie können bei dieser Bus-Architektur nur eine begrenzte Anzahl von Karten in einem Rechner betreiben. Das hat schlicht elektrotechnische Gründe. Bei Benutzung zu vieler Karten kommt irgendwann der Moment, wo ein EISA-System nicht mehr zuverlässig arbeitet.
CW: Begrenzte Anzahl an Karten heißt ...
Amdahl: ... in den größten PC-basierten Server-Systemen, die noch zuverlässig arbeiten, stecken nicht mehr als acht bis zehn Karten drin. Aus diesem Grunde limitiert ein Unternehmen wie Compaq die Bus-Master-Steckplätze auch auf sechs bis acht Slots.
CW: Was bei dem Design Ihrer Netframe-Systeme ja auch anders gelöst ist ...
Amdahl: Richtig. Wir haben mehr Erweiterungssteckplätze, unsere I/O-Prozessoren sind alle multifunktional, daß heißt, sie bedienen nicht nur eine Netzwerkanbindung, sondern unterstützen auch je sieben Peripherie-Subsysteme, also Band- oder Festplattenlaufwerke.
Das heißt, daß sie mit einem einzigen Servergehäuse acht 16-Mbit-Token-Ring-LANs bedienen können, die dem Anwender acht Subsystem-Kanäle für Peripheriespeicher zur Verfügung stellen, auf denen man bis 56 Platten mit maximal rund 90 GB Speicherkapazität anschließen kann.
CW: Stoßen Sie mit den technologischen Anleihen, die Ihren Netframe-Superservern zur Anwendung kommen, beim Mainframe eigentlich auf offene Ohren in den MIS-Zentralen?
Amdahl: Die verstehen sofort, was wir ihnen sagen. Die wissen zwar auch, daß es bei der Software für Server-basierte Systeme noch hapert - aber sie haben erkannt, daß diese neue Technologie eine Plattform darstellt, die sie in ihren DV-Organisationen brauchen.
CW: Können diese MIS-Manager denn auch damit leben, daß Software für Client-Server-Umgebungen noch nicht im wünschenswerten Maße vorhanden ist?
Amdahl: Sie können es tolerieren, daß die Software-Entwicklung hinterherhinkt. Was man aber nicht vergessen sollte, ist, daß auf Maschinen wie den unseren Software laufen wird, die industrieweit verbreitetet ist, da braucht man keine spezielle Entwicklung. Anwender von Server-basierten Systemen können Software von der Stange benutzen.
CW: Was wiederum einen enormen Kostenvorteil darstellt...
Amdahl: ... und es erhöht die Zahl von Software-Entwicklern, die für eine solche Plattform arbeiten.
CW: Es bestehen ja teilweise recht abenteuerliche Vorstellungen darüber, wieviel Geld man einsparen kann, wenn man Mainframes durch PC-basierte Server-Systeme ersetzt. Was ist denn realistisch?
Amdahl: Das kommt darauf an, was Sie vergleichen. Wenn Sie einfach Hardware gegen Hardware setzen, kommen sie möglicherweise auf einen Faktor von 5 bis 10 an Kosteneinsparungen gegenüber einem Großrechner. Vergleicht man aber die Gesamtkosten - also auch die Kosten für Personal, Anwendungsentwicklung und Ausbildung so kann man mit einem Preisvorteil um den Faktor 2 bis 3 rechnen.
CW: Wenn eine größere Upgrade-Aktion in einer DV-Zentrale ins Haus steht, sollte man sich also heutzutage lieber gleich überlegen, das Geld anders anzulegen?
Amdahl: Bei größeren Aufrüstinvestitionen muß man schnell ein bis zwei Millionen Dollar auf den Tisch legen. Wenn Sie dieses Geld für eine Netzwerklösung ausgeben, amortisieren sich die Kosten sehr schnell. Portieren Sie Ihre wesentlichen Anwendungen dann auch noch Schritt für Schritt auf ein LAN, schaffen Sie Ihrem Mainframe zusätzlich Luft. Wir haben eine Menge Kunden, die genau so vorgehen.
CW: Man sagt ja, daß es Anwendungen gibt - etwa Reservierungssysteme -, die sinnvollerweise nie vom Mainframe heruntergeholt werden können ...
Amdahl: Gut, je nachdem, wie und in welcher Größenordnung die Anbindung etwa an die Telekommunikation, an weltweite Netzwerke gefragt ist, kann das im Einzelfall zutreffen. Aber abgesehen davon, daß im Lauf der Zeit auch hierfür Softwarelösungen entwickelt werden, sehe ich das von Ihnen angesprochene Problem etwas anders: Ich bin der Meinung, daß in den meisten DV-Umgebungen netzwerkbasierte Topologien in der Lage sind, Mainframes zu ersetzen. Server-Systeme, wie wir sie jetzt zu entwickeln beginnen, können etwa 95 Prozent der Anwendungen bedienen, die man heute noch als traditionell Mainframe-orientiert bezeichnet.
CW: Herr Amdahl, wir bedanken uns für das Gespräch.