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`
**Topics**
+ [Vantaggi principali](#ephemeral-storage-key-benefits)
+ [Come funziona lo storage temporaneo](#ephemeral-storage-how-it-works)
+ [Abilitazione dello storage temporaneo](#ephemeral-storage-enable)
+ [Allocazione di archiviazione predefinita](#ephemeral-storage-default-allocation)
+ [Configurazione delle dimensioni di archiviazione effimere](#ephemeral-storage-configure-size)
+ [Monitoraggio dello storage temporaneo](#ephemeral-storage-monitoring)
+ [Come viene fatturato lo storage temporaneo](#ephemeral-storage-billing)
+ [Considerazioni e limitazioni](#ephemeral-storage-considerations)
+ [Risoluzione dei problemi relativi allo storage temporaneo](#ephemeral-storage-troubleshooting)
## Vantaggi principali
+ **Esecuzione più rapida delle attività:** lo storage temporaneo può migliorare le prestazioni di esecuzione riducendo il file system condiviso. I/O
+ **Prestazioni prevedibili: le** attività non competono con altre attività eseguite contemporaneamente in termini di I/O larghezza di banda, il che riduce la variabilità e la limitazione associate a un file system di rete condiviso.
+ **Costi inferiori:** l'esecuzione più rapida delle attività riduce direttamente i tempi e i costi di elaborazione per le attività vincolate che utilizziamo. I/O `/tmp` Per le esecuzioni che utilizzano lo storage di esecuzione statico, ciò può ridurre la quantità di storage di esecuzione assegnato di cui hai bisogno. Le esecuzioni dinamiche non richiedono modifiche.
## 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'`scratchStorageMode`API. `StartRun` L'`scratchStorageMode`impostazione si applica solo alle istanze della CPU e a tutte le attività in esecuzione.
`scratchStorageMode`determina dove il flusso di lavoro scrive i dati di memoria virtuale. Valori possibili:
+ `LOCAL`— L'archiviazione temporanea viene salvata sul disco locale. Scratch I/O ha IOPS e throughput dedicati.
+ `SHARED`— Viene utilizzato il filesystem condiviso (impostazione predefinita). Scratch I/O contende con la directory di lavoro.
Per ulteriori informazioni, consulta [Inizia una corsa in HealthOmics](starting-a-run.md).
**Nota**
Le attività GPU utilizzano sempre l'archiviazione temporanea locale NVMe per i dati scratch e lo sono sempre per le attività GPU. `scratchStorageMode` `LOCAL`
### 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 `scratchStorageMode``SHARED`, 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`
`scratchStorageMode`viene 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](#ephemeral-storage-supported-sizes).
### 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'`scratchStorageMode`impostazione 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` requisiti`memory`. `acceleratorType`
| Dimensione | GPU | VPCU | Memoria (GiB) | G4dn NVMe (T4) | NVMe G5 (A10G) | NVMe G6 (L4) | NVMe G6e (L40S) |
| --- | --- | --- | --- | --- | --- | --- | --- |
| xlarge | 1 | 4 | 16 | 125 GiB | 250 GiB | 250 GiB | 250 GiB |
| 2xlarge | 1 | 8 | 32 | 225 GiB | 450 GiB | 450 GiB | 450 GiB |
| 4xlarge | 1 | 16 | 64 | 225 GiB | 600 GiB | 600 GiB | 600 GiB |
| 8xlarge | 1 | 32 | 128 | 900 GiB | 900 GiB | 900 GiB | 900 GiB |
| 12xlarge | 4 | 48 | 192 | 900 GiB | 3.800 GiB | 3.760 GiB | 3.800 GiB |
| 16xlarge | 1 | 64 | 256 | 900 GiB | 1.900 GiB | 1.880 GiB | 1.900 GiB |
| 24xlarge | 4 | 96 | 384 | — | 3.800 GiB | 3.760 GiB | 3.800 GiB |
## Configurazione delle dimensioni di archiviazione effimere
Se `scratchStorageMode` è impostata su`LOCAL`, è 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 `cpu``memory`, e`acceleratorType`. Per ulteriori informazioni, consulta [Le risorse delle attività in una definizione di HealthOmics flusso di lavoro](task-resources.md).
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](workflows-ecr.md).
### 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
1. **RNA-Seq Fusion Detection:** RNA-seq i flussi di lavoro generano BAM intermedi di grandi dimensioni e i processi di attività spesso richiedono la presenza simultanea di FastQS non elaborati e degli output allineati, il che richiede dischi di memoria virtuale di grandi dimensioni (ad esempio, 512 GiB per attività).
1. **De Novo Genome Assembly: i flussi di lavoro di assemblaggio** richiedono grandi volumi di Long-read memoria virtuale per elaborare letture non elaborate e artefatti di assemblaggio temporanei che vengono riscritti e riorganizzati ripetutamente prima dell'output. Queste attività richiedono un uso intensivo della memoria e del disco e a volte richiedono più TiB di storage temporaneo.
1. **Richiesta di varianti /elaborazione BAM:** i flussi di lavoro per le chiamate di varianti richiedono una notevole capacità di storage virtuale per le fasi di allineamento e ordinamento che leggono e riscrivono ripetutamente file BAM o CRAM di grandi dimensioni. Le esigenze di storage temporaneo sono in genere centinaia di GiB.
### Sintassi delle direttive per motore
La tabella seguente mostra la direttiva equivalente per ogni linguaggio del flusso di lavoro.
| Motore | Direttiva | Esempio |
| --- | --- | --- |
| WDL 1.1 | disks | disks: "/tmp 700 GiB" |
| Flusso successivo | disk | disk '700 GB' |
| CWL | tmpdirMin | tmpdirMin: 716800(valore in MiB) |
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](workflow-languages-wdl.md) [Specifiche della definizione del flusso di lavoro Nextflow](workflow-definition-nextflow.md)
### Strumenti bioinformatici comuni e archiviazione effimera
Molti strumenti di bioinformatica scrivono file temporanei di grandi dimensioni durante l'esecuzione. Quando `scratchStorageMode` è impostato su`LOCAL`, 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.
**Nota**
Per le `disk` direttive basate sulle espressioni, come le chiusure Nextflow o le espressioni WDL, il valore viene valutato in fase di `disks: ceil(size(input_bam, "GiB") * 2.5)` esecuzione, non in. `CreateWorkflow` Se la dimensione valutata supera 3.072 GiB, l'attività ha esito negativo in fase di esecuzione e vengono addebitati tutti i costi di elaborazione sostenuti fino a quel momento.
### `Moduli` di dischi WDL supportati
Per l'elenco completo dei `disks` moduli WDL accettati, vedere. [`Moduli di dischi WDL supportati`](workflow-languages-wdl.md#workflow-wdl-disks-forms)
### 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](workflow-definition-nextflow.md#nextflow-scratch-storage)
## 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](monitoring-cloudwatch-logs.md)
## 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
| Considerazione | Dettaglio |
| --- | --- |
| Lo storage temporaneo non è persistente | I volumi di archiviazione temporanei vengono sempre eliminati al termine dell'attività. I dati in /tmp ingresso non vengono salvati, esportati o disponibili per attività o esecuzioni successive. I dati /tmp in memoria temporanea non possono essere un output di un'attività o un output di un flusso di lavoro; ciò comporterà un errore in fase di esecuzione. |
| Lo storage temporaneo non è condiviso tra le attività | Ogni attività riceve il proprio volume di archiviazione temporaneo isolato. Le attività non possono accedere alle rispettive directory. /tmp I dati che devono essere condivisi tra le attività devono essere scritti nel filesystem di esecuzione condiviso. |
| Lo storage non può essere ridimensionato durante l'operazione | La dimensione di archiviazione è fissa all'inizio dell'attività. Non è possibile aumentare o diminuire lo spazio di archiviazione allocato mentre un'attività è in esecuzione. |
| Working-directory scratch non viene reindirizzato automaticamente | I flussi di lavoro che scrivono scratch nella directory di lavoro, ad esempio, o input/ ./out/, non ne traggono automaticamente vantaggio. Aggiorna il tuo flusso di lavoro per reindirizzare scratch I/O verso o/tmp. $TMPDIR |
| I dati di Scratch non vengono scritti /tmp come previsto | Assicurati che i processi di attività scrivano in modo esplicito /tmp e che i comandi delle attività non siano mappati in un'altra $TMPDIR posizione. |
| Le istanze GPU utilizzano sempre lo storage temporaneo | Le attività GPU vengono sempre montate /tmp sull'archivio di istanze NVMe locale. L'impostazione scratchStorageMode su SHARED non disabilita lo storage temporaneo per le attività GPU. |
| Istanze GPU: la capacità NVMe è fissa | Il dimensionamento personalizzato del disco non è supportato sulle istanze GPU. HealthOmics ignora le disk direttive e fornisce la capacità NVMe predefinita per il tipo di istanza. |
| Massimo 3.072 GiB per attività (CPU) | Le richieste superiori a 3.072 GiB vengono fornite a 3.072 GiB con un avviso di log di esecuzione. Le attività non sono fallite. |
| Solo livelli supportati (CPU) | Le dimensioni richieste vengono arrotondate all'incremento di 16 GiB più vicino (16, 32, 48, 64,... fino a 3.072 GiB). |
| Expression-based direttive valutate in fase di esecuzione | diski valori calcolati dalle espressioni vengono convalidati all'inizio dell'attività, non a. CreateWorkflow I costi di elaborazione fino a quel momento vengono addebitati se l'attività fallisce in fase di esecuzione. |
| SHAREDla modalità ignora tutte le direttive del disco (solo CPU) | When scratchStorageMode isSHARED, disktmpdirMin, e le direttive equivalenti vengono ignorate per le attività della CPU. Non viene fornito alcun volume di archiviazione locale. Le attività della GPU non sono influenzate, utilizzano sempre la tecnologia NVMe locale. |
## 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}}
```