Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Stockage éphémère pour HealthOmics les tâches de flux de travail

HealthOmics fournit un stockage éphémère pour les tâches de flux de travail utilisant le /tmp répertoire. Ce stockage est temporaire et propre à chaque tâche d'un flux de travail. HealthOmics alloue 16 GiB de stockage éphémère à chaque instance de tâche par défaut. Vous pouvez augmenter la quantité de stockage éphémère allouée à des tâches individuelles dans la définition de votre flux de travail, jusqu'à un maximum de 3 072 GiB par tâche. Toutes les données stockées /tmp sont cryptées au repos.

Principaux avantages

Comment fonctionne le stockage éphémère

Lorsque vous activez le stockage éphémère, vous montez un HealthOmics volume de stockage local dédié /tmp pour chaque instance de tâche de flux de travail. Le stockage éphémère est destiné aux fichiers temporaires générés lors de l'exécution des tâches. Les volumes de stockage éphémères sont toujours supprimés à la fin de la tâche. Les données écrites ne /tmp sont pas conservées, exportées ou accessibles pour d'autres tâches ou exécutions ultérieures.

Où les flux de travail écrivent des fichiers temporaires

Les flux de travail bénéficient d'un stockage éphémère lorsque les processus de tâches sont dirigés vers. I/O /tmp Les langages de flux de travail bioinformatiques utilisent le /tmp répertoire (et les $TMP variables d'$TMPDIRenvironnement) pour les fichiers intermédiaires temporaires et de courte durée lors de l'exécution des tâches. Assurez-vous que vos commandes de tâches ne sont pas mappées $TMPDIR à un autre emplacement.

Les processus de tâches de flux de travail qui écrivent pour utiliser /tmp automatiquement le stockage éphémère lorsqu'il est activé, ne nécessitant aucune modification du flux de travail. Les flux de travail qui ne dirigent pas explicitement les processus scratch vers /tmp écriront les données scratch dans le répertoire de travail du système de fichiers partagé utilisé pour le stockage d'exécution, bien que les outils utilisés puissent tirer parti du /tmp stockage éphémère.

Chiffrement au repos

Tout le stockage éphémère est chiffré au repos à l'aide d'une clé gérée par les services AWS KMS . Les instances de calcul accéléré sont chiffrées matériellement à l'aide d'une clé unique par volume qui est détruite à la fermeture de l'instance.

Permissions

HealthOmics gère les pièces jointes et le cycle de vie des volumes de stockage éphémères en votre nom. Aucune autorisation IAM supplémentaire n'est requise dans votre rôle d'exécution des tâches.

Activation du stockage éphémère

Vous pouvez rediriger Scratch I/O vers le stockage local en le configurant scratchStorageMode dans l'StartRunAPI. Le scratchStorageMode paramètre s'applique uniquement aux instances de processeur et s'applique à toutes les tâches de cette exécution.

scratchStorageModedétermine où votre flux de travail écrit les données scratch. Valeurs possibles :

Pour de plus amples informations, veuillez consulter Commencez une course HealthOmics.

Optez pour le stockage éphémère

Pour activer le stockage éphémère pour une exécution, définissez le LOCAL moment où scratchStorageMode vous démarrez l'exécution.

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

Pour les tirages par lots, transmettez scratchStorageModedefaultRunSetting. Le paramètre s'applique à chaque exécution du lot.

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"}
        }
      ]
    }'

Désactiver le stockage éphémère

Pour désactiver le stockage éphémère pour une exécution spécifique (par exemple, pour isoler une panne), définissez surscratchStorageMode. 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

Lorsque scratchStorageMode c'est SHARED le cas, toutes les directives disk et les directives équivalentes de la définition du flux de travail sont ignorées et /tmp sont soutenues par le système de fichiers partagé. Ce paramètre s'applique uniquement aux instances de processeur. Les tâches GPU utilisent toujours le stockage éphémère NVMe local et ne peuvent pas être désactivées.

