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

Datenschutz für Container-Apps in der OpenShift Container Platform mit Trident Protect

Beitragende kevin-hoke
PDFs

Dieser Abschnitt des Referenzdokuments enthält Details zum Erstellen von Snapshots und Backups von Container-Apps mit Trident Protect. NetApp Trident Protect bietet erweiterte Funktionen zur Anwendungsdatenverwaltung, die die Funktionalität und Verfügbarkeit von Stateful-Kubernetes-Anwendungen verbessern, die von NetApp ONTAP Speichersystemen und dem NetApp Trident CSI-Speicherbereitsteller unterstützt werden. Trident Protect erstellt Anwendungs-Snapshots und -Backups. Dies bedeutet, dass nicht nur Snapshots und Backups von Anwendungsdaten in persistenten Volumes erstellt werden, sondern auch Snapshots und Backups von Anwendungsmetadaten. Die von Trident Protect erstellten Snapshots und Backups können in jedem der folgenden Objektspeicher gespeichert und zu einem späteren Zeitpunkt von dort wiederhergestellt werden.

  • AWS S3

  • Azure Blob-Speicher

  • Google Cloud-Speicher

  • Ontap S3

  • StorageGrid

  • jeder andere S3-kompatible Speicher

Trident Protect verwendet das Kubernetes-Modell der rollenbasierten Zugriffskontrolle (RBAC). Standardmäßig stellt Trident Protect einen einzelnen Systemnamespace namens „Trident-Protect“ und das zugehörige Standarddienstkonto bereit. Wenn Ihre Organisation viele Benutzer oder spezielle Sicherheitsanforderungen hat, können Sie die RBAC-Funktionen von Trident Protect nutzen, um eine genauere Kontrolle über den Zugriff auf Ressourcen und Namespaces zu erhalten.

Weitere Informationen zu RBAC in Trident Protect finden Sie im"Trident Protect-Dokumentation"

Hinweis Der Clusteradministrator hat Zugriff auf Ressourcen im Standard-Trident-Protect-Namespace und kann auch auf Ressourcen in allen anderen Namespaces zugreifen. Benutzer können im Trident-Protect-Namespace keine benutzerdefinierten Ressourcen (CRs) für die Anwendungsdatenverwaltung wie Snapshot- und Backup-CRs erstellen. Als bewährte Methode müssen Benutzer diese CRs im Anwendungsnamespace erstellen.

Trident Protect kann gemäß den Anweisungen in der Dokumentation installiert werden"hier," In diesem Abschnitt wird der Workflow für den Datenschutz von Containeranwendungen und die Wiederherstellung der Anwendungen mit Trident Protect gezeigt. 1. Snapshot-Erstellung (auf Anfrage und nach Zeitplan) 2. Wiederherstellen aus Snapshot (Wiederherstellung im gleichen und anderen Namespace) 3. Backup-Erstellung 4. Wiederherstellen aus einer Sicherung

Voraussetzung

Bevor die Snapshots und Backups für eine Anwendung erstellt werden, muss in Trident Protect ein Objektspeicher konfiguriert werden, um die Snapshots und Backups zu speichern. Dies geschieht mithilfe des Bucket CR. Nur Administratoren können einen Bucket CR erstellen und konfigurieren. Der Bucket CR ist in Trident Protect als AppVault bekannt. AppVault-Objekte sind die deklarative Kubernetes-Workflow-Darstellung eines Speicher-Buckets. Ein AppVault CR enthält die Konfigurationen, die für die Verwendung eines Buckets in Schutzvorgängen wie Backups, Snapshots, Wiederherstellungsvorgängen und SnapMirror Replikation erforderlich sind.

In diesem Beispiel zeigen wir die Verwendung von ONTAP S3 als Objektspeicher. Hier ist der Workflow zum Erstellen von AppVault CR für ONTAP S3: 1. Erstellen Sie einen S3-Objektspeicherserver in der SVM im ONTAP -Cluster. 2. Erstellen Sie einen Bucket im Object Store Server. 3. Erstellen Sie einen S3-Benutzer in der SVM. Bewahren Sie den Zugangsschlüssel und den geheimen Schlüssel an einem sicheren Ort auf. 4. Erstellen Sie in OpenShift ein Geheimnis zum Speichern der ONTAP S3-Anmeldeinformationen. 5. Erstellen eines AppVault-Objekts für ONTAP S3

Konfigurieren Sie Trident Protect AppVault für ONTAP S3

