Die Geschichte Ihres VPS: Vom Mainframe zur Cloud

Die Herkunft Ihres VPS

Die Geschichte der Datenverarbeitung vom Mainframe bis zur Cloud ist die Geschichte einer Idee, die immer günstiger wurde. Diese Idee ist Time-Sharing: Viele Personen nutzen gleichzeitig eine teure Maschine, und jede Person erhält eine private Sicht auf sie. Das Konzept entstand um 1960, weil ein Computer mehr kostete als die Personen, die ihn nutzten. Jeder Bestandteil des VPS, den Sie heute mieten, wurde für dieses Problem entwickelt: die Isolation zwischen Benutzern, der Scheduler zur Zuteilung von CPU-Zeit, der Hypervisor und die Abrechnung der Nutzungsstunden. Das Problem ist nie verschwunden. Die Hardware wurde günstiger. Dadurch kostet ein Teil einer Maschine, für den früher ein Forschungszuschuss erforderlich war, heute nur noch wenige Dollar pro Monat.

1959 bis 1961: Warum Time-Sharing erfunden wurde

Ein Computer lief in den 1950er-Jahren im Stapelbetrieb. Sie stanzten Ihr Programm auf Karten, übergaben den Kartenstapel einem Operator und kamen später für einen Ausdruck zurück. Ein falsch eingegebenes Zeichen kostete Sie einen ganzen Tag. Die Maschine blieb ausgelastet. Genau das war der Zweck, denn eine Maschine wie die IBM 7090 kostete Millionen Dollar, während die Wartezeit der Menschen auf keiner Rechnung erschien.

Im Januar 1959 legte John McCarthy in einem Memorandum am MIT den gegenteiligen Standpunkt dar. Die Maschine sollte auf den Menschen warten. Christopher Strachey beschrieb im selben Jahr auf einer UNESCO-Konferenz eine Form von Time-Sharing. Er meinte damit jedoch, dass ein Programmierer Fehler behebt, während andere Jobs ausgeführt werden, und nicht, dass viele Menschen gleichzeitig Eingaben machen. Bei der Hundertjahrfeier des MIT ging McCarthy 1961 noch weiter: Rechenleistung könne als öffentliches Versorgungsangebot verkauft und wie Strom nach Verbrauch abgerechnet werden.

Der damalige Einwand lautete, dass Time-Sharing die Maschine verschwendet. Der Wechsel zwischen Benutzern kostet Rechenzyklen, und Rechenzyklen waren teuer. Der Einwand war berechtigt. Er verlor jedoch an Bedeutung, weil der Preis eines Rechenzyklus sechzig Jahre lang sank, während der Preis für eine Stunde menschlicher Aufmerksamkeit nicht sank.

Was CTSS erfinden musste

Die Gruppe von Fernando Corbató am MIT Computation Center entwickelte das Compatible Time-Sharing System (CTSS), um diesen Streit zu beenden. Im November 1961 wurde es erstmals auf einem IBM 709 vorgeführt. Es bediente vier Benutzer und lagerte die Arbeit jedes Benutzers auf ein eigenes Magnetbandlaufwerk aus. „Compatible“ bedeutete, dass die Maschine weiterhin das alte Stapelsystem im Hintergrund ausführen konnte. Niemand kauft einen Computer, der nur die neue Funktion beherrscht.

Vier Benutzer sind keine große Zahl. Die Liste der Probleme, die dafür gelöst werden mussten, ist dagegen lang. Es ist dieselbe Liste, die Ihr Kernel gerade abarbeitet. CTSS benötigte einen Scheduler, damit ein langer Auftrag nicht jedes andere Terminal blockierte. Es benötigte Speicherschutz, damit ein abstürzendes Programm nur einen Benutzer und nicht das gesamte System beeinträchtigte. Es benötigte einen Speicher, der eine Abmeldung überstand. Deshalb verfügte CTSS über eines der ersten Dateisysteme, die ein moderner Benutzer wiedererkennen würde. Außerdem benötigte es Passwörter, damit ein Benutzer nicht die Dateien eines anderen Benutzers lesen konnte.

Benennt man diese Komponenten um, erhält man eine Linux-Box. Der Scheduler ist EEVDF und hat CFS in Linux 6.6 ersetzt. Den Speicherschutz übernimmt die MMU (memory management unit), die jedem Prozess einen eigenen virtuellen Adressraum zuweist. Der Speicher, der eine Abmeldung übersteht, ist Ihr Home-Verzeichnis. Die Passwortdatei heißt weiterhin /etc/passwd.

