Runtimes und Nodes

TL;DR

• Ein runtime ist eine Compute-Reservierung, in der ein deployment laeuft: ein Pool aus Maschinen, auf die der Workspace berechtigt ist zu deployen. Er traegt den runtime-Vertrag — runtime-Klasse, Kapazitaet, Lebensdauer, pro-deployment-Obergrenze — den ein deployment erbt.
• Ein node ist eine Maschine innerhalb eines runtime. Die Plattform plant Container automatisch ueber die nodes hinweg; Nutzer waehlen nodes nicht von Hand aus.
• Ein flavor ist das dimensionierte Template, aus dem ein node provisioniert wurde (CPU / GPU / RAM / Disk). Der flavor-Katalog listet, welche Groessen existieren und was auf Lager ist.
• runtimes kommen in zwei Formen: cloud-gestuetzt (die Plattform provisioniert nodes aus einer flavor-SKU bei Bedarf) und statisch (der runtime ist an vorregistrierte Kunden-Hardware angebunden — on-premise oder air-gapped).
• Der runtime-Vertrag eines runtime — ob er locked ist, seine node-Anzahl, sein Ablauf, seine pro-deployment-Obergrenze und seine runtime-Klasse — ist es, was die runtime-Auswahl zu einer bewussten Abstimmung mit der Last macht statt zu einem blinden Deploy.

Was runtimes und nodes sind

Ein runtime ist die Einheit, auf die ein deployment zielt, und ein node ist eine Maschine darin. Pipelogic modelliert die beiden getrennt, damit die Wahl, die ein Nutzer trifft (welcher runtime), von der Platzierung entkoppelt ist, die die Plattform vornimmt (welcher node). Ein einzelnes "Wo laeuft meine Last"-Konzept wuerde Details zusammenfalten, die fuer den Nutzer wichtig sind — GPU-Klasse, Speicher pro Instanz, Tenancy-Modell, ob die Last auf verwalteter Cloud oder auf der eigenen Hardware des Kunden laeuft — und Details, die der Scheduler besitzen sollte.

Der runtime ist, was Nutzer auswaehlen: ein benannter Pool mit eigenem Lock-Zustand, eigener runtime-Klasse, Lebensdauer und Berechtigung. Der node ist, was darin laeuft: eine Maschine, auf die die Plattform Container plant. Die Aufteilung laesst Nutzer ueber die Einheit nachdenken, die ihnen wichtig ist (runtime), ohne ueber die nachzudenken, die es nicht ist (eine konkrete Maschine), und laesst den Scheduler Container platzieren, ohne die Platzierung als Nutzerwahl zu exponieren.

Die runtime-Klasse an einem runtime ist das tragende Detail fuer viele Workflows. shared-runtimes hosten mehrere Tenants und sind der Standard fuer Entwicklung und kleine Lasten. dedicated-runtimes pinnen Compute an einen Workspace, fuer wenn die Platzierung im geteilten Pool zu unsicher ist. on_premise- und air_gapped-runtimes hosten nodes, die der Kunde eingebucht hat — die eigene Hardware des Workspace, innerhalb des Netzwerks des Kunden, an die Plattform angebunden, ohne dass Compute den Perimeter des Kunden verlaesst. Dasselbe backend deployt auf jede dieser Klassen ohne Codeaenderungen, weil backends von runtime entkoppelt sind.

Mentales Modell

   Workspace
       │
       │ owns
       ▼
   Runtime  (cloud-backed SKU  or  static set of nodes)
       │
       │ contains
       ▼
   Node     (a machine: VM / bare metal / cloud instance)
       │
       │ runs
       ▼
   container (one vertex of the deployed backend graph)

Der Nutzer waehlt den runtime; die Plattform waehlt den node. Ein deployment ist die Paarung eines backend mit einem runtime, und der Scheduler platziert die Container des deployment auf die nodes, die gesund sind und Spielraum haben. Von der Seite des Nutzers wird "Wo laeuft meine Last" durch das Benennen eines runtime beantwortet; den Rest erledigt die Plattform.

Siehe Deployments fuer die runtime-Paarung auf diesem Geflecht.

Cloud-gestuetzte versus statische runtimes

Nutze diesen Rahmen, wann immer die Frage lautet "woher soll das Compute dieser Last kommen".

Ein cloud-gestuetzter runtime ist die Standardform. Der runtime wird durch eine flavor-SKU identifiziert; die Plattform provisioniert nodes aus dieser SKU beim Deploy und dimensioniert das Compute passend zur Last. Der runtime erscheint im Listing des Workspace mit seiner aktuellen node-Anzahl und seiner pro-deployment-Obergrenze, und deployments landen darauf ohne vorherigen Provisionierungsschritt.

