Zentral oder verteilt – Hauptsache, verfügbar

Von wegen, früher war alles besser. Ein erster Job des Autors in der Industrie bestand darin, im Rahmen des Aufbaus eines Verwaltungssystems CAD-Workstations von Silicon Graphics mit einem Großrechner aus dem Hause Control Data zu koppeln. Man hatte sich im Jarhr 1989 gegen die Anschaffung von Unix-Servern entschieden und meinte, den Großrechner als Server verwenden zu können, der jedoch kein NFS sprach. Die auf den Workstations benötigten Daten mussten die Anwender zu diesem Zeitpunkt noch über eine Telnet-Sitzung aus dem zentralen Verwaltungssystem auschecken, dann per FTP vom Großrechner herunterkopieren, lokal ändern, anschließend mit FTP erneut hochladen, damit der Großrechner sie abschließend im zentralen Verwaltungssystem versionieren konnte. 

Die Idee, den Großrechner analog zu Unix-Servern mit einem TCP-Service auszustatten und von den Clients bedienen zu lassen, scheiterte an der Komplexität des Großrechnerbetriebsystems NOS/VE. Dies führte zu einem abenteuerlichen Konstrukt, das die Client-/Server-Rolle analog zum X-Windows-Design umkehrte. Alle Sicherheitsaspekte ignorierend wurde der Großrechner in einer Telnet-Session zum TCP-Client und bediente die Unix-Workstation als Server. Immerhin funktionierte diese Konstruktion auch auf dem IBM-Mainframe und den VAXen der Nachbarabteilungen.

Gegen die Widerstände der Großrechnerfraktion entstand das neue Verwaltungssystem vollständig auf Unix-Client-Server-Basis, wie von Sun Microsystems gelernt (siehe Kasten „Sun Microsystems – Das Netz ist der Computer“). Das Design sah eine Dreischichtarchitektur mit Trennung der zentralen Datenbank- und File-Services von der Applikations- und Clientebene vor. Die Hauptlast trugen dabei die Abteilungsserver, in denen ein 64-bittiger Alpha-Prozessor von Digital werkelte und die in einem Ring mit den zentralen Servern zusammengeschaltet waren. Jeder Workstation-Anwender startete nach dem Prinzip „von hinten durch die Brust ins Auge“ eine X11-Anwendung auf dem ihm zugeordneten Abteilungsserver, die wiederum mit kurzer Latenz die zentrale Oracle-Datenbank und den Fileserver kontaktierte. In gewisser Hinsicht beginnt mit dem X11-Protokoll die Virtualisierung der Applikation.

Der 1992 vorgestellte Alpha-Prozessor bildete einen weiteren Meilenstein in der Servergeschichte, wobei sich anfangs das Design der Server nicht wesentlich von dem der Workstations unterschied. Nach dem Vorbild anderer Hersteller ließ man die Grafikkarte weg, packte das Board in ein größeres Gehäuse und nutzte die PCI- und EISA-Slots zur Erweiterung der I/O-Kanäle. Die eigentliche Innovation war die 64-Bit-CPU selbst, zu einer Zeit, als die meisten Mainframes mit einem 32-Bit-Datenbus und 31-Bit-Adressraum werkelten. Die Alpha-CPU erzielte mit passiver Kühlung und einem Takt von 150 MHz aufwärts Rechengeschwindigkeiten, mit denen auch die flottesten 32-Bit-MIPS- und -Power-CPUs nicht mithalten konnten.

Zu schnell für den Benchmark

Bereits der Alpha 21064 ist superskalar und kann zwei Integer-Befehle parallel abarbeiten. Vorteilhaft sind zudem die getrennten Daten- und Instruktionscaches und Mechanismen zur Sprungvorhersage. Trotz der Tatsache, dass keine Byte-Adressierung möglich ist und zur Stringverarbeitung teilweise wüste Maskierungen notwendig sind, explodierten bei Einführung die Benchmarkergebnisse förmlich. Der in der Redaktion beliebte Drystone bedurfte sogar einer Anpassung, damit man überhaupt noch aussagekräftige Messergebnisse erhielt [1, 2]. 1993 legte DEC mit dem Alpha 21064A noch eine High-End-­Variante drauf (siehe Abbildung 2).

