Erweiterte Ressourcenkonfiguration

Mit der omicsResourceFallbackOrder Direktive können Sie eine geordnete Liste von Ressourcenprofilen (z. B. Beschleuniger und CPU) für eine Aufgabe innerhalb Ihres Workflows deklarieren. Sie geben diese Anweisung auf Aufgabenebene an. HealthOmics sucht nach den einzelnen Profilen in der von Ihnen angegebenen Reihenfolge, ob die Verfügbarkeit reserviert werden kann. Wenn innerhalb des Warte-Timeouts keine Kapazität verfügbar ist, HealthOmics wechselt zum nächsten Ressourcenprofil in der Liste.

Dies ist nützlich, wenn Ihre bevorzugte Beschleunigerkapazität (z. B. G6e mitnvidia-l40s) nicht verfügbar ist und Sie lieber auf einen anderen Beschleunigertyp oder auf eine CPU zurückgreifen möchten, anstatt den Lauf fehlzuschlagen.

Funktionsweise

1. In der Direktive definieren Sie eine geordnete Liste von RessourcenprofilenomicsResourceFallbackOrder.

2. HealthOmics Versucht zur Laufzeit, Kapazität für das erste Profil in der Liste zu reservieren.

3. Wenn innerhalb des Wartezeitraums keine Kapazität verfügbar ist, HealthOmics wechselt zum nächsten Profil.

4. Die Aufgabe wird auf dem Profil ausgeführt, das zuerst erfolgreich ist.

5. Wenn alle Profile in der Liste fehlschlagen, schlägt die Aufgabe aus gutem Grund fehl. ALL_PROFILES_INSTANCE_RESERVATION_FAILED Wenn alle Profile nicht verfügbar sind, werden keine Engine-Wiederholungen durchgeführt.

Anmerkung

omicsResourceFallbackOrderersetzt die normalen omicsResourceWaitTimeoutInMin FelderacceleratorType, acceleratorCount cpumemory, und der Aufgabe. Diese dürfen nicht auf der obersten Ebene festgelegt werden, wenn die Richtlinie vorliegt.

Anwendungsfälle

Szenario	Description
Fallback von GPU zu GPU	Listet die Beschleunigertypen (oder GPU-Typen) in der Reihenfolge ihrer Priorität auf. Versuchen Sie es beispielsweise nvidia-l40s zuerst und greifen Sie dann auf zurücknvidia-l4. Wenn die Arbeitslast bei allen Beschleunigertypen gleich ist, sind keine Befehlsänderungen erforderlich.
Fallback zwischen GPU und CPU	Fügen Sie ein endgültiges Profil hinzu, bei dem kein Fallback acceleratorType vorgesehen CPU-only ist. Verwenden Sie die AWS_HEALTHOMICS_RESOURCE_TYPE Umgebungsvariable, um den Befehl nach Ressourcentyp zu verzweigen.

Task-level Laufzeitfelder

Bei Verwendung werden omicsResourceFallbackOrder Laufzeitfelder auf Aufgabenebene in zwei Gruppen aufgeteilt:

• Per-profile fields (acceleratorType,,acceleratorCount, cpumemory,omicsResourceWaitTimeoutInMin) — unabhängig konfigurierbar für jedes Profil in der Liste.

• Gemeinsam genutzte Felder (alle anderen Laufzeitfelder, z. B.docker,maxRetries) — werden einmal auf der obersten Ebene festgelegt und gelten auf dieselbe Weise für jedes Profil.

WDL-Beispiel

Die folgende WDL-Aufgabe sucht nvidia-l40s zuerst (wartet bis zu 45 Minuten auf Kapazität), dann nvidia-l4 (Standard-Wartefenster) und fällt dann auf ein CPU-only Profil zurück (32 vCPUs, 128 GiB), wenn keiner der Beschleunigertypen verfügbar ist.

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 diesem Beispiel AWS_HEALTHOMICS_RESOURCE_TYPE teilt es dem Befehl mit, welcher Ressourcenpfad ausgewählt wurde (z. B. "nvidia-l40s" oder). "cpu"

Anmerkung

Das Docker-Image muss sowohl Beschleuniger- als auch CPU-Codepfade unterstützen, wenn Ihre Fallback-Reihenfolge ein CPU-Profil enthält. Stellen Sie sicher, dass Ihr Container die erforderlichen Tools für alle Ressourcenprofile in der Liste enthält.

Per-profile Referenz zum Feld

Jeder Eintrag in der omicsResourceFallbackOrder Liste ist eine Karte, die ein Ressourcenprofil beschreibt. Alle Felder sind optional; ein Profil kann eine Teilspezifikation sein. Jedes Profil muss Schlüssel (Zeichenfolge) in Anführungszeichen verwenden.

