As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Armazenamento temporário para tarefas de fluxo de trabalho HealthOmics

HealthOmics fornece armazenamento temporário para tarefas de fluxo de trabalho usando o diretório. /tmp Esse armazenamento é temporário e exclusivo para cada tarefa em um fluxo de trabalho. HealthOmics aloca 16 GiB de armazenamento temporário para cada instância de tarefa por padrão. Você pode aumentar a quantidade de armazenamento temporário alocado para tarefas individuais em sua definição de fluxo de trabalho, até um máximo de 3.072 GiB por tarefa. Todos os dados armazenados /tmp são criptografados em repouso.

Benefícios principais

Como funciona o armazenamento efêmero

Quando você ativa o armazenamento temporário, HealthOmics monta um volume de armazenamento local dedicado /tmp para cada instância de tarefa do fluxo de trabalho. O armazenamento temporário é destinado a arquivos temporários gerados durante a execução da tarefa. Os volumes de armazenamento efêmeros são sempre excluídos quando a tarefa é encerrada. Os dados gravados não /tmp são persistentes, exportados ou acessíveis para outras tarefas ou execuções subsequentes.

Onde os fluxos de trabalho gravam arquivos temporários

Os fluxos de trabalho se beneficiam do armazenamento efêmero quando os processos de tarefas são direcionados para o. I/O /tmp As linguagens de fluxo de trabalho de bioinformática usam o /tmp diretório (e as $TMP variáveis de $TMPDIR ambiente) para arquivos intermediários temporários e de curta duração durante a execução da tarefa. Certifique-se de que seus comandos de tarefa não tenham sido mapeados $TMPDIR para outro local.

Processos de tarefas de fluxo de trabalho que /tmp gravam para usar automaticamente o armazenamento temporário quando habilitados, sem exigir alterações no fluxo de trabalho. Os fluxos de trabalho que não direcionam explicitamente os processos temporários /tmp gravarão dados temporários no diretório de trabalho no sistema de arquivos compartilhado usado para executar o armazenamento, embora as ferramentas usadas possam tirar proveito do armazenamento /tmp temporário.

Criptografia em repouso

Todo o armazenamento temporário é criptografado em repouso usando uma chave gerenciada pelo serviço. AWS KMS As instâncias de computação acelerada são criptografadas por hardware com uma chave exclusiva por volume que é destruída quando a instância é encerrada.

Permissões

HealthOmics gerencia a conexão e o ciclo de vida de volumes de armazenamento efêmeros em seu nome. Nenhuma permissão adicional do IAM é necessária em sua função de execução de tarefas.

Habilitando o armazenamento efêmero

Você pode redirecionar o scratch I/O para o armazenamento local configurando scratchStorageMode na StartRun API. A scratchStorageMode configuração se aplica somente às instâncias de CPU e se aplica a todas as tarefas nessa execução.

scratchStorageModedetermina onde seu fluxo de trabalho grava dados preliminares. Possíveis valores:

Para obter mais informações, consulte Comece uma corrida em HealthOmics.

Opte pelo armazenamento temporário

Para ativar o armazenamento temporário para uma execução, defina como LOCAL quando você inicia scratchStorageMode a execução.

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 execuções scratchStorageMode em lote, passedefaultRunSetting. A configuração se aplica a todas as execuções no 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 não usar o armazenamento temporário

Para desativar o armazenamento temporário para uma execução específica (por exemplo, para isolar uma falha), defina como. 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

Quando scratchStorageMode éSHARED, todas as disk diretivas equivalentes na definição do fluxo de trabalho são ignoradas e /tmp são apoiadas pelo sistema de arquivos compartilhado. Essa configuração se aplica somente às instâncias de CPU. As tarefas de GPU sempre usam armazenamento temporário NVMe local e não podem ser desativadas.

Verifique o modo efetivo

O armazenamento temporário está desativado por padrão. Quando scratchStorageMode é omitido de uma StartRun solicitação, scratchStorageMode é definido como SHARED (padrão).

scratchStorageModesó é retornado na GetRun resposta se tiver sido explicitamente passado na StartRun solicitação. SHAREDé o valor padrão se for omitido. Ligue GetRun para confirmar o modo de armazenamento efetivo para uma corrida.

aws omics get-run --id run-id

Alocação de armazenamento padrão

A alocação padrão de armazenamento temporário é de 16 GiB por tarefa para todos os tipos padrão, de computação e instância. Memory-optimized Você não precisa especificar uma disk diretiva para receber esse padrão. Para configurar armazenamento adicional, use a disk diretiva. Você pode aumentar a quantidade de armazenamento temporário alocado para tarefas individuais em sua definição de fluxo de trabalho, até um máximo de 3.072 GiB por tarefa. Você é cobrado pelo armazenamento acima do padrão de 16 GiB.

O armazenamento temporário pode ser configurado em incrementos de 16 GiB. Para obter mais informações, consulte Tamanhos suportados.

Armazenamento temporário para instâncias de computação acelerada

A capacidade de armazenamento da instância de GPU é fixa por tipo de instância e fornecida sem custo adicional.

As tarefas de GPU sempre usam armazenamento temporário NVMe local. A scratchStorageMode configuração ativada StartRun não se aplica às tarefas da GPU e definir esse valor como não SHARED terá efeito nas instâncias da GPU. A capacidade é fixa por tipo de instância e não pode ser personalizada usando a disk diretiva. A capacidade do NVMe é predeterminada pelo tipo de instância selecionado para os requisitos e tarefas. cpu memory acceleratorType

Configurando o tamanho do armazenamento efêmero

Quando scratchStorageMode definido comoLOCAL, você pode solicitar maior armazenamento temporário por tarefa usando a disk diretiva (ou equivalente) na definição do fluxo de trabalho. HealthOmics trata a disk diretiva como uma dica e fornece um volume arredondado para os próximos 16 GiB. O uso da disk diretiva não afeta a seleção do tipo de instância. O tipo de instância é selecionado com base somente em cpumemory, acceleratorType e. Para obter mais informações, consulte Recursos de tarefas em uma definição de HealthOmics fluxo de trabalho.

Se nenhuma disk diretiva estiver presente, a tarefa receberá os 16 GiB padrão. As tarefas não podem ter menos do que o armazenamento efêmero padrão.

Você não precisa dimensionar seu armazenamento temporário para imagens de contêineres extraídos, que são contabilizadas separadamente. Para obter mais informações, consulte Imagens de contêiner para fluxos de trabalho privados.

Quando usar a diretiva de disco

Use a disk diretiva na definição da tarefa quando o armazenamento temporário padrão para o tipo de instância escolhido não for suficiente para os requisitos da tarefa. Por exemplo, quando uma tarefa grava grandes volumes de dados em/tmp.

Casos de uso comuns para armazenamento efêmero maior

Sintaxe da diretiva por mecanismo

A tabela a seguir mostra a diretiva equivalente para cada linguagem de fluxo de trabalho.

Os exemplos a seguir mostram como configurar uma tarefa que solicita 700 GiB de armazenamento temporário. HealthOmics arredonda isso para o nível 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 obter mais informações sobre a sintaxe de diretiva compatível, consulte Especificidades da definição do fluxo de trabalho da WDL e. Especificações da definição do fluxo de trabalho do Nextflow

Ferramentas comuns de bioinformática e armazenamento efêmero

Muitas ferramentas de bioinformática gravam grandes arquivos temporários durante a execução. Quando scratchStorageMode estiver definido comoLOCAL, redirecione essas ferramentas para uso de /tmp forma que o scratch I/O vá para o volume local rápido em vez do sistema de arquivos de execução compartilhado. Os exemplos a seguir mostram os sinalizadores relevantes para ferramentas comumente usadas.

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

Tamanhos suportados

Os tamanhos solicitados são arredondados para o incremento mais próximo de 16 GiB, começando pelo padrão de 16 GiB (16, 32, 48, 64,... até 3.072 GiB). O tamanho máximo suportado é de 3.072 GiB por tarefa.

Se um tamanho solicitado exceder 3.072 GiB, provisiona HealthOmics 3.072 GiB e grava um aviso no log de execução. A tarefa não falha automaticamente.

Formulários de discos WDL compatíveis

Para obter a lista completa dos disks formulários da Biblioteca Digital Mundial aceitos, consulteFormulários de discos WDL compatíveis.

Usando a diretiva de rascunho Nextflow

Para fluxos de trabalho do Nextflow, você pode usar a scratch diretiva para controlar onde os processos gravam arquivos de trabalho temporários. Para obter informações sobre os valores suportados e o uso recomendado com armazenamento temporário, consulte. Usando o armazenamento temporário de forma eficiente no Nextflow

Monitorando o armazenamento efêmero

HealthOmics grava métricas de armazenamento efêmero por tarefa nos registros do manifesto. CloudWatch As métricas incluem dados de armazenamento efêmero por tarefa do tamanho (sscratchStorageReservedGiB) e uso (s) do volume provisionado para cada tarefa. scratchStorageUtilizedGiB Analise o registro do manifesto para determinar se as tarefas foram superprovisionadas ou subprovisionadas sem consultar diretamente. CloudWatch Para obter detalhes sobre registros de manifestos, consulteMonitoramento HealthOmics com CloudWatch registros.

Como o armazenamento temporário é cobrado

Você é cobrado somente pelo armazenamento temporário provisionado acima da alocação padrão. As solicitações acima do padrão em sua disk diretiva são arredondadas para o nível suportado mais próximo.

As instâncias de GPU têm armazenamento efêmero já contabilizado nos preços das instâncias. Não há cobrança adicional pelo armazenamento temporário em tarefas de GPU.

Considerações e limitações

Solução de problemas de armazenamento temporário

A tarefa falha com o armazenamento efêmero esgotado

Uma tarefa falha quando o armazenamento efêmero atinge a capacidade máxima. Analise seus registros de CloudWatch manifesto para determinar quanto armazenamento sua tarefa realmente usou e, em seguida, adicione ou aumente a disk diretiva para solicitar um nível maior.

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

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

O armazenamento efêmero não parece ser utilizado

Ligue GetRun e verifique o scratchStorageMode campo. Se o valor forSHARED, o armazenamento temporário não está habilitado para essa execução. --scratch-storage-mode LOCALDefina sua próxima start-run chamada.

aws omics get-run --id run-id