DigitalOcean erklärt die MicroVM-Architektur hinter Managed Agents

Warum Agenten eine andere Grundlage brauchen

DigitalOcean beschreibt eine typische Agenten-Arbeitslast: Der Agent startet eine Test-Suite, bearbeitet eine Datei, ruft ein Modell auf und wartet. Später setzt er mit denselben Prozessen, Dateien und demselben Kontext fort. Manchmal muss er die Umgebung forken, um zwei Ansätze parallel auszuprobieren.

Herkömmliche Infrastruktur zwinge hier zu einem Kompromiss, so das Unternehmen. Eine Maschine, die weiterläuft, lässt inaktive Sitzungen Ressourcen belegen. Eine Maschine, die zerstört wird, muss ihre Umgebung bei der nächsten Interaktion neu aufbauen. Das Speichern des Dateisystems helfe zwar, bewahre aber weder einen laufenden Interpreter noch einen In-Memory-Index oder einen Prozess auf, der mitten in einer Aufgabe steckt.

Deshalb gibt die Harness Runtime jeder Sitzung eine Firecracker-MicroVM. Die darunterliegende MicroVM-Plattform verwaltet Isolation, Netzwerk, Speicher und die Checkpoint-Wiederherstellung, während Action Gateway kontrollierten Zugriff auf Tools ergänzt. Firecracker nutzt die KVM-Hardwarevirtualisierung, sodass jeder Gast einen eigenen Kernel hat, statt wie ein Container den Host-Kernel zu teilen. Network Namespaces ergänzen diese VM-Grenze, ersetzen sie aber nicht.

Die zentrale Designentscheidung ist, eine Sitzung von ihrem Host zu entkoppeln. Ein Gast behält eine stabile Netzwerkkonfiguration, und unveränderlicher Speicher hält seine per Checkpoint gesicherte Disk und seinen Arbeitsspeicher. Host-seitige Proxys setzen Netzwerkrichtlinien durch und können Zugangsdaten anhängen, ohne sie in die Gastumgebung zu legen.

Cells, Control Plane und Host Plane

Die Plattform ist in Cells gegliedert. Eine Cell ist eine in sich geschlossene, auf eine Region begrenzte Instanz der MicroVM-Plattform mit eigener VPC, eigenem DigitalOcean-Kubernetes-Cluster, eigener verwalteter PostgreSQL-Datenbank, eigenem Spaces-Bucket und einem Pool aus Hypervisor-Hosts. Eine Region kann viele Cells nebeneinander betreiben, und die Kapazität wächst, indem man einer Cell Hosts hinzufügt oder eine weitere Cell anlegt.

Laut DigitalOcean führt ein Datenbank- oder Routingausfall innerhalb einer Cell nicht dazu, dass andere Cells ihn teilen müssen. Zugleich betont das Unternehmen, dass Cells weiterhin von gemeinsamen regionalen und plattformweiten Diensten abhängen. Eine Cell begrenzt also den Schadensradius, beseitigt gemeinsame Abhängigkeiten aber nicht.

Jede Cell besteht aus zwei Teilen:

• Die Control Plane verantwortet Lebenszyklusentscheidungen, Platzierung und dauerhafte Metadaten und läuft auf Kubernetes.
• Die Host Plane führt Firecracker sowie die Dienste für Gastnetzwerk, Disks und Arbeitsspeicher aus und läuft auf Hypervisor-Droplets.

PostgreSQL enthält MicroVM-Definitionen, Ausführungszustand, Routing- und Lease-Informationen, Anfrageaktivität und Checkpoint-Metadaten. Spaces hält die großen Disk- und Speicher-Artefakte, sodass die Snapshot-Größe nicht zur Größe von Datenbanktransaktionen wird. Der Activator ermittelt die Platzierung aus einer kompakten Routing-Ansicht, der Controller koordiniert Erstellung, Pausieren, Fortsetzen und Platzierung, und Temporal-Worker übernehmen längere Vorgänge wie die Vorbereitung von Templates und die Verwaltung der Host-Flotte. Auf jedem Host setzt microvm-d diese Entscheidungen in Firecracker-Prozesse und lokale Ressourcen um.