Multics und das Computer-Versorgungsunternehmen

Das nächste System des MIT sollte die von McCarthy beschriebene Versorgungsleistung bereitstellen. Project MAC begann 1963, bestellte im August 1964 einen General Electric GE-645 und veröffentlichte 1965 die ersten Multics-Beiträge. Der Name bringt das Konzept zum Ausdruck: Multiplexed Information and Computing Service. Service im Sinne einer Leistung, die man stundenweise kauft.

Multics benötigte erheblich mehr Zeit als geplant. Prototypen der GE-645 erreichten das MIT und Bell Labs im Januar 1967. Bell Labs verließ das Projekt im April 1969. Multics wurde am 1. Oktober 1969 für Kunden des MIT Information Processing Center geöffnet und lief anschließend an irgendeinem Standort einunddreißig Jahre lang im Produktivbetrieb. Das letzte aktive Multics-System beim Canadian Department of National Defence in Halifax, Nova Scotia, wurde am 30. Oktober 2000 abgeschaltet.

Multics wird häufig als Fehlschlag eingeordnet, weil es verspätet eintraf und langsam lief. Die Fachbegriffe sprechen dagegen. Multics brachte uns das hierarchische Dateisystem mit Verzeichnissen in Verzeichnissen, eine Zugriffskontrollliste für jede Datei, segmentierten virtuellen Speicher, mit dem ein Programm eine Datei wie Speicher adressieren konnte, sowie Schutzringe, die Code nach dem Grad seines Vertrauens einstuften. Diese Ringe sind in der Hardware vor Ihnen weiterhin vorhanden. Ring 0 für den Kernel und Ring 3 für Benutzercode stammen aus der Multics-Terminologie. Die Hardware-Virtualisierung fügte später unterhalb von Ring 0 einen Modus für den Hypervisor hinzu, den viele informell als Ring -1 bezeichnen.

Unix: Timesharing auf einer erschwinglichen Maschine

Nachdem Ken Thompson Multics verlassen hatte, stand er bei Bell Labs ohne ein System da, das er verwenden wollte. 1969 begann er auf einem ausgemusterten PDP-7 mit einem wesentlich kleineren System. Das erste Unix Programmer's Manual trägt das Datum November 1971. Zu diesem Zeitpunkt war die Entwicklung bereits auf einen PDP-11 umgezogen. 1973 schrieben Thompson und Dennis Ritchie den Kernel in C neu. Dadurch konnte das System auf neue Hardware portiert werden, ohne es erneut von Hand schreiben zu müssen.

Deshalb geben Sie heute Befehle in einen Unix-Abkömmling ein und nicht in einen Multics-Abkömmling. Multics benötigte speziell für Multics entwickelte Hardware. Unix lief auf der Hardware, die günstig und verfügbar war. Das erwies sich als entscheidender Vorteil.

"The UNIX Time-Sharing System" von Ritchie und Thompson erschien im Juli 1974 in Communications of the ACM. Die Veröffentlichung beschreibt Ihr VPS: Prozesse, ein hierarchisches Dateisystem, Dateien als einfache Byte-Streams, fork, Benutzer und Gruppen mit Berechtigungsbits sowie eine Shell, die ein gewöhnliches Programm und kein Bestandteil des Kernels ist. Fünfundfünfzig Jahre später wurde diese Schnittstelle erweitert, aber nie ersetzt.

Sind auf Mainframes 1972 wirklich virtuelle Maschinen gelaufen?

Ja. Das ist der Teil der Geschichte, den die meisten übersehen. Während MIT Multics entwickelte, verfolgte das Cambridge Scientific Center von IBM dasselbe Ziel vom anderen Ende aus. Statt eines Betriebssystems, das viele Benutzer versorgte, entwickelten Robert Creasy und Les Comeau ein Steuerprogramm, das jedem Benutzer einen vollständig simulierten Computer bereitstellte. CP-40 ging im Januar 1967 in den Produktivbetrieb. Jeder Benutzer erhielt einen virtuellen System/360 und führte darin ein kleines Einzelbenutzerbetriebssystem namens CMS aus.

