Having been a student of how new tech finds it way into data centers, I am always impressed by how many IT professionals strike this great balance between getting the benefits from the new thing — and managing potential risk.As I talk to VSAN users, the pattern emerges. They certainly see the potential as compared to traditional storage, but are proceeding prudently. Today’s story has to be anonymous — not everyone wants their name used. Perfectly reasonable. Let’s call our VSAN adopter Ken, just to keep things simple.
The Basics
Ken works for a financial services firm of 1000+ employees, and — along with 2.5 other IT folks — is responsible for virtualization, storage, backup and probably a few more things — a role that he describes as “fully converged”.
Make no mistake — this is a very hands-on team. Ken was gracious enough to spend some time on the phone with me to describe his environment, what he’s doing with VSAN today — and what he intends to do in the future.
Getting Started
Ken first became interested in VSAN to support a disaster recovery requirement for their Horizon VDI environment: 600 users today, growing to 1000 and then the entire company. The primary VDI environment had already been rolled out on an all-flash array — what was now needed was a cost-effective DR target. Since his company had purchased the Horizon Enterprise edition, VSAN licenses were already included — making VSAN exceptionally cost effective in his situation.
Ken’s early performance testing showed that VSAN could easily handle the VDI load, and do so at essentially the cost of incremental hardware, thanks to the existing licenses. He’s got 7 servers in his VDI recovery cluster, with about 13% cache-to-usable-capacity ratio in front of 10K drives, something like 48TB total. Due to some delays associated with getting network connectivity going, Ken waited on rolling out VSAN 5.5 and went directly to VSAN 6. So far, he says VSAN has done exactly what he’s asked it to do. Now what?
Looking For An Array Alternative
Many of the company’s workloads currently run on shared, auto-tiering storage arrays — as you’d expect. Given his VSAN experience, Ken now has an eye on those as well. One array that’s being used to test and development is coming up for replacement — could VSAN potentially fill that bill?
To find out, he’s running a variety of database workloads against a beefy VSAN hybrid configuration — 7 hosts, five disk groups per host, five disk drives per disk group. One of his databases is large (7 TB), the remainders are more modest (2-3 TB). His first set of workloads were reporting runs that did database scans. While VSAN supports a modest striping policy, it doesn’t stripe as aggressively across the entire back end as do traditional (and more expensive) arrays. Heavily sequential workloads did better on the high-end array in some cases as a consequence. But the VSAN results are good enough for what he needs. He’s started to run some more transactionally-intensive database workloads, and is expecting impressive VSAN results, as these workloads are generally very cache-friendly.
And Those Branch Offices
Ken’s team is also responsible for a handful of remote offices. The workloads are very light: maybe 10-12 VMs, some light querying, etc. He’s strongly leaning to VSAN for these, as it eliminates the need for an external array entirely, in addition to simplifying the management environment.
And A Few Clusters To Grow
Down the road, Ken would like to build two VSAN clusters at the core of their environment — one hybrid cluster for the day-in-day-out workloads, and an all-flash VSAN cluster for the “problem children” as he puts it. He now sees enough potential use cases that he’s interested in potentially adding VSAN to their existing VMware ELA.
Some Pointed Feedback
Ken had some suggestions for the product team, which I’ll share here.
First, Ken decided to go the build-it-yourself route for his beefy VSAN clusters, vs using ReadyNodes. That decision forced a rather unwanted detour into the world of IO controllers, queue depths, RAID 0 vs. pass-through, and all that. Point noted — we need to do a better job making things easier for VSAN customers who decide to go that route. Second, Ken thinks we can do a better job on making software updates even simpler. He’s right — there’s more work we can do there.
A Pattern Emerges
Ken’s experience is not so dissimilar from other stories I’ve heard in demanding enterprise IT environments, especially those with lean, mean — and converged — IT teams. It starts with someone wanting something better than what they’ve been already doing for storage. On paper, VSAN looks like it does just that: great performance, attractive cost, and a hyperconverged management model. So they set up a small VSAN cluster, and start putting it through its paces. They find that — yes — it works pretty much as advertised. The next step is to find an opportunity to employ it in a moderate-risk production use case, and see how it holds up. In this case, it was DR for their VDI environment.
If that does well, now the net is a bit larger — what other storage assets are coming up for refresh? In Ken’s case, this means some additional testing, as you’d expect — as well as really understanding the cost model.
But this whole new technology process starts with a strong desire for a better solution, and investing the cycles to better understand what the alternatives are.
