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 du 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 aux 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 qui y sont /tmp stockées sont cryptées au repos.

Principaux avantages

Comment fonctionne le stockage éphémère

Lorsque vous activez le stockage éphémère, HealthOmics monte un 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 enregistrées ne /tmp sont pas conservées, exportées ou accessibles aux autres tâches ou aux 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 redirigent le scratch I/O vers. /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 de courte durée lors de l'exécution des tâches. Assurez-vous que les commandes de vos tâches ne sont pas mappées $TMPDIR vers un autre emplacement.

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 écrivent les données Scratch dans le répertoire de travail du système de fichiers partagé utilisé pour le stockage des exécutions, bien que les outils utilisés puissent tirer parti du /tmp stockage éphémère. /tmp

Chiffrement au repos

Tout le stockage éphémère est chiffré au repos à l'aide d'une clé gérée par le service 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 lorsque l'instance se termine.

Permissions

HealthOmics gère l'attachement 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 de tâches.

Permettre le stockage éphémère

Vous pouvez rediriger Scratch I/O vers le stockage local scratchStorageMode en configurant 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 l'endroit où votre flux de travail écrit les données temporaires. 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 course, définissez ce paramètre sur scratchStorageMode le LOCAL moment où vous commencez 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 séries par lots, scratchStorageMode transmettez-ledefaultRunSetting. 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 un échec), 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

Dans scratchStorageMode ce casSHARED, toutes disk les directives équivalentes de la définition du flux de travail sont ignorées et /tmp sont sauvegardées 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 efficace

Le stockage éphémère est désactivé par défaut. Lorsqu'il scratchStorageMode est omis dans une StartRun demande, scratchStorageMode il 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 si elle est omise. 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 GiB par tâche pour tous les types standard, de calcul et d'instance. Memory-optimized Il n'est pas nécessaire 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 aux tâches individuelles dans la définition de votre flux de travail, jusqu'à un maximum de 3 072 GiB par tâche. Le stockage supérieur à la valeur par défaut de 16 GiB 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 de calcul accéléré

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

Les tâches du GPU utilisent toujours le stockage éphémère NVMe local. Le scratchStorageMode paramètre activé StartRun ne s'applique pas aux tâches du GPU et la définition de cette valeur n'SHAREDaura aucun effet sur les instances du GPU. La capacité est fixe 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é en fonction des exigences de cpu la tâche. memory acceleratorType

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

Lorsque scratchStorageMode ce paramètre est défini surLOCAL, vous pouvez demander une augmentation du stockage éphémère par tâche en utilisant la disk directive (ou une directive équivalente) figurant dans la définition de votre flux de travail. HealthOmics traite la disk directive comme un indice 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 sur la base 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 un espace de stockage éphémère inférieur au stockage éphémère par défaut.

Il n'est pas nécessaire de dimensionner votre espace de stockage éphémère pour les images des conteneurs extraits, 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 les exigences de votre tâche. Par exemple, lorsqu'une tâche écrit de gros 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 langage de flux de travail.

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

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

Outils bioinformatiques courants et stockage éphémère

De nombreux outils bioinformatiques écrivent de gros fichiers temporaires lors de leur exécution. Lorsque scratchStorageMode ce paramètre est défini surLOCAL, redirigez ces outils pour les utiliser /tmp afin que I/O Scratch soit redirigé vers le volume local rapide plutôt que vers le système de fichiers partagé. Les exemples suivants montrent les indicateurs appropriés 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, approvisionne HealthOmics 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 l'endroit 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 à gratter 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 métriques incluent les données de stockage éphémères par tâche relatives à la taille (asscratchStorageReservedGiB) du volume provisionné (as) et à l'utilisation (asscratchStorageUtilizedGiB) pour chaque tâche. Consultez le journal du manifeste pour déterminer si les tâches étaient surprovisionnées ou sous-provisionnées sans demander directement. CloudWatch Pour plus de détails sur les journaux de 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-dessus 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 aucun frais supplémentaire pour le stockage éphémère sur les tâches du 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 vos journaux de CloudWatch manifeste 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 terrain. Si la valeur est « oui »SHARED, 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