Using NexentaConnect for file shares on VSAN
I already wrote an article on the NexentaConnect for VSAN product after seeing it in action at VMworld last year. More recently, I had the opportunity to play with it in earnest. Rather than giving you the whole low-down on NexentaConnect, instead I will use this post to show the steps involved in presenting a file share built by NexentaConnect to a VM. In this case, the VM and the file share both reside on Virtual SAN. I will also show you how to simply revert to a point-in-time snapshot of the file share using NexentaConnect. To answer the common question, “can VSAN do file shares as well as storing virtual machines?”, the answer is yes. This post will show you how.
Part 1: Initial Setup
There are 3 parts to the NexentaConnect solution:
- NexentaConnect Manager (available as OVA)
- Nexenta IO Engine (available as OVA)
- NexentaConnect Plugin for vCenter (EXE or script, depending on VC)
When the plugin is installed in vCenter, a NexentaConnect Settings icon is available. This allows the admin to configure communication between the Nexenta Connect Manager and the vCenter Server. It also enables Active Directory to be configured, allowing seamless integration for users wishing to access file shares later on. It also allows for the Nexenta IO Engine image to be identified. When everything has been configured correctly, all of the settings are displayed in green, indicating that everything is good to go:
We can now turn our attention to the other Nexenta icon on the vCenter home page, NexentaConnect for VSAN.
This is where the file shares are created. The vsanDatastore is recognized as a datastore that can be used for provisioning file shares. What happens is that, when a new file share is provisioned by Nexenta Connect, a new VMDK is added to the Nexenta IO Engine. Since this is VSAN, the VMDK can have a specific VSAN policy associated with it and the VMDK will be deployed on the VSAN datastore in accordance with the policy. Note that this is all integrated into the vSphere web client; there is no additional management window that needs to be launched, which is a nice bonus.
Part 2: Creating a share
Once in the Nexenta Connect for VSAN, a new file share can be created from the Summary tab by clicking on the icon below. The other icons relate to other operations such as edit or delete a file share and stopping and starting file share services. Note that the dashboard provides a lot of useful information regarding the file shares, but since I haven’t deployed any yet, its all zeros.
This launches a pop-up window where you need to provide information about the file share that you wish to create. One other thing to note is that if this is the first file share created, then there will be no Nexenta IO Engine deployed yet. When the first share is created, the image of the Nexenta IO Engine that has been installed previously is now cloned to a working Nexenta IO Engine. Therefore the network settings are important as this is the interface that will be plumbed up on the IO Engine. In this particular example, I am creating an SMB share of 5GB in size, and I am using a VM Storage Policy of FTT=1,SW=1 which is a policy that will create the share with a RAID-1 mirror configuration on the VSAN datastore:
When the share is created, we can examine the Nexenta IO Engine and see that a new 5GB VMDK has been created with a policy that reflects the policy chosen above:
If the policy for the VMDK is examined, we can see the layout of the components and the RAID-1 mirrored configuration:
What this means is that even if there is a host failure in the VSAN cluster, the share will still be available.
Part 3: Use the share from a Windows VM
Now it is time to use the share. The share can be mounted using default credentials, although Nexenta do support using Active Directory. Nexenta documentation shows how the Windows MMC “Shared Folders” plugin can be used for managing the share from within the Guest OS. Once the share is mounted on the Windows VM, it can be used for storing files, as you might expect. It’s as simple as one might expect. Note that the file share name reflects the policy name:
Part 4: A look at snapshot functionality
This is possibly the nicest feature from my perspective. The snapshot functionality provided by Nexenta Connect can be used directly with the Windows Guest OS. So in this example, I am going to create a snapshot of my important data via the NexentaConnect Manager, inadvertently loose the important files I created above, and then restore them without having to leave the Guest OS.
First, I create a snapshot. Note that I am taking a one-off snapshot, but that there is a snapshot scheduler also included.
Now, from the Guest OS, I accidentally delete the files from my share. Now what do I do? Very simply, right-click on the share, and select “Restore previous versions”:
And my files are back. Nice and simple, without ever having to leave the Guest OS.
So there you have it. If you are looking to use VSAN for both virtual machine hosting as well as file sharing, Nexenta provide a nice integrated solution. If you’d like to learn more, check out Nexenta’s web site.
On another note, this will be part of our excellent VSAN [A-Z] hands-on-lab (HOL) at VMworld 2015. The HOL id is #1608, and if you want to go through various features and functionality of VSAN, including the ecosystem around VSAN, this is the lab for you. As part of that ecosystem, Nexenta can provide file sharing if needed. If you are going to VMworld 2015, sign up for the lab to learn more.
2 Replies to “Using NexentaConnect for file shares on VSAN”
Comments are closed.