CP-40 wurde 1968 auf dem System/360-67 zu CP-67, und IBM kündigte VM/370 am 2. August 1972 an. Das war ein kommerzieller Hypervisor, der zahlenden Kunden angeboten wurde, vor vierundfünfzig Jahren. Ein Steuerprogramm teilte die reale Hardware mehreren Nutzern zu. Gastbetriebssysteme liefen unverändert in virtuellen Maschinen und gingen davon aus, dass sie die Hardware selbst besaßen.

Die Theorie folgte zwei Jahre später, in derselben Ausgabe von Communications of the ACM vom Juli 1974, die auch den Unix-Artikel enthielt. Gerald Popek und Robert Goldberg beschrieben in „Formal Requirements for Virtualizable Third Generation Architectures“, welche Eigenschaften ein Prozessor für die Virtualisierung benötigt. Die zentrale Regel ist kurz. Jede Anweisung, die den Zustand der Maschine lesen oder ändern kann, muss einen Trap auslösen, wenn ein Gast sie außerhalb des Kernel-Modus ausführt. Dadurch übernimmt der Hypervisor die Kontrolle und liefert die private, für diesen Gast gültige Version des Zustands zurück. Dieses Verfahren heißt Trap-and-Emulate. Die Hardware von IBM erfüllte diese Regel.

Warum der Minicomputer das Modell aufbrach

DEC stellte den PDP-8 am 22. März 1965 für etwa 18.000 $ in Dollar des Jahres 1965 vor. Er war der erste Minicomputer mit einem Preis unter 20.000 $ und wurde später mehr als 50.000-mal verkauft. Der Mikroprozessor senkte den Preis anschließend erneut. Sobald ein Fachbereich eine eigene Maschine kaufen konnte und später auch einzelne Personen dazu in der Lage waren, erschien die gemeinsame Nutzung eines zentralen Computers als gelöstes Problem, das nicht mehr gelöst werden musste. In den 1980er- und 1990er-Jahren verlagerte sich die Datenverarbeitung auf Schreibtische und in Racks mit kleinen x86-Servern.

Die Verschwendung kehrte in anderer Form zurück. Eine Anwendung pro Server ist einfach zu verwalten. Gleichzeitig bleibt der größte Teil der Hardware ungenutzt, während Strom und Rack-Fläche vollständig bezahlt werden. Das war erneut das CTSS-Problem, diesmal in einem anderen Maßstab. Die knappe und teure Ressource war nun der Raum und die Energie statt des Prozessors. Die Antwort war dieselbe wie zuvor: die Maschine gemeinsam nutzen.

Warum war x86 so schwer zu virtualisieren?

Weil x86 die Regel von Popek und Goldberg verletzte. Beim 9th USENIX Security Symposium im August 2000 untersuchten John Scott Robin und Cynthia Irvine den Pentium-Befehlssatz. Sie fanden siebzehn Befehle, die privilegierten Zustand lesen oder ändern, ohne einen Fehler auszulösen, wenn User-Mode-Code sie ausführt. popf ist das Standardbeispiel. Wird der Befehl im User Mode ausgeführt, ignoriert der Prozessor stillschweigend die Bits, die das Programm nicht setzen darf, statt einen Trap auszulösen. Ein Hypervisor, der auf Trap-and-Emulate basiert, erfährt dadurch nicht, dass der Gast diesen Befehl auszuführen versucht hat.

Bevor die Hardware korrigiert wurde, entstanden zwei Lösungen. VMware, 1998 aus der Stanford-Disco-Forschung hervorgegangen, untersuchte den Kernel-Code des Gasts und schrieb die problematischen Befehle um, bevor sie ausgeführt wurden. Diese Technik wird Binary Translation genannt. Xen, das aus dem University of Cambridge Computer Laboratory stammt, änderte stattdessen den Gast. Das Paper „Xen and the Art of Virtualization“, das im Oktober 2003 auf der SOSP vorgestellt wurde, beschrieb die Paravirtualisierung: Ein modifizierter Gastkernel ruft den Hypervisor absichtlich auf, statt Befehle auszuführen, die der Hypervisor nicht abfangen kann.

