Skip to main content
Die deutsche Sprachversion wurde als Serviceleistung für Sie durch maschinelle Übersetzung erstellt. Bei eventuellen Unstimmigkeiten hat die englische Sprachversion Vorrang.

Trident Protect-Ausführungshooks verwalten

Beitragende netapp-aruldeepa

Ein Ausführungshook ist eine benutzerdefinierte Aktion, die Sie so konfigurieren können, dass sie in Verbindung mit einer Datensicherungsoperation einer verwalteten App ausgeführt wird. Wenn Sie beispielsweise über eine Datenbank-App verfügen, können Sie mithilfe eines Ausführungs-Hooks alle Datenbanktransaktionen vor einem Snapshot anhalten und die Transaktionen nach Abschluss des Snapshots fortsetzen. Dadurch werden anwendungskonsistente Snapshots gewährleistet.

Arten von Ausführungs-Hooks

Trident Protect unterstützt die folgenden Arten von Ausführungs-Hooks, je nachdem, wann sie ausgeführt werden können:

  • Vorab-Schnappschuss

  • Nach dem Snapshot

  • Vorsicherung

  • Nach der Sicherung

  • Nach der Wiederherstellung

  • Nach dem Failover

Reihenfolge der Ausführung

Wenn ein Datenschutzvorgang ausgeführt wird, finden Ausführungs-Hook-Ereignisse in der folgenden Reihenfolge statt:

  1. Alle anwendbaren benutzerdefinierten Ausführungs-Hooks vor der Operation werden auf den entsprechenden Containern ausgeführt. Sie können so viele benutzerdefinierte Hooks vor der Operation erstellen und ausführen, wie Sie benötigen, aber die Reihenfolge der Ausführung dieser Hooks vor der Operation ist weder garantiert noch konfigurierbar.

  2. Gegebenenfalls kommt es zum Einfrieren des Dateisystems. "Erfahren Sie mehr über die Konfiguration des Einfrierens von Dateisystemen mit Trident Protect.".

  3. Der Datenschutzvorgang wird durchgeführt.

  4. Eingefrorene Dateisysteme werden gegebenenfalls wieder freigegeben.

  5. Alle anwendbaren benutzerdefinierten Ausführungs-Hooks nach der Operation werden auf den entsprechenden Containern ausgeführt. Sie können so viele benutzerdefinierte Post-Operation-Hooks erstellen und ausführen, wie Sie benötigen, aber die Reihenfolge der Ausführung dieser Hooks nach der Operation ist weder garantiert noch konfigurierbar.

Wenn Sie mehrere Ausführungs-Hooks desselben Typs erstellen (z. B. Pre-Snapshot), ist die Ausführungsreihenfolge dieser Hooks nicht garantiert. Die Reihenfolge der Ausführung von Hooks unterschiedlichen Typs ist jedoch gewährleistet. Im Folgenden sehen Sie beispielsweise die Ausführungsreihenfolge einer Konfiguration, die alle verschiedenen Hook-Typen enthält:

  1. Vor dem Snapshot ausgeführte Hooks

  2. Nach dem Snapshot ausgeführte Hooks

  3. Vor der Sicherung ausgeführte Hooks

  4. Nach der Sicherung ausgeführte Hooks

Hinweis Das vorhergehende Befehlsbeispiel gilt nur, wenn Sie eine Sicherung durchführen, die keinen vorhandenen Snapshot verwendet.
Hinweis Sie sollten Ihre Ausführungs-Hook-Skripte immer testen, bevor Sie sie in einer Produktionsumgebung aktivieren. Mit dem Befehl „kubectl exec“ können Sie die Skripte bequem testen. Nachdem Sie die Ausführungs-Hooks in einer Produktionsumgebung aktiviert haben, testen Sie die resultierenden Snapshots und Backups, um sicherzustellen, dass sie konsistent sind. Sie können dies tun, indem Sie die App in einen temporären Namespace klonen, den Snapshot oder das Backup wiederherstellen und dann die App testen.
Hinweis Wenn ein Pre-Snapshot-Ausführungs-Hook Kubernetes-Ressourcen hinzufügt, ändert oder entfernt, werden diese Änderungen in den Snapshot oder die Sicherung und in alle nachfolgenden Wiederherstellungsvorgänge einbezogen.

