Zusammenfassung

  • Beim frühen Firehose-1.0-Entwurf konnten zwei bestimmte Uplink-Ausfälle dazu führen, dass Rechner andere Rechner erreichten, einander aber nicht. Dieser Entwurf transportierte nie Produktionsverkehr.
  • Spätere unabhängige Verbindungsblöcke verkleinerten den Wartungsumfang. Gemeinsame Software, Steuerverbindungen und Konfigurationsverfahren blieben mögliche Quellen gekoppelter Risiken.
  • Urs Hölzles dokumentierte Infrastrukturverantwortung und seine Mitautorschaft ordnen ihn in diese Teamleistung ein, ohne ihm jede technische Entscheidung persönlich zuzuschreiben.

Bei einer Wartung zählt nicht nur, welche Geräte aus dem Betrieb genommen werden. Entscheidend ist, welche Beziehungen danach noch funktionieren. Zwei Rechnergruppen können beide erreichbar bleiben und dennoch untereinander keine Verbindung mehr haben. Ein schlichtes Bild von einer abgeschnittenen Insel beschreibt diese Störung nicht.

Die Originalarbeit von der SIGCOMM 2015 schildert einen solchen Fall für Firehose 1.0. Fielen an zwei Top-of-Rack-Switches die jeweils gegenüberliegenden Uplinks innerhalb desselben Reparaturfensters aus, konnten die angeschlossenen Rechner weiterhin andere Rechner erreichen, aber nicht einander. Diese nichttransitive Erreichbarkeit war für Anwendungen schwer zu handhaben.

Das ist kein Bericht über einen heutigen Google-Ausfall. Die Autoren halten fest, dass Firehose 1.0 nie Produktionsverkehr führte. Der Fall dokumentiert einen frühen Entwurf, dessen praktische Probleme die folgenden Systeme mitprägten. Gerade diese Unterscheidung macht die Rückschau brauchbar: Ein gescheiterter Betriebsansatz liefert andere Belege als eine vermessene Störung im laufenden Dienst.

Warum Hölzle hier wichtig ist

Urs Hölzle gehört zur großen Gruppe der Mitautoren. Google Research beschreibt ihn als Google Fellow in Google Cloud und nennt seine frühere Tätigkeit als Senior Vice President for Technical Infrastructure bis 2023. Zu diesem Verantwortungsbereich gehörten Entwurf, Installation und Betrieb der Server, Netze und Rechenzentren hinter Googles Diensten.

Damit führt seine Rolle Architektur und laufenden Betrieb zusammen. Die Verbindung ist wichtig, weil ein Netz nicht nur geplant, sondern verkabelt, mit Arbeit belegt und wiederholt verändert werden muss. Die Quellen verraten allerdings nicht, wer einen einzelnen Mechanismus erfand. Weder der Titel noch die gemeinsame Veröffentlichung rechtfertigen eine Geschichte, in der ein Mann sämtliche Entscheidungen getroffen hat.

Ein Google-Beitrag vom Mai 2013 und Hölzles Netzbeitrag vom März 2020 belegen den damaligen Infrastrukturposten zu konkreten Zeitpunkten. Der zweite Beitrag trennt außerdem Googles Netz von der letzten Meile der Zugangsanbieter. Der Verantwortungsbereich umfasst also nicht jede Abhängigkeit, die ein Nutzer auf dem Weg zu einem Dienst erlebt.

Ausfallschutz verändert den Verkehr

Die technische Rückschau erklärt, warum Rechenzentren breite Verbindungen zwischen Rechnergruppen benötigen. Werden Aufgaben und Speicher über unterschiedliche Stromversorgungs- und Fehlerbereiche verteilt, trifft eine örtliche Störung weniger Arbeit gleichzeitig. Dafür geht räumliche Nähe verloren. Eine Entscheidung zugunsten verteilter Risiken erzeugt somit zusätzlichen Kommunikationsbedarf im Netz.

Mehrstufige Clos-Topologien stellen viele Pfade aus zahlreichen Schaltelementen bereit. So lässt sich ein großes Netz anders bauen als um ein einziges riesiges Chassis. Die Zahl der eingezeichneten Pfade reicht jedoch nicht aus. Firehose 1.0 zeigt, dass bei einer bestimmten Kombination von Fehlern genau die Verbindung verschwinden kann, die eine Anwendung braucht, während große Teile des Netzes erreichbar bleiben.

