LUNs per target - VMWare - iSCSI

Notice: Page may contain affiliate links for which we may earn a small commission through services like Amazon Affiliates or Skimlinks.

Stril

Member
Sep 26, 2017
191
12
18
41
Hi!

I read some different things and I am not sure about the best way to setup iSCSI targets for VMWare:

ZFS-storage is serving zvols as LUNs but: How many LUNs per Target?

- 1 LUN per target?
- many LUNs and only one target?

Its one big storage, but I read multiple things about not to put too many VMs on one datastore because of the limited queue depth per datastore, but is it also limited per target?

Thank you for your help!

Stril
 

gea

Well-Known Member
Dec 31, 2010
3,156
1,195
113
DE
You can control access and visibility with target groups and target portal groups.
Depending on your concept this can mean one or more targets.

From ZFS view a Lun is a file or a zvol on a pool. From a performance view it does not matter if you use one ore Luns. More important ist the restorability of VMs from a ZFS snap. As you do not have access to single files/VMs, you can only rollback the whole zvol with all VMs on it. This may be the main reason to use more than one LUN.

That said, why do you want iSCSI. NFS is as fast and allows a filebased access to the share (via NFS and SMB at the same time), a file/VM based access to ZFS snaps (ex via Windows and previous versions) and is therefor much easier to manage.
 

Stril

Member
Sep 26, 2017
191
12
18
41
Hi!

Thank you for your answer!

From ZFS-view, that is clear, but I do not fully understand the "VMWare-view". There seem to be different queues and VMWare recommends to use smaller LUNs instead of some big ones. For ZFS it should be equal to have on zvol on a pool instead of multiple ones.

Do you know, if VMWare handles 1 target with 5LUNs like 5 targets with 1 LUN?

About NFS vs iSCSI:
I REALLY like the fact that iSCSI can do real MPIO with seperated switches in case of network issues like packet storms, etc. Within the last years, I started to have two completely independent switch-infrastructures...
 

TRACKER

Active Member
Jan 14, 2019
178
55
28
NFS as datastore for ESXi is pretty slow for me, i get around 10-15MB/s write speed, read speed is bit better, around 30-40MB/s.
Compared to regular CIFS access (Solaris 11.4 ZFS NAS), where i get between 500 and 750MB/s reads/writes...
I know NFS is slow because sync writes, still not sure how i can workaround that. Probably i shouldn't :)
 

gea

Well-Known Member
Dec 31, 2010
3,156
1,195
113
DE
NFS3 and SMB should perform similar.
Sync is not related to a protocol but is a setting.

For NFS it is a ZFS filesystem property. With sync=default, you use sync with ESXi and NFS. On iSCSI the effective sync setting is then determined via the writeback property of a lu and defaults to sync=off.

For iSCSI you can enable sync either via writeback=off or force with sync=always on the underlying ZFS filesystem/zvol. For SMB sync=default also means sync=off.

For VM storage, I would always suggest to enable sync (any sharing protocol) as otherwise a crash can corrupt the filesystem (ex ntfs, ext4) of a VM.
 

zxv

The more I C, the less I see.
Sep 10, 2017
156
57
28
Hi!

Thank you for your answer!

From ZFS-view, that is clear, but I do not fully understand the "VMWare-view". There seem to be different queues and VMWare recommends to use smaller LUNs instead of some big ones. For ZFS it should be equal to have on zvol on a pool instead of multiple ones.

Do you know, if VMWare handles 1 target with 5LUNs like 5 targets with 1 LUN?
In the esxi host, there is a queue depth limit per VM, per LUN, and per iscsi adapter.

In the driver:
Code:
esxcli system module list -m iscsi_vmk
iscsivmk_HostQDepth       int    Maximum Outstanding Commands Per Adapter
iscsivmk_LunQDepth        int    Maximum Outstanding Commands Per LUN
In the adapter:
Code:
esxcli iscsi adapter param get -A vmhba64
Name                  Current     Default     Min  Max       Settable  Inherit
--------------------  ----------  ----------  ---  --------  --------  -------
MaxCmds               128         128         2    2048         false    false
In the LUN:
Code:
esxcli storage core device list --device naa.624a93704bfab20d4b694df7000143ac
Device Max Queue Depth: 113
No of outstanding IOs with competing worlds: 32
'outstanding IOs with competing worlds' is a per VM limit. Increasing it to the max (113 here) can cause very high latency, even if a single VM is active.

After trying to tune a bunch of these parameters, I've found only one parameter that I tune in general, and that is the multipathing. By default, only a single path is active when using multipath iscsi. You can make all paths active by setting the policy to round robin (below). By default, esxi switches path ever 1000 iops. Most of the storage vendors recommend switching paths every single iop (iops=1). I see better random mixed read/write IOPS with somewhere in between (e.g. iops=64). Here's how to set what the vendors recommend.

Code:
esxcli storage nmp device set -d vmhba64 --psp=VMW_PSP_RR
esxcli storage nmp psp roundrobin deviceconfig set -d vmhba64 -t iops -I 1
Lastly, note that you can multipath NFS 4.1, and it will increase the performance, even if the paths are on the same link, subnet, etc., as long is there's enough network bandwidth. With jumbo frames, I see multipath NFS 4.1 outperform mulitpath iscsi, plus you can use one huge store and it doesn't require any tuning.
 
Last edited:

zxv

The more I C, the less I see.
Sep 10, 2017
156
57
28
NFS as datastore for ESXi is pretty slow for me, i get around 10-15MB/s write speed, read speed is bit better, around 30-40MB/s.
Compared to regular CIFS access (Solaris 11.4 ZFS NAS), where i get between 500 and 750MB/s reads/writes...
I know NFS is slow because sync writes, still not sure how i can workaround that. Probably i shouldn't :)
Using multipath NFS 4.1, and jumbo frames, I see 1.5 Gbytes/sec sequential write and 2 Gbyte/sec sequential read. This was on ubuntu 18.04 and zfs 0.7.5.

I've gotten good results from omniosce as well, but I'm still searching for a 40Gb/s NIC that performs well on omnios, and that's been a limiting factor, otherwise I'd switch back to omnios.
 

muhfugen

Active Member
Dec 5, 2016
156
45
28
Most of the storage vendors recommend switching paths every single iop (iops=1).
I'm not sure about yours, but just to put this out there, but not all storage arrays support round robin. VMware vSAN's iSCSI Target for instance only supports multipathing for failover.