Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Kurzlebiger Speicher für Workflow-Aufgaben HealthOmics

HealthOmics bietet temporären Speicher für Workflow-Aufgaben, die das Verzeichnis verwenden. /tmp Dieser Speicher ist temporär und für jede Aufgabe in einem Workflow einzigartig. HealthOmics weist jeder Aufgabeninstanz standardmäßig 16 GiB an temporärem Speicher zu. Sie können die Menge des temporären Speichers, der einzelnen Aufgaben in Ihrer Workflow-Definition zugewiesen ist, auf bis zu 3.072 GiB pro Aufgabe erhöhen. Alle darin gespeicherten Daten werden im Ruhezustand /tmp verschlüsselt.

Wichtigste Vorteile

Wie funktioniert ephemerer Speicher

Wenn Sie den temporären Speicher aktivieren, wird für jede HealthOmics Workflow-Aufgabeninstanz ein dediziertes lokales Speicher-Volume bereitgestellt/tmp. Der temporäre Speicher ist für temporäre Dateien vorgesehen, die während der Ausführung der Aufgabe generiert werden. Temporäre Speichervolumes werden immer gelöscht, wenn die Aufgabe beendet wird. Daten, in die geschrieben /tmp wird, werden nicht gespeichert, exportiert oder für andere Aufgaben oder nachfolgende Ausführungen zugänglich.

Wo Workflows temporäre Dateien schreiben

Workflows profitieren von flüchtigem Speicher, wenn Aufgabenprozesse direkt darauf zugreifen. I/O /tmp Workflow-Sprachen der Bioinformatik verwenden das /tmp Verzeichnis (und die $TMPDIR Umgebungsvariablen) für temporäre$TMP, kurzlebige Zwischendateien während der Aufgabenausführung. Stellen Sie sicher, dass Ihre Aufgabenbefehle keinem anderen Speicherort $TMPDIR zugeordnet sind.

Workflow-Aufgabenprozesse, die schreiben, um bei Aktivierung /tmp automatisch temporären Speicher zu verwenden, sodass keine Workflow-Änderungen erforderlich sind. Workflows, die Scratch-Prozesse nicht explizit dazu anweisen, /tmp schreiben Scratch-Daten in das Arbeitsverzeichnis auf dem gemeinsam genutzten Dateisystem, das für den Run-Speicher verwendet wird, obwohl die verwendeten Tools möglicherweise den temporären /tmp Speicher nutzen.

Verschlüsselung im Ruhezustand

Der gesamte temporäre Speicher wird im Ruhezustand mithilfe eines vom Service verwalteten Schlüssels verschlüsselt. AWS KMS Instances mit beschleunigter Datenverarbeitung sind hardwareverschlüsselt. Für jedes Volume gibt es einen eindeutigen Schlüssel, der beim Beenden der Instanz gelöscht wird.

Berechtigungen

HealthOmics verwaltet in Ihrem Namen die Anlage und den Lebenszyklus flüchtiger Speichervolumes. Für Ihre Rolle zur Aufgabenausführung sind keine zusätzlichen IAM-Berechtigungen erforderlich.

Ephemeren Speicher aktivieren

Sie können Scratch in I/O den lokalen Speicher umleiten, indem Sie dies scratchStorageMode in der StartRun API festlegen. Die scratchStorageMode Einstellung gilt nur für CPU-Instanzen und gilt für alle Aufgaben in diesem Lauf.

scratchStorageModebestimmt, wo Ihr Workflow Scratch-Daten schreibt. Mögliche Werte:

Weitere Informationen finden Sie unter Starte einen Lauf in HealthOmics.

Entscheiden Sie sich für kurzlebigen Speicher

Um den temporären Speicher für einen Lauf zu aktivieren, setze LOCAL beim Start des Laufs scratchStorageMode die Einstellung auf.