Dann wurde die Hardware korrigiert, so wie IBM dies bereits in den 1960er-Jahren getan hatte. Intel brachte VT-x am 14. November 2005 in zwei Pentium-4-Modellen auf den Markt. AMD brachte AMD-V im Mai 2006 auf den Markt. Beide Technologien fügen unterhalb des Gastkernels einen Prozessormodus hinzu. Dadurch läuft der Gastkernel mit voller Geschwindigkeit, während der Hypervisor die Kontrolle über die angeforderten Ereignisse behält. Das machte einen Hypervisor möglich, der klein genug war, um in einem gewöhnlichen Betriebssystem zu laufen. Avi Kivitys KVM bei Qumranet tat genau das: Es machte den Linux-Kernel selbst zum Hypervisor. KVM wurde in Linux 2.6.20 aufgenommen, das im Februar 2007 veröffentlicht wurde. Heute läuft ein großer Teil der VPS-Hosts damit.

Der Ursprung der Bezeichnung VPS

Anfang der 2000er-Jahre liefen zwei Entwicklungen zusammen. Die eine war die vollständige virtuelle Maschine auf x86, bei der ein Gast sein eigenes Kernel startet. Die andere war die Virtualisierung auf Betriebssystemebene: Ein gemeinsames Linux-Kernel wird in getrennte Umgebungen aufgeteilt, die jeweils über einen eigenen root-Benutzer und eine eigene Prozesstabelle verfügen. Linux-VServer und Virtuozzo von SWsoft erschienen beide 2001. SWsoft veröffentlichte 2005 einen Teil von Virtuozzo als Open-Source-Projekt unter dem Namen OpenVZ. Die Bezeichnung „virtual private server“ stammt aus diesem Umfeld. Sie wurde in Anlehnung an „virtual private network“ gebildet.

Amazon machte aus der Anmietung einen API-Aufruf. S3 startete am 14. März 2006. EC2 wurde am 25. August 2006 als begrenzte öffentliche Betaversion freigegeben, zunächst mit einem einzigen Instanztyp auf Xen. Rechenleistung zu kaufen war damit kein Vertrag mit einem Dienstleister mehr. Stattdessen wurde eine Anfrage gestellt, deren Ergebnis innerhalb einer Minute verfügbar war.

Beide Entwicklungslinien bestehen bis heute. Die daraus entstandene Unterscheidung bestimmt weiterhin, was Sie mit dem gemieteten Server tun können. Ein KVM-VPS startet sein eigenes Kernel. Sie können daher Kernel-Module laden und sogar einen Hypervisor in Ihrem VPS ausführen. Ein containerbasierter Tarif verwendet das Kernel des Hosts gemeinsam mit anderen Umgebungen und kann dies nicht. Hinter dieser einen Zeile auf einer Preisseite stehen sechzig Jahre Geschichte. Deshalb sollten Sie verstehen, wie sich ein VPS, eine VM und eine VPC unterscheiden, bevor Sie sich für eine Variante entscheiden.

Was sich vom Mainframe zu Ihrem VPS geändert hat – und was nicht

Vier Dinge haben sich geändert. Die Maschine steht nicht in Ihrem Gebäude. Das Terminal ist ein Programm und kein Möbelstück. Die Einheit, die Sie mieten, ist ein vollständiger Computer mit eigenem Kernel und kein Konto auf dem Betriebssystem eines anderen. Und der Preis ist so weit gefallen, dass der Kauf per Kartenzahlung erfolgt und kein Beschaffungsprozess mehr nötig ist.

Der Mechanismus hat sich überhaupt nicht geändert.

• Ihre ssh-Sitzung ist ein Timesharing-Terminal. Sie erhalten ein Login und eine Shell, und ein Scheduler entscheidet, wann Ihr Prozess als Nächstes ausgeführt wird.
• Die Isolation wird weiterhin durch Hardware erzwungen. Die MMU und die Privilegstufen des Prozessors übernehmen diese Aufgabe, genau wie sie 1967 für CP-40 erforderlich waren.
• Sie zahlen weiterhin zeitabhängig für einen Anteil an einer Maschine, so wie Servicebüros nach Verbindungsstunden abrechneten.
• Sie bekommen weiterhin die anderen Mandanten zu spüren. Wenn ein Host überbucht ist, wartet Ihr Gast auf eine physische CPU, und Linux meldet diese Wartezeit als CPU-Steal-Time durch einen lauten Nachbarn.

