最近在Gen10 Plus上安装了VMWare ESXi，发现服务器在存储方面还蛮多样化的，也了解到了许多新概念，并做了一些性能对比测试，故在此记录小结一下~

基本概念

VMFS

Virtual Machine File System（虚拟机文件系统），是一种针对存储虚拟机而优化的高性能文件系统格式。

虚拟磁盘

ESXi上给虚拟机分配的磁盘，用来安装操作系统以及存储数据，其本质上是存储在物理磁盘设备上的一个大文件（也可能拆分成多个文件）。

虚拟机通过虚拟SCSI控制器访问虚拟磁盘，对于虚拟机而言，每个虚拟磁盘都是与SCSI控制器连接的SCSI驱动器；而实际上真实的物理磁盘设备可能是本地的，也可能是远程的网络磁盘。

RDM

Raw Device Map（裸设备映射），除了虚拟磁盘外，ESXi还提供了裸设备映射的机制，虚拟机可以对存储设备进行直接访问。

iSCSI

iSCSI是一种存储设备远程映射技术，它可以将一个远程服务器上的存储设备映射到本地，并作为一个块设备（即磁盘）来使用。

NFS

Network File System（网络文件系统），ESXi 中内置的 NFS 客户端使用网络文件系统 (NFS) 协议通过 TCP/IP 访问位于 NAS 服务器上的 NFS 卷并挂载卷，并将其用作 NFS 数据存储。

其他相关的概念可以参考之前的文章《群晖 SAN Manager》 。

实战开始

VMFS

在ESXi的存储界面可以看到机器上已连接的磁盘设备：

我们在其中一个HDD上新建VMFS数据存储，可以选择使用全部磁盘或自定义大小：

之后还可以增加数据存储大小，可以在原来磁盘上进行扩展，或选择新磁盘添加数据区：

扩展后可以看到数据存储的VMFS中有两个数据区：

但貌似只能增加容量而不能减少，没有找到删除数据区的方法。

官网文档提到“要减小 VMFS 数据存储的容量，必须销毁原始数据存储”，感觉是个大坑，如果某块硬盘坏了岂不是凉凉？

RDM

ESXi中支持以裸设备的形式直接挂载iSCSI磁盘，但界面上并不支持本地磁盘，因此需要通过命令行进行操作。

在ESXi上启用SSH，然后登录主机，找到对应的磁盘名称：

