Datensicherung für VMs in OpenShift-Virtualisierung mit Trident Protect
Änderungen vorschlagen
PDFs
Dieser Abschnitt des Referenzdokuments enthält Details zum Erstellen von Snapshots und Backups von VMs mithilfe von Trident Protect.
Virtuelle Maschinen in der OpenShift-Virtualisierungsumgebung sind Container-Anwendungen, die in den Workerknoten der OpenShift-Container-Plattform ausgeführt werden. Es ist wichtig, die VM-Metadaten sowie die persistenten Festplatten der VMs zu schützen, damit Sie sie bei Verlust oder Beschädigung wiederherstellen können.
Die persistenten Festplatten der OpenShift-Virtualisierungs-VMs können mithilfe von ONTAP-Speicher gesichert werden, der in den OpenShift-Cluster integriert "Trident-CSI"ist. In diesem Abschnitt werden "Trident Protect"Snapshots und Backups von VMs einschließlich der Daten-Volumes im ONTAP-Objektspeicher erstellt.
Bei Bedarf führen wir dann Restores von einem Snapshot oder einem Backup durch.
Trident Protect ermöglicht Snapshots, Backups, Restores und Disaster Recovery von Applikationen und VMs auf einem OpenShift-Cluster. Für OpenShift-Virtualisierungs-VMs umfassen Daten, die mit Trident Protect gesichert werden können, Kubernetes-Ressourcenobjekte, die den VMs zugeordnet sind, persistente Volumes und interne Images.
Im Folgenden sind die Versionen der verschiedenen Komponenten, die für die Beispiele in diesem Abschnitt verwendet werden
App Vault für Objektspeicher erstellen
Erstellen Sie AppVault
Bevor Snapshots und Backups für eine Applikation oder eine VM erstellt werden, muss ein Objektspeicher in Trident Protect konfiguriert werden, um die Snapshots und Backups zu speichern. Dies geschieht mit dem Bucket CR. Nur Administratoren können einen Bucket CR erstellen und konfigurieren. Der Bucket CR wird in Trident Protect als AppVault bezeichnet. AppVault-Objekte sind die deklarative Kubernetes-Workflow-Darstellung eines Storage-Buckets. Ein AppVault CR enthält die Konfigurationen, die für einen Bucket erforderlich sind, der für Schutzvorgänge verwendet werden kann, z. B. Backups, Snapshots, Wiederherstellungsvorgänge und SnapMirror-Replikation.
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. S3-Objektspeicher-Server in der SVM im ONTAP-Cluster erstellen. 2. Erstellen Sie einen Bucket im Object Store Server. 3. Erstellen eines S3-Benutzers in der SVM Bewahren Sie den Zugriffsschlüssel und den geheimen Schlüssel an einem sicheren Ort auf. 4. Erstellen Sie in OpenShift einen Schlüssel, um die ONTAP S3-Anmeldedaten zu speichern. 5. Erstellen Sie ein AppVault-Objekt für ONTAP S3
Trident Protect AppVault für ONTAP S3 konfigurieren
# alias tp='tridentctl-protect'
# cat appvault-secret.yaml
apiVersion: v1
stringData:
accessKeyID: "<access key of S3>"
secretAccessKey: "<secret access key of S3>"
# you can also provide base 64 encoded values instead of string values
#data:
# base 64 encoded values
# accessKeyID: < base 64 encoded access key>
# secretAccessKey: <base 64 encoded secretAccess key>
kind: Secret
metadata:
name: appvault-secret
namespace: trident-protect
type: Opaque
# cat 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: trident-protect
endpoint: <lif for S3 access>
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
Erstellen Sie eine VM in OpenShift Virtualization
Erstellen Sie eine VM in OpenShift Virtualization
Die folgenden Screenshots zeigen die Erstellung der VM (Demo-Fedora in Namespace Demo) aus der Konsole mit der Vorlage. Die Stammfestplatte wählt automatisch die Standardspeicherklasse aus. Überprüfen Sie daher, ob die Standardspeicherklasse richtig eingestellt ist. In diesem Setup ist die Standard-Storage-Klasse sc-zonea-san. Stellen Sie sicher, dass Sie beim Erstellen der zusätzlichen Festplatte die Speicherklasse sc-zonea-san auswählen und das Kontrollkästchen „optimierte Speichereinstellungen anwenden“ aktivieren. Dadurch werden die Zugriffsmodi auf RWX und Volume Mode auf Block eingestellt.
|
Trident unterstützt den RWX-Zugriffsmodus im Block-Volume-Modus für SAN (iSCSI, NVMe/TCP und FC). (Dies ist der Standardzugriffsmodus für NAS). DER RWX-Zugriffsmodus ist erforderlich, wenn Sie die Live-Migration der VMs zu einem späteren Zeitpunkt durchführen müssen. |
Erstellen Sie eine App
App Erstellen
Trident Protect App für die VM erstellen
Im Beispiel hat der Demo-Namespace eine VM und alle Ressourcen des Namespace sind beim Erstellen der App enthalten.
# alias tp='tridentctl-protect'
# tp create app demo-vm --namespaces demo -n demo --dry-run > app.yaml
# cat app.yaml
apiVersion: protect.trident.netapp.io/v1
kind: Application
metadata:
creationTimestamp: null
name: demo-vm
namespace: demo
spec:
includedNamespaces:
- namespace: demo
# oc create -f app.yaml -n demo
Schützen Sie die App, indem Sie ein Backup erstellen
Backups Erstellen
Erstellen Sie ein On-Demand Backup
Erstellen Sie ein Backup für die zuvor erstellte App (Demo-vm), die alle Ressourcen im Demo-Namespace umfasst. Geben Sie den AppVault-Namen an, unter dem die Backups gespeichert werden sollen.
# tp create backup demo-vm-backup-on-demand --app demo-vm --appvault ontap-s3-appvault -n demo
Backup "demo-vm-backup-on-demand" created.
Backups nach Zeitplan erstellen
Erstellen Sie einen Zeitplan für die Backups, um die Granularität und die Anzahl der beizubehaltenden Backups anzugeben.
# tp create schedule backup-schedule1 --app demo-vm --appvault ontap-s3-appvault --granularity Hourly --minute 45 --backup-retention 1 -n demo --dry-run>backup-schedule-demo-vm.yaml
schedule.protect.trident.netapp.io/backup-schedule1 created
#cat backup-schedule-demo-vm.yaml
apiVersion: protect.trident.netapp.io/v1
kind: Schedule
metadata:
creationTimestamp: null
name: backup-schedule1
namespace: demo
spec:
appVaultRef: ontap-s3-appvault
applicationRef: demo-vm
backupRetention: "1"
dayOfMonth: ""
dayOfWeek: ""
enabled: true
granularity: Hourly
hour: ""
minute: "45"
recurrenceRule: ""
snapshotRetention: "0"
status: {}
# oc create -f backup-schedule-demo-vm.yaml -n demo
Aus Backup wiederherstellen
Wiederherstellung aus Backups
Wiederherstellung der VM auf den gleichen Namespace
Im Beispiel enthält die Backup-Demo-vm-Backup-on-Demand das Backup mit der Demo-App für die Fedora VM.
Löschen Sie zunächst die VM und stellen Sie sicher, dass die PVCs, der Pod und die VM-Objekte aus der Namespace „Demo“ gelöscht werden.
Erstellen Sie nun ein Backup-in-Place-Wiederherstellungsobjekt.
# tp create bir demo-fedora-restore --backup demo/demo-vm-backup-on-demand -n demo --dry-run>vm-demo-bir.yaml
# cat vm-demo-bir.yaml
apiVersion: protect.trident.netapp.io/v1
kind: BackupInplaceRestore
metadata:
annotations:
protect.trident.netapp.io/max-parallel-restore-jobs: "25"
creationTimestamp: null
name: demo-fedora-restore
namespace: demo
spec:
appArchivePath: demo-vm_cc8adc7a-0c28-460b-a32f-0a7b3d353e13/backups/demo-vm-backup-on-demand_f6af3513-9739-480e-88c7-4cca45808a80
appVaultRef: ontap-s3-appvault
resourceFilter: {}
status:
postRestoreExecHooksRunResults: null
state: ""
# oc create -f vm-demo-bir.yaml -n demo
backupinplacerestore.protect.trident.netapp.io/demo-fedora-restore created
Überprüfen Sie, ob VM, Pods und PVCs wiederhergestellt sind
Wiederherstellung der VM auf einen anderen Namespace
Erstellen Sie zunächst einen neuen Namespace, in dem Sie die App wiederherstellen möchten, in diesem Beispiel demo2. Erstellen Sie anschließend ein Backup Restore-Objekt
# tp create br demo2-fedora-restore --backup demo/hourly-4c094-20250312154500 --namespace-mapping demo:demo2 -n demo2 --dry-run>vm-demo2-br.yaml
# cat vm-demo2-br.yaml
apiVersion: protect.trident.netapp.io/v1
kind: BackupRestore
metadata:
annotations:
protect.trident.netapp.io/max-parallel-restore-jobs: "25"
creationTimestamp: null
name: demo2-fedora-restore
namespace: demo2
spec:
appArchivePath: demo-vm_cc8adc7a-0c28-460b-a32f-0a7b3d353e13/backups/hourly-4c094-20250312154500_aaa14543-a3fa-41f1-a04c-44b1664d0f81
appVaultRef: ontap-s3-appvault
namespaceMapping:
- destination: demo2
source: demo
resourceFilter: {}
status:
conditions: null
postRestoreExecHooksRunResults: null
state: ""
# oc create -f vm-demo2-br.yaml -n demo2
Vergewissern Sie sich, dass VM, Pods und pvcs in der neuen Namespace-Demo2 erstellt wurden.
Schützen Sie die App mithilfe von Snapshots
Erstellen Sie Snapshots
Erstellen Sie einen On-Demand-Snapshot Erstellen Sie einen Snapshot für die App und geben Sie den Appvault an, wo er gespeichert werden soll.
# tp create snapshot demo-vm-snapshot-ondemand --app demo-vm --appvault ontap-s3-appvault -n demo --dry-run
# cat demo-vm-snapshot-on-demand.yaml
apiVersion: protect.trident.netapp.io/v1
kind: Snapshot
metadata:
creationTimestamp: null
name: demo-vm-snapshot-ondemand
namespace: demo
spec:
appVaultRef: ontap-s3-appvault
applicationRef: demo-vm
completionTimeout: 0s
volumeSnapshotsCreatedTimeout: 0s
volumeSnapshotsReadyToUseTimeout: 0s
status:
conditions: null
postSnapshotExecHooksRunResults: null
preSnapshotExecHooksRunResults: null
state: ""
# oc create -f demo-vm-snapshot-on-demand.yaml
snapshot.protect.trident.netapp.io/demo-vm-snapshot-ondemand created
Erstellen Sie einen Zeitplan für Snapshots Erstellen Sie einen Zeitplan für die Snapshots. Geben Sie die Granularität und die Anzahl der beibehaltenen Snapshots an.
# tp create Schedule snapshot-schedule1 --app demo-vm --appvault ontap-s3-appvault --granularity Hourly --minute 50 --snapshot-retention 1 -n demo --dry-run>snapshot-schedule-demo-vm.yaml
# cat snapshot-schedule-demo-vm.yaml
apiVersion: protect.trident.netapp.io/v1
kind: Schedule
metadata:
creationTimestamp: null
name: snapshot-schedule1
namespace: demo
spec:
appVaultRef: ontap-s3-appvault
applicationRef: demo-vm
backupRetention: "0"
dayOfMonth: ""
dayOfWeek: ""
enabled: true
granularity: Hourly
hour: ""
minute: "50"
recurrenceRule: ""
snapshotRetention: "1"
status: {}
# oc create -f snapshot-schedule-demo-vm.yaml
schedule.protect.trident.netapp.io/snapshot-schedule1 created
Wiederherstellung aus Snapshot
Wiederherstellung aus Snapshot
VM aus dem Snapshot in den gleichen Namespace wiederherstellen Löschen Sie die VM Demo-Fedora aus dem Namespace demo2.
Erstellen Sie ein Snapshot-in-Place-Restore-Objekt aus dem Snapshot der VM.
# tp create sir demo-fedora-restore-from-snapshot --snapshot demo/demo-vm-snapshot-ondemand -n demo --dry-run>vm-demo-sir.yaml
# cat vm-demo-sir.yaml
apiVersion: protect.trident.netapp.io/v1
kind: SnapshotInplaceRestore
metadata:
creationTimestamp: null
name: demo-fedora-restore-from-snapshot
namespace: demo
spec:
appArchivePath: demo-vm_cc8adc7a-0c28-460b-a32f-0a7b3d353e13/snapshots/20250318132959_demo-vm-snapshot-ondemand_e3025972-30c0-4940-828a-47c276d7b034
appVaultRef: ontap-s3-appvault
resourceFilter: {}
status:
conditions: null
postRestoreExecHooksRunResults: null
state: ""
# oc create -f vm-demo-sir.yaml
snapshotinplacerestore.protect.trident.netapp.io/demo-fedora-restore-from-snapshot created
Vergewissern Sie sich, dass die VM und ihre PVCs im Demo-Namespace erstellt sind.
Wiederherstellen der VM vom Snapshot auf einen anderen Namespace
Löschen Sie die VM im zuvor aus dem Backup wiederhergestellten Namespace demo2.
Erstellen Sie das Objekt zur Snapshot-Wiederherstellung aus dem Snapshot und stellen Sie die Namespace-Zuordnung bereit.
# tp create sr demo2-fedora-restore-from-snapshot --snapshot demo/demo-vm-snapshot-ondemand --namespace-mapping demo:demo2 -n demo2 --dry-run>vm-demo2-sr.yaml
# cat vm-demo2-sr.yaml
apiVersion: protect.trident.netapp.io/v1
kind: SnapshotRestore
metadata:
creationTimestamp: null
name: demo2-fedora-restore-from-snapshot
namespace: demo2
spec:
appArchivePath: demo-vm_cc8adc7a-0c28-460b-a32f-0a7b3d353e13/snapshots/20250318132959_demo-vm-snapshot-ondemand_e3025972-30c0-4940-828a-47c276d7b034
appVaultRef: ontap-s3-appvault
namespaceMapping:
- destination: demo2
source: demo
resourceFilter: {}
status:
postRestoreExecHooksRunResults: null
state: ""
# oc create -f vm-demo2-sr.yaml
snapshotrestore.protect.trident.netapp.io/demo2-fedora-restore-from-snapshot created
Vergewissern Sie sich, dass die VM und ihre VES in der neuen Namespace-Demo2 wiederhergestellt sind.
Stellen Sie eine spezifische VM wieder her
Auswahl spezifischer VMs in einem Namespace zur Erstellung von Snapshots/Backups und Wiederherstellung
Im vorherigen Beispiel hatten wir eine einzelne VM innerhalb eines Namespace. Durch Einbeziehung des gesamten Namespace im Backup wurden alle mit der VM verbundenen Ressourcen erfasst. Im folgenden Beispiel fügen wir dem gleichen Namespace eine weitere VM hinzu und erstellen mithilfe einer Label-Selektor eine Anwendung nur für diese neue VM.
Erstellen Sie eine neue VM (Demo-centos vm) im Demo-Namespace
Label die Demo-centos vm und die damit verbundenen Ressourcen
Vergewissern Sie sich, dass die Demo-centos vm und ves die Labels erhalten haben
Erstellen Sie eine App nur für eine bestimmte VM (Demo-centos) mit dem Label Selector
# tp create app demo-centos-app --namespaces 'demo(category=protect-demo-centos)' -n demo --dry-run>demo-centos-app.yaml
# cat demo-centos-app.yaml
apiVersion: protect.trident.netapp.io/v1
kind: Application
metadata:
creationTimestamp: null
name: demo-centos-app
namespace: demo
spec:
includedNamespaces:
- labelSelector:
matchLabels:
category: protect-demo-centos
namespace: demo
status:
conditions: null
# oc create -f demo-centos-app.yaml -n demo
application.protect.trident.netapp.io/demo-centos-app created
Die Methode zum Erstellen von Backups und Snapshots nach Bedarf und nach einem Zeitplan ist die gleiche wie zuvor gezeigt. Da die Trident-Protect-App, die zur Erstellung der Snapshots oder Backups verwendet wird, nur die bestimmte VM aus dem Namespace enthält, stellt die Wiederherstellung von ihnen nur eine bestimmte VM wieder her. Ein Beispiel für einen Backup-/Wiederherstellungsvorgang ist unten als Beispiel dargestellt.
Erstellen Sie ein Backup einer bestimmten VM in einem Namespace mit der entsprechenden App
In den vorherigen Schritten wurde eine App mithilfe von Label-Selektoren erstellt, um nur die centos vm im Demo-Namespace aufzunehmen. Erstellen Sie für diese App ein Backup (On-Demand-Backup, in diesem Beispiel).
# tp create backup demo-centos-backup-on-demand --app demo-centos-app --appvault ontap-s3-appvault -n demo
Backup "demo-centos-backup-on-demand" created.
Eine bestimmte VM auf den gleichen Namespace zurückstellen das Backup einer bestimmten VM (centos) wurde mit der entsprechenden App erstellt. Wenn daraus eine Backup-in-Place-Wiederherstellung oder eine Backup-Wiederherstellung erstellt wird, wird nur diese spezifische VM wiederhergestellt. Löschen Sie die CentOS VM.
Erstellen Sie eine in-Place-Backup-Wiederherstellung aus Demo-centos-Backup-on-Demand, und überprüfen Sie, ob die centos VM neu erstellt wurde.
#tp create bir demo-centos-restore --backup demo/demo-centos-backup-on-demand -n demo
BackupInplaceRestore "demo-centos-restore" created.
Eine spezifische VM auf einen anderen Namespace wiederherstellen Erstellen Sie eine Backup-Wiederherstellung in einem anderen Namespace (demo3) von Demo-centos-Backup-on-Demand und überprüfen Sie, ob die centos VM neu erstellt wurde.
# tp create br demo2-centos-restore --backup demo/demo-centos-backup-on-demand --namespace-mapping demo:demo3 -n demo3
BackupRestore "demo2-centos-restore" created.
Videovorführung
Das folgende Video zeigt eine Demonstration der Sicherung einer VM mithilfe von Snapshots