Managed Kubernetes

Wir installieren Kubernetes auf Ihren dedizierten GPU-Servern mit NVIDIA GPU Operator und Network Operator, betreiben, aktualisieren und überwachen es und sind dafür in Rufbereitschaft.

Managed Kubernetes von 1Legion läuft auf GPU-Servern, die Ihnen allein zur Verfügung stehen, nicht auf gemeinsam genutzten Knoten. Wir installieren den Cluster mit NVIDIA GPU Operator und Network Operator, betreiben, aktualisieren und überwachen ihn und sind dafür in Rufbereitschaft. Ihr Team stellt seine Anwendungen über Kubernetes bereit; wir halten die Plattform, die GPUs und die Fabric darunter funktionsfähig.

Kubernetes auf Bare-Metal-GPU-Servern

Zwei Operatoren von NVIDIA bringen die GPU- und Netzwerksoftware auf jeden Knoten, sodass die Hardware in Kubernetes als Ressourcen erscheint, die Ihre Pods anfordern können.

NVIDIA GPU Operator

Verwaltet den NVIDIA-Treiber, das NVIDIA Container Toolkit, das Kubernetes-Device-Plugin, die Labels von GPU Feature Discovery und das DCGM-basierte Monitoring auf jedem GPU-Knoten. Pods fordern GPUs als nvidia.com/gpu an.

NVIDIA Network Operator

Installiert die Netzwerksoftware des Hosts: den NVIDIA-Netzwerktreiber, Device-Plugins, CNI-Plugins und die IP-Adressverwaltung, sodass Pods die RDMA-Fabric und GPUDirect RDMA nutzen können.

Die Server sind Bare Metal, es gibt also keinen Hypervisor zwischen Ihren Pods und den GPUs und keine Workloads anderer Kunden auf den Knoten. In einem HGX B300-Cluster bringt jeder GPU-Knoten 8 GPUs mit je 270 GB HBM3e, 800 Gbit/s Fabric-Bandbreite pro GPU und mindestens 9,2 TB lokalen NVMe-Speicher mit, alles ausschließlich für Ihre Workloads. CPU-Knoten übernehmen die Dienste rund um die GPUs, etwa Serving, Routing und Batch-Jobs, mit mindestens 6 Hardware-Threads und 24 GB Arbeitsspeicher pro GPU.

GPU Feature Discovery versieht jeden Knoten mit Labels zu GPU-Modell, Speicher und Treiberversion, sodass ein Deployment die benötigten Knoten mit einem gewöhnlichen Node Selector auswählen kann.

Was „Managed“ bedeutet

Vier Aufgaben bleiben bei uns, solange wir den Cluster verwalten: Wir betreiben ihn, aktualisieren ihn, überwachen ihn und sind zu jeder Uhrzeit für ihn zuständig.

Betrieb

Wir betreiben die Control Plane, beide Operatoren und jeden Knoten. Knoten mit fatalen GPU-Fehlern (XID 79, XID 48, Double-Bit-ECC-Fehler, Fehler beim Row Remapping) werden sofort unter Quarantäne gestellt.

Upgrades

Wir aktualisieren Kubernetes, die Operatoren und den GPU-Treiber im Rahmen eines schriftlichen Change-Managements und kündigen risikoreiche Arbeiten mindestens 7 Kalendertage im Voraus an.

Monitoring

DCGM-Metriken von jeder GPU sowie Out-of-Band-Hardwaretelemetrie über BMC und Redfish. Betriebstelemetrie wird mindestens 30 Tage aufbewahrt, die Historie von Störungen und Zuständen mindestens 12 Monate.

Rufbereitschaft

Zwei unabhängige, getestete Wege zu einem qualifizierten Mitarbeiter in Rufbereitschaft, 24 Stunden am Tag, an jedem Tag. Innerhalb von 15 Minuten werden Störungen bestätigt und ein Incident Commander benannt.

Alle Betriebszusagen

Der Netzwerkbetrieb schaltet sich zu jeder Uhrzeit innerhalb von 15 Minuten ein, die Haustechnik oder Remote Hands innerhalb von 45 Minuten. Wiederkehrende XID 13- und XID 31-Fehler werden ab einer mit Ihnen vereinbarten Häufigkeit behandelt. Zwei weitere Zusagen zählen bei langen Trainingsläufen: Wir korrelieren hängende NCCL-Operationen mit Ereignissen in der Fabric, und wir ersetzen NVMe-Laufwerke, bevor sie die Grenze ihrer Schreibfestigkeit erreichen.

Geteilte Verantwortung

Wir betreiben die Plattform von der Hardware bis zu Kubernetes; Sie betreiben, was Sie darauf bereitstellen.

Bereich1Legion übernimmtSie übernehmen
Server, Strom und KühlungFindet und behebt Fehler an Hardware, Rechenzentrum und KühlungAuffälligkeiten im gemeinsamen Slack-Kanal melden
GPU-FehlerStellt Knoten mit fatalen GPU-Fehlern sofort unter Quarantäne und hält Knoten mit Verdacht auf stille Datenkorruption in QuarantäneCheckpoints für Jobs setzen, damit sie auf intakten Knoten weiterlaufen
Kubernetes und KnotensoftwareInstalliert, aktualisiert und überwacht Kubernetes, den GPU Operator, den Network Operator und den GPU-TreiberUns mitteilen, von welchen Versionen Ihre Software abhängt
Fabric und EdgeBetreibt die Ost-West-Fabric, das Nord-Süd-Netzwerk und das Edge-Netzwerk und setzt Änderungen an Edge-ACLs innerhalb eines Geschäftstags umÜber die Edge-ACL-Regeln entscheiden und darüber, was Ihre Dienste nach außen freigeben
StörungenBestätigt innerhalb von 15 Minuten, benennt einen Incident Commander, liefert mindestens alle 60 Minuten Statusmeldungen und schreibt innerhalb von 7 Tagen nach jeder Störung mit Auswirkungen auf Kunden ein PostmortemProbleme im gemeinsamen Kanal oder über die Wege zur Rufbereitschaft melden
WorkloadsHält die Knoten und GPUs, auf denen sie laufen, in BetriebContainer, Modelle, Datensätze und Checkpoints sowie die Deployments und Jobs, die sie nutzen
MonitoringÜberwacht den Zustand von Cluster, Knoten und GPUsEigene Anwendungen und Modelle überwachen