Ein statischer runtime ist die Kunden-Hardware-Form. Der runtime ist an vorregistrierte nodes angebunden — Maschinen, die der Kunde in seinen Workspace eingebucht hat, typischerweise innerhalb des eigenen Netzwerks, oft air-gapped vom oeffentlichen Internet. Die runtime-Klasse (on_premise oder air_gapped) wird von den nodes geerbt. Statische runtimes sind fuer Lasten, die aus Compliance-, Latenz- oder Daten-Lokalitaetsgruenden auf der eigenen Hardware des Kunden laufen muessen. Die verwaltete Cloud und die Hardware des Kunden sind dasselbe backend auf derselben Plattform — keine Codeaenderungen dazwischen.

Die Einbuch-Flaeche fuer statische runtimes ist bei Plaenen verfuegbar, die sie enthalten; die relevanten ppl node enroll …-Befehle erscheinen, wenn die Berechtigung vorhanden ist. Das Pinnen dedizierter Cloud-Kapazitaet folgt demselben Muster — diese Flaeche erscheint, wenn der Plan es erlaubt. Das Durchsuchen von Cloud-flavors mit ppl node flavors ist universell verfuegbar; der Live-Katalog listet, was auf Lager ist und auf welche runtime-Klassen jeder flavor abgebildet wird.

Einen runtime auswaehlen

Nutze diesen Rahmen jedes Mal, wenn du zu ppl backend deploy greifst.

Die runtime-Auswahl ist ein einmaliges List-und-Filter. Der Workspace sieht eine Menge von runtimes; jeder bewirbt, ob er locked ist (ein gesperrter runtime nimmt keine neuen deployments), seine node-Anzahl (ob Spielraum existiert), seinen deployment_count (aktuelle Nutzung gegen Kapazitaet), seine runtime-Klasse (passend zu den Compliance- und Performance-Anforderungen der Last) und sein expires_at (wann der runtime selbst zurueckgefordert wird, bei zeitlich begrenzten runtimes).

ppl runtime listCopyppl runtime list --query=stagingCopy

Wenn der einzige verfuegbare runtime voll ist oder seine runtime-Klasse nicht zur Last passt, lehnt der Deploy ab, bevor ein Container startet. Das ist beabsichtigt: die Plattform platziert kein deployment in einen runtime, der es nicht hosten kann, sodass "der Deploy ist gelungen" auch bedeutet "die runtime-Erwartung wurde erfuellt". Den Deploy zu akzeptieren und ihn zur Laufzeit fehlschlagen zu lassen wuerde den Fehler zu spaet zeigen, um nuetzlich zu sein.

Die deployment-Paarung ist dann ein einzelner Aufruf: ppl backend deploy --backend <bid> --runtime <cid>. Bei Single-backend-deploys ist --runtime optional: wird es weggelassen, wird zuerst der konfigurierte Standard-runtime des Workspace verwendet, und der Picker der Plattform waehlt danach einen deploybaren runtime. Nutze die explizite Form, wenn die Last einen bestimmten runtime braucht, beim Batchen mehrerer backends (wo --runtime erforderlich ist) oder wenn der Standard nicht zum anstehenden Run passt.

Siehe Deploy and monitor fuer die operative Schleife, nachdem der runtime gewaehlt ist.

Warum nodes scheduler-verwaltet sind

Nutze diesen Rahmen, wann immer du dich fragst "kann ich auswaehlen, welcher node das ausfuehrt".

nodes sind sichtbar (ppl node list gibt die Liste zurueck), aber sie sind nicht fuer die deployment-Platzierung auswaehlbar. Der Scheduler entscheidet, wo jeder Container landet, basierend darauf, ob der node locked ist, seinen Faehigkeiten, seiner aktuellen Last und dem Ressourcenbedarf des deployment. Diese Entscheidung ist aus zwei Gruenden nicht nutzerkontrollierbar.

Erstens ist die Platzierung ein Optimierungsproblem, das der Scheduler mit Informationen loest, die der Nutzer nicht hat. Eine Last mit zwei Containern koennte auf einem node ko-lokalisiert sein (fuer Shared-Memory-Transport) oder ueber nodes verteilt (fuer Fehlertoleranz), abhaengig von Details, die pro Run variieren. Container an bestimmte nodes zu pinnen verschlechtert die Platzierung im Schnitt und schafft operativen Aufwand ohne Nutzen.

