Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
# Almacenamiento efímero para HealthOmics tareas de flujo de trabajo
HealthOmics proporciona almacenamiento efímero para tareas de flujo de trabajo mediante el directorio. `/tmp` Este almacenamiento es temporal y exclusivo para cada tarea de un flujo de trabajo. HealthOmics asigna 16 GiB de almacenamiento efímero a cada instancia de tarea de forma predeterminada. Puede aumentar la cantidad de almacenamiento efímero asignado a tareas individuales en su definición de flujo de trabajo, hasta un máximo de 3072 GiB por tarea. Todos los datos almacenados se cifran en reposo`/tmp`.
**Topics**
+ [Ventajas principales](#ephemeral-storage-key-benefits)
+ [Cómo funciona el almacenamiento efímero](#ephemeral-storage-how-it-works)
+ [Habilitar el almacenamiento efímero](#ephemeral-storage-enable)
+ [Asignación de almacenamiento predeterminada](#ephemeral-storage-default-allocation)
+ [Configuración del tamaño de almacenamiento efímero](#ephemeral-storage-configure-size)
+ [Supervisión del almacenamiento efímero](#ephemeral-storage-monitoring)
+ [Cómo se factura el almacenamiento efímero](#ephemeral-storage-billing)
+ [Consideraciones y limitaciones](#ephemeral-storage-considerations)
+ [Solución de problemas de almacenamiento efímero](#ephemeral-storage-troubleshooting)
## Ventajas principales
+ **Ejecución de tareas más rápida:** el almacenamiento efímero puede mejorar el rendimiento de ejecución al reducir el sistema de archivos compartidos. I/O
+ **Rendimiento predecible:** las tareas no compiten por el ancho de I/O banda con otras tareas que se ejecutan simultáneamente, lo que reduce la variabilidad y las limitaciones asociadas a un sistema de archivos de red compartido.
+ **Costes más bajos:** una ejecución más rápida de las tareas reduce directamente el tiempo de cálculo y el coste de las tareas I/O vinculadas que se utilizan. `/tmp` En el caso de las ejecuciones que utilizan almacenamiento de ejecución estático, esto puede reducir la cantidad de almacenamiento de ejecución aprovisionado que necesita. Las ejecuciones dinámicas no requieren cambios.
## Cómo funciona el almacenamiento efímero
Al habilitar el almacenamiento efímero, HealthOmics monta un volumen de almacenamiento local dedicado `/tmp` para cada instancia de tarea del flujo de trabajo. El almacenamiento efímero está destinado a los archivos temporales generados durante la ejecución de la tarea. Los volúmenes de almacenamiento efímero siempre se eliminan al finalizar la tarea. Los datos en los que `/tmp` se escriben no se conservan, no se exportan ni se puede acceder a ellos para otras tareas o ejecuciones posteriores.
### Dónde los flujos de trabajo escriben archivos temporales
Los flujos de trabajo se benefician del almacenamiento efímero cuando los procesos de tareas se ejecutan directamente desde cero. I/O `/tmp` Los lenguajes de flujo de trabajo bioinformáticos utilizan el `/tmp` directorio (y las `$TMP` variables de `$TMPDIR` entorno) para archivos intermedios temporales y de corta duración durante la ejecución de las tareas. Asegúrese de que los comandos de las tareas no estén mapeados a otra ubicación`$TMPDIR`.
Los procesos de tareas de flujo de trabajo que escriben para usar `/tmp` automáticamente el almacenamiento efímero cuando están habilitados, sin requerir cambios en el flujo de trabajo. Los flujos de trabajo que no indiquen de forma explícita los procesos temporales `/tmp` escribirán los datos temporales en el directorio de trabajo del sistema de archivos compartido utilizado para el almacenamiento en ejecución, aunque las herramientas utilizadas pueden aprovechar `/tmp` el almacenamiento efímero.
### Cifrado en reposo
Todo el almacenamiento efímero se cifra en reposo mediante una clave gestionada por el servicio. AWS KMS Las instancias de computación acelerada se cifran por hardware con una clave única por volumen que se destruye cuando la instancia finaliza.
### Permisos
HealthOmics gestiona la conexión y el ciclo de vida de los volúmenes de almacenamiento efímero en su nombre. No se requieren permisos de IAM adicionales para su función de ejecución de tareas.
## Habilitar el almacenamiento efímero
Puedes redirigir Scratch I/O al almacenamiento local configurándolo `scratchStorageMode` en la `StartRun` API. La `scratchStorageMode` configuración se aplica solo a las instancias de CPU y a todas las tareas de esa ejecución.
`scratchStorageMode`determina dónde escribe su flujo de trabajo los datos preliminares. Valores posibles:
+ `LOCAL`— El almacenamiento efímero se coloca en el disco local. Scratch I/O tiene un rendimiento y un IOPS dedicados.
+ `SHARED`— Se utiliza el sistema de archivos compartido (predeterminado). Scratch I/O se ocupa del directorio de trabajo.
Para obtener más información, consulte [Iniciar una carrera en HealthOmics](starting-a-run.md).
**nota**
Las tareas de la GPU siempre utilizan el almacenamiento efímero NVMe local para los datos temporales y `scratchStorageMode` siempre `LOCAL` lo utilizan para las tareas de la GPU.
### Opte por el almacenamiento efímero
Para habilitar el almacenamiento efímero para una ejecución, configúrelo en `LOCAL` cuando `scratchStorageMode` comience la ejecución.
```
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
```
En el caso de las ejecuciones por lotes, transfiérala`scratchStorageMode`. `defaultRunSetting` La configuración se aplica a todas las ejecuciones del lote.
```
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}}"}
}
]
}'
```
### Excluir el almacenamiento efímero
Para deshabilitar el almacenamiento efímero para una ejecución específica (por ejemplo, para aislar un error), configúrelo en. `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
```
Cuando `scratchStorageMode` está`SHARED`, todas las directivas de la definición del flujo de trabajo `disk` y las equivalentes se ignoran y `/tmp` están respaldadas por el sistema de archivos compartido. Esta configuración solo se aplica a las instancias de CPU. Las tareas de la GPU siempre utilizan el almacenamiento efímero de NVMe local y no se pueden excluir.
### Comprueba el modo efectivo
El almacenamiento efímero está desactivado de forma predeterminada. Cuando `scratchStorageMode` se omite en una `StartRun` solicitud, `scratchStorageMode` se establece en `SHARED` (predeterminado).
`scratchStorageMode`solo se devuelve en la `GetRun` respuesta si se pasó explícitamente en la `StartRun` solicitud. `SHARED`es el valor predeterminado si se omite. Llame `GetRun` para confirmar el modo de almacenamiento efectivo para una ejecución.
```
aws omics get-run --id {{run-id}}
```
## Asignación de almacenamiento predeterminada
La asignación de almacenamiento efímero predeterminada es de 16 GiB por tarea para todos los tipos estándar, de procesamiento e instancia. Memory-optimized No es necesario especificar una `disk` directiva para recibir este valor predeterminado. Para configurar un almacenamiento adicional, utilice la `disk` directiva. Puede aumentar la cantidad de almacenamiento efímero asignado a tareas individuales en su definición de flujo de trabajo, hasta un máximo de 3072 GiB por tarea. Se te facturará un almacenamiento superior a los 16 GiB predeterminados.
El almacenamiento efímero se puede configurar en incrementos de 16 GiB. Para obtener más información, consulte [Tamaños compatibles](#ephemeral-storage-supported-sizes).
### Almacenamiento efímero para instancias de computación acelerada
La capacidad de almacenamiento de las instancias de GPU es fija por tipo de instancia y se proporciona sin coste adicional.
Las tareas de GPU siempre utilizan el almacenamiento efímero NVMe local. La `scratchStorageMode` configuración activada `StartRun` no se aplica a las tareas de la GPU y establecer este valor en no `SHARED` tendrá ningún efecto en las instancias de la GPU. La capacidad es fija para cada tipo de instancia y no se puede personalizar mediante la `disk` directiva. La capacidad de NVMe viene predeterminada según el tipo de instancia seleccionado para la tarea y `cpu` `acceleratorType` los `memory` requisitos.
| Tamaño | GPU | vCPU | Memoria (GiB) | G4dn NVMe (T4) | G5 NVMe (A10G) | G6 NVMe (L4) | G6e NVMe (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 | 3760 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 | 3760 GiB | 3.800 GiB |
## Configuración del tamaño de almacenamiento efímero
Si `scratchStorageMode` está configurado en`LOCAL`, puede solicitar un aumento del almacenamiento efímero por tarea mediante la `disk` directiva (o equivalente) de la definición de su flujo de trabajo. HealthOmics trata la `disk` directiva como una sugerencia y proporciona un volumen redondeado a los siguientes 16 GiB. El uso de la `disk` directiva no afecta a la selección del tipo de instancia. El tipo de instancia se selecciona basándose únicamente en `cpu``memory`, y`acceleratorType`. Para obtener más información, consulte [Recursos de tareas en una definición de HealthOmics flujo de trabajo](task-resources.md).
Si no hay ninguna `disk` directiva, la tarea recibe los 16 GiB predeterminados. Las tareas no pueden tener menos almacenamiento efímero que el predeterminado.
No necesitas dimensionar tu almacenamiento efímero para las imágenes de contenedores extraídos, que se contabilizan por separado. Para obtener más información, consulte [Imágenes de contenedores para flujos de trabajo privados](workflows-ecr.md).
### Cuándo usar la directiva de discos
Usa la `disk` directiva en la definición de la tarea cuando el almacenamiento efímero predeterminado para el tipo de instancia elegido no sea suficiente para los requisitos de la tarea. Por ejemplo, cuando una tarea escribe grandes volúmenes de datos en. `/tmp`
### Casos de uso habituales para aumentar el almacenamiento efímero
1. **RNA-Seq Detección de fusión:** los RNA-seq flujos de trabajo generan grandes BAM intermedios y los procesos de tareas a menudo requieren que tanto los FastQs sin procesar como los resultados alineados estén presentes simultáneamente, lo que requiere discos de memoria virtual de gran tamaño (por ejemplo, 512 GiB por tarea).
1. **Ensamblaje del genoma de Novo:** los flujos de trabajo de Long-read ensamblaje necesitan grandes volúmenes de memoria para procesar las lecturas sin procesar y los artefactos de ensamblaje temporales que se reescriben y reorganizan repetidamente antes de su salida. Estas tareas consumen mucha memoria y disco y, a veces, requieren varios TiB de almacenamiento efímero.
1. **Procesamiento de llamadas de variantes o BAM:** los flujos de trabajo de llamadas de variantes requieren una gran cantidad de espacio de almacenamiento temporal para los pasos de alineación y clasificación que permiten leer y reescribir archivos BAM o CRAM de gran tamaño de forma repetida. Las necesidades de almacenamiento efímero suelen ser de cientos de GiB.
### Sintaxis directiva por motor
La siguiente tabla muestra la directiva equivalente para cada lenguaje de flujo de trabajo.
| Motor | Directiva | Ejemplo |
| --- | --- | --- |
| WDL 1.1 | disks | disks: "/tmp 700 GiB" |
| Siguiente flujo | disk | disk '700 GB' |
| CWL | tmpdirMin | tmpdirMin: 716800(valor en MiB) |
Los siguientes ejemplos muestran cómo configurar una tarea que solicita 700 GiB de almacenamiento efímero. HealthOmics redondea esto al nivel de 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
```
------
Para obtener más información sobre la sintaxis de las directivas admitidas, consulte [Especificaciones de la definición del flujo de trabajo de WDL](workflow-languages-wdl.md) y[Especificaciones de la definición del flujo de trabajo de Nextflow](workflow-definition-nextflow.md).
### Herramientas bioinformáticas comunes y almacenamiento efímero
Muchas herramientas bioinformáticas escriben archivos temporales de gran tamaño durante su ejecución. Cuando `scratchStorageMode` esté configurado en`LOCAL`, redirija estas herramientas para utilizarlas de `/tmp` forma que, desde cero, I/O se dirija al volumen local rápido en lugar de al sistema de archivos de ejecución compartida. Los siguientes ejemplos muestran los indicadores relevantes para las herramientas más utilizadas.
------
#### [ 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
```
------
### Tamaños compatibles
Los tamaños solicitados se redondean al alza al incremento de 16 GiB más cercano, empezando por el valor predeterminado de 16 GiB (16, 32, 48, 64,... hasta 3.072 GiB). El tamaño máximo admitido es de 3.072 GiB por tarea.
Si el tamaño solicitado supera los 3.072 GiB HealthOmics , aprovisiona 3.072 GiB y escribe una advertencia en el registro de ejecución. La tarea no falla automáticamente.
**nota**
En el caso de `disk` las directivas basadas en expresiones, como los cierres de Nextflow o las expresiones de WDL`disks: ceil(size(input_bam, "GiB") * 2.5)`, el valor se evalúa en tiempo de ejecución, no en. `CreateWorkflow` Si el tamaño evaluado supera los 3.072 GiB, la tarea falla en tiempo de ejecución y se cobrarán los costes informáticos incurridos hasta ese momento.
### `Formularios de discos WDL compatibles`
Para ver la lista completa de los `disks` formularios WDL aceptados, consulte. [`Formularios de discos WDL compatibles`](workflow-languages-wdl.md#workflow-wdl-disks-forms)
### Uso de la directiva scratch de Nextflow
Para los flujos de trabajo de Nextflow, puede usar la `scratch` directiva para controlar dónde escriben los procesos los archivos de trabajo temporales. Para obtener información sobre los valores admitidos y el uso recomendado con el almacenamiento efímero, consulte. [Uso eficiente del almacenamiento temporal en Nextflow](workflow-definition-nextflow.md#nextflow-scratch-storage)
## Supervisión del almacenamiento efímero
HealthOmics escribe métricas de almacenamiento efímero por tarea en los registros de manifiesto. CloudWatch Las métricas incluyen datos de almacenamiento efímero por tarea del tamaño del volumen aprovisionado y del uso para cada tarea. `scratchStorageReservedGiB` `scratchStorageUtilizedGiB` Revisa el registro de manifiestos para determinar si las tareas estaban sobreaprovisionadas o insuficientemente aprovisionadas sin consultarlas directamente. CloudWatch Para obtener más información sobre los registros de manifiestos, consulte. [Supervisión HealthOmics con CloudWatch registros](monitoring-cloudwatch-logs.md)
## Cómo se factura el almacenamiento efímero
Solo se le facturará el almacenamiento efímero aprovisionado por encima de la asignación predeterminada. Las solicitudes que superen el valor predeterminado de tu `disk` directiva se redondean al nivel compatible más cercano.
El almacenamiento efímero de las instancias de GPU ya está incluido en los precios de las instancias. El almacenamiento efímero en las tareas de GPU no conlleva ningún cargo adicional.
## Consideraciones y limitaciones
| Consideración | Detalle |
| --- | --- |
| El almacenamiento efímero no es persistente | Los volúmenes de almacenamiento efímero siempre se eliminan al finalizar la tarea. Los datos no /tmp se guardan, exportan ni están disponibles para tareas o ejecuciones posteriores. Los datos /tmp guardados en un almacenamiento efímero no pueden ser un resultado de una tarea o un flujo de trabajo; esto provocará un error durante el tiempo de ejecución. |
| El almacenamiento efímero no se comparte entre tareas | Cada tarea recibe su propio volumen de almacenamiento efímero aislado. Las tareas no pueden acceder a los directorios de las demás. /tmp Los datos que se deben compartir entre las tareas se deben escribir en el sistema de archivos de ejecución compartido. |
| No se puede cambiar el tamaño del almacenamiento a mitad de la tarea | El tamaño de almacenamiento se fija al inicio de la tarea. No puede aumentar ni disminuir el almacenamiento asignado mientras se está ejecutando una tarea. |
| Working-directory scratch no se redirige automáticamente | Los flujos de trabajo que escriben scratch en el directorio de trabajo (por ejemplo input/./,out/, o) no se benefician automáticamente. Actualice su flujo de trabajo para redirigir I/O el borrador a /tmp o$TMPDIR. |
| Los datos de Scratch no se escriben /tmp como se esperaba | Asegúrese de que los procesos de la tarea escriban de forma explícita en otra ubicación /tmp y de que los comandos de la tarea no estén mapeados $TMPDIR a otra ubicación. |
| Las instancias de GPU siempre utilizan almacenamiento efímero | Las tareas de GPU siempre se montan /tmp en el almacén de instancias de NVMe local. Si se establece scratchStorageMode en, SHARED no se inhabilita el almacenamiento efímero para las tareas de la GPU. |
| Instancias de GPU: la capacidad de NVMe es fija | Las instancias de GPU no admiten el tamaño de disco personalizado. HealthOmics ignora disk las directivas y proporciona la capacidad NVMe predeterminada para el tipo de instancia. |
| Máximo 3.072 GiB por tarea (CPU) | Las solicitudes que superen los 3.072 GiB se aprovisionan en 3.072 GiB con una advertencia de registro de ejecución. Las tareas no fallan. |
| Solo niveles compatibles (CPU) | Los tamaños solicitados se redondean al alza al incremento de 16 GiB más cercano (16, 32, 48, 64,... hasta 3.072 GiB). |
| Expression-based directivas evaluadas en tiempo de ejecución | disklos valores calculados a partir de las expresiones se validan al inicio de la tarea, no enCreateWorkflow. Los costes de procesamiento hasta ese punto se cobran si la tarea falla en tiempo de ejecución. |
| SHAREDel modo ignora todas las directivas del disco (solo la CPU) | Las directivas when scratchStorageMode is SHARED disktmpdirMin, y equivalentes se ignoran en las tareas de la CPU. No se aprovisiona ningún volumen de almacenamiento local. Las tareas de la GPU no se ven afectadas, ya que siempre utilizan un NVMe local. |
## Solución de problemas de almacenamiento efímero
### La tarea falla cuando el almacenamiento efímero está agotado
Una tarea falla cuando el almacenamiento efímero alcanza su capacidad máxima. Revisa los registros de tus CloudWatch manifiestos para determinar cuánto espacio de almacenamiento utilizó realmente tu tarea y, a continuación, agrega o aumenta la `disk` directiva para solicitar un nivel más grande.
```
# Before: 4-vCPU task using the 16 GiB default
runtime { cpu: 4 }
# After: explicitly request 400 GiB
runtime { cpu: 4, disks: "400 GiB" }
```
### No parece que se utilice el almacenamiento efímero
Llama `GetRun` y comprueba el `scratchStorageMode` campo. Si el valor es`SHARED`, el almacenamiento efímero no está habilitado para esa ejecución. Configure `--scratch-storage-mode LOCAL` su próxima `start-run` llamada.
```
aws omics get-run --id {{run-id}}
```