Betriebszusagen
Reaktionszeiten, ein gemeinsamer Slack-Kanal, Vorankündigung von Wartungen, ein maßgebliches Inventar und die Behandlung von Hardwarefehlern, festgeschrieben in unserer Lieferspezifikation für HGX B300.
Unsere Betriebszusagen legen schriftlich fest, wie schnell wir reagieren, wie wir Sie informieren, wie lange im Voraus wir Arbeiten ankündigen und wie wir mit Hardwarefehlern umgehen. Die Zusagen bilden Abschnitt 15 unserer Lieferspezifikation, der Grundlage jedes Angebots für HGX B300.
Die Zusagen in einer Tabelle
Jede Zusage ist ein Wert in Minuten, Tagen oder Monaten, sodass Sie unser Handeln daran messen können.
| Zusage | Wert |
|---|---|
| Störung bestätigt und ein Incident Commander benannt | Innerhalb von 15 Minuten |
| Statusmeldungen, solange eine Störung offen ist | Mindestens alle 60 Minuten |
| Netzwerkbetrieb eingebunden, zu jeder Uhrzeit | Innerhalb von 15 Minuten |
| Haustechnik oder Remote Hands eingebunden | Innerhalb von 45 Minuten |
| Schriftliches Postmortem nach einer Störung mit Auswirkungen auf Kunden | Innerhalb von 7 Tagen |
| Vorankündigung vor risikoreicher geplanter Wartung | Mindestens 7 Tage |
| Inventar- und Zustandsänderungen für Sie sichtbar | Innerhalb von 5 Minuten |
| Aktivierung des DDoS-Scrubbings über BGP | Innerhalb von 5 Minuten |
| Änderungen an Edge-Firewall-Regeln | Innerhalb von 1 Geschäftstag |
| Aufbewahrung der Betriebstelemetrie sowie der Historie von Störungen und Zuständen | 30 Tage bzw. 12 Monate |
Wir veröffentlichen keine Uptime-Prozentwerte. Wir veröffentlichen, was wir tun, wenn etwas schiefgeht, und wie schnell.
Support: ein gemeinsamer Kanal und ein fester Ansprechpartner
Sie arbeiten direkt mit den Menschen, die Ihren Cluster betreiben, in einem gemeinsamen Slack-Kanal, der jederzeit offen ist.
Ein gemeinsamer Slack-Kanal
Jederzeit offen, mit unserem Incident Commander, dem Netzwerkbetrieb, dem Rechenzentrumsbetrieb und Remote Hands.
Ein fester technischer Ansprechpartner für Ihren Account
Eine namentlich benannte Person bei 1Legion, die für Ihren Account verantwortlich ist.
Zwei Wege zur Rufbereitschaft
Zwei unabhängige, getestete Wege zu einem qualifizierten Mitarbeiter in Rufbereitschaft, 24 Stunden am Tag, an jedem Tag.
Der Kanal bringt die von einem Problem Betroffenen und diejenigen, die es beheben, an einem Ort zusammen. Der zweite, unabhängige Weg zur Rufbereitschaft ist für den Fall da, dass der erste das Problem ist.
Störungen, vom ersten Alarm bis zum Postmortem
Störungen folgen einem festen Ablauf: Bestätigung und Benennung eines Incident Commanders innerhalb von 15 Minuten, Einbindung der Techniker, Statusmeldungen mindestens alle 60 Minuten und ein schriftliches Postmortem innerhalb von 7 Kalendertagen nach jeder Störung mit Auswirkungen auf Kunden.
Bestätigen
Innerhalb von 15 Minuten bestätigen wir die Störung und benennen einen Incident Commander. Der Incident Commander ist die eine Person, die die Reaktion koordiniert.
Einbinden
Der Netzwerkbetrieb wird zu jeder Uhrzeit innerhalb von 15 Minuten eingebunden, die Haustechnik oder Remote Hands innerhalb von 45 Minuten.
Informieren
Solange die Störung offen ist, erhalten Sie mindestens alle 60 Minuten Statusmeldungen.
Postmortem
Innerhalb von 7 Kalendertagen nach jeder Störung mit Auswirkungen auf Kunden erhalten Sie ein schriftliches Postmortem.
Ein Postmortem ist ein schriftlicher Bericht über eine Störung: was passiert ist, warum es passiert ist und was getan wird, damit es nicht wieder passiert.
Wartung, Change-Management und Inventar
Geplante Arbeiten mit Risiko kündigen wir mindestens 7 Kalendertage im Voraus an, Änderungen durchlaufen ein schriftliches Change-Management, und ein maßgebliches Inventar erfasst Ihren Cluster bis zum einzelnen Kabel.
Vorankündigung von Wartungen
Die Vorankündigung gilt für risikoreiche Wartung außerhalb von Notfällen und gibt Ihnen Zeit, Jobs zu verlagern oder einen Checkpoint zu setzen, bevor die Arbeiten beginnen. Notfallarbeiten fallen nicht unter die Ankündigungsfrist. Von den Rechenzentren, die wir nutzen, verlangen wir unsererseits eine Vorankündigung von 14 Tagen für riskante Wartungsarbeiten.
Change-Management und Zugriff
Schriftliches Change-Management bedeutet, dass Änderungen an Ihrem Cluster einem dokumentierten Prozess folgen und schriftlich festgehalten werden. Der Out-of-Band-Zugriff, also der Verwaltungsweg, der einen Server über seinen BMC unterhalb des Betriebssystems erreicht, wird auditiert.
Das Inventar
Wir führen ein maßgebliches Inventar aller Racks, Knoten, GPUs, NICs, Laufwerke, Switches, Ports, Transceiver und Kabel, mit einem maschinenlesbaren Export für Sie. Zustandsänderungen sind innerhalb von 5 Minuten sichtbar. Die Drift-Erkennung vergleicht den Cluster mit der vereinbarten Baseline, sodass eine Änderung, die niemand geplant hat, auffällt.
Wir entwickeln eigene Plattformsoftware für Inventar, Monitoring und die Automatisierung des Burn-ins, auf Basis von Open-Source-Komponenten. Ein Kundenportal und eine öffentliche API gehören zu dieser Arbeit und sind noch nicht verfügbar.
Behandlung von Hardwarefehlern
Wir finden und beheben Fehler an Hardware, Rechenzentrum, Kühlung und Fabric und stellen eine GPU mit einem fatalen Fehler sofort unter Quarantäne.
| Fehler | Bedeutung | Was wir tun |
|---|---|---|
| XID 79 | Die GPU hat sich vom Bus getrennt und reagiert nicht mehr | Sofort unter Quarantäne stellen |
| XID 48 | Der Treiber hat einen Double-Bit-ECC-Fehler gemeldet | Sofort unter Quarantäne stellen |
| Double-Bit-ECC-Fehler | Ein nicht korrigierbarer Fehler im GPU-Speicher | Sofort unter Quarantäne stellen |
| Fehler beim Row Remapping | Die GPU konnte eine fehlerhafte Speicherzeile nicht auf eine Ersatzzeile umleiten | Sofort unter Quarantäne stellen |
| Wiederkehrende XID 13- oder XID 31-Fehler | Eine Ausnahme der Graphics Engine oder ein Seitenfehler im GPU-Speicher | Ab einer vereinbarten Häufigkeit handeln |
| Verschleiß von NVMe-Laufwerken | Flash-Laufwerke verschleißen, wenn Daten auf sie geschrieben werden | Ersetzen, bevor die Grenze der Schreibfestigkeit erreicht ist |
| Hängende NCCL-Operation | Eine kollektive Operation kommt nicht mehr voran | Mit Ereignissen in der Fabric korrelieren |
| Verdacht auf stille Datenkorruption | Falsche Ergebnisse ohne gemeldeten Fehler | Knoten in Quarantäne halten |
Die Quarantäne nimmt die betroffene Hardware außer Betrieb, bis der Fehler behoben ist, sodass kein Job darauf landet. XID 13 und XID 31 können von der Anwendung statt von der GPU stammen, daher handeln wir, wenn sie über eine vereinbarte Häufigkeit hinaus wiederkehren. Wenn ein NCCL-Job hängt, prüfen wir die Ereignisse in der Fabric aus demselben Moment, damit ein Link- oder Switch-Fehler als Ursache gefunden werden kann. Stille Datenkorruption gehört zu den am schwersten erkennbaren Fehlern, weil nichts sie meldet; deshalb bleibt ein verdächtiger Knoten in Quarantäne. NVMe-Laufwerke werden ersetzt, bevor sie die Grenze ihrer Schreibfestigkeit erreichen, nicht erst nach einem Ausfall.
Service für die Storage-Appliance
Wenn Ihr Cluster eine vom Hersteller verwaltete Storage-Appliance nutzt, sagt die Spezifikation ein vom Hersteller unterstütztes Design zu, mit 24/7-Eskalation, zugesagtem Durchsatz und zugesagter Latenz pro Storage-Tier, sichtbarer Nutzung und sichtbaren Quotas sowie getesteter Wiederherstellung.
- Vom Hersteller unterstütztes Design. Die Appliance von VAST Data, WEKA oder DDN wird nach einem Design aufgebaut, das ihr Hersteller unterstützt.
- 24/7-Eskalation. Ein Storage-Problem lässt sich zu jeder Uhrzeit eskalieren.
- Durchsatz und Latenz pro Storage-Tier. Jedes Storage-Tier hat zugesagte Werte für Durchsatz und Latenz, sodass Sie Jobs und Checkpoints auf Basis bekannter Werte planen können.
- Nutzung und Quotas. Nutzung und Quotas sind sichtbar, sodass die Kapazität nicht unbemerkt ausgeht.
- Getestete Wiederherstellung. Die Wiederherstellung wird getestet, nicht nur dokumentiert.
Beide Storage-Optionen, die Appliance und Storage-Knoten für Ihre eigene Software, beschreibt unsere Seite Storage und Netzwerk.
Telemetrie und Historie
Wir erfassen die Hardwaretelemetrie Out-of-Band und bewahren Betriebstelemetrie mindestens 30 Tage sowie die Historie von Störungen und Zuständen mindestens 12 Monate auf.
Die Out-of-Band-Telemetrie stammt über Redfish von den BMCs der Server und liefert deshalb auch dann weiter Daten, wenn das Betriebssystem keine mehr meldet. Netzwerk- und Rechenzentrumstelemetrie werden erfasst, wo verfügbar. Mindestens 12 Monate Historie von Störungen und Zuständen bedeuten, dass sich ein Fehler, der im Abstand von Monaten wiederkehrt, noch zu seinen früheren Vorkommen zurückverfolgen lässt.
Bevor all das greift, besteht jeder Cluster die Tests, die unsere Seite Burn-in und Abnahme beschreibt. Wenn wir zusätzlich die Plattformebene auf Ihren Servern betreiben sollen, sehen Sie sich Managed Kubernetes an.
Was Kunden fragen
Ist das ein SLA mit Uptime-Prozentwert und Servicegutschriften?
Nein. Wir veröffentlichen keine Uptime-Prozentwerte und keine Servicegutschriften. Stattdessen veröffentlichen wir die Zusagen auf dieser Seite: Reaktionszeiten, Intervalle für Statusmeldungen, Ankündigungsfristen, Berichte und Fehlerbehandlung. Ihr Angebot legt die Konditionen Ihres Vertrags fest.
Wie schnell reagieren Sie auf eine Störung?
Innerhalb von 15 Minuten werden Störungen bestätigt und ein Incident Commander benannt. Der Netzwerkbetrieb wird zu jeder Uhrzeit innerhalb von 15 Minuten eingebunden, die Haustechnik oder Remote Hands innerhalb von 45 Minuten.
Wie erreichen wir Sie außerhalb der Geschäftszeiten?
Über den gemeinsamen Slack-Kanal, der jederzeit offen ist, oder über zwei unabhängige, getestete Wege zu einem qualifizierten Mitarbeiter in Rufbereitschaft, 24 Stunden am Tag, an jedem Tag.
Wie lange im Voraus kündigen Sie Wartungen an?
Mindestens 7 Kalendertage bei risikoreicher Wartung außerhalb von Notfällen.
Was passiert, wenn eine GPU einen fatalen Fehler hat?
Bei fatalen GPU-Fehlern stellen wir die GPU sofort unter Quarantäne: XID 79, XID 48, Double-Bit-ECC-Fehler und Fehler beim Row Remapping. Dann finden und beheben wir den Fehler.
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.