Esegui tipi di storage nei flussi HealthOmics di lavoro

Quando avvii un'esecuzione, HealthOmics alloca lo storage di esecuzione temporaneo per il motore di workflow da utilizzare durante l'esecuzione. HealthOmicsfornisce l'archiviazione temporanea di esecuzione come file system.

Per un determinato flusso di lavoro o esecuzione del flusso di lavoro, è possibile scegliere l'archiviazione di esecuzione dinamica o statica. Per impostazione predefinita, HealthOmics fornisce l'archiviazione statica di esecuzione.

Nota

L'utilizzo di Run Storage comporta addebiti sul tuo account. Per informazioni sui prezzi dello storage a esecuzione statica e dinamica, consulta la pagina HealthOmicsdei prezzi.

Le sezioni seguenti forniscono informazioni da considerare quando si decide quale tipo di run storage utilizzare.

Run Storage dinamico

Si consiglia di utilizzare lo storage a esecuzione dinamica per la maggior parte delle esecuzioni, comprese quelle che richiedono tempi di avvio più rapidi, quelle in cui non si conoscono in anticipo le esigenze di storage e per cicli iterativi di test di sviluppo.

Non è necessario stimare lo storage o la velocità effettiva richiesti per l'esecuzione. HealthOmics aumenta o riduce dinamicamente le dimensioni dello storage, in base all'utilizzo del file system durante l'esecuzione. HealthOmics inoltre ridimensiona dinamicamente la velocità effettiva in base alle esigenze del flusso di lavoro. Un'esecuzione non fallisce mai a causa di un errore di archiviazione insufficiente per il file system.

Lo storage a esecuzione dinamica offre provisioning/deprovisioning tempi più rapidi rispetto allo storage a esecuzione statica. Una configurazione più rapida è un vantaggio per la maggior parte dei flussi di lavoro e lo è anche durante development/test i cicli.

Al termine dell'esecuzione (percorso di successo o percorso di errore), l'operazione API GetRun restituisce lo spazio di archiviazione massimo utilizzato dall'esecuzione nel campo StorageCapacity. È inoltre possibile trovare queste informazioni nei log del manifesto di esecuzione che si trovano nel gruppo di log. omics Per un'esecuzione dinamica dello storage che viene completata entro 2 ore, il valore massimo di archiviazione potrebbe non essere disponibile.

Per lo storage a esecuzione dinamica, il run esegue il provisioning di un file system che utilizza il protocollo NFS. NFS considera le operazioni CREATE, DELETE e RENAME sui file come operazioni non idempotenti, il che può occasionalmente portare a condizioni di concorrenza per queste operazioni che il codice deve gestire correttamente. Ad esempio, il codice non dovrebbe fallire se tenta di eliminare un file che non esiste. Prima di adottare lo storage a esecuzione dinamica, consigliamo di modificare il codice del flusso di lavoro per renderlo resiliente a operazioni sui file non idempotenti. Consultare Esempi di codice per la gestione sicura di operazioni non idempotenti.

Esempi di codice per la gestione sicura di operazioni non idempotenti

Il seguente esempio di python mostra come eliminare un file senza errori se il file non esiste.

import os
import errno

def remove_file(file_path):
    try:
        os.remove(file_path)
    except OSError as e:
        # If the error is "No such file or directory", ignore it (or log it)
        if e.errno != errno.ENOENT:
            # Otherwise, raise the error
            raise
            
# Example usage
remove_file("myfile") 

I seguenti esempi utilizzano la shell Bash. Per rimuovere in modo sicuro un file anche se non esiste, usa:

rm -f my_file

Per spostare (rinominare) un file in modo sicuro, esegui il comando move solo se il file old_name esiste nella directory corrente.

[ -f old_name ] && mv old_name new_name

Per creare una directory, utilizzate il seguente comando:

mkdir -p mydir/subdir/  

Archiviazione statica di esecuzione

Per l'archiviazione statica in esecuzione, run fornisce un file system che utilizza il protocollo Lustre. Per impostazione predefinita, questo protocollo è resiliente alle operazioni sui file non idempotenti. Non è necessario modificare il codice del flusso di lavoro per gestire operazioni sui file non idempotenti.

HealthOmics alloca una quantità fissa di storage di esecuzione. Questo valore viene specificato all'avvio della corsa. Lo storage di esecuzione predefinito è 1200 GiB, se non si specifica un valore. Quando si specifica un valore per la dimensione di archiviazione nella richiesta StartRun API, il sistema arrotonda il valore al multiplo più vicino di 1200 GiB. Se tale dimensione di archiviazione non è disponibile, viene arrotondata al multiplo più vicino di 2400 GiB.

Per lo storage a esecuzione statica, fornisce i seguenti HealthOmics valori di throughput:

• Throughput di base di 200 per MB/s TiB di capacità di storage fornita.

• Throughput burst fino a 1300 per MB/s TiB di capacità di storage fornita.

Se la dimensione di storage specificata è troppo bassa, l'esecuzione ha esito negativo e viene visualizzato un errore Out of storage for file system. Lo storage a esecuzione statica è ideale per flussi di lavoro prevedibili con requisiti di storage noti.

Lo storage a esecuzione statica è adatto per carichi di lavoro di grandi dimensioni e con elevata contemporaneità delle attività (ad esempio, un grande volume di campioni RNASeq elaborati in parallelo). Fornisce un throughput di file system per GiB più elevato e un costo per GiB inferiore rispetto allo storage a esecuzione dinamica.

Calcolo dello storage di esecuzione statico richiesto

Un flusso di lavoro richiede una capacità aggiuntiva quando utilizza lo storage di esecuzione statico (rispetto allo storage a esecuzione dinamica) perché l'installazione del file system di base utilizza il 7% della capacità statica del file system.

Se esegui un workflow di esecuzione dinamica per misurare lo storage massimo utilizzato dall'esecuzione, utilizza il seguente calcolo per determinare la quantità minima di storage statico richiesta:

  static storage required = 
         maximum storage in GiB used by the dynamic run storage  
           + (total static file system size in GiB * 0.07) 

Per esempio:

     Maximum storage measured from a dynamic run storage workflow run:  500GiB
       File system size: 1200GiB
       7% of the file system size:  84GiB
       500 + 84 = 584GiB of static run storage required for this run. 

Pertanto, 1200 GiB (la capacità minima per lo storage di esecuzione statica) sono sufficienti per questa esecuzione.