View a markdown version of this page

Configurazione avanzata delle risorse - AWS HealthOmics
Come funzionaCasi d’usoTask-level campi di runtimeEsempio WDLPer-profile riferimento sul campoComportamento del timeoutVariabili di ambienteCriteri di convalidaInterazione con i tentativiBest practiceLimitazioni

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Configurazione avanzata delle risorse

Con la omicsResourceFallbackOrder direttiva puoi dichiarare un elenco ordinato di profili di risorse (ad esempio, acceleratore e CPU) per un'attività all'interno del tuo flusso di lavoro. Si specifica questa direttiva a livello di attività. HealthOmics cerca ogni profilo nell'ordine specificato in base alla disponibilità da prenotare. Se la capacità non è disponibile entro il timeout di attesa, HealthOmics passa al profilo di risorsa successivo nell'elenco.

Ciò è utile quando la capacità dell'acceleratore preferita (ad esempio, G6e connvidia-l40s) non è disponibile e preferisci ricorrere a un tipo di acceleratore diverso o a una CPU invece di interrompere l'esecuzione.

Come funziona

  1. Nella direttiva si definisce un elenco ordinato di profili di risorse. omicsResourceFallbackOrder

  2. In fase di esecuzione, HealthOmics tenta di riservare la capacità per il primo profilo dell'elenco.

  3. Se la capacità non è disponibile entro il periodo di attesa, HealthOmics passa al profilo successivo.

  4. L'operazione viene eseguita sul profilo con esito positivo per primo.

  5. Se tutti i profili dell'elenco hanno esito negativo, l'operazione ha esito negativo e motivato. ALL_PROFILES_INSTANCE_RESERVATION_FAILED Non verrà applicato alcun nuovo tentativo del motore quando tutti i profili non sono disponibili.

Nota

omicsResourceFallbackOrdersostituisce i soliti campiacceleratorType, acceleratorCount cpumemory, e omicsResourceWaitTimeoutInMin dell'attività. Questi non devono essere fissati al massimo livello quando è presente la direttiva.

Casi d’uso

Scenario Description
Soluzione da GPU a GPU Elenca i tipi di acceleratore (o GPU) in ordine di priorità. Ad esempio, prova nvidia-l40s prima, poi torna a. nvidia-l4 Non sono necessarie modifiche ai comandi se il carico di lavoro è lo stesso per tutti i tipi di acceleratore.
Fallback da GPU a CPU Aggiungi un profilo finale che omette acceleratorType il fallback. CPU-only Usa la variabile di AWS_HEALTHOMICS_RESOURCE_TYPE ambiente per suddividere il comando in base al tipo di risorsa.

Task-level campi di runtime

Quando si utilizzanoomicsResourceFallbackOrder, i campi di runtime a livello di attività si dividono in due set:

  • Per-profile campi (acceleratorType,acceleratorCount,, cpumemory,omicsResourceWaitTimeoutInMin): configurabili indipendentemente per ogni profilo nell'elenco.

  • Campi condivisi (tutti gli altri campi di runtime, ad esempiodocker,maxRetries): impostati una volta al livello superiore e si applicano allo stesso modo a tutti i profili.

Esempio WDL

Il seguente task WDL esegue la ricerca per nvidia-l40s prima cosa (in attesa fino a 45 minuti per la capacità), quindi nvidia-l4 (finestra di attesa predefinita), quindi torna a un CPU-only profilo (32 vCPU, 128 GiB) se nessuno dei due tipi di acceleratore è disponibile.

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"}
    ]
  }
}

In questo esempio, AWS_HEALTHOMICS_RESOURCE_TYPE indica al comando quale percorso di risorsa è stato selezionato (ad esempio, o). "nvidia-l40s" "cpu"

Nota

L'immagine Docker deve supportare sia i percorsi di codice dell'acceleratore che quelli della CPU se l'ordine di fallback contiene un profilo CPU. Assicurati che il contenitore includa gli strumenti necessari per tutti i profili di risorse nell'elenco.

Per-profile riferimento sul campo

