With Virtual SAN gaining huge momentum, I had a pretty busy VMworld 2016 in Las Vegas, and I didn’t have too much free time this year to immerse myself in the Solutions Exchange. However there were a few folks that I did want to catch up with as I had heard that they have some cool new features added to their product sets. So I made a bee-line to check them out. Let me know if you found anything else interesting. I might have a little more time in VMworld Barcelona to check out the solutions exchange and see what else is going on.
Last week I had the opportunity to drop down to San Jose and catch up with our friends on the FlashSoft team at SanDisk. In case you were not aware, this team has been developing a cache acceleration I/O filter as part of the VAIO program (VAIO is short for vSphere APIs for I/O Filters). SanDisk were also one of the design partners chosen by VMware for VAIO. This program allows for our partners to plug directly into the VM I/O path, and add third-party data services, such as replication, encryption, quality of service and so on. An interesting observation made by the FlashSoft team is that implementing their acceleration data service via VAIO gives much greater performance than their previous product version which plugs into the Pluggable Storage Architecture (PSA) stack.
Manish, Rich, Serge and Tom gave us another update on the 4.0 version of the FlashSoft product. I had seen this before, as the guys tech previewed it at VMworld 2015 last year. However with the release of FlashSoft 4.0, the guys now have the first certified VAIO I/O Filter on the market. SanDisk are our first certified partner for VAIO. Rich Petersen has a good write-up on the capabilities here on the SanDisk blog.
The guys were also kind enough to give me access to the components and some evaluation licenses, so I could test it out in my own labs. The documentation is pretty good so I won’t go into too much detail. However these are the steps to get going:
It has been some time since I last looked at Horizon View on Virtual SAN. The last time was when we first released VSAN, back in the 5.5 days. This was with Horizon View 5.3.1, which was the first release that inter-operated with Virtual SAN. At the time, there was some funkiness with policies. View could only use the default policy at the time, and the default policy used to show up as “none” in the UI. The other issue is that you could not change the default policy via the UI, only through CLI commands. Thankfully, things have come a long way since then. In this post, I will look at how Horizon View 7 inter-operates with Virtual SAN 6.2, concentrating mostly on policies. However, Horizon View 7 also has new vmFork/Instant Clone technology and AppVolumes, and I hope to be able to do some posts on those features running on top of VSAN going forward.
In the VSAN 6.0 Design & Sizing Guide, a caveat was placed around the size of a VMDK, and the Number of Failures to Tolerate (FTT) number. It reads like this:
“If the VMDK size is greater than 16TB, then the maximum value for NumberOfFailuresToTolerate is 1.”
I’m pleased to say that this restriction has been lifted in VSAN 6.2.
I got a bit of a surprise a few weeks back when I noticed a register article by Chris Mellor stating that PrimaryIO (previously CacheBox) had announced a new cache acceleration I/O filter for vSphere. We first announced plans for VAIO (vSphere APIs for I/O Filters) back at VMworld 2014. VAIO allows VMware partners to plug their products/features directly into the VM I/O Path which in turn will give our customers access to 3rd party storage services/features like deduplication, compression, replication or encryption which may not be available on their storage array. Or in this case, a cache acceleration feature. I wasn’t aware of any announcement internally at VMware, so reading it on the register came as a bit of a surprise. I know that other partners such as SanDisk and Infinio are also working on cache acceleration products. However this was the first time I heard of PrimaryIO developing a cache acceleration filter.
Earlier this month I had the opportunity to meet with a number of VMware customers in both Singapore and in the UAE. Most of the sessions were enablement and education type sessions, where there was a lot of white-boarding of VSAN (VMware’s hyper-converged infrastructure product) and Virtual Volumes (VVols – Software Defined Storage or SDS for the storage arrays). This wasn’t a sales session; I’m not in sales. The objective of these sessions was simply to educate. I guess when you are immersed in this stuff 24×7, it easy to fall into the trap of believing that everyone is well versed in this technology, and that’s simply not the case.
With both virtualization teams and storage teams in the room at the same time, it was important to show the building blocks with each approach, as well as to compare and contrast the advantages of the different storage solutions over the other. As I repeatedly delivered the same session, I thought it might be useful to share my thoughts with a broader audience, in the guise of this blog post.
I had a query recently from a partner who was deploying VMware Horizon View 6.1 on top of an all-flash VSAN 6.0. They had done all the due diligence with configuring the AF-VSAN appropriately, marking certain flash devices as capacity devices, and so on. The configuration looked something like this:
The they went ahead and deployed Horizon View 6.1, which they had done many times before on hybrid configurations. They were able to successfully deploy full clone pools on the AF-VSAN, but hit a strange issue when deploying linked clone pools (floating/dedicated). The clone virtual machine operation would fail with an “Insufficient disk space on datastore” error, similar to the following: