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 stellt mithilfe des Verzeichnisses kurzlebigen Speicher für Workflow-Aufgaben bereit. /tmp Dieser Speicher ist temporär und für jede Aufgabe in einem Workflow einzigartig. HealthOmics weist jeder Task-Instanz standardmäßig 16 GiB kurzlebigen Speicher zu. Sie können die Menge an temporärem Speicher, der einzelnen Aufgaben in Ihrer Workflow-Definition zugewiesen ist, auf bis zu 3.072 GiB pro Aufgabe erhöhen. Alle Daten, die in gespeichert sind, sind im Ruhezustand /tmp verschlüsselt.

Wichtigste Vorteile

So funktioniert kurzlebiger Speicher

Wenn Sie kurzlebigen Speicher aktivieren, wird /tmp für jede HealthOmics Workflow-Aufgabeninstanz ein dediziertes lokales Speichervolume bereitgestellt. Kurzlebiger Speicher ist für temporäre Dateien vorgesehen, die bei der Ausführung von Aufgaben generiert werden. Kurzlebige Speichervolumes werden immer gelöscht, wenn die Aufgabe beendet wird. Daten, auf die geschrieben /tmp wird, werden nicht dauerhaft gespeichert, exportiert oder sind nicht 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 auf Scratch I/O zugreifen. /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, bei denen /tmp automatisch kurzlebigen Speicher verwendet wird, wenn sie aktiviert sind, 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 die Run-Speicherung verwendet wird, obwohl die verwendeten Tools möglicherweise die Vorteile von /tmp flüchtigem Speicher nutzen.

Verschlüsselung im Ruhezustand

Der gesamte kurzlebige Speicher wird im Ruhezustand mithilfe eines vom Service verwalteten Schlüssels verschlüsselt. AWS KMS Accelerated Computing-Instances sind hardwareverschlüsselt und verfügen über einen eindeutigen Schlüssel pro Volume, der gelöscht wird, wenn die Instance beendet wird.

Berechtigungen

HealthOmics verwaltet die Zuordnung und den Lebenszyklus von kurzlebigen Speichervolumes in Ihrem Namen. Für Ihre Aufgabenausführungsrolle 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, wohin 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 kurzlebigen Speicher für einen Lauf zu aktivieren, stellen Sie ihn auf ein, LOCAL wenn Sie scratchStorageMode den Lauf starten.

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

Geben Sie bei Batchausführungen den Wert ein. scratchStorageMode defaultRunSetting Die Einstellung gilt für jeden Lauf im Stapel.

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 kurzlebigen Speicher für einen bestimmten Lauf zu deaktivieren (z. B. um einen Fehler zu isolieren), setzen Sie 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

Wenn dies der SHARED Fall scratchStorageMode ist, 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 kurzlebigen NVMe-Speicher und können nicht deaktiviert werden.

Überprüfen Sie den effektiven Modus

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

scratchStorageModewird in der GetRun Antwort nur zurückgegeben, wenn es 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 Zuweisung von temporärem Speicher 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 die Menge an temporärem Speicher, der einzelnen Aufgaben in Ihrer Workflow-Definition zugewiesen ist, auf bis zu 3.072 GiB pro Aufgabe erhöhen. Ihnen wird Speicherplatz über den standardmäßigen 16 GiB in Rechnung gestellt.

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

Kurzlebiger Speicher für beschleunigte Recheninstanzen

Die Speicherkapazität für GPU-Instances ist pro Instance-Typ festgelegt und wird ohne zusätzliche Kosten bereitgestellt.

GPU-Aufgaben verwenden immer lokalen kurzlebigen NVMe-Speicher. Die scratchStorageMode Einstellung on gilt StartRun nicht für GPU-Aufgaben und die Einstellung dieses Werts auf hat keine Auswirkungen auf GPU-Instanzen. SHARED Die Kapazität ist pro Instanztyp festgelegt und kann nicht mithilfe der disk Direktive angepasst werden. Die NVMe-Kapazität wird durch den Instanztyp, der für die Aufgabe ausgewählt wurde cpumemory, und acceleratorType durch die Anforderungen vorgegeben.

