Zusammenfassung

  • Ein PlanetLab-Slice war kein verteilter Besitzstand, sondern eine zusammengesetzte Nutzungserlaubnis: Auf jedem Knoten stellte ein Sliver einen begrenzten Anteil lokaler Ressourcen bereit.
  • Die globale Koordination konnte Dienste benennen und ausrollen, doch der Node Manager, die Auslastung und die Regeln der gastgebenden Organisation entschieden, ob ein lokaler Anteil tatsächlich existierte.
  • Experimentierfreiheit beruhte auf Isolation, Ressourcenabrechnung und einer Verantwortlichkeitskette. Ohne Zuordnung eines extern sichtbaren Vorgangs zu einem Nutzer wäre der Slice politisch und betrieblich nicht tragfähig gewesen.

Eine gemeinsame Adresse war noch kein gemeinsamer Besitz

Wer zu Beginn der 2000er Jahre einen neuartigen Internetdienst unter realen Bedingungen erproben wollte, musste häufig zuerst ein Netz persönlicher Gefälligkeiten aufbauen. Hier ein Zugang zu einem Universitätsserver, dort ein Rechner im Labor eines Kollegen: Das reichte für eine Vorführung, aber kaum für einen belastbaren Versuch über lange Pfade, wechselnde Last und unterschiedliche Betriebsregeln hinweg.

PlanetLab verwandelte diese improvisierte Praxis in eine gemeinsame Versuchsinfrastruktur. Ein Forschungsteam erhielt einen Zugang, der viele Standorte umfasste, und konnte seinen Dienst auf einer verteilten Menge von Maschinen betreiben. Das daraus gebildete Objekt hieß Slice.

Der Begriff darf nicht mit einem Stück Eigentum verwechselt werden. Die NSDI-Arbeit von 2004 beschrieb den Slice als Menge virtueller Maschinen, von denen jede einen Anteil an den Ressourcen eines teilnehmenden Knotens nutzte. Für den Dienst sah diese Menge wie ein privates, weltweit verteiltes System aus. Die Autoren bezeichneten diese Privatheit jedoch ausdrücklich als eine durch Isolation erzeugte Illusion. Der physische Server blieb beim jeweiligen Standort, das Campusnetz blieb unter lokaler Verantwortung, und ein globales Konto verwandelte einen Beitrag nicht in zentrales Vermögen.

Die Abstraktion war gerade deshalb wirkungsvoll. Software ließ sich über den Slice hinweg installieren und verwalten, ohne dass jedes Experiment seine eigene Hardwareflotte beschaffen musste. Doch hinter dem einen Namen lagen viele einzeln begrenzte Erlaubnisse.

Der Sliver war die lokale Tatsache

PlanetLabs Wortschatz hielt diese Grenze sichtbar. Der lokale Anteil einer virtuellen Maschine an CPU, Speicher, Platte und Netzwerk hieß Sliver. Erst die Verbindung vieler solcher Sliver ergab den Slice.

Oberhalb dieser Basis blieb viel offen. Die Plattform schrieb weder eine einzige Overlay-Topologie noch eine Programmiersprache oder Laufzeit vor. Ein Team konnte seine verteilte Architektur selbst wählen. Diese Freiheit endete dort, wo eine Behauptung über den Dienst auf eine knappe lokale Ressource traf. Ein Slice konnte keinen CPU-Zyklus auf einem ausgelasteten Host erfinden, keinen ausgeschalteten Knoten aufwecken und sich keine privilegierten Rechte auf einer gemeinsam genutzten Maschine verleihen.

Ein frühes Architekturpapier machte die Trennung mit Tickets und Leases anschaulich. Ein Ticket benannte Knoten, Ressourcenmenge und Zeitfenster; daraus konnte eine Lease entstehen, sofern die lokale Zulassung sie akzeptierte. Das Papier war als fortlaufender Entwurf gekennzeichnet und ist daher keine unveränderliche Beschreibung jeder späteren PlanetLab-Version. Als Verfassungsmodell ist es dennoch präzise: Eine globale Stelle konnte einen Anspruch bis an die Tür tragen. Öffnen musste der Knoten selbst.

PlanetLab Central setzte zusammen; der Standort durfte ablehnen

PlanetLab war kein System ohne Zentrum. In der anfänglichen Architektur kontaktierte PlanetLab Central die Node Manager der ausgewählten Rechner. Diese lokalen Komponenten erzeugten und kontrollierten die virtuellen Maschinen. Auch das Bootstrapping brauchte privilegierten Code; ersetzbare Dienste konnten nicht aus einem endlosen Kreis weiterer Dienste entstehen.