[root@localhost:~] ls -al /vmfs/devices/disks/
total 20989220001
drwxr-xr-x    2 root     root           512 Jun 24 13:52 .
drwxr-xr-x   16 root     root           512 Jun 24 13:52 ..
-rw-------    1 root     root     30784094208 Jun 24 13:52 mpx.vmhba32:C0:T0:L0
-rw-------    1 root     root     104857600 Jun 24 13:52 mpx.vmhba32:C0:T0:L0:1
-rw-------    1 root     root     1073741824 Jun 24 13:52 mpx.vmhba32:C0:T0:L0:5
-rw-------    1 root     root     1073741824 Jun 24 13:52 mpx.vmhba32:C0:T0:L0:6
-rw-------    1 root     root     28527541760 Jun 24 13:52 mpx.vmhba32:C0:T0:L0:7
-rw-------    1 root     root     214748364800 Jun 24 13:52 naa.6001405c5769701dbb1bd4364da8bcd0
-rw-------    1 root     root     214748364800 Jun 24 13:52 naa.6001405f43350fcd7386d45a5d8441d4
-rw-------    1 root     root     3000592982016 Jun 24 13:52 t10.ATA_____ST3000DM0012D1ER166__________________________________W502Y98W
-rw-------    1 root     root     16000900661248 Jun 24 13:52 t10.ATA_____WDC__WUH721816ALE6L4____________________2PGVNPMT____________
-rw-------    1 root     root     1000204886016 Jun 24 13:52 t10.NVMe____Samsung_SSD_980_1TB_____________________68B7B011D6382500
-rw-------    1 root     root     1000202043904 Jun 24 13:52 t10.NVMe____Samsung_SSD_980_1TB_____________________68B7B011D6382500:2
lrwxrwxrwx    1 root     root            73 Jun 24 13:52 vml.01000000002020202020202020202020205735303259393857535433303030 -> t10.ATA_____ST3000DM0012D1ER166__________________________________W502Y98W
lrwxrwxrwx    1 root     root            20 Jun 24 13:52 vml.0100000000303130316238316239663438316237303130313766666330616235373162303466393735363353616e446973 -> mpx.vmhba32:C0:T0:L0
lrwxrwxrwx    1 root     root            22 Jun 24 13:52 vml.0100000000303130316238316239663438316237303130313766666330616235373162303466393735363353616e446973:1 -> mpx.vmhba32:C0:T0:L0:1
lrwxrwxrwx    1 root     root            22 Jun 24 13:52 vml.0100000000303130316238316239663438316237303130313766666330616235373162303466393735363353616e446973:5 -> mpx.vmhba32:C0:T0:L0:5
lrwxrwxrwx    1 root     root            22 Jun 24 13:52 vml.0100000000303130316238316239663438316237303130313766666330616235373162303466393735363353616e446973:6 -> mpx.vmhba32:C0:T0:L0:6
lrwxrwxrwx    1 root     root            22 Jun 24 13:52 vml.0100000000303130316238316239663438316237303130313766666330616235373162303466393735363353616e446973:7 -> mpx.vmhba32:C0:T0:L0:7
lrwxrwxrwx    1 root     root            72 Jun 24 13:52 vml.0100000000325047564e504d54202020202020202020202020574443202057 -> t10.ATA_____WDC__WUH721816ALE6L4____________________2PGVNPMT____________
lrwxrwxrwx    1 root     root            68 Jun 24 13:52 vml.0100000000363842375f423031315f443633385f323530300053616d73756e -> t10.NVMe____Samsung_SSD_980_1TB_____________________68B7B011D6382500
lrwxrwxrwx    1 root     root            70 Jun 24 13:52 vml.0100000000363842375f423031315f443633385f323530300053616d73756e:2 -> t10.NVMe____Samsung_SSD_980_1TB_____________________68B7B011D6382500:2
lrwxrwxrwx    1 root     root            36 Jun 24 13:52 vml.02000100006001405c5769701dbb1bd4364da8bcd053746f726167 -> naa.6001405c5769701dbb1bd4364da8bcd0
lrwxrwxrwx    1 root     root            36 Jun 24 13:52 vml.02000200006001405f43350fcd7386d45a5d8441d453746f726167 -> naa.6001405f43350fcd7386d45a5d8441d4
lrwxrwxrwx    1 root     root            68 Jun 24 13:52 vml.058000144d79e59e7c96948e42d69c40000cdeb3f97554247d0d2d7d5167846393 -> t10.NVMe____Samsung_SSD_980_1TB_____________________68B7B011D6382500
lrwxrwxrwx    1 root     root            70 Jun 24 13:52 vml.058000144d79e59e7c96948e42d69c40000cdeb3f97554247d0d2d7d5167846393:2 -> t10.NVMe____Samsung_SSD_980_1TB_____________________68B7B011D6382500:2

重点留意 t10. 开头的设备名，通过 vmkfstools 命令将其转为 RDM：

vmkfstools -z /vmfs/devices/disks/diskname /vmfs/volumes/datastorename/vmfolder/vmname.vmdk

我们以 t10.ATA_____WDC__WUH721816ALE6L4____________________2PGVNPMT____________ 这个磁盘为例：

[root@localhost:~] vmkfstools -z /vmfs/devices/disks/t10.ATA_____WDC__WUH721816ALE6L4____________________2PGVNPMT____________ /vmfs/volumes/datastore/test/hdd.vmdk

