Skip to main content
Eine neuere Version dieses Produkts ist erhältlich.
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

Änderungen vorschlagen

Ein Ausführungshook ist eine benutzerdefinierte Aktion, die Sie so konfigurieren können, dass sie in Verbindung mit einem Datenschutzvorgang einer verwalteten App ausgeführt wird. Wenn Sie beispielsweise eine Datenbank-App haben, können Sie einen Ausführungshook verwenden, um alle Datenbanktransaktionen vor einem Snapshot anzuhalten und die Transaktionen nach Abschluss des Snapshots fortzusetzen. Dies gewährleistet applikationskonsistente Snapshots.

Arten von Execution Hooks

Trident Protect unterstützt die folgenden Arten von Ausführungshooks, basierend darauf, wann sie ausgeführt werden können:

  • Vor-Snapshot

  • Nach dem Schnappschuss

  • Pre-Backup

  • Nach dem Backup

  • Nach der Wiederherstellung

  • Nach dem Failover

Ausführungsreihenfolge

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

  1. Alle anwendbaren benutzerdefinierten Pre-Operation-Hooks werden in den entsprechenden Containern ausgeführt. Sie können beliebig viele benutzerdefinierte Pre-Operation-Hooks erstellen und ausführen, aber die Ausführungsreihenfolge dieser Hooks vor der Operation ist weder garantiert noch konfigurierbar.

  2. Gegebenenfalls kommt es zu Dateisystem-Freezes. "Erfahren Sie mehr über die Konfiguration des Einfrierens von Dateisystemen mit Trident Protect".

  3. Der Datenschutzvorgang wird durchgeführt.

  4. Eingefrorene Dateisysteme werden, falls zutreffend, wieder freigegeben.

  5. Alle anwendbaren benutzerdefinierten Nachbearbeitungs-Hooks werden in den entsprechenden Containern ausgeführt. Sie können beliebig viele benutzerdefinierte Nachbearbeitungs-Hooks erstellen und ausführen, aber die Ausführungsreihenfolge 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 Ausführungsreihenfolge von Hooks unterschiedlicher Typen ist jedoch garantiert. Zum Beispiel ist dies die Ausführungsreihenfolge einer Konfiguration, die alle verschiedenen Hook-Typen enthält:

  1. Pre-Snapshot-Hooks ausgeführt

  2. Post-Snapshot-Hooks ausgeführt

  3. Pre-Backup-Hooks ausgeführt

  4. Post-Backup-Hooks ausgeführt

Hinweis Das vorhergehende Befehlsbeispiel gilt nur, wenn Sie eine Sicherung durchführen, die keinen vorhandenen Snapshot verwendet.
Hinweis Sie sollten Ihre Ausführungshook-Skripte immer testen, bevor Sie sie in einer Produktionsumgebung aktivieren. Sie können den Befehl 'kubectl exec' verwenden, um die Skripte bequem zu testen. Nachdem Sie die Ausführungshooks 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 das Backup und in jede nachfolgende Wiederherstellungsoperation einbezogen.

Wichtige Hinweise zu benutzerdefinierten Ausführungshooks

Beachten Sie Folgendes bei der Planung von Execution Hooks für Ihre Apps.

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

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

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

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

Hinweis Da Ausführungshooks die Funktionalität der Anwendung, auf der sie ausgeführt werden, oft einschränken oder vollständig deaktivieren, sollten Sie stets versuchen, die Zeit zu minimieren, die Ihre benutzerdefinierten Ausführungshooks zum Ausführen benötigen. Wenn Sie einen Sicherungs- oder Snapshot-Vorgang mit zugehörigen Ausführungshooks starten, diesen aber abbrechen, dürfen die Hooks dennoch ausgeführt werden, falls der Sicherungs- oder Snapshot-Vorgang bereits begonnen hat. Das bedeutet, dass die Logik, die in einem Ausführungshook nach der Sicherung verwendet wird, nicht davon ausgehen kann, dass die Sicherung abgeschlossen wurde.

Ausführungs-Hook-Filter

Wenn Sie einen Ausführungshook für eine Anwendung hinzufügen oder bearbeiten, können Sie Filter zum Ausführungshook hinzufügen, um zu steuern, auf welche Container der Hook angewendet wird. Filter sind nützlich für Anwendungen, die auf allen Containern dasselbe Container-Image verwenden, aber jedes Image für einen anderen Zweck nutzen (wie zum Beispiel Elasticsearch). Filter ermöglichen es Ihnen, Szenarien zu erstellen, in denen Ausführungshooks auf einigen, aber nicht unbedingt allen identischen Containern ausgeführt werden. Wenn Sie mehrere Filter für einen einzelnen Ausführungshook erstellen, werden diese mit einem logischen UND-Operator kombiniert. Sie können bis zu 10 aktive Filter pro Ausführungshook haben.

Jeder Filter, den Sie einem Ausführungshook hinzufügen, verwendet einen regulären Ausdruck, um Container in Ihrem Cluster zu finden. 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 Regular Expression 2 (RE2) Syntax, die das Erstellen eines Filters, der Container von der Liste der Treffer ausschließt, nicht unterstützt. Weitere Informationen zur Syntax, die Trident Protect für reguläre Ausdrücke in Ausführungshook-Filtern unterstützt, finden Sie unter "Unterstützung der Regular Expression 2 (RE2) Syntax".

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

Beispiele für Execution Hooks

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

Erstellen Sie einen Ausführungs-Hook

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

Verwenden Sie einen CR
Schritte
  1. Erstellen Sie die benutzerdefinierte Ressourcendatei (CR) 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 sinnvollen 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

      • Beitrag

    • spec.action: (Erforderlich) Eine Zeichenkette, die angibt, welche Aktion der Ausführungs-Hook ausführt, vorausgesetzt, dass alle angegebenen Ausführungs-Hook-Filter übereinstimmen. Mögliche Werte:

      • Schnappschuss

      • Backup

      • Wiederherstellen

      • Failover

    • spec.enabled: (Optional) Gibt an, ob dieser Ausführungs-Hook aktiviert oder deaktiviert ist. Wenn nicht angegeben, 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 und der Standardwert beträgt 25 Minuten, falls nicht angegeben.

    • spec.arguments: (Optional) Eine YAML-Liste von Argumenten, die Sie für den Ausführungshook 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 bis zu 10 Filter pro Ausführungs-Hook hinzufügen.

    • spec.matchingCriteria.type: (Optional) Eine Zeichenkette, die den Filtertyp des Ausführungshooks 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 Sie die Befehlszeile
Schritte
  1. Erstellen Sie den Ausführungs-Hook, und ersetzen Sie die Werte in Klammern durch Informationen aus Ihrer Umgebung. Zum 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ührungshook manuell ausführen

Sie können einen Ausführungs-Hook manuell zu Testzwecken ausführen oder wenn Sie den Hook nach einem Fehler manuell erneut ausführen müssen. Sie benötigen die Berechtigungen „Besitzer“, „Administrator“ oder „Mitglied“, um Ausführungs-Hooks manuell auszuführen.

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

  1. Erstellen Sie eine Ressourcensicherung, die Ressourcen sammelt und eine Sicherung davon erstellt, wobei festgelegt wird, wo der Hook ausgeführt wird

  2. Führe den Ausführungshook gegen das Backup aus

Schritt 1: Erstellen Sie eine Ressourcensicherung
Verwenden Sie einen CR
Schritte
  1. Erstellen Sie die benutzerdefinierte Ressourcendatei (CR) 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 sinnvollen 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 AppVault, in dem die Sicherungsinhalte gespeichert sind.

    • spec.appArchivePath: Der Pfad innerhalb von AppVault, in dem die Sicherungsinhalte gespeichert sind. Sie können den 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 Sie die Befehlszeile
Schritte
  1. Erstellen Sie die Sicherungskopie, indem Sie die Werte in Klammern durch Informationen aus Ihrer Umgebung ersetzen. Zum 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. Zeigen Sie den Status der Datensicherung an. Sie können diesen Beispielbefehl wiederholt verwenden, bis der Vorgang abgeschlossen ist:

    tridentctl protect get resourcebackup -n <my_app_namespace> <my_backup_name>
  3. Überprüfen Sie, ob das Backup 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) 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 sinnvollen 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 aus dem 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ührungs-Hook ausführt, vorausgesetzt, dass alle angegebenen Ausführungs-Hook-Filter übereinstimmen. Mögliche Werte:

      • Schnappschuss

      • Backup

      • Wiederherstellen

      • Failover

    • spec.stage: (Erforderlich) Eine Zeichenkette, die angibt, in welcher Phase der Aktion der Ausführungs-Hook ausgeführt werden soll. Dieser Hook-Lauf führt keine Hooks in anderen Phasen aus. Mögliche Werte:

      • Vor

      • Beitrag

        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 Sie die Befehlszeile
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 ausgeführten Hooks. Sie können diesen Befehl so lange wiederholen, 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>