存储

• 1: 存储介绍
• 2: NFS
• 2.1: 配置NFS
• 2.2: [废弃]通过NFS复制
• 2.3: [废弃]通过 NFS 进行 dump 和恢复
• 3: Ceph
• 3.1: Ceph概述

1 - 存储介绍

参考：

https://pve.proxmox.com/pve-docs/pve-admin-guide.html#chapter_storage

Proxmox VE存储模型非常灵活。虚拟机映像可以存储在一个或多个本地存储上，也可以存储在 NFS 或 iSCSI（NAS、SAN）等共享存储上。没有限制，您可以根据需要配置任意数量的存储池。您可以使用所有可用于 Debian Linux 的存储技术。

将 VM 存储在共享存储上的一个主要好处是能够在不停机的情况下实时迁移正在运行的计算机，因为群集中的所有节点都可以直接访问 VM 磁盘映像。无需复制 VM 映像数据，因此在这种情况下，实时迁移非常快。

存储库（包libpve-storage-perl）使用灵活的插件系统为所有存储类型提供通用接口。这可以很容易地采用，以包括将来的更多存储类型。

存储类型

基本上有两种不同类型的存储类型：

• File level storage 文件级存储

  基于文件级的存储技术允许访问功能齐全的 （POSIX） 文件系统。它们通常比任何块级存储（见下文）更灵活，并允许您存储任何类型的内容。ZFS 可能是最先进的系统，它完全支持快照和克隆。

• Block level storage 块级存储

  允许存储大型 raw 镜像。通常不可能在此类存储类型上存储其他文件（ISO、备份等）。大多数现代块级存储实现都支持快照和克隆。RADOS和GlusterFS是分布式系统，将存储数据复制到不同的节点。

可用的存储类型

精简配置

许多存储和 QEMU 映像格式 qcow2 支持精简配置。激活精简置备后，只有客户机系统实际使用的块才会写入存储。

例如，假设您创建了一个具有 32GB 硬盘的 VM，在安装 guest 系统操作系统后，该 VM 的根文件系统包含 3 GB 的数据。在这种情况下，即使来宾虚拟机看到 32GB 的硬盘驱动器，也只会将 3GB 写入存储。通过这种方式，精简配置允许您创建大于当前可用存储块的磁盘映像。可以为 VM 创建大型磁盘映像，并在需要时向存储添加更多磁盘，而无需调整 VM 文件系统的大小。

具有“快照”功能的所有存储类型也支持精简配置。

存储配置

所有与Proxmox VE相关的存储配置都存储在/etc/pve/storage.cfg的单个文本文件中。由于此文件位于 /etc/pve/ 中，因此会自动分发到所有群集节点。因此，所有节点共享相同的存储配置。

共享存储配置对于共享存储非常有意义，因为可以从所有节点访问相同的“共享”存储。但它对于本地存储类型也很有用。在这种情况下，这种本地存储在所有节点上都可用，但它在物理上是不同的，并且可以具有完全不同的内容。

存储池

每个存储池都有一个 <type>，并由其 <STORAGE_ID>。池配置如下所示：

<type>: <STORAGE_ID>
        <property> <value>
        <property> <value>
        <property>
        ...

<type>: <STORAGE_ID> 行开始池定义，然后是属性列表。大多数属性都需要值。有些具有合理的默认值，在这种情况下，您可以省略该值。

更具体地说，请查看安装后的默认存储配置。它包含一个名为 local 的特殊本地存储池，该池引用目录 /var/lib/vz 并且始终可用。Proxmox VE安装程序根据安装时选择的存储类型创建其他存储条目。

默认存储配置 （/etc/pve/storage.cfg）

dir: local
        path /var/lib/vz
        content iso,vztmpl,backup

# default image store on LVM based installation
lvmthin: local-lvm
        thinpool data
        vgname pve
        content rootdir,images

# default image store on ZFS based installation
zfspool: local-zfs
        pool rpool/data
        sparse
        content images,rootdir

2 - NFS

2.1 - 配置NFS

标准配置

在 pve 控制页面上打开 Datacenter, 进入 Storge, 在 “Add” 下拉框中选择 “NFS”:

这个方案在正常 pve 集群下没有问题，但是我这里因为机器都是按需启动，不会7x24小时在线，因此 pve 集群的最小法定人数经常无法达到，导致集群不可用。

如果用上面的方案，那么不同机器都会新建 nfs 存储，会导致都指向同一个 nfs 远程目录，这样应该会造成混乱。

个人实践（受限不能使用集群功能）

ID分段使用 nfs 存储

