Informa y repara hosts defectuosos con TPU en el modo All Capacity

Versión preliminar

Esta función está sujeta a las “Condiciones de la Oferta de la Fase Previa a la DG” en la sección Condiciones del Servicio Generales de las Condiciones Específicas del Servicio. Las funciones de la fase previa a la DG están disponibles sin modificaciones y pueden tener asistencia limitada. Para obtener más información, consulta las descripciones de la etapa de lanzamiento.

Si observas problemas en una VM en el modo All Capacity que no puedes resolver de otra manera (por ejemplo, métricas de latencia de ICI o temperatura constantemente altas en comparación con otras VMs), te recomendamos que informes que su host está defectuoso. Cuando informas que un host está defectuoso, Compute Engine lo marca como tal y repara la VM de forma automática ejecutando el mantenimiento del host. Con el modo All Capacity, las VMs de TPU no se migran a otro host durante la reparación. En cambio, se reiniciarán en el mismo host si hay capacidad suficiente. Solo puedes informar sobre un host defectuoso que tenga VMs en ejecución.

Usa el comando report-host-as-faulty para informar sobre un host defectuoso con el parámetro --fault-behavior para brindar información adicional sobre el problema.

gcloud compute instance report-host-as-faulty example-tpu-vm
   --fault-behavior \ # required
   --description="silent data corruption affecting our ML job…"
  [--disruption_policy=FUTURE | IMMEDIATE]

Puedes pasar uno de los siguientes valores para --fault-behavior:

• PERFORMANCE: Se usa para informar sobre la degradación del rendimiento en una instancia.
• SILENT_DATA_CORRUPTION: Se usa para informar cualquier sospecha de corrupción silenciosa de datos en una instancia.
• CHIP_ERROR: Se usa para informar cualquier error o falla de TPU en la que el acelerador deje de responder.
• BEHAVIOR_UNSPECIFIED: Se usa este grupo para informar un problema que no se encuentre en los otros tres grupos de comportamiento.

Por lo general, la operación para informar que el host está defectuoso tarda entre 10 y 12 minutos en completarse. Una vez que se completa la operación de informe, la reparación del host comienza en un minuto si la política de interrupción está configurada como immediate. Si se establece en future, no se toma ninguna medida de reparación de inmediato. En cambio, Compute Engine programa una reparación si se detecta alguna falla en el futuro. Una vez que se inicie la reparación, se apagará la VM. Es posible que esta permanezca en el estado pending hasta que se repare el host. La reparación del host defectuoso puede tardar entre 3 y 14 días, o más. En el modo All Capacity de TPU, las VMs de TPU no se migran a otro host durante la reparación. En cambio, se reiniciarán en el mismo host si hay capacidad suficiente.