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.
# Aufruf-Caching für Läufe HealthOmics
AWS HealthOmics unterstützt das Zwischenspeichern von Anrufen, auch bekannt als Resume, für private Workflows. Beim Aufruf-Caching werden die Ausgaben abgeschlossener Workflow-Aufgaben nach Abschluss eines Laufs gespeichert. Nachfolgende Ausführungen können die Aufgabenausgaben aus dem Cache verwenden, anstatt die Aufgabenausgaben erneut zu berechnen. Das Aufruf-Caching reduziert die Nutzung von Rechenressourcen, was zu kürzeren Ausführungsdauern und zu Einsparungen bei den Rechenkosten führt.
Nach Abschluss der Ausführung können Sie auf die zwischengespeicherten Aufgabenausgabedateien zugreifen. Für das erweiterte Debugging und die Problembehandlung von Aufgaben können Sie zwischengespeicherte Aufgabendateien zwischenspeichern, indem Sie diese Dateien in der Workflow-Definition als Aufgabenausgaben angeben.
Sie können die Zwischenspeicherung von Aufrufen verwenden, um die abgeschlossenen Aufgabenergebnisse fehlgeschlagener Ausführungen zu speichern. Die nächste Ausführung beginnt mit der letzten erfolgreich abgeschlossenen Aufgabe, anstatt die abgeschlossenen Aufgaben erneut zu berechnen.
Wenn HealthOmics kein passender Cache-Eintrag für eine Aufgabe gefunden wird, schlägt die Ausführung nicht fehl. HealthOmics berechnet die Aufgabe und die von ihr abhängigen Aufgaben neu.
Informationen zur Behebung von Problemen mit der Zwischenspeicherung von Anrufen finden Sie unter. [Behebung von Problemen beim Zwischenspeichern von Anrufen](troubleshooting.md#workflow-cache-troubleshooting)
**Topics**
+ [So funktioniert das Caching von Anrufen](how-run-cache.md)
+ [Einen Run-Cache erstellen](workflow-cache-create.md)
+ [Einen Run-Cache aktualisieren](workflow-cache-update.md)
+ [Löschen eines Run-Caches](workflow-cache-delete.md)
+ [Inhalt eines Run-Caches](workflow-cache-contents.md)
+ [Engine-spezifische Caching-Funktionen](workflow-cache-per-engine.md)
+ [Verwenden Sie den Run-Cache](workflow-cache-startrun.md)
# So funktioniert das Caching von Anrufen
Um Call Caching zu verwenden, erstellen Sie einen Run-Cache und konfigurieren ihn so, dass er über einen zugehörigen Amazon S3 S3-Speicherort für die zwischengespeicherten Daten verfügt. Wenn Sie einen Lauf starten, geben Sie den Run-Cache an. Ein Run-Cache ist nicht für einen einzigen Workflow vorgesehen. Läufe aus mehreren Workflows können denselben Cache verwenden.
Während der Exportphase eines Laufs exportiert das System die abgeschlossenen Aufgabenausgaben an den Amazon S3 S3-Speicherort. Um zwischengeschaltete Aufgabendateien zu exportieren, deklarieren Sie diese Dateien in der Workflow-Definition als Aufgabenausgaben. Das Aufruf-Caching speichert auch intern Metadaten und erstellt eindeutige Hashes für jeden Cache-Eintrag.
Für jede Aufgabe in einem Lauf erkennt die Workflow-Engine, ob es für diese Aufgabe einen passenden Cache-Eintrag gibt. Wenn es keinen passenden Cache-Eintrag gibt, HealthOmics berechnet die Aufgabe. Wenn es einen passenden Cache-Eintrag gibt, ruft die Engine die zwischengespeicherten Ergebnisse ab.
HealthOmics Verwendet zum Abgleichen von Cache-Einträgen den Hashing-Mechanismus, der in den systemeigenen Workflow-Engines enthalten ist. HealthOmicserweitert diese vorhandenen Hash-Implementierungen um HealthOmics Variablen wie S3-ETags und ECR-Container-Digests.
HealthOmics unterstützt das Caching von Aufrufen für diese Workflow-Sprachversionen:
+ Die WDL-Versionen 1.0, 1.1 und die Entwicklungsversion
+ Nextflow-Versionen 23.10 und 24.10
+ Alle CWL-Versionen
**Anmerkung**
HealthOmics unterstützt kein Aufruf-Caching für Ready2Run-Workflows.
**Topics**
+ [Modell der geteilten Verantwortung](#run-cache-srm)
+ [Anforderungen an das Zwischenspeichern von Aufgaben](#workflow-cache-task-prereqs)
+ [Führen Sie die Cache-Leistung aus](#run-cache-performance)
+ [Ereignisse zur Aufbewahrung und Invalidierung von Daten zwischenspeichern](#workflow-cache-data)
## Modell der geteilten Verantwortung
Die Benutzer sind gemeinsam dafür verantwortlich, AWS zu bestimmen, ob Aufgaben und Läufe sich für das Call-Caching eignen. Das Aufruf-Caching erzielt die besten Ergebnisse, wenn alle Aufgaben idempotent sind (wiederholte Ausführungen einer Aufgabe mit denselben Eingaben führen zu denselben Ergebnissen).
Wenn eine Aufgabe jedoch nicht deterministische Elemente enthält (wie Zufallszahlengenerationen oder Systemzeit), können wiederholte Ausführungen der Aufgabe mit denselben Eingaben zu unterschiedlichen Ausgaben führen. Dies kann sich auf folgende Weise auf die Effektivität des Caching von Anrufen auswirken:
+ Wenn ein Cache-Eintrag HealthOmics verwendet wird (der durch einen vorherigen Lauf erstellt wurde), der nicht mit der Ausgabe identisch ist, die die Ausführung der Aufgabe für den aktuellen Lauf erzeugen würde, kann der Lauf zu anderen Ergebnissen führen als derselbe Lauf ohne Zwischenspeicherung.
+ HealthOmics findet möglicherweise keinen passenden Cache-Eintrag für eine Aufgabe, der entsprechen sollte, weil die Aufgabenausgabe nicht deterministisch ist. Wenn der gültige Cache-Eintrag nicht gefunden wird, wird die Aufgabe bei der Ausführung unnötig neu berechnet, wodurch die Kosteneinsparung durch die Verwendung von Aufruf-Caching beeinträchtigt wird.
Im Folgenden sind bekannte Verhaltensweisen von Aufgaben aufgeführt, die zu nicht deterministischen Ergebnissen führen können, die sich auf die Ergebnisse der Zwischenspeicherung von Aufrufen auswirken:
+ Verwendung von Zufallszahlengeneratoren.
+ Abhängigkeit von der Systemzeit.
+ Verwendung von Parallelität (Rennbedingungen können zu Leistungsabweichungen führen).
+ Abrufen von lokalen oder entfernten Dateien, die über die in den Eingabeparametern der Aufgabe angegebenen hinausgehen.
Weitere Szenarien, die zu nicht deterministischem Verhalten führen können, finden Sie unter [Nicht deterministische Prozesseingaben](https://www.nextflow.io/docs/latest/cache-and-resume.html#non-deterministic-process-inputs) auf der Nextflow-Dokumentationsseite.
Wenn Sie vermuten, dass eine Aufgabe nicht deterministische Ergebnisse erzeugt, sollten Sie die Funktionen der Workflow-Engine verwenden, um zu vermeiden, dass bestimmte Aufgaben zwischengespeichert werden, die nicht deterministisch sind. Anweisungen, wie Sie das Caching für einzelne Aufgaben in jeder unterstützten Workflow-Sprache deaktivieren können, finden Sie unter. [Engine-spezifische Caching-Funktionen](workflow-cache-per-engine.md)
Wir empfehlen Ihnen, Ihre spezifischen Anforderungen an den Arbeitsablauf und die Aufgaben gründlich zu überprüfen, bevor Sie das Caching von Anrufen in Umgebungen aktivieren, in denen ineffektives Caching von Anrufen oder andere als erwartete Ergebnisse ein Risiko darstellen können. Beispielsweise sollten die potenziellen Einschränkungen von Call Caching bei der Entscheidung, ob Call Caching für klinische Anwendungsfälle geeignet ist, sorgfältig abgewogen werden.
## Anforderungen an das Zwischenspeichern von Aufgaben
HealthOmics speichert Aufgabenausgaben für Aufgaben, die die folgenden Anforderungen erfüllen:
+ Die Aufgabe muss einen Container definieren. HealthOmics speichert keine Ausgaben für eine Aufgabe ohne Container im Cache.
+ Die Aufgabe muss eine oder mehrere Ausgaben erzeugen. Sie geben die Ausgaben der Aufgaben in der Workflow-Definition an.
+ Die Workflow-Definition darf keine dynamischen Werte verwenden. Wenn Sie beispielsweise einen Parameter mit einem Wert an eine Aufgabe übergeben, der bei jedem Lauf erhöht wird, werden die Ausgaben der Aufgabe HealthOmics nicht zwischengespeichert.
**Anmerkung**
Wenn mehrere Aufgaben in einer Ausführung dasselbe Container-Image verwenden, wird HealthOmics für alle diese Aufgaben dieselbe Image-Version bereitgestellt. Nach HealthOmics dem Abrufen des Images werden alle Aktualisierungen des Container-Images für die Dauer der Ausführung ignoriert. Dieser Ansatz bietet eine vorhersehbare und konsistente Benutzererfahrung und verhindert potenzielle Probleme, die sich aus Aktualisierungen des Container-Images ergeben könnten, die während der Ausführung bereitgestellt werden.
## Führen Sie die Cache-Leistung aus
Wenn Sie das Zwischenspeichern von Aufrufen für einen Lauf aktivieren, stellen Sie möglicherweise die folgenden Auswirkungen auf die Ausführungsleistung fest:
+ HealthOmics Speichert während der ersten Ausführung die Cache-Daten für Aufgaben in der Ausführung. Bei diesem Lauf kann es zu längeren Exportzeiten kommen, da das Aufruf-Caching die Menge der Exportdaten erhöht.
+ Wenn Sie in nachfolgenden Ausführungen einen Lauf aus dem Cache wieder aufnehmen, kann dies die Anzahl der Verarbeitungsschritte und die Laufzeit verringern.
+ Wenn Sie sich auch dafür entscheiden, Zwischendateien als Ausgaben zu deklarieren, können Ihre Exportzeiten sogar noch länger sein, da diese Daten ausführlicher sein können.
## Ereignisse zur Aufbewahrung und Invalidierung von Daten zwischenspeichern
Der Hauptzweck eines Run-Caches besteht darin, die Berechnung der Aufgaben während der Ausführung zu optimieren. Wenn es einen gültigen passenden Cache-Eintrag für eine Aufgabe gibt, wird der Cache-Eintrag HealthOmics verwendet, anstatt die Aufgabe neu zu berechnen. Andernfalls wird das Standardverhalten des Dienstes HealthOmics wiederhergestellt, bei dem die Aufgabe und die von ihr abhängigen Aufgaben neu berechnet werden. Bei diesem Ansatz führen Cache-Fehler nicht dazu, dass die Ausführung fehlschlägt.
Es wird empfohlen, die Größe des Run-Caches zu verwalten. Im Laufe der Zeit sind Cacheeinträge aufgrund von Workflow-Engine- oder HealthOmics Service-Updates oder aufgrund von Änderungen, die Sie an der Ausführung oder den Ausführungsaufgaben vorgenommen haben, möglicherweise nicht mehr gültig. Die folgenden Abschnitte enthalten zusätzliche Informationen.
**Topics**
+ [Manifeste Versionsupdates und Datenaktualität](#workflow-cache-data-versions)
+ [Verhalten beim Ausführen des Caches](#run-cache-behavior)
+ [Steuern Sie die Größe des Run-Caches](#workflow-cache-manage)
### Manifeste Versionsupdates und Datenaktualität
In regelmäßigen Abständen führt der HealthOmics Dienst möglicherweise neue Funktionen oder Workflow-Engine-Updates ein, die einige oder alle Run-Cache-Einträge ungültig machen. In diesem Fall kann es bei Ihren Läufen zu einem einmaligen Cachefehler kommen.
HealthOmics erstellt für jeden Cache-Eintrag eine [JSON-Manifestdatei](workflow-cache-contents.md). Für Läufe, die nach dem 12. Februar 2025 gestartet wurden, enthält die Manifestdatei einen Versionsparameter. Wenn ein Service-Update Cache-Einträge ungültig macht, wird die Versionsnummer HealthOmics erhöht, sodass Sie die Legacy-Cache-Einträge identifizieren können, die entfernt werden müssen.
Das folgende Beispiel zeigt eine Manifestdatei, deren Version auf 2 gesetzt ist:
```
{
"arn": "arn:aws:omics:us-west-2:12345678901:runCache/0123456/cacheEntry/1234567-195f-3921-a1fa-ffffcef0a6a4",
"s3uri": "s3://example/1234567-d0d1-e230-d599-10f1539f4a32/1348677/4795326/7e8c69b1-145f-3991-a1fa-ffffcef0a6a4",
"taskArn": "arn:aws:omics:us-west-2:12345678901:task/4567891",
"workDir": "/mnt/workflow/1234567-d0d1-e230-d599-10f1539f4a32/workdir/call-TxtFileCopyTask/5w6tn5feyga7noasjuecdeoqpkltrfo3/wxz2fuddlo6hc4uh5s2lreaayczduxdm",
"files": [
{
"name": "output_txt_file",
"path": "out/output_txt_file/outfile.txt",
"etag": "ajdhyg9736b9654673b9fbb486753bc8"
}
],
"nextflowContext": {},
"otherOutputs": {},
"version": 2,
}
```
Bei Läufen mit Cacheeinträgen, die nicht mehr gültig sind, erstellen Sie den Cache neu, um neue gültige Einträge zu erstellen. Führen Sie für jeden Lauf die folgenden Schritte aus:
1. Starten Sie den Lauf einmal, wobei die Cache-Aufbewahrung auf CACHE ALWAYS eingestellt ist. Bei diesem Lauf werden die neuen Cache-Einträge erstellt.
1. Setzen Sie für nachfolgende Läufe die Cache-Aufbewahrung auf die vorherige Einstellung (CACHE ALWAYS oder CACHE ON FAILURE).
Um Cache-Einträge zu bereinigen, die nicht mehr gültig sind, können Sie diese Cache-Einträge aus dem Amazon S3 S3-Cache-Bucket löschen. HealthOmics verwendet diese Cache-Einträge niemals wieder. Wenn Sie sich dafür entscheiden, ungültige Einträge beizubehalten, hat dies keine Auswirkungen auf Ihre Läufe.
**Anmerkung**
Beim Aufruf-Caching werden die Ausgabedaten der Aufgaben an dem für den Cache angegebenen Amazon S3 S3-Speicherort gespeichert, wodurch Ihnen Gebühren entstehen. AWS-Konto
### Verhalten beim Ausführen des Caches
Sie können das Verhalten beim Ausführen des Caches festlegen, um die Taskausgaben für fehlgeschlagene Läufe (Cache on Failure) oder für alle Läufe (Cache immer) zu speichern. Wenn Sie einen Run-Cache erstellen, legen Sie das Standard-Cache-Verhalten für alle Läufe fest, die diesen Cache verwenden. Sie können das Standardverhalten überschreiben, wenn Sie einen Lauf starten.
**Cache on failure**ist nützlich, wenn Sie einen Workflow debuggen, der fehlschlägt, nachdem mehrere Aufgaben erfolgreich abgeschlossen wurden. Die nachfolgende Ausführung wird mit der letzten erfolgreich abgeschlossenen Aufgabe fortgesetzt, wenn alle vom Hash berücksichtigten eindeutigen Variablen mit der vorherigen Ausführung identisch sind.
**Cache always**ist nützlich, wenn Sie eine Aufgabe in einem Workflow aktualisieren, der erfolgreich abgeschlossen wurde. Wir empfehlen, dass Sie die folgenden Schritte ausführen:
1. Erstellen Sie einen neuen Lauf. Stellen Sie das **Cache-Verhalten** auf **Immer zwischenspeichern** ein und starten Sie den Lauf.
1. Nachdem die Ausführung abgeschlossen ist, aktualisieren Sie die Aufgabe im Workflow und starten Sie eine neue Ausführung mit dem Verhalten „**Immer zwischenspeichern**“. Dieser Lauf verarbeitet die aktualisierte Aufgabe und alle nachfolgenden Aufgaben, die von der aktualisierten Aufgabe abhängig sind. Alle anderen Aufgaben verwenden die zwischengespeicherten Ergebnisse.
1. Wiederholen Sie Schritt 2 nach Bedarf, bis die Entwicklung für die aktualisierte Aufgabe abgeschlossen ist.
1. Verwenden Sie die aktualisierte Aufgabe bei future Läufen nach Bedarf. Denken Sie daran, nachfolgende Läufe **im Fehlerfall auf Cache** umzustellen, wenn Sie beabsichtigen, für diese Läufe neue oder andere Eingaben zu verwenden.
**Anmerkung**
Wir empfehlen den Modus **Immer zwischenspeichern**, wenn Sie denselben Testdatensatz verwenden, jedoch nicht für mehrere Läufe. Wenn Sie diesen Modus für eine große Anzahl von Durchläufen festlegen, kann das System große Datenmengen nach Amazon S3 exportieren, was zu erhöhten Exportzeiten und Speicherkosten führt.
### Steuern Sie die Größe des Run-Caches
HealthOmics löscht oder archiviert keine Run-Cache-Daten und wendet auch keine Amazon S3 S3-Bereinigungsregeln für die Verwaltung der Cache-Daten an. Wir empfehlen Ihnen, regelmäßige Cache-Bereinigungen durchzuführen, um Amazon S3 S3-Speicherkosten zu sparen und die Größe Ihres Run-Caches überschaubar zu halten. Sie können Dateien direkt löschen oder retention/replication Datenrichtlinien für den Run-Cache-Bucket festlegen.
Sie können beispielsweise eine Amazon S3 S3-Lebenszyklusrichtlinie so konfigurieren, dass Objekte nach 90 Tagen ablaufen, oder Sie können die Cache-Daten am Ende jedes Entwicklungsprojekts manuell bereinigen.
Die folgenden Informationen können Ihnen bei der Verwaltung der Cache-Datengröße helfen:
+ Sie können sehen, wie viele Daten sich im Cache befinden, indem Sie Amazon S3 überprüfen. HealthOmics überwacht oder berichtet nicht über die Cachegröße.
+ Wenn Sie einen gültigen Cache-Eintrag löschen, schlägt die nachfolgende Ausführung nicht fehl. HealthOmics berechnet die Aufgabe und ihre abhängigen Aufgaben neu.
+ Wenn Sie Cache-Namen oder Verzeichnisstrukturen so ändern, HealthOmics dass kein passender Eintrag für eine Aufgabe gefunden wird, HealthOmics berechnet die Aufgabe neu.
Wenn Sie überprüfen müssen, ob ein Cache-Eintrag noch gültig ist, überprüfen Sie die Versionsnummer des Cache-Manifests. Weitere Informationen finden Sie unter [Manifeste Versionsupdates und Datenaktualität](#workflow-cache-data-versions).
# Einen Run-Cache erstellen
Wenn Sie einen Run-Cache erstellen, geben Sie einen Amazon S3 S3-Speicherort für die Cache-Daten an. Auf diese Daten muss sofort zugegriffen werden können. Beim Aufruf-Caching werden keine in Glacier archivierten Objekte abgerufen (z. B. GFR- und GDA-Speicherklassen).
Wenn der Amazon S3 S3-Bucket für die Cache-Daten einem anderen gehört AWS-Konto, geben Sie diese Konto-ID an, wenn Sie den Run-Cache erstellen.
## Einen Run-Cache mithilfe der Konsole erstellen
Gehen Sie von der Konsole aus wie folgt vor, um einen Run-Cache zu erstellen.
1. Öffnen Sie die [HealthOmics -Konsole](https://console.aws.amazon.com/omics/).
1. Öffnen Sie bei Bedarf den linken Navigationsbereich (±1). Wählen Sie „**Caches ausführen**“.
1. Wählen **Sie auf der Seite „Caches ausführen**“ die Option **Run-Cache erstellen** aus.
1. Konfigurieren Sie auf der Seite „**Run-Cache erstellen“ im Bereich „Details** **zum Ausführungs-Cache**“ die folgenden Felder:
1. Geben Sie einen Namen für den Run-Cache ein.
1. (Optional) Geben Sie eine Beschreibung ein.
1. Geben Sie einen S3-Speicherort für die zwischengespeicherte Ausgabe ein. Wählen Sie einen Bucket in derselben Region wie Ihr Workflow aus.
1. (Optional) Geben Sie den Namen AWS-Konto des Bucket-Besitzers ein, um die Inhaberschaft des Buckets zu überprüfen. Wenn Sie keinen Wert eingeben, ist der Standardwert Ihre Konto-ID.
1. Konfigurieren Sie unter **Cache-Verhalten** das Standardverhalten (ob Ausgaben für fehlgeschlagene Läufe oder für alle Läufe zwischengespeichert werden sollen). Wenn Sie einen Lauf starten, können Sie optional das Standardverhalten überschreiben.
1. (Optional) Ordnen Sie dem Run-Cache ein oder mehrere Tags zu.
1. Wählen Sie „**Run-Cache erstellen**“. Die Konsole zeigt den neuen Run-Cache in der Tabelle **Run-Caches an**.
## Einen Run-Cache mit der CLI erstellen
Verwenden Sie den **create-run-cache**CLI-Befehl, um einen Run-Cache zu erstellen. Das Standard-Cache-Verhalten ist`CACHE_ON_FAILURE`.
```
aws omics create-run-cache \
--name "workflow 123 run cache" \
--description "my run cache" \
--cache-s3-location "s3://amzn-s3-demo-bucket" \
--cache-behavior "CACHE_ALWAYS" \
--cache-bucket-owner-id "111122223333"
```
Wenn die Erstellung erfolgreich ist, erhalten Sie eine Antwort mit den folgenden Feldern.
```
{
"arn": "string",
"id": "string",
"status": "ACTIVE"
"tags": {}
}
```
# Einen Run-Cache aktualisieren
Sie können den Cache-Namen, die Beschreibung, die Tags oder das Cache-Verhalten ändern, aber nicht den S3-Speicherort für den Cache.
## Einen Run-Cache mithilfe der Konsole aktualisieren
Gehen Sie von der Konsole aus wie folgt vor, um einen Run-Cache zu aktualisieren.
1. Öffnen Sie die [HealthOmics -Konsole](https://console.aws.amazon.com/omics/).
1. Öffnen Sie bei Bedarf den linken Navigationsbereich (±1). Wählen Sie „**Caches ausführen**“.
1. **Wählen **Sie in der Tabelle Run Caches** den Run-Cache aus, der aktualisiert werden soll, und klicken Sie dann auf Bearbeiten.**
1. Im Bereich „**Details zum Ausführungs-Cache**“ können Sie die Felder „Name“, „Beschreibung“ und „Cache-Verhalten“ aktualisieren.
1. (Optional) Ordnen Sie dem Run-Cache ein oder mehrere neue Tags zu oder entfernen Sie vorhandene Tags.
1. Wählen Sie „**Run-Cache speichern**“.
## Aktualisierung eines Run-Caches mit der CLI
Verwenden Sie den **update-run-cache**CLI-Befehl, um einen Run-Cache zu aktualisieren.
```
aws omics update-run-cache \
--name "workflow 123 run cache" \
--id "workflow id" \
--description "my run cache" \
--cache-behavior "CACHE_ALWAYS"
```
Wenn das Update erfolgreich ist, erhalten Sie eine Antwort ohne Datenfelder.
# Löschen eines Run-Caches
Sie können einen Run-Cache löschen, wenn ihn keine aktiven Läufe verwenden. Wenn Läufe den Run-Cache verwenden, warten Sie, bis die Läufe abgeschlossen sind, oder Sie können die Läufe abbrechen.
Durch das Löschen eines Run-Caches werden die Ressource und ihre Metadaten entfernt, die Daten in Amazon S3 werden jedoch nicht gelöscht. Nachdem Sie den Cache gelöscht haben, können Sie ihn nicht erneut anhängen oder ihn für nachfolgende Läufe verwenden.
Die zwischengespeicherten Daten verbleiben zu Ihrer Prüfung in Amazon S3. Sie können alte Cache-Daten mithilfe von **Delete** Standard-S3-Vorgängen entfernen. Alternativ können Sie eine Amazon S3 S3-Lebenszyklusrichtlinie erstellen, um zwischengespeicherte Daten, die Sie nicht mehr verwenden, ablaufen zu lassen.
## Löschen eines Run-Caches mithilfe der Konsole
Gehen Sie von der Konsole aus wie folgt vor, um einen Run-Cache zu löschen.
1. Öffnen Sie die [HealthOmics -Konsole](https://console.aws.amazon.com/omics/).
1. Öffnen Sie bei Bedarf den linken Navigationsbereich (±1). Wählen Sie „**Caches ausführen**“.
1. Wählen **Sie in der Tabelle Run Caches** den Run-Cache aus, den Sie löschen möchten.
1. **Wählen **Sie im Tabellenmenü „Caches ausführen**“ die Option Löschen aus.**
1. Speichern Sie im modalen Dialog den Amazon S3 S3-Cache-Datenlink zum future Nachschlagen und bestätigen Sie dann, dass Sie den Run-Cache löschen möchten.
Sie können den Amazon S3 S3-Link verwenden, um die zwischengespeicherten Daten zu überprüfen, aber Sie können die Daten nicht erneut mit einem anderen Run-Cache verknüpfen. Löschen Sie die Cache-Daten, wenn Sie die Inspektion abgeschlossen haben.
## Löschen eines Run-Caches mit der CLI
Verwenden Sie den **delete-run-cache**CLI-Befehl, um einen Run-Cache zu löschen.
```
aws omics delete-run-cache \
--id "my cache id"
```
Wenn das Löschen erfolgreich ist, erhalten Sie eine Antwort ohne Datenfelder.
# Inhalt eines Run-Caches
HealthOmics organisiert Ihren Run-Cache mit der folgenden Struktur in Ihrem S3-Bucket:
```
s3://{cache.S3location}/{cache.uuid}/runID/taskID/{cacheentry.uuid}/
```
Die cache.uuid ist die weltweit eindeutige ID für den Cache. Die cacheentry.uuid ist die weltweit eindeutige UUID für eine zwischengespeicherte Aufgabe. HealthOmics weist die UUIDs Caches und Aufgaben zu.
Für alle Workflow-Engines enthält der Cache die folgenden Dateien:
+ Die **\$1cacheentryuuid\$1.json** Datei — HealthOmics erstellt diese Manifestdatei, die Informationen über den Cache enthält, einschließlich einer Liste aller Elemente im Cache und der [Cache-Version](how-run-cache.md#workflow-cache-data-versions).
+ Task-Ausgabedateien — Jede Task-Ausgabe besteht aus einer oder mehreren Dateien, wie von der Aufgabe definiert.
Für einen Workflow, der Nextflow verwendet, erstellt die Nextflow-Engine diese zusätzlichen Dateien im Cache:
+ Die **command.out** Datei — Diese Datei enthält den Standardinhalt zur Aufgabenausführung.
+ Die **.exitcode** Datei — Diese Datei enthält den Exit-Code der Aufgabe (eine Ganzzahl).
**Anmerkung**
Wenn Sie zur erweiterten Problembehandlung auf zwischengeschaltete Aufgabendateien in Ihrem Run-Cache zugreifen möchten, deklarieren Sie diese Dateien in der Workflow-Definition als Aufgabenausgaben.
# Engine-spezifische Caching-Funktionen
HealthOmics versucht, eine konsistente Implementierung von Call Caching in allen Workflow-Engines bereitzustellen. Je nachdem, wie jede Workflow-Engine mit bestimmten Fällen umgeht, gibt es einige Unterschiede:
+ Nextflow
+ Das Zwischenspeichern zwischen verschiedenen Nextflow-Versionen ist nicht garantiert. Wenn Sie beispielsweise eine Aufgabe in Version 23.10.0 ausführen und anschließend dieselbe Aufgabe in Version 24.10.8 ausführen, HealthOmics könnten Sie den zweiten Lauf als Cache-Fehler betrachten.
+ Sie können das Caching für einzelne Aufgaben deaktivieren, indem Sie die Cache-Direktive verwenden. **false** Informationen zu dieser Direktive finden Sie in den [Prozessen](https://www.nextflow.io/docs/latest/process.html#process-cache) in der Nextflow-Spezifikation.
+ HealthOmics verwendet den Nextflow-Lenient-Modus, unterstützt aber keinen Deep-Caching-Modus.
+ Beim Caching wird jedes einzelne S3-Objekt ausgewertet, wenn Sie ein Glob-Muster im S3-Pfad zu den Eingaben für eine Aufgabe verwenden. Wenn Sie ein neues Objekt hinzufügen, werden nur die Aufgaben HealthOmics neu berechnet, die das neue Objekt verwenden.
+ HealthOmics speichert keine Wiederholungsversuche von Aufgaben im Cache. Dieses Verhalten entspricht dem Standardverhalten von Nextflow.
+ WDL
+ HealthOmics unterstützt den neuen Verzeichnistyp für Eingaben, wenn Sie die Entwicklungsversion des WDL-Workflows verwenden. Bei der Zwischenspeicherung von Aufrufen werden alle Aufgaben, die das Verzeichnis eingeben, HealthOmics neu berechnet, wenn sich ein Objekt im Verzeichnis ändert.
+ HealthOmics unterstützt Caching auf Aufgabenebene, aber kein Caching auf Workflow-Ebene.
+ **Sie können das Caching für einzelne Aufgaben deaktivieren, indem Sie das Volatile-Attribut verwenden.** Weitere Informationen finden Sie unter [Deaktivieren Sie das Caching auf Aufgabenebene mit dem Attribut volatile](workflow-languages-wdl.md#workflow-wdl-volatile-attribute).
+ CWL
+ Konstante Ausgaben von Aufgaben sind in den Manifesten nicht explizit sichtbar. HealthOmics speichert konstante Ausgaben als Zwischendateien im Cache.
+ Sie können das Caching für einzelne Aufgaben mithilfe der [WorkReuse](https://www.commonwl.org/v1.1/Workflow.html#WorkReuse)Funktion steuern.
# Verwenden Sie den Run-Cache
Standardmäßig verwenden Läufe keinen Run-Cache. Um einen Cache für die Ausführung zu verwenden, geben Sie den Run-Cache und das Verhalten des Run-Caches an, wenn Sie die Ausführung starten.
Nach Abschluss eines Laufs können Sie die Konsole, CloudWatch Protokolle oder API-Operationen verwenden, um Cache-Treffer zu verfolgen oder Cache-Probleme zu beheben. Details dazu finden Sie unter [Informationen zum Anruf-Caching werden nachverfolgt](#workflow-cache-track) und [Behebung von Problemen beim Zwischenspeichern von Anrufen](troubleshooting.md#workflow-cache-troubleshooting).
Wenn eine oder mehrere Aufgaben in einem Lauf nicht deterministische Ausgaben generieren, empfehlen wir dringend, für die Ausführung kein Aufruf-Caching zu verwenden oder diese speziellen Aufgaben vom Caching auszuschließen. Weitere Informationen finden Sie unter [Modell der geteilten Verantwortung](how-run-cache.md#run-cache-srm).
**Anmerkung**
Sie geben eine IAM-Dienstrolle an, wenn Sie einen Lauf starten. Um Call Caching verwenden zu können, benötigt die Service-Rolle die Erlaubnis, auf den Amazon S3 S3-Standort Run Cache zuzugreifen. Weitere Informationen finden Sie unter [Servicerollen für AWS HealthOmics](permissions-service.md).
Sie können [Amazon Q CLI](https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/what-is.html) verwenden, um Ihre Run-Cache-Daten zu analysieren und zu verwalten. Weitere Informationen finden Sie unter [Beispielaufforderungen für Amazon Q CLI](getting-started.md#omics-q-prompts) und im [HealthOmics Agentic Generative AI-Tutorial](https://github.com/aws-samples/aws-healthomics-tutorials/tree/main/generative-ai) unter. GitHub
**Topics**
+ [Konfiguration eines Laufs mit Run-Cache mithilfe der Konsole](#workflow-cache-startrun-console)
+ [Konfiguration eines Laufs mit Run-Cache über die CLI](#workflow-cache-startrun-api)
+ [Fehlerfälle bei Run-Caches](#workflow-cache-errors)
+ [Informationen zum Anruf-Caching werden nachverfolgt](#workflow-cache-track)
## Konfiguration eines Laufs mit Run-Cache mithilfe der Konsole
Von der Konsole aus konfigurieren Sie den Run-Cache für einen Lauf, wenn Sie den Lauf starten.
1. Öffnen Sie die [HealthOmics -Konsole](https://console.aws.amazon.com/omics/).
1. Öffnen Sie bei Bedarf den linken Navigationsbereich (±1). Wählen Sie **Läufe** aus.
1. Wählen Sie auf der Seite „**Läufe**“ den Lauf aus, den Sie starten möchten.
1. Wählen Sie **Start run und führen** Sie die Schritte 1 und 2 von **Run starten aus**, wie unter beschrieben[Einen Lauf über die Konsole starten](starting-a-run.md#starting-a-run-console).
1. Wählen Sie in Schritt 3 von **Start Run** die **Option Existierenden Run-Cache auswählen aus**.
1. Wählen Sie den Cache aus der Dropdownliste „**Cache-ID ausführen**“ aus.
1. Um das Standardverhalten beim Ausführen des Cache zu überschreiben, wählen Sie das **Cache-Verhalten** für den Lauf aus. Weitere Informationen finden Sie unter [Verhalten beim Ausführen des Caches](how-run-cache.md#run-cache-behavior).
1. Fahren Sie mit Schritt 4 von **Start Run** fort.
## Konfiguration eines Laufs mit Run-Cache über die CLI
Um einen Lauf zu starten, der einen Run-Cache verwendet, fügen Sie dem CLI-Befehl **start-run** den Parameter cache-id hinzu. Verwenden Sie optional den `cache-behavior` Parameter, um das Standardverhalten zu überschreiben, das Sie für den Run-Cache konfiguriert haben. Das folgende Beispiel zeigt nur die Cache-Felder für den Befehl:
```
aws omics start-run \
...
--cache-id "xxxxxx" \
--cache-behavior CACHE_ALWAYS
```
Wenn der Vorgang erfolgreich ist, erhalten Sie eine Antwort ohne Datenfelder.
## Fehlerfälle bei Run-Caches
In den folgenden Szenarien werden Taskausgaben HealthOmics möglicherweise nicht zwischengespeichert, auch nicht bei einer Ausführung, bei der das Cacheverhalten auf **Immer zwischenspeichern** eingestellt ist.
+ Wenn bei der Ausführung ein Fehler auftritt, bevor die erste Aufgabe erfolgreich abgeschlossen wurde, können keine Cache-Ausgaben exportiert werden.
+ Wenn der Exportvorgang fehlschlägt, werden die Aufgabenausgaben HealthOmics nicht im Amazon S3 S3-Cache gespeichert.
+ Wenn der Lauf aufgrund eines **filesystem out of space** Fehlers fehlschlägt, speichert das Aufruf-Caching keine Aufgabenausgaben.
+ Wenn Sie einen Lauf abbrechen, speichert das Aufruf-Caching keine Aufgabenausgaben.
+ Wenn bei der Ausführung ein Timeout auftritt, speichert das Aufruf-Caching keine Aufgabenausgaben, auch wenn Sie den Lauf so konfiguriert haben, dass bei einem Fehler der Cache verwendet wird.
## Informationen zum Anruf-Caching werden nachverfolgt
Sie können Call-Caching-Ereignisse (z. B. Run-Cache-Treffer) mithilfe der Konsole, der CLI oder CloudWatch Logs verfolgen.
**Topics**
+ [Cache-Treffer mithilfe der Konsole verfolgen](#workflow-cache-track-console)
+ [Verfolgen Sie das Anruf-Caching mit der CLI](#workflow-cache-track-cli)
+ [Verfolgen Sie das Caching von Anrufen mithilfe von Protokollen CloudWatch](#workflow-cache-track-cwl)
### Cache-Treffer mithilfe der Konsole verfolgen
Auf der Seite mit den Ausführungsdetails für einen Lauf werden in der Tabelle **Aufgaben ausführen** Informationen zu **Cache-Treffern** für jede Aufgabe angezeigt. Die Tabelle enthält auch einen Link zum zugehörigen Cache-Eintrag. Gehen Sie wie folgt vor, um die Cache-Trefferinformationen für einen Lauf anzuzeigen.
1. Öffnen Sie die [HealthOmics -Konsole](https://console.aws.amazon.com/omics/).
1. Öffnen Sie bei Bedarf den linken Navigationsbereich (±1). Wählen Sie **Läufe** aus.
1. Wählen Sie auf der Seite „**Läufe**“ den Lauf aus, den Sie überprüfen möchten.
1. Wählen Sie auf der Seite mit den Ausführungsdetails die Registerkarte **Aufgaben ausführen**, um die Tabelle mit den Aufgaben anzuzeigen.
1. Wenn eine Aufgabe einen Cache-Treffer hat, enthält die Spalte **Cache-Treffer** einen Link zum Speicherort des Run-Cache-Eintrags in Amazon S3.
1. Wählen Sie den Link, um den Run-Cache-Eintrag zu überprüfen.
### Verfolgen Sie das Anruf-Caching mit der CLI
Überprüfen Sie mit dem CLI-Befehl **get-run**, ob der Lauf einen Aufrufcache verwendet hat.
```
aws omics get-run --id 1234567
```
Wenn das `cacheId` Feld in der Antwort gesetzt ist, verwendet die Ausführung diesen Cache.
Verwenden Sie den **list-run-tasks**CLI-Befehl, um den Speicherort der Cache-Daten für jede zwischengespeicherte Aufgabe in der Ausführung abzurufen.
```
aws omics list-run-tasks --id 1234567
```
Wenn das Feld CacheHit für eine Aufgabe den Wert true hat, gibt das Feld caches3URI in der Antwort den Speicherort der Cache-Daten für diese Aufgabe an.
Sie können auch den **get-run-task**CLI-Befehl verwenden, um den Cache-Datenspeicherort für eine bestimmte Aufgabe abzurufen:
```
aws omics get-run-task --id 1234567 --task-id
```
### Verfolgen Sie das Caching von Anrufen mithilfe von Protokollen CloudWatch
HealthOmics erstellt Cache-Aktivitätsprotokolle in der `/aws/omics/WorkflowLog` CloudWatch Protokollgruppe. Für jeden Run-Cache gibt es einen Log-Stream: **RunCache//**.
HealthOmics Generiert für Läufe, die Aufruf-Caching verwenden, CloudWatch Log-Einträge für die folgenden Ereignisse:
+ einen Cache-Eintrag erstellen (CACHE\$1ENTRY\$1CREATED)
+ Abgleichen eines Cache-Eintrags (CACHE\$1HIT)
+ konnte mit einem Cache-Eintrag nicht übereinstimmen (CACHE\$1MISS)
Weitere Hinweise zu diesen Protokollen finden Sie unter. [Meldet sich an CloudWatch](monitoring-cloudwatch-logs.md#cloudwatch-logs)
Verwenden Sie die folgende CloudWatch Insights-Abfrage für die `/aws/omics/WorkflowLog` Protokollgruppe, um die Anzahl der Cache-Treffer pro Lauf für diesen Cache zurückzugeben:
```
filter @logStream like 'runCache//'
fields @timestamp, @message
filter logMessage like 'CACHE_HIT'
parse "run: *," as run
stats count(*) as cacheHits by run
```
Verwenden Sie die folgende Abfrage, um die Anzahl der Cache-Einträge zurückzugeben, die bei jedem Lauf erstellt wurden:
```
filter @logStream like 'runCache//'
fields @timestamp, @message
filter logMessage like 'CACHE_ENTRY_CREATED'
parse "run: *," as run
stats count(*) as cacheEntries by run
```