一番尝试之后发现，标准的 nfs 存储只要处理好 ID 分段，不同的 pve 节点使用不同的 ID 范围，就可以正常使用的（前提：有多台 pve 机器又不愿意建立集群）。

建立 nfs 存储的方式和标准方式一样，只是 Content 只选了三个： Disk image, ISO image 和 VZDump backup file。

ID 分段规则：

• local： 从 100 到 999
• nfs-fast： skyserver1-6六台机器，分段分别为 1000-1099 / 2000-2099 / 3000-3099 / 4000-4099 / 5000-5099 / 6000-6099
• template： 10000 开始

nfs 文件存储位置

服务器端

在 export 文件中，服务器端 export 的目录是 /mnt/data/pve-share

ls
dump  images  template

• template/iso 目录： 存放上传的 iso 文件
• dump 目录： 存放虚拟机和模板的备份文件，可以用于恢复。

客户端

在 pve 页面上用 nfs-fast 为 ID 建立的 nfs 存储，在本地磁盘上挂载的路径为 /mnt/pve/nfs-fast

共享模板

由于模板是只读的，因此适合跨pve节点共享，但是按照 pve 标准的恢复方式，从 dump 文件恢复后存放在 nfs 存储中的模板虚拟机，只保存在执行恢复操作的这一台 pve 机器上，其他 pve 机器只能在 “VM Disk” 看到这些模板的镜像文件，但是在虚拟机列表中无法列出。

ssh 登录操作模板恢复的 pve 节点，可以看到恢复的虚拟机模板：

cd /etc/pve/qemu-server
ls

10000.conf  10001.conf

这里遵守前面定制的规则：虚拟机模板的 id 从 10000 开始，确保不会和本地存储上的虚拟机ID重叠。

先把配置文件下载到本地作为备份：

cd /media/d/backup/pve/qemu-server
scp root@192.168.99.38:/etc/pve/qemu-server/10000.conf /media/d/backup/pve/qemu-server/
scp root@192.168.99.38:/etc/pve/qemu-server/10001.conf /media/d/backup/pve/qemu-server/

然后将这些模板的配置文件复制到其他 pve 节点：

# skyserver
scp /media/d/backup/pve/qemu-server/10000.conf root@192.168.99.18:/etc/pve/qemu-server
scp /media/d/backup/pve/qemu-server/10001.conf root@192.168.99.18:/etc/pve/qemu-server

# skyserver2
scp /media/d/backup/pve/qemu-server/10000.conf root@192.168.99.28:/etc/pve/qemu-server
scp /media/d/backup/pve/qemu-server/10001.conf root@192.168.99.28:/etc/pve/qemu-server

# skyserver4
scp /media/d/backup/pve/qemu-server/10000.conf root@192.168.99.48:/etc/pve/qemu-server
scp /media/d/backup/pve/qemu-server/10001.conf root@192.168.99.48:/etc/pve/qemu-server

# skyserver5
scp /media/d/backup/pve/qemu-server/10000.conf root@192.168.99.58:/etc/pve/qemu-server
scp /media/d/backup/pve/qemu-server/10001.conf root@192.168.99.58:/etc/pve/qemu-server

比较麻烦一点的是以后模板文件有变化（增加/修改/删除）时，需要用这个方式手工同步各个 pve 节点机器（毕竟没有集群管理）。

好在模板一般数量有限，更新频率也不会太高，先这么对付着用，不行就写个脚本简化一下操作。

模板和虚拟机恢复的最佳实践

实际操作中，有一些发现：

1. 从 dump 出来的备份文件恢复模板，速度是非常快的

   不管是恢复到 nfs 存储还是某台 pve 节点的 local 本地存储，大概一分钟这个级别

2. 从模板文件 clone 到虚拟机，速度非常慢

   恢复 pve 节点的 local 本地存储，大概三五分钟这个级别。

3. clone 时如果选择 “Linked clone”，速度非常快。

   10秒级别， 毕竟这种情况下无需复制整个模板的文件（10-20G级别）

因此，总结出来的最佳实现应该是这样：

1. 坚持以模板为基础来实现虚拟机的备份和版本控制：模板是只读的，对内容的一致性有保障
2. 以pve备份的方式对模板进行备份，得到 dump 文件，用于离线冷备份和不同机器之间分发
3. dump 文件倒入到 nfs 存储中，全局一份
4. 模板默认恢复一份到 nfs 存储中，同样全局只有一份：使用时直接在 nfs 上 “Linked clone”，用完即删
5. 对于使用频率非常高的模板，直接恢复到 pve 节点的 local 本地存储：后续根据使用时间长短区分，长期使用的希望隔离性好的，用 “Full clone”。短期使用用完就删的用 “linked clone”

