A closer look at Nexenta Connect for VSAN
Whilst at VMworld 2014, I had the opportunity to catch up with the Nexenta team who have been working on a very interesting project with VMware’s Virtual SAN (VSAN). The Nexenta Connect for VSAN product, running on top of VSAN, is designed to provide file services, which allows VSAN to not only store your virtual machines, but also to provide SMB and NFS shares for those virtual machines. I caught up with Michael Letschin and Gijsbert Janssen van Doorn of the Nexenta team to learn more and get a tech preview of the product.
In a nutshell, Nexenta deploy the Nexenta Connect appliance on the VSAN datastore. This is integrated with the vSphere client to allow you to create, manage and monitor all aspects of the SMB or NFS shares that you create on the appliance. It deploys as a single appliance, but of course it uses VSAN’s availability mechanism for tolerating host failures, just like any other VM deployed on the VSAN datastore. It also can use vSphere HA, so that if the host on which the appliance’s compute is running goes down, vSphere HA can restart the appliance on another node in the VSAN cluster, making your SMB/NFS shares highly available.
The specs of the appliance running the Nexenta Connect are as follows:
- 4 vCPUs
- 16GB Memory
- 32GB boot disk
The Guest OS inside of the appliance requires < 8GB, but 32GB is reserved in case a memory dump is required)
The dashboard is pretty straight forward and simple to follow, but since it is integrated into the vSphere web client, you get a good idea of how the shares are performing at a glance. The dashboard, as you can see here, displays IOPS, Latency, Read acceleration, NFS share count and SMB share count. There is also data reduction information achieved, but right now data reduction is compression only, there is no deduplication currently.
Note that the guys at Nexenta are still tweaking the dashboard, so it may be slightly different in the final product, when it becomes available in the very near future. But I like the way they have designed this – very easy to read and understand.
Now, those of you familiar with VSAN will understand that the VM Storage Policies play a huge role in VM and VMDK deployments. For the boot disk of the appliance, there is a special predefined policy which sets Number of Failures To Tolerate. This is set to 1 on the appliance’s boot disk so that if there is a failure in the cluster, the boot disk of the appliance will still be available.
So what about the SMB And NFS shares that the appliance creates? Well, Nexenta Connect for VSAN enables VM Storage Policies to be created on a per share basis. So if you want to stripe a particular share, or you wish to reserve a certain amount of space, or even a percentage of flash read cache, you can create policies based on these requirements as you would for a normal VM or VMDK. This is fully integrated into the Nexenta Connect wizard for creating new shares. As you continue to use the same policy for new shares, additional filesystems are built on the same VMDK and the VMDK is grown accordingly to accommodate it. If you require a new share to have a different policy, a new VMDK is instantiated on the VSAN datastore and attached to the appliance. The same is true if the VMDK size starts to reach 2TB, since this is still the maximum VMDK size on VSAN; in that case a new VMDK is also created, but using the original policy. Here is a screenshot showing the different policies, one for the boot disk and another for the share:
What I particularly liked when I saw the demo is how integrated this product is with VSAN and with the vSphere client. The guys at Nexenta have done a really good job.
So what is the primary use case? Well, according to Michael, there could be many, but this is an ideal solution for your VDI/View desktops. These Nexenta Connect SMB shares can be mounted onto the Windows desktops to provide a persistent store for various user data and desktop data that must persist, even if the desktop does not have to. Since the appliance offers active directory integration, you have full access control already included.
Another nice feature is the snapshot functionality offered by Nexenta Connect. Since the filesystem underlying the appliance is ZFS, they offer users who mount a share on their desktop the ability to snapshot folders in their Windows Guest OS, and if given the appropriate permissions, the ability to roll back their folders to a particular point in time as well.
Another point to note is that through the use of Nexenta Connect, we can now allow hosts and virtual machines that do not reside in the VSAN Cluster to access the VSAN storage via the shares created by the appliance. Interesting concept.
DELL sent out a press release during VMworld 2014 in Barcelona to state that they will be including this product pre-integrated into their EVO:RAIL offerings when it launches. Supermicro have also made a similar EVO:RAIL & VSAN Ready nodes announcement.
As I stated earlier, this was a tech preview and the product is not yet generally available, but the plan is to have it out in early November, 2014. There may also be some final tweaks to the UI, so don’t be surprised if it is slightly different to the screen shots used here.
Finally Michael shared the licensing details. It looks like it will be priced at $650 per socket plus support.
Very interesting tool. Just a notation, for large data volumes, lots of memory will be required if used zfs deduplication.
Calculate memory requirement as follows:
Each in-core deduplication table (DDT) entry is approximately 320 bytes.
Multiply the number of allocated blocks by 320.
Here’s an example using the data from the zdb output in Listing 1:
In-core DDT size (1.02M) x 320 = 326.4 MB of memory is required.
Regards.
Jose