本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。 # 用于工作流程任务的临时存储 HealthOmics HealthOmics 使用目录为工作流任务提供临时存储。`/tmp`此存储空间是临时的，对于工作流程中的每项任务来说都是唯一的。 HealthOmics 默认情况下，会为每个任务实例分配 16 GiB 的临时存储空间。在工作流程定义中，您可以增加分配给各个任务的临时存储量，每个任务最多可达 3,072 GiB。存储在中的所有数据`/tmp`都是静态加密的。 **Topics** + [主要优势](#ephemeral-storage-key-benefits) + [临时存储的工作原理](#ephemeral-storage-how-it-works) + [启用临时存储](#ephemeral-storage-enable) + [默认存储分配](#ephemeral-storage-default-allocation) + [配置临时存储大小](#ephemeral-storage-configure-size) + [监控临时存储](#ephemeral-storage-monitoring) + [临时存储的计费方式](#ephemeral-storage-billing) + [注意事项和限制](#ephemeral-storage-considerations) + [对临时存储进行故障排除](#ephemeral-storage-troubleshooting) ## 主要优势 + **更快地执行任务：**临时存储可以通过减少共享文件系统来提高运行性能。 I/O + **可预测的性能：**任务不会与其他同时运行的任务争夺 I/O 带宽，从而减少了与共享网络文件系统相关的可变性和限制。 + **降低成本：**更快的任务执行速度可直接减少所使用的 I/O 绑定任务的计算时间和成本`/tmp`。对于使用静态运行存储空间的运行，这可以减少所需的预配置运行存储量。动态运行无需更改。 ## 临时存储的工作原理 启用临时存储时，会在每个`/tmp`工作流程任务实例上 HealthOmics 安装一个专用的本地存储卷。临时存储用于存储任务执行期间生成的临时文件。任务终止时，临时存储卷总是会被删除。写入`/tmp`的数据无法保存、导出，也无法供其他任务或后续运行访问。 ### 工作流程在哪里写入临时文件 当任务进程直接从头开始时，工作流程将受益于临时存储。 I/O `/tmp`在任务执行期间，生物信息学工作流程语言使用`/tmp`目录（和`$TMPDIR`环境变量）来存储临时的、短暂的中间文件。`$TMP`确保您的任务命令未映射`$TMPDIR`到其他位置。 写入的工作流任务进程在启用后`/tmp`会自动使用临时存储，无需更改工作流程。尽管使用的工具可能会利用临时存储，但未明确`/tmp`将暂存进程定向到的工作流会将临时数据写入用于运行存储的共享文件系统`/tmp`上的工作目录。 ### 静态加密 所有临时存储都使用服务托管密钥进行静态加密。 AWS KMS 加速计算实例使用每个卷的唯一密钥进行硬件加密，该密钥将在实例终止时销毁。 ### Permissions HealthOmics 代表您管理临时存储卷的附件和生命周期。您的任务执行角色不需要其他 IAM 权限。 ## 启用临时存储 您可以通过在 `StartRun` API `scratchStorageMode` 中 I/O 进行设置将临时重定向到本地存储。该`scratchStorageMode`设置仅适用于 CPU 实例，并适用于该运行中的所有任务。 `scratchStorageMode`确定您的工作流程在哪里写入临时数据。可能的值： + `LOCAL`— 临时存储放在本地磁盘上。 I/O Scratch 有专门的 IOPS 和吞吐量 + `SHARED`— 使用共享文件系统（默认）。Scrat I/O ch 与工作目录发生冲突。 有关更多信息，请参阅 [开始跑步 HealthOmics](starting-a-run.md)。 **注意** GPU 任务始终使用本地 NVMe 临时存储空间存储临时数据，并且始终`LOCAL`用于处理 G `scratchStorageMode` PU 任务。 ### 选择使用临时存储 要为运行启用临时存储，请`scratchStorageMode`将其设置为开始运行`LOCAL`时。 ``` 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 ``` 对于批量运行，请传`scratchStorageMode`入`defaultRunSetting`。该设置适用于批次中的每次运行。 ``` 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}}"} } ] }' ``` ### 选择退出临时存储 要禁用特定运行的临时存储（例如，隔离故障），请将设置为。`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 ``` 如果`scratchStorageMode`是`SHARED`，则工作流程定义中的所有指令`disk`和等效指令都将被忽略并`/tmp`由共享文件系统支持。此设置仅适用于 CPU 实例。GPU 任务始终使用本地 NVMe 临时存储，且无法选择退出。 ### 检查有效模式 默认情况下，临时存储处于关闭状态。`StartRun`请求中省略时`scratchStorageMode`，设置`scratchStorageMode`为`SHARED`（默认）。 `scratchStorageMode`只有在`StartRun`请求中明确传递时，才会在`GetRun`响应中返回。 `SHARED`如果省略，则为默认值。`GetRun`致电确认跑步的有效存储模式。 ``` aws omics get-run --id {{run-id}} ``` ## 默认存储分配 所有标准、计算和实例类型的默认临时存储分配为每个任务 16 GiB。 Memory-optimized您无需指定指`disk`令即可接收此默认值。要配置额外的存储空间，请使用指`disk`令。在工作流程定义中，您可以增加分配给各个任务的临时存储量，每个任务最多可达 3,072 GiB。您需要为超过默认 16 GiB 的存储空间付费。 临时存储可以以 16 GiB 为增量进行配置。有关更多信息，请参阅 [支持的尺寸](#ephemeral-storage-supported-sizes)。 ### 用于加速计算实例的临时存储 GPU 实例存储容量因实例类型而异，且不收取额外费用。 GPU 任务始终使用本地 NVMe 临时存储。开`scratchStorageMode`启的设置`StartRun`不适用于 GPU 任务，将此值设置为`SHARED`不会对 GPU 实例产生任何影响。容量因实例类型而异，无法使用该`disk`指令进行自定义。NVMe 容量由为任务`cpu``memory`、和`acceleratorType`要求选择的实例类型预先确定。 | Size | GPU | vCPU | 内存（GiB） | g4dn NVMe (T4) | G5 NVMe (A10G) | G6 NVMe (L4) | G6e NVMe (L40S) | | --- | --- | --- | --- | --- | --- | --- | --- | | xlarge | 1 | 4 | 16 | 125 GiB | 250GiB | 250GiB | 250GiB | | 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 | ## 配置临时存储大小 如果设置`scratchStorageMode`为`LOCAL`，则可以使用工作流程定义中的`disk`指令（或等效指令）请求增加每项任务的临时存储空间。 HealthOmics 将该`disk`指令视为提示，并提供一个四舍五入到接下来的 16 GiB 的音量。该`disk`指令的使用不会影响实例类型的选择。仅基于`cpu``memory`、和选择实例类型`acceleratorType`。有关更多信息，请参阅 [工作 HealthOmics 流程定义中的任务资源](task-resources.md)。 如果不存在任何`disk`指令，则该任务将收到默认的 16 GiB。任务的临时存储空间不能少于默认的临时存储空间。 您无需为提取的容器映像调整临时存储的大小，这些镜像是单独考虑的。有关更多信息，请参阅 [私有工作流程的容器镜像](workflows-ecr.md)。 ### 何时使用磁盘指令 当您所选实例类型的默认临时存储空间不足以满足您的任务要求时，请在任务定义中使用该`disk`指令。例如，当任务向写入大量数据时`/tmp`。 ### 增加短暂存储的常见应用场景 1. **RNA-Seq 融合检测：** RNA-seq 工作流程会生成大型中间 BAM，任务流程通常需要同时存在原始 FastQs 和对齐的输出，因此需要大容量暂存盘（例如，每个任务 512 GiB）。 1. **De Novo Genome Assembly： Long-read 装**配工作流程需要大量的划痕量来处理原始读取和在输出之前反复重写和重组的临时装配工件。这些任务需要占用大量内存和磁盘，有时需要多 TiB 的临时存储。 1. **变体调用/BAM 处理：**变体调用工作流程需要大量的暂存空间，用于重复读取和重写大型 BAM 或 CRAM 文件的对齐和排序步骤。临时存储需求通常为数百 GiB。 ### 各引擎的指令语法 下表显示了每种工作流语言的等效指令。 | Engine | 指令 | 示例 | | --- | --- | --- | | WDL 1.1 | disks | disks: "/tmp 700 GiB" | | 下一步 | disk | disk '700 GB' | | CWL | tmpdirMin | tmpdirMin: 716800（以 MiB 为单位的值） | 以下示例说明如何配置请求 700 GiB 临时存储空间的任务。 HealthOmics 将其四舍五入到 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 ``` ------ 有关支持的指令语法的更多信息，请参见[WDL 工作流程定义细节](workflow-languages-wdl.md)和[Nextflow 工作流程定义细节](workflow-definition-nextflow.md)。 ### 常用生物信息学工具和临时存储 许多生物信息学工具在执行过程中会写入大型临时文件。如果设置`scratchStorageMode`为`LOCAL`，则重定向这些工具以供使用，`/tmp`以便从头开始 I/O 进入快速本地卷，而不是共享的运行文件系统。以下示例显示了常用工具的相关标志。 ------ #### [ 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 ``` ------ ### 支持的尺寸 请求的大小将四舍五入到最接近的 16 GiB 增量，从默认的 16 GiB（16、32、48、64... 最多 3,072 GiB）开始。每个任务支持的最大大小为 3,072 GiB。 如果请求的大小超过 3,072 GiB，则预置 HealthOmics 3,072 GiB，并在运行日志中写入警告。任务不会自动失败。 **注意** 对于基于表达式的`disk`指令（例如 Nextflow 闭包或 WDL 表达式），该值是在运行时计算的，而不是在。`disks: ceil(size(input_bam, "GiB") * 2.5)` `CreateWorkflow`如果评估的大小超过 3,072 GiB，则任务将在运行时失败，并收取在此之前产生的任何计算成本。 ### 支持的 WDL `磁盘形式` 有关可接受的 WDL `disks` 表单的完整列表，请参阅[支持的 WDL `磁盘形式`](workflow-languages-wdl.md#workflow-wdl-disks-forms)。 ### 使用 Nextflow 临时指令 对于 Nextflow 工作流程，您可以使用`scratch`指令来控制进程写入临时工作文件的位置。有关临时存储支持的值和建议用法的信息，请参阅。[在 Nextflow 中高效使用临时存储](workflow-definition-nextflow.md#nextflow-scratch-storage) ## 监控临时存储 HealthOmics 将每个任务的临时存储指标写入清单日志。 CloudWatch 指标包括每个任务的临时存储数据，包括每个任务的预配置卷大小 (as`scratchStorageReservedGiB`) 和使用情况 (as`scratchStorageUtilizedGiB`)。无需直接查询 CloudWatch ，即可查看清单日志，确定任务是过度配置还是配置不足。有关清单日志的详细信息，请参阅[HealthOmics 使用 CloudWatch 日志进行监控](monitoring-cloudwatch-logs.md)。 ## 临时存储的计费方式 您只需为在默认分配之外配置的临时存储空间付费。`disk`指令中超过默认值的请求将向上舍入到最接近的支持级别。 GPU 实例在实例定价中已经考虑了临时存储。GPU 任务的临时存储不收取额外费用。 ## 注意事项和限制 | 考虑因素 | Detail | | --- | --- | | 临时存储不是永久性的 | 任务终止时，临时存储卷总是会被删除。中的/tmp数据无法保存、导出，也无法用于后续任务或运行。临时存储中的/tmp数据不能是任务输出或工作流程输出；这将导致运行时出现故障。 | | 临时存储不会在任务之间共享 | 每项任务都有自己的隔离临时存储卷。任务无法访问彼此的/tmp目录。必须在任务之间共享的数据必须写入共享运行文件系统。 | | 无法在任务中途调整存储空间的大小 | 存储大小在任务开始时是固定的。任务正在运行时，您不能增加或减少分配的存储空间。 | | Working-directory scratch 不会自动重定向 | 从头开始写入工作目录的工作流（例如input/./、或out/）不会自动受益。更新您的工作流程以将 scratch 重定向 I/O 到/tmp或$TMPDIR。 | | 未按预期写入/tmp临时数据 | 确保您的任务进程明确写入，/tmp并且您的任务命令未映射$TMPDIR到其他位置。 | | GPU 实例始终使用临时存储 | GPU 任务始终挂载/tmp在本地 NVMe 实例存储上。设置scratchStorageMode为SHARED不会禁用 GPU 任务的临时存储。 | | GPU 实例：NVMe 容量是固定的 | GPU 实例不支持自定义磁盘大小。 HealthOmics 忽略disk指令并为实例类型提供默认 NVMe 容量。 | | 每个任务最大 3,072 GiB (CPU) | 超过 3,072 GiB 的请求将配置为 3,072 GiB，并显示运行日志警告。任务没有失败。 | | 仅支持的层级 (CPU) | 请求的大小四舍五入到最接近的 16 GiB 增量（16、32、48、64，... 最多 3,072 GiB）。 | | Expression-based 在运行时评估的指令 | disk根据表达式计算的值在任务开始时进行验证，而不是在任务开始时进行验证CreateWorkflow。如果任务在运行时失败，则会收取到该点之前的计算成本。 | | SHARED模式会忽略所有磁盘指令（仅限 CPU） | scratchStorageMode对于 CPU 任务 SHARED disktmpdirMin，将忽略 when is、、和等效指令。未配置本地存储卷。GPU 任务不受影响，它们始终使用本地 NVMe。 | ## 对临时存储进行故障排除 ### 任务因临时存储空间耗尽而失败 当临时存储空间达到容量时，任务就会失败。查看 CloudWatch 清单日志，确定您的任务实际使用了多少存储空间，然后添加或增加指`disk`令以请求更大的存储层。 ``` # Before: 4-vCPU task using the 16 GiB default runtime { cpu: 4 } # After: explicitly request 400 GiB runtime { cpu: 4, disks: "400 GiB" } ``` ### 临时存储似乎未被利用 致电`GetRun`并查看字`scratchStorageMode`段。如果值为`SHARED`，则不为该运行启用临时存储。设`--scratch-storage-mode LOCAL`定下次`start-run`通话。 ``` aws omics get-run --id {{run-id}} ```