尧图网站建设 
Velero 文件系统备份性能指南Kopia 上传器在不同数据形态下的资源消耗与调优实践【免费下载链接】veleroBackup and migrate Kubernetes applications and their persistent volumes项目地址: https://gitcode.com/GitHub_Trending/ve/velero导读本指南以 Velero 官方文档 performance-guidance.md 为基础结合当前仓库源码系统讲解 Velero 文件系统备份File System BackupFS Backup在 Kopia 上传器路径下的性能表现通过 6 组覆盖海量小文件、中小文件量、大体积数据、超大文件等典型数据形态的基准测试量化时间消耗、CPU、内存与存储库占用并给出资源配额配置建议。读完本文你将掌握 Kopia 上传器的性能特征、OOM/超时的成因边界以及如何通过velero install的资源参数为 node-agent 设置合理配额避免大规模备份时的默认配置陷阱。背景FS Backup 与 Kopia 上传器Velero 对 Pod 卷Pod Volume的备份主要分为快照Snapshot与文件系统备份FS Backup两条路径。FS Backup 通过 node-agent 以 DaemonSet 形式在集群各节点上运行读取卷内文件系统数据并上传到对象存储。当前仓库中上传器的类型定义在 pkg/uploader/types.gokopiaKopiaType是当前唯一支持的文件系统上传器类型BlockType对应的velero-block用于块设备数据移动不属于本指南讨论范围。在安装阶段可通过--uploader-type显式指定上传器默认即为kopia见 pkg/cmd/cli/install/install.go同时--default-volumes-to-fs-backup可以配置 Velero 服务器在全部备份中默认对卷启用文件系统备份。执行备份时--parallel-files-upload仅对 Kopia 上传器生效可控制同时上传的文件数量见 pkg/cmd/cli/backup/create.go。本指南的核心命题是Kopia 上传器的性能会随数据形态data shape和资源配置resource settings而显著变化。官方文档基于多轮实测给出参考性结论但因基础设施差异与数据场景覆盖有限所有结果仅供参考不能直接外推为生产环境的绝对性能承诺。测试基础设施测试环境以 Minio 作为 Velero 后端对象存储NFS 用于创建承载数据的 PV/PVCMinio 与 NFS 服务器分别部署在不同虚拟机中写吞吐约 300 MB/s、读吞吐约 175 MB/s。完整环境信息如下原文照录### KUBERNETES VERSION Client Version: version.Info{Major:1, Minor:22, GitVersion:v1.22.4 Server Version: version.Info{Major:1, Minor:21, GitVersion:v1.21.14 ### DOCKER VERSION Client: Version: 20.10.12 API version: 1.41 Server: Engine: Version: 20.10.12 API version: 1.41 (minimum version 1.12) Go version: go1.16.2 containerd: Version: 1.5.9-0ubuntu1~20.04.4 runc: Version: 1.1.0-0ubuntu1~20.04.1 docker-init: Version: 0.19.0 ### NODES 6 // one master with 6 work nodes ### DISK INFO Vendor: VMware Product: Virtual disk Rotation Rate: Solid State Device Logical block size: 512 bytes ### MEMORY INFO total: 3.8Gi available: 3.3Gi (Swap: 0B) ### CPU INFO 4 Intel(R) Xeon(R) Gold 6230R CPU 2.10GHz ### SYSTEM INFO Linux version 5.4.0-126-generic (Ubuntu 20.04) ### VELERO VERSION Client: Version: main ###v1.10 pre-release version Server: Version: main ###v1.10 pre-release version测试方法要点共执行 6 组测试每组使用受限资源1 核 CPU 2 GB 内存或4 核 CPU 4 GB 内存在 Kopia 路径下执行 FS Backup记录指标node-agent DaemonSet 的时间消耗、最大 CPU 使用率、最大内存使用率以及 Minio 存储占用Velero Deployment 的指标不计入测试期间关闭压缩Compression disabled以隔离数据去重与压缩对结果的影响。六组基准测试数据形态决定性能曲线以下逐组呈现原文测试结果与结论。Case 1海量空文件419 万文件 / 239 万目录0B/文件内容总量 0BUploaderResourcesTimesMax CPUMax MemoryRepo UsageKopia1c2g24m54s65%1530 MB80 MBKopia4c4g24m52s63%2216 MB80 MB结论海量空文件场景下Kopia 的内存占用超过 Velero 默认的 1 GB 内存上限1530 MB / 2216 MB存在触发 OOM 的风险从 1c2g 提升到 4c4g 对耗时几乎没有改善24m54s → 24m52s说明该场景瓶颈不在 CPU/内存容量而在于文件数本身。Case 2固定 100B 文件大小、默认资源配置文件量从 2 万递增到 200 万本组旨在观察文件数量增长对性能的影响。Case 2.123K 文件 / 10K 目录100B/文件总量 22.440 MBUploaderResourcesTimesMax CPUMax MemoryRepo UsageKopia1c1g2m34s70%692 MB108 MBCase 2.240K 文件 / 10K 目录100B/文件总量 44.880 MBUploaderResourcesTimesMax CPUMax MemoryRepo UsageKopia1c1g3m45s68%831 MB108 MBCase 2.370K 文件 / 10K 目录100B/文件总量 67.319 MBUploaderResourcesTimesMax CPUMax MemoryRepo UsageKopia1c1g5m06s71%861 MB108 MBCase 2.42M 文件 / 2M 目录100B/文件总量 200.000 MBUploaderResourcesTimesMax CPUMax MemoryRepo UsageKopia1c1gOOM74%N/AN/A结论随着文件数增加内存没有异常突增而是近似线性增长直至 Case 2.4200 万文件突破 1 GB 阈值触发Kopia 上传器 OOMKopia 上传器随着文件数增加单位文件处理耗时反而变快吞吐提升但总内存占用持续走高。Case 3大体积中等文件10K 文件 / 781 目录1 MB/文件总量 10.376 GBUploaderResourcesTimesMax CPUMax MemoryRepo UsageKopia1c2g1m37s75%251 MB10 GBKopia4c4g1m35s75%248 MB10 GB结论该场景备份体量较大10 GB但内存占用很低约 250 MB与文件形态文件数少、单文件体积大直接相关从 1c2g 提升到 4c4g 对耗时几乎无改善1m37s → 1m35s瓶颈主要在网络/存储吞吐而非计算资源。Case 4超大文件900 文件 / 1 目录1 GB/文件总量 900.000 GBUploaderResourcesTimesMax CPUMax MemoryRepo UsageKopia1c2g2h30m100%714 MB900 GBKopia4c4g1h42m138%786 MB900 GB结论对于超大数据的备份增加资源可以显著缩短备份时间2h30m → 1h42m缩短约 32%与 Case 1/3 形成鲜明对比——CPU 成为该场景的明显瓶颈4c4g 时 Max CPU 138%说明多核利用率充分。总结三条关键性能结论官方文档给出三点汇总是生产调优的直接依据同等规格资源下Kopia 上传器备份耗时更短与 restic 路径对比的结论原文指 With the same specification resources, Kopia uploader is less time-consuming when backupKopia 上传器在大数据量、海量小文件两类极端场景下均表现良好——小文件场景瓶颈是内存而非时间大数据场景 CPU 扩展性良好务必根据自身场景设置合理的资源配置而非依赖默认值默认配置下大规模备份极易触发超时timeout或 OOM。实践为 node-agent 配置合理的资源配额上述测试结论直接指向安装参数。当前仓库中 node-agent 的资源默认值定义在 pkg/install/resources.goCPU/内存的 request 与 limit默认全部为 0即不设置请求与限制QoS 等级为 BestEffort。这意味着默认安装下node-agent 没有内存上限保护海量小文件场景Case 2.4 曾 OOM不会立即报 OOM 而是可能被节点驱逐反之若手工设置过小的 limit如 1 GB则会像 Case 1 那样直接触发容器 OOM。对应的安装参数在 pkg/cmd/cli/install/install.go 中定义均支持 0 表示无限制参数说明--node-agent-pod-cpu-requestnode-agent 的 CPU request0视为不限制--node-agent-pod-mem-requestnode-agent 的内存 request0视为不限制--node-agent-pod-cpu-limitnode-agent 的 CPU limit0视为不限制--node-agent-pod-mem-limitnode-agent 的内存 limit0视为不限制安装示例官方 install 命令帮助中给出的完整写法velero install --provider gcp --plugins velero/velero-plugin-for-gcp:v1.0.0 --bucket gcp-backups \ --secret-file ./gcp-creds.json --use-node-agent \ --node-agent-pod-cpu-request1000m --node-agent-pod-cpu-limit5000m \ --node-agent-pod-mem-request512Mi --node-agent-pod-mem-limit1024Mi注--use-node-agent是启用 FS Backup 的前提install.go 中校验了--default-volumes-to-fs-backup必须与--use-node-agent同时使用。按数据形态给出配额建议综合 6 组测试可形成如下调参策略以本文测试环境为参考前提生产环境需自行压测校准海量小文件 / 大量空文件内存是首要风险点。Case 2 显示内存随文件数近似线性增长200 万 100B 文件在 1 GB 限制下 OOM。此类场景应将--node-agent-pod-mem-limit设置到 2 GB 以上Case 1 在 1c2g 下峰值达 1530 MB并配合足够的内存 request 保证调度CPU 提升收益很小无需盲目扩容。大文件 / 大总量数据CPU 与吞吐是瓶颈内存占用低Case 3 仅约 250 MBCase 4 约 714-786 MB。此类场景可适度调高 CPU limitCase 4 在 4c4g 下 Max CPU 达 138%多核利用充分内存按常规值设置即可。混合负载以最坏数据形态文件数最多、单文件最大为基准设计配额同时关注--pod-volume-operation-timeout默认 4 小时见 install.go避免大备份在超时窗口内无法完成。其他相关调优开关--parallel-files-upload备份创建时指定控制 Kopia 上传器并发上传文件数见 pkg/cmd/cli/backup/create.go。并发提高吞吐的同时也会推高内存占用需与内存配额联动调整--default-volumes-to-fs-backup让所有备份默认走 FS Backup见 install.go--uploader-type上传器类型当前仅支持kopia校验逻辑在 pkg/uploader/types.go 与 pkg/uploader/provider/provider.go 中实现。与源码的对应Kopia 上传器的实现位置若需深入理解 Kopia 上传器的内存与并发行为可沿以下源码路径继续探索pkg/uploader/provider/kopia.goKopia 上传器 Provider 实现负责备份/恢复的发起、取消与进度上报备份快照标签中写入snapshot-uploaderkopia见第 154-155 行pkg/uploader/types.go上传器类型与常量定义pkg/install/resources.go 与 pkg/install/daemonset.gonode-agent DaemonSet 的资源配额与宿主机卷挂载host-pods、host-plugins 等的生成逻辑pkg/cmd/cli/backup/create.go 与 pkg/cmd/cli/install/install.go备份创建命令与安装命令的参数绑定与校验。适用范围与限制本文测试结论来自 v1.10 预发布版本Version: main ###v1.10 pre-release与特定基础设施VMware 虚拟磁盘、SSD、Minio NFS、300/175 MB/s 吞吐且测试中关闭了压缩。以下情形下结论可能不再适用请以自身环境实测为准存储后端对象存储、网络吞吐、时延差异较大时数据形态超出空文件 / 100B 小文件 / 1MB 中文件 / 1GB 大文件四类覆盖范围时如大量硬链接、稀疏文件、极深目录树启用压缩或更换上传器参数如修改--parallel-files-upload后Velero 版本与 Kopia 版本发生变更时。无论何种场景官方建议的核心始终一致不要依赖默认资源配置根据自身数据形态显式设置 node-agent 的 CPU/内存配额并在上线前通过小规模基准测试验证资源边界。【免费下载链接】veleroBackup and migrate Kubernetes applications and their persistent volumes项目地址: https://gitcode.com/GitHub_Trending/ve/velero创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Velero 文件系统备份性能指南：Kopia 上传器在不同数据形态下的资源消耗与调优实践
Velero 文件系统备份性能指南Kopia 上传器在不同数据形态下的资源消耗与调优实践【免费下载链接】veleroBackup and migrate Kubernetes applications and their persistent volumes项目地址: https://gitcode.com/GitHub_Trending/ve/velero导读本指南以 Velero 官方文档 performance-guidance.md 为基础结合当前仓库源码系统讲解 Velero 文件系统备份File System BackupFS Backup在 Kopia 上传器路径下的性能表现通过 6 组覆盖海量小文件、中小文件量、大体积数据、超大文件等典型数据形态的基准测试量化时间消耗、CPU、内存与存储库占用并给出资源配额配置建议。读完本文你将掌握 Kopia 上传器的性能特征、OOM/超时的成因边界以及如何通过velero install的资源参数为 node-agent 设置合理配额避免大规模备份时的默认配置陷阱。背景FS Backup 与 Kopia 上传器Velero 对 Pod 卷Pod Volume的备份主要分为快照Snapshot与文件系统备份FS Backup两条路径。FS Backup 通过 node-agent 以 DaemonSet 形式在集群各节点上运行读取卷内文件系统数据并上传到对象存储。当前仓库中上传器的类型定义在 pkg/uploader/types.gokopiaKopiaType是当前唯一支持的文件系统上传器类型BlockType对应的velero-block用于块设备数据移动不属于本指南讨论范围。在安装阶段可通过--uploader-type显式指定上传器默认即为kopia见 pkg/cmd/cli/install/install.go同时--default-volumes-to-fs-backup可以配置 Velero 服务器在全部备份中默认对卷启用文件系统备份。执行备份时--parallel-files-upload仅对 Kopia 上传器生效可控制同时上传的文件数量见 pkg/cmd/cli/backup/create.go。本指南的核心命题是Kopia 上传器的性能会随数据形态data shape和资源配置resource settings而显著变化。官方文档基于多轮实测给出参考性结论但因基础设施差异与数据场景覆盖有限所有结果仅供参考不能直接外推为生产环境的绝对性能承诺。测试基础设施测试环境以 Minio 作为 Velero 后端对象存储NFS 用于创建承载数据的 PV/PVCMinio 与 NFS 服务器分别部署在不同虚拟机中写吞吐约 300 MB/s、读吞吐约 175 MB/s。完整环境信息如下原文照录### KUBERNETES VERSION Client Version: version.Info{Major:1, Minor:22, GitVersion:v1.22.4 Server Version: version.Info{Major:1, Minor:21, GitVersion:v1.21.14 ### DOCKER VERSION Client: Version: 20.10.12 API version: 1.41 Server: Engine: Version: 20.10.12 API version: 1.41 (minimum version 1.12) Go version: go1.16.2 containerd: Version: 1.5.9-0ubuntu1~20.04.4 runc: Version: 1.1.0-0ubuntu1~20.04.1 docker-init: Version: 0.19.0 ### NODES 6 // one master with 6 work nodes ### DISK INFO Vendor: VMware Product: Virtual disk Rotation Rate: Solid State Device Logical block size: 512 bytes ### MEMORY INFO total: 3.8Gi available: 3.3Gi (Swap: 0B) ### CPU INFO 4 Intel(R) Xeon(R) Gold 6230R CPU 2.10GHz ### SYSTEM INFO Linux version 5.4.0-126-generic (Ubuntu 20.04) ### VELERO VERSION Client: Version: main ###v1.10 pre-release version Server: Version: main ###v1.10 pre-release version测试方法要点共执行 6 组测试每组使用受限资源1 核 CPU 2 GB 内存或4 核 CPU 4 GB 内存在 Kopia 路径下执行 FS Backup记录指标node-agent DaemonSet 的时间消耗、最大 CPU 使用率、最大内存使用率以及 Minio 存储占用Velero Deployment 的指标不计入测试期间关闭压缩Compression disabled以隔离数据去重与压缩对结果的影响。六组基准测试数据形态决定性能曲线以下逐组呈现原文测试结果与结论。Case 1海量空文件419 万文件 / 239 万目录0B/文件内容总量 0BUploaderResourcesTimesMax CPUMax MemoryRepo UsageKopia1c2g24m54s65%1530 MB80 MBKopia4c4g24m52s63%2216 MB80 MB结论海量空文件场景下Kopia 的内存占用超过 Velero 默认的 1 GB 内存上限1530 MB / 2216 MB存在触发 OOM 的风险从 1c2g 提升到 4c4g 对耗时几乎没有改善24m54s → 24m52s说明该场景瓶颈不在 CPU/内存容量而在于文件数本身。Case 2固定 100B 文件大小、默认资源配置文件量从 2 万递增到 200 万本组旨在观察文件数量增长对性能的影响。Case 2.123K 文件 / 10K 目录100B/文件总量 22.440 MBUploaderResourcesTimesMax CPUMax MemoryRepo UsageKopia1c1g2m34s70%692 MB108 MBCase 2.240K 文件 / 10K 目录100B/文件总量 44.880 MBUploaderResourcesTimesMax CPUMax MemoryRepo UsageKopia1c1g3m45s68%831 MB108 MBCase 2.370K 文件 / 10K 目录100B/文件总量 67.319 MBUploaderResourcesTimesMax CPUMax MemoryRepo UsageKopia1c1g5m06s71%861 MB108 MBCase 2.42M 文件 / 2M 目录100B/文件总量 200.000 MBUploaderResourcesTimesMax CPUMax MemoryRepo UsageKopia1c1gOOM74%N/AN/A结论随着文件数增加内存没有异常突增而是近似线性增长直至 Case 2.4200 万文件突破 1 GB 阈值触发Kopia 上传器 OOMKopia 上传器随着文件数增加单位文件处理耗时反而变快吞吐提升但总内存占用持续走高。Case 3大体积中等文件10K 文件 / 781 目录1 MB/文件总量 10.376 GBUploaderResourcesTimesMax CPUMax MemoryRepo UsageKopia1c2g1m37s75%251 MB10 GBKopia4c4g1m35s75%248 MB10 GB结论该场景备份体量较大10 GB但内存占用很低约 250 MB与文件形态文件数少、单文件体积大直接相关从 1c2g 提升到 4c4g 对耗时几乎无改善1m37s → 1m35s瓶颈主要在网络/存储吞吐而非计算资源。Case 4超大文件900 文件 / 1 目录1 GB/文件总量 900.000 GBUploaderResourcesTimesMax CPUMax MemoryRepo UsageKopia1c2g2h30m100%714 MB900 GBKopia4c4g1h42m138%786 MB900 GB结论对于超大数据的备份增加资源可以显著缩短备份时间2h30m → 1h42m缩短约 32%与 Case 1/3 形成鲜明对比——CPU 成为该场景的明显瓶颈4c4g 时 Max CPU 138%说明多核利用率充分。总结三条关键性能结论官方文档给出三点汇总是生产调优的直接依据同等规格资源下Kopia 上传器备份耗时更短与 restic 路径对比的结论原文指 With the same specification resources, Kopia uploader is less time-consuming when backupKopia 上传器在大数据量、海量小文件两类极端场景下均表现良好——小文件场景瓶颈是内存而非时间大数据场景 CPU 扩展性良好务必根据自身场景设置合理的资源配置而非依赖默认值默认配置下大规模备份极易触发超时timeout或 OOM。实践为 node-agent 配置合理的资源配额上述测试结论直接指向安装参数。当前仓库中 node-agent 的资源默认值定义在 pkg/install/resources.goCPU/内存的 request 与 limit默认全部为 0即不设置请求与限制QoS 等级为 BestEffort。这意味着默认安装下node-agent 没有内存上限保护海量小文件场景Case 2.4 曾 OOM不会立即报 OOM 而是可能被节点驱逐反之若手工设置过小的 limit如 1 GB则会像 Case 1 那样直接触发容器 OOM。对应的安装参数在 pkg/cmd/cli/install/install.go 中定义均支持 0 表示无限制参数说明--node-agent-pod-cpu-requestnode-agent 的 CPU request0视为不限制--node-agent-pod-mem-requestnode-agent 的内存 request0视为不限制--node-agent-pod-cpu-limitnode-agent 的 CPU limit0视为不限制--node-agent-pod-mem-limitnode-agent 的内存 limit0视为不限制安装示例官方 install 命令帮助中给出的完整写法velero install --provider gcp --plugins velero/velero-plugin-for-gcp:v1.0.0 --bucket gcp-backups \ --secret-file ./gcp-creds.json --use-node-agent \ --node-agent-pod-cpu-request1000m --node-agent-pod-cpu-limit5000m \ --node-agent-pod-mem-request512Mi --node-agent-pod-mem-limit1024Mi注--use-node-agent是启用 FS Backup 的前提install.go 中校验了--default-volumes-to-fs-backup必须与--use-node-agent同时使用。按数据形态给出配额建议综合 6 组测试可形成如下调参策略以本文测试环境为参考前提生产环境需自行压测校准海量小文件 / 大量空文件内存是首要风险点。Case 2 显示内存随文件数近似线性增长200 万 100B 文件在 1 GB 限制下 OOM。此类场景应将--node-agent-pod-mem-limit设置到 2 GB 以上Case 1 在 1c2g 下峰值达 1530 MB并配合足够的内存 request 保证调度CPU 提升收益很小无需盲目扩容。大文件 / 大总量数据CPU 与吞吐是瓶颈内存占用低Case 3 仅约 250 MBCase 4 约 714-786 MB。此类场景可适度调高 CPU limitCase 4 在 4c4g 下 Max CPU 达 138%多核利用充分内存按常规值设置即可。混合负载以最坏数据形态文件数最多、单文件最大为基准设计配额同时关注--pod-volume-operation-timeout默认 4 小时见 install.go避免大备份在超时窗口内无法完成。其他相关调优开关--parallel-files-upload备份创建时指定控制 Kopia 上传器并发上传文件数见 pkg/cmd/cli/backup/create.go。并发提高吞吐的同时也会推高内存占用需与内存配额联动调整--default-volumes-to-fs-backup让所有备份默认走 FS Backup见 install.go--uploader-type上传器类型当前仅支持kopia校验逻辑在 pkg/uploader/types.go 与 pkg/uploader/provider/provider.go 中实现。与源码的对应Kopia 上传器的实现位置若需深入理解 Kopia 上传器的内存与并发行为可沿以下源码路径继续探索pkg/uploader/provider/kopia.goKopia 上传器 Provider 实现负责备份/恢复的发起、取消与进度上报备份快照标签中写入snapshot-uploaderkopia见第 154-155 行pkg/uploader/types.go上传器类型与常量定义pkg/install/resources.go 与 pkg/install/daemonset.gonode-agent DaemonSet 的资源配额与宿主机卷挂载host-pods、host-plugins 等的生成逻辑pkg/cmd/cli/backup/create.go 与 pkg/cmd/cli/install/install.go备份创建命令与安装命令的参数绑定与校验。适用范围与限制本文测试结论来自 v1.10 预发布版本Version: main ###v1.10 pre-release与特定基础设施VMware 虚拟磁盘、SSD、Minio NFS、300/175 MB/s 吞吐且测试中关闭了压缩。以下情形下结论可能不再适用请以自身环境实测为准存储后端对象存储、网络吞吐、时延差异较大时数据形态超出空文件 / 100B 小文件 / 1MB 中文件 / 1GB 大文件四类覆盖范围时如大量硬链接、稀疏文件、极深目录树启用压缩或更换上传器参数如修改--parallel-files-upload后Velero 版本与 Kopia 版本发生变更时。无论何种场景官方建议的核心始终一致不要依赖默认资源配置根据自身数据形态显式设置 node-agent 的 CPU/内存配额并在上线前通过小规模基准测试验证资源边界。【免费下载链接】veleroBackup and migrate Kubernetes applications and their persistent volumes项目地址: https://gitcode.com/GitHub_Trending/ve/velero创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考