aws omics start-run \
    --workflow-id workflow-id \
    --role-arn arn:aws:iam::123456789012:role/OmicsServiceRole \
    --output-uri s3://amzn-s3-demo-bucket/output-folder/ \
    --parameters file:///path/to/parameters.json \
    --scratch-storage-mode LOCAL

Bei Batch-Läufen geben scratchStorageMode Sie den Wert ein. defaultRunSetting Die Einstellung gilt für jeden Lauf im Batch.

aws omics start-run-batch \
    --batch-name "my-batch" \
    --default-run-setting '{
      "workflowId": "workflow-id",
      "roleArn": "arn:aws:iam::123456789012:role/OmicsServiceRole",
      "outputUri": "s3://amzn-s3-demo-bucket/output-folder/",
      "storageType": "DYNAMIC",
      "parameters": {"referenceUri": "s3://amzn-s3-demo-bucket/reference.fasta"},
      "scratchStorageMode": "LOCAL"
    }' \
    --batch-run-settings '{
      "inlineSettings": [
        {
          "runSettingId": "sample-A",
          "parameters": {"inputUri": "s3://amzn-s3-demo-bucket/sampleA.fastq"}
        },
        {
          "runSettingId": "sample-B",
          "parameters": {"inputUri": "s3://amzn-s3-demo-bucket/sampleB.fastq"}
        }
      ]
    }'

Deaktivieren Sie den kurzlebigen Speicher

Um den kurzlebigen Speicher für einen bestimmten Lauf zu deaktivieren (z. B. um einen Fehler zu isolieren), setzen Sie den Wert auf. scratchStorageMode SHARED

aws omics start-run \
     --workflow-id workflow-id \
     --role-arn arn:aws:iam::123456789012:role/OmicsServiceRole \
     --output-uri s3://amzn-s3-demo-bucket/output-folder/ \
     --scratch-storage-mode SHARED

scratchStorageModeIst dies der SHARED Fall, werden alle disk und gleichwertige Anweisungen in der Workflow-Definition ignoriert und /tmp vom gemeinsam genutzten Dateisystem unterstützt. Diese Einstellung gilt nur für CPU-Instanzen. GPU-Aufgaben verwenden immer lokalen temporären NVMe-Speicher und können nicht deaktiviert werden.

Überprüfen Sie den effektiven Modus

Der kurzlebige Speicher ist standardmäßig deaktiviert. Wenn in einer StartRun Anfrage weggelassen scratchStorageMode wird, scratchStorageMode ist auf SHARED (Standard) gesetzt.

scratchStorageModewird in der GetRun Antwort nur zurückgegeben, wenn sie in der StartRun Anfrage explizit übergeben wurde. SHAREDist der Standardwert, wenn er weggelassen wird. Rufen Sie GetRun auf, um den effektiven Speichermodus für einen Lauf zu bestätigen.

aws omics get-run --id run-id

Standard-Speicherzuweisung

Die standardmäßige temporäre Speicherzuweisung beträgt 16 GiB pro Aufgabe für alle Standard-, Compute- und Memory-optimized Instance-Typen. Sie müssen keine disk Direktive angeben, um diese Standardeinstellung zu erhalten. Verwenden Sie die disk Direktive, um zusätzlichen Speicher zu konfigurieren. Sie können den Umfang des temporären Speichers, der einzelnen Aufgaben in Ihrer Workflow-Definition zugewiesen ist, auf bis zu 3.072 GiB pro Aufgabe erhöhen. Speicherplatz, der über den Standardwerten von 16 GiB liegt, wird Ihnen in Rechnung gestellt.

Kurzlebiger Speicher kann in Schritten von 16 GiB konfiguriert werden. Weitere Informationen finden Sie unter Unterstützte Größen.

Ephemerer Speicher für beschleunigte Recheninstanzen

Die Speicherkapazität der GPU-Instance ist pro Instance-Typ festgelegt und wird ohne zusätzliche Kosten bereitgestellt.

