Problèmes connus

Cette page décrit les problèmes connus que vous pourriez rencontrer lors de l'utilisation de Batch.

Si vous avez besoin d'aide supplémentaire pour utiliser Batch, consultez la documentation Dépannage ou Obtenir de l'aide.

Il est possible que Pub/Sub n'envoie pas de notifications pour les états intermédiaires lors de changements rapides.

Il est possible que Pub/Sub n'envoie pas de notifications pour tous les états intermédiaires lorsqu'un job ou une tâche change très rapidement. Par exemple, supposons qu'une tâche passe rapidement de l'état ASSIGNED à l'état RUNNING, puis à l'état FAILED. Dans ce cas, il est possible que vous ne receviez pas de notification indiquant que la tâche a atteint l'état RUNNING.

Pour atténuer ce problème, nous vous recommandons d'afficher les événements d'état au lieu des notifications Pub/Sub lorsque vous souhaitez consulter l'historique complet des états d'un job ou d'une tâche.

Pour en savoir plus sur les notifications Pub/Sub, consultez Surveiller l'état des jobs à l'aide des notifications Pub/Sub et de BigQuery.

Les journaux de délai d'attente n'indiquent pas si le délai d'attente de la tâche ou de l'exécutable a été dépassé.

Lorsqu'un job échoue en raison d'un délai avant expiration dépassé, les journaux associés au job n'indiquent pas si l'échec est dû au délai avant expiration de la tâche concernée ou à celui de l'exécutable concerné.

Pour contourner ce problème, définissez des valeurs de délai avant expiration différentes pour les tâches et les exécutables. Vous pouvez ensuite déterminer si un échec est dû au dépassement du délai d'expiration de la tâche ou de l'exécutable concerné en suivant la procédure ci-dessous :

1. Identifier la tâche, l'exécutable et l'heure d'un échec de dépassement du délai.

   1. Affichez les journaux du job.

   2. Recherchez un journal qui mentionne le code de sortie de dépassement du délai d'attente, 50005. Ce journal contient un textPayload semblable au message suivant :

      Task task/JOB_UID-group0-TASK_INDEX/0/0 runnable RUNNABLE_INDEX...exitCode 50005
      

      À partir de ce journal, enregistrez TASK_INDEX comme tâche ayant échoué, RUNNABLE_INDEX comme exécutable ayant échoué et la valeur timestamp du journal comme heure de l'échec du dépassement du délai.

2. Identifiez l'heure de début de la tâche ayant échoué.

   1. Affichez les événements d'état de la tâche ayant échoué.

   2. Recherchez l'événement d'état qui mentionne le message suivant :

      Task state is updated from ASSIGNED to RUNNING
      

      À partir de cet événement d'état, enregistrez le champ eventTime comme heure de début de la tâche ayant échoué.

3. Calculez la durée totale d'exécution de la tâche ayant échoué, \({failedTaskRunTime}\), à l'aide de la formule suivante :

   \[{failedTaskRunTime}={failureTime}-{failedTaskStartTime}\]

   Remplacez les valeurs suivantes :

   • \({failureTime}\) : heure de l'échec du dépassement du délai d'expiration.
   • \({failedTaskStartTime}\) : heure de début de la tâche ayant échoué.

4. Identifiez le délai avant expiration dépassé :

   • Si \({failedTaskRunTime}\) correspond au délai d'expiration que vous avez configuré pour la tâche ayant échoué, cela signifie que le délai d'expiration de cette tâche a été dépassé et a entraîné l'échec.

   • Sinon, le délai d'attente que vous avez configuré pour le runnable ayant échoué a été dépassé et a provoqué l'échec.

Les tâches consommant des réservations peuvent être retardées ou empêchées

Lorsque vous essayez de créer et d'exécuter un job qui consomme des réservations Compute Engine, Batch peut retarder ou empêcher l'exécution du job de manière incorrecte. Plus précisément, Batch exige que les projets disposent de quotas de ressources Compute Engine suffisants, même lorsque ces quotas de ressources sont utilisés par des réservations non consommées.

Pour en savoir plus sur ce problème :

1. Pour en savoir plus sur la manière dont ce problème affecte les jobs et sur le moment où il se produit, consultez Identifier et comprendre ce problème.
2. Pour savoir comment éviter ou résoudre ce problème, consultez Contourner ce problème.

Identifier et comprendre ce problème

Aucun message d'erreur spécifique n'indique ce problème. Ce problème peut se produire dans les circonstances suivantes :

• Si votre projet réserve toutes les ressources pour lesquelles il dispose d'un quota, ce problème empêche l'exécution des tâches qui spécifient ces ressources.

  Par exemple, supposons que votre projet comporte les éléments suivants :

  • Un quota maximal de 16 GPU H100.
  • Une réservation à projet unique non consommée pour deux VM a3-highgpu-8g, qui réserve un total de 16 GPU H100.

  Dans ce scénario, ce problème empêche votre projet de planifier et d'exécuter toute tâche correctement configurée pour consommer l'un des GPU H100 réservés.

