Latest posts by Brandon Lee (see all)
- SolarWinds Access Rights Manager: Automated access rights management - Tue, Nov 12 2019
- Securden Privileged Account Manager: Password management for privileged accounts - Thu, Nov 7 2019
- SolarWinds Serv-U: Fast, easy, and secure file transfers - Tue, Nov 5 2019
VMware vSAN is the premiere software-defined storage solution in the enterprise data center today and is arguably the market leader in this space. With each release, VMware has continued to improve the platform. It is known for its simplicity and feature set. One of the interesting features provided by VMware vSAN is the ability to take your software-defined storage and provide traditional legacy iSCSI storage targets to technologies that can consume iSCSI.
If you currently have Windows Server Failover Clusters in your vSphere environment that use RDMs for shared disks in use cases such as quorum, SQL Failover Cluster Instances (FCI) and Scale-out File Server (SOFS), these can now fully migrate to vSAN without the use of RDMs. In this way, customers who have been using the very problematic Raw Disk Mapping (RDM) storage can now migrate to vSAN iSCSI storage.
VMware vSAN iSCSI Overview ^
VMware vSAN iSCSI is a relatively new feature that has been added to the feature set of VMware vSAN. Introduced in vSAN 6.5, the iSCSI feature allows external resources to have access to vSAN storage. This provides many advantages outside of simply being able to provision storage on your vSAN datastore for external access.
This new feature not only allows for the connection of physical hosts to a vSAN datastore, but also allows the physical host to take advantage of SPBM and other vSAN features such as deduplication, compression, encryption and QoS for physical machines external to a virtualized cluster. These are all tremendous benefits to the external iSCSI-enabled access.
VMware vSAN 6.7, however, was a game changer for the VMware vSAN iSCSI service, as it made possible using this feature for one of the most powerful use cases—Windows Server Failover Clusters. The new vSAN 6.7 release provides additional iSCSI features for use with WSFC that was missing in the vSAN 6.5 release. With vSAN 6.7, the fully transparent failover of LUNs is now possible with the iSCSI service for vSAN when used with Windows Server Failover Clusters.
What does this mean? It means if you have a failed host in the vSAN cluster, the WSFC is pointed to for the iSCSI LUN access, and the LUN can be transparently failed over to another host in the vSAN cluster, allowing the shared iSCSI storage to continue to function.
How the vSAN iSCSI Service Works ^
How does VMware pull off being able to present a vSAN datastore to external physical resources for use as iSCSI shared storage? Interestingly, the iSCSI LUNs hosted on vSAN are essentially large empty virtual disk (VMDK) container objects that are managed and protected by storage policy configurations. And, as of vSAN 6.7, this means that the properties of these objects can be modified without bringing the LUNs offline.
VMware vSAN iSCSI Service Components
iSCSI Targets - The iSCSI Target is the same traditional construct we are used to with traditional SANs. Similar to traditional SANs, VMware identifies the iSCSI targets by a unique iSCSI qualified name (IQN). This unique IQN number is used to present the iSCSI target to the remote host provisioning the iSCSI storage via an iSCSI initiator.
The iSCSI Target contains the storage LUN that is provisioned as storage on the remote host. With the VMware vSAN iSCSI service, when configuring the iSCSI Target, you configure the LUN size, vSAN Storage Policy and enable the iSCSI Target service on the vSAN cluster itself.
iSCSI Initator Group - The iSCSI Initiator Group defines a group of iSCSI initiatiors that have access to the iSCSI target. The iSCSI Initiator Group provides a security construct that can be used to restrict access to only those initiators that are members of the group. If you do not create an iSCSI Intiator Group, then the target is accessible to all iSCSI initators.
VMware vSAN iSCSI Benefits, limitations, and maximums
There are many great benefits included with the VMware vSAN iSCSI service in VMware vSphere 6.7, including Windows Server Failover Cluster support. Below are other key benefits of the solution.
- Support Windows Server Failover Cluster (WSFC)
- iSCSI target performance greatly increased over VMware vSAN 6.5 release of the iSCSI service
- For mapping VMDKs to physical Oracle RAC deployments, this is the preferred method
- Sharing vSAN resources with physical workloads has been greatly improved
- Supports common iSCSI authentication methods including CHAP and Mutual CHAP authentication
- Storage Policy-Based Management protects the iSCSI target objects based on the policy implemented
- The solution can be managed using a variety of methods, including vCenter Server, vSAN APIs, and PowerCLI
- Currently, Windows Server Failover Clusters are the only supported virtual machine use case
- Unsupported vSAN iSCSI targets for other VMware vSphere ESXi hosts
- Not supported-party hypervisors
- for Multiple Connections per Session (MCS)
- Maximum 1024 LUNs per vSAN cluster
- Maximum 128 targets per vSAN cluster
- Maximum 256 LUNS per target
- Maximum LUN size of 62TB
- Maximum 128 iSCSI sessions per host
- Maximum 4096 iSCSI IO queue depth per host
- Maximum 128 outstanding writes per LUN
- Maximum 256 outstanding IOs per LUN
- Maximum 64 client initiators per LUN
Other VMware vSAN iSCSI Notes
Below are a few other points to note from VMware KB 54461 regarding the use of the vSAN iSCSI Target Service with SQL Server Failover Clustering.
- vSAN native fully supports Microsoft cluster techniques with shared disks on 6.7 U3 or higher.
- vSAN iSCSI Target Service supports Microsoft clustering with shared disks on 6.7 or higher.
- RDMs for WSFC using iSCSI Target Service is not officially supported on vSAN.
- Initiators can be either from virtual machines or physical servers. For guest initiators in virtual machines, those virtual machines can be residing on:
- The same vSAN cluster that provides the iSCSI target service
- vSAN Stretched Clusters using iSCSI Target Service are not supported.
Configuring the VMware vSAN iSCSI Service ^
Let’s run through configuring the VMware vSAN iSCSI Service and adding the configured storage to Windows Server Failover Cluster hosts.
In the vSphere Client, navigate to your vSAN Cluster settings > Configure > vSan Services > vSAN iSCSI Target Service and click the Edit link.
In the dialog box that opens, click the toggle button next to vSAN iSCSI target service to enable it.
Next, we need to add a new vSAN iSCSI Target. Click Configure > vSAN iSCSI Target Service > vSAN iSCSI Targets > Add.
In the New iSCSI Target dialog box, you can configure the following settings:
- Storage policy
- TCP port
You can leave the defaults on everything besides the Alias, which you will need to populate.
The new iSCSI Target has been created. Next, we need to create the vSAN iSCSI LUN. Click the Add button under the vSAN iSCSI LUN <your Target>.
Creating a new vSAN iSCSI LUN
In the Add LUN To Target dialog box, you have a few things to populate. You will need to provide an Alias and Size. You can also change the Storage policy to a different policy than the default.
The vSAN iSCSI LUN has been created, which you can verify in the iSCSI Target Service dashboard.
We are not configuring this in the walk through; however, if you want to scope down the initiators that have access to the vSAN iSCSI Target, you can do so by creating an Initiator Group.
Now that the vSAN iSCSI Target and iSCSI LUN are created, we can connect to the new vSAN hosted LUN from our Windows Server Failover Cluster hosts.
Adding a vSAN iSCSI Target LUN to Windows Server Failover Cluster Hosts
Launch the iSCSI Initiator Properties on the Windows Server Failover Cluster host. You can do this by typing iscsicpl in either the run menu or search box. Under the Discovery tab, click the Discover Portal button. Then enter the VMkernel IP of each of your ESXi hosts in the vSAN Cluster.
You want to enter all the host IPs for iSCSI Target connectivity, as this provides failover capabilities if you have an ESXi host that fails.
After adding the ESXi VMkernel IPs to the Discover Portal configuration, you should see them listed in the Discovery tab.
Under the Targets tab, you will see the Discovered Targets including the vSAN iSCSI IQN. It will be Inactive. Click the Connect button to connect to the target.
Click OK in the Connect To Target dialog box.
Verify that the Volume/mount point/device is listed under the Volumes and Devices tab.
Launch Disk Management on your WSFC host(s). You should see the dialog box on the first WSFC host to initialize the disk.
After initializing the disk, it should appear Online in Disk Management.
Concluding thoughts ^
VMware vSAN provides very interesting use case opportunities in the enterprise data center. This includes the ability to create shared drives for Windows Server Failover Cluster hosts, which can effectively allow customers to revisit using RDM disks with virtual machine WSFC hosts.
The configuration of the VMware iSCSI Target Service is very straightforward. With only a few clicks in the wizard-driven interface, you can quickly provision the service, provision a target LUN on your WSFC hosts. Additionally, you gain all the benefits of vSAN, including the protection of objects and Storage Policy-Based Management.