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.

Managen von Trident Protect-Ausführungshaken

Beitragende netapp-mwallis

Ein Execution Hook ist eine benutzerdefinierte Aktion, die Sie so konfigurieren können, dass sie zusammen mit einem Datenschutzvorgang einer verwalteten App ausgeführt wird. Wenn Sie beispielsweise über eine Datenbank-App verfügen, können Sie mit einem Execution-Hook alle Datenbanktransaktionen vor einem Snapshot anhalten und die Transaktionen nach Abschluss des Snapshots wieder aufnehmen. Dies gewährleistet applikationskonsistente Snapshots.

Arten von Ausführungshaken

Trident Protect unterstützt die folgenden Typen von Ausführungshaken, je nachdem, wann sie ausgeführt werden können:

  • Vor dem Snapshot

  • Nach dem Snapshot

  • Vor dem Backup

  • Nach dem Backup

  • Nach dem Wiederherstellen

  • Nach Failover

Ausführungsreihenfolge

Wenn ein Datenschutzvorgang ausgeführt wird, finden Hakenereignisse in der folgenden Reihenfolge statt:

  1. Alle entsprechenden benutzerdefinierten Testhaken für die Ausführung vor dem Betrieb werden auf den entsprechenden Containern ausgeführt. Sie können beliebig viele benutzerdefinierte Hooks für die Vorbedienung erstellen und ausführen, aber die Reihenfolge der Ausführung dieser Haken vor der Operation ist weder garantiert noch konfigurierbar.

  2. Das Dateisystem hängt sich ggf. ein. "Erfahren Sie mehr über das Konfigurieren des Dateisystemfrierens mit Trident Protect".

  3. Der Vorgang der Datensicherung wird durchgeführt.

  4. Eingefrorene Dateisysteme werden gegebenenfalls nicht eingefroren.

  5. Alle entsprechenden benutzerdefinierten Testhaken für die Ausführung nach der Operation werden auf den entsprechenden Containern ausgeführt. Sie können beliebig viele benutzerdefinierte Haken für die Nachbearbeitung erstellen und ausführen, aber die Reihenfolge der Ausführung dieser Haken nach der Operation ist weder garantiert noch konfigurierbar.

Wenn Sie mehrere Testausführungshaken desselben Typs erstellen (z. B. Pre-Snapshot), ist die Reihenfolge der Ausführung dieser Haken nicht garantiert. Die Reihenfolge der Ausführung von Haken unterschiedlicher Art ist jedoch garantiert. Im Folgenden wird beispielsweise die Reihenfolge der Ausführung einer Konfiguration beschrieben, die alle verschiedenen Hooks umfasst:

  1. Hooks vor dem Snapshot wurden ausgeführt

  2. Hooks nach dem Snapshot wurden ausgeführt

  3. Hooks vor dem Backup wurden ausgeführt

  4. Hooks nach dem Backup ausgeführt

Hinweis Das Beispiel der vorherigen Reihenfolge gilt nur, wenn Sie ein Backup ausführen, das keinen vorhandenen Snapshot verwendet.
Hinweis Sie sollten Ihre 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 Testausführungshaken in einer Produktionsumgebung aktiviert haben, testen Sie die erstellten Snapshots und Backups, um sicherzustellen, dass sie konsistent sind. Dazu klonen Sie die Applikation in einem temporären Namespace, stellen den Snapshot oder das Backup wieder her und testen anschließend die App.
Hinweis Wenn ein Hook aus einer Phase vor der Snapshot-Ausführung Kubernetes-Ressourcen hinzufügt, ändert oder entfernt, werden diese Änderungen im Snapshot oder Backup und in jedem nachfolgenden Wiederherstellungsvorgang enthalten.

Wichtige Hinweise zu benutzerdefinierten Testausführungshaken

Bei der Planung von Testausführungshooks für Ihre Apps sollten Sie Folgendes berücksichtigen:

  • Ein Testsuite muss ein Skript verwenden, um Aktionen durchzuführen. Viele Testsuitehaoks können auf dasselbe Skript verweisen.

  • Trident Protect erfordert, dass die Skripte, die Ausführungshaken verwenden, im Format ausführbarer Shell-Skripte geschrieben werden.

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

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

