Compromisos operativos
Tiempos de respuesta, un canal de Slack compartido, preaviso de mantenimiento, un inventario maestro y la gestión de fallos de hardware, recogidos por escrito en nuestra especificación de entrega de HGX B300.
Nuestros compromisos operativos establecen por escrito con qué rapidez respondemos, cómo le mantenemos informado, con cuánta antelación avisamos y cómo gestionamos los fallos de hardware. Son la sección 15 de nuestra especificación de entrega, la base de toda propuesta de HGX B300.
Los compromisos en una tabla
Cada compromiso es una cifra en minutos, días o meses, para que pueda contrastar con ella lo que hacemos.
| Compromiso | Cifra |
|---|---|
| Acuse de recibo del incidente y asignación de un responsable de incidentes | En un máximo de 15 minutos |
| Actualizaciones mientras un incidente sigue abierto | Al menos cada 60 minutos |
| Operaciones de red movilizadas, a cualquier hora | En un máximo de 15 minutos |
| Ingeniería de la instalación o manos remotas movilizadas | En un máximo de 45 minutos |
| Informe posterior al incidente por escrito, si este afecta al cliente | En un máximo de 7 días |
| Aviso previo al mantenimiento planificado de alto riesgo | Al menos 7 días |
| Cambios de inventario y de estado visibles para usted | En un máximo de 5 minutos |
| Filtrado de DDoS activado mediante BGP | En un máximo de 5 minutos |
| Cambios en las reglas del cortafuegos perimetral | En un máximo de 1 día hábil |
| Conservación de la telemetría operativa y del historial de incidentes y de estados | 30 días y 12 meses |
No publicamos porcentajes de disponibilidad. Publicamos lo que hacemos cuando algo falla, y con qué rapidez.
Soporte: un canal compartido y un responsable designado
Usted trabaja directamente con las personas que operan su clúster, en un canal de Slack compartido que está abierto en todo momento.
Un canal de Slack compartido
Abierto en todo momento, con nuestro responsable de incidentes, operaciones de red, operaciones de las instalaciones y manos remotas.
Un responsable técnico de cuenta designado
Una persona designada de 1Legion que es responsable de su cuenta.
Dos vías para contactar con la guardia
Dos vías independientes y probadas para contactar con un técnico de guardia cualificado, 24 horas al día, todos los días.
El canal reúne en un mismo lugar a las personas afectadas por un problema y a las que lo resuelven. La segunda vía independiente para contactar con la guardia existe para el caso de que el problema sea la primera.
Incidentes, de la primera alerta al informe posterior al incidente
Los incidentes siguen una única secuencia: acuse de recibo y un responsable de incidentes en un plazo de 15 minutos, ingenieros movilizados, actualizaciones al menos cada 60 minutos y un informe escrito posterior al incidente en un plazo de 7 días naturales desde cada incidente que afecte al cliente.
Acuse de recibo
Acusamos recibo del incidente y asignamos un responsable de incidentes en un plazo de 15 minutos. El responsable de incidentes es la única persona que coordina la respuesta.
Intervención
Las operaciones de red intervienen en un plazo de 15 minutos a cualquier hora, y la ingeniería de instalaciones o las manos remotas, en un plazo de 45 minutos.
Actualizaciones
Usted recibe actualizaciones al menos cada 60 minutos mientras el incidente esté abierto.
Informe posterior al incidente
En un plazo de 7 días naturales desde cada incidente que afecte al cliente, usted recibe un informe escrito posterior al incidente.
Un informe posterior al incidente es un relato por escrito de un incidente: qué ocurrió, por qué ocurrió y qué se está haciendo para que no vuelva a ocurrir.
Mantenimiento, cambios e inventario
Los trabajos planificados que conllevan riesgo se anuncian con al menos 7 días naturales de antelación, los cambios pasan por una gestión de cambios por escrito y un inventario maestro registra su clúster hasta el último cable.
Preaviso de mantenimiento
El preaviso se aplica al mantenimiento de alto riesgo que no sea de emergencia, y le da tiempo para mover trabajos o guardar un checkpoint antes de que empiecen los trabajos. Los trabajos de emergencia quedan fuera del periodo de preaviso. En cuanto a las instalaciones, pedimos a los centros de datos que utilizamos un aviso con 14 días de antelación para el mantenimiento con riesgo.
Gestión de cambios y acceso
La gestión de cambios por escrito significa que los cambios en su clúster siguen un proceso documentado y dejan un registro por escrito. El acceso fuera de banda, la vía de gestión que llega a un servidor a través de su BMC, por debajo del sistema operativo, está auditado.
El inventario
Mantenemos un inventario maestro de cada rack, nodo, GPU, NIC, unidad, switch, puerto, transceptor y cable, con una exportación legible por máquina para usted. Los cambios de estado son visibles en un plazo de 5 minutos. La detección de desviaciones compara el clúster con la línea base acordada, de modo que cualquier cambio que nadie haya planificado sale a la luz.
Estamos desarrollando nuestro propio software de plataforma para inventario, monitorización y automatización del burn-in, sobre componentes de código abierto. Un portal de clientes y una API pública forman parte de ese trabajo y todavía no están disponibles.
Gestión de fallos de hardware
Detectamos y corregimos los fallos de hardware, de las instalaciones, de refrigeración y de fabric, y ponemos de inmediato en cuarentena una GPU con un fallo fatal.
| Fallo | Qué significa | Qué hacemos |
|---|---|---|
| XID 79 | La GPU se ha caído del bus y ha dejado de responder | Cuarentena inmediata |
| XID 48 | El controlador ha notificado un error ECC de doble bit | Cuarentena inmediata |
| Error ECC de doble bit | Un error no corregible en la memoria de la GPU | Cuarentena inmediata |
| Fallo de reasignación de filas | La GPU no ha podido reasignar una fila de memoria defectuosa a una de reserva | Cuarentena inmediata |
| XID 13 o XID 31 recurrentes | Una excepción del motor gráfico o un fallo de página de la memoria de la GPU | Actuar tras un número acordado de repeticiones |
| Desgaste de unidades NVMe | Las unidades flash se desgastan a medida que se escriben datos en ellas | Sustituir antes de alcanzar los límites de resistencia |
| Bloqueo de NCCL | Una operación colectiva deja de avanzar | Correlacionar con eventos del fabric |
| Sospecha de corrupción silenciosa de datos | Resultados erróneos sin que se notifique ningún error | Mantener el nodo en cuarentena |
La cuarentena retira de servicio el hardware afectado hasta que se corrige el fallo, para que no se le asigne ningún trabajo. XID 13 y XID 31 pueden deberse a la aplicación y no a la GPU, por lo que actuamos sobre ellos cuando se repiten más allá de un número acordado. Cuando un trabajo de NCCL se bloquea, revisamos los eventos del fabric del mismo momento, para poder encontrar un fallo de enlace o de switch que esté detrás del bloqueo. La corrupción silenciosa de datos es uno de los fallos más difíciles de ver, porque nada la notifica, y por eso un nodo sospechoso permanece en cuarentena. Las unidades NVMe se sustituyen antes de que alcancen sus límites de resistencia, y no después de que fallen.
Servicio del appliance de almacenamiento
Si su clúster utiliza un appliance de almacenamiento gestionado por el fabricante, la especificación establece el compromiso de un diseño con soporte del fabricante, con escalado 24/7, rendimiento y latencia comprometidos por nivel, uso y cuotas visibles, y recuperación probada.
- Diseño con soporte del fabricante. El appliance, de VAST Data, WEKA o DDN, se construye según un diseño que cuenta con el soporte de su fabricante.
- Escalado 24/7. Un problema de almacenamiento puede escalarse a cualquier hora.
- Rendimiento y latencia por nivel. Cada nivel de almacenamiento tiene un rendimiento y una latencia comprometidos, para que pueda planificar trabajos y checkpoints con cifras conocidas.
- Uso y cuotas. El uso y las cuotas son visibles, para que la capacidad no se agote sin que nadie lo note.
- Recuperación probada. La recuperación se prueba, no solo se documenta.
Las dos opciones de almacenamiento, el appliance y los nodos de almacenamiento para su propio software, se describen en nuestra página almacenamiento y redes.
Telemetría e historial
Recopilamos la telemetría de hardware fuera de banda, y conservamos la telemetría operativa durante al menos 30 días y el historial de incidentes y de estados durante al menos 12 meses.
La telemetría fuera de banda procede de los BMC de los servidores a través de Redfish, por lo que sigue informando aunque el sistema operativo no lo haga. La telemetría de red y de las instalaciones se recopila cuando está disponible. Conservar al menos 12 meses de historial de incidentes y de estados significa que un fallo que se repite con meses de diferencia todavía puede relacionarse con sus apariciones anteriores.
Antes de que se aplique todo esto, cada clúster supera las pruebas de nuestra página burn-in y aceptación. Si además quiere que operemos la capa de plataforma en sus servidores, consulte Kubernetes gestionado.
Lo que preguntan los compradores
¿Es un SLA con un porcentaje de disponibilidad y créditos de servicio?
No. No publicamos porcentajes de disponibilidad ni créditos de servicio. En su lugar, publicamos los compromisos de esta página: tiempos de respuesta, intervalos de actualización, plazos de preaviso, informes y gestión de fallos. Su propuesta establece las condiciones de su contrato.
¿Con qué rapidez responden a un incidente?
En un plazo de 15 minutos se acusa recibo de los incidentes y se asigna un responsable de incidentes. Las operaciones de red intervienen en un plazo de 15 minutos a cualquier hora, y la ingeniería de instalaciones o las manos remotas, en un plazo de 45 minutos.
¿Cómo contactamos con ustedes fuera del horario laboral?
A través del canal de Slack compartido, que está abierto en todo momento, o mediante dos vías independientes y probadas para contactar con un técnico de guardia cualificado, 24 horas al día, todos los días.
¿Con cuánta antelación avisan antes de un mantenimiento?
Al menos 7 días naturales para el mantenimiento de alto riesgo que no sea de emergencia.
¿Qué ocurre cuando una GPU tiene un fallo fatal?
Ponemos en cuarentena de inmediato los fallos fatales de GPU: XID 79, XID 48, errores ECC de doble bit y fallos de reasignación de filas. Después detectamos y corregimos el fallo.
Díganos qué necesita ejecutar.
Indíquenos el hardware, el número de servidores, la duración del contrato y la fecha de inicio. Recibirá una propuesta por escrito basada en nuestra especificación de entrega.