Motifs d'échec de l'exécution

Si une exécution échoue, utilisez l'opération GetRun d'API pour récupérer la raison de l'échec.

Passez en revue la raison de l'échec pour vous aider à résoudre les problèmes liés à l'échec de l'exécution. Le tableau suivant répertorie les raisons de chaque échec avec une description de l'erreur.

Motif de l’échec	Description de l'erreur.
ASSUME_ROLE_FAILED	HealthOmics n'est pas autorisé à assumer ce rôle. Spécifiez le HealthOmics principal dans la relation de confiance pour le rôle.
ERREUR CANNOT_START_CONTAINER_ERROR	Impossible de démarrer la tâche de flux de travail :name, id : ID conteneur à l'aide de l'image :image name. Vérifiez que l'image est valide et réessayez.
CANNOT_START_CONTAINER_SIZE_ERROR	Impossible de démarrer la tâche de flux de travail :name, id : ID conteneur à l'aide de l'image :image name. Assurez-vous que la taille de l'image est inférieure à 45 GiB (95 GiB pour une instance GPU) et réessayez.
ECR_PERMISSION_ERROR	HealthOmics n'est pas autorisé à accéder à l'URI de l'image. Vérifiez que le référentiel privé Amazon ECR existe et qu'il a accordé l'accès au principal de HealthOmics service.
ECHEC D'EXPORTATION	L'exportation a échoué. Vérifiez que le compartiment de sortie existe et que le rôle d'exécution dispose d'une autorisation d'écriture sur le compartiment.
SYSTÈME_DE_FICHIER_OUT_OF_SPACE	Le système de fichiers ne dispose pas de suffisamment d'espace. Augmentez la taille du système de fichiers et lancez-le de nouveau.
ECHEC DE VÉRIFICATION_D'IMAGE	Impossible de vérifier l'imageimage name. Pour corriger le problème, essayez de récupérer l'image, puis redirigez-la vers votre référentiel ECR.
ECHEC DE L'IMPORTATION	L'importation a échoué. Vérifiez que le fichier d'entrée existe et que le rôle d'exécution peut accéder à l'entrée.
RESOURCE_OMICS_STORAGE_INACTIVE	L'URI HealthOmics de stockage n'est pas à l'état ACTIF. Activez le set de lecture et réessayez. Pour en savoir plus sur l'activation des ensembles de lecture, consultezL'activation de la lecture s'active HealthOmics.
URI D'ENTRÉE INTROUVABLE	L'URI fourni n'existe pas :uri. Vérifiez que le chemin URI existe et confirmez que le rôle peut accéder à l'objet.
L'INSTANCE_RESERVATION_A ÉCHOUÉ	La capacité d'instance est insuffisante pour terminer l'exécution du flux de travail. Attendez et réessayez d'exécuter le flux de travail. Pour en savoir plus sur les mesures d'atténuation des erreurs liées à l'échec de réservation d'instance, consultezAtténuer les erreurs INSTANCE_RESERVATION_FAILED.
URI D'IMAGE ECR_ECR NON VALIDE	La structure URI de l'image Amazon ECR n'est pas valide. Entrez un URI valide et réessayez.
VALEUR_RESOURCE_DE TÂCHE NON VALIDE	Le GPU, le processeur ou la mémoire requis est soit trop élevé pour la capacité de calcul disponible, soit inférieur à la valeur minimale de 1 pour la tâcheID.
SAISIE_URI NON VALIDE	La structure d'URI n'est pas valideuri. Vérifiez la structure de l'URI et réessayez.
RESSOURCE_D'ENTRÉE_MODIFIÉE	L'URI fourni uri a été modifié après le début de l'exécution. Réessayez d'exécuter.
ERREUR_DE_DE_MEMORY_OUT_DE_MEMORY	La tâche du flux de travail ID a manqué de mémoire. Augmentez la valeur de mémoire dans la définition du flux de travail et recommencez l'exécution.
ÉCHEC DE L'EXÉCUTION DE LA TÂCHE	L'exécution a échoué car la tâche a échoué. Pour corriger l'échec de la tâche, utilisez l'opération GetRunTask d'API et le flux Amazon CloudWatch Logs.
RUN_TIMED_OUT	Délai d'exécution après number quelques minutes.
ERROR DE SERVICE	Une erreur passagère s'est produite dans le service. Réessayez d'exécuter le flux de travail.
TASK_TIMED_OUT	La tâche id a expiré au bout de number quelques secondes.
TAILLE_DE_ENTRÉE NON PRISE EN CHARGE	La taille totale d'entrée est trop élevée. Diminuez la taille de saisie et réessayez.
WORKFLOW_RUN_FAILED	L'exécution du flux de travail a échoué. Consultez le flux de CloudWatch journalisation du moteur Logs : ID pour corriger la panne.
WORKFLOW_VER_VALIDATION_FAILED	HealthOmics ne prend pas en charge la version Nextflow demandée : version --. La dernière version prise en charge estversion. Modifiez votre version de Nextflow en une version compatible et réessayez.
TYPE D'INSTANCE_GPU NON PRIS EN CHARGE	Le type d'instance demandé n'est pas pris en charge dansRegion. Réessayez l'exécution avec un type d'instance GPU pris en charge dans cette région. Les types d'instances disponibles sontGPU instance types.

