Engagements d'exploitation
Délais de réponse, canal Slack partagé, préavis de maintenance, inventaire de référence et traitement des pannes matérielles, inscrits dans notre spécification de livraison HGX B300.
Nos engagements d'exploitation précisent par écrit la rapidité de notre réponse, la manière dont nous vous tenons informés, le préavis que nous donnons et la façon dont nous traitons les pannes matérielles. Ils constituent la section 15 de notre spécification de livraison, la base de référence de toute proposition HGX B300.
Les engagements en un tableau
Chaque engagement est un chiffre exprimé en minutes, en jours ou en mois, afin que vous puissiez vérifier nos actions au regard de ce chiffre.
| Engagement | Indicateur |
|---|---|
| Accusé de réception de l'incident et désignation d'un responsable de l'incident | Sous 15 minutes |
| Mises à jour tant qu'un incident est ouvert | Au moins toutes les 60 minutes |
| Équipe d'exploitation réseau mobilisée, à toute heure | Sous 15 minutes |
| Équipe technique du site ou techniciens sur site mobilisés | Sous 45 minutes |
| Rapport post-incident écrit après un incident qui affecte le client | Sous 7 jours |
| Préavis avant une maintenance planifiée à risque élevé | Au moins 7 jours |
| Changements d'inventaire et d'état visibles pour vous | Sous 5 minutes |
| Filtrage anti-DDoS activé via BGP | Sous 5 minutes |
| Modifications des règles du pare-feu de bordure | Sous 1 jour ouvrable |
| Conservation de la télémétrie opérationnelle, et de l'historique des incidents et des états | 30 jours, et 12 mois |
Nous ne publions pas de taux de disponibilité en pourcentage. Nous publions ce que nous faisons en cas de problème, et dans quels délais.
Assistance : un canal partagé et un responsable attitré
Vous travaillez directement avec les personnes qui exploitent votre cluster, dans un canal Slack partagé ouvert en permanence.
Un canal Slack partagé
Ouvert en permanence, avec notre responsable de l'incident, nos équipes d'exploitation réseau et d'exploitation du site et nos techniciens sur site.
Un responsable technique de compte attitré
Une personne désignée chez 1Legion, responsable de votre compte.
Deux moyens de joindre l'équipe de garde
Deux moyens indépendants et testés de joindre un intervenant de garde qualifié, 24 heures sur 24, tous les jours.
Le canal réunit au même endroit les personnes touchées par un problème et celles qui le résolvent. Le second moyen, indépendant, de joindre l'équipe de garde existe pour le cas où le premier est lui-même en cause.
Incidents, de la première alerte au rapport post-incident
Les incidents suivent une séquence unique : accusé de réception et désignation d'un responsable de l'incident dans un délai de 15 minutes, mobilisation des ingénieurs, mises à jour au moins toutes les 60 minutes, et rapport post-incident écrit dans les 7 jours civils suivant chaque incident ayant un impact sur le client.
Accusé de réception
Nous accusons réception de l'incident et désignons un responsable de l'incident dans un délai de 15 minutes. Le responsable de l'incident est la seule personne qui coordonne la réponse.
Mobilisation
L'équipe d'exploitation réseau est mobilisée dans un délai de 15 minutes à toute heure, et l'équipe technique du site ou les techniciens sur site dans un délai de 45 minutes.
Mises à jour
Vous recevez des mises à jour au moins toutes les 60 minutes tant que l'incident est ouvert.
Rapport post-incident
Dans les 7 jours civils suivant chaque incident ayant un impact sur le client, vous recevez un rapport post-incident écrit.
Un rapport post-incident est un compte rendu écrit d'un incident : ce qui s'est passé, pourquoi, et ce qui est fait pour que cela ne se reproduise pas.
Maintenance, changements et inventaire
Les travaux planifiés qui comportent un risque sont annoncés au moins 7 jours civils à l'avance, les modifications passent par une gestion des changements écrite, et un inventaire de référence enregistre votre cluster jusqu'au moindre câble.
Préavis de maintenance
Le préavis s'applique à la maintenance à risque élevé non urgente et vous laisse le temps de déplacer vos tâches ou de créer un point de contrôle avant le début des travaux. Les travaux d'urgence ne relèvent pas de ce préavis. Du côté des sites, nous demandons aux centres de données que nous utilisons un préavis de 14 jours pour toute maintenance à risque.
Gestion des changements et accès
Une gestion des changements écrite signifie que les modifications de votre cluster suivent une procédure documentée et laissent une trace écrite. L'accès hors bande, la voie de gestion qui atteint un serveur par son BMC, sous le système d'exploitation, fait l'objet d'un audit.
L'inventaire
Nous tenons un inventaire de référence de chaque baie, nœud, GPU, carte réseau, disque, commutateur, port, émetteur-récepteur et câble, avec une exportation lisible par machine à votre intention. Les changements d'état sont visibles dans un délai de 5 minutes. La détection des dérives compare le cluster à la configuration de référence convenue, de sorte qu'un changement que personne n'a prévu apparaît.
Nous développons notre propre logiciel de plateforme pour l'inventaire, la surveillance et l'automatisation du déverminage, à partir de composants open source. Un portail client et une API publique font partie de ce travail et ne sont pas encore disponibles.
Traitement des pannes matérielles
Nous détectons et corrigeons les pannes du matériel, du site, du refroidissement et du réseau d'interconnexion, et nous mettons immédiatement en quarantaine tout GPU présentant une panne fatale.
| Panne | Signification | Ce que nous faisons |
|---|---|---|
| XID 79 | Le GPU n'est plus visible sur le bus et ne répond plus | Mise en quarantaine immédiate |
| XID 48 | Le pilote a signalé une erreur ECC sur deux bits | Mise en quarantaine immédiate |
| Erreur ECC sur deux bits | Une erreur non corrigible dans la mémoire du GPU | Mise en quarantaine immédiate |
| Échec du remappage de lignes | Le GPU n'a pas pu remapper une ligne de mémoire défectueuse vers une ligne de réserve | Mise en quarantaine immédiate |
| XID 13 ou XID 31 récurrent | Une exception du moteur graphique ou un défaut de page de la mémoire GPU | Intervention à partir d'un nombre d'occurrences convenu |
| Usure des disques NVMe | Les disques flash s'usent au fil des écritures de données | Remplacement avant les limites d'endurance |
| Blocage NCCL | Une opération collective cesse de progresser | Corrélation avec les événements du réseau d'interconnexion |
| Suspicion de corruption silencieuse de données | Résultats erronés sans erreur signalée | Maintien du nœud en quarantaine |
La mise en quarantaine retire le matériel concerné du service jusqu'à la correction de la panne, afin qu'aucune tâche n'y soit placée. Les erreurs XID 13 et XID 31 peuvent provenir de l'application plutôt que du GPU : nous intervenons donc lorsqu'elles se répètent au-delà d'un nombre d'occurrences convenu. Lorsqu'une tâche NCCL se bloque, nous vérifions les événements du réseau d'interconnexion survenus au même moment, afin de détecter une éventuelle panne de liaison ou de commutateur à l'origine du blocage. La corruption silencieuse de données est l'une des pannes les plus difficiles à repérer, car rien ne la signale : c'est pourquoi un nœud suspect reste en quarantaine. Les disques NVMe sont remplacés avant d'atteindre leur limite d'endurance, et non après une défaillance.
Service du système de stockage
Si votre cluster utilise un système de stockage géré par son fournisseur, la spécification prévoit une architecture prise en charge par ce fournisseur, une escalade 24 h/24, 7 j/7, un débit et une latence faisant l'objet d'un engagement pour chaque niveau, une utilisation et des quotas visibles, et une restauration testée.
- Architecture prise en charge par le fournisseur. Le système, de VAST Data, WEKA ou DDN, est construit selon une architecture que son fournisseur prend en charge.
- Escalade 24 h/24, 7 j/7. Un problème de stockage peut faire l'objet d'une escalade à toute heure.
- Débit et latence par niveau. Chaque niveau de stockage dispose d'un débit et d'une latence faisant l'objet d'un engagement, ce qui vous permet de planifier vos tâches et vos points de contrôle en fonction de chiffres connus.
- Utilisation et quotas. L'utilisation et les quotas sont visibles, afin que la capacité ne s'épuise pas sans que personne ne s'en aperçoive.
- Restauration testée. La restauration est testée, et pas seulement documentée.
Les deux options de stockage, le système de stockage et les nœuds de stockage pour votre propre logiciel, sont décrites sur notre page Stockage et réseau.
Télémétrie et historique
Nous collectons la télémétrie matérielle hors bande, et conservons la télémétrie opérationnelle au moins 30 jours et l'historique des incidents et des états au moins 12 mois.
La télémétrie hors bande provient des BMC des serveurs via Redfish : elle continue donc de remonter des données lorsque le système d'exploitation ne le fait plus. La télémétrie du réseau et du site est collectée lorsqu'elle est disponible. Avec au moins 12 mois d'historique des incidents et des états, une panne qui se reproduit à plusieurs mois d'intervalle peut encore être rapprochée de ses occurrences précédentes.
Avant que tout cela ne s'applique, chaque cluster réussit les tests décrits sur notre page Déverminage et réception. Si vous souhaitez également que nous exploitions la couche plateforme sur vos serveurs, voir Kubernetes géré.
Questions des acheteurs
S'agit-il d'un accord de niveau de service (SLA) avec un taux de disponibilité en pourcentage et des crédits de service ?
Non. Nous ne publions ni taux de disponibilité en pourcentage ni crédits de service. Nous publions à la place les engagements de cette page : délais de réponse, intervalles entre les mises à jour, préavis, rapports et traitement des pannes. Votre proposition précise les conditions de votre contrat.
En combien de temps réagissez-vous à un incident ?
Les incidents font l'objet d'un accusé de réception et un responsable de l'incident est désigné dans un délai de 15 minutes. L'équipe d'exploitation réseau est mobilisée dans un délai de 15 minutes à toute heure, et l'équipe technique du site ou les techniciens sur site dans un délai de 45 minutes.
Comment vous joindre en dehors des heures ouvrables ?
Par le canal Slack partagé, ouvert en permanence, ou par deux moyens indépendants et testés de joindre un intervenant de garde qualifié, 24 heures sur 24, tous les jours.
Quel préavis donnez-vous avant une maintenance ?
Au moins 7 jours civils pour toute maintenance à risque élevé non urgente.
Que se passe-t-il lorsqu'un GPU présente une panne fatale ?
Nous mettons immédiatement en quarantaine tout GPU présentant une panne fatale : XID 79, XID 48, erreurs ECC sur deux bits et échecs du remappage de lignes. Nous identifions ensuite la panne et la corrigeons.
Dites-nous ce que vous devez exécuter.
Indiquez-nous le matériel, le nombre de serveurs, la durée d'engagement et la date de début. Vous recevez une proposition écrite fondée sur notre spécification de livraison.