Konfiguration der kurzlebigen Speichergröße

Wenn auf gesetzt scratchStorageMode istLOCAL, können Sie mithilfe der disk Direktive (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 stellt ein Volumen bereit, das auf die nächsten 16 GiB gerundet ist. 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 HealthOmics Workflow-Definition.

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

Sie müssen die Größe Ihres temporären Speichers nicht für gepullte Container-Images festlegen, da diese separat berücksichtigt werden. Weitere Informationen finden Sie unter Container-Images für private Workflows.

Wann sollte die Festplatten-Direktive verwendet werden

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

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

Syntax der Direktiven nach Engine

Die folgende Tabelle zeigt die entsprechende Anweisung 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 Informationen zur unterstützten Direktivensyntax finden Sie unter Besonderheiten der WDL-Workflow-Definition undEinzelheiten der Nextflow-Workflow-Definition.

Gängige Bioinformatik-Tools und kurzlebiger Speicher

Viele Bioinformatik-Tools schreiben während der Ausführung große temporäre Dateien. Wenn auf gesetzt scratchStorageMode istLOCAL, werden diese Tools /tmp so umgeleitet, dass Scratch auf I/O das schnelle lokale Volume und nicht auf das Shared 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

Angeforderte Größen werden auf das nächste 16-GiB-Inkrement aufgerundet, beginnend mit 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, werden HealthOmics 3.072 GiB bereitgestellt und eine Warnung in das Ausführungsprotokoll geschrieben. Die Aufgabe schlägt nicht automatisch fehl.

Unterstützte WDL-Festplatten

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

Verwenden der Nextflow-Scratch-Direktive

Für Nextflow-Workflows können Sie die scratch Direktive verwenden, um zu kontrollieren, wo Prozesse temporäre Arbeitsdateien schreiben. Hinweise zu unterstützten Werten und zur empfohlenen Verwendung mit flüchtigem Speicher finden Sie unter. Effiziente Nutzung von Scratch-Speicher in Nextflow

Überwachung kurzlebigen Speichers

HealthOmics schreibt Metriken für ephemeren Speicher pro Aufgabe in Manifestprotokolle. CloudWatch Zu den Metriken gehören kurzlebige Speicherdaten pro Aufgabe zur Größe (enscratchStorageReservedGiB) und Nutzung (en) des bereitgestellten Volumes für jede Aufgabe. scratchStorageUtilizedGiB Prüfen Sie ohne direkte Abfrage anhand des Manifestprotokolls, ob Aufgaben zu viel oder zu wenig bereitgestellt wurden. CloudWatch Einzelheiten zu Manifestprotokollen finden Sie unter. Überwachung HealthOmics mit CloudWatch Protokollen

Wie wird kurzlebiger Speicher abgerechnet

Ihnen wird nur der kurzlebige Speicher in Rechnung gestellt, der über der Standardzuweisung bereitgestellt wurde. Anfragen, die über dem in Ihrer disk Anweisung angegebenen Standard liegen, werden auf die nächstgelegene unterstützte Stufe aufgerundet.

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

Überlegungen und Einschränkungen

Fehlerbehebung bei kurzlebigem Speicher

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

Eine Aufgabe schlägt fehl, wenn der kurzlebige Speicher seine Kapazität erreicht. Überprüfen Sie Ihre CloudWatch Manifestprotokolle, um festzustellen, wie viel Speicherplatz Ihre Aufgabe tatsächlich belegt hat, und fügen Sie dann die disk Anweisung hinzu oder erhöhen Sie sie, um eine größere Stufe 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 lautetSHARED, ist kurzlebiger Speicher für diesen Lauf nicht aktiviert. Bei --scratch-storage-mode LOCAL Ihrem nächsten start-run Anruf festlegen.

aws omics get-run --id run-id