Mit dem flächendeckenden Einsatz von Windows-PCs ab 1995 ließ sich die X11-zentrierte Architektur nicht länger durchhalten. Die Idee, das Verwaltungssystem auf eine Zweischichtarchitektur umzustellen und die PCs als Datenbankclient einzusetzen, scheiterte, als die damals hochmoderne Oracle-Forms-Anwendung aufgrund der hohen Latenzen eines entfernten Standorts über 10 Minuten zum Start benötigte, um danach zäh wie Melasse weiterzukriechen. Wir hatten mit dem Design eine der beiden Grenzen aller Netze, Durchsatz und Latenz, verletzt.

Es ist dem Chefredakteur dieser Zeitschrift, Jürgen Seeger, zu verdanken, dass es anders kam. Er steckte dem Autor eine Magnetbandkassette mit dem Quellcode des Mosaic-Browsers und des NCSA-Webservers zu. Binnen weniger Nachtschichten gelang es, das Verwaltungssystem zumindest in Grundzügen auf HTTP und HTML umzustellen, was insbesondere der bereits implementierten Dreischichtarchitektur zu verdanken war. Dank des latenztoleranten HTTP fungierten die Abteilungsserver nun als Webserver und erlaubten bei direkter Datenbankprogrammierung eine bessere Skalierung und höhere Anwenderzahlen als je zuvor.

Auch diese mehrschichtige Client-Server-Architektur erforderte Nachbesserungen, denn kaum ein Anwender war willens, die Adresse seines Abteilungsservers einzutippen. Sie forderten eine feste URL, und zwar 24 Stunden an sieben Tagen von allen Standorten des Konzerns. Der Versuch, dessen mit Redirects Herr zu werden, scheiterten an den von den Anwendern hinterlegten Lesezeichen. Kaum dass ein Abteilungsserver zu Wartungszwecke herunterfuhr, kamen Klagen über dessen Nichtverfügbarkeit. Abhilfe brachte nur der Rücksturz zum großen Blech, in diesem Fall zum 1997 vorgestellten fehlertoleranten Mehrprozessorserver Sun Enterprise 10k (siehe Abbildung 3).

Eigentlich versteckte sich hinter der 1997 vorgestellten E10k eine Cray, doch nach der Übernahme von Cray Research durch Silicon Graphics kaufte Sun Microsystems den Entwurf. Kern des Systems ist ein fehlertoleranter Gigabit-Switch, genannt Centerplane, der bis zu 16 CPU-Boards verbindet. Jedes dieser Boards verfügt über bis zu vier Prozessoren vom Typ Ultra­SPARC II, 4 GByte RAM und vier SBus-I/O-Boards. Ein eigener Computer, der sogenannte Service Prozessor, steuert über zwei Controller-Module auf der Centerplane das System per Ethernet. Dies erlaubt die Partitionierung des Systems in mehrere Domains, auf denen voneinander unabhängige Solaris-Instanzen laufen können. Die E10k war als TCP-Benchmark-Weltmeister das Rückgrat vieler Systeme während der Internet-Blase um die Jahrtausendwende [3].

Restekammer oder Schatzkiste?

Inzwischen ist das Verwaltungssystem in der Restekammer des Unternehmens angekommen, jenen doppelt abgesicherten Räumen, in denen die unternehmenskritischen Anwendungen laufen, die noch nicht migriert sind oder deren Migration sich seit Jahren hinzieht. Hier werkeln Großrechneranwendungen, deren Entwickler verstorben und deren Quellcode verschollen ist, als unverzichtbare Dienste geisterhaft vor sich hin, auf Hardware, die man einmal kauft, dann jahrelang nutzt und stolz darauf ist, monatelang keine Betriebssystem-Patches einspielen zu müssen. Hier finden sich die Überbleibsel des einst so stolzen Unix-Welt, sprich Power-Server von IBM mit AIX, SPARC-Kisten von Oracle und Fujitsu unter Solaris und Intel-Itanium-Bleche mit HP-UX, gleich neben den zum Server mutierten Nachkommen der alten Mainframe-Recken (siehe Kasten „Der Mainframe ist tot, es lebe der Server!“). Allen gemeinsam ist ihre Unverträglichkeit mit der Software aus Redmond.

