Skip to main content
NetApp public and hybrid cloud solutions
La versione in lingua italiana fornita proviene da una traduzione automatica. Per eventuali incoerenze, fare riferimento alla versione in lingua inglese.

Protezione dei dati per le app container in OpenShift Container Platform utilizzando Trident Protect

Collaboratori banum-netapp kevin-hoke
PDF

Questa sezione del documento di riferimento fornisce dettagli sulla creazione di snapshot e backup di Container Apps utilizzando Trident Protect. NetApp Trident Protect offre avanzate capacità di gestione dei dati delle applicazioni che migliorano la funzionalità e la disponibilità delle applicazioni Kubernetes stateful supportate dai sistemi di storage NetApp ONTAP e dal NetApp Trident CSI storage provisioner. Trident Protect crea snapshot e backup delle applicazioni. Ciò significa che snapshot e backup vengono creati non solo per i dati delle applicazioni nei volumi persistenti, ma anche per i metadati delle applicazioni. Gli snapshot e i backup creati da Trident Protect possono essere archiviati in uno qualsiasi dei seguenti storage a oggetti e ripristinati da essi in un secondo momento.

  • AWS S3

  • Archiviazione BLOB di Azure

  • Google Cloud Storage

  • ONTAP S3

  • StorageGrid

  • Qualsiasi altro storage compatibile con S3

Trident Protect utilizza il modello Kubernetes di controllo degli accessi in base al ruolo (RBAC). Per impostazione predefinita, Trident Protect fornisce un singolo namespace di sistema chiamato trident-protect e il relativo account di servizio predefinito. Se hai un'organizzazione con molti utenti o esigenze di sicurezza specifiche, puoi utilizzare le funzionalità RBAC di Trident Protect per ottenere un controllo più granulare sull'accesso a risorse e namespace.

Ulteriori informazioni su RBAC in Trident Protect possono essere trovate nel "Documentazione Trident Protect"

Nota L'amministratore del cluster ha accesso alle risorse nello spazio dei nomi trident-protect predefinito e può anche accedere alle risorse in tutti gli altri spazi dei nomi. Gli utenti non possono creare risorse personalizzate (CR) per la gestione dei dati delle applicazioni, come CR Snapshot e Backup, nello spazio dei nomi trident-protect. Come buona pratica, gli utenti dovranno creare tali CR nello spazio dei nomi dell'applicazione.

Trident Protect può essere installato seguendo le istruzioni fornite nella documentazione "Qui". Questa sezione mostrerà il flusso di lavoro per la protezione dei dati delle applicazioni container e il ripristino delle applicazioni utilizzando Trident Protect. 1. Creazione di Snapshot (su richiesta o pianificata) 2. Ripristino da Snapshot (ripristino nello stesso namespace o in uno diverso) 3. Creazione di backup 4. Ripristino da backup

Prerequisito

Prima di creare le snapshot e i backup per un'applicazione, lo storage a oggetti deve essere configurato in Trident Protect per archiviare le snapshot e i backup. Questo viene fatto utilizzando il bucket CR. Solo gli amministratori possono creare un bucket CR e configurarlo. Il bucket CR è noto come AppVault in Trident Protect. Gli oggetti AppVault sono la rappresentazione dichiarativa del workflow Kubernetes di un bucket di storage. Un CR AppVault contiene le configurazioni necessarie affinché un bucket possa essere utilizzato nelle operazioni di protezione, come backup, snapshot, operazioni di ripristino e replica SnapMirror.

In questo esempio, mostreremo l'utilizzo di ONTAP S3 come storage a oggetti. Ecco il flusso di lavoro per la creazione di AppVault CR per ONTAP S3: 1. Creare un server di archivio di oggetti S3 nella SVM nel cluster ONTAP. 2. Creare un bucket nel server di archivio di oggetti. 3. Creare un utente S3 nella SVM. Conservare la access key e la secret key in un luogo sicuro. 4. In OpenShift, creare un secret per archiviare le credenziali ONTAP S3. 5. Creare un oggetto AppVault per ONTAP S3

Configura Trident Protect AppVault per ONTAP S3

Esempio di file YAML per la configurazione di Trident Protect con ONTAP S3 come 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 creato

Esempio di file yaml per l'installazione dell'app PostgreSQL 

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 creata

Crea snapshot

Creazione di uno snapshot on-demand

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

Istantanea creata

snapshot-pvc creato

Creazione di una pianificazione Utilizzando il seguente comando, gli snapshot verranno creati ogni giorno alle 15:33 e verranno conservati due snapshot e due backup.

# 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.

Schedule1 creato

Creazione di una pianificazione tramite 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: {}

Schedule2 creato

È possibile visualizzare gli snapshot creati in base a questa pianificazione.

Snap creato nei tempi previsti

Vengono creati anche snapshot del volume.

PVC Snap creato nei tempi previsti

Elimina l'applicazione per simulare la perdita dell'applicazione 
# oc delete deployment/postgres -n postgres
# oc get pod,pvc -n postgres
No resources found in postgres namespace.
Ripristina da Snapshot allo stesso namespace 
# tp create sir postgres-sir --snapshot postgres/hourly-3f1ee-20250214183300 -n postgres
SnapshotInplaceRestore "postgres-sir" created.

Signore creato

L'applicazione e il suo PVC vengono ripristinati nello stesso namespace.

App ripristinata, signore

Ripristina da Snapshot a uno spazio dei nomi diverso 
# tp create snapshotrestore postgres-restore --snapshot postgres/hourly-3f1ee-20250214183300 --namespace-mapping postgres:postgres-restore -n postgres-restore
SnapshotRestore "postgres-restore" created.

snapRestore creato

Puoi vedere che l'applicazione è stata ripristinata in un nuovo namespace.

App ripristinata, snapRestore

Crea backup

Creazione di un backup su richiesta

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

Backup creato

Creazione di una pianificazione per il backup

I backup giornalieri e orari nell'elenco sopra vengono creati in base alla pianificazione impostata in precedenza.

# 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.

Programma creato in precedenza

Ripristina dal backup

Eliminare l'applicazione e i PVC per simulare una perdita di dati.

Programma creato in precedenza

Ripristina nello stesso namespace #tp create bir postgres-bir --backup postgres/hourly-3f1ee-20250224023300 -n postgres BackupInplaceRestore "postgres-bir" creato.

ripristinare nello stesso namespace

L'applicazione e i PVC vengono ripristinati nello stesso namespace.

applicazio e pvcs ripristinano lo stesso namespace

Ripristina in uno spazio dei nomi diverso Crea un nuovo spazio dei nomi. Ripristina da un backup al nuovo namespace.

ripristinare in uno spazio dei nomi diverso

Migrazione delle applicazioni

Per clonare o migrare un'applicazione su un cluster diverso (eseguire un clone tra cluster), crea un backup sul cluster di origine e poi ripristina il backup su un cluster di destinazione. Assicurarsi che Trident Protect sia installato sul cluster di destinazione.

Sul cluster di origine, eseguire i passaggi mostrati nell'immagine seguente:

ripristinare in uno spazio dei nomi diverso

Dal cluster di origine, cambia contesto al cluster di destinazione. Quindi, assicurati che AppVault sia accessibile dal contesto del cluster di destinazione e ottieni i contenuti di AppVault dal cluster di destinazione.

cambia contesto alla destinazione

Utilizzare il percorso di backup dall'elenco e creare un oggetto CR backuprestore come mostrato nel comando seguente.

# 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.

ripristinare alla destinazione

Ora puoi vedere che i pod dell'applicazione e i pvc sono stati creati nel cluster di destinazione.

app sul cluster di destinazione