Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.


19.11.1993

Grosssysteme laufen kuenftig unter Unix Konsolidierungszwang foerdert die Bereitschaft zum Upsizing

MUENCHEN (CW) - Alle Welt redet vom Downsizing - nicht so Werner Dirlewanger*. Der Wissenschaftler ist davon ueberzeugt, dass parallel zu diesem Trend eine gegenlaeufige Entwicklung stattfindet, das Upsizing. Anwender konsolidieren ihre RZs und legen Kapazitaeten dort zusammen, wo es wirtschaftlich sinnvoll ist. Proprietaere Betriebssysteme haben in solchen Rechenzentren nichts mehr zu suchen.

Gene Amdahl, der Vater der 360-Grossrechnerarchitektur und damit aller ihrer Nachfolger, wurde vor kurzem nach seiner Definition eines Mainframes gefragt. Seine Antwort lautete, es sei ein "sehr grosser Computer, der eine Menge von Zugriffen auf mehrere Datenbanken abwickele". Nun ist zur Zeit ein Trend erkennbar, die DV-Versorgung von Unternehmen moeglichst nicht mehr mit Mainframes, sondern mit Systemen kleinerer Groesse zu realisieren (Downsizing). Offen bleibt in vielen Abhandlungen und Diskussionen, ob mit dem Attribut "kleiner" die Kosten, die Leistung einer Anlage - was immer darunter verstanden wird - oder etwas ganz anderes gemeint ist.

Stroemungen und Trends bleiben oft nicht ohne Gegenstroemung. Daher laesst sich die Frage stellen, ob es zum Downsizing eventuell auch eine Gegenentwicklung gibt. Betrachtet man die DV-Szene genau, so kann man tatsaechlich eine Reihe von Beschaffungsvorgaengen beobachten, bei denen Unternehmen, entgegen dem allgemeinen Trend, zunehmend groessere Systeme einsetzen.

Da es sich dabei meist um sehr grosse Firmen mit langjaehriger IT- Erfahrung handelt und weiterhin um DV-Systeme, die in der obersten Preiskategorie liegen, darf man davon ausgehen, dass solche Anschaffungen allein schon wegen der Kostendimensionen nicht unueberlegt zustande kommen. Insbesondere entstehen solche Installationen sicher nicht aus einer blossen Unkenntnis der Vorteile kleinerer Systeme und der von dezentral strukturierter DV.

Die Beispiele fuer solche Anschaffungen lassen sich in zwei Klassen einordnen. Eine Kategorie bilden solche Rechenzentren, die regelmaessig die jeweils am Markt erscheinenden groessten Modelle ihres Herstellers anschaffen. Zu dieser Gruppe zaehlt auch eine Reihe von DV-Serviceunternehmen - allen voran die grossen Outsourcing-Anbieter -, die bereits Groesstsysteme einsetzen. Die Rechner laufen sowohl mit proprietaeren Betriebssystemen wie auch zum Teil schon mit dem offenen Betriebssystem Unix.

Zu dieser Klasse gehoeren auch serviceleistende Grossrechenzentren, etwa Amadeus oder Galileo. Und schliesslich zaehlen auch die technisch-wissenschaftlichen Rechenzentren dazu, die mit Superrechnern arbeiten. Hier werden auch in Zukunft immer groessere DV-Systeme installiert. Dort findet also keineswegs ein Downsizing (oder Rightsizing) statt, sondern - um den entsprechenden englischen Ausdruck zu gebrauchen - ein Upsizing. Der wesentliche Antrieb dafuer, dass diese DV-Betreiber vornehmlich Grosssysteme nutzen, liegt im Umfang der vorhandenen Applikationen, die nicht teilbar sind, die gegebenenfalls sogar weiter wachsen.

Wegen des heute noch relativ geringen Erfahrungsstandes gilt der Versuch einer Verteilung der Anwendungen auf mehrere kleinere Systeme als sehr riskant. Eine zweite Gruppe von Anwendern sehr grosser Systeme hat nicht den Einsatz des jeweils groessten Modells einer Rechnerlinie zur Strategie erklaert. In diesen Unternehmen findet eine Umstrukturierung von Teilbereichen oder auch der gesamten betrieblichen Datenverarbeitung statt.