Wichtige Hinweise zu benutzerdefinierten Ausführungs-Hooks

Berücksichtigen Sie Folgendes, wenn Sie Ausführungs-Hooks für Ihre Apps planen.

  • Ein Ausführungs-Hook muss ein Skript verwenden, um Aktionen auszuführen. Viele Ausführungs-Hooks können auf dasselbe Skript verweisen.

  • Trident Protect verlangt, dass die Skripte, die von den Ausführungs-Hooks verwendet werden, im Format ausführbarer Shell-Skripte geschrieben sind.

  • Die Skriptgröße ist auf 96 KB begrenzt.

  • Trident Protect verwendet Execution Hook-Einstellungen und alle übereinstimmenden Kriterien, um zu bestimmen, welche Hooks für einen Snapshot-, Backup- oder Wiederherstellungsvorgang anwendbar sind.

Hinweis Da Ausführungs-Hooks häufig die Funktionalität der Anwendung, für die sie ausgeführt werden, einschränken oder vollständig deaktivieren, sollten Sie immer versuchen, die Ausführungszeit Ihrer benutzerdefinierten Ausführungs-Hooks zu minimieren. Wenn Sie einen Sicherungs- oder Snapshot-Vorgang mit zugehörigen Ausführungs-Hooks starten, ihn dann aber abbrechen, können die Hooks weiterhin ausgeführt werden, wenn der Sicherungs- oder Snapshot-Vorgang bereits begonnen hat. Dies bedeutet, dass die in einem Ausführungs-Hook nach der Sicherung verwendete Logik nicht davon ausgehen kann, dass die Sicherung abgeschlossen wurde.

Ausführungs-Hook-Filter

Wenn Sie einen Ausführungs-Hook für eine Anwendung hinzufügen oder bearbeiten, können Sie dem Ausführungs-Hook Filter hinzufügen, um zu verwalten, mit welchen Containern der Hook übereinstimmt. Filter sind nützlich für Anwendungen, die auf allen Containern dasselbe Container-Image verwenden, aber jedes Image möglicherweise für einen anderen Zweck verwenden (z. B. Elasticsearch). Mithilfe von Filtern können Sie Szenarien erstellen, in denen Ausführungs-Hooks auf einigen, aber nicht unbedingt allen identischen Containern ausgeführt werden. Wenn Sie mehrere Filter für einen einzelnen Ausführungs-Hook erstellen, werden diese mit einem logischen UND-Operator kombiniert. Sie können bis zu 10 aktive Filter pro Ausführungs-Hook haben.

Jeder Filter, den Sie einem Ausführungs-Hook hinzufügen, verwendet einen regulären Ausdruck, um Container in Ihrem Cluster abzugleichen. Wenn ein Hook mit einem Container übereinstimmt, führt der Hook das zugehörige Skript auf diesem Container aus. Reguläre Ausdrücke für Filter verwenden die Syntax „Regulärer Ausdruck 2“ (RE2), die das Erstellen eines Filters, der Container aus der Liste der Übereinstimmungen ausschließt, nicht unterstützt. Informationen zur Syntax, die Trident Protect für reguläre Ausdrücke in Ausführungshook-Filtern unterstützt, finden Sie unter "Unterstützung der Syntax „Regulärer Ausdruck 2“ (RE2)" .

Hinweis Wenn Sie einem Ausführungs-Hook, der nach einem Wiederherstellungs- oder Klonvorgang ausgeführt wird, einen Namespace-Filter hinzufügen und sich die Wiederherstellungs- oder Klonquelle und das Ziel in unterschiedlichen Namespaces befinden, wird der Namespace-Filter nur auf den Ziel-Namespace angewendet.