2.2 - [废弃]通过NFS复制

背景

scp 命令的速度，只能达到 300-400MB,无法发挥出网络和硬盘的速度。

nfs 会快一些，实际测试可以达到 2000 - 3000 MB （主要瓶颈在ssd写入速度）。

准备工作

准备 nfs 服务器端

在 skydev 机器上开通 nfs，然后将 4t 的 pcie 4.0 ssd 以 nfs 的方式共享出来

nfs 地址为： 192.168.99.100 ， export 地址为 /mnt/data/share。

准备 nfs 客户端

pve 节点上安装 nfs 客户端。

mount nfs 到 pve 节点

在pve 节点上执行命令：

mkdir -p /mnt/nfs-fast
# on skywork
sudo mount 192.168.100.1:/mnt/data/share /mnt/nfs-fast
# on skyserver
mount 192.168.99.100:/mnt/data/share /mnt/nfs-fast

为了方便，

vi ~/.zshrc

增加一个 alias :

# on skywork
alias mount-nfs-fast='sudo mount 192.168.100.1:/mnt/data/share /mnt/nfs-fast'
# on skyserver
alias mount-nfs-fast='mount 192.168.99.100:/mnt/data/share /mnt/nfs-fast'

复制虚拟机和模板

复制虚拟机或者模板文件到 pve 的 dump 目录:

cd /mnt/nfs-fast/pve-share/templates/ubuntu20.04
cp *.vma *.vma.notes /var/lib/vz/dump 

同样为了方便，

vi ~/.zshrc

增加一个 alias :

alias copy-pve-dump='cp *.vma *.vma.notes /var/lib/vz/dump/'

恢复虚拟机或者模板

在 pve 管理页面操作，打开 local，“Backups” 。

总结

这个方案中，nfs 只是作为一种快速的远程源文件复制方式，从 nfs 服务器端将虚拟机或者模板文件复制到 pve 本地存储，然后通过标准的 pve 虚拟机恢复方式来恢复虚拟机或者模板。之后虚拟机或者模板就存放在 pve 本地存储上了，再进行各种 clone 操作也就方便了。

缺点就是完全绕开了 pve, 需要 ssh + 命令手工执行。

2.3 - [废弃]通过 NFS 进行 dump 和恢复

背景

前面纯 nfs 的方案还是手工操作太多。

考虑采用 pve 的 nfs storage，但是只存放 dump 出来的虚拟机或者模板文件，不涉及到 vm id，不会造成冲突。

准备工作

准备 nfs 服务器端

在 skydev 机器上开通 nfs，额外增加一个 export 地址，为 /mnt/data/pve-dump。

新建 nfs 存储

打开 pve 管理页面，在 “datacenter” -》 “storage” 下，“Add” 一个名为 “nfs-fast-dump” 的 NFS 存储， export 选择 /mnt/data/pve-dump。“content” 只选择 “VZDump backup file”。

此时 pve 会自动在 /mnt/data/pve-dump 目录下新建一个名为 “dump” 的子目录，将之前备份的 vma 等文件，复制到 /mnt/data/pve-dump/dump/ 目录。

刷新 “nfs-fast-dump” 存储的 “Backups” 就可以看到之前备份的 dump 文件，然后就可以用 pve 标准的恢复功能将他们恢复为虚拟机或者模板。

实践了一下, 8G 的模板恢复时间为 66 秒：

restore vma archive: vma extract -v -r /var/tmp/vzdumptmp101735.fifo /mnt/pve/nfs-fast-dump/dump/vzdump-qemu-107-2023_07_26-02_23_55.vma /var/tmp/vzdumptmp101735
CFG: size: 667 name: qemu-server.conf
DEV: dev_id=1 size: 540672 devname: drive-efidisk0
DEV: dev_id=2 size: 549755813888 devname: drive-scsi0
CTIME: Wed Jul 26 02:23:55 2023
Formatting '/var/lib/vz/images/101/vm-101-disk-0.qcow2', fmt=qcow2 cluster_size=65536 extended_l2=off preallocation=metadata compression_type=zlib size=540672 lazy_refcounts=off refcount_bits=16
new volume ID is 'local:101/vm-101-disk-0.qcow2'
Formatting '/var/lib/vz/images/101/vm-101-disk-1.qcow2', fmt=qcow2 cluster_size=65536 extended_l2=off preallocation=metadata compression_type=zlib size=549755813888 lazy_refcounts=off refcount_bits=16
new volume ID is 'local:101/vm-101-disk-1.qcow2'
map 'drive-efidisk0' to '/var/lib/vz/images/101/vm-101-disk-0.qcow2' (write zeros = 0)
map 'drive-scsi0' to '/var/lib/vz/images/101/vm-101-disk-1.qcow2' (write zeros = 0)
progress 1% (read 5497618432 bytes, duration 1 sec)
progress 2% (read 10995171328 bytes, duration 3 sec)
progress 3% (read 16492724224 bytes, duration 6 sec)
progress 4% (read 21990277120 bytes, duration 7 sec)
......
progress 99% (read 544258785280 bytes, duration 66 sec)
progress 100% (read 549756338176 bytes, duration 66 sec)
total bytes read 549756403712, sparse bytes 541771325440 (98.5%)
space reduction due to 4K zero blocks 5.08%
rescan volumes...
Convert to template.
TASK OK

