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 las 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. Puedes aumentar la cantidad de almacenamiento efímero asignada a las tareas individuales en tu definición de flujo de trabajo, hasta un máximo de 3072 GiB por tarea. Todos los datos almacenados se cifran en reposo/tmp.

Ventajas principales

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 de 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 cuando finaliza la tarea. Los datos en los que /tmp se escribe no se conservan, no se exportan ni son accesibles para otras tareas o ejecuciones posteriores.

Donde los flujos de trabajo escriben archivos temporales

Los flujos de trabajo se benefician del almacenamiento efímero cuando los procesos de tareas se dirigen 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 se hayan asignado 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, no requieren cambios en el flujo de trabajo. Los flujos de trabajo que no dirijan explícitamente los procesos desde cero /tmp escribirán los datos desde cero en el directorio de trabajo del sistema de archivos compartido utilizado para el almacenamiento de la ejecución, aunque las herramientas utilizadas pueden aprovechar las ventajas del /tmp 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 termina.

Permisos

HealthOmics administra la conexión y el ciclo de vida de los volúmenes de almacenamiento efímeros 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 únicamente a las instancias de CPU y a todas las tareas de esa ejecución.

scratchStorageModedetermina dónde escribe el flujo de trabajo los datos desde cero. Valores posibles:

Para obtener más información, consulte Empieza una carrera en HealthOmics.

Opte por el almacenamiento efímero

Para habilitar el almacenamiento efímero para una ejecución, configúralo scratchStorageMode LOCAL al iniciar 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

Para las ejecuciones por lotes, scratchStorageMode transfiérelo. 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"}
        }
      ]
    }'

Opte por no utilizar 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 es asíSHARED, todas las directivas de la definición del flujo de trabajo disk y las equivalentes se ignoran y el /tmp sistema de archivos compartido las respalda. Esta configuración solo se aplica a las instancias de CPU. Las tareas de GPU siempre utilizan almacenamiento efímero local de NVMe y no se pueden desactivar.

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

scratchStorageModesolo se devuelve en la GetRun respuesta si se pasó explícitamente en la StartRun solicitud. SHAREDes 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 de instancias, de procesamiento y Memory-optimized estándar. No es necesario especificar una disk directiva para recibir este valor predeterminado. Para configurar el almacenamiento adicional, utilice la disk directiva. Puedes aumentar la cantidad de almacenamiento efímero asignada a tareas individuales en tu definición de flujo de trabajo, hasta un máximo de 3072 GiB por tarea. Se le factura por el almacenamiento que supere 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.

Almacenamiento efímero para instancias de computación acelerada

La capacidad de almacenamiento de las instancias de la GPU es fija por tipo de instancia y se proporciona sin costo adicional.

Las tareas de GPU siempre utilizan almacenamiento efímero local de NVMe. 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 por el tipo de instancia seleccionado para la tarea y cpu acceleratorType los memory requisitos.

Configuración del tamaño de almacenamiento efímero

Si scratchStorageMode está establecido enLOCAL, puedes solicitar un mayor almacenamiento efímero por tarea mediante la disk directiva (o una equivalente) de tu definición de flujo de trabajo. HealthOmics trata la disk directiva como una sugerencia y proporciona un volumen redondeado a los 16 GiB siguientes. 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 cpumemory, yacceleratorType. Para obtener más información, consulte Recursos de tareas en una definición de flujo de trabajo HealthOmics.

Si no hay ninguna disk directiva, la tarea recibe los 16 GiB predeterminados. Las tareas no pueden tener un almacenamiento efímero inferior al predeterminado.

No es necesario ajustar el tamaño de su almacenamiento efímero para las imágenes extraídas del contenedor, que se contabilizan por separado. Para obtener más información, consulte Imágenes de contenedores para flujos de trabajo privados.

¿Cuándo usar la directiva de disco

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

Sintaxis de directivas por motor

En la siguiente tabla se muestra la directiva equivalente para cada lenguaje de flujo de trabajo.

Los siguientes ejemplos muestran cómo configurar una tarea que solicita 700 GiB de almacenamiento efímero. HealthOmics lo redondea hasta el 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 directivas admitida, consulte Características específicas de la definición del flujo de trabajo de W yEspecificaciones de la definición del flujo de trabajo de Next.

Ejemplo: dimensionamiento de disco basado en expresiones

En lugar de un tamaño fijo, puedes establecer la disk directiva en una expresión que el motor de flujo de trabajo evalúe para cada tarea en tiempo de ejecución. El siguiente proceso de Nextflow utiliza un cierre que escala la solicitud según el número de intentos de tarea. Si la tarea falla por cualquier motivo y Nextflow la vuelve a intentar, el reintento solicita un volumen mayor.

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)

El motor de flujo de trabajo evalúa la expresión para cada intento de tarea. HealthOmics a continuación, redondea el tamaño resuelto al siguiente incremento de 16 GiB.

Herramientas bioinformáticas comunes y almacenamiento efímero

Muchas herramientas bioinformáticas escriben archivos temporales de gran tamaño durante la ejecución. Cuando scratchStorageMode esté configurado enLOCAL, redirija estas herramientas para usarlas de /tmp forma que Scratch I/O vaya al volumen local rápido en lugar de al sistema de archivos de ejecución compartida. En los siguientes ejemplos se muestran los indicadores correspondientes a las herramientas de uso habitual.

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 incremento de 16 GiB más cercano, partiendo del valor predeterminado de 16 GiB (16, 32, 48, 64,... hasta 3072 GiB). El tamaño máximo admitido es de 3072 GiB por tarea.

Si el tamaño solicitado supera los 3072 GiB, HealthOmics aprovisiona 3072 GiB y escribe una advertencia en el registro de ejecución. La tarea no falla automáticamente.

Formularios de discos WDL compatibles

Para ver la lista completa de los disks formularios WDL aceptados, consulte. Formularios de discos WDL compatibles

Uso de la directiva Scratch de Nextflow

En el caso de los flujos de trabajo de Nextflow, puedes 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. Cómo usar el almacenamiento desde cero de manera eficiente en Nextflow

Supervisar el 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 sobre el tamaño del volumen (asscratchStorageReservedGiB) y el uso (as) del volumen aprovisionado para cada tarea. scratchStorageUtilizedGiB Revisa el registro del manifiesto para determinar si las tareas se aprovisionaron en exceso o de forma insuficiente sin consultarlas directamente. CloudWatch Para obtener más información sobre los registros de manifiestos, consulte. Supervisión HealthOmics con CloudWatch registros

Cómo se factura el almacenamiento efímero

Solo se le factura por 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 admitido más cercano.

El almacenamiento efímero de las instancias de GPU ya está incluido en el precio de las instancias. No se aplica ningún cargo adicional por el almacenamiento efímero en las tareas de GPU.

Consideraciones y limitaciones

Solución de problemas de almacenamiento efímero

La tarea falla cuando se agota el almacenamiento efímero

Una tarea falla cuando el almacenamiento efímero alcanza su capacidad máxima. Revisa tus registros de CloudWatch manifiestos para determinar cuánto almacenamiento utilizó realmente tu tarea y, a continuación, agrega o aumenta la disk directiva para solicitar un nivel mayor.

# 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 esté utilizando el almacenamiento efímero

Llame GetRun y compruebe el scratchStorageMode campo. Si el valor esSHARED, el almacenamiento efímero no está habilitado para esa ejecución. Prepara --scratch-storage-mode LOCAL tu próxima start-run llamada.

aws omics get-run --id run-id