The storage space has been a very exciting space over recent years. There have been so many new start-ups and new innovations, that it becomes difficult to keep track sometimes. More recently, there has been a lot of news around mergers, acquisitions and IPOs in the storage industry. It got me thinking about a lot of the changes we have seen over the past 3-4 years in the storage market. Just for my own interest, I went back over many of my blogs, and the various conversations I had with people at various VMworld events and VMUG meetings, and tried to see where a lot of these companies/products are now, and what they are currently doing. Now, I am not going to mention every single vendor here. I’m simply trying to highlight the ones that were acquired or merged or indeed IPO’ed (and in some cases are no longer with us) during this period.
Many regular readers will know that we do not do read locality in Virtual SAN. For VSAN, it has always been a trade-off of networking vs. storage latency. Let me give you an example. When we deploy a virtual machine with multiple objects (e.g. VMDK), and this VMDK is mirrored across two disks on two different hosts, we read in a round-robin fashion from both copies based on the block offset. Similarly, as the number of failures to tolerate is increased, resulting in additional mirror copies, we continue to read in a round-robin fashion from each copy, again based on block offset. In fact, we don’t even need to have the VM’s compute reside on the same host as a copy of the data. In other words, the compute could be on host 1, the first copy of the data could be on host 2 and the second copy of the data could be on host 3. Yes, I/O will have to do a single network hop, but when compared to latency in the I/O stack itself, this is negligible. The cache associated with each copy of the data is also warmed, as reads are requested. The added benefit of this approach is that vMotion operations between any of the hosts in the VSAN cluster do not impact the performance of the VM – we can migrate the VM to our hearts content and still get the same performance.
So that’s how things were up until the VSAN 6.1 release. There is now a new network latency element which changes the equation when we talk about VSAN stretched clusters. The reasons for this change will become obvious shortly.
Datrium are a new storage company who only recently came out of stealth. They are one of the companies that I really wanted to catch up with at VMworld 2015. They have a lot of well-respected individuals on their team, including Boris Weissman, who was a principal engineer at VMware and Brian Biles of Data Domain fame. They also count of Diane Green, founder of VMware, among their investors. So there is a significant track record in both storage and virtualization at the company.
With the announcements just made at VMworld 2015, the embargo on Virtual SAN 6.1 has now been lifted, so we can now discuss publicly some of the new features and functionality. Virtual SAN is VMware’s software-defined solution for Hyper-Converged Infrastructure (HCI). For the last number of months, I’ve been heavily involved in preparing for the Virtual SAN 6.1 launch. What follows is a brief description of what I find to be the most interesting and exciting of the upcoming features in Virtual SAN 6.1. Later on, I will follow-up with more in-depth blog posts on the new features and functionality.
I’ve been involved in a few conversations recently regarding how VSAN trace files are handled when the ESXi host that is participating in a VSAN cluster boots from a flash device. I already did a post about some of these considerations in the past, but focused mostly on USB/SD. However SATADOM was not included in this discussion, as we did not initially support SATADOM in VSAN 5.5, and only announced SATADOM support for VSAN 6.0. It seems that there are some different behaviors that need to be taken into account between the various flash boot devices, which is why I decided to write this post.
As usual, there have been loads of things happening over the last 12 months in the storage space. The Solutions Exchange at VMworld is always a great place to meet new storage startups, and get some further information on their respective products and innovations. This year, I’ve made a note of a few startups that I wish to catch up with at VMworld 2015 and find out what issues are they trying to address with their technology, and why should a customer choose their solution over some of the others in the storage space.
Disclaimer: Please note that I am not endorsing any of these vendors. This is simply technology that I am interested in, and something I want to learn more about at VMworld. I’d urge any readers attending VMworld to do the same. For those not attending, my goal is to learn enough about these new startups so that I can write an article about them at some point (if I haven’t already done so).
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: