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.

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

scratchStorageModedetermina dónde escribe su flujo de trabajo los datos preliminares. Valores posibles:

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

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

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

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.

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

Si scratchStorageMode está configurado enLOCAL, 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 cpumemory, yacceleratorType. Para obtener más información, consulte Recursos de tareas en una definición de HealthOmics flujo de trabajo.

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.

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

Sintaxis directiva por motor

La siguiente tabla 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 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 yEspecificaciones de la definición del flujo de trabajo de Nextflow.

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 enLOCAL, 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.

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

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

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

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

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 esSHARED, 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