20G 的模板恢复时间为 115 秒：

restore vma archive: vma extract -v -r /var/tmp/vzdumptmp103025.fifo /mnt/pve/nfs-fast-dump/dump/vzdump-qemu-102-2023_07_26-01_23_50.vma /var/tmp/vzdumptmp103025
CFG: size: 637 name: qemu-server.conf
DEV: dev_id=1 size: 540672 devname: drive-efidisk0
DEV: dev_id=2 size: 549755813888 devname: drive-scsi0
CTIME: Wed Jul 26 01:23:50 2023
Formatting '/var/lib/vz/images/102/vm-102-disk-0.qcow2', fmt=qcow2 cluster_size=65536 extended_l2=off preallocation=metadata compression_type=zlib size=540672 lazy_refcounts=off refcount_bits=16
new volume ID is 'local:102/vm-102-disk-0.qcow2'
Formatting '/var/lib/vz/images/102/vm-102-disk-1.qcow2', fmt=qcow2 cluster_size=65536 extended_l2=off preallocation=metadata compression_type=zlib size=549755813888 lazy_refcounts=off refcount_bits=16
new volume ID is 'local:102/vm-102-disk-1.qcow2'
map 'drive-efidisk0' to '/var/lib/vz/images/102/vm-102-disk-0.qcow2' (write zeros = 0)
map 'drive-scsi0' to '/var/lib/vz/images/102/vm-102-disk-1.qcow2' (write zeros = 0)
progress 1% (read 5497618432 bytes, duration 5 sec)
progress 2% (read 10995171328 bytes, duration 6 sec)
......
progress 98% (read 538761232384 bytes, duration 108 sec)
progress 99% (read 544258785280 bytes, duration 109 sec)
progress 100% (read 549756338176 bytes, duration 115 sec)
total bytes read 549756403712, sparse bytes 529814392832 (96.4%)
space reduction due to 4K zero blocks 2.65%
rescan volumes...
Convert to template.
TASK OK

速度只能说还凑合，模板恢复的速度太慢了。

总结

这个方案中，使用到了 pve nfs 存储的功能，但是为了避免在多个 pve 机器（不是一个 cluster） 之间出现冲突，因此只在这个 nfs 存储中存放不涉及到集群的内容。

思路扩展

按照上面的思路，只要 nfs 存储上放的内容不涉及到集群，即不会造成集群范围内的冲突，就不影响使用。

扩展存储类型以包含 ISO 文件

因此，nfs 存储存放的类型可以不限于单纯的 “VZDump backup file”， 可以增加 iso image, 毕竟 iso 文件是没有任何集群属性的，而且也没有必要每台 pve 机器都存放一份。

手工分配 id 以避免冲突

继续扩展上面的思路，对于可能会造成集群冲突的内容，如果能通过某种方式避免冲突，那么也是可以存放在 nfs 上的（备注：多台 pve 机器但是不建立集群) ，比虚拟机和模板。

关键： 在虚拟机和模板的建立过程（包括新建，clone, 恢复等）中， id 是容许手工指定的。

因此，只要制订并遵守某个 id 分配的规则，让不同 pve 节点上的 nfs 存储以不同的 id 段分配 id, 就可以确保任意一台 pve 节点上的 id 都不会和其他 pve 节点重复。

按照这个思路，修改 nfs 存储可以存放的类型，增加 “Disk image” 用来存放虚拟机和模板的镜像文件。

比如 skysever4 这台机器的 id 就以 14000 开头，从 14001 到 14999，绝对够用。skysever5 就用 15001 到 15999……

3 - Ceph

3.1 - Ceph概述