Feld	Typ	Standard, wenn weggelassen	Hinweise
acceleratorType	Zeichenfolge	Wenn nicht angegeben, wird das Profil als CPU betrachtet	Muss einer der 7 unterstützten Beschleunigertypen sein. Siehe Taskbeschleuniger in einer Workflow-Definition HealthOmics. Lassen Sie dieses Feld aus, um ein CPU-only Profil anzugeben. Stellen Sie es für das CPU-Profil nicht auf "" ein.
acceleratorCount	Ganzzahl	Feld fehlt, wenn acceleratorType es auch fehlt	Muss zusammen mit angegeben werdenacceleratorType. Ein Profil kann nicht das eine ohne das andere haben.
cpu	Integer oder Float	1 vCPU oder GPU-Instanztyp, wenn er in einem GPU-Profil weggelassen wird	Auf die nächste ganze vCPU aufgerundet (mindestens 1). Gleiche fraktionale Unterstützung wie bei der Direktive der obersten Ebeneruntime.cpu.
memory	Zeichenfolge (zum Beispiel) "32 GiB"	1 GiB oder ein GPU-Instanztyp, wenn er in einem GPU-Profil weggelassen wird	Dasselbe Format wie die Direktive der obersten Ebene. runtime.memory
omicsResourceWaitTimeoutInMin	Ganzzahl	20 Minuten für ein Single-GPU-Beschleunigerpaket und 30 Minuten für Multi-GPU-Beschleunigerpakete. Dies sind ebenfalls empfohlene Mindestwerte.	Es gibt keine Obergrenze. Steuert, wie lange HealthOmics nach einem Profil gesucht wird, bevor zum nächsten Profil gewechselt wird. Siehe Timeout-Verhalten.

Anmerkung

Ausgelassene Felder nehmen den Standardwert an, nicht die Werte, die von einem früheren Profil in der Liste übernommen wurden. Ein Feld, das in einem Profil weggelassen wird, erhält seinen dokumentierten Standardwert (wie in der obigen Tabelle angegeben), nicht einen Wert, der aus einem früheren Profil in der Liste kopiert wurde.

Timeout-Verhalten

omicsResourceWaitTimeoutInMinsteuert, wie lange bei einem bestimmten Profil auf die Beschleunigerkapazität HealthOmics gewartet wird, bevor zum nächsten Profil gewechselt wird.

• Per-profile, nicht global. Jedes Beschleunigerprofil kann seinen eigenen Timeout angeben. Konfigurieren Sie eine längere Wartezeit für einen bevorzugten High-End-Beschleuniger und eine kürzere Wartezeit für einen Fallback-Typ.

• Mindestens 20 Minuten empfohlen. Werte unter 20 Minuten (30 für Pakete mit mehreren GPUs) werden akzeptiert, erzeugen jedoch eine Validierungswarnung.

• Das Timeout schreitet voran, schlägt nicht fehl. Wenn das Timeout abgelaufen ist, HealthOmics wechselt zum nächsten Profil — die Aufgabe schlägt nicht fehl. Ein Fehler tritt erst auf, wenn alle Profile erschöpft sind.

• Gilt nicht für CPU-only Profile. Ein CPU-Profil hat keine Kapazitätsbeschränkungen. Im endgültigen CPU-Profil weglassenomicsResourceWaitTimeoutInMin.

• Bei Wiederholungen wird ein neues Timeout-Fenster angezeigt. Bei jeder Wiederholung eines OOM- oder Servicefehlers wird ein eigenes vollständiges omicsResourceWaitTimeoutInMin Fenster mit demselben Profil gestartet, anstatt die Zeit zu vererben, die bereits bei einem früheren Versuch aufgewendet wurde.

Umgebungsvariablen

HealthOmics legt die folgende Umgebungsvariable im Aufgabencontainer fest, sodass Ihr Befehl auf der Grundlage des zugewiesenen Ressourcenprofils verzweigt werden kann:

Variable	Wert	Beispielwerte
AWS_HEALTHOMICS_RESOURCE_TYPE	Das acceleratorType des aktiven Profils oder "cpu" für ein CPU-only Profil.	"nvidia-l40s", "nvidia-l4", "cpu"

Kriterien für die Validierung

HealthOmics validiert Folgendes bei der Workflow-Erstellung und überprüft es erneut zur Laufzeit der Aufgabe. Alle Regeln lehnen den Workflow oder die Aufgabe ab, sofern nicht anders angegeben.

1. Kann nicht mit einzelnen Ressourcenrichtlinien kombiniert werden. Wenn omicsResourceFallbackOrder angegeben, omicsResourceWaitTimeoutInMin darf die oberste Ebene acceleratorType acceleratorCountcpu,memory, und nicht in derselben Aufgabe angegeben werden.

2. Es muss sich um eine Liste handeln. omicsResourceFallbackOrdermuss als eine Reihe von Profilen geschrieben werden.

3. Darf nicht leer sein. Die Liste muss mindestens ein Profil enthalten.