Ogni voce dell'omicsResourceFallbackOrderelenco è una mappa che descrive un profilo di risorsa. Tutti i campi sono opzionali; un profilo può essere una specifica parziale. Ogni profilo deve utilizzare chiavi tra virgolette (stringa).

Campo Tipo Impostazione predefinita se omessa Note
acceleratorType Stringa Se non specificato, il profilo viene considerato CPU Deve essere uno dei 7 tipi di acceleratori supportati. Consulta Acceleratori di attività in una definizione del flusso di lavoro HealthOmics. Ometti questo campo per specificare un CPU-only profilo. Per il profilo CPU, non impostarlo "" su.
acceleratorCount Numero intero Campo assente quando acceleratorType è anche assente Deve essere specificato insieme a. acceleratorType Un profilo non può avere uno senza l'altro.
cpu Integer o Float 1 vCPU o tipo di istanza GPU predefinito se un profilo GPU lo omette Arrotondato alla vCPU intera più vicina (minimo 1). Stesso supporto frazionario della direttiva di primo livelloruntime.cpu.
memory Stringa (ad esempio,) "32 GiB" 1 GiB o un tipo di istanza GPU predefinito se un profilo GPU lo omette Stesso formato della direttiva di primo livello. runtime.memory
omicsResourceWaitTimeoutInMin Numero intero 20 minuti per il pacchetto di acceleratori a GPU singola e 30 minuti per i pacchetti di acceleratori multi-GPU. Questi sono anche i valori minimi consigliati. Non vi sono limiti superiori. Controlla la durata della HealthOmics ricerca di un profilo prima di passare al profilo successivo. Consulta Comportamento del timeout.
Nota

I campi omessi assumono il valore predefinito, non i valori ereditati da un profilo precedente nell'elenco. Un campo escluso da un profilo assume il valore predefinito documentato (come indicato nella tabella precedente), non un valore copiato da un profilo precedente nell'elenco.

Comportamento del timeout

omicsResourceWaitTimeoutInMincontrolla quanto tempo HealthOmics attende la capacità dell'acceleratore su un determinato profilo prima di passare a quello successivo.

  • Per-profile, non globale. Ogni profilo dell'acceleratore può specificare il proprio timeout. Configura un'attesa più lunga per un acceleratore di fascia alta preferito e un'attesa più breve per un tipo di fallback.

  • Minimo consigliato di 20 minuti. I valori inferiori a 20 minuti (30 per i bundle multi-GPU) sono accettati ma generano un avviso di convalida.

  • Il timeout avanza, non fallisce. Allo scadere del timeout, si HealthOmics passa al profilo successivo: l'attività non fallisce. L'errore si verifica solo dopo che tutti i profili sono esauriti.

  • Non applicabile ai CPU-only profili. Un profilo CPU non ha limiti di capacità. Ometti omicsResourceWaitTimeoutInMin nel profilo CPU finale.

  • I tentativi ricevono una nuova finestra di timeout. Ogni tentativo di OOM o errore di servizio avvia omicsResourceWaitTimeoutInMin una finestra completa sullo stesso profilo, anziché ereditare il tempo già impiegato da un tentativo precedente.

Variabili di ambiente

HealthOmics imposta la seguente variabile di ambiente nel contenitore delle attività in modo che il comando possa ramificarsi in base al profilo di risorsa allocato:

Variabile Valore Valori di esempio
AWS_HEALTHOMICS_RESOURCE_TYPE Il acceleratorType nome del profilo attivo o "cpu" per un CPU-only profilo. "nvidia-l40s", "nvidia-l4", "cpu"

Criteri di convalida

