Így állítja vissza a DigitalOcean a MicroVM-eket milliszekundumok alatt
A DigitalOcean olyan MicroVM-platformot épített a Managed Agents mögé, amely képes egy ügynök munkamenetének folyamatokat, fájlokat és memóriabeli állapotot is megőrző szüneteltetésére és visszaállítására. A vállalat szerint a gyors folytatás kulcsa az, hogy a rendszer kevesebb adatot tölt vissza, nem az, hogy ugyanazt az adatot gyorsabban tölti be.
- A Managed Agents minden munkamenethez Firecracker microVM-et használ.
- A rendszer a folyamatokat, fájlokat, memóriát és hálózati állapotot is kezeli az ellenőrzési pontokban.
- A platform cellákra épül, amelyek saját vezérlési és gazdagépi síkkal rendelkeznek.
- A PostgreSQL az állapotokat és metaadatokat, a Spaces a nagy lemez- és memóriatartalmakat tárolja.
- A bejövő kérések futó munkamenetnél közvetlen, ébresztésnél vezérlőn keresztüli útvonalat kapnak.
A futó környezet állapotát is meg kell őrizni
Egy ügynök tesztkészletet indíthat, módosíthat egy fájlt, modellt hívhat, majd várakozhat, mielőtt később ugyanonnan folytatja a munkát. Ilyenkor a fájlok mellett a futó értelmező, a memóriában lévő index és a félbehagyott folyamat állapota is fontos lehet.
A DigitalOcean szerint a hagyományos infrastruktúra nehezen kezeli ezt a helyzetet. Ha a gép futva marad, az üresjárati munkamenetek továbbra is erőforrásokat foglalnak. Ha leállítják, a következő interakciónál újra fel kell építeni a környezetet. A fájlrendszer mentése önmagában nem őrzi meg a futó állapotot.
A Managed Agents jelenleg nyilvános előzetesben érhető el. A Harness Runtime minden munkamenethez Firecracker microVM-et biztosít, a platform pedig kezeli az elkülönítést, a hálózatot, a tárolást és az ellenőrzési pontokból történő visszaállítást. Az Action Gateway szabályozott hozzáférést ad az eszközökhöz.
Cellák választják el egymástól a hibákat
A MicroVM-platform alapegysége a cella, amely egy régióhoz kötött, önálló infrastruktúrapéldány. Saját VPC-t, DigitalOcean Kubernetes-fürtöt, kezelt PostgreSQL-adatbázist, Spaces-tárolót és hipervizor-gépekből álló készletet tartalmaz.
Egy régióban több cella futhat egymás mellett. A DigitalOcean így egy cellán belül bővítheti a kapacitást, vagy újabb cellát indíthat. Egy cella helyi adatbázis- vagy útválasztási hibája nem terjed automatikusan az összes többi cellára, bár a cellák közös régiós és platformszolgáltatásoktól továbbra is függnek.
A cellák két fő részre oszlanak. A Kubernetesen futó vezérlési sík kezeli az életciklus-döntéseket, az elhelyezést és a tartós metaadatokat. A gazdagépi sík a Firecracker-folyamatokat, valamint a vendégrendszerek hálózatát, lemezeit és memóriáját futtatja hipervizor Dropleteken.
A PostgreSQL az állapotokat, az útválasztási és bérleti információkat, valamint az ellenőrzési pontok metaadatait tárolja. A nagy lemez- és memóriatartalmak a Spaces-be kerülnek. A szétválasztás megakadályozza, hogy egy pillanatkép mérete egy adatbázis-tranzakció méretévé váljon.
Külön útvonal a futó és az ébresztendő munkamenetekhez
A bejövő forgalomnak először meg kell találnia a megfelelő végrehajtást, és szükség esetén fel is kell ébresztenie. A kimenő forgalomnál ezzel szemben az adott végrehajtás hálózati szabályainak betartása a fő szempont.
Ha egy végrehajtás fut, készenléti jelzője aktív, és az érvényes bérlete még nem járt le, az aktivátor közvetlenül a PostgreSQL-ben tárolt állapot alapján választ gazdagépet. Ez a forró útvonal, amelyhez nincs szükség új elhelyezési döntésre a vezérlőtől.
Az ébresztési útvonalon az aktivátor akkor kér létrehozást vagy folytatást, ha azt a végrehajtás szabályzata engedi. A kérés addig vár, amíg az útválasztási állapot megfelelővé válik, vagy le nem jár a határidő.
A DigitalOcean Edge végzi a peremhálózati útválasztást, az aktivátor a végrehajtás elérhetőségét kezeli, a gazdagépen futó Envoy pedig a végső útvonalat választja ki. A vállalat szerint a proxyk minden lépésének külön szerepe és bizalmi határa van. A gazdagépek szívverései frissítik az útválasztási nézetet, a lejárt bérletek pedig megakadályozzák, hogy egy leállt gazdagép címe elavult útvonalként megmaradjon.
A Firecracker külön kernelt ad minden vendégnek
A Firecracker KVM-alapú hardveres virtualizációt használ. Ennek eredményeként minden vendég saját kernelt kap, szemben a konténerekkel, amelyek a gazdagép kernelét osztják meg. A hálózati névterek ezt a virtuális gépi határt egészítik ki, és nem helyettesítik.
A rendszer egyik központi döntése, hogy a munkamenetet elválasztja az azt futtató gazdagéptől. A vendég stabil hálózati konfigurációt tart meg, a változtathatatlan tárolás pedig az ellenőrzési pontként mentett lemezt és memóriát őrzi. A gazdagép oldali proxyk hálózati szabályokat alkalmazhatnak, és hitelesítő adatokat csatolhatnak anélkül, hogy ezek a vendégkörnyezetbe kerülnének.
A DigitalOcean bemutatása alapján ez a felépítés a felhasználók számára azt jelenti, hogy egy ügynök munkamenete a szüneteltetés után a korábbi folyamatokkal, fájlokkal és kontextussal folytatható. A platform emellett a cellák, a külön kezelt vezérlési és gazdagépi sík, valamint a gyors visszaállítás révén a kapacitáskezelést és a hibák elkülönítését is az architektúra részévé teszi.
DigitalOcean: Building a computer that can pause and resume in milliseconds: Inside the MicroVM architecture behind Managed Agents