Das Unternehmen setzt die drei Rollen des Activators getrennt ein: Dataplane-Replikate skalieren mit den Anfragen, Lifecycle-Replikate kümmern sich um Host-Heartbeats und Abgleich, und die Execution-Rolle läuft neben dem Controller. Ein Grund dafür ist, dass ein Controller-Rollout die HTTP-Dataplane nicht neu starten und laufende Anfragen wie WebSocket oder SSE nicht unterbrechen soll.

Produktions-Cells nutzen DigitalOcean Managed PostgreSQL Advanced Edition. Der Anwendungsverkehr läuft über einen PgBouncer-Pool im Transaktionsmodus, während Schema-Migrationen eine separate direkte Verbindung verwenden. Laut Unternehmen leitet der Connection Pooler sich neu verbindende Clients nach einem Failover an den neuen Primary weiter, ohne auf DNS-Änderungen zu warten. Anwendungen müssen unterbrochene Transaktionen jedoch weiterhin selbst behandeln.

Wie Anfragen den Gast erreichen

Eingehender Verkehr muss eine bestimmte Ausführung finden und sie gegebenenfalls zuvor wecken, während ausgehender Verkehr die Netzwerkrichtlinie dieser Ausführung einhalten muss. Für HTTP-Ingress stellt DigitalOcean Edge die Routing-Schicht bereit. Der MicroVM-Controller veröffentlicht Routen, die Authentifizierungs- und Eigentümerprüfungen konfigurieren und interne Header setzen, die die Identität der Ausführung und den Zielport tragen und dabei vom Client gesendete Werte ersetzen. Ein Client kann eine Anfrage also nicht durch gefälschte Header zu einer anderen Ausführung lenken.

Der Activator wählt dann einen von zwei Pfaden. Auf dem Hot Path läuft die Ausführung, ihr Readiness-Flag ist gesetzt und ihr Lease gültig, sodass die Anfrage ohne neue Platzierungsentscheidung an den Host weitergeleitet wird. Auf dem Wake Path bittet der Activator den Controller, die Ausführung zu erstellen oder fortzusetzen, sofern die Richtlinie es erlaubt, und die Anfrage wartet bis zu einer Frist darauf, dass der Routing-Zustand zulässig wird. DigitalOcean warnt, dass ein Readiness-Flag der Control Plane für sich genommen kein Beweis dafür sei, dass jeder Anwendungsendpunkt gesund ist.

Host-Heartbeats halten die Routing-Ansicht aktuell, und Leases begrenzen, wie lange sie gültig bleibt. Meldet sich ein Host nicht mehr, werden seine Adressen unzulässig, statt als veraltete Routen weiterzubestehen. Der letzte Hop ist lokal: microvm-proxyd betreibt Envoy, microvm-d liefert dessen Konfiguration über einen Unix-Socket, und der Activator verbindet sich per Mutual TLS mit dem Host-Envoy. Envoy entfernt interne Routing-Header und leitet HTTP an den Gast weiter. Das Unternehmen betont, dass dies keine durchgehende TLS-Verbindung vom Client bis zur Anwendung sei, da jeder Hop eine eigene Rolle und Vertrauensgrenze habe.

Der Beitrag erklärt außerdem, dass jeder Gast dieselbe IP-Adresse hat. Ein Checkpoint bewahrt die Sicht des Gast-Kernels auf das Netzwerk, einschließlich Schnittstellenkonfiguration und zwischengespeicherter Neighbor-Einträge. Eine neue Adresse für einen wiederhergestellten Gast würde daher bedeuten, gesicherten Zustand zu verändern. Beim Forken wäre das noch schwieriger, weil jeder Fork von derselben Konfiguration ausgeht. Der bereitgestellte Quelltext endet an dieser Stelle.

Was das für Nutzer bedeutet

Für Teams, die Agenten entwickeln, legt der Beitrag dar, wie DigitalOcean Sitzungen pausieren und mit intaktem laufendem Zustand fortsetzen lassen will, statt zwischen Kosten für Leerlauf und Zeit für den Neuaufbau wählen zu müssen. Die Managed Agents befinden sich in der Public Preview, und die Beschreibung der Architektur ist die eigene Darstellung des Unternehmens zu seinem Design und kein unabhängiger Test.