Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

# Configuration avancée des ressources
<a name="advanced-resource-configuration"></a>

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 avec`nvidia-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
<a name="advanced-resource-configuration-how-it-works"></a>

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

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

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

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

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

**Note**  
**omicsResourceFallbackOrder**remplace les **omicsResourceWaitTimeoutInMin** champs habituels**acceleratorType**,, **acceleratorCount** **cpu****memory**, 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
<a name="advanced-resource-configuration-use-cases"></a>


| 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
<a name="advanced-resource-configuration-runtime-fields"></a>

Lors de l'utilisation**omicsResourceFallbackOrder**, les champs d'exécution au niveau des tâches sont divisés en deux ensembles :
+ **Per-profile champs ** (**acceleratorType**,**acceleratorCount**, **cpu****memory**,**omicsResourceWaitTimeoutInMin**) : configurables indépendamment pour chaque profil de la liste.
+ **Champs partagés ** (tous les autres champs d'exécution, tels que**docker**,**maxRetries**) : définis une fois au niveau supérieur et appliqués de la même manière à tous les profils.

## Exemple WDL
<a name="advanced-resource-configuration-wdl-example"></a>

La tâche WDL suivante recherche d'`nvidia-l40s`abord (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
<a name="advanced-resource-configuration-field-reference"></a>

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](task-accelerators.md). 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](#advanced-resource-configuration-timeout-behavior). | 

**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
<a name="advanced-resource-configuration-timeout-behavior"></a>

**omicsResourceWaitTimeoutInMin**contrô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
<a name="advanced-resource-configuration-environment-variables"></a>

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
<a name="advanced-resource-configuration-validation"></a>

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'**omicsResourceFallbackOrder**il est spécifié, le niveau supérieur**acceleratorType**,**acceleratorCount**, **cpu****memory**, et ne **omicsResourceWaitTimeoutInMin** doit pas être spécifié dans la même tâche.

1. **Ça doit être une liste. ****omicsResourceFallbackOrder**doit être écrit sous la forme d'un tableau de profils.

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

1. **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.

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

1. ****acceleratorType**et **acceleratorCount** allez-y ensemble. ** Un profil qui définit l'un doit définir l'autre. Un profil de processeur doit omettre les deux.

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

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

1. **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.

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

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

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

1. **Maximum de 10 profils par tâche. **

## Interaction avec les nouvelles tentatives
<a name="advanced-resource-configuration-retries"></a>

Pour les erreurs Out-of-Memory (OOM) et de service (à l'exception de 5xx`ALL_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, consultez[Nouvelles tentatives de tâches](monitoring-runs.md#run-status-task-retries).

**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'état`ALL_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
<a name="advanced-resource-configuration-best-practices"></a>
+ **É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 exemple`nvidia-t4-a10g-l4`) ne sont pas recommandés à l'intérieur**omicsResourceFallbackOrder**. Utilisez plutôt des types unifamiliaux. Pour plus de détails sur les types d'accélérateurs disponibles, consultez[Accélérateurs de tâches dans une définition de HealthOmics flux de travail](task-accelerators.md).
+ **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
<a name="advanced-resource-configuration-limitations"></a>
+ **omicsResourceFallbackOrder**n'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 exemple`omics.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.