• Si votre projet réserve certaines des ressources pour lesquelles il dispose d'un quota, ce problème peut empêcher ou retarder les jobs qui spécifient ces ressources.

  Par exemple, supposons que votre projet comporte les éléments suivants :

  • Un quota maximal de 16 GPU H100.
  • Une réservation à projet unique non consommée pour une VM a3-highgpu-8g, qui réserve un total de huit GPU H100.
  • Une VM a3-highgpu-8g configurée pour ne pas utiliser de réservations et qui est parfois supprimée, puis recréée. (Cette VM utilise huit GPU H100 non réservés lorsqu'elle existe.)

  Dans ce scénario, ce problème permet uniquement à votre projet de planifier et de commencer à exécuter n'importe quel job correctement configuré pour consommer l'un des GPU H100 réservés lorsque la VM a3-highgpu-8g n'existe pas.

Contourner ce problème

Pour contourner ce problème pour un job, ajoutez un libellé avec le nom goog-batch-skip-quota-check et la valeur true au champ labels au niveau du job. Ce libellé permet à Batch d'ignorer la vérification des quotas de ressources de votre projet avant de tenter de créer un job.

Important : Il est déconseillé d'activer le libellé goog-batch-skip-quota-check pour les jobs qui ne peuvent consommer aucune réservation dans votre projet. Par exemple, évitez cette solution de contournement lorsque votre projet ne comporte aucune réservation Compute Engine ou lorsqu'un job nécessite des VM qui ne sont pas compatibles avec ces réservations. Sinon, si les vérifications de quota sont inutilement ignorées par les jobs, vous risquez de rencontrer des échecs pour quota insuffisant inutiles.

Par exemple, pour éviter ou résoudre ce problème pour un job de script de base qui peut consommer des réservations, créez et exécutez un job avec la configuration JSON suivante :

{
  "taskGroups": [
    {
      "taskSpec": {
        "runnables": [
          {
            "script": {
              "text": "echo Hello world from task ${BATCH_TASK_INDEX}"
            }
          }
        ]
      },
      "taskCount": 3
    }
  ],
  "allocationPolicy": {
    "instances": [
      {
        VM_RESOURCES
      }
    ],
  },
  "labels": {
    "goog-batch-skip-quota-check": "true"
  },
  "logsPolicy": {
    "destination": "CLOUD_LOGGING"
  }
}

Remplacez VM_RESOURCES par les ressources de VM correspondant à la réservation que vous souhaitez que le job utilise.

Pour obtenir plus d'instructions, consultez Créer et exécuter un job pouvant consommer des VM réservées et Définir des libellés personnalisés pour le job.

Les jobs peuvent échouer lorsque vous spécifiez des images d'OS de VM Compute Engine (ou personnalisées) avec des noyaux obsolètes.

Un job peut échouer s'il spécifie une image d'OS de VM Compute Engine qui ne dispose pas de la dernière version du noyau. (Ce problème affecte également toutes les images personnalisées basées sur des images d'OS de VM Compute Engine.) Tenez compte de ce problème si vous avez un job qui échoue de manière inattendue et qui spécifie une image d'OS de VM Compute Engine ou une image personnalisée similaire. Bien que ce problème puisse survenir à tout moment pour n'importe quelle image Compute Engine (même la dernière version), nous avons constaté qu'il était principalement répandu pour les images Debian Compute Engine.

Pour en savoir plus sur ce problème :

Remarque : Si votre job utilise des GPU, consultez également Les jobs utilisant des GPU et les images d'OS de VM avec des noyaux obsolètes échouent uniquement lors de l'installation automatique des pilotes.

1. Pour en savoir plus sur la manière dont ce problème affecte les jobs et sur le moment où il se produit, consultez Identifier et comprendre ce problème.
2. Pour savoir comment éviter ou résoudre ce problème, consultez Contourner ce problème.

Identifier et comprendre ce problème

Ce problème est dû à une version de noyau obsolète dans l'image de l'OS de la VM, ce qui entraîne le redémarrage de la VM. Lorsqu'un job spécifie une image d'OS de VM qui n'est pas issue de Batch ni basée sur une image Batch, Batch installe les packages requis sur les VM du job après leur démarrage. Les packages requis peuvent varier selon les jobs et changer au fil du temps. Ils peuvent également exiger que l'image de l'OS de votre VM dispose de la dernière version du noyau. Ce problème se produit lorsque la mise à jour de la version de noyau nécessite le redémarrage de la VM, ce qui entraîne l'échec de l'installation du package et du job.

Ce problème peut survenir à tout moment, même si vous utilisez la dernière version d'une image Compute Engine. Si un OS a été mis à jour récemment, en particulier pour des mises à jour imprévisibles comme les correctifs (mises à jour urgentes pour les failles ou les problèmes critiques), il est possible que les images d'OS des VM Compute Engine n'aient pas encore pu réagir à ces modifications. Par exemple, nous avons observé que, pour l'OS Debian, les packages avec des préfixes linux-headers- peuvent être supprimés de manière imprévisible du noyau par des correctifs.

Pour identifier ce problème, nous vous recommandons de consulter les journaux du job afin de vérifier s'il existe des erreurs d'installation liées à l'image de l'OS de votre VM. Par exemple, si votre job utilise une image Debian Compute Engine ou une image personnalisée similaire, nous vous recommandons de rechercher les erreurs liées à l'installation des packages linux-headers- en spécifiant la requête suivante :

labels.job_uid="JOB_UID" AND severity="ERROR" AND textPayload:("failed" "apt" "install" "linux-headers-")

Remplacez JOB_UID par l'ID unique (UID) du job. Pour obtenir l'UID d'un job, décrivez-le. Si cette requête renvoie des résultats, il est possible que ce problème ait un impact sur votre job.

Contourner ce problème

Pour éviter ou résoudre ce problème, nous vous recommandons de procéder comme suit :

1. Dans la mesure du possible, utilisez des images par lot ou des images personnalisées basées sur des images par lot, qui ne sont pas concernées par ce problème.

2. Essayez la dernière version de l'image Compute Engine de votre choix. En général, les versions plus récentes des images Compute Engine sont plus susceptibles d'avoir la dernière version du noyau que les versions antérieures.

3. Choisissez l'une des options suivantes :

   • Essayez un autre OS ou créez une image personnalisée. Par exemple, si la dernière version de Debian 12 ne fonctionne pas, vous pouvez essayer de créer une image personnalisée à partir d'une VM Compute Engine exécutant Debian 12 et que vous avez mise à jour pour utiliser la dernière version du noyau.

   • Si votre job échoue en raison d'erreurs liées à l'installation de packages linux-headers-, vous pouvez essayer d'utiliser l'image d'OS de la VM avec des packages linux-headers- obsolètes. Pour autoriser les packages linux-headers- obsolètes, ajoutez un libellé avec le nom goog-batch-allow-insecure-linux-headers-installation et la valeur true au champ labels au niveau de la tâche.

     Attention : Activez le libellé goog-batch-allow-insecure-linux-headers-installation à vos propres risques. Ce libellé permet à votre tâche de tenter d'installer et d'utiliser des packages linux-headers- archivés. Étant donné que les packages sont obsolètes, ils sont potentiellement non sécurisés et peuvent exposer votre job à des failles ou manquer des mises à jour critiques.

     Par exemple, pour autoriser les packages linux-headers- obsolètes pour un job de script de base qui spécifie une image d'OS de VM, créez et exécutez un job avec la configuration JSON suivante :

     {
       "taskGroups": [
         {
           "taskSpec": {
             "runnables": [
               {
                 "script": {
                   "text": "echo Hello world from task ${BATCH_TASK_INDEX}"
                 }
               }
             ]
           },
           "taskCount": 3
         }
       ],
       "allocationPolicy": {
         "instances": [
           {
             "policy": {
               "bootDisk": {
                 "image": "VM_OS_IMAGE_URI"
               }
             }
           }
         ]
       },
       "labels": {
         "goog-batch-allow-insecure-linux-headers-installation": "true"
       },
       "logsPolicy": {
         "destination": "CLOUD_LOGGING"
       }
     }
     

     Remplacez VM_OS_IMAGE_URI par l'URI de l'image d'OS de VM que vous souhaitez utiliser.

     Pour obtenir plus d'instructions, consultez Définir des libellés personnalisés pour le job et Spécifier l'image d'OS de VM pour un job.

Pour en savoir plus sur les images d'OS de VM, consultez Présentation de l'environnement OS pour les VM d'un job.

Les jobs utilisant des GPU et des images d'OS de VM avec des noyaux obsolètes peuvent échouer uniquement lors de l'installation automatique des pilotes.

Ce problème est étroitement lié au précédent, Échec possible des jobs lors de la spécification d'images d'OS de VM Compute Engine (ou personnalisées) avec des noyaux obsolètes. Plus précisément, les tâches qui spécifient une image d'OS de VM Compute Engine (ou personnalisée) sans le dernier noyau et qui utilisent des GPU peuvent échouer uniquement si vous essayez d'installer automatiquement les pilotes de GPU. Pour ces tâches, vous pouvez également résoudre les échecs en installant manuellement les pilotes de GPU.

Pour en savoir plus sur ce problème et sur la façon de le résoudre, consultez Les jobs peuvent échouer lorsque des images d'OS de VM Compute Engine (ou personnalisées) avec des kernels obsolètes sont spécifiées. Pour en savoir plus sur les GPU, consultez Créer et exécuter un job qui utilise des GPU.