From d4e7d1472e82f283150627a74a145d6f6aea568d Mon Sep 17 00:00:00 2001 From: Shubham Pampattiwar Date: Thu, 15 Aug 2024 12:18:54 -0700 Subject: [PATCH] add docs for backup pvc config support Signed-off-by: Shubham Pampattiwar add changelog Signed-off-by: Shubham Pampattiwar add section to csi dm doc and minor fixes Signed-off-by: Shubham Pampattiwar configMap name is configurable Signed-off-by: Shubham Pampattiwar --- .../unreleased/8119-shubham-pampattiwar | 1 + .../docs/main/csi-snapshot-data-movement.md | 7 ++- .../data-movement-backup-pvc-configuration.md | 54 +++++++++++++++++++ site/data/docs/main-toc.yml | 4 +- 4 files changed, 64 insertions(+), 2 deletions(-) create mode 100644 changelogs/unreleased/8119-shubham-pampattiwar create mode 100644 site/content/docs/main/data-movement-backup-pvc-configuration.md diff --git a/changelogs/unreleased/8119-shubham-pampattiwar b/changelogs/unreleased/8119-shubham-pampattiwar new file mode 100644 index 000000000..48b4c0b09 --- /dev/null +++ b/changelogs/unreleased/8119-shubham-pampattiwar @@ -0,0 +1 @@ +Add docs for backup pvc config support diff --git a/site/content/docs/main/csi-snapshot-data-movement.md b/site/content/docs/main/csi-snapshot-data-movement.md index 60d72aecf..31419e3ee 100644 --- a/site/content/docs/main/csi-snapshot-data-movement.md +++ b/site/content/docs/main/csi-snapshot-data-movement.md @@ -491,8 +491,11 @@ For Velero built-in data mover, it uses Kubernetes' scheduler to mount a snapsho For the backup, you can intervene this scheduling process through [Data Movement Backup Node Selection][15], so that you can decide which node(s) should/should not run the data movement backup for various purposes. For the restore, this is not supported because sometimes the data movement restore must run in the same node where the restored workload pod is scheduled. +### BackupPVC Configuration - +The `BackupPVC` serves as an intermediate Persistent Volume Claim (PVC) utilized during data movement backup operations, providing efficient access to data. +In complex storage environments, optimizing `BackupPVC` configurations can significantly enhance the performance of backup operations. [This document][16] outlines +advanced configuration options for `BackupPVC`, allowing users to fine-tune access modes and storage class settings based on their storage provider's capabilities. [1]: https://github.com/vmware-tanzu/velero/pull/5968 [2]: csi.md @@ -509,3 +512,5 @@ For the restore, this is not supported because sometimes the data movement resto [13]: https://kubernetes.io/docs/concepts/workloads/pods/pod-qos/ [14]: node-agent-concurrency.md [15]: data-movement-backup-node-selection.md +[16]: data-movement-backup-pvc-configuration.md + diff --git a/site/content/docs/main/data-movement-backup-pvc-configuration.md b/site/content/docs/main/data-movement-backup-pvc-configuration.md new file mode 100644 index 000000000..61bbf53e1 --- /dev/null +++ b/site/content/docs/main/data-movement-backup-pvc-configuration.md @@ -0,0 +1,54 @@ +--- +title: "BackupPVC Configuration for Data Movement Backup" +layout: docs +--- + +`BackupPVC` is an intermediate PVC to access data from during the data movement backup operation. + +In some scenarios users may need to configure some advanced options of the backupPVC so that the data movement backup +operation could perform better. Specifically: +- For some storage providers, when creating a read-only volume from a snapshot, it is very fast; whereas, if a writable volume + is created from the snapshot, they need to clone the entire disk data, which is time consuming. If the `backupPVC`'s `accessModes` is + set as `ReadOnlyMany`, the volume driver is able to tell the storage to create a read-only volume, which may dramatically shorten the + snapshot expose time. On the other hand, `ReadOnlyMany` is not supported by all volumes. Therefore, users should be allowed to configure + the `accessModes` for the `backupPVC`. +- Some storage providers create one or more replicas when creating a volume, the number of replicas is defined in the storage class. + However, it doesn't make any sense to keep replicas when an intermediate volume used by the backup. Therefore, users should be allowed + to configure another storage class specifically used by the `backupPVC`. + +Velero introduces a new section in the node agent configuration configMap (the name of this configMap is passed using `--node-agent-config` velero server argument) +called `backupPVC`, through which you can specify the following +configurations: + +- `storageClass`: This specifies the storage class to be used for the backupPVC. If this value does not exist or is empty then by +default the source PVC's storage class will be used. + +- `readOnly`: This is a boolean value. If set to `true` then `ReadOnlyMany` will be the only value set to the backupPVC's access modes. Otherwise +`ReadWriteOnce` value will be used. + +A sample of `backupPVC` config as part of the configMap would look like: +```json +{ + "backupPVC": { + "storage-class-1": { + "storageClass": "backupPVC-storage-class", + "readOnly": true + }, + "storage-class-2": { + "storageClass": "backupPVC-storage-class" + }, + "storage-class-3": { + "readOnly": true + } + } +} +``` + +**Note:** +- Users should make sure that the storage class specified in `backupPVC` config should exist in the cluster and can be used by the +`backupPVC`, otherwise the corresponding DataUpload CR will stay in `Accepted` phase until timeout (data movement prepare timeout value is 30m by default). +- If the users are setting `readOnly` value as `true` in the `backupPVC` config then they must also make sure that the storage class that is being used for +`backupPVC` should support creation of `ReadOnlyMany` PVC from a snapshot, otherwise the corresponding DataUpload CR will stay in `Accepted` phase until +timeout (data movement prepare timeout value is 30m by default). +- If any of the above problems occur, then the DataUpload CR is `canceled` after timeout, and the backupPod and backupPVC will be deleted, and the backup +will be marked as `PartiallyFailed`. diff --git a/site/data/docs/main-toc.yml b/site/data/docs/main-toc.yml index cab546823..ec5f04604 100644 --- a/site/data/docs/main-toc.yml +++ b/site/data/docs/main-toc.yml @@ -52,7 +52,9 @@ toc: - page: CSI Snapshot Data Movement url: /csi-snapshot-data-movement - page: Node-agent Concurrency - url: /node-agent-concurrency + url: /node-agent-concurrency + - page: Backup PVC Configuration + url: /data-movement-backup-pvc-configuration - page: Verifying Self-signed Certificates url: /self-signed-certificates - page: Changing RBAC permissions