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à.

Archiviazione temporanea per le attività del flusso di lavoro HealthOmics

HealthOmics fornisce uno storage temporaneo per le attività del flusso di lavoro utilizzando la directory. /tmp Questo spazio di archiviazione è temporaneo e unico per ogni attività in un flusso di lavoro. HealthOmics per impostazione predefinita, alloca 16 GiB di spazio di archiviazione temporaneo a ciascuna istanza di attività. È possibile aumentare la quantità di storage temporaneo allocato alle singole attività nella definizione del flusso di lavoro, fino a un massimo di 3.072 GiB per attività. Tutti i dati archiviati sono crittografati quando sono inattivi. /tmp

Vantaggi principali

Come funziona lo storage temporaneo

Quando abiliti lo storage temporaneo, HealthOmics monta un volume di archiviazione locale dedicato per ogni istanza di attività del flusso di lavoro. /tmp Lo storage temporaneo è destinato ai file temporanei generati durante l'esecuzione dell'attività. I volumi di archiviazione temporanei vengono sempre eliminati al termine dell'attività. I dati scritti su non /tmp sono persistenti, esportati o accessibili ad altre attività o esecuzioni successive.

Dove i flussi di lavoro scrivono file temporanei

I flussi di lavoro traggono vantaggio dall'archiviazione temporanea quando i processi delle attività sono diretti a zero. I/O /tmp I linguaggi di workflow bioinformatici utilizzano la /tmp directory (e le variabili di $TMPDIR ambiente) per i $TMP file intermedi temporanei e di breve durata durante l'esecuzione delle attività. Assicurati che i comandi delle tue attività non siano mappati in un'altra posizione. $TMPDIR

I processi di attività del flusso di lavoro che scrivono in /tmp modo automatico utilizzano l'archiviazione temporanea quando abilitati, senza richiedere modifiche al flusso di lavoro. I flussi di lavoro che non indirizzano esplicitamente i processi scratch a scrivere /tmp i dati di scratch nella directory di lavoro del file system condiviso utilizzato per l'archiviazione di esecuzione, sebbene gli strumenti utilizzati possano trarre vantaggio dall'archiviazione temporanea. /tmp

Crittografia dei dati a riposo

Tutto lo storage temporaneo è crittografato quando è inattivo utilizzando una chiave gestita dal servizio. AWS KMS Le istanze di elaborazione accelerata sono crittografate tramite hardware con una chiave unica per volume che viene distrutta al termine dell'istanza.

Permissions

HealthOmics gestisce l'allegato e il ciclo di vita dei volumi di storage temporanei per tuo conto. Non sono richieste autorizzazioni IAM aggiuntive nel ruolo di esecuzione delle attività.

Abilitazione dello storage temporaneo

Puoi reindirizzare scratch I/O alla memoria locale impostando l'scratchStorageModeAPI. StartRun L'scratchStorageModeimpostazione si applica solo alle istanze della CPU e a tutte le attività in esecuzione.

scratchStorageModedetermina dove il flusso di lavoro scrive i dati di memoria virtuale. Valori possibili:

Per ulteriori informazioni, consulta Inizia una corsa in HealthOmics.

Scegli lo storage temporaneo

Per abilitare lo storage temporaneo per una corsa, imposta scratchStorageMode su quando inizi l'esecuzione. LOCAL

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

Per le esecuzioni in batch, trasferisci. scratchStorageMode defaultRunSetting L'impostazione si applica a ogni esecuzione del 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"}
        }
      ]
    }'

Disattiva l'archiviazione temporanea

Per disabilitare l'archiviazione temporanea per un'esecuzione specifica (ad esempio, per isolare un errore), imposta su. 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

In tal caso scratchStorageModeSHARED, tutte le disk direttive equivalenti nella definizione del flusso di lavoro vengono ignorate e sono supportate dal file system condiviso/tmp. Questa impostazione si applica solo alle istanze della CPU. Le attività GPU utilizzano sempre lo storage temporaneo NVMe locale e non possono essere disattivate.

Verifica la modalità effettiva

L'archiviazione temporanea è disattivata per impostazione predefinita. Quando scratchStorageMode viene omesso da una StartRun richiesta, scratchStorageMode è impostato su (impostazione predefinita). SHARED

scratchStorageModeviene restituito nella GetRun risposta solo se è stato passato esplicitamente nella StartRun richiesta. SHAREDè il valore predefinito se omesso. Chiama GetRun per confermare la modalità di archiviazione effettiva per una corsa.

aws omics get-run --id run-id

Allocazione di archiviazione predefinita

L'allocazione di storage temporaneo predefinita è di 16 GiB per attività per tutti i tipi Standard, Compute e di istanza. Memory-optimized Non è necessario specificare una disk direttiva per ricevere questa impostazione predefinita. Per configurare spazio di archiviazione aggiuntivo, usa la disk direttiva. È possibile aumentare la quantità di storage temporaneo allocato alle singole attività nella definizione del flusso di lavoro, fino a un massimo di 3.072 GiB per attività. Ti viene addebitato lo spazio di archiviazione superiore ai 16 GiB predefiniti.

Lo storage temporaneo può essere configurato con incrementi di 16 GiB. Per ulteriori informazioni, consulta Dimensioni supportate.

Storage temporaneo per istanze di elaborazione accelerata

La capacità di storage delle istanze GPU è fissa per tipo di istanza e viene fornita senza costi aggiuntivi.