Bei Firehose 1.1 änderten sich sowohl die Hardware-Unterbringung als auch die Topologie. Dedizierte Gehäuse ersetzten gewöhnliche Server als Träger der Schaltchips. Hinzu kamen ein separates Steuerungsnetz, gepaarte Rack-Switches und eine überarbeitete Aggregationsstruktur. Die Autoren berichten von höherer Robustheit gegenüber Link-Ausfällen. Zugleich blieben Verkabelung und Geräteplatzierung aufwendig. Ein Netz muss auch einen erneuten Anschluss und den Austausch von Komponenten verkraften können.

Ein Viertel der Geräte ist nicht immer ein Viertel der Kapazität

Die spätere Freedom-Architektur liefert ein klares Beispiel für den Wartungsumfang. Eine typische Verbindungsebene bestand aus vier unabhängigen Blöcken. Ein Block konnte vom Verkehr entlastet und aktualisiert werden; die Gesamtkapazität sank dabei um 25 Prozent. Die Intervention musste nicht die ganze Ebene umfassen.

Dieser Wert gehört zu der beschriebenen Anordnung. Er garantiert keiner Anwendung unveränderte Leistung während der Arbeiten. Die verbleibenden Ressourcen müssen die Last aufnehmen können, und die Summe der Kapazität sagt wenig über einzelne belastete Pfade aus.

Eine andere Upgrade-Abbildung derselben Arbeit verteilt die Chassis eines Clos-Netzes auf vier Gruppen. Wird eine Gruppe deaktiviert, bleiben 56,25 Prozent Kapazität, weil sich Einschränkungen über die Stufen hinweg verbinden. Acht Gruppen ermöglichen ein schonenderes, aber längeres Verfahren. Das ist nicht das Freedom-Beispiel mit vier unabhängigen Blöcken.

Wer Wartungsgruppen nur nach Stückzahl festlegt, übersieht diesen Unterschied. Die verbleibende Topologie und die Verkehrsverteilung bestimmen, wie groß eine Änderung betrieblich tatsächlich ist.

Gemeinsame Steuerung trotz getrennter Hardware

Für Firehose, Watchtower und Saturn erläutert die Arbeit Firepath. Das System verteilt eine gemeinsame Sicht auf Topologie und Link-Zustände; die Switches berechnen ihre Weiterleitungstabellen lokal. Es handelt sich um logisch zentralisierte Zustandskoordination, nicht um eine zentrale Entscheidung für jedes Paket. Redundante Steuerinstanzen und ein separates Netz unterstützen das Verfahren. Die Details der Jupiter-Steuerung liegen ausdrücklich außerhalb des Umfangs der Arbeit.

Vor Jupiter lieferte eine begrenzte Zahl von Clusterparametern zudem Materiallisten, Rack- und Kabelpläne, Steuerungsnetzdetails, Überwachungsdaten und gemeinsame Switch-Konfigurationen. Weniger Wahlmöglichkeiten erleichterten wiederholbare Installationen. Damit gewann zugleich die Richtigkeit der gemeinsamen Spezifikation an Bedeutung.

Die Betriebsbeispiele zeigen die Kehrseite. Beim gleichzeitigen Neustart eines ganzen Netzes konkurrierten Erreichbarkeitsprüfungen und Routenberechnung um knappe Switch-CPU-Ressourcen. Alternde interne Links und Steuerverbindungen machten unzureichend überwachte Zustände sichtbar. Während einer BGP-Änderung in Freedom griff ein nicht gesperrter Lesevorgang gleichzeitig auf die Konfiguration zu; eine Teilkonfiguration entstand. Die Autoren schildern die Rücknahme und eine anschließende Härtung der Werkzeuge.

Die Passagen belegen historische Mechanismen, nicht Ausfallhäufigkeiten, Ausfalldauern oder Kundenschäden. Sie erklären aber, warum getrennte Hardware noch keine getrennten Betriebsrisiken schafft. Beobachtung, Softwareübergänge und Konfigurationszugriffe müssen die gewünschte Wartungsgrenze ebenfalls respektieren.

Eine gemeinsame Arbeit mit einer bleibenden Frage

Die SIGCOMM-Veröffentlichung von 2015 und die CACM-Fassung von 2016 sind Versionen derselben Arbeit, keine unabhängigen Wiederholungen. Die Rückschau des Betreibers ist reich an Details, bestätigt aber nicht den heutigen Aufbau aller Rechenzentren.

Hölzles Bedeutung liegt hier in der dokumentierten Verbindung zwischen Infrastrukturführung und einer Teamleistung, die große Netze in begrenzten Teilen veränderbar machte. Die entscheidende Frage bleibt: Was ist beim Herausnehmen eines solchen Teils wirklich unabhängig, und was hängt weiterhin an derselben Änderung oder Störung?

Quellen