GPU-Aufgaben verwenden immer lokalen ephemeren NVMe-Speicher. Die scratchStorageMode Einstellung auf gilt StartRun nicht für GPU-Aufgaben. Wenn Sie diesen Wert auf setzen, hat SHARED dies keine Auswirkungen auf GPU-Instances. Die Kapazität ist pro Instanztyp fest und kann nicht mithilfe der disk Direktive angepasst werden. Die NVMe-Kapazität wird durch den Instance-Typ vorgegebencpu, memory der für die Anforderungen der Aufgabe ausgewählt wurde. acceleratorType

Konfiguration der Größe des kurzlebigen Speichers

Wenn auf gesetzt scratchStorageMode istLOCAL, können Sie mithilfe der disk Anweisung (oder einer gleichwertigen Anweisung) in Ihrer Workflow-Definition eine Erhöhung des temporären Speichers pro Aufgabe anfordern. HealthOmics behandelt die disk Direktive als Hinweis und gibt ein auf die nächsten 16 GiB gerundetes Volumen an. Die Verwendung der disk Direktive hat keinen Einfluss auf die Auswahl des Instanztyps. Der Instanztyp wird ausschließlich auf der Grundlage von cpumemory, und ausgewähltacceleratorType. Weitere Informationen finden Sie unter Aufgabenressourcen in einer Workflow-Definition HealthOmics.

Wenn keine disk Direktive vorhanden ist, erhält die Aufgabe die Standardgröße von 16 GiB. Aufgaben können nicht weniger als den standardmäßigen temporären Speicher haben.

Sie müssen die Größe Ihres temporären Speichers nicht für abgerufene Container-Images anpassen, die separat abgerechnet werden. Weitere Informationen finden Sie unter Container-Images für private Workflows.

Wann sollte die Disk-Direktive verwendet werden

Verwenden Sie die disk Direktive in Ihrer Aufgabendefinition, wenn der standardmäßige temporäre Speicher für den von Ihnen ausgewählten Instance-Typ für Ihre Aufgabenanforderungen nicht ausreicht. Zum Beispiel, wenn eine Aufgabe große Datenmengen in sie schreibt. /tmp

Häufige Anwendungsfälle für flüchtiger Speicher

Syntax der Direktive nach Engine

Die folgende Tabelle zeigt die entsprechende Direktive für jede Workflow-Sprache.

Die folgenden Beispiele zeigen, wie eine Aufgabe konfiguriert wird, die 700 GiB kurzlebigen Speicher anfordert. HealthOmics rundet dies auf die 704-GiB-Stufe auf.

WDL

task sort_bam {
    runtime {
        cpu:  16
        disks: "700 GiB"
    }
    command <<<
        samtools sort -T /tmp/sort_buffer ~{input_bam} -o ~{output_bam}
    >>>
}

Nextflow

process sort_bam {
    disk '700 GB'
    script:
    """
    samtools sort -T /tmp/sort_buffer ${input} -o ${output}
    """
}

CWL

requirements:
  ResourceRequirement:
    tmpdirMin: 716800   # 700 GiB expressed in MiB

Weitere Hinweise zur unterstützten Direktivensyntax finden Sie unter Besonderheiten der WDL-Workflow-Definition undBesonderheiten der Nextflow-Workflow-Definition.

Beispiel: Ausdrucksbasierte Festplattengröße

Statt einer festen Größe können Sie die disk Direktive auf einen Ausdruck setzen, den die Workflow-Engine zur Laufzeit für jede Aufgabe auswertet. Der folgende Nextflow-Prozess verwendet einen Abschluss, der die Anforderung anhand der Anzahl der Aufgabenversuche skaliert. Wenn die Aufgabe aus irgendeinem Grund fehlschlägt und Nextflow sie erneut versucht, wird bei der Wiederholung ein größeres Volumen angefordert.