Vérifiez le mode effectif

Le stockage éphémère est désactivé par défaut. Quand scratchStorageMode est omis dans une StartRun demande, scratchStorageMode est défini sur SHARED (par défaut).

scratchStorageModen'est renvoyé dans la GetRun réponse que s'il a été explicitement transmis dans la StartRun demande. SHAREDest la valeur par défaut en cas d'omission. Appelez GetRun pour confirmer le mode de stockage effectif pour une exécution.

aws omics get-run --id run-id

Allocation de stockage par défaut

L'allocation de stockage éphémère par défaut est de 16 Go par tâche pour tous les types de stockage standard, de calcul et Memory-optimized d'instance. Vous n'avez pas besoin de spécifier de disk directive pour recevoir cette valeur par défaut. Pour configurer un stockage supplémentaire, utilisez la disk directive. Vous pouvez augmenter la quantité de stockage éphémère allouée à des tâches individuelles dans la définition de votre flux de travail, jusqu'à un maximum de 3 072 GiB par tâche. Un stockage supérieur à la valeur par défaut de 16 Go vous est facturé.

Le stockage éphémère peut être configuré par incréments de 16 GiB. Pour de plus amples informations, veuillez consulter Tailles prises en charge.

Stockage éphémère pour les instances informatiques accélérées

La capacité de stockage des instances GPU est fixe par type d'instance et est fournie sans frais supplémentaires.

Les tâches GPU utilisent toujours le stockage éphémère NVMe local. Le scratchStorageMode paramètre activé StartRun ne s'applique pas aux tâches GPU et définir cette valeur sur n'SHAREDaura aucun effet sur les instances GPU. La capacité est fixée par type d'instance et ne peut pas être personnalisée à l'aide de la disk directive. La capacité NVMe est prédéterminée par le type d'instance sélectionné pour les exigences et acceleratorType les exigences de cpu la tâche. memory

Configuration de la taille du stockage éphémère

Lorsque cette valeur scratchStorageMode est définie surLOCAL, vous pouvez demander une augmentation du stockage éphémère par tâche à l'aide de la disk directive (ou d'une directive équivalente) figurant dans la définition de votre flux de travail. HealthOmics traite la disk directive comme une indication et fournit un volume arrondi aux 16 GiB suivants. L'utilisation de la disk directive n'affecte pas la sélection du type d'instance. Le type d'instance est sélectionné uniquement en fonction de cpumemory, etacceleratorType. Pour de plus amples informations, veuillez consulter Ressources de tâches dans une définition HealthOmics de flux de travail.

Si aucune disk directive n'est présente, la tâche reçoit la valeur par défaut de 16 GiB. Les tâches ne peuvent pas avoir moins que le stockage éphémère par défaut.

Vous n'avez pas besoin de dimensionner votre espace de stockage éphémère pour les images de conteneurs extraites, qui sont comptabilisées séparément. Pour de plus amples informations, veuillez consulter Images de conteneur pour les flux de travail privés.

Quand utiliser la directive Disk

Utilisez la disk directive dans votre définition de tâche lorsque le stockage éphémère par défaut pour le type d'instance que vous avez choisi n'est pas suffisant pour répondre aux exigences de votre tâche. Par exemple, lorsqu'une tâche écrit de grands volumes de données dans/tmp.

Cas d’utilisation courants pour un stockage éphémère augmenté

Syntaxe des directives par moteur

Le tableau suivant indique la directive équivalente pour chaque langue de flux de travail.

Les exemples suivants montrent comment configurer une tâche qui demande 700 Go de stockage éphémère. HealthOmics arrondit ce chiffre au niveau 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

Pour plus d'informations sur la syntaxe de directive prise en charge, consultez Spécificités de la définition du flux de travail WDL etSpécificités de la définition du flux de travail Nextflow.

Exemple : dimensionnement de disque basé sur l'expression

