Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Speichertypen in HealthOmics Workflows ausführen

Wenn Sie einen Lauf starten, wird temporärer HealthOmics Ausführungsspeicher zugewiesen, den die Workflow-Engine während des Laufs verwenden kann. HealthOmicsstellt den temporären Run-Speicher als Dateisystem bereit.

Für einen bestimmten Workflow oder eine Workflow-Ausführung können Sie zwischen dynamischem oder statischem Run-Speicher wählen. HealthOmics Stellt standardmäßig statischen Run-Speicher bereit.

Die folgenden Abschnitte enthalten Informationen, die Sie bei der Entscheidung, welcher Run-Speichertyp verwendet werden soll, berücksichtigen sollten.

Dynamischer Run-Speicher

Wir empfehlen die Verwendung von dynamischem Run-Storage für die meisten Läufe, einschließlich Läufe, für die schnellere Startzeiten erforderlich sind, für Läufe, bei denen Sie den Speicherbedarf nicht im Voraus kennen, und für iterative Entwicklungstestzyklen.

Sie müssen den benötigten Speicherplatz oder den Durchsatz für den Lauf nicht abschätzen. HealthOmics skaliert die Speichergröße je nach Auslastung des Dateisystems während des Laufs dynamisch nach oben oder unten. HealthOmics skaliert außerdem dynamisch den Durchsatz entsprechend den Anforderungen des Workflows. Eine Ausführung schlägt nie aufgrund eines Fehlers „Nicht genügend Speicherplatz für das Dateisystem“ fehl.

Dynamischer Run-Speicher bietet eine schnellere provisioning/deprovisioning Zeit als statischer Run-Speicher. Eine schnellere Einrichtung ist für die meisten Workflows von Vorteil und auch während development/test Zyklen von Vorteil.

Nach Abschluss der Ausführung (Erfolgspfad oder Fehlschlagpfad) gibt die GetRun-API-Operation den vom Lauf maximal belegten Speicherplatz im Feld StorageCapacity zurück. Sie finden diese Informationen auch in den Run-Manifest-Protokollen in der omics Protokollgruppe. Bei einem dynamischen Speicherlauf, der innerhalb von 2 Stunden abgeschlossen wird, ist der maximale Speicherwert möglicherweise nicht verfügbar.

Für den dynamischen Run-Speicher stellt der Lauf ein Dateisystem bereit, das das NFS-Protokoll verwendet. NFS behandelt CREATE-, DELETE- und RENAME-Dateioperationen als nicht idempotent, was gelegentlich zu Wettlaufbedingungen für diese Operationen führen kann, die Ihr Code ordnungsgemäß verarbeiten muss. Ihr Code sollte beispielsweise nicht fehlschlagen, wenn er versucht, eine Datei zu löschen, die nicht existiert. Vor der Einführung von Dynamic Run Storage empfehlen wir, Ihren Workflow-Code so anzupassen, dass er auch nicht-idempotenten Dateioperationen standhält. Siehe Codebeispiele für den sicheren Umgang mit nicht-idempotenten Vorgängen.

Codebeispiele für den sicheren Umgang mit nicht-idempotenten Vorgängen

Das folgende Python-Beispiel zeigt, wie eine Datei gelöscht werden kann, ohne dass ein Fehler auftritt, wenn die Datei nicht existiert.

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") 

Die folgenden Beispiele verwenden die Bash-Shell. Um eine Datei sicher zu entfernen, auch wenn sie nicht existiert, verwenden Sie:

rm -f my_file

Um eine Datei sicher zu verschieben (umzubenennen), führen Sie den Befehl move nur aus, wenn die Datei im aktuellen Verzeichnis old_name vorhanden ist.

[ -f old_name ] && mv old_name new_name

Verwenden Sie den folgenden Befehl, um ein Verzeichnis zu erstellen:

mkdir -p mydir/subdir/  

Statisch ausgeführter Speicher

Für den statischen Run-Speicher stellt der Run ein Dateisystem bereit, das das Lustre-Protokoll verwendet. Dieses Protokoll ist standardmäßig resistent gegen nicht-idempotente Dateioperationen. Sie müssen Ihren Workflow-Code nicht anpassen, um nicht-idempotente Dateioperationen zu verarbeiten.

HealthOmics weist eine feste Menge an Run-Speicher zu. Sie geben diesen Wert an, wenn Sie den Lauf starten. Der Standard-Run-Speicher ist 1200 GiB, wenn Sie keinen Wert angeben. Wenn Sie in der StartRun API-Anfrage einen Wert für die Speichergröße angeben, rundet das System den Wert auf das nächste Vielfache von 1200 GiB auf. Wenn diese Speichergröße nicht verfügbar ist, wird sie auf das nächste Vielfache von 2400 GiB aufgerundet.

Stellt für statischen Run-Speicher HealthOmics die folgenden Durchsatzwerte bereit:

Wenn die angegebene Speichergröße zu niedrig ist, schlägt die Ausführung fehl und es wird der Fehler Nicht genügend Speicherplatz für das Dateisystem angezeigt. Static Run Storage eignet sich gut für vorhersehbare Workflows mit bekannten Speicheranforderungen.

Static Run Storage eignet sich für große, Burst-Workloads mit hoher Aufgabenparallelität (z. B. eine große Menge parallel verarbeiteter RNASeq Samples). Es bietet einen höheren Dateisystemdurchsatz pro GiB und niedrigere Kosten pro GiB als Dynamic Run Storage.

Berechnung des erforderlichen statischen Laufspeichers

Ein Workflow benötigt zusätzliche Kapazität, wenn er statischen Laufspeicher verwendet (im Vergleich zu dynamischem Laufspeicher), da die Basisdateisysteminstallation 7% der Kapazität des statischen Dateisystems beansprucht.

Wenn Sie einen dynamischen Run-Storage-Workflow ausführen, um den maximalen Speicherplatz zu messen, der von der Ausführung verwendet wird, verwenden Sie die folgende Berechnung, um die Mindestmenge an statischem Speicher zu ermitteln:

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

Zum Beispiel:

     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. 

Daher sind 1200 GiB (die Mindestkapazität für statischen Laufspeicher) für diesen Lauf ausreichend.