4. Schlüssel in Anführungszeichen erforderlich. Jeder Feldname muss beispielsweise eine Zeichenfolge in Anführungszeichen sein{"acceleratorType": "nvidia-l4", "acceleratorCount": 1}. Die Überprüfung von Bareword-Schlüsseln ist fehlgeschlagen.

5. Non-empty Profile. Ein leeres Profil ({}) ist nicht zulässig.

6. acceleratorTypeund acceleratorCount geh zusammen. Ein Profil, das das eine festlegt, muss das andere festlegen. Ein CPU-Profil muss beide weglassen.

7. Nur unterstützte Beschleunigertypen. acceleratorTypemuss ein unterstützter Beschleunigertyp sein oder weggelassen werden (CPU-Profil). Eine leere Zeichenfolge "" wird nicht akzeptiert.

8. Minimaler Timeout für die Wartezeit. omicsResourceWaitTimeoutInMinDer empfohlene Wert ist ≥ 20 Minuten (≥ 30 für Pakete mit mehreren GPUs).

9. Doppelte Profile (nur Warnung). Doppelte Profile sind zulässig, führen jedoch zu einer Warnung. Erwägen Sie stattdessen, das frühere Profil zu erhöhenomicsResourceWaitTimeoutInMin.

10. Unbekannte Felder wurden zurückgewiesen. Nur die fünf oben aufgeführten Felder pro Profil sind zulässig.

11. Richtige Typen. Beispielsweise cpu muss es sich um eine Zahl handeln, nicht um eine Zeichenfolge.

12. Höchstens ein CPU-Profil. Nur ein Profil, das ausgelassen wird, acceleratorType ist zulässig.

13. Maximal 10 Profile pro Aufgabe.

Interaktion mit Wiederholungsversuchen

Bei Out-of-Memory (OOM) und Servicefehlern (ohne 5xxALL_PROFILES_INSTANCE_RESERVATION_FAILED) wird die Aufgabe wie HealthOmics folgt wiederholt:

• Wiederholungen erfolgen innerhalb des aktuell aktiven Profils, das zuvor erfolgreich reserviert wurde.

• Wiederholungen wechseln nie zum nächsten Profil in der Ausweichreihenfolge.

• Ein erschöpfender Wiederholungsversuch schlägt fehl. maxRetries

Weitere Hinweise zu Aufgabenwiederholungen finden Sie unter HealthOmics. Die Aufgabe wird erneut versucht

Anmerkung

Wenn alle Profile beim ersten Engine-Versuch ohne Instanzreservierung erschöpft sind, schlägt die Engine bei der Aufgabe fehl und anschließend wird der Vorgang mit dem Status ALL_PROFILES_INSTANCE_RESERVATION_FAILED ausgeführt. Auch wenn Sie Wiederholungsversuche konfiguriert haben, HealthOmics wird der Vorgang bei diesem Fehlercode nicht wiederholt. Wir empfehlen, Ihre omicsResourceWaitTimeoutInMin Einstellungen entsprechend anzupassen.

Bewährte Methoden

• Vermeiden Sie Pakettypen mit mehreren GPUs in der Fallback-Reihenfolge. Accelerator-Typen, die sich über mehrere Instance-Familien erstrecken (z. B.nvidia-t4-a10g-l4), werden intern nicht empfohlenomicsResourceFallbackOrder. Verwenden Sie stattdessen Typen mit nur einer Familie. Einzelheiten zu den verfügbaren Beschleunigertypen finden Sie unterTaskbeschleuniger in einer Workflow-Definition HealthOmics.

• Stellen Sie entsprechende Warte-Timeouts ein. Erhöhen Sie bei Beschleunigerprofilen mit hoher Priorität die Erhöhung, omicsResourceWaitTimeoutInMin um HealthOmics mehr Zeit zum Auffinden der Kapazität zu haben.

• Platzieren Sie die CPU-Profile an letzter Stelle. Wenn Sie einen CPU-only Fallback hinzufügen, muss dies der letzte Eintrag sein, sodass Beschleuniger bevorzugt werden, sofern verfügbar.

• Verwenden Sie Container-Images mit mehreren Architekturen. Wenn Sie GPU-CPU-Fallback verwenden, stellen Sie sicher, dass Ihr Docker-Image GPU-accelerated sowohl als auch CPU-only Codepfade unterstützt.

Einschränkungen

• omicsResourceFallbackOrderwird innerhalb scatter von Blöcken nicht unterstützt. Sie ist nur auf Aufgabenebene verfügbar.

• Ab dem Veröffentlichungsdatum von GA wird nur WDL unterstützt. Nextflow- und CWL-Unterstützung ist geplant.

• Instance-type Namen (z. B.omics.g6e.4xlarge) werden nicht als Ressourcenwerte akzeptiert. Sie müssen die auf dieser Seite beschriebene Feldsyntax pro Profil verwenden.