Beispiele für Ausführungs-Hooks

Besuchen Sie die "NetApp Verda GitHub-Projekt" um echte Ausführungs-Hooks für beliebte Apps wie Apache Cassandra und Elasticsearch herunterzuladen. Sie können sich auch Beispiele ansehen und Ideen für die Strukturierung Ihrer eigenen benutzerdefinierten Ausführungs-Hooks holen.

Erstelle einen Ausführungs-Hook

Sie können mit Trident Protect einen benutzerdefinierten Ausführungs-Hook für eine App erstellen. Sie benötigen die Berechtigungen Eigentümer, Administrator oder Mitglied, um Ausführungs-Hooks zu erstellen.

Verwenden Sie einen CR
Schritte
  1. Erstellen Sie die benutzerdefinierte Ressourcendatei (CR-Datei) und benennen Sie sie. trident-protect-hook.yaml .

  2. Konfigurieren Sie die folgenden Attribute so, dass sie Ihrer Trident Protect-Umgebung und Clusterkonfiguration entsprechen:

    • metadata.name: (Erforderlich) Der Name dieser benutzerdefinierten Ressource; wählen Sie einen eindeutigen und aussagekräftigen Namen für Ihre Umgebung.

    • spec.applicationRef: (Erforderlich) Der Kubernetes-Name der Anwendung, für die der Ausführungshook ausgeführt werden soll.

    • spec.stage: (Erforderlich) Eine Zeichenkette, die angibt, in welcher Phase der Aktion der Ausführungs-Hook ausgeführt werden soll. Mögliche Werte:

      • Vor

      • Post

    • spec.action: (Erforderlich) Eine Zeichenkette, die angibt, welche Aktion der Ausführungshook ausführen wird, vorausgesetzt, alle angegebenen Ausführungshook-Filter stimmen überein. Mögliche Werte:

      • Schnappschuss

      • Sicherung

      • Wiederherstellen

      • Ausfallsicherung

    • spec.enabled: (Optional) Gibt an, ob dieser Ausführungs-Hook aktiviert oder deaktiviert ist. Wenn kein Wert angegeben ist, ist der Standardwert „true“.

    • spec.hookSource: (Erforderlich) Eine Zeichenkette, die das Base64-kodierte Hook-Skript enthält.

    • spec.timeout: (Optional) Eine Zahl, die angibt, wie lange in Minuten der Ausführungs-Hook ausgeführt werden darf. Der Mindestwert beträgt 1 Minute, der Standardwert beträgt 25 Minuten, sofern nichts anderes angegeben ist.

    • spec.arguments: (Optional) Eine YAML-Liste von Argumenten, die Sie für den Ausführungs-Hook angeben können.

    • spec.matchingCriteria: (Optional) Eine optionale Liste von Kriterien-Schlüssel-Wert-Paaren, wobei jedes Paar einen Ausführungs-Hook-Filter bildet. Sie können pro Ausführungs-Hook bis zu 10 Filter hinzufügen.

    • spec.matchingCriteria.type: (Optional) Eine Zeichenkette, die den Typ des Ausführungs-Hook-Filters identifiziert. Mögliche Werte:

      • ContainerImage

      • ContainerName

      • PodName

      • PodLabel

      • NamespaceName

    • spec.matchingCriteria.value: (Optional) Eine Zeichenkette oder ein regulärer Ausdruck, der den Wert des Ausführungs-Hook-Filters identifiziert.

      Beispiel-YAML:

    apiVersion: protect.trident.netapp.io/v1
    kind: ExecHook
    metadata:
      name: example-hook-cr
      namespace: my-app-namespace
      annotations:
        astra.netapp.io/astra-control-hook-source-id: /account/test/hookSource/id
    spec:
      applicationRef: my-app-name
      stage: Pre
      action: Snapshot
      enabled: true
      hookSource: IyEvYmluL2Jhc2gKZWNobyAiZXhhbXBsZSBzY3JpcHQiCg==
      timeout: 10
      arguments:
        - FirstExampleArg
        - SecondExampleArg
      matchingCriteria:
        - type: containerName
          value: mysql
        - type: containerImage
          value: bitnami/mysql
        - type: podName
          value: mysql
        - type: namespaceName
          value: mysql-a
        - type: podLabel
          value: app.kubernetes.io/component=primary
        - type: podLabel
          value: helm.sh/chart=mysql-10.1.0
        - type: podLabel
          value: deployment-type=production
  3. Nachdem Sie die CR-Datei mit den korrekten Werten gefüllt haben, wenden Sie die CR an:

    kubectl apply -f trident-protect-hook.yaml
Verwenden der CLI
Schritte
  1. Erstellen Sie den Ausführungs-Hook und ersetzen Sie die Werte in Klammern durch Informationen aus Ihrer Umgebung. Beispiel:

    tridentctl-protect create exechook <my_exec_hook_name> --action <action_type> --app <app_to_use_hook> --stage <pre_or_post_stage> --source-file <script-file> -n <application_namespace>

Einen Ausführungs-Hook manuell ausführen

Sie können einen Ausführungshook manuell ausführen, beispielsweise zu Testzwecken oder wenn Sie den Hook nach einem Fehler manuell erneut ausführen müssen. Sie benötigen Eigentümer-, Administrator- oder Mitgliedsberechtigungen, um Ausführungshooks manuell auszuführen.

Das manuelle Ausführen eines Ausführungshooks besteht aus zwei grundlegenden Schritten:

  1. Erstellen Sie eine Ressourcensicherung, die Ressourcen sammelt und eine Sicherungskopie davon erstellt, um festzulegen, wo der Hook ausgeführt wird.

  2. Führe den Ausführungshook für das Backup aus.

Schritt 1: Erstellen Sie eine Ressourcensicherung.
Verwenden Sie einen CR
Schritte
  1. Erstellen Sie die benutzerdefinierte Ressourcendatei (CR-Datei) und benennen Sie sie. trident-protect-resource-backup.yaml .

  2. Konfigurieren Sie die folgenden Attribute so, dass sie Ihrer Trident Protect-Umgebung und Clusterkonfiguration entsprechen:

    • metadata.name: (Erforderlich) Der Name dieser benutzerdefinierten Ressource; wählen Sie einen eindeutigen und aussagekräftigen Namen für Ihre Umgebung.

    • spec.applicationRef: (Erforderlich) Der Kubernetes-Name der Anwendung, für die das Ressourcen-Backup erstellt werden soll.

    • spec.appVaultRef: (Erforderlich) Der Name des AppVaults, in dem die Sicherungsinhalte gespeichert sind.

    • spec.appArchivePath: Der Pfad innerhalb von AppVault, in dem die Sicherungsinhalte gespeichert sind. Sie können folgenden Befehl verwenden, um diesen Pfad zu finden:

      kubectl get backups <BACKUP_NAME> -n my-app-namespace -o jsonpath='{.status.appArchivePath}'

      Beispiel-YAML:

    ---
    apiVersion: protect.trident.netapp.io/v1
    kind: ResourceBackup
    metadata:
      name: example-resource-backup
    spec:
      applicationRef: my-app-name
      appVaultRef: my-appvault-name
      appArchivePath: example-resource-backup
  3. Nachdem Sie die CR-Datei mit den korrekten Werten gefüllt haben, wenden Sie die CR an:

    kubectl apply -f trident-protect-resource-backup.yaml
Verwenden der CLI
Schritte
  1. Erstellen Sie die Sicherungskopie und ersetzen Sie die Werte in Klammern durch Informationen aus Ihrer Umgebung. Beispiel:

    tridentctl protect create resourcebackup <my_backup_name> --app <my_app_name> --appvault <my_appvault_name> -n <my_app_namespace> --app-archive-path <app_archive_path>
  2. Den Status der Datensicherung anzeigen. Sie können diesen Beispielbefehl so oft verwenden, bis der Vorgang abgeschlossen ist:

    tridentctl protect get resourcebackup -n <my_app_namespace> <my_backup_name>
  3. Überprüfen Sie, ob die Datensicherung erfolgreich war:

    kubectl describe resourcebackup <my_backup_name>
Schritt 2: Den Ausführungshook ausführen
Verwenden Sie einen CR
Schritte
  1. Erstellen Sie die benutzerdefinierte Ressourcendatei (CR-Datei) und benennen Sie sie. trident-protect-hook-run.yaml .

  2. Konfigurieren Sie die folgenden Attribute so, dass sie Ihrer Trident Protect-Umgebung und Clusterkonfiguration entsprechen:

    • metadata.name: (Erforderlich) Der Name dieser benutzerdefinierten Ressource; wählen Sie einen eindeutigen und aussagekräftigen Namen für Ihre Umgebung.

    • spec.applicationRef: (Erforderlich) Stellen Sie sicher, dass dieser Wert mit dem Anwendungsnamen aus dem ResourceBackup CR übereinstimmt, den Sie in Schritt 1 erstellt haben.

    • spec.appVaultRef: (Erforderlich) Stellen Sie sicher, dass dieser Wert mit dem appVaultRef aus dem ResourceBackup CR übereinstimmt, den Sie in Schritt 1 erstellt haben.

    • spec.appArchivePath: Stellen Sie sicher, dass dieser Wert mit dem appArchivePath des ResourceBackup CR übereinstimmt, den Sie in Schritt 1 erstellt haben.

      kubectl get backups <BACKUP_NAME> -n my-app-namespace -o jsonpath='{.status.appArchivePath}'
    • spec.action: (Erforderlich) Eine Zeichenkette, die angibt, welche Aktion der Ausführungshook ausführen wird, vorausgesetzt, alle angegebenen Ausführungshook-Filter stimmen überein. Mögliche Werte:

      • Schnappschuss

      • Sicherung

      • Wiederherstellen

      • Ausfallsicherung

    • spec.stage: (Erforderlich) Eine Zeichenkette, die angibt, in welcher Phase der Aktion der Ausführungs-Hook ausgeführt werden soll. Dieser Hakenlauf wird in keiner anderen Phase Haken ausführen. Mögliche Werte:

      • Vor

      • Post

        Beispiel-YAML:

    ---
    apiVersion: protect.trident.netapp.io/v1
    kind: ExecHooksRun
    metadata:
      name: example-hook-run
    spec:
      applicationRef: my-app-name
      appVaultRef: my-appvault-name
      appArchivePath: example-resource-backup
      stage: Post
      action: Failover
  3. Nachdem Sie die CR-Datei mit den korrekten Werten gefüllt haben, wenden Sie die CR an:

    kubectl apply -f trident-protect-hook-run.yaml
Verwenden der CLI
Schritte
  1. Erstellen Sie die manuelle Ausführungs-Hook-Anforderung:

    tridentctl protect create exechooksrun <my_exec_hook_run_name> -n <my_app_namespace> --action snapshot --stage <pre_or_post> --app <my_app_name> --appvault <my_appvault_name> --path <my_backup_name>
  2. Überprüfen Sie den Status des Ausführungs-Hooks. Sie können diesen Befehl so oft ausführen, bis der Vorgang abgeschlossen ist:

    tridentctl protect get exechooksrun -n <my_app_namespace> <my_exec_hook_run_name>
  3. Beschreiben Sie das exechooksrun-Objekt, um die endgültigen Details und den Status anzuzeigen:

    kubectl -n <my_app_namespace> describe exechooksrun <my_exec_hook_run_name>