Le attività GPU utilizzano sempre lo storage temporaneo NVMe locale. L'scratchStorageModeimpostazione su StartRun non si applica alle attività GPU e l'impostazione di questo valore su non SHARED avrà alcun effetto sulle istanze GPU. La capacità è fissa per tipo di istanza e non può essere personalizzata utilizzando la direttiva. disk La capacità NVMe è predeterminata dal tipo di istanza selezionato per l'attività e i cpu requisitimemory. acceleratorType

Configurazione delle dimensioni di archiviazione effimere

Se scratchStorageMode è impostata suLOCAL, è possibile richiedere una maggiore memorizzazione effimera per attività utilizzando la disk direttiva (o equivalente) nella definizione del flusso di lavoro. HealthOmics tratta la disk direttiva come un suggerimento e fornisce un volume arrotondato ai successivi 16 GiB. L'uso della disk direttiva non influisce sulla selezione del tipo di istanza. Il tipo di istanza viene selezionato esclusivamente in base a cpumemory, eacceleratorType. Per ulteriori informazioni, consulta Le risorse delle attività in una definizione di HealthOmics flusso di lavoro.

Se non è presente alcuna disk direttiva, l'attività riceve i 16 GiB predefiniti. Le attività non possono avere una memoria temporanea inferiore a quella predefinita.

Non è necessario ridimensionare lo spazio di archiviazione temporaneo per le immagini dei container estratte, che vengono contabilizzate separatamente. Per ulteriori informazioni, consulta Immagini di container per flussi di lavoro privati.

Quando usare la direttiva disk

Utilizzate la disk direttiva nella definizione dell'attività quando lo storage temporaneo predefinito per il tipo di istanza scelto non è sufficiente per i requisiti dell'attività. Ad esempio, quando un'attività scrive grandi volumi di dati su. /tmp

Casi d'uso comuni per una maggiore archiviazione temporanea

Sintassi delle direttive per motore

La tabella seguente mostra la direttiva equivalente per ogni linguaggio del flusso di lavoro.

Gli esempi seguenti mostrano come configurare un'attività che richiede 700 GiB di storage temporaneo. HealthOmics lo arrotonda al livello 704 GiB.

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

Per ulteriori informazioni sulla sintassi delle direttive supportate, vedere e. Specifiche della definizione del flusso di lavoro WDL Specifiche della definizione del flusso di lavoro Nextflow

Strumenti bioinformatici comuni e archiviazione effimera

Molti strumenti di bioinformatica scrivono file temporanei di grandi dimensioni durante l'esecuzione. Quando scratchStorageMode è impostato suLOCAL, reindirizza questi strumenti per utilizzarli /tmp in modo che scratch I/O vada al volume locale veloce anziché al filesystem a esecuzione condivisa. Gli esempi seguenti mostrano i flag pertinenti per gli strumenti di uso comune.

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

Dimensioni supportate

Le dimensioni richieste vengono arrotondate all'incremento di 16 GiB più vicino, a partire dal valore predefinito di 16 GiB (16, 32, 48, 64,... fino a 3.072 GiB). La dimensione massima supportata è 3.072 GiB per attività.

Se una dimensione richiesta supera 3.072 GiB, fornisce 3.072 GiB HealthOmics e scrive un avviso nel registro di esecuzione. L'operazione non viene automaticamente fallita.

Moduli di dischi WDL supportati

Per l'elenco completo dei disks moduli WDL accettati, vedere. Moduli di dischi WDL supportati

Utilizzo della direttiva scratch di Nextflow

Per i flussi di lavoro Nextflow, puoi utilizzare la scratch direttiva per controllare dove i processi scrivono file di lavoro temporanei. Per informazioni sui valori supportati e sull'utilizzo consigliato con l'archiviazione effimera, consulta. Utilizzo efficiente dello storage Scratch in Nextflow

Monitoraggio dello storage temporaneo

HealthOmics scrive metriche di archiviazione effimere per attività nei registri manifest. CloudWatch Le metriche includono dati di archiviazione temporanei per attività relativi alle dimensioni del volume (e) e all'utilizzo (as) assegnati per ogni attività. scratchStorageReservedGiB scratchStorageUtilizedGiB Esamina il registro del manifesto per determinare se il provisioning delle attività è stato eccessivo o insufficiente senza dover eseguire direttamente delle interrogazioni. CloudWatch Per informazioni dettagliate sui registri del manifesto, vedere. Monitoraggio HealthOmics con CloudWatch registri

Come viene fatturato lo storage temporaneo

Ti viene fatturato solo lo spazio di archiviazione temporaneo fornito al di sopra dell'allocazione predefinita. Le richieste superiori al valore predefinito nella disk direttiva vengono arrotondate al livello supportato più vicino.

Lo storage temporaneo delle istanze GPU è già incluso nel prezzo delle istanze. Non sono previsti costi aggiuntivi per lo storage temporaneo sulle attività GPU.

Considerazioni e limitazioni

Risoluzione dei problemi relativi allo storage temporaneo

L'operazione fallisce quando lo storage temporaneo è esaurito

Un'operazione ha esito negativo quando lo storage temporaneo raggiunge la capacità. Esamina i log del CloudWatch manifesto per determinare la quantità di storage effettivamente utilizzata dall'attività, quindi aggiungi o aumenta la disk direttiva per richiedere un livello più ampio.

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

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

Lo storage effimero non sembra essere utilizzato

Chiama GetRun e controlla il campo. scratchStorageMode Se il valore èSHARED, la memorizzazione effimera non è abilitata per quell'esecuzione. Imposta la tua --scratch-storage-mode LOCAL prossima chiamata. start-run

aws omics get-run --id run-id