Zugleich gehörten die Knoten autonomen Universitäten, Forschungslaboren und anderen Organisationen. Der Erfahrungsbericht von 2006 behandelte ihre fortdauernde Kontrolle nicht als lästige Ausnahme, sondern als Voraussetzung für Wachstum: Wer Ressourcen beisteuerte, musste beeinflussen können, wie sie verwendet wurden, während der zentrale Eingriff möglichst klein blieb.

Jeder neue Sliver überschritt deshalb eine Autoritätsgrenze. Die globale Datenbank konnte vorsehen, dass ein Dienst in Princeton, Berkeley oder an einem anderen Ort laufen sollte. Ob er dort wirklich lief, entschieden der lokale Zustand, der Node Manager, der Scheduler und die Regeln des Standorts. Ein veralteter Eintrag konnte freie Kapazität nicht herbeischreiben. Der Datensatz beschrieb die Absicht; der laufende Prozess belegte die gegenwärtige Wirklichkeit.

Isolation bestand aus mehreren, nicht austauschbaren Zusagen

Unter dem Wort Isolation lagen verschiedene Aufgaben. Ressourcenisolation sollte verhindern, dass ein Dienst CPU, Speicher, Festplatte oder Bandbreite seiner Nachbarn übermäßig beeinträchtigte. Sicherheitsisolation trennte Namensräume und Daten. Eine stabile lokale Basis verhinderte, dass ein unprivilegierter Slice die Mechanismen unter anderen Slices veränderte.

Keine dieser Eigenschaften garantierte automatisch die andere. Ein Dienst konnte sicher getrennt sein und dennoch auf einem belasteten Knoten stark schwankende Latenz erleben. Ein fairer CPU-Anteil war keine Reservierung. Ein im eigenen virtuellen Umfeld korrektes Programm konnte durch eine lokale Bandbreitenobergrenze ein anderes Messergebnis liefern.

Die Betriebspapiere räumten diese Lücke offen ein. Anfangs erschien Best Effort ausreichend; mit hoher Last und volatiler Leistung wurde diese Annahme teuer. PlanetLab führte faire Aufteilung, ausdrückliche Reservierungen und tokenbasierte Planung ein. Bei Speicherdruck konnte ein Watchdog einen großen Verbraucher zurücksetzen, und Standorte konnten den ausgehenden Verkehr begrenzen.

Eine Messung aus dem Jahr 2006 zeigt die Bedeutung, ohne einen allgemeinen Leistungswert zu behaupten: Auf einem zugrunde liegenden Pfad von 74 Millisekunden lagen Overlay-Rundlaufzeiten zunächst zwischen 76 und 135 Millisekunden. Bevorzugte CPU-Behandlung und Echtzeitplanung verringerten den größten Teil der Abweichung, beseitigten aber nicht jede Aktivität des Kernels und jede Schwankung. Ein weltweit benannter Slice war noch lange keine weltweit dedizierte Maschine.

Verantwortlichkeit ermöglichte großzügige Delegation

PlanetLab-Nutzer sendeten Verkehr aus Institutionen, denen sie nicht angehörten, an Netze, die dem Experiment nicht zugestimmt hatten. Eine Kartierung konnte einen Einbruchsalarm auslösen; ein Durchsatzversuch konnte die Verbindung eines Campus belasten. Wissenschaftliche Absicht hob diese externen Kosten nicht auf.

Die Arbeit von 2004 verlangte deshalb nicht nur Mengenabrechnung, sondern die nachträgliche Zuordnung von Handlungen zu Slices. Das spätere Papier zu den Entwurfsprinzipien formulierte daraus eine „chain of responsibility“: Eine nach außen sichtbare Aktivität musste über den Slice bis zum verantwortlichen Nutzer zurückgeführt werden können.

Diese Kette ersparte einem Standort eine eigene Vertrauensbeziehung zu jedem Forscher. Er brauchte stattdessen durchsetzbare Grenzen, einen identifizierbaren Principal und eine Stelle, die auf Beschwerden reagieren konnte. Der Slice war somit nicht nur ein Freiheitsraum, sondern auch ein Beweisraum.

Riss die Kette, blieb der Prozess vielleicht technisch isoliert, während die Institution mit dem Schaden allein war. Ein Paket verließ weiterhin den Knoten; nicht mehr feststellbar war jedoch, welcher Dienst es unter welcher Ressourcenzusage und in welchem Zeitfenster gesendet hatte. Das ist der Punkt, an dem Virtualisierung ohne Verantwortlichkeit die Teilnahmebereitschaft zerstört.