Upgrades und Wartung

Jede Änderung am Cluster folgt einem schriftlichen Change-Management, und risikoreiche Wartung außerhalb von Notfällen kündigen wir mindestens 7 Kalendertage im Voraus an.

Die Regel gilt für Upgrades von Kubernetes, den beiden Operatoren und dem GPU-Treiber, wann immer sie risikoreich sind, ebenso wie für Arbeiten an der Hardware. Notfallarbeiten, etwa die Wiederherstellung des Dienstes während einer Störung, folgen stattdessen dem Störungsprozess. Warum lange Trainingsläufe in der geteilten Cloud scheitern zeigt, was ein unangekündigtes Treiberupdate mit einem laufenden Trainingslauf anrichten kann. Das maßgebliche Inventar erfasst jeden Knoten, jede GPU, jede NIC und jedes Laufwerk, erkennt Abweichungen von der vereinbarten Baseline und macht Zustandsänderungen innerhalb von 5 Minuten in einem maschinenlesbaren Export für Sie sichtbar. Unser Out-of-Band-Zugriff auf Ihre Server wird auditiert.

7 Tage Vorankündigung vor risikoreicher Wartung außerhalb von Notfällen
15 Min. Bis zur Bestätigung einer Störung und zur Benennung eines Incident Commanders
60 Min. Längster Abstand zwischen Statusmeldungen zu einer Störung
5 Min. Bis Inventar- und Zustandsänderungen bei Ihnen ankommen

Managed Slurm

Managed Slurm ist die Alternative für Teams, die ihre Arbeit lieber als Batch-Jobs einplanen.

Forschungsteams, die Trainingsläufe mit sbatch und srun starten und nach Partition und Priorität in die Warteschlange stellen, ziehen Slurm oft Kubernetes vor. Wir betreiben den Scheduler, den Ihr Team bevorzugt, und nennen ihn in Ihrem Angebot. Die Server, die Fabric und das Burn-in mit HW-1 bis HW-5 sind in beiden Fällen gleich, ebenso der gemeinsame Kanal mit unserem Incident Commander. Die Hardware unter beiden beschreibt die Seite GPU-Cluster.

Wie Managed Kubernetes bepreist wird

Managed Kubernetes ist ein Managementservice, der zusätzlich zur Servermiete berechnet wird, als eigene Position in Ihrem Angebot.

Es gibt keine veröffentlichte Gebühr und keine Self-Service-Registrierung. Wir entwickeln eigene Plattformsoftware für Inventar, Monitoring und die Automatisierung des Burn-ins. Heute arbeiten Sie mit uns über den gemeinsamen Slack-Kanal, einen festen technischen Ansprechpartner für Ihren Account, den Abnahmebericht bei der Übergabe und die Berichte, die wir Ihnen senden. Unsere Seite So mieten Sie erklärt Konditionen, Abrechnung und Onboarding.

Was Kunden fragen

Welche NVIDIA-Software installieren Sie?

Den NVIDIA GPU Operator und den NVIDIA Network Operator. Zusammen verwalten sie GPU-Treiber, Container Toolkit, Device-Plugin, GPU Feature Discovery, DCGM-Monitoring und die RDMA-Netzwerksoftware auf jedem Knoten.

Bieten Sie Managed Slurm an?

Ja. Managed Slurm ist die Alternative für Teams, die Batch-Scheduling bevorzugen, und Ihr Angebot nennt den Scheduler, den wir für Sie betreiben.

Was passiert, wenn eine GPU ausfällt?

Ein Knoten mit einem fatalen GPU-Fehler, etwa XID 79, XID 48, einem Double-Bit-ECC-Fehler oder einem Fehler beim Row Remapping, wird sofort unter Quarantäne gestellt, und wir finden und beheben den Fehler.

Wie lange im Voraus kündigen Sie Wartungen an?

Mindestens 7 Kalendertage bei risikoreicher Wartung außerhalb von Notfällen, und jede Änderung folgt einem schriftlichen Change-Management.

Gibt es eine Webkonsole für den Cluster?

Noch nicht. Wir entwickeln eigene Plattformsoftware; heute arbeiten Sie mit uns über einen gemeinsamen Slack-Kanal, einen festen technischen Ansprechpartner für Ihren Account und schriftliche Berichte.

Wie wird Managed Kubernetes bepreist?

Als Managementservice zusätzlich zur Servermiete, festgelegt in Ihrem schriftlichen Angebot. Wir veröffentlichen keine Preise.

Sagen Sie uns, was Sie betreiben möchten.

Nennen Sie uns die Hardware, die Anzahl der Server, die Laufzeit und das Startdatum. Sie erhalten ein schriftliches Angebot auf Grundlage unserer Lieferspezifikation.