Zusammenfassung

  • Ein kritischer Vorfall traf am 19. August ab 11:10 UTC mehrere Racks und Knoten in MKC1 und wirkte sich zeitweise auf GPU-Dienste, DOKS sowie Cluster-Verwaltung aus.
  • DigitalOcean setzte den Status um 19:34 auf gelöst, nachdem die regionale Steuerungsebene und breite Plattformdienste zurück waren; GPU Droplets blieben laut demselben Abschlussbericht beeinträchtigt.

Bei der Störungsbehebung können Oberfläche und Nutzlast verschiedene Zielgeraden haben. In Kansas City kehrten die regionalen Verwaltungsfunktionen und viele gemeinsam genutzte Dienste zurück, bevor DigitalOcean die Wiederherstellung aller GPU-Knoten bestätigen konnte. Trotzdem endete der öffentliche Vorfall noch am selben Abend.

Er begann um 11:10:06 UTC. DigitalOcean meldete ein Problem an mehreren Racks und Knoten von MKC1. GPU-Workloads könnten unterbrochen werden, Worker-Knoten von DigitalOcean Kubernetes (DOKS) in den Zustand NotReady wechseln. Der Anbieter stufte die Auswirkung als kritisch ein.

Um 12:22 erklärte das Unternehmen, die Ursache identifiziert zu haben und Gegenmaßnahmen umzusetzen. Welche Ursache vorlag, blieb öffentlich offen. Genannt wurden nun GPU-Workloads, Serverless Inference, DOKS-Worker sowie möglicherweise nicht erreichbare Kubernetes-API-Endpunkte und eingeschränkte Cluster-Verwaltung. Um 15:28 liefen die Wiederherstellung der Konnektivität und das Hochfahren betroffener Knoten weiter. Eine Zahl der Racks, Knoten, Cluster oder Kunden veröffentlichte DigitalOcean nicht.

Das Update um 18:59 beschrieb eine klare Teilung. Die regionale Steuerungsebene war vollständig gesund. CPU Droplets, Managed Databases, Load Balancers, Block Storage und Spaces arbeiteten normal. Das Erstellen, Skalieren und Verwalten von Droplets funktionierte wieder; DOKS-Steuerungsebenen waren erreichbar. Damit waren zentrale regionale und administrative Fähigkeiten nachweislich zurück.

Für die beschleunigte Infrastruktur galt das noch nicht. GPU Droplets in MKC1 blieben offline oder unerreichbar. GPU-Worker von DOKS konnten weiterhin NotReady sein, GPU-gestützte Inferenzendpunkte weiterhin ausfallen. DigitalOcean kündigte an, die regionale Steuerungsebene kurz zu beobachten und den Vorfall danach zu schließen. Weitere Informationen für GPU-Kunden sollten individuell über Slack und E-Mail statt über die Statusseite folgen.

Um 19:34:54 wechselte die Einstufung auf resolved. Der Abschlusstext bestätigte erneut den Normalbetrieb der allgemeinen Dienste, hielt aber gleichzeitig fest, dass GPU Droplets weiter beeinträchtigt waren und alle Knoten noch nicht wiederhergestellt waren. Die öffentlich sichtbaren 8 Stunden, 24 Minuten und 48 Sekunden sind folglich ein Verwaltungsfenster mit veränderlichem Umfang. Sie belegen weder einen gleich langen Ausfall aller Produkte noch einen gemeinsamen Rückkehrzeitpunkt aller Kundenressourcen.

Die Region war zu diesem Zeitpunkt 15 Tage alt. DigitalOcean hatte MKC1 am 4. August als vollständig flüssigkeitsgekühltes Rechenzentrum mit NVIDIA-B300-GPUs angekündigt. Zum Start gehörten Rechenleistung, DOKS, Datenbanken, Speicher, Netzwerk, App Platform und Functions. Die Quellen stellen keinen ursächlichen Zusammenhang zwischen Flüssigkühlung, B300 und dem Vorfall her. Sie zeigen aber einen frühen öffentlichen Bewährungstest für die Inbetriebnahme einer Region, deren GPU-Angebot ein wesentlicher Verkaufsfaktor ist.

Die DOKS-Architektur macht die Ebenen sichtbar. DigitalOcean verwaltet die Kubernetes-Steuerungsebene, während Kundenanwendungen auf Workern laufen. Eine erreichbare API ermöglicht Beobachtung und Steuerung, ersetzt aber keine Beschleunigerkapazität auf einem noch NotReady gemeldeten Knoten. DigitalOcean dokumentiert eine automatische Worker-Sanierung. Sie befindet sich jedoch in der öffentlichen Vorschau, ist optional und verlangt konfigurierte Bedingungen, Wartezeiten, Aktionen und Parallelitätsbudgets. Es gibt keinen Beleg, dass betroffene Kunden sie aktiviert hatten.

Auch die Ursache bleibt begrenzt dokumentiert. DigitalOcean sprach von einer identifizierten Ursache und später von Zusammenarbeit mit der Einrichtung, erklärte den Mechanismus aber nicht. Daraus lässt sich weder ein Strom-, Kühlungs-, Netzwerk-, Hardware- noch Softwarefehler ableiten. Es fehlen ferner eine Kundenzahl, der genaue Zeitpunkt vollständiger GPU-Erholung, Aussagen zu Datenverlust oder Workload-Integrität und ein detaillierter Präventionsplan. Ein später grüner Komponentenstatus kann diese historischen Angaben nicht ersetzen.

Für Betreiber zählt deshalb eine Messkette: Ist die Steuerungsebene erreichbar, sind die Worker Ready, lassen sich Beschleuniger zuteilen, antworten Inferenzendpunkte und erreicht die Anwendung ihr Ziel? Am 19. August kamen diese Signale gestaffelt zurück. Die gemeinsame Region erfüllte das öffentliche Schließkriterium, während spezialisierte GPU-Ressourcen in einem separaten, kundenbezogenen Wiederherstellungsprozess verblieben.

Quellen