Atténuer les erreurs INSTANCE_RESERVATION_FAILED

Les instances GPU sont des ressources à la demande qui ne sont pas toujours disponibles immédiatement dans la zone ou la région de disponibilité de votre choix.

Qu'est-ce qui HealthOmics se fait automatiquement

HealthOmics effectue plusieurs optimisations pour votre compte afin de maximiser le succès de l'acquisition de GPU :

• Multi-AZ recherche  : HealthOmics vérifie la capacité du GPU dans plusieurs zones de disponibilité, et pas seulement dans une seule zone de disponibilité.

• Réessais automatiques  : lorsqu'un GPU n'est pas immédiatement disponible, HealthOmics réessaie plusieurs fois pour acquérir de la capacité au fur et à mesure qu'elle devient disponible.

• Conservation du GPU pour toutes les tâches  : lorsque votre flux de travail comporte des tâches séquentielles nécessitant un GPU, HealthOmics conservez le GPU que vous possédez déjà pour les tâches suivantes au lieu de le libérer et de le demander à nouveau, ce qui garantit la réussite des flux de travail GPU en plusieurs étapes.

Les bonnes pratiques supplémentaires suivantes peuvent encore améliorer votre taux de réussite lorsque vous exécutez des GPU-accelerated flux de travail sur HealthOmics :

1. Utilisez des packs d'accélérateurs pour maximiser la flexibilité

   Au lieu de demander un type d'instance de GPU spécifique, utilisez des packs d'accélérateurs qui permettent de HealthOmics sélectionner parmi plusieurs générations de GPU compatibles (par exemple, g4dn, g5, g6). Plus votre flux de travail peut accepter de types de GPU, plus la probabilité de trouver de la capacité disponible est élevée.

   Pour en savoir plus, consultez Accélérateurs de tâches dans une définition de HealthOmics flux de travail. Par exemple :

   • nvidia-t4-a10g-l4s'appuie sur les familles d'instances G4, G5 et G6

   • nvidia-l4-a10gs'appuie sur les familles d'instances G5 et G6

2. Envisagez d'exécuter votre flux de travail dans une autre AWS région

   La disponibilité des GPU varie selon AWS les régions. Si vos exigences en matière de résidence des données le permettent, envisagez d'exécuter GPU-intensive des flux de travail dans une autre région où la capacité peut être plus facilement disponible. Pour en savoir plus sur les régions prises en charge, consultez la section Quotas de service et points de terminaison pour AWS HealthOmics.

3. Configurer le repli des ressources (flux de travail WDL uniquement)

   Pour les flux de travail WDL, la omicsResourceFallbackOrder directive vous permet de définir une liste ordonnée de profils de ressources (GPU ou CPU) par tâche. Si votre type d'accélérateur préféré n'est pas disponible, essaie HealthOmics automatiquement le type d'accélérateur ou le processeur suivant au lieu d'échouer. Vous pouvez également spécifier la durée pendant HealthOmics laquelle vous devez rechercher un GPU. Cas d’utilisation :

   • Solution de secours GPU à GPU  : essayez d'abord votre accélérateur préféré, puis revenez à une alternative (par exemple, essayez d'nvidia-l40sabord, ensuitenvidia-l4).

   • Solution de secours GPU à CPU  : ajoutez un CPU-only profil final pour que la tâche soit terminée même si aucune capacité GPU n'est disponible.

   Note

   La omicsResourceFallbackOrder directive n'est actuellement prise en charge que pour les flux de travail WDL. Le support de Nextflow est prévu.

   Pour en savoir plus, consultez Configuration avancée des ressources.

Conseils pour les courses qui ne répondent pas

Lors du développement de nouveaux flux de travail, des exécutions ou des tâches spécifiques peuvent être « bloquées » ou « bloquées » en cas de problème avec votre code et si les tâches ne parviennent pas à quitter correctement les processus. Cela peut être difficile à résoudre et à détecter, car il est normal que les tâches s'exécutent pendant de longues périodes. Pour prévenir et identifier les exécutions qui ne répondent pas, suivez les bonnes pratiques suggérées dans les sections suivantes.

Meilleures pratiques pour éviter les courses sans réponse

• Assurez-vous de fermer tous les fichiers ouverts dans votre code de tâche. L'ouverture d'un trop grand nombre de fichiers peut parfois entraîner des problèmes de thread dans les moteurs de flux de travail.

• Les processus d'arrière-plan créés par une tâche de flux de travail doivent se terminer à la fin de la tâche. Toutefois, si un processus en arrière-plan ne se termine pas correctement, vous devez l'arrêter explicitement dans votre code de tâche.

• Assurez-vous que vos processus ne se déroulent pas en boucle sans être interrompus. Cela peut entraîner une exécution qui ne répond pas et nécessite une modification du code de définition de votre flux de travail pour être résolu.

• Fournissez une allocation de mémoire et de processeur appropriée à vos tâches. Analysez les CloudWatch journaux ou utilisez les informations Exécuter l'analyseur relatives aux exécutions réussies de votre flux de travail pour vérifier que vous disposez d'une allocation de calcul optimale. Utilisez le headroom paramètre Run Analyzer pour ajouter une marge de manœuvre supplémentaire, afin de vous assurer que les processus disposent de ressources suffisantes pour être exécutés. Prévoyez au moins 5 % de marge de manœuvre dans la mémoire et le processeur alloués, afin de tenir compte des processus du système d'exploitation en arrière-plan.

  • En outre, augmentez la taille de la bande passante de l'instance si celle-ci nécessite un débit plus élevé. Les instances Amazon EC2 dotées de moins de 16 vCPU (taille 4xl et inférieure) peuvent connaître une explosion de débit. Pour plus d'informations sur le débit des instances Amazon EC2, consultez la section Bande passante d'instance disponible sur Amazon EC2.

• Assurez-vous d'utiliser la bonne taille de système de fichiers pour vos exécutions. Pour les exécutions qui ne répondent pas et qui utilisent le stockage d'exécution statique, envisagez d'augmenter l'allocation de stockage d'exécution statique afin d'augmenter le débit d'E/S et la capacité de stockage sur le système de fichiers. Analysez le manifeste d'exécution pour connaître la capacité de stockage maximale du système de fichiers, utilisez l'analyseur d'exécution pour déterminer si l'allocation du système de fichiers doit être augmentée.

Meilleures pratiques pour détecter les courses qui ne répondent pas

• Lorsque vous développez de nouveaux flux de travail, utilisez un groupe d'exécution dont la limite de temps d'exécution maximale est définie pour détecter le code incontrôlable. Par exemple, si une course doit prendre 1 heure, placez-la dans un groupe de courses dont le temps expire au bout de 2 ou 3 heures (ou une période différente en fonction de votre cas d'utilisation) pour détecter les tâches incontrôlables. Appliquez également une mémoire tampon pour tenir compte de la variation des temps de traitement.

• Configurez une série de groupes d'exécution avec différentes limites d'exécution maximales. Par exemple, vous pouvez attribuer des séries courtes à un groupe d'exécutions qui met fin aux séries au bout de quelques heures, et à un groupe de séries longues qui met fin aux séries au bout de quelques jours, en fonction de la durée prévue de votre flux de travail.

• HealthOmics a une limite de service de durée d'exécution maximale par défaut de 604 800 secondes, soit 7 jours, qui est ajustable via une demande dans l'outil de quotas. Ne demandez une augmentation de la limite de service de ce quota que si vous avez des courses d'une durée d'environ une semaine. Si vous avez une combinaison de courses courtes et longues et que vous n'utilisez pas de groupes de courses, pensez à placer les courses de longue durée dans un compte distinct avec une limite de service de durée maximale de course plus élevée.

• Consultez les CloudWatch journaux pour détecter les tâches susceptibles de ne pas répondre. Si une tâche génère normalement des instructions de journal régulières et ne l'a pas fait pendant une période prolongée, la tâche est probablement bloquée ou bloquée.

Que faire si vous rencontrez une course qui ne répond pas

• Annulez la course pour éviter des frais supplémentaires.

• Inspectez les journaux des tâches pour vérifier si des processus ne se sont pas terminés correctement.

• Inspectez les carnets du moteur pour identifier tout comportement anormal du moteur.

• Comparez les journaux des tâches et du moteur de l'exécution qui ne répond pas à ceux des exécutions identiques effectuées avec succès. Cela peut aider à identifier les différences susceptibles d'être à l'origine du comportement insensible.

• Si vous ne parvenez pas à déterminer la cause première, soumettez une demande d'assistance et incluez les éléments suivants :

  • ARN de l'exécution bloquée et ARN d'une exécution identique qui s'est terminée avec succès.

  • Journaux du moteur (disponibles une fois que l'exécution a été annulée ou échoue)

  • Journaux des tâches pour la tâche qui ne répond pas. Nous n'avons pas besoin de journaux de tâches pour toutes les tâches du flux de travail à des fins de dépannage.