Applikationen, die bisher auf mehreren kleinen, dezentral aufgestellten und organisatorisch unter lokaler Verwaltung betriebenen Systemen abgewickelt worden sind, werden nun auf ein neues Grosssystem verlagert. Die lokalen, dezentralen Minirechenzentren werden ersatzlos aufgeloest.

Ein klassisches Beispiel fuer diese Art von Upsizing gab die amerikanische Telefongesellschaft US West. Sie stellte 1990 den Betrieb von 66 Minirechenzentren ein, in denen Maschinen verschiedener Hersteller zum Teil unter proprietaeren Betriebssystemen, zum Teil unter Unix liefen. Saemtliche Applikationen wurden auf neu installierte Grosssysteme in zwei Rechenzentren verlagert. Der Telefongigant strukturierte zwar nicht die gesamte Unternehmens-DV, aber einen erheblichen Teil voellig um.

Telefonkonzern US West ist ein Upsizing-Pionier

Die US West zieht heute nach einer gut zweijaehrigen Erfahrung mit dieser Loesung eine positive Bilanz. Unter anderem habe man die Kosten stark reduziert, ausserdem habe die Neuorientierung wesentliche organisatorische Verbesserungen und eine erhebliche Reduzierung des Personalaufwands gebracht. Die Massnahme des Unternehmens ist kein Einzelfall.

Es hat sich bereits seit einiger Zeit ein Begriff fuer diese Art der DV-Umstrukturierung eingebuergert, die Data Center Consolidation. Sie wird definiert als die Zusammenfassung mehrerer verteilt aufgestellter Rechenzentren, die entweder organisatorisch dezentral (und unabhaengig) oder von einer zentralen Stelle aus geleitet wurden.

Sowohl in der erstgenannten Upsizing-Kategorie als auch in der zweiten geht die Entwicklung hin zu groesseren Systemen. In der ersten Klasse findet aber lediglich eine Anpassung der Hardware von bereits zentral betriebenen Applikationen an neue, groessere Anlagentypen statt. Hier sollte man von einem "unechten" Upsizing sprechen.

In der zweiten Kategorie dagegen findet zunaechst eine Pruefung der jeweils bestehenden DV-Struktur statt. Erst dann wird die Frage nach einer alternativen, vorteilhafteren Struktur gestellt. Bei diesem "echten" Upsizing wird die DV-Struktur erst dann veraendert, wenn die Ueberzeugung besteht, Vorteile realisieren zu koennen.

Eine Studie, die ein sehr grosses deutsches Unternehmen vor kurzem anfertigen liess, kann als gutes Beispiel dafuer gelten, wie bezueglich Upsizing-Ueberlegungen vorzugehen ist. In dem Unternehmen werden mehr als 200 dezentrale Abteilungsrechner betrieben, die alle relativ leistungsstark sind und von daher bereits im unteren Mainframe-Bereich liegen.

Das Unternehmen hatte die Abteilungsrechenzentren bereits vor Jahren eingerichtet. Dabei wurde keineswegs ein unkontrollierter dezentraler Wildwuchs zugelassen. Im Gegenteil, das Unternehmen hatte eine sehr wohl geordnete Downsizing-Massnahme durchgefuehrt: Die eingesetzten Systeme waren weitgehend einheitlich, es wurden strikt zentral hergestellte und koordinierte Anwendungssoftware- Pakete verwendet, ein effizient durchgefuehrtes Change-Management besteht etc.

Dennoch empfand das Unternehmen die Kostenbelastung als so hoch, dass die Frage nach alternativen Loesungen fuer die Zukunft gestellt wurde. In diesem Zusammenhang kam Upsizing als eine moegliche Variante ins Spiel.

Ausgangspunkt aller Ueberlegungen waren dabei nicht MIPS- Leistungen, Speicherplatzaspekte oder aehnliche Leistungskriterien, sondern allein der Enduser und seine Anforderungen. Ein Mengengeruest der Endbenutzerschaft und deren Serviceanforderungen standen im Mittelpunkt.

Folgende Rechnung wurde aufgestellt: Von der Gesamtmenge der dezentralen Rechenzentren werden zur Zeit 6000 Endbenutzer bedient. Zu diesem Zweck kommen im wesentlichen zwei datenbankgestuetzte Applikationen zum Einsatz. Die Hauptmenge der Transaktionen ist mit mittleren Antwortzeiten von rund einer halben Sekunde (beim Einzelschritt) zu bedienen. Bei einigen Transaktions-Teilschritten (Anteil unter 10 Prozent) sind mittlere Response-Zeiten bis zu fuenf Sekunden zugelassen.

