Previously iSCSI on vSAN was not supported. Why was this?
Normally vSAN Stretched clusters implement a site locality construct to avoid unnecessary inter-site latency being added to the read IO path (They prefer all reads from the local site). The challenge came from the fact that the iSCSI service had no awareness of the two fault domains, and you easily get in a situation where an iSCSI target would be placed on the secondary site, while serving IO to virtual machines on the first site. As a result, it would be possible for data at the preferred site where a virtual machine is being served to be sent to an iSCSI target on the remote site, and then come back as an iSCSI packet to a virtual machine running at the preferred site.
To prevent this problem, vSAN 7 Update 1 now supports setting a preferred site for an iSCSI target to live. Note, in the event of a complete site failure, the preference will be discarded and the service will cleanly failover to the other side of the stretched cluster. This combined with other networking improvements and performance optimizations I mentioned in this blog, should help round out this new use case.
The UI includes both ability to assign an ownership location, but also monitor the status of the current owner against this configuration.
It is possible to relocate to the preferred location. You will also receive a warning if something has caused a target to run at the non-preferred location.
It is worth noting that vSAN does support clustered VMDKs that can present SCSI-3PR clustering. For information on how to present these volumes (Without the need for iSCSI) see this blog.
As always if you have any questions, I’ll be on Twitter @Lost_Signal.
