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.
**Topics**
+ [Benefícios principais](#ephemeral-storage-key-benefits)
+ [Como funciona o armazenamento efêmero](#ephemeral-storage-how-it-works)
+ [Habilitando o armazenamento efêmero](#ephemeral-storage-enable)
+ [Alocação de armazenamento padrão](#ephemeral-storage-default-allocation)
+ [Configurando o tamanho do armazenamento efêmero](#ephemeral-storage-configure-size)
+ [Monitorando o armazenamento efêmero](#ephemeral-storage-monitoring)
+ [Como o armazenamento temporário é cobrado](#ephemeral-storage-billing)
+ [Considerações e limitações](#ephemeral-storage-considerations)
+ [Solução de problemas de armazenamento temporário](#ephemeral-storage-troubleshooting)
## Benefícios principais
+ **Execução mais rápida de tarefas:** o armazenamento temporário pode melhorar o desempenho da execução ao reduzir o sistema de arquivos compartilhado. I/O
+ **Desempenho previsível:** as tarefas não competem com outras tarefas em execução simultânea pela I/O largura de banda, reduzindo a variabilidade e a limitação associadas a um sistema de arquivos de rede compartilhado.
+ **Custos mais baixos:** a execução mais rápida de tarefas reduz diretamente o tempo de computação e o custo das tarefas I/O vinculadas que são usadas. `/tmp` Para execuções usando armazenamento de execução estático, isso pode reduzir a quantidade de armazenamento de execução provisionado de que você precisa. As execuções dinâmicas não exigem alterações.
## 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.
`scratchStorageMode`determina onde seu fluxo de trabalho grava dados preliminares. Possíveis valores:
+ `LOCAL`— O armazenamento temporário é colocado no disco local. I/O O Scratch tem IOPS e taxa de transferência dedicados.
+ `SHARED`— O sistema de arquivos compartilhado é usado (padrão). O Scratch I/O compete com o diretório de trabalho.
Para obter mais informações, consulte [Comece uma corrida em HealthOmics](starting-a-run.md).
**nota**
As tarefas de GPU sempre usam armazenamento efêmero NVMe local para dados preliminares e `scratchStorageMode` sempre usam para tarefas de GPU. `LOCAL`
### 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, passe`defaultRunSetting`. 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).
`scratchStorageMode`só é 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](#ephemeral-storage-supported-sizes).
### 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`
| Tamanho | GPUs | vCPU | Memória (GiB) | 4Gdn NVMe (T4) | 5G NVMe (A10G) | G6 NVMe (L4) | 6e 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 | 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 |
## Configurando o tamanho do armazenamento efêmero
Quando `scratchStorageMode` definido como`LOCAL`, 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 `cpu``memory`, `acceleratorType` e. Para obter mais informações, consulte [Recursos de tarefas em uma definição de HealthOmics fluxo de trabalho](task-resources.md).
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](workflows-ecr.md).
### 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
1. **RNA-Seq Detecção de fusão:** RNA-seq os fluxos de trabalho geram grandes BAMs intermediários e os processos de tarefas geralmente exigem que os FASTQs brutos e as saídas alinhadas estejam presentes simultaneamente, exigindo discos de trabalho grandes (por exemplo, 512 GiB por tarefa).
1. **Montagem do Genoma De Novo:** os fluxos de trabalho de Long-read montagem precisam de grandes volumes de rascunho para processar leituras brutas e artefatos de montagem temporários que são repetidamente reescritos e reorganizados antes da saída. Essas tarefas consomem muita memória e disco, às vezes exigindo vários TiB de armazenamento temporário.
1. **Chamada de variantes/Processamento BAM:** os fluxos de trabalho de chamadas de variantes exigem um armazenamento temporário substancial para etapas de alinhamento e classificação que leem e reescrevem repetidamente grandes arquivos BAM ou CRAM. As necessidades de armazenamento efêmero geralmente são de centenas de GiB.
### Sintaxe da diretiva por mecanismo
A tabela a seguir mostra a diretiva equivalente para cada linguagem de fluxo de trabalho.
| Mecanismo | Diretiva | Exemplo |
| --- | --- | --- |
| REDE SOCIAL 1.1 | disks | disks: "/tmp 700 GiB" |
| Próximo fluxo | disk | disk '700 GB' |
| CAPUZ | tmpdirMin | tmpdirMin: 716800(valor em MiB) |
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](workflow-languages-wdl.md) e. [Especificações da definição do fluxo de trabalho do Nextflow](workflow-definition-nextflow.md)
### 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 como`LOCAL`, 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.
**nota**
Para `disk` diretivas baseadas em expressões, como encerramentos do Nextflow ou expressões WDL como, o valor é avaliado em tempo de `disks: ceil(size(input_bam, "GiB") * 2.5)` execução, não em. `CreateWorkflow` Se o tamanho avaliado exceder 3.072 GiB, a tarefa falhará em tempo de execução e quaisquer custos de computação incorridos até esse ponto serão cobrados.
### Formulários de `discos` WDL compatíveis
Para obter a lista completa dos `disks` formulários da Biblioteca Digital Mundial aceitos, consulte[Formulários de `discos` WDL compatíveis](workflow-languages-wdl.md#workflow-wdl-disks-forms).
### 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](workflow-definition-nextflow.md#nextflow-scratch-storage)
## 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 (s`scratchStorageReservedGiB`) 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, consulte[Monitoramento HealthOmics com CloudWatch registros](monitoring-cloudwatch-logs.md).
## 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
| Consideração | Detalhes |
| --- | --- |
| O armazenamento temporário não é persistente | Os volumes de armazenamento efêmeros são sempre excluídos quando a tarefa é encerrada. Os dados de /tmp entrada não são salvos, exportados ou disponibilizados para tarefas ou execuções subsequentes. Os dados inseridos /tmp no armazenamento temporário não podem ser uma saída de tarefa ou uma saída de fluxo de trabalho; isso resultará em uma falha no tempo de execução. |
| O armazenamento temporário não é compartilhado entre as tarefas | Cada tarefa recebe seu próprio volume de armazenamento efêmero isolado. As tarefas não podem acessar os /tmp diretórios umas das outras. Os dados que devem ser compartilhados entre tarefas devem ser gravados no sistema de arquivos de execução compartilhado. |
| O armazenamento não pode ser redimensionado no meio da tarefa | O tamanho do armazenamento é fixo no início da tarefa. Você não pode aumentar ou diminuir o armazenamento alocado enquanto uma tarefa está em execução. |
| Working-directory scratch não é redirecionado automaticamente | Fluxos de trabalho que gravam de rascunho no diretório de trabalho — por exemploinput/,./,, ou out/ — não se beneficiam automaticamente. Atualize seu fluxo de trabalho para redirecionar o scratch I/O para /tmp ou$TMPDIR. |
| Os dados do Scratch não estão sendo gravados /tmp conforme o esperado | Certifique-se de que seus processos de tarefas sejam gravados explicitamente /tmp e que seus comandos de tarefa não tenham sido mapeados $TMPDIR para outro local. |
| As instâncias de GPU sempre usam armazenamento efêmero | As tarefas de GPU sempre são montadas /tmp no armazenamento de instâncias NVMe local. scratchStorageModeA configuração como SHARED não desativa o armazenamento efêmero para tarefas de GPU. |
| Instâncias de GPU: a capacidade do NVMe é fixa | O dimensionamento de disco personalizado não é compatível com instâncias de GPU. HealthOmics ignora as disk diretivas e fornece a capacidade NVMe padrão para o tipo de instância. |
| Máximo de 3.072 GiB por tarefa (CPU) | Solicitações que excedam 3.072 GiB são provisionadas em 3.072 GiB com um aviso de registro de execução. As tarefas não falharam. |
| Somente níveis suportados (CPU) | Os tamanhos solicitados são arredondados para o incremento mais próximo de 16 GiB (16, 32, 48, 64,... até 3.072 GiB). |
| Expression-based diretivas avaliadas em tempo de execução | diskvalores calculados a partir de expressões são validados no início da tarefa, não em. CreateWorkflow Os custos de computação até esse ponto são cobrados se a tarefa falhar em tempo de execução. |
| SHAREDo modo ignora todas as diretivas de disco (somente CPU) | As diretivas SHARED when scratchStorageMode is disktmpdirMin,, e equivalentes são ignoradas para tarefas de CPU. Nenhum volume de armazenamento local é provisionado. As tarefas da GPU não são afetadas, elas sempre usam o NVMe local. |
## 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 for`SHARED`, o armazenamento temporário não está habilitado para essa execução. `--scratch-storage-mode LOCAL`Defina sua próxima `start-run` chamada.
```
aws omics get-run --id {{run-id}}
```