process sort_bam {
    disk { 200.GB * task.attempt }
    errorStrategy 'retry'
    maxRetries 2

    script:
    """
    samtools sort -T /tmp/sort_buffer ${input} -o ${output}
    """
}
// First attempt requests 200 GiB (provisioned at the 208 GiB tier)
// Second attempt requests 400 GiB (provisioned at the 400 GiB tier)

Die Workflow-Engine wertet den Ausdruck für jeden Aufgabenversuch aus. HealthOmics rundet dann die aufgelöste Größe auf das nächste 16-GiB-Inkrement auf.

Allgemeine Bioinformatik-Tools und kurzlebige Speicherung

Viele Bioinformatik-Tools schreiben während der Ausführung große temporäre Dateien. Wenn auf gesetzt scratchStorageMode istLOCAL, leiten Sie diese Tools zur Verwendung um, /tmp sodass Scratch auf I/O das schnelle lokale Volume und nicht auf das gemeinsam genutzte Run-Dateisystem übertragen wird. Die folgenden Beispiele zeigen die relevanten Flags für häufig verwendete Tools.

WDL

task sort_bam {
    runtime {
        cpu:   16
        disks: "700 GiB"
    }
    command <<<
        # samtools: -T sets the temp-file prefix
        samtools sort -T /tmp/sort_buffer ~{input_bam} -o ~{sorted_bam}

        # GATK / Picard: --TMP_DIR flag (older Picard uses TMP_DIR=/tmp)
        gatk MarkDuplicates -I ~{sorted_bam} -O ~{output_bam} --TMP_DIR /tmp

        # STAR: --outTmpDir (path must not pre-exist; STAR creates it)
        STAR --runThreadN 16 --readFilesIn ~{reads} --outTmpDir /tmp/star_tmp --outFileNamePrefix out_

        # bcftools sort: -T / --temp-dir
        bcftools sort -T /tmp ~{vcf} -o ~{output_vcf}

        # GNU sort: -T / --temporary-directory
        sort -T /tmp ~{big_table} -o ~{sorted_table}
    >>>
}
# HealthOmics rounds 700 GiB up to the 704 GiB tier

Nextflow

process sort_bam {
    disk '700 GB'
    script:
    """
    # samtools: -T sets the temp-file prefix
    samtools sort -T /tmp/sort_buffer input.bam -o sorted.bam

    # GATK / Picard: --TMP_DIR flag (older Picard uses TMP_DIR=/tmp)
    gatk MarkDuplicates -I sorted.bam -O dedup.bam --TMP_DIR /tmp

    # STAR: --outTmpDir (path must not pre-exist; STAR creates it)
    STAR --runThreadN 16 --readFilesIn reads.fastq --outTmpDir /tmp/star_tmp --outFileNamePrefix out_

    # bcftools sort: -T / --temp-dir
    bcftools sort -T /tmp input.vcf -o sorted.vcf

    # GNU sort: -T / --temporary-directory
    sort -T /tmp big_table.tsv -o sorted_table.tsv
    """
}
// HealthOmics rounds 700 GB up to the 704 GiB tier

CWL

class: CommandLineTool
cwlVersion: v1.2
requirements:
  ResourceRequirement:
    coresMin: 16
    tmpdirMin: 716800          # 700 GiB expressed in MiB
baseCommand: [bash, -c]
arguments:
  - |
    set -euo pipefail

    # samtools: -T sets the temp-file prefix
    samtools sort -T /tmp/sort_buffer input.bam -o sorted.bam

    # GATK / Picard: --TMP_DIR flag (older Picard uses TMP_DIR=/tmp)
    gatk MarkDuplicates -I sorted.bam -O dedup.bam --TMP_DIR /tmp

    # STAR: --outTmpDir (path must not pre-exist; STAR creates it)
    STAR --runThreadN 16 --readFilesIn reads.fastq --outTmpDir /tmp/star_tmp --outFileNamePrefix out_

    # bcftools sort: -T / --temp-dir
    bcftools sort -T /tmp input.vcf -o sorted.vcf

    # GNU sort: -T / --temporary-directory
    sort -T /tmp big_table.tsv -o sorted_table.tsv

