Signaler et réparer les hôtes défectueux avec des TPU en mode "Toute la capacité"
Si vous constatez des problèmes sur une VM en mode "Toute la capacité" que vous ne pouvez pas résoudre autrement (par exemple, des métriques de latence ICI constamment élevées ou une température constamment élevée par rapport à ses pairs), nous vous recommandons de signaler son hôte comme défectueux. Lorsque vous signalez un hôte comme défectueux, Compute Engine le marque comme tel et répare automatiquement la VM en exécutant la maintenance de l'hôte. En mode "Toute la capacité", les VM TPU ne sont pas migrées vers un autre hôte pendant la réparation. Au lieu de cela, elles sont redémarrées sur le même hôte s'il y a suffisamment de capacité. Vous ne pouvez signaler qu'un hôte défectueux qui comporte une ou plusieurs VM en cours d'exécution.
Utilisez la commande report-host-as-faulty pour signaler un hôte défectueux à l'aide du paramètre --fault-behavior afin de fournir des informations supplémentaires sur le problème.
gcloud compute instances report-host-as-faulty TPU_NAME \ --fault-reasons=behavior=FAULT_BEHAVIOR,description=DESCRIPTION \ --disruption-schedule=DISRUPTION_SCHEDULE
Remplacez les éléments suivants :
- TPU_NAME : nom de la VM TPU.
FAULT_BEHAVIOR : vous pouvez transmettre l'une des valeurs suivantes :
PERFORMANCE: utilisez cette option pour signaler une dégradation des performances sur une instance.SILENT_DATA_CORRUPTION: utilisez cette option pour signaler toute corruption silencieuse des données suspectée sur une instance.BEHAVIOR_UNSPECIFIED: utilisez cette option pour signaler un problème qui ne correspond pas aux autres groupes de comportements.
DESCRIPTION : description du problème qui affecte votre VM.
DISRUPTION_SCHEDULE : spécifie le moment où le processus de signalement des erreurs doit être lancé. La valeur par défaut est
IMMEDIATE, ce qui lance le processus immédiatement.DISRUPTION_SCHEDULEdoit avoir l'une des valeurs suivantes :IMMEDIATEouFUTURE.
L'opération de signalement d'un hôte défectueux prend généralement 10 à 12 minutes. Une fois l'opération de signalement terminée, la réparation de l'hôte commence dans la minute qui suit si la planification des interruptions est définie sur IMMEDIATE. Si la planification des interruptions est définie sur FUTURE, aucune action de réparation n'est effectuée immédiatement. Au lieu de cela, Compute Engine planifie une réparation si une erreur est détectée à l'avenir. Une fois la réparation lancée, la VM est mise hors tension. Elle peut rester à l'état PENDING jusqu'à ce que l'hôte soit réparé. La réparation de l'hôte défectueux peut prendre entre 3 et 14 jours, voire plus. En mode "Toute la capacité", les VM TPU ne sont pas migrées vers un autre hôte pendant la réparation. Au lieu de cela, elles sont redémarrées sur le même hôte s'il y a suffisamment de capacité.