Au lieu d'une taille fixe, vous pouvez définir la disk directive sur une expression que le moteur de flux de travail évalue pour chaque tâche au moment de l'exécution. Le processus Nextflow suivant utilise une fermeture qui redimensionne la demande en fonction du nombre de tentatives de tâche. Si la tâche échoue pour une raison quelconque et que Nextflow la réessaie, la nouvelle tentative demande un volume plus important.

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)

Le moteur de flux de travail évalue l'expression pour chaque tentative de tâche. HealthOmics arrondit ensuite la taille résolue au prochain incrément de 16 GiB.

Outils bioinformatiques courants et stockage éphémère

De nombreux outils bioinformatiques écrivent de gros fichiers temporaires pendant leur exécution. Lorsque cette scratchStorageMode option est définie surLOCAL, redirigez ces outils à utiliser /tmp afin que I/O Scratch soit dirigé vers le volume local rapide au lieu du système de fichiers d'exécution partagé. Les exemples suivants montrent les indicateurs pertinents pour les outils couramment utilisés.

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

Tailles prises en charge

Les tailles demandées sont arrondies à l'incrément de 16 GiB le plus proche, à partir de la valeur par défaut de 16 GiB (16, 32, 48, 64,... jusqu'à 3 072 GiB). La taille maximale prise en charge est de 3 072 GiB par tâche.

Si la taille demandée dépasse 3 072 GiB, HealthOmics provisionne 3 072 GiB et écrit un avertissement dans le journal d'exécution. La tâche n'échoue pas automatiquement.

Formulaires de disques WDL pris en charge

Pour la liste complète des disks formulaires WDL acceptés, voirFormulaires de disques WDL pris en charge.

Utilisation de la directive scratch Nextflow

Pour les flux de travail Nextflow, vous pouvez utiliser la scratch directive pour contrôler où les processus écrivent les fichiers de travail temporaires. Pour plus d'informations sur les valeurs prises en charge et l'utilisation recommandée avec le stockage éphémère, consultez. Utiliser efficacement le stockage Scratch dans Nextflow

Surveillance du stockage éphémère

HealthOmics écrit des métriques de stockage éphémères par tâche dans les journaux des manifestes. CloudWatch Les mesures incluent les données de stockage éphémères par tâche relatives à la taille du volume provisionné (en tant quescratchStorageReservedGiB) et à l'utilisation (en tant quescratchStorageUtilizedGiB) pour chaque tâche. Consultez le journal du manifeste pour déterminer si les tâches étaient surprovisionnées ou sous-provisionnées sans effectuer de requêtes CloudWatch directes. Pour plus de détails sur les journaux des manifestes, consultezSurveillance à HealthOmics l'aide de CloudWatch journaux.

Comment est facturé le stockage éphémère

Vous êtes facturé uniquement pour le stockage éphémère fourni au-delà de l'allocation par défaut. Les demandes supérieures à la valeur par défaut de votre disk directive sont arrondies au niveau pris en charge le plus proche.

Le stockage éphémère des instances GPU est déjà pris en compte dans la tarification des instances. Il n'y a pas de frais supplémentaires pour le stockage éphémère des tâches GPU.

Considérations et restrictions

Résolution des problèmes liés au stockage éphémère

La tâche échoue lorsque le stockage éphémère est épuisé

Une tâche échoue lorsque le stockage éphémère atteint sa capacité maximale. Passez en revue les journaux de vos CloudWatch manifestes pour déterminer la quantité de stockage réellement utilisée par votre tâche, puis ajoutez ou augmentez la disk directive pour demander un niveau plus élevé.

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

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

Le stockage éphémère ne semble pas être utilisé

Appelez GetRun et vérifiez le scratchStorageMode champ. Si la valeur estSHARED, le stockage éphémère n'est pas activé pour cette exécution. --scratch-storage-mode LOCALProgrammez votre prochain start-run appel.

aws omics get-run --id run-id