HealthOmics convalida quanto segue al momento della creazione del flusso di lavoro e ricontrolla in fase di esecuzione dell'attività. Tutte le regole rifiutano il flusso di lavoro o l'attività se non diversamente indicato.

  1. Non può essere combinato con le direttive relative alle singole risorse. Se omicsResourceFallbackOrder è specificato, il livello superiore acceleratorTypeacceleratorCount, cpumemory, e non omicsResourceWaitTimeoutInMin deve essere specificato nella stessa attività.

  2. Deve essere un elenco. omicsResourceFallbackOrderdeve essere scritto come una serie di profili.

  3. Non può essere vuoto. L'elenco deve contenere almeno un profilo.

  4. Le chiavi tra virgolette sono obbligatorie. Ad esempio{"acceleratorType": "nvidia-l4", "acceleratorCount": 1}, il nome di ogni campo deve essere una stringa tra virgolette. Le chiavi Bareword hanno esito negativo nella convalida.

  5. Non-empty profili. Un profilo vuoto ({}) non è consentito.

  6. acceleratorTypee acceleratorCount andate insieme. Un profilo che ne imposta uno deve impostare l'altro. Un profilo CPU deve omettere entrambi.

  7. Solo tipi di acceleratori supportati. acceleratorTypedeve essere un tipo di acceleratore supportato o omesso (profilo CPU). La stringa vuota non "" è accettata.

  8. Timeout minimo di attesa. omicsResourceWaitTimeoutInMinil valore consigliato è ≥ 20 minuti (≥ 30 per i bundle multi-GPU).

  9. Profili duplicati (solo avviso). I profili duplicati sono consentiti ma generano un avviso. Valuta invece la possibilità di aumentare omicsResourceWaitTimeoutInMin il profilo precedente.

  10. Campi non riconosciuti rifiutati. Sono consentiti solo i cinque campi per profilo elencati sopra.

  11. Tipi corretti. Ad esempio, cpu deve essere un numero, non una stringa.

  12. Al massimo un profilo CPU. È consentito un solo profilo acceleratorType omesso.

  13. Massimo 10 profili per attività.

Interazione con i tentativi

In caso di errori Out-of-Memory (OOM) e di servizio (5xx esclusiALL_PROFILES_INSTANCE_RESERVATION_FAILED), HealthOmics riprova l'operazione come segue:

  • I tentativi vengono eseguiti all'interno del profilo attualmente attivo che in precedenza era stato prenotato con successo.

  • I tentativi non passano mai al profilo successivo nell'ordine alternativo.

  • Un nuovo tentativo che si esaurisce non ha esito positivomaxRetries.

Per ulteriori informazioni sui tentativi di esecuzione delle attività, vedere. HealthOmics Ritentativi di attività

Nota

Se tutti i profili sono esauriti al primo tentativo del motore senza alcuna prenotazione di istanza, il motore fallisce l'operazione e successivamente lo stato di esecuzione con esito negativo. ALL_PROFILES_INSTANCE_RESERVATION_FAILED Anche se hai configurato i tentativi, HealthOmics non riprova con questo codice di errore. Ti consigliamo di modificare il tuo in modo appropriato. omicsResourceWaitTimeoutInMin

Best practice

  • Evita i tipi di bundle multi-GPU in ordine alternativo. I tipi di acceleratori che si estendono su più famiglie di istanze (ad esempionvidia-t4-a10g-l4) non sono consigliati all'interno. omicsResourceFallbackOrder Utilizzate invece tipi unifamiliari. Per informazioni dettagliate sui tipi di acceleratori disponibili, vedere. Acceleratori di attività in una definizione del flusso di lavoro HealthOmics

  • Imposta i timeout di attesa appropriati. Per i profili acceleratori ad alta priorità, aumentali omicsResourceWaitTimeoutInMin per avere HealthOmics più tempo per trovare capacità.

  • Posiziona i profili CPU per ultimi. Se includi un CPU-only fallback, deve essere l'ultima voce, quindi gli acceleratori sono preferiti quando disponibili.

  • Usa immagini di contenitori con più architetture. Quando utilizzi il fallback da GPU a CPU, assicurati che l'immagine Docker supporti entrambi GPU-accelerated i percorsi del codice. CPU-only

Limitazioni

  • omicsResourceFallbackOrdernon è supportato all'interno dei blocchi. scatter È disponibile solo a livello di attività.

  • Alla data di lancio di GA è supportato solo WDL. È previsto il supporto per Nextflow e CWL.

  • Instance-type i nomi (ad esempioomics.g6e.4xlarge) non sono accettati come valori di risorse. È necessario utilizzare la sintassi dei campi per profilo descritta in questa pagina.