Beispiel-YAML-Datei zum Konfigurieren von Trident Protect mit ONTAP S3 als AppVault

# alias tp='tridentctl-protect'

appvault-secret.yaml

apiVersion: v1
stringData:
  accessKeyID: "<access key id created for a user to access ONTAP S3 bucket>"
  secretAccessKey: "corresponding Secret Access Key"
#data:
# base 64 encoded values
#  accessKeyID: <base64 access key id created for a user to access ONTAP S3 bucket>
#  secretAccessKey: <base 64  Secret Access Key>
kind: Secret
metadata:
  name: appvault-secret
  namespace: trident-protect
type: Opaque

appvault.yaml

apiVersion: protect.trident.netapp.io/v1
kind: AppVault
metadata:
  name: ontap-s3-appvault
  namespace: trident-protect
spec:
  providerConfig:
    azure:
      accountName: ""
      bucketName: ""
      endpoint: ""
    gcp:
      bucketName: ""
      projectID: ""
    s3:
      bucketName: <bucket-name for storing the snapshots and backups>
      endpoint: <endpoint IP for S3>
      secure: "false"
      skipCertValidation: "true"
  providerCredentials:
    accessKeyID:
      valueFromSecret:
        key: accessKeyID
        name: appvault-secret
    secretAccessKey:
      valueFromSecret:
        key: secretAccessKey
        name: appvault-secret
  providerType: OntapS3

# oc create -f appvault-secret.yaml -n trident-protect
# oc create -f appvault.yaml -n trident-protect

AppVault erstellt

Beispiel-YAML-Datei zum Installieren der PostgreSQL-App 

postgres.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: postgres
spec:
  replicas: 1
  selector:
    matchLabels:
      app: postgres
  template:
    metadata:
      labels:
        app: postgres
    spec:
      containers:
      - name: postgres
        image: postgres:14
        env:
        - name: POSTGRES_USER
          #value: "myuser"
          value: "admin"
        - name: POSTGRES_PASSWORD
          #value: "mypassword"
          value: "adminpass"
        - name: POSTGRES_DB
          value: "mydb"
        - name: PGDATA
          value: "/var/lib/postgresql/data/pgdata"
        ports:
        - containerPort: 5432
        volumeMounts:
        - name: postgres-storage
          mountPath: /var/lib/postgresql/data
      volumes:
      - name: postgres-storage
        persistentVolumeClaim:
          claimName: postgres-pvc
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: postgres-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
---
apiVersion: v1
kind: Service
metadata:
  name: postgres
spec:
  selector:
    app: postgres
  ports:
  - protocol: TCP
    port: 5432
    targetPort: 5432
  type: ClusterIP

Now create the Trident protect application CR for the postgres app. Include the objects in the namespace postgres and create it in the postgres namespace.
# tp create app postgres-app --namespaces postgres -n postgres

App erstellt

Snapshots erstellen

Erstellen eines On-Demand-Snapshots

# tp create snapshot postgres-snap1 --app postgres-app --appvault ontap-s3-appvault -n postgres
Snapshot "postgres-snap1" created.

Snapshot erstellt

Snapshot-PVC erstellt

Erstellen eines Zeitplans Mit dem folgenden Befehl werden täglich um 15:33 Uhr Snapshots erstellt und zwei Snapshots und Backups aufbewahrt.

# tp create schedule schedule1 --app postgres-app --appvault ontap-s3-appvault --backup-retention 2 --snapshot-retention 2 --granularity Daily --hour 15 --minute 33 --data-mover Restic -n postgres
Schedule "schedule1" created.

Zeitplan1 erstellt

Erstellen eines Zeitplans mit YAML

# tp create schedule schedule2 --app postgres-app --appvault ontap-s3-appvault --backup-retention 2 --snapshot-retention 2 --granularity Daily --hour 15 --minute 33 --data-mover Restic -n postgres --dry-run > hourly-snapshotschedule.yaml

cat hourly-snapshotschedule.yaml

apiVersion: protect.trident.netapp.io/v1
kind: Schedule
metadata:
  creationTimestamp: null
  name: schedule2
  namespace: postgres
spec:
  appVaultRef: ontap-s3-appvault
  applicationRef: postgres-app
  backupRetention: "2"
  dataMover: Restic
  dayOfMonth: ""
  dayOfWeek: ""
  enabled: true
  granularity: Hourly
  #hour: "15"
  minute: "33"
  recurrenceRule: ""
  snapshotRetention: "2"
