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 diagy nccl-tests con los comandos que imprimeaccept 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.
Why this lab
Accepting new hardware and running go-live and service-acceptance reviews are part of my IT operations work. This lab applies the same discipline to a GPU cluster, from handover to the customer's signature.
What I built
A pipeline that runs inventory (GPU, driver, VBIOS, InfiniBand ports) → dcgmi diag -r 3 → nccl-tests per node → per rack → a 72-hour burn-in → a whole-cluster burn-in job scored with lab 12's rules.
- A node stops at its first failure, and every failure gets a disposition (RMA, firmware, fabric, facility, investigate, collect evidence), an owner and a next step.
- Criteria live in criteria.toml, and unknown keys are errors.
- A second round replaces the evidence of the first.
- Outputs: report.md and report.html for the customer (verdict, rack × node grid, punch list, criteria and a signature table), punch-list.csv and result.json.
The example
A fictional cluster with 4 racks × 8 nodes × 8 GPUs and 8 defects. Round 1 ends NOT READY with 144 of 256 GPUs. After round 2 it is READY with 248, and one node is still waiting on an RMA.
How it is tested
25 tests, and a CI job that runs both rounds and requires NOT READY and then READY.
Next steps
- Write your acceptance criteria in
criteria.toml. - Collect the real
dcgmi diagand nccl-tests output with the commands thataccept planprints. - Hand the HTML report and the punch list to the customer for sign-off.
Want to bring it to your environment or adapt it to your case? Get in touch and we can look at it together.
Tech Career Lab · newsletter
¿Te ha servido? Cada dos semanas envío una idea práctica para perfiles IT: LinkedIn, proyectos, networking y procesos de selección.Found this useful? Every two weeks I send one practical idea for IT professionals: LinkedIn, projects, networking and hiring processes.
Apúntate y llévate las 33 ideasSign up and get the 33 ideas →