It's probably safe to say that storage is still one of the biggest (if not the biggest) design challenges for VDI environments. Badly-designed storage can cripple a VDI system; the storage vendors and technologies tend to be new (or at least less known) to people architecting VDI; and there are literally dozens of different vendors to choose from.
It's probably safe to say that storage is still one of the biggest (if not the biggest) design challenges for VDI environments. Badly-designed storage can cripple a VDI system; the storage vendors and technologies tend to be new (or at least less known) to people architecting VDI; and there are literally dozens of different vendors to choose from. Heck, at BriForum 2013 Chicago last month we had nine storage vendors in our demo area, making up a full 30% of the vendors present. (At BriForum we had Atlantis Computing, Dell, Greenbytes, NetApp, Nimble Storage, Nutanix, Pure Storage, Tegile, and Tintri. Then there are also VDI-specific storage solutions from Convergent.io, Cleversafe, CloudByte, DataCore, EMC (including Data Domain, XtremeIO, and others), HP, IBM, Kaminario, Nimbus Data, Oracle, Promise Technology, Sanbolic, Skyera, VMware (including Virsto), Whiptail, and probably dozens of others that I'm forgetting.
Download: All-Inclusive 51-Page VDI Project Success Plan
When planning for VDI success, where do you begin? What options are available? What challenges might you run into? This expert all-inclusive VDI guide features 12 chapters to provide details on how to plan for a successful deployment, compare vendors and products, determine your ROI and much more.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
You also agree that your personal information may be transferred and processed in the United States, and that you have read and agree to the Terms of Use and the Privacy Policy.
The other challenge is that storage technologies are changing rapidly. In our 2012 book, The VDI Delusion, storage for VDI—at least the way that we prefer to do VDI—was still a major showstopper. But then fifteen short months later several storage technologies emerged that addressed those issues and we updated the book with a new title, The New VDI Reality, to incorporate those changes.
So if you're designing a VDI environment, where do you even begin? How do you pick storage a storage vendor for VDI, especially when they're all saying they're better than the others?
I'm going to try to shed some light on that topic today. I'm not going to come out and say, "You should use Vendor X or Technology Y," rather, I'm going to share some things that are important when evaluating VDI storage which can hopefully work as a starting point as you look at the dozens of vendors and technologies out there. So here's my starting list:
Understand VDI storage requirements and how they differ from virtual server storage needs
The first thing to understand is that desktop workloads in a datacenter do not have the same storage requirements as server workloads. To begin with, you typically have a lot more desktop VMs per host (hundreds) than server VMs (just a few), and the desktop VMs tend to be more similar to each other than servers. Desktops are extremely read heavy during the boot and logon process, but once they're up and running they flip to become extremely write-heavy.
We've got a whole chapter in the book on this, but the short version is that you need lots of random IOPS for desktops, and you need them to be both read and write. (Check out the amazing article from Ruben Spruijt and Herco van Brug about understanding VDI storage. 86,000 views and counting!)
Don't pick your VDI storage vendor just because they're your "standard" enterprise storage vendor
When we look at struggling VDI environments in the real world, we'll often ask, "Why did you pick Vendor X for your storage?" Unfortunately we tend to hear, "Because they're our corporate standard storage vendor."
Wrong!
Desktops and servers are different. You don't put HP 1U rack mounted servers under your users' desks, do you? Then why would you choose a storage vendor for desktop virtualization just because it's the vendor you use for server virtualization? Desktops are not servers. Desktop storage is not server storage.
Flash is better. Or not. Actually, who cares?
Flash and SSD is all the rage with storage vendors today. Terms like SLC, MLC, EMLC, PCI-based, flash-backed, flash-fronted, and flash-accelerated are thrown around like you're supposed to know what the hell they all mean and why it matters. Here's the secret to understanding flash: It doesn't matter. What matters is that the storage system can deliver a given amount of storage at a given amount of IOPS with a given amount of power in a given number of rack units. Whether the vendor uses flash, spinning disks, RAM, squirrels, monkeys, or coconuts doesn't really matter. To paraphrase Jerry Seinfeld's bit about over-communicative airline pilots, "Yeah, fine.. whatever... You just do whatever the hell you gotta do back there to support my requirements."
Some vendors are pure flash, some are a mix, and some do all their magic in RAM and use 100% spinning disks. Whether a vendor uses flash or not has no bearing on whether they can build a storage system that meets your VDI needs. So if they use flash, fine. Whatever. If not, that's fine too.
Single instance block-level (a.k.a "inline dedupe") is required! Or.. wait.. is it??
I've written and spoken several times this year that "single instance block-level storage" (also known as "inline deduping" is required for persistent VDI today. But just like what I wrote in the previous item about flash, this issue is an "in the weeds" technical nuance that doesn't really matter. (I'm going to change my phrasing around that moving forward.) Sure, single instance block-level storage / inline deduping is one technique that many vendors use to support persistent VDI, but it's not the only way. (Some just have great caching, others serialize writes, etc.) At the end of the day I don't really care what technique the vendor uses to support my persistent desktops at a required IOPS and price point. Whether they use inline dedupe or not is up to them—I don't care how they do it.
Make sure they can support persistent VDI
I've written quite a bit about how I believe that most VDI environments should be based on fully persistent desktops. (After all, if you want a datacenter-hosted desktop that's non-persistent, then why don't you just use RDSH / Terminal Server / XenApp for about 1/3 the cost?) It's surprising that even in 2013, a lot of VDI storage vendors are only focusing their marketing, reference architectures, and pricing on non-persistent. (I blame VMware for this since they don't support RDSH, and they have a lot of virtualization mindshare, so they steer all datacenter-hosted desktop projects down the VDI path.)
So if you want your VDI environment to be persistent, make sure your storage vendor can support it. (And if you want your VDI environment to be non-persistent, then ask yourself why you're using VDI instead of RDSH?)
See how granular their scalability is
One of the biggest issues I have with storage vendors who sell hardware is that the hardware often comes in a big "chunk" that you can only buy in multiples of one big chunk at a time. For example, if a vendor has a $75,000 storage appliance that can scale to 1,000 VDI desktops, you have to pay at least $75k whether you're building VDI for 100, 300, or 1,000 users. And then when you grow your environment from 1,000 to 1,050 users, you have to spend another $75k for those last 50 users.
Software-based storage vendors have the advantage that you can buy the specific number of licenses for your exact environment, though there are several hardware storage vendors who offer upgradeable components (controllers, spinning disks, flash, SSDs, and/or memory) so you can upgrade your hardware storage in smaller chunks too. So make sure your storage vendor's sizing jives with your current and near future plans.
Don't be fooled by the "price per desktop" marketing number
A few years ago I wrote "How to lie with cost models." (Actually that's also an entire chapter in our book.) I could probably write a similar article called "How to lie with VDI storage costs per user." A few tricks include:
Cost-per-user numbers could be for "light" user workloads which represent ideal lab conditions which differ from your real world conditions.
Vendors often talk about pricing for non-persistent desktops based on a single master image (linked clones, etc.), while your VDI environment might be for persistent desktops
Vendors with pure software solutions can talk about their software costs per user without considering hardware costs. (Or they don't include the fact that they need to run a storage controller VM on each of your VDI hosts which means that host runs fewer desktops, thus requiring more VDI servers overall.)
Their costs per user might be for some huge storage appliance that supports 1,000 users, and you only need 300 users.
Vendors tend to talk about "average" IOPS which are not at all aligned with the real world. (After all, if a VDI vendor thinks that 20 IOPS are okay for a desktop, then why are we replacing the 80 IOPS spinning disk hard drives in our laptops with SSDs?)
Plus more I'm sure
What else am I forgetting?
The bottom line is that the latest storage products can enable VDI to succeed where even a year ago it would fail. Unfortunately every environment is different, so it's impossible to label one vendor or storage technology as the "best" for VDI. But hopefully this gives you a starting point to frame your VDI storage conversation with the vendors you're considering.
pure storage for vdi, storage requirements for vdi, storage sizing for vdi
Source: http://docphy.com/technology/computers/software/pick-storage-vendor-vdi-hint-flash-single-instance-dont-matter.html
No comments:
Post a Comment