ESXi存储小记
source link: https://chenjiehua.me/linux/esxi-storage-note.html
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
ESXi存储小记
最近在Gen10 Plus上安装了VMWare ESXi，发现服务器在存储方面还蛮多样化的，也了解到了许多新概念，并做了一些性能对比测试，故在此记录小结一下~
Virtual Machine File System（虚拟机文件系统），是一种针对存储虚拟机而优化的高性能文件系统格式。
ESXi上给虚拟机分配的磁盘，用来安装操作系统以及存储数据，其本质上是存储在物理磁盘设备上的一个大文件（也可能拆分成多个文件）。
虚拟机通过虚拟SCSI控制器访问虚拟磁盘，对于虚拟机而言，每个虚拟磁盘都是与SCSI控制器连接的SCSI驱动器；而实际上真实的物理磁盘设备可能是本地的，也可能是远程的网络磁盘。
Raw Device Map（裸设备映射），除了虚拟磁盘外，ESXi还提供了裸设备映射的机制，虚拟机可以对存储设备进行直接访问。
iSCSI
iSCSI是一种存储设备远程映射技术，它可以将一个远程服务器上的存储设备映射到本地，并作为一个块设备（即磁盘）来使用。
Network File System（网络文件系统），ESXi 中内置的 NFS 客户端使用网络文件系统 (NFS) 协议通过 TCP/IP 访问位于 NAS 服务器上的 NFS 卷并挂载卷，并将其用作 NFS 数据存储。
其他相关的概念可以参考之前的文章《群晖 SAN Manager》 。
在ESXi的存储界面可以看到机器上已连接的磁盘设备：
我们在其中一个HDD上新建VMFS数据存储，可以选择使用全部磁盘或自定义大小：
之后还可以增加数据存储大小，可以在原来磁盘上进行扩展，或选择新磁盘添加数据区：
扩展后可以看到数据存储的VMFS中有两个数据区：
但貌似只能增加容量而不能减少，没有找到删除数据区的方法。
官网文档提到“要减小 VMFS 数据存储的容量，必须销毁原始数据存储”，感觉是个大坑，如果某块硬盘坏了岂不是凉凉？
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磁盘：
在ESXi中挂载NFS存储相当简单，新建数据存储，选择挂载NFS数据存储，填写NFS配置：
可以看到已经挂载成功了：
以 Windows10 为测试平台，通过 CrystalDisk Mark 8 分别测试每个磁盘设备的读写速度。首先，我们将虚拟机安装在三星SSD 980上，然后分别添加不同类型的磁盘进行测试。
直接测试系统盘的读写速度，测试结果基本接近SSD的原生性能。
添加一块100G的虚拟磁盘，选择厚置备(置零)，其磁盘文件保存在机械硬盘上。
尝试复制一个较大的文件，速度稳定在266MB/s，最前面的峰值应该是磁盘缓存。
通过前面的RDM映射方法直接将磁盘挂载到虚拟机，测试其硬盘性能：
对比HDD虚拟磁盘的测试，连续读写要差一点、随机4K则好一点，具体原因不明。
再测试复制一个较大的文件：
结果发现平均写入速度竟然只有90MB/s 左右，比HDD结果慢了一大半，具体原因不明。
iSCSI
先在ESXi中选择iSCSI磁盘新建数据存储，然后添加给虚拟机添加一块虚拟磁盘(100G、厚置备置零)。
由于iSCSI磁盘与服务器之间是通过千兆网连接的，可以看到速度瓶颈卡在网络上。
iSCSI RDM
直接将iSCSI磁盘以裸设备的形式挂载到虚拟机，然后进行测试。
对比在iSCSI磁盘上新建虚拟磁盘的方式，裸磁盘映射结果基本一样。
我们在通过NFS挂载的数据存储上新建一个虚拟磁盘（20G、厚置备置零），期间发现创建磁盘过程中竟然要完整写入20G数据到NFS上。
对比前面在iSCSI磁盘上创建虚拟磁盘并不需要等待很久即可完成厚置备置零操作，猜测是VMFS对此进行了优化。
结果与iSCSI相差无几，瓶颈仍旧在于网络。
由于目前手头没有万兆网络设备，无法确定10Gb网络环境下会有多大性能差异，而万兆网络搭建需要相应的万兆网卡和万兆交换机，成本较高。
RDM vs VMFS
一般情况下，在VMFS上使用虚拟磁盘是推荐做法，这种方式能够得到更加完整的功能支持；在上面的测试比较中，我们也能看到RDM并没有比VMFS更加高性能（或者说VMFS本身性能已经非常好了）。
当然，在一些特定的场景（比如SAN管理软件）需要直接访问底层磁盘，这时候就需要使用RDM了。
详细的性能对比，可以查看官方说明。
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK