I mentioned in an earlier post that Cohesity were one of the vendors that I wanted to check out at VMworld 2015. These guys have only literally exited stealth. Just yesterday, I sat in on a webinar from Nick Howell, who I know extremely well from his days in technical marketing over at NetApp. Nick has now joined Cohesity as the role of an evangelist, which I think is a great move on Cohesity’s part. On Nick’s webinar, he introduced us to the vision behind Cohesity’s product, what they hope to fix in a customer’s environment and some teasers regarding where the direction “may” be going in the future.
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).
This question has come up on a number of occasions in the past. It usually comes up when there is a question about scalability and the number of disk drives that can be supported on a single host that is participating in Virtual SAN. The configurations maximums for a Virtual SAN node is 5 disk groups, with each disk group containing 1 flash device and up to 7 capacity devices (these capacity devices are magnetic disks in hybrid configurations or flash devices in all-flash configurations). Now the inevitable next question is how is this configuration implemented on a physical server. How can I get to 35/40 devices in a single server. There are a few ways to do it.
A couple of months back, I wrote a short article on Rubrik. They were just coming out of stealth mode and had started an early access program. Since they had not officially launched, there wasn’t a lot that I was allowed to say about the company, other than give a high level overview. As they have now officially launched their r300 series of products, along with news of a massive $41 million Series B of funding, I can now share some additional details about their products and technology. Just to recap on what Rubrik do, they are offering a converged and scale-out backup software and backup storage appliance. The Rubrik appliance (Brik) is a “rack and go” architecture, with the ability to scale from three to thousands of nodes (unlimited) using industry standard 2U commodity appliance hardware.
The whole pitch is the idea that “backups suck”, and they want to give administrators a much better back and restore experience, similar to Apple’s ‘Time Machine’ feature.
There have been a number of queries around Virtual Volumes (VVols) and replication, especially since the release of KB article 2112039 which details all the interoperability aspects of VVols.
In Q1 of the KB, the question is asked “Which VMware Products are interoperable with Virtual Volumes (VVols)?” The response includes “VMware vSphere Replication 6.0.x”.
In Q2 of the KB, the question is asked “Which VMware Products are currently NOT interoperable with Virtual Volumes (VVols)?” The response includes “VMware Site Recovery Manager (SRM) 5.x to 6.0.x”
In Q4 of the KB, the question is asked “Which VMware vSphere 6.0.x features are currently NOT interoperable with Virtual Volumes (VVols)?” The response includes “Array-based replication”.
So where does that leave us from a replication/DR standpoint with VVols?
Before I begin, this isn’t really a feature of VSAN so to speak. In vSphere 6.0, you can also blink LEDs on disk drives without VSAN deployed. However, because of the scale up and scale out features in VSAN 6.0, where you can have very many disk drives and very many ESXi hosts, being able to identify a drive for replacement becomes very important.
So this is obviously a useful feature. And of course I wanted to test it out, see how it works, etc. In my 4 node cluster, I started to test this feature on some disks in each of the hosts. On 2 out of the 4 hosts, this worked fine. On the other 2, it did not. Eh? These were all identically configured hosts, all running 6.0 GA with the same controller and identical disks. In the ensuing investigation, this is what was found.