Hinweis Da Testsuitehingel die Funktionalität der Anwendung, für die sie ausgeführt werden, oft reduzieren oder vollständig deaktivieren, sollten Sie immer versuchen, die Zeit zu minimieren, die Ihre benutzerdefinierten Testausführungshaken für die Ausführung benötigt. Wenn Sie eine Backup- oder Snapshot-Operation mit zugeordneten Testsuiten starten, diese aber dann abbrechen, können die Haken trotzdem ausgeführt werden, wenn der Backup- oder Snapshot-Vorgang bereits gestartet wurde. Das bedeutet, dass die in einem Testsuite nach dem Backup verwendete Logik nicht davon ausgehen kann, dass das Backup abgeschlossen wurde.

Filter für Testausführungshaken

Wenn Sie einen Ausführungshaken für eine Anwendung hinzufügen oder bearbeiten, können Sie dem Ausführungshaken Filter hinzufügen, um zu verwalten, welche Container der Hook entsprechen soll. Filter sind für Applikationen nützlich, die in allen Containern dasselbe Container-Image nutzen. Jedes Image kann jedoch für einen anderen Zweck (wie Elasticsearch) verwendet werden. Mit Filtern können Sie Szenarien erstellen, in denen Ausführungshaken auf einigen, aber nicht unbedingt allen identischen Containern ausgeführt werden. Wenn Sie mehrere Filter für einen einzelnen Testausführungshaken erstellen, werden diese mit einem logischen UND einem Operator kombiniert. Pro Testsuite können Sie bis zu 10 aktive Filter haben.

Jeder Filter, den Sie einem Execution Hook hinzufügen, verwendet einen regulären Ausdruck, um Container in Ihrem Cluster zu entsprechen. Wenn ein Haken einem Container entspricht, führt der Haken sein zugehöriges Skript auf diesem Container aus. Reguläre Ausdrücke für Filter verwenden die Syntax des regulären Ausdrucks 2 (RE2), die das Erstellen eines Filters nicht unterstützt, der Container aus der Liste der Übereinstimmungen ausschließt. Informationen zur Syntax, die Trident Protect für reguläre Ausdrücke in Ausführungshook-Filtern unterstützt, finden Sie unter "Syntaxunterstützung für regulären Ausdruck 2 (RE2)".

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

Beispiele für Testausführungshaken

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

Erstellen Sie einen Ausführungshaken

Mit Trident Protect können Sie einen benutzerdefinierten Ausführungshaken für eine App erstellen. Sie müssen über die Berechtigungen Eigentümer, Administrator oder Mitglied verfügen, um Testausführungshaken zu erstellen.

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

  2. Konfigurieren Sie die folgenden Attribute entsprechend Ihrer Trident Protect-Umgebung und Cluster-Konfiguration:

    • metadata.name: (required) der Name dieser benutzerdefinierten Ressource; wählen Sie einen eindeutigen und sinnvollen Namen für Ihre Umgebung.

    • Spec.applicationRef: (required) der Kubernetes-Name der Anwendung, für die der Ausführungshaken ausgeführt werden soll.

    • Spec.Stage: (required) Eine Zeichenfolge, die angibt, welche Phase während der Aktion der Ausführungshaken ausgeführt werden soll. Mögliche Werte:

      • Vor

      • Post

    • Spec.Action: (required) Eine Zeichenfolge, die angibt, welche Aktion der Ausführungshaken ausführen wird, vorausgesetzt, dass alle angegebenen Ausführungshaken-Filter übereinstimmen. Mögliche Werte:

      • Snapshot

      • Backup

      • Wiederherstellen

      • Failover

    • Spec.enabled: (Optional) gibt an, ob dieser Ausführungshaken aktiviert oder deaktiviert ist. Wenn nicht angegeben, ist der Standardwert TRUE.

    • Spec.hookSource: (required) Ein String, der das base64-kodierte Hook-Skript enthält.

    • Spec.timeout: (Optional) Eine Zahl, die definiert, wie lange der Ausführungshaken in Minuten ausgeführt werden darf. Der Mindestwert beträgt 1 Minute, und der Standardwert ist 25 Minuten, wenn nicht angegeben.

    • Spec.Arguments: (Optional) Eine YAML-Liste von Argumenten, die Sie für den Ausführungshaken angeben können.

    • Spec.matchingCriteria: (Optional) eine optionale Liste von Kriterien-Schlüsselwertpaaren, jedes Paar, das einen Ausführungshook-Filter bildet. Sie können bis zu 10 Filter pro Ausführungshaken hinzufügen.

    • Spec.matchingCriteria.type: (Optional) Eine Zeichenfolge, die den Filtertyp für den Ausführungshaken identifiziert. Mögliche Werte:

      • ContainerImage

      • Containername

      • PodName

      • PodLabel

      • NamespaceName

    • Spec.matchingCriteria.value: (Optional) Ein String oder regulärer Ausdruck, der den Wert des Ausführungshook-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 richtigen Werten ausgefüllt haben, wenden Sie den CR an:

    kubectl apply -f trident-protect-hook.yaml
Verwenden Sie die CLI
Schritte
  1. Erstellen Sie den Ausführungshaken, und ersetzen Sie 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>

Führen Sie manuell einen Ausführungshaken aus

Sie können einen Ausführungshaken manuell zu Testzwecken ausführen oder den Hook nach einem Fehler manuell erneut ausführen. Sie müssen über die Berechtigungen Eigentümer, Administrator oder Mitglied verfügen, um Ausführungshaken manuell auszuführen.

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

  1. Erstellen Sie ein Ressourcenbackup, das Ressourcen sammelt und eine Sicherung von ihnen erstellt und bestimmt, wo der Hook ausgeführt wird

  2. Führen Sie den Ausführungshaken gegen die Sicherung aus

Schritt 1: Erstellen einer Ressourcensicherung
CR verwenden
Schritte
  1. Erstellen Sie die benutzerdefinierte Ressourcendatei (CR) und benennen Sie sie trident-protect-resource-backup.yaml.

  2. Konfigurieren Sie die folgenden Attribute entsprechend Ihrer Trident Protect-Umgebung und Cluster-Konfiguration:

    • metadata.name: (required) der Name dieser benutzerdefinierten Ressource; wählen Sie einen eindeutigen und sinnvollen Namen für Ihre Umgebung.

    • Spec.applicationRef: (required) der Kubernetes-Name der Applikation, für die das Ressourcen-Backup erstellt werden soll.

    • Spec.appVaultRef: (required) der Name des AppVault, in dem der Backup-Inhalt gespeichert ist.

    • Spec.appArchivePath: Der Pfad innerhalb von AppVault, in dem die Backup-Inhalte gespeichert werden. 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 richtigen Werten ausgefüllt haben, wenden Sie den CR an:

    kubectl apply -f trident-protect-resource-backup.yaml
Verwenden Sie die CLI
Schritte
  1. Erstellen Sie das Backup, und ersetzen Sie 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 des Backups anzeigen. 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 die Sicherung erfolgreich war:

    kubectl describe resourcebackup <my_backup_name>
Schritt 2: Führen Sie den Ausführungshaken aus
CR verwenden
Schritte
  1. Erstellen Sie die benutzerdefinierte Ressourcendatei (CR) und benennen Sie sie trident-protect-hook-run.yaml.

  2. Konfigurieren Sie die folgenden Attribute entsprechend Ihrer Trident Protect-Umgebung und Cluster-Konfiguration:

    • metadata.name: (required) der Name dieser benutzerdefinierten Ressource; wählen Sie einen eindeutigen und sinnvollen Namen für Ihre Umgebung.

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

    • Spec.appVaultRef: (required) Stellen Sie sicher, dass dieser Wert mit der appVaultRef aus der ResourceBackup CR übereinstimmt, die 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: (required) Eine Zeichenfolge, die angibt, welche Aktion der Ausführungshaken ausführen wird, vorausgesetzt, dass alle angegebenen Ausführungshaken-Filter übereinstimmen. Mögliche Werte:

      • Snapshot

      • Backup

      • Wiederherstellen

      • Failover

    • Spec.Stage: (required) Eine Zeichenfolge, die angibt, welche Phase während der Aktion der Ausführungshaken ausgeführt werden soll. Bei diesem Hakenlauf werden keine Haken in einer anderen Phase ausgeführt. 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 richtigen Werten ausgefüllt haben, wenden Sie den CR an:

    kubectl apply -f trident-protect-hook-run.yaml
Verwenden Sie die CLI
Schritte
  1. Erstellen Sie die Anforderung zur manuellen Ausführung von Hook Run:

    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-Hook-Durchlaufs. Sie können diesen Befehl wiederholt ausführen, bis der Vorgang abgeschlossen ist:

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

    kubectl -n <my_app_namespace> describe exechooksrun <my_exec_hook_run_name>