Im Fall des beschriebenen Verwaltungssystems verteilt ein Switch die Anwender ausfallsicher auf zwei getrennte Netze, hinter denen die Webanwendung gerade so viel Ressourcen zugeteilt bekam, wie sie benötigt. Auf demselben Blech liest und schreibt die Oracle-Datenbank ihre Daten in ein SAN. Zur Absicherung des Katastrophenfalls wartet ein Spiegel der Datenbank im Hot-Stand-by-Modus an einem anderen Unternehmensstandort auf den Herzinfarkt des Hauptsystems.

Cloud oder nicht Cloud?

Würde man eine ähnlich komplexe Applikation heute erneut entwerfen, drängten sich zwei Entscheidungen in den Vordergrund. Erstens: Cloud ja, nein oder teilweise? Zweitens: Einbeziehung lokaler Ressourcen am Rande des Netzwerks, sprich Fat Client, oder Edge Computing – ja oder nein?

Zur Beantwortung dieser Fragen würde man folgende Szenarien auswerten: Wo und mit welchem Endgerät nutzen Anwender das System, wo findet der Großteil der Datenverarbeitung statt und bietet das Netz dazwischen ausreichend Durchsatz bei geringer Latenz? Auf jeden Fall würde hinter der Firewall ein Server einen komplexen Verhau an virtualisierten Diensten bereitstellen. Doch wie weit man die Einzelteile konsolidiert oder verteilt, ist heute nur noch eine Frage der Anforderungen und des Geschmacks.

Start-ups, die keine Unternehmenshistorie zu integrieren haben und sich primär der gängigen Internetstandards wie Karten- und Bezahldienste bedienen, reicht eine Kreditkarte, eine Prime-­Mitgliedschaft beim Bücherversandhandel und ein Laptop mit Internetzugang vollkommen aus. Keine europaweite Ausschreibung, kein klimatisierter Rechnerraum mit Hochsicherheitszugang, kein Personal mit Urlaubsanspruch. Stattdessen ein meterlanger Vertrag, genauso schnell kündbar wie abgeschlossen.

Aus Sicht der Entwickler ist die IaaS eine Ressource, die nie zu enden scheint, solange der Wagniskapitalgeber bürgt. Doch im Grunde versteckt sich dahinter auch nur ein Rechenzentrum mit schnellem Internetzugang und denselben Aufgaben, nämlich möglichst schnell auf die Anforderungen der Applikationslieferanten reagieren zu können. Konkret: Skalierung von Rechenleistung, Massenspeicher und I/O. Auf diese Anforderungen hat die Industrie unterschiedliche Antworten.

Universalblech, wohin man schaut

Der aktuelle Universalserver bietet dem Betriebssystem oder Hypervisor mehrere Kerne einer x86-64-CPU an, denn nur sie kann wahlweise Windows oder Linux bedienen. Der Einschubserver benötigt eine oder zwei Höheneinheiten im19-Zoll-Rack, verfügt vorne über eine Reihe von Einschüben für Hot-Swap-Massenspeicher, dahinter eine Batterie tauschbarer Lüfter. In der Mitte des Stahlblechs flankieren Hauptspeichersockel die Doppelbestückung mit Intels Scalable-Prozessoren der Xeon-Reihe oder AMDs Server-CPUs der EPYC-Serie. Die Rückseite ist geprägt von PCIe-Erweiterungssteckplätzen, Ethernet-Buchsen, Wartungs­adaptern (VGA, Netzwerk, USB) sowie zwei im Betrieb austauschbaren Netzteilen.

Und: Anders als die Server der ersten Generation, die sich im Design kaum von ihren Workstation-Brüdern unterschieden, verfügen die heutigen ausnahmslos über einen Anschluss ans Wartungsnetz. Gerade den Serviceprozessor und seine übergeordnete zentrale Verwaltungssoftware nutzen die Hersteller zur Kundenbindung, denn wer sich für eine Administrationsmethode entschieden hat, wird auch weitere Systeme des Herstellers ordern.