status: {}

Zeitplan2 erstellt

Sie können die nach diesem Zeitplan erstellten Snapshots sehen.

Snap planmäßig erstellt

Außerdem werden Volume-Snapshots erstellt.

PVC Snap termingerecht erstellt

Löschen Sie die Anwendung, um den Verlust der Anwendung zu simulieren 
# oc delete deployment/postgres -n postgres
# oc get pod,pvc -n postgres
No resources found in postgres namespace.
Wiederherstellen aus Snapshot im selben Namespace 
# tp create sir postgres-sir --snapshot postgres/hourly-3f1ee-20250214183300 -n postgres
SnapshotInplaceRestore "postgres-sir" created.

Herr erstellt

Die Anwendung und ihr PVC werden im selben Namespace wiederhergestellt.

App wiederhergestellt, Sir

Wiederherstellen aus Snapshot in einem anderen Namespace 
# tp create snapshotrestore postgres-restore --snapshot postgres/hourly-3f1ee-20250214183300 --namespace-mapping postgres:postgres-restore -n postgres-restore
SnapshotRestore "postgres-restore" created.

SnapRestore erstellt

Sie können sehen, dass die Anwendung in einem neuen Namespace wiederhergestellt wurde.

App wiederhergestellt, SnapRestore

Backups erstellen

Erstellen eines On-Demand-Backups

# tp create backup postgres-backup1 --app postgres-app --appvault ontap-s3-appvault -n postgres
Backup "postgres-backup1" created.

Sicherung erstellt

Zeitplan für die Sicherung erstellen

Die täglichen und stündlichen Sicherungen in der obigen Liste werden anhand des zuvor eingerichteten Zeitplans erstellt.

# tp create schedule schedule1 --app postgres-app --appvault ontap-s3-appvault --backup-retention 2 --snapshot-retention 2 --granularity Daily --hour 15 --minute 33 --data-mover Restic -n postgres
Schedule "schedule1" created.

Zuvor erstellter Zeitplan

Wiederherstellen aus einer Sicherung

Löschen Sie die Anwendung und PVCs, um einen Datenverlust zu simulieren.

Zuvor erstellter Zeitplan

Im selben Namespace wiederherstellen #tp create bir postgres-bir --backup postgres/hourly-3f1ee-20250224023300 -n postgres BackupInplaceRestore „postgres-bir“ erstellt.

Wiederherstellung im selben Namespace

Die Anwendung und die PVCs werden im selben Namespace wiederhergestellt.

Anwendung und PVCs werden im selben Namespace wiederhergestellt

In einem anderen Namespace wiederherstellen Erstellen Sie einen neuen Namespace. Stellen Sie aus einer Sicherung im neuen Namespace wieder her.

Wiederherstellung in einem anderen Namespace

Migrieren von Anwendungen

Um eine Anwendung auf einen anderen Cluster zu klonen oder zu migrieren (durchführen eines Cluster-übergreifenden Klons), erstellen Sie eine Sicherung auf dem Quellcluster und stellen Sie die Sicherung dann auf einem anderen Cluster wieder her. Stellen Sie sicher, dass Trident Protect auf dem Zielcluster installiert ist.

Führen Sie im Quellcluster die im folgenden Bild gezeigten Schritte aus:

Wiederherstellung in einem anderen Namespace

Wechseln Sie vom Quellcluster zum Zielcluster. Stellen Sie dann sicher, dass vom Zielclusterkontext aus auf den AppVault zugegriffen werden kann, und rufen Sie den AppVault-Inhalt vom Zielcluster ab.

Kontext zum Ziel wechseln

Verwenden Sie den Sicherungspfad aus der Liste und erstellen Sie ein Backuprestore-CR-Objekt, wie im folgenden Befehl gezeigt.

# tp create backuprestore backup-restore-cluster2 --namespace-mapping postgres:postgres --appvault ontap-s3-appvault --path postgres-app_4d798ed5-cfa8-49ff-a5b6-c5e2d89aeb89/backups/postgres-backup-cluster1_ec0ed3f3-5500-4e72-afa8-117a04a0b1c3 -n postgres
BackupRestore "backup-restore-cluster2" created.

Am Ziel wiederherstellen

Sie können jetzt sehen, dass die Anwendungspods und die PVCs im Zielcluster erstellt werden.

App auf dem Zielcluster