Del handover a la firma: aceptar un clúster de GPU nuevo

Por qué este laboratorio

Aceptar hardware nuevo y llevar revisiones de puesta en producción y aceptación del servicio forman parte de mi trabajo en operaciones IT. Este laboratorio aplica la misma disciplina a un clúster de GPU, de la entrega a la firma del cliente.

Qué he hecho

Un proceso que pasa por inventario (GPU, driver, VBIOS, puertos InfiniBand) → dcgmi diag -r 3 → nccl-tests por nodo → por rack → burn-in de 72 horas → un trabajo de burn-in de todo el clúster medido con las reglas del laboratorio 12.

• Un nodo se para en su primer fallo, y cada fallo tiene disposición (RMA, firmware, fabric, instalaciones, investigar, recoger evidencia), responsable y siguiente paso.
• Los criterios están en criteria.toml, y las claves desconocidas son error.
• Una segunda ronda sustituye la evidencia de la primera.
• Salidas: report.md y report.html para el cliente (veredicto, rejilla rack × nodo, lista de pendientes, criterios y tabla de firmas), punch-list.csv y result.json.

El ejemplo

Un clúster ficticio de 4 racks × 8 nodos × 8 GPU con 8 defectos. La ronda 1 acaba NO LISTO con 144 de 256 GPU. Tras la ronda 2 queda LISTO con 248, y un nodo sigue esperando un RMA.

Cómo se prueba

25 tests y un job de CI que corre las dos rondas y exige NO LISTO y después LISTO.

Siguientes pasos

• Escribir tus criterios de aceptación en criteria.toml.
• Recoger la salida real de dcgmi diag y nccl-tests con los comandos que imprime accept plan.
• Entregar al cliente el informe HTML y la punch list para la firma.

¿Quieres llevarlo a tu entorno o adaptarlo a tu caso? Escríbeme y lo vemos.