Dieser letzte Punkt ist die ehrliche Zusammenfassung der gesamten Geschichte. Die gemeinsame Nutzung einer Maschine ist ein Abwägen. Sie wurde 1961 akzeptiert, weil der Computer mehr kostete als die Menschen, und sie wird 2026 akzeptiert, weil ein Server, der mit zehn Prozent seiner Kapazität läuft, verbranntes Geld bedeutet. Wenn Sie lieber auf der Betreiberseite dieses Abwägens stehen möchten, erhalten Sie mit Proxmox auf eigener Hardware zugleich den Hypervisor und die Probleme des Betreibers.

Behalten Sie das Verhältnis im Blick. CTSS versorgte vier Benutzer auf einer Maschine, die in Dollar des Jahres 1961 mehrere Millionen kostete und einen ganzen Raum ausfüllte. Ihr VPS ist 2026 für wenige Dollar im Monat ein weitaus besserer Computer als der, den Corbatós Team rationieren musste, und Sie haben ihn für sich allein. Mieten können Sie ihn überhaupt nur aufgrund einer fünfundsechzig Jahre alten Idee, die schließlich auf günstige Hardware traf. Wenn Sie überlegen, was Sie darauf betreiben möchten, beginnen Sie mit dem, was ein VPS tatsächlich bereitstellt, und lesen Sie anschließend was andere darauf betreiben.

FAQ

Was war das erste Computersystem mit Time-Sharing?

CTSS, das Compatible Time-Sharing System, wurde von der Gruppe um Fernando Corbató am MIT Computation Center entwickelt. Es wurde im November 1961 erstmals auf einem IBM 709 vorgeführt und bediente vier Benutzer, die jeweils auf ein eigenes Bandlaufwerk ausgelagert wurden. Der erste Time-Sharing-Dienst für eine ganze Gemeinschaft war das Dartmouth Time-Sharing System: Am 1. Mai 1964 führten John Kemeny und ein studentischer Programmierer gleichzeitig BASIC-Programme auf zwei Terminals aus und erhielten beide korrekte Ergebnisse.

Wurden virtuelle Maschinen tatsächlich in den 1960er-Jahren erfunden?

Ja. Das Cambridge Scientific Center von IBM nahm CP-40 im Januar 1967 produktiv in Betrieb. Dadurch erhielt jeder Benutzer ein vollständiges virtuelles System/360, in dem das Betriebssystem CMS ausgeführt wurde. 1968 folgte CP-67 auf dem System/360-67. Am 2. August 1972 kündigte IBM VM/370 an. Dabei handelte es sich um echte Hypervisoren, die unveränderte Gastbetriebssysteme ausführten und kommerziell vertrieben wurden. Das geschah Jahrzehnte bevor x86-Hardware dasselbe leisten konnte.

Warum ließ sich x86 nur schwer virtualisieren, Mainframes dagegen nicht?

Die Regel von Popek und Goldberg aus dem Jahr 1974 besagt, dass jede Instruktion, die den Maschinenzustand lesen oder ändern kann, einen Trap auslösen muss, wenn ein Gast sie außerhalb des Kernel-Modus ausführt. x86 verletzte diese Regel. Robin und Irvine zählten siebzehn Pentium-Instruktionen, die im Benutzermodus still fehlschlagen, statt einen Trap auszulösen. Ein klassischer Hypervisor mit Trap-and-Emulate-Verfahren erkennt sie daher nicht. popf ist das übliche Beispiel. VMware umging dieses Problem mit Binary Translation und Xen mit Paravirtualisierung. Erst Intel VT-x im November 2005 und AMD-V im Mai 2006 führten einen Hardwaremodus für den Hypervisor ein.

Ist das Mieten eines VPS dasselbe wie ein Time-Sharing-Konto?

Das Abrechnungsmodell und das Isolationsproblem sind gleich. Die Einheit ist unterschiedlich. Ein Time-Sharing-Benutzer hatte ein Konto auf einem Betriebssystem, das er mit allen anderen teilte. Der Administrator war daher jemand im Rechenzentrum. Ein KVM-VPS stellt Ihnen eine virtuelle Maschine mit einem eigenen Kernel und einem eigenen root-Konto bereit. Der Administrator sind daher Sie selbst. Ein containerbasierter VPS liegt zwischen diesen beiden Modellen, weil er den Kernel des Hosts gemeinsam nutzt und Ihnen trotzdem root innerhalb Ihrer eigenen Umgebung gibt.