Die einzuhaltenden Servicegrad-Anforderungen wurden im Detail gemaess DIN 66273 beschrieben und normgerecht mit Ausreisserklassen konkretisiert. Ebenso beschrieb das Unternehmen das Zeitverhalten der Endbenutzer nach DIN 66273 und legte somit das Mengengeruest der insgesamt zu bewaeltigenden Auftragsmengen fest.

In einem ersten Schritt untersuchte das Unternehmen dann die Portierbarkeit der dezentralen Anwendungen auf ein zentrales, unter Unix zu betreibendes DV-System. Anschliessend erfolgte die volle Implementierung. Die Portierung erwies sich als machbar, der definitive Aufwand, der nun festgestellt werden konnte, blieb im Rahmen des Erwarteten.

Im naechsten Schritt wurde die Funktionalitaet der Applikationen fuer den tatsaechlichen Rechenbetrieb geprueft. Zu diesem Zweck legten die Projektbeteiligten die Anwendungen samt Datenbanksystemen auf ein grosses Unix-System und unterwarfen sie einem vollen Rechenbetrieb mit einer ausreichend hohen Anzahl aktiver Terminals. Da es kaum moeglich ist, eine solche Menge von Terminals mit menschlichen Benutzern versuchsgerecht zu aktivieren, setzten die Verantwortlichen einen Benutzersimulator ein.

Der Simulator wurde als "voll externer Treiber" auf einem speziellen Rechner realisiert. Das heisst, es wurde nicht etwa nur ein im zu bewertenden DV-System intern ablaufendes Testprogramm verwendet, das nur vorbereitete Jobs anstoesst.

Betrieb mit 100 Benutzern simuliert

Die Mitarbeiter schlossen den Benutzersimulator ueber fast 100 Schnittstellen-Kabel (V.24) an die voll aufgebaute E/A- und Interface-Konfiguration an, womit - aehnlich, wie dies bei TPC- Tests verlangt wird - ein wirklichkeitsgetreuer Betrieb mit (hier fast 100) Benutzern stattfand.

Im dritten Schritt wurde dann eine DV-Leistungsmessung gemaess DIN 66273 vorgenommen. Damit sollte geprueft werden, ob die fuer die zentrale Installation in Erwaegung gezogene Konfiguration tatsaechlich imstande ist, alle 6000 Endbenutzer unter Einhaltung der Servicegrad-Anforderungen gleichzeitig zu bedienen. Das Ergebnis war positiv.

Erst jetzt erfolgte eine Kostenrechnung. Diese beschraenkte sich keineswegs nur auf die Installationskosten der Rechensysteme. Vielmehr wurde eine vergleichende Vollkostenrechnung unter Einbeziehung aller kostenwirksamen Aspekte fuer einen Zeitraum von fuenf Jahren vorgenommen, wobei das bestehende dezentrale System ebenso wie die betrachtete Upsizing-Loesung einbezogen wurden.

Die Rechnung erfasste unter anderem folgende Positionen: Hardware, Steuerabschreibung, Zinsen, Installation der Systeme, Wartung, Strom, Klimatisierung, Raeumlichkeiten, Lizenzen fuer Betriebssysteme und systemnahe Software (inklusive Datenbanken), Applikationssoftware und deren Wartung, Uebertragungskosten fuer das weitverzweigte Datenuebertragungsnetz (Postgebuehren etc.), Netzhardware und -software (einschliesslich Wartung, Steuerabschreibung, Zinsen etc.), Personal fuer Operating und Netzverwaltung, Anwenderbetreuung und Anwendungsadministration, Schulung (unter anderem fuer Operating, Administratoren, Netzverwalter).

Das mit Staunen zur Kenntnis genommene Endergebnis war, dass die Upsizing-Loesung deutlich kostenguenstiger ist und dies, obwohl wegen der geographisch weit verstreuten Endbenutzer das Datenuebertragungsnetz teurer ist als bei der dezentralen Loesung.