Zweitens ist die node-Identitaet ephemer. Cloud-gestuetzte nodes werden rotiert, fuer Wartung gedraint und ersetzt, wenn sich ihr flavor-Katalog aendert. Ein deployment an einen bestimmten node zu pinnen wuerde diese Operationen exponieren, die unsichtbar sein sollen. Der Vertrag des Nutzers ist mit dem runtime, der eine stabile Identitaet und runtime-Klasse hat; die Plattform verwaltet die nodes darunter.

Beobachtbarkeit der Platzierung wird trotzdem exponiert. ppl deployment containers <did> zeigt, auf welchem node jeder Container gelandet ist, sodass das Team den Container-Zustand mit dem node-Zustand korrelieren und sagen kann, ob ein Problem node-lokal ist (ein node verhaelt sich daneben) oder systemisch (jeder node zeigt dasselbe Problem).

runtime-Lebenszyklus und -Operationen

Ein runtime hat seinen eigenen Lebenszyklus, getrennt von jedem deployment, das darauf laeuft. Ein runtime akzeptiert deployments, solange er nicht gesperrt ist und einen gesunden node hat; ein Operator kann ihn locken (fuer Wartung eingefroren, keine neuen deployments akzeptiert); und er wird zu seinem expires_at zurueckgefordert. Cloud-gestuetzte runtimes laufen nach dem Plan der Plattform ab; statische runtimes laufen ab, wenn der Kunde seine nodes abkoppelt.

Jedes deployment, das auf einem runtime landet, hat seine eigene Obergrenze — die deployment_timeout, die der runtime bewirbt. Standardmaessig verlaengern sich deployments automatisch bis zu dieser Obergrenze; das Uebergeben von --fixed-duration <dur> beim Deploy pinnt ein hartes Ende und deaktiviert die Auto-Verlaengerung. Pinne eine feste Dauer, wenn die Last ein bekanntes Wall-Clock-Budget hat (ein Demo-Fenster, ein geplanter Batch); lass die Auto-Verlaengerung fuer deployments, die so lange laufen sollen wie der runtime.

Haeufige Fehlerformen

Die meisten runtime-bezogenen Fehler clustern sich in eine kleine Menge von Formen:

• no deployable runtime available — jeder erreichbare runtime ist locked, voll oder hat keinen gesunden node. Die Abhilfe ist, einen anderen runtime mit Spielraum zu waehlen oder Kapazitaet freizugeben.
• runtime locked — der runtime ist fuer Wartung eingefroren. Die Abhilfe ist, zu warten, bis er entsperrt wird, oder einen anderen runtime fuer den Run zu nutzen.
• Reservierter runtime nicht bezahlt oder Reservierung abgelaufen — das Fenster eines dedizierten reservierten runtime ist abgelaufen. Die Abhilfe ist, die Reservierung zu erneuern oder auf einem anderen runtime zu deployen.
• deployment lief ab, bevor der Run fertig war — die deployment_timeout des runtime ist kuerzer als der Run brauchte. Die Abhilfe ist, --fixed-duration auf ein laengeres Fenster zu pinnen oder auf einem runtime mit hoeherer Obergrenze zu deployen.
• unknown flavor von deploy — der flavor-Name ist nicht im aktuellen Katalog (nur cloud-gestuetzte runtimes). Die Abhilfe ist, einen aktuellen flavor mit ppl node flavors aufzuloesen und einen zu waehlen, der existiert.

Breitere Fehlermuster leben in Common failures.

Wo das hineinpasst

runtimes und nodes sind die Laufzeitschicht der Plattform. Sie sitzen unter deployments — jedes deployment landet auf genau einem runtime, jeder Container im deployment landet auf genau einem node — und sie exponieren genug Vertrag, damit das Team ueber Kapazitaet, Compliance und Platzierung nachdenken kann, ohne die Scheduling-Interna zu exponieren, die die Plattform besitzt.

Die Aufteilung zwischen runtime (nutzer-sichtbarer runtime-Vertrag) und node (plattform-geplantes Compute) ist es, die dasselbe backend ohne Codeaenderungen auf einen geteilten Cloud-runtime und auf einen kunden-eingebuchten statischen runtime deployen laesst. Diese Portabilitaet folgt daraus, backends von runtime entkoppelt zu halten.

Verwandt

• Deployments — die backend-plus-runtime-Laufzeitpaarung auf diesem Geflecht.
• Backends — der typisierte Graph, der deployt wird.
• Leases — runtimes sind auch das, worauf leases zielen.
• Deploy and monitor — die operative Schleife, nachdem der runtime gewaehlt ist.
• Common failures — Symptom → Abhilfe-Nachschlag.