Entbündelte Verwaltung verkleinerte den einzigartigen Kern

PlanetLabs zweiter entscheidender Schritt bestand darin, lokale Mechanismen von netzweiten Verwaltungsdiensten zu trennen. Slice-Erzeugung, Ressourcensuche, Überwachung und Softwareverteilung konnten als Dienste oberhalb des Knotenbetriebssystems entstehen. Mehrere Varianten durften nebeneinander wachsen, statt einer einzigen Anwendung dauerhafte Sonderrechte zu geben.

Das Betriebssystem sollte vor allem lokale Abstraktionen und klar teilbare Schnittstellen anbieten. Globale Abstraktionen wurden daraus zusammengesetzt. Dadurch schrumpfte die Menge der Funktionen, die als einmalig und privilegiert gelten mussten.

Ganz verschwand der Kern nicht. Irgendetwas musste den lokalen virtuellen Rechner erzeugen, Grenzen durchsetzen und den ersten Dienst starten. Die Autoren benannten diese Grenze. Der Fortschritt lag nicht in herrschaftsfreier Infrastruktur, sondern in einer kleineren, überprüfbaren Autoritätsfläche.

Hier lässt sich eine heutige Verbindung zu Heng Lus Gedanken der minimalen Anfangsspezifikation und des Vorrangs laufenden Codes ziehen. Eine gemeinsame Schicht sollte nur die lokalen Invarianten festschreiben, die sichere Zusammensetzung erlauben. Höhere Dienste dürfen wechseln; ihr globaler Datensatz kann keine lokale Kapazität erzeugen und ihr Name keinen Eigentumstitel ersetzen. Das ist eine redaktionelle Lesart, keine Behauptung über die damaligen Motive der PlanetLab-Autoren.

PlanetLab nahm die Cloud vorweg, ohne ihre Geschichte zu besitzen

Princetons Rückblick von 2026 beziffert den Höhepunkt auf 1.353 Knoten an 717 Standorten in 48 Ländern; 2020 wurde PlanetLab offiziell beendet. Petersons eigene vorsichtige Formel ist hilfreicher als eine Ursprungslegende: PlanetLab erfand die Cloud nicht, nahm sie aber vorweg.

Es zeigte eine Welt, in der Nutzer eine abstrakte Ressource anfordern, Software auf entfernte Maschinen bringen und physische Kapazität mit anderen Mietern teilen. Zugleich legte es die Fragen frei, die eine glatte Cloud-Konsole leicht verdeckt: Welcher Standort gab die Ressource? Welche Leistungsklasse galt? Wer durfte ablehnen oder zurücksetzen? Wer antwortete, wenn der Verkehr Dritte traf?

PlanetLab war nicht der alleinige Ursprung von virtuellen Maschinen, Containern, CDNs oder Orchestrierung. Sein besonderer Beitrag lag darin, eine globale Ressourcenabstraktion öffentlich, unter ungleichmäßiger Last und über autonome Eigentümer hinweg zu betreiben. Das Projekt endete; die Pflicht, lokale Zusagen unter einem globalen Objekt sichtbar zu halten, blieb.

Larry Petersons Rolle war zentral und gemeinschaftlich

Larry Peterson war Organisator, Architekt und Betreiber von PlanetLab; Princeton führt ihn heute als Robert E. Kahn Professor, Emeritus und Senior Research Scholar. Allein erfand er das System nicht.

Den Blueprint von 2002 schrieb er mit Tom Anderson, David Culler und Timothy Roscoe. Die Systemarbeit von 2004 nennt Andy Bavier, Mic Bowman, Brent Chun, David Culler, Scott Karlin, Steve Muir, Peterson, Roscoe, Tammo Spalink und Mike Wawrzoniak. Der Erfahrungsbericht von 2006 stammt von Peterson, Bavier, Marc E. Fiuczynski und Muir. Das Papier zur dynamischen Slice-Erzeugung war ein Dokument des Architecture Team, herausgegeben von Peterson und Amin Vahdat und ergänzt um weitere namentlich genannte Beiträge.

Diese Zuschreibung ist Teil der Sache. PlanetLab untersuchte, wie unabhängige Institutionen ein System teilen können, ohne einen einzigen Eigentümer vorzutäuschen. Seine Entstehung sollte nicht durch eine Einzelerzählung genau das Gegenteil behaupten.

Quellen