One of the new features of vSAN 6.5 is iSCSI access, so before I talk about how to configure iSCSI on vSAN let me just cover what is meant by iSCSI on vSAN to avoid any confusion 🙂
As we know, vSAN is an object based storage system, everything that exists on vSAN is an object that has a storage policy applied to is via Storage Policy Based Management, in vSAN 6.2 the vSAN performance metrics are stored on vSAN as an object also, so vSAN is already gearing up for other types of objects and not just a file system for running virtual machines.? The iSCSI side of vSAN is no different, the iSCSI Target has a home folder object just like a virtual machine, and each iSCSI LUN created has it’s own object, just like a VMDK does for a virtual machine.? The main use cases for vSAN are as follows:
- Physical Workloads
- In virtual machine Software iSCSI (as at the time of writing this, it will be supported in a future release)
- Microsoft Cluster Service (MSCS) and Windows Failover Cluster Instance (FCI) (as at the time of writing this, the MSCS/FCI will be supported in a future release)
VMware does not allow the presenting of iSCSI LUNs on vSAN to other vSphere clusters, when I sit back and think about that statement I can see a few reasons for this
- There is no SATP in ESXi for vSAN iSCSI
- You lose the whole functionality Storage Policy Based Management for your virtual machines
- You end up defeating the object of vSAN and start placing all of your Virtual Machines back onto LUNs again
So how do we configure iSCSI on vSAN?? Well just like the whole simplicity around vSAN, iSCSI is no different and is extrmely simple to set up, for the purpose of the test I used a Windows 2012 Server Virtual Machine and the iSCSI Initiator Service in Windows
Step 1 – Create an iSCSI VMKernel Interface
This interface will be used for iSCSI communication to allow the iSCSI traffic to flow over to our Physical or even Virtual Machines
Step 2 – Enable the iSCSI Service on vSAN
Suring the enabling you are presented with various options:
- VMKernel Interface
- TCP Port Number
- Authentication Method (CHAP and Mutual CHAP suupported)
- The Storage Policy to be applied to the Home Object for the iSCSI Target
Step 4 – Create an iSCSI LUN
For this I am creating an iSCSI LUN with a storage policy I have specified where my iSCSI LUNs are 100% Space reserved as per my Storage Policy, when creating the LUN it gives you an example on the right hand side of what this looks like from a vSAN Perspective, since I am using RAID1 – FTT=1, my 40GB LUN Object will consume 80GB of space and will be 80GB Reserved as per the policy
After this my display shows the LUN as being created and storage policy compliant
Step 5 – Add an Initiator or Initiator Group to the LUN Object
Before the Virtual Machine can see the LUN, I need to add the Initiator for the VM into the Allowed Initiators, I copied the initiator name from my virtual machine and pasted it in here
And the display shows this as now being added
From a vSAN perspective this is the iSCSI configuration completed, so now I need to go to my Windows virtual machine and configure the iSCSI Initiator side of things, so the first thing I need to do is enable MPIO for iSCSI, this is listed in Windows 2012 under Administrative Tools, ensure the “Add support for iSCSI devices” is selected
Once I have MPIO configured for iSCSI Devices it is time to add my iSCSI Target, for this you need to go into Adminisrative Tools and select the iSCSI Initiator service, once in there go to the “Discovery Tab” and enter the IP Address of your iSCSI Target, in my setup the iSCSI Target was being hosted by host 2 and for this the iSCSI IP is 192.168.50.2
Configure any advanced settings for example if you are using CHAP/Mutual CHAP, then click on the “Targets” tab and you will see your Target IQN as “Inactive”, click on Connect
In here select “Enable Multi Path”
Once connected I can now see my 40GB LUN in Device Manager and also in Disk Management, in Device Manager it is listed as “VMware Virtual SAN Multi-Path Disk Device”…..yes I know it’s no longer called Virtual SAN
That’s your iSCSI Configured on vSAN and also connected the LUN to a Windows 2012 Server, like I said, very easy to do
Is this a software iSCSI?
Software iSCSI is referred to as when the Initiator is using in Guest Operating system iSCSI, for example with ESXi connnecting to a traditional iSCSI SAN, some arrays have been certified to be used either with SWiSCSI, HW Dependent iSCSI and Hardware Independent iSCSI, obviously the SWiSCSI is controlled completely by the Software Stack
Since vSAN is Software Defined Storage, the iSCSI Target aspect is defined by software, it confirms to a policy the exact same way that a VMDK residing on vSAN does also
Hi
I’m using vsan iscsi for my microsoft fileserver cluster an everthing working fine.
but can you tell me, how i can backup the target? for the VMs i’m using veeam. but die iscsi target dose nocht backup with veeam…
thanks
Hi Sebastian
Right now the only option would be to use an in guest backup agent to back up tht eonctents of the iSCSI LUN associated with the File Server, this would be the same if you was using an RDM or using a VM that is using in Guest iSCSI to access a storage LUN provided from somewhere else. In the future you will be able to do this natively outside of the guest operating system
Thanks for this interesting post. My question would be: How does the vSAN iSCSI LUN behave, when Host2 is unavailable (planed maintenance, failure etc). Does Host1 now take over the iSCSI Initiator from Host2? Can I “manually switch” the Initiator from Host2 to Host1?
Thank you very much
From an ESXi host perspective, if say host 2 is the owning Target and it fails, vSAN will assign ownership of the target to another host in the cluster
Hi
I have a RAID 1 – FTT=1 with a stretched cluster. I need to create vSAN iSCSI LUNs for external SPARC machines. 3 specific configurations. Steps 1-4 are straight forward but when I get to step 5 I hit a bump. Do I need to create a Windows or Linux VM to serve the storage back to the SPARC machines or can this be accomplished without an additional VM? One of the SPARC configurations will need to be able to migrate to the alternate site in the event of the primary site failing. Will this be as seamless as reassigning the target between hosts in the primary site as indicated by your response to vWorkload? Thank you very much for your insight.
Step 5 is where you take your iSCSI Inititator IQN details from your Physical SPARC system and enter it in here, this is to allow that SPARC initiator to access the LUN object that you have just created, during a site failure in the stretched cluster, the iSCSI Target will be owned by another host in the cluster, this should be seamless to the SPARC system