[root@localhost:~] ls -alh /vmfs/volumes/datastore/test/
total 1152
drwxr-xr-x    1 root     root       72.0K Jun 24 11:37 .
drwxr-xr-t    1 root     root       76.0K Jun 24 11:37 ..
-rw-------    1 root     root       14.6T Jun 24 11:37 hdd-rdmp.vmdk
-rw-------    1 root     root         475 Jun 24 11:37 hdd.vmdk

可以看到在test目录下生成了两个磁盘文件，新创建的 RDM 指针文件的大小与其映射到的裸设备大小相同，它是一个虚拟文件，不占用任何存储空间。

最后，我们就可以在虚拟机中直接添加现有硬盘：

iSCSI

先在群晖 NAS 的 SAN Manager 中新建一个LUN并分配到 iSCSI Target，然后在ESXi中开启 iSCSI：

可以尝试填写静态目标（IQN+IP），或者直接使用动态目标自动发现（保存配置后再打开）。

最后就可以通过iSCSI磁盘创建VMFS数据存储了：

可以看到多了一个数据存储：

除了创建VMFS数据存储，还可以直接将iSCSI磁盘挂载到虚拟机，编辑虚拟机配置-添加硬盘-新裸磁盘，然后选择对应的iSCSI磁盘：

NFS

在ESXi中挂载NFS存储相当简单，新建数据存储，选择挂载NFS数据存储，填写NFS配置：

可以看到已经挂载成功了：

性能对比

以 Windows10 为测试平台，通过 CrystalDisk Mark 8 分别测试每个磁盘设备的读写速度。首先，我们将虚拟机安装在三星SSD 980上，然后分别添加不同类型的磁盘进行测试。

SSD

直接测试系统盘的读写速度，测试结果基本接近SSD的原生性能。

HDD

添加一块100G的虚拟磁盘，选择厚置备(置零)，其磁盘文件保存在机械硬盘上。

尝试复制一个较大的文件，速度稳定在266MB/s，最前面的峰值应该是磁盘缓存。

RDM

通过前面的RDM映射方法直接将磁盘挂载到虚拟机，测试其硬盘性能：

对比HDD虚拟磁盘的测试，连续读写要差一点、随机4K则好一点，具体原因不明。

再测试复制一个较大的文件：

结果发现平均写入速度竟然只有90MB/s 左右，比HDD结果慢了一大半，具体原因不明。

iSCSI

先在ESXi中选择iSCSI磁盘新建数据存储，然后添加给虚拟机添加一块虚拟磁盘(100G、厚置备置零)。

由于iSCSI磁盘与服务器之间是通过千兆网连接的，可以看到速度瓶颈卡在网络上。

iSCSI RDM

直接将iSCSI磁盘以裸设备的形式挂载到虚拟机，然后进行测试。

对比在iSCSI磁盘上新建虚拟磁盘的方式，裸磁盘映射结果基本一样。

NFS

我们在通过NFS挂载的数据存储上新建一个虚拟磁盘（20G、厚置备置零），期间发现创建磁盘过程中竟然要完整写入20G数据到NFS上。

对比前面在iSCSI磁盘上创建虚拟磁盘并不需要等待很久即可完成厚置备置零操作，猜测是VMFS对此进行了优化。

结果与iSCSI相差无几，瓶颈仍旧在于网络。

由于目前手头没有万兆网络设备，无法确定10Gb网络环境下会有多大性能差异，而万兆网络搭建需要相应的万兆网卡和万兆交换机，成本较高。

RDM vs VMFS

一般情况下，在VMFS上使用虚拟磁盘是推荐做法，这种方式能够得到更加完整的功能支持；在上面的测试比较中，我们也能看到RDM并没有比VMFS更加高性能（或者说VMFS本身性能已经非常好了）。

当然，在一些特定的场景（比如SAN管理软件）需要直接访问底层磁盘，这时候就需要使用RDM了。

详细的性能对比，可以查看官方说明。

参考：

• Raw Device Mapping for local storage
• Reducing the size of a VMFS datastore
• Performance Characteristics of VMFS and RDM