Unterstützte Größen

Die angeforderten Größen werden auf das nächste 16-GiB-Inkrement aufgerundet, ausgehend von der Standardeinstellung von 16 GiB (16, 32, 48, 64,... bis zu 3.072 GiB). Die maximal unterstützte Größe beträgt 3.072 GiB pro Aufgabe.

Wenn eine angeforderte Größe 3.072 GiB überschreitet, HealthOmics werden 3.072 GiB bereitgestellt und eine Warnung in das Ausführungsprotokoll geschrieben. Die Aufgabe ist nicht automatisch fehlgeschlagen.

Unterstützte WDL-Festplattenformulare

Eine vollständige Liste der akzeptierten disks WDL-Formulare finden Sie unter. Unterstützte WDL-Festplattenformulare

Verwenden der Nextflow-Scratch-Direktive

Für Nextflow-Workflows können Sie die scratch Direktive verwenden, um zu steuern, wo Prozesse temporäre Arbeitsdateien schreiben. Hinweise zu den unterstützten Werten und der empfohlenen Verwendung von temporärem Speicher finden Sie unter. Effiziente Nutzung des Scratch-Speichers in Nextflow

Überwachung des kurzlebigen Speichers

HealthOmics schreibt temporäre Speichermetriken pro Aufgabe in Manifestprotokolle. CloudWatch Zu den Metriken gehören temporäre Speicherdaten pro Aufgabe in Bezug auf die Größe (n) des bereitgestellten Volumes und dessen Nutzung (enscratchStorageReservedGiB) für jede Aufgabe. scratchStorageUtilizedGiB Prüfen Sie das Manifestprotokoll, um festzustellen, ob die Aufgaben zu viel oder zu wenig bereitgestellt wurden, ohne eine direkte Abfrage durchzuführen. CloudWatch Einzelheiten zu Manifestprotokollen finden Sie unter. Überwachung HealthOmics mit CloudWatch Protokollen

Wie wird kurzlebiger Speicher abgerechnet

Ihnen wird nur der temporäre Speicher in Rechnung gestellt, der über der Standardzuweisung bereitgestellt wird. Anfragen, die über der Standardeinstellung in Ihrer disk Anweisung liegen, werden auf die nächste unterstützte Stufe aufgerundet.

Bei GPU-Instances ist kurzlebiger Speicher bereits in der Preisgestaltung für Instances berücksichtigt. Für kurzlebigen Speicher bei GPU-Aufgaben fallen keine zusätzlichen Gebühren an.

Überlegungen und Einschränkungen

Problembehandlung bei kurzlebigem Speicher

Die Aufgabe schlägt fehl, da der kurzlebige Speicher erschöpft ist

Eine Aufgabe schlägt fehl, wenn der kurzlebige Speicher seine Kapazität erreicht. Prüfen Sie Ihre CloudWatch Manifestprotokolle, um festzustellen, wie viel Speicherplatz Ihre Aufgabe tatsächlich verbraucht hat, und fügen Sie dann die disk Direktive hinzu oder erhöhen Sie sie, um eine größere Ebene anzufordern.

# Before: 4-vCPU task using the 16 GiB default
runtime { cpu: 4 }

# After: explicitly request 400 GiB
runtime { cpu: 4, disks: "400 GiB" }

Kurzlebiger Speicher scheint nicht genutzt zu werden

Rufen Sie an GetRun und überprüfen Sie das FeldscratchStorageMode. Wenn der Wert 0 istSHARED, ist der kurzlebige Speicher für diesen Lauf nicht aktiviert. Stellen Sie es --scratch-storage-mode LOCAL bei Ihrem nächsten start-run Anruf ein.

aws omics get-run --id run-id