Configuration avancée des ressources

Cette omicsResourceFallbackOrder directive vous permet de déclarer une liste ordonnée de profils de ressources (par exemple, accélérateur et processeur) pour une tâche de votre flux de travail. Vous spécifiez cette directive au niveau de la tâche. HealthOmics recherche chaque profil dans l'ordre que vous avez indiqué pour la disponibilité des réservations. Si la capacité n'est pas disponible dans le délai d'attente, HealthOmics passe au profil de ressource suivant de la liste.

Ceci est utile lorsque votre capacité d'accélérateur préférée (par exemple, G6e avecnvidia-l40s) n'est pas disponible et que vous préférez revenir à un autre type d'accélérateur ou à un processeur au lieu d'échouer.

Comment ça marche

1. Vous définissez une liste ordonnée de profils de ressources dans la omicsResourceFallbackOrder directive.

2. Au moment de l'exécution, HealthOmics essaie de réserver de la capacité pour le premier profil de la liste.

3. Si la capacité n'est pas disponible dans le délai d'attente, HealthOmics passe au profil suivant.

4. La tâche s'exécute sur le profil qui réussit en premier.

5. Si tous les profils de la liste échouent, c'est que la tâche échoue pour causeALL_PROFILES_INSTANCE_RESERVATION_FAILED. Aucune nouvelle tentative de moteur ne sera appliquée lorsque tous les profils ne sont pas disponibles.

Note

omicsResourceFallbackOrderremplace les omicsResourceWaitTimeoutInMin champs habituelsacceleratorType,, acceleratorCount cpumemory, et de la tâche. Ceux-ci ne doivent pas être définis au plus haut niveau lorsque la directive est présente.

Cas d’utilisation

Scénario	Description
Solution de repli GPU à GPU	Répertoriez les types d'accélérateurs (ou GPU) par ordre de priorité. Par exemple, essayez d'nvidia-l40sabord, puis revenez ànvidia-l4. Aucune modification de commande n'est nécessaire si la charge de travail est la même pour tous les types d'accélérateurs.
Solution de repli entre GPU	Ajoutez un profil final qui ne permet pas de revenir acceleratorType en arrière CPU-only . Utilisez la variable d'AWS_HEALTHOMICS_RESOURCE_TYPEenvironnement pour créer une branche de la commande par type de ressource.

Task-level champs d'exécution

Lors de l'utilisationomicsResourceFallbackOrder, les champs d'exécution au niveau des tâches sont divisés en deux ensembles :

• Per-profile champs (acceleratorType,acceleratorCount, cpumemory,omicsResourceWaitTimeoutInMin) : configurables indépendamment pour chaque profil de la liste.

• Champs partagés (tous les autres champs d'exécution, tels quedocker,maxRetries) : définis une fois au niveau supérieur et appliqués de la même manière à tous les profils.

Exemple WDL

La tâche WDL suivante recherche d'nvidia-l40sabord (attente jusqu'à 45 minutes pour la capacité), puis nvidia-l4 (fenêtre d'attente par défaut), puis revient à un CPU-only profil (32 vCPU, 128 GiB) si aucun type d'accélérateur n'est disponible.

task align {
  command <<<
    # Branch based on which resource type was allocated
    if [ "$AWS_HEALTHOMICS_RESOURCE_TYPE" = "cpu" ]; then
      sentieon bwa mem -t 32 ~{reference} ~{fastq}
    else
      pbrun fq2bam --ref ~{reference} --in-fq ~{fastq}
    fi
  >>>

  runtime {
    docker: "my-registry/align-multi-arch:latest"
    maxRetries: 2

    omicsResourceFallbackOrder: [
      {"acceleratorType": "nvidia-l40s", "acceleratorCount": 1,
       "cpu": 8, "memory": "32 GiB",
       "omicsResourceWaitTimeoutInMin": 45},

      {"acceleratorType": "nvidia-l4", "acceleratorCount": 1,
       "cpu": 8, "memory": "32 GiB"},

      {"cpu": 32, "memory": "128 GiB"}
    ]
  }
}

Dans cet exemple, AWS_HEALTHOMICS_RESOURCE_TYPE indique à la commande quel chemin de ressource a été sélectionné (par exemple, "nvidia-l40s" ou"cpu").

Note

L'image Docker doit prendre en charge à la fois les chemins de code de l'accélérateur et du processeur si votre ordre de repli contient un profil de processeur. Assurez-vous que votre conteneur inclut l'outillage requis pour tous les profils de ressources de la liste.

Per-profile référence de champ

Chaque entrée de la omicsResourceFallbackOrder liste est une carte décrivant un profil de ressource. Tous les champs sont facultatifs ; un profil peut être une spécification partielle. Chaque profil doit utiliser des clés entre guillemets (chaînes).

Champ	Type	Par défaut en cas d'omission	Remarques
acceleratorType	Chaîne	Lorsqu'il n'est pas spécifié, le profil est considéré comme un processeur	Il doit s'agir de l'un des 7 types d'accélérateurs pris en charge. Consultez Accélérateurs de tâches dans une définition de HealthOmics flux de travail. Omettez ce champ pour spécifier un CPU-only profil. Pour le profil du processeur, ne le définissez pas sur"".
acceleratorCount	Entier	Champ absent lorsqu'il acceleratorType est également absent	Doit être spécifié avecacceleratorType. Un profil ne peut pas avoir l'un sans l'autre.
cpu	Nombre entier ou flottant	1 vCPU, ou type d'instance GPU par défaut si un profil GPU l'omet	Arrondi au processeur virtuel entier le plus proche (minimum 1). Même support fractionnel que la directive de haut niveau. runtime.cpu
memory	Chaîne (par exemple,"32 GiB")	1 Gio, ou une instance de type GPU par défaut si un profil GPU l'omet	Même format que la runtime.memory directive de niveau supérieur.
omicsResourceWaitTimeoutInMin	Entier	20 minutes pour les packs d'accélérateurs à GPU unique et 30 minutes pour les packs d'accélérateurs multi-GPU. Il s'agit également de valeurs minimales recommandées.	Il n'y a pas de limite supérieure. Contrôle la durée de HealthOmics recherche d'un profil avant de passer au profil suivant. Consultez Comportement en cas d'expiration.

Note

Les champs omis prennent la valeur par défaut, et non les valeurs héritées d'un profil antérieur de la liste. Un champ omis d'un profil reprend sa valeur par défaut documentée (comme indiqué dans le tableau ci-dessus), et non une valeur copiée à partir d'un profil antérieur de la liste.

Comportement en cas d'expiration

omicsResourceWaitTimeoutInMincontrôle le temps d' HealthOmics attente pour obtenir la capacité de l'accélérateur sur un profil donné avant de passer au profil suivant.

• Per-profile, pas mondial. Chaque profil d'accélérateur peut spécifier son propre délai d'attente. Configurez une attente plus longue pour un accélérateur haut de gamme préféré et une attente plus courte pour un type de secours.

• Minimum recommandé de 20 minutes. Les valeurs inférieures à 20 minutes (30 pour les packs multi-GPU) sont acceptées mais génèrent un avertissement de validation.

• Le timeout avance, pas échoue. Une fois le délai écoulé, HealthOmics passe au profil suivant : la tâche n'échoue pas. L'échec ne se produit que lorsque tous les profils sont épuisés.

• Ne s'applique pas aux CPU-only profils. Un profil de processeur n'est soumis à aucune limite de capacité. Omettez omicsResourceWaitTimeoutInMin le profil final du processeur.

• Les nouvelles tentatives reçoivent une nouvelle fenêtre de temporisation. Chaque nouvelle tentative d'erreur OOM ou de service ouvre sa propre omicsResourceWaitTimeoutInMin fenêtre complète sur le même profil, au lieu d'hériter du temps déjà passé lors d'une tentative précédente.

Variables d’environnement

HealthOmics définit la variable d'environnement suivante dans le conteneur de tâches afin que votre commande puisse se ramifier en fonction du profil de ressource alloué :

Variable	Value	Exemples de valeur
AWS_HEALTHOMICS_RESOURCE_TYPE	Le acceleratorType du profil actif, ou "cpu" pour un CPU-only profil.	"nvidia-l40s", "nvidia-l4", "cpu"

Critères de validation

HealthOmics valide les éléments suivants au moment de la création du flux de travail et les revérifie lors de l'exécution de la tâche. Toutes les règles rejettent le flux de travail ou la tâche, sauf indication contraire.

1. Ne peut pas être mélangé avec des directives de ressources individuelles. S'omicsResourceFallbackOrderil est spécifié, le niveau supérieuracceleratorType,acceleratorCount, cpumemory, et ne omicsResourceWaitTimeoutInMin doit pas être spécifié dans la même tâche.

2. Ça doit être une liste. omicsResourceFallbackOrderdoit être écrit sous la forme d'un tableau de profils.

3. Ne peut pas être vide. La liste doit contenir au moins un profil.

4. Clés citées obligatoires. Chaque nom de champ doit être une chaîne entre guillemets, par exemple{"acceleratorType": "nvidia-l4", "acceleratorCount": 1}. Les clés Bareword échouent à la validation.

5. Non-empty profils. Un profil vide ({}) n'est pas autorisé.

6. acceleratorTypeet acceleratorCount allez-y ensemble. Un profil qui définit l'un doit définir l'autre. Un profil de processeur doit omettre les deux.

7. Types d'accélérateurs pris en charge uniquement. acceleratorTypedoit être un type d'accélérateur pris en charge ou omis (profil CPU). Les chaînes vides ne "" sont pas acceptées.

8. Délai d'attente minimum. omicsResourceWaitTimeoutInMinla valeur recommandée est ≥ 20 minutes (≥ 30 pour les packs multi-GPU).

9. Profils dupliqués (avertissement uniquement). Les profils dupliqués sont autorisés mais génèrent un avertissement. Envisagez plutôt d'augmenter omicsResourceWaitTimeoutInMin le profil précédent.

10. Les champs non reconnus ont été rejetés. Seuls les cinq champs par profil répertoriés ci-dessus sont autorisés.

11. Types corrects. Par exemple, cpu il doit s'agir d'un nombre et non d'une chaîne.

12. Au plus un profil de processeur. Un seul profil omet acceleratorType est autorisé.

13. Maximum de 10 profils par tâche.

Interaction avec les nouvelles tentatives

Pour les erreurs Out-of-Memory (OOM) et de service (à l'exception de 5xxALL_PROFILES_INSTANCE_RESERVATION_FAILED), HealthOmics recommencez la tâche comme suit :

• Les nouvelles tentatives ont lieu dans le profil actuellement actif qui a été réservé avec succès.

• Les nouvelles tentatives ne passent jamais au profil suivant dans l'ordre de repli.

• Une nouvelle tentative qui épuise maxRetries échoue.

Pour plus d'informations sur les nouvelles tentatives de tâches HealthOmics, consultezNouvelles tentatives de tâches.

Note

Si tous les profils sont épuisés lors de la première tentative du moteur sans réservation d'instance, le moteur échoue dans la tâche, puis s'exécute avec l'étatALL_PROFILES_INSTANCE_RESERVATION_FAILED. Même si vous avez configuré de nouvelles tentatives, HealthOmics ne réessayez pas pour ce code d'erreur. Nous vous recommandons de l'ajuster en omicsResourceWaitTimeoutInMin conséquence.

Bonnes pratiques

• Évitez les types de bundle multi-GPU dans l'ordre de repli. Les types d'accélérateurs qui couvrent plusieurs familles d'instances (par exemplenvidia-t4-a10g-l4) ne sont pas recommandés à l'intérieuromicsResourceFallbackOrder. Utilisez plutôt des types unifamiliaux. Pour plus de détails sur les types d'accélérateurs disponibles, consultezAccélérateurs de tâches dans une définition de HealthOmics flux de travail.

• Définissez des délais d'attente appropriés. Pour les profils d'accélérateurs hautement prioritaires, augmentez la valeur omicsResourceWaitTimeoutInMin afin de disposer de HealthOmics plus de temps pour trouver de la capacité.

• Placez les profils de processeur en dernier. Si vous incluez une CPU-only solution de secours, il doit s'agir de la dernière entrée. Les accélérateurs sont donc préférés lorsqu'ils sont disponibles.

• Utilisez des images de conteneurs multi-architectures. Lorsque vous utilisez la solution de secours entre GPU et CPU, assurez-vous que votre image Docker prend en charge les deux GPU-accelerated et les chemins de CPU-only code.

Limitations

• omicsResourceFallbackOrdern'est pas pris en charge dans scatter les blocs. Il n'est disponible qu'au niveau des tâches.

• Seule la WDL est prise en charge à la date de lancement de GA. Le support de Nextflow et CWL est prévu.

• Instance-type les noms (par exempleomics.g6e.4xlarge) ne sont pas acceptés comme valeurs de ressources. Vous devez utiliser la syntaxe de champ par profil décrite sur cette page.