Nun koennte man einwenden, dass dieses Ergebnis aus der kostenguenstigen Rechnerhardware der zentralen Unix-Konfiguration resultiere. Dem ist aber nicht so. Da es fuer die in diesem Fall benoetigte Groessenordnung der Anlagenleistung derzeit noch keine erprobten und ausgereiften VLSI-basierten Unix-Systeme gibt, wurde ein Unix-System gewaehlt (UTS), das Prozessoren der 390er Architektur verwendet - also CPUs, die auf dem Preisniveau proprietaerer Mainframe-Systeme liegen. Haetten erprobte VLSI- Prozessoren der benoetigten Leistungsgroesse schon zur Verfuegung gestanden (womit in einiger Zeit zu rechnen ist), dann haette die Kostenrechnung noch einen groesseren Vorteil zugunsten der Upsizing- Loesung ausgewiesen.

Ein weiterer interessanter Aspekt der Aufwandsbetrachtung sei hier erwaehnt: Obwohl ein gut organisiertes und modernes Change- Management fuer die ueber 200 dezentralen Rechenanlagen bestand, war es in der Praxis nicht zu verhindern, dass einige wenige der dezentralen Rechenzentren lokale Varianten fuer die Applikationssoftware durchsetzten. Die Betreiber glaubten, auf lokaler Ebene Kosten einsparen zu koennen und zu muessen.

Es zeigte sich aber, dass die Pflege dieser Sonderloesungen mehr zusaetzlichen Aufwand und Kosten in der Programmierabteilung des Unternehmens verursachte, als in den dezentralen Rechenzentren lokal eingespart wurde. Auch hier konnte die Upsizing-Loesung Pluspunkte bei den anfallenden Kosten verbuchen, da hier nur noch eine einheitliche Applikationssoftware-Version zu pflegen und fortzuentwickeln ist.

Auch bei Upsizing: Unix ist das richtige Betriebssystem

Wenn es, wie Beispiele zeigen, tatsaechlich Kosteneinsparungen nicht nur durch Downsizing, sondern auch durch Upsizing gibt, dann bedeutet dies keineswegs das Revival gewisser ineffizienter Betriebssysteme, die unhandlich und extrem pflegeaufwendig sind und mit denen sich einige DV-Hersteller bisher zum Teil unangemessen hohe Gewinnspannen sicherten. Nicht nur Downsizing, auch Upsizing bedeutet fast immer einen Betriebssystem-Wechsel (hin zu Unix), es sei denn, man besitzt eines der wenigen proprietaeren Ausnahme-Betriebssysteme, die sowohl de facto offen als auch wirklich effizient arbeiten.

Erst unter offenen Betriebssystemen lassen sich die prinzipiellen Vorteile verschiedener DV-Strukturen (verteilt, zentralisiert, mit oder ohne Client-Server-Funktionen) ausschoepfen und nutzen.

Dabei zeigt sich, dass es in Zukunft keineswegs nur die von vielen Planern vorhergesagte Monokultur von dezentral installierten und lokal betriebenen Minicomputern geben wird. Vielmehr wird es unter offenen Systemen kleine wie grosse DV-Installationen geben, die sehr verschiedene Strukturen aufweisen werden.

Die DV wird vergleichbar mit dem Verkehrswesen sein, wo es eine extreme Bandbreite an Fortbewegungsmitteln gibt. Fuer den Personentransport beispielsweise reicht die Palette vom Kleinwagen bis hin zum Hunderte von Personen fassenden Flugzeug. Waere es tatsaechlich besser, billiger und schneller, 300 Personen mit kleinen ein- oder zweisitzigen Flugzeugen von Frankfurt nach Tokyo zu bringen, so gaebe es laengst keine Fluglinien mit 300sitzigen Grossraumflugzeugen mehr.

Die Zeit der Mainframe-Rechner im Sinne der Definition von Gene Amdahl ist also keineswegs vorbei. Vielmehr werden solche Systeme auch in Zukunft benoetigt. Allerdings werden sie raeumlich wesentlich kleiner als die bisherigen "Jumbos der 390-Archi- tektur" sein.

Sie werden eine andere Hardware-Architektur haben, sie werden (bezogen auf gleiche Leistung) wesentlich billiger sein, und sie werden unter Betriebssystemen laufen, die wesentlich moderner und effizienter sind als die von der ueberwiegenden Mehrheit der Mainframe-Anwen-der heute noch verwendeten Betriebssysteme des Industriestandards. Im Moment und auf absehbare Zeit kann Unix diese Rolle bei den Betriebssystemen erfuellen beziehungsweise wird in sie hineinwachsen.